SLIM - A Mathematical Model

SLIM - A Mathematical Model

With regression modeling, the stress is on constructing a formula that best represents scattered data points. In mathematical modeling, the stress is on matching the data to the form of an existing mathematical function. In the early 1960s, Peter V. Norden of IBM concluded that research and development projects exhibit well-defined and predictable staff loading patterns that fit the mathematical formula for a Rayleigh distribution (Box 1), as shown in Figure 1

The Rayleigh Staffing Curve

The Norden-Rayleigh Function 

Later, in the 1970s, Lawrence H. Putnam (Quality Software Management, QSM) applied Norden's observations to the software life cycle, validating the existence of an optimum staffing shape for a given project. He started with 50 U.S. Army projects and now has empirical evidence for several thousand. Based on statistical analysis of these projects (QSM has been collecting data on completed projects since 1975), Putnam found that the relationship among the three principal elements of software estimating - size, schedule, and effort - matched the Norden/Rayleigh function. As size goes up, so do effort, time, and defects, but in different types of relationships (exponential, logarithmic). He concluded that reducing size is one way to reduce schedule, effort, and number of defects. Size can be reduced a number of ways, including "requirements scrubbing" (eliminating "gold plating" or nonessential features), phased or incremental delivery, reuse, and commercial-off-the-shelf products.

Like Boehm, Putnam used scatter diagrams and curve-fitting techniques to find relationships in his observed data. After plotting the major trend line that represents all observed data points (size versus months), the mean was calculated (50% of the projects fell above the line and 50% of the projects fell below the line), along with values for +1 (only 16% of the data points fell above this line; 84% of the data points fell below this line) and for -1 (only 16% of the data points fell below this line; 84% of the data points fell above this line), as shown in Figure 2. If a project is estimated to fall above the +1 line, the indication is that it is not practical to build the product now - this has become known as the Impractical Zone. If a project is estimated to fall below -1, the indication is that it is not possible to build the product this fast (this has become known as the Impossible Zone, although many project managers have been known to forge ahead anyway).

Impractical & Impossible Zones

QSM's Software Lifecycle Management (SLIM) process consists of methodologies tied together with the decision-support tools, SLIM-Estimate, SLIM-Control, and SLIM-Metrics. SLIM-Estimate supports estimating and planning, SLIM-Control supports tracking and forecasting, and SLIM-Metrics supports data capture and analysis.

The software production relationship is explained in Box 2.

The QSM SPR Relationship

As with almost all sizing and estimating models, the estimating paradigm demonstrated by triangle ("Effort Measures" Figure (a)) or box ("Effort Measures" Figure (b)) applies. There are only so many degrees of freedom. If productivity goes up, the schedule is extended, or resources are added, the size is able to increase as well (the inverse relationship also holds true).

All sizing and estimating methods and processes encourage the collection of actual data. The benefit of using an automated tool is that most of them provide "starter sets" of data based on observed projects. SLIM is particularly helpful in this regard because data from more than 5,500 projects has been captured. Putnam's softwa    re equation links the size of the software to development time and overall effort. The equation was derived by linking two mathematical definitions of productivity: size/staff power and Putnam's formula relating productivity and difficulty (see Box 3).

The Putnam Equation

The technology constant, C, combines the effect of using tools, languages, methodology, quality assurance procedures, standards, and so on. It is determined on the basis of historical data (past projects). The values of the technology constant can vary from as little as 610 up to 57,314. C is determined from project size, area under effort curve, and project duration.   

Rating: C = 2,000 - poor, C = 8,000 - good, C = 11,000 - excellent

For instance, suppose that the technology constant, C, is estimated to be 4,000 (not great, but not poor) and size is estimated as 200,000 LOC. Then, plugging these numbers into the formula,

Total lifetime effort B = (1/T4) (S/C)3

Total lifetime effort B = (1/T4) (200,000/4,000)3 = (1/T4) (50)3

Development effort E = 0.3945 B

If target development period is two years, then

Total lifetime effort B = (1/16) (50)3 = 7,812.5 staff-years

Development effort E = 0.3945 B = 3,082 staff-years

Putnam's recommended figures for C for different types of projects are:

●  Real-time embedded - 1,500;

●  Batch development - 4,894;

●  Supported and organized - 10,040;

Effort and productivity change when development time varies between two and three years:

Focusing on the productivity level is one major difference between the Boehm and Putnam models. It can be calculated based on the size, time, and effort values from previously completed projects. Putnam combines attributes of both the process and the product in his definition of productivity, and he separates the wide range of productivity values into an index ranging from 0 to 40. He calls this the process productivity index (PI), based on product attributes such as algorithm complexity and process attributes such as standards and team capabilities. Putnam is careful to explain that the PI is not a fair quantification of personal productivity because some of the attributes may not be within the control of the development team.

The PI makes a huge difference in the effort, schedule, and cost of a project. Organizations can improve their PI, just as they can improve their SEI CMM maturity level. Application types exhibit different PIs. For instance, business systems average 17.3, scientific systems average 14.8, telecommunications average 11.4, real-time systems average 8.3, and microcode systems average 6.3.

Size and productivity are constants, while time and effort can be adjusted to some degree. According to Fred Brooks (Brooks' Law), adding people to a late project generally only makes it later. There is a minimum time solution and a minimum effort/cost solution.

Essential steps in estimating with the mathematical model are made palatable with the use of automated tools:

Step 1. Estimate software size.

Application of a beta distribution is one way to do this (or expert opinion, analogy, Wideband Delphi).


Sn = the predicted nominal size of the software product

Smin = the minimum possible size

Si = the most likely size (50% probable)

Smax = the maximum possible size

Step 2. Determine productivity and environmental factors (PI, C).

Step 3. Identify the development constraints (maximum cost, etc.).

Step 4. Construct a planning zone (feasible region versus the impractical or impossible zones) similar to Figure 3.
Planning Zone

Step 5. Find an acceptable planning point.

The QSM model default is based on four phases (users may customize this): requirements, design, code, and integration. The third phase is determined by estimated size and PI; phases 1 and 2 are determined as percentages of phase 3 values by analysis of historical data; and phase 4 is an extrapolation of the phase 3 staffing curve. (See Figure 4).

Staffing Profile

Advantages of the SLIM Model

Advantages of the SLIM model include:

●  Provides a comprehensive set of software development management tools that support the entire software program life cycle.

●  Helps to enforce good habits within engineering and management team (software project planning, and software project tracking and oversight key process areas within the SEI CMM Level 2).

●  Offers value-added effective planning, especially on large projects.

●  Uses linear programming, statistical simulation, program evaluation, and review techniques to derive a software cost estimate. (Linear programming allows the user to impose a maximum cost, a maximum schedule, and high and low bounds on staffing, and to have an appropriate range of time and effort solutions returned.)

●  Allows "design to cost" if the user elects to enter size and desired number of staff-months.

●  Enables a software cost estimator to perform the following functions:

-  Calibration - Fine-tune the model to represent the local software development environment by interpreting a historical database of past projects.

- Build - Create an information model of the software system, collecting software characteristics, personal attributes, computer attributes, and so on.

- Software sizing - Use an automated version of the LOC costing technique.

●  Allows an organization to tailor life cycle phases and milestones fit a given environment.

●  Simplifies strategic decision making.

●  Provides an optimal staffing policy in the context of the development environment.

●  Supports "what-if" analysis.

●  Generates reports and graphs for:

-  monthly staffing profiles

-  monthly budget profiles

-  risk profiles for cost, schedule, and effort

-  forecasts of software reliability

-  forecasts of beginning and ending milestones

●  Provides defect rate information.

●  SLIM will output minimal time and associated cost and effort, including a sensitivity analysis showing how the values change as the size estimate varies from one to three standard deviations.

Disadvantages of the SLIM Model

Disadvantages of the SLIM model include:

●  It works best on large projects (some say anything where software size is greater than 5,000 lines, effort is greater than 1.5 person-years, and development time is more than 6 months).

●  To use the model, the software size must be identified in advance.

●  Estimates are extremely sensitive to the technology factor.

●  The model is extremely sensitive to compression of the delivery time (td).

●  The model is extremely sensitive to the size estimate.

●  With the environmental factor, many important factors must be modeled, many of which may be difficult to determine.

●  It assumes a waterfall life cycle, which does not map to incremental iterative (spiral) development process or the Rational Unified Process.

●  Users must remember to add phases and integral tasks such as program management.

●  The tool is complex - it is not usually a 2- to 5-minute job to update a model.

●  The model often shows that total effort of small projects may be less than the effort of their sum if they were one large project. The user must be careful not to chop large projects into too many smaller ones, considering interface issues.


life cycle, software estimating, productivity level, software size
The contents available on this website are copyrighted by TechPlus unless otherwise indicated. All rights are reserved by TechPlus, and content may not be reproduced, published, or transferred in any form or by any means, except with the prior written permission of TechPlus.
Copyright 2018 SPMInfoBlog.
Designed by TechPlus