CSCI-485: Software Design Lecture 6 Note: Some slides adapted from Software Engineering by Ian Sommerville
Software Processes
Code-and-fix model Software process model used in the early days of computing (i.e., when software development was mainly a single-person usually a scientist task and the problem to be solved usually mathematical in nature was well understood) It has been the source of many difficulties and deficiencies It was ok at the time though, well understood simple applications The failure of this model in the new software age led to the recognition of the so-called software crisis and, in turn, to the birth of software engineering as a discipline
Prescriptive Models Prescriptive models advocate an orderly approach to software engineering That leads to a few questions If prescriptive process models strive for structure and order, are they inappropriate for a software world that thrives on change? Yet, if we reject traditional process models (and the order they imply) and replace them with something less structured, do we make it impossible to achieve coordination and coherence in software work?
Generic software process models The waterfall model Separate and distinct phases of specification and development Evolutionary development Specification, development and validation are interleaved Component-based software engineering The system is assembled from existing components There are many variants of these models, e.g., formal development, where a waterfall-like process is used but the specification is a formal specification that is refined through several stages to an implementable design
Limitations of Models A model is just a model It abstracts away some aspects and highlights others Artificial constraints Compromises with model are often necessary (as with almost everything in SE) Risk of overemphasizing the process The process is not the end in itself Product delivery is
Waterfall model First described by Winston Royce in 1970
Waterfall model problems Inflexible partitioning of the project into distinct stages makes it difficult to respond to changing customer requirements Therefore, this model is only appropriate when the requirements are well-understood and changes will be fairly limited during the design process Few business systems have stable requirements Waterfall model describes a process of stepwise refinement based on hardware engineering models Model derived from the hardware world, presenting a manufacturing view of software development
Waterfall model problems (cont d) Real projects rarely follow the sequential flow that the model proposes. Iteration always occurs and creates problems in the application of the paradigm It is often difficult for the customer to state all requirements explicitly. The classic life cycle requires this and has difficulty accomodating the natural uncertainty that exists at the beginning of many projects The customer must have patience. A working version of the program will not be available until late in the project timespan. A major blunder, if undetected until the working program is reviewed, can be disastrous If this model is pure fiction, why is it still the standard software process? Mainly because of its links to the traditional engineering model and ease of management
Waterfall model problems (cont d) Waterfall delays risk (CLASS DISCUSSION)
Formal systems development Based on the transformation of a mathematical specification through different representations to an executable program Transformations are correctness-preserving so it is straightforward to show that the program conforms to its specification Embodied in the Cleanroom approach (which was originally developed by IBM) to software development Requirements definition Formal specification Formal transformation Integration and system testing
Formal systems development Problems Need for specialised skills and training to apply the technique Difficult to formally specify some aspects of the system such as the user interface Applicability Critical systems especially those where a safety or security case must be made before the system is put into operation Use Outside specialized areas, this process is not widely used
Component-based software engineering Based on systematic reuse where systems are integrated from existing components or COTS (Commercial-off-the-shelf) systems This approach is becoming more important but still limited experience with it
The Manifesto for Agile Software Development (CLASS DISCUSSION) (The Rise and Fall of Waterfall)