An employee owned company Investigating the Default Behavior of Requirements Evolution in COCOMO II Dan Strickland Dynetics, Inc.

Slides:



Advertisements
Similar presentations
COST ESTIMATION TECHNIQUES AND COCOMO. Cost Estimation Techniques 1-)Algorithmic cost modelling 2-)Expert judgement 3-)Estimation by analogy 4)-Parkinsons.
Advertisements

Estimation using COCOMO More Science, Less Art. COCOMO History COCOMO History Constructive Cost Model Dr. Barry Boehm TRW in 1970s COCOMO
Software Cost Estimation Main issues:  What factors determine cost/effort?  How to relate effort to development time?
Project Quality Management Sections of this presentation were adapted from A Guide to the Project Management Body of Knowledge 4 th Edition, Project Management.
COCOMO II Calibration Brad Clark Software Metrics Inc. Don Reifer Reifer Consultants Inc. 22nd International Forum on COCOMO and Systems / Software Cost.
Smi COCOMO II Calibration Status COCOMO Forum October 2004.
Ch8: Management of Software Engineering. 1 Management of software engineering  Traditional engineering practice is to define a project around the product.
Measuring process attributes. Good Estimates Predictions are needed for software development decision-making (figure 12.1) A prediction is useful only.
CSC 395 – Software Engineering
An employee-owned company Extensions of Auto-Generated Code and NOSTROMO Methodologies (U) Pam McDonaldSandra GilesDan Strickland THAAD Project OfficeTHAAD.
Costar & SystemStar Estimation Tools Dan Ligett Softstar Systems (603)
©2011 Rolls-Royce plc The information in this document is the property of Rolls-Royce plc and may not be copied or communicated to a third party, or used.
Measuring Dollar Savings from Software Process Improvement with COCOMO II Betsy Clark Software Metrics Inc. October 25, 2001 Acknowledgment: This presentation.
UNCLASSIFIED Schopenhauer's Proof For Software: Pessimistic Bias In the NOSTROMO Tool (U) Dan Strickland Dynetics Program Software Support
University of Southern California Center for Systems and Software Engineering © 2009, USC-CSSE 1 An Analysis of Changes in Productivity and COCOMO Cost.
MODULE 12 RANDOM VIBRATION.
Chapter 23 – Project planning Part 2. Estimation techniques  Organizations need to make software effort and cost estimates. There are two types of technique.
1 Cost Estimation CIS 375 Bruce R. Maxim UM-Dearborn.
Information System Economics Software Project Cost Estimation.
Data Collection & Processing Hand Grip Strength P textbook.
1 RELATIONSHIP-OBJECTIVE ANALYSIS Getting Full Value From Earned Value With a Value-Added Way of Looking at Performance Measurement Presented at the 14th.
1 ECE 453 – CS 447 – SE 465 Software Testing & Quality Assurance Lecture 22 Instructor Paulo Alencar.
COCOMO Models Ognian Kabranov SEG3300 A&B W2004 R.L. Probert.
This document is proprietary to Project Consulting Group, Inc. and contains confidential information which is solely the property of Project Consulting.
Estimation Why estimate? What to estimate? When to estimate?
Dr. M. Shamim HossainSWE 211 Effort, Duration and Cost Lec 3 1.
Project Management Estimation. LOC and FP Estimation –Lines of code and function points were described as basic data from which productivity metrics can.
A Brief Introduction to COCOMO Hossein Saiedian EECS810: Software Engineering.
A General Discussion on Functional (Black-box) Testing What are some of the concerns of testers ? –Have we got enough time to test (effort & schedule)?
Copyright © 2010, 2007, 2004 Pearson Education, Inc. Chapter 6 Normal Probability Distributions 6-1 Review and Preview 6-2 The Standard Normal.
Selecting and Recruiting Subjects One Independent Variable: Two Group Designs Two Independent Groups Two Matched Groups Multiple Groups.
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.
Cost Estimation What is estimated? –resources (humans, components, tools) –cost (person-months) –schedule (months) Why? –Personnel allocation –Contract.
Project Estimation Model By Deepika Chaudhary. Factors for estimation Initial estimates may have to be made on the basis of a high level user requirements.
Quality Software Project Management Software Size and Reuse Estimating.
Stats/Methods I JEOPARDY. Jeopardy Validity Research Strategies Frequency Distributions Descriptive Stats Grab Bag $100 $200$200 $300 $500 $400 $300 $400.
©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 26 Slide 1 Software cost estimation 2.
SFWR ENG 3KO4 Slide 1 Management of Software Engineering Chapter 8: Fundamentals of Software Engineering C. Ghezzi, M. Jazayeri, D. Mandrioli.
Software Project Estimation IMRAN ASHRAF
Cost9a 1 Software Estimating Technology: A Survey Richard Stutzke Crosstalk, May96 text pp
Copyright , Dennis J. Frailey CSE7315 – Software Project Management CSE7315 M18 - Version 9.01 SMU CSE 7315 Planning and Managing a Software Project.
University of Southern California Center for Systems and Software Engineering © 2010, USC-CSSE 1 Trends in Productivity and COCOMO Cost Drivers over the.
Estimation using COCOMO
Function Points Synthetic measure of program size used to estimate size early in the project Easier (than lines of code) to calculate from requirements.
Estimating “Size” of Software There are many ways to estimate the volume or size of software. ( understanding requirements is key to this activity ) –We.
Effort Estimation In WBS,one can estimate effort (micro-level) but needed to know: –Size of the deliverable –Productivity of resource in producing that.
Chapter 6: Analyzing and Interpreting Quantitative Data
UNCLASSIFIED Approved for Public Release 07-MDA-2965 (26 OCT 07) Load Bearing Walls: Early Sizing Estimation In The NOSTROMO Tool (U) Dan Strickland Dynetics.
CSE SW Project Management / Module 15 - Introduction to Effort Estimation Copyright © , Dennis J. Frailey, All Rights Reserved CSE7315M15.
The COCOMO model An empirical model based on project experience. Well-documented, ‘independent’ model which is not tied to a specific software vendor.
Rating Very Very Extra Cost Drivers Low Low Nominal High High High Product Attributes Required software reliability Database size.
Copyright , Dennis J. Frailey CSE7315 – Software Project Management CSE7315 M15 - Version 9.01 SMU CSE 7315 Planning and Managing a Software Project.
Measures of Central Tendency (MCT) 1. Describe how MCT describe data 2. Explain mean, median & mode 3. Explain sample means 4. Explain “deviations around.
F5 Performance Management. 2 Section C: Budgeting Designed to give you knowledge and application of: C1. Objectives C2. Budgetary systems C3. Types of.
NURS 306, Nursing Research Lisa Broughton, MSN, RN, CCRN RESEARCH STATISTICS.
Chapter 5: Software effort estimation
بشرا رجائی برآورد هزینه نرم افزار.
(8) Potential required for planning with management Top-Down Estimating Method: Top-down estimating method is also called Macro Model. Using it, estimation.
COCOMO Software Cost Estimating Model Lab 4 Demonstrator : Bandar Al Khalil.
Software Estimating Technology: A Survey
Constructive Cost Model
COCOMO Model Basic.
Chapter 5: Software effort estimation
More on Estimation In general, effort estimation is based on several parameters and the model ( E= a + b*S**c ): Personnel Environment Quality Size or.
COCOMO Models.
Project Quality Management
COCOMO 2 COCOMO 81 was developed with the assumption that a waterfall process would be used and that all software would be developed from scratch. Since.
Software Cost Estimation
COnstructive COst MOdel
COCOMO MODEL.
Presentation transcript:

an employee owned company Investigating the Default Behavior of Requirements Evolution in COCOMO II Dan Strickland Dynetics, Inc.

an employee owned company Overview Background of Requirements Evolution and Volatility in COCOMO II Using Other Popular Estimating Models’ Approaches Requirements Evolution Using the Rosetta Stone Requirements Evolution Using REVIC II Using Outside Formulas for Guidance Future Work and Conclusions

an employee owned company Background Estimators have a difficult time explaining the COCOMO II factor for Requirements Evolution and Volatility (REVL) to customers and even other estimators The simple questions tend to be the most difficult to answer: –“What’s a good value for Requirements Evolution?” –“Why can’t we just use the industry standard here?” –“Just use your best judgement, whatever would be typical for this program.” Estimators need some guidance as to how REVL behaves normally and how to adjust the parameter for best results Estimators have a difficult time explaining the COCOMO II factor for Requirements Evolution and Volatility (REVL) to customers and even other estimators The simple questions tend to be the most difficult to answer: –“What’s a good value for Requirements Evolution?” –“Why can’t we just use the industry standard here?” –“Just use your best judgement, whatever would be typical for this program.” Estimators need some guidance as to how REVL behaves normally and how to adjust the parameter for best results

an employee owned company History of COCOMO II’s REVL Factor In early versions of COCOMO 81, Requirements Volatility (RVOL) was a cost driver ranging from Low to Extra High in rating RVOL was changed to a percentage multiplier of Size because the cost driver was too volatile and subjective In COCOMOII.1999, RVOL was changed in name only to Breakage(BRAK) In 2000, COCOMO II settled on Requirements Evolution and Volatility (REVL) as a percentage multiplier of Effective Size caused by volatility and evolution of baselined requirements REVL is a percentage measure of “wasted effort” expressed in COCOMO II’s primary unit, Source Lines of Code In COCOMO II, a 10% change in REVL can have more impact than a two-level change in CMM Level Without the textual guidance from RVOL, REVL can severely impact an estimate (“With great power comes great responsibility” - Uncle Ben Parker)

an employee owned company Other Popular Estimation Models Models used: SEER-SEM, Cost Xpert, REVIC SEER-SEM : Requirements Volatility (Change) : ranges from Low (“essentially no requirements changes”) to Extra High (“frequent major changes”) Cost Xpert : Requirements Evolution Volatility : ranges from Nominal to Extra High REVIC : Requirements Volatility : ranges from Low to Extra High Sample projects of different sizes were run to capture the percentage change to effort caused by changes in each model’s Requirements factor only Assuming that conceptually all the models start from zero impact to effort and work up, the deltas were aligned without rating headings to show a potential range from zero GOAL: Develop guidelines for REVL using other popular costing models and the textual descriptions from COCOMO 81’s RVOL

an employee owned company Other Popular Estimation Models (cont’d) Percent change in estimated effort between ratings Size is not a factor as the deltas are stable Average of each delta was taken to develop a consensus range (only 2 values for Delta 4) The models assume a lowest value of “no requirements volatility” which is equal to a REVL of 0% Using the rating and description from RVOL, the average of the Deltas form a range for REVL LO = 0% to average (Delta 1), etc.

an employee owned company Using the Translations - Rosetta Stone GOAL: Develop formula for REVL as a function of RVOL using COCOMO 81 effort, COCOMO II effort, and the Rosetta Stone Uses the effort formula from COCOMO 81 with RVOL added back in and KDSI converted to KSLOC (reduce KDSI by 25% for 3rd Generation Languages) Uses the effort formula from COCOMO II with Scale Factors set as described in Rosetta Stone; PMAT = Low as MODP = Nominal Corresponding development mode formulas (Embedded, Semi- detached, Organic) are set equal to one another Formulas assume no impact from other cost drivers; set equal to 1.0 Formulas are reduced to show REVL as a function of RVOL and Size Result is three formulas corresponding to the three development modes

an employee owned company Using the Translations - Rosetta Stone - Reduction Example Example for Embedded Mode: Effort E81 = 2.8 * RVOL * (Size * 0.75) 1.20 Effort EII = 2.94 * (REVL * (Size)) * (REVL * (Size)) = 2.8 * RVOL * (Size * 0.75) 1.20 (REVL * (Size)) = * RVOL * Size 1.20 * (REVL * (Size)) = * RVOL * Size 1.20 REVL * Size = * RVOL * Size REVL (Embedded) = * RVOL * Size Other Development Modes: REVL (Semi-detached) = * RVOL * Size REVL (Organic) = * RVOL * Size

an employee owned company Using the Translations - Rosetta Stone - Results Results for Organic and Semi-detached are too high (80% for Nominal, Organic, 25 KSLOC) Results for Embedded look acceptable, but need a way to make all the results equally acceptable

an employee owned company Using the Translations - Rosetta Stone - Using a Bias Target: Develop a multiplicative bias that sets the results of Low to 1.0 (0% REVL) for every result The bias is the inverse of the value for Low, changing with each size and development mode Assume the bias is carried through the column for each size and development mode Result is the “floor value” for each rating Also equal to the Cumulative Percentage Delta between results for REVL, size independent Example: For Embedded mode, a Nominal Requirements Volatility is equal to REVL between 8.5% and 24.8%

an employee owned company Using the Translations - REVIC II GOAL: Develop formula for REVL as a function of RVOL using REVIC effort, COCOMO II effort, and REVIC II Uses the effort formula from REVIC (includes RVOL) and KDSI converted to KSLOC (reduce KDSI by 25% for 3rd Generation Languages) Uses the effort formula from COCOMO II with Scale Factors set as described in REVIC II Corresponding development mode formulas (Embedded, Semi- detached, Organic) are set equal to one another Formulas assume no impact from other cost drivers; set equal to 1.0 Formulas are reduced to show REVL as a function of RVOL Result is three formulas corresponding to the three development modes

an employee owned company Using the Translations - REVIC II - Reduction Example Example for Embedded Mode: Effort EREV = * RVOL * (Size * 0.75) 1.20 Effort ERII = * (Size * REVL) * (Size * REVL) 1.20 = * RVOL * (Size * 0.75) 1.20 (Size * REVL) 1.20 = * RVOL * Size 1.20 * (Size * REVL) 1.20 = * RVOL * Size 1.20 Size * REVL = * RVOL * Size REVL (Embedded) = * RVOL Other Development Modes: REVL (Semi-detached) = * RVOL REVL (Organic) = * RVOL

an employee owned company Using the Translations - REVIC II - Results Results are poor for all modes with all values falling below 1.0 (0% REVL) Adjust the results using the same bias technique used for Rosetta Stone

an employee owned company Using the Translations - REVIC II - Using a Bias Target: Develop a multiplicative bias that sets the results of Low to 1.0 (0% REVL) for every result The bias is the inverse of the value for Low, changing with each development mode Assume the bias is carried through the column for each development mode Result is the “floor value” for each rating Also equal to the Cumulative Percentage Delta between results for REVL, size independent Example: For Embedded mode, a Nominal Requirements Volatility is equal to REVL between 8.2% and 23.8%

an employee owned company Using the Translations - Rosetta Stone/REVIC Guide GOAL: Develop single guide for REVL using COCOMO 81 text and ratings, Rosetta Stone REVL guide, and REVIC II REVL guide Assumes all six results are equally likely Use the average of all six values to get a single “floor value” for each corresponding rating Values rounded to integer values to be consistent with REVL input

an employee owned company Other Literature on Requirements Volatility - One Percent Metric Capers Jones Requirements Volatility Metric: –one percent per month is expected Tested with Softstar Systems’ Costar 6.0 tool –default scale factors, cost drivers, and calibration model –different Sizes –REVL starts at 0% and raised to match initial Duration –changes made, so that there is a REVL that matches Duration (large sizes require more changes)

an employee owned company Other Literature on Requirements Volatility - Percent Schedule Change Formula Stark, Skillcorn, and Ameele: Y = * X * Z Y = Percent Schedule Change X = Requirements Volatility Z = Risk (Change Requests Per Staff-Day) Expressing as a formula for Requirements Volatility: X = ((Y - (0.23 * Z) ) / 0.41) 2 Assuming Risk is equal to the median value from the study (0.1): X = ((Y ) / 0.41) 2 Defines Requirements Volatility in terms of Percent Schedule Change An equivalent measure in COCOMO II is the Development Schedule (SCED) driver, which changes effort with compression, but not with expansion If metrics on past schedule performance are available, an expected default REVL could be set

an employee owned company Other Literature on Requirements Volatility - Percent Schedule Change Formula (cont’d) 100% is equal to the default schedule (no slips) More research is needed in this area

an employee owned company Future Work and Conclusions Define more textual guidelines to further define ranges (include plus and minus notation like USC-COCOMO tool) Investigate more commercial tools for Requirements Volatility methods Identify more formulas outside of the common tools including case studies Gather industry data on REVL from completed estimates to gauge how estimators are using the value Work provided gives: –Guidance to default REVL behavior through popular model consensus –Guidance to default REVL behavior through translation models –Guidance to REVL behavior using other literature Work provided gives: –Guidance to default REVL behavior through popular model consensus –Guidance to default REVL behavior through translation models –Guidance to REVL behavior using other literature