Definition

The very first part of the SLC is to define the problem.

The system analyst must determine whya new system is required.

After all, if there isn't a problem to start with, why would an organization incur
huge costs to develop a new one?

In the definition stage the role of the analyst is to scope out the problem.

The analyst has a number of methods available to do this

 Interviews with management to get their viewpoint

 Interviews with staff to understand the limitations of the current system
 Other methods that will be discussed later in this mini-web
Feasibility Study - constraints
Once the system analyst is convinced that there is a problem which could be solved
with a new IT system they have to determine whether it is feasible to actually go
ahead and develop the system.

Some of the questions that will need to be answered are:

Cost How much would the new system cost to develop?

Would there be enough money available in the budget to develop the

Budget
system?

Time How long would it take to make the system from start to finish?

Does the company have the skills in-house or would it need to go to a

Skills
specialist software development firm?

Hardware to
Does the company have the necessary hardware to develop the system?
develop

Would new hardware be needed to run the system and if so how much
Hardware to run
would that cost?

Software Does the company have the necessary software to develop the system?

What would the training implications be once the system had been
Training
developed?

Technical After finding out what is required is it technically possible to create the
feasibility system
Feasibility Study - alternative solutions
The system analysis will consider all of the answers from the feasibility study and
come up with a number of alternative solutions to present to management.

It is then the management's job to consider going ahead with the new project.

Some possible solutions that might be suggested to management could be:

a) Company does not change anything

Benefit No disruption to the business.

Cost No cost.

Performance No change, system remains outdated. Process becomes increasingly less efficient.

b) Company makes alterations to half the system

Best parts of the system are retained whilst the least efficient aspects are redesigned to
Benefit
enhance performance.

Cost Moderate, training moderate.

Performance Performance improvement: 30%

c) Complete overhaul

Benefit Reduces company cost base (more profitable).

Cost High, given that new equipment / software will be required. Training for staff needed.

Performance 70% improvement over the old system.

As you can see, deciding on the best alternative is often not simple - management
have to take many factors into account. There are often complicated relationships
between cost, performance and benefit.

So at this point of the system life cycle, you know what the problem is and you are
considering options.

The various options are usually presented to management at this stage and it is up
to them to make a decision as to how much investment they wish to put into the
project.

If the decision is made that it is worth developing a new system, the SLC will
progress onto the next stage, Investigation and Analysis. If management decide to
stick with the current system, the SLC will stop here.

Investigation and Analysis: investigating the

system
In order to reach this stage in the SLC, management would have listened to the
alternative solutions presented by the system analyst and have decided to either
commission a brand new IT system or have changes made to their current system.

During the earlier 'definition' phase the analysis looked superficially at the current
system and the potential benefits of a new system.

During this 'investigation and analysis' phase they will carry out very detailed
investigations in order to fully understand the current system and the proposed
new system.

The current system

  how staff / customers interact with the current system i.e. how tasks are
carried out
 how other systems interact with the current system
 what is good about the current system
 what causes problems with the current system
 which parts of the system are critical to the business

The proposed new system

 what the new system is expected to be able to do

 how the new system is expected to do this
 what people want from the new system
 which working methods from the old system should be incorporated into
the new system

Investigation and Analysis: investigation methods

In order to find the answers to the points on made on the previous page the system
analyst will do some or all of the following:

The analyst will interview selected staff who use the current system in order to get
a detailed overview of how things work.
Face-to-face
Interviews
They will want to know what the main problems are and whether users have any
suggestions on how to improve the way things work.

The analyst will observe users actually using the system. They will probably follow
Observation a complete process from start to finish and note down every interaction that
happens

Questionnaires enable the analyst to obtain the views of a large number of staff/
users. Questionnaires are also easier to analyse than face-to-face interviews but
Questionnaires the trade-off is that they don't give as much detail.
 Most organisations have business documents and written processes/ procedures
Examination of relating to the current IT system. These documents detail how the system works
business documents and the processes which users should follow. The analyst will examine these
documents in detail.

Following information from the point it enters the system and observing what
Paper trail
outputs are created at each point in the system.

10. Investigation and Analysis: documentation

All of the information obtained through interviews, questionnaires, observations and

paper trails is carefully examined and analysed to determine the requirements for
the new IT system.

The findings are translated into a set of specific diagrams which represent how the
system will work and the processes required.

The main diagrams are:

System These show the relationships between the various systems in the company (or even
diagrams outside if relevant) - how they interact, what depends on what and so on.

Most systems deal with information in one way or another. What really matters is how
the information flows through the system. How does it branch and re-join. What outputs
Data Flow
are created and so on.
Diagrams

The 'data flow' diagram seeks to show this movement through the system.

People handle information in a specific way - they have a 'process'. For example, an
employee makes an expense claim. First of all their manager counter-signs the claim. It
then goes to the account manager who authorises payment and so on...This is 'process
Process
flow' in action.
diagrams

Process diagrams try to show how people interact with the system - who and when
(and why).

Once the diagrams have been completed, two key documents/ reports are
produced:

1. A full written analysis of the current system, the processes and

the problem it causes
2. Detailed user requirements for the new system

User requirements document

The 'User Requirements Document' does not define the hardware or software
design but rather seeks to capture the essence of what needs to be done.

Some fairly standard headings within the document are:

An introduction ....

"The project has been developed in order to create a new invoicing system to
replace the AIX400 computer system..."
The introduction gives a broad description of the project and its aspirations.

Context ....

"The project was developed in light of the up-coming new regulations and also the
increasing awareness that the existing system could no longer meet customer
expectations ...."

This section provides the background to the project.

Specific details required

Having provided a broad description and some context to the project this section
deals with specific things that need to be included in the system.

Examples:

 The system will be able to use a query to create a mail merged

personalised letter.
 The system must create an invoice in less than 3 seconds
 The system will be able to print a management report onto A4 paper,
portrait layout.

Notice that these specific requirements are all measurable.

The document should NOT contain vague statements such as "The computer will
run as fast as possible..." because you cannot know if 'as fast as possible' has been
met when the system finally gets switched on.

The Requirements Specification is the 'contract' between project managers and the
client. It will be used at the testing stage to confirm that the system performs as
the client expects.

Role of the user

The key point of the System Life Cycle Process is that it is the people who are
actually going to use the system who get a say in how it going to work.
They are called the 'user'.

This does sound like common sense but an amazing number of projects are carried
out without any regard to what the user actually wants - assumptions are made.
And this is one of the key reasons why a project fails.

This is the purpose of the 'User Requirement' document. The document tries to:

1. Eliminate misunderstandings
2. Reduce errors
3. Gain user agreement

The way it works is that the system analyst tries to understand what the user needs
of the system. The analyst then sets this out in a non-technical user requirement
document. He may use a number of diagrams and charts within the document to
explain his understanding of their needs.

Users are then invited to comment on the document and provide feedback to
improve upon it.

There may be several iterations of the User Requirements Document as users

further explain to the analyst what they need. Getting it right the first time is a rare
thing!

This process continues until the user agrees that the system will do the job.

This is called the 'sign-off'. It is saying that the user buys into the project, that they
are confident that the project will do the job.

Complications
This sounds simple, so why do project fail so often? In terms of the user it may be
because

1. They are not the right user! For instance if it is a system that the public need to
use then have all the types of customers been included? Is it too complicated for
some people or too long-winded for others?

2. User requirement change within the lifetime of the project. This is a major
problem as large projects have a habit of becoming more and more complicated as
people want it to do more and more things. Sometimes this is called 'mission
creep'.
Design phase
This is the next stage in the SLC and it follows on from the Investigation and
Analysis stage.

Now that the project manager and the client have agreed on the requirements
(Requirements Specification) it is time to define how the project is going to be
carried out.

This part of the System Lifecycle is called the Design phase.

The Design phase is about planning the project in detail so that that system will
meet user requirements.

The following are tasks that must take place during this phase:

Project planning is all about handling people: how many, where and when are they
needed. In addition those people will need resources to carry out their jobs:
computers, offices etc. There are a number of different project planning tools which
will be used during this stage in order to effectively plan out the project, timescale
and the resources required. These include:

Project planning
 Gantt Charts

 Critical Path Analysis (CPA)

 Project Management Software

This document will include the following information:

System Data capture methods for the system

requirements
specification Data inputs to the system

Data outputs from the system

 Data processing within the system

The file structure for data storage

The user interface i.e. screen layouts, buttons, error messages

How information is accessed and indexed or sorted.

The operating system to be used

The hardware to be used to run the new system

A Data dictionary defines the:

 tables, fields, records and relationships

Data Dictionary  constants, variables and data structures

 validation that is required in the system

 query structures

Once the user requirements document and the system requirements specification
have been written the analyst will know exactly what the system should be able to
Testing do.
documentation
A test plan is written at this stage to test the key parts of the system once it has
been developed.

A 'prototype' is something that represents what you will finally create without
having to worry about all the details - it captures the essential details to confirm
Prototyping that the design is likely to work.

In software the prototype is often written in a kind of shorthand English called

 pseudo-code, for instance 'Read in the record'.

The details do not matter at this stage but a record must be 'read in'.

Implementation (development)

Just to confuse you, depending on which version of the SLC you look at,
implementation can mean either the development phase of the system or
the installation phase of the system.

For the purposes of the OCR A2 specification, implementation is taken to be

the software development stage.

Once the design stage has been

completed the software developers can begin to write the code and actually develop
the new system.

The system could either be completely bespoke with every line of code being
written by specialist programmers or it could be developed from an 'off-the-shelf'
application which is then customised.
The developers will follow the system requirement specification exactly, if it states
to put a button 500 px by 100 px, colour #ffefdf in the top left hand corner that is
exactly what they will do.

They should not deviate from the specification in any way without consulting the
analyst.

During this stage some of the following are developed:

 the tables and data structures

 validation routines
 data capture forms
 data input forms
 automated processing routines i.e. macros
 queries
 the user interface i.e. screen, buttons, help messages
 printing outputs

Testing

Once the system has been

developed it must be tested to ensure that it is working as expected.

Testing Team
A team of testers will have been chosen to test the system. They are known as beta
testers. Their role is to check that the system does everything exactly as specified
in the system and user specification.

Although this team will check if the system is user friendly that is not their main
role. A separate team is usually appointed made up of front end users to 'user test'
the system once it has been passed by the beta testers.

Test Plan

In an ideal world a test plan will have been written during the design stage.
However, sometimes the test plan gets left until now.

The test plan is a detailed document which a team of testers must follow carefully.
It will set out every single test they are to do on the system, what data they should
enter and what result they should expect to obtain.

For example one test might look something like this:

Test Part of What is being Test Expected Actual Pass

no. system tested data result result / Fail

Input mask on
postcode to check Fail - should
Customer that numbers not be able to
23 45CV523
input form cannot be entered enter
where letters postcode
should be.

The first five columns are already completed in the test plan. The final two columns
are left blank for the testers to complete when they do the test on the system.

The testers follow the plan exactly. They enter the data just as it is shown in the
plan and then they record what happened and whether the test passed or failed.

If the test was passed they go onto the next test. If it failed they fill in a form to tell
the developers that they need to look at that part of the system again.

The testers normally take screen shots of every test to provide evidence of what
they have done. These can be referred to by the developers if they cannot replicate
the problem. They can also be used by an audit team at the end of the project to
check that the testing was done properly.
This stage may seem to you a bit pedantic - after all why couldn't the developer
have run this test when they were coding the software and then fix it instantly? -
Answer: Human Nature!

It is a very bad idea to have the person who codes the software to test it! This is
because they know too much and so will tend to make assumptions about how real
users will use their software.

The best testers are those who know nothing about the system and will do things to
the system the developer never imagined! Just like real users!

Test Selection

It is important to realise that with the best will in the world it is not possible to test
every part of the system.

Consider a system having 8 data inputs that can applied in any combination. The
maths says that there are over 16 million possible combinations of just 8 inputs!

So the skill of the testing team is to carefully select a practical number of tests that
can be carried out in the time available and yet be confident that the system is
working.

This is why complicated software often has bugs even after being released. It is
simply not practical to test everything.

Test Data

It is important that any testing which checks the validation routines should include:

Data that is within the normal range and will be accepted

Data that is on the extreme limits of the range but should be accepted e.g. if the
validation says that price <=£100 then £100 should be tested as that is right at the
outer limit.

Data that should fail (erroneous data) should be tested. For the test mentioned
previously, the test might be: enter £100.01
Iteration or Looping Around.
If an issue is found it may actually be a problem with the user requirement itself. It
is quite common for the user requirement to not consider an unexpected situation.

For instance, the document might state that the system is to be used by 10 people
at the same time. But by the time testing is underway something changes in the
company and now the system needs to deal with 20 people instead.

In which case the client has to agree to change the user requirement document.

Then testing continues with the modified user requirement document.

Changing user requirements part way through a project causes delays and extra
cost. It is often the most common reason a project fails especially on large projects.

Testing is usually an 'iterative' process.

Installation Stage: Methods

Depending on which version of the SLC you are using, you might see this
stage called the implementation stage, the installation stage or the
changeover stage. For the OCR syllabus, the term 'implementation' is used
to mean the development phase.
 The system has been developed
and tested. It is working correctly and doing everything that was agreed during the
design stage. The business is waiting in eager anticipation for the new system to be
handed over to them.

A key decision is which method of the four different methods of installation will be
chosen. These are:

1. Direct
2. Parallel
3. Phased
4. Pilot

Direct method

This is where the company literally switches off the old system and switches on the
new one. This is probably the most straightforward method but is also probably the
riskiest.

Advantages Disadvantages

New system available to Most risky method - if something goes wrong, there is
everyone in company nothing to fall back on. Have to wait while the problem is
 Advantages Disadvantages

immediately fixed.

Often the cheapest method of Have to transfer all of the data to the new one before the
installation old one can be switched off

There will be a period of time where no system is

Don't need to keep duplicate
available because can't have old one working while new
sets of data
one is being switched on

There will be a period of upheaval while the system is

brand new and staff are finding their way around it

Parallel method

This is a more popular method than the previous one. With a parallel changeover
the organisation runs both the old and new system in parallel for a time. Once the
organisation is sure that the new system is working properly and that staff are
ready to begin using it they will make the decision to completely change over.
During a quiet period, perhaps during the night or at a weekend, the data is fully
transferred from the old system which is then shut down.

Advantages Disadvantages

Less risky than the direct method. If the new Time consuming as data has to be
system fails, the old system is still up-to-date entered onto both systems

Less stress for staff as they still have the security One system can become out of sync.
of the old system with the other.

Staff can take their time to learn to use the new Maintaining duplicate sets of data can
system lead to errors
 Advantages Disadvantages

Extra cost of running and maintaining

two systems

Installation Stage: Methods Cont.

Phased method

This is where the old system is still active but parts of the new system or modules
are brought online, for example, perhaps just the data entry screens and the
printing modules are made available but the 'back end' of the system remains the
same. Once any problems are ironed out with the new modules then extra modules
will be introduced. Effectively the installation happens in small chunks.

Advantages Disadvantages

Less risk of the whole system going

This method of installation can take a long
wrong, if something happens, it will only
period of time
affect that specific part.

As parts of the system are used, users ask for

Staff are introduced to the changes in
changes which then hold up the installation of
small stages
the next phase

It might be difficult to integrate the old and the

new systems

Pilot method

This is where the complete new system is installed and tested in a small number of
departments or branches. They then use the system and report their feedback and
any issues to the analyst. Once the organisation is confident that the system is
working as expected, it will be rolled out across the whole organisation.

Advantages Disadvantages

Only a small part of the business is Even though it is only introduced to a small
affected. The rest of the business number of departments, those chosen will have the
continues using the old system for same disadvantages experienced as for a 'direct
now changeover'

Any problems or issues are Those staff using the new system might not be
identified without it affecting the able to easily share data with the rest of the
whole company company who are still on the old system

When the rollout happens, staff from

Extra work for IT staff who are having to support
the pilot departments can be
two different systems
involved in training other staff