1
SOFTWARE DEVELOPMENT
Phases & Process Model
Software Processes
Waterfall Model
Project Management Process
Role of Metrics and Measurement
Software Quality
Unit 2
Software Development
Learning Objectives
After reading this unit, you should appreciate the following:
- Phases & Process Model
- Software Processes
- Waterfall Model
- Project Management Process
- Role of Metrics & Measurement
- Software Quality
Top
Phases & Process Model
From the inception of an idea for a software system, until it is implemented and delivered to a customer, and even after that, the system undergoes gradual development and evolution. The software is said to have a life cycle composed of several phases. Each of these phases results in the development of either a part of the system or something associated with the system, such as a test plan or a user manual. In the traditional life cycle model, called the “waterfall model”, each phase has well-defined starting and ending points, with clearly identifiable deliverables to the next phase. In practice, it is rarely so simple.
Various process models have been proposed for developing software. In fact, each organization that follows a process has its own version. The different processes can have different activities. However, in general, we can say that any problem solving in software must consist of these activities: requirement specification for understanding and clearly stating the problem, design for deciding a plan for a solution, coding for implementing the planned solution, and testing for verifying the programs. For small problems, these activities may not be done explicitly, the start and end boundaries of these activities may not be clearly defined, and no written record of the activities may be kept. However, for large systems, where the problem-solving activity may last a couple of years and where many people are involved in development, performing these activities implicitly without proper documentation and representation will clearly not work, and each of these four problem solving activities has to be done formally. In fact, for large systems, each activity can itself be extremely complex, and methodologies and procedures are needed to perform it efficiently and correctly. Each of these activities is a major task for large software projects.
Requirements Analysis and Specification
Requirements analysis is usually the first phase of a large-scale software development project. It is undertaken after a feasibility study has been performed to define the precise costs and benefits of a software system. The purpose of this phase is to identify and document the exact requirements for the system. Such study may be performed by the customer, the developer, a marketing organization, or any combination of the three. In cases where the requirements are not clear – e.g. for a system that has never been done before – much interaction is required between the user and the developer. The requirements at this stage are in end-user terms. Various software engineering methodologies advocate that this phase must also produce user manuals and system test plans.
There are two major activities in this phase: problem understanding or analysis and requirement specification. In problem analysis, the analyst has to understand the problem and its context. Such analysis typically requires a thorough understanding of the existing system, parts of which have to be automated. A clear understanding is needed of the important data entities in the system, major centers where action is taken, the purpose of the different actions that are performed, and the inputs and outputs. This requires interacting with clients and end users, as well as studying the existing manuals and procedures. With the analysis of the current system, the analyst can understand the reasons for automation and what affects the automated system might have.
Understanding the existing system is usually just the starting activity in problem analysis, and it is relatively simple. The goal of this activity is to understand the requirements of the new system that is to be developed. Understanding the properties of a system that does not exist is more difficult and requires creative thinking. The problem is more complex because an automated system offers possibilities that do not exist otherwise. Consequently, even the client may not really know the needs of the system. The analyst has to make the client aware of the new possibilities, thus helping both, client and analyst, determine the requirements for the new system.
Once the problem is analyzed and the essentials understood, the requirements must be specified in the requirement specification document. For requirement specification in the form of a document, some specification language has to be selected (e.g., English, regular expressions, tables, or a combination of these). The requirements document must specify all functional and performance requirements; the formats of inputs and outputs; and all design constraints that exist due to political, economic, environmental, and security reasons. In other words, besides the functionality required from the system, all the factors that may affect the design and proper functioning of the system should be specified in the requirements document. A preliminary user manual that describes all the major user interfaces, frequently, forms a part of the requirements document.
Software Design and Specification
Once the requirements for a system have been documented, software engineers design a software system to meet them. This phase is sometimes split into two sub-phases: architectural or high level design and detailed design. High-level design deals with the overall module structure and organization, rather than the details of the modules. The high-level design is refined by designing each module in detail (detail design).
Separating the requirements analysis phase from the design phase is an instance of a fundamental “what/how” dichotomy that we encounter, quite often, in computer science. The general principle involves making a clear distinction between what the problem is and how to solve the problem. In this case, the requirements phase attempts to specify what the problem is. There are, usually, many ways the requirements may be met, including some solutions that do not involve the use of computers at all. The purpose of the design phase is to specify a particular software system that will meet the stated requirements. Again, there are usually many ways to build the specified system. In the coding phase, which follows the design phase, a particular system is coded to meet the design specification. We will see many other instances of the what/how dichotomy throughout the book.
During detailed design, the internal logic of each of the modules specified in system design is decided. During this phase, further details of the data structures and algorithmic design of each of the modules is specified. The logic of a module is usually specified in a high-level design description language, which is independent of the target language in which the software will eventually be implemented.
In system design, the focus is on identifying the modules, whereas during detailed design, the focus is on designing the logic for each of the modules. In other words, in system design, the attention is on what components are needed, while in detailed design how the components can be implemented in software is the issue. A design methodology is a systematic approach to create a design by application of a set of techniques and guidelines. Most methodologies focus on system design.
Coding and Module Testing
This is the phase that produces the actual code that will be delivered to the customer as the running system. The other phases of the life cycle may also develop code, such as prototypes, tests, and test drivers, but these are for use by the developer. Individual modules developed in this phase are also tested before delivered to the next phase.
The coding phase affects both testing and maintenance profoundly. Well-written code can reduce the testing and maintenance effort. Because the testing and maintenance costs of software are much higher than the coding cost, the goal of coding should be to reduce the testing and maintenance effort. Hence, during coding, the focus should be on developing programs that are easy to read and understand, and not simply on developing programs that are easy to write. Simplicity and clarity should be striving for during the coding phase.
An important concept that helps the understandability of programs is structured programming. The goal of structured programming is to linearize the control flow in the program. That is, the program text should be organized as a sequence of statements, and during execution, the statements are executed in the sequence given in the program. For structured programming, a few single-entry-single-exit constructs should be used. These constructs include selection (if-then-else) and iteration (while-do, repeat-until, etc.). With these constructs, it is possible to construct a program as a sequence of single-entry-single-exit constructs.
Integration and System Testing
All the modules that have been developed before and tested individually are put together integrated in this phase and tested as a whole system.
The starting point of testing is unit testing. In this, a module is tested separately and is often performed by the coder himself simultaneously along with the coding of the module. The purpose is to exercise the different parts of the module code to detect coding errors. After this, the modules are gradually integrated into subsystems, which are then integrated to eventually form the entire system. During integration of modules, integration testing is performed to detect design errors by focusing on testing the interconnection between modules.
After the system is put together, system testing is performed. Here the system is tested against the system requirements to see if all the requirements are met and if the system performs as specified by the requirements. Finally, acceptance testing is performed to demonstrate to the client, on the real-life data of the client, the operation of the system.
Testing is an extremely critical and time-consuming activity. It requires proper planning of the overall testing process. Frequently the testing process starts with a test plan that identifies all the testing-related activities that must be performed and specifies the schedule, allocates the resources, and specifies guidelines for testing. The test plan specifies conditions that should be tested, different units to be tested, and the manner in which modules will be integrated together. Then for different test units, a test case specification document is produced, which lists all the different test cases, together with the expected outputs. During the testing of the unit, the specified test cases are executed and the actual result compared with the expected output. The final output of the testing phase is the test report and the error report, or a set of such reports (one for each unit tested). Each test report contains the set of test cases and the result of executing the code with these test cases. The error report describes the errors encountered and the action taken to remove the errors.
Delivery and Maintenance
Once the system passes all the tests, it is delivered to the customer and enters the maintenance phase. Any modifications made to the system after initial delivery is usually attributed to this phase.
Student Activity 2.1
Before reading the next section, answer the following questions.
1.Name different types of phases.
2.Describe requirement analysis phase.
If your answers are correct, then proceed to the next section.
Top
Software Processes
The concept of process is the main step in the software engineering approach. The process means "a particular method of doing something, generally involving a number of steps or operations." In software engineering, the phrase software process refers to the method of developing software.
Software process teaches us how we can manage our planning, according to the constraints and boundaries. A software process is a set of activities, together with ordering constraints among them, such that if the activities are performed properly and in accordance with the ordering constraints, the desired result is produced. The desired result is, as stated earlier, high-quality software at low cost. Clearly, if a process does not scale up (i.e., cannot handle large software projects) or cannot produce good-quality software (i.e., good-quality software is not the outcome) is not a suitable process.
In an organization, whose major business is software development, there are typically many processes executing simultaneously. Many of these do not concern software engineering, though they do impact software development. These could be considered non-software engineering process models. Business process models, social process models, and training models, are all examples of processes that come under this. These processes also affect the software development activity but are beyond the purview of software engineering.
The process that deals with the technical and management issues of software development is called a software process. Clearly, many different types of activities need to be performed to develop software. As we have seen earlier, a software development project must have at least development activities and project management activities. All these activities together comprise the software process.
As different type of activities are being performed, which are frequently done by different people, it is better to view the software process as consisting of many in component processes, each consisting of a certain type of activity. Each of these component processes typically has a different objective, though these processes obviously cooperate with each other to satisfy the overall software engineering objective.
Processes, Projects, and Products
A software process, as mentioned earlier, specifies a method of developing software. A software project, on the other hand, is a development project in which a software process is used. Software products are the outcomes of a software project. Each software development project starts with some needs and (hopefully) ends with some software that satisfies those needs. A software process specifies the abstract set of activities that should be performed to go from user needs to the final product. The actual act of executing the activities for some specific user needs is a software project. And all the outputs that are produced while the activities are being executed are the products (one of which is the final software). One can view the software process as an abstract type, and each project is done using that process as an instance of this type. In other words, there can be many projects for a process (i.e., many projects can be done using a process), and there can be many products produced in a project. This relationship is shown in Figure 2.1.
Figure 2.1: Processes, projects, and products
The sequence of activities specified by the process is typically at an abstract level because they have to be usable for a wide range of projects. Hence, "implementing" them in a project is not straightforward. To clarify this, let us take the example of traveling. A process for traveling to a destination will be something like this: Set objectives for the travel (tourism, business, meeting friends, etc.), determine the optimal means of traveling (this will depend on the objective), if driving is best determine what type of vehicle is most desired (car, truck, or camper), get a detailed map to reach the destination, plan details of the trip, get sufficient money, rent the car, etc. If flying to the destination is best, then book flights, reserve a car at the destination if needed, etc. In a sense, the process provides a "checklist," with an ordering constraint (e.g., renting a car as a first step is suboptimal). If one has to go from New York to Orlando (a specific project), then even with this process, a considerable effort is required to reach Orlando. And this effort is not all passive; one has to be alert and active to achieve this goal (e.g., preparing a map and following the map are not passive or trivial tasks).
Overall, the process specifies activities at an abstract level that are not project- specific. It is a generic set of activities that does not provide a detailed roadmap for a particular project. The detailed roadmap for a particular project is the project plan that specifies what specific activities to perform for this particular project, when, and how to ensure that the project progresses smoothly. In our travel example, the project plan to go from New York to Orlando will be the detailed marked map showing the route, with other details like plans for night halts, getting gas, and breaks.