CHAPTER

08 Software Engineering

316
317
 8.1 Stages in Developing a Program

LEARNING OUTCOMES
2.6.1 Understand and describe the stages in developing a program: gather requirements, design
solutions, write code, test and refine code, deploy code.

ER MS
Software engineering is the process of designing,
creating, and maintaining software applications. In
KEY T
general, there are five stages in developing a program. Software Engineering
The process of designing, creating, and
This is a version of the traditional “waterfall model” maintaining software applications
of software development where progress flows
through multiple stages in a sequential manner and
each stage is completed before moving on to the next
stage, just like how a waterfall flows downward in a
single direction.

!"#$%&'(%)*+&%,%-#.

/%.+0-'123*#+2-.

4&+#%'526%

7%.#'8'(%9+-%'526%

/%:32;'526%

Figure 8.1 Stages in developing a program

318
 8.1.1 Gather Requirements

The goal of this initial stage is to determine the nature of the problem, why a program is needed and what
the program is expected to do. If this stage is not performed properly, it is likely that any program that is
developed will not be as useful as intended. Some of the tasks that can be done during this stage:

• Interviewing the intended audience of the program to understand the nature of the problem or
their expectations
• Specifying the complete set of inputs that is necessary for the problem and how the inputs can
be supplied to the program being developed
• Specifying the complete set of outputs that is necessary for the problem, any requirements the
output must meet and the format for the output

Suppose Siti is required to develop a program to manage the loan records and check the availability of
books at the school library. She interviews the librarians in her school to understand why a program is
needed and what the program is expected to do. They give the following responses:

“This is a very small library

so no two books have the
same title.”
“We only have one
“When someone asks me if computer connected to a
a book is available, I must keyboard and screen. The
go check the bookshelf. computer has a list of book
This can take a long time. titles and their availability
It would be faster if I could as comma-separated
find out the answer from values in a text file.”
the computer.”

Figure 8.2 Siti interviewing a librarian

From the information that she has gathered, Siti concludes that the program would need the following
inputs and output shown in Table 8.1. She has also given each input a descriptive name to work with.

319
 Input Expected Output

• availability: list of book • Whether the book in

titles and availability as comma- search is available
separated values (via text file)
• search: title of book to check
availability

Table 8.1 Input and output requirements for the book availability problem – Test Case 1

A good way to check whether the program’s requirements are understood correctly is to write test cases.
This is also a good opportunity to solve simple examples of the problem manually for the next stage. Siti
thus prepares two test cases under normal conditions:

→ Input Expected Output →

• availability: (see availability.txt below) Available

How to Solve a Mystery,Not Available

Vacant Memories,Available
The Cybersnake Chronicles,Available
Music History,Not Available
Like Tears in Rain,Not Available
Out of the Abyss,Not Available

• search: “Vacant Memories”

Table 8.2 Book availability problem – Test Case 1

→ Input Expected Output →

• availability: (see availability.txt below) Not Available

How to Solve a Mystery,Not Available

Vacant Memories,Available
The Cybersnake Chronicles,Available
Music History,Not Available
Like Tears in Rain,Not Available
Out of the Abyss,Not Available

• search: “Music History”

Table 8.3 Book availability problem – Test Case 2

320
She then prepares a test case under error conditions where the book is not found:

→ Input Expected Output →

• availability: (see availability.txt below) Book Not Found

How to Solve a Mystery,Not Available

Vacant Memories,Available
The Cybersnake Chronicles,Available
Music History,Not Available
Like Tears in Rain,Not Available
Out of the Abyss,Not Available

• search: “Resilience”

Table 8.4 Book availability problem – Test Case 3

Siti also prepares additional test cases to cover boundary conditions such as having empty inputs, but for
simplicity we shall omit these test cases from the following discussion.

U
DID YO
N O W ?
K
For user interface requirements that may not be expressed easily as test
cases, a sketch or mock-up of the final product (without any actual code)
can be another useful communication tool for developers to visualise
and understand the desired features and behaviour of the software.

8.1.2 Design Solutions

After gathering and refining the required inputs and outputs of the program, the next stage is where
the skills of decomposition and generalisation are used to plan out a solution. The goal of this stage is
to consider the options available before any code is written, and to choose an algorithm based on the
resources available (such as manpower and time). Some of the tasks that can be done at this stage:

• Manually solving different simplified examples of the problem and generalising the steps needed
to produce the required output
• Trying different ways to break down the problem into smaller parts such that the intended output
of each part gets closer and closer to what is needed to solve the problem
• Comparing the problem (or its smaller parts) to other problems that have been solved before and
identifying which algorithms can be used
• Estimating the amount of effort needed to write the code or the time needed to complete the
algorithm before making a definite choice
• Planning possible algorithms using flowcharts

321
 U
Siti notices that she can DID YO
decompose the problem
O W ?
into three distinct tasks of
obtaining input, searching K N
through the list of book
titles and, finally, generating Often, existing software or Python modules that solve significant parts
output of whether the of the problem are readily available online so it will not be necessary to
requested book is available. reimplement the relevant algorithms. Finding and using such resources,
She illustrates this using a if allowed by their license (see Chapter 12), can greatly reduce the
simple flowchart shown in amount of new code that needs to be written in the next stage.
Figure 8.3:

START

INPUT availability, search

Find search in availability and

store its corresponding
availability in result

OUTPUT result

STOP

Figure 8.3 Planned solution to Siti’s problem

She notices that the task of reading comma-separated values from a file can be further decomposed
into the tasks of reading a file and splitting its lines based on a delimiter. She also notices that the task of
searching for the book title is similar to the task of finding the location of a value in a list. From there, she
can adapt algorithms that she is already familiar with to complete the task.

322
 START

INPUT availability.txt as ƒ

lines = split contents of ƒ by “\n”

delimiter

availability = []

No
All items in lines line = next unprocessed item in lines
processed?

Yes
Split line by “,” delimiter and insert split
INPUT search values into availability

No
All items availability record = next unprocessed item in
processed? availability

Yes
No
Is search == record [0]?

Yes

result = record [1]

OUTPUT results

STOP

Figure 8.4 Expanding the planned solution to Siti’s problem

Siti decides that this planned solution is feasible and moves on to the next stage.

323
 8.1.3 Write Code

In traditional program development, the code for the final program is written only after the first two
stages of gathering requirements and planning solutions are completed. This minimises the possibility of
producing code based on incomplete requirements or inefficient algorithms that would eventually need to
be discarded. The goal of this stage is to write code that performs the algorithm as planned in the previous
stage as efficiently as possible.

One possible way for Siti to write her code would be:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15

Figure 8.5 Draft of code to solve Siti’s problem

U
DID YO
KNOW?
Instead of writing code from scratch, generative artificial intelligence services, such as GitHub
Copilot, ChatGPT and Google Gemini, can generate useful code based on an English description
of the problem to be solved. For best results, decomposition should be used to break the problem
down into simpler parts first as such services may not work well for overly complex or uncommon
problems.

Although useful, be aware that the code generated from such services may not always be correct
and there are ethical concerns as these services typically use code written by authors who may
not have explicitly consented to the use of their code in this way. In addition, using these services
and presenting the code that is generated as your own work would be considered plagiarism.
These and other concerns with the use of Artificial Intelligence are discussed further in Chapter 14.

324
 8.1.4 Test and Refine Code
After the initial code is written, the resulting program is likely to require further refinement. Some possible
reasons for this:
• The programmer may have made mistakes in translating the planned algorithm into code or may have
forgotten to perform input validation. For example, the programmer may have made a syntax error or
forgotten to check for invalid input. These are relatively minor errors that usually would not require
major rewriting of code as simply correcting the syntax error or adding an if statement would usually
be sufficient to correct the program.
• The solution-planning stage may not have been performed properly, resulting in an unsuitable or
incomplete algorithm. For example, the chosen algorithm may give the correct answer for only some
combinations of inputs and not for other (valid but perhaps less common) combinations of inputs.
Depending on how serious the mismatch is, it may be possible to keep most of the written code and
simply make refinements. Otherwise, it may be necessary to discard the written code and redo the
evaluation of algorithms.
• The requirement-gathering stage may have been incomplete, resulting in code that does not address
the users’ needs. Depending on how serious the mismatch is, it may or may not be possible to reuse
most of the written code.

U
Testing is the process by which DID YO
KNOW?
these and other imperfections
are uncovered. For the first two
points, this is done by running the
code through the test cases that
may have been written during the To detect the possibility that the program may not actually
requirement-gathering stage to address the users’ needs, after passing the prepared test
evaluate whether the written code cases, user acceptance testing may also be performed. In
adequately satisfies the gathered user acceptance testing, members of the program’s intended
requirements and is ready to be audience use early versions of the program and provide feedback
used. to the developers. If the testing is done at the developer’s site,
this is called alpha testing. If the testing is done externally in
Siti runs the program through the the user’s environment, this is called beta testing. This process
test cases one by one, comparing of involving eventual users of the program early ensures that
the program’s output with the requirements gathering is performed properly and helps to
expected output: avoid any problems later when the code is deployed.

→ Input Expected Output →

• availability: (see availability.txt below) Available

How to Solve a Mystery,Not Available

Vacant Memories,Available
The Cybersnake Chronicles,Available
Music History,Not Available
Like Tears in Rain,Not Available
Out of the Abyss,Not Available

• search: “Vacant Memories”

Running availability_draft.ipynb → Result

Enter title of book to check: Vacant Memories Passed

Available

Table 8.5 Book availability problem – Test Case 1

325
 → Input Expected Output →

• availability: (see availability.txt below) Not Available

How to Solve a Mystery,Not Available

Vacant Memories,Available
The Cybersnake Chronicles,Available
Music History,Not Available
Like Tears in Rain,Not Available
Out of the Abyss,Not Available

• search: “Music History”

Running availability_draft.ipynb → Result

Enter title of book to check: Music History Passed

Not Available

Table 8.6 Book availability problem – Test Case 2

So far, the output of Siti’s program has matched the expected output, so the program seems to be
functioning as intended. However, she proceeds to run the next test case that searches for the name of a
book which is not in the library collection.

→ Input Expected Output →

• availability: (see availability.txt below) Book Not Found

How to Solve a Mystery,Not Available

Vacant Memories,Available
The Cybersnake Chronicles,Available
Music History,Not Available
Like Tears in Rain,Not Available
Out of the Abyss,Not Available

• search: “Resilience”

Running availability_draft.ipynb → Result

Enter title of book to check: Music History Failed

Not Available

---------------------------------------------------
NameError Traceback (most recent call last)
Input In [1], in <cell line: 15>()
12 result = record[1]
14 # Output
---> 15 print(result)

ame rror name re ult i not e ne

Table 8.7 Book availability problem – Test Case 3

326
Now, Siti notices a bug. When the user enters the name of a book that does not exist in the library, her
program generates an error instead of producing the expected output “Book Not Found”. (If you are
running the test case for yourself, you may not get the error of an undefined variable if you ran any previous
test cases in the same Jupyter notebook. Instead, the output from the last test case that is still stored in
result will be displayed, which still fails the test case.)

Siti studies her program carefully and realises that she did not consider this special case. Fortunately, she
can resolve this by initialising the value of result to “Book Not Found”. Her refined code is shown in Figure
8.6:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16

Figure 8.6 Refined draft of code to solve Siti’s problem

With this modification, her program passes Test Case 3:

→ Input Expected Output →

• availability: (see availability.txt below) Book Not Found

How to Solve a Mystery,Not Available

Vacant Memories,Available
The Cybersnake Chronicles,Available
Music History,Not Available
Like Tears in Rain,Not Available
Out of the Abyss,Not Available

• search: “Resilience”

Running availability_draft.ipynb → Result

Enter title of book to check: Resilience Passed

Book Not Found

Table 8.5 Book availability problem – Test Case 1

327
 Siti then continues to run the program on the remaining test cases and makes further modifications to fix
bugs until all test cases are passed.

U
DID YO
KNOW?
In larger projects with multiple developers, code is usually kept in a version control system,
such as Git, that allows developers to easily track, compare and combine changes from multiple
programmers. Version control systems also allow for previous versions of code to be recovered
easily if any modifications need to be rolled back.

8.1.5 Deploy Code

With the code tested and refined, this is the stage where the program is actually “rolled out” and used by
its intended audience. Some of the tasks that can be performed under this stage:

• Training users to use the program

• Transitioning from an old program or system to the new program
• Evaluating the effectiveness of the program in solving the problem and considering any changes that
might increase its usability or effectiveness

Siti deploys her code by installing Python in the library’s computer and copying the program over. She
organises a training session to teach the librarians how to use the program and gathers their feedback after
the first day of use. She receives the following comments:

“The program is good, but

can it be faster?”
“Some book titles take very
“Your program makes it long to type. However, it’s
much easier to check if a still faster than checking
book is available. Thank the bookshelves!”
you!”

It seems that while Siti’s program meets the requirements, it can still be improved in terms of usability and
speed. To make these improvements, it may be necessary to perform a review and repeat the five stages
starting from the requirements gathering stage.

328
 QUICK . 1
C K 8
CHE
1. Write a short description for each of the five software development stages (i.e., gather requirements, design
solutions, write code, test and refine code, deploy code).

2. Describe two problems that might occur if the initial requirements-gathering stage is not performed properly.

3. For each of the following activities, identify at which stage of software development the activity is most likely
to occur in:
a) Translating an algorithm to a computer program.
b) Editing the program to fix a bug.
c) Asking users to describe what they want for the program’s output.
d) Installing the program on a user’s computer.
e) Deciding on an algorithm that would produce the desired output.

8.2 Alternative Methodologies

LEARNING OUTCOMES
2.6.2 Recognise that the sequence of software development stages may not be linear, and the use
of iterative development may sometimes be more appropriate.

Suppose that midway through the development

of Siti’s program, the librarians inform her that the
U
DID YO
library will be expanding and in the future, there
may be multiple books with the same title. This
requires Siti to relook at the design of her solution
N O W ?
so each physical book can still be identified
uniquely. K
Alternatively, while testing the program, the This more flexible version of the waterfall
librarians realise that they also need the program model, where there are still clear stages but
to handle updating the text file when a book is feedback loops are allowed, is called the
borrowed or returned. This requires Siti to expand modified waterfall model.
the scope of her program significantly. In general,
users may not know what they really need until
they have experimented with an early version of
the product.

These scenarios highlight a weakness of having a strict sequence of stages in that requirements often
change in practice, but a linear approach makes it difficult to go back and make changes to earlier stages.
Ideally, some flexibility is allowed such that if issues are identified at a later stage, it’s possible to go back
to a previous stage and make adjustments.

Hence, sometimes the use of alternative software engineering methodologies that allow for iterative
development and blending of the different stages may be more appropriate. Two such methodologies are
Agile Development and Test-Driven Development.

329
 8.2.1 Agile Development

Although “agile” is a broad term that encompasses a range of practices, in general software developers
who practice agile development break down a large project into smaller increments so feedback and
changes to requirements can be integrated continuously.

Unlike the traditional model where requirements

are gathered before any coding begins, in agile
U
development requirements gathering is not a DID YO
one-time activity that occurs at the beginning of
O W ?
the project. Instead, requirements are collected
and refined throughout the development K N
process. This allows for flexibility and the ability
to adapt to changing needs and priorities. Under agile development, requirements
are usually collected and prioritised in the
Development is also broken down into short form of user stories that describe the desired
cycles called sprints, where a specific subset of functionality or features from the user’s
requirements is selected for implementation. perspective without focussing on technical
At the end of each sprint, working software is details. User stories helps to keep user at
produced, then the implemented features are the centre of the process and serve as a
demonstrated to the users and early feedback communication tool to help programmers
collected to be incorporated into the next sprint. build a common understanding of what
Hence, this is an iterative process where smaller features they need to build and why they are
versions of the five stages take place for each important to the user.
sprint within the larger development process.

:%-#;",9
'%<*,%;869% :%-#;",9
'%<*,%;869% :%-#;",9
'%<*,%;869%
3%=76>
869% 1&*#% 3%=76>
869% 1&*#% 3%=76>
!"#$%& 869%
!"#$%&
869% 869% 1&*#%
869%
!"#$%&

3%-*4, 3%-*4, 3%-*4,

567)#*6,- !"#$%& 567)#*6,- !"#$%& 567)#*6,-
!"#$%&;'%()*&%+%,#- './0.12 './0.12 './0.12
'%()*&%+%,#- '%()*&%+%,#-

Figure 8.7 Agile is an iterative process where smaller versions of the five stages take place for each sprint

8.2.2 Test-Driven Development

Unlike the traditional model where developers complete writing code before testing code, in Test-Driven
Development (TDD), test cases are run regularly, and code is written incrementally to pass each test. Many
aspects of this methodology, such as writing test cases before writing code and testing incrementally,
already reflect some of the recommended practices in this textbook.

330
 U
In TDD, each time new functionality is DID YO
?
KNO W
implemented, three steps are followed.

The diagram below represents an iterative

process where the “write code” and
“test and refine code” stages are tightly
To facilitate TDD, the running of test cases and
integrated and repeated for each new
reporting of which test cases passed or failed is
feature that is implemented.
usually automated. Some built-in Python modules
that are designed for this purpose are unittest
and doctest.

1 2 3
Write Test Cases Write Code Tidy the Code

The test cases should specify The goal for this step is to After the test cases pass,
the intended behaviour of write the minimum amount developers can improve
the new functionality and will of code needed to pass all the code’s organisation,
initially fail because code has the test cases. This is to readability, and efficiency
not been written yet. discourage implementing without changing its
functionality for which test functionality. This step
cases have not been written ensures that the code remains
yet. clean and maintainable.

QUICK . 2
C K 8
CHE
1. For each of the following statements, state whether it is a valid reason as to why an iterative process may be
more appropriate than following the five stages of software development in a strict order.

a) Users may not know what they truly want until they have experimented with an early version of the product.
b) New and unexpected requirements may arise midway through development.
c) The time required to go through the five stages is not significant and so it is not costly to iterate through them
repeatedly.
d) The risk of having an entire project fail is reduced as working software is produced incrementally.
e) The program can be deployed more quickly as testing and refining code may be skipped after the first
iteration.
f) It is easier for developers to satisfy a small set of requirements at a time over multiple iterations than to
satisfy the entire project’s requirements all at once.

331
 W
REVIE
E STI ON
Q U
1. In some versions of the traditional model, test cases are not used for requirements gathering and are
prepared only after the project’s code is written. Suggest one possible disadvantage of this approach.

2. You have been asked to develop a direct replacement for an existing program with no change in behaviour
other than the programming language used. The requirements for the current program are already fully
documented and the replacement program must be completed within a fixed timeline. Interaction with the
program’s eventual users is also limited to two short periods at the start and end of the project.

Suggest two reasons why an iterative approach may not be appropriate in this scenario.

3. While training teachers in the code deployment stage on how to use a new program for classroom
management, a developer encounters some problems caused by previous stages of software development
not being performed properly. Suggest which stage is most likely to be at fault for each problem and explain
why:

a) The program fails unexpectedly during a demonstration.

b) The teachers are dissatisfied as they expected that the program would allow for custom names for each
classroom.
c) The program is slow due to the choice of algorithm used.

ANSWER

Pg. 329-Quick Check 8.1

1.
Stage Description
Gather requirements Stage where the developer communicates with the intended users
to understand what the program is supposed to do. This involves
identifying the problem that needs to be solved by specifying the
required inputs and outputs. Test cases may also be written at this
stage.
Design solutions Stage where the developer considers the options available, uses
decomposition and generalisation to plan possible algorithms, then
finally chooses a suitable algorithm based on the resources available
such as manpower and time.
Write code Stage where the developer translates the program’s design into
computer code by writing instructions in a programming language.
Test and refine code Stage where the developer runs the program through test cases to
detect bugs, The program’s code is then modified and debugged until
all the test cases pass.
Deploy code Stage where the program is installed on users’ computers, training for
users on how to use the program takes place and the program’s usage
is monitored for any improvements that may be made in the future.

2. Any two of:

• Unsatisfied users as resulting program may not include all the necessary features and is thus not as useful as
intended.
• Increased cost or inefficient use of resources as resulting program may include features that are not actually
needed.
• Delayed completion of project due to extra time needed to clarify requirements or to repeat the requirements-
gathering stage entirely.

332
ANSWER
3. a) Write code
b) Test and refine code
c) Gather requirements
d) Deploy code
e) Design solutions

Pg. 331-Quick Check 8.2

3. a) Valid reason.
b) Valid reason.
c) Invalid reason. Compared to going through the five stages just once, iteration is likely to be more costly in
terms of time.
d) Valid reason.
e) Invalid reason. Testing and refining code is important should not be skipped even after the first iteration.
f) Valid reason.

Pg.332-Review Question
1. Any two of:
• Higher chance of misinterpretation or misunderstanding of requirements. Test cases are more explicit than
trying to describe requirements in words and they help to ensure that there is a shared understanding of the
requirements by both developers and users.
• Higher chance of omitting requirements, especially for input data under error and boundary conditions.
The guideline that test cases must cover normal, error and boundary conditions helps to ensure that the
requirements under these conditions are properly considered.

2. Any two of:

• The requirements are fixed and already documented, so an iterative process that is intended for ongoing
refinement of requirements and adjustment of existing features may not be the most appropriate.
• The timeline is fixed, so an iterative process that may require more flexibility in terms of timeline may not be
the most appropriate.
• The opportunities for developers and users to communicate are limited, so an iterative approach that requires
continuous feedback from users may not be the most appropriate

3. a) Stage most likely at fault: Test and refine code

Explanation: The program likely failed due to a bug that should have been detected and fixed in the code
testing and refinement stage.
b) Stage most likely at fault: Gather requirements
Explanation: The teachers’ expectation that the program would allow custom names for each classroom
should have been captured in the requirements gathering stage.
c) Stage most likely at fault: Design solutions
Explanation: A more efficient or appropriate algorithm should have been chosen in the solution designing
stage.

333