Systems development life cycle

1. Systems Development Life Cycle
When considering the systems development life cycle it is important to
think of the different stages as a continually developing process rather
than each stage being an end in itself.
When one of the stages is completed the following stages may mean that the previous ones may
need to be considered again. If the problem definition agreed with the end user later proves to be
impossible to implement then the problem will have to be redefined. If the required input proves
to be not feasible then it may be necessary to alter the expected output. If, during the training of
the staff, one of the input operators proves to be colour blind then the input screens may need to
be altered in order to not have any clashes between red and green.
This reliance of each stage being on the following stages as well as the previous ones means that
the process is said to be iterative.
1.7.b Problem Definition
It is important from the outset to ensure that when a computer system is being designed all those
that are involved are agreed about the aims of the system.
There will normally be a person, or a company or organisation, that decides that a task would
benefit from computerisation. This belief normally arises because there is a problem which
cannot be solved by previously used methods or similar problems seem to have been solved by
computerisation elsewhere. Unfortunately, the owner of the problem probably understands the
problem itself quite well, but does not understand the consequences of using computers to try to
solve the problem, or, indeed, whether such a solution is even possible. For this reason it is
necessary for the organisation to employ a specialist who does understand computers and
computerised solutions to problems. This is the systems analyst. Unfortunately, it is probable that
the systems analyst is not expert in the area of the problem.
The system analyst’s job is to solve the problem by planning and overseeing the introduction of
computer technologies. The owner of the problem will be happy if the analyst can introduce a
computer solution. The problem arises when the analyst, who doesn’t know very much about the
business, solves the problem that they think needs solving, while the owner of the problem
expects a very different problem to be solved.
It seems obvious that if someone is doing something for someone else that they should make sure
that they know what is required. If you are asked to answer questions 1 to 5 and you do 6 to 10
instead there is an obvious breakdown in communication, but this is what can happen if you only
listen to the instruction, “Do the 5 questions”. The method most often used to overcome this
problem is for there to be discussions between all the interested parties, and then for a list of
objectives to be written up. This list of objectives, if they are all solved, will be the solution to
the problem. The different people involved then agree to the list of the objectives and the success
or otherwise of the project depends on the completion of those objectives.

2. The definition of the problem is the most important part of the analysis because if it is not done
correctly the wrong problem may be solved.
1.7.c A Feasibility Study.
When the organisation and the systems analyst have agreed the definition of the problem, a
decision must be made about the value of continuing with the computerised solution. The
organisation may be convinced that there is a problem to be solved, and that its solution will be
worth the effort and the expense. However, the systems analyst is being paid to look at the
problem, and its solution, from another point of view. The analyst is an expert in computer
systems and what is possible with computer systems. This analyst must consider the problem
from the point of view of the computerised part of the solution and make a report to the
organisation saying whether the solution is possible and sensible. This report is called the
feasibility study because it says whether the solution is feasible.
The feasibility study will consider the problem, and the proposed solution, from a number of
points of view.
 Is the solution technically possible? A car firm may decide that if robots are used on the
production line to assemble the different parts of engines then quality of work may improve.
However, if it is not possible to manufacture a robot arm of the correct dimensions to fit into
the small areas under a car bonnet, it doesn’t matter how big an improvement there would be
in the quality of the finished product, it would simply not be feasible.
 Is the solution economic to produce? Perhaps the robots exist that can be programmed to
assemble this engine and the benefits will be worthwhile. However, if the cost of the robots
and the program to control them is so great that it puts the car manufacturer out of business,
the introduction of the robots is not feasible.
 Is the solution economic to run? It has been decided that there are tremendous benefits in
producing a robot production line and the robots are very cheap to buy, but they have so
many electric motors, and they are so slow at assembling the engines that it is cheaper to
employ people to do the job.
 What is the effect on the human beings involved? If the car plant is the only major employer
in the region, and the introduction will put much of the workforce out of work, then the
employer may decide that the human cost is too great, certainly the Government would.
 Is the workforce skilled enough? It will be necessary to employ highly skilled technicians to
look after the robots. If there are no workers with the necessary skills then the
computerisation is not feasible.
 What effect will there be on the customer? If the customer is likely to be impressed with the
introduction of the new systems then it may be worth the expense, however, if the customer
will notice no difference, what is the point?
 Will the introduction of the new systems be economically beneficial? Put bluntly, will the
introduction of robots increase the profits made by the firm?
If the feasibility study shows a positive result which is accepted by the company, the next stage
will be for the analyst to collect as much information about the process as possible.

3. 1.7.d InformationRequirements of a System and Fact Finding
When a computer system is being designed it is necessary to ensure that the designer of the
system finds out as much as possible about the requirements of the system. We have already
mentioned the importance of defining the problem but further difficulties can arise. Imagine an
organisation that commissions an analyst to design a new payroll program. The analyst and the
boss of the organisation agree that the software needs to be able to communicate with the
relevant banks, and to deduct tax at source and other important details. The analyst designs the
solution and the software is written. It is the best payroll program ever produced and is installed
into the computer system ready to do the first monthly payroll. Unfortunately, many of the
workforce are employed on a weekly basis. A simple question to one of those paid in this way
would have highlighted this for the analyst and meant that the costly mistake was avoided. When
a system’s requirements are being studied there is no room for errors caused by lack of
information.
The feasibility study has been accepted so the analyst now needs to collect as much information
as possible. Obvious methods of collecting information are to ask different types of people. It
may not be feasible to ask everyone in the organisation for their views, but a representative
sample of workers, management, customers should be given the chance to supply information.
After all, the part time worker on the production line probably knows more about the business
than the analyst. There are three accepted methods of finding out people’s views:
1. By interview. Interviews are particularly important because they allow the interviewee to talk
at length, and also to leave a prepared script. However, they are very time consuming and
consequently restricting in the number of people whose views can be sought.
2. By using questionnaires. Questionnaires make it possible to find out the views of a large
number of people very quickly, but because the questions are pre-determined the person who is
supplying the answers may find difficulty in putting their point of view across.
3. A compromise is to hold a group meeting. This allows a number of people to discuss points
and make their views known and yet cuts down on the amount of time spent in interviews getting
the same answers over and over again. The problem with meetings is that one or two people tend
to dominate, not allowing all the members of the group to give their opinions.
Often the views of the people connected with the problem are clouded by years of familiarity, so
it is important for the analyst to also gain first hand knowledge of any existing systems. One way
to do this is to observe the current system in action. Care must be taken to take into account the
fact that if the workers know that they are being observed it is unlikely that they will behave in
their normal manner. This is the same effect as a television camera has on otherwise fairly
sensible individuals. The second method is to collect printed documentation and study it in order
to find out what data is required by the system and what form information is output.
1.7.e Requirements Specifications
The planning of any system design must start by deciding what the requirements are of the
system. A system may need to store data for future reference or processing. However, simply
being aware that the system may need to store data is not enough.
 Decisions need to be made about the types of data to be held as this will dictate the form that
the data will be stored in and the amount of storage space required for each set of
information.

4.  Calculations as to the number of sets of data that are going to be held have to be made
because the volume of storage will make some storage devices more sensible than others.
Also, the volume of storage can effect the structures that will be used to store the data.
 Decisions need to be made about the relative importance of the different ways of accessing
the data. Is it going to be necessary to access individual items of data or will all the data be
accessed at the same time?
 Will the data be changed regularly or is it fairly static?
When decisions are made as to the direction that a particular system is going to take, it is normal
to produce a list of tasks that need to be carried out to complete the system. These tasks should
be in a specific order. It would not make sense to consider inputting data into the system before
designing the data structure into which the data is to be put. This list is called a priority list and it
forms the basis of the system design. Each of the tasks that are in the list should then be
considered separately to decide the important points about each one. An example would be that
the file of information on stock being held in a business must allow
 for 1000 items (immediately putting a lower limit on the size of appropriate storage)
 for direct searching for information on a single item (means that some storage media are not
suitable, and that some data structures cannot be used)
 another file, of manufacturers, to be accessed from each record in the stock file to facilitate
reordering (forces one field to act as a link between the two files).
Plenty of other facts must be considered and decisions made, but a set of constraints has already
been placed on the design. This is known as the design specification and it should be agreed
between the analyst and the organisation before the design is implemented.
Often, the inputs and outputs to a system and the storage and processing that goes on in the
system is such that, in order to understand it, the system needs to be divided up into a number of
interconnected sections, or modules, each one being simple enough to be handled as an entity. A
diagram can be drawn which shows all the sections and how they fit together. Such a diagram is
called a Jackson diagram.
Jackson diagrams:
A Jackson diagram starts with the original problem as the highest level. The next, and
subsequent, levels show how the problems in the previous levels are split up to form smaller,
more manageable, problems. This continues until each of the blocks in the lowest levels are self
contained, easily solvable problems. These individual problems can then be solved and combined
according to the links that have been used. If the links between the different blocks are then used
correctly, the result will be a solution to the original problem. Imagine a Jackson diagram as a
method for showing the individual modules that go to make up a solution to a problem and the
relationships between them.
Original Problem
Links
Individual modules
Final level

5. The links between the modules can be conditional. For example if the result of a module was a
mark out of 100, then there could be two possible print routines, one for failure if the mark was
below a certain level, and one for pass if it was above the pass mark.
An example of a Jackson diagram to show the solution to a simple problem.
A register is taken of the 25 students in a class. Each student can be either present or absent. It is
necessary to print out the number of students who are present and the number absent.
*
repeat
Data flow diagrams:
These are diagrams that are used to describe systems. Boxes are used to stand for input,
processes, storage, and output. Arrows show the direction of communication around the system,
and communications outside the system. As the name implies, these diagrams are used to show
the directions of flow of data from one part of a system to another. Data flow diagrams can have
complex shapes for the boxes that are used, but the important thing is not the shapes of the
boxes, rather the logical train of thought that has been used to produce the diagram. Rectangular
boxes, though not always used, are perfectly acceptable for all elements in a data flow diagram.
Such diagrams are intended to show how the processes and the data interrelate, not the details of
any of the programming logic.
Note: A Systems Flowchart is another name for a data flow diagram.
Students are expected to be able to follow the logic in a data flow diagram and, indeed, produce
their own, but not under examination conditions because the drawing of such a diagram would
take too much of the time allowed for the exam.
At this stage the analyst will also identify the hardware that will be necessary for the system to
operate as the user requires, and the software characteristics that will need to be satisfied for the
system to operate.
Register
Input
Present or
absent
OutputWhile count
<25 *
Initialise
Count = 0
Cpresent = 0
Cabsent=0
Increment
Cpresent
Increment
Cabsent
Output
Cpresent
Cabsent

6. Design of Input, Output, and Data Structures
Input Design
All systems require input. The way that the data is input to the system depends on a number of
factors.
 The data that is required. Is it graphical/textual/physical in nature? Is the data already in
existence or does it need to be collected first?
 The hardware that is available. Is the data to be entered via a keyboard by an operator, or is
there an automatic way to enter the data?
 The experience of the operator.
 The design of the user interface.
This section relates back to section 1.2.c which covered the different forms of software interface.
The main task in input design is to design the interface with the outside world so that data can be
passed to the system, both software and hardware.
Diagrammatic depiction of the system processing is covered in section 1.7.e, above. It is not
necessary to go into great detail about such diagrams, but students should be aware that they
exist.
Output Design.
The results that are produced by the system must be presented in a way that is appropriate for the
application. If the system is designed to produce bank statements for customers, then it would
not be sensible to have an audio output. Similarly, a burglar alarm system would not serve the
purpose for which it had been designed if the output is a message on a computer screen saying
that someone has broken in as there is probably no-one in the house to read it, which is why the
alarm was needed in the first place.
The decision about the type of output will depend greatly upon the same factors as the input,
namely, the hardware available, the form that the output needs to be in, the experience of the
operator, indeed, whether there will be an operator present.
Equally important to giving enough information, is the danger of providing too much. In order
for users to be able to understand the information presented various tricks can be used.
 Information can be arranged on a monitor screen by always putting the same sort of
information in the same place. The operator will then quickly become accustomed to the
relative importance of different areas of the screen.
 Information can be colour coded. Important information may appear in red while that which
is less important is in black. Notice that this implies some form of decision making on the
part of the processor to determine what is important in the first place. It is also necessary to
be very careful about choice of colours. People who are colour blind commonly find
difficulty distinguishing between red and green, so choosing these colours to stand for
information that is dangerously near a limit or at a safe level, could be disastrously wrong.
Similarly, colour combinations have to be chosen carefully. Blue writing on a black
background is almost impossible to see, as is yellow writing in some lighting conditions.
 Video reversal can be used to highlight a particular piece of information effectively. This is
when the normal writing on the screen is black on a white background, but the piece that
needs to stand out is shown as white on a black background.

7.  Very important pieces of information may be shown as a dialogue box obscuring the rest of
the screen until it is dealt with.
 A printer may be reserved for special messages so that a hard copy of the information is
preserved. Again, the fact that the information appears on that printer means that it has a
particular importance.
 Information can be made to flash, or can be printed in a different size, anything that makes
the operator’s eye go to that part of the screen.
Data structure design.
The data used in a computer solution will need to be stored somewhere. The storage is not that
important. What is important is getting it back again when it is needed. In section 1.4, the data
structures array, queue, stack, linked list, were described. When the solution is designed it is
necessary to decide how access to the data will be handled and to choose an appropriate data
structure. Questions on this part of the syllabus will tend to ask for the sort of choices that need
to be made rather than any complex analysis of fitting a data structure to a given situation,
though simple examples like modelling a queue at a check out till may be asked.
1.7.f System Evaluation
Any system must match certain criteria if it is to be considered successful. This does not only
apply to a computer system but any system. For example, a car must satisfy various criteria
before being able to be called a car
 it must move under its own power
 it must be possible to steer it
 it must have 3 or 4 wheels
 it must have seats.
There would be many other facts which would have to be true before most of us would recognise
that this system is a car. However, some assumptions have been made in just the four criteria
mentioned here. A toy, radio controlled, car fits all these criteria, but it was not the sort of system
that we had in mind when designing the criteria. Perhaps the second bullet point should have
specified that it has to be controlled from within the car itself, or should there be a new criteria
that gives a minimum size for the vehicle. When systems are being designed, this list of criteria,
that the finished system must match, is of paramount importance. It must also be agreed between
the designer of the system and the commissioner of the design, so that there will be no
unfortunate misunderstandings. We can imagine a situation where the Ford motor company
commission a new car design, only to find that it is 30 cms long when delivered.
Note that these criteria are decided before the system is created. They are used to decide how
well the system works. In other words, does it do what it is meant to? This question can only be
answered if it is known what the system was meant to do in the first place.
1.7.g Documentation
The documentation of a system consists of all the text and graphics that explain how the system
was produced, how it should be used, and how it can be maintained.
Documentation is created at different stages in the life of a system and for different people to
use. Some of the different types of documentation are met in this section and others will be
encountered later in the course. Indeed, much of the project work that is done in module 4
consists of producing the documentation for a problem solution.

8. Requirements specification
This is a list of the requirements of the customer for whom the system is being designed. It
consists, largely, of the criteria that will be used for the evaluation of the finished system that
were discussed in section 1.7.f. It is usual for the system analyst and the customer to sign the list
of requirements so that there is no confusion when the work is finished.
Design specification
Taking the requirements specification and working out the stages necessary to produce the
required end product is known as the design specification. This will include the different stages,
often shown in diagrammatic form as mentioned earlier in this chapter, and also the criteria for
each stage of the solution. For example, one part of a solution may be the production of a file of
data. The ways that this file of data relates to the other parts of the system, and the specification
of the file (what is the key field? How many records will there be? What type of medium should
it be stored on?) make up the design specification.
Program specifications
These will include detailed algorithms showing the method of solution for some of the parts of
the problem. These algorithms may well be in the form of flow diagrams or pseudo code. The
language to be used, the data structures necessary, and details of any library routines to be used
will also be in the program specification.
Technical documentation
The technical documentation will include the program specifications, the coded program itself,
details of hardware configurations. Generally, anything that will aid a technician in maintaining
or updating a system. Indeed, technical documentation is otherwise known as maintenance
documentation. This type of documentation is not intended to be accessible to the user of the
system, who does not need any of these details to be able to use the system correctly.
User documentation
This is the documentation for the person who will actually be using the system. It contains those
details that are needed to make the system operate as it should. Items normally included in the
user documentation will be
 examples of output screens
 examples of valid input
 methods of input of data
 error messages and what to do when they appear
 How to install the system onto specific hardware
Some user documentation is part of the software and can be called up onto the screen when it is
needed. This type of documentation is called on-screen help.
1.7.h Testing and ImplementationPlanning
Any system needs to be tested to ensure that it works. This seems to be a fairly obvious
statement, but in reality such testing is impossible in all but the simplest of systems because it
simply is not possible to test every conceivable input to, or logical construction in, the system.
This difficulty means that testing that is to be done must be carefully planned and that it should
relate directly to the criteria referred to earlier in this chapter. Specific types of testing have
already been covered in 1.3.g.

9. When the system has been completed it has to be implemented so that it is performing the tasks
for which it was designed. Initially, this involves
 ensuring that the correct hardware is available
 arranging for staff to be trained in the use of the new system
 inputting the data to the data files, either manually or by downloading them from the original
system.
The system handover, itself can be done in a number of ways:
 Parallel running. Until the system can be considered fault free, the old and new systems are
run side by side, both doing the same processing. This allows results to be compared to
ensure that there is no problem with the new system. Such a system is ‘safe’ and also allows
staff training to be carried out, but it is obviously very expensive because of the need to do
everything twice. Parallel running is used in situations where the data is so valuable that there
must be no possibility of failure.
 Pilot running. Key parts of the new system are run alongside the old system until it is
considered that they have been fully tested. This is a compromise with the idea of parallel
running, but it does not give a clear idea of the effects on the system of the large amounts of
data that are going to be encountered in the full application.
 Big bang, or direct change. The old system is removed and the new system replaces it
completely and immediately.
 Phasing. Parts of a system are replaced while the remaining parts are covered by the old
system. This allows for some testing of the new system to be done, and for staff training to
take place, but also allows for a back-up position if the new version does not work as
anticipated.
This topic is not fully expounded upon here, the candidate simply needing to understand that
there are different methods of implementation and be able to outline some of the methods along
the lines shown here. This topic will reappear for a fuller treatment in section 3.8.e.
1.7.i System Maintenance and the Software Life Span
Systems may be designed for a well defined purpose and may realise that purpose, hence they
would be considered successful. However, the original reasons for a particular system to be
created may change, the hardware may alter, the law governing a system may change. For many
reasons the original system may no longer be satisfactory. One solution would be to produce a
totally new system, another would be to adapt the present one so that it can be used in the new
circumstances. This situation is reviewing the system and is the main reason for technical
documentation.
While the system is running it will need attention because of faults being discovered, this again
needs a technician with a set of maintenance documentation.
Computing and computer applications is a subject that changes so regularly through
improvements in technology, new ideas, different legal frameworks trying to keep pace, that, in
reality, a system should never be considered to be finished. Rather than being a linear process
with a beginning, a middle and an end, it should be thought of as a circular process, continually
returning to previous stages to fine tune them and take advantage of changing circumstances.