860 likes | 1.26k Views
COCOMO II Overview. A Winsor Brown (especially from page 50 on) (Based on original by Ray Madachy madachy@usc.edu) CSCI 510 September 22, 2008. Agenda. COCOMO introduction Basic estimation formulas Cost factors Reuse model Sizing USC COCOMO tool demo Data collection.
E N D
COCOMO II Overview A Winsor Brown (especially from page 50 on) (Based on original by Ray Madachy madachy@usc.edu) CSCI 510 September 22, 2008 (c) 2005-08 USC CSSE
Agenda • COCOMO introduction • Basic estimation formulas • Cost factors • Reuse model • Sizing • USC COCOMO tool demo • Data collection (c) 2005-08 USC CSSE
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 • Best approach is a combination of methods • compare and iterate estimates, reconcile differences • COCOMO is the most widely used, thoroughly documented and calibrated cost model • Price-to-win • Top-down • Bottom-up (c) 2005-08 USC CSSE
COCOMO Background • COCOMO - the “COnstructive COst MOdel” • COCOMO II is the update to COCOMO 1981 • ongoing research with annual calibrations made available • Originally developed by Dr. Barry Boehm and published in 1981 book Software Engineering Economics • COCOMO II described in new book Software Cost Estimation with COCOMO II • COCOMO can be used as a framework for cost estimation and related activities (c) 2005-08 USC CSSE
Software Estimation Accuracy 4x • Effect of uncertaintiesover time 2x Relative Size Range x 0.5x Initial Operating Capability OperationalConcept Life Cycle Objectives Life Cycle Architecture 0.25x Feasibility Plans/Rqts. Design Develop and Test Phases and Milestones (c) 2005-08 USC CSSE
COCOMO Black Box Model product size estimate development, maintenance cost and schedule estimates product, process, platform, and personnel attributes COCOMO II cost, schedule distribution by phase, activity, increment reuse, maintenance, and increment parameters organizational project data recalibration to organizational data (c) 2005-08 USC CSSE
Major COCOMO II Features • Multi-model coverage of different development sectors • Variable-granularity cost model inputs • Flexibility in size inputs • SLOCS • function points • application points • other (use cases ...) • Range vs. point estimates per funnel chart (c) 2005-08 USC CSSE
COCOMO Uses for Software Decision Making • Making investment decisions and business-case analyses • Setting project budgets and schedules • Performing tradeoff analyses • Cost risk management • Development vs. reuse decisions • Legacy software phaseout decisions • Software reuse and product line decisions • Process improvement decisions (c) 2005-08 USC CSSE
Productivity Ranges • COCOMO provides natural framework to identify high leverage productivity improvement factors and estimate their payoffs. (c) 2005-08 USC CSSE
COCOMO Submodels • Applications Composition involves rapid development or prototyping efforts to resolve potential high-risk issues such as user interfaces, software/system interaction, performance, or technology maturity. It’s sized with application points (weighted screen elements, reports and 3GL modules). • The Early Design model involves exploration of alternative software/system architectures and concepts of operation using function points and a course-grained set of 7 cost drivers. • The Post-Architecture model involves the actual development and maintenance of a software product using source instructions and / or function points for sizing, with modifiers for reuse and software breakage; a set of 17 multiplicative cost drivers; and a set of 5 factors determining the project's scaling exponent. (c) 2005-08 USC CSSE
Agenda • COCOMO introduction • Basic estimation formulas • Cost factors • Reuse model • Sizing • USC COCOMO tool demo • Data collection (c) 2005-08 USC CSSE
COCOMO Effort Formulation # of cost drivers Effort (person-months) = A (Size)BPEMi i=1 • Where: • A is a constant derived from historical project data (currently A = 2.94 in COCOMOII.2000) • Size is in KSLOC (thousand source lines of code), or converted from function points or object points • B is an exponent for the diseconomy of scale dependent on five additive scale drivers according to b = .91 + .01*SSFi,where SFiis a weighting factor for ith scale driver • EMiis the effort multiplier for the ith cost driver. The geometric product results in an overall effort adjustment factor to the nominal effort. • Automated translation effects are not included (c) 2005-08 USC CSSE
Diseconomy of Scale • Nonlinear relationship when exponent > 1 (c) 2005-08 USC CSSE
COCOMO Schedule Formulation Schedule (months) = C (Effort)(.33+0.2(B-1.01))x SCED%/100 • Where: • Schedule is the calendar time in months from the requirements baseline to acceptance • C is a constant derived from historical project data (currently C = 3.67 in COCOMOII.2000) • Effort is the estimated person-months excluding the SCED effort multiplier • B is the sum of project scale factors • SCED% is the compression / expansion percentage in the SCED cost driver • This is the COCOMOII.2000 calibration • Formula can vary to reflect process models for reusable and COTS software, and the effects of application composition capabilities. (c) 2005-08 USC CSSE
Coverage of Different Processes • COCOMO II provides a framework for tailoring the model to any desired process • Original COCOMO was predicated on the waterfall process • single-pass, sequential progression of requirements, design, code, test • Modern processes are concurrent, iterative, incremental, and cyclic • e.g. Rational Unified Process (RUP), the USC Model-Based Architecting and Software Engineering (MBASE) process • Effort and schedule are distributed among different phases and activities per work breakdown structure of chosen process (c) 2005-08 USC CSSE
Common Process Anchor Points • Anchor points are common process milestones around which cost and schedule budgets are organized • COCOMO II submodels address different development stages anchored by these generic milestones: • Life Cycle Objectives (LCO) • inception: establishing a sound business case • Life Cycle Architecture (LCA) • elaboration: commit to a single architecture and elaborate it to cover all major risk sources • Initial Operational Capability (IOC) • construction: commit to transition and support operations (c) 2005-08 USC CSSE
MBASE Phase Distributions • see COCOMO II book for complete phase/activity distributions Phase Effort % Schedule % Inception 6 12.5 Elaboration 24 37.5 Construction 76 62.5 Transition 12 12.5 COCOMO Total 100 100 Project Total 118 125 (c) 2005-08 USC CSSE
Waterfall Phase Distributions Phase Effort % Schedule % Plans & rqts 7 20 Product Design 17 26 Programming 58 48 Integration & Test 25 26 Transition 12 12.5 COCOMO Total 100 100 Project Total 119 125 (c) 2005-08 USC CSSE
COCOMO II Output Ranges • COCOMO II provides one standard deviation optimistic and pessimistic estimates. • Reflect sources of input uncertainties per funnel chart. • Apply to effort or schedule for all of the stage models. • Represent 80% confidence limits: below optimistic or pessimistic estimates 10% of the time. (c) 2005-08 USC CSSE
COCOMO Tailoring & Enhancements • Calibrate effort equations to organizational experience • USC COCOMO has a calibration capability • Consolidate or eliminate redundant cost driver attributes • Add cost drivers applicable to your organization • Account for systems engineering, hardware and software integration (c) 2005-08 USC CSSE
Agenda • COCOMO introduction • Basic estimation formulas • Cost factors • Reuse model • Sizing • USC COCOMO tool demo • Data collection (c) 2005-08 USC CSSE
Cost Factors • Significant factors of development cost: • scale drivers are sources of exponential effort variation • cost drivers are sources of linear effort variation • product, platform, personnel and project attributes • effort multipliers associated with cost driver ratings • Defined to be as objective as possible • Each factor is rated between very low and very high per rating guidelines • relevant effort multipliers adjust the cost up or down (c) 2005-08 USC CSSE
Scale Drivers • Precedentedness (PREC) • Degree to which system is new and past experience applies • Development Flexibility (FLEX) • Need to conform with specified requirements • Architecture/Risk Resolution (RESL) • Degree of design thoroughness and risk elimination • Team Cohesion (TEAM) • Need to synchronize stakeholders and minimize conflict • Process Maturity (PMAT) • SEI CMM process maturity rating (c) 2005-08 USC CSSE
Product Factors Reliability (RELY) Data (DATA) Complexity (CPLX) Reusability (RUSE) Documentation (DOCU) Platform Factors Time constraint (TIME) Storage constraint (STOR) Platform volatility (PVOL) Personnel factors Analyst capability (ACAP) Program capability (PCAP) Applications experience (APEX) Platform experience (PLEX) Language and tool experience (LTEX) Personnel continuity (PCON) Project Factors Software tools (TOOL) Multisite development (SITE) Required schedule (SCED) Cost Drivers (c) 2005-08 USC CSSE
Example Cost Driver - Required Software Reliability (RELY) • Measures the extent to which the software must perform its intended function over a period of time. • Ask: what is the effect of a software failure? (c) 2005-08 USC CSSE
Example Effort Multiplier Values for RELY 1.39 E.g. a highly reliable system costs 39% more than a nominally reliable system 1.39/1.0=1.39) or a highly reliable system costs 85% more than a very low reliability system (1.39/.75=1.85) 1.15 Very High High Very Low Nominal Low 1.0 Low, Easily Recoverable Losses Slight Inconvenience High Financial Loss Moderate, Easily Recoverable Losses Risk to Human Life 0.88 0.75 (c) 2005-08 USC CSSE
Scale Factors • Sum scale factors Wi across all of the factors to determine a scale exponent, B, using B = .91 + .01 SWi (c) 2005-08 USC CSSE
Precedentedness (PREC) and Development Flexibility (FLEX) • Elaboration of the PREC and FLEX rating scales: (c) 2005-08 USC CSSE
Architecture / Risk Resolution (RESL) • Use a subjective weighted average of the characteristics: (c) 2005-08 USC CSSE
Team Cohesion (TEAM) • Use a subjective weighted average of the characteristics to account for project turbulence and entropy due to difficulties in synchronizing the project's stakeholders. • Stakeholders include users, customers, developers, maintainers, interfacers, and others (c) 2005-08 USC CSSE
Process Maturity (PMAT) • Two methods based on the Software Engineering Institute's Capability Maturity Model (CMM) • Method 1: Overall Maturity Level (CMM Level 1 through 5) • Method 2: Key Process Areas(see next slide) (c) 2005-08 USC CSSE
Key Process Areas • Decide the percentage of compliance for each of the KPAs as determined by a judgement-based averaging across the goals for all 18 Key Process Areas. (c) 2005-08 USC CSSE
Cost Drivers • Product Factors • Platform Factors • Personnel Factors • Project Factors (c) 2005-08 USC CSSE
Product Factors • Required Software Reliability (RELY) • Measures the extent to which the software must perform its intended function over a period of time. Ask: what is the effect of a software failure (c) 2005-08 USC CSSE
Product Factors cont’d • Data Base Size (DATA) • Captures the effect large data requirements have on development to generate test data that will be used to exercise the program. • Calculate the data/program size ratio (D/P): (c) 2005-08 USC CSSE
Product Factors cont’d • Product Complexity (CPLX) • Complexity is divided into five areas: • control operations, • computational operations, • device-dependent operations, • data management operations, and • user interface management operations. • Select the area or combination of areas that characterize the product or a sub-system of the product. • See the module complexity table, next several slides (c) 2005-08 USC CSSE
Product Factors cont’d • Module Complexity Ratings vs. Type of Module • Use a subjective weighted average of the attributes, weighted by their relative product importance. (c) 2005-08 USC CSSE
Product Factors cont’d • Module Complexity Ratings vs. Type of Module • Use a subjective weighted average of the attributes, weighted by their relative product importance. (c) 2005-08 USC CSSE
Product Factors cont’d • Required Reusability (RUSE) • Accounts for the additional effort needed to construct components intended for reuse. • Documentation match to life-cycle needs (DOCU) • What is the suitability of the project's documentation to its life-cycle needs. (c) 2005-08 USC CSSE
Platform Factors • Platform • Refers to the target-machine complex of hardware and infrastructure software (previously called the virtual machine). • Execution Time Constraint (TIME) • Measures the constraint imposed upon a system in terms of the percentage of available execution time expected to be used by the system. (c) 2005-08 USC CSSE
Platform Factors cont’d • Main Storage Constraint (STOR) • Measures the degree of main storage constraint imposed on a software system or subsystem. • Platform Volatility (PVOL) • Assesses the volatility of the platform (the complex of hardware and software the software product calls on to perform its tasks). (c) 2005-08 USC CSSE
Personnel Factors • Analyst Capability (ACAP) • Analysts work on requirements, high level design and detailed design. Consider analysis and design ability, efficiency and thoroughness, and the ability to communicate and cooperate. • Programmer Capability (PCAP) • Evaluate the capability of the programmers as a team rather than as individuals. Consider ability, efficiency and thoroughness, and the ability to communicate and cooperate. (c) 2005-08 USC CSSE
Personnel Factors cont’d • Applications Experience (AEXP) • Assess the project team's equivalent level of experience with this type of application. • Platform Experience (PEXP) • Assess the project team's equivalent level of experience with this platform including the OS, graphical user interface, database, networking, and distributed middleware. (c) 2005-08 USC CSSE
Personnel Factors cont’d • Language and Tool Experience (LTEX) • Measures the level of programming language and software tool experience of the project team. • Personnel Continuity (PCON) • The scale for PCON is in terms of the project's annual personnel turnover. (c) 2005-08 USC CSSE
Project Factors • Use of Software Tools (TOOL) • Assess the usage of software tools used to develop the product in terms of their capabilities and maturity. (c) 2005-08 USC CSSE
Project Factors cont’d • Multisite Development (SITE) • Assess and average two factors: site collocation and communication support. • Required Development Schedule (SCED) • Measure the imposed schedule constraint in terms of the percentage of schedule stretch-out or acceleration with respect to a nominal schedule for the project. (c) 2005-08 USC CSSE
Cost Factor Rating • Whenever an assessment of a cost driver is between the rating levels: • always round to the Nominal rating • e.g. if a cost driver rating is between High and Very High, then select High. (c) 2005-08 USC CSSE
Cost Driver Rating Level Summary (c) 2005-08 USC CSSE
Cost Driver Rating Level Summary cont’d (c) 2005-08 USC CSSE
Agenda • COCOMO introduction • Basic estimation formulas • Cost factors • Reuse model • Sizing • USC COCOMO tool demo • Data collection (c) 2005-08 USC CSSE