If you were unable to attend our recent webinar, QSM's Software Sizing Infographic: A Visual Aid for Understanding Software Size, a replay is now available.

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 gives 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 provides case studies and best practices for real world application.

Watch the replay!

When an organization wants to proactively manage their software activities from inception through development and sustainment, an enterprise software estimation or acquisition Center of Excellence (COE) is a great solution.  A significant portion of our professional services business at QSM is helping companies design and stand up enterprise COE operations. 

There are three main components to a successful COE implementation.  They are:

1. People – Finding people with the right characteristics and developing their skills;
2. Business Processes – developing the right business processes to support decision making; and
3. Tools – Acquiring and configuring analytical tools to support the business processes.

Our clients often ask us to identify the best characteristics and skills for a person that they plan to staff into a COE.  We went back and looked at our most successful implementations, and here is what we found.

Ideal Enterprise COE Skill Set:

There is an old adage that if your only tool is a hammer, everything looks like a nail.  We use the lessons learned and experience we have gained to address current issues.  But if the problem (or software project) we face today is fundamentally different from those we’ve dealt with previously, past experience isn’t the proper framework.  In effect, we will be using a hammer when a saw or a chisel might be the tools we need.

The solution, of course, is to first gain an understanding of the problem at hand.  What are its defining features?  How does it behave?  Only then can a proper solution be designed and the appropriate tools selected.

To a large degree, our understanding of how products are developed comes from knowledge gained from manufacturing since the beginning of the Industrial Revolution.  Mentally, our first instinct is to try to apply those lessons learned to software development.  But there is a huge problem with this approach. The creation of software is not a manufacturing process, but rather a knowledge acquisition and learning process that follows different rules.  Here is a simple example.  If I have an assembly line and want to double my output, I have several choices.  I might add a second shift of workers or I could install an additional assembly line.  Because manufacturing is a repetitive process in which design problems are solved before product construction begins, the relationship between labor required and output remains fairly constant.  In a nutshell, we already know exactly what we need to do (and how to do it).  

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.

On large software development and acquisition programs, testing phases typically extend over many months. It is important to forecast the quality of the software at that future time when the schedule calls for testing to be complete. In this article, originally published in CrossTalk, Paul Below shows how Walter Shewhart’s Control Charts can be applied to this purpose, in order to detect a signal that indicates a significant change in the state of the software. This signal detection is then used to improve mapping of project progress to forecast curves and thereby improve estimates of project schedule.

At QSM, we have one of the largest industry databases in the world of completed software projects. The data comes from our clients with their permission and this data has been the backbone of our software estimation business for over 35 years. We can see what is reasonable on software development projects as it relates to cost, team size, effort, duration, size, and reliability. Because of our experience we are often asked about risk factors and estimation accuracy early in the project lifecycle. We explain that increased accuracy comes with having historical data and good sizing information.

But what happens on the early estimates when clients don’t have history and detailed sizing information? Can they still generate scope level estimates so they can make good business decisions? The answer is yes. Risk management techniques can be applied and project uncertainty can be calculated so organizations can plan effectively. This is very important because big business decisions are often made early. Decision-makers need to know if they should move forward with a project and they need to know how much time and effort to allocate.

We use SLIM-Estimate, which is a leading estimation tool that leverages the Putnam Model. It generates reliable estimates based on QSM’s time-tested forecasting models and historical data and it also provides scope level estimates when project information is hard to find. It will allow you to see the chance you have of hitting your project goals and it will allow you to factor in your uncertainty.