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

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.

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):

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)

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. 

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.

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.