Page 531 -

530 Part Four Building and Managing Systems

Programming
During the programming stage, system specifications that were prepared
during the design stage are translated into software program code. Today, many
organizations no longer do their own programming for new systems. Instead,
they purchase the software that meets the requirements for a new system from
external sources such as software packages from a commercial software vendor,
software services from an application service provider, or outsourcing firms
that develop custom application software for their clients (see Section 13.3).

Testing
Exhaustive and thorough testing must be conducted to ascertain whether the
system produces the right results. Testing answers the question, “Will the system
produce the desired results under known conditions?” As Chapter 5 noted, some
companies are starting to use cloud computing services for this work.
The amount of time needed to answer this question has been traditionally
underrated in systems project planning (see Chapter 14). Testing is time-con-
suming: Test data must be carefully prepared, results reviewed, and corrections
made in the system. In some instances, parts of the system may have to be
redesigned. The risks resulting from glossing over this step are enormous.
Testing an information system can be broken down into three types of activi-
ties: unit testing, system testing, and acceptance testing. Unit testing, or program
testing, consists of testing each program separately in the system. It is widely
believed that the purpose of such testing is to guarantee that programs are error-
free, but this goal is realistically impossible. Testing should be viewed instead as a
means of locating errors in programs, focusing on finding all the ways to make a
program fail. Once they are pinpointed, problems can be corrected.
System testing tests the functioning of the information system as a whole. It
tries to determine whether discrete modules will function together as planned
and whether discrepancies exist between the way the system actually works
and the way it was conceived. Among the areas examined are performance
time, capacity for file storage and handling peak loads, recovery and restart
capabilities, and manual procedures.
Acceptance testing provides the final certification that the system is ready
to be used in a production setting. Systems tests are evaluated by users and
reviewed by management. When all parties are satisfied that the new system
meets their standards, the system is formally accepted for installation.
The systems development team works with users to devise a systematic test
plan. The test plan includes all of the preparations for the series of tests we
have just described.
Figure 13.5 shows an example of a test plan. The general condition being
tested is a record change. The documentation consists of a series of test plan
screens maintained on a database (perhaps a PC database) that is ideally suited
to this kind of application.
Conversion is the process of changing from the old system to the new
system. Four main conversion strategies can be employed: the parallel strategy,
the direct cutover strategy, the pilot study strategy, and the phased approach
strategy.
In a parallel strategy, both the old system and its potential replacement
are run together for a time until everyone is assured that the new one func-
tions correctly. This is the safest conversion approach because, in the event of
errors or processing disruptions, the old system can still be used as a backup.
However, this approach is very expensive, and additional staff or resources may
be required to run the extra system.

MIS_13_Ch_13 global.indd 530 1/17/2013 2:31:22 PM