Frequently Asked Questions

Though we have thousands of Function Point projects (over 4,000 at last count!)  in our database, several factors limit the number of projects judged suitable for inclusion in our Function Point Gearing Factors table.

Here's a partial list of the most important inclusion criteria:

• Recently completed
• Rated Medium to High Confidence
• Similar application complexity. While FP are sometimes used to size real time and engineering class projects, our table uses only IT project to ensure apples to apples comparisons. 
• Written in a single language. Why is this a problem? These days, the vast majority of projects submitted our database use more than one language. We wouldn't want to represent a project with only 20% Java as "a Java project" because any gearing factor derived from such a project would not be accurate for estimating projects developed solely or predominantly in Java.
• Not drawn from our own table!
• No extreme values or outliers.

It would be wonderful to be able to classify projects by language version as well as language but even if we had all the information we needed, the resulting samples would probably be too small to be relied upon. 

There are many possible explanations for observed variability in gearing factors (imprecision in counting being not the least of them). But perhaps the more important point is that our table is based on real data, and even where we do have language version information, we haven’t seen sufficient evidence to conclude that language gearing factors change radically from release to release. The differences we've observed seem to be within the range of normal variation.

Without strong empirical evidence, we're reluctant to draw conclusions about the influence of new releases of IDEs (integrated development environments) or language versions on function point gearing factors. 

Today I tried to open a SLIM-Suite file on the network and got an error message that said the file stamp was wrong and the workbook could not be opened. What's going on?

That message appears whenever you try to open a workbook created in a later version of SLIM-Suite with an earlier version of the applications. For example, you tried to open a workbook created in 8.0d with an earlier version of SLIM-Suite like 7.0 or 8.0 a, b or c.

SLIM-Suite workbooks are forward compatible: in other words, you can open and upgrade files created with earlier versions of SLIM-Suite. But they are not backward compatible (older versions of SLIM-Suite cannot open or read files created with a newer version of the applications). 

To open your workbook, you should either upgrade your machine to the latest version of SLIM-Suite or open the file on a machine with the latest version installed. To download the latest version of SLIM-Suite, visit our upgrades page. You’ll need your license email or the readme.txt file in your Tools80 directory to access the license registration and activation codes. The Upgrades page contains instructions for the upgrade as well as an Installation FAQs page that addresses common questions associated with installing or upgrading SLIM-Suite products.

You can also check for updates right from the Help menu. If you still have questions or need help, just contact QSM support for assistance!

Here's how to locate your SLIM license information:

• If the applications are already installed:
  • Simply launch any SLIM application and look at the right side of the splash screen, or
  • With the application open, select Help | About SLIM... from the menu to access the splash screen.

• If your license has expired or the application has not been installed yet, try the following:
  •  If the application is installed on your computer, simply browse to the directory where it is installed (Usually C:\Program Files\QSM\Toolsnn, where “nn” is the current version of SLIM-Suite). To determine the path to the application directory, right-click on the application shortcut and select the "properties" tab. Locate the readme.txt file located in your Toolsnn folder. Open this file in Notepad or any other text editor - it contains your license information.
  • If the applications have not yet been installed, contact the software administrator for your company and ask for a copy of your license email.
  • If you need help locating your software administrator or license email (or if you have questions) call QSM at 800 424-6755 for assistance.

Where can I get the exercise files used in SLIM Suite Training? I would like to rework the training problems to refresh my memory before I begin using SLIM tools.

The SLIM Suite Training Pack is installed with SLIM-Suite. It contains the SLIM-Suite workbooks used in our training classes. To access the training workbooks, browse to the QSM directory (c:/Program Files/QSM/ by default) and look for the “Toolsnn” folder where “nn” represents the current version of SLIM suite. If you installed the Training files during setup, you should see Training folder that contains the training exercises.

To install and run the SLIM Tool Suite, you will need:

• Microsoft Windows XP, Vista, Windows 7, or later. 

• 200-800 MB hard disk space, depending upon which applications are installed. As SLIM Suite applications require additional disk space to store and work with your files, we recommend keeping at least 100 MB free space on your hard disk at all times

• A machine that meets Microsoft's recommended requirements for your operating system. Windows 7 users who plan to run SLIM-Suite in XP compatibility mode should have an addition 1 GB RAM and 15 GB of hard disk space.  Having more memory than the minimum required will result in better performance.

• A monitor capable of displaying at least 1024 x 768 with 256 colors and 96 dpi fonts (default small fonts).

What are the latest versions of the SLIM Tool Suite?

Information on the latest version of SLIM-Suite (along with download links, release notes, and installation FAQs) can be found on the Downloads page of the QSM website. To see whether you're running the latest version, select Help | Check for updates from the menu of any SLIM-Suite application.

In SLIM-Suite, some dialog boxes are too large for my screen.  What is the recommended screen resolution?

If you are running at a low screen resolution, certain dialog boxes may not fit within the screen display. 

The recommended screen resolution is 1024 x 768 with 256 colors and 96 dpi (default small fonts). For optimal graphics display when running SLIM tools, the screen resolution should be set to at least 800 by 600 for small fonts (or at a higher resolution if you are using large fonts). 

Today I tried to open a SLIM-Suite file on the network and got an error message that said the file stamp was wrong and the workbook could not be opened. What's going on?

That message appears whenever you try to open a workbook created in a later version of SLIM-Suite with an earlier version of the applications. For example, you tried to open a workbook created in 8.0d with an earlier version of SLIM-Suite like 7.0 or 8.0 a, b or c.

SLIM-Suite workbooks are forward compatible: in other words, you can open and upgrade files created with earlier versions of SLIM-Suite. But they are not backward compatible (older versions of SLIM-Suite cannot open or read files created with a newer version of the applications). 

To open your workbook, you should either upgrade your machine to the latest version of SLIM-Suite or open the file on a machine with the latest version installed. To download the latest version of SLIM-Suite, visit our upgrades page. You’ll need your license email or the readme.txt file in your Tools80 directory to access the license registration and activation codes. The Upgrades page contains instructions for the upgrade as well as an Installation FAQs page that addresses common questions associated with installing or upgrading SLIM-Suite products.

You can also check for updates right from the Help menu. If you still have questions or need help, just contact QSM support for assistance!

I created custom trends in SLIM Metrics, but I can't get them to work in SLIM-Estimate. What am I doing wrong?

Chances are your workbook has missing reference data or is pointing to the wrong set of trends. 

• If you're using Version 8.0a or later: 
  
  
  • Make sure you have created reference data for PI vs. Effective Size. Reference data for this metric pair must be present in order to perform the PI calculation. If it is missing, the “Calculate a PI from currently selected trend lines” option will be grayed out.
  • Make sure the default reference group in your SLIM-Estimate file matches the reference group you created in SLIM-Metrics. If it points to another reference group or to "None", your custom data will not be used. To select your custom reference data, select Tools | Customize Project Environment from the menu and select your trend from the Primary Trend Group combo box.
    
    
    
    When you click OK, two things will occur. First, that reference group will be the default shown on all new charts and reports created in your workbook. Any charts or reports which are already present will not be affected unless the trend line shown is set to Automatic, but you can easily change this by right-clicking on any chart and adjusting the chart properties.
    
    Secondly, the default PI dialogs will now offer you a choice between the default QSM PI and the reference group or trend mix you chose on the Project Environment dialog. 
    
    
    
    You can use this new set of trends for the default PI on the PI Calculator (via the Solution Assumptions dialog), Quick Estimate Wizard, and Level of Effort Wizard when generating new estimates.
    
    
• If you're using Version 7.0 or earlier: 
  
  
  • Select Edit | Workbook Options | Reference Data from the menu. Make sure the Manual radio button is selected and your custom reference trends appear in the Manual combo box. 
  • Check your custom reference trends in SLIM-Metrics. They should include the following reference trends:
    • Average Staff vs. Effective Size
    • Phase 3 Effort (MM) vs. Effective Size
    • Phase 3 Duration (months) vs. Effective Size

The planned MTTD value shown on my graph for the final month of phase 3 is not the same as the value reported in the Project Profile report and the consistency report for my Phase 3 MTTD. It appears to be slightly higher in the reports.  Why?

The value displayed on graphs is the average MTTD rate for the final month of phase 3, but the MTTD value reported in the reports represents the planned MTTD at the end of phase 3. You should expect this value to be somewhat higher than the average value for the entire month, because the theoretical MTTD is always improving (getting larger) as time progresses.

The skill category percentages are set by the user in the Work Breakdown Structure (WBS) area of SLIM-Estimate.  If you don’t have a WBS or WBS template, you can use the QSM default settings.

To customize the skill category percentages, select Tools | Customize WBS then select Setup Skill Categories.  On the WBS tab, click the radio button for Edit Skill Category Percentages by Task to input your own values for skill percentages.

On the Sensitivity to Size graph, I thought the MTTD (Mean Time To Defect) would decrease (become worse) as the system size increases because the total errors should be increasing.

On Sensitivity graphs, peak staff is held constant as system size increases***, resulting in a more moderate manpower buildup.  Error production is linearly related to size but exponentially related to effort, so holding effort constant while increasing size results in an easier project, relative to the size increase.  

*** Unless the MBI approaches -3 or 10.  If the MBI goes outside of the allowable -3 to 10 range, the peak staff will be reset to a reasonable value.

I increased the PI on one of my estimates from 14.6 to 20.3. When I ran the optimized solution, I got an error message that said the new solution was out of bounds. What went wrong?

If you increase the PI while keeping the MBI (Manpower Buildup Index) the same, you are telling SLIM to keep applying manpower at the same rate in spite of the dramatically higher productivity of 20.3. But if a project operating at a much higher level of productivity does not need as many people as a project team with very low productivity.

At a PI of 20.3,  the calculated peak staff level falls to only .5 (half a Full-Time Equivalent person). This value is below the reasonable effort range, so SLIM generates the following error:

"Your calculated solution is below SLIM's minimum peak staff of .5 people. Your solution will be reset to the last valid solution".

After increasing the PI, you should allow SLIM to calculate a manpower buildup rate that matches the increase in productivity. At the bottom of the Solution Assumptions screen, you can choose between the current MBI and a QSM default MBI.

Selecting the Unconstrained (QSM Default Solution) solution method will provide a more reasonable bui effort buildup consistent with your new PI. 

How do I set Phase Start dates?

To set Phase Start dates, simply click Estimate | Solution Assumptions, then select the Phase Tuning tab.  Please note that you cannot select the start date for Phase 1, nor can you set the start date for the first phase included in the project. The first included phase will always begin on the start date specified in the Solution Assumptions or Wizards.

Subsequent phases can be set to begin at:

• a specific percentage of the prior phase’s duration
• a specified number of months into the prior phase
• a specific date.

What is the difference between the Basic Work Unit and the Function Unit?

The Function Unit is the overall size measure for the project.  It makes sense to describe a book as a collection of chapters or a building by the number of floors or rooms it contains. The Function Unit allows estimators to describe a system as a group of functional or logical components (function points, modules, objects, or screens).

The Function unit is defined by three components:

1. A name  (SLOC, Function Points, CSCI, etc.)  

2. A number or count (257 function points, 83 modules). 

3. A gearing factor, which is a normalization or scaling factor that relates projects with different Function Units back to a common unit of measure: the Basic Unit of Work.  The Basic Unit of Work is conceptually similar to the least common denominator (LCD) in mathematics.

Why use a gearing factor at all?  The QSM database contains thousands of projects sized in different Function Units.  Without a common reference point – a basic work unit – it would be impossible to make meaningful size comparisons between a project sized in Function Points and one sized in Objects or Requirements.

To go back to our building analogy, people often use floors or rooms to convey a rough idea of the size of various buildings. But a floor of a single-family home is not necessarily the same size as a floor of a large office building.  And we can't easily compare a building sized in rooms to one sized in floors without some way to know how big a room is, relative to a floor. To make the comparison meaningful we need to identify a smaller, common size unit (the number of cubic feet per floor or per room, perhaps).  Using this basic size measure, we can "normalize" the size of a floor or a room to cubic feet. We can compare the size of a 4 story office building to a 2 story house. We can also compare a 2 story house to a 10 room apartment because in both cases, we can convert stories or rooms to cubic feet. 

For software projects, the Basic Work Unit performs the same function as cubic feet did when we were describing buildings. The number of cubic feet in a floor or room is analogous to the gearing factor, and cubic feet to the Basic Work Unit.  In previous versions of SLIM tools, the basic work unit was always SLOC. If you are developing the system using a statement-oriented programming language, your basic work unit will usually be SLOC.

If you are developing in a non-statement oriented language or environment, the Basic Work Unit field in Global Options allows you to choose a basic work unit that reflects the work being performed.  You should select a basic work unit that is roughly equivalent in time/effort to writing a line of code. The gearing factor for the basic work unit will always be 1 - it cannot be set by the user.

To set up the sizing units for an estimate, you should do three things:

1. Choose a Basic Work Unit in Global Options.  Normally there is no reason to change the default unless you prefer another name.

2. Choose a Function Unit on the project environment screen.  By default, the Basic Work Unit is always the first item in the Function Unit list box. To size your project in the same unit as your Basic Work Unit (for example, if you are sizing the entire system in a basic unit such as SLOC or Object Properties), simply leave this field unchanged.  Otherwise, select the desired function unit from the list box or add a new entry.

3. Enter a gearing factor appropriate for the Basic Work Unit and Function Unit you have selected (i.e. the Basic Work Units/Function Unit) Some examples are:  # of SLOC per Function Point or # of Object Properties per Object. 

In SLIM-DataManager, you can set the Basic Work Unit on the Database Defaults screen.

If you need help determining an appropriate gearing factor, visit the Function Point Gearing Factors page on the QSM web site, download our gearing factors whitepaper, or contact QSM for assistance.

How can I change the Basic Unit of Work in the Quick Estimate Wizard? Currently it is set to SLOC, but we use Function Points.  I have changed the Basic Work Unit in the Global Options, but when I go into the Quick Estimate Wizard, the size estimate is still in SLOC.

What you need to change is not the Basic Work Unit, but the Function Unit.  To change the Function Unit to Function Points, select Tools | Customize Project Environment from the menu. On the Project Description Tab, there is a Function Unit list box.  Select Function Points, then enter an appropriate gearing factor to represent the average number of Basic Work Units contained in your selected  size unit (ex.: a gearing factor of 250 might represent 250 Basic Work Units per Object).  

If you need help determining an appropriate gearing factor, visit the Function Point Gearing Factors pageon the QSM web site, download our gearing factors whitepaper, or contact QSM for assistance.

I changed my runtime environment from 5 days to 7 days. I would have expected my MTTD value to get smaller because I am running the system longer. Why did my MTTD value get larger?

The MTTD value is simply the reciprocal of the monthly defect rate. Suppose the expected defect rate is 100 defects found during the last month of phase 3. This is a theoretical monthly rate number based on an average runtime environment. The MTTD for this month is therefore 1 month/100 errors or .01 months between defects. 

Because it is difficult to think in terms of .01 months, you can specify a more intuitive MTTD time unit.  If you select days, then .01 months is the same as .01 * 30 (roughly) or .3 days between defects (assuming you are running 7 days a week). However, if you are running only 5 days a week, then .01 months converts to (.01 * 20) or .2 days.

The Solution Panel says my peak staff value is 10.3, but the Average Staffing Rate charts and reports show a peak staff of 10.1. What is causing this inconsistency?

The theoretical Rayleigh curve used to derive the values on the Solution Panel is a smooth curve resulting in different staffing numbers at each point along the x-axis. In drawing the Average Staffing chart, this smooth theoretical curve is approximated by a series of discrete staffing rates (with one bar, or average staffing rate value, per month).

The graph and solution panel values won't always match exactly because the graphical peak staff is always taken mid-month for any internal month while the solution panel always shows the highest peak staff point on the staffing curve (regardless of when it occurs). Usually the theoretical curve does not peak exactly at mid-month, so the true peak shown on the solution panel will not match the one on the average staffing charts unless the theoretical peak happens to fall at mid-month.

On large projects where a longer schedule allows a natural smoothing of the staffing curve, the theoretical peak staff will usually be close to the average staff rate value. On shorter projects, you can expect to see larger discrepancies.

I have an estimate with one very short phase. When I view the Staffing Profile in aggregate mode, the staffing for the final month of that phase does not appear to dip down as it does when I view the individual phases. Why not?

The aggregate staffing chart shows the maximum FTE (full-time equivalent) staff rate during any given month.  For months where two phases overlap, the staffing values for both phases are combined to get the total staffing for that month.  

Sometimes the effort data points on my Life Cycle Sensitivity to PI graph have values that do not always increase (or decrease); e.g., there are small dips in the data.

Remember that the time and effort shown on these graphs are life cycle values. The most likely cause of slight variations in the expected behavior of the data is caused by variation in the effort for phase 4. Staffing projections for phase 4 are dependent on the staffing rate at the end of phase 3. Therefore, differences in the final phase 3 staffing rate can result in variations in the total effort for phase 4. You can check to see if this is the case by making the solutions in question the current solution, then comparing the phase 4 effort in the solution panel of the staffing view.

Sometimes the time data points on my Sensitivity graph are not in a straight line; sometimes 2 or 3 points may even have the same value.

Time values on sensitivity charts are rounded to the nearest day. For very small size increments, this rounding may result in 2 or 3 data points having the same value.

I set a Schedule constraint of 24 months. Why does the solution on the Staffing screen show a 22-month schedule?

There are several reasons this could be happening, but the most likely cause is that you entered a target probability of more than 50% for the Schedule constraint. For example, if you enter a time constraint of 24 months at a target probability of 90%, you are asking SLIM-Estimate to calculate a risk-buffered solution that provides a 90% probability that the project will not exceed 24 months: in effect, a risk-buffered solution.

The difference between the expected solution of 22 months and your constraint of 24 months represents the built-in risk buffer that protects you against possible size growth, lower than estimated productivity, staff availability issues, or other facts that may affect the delivery date. The size of this risk buffer is determined by the uncertainty range around the estimated size, PI, and manpower buildup.

If you want your solution to correspond exactly to your input constraint values, you should use desired probabilities of 50% for those constraints.

The 50% solution is based on the expected value (the solution with a 50% probability of achieving the same or better values for schedule, effort, cost, and reliability). Each of the inputs to an estimate - size, application complexity, and productivity - has some uncertainty associated with it. If any one of your input parameters (size, for instance) increases significantly from the original estimate, it makes sense that the actual outcome will vary from the estimated outcome.

To manage this uncertainty, SLIM-Estimate employs the concept of a risk-buffered solution. The estimate or “work plan” is a 50% probability solution. If the project is managed to this 50% solution, the risk charts should reflect alternative delivery dates at various levels of assurance. You can decide which date to promise to the customer based on your risk tolerance and your assessment of the amount of uncertainty in your inputs.

Essentially, the time difference between the 50% delivery date and the 90% (or whatever assurance level you choose) delivery date represents the amount of schedule buffer needed to account for the possibility that one or more of your input parameters will vary significantly from the estimate.

The alternate outcomes on each risk chart are based on the assumption that the 50% solution represents the work plan for the project. If the project is worked to another plan (the 70% assurance solution, for instance), the values on the risk charts will change.

When I change the Person Hours per Person Month field on the Accounting tab of the Solution Assumptions dialog, there is no change to the total schedule and effort for the project. Why is this?

Many SLIM-Estimate and SLIM-Control users have asked why their overall schedule does not change when they change the value of the "Person Hours per Person Month" field,  Solution Assumptions screen, Accounting Tab.

The number of Person Hours comprising a particular organization's Person Month is not used to calculate total effort.  If your chosen effort unit is Person Months, the hours per month setting is not used at all. If, on the other hand, your effort unit is weeks, days, or hours, your hours per month will be used to convert the estimated total effort (in Person Months) into your chosen effort unit.

At first, this may seem counter-intuitive. Shouldn't an increase or decrease in the number of Person Hours in a Person Month be reflected in the final estimate?

The number of staff hours in an organization's staffing month is more relevant in the accounting world than it is in software estimation. It attempts to account for items such as vacations, meetings, and administrative activities but in most cases, it is merely an estimate or average.  It may tell how many hours will be charged to a particular project, but has nothing to say about how much is actually accomplished during those hours (or even how many actual hours were worked). The productivity index, or PI, is where actual work produced is measured.

The Productivity Index, or PI, reflects a number of environmental factors such as:

If you are using a PI calculated from your past projects, your user-specified PI already reflects the conditions in your working environment. Holding other factors constant, organizations which have high "administrative overhead" will tend to have a lower calculated productivity index than organizations which maximize time spent working on the most productive project tasks.

SLIM-Estimate® is a macro model based on the software equation described in Measures for Excellence. The SLIM software equation is designed to estimate consistently across a broad spectrum of working environments and accounting standards. For this reason, the effort parameter was originally calculated in Person Years, which are converted to Person Months in SLIM-Estimate. Once the total effort in PM has been determined, it can be converted into your chosen effort unit for display on charts and reports.  But what if you have no historical data and are using the PI suggested by the QSM database? SLIM® estimating and project control tools will still give you a good first estimate that you can continue to refine as more project data becomes available. As projects are completed, SLIM® tools will calculate the project PI's from your historical data. These PI's can be used to calibrate new estimates to the unique conditions in your development environment.

As you begin to compare and analyze PI's from completed projects, you can spot and eliminate bottlenecks as well as identify successful strategies that you can repeat to improve productivity. Storing project metrics in a useful and accessible form and analyzing them to identify trends is the key to process and productivity improvement. Consistent use of SLIM® tools results in increasingly accurate estimates and will help you build a repository of historical data for future analysis and benchmarking.

What options are available for sizing projects in SLIM-Estimate?

The Size Calculator offers a variety of sizing techniques that may be used individually or in combination. One technique is GUI Sizing, which allows you to break the system down into individual components such as screens, reports, dialogs, or your custom components, each of which can have its own gearing factor (LOC/component). The individual component estimates are rolled up into a total size estimate, which will be posted back to the Assumptions screen.

• Sizing by History

Sizing by History is useful early in the software planning cycle when the requirements may still be vague and the design not clearly defined. The technique combines historical size data from the QSM database or your custom trends with your intuition and experience to produce a rough order-of-magnitude size estimate for the proposed system. You are strongly encouraged to review this preliminary size estimate as more information becomes available.

• Total System Mapping

This technique breaks the entire system down into a single functional component of your choice (such as objects, subsystems, etc.) then provides a size estimate based on the expected number of components the system will contain.

• Sizing by Decomposition

Whereas Total System Mapping sizes the system using a single overall sizing unit, Sizing by Decomposition breaks your system down into different groups of components. Each type of component uses its own mapping factor to convert the component estimate into your chosen function unit. The results for each component are then rolled up into a total expected system size. Although Sizing by Decomposition was originally developed for use with GUI languages, it is a very versatile technique that can be used anytime you want to size parts of the system using different sizing components.

• Sizing by Module

This sizing technique decomposes the system into modules (or programs or subsystems). Estimates here should be made in the function unit specified on the Project Environment dialog. While the screen layout for this function is almost identical to that of Sizing by Decomposition, the two techniques are used for different purposes.

Sizing by Module breaks the system into single, like components of different sizes. Each single component has its own mapping factor that converts the total expected size back to your chosen function unit. Sizing by Decomposition, on the other hand, allows you to break down the system into several different groups of like components. Each group has the same mapping factor, which is used to convert each component to your selected function unit.

• Function Point Sizing

Function Point Sizing is an alternative to estimating source lines of code. It attempts to measure the functionality the software will provide. The methodology is based on a weighted sum of the inputs, outputs, files, inquiries, and interfaces provided to or generated by the software.

• Microsoft Excel Sizing by Spreadsheet

In addition to the five sizing techniques just described, you can design your own custom sizing techniques using Microsoft Excel. Several Excel sizing template files (.xlt or .xltx file extension) are installed to the \Tools80\Templates folder when SLIM-Estimate is installed. You can use one of the QSM templates or create your own sizing spreadsheets and import the results into SLIM-Estimate.

What is the purpose of the gearing factor?

Gearing factors are used to convert projects with many different sizing units (objects, modules, or use cases for example) back to a common sizing unit: the Basic Work Unit. The Basic Work Unit represents the smallest sizing unit that is common to all projects.

This conversion is important for two reasons. First, it allows us to apply the same family of PIs (or Productivity Indices) to all projects. Second, it allows you to compare your project, whether it is sized in tables, screens, or any other sizing unit, to QSM’s industry – or your own custom - trend lines, which can be sized in a variety of size units.

In our research, we have found a strong correlation between system size and important metrics like PI, schedule, effort, and defects. For more information on gearing factors, download our free whitepaper.

Today I tried to open a SLIM-Suite file on the network and got an error message that said the file stamp was wrong and the workbook could not be opened. What's going on?

That message appears whenever you try to open a workbook created in a later version of SLIM-Suite with an earlier version of the applications. For example, you tried to open a workbook created in 8.0d with an earlier version of SLIM-Suite like 7.0 or 8.0 a, b or c.

SLIM-Suite workbooks are forward compatible: in other words, you can open and upgrade files created with earlier versions of SLIM-Suite. But they are not backward compatible (older versions of SLIM-Suite cannot open or read files created with a newer version of the applications). 

To open your workbook, you should either upgrade your machine to the latest version of SLIM-Suite or open the file on a machine with the latest version installed. To download the latest version of SLIM-Suite, visit our upgrades page. You’ll need your license email or the readme.txt file in your Tools80 directory to access the license registration and activation codes. The Upgrades page contains instructions for the upgrade as well as an Installation FAQs page that addresses common questions associated with installing or upgrading SLIM-Suite products.

You can also check for updates right from the Help menu. If you still have questions or need help, just contact QSM support for assistance!

There's a good fit between my total defect data and the plan but in the defects by category charts, the defect actuals for each category aren't tracking the plan very well. How can I fix this?

Chances are your defect category percentages need to be adjusted. To tune these percentages using your actual data, create a Multi-Metric Time Series Chart and insert a QSM Tracked Defects Category Total (Actual) metric for each defect category you're tracking:

Next, right click on your chart to access the chart property tabs. On the Data tab, select "Percent of first metric's data points" and click OK to exit the dialog.

Next, toggle your Multi-Metric chart into report form:

If the weekly or monthly values seem fairly consistent, you can simply use the latest % of total for each category. If you see a lot of variation, you may want to average the values - don't be afraid to experiment until you get the best visual fit! Enter the % for each category on the Reliability tab of the Project Environment dialog:

Once you return to the defects by category views, you should see a better fit between the plan and actuals.

Can I use the forecast function to explore various staffing options?

When you run a forecast, SLIM-Control bases the future staffing profile on the peak staff and staffing shape defined in the current plan.

While Phase 3 is ongoing, run a tradeoff forecast to see the impact of increasing or decreasing staff and apply any resulting schedule tradeoff to your existing forecast.  To run a tradeoff forecast, select Control | Tradeoff Forecast… from the menu.

Once Phase 3 has completed, use the maintenance forecast to evaluate staff tradeoffs.  The maintenance forecast can only be performed during Phase 4.  To run a maintenance forecast, select Control | Run Forecast… from the menu.

My current plan is extremely inconsistent with my actual data. For instance, the project started a year late and has already slipped by almost 15 months.  Using my original plan, the actual defect data yields a defect tuning factor of 2000% when I run the Defect Tuning Calculator function. 

Is the plan being factored into the defect tuning calculations? If so, can significant variation between the plan and the actuals result in an incorrect tuning factor?

When looking for the best tuning factor, SLIM-Control must make some assumptions in order to generate a set of theoretical defect curves and find the one that best fits your actual data. If these assumptions are incorrect (for example, if either the expected phase 3 duration or expected effort are wrong) then any calculations based on these assumptions will be affected. 

Before running the Defect Tuning Calculator, it’s a good idea to review the current plan to ensure reasonable consistency with your actual data. If your actuals have diverged significantly from the current plan, it should be updated before defect tuning is performed. To update the current plan, run a forecast, make the forecast the current plan, then re-run the Defect Tuning Calculator. 

Sometimes, one or more of the menu items in SLIM-Control are grayed out and I'm not sure why.

Grayed out menu options generally denote features that will not become available until some condition has been satisfied. Here are some of the most common reasons a menu option may be unavailable:

1.     You're trying to edit a QSM Default custom metric or control bound. Since QSM default custom metrics and control bound definitions cannot be edited, the options for these metrics are grayed out. You can, however,  copy a QSM default metric or control bound definition and edit the copy.

2.     You're trying to enter actual data for a metric that has not started yet or is complete. Before you can enter actual data for a metric, you must first enter an actual start date for that metric. Likewise, once you've entered an actual end date for a metric, you will no longer be able to enter actual data for that metric. 

3.     You're trying to set a start or end date for a metric that is tied to a phase:  Start and end date fields for planned staffing/effort are disabled because staffing and effort data is always tied to a specific phase. For example, phase 2 effort begins on the first day of phase 2 and ends on the last day of phase 2. Start/end dates for each phase are defined on the Phases tab of the Plan property sheet (Control | Plan Data). 

Start dates for Defect metrics are customizable, but defect end dates are disabled because they coincide with the end of the life cycle.

4.     You're trying to enter a start or end date for an inactive phase. On the Plan | Phases tab, planned start or end dates can only be entered for active phases. To view/edit the active phases for the project, select Tools | Customize Project Environment and select the Phases tab.

My actual defect data points don't show up on the defect remaining and defect remaining/sloc reports and graphs.   Why not?

Before we can calculate and display the number of errors remaining, we must know the forecasted number of errors in the system.  Planned defects remaining is the difference between planned total defects and planned defects found at various points in time. Actual defects remaining are calculated by subtracting actual defects found from the forecasted total defects.

Therefore, the actual number of defects remaining will be shown only when a forecast exists.

I changed my runtime environment from 5 days to 7 days. I would have expected my MTTD value to get smaller because I am running the system longer. Why did my MTTD value get larger?

The MTTD value is simply the reciprocal of the monthly defect rate. Suppose the expected defect rate is 100 defects found during the last month of phase 3. This is a theoretical monthly rate number based on an average runtime environment. The MTTD for this month is therefore 1 month/100 errors or .01 months between defects. 

Because it is difficult to think in terms of .01 months, you can specify a more intuitive MTTD time unit.  If you select days, then .01 months is the same as .01 * 30 (roughly) or .3 days between defects (assuming you are running 7 days a week). However, if you are running only 5 days a week, then .01 months converts to (.01 * 20) or .2 days.

I sometimes get poor defect curve fits when running a forecast.  What can I do to improve this?

Getting a good curve fit is important - the poorer the fit, the less confidence you will have in the projected new time for that set of data. The goodness of fit is particularly important during the latter stages of Phase 3 because defect data is weighted more heavily at that time. There are two things you can do to improve your defect curve fits:

1.  Assess the reliability of early data points carefully. If you have little confidence in the earliest defect data, you should throw it out. Our theoretical defect data curve algorithm assumes defects are being captured from the start of Phase 3 in a consistent and systematic manner. In practice, however, systematic logging of defects is often not performed until around Systems Integration Test (71% of phase 3 duration). If your early defect data is very erratic, chances are those data points are unreliable. If you know (or suspect) this to be the case, exclude the unreliable data points from curve fitting and forecasting. Unreliable data introduces random noise into SLIM-Control's calculations and creates unreliable forecasts.

2.  Try to determine the best tuning factor for your defect data. This is fairly easy to do once any early noisy data points have been discarded. There are two ways to get a handle on the defect tuning factor.  You can use either one, or combine the two methods:

• The first method uses past projects to generate a historic defect tuning factor. You can use any similar projects captured in SLIM-DataManager. Individual defect tuning factors for each project can be displayed on DataManager’s Project List View by selecting Tools | Customize View Layout from the menu. To get the average Defect Tuning Factor for one or more completed projects, import them into SLIM-Control using the History | Load Projects menu item and then run the Defect Tuning Calculator.  If you plan on using an average DTF from your history, you may wish to inspect the data and eliminate outliers to prevent distortion of the average.
• Once you have entered at least three actual total defect data points into SLIM-Control the Defect Tuning Calculator can also calculate a defect tuning factor from your actual defect data.

Once the expected defect total has been tuned to your history or actual data, you should see an improvement in your defect curve fits. If you’re tracking Defects Found by Category, here's one final step that will help ensure optimal curve fits:

• Tune the % of total defects for each category using your actual data. For more information on how to do this, see the FAQ entitled, "How Do I Tune My Defect Category Percentages?".

If you are still getting poor data fits after performing the steps outlined above, either try to determine the reasons or simply exclude defect data from the forecast curve fit.

The Solution Panel says my peak staff value is 10.3, but the Average Staffing Rate charts and reports show a peak staff of 10.1. What is causing this inconsistency?

The theoretical Rayleigh curve used to derive the values on the Solution Panel is a smooth curve resulting in different staffing numbers at each point along the x-axis. In drawing the Average Staffing chart, this smooth theoretical curve is approximated by a series of discrete staffing rates (with one bar, or average staffing rate value, per month).

The graph and solution panel values won't always match exactly because the graphical peak staff is always taken mid-month for any internal month while the solution panel always shows the highest peak staff point on the staffing curve (regardless of when it occurs). Usually the theoretical curve does not peak exactly at mid-month, so the true peak shown on the solution panel will not match the one on the average staffing charts unless the theoretical peak happens to fall at mid-month.

On large projects where a longer schedule allows a natural smoothing of the staffing curve, the theoretical peak staff will usually be close to the average staff rate value. On shorter projects, you can expect to see larger discrepancies.

How does SLIM-Control handle missing actual data points?

The answer to this question depends on the context. You can display interpolated or missing data points on charts via the "display interpolated data" option in the chart properties. If possible, SLIM-Control will interpolate missing data points using the expected shape of the associated metric curve. Note that only interior data points can be interpolated - SLIM-Control needs a start and end point for interpolation.

It's important to realize that interpolated data points have no bearing on the analysis of actual data in SLIM-Control. When you run a forecast, missing data points are not used during curve fit analysis. The only time missing data is not completely ignored is in the case of milestones. If a milestone should have occurred prior to the projection date (and no actual milestone date has been entered), SLIM-Control assumes the milestone has been missed and the earliest it can occur is immediately after the date of projection. If more than one milestone is "missing", it is assumed that they have all been missed, and that the earliest missed milestone cannot occur before the date of projection.

When I change the Person Hours per Person Month field on the Accounting tab of the Solution Assumptions dialog, there is no change to the total schedule and effort for the project. Why is this?

Many SLIM-Estimate and SLIM-Control users have asked why their overall schedule does not change when they change the value of the "Person Hours per Person Month" field,  Solution Assumptions screen, Accounting Tab.

The number of Person Hours comprising a particular organization's Person Month is not used to calculate total effort.  If your chosen effort unit is Person Months, the hours per month setting is not used at all. If, on the other hand, your effort unit is weeks, days, or hours, your hours per month will be used to convert the estimated total effort (in Person Months) into your chosen effort unit.

At first, this may seem counter-intuitive. Shouldn't an increase or decrease in the number of Person Hours in a Person Month be reflected in the final estimate?

The number of staff hours in an organization's staffing month is more relevant in the accounting world than it is in software estimation. It attempts to account for items such as vacations, meetings, and administrative activities but in most cases, it is merely an estimate or average.  It may tell how many hours will be charged to a particular project, but has nothing to say about how much is actually accomplished during those hours (or even how many actual hours were worked). The productivity index, or PI, is where actual work produced is measured.

The Productivity Index, or PI, reflects a number of environmental factors such as:

If you are using a PI calculated from your past projects, your user-specified PI already reflects the conditions in your working environment. Holding other factors constant, organizations which have high "administrative overhead" will tend to have a lower calculated productivity index than organizations which maximize time spent working on the most productive project tasks.

SLIM-Estimate® is a macro model based on the software equation described in Measures for Excellence. The SLIM software equation is designed to estimate consistently across a broad spectrum of working environments and accounting standards. For this reason, the effort parameter was originally calculated in Person Years, which are converted to Person Months in SLIM-Estimate. Once the total effort in PM has been determined, it can be converted into your chosen effort unit for display on charts and reports.  But what if you have no historical data and are using the PI suggested by the QSM database? SLIM® estimating and project control tools will still give you a good first estimate that you can continue to refine as more project data becomes available. As projects are completed, SLIM® tools will calculate the project PI's from your historical data. These PI's can be used to calibrate new estimates to the unique conditions in your development environment.

As you begin to compare and analyze PI's from completed projects, you can spot and eliminate bottlenecks as well as identify successful strategies that you can repeat to improve productivity. Storing project metrics in a useful and accessible form and analyzing them to identify trends is the key to process and productivity improvement. Consistent use of SLIM® tools results in increasingly accurate estimates and will help you build a repository of historical data for future analysis and benchmarking.

I’d like my MTTD forecasts to reflect the number of test hours for each reporting period. How do I do this in SLIM-Control?

The Weighted MTTD option allows you to account for the actual hours spent testing each reporting period. Often the number of test hours fluctuates from month to month, causing large swings or "find and fix cycles" as test effort is directed to finding defects one period, then drops off as effort goes into fixing newly discovered defects during the next period. Using the Weighted MTTD option will smooth out these "find and fix" cycles, giving you a smoother defect curve.  Be sure to click the box at the top of the Metric Definitions dialog box in order to display both active and inactive metrics.

To use the Weighted MTTD metric, you must activate it by choosing Tools | Customize Metric Definitions from the menu. Locate the active defect metrics folder (Hint: the folder title will be bolded). If you don't see the metric, make sure you are displaying all active and inactive metrics. Scroll down and select the Weighted MTTD metric, then click the Edit Metric button:

Activate the metric by checking the “Active” checkbox and click OK to exit.

Next, activate the QSM Test folder. Note the lack of bold type – this category is inactive by default. Select the folder title and activate the category using the Edit Category button:

Click OK to save your changes and exit the Metrics Definitions dialogs.

The number of testing hours per reporting period should now appear on the Metrics tab of the Actual Data screen (select Control | Actual Data from the menu). As with all custom metrics, the testing hours field is appended to the list of standard metrics so you will need to scroll down to the bottom of the metric list to see the Test Hours field. This is where you will enter the actual hours spent testing for each reporting period.

How are the control bounds in SLIM-Control® calculated? Can I change them?

SLIM-Control® ships with a set of pre-defined control bound shapes and widths to help you assess variation of the project actuals from the plan. 

QSM control bound limits typically default to a percentage of the planned total or peak value for the metric being displayed, but you can copy and edit our default control bounds or create your own from scratch! In the custom control bound definition below, the green upper control bound is wider (14% of the planned peak value) than the lower green control bound (11% of the planned peak):

Wider control bounds allow more deviation from the plan before triggering a visual warning. Narrower control bounds provide earlier warning and tighter control. QSM default control bounds vary in width depending on whether the metric being assessed is in rate or cumulative form. Because defect data is typically more variable than other software metrics, control bounds for defect metrics default to twice the width of regular rate and cumulative control bounds. 

Regardless of whether you use QSM default control limits or create your own control bound rules, SLIM-Control’s status icons help you instantly assess the status of various project metrics and take corrective action:

• When your actual data fall an average of one control bound from the plan, a green status icon lets you know the variation is within acceptable limits. When calculating the average distance from the plan, SLIM-Control® considers all data points but gives more weight to the later data points.
• When actual data average 1-2 control bounds from the plan, a yellow (warning) status icon is shown. The yellow icon alerts the user that the displayed metric needs to be monitored closely.
• When the data points average more than 2 control bounds from the plan, a red status icon will be displayed to indicate that re-planning may be needed. The user can generate a new forecast to completion to learn the impact of current deviations upon the delivery date.

The Scoreboard Summary Report can even create an audit trail for key project metrics over time:

Need more information before making a decision? SLIM-Control’s Snapshot Manager records the status (green, yellow, or red) of various metrics as the project unfolds. This time series view adds context to your analysis: if a “red” metric has consistently lagged behind the plan, it’s probably time to take corrective action. If the same metric has stayed in the green region for the entire project, a red status icon could alert you to a possible data entry error.

SLIM-Control’s customizable control bounds, status icons, and snapshot manager make tracking and monitoring projects a snap!

Today I tried to open a SLIM-Suite file on the network and got an error message that said the file stamp was wrong and the workbook could not be opened. What's going on?

That message appears whenever you try to open a workbook created in a later version of SLIM-Suite with an earlier version of the applications. For example, you tried to open a workbook created in 8.0d with an earlier version of SLIM-Suite like 7.0 or 8.0 a, b or c.

SLIM-Suite workbooks are forward compatible: in other words, you can open and upgrade files created with earlier versions of SLIM-Suite. But they are not backward compatible (older versions of SLIM-Suite cannot open or read files created with a newer version of the applications). 

To open your workbook, you should either upgrade your machine to the latest version of SLIM-Suite or open the file on a machine with the latest version installed. To download the latest version of SLIM-Suite, visit our upgrades page. You’ll need your license email or the readme.txt file in your Tools80 directory to access the license registration and activation codes. The Upgrades page contains instructions for the upgrade as well as an Installation FAQs page that addresses common questions associated with installing or upgrading SLIM-Suite products.

You can also check for updates right from the Help menu. If you still have questions or need help, just contact QSM support for assistance!

I created custom trends in SLIM Metrics, but I can't get them to work in SLIM-Estimate. What am I doing wrong?

Chances are your workbook has missing reference data or is pointing to the wrong set of trends. 

• If you're using Version 8.0a or later: 
  
  
  • Make sure you have created reference data for PI vs. Effective Size. Reference data for this metric pair must be present in order to perform the PI calculation. If it is missing, the “Calculate a PI from currently selected trend lines” option will be grayed out.
  • Make sure the default reference group in your SLIM-Estimate file matches the reference group you created in SLIM-Metrics. If it points to another reference group or to "None", your custom data will not be used. To select your custom reference data, select Tools | Customize Project Environment from the menu and select your trend from the Primary Trend Group combo box.
    
    
    
    When you click OK, two things will occur. First, that reference group will be the default shown on all new charts and reports created in your workbook. Any charts or reports which are already present will not be affected unless the trend line shown is set to Automatic, but you can easily change this by right-clicking on any chart and adjusting the chart properties.
    
    Secondly, the default PI dialogs will now offer you a choice between the default QSM PI and the reference group or trend mix you chose on the Project Environment dialog. 
    
    
    
    You can use this new set of trends for the default PI on the PI Calculator (via the Solution Assumptions dialog), Quick Estimate Wizard, and Level of Effort Wizard when generating new estimates.
    
    
• If you're using Version 7.0 or earlier: 
  
  
  • Select Edit | Workbook Options | Reference Data from the menu. Make sure the Manual radio button is selected and your custom reference trends appear in the Manual combo box. 
  • Check your custom reference trends in SLIM-Metrics. They should include the following reference trends:
    • Average Staff vs. Effective Size
    • Phase 3 Effort (MM) vs. Effective Size
    • Phase 3 Duration (months) vs. Effective Size

Today I tried to open a SLIM-Suite file on the network and got an error message that said the file stamp was wrong and the workbook could not be opened. What's going on?

That message appears whenever you try to open a workbook created in a later version of SLIM-Suite with an earlier version of the applications. For example, you tried to open a workbook created in 8.0d with an earlier version of SLIM-Suite like 7.0 or 8.0 a, b or c.

SLIM-Suite workbooks are forward compatible: in other words, you can open and upgrade files created with earlier versions of SLIM-Suite. But they are not backward compatible (older versions of SLIM-Suite cannot open or read files created with a newer version of the applications). 

To open your workbook, you should either upgrade your machine to the latest version of SLIM-Suite or open the file on a machine with the latest version installed. To download the latest version of SLIM-Suite, visit our upgrades page. You’ll need your license email or the readme.txt file in your Tools80 directory to access the license registration and activation codes. The Upgrades page contains instructions for the upgrade as well as an Installation FAQs page that addresses common questions associated with installing or upgrading SLIM-Suite products.

You can also check for updates right from the Help menu. If you still have questions or need help, just contact QSM support for assistance!

What is the difference between the Basic Work Unit and the Function Unit?

The Function Unit is the overall size measure for the project.  It makes sense to describe a book as a collection of chapters or a building by the number of floors or rooms it contains. The Function Unit allows estimators to describe a system as a group of functional or logical components (function points, modules, objects, or screens).

The Function unit is defined by three components:

1. A name  (SLOC, Function Points, CSCI, etc.)  

2. A number or count (257 function points, 83 modules). 

3. A gearing factor, which is a normalization or scaling factor that relates projects with different Function Units back to a common unit of measure: the Basic Unit of Work.  The Basic Unit of Work is conceptually similar to the least common denominator (LCD) in mathematics.

Why use a gearing factor at all?  The QSM database contains thousands of projects sized in different Function Units.  Without a common reference point – a basic work unit – it would be impossible to make meaningful size comparisons between a project sized in Function Points and one sized in Objects or Requirements.

To go back to our building analogy, people often use floors or rooms to convey a rough idea of the size of various buildings. But a floor of a single-family home is not necessarily the same size as a floor of a large office building.  And we can't easily compare a building sized in rooms to one sized in floors without some way to know how big a room is, relative to a floor. To make the comparison meaningful we need to identify a smaller, common size unit (the number of cubic feet per floor or per room, perhaps).  Using this basic size measure, we can "normalize" the size of a floor or a room to cubic feet. We can compare the size of a 4 story office building to a 2 story house. We can also compare a 2 story house to a 10 room apartment because in both cases, we can convert stories or rooms to cubic feet. 

For software projects, the Basic Work Unit performs the same function as cubic feet did when we were describing buildings. The number of cubic feet in a floor or room is analogous to the gearing factor, and cubic feet to the Basic Work Unit.  In previous versions of SLIM tools, the basic work unit was always SLOC. If you are developing the system using a statement-oriented programming language, your basic work unit will usually be SLOC.

If you are developing in a non-statement oriented language or environment, the Basic Work Unit field in Global Options allows you to choose a basic work unit that reflects the work being performed.  You should select a basic work unit that is roughly equivalent in time/effort to writing a line of code. The gearing factor for the basic work unit will always be 1 - it cannot be set by the user.

To set up the sizing units for an estimate, you should do three things:

1. Choose a Basic Work Unit in Global Options.  Normally there is no reason to change the default unless you prefer another name.

2. Choose a Function Unit on the project environment screen.  By default, the Basic Work Unit is always the first item in the Function Unit list box. To size your project in the same unit as your Basic Work Unit (for example, if you are sizing the entire system in a basic unit such as SLOC or Object Properties), simply leave this field unchanged.  Otherwise, select the desired function unit from the list box or add a new entry.

3. Enter a gearing factor appropriate for the Basic Work Unit and Function Unit you have selected (i.e. the Basic Work Units/Function Unit) Some examples are:  # of SLOC per Function Point or # of Object Properties per Object. 

In SLIM-DataManager, you can set the Basic Work Unit on the Database Defaults screen.

If you need help determining an appropriate gearing factor, visit the Function Point Gearing Factors page on the QSM web site, download our gearing factors whitepaper, or contact QSM for assistance.

Today I tried to open a SLIM-Suite file on the network and got an error message that said the file stamp was wrong and the workbook could not be opened. What's going on?

That message appears whenever you try to open a workbook created in a later version of SLIM-Suite with an earlier version of the applications. For example, you tried to open a workbook created in 8.0d with an earlier version of SLIM-Suite like 7.0 or 8.0 a, b or c.

SLIM-Suite workbooks are forward compatible: in other words, you can open and upgrade files created with earlier versions of SLIM-Suite. But they are not backward compatible (older versions of SLIM-Suite cannot open or read files created with a newer version of the applications). 

To open your workbook, you should either upgrade your machine to the latest version of SLIM-Suite or open the file on a machine with the latest version installed. To download the latest version of SLIM-Suite, visit our upgrades page. You’ll need your license email or the readme.txt file in your Tools80 directory to access the license registration and activation codes. The Upgrades page contains instructions for the upgrade as well as an Installation FAQs page that addresses common questions associated with installing or upgrading SLIM-Suite products.

You can also check for updates right from the Help menu. If you still have questions or need help, just contact QSM support for assistance!

Is there a limit on the number of projects that can be loaded into SLIM-MasterPlan?

There is no limit to the number of projects you can load into MasterPlan other than what is allowed by the graphics and memory capabilities of your PC. But if your MasterPlan workbook includes an unusually large number of projects it may be difficult to see all the projects clearly on graphs.

Here are some suggestions for MasterPlan files with a large number of projects:

• Place a single graph on each view to allow more room for MasterPlan to display the projects onscreen.
• Use the Level of Detail tab in Gantt Chart Properties to adjust the number of levels shown
• Group your projects by category, perhaps by division, year, budget, or program to make your MasterPlan estimates more meaningful
• Consider moving projects which are more similar to iterations to SLIM-Estimate as a Work Breakdown Structure (WBS)

What's the best way to get SLIM-Suite reports and graphs into other applications?

There's a good fit between my total defect data and the plan but in the defects by category charts, the defect actuals for each category aren't tracking the plan very well. How can I fix this?

Chances are your defect category percentages need to be adjusted. To tune these percentages using your actual data, create a Multi-Metric Time Series Chart and insert a QSM Tracked Defects Category Total (Actual) metric for each defect category you're tracking:

Next, right click on your chart to access the chart property tabs. On the Data tab, select "Percent of first metric's data points" and click OK to exit the dialog.

Next, toggle your Multi-Metric chart into report form:

If the weekly or monthly values seem fairly consistent, you can simply use the latest % of total for each category. If you see a lot of variation, you may want to average the values - don't be afraid to experiment until you get the best visual fit! Enter the % for each category on the Reliability tab of the Project Environment dialog:

Once you return to the defects by category views, you should see a better fit between the plan and actuals.

My actual defect data points don't show up on the defect remaining and defect remaining/sloc reports and graphs.   Why not?

Before we can calculate and display the number of errors remaining, we must know the forecasted number of errors in the system.  Planned defects remaining is the difference between planned total defects and planned defects found at various points in time. Actual defects remaining are calculated by subtracting actual defects found from the forecasted total defects.

Therefore, the actual number of defects remaining will be shown only when a forecast exists.

The Solution Panel says my peak staff value is 10.3, but the Average Staffing Rate charts and reports show a peak staff of 10.1. What is causing this inconsistency?

The theoretical Rayleigh curve used to derive the values on the Solution Panel is a smooth curve resulting in different staffing numbers at each point along the x-axis. In drawing the Average Staffing chart, this smooth theoretical curve is approximated by a series of discrete staffing rates (with one bar, or average staffing rate value, per month).

The graph and solution panel values won't always match exactly because the graphical peak staff is always taken mid-month for any internal month while the solution panel always shows the highest peak staff point on the staffing curve (regardless of when it occurs). Usually the theoretical curve does not peak exactly at mid-month, so the true peak shown on the solution panel will not match the one on the average staffing charts unless the theoretical peak happens to fall at mid-month.

On large projects where a longer schedule allows a natural smoothing of the staffing curve, the theoretical peak staff will usually be close to the average staff rate value. On shorter projects, you can expect to see larger discrepancies.

When I change the Person Hours per Person Month field in Accounting Options, there is no change to the total schedule and effort for the project.  How can I adjust the estimate to reflect overtime?

The person hours/person month field was never intended to be used for performing time/effort tradeoffs.  For estimating purposes, SLIM-Estimate assumes that a FTE person is a FTE person, regardless of the number of hours in an effort month.  To account for overtime or unusual staffing situations, you should adjust the FTE (full-time equivalent) peak staffing level.  

For example, to reflect 10% overtime, you need a peak staff that is 1.1 times the current peak.  You can do this using the Control Panel peak staffing dial or by extending or shortening the Phase 3 schedule.

NOTE: if you are using a PI from your completed projects, you should only make this type of adjustment if your history does not include overtime.  It is usually better to be conservative in making adjustments as overtime hours are often less productive.  If the completed projects you used to derive a PI had a similar amount of overtime, it is already reflected in the PI and no adjustment is needed.  

I have an estimate with one very short phase. When I view the Staffing Profile in aggregate mode, the staffing for the final month of that phase does not appear to dip down as it does when I view the individual phases. Why not?

The aggregate staffing chart shows the maximum FTE (full-time equivalent) staff rate during any given month.  For months where two phases overlap, the staffing values for both phases are combined to get the total staffing for that month.  

Sometimes the effort data points on my Life Cycle Sensitivity to PI graph have values that do not always increase (or decrease); e.g., there are small dips in the data.

Remember that the time and effort shown on these graphs are life cycle values. The most likely cause of slight variations in the expected behavior of the data is caused by variation in the effort for phase 4. Staffing projections for phase 4 are dependent on the staffing rate at the end of phase 3. Therefore, differences in the final phase 3 staffing rate can result in variations in the total effort for phase 4. You can check to see if this is the case by making the solutions in question the current solution, then comparing the phase 4 effort in the solution panel of the staffing view.

Sometimes the time data points on my Sensitivity graph are not in a straight line; sometimes 2 or 3 points may even have the same value.

Time values on sensitivity charts are rounded to the nearest day. For very small size increments, this rounding may result in 2 or 3 data points having the same value.

What is the impact of selecting various phase staffing shapes? When should I deviate from the default Rayleigh pattern, and how is my estimate affected?

We have found that the default Rayleigh pattern is the staffing pattern that best matches the application of effort to the work to be performed but due to staffing constraints or different software management styles, you may decide that another staffing pattern fits your organization or project better.

In general, the various staffing shapes can be described as follows: 

• Front Load Rayleigh peaks at approximately 40% the phase 
• Medium Front Load Rayleigh peaks midway through the phase 
• Medium Rear Load Rayleigh peaks at approximately 75% of the phase 
• Rear Load Rayleigh (Phase 3 only) peaks at the end of the phase 
• Level Load maintains a constant staffing level over the entire phase
• Exponential (Phase 4 only) gives the most rapid drop off of staffing from the end of Phase 3.
• Stair Step (Phase 4 only) begins at about half of the staffing level from the end of Phase 3 and stair steps down.
• Straight Line: (Phase 4 only) represents a straight-line decrease in staffing from the end of Phase 3.
• Rayleigh (Phase 4 only) is a natural tailing off/continuation of any Phase 3 Rayleigh curve. Not valid if the selected Phase 3 staffing shape is Level Load. 

Level loading is generally seen in the development of very small systems. In larger systems, early application of people often represents wasted effort. The Default Rayleigh shape determines the staffing shape based on the size of the application. QSM has found that small projects (less than 18,000 lines of code) tend to have a Front Load Rayleigh profile while larger systems (greater than 100,000 lines of code) typically reach peak staffing towards the end of phase 3. For very small systems (3 to 6 months in duration with a peak staff of 1-3 persons), a level load profile is more appropriate.

The estimated total effort for each of the staffing patterns for the first three phases will remain constant regardless of the pattern selected. Phase 4 effort will vary, depending on the shape of phase 3. This is because in phase 4, manpower tails off from the final Phase 3 staffing level and is therefore a function of the number of people on board at the end of phase 3 and the length of phase 4. Projects that peak at the end of Phase 3 will have higher phase 4 effort. Projects that peak earlier will have lower phase 4 effort.

If you are using default QSM overlaps for the phases, you can expect to see some differences in the phase overlap when you change the staffing pattern. This occurs because SLIM attempts to produce the smoothest aggregate staffing pattern when moving from one phase to the next.

For example, the overlap percentage between Phases 2 and 3 will be 0% if Phase 3 is Level Loaded. Otherwise the overlap ratio will range from  33% to 40% as the phase 2 staffing shape changes from Front Load Rayleigh to Medium Front Load Rayleigh.

Is there a limit on the number of projects that can be loaded into SLIM-MasterPlan?

There is no limit to the number of projects you can load into MasterPlan other than what is allowed by the graphics and memory capabilities of your PC. But if your MasterPlan workbook includes an unusually large number of projects it may be difficult to see all the projects clearly on graphs.

Here are some suggestions for MasterPlan files with a large number of projects:

• Place a single graph on each view to allow more room for MasterPlan to display the projects onscreen.
• Use the Level of Detail tab in Gantt Chart Properties to adjust the number of levels shown
• Group your projects by category, perhaps by division, year, budget, or program to make your MasterPlan estimates more meaningful
• Consider moving projects which are more similar to iterations to SLIM-Estimate as a Work Breakdown Structure (WBS)

My current plan is extremely inconsistent with my actual data. For instance, the project started a year late and has already slipped by almost 15 months.  Using my original plan, the actual defect data yields a defect tuning factor of 2000% when I run the Defect Tuning Calculator function. 

Is the plan being factored into the defect tuning calculations? If so, can significant variation between the plan and the actuals result in an incorrect tuning factor?

When looking for the best tuning factor, SLIM-Control must make some assumptions in order to generate a set of theoretical defect curves and find the one that best fits your actual data. If these assumptions are incorrect (for example, if either the expected phase 3 duration or expected effort are wrong) then any calculations based on these assumptions will be affected. 

Before running the Defect Tuning Calculator, it’s a good idea to review the current plan to ensure reasonable consistency with your actual data. If your actuals have diverged significantly from the current plan, it should be updated before defect tuning is performed. To update the current plan, run a forecast, make the forecast the current plan, then re-run the Defect Tuning Calculator. 

The planned MTTD value shown on my graph for the final month of phase 3 is not the same as the value reported in the Project Profile report and the consistency report for my Phase 3 MTTD. It appears to be slightly higher in the reports.  Why?

The value displayed on graphs is the average MTTD rate for the final month of phase 3, but the MTTD value reported in the reports represents the planned MTTD at the end of phase 3. You should expect this value to be somewhat higher than the average value for the entire month, because the theoretical MTTD is always improving (getting larger) as time progresses.

On the Sensitivity to Size graph, I thought the MTTD (Mean Time To Defect) would decrease (become worse) as the system size increases because the total errors should be increasing.

On Sensitivity graphs, peak staff is held constant as system size increases***, resulting in a more moderate manpower buildup.  Error production is linearly related to size but exponentially related to effort, so holding effort constant while increasing size results in an easier project, relative to the size increase.  

*** Unless the MBI approaches -3 or 10.  If the MBI goes outside of the allowable -3 to 10 range, the peak staff will be reset to a reasonable value.

My actual defect data points don't show up on the defect remaining and defect remaining/sloc reports and graphs.   Why not?

Before we can calculate and display the number of errors remaining, we must know the forecasted number of errors in the system.  Planned defects remaining is the difference between planned total defects and planned defects found at various points in time. Actual defects remaining are calculated by subtracting actual defects found from the forecasted total defects.

Therefore, the actual number of defects remaining will be shown only when a forecast exists.

I changed my runtime environment from 5 days to 7 days. I would have expected my MTTD value to get smaller because I am running the system longer. Why did my MTTD value get larger?

The MTTD value is simply the reciprocal of the monthly defect rate. Suppose the expected defect rate is 100 defects found during the last month of phase 3. This is a theoretical monthly rate number based on an average runtime environment. The MTTD for this month is therefore 1 month/100 errors or .01 months between defects. 

Because it is difficult to think in terms of .01 months, you can specify a more intuitive MTTD time unit.  If you select days, then .01 months is the same as .01 * 30 (roughly) or .3 days between defects (assuming you are running 7 days a week). However, if you are running only 5 days a week, then .01 months converts to (.01 * 20) or .2 days.

I sometimes get poor defect curve fits when running a forecast.  What can I do to improve this?

Getting a good curve fit is important - the poorer the fit, the less confidence you will have in the projected new time for that set of data. The goodness of fit is particularly important during the latter stages of Phase 3 because defect data is weighted more heavily at that time. There are two things you can do to improve your defect curve fits:

1.  Assess the reliability of early data points carefully. If you have little confidence in the earliest defect data, you should throw it out. Our theoretical defect data curve algorithm assumes defects are being captured from the start of Phase 3 in a consistent and systematic manner. In practice, however, systematic logging of defects is often not performed until around Systems Integration Test (71% of phase 3 duration). If your early defect data is very erratic, chances are those data points are unreliable. If you know (or suspect) this to be the case, exclude the unreliable data points from curve fitting and forecasting. Unreliable data introduces random noise into SLIM-Control's calculations and creates unreliable forecasts.

2.  Try to determine the best tuning factor for your defect data. This is fairly easy to do once any early noisy data points have been discarded. There are two ways to get a handle on the defect tuning factor.  You can use either one, or combine the two methods:

• The first method uses past projects to generate a historic defect tuning factor. You can use any similar projects captured in SLIM-DataManager. Individual defect tuning factors for each project can be displayed on DataManager’s Project List View by selecting Tools | Customize View Layout from the menu. To get the average Defect Tuning Factor for one or more completed projects, import them into SLIM-Control using the History | Load Projects menu item and then run the Defect Tuning Calculator.  If you plan on using an average DTF from your history, you may wish to inspect the data and eliminate outliers to prevent distortion of the average.
• Once you have entered at least three actual total defect data points into SLIM-Control the Defect Tuning Calculator can also calculate a defect tuning factor from your actual defect data.

Once the expected defect total has been tuned to your history or actual data, you should see an improvement in your defect curve fits. If you’re tracking Defects Found by Category, here's one final step that will help ensure optimal curve fits:

• Tune the % of total defects for each category using your actual data. For more information on how to do this, see the FAQ entitled, "How Do I Tune My Defect Category Percentages?".

If you are still getting poor data fits after performing the steps outlined above, either try to determine the reasons or simply exclude defect data from the forecast curve fit.

My actual MTTD data points start at different times depending on whether there is a forecast being displayed. Why?

MTTD is not truly relevant until the entire system is integrated and functioning as a complete entity.  For this reason, MTTD values are not shown until Systems Integration Test (which occurs at about 71% of phase 3).   

Because we do not know the actual phase 3 time until the system is completed, we show actual MTTD data points starting at the same time as the plan unless there is a forecast present. Planned MTTD data points will always begin at about 71% of the planned phase 3 time. 

Once a forecast is present, the actual/forecast MTTD data points will be shown starting at 71% of the forecasted phase 3 time.

I’d like my MTTD forecasts to reflect the number of test hours for each reporting period. How do I do this in SLIM-Control?

The Weighted MTTD option allows you to account for the actual hours spent testing each reporting period. Often the number of test hours fluctuates from month to month, causing large swings or "find and fix cycles" as test effort is directed to finding defects one period, then drops off as effort goes into fixing newly discovered defects during the next period. Using the Weighted MTTD option will smooth out these "find and fix" cycles, giving you a smoother defect curve.  Be sure to click the box at the top of the Metric Definitions dialog box in order to display both active and inactive metrics.

To use the Weighted MTTD metric, you must activate it by choosing Tools | Customize Metric Definitions from the menu. Locate the active defect metrics folder (Hint: the folder title will be bolded). If you don't see the metric, make sure you are displaying all active and inactive metrics. Scroll down and select the Weighted MTTD metric, then click the Edit Metric button:

Activate the metric by checking the “Active” checkbox and click OK to exit.

Next, activate the QSM Test folder. Note the lack of bold type – this category is inactive by default. Select the folder title and activate the category using the Edit Category button:

Click OK to save your changes and exit the Metrics Definitions dialogs.

The number of testing hours per reporting period should now appear on the Metrics tab of the Actual Data screen (select Control | Actual Data from the menu). As with all custom metrics, the testing hours field is appended to the list of standard metrics so you will need to scroll down to the bottom of the metric list to see the Test Hours field. This is where you will enter the actual hours spent testing for each reporting period.

Today I tried to open a SLIM-Suite file on the network and got an error message that said the file stamp was wrong and the workbook could not be opened. What's going on?

That message appears whenever you try to open a workbook created in a later version of SLIM-Suite with an earlier version of the applications. For example, you tried to open a workbook created in 8.0d with an earlier version of SLIM-Suite like 7.0 or 8.0 a, b or c.

SLIM-Suite workbooks are forward compatible: in other words, you can open and upgrade files created with earlier versions of SLIM-Suite. But they are not backward compatible (older versions of SLIM-Suite cannot open or read files created with a newer version of the applications). 

To open your workbook, you should either upgrade your machine to the latest version of SLIM-Suite or open the file on a machine with the latest version installed. To download the latest version of SLIM-Suite, visit our upgrades page. You’ll need your license email or the readme.txt file in your Tools80 directory to access the license registration and activation codes. The Upgrades page contains instructions for the upgrade as well as an Installation FAQs page that addresses common questions associated with installing or upgrading SLIM-Suite products.

You can also check for updates right from the Help menu. If you still have questions or need help, just contact QSM support for assistance!

This error is a message generated by the DAO Engine. It occurs when input exceeds the maximum size for the database field we’re trying to write to.  Please contact QSM Support if you see this error message.

I increased the PI on one of my estimates from 14.6 to 20.3. When I ran the optimized solution, I got an error message that said the new solution was out of bounds. What went wrong?

If you increase the PI while keeping the MBI (Manpower Buildup Index) the same, you are telling SLIM to keep applying manpower at the same rate in spite of the dramatically higher productivity of 20.3. But if a project operating at a much higher level of productivity does not need as many people as a project team with very low productivity.

At a PI of 20.3,  the calculated peak staff level falls to only .5 (half a Full-Time Equivalent person). This value is below the reasonable effort range, so SLIM generates the following error:

"Your calculated solution is below SLIM's minimum peak staff of .5 people. Your solution will be reset to the last valid solution".

After increasing the PI, you should allow SLIM to calculate a manpower buildup rate that matches the increase in productivity. At the bottom of the Solution Assumptions screen, you can choose between the current MBI and a QSM default MBI.

Selecting the Unconstrained (QSM Default Solution) solution method will provide a more reasonable bui effort buildup consistent with your new PI. 

What's the best way to get SLIM-Suite reports and graphs into other applications?

There's a good fit between my total defect data and the plan but in the defects by category charts, the defect actuals for each category aren't tracking the plan very well. How can I fix this?

Chances are your defect category percentages need to be adjusted. To tune these percentages using your actual data, create a Multi-Metric Time Series Chart and insert a QSM Tracked Defects Category Total (Actual) metric for each defect category you're tracking:

Next, right click on your chart to access the chart property tabs. On the Data tab, select "Percent of first metric's data points" and click OK to exit the dialog.

Next, toggle your Multi-Metric chart into report form:

If the weekly or monthly values seem fairly consistent, you can simply use the latest % of total for each category. If you see a lot of variation, you may want to average the values - don't be afraid to experiment until you get the best visual fit! Enter the % for each category on the Reliability tab of the Project Environment dialog:

Once you return to the defects by category views, you should see a better fit between the plan and actuals.

My current plan is extremely inconsistent with my actual data. For instance, the project started a year late and has already slipped by almost 15 months.  Using my original plan, the actual defect data yields a defect tuning factor of 2000% when I run the Defect Tuning Calculator function. 

Is the plan being factored into the defect tuning calculations? If so, can significant variation between the plan and the actuals result in an incorrect tuning factor?

When looking for the best tuning factor, SLIM-Control must make some assumptions in order to generate a set of theoretical defect curves and find the one that best fits your actual data. If these assumptions are incorrect (for example, if either the expected phase 3 duration or expected effort are wrong) then any calculations based on these assumptions will be affected. 

Before running the Defect Tuning Calculator, it’s a good idea to review the current plan to ensure reasonable consistency with your actual data. If your actuals have diverged significantly from the current plan, it should be updated before defect tuning is performed. To update the current plan, run a forecast, make the forecast the current plan, then re-run the Defect Tuning Calculator. 

The skill category percentages are set by the user in the Work Breakdown Structure (WBS) area of SLIM-Estimate.  If you don’t have a WBS or WBS template, you can use the QSM default settings.

To customize the skill category percentages, select Tools | Customize WBS then select Setup Skill Categories.  On the WBS tab, click the radio button for Edit Skill Category Percentages by Task to input your own values for skill percentages.

How do I set Phase Start dates?

To set Phase Start dates, simply click Estimate | Solution Assumptions, then select the Phase Tuning tab.  Please note that you cannot select the start date for Phase 1, nor can you set the start date for the first phase included in the project. The first included phase will always begin on the start date specified in the Solution Assumptions or Wizards.

Subsequent phases can be set to begin at:

• a specific percentage of the prior phase’s duration
• a specified number of months into the prior phase
• a specific date.

How can I change the Basic Unit of Work in the Quick Estimate Wizard? Currently it is set to SLOC, but we use Function Points.  I have changed the Basic Work Unit in the Global Options, but when I go into the Quick Estimate Wizard, the size estimate is still in SLOC.

What you need to change is not the Basic Work Unit, but the Function Unit.  To change the Function Unit to Function Points, select Tools | Customize Project Environment from the menu. On the Project Description Tab, there is a Function Unit list box.  Select Function Points, then enter an appropriate gearing factor to represent the average number of Basic Work Units contained in your selected  size unit (ex.: a gearing factor of 250 might represent 250 Basic Work Units per Object).  

If you need help determining an appropriate gearing factor, visit the Function Point Gearing Factors pageon the QSM web site, download our gearing factors whitepaper, or contact QSM for assistance.

I sometimes get poor defect curve fits when running a forecast.  What can I do to improve this?

Getting a good curve fit is important - the poorer the fit, the less confidence you will have in the projected new time for that set of data. The goodness of fit is particularly important during the latter stages of Phase 3 because defect data is weighted more heavily at that time. There are two things you can do to improve your defect curve fits:

1.  Assess the reliability of early data points carefully. If you have little confidence in the earliest defect data, you should throw it out. Our theoretical defect data curve algorithm assumes defects are being captured from the start of Phase 3 in a consistent and systematic manner. In practice, however, systematic logging of defects is often not performed until around Systems Integration Test (71% of phase 3 duration). If your early defect data is very erratic, chances are those data points are unreliable. If you know (or suspect) this to be the case, exclude the unreliable data points from curve fitting and forecasting. Unreliable data introduces random noise into SLIM-Control's calculations and creates unreliable forecasts.

2.  Try to determine the best tuning factor for your defect data. This is fairly easy to do once any early noisy data points have been discarded. There are two ways to get a handle on the defect tuning factor.  You can use either one, or combine the two methods:

• The first method uses past projects to generate a historic defect tuning factor. You can use any similar projects captured in SLIM-DataManager. Individual defect tuning factors for each project can be displayed on DataManager’s Project List View by selecting Tools | Customize View Layout from the menu. To get the average Defect Tuning Factor for one or more completed projects, import them into SLIM-Control using the History | Load Projects menu item and then run the Defect Tuning Calculator.  If you plan on using an average DTF from your history, you may wish to inspect the data and eliminate outliers to prevent distortion of the average.
• Once you have entered at least three actual total defect data points into SLIM-Control the Defect Tuning Calculator can also calculate a defect tuning factor from your actual defect data.

Once the expected defect total has been tuned to your history or actual data, you should see an improvement in your defect curve fits. If you’re tracking Defects Found by Category, here's one final step that will help ensure optimal curve fits:

• Tune the % of total defects for each category using your actual data. For more information on how to do this, see the FAQ entitled, "How Do I Tune My Defect Category Percentages?".

If you are still getting poor data fits after performing the steps outlined above, either try to determine the reasons or simply exclude defect data from the forecast curve fit.

I’d like my MTTD forecasts to reflect the number of test hours for each reporting period. How do I do this in SLIM-Control?

The Weighted MTTD option allows you to account for the actual hours spent testing each reporting period. Often the number of test hours fluctuates from month to month, causing large swings or "find and fix cycles" as test effort is directed to finding defects one period, then drops off as effort goes into fixing newly discovered defects during the next period. Using the Weighted MTTD option will smooth out these "find and fix" cycles, giving you a smoother defect curve.  Be sure to click the box at the top of the Metric Definitions dialog box in order to display both active and inactive metrics.

To use the Weighted MTTD metric, you must activate it by choosing Tools | Customize Metric Definitions from the menu. Locate the active defect metrics folder (Hint: the folder title will be bolded). If you don't see the metric, make sure you are displaying all active and inactive metrics. Scroll down and select the Weighted MTTD metric, then click the Edit Metric button:

Activate the metric by checking the “Active” checkbox and click OK to exit.

Next, activate the QSM Test folder. Note the lack of bold type – this category is inactive by default. Select the folder title and activate the category using the Edit Category button:

Click OK to save your changes and exit the Metrics Definitions dialogs.

The number of testing hours per reporting period should now appear on the Metrics tab of the Actual Data screen (select Control | Actual Data from the menu). As with all custom metrics, the testing hours field is appended to the list of standard metrics so you will need to scroll down to the bottom of the metric list to see the Test Hours field. This is where you will enter the actual hours spent testing for each reporting period.

Inside your Tools80 application directory are a series of sub-folders containing sample files, templates and product documentation. If you accepted the default installation location during setup, you'll find pdf copies of the User Manuals in C:\Program Files\QSM\Tools80\Doc.

You can find your activation code in either of the following places:

* If you are upgrading from a prior version of SLIM Suite 8.0, there should be a readme.txt file in your Tools80 directory. The default path for this directory is c:/Program Files/QSM/Tools80, but you can also find it by right clicking any SLIM 80 application shortcut and looking at the shortcut properties.
* Your activation code is also in the original shipping email you received at the beginning of your license period

If you need assistance, please contact your software administrator or email QSM support.

Download the 8.0 installation manual.

This deployment whitepaper discusses common questions asked by SLIM-Suite users. If you have additional questions or would like to discuss your deployment options in greater detail, please don't hesitate to contact QSM support!

A checksum error occurs when the values you entered for company name and location don't match the values expected by the setup program. Check to make sure your entries match the information provided in your license email. For example, if your license email has "Dave's Software Emporium" and you type in "Daves Software Emporium", setup will detect the mismatch (no apostrophe in "Daves")and return a checksum error. If you pasted license information from your license email, check to make sure you didn't inadvertently capture/paste any leading or trailing spaces. If you require assistance, email us or call QSM support (301 865-8242).

 
No. Once you have upgraded the server copy of SLIM-Suite, all users will be automatically upgraded. No action is needed on your part.

List of features and fixes for version 8.0g2.
List of features and fixes 8.0a-g.

Workbooks created in earlier versions of SLIM-Suite must be upgraded before they can be viewed or edited in version 8.0. Upgraded workbooks will no longer be compatible with earlier versions of SLIM-Suite, however. Workbooks are forward, but not backward compatible.

Yes - each application installs to its own folder and has its own set of registry entries and support files.

Here's how to locate your SLIM license information:

• If the applications are already installed:
  • Simply launch any SLIM application and look at the right side of the splash screen, or
  • With the application open, select Help | About SLIM... from the menu to access the splash screen.

• If your license has expired or the application has not been installed yet, try the following:
  •  If the application is installed on your computer, simply browse to the directory where it is installed (Usually C:\Program Files\QSM\Toolsnn, where “nn” is the current version of SLIM-Suite). To determine the path to the application directory, right-click on the application shortcut and select the "properties" tab. Locate the readme.txt file located in your Toolsnn folder. Open this file in Notepad or any other text editor - it contains your license information.
  • If the applications have not yet been installed, contact the software administrator for your company and ask for a copy of your license email.
  • If you need help locating your software administrator or license email (or if you have questions) call QSM at 800 424-6755 for assistance.

This FAQ affects only users who are uninstalling SLIM tools from a machine with another version of SLIM Suite applications installed. 

If you choose to uninstall SLIM tools, you may be asked whether you want to uninstall the DAO dll's. On some systems, the message box may state that the DAO dll's are not being used by any other application. This is not correct: the DAO files are required by all SLIM-Suite tools.

If you need to uninstall one version of the suite, do NOT uninstall the DAO dll's. Uninstalling these files will prevent your other SLIM Suite tools from running, and you will have to reinstall the SLIM Suite to restore the missing DAO files.

Where can I get the exercise files used in SLIM Suite Training? I would like to rework the training problems to refresh my memory before I begin using SLIM tools.

The SLIM Suite Training Pack is installed with SLIM-Suite. It contains the SLIM-Suite workbooks used in our training classes. To access the training workbooks, browse to the QSM directory (c:/Program Files/QSM/ by default) and look for the “Toolsnn” folder where “nn” represents the current version of SLIM suite. If you installed the Training files during setup, you should see Training folder that contains the training exercises.

To install and run the SLIM Tool Suite, you will need:

• Microsoft Windows XP, Vista, Windows 7, or later. 

• 200-800 MB hard disk space, depending upon which applications are installed. As SLIM Suite applications require additional disk space to store and work with your files, we recommend keeping at least 100 MB free space on your hard disk at all times

• A machine that meets Microsoft's recommended requirements for your operating system. Windows 7 users who plan to run SLIM-Suite in XP compatibility mode should have an addition 1 GB RAM and 15 GB of hard disk space.  Having more memory than the minimum required will result in better performance.

• A monitor capable of displaying at least 1024 x 768 with 256 colors and 96 dpi fonts (default small fonts).

What are the latest versions of the SLIM Tool Suite?

Information on the latest version of SLIM-Suite (along with download links, release notes, and installation FAQs) can be found on the Downloads page of the QSM website. To see whether you're running the latest version, select Help | Check for updates from the menu of any SLIM-Suite application.

Today I tried to open a SLIM-Suite file on the network and got an error message that said the file stamp was wrong and the workbook could not be opened. What's going on?

That message appears whenever you try to open a workbook created in a later version of SLIM-Suite with an earlier version of the applications. For example, you tried to open a workbook created in 8.0d with an earlier version of SLIM-Suite like 7.0 or 8.0 a, b or c.

SLIM-Suite workbooks are forward compatible: in other words, you can open and upgrade files created with earlier versions of SLIM-Suite. But they are not backward compatible (older versions of SLIM-Suite cannot open or read files created with a newer version of the applications). 

To open your workbook, you should either upgrade your machine to the latest version of SLIM-Suite or open the file on a machine with the latest version installed. To download the latest version of SLIM-Suite, visit our upgrades page. You’ll need your license email or the readme.txt file in your Tools80 directory to access the license registration and activation codes. The Upgrades page contains instructions for the upgrade as well as an Installation FAQs page that addresses common questions associated with installing or upgrading SLIM-Suite products.

You can also check for updates right from the Help menu. If you still have questions or need help, just contact QSM support for assistance!

To install and run the SLIM Tool Suite, you will need:

• Microsoft Windows XP, Vista, Windows 7, or later. 

• 200-800 MB hard disk space, depending upon which applications are installed. As SLIM Suite applications require additional disk space to store and work with your files, we recommend keeping at least 100 MB free space on your hard disk at all times

• A machine that meets Microsoft's recommended requirements for your operating system. Windows 7 users who plan to run SLIM-Suite in XP compatibility mode should have an addition 1 GB RAM and 15 GB of hard disk space.  Having more memory than the minimum required will result in better performance.

• A monitor capable of displaying at least 1024 x 768 with 256 colors and 96 dpi fonts (default small fonts).

What are the latest versions of the SLIM Tool Suite?

Information on the latest version of SLIM-Suite (along with download links, release notes, and installation FAQs) can be found on the Downloads page of the QSM website. To see whether you're running the latest version, select Help | Check for updates from the menu of any SLIM-Suite application.

What's the best way to get SLIM-Suite reports and graphs into other applications?

I created custom trends in SLIM Metrics, but I can't get them to work in SLIM-Estimate. What am I doing wrong?

Chances are your workbook has missing reference data or is pointing to the wrong set of trends. 

• If you're using Version 8.0a or later: 
  
  
  • Make sure you have created reference data for PI vs. Effective Size. Reference data for this metric pair must be present in order to perform the PI calculation. If it is missing, the “Calculate a PI from currently selected trend lines” option will be grayed out.
  • Make sure the default reference group in your SLIM-Estimate file matches the reference group you created in SLIM-Metrics. If it points to another reference group or to "None", your custom data will not be used. To select your custom reference data, select Tools | Customize Project Environment from the menu and select your trend from the Primary Trend Group combo box.
    
    
    
    When you click OK, two things will occur. First, that reference group will be the default shown on all new charts and reports created in your workbook. Any charts or reports which are already present will not be affected unless the trend line shown is set to Automatic, but you can easily change this by right-clicking on any chart and adjusting the chart properties.
    
    Secondly, the default PI dialogs will now offer you a choice between the default QSM PI and the reference group or trend mix you chose on the Project Environment dialog. 
    
    
    
    You can use this new set of trends for the default PI on the PI Calculator (via the Solution Assumptions dialog), Quick Estimate Wizard, and Level of Effort Wizard when generating new estimates.
    
    
• If you're using Version 7.0 or earlier: 
  
  
  • Select Edit | Workbook Options | Reference Data from the menu. Make sure the Manual radio button is selected and your custom reference trends appear in the Manual combo box. 
  • Check your custom reference trends in SLIM-Metrics. They should include the following reference trends:
    • Average Staff vs. Effective Size
    • Phase 3 Effort (MM) vs. Effective Size
    • Phase 3 Duration (months) vs. Effective Size

I increased the PI on one of my estimates from 14.6 to 20.3. When I ran the optimized solution, I got an error message that said the new solution was out of bounds. What went wrong?

If you increase the PI while keeping the MBI (Manpower Buildup Index) the same, you are telling SLIM to keep applying manpower at the same rate in spite of the dramatically higher productivity of 20.3. But if a project operating at a much higher level of productivity does not need as many people as a project team with very low productivity.

At a PI of 20.3,  the calculated peak staff level falls to only .5 (half a Full-Time Equivalent person). This value is below the reasonable effort range, so SLIM generates the following error:

"Your calculated solution is below SLIM's minimum peak staff of .5 people. Your solution will be reset to the last valid solution".

After increasing the PI, you should allow SLIM to calculate a manpower buildup rate that matches the increase in productivity. At the bottom of the Solution Assumptions screen, you can choose between the current MBI and a QSM default MBI.

Selecting the Unconstrained (QSM Default Solution) solution method will provide a more reasonable bui effort buildup consistent with your new PI. 

When I change the Person Hours per Person Month field in Accounting Options, there is no change to the total schedule and effort for the project.  How can I adjust the estimate to reflect overtime?

The person hours/person month field was never intended to be used for performing time/effort tradeoffs.  For estimating purposes, SLIM-Estimate assumes that a FTE person is a FTE person, regardless of the number of hours in an effort month.  To account for overtime or unusual staffing situations, you should adjust the FTE (full-time equivalent) peak staffing level.  

For example, to reflect 10% overtime, you need a peak staff that is 1.1 times the current peak.  You can do this using the Control Panel peak staffing dial or by extending or shortening the Phase 3 schedule.

NOTE: if you are using a PI from your completed projects, you should only make this type of adjustment if your history does not include overtime.  It is usually better to be conservative in making adjustments as overtime hours are often less productive.  If the completed projects you used to derive a PI had a similar amount of overtime, it is already reflected in the PI and no adjustment is needed.  

Sometimes the effort data points on my Life Cycle Sensitivity to PI graph have values that do not always increase (or decrease); e.g., there are small dips in the data.

Remember that the time and effort shown on these graphs are life cycle values. The most likely cause of slight variations in the expected behavior of the data is caused by variation in the effort for phase 4. Staffing projections for phase 4 are dependent on the staffing rate at the end of phase 3. Therefore, differences in the final phase 3 staffing rate can result in variations in the total effort for phase 4. You can check to see if this is the case by making the solutions in question the current solution, then comparing the phase 4 effort in the solution panel of the staffing view.

When I change the Person Hours per Person Month field on the Accounting tab of the Solution Assumptions dialog, there is no change to the total schedule and effort for the project. Why is this?

Many SLIM-Estimate and SLIM-Control users have asked why their overall schedule does not change when they change the value of the "Person Hours per Person Month" field,  Solution Assumptions screen, Accounting Tab.

The number of Person Hours comprising a particular organization's Person Month is not used to calculate total effort.  If your chosen effort unit is Person Months, the hours per month setting is not used at all. If, on the other hand, your effort unit is weeks, days, or hours, your hours per month will be used to convert the estimated total effort (in Person Months) into your chosen effort unit.

At first, this may seem counter-intuitive. Shouldn't an increase or decrease in the number of Person Hours in a Person Month be reflected in the final estimate?

The number of staff hours in an organization's staffing month is more relevant in the accounting world than it is in software estimation. It attempts to account for items such as vacations, meetings, and administrative activities but in most cases, it is merely an estimate or average.  It may tell how many hours will be charged to a particular project, but has nothing to say about how much is actually accomplished during those hours (or even how many actual hours were worked). The productivity index, or PI, is where actual work produced is measured.

The Productivity Index, or PI, reflects a number of environmental factors such as:

If you are using a PI calculated from your past projects, your user-specified PI already reflects the conditions in your working environment. Holding other factors constant, organizations which have high "administrative overhead" will tend to have a lower calculated productivity index than organizations which maximize time spent working on the most productive project tasks.

SLIM-Estimate® is a macro model based on the software equation described in Measures for Excellence. The SLIM software equation is designed to estimate consistently across a broad spectrum of working environments and accounting standards. For this reason, the effort parameter was originally calculated in Person Years, which are converted to Person Months in SLIM-Estimate. Once the total effort in PM has been determined, it can be converted into your chosen effort unit for display on charts and reports.  But what if you have no historical data and are using the PI suggested by the QSM database? SLIM® estimating and project control tools will still give you a good first estimate that you can continue to refine as more project data becomes available. As projects are completed, SLIM® tools will calculate the project PI's from your historical data. These PI's can be used to calibrate new estimates to the unique conditions in your development environment.

As you begin to compare and analyze PI's from completed projects, you can spot and eliminate bottlenecks as well as identify successful strategies that you can repeat to improve productivity. Storing project metrics in a useful and accessible form and analyzing them to identify trends is the key to process and productivity improvement. Consistent use of SLIM® tools results in increasingly accurate estimates and will help you build a repository of historical data for future analysis and benchmarking.

Though we have thousands of Function Point projects (over 4,000 at last count!)  in our database, several factors limit the number of projects judged suitable for inclusion in our Function Point Gearing Factors table.

Here's a partial list of the most important inclusion criteria:

• Recently completed
• Rated Medium to High Confidence
• Similar application complexity. While FP are sometimes used to size real time and engineering class projects, our table uses only IT project to ensure apples to apples comparisons. 
• Written in a single language. Why is this a problem? These days, the vast majority of projects submitted our database use more than one language. We wouldn't want to represent a project with only 20% Java as "a Java project" because any gearing factor derived from such a project would not be accurate for estimating projects developed solely or predominantly in Java.
• Not drawn from our own table!
• No extreme values or outliers.

It would be wonderful to be able to classify projects by language version as well as language but even if we had all the information we needed, the resulting samples would probably be too small to be relied upon. 

There are many possible explanations for observed variability in gearing factors (imprecision in counting being not the least of them). But perhaps the more important point is that our table is based on real data, and even where we do have language version information, we haven’t seen sufficient evidence to conclude that language gearing factors change radically from release to release. The differences we've observed seem to be within the range of normal variation.

Without strong empirical evidence, we're reluctant to draw conclusions about the influence of new releases of IDEs (integrated development environments) or language versions on function point gearing factors. 

QSM began building its database of completed software projects in 1978. Since that time, we have collected project data continuously, updating the database every 12 to 18 months. Our primary source of industry data is QSM tool clients, some of whom choose to contribute their completed project data to the database. This is a great way for our clients to ensure that their industries, development methods, and technologies are represented in our industry trends. We also collect data by permission through our ongoing consulting practice in the areas of productivity assessments, estimates, and cost-to-completes. 

Over the past three decades QSM has analyzed software developments from North America, Europe, Asia, Australia, and Africa. Our projects span a wide variety of size regimes, application domains, industries and development methodologies. Before it is added to the database, all incoming project data is carefully examined for accuracy and completeness. After inspection and validation, approximately 10,000 projects have been integrated into the QSM database.

Trust is the foundation of the partnership between QSM and the clients who rely on our tools and services: trust that QSM will guard the confidentiality and identity of the clients who contribute project data; trust in the integrity of our industry data. For over three decades, our goal has been to create longstanding partnerships with our clients. For this reason, we treat all contributed data as confidential.

QSM does not release project data directly to our customers. To protect the confidentiality of our client contributors, we use industry trend lines (calculated from the most recent 2-3 years of data) for comparison and analysis. Due to the enormous variability in schedule, effort, and defects at any given size, the data is broken down into nine application categories:

Stratifying the data by application type reduces the variability at each size range and allows for a more accurate curve fit.

QSM clients can access the QSM database in several ways:

• Current industry trend lines for each of the nine application types are included with QSM tools.
• Basic Custom queries on the QSM database are included with your license. Let us do the research to answer your estimating and benchmarking questions. We can provide graphs and summaries that allow you to compare your projects against both industry trend lines and actual projects that are similar in size, application type, and complexity. Note: more extensive query analysis is available through QSM's Basic Measurement Service.
• QSM's Basic Measurement Service can help you assess your current position against your competitors by cost, cycle time, and quality. Based on your present productivity and quality, we can help you set realistic goals for process improvement.
• Research papers and articles from our database analysis are available for download on the Resources page. Five Core Metrics, Measures for Excellence and Industrial Strength Software by Lawrence H. Putnam and Ware Myers outline the theory and research behind QSM's three decades of software estimation, tracking, and benchmarking. And don't forget to check out the QSM IT Almanac, Function Point Table, Performance Benchmark Tables, and blog!

Though we have thousands of Function Point projects (over 4,000 at last count!)  in our database, several factors limit the number of projects judged suitable for inclusion in our Function Point Gearing Factors table.

Here's a partial list of the most important inclusion criteria:

• Recently completed
• Rated Medium to High Confidence
• Similar application complexity. While FP are sometimes used to size real time and engineering class projects, our table uses only IT project to ensure apples to apples comparisons. 
• Written in a single language. Why is this a problem? These days, the vast majority of projects submitted our database use more than one language. We wouldn't want to represent a project with only 20% Java as "a Java project" because any gearing factor derived from such a project would not be accurate for estimating projects developed solely or predominantly in Java.
• Not drawn from our own table!
• No extreme values or outliers.

It would be wonderful to be able to classify projects by language version as well as language but even if we had all the information we needed, the resulting samples would probably be too small to be relied upon. 

There are many possible explanations for observed variability in gearing factors (imprecision in counting being not the least of them). But perhaps the more important point is that our table is based on real data, and even where we do have language version information, we haven’t seen sufficient evidence to conclude that language gearing factors change radically from release to release. The differences we've observed seem to be within the range of normal variation.

Without strong empirical evidence, we're reluctant to draw conclusions about the influence of new releases of IDEs (integrated development environments) or language versions on function point gearing factors. 

I need a gearing factor for a language not listed on the Function Point Languages Table.  Is this information available from QSM?  What are my options if QSM does not have this information?

Although the Function Point Languages Table is fairly extensive, we do not always have enough information to provide gearing factors for every language. Before we can use a completed project in our Gearing Factors table, certain conditions must be satisified:

1.  The project must be sized in function points.  Although thousands of projects in our database are sized in function points, we are starting with a subset of a subset of the database.
2. The project must be recent.  Because coding techniques and languages change over time, we would not want to include projects that were 20 years old.
3. The project must be developed in a single language or the requested language must comprise at least 80 to 90% of the project.  These days, however, it’s not uncommon for projects to be developed with a mix of technologies and languages. A project that contains only 20% Oracle  should not be used to determine an Oracle gearing factor.
4. There should be a decent sample size.  A large sample size gives more reliable and realistic gearing factor information than a very small sample size.

Given these constraints, if you do not see a language listed in the Function Point Languages Table,  consider using the higher level language as a starting point and adjust your risk.  For example, if you were searching for an APEX (Oracle) gearing factor but did not see that language listed in the table, you can start with the gearing factor for Oracle (or another similar language) and adjust the uncertainty on size to build an appropriate amount of risk buffer into your estimate.

If you would like to know if QSM has any information about a specific language’s gearing factor, please e-mail QSM support.

How can I change the Basic Unit of Work in the Quick Estimate Wizard? Currently it is set to SLOC, but we use Function Points.  I have changed the Basic Work Unit in the Global Options, but when I go into the Quick Estimate Wizard, the size estimate is still in SLOC.

What you need to change is not the Basic Work Unit, but the Function Unit.  To change the Function Unit to Function Points, select Tools | Customize Project Environment from the menu. On the Project Description Tab, there is a Function Unit list box.  Select Function Points, then enter an appropriate gearing factor to represent the average number of Basic Work Units contained in your selected  size unit (ex.: a gearing factor of 250 might represent 250 Basic Work Units per Object).  

If you need help determining an appropriate gearing factor, visit the Function Point Gearing Factors pageon the QSM web site, download our gearing factors whitepaper, or contact QSM for assistance.

What options are available for sizing projects in SLIM-Estimate?

The Size Calculator offers a variety of sizing techniques that may be used individually or in combination. One technique is GUI Sizing, which allows you to break the system down into individual components such as screens, reports, dialogs, or your custom components, each of which can have its own gearing factor (LOC/component). The individual component estimates are rolled up into a total size estimate, which will be posted back to the Assumptions screen.

• Sizing by History

Sizing by History is useful early in the software planning cycle when the requirements may still be vague and the design not clearly defined. The technique combines historical size data from the QSM database or your custom trends with your intuition and experience to produce a rough order-of-magnitude size estimate for the proposed system. You are strongly encouraged to review this preliminary size estimate as more information becomes available.

• Total System Mapping

This technique breaks the entire system down into a single functional component of your choice (such as objects, subsystems, etc.) then provides a size estimate based on the expected number of components the system will contain.

• Sizing by Decomposition

Whereas Total System Mapping sizes the system using a single overall sizing unit, Sizing by Decomposition breaks your system down into different groups of components. Each type of component uses its own mapping factor to convert the component estimate into your chosen function unit. The results for each component are then rolled up into a total expected system size. Although Sizing by Decomposition was originally developed for use with GUI languages, it is a very versatile technique that can be used anytime you want to size parts of the system using different sizing components.

• Sizing by Module

This sizing technique decomposes the system into modules (or programs or subsystems). Estimates here should be made in the function unit specified on the Project Environment dialog. While the screen layout for this function is almost identical to that of Sizing by Decomposition, the two techniques are used for different purposes.

Sizing by Module breaks the system into single, like components of different sizes. Each single component has its own mapping factor that converts the total expected size back to your chosen function unit. Sizing by Decomposition, on the other hand, allows you to break down the system into several different groups of like components. Each group has the same mapping factor, which is used to convert each component to your selected function unit.

• Function Point Sizing

Function Point Sizing is an alternative to estimating source lines of code. It attempts to measure the functionality the software will provide. The methodology is based on a weighted sum of the inputs, outputs, files, inquiries, and interfaces provided to or generated by the software.

• Microsoft Excel Sizing by Spreadsheet

In addition to the five sizing techniques just described, you can design your own custom sizing techniques using Microsoft Excel. Several Excel sizing template files (.xlt or .xltx file extension) are installed to the \Tools80\Templates folder when SLIM-Estimate is installed. You can use one of the QSM templates or create your own sizing spreadsheets and import the results into SLIM-Estimate.

What is the purpose of the gearing factor?

Gearing factors are used to convert projects with many different sizing units (objects, modules, or use cases for example) back to a common sizing unit: the Basic Work Unit. The Basic Work Unit represents the smallest sizing unit that is common to all projects.

This conversion is important for two reasons. First, it allows us to apply the same family of PIs (or Productivity Indices) to all projects. Second, it allows you to compare your project, whether it is sized in tables, screens, or any other sizing unit, to QSM’s industry – or your own custom - trend lines, which can be sized in a variety of size units.

In our research, we have found a strong correlation between system size and important metrics like PI, schedule, effort, and defects. For more information on gearing factors, download our free whitepaper.

Can I use the forecast function to explore various staffing options?

When you run a forecast, SLIM-Control bases the future staffing profile on the peak staff and staffing shape defined in the current plan.

While Phase 3 is ongoing, run a tradeoff forecast to see the impact of increasing or decreasing staff and apply any resulting schedule tradeoff to your existing forecast.  To run a tradeoff forecast, select Control | Tradeoff Forecast… from the menu.

Once Phase 3 has completed, use the maintenance forecast to evaluate staff tradeoffs.  The maintenance forecast can only be performed during Phase 4.  To run a maintenance forecast, select Control | Run Forecast… from the menu.

Why don't my staffing rate numbers add up to the same total shown on cumulative effort charts and reports?

First, it is important to understand the difference between the average staffing rate and cumulative effort charts and reports.

Average Staffing Rate charts and reports display the number of FTE staff used by the project during any given month, regardless of how much of the month is covered by that phase. When a phase starts or ends mid-month, the staffing rate for that month is not affected.  

Cumulative Effort charts and reports display the total effort for each month.   So here, when a phase starts or ends mid-month, the total effort reflects those partial months.

To see this more clearly, let's look at an example.  If there 10 people work during December (and the phase begins on December 31st), then the Staffing Rate chart and report will show 10 people for December; but the Cumulative Effort for that month would only be .33 mm (10 people x .033 months). This logic holds true for other rate values like defects and cost.

A second factor that may cause discrepancies between cumulative effort or cost and the sum of the monthly effort/cost rates is really a calculus issue.  Staffing numbers represent the average manpower rate for a given time period. These numbers are typically taken at mid-month. 

For graphing purposes, it is more practical to break up the smooth theoretical curve used to derive cumulative effort/cost into slices (like bars in a histogram) where the top of each bar corresponds to the average staffing rate for each month. Because each bar has a flat top, each month a small amount of error is introduced as there will always be a small area under the curve that is not covered by the bars.

As we add more and more months (bars) to the staffing chart, the bars become narrower and narrower and the amount of error decreases. If the intervals are small enough, the sum of the rates should be very close to the cumulative effort. However, when the intervals are large (for instance, monthly for a 3-month project), the approximation will not be as close. 

The Solution Panel says my peak staff value is 10.3, but the Average Staffing Rate charts and reports show a peak staff of 10.1. What is causing this inconsistency?

The theoretical Rayleigh curve used to derive the values on the Solution Panel is a smooth curve resulting in different staffing numbers at each point along the x-axis. In drawing the Average Staffing chart, this smooth theoretical curve is approximated by a series of discrete staffing rates (with one bar, or average staffing rate value, per month).

The graph and solution panel values won't always match exactly because the graphical peak staff is always taken mid-month for any internal month while the solution panel always shows the highest peak staff point on the staffing curve (regardless of when it occurs). Usually the theoretical curve does not peak exactly at mid-month, so the true peak shown on the solution panel will not match the one on the average staffing charts unless the theoretical peak happens to fall at mid-month.

On large projects where a longer schedule allows a natural smoothing of the staffing curve, the theoretical peak staff will usually be close to the average staff rate value. On shorter projects, you can expect to see larger discrepancies.

When I change the Person Hours per Person Month field in Accounting Options, there is no change to the total schedule and effort for the project.  How can I adjust the estimate to reflect overtime?

The person hours/person month field was never intended to be used for performing time/effort tradeoffs.  For estimating purposes, SLIM-Estimate assumes that a FTE person is a FTE person, regardless of the number of hours in an effort month.  To account for overtime or unusual staffing situations, you should adjust the FTE (full-time equivalent) peak staffing level.  

For example, to reflect 10% overtime, you need a peak staff that is 1.1 times the current peak.  You can do this using the Control Panel peak staffing dial or by extending or shortening the Phase 3 schedule.

NOTE: if you are using a PI from your completed projects, you should only make this type of adjustment if your history does not include overtime.  It is usually better to be conservative in making adjustments as overtime hours are often less productive.  If the completed projects you used to derive a PI had a similar amount of overtime, it is already reflected in the PI and no adjustment is needed.  

I have an estimate with one very short phase. When I view the Staffing Profile in aggregate mode, the staffing for the final month of that phase does not appear to dip down as it does when I view the individual phases. Why not?

The aggregate staffing chart shows the maximum FTE (full-time equivalent) staff rate during any given month.  For months where two phases overlap, the staffing values for both phases are combined to get the total staffing for that month.  

What is the impact of selecting various phase staffing shapes? When should I deviate from the default Rayleigh pattern, and how is my estimate affected?

We have found that the default Rayleigh pattern is the staffing pattern that best matches the application of effort to the work to be performed but due to staffing constraints or different software management styles, you may decide that another staffing pattern fits your organization or project better.

In general, the various staffing shapes can be described as follows: 

• Front Load Rayleigh peaks at approximately 40% the phase 
• Medium Front Load Rayleigh peaks midway through the phase 
• Medium Rear Load Rayleigh peaks at approximately 75% of the phase 
• Rear Load Rayleigh (Phase 3 only) peaks at the end of the phase 
• Level Load maintains a constant staffing level over the entire phase
• Exponential (Phase 4 only) gives the most rapid drop off of staffing from the end of Phase 3.
• Stair Step (Phase 4 only) begins at about half of the staffing level from the end of Phase 3 and stair steps down.
• Straight Line: (Phase 4 only) represents a straight-line decrease in staffing from the end of Phase 3.
• Rayleigh (Phase 4 only) is a natural tailing off/continuation of any Phase 3 Rayleigh curve. Not valid if the selected Phase 3 staffing shape is Level Load. 

Level loading is generally seen in the development of very small systems. In larger systems, early application of people often represents wasted effort. The Default Rayleigh shape determines the staffing shape based on the size of the application. QSM has found that small projects (less than 18,000 lines of code) tend to have a Front Load Rayleigh profile while larger systems (greater than 100,000 lines of code) typically reach peak staffing towards the end of phase 3. For very small systems (3 to 6 months in duration with a peak staff of 1-3 persons), a level load profile is more appropriate.

The estimated total effort for each of the staffing patterns for the first three phases will remain constant regardless of the pattern selected. Phase 4 effort will vary, depending on the shape of phase 3. This is because in phase 4, manpower tails off from the final Phase 3 staffing level and is therefore a function of the number of people on board at the end of phase 3 and the length of phase 4. Projects that peak at the end of Phase 3 will have higher phase 4 effort. Projects that peak earlier will have lower phase 4 effort.

If you are using default QSM overlaps for the phases, you can expect to see some differences in the phase overlap when you change the staffing pattern. This occurs because SLIM attempts to produce the smoothest aggregate staffing pattern when moving from one phase to the next.

For example, the overlap percentage between Phases 2 and 3 will be 0% if Phase 3 is Level Loaded. Otherwise the overlap ratio will range from  33% to 40% as the phase 2 staffing shape changes from Front Load Rayleigh to Medium Front Load Rayleigh.

What's the best way to get SLIM-Suite reports and graphs into other applications?

There's a good fit between my total defect data and the plan but in the defects by category charts, the defect actuals for each category aren't tracking the plan very well. How can I fix this?

Chances are your defect category percentages need to be adjusted. To tune these percentages using your actual data, create a Multi-Metric Time Series Chart and insert a QSM Tracked Defects Category Total (Actual) metric for each defect category you're tracking:

Next, right click on your chart to access the chart property tabs. On the Data tab, select "Percent of first metric's data points" and click OK to exit the dialog.

Next, toggle your Multi-Metric chart into report form:

If the weekly or monthly values seem fairly consistent, you can simply use the latest % of total for each category. If you see a lot of variation, you may want to average the values - don't be afraid to experiment until you get the best visual fit! Enter the % for each category on the Reliability tab of the Project Environment dialog:

Once you return to the defects by category views, you should see a better fit between the plan and actuals.

The planned MTTD value shown on my graph for the final month of phase 3 is not the same as the value reported in the Project Profile report and the consistency report for my Phase 3 MTTD. It appears to be slightly higher in the reports.  Why?

The value displayed on graphs is the average MTTD rate for the final month of phase 3, but the MTTD value reported in the reports represents the planned MTTD at the end of phase 3. You should expect this value to be somewhat higher than the average value for the entire month, because the theoretical MTTD is always improving (getting larger) as time progresses.

Sometimes, one or more of the menu items in SLIM-Control are grayed out and I'm not sure why.

Grayed out menu options generally denote features that will not become available until some condition has been satisfied. Here are some of the most common reasons a menu option may be unavailable:

1.     You're trying to edit a QSM Default custom metric or control bound. Since QSM default custom metrics and control bound definitions cannot be edited, the options for these metrics are grayed out. You can, however,  copy a QSM default metric or control bound definition and edit the copy.

2.     You're trying to enter actual data for a metric that has not started yet or is complete. Before you can enter actual data for a metric, you must first enter an actual start date for that metric. Likewise, once you've entered an actual end date for a metric, you will no longer be able to enter actual data for that metric. 

3.     You're trying to set a start or end date for a metric that is tied to a phase:  Start and end date fields for planned staffing/effort are disabled because staffing and effort data is always tied to a specific phase. For example, phase 2 effort begins on the first day of phase 2 and ends on the last day of phase 2. Start/end dates for each phase are defined on the Phases tab of the Plan property sheet (Control | Plan Data). 

Start dates for Defect metrics are customizable, but defect end dates are disabled because they coincide with the end of the life cycle.

4.     You're trying to enter a start or end date for an inactive phase. On the Plan | Phases tab, planned start or end dates can only be entered for active phases. To view/edit the active phases for the project, select Tools | Customize Project Environment and select the Phases tab.

Where can I get the exercise files used in SLIM Suite Training? I would like to rework the training problems to refresh my memory before I begin using SLIM tools.

The SLIM Suite Training Pack is installed with SLIM-Suite. It contains the SLIM-Suite workbooks used in our training classes. To access the training workbooks, browse to the QSM directory (c:/Program Files/QSM/ by default) and look for the “Toolsnn” folder where “nn” represents the current version of SLIM suite. If you installed the Training files during setup, you should see Training folder that contains the training exercises.

How can I change the Basic Unit of Work in the Quick Estimate Wizard? Currently it is set to SLOC, but we use Function Points.  I have changed the Basic Work Unit in the Global Options, but when I go into the Quick Estimate Wizard, the size estimate is still in SLOC.

What you need to change is not the Basic Work Unit, but the Function Unit.  To change the Function Unit to Function Points, select Tools | Customize Project Environment from the menu. On the Project Description Tab, there is a Function Unit list box.  Select Function Points, then enter an appropriate gearing factor to represent the average number of Basic Work Units contained in your selected  size unit (ex.: a gearing factor of 250 might represent 250 Basic Work Units per Object).  

If you need help determining an appropriate gearing factor, visit the Function Point Gearing Factors pageon the QSM web site, download our gearing factors whitepaper, or contact QSM for assistance.

When I change the Person Hours per Person Month field in Accounting Options, there is no change to the total schedule and effort for the project.  How can I adjust the estimate to reflect overtime?

The person hours/person month field was never intended to be used for performing time/effort tradeoffs.  For estimating purposes, SLIM-Estimate assumes that a FTE person is a FTE person, regardless of the number of hours in an effort month.  To account for overtime or unusual staffing situations, you should adjust the FTE (full-time equivalent) peak staffing level.  

For example, to reflect 10% overtime, you need a peak staff that is 1.1 times the current peak.  You can do this using the Control Panel peak staffing dial or by extending or shortening the Phase 3 schedule.

NOTE: if you are using a PI from your completed projects, you should only make this type of adjustment if your history does not include overtime.  It is usually better to be conservative in making adjustments as overtime hours are often less productive.  If the completed projects you used to derive a PI had a similar amount of overtime, it is already reflected in the PI and no adjustment is needed.  

Sometimes the effort data points on my Life Cycle Sensitivity to PI graph have values that do not always increase (or decrease); e.g., there are small dips in the data.

Remember that the time and effort shown on these graphs are life cycle values. The most likely cause of slight variations in the expected behavior of the data is caused by variation in the effort for phase 4. Staffing projections for phase 4 are dependent on the staffing rate at the end of phase 3. Therefore, differences in the final phase 3 staffing rate can result in variations in the total effort for phase 4. You can check to see if this is the case by making the solutions in question the current solution, then comparing the phase 4 effort in the solution panel of the staffing view.

Sometimes the time data points on my Sensitivity graph are not in a straight line; sometimes 2 or 3 points may even have the same value.

Time values on sensitivity charts are rounded to the nearest day. For very small size increments, this rounding may result in 2 or 3 data points having the same value.

I set a Schedule constraint of 24 months. Why does the solution on the Staffing screen show a 22-month schedule?

There are several reasons this could be happening, but the most likely cause is that you entered a target probability of more than 50% for the Schedule constraint. For example, if you enter a time constraint of 24 months at a target probability of 90%, you are asking SLIM-Estimate to calculate a risk-buffered solution that provides a 90% probability that the project will not exceed 24 months: in effect, a risk-buffered solution.

The difference between the expected solution of 22 months and your constraint of 24 months represents the built-in risk buffer that protects you against possible size growth, lower than estimated productivity, staff availability issues, or other facts that may affect the delivery date. The size of this risk buffer is determined by the uncertainty range around the estimated size, PI, and manpower buildup.

If you want your solution to correspond exactly to your input constraint values, you should use desired probabilities of 50% for those constraints.

What is the impact of selecting various phase staffing shapes? When should I deviate from the default Rayleigh pattern, and how is my estimate affected?

We have found that the default Rayleigh pattern is the staffing pattern that best matches the application of effort to the work to be performed but due to staffing constraints or different software management styles, you may decide that another staffing pattern fits your organization or project better.

In general, the various staffing shapes can be described as follows: 

• Front Load Rayleigh peaks at approximately 40% the phase 
• Medium Front Load Rayleigh peaks midway through the phase 
• Medium Rear Load Rayleigh peaks at approximately 75% of the phase 
• Rear Load Rayleigh (Phase 3 only) peaks at the end of the phase 
• Level Load maintains a constant staffing level over the entire phase
• Exponential (Phase 4 only) gives the most rapid drop off of staffing from the end of Phase 3.
• Stair Step (Phase 4 only) begins at about half of the staffing level from the end of Phase 3 and stair steps down.
• Straight Line: (Phase 4 only) represents a straight-line decrease in staffing from the end of Phase 3.
• Rayleigh (Phase 4 only) is a natural tailing off/continuation of any Phase 3 Rayleigh curve. Not valid if the selected Phase 3 staffing shape is Level Load. 

Level loading is generally seen in the development of very small systems. In larger systems, early application of people often represents wasted effort. The Default Rayleigh shape determines the staffing shape based on the size of the application. QSM has found that small projects (less than 18,000 lines of code) tend to have a Front Load Rayleigh profile while larger systems (greater than 100,000 lines of code) typically reach peak staffing towards the end of phase 3. For very small systems (3 to 6 months in duration with a peak staff of 1-3 persons), a level load profile is more appropriate.

The estimated total effort for each of the staffing patterns for the first three phases will remain constant regardless of the pattern selected. Phase 4 effort will vary, depending on the shape of phase 3. This is because in phase 4, manpower tails off from the final Phase 3 staffing level and is therefore a function of the number of people on board at the end of phase 3 and the length of phase 4. Projects that peak at the end of Phase 3 will have higher phase 4 effort. Projects that peak earlier will have lower phase 4 effort.

If you are using default QSM overlaps for the phases, you can expect to see some differences in the phase overlap when you change the staffing pattern. This occurs because SLIM attempts to produce the smoothest aggregate staffing pattern when moving from one phase to the next.

For example, the overlap percentage between Phases 2 and 3 will be 0% if Phase 3 is Level Loaded. Otherwise the overlap ratio will range from  33% to 40% as the phase 2 staffing shape changes from Front Load Rayleigh to Medium Front Load Rayleigh.

Is there a limit on the number of projects that can be loaded into SLIM-MasterPlan?

There is no limit to the number of projects you can load into MasterPlan other than what is allowed by the graphics and memory capabilities of your PC. But if your MasterPlan workbook includes an unusually large number of projects it may be difficult to see all the projects clearly on graphs.

Here are some suggestions for MasterPlan files with a large number of projects:

• Place a single graph on each view to allow more room for MasterPlan to display the projects onscreen.
• Use the Level of Detail tab in Gantt Chart Properties to adjust the number of levels shown
• Group your projects by category, perhaps by division, year, budget, or program to make your MasterPlan estimates more meaningful
• Consider moving projects which are more similar to iterations to SLIM-Estimate as a Work Breakdown Structure (WBS)

In SLIM-Suite, some dialog boxes are too large for my screen.  What is the recommended screen resolution?

If you are running at a low screen resolution, certain dialog boxes may not fit within the screen display. 

The recommended screen resolution is 1024 x 768 with 256 colors and 96 dpi (default small fonts). For optimal graphics display when running SLIM tools, the screen resolution should be set to at least 800 by 600 for small fonts (or at a higher resolution if you are using large fonts). 

My graph titles are being truncated in SLIM-Suite. Is there a way to fix this so that I can keep my chart title?

If a chart title or chart axis label is too long to fit in the allotted space, SLIM-Suite applications will truncate the text instead of wrapping to the next line. This happens on all QSM charts. There are a few options in this case:

• Reduce the font size.
• Shorten the title by cutting out words or using abbreviations.
• Maximize the display window.
• If the appearance is acceptable on printouts, leave the title as is.

To reduce the font size, select Tools | Customize Display | Screen/Printer Fonts, Colors, & Symbols.  On the Element side of the dialog box, select the desired chart title or label and click the Select Font… button to reduce the font size.