Software Estimation, Development, and Research

Author: Michael Chaves, Synaction Consulting Group

Software development is a business, and while it can be lucrative, it normally requires a large amount of up-front investment. Therefore, even if an iterative approach to development is used, it is normally necessary to be able to provide a reasonably accurate estimate of what the total cost (money, people, time) of the software development will be. This is especially true of large projects.

Assume that a business has identified a need for a new piece of software. The type of software is irrelevant to this discussion. It could be for in house use, a product for sale, or all new development or major redesign of an existing system. Also assume that even in the absence of any formal requirements gathering it's quite obvious that the project will be very large. Management usually needs to have a reasonably accurate cost estimate to determine if the investment in the project makes sense from a business point of view.

Developing in an Ideal World

From a business point of view the ideal would be for software to be built with the following steps:

1. Cost Estimation
2. Requirements Gathering
3. Design
4. Development
5. Testing
6. Production

Steps 2 though 6 are simply the classic "Waterfall" model of development. Unfortunately, this methodology cannot be successful. The issue is that any reasonably accurate cost estimate requires (at least) stages 2 and 3 to be completed. Additionally, any errors (missed requirements or unworkable designs) can easily cause the estimate to be off by 100% or more. Clearly a better approach is required.

To solve the problems of the Waterfall model, various flavors of iterative (sometimes called spiral) development have been formulated. For example, a true iterative development could be done as follows:

1. Requirements Gathering
2. Design
3. Cost Estimation
4. Development
5. Testing
6. Proceed to step 1 for the next iteration or go into Production.

Each iteration must deliver a testable feature or features. From a management decision point of view, the attraction of this method is that a go/no go decision can be made at every iteration after stage 3. This completely prevents runaway projects. This methodology, especially when combined with test driven development, leads to faster overall development and higher quality. This however does not contribute to the initial decision of whether or not to invest in the project.

A Better Approach for Large Projects

From the standpoint of making that initial decision, a slightly less iterative approach should be followed for large projects.

1. Initial Requirements Gathering
2. Initial Design
3. Approximate Cost Estimation for the whole project
4. Iterate

   I1.	Refine Requirements
   I2.	Refine Design
   I3.	Refine Cost Estimate
   I4.	Development
   I5.	Testing
   I6.	Proceed to next iteration

5. Production

Again, each iteration must deliver a testable feature or features. This method allows management to make a go/no go decision at step 3 (quite early in the project) and at each iteration at step I3. It provides almost all of the other benefits of the true iterative development model except that the true iterative model will lead to slightly faster overall development. For example, this approach trades a small amount of total development speed for earlier predictability, and the earlier predictability can actually lead to lower overall total project costs.

The keys to this method are steps 1 and 2. If they are allowed to grow too large, too many resources are spent before any go/no go decision can be made. Conversely, if insufficient resources are provided for these steps then the initial cost estimate is liable to be worthless. So proper attention to the first two steps is in many ways a balancing act. One of the most important, and least considered, keys to that balancing act is understanding the basic difference between software development and software research.

Research and Development

In general:

Development (WordNet® 2.1. Princeton University. 20 Jan. 2007, dictionary.reference.com)
[The] act of improving by expanding or enlarging or refining

Research (WordNet® 2.1. Princeton University. 20 Jan. 2007, dictionary.reference.com)
[The] systematic investigation to establish facts

Why is this important to software estimation? Because development costs can be estimated, research costs cannot. Note that this statement is much more general than software; it is true over all engineering disciplines.

Software estimation is often harder because the line between development and research is much blurrier in software than most other disciplines. Take software requirements as an example. While gathering requirements is usually considered and estimated as a development type task (and it can be), it is often actually a research task. Often, not even the users know what the "facts" are.

Another example might involve taking a legacy application from a rich client architecture to a thin client architecture. Normally this would be assumed to be straightforward software development and costs would be estimated on that assumption. However, this may not be the case. Consider any of the following (at least in the days before AJAX):

1. The thick client used drag-and-drop heavily.
2. The thick client allowed the user to scroll though enormous (10,000+) item lists.
3. The thick client required the use of disk buffers for acceptable performance.

Now, none of these may actually be research if at least one known methodology exists for handling the requirement (#1 really stopped being research with the wide acceptance of AJAX). The point is that the task is a research task if you don't know the approach to take to handle the requirement or issue.

The key is to determine what research the project requires, either in the first few iterations (if using the true iterative model) or in the initial design (if using the modified iterative model). Then recognize that research can only be bounded, not estimated. Accept the fact that research can fail (i.e., the acceptable cost boundary reached without a resolution). At that point the only recourse is to do more research or accept that the project should not continue.

From a business point of view, the "trick" is to make sure the research gets done first or at least early, so that if it fails, minimal resources have been lost.

For example, maybe that thick client should have merely been re-architected to use web services. Or maybe a new UI should go through several iterations to get "buy-in" from the users before any backend processes are written. The point is that an early resolution to the research allows alternate solutions to be explored.

Copyright ©2006 Synaction, Inc.