Advantages
of the COSMIC method
Summary
Compared with ‘1st Generation’ Functional
Size Measurement methods, the COSMIC method has the following main advantages
and benefits.
·
The
COSMIC method can be applied to real-time and infrastructure software (such
as operating system software) as well as to business software and to hybrids
of all these types
·
COSMIC’s
underlying concepts are compatible with modern methods of determining software
requirements and constructing software, so the method is easier to learn and
to apply, and automatic sizing should become possible with the right tools.
·
Measuring
the size of functional user requirements with COSMIC can help the requirements
determination process. Requirements
that are measurable are likely to be clear, unambiguous and testable
·
The
size scale is not subject to arbitrary limits on the size of any one component,
so the size scale is more realistic and plausible
·
The
method’s underlying concepts have been carefully defined to eliminate difficulties
of interpretation from which earlier FSM Methods suffer.
·
The
method is also more ‘robust’ in that measured sizes are generally less
sensitive to mistakes of analysis than is typically the case with 1st
Generation FSM Methods
·
COSMIC
sizes can be measured from different ‘Measurement Viewpoints’ (MV). The Developer Measurement Viewpoint allows functional
sizes to be measured of the actual components of a multi-peer, multi-layered
architecture that have to be developed or modified, for any type of software,
to satisfy the FUR. The End-user Measurement
Viewpoint allows a functional size to be measured of business application
software as specified in the FUR of the Business User, or sponsor of the software.
Sizes measured from the Developer MV should be more generally useful
for project managers for estimating and project scope control. Sizes
measured from the End-user MV should be more comparable with sizes measured
with ‘1st Generation’ FSM Methods.
More on the above
The best way to describe the advantages of the
COSMIC method over ‘1st Generation functional sizing methods is
to compare it as define in the Measurement Manual v2.2 against the IFPUG method,
version 4.1 and its International Standard equivalent version (ISO/IEC 20926:2003).
Objectives
Both methods aim to measure a functional size of a piece of
software, independently of the technology with which it is implemented, but
additionally the IFPUG method attempts to take into account the effect on size
of certain technical and quality requirements.
The COSMIC size scale is based exclusively on what
are known as ‘Functional User Requirements’, or ‘FUR’, defined as ‘the user
practices and procedures that the software must perform to fulfill the users’
needs. FUR exclude Quality requirements and
any Technical requirements’ 6).
The IFPUG method, as well as measuring a size of
FUR, which it calls the ‘Unadjusted FP’ size, also attempts to take into
account the contribution to size of certain Technical and Quality requirements
in a factor known as the ‘Value Adjustment Factor’, or ‘VAF’ – see further
below. The International Standard definition of the IFPUG method 7)
covers only the Unadjusted FP size.
Scope of Applicability
The IFPUG method was created for sizing business
application software but the IFPUG organisation does
not now state any limits on the type of software which can be measured. If you stay within the IFPUG rules it is
clear that the method is unsuitable for most real-time and infrastructure
software (see further below) and for all software that is dominated by
mathematical algorithms.
The COSMIC method was designed to measure a functional
size of business application, real-time and infrastructure software, and hybrids
of these, on the same size scale. It has been tested and accepted in
those domains. It has no solution for sizing software dominated by mathematical
algorithms, but offers a ‘user extension’ facility for that purpose.
‘Viewpoint’ of the Measurement
The IFPUG method was designed to measure a
functional size of the business requirements of ‘application’ software as seen
from the ‘User View’ of the software. This is defined as “A User View represents a formal description of
the user’s business needs in the user’s language. Developers
translate the user information into information technology language in order to
provide a solution” 3).
It follows from this ‘Viewpoint’, that much of the detail
of the functionality that has to be developed to meet ‘the user’s business
needs’ will often be invisible. For
example, for the user’s business needs, it is immaterial if the functionality
happens to be on one processor, or is distributed over multiple
processors. The ‘User’ sees the same functionality
and only one size regardless of any such implementation considerations. Also in this viewpoint, the functionality of
software in layers beneath the application software is invisible to the human
user and therefore any need to alter its functionality is ignored. A further consequence is that in a batch
processing stream, the only elementary processes that can be measured are those
where the input and output cross the external boundary as seen by the human
user. Any other functionality that is
not recognisably part of these processes is ignored.
The COSMIC method
introduces the concept of a ‘Measurement Viewpoint’ (or ‘MV’), and offers
a choice to the measurer. It can be used to measure a functional size
from the ‘End-user’ MV, the same as that measured by the IFPUG method, or
it can be used to measure a functional size as seen from the ‘Developer’ MV.
An analogy would be a measurement of the height of the building. A person
in the street would see a height that is lower than the height seen by the
builder, who may want to include the height of floors
beneath ground level.
If size measurements are made using the End-user MV, it can
be difficult to compare performance across projects that develop software with
differing technology constraints. For example, project A developed its
software on a single platform, project B on multiple platforms of differing
technology, project C necessitated work on software in layers below the
application level. Such differences are ‘invisible’ in the End-user MV,
and so do not get taken into account when measuring the size of the
work-output.
The COSMIC method, using the Developer MV, will give sizes
for each separate component of a multi-tier architecture and in each layer
of multi-layered software. Such size measures should be more useful
for understanding development performance and for estimating purposes.
Sizes from different Measurement Viewpoints should obviously never be combined
or used together.
A further consequence of using the Developer MV with COSMIC
is that all functions that are allocated to software are included in the size
measure. In the IFPUG method, functionality associated with menu navigation,
log-on and security checking, check-pointing and such-like is not measured
as it is not considered to be ‘business’ functionality.
The Concepts underlying the Size Measure – the ‘Base Functional
Components’ (BFC’s 6)) that are measured
The IFPUG method’s underlying concepts date from
when it was invented in the mid-1970’s. The
software to be measured, or its FUR, is broken down into three types of
‘Elementary Processes’ (Inputs, Outputs and Enquiries) and two types of files
(Internal Logical Files and External Interface Files). Each component is
then classified as Simple, Average or Complex, and is awarded a number of
‘Function Points’ depending on this complexity.
The complexity of an Elementary Process depends on the number
of data element types on the component and on the number of file-types referenced
in its processing. Example: Simple, Average and Complex Outputs score
4, 5 and 7 ‘Unadjusted’ FP’s respectively.
The complexity of a file depends on the number of its
record-types and data element types. Simple, Average and Complex Internal
Logical Files score 7, 10 and 15 UFP’s respectively.
Summing the UFP sizes of all its components gives the
‘unadjusted’ size of a piece of software. This size is then multiplied by
the VAF, which is determined by the contributions of 14 technical and quality
factors to give the ‘adjusted’ size in FP’s. By common consent this ‘VAF’
factor is nowadays obsolete, but it is still included when performance data
have to be compared against external benchmarks. The ISO definition of
the IFPUG method excludes the VAF.
In the COSMIC method, the software to be measured or
its FUR is broken down into ‘functional process types’, defined as ‘an elementary
component of a set of Functional User Requirements comprising a unique cohesive
and independently executable set of data movement types. It is triggered
by one or more Triggering event types either directly,
or indirectly via an ‘actor’. It is complete when it has executed all
that is required to be done in response to the Triggering event type.’ 4,
5)
Functional process types are then broken down into four
types of ‘sub-processes’, or ‘data movement types’, namely Entries, Exits,
Reads and Writes, each with an assumed associated amount of data
manipulation. Entries and Exits cross the boundary between the software
being measured and its Users (who may be any person, other piece of software or
‘thing’, e.g. a sensor that communicates with the software being
measured). A Read moves data from ‘persistent storage’ into the software
being measured whilst a Write makes data ‘persistent’, meaning that the data
lasts beyond the life of the functional process. Each data movement is
awarded a size of one Cfsu (COSMIC functional size unit).
The size of a functional process is the sum of its data
movements and the size of a piece of software is the sum of the sizes of all of
its functional processes. The simplest functional process has a size of 2
Cfsu (one Entry, plus an outcome, either as a Write or an Exit), but there is
no upper limit to the size of a functional process.
Both methods have more detailed rules for identifying their
underlying concepts than are given in this brief overview.
A key difference between the methods is that the IFPUG method
accounts for stored data (as in Logical Files) once per system. In addition
and to a limited extent, the number of file references affects the complexity
and therefore the size of each elementary process. In contrast, the
COSMIC method accounts for stored data every time it is read or written by
a data movement in each functional process. This difference should result
in the COSMIC method accounting better in its size measure for the complexity
of processing stored data.
Relevance of the underlying Concepts (the BFC’s)
to modern methods of documenting software Functional User Requirements
The IFPUG ‘Logical Files’ are not concepts that
would appear in modern ways of documenting software such as when UML,
entity-relationship analysis or relational data analysis are used. Nor do
they fit with OO concepts. Further, distinguishing elementary processes
as Inputs, Outputs and Inquiries, and giving them different UFP’s
may be satisfactory for business application software, but has no relevance to
real-time software. For example, a functional process to forward a
message has both input and output, of equal importance.
The COSMIC method has been designed to be compatible
with modern requirements analysis methods such as UML. The underlying
concepts of the COSMIC method have been mapped to UML by Malcolm Jenner
8, 9) (except UML lacks the concept of a ‘trigger’ for each functional
process). He has given rules for automatic sizing of FUR held in a UML-compatible
repository. These are currently being tested in RUP using the Rational
Rose tool by graduate students at the École Supérieure
de Technologie in Montréal.
Subjectivity of the
Underlying Concepts.
This topic is critical for the
repeatability of the measurement. If the Base Functional Components of a
method are difficult or subjective to interpret, different measurers will get
different results.
IFPUG’s BFC’s are not
well-defined in two ways. An ‘elementary process’ is defined as ‘the
smallest processing unit of interest to the user’, which is open to wide interpretation.
In practice it is generally interpreted in the same way as a COSMIC ‘functional
process’, but nevertheless when faced with very large and complex processes,
the IFPUG measurer may be uncertain as to how far to sub-divide the elementary
processes before assigning the UFP’s.
Similarly, a ‘Logical File’ is
defined in the IFPUG method as that which is a logical unit for the user.
This frequently leads to difficulty of interpretation. A classic example
where the rules of both methods give consistent results is a file of ‘orders’
where each order has a header and one or more order-lines. This is considered
as a single Internal Logical File in the IFPUG method, as it would be in the
non-computerised world. But in entity-relationship analysis this would
be considered as two entity-types. Hence reading an order file in the
IFPUG method counts as one file reference, or two Reads on the COSMIC method.
But typically when analysing
more complex relational databases, difficulties often arise in the IFPUG method
on how to answer the question of ‘what are the files that the user would
consider as separate logical files?’
The definitions and rules of the
COSMIC method have been carefully drawn up to eliminate ambiguity completely
on these points as far as possible.
Validity of the Size Scale.
One of the most significant weaknesses of the IFPUG
method is its limit on the size of any elementary process or of any file.
No matter how big or complex, an Input elementary process cannot get more than
6 UFP, and a file cannot score more than 15 UFP.
In contrast there is no upper limit to the size of a COSMIC
functional process. Examples have been found of functional processes
having more than 100 Cfsu (i.e. more than 100 data movement types) in avionics
software, and of up to 25 Cfsu in life assurance software. Although
perhaps proportionately few in number, these very complex functional processes
can account for a high proportion of the total size of the software being
measured.
A consequence of this problem is that when measured on the
IFPUG scale, the systems of an organisation that
typically have many very complex elementary processes (such as in life
assurance) will be ‘under-sized’ compared with those of an organisation
whose systems have much simpler elementary processes (such as in simple
web-based booking systems). This means that the productivity of work on
systems with very complex processes will automatically appear lower than that
of work on simpler systems, other factors being equal.
The IFPUG scale also has peculiar distorting effects.
For an elementary process to be counted as more than ‘average’ complexity and
therefore score more than 4 or 5 UFP’s, it must have
more than 2 file-type references. But many functional processes in
real-time or infrastructure software that handle much data in and out across
the boundary have no file accesses at all, so can never be considered as
‘complex’ on the IFPUG scale.
A second important factor concerns the sizing of
enhancements to existing software. The IFPUG method measures the size of
an enhancement as the size of the components that are added, changed and
deleted, regardless of how much functionality has been added, changed or
deleted in those components. This is a very coarse measure. For
example, if a single data element type is added to an existing complex Input
elementary process, or if a whole new complex Input is added, both changes
score the same number of UFP’s (6). A
consequence of the IFPUG measurement rules is that productivity of enhancement
work appears much higher relative to new development work than it probably
really is.
The COSMIC method measures the size of an enhancement by adding
up the number of sub-processes added, changed or
deleted, which more closely reflects the amount of work involved.
Finally, the VAF of the IFPUG method affects the size scale
in ways that are no longer valid. The factor is retained mostly for the
sake of being able to continue using performance data and estimating methods
accumulated over many measurements and for comparison with external benchmark
data. In the COSMIC view, such factors must clearly be taken into account
in estimating and benchmarking activities, but they should be considered
separately from the functional size measure. This is also the ISO view 6).
Speed of
Measurement.
Any FSM Method must be reasonably fast to apply, for the method
to be economical to use. Because the IFPUG method is ‘coarser’
than the COSMIC method, in a sense it is more approximate and early experience
indicated that the COSMIC method appeared to be slower to apply than
the IFPUG method.
A major consultancy in the
“Our experience is that the quality of documentation (or the
level) determines the counting speed and that for the same quality or level
of documentation there is no difference between using NESMA (a Dutch variant
of the IFPUG method) or using COSMIC. We have converted an IT-department
of XXX (a major bank) from using NESMA FPA to the use of COSMICand there is
no significant change in the time we need to size projects. For each
project we size we perform an intake on the quality of the documentation to
determine the amount of time we need for sizing. The impact of the quality
(or the level) is almost the same order of magnitude as size in respect to
the time to size a project.”
The authors’ own experience is similar, though when documentation
is poor (i.e. not detailed enough for accurate FP sizing) and speed of sizing
is important, it seems to be easier and therefore
faster for an experienced FP analyst to determine an IFPUG size than to measure
a COSMIC size. This is because with the IFPUG method’s narrow range
of UFP sizes for any one component, with experience it is easy to reach a
quick decision on its complexity and hence to assign a UFP size which will
be good enough to achieve a required + or - percentage accuracy. With
the COSMIC method, it may well be necessary to speak to an expert in the software
when there are documentation weaknesses in order to achieve the same required
percentage accuracy on its scale. This could make the measurement process
more time-consuming.
The argument can also be turned round. Requirements
documentation that is adequate to perform an IFPUG size measure will not necessarily
be good enough for the developer’s or user’s purposes. On the other
hand, requirements documentation that is adequate for a COSMIC size measure
is likely to be extremely clear for the purposes of agreeing functional user
requirements and as a basis for ensuring requirements traceability and for
test planning.
Approximate versions of the standard methods for early life-cycle sizing
Both the IFPUG and COSMIC
methods include approximation variants that can be applied early in a project
life-cycle, before all the details of requirements have been worked out that
would be needed to measure an accurate size according to the method.
On the IFPUG method, because of the narrow range of sizes
that are allowed for any one component-type, its approximation method variants
are usually very simple to apply. For the COSMIC method’s approximation
variants, it is advisable to calibrate the chosen approximation approach locally
using measurements on systems comparable to the one whose type has to be approximately
sized.
Approximation
variants of the standard sizing methods can also, of course, be used when rapid
speed of sizing is more important than the accuracy given by the standard
method.
Convertibility of
IFPUG to COSMIC sizes
Conversion of IFPUG size measurements to those
of COSMIC is relevant to organisations that
have invested a lot of effort in measurements using the IFPUG method and who
do not want to have to scrap that investment to adopt the new method.
Given the various differences between the two methods, one
can see that it is impossible to devise a mathematical formula for conversion,
even for measurements made from the same Measurement Viewpoint. Therefore
the only means of conversion will be to measure some sizes of software developed
or enhanced in similar circumstances on both the IFPUG and COSMIC methods
and to establish an empirical conversion formula.
The results of two such studies have been reported.
Fetke 10) published some data in 1999 where the
COSMIC sizes were measured using v2.0 of the method definition, that is, before
the concept of a ‘Measurement Viewpoint’ was introduced. We may assume
that the measurements were effectively carried out from the End-user MV.
He established the formula:
Y (Cfsu) = - 6.2 + 1.1 X (UFP)
where Y is the size in Cfsu and X is the
Unadjusted FP size measured using the rules of IFPUG 4.1 (the latest version).
The correlation coefficient is 99% and the standard deviation of the Y values
about the line is 2.6 Cfsu.
Recently, Vogelezang and Lesterhuis 11) have published data obtained with
10 projects at one bank, all measured using the NESMA method (a Dutch variant
of the IFPUG method, very close to IFPUG 4.1) and COSMIC v2.2, according to
the End-user MV. Their formula is:
Y (Cfsu) = - 87 + 1.2 X (UFP)
The correlation coefficient is again 99% and the standard
deviation of the Y-values about the line is 59 CFP.
The only significant difference between
these two formulae is the constant. Vogelezang
and Lesterhuis point out that their ‘minus 87’ intercept
arises due to the influence of counting Internal Logical Files and External
Interface files on the IFPUG method, which tend to bump up the size of small
project software, compared to using the COSMIC method. Generally the conversion
formula should not be relied upon for sizes of less than around 100 Cfsu.
So, on average, for sizes over 100 CFP, for new
developments, measured from the same End-user MV, the IFPUG and COSMIC methods
give roughly similar sizes according to these early and limited-statistics
studies. There are of course considerable variations in size about the
mean for individual pieces of software due to other factors mentioned above.
Software dominated by very complex functional processes could be very much
larger as measured in Cfsu, compared with function points.
When measurements are taken from differing Measurement
Viewpoints, and for enhancement projects, we may expect much poorer
correlations of sizes measured on the two methods.
Availability of Benchmark Data
Several organisations offer proprietary commercial benchmarking
services where performance measurements are made using the IFPUG sizing
method. As these services have existed for many years, they typically
have thousands of project performance measurements on which to base their benchmarks.
A first set of project performance data measured using the
COSMIC method is to be published in early 2004 for benchmarking purposes
as the result of an initiative of COSMIC and the International Software Benchmarking
Standards Group 12). These measurements show, for example
that projects delivering MIS software are typically three times more productive
than those delivering communications software and the latter are three times
more productive than those delivering other real-time software such as embedded
and avionics software (noting that statistics are limited at the moment).
Other Commercial Considerations
The IFPUG method was first described in 1979, was heavily promoted by IBM in its early years and was
first published in a form close to its current definition around 1985.
Since then there have been a succession of refinements to the method, but
always constrained by the need to keep as much consistency as possible with
previous versions to enable continuity of measurement. There exists,
therefore a lot of experience, support tools, consulting, training and
benchmarking services and such-like, accumulated over almost 25 years.
IFPUG organises examinations to certify specialists
in Function Point measurement and an International Standard version of the
method (excluding the VAF) was published in 2003.
The COSMIC method was first published in late 1999
and became stable with the publication of an International Standard definition
in 2003. Consultancy and training services are available but on a more
limited scale so far than for the IFPUG method. The first tools to support
and record measurements have also been announced.
Conclusions
The COSMIC method represents a considerable advance over the
IFPUG and other ‘1st Generation’ FSM Methods. Measurement of functional sizes with the COSMIC
method should be more plausible, easier to make and repeatable, and more useful
for performance measurement and estimating purposes.
References:
1.
Albrecht A.J. ‘Measuring application development productivity’ in Proc. IBM
Applications Development Symposium. GUIDE Int and
Share Inc., IBM Corp.,
2. IFPUG, 1999, “Function Points Counting Practices Manual –
Release 4.1”, International Function Point Users Group (IFPUG),
Wisconsin, USA, 1999.
4. ISO/IEC
19761:2003 ‘Software Engineering – COSMIC-FFP – A functional size measurement
method’
5. Abran, A., Descharnais, J-M., Oligny, S.,
6. ISO/IEC
14143/1:1997 ‘Information Technology – Software Engineering – Functional Size
Measurement – Definition of Concepts’
7. ISO/IEC
20926:2003. ‘Software engineering - IFPUG 4.1 Unadjusted functional size measurement
method - Counting practices manual.’
8. Jenner, M.S. ‘COSMIC-FFP 2.0 and UML: Estimation of
the size of a system specified in UML – problems of granularity’. FESMA
Conference,
9. Jenner, M.S., ‘Automation of counting of functional size
using COSMIC-FFP in UML’, International Workshop on Software Measurement,
10. Fetke, T., ‘The warehouse software portfolio, a case study
in functional size measurement, Technical report no. 1999-20, Software
Engineering Management Research Laboratory, Université
du Québec à Montréal,
Canada, 1999.
11. Vogelezang, F., and Lesterhuis,
A., ‘Applicability of COSMIC Full Function Points’, 13th
International Workshop on Software Measurement, Montréal,
12. The
International Software Benchmarking Standards Group, ‘The Benchmark Release 8’,