![]() |
||
![]() |
![]() |
|
![]() |
What we haven’t yet done is divide the requirements and use cases into separate releases. Currently, they’re a relatively unstructured list of things that we want the new system to be able to do. The next stage, then, is to start to prioritize these. We can then divide the project into smaller releases.
The original release plan for the mapplet project (totally unaltered from the version that the team used) is shown in Table 5-1.
Release |
Use Case |
Comments |
---|---|---|
1 |
Create AOI for Address | |
Generate Hotel Map for AOI | ||
View Map | ||
Pan/Zoom Map |
Basic |
|
View Hotel Information |
Basic |
|
Create Shapefile | ||
2 |
Display Rollover Information |
Basic |
Pan/Zoom Map |
Progressive disclosure |
|
View Hotel Info |
Multiple hotels found at click coordinates |
|
3 |
Generate Query by Country from Map |
Subsumes functionality of existing mapplet |
Generate Query by City from Map |
Subsumes functionality of existing mapplet |
|
4 |
Check Room Availability |
Anything that requires “XML for Travel” |
Specify Reservation Dates | ||
Set Up Display Filter | ||
Display Rollover Information |
Including availability/rate data |
Of course, it doesn’t get much simpler than that. We’ve simply taken the requirements, broken them down into use cases, and decided which use cases will go in which release.
The release plan isn’t set in stone by any means. We’ll revisit the plan several times as the project continues to take shape. The release plan after the first release is done will look different from this version. We’ll evolve the requirements as the software gets partially completed, and our estimates should become more accurate the further we progress in the project.
The planning is done in an iterative, incremental, feature-driven, model-driven manner:
It’s iterative because each release is broken down into smaller, fixed-size planning iterations.
It’s incremental because each release builds incrementally on top of the previous release.
It’s feature driven because we’re deriving the plan from specific features that we want to see delivered. (In the same sense, it’s use case driven because we’re driving the release plan directly from the use cases.)
It’s model driven because the estimates are derived from engineering tasks that we identify via the object model.
![]() |
||
![]() |
![]() |
|
![]() |