The Software Development Life Cycle

LEARNING OBJECTIVES

•      to recognize that an information systems development project follows a well-defined system development life cycle (SDLC) methodology

•      to examine the separate data and process models within an SDLC

•      to identify the more popular SDLC methodologies

•      to list the key features of the phased development methodology (PDM)

•      to identify where software testing occurs in the PDM

2.1 INTRODUCTION

The development of an information system demands the commitment of valuable company resources and time. Large projects often require millions of dollars of effort and take years to complete. Specifi c sequences of activities have been devised to guide developers along a path that repeatedly delivers quality software on time and within budget. In this chapter, we describe how collections of the more popular software activities have evolved, and then focus on one collection named the PDM, which is especially effective in providing an overall framework for software development.

2.2 METHODOLOGIES AND TOOLS

Two terms that one often hears in relation to information systems development are methodologies and tools. A methodology is a recommended way of doing something, and a tool is a device for accomplishing a task. Relating these terms to the

Software Testing: Testing Across the Entire Software Development Life Cycle, by G. D. Everett and R. McLeod, Jr. Copyright © 2007 John Wiley & Sons, Inc.

   29

building of a house, the arhchitect’s blueprint is a methodology (the architect’s recommended way of building the house), and the tools are what the construction workers use to actually build the house (nail guns, circular saws, and electric drills).

An information system methodology is a recommended way to develop an information system. A System Development Life Cycle (SDLC) is a series of stages within the methodology that are followed in the process of developing and revising an information system. A stage is a segment of an SDLC that consists of certain types of activity. Stages are usually completed in a certain sequence using software development tools.

Developers use system design tools for data, process, and object modeling. Data modeling tools include entity-relationship diagrams (ERDs) and data dictionaries. Process modeling tools include data fl ow diagrams (DFDs) and use case diagrams. Object modeling tools include class and sequence diagrams. Business processing uses workfl ow diagrams (WFDs).

2.3 THE EVOLUTION OF SYSTEM DEVELOPMENT LIFE CYCLES

When the fi rst business computer was installed at General Electric in 1954, the developers had no previous experiences to guide them in the right direction. They were forced to use trial and error. Gradually, the developers compiled a list of Do’s and Don’ts to cut down on the errors and increase the likelihood that the next development project would be more successful.

2.3.1 The Classical SDLC

The lists of Do’s were the beginning of an SDLC. The first SDLC structure, which we will call the classical SDLC, consisted of four stages—planning, analysis, design, and implementation. Planning consisted of such things as defining the problem to be solved or specifying the objectives of the new system. Analysis consisted of conducting a system study for the purpose of thoroughly understanding the existing system. Design consisted of defining the processes and data to be used in the new system. Implementation consisted of preparing the software, building the data files, assembling the hardware, and cutting over to the new system. Figure 2.1 illustrates how these stages were intended to be taken in sequence. The term waterfall development life cycle is used today to describe the classical SDLC because it was based on the assumption that each stage would be executed a single time in a specific sequence.

2.3 The Evolution of System Development Life Cycles

Figure 2.1   The waterfall development life cycle

2.3.2 Prototyping

Although the sequence of the classical SDLC stages was intuitively logical, there were two major weaknesses. First, it took from 3 to 5 years to go through the stages in order. All too frequently, the business market targeted by the new system had time to move out from under the new system. Second, there was invariably a need to backtrack and repeat stages or portions of stages to accommodate changes in business requirements or changes in the business market.

Developers came to the conclusion that a better approach would be to expect that interim changes would be the rule rather than the exception. The result was prototyping: the development of a system by means of a series of iterations to incorporate midstream changes until the system meets all the business requirements. Figure 2.2 shows how the prototyping stages are arranged with any of the first four stages repeated until the user approves the prototype. Stage names different from those in the classical SDLC are used in the figure, but they continue the logical sequence that begins with planning and concludes with implementation.

In some projects, the user is unable to specifi cally defi ne what the system will accomplish and how it will accomplish it. In these cases, developers use prototyping to defi ne the user’s needs.  This kind of prototype is called a requirements prototype. The prototype is often just a nonoperational shell of the intended system. Once it is approved, it serves as the blueprint for development of the system following an

Reject prototype

Figure 2.2 The prototyping development life cycle

SDLC methodology. Figure 2.2 also illustrates the requirements prototype by virtue of the design iteration, with the blueprint serving as the basis for completing the system components such as software, hardware, and data. In other cases, a prototype called an evolutionary prototype is built to contain all of the operational features of the system and is put into use upon approval.

Although the classical SDLC has been largely replaced, prototyping continues to be used in many development projects, especially those of relatively simple PC-based systems like electronic spreadsheets and database management systems.

2.3.3 Rapid Application Development

Computer consultant James Martin conceived of the rapid application development (RAD) in an effort to expand the classical SDLC to larger scale projects while substantially reducing the implementation time by 2–3 years. [12] RAD consists

2.4 The Phased Development Methodology

Figure 2.3 The RAD life cycle compared with a classical SDLC. Source: James Martin, Rapid A pplication Development, Prentice Hall, New York, 1991, page 127. Reprinted by permission of Pearson Education, Inc, Upper Saddle River, NJ.

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. Sometimes 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 THE PHASED DEVELOPMENT METHODOLOGY

The main underlying concept of phased development is that the system can be subdivided into subsystems or modules. Each subsystem represents the objective of a separate development phase. A phase is a series of SDLC stages that are completed for a subset of a system, a subsystem, or module. Once work on the individual phases is completed, the subsystems are integrated to form a whole solution.

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.igure 2.4 PDM stages and phases

2.4 The Phased Development Methodology

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 documents. No code is written in these phases, so no test executions can be performed.

igure 2.5 PDM phases of a data warehousing project

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 programming 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, Operator 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 e xecution 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 probably be employed to verify the continued  operation of the system as designed and tested. This kind of testing is considered  “passive’’ t esting 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. Putting 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 construction 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.

Table 2.1    Testing in the PDM

Stage

Type of testing

Preliminary investigation Analysis Design Preliminary construction Final construction Installation Postimplementation evaluation

None •   Static testing of requirements •   Static testing of all design documents •   Static testing of all codes •   Functional tests •   Performance tests •   Static testing of users guide, operators guide, installation guide, and training material •   Performance tests •   Load tests •   User acceptance testing •   Installation testing None •   Monitoring of operation and performance within prescribed boundaries

We will now describe each stage of the PDM.

2.5 THE PRELIMINARY INVESTIGATION STAGE

During preliminary investigation, the developers perform an enterprise analysis. From this analysis the developers defi ne system goals, objectives, and performance criteria. The developers evaluate system and project risk. Finally, the developer evaluates system and project feasibility. The stage is completed when the developers receive user approval of their fi ndings and recommendations to proceed.

2.5.1 Perform Enterprise Analysis

As the developers seek to become familiar with the organization and its environment, two graphical diagrams can provide a framework. Figure 2.6 is the general systems model of an example called the “fi rm,” which contains all of the required components and fl ows of an organization functioning as a closed-loop, managed system. The developers can ensure that all process components and data fl ows are present and performing as intended. For example, does the fi rm have standards of performance that managers are to achieve ? Another example, does information fl ow directly to management from the physical system of the fi rm where the fi rm’s operations are performed?