Computer Science

AS 12 Software
Development
Introduction
• AS 12.1 – Development Lifecycles

• AS 12.2 – Program Design

• AS 12.3 – Testing and Maintenance

AS 12.1 – Development Lifecycles
• Show understanding of the purpose of a development life cycle
• Show understanding of the need for different development life cycles
depending on the program being developed
• Describe the principles, benefits and drawbacks of each type of life
cycle
• Show understanding of the analysis, design, coding, testing and
maintenance stages in the program development life cycle

• Including: waterfall, iterative, rapid application development (RAD)

Software Development Challenge
(idealised)
User Requirements Technical Solution User System
Software Development Challenge
User Requirements Technical Solution User System

Lack of understanding
Conflict Delivery problems
Technology limitations
Lack of clarity Poor handover
Availability of
Other systems Change
professionals
Other processes Budget
Change
Lack of consultation Time
Time constraints
Fantasy requirements Quality
Budget
Change Lack of engagement
Quality
What is a Software Development
Methodology?
• A set of processes used in developing software
• Describes the lifecycle of this development, normally breaking the lifecycle
down into phases
• Specifies certain 'ceremonies' – activities that must be performed such as
reviews and meetings
• Specifies certain artefacts – things that must be produced in addition to the
running software itself
There are many methodologies in use – so far, no clear 'winner' has emerged,
and selecting the methodology most likely to succeed for a given project
depends on a number of factors (and there are many factors other than
methodology)
The Waterfall Methodology*
• Classical engineering approach
• Separate phase for each major activity
• As one phase completes, the next one starts (sequential)
• Heavily dependent on high quality in the early stages (requirements
gathering and analysis, design)
• Change is viewed as expensive and undesirable
• Changes later in the project are much worse than changes at the outset
• High levels of ceremony (major reviews and sign-off commitments)
• Testing is a separate discipline focused on sign-off as much as quality
 The Waterfall Methodology
Requirements sign-off / contractual agreement
Requirements
Gathering and Analysis
Agreement / contractual milestone
System Design

Agreement / contractual milestone

System Implementation

We should note that all of these activities are required, Acceptance / contractual agreement
System Testing and
regardless of methodology. We always need to gather Evaluation
and analyse requirements, do design work, write
software, test it, and handover to full operation.
Each methodology has a different 'take' on how these Maintenance
should be done, and their relative values
Iterative Life Cycles
The Agile Methodology
• More novel engineering approach
• Phases replaced by iterations (sprints in the scrum model)
• Each iteration is similar to a mini project, with the intention of
generating a tangible output which contributes to the final delivery
• Heavily dependent on involvement of the user throughout the project
• Change is viewed as unavoidable and, in some cases, desirable
• Changes are expected throughout each iteration
• Low levels of formal ceremony (but frequent gatherings and discussions)
There are various versions of Agile – Scrum, Kanban, Lean, …
Agile Methodology
Manifesto for Agile Software
Development
Individuals and interactions 1 Processes and tools
2

Working software 1 Comprehensive documentation 2

Customer collaboration 1 Contract negotiation 2

Responding to change 1 Following a plan 2

Scrum – Agile Project Management
Method
Extreme Programming (XP)
• XP is based on the Agile Methodology
• The name comes from the approach of taking common good practices to an 'extreme'
level:
• Agile's iterations become very short development cycles, with code released at the end of each
cycle
• Code reviews become an integral, continuous part of development though "pair programming"
• Unit testing is good, so do it for every piece of code
• Testing is good, so use it to drive design
• The focus of XP is on code quality; code is the only truly important product of the
SDLC (in the view of XP)
• Write code to investigate problems (prototype)
• Write code to communicate thoughts
• As well as writing code to contribute to the final product
Rapid Application Development
(RAD)
• Focuses on risk reduction through prototyping
• Users find it easier to review and respond to prototypes than to create
detailed requirements specifications
• Prototypes can be used to find and fix problems early in the lifecycle
• Prototypes can evolve, in some cases into final products
• Users involved throughout the development
• Iterative for the design and construction phases (which can run in
parallel)
• Risk of too much focus on user interface vs functionality
 User Design

Requirements
"Cutover"
Planning

Construction
Comparison Overview
• Waterfall - driven by plan
• Gathering and analysis of requirements at the beginning of a project leads to
a proposed solution which is then built, tested and delivered
• Agile/iterative - driven by value
• Recognises that software systems can change the processes they are designed
to implement
• Iterations build-in the ability to change the scope and nature of the
development (and therefore the requirements develop through the project)
Software Development Methodologies
Compared 1 Waterfall RAD Agile XP
Sequential or Phases are mainly Iterative Iterative Iterative
iterative sequential, some tasks
can happen in parallel
When are In the early stages Throughout Throughout Throughout
requirements
gathered?
When are Mainly in the early stages Throughout Throughout Throughout
users involved? and at acceptance
Main focus Delivering to an agreed Delivering what the user Delivering what Delivering high quality
specification actually wants, quickly the user actually software
wants
Attitude to Change should be Change is unavoidable, Change is Change is unavoidable
changes avoided, particularly in prototypes are designed unavoidable, and and must be
the later stages to identify changes may be desirable embraced to deliver
high quality software
Attitude to Testing is a separate Testing should be part of Testing should be Testing should drive
testing discipline from each iteration part of each development
development and iteration
happens mainly after
development
Software Development Methodologies
Compared 2
Low criticality
Small team of experienced developers
Agile-style SDLC
Requirements subject to change

Increasing focus on system and plan

Culture comfortable with change

Increasing focus on users and value

High criticality
Large team of mixed developers
Waterfall-style SDLC
Requirements that should not change
Culture that prefers order/predictability

Extreme criticality
Team of experienced developers
Formal method
Limited requirements, unlikely to change
Extreme quality
Example Questions
• Discuss/Describe/Justify area of questioning
• Very under-represented in previous papers
• There are no whole questions in the 2021, 2022, or sample papers
Q1
a) The development life cycle of a program involves the following
stages: analysis, design, coding, testing and maintenance.
Summarise what each stage consists of.
[10]

b) Describe one distinguishing principle of each of the following types

of development life cycle: waterfall, iterative development, rapid
application development (RAD).
[3]
Q1(a) Mark Scheme
• 1 mark for each point (max 2 marks per stage; max 10 marks total)
• Analysis: investigate current system; define the problem; draw up a
requirement specification; decide on bottom-up or top-down method of
solution
• Design: design identifier table; design data structures; plan algorithms /
flowcharts / pseudocode
• Coding: choose high-level language; convert pseudocode to program code;
correct syntax errors
• Testing: design test strategy/test plan; design test data; test each module
(black-box / white-box / dry-run); test the complete system (integration /
alpha / beta / acceptance)
• Maintenance: fixing program/errors (corrective); change system settings to
enhance performance (perfective); add more functionality (adaptive)
Q1(b) Mark Scheme
• 1 mark for each point (max 1 mark per type; max 3 marks total)
• Waterfall
• set order of stages
• stages are completed one at a time
• may need to go back to previous stage
• Iterative
• development starts with implementing a subset of the requirements
• reviews are repeated until the system is complete
• RAD
• uses prototyping
• modules are developed in parallel
• changes can be made during the development process
AS 12.2 – Program Design
• Use a structure chart to decompose a problem into sub-tasks and
express the parameters passed between the various modules,
procedures, functions which are part of the algorithm design
• Describe the purpose of a structure chart
• Construct a structure chart for a given problem
• Derive equivalent pseudocode from a structure chart
• Show understanding of the purpose of state-transition diagrams to
document an algorithm
Program Design – Structure Charts
• Main purpose is to show a functional breakdown of a program
• Each 'level' in the diagram is a refinement of the level above
• Structure charts may also feature the parameters passed between modules
• Structure charts may be further annotated to show selection (decisions)
and iteration (loops)
• Note that there is limited formality to these diagrams; for example it is
usually the case that there is some 'flow' from left to right, but there is no
rule for this
• There is, however, a clear convention that modules 'higher' in the chart call
modules 'lower' in the chart
Basic Structure Diagram

Averages Level 0

Interface

INPUT Calculate OUTPUT

Level 1
numbers average average
 Basic Structure Diagram
Number Guessing
Level 0
Game

Interface

Generate Secret INPUT OUTPUT

Level 1
Number Guess Message

Interface

OUTPUT OUTPUT
Level 2
congratulations commiserations
Adding Parameters
• Arrows show direction that the parameter(s) are passed
• A filled in circle indicates a Boolean value
• An empty circle indicates any data type other than Boolean
• A double-ended arrow means that the parameter value is modified in
the module/procedure
Structure Diagram with Parameters

Averages Level 0

rs Aver

Numbers
be Interface

Average
N u m age

INPUT Calculate OUTPUT

Level 1
numbers average average
 Structure Diagram with Parameters
Number Guessing
Level 0
Game
g ue
ss
er secr
etN u mb etN
u mb

guess
s e cr er Interface

Generate Secret INPUT OUTPUT

Level 1
Number Guess Message

Interface

OUTPUT OUTPUT
Level 2
congratulations commiserations
Double-ended Parameter
Number Guessing
Game

numberOfGuesses
guess
The double-ended line for numberOfGuesses
indicates that the value is passed down to "INPUT
Guess" which modifies the value and passes this
new value back up to "Number Guessing Game"

INPUT
Guess
Adding Selection
• Selection may be shown on a structure chart by including the
flowchart 'diamond'
• Ideally, you should clearly show the result of the decision as a
Boolean yes/no outcome leading to different modules…
• … however, this may not always be easy and some text book examples
take a 'relaxed' approach requiring the reader to interpret the intent
 Structure Diagram with Decision
Number Guessing
Game

Generate Secret INPUT OUTPUT

Number Guess Message

Guess =
Secret
Yes Number No

OUTPUT OUTPUT
congratulations commiserations
Adding Iteration
• Iteration (looping) may be shown on a structure chart by including a
semi-circular arrow covering one or more submodules
• You should clearly show the iteration condition next to this arrow
 Structure Diagram with Iteration
Number Guessing
Game
UNTIL Guess = SecretNumber

Generate Secret INPUT OUTPUT

Number Guess Message

Guess =
Secret
Yes Number No

OUTPUT OUTPUT
congratulations commiserations
 Number Guessing Game

gue
ss
ber secr
c retNum et Num

guess
se ber

INPUT OUTPUT
Generate Secret Number
Guess Message

Guess =
Secret
Yes Number No

OUTPUT OUTPUT
congratulations commiserations
Practical – Convert to pseudocode
Number Guessing Game

gue
ss
u mber secr
etN
etN umb
secr

guess
er

INPUT OUTPUT
Generate Secret Number
Guess Message

Guess =
Secret
Yes Number No

OUTPUT OUTPUT
congratulations commiserations
Criticism
• Examples in the textbook assume global variables
• CIE pseudocode gives us functions as well as procedures, but the
textbook seems to prefer using procedures
• Exam questions require conversion of structure charts to pseudocode
– candidates are not required to write strict CIE pseudocode – but...
see next page
CIE Position on Pseudocode in
exams
"Learners should be encouraged to follow this guide in their examination
answers or any other material they present for assessment.
By definition, pseudocode is not a programming language with a defined,
mandatory syntax. Any pseudocode presented by candidates will only
be assessed for the logic of the solution presented – where the logic is
understood by the Examiner, and correctly solves the problem
addressed, the candidate will be given credit regardless of whether the
candidate has followed the style presented here.
However, candidates are required to write pseudocode for questions
that require answers in pseudocode and not a programming language.
Using a recommended style will enable the candidate to communicate
their solution to the Examiner more effectively."
Example Questions – Q1
• Roberta downloads music from an online music store. The diagram
shows part of a structure chart for the online music store program.

• State three items of information that the diagram shows about the
design of the program.
Q1 Ctd.
• Examples of the data items that correspond to the arrows are given in
the table.
Arrow Data Item
A 234.56
B "Ms Roberta Smith"
C TRUE

• Use pseudocode to write the function header for the Card payment
module.
Program Design – Finite State
Machines
• Finite State Machines (FSMs) are another way to model software
systems
• An FSM is an abstraction of a software system (or any other machine)
• An FSM must be in just one of a finite number of states at any one
time
• An FSM can 'transition' or change state in response to some input
• An FSM is defined by:
• The list of all possible states
• The list of all possible inputs and their associated transitions
• Its initial or starting state
Representing Finite State Machines
• A Finite State Machine can be specified graphically, using a state-
transition diagram
• Alternatively a state-transition table can be used to specify the FSM in
a tabular form
validCardPresented
validCardPresented

start
Closed Open

personPassed
Representing Finite State Machines
• A Finite State Machine can be specified graphically, using a state-
transition diagram
• Alternatively a state-transition table can be used to specify the FSM in
a tabular form
Current State Input Next State
Closed validCardPresented Open
Open validCardPresented Open
Open personPassed Closed
Closed personPassed Closed
Finite State Machines - Outputs
• Explain the representation of outputs on State-transition Diagrams
Example Questions
• This is a frequently-examined area
AS 12.3 – Testing and Maintenance
• Show understanding of ways of exposing and avoiding faults in
programs
• Locate and identify the different types of errors
• Syntax Errors
• Logic Errors
• Run-time Errors
• Correct identified errors
• Show understanding of the methods of testing available and select
appropriate data for a given method
• Including dry run, walkthrough, white-box, black-box, integration, alpha, beta,
acceptance, stub
AS 12.3 – Testing and Maintenance
(ctd.)
• Show understanding of the need for a test strategy and test plan and
their likely contents
• Choose appropriate test data for a test plan
• Including normal, abnormal and extreme/boundary
• Show understanding of the need for continuing maintenance of a
system and the differences between each type of maintenance
• Including perfective, adaptive and corrective
• Analyse an existing program and make amendments to enhance
functionality
 Types of Software Error
Type Definition Example Discovered by…
Syntax Error A mistake that breaks the rules x = Input("Enter your guess: ") The Integrated Development
of the programming language. Misspelt keyword Environment will normally flag syntax
The program cannot be errors in the code editor.
interpreted or compiled print(myStr[i])) The interpreter or compiler will flag
Extra or missing bracket syntax errors in the early stages

Logic Error A mistake in the construction of average = count / total Testing – the program will fail to
the code which will lead to an count and total switched produce an expected result
incorrect or unexpected result

Run-time A mistake in the construction of myStr = "Hello" Testing – the program will crash
Error the code which will cause an for i in range(6): during testing
error when the program runs print(myStr[i])
index will go out of range
Types of Software Error
• Syntax Errors are normally very easy to find, particularly in compiled
languages, where the compiler will flag the errors and will *not*
produce any executable output.
• Syntax Errors are normally very easy to fix.
• Logic and Run-time Errors are more difficult to find, and depend on
software testing. Some errors may occur every time the program is
executed; others may only show up when a certain set of circumstances
occurs (specific inputs, specific timing).
• Most Logic and Run-time Errors are reasonably easy to fix, but some
may require a level of redesign, making the fix a much more complex
and time-consuming activity.
Overview of Testing
• Testing is a core part of quality assurance for software development
• Different Software Development methodologies take different views
of the role of testing, however there are a number of common
elements that we can examine…
Stub Testing
• A 'Stub' is a simple replacement/substitute for a sub-module
• Stubs allow us to test portions of code which rely on sub-modules,
even if those sub-modules have not been written
• Stubs also allow us to test these portions of code under simple and
strictly controlled conditions, removing any complications which arise
from a full implementation of the sub-module
Stub Testing – Very Simple Example
Number Guessing Game

gue
ss
u mber secr
etN
etN umb
secr

guess
er

INPUT OUTPUT
Generate
return
Secret
12Number
Guess Message

Guess =
Secret
Yes Number No

OUTPUT OUTPUT
congratulations commiserations
Alpha and Beta Testing
• Alpha builds of software are early, incomplete products and are
expected to have faults. Testing of these builds is conducted by the
internal product team (testers, developers, or possibly both). This
Alpha testing is an important part of the development process,
attempting to improve build quality at an early stage, as well as
providing feedback on the design.
• Beta builds are functionally complete products which *could* become
release builds. Testing of these builds involves external third-parties,
such as potential users/buyers. The primary focus of Beta testing is to
ensure that the product meets the requirements, but we are also
interested in non-functional aspects such as performance and usability.
Black Box and White Box Testing
• The distinction between Black Box and White Box testing is simply
whether the tester has access to the details of the system being
tested, such as design documents, source code etc. If the tester does
not have access to this information, then they are conducting Black
Box testing; if they do have access, then they are White Box testing.
• In any large software development we will use a combination of these
two approaches.
• The next slide compares and contrasts the uses of these two
approaches.
Black Box and White Box Testing
• White Box testing – we can do structure testing, making sure that we
exercise all code paths (achieving 100% coverage)
• White Box testing is essential for safety-critical systems, where we
want assurance that the behaviour of the software is known for every
possible pathway through the code
• Black Box testing – more representative of the way a user (or an
attacker) would behave
• Most testing approaches would employ both Black and White Box
testing for different and complementary purposes
Dry Runs / Code Walkthroughs
• Dry runs and code walkthroughs are closely-related testing activities
• Instead of using a computer to run the code being tested, we manually
work through the code, assessing and recording its behaviour with given
test inputs
• Trace Tables are often used to keep track of the most important variables
for dry runs
• Code walkthroughs are sometimes less formal procedures, with one
developer providing an explanation (perhaps down to line-by-line in critical
places) of their code
• These activities clearly fit into the category of 'White Box' testing, as we are
operating with knowledge of the software and the internal variables
Test Data
• When we are testing software, it is useful to have a defined set of test
data. One reason being that we want to repeat the same tests on
multiple different builds (sometimes called 'Regression Testing' –
checking whether a new build fails a test that was passed by a previous
build)
• We can broadly divide test data into three categories:
• Normal – valid data which broadly correspond to our expectations of how the
system will be used. Sometimes called 'representative' or 'valid' data
• Boundary – data which tests the boundaries of the system, either from
requirements or code inspection. These data should be accepted; we are
checking for any boundary errors. Sometimes called 'extreme' data.
• Abnormal (or Erroneous) – data which should be rejected by our software
Test Coverage
• A key metric for software development projects, particularly those of
high criticality is 'test coverage', which is a measure of how
comprehensive our suite of tests is
• We can judge coverage both of the requirements and the written code
• Clearly we would like 100% of our requirements to be covered by tests
• The situation with code is rather more difficult, as the effort required to
reach 100% coverage can grow exponentially with respect to the number
of lines of code (we may have different coverage targets for different
parts of our code)
Unit Testing & Integration Testing
• During the development phase of a project, we will be producing a
number of software 'units'; smaller pieces of code which could be
'subroutines' such as individual functions or procedures, whole classes,
or modules
• Each of these 'units' should be capable of being tested in a stand-alone
fashion – without any requirement for the rest of the system. This is
not always the case on all projects, but it is one of the strengths of XP's
test-driven design approach
• When we bring these units together into a full build, then we may carry
out integration testing to check that a combination of units work
together as expected
Acceptance Testing
• Acceptance Testing is really the final goal of the software
development project (before moving into some kind of support and
maintenance phase)
• Acceptance Testing assesses whether the software product meets the
users' requirements
• In Waterfall methodologies, Acceptance Testing is a major milestone,
marking completion of the development work. Agile approaches may
build some elements of Acceptance Testing into sprints, but there will
still be a final phase of testing, assessing the quality of the release
build.
Load Testing
• Load testing is particularly important for web applications, where the
number of users potentially able to access the application or service
simultaneously is enormous, and not easy to predict or control
• A load test will look very similar to a denial of service attack (and if you
are testing a web app in a live environment, you are normally required
to gain the agreement of your hosting service before conducting a load
test)
• Load testing helps us to assess the performance of our software under
real and extreme conditions, so that we can identify and remove
bottlenecks, or design load-responsive approaches (for example scaling-
out by adding more servers)
Usability Testing
• Many of our testing activities focus on whether the software is doing
the right thing – producing the correct outputs for a given set of
inputs for example
• Usability testing is one of our non-functional tests (load testing falls
into this category) and focuses on how easy the user interface is to
navigate and operate – can a user rapidly find the most common
pieces of functionality? Do these functions operate in a predictable
manner? Are less-common pieces of functionality still relatively easy
to find? Can visually-impaired users access the software?
Test Automation
• Manually testing software can be a repetitive and mundane task
• Many software development teams automate the routine tests to
some degree
• Unit and integration tests can be automated, and most modern
software development environments support the automatic
execution of tests (for example, running these tests each time a full
system build is produced)
Software Maintenance
• Like any other complex man-made system, programs need to be maintained
in order to keep them in good working order
• We can divide software maintenance into three broad categories:
• Corrective Maintenance
• When a software system has been completed, some errors may remain undetected.
As the system is put to use, these errors can manifest themselves. Corrective
maintenance is concerned with correcting these bugs
• Adaptive Maintenance
• As a software system is put to use, new requirements may be identified – perhaps new
integrations, or additional features. Adaptive maintenance is concerned with ensuring
that the program meets these emerging needs
• Perfective Maintenance
• Finally, there are a range of non-functional aspects to software; performance, usability,
scalability for example. Perfective maintenance is concerned with improving these
non-functional aspects