Systems Analysis and Design in a Changing World, sixth edition 13-1

Chapter 13 Making the System Operational

Solutions to End-of-Chapter Problems

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.

Build, test, and integrate

Program the software the programmers write the code
Unit test the software the programmers test the code they have programmed
Identify and build test cases this requires both project staff and end users. There are
often test cases to be used for integration and system test. Additional end user test cases,
which uses or simulates live data, are usually more complex.
Integrate and test components as components successfully pass unit test, they are
integrated into a growing overall system and tested as part of the integrated system.

Complete system tests and deploy solution

Perform system and stress tests after the components are integrated successfully, then
the entire system is tested to test cross functions, cross time periods, and high volumes.
Convert existing data if the new system replaces an existing system valid data, such as
customer accounts, must be converted to the new database format.
Build training materials and conduct training often end user training and perhaps
system training is require to ensure that the deployed system runs successfully and that
the users can do their work.
Deploy the solution install the system on the production servers with the production
database and begin using it.

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?

A unit test is a test of an individual module or method before it is integrated with other modules
or methods.

An integration test is a test of the behavior of a group of modules or methods.

A system test is a test of the behavior of an entire system or independent subsystem.

An acceptance test is a system test that determines whether the system fulfills user
requirements.

An acceptance test is normally performed by or under the direction of users. The programmer or
his or her testing buddy usually performs unit testing. Integration and system tests may be
Systems Analysis and Design in a Changing World, sixth edition 13-2

performed by programmers or members of a separate quality assurance group.

3. What is a test case? What are the characteristics of a good test case?

A test case is a predefined set of data to test a particular function or set of functions. Both the
input data and the expected results are normally defined before hand. Test cases must ensure
that all instructions in a program are executed, preferably many times, with a variety of data
inputs.

4. What is a driver? What is a stub? With what type of test is each most closely associated?

A driver is a module that simulates the calling behavior of a module that hasnt yet been
developed. Drivers are most closely associated with unit testing.

A stub is a module that simulates the execution or behavior of a module that hasnt yet been
developed. Stubs are most closely associated with unit testing.

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.

Possible data sources include manual (paper) records, files or databases of a system being
replaced, files or databases of other systems in the organization, and manual data entry during
training or normal system operation. Tools for initializing database content include normal data
entry programs, optical character recognition software, custom-developed data conversion
programs, and DBMS import and export utilities.

6. How do user documentation and training activities differ between end users and system
operators?

Operator documentation and training covers topics, such as system startup and shutdown,
backup and recovery, and software installation and upgrade, that are not typically covered in
end user documentation. System operators are usually more highly trained than end users, so
their documentation often has fewer bells and whistles.

System operator training generally omits the business context. The relatively small number of
operators usually precludes classroom-based approaches. Relatively high skill and experience
levels allow greater use of self-study as a training method.

End user training emphasizes hands-on system use to achieve specific business objectives.
Training in the business context is as important as training in system specifics. Relatively large
numbers of end users allow one-to-many (classroom) training sessions and train-the-trainer
approaches. Variation in skills and experience levels necessitate several training methods and
materials.

End user documentation and training focus on the functions and procedures of the new system.
This would include such things as the screens, shortcut keys, sequences of screens, output
reports and screens, and menus or navigation paths to access the system functions.
Systems Analysis and Design in a Changing World, sixth edition 13-3

7. List and briefly describe the three basic approaches to program development order. What are
the advantages and disadvantages of each?

Input-process-output development order Develop the input screens and reports, then the
business logic, and finally the output reports and screens. The advantage of this is that testing is
easier, because the inputs accept data, which is available when testing the business logic. The
disadvantage is that this IPO order may not be the most logical order for integration or use of
the system. Since outputs are done last, sometimes it is hard to know if the system is processing
the data correctly.

Top-down development order This approach develops the controlling modules or controlling
methods first. The advantage of this is that the overall program structure is developed first, so
that there is a skeleton to add new functions to. This would be an example of a walking
skeleton approach. The disadvantage is that it is hard to see what the results of a test are
without the detailed workhorse methods coded. It also may not use programmer time
effectively since there will only be a few high-level functions that need to be done first.

Bottom-up development order This approach develops the detailed workhorse functions and
methods first. The advantage is that these methods are tested over and over again as the system
is built. However, the disadvantage is that driver methods need to be written to test them. In
other words, it is not efficient since so much additional work is required to have a test structure
for these low-level methods.

8. How can the concepts of top-down and bottom-up development order be applied to object-
oriented software?

As implied in the previous question, top-down and bottom-up can be applied to OO because of
method dependency. Those methods that call other methods are considered top-level methods.
Those methods that do the basic calculations without calling other methods are considered low-
level methods.

9. What is a source code control system? Why is such a system necessary when multiple
programmers build a program or system?

A source code control system (SCCS) is an automated tool for tracking source code files and
controlling changes to those files. An SCCS prevents multiple programmers from making
inconsistent or conflicting changes to source files. An SCCS ensures that a source code file
cannot be modified by more than one programmer at a time.

10. Briefly describe direct, parallel, and phased deployments. What are the advantages and
disadvantages of each deployment approach?

Direct installation installs a new system, quickly makes it operational, and immediately turns
off any overlapping systems. Direct installation is the simplest to plan and execute, but it runs
Systems Analysis and Design in a Changing World, sixth edition 13-4

the greatest risk of interrupted service.

Parallel installation operates both the old and new systems for an extended period of time.
Parallel installation is relatively complex to plan and implement, but it reduces the risk of
interrupted service.

Phased installation installs a new system and makes it operational in a series of steps or phases.
Phased installation breaks up the complexity of planning and execution into manageable pieces,
but the total planning and execution effort is greater than with the other methods.

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?

An alpha version is a system that is incomplete but ready for some level of rigorous testing. A
beta version is a system that is stable enough to be tested by end users. A production version is a
system that is formally distributed to users or made operational.

Because users test beta versions by using them to do real work, an alpha version must meet the
following criteria to become a beta version: the software must be nearly complete, and it must
not be susceptible to severe crashes or other productivity-thwarting behaviors.

A beta version usually becomes a production version after successful acceptance testing.
Systems Analysis and Design in a Changing World, sixth edition 13-5

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 testing? 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?

Software testing under top-down development order starts with an implementation of the top-
most module and stubs for each of the second-level modules. One by one, each stub is replaced
with a fully implemented module, which is then tested. As each stub is replaced, new stubs must
be created for any subordinate modules. The process continues until all of the modules have
been fully implemented and tested.

Bottom-up development order starts with a driver for one related set of bottom-level modules
and the initial implementation of one of the bottom-level modules. After that module is tested,
another bottom-level module is created, and the driver is modified to call it (or a new driver is
created). After all bottom-level modules in a calling group have been implemented, the driver is
replaced with a new module, and a new driver is written to call the new module.
Implementation and testing moves up the structure chart in this fashion until all program
modules have been implemented and tested.

Under top-down development order, a stub is written once for every module. Under bottom-up
development order, a smaller set of drivers is written, but each driver must be updated several
times as subordinate modules below it are implemented. In addition, driver modules are
generally more complex than stub modules (for example, compare the driver in Figure 15-16 to
the stubs in Figure 15-17). Thus, bottom-up development order tends to consume more
resources because more effort is expended writing and modifying modules that will be
discarded after testing.

Top-down development order finds errors in upper-level modules first. These modules typically
contain the business logic of the system and integrate the activities of the lower- level modules.
Thus, logic and integration errors are found sooner with top-down development order.

Bottom-up development order finds errors in the lower-level modules first. These modules
typically contain detailed procedural code including data access, I/O formatting, and
computations. Thus, errors in those modules are found sooner with bottom-up development.

Neither implementation order completely dominates the other when required resources and
early error detection are considered. If errors are assumed to be evenly distributed through the
structure chart and if they are assumed to be equally fixable regardless of structure chart
location, then top-down development order is better due to its lower resource consumption. But
many systems have complex procedural, I/O, or data access modules, and discovering errors in
those modules early in the development process can save time and testing resources.
Systems Analysis and Design in a Changing World, sixth edition 13-6

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.

Answers will vary. (It is not necessary to do it in MS Project, but we show an MS Project
solution.)

Since this is a prototype, or a first version of only a single use case, it is assumed that only
Implementation Activities (ii. e. Core Process 5 Figure 13-1) will be required. Deployment will
occur later with other use cases and production versions. This plan will include unit testing and
integration testing as much as possible.

Start with a WBS. (P1, P2, P3, P4 are persons in the team)

Task Description Effort Resources Predecessor

ID
1 Manage environment, code control, documentation 2 days P1 0
2 Layout, program, and review input screens 3 days P1 0
3 Unit test input screen 1 day P1 2
4 Verify fields and build database schema (4 tables) 1 day P2 0
5 Program methods of 4 classes 5 days P3, P4 0
6 Unit test 4 methods of 4 classes 2 days P3, P4 5
7 Identify build test cases for add and update 3 days P2 4
8 Write support programs to verify database updates 2 days P2 7
9 Perform integration testing of all components - 2 days P1, P2, P3, 1,3,6,8
view, logic, data layers. P4
Systems Analysis and Design in a Changing World, sixth edition 13-7

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?

Answers will vary.

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 J Developer. 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.)

The system owner is effectively locked into the CASE tool for the life of the system, unless he
or she is willing to spend the considerable amount of money required to re-implement the
system without the CASE tool. The situation is similar to the problem of extracting data from
old sources (for example, data stored in a dBase II file on a 5.25 inch floppy disk). You must
maintain appropriate software and hardware to be able to access the data.

Without the CASE tool, developers would have to rely on printed output (which may be
incomplete or unavailable) and source code stored in ordinary files (if it was ever stored that
way). While this may appear acceptable in theory, it is extremely difficult in practice. Source
code generated by CASE tools is not intended to be read by the human eye (and theres
considerable incentive for the CASE tool vendor to make it unreadable). Modifying such code
is technically but not economically feasible.

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?

Answers will vary.

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 arent 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.

Answers will vary, and there are many correct answers. Here are some considerations.
Systems Analysis and Design in a Changing World, sixth edition 13-8

Operating both systems in parallel requires that every transaction, or business process be
completed two times once for the old system and once for the new system.

Issues that will affect the approach.

1. Data conversion. It is assumed that there will be a data conversion at the beginning of the
parallel. Question: Will there also be a reconversion of the data at the end of the parallel period?
Yes Then all transactions must be completely done for the old system, and it is less
important if there are missed transactions on the new system.
No Then transactions on the old system can gradually be reduced. The transactions
that are processing correctly on the new system can be discontinued on the old.
2. Anticipated error load: Question: Will there be a high number of errors or low error rates?
High The old system must maintain a complete set of transactions from the work
activity.
Low The old system can gradually be phased out as the new system assumes the work.
3. Employee attrition: Questions: Will there be a substantial number of employees who will not
be able to adjust to the new automated system?
Yes Keep those employees on the old system. Look for temporary staff that may be
desirous to hire on.
No Move employees to the new system as rapidly as possible.

Objectives of the parallel testing:

1. The new system should be thoroughly tested with all data at the end of the test period.
2. The company must keep current with the work load.
3. Train as many current employees as possible on the new system. Move them over as rapidly
as possible.

Approach:
1. Load as many as possible of the temporary people on the old system. Even if it requires 2 or
3 temporary persons to do the job of one full time employee. Leave sufficient current employees
to ensure that the work is done with few errors.
2. Move as many people as possible to the new system. This avoids training temporaries on the
new system. This uses training time on the new system to train current employees.
3. Move over more current employees as the temporary staff becomes more efficient on the old
system.
Systems Analysis and Design in a Changing World, sixth edition 13-9

Solutions to End-of-Chapter Cases

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 random 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 didnt 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 wasnt 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
Systems Analysis and Design in a Changing World, sixth edition 13-10

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?

HudsonBanc used a modified type of parallel deployment of two months. It was a parallel
deployment because it supposedly paralleled activity on both systems. However, it was
modified because it only did a parallel on 10% of the accounts.

The choice was appropriate, but needed to be implemented differently.

A direct cut over would not have worked.

A phased deployment would probably not have worked well because a billing system is usually
a tightly integrated unit. Perhaps some type limited things, such as billing, could have been
done in a phased fashion.

2. How could the operational problems have been avoided?

Answers will vary.

The following steps could possibly have avoided the problems:
1. After the two month 10% parallel, run a complete parallel of all customer accounts
for an additional period.
2. Extend the parallel testing time period. Two months was too short. Probably a six
month parallel period would be more appropriate.
3. Manual checking of customer accounts is limited. It probably only checks one type
of record, and it is subject to manual errors. A programmatic verification of all database
records, including customer accounts and transactions should be done.
4. Testing should have been against the existing system, as well as against predicted
values.
5. Paralleling the entire customer database would have indicated scaling problems.
Systems Analysis and Design in a Changing World, sixth edition 13-11

Running Cases: 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?

Answers will vary.

Microsoft Access Upsizing Wizard
Microsoft SQL Server Migration Assistant (SSMA) for various databases
ESF Database Migration Toolkit (ESF = EasyFrom)
Redevelop the SQL Server from scratch

MS Access database systems usually contain both Access Jet Engine database schema and data,
as well as Access Front End code for user input forms and output reports. Hence a migration
plan will need to include at least the following:
1. Convert database schema
2. Convert database data
3. Convert the macros and code modules (Upsize Wizard does not do this)
4. Convert input forms, output reports, and front end code (Wizard does not do this)

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?

Answers will vary.

Items to include in a test plan:

1. Test the schema conversion manually review each table and each field type and
definition. Also review keys and indexes.
2. Test the the data conversion programmatically read the data from both databases and
do a comparison of data values. The data reads should include simple queries as well as
complex joins and read by index values.
3. Compare the insertion of new data records in both databases to ensure that it works the
same in both.
4. Test the store procedures (macros and modules) that work within the confines of the
database.
5. After the database is converted successfully, then test the interaction between the
Systems Analysis and Design in a Changing World, sixth edition 13-12

database and the applications that use it. Test all applications, test all functions, test all
business operations. This is like an extensive systems test.
6. Finally conduct an independent Acceptance Test of all user activity.

To know if the migration is successful, the first step is comparing database values between old
and new systems. In other words, a parallel type of test.

The final success, is the acceptance test that it is performing business operations and processes
successfully.
Systems Analysis and Design in a Changing World, sixth edition 13-13

Running Cases: 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 subsystemResort relations, Student booking, Accounting and finance, and Social
networking specify which other subsystem(s) it depends on for input data?

From Chapter 8 we get the classes in each subsystem. We enhance to show where the original
data comes from. In other words, which system has Create and Update responsibility for that
class.

Subsystems Classes and subsystem which have Create and

Update responsibility.
Resort relations Resort Resort relations
Accommodation Resort relations
Facility Resort relations
Activity Resort relations
Traveler Student booking
TravelerInRoom Resort relations
Comment (read) Social networking
Student booking Reservation Student booking
Traveler Student booking
PersonAccount Student booking
Group Student booking
Resort (read) Resort relations
PaymentTxn Account and Finance
Accounting and finance PaymentTxn Accounting
PersonAccount (read) Student booking
Traveler (read) Student booking
Resort (payments to resorts) Resort relations
Social networking Traveler (read) Student booking
Group (read) Student booking
Interest** Social networking
Comment Social networking
Resort (read) Resort relations
TravelerInRoom (read) Resort relations
Accommodation (read) Resort relations
Facility (read) Resort relations
Activity (read) Resort relations
MultimediaInfo** Social networking
Systems Analysis and Design in a Changing World, sixth edition 13-14

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.

Answers will vary. There is a lot of interdependence among the four subsystems. Answers will be
some variation of Chapter 8 solution.
Systems Analysis and Design in a Changing World, sixth edition 13-15

Running Cases: 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 might be combined or scheduled with an overlap.

Answers will vary. Here are some considerations.

From Chapter 9 there are 7 basic iterations defined. We add additional iterations as needed to
do final system and performance testing. Let's assume that the approach to building the system
is an organic approach so that as each new piece is completed, that it is integrated into an
every expanding and more comprehensive total system. We can do this, even though we may
not begin to deploy the system until the end of the project.

The length of the first iteration was defined as 17 days, but with minimal testing defined. Let's
assume that iterations normally require 20 days (4 weeks) to 30 days (6 weeks). Within each
iteration there will need to be unit tests, usability tests, and integration tests. We will also begin
system tests (particularly build and smoke tests) as the project progresses. In other words, as
the system grows, we will begin doing early stage system test.

Given the testing approach as outlined above, each iteration will require the following tests.
Unit test Each programmer will test his/her own work. If the programmers are
working in pairs, then it is often productive to have the programmer who did NOT write
a particular piece of code to test it. Programming teams should attempt to test the code
with good data (expected to work), and with bad data (expected to not work). Bad data
should be caught and handled correctly. Test cases for these tests is normally very
simple transaction input tested with drivers and stubs as explained in the chapter. Each
use case should have an extensive unit test. Programmers should test the output (result)
from the test. They should also test the intermediate results, including database values
and internal data items.

Integration testing The first iteration should produce a core system with a basic
Systems Analysis and Design in a Changing World, sixth edition 13-16

database schema. This will serve as the starting point for integration testing. During each
iteration, as each use case completes its unit test, it should then be integrated into the
system. Integration testing is a growing process because the system itself is growing.
Test cases for integration testing are more complex because they must include previous
components that are already integrated and new components that are just being added. A
test bank of test cases should be built and expanded as the system grows. The integration
test should verify that existing results, both database values and internal data items, have
not be inadvertently modified by the newly integrated code. Integration testing will
require more and more effort as the project progresses. Responsibility for integration
testing is shared between the programmer who wrote the code, and a team member who
is in charge of integration tests. Each iteration should include integration testing for
each new use case which is added to the system.

Usability testing As each new use case is added to the system, and after a successful
integration test, a brief usability test is conducted. A small group of users will test
specific use cases to see if (1) the business function is supported correctly and
accurately, and (2) if the system is user friendly and easy to understand and use. Users
who understand the process of system development and testing should be involved in
this test. Again, it is done on a use case by use case basis.

Build and Smoke testing This is a system test of the whole system. It is the first type
of system test, and is a direct outgrowth of integration testing. As new components are
added, the total system is recompiled (if necessary), and all previous data is tested again.
For every iteration a complete build and smoke test will be conducted before the
iteration is considered complete.

b. Develop a total project test plan to integrate all the subsystems. Discuss which types of testing
you would include and why. (Dont put them on a schedule yet.)

As mentioned in part (a), the system will grow with each iteration. Hence integration testing
will be done as part of each iteration. Preliminary system testing will be done within each
iteration as part of the build and smoke testing that is conducted. However, comprehensive
system testing will be done as part of a separate system and acceptance test activity.

Given that integration testing and build and smoke testing is done during each iteration, then at
the end of the project a testing iteration will be defined to finalize system testing. During this
final iteration the following will occur.

System testing System testing is performed in a test environment on test computers.

The total system, including the database, is compiled and linked together. System
testing requires that the system be tested with initial transactions that create and
initialize data, update transactions that modify and change the data, with delete
transactions that remove or deactivate data. Also end-of-period transactions and activity
must also be tested to ensure that balances are carried forward, reports are generated,
and that the database maintains its integrity and accuracy. Usually several test periods
Systems Analysis and Design in a Changing World, sixth edition 13-17

are defined that simulate day, week, month, and yearly activity. Test cases for system
test can be obtained from the integration tests as well as from acceptance test cases.
Sometimes test data can be obtained from sampling live data from existing processes.

Acceptance testing Acceptance testing can be begun within the context of the test
environment. However, final acceptance test should be done on the production
environment. Primary responsibility for acceptance testing belongs to the users,
however, developers can help set up and monitor the tests. Test cases for acceptance test
should be derived from live data and it should mirror the actual business processes as
much as possible. Acceptance test should also have many of the same characteristics of
system test, in that it must cover complete business processes (request, pickup, delivery,
payment, etc.) and multiple time periods. Adequate time should be scheduled for
acceptance testing. Deployment of systems before they are completely tested is a major
cause of headache and pain for the organization.

Stress and performance testing Performance testing should be done within the
context of the production environment. For this system On the Spot there does not
appear to be the need for extremely high volumes. Package delivery and routing are not
frequently occurring activities. Even customer requests for pickup are not high volume
for a single metropolitan area or even state. However, issues may arise with the
connectivity and telecommunications requirements. Hence performance tests in these
areas should be conducted. Again using the production equipment and environment.

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.

The following table identifies database tables that will be required for the new system. It is
based on the class diagram developed in Chapter 4. (Chapter 12 case problems did not require a
database schema. )

Database table Conversion requirements

Customer Yes. Must retrieve from existing customer data
CustomerAccount Yes. Must retrieve from existing customer data
IndividualCust Yes. Must retrieve from existing customer data
BusinessCust Yes. Must retrieve from existing customer data
PickupRequest No. Old data must be processed, but does not need to go to new system.
Package No. Old data must be processed, but does not need to go to new system.
RouteTrip No. Old data must be processed, but does not need to go to new system.
Employee Probably not in old system. Must create new data.
Systems Analysis and Design in a Changing World, sixth edition 13-18

MovementEvent No. Old data must be processed, but does not need to go to new system.
Payment Yes. Want to keep records of customer payments.
Note: Some data will not be needed in the new system, however, old records should be saved to
do statistical and financial analysis. This would include Package and RouteTrip data.

b. Deployment: Based on your decisions about which subsystems should be deployed first
(Chapter 8 & 9), 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.

Answers will vary. Some students may want to do a phased implementation and some may do a
parallel implementation. A direct cut over is too risky, even for this small company.

A phased implementation might be something like the following (from Chapter 9)

Iteration Subsystem/ No. of Use Time Test/Conversion Activities

Description Cases
#1 Customer account 3 4 weeks Iteration tests
#2 Customer account 2 3 weeks Iteration tests
#3 Pickup request 5 5 weeks Iteration tests (including integration)
#4 Package delivery/ 4 4 weeks Iteration tests (including integration)
Routing
New Data conversion 0 1 week Data conversion tests
New System tests 0 2 weeks
New Acceptance tests 0 2 weeks Acceptance tests
New Begin Phased/ Parallel 0 2 weeks Parallel comparisons
Deployment
#5 Routing and scheduling 5 5 weeks Iteration tests (including integration)
New System test Routing and 0 1 week Data creation
Scheduling
New Acceptance test and 0 2 weeks
phased deployment
#6 Administration 4 4 weeks Iteration tests (including integration)
#7 Administration 4 4 weeks Iteration tests (including integration)
New Total system test 0 1 week
New Total Acceptance test 0 2 weeks
New Total Parallel 0 2 weeks
Systems Analysis and Design in a Changing World, sixth edition 13-19

New Final deployment 0 2 weeks

Total time 46 weeks

A parallel conversion might look like the following:

Iteration Subsystem/ No. of Use Time Test/Conversion Activities

Description Cases
#1 Customer account 3 4 weeks Iteration tests
#2 Customer account 2 3 weeks Iteration tests
#3 Pickup request 5 5 weeks Iteration tests (including integration)
#4 Package delivery/ 4 4 weeks Iteration tests (including integration)
Routing
#5 Routing and scheduling 5 5 weeks Iteration tests (including integration)
#6 Administration 4 4 weeks Iteration tests (including integration)
#7 Administration 4 4 weeks Iteration tests (including integration)
New Data Conversion 0 2 weeks Verify Data conversion
New System/ performance 0 4 weeks Verify all components of the system
test
New Acceptance test 0 4 weeks Verify all functions
New Begin Parallel operation 0 4 weeks Verify all operations
Total time 43 weeks

Note: The phased parallel has three disadvantages: First, It will take 3 weeks longer, which is a
normal condition. Second, it will require more resources (and expenses) over a longer period of
time because more parallel activities are going on. Third, since there is more parallel overlap,
more coordination and synchronization will be required to keep the two systems up-to-date.

However, it also has two advantages. First, the system is in use earlier, so the organization
begins to get the benefits of the new system. Second, the system is tested over a longer period
of time, so there also less risk.

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.

For the phased parallel deployment approach, a separate activity will need to be integrated into
the project at about 12 weeks into the project. This activity will purchase and install the
necessary equipment (as identified in Chapter 6).

For the non-phases, parallel deployment approach a separate activity will need to be integrated
Systems Analysis and Design in a Changing World, sixth edition 13-20

into the project at about 24 or 25 weeks into the project. This activity will purchase and install
the necessary equipment (as identified in Chapter 6).
Systems Analysis and Design in a Changing World, sixth edition 13-21

Running Cases: 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?

Answers will vary depending on student's plan from Chapter 9.

Integration tests should be conducted as part of the iteration test activity. This system has many
individual components which send data to other components. In other words, the integration is
primarily through sending data as opposed to having program or function calls. Interfaces
through APIs and direct program to program communication is not extensive.

However, since this system is a life-critical system, it must be thoroughly tested and evaluated
to ensure accurate, reliable results. The system must be robust with 100% uptime.

System testing options will depend on the deployment method. The following plan does not do
any phase deployment. The deployment is essentially a direct deployment since no existing
systems are being replaced. The system test is extended (lengthened from the answer in
Chapter 9), due to the life-critical nature of the system to ensure that the system works well
prior to user acceptance testing. The acceptance test period is lengthy to ensure accuracy and
reliability.

Iteration Subsystem No of use Time Activities

cases
#1 Patient alert 1 3 weeks
#2 Patient alert 1 2 weeks begin integration testing
#3 Patient alert 1 2 weeks unit and integration tests
#4 Patient alert 2 3 weeks unit and integration tests
#5 Physician alert 3 4 weeks unit and integration tests
#6 Physician message 2 3 weeks unit and integration tests
#7 Patient message 2 3 weeks unit and integration tests
#8 Integration/ 8 weeks
system test
#9 Acceptance test 12 weeks
Total 40 weeks
Systems Analysis and Design in a Changing World, sixth edition 13-22

2. What are the documentation and user training requirements for the system, and when should
they be incorporated into the iteration schedule?

Answers will vary. There are many approaches that will work for this system.

Documentation: Since this system requires both hardware and software to be deployed,
documentation will need to cover both aspects of the system. How to use the hardware, and
how to use the applications. Separate documentation will be required for patients and medical
staff.
User (Patient) Documentation: Documentation should be provided on how to attach
and initialize the monitoring device, including any buttons, displays, etc. If there are
messages that display on the monitoring device, they should be explained. Additional
documentation should be provided on the phone application - including how to install it,
how to initialize it and how to use it.
User (Medical Staff) Documentation: Documentation should indicate how to install
the application on the medical staff computers. Also instructions on how to use the
software, including all of the options.
Technical Documentation (Equipment): Both how to initialize and how to check out
the equipment. Often equipment will have verification processes to make sure that it is
operating correctly. This should be well documented.
Technical Documentation (Applications): How to install and maintain the various
software applications on all the equipment.

Training should be conducted during the final stages of system test or at the beginning of
acceptance test. The medical staff must be trained in the operation and use of the system,
including all medical equipment and software. Medical staff must be trained to be able to train
patients when they begin to use the devices.

The documentation and training material should be created during the integration and system
test period.

As much as possible the application should be created with user friendly, intuitive menu items
and online instructions in order to minimize the need for extra documentation. Obviously, the
usability of the system should be an integral part of the design and development of the system.
Systems Analysis and Design in a Changing World, sixth edition 13-23

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.

This second project will have two major components. Each will be a different version of the
system.
1. Develop and integrate updates and modifications to the Android system.
(Version Android-1.2)
2. Develop and integrate the iPhone version. (Version iPhone-1.0)

Note: Updating the Andriod system will require new systems analysis to define the new
requirements.
Developing the iPhone version will be more design and implementation activities and will use
the same requirements as previously defined for the Android system.

Note: The project to update an existing system can be done either with a predictive approach
or an adaptive approach. Since the updates will tend to be smaller, and will be integrated into
an existing and known system, a predictive approach works well. In a predictive approach, the
first step is a complete analysis phase to precisely define all the changes across all subsystems.
A modified waterfall approach with analysis, design, implementation, and deployment is an
acceptable approach.
Systems Analysis and Design in a Changing World, sixth edition 13-24

This plan is for a predictive approach.

Predictive Modified Waterfall approach

Phase Activity Estimated Description
Time
#1 Define new requirements 3 weeks Analysis activities to determine and document
all update requirements. Initial ideas have
probably been collected during acceptance test
and productive use. This activity refines the
requirements into specifications.
#2 Android System Design 2 weeks Define precisely the changes that need to be
made to the Android system
#3 Programming, unit test, and 4 weeks Make the changes to the new Android version
integration testing of new
Android version
#4 Deploy Android for 4 weeks
Acceptance test
#5 Design iPhone system 2 weeks This activity can overlap with #3 and #4. If
separate developers, e.g. those with Apple
programming skills are used for the iPhone
system, then #5 can run concurrently with #3.
If the same programmers are used, then #5 can
run concurrently with #4.
#6 Programming, unit test, and 4 weeks The iPhone system is the patient system only,
integration testing of iPhone and will interface with the same back-end
system server and physician system. Using the same
data protocols, modifications to the back end
should be minimal.
#7 Deploy iPhone for 4 weeks Testing integration and patient system.
Acceptance test
Systems Analysis and Design in a Changing World, sixth edition 13-25

This is a plan for an adaptive approach.

Adaptive Iterative approach

Iteration Activity Estimated Description
Time
#1 Patient Alert and messaging 4 weeks Analysis, design and programming for
modifications updates to the Patient alert system.
for Android
#2 Physician Alert and 4 weeks Analysis, design, and programming for
messaging modifications updates to Physician alert system.
for Android
#3 Android system test 1 weeks
#4 Android Acceptance test 4 weeks
#5 iPhone Patient Alert and 4 weeks Design and implement of iPhone based on
messaging system design same requirements as Android new version.
and build This activity can possibly overlap with #3 and
#4.
#6 iPhone System test 2 weeks
#7 iPhone Acceptance test 4 weeks Testing integration and patient system.