You can download a Costar
7.0 demo nowHome | COCOMO Overview | Costar Overview | COCOMO II
Training | Great Links | Costar Guided Tour
You can download a Costar
7.0 demo now
To learn about Costar before you download it, check out the Costar Guided Tour.
A Person-Month is one month of effort by one person. In the olden days, a Person-Month would have been called a Man-Month or a Staff-Month.
In standard COCOMO, there are exactly 152 hours per Person-Month. In your organization, you might have a definition that differs from the standard by 10% to 20%.
Luckily, the Calico program that is included with Costar lets you redefine the number of Hours per Person-Month to match your organization's definition, so this is taken care of automatically by Costar.
If you're doing the COCOMO calculations by hand, or using one of the free versions of COCOMO, you must make this adjustment manually, or your estimates will be wrong.
It depends.
Consider the form of the estimating equations (as explained in the COCOMO Overview). The Effort Equation has an exponent greater than 1, indicating that software projects experience a diseconomy of scale. That reflects the common experience that a 10,000 line project will take more effort than 10 projects of 1,000 lines each. On a larger project, more effort is spent on communication and organization, rather than on technical work.
So, if your projects will proceed without much interaction between them, you should estimate them as 2 separate projects. The diseconomy of scale won't apply.
But, if the 2 projects will be coordinated with each other, requiring a lot of contact and interaction with each other, you should consider them as pieces of a single large project, and make a single estimate that includes both.
Note that Costar lets you decompose an estimate into any number of components and subcomponents, so you can model your estimate as having 2 major components if you like. Each of those components might have dozens (or hundreds) of subcomponents.
Costar supports the COCOMO Reuse & Adaptation calculations. After reviewing a sample of your code, you should be able to supply the following figures for your system:
Let's work an example assuming the system is 1 million Source Lines of Code (SLOC).
Let's assume that you'll change just 2% of the design.
Let's assume that you'll change 5% of the code.
We'll assume that the testing will be just as thorough as it was during the original development.
Using the Costar Reuse Tab, you'll arrive at an Equivalent SLOC (323,000 in this example). That's the figure that will be pushed through the standard COCOMO estimating equations to make estimates for your project.
When you try this, you may be shocked at the size of the effort predicted. There are a couple of factors working in your favor, though. You can probably set the Precedentedness scale driver to "Thoroughly Familiar" and Architecture/Risk Resolution to 100% because is a well understood problem being undertaken in a familiar environment. You can probably assume that the Complexity cost driver is very low, and that the Applications Experience cost driver is very high -- setting these 2 cost drivers will trim the estimated effort by over 40%.
There are many ways to estimate the value of a software company, but none of them are very good. Costar and COCOMO can help you estimate the value of the software itself (which might be much less than the value of the company). The simplest approach is to estimate the "replacement cost" -- what would it cost someone else to duplicate your product from scratch?
The folks at The Corum Group are experts at valuing software companies.
Out-of-the-box, Costar estimates pretty well for most organizations, but in an ideal world, you'd tune it to match your organization's history.
Here's the hard part: collect data describing completed projects (size, effort, duration, cost drivers). You'll need at least half a dozen data points to get reasonable results.
Here's the easy part: type your data into Calico, select a style of calibration, and press Enter. Calico is our COCOMO calibration tool -- it's included with every purchase of Costar. Calico takes a description of your completed projects as inputs, and calibrates the COCOMO equations to match your environment. You can arrange for Costar to automatically use your new equations instead of the standard estimating equations.
No, Calico doesn't use magic -- it turns out that all you need is a linear regression.
Somewhere between 1 and 1,000,000 different inputs.
At a minimum, you need to describe your project with a size in Source Lines of Code (SLOC) or Function Points, so you need at least one input (!).
But, for each component, there are 50 to 100 different items you can set (costs, cost drivers, maintenance cost drivers, etc.), and in Costar 7.0 you can create thousands of components, so in theory, there are hundreds of thousands of possible inputs.
In practice, you'll probably set only a handful of parameters for each component.
Subcomponents in Costar can inherit attributes from their parent components, so if you set the Programmer Capability cost driver to Very High for the top level component, that value will be inherited by all subcomponents (unless overridden by a different value in a particular subcomponent). That simplifies life.
They key word here is "model". You use Costar and COCOMO to create a model of a software project, then you press a button and the program does the calculations.
If you plan to develop your software in 2 or more increments, use the Incremental Development model to do the estimates. Using Costar, it's simple to assign a component to any one of your increments -- and if you want to switch back to a single increment, just assign all of your components to increment 1.
You could model that as a series of small increments, where each increment adds more functionality to the product.
We've generalized the usual Incremental COCOMO a little bit to handle this sort of situation. In Costar, you can use the Phasing Worksheet to describe how each of your increments overlaps with the other increments (you may have several going on at once).
In the traditional "waterfall" model of a software project, we pretended that all of the requirements and design was done first, before we started any coding and testing.
In a project with a lot of prototyping and concurrent development, you won't be doing all of the Requirements and Product Design at the beginning of the project -- you'll be doing some of each throughout the project as you learn more about what it is you're developing. In Costar, you can use the Phasing Worksheet to model that approach -- you can specify that you'll be doing some Requirements and Design work at the beginning of every increment -- not just before the first one.
You can also use Costar's Increment Breakage worksheet to describe the amount of code you'll be throwing away in each increment (the "breakage"). There will be some breakage because you'll probably have to abandon some ideas and features as you home in on what it is you're trying to build. If the breakage is a large number (say, 50%), you've slipped over the edge from Rapid Prototyping to Rabid Prototyping.
You should use COCOMO II for most of your new projects.
COCOMO 81 is still the best approach for some software projects. If you're using a fairly traditional approach, and using a 3GL (third generation language), such as C, Fortran, or Cobol, the original COCOMO will give you good results. If your development tools and processes haven't changed much in recent years, COCOMO 81 might be the right model for you.
If you're using more modern tools, a new development process model, a 4GL language, or tools like Visual Basic, Delphi, or Power Builder, you might find that COCOMO II makes more sense.
When in doubt, try to model your project using both the traditional COCOMO and COCOMO II.
Do you remember the episode of M*A*S*H in which Col. Potter refers to the Great War, and says "...that was before we knew enough to start numbering them..."?
Well, we use the original Albrecht definitions, before any names or version numbers were attached to Function Points.
But, just about everything in Costar can be customized, one way or another. Using the Calico tool included with Costar, you can change all of the FP weights, and invent your own version of function points. Just don't tell the people at IFPUG about it.
The Post-Architecture Model and the Early Design Model have been released. The Applications Composition Model is still under development at USC.
Our Costar 7.0 for Windows supports the most recent changes to COCOMO II.
We like to think of Costar and Calico as a suite of tools. You get Calico with every purchase of Costar.
| Costar | Estimation |
| Calico | Calibration, Tuning, Tweaking the model |
By now, you know that Costar is used to model & estimate a software project.
Calico is used to calibrate the COCOMO equations to your local environment, based on projects you've already completed. You can do periodic Calico calibrations as you complete more projects, and feed the revised equations into Costar. You might even have multiple calibrations -- perhaps one for MIS applications that you do in Cobol, and another that you use to estimate your 4GL projects. Most Costar users never use Calico, but we recommend it to everyone who's collected enough data.
Calico lets you change any of the thousands of numbers that control a COCOMO estimate, including:
COCOMO II is defined using intermediate calculations, but the COCOMO 81 models let you choose between the Intermediate mode and the Detailed mode.
The two modes are equally fast, but the Detailed mode use phase-dependent effort multipliers for the cost drivers. For example, The Programmer Capability (PCAP) cost driver set to Very High in COCOMO 81 has an effort multiplier of 1.00 for the Product Design phase, but an effort multiplier of 0.65 for the Code & Unit Test phase. That means that the quality of the programmers doesn't have an impact on the design, but will save you a lot of effort in the programming phases.
If you try to do the COCOMO calculations by hand, but can't match the Costar results, consider these ideas:
Call us if you can't resolve the problem.
If you are reusing code that already exists, you should use the COCOMO adaptation equations.
If you're writing code that will be reused, you should use the RUSE cost driver (available in all of the models except COCOMO_85).
The idea behind the RUSE cost driver is that it is more expensive to develop code that is designed and documented to be reused -- it's harder than simply making a special purpose version of the code. The payoff only comes when you use the code a second and third time. Which explains why reuse of code is the exception rather than the rule -- nobody has an incentive to make life easier for the next generation of developers. Usually, we're too busy trying to ship a product.
We include 13 different models with Costar 7.0. Of course, you can use Calico to make your own versions.
If you're new to COCOMO and Costar, you should probably use one of these Post-Architecture models for your estimating:
Select the model that most nearly matches your development environment. The Waterfall model has a traditional set of software development phases; the MBASE model is comparable to the Rational Unified Process.
The COCOMO II Early Design models are intended for use when very little is known about the project you're estimating. Instead of the full complement of 17 cost drivers available in the Post-Architecture models, the Early Design models have 7 composite cost drivers. Otherwise, the models are the same.
There are also four COCOMO II.1997 models built into Costar 7.0. Use these models only for compatibility with existing estimates -- otherwise, you'd be better off using a COCOMO II.2000 model.
You may see references in the literature to COCOMO II.1998 or COCOMO II.1999. COCOMO II.1998 was renamed to COCOMO II.1999 and then to COCOMO II.2000, so all of those models are identical.
These five models built into Costar are variations on the original COCOMO 81 model;
COCOMO_85
This is almost identical to the COCOMO defined in Software Engineering Economics. It simply has an extra setting for the TURN and TOOL cost drivers.
If you want to use the most standard version of traditional COCOMO, use this model.
COCOMO_87
This database uses the COCOMO 81 equations, but has 4 new Cost Drivers added: VMVH, VMVT, SECU (Security), and RUSE (Reuse). Two of the standard cost drivers have been updated -- SCED and TOOL.
This is like the COCOMO_87 model, except that we assume that you're using Ada as a programming Language. The RELY cost driver has changed to reflect that it's easier to create reliable software in Ada. The CPLX cost driver has changed to reflect that it's easier to develop complex software in Ada. The LEXP cost driver penalizes you for being an inexperienced Ada programmer.
Use this model if you're developing software in the traditional fashion, but you're writing in Ada.
APM_88
This model has a different form for the equations, new tables, new cost driver values, etc. It assume that you've adopted a new way of developing software -- the Ada Process Model (APM).
Use this model after you've read the relevant papers. This is considered an experimental model, so you should use it in parallel with one of the more conventional models.
It's interesting to compare this experimental model to the form of the COCOMO II model. The major feature introduced with the Ada Process Model, and carried forward into COCOMO II, is the idea that there are a set of Scale Drivers that modify the exponent in the estimating equation. The original COCOMO models only have a single factor, the Development Mode, that changes the exponent.
Sure. Version 1.00 of Costar could read the old WICOMO estimates, but there hasn't been much demand for that lately, so the latest Costar doesn't support that feature.
We can help customers convert the WICOMO estimates into Costar estimates.
Yes. You can have any number of Costar estimates in memory at the same time, and you can use the Comparison Report to compare up to 3 of them side-by-side.
We want you to develop many version of your estimate. You should feel free to try different experiments as you refine the model of your software project. Here are the sort of experiments you might try:
Read the Costar Overview , the COCOMO Overview, and the page about Advanced COCOMO.
Next call us, or send email requesting a demo disk. Better yet, download the demo!
Download a demo of Costar
7.0 for Windows.
If you're ready to place an order, check the Price List, and then contact us.
There's no release currently planned. Send email to let us know what you'd like to see.
We like it, and it is the most popular model.
But you don't need to take our word for it -- COCOMO is so good at estimating, that one of our major competitors (a Fortune 100 company) has a worldwide license for Costar and uses it extensively for their internal estimation projects. What better endorsement?
To do a good job estimating, you should use 2 or more independent techniques. One of them must be COCOMO. Even if you don't buy our product, you should use COCOMO for your estimating. You can do small estimates by hand if you need to, or get a simple, free, version from USC, but you ought to use COCOMO.
You have a lot of choices for your second technique. We have a number of competitors -- call us and we can recommend our favorites (most of them will suggest that you use 2 or more techniques, too). The best choice would be an estimating approach that differs significantly from the COCOMO technique, so that you examine your project from more than one point of view.
It's easy for us to recommend that you talk to our competitors. Costar is much less expensive then their products, so we think you'll be back to talk to us. Ask to see their Price List.
"Expert Judgment" is an acceptable technique. If you have experienced estimators that can give you good results, use them.
All of the Costar reports can export their data to Excel. They can even do it in real time, so that as you change parameters in Costar, all of your related spreadsheets change. So, if none of the 18 built-in reports & graphs show what you want to see, you can use Excel as a fancy report writer/graphing tool.
Importing data to Costar is a bit more tricky. Click here to download an Excel spreadsheet that does just that. It has a macro that collects data from the spreadsheet, executes Costar (sending the data), and harvests the results from a Costar report, and places the Costar results into the spreadsheet. The macro assumes that Costar is installed in the "Costar 7" directory or "Costar 7 Demo" directory.
You can embellish this simple macro into something that is more useful. Contact us if you need more details about the Costar command language.
By the way, when you read the spreadsheet into Excel it will warn you about the presence of a macro -- that's normal in this case.
COCOMO Overview | Source Line of Code (SLOC) | The Development Mode
Basic COCOMO | Intermediate COCOMO | Detailed COCOMO
Ada COCOMO | Incremental COCOMO | Function Points | COCOMO II
Costar Overview | Using Costar
Training | Great Links | Home
Copyright © 1986-2005 Softstar Systems All rights reserved.