Practical Software Measurement
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.
“I'm sorry, Dave. I'm afraid I can't do that” – HAL 9000
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.
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.
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:
This 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!
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.
New Book - Understanding Software Estimation, Negotiation, and Demand Management: An Executive Primer
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.
A foundation of the SLIM philosophy is to know what your team is capable of producing and never promise to deliver more than those finite limits. Leveraging a history of completed project core metrics enables you to quantify your capabilities, and not only provide a defensible basis of estimation, but support statistical analysis for project benchmarking and identifying performance improvement opportunities.
Software projects can be so complicated and so different from each other that predicting whether they will succeed or fail can be as difficult as forecasting the weather or picking winning stocks. Will the project entirely fulfill its goals? Will it deliver some value at a higher cost or later than desired? Or will it just crash and burn leaving the exhausted survivors to lick their wounds, bury the dead bodies, and shred the evidence?