Guide to Choosing a Functional Size Method

There are currently four FSM Methods approved by the International Organisation for Standardisation (ISO). SCOPE currently records IFPUG Functional Size, but it planned to incorporate COSMIC FSM in future versions:

• COSMIC - ISO/IEC 19761 SOFTWARE ENGINEERING – COSMIC-FFP – A FUNCTIONAL SIZE MEASUREMENT METHOD
• IFPUG - ISO/IEC 20926 SOFTWARE ENGINEERING - FUNCTION POINT COUNTING PRACTICES MANUAL.
• MKII - ISO/IEC 20968 INFORMATION TECHNOLOGY - SOFTWARE ENGINEERING - Mk II FUNCTION PONT ANALYSIS - COUNTING PRACTICES MANUAL:2002
• NESMA - ISO/IEC 24570 INFORMATION TECHNOLOGY – DEFINITIONS AND COUNTING GUIDES FOR THE APPLICATION OF FUNCTON POINT ANALYSIS

ISO has recently published a guide to choosing the method most appropriate for your needs (ISO/IEC 14143: Part 6) . Key points needed to be considered are the following:

• Applicability to the domain of software that you need to measure. As a guide most organisations that develop or support ‘data rich’ software (i.e. Management Information Systems, Banking, financial, CRM, Asset Management, Work flow systems etc) use the IFPUG method. Organisations that develop or support ‘process rich’ or real time software tend to use the COSMIC method.
• Availability of equivalent Industry data. If you need to use Industry data for comparison of productivity or as input into estimates then this may be a deciding factor. The ISBSG repository has >90% of projects measured with the IFPUG method, but the proportion of COSMIC projects is increasing rapidly as the COSMIC method becomes more widely used.
• Availability of training and FSM tools. Most of the Industry leading tools e.g. SCOPE Project Sizing Software^® have been written to measure using the IFPUG method, but will also offer a version in the future that uses the COSMIC method, as its use increases.
• Availability of trained experienced certified Metrics experts. Currently most people are trained and certified in the IFPUG method which is offered in most countries, but COSMIC training and certification is now being offered in Europe, North America and Australia.

How hard is it to measure Functional Size?

Functional Size measurement requires specialised training of 2 to 3 days duration. After training, it typically takes several months of using the technique, measuring in a variety of situations to become proficient. International accreditation usually requires the measurer to have a skill level of at least 2 years experience in using the technique. Most organisations train a select group of software developers for the measurement role. It is similar to other specialist activities e.g. Database Design, it takes a person skilled in business analysis and attention to detail to make a good Functional Size Measurement Specialist.

How do we effectively manage the Functional Size Results?

Whilst Functional sizing can be performed by recording the results in a spreadsheet, experience shows that this approach has proved to be very high risk which are mitigated by using a specialist FSM tool such as SCOPE Project Sizing Software^®. Problems we have experienced with clients using spreadsheets are as follows:

• Results are hard to check for correctness or completeness: There is no capability to ‘model’ the functional requirements, and long lists of functional processes (often thousands) are very hard to track. It is very difficult for the applications expert to determine if the measurer has missed any of the requirements from the measured project size. Omissions will result in under estimating the effort and cost of the project.
• Size Calculation formulas are prone to Corruption: Formulas totalling the components of the measurement are prone to have their ranges corrupted as inexperienced users insert rows outside the calculations specified range. In a recent survey of an organisations FP Spreadsheets 100% of those in the sample set were not calculating as originally designed. Errors in their reported size results ranged from 10% to 300%. These erroneous results had been previously extracted into the organisations estimation database and used in estimating other projects. Until the issue was identified the organisation was unaware that they were relying on incorrect results.
• Significant time is wasted every measurement as there is little opportunity for re-use of previous measurements: Each time a new enhancement project is started a new spreadsheet is started. There is rarely a library or cross-reverencing capability to determine if a previous project measurement could be leveraged and re-used. A lot of duplicate measurement is done and often not in a consistent way to previous measures of the same functions. There is no cross-referencing to decisions made in the original base to ensure functions are counted consistently.
• Base Sizes are quickly out of date: If a base measurement was completed for an application or project, change requests are rarely retrospectively applied to keep the base size current; since on a spreadsheet this involves two different acts of measurement recording (Base updates are performed automatically using FSM tools such as SCOPE).
• Configuration control of multiple concurrent projects is very difficult. If multiple Projects are applied to the same application and several people develop concurrent measures of the impact of their projects, then it is a significant cross-referencing activity to determine if the same function is impacted by several projects and to determine the final impact on the base measurement