Make your own free website on Tripod.com

CS 615 Software Engineering

Software Lifecycles


Software lifecycle refers to the progression of a software system from development through maintenance and eventually replacement. The software development cycle involves the activities in the production of a software system. Generally the software development cycle can be divided into the following phases:

Each phase has associated activities and products. The focus of this material is to review various approaches to software lifecycles (and their component software development cycles). Each approach has unique characteristics which make it more or less suitable for a particular application domain.


There exists no general agreement on which phases should be included in a software lifecycle or the order in which they occur. In fact, the term software lifecycle is not even agreed upon, with software process being at least one alternative term. However, most software lifecycles are phased processes with clearly identifiable goals, milestones, and tasks.

Software lifecycles that will be reviewed include:


Waterfall Model



Modified Waterfall Model

The waterfall model (and modified waterfall model) are inflexible in the partitioning of the project into distinct phases. However, they generally reflect engineering practice. Software development efforts using these approaches are currently the norm and will probably remain so for some time to come.


Considerable emphasis must be placed on discerning users' needs and requirements prior to the system being built. The identification of users' requirements as early as possible, and the agreement between user and developer with respect to those requirements, often is the deciding factor in the success or failure of a software project. These requirements are documented in the requirements specification, which is used to verify whether subsequent phases are complying with the requirements. Unfortunately specifying users' requirements is very much an art, and as such is extremely difficult. Validation feedback can be used to prevent the appearance of a strong divergence between the system under development and the users' expectations for the delivered system.

Unfortunately, the waterfall lifecycle (and the modified waterfall lifecycle) are inadequate for realistic validation activities. They are exclusively document driven models. The resulting design reality is that only 50% of the design effort occurs during the actual design phase with 1/3 of the design effort occuring during the coding activity! This is topped by the fact that over 16% of the design effort occurs after the system is supposed to be completed! In general the behavior of many individuals in this type of process is opportunistic. The boundaries of phases are indiscriminately crossed with deadlines being somewhat arbitrary.


Prototyping

Also referred to as evolutionary development, prototyping aims to enhance the accuracy of the designer's perception of the user's requirements. Prototyping is based on the idea of developing an initial implementation for user feedback, and then refining this prototype through many versions until an satisfactory system emerges. The specification, development and validation activities are carried out concurrently with rapid feedback across the activities. Generally, prototyping is characterized by the use of very high-level languages, which probably will not be used in the final software implementation but which allow rapid development, and the development of a system with less functionality with respect to quality attributes such as robustness, speed, etc.

Prototyping allows the clarification of users requirements through, particularly, the early development of the user interface. The user can then try out the system, albeit a (sub) system of what will be the final product. This allows the user to provide feedback before a large investment has been made in the development of the wrong system.

There are two types of prototypes:

Experiments with prototyping showed that this approach took 40% less time and resulted in 45% less code; however, it produced code which was not as robust, and therefore more difficult to maintain. Documentation was often sacrificed or done incompletely. The schedule expectations of users and managers tended to be unrealistic especially with respect to throw-away prototypes.


Boehm's spiral model

Need an improved software lifecycle model which can subsume all the generic models discussed so far. Must also satisfy the requirements of management.

Boehm proposed a spiral model where each round of the spiral a) identifies the subproblem which has the highest risk associated with it and b) fins a solution for that problem.


Object-Oriented Analysis

While not strictly a software lifecycle model, object-oriented development employs an object-oriented strategy. The primary activities are: Notice that much of the testing phase and certain aspects of the other phases follow the traditional approaches. The primary difference between object- oriented development and the other development lifecycles, is in the modeling of the system components. Other development lifecycles operate on a separation of events and data, while the object-oriented development encapsulates events with the specific data for which the event is valid.

Object-oriented analysis develops an object-oriented model of the application domain. Object-oriented design develops an object-oriented model of the software system. Object-oriented programming realizes the software design with an object-oriented programming language which supports direct implementation of objects, classes, and inheritance.

There are a wide variety of object-oriented methodologies which have been proposed. Common to almost all of these methodologies are:

These activities tend to be overlapping and in general, parallel.