September 26th, 2008 chris
Have you tried putting oil into water or vice versa? What do you get? Nothing, oil is still oil and water is still water. They do not combine to make a compound. They do not get mixed up. Same us with regards to Estimation and Planning. Do not mix them up or get mixed up between the two.
Estimation and planning are related topics, but estimation is not planning, and planning is not estimation. Estimation should be treated as an unbiased, analytical process; planning should be treated as a biased, goal-seeking process. With estimation, it’s hazardous to want the estimate to come out to any particular answer. The goal is accuracy; the goal is not to seek a particular result. But the goal of planning is to seek a particular result. We deliberately (and appropriately) bias our plans to achieve specific outcomes. We plan specific means to reach a specific end.
Estimates form the foundation for the plans, but the plans don’t have to be the same as the estimates. If the estimates are dramatically different from the targets, the project plans will need to recognize that gap and account for a high level of risk. If the estimates are close to the targets, then the plans can assume less risk.
Both estimation and planning are important, but the fundamental differences between the two activities mean that combining the two tends to lead to poor estimates and poor plans. The presence of a strong planning target can lead to substitution of the target for an analytically derived estimate; project members might even refer to the target as an “estimate,” giving it a halo of objectivity that it doesn’t deserve.
Here are examples of planning considerations that depend in part on accurate estimates:
-
Creating a detailed schedule
-
Identifying a project’s critical path
-
Creating a complete work breakdown structure
-
Prioritizing functionality for delivery
-
Breaking a project into iterations
Accurate estimates support better work in each of these areas
Posted in Estimation
September 26th, 2008 chris
When executives ask for an “estimate,” they’re often asking for a commitment or for a plan to meet a target. The distinctions between estimates, targets, and commitments are critical to understanding what an estimate is, what an estimate is not, and how to make your estimates better.
What you need to do is to distinguish between estimates, targets, and commitments.
An estimate is a prediction of how long a project will take or how much it will cost. But estimation on software projects interplays with business targets, commitments, and control.
A target is a statement of a desirable business objective. Businesses have important reasons to establish targets independent of software estimates. But the fact that a target is desirable or even mandatory does not necessarily mean that it is achievable.
A commitment is a promise to deliver defined functionality at a specific level of quality by a certain date. A commitment can be the same as the estimate, or it can be more aggressive or more conservative than the estimate. In other words, do not assume that the commitment has to be the same as the estimate; it doesn’t.
Posted in Estimation
September 26th, 2008 chris
Move over Heidi, Kate and Cindy, if we are talking about software reliability, this model will surely dominate the runway. Supermodel Rayleigh.
A model of software reliability, the Rayleigh model is a parametric model in the sense that it is based on a specific statistical distribution. When the parameters of the statistical distribution are estimated based on the data from a software project, projections about the defect rate of the project can be made based on the model.
The Rayleigh model is a special case of the Weibull distribution family, which has been widely used for reliability studies in various fields. Supported by a large body of empirical data, software projects were found to follow a life-cycle pattern described by the Rayleigh curve, for both resource and staffing demand and defect discovery/removal patterns. The Rayleigh model is implemented in several software products for quality assessment. It can also be implemented easily via statistical software packages, such as the example provided in this chapter.
Compared to the phase-based defect removal model, the Rayleigh model is a formal parametric model that can be used for projecting the latent software defects when the development work is complete and the product is ready to ship to customers. The rationale behind the model fits well with the rationale for effective software development. Specifically, while the defect removal effectiveness approach focuses on defect removal, the Rayleigh encompasses both defect prevention (reduction in defect rates) and early defect removal.
In addition to quality projection, another strength of the Rayleigh model is that it provides an excellent framework for quality management.
Posted in Software Metrics
September 26th, 2008 chris
Kaoru Ishikawa, a Japanese University professor and influential quality management innovator, developed seven basic tools for quality control.
They are the following:
- Checklist (or Check Sheet)
- Pareto diagram
- Histogram
- Scatter Diagram
- Run Chart
- Control Chart
- Cause-and-effect Diagram
Posted in Software Metrics
September 26th, 2008 chris
Customer satisfaction is often measured by customer survey data via the five-point scale:
-
Very satisfied
-
Satisfied
-
Neutral
-
Dissatisfied
-
Very dissatisfied.
Satisfaction with the overall quality of the product and its specific dimensions is usually obtained through various methods of customer surveys. For example, the specific parameters of customer satisfaction in software monitored by IBM include the CUPRIMDSO categories (capability, functionality, usability, performance, reliability, installability, maintainability, documentation/information, service, and overall); for Hewlett-Packard they are FURPS (functionality, usability, reliability, performance, and service).
Based on the five-point-scale data, several metrics with slight variations can be constructed and used, depending on the purpose of analysis. For example:
(1) Percent of completely satisfied customers
(2) Percent of satisfied customers (satisfied and completely satisfied)
(3) Percent of dissatisfied customers (dissatisfied and completely dissatisfied)
(4) Percent of nonsatisfied (neutral, dissatisfied, and completely dissatisfied)
Usually the second metric, percent satisfaction, is used. In practices that focus on reducing the percentage of nonsatisfaction, much like reducing product defects, metric (4) is used.
In addition to forming percentages for various satisfaction or dissatisfaction categories, the weighted index approach can be used. For instance, some companies use the net satisfaction index (NSI) to facilitate comparisons across product. The NSI has the following weighting factors:
NSI ranges from 0% (all customers are completely dissatisfied) to 100% (all customers are completely satisfied). If all customers are satisfied (but not completely satisfied), NSI will have a value of 75%. This weighting approach, however, may be masking the satisfaction profile of one’s customer set. For example, if half of the customers are completely satisfied and half are neutral, NSI’s value is also 75%, which is equivalent to the scenario that all customers are satisfied. If satisfaction is a good indicator of product loyalty, then half completely satisfied and half neutral is certainly less positive than all satisfied. Furthermore, we are not sure of the rationale behind giving a 25% weight to those who are dissatisfied. Therefore, this example of NSI is not a good metric; it is inferior to the simple approach of calculating percentage of specific categories. If the entire satisfaction profile is desired, one can simply show the percent distribution of all categories via a histogram. A weighted index is for data summary when multiple indicators are too cumbersome to be shown. For example, if customers’ purchase decisions can be expressed as a function of their satisfaction with specific dimensions of a product, then a purchase decision index could be useful. In contrast, if simple indicators can do the job, then the weighted index approach should be avoided.
Posted in Software Metrics