Setting the Microschedule
It follows that you must coordinate the class method implementation so that the use cases become integrated. The ideal way to organize this phase's activity is to:
1. Plan the order of use-case implementation.
2. Derive the order of class method implementation to meet the use-case implementation plan.
3. Sort out the dependencies and resource leveling of the class method implementation and schedule the implementation of the classes based on the effort and the dependencies.
4. Reset the use-case order to meet the development realities.
5. Review the new use-case order.
6. If it is acceptable, set the microschedule.
If the derived use-case order is not acceptable, go through another iteration. This process is diagrammed in Figure 7.9. The output of the process is the phase micro-schedule and the Svedlow diagram, a cross-tabulation of the use cases and the class methods.
Figure 7.9 Coordination of class development.
As in the previous phases, use the microschedule to coordinate and prioritize order of development. In this phase, it contains the schedule and content of the interim system integrations. As shown in Figure 7.10, the microschedule records the date and contents of the interim system integrations. The Functionality column is used to record any limitations on the functionality of the use case. For example, your team may decide to include a use case, but not all of its scenarios. Of course, in this situation, you need to include the rest of the functionality in a later integration or negotiate it as out of scope for this build.
Figure 7.10 Construction phase microschedule.
FOR FURTHER READING
See Alistar Cockburn's Surviving Object-Oriented Projects, a Manager's Guide published by Addison-Wesley in 1998 for another discussion of managing incremental integrations.
Also as in the other phases, the microschedule is maintained by the development lead. I recommend the microschedule be maintained on your project's Web site as well, so that the most current version is readily available.
The Svedlow diagram is used to derive the class methods that need to be implemented in each system integration. A simplified version of the Svedlow diagram is shown Figure 7.11, and a more elaborate spreadsheet version containing tracking capability is available on the companion Web site. Each row contains one of the system's class methods. The columns list system use cases along with their target integration number from the microschedule. The X's signify which class method is included in each of the integrations.
?igure 7.11 A simplified Svedlow diagram. Each X is an integration number.
During the construction phase, accommodate changes of design, not changes of requirements.
The Svedlow diagram and the microschedule are maintained by the development lead. Update both on at least a weekly basis at the build meeting, discussed in more detail later in the chapter.
Finally, it is important to note that the use of interim integrations and the construction phase microschedule gives you with an unambiguous view of the phase's progress. A class and its methods are complete if and only if the code is successfully tested in system integration. Further, the overall system state of completion can also be determined. The system's progress can be measured by comparing the number of planned use cases to those that test successfully in an integration.
FOR FURTHER READING
A more extensive discussion of the change process may be found in Neal Whitten Managing Software Development Projects, 2nd ed., 1995 or Philip Metzger and John Boddie, Managing a Programming Project, Prentice-Hall, 1996.
Post a comment