The Software Development Life Cycle
2.4 THE PHASED DEVELOPMENT METHODOLOGY
of basically the same stages as the classical SDLC, but they are augmented with heavier user involvement, use of computer-based development tools, and skilled with advanced tools (SWAT) teams. Figure 2.3 compares RAD with the classical approach and illustrates how users play much greater roles, especially during the early stages.
The information systems developers are able to spend less effort to complete tasks because they use computer-aided software engineering (CASE) tools. Some- times the information systems developers are organized into specialized teams, called SWAT teams, such as those specializing in activities like economic justifi cation and systems designs like those involving Web sites and wireless communications. Many large fi rms using large computer systems today are committed to RAD as their primary SDLC.
An SDLC that incorporates the best features of prototyping and RAD is the phased development methodology (PDM). Because it is the methodology that we will use in this text, it is described in detail on the remaining pages of this chapter.
2.4.1 Life Cycle Stages
Figure 2.4 illustrates how the project begins with a preliminary investigation.
Then the analysis, design, and preliminary construction stages are executed in an iterative manner for each phase until that phase receives user approval. Then, the two fi nal stages complete the project. This entire process represents the fi rst cycle in the life of the system being developed. The next releases of the system will follow the same process paths to produce the second-third, and fourth cycles in the life of the system. The life cycle is not considered complete until the system is sunset.
Design stage
Phase 1 Phase 2 Phase n
Preliminary investigation
stage
Final construction
stage
Installation stage
Preliminary construction
stage Analysis stage
Design stage Design stage
Preliminary construction
stage Analysis stage
Preliminary construction
stage Analysis stage
Design stage
Figure 2.4 PDM stages and phases
2.4.2 System Development Phases
Figure 2.5 shows how the analysis, design, and preliminary construction stages are repeated for a data warehousing project, assuming that the subsystems include a staging area, the warehouse data repository, and an information delivery system.
The work on each subsystem is a phase.
2.4.3 Software Testing in the Stages
Some kind of software testing is normally performed in every development phase except Installation. The Preliminary INVESTIGATION, Analysis, and Design phases are “paper and pencil’’ exercises because all of these phase results are docu- ments. No code is written in these phases, so no test executions can be performed.
Staging area module
Preliminary construction
stage Analysis stage
Design stage
Warehouse data repository module
Preliminary construction
stage Analysis stage
Design stage
Information delivery module
Preliminary construction
stage Analysis stage
Design stage Preliminary
investigation stage
Final construction
stage
Installation stage Figure 2.5 PDM phases of a data warehousing project
2.4 The Phased Development Methodology 35
That is ok because there is plenty to test in the documentation of the fi rst three phases. Documents are tested to verify they are correct, complete, accurate, use good spelling, use good grammar, and are properly formatted. This kind of manual testing is sometimes called “paper and pencil testing’’ because computer execution is not required. The more formally recognized term for this document testing is static testing. As we have seen in Chapter 1, if the system requirements are not static tested, then errors in the requirements will show up later as expensive program- ming defects. The PDM demonstrates that there are documents written before the requirements documents that can, in fact, cause the requirements documents to have errors. This documentation dependency further underscores the importance of the tested correctness of the earliest documents written.
Programmers do not normally refer to their code as “documentation,’’ but in fact it needs to be static tested like a document. If you have ever participated in code inspections or code walk-throughs, these are some of the ways code is static tested before it is executed for functional, structural, and performance verifi cation.
As the development progresses, other documents are produced that need to be static tested as well. Examples of these later documents are End User Guides, Opera- tor Guides, Training Manuals, and Installation Guides.
Once the development staff begins to write program code, additional kinds of testing are needed as the code begins to work and are successively larger components or modules of the application. Chapters 7–9 will provide a detailed treatment of the code execution kinds of testing. The majority of this execution testing is considered
“active’’ testing because the tests intentionally cause the code to behave in certain expected ways. Once the new system is installed, some kind of monitoring will prob- ably be employed to verify the continued operation of the system as designed and tested. This kind of testing is considered “passive’’ testing because the tests do not cause the code to behave in certain ways; rather, the tests only observe and report the behavior of the system doing routine business.
The Installation phase of the PDM is the only phase in which no testing occurs.
This phase presents its own challenges to the development and production teams but not the testing team. The testing team has already validated that the system will successfully install and that the persons responsible for operating the system can perform the install correctly. This installation verifi cation is accomplished in the last steps in the Final construction phase. To understand this approach better, place yourself in the role of the new system owner who must sign a document saying that the new system is ready for installation in production. Remember that production is the way your company sustains daily business on the computer. Put- ting anything untried in production is playing Russian Roulette with your entire business. Are you really going to agree that the new system is ready for installation in production without seeing proof that the new system passed all Final construc- tion tests? We hope not.
Table 2.1 is a summary of the above testing discussion by PDM phase with a little additional detail in the code producing phases to set the stage for the Chapters 7–9 presentations.
We will now describe each stage of the PDM.