Integration and Systems Test.DS_Store__MACOSXIntegration a.docx

Integration and Systems Test/.DS_Store
__MACOSX/Integration and Systems Test/._.DS_Store
Integration and Systems Test/Assignment Instructions.docx
Assignment Integration and System Tests
In this assignment you will develop an iteration test plan for the
CPPS Case Study.
Instructions
Complete the following for the CPPS Case Study and use a
Word file.
1. Develop an iteration test plan (one that applies to and can be
used within a subsystem iteration mini-project).
2. Discuss which types of testing (as identified in Chapter 13)
you would include and why.
3. Estimate how much time will be needed for each type of test.
4. Discuss what types of testing might be combined or
scheduled with an overlap.
Submission Instructions
1. Submit your assignment in Word file and name it like
LastNameFirstNameAssignment.
2. Make certain that you include the above questions with the
answers in your document. Clearly identify the questions and
answers.
3. Include your name and assignment number at the top of your
Word document.
4. Insert any graphics into your Word document. Do not submit
graphics separately.

Your assignment will be graded with the following rubric:
Rubric for Assignments
Points
Content & Development 50%
50/50
Organization 20%
20/20
Format 10%
10/10
Grammar, Punctuation, & Spelling 15%
15/15
Readability & Style 5%
5/5
Timeliness (late deduction 10 points) Optional
Total
100/100
__MACOSX/Integration and Systems Test/._Assignment
Instructions.docx
Integration and Systems Test/Chapter 13.pdf
13 Making the System Operational
Chapter Outline
▪ Testing
▪ Deployment Activities
▪ Planning and Managing Implementation, Testing, and

Deployment
▪ Putting It All Together—RMO Revisited
Learning Objectives
After reading this chapter, you should be able to:
▪ Describe implementation and deployment activities
▪ Describe various types of software tests and explain how and
why each is used
▪ Explain the importance of configuration management, change
management, and source code control to the
implementation, testing, and deployment of a system
▪ List various approaches to data conversion and system
deployment and describe the advantages and
disadvantages of each
▪ Describe training and user support requirements for new and
operational systems
OPENING CASE : Tri-State Heating Oil: Juggling Priorities to
Begin
Operation
It was 8:30 on Monday morning, and Maria Grasso, Kim Song,
Dave Williams, and Rajiv Gupta were about to begin
the weekly project status meeting. Tri-State Heating Oil had
started developing a new scheduling system for customer
orders and service calls five months earlier. The target
completion date was 10 weeks away, but the project was
behind schedule. Early project iterations had accomplished far
less than anticipated because key users had disagreed
on what new system requirements to include and the system

scope was larger than expected.
Maria began the meeting. “We've gained a day or two since
our last meeting due to better-than-expected unit testing
results,” she said. “All the methods developed last week sailed
through unit testing, so we won't need any time this
week to fix errors in that code.”
Kim frowned. “I wouldn't get too cocky just yet,” she said.
“All the nasty surprises in my last project came during
integration testing. We're completing the user interface classes
this week, so we should be able to start integration
testing with the business classes sometime next week.”
Nodding enthusiastically, Dave said, “That's good! We have
to finish testing those user-interface classes as quickly
as possible because we're scheduled to start user training in
three weeks. I need that time to develop the
documentation and training materials and work out the final
training schedule with the users.”
Rajiv looked doubtful. “I'm not sure that we should be trying
to meet our original training schedule with so much of
the system still under development,” he said. “What if
integration testing shows major bugs that require more time to
fix? And what about the unfinished business and database
classes? Can we realistically start training with a system
that's little more than a user interface with half a system behind
it?”
409
409
410
Systems Analysis and Design in a Changing World, 6th Edition

of 11
that's little more than a user interface with half a system behind
it?”
“But we have to start training in three weeks,” Dave replied.
“We contracted for a dozen temporary workers so we
could train our staff on the new system. Half of them are
scheduled to start in two weeks, and the rest two weeks after
that. It's too late to renegotiate their starting dates. We can
extend the time they'll be here, but delaying their starting
date means we'll be paying for people we aren't using.”
Maria spoke up. “I think that Rajiv's concerns are valid,” she
said. “It's not realistic to start training in three weeks
with so little of the system completed and tested. We're at least
five weeks behind schedule, and there's no way we'll
recapture more than four or five days of that during the next
few weeks. I've already looked into rearranging some of
the remaining coding to give priority to the work most critical
to user training. There are a few batch processes that
can be back-burnered for a while. Kim, can you rearrange your
testing plans to handle all the interactive applications
first?”
“I'll have to go back to my office and take another look at the
dependencies among those programs,” Kim replied.
“Offhand, I'd say yes, but I need a few hours to make sure.”
“Okay,” Maria said. “Let's proceed under the assumption that
we can rearrange coding and testing to complete a
usable system for training in five weeks. I'll confirm that by e-
mail later today, as soon as Kim gets back to me. I'll
also schedule a meeting with the CIO to deliver the bad news

about temporary staffing costs.”
After a few moments of silence, Rajiv asked, “So, what else
do we need to be thinking about?”
Well, let's see, “ Maria replied.” “There's hardware delivery
and setup, operating system and DBMS installation,
importing data from the old database, the network upgrade, and
stress testing for the distributed database accesses.”
Rajiv smiled and said to Maria, “You must have been a
juggler in your youth, which would have been good practice
for keeping all these project pieces up in the air. Does
management pay you by the ball?”
Maria chuckled. “I do think of myself as a juggler sometimes.
And if management paid me by the ball, I could retire
as soon as this project is finished!”
Overview
Developing any complex system is inherently difficult. For
example, consider the complexity of manufacturing
automobiles. Tens of thousands of parts must be fabricated or
purchased. Laborers and machines must assemble those
parts into small subcomponents, such as dashboard instruments,
wiring harnesses, and brake assemblies, which are in
turn assembled into larger subcomponents, such as instrument
clusters, engines, and transmissions, which in turn must
be constructed, tested, and passed on to subsequent assembly
steps. The effort, timeliness, cost, and output quality of
each step depend on all the preceding steps.
Implementing and deploying an information system is similar
in many ways; it is a complex production and assembly
process that must use resources efficiently, minimize
construction time, and maximize product quality. But unlike

automobile manufacturing, it isn't done once and then used to
build thousands of similar units. Instead, implementation
and deployment are unique to each project and must match that
project's characteristics.
FIGURE 13-1 Activities of the implementation and deployment
SDLC core
processes
410
411
Page 2 of 11
We have spent many chapters detailing the first four core
processes of the system development life cycle (SDLC).
Those core processes are the primary focus of this text, but
additional processes and activities are needed to complete a
system and put it to regular use. The core processes and
activities covered in this chapter are summarized in Figure 13-1
The fact that we are covering two core processes in a single
chapter doesn't mean that they are simple or unimportant.
Rather, they are complex processes that you will learn about in
detail by completing other courses and reading other
books as well as through on-the-job training and experience.
Our purpose in covering them in this chapter is to round
out our discussion of the SDLC and to show how all the core
processes and activities relate to one another.
As you can see from Figure 13-1, program and testing are the
primary implementation activities. You will learn about
programming in other courses and from other textbooks, so we

won't discuss how software components are constructed
in this textbook. However, we will discuss testing activities in
detail because they are such an integral part of multiple
core processes, including project planning and monitoring,
design, implementation, and deployment.
Testing
Testing activities are a key part of implementation and
deployment activities, although different kinds of tests are used
in each core process. Testing is the process of examining a
component, subsystem, or system to determine its opera
tional characteristics and whether it contains any defects. To
conduct a test, developers must have well-defined
standards for functional and nonfunctional requirements. From
the requirements, test developers develop precise
definitions of expected operational characteristics and what
constitutes a defect. The developers can test software by
reviewing its construction and composition or by designing and
building the software, exercising its function, and
examining the results. If the results indicate a shortcoming or
defect, developers cycle back through earlier
implementation or deployment activities until the shortcoming
is remedied or the defect is eliminated.
Test types, their related core processes, and the defects they
detect and operational characteristics they measure are
summarized in Figure 13-2 Each type of testing is described in
detail later in this section.
FIGURE 13-2 Test types and corresponding operational
characteristics and
defects
411
412

Page 3 of 11
test case a formal description of a starting state, one or more
events to which the software must respond, and the
expected response or ending state
test data a set of starting states and events used to test a
module, group of modules, or entire system
unit test test of an individual method, class, or component
before it is integrated with other software
An important part of developing tests is specifying test cases
and data. A test case is a formal description of the
following:
▪ A starting state
▪ One or more events to which the software must respond
▪ The expected response or ending state
The starting and ending states and the events are represented
by a set of test data. For example, the starting state of a
system may represent a particular set of data, such as the
existence of a particular customer and order for that customer.
The event may be represented by a set of input data items, such
as a customer account number and order number used to
query order status. The expected response may be a described
behavior, such as the display of certain information, or a
specific state of stored data, such as a canceled order.
Preparing test cases and data is a tedious and time-consuming

process. At the component and method levels, every
instruction must be executed at least once. Ensuring that all
instructions are executed during testing is a complex
problem. Fortunately, automated tools based on proven
mathematical techniques are available to generate a complete
set
of test cases. Many test cases repre senting normal and
exceptional processing situations should be prepared for each
scenario.
Unit Testing
Unit testing is the process of testing individual methods,
classes, or components before they are integrated with other
software. The goal of unit testing is to identify and fix as many
errors as possible before modules are combined into
larger software units, such as programs, classes, and
subsystems. Errors become much more difficult and expensive
to
locate and fix when many units are combined.
Few units are designed to operate in isolation. Instead, groups
of units are designed to execute as an integrated
whole. If a method is considered a unit, that method may be
called by messages sent from methods in one or more
classes and may, in turn, send messages to other methods in its
own or other classes. These relationships are easily
seen in a sequence diagram, such as in Figure 13-3, which
duplicates Figure 11-13. For example, when the class
CartItem receives a createCartItem() message, it performs
internal processing and sends messages to six other
methods—findPromo(), getPrice(), findProdItem(),
getDescription(), findlnvItem(), and updateQty()—in three other
classes: PromoOffering, ProductItem, and InventoryItem. 412
Page 4 of 11

classes: PromoOffering, ProductItem, and InventoryItem.
FIGURE 13-3 Sequence diagram for Create new order
driver a method or class developed for unit testing that
simulates the behavior of a method that sends a message
to the method being tested
If the createCartItem() method of CartItem is being tested in
isolation, then two types of testing methods are
required. The first method type is called a driver. A driver
simulates the behavior of a method that sends a message to
the method being tested—in this example, the call by an
OnlineCart object to createCartItem(). A driver module
implements these functions:
412
413
413
Page 5 of 11
implements these functions:
FIGURE 13-4 Driver module to test createCartItem()
▪ Sets the value of input parameters
▪ Calls the tested unit, passing it the input parameters

▪ Accepts return parameters from the tested unit and prints
them, displays them, or tests their values against
expected results and then prints or displays the results
Figure 13-4 shows a simple driver module for testing
createCartItem(). A more complex driver module might use
test data consisting of hundreds or thousands of test inputs and
correct outputs stored in a file or database. The driver
would loop through the test inputs and repeatedly call
createCartItem(), check the return parameter against the
expected value, and print or display warnings of any
discrepancy. Using a driver allows a subordinate method to be
tested before methods that call it have been written.
stub a method or class developed for unit testing that simulates
the behavior of a method that hasn't yet been
written
integration test test of the behavior of a group of methods,
classes, or components
The second type of testing method used to perform unit tests
is called a stub. A stub simulates the behavior of a
method that hasn't yet been written. A unit test of
createCartItem() would require three stub methods: getPrice(),
getDescription(), and updateQty(). Stubs are relatively simple
methods that usually have only a few executable
statements. Each of the stubs used to test createCartItem() can
be implemented as a statement that simply returns a
413
414
Page 6 of 11

getDescription(), and updateQty(). Stubs are relatively simple
methods that usually have only a few executable
statements. Each of the stubs used to test createCartItem() can
be implemented as a statement that simply returns a
constant, regardless of the parameters passed as input. Figure
13-5 shows sample code for each of the three stub
modules.
Integration Testing
An integration test evaluates the behavior of a group of
methods, classes, or components. The purpose of an
integration test is to identify errors that weren't or couldn't be
detected by unit testing. Such errors may result from a
number of problems, including:
▪ Interface incompatibility—For example, one method passes a
parameter of the wrong data type to another
method.
FIGURE 13-5 Stub modules used by createCartItem()
▪ Parameter values—A method is passed or returns a value that
was unexpected, such as a negative number for a
price.
▪ Run-time exceptions—A method generates an error, such as
“out of mem ory” or “file already in use,” due to
conflicting resource needs.
▪ Unexpected state interactions—The states of two or more
objects interact to cause complex failures, as when
an OnlineCart class method operates correctly for all possible
Customer object states except one.

These four problems are some of the most common integration
testing errors, but there are many other possible
errors and causes.
Once an integration error has been detected, the responsibility
for incorrect behavior must be traced to specific
method(s). The person responsible for performing the
integration test is generally also responsible for identifying the
cause of the error. Once the error has been traced to a particular
method, the programmer who wrote the method is
414
415
Page 7 of 11
method(s). The person responsible for performing the
integration test is generally also responsible for identifying the
cause of the error. Once the error has been traced to a particular
method, the programmer who wrote the method is
asked to rewrite it to correct the error.
Integration testing of object-oriented software is very
complex. Because an object-oriented program consists of a set
of interacting objects that can be created or destroyed during
execution, there is no clear hierarchical structure. As a
result, object interactions and control flow are dynamic and
complex.
Additional factors that complicate object-oriented integration
testing include:

▪ Methods can be (and usually are) called by many other
methods, and the calling methods may be distributed
across many classes.
▪ Classes may inherit methods and state variables from other
classes.
▪ The specific method to be called is dynamically determined at
run time based on the number and type of
message parameters.
▪ Objects can retain internal variable values (i.e., the object
state) between calls. The response to two identical
calls may be different due to state changes that result from the
first call or occur between calls.
This combination of factors makes it difficult to determine an
optimal testing order and to predict the behavior of a
group of interacting methods and objects. Thus, developing and
executing an integration testing plan for object-
oriented software is an extremely complex process. Specific
methods and techniques for dealing with that complexity
are well beyond the scope of this textbook. See the Further
Resources section at the end of this chapter for object-
oriented software testing references.
Usability Testing
usability test a test to determine whether a method, class,
subsystem, or system meets user requirements
system test an integration test of an entire system or
independent subsystem
build and smoke test a system test that is performed daily or
several times a week

performance test or stress test an integration and usability test
that determines whether a system or subsystem
can meet time-based performance criteria
response time the desired or maximum allowable time limit for
software response to a query or update
throughput the desired or minimum number of queries and
transactions that must be processed per minute or
hour
A usability test is a test to determine whether a method, class,
subsystem, or system meets user requirements.
Because there are many types of requirements— functional and
nonfunctional—many types of usability tests are
performed at many different times.
The most common type of usability test evaluates functional
requirements and the quality of a user interface. Users
interact with a portion of the system to determine whether it
functions as expected and whether the user interface is
easy to use. Such tests are conducted frequently, as user
interfaces are developed to provide rapid feedback to
developers for improving the interface and correcting any errors
in the underlying software components.
System, Performance, and Stress Testing
A system test is an integration test of the behavior of an entire
system or independent subsystem. Integration testing
is normally associated with the implementation core process,
and system testing is normally associated with the
deployment core process. The line separating integration testing
from system testing is fuzzy, as is the line between
implementation and deployment activities. The important
differences are scope and timing. Integration tests are

415
416
Page 8 of 11
deployment core process. The line separating integration testing
from system testing is fuzzy, as is the line between
implementation and deployment activities. The important
differences are scope and timing. Integration tests are
performed more frequently and on smaller component groups.
System tests are performed less frequently on entire
systems or subsystems.
For a system developed by using a traditional waterfall SDLC,
system testing is concentrated near the end of the
project. In a typical iterative project, some deployment
activities, including system testing activities, are usually
performed at the end of each iteration. In essence, the system is
implemented and deployed incrementally.
System testing may also be performed more frequently. A
build and smoke test is a system test that is typically
performed daily or several times per week. The system is
completely compiled and linked (built), and a battery of
tests is executed to see whether anything malfunctions in an
obvious way (”smokes”).
Build and smoke tests are valuable because they provide rapid
feedback on significant integration problems. Any
problem that occurs during a build and smoke test must result
from software modified or added since the previous
test. Daily testing ensures that errors are found quickly and that

they can be easily tracked to their sources. Less
frequent testing provides rapidly diminishing benefits because
more software has changed and errors are more
difficult to track to their sources.
A performance test, also called a stress test, determines
whether a system or subsystem can meet such time-based
performance criteria as response time or throughput. Response
time requirements specify desired or maximum
allowable time limits for software responses to queries and
updates. Throughput requirements specify the desired or
minimum number of queries and transactions that must be
processed per minute or hour.
Performance tests are complex because they can involve
multiple programs, subsystems, computer systems, and
network infrastructure. They require a large suite of test data to
simulate system operation under normal or maximum
load. Diagnosing and correcting performance test failures are
also complex. Bottlenecks and underperforming
components must first be identified. Corrective actions may
include any combination of the following:
▪ Application software tuning or reimplementation
▪ Hardware, system software, or network reconfiguration
▪ Upgrade or replacement of underperforming components
User Acceptance Testing
user acceptance test a system test performed to determine
whether the system fulfills user requirements
A user acceptance test is a system test to determine whether the
system fulfills user requirements. Acceptance

testing may be performed near the end of the project or it may
be broken down into a series of tests conducted at
the end of each iteration. Acceptance testing is a very formal
activity in most development projects. Details of
acceptance tests are sometimes included in the request for
proposal (RFP) and procurement contract when a new
system is built by or purchased from an external party.
Customer payments to the developers are often tied to
passing specific usability tests.
Deployment Activities
Once a new system has been developed and tested, it must be
placed into operation. Deployment activities (see Figure
13-6) involve many conflicting constraints, including cost, the
need to maintain positive customer relations, the need to
support employees, logistical complexity, and overall risk to the
organization. User acceptance and other test types were
described in the previous section. Multiple types of tests are
often performed concurrently because later project
iterations typically include implementation and deployment
activities. The following sections provide additional details
about deployment activities other than testing.
416
417
Page 9 of 11
about deployment activities other than testing.
Converting and Initializing Data
An operational system requires a fully populated database to
support ongoing processing. For example, online order-

entry and management functions of the RMO CSMS rely on
stored information about products, promotions,
customers, and previous orders. Developers must ensure that
such information is present in the database at the
moment the subsystem becomes operational.
Data needed at system startup can be obtained from these
sources:
▪ Files or databases of a system being replaced
▪ Manual records
▪ Files or databases from other systems in the organization
▪ User feedback during normal system operation
Reusing Existing Databases
Most new information systems replace or augment an existing
manual or automated system. In the simplest form of
data conversion, the old system's database is used directly by
the new system with little or no change to the
database structure. Reusing an existing database is fairly
common because of the difficulty and expense of creating
new databases from scratch, especially when a single database
often supports multiple information systems, as in
today's enterprise resource planning (ERP) systems.
FIGURE 13-6 SDLC deployment activities
Although old databases are commonly reused in new or
upgraded systems, some changes to database content are
usually required. Typical changes include adding new tables,
adding new attributes, and modifying existing tables
or attributes. Modern database management systems (DBMSs)
usually allow database administrators to modify the

structure of a fully populated database. Such simple changes as
adding new attributes or changing attribute types
can be performed entirely by the DBMS.
Reloading Databases
More complex changes to database structure may require
creating an entirely new database and copying and
converting data from the old database to the new database.
Whenever possible, utility programs supplied with the
DBMS are used to copy and convert the data. In more complex
conversions, implementation staff must develop
programs to perform the conversion and transfer some or all of
the data. The upper portion of Figure 13-7 shows
both approaches. In either case, the old database can be
discarded once the conversion and transfer process is
417
418
Page 10 of 11
programs to perform the conversion and transfer some or all of
the data. The upper portion of Figure 13-7 shows
both approaches. In either case, the old database can be
discarded once the conversion and transfer process is
complete.
The middle of Figure 13-7 shows a more complex approach
that uses an export utility, an import utility, and a
temporary data store. This approach might be employed when
the source and target databases employ different
database technologies; no utility exists that can directly
translate from one to the other, but a “neutral” format exists

that can serve as a bridge.
Data from paper records can be entered by using the same
programs being developed for the operational system.
In that case, data-entry programs are usually developed and
tested as early as possible. Initial data entry can be
structured as a user training exercise. For greater efficiency,
data from paper records can also be scanned into an
optical character recognition program and then entered into the
database by using custom-developed conversion
programs or a DBMS import utility.
FIGURE 13-7 Complex data-conversion example
418
Page 11 of 11
In some cases, it may be possible to begin system operation
with a partially or completely empty database. For
example, a customer order-entry system need not have existing
customer information loaded into the database.
Customer information could be added the first time a customer
places an order, based on a dialog between a
telephone order-entry clerk and the customer. Adding data as
they are encountered reduces the complexity of data
conversion but at the expense of slower processing of initial
transactions.
Training Users
Training two classes of users—end users and system
operators—is an essential part of any system deployment
project. End users are people who use the system from day to

day to achieve the system's business purpose. System
operators are people who perform administrative functions and
routine maintenance to keep the system operating.
Figure 13-8 shows representative activities for each role. In
smaller systems, a single person may fill both roles.
The nature of training varies with the target audience.
Training for end users must emphasize hands-on use for
specific business processes or functions, such as order entry,
inventory control, or accounting. If the users aren't
already familiar with those procedures, training must include
them. Widely varying skill and experience levels call for
at least some hands-on training, including practice exercises,
questions and answers, and one-on-one tutorials. Self-
paced training materials can fill some of this need, but complex
systems also require some face-to-face training. If
there is a large number of end users, group training sessions can
be used, and a subset of well-qualified end users can
be trained and then pass their knowledge on to other users.
System operator training can be much less formal when the
operators aren't end users. Experienced computer
operators and administrators can learn most or all they need to
know by self-study. Thus, formal training sessions may
not be required. Also, the relatively small number of system
operators makes one on-one training feasible, if it is
necessary.
Determining the best time to begin formal training can be
difficult. On one hand, users can be trained as parts of the
system are developed and tested, which ensures that they hit the
ground running. On the other hand, starting early can
be frustrating to users and trainers because the system may not
be stable or complete. End users can quickly become
frustrated when using a buggy, crash-prone system with features
and interfaces that are constantly changing.

In an ideal world, training doesn't begin until the interfaces
are finalized and a test version has been installed and
fully debugged. But the typical end-of-project crunch makes
that approach a luxury that is often sacrificed. Instead,
training materials are normally developed as soon as the
interfaces are reasonably stable, and end-user training begins
as soon as possible thereafter. It is much easier to provide
training if system interfaces are completed in early project
iterations.
FIGURE 13-8 Typical activities of end users and system
operators
418
419
419
Page 1 of 11
Documentation and other training materials are usually
developed before formal user training begins.
Documentation can be loosely classified into two types:
system documentation descriptions of system requirements,
architecture, and construction details, as used by
maintenance personnel and future developers
user documentation descriptions of how to interact with and
use the system, as used by end users and system
operators

▪ System documentation—descriptions of system requirements,
architecture, and construction details
▪ User documentation—descriptions of how to interact with and
use the system
Each documentation type is targeted to a different purpose
and audience. The purpose of system documentation is to
support development activities now and in the future. User
documentation is created during implementation. The
development team can't create user documentation earlier
because many details of the user interface and system
operation either haven't yet been determined or may change
during development.
System Documentation
System documentation serves one primary purpose: providing
information to developers and other technical
personnel who will build, maintain, and upgrade the system.
System documentation is generated throughout the
SDLC by each core process and many development activities.
System documentation developed during early
project iterations guides activities in later iterations, and
documen tation developed throughout the SDLC guides
future system maintenance and upgrades.
A system deployed for a customer is a collection of
computing and network hardware, system software, and
application software. Once the system has been developed,
separate descriptions of it, such as written text and
graphical models, are redundant with the system itself. In the
early days of computing, there were few automated
tools to support development of analysis and design models and
even less support for automating the process of
generating application software from those models. Developers
in that era faced a recurring dilemma: how to

minimize the duplicate effort of updating models and
application software while ensuring that the system
documentation was always “in sync” with the actual system. In
the rush to complete and deploy systems and to
maintain and upgrade them over time, system documentation
updates were often neglected and documentation was
frequently lost. As a result, systems were often scrapped
“before their time” because it was cheaper to build a new
system than to fix or upgrade a poorly documented existing
system.
Modern application development tools and methods have
largely solved the system documentation dilemma of
earlier times. A modern integrated development environment
provides automated tools to support all SDLC core
processes. Requirements and design models, such as use case
descriptions, class diagrams, and sequence diagrams,
are developed by using the development tool and stored in a
project library (see Figure 13-9). Changes to one
model are automatically synchronized with related models.
Application software is often generated in part or in its
entirety directly from design models. When application software
is altered at a later date, the development tools can
“reverse engineer” appropriate changes to the models. Due to
these capabilities, system documentation is always
complete and in sync with the deployed system, thus
simplifying future maintenance and upgrades.
User Documentation
User documentation provides ongoing support for end users of
the system. It primarily describes routine operation
of the system, including such functions as data entry, output
generation, and periodic maintenance. Topics typically
covered include:
419

420
420
Page 2 of 11
covered include:
FIGURE 13-9 System documentation stored within Microsoft
Visual Studio
▪ Software startup and shutdown
▪ Keystroke, mouse, or command sequences required to perform
specific functions
▪ Program functions required to implement specific business
procedures (e.g., the steps followed to enter a
new customer order)
▪ Common errors and ways to correct them
For ease of use, user documentation typically includes a table
of contents, a general description of the purpose
and function of the program or system, a glossary, and an index.
User documentation for modern systems is almost always
electronic and is usually an integral part of the
application. Most modern operating systems pro vide standard
facilities to support embedded documentation.
Figure 13-10 shows electronic user documentation of a typical
Windows application. The table of contents can be
displayed by clicking the book-shaped icon in the top toolbar,

and the user can search for specific words or phrases
by using the search tool. The center portion of the display
shows individual pages of user documentation. The
sample page includes embedded glossary definition hyperlinks
(in green) and hyperlinks to other documentation
pages (in blue).
Knowledge of how to use a system is as important an asset as
the system itself. After initial training is completed,
that practical knowledge is stored in the minds of end users. But
experience such as that is difficult to maintain or
effectively transfer to other users. Employee turnover,
reassignment, and other factors make direct person-to-
person transfer of operational knowledge difficult and
uncertain. In contrast, written or electronic documentation is
easier to access and far more permanent.
Developing good user documentation requires special skills
and considerable time and resources. Writing clearly
and concisely, developing effective presentation graphics,
organizing information for easy learning and access, and
communicating effectively with a nontechnical audience are
skills for which there is high demand and limited
supply. Development takes time, and high-quality results are
achieved only with thorough review and testing.
Unfortunately, preparing user documentation is often left to
technicians lacking in one or more necessary skills.
Also, preparation time, review, and testing are often
shortchanged because of schedule overruns and the last-minute
420
421
Page 3 of 11

Unfortunately, preparing user documentation is often left to
technicians lacking in one or more necessary skills.
Also, preparation time, review, and testing are often
shortchanged because of schedule overruns and the last-minute
rush to tie up all the loose ends of implementation.
FIGURE 13-10 Sample Windows Help and Support display
Configuring the Production Environment
Modern applications are built from software components based
on interaction standards, such as Common Object
Request Broker Architecture (CORBA), Simple Object Access
Protocol (SOAP), and Java Platform Enterprise
Edition (Java EE). Each standard defines specific ways in which
components locate and communicate with one
another. Each standard also defines a set of supporting system
software to provide needed services, such as
maintaining component directories, enforcing security
requirements, and encoding and decoding messages across
networks and other transport protocols. The exact system
software, its hardware, and its configuration requirements
vary substantially among the component interaction standards.
Figure 13-11 shows a typical support infrastructure for an
application deployed using Microsoft .NET, a variant of
SOAP. Application software components written in such
programming languages as Visual Basic and C# are stored
on one or more application servers. Other required services
include a Web server for browser-based interfaces, a
database server to manage the database, an Active Directory
server to authenticate users and authorize access to
information and software resources, a router and firewall, and a
server to operate such low-level Internet services as
domain naming (DNS) and Internet address allocation (DHCP).

421
422
422
Page 4 of 11
domain naming (DNS) and Internet address allocation (DHCP).
FIGURE 13-11 Infrastructure and clients of a typical .NET
application
Unless it already exists, all this hardware and system software
infrastructure must be acquired, installed, and
configured before application software can be installed and
tested. In most cases, some or all of the infrastructure will
already exist—to support existing information systems. In that
case, developers work closely with personnel who
administer the existing infrastructure to plan the support for the
new system. In either case, this deployment activity
typically starts early in the project so software components can
be developed, tested, and deployed as they are
developed in later project iterations.
Planning and Managing Implementation, Testing, and
Deployment
The previous sections have discussed the implementation,
testing, and deployment activities in isolation. In this section,
we concentrate on issues that impact all those activities as well
as other core processes, including project planning and
monitoring, analysis, and design. In an iterative development
project, activities from all core processes are integrated

into each iteration and the system is analyzed, designed,
implemented, and deployed incrementally. But how does the
project manager decide which portions of the system will be
worked on in early iterations and which in later iterations?
And how does he or she manage the complexity of so many
models, components, and tests?
Some of these issues were partly addressed in earlier chapters.
But now that you understand implementation, testing,
and deployment activities in depth, you can see that there are
many interdependencies that must be accounted for. These
interdependencies must be fully identified and considered when
developing a workable iteration plan. Furthermore,
automated tools must be utilized to manage each part of the
development project and to ensure maximal coordination
across iterations, core processes, and activities.
422
423
423
424
Page 5 of 11
across iterations, core processes, and activities.
Development Order
One of the most basic decisions to be made about developing a
system is the order in which software components will
be built or acquired, tested, and deployed. Choosing which
portions of the system to implement in which iterations is
difficult, and developers must consider many factors, only some

of which arise from the software requirements. Some
of the other factors discussed in earlier chapters include the
need to validate requirements and design decisions and
the need to minimize project risk by resolving technical and
other risks as early as possible.
A development order can be based directly on the structure of
the system itself and its related issues, such as use
cases, testing, and efficient use of development staff. Several
orders are possible, including:
▪ Input, process, output
▪ Top-down
▪ Bottom-up
Each project must adapt one or a combination of these
approaches to specific project requirements and constraints.
Input, Process, Output Development Order
input, process, output (IPO) development order a development
order that implements input modules first,
process modules next, and output modules last
The input, process, output (IPO) development order is based on
data flow through a system or program.
Programs or modules that obtain external input are developed
first. Programs or modules that process the input
(i.e., transform it into output) are developed next. Programs or
modules that produce output are developed last. The
key issue to analyze is dependency—that is, which classes and
methods capture or generate data that are needed by
other classes or methods? Dependency information is
documented in package diagrams and may also be

documented in a class diagram. Thus, either or both diagram
types can guide implementation order decisions.
For example, the package diagram in Figure 13-12 shows that
the Customer account and Marketing subsystems
don't depend on any of the other subsystems. The Sales
subsystem depends on the Customer account and
Marketing subsystems, and the Order fulfillment and Reporting
subsystems depend on the Sales subsystem.
Data dependency among the packages (subsystems) implies
data dependency among their embedded classes.
Thus, the classes CustomerHandler, Customer, Address,
Account, FamilyLink, Message, Suggestion,
CustPartnerCredit, PromoPartner, Promotion, PromoOffering,
ProductItem, and InventoryItem have no data
dependency on the remaining RMO classes. Under the IPO
development order, those three classes are implemented
first.
The chief advantage of the IPO development order is that it
simplifies testing. Because input programs and
modules are developed first, they can be used to enter test data
for process and output programs and modules. The
IPO development order is also advantageous because important
user interfaces (e.g., data entry routines) are
developed early. User interfaces are more likely to require
change during development than during other portions
of the system, so early development allows for early testing and
user evaluation. If changes are needed, there is still
plenty of time to make them. Early development of user
interfaces also provides a head start for related activities,
such as training users and writing documentation.
A disadvantage of the IPO development order is the late
implementation of outputs. Output programs are useful

for testing process-oriented modules and programs; analysts can
find errors in processing by carefully examining
printed reports or displayed outputs. IPO development defers
such testing until late in the development phase.
However, analysts can usually generate alternate test outputs by
using the query-processing or report-writing
capabilities of a database management system (DBMS). 424
Page 6 of 11
capabilities of a database management system (DBMS).
FIGURE 13-12 Package diagram for the four RMO subsystems
Top-Down and Bottom-Up Development Order
top-down development a development order that implements
top-level modules first
bottom-up development a develop ment order that implements
low-level detailed modules first
The terms top-down and bottom-up have their roots in
traditional structured design and structured programming. A
traditional structured design decomposes software into a series
of modules or functions, which are hierarchically
related to one another. As a visual analogy, consider a typical
organization chart with the president or CEO at the
top. In structured design, a single module (the president or
CEO) controls the entire software program. Modules at
the bottom perform low-level specialized tasks when directed to
do so by a module at the next higher level. Top-
down development begins with the CEO and works downward.

Bottom-up development begins with the detailed
modules at the lowest level and works upward to the CEO.
Top-down and bottom-up program development can also be
applied to object-oriented designs and programs,
although a visual analogy isn't obvious with object-oriented
diagrams. The key issue is method dependency—that
is, which methods call which other methods. Within an object-
oriented subsystem or class, method dependency can
be examined in terms of navigation visibility, as discussed in
Chapters 10 and 11.
424
425
425
Page 7 of 11
be examined in terms of navigation visibility, as discussed in
Chapters 10 and 11.
FIGURE 13-13 Package diagram for a three-layer object-
oriented design
For example, consider the three-layer design of part of the
RMO Order entry subsystem shown in Figure 13-13.
The arrows connecting packages and classes show navigation
visibility requirements. Methods in the view (user
interface) layer call methods in the domain layer, which in turn
call methods in the data access layer. Top-down
implementation would implement the view layer classes and
methods first, the domain layer classes and methods

next, and the data access layer classes and methods last.
Bottom-up implementation would reverse the top-down
implementation order.
425
426
Page 8 of 11
implementation order.
Method dependency is also documented in a sequence
diagram. For example, in Figure 13-3, method dependency
is documented in the left-to-right flow of messages among
objects. Rotating the figure 90 degrees clockwise
creates a top-down and bottom-up visual analogy similar to an
organizational chart. Top-down development would
proceed through CartHandler, Customer, CustomerDA,
OnlineCart, OnlineCartDA, CartItem, CartItemDA, and the
set of classes: PromoOffering, PromoOfferingDA, ProductItem,
ProductItemDA, InventoryItem, and
InventoryItemDA. Bottom-up development would reverse this
order, starting with InventoryItem and
InventoryItemDA and ending with CartHandler.
The primary advantage of top-down development is that there
is always a working version of a program. For
example, top-down development in Figure 13-3 would begin
with a partial or complete version of the CartHandler
class and dummy (or stub) versions of the Customer and
OnlineCart classes. This set of classes forms a complete
program that can be built, deployed, and executed, although at
this point, it wouldn't do very much when executed.

As each method or class is implemented, stubs for the methods
or classes on the next lower level are added. At
every stage of development, the program can be executed and
tested, and its behavior becomes more complex and
realistic as development proceeds.
The primary disadvantage of top-down development order is
that it doesn't use programming personnel very
efficiently at the beginning of software development.
Development has to proceed through two or three levels
before a significant number of classes and methods can be
developed simultaneously. In contrast, bottom-up
development enables many programmers to be put to work
immediately on classes that support a wide variety of
use cases. Unfortunately, bottom-up development also requires
writing a large number of driver methods to test
bottom-level classes and methods, which adds additional
complexity to the implementation and testing process.
Also, the entire system isn't assembled until the topmost classes
are written. Thus, testing for individual use cases
and integration testing are delayed.
Other Development Order Considerations
IPO, top-down, and bottom-up development are only starting
points for creating implementation and iteration
plans. Other factors that must be considered include use case-
driven development, user feedback, training,
documentation, and testing. Use cases deserve special attention
in determining development order because they are
one of the primary bases for dividing a development project into
iterations.
In most projects, developers choose a set of related use cases
for a single iteration and complete analysis, design,
implementation, and deployment activities. Developers choose
which use cases to focus on first based on such

factors as minimizing project risk, efficiently using
nontechnical staff, or deploying some parts of the system
earlier than others. For example, use cases with uncertain
requirements or high technical risks are typically
addressed in early iterations. Addressing uncertain requirements
requires usability and other testing by
nontechnical development staff, and those staff members may
only be available at certain times in the project.
User feedback, training, and documentation all depend
heavily on the user interfaces of the system. Early
implementation of user interfaces enables user training and the
development of user documentation to begin early
in the development process. It also gathers early feedback on
the quality and usability of the interface. Note the
important role that this issue played in the opening case of this
chapter.
Testing is also an important consideration when determining
development order. As individual software
components are constructed, they must be tested. Programmers
must find and correct errors as soon as possible
because they become much harder to find and more expensive to
fix as components are integrated into larger units.
It is important to identify portions of the software that are
susceptible to errors and to identify portions of the
software where errors can pose serious problems that affect the
system as a whole. These portions of the software
must be built and tested early, regardless of where they fit
within the basic approaches of IPO, top-down, or
bottom-up development.
426
427

of 11
bottom-up development.
Source Code Control
source code control system (SCCS) an automated tool for
tracking source code files and controlling changes to
those files
Development teams need tools to help coordinate their
programming tasks. A source code control system (SCCS) is
an automated tool for tracking source code files and controlling
changes to those files. An SCCS stores project source
code files in a repository, and it acts the way a librarian
would—that is, implements check-in and checkout
procedures, tracks which programmer has which files, and
ensures that only authorized users have access to the
repository.
FIGURE 13-14 Project files managed by a source code control
system
A programmer checks out a file in read-only mode when he or
she wants to examine the code without making
changes (e.g., to examine a module's interfaces to other
modules). When a programmer needs to make changes to a
file, he or she checks out the file in read/write mode. The SCCS
allows only one pro grammer to check out a file in
read/write mode. The file must be checked back in before
another programmer can check it out in read/write mode.
Figure 13-14 shows the source code control display of
Microsoft Visual Studio. Various source code files from the

RMO CSS are shown in the display. Some files are currently
checked out by programmers. For each file checked out
in read/write mode, the program lists the programmer who
checked it out, the date and time of checkout, and whether
the copy currently stored in the central repository is the most
current (latest) version.
427
428
Page 10 of 11
the copy currently stored in the central repository is the most
current (latest) version.
An SCCS prevents multiple programmers from updating the
same file at the same time, thus preventing inconsistent
changes to the source code. Source code control is an absolute
necessity when programs are developed by multiple
programmers. It prevents inconsistent changes and automates
coordination among programmers and teams. The
repository also serves as a common facility for backup and
recovery operations.
Packaging, Installing, and Deploying Components
As with the other disciplines discussed in this chapter,
deployment activities are highly interdependent with activities
of the other disciplines. In short, a system or subsystem can't be
deployed until it has been implemented and tested. If
a system or subsystem is large and complex, it is typically
deployed in multiple stages or versions, thus necessitating
some formal method of configuration and change management.
428

Page 11 of 11
some formal method of configuration and change management.
Important issues to consider when planning deployment
include:
▪ Incurring costs of operating both systems in parallel
▪ Detecting and correcting errors in the new system
▪ Potentially disrupting the company and its IS operations
▪ Training personnel and familiarizing customers with new
procedures
Different approaches to deployment represent different trade-
offs among cost, complexity, and risk. The most
commonly used deployment approaches are:
▪ Direct deployment
▪ Parallel deployment
▪ Phased deployment
Each approach has different strengths and weaknesses, and no
one approach is best for all systems. Each approach
is discussed in detail here.
Direct Deployment

direct deployment or immediate cutover a deployment method
that installs a new system, quickly makes it
operational, and immediately turns off any overlapping systems
In a direct deployment, the new system is installed and quickly
made operational, and any overlapping systems
are then turned off. Direct deployment is also sometimes called
immediate cutover. Both systems are concurrently
operated for only a brief time (typically a few days or weeks)
while the new system is being installed and tested.
Figure 13-15 shows a timeline for direct deployment.
The primary advantage of direct deployment is its simplicity.
Because the old and new systems aren't operated in
parallel, there are fewer logistical issues to manage and fewer
resources required. The primary disadvantage of
direct deployment is its risk. Because older systems aren't
operated in parallel, there is no backup in the event that
the new system fails. The magnitude of the risk depends on the
nature of the system, the cost of workarounds in the
event of a system failure, and the cost of system unavailability
or less-than-optimal system function.
Parallel Deployment
parallel deployment a deployment method that operates the old
and the new systems for an extended time
period
In a parallel deployment, the old and new systems are operated
for an extended period of time (typically weeks or
months). Figure 13-16 illustrates the timeline for parallel
deployment. Ideally, the old system continues to operate
until the new system has been thoroughly tested and determined
to be error-free and ready to operate
independently. As a practical matter, the time allocated for

parallel operation is often determined in advance and
limited to minimize the cost of dual operation.
The primary advantage of parallel deployment is relatively
low operational risk. If both systems are operated
completely (i.e., using all data and exercising all functions), the
old system functions as a backup for the new
system. Any failure in the new system can be mitigated by
relying on the old system.
428
429
Page 1 of 12
system. Any failure in the new system can be mitigated by
relying on the old system.
FIGURE 13-15 Direct deployment and cutover
FIGURE 13-16 Parallel deployment and operation
The primary disadvantage of parallel deployment is cost.
During the period of parallel operation, the organization
pays to operate both systems. Extra costs associated with
operating two systems in parallel include:
▪ Hiring temporary personnel or temporarily reassigning
existing personnel
▪ Acquiring additional computing and network capacity
429

430
Page 2 of 12
▪ Acquiring additional computing and network capacity
▪ Increasing managerial and logistical complexity
Parallel operation is generally best when the consequences of
a system failure are severe. Parallel operation
substantially reduces the risk of a system failure through
redundant operation. The risk reduction is especially
important for such “mission critical” applications as customer
service, production control, basic accounting
functions, and most forms of online transaction processing.
Full parallel operation may be impractical for any number of
reasons, including:
▪ Inputs to one system may be unusable by the other, and it may
not be possible to use both types of inputs.
▪ The new system may use the same equipment as the old system
(e.g., com puters, I/O devices, and
networks), and capacity may be insufficient to operate both
systems.
▪ Staffing levels may be insufficient to operate or manage both
systems at the same time.
When full parallel operation isn't possible or feasible, a
partial parallel operation may be employed instead.
Possible modes of partial parallel operation include:

▪ Processing only a subset of input data in one of the two
systems. The subset could be determined by
transaction type, geography, or sampling (e.g., every 10th
transaction).
▪ Performing only a subset of processing functions (e.g.,
updating account history but not printing monthly
bills)
▪ Performing a combination of data and processing function
subsets
Partial parallel operation always entails the risk that
significant errors or problems will go undetected. For
example, parallel operation with partial input increases the risk
that errors associated with untested inputs won't be
discovered.
Phased Deployment
phased deployment a deployment method that installs a new
system and makes It operational in a series of
steps or phases
In a phased deployment, the system is deployed in a series of
steps or phases. Each phase adds components or
functions to the operational system. During each phase, the
system is tested to ensure that it is ready for the next
phase. Phased deployment can be combined with parallel
deployment, particularly when the new system will take
over the operation of multiple existing systems.
FIGURE 13-17 Phased deployment with direct cutover and
parallel operation

430
431
Page 3 of 12
Figure 13-17 shows a phased deployment with direct and
parallel deployment of individual phases. The new
system replaces two existing systems. The deployment is
divided into three phases. The first phase is a direct
replacement of one of the existing systems. The second and
third phases are different parts of a parallel deployment
that replace the other existing system.
The primary advantage of phased deployment is reduced risk
because fail ure of a single phase is less
problematic than failure of an entire system. The primary
disadvantage of phased deployment is increased
complexity. Dividing the deployment into phases creates more
activities and milestones, thus making the entire
process more complex. However, each phase contains a smaller
and more manageable set of activities. If the entire
system is simply too big or complex to install at one time, the
reduced risks of phased deployment outweigh the
increased complexity inherent in managing and coordinating
multiple phases.
Change and Version Control
Though not formal activities of the implementation or
deployment core processes, change and version control are key
parts of managing software development, testing, and
deployment. Medium- and large-scale systems are complex and
constantly changing. Changes occur rapidly during
implementation and more slowly during deployment and after

the
system is in use. System complexity and rapid change create a
host of management problems, particularly for testing
and postdeployment support.
Change and version control tools and processes handle the
complexity associated with testing and supporting a
system through multiple versions. Tools and processes are
typically incorporated into implementation activities from
the beginning and continue throughout the life of a system.
Most organizations use a common set of tools and
procedures for all their systems.
Versioning
Complex systems are developed, installed, and maintained in a
series of versions to simplify testing, deployment,
and support. It isn't unusual to have multiple versions of a
system deployed to end users and yet more versions in
different stages of development. A system version created
during development is called a test version. A test
version contains a well-defined set of features and represents a
concrete step toward final completion of the system.
Test versions provide a static system snapshot and a checkpoint
to evaluate the project's progress.
alpha version a test version that is incomplete but ready for
some level of rigorous integration or usability
testing
An alpha version is a test version that is incomplete but ready
for some level of rigorous integration or usability
testing. Multiple alpha versions may be built depending on the
size and complexity of the system. The lifetime of
an alpha version is typically short—days or weeks.
beta version a test version that is stable enough to be tested by

end users over an extended period of time
A beta version is a test version that is stable enough to be
tested by end users over an extended period of time. A
beta version is produced after one or more alpha versions have
been tested and known problems have been
corrected. End users test beta versions by using them to do real
work. Thus, beta versions must be more complete
and less prone to disastrous failures than alpha versions. Beta
versions are typically tested over a period of weeks
or months.
production release, release version, or production release a
system version that is formally distributed to
users or made operational for long-term use
431
432
Page 4 of 12
users or made operational for long-term use
maintenance release a system update that provides bug fixes
and small changes to existing features
A system version created for long-term release to users is
called a production version, release version, or
production release. A production version is considered a final
product, although software systems are rarely
“finished” in the usual sense of that term. Minor production
releases (sometimes called maintenance releases)
provide bug fixes and small changes to existing features. Major

production releases add significant new
functionality and may be the result of rewriting an older release
from the ground up.
Keeping track of versions is complex. Each version needs to
be uniquely identified for developers, testers, and
users. In applications designed to run under Windows, users
typically view the version information by choosing the
About item from the standard Help menu (see Figure 13-18).
Users seeking support or reporting errors in a beta or
production version use this feature to report the system version
to testers or support personnel.
FIGURE 13-18 About box of a typical Windows application
Controlling multiple versions of the same system requires
sophisticated version control software, which is often
built into development tools or can be obtained through a
separate source code and version control system, as
described later in this chapter. Programmers and support
personnel can extract the current version or any previous
version for execution, testing, or modification. Modifications
are saved under a new version number to protect the
accuracy of the historical snapshot.
Beta and production versions must be stored as long as they
are installed on any servers or user machines. Stored
versions are used to evaluate future bug reports. For example,
when a user reports a bug in version 1.0, support
personnel extract that release from the archive and attempt to
replicate the user's error. Feedback provided to the
user is specific to version 1.0, even if the most recent
production release is a higher-numbered version.
Submitting Error Reports and Change Requests
To manage the risks associated with change, most organizations

adopt formal control procedures for all systems
under development and in operation. Formal controls are
designed to ensure that potential changes are adequately
described, considered, and planned before being implemented
and deployed. Typical change control procedures
432
433
Page 5 of 12
under development and in operation. Formal controls are
designed to ensure that potential changes are adequately
described, considered, and planned before being implemented
and deployed. Typical change control procedures
include these:
▪ Standard reporting methods
▪ Review of requests by a project manager or change control
committee
▪ For operational systems, extensive planning for design and
implementation
Figure 13-19 shows a sample error (bug) report that has been
completed by a tester or system developer. In this
case, error reporting is integrated into the application
development tool and source code control system, which
enables the project manager to centrally manage all reports,
assign reports to specific developers, and track each
report to its resolution.

FIGURE 13-19 Sample error report in Microsoft Visual Studio
Similar tools can be used to report and manage errors and
requests for new features in operational systems. In the
case of new features, the request is usually submitted to a
change control committee that reviews the change
request to assess the impact on existing computer hardware and
software, system performance and availability,
security, and operating budget. Approved changes are added to
the list of pending changes for budgeting,
scheduling, planning, and implementation.
433
434
Page 6 of 12
scheduling, planning, and implementation.
Implementing a Change
Change implementation follows a miniature version of the
SDLC. Most of the SDLC activities are performed,
although they may be reduced in scope or some times
completely eliminated. In essence, a change for a
maintenance release is an incremental development project in
which the user and technical requirements are fully
known in advance. Analysis activities are typically skimmed or
skipped, design activities are substantially reduced
in scope, and the entire project is typically completed in one or
two short iterations.
Planning for a change includes these activities:

▪ Identify what parts of the system must be changed.
▪ Secure resources (such as personnel) to implement the change.
▪ Schedule design and implementation activities.
▪ Develop test criteria and a testing plan for the changed
system.
production system the version of the system used from day to
day
test system a copy of the production system that is modified to
test changes
Whenever possible, changes are implemented and tested on a
copy of the operational system. The production
system is the version of the system used day to day. The test
system is a copy of the production system that is
modified to test changes. The test system may be developed and
tested on separate hardware or on a redundant
system. The test system becomes the operational system only
after complete and successful testing.
Putting It All Together—RMO Revisited
In a medium-sized or large-scale development project, managers
usually feel overwhelmed by the sheer number of
activities to be performed, their interde pendencies, and the
risks involved. In this section, we give you a glimpse of the
interplay among those issues by showing how Barbara Halifax's
team developed an iteration plan for RMO's Customer
Support System (CSS). But keep in mind that no single example
can adequately prepare you to tackle iteration planning
for a complex project. That is why iteration planning and other
project planning tasks are typically performed by
developers with years of experience.

Before reading the rest of this section, you may want to
review earlier descriptions of the RMO case in Chapters 2, 3,
4, 6, and 9. Some basic parameters for the project are already
described, including subsystem boundaries, project length,
and number of iterations.
Chapter 9 describes Barbara's early planning decisions. In this
section, she expands on those decisions, makes some
changes to her earlier decisions, makes additional key
decisions, and develops the revised iteration plan shown in
Figure 13-20. The sections that follow describe key issues and
decisions that underlie that plan.
Upgrade or Replace?
Upgrading the current CSS “in place” was ruled out early in
project planning for these reasons:
▪ The current infrastructure is near capacity.
▪ RMO expects to save money by having an external vendor host
the CSMS. 434
Page 7 of 12
▪ RMO expects to save money by having an external vendor host
the CSMS.
FIGURE 13-20 Revised CSMS iteration plan
▪ Existing CSS programs and Web interfaces are a hodgepodge
developed over 15 years.

▪ Current system software is several versions out of date.
▪ Infrastructure that supports the current CSS can be repurposed
to expand SCM capacity.
In short, it would be too complex to upgrade the current CSS
without disrupting operations, and the risks of
upgrading old infrastructure and application software are simply
too great. By building and deploying an entirely new
system, RMO will make a clean break from the existing CSS
and its supporting infrastructure. A new hosted
434
435
435
Page 8 of 12
upgrading old infrastructure and application software are simply
too great. By building and deploying an entirely new
system, RMO will make a clean break from the existing CSS
and its supporting infrastructure. A new hosted
infrastructure will be developed for the CSMS. After the first
deployment phase, the existing CSS infrastructure will
be updated to match the hosted environment and serve as a test
environment for later development and deployment
activities.
Phased Deployment to Minimize Risk
The schedule described in Chapter 9 didn't call for phased
deployment, but neither did it directly consider such
deployment issues as database development, data migration, and

training. To minimize deployment risks, the CSMS
will be deployed in two versions. Version 1.0 will reimplement
most of the existing CSS use cases with minimal
changes. Version 2.0 will incorporate bug fixes and incremental
improvements to version 1.0 and will add additional
functionality not present in the CSS, including social
networking, feedback/recommendations, business partners, and
Mountain Bucks.
The two-phase deployment minimizes project risk by dividing
a single large deployment into two smaller
deployments. Another key risk mitigation feature is maintaining
the current CSS and its database as a backup for at
least one iteration after version 1.0 deployment. If a serious
problem arises with version 1.0, RMO can revert to the
current CSS simply by redirecting Web site accesses back to its
internal servers.
Database Development and Data Conversion
Many of the classes in the CSMS class diagram are already
represented in the existing CSS database. However, there
are some new classes and associations and some changes to
existing classes. Thus, there is some degree of
compatibility between the old and new databases but not enough
to enable an upgraded version of the current
database to directly interface with both systems. Thus, a new
CSMS database will need to be built, and data will need
to be migrated from the CSS database prior to deploying version
1.0.
Database development and migration prior to version 1.0
deployment will occur over multiple iterations. The
iteration plan calls for creating a copy of the CSS database early
in the project and making incremental changes to it.
All data in the production CSS database will be migrated to the
CSMS database near the end of the fourth iteration. If

problems are encountered, they will be resolved and the
migration will be repeated as early as possible during the
fifth iteration. Migrating much of the data during the fourth
iteration will enable fifth-iteration testing of user
interfaces with real data from real customers and products and
system and stress testing with a “production sized”
database.
At the end of the fifth iteration, all CSS database changes
since the last full migration will be copied to the CSMS
database. Copying only the changes will enable migration
within a matter of hours. The CSS system will be offline
during the migration. Cutover to the CSMS will occur as soon
as the migration is completed. To minimize risk,
additional data conversion routines will copy new data from the
CSMS database back to the CSS database twice per
day during the fifth iteration. If disaster strikes, the CSS can be
restarted with a current and complete database. If
CSMS version 1.0 passes all user acceptance tests during the
fifth iteration, the CSS will be turned off and data
migration will cease.
Development Order
The IPO development order is the primary basis for the
development plan. By starting with a copy of the CSS
database, a set of test data will exist from the first iteration,
thus enabling the highest risk use cases to be tackled first.
These involve the entire Sales subsystem and customer-facing
portions of the Order fulfillment subsystem. The risks
arise from new technology, uncertainty about requirements, and
the operational importance of sales and order
fulfillment to RMO. By tackling those use cases first, Barbara
allowed her development staff plenty of time to resolve
uncertainties and test related software. Note that significant
testing of these functions began in iteration 2 and
continued through most of the project.

436
436
437
Page 9 of 12
continued through most of the project.
Documentation and Training
Training activities were spread throughout later project
iterations for both production versions. Initial training
exercises covered the highest-risk portion of the system prior to
deployment. They also enabled developers to do
integration and performance testing on the sales-related use
cases long before deployment. Additional training
continued as new functions were added to the system, providing
a gradual ramping up of user skills and developer
workload.
Chapter Summary
Implementation and deployment are complex processes because
they consist of so many interdependent activities.
Testing is a key activity of implementation and deployment.
Software components must be constructed in an order that
minimizes the use of development resources and maximizes the
ability to test the system and correct errors.
Unfortunately, those two goals often conflict. Thus, a program
development plan is a trade-off among available
resources, available time, and the desire to detect and correct
errors prior to system deployment.

Configuration and change management activities track
changes to models and software through multiple system
versions, which enables developers to test and deploy a system
in stages. Versioning also improves postdeployment
support by enabling developers to track problem support to
specific system versions. Source code control systems
enable development teams to coordinate their work.
Key Terms
alpha version 432
beta version 432
bottom-up development 425
build and smoke test 416
direct deployment 429
driver 413
immediate cutover 429
input, process, output (IPO) development order 424
integration test 414
maintenance release 432
parallel deployment 429
performance test 416
phased deployment 430
production system 434

production version, release version, or production release 432
response time 416
source code control system (SCCS) 427
Page 10 of 12
source code control system (SCCS) 427
stub 414
system documentation 420
system test 416
test case 412
test data 412
test system 434
throughput 416
top-down development 425
unit testing 412
usability test 416
user acceptance test 417

user documentation 420
Review Questions
1. List and briefly describe each activity of the SDLC core
processes Build, test, and integrate system components
and Complete system tests and deploy solution.
2. Define the terms unit test, integration test, system test, and
user acceptance test. During which SDLC activity (or
activities) is each test type performed?
3. What is a test case? What are the characteristics of a good
test case?
4. What is a driver? What is a stub? With what type of test is
each most closely associated?
5. List possible sources of data used to initialize a new system
database. Briefly describe the tools and methods
used to load initial data into the database.
6. How do user documentation and training activities differ
between end users and system operators?
7. List and briefly describe the three basic approaches to
program development order. What are the advantages and
disadvantages of each?
8. How can the concepts of top-down and bottom-up
development order be applied to object-oriented software?
9. What is a source code control system? Why is such a system
necessary when multiple programmers build a
program or system?

10. Briefly describe direct, parallel, and phased deployments.
What are the advantages and disadvantages of each
deployment approach?
11. Define the terms alpha version, beta version, and production
version. Are there well-defined criteria for deciding
when an alpha version becomes a beta version or a beta version
becomes a production version?
437
438
Page 11 of 12
when an alpha version becomes a beta version or a beta version
becomes a production version?
Problems and Exercises
1. Describe the process of testing software developed with the
IPO (input, process, output), top-down, and bottom-
up development orders. Which development order results in the
fewest resources required for test ing? What
types of errors are likely to be discovered earliest under each
development order? Which development order is
best, as measured by the combination of required testing
resources and ability to capture important errors early in
the testing process?
2. Assume that you and three of your classmates are charged
with developing the first prototype to implement the
RMO use case Create/update customer account. Create a
development and testing plan to write and test the

classes and methods. Assume that you have two weeks to
complete all tasks.
3. Talk with a computer center or IS manager about the testing
process used with a recently deployed system or
subsystem. What types of tests were performed? How were test
cases and test data generated? What types of
teams developed and implemented the tests?
4. Consider the issue of documenting a system by using only
electronic models developed with an integrated
development tool, such as Microsoft Visual Studio or Oracle
JDeveloper. The advantages are obvious (e.g., the
analyst modifies the models to reflect new requirements and
automatically generates an updated system). Are
there any disadvantages? (Hint: The system might be maintained
for a decade or more.)
5. Talk with an end user at your school or work about the
documentation and training provided with a recently
installed or distributed business application. What types of
training and documentation were provided? Did the
user consider the training to be sufficient? Does the user
consider the documentation to be useful and complete?
6. Assume you are in charge of implementation and deployment
of a new system that is replacing a critical existing
system that is used 24 hours a day. To minimize risk, you plan
to phase in deployment of new subsystems over a
period of six weeks and operate both systems in parallel for at
least three weeks beyond the last new subsystem
deployment. Because there aren't enough personnel to operate
both systems, you plan to hire up to 30 temporary
workers during the parallel operation period. How should you
use the temporary workers? In answering that
question be sure to consider these issues:

i. Some current personnel will be trained before subsystem
deployments, and those employees will train
other employees.
ii. Employees newly trained on the system will probably not
reach their former levels of efficiency for many
weeks. 438
Page 12 of 12
weeks.
Case Study
HudsonBanc Billing System Upgrade
Two regional banks with similar geographic territories merged
to form HudsonBanc. Both banks had credit card
operations and operated billing systems that had been internally
developed and upgraded over three decades. The
systems performed similar functions, and both operated
primarily in batch mode on mainframe computers.
Merging the two billing systems was identified as a high-
priority cost-saving measure.
HudsonBanc initiated a project to investigate how to merge
the two billing systems. Upgrading either system
was quickly ruled out because the existing technology was
considered old and the costs of upgrading the system
were estimated to be too high. HudsonBanc decided that a new
component-based, Web-oriented system should
be built or purchased. Management preferred the purchase
option because it was assumed that a purchased

system could be brought online more quickly and cheaply. An
RFP (request for proposal) was prepared, many
responses were received, and after months of business modeling
and requirements activities, a vendor was
chosen.
Hardware for the new system was installed in early January.
Software was installed the following week, and a
ran dom sample of 10 percent of the customer accounts was
copied to the new system. The new system was
operated in parallel with the old systems for two months. To
save costs involved with complete duplication, the
new system computed but didn't actually print billing
statements. Payments were entered into both systems and
used to update parallel customer account databases. Duplicate
account records were checked manually to ensure
that they were the same.
After the second test billing cycle, the new system was
declared ready for operation. All customer accounts
were migrated to the new system in mid-April. The old systems
were turned off on May 1, and the new system
took over operation. Problems occurred almost immediately.
The system was unable to handle the greatly
increased volume of transactions. Data entry and customer Web
access slowed to a crawl, and payments were
soon backed up by several weeks. The system wasn't handling
certain types of transactions correctly (e.g., charge
corrections and credits for overpayment). Manual inspection of
the recently migrated account records showed
errors in approximately 50,000 accounts.
It took almost six weeks to adjust the incorrect accounts and
update functions to handle all transaction types
correctly. On June 20, the company attempted to print billing
statements for the 50,000 corrected customer

accounts. The system refused to print any information for
transactions more than 30 days old. A panicked
consultation with the vendor concluded that fixing the 30-day
restriction would require more than a month of
work and testing. It was also concluded that manual entry of
account adjustments followed by billing within 30
days was the fastest and least risky way to solve the immediate
problem.
Clearing the backlog took two months. During that time, many
incorrect bills were mailed. Customer support
telephone lines were continually overloaded. Twenty-five
people were reassigned from other operational areas,
and additional phone lines were added to provide sufficient
customer support capacity. System development
personnel were reassigned to IS operations for up to three
months to assist in clearing the billing backlog.
Federal and state regulatory authorities stepped in to investigate
the problems. HudsonBanc agreed to allow
customers to spread payments for late bills over three months
without interest charges. Setting up the payment
arrangements further aggravated the backlog and staffing
problems.
1. What type of installation did HudsonBanc use for its new
system? Was it an appropriate choice?
2. How could the operational problems have been avoided?
RUNNING CASE STUDIES
438
439
Page 1 of 4

RUNNING CASE STUDIES
Community Board of Realtors
Assume that the Multiple Listing Service that is under
development will replace an existing system developed
many years ago. The database requirements and design for the
old and new systems are very similar.
Unfortunately, the existing system stores its data in a Microsoft
Access database, which provides little support
for simultaneous access and updates by multiple users. An
important reason for replacing the current system is to
upgrade to a DBMS that can easily support many simultaneous
accesses.
The current plan is to use Microsoft SQL Server as the new
DBMS and to migrate all data from the existing
Microsoft Access database immediately prior to full
deployment. Perform these tasks to prepare for this
migration:
1. Investigate data migration from Microsoft Access to SQL
Server. What tools are available to assist in or
perform the migration? If there are multiple possible tools,
which should you use and why?
2. Develop plans to test the migration tools/strategy in advance
of full deployment. When should the test be
performed, and how will you determine whether the test has
been “passed”?
The Spring Breaks 'R' Us Travel Service

Review the case-related questions and tasks as well as your
responses from Chapters 8 and 9. As described in
previous chapters, assume the new system will upgrade an
existing system and add new social networking
functions to it. Specifically, review your answer to question 2 in
Chapter 9 in light of the more detailed
understanding of the risks, costs, and benefits of various
implementation orders and deployment approaches that
you gained by reading this chapter.
1. For each subsystem—Resort relations, Student booking,
Accounting and finance, and Social net working
—specify which other subsystem(s) it depends on for input
data?
2. Can the four subsystems be developed and deployed
independently? If so, in which order should they be
developed and deployed? If not, explain why not and describe
how you would develop and deploy the
system.
On the Spot Courier Services
In Chapter 8, we identified these four subsystems:
▪ Customer account subsystem (such as customer account)
▪ Pickup request subsystem (such as sales)
▪ Package delivery subsystem (such as order fulfillment)
▪ Routing and scheduling subsystem
In Chapter 8, you also decided on a development order for
these four subsystems, assuming a single two
person team. In Chapter 9, you created individual subsystem
iteration schedules and a combined project

schedule. In Chapter 6, you identified equipment that would be
needed for the system.
Your assignment for this chapter is to develop a test plan for
each subsystem and for the overall project as well
as to develop a conversion/deployment schedule.
1. For your test plan, do the following:
a. Develop an iteration test plan (i.e., one that applies to and
can be used within a subsystem iteration
mini-project). Discuss which types of testing (as identified in
this chapter) you would include and
why. Estimate how much time will be needed for each type of
test. Discuss what types of testing
439
440
Page 2 of 4
mini-project). Discuss which types of testing (as identified in
this chapter) you would include and
why. Estimate how much time will be needed for each type of
test. Discuss what types of testing
might be combined or scheduled with an overlap.
b. Develop a total project test plan to integrate all the
subsystems. Discuss which types of testing you
would include and why. (Don't put them on a schedule yet.)
2. Develop a conversion/deployment plan. Discuss these:

a. Data conversion: Which parts of the data must be saved from
the old spreadsheet/manual system?
Which parts of the data can just be discarded (i.e., not moved to
the new system)? Discuss specific
tables that you identified in Chapter 12.
b. Deployment: Based on your decisions about which
subsystems should be deployed first (Chapter
8), your overall testing plan, and your data conversion
decisions, develop an overall schedule for
testing and deployment of the new system. How would you
characterize your solution: direct,
parallel, or phased conversion? Support your answer by
discussing the logic behind your decisions.
3. Revisit your solution in Chapter 6 regarding the types of
equipment that will be needed. Include in your
discussion your current recommendation for hosting the system.
Add to your deployment schedule the
activities to purchase equipment and set up the hosting
environment.
Sandia Medical Devices
Refer to the case information provided at the end of Chapters 8
and 9 and the domain class diagram at the end of
Chapter 11. Review and update your results from performing the
tasks at the end of Chapter 9 based on the
information provided in this chapter. Then, answer these
questions:
1. What integration and system tests are required, and when
should they be incorporated into the iteration
schedule?
2. What are the documentation and user training requirements
for the system, and when should they be

incorporated into the iteration schedule?
3. Assume that after deployment and a three-month testing and
evaluation period, updates to the first
Android-based system (client and server) will be implemented
and another client-side version will be
implemented for the iPhone. Develop an iteration plan for
implementing and deploying the second
version of the system.
Further Resources
Robert V. Binder, Testing Object-Oriented Systems: Models,
Patterns, and Tools. Addison-Wesley, 2000.
Mark Fewster and Dorothy Graham, Software Test Automation.
Addison-Wesley, 1999.
Jerry Gao, H.-S. Jacob Tsao, and Ye Wu, Testing and Quality
Assurance for Component-Based Software, Artech House
Publishers, 2003.
William Horton, Designing and Writing Online Documentation:
Hypermedia for Self-Supporting Products (2nd
edition). John Wiley & Sons, 1994.
William Horton, Designing Web-Based Training: How to Teach
Anyone Anything Anywhere Anytime. John Wiley &
Sons, 2000.
William Horton, e-Learning by Design. Pfeiffer,
International Association of Information 2011.
440
441

Page 3 of 4
International Association of Information 2011.
Technology Trainers (ITrain) Web site, http://itrain.org.
David Yardley, Successful IT Project Delivery. Addison-
Wesley, 2002.
Page 4 of 4
__MACOSX/Integration and Systems Test/._Chapter 13.pdf
The purpose of this assignment is to finalize an internal
business proposal that outlines how you will implement the
solution to the problem you have identified in your
organization.
The key pieces you will focus on creating are the Executive
Summary and the Conclusion/Call to Action. (Add onto the
attached Business Proposal with the Highlighted below).
1. Executive Summary (250 words) provides a short summary of
the entire proposal so key stakeholders can see an overview of
the proposal and understand it without reading the entire
document.
2. Purpose Statement (100-250 words) provides clear statement
of why the business proposal is being made.
3. Problem Statement (revised as needed from Topic 1
assignment feedback) including specific data (statistics and
numbers) related to how the problem impacts the business. This
part of the proposal should include the graph/chart/data you

collected in Part 1 of the Topic 2 assignment.
4. Data and Research Findings (250-500 words) should include
a summary of what you learned from conducting research
related to what has already been done to address the
organizational problem. This part of the proposal should include
the graph/chart/data you collected in Part 2 of the Topic 2
assignment.
5. Proposed
Solution
(250-500 words) should include a summary of the top three
problem solutions you considered to address the problem. In
addition to including the graph/chart/data you collected in Part
3 of the Topic 2 assignment, this section should provide a
succinct discussion of the pros and cons of implementing each
of the top three solutions being considered to address the
problem.
6. Stakeholder Analysis and Benefits (500 words, revised as
needed from Topic 3 assignment feedback) summarizes all data
and information related to the key stakeholders affected by the
proposed problem solution along with a summary of benefits to
be gained by stakeholders if the problem solution is
implemented.
7. Change Management Plan (250-500 words) clearly articulates
specific methods and strategies to be utilized to manage
organizational changes associated with the selected solution

implementation.
8. Implementation Methods (250-500 words) summarize specific
strategies that will used to implement the problem solution,
including time and costs associated with implementation of the
solution.
9. Evaluating Success (250 words) summarize specific measures
you will use to evaluate the success of the problem solution.
10. Conclusion/Call to Action (100 words) provides specific
steps you would like key stakeholders and sponsors to take in
the implementation of the proposed solution.
Keep in mind that the proposal is an internal document that will
be read by stakeholders within the organization where the
problem exists. Focus on this audience as you write. Within the
Word document, include subsection titles to organize content
according to the categories listed above to provide easy
reference points for the reader.
1
BUSINESS PROPOSAL PART 1

Business Proposal Part 1
12/04/2016
Purpose Statement
Every day, there is a student across the nation that is dropping
out of school due to unforeseen circumstances and it is a
problem in our society today. All students need to have an
education so they have a successful future but that cannot
happen if we do not find out what the true problem is and figure
out how to fix it before it is too late. Everyone wonders why
there is so much unemployment rate or why there are people
incarcerated and I believe that is due to them not having the
education that they need to have the job that they are looking
for that can keep them out of trouble and be successful.
Problem Statement
The overall graduation rate in my local area is at an all-time
low of 78%. It shows that students are not focusing on

graduation and are distracted by other things outside of school.
Whether they come from different backgrounds or have trouble
learning and feel that it is a need to dropout because of it, it is
detrimental to not only those students who decide that school is
not for them but also the economy because high school
graduates are important to the economy. There is an opportunity
to turn the dropout rate if there people who are willing to help
invest in the high risk students that are in need of help and to
show them that someone does care about their future.
Data and Research Findings
As I have done major research, I have learned through the staff
and students that they know there is a major issue in the system
and there is a major disconnect between both staff and students.
The school administrators know that Math and English are the
main subjects that are prevent students from graduating and
they are trying to figure out a different route on how they would
go about making sure that all of their students are able to pass
those subjects in time for graduation. They have started having
people come on campus after school to help students that
needed help in certain subjects and tutor them daily which
comes out of the schools separate funding that they have. They
do plan to raise their graduation rate to 90% in the next 5 years
as their goal.

As I have talked to the students, they seemed as though they
were having a tough time understanding what was going on in
class, or at least a most of them were. Some of the students said
that they were getting help from their teachers while others
were not which is where the disconnection is between the
teacher and the student. I’m sure the teachers think that the
students are failing on purpose but in all reality, the students do
not comprehend the work that is being given and when they ask
for help, most of the time they don’t receive it. These students
would like to see change in their school when it comes to their
curriculum and making sure that their teachers get the proper
training that they need to help them to become
successful.Comment by WES WALTER: Delete word.Comment
by WES WALTER: Is it the curriculum or is it that they are
advancing through lowering classes without having grasped the
fundamental foundations that would allow them to succeed?
Proposed

Integration and Systems Test.DS_Store__MACOSXIntegration a.docx

More Related Content

Similar to Integration and Systems Test.DS_Store__MACOSXIntegration a.docx

More from normanibarber20063

Recently uploaded

Integration and Systems Test.DS_Store__MACOSXIntegration a.docx