11.

1 Introduction
11.1.1 Project Selection

A business organisation may have more than one reason for the introduction of computers. Usually a
particular area of the business is selected for computerisation.

Reasons why an organisation may computerise 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:

 Analyse the data processing requirements of the organisation.

 Decide whether the current system could be computerised.

 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 organisation and how computers can be used.

11.1.3 The Systems Life Cycle

Commercial systems all share a commom life cycle pattern.

Business systems may need to change because of:

 expansion

 change of business activities

 the economic situation

 technological advances

 or other factors
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 acheive.

 Improved customer service.

 Better management information.

 Cope with larger volumes of business.

Constraints

 Maximum cost.

 Avaliable 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

 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

The systems designer will need to choose between Batch Processing and On-Line Processing. This
decision will be dependent 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.

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

Off Page Connector

Online Storage
 Magnetic Tape

Disk Storage

Visual Display

Written or Printed Document

Example
Data validation of mail order forms.
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)

 Psuedocode

 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:

 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, sutiable 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.

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

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 organisation stops using the old system one day and starts using the new system the next.

Advantages

o Fast

o Efficient

o Little or no duplication of work

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 The old system can be relied upon while any problems with the new system are fixed

o 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 organisation 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:

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

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