Kate Armel's blog

Kate Armel's blog

Making the Case for Software Estimation

The challenges surrounding software estimation are both well known and well documented.  Most discussions on this topic center around the technical challenges estimators face: tight schedules, unclear scope, evolving requirements, and accounting for dependencies and risk.  But there's a more fundamental challenge we don't hear so much about – educating stakeholders and making the business case for structured, yet practical estimation, and why it is a critical success factor. 

Let's face it: process improvement is rarely cost-free.  Businesses expect a visible return on investments made in estimation tools and training.  The benefits of quality software estimation can be compelling, but moving decision makers from "open to the idea of estimation" to "willing to commit money and resources" can be difficult for busy analysts and managers juggling multiple roles and tasks.

In her latest video, QSM's Laura Zuber explains what makes a good software estimate and how empirically-based estimation helps projects:

Blog Post Categories 
Estimation Training

Top Programming Languages Revisited

Mike Harris at the Davis Consulting Group blog links to a 2014 list of 11 Essential Programming Languages from Baseline Magazine:

If you want to learn about the hottest programming languages today, don't miss this list from IEEE Spectrum. This respected organization, which has 400,000 members and is considered the world's largest association of technology professionals, enlisted the services of Nick Diakopoulos, a well-known computational journalist and assistant professor at the University of Maryland, to compile the language rankings. Diakopoulos proceeded by weighing and combining 12 metrics from 10 sources, including IEEE Xplore, Google and GitHub. The result is a compilation of languages that cover big data analytics, graphics, system administration, network programming and virtually every other tech-supported function.

IEEE’s interactive list, which you can explore here, generates customized rankings for various sectors (Web, embedded, enterprise). In evaluating the results, it makes sense to ask, “What makes a programming language, ‘essential’?” Language popularity can be measured several ways:

Blog Post Categories 
Languages QSM Database

Extending SLIM Tools with Extension Menu Items

Extension menu items are one of the best new features in SLIM-Suite 8.2.  You don’t have to be a programmer (or even pretend to be one online) to create customizable menu items that perform tasks like these right from the menu of any SLIM-Suite application:

  • Call external applications like Excel, Word, or PowerPoint
  • Run SLIM-Suite utilities or APIs
  • Open external references or process guides
  • Launch the Windows Snipping Tool to capture screen settings or data and email them to your team.

Once you get the hang of it, creating your own custom menu items is easy: if you can unzip files and use Notepad, trust me – you can do this!

The Extension Menu Item feature is documented in its own chapter in each SLIM-Suite user guide, but if you’re like me you could probably use a few real life examples and some sample configuration settings to jump start the process.  In a fairly short period of time, I was easily able to create the following menu items in SLIM-DataManager:

  • IMPORT PROJECT FROM SPREADSHEET
  • EXPORT DATABASE TO SPREADSHEET
  • RUN DATAMANAGER API
  • Bring up the API documentation
  • Bring up an internal data validation guide
  • Launch Excel, Word, PowerPoint and OneNote
  • Launch the Windows Snipping tool.

The menu items I created fell into several categories: launching an external application, launching a SLIM-Suite utility/API, pointing to an external process guide, launching a Windows utility. I’ll cover each one, providing sample configuration text for each.

CREATING THE .INI FILE

Blog Post Categories 
SLIM Suite Tips & Tricks

Software Cost Estimation Article in The DACS Journal

The February issue of the DACS Journal of Software Technology focuses on Software Cost Estimation and Systems Acquisition. My contribution, which you can read here, addresses the challenges faced by estimators and the value of establishing a historical baseline to support smarter planning, counter unrealistic expectations, and maximize productivity.

Using several recent studies, my paper addresses the following questions:

  • What is estimation accuracy, and how important is it really?
  • What is the connection between the Financial Crisis of 2008 and software estimation?
  • Why do small team projects outperform large team projects?
  • How can you find the optimal team size for your project?

Read the full article.

Blog Post Categories 
Estimation Articles

Part III: Finding the Optimal Team Size for Your Project

In part one of our team size series, we looked at Best and Worst in Class software projects and found that using small teams is a best practice for top performing projects. Part two looked at differences in cost and quality between small and large team projects and found that small teams use dramatically less effort and create fewer defects.  But simply knowing that small teams perform better doesn’t tell us how small a team to use. Most software metrics scale with project size, and team size is no exception. Management priorities must also be taken into account. Small projects can realize some schedule compression by using slightly larger teams but for larger projects, using too many people drives up cost but does little to reduce time to market:

Larger teams create more defects, which in turn beget additional rework… These unplanned find/fix/retest cycles take additional time, drive up cost, and cancel out any schedule compression achieved by larger teams earlier in the lifecycle.

In a study conducted in the spring of 2011, QSM Consultant Don Beckett designed a study that takes both system size and management priorities into account. He divided 1920 IT projects into four size quartiles. Using median effort productivity (SLOC/PM) and schedule productivity (SLOC/Month) values for each size bin, he then isolated top performing projects for schedule, effort, and balanced performance (better than average for effort and schedule):

Effort vs. Schedule

Blog Post Categories 
Team Size

Part II: Small Teams Deliver Lower Cost, Higher Quality

This is the second post in a three part investigation of how team size affects project performance, cost, quality, and productivity. Part one looked at cost and schedule performance for Best in Class and Worst in Class IT projects. For this study, Best in Class projects were those that delivered more than one standard deviation faster, but used more than one standard deviation less effort than the industry average for projects of the same size. A key characteristic of these top performing projects was the use of small teams: median team size for best in class projects was 4 FTEs (full time equivalent) people versus 17 FTEs for the worst performers.

What is the relationship between team size and management metrics like cost and defects? To find out, I recently looked at 1060 medium and high confidence IT projects completed between 2005 and 2011. These projects were drawn from the QSM database of over 10,000 completed software projects. The projects were divided into two staffing bins:

  • Small team projects (4 or fewer FTE staff)
  • Large team projects (5 or more FTE staff)

Average Staff vs. System Size

These size bins bracket the median team size of 4.6 for the overall sample, producing roughly equal groups of projects that cover the same size range. Our best/worst in class study found a 4 to 1 team size ratio between the best and worst performers. 

Blog Post Categories 
Team Size

Top Performing Projects Use Small Teams

Last week, Carl Erickson of Atomic Spin referenced a study performed by Doug Putnam several years ago:

A study done by consultancy QSM in 2005 seems to indicate that smaller teams are more efficient than larger teams. Not just a little more efficient, but dramatically more efficient. QSM maintains a database of 4000+ projects. For this study they looked at 564 information systems projects done since 2002. (The author of the study claims their data for real-time embedded systems projects showed similar results.) They divided the data into “small” teams (less than 5 people) and “large” teams (greater than 20 people).

To complete projects of 100,000 equivalent source lines of code (a measure of the size of the project) they found the large teams took 8.92 months, and the small teams took 9.12 months. In other words, the large teams just barely (by a week or so) beat the small teams in finishing the project!

Since then, QSM has performed several studies investigating the relationship between team size and metrics like project scope, productivity, effort/cost, and reliability. The results have been surprisingly consistent regardless of application domain, technology, or year group.  I’ll be reviewing what we found in a series of posts.

Blog Post Categories 
Team Size

SLIM Suite Quick Reference Guide

Have you ever found yourself wondering which SLIM tool to use for a task, or what interfacing features are available for various SLIM Suite applications? We've created a handy Quick Reference Guide that offers a concise, "at a glance" summary of the great features built into SLIM Suite! This one page table is chock full of useful information about import/export capabilities, major tool features, and interfaces to other SLIM tools or applications like Microsoft Project and IBM Rational Focal Point and Rational Team Concert.

Here's what you'll find:

  • Tool descriptions and features
  • Workbook extensions for each application
  • API (Application Programmer's Interface) and third party integration availability by application
  • Which settings and data can be imported into each tool
  • Export options for charts, reports, and project data

Whether you've licensed one or two applications or the entire tool suite, we hope our Quick Reference Guide will be a helpful resource. 

You can find more resources in the QSM Support section of our website.

Blog Post Categories 
Tips & Tricks Quick Reference

New Faces in QSM Support

The next time you call or email QSM for support, you may notice a few unfamiliar names or voices. That's because QSM Research and Support is growing!

The first addition to our team is Katie Costantini. Katie joined QSM as a temporary summer intern in May of this year. We were so delighted by the quality of her work that we recently offered her a full time position at QSM as a Technical Support and Documentation specialist.

Katie Costantini joins QSM Research and Technical Support with three years of customer service experience under her belt. Over the summer, she has been working hard to upgrade our product documentation to a newer platform and format. You'll see some of her work in the next edition of SLIM-Suite manuals and help. She also assisted with the redesign of our new FAQs page and has been helping us revamp our ramp up documentation and processes. Katie graduated from Virginia Commonwealth University cum laude with a B.S. in Economics and a minor in Latin and Roman Studies. Raised in a Marine Corps family (ooh rah!), Katie has lived in California, North Carolina, Virginia, and Cairo, Egypt.

Over the next year, Kate will be working on support documentation and the next update of the QSM database and industry trend lines. Her strong quantitative background and stellar organizational skills are already helping us bring about some exciting changes that we'll be unveiling soon!

The second (chronologically speaking) addition to QSM Research & Support is Laura Zuber:

Blog Post Categories 
QSM News Support

An In-Depth Look at the QSM Database

The QSM Database is the cornerstone of our tools and services, so our clients and prospects often ask for more information regarding the data and types of projects represented. This blog post addresses some frequently asked questions about the QSM Database.

Sources of Data

Since 1978, QSM has collected completed project data from licensed SLIM-Suite® users and trained QSM consulting staff. Consulting data is also collected by permission during productivity assessment, benchmark, software estimation, project audit, and cost-to-complete engagements. Many projects in our database are subject to non-disclosure agreements but regardless of whether formal agreements are in place, it is our policy to guard the confidentiality and identity of clients who contribute project data. For this reason, QSM releases industry data in summary form to preclude identification of individual projects/companies or disclosure of sensitive business information.

Data Metrics

Our basic metric set focuses on size, time, effort, and defects (SEI Core Metrics) for the Feasibility, Requirements/Design, Code/Test, and Maintenance phases. These core measurements are supplemented by nearly 300 other quantitative and qualitative metrics. Approximately 98% of our projects have time and effort data for the Code and Test phase and 70% have time/effort data for both the R&D and C&T phases.

Productivity is captured via the following metrics:

QSM Productivity Index (PI)
Cost per SLOC or Function Point
SLOC or Function Points per month
SLOC or Function Points per Effort Unit (Months, Hours, Days, Weeks, Years)

Quality data is captured via the following metrics:

Blog Post Categories 
Metrics QSM Database