Question? Leave a message!




Software Project Management

Software Project Management 17
Software Project Management Daniel M. Berry with material from James E. Tomayko 1994 Daniel M. Berry Software Enginering Software Project Management Pg. 1 ©Nature of Software Production SOFTWARE — program system product (PSP) PROJECT — planned MANAGEMENT — make sure that the PSP comes out as planned 1994 Daniel M. Berry Software Enginering Software Project Management Pg. 2 ©Software 1 We are not talking about programs, but about program system products (PSP) We all know all about programs, but what about PSPs Fred Brooks explains the difference and shows the effort involved (multipliers may be bigger if the number of components is large): 1994 Daniel M. Berry Software Enginering Software Project Management Pg. 3 ©Software 2 Program Program x 3 Product x 3 x 9 x 3 Program Program x 3 System System Product 1994 Daniel M. Berry Software Enginering Software Project Management Pg. 4 ©Program: • program is complete by itself • program is ready to run by author for planned inputs on system on which it was developed, and probably under no other circumstances 1994 Daniel M. Berry Software Enginering Software Project Management Pg. 5 ©Program System: • each program is a component in integrated collection (system) • precisely defined interface to which all programs in system must comply • each program must stick to reasonable resources • each program is tested with other programs; number of combinations grows quadratically with each additional program 1994 Daniel M. Berry Software Enginering Software Project Management Pg. 6 ©Program Product: • product can be run, tested, repaired, extended by anyone, not just author • product runs on multiple platforms • product accommodates many sets of data • range and form of input to product must be generalized • product must test for validity of input and provide response to invalid inputs • must be product documentation for maintainers and users 1994 Daniel M. Berry Software Enginering Software Project Management Pg. 7 ©Program System Product: • all attributes of program system and • all attributes of program product 1994 Daniel M. Berry Software Enginering Software Project Management Pg. 8 ©Programs vs. PSPs 1 Perhaps the key problem in SPM is that when we should be thinking about PSPs, we continue to think about programs, and all expectations, • ease vs. difficulties, • time, • costs, • you name it, are off by an order of magnitude. 1994 Daniel M. Berry Software Enginering Software Project Management Pg. 9 ©Programs vs. PSPs 2 We see only the program in the heart of the PSP and forget all the other junk that must be added to make it a PSP 1994 Daniel M. Berry Software Enginering Software Project Management Pg. 10 ©Project The objective of the project to build a PSP is to make sure that all the necessary junk gets planned in. Projects have plans: • Specific work to do • Deliverables • Resources Multiple People Schedule Budget 1994 Daniel M. Berry Software Enginering Software Project Management Pg. 11 ©Management 1 Any project with more than one person must be managed by definition, just to keep the communication going between the folk in the project. Note that the management does not need to be applied externally, the manager can be one of the managed folk 1994 Daniel M. Berry Software Enginering Software Project Management Pg. 12 ©Management 2 The job of management is to make sure that the planned junk does not get left behind in the zeal to release the PSP when only the program in its heart has been written 1994 Daniel M. Berry Software Enginering Software Project Management Pg. 13 ©Management 3 • Control leads to quality. • Deliver what you promise. • Allocate resources properly. • Communicate and facilitate communication. 1994 Daniel M. Berry Software Enginering Software Project Management Pg. 14 ©Truths about Management Boehm says: “Poor management can increase software costs more than any other factor”. “Poor management can decrease software productivity more rapidly than any other factor” “The single most important factor in the success of a (multiperson) software project is the talent of its project manager” 1994 Daniel M. Berry Software Enginering Software Project Management Pg. 15 ©Production of Managers Mark Kellner goes so far as to say: “The software engineering profession has not produced a cadre of capable/competent managers.” Promotion up the technical ladder requires skills different from those needed by a manager. 1994 Daniel M. Berry Software Enginering Software Project Management Pg. 16 ©Basic Equation Profit = Revenues Expenses Usually revenues are fixed, either by contract or by the market. Therefore to maximize, or even to guarantee, profit, it is essential to reduce expenses or costs. Cannot reduce anything unless you know what it is. 1994 Daniel M. Berry Software Enginering Software Project Management Pg. 17 © Required Knowledge Therefore, we gotta know what the costs are. More importantly, we gotta what they will be if we’re using projected costs to determine what the price (i.e., revenues) is. 1994 Daniel M. Berry Software Enginering Software Project Management Pg. 18 ©Multipronged attack Actually, there is a mirror image to reducing costs that has the same net effect, when it is done right. • Reducing costs • Increasing productivity 1994 Daniel M. Berry Software Enginering Software Project Management Pg. 19 ©Reducing Costs To reduce cost, you have to know what you’re spending and where you’re spending it. 1994 Daniel M. Berry Software Enginering Software Project Management Pg. 20 ©Increasing Productivity To increase productivity, you have to eliminate unnecessary work and make the work that’s done more effective. 1994 Daniel M. Berry Software Enginering Software Project Management Pg. 21 ©Recurring Theme 1 Recall the diagram presented earlier of Boehm’s cost drivers, showing how much more important personnel and team capability are than any technical factor. Well, there is another line showing an even more important cost driver for software, namely the size of the code itself, and that’s about 5 times more important than personnel and team capability. 1994 Daniel M. Berry Software Enginering Software Project Management Pg. 22 ©Recurring Theme 2 1.20 Language Experience 1.23 Schedule Constraint 1.23 Database Size 1.32 Turnaround Time 1.34 Virtual Machine Experience 1.49 Virtual Machine Volatility 1.49 Software Tools 1.51 Modern Programming Practices 1.56 Storage Constraint 1.57 Application Experience 1.66 Timing Constraint 1.87 Required Reliability 2.36 Product Complexity Personnel/Team Capability 4.18 Code Size ≈ 20 01234 20 Relative Effect 1994 Daniel M. Berry Software Enginering Software Project Management Pg. 23 © Software Cost Driver AttributeRecurring Theme 3 So a simple way to reduce costs is to write less code Nu • Beg it. • Borrow it. • Buy it. • (No “steal it”) 1994 Daniel M. Berry Software Enginering Software Project Management Pg. 24 ©Outline • Lifecycles • Cost Estimation • Risk Management • Planning General Issues • Process Management • Planning Details • Notations Each major topic will be preceded with its own outline 1994 Daniel M. Berry Software Enginering Software Project Management Pg. 25 ©Lifecycles Outline: • Buildandfix • Waterfall • Spiral • One Sweep of Spiral • Requirements Engineering 1994 Daniel M. Berry Software Enginering Software Project Management Pg. 26 ©Reasons for Considering Topic Lifecycle models are generally considered too constraining and too ideal. However, it is useful to understand what lifecycles were envisioned when documentation standards were developed. Later we will learn how and why to fake the lifecycles to make the documents. 1994 Daniel M. Berry Software Enginering Software Project Management Pg. 27 ©BuildandFix Build first version Modify until client is satisfied Operations mode Retirement All too common 1994 Daniel M. Berry Software Enginering Software Project Management Pg. 28 ©Waterfall 1 Win Royce described what is now called the traditional waterfall lifecycle. Requirements Specifications Design Realization Integration Operation 1994 Daniel M. Berry Software Enginering Software Project Management Pg. 29 ©Waterfall 2 The waterfall model is descriptive, and not too good at that. It is by no means proscriptive; it simply does not work Lowering fever is a good model of getting over an illness, but refrigerating a sick person will not make him or her better. 1994 Daniel M. Berry Software Enginering Software Project Management Pg. 30 ©Spiral Model Barry Boehm introduced the more realistic spiral model. Determine objectives, alternatives, Evaluate alternatives; constraints identify, resolve risks Risk analysis Simulations, Models, Benchmarks Plan next phase Develop, verify next level product The waterfall can be considered one 360° sweep of the spiral. 1994 Daniel M. Berry Software Enginering Software Project Management Pg. 31 ©One Sweep of Spiral But here is the real lifecycle for one sweep. More difficult than thought to be Reqs Client Design Code Specs Ideas More haphazard More systematic 1994 Daniel M. Berry Software Enginering Software Project Management Pg. 32 ©Requirements Engineering 1 It is important to try to straighten the tortuous line from conception to requirements specifications. Recall that the cost to correct an error skyrockets as a function of lifecycle stage. 1994 Daniel M. Berry Software Enginering Software Project Management Pg. 33 ©Requirements Engineering 2 100 50 20 10 5 2 1 Preliminary Detailed Code and Integrate Validate Operation design design debug Phase in which error is detected 1994 Daniel M. Berry Software Enginering Software Project Management Pg. 34 © Relative cost to correct errorRequirements Engineering 3 Meir Lehman identified Etype software. • A system that solves a problem or implements an application in some real world domain. • Once installed, an Etype system becomes inextricably part of the application domain, so that it ends up altering its own requirements. 1994 Daniel M. Berry Software Enginering Software Project Management Pg. 35 ©Requirements Engineering 4 Martin Tsai did experiment to identify lifecycle stages in which requirement errors are found • Used polished 10page requirements for centralized railroad traffic controller. • Ten 4person teams of software engineers looked for errors. • Requirements author believed that teams would find only 1 or 2 errors. 1994 Daniel M. Berry Software Enginering Software Project Management Pg. 36 ©Requirements Engineering 5 • 92 errors, some very serious, were found • Average team found only 35.5 errors, i.e., it missed 56.5 to be found downstream • Many errors found by only one team • Errors of greatest severity found by fewest teams 1994 Daniel M. Berry Software Enginering Software Project Management Pg. 37 ©Requirements Engineering 6 Most errors are introduced during requirements specification. Boehm: At TRW 54 of all errors were detected after coding and unit test; 85 of these errors were allocatable to the requirements and design stages rather than the coding stage, which accounted for only 17 of the errors. 1994 Daniel M. Berry Software Enginering Software Project Management Pg. 38 ©Requirements Engineering 7 The requirements iceberg and various icepicks chipping at it: Client’s View Requirements 1994 Daniel M. Berry Software Enginering Software Project Management Pg. 39 ©Requirements Engineering 8 The problem is the conceptual distance from the client’s ideas to the specifications. Concept Folded in middle to give feeling of true conceptual distances involved Formal Spec. Informal Spec. 1994 Daniel M. Berry Software Enginering Software Project Management Pg. 40 ©Requirements Engineering 9 Requirements engineering has its own lifecycle: Conception Elicitation Analysis Specification Validation 1994 Daniel M. Berry Software Enginering Software Project Management Pg. 41 ©Requirements Engineering 10 The next slide shows the benefits of spending a significant percentage of development costs on studying the requirements. It is a graph from “System Engineering Overview” by Kevin Forsberg and Harold Mooz, 1996. It relates percentage cost overrun to study phase cost as a percentage of development cost in 25 NASA projects. 1994 Daniel M. Berry Software Enginering Software Project Management Pg. 42 ©Requirements Engineering 11 180 160 140 120 100 80 60 40 20 0 0 5 10 15 20 25 Study Phase Cost as a Percent of Development Cost 1994 Daniel M. Berry Software Enginering Software Project Management Pg. 43 © Percentage Cost OverrunRequirements Engineering 12 The study, performed by W. Gruhl at NASA HQ includes such projects as g Hubble Space Telescope g TDRSS g Gamma Ray Obs 1978 g Gamma Ray Obs 1982 g SeaSat g Pioneer Venus g Voyager 1994 Daniel M. Berry Software Enginering Software Project Management Pg. 44 ©Cost Estimation Outline: • What needs to be estimated • Understanding software costs • Estimation models 1994 Daniel M. Berry Software Enginering Software Project Management Pg. 45 ©What Needs to be Estimated • Size • Time • Complexity • Effort • Resources That is, all sorts of costs 1994 Daniel M. Berry Software Enginering Software Project Management Pg. 46 ©Understanding Software Costs What affects software costs • Why estimation so hard for SW • Personnel team capabilities • Individual differences • Team size • Product complexity • Fun vs. duty • Main reason for poor estimates • Accuracy of cost estimation • Twostep cost estimation • Risk of software cost estimation 1994 Daniel M. Berry Software Enginering Software Project Management Pg. 47 ©Why Estimation SO Hard for SW • Often entirely new • Start with incomplete specifications • Moving target • People factors • Difficult to relate size and complexity 1994 Daniel M. Berry Software Enginering Software Project Management Pg. 48 ©Personnel Team Capabilities 1 Effects of personnel and team capability on productivity: • factors that managers cannot affect • factors that managers can affect 1994 Daniel M. Berry Software Enginering Software Project Management Pg. 49 ©Personnel Team Capabilities 2 There is nothing a manager can do to change the talent of the individuals. However, there are things that can be done to bring the talent of the indviduals out. 1994 Daniel M. Berry Software Enginering Software Project Management Pg. 50 ©Personnel Team Capabilities 2 Some things that management can do to help improve personnel productivity: • make a better programming environment • provide education and training • improve the software process 1994 Daniel M. Berry Software Enginering Software Project Management Pg. 51 ©Individual Differences 1 • Individuals can be virtuosos, but there is a limit to what a virtuoso can do. 1994 Daniel M. Berry Software Enginering Software Project Management Pg. 52 ©Individual Differences 2 • An experiment to show that programmers using interactive system are more productive than those using batch system failed because the socalled independent variable of programmer quality dominated; they found a 26 to 1 productivity ratio among experienced programmers. • Other studies have shown 17 to 1 productivity ratio among individual programmers. 1994 Daniel M. Berry Software Enginering Software Project Management Pg. 53 ©Individual Differences 3 Not many human endeavors have this wide of a gap. For example, in the best sprinters are not 17 times faster than the worst. On the other hand, Michael Jordan is around 17 times better than the worst basket shooter and Pat Riley is around 17 times better than the worst coach. 1994 Daniel M. Berry Software Enginering Software Project Management Pg. 54 ©Individual Differences 4 I guess that the key here is that when skill rather than capacity is involved, individual differences are large. 1994 Daniel M. Berry Software Enginering Software Project Management Pg. 55 ©Team Size Smaller teams are generally more effective than larger teams. • There is less communication between members. 5,10 1,0 2,1 3,3 4,6 number of persons, lines of communication • Stars of group can shine through easier. 1994 Daniel M. Berry Software Enginering Software Project Management Pg. 56 ©Product Complexity The more complex the project, the lower the productivity. There are definite harbingers of complex products: • newness for the sake of newness • embedded in a larger system • filled with features 1994 Daniel M. Berry Software Enginering Software Project Management Pg. 57 ©Fun vs. Duty The fun of software development is outweighed by the drudgery. • need for perfection • taking responsibility for quality of work products • debugging • documentation That everyone would prefer to forget the drudgery leads to... 1994 Daniel M. Berry Software Enginering Software Project Management Pg. 58 ©Main Reason for Poor Estimates Estimating fails due to lack of attention to distracting factors. That is, everyone forgets the junk that makes a program system product out of a program 1994 Daniel M. Berry Software Enginering Software Project Management Pg. 59 ©Accuracy of Cost Estimation Basic problem with all estimates 4X X .25X Start Lifecycle Phase End Lousy foresight; perfect hindsight 1994 Daniel M. Berry Software Enginering Software Project Management Pg. 60 ©TwoStep Cost Estimation Must map from requirements to personnel. 1. Internal influences step, e.g., functionpoint analysis that estimates program size from details of required functions 2. External influences step, e.g., COCOMO that maps from estimated size to people needed 1994 Daniel M. Berry Software Enginering Software Project Management Pg. 61 ©Code Size Code size can • be affected by the desired functionality. • affect the desired functionality. • be affected by the implementation. • be affected by external factors, e.g., memory size limitations or coding standards. 1994 Daniel M. Berry Software Enginering Software Project Management Pg. 62 ©Code Size Estimation Models • Sizing by analogy • Wideband Delphi technique • Clark’s model • Function points Note how all of these depend on detailed knowledge of expected internals of the program or of its requirements. 1994 Daniel M. Berry Software Enginering Software Project Management Pg. 63 ©Sizing by Analogy Find another program like the one you’re going to build and base your estimate on its size. 1994 Daniel M. Berry Software Enginering Software Project Management Pg. 64 ©Wideband Delphi Technique 1. Individuals examine the requirements. 2. Discuss the requirements in a group. 3. Individuals estimate anonymously. 4. Compare individual estimates to mean. 5. Discuss results in group. 6. Loop back to 3. 1994 Daniel M. Berry Software Enginering Software Project Management Pg. 65 ©Clark’s Model (L+4M+H) hhhhhhhhhhhh E = for each module 6 M = what you think is about right size for module H = the biggest you think it can ever be L = the smallest you think it can ever be E = final estimate for the module Captures standard bellshaped distribution. 1994 Daniel M. Berry Software Enginering Software Project Management Pg. 66 ©Function Points 1 Function points were invented by Allan Albrecht at IBM in 1979. Function points were originally intended for commercial applications, and as we look at the factors involved, this will be clear. However, the idea of finding key factors can be applied to any application domain; you just have to find a different set of functional factors. 1994 Daniel M. Berry Software Enginering Software Project Management Pg. 67 ©Function Points 2 Objective: to be able to estimate code size relatively easy early in the lifecycle from knowledge of only the requirements. This is all you know when the customer says, “Here’s what I want. How much will it cost” If you over estimate, you lose the job. If you underestimate, you lose the profit 1994 Daniel M. Berry Software Enginering Software Project Management Pg. 68 ©Function Points 3 Function Points (FP) = Sum of Functional Factors × 0.65 + 0.01 × Sum of Weighting Factors 1994 Daniel M. Berry Software Enginering Software Project Management Pg. 69 ©Functional Factors Five Functional Factors (Simple, Average, Complex) Functional Weights for Factor S A C iiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiii Number of user inputs ×346 Number of user outputs ×457 Number of user inquiries ×346 Number of files ×71015 Number of external interfaces ×57 10 1994 Daniel M. Berry Software Enginering Software Project Management Pg. 70 ©Weights of Functional Factors Weights can be adjusted, according to experience. Nowadays, because of libraries, the weights tend to be the same. 1994 Daniel M. Berry Software Enginering Software Project Management Pg. 71 ©Weighting Factors 1 1 Does system require reliable backup and recovery 2 Are data communications required 3 Are there distributed processing functions 4 Is performance critical 1994 Daniel M. Berry Software Enginering Software Project Management Pg. 72 ©Weighting Factors 2 5 Will system run in an existing, heavily used operational environment 6 Does system require online data entry 7 Does the online data entry require the input transaction to be built over multiple screens or operations 1994 Daniel M. Berry Software Enginering Software Project Management Pg. 73 ©Weighting Factors 3 8 Are master files updated online 9 Are input, output, files, or inquiries complex 10 Is the internal processing complex 11 Is the code designed to be reusable 1994 Daniel M. Berry Software Enginering Software Project Management Pg. 74 ©Weighting Factors 4 12 Are conversion and installation included in the design 13 Is system designed for multiple installations in different organizations 14 Is the application designed to facilitate change and ease of use by the users 1994 Daniel M. Berry Software Enginering Software Project Management Pg. 75 ©Alternate Weighting Factors 1 1 Data communications 2 Distributed data processing 3 Performance criteria 4 Heavily utilized hardware 5 High transaction rates 1994 Daniel M. Berry Software Enginering Software Project Management Pg. 76 ©Alternate Weighting Factors 2 6 Online data entry 7 Enduser efficiency 8 Online updating 9 Complex computations 10 Reusability 1994 Daniel M. Berry Software Enginering Software Project Management Pg. 77 ©Alternate Weighting Factors 3 11 Ease of installation 12 Ease of operation 13 Portability 14 Maintainability 1994 Daniel M. Berry Software Enginering Software Project Management Pg. 78 ©Modern Weighting Factors Nowadays, the following are considered: • interfaces with other applications • special security features • direct access by third party software • documentation requirements • training and help subsystems 1994 Daniel M. Berry Software Enginering Software Project Management Pg. 79 ©Modern Formula 1 FP = 0.44 × No. of Input Element Types + 1.67 × No. of Entity Type References + 0.38 × No. of Output Element Types That is count number of types used rather than objects. Presumably, all accesses to objects of the same types will reuse the same operators. 1994 Daniel M. Berry Software Enginering Software Project Management Pg. 80 ©Modern Formula 2 The new formula reflects current modular style of programming. In this style, the intellectual effort is in designing classes not variables. 1994 Daniel M. Berry Software Enginering Software Project Management Pg. 81 ©Key Observations about FPs These measures are based on user’s external view and are technology independent. They can be developed early in the lifecycle, enabling their use for early cost estimation in planning stages. They can be understood and evaluated by nontechnical users 1994 Daniel M. Berry Software Enginering Software Project Management Pg. 82 ©Additional FP Metrics • Productivity = FP ⁄ PM • Quality = Errors ⁄ FP • Cost = Dollars ⁄ FP • Documentation = Pages ⁄ FP 1994 Daniel M. Berry Software Enginering Software Project Management Pg. 83 ©FP vs. DSI Basic Assembler 360 Macro Assembler 213 C 128 COBOL 105 FORTRAN 105 Pascal 80 Ada 72 Basic 64 4GL 25 So now we have the data to plug into, e.g., COCOMO to estimate personnel 1994 Daniel M. Berry Software Enginering Software Project Management Pg. 84 ©Advantages of Function Points • Deeper understanding of complexity than other methods • More than one variable • Can and must look at requirements • Can and must involve user 1994 Daniel M. Berry Software Enginering Software Project Management Pg. 85 ©Disadvantages of Function Points • More complex • Subjective • DPbiased 1994 Daniel M. Berry Software Enginering Software Project Management Pg. 86 ©COCOMO • History • Empiricism • Three levels of detail • Three development environments • Assumptions of COCOMO model • DSI • Personmonth formulae • Time of development formulae • Fulltime software personnel • COCOMO caveat 1994 Daniel M. Berry Software Enginering Software Project Management Pg. 87 ©History Developed by Barry Boehm in 1970s base on his experience as head of software development at TRW. He was in position of having to make estimates, and he got to be good at it. COCOMO is a formalization of his experience in 62+ projects at TRW. Described in Boehm’s 1981 book Software Engineering Economics 1994 Daniel M. Berry Software Enginering Software Project Management Pg. 88 ©Empiricism It is entirely empirical, based on 62+ projects at TRW. Although, the shape of the formulae makes sense, that is, factors that are adversely affected by growth in intermodule communication contribute to quadratic growth in needed personnel. Each place will have to adjust the constants to reflect what is true there. 1994 Daniel M. Berry Software Enginering Software Project Management Pg. 89 ©Three Levels of Detail 1 • Basic • Intermediate • Detailed 1994 Daniel M. Berry Software Enginering Software Project Management Pg. 90 ©Three Levels of Detail 2 As the detail increases, the number of factors considered increases. “Detailed” considered most accurate, but may not be. In other words, by calibrating constants in basic model, might get better results faster 1994 Daniel M. Berry Software Enginering Software Project Management Pg. 91 ©Three Levels of Detail 3 We cover only basic here. There are costestimation tools that implement the model. Use of such tools can help insure company wide input in calibration and companywide consistency in resulting estimates. 1994 Daniel M. Berry Software Enginering Software Project Management Pg. 92 ©Three Development Environments 1. Organic (Informal group structure) 2. Semidetached 3. Embedded (Very formal group hierarchy and process) 1994 Daniel M. Berry Software Enginering Software Project Management Pg. 93 ©Organic Development Mode • Thorough understanding of project objectives • Extensive experience with related systems • Minimal need to meet predefined requirements • Minimal need to conform to external interfaces • Hardware already exists • Minimal need for innovation • Loose deadline 1994 Daniel M. Berry Software Enginering Software Project Management Pg. 94 ©Semidetached Development Mode • Much understanding of project objectives • Much experience with related systems • Much need to meet predefined requirements • Much need to conform to external interfaces • Some concurrently developed new hardware • Some need for innovation • Moderately tight deadline 1994 Daniel M. Berry Software Enginering Software Project Management Pg. 95 ©Embedded Development Mode • Only general understanding of project objectives • Moderate experience with related systems • Must meet predefined requirements • Must conform to external interfaces • Much concurrently developed new hardware • Much need for innovation • Very tight deadline 1994 Daniel M. Berry Software Enginering Software Project Management Pg. 96 ©Assumptions of COCOMO Model • Low volatility of requirements • Good SE practice • Good management 1994 Daniel M. Berry Software Enginering Software Project Management Pg. 97 ©DSI 1 The Concept of DSI is an attempt to capture intellectual effort. Delivered (not thrown out code) Source (that which humans operate on) Instructions (and not comments) However, if test suites are to be delivered, they must be counted too Also use KDSI, thousand DSI 1994 Daniel M. Berry Software Enginering Software Project Management Pg. 98 ©DSI 2 Counting source instructions is hard What do we count • linefeeds • semicolons What do we do about control constructs • if(... ); • if ( ... ) 1994 Daniel M. Berry Software Enginering Software Project Management Pg. 99 ©PersonMonth Formulae 1 1.05 Organic: PM = 2.4×KDSI 1.12 Semidetached: PM = 3.0×KDSI 1.20 Embedded: PM = 3.6×KDSI 1994 Daniel M. Berry Software Enginering Software Project Management Pg. 100 ©PersonMonth Formulae 2 400 200 160 380 120 360 80 340 40 0 10K 20K 30K 40K 50K 60K Product Size (DSI) 1994 Daniel M. Berry Software Enginering Software Project Management Pg. 101 © Estimated Effort (PM)Time of Development Formulae 1 0.38 Organic: TDEV = 2.5×PM 0.35 Semidetached: TDEV = 2.5×PM 0.32 Embedded: TDEV = 2.5×PM This is consistent with people and time not being exchangeable 1994 Daniel M. Berry Software Enginering Software Project Management Pg. 102 ©Time of Development Formulae 2 18 12 6 0 10K 20K 30K 40K 50K 60K Product Size (DSI) 1994 Daniel M. Berry Software Enginering Software Project Management Pg. 103 © Estimated Schedule (Months)FullTime Software Personnel 1 PM hhhhhh FSP = TDEV This assumes uniform personnel level over whole project. Usually want to start off light and hire more as project evolves. Use Rayleigh curve. 1994 Daniel M. Berry Software Enginering Software Project Management Pg. 104 ©FullTime Software Personnel 2 150 Programming 125 Testing 100 75 Design Integration 50 25 Requirements 0 0 102030405060708090 100 Percentage of Development Completed 1994 Daniel M. Berry Software Enginering Software Project Management Pg. 105 © Percent of Average Personnel LevelFullTime Software Personnel 3 2 t hhhhh ( ) 2 t 2p h hhh FSP = PM×( ) ×e 2 p Here p is percentage of development schedule completed at peak. 1994 Daniel M. Berry Software Enginering Software Project Management Pg. 106 © Ada Modifications to Basic Model 1 • Assume smaller teams initially, but allow longer design period. • DSI = carriage returns in specification parts and bodies. 1994 Daniel M. Berry Software Enginering Software Project Management Pg. 107 ©Ada Modifications to Basic Model 2 1.05 PM = 2.4×KDSI 0.32 TDEV = 3×PM PM for PD, DD, CUT, IT = PM × (.23, .29, .22, .26) TDEV for PD, DD, CUT, IT = TDEV × (.39, .25, .15, .21) PD = preliminary design, DD = detailed design, CUT = code unit testing, IT = integration testing 1994 Daniel M. Berry Software Enginering Software Project Management Pg. 108 ©Intermediate Model 1 Sample multipliers for cost drivers: Rating Very Nom Very Extra Cost Drivers Low Low inal High High High iiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiii Product Attributes Required Software Reliability 0.75 0.88 1.00 1.15 1.40 Database Size 0.94 1.00 1.08 1.16 Product Complexity 0.70 0.85 1.00 1.15 1.30 1.65 Personnel Attributes Analyst Capability 1.46 1.19 1.00 0.86 0.71 Applications Experience 1.29 1.13 1.00 0.91 0.82 Programmer Capability 1.42 1.17 1.00 0.86 0.70 Virtual Machine Experience 1.21 1.10 1.00 0.90 Programming Language Experience 1.14 1.07 1.00 0.95 1994 Daniel M. Berry Software Enginering Software Project Management Pg. 109 ©Intermediate Model 2 Sample rating determination: Cost Drivers Situation Rating iiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiii Required Software Reliability Serious financial conse High quences of software fault Database Size 20,000 bytes Low Product Complexity Communications processing Very High Analyst Capability Good senior analyst High Applications Experience Three years Nominal Programmer Capability Good senior programmer High Virtual Machine Experience Six months Low Programming Language Experience Twelve months Nominal 1994 Daniel M. Berry Software Enginering Software Project Management Pg. 110 ©COCOMO Caveat All depends on estimate of code size (DSI), which can be • a result of solving a problem • driven by external factors, e.g., memory bound by system design or standards • directly affected by desired functionality and it • directly affects desired functionality 1994 Daniel M. Berry Software Enginering Software Project Management Pg. 111 ©Advantages of COCOMO • Reasonable • Simple • Clear 1994 Daniel M. Berry Software Enginering Software Project Management Pg. 112 ©Disadvantages of COCOMO • Too believable • Too dependent on one variable • Subjective 1994 Daniel M. Berry Software Enginering Software Project Management Pg. 113 ©Implications of Cost Drivers The biggest cost driver is the number of instructions to develop. Therefore, it pays to try to eliminate the necessity of developing new instructions. • OffTheShelf Software (OTS) • Reuse or adapt existing software • Application generators 1994 Daniel M. Berry Software Enginering Software Project Management Pg. 114 ©Risks of Software Cost Estimation 100 98 98 100 95 99 90 90 98 95 80 75 70 60 50 50 40 30 30 20 10 10 0 0 255075 100 Percentage of Total Project Time Why don’t I believe “It’s 90 done” 1994 Daniel M. Berry Software Enginering Software Project Management Pg. 115 © Estimated Percent CompleteTypical Estimation Results Contractor LOC Dollars iiiiiiiiiiiiiiiiiiiiiiiiiiii A 153K 2.8M B 282K 2.5M C 400K 4.6M D 735K 4.5M E 766K 2.1M 1994 Daniel M. Berry Software Enginering Software Project Management Pg. 116 ©And the Winna is E Actual code size 900K Actual cost 5.8M Nu 1994 Daniel M. Berry Software Enginering Software Project Management Pg. 117 ©Why Estimates Fail • Optimism • Confusion between effort and progress • Gutless estimating • Poor progress monitoring • Requirements Creep • Adding peoplepower 1994 Daniel M. Berry Software Enginering Software Project Management Pg. 118 ©Optimism 1 It comes primarily from forgetting that we are dealing with a program system product rather than a program. It happens to the best of us 1994 Daniel M. Berry Software Enginering Software Project Management Pg. 119 ©Optimism 2 Meir Burstin was a very successful software manager. He could estimate project durations just like that, right off the seat of his pants. His company’s success was testimony to his estimation ability. 1994 Daniel M. Berry Software Enginering Software Project Management Pg. 120 ©Optimism 3 Soon after he sold the company, he went to get a Ph.D. and had to develop a requirements management system for his Ph.D. research. His estimate was suddenly low, by an order of magnitude. 1994 Daniel M. Berry Software Enginering Software Project Management Pg. 121 ©Optimism 4 When asked about this, he said that since he was doing by himself, and he is a good programmer, he forgot to apply all his normal fudge factors. That is, he thought he could do it as a program and forgot that it was a PSP 1994 Daniel M. Berry Software Enginering Software Project Management Pg. 122 ©Optimism 5 Donald Knuth is a good programmer, a programmer’s programmer. I remember hearing a talk he gave in 1980 when he was about .75 year into the T Xand E METAFONT project. He expected to be finished soon, that it would be a 1year project. He wanted to get back to writing his 7volume encyclopedia of programming 1994 Daniel M. Berry Software Enginering Software Project Management Pg. 123 ©Optimism 6 It took 10 years to get to the stage that it was a satisfactory PSP. I’ll bet that he was thinking program, not PSP, when he gave his 1year estimate 1994 Daniel M. Berry Software Enginering Software Project Management Pg. 124 ©Rules of Thumb 1 Here are some rules of thumb that you can use. If you think program when you’re supposed to be thinking PSP. Identify which rule of thumb below applies, and take your “program” estimate and let it be just the coding stage. 1994 Daniel M. Berry Software Enginering Software Project Management Pg. 125 ©Rules of Thumb 2 From that, you can get a rough estimate of the full time needed. Also when you do get a detailed estimate, if it doesn’t jibe with one of these rules of thumb, something is wrong. 1994 Daniel M. Berry Software Enginering Software Project Management Pg. 126 ©Brooks’s Rule of Thumb For distribution of effort in functionally decomposed programs: 1⁄3 planning 1⁄6 coding 1⁄4 unit test and early integration test 1⁄4 integration test 1994 Daniel M. Berry Software Enginering Software Project Management Pg. 127 ©Tomayko’s Rule of Thumb: For distribution of effort for developing modular, data hiding software: 1⁄2 planning 1⁄12 coding 1⁄4 unit test and early integration test 1⁄6 integration test 1994 Daniel M. Berry Software Enginering Software Project Management Pg. 128 ©Adding Peoplepower 1 Sometimes it seems unavoidable. Sometimes it is done to protect against future problems. In either case it’s a disaster “Adding manpower to a late software project makes it later” — F.P. Brooks, Jr. 1994 Daniel M. Berry Software Enginering Software Project Management Pg. 129 ©Adding Peoplepower 2 The problems are bring the new people up to date and adding them to the communication loop. Both catchup and additional necessary communication cost more time than a new person adds. You can add more bricklayers to a wall building project; no catch up and no additional necessary communication 1994 Daniel M. Berry Software Enginering Software Project Management Pg. 130 ©Adding Peoplepower 3 If it is necessary, i.e., it simply requires too much work for the available people to deliver. Then add the people But, then the whole project must be re planned with a later deadline No two ways about it 1994 Daniel M. Berry Software Enginering Software Project Management Pg. 131 ©Cost Increases Causes: • Requirements changes: 85 • Poor estimation: 15 1994 Daniel M. Berry Software Enginering Software Project Management Pg. 132 ©Danger Lurks 1 Quick, look at a typical project’s Pert Chart: require docu design ments ment start code finish test test product plan data test test drivers 1994 Daniel M. Berry Software Enginering Software Project Management Pg. 133 ©Danger Lurks 2 The duration of which development phase is the most dangerous to underestimate 1994 Daniel M. Berry Software Enginering Software Project Management Pg. 134 ©Danger Lurks 3 The answer: Testing You are too close to delivery for recovery 1994 Daniel M. Berry Software Enginering Software Project Management Pg. 135 ©SelfFulfilling Prophecies Different estimates make different projects Tarek AbdelHamid found that estimates tend to influence people’s work habits. Parkinson’s law: Work tends to expand to fill the time available 1994 Daniel M. Berry Software Enginering Software Project Management Pg. 136 ©Validity of Estimation Models Chris Kemerer did an Empirical Evaluation of Software Cost Estimation Models. Used COCOMO, FPs, and other methods on data of finished projects. Data on 15 large COBOL projects were collected to test accuracy of the models ex post facto using actual DSI data and not estimates. 1994 Daniel M. Berry Software Enginering Software Project Management Pg. 137 ©Kemerer’s COCOMO Data A mean over 15 projects: Actual/Estimate PM Error iiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiii Actual 219 Basic Estimate 1226 610 Intermediate Estimate 1280 583 Detailed 1291 607 1994 Daniel M. Berry Software Enginering Software Project Management Pg. 138 ©Kemerer’s FP Data A mean over 14 projects: Actual KLOC: 221 Estimate: 128 Error: 38 low What can be inferred 1994 Daniel M. Berry Software Enginering Software Project Management Pg. 139 ©Validity of Models Kemerer concludes that the models are generally valid, that the shape of the formulae are OK. But all the models need calibration of their multipliers, powers, and constants. So this means that before you can start believing your estimates you have to have been applying them over a number of projects. 1994 Daniel M. Berry Software Enginering Software Project Management Pg. 140 ©What’s a Project Manager to Do • Reject the models. • Use fudge factors in the models. • Adapt and calibrate the models. • Make new models. 1994 Daniel M. Berry Software Enginering Software Project Management Pg. 141 ©Configuration Management (CM) • Role of CM • Functions of CM • Commitment is necessary • Typical configured items • CM library functions • Variations vs. revision • Types of changes • Implementing CM 1994 Daniel M. Berry Software Enginering Software Project Management Pg. 142 ©Role of CM Management Disciplines Controlling Development Disciplines Disciplines Product Software Specification Quality Integrity Design Assurance Software Code Configuration Test Management Independent Verification and Validation 1994 Daniel M. Berry Software Enginering Software Project Management Pg. 143 ©Functions of CM • Maintain integrity of configured items • Evaluate and control changes • Make the product visible 1994 Daniel M. Berry Software Enginering Software Project Management Pg. 144 ©Commitment is Necessary No matter how good are the CM tools, it is always possible to bypass them, rendering them useless. Therefore: Commitment to configuration management by the entire organization is the key to success of configuration management. 1994 Daniel M. Berry Software Enginering Software Project Management Pg. 145 ©Typical Configured Items 1 • Requirements • Specifications • Design Documents • Source Code • Object Code • Load Modules • Tools 1994 Daniel M. Berry Software Enginering Software Project Management Pg. 146 ©Typical Configured Items 2 • System Description • Test Plans • Test Suites • User Manuals • Maintenance Manuals • Interface Control Documents • Memory Maps In other words, all deliverables 1994 Daniel M. Berry Software Enginering Software Project Management Pg. 147 ©CM Library Functions • Software Part Naming • Configured Item Maintenance/Archiving • Version Control • Revision Control • Preparation for Product Release 1994 Daniel M. Berry Software Enginering Software Project Management Pg. 148 ©Variations vs. Revision Variations can coexist, e.g., different versions of same program for two different CPUs or OSs A new revision replaces an older one. 1994 Daniel M. Berry Software Enginering Software Project Management Pg. 149 ©Types of Changes 1 • Disrepancies Requirements Errors Development Errors Violations of Standards • Requested Changes Unimplementable Requirements Enhancements 1994 Daniel M. Berry Software Enginering Software Project Management Pg. 150 ©Types of Changes 2 • Disrepancies — absolutely critical, cannot go on without fixing • Requested Changes — more voluntary, can go on without fixing Requested changes tend to be more difficult than fixing disrepancies and tend to have major impacts on other features if carried out. Disrepancies have major impacts if they are not fixed. 1994 Daniel M. Berry Software Enginering Software Project Management Pg. 151 ©Implementing CM • Fundamental principles • CCB characteristics • Hierarchies of CCBs • Evaluating changes • Disrepancy report (DR) evaluation • Change request (CR) evaluation • Simultaneous update problem • Variations revisions tree • Tools for version control • Tools for system building • Trends of reporting • Standards for CM plans 1994 Daniel M. Berry Software Enginering Software Project Management Pg. 152 ©Fundamental Principles Fundamental principles to guide configuration control boards (CCBs): • Principle of authority • Principle of solitary responsibility • Principle of specificity (assigning the DR or CR to the right CCB) As Jim Tomayko says, the CCB has to have teeth (grrr) or it will not work 1994 Daniel M. Berry Software Enginering Software Project Management Pg. 153 ©CCB Characteristics Factors determining CCB characteristics: • Hierarchies • Scope • Composition 1994 Daniel M. Berry Software Enginering Software Project Management Pg. 154 ©Hierarchies of CCBs Project CCB Subsystem Subsystem Subsystem A CCB B CCB C CCB Subsystem C Subsystem C Hardware CCB Software CCB Inherited Original Software CCB Software CCB 1994 Daniel M. Berry Software Enginering Software Project Management Pg. 155 ©Evaluating Changes 1 Key factors in evaluating proposed changes: • Size • Complexity • Date needed • CPU and memory impact • Cost • Test requirements 1994 Daniel M. Berry Software Enginering Software Project Management Pg. 156 ©Evaluating Changes 2 • Criticality of area involved • Politics (customer/marketing desires) • Approved changes already in progress • Resources (skills/hardware/system) • Impact and current and future work • Is there an alternative 1994 Daniel M. Berry Software Enginering Software Project Management Pg. 157 ©Disrepancy Report (DR) Evaluation DR submitted DR logged YN CCB waives DR Waiver document Development group makes change Configured items updated DR closure audited and logged 1994 Daniel M. Berry Software Enginering Software Project Management Pg. 158 ©Change Request (CR) Evaluation CR submitted CR logged Y CCB approves CR Development group makes change Configured items updated CR closure audited and logged 1994 Daniel M. Berry Software Enginering Software Project Management Pg. 159 ©Simultaneous Update Problem Source 09:00 16.7.94 09:15 Coder A 09:20 Coder B 09:27 09:35 Source 10:00 16.7.94 1994 Daniel M. Berry Software Enginering Software Project Management Pg. 160 ©Variations Revisions Tree Variation 1.0 Original Release 1.1 Upgrade 1.2 Upgrade Variation for another New Release 2.0 2.0’ platform Upgrade variation for 2.1" still another platform 1994 Daniel M. Berry Software Enginering Software Project Management Pg. 161 © RevisionTools for Version Control Keeping track of versions and revisions tree • SCCS • RCS • Domain 1994 Daniel M. Berry Software Enginering Software Project Management Pg. 162 ©Tools for System Building Describe the system and let the tool build it according to description. Description shows module dependencies: if A includes B then recompilation of B forces recompilation of A • Shell scripts/batch files • Make • Domain 1994 Daniel M. Berry Software Enginering Software Project Management Pg. 163 ©Trends of Reporting DR CR Time into project 1994 Daniel M. Berry Software Enginering Software Project Management Pg. 164 © Number of reportsStandards for CM Plans • IEEE (ANSI/IEEE 8281983) • MILSTD483A (Air Force) • DoDSTD2167 1994 Daniel M. Berry Software Enginering Software Project Management Pg. 165 ©Legal Issues • Intellectual Property Protection • Liability and Warranty Note that in all the following, laws exist, agencies exist to administer various protections, and courts have final say in disputes over whether protections are legitimate in any case. 1994 Daniel M. Berry Software Enginering Software Project Management Pg. 166 ©Intellectual Property What is intellectual property Why is it important Pirating costs money and future advancement Three main ways to protect intellectual property: • Patent • Copyright • Trade Secret 1994 Daniel M. Berry Software Enginering Software Project Management Pg. 167 ©Patent 1 Exclusive right to manufacture and sell product meeting description of patent for fixed number of years (about 50). Get it by applying to national patent office and showing that your invention meets requirements and you were first to think of it. Must disclose the full details of the invention, but this is what you get the exclusive right to produce and sell. 1994 Daniel M. Berry Software Enginering Software Project Management Pg. 168 ©Patent 2 Requirements for patentability: • utility • novelty • nonobviousness 1994 Daniel M. Berry Software Enginering Software Project Management Pg. 169 ©Patent 3 Excluded from patents: • business systems • printed matter • mental steps • algorithms 1994 Daniel M. Berry Software Enginering Software Project Management Pg. 170 ©Patent 4 But Gottschalk vs. Benson 1972 granted patent to an industrial process that included a computer program to do process control that is beyond human and mechanical capabilities. So now there is a big flurry to patent programs. 1994 Daniel M. Berry Software Enginering Software Project Management Pg. 171 ©Patent 5 Definition of algorithm: • finite • definite • input • output • effective 1994 Daniel M. Berry Software Enginering Software Project Management Pg. 172 ©Patent 6 Routines that are part of programmer’s normal bag of tricks are being patented. Patents can be challenged in courts and that is the only defense against an improperly granted patent. 1994 Daniel M. Berry Software Enginering Software Project Management Pg. 173 ©Copyright 1 Copyright is the exclusive right to publish something written or performable for a fixed number of years. Protection is on expression and not idea, but you cannot copyright something for which there is only one expression, e.g., a formula. Protection extends to derived works, e.g., obtained by translation. 1994 Daniel M. Berry Software Enginering Software Project Management Pg. 174 ©Copyright 3 Recently copyright has been extended to software in any form, source or object. The copy needed to run and a back up copy are permitted when you license software; copyright cannot prevent someone from using object for its intended purpose or for personal use. 1994 Daniel M. Berry Software Enginering Software Project Management Pg. 175 ©Copyright 3 Licensing vs. buying software. Shrinkwrap licensing. License usually prohibits reverse engineering which is allowed by copyright law. Big issue in courts now: is output generated by programs copyrightable, e.g., look and feel 1994 Daniel M. Berry Software Enginering Software Project Management Pg. 176 ©Trade Secret 1 Problem with both patent and copyright: you have to disclose secrets. Can go trade secret route. Laws exist to protect secrets obtained unfairly or fraudulently if you take active steps to protect them. 1994 Daniel M. Berry Software Enginering Software Project Management Pg. 177 ©Trade Secret 2 Active steps: • Security at plant • Nondisclosure agreements for employees • Nondisclosure agreements with potential customers • Licensing agreements that specify no reverse engineering and nondisclosure of secrets discovered while using 1994 Daniel M. Berry Software Enginering Software Project Management Pg. 178 ©Trade Secret 3 Caveat: You lose the protection of the law if the usurper of the secret can show that you have not been diligent in protecting the secret or have given it out without limits. 1994 Daniel M. Berry Software Enginering Software Project Management Pg. 179 ©Liability and Warranty 1 Liability: You are responsible for the effects of your actions and products and can be made to pay for damages that result, and sometimes punitive damages if it can be shown that you were willfully negligent Warranty: Claim, backed by right to return a product at no cost to consumer, of capability, suitability, or fitness of the product for its stated or intended purpose. 1994 Daniel M. Berry Software Enginering Software Project Management Pg. 180 ©Liability and Warranty 2 Protection from liability: • Limited warranty • Disclaimers • Limit of remedy 1994 Daniel M. Berry Software Enginering Software Project Management Pg. 181 ©Liability and Warranty 3 Definition of fraud: • Misrepresentation of a capability • Using the user as a beta site • Misrepresentation of suitability or fitness • Misrepresentation of time or management or money savings 1994 Daniel M. Berry Software Enginering Software Project Management Pg. 182 ©Liability and Warranty 4 • Express warranty • Implied warranty 1994 Daniel M. Berry Software Enginering Software Project Management Pg. 183 ©Liability and Warranty 5 Concept of unconscionability 1994 Daniel M. Berry Software Enginering Software Project Management Pg. 184 ©Liability and Warranty 6 Differentiate between • goods • services 1994 Daniel M. Berry Software Enginering Software Project Management Pg. 185 ©Liability and Warranty 7 • Professional liability • Product liability 1994 Daniel M. Berry Software Enginering Software Project Management Pg. 186 ©Liability and Warranty 8 Warranty protection for computer systems: • hardware • offtheshelf software • custom software 1994 Daniel M. Berry Software Enginering Software Project Management Pg. 187 ©