Iterative Planning

(in a nutshell)
 Needs
• plan what to do next iteration
• track requirements
• organise project artifacts (e.g. UML documents)
 Ranking Requirements
• risk
• technical complexity

• uncertainty of effort

• poor specs

• coverage
• aim to touch on all major parts of the system in early iterations

• criticality
• functions of high value to the project should be (at least partially) implemented as early as
possible, regardless of risk

• think about the impact of a use case or function upon other areas

• e.g. Start-up and Shut-down use cases may be low-value in isolation, but usually need to
be partially implemented for other cases’ sake
 Example
Rank Requirement Comment
Enrol on Course scores high in all 3 areas; pervasive
High Networking low risk but pervasive

Add Assessment Item low risk but implementation needed before other
Medium ... cases can be built and tested

Edit Course Details easy to implement, minimal impact on other

Low ... areas of build

notice that we rank both use cases (Enrol on Course) and other high-level requirements (Networking)
 Ranking Project Risks

Risk Prob. Impact Mitigation

Types of association between courses High High Maximise flexibility in the
and their pre-requisites might not all be number and nature of
known by time of release. associations until pinned down.

Delayed availability of developers Medium High Hire temporary developers.

currently working on other projects. Organise teams and pairs to
avoid latecomers working in
isolation.
...
 Plan Adaptively
• in detail just enough for the next iteration

• you know what the overall goals and deadlines are, and
try to retain flexibility in the route to these

• but don’t leave too much to be done too late!

• for large use cases it is sometimes a good idea to tackle

a happy path first, then expand functionality

• keep a log of your progress compared to your plan

• if they differ, briefly note why

 Your Group Project
• Develop over 4 iterations:

• each approximately 2 weeks long

• will need to submit a set of deliverables at the end of

each iteration:

• e.g. “2 fully dressed use cases, 5 brief use cases, ...”

• but you should plan to do more each iteration in

order to stay on target for completion

• e.g. analyse more use cases, try out some code, try
out UI ideas, ...
 Example Plan
• “In the next iteration the group plans to:

• identify all primary users and their goals

• analyse the “Enrol on a Course” and “Add Course Offering” use cases, for each
producing:

• full use case description

• sequence diagram

• UI prototype sketch

• analyse networking requirements for the system

• to be recorded in Special Requirements section in the Vision Document

• analyse 5 further use cases: view class list, add assessment item (, ...), recording a
brief use case description and UI prototype sketch for each.”

• ...and so on.
 Summary
• in iterative development we can prioritise tasks
by risk, coverage and criticality

• try to avoid detailed planning too far ahead

• but don’t get caught out

• use common sense!

 References
• content based on Chapter 36 of Applying UML & Patterns
(2nd Edition), (Larman 2003)