COSMIC-FFP – A Method for Sizing All the Software Not Just What the User Sees

By Pam Morris, CEO - Total Metrics

1. INTRODUCTION

Outsourcing Information Technology’s (IT) software development and maintenance activities has become increasingly popular as a means of enabling an organisation to more effectively focus on their core business activities.

The high cost and risk associated with these IT outsourcing contracts means that they need to be carefully monitored and managed. Both the client and the supplier need to establish a means by which the client’s software assets can be quantified and the supplier’s performance can be evaluated and compared to agreed targets. The most common mechanism for providing these performance measurements is to measure the supplier’s productivity rates in units of software product delivered per unit effort or units of software product delivered per unit cost.

The units of software product delivered are usually measured using a Functional Size Measurement (FSM) method called IFPUG Function Point Analysis (FPA). FPA was developed by Alan Albrecht in the late 1970s and has since been refined by the International Function Point Users Group (IFPUG). Analysis of industry benchmarking repositories shows that the use of FPA has been largely concentrated within the business application domains i.e. software which delivers functionality to the human business user. These applications are typically commercial and management information systems (MIS) software. FPA has been found to very effective in measuring the functionality delivered by these types of applications, particularly when determining the productivity of software development and using the size as input into estimates for project resources and schedules. However, in recent years the need to quantify software has extended way beyond just measuring business applications for these purposes. Many developers are working on real-time embedded and process control software where the users are software in electronic components rather than people. Other developers are building infrastructure software, which enable the business applications software to operate in new technology environments and therefore have other software components as their users. With the advent of outsourcing, the client and supplier need to monitor all software worked on by the development teams, not only the applications that deliver software directly to the business users, but also include software that has other software components or equipment as its primary users. However developers recognise that the functionality delivered by these ‘other types’ of applications does not behave in the same way as functionality delivered primarily to human users.

Many functional size measurement specialists have found that FPA is less effective when measuring software, which delivers functionality to ‘users’ other than the business user compared to when it is applied in its traditional domain for which it was designed. This creates a problem in outsourcing contracts where all the supported software needs to be included in the performance measures and the charging model. This paper explores the reasons for these observed limitations of FPA and shows how they can be overcome using COSMIC-FFP.

Results from industry trials with COSMIC-FFP showed that the COSMIC-FFP measures have the potential to be used successfully for productivity monitoring and estimating, where FPA measures have been tried and were found to be lacking.

2. TYPES OF SOFTWARE APPLICATIONS

The functional domains of software applications, usually included within the scope of the outsourcing contract, can be categorized based on the type of end-user and the services provided by the software to these end users. These categories are illustrated in Figure 1; they include, but are not restricted to, the types identified in Table 1.

Outsourcing contracts may include the support and maintenance of applications in any or all of these categories. For the purposes of this paper, we will describe the software that is not of the type ‘business applications software’ as ‘non-business applications’ software. The non-business applications include real time embedded or control software and infrastructure software i.e. utility software, user’s tools, developer’s tools and systems software.

Figure 1. Categories of Software

Table 1: Profile of Software Types

3. FPA AND COSMIC-FFP CONCEPTS

This section compares the differences between the basic concepts of FPA and COSMIC-FFP. COSMIC-FFP was developed as a collaborative effort of the international functional size measurement community who distilled the ideas and lessons learnt from the preceding FSM Methods into a single FSM method that optimised the strengths of the previous generation methods and addressed their perceived limitations. Although initially developed to take into account functional characteristics specific to real-time software, its concepts have been found to be equally applicable to other types of software particularly where the primary users are not human.

3.1. FPA Concepts

IFPUG FPA was designed, refined and mostly used for Business applications software, which usually constitutes about 70% - 80% of a commercial organisation’s software portfolio. This section describes the basic concepts of IFPUG FPA, which have contributed to it being able to be used to effectively measure Business Applications software over the past 25 years. Full details of the rules for applying FPA can be found in the IFPUG Counting Practices Manual 4.2.

The FPA method measures functionality by quantifying the software’s processes (Inputs, Outputs, Enquires) and data files (Internal and External). It is based on the following fundamental principles: 1. Functional size is the measure of the functionality delivered to the end business user. Only processes that send or receive data to, or from, the external user boundary are included in the measurement of functionality delivered to the user.
2. A process is required to have a predominant role of either entering or extracting data. This predominant role determines the process type (Input, Output or Enquiry).
3. The functional size of a process is directly related to the :

• Amount of data which crosses the external user boundary of the software during the execution of the process
• The number of data groups, accessed by the software during the execution of the process

3.2. COSMIC-FFP Concepts

The COSMIC-FFP method measures functionality of the software by quantifying the software’s sub-processes (data movements) within each process. It is based on the following fundamental principles:
1. It measures functional size from the functional perspective instead of the external user view. I.e. measures the functionality required to be delivered by a process to the user of the process not just the functionality experienced directly by the user. Sub-processes that access data in the data groups (reads and writes) are included in the measurement of functionality in addition to the sub-processes required to receive data (entry) and extract data (exit).
2. A process is not required to have a predominant role per se. In order to measure size it is only necessary to identify all the Entry, Exit, Read and Write sub-process data movements.
3. The functional size of a process is determined by measuring the number of unique sub-processes (data movements). The predominant role of a process to either extract or accept data does not influence its resultant size.
4. An extremely complex process of a particular type can be sized accordingly by awarding proportionally more ‘points’. In theory, there is no limit to the number of points awarded for one specific process.
5. The number of ‘points’ awarded to a process (i.e. its functional size) is directly related to the number of unique data movements executed and therefore, the process size can be measured in linear increments of 1 fp unit, with a potential to reach an infinite size. The minimum size is two units with possible sizes in integers from two to infinity units.
6. Functionality delivered by stored data does not contribute to the overall functional size of the software. (I.e. stored data only contributes via the Read and Write sub-processes); it is not counted as a separate functional type.
7. Functionality changed by an enhancement project is recorded at the level of the sub-processes. Only a part of the process is credited for being impacted by the change (identified by the sub-processes added, changed or deleted).

The COSMIC-FFP FSM Method has taken into consideration current industry practices in the specification of software user requirements from a functional perspective and its constructs map well to the constructs of UML and other specification techniques. COSMIC-FFP introduces new concepts (viewpoints and layers) for measuring functionality delivered by non-business applications software.

4. COMPARISON OF FPA AND COSMIC-FFP FOR NON-BUSINESS APPLICATIONS SOFTWARE

The following section illustrates how the conceptual differences between FPA and COSMIC-FFP affect their capability to measure functional size in non-business applications software.

4.1. Identifying functionality delivered to the end user

In the past, functional size measurements using FPA have usually only included functionality of processes that send or receive data to or from the external user boundary. I.e. FPA is usually used to report the size of the functions delivered to the external business user. In contrast, the end users of non-business software are primarily other software components in either the same or another architectural layer. Many outsourcing pricing models are based on payment for function points delivered (added, changed or deleted) to the end business user. Contention arises when the customer requests infrastructure functionality to be developed or changed and the contract only allows the supplier to charge on function points affected. (E.g. A client request is to improve the performance of all database accesses. The developers do this by modifying the archiving utility software so that its business rules now selectively archive any obsolete data, thus reducing database access time). The quality of the end user functionality (i.e. performance) is improved but the functional size of the business applications software is not considered impacted and therefore, the effort required is not chargeable. FPA specialists consider performance as a general system characteristic rather than functionality changed in software. Issues also arise when a project needs to build infrastructure software in addition to the Business Application software but the infrastructure software is not included in the development project’s functional size. Consequently, the impact on the effort for building the infrastructure software is not adequately catered for by the adjustment for the technical and quality features in the Value Adjustment Factor of the Business Application. The COSMIC-FFP approach, from the functional user requirements perspective instead of external user view, enables the functionality delivered by non-business software, residing in other architectural layers, to be consistently identified and effectively measured. It provides specific guidelines on how to identify software delivered in different architectural layers and how to size their interactions. I.e. when estimating projects, it enables infrastructure software, which supports the Business Applications, to be effectively sized, and their productivity rates and resource estimates to be separately established.

4.2. Measuring internal and external sub-processes

FPA measures functionality by evaluating the amount of data that crosses the external boundary during the processing of the process. The processes within Business Applications software tend to be primarily involved with entering and extracting data so the amount of data movement is a good indicator of overall process size. However, problems arise with non-business software where there is significant internal processing (eg. Read and Write data movements) compared to the processing required to move the data into or outside the boundary. This poses a problem in outsourcing contracts where the performance of the suppliers is measured in Function Points delivered. Since any process that has significant internal processing, but little external visibility, will not be sufficiently accredited for the full amount of functionality it delivers, this will result in low-recorded productivity rates for the project. Although considerable effort may have been expended adding or changing the internal logic within a process, if it only accepts a minimal number of data items then its FPA function points will be low. For example, a process, which receives the coordinates of a radar system and only sends out confirmation or an alarm, may have significant internal processing to check positioning and identify exception conditions (eg. accesses many control and reference tables). FPA only measures the external data movements and restricts the ‘recognition’ of data accesses to a maximum of three, which often does not represent an adequate measure of the functionality delivered by this process.

In comparison, COSMIC-FFP measures all the unique sub-processes within a process, i.e. not only the data entering and exiting the process but the internal sub-processes of reading and writing to the data groups. By measuring and recognising all the functionality that a process is required to deliver, rather than just the external aspects of a process and limited data accesses, it captures the full complement of functionality for estimating and productivity comparisons.

4.3. Categorising processes which do not have predominant role

FPA requires a process to have a predominant role of either entering or extracting data. This predominant role determines the process type (Input, Output or Enquiry). However, the processes within non-business software tend not to have a predominant role making them difficult to categorise unequivocally into one of those process types, since they often:

• Accept data which enters one side of the application boundary, process it and send the results immediately externally across the boundary to another application in another layer. (e.g. translation process in a gateway protocol converter or extraction process in screen scraper software)
• Involve the processing of multiple and variable sets of incoming data and outgoing data. Neither side of the process is predominant (e.g. processes in real-time equipment monitoring).

It is difficult to consistently measure these types of processes since the same process may be categorised differently each time it is sized, resulting in a range of reported functional sizes for the same application. I.e. different people will justifiably categorise the same process as an Input, Output or Enquiry each of which will be allocated a different number of function points. Variations in counting results cause contractual disputes, particularly when performance targets fall within the error boundaries of the measures. Variations in count results also undermine the credibility of Functional Size Measurement as a valid means of consistently measuring size.

In comparison, COSMIC-FFP assesses sub-processes within processes. The number of points awarded is independent of the type of sub-process; just its existence is recognised. Since the direction of the data movement for a sub-process is quite obvious, variations in categorisations are uncommon. However, since all sub-processes are attributed one unit of functional size irrespective of type, any errors or variations in categorisation do not affect the measured size of a process. The resultant size tends to be more consistently measured.

4.4. Sensitivity to large variations in functionality delivered by processes

The FPA rating scale used to award function points to a process increases by just over two fold between the points awarded for the simplest process (e.g. Low complexity input is awarded 3 points) and the points awarded for the most complex process (high complexity output is awarded 7 points). The coarseness of the FPA measure is usable and acceptable for business applications where, in most cases, a two-fold difference in size is representative of the range of functionality delivered by most processes. The categorisation of size using ‘ranges’ also assists in the speed of function point counting with the IFPUG method.

However, the processes delivered by non-business software have been found in practice to deliver a much broader spectrum of functionality than a two-fold difference in size. Yet, no matter how complex the functionality delivered by a process IFPUG FPA cannot award it points beyond the maximum upper limit. This can cause significant errors in estimates of effort for a requirement to change a number of very complex processes. This is a concern in an outsourcing contract where a requirement of the contract is to provide fixed price estimates on projects using historical productivity rates.

The COSMIC-FFP measure is not restricted to awarding a maximum number of points to any one process. It is therefore much more sensitive to large variations in size of processes experienced in non-business applications.

4.5. Measuring process-rich, data-poor software

FPA measures the data groups accessed by the processes as one of the major contributors to functional size. FPA is based on the concept that maintaining and reporting on data is the software’s primary role. It includes within its total size the function points awarded to the logical data groups accessed by the application. These data groups also contribute to the functionality attributed to each process that accesses the data groups. However, non-business software does not have the same emphasis on stored and maintained data. Their processes often operate by referencing relatively static threshold values and parameter controls to make decisions on the data to output. The processes may involve multiple unique sub-processes which reference and update fields in these data groups but the data itself is often minimal compared to the many steps to analyse it and react appropriately. The data input to the process is not usually permanently stored but used for the duration of the process. The permanent data that is accessed is relatively simple and usually consists of historical logs, threshold values or parameter controls.

Difficulties arise when using FPA to measure non-business software since FPA uses the amount of stored data as a significant factor in determining the functional size of the application (usually contributes around 25% - 30% of measured size). Where the stored data is simple but the processing of the stored values is complex, the functional size of the application is underestimated. In contrast, COSMIC-FFP determines the size of a process by measuring the number of unique accesses (Reads and /or Writes) to data groups with no upper limit on the number of Data Groups accessed by a process. Thus, COSMIC-FFP gives a better indication of size for applications that have a few groups of simple data but complex use of that data. COSMIC-FFP also measures both the Read and Write accesses as two sub-processes within a Process, compared to IFPUG FPA, which does not recognise additional logic to both extract data from a data group and update it in the same process.

6. CONCLUSION

All software developed and supported by the supplier in an outsourcing contract, needs to be able to be measured in order to provide input into performance monitoring. This software usually includes applications, which do not deliver functionality directly to the human business users. Experience showed that the IFPUG FPA functional sizing technique was not well suited to measuring software that has other software (particularly in other architectural layers) as its primary users. Early industry results have indicated that the COSMIC-FFP technique provides a more effective method of measuring these infrastructure, real-time, embedded and process control software applications (non-business software), than IFPUG FPA.

COSMIC-FFP’s ability to measure consistently across layers, in a repeatable way, by different people, and effectively (i.e. measure all the functionality delivered by these types of applications), makes it a good candidate to be considered when measuring all the software involved in monitoring a contract.

7.BIBLIOGRAPHY

Abran, A., Desharnais, J.M., Oligny, S., St-Pierre, D. and Symons, C. (2003) “Measurement Manual – The COSMIC Implementation Guide for ISO/IEC 19761: 2003, version 2.2”, Software Engineering Research Laboratory, École de Technologie Supérieure, Université du Québec, Montreal, Canada, 2003. Downloadable at http://www.gelog.etsmtl.ca/cosmic-ffp

Abran, A., Symons, C., Desharnais, J.M., Fagg, P., Morris, P., Oligny, S., Onvlee, J., Meli, R., Nevalainen, R., Rule, G. and St-Pierre, D., “COSMIC-FFP Field Trials Aims, Progress and Interim Findings,” 11th European Software Control and Metric Conference - ESCOM SCOPE 2000, Munich, Germany, 2000.

Desharnais, J.M., St-Pierre, D., Oligny, S. and Abran, A., “Software Layers and Measurement,” International Workshop on Software Measurement – IWSM, Lac Supérieur, Québec, 1999.

Desharnais, J.M., Abran, A. and St-Pierre, D., “Functional Size of Real-Time Software,” 11th International Conference - Software Engineering and its Applications, Paris, France, 1998.

Desharnais J.-M., Morris P., Post Measurement Validation Procedure for Function Point Counts, Position Paper Forum on Software Engineering Standards Issues, October, 1996.

ISO, ISO/IEC 14143-1998 – Software Engineering – Software measurement – Functional size measurement – Part 1: Definition of concepts.

IFPUG Counting Practices Manual Release 4.2 Series – International Function Point Users Group 2004

ISBSG Release 9 Benchmarking Repository – WWW.isbsg.org

Morris, P. and Desharnais, J.M. ‘Measuring All the Software not Just What the Business Uses’, IFPUG Fall Conference, Orlando, Florida, Sept. 21-25, 1998.

Morris, P,’ Similarities and Differences between IFPUG and COSMIC Functional Size Measurement Methods’ IFPUG Arizona, USA, September 2003

Morris, P ‘Using FPA in Project Governance’, Key Note Address, IEEE Metrics Conference, Sydney Australia, September 2003.

Morris, P.;’ Impact of Standardization on Functional Size’, AEMES conference, Madrid, Spain, October 2005

Reifer, D. J. (1990), ‘Asset-R: A Function Point Sizing Tool for Scientific and Real-Time Systems’, Journal of Systems and Software, Vol. 11, No. 3, March, 1990, pp. 159-171.

St-Pierre, D., Desharnais, J.M., Abran, A. and Gardner, B., “Definition of When Requirements Should be Used to Count Function Points in a Project,” in The Voice 1996 - A publication of the International Function Point Users Group, Vol. 1, no 1, 1996, p. 6-7, 22.

St-Pierre, D., Abran, A., Araki, M. and Desharnais, J.-M, (1997c), Adapting Function Points to Real-Time Software, IFPUG 1997 Fall Conference, Scottsdale, AZ, September 15-19, 1997.

Symons, C., Abran, A., Desharnais, J.M., Fagg, P., Goodman, P., Morris, P., Oligny, S., Onvlee, J., Nevalainen, R., Rule, G. and St-Pierre, D., “COSMIC-FFP - Buts, approche conceptuelle et progrès,” presented at ASSEMI, Paris, France, 1999.

Symons, C., Abran, A., Dekkers, C., Desharnais, M.M., Fagg, P. Morris, P., Onvlee, J., Nevalainen, R., Rule, G. and St Pierre, D., “Introduction and Overview of Principles,” Japanese Function Point User Group - JFPUG, Tokyo, Japan, 1999.

Whitmire, S. A. (1992), ‘3-D Function Points: Scientific and Real-Time Extensions to Function Points’, Proceedings of the 1992 Pacific Northwest Software Quality Conference, June 1, 1992.

About the Author

Pam Morris is the CEO of Total Metrics, founded in 1994 in response to the software industry’s need to better manage and control their software development processes. She has a B.Sc., Graduate Diploma of Computing and Diploma of Education from La Trobe and Monash Universities, Australia.

She is the past president of the Australian Software Metrics Association (ASMA) where she currently holds a position on their Executive and the Benchmarking Database Special Interest groups. She represents Standards Australia as the international project editor of the ISO standard 14143-1 and 2 for Functional Size Measurement. She was the international convenor of ISO/IEC/WG12 group developing FSM standards from 1997 to 2004. She plays an active role internationally in the development of measurement standards and she was a member of the International Function Point User Group (IFPUG) Counting Practices Committee in the USA from 1993 to 2000. She is a member of the COSMIC-FFP Core Group that is responsible for the development of the COSMIC-FFP FSM method. She has been an IFPUG Certified Function Point Specialist (CFPS) since 1994 and a Certified Software Measurement Specialist (CSMS Level 3) since 2006.

Pam has provided consulting services and presented training courses to over 200 corporate and government organizations in the USA, Japan, Australia, India and New Zealand since 1991.

Author Contact Information
Post: Total Metrics
Suite 1, 667 Burke Road
Camberwell Victoria 3124 Australia
Email: pam.morris@totalmetrics.com
Phone: 61(0)3 9882 7611
Fax: 61(0)3 9882 7633
Visit us http://www.totalmetrics.com/