1.5 Architecture-Centric Project Management
I provide here an overview of how you could manage a software project that has architecture design at the center. Again, the specific sequence of tasks will depend on your software development process. But identifying the advantages and useful outputs of architecture design will help put the tips contained in later chapters of this book into a framework. You will perform many tasks as a project manager that have nothing to do with the design. But, very simply, over the course of managing a project you will need to make certain that you have an architecture design that represents the vision of the product that will be developed. Your software development plan will identify how you will achieve the vision that the architecture represents. As you manage the development, you will be guided by your plan as well as your progress in achieving the architecture. You will need to make many mid-course corrections to your development plan, but hopefully the architecture will remain more constant while it is being implemented.
Figure 1.1 identifies some of the major steps associated with implementing an entire project using an architecture-centric approach. The boxes represent the activities that will generally be done during the project, and the arrows represent some of the outputs that result from the activities and are inputs to other activities. This project management book will cover the period from when market requirements have been defined to when the software is delivered to the first customer. Thus, it does not focus on project management practices for software products that are mostly being maintained rather than developed. The following sections introduce these major and other steps in the project management activities of planning, organizing, implementing, and measuring.
Figure 1.1 Architecture-Centric Project.
Architecture-centric project management starts when an initial set of market requirements has been defined. The project manager and the architecture design team analyze the requirements. They analyze product factors and other influences as part of a global analysis. They analyze risks as part of the risk analysis. The module view of the architecture along with the feature list resulting from the requirements analysis become the basis for the release planning for the incremental development.
Once release planning is complete, a software development plan can be developed that also includes the schedule, estimated development costs, and project organization. The software development plan (SDP) is generally written for the entire project, with more detailed plans and specific tasks for the first incremental release. This document will be revised for each release increment as the build plan is developed in detail for each increment. I suggest keeping the increment duration small, to within eight weeks between releases. Once development starts, beginning with the detailed design of each software component identified within the module view of the architecture, you will be leading and managing the development team. You will use the schedule and organization identified in the software development plan as a guide. Mid-course corrections to the development plan are inevitable, since not everything will go as planned and unexpected events will occur (e.g., illness of a team member).
At the end of the development increment, the software will be released on the date agreed to in the release plan. You will then plan and implement a cycle of increments until the product functionality is sufficient for an initial product. This initial product will be delivered to users, possibly at first within some type of beta testing or for a lead customer. Within release delivery, you will review test results and data, in order to determine if the product quality is adequate for customer delivery. After the first increment is released, you will likely use a system-testing function to perform independent testing on the software while your development team is working on the next increment. You will plan the project so that you have test results available from the prior increment before you release the next increment. This helps improve product quality over time and avoids having to do all the testing and fixing at the end of the project.