You are on page 1of 4


The system life cycle is the process by which an existing system is replaced with another


- Interview employees about their issues with the current system.

- Analysing the total costs of the current system.
- Key external factors that may point towards developing a new system.
- Performance of the existing system.


The feasibility study involves breaking down the problems with the existing system and
looking at alternative ways of solving them.

- Keep the existing system, because any changes are unfeasible due to cost and/or
technical reasons.
- Keeping the parts of the existing system that work well, and only developing the
ones that don’t.
- Using an “off the shelf” solution and changing the way the business works to fit in
with it.
- Using an “off the shelf” solution, and then adapt it to fit with the way the business
already works.
- Developing a customised solution to fit with the way the business already works.


Involves analysing how the existing system works. Not necessarily the hardware or the
software- but more about how information is handled and how people interact with it. This
is a study of the inputs, processing and outputs of the existing system.

This confirms that the true cause of the problem has been correctly defined. It also
confirms that the project will overcome the problem.

- System diagrams: show relationships between systems in the company (or even
outside it)- how they interact, what depends on what and so on.
- Data flow diagrams: most systems deal with information in one way or another.
What really matters is how the information flows through the system.
- Process diagrams: people handle information in a specific way. They show how people
interact with the system- who, when and why.

The next stage is to create a “Requirements Document”, which won’t define the hardware
or the software design, but rather seeks to capture the essence of what needs to be done.
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

It consists on:
- An introduction: a broad description of the project and its aspirations is given.
- A context: that provides background to the project.
- Specific details required: this section will deal with things that need to be included
in the system.


It defines how the project is going to be carried out. This phase is trying to define the
system in even greater detail. In this stage prototypes are created so as to prove it will
work correctly. A prototype is something that represents what you will finally create
without having to deal with the more specific details, rather with the essential, so as to
confirm that the design is likely to work.


In this stage, the software and hardware engineers work together to develop a working
system, following the designs already made. Each phase will probably be tested as it is
developed to make sure it is working. There may be several teams involved in this stage.

- The software developers write code.

- The hardware people develop equipment.
- The testing team develop test plans.

Documentation is also created in this phase.

- User documentation: to help train staff to use the new system. Instruction on how
to input data, process it and output it.
o Installation instructions.
o Purpose and limitations.
o Hardware and software requirements.
o Input and output formats.
o How to use the system.
o Sample runs.
o Error messages.
o Trouble-shooting guide.
- Technical documentation: to help technical staff who create systems to maintain
the new oen.
o Program coding.
o Program flowcharts.
o System flowchartds.
o Hardware and software requirements.
o File structures.
o List of variables.
o Validation routines.


In this phase, the whole system is tested using the testing plan already made. If any
results aren’t satisfactory then a report is sent to the developers and corrections are
made. The test is performed again until all the tests are passed. Types of test data:

- Normal test data (typical data expected to be entered).

- Abnormal test data (not typical data expected to be entered).
- Extreme test data (maximum and minimum values expected to be entered).
- Null data (no data is entered when expected).


The system is implemented in the working environment, replacing the older system. Staff
will need to be trained to use the new system and data from the old system may need to
be converted for use on the new one.

- Direct changeover: switch off the old system and switch on the new one.
- Parallel running: you run the old system in parallel to the new one for a time.
- Phased changeover: you change only part of the new system.
- Pilot changeover: you change only one area, branch, shop or office of a large


Staff needs to be shown how to use the new stems and how to access help if they run into
difficulties. There may be a member of the development team fro a period of tie or there
may be a dedicated help line. There will most definitely be a s user manual or
documentation to act as a source of reference.


This stage involves monitoring the performance of the new system over an extended
period of time to see how well it performs. Some problems may only appear when there’s a
high amount of data processed or at critical times of the year where there’s an above
average demand.
- Does the finished solution meet its requirements?
- Does it solve the problem?


In this phase, the new system is maintained once it has been installed and is up and
running. Some parts of the new system will need improving, and this will be fed back into
the system cycle, resulting in software and hardware upgrades and updates being
developed, tested and then implemented. This phase finished when a new system
completely replaces it.

- Problems are cleared as they arise.

- Tweaks to the system are applied to improve performance.
- New circumstances might arise such as an office moves and the system has to be
- Data is baked up and kept safe.
- Printers, monitors and other equipment are replaced as required.