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 SystemStar lets you redefine the number of Hours per Person-Month to match your organization's definition, so this is taken care of automatically by SystemStar.
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 two separate projects. The diseconomy of scale won't apply.
But, if the two 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 SystemStar lets you decompose an estimate into any number of components and subcomponents, so you can model your estimate as having two major components if you like. Each of those components might have dozens (or hundreds) of subcomponents.
There are many ways to estimate the value of a software company, but none of them are very good. SystemStar 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?
Out-of-the-box, SystemStar 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 SystemStar. Calico takes a description of your completed projects as inputs, and calibrates the COCOMO equations to match your environment. You can arrange for SystemStar 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 SystemStar 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 SystemStar 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 SystemStar 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 two or more increments, use the Incremental Development model to do the estimates. Using SystemStar, 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 SystemStar, 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 SystemStar, 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 SystemStar'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.
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, COCOMO II makes more sense.
When in doubt, use 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 SystemStar can be customized, one way or another. Using the Calico tool included with SystemStar, 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.
We like to think of SystemStar and Calico as a suite of tools. You get Calico with every purchase of SystemStar.
| SystemStar | Estimation |
| Calico | Calibration, Tuning, Tweaking the model |
By now, you know that SystemStar 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 SystemStar. 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 SystemStar 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 SystemStar 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 a variety of different models with SystemStar. Of course, you can use Calico to make your own versions.
If you're new to COCOMO and SystemStar, 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.
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 three models built into SystemStar 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.
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 SystemStar doesn't support that feature.
We can help customers convert the WICOMO estimates into SystemStar estimates.
Yes. You can have any number of SystemStar 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 SystemStar 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 SystemStar 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 SystemStar and uses it extensively for their internal estimation projects. What better endorsement?
To do a good job estimating, you should use two 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 two 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. SystemStar is much less expensive than 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 SystemStar reports can export their data to Excel. They can even do it in real time, so that as you change parameters in SystemStar, all of your related spreadsheets change. So, if none of the built-in reports & graphs show what you want to see, you can use Excel as a fancy report writer/graphing tool.
Importing data to SystemStar 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 SystemStar (sending the data), and harvests the results from a SystemStar report, and places the SystemStar results into the spreadsheet. The macro assumes that SystemStar is installed in the "Costar 7" directory or "Costar 7 Demo" directory. LATER: This is an old old spreadsheet, made for Costar -- you may need to improvise to make it work.
You can embellish this simple macro into something that is more useful. Contact us if you need more details about the SystemStar 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.