New User Special Price Expires in

Let's log you in.

Sign in with Facebook


Don't have a StudySoup account? Create one here!


Create a StudySoup account

Be part of our community, it's free to join!

Sign up with Facebook


Create your account
By creating an account you agree to StudySoup's terms and conditions and privacy policy

Already have a StudySoup account? Login here

Software Project Management

by: Miss Terry Reichel

Software Project Management CSSE 372

Miss Terry Reichel
GPA 3.52


Almost Ready


These notes were just uploaded, and will be ready to view shortly.

Purchase these notes here, or revisit this page.

Either way, we'll remind you when they're ready :)

Preview These Notes for FREE

Get a free preview of these Notes, just enter your email below.

Unlock Preview
Unlock Preview

Preview these materials now for free

Why put in your email? Get access to more of this material and other relevant free materials for your school

View Preview

About this Document

Class Notes
25 ?




Popular in Course

Popular in Computer Science and Engineering

This 75 page Class Notes was uploaded by Miss Terry Reichel on Monday October 19, 2015. The Class Notes belongs to CSSE 372 at Rose-Hulman Institute of Technology taught by Staff in Fall. Since its upload, it has received 23 views. For similar materials see /class/225106/csse-372-rose-hulman-institute-of-technology in Computer Science and Engineering at Rose-Hulman Institute of Technology.

Similar to CSSE 372 at RHIT

Popular in Computer Science and Engineering


Reviews for Software Project Management


Report this Material


What is Karma?


Karma is the currency of StudySoup.

You can buy or earn more Karma at anytime and redeem it for class notes, study guides, flashcards, and more!

Date Created: 10/19/15
Monitoring and reporting project status Chapter 10 pages 317342 CSSE 372 22anuary2008 Outline 0 Control vs risk 0 Other kinds of reporting 0 EV Why do we need to monitor progress 0 70 of projects are Over budget Behind schedule 0 52 of all projects finish at 189 of their initial budget o Average of 16 of SW projects are ontime and budget Source The Standish Group How to answer the question quotHave we done what we said we d do complete estimating ofbudget spent of work done of time elapsed subjective incomplete draws false conclusions Types of progress reporting 0 Current period reports 0 Cumulative reports 0 Exception reports 0 Stoplight reports 0 Variance reports 0 Numerical 0 Graphical Milestone trend charts Early 3 2 1 On Schedule Late 12345678 Project Month Early 3 2 1 On Schedule 1 2 3 Late 12345678 Project Month Early 3 2 1 On Schedule 1 2 3 Late Early 3 2 1 On Schedule 1 2 3 Late 123456789 Project Month 123456789 Project Month EVA 0 Earned Value Analysis EVA is 0 an industry standard way to measure a project s progress forecast its completion date and final cost and provide schedule and budget variances along the way 0 By integrating three measurements it provides consistent numerical indicators with which you can evaluate and compare projects Standard scurve qu I ll 1 Exam D E5411 Ea m 300 ew 1iIII raj 71quot 1 135 1113151i 1 2123 2729 WWI SCum Mu Ella wm imal mahmagi Let s talk terms 0 BCWS Budgeted Cost of Work Scheduled 0 Planned cost of the total amount of work scheduled to be performed by the milestone date 0 Author calls this PV ACWP Actual Cost of Work Performed 0 Cost incurred to accomplish the work that has been done to date 0 Author calls this AC 0 BCWP Budgeted Cost of Work Performed o The planned not actual cost to complete the work that has been done 0 Author calls this EV Variance 0 Positive 0 Indicates ahead of schedule or less cost than planned 0 May not always be good 0 Negative 0 Indicates behind schedule or more cost than planned 0 May not always be bad Baseline vs actual cost curve Progress Cost Variance lt Update Date Time gt Costperformance indicators BCWS BCWP ACWP lt Sdays gt lt 5 days lt 5 days gt I l I I I l 500 300 200 400 200 ScheduledBudgeted Schedule slippage Actual cost of work to do 500 work permits only 3 days300 performed 400 over 5 days in a work to be performed ACWP 400 5 day window BCWP 39300 Actual cost BCWS 500 Schedule variance 200 variance 100 Full story Reporting Es rimated East Cutoff late at Comp etian I I I u o W s mm O 0 Total Budglud Cost 0 3 u I quotat Ru Budget at Completion E E ACTUALS 1 D Q ijacledl Siippage EARNED VALUE K httpevmnasagovimageskeydatagif Performance indices 0 Schedule Performance Index 0 SP1 BCWP BCWS 0 Cost Performance Index 0 CPI BCWP ACWP AS A PROJECT WEARS ON STANDARDS FOR SUCCESS 5pr LOWER mo LOWER 0 HOURS OKAY I SHOULD BE ABLE TO DUAL BOOT BSD sooN 6 HOURS I39LL BE HAPPY IF I ANGEF THE SYSTEM WORKING LIKE IT HRS WEN I SPEED 10 HOURS 0 LJEIL THE DEsKmP39s A Losr muse BUTI IHINK ImN HXTHE PROBLEMS THE LAP IOPS DEVELOPED 2H HOURS tgATTu n wake 10ch THESHAHG mu STAY My UNnL WEREACH Mow WATER 453 quot IF WEF IAKE mm ALIVE YOU39RE NEVER GRADING ANYTHIW AGNN Let s do an example PROJECT STATUS Make 1000 widgets over 50 days 20 per day INPUT Total Expected Output 1000 INPUT Budgeted Unit Cost 50 Total Project Budget is 1000 X 50 500 httpwwwearnedvaIueanalysiscomindexcfmnextpageexample EVInput BCWS How much did we expect to pay for the work that was scheduled Total Project Days 10 Unit Production Per Day 20 widgetsday Budgeted Unit Cost 50widget BCWS 10 days x 20 widgets day x 50widget budget 100 EVInput BCWP How much did we expect to pay for the work that was actually done Actual Current Output 150 Budgeted Unit Cost 50widget BCWP 150 widgets x 50widget budgeted 75 EVInput ACWP What was the actual cost of the work that was completed Actual Current Output 150 Actual Unit Cost 60widget ACWP 150 widgets x 60widget actual 90 EV Analysis SV Schedule Variance BCWP BCWS The Question Are we ahead or behind production schedule SV BCWP BCWS 75 100 25 EV Analysis SPI Schedule Performance Index BCWPBCWS The Question How far ahead or behind schedule are we SP1 BCWPBCWS 75100 075 LT 1 s0 behind schedule EV Analysis CV Cost Variance is measured as follows If BCWP gt ACWP the project is UNDER budget If BCWP lt ACWP the project is OVER budget The Question Are we on or offbudget CV BCWP ACWP 75 90 15 negative means over budget EV Analysis CPICostPer n1nanceIndex The Question How far on or off budget are we CPI BCWP ACWP 7590 08333 less than 1 means over budget Project forecast EAC Estimate at Completion Method 1 BCWP at a point Estimates to completion Method 2 The ratio ofBAC CPI Method 3 Wilkens BAC BCWPCPI ACWP The Question At the rate going how much will all of this cost This is a SIMPLIFIED estimate ofEAC EAC BAC CPI 500 08333 600 Questions JPP Chapter 8 CSSE 372 7anuary2008 Outline 0 Questions on exam midterm anything 0 Chapter 8 0 Thoughts on Ch 9 and Ch 10 0 Questions Questions on exam midterm anything Why bother planning 0 Reduces uncertainty 0 Increases understanding 0 Improves efficiency The JPP session 0 Attendees Facilitator other PM IPP consultant 0 PM 0 Technographer 0 Core project team 0 Customer rep 0 Resource and functional managers 0 Project Champion 0 Process owner 0 Facilities 0 Equipment FOURHOUR LEADERSHIP MEETING THIS WAS A PRODUCTIVE I D LIKE ONE OF 0mm NO PROBLEM E NE DOE5 ANYO REMEMBER WAT NE DECIDEDquot 5 UPS Inc we AGREED TO INCREASE r SOMETHING NO DECREASE SOMETHING quotM NEVER MIND LETS TRY IT AGAIN ON THURSDAY AT 8 AM Deliverables o WBS 0 Activity duration estimates 0 Resource requirements 0 PDM 0 Activity schedule 0 Resource assignments 0 Project notebook 0 Project proposal Project proposal 0 Background 0 Objective 0 Overview of the approach to be taken 0 Detailed SOW 0 Time and cost summary 0 Appendices In the real world Chapters 9 and 10 o Hardest 2 Chapters in the book 0 We ll do this in 4 parts 0 Encourage you to read Chapters all the way through Questions Finalizing the Schedule and Cost Chapter 7 CSSE 372 18Dec2007 Outline 0 Where are we 0 Leveling strategies 0 Responsibility matrix 0 Microlevel planning 0 Qualities of a schedule 0 Tools 0 Activity Resource leveling strategies 0 Utilize available slack o Shifting the project finish date 0 Smoothing 0 Alternatives 0 Further decomposition of tasks 0 Stretching tasks Assigning substitute resources Project name 0 Responsible Responsibility Matrix 0 Contribute Revision Dapa ment Name CotD I M ADDICTED TO THE INTERNET wwwdlberlcom Kuhdams nolrum 1 NO LONGER CARE FER DIRECT HUMAN INTERACTION IT S TOO EHALLGLU AND PREDICTABLE 0 3 gt73 1 2W mu lldmm HEJDIIL bf UFE Inc MAYBE YOU EHOULD TRY SOME OUTDOOR ACTIVITIES Scott Adams ncJDist by UPS 3 5quot Microlevel planning MTWRFSSMTWRFS Duffy Al l a Ernie Fran Work Package Assignment Sheet Asvs gzmpafx Project Name Project No Project Manager Work Package Schedule Number Name E1511 F131 W iii ge n ifs n A DESIGN 030100 040100 ANNA LYST B PROD EVAL 040200 070200 HY ROWLER C1 PLACELOCATEPT1 040200 030401 SY YONARA C2 PLACELOCATEPT2 070300 030401 HY ROWLER D PRODFCAST 070300 030401 SY YONARA E PRODDELETE 030501 060201 HY ROWLER 1quot PROMOREGION 030501 070601 TERRITORY H PRICE 080401 020502 HY ROWLER PLACEDESICN 060501 080302 HY ROWLER l PROMOSALESLEAD 070701 110501 TERRI TORY G PROMOMEDIA 070701 020502 SY YONARA K PROMOSALESRPT 100701 020502 TERRITORY L SYSTEMTEST 020802 051002 ANNA LYST M SYSTEMACCEPT 051002 061002 ANNA LYST Prepared by Date Approved by Dale Sheet 1 of 1 Qualities a schedule must possess 0 Be translatable into action 0 Startend dates 0 Person 0 Task description 0 Have retraceable logic 0 Be visible 0 Be manageable Tools discussion Questions Activity 0 Write the first 17 tasks across the bottom 0 Fill in the top 2 resource boxes if needed 0 Enter dots and circle dotsquot one task at a time 0 Record any issues or assumptions 0 Check your PDM to verify you haven t overloaded your resources Time 15 minutes Project closeout Chapter 11 CSSE 372 24anuary2008 Outline 0 Steps to Closing a project 0 Lessons learned 0 Activity Steps to closing a project Getting client acceptance of deliverables Ensuring that all deliverables are installed Ensuring that the documentation is in place Getting client signoff on the final report Conducting the postimplementation audit 991WN Celebrating the success Lessons learned 0 Problem solved or dealt with 0 Positive experiences Category Category Category Category Cause Cause Cause Cause Cause Cause Cause Cause Cause Cause Cause Cause Cause Effect Category Category Category Category Lessons learned session 0 You need postits o Brainstorm effects 0 Organize effects into categories 0 Brainstorm causes for each effect 0 Organize causes into categories 0 Write up issue Chords Team 2 Flshbone Keith Marcum Bryan Musial Scott Ward Q API designed for 50 What few comments exist 0 Windows 95era 1993 O are header blocks for C O 0 source files Existing documentation is relegated to MSDNs archives 8 0 b 0 Calls to Win32Api can not be debugged 6 quot as you can not 39step in39 to the API o Sequences of cryptic 39SendMessage39 commands require multiple MSDN 9y Vertical Whitespace occurs after every Code hierarchy had to be established through reverse engineeringquot Poor Project Execution Library reverse lockupsl line making code comprehension difficult by project owner 626 Chords Audio features draw on Directx Current uwomng version of the A Sound Libraries that are not Included In Lg source code has build failures 6 the downloadable source code 30 4 o 18 08 A speci c version of the DirectX 53 0 Prolei Owner39s 90mm infOYmaiion 5 0 Sound SDK is required and is 0 IS invalid making requests lor QA 1 difficult to locate 95 00 information impossible 06 90 9 Project AdministratorOwner C is the only person authorized to check code back in Dif cult to Debug Debug Wlndnw Poor Documentation Broken Links Cass Stmcture 1m Debug mm Page Update Information Scal39ered Shared Window Iden ng Current Accounts Return Unexpected Values Inuicam Dosign No Comment Justl calinn Too Mhny Descandams Generic Descriptions Confusing Function Names NonDescriptive Class Names Confusing Class Hierarchy What to include in a lessons learned Title Simple and brief Forward OPTIONAL Background history information Statement of problem Describe the situation Discussion Discussion of the issue References References for the discussion What to do Action plan References Action plan references Activity Conduct 3 lessons learned session for the Big Dig case study Questions Software Estimation An Overview Richard D Stutzke Science Applications International Corporation Introduction Our world increasingly relies on software There is a seemingly insatiable demand for more functionality interfaces that are easier to use faster response and fewer defects Developers must strive to achieve these objectives while simultaneously reducing development costs and cycle time Above all senior management wants software delivered on schedule and within cost a rarity in past software development projects Soft ware process improvement SPI as advocated by the Software Engineering Institute SE1 helps to achieve these objectives Project planning and tracking are identi ed as two key process areas in the SEI s Capability Maturity Model CMM 3 Software cost and schedule estimation supports the planning and tracking of software projects The for mal study of software estimating technology did not begin until the 1960s although Peter Norden did some earlier work on models of research and development 1 Estimation received renewed attention during the 19903 to cope with new ways of building software and to provide more accurate and dependable estimates of costs and schedules This article discusses the problems encountered in software estimation surveys previous work in the eld and describes current work Description of the Problem estimate the e ort personhours and duration calendardays of a project to enable managers to assess important quantities such as product costs return on investment time to market and quality The estimation process is dif cult for several reasons 0 Con icting project goals a Lack of a detailed product description 0 Wide variations in developer productivity 0 Dif culty of modifying existing code and o Emergence of new development processes methods and tools This paper originally appeared in the May 1996 issue of the journal CmssTalk An updated version appeared in the 5th edition of this book This article updates and signi cantly expands the previous version It contains more detail on some of the parametric models and additional information about some new models The entire article has been reformatted to improve readability 221 J AH a t n What is an Estimate As a minimum the estimator must compute the effort cost and duration schedule for the project s process activities identify associated costs such as equipment travel and staff training and state the rationale behind the calculations including the input values used assumptions etc Estimation is closely tied to the details of the product s requirements and design primarily the software architecture the activities of the chosen development process and the resources people tools and facilities provided The requirements architecture and reuse of existing code all a ect the product size The process activities and the project resources affect the productivity Estimators must understand all of these factors in order to produce accurate estimates for project planning ie these factors also affect estimates of product performance and quality It is also highly desirable for the estimator to indicate the con dence in the reported values via ranges or standard deviations The estimator should also try to state the assumptions and risks to highlight any areas of limited understanding relating to the requirements product design or development process Estimation Techniques Estimation techniques use a mixture of analytic models historical data and expert judgment These tech niques differ based on the emphasis they place on each element and the rules they use to combine the three elements The paper that follows this one Software Engineering Economics by Barry Boehm and Sunita Chulani describes six categories of estimation techniques The next section gives a chronological summary of work in the eld during the past four decades with emphasis on analytic models also called parametric models The paper by Boehm and Chulani contains 39 detailed descriptions of several popular software estimation models Their paper also explains the important role that estimation plays in decisions involving limited resources Survey of Past Work From simple beginnings in the 1960s software estimation technology has expanded due to the work of many individuals The 1960s In the 1960s while at RCA Frank Freiman developed the concept of parametric estimating and this lead to the development of the PRICE modelrfor hardware This was the tool It was extended to handle software in the 1970s The 19705 The decade of the 1970s was a very active period During this decade the need to accurately predict the costs and schedules for software development became increasingly important and so began to receive more attention Larger and larger systems were being built and many past projects had been nancial disasters Frederick Brooks while at IBM described many of these problems in his book The Mythical ManMonth 8 His book provides an entertaining but realistic account of the problems as perceived at that time During the 19708 high order languages such as FORTRAN ALGOL JOVIAL and Pascal were com ing into increasingly wider usebut did not support reuse Also programming tools other than compilers may 59WM UWJ m w t f ti quot r39atawrwwmmwwmwmu 39mw r r gg3n m n power and development time proportional to the cube root of the effort PRICES has effort approximately proportional to the size raised 11 power and development time is also approximately proportional to the cube root of the effort The basic equations of these 197 0sera composite models are thus similar even though the models were developed independently These similarities suggest that there may be some common laws of software estimatingquot at least for the case of new software development Because of these similarities these models have comparable accuracies generally predicting effort within 10 to 20 percent of project actuals for some appreciable fraction of the projects analyzed The 19805 During the 1980s work continued to improve and consolidate the best models As personal computers PCs started to come into general use many models were programmed Several rms began selling computerized estimating tools Following the publication of the COCOMO equations in 1981 several tools that imple mented COCOMO appeared during the latter half of the 19803 For proprietary models the tool and the model are one and the same The model exists only as implemented by the tool The DoD introduced the Ada programming language in 1983 American National Standards Institute ANSI and DODSTD1815A1983 to reduce the costs of developing large systems Certain features of Ada signi cantly impact development and maintenance costs and so Barry Boehm and Walker Royce de ned a revised model called Ada COCOMO 19 This model also addressed the fact that systems were being built incrementally in an effort to handle the inevitable changes in requirements Robert C Tausworthe 20 extended the work of Boehm Herd Putnam Walston and Felix and Wolver ton to develop a cost model for NASA s Jet Propulsion Laboratory Tausworthe s model was further extended by Donald Reifer to produce the PCbased SOFTCOSTR model and a companion Ada estimating model called SOFTCOSTAda Both of these models are no longer sold commercially Randall W Jensen 21 extended the work of Putnam by eliminating some of the undesirable behav ior of Putnam s SLIM Putnam s SLIM equation has development effort proportional to size measured in SLOC cubed divided by development time to the fourth power Jensen asserted that development effort is proportional to the square of the size divided by the square of the development time Both Jensen and Putnam apply the constraint that effort divided by the cube of the development time is less than some con stant which is chosen based on product and project parameters Jensen s equations reduce to equations that are close to those of COCOMO s embedded mode but the effect of various cost drivers is handled quite differently Daniel Galorath and coworkers continue to re ne the Jensen model and market it as the Soft ware Estimation Model SEM part of the System Evaluation and Estimation of Resources SEER toolset Jensen has recently proposed a new model that is described in the next section In 1984 Albrecht 22 published a major revision to the FPA method These revisions sharpened the rules for rating the complexity of the software The original version of FPA had a single empirically derived weight for each type of component The new method subdivided each type of component by complexity according to certain rules Different weights are used for low medium and high complexity components This revised method is the basis for the current standard as de ned by the International Function Point Users Group FPA was extended by Capers Jones 23 to include the effect of computationally complex algorithm on development costs His Feature Point Method counts FPA s ve types plus a sixth type called algorithms His method eliminates the classi cation of the elements in terms of three levels of complexity a single weight is used for each element type Various PC based tools implement these FPAbased methods such as Function Point Workbench and Checkpoint from Software Productivity Research and FPXpert and Estimacs from Computer Associates Multiplying by 1 minus the fraction of reuse expected or planned ie 100 percent reuse decreases this count This method combines simpli ed elements similar to Gaffney s method described in the next para graph and complexity ratings of the elements similar to FPA The application point estimation model while considered to be part of the COCOMO 11 model has not yet been calibrated It will no doubt evolve in the future In 1996 John Gaffney 28 reported that using only a subset of the elements of a function point count provides estimates of development effort that are as accurate as those produced using classical function points His analysis showed that the development effort was highly correlated with just the counts of the inputs and outputs Gaffney actually evaluated six linear models and ve nonlinear models Gaffney s simpli ed function point estimation methodquot does not use the three levels of complexity ie low medium high for the elements that are part of the of cial IFPUG FPA method Capers Jones s Feature Points Method as mentioned previously also does not use the three levels of complexity Scott Whitmire has proposed a way to extend EPA to handle scienti c and realtime systems 29 He acknowledges DeMarco s statement 30 that all software has three dimensions data function and control Whitmire asserts that classical FPA addresses only the data dimension of a software program His threedimensional 3D function point method provides a way to quantify characteristics of the other two dimensions The 3D function point index ie the amount of functionality in the software is computed in a way similar to that of classical FPA with the addition of two new element types transformations and transitions The method is not yet rigorously validated David Garmus has also described how to use function point counting in a realtime environment 31 Randall Jensen has extended his original model 21 to explicitly handle the effects of management 32 on project costs and schedule The new model called SAGE not an acronym for a longer term considers factors such as the working environment multiple development sites team experience and the degree of resource dedication The COCOMO 20 model also considers similar factors The SAGE model was rst formulated in 1995 and handles new development A new version that handles software maintenance was released in 1997 The20008 The technology used to build systems continues to evolve rapidly This technology includes hardware plat forms operating systems data formats transmission protocols programming languages methods tools and COTS components The halflife of software engineering knowledge is typically less than 3 years Many project teams are using nontraditional development processes such as Rapid Application Development RAD COTS integration and agile methods to grow software systems These processes will continue to evolve rapidly as we learn Such constant and rapid changes mean that little relevant historical data will be available to help us estimate future software projects and to develop new cost estimation models This may challenge SE1 CMM 13gt criteria relating to estimating planning and tracking that require the use of historical data and assume a stable process In an effort to keep up researchers and model vendors are working to formulate validate and deploy new software estimation models Much of this work is a continuation of work started in the 19908 I cover it here because it is still in progress Allan Albrecht s function points originally developed in the 19703 are being extended to handle new software technologies and methods Organizations such as the International Function Point Users Group IFPUG the Netherlands Software Metrics Users Association NESMA and the Federation of Software Measurement Associations FESMA are working to modernize the rules for function point counting See wwwifpugorg wwwnesmanl and wwwfesmaorg Lee Fischman has also proposed simplifying the 231 Size is also dif cult to de ne for prebuilt components In many cases the developer does not even have the source code so measures such as SLOC are not feasible In addition only the portion of the component s interfaces and functionality that is actually used needs to be understood integrated and tested by the developer The size needs to re ect only this portion for the purpose of estimating the developer s effort During the 1990s Boehm and his collaborators actually began to de ne a family of estimation models to estimate effort and schedule for different types of development processes They have also done some work on a model to estimate software defect densities and reliability As the importance of reliability increases improved versions of such models will be needed The family presently includes the following COCOMO H COCOT S CORADMO COSSEMO COPROMO COQUALMO COnstructive COst MOdel Version II COnstructive COTS model COnstructive Rapid Application Development MOdel COnstructive Staged Schedule amp Effort MOdel COnstructive PROductivity Improvement MOdel COnstructive QUALity Model This family of models continues to evolve In particular the group plans to release new versions of CO COMO II incorporating the latest calibration data every 2 years or so The versions are identi ed by their year of release for example COCOMO 112000 For more information on these models see 25 and the COCOMO II Web site httpsunsetusceduCOCOMOIlsuitehtml All model vendors are overhauling their proprietary models to cope with many of these same challenges One trend is that the vendors are now packaging their estimation models with data collection capabilities This supports integrated planning and tracking It also provides the data needed to calibrate the estimation models to local development processes Many tools provide built in tools to do this This enables organi zations to retain the same basic toolset yet adapt it to their changing development methods and processes Future Challenges Technology and processes alone do not determine how businesses will develop software license their prod ucts etc As the World Wide Web evolves entirely new business models will become possible For example users may not buy software products but instead rent them from service providers Costs would be based on actual usage Legal and security considerations may also affect the business models Such in uences will affect how software is built and sold Estimating the tradeoffs between development operating and maintenance costs will become more important and more dif cult as new technologies and business models emerge Estimators will require more knowledge of nancial practices such as return on investment and discounted value Barry Boehm covers such topics in Part III of his classic book 2 Another factor that estimators must confront is the use of ephemeral teams Projects need experts in multiple application and solution domains in order to build the large complex systems No single person can understand all of these domains and so development teams will be more interdisciplinary Because all of these experts are not needed continuously project teams and possibly entire companies may consist of a core of permanent experts and groups of temporary workers hired on a justintime basis The permanent staff would include managers project control chief engineers and so forth The temporary workers would include analysts designers engineers testers support staff and various domain experts It will be challeng ing to assemble and manage such diverse dynamic teams Advances in telecommunications networking and support software groupware can help such teams function even though they are geographically and 233 Pu mm 9 S D Conte H E Dunsmore and V Y Shen Software Engineering Metrics and Models Benjamin Cummings 1986 10 A Technique for the Measurement of Attitudes Rensis Likert Archives of Psychology Vol 140 June 1932 Two brief discussions on Likert are available at httpwwwoiseutorontoca 1m cleantomabshtml and httpwwwvcueduhaswebpsypsy632measurehtm 11 Robert E Park The Central Equations of the PRICESoftware Cost Model PRICESystems 1988 12 Arlene Minkiewicz and Anthony DeMarco The PRICESoftware Model Lockheed Martin PRICE Systems 1995 13 Allan J Albrecht Measuring Application Development Productivity Proceedings of the Joint SHARE GUIDE and IBM Application Development Symposium October 14 17 1979 14 Allan J Albrecht and John E Gaffney Software Function Source Lines of Code and Development Effort Prediction A Software Science Validation IEEE Transactions on Software Engineering Vol 9 No 2 November 1983 15 Lawrence H Putnam A General Empirical Solution to the Macro Software Sizing and Estimating Problem IEEE Transactions on Software Engineering Vol SE 4 July 1978 pp 345 361 16 Maurice H Halstead Elements of Software Science Elsevier New York 1977 17 Don Coleman Dan Ash Bruce Lowther and Paul Oman Using Metrics to Evaluate Software System Maintainability IEEE Computer Vol 27 No 8 August 1994 pp 44 49 18 Norman E Fenton Software Metrics A Rigorous Approach Chapman and Hall London 1995 A revised edition coauthored with Shari Lawrence P eeger appeared in 1998 19 Barry W Boehm and Walker Royce Ada COCOMO and the Ada Process Model Proceedings of the Third International COCOMO Users Meeting Software Engineering Institute Pittsburgh PA Novem ber 1987 plus re nements presented at the Fourth International COCOMO Users Group Meeting held in November 1988 20 Robert C Tausworthe Deep Space Network Estimation Model Jet Propulsion Report 81 7 1981 21 Randall W Jensen A Comparison of the Jensen and COCOMO Estimation Models Proceedings of the International Society of Parametric Analysts 1984 pp 96 106 22 Allan J Albrecht ADM Productivity Measurement and Estimate Validation IBM Corporate Informa tion Systems IBM Corp Purchase NY May 1984 23 Capers Jones The SPR Feature Point Method Software Productivity Research Inc 1986 24 Charles Symons Software Sizing and Estimating Mark 11 Function Points Function PointAnalysis John Wiley amp Sons New York 1991 ISBN 0471 929859 25 Barry W Boehm Chris Abts A Winsor Brown Sunita Chulani Bradford K Clark Ellis Horowitz Ray Madachy Donald Reifer and Bert Steece Software Cost Estimation with COCOMO II Prentice Hall Upper Saddle River NJ 2000 1 Hz rrlumw ma g Uta


Buy Material

Are you sure you want to buy this material for

25 Karma

Buy Material

BOOM! Enjoy Your Free Notes!

We've added these Notes to your profile, click here to view them now.


You're already Subscribed!

Looks like you've already subscribed to StudySoup, you won't need to purchase another subscription to get this material. To access this material simply click 'View Full Document'

Why people love StudySoup

Steve Martinelli UC Los Angeles

"There's no way I would have passed my Organic Chemistry class this semester without the notes and study guides I got from StudySoup."

Kyle Maynard Purdue

"When you're taking detailed notes and trying to help everyone else out in the class, it really helps you learn and understand the I made $280 on my first study guide!"

Jim McGreen Ohio University

"Knowing I can count on the Elite Notetaker in my class allows me to focus on what the professor is saying instead of just scribbling notes the whole time and falling behind."


"Their 'Elite Notetakers' are making over $1,200/month in sales by creating high quality content that helps their classmates in a time of need."

Become an Elite Notetaker and start selling your notes online!

Refund Policy


All subscriptions to StudySoup are paid in full at the time of subscribing. To change your credit card information or to cancel your subscription, go to "Edit Settings". All credit card information will be available there. If you should decide to cancel your subscription, it will continue to be valid until the next payment period, as all payments for the current period were made in advance. For special circumstances, please email


StudySoup has more than 1 million course-specific study resources to help students study smarter. If you’re having trouble finding what you’re looking for, our customer support team can help you find what you need! Feel free to contact them here:

Recurring Subscriptions: If you have canceled your recurring subscription on the day of renewal and have not downloaded any documents, you may request a refund by submitting an email to

Satisfaction Guarantee: If you’re not satisfied with your subscription, you can contact us for further help. Contact must be made within 3 business days of your subscription purchase and your refund request will be subject for review.

Please Note: Refunds can never be provided more than 30 days after the initial purchase date regardless of your activity on the site.