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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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