Software size, the amount of functionality in a given software release, is arguably the most important of the five core metrics of software estimation. There is little point in tracking effort, duration, productivity and quality if you are unable to quantify what you are building.
Yet, despite its critical importance, software sizing is often a difficult concept for many to understand and use properly in the estimation process. Sometimes a picture is better than 1,000 words. With that ideal of visual simplicity in mind, we developed a software sizing infographic that helps explain:
- Why we care about size
- Challenges in sizing
- When size should be measured during the software development life cycle (SDLC) to narrow the cone of uncertainty
- The difference between functional and technical size
- The most popular sizing methods and when to use them
The infographic begins by introducing the five core metrics of software estimation (size (scope), schedule (duration), effort (cost), quality (defects) and productivity) and the nonlinear relationship between them.
Next it outlines the four generic phases in the software development life cycle and why estimators need to use different sizing methods, depending on where the project is in the life cycle and what information is available. At each stage of the software development life cycle the cone of uncertainty narrows and the number of sizing techniques that can be used increases as more information is known about the project and the required functionality.
It then introduces the concepts of functional size and technical size and how every sizing method can be normalized to a common unit.
- Technical size is the amount of software logic (source lines of code or configurations to a commercial off-the-shelf package (COTS)) that creates the functionality. All technical sizing methods can be converted to implementation units (IUs). An IU is equivalent to writing one source line of code or one technical step in configuring a commercial COTS package. Developers typically care more about technical size than functional size because it is a measure of how much technical work they need to do.
- Functional size is a technology-independent measure of the amount of software functionality delivered to the end user. All functional sizing methods can be converted to function points (the most widely used ISO standard for functional sizing is the International Function Point Users Group (IFPUG) method). Function points can, in turn, be converted to IUs based on the QSM Function Point Languages table. End users typically care more about functional size than technical size because it represents the software functionality that provides business value to them.
Building on the above concepts, it next provides a table of the most common sizing methods with definitions.
- Examples of functional sizing methods include higher levels of abstraction (e.g. business requirements, epics or use cases), medium levels of abstraction that can be prioritized for planning purposes (e.g. functional requirements, functional capabilities or user stories) and low level ISO standard function point techniques (IFPUG, COSMIC, MARK-II, FISMA, NESMA).
- Examples of technical sizing methods include business process configurations and RICEFW objects, technical components (screens, reports, forms, tables, etc.), source code files and source lines of code. (Note: RICEFW is an acronym that stands for reports, interfaces, conversions, enhancements, forms and workflows which represent customizations to a COTS package.)
Finally the infographic summarizes the whole sizing process by overlaying the cone of uncertainty with the four software life cycle phases and the recommended sizing methods for each phase.
When combined with our workshop in software sizing, this infographic is a useful visual reference that puts you on the fast track to more successful estimation.