CS 615 Software Engineering
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:
- Requirements analysis and specification
- Preliminary design
- Detailed design
- Unit testing
- Integration testing
- System testing
- Installation and Acceptance Testing
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
- Boehm's spiral model
- Object-oriented analysis
- Derived from other engineering processes in 1970.
- Offered a means of making the development process more structured.
- Expresses the interaction between subsequent phases.
- Each phase cascades into the next phase.
- In the original waterfall model, a strict sequentiality was at least implied.
- This meant that one phase had to be completed before the next phase was begun.
- It also did not provide for feedback between phases or for updating/re-definition of earlier phases.
Modified Waterfall Model
- Needed to provide for overlap and feedback between phases.
- Rather than being a simple linear model, it needed to be an iterative model.
- To facilitate the completion of the goals, milestones, and tasks, it is normal to freeze parts of the development after a certain point in the iteration.
- Verification and validation are added.
- Verification checks that the system is correct (building the system right).
- Validation checks that the system meets the users desires (building the right system).
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.
PrototypingAlso 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:
- Exploratory programming: Objective is to work with the user to explore their requirements and deliver a final system. Starts with the parts of the system which are understood, and then evolves as the user proposes new features.
- Throw-away prototyping: Objective is to understand the users' requirements and develop a better requirements definition for the system. Concentrates on poorly understood components.
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 modelNeed 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 AnalysisWhile 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
- Object-oriented design
- Object-oriented programming
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:
- Object identification - system objects and their characteristics and events.
- Object organization - shows how objects are related via "part-of" relationships.
- Object interfaces - shows how objects interact with other objects
These activities tend to be overlapping and in general, parallel.