System Life Cycle

9626 A’LEVEL INFORMATION TECHNOLOGY

Learning Objectives

o Evaluate different methods of analysis

o Describe the contents of specifications
o Design a solution
o Evaluate suitable hardware and
software
o Explain and analyze different types of
testing
o Create a test plan
Learning Objectives

o Describe and analyze different

implementation methods
o Design, develop and explain the
need for documentation
o Evaluate a new system
o Explain different types of
maintenance
 Key Terms

Key Terms Explanation

Maintenance Changes made to a system after
its implementation
Requirements What a user needs a new system
specification to do
System specification The hardware and software
needed to run the system
Design specification Illustration of how the system
look, what the data structures
will be and how the system will
work
 System Development

System development is a set of activities

used to build an information system

System development activities

are grouped into phases, and
is called the system life cycle
System Life Cycle

o A systems analysis team is often brought

in to review an existing system and
suggest several improvements.

o The existing method used may be either a

manual paper-based system or a
computer-based operation that is no
longer regarded as adequate for the task.
System Life Cycle

Analysis

Installation Design

Documentatio
n

Testing Development
Phase 1: Analysis

o Involves finding out how the current

system works and what the requirements
of the client are for the new system.
o Variety of methods can be used to
research current systems and the
requirements of a new system.
The Content of Specifications

o There are 3 types of

specifications used within the life
cycle.
Requirements specifications
Design specification
System specification
 Requirements Specification

o is a contract between the developer and the

client.

o It specify exactly what the client needs the

system to do.

o Analyst will write the requirements specification

in consultation with client who will approve it.
 Requirements Specification
o Requirements specification include:
• Purpose of the system
• Main objectives
• Output (invoices, sales report)
• Input
• Validation and verification for input data
• Processes involves to convert from input to
output
• Data needed to be stored
• Performance measures
• Deadlines for each milestones
 System Specification

o Created by the system designer

o List all the software and hardware that is needed
for the new system.
o Identifies the minimum hardware that is needed for
the new system.
Design Specification

o To illustrate how the system will look, what

data structures will be used and how the
system will work.
o To give the user an idea of what the system will
look like before it is developed.
o User’s feedback can be incorporated into the
final designs.
o The developer will follow the designs.
Design Specification

o The design include:

▪ Flowcharts
▪ Data flow diagrams
▪ Data collection forms
▪ Screen layouts
▪ Validation routines
▪ Data dictionary
▪ House style (logos, colours, fonts, styles, sizes)
▪ Screen sizes
▪ Connectivity diagram to show links between screens
▪ Purpose of calculations.
The Content of Specifications
Requirements Design specification System
specification specification
Created by the Created by the Created by the
analyst designer designer
Contract between Shows what the Identifies the
developer and system will look software and
client like hardware needed to
run the system.

Identifies what the Describes how the Identifies the

system must do system should work minimum hardware
needed to run the
system.

Specifies the data

structure to be
used.
Review Questions

 Complete review questions number 1 and 2.

Phase 2: Design

o Diagrams can be used to describe how a

current system works .
o To demonstrate how a new system will work.
o Data flow diagram
o System Flowchart
o Data collection forms
o Screen layouts
o Validation routines
o Hardware and software for a new system.
Data Flow Diagram (DFD)

❑ DFD shows how data flows throughout

a system.
❑ It is not about the order of processes,
it is purely about the data flows.
Data Flow Diagram (DFD) Elements
Data Flow Diagram (DFD)

o DFD can exist at many levels.

o At level 0, or context level, the diagram
will show the whole system and the
data flows between the whole system
and any external entities, such as
customers, suppliers, members and
guests.
Rules for Drawing DFD’s

A minimum of one data flow

in and one data flow out of
a process

A datastore must be
connected to a process
(either in, out, or both)

An external entity must

be connected to a process
(either in, out, or both)

A single data flow must

only flow one way
DFD: Common Mistakes

• Process has no data flowing

into it, but has data flowing
out.

• Data store is hooked to

external entity. This means
external entity can read and
write to your data file
without auditing!!

• The data flow goes in two

directions at once. Two or
more arrows should be used
to show the flow to and
from each process.
NOTE:
DFDs can exist at many levels.
At level 0 (context level), the
DFD will show the whole system
any data flows between the
whole system and any external
entities such as customers,
suppliers, members, guests, etc.
Example 1
• A hotel accepts online booking for its hotel
rooms.
• Guests make a booking online and the
booking is received by the hotel.
• When the customer arrives, they are given
an electronic key which includes
encrypted data that will unlock the door
and allow purchases at the bar.
• At the end of the stay, the guest is
presented with a bill which must be paid
before leaving.
Context Diagram - Level 0

▪ The context diagram must fit in one

page.
▪ The system name in the context diagram
should be the name of the information
system.
 For example, Grading System, Order
Processing System, Registration System.
▪ The context level diagram gets the
number 0 (level zero).
 Tocreate a level-0 DFD, you should
identify the external entities and the
data flows between the external
entities and the system. It is
important to remember that it is the
data flow that is being represented
and not physical objects. Each data
flow will be in one direction only.
 Level-0 DFD
▪ This DFD shows the system as the hotel booking
system.
▪ It shows the guest as an external entity.
▪ It then shows the four items of data that flow
between the guest and the booking system.
Online booking

Encrypted Key card

Hotel Guest
Booking
System Bill

Payment
Level-1 DFD

▪ When the guest sends their online booking, the

room availability is checked and the booking
details are stored.
▪ When the guest arrives, their key card is
activated by retrieving the room access details.
▪ When the guest is ready to leave, a bill is
produces by retrieving the booking details and
any bar expenditure from the bar system.
▪ When payment is made, the booking details are
updated to confirm that payment has been
made.
 Guest

booking
enquiry
Online

Payment
Encrypted
key card
Bill

Check room Activate Expenditure

keycard Produce Bar
availability bill

Room access
Booking
details
details

Accept
payment
Booking
details

Payment
details
 TASK
 Create a level-0 DFD for the scenario below:
A car hire company accepts bookings of cars by telephone. A
credit card payment for the deposit is taken from the customer
at the time 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.
TASK

 Create a level-1 DFD for the car hire

company introduced in the previous
task. Assume the DFD will be for the
whole system.
 Exercises

▪ Answer the following questions:

▪ June 2017 9626/32, Question 4.
▪ June 2018, 9626/33, Question 5
 System Flowchart

 A system flowchart shows the processes that take

place within the system and the decisions that are
made. It focuses on the logic of the system, rather
than the data within the system. A flowchart can
represent a whole system or just part of a system.

 Flowchart symbols are linked together with arrows

showing flow direction.
System Flowchart Symbols
Flowchart Symbols
Flowchart Symbols
 Flowchart

• Flowchart: diagram showing the flow of

instructions in an algorithm.
– Flowchart symbols are linked together
with arrows showing flow direction.
Flowchart

 Example 1: Draw a flowchart to

determine a student’s final grade. The
final grade is calculated as the average of
three marks.
 Flowchart

 Flowchart for calculating

the average of three
numbers.
Flowchart (selection
Structure)
Flowchart (repetition structure)
System Flowchart
 System Flowchart
 Example 1:
System Flowchart
 System Flowchart
 Solution:
 Exercises

❖ Readthe example in textbook page 256.

❖ Complete the task in page 256.
 Exercise

❖ Download paper 9626/33 November

2018.
❖ Complete question 2.
 Data Collections Forms

• Documents that are used to collect data without

the use of a computer.
• Including:
• membership applications form
• Questionnaires
• Job applications

• The design of the form is important to get the

required data.
 Data Collections Forms
• The design of the form should follow these
principles:
• Avoid colour as the document may not be printed
in colour.
• Include instructions about how to complete the
form.
• Give clear instructions about where the form
should be returned.
• Identify which questions must be answered and
which are optional.
• Provide enough space for each answer
• Use tick boxes for multiple choice lists
 Data Collections Forms

• Make it clear how many options are allowed to

be chosen from a multiple choice list
• Ensure all fonts are consistently used
• Avoid cluttering the form with too much
information or too many questions
• Ensure the font style and size are legible
• If the respondent needs to complete a scale (1-
10), then explain what scale represents.
 TASK

• complete task page 268.

 Screen layouts

• A screen can be used to ask the user for

data to be input or to display information
to the user or a mixture of both.
• The principles of design for screen layouts:
• Use colour appropriately.
• Ensure all fonts are used with consistency.
• Avoid using too much information.
• Ensure the font style and size are legible
(clear)
Screen layouts

• If the screen requires user input:

• Include instructions about how to complete the
form
• Identify which questions must be answered and
which are optional
• Provide enough space for each answer
• Use tick boxes for multiple choice lists that can
have more than one response
• Use drop-down boxes or radio button for
multiple choice lists that can only have one
response.
Screen example
Screen layouts

• When designing a screen, it is only

necessary to indicate where questions
and responses will go, the type of
response options and the styles to use.
• The layout of any information should also
be indicated.
• The developer will then follow the
design.
Screen Design
 VALIDATION ROUTINES

• Validation rules should be used wherever possible

and be appropriate in order to reduce the number
of possible input errors.
• They only need to be used for input data so any
calculations or output data do not require
validating.
• 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
• Error message that should appear if the data input is
invalid.
 TASK

 Complete the task page 269.

 Validation Routines
Input Validation Validation rule Error message
data type
Surname Presence Surname must be Please enter a surname
entered
Date of Range Date of birth Applicant must be at
birth must be at least least 18 years old
18 years earlier
than today
Applicatio Type Must be a whole The application number
n number number must contain only
numbers
Telephone Length Must be between Telephone number
3 and 15 digits must be between 3 and
15 digits
Product Format XX9999XX9 The product code must
code be in the format
XX9999XX9
Where X is a letter
 Data Dictionary
• This is a document or file that describes the structure of the data held
within the database.
• It is known as metadata (data about data).
• It will include the following items.
• Data about fields:
• Field names to identify each field
• Data types such as text, integer, date/time
• Field size, such as the length of a text field or the maximum value of
a numeric field
• Format of fields
• Default values which are values a field is set to be initially when a
new record is created
• Primary keys, compound keys and foreign keys
• Indexed fields which improves search times
• Validation rules that restrict data entry for that field.
 Data Dictionary

• Complete task 1 page 270.

Data Dictionary
• Data about tables:
• The primary key of the table
• What sort order to use when displaying data
• Relationships to other tables
• Total number of records
• Validation rules that apply based on multiple
fields within the table
• Permissions and security as to which users can
access the table.
HARDWARE AND SOFTWARE FOR A
NEW SYSTEM
• the designer will need to decide what
hardware and software is required.
• The designer need to determine the
minimum hardware and software
requirements and then find out if the
hardware and software already exists and
can be used.
 Task

• Complete task 2 on page 170.

 DEVELOPMENT AND TESTING
• Often referred to as the implementation
stage where the design is implemented.
• Type of test:
• Alpha testing and beta testing
• Black box testing and white box testing
TEST DATA
• Test data: When a system has been developed
it needs to be tested. Data has to be created to
be used for testing the system. This is known as
test data.
• There is need to be enough test data generated
so that the system is able to cope under the
pressure of large amounts of data in everyday
use. There will also be need of specific types of
data to test different scenarios in the software.
 TEST DATA
Type of test Description
data
Normal (valid Data that will be accepted by the validation
data) rule.
Abnormal(Inv Data that will not be accepted by the validation
alid or rule.
erroneous
data)
Extreme valid Data that will only just be accepted by the
(extreme validation rule because it is within the limit of
data) acceptability.
Extreme Data that will not be accepted by the validation
invalid rule because it is just beyond the limit of
acceptability.
 TEST DATA

• Select test data to test the input of

numbers in the range 2500 to 5000.
 ALPHA TESTING

• This is carried out by the developers or

a specialized team of testers before
system is delivered to the user.
• This usually takes place close to the
end of the development stage when the
application is nearly ready for the user.
 ALPHA TESTING

• It may take a long time because each

time an error is found, testing has to
be repeated.
• when the error has been corrected and
there may be knock-on effects to other
parts of the system.
 BETA TESTING
• This is used when software is being made
available to a large number of customers.
• It involves using real customers who have been
selected to test an early release of the
application.
• Only takes place after alpha testing has been
completed.
• Alpha testing is planned and structured using
test data to follow all pathway through the
software.
 BETA TESTING

• Beta testing involves customers using the

software in real world environment using real
data.
• As bugs are found within a beta version, new
beta versions will be released for further
testing before a final version is released for
sale.
 BLACK BOX TESTING AND WHITE BOX
TESTING
• Black box testing involves selecting input data and
checking that the expected output data matches the
actual output data, with no knowledge or
understanding of what happens inside the black box
(the whole or part of the system is the black box). The
functionalities of software applications are tested
without having knowledge of coding or the way the
system works.
• White box testing: The internal structure, design and
coding of software are tested to verify flow of input-
output and to improve design, usability and security. In
white box testing, code is visible to testers.
 BLACK BOX TESTING AND WHITE BOX
TESTING
• White box: usually involves small program
modules and is carried out by the software
developers who coded the programs.
• Black box: It usually involves testing the whole
system or user testing.
• Black box: Carried out by specialist tester or by
intended users.
• No knowledge of programming or the way the
system works is required.
• It focused on ensuring the requirements
specification has been met.
THE IMPORTANCE OF TESTING AND HAVING A
TEST PLAN
• Testing is necessary:
• to find error and rectified it.
• To ensure the system is error free and work reliably
and behave as expected.
• Test plan :
• Can help to minimize the number of errors by ensuring
that all pathways through a system and types of data
have been tested.
• Include different types of test data so the inputs are
tested to their limits.
• It cover all the user’s requirements and ensure that
they are tested.
 TEST PLAN
• Will identify:
• all tests that are needed for every input, every button, every
link, every report and screen and all other elements of a system.
• what is being tested,
• the type of test,
• the input data that should be used to test,
• the expected result of the test and
• space to record the actual result.
• Each test will be numbered.
• Each input for a calculation will need to be identified and an
expected result expected.
• The test plan will include different types of test data such normal,
abnormal and extreme data
TEST PLAN

• Refer to example page 273 and 274.

 Exercise

• 9626/33 Paper 3 October/November

2017
• Paper 3 examination from 2020
SPECIMEN PAPER
 INSTALLATION

• There are 4 different methods of installing

(implementing) a new system known as the 4Ps:
• Parallel
• Plunge (direct)
• Phased
• pilot
Parallel implementation

• Old and new systems are run at the same

time until the organization is confident
that the new system is running
satisfactorily.
• Data will need to be duplicated from the
old system to the new system.
• low risk but can be expensive.
Parallel Implementation

Advantages Disadvantages
• Less risky – because if the • Duplication of data input
new system fails the means additional staffing
organization can continue to costs.
run using the old system. • Require more space.

• The accuracy of the new

system can be tested against • Data may be input into two
the old system and errors systems, meaning that the
can be fixed. data may not accurate.
Plunge (Direct Changeover)
Approach
• A date is chosen for the old system to stop
running and the new system to start
running. The old and the new systems do
not run at the same time.
• Data will need to be transferred from the
old system to the new system before the
new system can be used.
Plunge (Direct Changeover)
approach
Advantages Disadvantages
• Cheap to implement • Risky because any errors could
because there is no lead to the system failing.
duplication of work.
• All the training will need to
• Data is consistent because be done in advance and some
only used in one system at a users may forget how to use
time. the new system.

• There is no need for the new

system to be compatible with
the old system.
Phased Implementation

• Part of the new system will be introduced one at a

time.
• Used when there is a large system with lots of
functionality that can easily be separated into sections.
• The old system will run until a date that has been
agreed.
• Later, part of the old system will be retired and part of
the new system will start running.
• This will continue until the complete new system is
fully running.
• Expensive but one of the least risky approaches.
Phased Implementation

Advantages Disadvantages
• Less risky: if there is error it • Delays can occur waiting for
will only affect the part of each phase to be running
the system that has changed successfully before the next
over rather than the whole phase can start.
system. • Since users use two different
systems, it could lead to data
• End users can be trained how being updated in the wrong
to use each phase of the new system.
system and spend time using • Both old and new system
that phase before being need to be compatible
trained in the next phase. with each other in order for
data to be used across both
systems.
Pilot Implementation

• A part of the organization starts to use the

new system while the rest continue to use
the old system.
• The new system is effectively being beta
tested by the pilot group.
• Later, this pilot group can deliver training to
the rest of the organization when system
goes fully live.
• less expensive than the parallel approach.
Pilot Implementation

Advantages Disadvantages
• If there are any errors, it will • Slower method because the
only affect the pilot group. rest of the organization has to
wait until the pilot has been
• Any errors found by the pilot completed satisfactorily.
group can be fixed before the
system is installed for all • Users in pilot may not be
users. happy with the new system
while it may still have some
• The pilot can train other errors in it.
users on how to use the
system because they will have • Both the old and new system
experienced using it for real. need to be compatible with
each other.
 Implementation method

• The most suitable changeover method will

always be dependent upon the individual
circumstances surrounding of a new system.
• Factors to consider:
• How critical the system is to the running of the
organization.
• Cost.
• Number of users in the organization.
• The size of the new system.
Exercise

• Answer questions 11, 12 and 13 (page 276).

 Documentation

• There are 2 types of documentation:

• Technical documentation
• User documentation
 Technical Documentation

• The overview structure of the system on how it was

put together and how it works.
• It includes:
• Data dictionary
• Programming code or macros
• Validation rules
• Purpose of the calculation
• All button and links, the locations and functions
• Files used by the system
Technical Documentation

• It will also include:

• Flow charts, Entity-Relationship Diagrams,

screen connectivity diagrams
• Installation guide
• Results of testing
• Backup routines to show where files are stored
and how to restore from a backup
• Security settings to users access and
permissions
• Software and hardware requirements
 User Documentation
• This is a user guide giving instructions to the
user.
• It can be in electronic or printed format.
• A printed user guide should have:
• Front cover (name of the system)
• Header /footer with page numbers
• Contents page.
• Page numbers and an electronic version should have hyperlinks to
those pages.
• Introduction (purpose)
 User Documentation
• A user guide should have:
• Software and hardware requirements
• Instructions on how to use the system with
screenshots of the system or photographs of
hardware, arrows to point to parts of the
system.
• Glossary showing an alphabetical list of technical
terms used in the user guide and definition of
each.
• Troubleshooting (refer to example page 265)
• Index (with page number)
 The importance of technical and user
documentation
• Technical documentation:
• This 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.
• Maybe the person carrying out the future
maintenance is not part of the original
development team.
• Even if it the same person from the
development team can also refer to the
technical documentation.
The importance of technical and user
documentation
• User documentation:
• This is required so that users can learn how
to use the new system or look up how
certain features are supposed to work.
• The troubleshooting section is important
for user to understand what has caused an
error to occur and what they need to do in
order to stop the error from occurring.
 Exercise

• Answer questions 14,15 and 16 on page

277.
Evaluation and maintenance
Evaluation
• When a system has been developed and installed, the whole
process will be evaluated.
• Evaluation is also known as a review.
• It will consider how the project team and end users worked
together so that lessons can be learned for future projects.
• Users will be given questionnaires to find out what they
think of the new system and how they feel it is improving
their workflow or not.
• It will check to see if the new system is living up to its
expectations by giving selected users specific tasks which is
observed. Users are interviewed about their interactions
with the system.
• The most important question to be asked is whether the new
system meets the user requirements.
Evaluation and maintenance
Maintenance
• Maintenance takes place after a new system has been
delivered to the customer and it is in use.
• There are four reasons why maintenance might be
required which are:
• Perfective maintenance
• Adaptive maintenance
• Preventative maintenance
• Corrective maintenance
 Perfective maintenance
 The purpose is to improve the system
 There may not be anything wrong with the system but there
may be ideas on how to make the system perform better or
do additional tasks
 Improvements might be as a result of new technology that
has become available
 If a system is used for several years without improvements
it may become outdated.
 Adaptive maintenance
 The system needs adapt to changes. There could be changes
to internal procedures within the organizations or changes
the organization has no control e.g. New government
legislation or law is introduced which the system has to
adapt or comply.
 It is necessary to adapt to changes so that the system
continues to work effectively and produce correct outputs.
 There may be need to adapt to new technology such a new
OS or web browser.
 Preventative maintenance
 This is required to prevent problems arising within the system.
This can apply to hardware and software.
 Hardware should be cleaned regularly to prevent dusts from
blocking fans.
 Regular scans of storage media should be carried out to ensure
they are in good working condition and to prevent virus infection
 Heat should be monitored in the system to detect abnormalities
and prevent hardware failure
 Performance should be monitored to ensure processor, memory
and storage are working efficiently.
 Regular preventative maintenance helps to avoid system
downtime.
 Corrective maintenance
 This is carried out to correct errors or bugs found in the system.
This can be done by the original developer or different persons.
 These errors need to be corrected so that the system can run
efficiently and accurately and produce the desired results.
 Bugs can cause problems by making the system slow or crashing
the system which can be frustrating to users and reduce
productivity.
 It may also involve the replacement or repair of a hardware after it
fails
 EXERCISE

 Answer questions 17 and 18 on page 279

Methods of Software Development
 Methods of Software Development
 Incremental development
 Iterative development
 Waterfall model
 Agile model
Incremental Development
 The Incremental development is a method of software
development where the model is designed, implemented and
tested incrementally (a little functionality is added each
time) until the product is finished. It involves both
development and maintenance. The product is defined as
finished when it satisfies all of its requirements.
 The requirements are divided into multiple standalone
modules of the software development cycle. Each module
goes through the requirements, design, implementation and
testing phases. Every subsequent release of the module adds
function to the previous release. The process continues until
the complete system achieved.
Incremental Development

When to use the Incremental model:

•This model can be used when the requirements of the complete
system are clearly defined and understood.
•Major requirements must be defined; however, some details can
evolve with time.
Incremental Development
 Advantages of Incremental model:
• Generates working software quickly and early during the software
life cycle.
• This model is more flexible – less costly to change scope and
requirements.
• It is easier to test and debug during a smaller iteration.
• In this model customer can respond to each build.
• Lowers initial delivery cost.
• Easier to manage risk because risky pieces are identified and
handled during it’s iteration.

 Disadvantages of Incremental model:

• Needs good planning and design.
• Needs a clear and complete definition of the whole system before it
can be broken down and built incrementally.
• Total cost is higher than waterfall model.
 Iterative Development
 In the Iterative model, iterative process starts with a simple implementation of a
small set of the software requirements and iteratively enhances the evolving
versions until the complete system is implemented and ready to be deployed.
 An iterative life cycle model does not attempt to start with a full specification of
requirements. Instead, development begins by specifying and implementing just
part of the software, which is then reviewed to identify further requirements.
This process is then repeated, producing a new version of the software at the
end of each iteration of the model.
 Every release of the Iterative Model finishes in an exact and fixed period that is
called iteration.
 The Iterative Model allows the accessing earlier phases, in which the variations
made respectively. The final output of the project renewed at the end of the
Software Development Life Cycle (SDLC) process.
Iterative Development
 Advantages of Iterative Model
• This model produces a working software much quickly and early during the SDLC.
• This model is very flexible. As new functionality can be added to it at any time of
development.
• This model is considerably cheap as it is less costly to change requirements as
compared to the other process models.
• The end-user or the stakeholders can give their feedback quickly, which can then be
implemented into the system.
• The errors and bugs in the system can be identified early.
• Takes smaller development teams as compared to other process models.

• Disadvantages of Iterative Model

• It is not a good choice for small projects.
• More resource-intensive than waterfall model.
• The need for more intensive project management may be required
• Highly skilled talent is required for risk analysis
 WATERFALL MODEL
 The Waterfall Model is the earliest SDLC approach that was used for
software development. It is very simple to understand and use. In a
waterfall model, each phase must be completed before the next phase
can begin and there is no overlapping in the phases.
 The waterfall Model illustrates the software development process in a
linear sequential flow. This means that any phase in the development
process begins only if the previous phase is complete. In this waterfall
model, the phases do not overlap.
Waterfall Method
 The waterfall method involves
gathering all the user requirements
at the beginning of the project.
 There will be considerable
communication with the user at this
stage in order to elicit the
requirements of the potential
solution.
 When the requirements are defined,
the process runs 'downhill’ like a
waterfall.
 During the design stage, the interface and the structure of the
system will be designed. During implementation, often referred
to as development, the system will be developed, which often
involves programming.
Waterfall Method
 The purpose of the verification
phase is to ensure that the project
meets the customer’s requirements.
The system will then be used and
during its use there may be
problems that are discovered that
need to be corrected or other
changes that need to be made.
This is known as maintenance.
 The waterfall method relies upon the requirements being 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.
 The system life cycle, discussed in Chapter 15, is based on the
waterfall model and there are many variations in existence.
 WATERFALL MODEL
Advantages
 Suitable for smaller projects where requirements are very well
understood.
 Simple and easy to understand and use.
 Before the next phase of development, each phase must be
completed
Disadvantages
 It is not desirable for complex project where requirement changes
frequently.
 No working software is produced until late during the life cycle.
 Lack of user involvement.
 Cannot accommodate changing requirements.
 Agile Model
 Agile model is a combination of iterative and incremental process models
with focus on process adaptability and customer satisfaction by rapid
delivery of working software product. Agile Methods break the product
into small incremental builds. These builds are provided in iterations.
Each iteration typically lasts from about one to three weeks.
 Software is developed in incremental, rapid cycles. In Agile model, it
might be that some analysis is done and some parts of the system is
designed and implemented while other parts are still being analysed
and then, implementation and testing may be intermixed. The
developer may then go back to develop another aspect of the system.
Throughout the process, feedback will be obtained from the user. It is
an iterative process in which changes made are incremental as the next
part of the system is built. The system is developed with user
participation and in line with what users want.
Agile Model
14.7 – Prototyping
Key Terms
Prototype: a ‘mock-up’ of a software or manufactured solution
RAD: rapid application development
Prototype
 A prototype is a working model of a software solution or information system
usually built for demonstration purposes or as part of the development
process. It is used during the design stage to demonstrate how a system will
look and work. It is usually focused on the user interface, rather than any
data structures.
 It is used so that the client can get a feel for the new system before it is
developed and can provide feedback that can then be acted upon. The client
is also able to compare
the prototype against the
requirements specification.
 The client also has an opportunity
to explain their requirements more
clearly having seen the designer’s
14.7 – Prototyping - Types
Evolutionary/incremental prototyping Initial Requirements
 This type of prototyping takes an iterative approach in
that requirements are specified, an initial prototype is
developed, the prototype is reviewed and then Initial Prototype
requirements are clarified and the prototype is
improved based on feedback.
 Each prototype will be build upon the previous one Feedback
and include more functionality until a final product is
built. At each stage, only clearly understood
requirements are developed. Refine Requirements
 Each prototype can be functional and if required can
be used by the client until the next evolution of the
prototype is ready. Refine Prototype
 This means that the end users may request enhanced
or new features that they discover they require as the
prototypes are being developed, features they Final Product
wouldn’t have envisaged at the initial requirements ▲ Figure 14.15 - Iterative
specification stage. prototyping.
14.7 – Prototyping - Types
Throwaway/rapid prototyping Initial Requirements
 With throwaway prototyping, also known as rapid
prototyping, the prototype will never become
Rapid Prototype
part of the final delivered software, but will be
discarded.
 A loosely working model is created following a Client Feedback
short investigation, with the aim being to get
something tangible to the client as soon as Specify Final
possible for feedback as to how well the Requirements
requirements are being met.
▲ Figure 14.16 -
 This enables the requirements to be fine-tuned Throwaway prototyping.
early in the process, which is more cost-effective
than trying to make changes later when
considerable work has been carried out.
 The main aspect to the prototype will be the
user interface which the client will be able to
test and experience. The interface will appear to
work by being simulated.
14.7 – Prototyping - Types
The advantages and disadvantages of prototyping
 These are shown in Table 14.01.

Advantages Disadvantages
Problems can be identified early Requirements analysis can be rushed,
during the process and modifications meaning that prototypes don’t reflect much
made before it becomes very costly of what the end users were expecting.
to make changes.
Requirements can be clarified and With rapid prototyping, the prototype can
refined following feedback on the become rushed and, when trying to develop
prototypes. it into a working system, it may have
significant design flaws or structural errors
that carry through to the end solution.
The end users will be involved more When users see the prototype, they can
in the process, giving them more often get lots of new ideas about features
ownership of the solution and they would like to be included, which can
providing valuable feedback. lead to disappointment if these features can’t
be funded. This is known as ‘feature creep’.
14.7 – Prototyping - Types
Advantages Disadvantages
If the prototype is evolutionary, then When users see what looks like a
users can get used to using parts of working interface with a throwaway
the system before having to use the prototype, they don’t realize how much
whole system, which will reduce the more effort is required to make it into a
need for bulk training. working solution and may have false
It’s much cheaper to make changes expectations as to the timescale.
earlier in the process than after real The iterative process of feedback can
development has taken place. sometimes last too long if the user is
regularly wanting changes to be made
to the latest prototype.
By listening to feedback from end The initial costs of developing a
users, the developers will have a prototype are high compared with
much better understanding of what the traditional designs.
users are expecting and so a better
quality solution will be provided.

▲ Table 14.01 - Advantages and disadvantages of prototyping.

14.7 – Prototyping - Types
METHODS OF SOFTWARE DEVELOPMENT
Rapid application development
 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 requirements gathering
approach, requirements are gathered through focus groups. Users
are key players in the prototyping stage and provide feedback for
refinements.
 This type of user involvement is known as joint application
development (JAD) because the user is jointly involved with the
developer in the development
of the system.
 Less time is spent on planning
and design and more emphasis
is put on the development phase.
14.7 – Prototyping - Types
Methods of software development
Rapid application development
 Strict deadlines are allocated throughout the
development of the system to ensure that the
product is developed and finished on time by
allocating time boxes to the development of each
requirement.
 This requires understanding from the user that, if
requirements are too complex, then they must be
simplified or removed from the project. The RAD
approach will also try to reuse any modules of
software that already exist and are available, rather
than always developing from scratch.
 Software application frameworks can be used to develop the solution
whereby a complex graphical user interface can be created using drag
and drop functionality. This enables users to be involved in the actual
design of the interface as part of the JAD approach and they can see
the interface taking shape in real time.
14.7 – Prototyping - Types
The advantages and disadvantages of RAD
 The advantages and disadvantages of RAD are shown in Table 14.02.

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

▪Prototyping is a ‘mock-up’ of a software solution in a primitive form and can be

evolutionary/incremental or throwaway/rapid.
▪Rapid application development uses prototyping to develop a system in a very
short time frame.
▪The waterfall method of development identifies user requirements at the start of
the project, similar to the system life cycle.
▪An evolutionary prototype approach will be used during the design and
development of the software.