Software engineering is a cognitive reaction to the complexity of software development. It reflects the inevitable need for analysis and planning; reliability and control of risk; and scheduling and coordination when embarking on any complex human endeavor. The planning and organized effort required in developing software products is not unlike the one required in many other activities. As a very simple example, one could compare developing a software product to start on a journey as both begin with preparation. For a journey, the first decision is to decide the destination. Then, before the journey begins, plans are made so as to arrive at the destination within a reasonable time and at an acceptable cost, with an understanding of the length and constraints of the journey. In doing this, one may evaluate alternative routes to the destination, consider environmental conditions, identify and evaluate potential risks or dangers, and so on.
Similarly, developing a successful software solution involves establishing destination or product goal; carefully examining alternative designs for the
system; identifying potential risks; demarcating milestones along the way; identifying what activities must be done in what sequence or those that may be done in parallel; and identifying needed resources — including human resources, financial resources, information, tools, and strategies. More complex endeavors require more complex planning. Pre-tested patterns for performing activities, learned from experience and proven helpful, are universally used in commerce and engineering.
For example, extensive standard protocols are followed when constructing a building. The purpose of the building and justification for construction, its detailed architectural design plans, engineering and structural constraints, budget, and scheduling must be clarified or documented. The building design may be highly original or it may rely on pre-existing design templates and even prefabricated components. Specific design patterns proven to be useful as solution templates for different kinds of problems may be drawn upon during the design stage of the development. In architecture, such design templates vary with the building type and use. Naturally, the stakeholders in the enterprise must be in agreement, from the customer who has contracted for the building to the architect, builder, and municipal agencies that enforce implementation standards like zoning and building codes, etc.
In software engineering, a variety of similar development protocols or models for organizing development effort have also evolved over time. AU these models share certain characteristics. They identify stakeholder goals; specify key activities to be followed according to a certain sequence; work within time constraints; and are based on what has been learned from past experience. For example, at the design stage in software engineering, comparable, successful, reusable design patterns have been recognized, such as those compiled by the so-called Gang of Four (Gamma et al. 1995), just as it has been done in architecture.
Similarly, in software engineering, proven useful practices for solving problems have become a part of the so-called best practice, just as in other fields of engineering. A wide array of strategies for organizing the process of software development has emerged over the past four decades. In a sense, these strategies represent pretested patterns for successful development under different conditions. The strategies share generally similar objectives, but reach their goals by different routes. These development strategies are called software development life-cycle models or process models. They address in an encompassing way the entire, cradle-to-grave, software development process. The notion of a software process model is more general than the related idea of a method or technique, which tends to refer to approaches or tools used in specific stages of the development process.
This chapter introduces and criticises the basic development process and risk reduction models. We observe how these and later models share varying degrees and evolving over time) a number of characteristics, beginning with an emphasis on requirements engineering; the use of a multistage development decomposition derived from the Waterfall Model; documentation requirements; stakeholder involvement; project manage-ment; a consideration of objectives related to economic or business constraints; and implicit or explicit adoption of recognized best practices In development. Their shared characteristics reflect the universal human, technical, and economic constraints under which development operates. For example, recognition of best practices is a recurrent theme in the evolution of every engineering field. In software development these practices include separation of concerns, deferring design decisions when possible, focusing on stakeholder goals, and, more recently, the application of use cases to identify requirements.
The historical evolution of software process models has played a significant role in how models have diversified over time, with later approaches building on earlier ones and technological advances enabling new approaches. The basic life-cycle models that introduced structured planning and development and applied basic engineering principles to the development of software are considered first. The Waterfall Model was the most influential of these. Incremental and iterative models were introduced to reduce the cycle time for development. These include the Evolutionary Development Model and the early Iterative Enhancement Model, which served as a practical method for achieving step-wise refinement. Incremental development facilitated early solution of implementation problems and reduced risk associated with the late integration of components. Investing in any business involves risk, as does in developing a software product.
Thus, the next chapter criticises the basic models that addressed risk in software development, such as the Prototyping and Spiral models. Prototypes are widely used in engineering; examples include rapid, throvv_ away, exploratory, embedded prototypes, etc., as well as techniques such as the use of presentation prototypes, breadboards, mockups, and pilot systems. Benefits of prototyping include obtaining early feedback from users and motivating user involvement, which help to avoid failure of user satisfaction. The most famous risk reduction strategy is Boehm's Spiral Model, which relies heavily on prototyping but is also designed to allow incorporating other process models into its cycles. Each spiral development cycle is like a mini-life cycle, with its deliverables and assurance processes intended to minimize risk. The win-win spiral variant, which uses a stakeholder approach to determine the objectives-constraints-alternatives for each cycle of the spiral, will be considered. Finally, focus shifts to the Cleanroom Model, which is based on incremental development under statistical quality control and formal correctness principles; this model uses statistically based software testing intended to yield a certifiably reliable software product.
At the end of this unit a student should he able to know:
- The characteristics of software development strategies
- Life-Cycle Models
- Risk-Reduction Models