October 12th, 2008 chris
Of the three types of Measurement Models, Text models tend to be the least effective, but the most common. It is difficult to adequately describe complex situations and dynamics using just words.
Here is a text model for software development:
Effort: The time required to develop a product, expressed as increments of staff development time (e.g., staff months/hours). In general, effort is a function of size and results in cost.
Features: The requirements of the product to be developed.
Size: The magnitude of the product to be developed. In general, size is a function of features.
Defects: The incompleteness of the product. In general, defects are a function of size and schedule.
Schedule: The total development time; completion times for principal milestones. In general, schedule is a function of effort and resources.
Resources: The number of developers applied to the product development.
This text model has advantages and disadvantages. Each item is clearly defined and easy to understand, but the relationships between items may be difficult to visualize. But notice that this text model describes software development in such a way that we can discuss it, measure it, and predict it: if the size changes, the number of defects will change. This text model gives structure to the abstract concept of software development.
Posted in Estimation
October 12th, 2008 chris
The key to making the unmeasurable measurable is models. A model is an abstraction, which strips away unnecessary details and views an entity or concept from a particular perspective. Models allow us to focus on the important parts, ignore those that are irrelevant, and hypothesize and reason about an entity. Models make measurement possible.
We must have models of whatever we want to measure. For example, say we want to know how much of the total system development effort is testing. To determine that, we need a model of both the overall development process and the testing process, which specifies when testing starts and when it ends, what is included, and the number of people involved. If our model starts with unit test by the programmer, it is a different model and will give different results than one that includes only system test.
There are three types of models you can use: text, diagrammatic, and algorithmic that is, words, pictures, and numbers.
Posted in Estimation
October 12th, 2008 chris
Need a philosophical or theoretical framework on how to measure anything or concerned about how to create a model. The Pantometric Paradigm is a simple method to produce a purely visual and quantitative model of anything within the material world. You can use it to create an initial model that can evolve to meet your needs. The simple process is:
1. Reduce what you are trying to model to the minimum required by its definition. Strip away all extraneous information.
2. Visualize it on a piece of paper or in your head.
3. Divide it in fact or in your imagination into equal parts.
4. Then measure it (e.g., count the parts).
Now you have a quantitative representation (model) of your subject which matches your definition. You can now manipulate it, reason about it, experiment with it, and evolve it.
Posted in Estimation
October 12th, 2008 chris
In science, there are a lot of theories, and one of the most popular is Albert Einstein’s theory of gravitation called “General relativity”. According to general relativity, the observed gravitational attraction between masses results from the warping of space and time by those masses.
In software development, particularly on estimation, there are also theories that exist. One is a theory to define measurements and metrics, and it is called the “Measurement Theory”.
Measurement theory allows us to validly define measurements and metrics and to use statistical analysis on our metrics data.
Measurement theory is a branch of applied mathematics. The specific theory we use is called the Representational Theory of Measurement. It formalizes our intuition about the way the world actually works. In this theory, intuition is the starting point for all measurement. Any data manipulation of the measurements must preserve the relationships that we observe between the real-world entities that we are measuring.
Measurement theory allows us to validly analyze and manipulate our measurement data.
As an example, consider a customer satisfaction survey. Your users were asked what they thought of your customer support. The possible answers were:
1 Excellent
2 Good
3 Average
4 Inadequate
5 Poor
The result was that you ended up with a score of 3. So, you have average support, and it means you just need to improve a bit, right? Well, maybe. Or maybe not. When you looked at the data, you found out that your scores were 50% Excellent and 50% Poor. No one thought your customer support was average. Measurement theory dicates that taking the average of this kind of data is invalid and can give misleading results.
Measurement theory allows us to use statistics and probability to understand quantitatively the possible variances, ranges, and types of errors in the data.
Assume that you are responsible for estimating the effort and schedule for a new project. You use a prediction model for development effort, and it predicts that, on average, the effort will be 10 staff years with a duration of 1 year. What would you then tell your boss as your estimate? Maybe you would pad it by one staff year, just to be safe. What if you knew that the standard deviation is 2 staff years? A standard deviation of 2 means that 68% of the time, you expect the result to be between 8 and 12 staff years. This means that 16% of the time it will be over 12 staff years. Now what would you estimate? 12 staff years? 13? Or 10? What if, instead, you knew that the standard deviation was 4 months? Then what would you estimate? 10.5 staff years? (By the way, if we were the boss, we would prefer an answer that included the range with probabilities. We would want the additional information to better trade-off the risks and the rewards.)
Posted in Estimation
September 30th, 2008 chris
When you’re asked to provide an estimate, determine whether you’re supposed to be estimating or figuring out how to hit a target.
One implication of the close and sometimes confusing relationship between estimation and planning is that project stakeholders sometimes miscommunicate about these activities.
Most executives don’t have the technical background that would allow them to make fine distinctions between estimates, targets, commitments, and plans. So it becomes the technical leader’s responsibility to translate the executive’s request into more specific technical terms.
Usually , executives are not really asking for an estimate; instead they are really asking project leaders to come up with a plan to hit a target.
Posted in Estimation
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