Depending on your point of
view, 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.
First, 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. |
Lastly, there is some
construction work going on
that is not directly related
to the solution, but is
related to the needs of the
lifecycle. 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. These four
areas started off with
strategy documents, which
were further developed into
lower level plans. Now any
supporting material will be
constructed in this current
phase so that it will be
ready to be tested and
executed in the rest of the
lifecycle. It is too late,
for instance, to be creating
training content in the
Implementation Phase. You
need to execute training at
that point. The training
needs to be created now and
tested in the Test Phase,
perhaps through an initial
pilot class.
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.
431.0 Validate Standards and
Guidelines
433.0 Construct the Solution
434.0 Unit Test the
Components
435.0 Review the Components
436.0 Construct Support
Documentation
437.0 Construct Misc
Elements of Solution
438.0 Re-plan for the
Remainder of the Project
439.0 Obtain Approval to
Proceed
Supporting Templates
