COCOMO II Model Definition Manual - Montana State University
COCOMO II Model Definition ManualVersion 1.4 - Copyright University of Southern California
AcknowledgmentsThis work has been supported both financially and technically by the COCOMO II Program Affiliates: Aerospace, Air ForceCost Analysis Agency, Allied Signal, AT&T, Bellcore, EDS, E-Systems, GDE Systems, Hughes, IDA, Litton, LockheedMartin, Loral, MCC, MDAC, Motorola, Northrop Grumman, Rational, Rockwell, SAIC, SEI, SPC, Sun, TI, TRW, USAFRome Lab, US Army Research Labs, Xerox.Graduate Assistants:Chris Abts, Brad Clark, Sunita Devnani-ChulaniThe COCOMO II project is being led by Dr. Barry BoehmVersion 1.4 - Copyright University of Southern California
Table of ContentsCHAPTER 1: FUTURE SOFTWARE PRACTICES -----------------------11.1 -----------------------------------------11.2 FUTURE MARKETPLACE ------------2CHAPTER 2: COCOMO II STRATEGY AND ---------------------------------42.1 COCOMO II M ODELS FOR THE SOFTWARE MARKETPLACE SECTORS ------------42.2 COCOMO II M ODEL RATIONALE AND ELABORATION ------------------------------42.3 DEVELOPMENT EFFORT ESTIMATES --62.3.1 Nominal Person Months ------72.3.2 Breakage ------------------------72.3.3 Adjusting for Reuse ------------72.3.4 Adjusting for Re-engineering or Conversion ----------------------------- -- 112.3.5 Applications Maintenance ----------------------------------------------- ----- 122.3.6 Adjusting Person Months ------------------------------------------------ ----- 132.4 DEVELOPMENT SCHEDULE ------ 132.4.1 Output Ranges --------------- 13CHAPTER 3: SOFTWARE ECONOMIES AND DISECONOMIES OF SCALE ------------------------------------------------ 153.1 APPROACH ------------------------------ 153.1.1 Previous Approaches -------- 153.2 SCALING DRIVERS --------------------- 163.2.1 Precedentedness (PREC) and Development Flexibility (FLEX) --------- 163.2.2 Architecture / Risk Resolution (RESL) ---------------------------------- ---- 173.2.3 Team Cohesion (TEAM) - --- 173.2.4 Process Maturity (PMAT) ------------------------------------------------ ---- 19CHAPTER 4: THE APPLICATION COMPOSITION ------------------------ 214.1 APPROACH ------------------------------ 214.2 OBJECT POINT COUNTING PROCEDURE ---------------------------------------------- 21CHAPTER 5: THE EARLY DESIGN MODEL -------------------------------------- 245.1 COUNTING WITH FUNCTION ------- 245.2 COUNTING PROCEDURE FOR UNADJUSTED FUNCTION POINTS ------------------- 255.3 CONVERTING FUNCTION POINTS TO LINES OF CODE ------------------------------- 265.4 COST DRIVERS ------------------------- 265.4.1 Overall Approach: Personnel Capability (PERS) Example -------------- 275.4.2 Product Reliability and Complexity (RCPX) ------------------------------ - 285.4.3 Required Reuse ----------- 285.4.4 Platform Difficulty (PDIF) - 285.4.5 Personnel Experience (PREX) ----------------------------------------------- 295.4.6 Facilities (FCIL) ------------- 295.4.7 Schedule (SCED) ------------ 29CHAPTER 6: THE POST-ARCHITECTURE MODEL ---------------------------- 316.1 LINES OF CODE COUNTING RULES -- 316.2 FUNCTION POINTS --------------------- 336.3 COST DRIVERS ------------------------- 336.3.1 Product Factors -------------- 336.3.2 Platform Factors ------------- 34Version 1.4 - Copyright University of Southern Californiai
6.3.3 Personnel Factors ----------- 356.3.4 Project ---------------------- 37CHAPTER 7: ------------------- 41CHAPTER 8: GLOSSARY AND INDEX ---------------------------------------------- 43APPENDIX A: MASTER ------ 46APPENDIX B: LOGICAL LINES OF SOURCE CODE COUNTING RULES - 52APPENDIX C: COCOMO II PROCESS --------------------------------------- 57APPENDIX D: VALUES FOR COCOMO ------------------------------------------ 68Version 1.4 - Copyright University of Southern Californiaii
Chapter 1: Future Software Practices MarketplaceChapter 1: Future Software Practices Marketplace"We are becoming a software company," is an increasingly-repeated phrase in organizations as diverse as finance,transportation, aerospace, electronics, and manufacturing firms. Competitive advantage is increasingly dependent on thedevelopment of smart, tailorable products and services, and on the ability to develop and adapt these products and servicesmore rapidly than competitors’ adaptation times.Dramatic reductions in computer hardware platform costs, and the prevalence of commodity software solutions haveindirectly put downward pressure on systems development costs. This situation makes cost-benefit calculations even moreimportant in selecting the correct components for construction and life cycle evolution of a system, and in convincingskeptical financial management of the business case for software investments. It also highlights the need for concurrentproduct and process determination, and for the ability to conduct trade-off analyses among software and system life cyclecosts, cycle times, functions, performance, and qualities.Concurrently, a new generation of software processes and products is changing the way organizations develop software.These new approaches-evolutionary, risk-driven, and collaborative software processes; fourth generation languages andapplication generators; commercial off-the-shelf (COTS) and reuse-driven software approaches; fast-track softwaredevelopment approaches; software process maturity initiatives-lead to significant benefits in terms of improved softwarequality and reduced software cost, risk, and cycle time.However, although some of the existing software cost models have initiatives addressing aspects of these issues, these newapproaches have not been strongly matched to date by complementary new models for estimating software costs andschedules. This makes it difficult for organizations to conduct effective planning, analysis, and control of projects using thenew approaches.These concerns have led to the formulation of a new version of the Constructive Cost Model (COCOMO) for software effort,cost, and schedule estimation. The original COCOMO [Boehm 1981] and its specialized Ada COCOMO successor [Boehmand Royce 1989] were reasonably well-matched to the classes of software project that they modeled: largely custom, build-tospecification software [Miyazaki and Mori 1985, Boehm 1985, Goudy 1987]. Although Ada COCOMO added a capabilityfor estimating the costs and schedules for incremental software development, COCOMO encountered increasing difficulty inestimating the costs of business software [Kemerer 1987, Ruhl and Gunn 1991], of object-oriented software [Pfleeger 1991],of software created via spiral or evolutionary development models, or of software developed largely via commercial-off-theshelf (COTS) applications-composition capabilities.1.1 ObjectivesThe initial definition of COCOMO II and its rationale are described in this paper. The definition will be refined as additionaldata are collected and analyzed. The primary objectives of the COCOMO II effort are: To develop a software cost and schedule estimation model tuned to the life cycle practices of the 1990’s and 2000’s. To develop software cost database and tool support capabilities for continuous model improvement. To provide a quantitative analytic framework, and set of tools and techniques for evaluating the effects of softwaretechnology improvements on software life cycle costs and schedules.These objectives support the primary needs expressed by software cost estimation users in a recent Software EngineeringInstitute survey [Park et al. 1994]. In priority order, these needs were for support of project planning and scheduling, projec tstaffing, estimates-to-complete, project preparation, replanning and rescheduling, project tracking, contract negotiation,proposal evaluation, resource leveling, concept exploration, design evaluation, and bid/no-bid decisions. For each of theseneeds, COCOMO II will provide more up-to-date support than the original COCOMO and Ada COCOMO predecessors.Version 1.4 - Copyright University of Southern California1
Chapter 1: Future Software Practices Marketplace1.2 Future Marketplace ModelFigure1 summarizes the model of the future software practices marketplace that we are using to guide the development ofCOCOMO II. It includes a large upper "end-user programming" sector with roughly 55 million practitioners in the U.S. by theyear 2005; a lower "infrastructure" sector with roughly 0.75 million practitioners; and three intermediate sectors, involvingthe development of applications generators and composition aids (0.6 million practitioners), the development of systems byapplications composition (0.7 million), and system integration of large-scale and/or embedded software systems (0.7 million)1.End-User Programming(55,000,000 performers in US)Application Generatorsand Composition Aids(600,000)ApplicationComposition(700,000)System Integration(700,000)Infrastructure(750,000)Figure 1: Future Software Practices Marketplace ModelEnd-User Programming will be driven by increasing computer literacy and competitive pressures for rapid, flexible, and userdriven information processing solutions. These trends will push the software marketplace toward having users develop mostinformation processing applications themselves via application generators. Some example application generators arespreadsheets, extended query systems, and simple, specialized planning or inventory systems. They enable users to determinetheir desired information processing application via domain-familiar options, parameters, or simple rules. Every enterprisefrom Fortune 100 companies to small businesses and the U.S. Department of Defense will be involved in this sector.Typical Infrastructure sector products will be in the areas of operating systems, database management systems, user interfacemanagement systems, and networking systems. Increasingly, the Infrastructure sector will address "middleware" solutions forsuch generic problems as distributed processing and transaction processing. Representative firms in the Infrastructure sectorare Microsoft, NeXT, Oracle, SyBase, Novell, and the major computer vendors.In contrast to end-user programmers, who will generally know a good deal about their applications domain and relatively littleabout computer science, the infrastructure developers will generally know a good deal about computer science and relativelylittle about applications. Their product lines will have many reusable components, but the pace of technology (new processor,memory, communications, display, and multimedia technology) will require them to build many components and capabilitiesfrom scratch.Performers in the three intermediate sectors in Figure 1 will need to know a good deal about computer science-intensiveInfrastructure software and also one or more applications domains. Creating this talent pool is a major national challenge.1These figures are judgment-based extensions of the Bureau of Labor Statistics moderate-growth labor distribution scenariofor the year 2005 [CSTB 1993; Silvestri and Lukaseiwicz 1991]. The 55 million End-User programming figure was obtainedby applying judgment based extrapolations of the 1989 Bureau of the Census data on computer usage fractions by occupation[Kominski 1991] to generate end-user programming fractions by occupation category. These were then applied to the 2005occupation-category populations (e.g., 10% of the 25M people in "Service Occupations"; 40% of the 17M people in"Marketing and Sales Occupations"). The 2005 total of 2.75 M software practitioners was obtained by applying a factor of 1.6to the number of people traditionally identified as "Systems Analysts and Computer Scientists"Version 1.4 - Copyright University of Southern California2
Chapter 1: Future Software Practices MarketplaceThe Application Generators sector will create largely prepackaged capabilities for user programming. Typical firms operatingin this sector are Microsoft, Lotus, Novell, Borland, and vendors of computer-aided planning, engineering, manufacturing,and financial analysis systems. Their product lines will have many reusable components, but also will require a good deal ofnew-capability development from scratch. Application Composition Aids will be developed both by the firms above and bysoftware product-line investments of firms in the Application Composition sector.The Application Composition sector deals with applications which are too diversified to be handled by prepackaged solutions,but which are sufficiently simple to be rapidly composable from interoperable components. Typical components will begraphic user interface (GUI) builders, database or object managers, middleware for distributed processing or transactionprocessing, hypermedia handlers, smart data finders, and domain-specific components such as financial, medical, or industrialprocess control packages.Most large firms will have groups to compose such applications, but a great many specialized software firms will providecomposed applications on contract. These range from large, versatile firms such as Andersen Consulting and EDS, to smallfirms specializing in such specialty areas as decision support or transaction processing, or in such applications domains asfinance or manufacturing.The Systems Integration sector deals with large scale, highly embedded, or unprecedented systems. Portions of these systemscan be developed with Application Composition capabilities, but their demands generally require a significant amount of upfront systems engineering and custom software development. Aerospace firms operate within this sector, as do major systemintegration firms such as EDS and Andersen Consulting, large firms developing software-intensive products and services(telecommunications, automotive, financial, and electronic products firms), and firms developing large-scale corporateinformation systems or manufacturing support systems.Version 1.4 - Copyright University of Southern California3
Chapter 2: COCOMO II Strategy and RationaleChapter 2: COCOMO II Strategy and RationaleThe four main elements of the COCOMO II strategy are: Preserve the openness of the original COCOMO; Key the structure of COCOMO II to the future software marketplace sectors described above; Key the inputs and outputs of the COCOMO II submodels to the level of information available; Enable the COCOMO II submodels to be tailored to a project’s particular process strategy.COCOMO II follows the openness principles used in the original COCOMO. Thus, all of its relationships and algorithms willbe publicly available. Also, all of its interfaces are designed to be public, well-defined, and parametrized, so thatcomplementary preprocessors (analogy, case-based, or other size estimation models), post-processors (project planning andcontrol tools, project dynamics models, risk analyzers), and higher level packages (project management packages, productnegotiation aids), can be combined straightforwardly with COCOMO II. To support the software marketplace sectors above,COCOMO II provides a family of increasingly detailed software cost estimation models, each tuned to the sectors’ needs andtype of information available to support software cost estimation.2.1 COCOMO II Models for the Software Marketplace SectorsThe End-User Programming sector from Figure 1 does not need a COCOMO II model. Its applications are typicallydeveloped in hours to days, so a simple activity-based estimate will generally be sufficient.The COCOMO II model for the Application Composition sector is based on Object Points. Object Points are a count of thescreens, reports and third-generation-language modules developed in the application, each weighted by a three-level (simple,medium, difficult) complexity factor [Banker et al. 1994, Kauffman and Kumar 1993]. This is commensurate with the level ofinformation generally known about an Application Composition product during its planning stages, and the correspondinglevel of accuracy needed for its software cost estimates (such applications are generally developed by a small team in a fewwee
The initial definition of COCOMO II and its rationale are described in this paper. The definition will be refined as additional data are collected and analyzed. The primary objectives of the COCOMO II effort are: To develop a software cost and schedule estimation model tuned to the life cycle practices of the 1990’s and 2000’s.
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 .
COCOMO II is also more accurate to solve the problems in software project estimation. In COCOMO II, there are two models, namely Early Design and Post Architecture model. Early Design model is a high-level model in COCOMO II. This model has function to explore alternatives in architectural or do the development strategies.
2. COCOMO II Model COnstructive COst MOdel II (COCOMO II) [4], which was developed in 1995, is a model that allows one to estimate the cost, e ort, and schedule when planning a new soft-ware development activity. It takes qualitative inputs and produces quantitative results. In COCOMO II, the e ort is represented as person-months (PMs). A .
The COCOMO software package is based upon the software cost and schedule estimation model: COnstructive COst MOdel version II (COCOMO II). This is the newly revised version of the original COnstructive COst MOdel (COCOMO) first published by Dr. Barry Boehm in his book Software Engineering Economics, Prentice-
1. Can calibrated COCOMO II for FPs and CFPs perform better than options suggested in research? Null Hypothesis (H 0): Calibrated COCOMO II will not perform better than the currently available options. 2. Do functional size metrics, using the calibrated COCOMO II model, perform better on some types of projects compared to others?
COCOMO Model Basic (COCOMO I 1981) Menghitung dari estimasi jumlah FP dan LOC; FP suatu unit pengukuran untuk keterhubungan dan keterkaitan antar prosedur, fungsi dan lingkungan SW Intermediate (COCOMO II 1999) Menghitung dari besarnya program dan “cost drivers” (faktor-faktor yang berpengaruh langsung kepada
Bruno Hott 2 COCOMO II COCOMO II foi construído em cima do COCOMO '81 para levar em consideração: – Novos processos de desenvolvimento (ex. espiral) – Aumentar a flexibilidade em desenvolvimento de software (ex. reuso, geração de código automático) – Necessidade de tomada de decisão com informações incompletas – Novos dados de projetos (161 projects vs 61)
AngularJS is an extensible and exciting new JavaScript MVC framework developed by Google for building well-designed, structured and interactive single-page applications (SPA). It lays strong emphasis on Testing and Development best practices such as templating and declarative bi-directional data binding. This cheat sheet co-authored by Ravi Kiran and Suprotim Agarwal, aims at providing a quick .
