I. iterative development and the unified process (Larman, Ch. 2)
 A. iterative development (2.1)
  1. what is it?
------------------------------------------
            AN ITERATIVE PROCESS

1st 4 weeks:
  Requirements, Design, Implement, Test

2nd 4 weeks:
  Requirements, Design, Implement, Test

3rd 4 weeks:
  Requirements, Design, Implement, Test

etc.


Why do iterative development this way?




------------------------------------------
  2. embracing change
------------------------------------------
        FIGHT OR EMBRACE CHANGE?

Waterfall process fights change:
   - get requirements "right"
   - customer "signs off"
   - get design "right"
   - correctly build the design
   - test vs. requirements
   - deliver system to customer

Not usually successful:
   - users learn what they really want
   - business, technology changes
   - we don't have that much foresight

Better to embrace change
   - plan to learn
   - plan to get feedback from system
   - plan to revise requirements, design

------------------------------------------
------------------------------------------
  ITERATIVE DEVELOPMENT EMBRACES CHANGE

Each iteration:
  - choose small subset of requirements
  - quick design, implement, test

Timeboxing:
  - iterations between 2-6 weeks long
  - fixed length
  - if schedule slips, reduce requirements

------------------------------------------
        does this mean we don't try to plan and anticipate changes, needs?
        what might be the problems if use longer cycles?
        shorter cycles?
------------------------------------------
      RISK DRIVEN DEVELOPMENT

Risk: technical
      schedule
      requirements

Strategy: minimize
          by attacking high risk first

------------------------------------------
        What impact does resolving the risks early have on change?
 B. phases (2.3)
------------------------------------------
     PHASES OF PROJECT

- inception: investigate feasibility
- elaboration: implement core architecture
               mitigate risks
- construction: implement easier parts
- transition: beta testing, deployment


    DISCIPLINES (aka WORKFLOWS)

- Business modeling: objects in domain
- Requirements: use cases, what to do
- Design: architecture, objects,
          databases, networks, ...

------------------------------------------
 C. process customization (2.5)
------------------------------------------
    OPTIONAL ARTIFACTS AND PHASES

Focus on small set of artifacts,
      tailored to project

                             Incep  Elab
Discipline    Artifact        I1    E1..n
=========================================
Business      domain model          start
   Modeling   

Requirements  use-case model start  ref
              vision         start  ref
              suppl. spec.   start  ref
              glossary       start  ref

Design        design model          start
              SW arch. doc.         start
              data model            start
------------------------------------------
 D. algile unified process (2.6)
------------------------------------------
          PROCESS TYPES

Heavy process:
  - many artifacts,
  - bureaucratic,
  - rigid control,
  - elaborate planning for long term.

Predictive process:
  - plans resource allocations in detail
  - over long time span

Adaptive process:



Agile process:


------------------------------------------
 E. questions (2.8)
       Is inception the same as requirements planning?
       Should most of the requirements be defined before starting design?
       Is programming just a translation to code of the design?
       Can we accurately bid a project before elaboration is finished?