Practical Software Measurement

Blogs

QSM Function Point Workshop Is Now IFPUG-Certified

Function Point Workshop

QSM is pleased to announce our Function Point Workshop is now IFPUG-certified! This 2 day course focuses on building function point analysis skills to measure software development work products. Students will learn how to express the result in a standard, accurate, repeatable way based on the logical view of required functionality in the business and the end user's perspective. This standard technique promotes consistent sizing across multiple project types, and can be used to support project estimating, application maintenance, and portfolio analysis. Ultimately students will gain an initial understanding of the purpose, context, and rules for counting function points. This course is targeted to attendees with interest levels ranging from high level familiarity with the process to those who are beginning to prepare for certification. 

Learn more about about QSM's workshops and function point offerings.

Blog Post Categories 
Function Points Training

New Article: How Everyone Can Plan for 2017

2017 IT Budgeting

No one got into software development to budget. Developers love to code and create. If they wanted to create budgets, they’d have become accountants. Still, creating a development plan for 2017 is essential and will inevitably require budgeting and estimating, a process that should be done in partnership with business teams. This will ensure the creation of software that cost-effectively meets their needs. In this article, originally published on SD Times, Doug Putnam identifies three strategies for better budgeting and planning in the new year.

Read the article!

Blog Post Categories 
Articles IT Budgeting

New Article: Common Ground Through PPM

Project Portfolio Planning

The most effective project portfolio planning brings IT managers and business leaders together to prioritize, scope and staff initiatives as a single team with common goals. In doing so, the process fosters better working relationships — and provides a roadmap for delivering value to the organization. In this article for Projects at Work, Larry Putnam, Jr. outlines best practices on how to determine the maximum capabilities that can be delivered within the confines of budgets, resources, and time. 

Read the full article!

AI and Automation Make Software Reliability More Important Than Ever

AI and Automation Software Reliability

This post was originally published on Linkedin. Join the QSM Linkedin Group and Company Page to stay up-to-date with more content like this.

If you were thinking about purchasing a driverless car, and the salesperson told you that there’s a “slight” chance that the car will fail during transit, would you still feel comfortable laying down your money? Or, if you faced an emergency, would you trust an automated robot to perform open-heart surgery, rather than the hands of a skilled physician?

While these questions might seem like the stuff of a science fiction novel, they’re quickly becoming a part of our normal, everyday world. We’re hearing a great deal about artificial intelligence and how it is replacing tasks that were once done by humans. AI is powered by software, and that software is becoming increasingly vital to our lives. This makes ensuring its reliability more important than ever.

But here’s a sobering thought: right now, IT operations teams are building software that is, on average, 95% reliable out the door. That’s right; today, a 5% unreliability gap is considered “good enough.”

Blog Post Categories 
Estimation Quality

How Can We Leverage Summary Level Analytics to Support Enterprise Planning?

What if you could leverage summary level cost, duration, and productivity data to support estimates for future projects, at the release and enterprise level? C-level executives, development managers, and project stakeholders are all involved at some level in project planning. They want quick access to information on a regular basis and they want web-based solutions to make it happen. So how does it all work? There are web-based analytics tools that allow you to create a centralized database for all of your projects. These tools store the data, leverage it to generate project and portfolio estimates, and then provide a communication vehicle throughout the organization to ensure that everyone involved is on the same page. It all starts with having the data in one place. 

Software Project Database

Once you have all of your project data in one place, then you can focus on analyzing the completed projects. You can compare them against industry trends and leverage a 5-star report to show how they rate on performance in the industry. The initial measures to focus on would be size, duration, effort, reliability, and productivity. A project's productivity will be calculated automatically once you have entered the size, duration and effort. We call this measure a Productivity Index. This measure can be compared to industry and used as a benchmark to measure process improvements over time.  These numbers give you a quantitative picture of your current project environment.  

Software Project Closeout

5 Star Report

The 2017 Software Almanac: Development Research Series

QSM Software Almanac: 2017 Edition

Software plays an increasingly vital role in our everyday lives. It powers everything from autonomous cars and aircraft, life-saving medical equipment, and the data that allows the government to protect our country. When companies develop software, there’s no room for error. 

That’s why software predictive analysis and estimation are still extremely important. Last year, with the release of the 2016 Software Almanac, we learned that the last 35 years of predictive analytics and estimation principles were still incredibly relevant for providing reliable and applicable business intelligence for implementing successful software projects.

This year’s version of QSM’s annual Software Almanac further strengthens those findings. The 2017 Software Almanac builds on the principles identified in last year’s publication and highlights the dangers of not applying predictive analysis and estimation processes.   As stated by Angela Maria Lungu, Almanac Editor and Managing Director at QSM, these principles can be a “double-edged rearview mirror.” If you move forward without applying the historical principles of estimation and analysis correctly, their value is diminished.   Here’s what else you can expect from this year’s Almanac:

Blog Post Categories 
Articles QSM Database

New Article: Big Rock Estimation in Agile

Agile Big Rock Sizing

Big Rock Estimation: Using Agile Techniques to Provide a Rough Software Schedule / Resource Estimate is the third article in the QSM Agile Round Table series.  The QSM Agile Round Table was formed to discuss the role of estimation in agile environments.  QSM customers shared their questions, challenges, and experiences on the relevance and benefits of scope-based estimation in an agile environment.  The Round Table spent several meetings on the key topic of sizing an agile release. The discussion centered around two main questions:

  1. How can you determine the size of a release early in absence of a “big upfront requirements phase,” and thus when the requirements are only known at a very high level and subject to refinement and change?
  2. How can you determine size in a consistent way across multiple products, projects, and agile teams so that you have good historical data on which to base an estimate?

This and the next article in the QSM Agile Round Table series are based on those discussions. Aaron Jeutter, a participant in the Round Table from Rockwell Automation, presented the technique of “Big Rock Sizing.”  This technique is used at Rockwell Automation for early sizing and estimating based on high level requirements that will be refined using agile techniques as the work progresses.

Read the full article!

Blog Post Categories 
Articles Agile Estimation

Agile Development and Software Estimation: Two Processes That Go Great Together

This post was originally published on Linkedin. Join the QSM Linkedin Group and Company Page to stay up-to-date with more content like this.

New approaches to software development can sometimes seem at odds with the needs of business customers. For instance, ardent practitioners of the agile development methodology continue to advocate for rapid response approaches and the need for constant iteration to solve complex problems. On the other hand, companies and customers are demanding a strategic approach that provides insight into process, timing, and costs.

So, which of these yin and yang scenarios should developers employ? The answer is “both.”

Enter scope-based software estimation, which I maintain can be a powerful tool to ensure that projects remain on course and on budget. It is possible for schedule and budget estimation to be achieved without sacrificing any of the things that make agile development so potent.

Not everyone feels the same. Some would argue that there’s simply no place for estimates in an agile development world; that estimates cannot coexist with agile or “lean” methodologies like Scrum, which encourage teamwork, speed, and communication without constraints.

What do Sports and Agile Software Productivity Have in Common?

I am a big sports fan and since I work for a software metrics company, I started thinking about the similarities in productivity measurement in both industries. From draft picks to game planning decisions, managers in sports measure their team’s productivity to help them make better decisions in the future. Software executives and product owners do the same thing; they measure productivity in order to make better planning decisions regarding upcoming projects.

To measure productivity in baseball, we look at measures like batting average, on-base percentage, slugging percentage, and earned run average. When measuring the productivity of agile software projects, we often look at the velocity, which takes into account the number of user stories completed in each sprint. This type of historical data helps us plan effectively at the detailed level.

As part of our work at QSM, we are often asked to provide plans at the release and portfolio level. To provide these plans reliably, we use a macro level, empirically-based productivity measure that encapsulates a number of project-related factors. This measure is called the Productivity Index, an integral part of the Putnam Model.  Also known as the SLIM Model, the Putnam Model was invented by Larry Putnam Sr. almost 40 years ago and is having a big impact on software measurement more than ever today.

Once we know the total number of user stories (or any size measure), the release level effort, and the duration, we can calculate the Productivity Index of a project. The Productivity Index also takes into account the project environment including: the experience level of the team, the complexity of the software, and the quality of the tools and methods being used on the project.

Blog Post Categories 
Productivity Agile

Historical Data Isn’t Playing “Hard to Get”

Historical Data Collection

“No, we don’t have any historical project data collected” is the statement I hear with some frequency when speaking to organizations about their IT project estimating processes.  Ideally we use client history to calibrate and tune the project estimates we provide.  In my quest to spread the word about parametric estimating I often encounter this notion that organizations don’t believe they have historical data in a retrievable form.  In almost every case that I have been involved, it turned out that the historical data was present, just not in the form of a 1,000 rowed spreadsheet.  Often times the data is more available than the client is aware.

Our approach works at a macro level so we are seeking overall project metrics of cost, schedule, size, staffing and defects.  If the actual formal documentation of history is not available for these five core metrics, then it usually is available by leveraging various sources within the organization.  We have found it’s common to resurrect a project’s outcome by seeking feedback from the team that worked the project, however if that’s not possible due to attrition, re-org or other disrupting factors, we can usually find the project metrics through other means.  Those other means may be time and defect tracking tools, requirements analysis tools and accounting systems.  The data is almost always documented somewhere.   

Blog Post Categories 
Database Data Metrics