Software Reliability: A Federal Highway Administration Preliminary Handbook

PDF files can be viewed with the Acrobat® Reader®

Chapter 2: Software Life Cycle

The techniques developed in this handbook can be applied separately or in conjunction to improve the reliability of the software product. This chapter examines the utilization of these techniques throughout the software development life cycle. This chapter discusses:

• Software development life cycles.
• Software development phases.
• Application of the handbook's techniques in the life cycle.

Software Development Life Cycles (SDLC)

When developing any large complex system, it is customary to divide it into tasks or groups of related tasks that make it easy to understand, organize, and manage. In the context of software projects, these tasks or groups of tasks are referred to as phases. Grouping these phases and their outcomes in a way that produces a software product is called a software process or an SDLC.

There are many different software processes, and none is ideal for all instances. Each is good for a particular situation and, in most complex software projects, a combination of these processes is used. The most used life cycles (processes) for software development are:

• Waterfall.
• V (or U).
• Evolutionary/Incremental.
• Spiral.

Recently, with the advent of Internet applications, many fast software development processes were developed, including:

• Rapid Applications Development (RAD): Centered on the Joint Application Development (JAD) sessions. System stakeholders (owners, users, developers, testers, etc.) are brought together in a session to develop the system requirements and acceptance tests.
• Extreme Programming (XP): Very short cycle (usually weeks) centered on developing, testing, and releasing one function (or very small group of related functions) at a time. Relies primarily on human communication with no documentation.

All of these systems are discussed in detail in the literature.

Software Development Phases

Most of the processes outlined above encompass most or all of the following activities or phases:

• Concept Exploration: At this phase, concepts are explored, other alternatives (other than developing the system) are considered.
• Requirement: The software functionality is determined from a user's point of view (user's requirements) and a system's point of view (system's requirements).
• Specifications: The requirements are turned into rigorous specifications.
• Design: The requirements are transformed into a system design. The requirements are partitioned into groups and assigned to units and/or subsystems, then the relationships (interfaces) between those units and/or subsystems are defined.
• Unit Build and Test: The design is transformed into code for every unit. Every unit is then tested.
• Integration and Test: Units are brought together, preferably in a predetermined order, to form a complete system. During this process, the units are tested to make sure all the connections work as expected.
• System and Users' Acceptance Testing: The entire system is tested from a functional point of view to make sure all the functions (from the requirements) are implemented correctly and that the system behaves the way it is supposed to all circumstances.
• Operation, Support, and Maintenance: The system is installed in its operational environment and, as it is being used, support is provided to the users. As the system is used, defects might be discovered and/or more functionality might be needed. Maintenance is defined as correcting those defects and/or adding functionality.

Scope of Chapter

Only some of the highlights of the extensive literature on SDLCs are included here to help explain where in the life cycle the techniques developed in the handbook are applicable.

What Constitutes Testing

For the purposes of discussion, the V model is used to pinpoint where the techniques developed in this handbook can be applied. Keep in mind, as mentioned above, that most of these processes have the same activities and phases.

As shown in figure 1, the V model contains all the phases outlined above.

Figure 1: The V (U) Model for SDLC

For simplicity and certain similarities in their accomplishment, some of the phases that require similar techniques are combined here. These are:

• Definition Phase: This phase includes the Requirements and Specifications phases.
• Design Phase: High- (software architecture) and low- (unit and/or object) level design.
• Code: The Build Code (construction) phase
• Unit and Integration Tests: These are combined because they are both concerned with the structure (white-box) testing and, in most instances, are performed by the programmers.
• System and User's Acceptance Testing: These tests are concerned more with the functional (black-box) testing and performed by testers (which may or may not be in the same organization as the programmers).

Figure 2 is a simplification of the V model and includes techniques outlined in the remainder of this handbook.

Figure 2: Simplified V Model with Handbook Techniques

	SpecChekTM: Used in the definition phase to organize the requirements. The specifications can be coded in XML, and SpecChekTM is used to produce a running version of the specifications. "What if" scenarios then can be created to consider different alternatives. This can also be used as a communication tool with users and stakeholders to clarify ambiguities in the requirements. After the specifications have been completed, the XML (SpecChekTM) version can be saved and used later on in the system and acceptance testing phases to compare SpecChek (expected) results with the system's (actual) outputs.
	Wrapping: Used to wrap pieces of code that are either critical or that communicate (their output is used by) critical code. The wrapper tests the result (output) of the wrapped code before it is passed to other parts of the system. This can be used to test structure (to verify the execution of a particular path) and function (to verify a particular function) .
	Numerical Reliability: Used to verify the numerical precision and accuracy of a mathematical computation.

Previous | Table of Contents | Next