You intuitively know that the scope of your software development project determines your team size, schedule, and budget. How do you measure software project scope, especially when you don’t have much information to go on?
Episode 3: Sizing Terms & Metrics is part of our Software Size Matters video series that explores how you not only can, but should be using software size measures at every stage of software project, program, and portfolio management. In Episode 1, we introduced QSM's Software Lifecycle Management top-down scope-based project estimating simulation model. In Episode 2, we explained why quantifying software size is so important. In this episode, we'll discuss sizing terms and metrics you're likely familiar with and already using.
Watch Episode 3: Sizing Terms & Metrics
Size is one of Five Core Metrics used to understand and manage software projects.
The average values for schedule, effort, quality, and productivity increase nonlinearly with size. Thus, you can't meaningfully compare proposed or actual performance metrics without factoring in size. Every productivity metric captures units of input per unit of output. If you can't quantify the output, you can't calculate productivity. Now that we've reviewed a few reasons why quantifying software size is so important, understanding sizing terms and metrics tells us how size is measured.
Before we quantify software size and explore size metrics, we need to understand what we are measuring. Size is the output of the software development project. It is the features and functionality built for end users. Time, effort, and cost are the inputs needed to create deliverable features and functionality. Defects are mistakes in the features that must be fixed so they work correctly. It's easy to think of software project size in terms of dollar amounts, team sizes, or schedules. What you really need to know is what was produced with the time and money.
Software size is a proxy for the work done to produce the software product. It's not how long it takes to do the work or how many hours are spent, but the actual work. A good analogy is the square footage of your home. That is a size measure.
Never mind how fancy your home is on the inside or outside, in a particular location, the square footage is an excellent indicator of the cost and time it would take to build it.
QSM has been collecting and analyzing software size data for over 47 years. These are the metrics we use. Three metrics are used to quantify size:
- Function Unit - a countable entity used to capture estimated or delivered size 310 requirements or 875 function points.
- Base size unit - is a normalized line of code equivalent. It provides a common baseline for comparing projects measured in different function units. You can think of it as the most elementary development step.
- Gearing factor - a conversion factor. The average number of steps required to implement a requirement, function unit, or other function unit.
A breakout of new, modified, and unmodified functionality classifies the type of work to be done:
- New - code or features created for the new release
- Modified - pre-existing code or features changed for the current release
- Unmodified - preexisting code or features used as is in the current release.
Software project estimates and forecasts are based on new plus modified size percentages because they require work. Unmodified percentages are excluded from the size estimate but can be used to adjust productivity.
You are probably familiar with these function units and have used one or more of them:
- Requirements - Software project scope definition usually starts with a list of requirements. This is an abstract unit because people think of them differently and in varying levels of decomposition, but they are useful nonetheless.
- Epics, Features, Stories, Story Points - Agile development methods have greatly improved the use of software size metrics.
- Function Points - Function Points work well for business applications and are backed by the International Function Point User Group standard.
- RICEF (Reports, Interfaces, Conversions, Extensions, Forms) – RICEF objects are a good way to quantify the customization of commercial off-the-shelf packages, and
- SLOC - Source Lines of Code are typically used in embedded avionics and engineering software disciplines.
There are many function units that fit different application types and development methods.
Multiple function units are often used to quantify software size for a single project or release because they can express the level of decomposition. Where you are in the project lifecycle dictates the amount and type of data you have available. As the scope is decomposed into manageable chunks, more data becomes available. For example, epics can be broken down into features, which are further divided into stories, and estimated using story points. Multiple functions can correspond to identifiable components used for a particular application, like reports, data conversions, or forms.
Converting function units to the normalized base size unit enables the best practice of sanity-checking software project estimates against historical data, and benchmarking completed project performance against QSM industry trends or your data.
To summarize:
- Software Size is one of five core metrics used to estimate and manage software projects. Effort, time, defects, and productivity all increase nonlinearly with size. Size matters, so we need to understand what we're measuring.
- Size is the output of the software development process. It is a proxy for the work to be done, a key input for software estimation, tracking and forecasting, and performance benchmarking.
- Familiar Function Units are used for different technologies and development methods. You are likely using some of these now.