This chapter is from the book
This chapter is from the book
This chapter is from the book
3.2 Planning Phases
In order to create an effective planning process, you must recognize the phases that every project goes through, whether explicitly or implicitly. A planning strategy that explicitly recognizes each of these phases will do a much better job of ensuring phase integrity. This means that planning gets done at the right time by the right people.
The following are the logical phases that software planning should follow. These serve as the model on which this book is based:
-
Sales Phase
-
Envisioning Phase
-
Analysis Phase
-
Design Phase
-
Architecture Phase
-
Development Phase
-
Testing Phase
-
Deployment Phase
-
Training Phase
-
Maintenance Phase
Sales Phase
The first discussions occur during this phase, normally between a sales representative or other point of initial contact and a client manager. Enough of the business need is discussed to determine that there may be overlap between the client need and the firm's core competence.
Envisioning Phase
During the envisioning phase, a project manager, business analysts, and engineers typically conduct a high-level exploration of the business need that has been identified. A Vision Document is usually prepared to summarize the proposed project.
This phase defines the Why.
Analysis Phase
Once the client approves the Vision Document, a more detailed analysis of the business requirements is undertaken. Analysts interview the business experts and elicit source information. The business specifications are summarized in metadata documents, including narratives, usage scenarios, flow charts, transition diagrams, and others.
Design Phase
Once all the business requirements are understood, and not before, the process of specifying the solution requirements can commence. User interface screens and reports are designed and the operational specifics are detailed.
This phase defines the What.
Architecture Phase
During this phase, the software architect plans the high-level architecture of the solution as well as the database schema and systems infrastructure. The user interfaces are refined and optimized.
This phase defines the How.
Development Phase
The actual development work is performed during this phase. The code is written and unit-tested. This is the production phase that all the previous phases have prepared for.
The working software solution is produced here.
Testing Phase
Once the software is complete, a testing team, working largely from documentation produced during the analysis and design phases, performs system tests independent of and beyond unit-testing.
Deployment Phase
During deployment, the complete hardware and software system is installed at the client site or on a production server. It may undergo additional testing after it is deployed to the production environment.
Training Phase
Sometime just before or after deployment, the users are trained in the use of the completed system.
Maintenance Phase
After the system is in use, any future fixes, enhancements, and required maintenance take place during the maintenance phase. This phase continues as long as the software remains in use.
Notice that this outline doesn't include a “specification” phase as is normally expected. In this book, we intentionally stay away from using that term since it means so many different things to different people. It is generally a combination of tasks from several of the phases identified above. For example, does “specification” mean specifying the requirement or specifying the solution? Too often it means both. It often includes architectural decisions made before the design is complete and design decisions made before the analysis is complete. For that reason, in this book we throw out the specification phase and start fresh without all the baggage that overused term carries with it.
Other Phase Models
Note that some other authors use a less granular series of phases including inception, elaboration, construction, and transition [Kruchten, 1999]. In this model, the inception phase includes envisioning. The elaboration phase includes analysis, design, and architecture. The construction phase is equivalent to the development and testing phases, and the transition phase covers the remainder.
In practice, lumping analysis, design, and architecture activities into one jumbled process is a typical cause of poor specifications. There is some benefit to keeping these explicitly discrete and in the proper logical order.
The phases identified above are logical phases. In practice, there are many different strategies for implementing these phases in the project life-cycle. Some of these life-cycle models are summarized in the next section.