Saturday, February 7, 2009

Iterative process models

The specification is developed in conjunction with the software. But this implies contractual problems.
* We can apply these models to any of the generic process models.
* The below models are not completely separate, they're related.


INCREMENTAL DELIVERY
- the software specification, design and implementation are broken down into a series of increments that are each developed in turn
- user requirements of high priority and are developed in early increments
- once increment started the current increment's requirements are frozen (but the later increment's requirements can still evolve)

STAGES:

  1. Define outline requirements
  2. Assign requirements to increments
  3. Design system architecture
  4. Develop system increment
  5. Validate increment
  6. Integrate increment
  7. Validate system
  8. if system incomplete: go to 4.
-> early increments work as prototypes
-> lower risk of overall project failure
-> highest priority services are most tested, because they're the earliest
-> users can use the system immidiately
-> increments should be of right size - difficult

* a variant of this development is XP development ;p



SPIRAL DEVELOPMENT (by Boehm, 1988)
- the development of the system spirals outwards from an initial outline through to the final developed system
- each loop in the spiral represents a phase in the process
- no fixed phases such as specification or design - loops in the spiral are chosen depending on what is required
- risks are explicitly assessed and resolved throughout the process

http://www.ics.uci.edu/~wscacchi/Software-Process/Images/Spiral-Model-Boehm-1987.gif

Each loop stands for different a phase in software process. For example the first loop could be concerned with system feasibility, second with requirements definition, next one with system designand, and so on.. Additionally, each loop consists of FOUR sectors:
  • Objective setting - defining phase objectives; identify constraints on the process; draw up a management plan; identify project risks; define alternative strategies based on that risk;
  • Risk assessment and reduction - detailed analysis of every identified project risk; take steps to reduce the risk;
  • Development and validation - choose development model (e.g. waterfall if main risk is sub-system integration, evolutionary dev. if user interface risks are dominant, ...)
  • Planning - review of the project, decision if we continue to the next cycle, if yes - plans for the next phase
-> explicit recognition of risk
-> we can decide after risk analysis if we want to continue or we should quit