English
Phone: + 33 (0) 9 80 89 99 65 - Email: contact@estimancy.com
Site logo
Sticky header logo
Mobile logo
English
  • Products
    • Enterprise Application Outsourcing management
    • Software project estimation
    • Tagger, requirements management
  • Services
    • On demand software project sizing and estimation by certified experts
    • E-learning
  • Resources
    • Blog
    • Videos
    • FAQ
  • About us
    • Job opportunities
    • Press kit
  • Contact
  • Online demo
PrevArticle application outsourcingApplication outsourcing: How to control the price of your suppliers?30 September 2019NextVideo: enterprise application outsourcing[#Video] Enterprise Application Outsourcing Management with Estimancy09 December 2019
  • Blog

Software sizing: If you can’t measure it, you can’t improve it!

Software sizing

One of the most important quotes in business management states, “If you can’t measure it, you can’t improve it.”. When you think about this quote, it should immediately become apparent how true it is. It’s like trying to improve your running speed, but never keeping score, so you don’t know if you’re actually getting better or not. The importance of measuring the size of software projects (software sizing) before you start developing is much like looking at a map before starting a road trip or reading the blueprints before building a house.

One can even argue that the ability to measure software size early in the project life cycle (i.e. estimating the size before development) can be the most important resource for software development companies in terms of management and control of project resources.

Software functional size

The primary measurement of software is size, more specifically, functional size. Software size is principally measured in function points. It can also be measured in source lines of code (SLOC) which is functional code excluding comments.

Whilst measuring SLOC is interesting, it is more of an indication of effort than of functionality. Two developers could develop a functionality using different techniques, one might only need to write a few lines of code, and the other might need to write many more lines to achieve the same functionality. The most reliable method for measuring software size is technique-independent and is based on the user’s point of view, in “function points”.

What are Function Points?

The concept of Function Point was first introduced by Alan Albrecht of IBM in 1979. A function point is a “unit of measurement” used to express the amount of business functionality an information system (as a product) provides to a user. Function points are used to compute a functional size measurement (FSM) of software. The cost (in euros or hours) of a single unit is called productivity and is calculated based on past projects.

The most commonly used functional size measurement (FSM) methods are IFPUG (International Function Point Users’ Group) and COSMIC (Common Software Measurement International Consortium) Function points. They are ISO standards.

The IFPUG method

The IFPUG measurement process includes 5 main steps:

  • The first step is to identify the counting scope. The purpose of the count determines the counting scope. This step basically involves determining the type of function point count – development, enhancement, or application.
  • The second step is to define the application boundary. Basically, a boundary indicates the border between the project or application being counted, and the external applications or users. It is very important to draw the application boundary from the user’s point of view and not from the point of view of the technical implementation.
  • The figure bellow shows the functionality as viewed from the user’s perspective and according to IFPUG.
  • The third step is to identify and rate the data functions. The data functions include Internal Logic Files (ILF) and External Interface Files (EIF). Data functionality satisfies the functional user requirements to store and/or reference data.
  • ILF: Logical group of data maintained by the application under study (e.g., Employee file)
  • EIF: Logical group of data referenced but not maintained by the application under study (e.g., Global state table)
  • The fourth step is to identify and rate the transaction functions. The transaction functions include External Inputs (EIs), External Queries (EQs), and External Outputs (EOs). Transaction functionality satisfies the functional user requirements that process data.
    • EI: Maintains an ILF or passes control data into the application under study
    • EO: Formatted data sent out of application with added value (e.g., calculated totals)
    • EQ: Formatted data sent out of application without added value
  • The last step is to calculate functional size. After identifying and rating the data functions and transaction functions, the purpose and counting scope shall be considered when selecting and using the appropriate formula to calculate the functional size. The size of a software project is different from the size of the resulting software product. The resulting measure is called Unadjusted Function Point (UFP). This count specifies the size of the application or the project, based on the functionality provided from the user perspective.
IFPUG

The COSMIC Function Points method

The COSMIC method may be used for software sizing in cases such as business applications; real-time software; infrastructure software such as in operating systems; and hybrids of these. The common characteristic of all these types of software is that they are dominated by functions that input data, store and retrieve data, and output data.

Similarly to IFPUG, boundaries should be drawn between the application under study and functional users.

There are four types of data movement sub-processes (see figure bellow) that should be identified from specifications:

  • An “Entry” moves a data group from a functional user into the software,
  • An “Exit” moves a data group out of the software,
  • A “Read” move a data group from persistent storage,
  • A “Write” move a data group to persistent storage.

The size of a piece of software is then defined as the total number of data movements (Entries, Exits, Reads and Writes) summed over all functional processes of the piece of software. Each data movement is counted as one ‘COSMIC Function Point’ (‘CFP’).

The figure bellow shows the four types of data movements.

COSMIC

Conclusion

Both IFPUG and COSMIC are standard methods to measure the size of a software application. One may wonder which method is more suitable for his/her projects.

Although similarities and differences between the two methods were studied and discussed by multiple studies, the choice between these methods is not as easy as it could appear. Some comparison studies conclude that IFPUG is more suitable for MIS applications and COSMIC is more suitable for real time applications but both methodologies are competing against one another for their place in the software industry as the primary method for sizing software applications.

Another question that is often raised concerns the convertibility between the IFPUG and COSMIC Function Points. When, for example, a part of a business application has been measured in IFPUG FP and other parts in COSMIC function points, which is the real measure of the whole application?

Some researchers namely Desharnais suggest a conversion factor from COSMIC to IFPUG. Multiple studies conclude that the correlation between the two methods depends on the context.

  • Function Points
  • Functional size
  • Software Sizing

Related posts

Blog Video: enterprise application outsourcing
9 December 2019in Blog 0 Comments 0 Likes

[#Video] Enterprise Application Outsourcing Management with Estimancy

Blog Article application outsourcing
30 September 2019in Blog 0 Comments 0 Likes

Application outsourcing: How to control the price of your suppliers?

Blog Procurecon IT Sourcing
15 May 2019in Blog 0 Comments 0 Likes

Estimancy moderates a roundtable at ProcureCon IT Sourcing 2019 in Denver

Blog Big Rock
12 November 2018in Blog 0 Comments 0 Likes

“Big Rock”, how to estimate a budget during an upstream phase

Livres blancs illustration de la mesure de la taille du projet logiciel en points de fonction
10 October 2018in Livres blancs 0 Comments 0 Likes

Software sizing in Function points : the 7 steps

Blog Agilité
2 October 2018in Blog 0 Comments 0 Likes

Why should you use Function Points to estimate agile software projects?

Blog Story Points
25 September 2018in Blog 0 Comments 0 Likes

Story Points vs. Function Points

Blog Application outsourcing
13 November 2017in Blog 0 Comments 0 Likes

Application Outsoucing: Which Type of Contract Should You Choose?

Application outsourcing Estimate Function Points IFPUG Mesure logicielle Points de Fonction Projet logiciel Software project sous-traitance Taille logicielle

Categories

  • Blog
  • Blog
  • Livres blancs
  • White paper
  • enEnglish
  • frFrench

Estimancy

Software outsourcing management

Software project estimation

On demand software project sizing and estimation

Legal notice

Company

About us

Blog

Job opportunities

 

Contact us

Estimancy

USA : 128 Marsh Drive, 31410 Savannah, GA, USA

Europe : 7 rue de la Croix Martre, 91120 Palaiseau, France

EMEA : Salima 2, 115 bat. 9, 11100 Sala Jadida, Maroc

 

contact@estimancy.com

Cookies

Ce site utilise des cookies : En savoir plus.