McGraw-Hill

1 The McGraw-Hill Companies, Inc., 2000

10-1 THE SOFTWARE LIFECYCLE

A fundamental concept in software engineering is the software lifecycle. Software, like many other products, goes through a cycle of repeating phases (Figure 10.1).

Figure 10.1 The software lifecycle

10. 2

Development process models

The development process in the software lifecycle involves four phases: analysis, design, implementation testing There are several models for the development process. We discuss the two most common here: waterfall model incremental model

10. 3

End users perspective:

Clients perspective:

No system: what system? I havent seen a system. Unusable Insufficient power

Developers perspective:
Wrong requirements Insufficient resources Incomplete requirements Impossible requirements Blame the others

Too expensive Too late Change of mind Change of requirements

Quality problems:

Process problems:

The wrong problem is addressed. Wider influence are neglected. Analysis is carried out incorrectly. Project undertaken for the wrong reasons. Requirements drift. External events change the environment. Implementation is not feasible. Poor project management.

Main phases are

Data gathering Problem redefinition

Finding ideas Finding solutions

Implementation

These focus on understanding what the problem is about Concerned with understanding more about the nature of the problem and possible solutions

The information systems development process is a partially ordered collection of actions, carried out by one or more developers, testers, users, or other information systems in order to accomplish a task. The development life cycle is a process by which a information system is developed, tested, installed and maintained throughout its useful history. The concept of lifecycle is a useful project management tool. A lifecycle consists of phases, each of which is a process.

For large software systems, involving >10k lines of code, the breakdown of costs between different phases is as follows:

Small software systems<5k LOC

Specification Decomposition Coding Optimization Testing Validation

Requirements Analysis Design Programming-in-the-small Integration Maintenance and Evolution

5% 10%
60%

15% 10%

Systems analysis and design more important.

10% 20% 20% 15% 25% 10%

The lifecycle describes the temporal, causal and I/O relationships between different lifecycle phases. The lifecycle concept includes the concept of feedback (returning to a previous phase) as well as moving forward to the next phase. In the past, the lifecycle concept was applied to the management of complex systems that had some sort of physical hardware as their end product, e.g., missiles, communication networks, spacecraft, etc.

A series steps through which the product progresses. A life cycle specifies:
The various phases of the process. The order in which they are carried out. The guidance for project management.

The waterfall model In this model, the development process flows in only one direction. This means that a phase cannot be started until the previous phase is completed.

Figure 10.2 The waterfall model

10. 13

System Engineering
High Level Architectural Specification

Requirements Analysis
Requirements Specification Functional Specification Acceptance Test Specifications

Design
Software architecture specification System test specification Design specification Sub-system test specification Unit test specification

Life cycle deliverables (adapted from Sommerville, 1992).

Construction
Testing

Program code Unit test report Sub-system test report System test report Acceptance test report Completed system

Life cycle deliverables (adapted from Sommerville, 1992).

Installation
Installed System

Maintenance
Change requests Change request report

Life cycle deliverables (adapted from Sommerville, 1992).

Real projects rarely follow such a simple sequential life cycle Iterations are almost inevitable Time elapses between system engineering and the final installation The design is unresponsive to business changes during the project

The incremental model In the incremental model, software is developed in a series of steps.

Figure 10.3 The incremental model

10. 19

10-2 ANALYSIS PHASE

The development process starts with the analysis phase. This phase results in a specification document that shows what the software will do without specifying how it will be done.

10. 20

Procedure-oriented analysis
Procedure-oriented analysisalso called structured analysis or classical analysisis the analysis process used if the system implementation phase will use a procedural language.

10. 21

Data flow diagrams Data flow diagrams show the movement of data in the system.

Figure 10.4 An example of a data flow diagram

10. 22

Entity-relationship diagrams Another modeling tool used during the analysis phase is the entity-relationship diagram. State diagrams

State diagrams (see Appendix B) provide another useful tool that is normally used when the state of the entities in the system will change in response to events.
As an example of a state diagram, we show the operation of a one-passenger elevator. When a floor button is pushed, the elevator moves in the requested direction. It does not respond to any other request until it reaches its destination.

10. 23

Figure 10.5 An example of a state diagram

10. 24

Object-oriented analysis
Object-oriented analysis is the analysis process used if the implementation uses an objectoriented language.

10. 25

Use case diagrams A use-case diagram gives the users view of a system: it shows how users communicate with the system. A use-case diagram uses four components: system, use cases, actors and relationships. A system, shown by a rectangle, performs a function.

Figure 10.6 An example of use case diagram

10. 26

Class diagrams The next step in analysis is to create a class diagram for the system. For example, we can create a class diagram for our old-style elevator. To do so, we need to think about the entities involved in the system.

Figure 10.7 An example of a class diagram

10. 27

State chart After the class diagram is finalized, a state chart can be prepared for each class in the class diagram. A state chart in objectoriented analysis plays the same role as the state diagram in procedure-oriented analysis. This means that for the class diagram of Figure 10.7, we need to have a four-state chart.

10. 28

10-3 DESIGN PHASE

The design phase defines how the system will accomplish what was defined in the analysis phase. In the design phase, all components of the system are defined.

10. 29

Procedure-oriented design
In procedure-oriented design we have both procedures and data to design. In procedure-oriented design, the whole system is divided into a set of procedures or modules.

10. 30

Structure charts A common tool for illustrating the relations between modules in procedure-oriented design is a structure chart. For example, the elevator system whose state diagram is shown in Figure 10.5 can be designed as a set of modules shown in the structure chart in Figure 10.8.

Figure 10.8 A structure chart

10. 31

Modularity Modularity means breaking a large project into smaller parts that can be understood and handled easily. The structure chart discussed in the previous section shows the modularity in the elevator system. There are two main concerns when a system is divided into modules: coupling and cohesion. Coupling is a measure of how tightly two modules are bound to each other.

Coupling between modules in a software system must be minimized.

10. 32

Another issue in modularity is cohesion. Cohesion is a measure of how closely the modules in a system are related. We need to have maximum possible cohesion between modules in a software system.

i
Cohesion between modules in a software system must be maximized.

10. 33

Object-oriented design
In object-oriented design the design phase continues by elaborating the details of classes. As we mentioned in Chapter 9, a class is made of a set of variables (attributes) and a set of methods. The object-oriented design phase lists details of these attributes and methods. Figure 10.9 shows an example of the details of our four classes used in the design of the old-style elevator.

Figure 10.9 An example of classes with attributes and methods

10. 34

10-4 IMPLEMENTATION PHASE

In the waterfall model, after the design phase is completed, the implementation phase can start. In this phase the programmers write the code for the modules in procedureoriented design, or write the program units to implement classes in object-oriented design. There are several issues we need to mention in each case.

10. 35

Choice of language
In a procedure-oriented development, the project team needs to choose a language or a set of languages from among the procedural languages discussed in Chapter 10. Although some languages like C++ are considered to be both a procedural and an object-oriented languagenormally an implementation uses a purely procedural language such as C. In the object-oriented case, both C++ and Java are common.

10. 36

Software quality
The quality of software created at the implementation phase is a very important issue. A software system of high quality is one that satisfies the users requirements, meets the operating standards of the organization, and runs efficiently on the hardware for which it was developed. However, if we want to achieve a software system of high quality, we must be able to define some attributes of quality.

10. 37

Software quality factors Software quality can be divided into three broad measures: operability, maintainability and transferability. Each of these measures can be further broken down as shown in Figure 10.10.

Figure 10.10 Quality factors

10. 38

10-5 TESTING PHASE

The goal of the testing phase is to find errors, which means that a good testing strategy is the one that finds most errors. There are two types of testing: glass-box and black-box (Figure 10.11).

Figure 10.11 Software testing

10. 39

Glass-box testing
Glass-box testing (or white-box testing) is based on knowing the internal structure of the software. The testing goal is to determine whether all components of the software do what they are designed for. Glass-box testing assumes that the tester knows everything about the software. In this case, the software is like a glass box in which everything inside the box is visible. Glass-box testing is done by the software engineer or a dedicated team. Several testing methodologies have been designed in the past. We briefly discuss two of them: basis path testing and control structure testing.
10. 40

Basis path testing Basis path testing was proposed by Tom McCabe. This method creates a set of test cases that executes every statement in the software at least once.

i
Basis path testing is a method in which each statement in the software is executed at least once.

10. 41

Example 10.1 To give the idea of basis path testing and finding the independent paths in part of a program, assume that a system is made up of only one program and that the program is only a single loop with the UML diagram shown in Figure 10.12.

Figure 10.12 An example of basis path testing

10. 42

Control structure testing Control structure testing is more comprehensive than basis path testing and includes it. This method uses different categories of tests that are listed below. Condition testing Data flow testing Loop testing

10. 43

Black-box testing
Black box testing gets its name from the concept of testing software without knowing what is inside it and without knowing how it works. In other words, the software is like a black box into which the tester cannot see. Black-box testing tests the functionality of the software in terms of what the software is supposed to accomplish, such as its inputs and outputs.

10. 44

Exhaustive testing The best black-box test method is to test the software for all possible values in the input domain. However, in complex software the input domain is so huge that it is often impractical to do so.

Random testing In random testing, a subset of values in the input domain is selected for testing. It is very important that the subset be chosen in such a way that the values are distributed over the domain input. The use of random number generators can be very helpful in this case.
10. 45

Boundary-value testing Errors often happen when boundary values are encountered. For example, if a module defines that one of its inputs must be greater than or equal to 100, it is very important that module be tested for the boundary value 100. If the module fails at this boundary value, it is possible that some condition in the modules code such as x 100 is written as x > 100.

10. 46

10-6 DOCUMENTATION
For software to be used properly and maintained efficiently, documentation is needed. Usually, three separate sets of documentation are prepared for software: user documentation system documentation technical documentation

Documentation is an ongoing process.

10. 47

User documentation
To run the software system properly, the users need documentation, traditionally called a user guide, that shows how to use the software step by step. User guides usually contains a tutorial section to guide the user through each feature of the software. a good user guide can be a very powerful marketing tool: the importance of user documentation in marketing cannot be over-emphasized. User guides should be written for both the novice and the expert users, and a software system with good user documentation will definitely increase sales.
10. 48

System documentation
System documentation defines the software itself. It should be written so that the software can be maintained and modified by people other than the original developers. System documentation should exist for all four phases of system development.

10. 49

Technical documentation
Technical documentation describes the installation and the servicing of the software system. Installation documentation defines how the software should be installed on each computer, for example, servers and clients. Service documentation defines how the system should be maintained and updated if necessary.

10. 50