COSMIC measurement process
The COSMIC measurement process consists of three phases:
- the Measurement Strategy phase, in which the purpose and scope of the measurement are defined. Then apply the Software Context Model to unambiguously define the software to be measured and the required measurement.
- the Mapping Phase. Apply the Generic Software Model to the Functional User Requirements (FUR) of the software to be measured to produce the COSMIC model of the software that can be measured.
- the Measurement Phase, measure actual sizes.
The relationship of the three phases of the COSMIC method is shown below:
1 – The Measurement Strategy Phase
In this and subsequent pages, the first use of a COSMIC keyword is given in bold. Formal definitions of the keywords are given in Part 1 of the Measurement Manual (‘MM’) which gives the principles and rules of the COSMIC method, with many examples in Part 3 . This Introduction only has informal definitions.
a) Why a ‘strategy’?
It is necessary to agree and document the purpose of the measurement and various other parameters with the measurement sponsor so that in the future everyone will understand the measured size and how it may be used.
In practice only a few recurrent ‘patterns’ of parameters will be needed for the different types of software that will have to be measured in an organization. See Part 3a ‘Standard Measurement Strategy Examples’ for the most common patterns and their uses.
b) The five key strategy parameters to be determined
- The purpose of the measurement. The purpose helps determine all the following parameters.
- The scope of the piece(s) of software to be measured. A project might have to deliver several pieces of software, or the functionality to be measured might be restricted in some way. What’s included in the functionality and what’s excluded?
- The level of decomposition of the piece(s) of software to be measured. Different levels would be, for example, a ‘whole application’, or one of the primary components of a distributed system, or a re-usable component in a SOA architecture.
- The functional users of each piece of software to be measured. These are the humans or ‘things’ (hardware devices or other pieces of software) that are the intended senders or recipients of data to/from the software being measured. It is the functionality they ‘see’, that will be measured;
- The layer(s) of the software architecture in which the software resides. A piece of software to be measured must be confined to one layer.
Documenting these parameters for each measured size will ensure that in the future the sizes will only be compared and used on a ‘like-for-like’ basis.
c) Software ‘layers’
The term ‘layer’ is used in various ways in the software industry. (Sometimes ‘n-tier’ is used instead of ‘n-layer’.)
The figure below shows that the Application Layer may be sub-divided into other layers, dependent on the ‘view’ of the software architect (and consequently of the functional users of the software to be measured (see the following examples).
d) Before starting to measure
It’s very important to agree what artefacts of the software are available that can be used to determine the FUR to be measured. In practice the available artefacts may not supply exactly the information needed for any FSM measurement, so the measurer usually has to make some assumptions when deriving the FUR. It is best to consult an expert in the requirements of the software to be measured to help with understanding the software so that the measurement is as accurate as possible.
Some examples of the problems typically faced are:
- If a size measurement is needed early in the life of a project, the requirements may not yet have been documented in the detail needed for an accurate COSMIC measurement. For these situations, variants of the standard COSMIC method can be used to measure an approximate size;
- Sometimes software requirements are defined at a ‘high-level’ and then defined at increasingly detailed ‘lower’ levels, called levels of granularity. To ensure comparability, sizes must be measured at the standard level of granularity of ‘functional processes’ (see further below). If necessary, a variant for approximate size measurement can be used to scale from a size measured at a higher level of granularity to the standard level;
- Sometimes a size must be measured of an installed system for which the requirements no longer exist. In these situations, the measurer will need to ‘reverse engineer’ from the available artefacts, e.g. screens, user documentation, reports, user interfaces, etc. to determine the FUR.
Several COSMIC Guidelines describe how to derive or analyze FUR for different types of software or development methods. They are available for free from the Knowledge base.
2 – The Mapping Phase
A discussion of the elements of the model and of the mapping process follows.
a) The principles of the Generic Software Model
- A piece of software interacts with its functional users across a boundary, and with persistent storage within this boundary.
- A functional process consists of sub-processes called data movements.
- There are four data movement sub-types, Entry, Exit, Write and Read. A data movement sub-type includes any associated data manipulation.
- A data movement moves a single data group.
- A data group consists of a unique set of data attributes that describe a single object of interest.
- Each functional process is initiated by a triggering event, detected by a functional user and which in turn initiates a data movement called the triggering Entry.
- The functional size is based on the types of the elements used for measurement, not on the number of their occurrences.
- The size of a functional process is equal to the number of its data movements, where one data movement has a size of 1 COSMIC Function Point.
- The size of a piece of software is the sum of the sizes of the functional processes within the scope of the FSM.
- The size of a modified piece of software is the sum of the sizes of the functional processes modified, added and deleted.
b) A key relationship: events / functional users / functional processes
The task of software is to respond to events that occur in the world of its functional users. A functional user informs software that an event has occurred by sending a ‘data group’ pertaining to the event. The software must do something useful for the functional user(s) that have an interest in the response to that event. This ‘something useful’ is a ‘functional process’. All software FUR can be expressed in terms of functional processes.
The boundary is the interface between the software being measured and its functional user(s).
An event causes a functional user to generate a message (a data group) that is moved by a ‘triggering Entry’ into its functional process, thus starting the functional process.
An event is ‘something that happens’. A triggering event has either happened or not happened; it cannot be sub-divided for the FUR of the software to be measured. Note that a single event might be detected by multiple functional users of the same or different pieces of software (e.g. an earthquake detected by multiple sensors); a functional user of one piece of software may detect many types of events (e.g. humans interacting with software).
c) The structure of FUR: functional processes and data movements
The structure of FUR, i.e. their decomposition into functional processes and their data movements is very important. Correctly identifying functional processes is the most important step of the Mapping phase. A functional process can have from 2 (minimum) up to ‘n’ data movements.
d) Accounting for data manipulation
The COSMIC method does not measure data manipulation because there is no generally accepted way of measuring data manipulation. Therefore it is assumed that each data movement can account for any associated data manipulation. This assumption has proven to be reasonable for all the practical purposes such as project performance measurement and estimating. Where the method cannot account adequately for data manipulation, the COSMIC measurement method has provision for local extensions to the method to overcome the limitation.
e) The four types of data movements
The Figure shows the four types of data movement and the data groups they move, their relationships with a functional process, the functional users and persistent storage:
Figure – The four types of data movements
Entries and Exits move a data group in and out of the software from/to functional users respectively.
Reads and Writes move a data group from persistent storage to the software, or vice versa, respectively.
f) Persistent storage
Persistent storage (shown in the Figure) is an abstract concept of the Generic Software Model. In the model, such storage is accessible by any software in any layer if it needs to store data or to retrieve stored data and this storing or retrieving is not delegated to a functional user. After a functional process has written some data on persistent storage, that ‘persistent data’, is available to other functional processes that need it or to another occurrence of the functional process that wrote it.
A consequence of this concept is that if an application that must store data or retrieve stored data is measured, ignore how that data is physically processed by software in lower layers or by the hardware. Just represent FUR that require data to be stored or retrieved by Writes and Reads respectively.
Functional users interact with the software to be measured via Entries and Exits.
g) Data movement, data group and object of interest
One Entry data movement can be distinguished from another Entry data movement by distinguishing the objects of interest about which data is moved. Similarly for Exits, Reads and Writes.
Any data movement moves a single data group that consists of one or more data attributes. All attributes in a data group describe the same one object of interest. An object of interest is any ‘thing’ (physical or conceptual) about which the software being measured must process or store data. If data that is moved from a functional user into the software describe two objects of interest, then identify two data groups and hence two Entry data movements. Similarly for Exits, Reads and Writes.
It is only necessary to identify the data attributes for measurement purposes in case of measurement of functional changes to software (discussed below). However, in other cases it may be helpful to distinguish different data groups and their objects of interest by examining the data attributes.
To help understand these concepts:
- Of data analysis methods, often used in the domain of business applications, entity-types found in Entity-Relationship Analysis, and the subjects of relations in 3rd normal form found in Relational Data Analysis will be objects of interest. But these analysis methods are usually only applied to the structure of stored data groups. For a COSMIC measurement, it is also needed to apply these same analysis ideas to distinguish data groups and hence the data movements in the input and output of functional processes.
- There is a one-to-one relationship between objects of interest and the object classes resulting from UML analysis, though they are not the same concept.
- In the domain of real-time software, it is NOT usually necessary to think about objects of interest. Often the functional user – e.g. a sensor – sends data about itself, i.e. the functional user ‘is’ object of interest. Similarly in business application software: if a human user enters an ID and a password in a logon process to identify himself/herself to a system, the human functional user is the object of interest of the data group entered.
h) Summary of the Mapping phase process
Assuming the available artefacts of the software to be measured are at the functional process level of granularity, we examine them to derive the concepts of the Generic Software Model. The steps of this process are:
- Identify the separate events in the world of the functional users that the software must respond to, i.e. the ‘triggering events’.
- Identify which functional user(s) of the software must respond to each triggering event by generating a data group that is moved by a triggering Entry.
- Identify one functional process for each triggering Entry.
- Identify any other Entries and all the Exits, Reads and Writes of each functional process needed to meet the FUR for all possible responses to the triggering Entry.
For the last step, it may be necessary, especially for sizing business applictions, to identify the data groups that are moved in each data movement and the objects of interest that the data describe.
3 – The Measurement phase
By the end of the Mapping phase, the measurer will have produced the concepts from the COSMIC Generic Software Model of the FUR of the piece of software to be measured. Now measure the functional size of the FUR of the software by applying the rules of the Measurement phase to this model.
The COSMIC measurement principle
The COSMIC measurement principle reads ‘the functional size of a piece of software is equal to the number of its data movements’. A COSMIC functional size is measured in the unit called ‘COSMIC Function Point’, abbreviated as ‘CFP’. 1 CFP is defined as the size of a single data movement (Entry, Exit, Read or Write).
Sizes can be measured at various levels of aggregation.
- The size of a functional process is equal to the number of its data movements
- The size of a piece of software is equal to the sum of the sizes of its functional processes
- The size of a piece of software can be derived from the size of its components provided the aggregation rules given in the Measurement Manual are followed
Size of required functional changes
The size of required functional changes to a piece of software are measured as follows:
- The size of a required functional change to a data movement (i.e. that must be added, modified or deleted) is measured by convention as 1 CFP. (‘Modified’ could mean any functional change to the data manipulation associated with the data movement and/or to any of the attributes of the data group moved.)
- The minimum size of a functional change to a functional process is therefore 1 CFP.
- The size of all the required functional changes to a piece of software is equal to the number of data movements that must be added, modified or deleted, summed over all functional processes.