Identification

When the decision to make the new system is made. Based off a range of conditions.
Situations could be:
They have a computer system which can’t be improved or it might not be compatible with
other systems in use.
Might have no computer system and making their first attempt at computerisation.

Feasibility
Considers if the new system is:
Financially feasible – whether the system is worth the cost
Technically feasible – Can it be achieved and what hardware is needed for it
Operational feasible – How long will it take to bring into use, what benefits would it bring to
the company, how much disruption changing to it cause, what, if any, new jobs will be
created by this, will any jobs be lost
Time scale – What is the time scale needed to make this and can it be met

Analysis
Often a team of analysts will be used
The advantages of a team include: data being collected quicker, more ideas from more
people, varied experiences of businesses and systems

Different methods of investigation:

Questionnaire – can be given around to people in the business to gather opinions.
Interviews – with others in the business to gather their opinions in more detail.
Direct Observation - analyse the current system
Analyse existing documentation – gather evidence of current documents and processes. We
can then see decisions that were made and the types of documentation that need to be
generated and saved.
Investigate the current hardware and software in use.

Data Flow Diagrams

Shows the inputs of data into the system, the processes are applied to the data, the outputs
and the storage requirements.

End User Requirements

A clear list of requirements that the new system needs. Developed through the analysis
stage. Revisiting the list with the client is vital
Design
In the design stage they plans are created and compared to the user requirements. The
design is reliant upon a good quality analysis.

Once the analysis is completed to a good standard, the design is the blueprint for the build
process. All the best projects have clear plans within their design.

Design tasks:
Come up with the alternate solutions for the system then decide which one would be best
for the problem.
Break a large problem into smaller ones
A top-down approach (sometimes known as a stepwise design) is the breaking down of a
system to gain insight into the sub-systems that make it up. Each subsystem is then broken
down in yet greater detail.

Consider the HCI (Human Computer Interface)

Features of a HCI: Clear interface, Keyboard shortcuts, Provide help, Can be
customised, Could be command line or GUI Easy to learn

Plan data dictionaries –show the structure of any data records that need to be stored.

Write algorithms –show the concept of the program.

They would have to design the processes that would work upon the data such as searches
(queries) and reports that the system would produce.

Test plan
testing strategies include:
Dry run - working through a section of code manually to try to locate any errors. A trace
table is made from the program, variables are tracked as instructions are executed. Doesn’t
require a computer, helps to give the programmer a clearer idea of what is happening

Unit Testing- each section of the system is separately tested with suitable test data to
ensure it functions properly before it’s available for operational release.
Integration testing -A number of components are tested together to ensure that they
interact correctly to produce the desired response.
System Testing - Using suitable test data, the whole system is tested to ensure that all the
parts function correctly and meet the specification outcomes.
Normal/Typical data - valid data to ensure that the program can function properly with the
majority of expected values.
Extreme/Boundary data - data to test the programs upper and lower limits.
Invalid/Erroneous data - to ensure that the program can handle it without crashing. Suitable
messages are usually generated informing the user that the data or operation is invalid.
User Acceptance testing -the program is finally tested with real data in the environment
where it will eventually be used. This allows the client to decide if they are happy with the
solution. They can put the program through its paces to ensure it meets their expectations
with relation to speed, ease of use, volume of data and consistency.

Build
The design is implemented through the development/coding team. They will use good
standards such as commenting code and self-documenting identifiers.

Testing
Alpha:
Restricted audience of testers
From members of the company

Beta:
Tested by people outside the company
For example, “privileged customers” In exchange for their constructive comments

Acceptance Testing
Carried by the customer to ensure that the system works

Maintenance Documentation
Documentation is created through the design and build stages. The purpose of this
documentation is to help programmers maintaining.

Algorithms + Data Dictionaries

DFDs -These are used to show the data in the system and what happens to it. It tracks
where it goes and what happens. Used so designers and programmers know what’s
happening to data and what they need to do when it is sent into the system.
End user Documents
User manual - Used by the people that will be using the system on a daily basis. Contains
information on how the system works and any information that they need to use it. Very in
depth and used by someone who would already has good understanding of the system.

Technical manual - Contains the technical information about the system. Includes the code.
Used for maintenance so anyone maintaining the system would know what all the code is
and what it does. This makes sure the system can be maintained without the company that
made it having to come and fix it. All code should adhere to standards such as comments
and self-documenting identifiers.

Changeover/Implementation
Direct changeover - When the new system completely replaces the old system without
overlap. If the new system fails, the business will struggle.

Parallel changeover - Old system works alongside the new system for a little bit.
Comparisons can be made and results checked to ensure the new system works. Processes
might get carried out on both systems. If the new system doesn’t work they would still have
the old system.

Phased changeover - When the new system starts to replace some of the roles in the
organisation to test if it works without replacing the old system completely which is more of
a risk.
Pilot running - generally used in geographically dispersed companies, the system is used in
one part of the company and tested there before being used in the rest of the company.

Backup/Recovery
Organisations susceptible to experiencing unexpected events that can cause internal
disasters with respect to business operations.
There is a need for plans and recovery strategies. Disaster recovery plans (DRPs) aim at
ensuring the company can function effectively during and after a disaster.

Backups should be planned and checked.

The policy should indicate the frequency, timing and responsibility for the backups.
Staff should be trained in recovery procedures including how to successfully restore the
data
There should be an alternative computer system.
There should be a back-up power supply.
Files should be archived off-site.
Transactions that were affected/interrupted at the time of the failure must be dealt with.
The recovery plan should include a check that all the data is there.

Maintenance
When the new system needs alterations, there are three main types of maintenance:
adaptive, corrective and perfective.

Adaptive - This changes the system in line with an external change

Corrective - Bugs found after implementation
Perfective - An improvement to the system, making it more effective