This chapter is from the book
This chapter is from the book
This chapter is from the book
1.6 Planning
The major steps involved with planning an architecture-centric software project are summarized in Figure 1.2.
){kind=link}
Figure 1.2 Project Planning.
Project planning starts when a first set of requirements is defined and ends with the software development plan. Project planning happens in parallel with the design of the software architecture in what I call the high-level design phase of the project. It will also happen before the development of each incremental release. The project manager works with and manages a small architecture design team during the high-level design phase. The chief architect is the technical leader of the design team. The project manager, along with the design team, contributes to the global analysis. The project manager focuses more on organizational influencing factors, while the architects focus more on product and technological factors.
The project manager starts developing top-down schedule estimates in order to get a feel for the scope of the development that will be required to implement the architecture. Once the module view of the software architecture is defined, you can begin putting together bottom-up estimates for all the components of the architecture that will need to be developed. If possible, the members of the anticipated development team will develop the bottom-up estimates. When the architecture is described enough, you will schedule an architecture evaluation review, using both internal and external reviewers. You will keep track of the progress of the high-level design phase so that it is completed in a time frame consistent with the rules of thumb I suggest in Chapter 2.
As project manager you will begin release planning, based on the set of requirements, the bottom-up estimates, and the project milestones that should be reached. You will describe release feature content and define engineering releases and incremental builds within a build plan. You will be making key decisions with the chief architect concerning the technologies needed to implement the architecture.
Global analysis, the architecture design, and the architecture evaluation will help to identify the risks associated with implementing the architecture. As project manager you will further analyze these risks, propose possible risk mitigation actions, and identify project goals and strategies.
In addition to the architecture design specification, the other primary artifact resulting from the high-level design phase is the software development plan (SDP). The SDP contains the schedules and staffing plans for implementing the product. You will update the SDP for each successive release increment. The SDP will identify risk mitigation actions as project tasks. The SDP information is typically used for a management gate review at the end of the high-level design phase, prior to the beginning of development. Management is interested in learning how long the development will take and how much it will cost as an engineering investment. Depending on the results of the review, you may need to modify the SDP, which may also mean changing the architecture design. For example, if the required size of the proposed development team cannot be staffed, the SDP may need to extend the schedule or the architecture may need to be simplified to require less implementation. Clearly, you could also simplify the requirements. Project planning is a set of trade-offs that hopefully will result in a plan that can be staffed within an acceptable schedule, set of features, and quality level.