Information Technology Reference
In-Depth Information
• Lack of deployable software
• Late discovery of defects
• Lack of project visibility
• Low-quality software
You may say, “Oh, I've heard of all of these risks before. This is
nothing new to me.” However, you can be
aware
of a risk but not nec-
essarily mitigating it. There are more efficient and productive ways to
identify and address risks so that they are no longer a focus on your
projects. Like most practices, it comes down to effective implementa-
tion. In later chapters, using the model of the Integrate button
,
we
show you effective ways to recognize and reduce these risks.
I was on a project in which we built the software on a separate machine
every month or so. When we finally built the software, too close to the
delivery deadline, most team members would stay until the late hours
of the night to pull off another miracle. During this “integration hell,”
we found that we had interfaces that did not work, were missing con-
figuration files, had multiple components providing similar functional-
ity, and had difficulty in merging many changes that were part of the
latest build. This sometimes caused us to miss critical milestones on
the project.
On another project, the software integration build was a manual
process initiated by the IDE. On average, we were manually integrat-
ing software on a weekly basis. In some cases, there were certain
scripts used by the Configuration Management (CM) analyst to build
the software that did not reside in the version control repository. The
lack of automation increased the overhead of running the build.
Because we were not performing the build in a clean environment on a
separate machine, we had no confidence we were building the soft-
ware correctly. The effects of all these were threefold:
• Little or no confidence in whether we could even
build
the
software
