b) For any functional process, the functional size of changes to its Functional User Requirements shall be aggregated from the sizes of the data movements that have been added, modified or deleted in the functional process to give a size of the change in units of CFP, according to the following formula.
Size (Change(functional processi)) =
Σ size (added data movements) +
Σ size (modified data movements) +Σ size (deleted data movements)
For more on aggregating functional size, see section 4.3.2. For measuring the size of the changed software, see section 4.4.2.
c) The size of a piece of software within a defined scope shall be obtained by aggregating the sizes of the functional processes for the piece, subject to rules e) and f) below
d) The size of any change to a piece of software within a defined scope shall be obtained by aggregating the sizes of all changes to all functional processes for the piece, subject to rules e) and f) below.
e) Sizes of pieces of software or of changes to pieces of software may be added together only if measured at the same functional process level of granularity of their FUR.
f) Sizes of pieces of software and/or changes in the sizes of pieces of software within any one layer or from different layers shall be added together only if it makes sense to do so, for the purpose of the measurement.
g) The size of a piece of software may be obtained by adding up the sizes of its components (regardless of how the piece is decomposed) and eliminating the size contributions of inter-component data movements.
h) Only one Exit shall be identified for all error/confirmation messages issued by any one functional process to a human functional user.
i) If the COSMIC method is extended locally (for example to measure some aspect of size not covered by the standard method), then the size measured via the local extension must be reported separately as described in section 5.1 and shall NOT be added to the size obtained by the standard method, measured in CFP (see further in section 4.5).
In addition to the actual measurements, recorded as in 5.1, some or all of the following attributes of each measurement should be recorded, depending on the measurement purpose and the desired level of comparability to other measurements, e.g. for benchmarking purposes.
a) Identification of the measured software component (name, version ID or configuration ID).
b) The sources of information used to identify the FUR used for the measurement
c) The domain of the software
d) A description of the architecture of layers in which the measurement is made, if applicable.
e) A statement of the purpose of the measurement.
f) A description of the scope of the measurement, and its relation to the overall scope of a related set of measurements, if any. (Use the generic scope categories in section 2.2)
g) The measurement strategy pattern used (COSMIC or local), with the processing mode (on-line or batch)
h) The functional users of the software
i) The level of granularity of the available software artefacts and the level of decomposition of the software.
j) The point in the project life-cycle when the measurement was made (especially whether the measurement is an estimate based on incomplete requirements, or was made on the basis of actually delivered functionality).
k) The target or believed error margin of the measurement.
l) Indications whether the standard COSMIC measurement method was used, and/or a local approximation to the standard method, and/or whether local extensions were used (see section 4.5). Use the labeling conventions of sections 5.1 or 5.2.
m) An indication whether the measurement is of developed or deliveredfunctionality (‘developed’ functionality is obtained by creating new software; ‘delivered’ functionality includes ‘developed’ functionality and also includesfunctionality obtained by other means than creating new software, i.e. including all forms of re-use of existing software, implementation of software packages, use of existing parameters to add or change functionality, etc.).
n) An indication of whether the measurement is of newly provided functionalityor is the result of an ‘enhancement’ activity (i.e. the sum is of added,changed and deleted functionality – see 4.4).
o) The number of major components, if applicable, whose sizes have been added together for the total size recorded.
p) The percentage of functionality implemented by re-used software
q) For each scope within the overall measurement scope, one measurement matrix, as specified in Appendix A.
r) The Measurer’s name and any COSMIC certification qualifications; the date of the measurement
COSMIC measurement labeling
A COSMIC measurement result shall be noted as ‘x CFP (v) ‘, where:
‘x’ represents the numerical value of the functional size,
‘v’ represents the identification of the standard version of the COSMIC method used to obtain the numerical functional size value ‘x’.NOTE: If a local approximation method was used to obtain the measurement, but otherwise the measurement was made using the conventions of a standard COSMIC version, the above labeling convention shall be used, but use of the approximation method should be noted elsewhere – see section 5.2.COSMIC local extensions labeling
A COSMIC measurement result using local extensions shall be noted as:‘ x CFP (v) + z Local FP’, where:
‘x’ represents the numerical value obtained by aggregating all individualmeasurement results according to the standard COSMIC method, version v,
‘v’ represents the identification of the standard version of the COSMIC method used to obtain the numerical functional size value ‘x’.
‘z’ represents the numerical value obtained by aggregating all individual measurement results obtained from local extensions to the COSMIC method.
Each identified data group shall be unique and distinguishable through its unique collection of data attributes.
Identifying different data groups (and hence different objects of interest) moved in the same one functional process
For all the data attributes appearing in the input of a functional process:
a) sets of data attributes that have different frequencies of occurrence describe different objects of interest;
b) sets of data attributes that have the same frequency of occurrence but different identifying key attribute(s) describe different objects of interest;
c) all the data attributes in a set resulting from applying parts a) and b) of this rule belong to the same one data group type, unless the FUR specify that there may be more than one data group type describing the same object of interest in the input to the functional process (see Note 3)
This same rule applies for all the data attributes appearing in the output of a functional process, or all that are moved from a functional process to persistent storage, or all that are moved from persistent storage into a functional process.
NOTE 1. It can be helpful when analyzing complex output, e.g. reports with data describing several objects of interest, to consider each separate candidate data group as if it were output by one separate functional process. Each of the data group types identified this way must also be distinguished and counted when measuring the complex report. For examples, see the ‘Guideline for sizing business application software’ , in particular the example in section 2.6.1 andits analysis in 2.6.2. See also the analysis of the examples 4 and 5 in section 4.2.4.
NOTE 2. Examining how data attributes are physically grouped or separated oninput or output may help distinguish different data group types, but cannot be relied upon to distinguish them. As an example, two or more sets of data attributes occurring on the same input or output that are physically separated for aesthetic reasons or for ease of understanding, will belong to the same one data group type if they satisfy the rule above.
NOTE 3. See section 3.5 of the Measurement Manual for the definitions, principles and rules for the data movements that move data groups, and section 3.5.7 (examples 2, 3, 4 and 5) and 3.5.11 for exceptions to these rules for data movements, as per rule c above.
a) A functional process shall belong entirely to the measurement scope of one piece of software in one, and only one, layer.
b) A functional process shall comprise a minimum of two data movements, namely the triggering Entry plus either an Exit or a Write, giving a minimum size of 2 CFP. There is no upper limit to the number of data movements in a functional process and hence no upper limit to its size.
c) An executing functional process shall be considered terminated when it has satisfied its FUR for all the possible responses to its triggering Entry. A pause during the processing for technical reasons shall not be considered as termination of the functional process.
a) Precise functional size measurement of a piece of software requires that its FUR are known at a level of granularity at which its functional processes and data movement sub-processes may be identified.
b) If some requirements must be measured before they have been defined in sufficient detail for a precise measurement, the requirements can be measured using an
PRINCIPLES AND RULES DESCRIPTION
approximate approach. These approaches define how requirements can be measured at higher level(s) of granularity. Scaling factors are then applied to the measurements at the higher level(s) of granularity to produce an approximate size at the level of granularity of the functional processes and their data movement subprocesses. See the ‘Guideline for approximate COSMIC functional size measurement’ .
A functional process requiring data from a functional user
a) A functional process shall obtain a data group via an Entry data movement from a functional user, when the functional process does not need to tell the functional user what data to send, as in any of the following four cases:
when a functional user sends a data group via a triggering Entry which initiates the functional process;
when a functional process, having received a data group via a triggering Entry, waits, expecting the arrival of a further data group from the functional user via an Entry (can occur when a human functional user enters data to business application software);
when a functional process, having started, requests the functional user,‘send me your data now, if you have any’ and the functional user sends its data;
when a functional process, having started, inspects the state of a functional user and retrieves the data it requires.
In the latter two cases (typically occurring in real-time ‘polling’ software), byconvention no Exit from the functional process shall be identified to obtain the required data. The functional process merely needs to send a prompt message to a functional user and the functionality of that prompt message is considered to be part of the Entry. The functional process knows what data to expect. Only one Entry shall be identified for this case.
b) Where a functional process needs to obtain the services of a functional user (for instance to obtain data) and the functional user needs to be told what to send (typically where the functional user is another piece of software outside the scope of the software being measured), an Exit followed by an Entry data movement shall be identified. The Exit sends the request for the specific data; the Entry receives the returned data.
a) The functional users of a piece of software to be measured shall depend on the purpose of the measurement.
b) When the purpose of a measurement of a piece of software is related to the effort to develop or modify the piece of software, then the functional users should be all the different types of senders and/or intended recipients of data to/from the new or modified functionality, as required by its FUR.
NOTE: FUR may specify that a set of functional users must be individually identified. Nevertheless they will be of the same type if each occurrence is subject to the same FUR
a) A piece of software interacts with its functional users across a boundary, and with persistent storage within this boundary.
b) Functional user requirements of a piece of software to be measured can be mapped into unique functional processes.
c) Each functional process consists of sub-processes.
d) A sub-process may be either a data movement or a data manipulation.
e) A data movement moves a single data group.
f) There are four data movement types, Entry, Exit, Write and Read.
An Entry moves a data group into a functional process from a functional user.
An Exit moves a data group out of a functional process to a functional user.
A Write moves a data group from a functional process to persistent storage.
A Read moves a data group from persistent storage to a functional process.
g) A data group consists of a unique set of data attributes that describe a single object of interest.
h) 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.
i) The size of a functional process is equal to the total count of its data movements
j) A functional process shall include at least the triggering Entry data movement and either a Write or an Exit data movement, i.e. it shall include a minimum of two data movements. There is no upper limit to the number of data movements in a functional process
k) As an approximation for measurement purposes, data manipulation sub- processes are not separately measured; the functionality of any data manipulation is assumed to be accounted for by the data movement with which it is associated
NOTE: The COSMIC Generic Software Model, as its name suggests, is a logical ‘model’ that exposes units in which software processes data that aresuitable for functional size measurement. The model does not intend to describe the physical sequence of the steps by which software executes nor any technical implementation of the software.
a) Software in one layer provides a set of services that is cohesive according to some defined criterion, and that software in other layers can utilize without knowing how those services are implemented.
b) The relationship between software in any two layers is defined by a‘correspondence rule’ which may be either
‘hierarchical’, i.e. software in layer A is allowed to use the services provided by software in layer B but not vice versa (where the hierarchical relationship may be up or down), or
‘bi-directional’, i.e. software in layer A is allowed to use software in layerB, and vice versa.
c) Software in one layer exchanges data groups with software in another layer via their respective functional processes.
d) Software in one layer does not necessarily use all the functional services supplied by software in another layer.
e) Software in one layer of a defined software architecture may be partitioned into other layers according to a different defined software architecture.
c) A layer may contain one or more separate ‘peer’ pieces of software.
d) Any piece of software to be measured, shall be defined by its measurementscope, which shall be confined wholly within a single layer.
e) The scope of a piece of software to be measured shall depend on thepurpose of the measurement.
f) 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.
g) The functional requirements of software may be expressed at differentlevels of granularity.
h) A precise COSMIC size measurement of a piece of software requires that its FUR are known at the levels of granularity at which its functional processes and sub-processes can be identified.
i) An approximate COSMIC size measurement of a piece of software is possible if its functional requirements are measured at a high level of granularity by an approximation approach and scaled to the levels of granularity of the functional processes and sub-processes.
Levels of granularity for measuring a functional process
a) A functional size measurement of a piece of software requires that its FUR are known at the levels of granularity at which its functional processes and data movement sub-processes may be identified.
b) If some requirements must be measured before they have been defined in sufficient detail for a precise measurement, the requirements can be measured using an approximate approach. These approaches define how requirements can be measured at higher level(s) of granularity. Scaling factors are then applied to the measurements at the higher level(s) of granularity to produce an approximate size at the levels of granularity of the functional processes and their data movement sub processes. See the Guideline for Early or Rapid COSMIC Functional Size Measurement by approximation approaches’. .
a) An Entry shall move a single data group describing a single object of interest from a functional user across the boundary and into the functional process of which the Entry forms part. If the input to a functional process comprises more than one data group, each describing a different object of interest, identify one Entry for each unique data group in the input. (See also section 3.5.7 on ‘Data movement uniqueness’.)
b) An Entry shall not exit data across the boundary, or read or write data from/to persistent storage.
a) The data group of a triggering Entry may consist of only one data attributewhich simply informs the software that ‘an event Y has occurred’. Veryoften, especially in business application software, the data group of the triggering Entry has several data attributes which inform the software that‘an event Y has occurred and here is the data about that particular event’.
b) Clock-ticks that are triggering events shall always be external to the software being measured. Therefore, for example, a clock-tick event occurring every 3 seconds shall be associated with an Entry moving a data group of one data attribute. Note that it makes no difference whether the triggering event is generated periodically by hardware or by another piece of software outside of the boundary of the software being measured.
c) Unless a specific functional process is necessary, obtaining the date and/ortime from the system’s clock shall not be considered to cause an Entry or any other data movement.
d) If an occurrence of a specific event causes the Entry of a data groupcomprising up to ‘n’ data attributes of a particular object of interest and the FUR allows that other occurrences of the same event can cause an Entry of a data group which has values for attributes of only a sub-set of the ‘n’attributes of the object of interest, then one Entry shall be identified, moving a data group comprising all ‘n’ data attributes.
e) When identifying Entries in a screen that enables human functional users to input data into functional processes, analyze only screens that are filled with data. Ignore any screen that is formatted but otherwise ‘blank’ except forpossible default values, and ignore all field and other headings that enable human users to understand the input data required.
NOTE. It may be necessary to consider field and other headings when measuring FUR for changes to Entries – see section 4.4.1.
a) An Exit shall move a single data group describing a single object of interest from the functional process of which the Exit forms part across the boundary to a functional user. If the output of a functional process comprises more than one data group, identify one Exit for each unique data group in the output. (See also section 3.5.7 on ‘Data movement uniqueness’.)
b) An Exit shall not enter data across the boundary, or read or write data from/to persistent storage.
a) An enquiry which outputs fixed text, (where ‘fixed’ means the messagecontains no variable data values e.g. the result of pressing a button for‘Terms & Conditions’ on a shopping web-site), shall be modeled as having one Exit for the fixed text output.
NOTE: For the output from ‘Help’ functionality, see the ‘Guideline for sizing Business Application Software’. For the output of messages concerned witherror conditions or confirming success, see section 3.5.11 of this Measurement Manual.
b) If an Exit of a functional process moves a data group comprising up to ‘n’data attributes of a particular object of interest and the FUR allows that the functional process may have an occurrence of an Exit that moves a data group which has values for attributes of only a sub-set of the ‘n’ attributes ofthe object of interest, then one Exit shall be identified, moving a data groupcomprising all ‘n’ data attributes.
c) When identifying Exits, ignore all field and other headings that enable human users to understand the output data.
NOTE: It may be necessary to consider field and other headings when measuring FUR for changes to Exits – see section 4.4.1
a) A Read shall move a single data group describing a single object of interest from persistent storage to a functional process of which the Read forms part. If the functional process must retrieve more than one data group from persistent storage, identify one Read for each unique data group that is retrieved. (See also section 3.5.7 on ‘Data movement uniqueness’.)
b) A Read shall not receive or exit data across the boundary or write data to persistent storage.
c) During a functional process, movement or manipulation of constants or variables which are internal to the functional process and that can be changed only by a programmer, or computation of intermediate results in a calculation, or of data stored by a functional process resulting only from the implementation, rather than from the FUR, shall not be considered as Read data movements.
d) A Read data movement always includes any ‘request to Read’ functionality (so a separate data movement shall never be counted for any ‘request to Read’ functionality). See also section 3.5.9.
a) Identify a Read when, according to the FUR, the software being measured must retrieve a data group from persistent storage.
b) Do not identify a Read when the FUR of the software being measured specify any software or hardware functional user as the source of a data group, or as the means of retrieving a persistently-stored data group. (For this case see the principles and rules for Entries and Exits.)
a) A Write shall move a single data group describing a single object of interest from the functional process of which the Write forms part to persistent storage. If the functional process must move more than one data group to persistent storage, identify one Write for each unique data group that is moved to persistent storage. (See also section 3.5.7 on ‘Data movement uniqueness’.)
b) A Write shall not receive or exit data across the boundary, or read data from persistent storage.
c) A requirement to delete a data group from persistent storage shall be measured as a single Write data movement.
The following shall not be considered as Write data movements:
The movement or manipulation of any data that did not exist at the start of a functional process and that has not been made persistent when the functional process is complete;
Creation or update of variables or intermediate results that are internal to the functional process;
Storage of data by a functional process resulting only from the implementation, rather than from the FUR. (An example would be the use of storage to store data temporarily during a large sort process in a batch-processed job.)
a) Identify a Write when, according to the FUR, the software being measured must move a data group to persistent storage.
b) Do not identify a Write when the FUR of the software being measured specify any software or hardware functional user as the destination of the data group, or as the means of storing the data group. (For this case see the principles and rules for Entries and Exits.)
All data manipulation in a functional process shall be associated with the four types of data movement (E, X, R, and W). By convention, the data movements of a functional process are assumed also to account for the data manipulation of the functional process.
a) An Entry data movement accounts for all data manipulation to enable a data group to be entered by a functional user (e.g. formatting and presentation manipulations) and to be validated.
b) An Exit data movement accounts for all data manipulation to create the data attributes of a data group to be output and/or to enable the data group to be output (e.g. formatting and presentation manipulations) and to be routed to the intended functional user.
c) A Read data movement accounts for all computation and/or logical processing needed in order to retrieve a data group from persistent storage.
d) A Write data movement accounts for all computation and/or logical processing to create or to update a data group to be written, or to delete a data group.
e) The data manipulation associated with any of these data movements does not include any data manipulation that is needed after the data movement has been successfully completed, nor does it include any data manipulation associated with any other data movement.
N.B. All COSMIC rules concern types of functional users, data groups, data movements, functional processes and objects of interest. For ease of reading,we normally omit ‘type’ from these terms. This convention is followed in rules a), b) and c) below but In rule d) we include ‘type’ where it is helpful to distinguish a‘type’ from an ‘occurrence’.
a) Unless the Functional User Requirements are as given in rules b) or c), all data describing any one object of interest that is required to be entered into one functional process shall be identified as one data group moved by one Entry.
NOTE: A functional process may, of course, have multiple Entries, each moving data describing a different object of interest.
The same equivalent rule applies to any Read, Write or Exit data movement in any one functional process.
b) If Functional User Requirements specify that different data groups must be entered into one functional process each from a different functional user, where each data group describes the same object of interest then one Entry shall be identified for each of these different data groups.
The same equivalent rule applies for Exits of data to different functional users from any one functional process.
NOTE: Any one functional process shall have only one triggering Entry.
c) If Functional User Requirements specify that different data groups must be moved from persistent storage into one functional process, each describing the same object of interest then one Read shall be identified for each of these different data groups.
The same equivalent rule applies for Writes in any given functional process.
NOTE: This rule is analogous to rule b). In the case of the FUR to read different data groups describing the same object of interest, they will likely have originated from different functional users. In the case of the FUR to write different data groups, they will likely be made available to be read by different functional users.
d) Repeated occurrences of any data movement type when it is being executed shall not be counted.
This applies even if multiple occurrences of the data movement type differ in their execution because different values of the data attributes of the data group moved result in different processing paths being followed through the functional process type.
Error/Confirmation messages and other indications of error conditions
a) One Exit shall be identified to account for all types of error/confirmation messages issued by any one functional process of the software being measured from all possible causes according to its FUR, e.g. successes or failures of: validation of entered data or for a call to retrieve data or to make data persistent, or for the response from a service requested of another piece of software.
NOTE: If the FUR of the functional process do not require any type of error/confirmation message to be issued, do not identify any corresponding Exit.
b) If a message to a human functional user provides data in addition to confirming that entered data has been accepted, or that entered data is in error, then this additional data should be identified as a data group moved by an Exit in the normal way, in addition to the error/confirmation Exit.
c) All other data, issued or received by the software being measured, to/from its hardware or software functional users should be analyzed according to the FUR as Exits or Entries respectively, according to the normal COSMIC rules, regardless of whether or not the data values indicate an error condition.
d) Reads and Writes are considered to account for any associated reporting of error conditions. Therefore no Entry to the functional process being measured shall be identified for any error indication received as a result of a Read or Write of persistent data.
e) No Entry or Exit shall be identified for any message indicating an error condition that might be issued whilst using the software being measured but which is not required to be processed in any way by the FUR of that software, e.g. an error message issued by the operating system.
a) If a data movement must be modified due to a change of the data manipulation associated with the data movement and/or due to a change in the number or type of the attributes in the data group moved, one changed CFP shall be measured, regardless of the actual number of modifications in the one data movement.
b) If a data group must be modified, data movements moving the modified data group whose functionality is not affected by the modification to the data group shall not be identified as changed data movements.
NOTE: A modification to any data appearing on input or output screens that are not related to an object of interest to a functional user shall not be identified as a changed CFP. (See section 3.3.3 for examples of such data.)