Chapter 12 Construction
This chapter discusses the activities needed to successfully build the information system: programming,
testing, and documenting the system.
When projects fail, it is usually not because the programmers were unable to write the
programs but because the analysis, design, installation, and/or project management were done
Construction is the development of all parts of the system, including the software itself,
documentation, and new operating procedures.
Most professional organization devote more time and more to testing than to writing the
programs in the first place
The first step in programming is assigning models to the programmers
The project manager first groups together class that are related so that each programmer is
working on related classed.
One rule of system development is that the more programmers who are involved in a project,
the longer the system will take to build.
The best strategy is to try to break the project into a series of smaller parts that can function as
independently as possible.
The simplest approach is to have a weekly project meeting to discuss any changes to the system
that have arisen during the past week, or just any issues that have come up
Improve coordination is to create and follow standard that can range from formal rules for
naming files to forms that must be completed when goals are reached to programming
Many project teams set up three “areas” in which programmers can work: a development area,
a testing area, and a production area
At first, programmers access and build files within the development area and then copy them to
the testing are when the programmers are “finished”.
One of the more important things to coordinate is the traceability of the implementation of the
system back to the original requirements.
Each class and method must be associated with an individual requirement or a set of
If a case tool is used during the construction step, it can be very helpful for change control
because many case tools are set up to track the status of programs and help manage
programmers as they work.
In most cases, maintaining coordination is not conceptually complex. It just requires a lot of
attention and discipline to track small details.
1 Chapter 12 Construction
Managing the schedule
It is virtually impossible to develop an exact assessment of the project’s schedule.
A well-done set of time estimate will usually have a 10 percent margin of error by the time you
reach the construction step.
Scope creep occurs when new requirements are added to the project after the system design
Scope creep can be very expensive because changes made late in the SDLC can require much of
the completed system design to be re-done.
Any proposed change during the construction phase must require the approval of the project
manager and should only be done after a quick cost-benefit analysis has been done.
Another common cause is the unnoticed day-by-day slippage in the schedule. One package is a
day later her, another one a day later there, pretty soon these minor delays add up, and the
project is noticeably behind schedule.
A project manager will create a risk assessment that tracks potential risks along with an
evaluation of their likelihood and potential impact.
In object-oriented systems, the temptation is to minimize testing. After all, through the use of
patterns, frameworks, class libraries, and components, much of the system has been tested
previously. Therefore, we should not have to test as much. Right? Wrong!! Testing is more
critical to object-orient system than to systems developed in the past.
Based on encapsulation, polymorphism, inheritance, and reuse, thorough testing is much more
difficult and critical.
The purpose of testing is not to demonstrate that the system is free of error.
If a test fails to find problems with a theory, your confidence in the theory is increased.
However, if a test succeeds in finding a problem, then a theory has been falsified.
The purpose of testing is to uncover as many errors as feasible.
There are four stages of testing: unit tests, integration tests, system tests, and acceptance tests.
Testing and Object-orientation
Most testing techniques have been developed to support non-object-oriented development.
The sheer volume of products that come out of a typical object-oriented development process
has increased the importance of testing in object-oriented development
Encapsulation and information hiding
Encapsulation and information hiding allow process and data to combine to create holistic
Furthermore, they support hiding everything behind a visible interface, which makes testing the
A second issue raised by encapsulation and information hiding is the definition of a “unit” for
A third issue raised is the impact on integration testing. In this case, objects can be aggregated
to form aggregate objects; for example, a car has many parts, or they can be grouped together
to form collaborations.
2 Chapter 12 Construction
Polymorphism and Dynamic binding
Polymorphism and dynamic binding dramatically impact both unit and integration testing.
With polymorphism and dynamic binding, the same method can be implemented in many
Testing individual implantations of methods made no sense.
Through the use of inheritance, bugs can be propagated from a super-class to all of its direct and
indirect sub-classes instantaneously.
Inheritance is a double-edged sword
Each time a class is used in a different context, the class must be tested again
Object-oriented development process and products
Testing is always covered near the end of the SDLC
Each and every product that comes out of object-oriented development process must be tested
It is a lot cheap to catch this type of error back in analysis phase than it is in the implementation
Testing must be placed throughout the life span of a SDLC not just the end
Test plan that defines a series of tests that will be conducted test plan should be developed at
the very beginning of the SDLC and continuously updated as the system evolves.
The test plan should address all products that are created during the development of the
Not all classes are likely to be finished at the same time, so the programmer usually writes stubs
for the unfinished classes to enable the classed around them to be tested.
A stub is placeholder for a class that usually displays a simple test message on the screen or
returns some hardcoded value.
A stub would be written for each of the classes on the other layers that interact with the
problem domain class.
Stubs would contain the minimal interface necessary to be able to test the problem domain
Typically, the methods would display a message on the screen notifying the tester that the
method had been successfully reached.
Unit tests focus on a