A Process to Improve the Accuracy of MkII FP to COSMIC Size Conversions: Insights into the COSMIC Method Design Assumptions

Abstract

Converting software sizes measured by one Functional Size Measurement (FSM) method to another is usually achieved by measuring the size of a sample of software items by both methods and deriving a statistical correlation curve that can be used for converting the whole set of measurements.

This paper describes a ‘calculation method’ to convert functional sizes measured by the MkII FSM method to COSMIC functional sizes. The method exploits some common features of both FSM methods and uses ‘functional profiling’ of measurements in order to form homogeneous datasets suitable for conversion. Applying the method to measurements of the same software by both FSM methods confirms that the calculated COSMIC sizes are more accurate than statistically-converted sizes.

Comparing the way in which the two methods measure functional size and the results of the conversion study yields significant, positive insights into the design assumptions of the COSMIC FSM method.

Appendices

Appendix 1: Components of the MkII and COSMIC Size Measurements

Appendix 2: A More Detailed Examination of How the MkII and COSMIC Methods Measure the Input vs Processing Phases of a Functional Process

Data validation in the input phase of a functional process. The input phase of any functional process is normally considered to include validation of entered data, which can require significant amounts of functionality for business applications.

As represented by the MkII method, validation processes may require references to:

• the so-called ‘System Entity’; this was introduced into the MkII method to simplify measurement by counting a single ER (entity reference) in any functional process that referenced fixed tables of simple codes and descriptions and other ‘non-primary’ entities, typically found in dialogues of on-line systems with GUI interfaces, and

• other ‘primary’ entities, e.g. to check if the data to be entered describes an occurrence of an entity about which data are already stored.

Consequently, the input phase is more closely accounted for by:

• the number of DET’s on the input, plus

• (where required) reference to the System Entity and maybe references to other entities.

This is in contrast to the ‘simple’ view described in the main text which assumes all entity-references belong to the processing phase.

Similarly, for the COSMIC method, data entry is accounted for by the Entry data movements and by any Read data movements needed for validation of the input data. So in reality the functionality needed to handle data entry and validation, i.e. the Input phase, includes some of the Reads that have been considered as part of the Processing phase on the ‘simple’ view of the division of functionality across the three phases.

Differences between MkII ‘entity references’ and COSMIC ‘data movements’. There are two significant differences between how the MkII method defines an ‘entity’ and its rules for counting ER’s, and the equivalent COSMIC method’s definition of an ‘object of interest’ and its rules for counting Reads and Writes of persistently-stored data groups.

• The COSMIC method requires that all objects of interest that need to be referenced to validate entered data must be identified and counted as Reads. The COSMIC method does not recognise the simplifying concept of a ‘System Entity’. So a single reference to the System Entity in the measurement of a MkII functional process may, when measured by the COSMIC method, be replaced by one or more Reads of objects of interest. (For more on this topic of the MkII System Entity and the equivalent COSMIC objects of interest, see the respective method’s documentation.)

• In the COSMIC method, a functional processes that is designed for batch-processing may need a Read and Write of the same object of interest. The MkII method rules would require the counting of one ER in such a functional process. (All software items on which size data are reported in this paper were designed for on-line, not batch, processing, so this difference has no influence on the results reported here.)

Potential for further refinement of the ‘calculated’ size conversion method. The data available to the authors do not distinguish whether the counts of entity references include any that were required for input data validation. For this reason we have to continue to adopt the simple view of the division of functionality across the three phases when analysing the available data.

If we had the measurements, or could make some reasonable assumptions about the proportion of MkII entity-references and COSMIC Reads devoted to the input phase, then it might be possible to develop an even more refined version of the ‘calculated’ conversion process described and used in the body of this paper.