CSE360 Lecture 27

Introduction to Software Engineering
Software Cost Estimation
(201807)

Transcript

1. CSE360 Introduction to Software Engineering Lecture 27: Software Cost Estimation Javier Gonzalez-Sanchez javiergs@asu.edu javiergs.engineering.asu.edu Office Hours: By appointment
2. Javier Gonzalez-Sanchez | CSE360 | Summer 2017 | 2 Software Cost Estimation Methods • Cost estimation: prediction of both the person-effort and elapsed time of a project • Methods: Algorithmic, Expert judgement, Estimation by analogy, Parkinsonian (Parkinson’s Law). “work expands so as to fill the time available for its completion” • Best approach is a combination of methods: compare and iterate estimates, reconcile differences
3. Javier Gonzalez-Sanchez | CSE360 | Summer 2017 | 3 COCOMO Model • The Constructive Cost Model (COCOMO) is a procedural software cost estimation model developed by Barry W. Boehm. • The model parameters are derived from fitting a regression formula using data from historical projects (61 projects for COCOMO 81 and 163 projects for COCOMO II). • COCOMO is the most widely used, thoroughly documented and calibrated cost model
4. Javier Gonzalez-Sanchez | CSE360 | Summer 2017 | 4 COCOMO II COCOMO II product size estimate product, process, platform, and personnel attributes reuse, maintenance, and increment parameters organizational project data development, maintenance cost and schedule estimates cost, schedule distribution by phase, activity, increment recalibration to organizational data
5. Javier Gonzalez-Sanchez | CSE360 | Summer 2017 | 5 COCOMO II There is an online implementation here: http://csse.usc.edu/tools/COCOMOII.php
6. Javier Gonzalez-Sanchez | CSE360 | Summer 2017 | 6 COCOMO II - User Interface
7. COCOMO Outputs
8. Javier Gonzalez-Sanchez | CSE360 | Summer 2017 | 8 COCOMO II - Output Result A
9. Javier Gonzalez-Sanchez | CSE360 | Summer 2017 | 9 COCOMO II - Output Result B
10. COCOMO Size and Scale Drivers
11. Javier Gonzalez-Sanchez | CSE360 | Summer 2017 | 11 COCOMO II - Inputs
12. Javier Gonzalez-Sanchez | CSE360 | Summer 2017 | 12 Size • The size of a software system can only be known accurately when it is finished. • As the development process progresses then the size estimate becomes more accurate. • Several factors influence the final size o Use of reused systems and components; o Programming language; o Distribution of system. • Effort for adapted software (reused or modified) is not the same as for new software. • Approach: convert adapted software into equivalent size of new software.
13. Javier Gonzalez-Sanchez | CSE360 | Summer 2017 | 13 Nonlinear Reuse Effects • The reuse cost function does not go through the origin due to a cost of about 5% for assessing, selecting, and assimilating the reusable component. • Small modifications generate disproportionately large costs primarily due the cost of understanding the software to be modified, and the relative cost of interface checking. Relative cost Amount Modified 1.0 0.75 0.5 0.25 0.25 0.5 0.75 1.0 0.55 0.70 1.0 0.046 Usual Linear Assumption Data on 2954 NASA modules [Selby,1988]
14. Javier Gonzalez-Sanchez | CSE360 | Summer 2017 | 14 COCOMO II - Inputs
15. Javier Gonzalez-Sanchez | CSE360 | Summer 2017 | 15 Scale Drivers 1. Precedentedness (PREC). Degree to which system is new and past experience applies 2. Development Flexibility (FLEX). Need to conform with specified requirements 3. Architecture/Risk Resolution (RESL). Degree of design thoroughness and risk elimination 4. Team Cohesion (TEAM). Need to synchronize stakeholders and minimize conflict 5. Process Maturity (PMAT). SEI CMM process maturity rating ©USC-CSSE 15
16. Javier Gonzalez-Sanchez | CSE360 | Summer 2017 | 16 Scale Drivers Rating Scale Factors (Wi ) Very Low Low Nominal High Very High Extra High Precedentedness (PREC) thoroughly unprecedented largely unprecedented somewhat unprecedented generally familiar largely familiar throughly familiar Development Flexibility (FLEX) rigorous occasional relaxation some relaxation general conformity some conformity general goals Architecture/Risk Resolution (RESL)* little (20%) some (40%) often (60%) generally (75%) mostly (90%) full (100%) Team Cohesion (TEAM) very difficult interactions some difficult interactions basically cooperative interactions largely cooperative highly cooperative seamless interactions Process Maturity (PMAT) Weighted average of “Yes” answers to CMM Maturity Questionnaire * % significant module interfaces specified, % significant risks eliminated
17. Cost Factors
18. Javier Gonzalez-Sanchez | CSE360 | Summer 2017 | 18 COCOMO II - Inputs
19. Javier Gonzalez-Sanchez | CSE360 | Summer 2017 | 19 Scale Drivers Rating Scale Factors (Wi ) Very Low Low Nominal High Very High Extra High Precedentedness (PREC) thoroughly unprecedented largely unprecedented somewhat unprecedented generally familiar largely familiar throughly familiar Development Flexibility (FLEX) rigorous occasional relaxation some relaxation general conformity some conformity general goals Architecture/Risk Resolution (RESL)* little (20%) some (40%) often (60%) generally (75%) mostly (90%) full (100%) Team Cohesion (TEAM) very difficult interactions some difficult interactions basically cooperative interactions largely cooperative highly cooperative seamless interactions Process Maturity (PMAT) Weighted average of “Yes” answers to CMM Maturity Questionnaire * % significant module interfaces specified, % significant risks eliminated
20. Javier Gonzalez-Sanchez | CSE360 | Summer 2017 | 20 COCOMO II - Inputs
21. Javier Gonzalez-Sanchez | CSE360 | Summer 2017 | 21 1. Product Factors 1.1. Required Reliability (RELY) 1. 2. Data Base Size (DATA) 1. 3. Complexity (CPLX) 1. 4. Developed for Reusability (RUSE) 1. 5. Documentation (DOCU)
22. Javier Gonzalez-Sanchez | CSE360 | Summer 2017 | 22 2. Personnel factors 2.1 Analyst capability (ACAP) 2.2 Programmer (Software Engineer) capability (PCAP) 2.3. Applications experience (APEX) 2.4. Platform (or VM) experience (PLEX) 2.5. Language and tool experience (LTEX) 2.6. Personnel continuity (PCON)
23. Javier Gonzalez-Sanchez | CSE360 | Summer 2017 | 23 3. Platform Factors 3.1. Time constraint (TIME) 3.2. Storage constraint (STOR) 3.3. Platform volatility (PVOL)
24. Javier Gonzalez-Sanchez | CSE360 | Summer 2017 | 24 4. Project Factors Project Factors 4.1. Use of Software tools (TOOL) 4.2. Multisite development (SITE) 4.3. Required schedule - stretch-out or acceleration (SCED) Multisite development
25. Javier Gonzalez-Sanchez | CSE360 | Summer 2017 | 25 Reference • http://sunset.usc.edu/research/COCOMOII/ expert_cocomo/drivers.html • Chapter 23
26. CSE360 – Introduction to Software Engineering Javier G onzalez-Sanchez javiergs@ asu.edu Sum m er 2017 Disclaim er. These slides can only be used as study m aterial for the class C SE360 at ASU. They cannot be distributed or used for another purpose.