Capers Jones, Chief Scientist at Software Productivity Research, summarized 20 years of software research by pointing out that he and his colleagues have seen 40 different methods for gathering requirements, 50 variations in working on software designs, and 30 kinds of testing applied to projects in more than 700 different programming languages (Jones 2003).
Different kinds of software projects call for different balances between preparation and construction. Every project is unique, but projects do tend to fall into general development styles. Table 3-2 shows three of the most common kinds of projects and lists the practices that are typically best suited to each kind of project.
Table 3-2. Typical Good Practices for Three Common Kinds of Software Projects
Kind of Software | |||
---|---|---|---|
Business Systems |
Mission-Critical Systems |
Embedded Life-Critical Systems | |
Typical applications |
Internet site Intranet site Inventory management Games Management information systems Payroll system |
Embedded software Games Internet site Packaged software Software tools Web services |
Avionics software Embedded software Medical devices Operating systems Packaged software |
Life-cycle models |
Agile development (Extreme Programming, Scrum, timebox development, and so on) Evolutionary prototyping |
Staged delivery Evolutionary delivery Spiral development |
Staged delivery Spiral development Evolutionary delivery |
Planning and management |
Incremental project planning As-needed test and QA planning Informal change control |
Basic up-front planning Basic test planning As-needed QA planning Formal change control |
Extensive up-front planning Extensive test planning Extensive QA planning Rigorous change control |
Requirements |
Informal requirements specification |
Semiformal requirements specification As-needed requirements reviews |
Formal requirements specification Formal requirements inspections |
Design |
Design and coding are combined |
Architectural design Informal detailed design As-needed design reviews |
Architectural design Formal architecture inspections Formal detailed design Formal detailed design inspections |
Construction |
Pair programming or individual coding Informal check-in procedure or no check-in procedure |
Pair programming or individual coding Informal check-in procedure As-needed code reviews |
Pair programming or individual coding Formal check-in procedure Formal code inspections |
Testing and QA |
Developers test their own code Test-first development Little or no testing by a separate test group |
Developers test their own code Test-first development Separate testing group |
Developers test their own code Test-first development Separate testing group Separate QA group |
Deployment |
Informal deployment procedure |
Formal deployment procedure |
Formal deployment procedure |
On real projects, you'll find infinite variations on the three themes presented in this table; however, the generalities in the table are illuminating. Business systems projects tend to benefit from highly iterative approaches, in which planning, requirements, and architecture are interleaved with construction, system testing, and quality-assurance activities. Life-critical systems tend to require more sequential approaches— requirements stability is part of what's needed to ensure ultrahigh levels of reliability.
Some writers have asserted that projects that use iterative techniques don't need to focus on prerequisites much at all, but that point of view is misinformed. Iterative approaches tend to reduce the impact of inadequate upstream work, but they don't eliminate it. Consider the examples shown in Table 3-3 of projects that don't focus on prerequisites. One project is conducted sequentially and relies solely on testing to discover defects; the other is conducted iteratively and discovers defects as it progresses. The first approach delays most defect correction work to the end of the project, making the costs higher, as noted in Table 3-1. The iterative approach absorbs rework piecemeal over the course of the project, which makes the total cost lower. The data in this table and the next is for purposes of illustration only, but the relative costs of the two general approaches are well supported by the research described earlier in this chapter.
Table 3-3. Effect of Skipping Prerequisites on Sequential and Iterative Projects
Approach #1: Sequential Approach Without Prerequisites |
Approach #2: Iterative Approach Without Prerequisites | |||
---|---|---|---|---|
Project Completion Status |
Cost of Work |
Cost of Rework |
Cost of Work |
Cost of Rework |
20% |
$100,000 |
$0 |
$100,000 |
$75,000 |
40% |
$100,000 |
$0 |
$100,000 |
$75,000 |
60% |
$100,000 |
$0 |
$100,000 |
$75,000 |
80% |
$100,000 |
$0 |
$100,000 |
$75,000 |
100% |
$100,000 |
$0 |
$100,000 |
$75,000 |
End-of-Project Rework |
$0 |
$500,000 |
$0 |
$0 |
TOTAL |
$500,000 |
$500,000 |
$500,000 |
$375,000 |
GRAND TOTAL |
$1,000,000 |
$875,000 |
The iterative project that abbreviates or eliminates prerequisites will differ in two ways from a sequential project that does the same thing. First, average defect correction costs will be lower because defects will tend to be detected closer to the time they were inserted into the software. However, the defects will still be detected late in each iteration, and correcting them will require parts of the software to be redesigned, recoded, and retested—which makes the defect-correction cost higher than it needs to be.
Second, with iterative approaches costs will be absorbed piecemeal, throughout the project, rather than being clustered at the end. When all the dust settles, the total cost will be similar but it won't seem as high because the price will have been paid in small installments over the course of the project, rather than paid all at once at the end.
As Table 3-4 illustrates, a focus on prerequisites can reduce costs regardless of whether you use an iterative or a sequential approach. Iterative approaches are usually a better option for many reasons, but an iterative approach that ignores prerequisites can end up costing significantly more than a sequential project that pays close attention to prerequisites.
Table 3-4. Effect of Focusing on Prerequisites on Sequential and Iterative Projects
Approach #3: Sequential Approach with Prerequisites |
Approach #4: Iterative Approach with Prerequisites | |||
---|---|---|---|---|
Project completion status |
Cost of Work |
Cost of Rework |
Cost of Work |
Cost of Rework |
20% |
$100,000 |
$20,000 |
$100,000 |
$10,000 |
40% |
$100,000 |
$20,000 |
$100,000 |
$10,000 |
60% |
$100,000 |
$20,000 |
$100,000 |
$10,000 |
80% |
$100,000 |
$20,000 |
$100,000 |
$10,000 |
100% |
$100,000 |
$20,000 |
$100,000 |
$10,000 |
End-of-Project Rework |
$0 |
$0 |
$0 |
$0 |
TOTAL |
$500,000 |
$100,000 |
$500,000 |
$50,000 |
GRAND TOTAL |
$600,000 |
$550,000 |
As Table 3-4 suggested, most projects are neither completely sequential nor completely iterative. It isn't practical to specify 100 percent of the requirements or design up front, but most projects find value in identifying at least the most critical requirements and architectural elements early.
One common rule of thumb is to plan to specify about 80 percent of the requirements up front, allocate time for additional requirements to be specified later, and then practice systematic change control to accept only the most valuable new requirements as the project progresses. Another alternative is to specify only the most important 20 percent of the requirements up front and plan to develop the rest of the software in small increments, specifying additional requirements and designs as you go. Figure 3-2 and Figure 3-3 reflect these different approaches.
Figure 3-2. Activities will overlap to some degree on most projects, even those that are highly sequential
Figure 3-3. On other projects, activities will overlap for the duration of the project. One key to successful construction is understanding the degree to which prerequisites have been completed and adjusting your approach accordingly
For details on how to adapt your development approach for programs of different sizes, see Chapter 27.
The extent to which prerequisites need to be satisfied up front will vary with the project type indicated in Table 3-2, project formality, technical environment, staff capabilities, and project business goals. You might choose a more sequential (up-front) approach when
The requirements are fairly stable.
The design is straightforward and fairly well understood.
The development team is familiar with the applications area.
The project contains little risk.
Long-term predictability is important.
The cost of changing requirements, design, and code downstream is likely to be high.
You might choose a more iterative (as-you-go) approach when
The requirements are not well understood or you expect them to be unstable for other reasons.
The design is complex, challenging, or both.
The development team is unfamiliar with the applications area.
The project contains a lot of risk.
Long-term predictability is not important.
The cost of changing requirements, design, and code downstream is likely to be low.
Software being what it is, iterative approaches are useful much more often than sequential approaches are. You can adapt the prerequisites to your specific project by making them more or less formal and more or less complete, as you see fit. For a detailed discussion of different approaches to large and small projects (also known as the different approaches to formal and informal projects), see Chapter 27.
The net impact on construction prerequisites is that you should first determine what construction prerequisites are well suited to your project. Some projects spend too little time on prerequisites, which exposes construction to an unnecessarily high rate of destabilizing changes and prevents the project from making consistent progress. Some projects do too much up front; they doggedly adhere to requirements and plans that have been invalidated by downstream discoveries, and that can also impede progress during construction.
Now that you've studied Table 3-2 and determined what prerequisites are appropriate for your project, the rest of this chapter describes how to determine whether each specific construction prerequisite has been "prereq'd" or "prewrecked."
18.118.10.32