COSMIC is a software sizing methodology. It is applicable to business, real-time and infrastructure software at any level of decomposition (from a whole software system down to a single re-usable component or a user story). It is independent of the technology or processes used to develop the system. It is an ISO standard. It is a refined improvement over its predecessors (IFPUG and Mark II FP). The unit of size is the COSMIC Function Point or CFP
COSMIC Function Points can be used to :
- Estimate or measure software size
- Estimate project effort
- Estimate project duration
- Estimate project quality achievement
- Improve requirements
- Control scope creep
- Assess the value a software asset
- Estimate maintenance and replacement costs
- Improve decision making
- For fixed scope contracts
- and more..
Based on Principles
The COSMIC Function Point sizing method of measuring software requirements is based on two main principles:
1. The ‘Software Context Model’
Defines the software to be measured
- Software is bounded by hardware and typically structured into layers.
- The scope of any piece of software to be measured shall depend on the purpose of the measurement and shall be confined wholly within a single layer.
- The functional users of a piece of software to be measured shall be identified from its Functional User Requirements (FUR) as the senders and/or intended recipients of data to/from the software respectively.
- A precise COSMIC size measurement of a piece of software requires that its FUR are known at a level of granularity at which its functional processes and sub-processes may be identified.
- An approximate COSMIC size measurement is possible if its FUR are measured at a high level of granularity by an approximation approach and scaled to the level of granularity of the functional processes.
2. The ‘Generic Software Model’
Generic concepts applicable to all software
- A piece of software interacts with its functional users across a boundary, and with persistent storage within the boundary.
- The FUR of a piece of software can be mapped into unique functional processes.
- Each functional process is started by its triggering Entry data movement. The data group moved by the triggering Entry is generated by a functional user in response to a triggering event.
- A functional process shall include at least one Entry data movement and either a Write or an Exit data movement. There is no upper limit to the number of data movements in a functional process
- Each functional process consists of sub-processes, data movements (DMs) and data manipulations.
- As an approximation for measurement purposes, the COSMIC method assumes that the functionality of any data manipulation is accounted for by the data movement with which it is associated.
- There are four data movement types, Entry, Exit, Write and Read.
- A data movement moves a single data group, which consists of a unique set of data attributes that describe a single object of interest.
Three Steps to Counting Cosmic Function Points
1 Measurement Strategy – Determine the purpose of the measurement as per the Software Context defined above
e.g. are we measuring an entire application or just a single component / layer. Who are the functional users interacting with the software.
2 Determine the parameters of the ‘Generic Software Model’ from the Functional User Requirements (FUR)
- Triggering Events
- The Functional Processes
- Objects of Interest (and Data groups)
- Data movements
3. Count the Data Movements
For a new application: count the new Data movements (DMs)
For system modifications : Add the new DMs , changed DMs and removed DMs.
And that’s it, the sum of the DMs is the CFP total!
|Functional Process||A set of data movements … for the software being measured, that is unique within those FUR and that can be defined independently of any other functional process in those FUR.
Each functional process starts processing on receipt of a data group moved by its triggering Entry data movement.
The set of all data movements of a functional process is the set that is needed to meet its FUR for all the possible responses to its triggering Entry.
|Functional User||the ‘senders or intended recipients of data’ (can be human or connected systems or devices such as sensors)|
|Functional User Requirement (FUR)||Statements of functional requirements, eg. software specification or user stories.|
|Object of Interest||any ‘thing’ (physical or conceptual) in the world of the functional user, about which the software being measured must process or store/retrieve data|
|Data Group||consists of one or more data attributes that all describe a single object of interest|
|Triggering Event||Each functional process is started by its triggering entry data movement. The data group moved by the triggering Entry is generated by a functional user in response to a triggering event.|