THE SYSTEMS LIFE CYCLE

REASONS FOR A NEW SYSTEM

• The existing computer equipment is now obsolete (it cannot be
repaired anymore).
• Changes to laws or taxes requiring radical overhaul of software.
• More suitable hardware is now available to improve efficiency
and reliability.
• There is a need to expand the company.
• A systems analyst is brought in to oversee the whole upgrade
process
 DUTIES OF A SYSTEMS ANALYST

• Analyzing the existing (current) system.

• Suggesting a number of improvements that can be
made.
• Costing
• Stating advantages of the proposed system over the
current system.
• Once a new system is agreed and it has been fully
tested, it is then installed.
• It needs to be fully evaluated and any changes made
where necessary.
• Therefore, a cycle of events take place until a fully-
working system is signed off and handed over to the
management team.
• This whole process is called the systems life cycle.
SYSTEMS LIFE CYCLE
 ANALYSIS

• The first stage

in the process is
the analysis of
the current
system. Figure
below shows the
stages in
analysis
 ANALYZING THE CURRENT SYSTEM
• There are four methods used to research the current
system.
➢Observation
➢Questionnaires
➢Interviews
➢Examination of existing documents.
 OBSERVATION

• This method involves watching personnel using the

existing system to find out exactly how it works.
 INTERVIEW

• This method involves a one to one question and answer

session between the analyst and the user.
• It is a good method if the analyst wants to probe deeply
into one specific aspect of the existing system.
 QUESTIONNAIRES

• This method involves distributing questionnaires to

the workforce, clients or system users to find out their
views of the existing system and to find out how
some of the key tasks are carried out.
 EXISTING DOCUMENTS

• This method allows the analyst to see how existing files

are kept, look at operating instructions and training
manuals, check the accounts, etc.
• This allows the analyst to get some idea of the scale of the
problem, memory size requirements, type of input/ output
devices needed, etc.
 RECORD AND ANALYSE INFORMATION
ABOUT THE CURRENT SYSTEM

• This stage in the process requires the analyst to find out:

• What input and output takes place.
• What processing is done.
• What problems exist with the current system.
• User and information requirements for the new system
• One method the
analyst can use is
a data flow
diagram (DFD).
• An example of a
DFD that follows
the reservation
system when
booking a flight
on an aeroplane.
• From the DFD, we can get the following information:
oWhat inputs take place during the customer enquiry (in
this case, a customer keys in their flight details, such as
names of passengers, passport numbers, dates of flight,
and so on)
oWhat outputs are produced (in this case, on-screen and
e-ticket (QR code) sent to customer’s smartphone)
oWhat processing is done (check flights, process
customer data, allocate flight reference number and
access booking database; customer flight booking has to
be added to database once all processing completed).
oWhat storage may be needed (a database is needed to
store all the flight booking details).
• As the analyst looks at each stage in the DFD process, they
will then identify:
❖Any problems that occur in the current system (this is
done by looking at the data flows in each stage of the
process and looking for bottlenecks and other potential
areas where errors do or could occur)
❖User and information requirements (see below)
 USER REQUIREMENTS
• computer system developers do not really understand how
a business works.
• Business managers do not really know how computer
systems could help them.
• The user requirements are designed to help with this
problem.
 INFORMATION REQUIREMENTS
• This is the information needed to support the business.
• The information requirements are made up of:
• what? (that is, the data)
• when? (that is, the timing).
• A systems analyst turns the information and user
requirements into a functional requirements specification.
 SYSTEM SPECIFICATION

• The DFD and other information gathering processes

allow the analysis team to identify what hardware and
software is needed to run the new system.
• Identify and justify hardware
• Identify and justify software
 IDENTIFY AND JUSTIFY HARDWARE
• Input devices might be for example: barcode readers (using
barcode readers avoids the need to manually input data about
goods, which is more efficient, less error-prone and less
expensive in the long run).
• Output devices might be for example: 3D printer (if the company
are manufacturing toys, it is much more cost-effective to do a
‘one off’ using a 3D printer than making a toy in the conventional
way)
 IDENTIFY AND JUSTIFY SOFTWARE
• Operating system.
• Applications software:
• off-the-shelf software, which would save a lot of
development time and costs, (such as Word or Excel).
• Bespoke software (written specifically for the company) –
this will require considerable time and money to develop.
• Storage requirements also need to be considered;
• Size of storage
• Type of storage:
• hard disk drives
• Solid-state drives
• Magnetic tape drives
 DESIGN

• Once the analysis of the existing system has taken place.

• The systems analyst has a better idea of the scale of the
problem
• Then the next stage in the process is design.
 FILE STRUCTURES AND DATA
STRUCTURES

• In this stage, the following are considered:

• How the files containing data will be structured.
• The format of the data types being stored in the
files.
• A file is made up of a number of records.
• Each record is broken up into fields.
• One of the fields must be unique and will act as the
primary key field
• This is to allow each record to be uniquely identified.
AN EXAMPLE
• Each field in the record now needs to be totally defined as
follows:
• Field name (for example, product code).
• Field length (what is the maximum number of characters
that need to be stored)
• data type
• primary key field here will be product code because it is
unique.
Data type Description Examples
Alphanumeric This type of data can store alpha characters (letters or A345FF or
text) and numeric data (numbers) 07432011122
Character This is just a single letter (or text X or d
Text This can be a string of letters or numbers or other symbols example_of_text_ string

Boolean This data type stores data in a Yes/No or True/False Y or N

format (logical options
This data type is used to store numeric data which is used
to perform calculations (this does not include telephone
numbers, for example, because these have to be stored as
alphanumeric data)
There are several different types of numeric data:
Numeric
Integer (whole numbers) 234 or −1245
Decimal/real (non-integer values) 25.54 or −150.22
Currency (allows inclusion of currency symbols) $24.55 or €123.50
Date/time (allows dates and time to be stored) 14/05/2020 or 12:45
FIELD NAME FIELD LENGTH DATA TYPE

Product code

Year of make

Product description

Price

Department
 VALIDATION ROUTINES
• It is the process where data entered into a computer is checked
to see if it satisfies certain criteria.
• It is an automatic check carried out by the computer as part of
its programming.
• It is not a check on whether the data is correct or accurate; it is
only a check to see if it is reasonable.
Validation Description Example
check
Range Checks to see if the data input lies between an Temperature range from
acceptable upper and lower value 10 to 50 degrees celcius
Type/charact Checks to see if the data entered is of the Name should not contain
er correct type (i.e. letter or number only) numbers
Length Checks to see if the data input contains only the Password with 8
required number of characters characters should decline
those with less.
Format Checks to see if the data input is in the correct Date format entered
format correctly, dd/mm/yyyy
Presence checks that data has been entered into a field. Required field like name

Check digit This is an extra digit added to a number which 13597 instead of 13579
has been calculated from the other digits 13559 instead of 13579
 INPUT FORMATS (DATA CAPTURE FORMS)
• Used to input data into the computer.
• These forms ensure data is input into the computer in the
correct format.
• Need to be designed carefully to ensure that the format of the
data matches the database where the data is being stored.
• They can either be paper-based or electronic-based depending
on the application
 PAPER BASED FORMS
• have a heading to make the purpose of the form clear.
• Make it clear to the person filling in the form where they must
place their answers.
• Make use of text boxes which will limit the amount of
information collected.
• Make use of character boxes for data such as surnames,
telephone numbers, and so on.
• Make use of printed text boxes to allow for easy input of items
such as date of birth.
• Make use of tick boxes to make choices easier (such as sex –
male or female).
• Make sure there is sufficient space to write answers.
• Make use of clear fonts and clear text colours to ensure the
form is easy to read.
 A COMPUTER-BASED FORM

• use of text boxes to capture key data clearly

• Use of on-screen help when completing the form.
• Use of drop-down/combo boxes where there are limited
choices.
• Use of radio buttons and tick boxes requiring a single click of
a mouse to select.
• Automatic validation of data as it is entered.
• control buttons (such as next form, clear entry, save, etc.)
• Double entry boxes (with verification rules) to check
correctness of key data (for example, when keying in an
email address)
 OUTPUT FORMATS (SCREEN LAYOUTS AND
REPORT LAYOUTS)

• The output from any system needs careful consideration

because this is part of any user interface, and is the result of
some form of processing.
• Screen outputs should be designed:
• To make sure the size of all the output fields is correct.
• So that any instructions/descriptions are clear.
• So that the full screen is utilized (avoiding large areas of
‘nothing’).
• So that colours and fonts (size and type) make the output
clear
• Screen output
example.
 DEVELOPMENT AND TESTING

• There is need for testing Once the design stage is

completed.
• It is then necessary to create the system and fully test
it.
 Test designs
Data structures The test design should determine how we can test that all data is in
a correct format or has been stored in the correct way.

File structures test that the file structures function correctly (i.e. data is stored in
the correct format and can be correctly retrieved when required).

Input formats determine how we can test that all data can be entered into the
system correctly.

Output formats The test design should determine how we can test that screen
outputs and reports are all in the correct format.

Validation The test design should determine what data is needed to test to see
routines if all the validation rules work.
 TEST STRATEGIES
• Software is often developed in modular form.
• This method allows it to be broken down into smaller parts
(known as modules).
• Each module is developed separately by a programmer.
• Each module needs to be tested separately to see if it functions
correctly.
• Any problems resulting from the testing require the module to
be modified and then tested again.
• Once the development of each module is completed, the whole
system needs to be tested as a whole.
• Even though each module may work satisfactorily, when they
are all put together there may be data clashes or incompatibility,
memory issues, etc.
• All of this may lead to a need to improve the input and output
methods, file/ database structures, validation and verification
methods, etc.
• Then fully test everything again.
 TEST PLAN
• A list of all the tests to be performed.
• What data is to be used in the testing.
• What type of testing the data is designed to check (i.e. normal,
abnormal or extreme).
• What live data should be used.
• What the expected outcomes are from the testing.
• Do the actual outcomes match what is expected
 TYPES OF DATA
• normal – this is data which is acceptable/valid and has an
expected (known) outcome.
• For example, the month can be any whole number in the range
1 to 12.
• Extreme – this is data at the limits of acceptability/validity.
• For example, 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, none of the following values are allowed as
inputs for the month:
• Any value less than 1 (0, −1, −15, etc.)
• Any value greater than 12 (32, 45, etc.)
• Letters or other non-numeric data (July, etc.)
• Non-integer values (3.5, 10.75, etc.)
 LIVE DATA
• Once a system has been fully tested, it is then tested with
live data.
• This is data with known outcomes.
• It is entered into the new system and the results compared
with those produced from the existing system.
• If the two outcomes do not match, then further
modifications to the system may be needed.
 IMPLEMENTATION
• Once the system is fully tested, the next stage is to fully
implement it.
 DIRECT CHANGEOVER

• With this method the old system is stopped

overnight and the new system introduced
immediately.
 ADVANTAGES
• The benefits are immediate.
• Costs are reduced (because only one system is used there is
no need to pay for two sets of staff).
DISADVANTAGE
• This method can be disastrous if the new system fails
because the old system is no longer available.
 PARALLEL RUNNING

• The old and new systems are run side by side for a time
before the new system takes over altogether.
ADVANTAGES
• If this new system fails, the old system is still available as a
backup.
• It is possible to gradually train staff.
 DISADVANTAGES

• It is more expensive than direct because extra staff

are needed to run both systems together.
• It is also more time consuming than direct because
data needs to be entered into two systems.
 PILOT IMPLEMENTATION

• The new system is introduced into one branch or

office of the company and its performance assessed
before being introduced elsewhere in the company.
 ADVANTAGES

• If the new system fails, only one part is affected.

• It is possible to train staff in one area only, which is
much faster and less costly than parallel.
• The costs are also less than parallel because only one
part of the system is being used in the pilot warehouse.
 PHASED IMPLEMENTATION
• Only part of the new system is introduced and, only when it
proves to work satisfactorily, is the next part introduced, and so
on, until the 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

• More expensive than direct because it is necessary

to evaluate each phase before moving to the next
stage.
• Very time consuming because each part needs to
be fully evaluated before making any further
changes to the system.
 DOCUMENTATION
• Once the new system is fully developed, a considerable
amount of documentation also needs to be produced for:
• people who may need to modify or develop the
system further at some later stage (Technical
documentation).
• the end-user (user documentation).
 TECHNICAL DOCUMENTATION
• Technical documentation is designed to help
programmers/analysts to make improvements to the system
or repair/maintain the system.
• This can consist of any of the following:
✓program listing/coding
✓programming language used
✓program flowcharts/algorithms
✓system flowcharts
✓purpose of the system/program/software
✓ limitations of the system
✓ 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 results and actual test data used)
✓ 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:
✓how to load/install/run the software
✓how to save files
✓how to do a search
✓how to sort data
✓how to print out
• how to add, delete or amend records
• the purpose of the system/program/software package
• limitations of the system
• screen layouts (input format)
• print layouts (output format)
• hardware requirements
• software requirements
• sample runs (with results and actual test data used)
• error handling/meaning of errors
• troubleshooting guide/help lines/FAQs (frequently asked
questions)
• how to log in/log out
• Tutorials
• error messages/meaning of error messages
• glossary of terms.
 EVALUATION
• It is necessary to do some evaluation and carry out any
maintenance if necessary.
• The following is a list of some of the things to be considered
when evaluating how well the new system has worked
• This can lead to a redesign of part of the system if there is
strong evidence to suggest that changes need be made
• Compare the final solution with the original task
requirements.
• Identify any limitations of the system.
• Identify any necessary improvements that need to be made.
• Evaluate the users’ responses to using the new system.
• Compare test results from the new system with results from
the old system
• Compare performance of the new system with performance
of the old system.
• Observe users performing set tasks (compare old with new).
• Measure the time taken to complete tasks (compare 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.
• Evaluation may lead to:
❖update of hardware because:
❖of feedback from end-users
❖new hardware comes on the market, necessitating
change.
❖changes within the company require new devices to be
added or updated
❖Update of software because:
❖of feedback from end-users.
❖changes to the company structure or how the
company works that may require modifications to the
software.
❖changes in legislation that may require modifications
to the software.
END OF SYSTEMS LIFE CYCLE