430.0 CONSTRUCT PHASE
The Construct Phase is where the "rubber meets the road." This is the point in the project when you actually start to construct the solution. In an IT development project, this is the time to start writing program code. If you followed the LifecycleStep process so far, your construct team has a lot of guidance. They have a complete set of design specifications showing how the application should be structured and organized. They have design specifications for all screens, reports and programs. At this point, then, the project manager should be able to start handing out the various design specifications and the construct team can start to build the solution.
Of course, different projects are going to execute the Analysis and Design Phases in different manners. If some of the design work appeared trivial, it may have been bypassed with the assumption that the construct team will be able to figure it out. For instance, if your organization has a good set of predefined screen layouts and screen standards, perhaps the screens were not formally defined for your solution. The designers may have confidence that the constructors can use the organization standards to easily build the required screens.
Likewise, on many teams, the same people are doing both the design and construct work. In many cases, the team members feel it is redundant to spend too much time on detailed design specifications since they will be the ones receiving the design specs anyway. While the detailed design specifications would be valuable when turning over the work to a separate group of people doing construction, they are not as valuable if the same people are on both the creating and receiving end.
You will note from the outline below that there are a few activities completed during the Construct Phase that are not directly related to programming. The initial unit testing is considered a part of Construct. Even if you have a separate group that will do the detailed testing, the original people constructing each component should also make sure that the component passes a simple unit test. Unit testing validates that the component appears to meet the minimum requirements for features and functionality and does not contain any known and obvious bugs.
The Construct Phase is also where you will create support documentation such as a Disaster Recovery Manual and User's Manual. In essence, these documents are also being "constructed," and so the logical place to create them is the Construction Phase. Depending on the type of document, the support material can also be tested in the Test Phase and then executed or implemented in the Implementation Phase.
There is also some construction work going on that supports the implementation of the solution. For instance, you may need to construct some components to assist in the testing process. It is also likely that you will need some custom programs written to support the data conversion requirements. You may also need to create some training content.
Now that you are in the Construct Phase, you need to understand how you are going to manage all of the components you are creating. The components are stored, organized and tracked using a source code management tool. Although your analysis and design components may need to be managed as well, in the Construct Phase, it is vital to do so. See 430.1 Source Code Management for more details. If you are tracing requirements from the Analysis Phase, you must continue to do so now as well in the Construct Phase. Continuing the tracking process is described in 430.2 Tracing Requirements . Depending on your Implementation Plan, many solutions will be turned over to a support organization after implementation. If you have not done so already, now is the time to make sure that the support organization starts to get involved in the project. See 430.3 Get the Support Organization Involved for more details.
Application Maintenance Manual
Disaster Recovery Manual
Service Level Agreement