Home > Articles > Software Development & Management

  • Print
  • + Share This
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.

  • + Share This
  • 🔖 Save To Your Account