Académique Documents
Professionnel Documents
Culture Documents
INDEX
CONTENTS 1.1 INTRODUCTION 1.2 PROCESS DESCRIPTIONS 1.3 LIFE CYCLE MODELS 1.3.1 Build-and-fix model 1.3.2 Waterfall model 1.3.3 V-Shaped Model 1.3.4 Spiral model 1.3.5 Sawtooth model 1.3.6 Sharktooth Model 1.3.7 Unified Software Development Process 1.3.8 Issue-Based Life Cycle Model 1.4 REFERENCE (Figure 1-01) (Figure 1-02) (Figure 1-03) (Figure 1-04) (Figure 1-05) (Figure 1-06) (Figure 1-07) (Figure 1-08) (Figure 1-09) (Figure 1-10)
PAGE NO
2 3 5 7 9 11 13 15 17 19 21
Page |2
Introduction
In the early days of computing, software was developed by many individuals following their own methods. Often, the methods employed some form of code and fix, where the programmer writes some code and then tests it to see how it performs. The programmer then uses the test results to modify or fix the code and tests again. Programmers were able to get by with this type of development for two reasons. First, no better way had been developed, and second, software was not that complex. As software grew more complicated and organizations relied on computers for more of their operations, including finances and even human lives, this laissez faire approach to programming gave way to more disciplined methods. The overall framework in which software is conceived, developed, and maintained is known as the Software Development Life Cycle (SDLC). This chapter discusses the various types of SDLCs, along with their advantages and disadvantages. A life cycle model defines the phases, milestones, deliverables, and evaluation criteria of the software development process. These form the basis of the work breakdown structure (WBS), used for project planning and management.
Page |3
Process Description
Life cycles are usually referred to as models, and define the phases of a software development effort. Simple life cycles may have only three phases, Design, Development, and Maintenance; while complex life cycles may include 20 or more phases. Generally, software life cycles include the phases shown in Figure 1-01.
Requirements Design Implementation Testing Deployment Maintenance
These classic phases are often divided into additional phases to allow better definition and control of the development process. They may also be repeated in an iterative manner, depending on the software complexity and the life cycle model used. Most life cycle phases are identical or similar to the common phases identified above and the following general descriptions will apply across most models. Note that single phases are composed of multiple activities. The Requirements Phase consists of analyzing the problem or need for which the software is being developed. This analysis, a systems engineering activity, develops and specifies requirements, stating what the software must do. In addition to stated requirements, requirements are derived from higher-level requirements and statements of need. In the Design Phase the software structure is defined. Technical approaches are chosen and problems are solved conceptually. This phase is often divided into a Preliminary Design Phase and a Detailed Design Phase. In the preliminary design the initial software architecture is developed. In the detailed design, functional modules are defined, along with user interfaces and interfaces between modules. The Implementation Phase (sometimes called the Development Phase) is where the programming or coding takes place to execute the software design. This
Page |4
phase is often iterative, with unit and integration testing being performed after software build, and the results used in another round of programming. Software is tested for functionality and requirements compliance during the Testing Phase. Testing is often split into three separate phases: Unit Testing, Integration Testing, and Acceptance Testing. The first two may be part of a repeated cycle of coding and testing, while acceptance testing verifies requirements compliance. During the Deployment Phase the software is installed in the intended system and users are trained in its operation. At this point the software development effort is considered complete. The Maintenance Phase includes fixing errors and modifying or upgrading the software to provide additional functionality, such as enabling the software to work with new computing platforms. This phase costs far more in time and effort than the original development. Software maintainers must relearn the original software code to understand what was done, and then make changes to specific modules to produce the desired effect without interfering with rest of the software. Its much easier to change requirements earlier than it is to change software code later. This also means that software should be developed with maintenance in mind.
Page |5
Page |6
Figure 1-02Process interrelationships in the IEEE 1074 standard (UML activity diagram, adapted from [IEEE Std. 1074-1995]]. As suggested by this picture, dependencies among processes and activities are complex and seldom allow a sequential execution of processes.
Page |7
Build-And-Fix Model
The earliest approach Fix it to eliminate any errors that have been detected, to enhance existing functionality, or to add new features Source of difficulties and deficiencies o impossible to predict o impossible to manage The easiest way to develop software The most expensive way for maintenance (i.e., maintenance nightmare) Figure 1-03 showing Build-And-Fix Model
Page |8
The product is implemented without requirements or specifications, or any attempt at design. The developers simply throw code together and rework it as many times as necessary to satisfy the client. It is used in small project and is totally unsatisfactory for products of any reasonable size. It is the worst model for developing a project. The product is built without proper specifications and design steps. In essence, the product is built and modified as many times as possible until it satisfies the client. The cost of using this approach is greater than if specifications are drawn up and a design is carefully developed. Software engineers are strongly discouraged from using this development approach
Page |9
Figure 1-04 The waterfall model of software development is an activity-centered view of the software lifecycle: Software development activities are performed in sequence (UML activity diagram adapted from [Royse, 1970] using IEEE 1074 names; project management and cross-development processes are omitted).
The requirements activities are all completed before the system design activity starts. The goal is to never turn back once an activity is completed. The key feature of his model is the constant verification activity (called verification step by Royse) that ensures that each development activity does not introduce unwanted or deletes mandatory requirements. This model provides a simple (or even simplistic) view of software development that measures progress by the number of tasks that have been completed. The model assumes that software development can be
P a g e | 10
scheduled as a step-by-step process that transforms user needs into code. Figure 104 shows a widely used waterfall model, the DOD 2167A standard life cycle model. The main characteristic of this model is that each development activity is followed by a review. The starting point in this model is the system requirements analysis activity whose goal is to generate unambiguous system requirements. The first review is the System Requirements Review, during which the requirements are reviewed with respect to completeness, consistency, and clarity. The system requirements are the basis for the system design activity, which generates the system design. The system design is reviewed during the System Design Review activity. The system design is baselined once the system design review is successfully completed. The functional baseline serves as the starting point for the software requirements analysis, which creates the software requirements. The software requirements are then reviewed and baselined before serving as a basis for implementation. Implementation starts with the preliminary design followed by the detailed design activity. An important review is the critical design review (CDR). Coding does not occur before the CDR completes successfully.
P a g e | 11
V-model
The V-model is a variation of the waterfall model that makes explicit the dependency between development activities and verification activities. The difference between the waterfall model and the V model is that the latter makes explicit the notion of level of abstraction. All activities from requirements to implementation focus on building more and more detailed representation of the system, whereas all activities from implementation to operation focus on validating the system. Higher levels of abstractions of the V-model deal with the requirements in terms of elicitation and operation. The middle-part of the V-model focuses on mapping the understanding of the problem into software architecture. The lower level of the V-model focuses on details such as the assembly of software components and the coding of new ones. For example, the goal of the Unit Test activity is to validate units against their description in the detailed design. The Component Integration and Test activity validates functional components against the preliminary (or high-level) design.
Figure 1-05 V-Model of software development (UML activity diagram; adapted from [Jensen & Tonies, 1979]). The horizontal object flow denotes the information flow between activities of same abstraction level (e.g., the system requirements analysis results are validated during system and integration test). The V shape layout of the activities was conserved to reflect the original drawing. However, the layout of the activities has no semantics in UML.
P a g e | 12
In many aspects, the waterfall model and its variants are simplistic abstractions of the software development process. The weakness of these models is that they assume that after an activity is finished and reviewed the associated work product can be baselined. Such an idealized model is only appropriate if the specification of the requirements is of high level of assurance and does not change during development. In practice, system development rarely conforms to this ideal model. Changes during an activity often require work of a prior activity to be revisited.
P a g e | 13
P a g e | 14
product is the realization of the cycle, the activity Plan is a management activity preparing for the next cycle. These rounds can be viewed in a polar-coordinate system shown in Figure 106. The first round, Concept of Operation, starts in the upper left quadrant. Subsequent rounds are represented as additional layers on the spiral. The notation allows easily determining the status of the project over time. The distance from the origin is the cost accumulated by the project. The angular coordinate indicates the progress accomplished within each phase. Figure 1-06 Boehms spiral model (Adapted from [Boehm, 1987]). The distance from the origin represents the cost accumulated by the project. The angle from the horizontal represents the type of activity. For example, the project P1 is currently in the risk analysis activity associated with software requirements. The project P2 is in the development of the system product design.
P a g e | 15
Sawtooth model
The life cycle models we described until now emphasize the management of software developers. They do not address the needs of the customer or the user. The waterfall model, the V model and the spiral model all assume that the software requirements will not change drastically during the duration of the project and that it is sufficient to show progress according to the development plan. The drawback of this approach is that the client and the user do not see a running system before the client acceptance test, and thus, cannot correct any requirement problems. Users and implementers, however, have different needs when trying to understand software systems. The sawtooth model [Rowen, 1990] tries to solve this discrepancy by showing the user and software developers perception of the system at different levels of abstractions over time. At the beginning of a project, developers and the client are at the same level of abstraction, namely the requirements of the system as described in the problem statement. During development these points of view differ quite a bit. The user stays at the level of requirements, whereas the developers focus on feasibility. The software development process has to ensure that both points of view meet at the end of the project. The sawtooth model achieves this goal by introducing new activities. The span between these levels of abstractions corresponds to the gap between the users perception of the system and the developers perception of the system. To make sure that these meet at the end, checkpoints are introduced during development. This is usually done by getting the client involved at their level of abstraction. For example, after the requirements and system design phase of an interactive software system, the developers can prototype the screen sequences in terms of the use cases describing the functional requirements. By demonstrating this prototype to the client, the client is able to evaluate quite early in the development whether the prototype satisfies the functional requirements. By repeating this process several times during the development, the manager makes sure that the trajectories intersect several times during the development. This makes it much more probable that they meet at the end of development. The sawtooth model is a modified V-Model that includes these intersections. It is called sawtooth model, because each prototype demonstration results in a tooth. The tip of each tooth is an intersection with the clients level of abstraction.
P a g e | 16
Figure 1-07 shows the sawtooth model for a development project with two prototypes, a revolutionary prototype, and an evolutionary prototype. The revolutionary prototype is often an illustrative prototype because it needs to be built quickly for demonstrating the functionality of the system. There is little intent to deliver this prototype for production use.3 No matter how realistic; this prototype is still only a model of the system. The scenarios demonstrated will be contrived and represent only a small fraction of the required functionality. The short cuts taken to develop a quick version would be a maintenance nightmare if this prototype was promoted to production use. The second prototype is usually an evolutionary prototype. It is shown late in the development where some functionality has already been implemented. The primary distinction between the two types of prototyping is that the revolutionary prototype does not need an overall design whereas the evolutionary prototype does. It is in general counterproductive to insist on complete subsystem decomposition when showing the first prototype to the user. The tasks and activities of the prototype development process in the sawtooth model are shown in Table 12-8.
Figure 1-07 Sawtooth Model with 2 Prototype demonstrations (UML activity diagram). The Client swimlane encloses the activities that are visible to the client, whereas the developer swimlane encloses the activities that are at a lower abstraction level.
P a g e | 17
P a g e | 18
Figure 1-08 Shark tooth model with 2 Prototype demonstrations and 1 review (UML activity diagrams, levels of abstraction are represented with swimlanes). Small teeth reaching the management swimlane are internal reviews involving a prototype demo by the developers for the project manager. Large teeth reaching the client swimlane are prototype demonstrations to the client.
P a g e | 19
P a g e | 20
Figure 1-10 Entity-centered life cycle view of the models of the Unified Process (UML class diagram). The dependencies depict traceability. There are dependencies between all models. Only the dependencies between the use case model and the other models are shown [Jacobson et al., 1999].
P a g e | 21
Figure 1-11 Snapshot of a project issue base (UML object diagram). Issues i1 and i5 have been resolved, whereas all other issues are still open. Dependencies among issues indicate that the resolution of an issue can constraint the alternatives for dependent issues.
P a g e | 22
Reference
[1] Brundick, Bill, Editor, Parametric Cost Estimating Handbook, Chapter 5, Naval Sea Systems Command, fall 1995. [2] Sorensen, Reed, A Comparison of Software Development Methodologies, Crosstalk, January 1995 [3] Whitgift, David, Methods and Tools for Software Configuration Management, 1991, p17. [4] Pressman, Roger S., Understanding Software Engineering Practices, Required at SEI Level 2 Process Maturity, Software Engineering Training Series, Software Engineering Process Group, 30 July 1993. [5] Guidelines for the Successful Acquisition and Management of Software Intensive Systems (GSAM), Version 3, Chapter 5, USAF Software Technology Support Center, May 2000. [6] Boehm, Barry W., A Spiral Model of Software Development and Enhancement, IEEE Computer, May 1988. [7] McKenzie, Charlotte A., MIS327 - Systems Analysis and Design, Course Schedule, 1999. [8] Memorandum from the Undersecretary of Defense for Acquisition Technology and Logistics, Subject: Evolutionary Acquisition and Spiral Development, 12 April 2002. [9] Quann, Eileen, personal communication to Lloyd K. Mosemann, II, September 1995.