System Development

11.1 Introduction
11.1.1 Project Selection
A business organization may have more than one reason for the introduction of
computers. Usually a particular area of the business is selected for computerization.
Reasons why an organization may computerize an area of business:

There is a large amount of data that requires repetitive processing.

There is a need for better access for up-to-date information.
Clerical costs could be reduced.

There may also be indirect benefits to customer service or cash flow.

For the project to be successful it must not be too complex.

11.1.2 The Systems Analyst

The job of the Systems Analyst:

Analyze the data processing requirements of the organization.

Decide whether the current system could be computerized.
Specify how the new system should work.
Take the responsibility for implementing the new system.

In order to do this the analyst must:

Have a very good understanding of the organization and how computers can be
used.

11.1.3 The Systems Life Cycle

Commercial systems all share a common life cycle pattern.
Business systems may need to change because of:

expansion
change of business activities
the economic situation
technological advances
or other factors

Prepared by A. Pryce

At this point a Systems Analyst is employed.

11.2 Analysis
11.2.1 Problem Definition
The first step is to write down the terms of reference.
The terms of reference may well include:
Objectives - What the system should achieve.

Improved customer service.

Prepared by A. Pryce

Better management information.

Cope with larger volumes of business.

Constraints

Maximum cost.
Available equipment.
Any business area not to be changed.

Timescale - A special constraint.

Reports - What output is required.
Suggested Solutions - By management.

11.2.2 Feasibility Study

Technological Feasibility
Is the hardware able to meet the demands put upon it?
Social Feasibility
What will be the effect on employees and customers if the new system is implemented?
Economic Feasibility
Will the new system be cost effective?

11.2.3 Further Analysis

Fact Recording And Investigation
The analyst is interested in:

The procedures
The data
The future
News reports
Problems

The following are ways of investigating existing procedures and the existing problems:

Observation
Reading existing documentation
Questionnaires

Prepared by A. Pryce

Task counting - by clerical staff

Interviews

11.3 Design
In designing a new system all aspects of the design must be documented.

11.3.1 Systems Specification

This involves:

designing screen layouts and reports formats.

specifying file contents and organization.

11.3.2 Prototyping
This is an aid to better, faster, systems design.
In a computing context, prototyping involves building a simple model of software under
development.
This could involve using special software to quickly design input screens and validate
data input.
This gives the user a chance to experience the look and feel of the input process.
Note that prototyping would also be used during analysis.

11.3.3 Computer Aided Software Engineering (CASE)

These are software tools that insist in the design or development of a system.
Examples of CASE software:

Graphics Tools - to draw structure diagrams, data flow diagrams, etc.

Interface Generator - for rapid prototyping.
Project Management Tools - schedule the steps in analysis, design, coding and
testing.

11.3.4 Design Choices

Firstly decide upon:
Processing Method

Prepared by A. Pryce

The systems designer will need to chose between Batch Processing and On-Line
Processing. This decision will be dependant on:

how often the data changes.

the volume of data.
the cost of hardware.
how the data is collected.

Software Solution
In general there will be many different solutions to a problem.
The following affect this choice:

Usability
Performance
Suitability
Maintenance

Hardware Solution
This depends on many factors, for example:

The software
Volume of data
Number of users and their locations
Processing method
Security considerations

11.4 Graphical System Representation

There are several various methods for representing computer systems.

11.4.1 Data Flow Diagrams

This type of representation is concerned with how data moves through a system not with
such details as what type of data storage is used.
Source or destination of data external to the system.

Prepared by A. Pryce

An operation on data which transforms it.

Any stored data without reference to the physical method of

storage.
This represents the movement of data between any of the above.
Conventions
1. Data flows may not go directly to and from data stores and entities.
2. Data flows must be labeled to indicate what data is been transferred.

11.4.2 System Flow Charts

A systems flow chart shows an overview of the whole system. In particular it represents:

Tasks to be carried out.

The hardware devices.
The inputs, outputs and storage media.
The files.

Input/Output

Keyboard Input

Process

Manual Operation

Sort

Prepared by A. Pryce

Off Page Connector

Online Storage

Magnetic Tape

Disk Storage

Visual Display

Written or Printed Document

Example
Data validation of mail order forms.

Prepared by A. Pryce

11.5 Development
11.5.1 Program Development
Each program in the system must have a specification written for it, which describes what
it will do (and how it will do it).
The program specification could be accompanied by:

Jackson Structure Diagrams (JSD)

Pseudocode
Flowcharts

Applications Generator
These are software tools that generate complete systems. The user defines the input,
output, data, files and what the system needs to do. The applications generator then
produces the program code.
Report Generator
A report generator will produce reports from information supplied by the user. The way
that they work is that the user supplies the headings, the fields to be printed, what order
they are in, the space to allow for each field and what totals are required.
CASE Tools For Development
The CASE software tools that aid the programmer in the development stage are:
Prepared by A. Pryce

A source code generator

A data dictionary tool

Applications Packages
Programs may not need to be written for the new system. If an "off-the-shelf" package
may be suitable then it is the analyst's job to evaluate the package and make sure that it
will meet the requirements.

11.5.2 Equipment Acquisition

Following the hardware considerations in the design stage of the life cycle, suitable
equipment needs to be acquired.

11.6 Testing
11.6.1 Acceptance Testing
The tasks the finished system must perform in order to be accepted (by the user) can be
used as the basis for different tests.

11.6.2 Program Testing Strategies

Bottom-Up Testing
The individual modules are tested in a stand-alone fashion. The individual modules are
combined and tested. Finally, a system test is performed.
Top-Down Testing
The whole system (or at least a skeleton of it) is tested. Individual modules, yet to be
completed, are replaced by 'stubs'. Stubs often display a message on screen to show that
the module has been called.

11.6.3 The Test Plan

A test plan should be developed which will go through as many paths as possible in the
system.
For each test the following points should be included:

the test's purposes.

the test's location.
a description of the test.
testing procedure.

Prepared by A. Pryce

Test data should test the program to its limits.

It should include:

data in the extremes

invalid data
commonly entered data

11.6.4 Objectives Of Testing

We need to ask:
Does the logic work properly?
- does it work as intended?
- any runtime errors?
Is all the logic present?
- any functions or sub-programs missing?

11.6.5 White And Black Box Testing

White Box Testing (or Logical Testing)
We test the program by examining the code and trying to test each possible path in the
program at least once.
Black Box Testing (or Functional Testing)
In Black Box we are not concerned with the program code. The program specification is
used as the basis for producing a set of test data that covers all the inputs, outputs and
program functions

11.6.6 Other Types Of Testing

Performance Testing
The system is tested to see if it can handle the volume of data anticipated in the user
environment.
Recovery Testing
Here we need to ensure that the system can recover from various types of failure.
Such tests can be performed by simulating hardware or power failures.

Prepared by A. Pryce

10

11.7 Implementation
11.7.1 Hardware Installation
Before the new system can come into operation hardware will probably have to be
installed. This may include:

New computers
New peripherals
New office layout and furniture

11.7.2 Staff Training

Prior to the new system going live, all the staff involved in the system will need hands on
training.
Realistic data should be used in briefing.

11.7.3 Creation Of Master Files

All the master files will have to be created before the system can be used.
Typically, there are two phases:
Phase 1
All the data that will not change can be typed in over a few days or weeks.
Phase 2
Data that is liable to change needs to be keyed in just before the changeover to the new
system.

11.7.4 Conversion Methods

a. Direct Changeover
The organization stops using the old system one day and starts using the new
system the next.
Advantages
o
o
o

Fast
Efficient
Little or no duplication of work

Prepared by A. Pryce

11

Disadvantages
o

If the new system fails then there will be serious disruption

b. Parallel Conversion
The old system is kept running alongside the new system for a few weeks or
months.
Advantages
o
o

The old system can be relied upon while any problems with the new
system are fixed
Results from the new system can be checked against the old system

Disadvantages
o

There's a heavy workload on staff

c. Phased Conversion (Direct or Parallel)

This is used with larger system that can be broken down into several stages.
Each part of the system can be implemented at different times.

d. Pilot Conversion
Only a part of the organization uses the new system at first.

11.8 Maintenance
11.8.1 Post Implementation Review
This is carried out several weeks or months after the system has been implemented.
Small changes may need to be made:
For example:

Prepared by A. Pryce

12

Correct program errors

Amend clerical procedures
Modify screen and report formats

11.8.2 Perfective Maintenance

Here we are concerned with taking an acceptable system and making it better.

11.8.3 Adaptive Maintenance

As the system requirements change, the system needs updating.

11.8.4 Corrective Maintenance

There may still be problems with our system that need to be corrected.

11.9 System Documentation

11.9.1 The Aims Of Documentation

To assist system design

To ensure everyone understands how their aspect of the system should work
To help greatly in system maintenance

11.9.2 The Documentation Contents

A system specification
System flow charts or data flow diagrams

Program descriptions

Structure diagrams, program flow charts and pseudocode

Files or database descriptions

Layouts for screen display and reports

Current program listings

Test data with expected results

Clerical procedures manual

This describes the activities that clerical staff undertake when preparing data for
input to the system.

Prepared by A. Pryce

13

It will also detail what action should be taken if an error occurs.

Operating instructions
This tells the computer operator how to run the program.

Data preparation instructions

This details how to enter data what format the data should be in.

11.9.3 Documenting A Software Package

This may include:

A user manual
A technical manual/operations manual
Tutorials

Prepared by A. Pryce

14