Have you ever been excited to discover a new use for something familiar, like learning that lighter fluid can be used to remove ink stains from your clothes?  I recently discovered a way to leverage the tie between SLIM-Estimate and SLIM-DataManager that I was previously unaware of.  

My limited view of SLIM-DataManager as a tool for historical data and SLIM-Estimate as a tool for software project estimation limited my creativity in applying the rich set of capabilities in the entire SLIM tools suite.  I recently observed a more experienced SLIM user use both tools to model a history project where very little data was available, using both applications.  Here is a description of the situation.

Scenario: 

You have gathered metrics from a completed project to serve as the basis of estimation for your next project.  Software size, lifecycle effort, lifecycle duration (phases 1-3), and defects are known, but you do not have a break out of individual phase data.  How can you best model this project and capture the results in SLIM-DataManager?

Solution A: 

QSM is pleased to announce the SLIM-Estimate^® Certification Program.  Specifically designed to help our customers ensure the technical excellence of their SLIM users, this program increases the business value of our software project estimation tools to your organization. 

How Certification Is Achieved:

In order to be awarded certification, a user must demonstrate competence in the following areas:

If you missed our webinar, Best in Class SLIM Estimation Processes for Package Implementations, a replay is now available.

To be able to estimate package implementations, we need to be able to size them and support productivity assumptions with relevant data. Presented by Keith Ciocco, this webinar demonstrates package implementation sizing processes and how to calibrate SLIM to package implementation project trends.

As Vice President of QSM, Keith has more than 23 years of experience working in sales and customer service, with 15 of those years spent at QSM. Keith’s primary responsibilities include managing business development, existing client relations, customer retention and response.

View the replay.

On Thursday, June 16 at 1:00 PM EDT, QSM will host a webinar focused on estimating package implementations.

To be able to estimate package implementations, we need to be able to size them and support productivity assumptions with relevant data. Presented by Keith Ciocco, this webinar demonstrates package implementation sizing processes and how to calibrate SLIM software estimation tools to package implementation project trends.

As Vice President of QSM, Keith has more than 23 years of experience working in sales and customer service, with 15 of those years spent at QSM. Keith’s primary responsibilities include managing business development, existing client relations, customer retention and response.

Watch the replay!

Two common questions we receive are “how quickly can we get SLIM deployed within our organization?” and “how accurate will our estimates be?” On the accuracy question, our answer is usually that “it depends”. Like most things, accuracy and success in estimating are directly correlated to the effort put into the task. If you buy a commercial estimating tool and try to use it “out of the box” with no tailoring and calibration, accuracy usually suffers. One of the most efficient ways to achieve both of these goals is to use your own historical data. This was an excellent example of how one of our global systems integration clients was able to get almost immediate value by calibrating SLIM-Estimate to their historical data.

This major integrator wanted to improve estimation at one of their accounts, a large multinational company.  In addition they wanted to use function points as their sizing metric. After evaluating a number of estimation options, including custom built and other internally developed solutions, they decided to use QSM’s SLIM-Estimate, which was being deployed globally across the rest of the organization. They decided to start with a pilot implementation. The estimation pilot lasted a total of 5 months with a staff of 2 people. After the fact they looked at the effort expended on their pilot activities and found that 60% of the total effort went into their calibration activities. The calibration  process included assembling a historical data sample of over 50 projects. As part of their function point deployment, they empirically determined FP/ESLOC gearing factors.

In recent years, we have seen our client base become increasingly diverse, expressing the need for our estimation, tracking, and benchmarking tools for design processes outside of just software. While clients have customized SLIM to other design disciplines in the past, our goal with SLIM 8.0 was to increase configurability within our tools so our users can model any type of system quickly and easily. Now users can forecast and benchmark Agile, infrastructure, offshore/multi-shore, ERP/package implementation projects, and more.  In addition to updated trendlines from 10,000 completed software and systems projects, SLIM comes pre-packaged with trend groups, such as Agile, ERP, Financial, Web, and Government.

Read the full press release with detailed product upgrades here.

It’s hard to believe it’s been 36 years since an IBM manager named Fred Brooks came out with his seminal insights about software development, the most famous of which ("adding more people to a late software project makes it later") came to be known as Brooks’ Law. These days, most software professionals accept and appreciate Brooks’ analysis, yet we continue to make the very mistakes that prompted him to write The Mythical Man Month!

Which leads to an interesting question: armed with such a clear and compelling argument against piling on staff at the last minute, why do we repeatedly employ a strategy that not only fails to achieve the hoped-for schedule reductions but often results in buggy, unreliable software?

The most likely answer combines schedule pressure with the human tendency to over-optimism. Basing plans on hope rather than experience is encouraged by a constant parade of new tools and methods. Faced with the pressure to win business, please customers and maintain market share, is it really surprising that new  technologies tempt us to discount the past and hope that – if we use this tool, this team, this methodology - this project will be different?

How can software developers counter the human tendency to fall for overly optimistic estimates and unachievable schedules?

What's needed is perspective: the kind of perspective that comes from honestly examining - and reminding ourselves - how things have worked in the past. In a paper called, “Technology Can Only Do So Much”, I look at the human and technological factors that trip up so many software projects.  Good historical data provides a sound empirical baseline, against which both conventional wisdom and future plans can be assessed.

On Thursday, September 30th at 1 pm EDT, QSM will host a Webinar on Agile Estimation Methods.

You can view the replay of this webinar here.

Regardless of which size measures (Effective SLOC, function points, objects, modules, etc.) your organization uses to measure software size, code counters provide a fast and easy way to measure developed functionality. If your organization uses Effective (new and modified) SLOC, the output from an automated code counter can generally be used "as is". If you use more abstract size measures (function points or requirements, for example), code counts can be used to calculated gearing factors such as average SLOC/FP or SLOC/requirement.

The QSM Code Counters page has been updated and extended to include both updated version information and additional code counters. Though QSM neither endorses nor recommends the use of any particular code counting tool, we hope the code counter page will be a useful resource that supports both size estimation and the collection of historical data.