University of Southern California Center for Software Engineering C S E USC Using COCOMO for Software Decisions - from COCOMO II Book, Section 2.6 Barry Boehm CS 510, Fall 2015

University of Southern California Center for Software Engineering C S E USC 2 Outline COCOMO II Objective: Decision Support Example Company: UST, Inc. Auto Parts Frequent Software Decisions –Investment; Business Case Analysis –Setting Project Budgets and Schedules –Performing Tradeoff Analysis –Cost Risk Management –Development vs. Reuse –Legacy Software Phaseout –Software Process Improvement Software Organizational Decisions Conclusions

University of Southern California Center for Software Engineering C S E USC 3 UST, Inc. Auto Parts Company Large manufacturing company –200-person software organization Considering development of manufacturing control system (MCS) –100 KSLOC; nominal driver ratings; $8K/PM Scaling exponent E= ( )=1.10 Estimated effort and cost Effort=2.94*100^1.10 = 466 PM Cost = 466 PM * $8K/PM = $3.728M

University of Southern California Center for Software Engineering C S E USC 4 UST, Inc. Auto Parts Company (Cont.) Plus Inception (6%) and Transition (12%) costs –Acquisition Cost = $3.728*1.18 = $4.4M Annual Maintenance Cost Annual Software Change = 100*(0.20) = 20 KSLOC Cost = 2.94*(20)^1.10*$8K=$635K

University of Southern California Center for Software Engineering C S E USC 5 MCS Business Case Analysis MCS estimate to reduce manufacturing inventory 20% –Enables more just-in-time arrival of suppliers components Current Manufacturing inventory valued at $80M Inventory carrying costs average around 25% –Inventory control, property taxes, capital costs, etc. MCS savings in reduced inventory carrying costs = ($80)*(0.25)*(0.2)=$4M/Year MCS savings subtracts software maintenance cost =$4M-0.635M=$3.365M 5-year-ROI = (5 * $3.365M - $4.4M) / $4.4M = 2.8 –Well worth the investment

University of Southern California Center for Software Engineering C S E USC 6 Setting Project Budgets and Schedules Schedule TDEV=3.67*(PM)^[ *(E-0.91)] = 3.67*(466)^0.318 = 26 month Development phase schedule and effort –Effort=0.76*(466)=354 PM; Schedule=0.625*26=16.25 Month; –Staff Level = 354/16.25=28.8 people

University of Southern California Center for Software Engineering C S E USC 7 Performing Tradeoff Analysis MCS Life-cycle Costs vs. Reliability Level RELY RatingVery Low LowNominalHighVery High Dev. Effort Mult Dev. Cost ($K) Maint. Effort Mult Maint. Cost (*2 for Nominal: 20%/year * 10 years) 11,88010,1208,8008,6249,680 Life-cycle Cost15,48814,16813,20013,46415,224

University of Southern California Center for Software Engineering C S E USC 8 Value-Based Tradeoff Analysis Cost of Downtime = $38K*(Downtime) RELY RatingVery Low LowNominalHighVery High Mean Time to Failure (hr) ,000300,000 Mean Time to Repair (hr) Avail= MTBF/(MTBF+MTTR) Downtime Cost=$38K*Downtime $1660M$330M$10M$0.33M$0.01M SW Life-cycle Cost $15.5M$14.2M$13.2M$13.5M$15.2M Ownership Cost $1675.5M$344.2M$23.2M$13.8M$15.2M

University of Southern California Center for Software Engineering C S E USC 9 Outline COCOMO II Objective: Decision Support Example Company: UST, Inc. Auto Parts Frequent Software Decisions –Investment; Business Case Analysis –Setting Project Budgets and Schedules –Performing Tradeoff Analysis –Cost Risk Management –Development vs. Reuse –Legacy Software Phaseout –Software Process Improvement Software Organizational Decisions Conclusions

University of Southern California Center for Software Engineering C S E USC 10 Cost Risk Management Risk reserve for requirement volatility –Estimate as high as 15% –Resulting cost = 2.94*(100+15)^1.10*($8k)=$5130k –Risk reserve = $5130k – 4400k = $730k Risk reserve for less experienced personnel –Average applications, Platform experience ½-level lower –Resulting cost = $4400k*(1.05)*(1.045)=$4828k –Risk reserve = $428k

University of Southern California Center for Software Engineering C S E USC 11 Development vs. Reuse Possibility of reusing a 40 KSLOC component Reuse parameters not a strong match –% design modified DM=40 –% code modified CM=50 –% integration redone IM=100 –Understanding penalty SU=50 –SW unfamiliarity UMFM=1.0 –Adaptation of assessment AA =5% Equivalent new lines of code = 40k*[(0.4*40+0.3*50+0.3*100)/100+(5+50*1.0)/100] = 40k * ( ) = 46.4KSLOC Not a good decision to reuse

University of Southern California Center for Software Engineering C S E USC 12 Legacy Software Phaseout Candidate: Corporate property accounting system –50K COBOL program; 20% annual change (10K) –SU = 50: poorly structured, documented –UNFM = 0.7: few people familiar with code Equivalent annual maintenance size = 10KSLOC * [1 + (50*0.7)/100] = 13.5 KSLOC/year 3 years: 40.5K SLOC Replacement could use MCS GUI, DBMS –Only 20 KSLOC of new software needed; 20% annual change (4KSLOC) –SU = 25: better structured, documented –UNFM = 0.4: New developers familiar with the code Equivalent annual maintenance size = 4KSLOC * [1+ (25*0.4)/100] = 4.4 KSLOC/year 3 years + development = 3* = 33.2 KSLOC –Better to phase out and replace legacy SW

University of Southern California Center for Software Engineering C S E USC 13 Software Process Improvement UST currently at Process maturity Level 2 –Planning & control, config. Management, quality assurance Cost to achieve level 3 (process group, training, product engr.) –Process group: (2yr)*(4 persons)*($96K/yr) = $768K –Training: (200 persons)*(3weeks)*($96K/yr) = $1108K –Contingency = $124K; Total = = $2000K Benefit: scale exponent reduced by =.0156, to 1.10 – = –From 100^1.10 = to 100^ = 147.5, or 7% less effort –Annual savings = (200 persons)*(96K/yr)(.07)=$1344K 5 year ROI = [5*$1344K-$2000K]/$2000K = 2.36 –Again, well worth the investment

University of Southern California Center for Software Engineering C S E USC 14 Outline COCOMO II Objective: Decision Support Example Company: UST, Inc. Auto Parts Frequent Software Decisions –Investment; Business Case Analysis –Setting Project Budgets and Schedules –Performing Tradeoff Analysis –Cost Risk Management –Development vs. Reuse –Legacy Software Phaseout –Software Process Improvement Software Organizational Decisions Conclusions

University of Southern California Center for Software Engineering C S E USC 15 COCOMO II Experience Factory: I Ok? Rescope COCOMO 2.0 Corporate parameters: tools, processes, reuse System objectives: fcn’y, perf., quality No Yes Cost, Sched, Risks

University of Southern California Center for Software Engineering C S E USC 16 COCOMO II Experience Factory: II Ok? Rescope COCOMO 2.0 Corporate parameters: tools, processes, reuse System objectives: fcn’y, perf., quality Execute project to next Milestone Ok? Done? End Revise Milestones, Plans, Resources No Revised Expectations M/S Results Yes Milestone expectations No Yes Cost, Sched, Risks No Milestone plans, resources

University of Southern California Center for Software Engineering C S E USC 17 COCOMO II Experience Factory: III Ok? Rescope COCOMO 2.0 Recalibrate COCOMO 2.0 Corporate parameters: tools, processes, reuse System objectives: fcn’y, perf., quality Execute project to next Milestone Ok? Done? End Revise Milestones, Plans, Resources Accumulate COCOMO 2.0 calibration data No Revised Expectations M/S Results Yes Milestone expectations No Yes Cost, Sched, Risks No Milestone plans, resources

University of Southern California Center for Software Engineering C S E USC 18 COCOMO II Experience Factory: IV Ok? Rescope COCOMO 2.0 Recalibrate COCOMO 2.0 Corporate parameters: tools, processes, reuse System objectives: fcn’y, perf., quality Execute project to next Milestone Ok? Done? End Revise Milestones, Plans, Resources Evaluate Corporate SW Improvement Strategies Accumulate COCOMO 2.0 calibration data No Revised Expectations M/S Results Yes Milestone expectations Improved Corporate Parameters No Yes Cost, Sched, Risks Cost, Sched, Quality drivers No Milestone plans, resources

University of Southern California Center for Software Engineering C S E USC 19 Conclusions COCOMO II is useful in many decision situations –Supports objective discussion and negotiation Most analyses can be done with hand calculator –Simpler, easier to explain Usage builds shared understanding and trust

University of Southern California Center for Software Engineering C S E USC CS 510 Homework 3 Preparation Due Wednesday, September 16 Become familiar with EP-2: Chapter 2 of the COCOMO II cost model book. Use Table 2.50 for the COCOMO II cost estimation parameters. Become familiar with Sections 5.4, 6.6, and 7.6 of the ICSM book. These describe the Medical First Responder System (MedFRS) used as an example project using the ICSM. 20

University of Southern California Center for Software Engineering C S E USC CS 510 Homework 3 Assignment 1 The total software portion of the $2million budget for the initial operational capability of the MedFRS system, excluding the deferred Electronic Health Record (EHR) system, is $500K. To provide evidence of the feasibility of the $500K budget, Table 7-3 proposes a prototype of the new integrated patient- monitoring systems and 4G communications on a single first-responder vehicle and one level 1 trauma center. 3.1 (15 points). Perform a COCOMO II cost and schedule estimate for developing the prototype, using the following additional parameters: a prototype size estimate of 5 KSLOC and an average developer cost of $6K per person-month. The COCOMO II parameter ratings are all Nominal (round off the all-Nominal exponent to be 1.10) except for: RELY: Low, since the prototype will not be operational. CPLX: High; some complex cross-device and external interfaces ACAP: High; prototype needs top talent PCAP: High; prototype needs top talent APEX: High; prototypers familiar with medical field PLEX: Low; prototypers unfamiliar with new devices 21

University of Southern California Center for Software Engineering C S E USC CS 510 Homework 3 Assignment (15 points). Assume that the prototype has been successful and has not only provided evidence of feasibility of the approach, but also has determined the likely size of the full development to be 22 KSLOC, and provided evidence for stronger ratings for the system’s complexity CPLX (now Nominal due to experience with the prototype) and the team’s added platform experience PLEX (now High). For the full system, perform a COCOMO II cost and schedule estimate, assuming that the average developer cost is still $6K per person-month, and the COCOMO II parameter ratings are all Nominal except for: RELY: Very High, since the system needs to be safety-critical. ACAP: High; system needs top talent PCAP: High; system needs top talent APEX: High; developers familiar with medical field PLEX: High; developers now familiar with new devices Does the total cost of prototype and development fit within the $500K budget? 22