MAKING THE SYSTEM

OPERATIONAL
16

CHAPTER OUTLINE
Program Development
Quality Assurance
Data Conversion

LEARNING OBJECTIVES
Describe implementation and support activities
Choose an appropriate approach to program development
Describe various types of software tests and explain how and why each is used
List various approaches to data conversion

OVERVIEW

Implementation & Support

Implementation
Activities that occur before the system is turned over to its users are collectively

Support
Activities that occur after the system becomes operational are collectively

PROGRAM DEVELOPMENT
The creation on an entire information system and all related software.

Program development (including unit testing) typically accounts for at least onethird of all development labor. It also accounts for between one-third and one-half of the
project development schedule.

PROGRAM DEVELOPMENT

ORDER OF IMPLEMENTATION
Input, Process, Output Development Order ( IPO )
o A development order that implements input modules first, process modules next, and output

modules last

PROGRAM DEVELOPMENT

ORDER OF IMPLEMENTATION
Input, Process, Output Development Order ( IPO )
o A development order that implements input modules first, process modules next, and output

modules last
IPO development order can also be
applied to object-oriented (OO)
designs and programs.
The key issue to analyze is
dependencythat is, which classes
and methods capture or generate
data that is needed by other classes
or methods.

PROGRAM DEVELOPMENT

ORDER OF IMPLEMENTATION
Top-Down and Bottom-Up Development Order
Both terms describe the order of implementation with respect to a modules location within a

structure chart.

Top-down development begins with the

module at the top of the structure chart.

Bottom-up development begins with the

set of modules at the lowest level of the
structure chart.

PROGRAM DEVELOPMENT

ORDER OF IMPLEMENTATION
Top-Down and Bottom-Up Development Order
Both terms describe the order of implementation with respect to a modules location within a

structure chart.
Top-down and bottom-up program development can
also be applied to OO designs and programs.
The key issue is method dependencythat is, which
methods call which other methods.

PROGRAM DEVELOPMENT

ORDER OF IMPLEMENTATION
Top-Down and Bottom-Up Development Order
Both terms describe the order of implementation with respect to a modules location within a

structure chart.

Method dependency can also be

documented in a sequence diagram.

PROGRAM DEVELOPMENT

ORDER OF IMPLEMENTATION
Other Development Order Considerations
Testing and construction are highly interdependent. For this reason, a formal plan covering

both testing and construction is normally created before either activity begins.
The construction and test plan covers many specifics, including the following:
Development order
Testing order
Data used to test modules, module groups, methods, classes, programs, and subsystems
Acceptance criteria
Personnel assignments (construction and testing)

PROGRAM DEVELOPMENT

FRAMEWORK DEVELOPMENT
When implementing a large OO system, it is not unusual to build an object framework (or set

of foundation classes) that covers most or all of the domain and data access layer classes.
Foundation classes are typically reused in many parts of the system and across many

different applications.
Foundation classes are typically implemented first to minimize the impact of errors and

changes.

PROGRAM DEVELOPMENT

TEAM-BASED PROGRAM DEVELOPMENT

A team of programmers normally works on program development.
Using multiple programmers compresses the development schedule by allowing many
portions of the system to be developed simultaneously.
Management issues:
Organization of programming teams
Task assignment to specific teams or members
Member and team communication and coordination

PROGRAM DEVELOPMENT

TEAM-BASED PROGRAM DEVELOPMENT

Cooperating peer team includes members of roughly equal skill and experience with

overlapping areas of specialization.

Chief developer team a team with a single leader who makes all important decisions.
Collaborative specialist team a team with members who have wide variation in and

minimal overlap of skills and experience.

PROGRAM DEVELOPMENT

SOURCE CODE CONTROL

An automated tool for tracking source code files and controlling changes to those

files.

The SCCS acts the way a librarian wouldit implements check-in and checkout

procedures, tracks which programmer has which files, and ensures that only
authorized users have access to the repository.

Programmers can manipulate files in the repository as follows:

Check out a file in read-only mode
Check out a file in read/write mode
Check in a modified file

PROGRAM DEVELOPMENT

VERSIONING
Complex systems are developed, installed, and maintained in a series of versions to

simplify testing and support.

A system version created during development is called a test version.

Alpha version a system

that is incomplete but
ready for some level of
rigorous testing.

Beta version a system

that is stable enough
to be tested by end
users.

Production version, release

version, or production release a
system that is formally distributed
to users or made operational.

Maintenance release a
system update that provides
bug fixes and minor changes
to existing features.

PROGRAM DEVELOPMENT

VERSIONING

QUALITY ASSURANCE
The process of ensuring that an information system meets minimal quality standards.
QA activities during implementation consist primarily of testing.
QA activities are often shortchanged during design and especially during implementation.

This lapse occurs for several reasons, including the following:

Schedule pressures can build as the project progresses.
QA activities require development personnel to open their work to thorough
examination and criticism by others.
Many people view testing and test personnel as the bearers of bad news.

QUALITY ASSURANCE
The process of ensuring that an information system meets minimal quality standards.
QA activities during implementation consist primarily of testing.
QA activities are often shortchanged during design and especially during implementation.

To avoid issues mentioned:

Formally integrate QA into the project and schedule from the beginning and never

abandon it.

Quality standards should be clearly stated, be measurable, and require a product that

doesnt meet those standards to be fixed no matter what the effect on the schedule or
budget.

Build an environment of openness, collegiality, and mutual respect among project

participants.

QUALITY ASSURANCE

TECHNICAL REVIEWS
A formal or informal review of design or construction details by a group of developers.

Some organizations use informal processes, while others adopt formal procedures.
A walkthrough is a review
by two or more people of
the accuracy and
completeness of a model
or program.

Inspection a formal review of

design or construction details by
a group of developers, where
each person plays a specific
role

Walkthroughs and inspections are important QA processes because they can detect errors
before code has been written.

QUALITY ASSURANCE

TESTING
Testing is the process of examining a product to determine what defects it contains.

Software Testing
Components can be tested individually or in groups,
or the entire system can be tested as a whole.

QUALITY ASSURANCE

TESTING
Testing is the process of examining a product to determine what defects it contains.

The Three Testing Types:

o Unit Testing is testing components individually.
o Integration Testing is testing components in groups.
o System Testing is testing entire systems.

QUALITY ASSURANCE

TESTING
Testing is the process of examining a product to determine what defects it contains.

An important part of developing tests is specifying test cases and data.

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, a
group of modules, or an entire
system

QUALITY ASSURANCE

TESTING
Testing is the process of examining a product to determine what defects it contains.

Unit Testing
The process of testing individual code modules before they are integrated with
other modules.
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).

QUALITY ASSURANCE

TESTING
Testing is the process of examining a product to determine what defects it contains.

Modules can call other software units to

perform tasks or can be called by other
modules.
Two Types of Testing Modules:
driver
a module, developed for
unit testing, that simulates
the calling behavior of a
module that hasnt yet
been developed

stub
a module, developed for
testing, that simulates the
execution or behavior of a
module that hasnt yet been
developed

QUALITY ASSURANCE

TESTING

QUALITY ASSURANCE

TESTING
Testing is the process of examining a product to determine what defects it contains.

Integration Testing
A test of the behavior of a group of modules or methods
The purpose of an integration test is to identify errors that were not or could not be
detected by unit-testing individual modules or methods

QUALITY ASSURANCE

TESTING
Testing is the process of examining a product to determine what defects it contains.

Integration Testing
Such errors might result from a number of problems, including the following:
Interface incompatibility.
Parameter values.
Run-time exceptions.
Unexpected state interactions.

QUALITY ASSURANCE

TESTING
Testing is the process of examining a product to determine what defects it contains.

System Testing
Tests the behavior of the entire system
To identify significant issues such as performance problems that must be addressed in
the next iteration.

QUALITY ASSURANCE

TESTING
Testing is the process of examining a product to determine what defects it contains.

System Testing
Build and smoke test
A system test that is performed daily

QUALITY ASSURANCE

TESTING
Testing is the process of examining a product to determine what defects it contains.

Usability Testing
A test to determine whether a module, method, class, subsystem, or system meets
user requirements
Evaluates functional requirements and the quality of a user interface.

QUALITY ASSURANCE

TESTING
Testing is the process of examining a product to determine what defects it contains.

Usability Testing
Performance test
Checks time-based requirements
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

QUALITY ASSURANCE

TESTING
Testing is the process of examining a product to determine what defects it contains.

Usability Testing
Acceptance test
A system test that determines whether the system fulfills user requirements

DATA CONVERSION
Data needed at system startup can be obtained from the following sources:

Files or databases of a system being replaced

Manual records
Files or databases of other systems in the organization
User feedback during normal system operation

DATA CONVERSION

REUSING EXISTING DATABASES

The old system database is used directly by the new system with little or no change to

the database structure

DATA CONVERSION

RELOADING DATABASE CONTENTS

More complex changes to database structure might require reloading data after the

change.

The first approach initializes a new database and copies the contents of the old database to it.
The second approach uses a program to extract and delete data from an existing database
and store it in a temporary data store.

DATA CONVERSION

CREATING NEW DATABASES

If the system being developed is entirely new or if it replaces a manual system, initial

data must be obtained from manual records or from other automated systems in the
organization.