cocomo.pdf
- 1. ROHINI COLLEGE OF ENGINEERING AND TECHNOLOGY IT 8075 – SOFTWARE PROJECT MANAGEMENT COCOMO II: A Parametric Productivity Model COnstructive COst MOdel II (COCOMO II) is a model that allows one to estimate the cost, effort,and schedule when planning a new software development activity. COCOMO II is the latest majorextension to the original COCOMO (COCOMO 81) model published in 1981. It consists of threesubmodels, each one offering increased fidelity the further along one is in the project planning and design process. Listed in increasing fidelity, these sub models are called the Applications Composition,Early Design, and Post-architecture models. COCOMO II can be used for the following major decision situations Making investment or other financial decisions involving a software development effort Setting project budgets and schedules as a basis for planning and control Deciding on or negotiating tradeoffs among software cost, schedule, functionality, performance or quality factors Making software cost and schedule risk management decisions Deciding which parts of a software system to develop, reuse, lease, or purchase Making legacy software inventory decisions: what parts to modify, phase out, outsource, etc Setting mixed investment strategies to improve organization's software capability, via reuse, tools, process maturity, outsourcing, etc Deciding how to implement a process improvement strategy, such as that provided in the SEI CMM The original COCOMO model was first published by Dr. Barry Boehm in 1981, and reflected thesoftware development practices of the day. In the ensuing decade and a half, software development techniques changed dramatically. These changes included a move away from mainframe overnightbatch processing to desktop-based real-time turnaround; a greatly increased emphasis on reusing existing software and building new systems using off-the-shelf software components; and spending as much effort to design and manage the software development process as was once spentcreating the software product. These changes and others began to make applying the original COCOMO model problematic. Thesolution to the problem was to reinvent the model for the 1990s. After several years and the combined efforts of USC-CSSE, ISR at UC Irvine, and the COCOMO II Project Affiliate
- 2. ROHINI COLLEGE OF ENGINEERING AND TECHNOLOGY IT 8075 – SOFTWARE PROJECT MANAGEMENT Organizations, the result is COCOMO II, a revised cost estimation model reflecting the changes in professional software development practice that have come about since the 1970s. This new, improved COCOMO is now ready to assist professional software cost estimators for many years to come. Staffing Pattern Putnam was the first to study the problem of what should be a proper staffing pattern for software projects. He extended the classical work of Norden who had earlier investigated the staffing pattern of general research and development type of projects. In order to appreciate the staffing pattern desirable for software projects, we must understand both Norden’s and Putnam’s results. Norden’s Work Nordern studied the staffing patterns of several R&D projects. He found the staffing patterns of R&D projects to be very different from the manufacturing or sales type of work. Staffing pattern of R&D types of projects changes dynamically over time for efficient man power utilization. He concluded that staffing pattern for any R&D project can be approximated by the Rayleigh distribution curve. Putnam’s Work Putnam studied the problem of staffing of software projects. He found that staffing pattern for software development projects has characteristics very similar to R&D projects He adapted the Rayleigh-Norden curve to relate the no of delivered lines of code to the effort and the time required to develop the product. Initially less no of developers are needed. As the project progresses and more detailed work is performed, the number of developers increases and reaches a peak during product delivery After delivery, the no. of project staff falls consistently during product maintenance.