1. 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

2. The Incremental Model

3. 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

4. Evolutionary Models: The Spiral

5. 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).

6. The RAD Model

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

8. 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.

9. Evolutionary Models: Concurrent

10. 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.

11. 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.