Chapter 16

System
life cycle
LEARNING INTENTIONS
By the end of this chapter, you will be able to:
• describe the stages in the system life cycle
• describe methods of research for a given situation
• understand the content and purpose of specifications
• construct diagrams to represent system processing and the flow of data through a system
• design data storage, input forms and output reports
• create a test plan and understand its purpose
• select appropriate test data
• describe the differences between alpha and beta testing
• describe the differences between white box and black box testing
• describe different methods of implementing a system
• explain the advantages and disadvantages of each implementation method for a given situation
 CAMBRIDGE INTERNATIONAL AS & A LEVEL IT: COURSEBOOK

CONTINUED
• describe types of documentation and explain why each is needed
• describe the contents of documentation
• explain methods of evaluating a new system
• describe different types of maintenance and explain why each is needed
• explain how each type of maintenance is carried out
• explain different types of prototyping and explain why each is needed
• explain the advantages and disadvantages of each type of prototyping
• describe the stages and processes of different software development methodologies
• explain the advantages and disadvantages of different software development methodologies.

BEFORE YOU START

• Do you understand what a project is? • Do you know what validation means?
• Do you understand the structure of a database? • Are you able to draw a flowchart?

Introduction KEY WORD

A new system following the waterfall method of analysis: finding out how the current system
software development evolves through a system life works and what the requirements of the client are
cycle. Requirements are specified by the client and for the new system
recorded by the analyst. The designer will then follow
a requirements specification in order to produce a
design specification which will show the client what
the new system is likely to look like. When the user is Methods of research
happy with the design specification, the system will
be developed based upon the design specification and A variety of methods can be used to research current
the developed system will then be tested before being systems and the requirements of a new system.
installed for the client. The client will be provided with
user documentation. An evaluation will take place to Questionnaires
review the system life cycle for the project. Any ongoing Questionnaires are used when information is required
maintenance will be carried out by the maintenance from a large number of users when it would be
team. Other methods for software development are impractical to interview them all. A large number
also used including agile and Rapid Application of users also means there is a large sample size for
Development (RAD). the results of the questionnaire to be quantified and
compared. They are not suitable when there are only
a small number of users involved because there is not

16.1 Analysis a large enough sample size to gauge opinion and it

would be quicker to conduct interviews than spend time
Analysis involves finding out how the current system preparing questionnaires. An exception to this would be
works and what the requirements of the client are for if it is impossible to arrange an appointment time with a
the new system. user or users, in which case questionnaires could be used

344
 16 System life cycle

as an alternative to interviews. The disadvantage of this so that the responses can be analysed collectively. This
is that it doesn’t allow the analyst the opportunity to ask often means providing multiple choice responses so that
the user to elaborate on answers without contacting the each response can be counted. It’s also important to
user again. ensure that the questionnaire does not take too long for
users to complete as otherwise not many responses may
Questions need to be asked in a way in which the
be returned.
required information can be elicited from users, but also

WORKED EXAMPLE 16.01

During the analysis for a new school reports system, the analyst wants to find out from pupils, teachers and parents
what information should be included on the report. One question that could be asked would be:
Please rate from 1 to 5 the importance of the following information on the school report (1 is not important, 5 is
very important):
• Attendance total half days • Percentage score for each end of year exam
• Attendance percentage • Average score for all exams
• Number of negative behavioural events • Comment from subject teacher
• Number of positive praise events • Targets from subject teacher
• Academic grade for each subject • Comment from house tutor
• Position/rank in class for each subject • Target grade.
This will allow the analyst to consider the importance attributed to each piece of information by the three different
groups of people, which will contribute to deciding what is included on the reports and how prominent a position
each piece of information will take.
An alternative way of asking this question would be:
Please list any information you would like to be included on the school report.
This would make it very difficult to quantify the responses and analyse the findings as each respondent would give
very different answers. By providing the list, the analyst is able to give the respondents a starting point.

A mixture of multiple choice questions, opinion ratings applied to compare the responses of all males who work
and open questions should be used. This will provide part-time compared with males who work full-time.
a balance of quantitative analysis of closed questions
and a qualitative analysis of open questions where users Interviews
are able to suggest alternative ideas to those presented
by the questionnaire. Questions should also be written Interviews involve a direct conversation between the
in a way which does not threaten users and the way analyst and the client. Where there is a single end user or
they currently do their work. Users should be given the small group of end users then interviews are the perfect
opportunity to return their questionnaires anonymously solution, because questions can be asked of the users
because that means more honest answers are likely and a conversation can take place which can expand
to be given. upon answers that are given with follow-up questions
searching for further detail. Even in large organisations,
Questionnaires should ideally be completed online. interviews can still be used with key stakeholders or
This means that the results are immediately stored and representatives of user groups.
readily available for detailed analysis in the form of
graphs and tables. Filters can be applied to the results Questions to be asked during interviews should be
and responses can be compared based on the answers planned and designed to elicit the required information
given to another question. For example, a filter could be from the client. The questions will vary depending on
who is being interviewed. If management are being

345
 CAMBRIDGE INTERNATIONAL AS & A LEVEL IT: COURSEBOOK

interviewed, then the questions will focus on the and this may cause them some stress, which means they
requirements of the organisation as a whole and the don’t perform as they would do normally. Although this
information that is required for decision making. If end method can take up a lot of time, it is the most insightful
users are being interviewed, then the questions need to method of finding out how an organisation works.
be aimed at finding out what the users need to make
their jobs more efficient. Interviews don’t have to be with Document analysis
individual users. They can take place with groups of users
or focus groups that represent user groups or customers. Existing documents within an organisation can tell an
analyst a lot about the information that is currently
The logistics of each interview also needs to be planned. being used.
It can sometimes be difficult to find a time when both
the analyst and the client are available, especially if
PRACTICAL ACTIVITY 16.01
the client has a busy schedule. Honesty is important
during interviews so that the analyst can get an accurate Examine the receipt in Figure 16.1.
picture of how tasks are completed. This can sometimes
be difficult to achieve because end users may not
want to admit to taking shortcuts in their tasks or not
carrying out tasks to the best of their ability. In these
situations, anonymous questionnaires can get more
honest responses. With interviews, the analyst has to be
involved with every interview and this can result in a lot
of time being used up early in the project.

Observation
Observation involves the analyst watching the processes
that take place within an organisation to find out
how everyday tasks are completed. This can involve
sitting with users to understand the tasks they have
Figure 16.1: Receipt.
to complete, with an opportunity to ask questions
of the users to elicit further information that could
be needed for a requirements specification. This can 1 Identify the output information that is
give a very good understanding of the current input included on the receipt.
data, processing methods and output information. 2 Identify any calculations that are likely to
Other options can include wandering around an office have taken place on the receipt.
throughout the day to see how information is shared
amongst users. 3 Identify which information is likely to be the
same for all receipts and which information is
likely to be different for each receipt.
KEY WORDS
requirements specification: what a user needs a
The analyst will need to see examples of any documents
new system to do
that show output information or give an indication of
what data is being collected for input to a system. The
analyst can sometimes also identify processes that take
One disadvantage of this method is that when users are
place by looking at documents. It’s also possible to
being observed, they may do things differently from normal
estimate the amount of data that is likely to be required
or they may be more efficient and so this does not give the
if the volume of documents is known.
analyst a true picture of what is happening. The analyst
needs to be able to identify how long tasks genuinely take This method is not to be used on its own but must be
and any inefficiencies that could be improved upon. By used in conjunction with other analysis methods, because
observing users directly, the analyst can get first-hand it is difficult to identify the processes just by looking at
experience of the inefficiencies and can plan to overcome documents. Examination of the documents also only
these. Of course, some users may not like being watched shows data that is currently output and doesn’t give the

346
 16 System life cycle

analyst an opportunity to find out what additional data • processes that need to take place to convert inputs
an organisation might need or what data the organisation into outputs or to store data
does not need. This information can be found out by • data that need to be stored
following up document analysis with interviews.
• functional requirements such as
performance measures
The content of specifications • deadlines for each milestone within the project.
There are three types of specification used within the life
cycle. These can be summarised as shown in Table 16.1. WORKED EXAMPLE 16.02
Here is an extract from a requirements specification for
Requirements Design System
a new town council website. The extract shows specific
specification specification specification
data that is required on the home page in addition to
Created by the Created by the Created by the that which will have been specified for all pages:
analyst. designer. designer.
• Quick links
Contract Shows what the Identifies the
between system will look software and • Show list of links editable by content manager
developer and like. hardware • Initially to be:
client. needed to run
the system. • How can I get involved? (go to Consultations)
Identifies what Describes how Identifies the • How can I stand for council? (go to Elections
the system the system minimum arrangements)
must do. should work. hardware
• When is the next steering group meeting? (go to
needed to run
Meetings)
the system.
Specifies the • When will I be able to vote for councillors? (go
data structure to Key dates)
to be used. • What powers does the Town Council have?

Table 16.1: The different types of specification. • How do I report a problem? (go to City
Council sub-page)
• When can I vote for councillors? (go to
Requirements specification Elections 2016 arrangements)
A requirements specification is a contract between the
• News list
developer and the client. It will specify exactly what
the client needs the system to do so that the developer • Picture, news title, date (taken from list of
can produce a system that meets the client’s needs. The news)
analyst will usually write the requirements specification
• Button: view all news
in consultation with the client who will approve it.
• To show latest four news articles
A requirements specification should include:
• the purpose of the system • What’s on list

• the main objectives of the system • Picture, event title with hyperlink, date and
time (taken from List of events, Key dates and
• data that must be output from the system (for
Meetings)
example, invoices, sales reports)
• Button: view all events
• data that needs to be input to the system to
generate the outputs, including any screens or data • Button: view all key dates
collection forms
• To show next four events.
• validation and verification that is needed for
input data

347
 CAMBRIDGE INTERNATIONAL AS & A LEVEL IT: COURSEBOOK

System specification In addition to this, a design specification will include:

A system specification lists all the software and hardware • house style (logos, colours, fonts, styles, sizes)
that is needed for the new system. The software needs
• screen sizes
to be identified first as the hardware will depend upon
what software is needed. Only software that is needed • connectivity diagram to show links between screens
to run the system should be specified. There may be
• purpose of calculations.
different software identified for different types of users
and for servers.
Once the software is known, the minimum hardware Questions
required to run that software can be identified. In 1 Identify five stages in the system life cycle.
addition to this, the analyst needs to consider how 2 Explain why interviews are better than
much storage space is going to be required for the data questionnaires for smaller groups of users.
being used by the system. The analyst will probably
also recommend higher than minimum specifications so 3 State the purpose of the system specification.
that the system functions at a reasonable speed. These
specifications will include the processing power and
the amount of memory required. External hardware
components that are needed should also be specified
16.2 Design
and these should be based upon the requirements During the design stage, the overall structure of the
of the user. system and details of the system components are
designed without being developed. Diagrams can be
Design specification used to describe how a current system works (during
analysis) or they can also be used to demonstrate how a
The design specification is produced by the designer and
new system will work (during design).
is an illustration of how the system will look, what the
data structures will be and how the system will work. It
is intended to give the user an idea of what the system KEY WORD
will look like before it is developed so that the user’s
feedback can be incorporated into the final designs. The design: the stage in the life cycle when the
developer will then follow the designs. design specification is produced

KEY WORDS
system specification: the hardware and software
System processing
needed to run the system Data flow diagram
design specification: illustration of how the A data flow diagram (DFD) shows how data flows
system will look, what the data structures will be throughout a system. It is not about the order of
and how the system will work processes, it is purely about the data flows. The elements
shown in Table 16.2 are used within a DFD.

Later in this chapter you will learn how to design:

KEY WORD
• flowcharts
DFD: data flow diagram which shows how data
• data flow diagrams
moves around a system
• data collection forms
• screen layouts
• validation routines
• data dictionary.

348
 16 System life cycle

Element Purpose Symbol CONTINUED

Data flow This is the data that
is flowing throughout Guest
the system.

ing
Process This is an action that

Pa
ok
bo

ym
uses or manipulates

ent
ne

Encrypted
key card
data.

Onli
Bill
Data store This is a place where
data is stored. This
could be a hard
disk, cloud storage
or a paper file, for Hotel
booking
example. system
Data This is an external
source or entity where the Figure 16.2: Level 0: DFD.
destination data originates or is
(inputs and destined.
This DFD shows the system as the hotel booking
outputs)
system. It shows the guest as an external entity. It then
Duplication This is where we have shows the four items of data that flow between the
data more than one source guest and the booking system.
source or where data originates
destination. or is destined, to avoid
crossing data flow. To create a level 0 DFD, you should identify the external
entities and the data flows between the external entities
Table 16.2: DFD elements.
and the system. It is important to remember that it is
the data flow that is being represented and not physical
DFDs can exist at many levels. At level 0, or context level, objects. Each data flow will be in one direction only.
the diagram will show the whole system and the data
flows between the whole system and any external entities, DFDs can also be considered to be one of the final
such as customers, suppliers, members, guests, etc. stages of analysis as they can be used to record the
data flows that are currently taking place within an
existing system.
WORKED EXAMPLE 16.03
A hotel accepts online bookings for its hotel rooms. PRACTICAL ACTIVITY 16.02
Guests make a booking online and the booking is
received by the hotel. When the customer arrives, they Create a level 0 DFD for the following scenario:
are given an electronic key which includes encrypted A car hire company accepts bookings of cars
data that will unlock the door and allow purchases at by telephone. A credit card payment for the
the bar. At the end of the stay, the guest is presented deposit is taken from the customer at the time
with a bill which must be paid before leaving. of booking. When the customer arrives to collect
the car, they have to provide details of their
driving licence, which are stored by the car hire
company. The car hire company will provide
the customer with details of the insurance and
breakdown services for the car. The customer
must pay the remainder of the hire cost before
taking the car. The customer will be presented
with an invoice showing the payments made.

349
 CAMBRIDGE INTERNATIONAL AS & A LEVEL IT: COURSEBOOK

The next level is a level 1 DFD. This shows the flow of store to another or between an external entity and a
data within part of a system, or if the system is small data store because a process is required to deal with the
within the whole system. If the DFD is showing just data. Ignore how the data will actually be processed and
part of a system, then other parts of the system are just focus on the data movements.
considered to be external entities. Each flow of data
must be linked to a process, because something has to PRACTICAL ACTIVITY 16.03
happen to the data before it can be stored or passed
onto an external entity. Create a level 1 DFD for the car hire company
introduced in Practical Activity 16.02. Assume the
DFD will be for the whole system.
WORKED EXAMPLE 16.04

Figure 16.3 is a level 1 DFD for the hotel booking

system. Any other aspects of the hotel system are System flowchart
considered to be external entities. A system flowchart shows the flow of data and processes
within a complete system. A system flowchart will show
Guest
how various elements of an information system are
related. System flowcharts were popular in the 1960s
Payment
Encrypted

and 70s when punched card and magnetic tape were

key card

Bill
commonplace, but they are not as commonly used
Hotel booking system
in modern systems analysis techniques. The elements
Online booking
shown in Table 16.3 are used within a flowchart.

Check room Activate Produce Bar

Bar
availability key card expenditure
bill
KEY WORDS
Booking
details

Booking

Room
details

access system flowchart: an overview of how a system

details
Bookings Rooms
works in a diagrammatic format
Accept
payment
Booking
details

Payment details Element Purpose Symbol

Manual Manual input into a
input computer system,
Figure 16.3: Level 1: DFD. for example using
a keyboard.
When the guest sends their online booking, the
room availability is checked and the booking details Arrow Shows the direction
are stored. When the guest arrives, their key card of flow.
is activated by retrieving the room access details.
When the guest is ready to leave, a bill is produced by Process An activity within
retrieving the booking details and any bar expenditure the system.
from the bar system. When payment is made, the
booking details are updated to confirm that payment
has been made.
Document A single printed
document.
To create a level 1 DFD, first identify any external
entities and any other parts of the system that will be
classed as external entities. Identify the data flows to and
from those external entities. Each data flow must have a
process attached to it. A data flow cannot move directly
from one external entity to another or from one data

350
 16 System life cycle

Element Purpose Symbol CONTINUED

Multi- Multiple printed
Hotel bookings are input manually using a keyboard.
document documents.
While editing the booking, the data that has been
input is displayed on the screen. Data for the guest
who will be staying at the hotel is retrieved from
the guests’ file. When the data has been input, it is
Magnetic Storage on a validated and the user is required to correct any
disk magnetic disk, errors. A process then saves the booking and prints
although in a booking confirmation document which can be
modern systems, sent to the guest. Each morning, guest arrival sheets,
other storage which include information about each guest and the
methods are likely. room they will be staying in, are printed. Also in the
morning, a checkout list is printed which shows which
Magnetic Data stored on a rooms are due to be vacated that morning.
tape magnetic tape.

To create a system flowchart, identify the processes that

take place within the system. Then identify the different
files that will be used. Use arrows to connect process to
Display Output on a visual data files with the arrow pointing towards the data file
display. if data is being stored, or the arrow pointing towards
the process if data is being retrieved. If user input is
required, then add the manual input symbol at the
appropriate place with the arrow pointing towards the
process. Identify any documents that are produced by
Table 16.3: Flow chart elements. the system and link each one with a process with the
arrow pointing from the process to the document.

WORKED EXAMPLE 16.05 PRACTICAL ACTIVITY 16.04

Figure 16.4 is a flowchart for taking a hotel booking Create a system flowchart for the following
online. scenario:
A pizza delivery company accepts orders for
Guests Guest
pizzas by phone. The customer is asked for their
file arrival
sheets
address and the system checks the address is in
the delivery file. The customer is asked for their
Enter hotel Edit the
Booking Print guests order and the telephone operator inputs the
confirmation arrival sheets
booking booking order into the system. The order is added to the
orders file. Payment details are then taken from
Booking
Print
Bookings
the customer which are saved to the payments
checkout list
display file file. A receipt is printed for the customer and an
order sheet is printed for the cooks.
Validate the Correct Save and print
booking data errors the booking

Booking
confirmation

Figure 16.4: Online hotel booking flowchart.

351
 CAMBRIDGE INTERNATIONAL AS & A LEVEL IT: COURSEBOOK

Data storage
Data dictionaries
A data dictionary should be created to describe how data will be stored in tables within a database. The fieldnames
should be identified along with their data type, field size and format. Primary keys and foreign keys be identified,
including the names of tables to which the foreign keys link to. Any input masks, validation rules or default values
should be identified for each field along with an example of what typical data might look like.

WORKED EXAMPLE 16.06

This is an example of a data dictionary for a table about students.

Attribute Data Length Format Validation Rule Default Sample Primary Foreign
type Value Data Key Key
Student ID Integer 6 999999 Autonumber 459283 Yes
Forename Text 20 Xxxxx Required Mao
Surname Text 20 Xxxxx Required Zedong
Other names Text 50 Xxxxx Required Xi
Tutor Group Text 3 99X 12A TUTOR
GROUP –
TgId
Date of Birth Date 8 DD/MM/ <= 10 years 12/04/2007
YYYY before today
Date Joined Date 8 DD/MM/ >= 10 years 01/09/2018
YYYY after date of
birth
Date Left Date 8 DD/MM/ > [Date
YYYY Joined]
Disability Boolean 1 Required False True

PRACTICAL ACTIVITY 16.05

Revise data types, field sizes, primary and foreign keys and validation from chapter 10. Complete the
following data dictionary for a table of vehicles:

Attribute Data Length Format Validation Default Sample Primary Foreign

type Rule Value Data Key Key
Vehicle Registration
Make
Model
Engine size (cc)
Transmission
Number of doors
Imported?

352
 16 System life cycle

An entity relationship diagram should be created to job applications or reply slips. It is important to design the
show the relationships between the tables that will be form in such a way that the required data can be collected.
used. Refer to Chapter 10 for detailed information about When designing a data collection form, it is good
entity relationships. practice to follow these principles:
• avoid colour as the document may not be
Files
printed in colour
Any files that will be used to import data should be
• include instructions about how to complete the form
designed, including the intended layout of data. Similarly,
any files generated by the system should be designed, • give clear instructions about where the form should
including the format in which the data will be exported. be returned
The type of files should be specified, for example, whether • identify which questions must be answered and
it is comma separated or tab delimited. The contents of which are optional
each column should be specified including the expected
• provide enough space for each answer
data type, length and format of each column.
• use tick boxes for multiple choice lists
• make it clear how many options are allowed to be
Input forms chosen from a multiple choice list
Data collection forms • ensure all fonts are consistently used
Data collection forms are documents that are used to • avoid cluttering the form with too much
collect data without the use of a computer. These could information or too many questions
include membership application forms, questionnaires,
• ensure the font style and size are legible

Figure 16.5: Example of a data collection form.

353
 CAMBRIDGE INTERNATIONAL AS & A LEVEL IT: COURSEBOOK

• if the respondent needs to complete a scale (e.g. user expects should be used, for example green
1–10), then explain what the scale represents is usually seen as a positive colour and red as a
(e.g. 1 = very dissatisfied, 5 = neither satisfied or negative colour
dissatisfied, 10 = very satisfied). • ensure all fonts are used with consistency
• avoid cluttering the screen with too much
PRACTICAL ACTIVITY 16.06 information, but at the same time try to fit all
Explain how the application form in Figure 16.6 information that needs to be viewed at the same
could be improved. time on a single screen
• ensure the font style and size are legible

Membership Application Form

• if the screen requires user input:
• include instructions about how to
complete the form
Name________
• identify which questions must be answered and
Address________________________________________________________ which are optional
Gender________________________________________________________
• provide enough space for each answer
Age___________________________________________________________

Do you have any disabilities? Y/N

• use tick boxes for multiple choice lists that can
have more than one response
Which of the following types of movie do you watch? Horror Action
Drama Comedy Other • use drop-down boxes (combo boxes) or option
buttons (radio buttons) for multiple choice lists
Figure 16.6: Poorly designed form. that can only have one response.
See C*hapter 2 for detailed information about the types
of form controls that can be used on input forms.
Screen layouts When designing a screen or collection form, it is only
A screen can be used to ask the user for data to be input necessary to indicate where questions and responses will
or to display information to the user or a mixture of go, the types of response options and the styles to use.
both. For example, Figure 16.7 shows information about The layout of any information should also be indicated.
a property that is for sale. It also allows the user to The developer will then follow the design.
change details about the property or add details about a
Arial, bold, 18,
new property. black

Title: Lesson Charge Calculator

* Please select the type of lesson you require:
drop-down box for type
of lesson: Beginner
Test Retake
Disqualified retake
Advanced

* Please select the number of hours you require:

radio buttons
1 Hour
2 Hours
3 Hours

* The total charge for your lesson will be:

$ total charge for lessons in $ dollars

Figure 16.7: Screen example. Main Menu Clear Arial, bold, 20,
black, yellow
Button to Button to background
When designing a screen it is good practice to follow return to clear screen
main menu
these principles:
• use colour sparingly and appropriately; different * Instructions in Arial, 14, black 800 x 600 screen
colours could be used for questions and responses
or for different types of data; colours that the Figure 16.8: Example of a screen design.

354
 16 System life cycle

Validation routines Input data Validation Validation Error

type rule message
PRACTICAL ACTIVITY 16.07 Application Type Must be The
Revise validation routines from Chapter 1. number a whole application
Complete the following table. number number
must
Validation Description Example contain only
type numbers
Presence Telephone Length Must be Telephone
between number
Range
3 and 15 must be
Type digits between
Length 3 and 15
digits
Format
Product Format XX999XX9 The product
code code must
Validation rules should be used wherever possible be in the
and be appropriate in order to reduce the number of format
possible input errors. They only need to be used for XX999XX9
input data so any calculations or output data do not where X is a
require validating. Drop-down boxes should always be letter from
used instead of lookup validation checks. For example, A to Z and 9
if a category needs to be selected, then a drop-down is a number
box should be used to select that category rather than from 0 to 9
requiring the user to type in the category. Table 16.4: Examples of a design for validation.
When designing a validation rule, identify the input data
that is to be validated, the type of validation rule to be
used, the rule that will be used and the error message
Checking of data collected by forms
that should appear if the data input is invalid. Error In addition to validation rules, any intended methods
messages should be positive and guide the user as to for verifying data input such as visual checking,
what to do to correct the error. double data entry or hash control should be specified.
See Chapter 1 for detailed information about these
Input data Validation Validation Error verification methods.
type rule message
Surname Presence Surname Please enter
must be a surname Output reports
entered The design of output screen layouts follows the same
Date of Range Date of Applicant principal as input forms except that there is no need for
birth birth must must be instructions or input fields.
be at least at least 18
18 years years old Printed copy layouts
earlier
When designing a printed copy layout, as well as
than today
following the same principles for output reports,
consideration needs to be made to the size of paper
that will be used, the size of margins and the intended
audience. Printed copies can often include tabular data.

355
 CAMBRIDGE INTERNATIONAL AS & A LEVEL IT: COURSEBOOK

WORKED EXAMPLE 16.07

16.3 Development
This example shows a report for listing all the
products available. and testing
The development stage is often referred to as the
Products implementation stage where the design is implemented.
Due to the confusion between implementation
of the design and implementation of the system,
Description Category Supplier 1
development is now a more commonly recognised and
Description Category Supplier 1 understood term.

Description Category Supplier 1

KEY WORD
Description Category Supplier 1

development: the stage in the system life cycle

Page n of nn 2 Total products: ## 3 when the software is produced

Key:
field from the database Test data
field titles (should appear at top of every page)
When a system has been developed, it needs to be tested.
data that should appear at the bottom of the whole report only
In order to test the system, data has to be created that
data labels
will be used for the purpose of testing. This is known
Figure 16.9: Example of report listing for products. as test data. The data used in this phase is a simulation
of ‘live data’. There will need to be enough test data
1 The description, category and supplier generated to ensure that the system is able to cope under
data will be repeated for each record in the the pressures of large amounts of data in everyday
PRODUCTS table. use. There will also need to be specific types of data to
test different scenarios within the software, including
2 n = page number, nn = total number of pages validation rules and queries.
3 ## = total number of products in
PRODUCTS table
KEY WORD
In addition to these points, the size of paper, size
of margins, font styles and sizes, colours and any test data: data that will be used for testing a
gridlines should also be specified. system

When testing the input of data that is to be validated,

PRACTICAL ACTIVITY 16.08
Table 16.5 shows the types of data that should be
Design the layout of a report that will show a list included as test data:
of all the students in your class including their
dates of birth and contact details. Type of test data Description
Valid (also called Data that will be accepted by
normal data) the validation rule.
Questions Invalid (also called Data that will not be accepted
4 Identify the purpose of a data flow diagram (DFD). abnormal or by the validation rule.
5 Identify one rule for data flows within a erroneous data)
level 1 DFD.
6 Describe the difference between a tick box and an
option button.

356
 16 System life cycle

Type of test data Description WORKED EXAMPLE 16.09

Extreme (also Data that will only be
The following data for records could be used to test
called extreme accepted by the validation
the query for males over the age of 50 (including 50).
data) rule because it is at the limit
of acceptability. Record Gender Age Reason
Table 16.5: Types of test data. number
1 M 65 Both criteria met
2 F 25 Both criteria not met
WORKED EXAMPLE 16.08 3 M 25 Gender part met, age
To test the validation rule that gender must be ‘M’ or part not met
‘F’, the following test data could be used. 4 F 65 Gender part not met,
age part met
Type of test data Data 5 M 50 Age part only just
Valid (normal) M, F met
6 M 49 Age part only just not
Invalid (abnormal or B
met
erroneous)

To test the validation rule that a date must be between

1/1/2017 and 31/12/2017, the following test data could The more criteria that are used and the more
be used. possibilities for extremes, then the more records that will
be required to test the query fully.
Type of test data Test data
Valid (normal) 12/5/2017 PRACTICAL ACTIVITY 16.10

Invalid (abnormal or 15/7/2012, 4/6/2019 Data is stored about cars, including their make,
erroneous) model, registration number, transmission
(automatic or manual), colour, distance travelled
Extreme 1/1/2017, 31/12/2017
and year of registration. Select test data that
could be used to test the query to find all
automatic transmission cars that were registered
before 2016.
PRACTICAL ACTIVITY 16.09

Select test data to test the input of numbers in The system will also be tested to see how it works under
the range 2500 to 5000. normal conditions and so a sample set of `live data’ will
be used to test that the system functions correctly under
normal conditions. ‘Live data’ is the actual data being
Test data is also needed to test queries. Records will used by the system once it has been implemented, and
need to be created where there is data that meets the so a sample of `live data’ enables a simulation of a live
criteria of the query, does not meet the criteria of the system to take place. This type of testing with a sample
query, only just meets the criteria of the query and only of ‘live data’ will be carried out by the end-users in most
just fails to meet the criteria of the query. Where there is circumstances. They will use the data as if they were
more than a single criterion, data should also be selected doing their normal job, simulating different processes
that only meets part of the criteria in case both parts that they would carry out.
have not been set up correctly.

357
 CAMBRIDGE INTERNATIONAL AS & A LEVEL IT: COURSEBOOK

Alpha testing and beta testing White box testing usually takes place with small program
modules and is carried out by the software developers who
Alpha testing is carried out by the developers or a coded the programs. They will do this to ensure that each
specialised team of testers before a system is delivered to module works in the way it was intended, and because
the user. This usually takes place close to the end of the they know the inner workings of the module they can test
development stage when the application is nearly ready pathways that a black box tester would not know about.
for the user. Alpha testing can take a long time because The testing will be focused on whether detailed designs,
each time an error is found, testing has to be repeated such as validation rules, have been developed correctly.
when the error has been corrected and there may be
knock-on effects to other parts of the system. Black box testing usually involves testing the whole
system or user testing. It can be carried out by specialist
Beta testing is used when software is being made available testers or, in the case of user testing, by the intended
to a large number of customers. Beta testers will be users. No knowledge of programming or the way the
real customers who have been selected to test an early system works is required. The testing will be focused on
release of the application. Beta testing only takes place ensuring the requirements specification has been met.
after alpha testing has been completed. Alpha testing
is planned and structured using test data to follow all White box testing needs access to a detailed specification,
pathways through the software but beta testing involves whereas black box testing does not require knowledge
customers using the software in a real world environment of how the system was developed. In black box testing,
using real data. As bugs are found within a beta version, only a limited number of test scenarios are actually
new beta versions will be released for further testing performed due to not knowing how each module works,
before a final version is released for sale. but with white box testing, each module can be tested
in-depth. Black box test plans are difficult to design
because so many different input data options have to
KEY WORDS be considered along with pathways through the system,
alpha testing: initial testing of the software by a whereas with white box testing, test plans can be created
for each calculation, navigation and input separately.
limited group of people
With white box testing, the tester can identify the type
beta testing: a sample of users test a pre-release of test data that will be required, particularly related to
version of the software valid, invalid and extreme test data, but with black box
testing, the tester may not know what the boundary
values are expected to be. Due to needing to understand
the code, skilled testers are required to carry out white
Black box testing and white box testing, whereas black box testing can be carried out
by moderately skilled testers.
box testing
Black box testing involves selecting input data and The importance of testing and
checking that the expected output data matches the
actual output data, with no knowledge or understanding having a test plan
of what happens inside the black box. The black box Testing is necessary because no programmer or developer
could be the whole system or part of a system. White
is perfect and errors are to be expected. These errors need
box testing involves the same process of input and
to be found and rectified. It is important to ensure that
output data but the internal structure and logic of the
the system is error free so that the users can use the system
program are known to the tester.
knowing that it will work reliably and behave as expected.
Although it’s almost impossible to ensure a system is
KEY WORDS completely free of errors, a test plan can help to minimise
black box testing: testing of inputs and the number of errors by ensuring that all pathways
outputs to a system or part of a system with no through a system and types of data have been tested.
consideration for the workings of the system
KEY WORD
white box testing: testing the whole system in
terms of structure and logic covering all paths test plan: a detailed and structured plan of how
through the system testing should be carried out

358
 16 System life cycle

WORKED EXAMPLE 16.10

This extract, from a test plan, tests the input of data where the date must be between 1/1/17 and 31/12/17.

Number Description Type of test Input Expected result Pass/Fail

data
1a Test the Valid 12/5/17 Accepted Pass
1b input of join Extreme 1/1/17 Accepted Pass
date.
1c Extreme 31/12/17 Accepted Fail – error message
1d Invalid 15/7/12 Error message: the join Pass
1e Invalid 4/6/19 date must be in 2017. Pass
1f Extreme 31/12/16 Fail – accepted
1g Extreme 1/1/18 Pass

The reason the test for 31/12/17 failed to be accepted may be because <31/12/17 was used in the validation rule
rather than <=31/12/17. Similarly, the reason 31/12/16 failed to generate an error message may be because >=
31/12/16 was used in the validation rule rather than >31/12/16.

A test plan will identify all the tests that are needed
for every input, every button, every link, every report, Test plans
every screen and all other elements of a system. The test A test plan will identify what is being tested, the type
plan will include different types of test data, including of test, the input data that should be used to test it, the
valid, invalid and extreme, so that inputs are tested to expected result of the test and space to record the actual
their limits. Without this planning, important parts of result. Each test will be numbered.
testing would be missed out and errors could be left
undiscovered. The plan will also cover all the user’s
PRACTICAL ACTIVITY 16.11
requirements and ensure that they are tested.
A good test plan will provide a systematic outline of Create a test plan to test the input of data for a
all features and functionality which will be continually character code between the letters D and P.
updated to reflect any new risks as the software is
developed. The test plan will ensure that all aspects
of running a test are considered and prevent aspects As well as inputs, it is important to test that all
being missed out. The test plan is also important so calculations work as expected. Each input for a
that testers know what the testing regime will involve calculation will need to be identified and an expected
and that there is a mechanism for ensuring each test is result determined. Table 16.6 shows an example of how
carried out as planned and signed off. testing of calculations might be planned and executed.

Number Description Type of Input data Expected result Pass/Fail

test
2 Discount formula Calculation Charge per hour = $13 on Test retake = $25 in Pass
works for 2 hours quote worksheet 2 hours column
3 Function for lesson Calculation Lesson type = advanced Total charge = $19 Fail = $1.90
charge
Number of hours = 2 on
quote worksheet

Table 16.6: Examples of test plan for calculations.

359
 CAMBRIDGE INTERNATIONAL AS & A LEVEL IT: COURSEBOOK

Any links or buttons also need testing. Table 16.7 shows

how a navigation button (main menu) and an action
button (clear) would be tested.

Number Description Type of test Input data Expected result Pass/fail

4 Main menu Button Click on main menu The main menu Pass
button button on quote worksheet opens
worksheet
5 Clear button Button Lesson type = advanced, Lesson type = Fail – number of
works number of hours = 2 (blank) Number hours remained
Click on the clear button of hours = as 2
on quote worksheet (blank)
Table 16.7: Example of a test plan for buttons.

Questions Parallel running

7 Describe the purpose of using extreme test data. Parallel running is when a new system and an old system
8 Describe two differences between alpha and are run at the same time. On an agreed date, the new
beta testing. system will become live but the old system will continue
to run. Data will need to be duplicated from the old
9 Explain black box testing.
system to the new system. New data will need to be input
10 Explain the importance of having a test plan. into both systems and output will be produced from
both systems. This will continue until the organisation is
REFLECTION confident that the new system is running satisfactorily.

What would be the implications of rocket launch

system software not being fully tested? Direct changeover
Direct changeover is when a date is chosen for the old
system to stop running and the new system to start
running. The systems do not run at the same time
16.4 Implementation and there is a clear break from the old system to the
This section has the title ‘Implementation’, however, the new system. Data will need to be transferred from the
term ‘installation’ can also be used. Implementation old system to the new system before the new system
can have two meanings within the system life cycle and can be used.
is sometimes understood to be the development stage
where the design is implemented.
Phased implementation
With phased implementation, parts of the new system
KEY WORD
will be introduced one at a time. This often takes place
implementation: the stage in the system life when there is a large system with lots of functionality
cycle when the software is installed for the user that can be easily separated into sections. The old system
will run until a date that has been agreed, at which point
part of the old system will be retired and part of the
There are four different methods of implementing new system will start running. After a while, another
(installing) a new system which can be remembered as part of the old system will be retired and another part
the 4 Ps: of the new system will start running. This will continue
until the complete new system is fully running.
• parallel • phased
• plunge (direct) • pilot.

360
 16 System life cycle

Pilot implementation • how critical the system is to the running of the

organisation
Pilot implementation takes place when part of an
• cost
organisation starts to use the new system while the rest
of the organisation continues to use the old system. The • number of users in the organisation
new system is effectively being beta tested by the pilot
• the size of the new system.
group who may also be able to deliver training to the
rest of the organisation when the system goes fully live. The advantages and disadvantages of each method is
shown in Table 16.8.

Choosing an implementation
method
The most suitable changeover method will always
be dependent upon the individual circumstances
surrounding a new system. Factors that will need to be
taken into account will include:

Implementation Advantages Disadvantages

method
Parallel Less risky because if the new system Duplication of data input means additional
fails the organisation can continue to run staffing costs.
using the old system.
There may need to be additional hardware
The accuracy of the new system can be installed at the same time as the old hardware
tested against the old system and any is still being used, which will require physical
errors can be fixed. space.
Data may be input differently into the two
systems, meaning that the data is not accurate
in both.
Direct This is cheap to implement because there This is a risky method because any errors
is no duplication of work. could lead to the system failing with no
fallback.
The data being used will be consistent
because it is only being used in one All the training will need to be done in
system at a time. advance of changeover and so if there are a
lot of users this could result in some forgetting
There is no need for the new system to
what they’ve learned by the time they start to
be compatible with the old system.
use the new system.
Phased If there are any errors, they will only affect Delays can occur waiting for each phase to
the part of the system that has changed be running successfully before the next phase
over rather than the whole system. can start.
End users can be trained how to use each Users will be using two different systems and
phase of the new system and spend time they may get confused as to which system
using that phase before being trained in they should be using for which part of their
the next phase. work. This could lead to data being updated
in the wrong system.
Both the old and new system need to be
compatible with each other in order for data
to be used across both systems.

361
 CAMBRIDGE INTERNATIONAL AS & A LEVEL IT: COURSEBOOK

Implementation Advantages Disadvantages

method
Pilot If there are any errors, they will only affect This is a slower method of changeover
the pilot group that are using the system. because the rest of the organisation has
to wait until the pilot has been completed
Any errors found by the pilot group can
satisfactorily.
be fixed before the system is installed for
all users. Users in the pilot group might not be happy
about using the new system while it may still
The pilot group can train other users on
have some errors in it and users not in the
how to use the system because they will
pilot group may be disgruntled that they have
have experienced using it for real.
not been offered the opportunity to try the
new software first.
Both the old and new system need to be
compatible with each other in order for data
to be shared between the pilot group and the
users still using the old system.

Table 16.8: Advantages and disadvantages of implementation methods.

Questions validation rules will be listed with the criteria used

for successful input and the error messages that they
11 Identify four methods of changeover. generate. The purpose of calculations within the system
12 Describe one situation when direct changeover will be identified and an explanation given of how each
would be more appropriate than parallel calculation works. All buttons and links will be listed,
changeover. including where they are located and what their function
is. All files used by the system will be listed and their
13 Describe one situation when pilot changeover would
purpose identified. The technical documentation will
be more appropriate than phased changeover.
also include flowcharts to show how different parts of
the system work and other diagrams that may have
REFLECTION been used during design and development such as entity
relationship diagrams and screen connectivity diagrams.
Find out what happened in 1992 when the
London Ambulance Service Computer Aided
Dispatch system failed. What lessons can be KEY WORDS
learned from this?
technical documentation: an overview of the
structure of the system, how it was put together
and how it works

16.5 Documentation There will be an installation guide for the installation

team and also in case the system has to be installed
Technical documentation again in the future. All the results of testing will be
Technical documentation is an overview of the structure recorded, including any known errors and bugs. Backup
of the system, how it was put together and how it works. routines will be detailed to show where files are stored,
It will include a data dictionary to show how data has how the routines were configured and how to restore
been structured within the system. Any programming from a backup. All security settings will be documented
code or macros will be annotated to explain their to show which groups have access to each part of the
purpose and anything unusual, along with a list of system and the permissions they have been granted. The
variables including their datatypes and purpose. All software and hardware requirements will also be listed.

362
 16 System life cycle

User documentation The main part of the user guide will be the instructions
on how to use the system. This should include written
User documentation is a user guide giving instructions instructions together with screenshots of the system
to the user. It can be in electronic or printed format. or photographs of hardware. Arrows can be used to
A printed user guide should have a front cover that point to parts of screenshots or photographs. Bullets or
clearly identifies the name of the system and the whole numbering should be used to break instructions down
guide should have a header or footer with page numbers. into manageable tasks.
A contents page should be included with page numbers
A glossary will show an alphabetical list of any technical
and an electronic version would include hyperlinks to
terms that have been used within the user guide and a
those pages. An introduction to the purpose of the user
definition of each of those terms. There should be a
guide should be included, but it only needs to be a few
troubleshooting section that includes a table of common
sentences. All the software and hardware requirements
problems (for example, error messages) together with a
will be listed within the guide.
description of what might have caused the problem and
possible solutions for overcoming the problem. An index
KEY WORDS will be included at the end of the user guide with page
numbers for each popular term.
user documentation: a user guide giving
instructions to the user on how to use
the software

WORKED EXAMPLE 16.11

This is an example of a troubleshooting guide for a printer.

Problem Cause Solution

Orange light displayed on No paper in feeder tray. Add paper to the feeder tray.
printer.
Red light displayed on Paper is jammed in the Open the paper feeder tray and check there is
printer. printer. no paper stuck there. Open the back door and
check there is no paper stuck there. Open the
toner door, remove the toner and check there
is no paper stuck there. If any paper is found,
gently pull any paper that is stuck.
Error message on computer Printer is turned off. Turn on printer.
says ‘Printer Offline’. Printer is not connected to Ensure the USB cable is connected between
the computer. the computer and the printer.

363
 CAMBRIDGE INTERNATIONAL AS & A LEVEL IT: COURSEBOOK

CONTINUED
Below is an example of a troubleshooting guide for an order processing system.

Problem Cause Solution

Microsoft Access On the New order form Enter a smaller quantity.

you have specified a
quantity larger than the
i Not enough items in stock
amount currently in stock.
OK

Figure 16.10: Error message 1.

Microsoft Access On the Order details form Check the invoice has been dispatched. If it
you have ticked the Paid has, then tick the Invoice dispatched box.
i Invoice cannot be paid if not dispatched
box before the Invoice has
OK been dispatched.

Figure 16.11: Error message 2.

what has caused an error to occur and what they need to

PRACTICAL ACTIVITY 16.12 do in order to stop the error from occurring.
Find a user manual for an electronic device or
appliance at home. Identify the different sections
that are used and compare them with those Questions
listed in Worked Example 16.10. 14 Give three sections you would expect to find in user
documentation.
15 Describe the purpose of a glossary in user
Why technical and user documentation.
16 Give a situation when technical documentation
documentation is needed would be needed.
Technical documentation is required so that anybody
carrying out future maintenance on the system will
be able to understand how the system was developed
and how it is configured. It is unlikely that the person
16.6 Evaluation
carrying out future maintenance is part of the original When a system has been developed and installed, the
development team and so will not be familiar with whole process will be evaluated. This is sometimes
the system without the technical documentation. referred to as a review. The evaluation will consider how
Even if it is the same person or team carrying out the the project team and end users worked together so that
maintenance, they will need the documentation to lessons can be learned for future projects.
remember the structure of the system.
User documentation is needed so that the user can KEY WORD
learn how to use the new system or look up how certain
features are supposed to work. The troubleshooting evaluation: a formal review of a project
section will be important for the user to understand

364
 16 System life cycle

Users will be given questionnaires to find out what

they think of the new system and how they feel it is
Perfective maintenance
improving their workflow (or not). Selected users will The idea of perfective maintenance is to be always
also be given specific tasks to complete that will be looking to improve a system. There may not be anything
observed to see whether the new system is living up to its wrong with the system, but there may be ideas to make
expectations. Some users will also be interviewed about the system perform better or to do additional tasks.
their interaction with the new system. Sometimes improvements might be possible because of
new technology that has become available.
The most important question to be asked will be
whether the system meets the user requirements. Each If a system remains in place for several years without
requirement will be considered in turn to determine if it any improvements, then it may become outdated
has been fulfilled. If it hasn’t been fulfilled, then actions and inefficient compared with other systems that
will be set to rectify the situation in the long run. The are available. Users will also have new ideas and if
efficiency of the new system will also be discussed. Users they are likely to improve efficiency then they should
will have been given an opportunity to feed back on how be embraced.
well the new system is working for them and if there are
For example, an online accounts application sends
any problems. It is expected that the new system will
out automatic reminders to customers when payments
work more efficiently than the old system. However, if
haven’t been made. These reminders are sent to a single
there are problems that need addressing, then actions
customer contact. The system only allows for the
will be taken.
contact details of one person to be stored. Many users
The requirements specification should have specified of the accounts application have requested that the
how easy the new system should be to use. This can be system be adapted to store details of multiple contacts
rather subjective and so it is difficult to measure. Again, for each customer and that contacts who should receive
feedback will have been gained from users as to how invoice payment reminders are identified within the
well they have adapted to the new system and how easy software so that they go to the right person.
or not they find it to use now they are using it regularly.
If there are issues regarding ease of use, then plans can
be made to simplify any processes by adding additional Adaptive maintenance
features to the software if necessary.
Systems need to adapt to changes. There could be
There will also be an opportunity for users to make changes to internal procedures within an organisation
suggestions for future improvements or additions to or changes over which the organisation has no control.
the system. For example, new government legislation could be
introduced to which the system has to adapt. It’s
necessary to adapt to changes so that the system
Question continues to work effectively and doesn’t produce
17 State three elements that might be evaluated after a incorrect outputs. It’s important that the system enables
system has been installed. an organisation to comply with new laws. There is
also a need to adapt to new technology such as a new
operating system, new web browser and new hardware.

16.7 Maintenance For example, the government introduced new

requirements for organisations to provide pensions to
Maintenance takes place after a system has been all employees. The online accounts application needed
delivered to a customer and it is being used. There are to be updated to include a facility for checking that all
four reasons why maintenance might be required, which employee payslips include pension payments unless they
are outlined here. have opted out of the scheme. The accounting software
was supposed to show a paper clip symbol to indicate
that a receipt had been uploaded against a recorded
KEY WORD expenditure. When a web browser was upgraded, this
paper clip stopped being displayed. The software had to
maintenance: changes made to a system after its
be adapted to work with the new web browser.
implementation

365
 CAMBRIDGE INTERNATIONAL AS & A LEVEL IT: COURSEBOOK

Preventative maintenance
Preventative maintenance is required to prevent
Identification
problems arising within a system. This can apply to both and tracing
Analysis Design
hardware and software. Hardware should be regularly
cleaned to stop dust from blocking any fans and regular
scans of storage media should be carried out to ensure
they are working properly. Heat should be monitored
within systems for any abnormalities to prevent Maintenance Maintenance Implementation
hardware failures. Data should be regularly checked for management
activities
consistency and integrity. Performance of the system
should be monitored to ensure that the processor,
memory and storage are all working efficiently. By
carrying out regular preventative maintenance, system
downtime can be avoided. Delivery
Acceptance System
testing testing

Corrective maintenance
When errors or bugs are found within a system they Figure 16.12: Maintenance activities.
need to be corrected. This will be the responsibility
of the original developers, although it may be different Maintenance needs to go through the same stages as
people that carry out the maintenance. These errors software development because the software is being
need to be corrected so that the system can run further developed. Testing is still very important because
efficiently and accurately and produce the results any changes made could affect existing parts of the
required by the organisation. Bugs that cause problems system. The maintenance team can be formed using one
by making a system slow or by crashing a system of three different approaches:
can be very frustrating to users and reduce overall
productivity. • separating development and maintenance: the
maintenance team will be different to the original
For example, a graphics application would intermittently development team.
stop responding for several seconds. This was not
supposed to happen and so corrective maintenance • combined approach: the maintenance team will
was required. include both maintenance specialists and members
of the original development team.

How maintenance is carried out • functional approach: this is similar to the combined
approach, but systems personnel are assigned to
There are many ways in which maintenance to software
functional areas within an organisation where
can be carried out, but one widely used methodology
they are responsible for both development and
similar to the software development life cycle (SDLC)
maintenance within that functional area.
is the maintenance process model. The maintenance
process model includes the following stages: Maintenance starts with the identification and tracing
stage. A modification request (or problem report) will
be generated which could be a request by a user or it
could be as a result of collating error logs from the
system. The modification request must clearly describe
the existing functionality of the system and the desired
functionality of the system. The modification request
will need to be classified as either perfective, adaptive,
preventative or corrective maintenance.
During the analysis stage, a change impact analysis
will take place. An impact analysis involves identifying
all systems and software that will be affected by the

366
 16 System life cycle

change, the risks associated with the change, an estimate During system testing, new and modified modules
of the resources that will be required to implement will be tested together as a group. This type of testing
the change and a cost-benefit analysis of the change. is known as integration testing because the testing is
If the impact of the change is considered to be severe designed to expose faults in the interaction between
then an alternative solution may be sought. If the integrated units. Following this, regression testing will
impact is manageable then the required modifications take place. This is effectively re-running the original test
from the modification request will be analysed with the plan for the original software to ensure that the software
customer to form a requirements specification for the continues to perform as expected after the change. It is
modification. called regression testing because if a change causes a
new fault, then that is a regression.
The design stage of the maintenance process model
closely follows the design stage of the SDLC. There Acceptance testing involves the users testing the system
will also be a need to identify any new modules that following the change. Users will be able to confirm
are required, any modules that need to be replaced, whether issues have been addressed by the change or
any modules that need to be modified and any modules if there are any adverse effects on the system following
that need to be scrapped. Test plans will be created in the change. Simple modifications to a system may not
preparation for the testing stage. require this stage.
The implementation stage is very similar to the The delivery stage is similar to the implementation/
development stage of the SDLC but should not be installation stage of the SDLC where the existing
confused with the implementation/installation stage software will be upgraded to include the modification
of the SDLC. Implementation will involve following that has been developed. This will include any
the design to implement the changes to modules. A additional training that is required by users and updates
technique known as software re-engineering will be to the user documentation.
used. Software re-engineering can involve:
Maintenance management is an essential part of
• deciding whether the whole system needs re- maintenance in terms of documenting changes. It
engineering or just part of it involves ensuring that version control is in place and
is fully documented. Version control identifies each
• performing reverse engineering to obtain
update made to the software and will include technical
specifications of the existing software
documentation for that update. Without version
• restructuring the program (if required) control, software revisions become unmanageable and
• restructuring the data (if required) it is impossible to identify when changes were made
and what impact those changes may have had on the
• forward engineering to get the re-engineered software. This makes finding a bug in the system very
software through software engineering methods. difficult because there is no documentation to show the
Reverse-engineering involves analysing and changes which may have caused that bug.
understanding the existing system to produce a
system specification. This is required when original
specifications are unavailable. The process involves Question
examining the code in depth to generate a design. The 18 Give a situation when corrective maintenance
design is then used to generate a system specification. would be required.
Program restructuring could involve re-writing the
program in a different programming language or REFLECTION
restructuring the way modules are used within a
program. Program restructuring is often required to Discuss the types of software maintenance you
enable obsolete hardware to be decommissioned. have seen take place on mobile phones.
Throughout the implementation stage, modules that are
introduced or modified should be tested, including their
impact on other parts of the system. The impact on the
rest of the system of scrapping any modules should also
be tested.

367
 CAMBRIDGE INTERNATIONAL AS & A LEVEL IT: COURSEBOOK

Each prototype will build upon the previous one and

16.8 Prototyping include more functionality until a final product is built.
At each stage, only clearly understood requirements
A prototype is a ‘mock-up’ of a software solution in
are developed. Each prototype can be functional and if
a primitive form. It is used during the design stage to
required can be used by the client until the next iteration
demonstrate how a system will look and work. It is
of the prototype is ready. This means that the end users
usually focused on the user interface, rather than any
may request enhanced or new features that they discover
data structures. It is used so that the client can get a
they require as the prototypes are being developed,
feel for the new system before it is developed and can
features they wouldn’t have envisaged at the initial
provide feedback that can then be acted upon. The
requirements specification stage.
client is also able to compare the prototype against
the requirements specification. The client also has an
opportunity to explain their requirements more clearly Evolutionary prototyping
having seen the designer’s interpretation. Evolutionary prototyping follows a similar pattern
to incremental prototyping in that it is iterative in
nature. However, unlike incremental prototyping, there
KEY WORD is no requirements specification at the start of the
prototype: a ‘mock-up’ of a software solution in project, but instead there might be a goal or an aim.
a primitive form Both the analyst and developer begin the project by
brainstorming ideas. The developer will start working
on some of the best ideas so far while the analyst will
discuss with the customer what the problem is and what
Types of prototyping is needed to solve the problem.
After a few days, the analyst and developer will compare
Incremental prototyping notes. The developer will demonstrate how they have
This type of prototyping takes an iterative approach implemented ideas and the analyst will talk about what
in that requirements are specified, an initial prototype the customer has said. Following this discussion, the
is developed, the prototype is reviewed and then developer will continue with development focusing on
requirements are clarified and the prototype is improved the needs of the customer that are understood most
based on feedback. clearly, while the analyst will get feedback from the
customer and get more clarification on their needs.
Initial requirements This process will continue as the product evolves from
a goal to a usable piece of software. This evolutionary
approach is often used by start-ups or where new ideas
Initial prototype are being experimented with.

Throwaway/rapid prototyping
Feedback With throwaway prototyping, also known as rapid
prototyping, the prototype will never become part of the
final delivered software, but will be discarded. A loosely
Refine requirements working model is created following a short investigation,
with the aim being to get something tangible to the
client as soon as possible for feedback as to how well the
Refine prototype requirements are being met.

Final product

Figure 16.13: Iterative prototyping.

368
 16 System life cycle

Initial requirements Advantages Disadvantages

The end users will be When users see the
involved more in the prototype, they can
Rapid prototype process, giving them often get lots of new
more ownership of the ideas about features
solution and providing they would like to be
Client feedback valuable feedback. included, which can lead
to disappointment if
these features can’t be
Specify final requirements
funded. This is known as
‘feature creep’.
If the prototype is When users see what
Figure 16.14: Throwaway prototyping.
evolutionary, then users looks like a working
can get used to using interface with a
This enables the requirements to be fine-tuned early in parts of the system throwaway prototype,
the process, which is more cost-effective than trying to before having to use the they don’t realise how
make changes later when considerable work has been whole system, which will much more effort is
carried out. The main aspect to the prototype will be the reduce the need for bulk required to make it
user interface which the client will be able to test and training. into a working solution
experience. The interface will appear to work by being and may have false
simulated. It’s much cheaper to expectations as to the
make changes earlier in timescale.
the process than after
The advantages and real development has The iterative process of
taken place. feedback can sometimes
disadvantages of prototyping last too long if the user
is regularly wanting
The advantages and disadvantages of prototyping are
changes to be made to
shown in Table 16.9.
the latest prototype.
By listening to feedback The initial costs of
Advantages Disadvantages
from end users, developing a prototype
Problems can be Requirements analysis the developers will are high compared with
identified early during can be rushed, meaning have a much better traditional designs.
the process and that prototypes don’t understanding of what
modifications made reflect much of what the users are expecting
before it becomes very the end users were and so a better
costly to make changes. expecting. quality solution will be
Requirements can be With rapid prototyping, provided.
clarified and refined the prototype can
following feedback on become rushed and, Table 16.9: Advantages and disadvantages of prototyping.
the prototypes. when trying to develop
it into a working system,
it may have significant
design flaws or structural Question
errors that carry through 19 Compare and contrast evolutionary and throw-
to the end solution. away prototyping.

369
 CAMBRIDGE INTERNATIONAL AS & A LEVEL IT: COURSEBOOK

16.9 Methods of Development methodologies

Waterfall method
software development
Requirements
Types of development
Software development tends to fall into two main
categories which are incremental development and iterative Design
development. Both types of development can be followed
mutually exclusively or in co-existence with each other.
Implementation

KEY WORDS
Verification
incremental development: creating a system or
adding new functionality in small parts
iterative development: creating a system or Maintenance
adding new functionality in a repetitive cycle

Figure 16.15: Waterfall method.

Incremental development is about development in
phases. Part of the software is developed fully, including The waterfall method is an iterative development model.
improvements from feedback, before moving on to the The waterfall method involves gathering all the user
next part of the software. requirements at the beginning of the project. There will
Iterative development is about planned rework be considerable communication with the user at this
throughout a project. It allows for feedback to be given stage in order to elicit the requirements of the potential
by the customer and improvements to be made based on solution. When the requirements are defined, the process
that feedback. It usually involves building a bit of every runs ‘downhill’ like a waterfall.
part of a solution before seeking feedback and then During the design stage, the interface and the structure
revisiting the whole solution to make improvements. of the system will be designed. During implementation,
A typical analogy used to describe incremental and often referred to as development, the system will be
iterative development is that of an artist. A landscape developed, which often involves programming. The
artist following the incremental approach might start purpose of the verification phase is to ensure that the
by painting a picture of a house and perfect that picture project meets the customer’s requirements. The system
before moving on to painting something else. Then will then be used and during its use there may be
the artist may paint a tree and perfect that tree before problems that are discovered that need to be corrected
moving on to the next object. or other changes that need to be made. This is known as
maintenance.
A landscape artist following the iterative approach
would sketch an outline of the whole landscape. The As each stage starts, changes may need to be made to
artist might then start to add background colour to all the previous stage as a result of user feedback or lessons
parts of the landscape. The artist might then start to that have been learned during that stage. This is what
add details to all parts of the landscape. The artist will makes the model iterative.
keep revisiting the picture and changing it until they are The waterfall method relies upon the requirements being
happy with the final picture. clearly defined, which is an unrealistic expectation, so
it is fundamentally flawed. It was originally used in
manufacturing and then adopted into computing, but
with adaptions that included the need to revisit the
requirements.

370
 16 System life cycle

The system life cycle discussed in this chapter is based Agile

on the waterfall model and there are many variations in
The agile approach to software development is able to
existence.
respond to a customer’s changing requirements, even
The advantages and disadvantages of the waterfall late in the development life cycle. It is expected that
method are shown in Table 16.10. the customer’s requirements will evolve as the project
develops. The process can cope with change and harness
Advantages Disadvantages that change for the benefit of the customer.
Each stage is completed The customer only sees Following the agile approach, individuals and the
before moving onto the product at the end interaction between people is valued more highly
the next stage making of the project. than design processes and tools. Similarly, it is more
management of the important that working software is developed than
project more structured having comprehensive supporting documentation.
and controllable. Collaboration with the customer is expected to underpin
It’s a simple model to It’s hard to measure the whole project with contract negotiations taking
understand and use progress within each a less important role. While planning is necessary,
because each stage is stage because the flexibility is more important in the agile approach and so
distinctly separate from milestones are just the responding to change is essential. These are summarised
the other stages. beginning and end of in a manifesto for agile software development
each stage. as valuing:

It works well for projects It doesn’t work well for • individuals and interactions over
where the requirements complex projects where processes and tools
are clearly understood the requirements cover • working software over comprehensive
and are unlikely to a large variety of aspects documentation
change. and aren’t clearly
• customer collaboration over contract negotiation
understood by everyone
involved. • responding to change over following a plan.
The process followed Projects can take longer Unlike the waterfall model which has separate phases
and the resulting to deliver than other throughout the system lifecycle, the agile approach uses
software are well methods because of the iterations with each iteration including the planning,
documented, meaning emphasis on planning design, development and testing of part of the software.
new team members can and documentation. At the end of an iteration, a working solution for that
get up to speed very part of the software is ready for demonstration. Several
quickly. iterations are usually required before a product is ready
The client and project Client involvement is to be released or updated.
team work to a set limited to set times As an iteration includes designers, developers and
timescale and a set within the project which testers, they are expected to be located in the same place.
budget which removes can lead to requirements This ensures a collaborative approach to each iteration.
a lot of uncertainty from not being met to the Each team will also include a customer representative,
projects. client’s expectation. sometimes referred to as a product owner, who
The requirements are The model doesn’t represents the client and must be available to developers
clearly set from the accommodate changes throughout an iteration. Working closely together means
beginning of the project to requirements. that feedback is instantaneous and enables a flexible
and are used to measure approach to be taken to the design and development.
the project’s success There will often be a daily ‘scrum’, which is a briefing
when it is completed. session where each team member reports to the others
on their work so far and their plan for their next stage
Table 16.10: Advantages and disadvantages of the of development.
waterfall method.
One technique used in agile software development is
pair programming where two programmers work at the

371
 CAMBRIDGE INTERNATIONAL AS & A LEVEL IT: COURSEBOOK

same computer with one being the driver who writes the upon in future iterations. It’s important not to get the
code and the other being the observer who reviews each words iteration and iterative confused. Each iteration
line of code. The observer is expected to think about increments the existing functionality and each iteration
potential improvements that could be made and pre- is iterative in nature.
empt potential problems that might take place.
The advantages and disadvantages of agile software
Agile is both iterative and incremental. It’s incremental development are shown in Table 16.11.
because each iteration can be planned to be improved

Advantages Disadvantages
The customer gets to see completed parts of As requirements change, it’s difficult to know how
software quickly which enables them to adapt their much a project is going to cost and how long it will
requirements for other parts of the software. take.
The customer, designers, developers and testers are The project can easily go off track if requirements
constantly interacting with each other which reduces change too much.
delay.
If the business needs aren’t fully known at the start Experienced senior programmers are needed to be
of the project then they can evolve as the project able to make quick decisions during each iteration.
progresses.
There is unlimited access to the customer which There will be minimal documentation produced which
means their needs are more likely to be met. means new team members can take longer to get up
to speed with the project and there can be a large
learning curve when maintaining the software.
There is no complicated bureaucracy that delays Projects may seem to never have an end in sight.
decision making.
The customer doesn’t have a fixed budget or Not having a fixed budget or timescale creates a lot
timescale so customer needs can be met above of uncertainty for the client and is not a popular move
timescales and budgets. with senior members of an organisation.
Parts of the software can be deployed when they are The software, especially the user interface, can
ready so the customer sees the value of that software become disjointed because each iteration is worked
sooner. on separately.
Bugs and problems can be fixed quickly because the
designers, developers and testers for each iteration
are working closely together.

Table 16.11: Advantages and disadvantages of agile software development.

Rapid application development of the system. Less time is spent on planning and design
and more emphasis is put on the development phase.
Rapid application development (RAD) uses prototyping
to develop a system in a very short time frame, usually
less than six months. Instead of following a traditional KEY WORD
requirements gathering approach, requirements are
gathered through focus groups. Users are key players rapid application development (RAD): use of
in the prototyping stage and provide feedback for prototyping to develop a system in a very short
refinements. This type of user involvement is known as time frame
joint application development (JAD) because the user is
jointly involved with the developer in the development

372
 16 System life cycle

Strict deadlines are allocated throughout the can be created using drag and drop functionality. This
development of the system to ensure that the product is enables users to be involved in the actual design of the
developed and finished on time by allocating time boxes interface as part of the JAD approach and they can see
to the development of each requirement. This requires the interface taking shape in real time.
understanding from the user that, if requirements are
RAD is based on an incremental model in that each
too complex, then they must be simplified or removed
timebox will deliver specific functionality. However, it’s
from the project. The RAD approach will also try to
not necessary to complete a timebox before moving onto
reuse any modules of software that already exist and are
another one as timeboxes can be developed in parallel.
available, rather than always developing from scratch.
Software application frameworks can be used to develop The advantages and disadvantages of RAD are shown
the solution whereby a complex graphical user interface in Table 16.12.

Advantages Disadvantages
The high level of user involvement means that the end Requirements are not clearly specified from the outset
solution is more likely to be suitable for the end users, and so the final solution may not meet the entire
who will also have ownership of the solution. needs of the organisation.
Users are often not sure of what the requirements Users are required throughout the whole process and
of a system should be from the outset and so they also have their normal day jobs to do. This can
the evolutionary approach of RAD enables the lead to work overload or the need for temporary staff.
requirements to evolve.
As users are involved throughout the whole project, The structure of the system may be compromised,
it is quickly recognised when a requirement is leading to instability, as the focus is on the user
overambitious and therefore the requirement can be interface and getting a system developed rapidly.
simplified or removed at an early stage.
The strict deadlines ensure that the project will be The strict deadlines mean that some parts of the
completed on time and prevents ‘feature creep’. project could be rushed and not completed to a high
enough quality.
Prototyping of the interface with user involvement Existing software modules will not have been
means less time is spent on design and more on designed for the exact requirements of the system
development, leading to a shorter overall project. and so may not provide sufficient functionality.
Software application frameworks mean that a user Software application frameworks don’t produce
interface can be developed quickly and users can particularly efficient code and so the end solution will
even be involved in configuring the layouts of screens not run as quickly as if it had been developed from
and reports. scratch.
Users who are not involved in the JAD approach may
be disappointed that they didn’t have a say in the
process and the system may not meet their specific
needs.

Table 16.12: Advantages and disadvantages of RAD.

REFLECTION
Questions
20 Describe the differences between incremental and Discuss whether there is a perfect methodology
iterative methods of development. that would be right for every project.
21 Describe joint application development.

373
 CAMBRIDGE INTERNATIONAL AS & A LEVEL IT: COURSEBOOK

EXAM-STYLE QUESTIONS
Thornhill Estates runs several hotels. It would like a new software solution to manage room bookings, dinner
reservations and purchases across all its hotels. It has asked a software developer to produce the software for them.
The software developer will follow the system life cycle.
1 a State one purpose of analysis in the system life cycle. [1]
b Suggest four reasons why questionnaires would be appropriate for researching how bookings are
currently managed at the hotel. [4]
c State three other methods that could be used to research the current booking system. [3]
[Total 8]

The analyst will interview a group of users to create a requirements specification.

2 State the purpose of a requirements specification. [1]

The designer will create a design specification based on the requirements specification.
3 a Identify three factors that should be considered when designing a screen layout. [3]
b Using an example, show how a validation rule could be designed for the hotel booking system. [3]
c Apart from keyboards, mice and monitors, describe three external hardware components that will
be needed by the hotel system. [3]
[Total 9]

An evolutionary prototype approach will be used during the design and development of the software.
4 a Define the term ‘prototype’. [1]
b Justify the manager’s choice of an evolutionary approach. [4]
[Total 5]

Once the system has been developed, it will need to be tested.

5 a Describe two differences between white box and black box testing. [4]
b Explain one reason why beta testing might not be appropriate for the hotel system. [2]
c Explain why invalid test data is used. [2]
[Total 8]

The system will be installed in a pilot approach and user documentation will be provided to the hotel staff.
6 a Justify the choice of the pilot approach of installation for the hotel system. [4]
b Explain why the user documentation should include troubleshooting and glossary sections. [4]
c Suggest four reasons why the hotel system may require maintenance in the future. [4]
[Total 12]

374
 16 System life cycle

SUMMARY CHECKLIST
I can describe the stages in the system life cycle.
I can describe methods of research for a given situation.
I can understand the content and purpose of specifications.
I can construct diagrams to represent system processing and the flow of data through a system.
I can design data storage, input forms and output reports.
I can create a test plan and understand its purpose.
I can select appropriate test data.
I can describe the differences between alpha and beta testing.
I can describe the differences between white box and black box testing.
I can describe different methods of implementing a system.
I can explain the advantages and disadvantages of each implementation method for a given situation.
I can describe types of documentation and explain why each is needed.
I can describe the contents of documentation.
I can explain methods of evaluating a new system.
I can describe different types of maintenance and explain why each is needed.
I can explain how each type of maintenance is carried out.
I can explain different types of prototyping and explain why each is needed.
I can explain the advantages and disadvantages of each type of prototyping.
I can describe the stages and processes of different software development methodologies.
I can explain the advantages and disadvantages of different software development methodologies.

375