System Life Cycle

Introduction
 A systems analysis team is often brought in to review an existing system and suggest
several improvements
 The existing method used may be either a manual paper-based system or a computer-
based operation that is no longer regarded as adequate for the task

Analysis
 The basic steps in the analysis stage can be summarized as follows:

1. Fact finding/collecting data from the current system

2. Description of the current system – establishing the inputs, outputs and processing
being done
3. Identification of the problems with the current system
4. Agreeing the objectives with the customer
5. Identifying and agreeing the customer’s requirements
6. Interpreting the customer’s requirements
7. Producing a cost-benefit analysis
8. Producing a data flow diagram

4 Common Methods of Fact Finding

Observation
 Involves watching personnel using the existing system to find out exactly how it works
Advantages
 The analyst obtains reliable data
 It is possible to see exactly what is being done
 It is a relatively inexpensive method
 Disadvantages
 People are generally uncomfortable being watched and may work in a different way
 If workers perform tasks that violate standard procedures, they may not do this while
being watched

Interviews
 Involves a one-to-one question-and-answer session between the analyst and the
employee/customer

Advantages
 It gives the opportunity to motivate the interviewee into giving open and honest answers
to the analyst’s questions
 It allows the analyst to probe for more feedback from the interviewee, as it is easier to
extend a question
 It is possible to modify questions as the interview proceeds and ask questions specific
to the interviewee
 It is a good method if the analyst wants to probe deeply into one specific aspect of the
existing system

Disadvantages
 It can be rather time consuming
 It is relatively expensive, due to the use of the analyst’s time
 The interviewee cannot remain anonymous

Questionnaires
 Involves sending out questionnaires to the work force and/or to customers to find out
views of the existing system and find out how some key tasks are carried out

Advantages
 The questions can be answered quite quickly
 It is a relatively inexpensive method
 Individuals can remain anonymous if they want
 It allows quick analysis of the data

Disadvantages
 Often the number of returned questionnaire is low
 The questions are rather inflexible since they have to be generic
 There is no immediate way to clarify a vague or incomplete answer to a question

Looking at Existing Paperwork

Allows the analyst to see how the paper files are kept, look at operating instructions and
training manuals, check the accounts, etc.
Advantages
 It allows information to be obtained which was not possible by any of the other methods
 The analyst can see for themselves how the paper system operates
 It allows the analyst to get some idea of the scale of the problem, memory size
requirements, type of input/output devices needed
 Disadvantages
 It can be very time consuming
 Because of the analyst’s time, it is a relatively expensive method

Design
 Once the analysis has taken place and the systems analyst has some idea of the scale
of the problem and what needs to be done, the next stage is to design the key parts of
the recommended system
A list of tasks is summarized here
 Designing data capture forms/input forms
 Designing screen layouts
 Designing output forms and reports
 Producing systems flowcharts and/or pseudo code
 Selecting and designing validation rules that need to be used
 Selecting the most appropriate data verification methods
 Designing and agreeing the file structures and tables
 Selecting and designing the hardware requirements
 Selecting and designing the software requirements
 Producing algorithms or program flowcharts
 Designing a testing strategy/plan

Verification
 A way of preventing errors when data is copied from one medium to another
 Double entry: data is entered twice, sometimes by two different people
 The computer compares the two entries, either after data entry or during the data entry
process, and identifies any differences
 Visual check: checking for errors by comparing entered data on the screen with the
data in the original document (not the same as proof reading)

Validation
 Process where data is checked to see if it satisfies certain criteria when input into a
computer, for example to see if the data falls within accepted boundaries
 Range Check: Checks whether data is within given/acceptable values.
 E.g. A person’s age should be in range > 0 but < 150
 Length Check: Checks if the input data contains the required number of characters
 E.g. If a field needs six digits then inputting a five- or seven-digit number, for example
should cause an error message
 Character/type Check: Checks that the input data does not contain invalid characters
E.g. A person’s name should not contain any numbers, but a person’s height should
only contain digits
 Format/picture Check: Checks that data is in a specific format
E.g. Date should be in the form dd/mm/yyyy
 Limit Check: Similar to range check except that only one of the limits (boundaries) is
checked
E.g. Input data must be > 10
 Presence Check: Checks if data is actually present and has not been missed out
E.g. In an electronic form, a person’s telephone number may be a required field and if
no data is present this should give rise to an error message
 Consistency Check: Checks if fields correspond (tie up) with each other
E.g. If ‘Mr’ has been typed into a field called title then the gender field must contain
either ‘M’ or ‘Male
 Check Digit: Look at an extra digit which is calculated from the digits of a number and
then put on the end of the number
E.g. Check digits can identify three types of error:
 If two digits have been inverted during input
 An incorrect digit entered twice
 A digit missed out altogether

Development & Testing

 Once the design stage is completed, it is then necessary to create the system and fully
test it
 This section considers some of the development stages and testing strategies which are
often adopted by system analysts

Development stages
 If the system contains files (e.g. a database) then the file structure needs to be finalized
at this stage (e.g. what type of data is being stored in each field, length of each field,
which field will be the key field, how the data files will be linked, etc.)
 Once the file structure has been determined, it is then created and fully tested to make
sure it is robust when the system actually goes live
 Since it is important that correct data is stored in files, there are certain techniques that
need to be adopted to make sure the data populating the file and database is at least of
the right type & that it conforms to certain rules
 Validation routines and verification methods are used to ensure this happens
 Again, routines have to be fully tested to ensure they trap unwanted data but also to
make sure any data transferred from a paper-based system to an electronic system has
been done accurately
 Any system being developed will have some form of user interface
 The types of hardware were chosen in the design stage
 How these are used to interface with the final system now needs to be identified, for
example how the screens will be used to collect the data and the way the output will be
presented
 If specialist hardware is needed (e.g. for people with disabilities), then it will be
necessary to finalize how these devices are used with the system when it is
implemented
 This will be followed by thorough testing to ensure the user screens are user friendly
and that the correct output is associated with the inputs to the system

Testing strategies
 Testing of each module needs to be done to ensure each one functions correctly on its
own
 Once the development of each module(part) is completed, the whole system needs to
be tested (i.e. all modules functioning together)
 Even though each individual module may work satisfactorily, when they are all put
together there may be data clashes, incompatibility and memory issues
 All of this may lead to a need to improve the input and output methods, file and
database structures, validation and verification methods
 Then the system will need to be fully tested again
 It is a very time-consuming process but the system must be as perfect as possible
before it goes live.
 Testing will use many different types of data, which will fall into one of three categories:
normal, extreme or abnormal
 Let us suppose one of the fields in a database is the date and this must be in the form
dd/mm/yyyy, where each element of the date must be numeric:
 Normal: this is data which is acceptable/valid and has an expected (known) outcome,
e.g. the month can be any whole number in the range 1 to 12
 Extreme: this is data at the limits of acceptability/validity, e.g. the month can be either of
the two end values i.e. 1 or 12
 Abnormal: this is data outside the limits of acceptability/validity and should be rejected
or cause an error message
 For example, all the following values are not allowed as inputs for the month:
 Negative numbers (e.g. -1, -15)
 Any value greater than 12 (e.g. 32, 45)
 Letters or other non-numeric data (e.g. July)
 Non-integer values (e.g. 3.5, 10.75)

Implementation
 Once the system is fully tested, the next stage is to fully implement it
 We will now consider changeover to the new system in more depth
 There are four common methods used for changing over from the old system to the new
system
 Each one has advantages and disadvantages which need to be weighed up before the
most appropriate method is chosen for a particular application

4 Common Methods of Changing Systems

Direct method
 The old system is stopped overnight and the new system introduced immediately
 Advantages
 The benefits are immediate
 Costs are reduced - since only one system is used there is no need to pay for two sets
of staff
 There is less likelihood of a malfunction since the new system will have been fully tested
 Disadvantage
 This method can be disastrous if the new system fails
Parallel Running method
 The old and new systems are run side by side for a time before the new system takes
over altogether
 Advantages
 If the new system fails, the old system is still available as a back-up
 It is possible to train staff gradually
 Staff have time to get used to the new system
Disadvantage
 It is more expensive than direct changeover, since extra staff are needed to run both
systems together

Pilot Implementation method

 The new system is introduced into one part of the company (e.g. into a warehouse of a
supermarket) and its performance assessed

Advantages
 If the new system fails, only one part of the company is affected
 It is possible to train staff in one area only, which is much faster and less costly than
parallel running
 The costs are also less than parallel running, since only one part of the system is being
used in the pilot

Disadvantage
 It is more expensive than direct changeover, since each pilot scheme needs to be
evaluated before the next stage is introduced

Phased Implementation
 Initially, only part of the new system is introduced
 Only when it proves to work satisfactorily is the next part introduced, and so on, until old
system is fully replaced

Advantages
 If the latest part fails, it is only necessary to go back in the system to the point of failure,
hence failure is not disastrous
 It is possible to ensure the system works properly before expanding
 Disadvantages
 This is more expensive than direct changeover, since it is necessary to evaluate each
phase before moving to the next stage
 Comparing Changeover Methods
Changeover method Direct Parallel Pilot Phased

Mediu
Relative costs Low High Medium
m

Input needed by the user Medium High Low Medium

Input needed by systems Mediu

Low* Low Medium
team m

Impact of failure High Low Low Medium

Documentation
 Once the new system is fully developed, a considerable amount of documentation
needs to be produced
 For the end user
 For people who may need to modify or develop the system further at some later stage
 There is some overlap between the two types of documentation, but the basic
requirements are shown below

Technical Documentation
 Technical documentation is designed to help programmers & analysts who need to
make improvements or repair/maintain to the system
 This can consist of any of the following:
 purpose of the system/program/software
 program listing/coding
 programming language used
 flowchart/algorithm
 input formats
 hardware requirements
 software requirements
 minimum memory requirements
 known bugs in the system
 list of variables used (and their meaning/description)
 file structures
 sample runs (with test data and results)
 output formats
 validation rules
 meaning of error messages

User Documentation
 User documentation is designed to help users to learn how to use the software or
system
 This can consist of any of the following:
 the purpose of the system/program/software package
 how to log in/log out
 how to load/run the software
 how to save files
 how to do a search
 how to sort data
 how to do printouts
 how to add, delete or amend records
 screen layouts (input)
 print layouts (output)
 hardware requirements
 software requirements
 sample runs (with test data and results)
 error handling/meaning of errors
 troubleshooting guide/help lines/FAQs
 tutorials

Evaluation
 Once a system is up and running it is necessary to do some evaluation and carry out
any maintenance, if necessary.
 This is done to ensure the efficiency of the system, the ease of use of the system, and
the appropriateness of the system.
 The following is a list of some of the things considered when evaluating how well the
new system has worked. This can ultimately lead back to a re-design of part of the
system if there is strong evidence to suggest that changes need be made.
 To evaluate the system, the analyst will:
 compare the final solution with the original requirement
 identify any limitations in the system
 identify any necessary improvements that need to be made
 evaluate the user’s responses to using the new system
 compare test results from the new system with results from the old system
 compare the performance of the new system with the performance of the old system
 observe users performing set tasks, comparing old with new
 measure the time taken to complete tasks, comparing old with new
 interview users to gather responses about how well the new system works
 give out questionnaires to gather responses about the ease of use of the new system
 Some results from the evaluation may require changes to either hardware or software.

Hardware may need to be updated because:

 of feedback from end users
 new hardware comes on the market, making change necessary
 there are changes within the company which require new devices to be added or
updated
 Software may need to be updated because:
 of feedback from end users
 changes to the company structure or how the company works may need modifications
to the software
 changes in legislation may need modifications to the software