Software Sizing

Software Sizing

6 Essential Software Sizing Resources

Software Project Sizing

Project managers and estimators have long struggled with the issue of how to measure software size. Really, before you can calculate cost and schedule, you will need some notion of how big the project will be. There are myriad of ways to size a project depending on the methodology you use and where you are in the planning process. Here at QSM, it's one of the common questions we receive, so we've devoted many years of research to the topic. Our website features a wealth of resources on sizing and in this post, we will highlight a few of the most valuable for anyone grappling with this issue or looking for a place to start.

General Sizing

  • QSM's Software Sizing infographic is a great place to start. This easy to understand visual resource helps explain the most popular sizing methods and when to use them, the difference between functional and technical size, sizing challenges and more!
  • Measuring Software Size - Insights from the Past to Guide the Future is another helpful guide if you're struggling with which sizing units to use. This PDU-approved webinar will help you determine what sizing measure will work for you based on your own historical data. This presentation is worth a watch no matter what development methodology you use and can help improve future estimates and in-flight project forecasts.

Function Points

Blog Post Categories 
Sizing Software Sizing Estimation

How Can We Fix the Disconnect Between Software Vendors and Their Clients?

QSM is a leading demand and vendor management company. We have many years of experience working with outsource management professionals, evaluating software project vendor bids and monitoring the development progress of those bids for our clients. We are often hired to help them with their vendor management process because their past projects have failed to meet cost, effort, reliability, and duration expectations. 

It starts with the independent estimate and bid evaluation process. Our main clients are CIOs, PMO managers, purchasing managers, software project managers, and business stakeholders. Our clients will usually have a large software development or package configuration project pending. They are initially trying to figure out which vendor to hire. Vendor A will offer them a bid of 20 million dollars with a specified duration commitment and Vendor B will offer them a bid of 30 million dollars with a different duration commitment. How do we know which vendor to choose? Can Vendor A really finish with a lower cost and shorter schedule? Is the system going to work when it’s done?

The way it usually works is the client will make a decision based on their experience or gut feel. Or if they have already worked with a specific vendor in the past they will go with that vendor again based on some personal relationships that have evolved. Then the problems start. The work that was promised doesn’t get done within the promised time or the promised budget. The vendor then comes back and says they will add people to the project and everything will be ok. The client approves the revised project plan since they don’t have a way to confirm the accuracy of the revised proposal. Then even bigger problems start. More money is wasted, the schedule slips even more, and relationships sour.

The Lowly Line of Code (Part One)

“I'm sorry, Dave. I'm afraid I can't do that” – HAL 9000[1]

Source lines of code (SLOC) is a measure of software size, in use since the 1960s. This blog post describes various uses of SLOC from the perspective of software measurement.

There seems to be a love/hate relationship with the line of code measure. Despite its broad and continuous use (or perhaps because of it) SLOC seems to get the blame for many a failed software project, process improvement or software metrics initiative. There are even those who claim that “…in many situations usage of LOC metrics can be viewed as professional malpractice…”[2] But, as you will see, SLOC has many benefits, when used intelligently.

Blog Post Categories 
Metrics Sizing Software Sizing

Averages Considered Harmful

Arithmetic mean (aka average) is often a misleading number. One reason for this is that mean is sensitive to outliers. A very large or a very small value can greatly influence the average. In those situations a better measure of center is the median (the 50th percentile). But there is a second huge pitfall awaiting anyone using average for estimating or benchmarking: software size.

Even though we know that software size has a major influence on the key metrics (e.g., effort, duration, productivity, defects) many people insist on reporting and comparing and using the average value. Let’s look at an example. Consider a sample of 45 completed telecommunications application type projects. Picking one of the key metrics already mentioned, duration of phase 3, we can generate a histogram and calculate the mean. The average duration is 27.5 months. Does this tell us anything useful?

Number of Software Projects vs. Duration

The histogram of durations shows a skewed distribution (many projects have a shorter duration, few have a long duration), so we will need to do some sort of normalization before the average is a measure of center.  And even then, what about size?  In a typical SLIM scatterplot of duration versus size for these projects, we can see that in general larger projects take longer than smaller ones.  

Blog Post Categories 
Software Sizing

Software Project Size and Road Construction

Software Project Size and Road ConstructionI have been a software project estimator for 20 years.  Like many people who have worked a long time in their profession, I find myself applying my work experience to other events in my life.  So, when a family member tells me that he or she will be back from a trip into town at 3:30, I look at their past performance (project history) and what they propose to do (project plan) and add an hour.  Usually, I am closer to the mark than they are.

Blog Post Categories 
Software Sizing Estimation

Webinar - QSM's Software Sizing Infographic: A Visual Aid for Understanding Software Size

On Thursday, March 26th at 1:00 PM EDT, Joe Madden will present QSM's Software Sizing Infographic: A Visual Aid for Understanding Software Size.

Software size, the amount of functionality in a given software release, is arguably the most critical 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. In this webinar, Joe Madden will give an overview of QSM's Software Size Matters Infographic, which addresses the challenges of measuring software size and identifies the most popular sizing methods and when to use them. With over 17 years of software sizing experience, Joe will provide case studies and best practices for real world application.

Joe Madden currently leads the QSM consulting division which has grown dramatically in the past six years and offers a wide range of professional services. These include the software estimation center of excellence, function point analysis, program and portfolio management, independent verification and validation, vendor management, benchmarking and process improvement, and expert witness services. A longtime client of the QSM SLIM Tools Suite and co-author of the book, "IT Measurement: Practical Advice from the Experts," Joe has more than 23 years of experience in IT management and consulting.

Blog Post Categories 
Webinars Software Sizing

How Much Software Is in your Car? From the 1977 Toronado to the Tesla P85D

It’s easy to imagine there is a lot of complex computer software code required to operate and control a fully autonomous self-driving car, such as the prototype recently unveiled by Google, and that advanced systems engineering and software life cycle management techniques are required to successfully manage its development.  However, you may be surprised to find out that nearly every vehicle under 30 years old on the road today also depends on computer software - and lots of it.

According to an IEEE Spectrum article by Robert Charette entitled: “This Car Runs on Code,” the first production car to incorporate embedded software was the 1977 General Motors Oldsmobile Toronado which had an electronic control unit (ECU) that managed electronic spark timing.  By 1981, GM had deployed about 50,000 lines of engine control software code across their entire domestic passenger car line.  Other auto manufacturers soon followed the same trend.   

Automotive Software Size

1977 General Motors Oldsmobile Toronado (image source)

Blog Post Categories 
Software Sizing Project Management

Introducing QSM's Software Sizing Infographic

QSM Software Sizing Infographic 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.

Blog Post Categories 
Sizing Software Sizing Estimation

Ask Carol: With Software Sizing, If You Don't Know the What, You Can't Estimate the How

Software Sizing and Project EstimationDear Carol: 

I’m a developer in our IT department and we know that project estimating is a big deal for our customers.  Somehow, no matter what we do, we can't seem to get it right.  We do know that project size is an important input to good estimating  and our gut feel is that if we get sizing right, we’ll do better estimates!  I know you recommend using function points, but I’ve also been reading a lot about use case points, story points, SLOC, sizing by analogy, T-shirt sizing, COSMIC and other sizing metrics.  We do a mix of waterfall, agile, iterative and even Kanban to do our projects so what’s the best choice for sizing to get the best results? 

- Size Challenged in Milwaukee

Dear Size Challenged:    

Sometimes I wonder if the internet and the proliferation of (mis)information is a good thing. Before the internet, our choices (for sizing or estimating or anything) were limited and we didn’t have such an overwhelming task to first sift through many options before taking action.  Your list of software sizing choices is an example of this. 

Blog Post Categories 
Software Sizing Estimation Ask Carol

Function Points: A "Mousetrap" for Software Sizing?

Sometimes business life follows literature. Recently, I came across the following quote and I had to pause:

“Before we build a better mousetrap, we need to find
out if there are any mice out there.” - Yogi Berra

It reminded me of a conversation I had over lunch 15 years ago, when I was president of the International Function Point Users Group (IFPUG) and Charles Symons was president of the UK Software Metrics Association (UKSMA), where we were talking about the future of software sizing.  IFPUG is the inventor of the original method to size software using a measure called “Function Points.”  Charles is the creator of a similar UK method called Mark II function points and a co-creator of the Common Software Metrics International Consortium (COSMIC) sizing method that was, at the time, still in its infancy.  I’m paraphrasing with the words but I believe it captures the content of our conversation:

“The problem with function points,” Charles remarked, “is that they aren’t yet perfect enough.  What we need is a better mousetrap and the world will beat a path to our door.”

I disagreed saying “I don’t think that’s the problem at all – I think the problem is that world doesn’t yet see mice as a problem.”

Blog Post Categories 
Software Sizing Function Points