Professional Documents
Culture Documents
Introduction
All things have a beginning, a middle and an end. And Information Technology (IT) is no different.
Indeed it could be argued that IT sees more rapid change than many other technologies. Think how
many 'upgrades' have happened with your favourite software.
For instance, imagine you have been working at a company for a few years.
At some point in the past a wonderful new system was introduced into the company. Everyone was
happy. Management could see their business improve. The workflow for employees was smoother
and more productive.
After the first few months of bedding in, the system worked well... and for a few years the system
did everything it was meant to do.
Time passed, people moved on, the company changed ... that wonderful system began to show its
age... the new manufacturing system now had problems exchanging data. Customer invoices no
longer flowed effortlessly from their newer systems into your aging IT system.
Workers grew tired of using old CRT screens - even their home computers were more modern than
this!
It was time for a change.
But change has to managed to avoid disruption, chaos and inefficiency. This is where 'System Life
Cycle' comes in.
Object 1
The current one is out of date and no longer doing its job effectively
Technology might have moved on and new things are possible that couldn't be done with the
previous system
A competitor has developed a new system or process and the organisation needs something
similar in order to offer the same service to customers
The organisation has grown and the current system can't cope with the increased demands
placed on it. Perhaps the company had only a few customers to start with but now it needs to
be able to deal with hundreds of accounts.
A new part of the company needs IT support e.g. a new customer service help desk.
The company might want to improve the quality of a repetitive task. Doing the same thing
over and over is very tiring and tedious for a person. A robotic system may be able to help
with this. For instance the car industry makes heavy use of robots in their factories.
As people have learnt from past mistakes, a model has been developed and refined over the years to
try and maximise the chances of a successful project.
This method / model is called the SYSTEMS LIFE CYCLE.
4. The System Life Cycle (SLC)
The SYSTEM LIFE CYCLE is a process of stages which occur during the development of a
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
Observation will probably follow a complete process from start to finish
and note down every interaction that happens
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:
These documents will be used by the system developers and so must be clearly written,
broken down into relevant stages and contain all of the necessary details for them to create
the new system.
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.
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'.
Project planning 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:
Gantt Charts
Critical Path Analysis (CPA)
Project Management Software
Prototyping 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 that the design is likely to work.
The details do not matter at this stage but a record must be 'read in'.
For the purposes of the OCR A2 specification, implementation is taken to be the software
development stage.
15. Testing
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:
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!
16. Testing continued.
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
Advantages Disadvantages
Most risky method - if something goes
New system available to everyone in
wrong, there is nothing to fall back on. Have
company immediately
to wait while the problem is fixed.
Have to transfer all of the data to the new
Often the cheapest method of installation
one before the old one can be switched off
There will be a period of time where no
system is available because can't have old
Don't need to keep duplicate sets of data
one working while new 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
Time consuming as data has to be entered
new system fails, the old system is still up-
onto both systems
to-date
Less stress for staff as they still have the One system can become out of sync. with
security of the old system the other.
Staff can take their time to learn to use the Maintaining duplicate sets of data can lead
new system to errors
Extra cost of running and maintaining two
systems
18. 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 wrong,
This method of installation can take a long
if something happens, it will only affect that
period of time
specific part.
As parts of the system are used, users ask
Staff are introduced to the changes in small
for changes which then hold up the
stages
installation of 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
Even though it is only introduced to a small
Only a small part of the business is affected.
number of departments, those chosen will
The rest of the business continues using the
have the same disadvantages experienced as
old system for now
for a 'direct changeover'
Those staff using the new system might not
Any problems or issues are identified
be able to easily share data with the rest of
without it affecting the whole company
the company who are still on the old system
When the rollout happens, staff from the
Extra work for IT staff who are having to
pilot departments can be involved in
support two different systems
training other staff
challenge see if you can find out one extra fact on this topic that we haven't already told you
Click on this link: Rollout methods
19. Installation Stage: Training
Staff training is part of the installation phase.
User documentation is often used during staff training sessions in order to familiarise the staff with
both the system and the user documents.
Many help systems have a search facility to answer those 'How do I ....' type of questions the user
may have. Another popular format is the 'FAQ' or Frequently Asked Questions document.
Typical features of the help system include:
Text search facility
Hyperlinks and navigation buttons to move around the help documentation
Buttons with relevant text
Worked examples of how to use a feature
Links to related features
Multimedia help in the form of video tutorials or spoken word
'Tool tips' which appear when you hover over a word or sentence
Pop-up instructions when you press a certain function key
The online version has the advantage that it can be easily updated with the latest information
compared to a published paper based system.
23. Evaluation
24. Maintenance
Corrective maintenance
This is where problems are identified with the system after installation. Perhaps an item on the
template isn't printing out correctly or maybe one of the on-screen buttons isn't linking to the correct
form.
A fault report is raised and the developers fix the problem. It is then passed over to a team of testers
who check that the fault has been fixed. Once it has been passed by the testers, the fix will be
released to the live system.
Corrective maintenance can also involve fixing hardware faults or replacing equipment as
necessary.
Adaptive maintenance
This type of maintenance often occurs as a result of external influences or strategic changes within
the company. For example, the Government recently changed the VAT rate from 17.5% to 20%.
This change would have meant that many organisations had to make alterations to their systems.
Perhaps a bank decides to offer a new mortgage product. This will have to be included in the system
so that mortgage interest and payments can be calculated.
Perfective maintenance
The system has been in place and running fine for a while. However, over time, the end user will
often find tweaks or minor improvements which could be made to improve the way the system
works. Perhaps a slightly different screen or data input form. These tweaks are not major enough to
prompt a complete new system, so the maintenance team adapt the system to suit.
It is important to be aware that while the system remains in use the maintenance stage will be
ongoing.