What do you do if you want to improve a process and have 100 candidate predictor variables?  How do you decide where to direct causal analysis effort?  Similarly, what if you want to create an estimating model and you have so many factors you do not know where to start? Data mining techniques can be used to filter many variables down to a vital few to attack first or to build estimating models to predict important outcomes. CrossTalk Magazine, January 2011.

Read the full article here.

Paul Below has over 25 years’ experience in measurement technology, statistical analysis, estimating, forecasting, Lean Six Sigma, and data mining. He serves as a consultant for QSM, providing clients with statistical analysis of operational performance leading to process improvement and predictability.

Mr. Below is a Certified Software Quality Analyst, a past Certified Function Point Specialist, and a Six Sigma Black Belt. He has been a course developer and instructor for Estimating, Lean Six Sigma, Metrics Analysis, Function Point Analysis, as well as statistical analysis in the Masters of Software Engineering program at Seattle University. He has presented papers at numerous conferences. He has one US patent and two patents pending.

Recently I attended a seminar on a commercial reporting and data sharing product. In the sales material and discussion, the phrase “Single Version of the Truth” was used several times. But what does it mean?

“In computerized business management, svot, or Single Version of the Truth, is a technical concept describing the data warehousing ideal of having either a single centralised database, or at least a distributed synchronised database, which stores all of an organisation's data in a consistent and non‐redundant form.” - Wikipedia

The concept is attractive to decision makers who collect and analyze information from multiple departments or teams. Here's why:

“Since the dawn of MIS (Management Information Systems), the most important objective has been to create a single version of the truth. That is, a single set of reports and definitions for all business terms, to make sure every manager has the same understanding.”

Sounds simple, doesn’t it? Sales pitches for svot imply that if distributed data sources were linked into a single master repository, the problem of unambiguous, consistent reporting and analysis would be solved. Yet reports are often based on different data using different definitions, different collection processes, and different reporting criteria.

For many projects, duration is just as important a constraint as cost. In this installment we will tackle the question:  How do changes to team size affect project duration and the resulting productivity?  Once again we will use our database of business applications completed since January, 2000.

Continue reading...

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.

This week we turn to another question triggered by the Performance Benchmark Tables: how does duration affect productivity? To many managers, project schedule and cost are equally important. There are significant tradeoffs involved: if the project takes too long, important market opportunities may be lost. But adding people to compress the schedule can drive up cost dramatically. For this reason, QSM uses a productivity metric that explicitly accounts for duration: the Productivity Index (or PI). Unlike ratio based productivity measures, the PI is a three dimensional measure that adds duration to the traditional size/effort equation. It explicitly accounts for the distinctly non-linear relationships between size, effort, and time.  To see the benefits of this approach, let’s look at how project duration relates to simple (SLOC/effort) productivity.

Continue reading...

In Part I of this series, we demonstrated that average productivity (effective size/effort) increases with project size. This relationship holds true across the size spectrum whether we’re talking about projects in the very small range or projects that deliver a million lines of code. Above this cutoff, the sample size is too small to be definitive.

But productivity isn't the only metric that increases with project size. On average, large projects use more effort, take longer, and use bigger teams.  How can these results be reconciled with previous studies which conclude that the large team strategy results in lower productivity? It would seem that we have a contradiction on our hands.

QSM and IBM Rational are pleased to announce yet another point of integration between SLIM and Rational tools.  Most projects overrun their schedules and budgets because of the lack of good estimates at the time commitments are made.  Project and portfolio management tools like Rational Focal Point are useful to analyze proposals and help build a solid business case on which to base project approvals.  These products focus primarily on justifying the project through the business benefits and/or savings derived from the implementation of the proposal’s business requirements.  They do not assess the risk of failing to meet a business stakeholder’s desired project schedule and budget in a proposal.  QSM’s integration to Rational Focal Point brings this powerful capability to market and helps identify high risk proposals before they enter an organization’s project stream.  This capability can significantly reduce schedule slippage and cost overruns that can reach tens of millions of dollars for many large Fortune 1000 organizations.

Read more about the SLIM-Estimate and Rational Focal Point integration here or you can read more about QSM's IBM Rational Solutions on our Partners Page.

From time to time, questions from clients get us thinking:

After yesterday's Web presentation on the QSM Benchmarking Consortium, I went to your Web site and found the paper "Performance Benchmark Tables." I noticed the delivery rates in both SLOC/PM and FP/PM numbers increase as average project size increases. This seems counterintuitive: are the Performance Benchmark Tables correct?

That's a great question. Our data definitely shows an upward trend in productivity as application size increases. This is true whether we use measures like QSM's PI (productivity index) or ratio based productivity measures (SLOC or FP per person month of effort). The QSM industry benchmark trends behave similarly: as projects get larger, average productivity increases as well.

Paul Below recently took another look at productivity data using several popular statistical software packages. The question he was trying to answer was, “Does productivity (measured as SLOC/PM) always increase with system size, or could the size-productivity relationship actually behave differently in certain regions of the size spectrum?" To answer this question he used something called residuals to evaluate the size/productivity regression trend.

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.

It’s time to update QSM’s industry trends and we need your help! Contributing data ensures that the database reflects a wide spectrum of project types, languages, and development methods. It helps us conduct ground-breaking research and improve our suite of estimation, tracking, and benchmarking tools. Contributors benefit from the ability to sanity-check estimates, ongoing projects, and completed projects against the best industry trends in the business.

 We're validating over 400 new projects, but we can always use more – especially in the Real Time, Microcode, and Process Control application domains. So what do you need to do to ensure your firm is represented in the next trend line update? That’s easy! Simply send us your DataManager (.smp files) or completed SLIM-Control (.scw) workbooks. Here’s the recommended minimum data set:

• Project Name
• Status = “Completed” only – no estimates or in progress projects
• Application type and sub-type (if applicable)
• Phase 3 time. Can be calculated from the phase end/start date or entered as a value (e.g.: 3.2 months)
• Phase 3 effort
• Effective Size (the number of new and or modified functional size units used to measure the application – objects, SLOC, function points, database tables). Please include a gearing factor if the project was sized in something other than Source Lines of Code

Additional information allows us to perform more sophisticated queries: