The Waterfall Model Also known as: classic life cycle, the waterfall model, the linear model Rarely projects are sequential (allows iteration indirectly) Changes cause confusion to project team as it proceeds (-) It is often difficult to state all requirements explicitly (required) (-) Customer must have patience until full iterations are complete – one way (-) It provides a template (+) Still better than haphazard development (+) Best for huge projects

The Incremental Model

Incremental Model Combine linear (applied repetitively) with iterative philosophy in staggered fashion Each linear sequence produces a deliverable “increment” of the software (unlike prototyping) Good when staffing is not available (start with few people). If product is well received, more people added Early versions can be planned to manage technical risk. i.e. if software is created for hardware that does not yet exist.. Work can proceed. Ex: if word processing is creating Deliver basic file management, editing, document production (core product) More sophisticated editing and document production capabilities Spelling and grammar checking (supplementary features) Advanced page layout capability Note: it can incorporate the prototyping paradigm

Evolutionary Models: The Spiral

Spiral Model Evolutionary coupled with iterative nature of prototyping Provides for rapid development of incremental versions of the software Software is developed in series of incremental releases Early versions could be paper model. Later ones, more complete versions Divided into a number of framework activities - task regions. (See picture).

The RAD Model

Evolutionary Models: Prototyping Quick plan communication Modeling Quick design Deployment delivery & feedback Construction of prototype

Prototyping Model Intended to get requirements from the users: great for this aspect! Easy programming/modeling language is used (like Access) to create prototype: not good as final product User assumes the prototype is the final product: hard to sell/convince the need for the development effort Good for small projects. In huge projects, it would be harder to coordinate numerous prototypes.

Evolutionary Models: Concurrent

Concurrent Model All activities exist concurrently but reside in different states: For example, early in a project the communication activity has completed its first iteration and exists in the Awaiting changes state. The modeling activity which existed in the None state while initial communication completed, now makes a transition into the Under development state. If, however, the customer indicates that changes in requirements must be made, the modeling activity moves from the Under development state into the Awaiting changes state. It defines a series of events that will trigger transitions from state to state for each of the software engineering activities, actions, or tasks. For example, during early stages of design (a software engineering action that occurs during the modeling activity), an inconsistency in the analysis model is uncovered. This generates the event analysis model correction which will trigger the analysis action from the Done state into the Awaiting changes state.

Still Other Process Models Component based development—the process to apply when reuse is a development objective Formal methods—emphasizes the mathematical specification of requirements AOSD—provides a process and methodological approach for defining, specifying, designing, and constructing aspects Unified Process—a “use-case driven, architecture-centric, iterative and incremental” software process closely aligned with the Unified Modeling Language (UML) – Covered the second part of the semester.