1. Pongtip Aroonvatanaporn CSCI 577b Spring 2011 March 25, 2011
COCOMO II Estimation
Pongtip Aroonvatanaporn
CSCI 577b Spring 2011
March 25, 2011
3/25/11
(C) USC-CSSE

2. Outline Problems COCOMO II parameters
Scale Factors
Cost Drivers
CSCI577 Scenario
COCOMO II estimation uncertainties
3/25/11
(C) USC-CSSE

3. Problems Many misunderstandings of COCOMO parameters
Name sound straightforward
But actual meanings are more detailed
Inaccurate estimations of effort
Incorrect values specified for COCOMO drivers
Many done with guesses
3/25/11
(C) USC-CSSE

4. Outline Problems COCOMO II parameters
Scale Factors
Cost Drivers
CSCI577 Scenario
COCOMO II estimation uncertainties
3/25/11
(C) USC-CSSE

5. Scale Factors Precedentedness (PREC) Development Flexibility (FLEX)
Architecture / Risk Resolution (RESL)
Team Cohesion (TEAM)
Process Maturity (PMAT)
3/25/11
(C) USC-CSSE

6. PREC Similarity to previously developed projects
Knowledge on the project
Familiarity
Very low
Very high
Low
Nominal
High
Extra high
Most likely for 577
3/25/11
(C) USC-CSSE

7. PREC for 577 Most students are familiar with web development
Web applications have been done for many years
3/25/11
(C) USC-CSSE

8. FLEX The flexibility in development allowed in the project
Levels of conformity required in developing the software product
Dependent on external interface and specifications
Very low
Very high
Low
Nominal
High
Extra high
Most likely for 577
3/25/11
(C) USC-CSSE

9. FLEC for 577
Most clients do not have strict requirements on specifications
Only on capabilities, but not implementation
Developers can often suggest development approaches
Developers often know better
3/25/11
(C) USC-CSSE

10. RESL How much effort is spent in reviewing design and mitigating risks
Very low
Very high
Low
Nominal
High
Extra high
Most likely for 577
3/25/11
(C) USC-CSSE

11. RESL for 577 ICSM is a risk-based process
Risk resolution are done extensively throughout the project life-cycle
Project designs and architectures are reviewed
ARB at every milestones
Reviews by IIV&V
3/25/11
(C) USC-CSSE

12. PMAT Based on the SEI’s Capability Maturity Model (CMM)
Values correspond to CMMI levels
Very low
Very high
Low
Nominal
High
Extra high
Most likely for 577
3/25/11
(C) USC-CSSE

13. PMAT for 577
The level of detail done for 577 equates roughly to CMMI level 2
If you perform extra project management or life-cycle management tasks, level can increase
3/25/11
(C) USC-CSSE

14. Cost Drivers Focus on the post-architecture
Overall design of the project is already known
For use in development and maintenance of software products
Cost drivers usually tend to be different for each module
E.g. UI modules are usually less complex than server modules
Achieve more accurate estimation when done by module
3/25/11
(C) USC-CSSE

15. Product Required Software Reliability (RELY) Database Size (DATA)
Product Complexity (CPLX)
Developed for Reusability (RUSE)
Documentation Match to Life-Cycle Needs (DOCU)
3/25/11
(C) USC-CSSE

16. RELY The required reliability of the software product
What is the impact of the software failure?
Very low
Very high
Low
Nominal
High
Slight
inconvenience
Low, easily
recoverable
losses
Moderate, easily
recoverable
losses
High financial
losses
Risk to
human life
Most likely for 577
3/25/11
(C) USC-CSSE

17. RELY for 577 Most are web application projects
Content management systems, user management systems, informative web
Systems are used mainly for convenience
To speed up process
To reach wider audience
No safety critical systems
3/25/11
(C) USC-CSSE

18. DATA Calculation formula provided in the COCOMO book
Based on the ratio of database size and program size
Not simply how much you need to store
The data required to complete test of the program
3/25/11
(C) USC-CSSE

19. CPLX 5 areas Find the average between the areas Control operations
Computational operations
Device-dependent operations
Data management operations
User interface management operations
Find the average between the areas
Very low
Very high
Low
Nominal
High
Most likely for 577
3/25/11
(C) USC-CSSE

20. CPLX for 577
Mostly using simple reads and writes between application and database
Utilize NDI/NCS components (i.e. MySQL, PHP, Apache, Tomcat)
Simple UI designs
No widget designs, no framework designs
No direct hardware operations
No complex data structure designs
3/25/11
(C) USC-CSSE

21. RUSE
How much of the components will need to be reused in other applications
Effort needed to achieve generic design
Effort for testing to ensure wide range of compatibility
Across project
Across product line
Across multiple product lines
Low
Extra high
Nominal
High
Very high
Across product
lines
None
Across project
Across program
Across multiple
product lines
Most likely for 577
3/25/11
(C) USC-CSSE

22. RUSE for 577 Not developing for a product line
Independent / standalone web applications
Very little reuse components
Unless designing frameworks and widgets for use within project
3/25/11
(C) USC-CSSE

23. DOCU Based on the life-cycle needs How much is suitable
How much of the life-cycle is captured in documentation
How much is suitable
Affects maintenance portion of life-cycle
Software understanding (SU)
Very low
Very high
Low
Nominal
High
Many life-cycle
needs uncovered
Some life-cycle
needs uncovered
Right-sized to
life-cycle needs
Excessive for
life-cycle needs
Very excessive
for life-cycle
needs
Most likely for 577
3/25/11
(C) USC-CSSE

24. DOCU for 577 ICSM does require certain amount of documentation
May seem excessive due to
Learning curve
Teaching process
Actual documentation may be more than required for project complexity
3/25/11
(C) USC-CSSE

25. Platform Execution Time Constraint (TIME)
Main Storage Constraint (STOR)
Platform Volatility (PVOL)
3/25/11
(C) USC-CSSE

26. Platform
Given the modern day technologies, these drivers are nearly irrelevant.
Most likely NOMINAL for 577 projects
Little computation resource required for web applications
Storage is cheap
Size of data store tends to be insignificant compared to available storage
Platforms are stable (i.e. OS, DBMS). Major changes are not needed.
3/25/11
(C) USC-CSSE

27. Personnel Analyst Capability (ACAP) Programmer Capability (PCAP)
Personnel Continuity (PCON)
Applications Experience (APEX)
Platform Experience (PLEX)
Language and Tool Experience (LTEX)
3/25/11
(C) USC-CSSE

28. ACAP
Capability of requirements gatherer, high-level and detailed designers.
Not based on the experience of analyst
Abilities in
Analysis and design
Efficiency and thoroughness
Communication and cooperation
Very low
Very high
Low
Nominal
High
15th percentile
35th percentile
55th percentile
75th percentile
90th percentile
Most likely for 577
3/25/11
(C) USC-CSSE

29. PCAP Ability of programmers to deal with
COTS packages
SDKs, frameworks, etc.
Based on the capability of the team, not the individuals
Not experience
Very low
Very high
Low
Nominal
High
15th percentile
35th percentile
55th percentile
75th percentile
Most likely for 577
3/25/11
(C) USC-CSSE

30. APEX Team’s experience with specific type of application Very low
Very high
Low
Nominal
High
< 2 months
6 months
1 year
3 years
6 years
Most likely for 577
3/25/11
(C) USC-CSSE

31. APEX for 577 Most are computer science students
Familiar with web development
3/25/11
(C) USC-CSSE

32. PLEX Experience with the platforms used Database
Graphical user interface
Frameworks
Middlewares
Very low
Very high
Low
Nominal
High
< 2 months
6 months
1 year
3 years
6 years
Most likely for 577
3/25/11
(C) USC-CSSE

33. PLEX for 577 Most experiences develop from industry work
Many undergraduate courses may not have provided the necessary experience
3/25/11
(C) USC-CSSE

34. LTEX Experience on the programming language used
Experience with the tool support used for development
IDE, DBMS
Very low
Very high
Low
Nominal
High
< 2 months
6 months
1 year
3 years
6 years
Most likely for 577
3/25/11
(C) USC-CSSE

35. LTEX for 577 Most are computer science students
Should be familiar with few programming languages
Chosen language are often picked by developers, not client
Pick language most comfortable/experienced with
3/25/11
(C) USC-CSSE

36. Project Use of Software Tools (TOOL) Multisite Development (SITE)
Required Development Schedule (SCED)
3/25/11
(C) USC-CSSE

37. TOOL Extensiveness on the use of tools in the development process
Code editing
Life-cycle management
Very low
Very high
Low
Nominal
High
Edit, code,
debug
Simple CASE,
little integration
Basic life-cycle
tools, moderately
integrated
Strong life-cycle
tools, moderately
integrated
Proactive life-cycle
tools, well integrated
with processes,
methods, reuse
Most likely for 577
3/25/11
(C) USC-CSSE

38. TOOL for 577 Most teams do not have access to life-cycle support tools
Most require expensive licenses
Some software engineering aid tools
Bugzilla is used for bug/defect tracking
SVN for version control
3/25/11
(C) USC-CSSE

39. SCED Based on percentage of schedule compression
Stretch-out or acceleration
Accelerated schedules tend to produce more effort at early and later phases
Balanced out by middle phases
Higher ratings do not add or decrease effort
Very low
Very high
Low
Nominal
High
75% or nominal
85% of nominal
100% of nominal
130% of nominal
160% of nominal
Most likely for 577
3/25/11
(C) USC-CSSE

40. SCED for 577
Nominal, high, and very high ratings all have value of 1.0
Makes no difference
Must be at least nominal since much effort is spent in early phases
Address and mitigate risks
Design, review, and refine architecture
3/25/11
(C) USC-CSSE

41. Outline Problems COCOMO II parameters
Scale Factors
Cost Drivers
CSCI577 Scenario
COCOMO II estimation uncertainties
3/25/11
(C) USC-CSSE

42. Purpose
To determine the level of estimation uncertainty throughout the project
Develop the cone of uncertainty in project effort estimation
3/25/11
(C) USC-CSSE

43. What to do Revisit project estimation since the beginning of project
For each COCOMO parameter, determine
Optimistic value
Most likely value
Pessimistic value
The same process done for Code Count assignment
3/25/11
(C) USC-CSSE

44. What to do First individually revisit the estimations
Provide values for the estimations
Discuss each COCOMO parameter among team members
Final values should be consensus among team members
3/25/11
(C) USC-CSSE