Softstar Systems

COCOMO and COSYSMO Estimation Tools

Frequently Asked Questions

Home

SystemStar Guided Tour

SystemStar Features

SystemStar Facts

Download Demo

Price List

Training

COCOMO Overview

COCOMO History

COCOMO Cost Drivers

COCOMO II Features

Function Points

Incremental COCOMO

Calibration

COSYSMO Overview

COSYSMO Features

Links

FAQ

What's New

Contact Us


Table of Contents

  1. What's the definition of a Person-Month?
  2. Should I estimate two related projects together?
  3. How can I estimate the value of my software company?
  4. How do I calibrate SystemStar to my environment?
  5. How many different inputs are there?
  6. When should I use the Incremental Development model?
  7. How should I model a Rapid Prototyping project?
  8. Does COCOMO II replace traditional COCOMO?
  9. What version of Function Points do you support?
  10. What do I use Calico for?
  11. Should I use the Detailed calculations?
  12. How did SystemStar get this answer?
  13. How should I model reuse of code?
  14. Which SystemStar model should I use?
  15. I've got old WICOMO estimates. Can you help me convert them?
  16. Can I compare one SystemStar estimate to another?
  17. How do I get started?
  18. When will the Linux and Mac versions of SystemStar be released?
  19. Is COCOMO the best software estimation model?
  20. Can Excel and SystemStar trade data?

1. What's the definition of a Person-Month?

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.

Back to Top

2. Should I estimate two related projects together?

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.

Back to Top

3. How can I estimate the value of my software company?

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?

Back to Top

4. How do I calibrate SystemStar to my environment?

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.

Back to Top

5. How many different inputs are there?

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.

Back to Top

6. When should I use the Incremental Development model?

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.

Back to Top

7. How should I model a Rapid Prototyping project?

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.

Back to Top

8. Does COCOMO II replace traditional COCOMO?

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.

Back to Top

9. What version of Function Points do you support?

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.

Back to Top

10. What do I use Calico for?

We like to think of SystemStar and Calico as a suite of tools. You get Calico with every purchase of SystemStar.

SystemStarEstimation
CalicoCalibration, 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:

Back to Top

11. Should I use the Detailed calculations?

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.

Back to Top

12. How did SystemStar get this answer?

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.

Back to Top

13. How should I model reuse of code?

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.

Back to Top

14. Which SystemStar model should I use?

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.

Back to Top

15. I've got old WICOMO estimates. Can you help me convert them?

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.

Back to Top

16. Can I compare one SystemStar estimate to another?

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:

Back to Top

17. How do I get started?

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.

Back to Top

18. When will the Linux and Mac versions of SystemStar be released?

There's no release currently planned.  Send email to let us know what you'd like to see.

Back to Top

19. Is COCOMO the best software estimation model?

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.

Back to Top

20. Can Excel and SystemStar trade data?

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.

Back to Top