Scoping, analysis and estimation

Introduction

Aim

All of us do it at some time in our work place. In fact we do it all the time in our lives. Trying to figure out how much of our resources (e.g. time, money, effort) we need to achieve our goals. It may be an attempt to calculate expected expenses, throw a scrap of paper into the waste basket a few feet away or time required to write some code or whatever-whenever.

To better understand what is involved to get a job done, we need to do an estimate. The estimate itself depends upon our analyzing the scope of work. The analysis cannot be done correctly if the scope of work is not explained clearly. Understanding, explaining and documenting the scope of work is rather difficult. This is usually due to poor domain knowledge, complexity of the business, specific requirements of each customer and poor presentation of the workflows and processes. This article focuses on scoping, analysis and estimation from a developer’s view and not an analyst view while at the same time keeping in mind the above shortcomings.

Proposal

For this article, I will attempt to explain how to create a resource management tool. I will use the object hierarchy tree to identify business objects in my application, create some simple workflows to understand what needs to be done and identify the users of the application.

1.1 Vision

“To develop an easy to use, general purpose, resource management tool.”

1.2 Use cases

• Request a resource: A request is made by an authorized person for a resource to the concerned department.
• Identify a resource: The resource manager then searches for availability of any matching resources.
• Evaluate a resource: The resource is evaluated by the authorized person.
• Allocate a resource: The resource is assigned to a person or department.

1.3 Requirements for each workflow

1.3.1 Request for a resource

• Give the name of the resource.
• Give the type of the resource.
• Give the description of the resource.
• Give the reason for wanting the resource.
• Give the date of the request.
• Give the date by which the resource is expected.
• Give the approximate cost range expected for the resource.
• Give the importance of the resource.

1.3.3 Identify a resource

• Search for the requested resource.
• Display search results.
• View details of available resources.

1.3.4 Evaluate a resource

1.3.5 Allocate a resource

1.4 Identifying business entities.

Now comes the part I like. Using the limited documentation above, we can cover a lot of ground using a little thinking. We first identify the business objects as best as we can and then create an object hierarchy tree to understand them better.

First, let us start with a general object to represent the tool we are developing. I am calling it “Rap”. Then reading the documentation provided, I have identified possible business object and changed their font to bold-italic-orange.

Besides the business entities are the utility objects like the objects for data access, custom exception handling, logging, data formatters, security, constants and external interfaces. Also keep in mind regular objects like the users, forms, error and other message texts.

So using a combination of experience as well as the available documentation I came up with the following object tree. Now this isn’t the final story and based upon our further understanding we could revise the object tree.

The object tree gives me a better picture of what is involved in developing the application and would be easier to grasp than several thousand lines of documents. While this is not an OOP inheritance tree, it does involve similar thinking. So as we get into scoping and analysis, this tree will go on expanding and we would end up with several objects.

1.5 Map the objects to the workflows

This part of the scoping and analysis is used more for traceability. It helps us understand how are objects are connected to the workflows provided and justifies their existence. This has similarities to the activity diagrams used in UML. The objects are the “streams” and the nodes of the workflow are the “activities”.

We could debate exactly which workflow node belongs to which object. This is exactly what is needed to improve our understanding of the application. The more we try to fit things into the object tree and work flow map, the more we are able to identify what we still need to do to satisfy the requirements. The more we try to fit things into the object tree and work flow map, the more we understand if the requirements have any gaps or are self explanatory. It helps us realize if we have understood the customer’s needs correctly. For example, I did not identify the object “Data” until I tried to finish the mapping. And I still am not sure if the “Fill request form” workflow node should be with the “Request” object or the “Form” object. But I still feel that the above mapping gives me a clearer picture of what is involved here.

1.6 Estimating effort.

I had written two articles of my approach to estimation. They are How to estimate a software project and How to estimate a software project in man-hours.

For estimation, consider the following general points:

• Identifying the architecture, forms, classes, components and supporting documents required.
• Defining the structure and purpose of all the items.
• Writing test cases.
• Coding, code optimizing, unit testing and integration testing.
• Regression testing, performance testing.
• Deployment issues and acceptance testing.
• Beta testing and warranty.

I will focus on only two objects identified in this article as follows:

1.6.1 Forms

From the objects and workflow map we can now break down the details further almost to a GUI level. The forms in the figure object/workflow above would be the request and reasons forms. The request details are provided in section 1.3.1. Using this, we can arrive at the control types required in each form.

For example,

• Give the name of the resource -> label and text box.
• Give the type of the resource -> label and drop down list.
• Give the description of the resource -> label and multi line text box.
• Give the reason for wanting the resource -> label and multi line text box.
• Give the date of the request -> label and calendar control.
• Give the date by which the resource is expected -> label and calendar control.
• Give the approximate cost range expected for the resource -> two labels and two text boxes.
• Give the importance of the resource -> label and drop down list.

Most forms are placed inside a template divided into a combination of top, left, right, bottom and central sections. Each of these sections may contain dynamic or static information which has to be estimated separately. Again a document describing the form, the location of the controls and content, the human engineering effort, the time and effort to get the form approved from various stake holders are all part of the estimate.

From my experience, it would take at least two man days from concept to customer approval for this form.

1.6.2 Validater

The validater normally implements data integrity rules and business rules. Data integrity means the data has acceptable characters in it. A simple example being numeric data usually doesn’t include non numeric characters. Business rules would be verifying a value calculated during the process or a limitation rule like “A user cannot select more than one resource per request”. So I have defined two specific validation objects to do the specific type of validations, the “Business Rules” object and the “Valid Data Type” object. Now validations may be distributed across the different layers in an application. For example validating data types may happen only at the client in case of a Windows forms application deployed on a LAN. But the business rules would usually happen at the database tier and business tiers (if any). So while estimating the effort for the “Validater” object, remember that it could be used by different layers. Depending upon the form or set of forms, there could be more specific type of validater classes to be developed.

The (valid) validations I can think of for the above requirements are,

• resource name is mandatory.
• requester's name is mandatory.
• evaluation reasons for accepting or rejecting a resource is mandatory.
• size restrictions for text box values.
• dates to be in suitable format and range.
• type of resource should match to a predefined value.

From my experience, it would take at least two man days (again) to provide these validations including design, coding, testing and customer approval.

For both 1.6.1 and 1.6.2, we have identified some of the possible things to be done during development and we haven't even finished our scoping and analysis as yet. So the chances of discovering what more has to be done keep increasing and that too at a very low level where it is easier to judge the effort involved. This is a simple and not so crude way to estimate the effort.

1.7 Who qualifies as a beginner?

For any estimating, scoping or analysis, work knowledge of all development phases play an important role. And the steps mentioned in this article would be easier to understand if one has experience in development, design and testing along with a couple of end to end projects behind them. The advantage of this approach is that you could estimate applications and modules even if you do not know any industry accepted means of estimation like function point analysis. And you get three for the price of one i.e. estimating, scoping and analysis can happen side by side. Think of this as an intermediate phase to becoming an analyst, architect or even project manager.

How to estimate a software project

Introduction

Let us get one thing straight. The only estimation I have done earlier is during my engineering days where I worked out quantities and rates for construction work. The key advantage then was that most of the design and specifications were finalized before the estimation began. If not, one could quote a vague figure called the 'accepted market rate', and then go on changing that figure [provided one had the skill set ;) to do so] as and when the design and specs were finalized.

For others with my kind of background, estimating a software project based upon a few discussions with the customer and stakeholders is nonsense. Estimating a software project is like estimating what it would take to invent something without knowing what that something is. Function point analysis and cocomo(?) is for geeks. Quite often, software estimates are way off the mark, and the end result being some geeks are then given pink slips.

And so, I did a sensible thing. I stayed well clear of estimating software projects. But situations change and it is getting more difficult to avoid this dumb task. The inability to estimate projects, resources, risks etc. also means inability to get perks, broaden our horizons, and rise up the geek ladder. Meanwhile, there are more mouths to feed, more financial commitments, more taxes to handle. And anyways, there is no point doing low level coding all your life. One should strive to reach a level where one can really screw things up.

Brass Tacks

Right then, enough of cribbing. It doesn’t pay. And my superiors are better at it. What I aim to do is to figure out a way to make estimation of a regular software project similar to estimating a regular engineering project. A typical engineering project estimate contains several parts as follows:

• Identifying the items of work.
• Fixing a unit for each item of work.
• Calculating the quantity of work.
• Calculating the rate for each item of work.
• Fine tuning the final cost.

The rate is the cost of resources involved per unit of work. The resources are usually:

• Man-hours.
• Materials.
• Tools and plants.
• Overheads.
• Profit margin.

The overheads involve:

• The establishment charges.
• Depreciation of tools and plants.
• Interest factor etc.
• Licenses, permits, taxes.

The same concept can be extended for estimating software projects. We start by identifying and describing items of work, then the units for the item, the quantity, and so on. Describing items of work can be fairly irritating form a techie point of view, thanks to its verbose nature. The rate part should look normal enough. Usually, overheads and profit margin [decided by authorized persons only ;)] are taken as a percentage. By now, many would be smirking and/or condemning this kind of an approach. The main defense in favor of this approach is that most engineering works have to last for years, the project durations range from months to years, and there are many non technical people who believe they know things better than engineers (in some case, it's true). Many engineering projects have critics ranging from politicians, journalists, lawyers, social workers, citizens, idiots, and even engineers. Engineering projects include the Egyptian pyramids, space exploration, or manufacturing paper clips. So, why can't engineering techniques be applied to software development - a field that includes engineers of software, hardware, computers, and networking, and where reliability, robustness, and scalability are required.

Identifying items of work

Okay, now for the first part. What does an item of work consist of? In business applications, this could be a workflow, sub workflow, or development of components or sub components. We also need to classify the items of work (i.e., identify types of work).

In the following example, I will create some categories of work in software projects. A typical classification tree could be as shown in the figure below:

We can continue working out more categories and subcategories, but for now, we will attempt to estimate within the categories shown above. All the items under hardware category and sub categories are easier to estimate as we can get the costing from their purchase/market value. The same applies to the operating systems, run time software, and tools. The workstation cost includes establishment charges like office space, electricity, water, air conditioning etc. Other costs like renting, licenses, work permits, and taxes for acquiring each item should be added as applicable. Some overheads and hidden costs are not reflected in the tree. These are usually estimated and added as either a lump sum cost or as a percentage of the overall cost.

The actual software development costing starts from the category 'Application'. Most business applications have several modules. A module is a feature in an application. Now, we start to identify each item of work for each of its categories.

The category 'Framework' provides the backbone on which all the other components in the application link to or depend upon to do common tasks.

The framework development could include the following items of work:

• Data access components
• Exception handling
• Logging
• Email/Fax
• Printing
• Data Export
• Services (web services, remoting, DCOM, COM+, application server etc.)
• Security (authorization, authentication, code access, encryption)
• Resource Files
• Deployment
• Miscellaneous (utilities, constants, enumerations)

The category 'Presentation' could include the following items of work:

• GUI (Forms and controls)
• Custom controls
• Validation
• Animation and Graphics

The category 'Business' could include the following items of work:

• Coding (for work flows and business requirements)
• Validating data
• Formulas and calculations
• Data manipulations
• Implementing business rules

The category 'Data formatter' is used to convert data into acceptable formats before sending and after receiving. The formats can be XML, value objects (an object that is used to carry data from tier to tier), and encryption.

The category 'Data storage' could have the following items of work:

• Database design
• Writing SQLs, procedures, triggers
• Indexing
• Performance tuning
• Flat Files (including text, XML, graphics, multimedia, etc.)

The Application itself is a category. In the category Application, an item of work is a work flow. A work flow itself may consists of other workflows and processes. The most common features when fixing a rate for an item of work are the expected amount of work to be done (GUI objects, lines of code, non private methods,) and expected complexity. This depends upon the experience of the bidding company, technology being used, and support available. The amount of work increases with the size of the workflow. If the workflow has a lot of rules, branches, sub workflows, and processes, it indicates complexity. Complex workflows should be broken down into simpler workflows. Therefore, the basis of estimation would be to develop as many workflows as possible and to put in the maximum number of details into the workflow. In case, developing all the workflows is not possible (often the case), then (the business analyst should be able to) map expected workflows to existing workflows so that estimation can be done with better accuracy. Trying to estimate a project without doing the workflows is practically impossible except in the case of static web pages.

Now that we have identified some of the items of work, we need to explain them in detail. Determine what exactly is going to be provided (and maybe even what is not being provided), the corresponding specifications, the cost of manpower, hardware, documents and other deliverables, overheads up to completion (or delivery). In software, this would also include the cost of testing, quality assurance, user acceptance testing, and warranties.

After describing an item of work, fix the unit for each item. For form development, the unit could be done as numbers (no.s). Note, the forms maybe further divided into categories depending upon the complexity and content in it. So, do not put all the forms into one single item of work unless all forms are similar to develop. In the Business category, we should identify the main business objects, components, or features, and categorize them depending upon the content and complexity. Again the unit for business category works could be no.s.

The database could be estimated based upon the number of database objects expected, and the complexity of the tables, views, SQLs, procedures, normalization, and level of data integrity required.

Once a workflow is done, it should be studied carefully to identify the items of work involved. Below are a set of workflows to request and provide a resource.

Categorization

Let us study the resource allotment workflow for different categories.

Category Data Storage

This requires resource details to be stored so that resources can be easily stored and retrieved. This involves a relation database management system. The database should contain tables to store resources based upon certain characteristics, say human resources, items, and documents. To retrieve these faster, they can be further categorized and have keywords associated with them. All these categories would themselves be stored in another table(s) and mapped to their parent categories.

The request for resource should be mapped to the resources found. Therefore, all requests are stored in a table and can be categorized based upon priority, impact, department/person placing the request, and availability of resource.

Finally, the different criteria for accepting or rejecting a resource should be recorded along with the department/person who accepted or rejected the resource, along with an explanation. The criteria for accepting/rejecting a resource could be stored in another table and also could be categorized.

To place requests, search and allocate for resources would require writing SQLs. By viewing the functionality of the screens (if prototypes are available) as well as the workflow itself gives a fair idea of the complexity of the SQLs to be developed.

So right away, we get an idea of what is required from the data storage point of view.

Category Presentation

The persons in charge of resource allocation would need to view the requests for resources. They should also be able to sort resources based upon the status of the request, date of the request, priority, impact, department, costing etc. This would help them decide how to handle each request. The resource in charge persons should be able to search for resources based upon categories and sub categories, keywords, status, location etc. Finally, a resource should be mapped to a request. Screens should be developed to display requests details, resource details, resources and requests mapping, search for requests and resources, etc. The display can be on WinForms, browser or console.

Category Business

The Business category usually contains the interfaces and business objects. The business object may perform calculations (say, time period can be calculated from date(s) provided), implementing business rules (like whether the particular department can be given a certain resource), sequence of calling the business methods, and interactions with the data tier.

In the resource allocation workflow, we could have business objects such as requester, resource manager, resource, and search engine. Each object required can be considered while estimating the cost of the workflow.

Category Data Formatter

The Data formatter ensures that the format of the data is correct. If a particular data were of type float, then the data formatter would convert the data passed to it into a float before assigning it. Else it would not allow the data to be assigned at all. In case of XML, it would ensure that the XML document is built as per some predefined format. The data formatter could also be part of the framework. A data formatter can also be thought of as an object to carry data from one tier to another.

Category Framework

The framework components required by the resource allotment workflow could consist of tier to tier communication, security features, custom components, libraries, resource files, data tier access, error handling, and possibly logging, email, fax, and third party interaction. The extent to which each of these would be developed should be considered after looking at the entire application. But for our item of work, we should take a fraction of the framework development cost into account. This is because the framework is a development requirement and not a business requirement. So, only consider the features of the framework that would be required for the flow and add an approximate cost to the rate.

Item of Work

Let us call the item of work as 'resource allotment'. Now that we have looked at the item of work with respect to different categories, it will be easier to describe it. A critical aspect is the labor or man-hours involved to develop the workflow. Most companies have their own metrics on the development cost based upon efforts put into previous projects. Based upon the previous project metrics, they calculate the number of man-hours.

Now we put the item of work into an estimation table as shown below:

Serial No.	Item Code	Description	Rate (INR)	Unit	Qty	Amt
1	wf_res_01	Developing and deploying the work flow resource allotment including the cost coding for sub workflows, components, display screens, inserting, modifying, deleting and retrieving data, passing data between client systems, servers, databases and external services, validating and formatting data, implementing business rules, including database design, application design, quality assurance, unit/integration/black box/load/user acceptance testing, hardware/software tools/operating-systems/compilers/labor/ licenses/permits/shipping/ deliverables.	60000.00	No.s	1.00	60000.00

For an inexperienced estimator, it would be difficult to fix the cost for the item of work shown in the table above. The best way is to describe the item of work with as many details as possible, and then try to arrive at the cost of each detail. Take the help of experienced persons (architects, managers, developers, testers, technical writers. etc.) to identify more details (including hardware, software, man hours, overheads) and their corresponding costs. Then simply add it up and compare the final figure against the cost of similar work done earlier.

Parting Note

Unlike engineering projects where many works are repetitive and the average output of a machine or person is easier to work out, in software projects, there are usually wi(l)der fluctuations. The risk factor, impact factor, changes, even miscommunications are more, and affect the costing greatly. All these issues have to be factored into the cost along with the expected profit margin.

Software Project Cost Estimates Using COCOMO II Model

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 eighties. The COCOMO II 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:

Effort (in person-months)     =    a x KSLOCb

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.

If you have project source code, and some project details, this is all you need to make a simple cost estimate. Surely, you don’t 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 application’s 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 result of separate SLOC count in all project folders is the following:

	Folder	Total SLOC
1	SQL Files	414
2	Java DB Provider Files	345
3	Java Servlet	156
4	Web Files	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 I’m wrong!) the latter choice, and therefore, I would cover in this section one of the specific tools for making COCOMO II estimates.

I’ve 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 Costar’s costar_dbprovider.cst project file for this project in cocomo2.zip), I’ve created the main (root) component and four subcomponents:

1. db_provider
2. servlet
3. database_scripts
4. 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:

PCAP [high=0.88]x LTEX[low=1.09]x PLEX[low=1.09] =1.04 ~ 1

• There was no separate role for an analyst. This factor decreases team’s 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 small–size or even intermediate–size 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:

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	Sample Project Value	Description
1	DATA	high	Database size.
2	CPLX	nominal	Product complexity.
3	TIME	nominal	Execution time constraint.
4	STOR	nominal	Main storage constraint.
5	RUSE	nominal	Required reusability.
6	DOCU	nominal	Documentation match to life-cycle needs.
7	PVOL	nominal	Platform volatility.
8	SCED	very high	Scheduling factor.
9	RELY	nominal	Required reliability.
10	TOOL	nominal	Use of software tools.
11	APEX	nominal	Application experience.
12	ACAP	low	Analyst capability.
13	PCAP	high	Programmer capability.
14	PLEX	low	Platform experience.
15	LTEX	low	Language and tools experience.
16	PCON	nominal	Personnel continuity.
17	SITE	nominal	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	Sample Project Value	Description
1	PREC	nominal	Precedence.
2	PMAT	CMM Level I (upper)	Process maturity.
3	TEAM	nominal	Team cohesion.
4	FLEX	nominal	Development flexibility.
5	RESL	little (20%)	Architecture and risk resolution.