Practical Software Measurement

Blogs

The Shape of the Work When Estimating Agile Releases

In a recent webinar on using the SLIM tools and methods in an agile environment, we showed a template for agile projects included with SLIM-Estimate. I was asked, "Since agile teams are a fixed size group that stays together throughout the work on the release, why doesn’t the agile template use the Level Load shape?" My answer was the typical short answer to a complex question, "It’s complicated and it depends." In this blog, let’s take a look at some of those complications and dependencies.

The team, the whole team, or nothing but the team?

When using SLIM-Estimate to estimate the effort required for a release, agile or not, you have to decide, "Whose effort are we interested in?" When describing a team in a scrum project, we usually talk about three major roles: product owner, scrum master, and team member. These people are, in general, full time on the project. If you are only interested in estimating the effort of these full time team members, then you may want to use the “Level Load” shape in SLIM-Estimate. The total effort of these people is based on the number of people multiplied by the duration of the work on the release.

Blog Post Categories 
Agile

SLIM-Collaborate 2.0 - What's in a Name?

We're happy to announce the launch of SLIM-Collaborate™ 2.0, the solution formerly known as SLIM-WebServices. The new name better represents how our customers use this "light and lean" version of our trusted software estimation, tracking, and benchmarking suite. 

As technology has become more integrated into every facet of our work and life, the number of stakeholders in software projects has grown. Collaboration among all of these parties is critical in making sure software is designed, developed, and deployed correctly. Not everyone involved needs the detail and power of our SLIM solution, but they all need visibility into project status. SLIM-Collaborate gives that transparency with an easy-to-use interface and dashboards designed with business users in mind. This transparency and involvement of all users improves estimation accuracy and ultimately achieve software project goals on time and on budget.

This update is not just a facelift; we’ve updated more than just the name. The new version includes a number of new features and enhancements that help the entire project management team estimate, implement and track its projects to avoid failure, such as:

Blog Post Categories 
SLIM-Collaborate

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

Should Task Planning Occur Before Software Estimation?

I work for QSM, a leading software project estimation and demand management company. We focus on top-down estimation, meaning we figure out the total project duration and effort before any detailed planning occurs. We use SLIM-Estimate also known as the Putnam Model. Larry Putnam Sr. introduced SLIM in 1978. It is one of the leading software estimation tools in the world, validated with over 35 years of industry leading research and updated regularly with the latest technologies. 

Many people call us for help with team size software project estimation, they want to see how many people it’s going to take to deliver a specified amount of functionality within a certain duration and budget. At the time they call us they are often using task level planning tools to try to figure this out. 

The problem is that it’s tough to allocate people and the number of hours they will work when they haven’t figured out the specific requirements of each task and when they haven’t estimated the total duration and effort for the overall system. A manager could spend days creating a task level plan that doesn’t add up to the overall project duration and budget that is needed to deliver the functional requirements. When it doesn’t add up then re-planning has to take place costing more time and money. This is why QSM recommends estimating the big picture first, the scope level. 

Blog Post Categories 
Estimation Process Improvement Sizing

ITMPI Webinar - Agile Estimation: Beyond the Myths

Presented by for ITMPI on Sept. 9 at 11:00 AM EST by Dr. Andy Berner.

When it comes to agile, there are common myths and misconceptions about estimation. In this webinar, QSM’s Andy Berner will offer corrections to these, such as:

  • Why we still need to estimate duration on agile projects
  • Why velocity is not constant on a project, or across projects
  • Why setting expectations based on scope is still important, even as we “embrace change”
  • Why burndown charts will not be straight lines
  • Why you still need to plan for work on requirements, even though it’s not all “upfront”

While some longstanding principles about software estimation still apply, agile methods require some significant changes to how we estimate. This webinar will show you how to tailor estimation tools and methods specifically to an agile development environment to estimate, measure, and analyze your agile software development projects. Andy Berner will demonstrate how top-down estimation fits with the principles of agile development, and will discuss what needs to be estimated, how size factors in, and how to accommodate different iteration lengths and types of work. This will allow you to optimize the choices and plans for the work of your agile teams.

Register for this webinar!

Blog Post Categories 
Agile Webinars

How Cyber Secure Is the Software in Your Car?

Cyber Security JeepThis past July marked the first cyber security recall in automotive history.  Fiat Chrysler issued a formal voluntary recall of 1.4 million vehicles after security researchers Charlie Miller and Chris Valasek demonstrated to WIRED how they could exploit a software vulnerability in Chrysler’s Uconnect dashboard computers and remotely hack into a 2014 Jeep Grand Cherokee over the Internet, taking over dashboard functions, transmission, steering and brakes.  Most notably, they did so from their basement while WIRED author Andy Greenberg was driving the vehicle on the highway!

Though this was first time an automotive manufacturer issued a recall for cyber security, it’s not the first time security risks have been found in automotive software.  As I’ve pointed out in my previous article “How Much Software Is in Your Car?” nearly every vehicle less than 30 years old on the road today depends on lots of computer software and thus is potentially vulnerable to hacking, especially newer models that are connected to the Internet.  

Blog Post Categories 
Cyber Security Program Management

New Article - 10 Steps to Better Metrics

10 Steps to Better Metrics

An effective software measurement program is a long-term investment, not a quick fix. In this article originally published in Projects at Work, Carol Dekkers identifies 10 steps to ensure your organization's metrics deliver a positive return on that investment, from more accurate cost and schedule estimation, to streamlined processes and better insights into current and future commitments.

Read the full article!

Blog Post Categories 
Metrics Articles

New Book - Understanding Software Estimation, Negotiation, and Demand Management: An Executive Primer

Understanding Software Estimation, Negotiation, and Enterprise Demand Management: An Executive Primer

QSM is pleased to announce the release of a new book, Understanding Software Estimation, Negotiation, and Demand Management: An Executive Primer. Historically, only 20% of software projects are completed successfully and with software becoming critical to nearly every company and industry, having such a high rate of failure is simply unacceptable anymore. It is for this reason that QSM has compiled this collection of articles that will aid anyone from project managers to CIOs in implementing software estimation, negotiation and demand management methods efficiently to reduce costs.

Larry Putnam, Sr., founder of QSM and a pioneer and top problem solver in the software estimation and measurement field, provides the foreword to the book, which is co-authored by his son and granddaughter, Doug Putnam and Taylor Putnam-Majarian. Combined, the authors bring more than 40 years of experience in software measurement to a range of topics, including:

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