COCOMO

The Constructive Cost Model (COCOMO) is an algorithmic software cost estimation model developed by Barry W. Boehm. The model uses a basic regression formula with parameters that are derived from historical project data and current project characteristics. COCOMO was first published in Boehm's 1981 book Software Engineering Economics[1] as a model for estimating effort, cost, and schedule for software projects. It drew on a study of 63 projects at TRW Aerospace where Boehm was Director of Software Research and Technology. The study examined projects ranging in size from 2,000 to 100,000 lines of code, and programming languages ranging from assembly to PL/I. These projects were based on the waterfall model of software development which was the prevalent software development process in 1981. References to this model typically call it COCOMO 81. In 1995 COCOMO II was developed and finally published in 2000 in the book Software Cost Estimation with COCOMO II.[2] COCOMO II is the successor of COCOMO 81 and is better suited for estimating modern software development projects. It provides more support for modern software development processes and an updated project database. The need for the new model came as software development technology moved from mainframe and overnight batch processing to desktop development, code reusability and the use of off-the-shelf software components. This article refers to COCOMO 81. COCOMO consists of a hierarchy of three increasingly detailed and accurate forms. The first level, Basic COCOMO is good for quick, early, rough order of magnitude estimates of software costs, but its accuracy is limited due to its lack of factors to account for difference in project attributes (Cost Drivers). Intermediate COCOMO takes these Cost Drivers into account and Detailed COCOMO additionally accounts for the influence of individual project phases.

Contents

1 Basic COCOMO 2 Intermediate COCOMOs 3 Detailed COCOMO 4 See also 5 References 6 Further reading 7 External links

Basic COCOMO
Basic COCOMO computes software development effort (and cost) as a function of program size. Program size is expressed in estimated thousands of source lines of code (SLOC) COCOMO applies to three classes of software projects:

Organic projects - "small" teams with "good" experience working with "less than rigid" requirements Semi-detached projects - "medium" teams with mixed experience working with a mix of rigid and less than rigid requirements Embedded projects - developed within a set of "tight" constraints. It is also combination of organic and semi-detached projects.(hardware, software, operational, ...)

The basic COCOMO equations take the form

Effort Applied (E) = ab(SLOC)bb [ man-months ] Development Time (D) = cb(Effort Applied)db [months] People required (P) = Effort Applied / Development Time [count]

where, SLOC is the estimated number of delivered lines (expressed in thousands ) of code for project. The coefficients ab, bb, cb and db are given in the following table:
Software project Organic Semidetached Embedded ab bb cb db 2. 1.0 2. 0.3 4 5 5 8 3. 1.1 2. 0.3 0 2 5 5 3. 1.2 2. 0.3 6 0 5 2

Basic COCOMO is good for quick estimate of software costs. However it does not account for differences in hardware constraints, personnel quality and experience, use of modern tools and techniques, and so on.

Intermediate COCOMOs
Intermediate COCOMO computes software development effort as function of program size and a set of "cost drivers" that include subjective assessment of product, hardware, personnel and project attributes. This extension considers a set of four "cost drivers",each with a number of subsidiary attributes:

Product attributes o Required software reliability o Size of application database o Complexity of the product Hardware attributes

Run-time performance constraints Memory constraints Volatility of the virtual machine environment Required turnabout time Personnel attributes o Analyst capability o Software engineering capability o Applications experience o Virtual machine experience o Programming language experience Project attributes o Use of software tools o Application of software engineering methods o Required development schedule
o o o o

Each of the 15 attributes receives a rating on a six-point scale that ranges from "very low" to "extra high" (in importance or value). An effort multiplier from the table below applies to the rating. The product of all effort multipliers results in an effort adjustment factor (EAF). Typical values for EAF range from 0.9 to 1.4.
Ratings Cost Drivers Product attributes Required software reliability Size of application database Complexity of the product Hardware attributes Run-time performance constraints Memory constraints Volatility of the virtual machine envir onment Required turnabout time Personnel attributes Analyst capability Applications experience 1.46 1.29 1.19 1.13 1.00 1.00 0.86 0.91 0.71 0.82 0.87 0.87 1.00 1.00 1.00 1.00 1.11 1.06 1.15 1.07 1.30 1.21 1.30 1.15 1.66 1.56 0.70 0.75 0.88 0.94 0.85 1.00 1.00 1.00 1.15 1.08 1.15 1.40 1.16 1.30 1.65 Very Low Low Nomina l High Very High Extra High

Software engineer capability Virtual machine experience Programming language experience Project attributes Application of software engineering methods Use of software tools Required development schedule

1.42 1.21 1.14

1.17 1.10 1.07

1.00 1.00 1.00

0.86 0.90 0.95

0.70

1.24 1.24 1.23

1.10 1.10 1.08

1.00 1.00 1.00

0.91 0.91 1.04

0.82 0.83 1.10

The Intermediate Cocomo formula now takes the form:

E=ai(SLoC)(bi).EAF

where E is the effort applied in person-months, SLoC is the estimated number of thousands of delivered lines of code for the project, and EAF is the factor calculated above. The coefficient ai and the exponent bi are given in the next table.
Software pr oject Organic Semidetached Embedded ai bi

3.2 1.05 3.0 1.12 2.8 1.20

The Development time D calculation uses E in the same way as in the Basic COCOMO.

Detailed COCOMO
Detailed COCOMO incorporates all characteristics of the intermediate version with an assessment of the cost driver's impact on each step (analysis, design, etc.) of the software engineering process. The detailed model uses different efforts multipliers for each cost drivers attribute these Phase Sensitive effort multipliers are each to determine the amount of effort required to complete each phase. In detailed COCOMO, the effort is calculated as function of program size and a set of cost drivers given according to each phase of software life cycle.

The five phases of detailed COCOMO are:

plan and requirement. system design. detailed design. module code and test. integration and test.

COCOMO Reference another

Contents

Introduction Audience Sample Project Description and Scope Introduction to COCOMO II Estimates Counting SLOC in the Project Using Costar Estimation Tool Summary of Cost Estimation Results Conclusion References Appendix A: Cost Drivers Appendix B: Scale Factors

Introduction
This article provides a sample of COCOMO II cost estimate for a real project, and concentrates on outlining basic how-to when project manager needs some advice on making simple cost estimates and tools that can be used.

Audience
The article is intended for those who are new to project cost estimation techniques, and those who would like to have a feedback on COCOMO II model. My objective is to describe in a simple way basic cost estimation steps, tools and assumptions, having a real project in mind, and supplying only necessary details on the project itself.

Sample Project Description and Scope

A bioinformatics company, providing advanced methods for data mining of genetic information, intends to construct a distributed application for analysis and navigation of biological networks. As part of this project, a database provider that exposes simple interfaces to UI programmer and hides complexities of the data layer should be build. As soon as the scope of this task is broadly defined

as such, it is sliced into a separate project. The content of this article targets cost estimation perspective of the latter project. The company has already made work on inception phase, and provided the document describing the project concept. The customer has the following preferences:
1. Transfer existing SQL Server database (~1 GB) hosted on Windows to PostgreSQL data end hosted on Linux. 2. Build components for this project using Java. The main component is database provider. 3. Since the project is small, the elaboration phase (or detailed design phase) is not necessary. 4. Project has time constraints.

Said above is a short scope definition for the project provided by the company. As in many projects, the next important step is to make cost estimates.

Introduction to COCOMO II Estimates

COCOMO (Constructive Cost Model) is a model that allows software project managers to estimate project cost and duration. It was developed initially (COCOMO 81) by Barry Boehm in the early eighties2). The COCOMO II1) model is a COCOMO 81 update to address software development practices in the 1990's and 2000's. The model is by now invigorative software engineering artifact that has, from customer perspective, the following features:

The model is simple and well tested Provides about 20% cost and 70% time estimate accuracy

In general, COCOMO II estimates project cost, derived directly from person-months effort, by assuming the cost is basically dependent on total physical size of all project files, expressed in thousands single lines of code (KSLOC). The estimation formulas have the form:
Collapse | Copy Code
<A name=formula></A>Effort (in person-months) = a x KSLOC<SUP>b</SUP>

where coefficient a is about 3 (2.94), and scaling factor b is close to 1 (1.0997). There are similar COCOMO formulas for project duration (expressed in months) and average size of project team. Interestingly, project duration in COCOMO is approximately cube root of effort (in person-months). In practice, COCOMO parameters can be greatly different from its typical values. COCOMO II provides classification of factors that can have an influence on project cost, and lets you make better approximation of coefficients and scaling factors for your particular project. As the result of adjustment, a coefficient value falls between 0.056 120. See Appendix A for COCOMO II list of adjustment factors that affect first parameter. Model-driven adjustment of scaling factor b is

new in COCOMO II model and reflects latest trends in software engineering. You can see scaling factors descriptions in Appendix B. Many project managers used to negotiate project costs with trade-off triangle and trade-off matrix in terms of product functionality, quality, and schedule. If this is a case for you, you might be intrigued how COCOMO II adjustment parameters fit into this picture. The answer is that COCOMO II parameters can be viewed as two sets of parameters. The first set is external and can be loosely matched to trade-off triangle/matrix view and its vocabulary is frequently used while negotiating costs with stakeholder, and the second set is COCOMO II internal and usually cannot be used for this purpose. In this trade-off triangle/matrix perspective, schedule is loosely corresponding to SCED (required development schedule), quality to RELY (required reliability), and functionality to a combination of CPLX (product complexity), DATA (database size), TIME (execution time), DOCU (documentation match to life-cycle needs), and occasionally RUSE, STOR, PVOL parameters. COCOMO II internal parameters such as parameters for evaluation of personnel capabilities/experiences, used project tools and others are obviously important for project cost estimates, but usually are not a subject of cost communications with stakeholder. There are well-approbated COCOMO II tools on the market that calculate these parameters for you, asking questions about particular project in natural language, such as How experienced is the development team? or How tough is the project schedule? and, thus, hiding model details in the background. COCOMO II supercedes earlier version of COCOMO such as COCOMO 81, Ada COCOMO, which are considered by now as outdated. The model simplifies inception phase cost estimates by reducing the total number of parameters to seven (from 15 in the original COCOMO model), and suggests to use functional points for inception phase, and SLOC for later, more accurate phases. In fact, COCOMO II reduces controversy of what project metrics to use SLOC or functional points making the new model more flexible. Comparing to classical COCOMO 81, COCOMO II introduces five scale factors, at least three of them are directly related to PM activities, and, thus, raises the role of project management in reducing project costs:

Takes into account process maturity in the organization (CMM levels) Takes into account the degree to which project architecture exists and is stabilized before construction phase Takes into account relationships perspective: team cohesion, relations with stockholder

Now, I will demonstrate basic estimation steps in COCOMO II model. To make actual estimates, Ill use the source code for this project that can be downloaded from here. If you have project source code, and some project details, this is all you need to make a simple cost estimate. Surely, you dont have a source code before starting your project, and this approach is more like post-mortem analysis. OK, this is my intention! By doing so, some chronological accuracy will be lost, but real cost estimate will be more correct.

Counting SLOC in the Project

To make actual estimations, you need at first to figure out SLOC count for each of the components and use these counts in COCOMO model. To put it simple, SLOC (single line of code) is a physical line of code in your program except comments. Of course, you can use your favorite IDE and look onto the status bar in order to see how much line the code contains. It might be acceptable as a first-time estimate of SLOC. To be more accurate, you need to exclude comments and blank lines. Albeit, it is an easy procedure for a small project; for a larger project with many thousands of SLOC and multiple files, the choice of automated SLOC counting tool would be a more natural option. I decided to use for these estimates the CodeCounter program that has a friendly UI, and can count SLOC in many languages including Java, C/C++, SQL (and flavors), HTML/XML. The CodeCounter program can be downloaded for 30-day evaluation from here. The case study source project files reflect four tasks accomplished during this project:

Create PostgreSQL database, indexes, write pgSQL (close to PL/SQL) stored procedures. Build a Java component (composed of multiple JavaBeans) that encapsulates an applications basic logic, and serves as database provider. Build a servlet, considered as a separate component, to dispatch UI calls to the core Java component. Write simple HTML pages to test database provider.

In other words, the sample project source files correspond to four ingredients written in SQL, Java, and HTML/XML. It is convenient before counting to make separate folders corresponding to the project components and place there files to count. The following picture shows the result of line count with CodeCounter in Java folder:

Picture 1.
-->

The result of separate SLOC count in all project folders is the following:
Folder 1 SQL Files Total SLOC 414

2 Java DB Provider 345

Files 3 Java Servlet 4 Web Files 156 113

Table 1. COCOMO generally recommends using standard SLOC counting programs that can perform line counting for code written in different languages. One of these programs is C-based CodeCount (command-line program without UI). You can download its source from Center for Software Engineering (you need to compile it by yourself too!), and count SLOC in C, C++, Java, and other languages. The benefit of CodeCount is that it is free, and was used for many years by many companies for code counting.

Making COCOMO II estimates Using Costar Estimation Tool

Of course, you can use COCOMO II as it is: choose model, formulas, figure out the values for parameters, and manually calculate project costs. I believe it is a matter what tool you prefer in every spring, filling out tax forms just simple calculator or automated software tools. Allegedly, you prefer (you can opt to skip this section if Im wrong!) the latter choice, and therefore, I would cover in this section one of the specific tools for making COCOMO II estimates. Ive selected Costar 7.0 COCOMO II tool since it has a convenient interface and concise help. The program is licensed to over than one million customers. Costar 7.0 30-day demo can be downloaded from here. Generally, you create a main component and subcomponents corresponding to separate tasks of your project. The main component serves basically as the Costar project root for all other components, and is a place to summarize all estimates. It is not supposed to be associated with your project files. You need to create subcomponents for every project task, and type manually total SLOC count for the task from the SLOC counting program. For this sample project (see Costars costar_dbprovider.cst project file for this project in cocomo2.zip), Ive created the main (root) component and four subcomponents:
1. 2. 3. 4.
db_provider servlet database_scripts ui_web_testing

Now, when initial state of components is set up in the Costar project, we can start making actual COCOMO II estimates. Albeit the total cost of the project in COCOMO models is largely determined by total SLOC count, adjustment and scaling parameters for a real project can vary project costs in hundreds of times. As was mentioned above, there are two sets of additional parameters that are used to make COCOMO II estimates more accurate. The first set, 17 cost

drivers, are largely inherited from COCOMO 81 model, and the second set, 5 scale drivers, are new in COCOMO II model. The method of setting these parameters in a real project is rather straightforward. As a project manager, you need to gather information about most important sides of your project such as required product characteristics, required schedule, required product quality, experience and capability of project team, project infrastructure readiness and maturity. Next comes the delicate part of making assumptions about the values of COCOMO II parameters that correspond to the information collected. Since my aim is to make an introduction to COCOMO II techniques and terminology based on real project, I will only briefly describe assumptions that I made for the case study project. All COCOMO II parameters not mentioned below are set to their nominal value equal to 1. The project was characterized by: Scaling factors and product characteristics

Accomplished inception phase, but the major lack of documented architecture since stockholders considered this project as rather small and not made elaboration phase as a separate phase. (RESL scale factor is very low). The development team was familiar with basic concepts of software development methodology, but the software process maturity was close to initial CMM stages (PMAT scale factor, describing CMM level, is low). Medium-size database backend (~1 GB) with about 20 tables and 100 indexes (DATA cost driver is very high).

Schedule and personnel

The project schedule was characterized by fixed time limitations, limited time for new team members to accommodate themselves to the environment and tasks, which means that schedule can be considered as tough (SCED scheduling parameter is high). Team members were experienced more than average in programming languages such as C/C++, but were new to Java development (PCAP, programmer capabilities is high, and LTEX, language/tool experience, cost driver is low). Team members were experienced more than average in Windows environments, but were not especially experienced in the latest Linux developments (PLEX, platform experience, cost driver is low).

Interestingly, COCOMO II predicts that selection of highly capable development team albeit not particularly experienced in language, tools, and platform justifies itself for a project:
Collapse | Copy Code
<CODE>PCAP</CODE> [high=0.88]x <CODE>LTEX</CODE>[low=1.09]x <CODE>PLEX</CODE>[low=1.09] =1.04 ~ 1

There was no separate role for an analyst. This factor decreases teams analytical capabilities. This is not a standard situation in COCOMO model, which has ACAP parameter to account for analyst capabilities. It seems possible to take into account not filled analyst position in COCOMO II by setting analyst capabilities parameter to lower value (ACAP, analyst capabilities is low).

Finally, the pictures 2 and 3 taken from Costar project show all COCOMO II cost drivers and scale factors along with their values:

Picture 2.

Picture 3. Notice that Costar lets you see equations that were used for final cost estimates, as on picture 4:

Picture 4.

Summary of Cost Estimation Results

The overall result of COCOMO II estimates demonstrated in the report obtained from Costar project:

Picture 5. The report says that project cost is $23,000 and project duration is 4.6 months ($5000 was taken as an average monthly developer salary).

Conclusion
This brief article shows how to make cost estimates for a sample project, and outlines basic steps, terms, and tools used. In a smallsize or even intermediatesize project, there is a temptation to cut off traditional sides of development that were widely accepted in the nineties and actively used now. Obviously, ad hoc estimates are prone to error. Cost estimation tools make it easy for you to clarify not only an expected project cost and duration, but also prompt you to verify all basic sides of a software project by providing clear, compact, and concise terms, methodology, which are tested on a wide range of real-life projects, and, thus, reduce essentially project risks, and provide reasonable grounds for communication with a project stockholder.

References
1. Software Cost Estimation With COCOMO II, Prentice Hall, 2000. 2. Software Engineering Economics by Barry Boehm, Prentice Hall, 1981.

Appendix A: Cost Drivers

There are multiple factors that effect project cost. COCOMO II model defines 17 parameters called cost drivers that have a major influence on project cost. Project manager can determine cost drivers based on project specifics, and use them to adjust first coefficient in formula:
Collapse | Copy Code
a = 2.94 x EAF

where EAF (Effort Adjustment Factor) is obtained by multiplication of 17 parameters, which:

All have a nominal value equal to 1.0. Most of them can have values: very low, low, nominal, high, very high (extra low, extra high can be also considered). The range of majority of cost driver values falls between 0.5-1.5, and maximum value exceeds minimum value no more than 50%. Two exceptions are product complexity (CPLX) and analyst capability (ACAP), where max/min value can be as high as 2. SITE, RUSE, DOCU, PVOL, PCON factors (marked with bold) are new in COCOMO II, and reflect trends in software development of late ninetieth, and 2000+ years.

The following table provides a list of COCOMO II adjustment factors. Notice that the second column shows factors for this case study project.
Cost Driver 1 DATA 2 CPLX 3 TIME 4 STOR 5 RUSE 6 DOCU 7 PVOL 8 SCED 9 RELY Sample Project Value high nominal nominal nominal nominal nominal nominal very high nominal Description Database size. Product complexity. Execution time constraint. Main storage constraint. Required reusability. Documentation match to life-cycle needs. Platform volatility. Scheduling factor. Required reliability.

1 TOOL 0 1 APEX 1 1 ACAP 2 1 PCAP 3 1 PLEX 4 1 LTEX 5 1 PCON 6 1 SITE 7

nominal nominal low high low low nominal nominal

Use of software tools. Application experience. Analyst capability. Programmer capability. Platform experience. Language and tools experience. Personnel continuity. Multisite development.

Appendix B: Scale Factors

Scale factors are new in COCOMO II. They modify second coefficient in formula 1 (coefficient b). The effect of scale factor is in 1.01 1.26 range. The second column shows factors for this case study project.
Scale Factor 1 PREC 2 PMAT 3 TEAM 4 FLEX 5 RESL Sample Project Value nominal CMM Level I (upper) nominal nominal little (20%) Description Precedence. Process maturity. Team cohesion. Development flexibility. Architecture and risk resolution.

Twelve essential Steps of Software Testing Life Cycle (STLC)

Posted by: Jaideep software quality assurance, software testing, Project Management, software quality, Quality Assurance, software engineering, Software testers, SDLC, software qa, Project Lifecycle, software testing cycle, Software testing methodologies, software testing procedure, software testing process, software testing projects, software testing strategy, software testing tips, softwaretesting, STLC STLC (Software Testing Life Cycle) is an integral component of SDLC (Software Development Life Cycle). Gone are the times when any software was made on the basis of its requirements and the moment it used to get completed by the development team, it got released to the customer. But now, Testing has become a distinct phenomenon during and after the development of software. No software is released to the customer without a comprehensive testing by QC or Testing team in the organization. The Scope and Methodology may vary from product to product, customer to customer, and organization to organization. There are certain aspects of Software Testing Life Cycle. To name top few among them, I would like to list twelve essential steps of Software Testing Life Cycle. The Steps are to be followed from the start of Testing of software to the end of the testing as follows: 1- Before the dynamic testing, there is a static testing. Static testing includes review of documents required for the software development. This includes following activities: (a) All the documents related to customer requirements and business rules that are required for software design and development should be handed over to QA. These documents should be complete and dually signed by client and representative of the company (usually Project Manager). (b) QA reviews these documents. The reviewing of documents includes comprehensive and thorough study of the documents. If any discrepancy is found then it should be noted and raised in the review meeting with the Development team. (c) After this there should be a formal meeting between the QA and development team regarding these documents, the agenda of this meeting mainly includes what is missing in the document, QA queries to be answered by Development/Project Team and/or clarification required for any confusions. 2- After the Software development or build of a module, QA starts dynamic testing. If during the development the requirement has been changed on customer demand or due to any other reason, then that should be documented and a copy of this revised document is given to the QA and also discussed as explained in point 1 above.

3- Development and Testing environment should be made clear to the QA by the Development team. It include the following activities: (a)- Server to hit for Testing (b)- Installation of latest build on the test server. (c)- Modules/Screens to test. (d)- Test duration as decided by test manager and project manager mutually based on scope of work and team strength. (e) Demo of the software on test server by development team to the QC members. 4- After this Test cases and test scenarios are prepared and then the Test execution by QC. 5- A comprehensive Report of Bugs is prepared by the Testers and a review/verification by QC/QA/Testing Head takes place. Before handing over this report to Development Team there is a thorough review of Bugs List by Test Manager and in case of any clarification required on a bug submitted, the Testing Head discusses the bugs with the assigned tester. 6- Release of bug report by QC Team to Development Team. 7- Discussion/simulation of bugs by QC with development team if development team requires and time required for fixing the bugs should be made clear by Dev team at this stage. 8- Feedback from Development team on reported bugs with the stipulated time frame required to fix all bugs. 9- Any changes in the software being made in respect to fix these bugs should be made clear to the QA team by the Development team. 10- Testing team then Retests or verifies the bugs fixed by the development team. 11- Submitting the retesting bug report to the Test manager and after this the step 5 to step 10 are followed until the product has reached a stage where it can be released to customer. 12- Criteria for ending the testing should be defined by management or Test Manager Like when all major bugs are reported and fixed. Major bugs mean the bugs that affect the Business of the Client.