Vision
Project size estimation using Cosmic FFP
April 2005
Introduction
Estimating the functional size of software is challenging. Several researches found initial estimations to be accurate within a 50% - 400% range. One way to measure the size of software is to do expert estimation, which is another way of saying someone gives an educated guess based on past experiences. This can work out great or not, depending on the skills and experience of the estimater. However, using this approach it’s easy for outsiders to influence the outcome (“Does it take that long? Really?”). Also, if the estimation is wrong it’s very hard (if at all possible) to detect were things went wrong. Another way to measure project size is to use Function Points Analysis (FPA), which is fine, although several sources claim FPA is more complex then it needs to be. The approach which is discussed in this article is called Cosmic Full Function Points (also called Cosmic FFP or just Cosmic) which offers a structural approach to software estimation. One of the advantages of Cosmic is it’s ease of use. This article gives a general high level overview of Cosmic.
Cosmic
Cosmic has been around since 1997 and stands for Common Software Measurement International Consortium. Cosmic is a voluntart initiative of an international group of software measurement experts (see http://www.cosmicon.com). Cosmic can be used to estimate project size or measure productivity. Cosmic can even be used to say something about quality, albeit indirectly.
The Cosmic measurement method is applicable to software belonging to the following domains:
- Business application software.
- Real-time software.
- Hybrids of the above.
The Cosmic model is not designed, and not suitable, for the following types of software:
- Software which is characterized by complex mathematical algorithms.
- Games.
- Streaming software (audio, video).
Cosmic can be separated in three different phases:
- Preparation.
- Mapping.
- Measurement.
During the preparation phase the goals of the project are established (for example, “we want to know how much it costs to build this system”). Firstly, the viewpoint of the estimation is established. There are two viewpoints within Cosmic: the end user measurement viewpoint and the developer measurement viewpoint. There are differences between both viewpoints, but for this article it suffices to say that most Cosmic users use the end user measurement viewpoint. Also, the scope of the project is determined.
The mapping phase is based on information provided by the functional user requirements. During this phase the first step is to establish software layers. Each software layer operates on a specific level of abstraction based on the functional exchanges between software modules. Next, the boundary of the software system is determined. It’s elemental to know which items are parts of the software (inside the boundary) and which are not (outside the boundary). After that software users are identified. Examples of software users are human beings, devices or other software. After that, functional user requirements or processes are identified. The estimation process delivers estimations per process. Finally, objects of interest and their attributes are determined. Objects of interest are the key players interacting within a functional process.
The final phase of Cosmic is the measurement phase. In the mapping phase a set of functional processes is established. Each of those processes encompasses a unique set of data movements or data manipulations. The Cosmic FFP software model distinguishes four types of data movements:
- Entry, data is moved from the user across the process boundary inside the functional process.
- Exit, data is moved from inside the functional process across the process boundary to the users.
- Read, moves data inside the process from a persistent data store (for example, a database).
- Write, moves data from inside the process to a persistent data store.
At this point, we’re almost there. We can count the number of data movements within a process. Then, the Cosmic FFP measurement principle applies which states that the functional size of software is directly proportional to the number of data movements. Each data movement equals a Cosmic Functional Size Unit (Cfsu). So if a functional process has a total of 15 Cfsu’s and each Cfsu stands for 10 hours, the software system takes 150 hours to build. Of course, determining the number of hours it takes to implement a Cfsu remains tricky, as this depends on many factors, like project complexity and the technology used to implement the software. Experience solves this problem. By measuring project sizes in Csfu’s it’s relatively easy to gain insight of the productivity within your company. At this point, you’ve seen a high level overview (albeit somewhat simplified) of Cosmic.
Conclusion
Cosmic FFP is easy to use and a viable alternative when it comes to estimating software size. When used right, it’s a great way to estimate software size, productivity and quality. Youy could even compare your findings with other companies. But the great thing is, when applied wrongly (but consistently) it’s still a very useful methodology. Project teams can still use the methodology and compare results within team boundaries. However, applying Cosmic in the wrong way makes it hard to compare results outside the team or even compare results between companies.