Software estimation is a topic of considerable discussion and frustration in many circles. Managers want/need to know how much it will cost and how long it will take to build/deliver. Developers typically push back on providing estimates because they are often mishandled.
ScopeMaster was conceived as a tool to perform automated functional size estimates of software. The reason I set out to write a tool to do this is because, as a software project manager, functional size is one of the single most important pieces of data, metrics that I need to manage a project successfully.
Functional Size measurement (FSM), is a universal means of measuring software size. It is independent of the coding language used to develop it. FSM has been around for many years and has established a solid reputation for being the most reliable measure of software measurement. FSM allows you to measure size before, during and after the code has been written.
FSM is a methodology that requires you to read and interpret requirements and specifications, and then assign the functions points – Function Points.
Software Size First
Software size is the single most significant metric that can be adopted on software projects, from which other metrics can be derived. For example, once you know the size, you can go on to derive defects predictions, resources needed, time it will take to develop and more.
COSMIC Functional Sizing
Over the years, several variations of functional size metric have been created. Only five have achieved ISO recognition (COSMIC, IFPUG, Mark II, NESMA and FiSMA). IFPUG, Mark II, NESMA and FiSMA are all similar in that they are derived from the original ruleset created by Allan Albrecht back in the 1980’s. The COSMIC functional size methodology evolved from earlier methodologies, specifically designed to address the shortcomings of them. The key advantages that make COSMIC more relevant to modern software are:
- COSMIC FSM is designed to handle interconnected software layers – suited to modern software architectures.
- COSMIC measurements can be made before all requirements are known – highly suited to Agile development.
- COSMIC FSM is principle (not rules) based – easy to learn
Function Points and Story Points
Story points are prevalent across all Agile projects, they are a team-specific proxy measure for effort. By this, I mean that each team has a common understanding of the magnitude of a story point, it is typically in the order of a few hours of effort, but there are no strict rules. I saw one organisation that had 6 teams each of which had a different understanding of the size of a story point. Story points are not a universal currency, they are not a standard, they cannot reliably be used to compare teams or projects. Story points are a useful internal indicator of anticipated effort. Function points however are universal, standard and highly applicable to Agile development as much as any other development methodology. I advocate, continue with story points at the team level, but use function points for everything else.
Size is the cornerstone of Estimates
Once you know the size in function points (CFP), you can quickly establish other metrics that are directly related to size, such as cost, effort and schedule.
What can you estimates based on size
- Schedule (number of months needed to deliver)
- Cost (total cost to design, develop, test and deliver)
- Effort / Resources (effort needed to design, develop, test and deliver)
- Quality (defect potentials for each constituent of the delivery)
How fast can you derive size estimates
Manually, a competent analyst can count (measure) function points at a rate of about 100-500 FP per day. This depends on the quality and clarity of the requirements and specifications. The speed also depend on the experience and ability of the analyst. Thats in the order of $100k – $500k ‘s worth of software.
Automated Sizing with ScopeMaster
Using ScopeMaster, the rate of sizing is increased dramatically, we have found it to be consistently four times faster. ScopeMaster “reads” the requirements identifying language patterns that implicate functional need. It can read and estimate size at about 3 CFP per second. A review by an experienced analyst is necessary to a) correct mistakes in requirements and b) verify the functional size of each requirement. Once verified by the analyst, the estimate becomes an exact count/measurement.
Once the size in CFP is established you can then use industry conversion values that map function points to effort, cost and schedule. Rather than use industry conversions, you can use your own historical project data to establish your own benchmarks.
To do this, take a few past projects, insert their requirements into ScopeMaster to get the functional size. Given that you (should) know the cost, effort and schedule of those projects. You can then use that data to predict the next project.