Unit 7 system life cycle

System life cycle in order: Analysis
Design Development and testing implementation documentation Evaluation

click to edit

Analysis - During the analysis stage systems analysts investigate the existing system to identify exactly what the problems are with the existing system

Feasibility study-

For any project, the feasibility study will examine how realistic the proposed solution is, to meet the aims of the project. It will also compare and contrast the options put forward to complete the project. It will examine issues such as costs, manpower, timescale and so on.

At the end of a feasibility study, there will be recommendations on the best way forward (or the study may even recommend cancelling the project if it not feasible).

This is a relatively cheap way of checking that the project will succeed before a lot of money and time is spent on it.

Design-

Alternative possible solutions are identified

Alternative solutions evaluated

The best solution is identified

Validation and verification rules are put into place during the design stage

click to edit

Range check

Checks that a value falls within the specified range

EG. Number must be between 1-10

Length check

Checks the data isn't too short or too long

A username that is required to only be 10 characters long

Data type check

Checks that the data entered doesn’t have invalid characters

A field where only numbers should be entered like age, should not allow text to be entered

Format check

Checks the data is in the right format

Date has to be in the format of DD/MM/YYYY

Presence check

Checks the data is in the right format

Some fields can not be left blank

Consistency

A check that is performed to make sure that the data has no internal conflict

If male has been entered the title entered can not be 'Mrs.'

Check digit

The last one or two digits in a code are used to check the other digits are correct

Barcodes in the supermarket use check digits

Development and testing

click to edit

There are 4 main parts of development

Creating a file structure to store data

Systems that are required to hold data need to use file structure

File structures determine how the data is stored in the system and are made up of 4 parts:

Tables Fields Field Properties Records

Test data is entered into the fields to make sure that data is being data is being stored correctly

Create validation rules to make sure that the data entered is sensible

Validation checks will have been thought about and decided on during the design stage

Once all of the necessary validation checks have been programmed into the system, they are tested to make sure that they work

Create a user interface to allow data to be input into the system

User interfaces have to be created to allow users to input data into the system

The screens of a system that allow users to enter data into the system are called Data entry forms. Data entry forms should be well designed to make sure that they are easy to use.

A good entry form should include

Entries for all required fields

Make appropriate use of form controls

Include instructions about entering data

Make sure that the text boxes are big enough

Easy to understand

Create output formats

Two types of system outputs have to be created: onscreen and printed

The system developer will create all outputs by following designs provided

The developer will ensure that all hard copies are printable

Outputs are tested to check if they are clear and easy to use

Testing

To test a system you need a testing plan.

EG there is a range for data entered lets say 1-10

Any number between 1-10 would be a NORMAL value

Number 1 and 10 are Extreme values

Numbers outside the range or not written in integer format are ABNORMAL

Implementation

click to edit

Direct Changeover

The old system stops getting used one day and the new system is used the next day

The changeover is fast

ADVANTAGES:

Fastest way of changing systems

New system can be used automatically after installation

Cheap as you dont pay for two sets of staff

DISADVANTAGES

Staff have to be fully trained to use the system before its installed

If the new system fails all the data will be lost because the old system is completely removed and there is no back up

Difficult to plan

Parallel running

The old system and the new system will run alongside each other for a period of time

Data would be inputted into both systems producing two sets of results

When staff are certain about the new system the old one is shut off

ADVANTAGES

If the new system fails the old one is still available

Staff can be trained gradually

Good way to test the system using live data

Disadvantages

Expensive due to the price of running two systems at once

Pilot running

Involves introducing the new system to one part of the company and then rolling it out to other departments.

Good way to implement system without having to massively restructure the company

ADVANTAGES

If the system fails it only affects one part of the company

On a smaller scale and is easier to manage

Staff can be trained gradually

Cheaper

DISADVANTAGES

Takes a very long time

The department doing the testing might lose its data if the system fails

Phased implementation

New system is implemented in phases

ADVANTAGES

Staff can be trained gradually

Easier to find system errors

DISADVANTAGES

Expensive

Only suitable for systems that can be split

Takes a long time

Documentation

click to edit

Technical documentation is produced for the benefit of future developers of the system. This like a manual which explains how the system was developed and includes information like software and hardware requirements, file structures and coding used.

Why is it important?:

It gives future analysts, programmers and designers the knowledge needed to repair/maintain/improve the system.

Summary:

Technical documentation

Purpose of the system

Hardware requirement

Software requirement

Memory requirement

Copies of all system designs

Copies of system flowcharts

Explanation of file structures used

Programming language used to code the system

Listings of the code

Details of system bugs

User interface designs

Input formats

Output formats

Validation rules used

Meaning of error messages

Testing information

User documentation is produced for the benefit of the intended users of the system.

Why is it important?:

It explains to the users exactly how the system is supposed to be used.

Summary:

User documentation

Purpose of the system

Hardware requirements

Operating system required

How to open/load the system

How to log in and out of the system

How to search for system data

How to input new data

How to amend data

How to sort data

How to save files

How to print files

How to handle system errors

FAQs

Troubleshooting guides

Help guides

Evaluation

click to edit

Why is it important to evaluate?

Systems are evaluated to determine if:

The system is doing the job it was designed to do

The system is working well with minimum errors

Staff can use the system properly

GOOD EVALUATION INCLUDES:

Effective?

Does it work fast?

Does run smoothly?

Does it save the company time and money?

Does it reduce paper waste?

Easy to use?

Does it have a user-friendly interface?

Can everyone use it easily?

Can it be used with minimal training?

Appropriate?

Does it perform the job it was designed to do?

Are the clients happy with it?

Is there anything it cant do that it should?

HOW IS AN EVALUATION CARRIED OUT?:

Comparing the system against the initial requirements

Evaluating user's experiences

Identifying limitations of the new system

Identifying system improvements

FINAL IMPROVEMENTS:

Error correction

Add functionality

Performance improvement