GET 211 – SOFTWARE ENGINEERING STUDY NOTES

COMPILED BY

DR ABOLADE OMIYALE

DEPARTMENT OF SYSTEMS ENGINEERING

1
 TOPIC 1: SOFTWARE ENGINEERING AS AN ENGINEERING DISCIPLINE

Introduction

Software is no longer a peripheral component of modern systems; it is often the central

element determining how systems behave. Banking platforms, hospital information systems,
transport scheduling applications, and digital learning environments rely heavily on
software. Because these systems affect economic activity, safety, and public trust, their
development cannot be treated as informal programming. Software engineering, therefore,
emerges as a disciplined approach to designing, building, testing, deploying, and maintaining
software systems in a controlled and responsible manner.

At the undergraduate level, the most important conceptual shift is moving from “writing
programs” to “engineering software systems”. Programming emphasises syntax, logic, and
making code run. Software engineering expands this focus to include requirements analysis,
design structure, risk management, teamwork, lifecycle thinking, and professional
responsibility.

Conceptual Explanation

Software engineering is defined as the systematic application of engineering principles,

methods, and tools to software development and maintenance. The term systematic
highlights predictability and repeatability, while engineering principles emphasise trade-offs,
evidence-based decision-making, and accountability.

Unlike physical products, software does not wear out. Instead, problems arise from design
flaws and evolving requirements. Maintenance, therefore, involves modification rather than
repair. This characteristic makes software engineering heavily lifecycle-oriented, with
significant effort occurring after deployment.

Software should be viewed as a structured collection of:

• Executable programs implementing logic

• Data that the system processes and stores
• Configuration artefacts controlling behaviour
• Documentation supporting usage and maintenance

This broader view reinforces the idea that software is a system asset rather than merely code.

Another defining characteristic of software engineering is the management of constraints.

Engineers must operate within cost limits, deadlines, safety requirements, legal frameworks,
and technological constraints. Engineering decisions, therefore, involve trade-offs. For
example, increasing security in an online banking platform may reduce usability, while
improving performance may increase infrastructure costs.

2
Examples and Nigerian Context

Consider a Nigerian university portal used for course registration. From a programming
perspective, the goal may appear simple: allow students to select courses and submit forms.
From a software engineering perspective, the system must handle thousands of
simultaneous users, prevent duplicate registration, ensure data integrity, and remain
available during peak periods. These concerns require planning, architecture, testing, and
maintenance strategies beyond coding.

Similarly, digital payment platforms such as mobile transfer applications must maintain
reliability and security. A single software failure could result in incorrect debits or loss of
trust. Such systems demonstrate why software engineering practices exist.

Applications

Understanding software engineering as a discipline prepares students to:

• Participate effectively in team development

• Build systems that remain usable over long periods
• Anticipate risks associated with complexity
• Design systems that balance performance, usability, and security

This mindset is essential for large-scale systems such as smart waste management platforms,
e-government services, and digital health solutions increasingly deployed across Nigeria.

Summary

Software engineering transforms programming into a disciplined engineering activity. It

emphasises lifecycle thinking, responsibility, trade-offs, and system context. The discipline
ensures that software systems are reliable, maintainable, and suitable for real-world
deployment.

Exercises

Short-Answer Questions

1. Define software engineering.

2. State two differences between programming and software engineering.
3. Why does most software cost occur after deployment?

Conceptual Questions

1. Explain why software is considered an informational product rather than a physical

product.
2. Discuss how engineering constraints influence software design decisions.

3
Application Question

A Nigerian polytechnic wants to build an online hostel allocation system. Identify three
software engineering considerations beyond coding.

Model Answers

Short Answers

1. Software engineering is the disciplined application of engineering principles to the

development and maintenance of software systems.
2. Programming focuses on writing code, while software engineering includes
requirements analysis, design, testing, and maintenance.
3. Software evolves, requiring updates, adaptation, and defect correction.

Conceptual Answers

1. Software is intangible, and its defects arise from design rather than manufacturing
processes.
2. Constraints such as cost, time, and security force engineers to balance competing
system qualities.

Application Answer

• Scalability to support many students

• Data integrity for allocation records
• Security to prevent unauthorised access

Recommended Textbook Chapters

• Sommerville: Ch. 1 — Introduction

• Pressman: Ch. 1 — Software and Software Engineering
• Mall: Ch. 1 — Introduction to Software Engineering

Freely Accessible Materials

• IEEE SWEBOK overview (software engineering fundamentals)

• MIT OpenCourseWare — Intro to Software Engineering lectures (YouTube)

4
 TOPIC 2: SOFTWARE SYSTEMS AND ENGINEERING CONTEXT

Introduction

Software does not operate in isolation. Every software system exists within a broader
environment consisting of hardware, networks, human users, organisational policies, and
physical conditions. Failure to understand this context is a common cause of system
breakdown, even when code is technically correct.

This topic introduces the concept of software systems as socio-technical systems,

emphasising that successful engineering requires understanding interactions among
technical and non-technical elements.

Conceptual Explanation

A software system is a collection of interacting components working together to achieve a

specific purpose. These components typically include:

• Software modules and services

• Hardware devices and sensors
• Databases and communication networks
• Human users and operational procedures

System behaviour emerges from interactions among these elements rather than from
individual components alone. Consequently, a system may fail even when each component
works correctly.

Interfaces play a central role in system success. Software–hardware interfaces define

communication with devices, software–software interfaces define integration among
services, and human–computer interfaces determine usability. Many failures occur at these
boundaries due to incompatible assumptions or poor design.

Human behaviour adds additional complexity. Users may misinterpret instructions, make
mistakes, or use systems in unintended ways. Software engineering, therefore, adopts a
defensive design philosophy that anticipates user error and provides safeguards.

Examples and Nigerian Context

A Nigerian university registration portal may experience failure not because of faulty code
but because students attempt simultaneous access during course registration deadlines.
Network congestion, server overload, and user impatience create system stress that must be
anticipated during design.

Similarly, ATM systems integrate software, hardware, banking networks, and operational
procedures. A failure in any interface may lead to transaction inconsistencies, highlighting
the importance of system-level thinking.
5
Traffic control systems provide another example. Sensors detect vehicle movement,
software determines signal timing, and physical traffic lights execute commands. Timing
errors or incorrect assumptions may cause congestion or accidents, illustrating the safety
implications of software context.

Applications

Understanding system context helps engineers:

• Design resilient systems that tolerate failure

• Balance technical performance with human usability
• Anticipate environmental constraints such as power instability
• Develop dependable socio-technical systems

These insights are particularly relevant in environments with infrastructure variability,

where engineering must consider network reliability, device heterogeneity, and diverse user
skill levels.

Summary

Software engineering extends beyond coding to understanding interactions among technical

components, humans, and organisational processes. System success depends on context
awareness, interface design, and anticipation of real-world conditions.

Exercises

Short-Answer Questions

1. Define a software system.

2. What is a socio-technical system?
3. Mention two types of interfaces in software systems.

Conceptual Questions

1. Explain why correct software logic does not guarantee system success.
2. Discuss the role of human behaviour in software system reliability.

Application Question

A hospital appointment system frequently experiences missed bookings despite correct

scheduling logic. Suggest possible contextual causes.

6
Model Answers

Short Answers

1. A software system is a collection of interacting components working together to

achieve a purpose.
2. A socio-technical system combines technical components with human and
organisational factors.
3. Software–hardware interface and human–computer interface.

Conceptual Answers

1. Failures may arise from interface issues, environmental constraints, or user

misunderstandings.
2. Human errors can introduce unexpected inputs and misuse that compromise
reliability.

Application Answer

• User interface confusion

• Network connectivity problems
• Staff misunderstanding of procedures

Recommended Textbook Chapters

• Sommerville: Ch. 2 — Socio-technical Systems

• Pfleeger: Ch. 1–2 — Systems and Context
• Mall: Ch. 2 — Software Process and Environment

Free Resources

• NPTEL Software Engineering lectures (India IIT series)

• OpenLearn (UK Open University) — Systems thinking modules

7
 TOPIC 3: SOFTWARE PROCESSES AND LIFECYCLE MODELS

Introduction

Large software systems cannot be developed through improvisation. They involve many
developers, long timelines, evolving requirements, and significant risks. A software process
provides the structure that organises these activities and ensures predictable outcomes.
Without a defined process, development becomes chaotic, leading to missed deadlines,
rework, and poor-quality systems.

A software process is therefore a structured set of activities, roles, and artefacts that guide
how software is developed and maintained over time. It answers four fundamental questions:
what activities are performed, in what order they occur, who performs them, and what
outputs are produced.

Conceptual Explanation

The Software Development Life Cycle (SDLC) represents the phases through which a system
passes from conception to retirement. Typical phases include planning, requirements
analysis, design, implementation, testing, deployment, and maintenance. Lifecycle thinking
highlights that early decisions influence long-term system cost and quality, while
maintenance often dominates total project effort.

Traditional Process Models

Traditional models assume stable requirements and sequential development. The Waterfall
model exemplifies this approach, where each phase must be completed before the next
begins. It is effective when requirements are well understood and regulatory documentation
is required, such as in payroll or inventory systems.

The V-Model extends the waterfall model by associating each development stage with a
corresponding testing stage. Requirements link to acceptance testing, design links to system
testing, and module design links to unit testing. This traceability is essential in safety-critical
systems.

Iterative and Incremental Development

Iterative development builds software through repeated cycles, while incremental

development delivers functionality in small, usable segments. This approach recognises that
understanding improves over time and allows early feedback. For instance, a mobile banking
app may release balance inquiry first, followed by transfers and later bill payments.

8
Agile Thinking

Agile methods emphasise adaptability, collaboration, and continuous delivery. Short

iterations enable rapid feedback and evolving requirements. Agile treats development as a
learning process rather than a rigid plan, making it suitable for dynamic environments such
as web platforms and startups.

Illustration

Consider a Nigerian university learning management system. Using a Waterfall approach

might delay student feedback until late stages, risking usability issues. An iterative approach,
however, could release core features like lecture upload first, then expand to assessments
and analytics based on user feedback.

Applications

Process selection depends on project characteristics, including system complexity, risk level,
team size, and requirement stability. Choosing an inappropriate process can itself become a
cause of project failure.

Summary

Software processes transform development from ad hoc coding into disciplined engineering.
They provide coordination, risk control, and lifecycle awareness, enabling reliable system
delivery.

Exercises

Short Answer

1. Define software process.

2. List two phases of the SDLC.
3. State one advantage of iterative development.

Conceptual

1. Explain lifecycle thinking in software engineering.

2. Compare Waterfall and Agile approaches.

Application

A startup developing a ride-hailing platform expects changing requirements. Which

process is most suitable and why?

9
Model Answers

Short: Structured set of development activities; planning and testing; early feedback.
Conceptual: Early decisions influence long-term cost; Waterfall is sequential, while Agile is
adaptive.
Application: Agile, because requirements evolve and rapid feedback is needed.

Recommended Textbook Chapters

• Sommerville: Ch. 3 — Software Processes

• Pressman: Ch. 2–3 — Process Models
• Jalote: Ch. 2 — Process Framework

Free Resources

• GeeksforGeeks — SDLC overview articles

• Guru99 SDLC tutorials (very accessible for students)

10
 TOPIC 4: AGILE DEVELOPMENT PHILOSOPHY

Introduction

Agile development recognises that change is inevitable in software projects. Rather than
resisting change, Agile embraces adaptability through iterative delivery and continuous
stakeholder collaboration.

Conceptual Explanation

Agile development operates in short cycles called iterations or sprints. Each iteration
produces a usable increment of the system. Collaboration with users ensures that evolving
requirements are incorporated early, reducing the risk of building irrelevant features.

Agile teams are typically small and cross-functional, promoting shared responsibility and
rapid communication. Documentation is kept lightweight, prioritising working software as
the primary measure of progress. Continuous testing and integration ensure that defects are
detected early.

Strengths and Challenges

Agile improves responsiveness, visibility of progress, and user satisfaction. However, it

demands strong discipline, effective communication, and consistent stakeholder
involvement. Without these, development may become unstructured.

Illustration

A fintech startup launching a savings application may adopt Agile to release core features
quickly, gather customer feedback, and iteratively enhance security and usability.

Applications

Agile is suitable for dynamic environments, user-centred systems, and innovation-driven

projects. It is less appropriate for safety-critical systems requiring extensive documentation
and certification.

Summary

Agile represents a mindset prioritising adaptability, collaboration, and incremental delivery.

It reflects the evolving nature of modern software development.

11
Exercises

Short: Define Agile; state one Agile principle.

Conceptual: Why is continuous testing important in Agile?
Application: Suggest a project suitable for Agile.

Model Answers

Agile is iterative, adaptive development; customer collaboration; early defect detection;

mobile banking app.

Recommended Textbook Chapters

• Sommerville: Ch. 3–4 — Agile Methods

• Pressman: Ch. 3 — Agile Process Models
• Engineering Software Products: Agile & Lean chapters

Free Resources

• Scrum Guide (official, free PDF)

• Agile Alliance introductory materials

12
 TOPIC 5: PROTOTYPING MODEL

Introduction

When requirements are unclear, attempting full-scale development immediately can be risky.
The prototyping model addresses this challenge by creating simplified experimental
versions of the system that help stakeholders visualise functionality and refine expectations.

Conceptual Explanation

A prototype is an incomplete, quickly developed system created primarily for learning rather
than deployment. Its objective is to determine whether the proposed system meets user
needs. Prototypes emphasise interaction and workflow rather than performance or
completeness.

Two major forms exist:

Throwaway Prototyping

Here, the prototype is built, evaluated, and discarded. Lessons learned guide the final design.
This prevents experimental code from contaminating production systems.

Evolutionary Prototyping

The prototype is gradually refined into the final product through continuous feedback and
incremental improvements. While this approach accelerates delivery, it risks architectural
weaknesses if early design decisions are poor.

Benefits and Risks

Prototyping improves requirement clarity, enhances usability, and fosters user engagement.
However, stakeholders may misinterpret prototypes as finished systems, leading to
unrealistic expectations. Developers may also introduce shortcuts that accumulate technical
debt.

Illustration

In developing an online examination platform for a college of education, a prototype

interface could help lecturers visualise questions and upload workflows before full
implementation. This reduces misunderstanding and improves acceptance.

Applications

Prototyping is particularly valuable for user-interface-intensive systems, decision-support

tools, and innovative applications where requirements evolve.

13
Summary

Prototyping is a risk-reduction strategy that enhances requirement understanding and

usability. When managed properly, it strengthens system design; when misused, it
undermines engineering discipline.

Exercises

Short: Define prototype; mention one type; state one benefit.

Conceptual: Why should prototypes not be treated as final systems?
Application: Suggest a scenario where prototyping is appropriate.

Model Answers

Prototype is an experimental system; throwaway prototyping improves requirement

clarity.
Conceptual: They may lack security and optimisation.
Application: Designing a student registration interface.

Recommended Textbook Chapters

• Sommerville: Ch. 4–5 — Requirements Engineering

• Pressman: Ch. 5–7 — Requirements Analysis
• Pfleeger: Requirements chapters

Free Resources

• SWEBOK — Requirements Knowledge Area

• Volere Requirements templates (free online)

14
 TOPIC 6: SOFTWARE DESIGN FUNDAMENTALS

Introduction

Software design is the intellectual bridge between requirements and implementation. Once
user needs have been understood, engineers must decide how the system will be organised
before writing code. This planning stage determines system structure, responsibilities of
components, and interactions among them. Many software failures arise not from poor
algorithms but from weak design decisions that create tangled logic, difficult maintenance,
and unreliable behaviour.

Design is therefore a core engineering activity involving analysis of constraints, evaluation

of alternatives, and justification of decisions. It shapes system qualities such as reliability,
scalability, maintainability, and performance.

Conceptual Explanation

Software design defines how a system will be structured. It focuses on responsibilities,

interfaces, and organisation rather than syntax or programming language constructs. A key
principle is the separation of concerns, which ensures that different system responsibilities
are handled independently. For example, user interface logic should be separated from
business rules and data storage.

Modularity

Modularity divides a system into self-contained units called modules. Each module performs
a specific function and communicates through well-defined interfaces. Effective modular
design relies on:

• High cohesion (modules focus on a single purpose)

• Low coupling (modules depend minimally on each other)

This approach improves understanding, facilitates teamwork, simplifies testing, and reduces
maintenance effort.

Decomposition

Decomposition involves breaking complex systems into manageable parts based on logical
responsibilities. Proper decomposition prevents arbitrary divisions and ensures that system
structure reflects functional needs.

High-Level vs Low-Level Design

High-level design describes major subsystems and their interactions, answering the question,
“How is the system organised?” Low-level design provides details of algorithms, data

15
structures, and internal module logic. Weak high-level design often leads to poor system
quality regardless of low-level correctness.

Illustration
Consider a university portal system. A well-designed structure might separate:

• Presentation layer for student interfaces

• Application logic for registration rules
• Data layer for student records

Without this separation, changes in one area may affect others, increasing maintenance
difficulty.

Applications

Good design:

• Enables easier system modification

• Improves reliability and scalability
• Enhances testability
• Reduces lifecycle cost

Design decisions influence system longevity and adaptability, making them critical
engineering responsibilities.

Summary

Software design transforms requirements into structured solutions. By applying principles

such as modularity and separation of concerns, engineers control complexity and produce
maintainable systems.

Exercises

Short Answer

1. Define software design.

2. What is modularity?
3. Distinguish between high-level and low-level design.

Conceptual

1. Explain why functional correctness alone is insufficient for good design.

2. Discuss the relationship between cohesion and coupling.

16
Application

Design a modular structure for an online food delivery platform operating in [Link]
Answers

Software design structures solutions; modularity divides systems into independent units;
high-level defines structure, while low-level defines logic.
Conceptual: Systems may work but be difficult to maintain; high cohesion and low
coupling improve quality.
Application: Separate ordering interface, payment processing, delivery coordination, and
database modules.

Recommended Textbook Chapters

• Pressman: Modelling and UML chapters

• Schach: OO modelling sections
• Pfleeger: Design and modelling chapters

Free Resources

• Visual Paradigm UML tutorials

• Lucidchart UML guides

UML official documentation (OMG)

17
 TOPIC 7: SOFTWARE ARCHITECTURE

Introduction

While design addresses module-level organisation, software architecture focuses on system-

wide structure. Architecture describes major subsystems, their responsibilities, and
interactions. It represents the blueprint guiding development and evolution. Architectural
decisions are difficult to change and therefore have a long-term impact on system success.

Conceptual Explanation

Software architecture helps control complexity, manage risks, and support scalability. It
answers fundamental questions about system organisation and distribution of
responsibilities.

Architectural Styles

Common styles include:

Layered Architecture
Divides the system into hierarchical layers such as presentation, logic, and data. Each layer
interacts only with adjacent layers, simplifying maintenance.

Client–Server Architecture
Clients request services while servers provide them. This model supports centralised data
management and multiple users.

Distributed Architecture
System components operate across multiple machines, improving scalability and reliability
but introducing network complexity.

Benefits

Good architecture:

• Reduces system risk

• Supports growth and scalability
• Enhances maintainability
• Prevents large-scale failures

Poor architecture leads to performance bottlenecks, security vulnerabilities, and costly

redesign.

18
Illustration

A national examination portal may use layered architecture for clarity, client–server
architecture for web access, and distributed architecture to support nationwide usage.
Architectural choices determine whether the system handles peak loads effectively.

Applications

Architectural design is crucial for banking platforms, telecommunications systems, e-

government portals, and intelligent urban systems.

Summary

Software architecture defines the overall structure of a system and shapes its long-term
behaviour. Thoughtful architectural decisions are essential for dependable large-scale
systems.

Exercises

Short: Define software architecture; list one architectural style.

Conceptual: Why are architectural decisions difficult to change?
Application: Suggest an architecture for an online voting system.

Model Answers

Architecture is a system-wide structure; layered architecture; decisions affect the entire

system.
Application: Client–server with layered components for security and scalability.

Recommended Textbook Chapters

• Sommerville: Design chapters

• Pressman: Design engineering
• Mall: Software Design chapter

Free Resources

• Refactoring Guru (design principles explained simply)

• Clean Code summary materials (educational blogs)

19
 TOPIC 8: SOFTWARE IMPLEMENTATION AS AN ENGINEERING ACTIVITY

Introduction

Implementation translates design into working code. However, coding is not merely writing
instructions; it is an engineering activity requiring discipline, structure, and communication.
Code reflects design decisions and becomes a long-term asset maintained by multiple
developers.

Conceptual Explanation

Implementation involves understanding architecture, respecting module boundaries, and

preserving design structure. Good implementation emphasises readability, maintainability,
and reliability.

Readable Code

Readable code uses meaningful naming, consistent formatting, and simple logic. Because
maintenance often lasts longer than development, clarity reduces future errors and costs.

Structured Implementation

Breaking code into functions and modules maintains separation of concerns and simplifies
testing. Poor implementation may destroy good design by introducing unnecessary
dependencies.

Version Control

Version control systems manage changes, track history, and coordinate teamwork. They
allow recovery of previous versions and documentation of evolution.

Debugging

Debugging is a systematic diagnosis of defects involving observation, fault isolation, root

cause identification, correction, and verification.

Illustration

A software team building a ride-hailing platform must use version control to coordinate
contributions from multiple developers and maintain code quality over time.

Applications

Implementation practices influence maintainability, reliability, and system longevity.

Disciplined coding supports scalability and reduces technical debt.

20
Summary

Implementation converts plans into reality while preserving design integrity. Engineering
discipline during coding ensures clarity, reliability, and long-term system sustainability.

Exercises

Short: Define software implementation; state one benefit of readable code.

Conceptual: Why is version control essential in teamwork?
Application: Describe debugging steps for a faulty payment transaction.

Model Answers

Implementation translates design into code; readability reduces maintenance errors;

version control manages collaboration.
Application: Observe error, isolate module, identify root cause, fix, and verify.

Recommended Textbook Chapters

• Sommerville: Architectural Design

• Pressman: Architecture modelling
• Engineering Software Products: Architecture & microservices

Free Resources

• Microsoft architecture guides (free)

Martin Fowler architecture articles

21
 TOPIC 9: SOFTWARE TESTING AND QUALITY ASSURANCE

Introduction

Software testing is an engineering activity that verifies whether a system behaves as

intended and satisfies specified requirements. In professional practice, testing is not an
optional phase added at the end of development; it is an integral quality assurance process
embedded throughout the lifecycle. Because software systems influence finance, healthcare,
education, and public infrastructure, testing protects users, organisations, and society from
the consequences of defects.

A useful mindset for students is that untested software is incomplete engineering work. A
program may compile and produce results yet still contain hidden faults that appear only
under unusual inputs, heavy loads, or real-world usage conditions.

Conceptual Explanation

Testing exists because defects may arise from requirements misunderstandings, design
errors, or implementation mistakes. A defect (bug) is a flaw in design or code, while a failure
occurs when the system exhibits incorrect behaviour during execution. Not all defects
immediately cause failures; some remain dormant until triggered.

Levels of Testing

Unit Testing verifies individual modules or functions. Developers confirm that internal
logic behaves correctly in isolation.
Integration Testing evaluates interactions among modules, ensuring correct data flow and
interface compatibility.
System Testing examines the complete system against functional and non-functional
requirements such as performance, reliability, and usability.

Test Cases

A test case specifies inputs, expected outputs, and execution conditions. Testing compares
actual behaviour with expected behaviour defined in requirements. Any mismatch
indicates a defect.

Quality Beyond Correctness

Software quality includes robustness, usability, reliability, and performance. A system

producing correct output but crashing under unexpected input or confusing users cannot be
considered high quality.

22
Illustration

Consider an online result-checking portal used by examination bodies. Unit testing may
verify score calculation logic, integration testing ensures database retrieval works correctly,
while system testing confirms the portal handles thousands of simultaneous users during
result release.

Applications

Testing improves reliability, reduces maintenance costs, and protects users from system
failure. It is essential for financial platforms, e-learning systems, and public service
applications.

Summary

Software testing is a systematic verification process that detects defects early, enhances
reliability, and ensures engineering responsibility.

Exercises

Short Answer

1. Define software testing.

2. Distinguish between defect and failure.
3. Mention one testing level.

Conceptual

1. Why is testing required even if the code compiles successfully?

2. Explain the importance of test cases.

Application

Suggest testing strategies for a mobile airtime recharge application.

Model Answers

Testing verifies behaviour; a defect is a fault, while failure is incorrect behaviour; unit testing.
Conceptual: Compilation does not guarantee correctness; test cases provide systematic
verification.
Application: Unit tests for recharge logic, integration tests for payment gateway, system tests
for user experience.

23
Recommended Textbook Chapters

• Pressman: Implementation & configuration management

• Sommerville: Development and configuration management
• Jalote: Software configuration management

Free Resources

• Git documentation (official)

• GitHub learning lab
• Atlassian Git tutorials

24
 TOPIC 10: SOFTWARE MAINTENANCE AND EVOLUTION

Introduction

Software engineering does not end at deployment. Systems must evolve to remain useful as
requirements change, technologies advance, and defects are discovered. Maintenance,
therefore, represents a major portion of software lifecycle effort and cost.

Conceptual Explanation

Software maintenance involves modifying deployed systems to correct defects, adapt to

new environments, or enhance functionality. Three main types exist:

• Corrective Maintenance: Fixing defects and failures.

• Adaptive Maintenance: Adjusting systems to new environments or technologies.
• Perfective Maintenance: Enhancing performance, usability, or functionality.

Maintenance dominates lifecycle cost because systems often operate for many years while
requirements and technologies evolve. Early design decisions significantly influence
maintenance difficulty.

Technical Debt

Technical debt refers to shortcuts taken during development that increase future
maintenance effort. While sometimes unavoidable, unmanaged technical debt accumulates
and degrades system quality.

Illustration

A school management system initially designed for desktop use may later require mobile
access and cloud deployment. Adaptive maintenance supports this transition, while
perfective maintenance improves interface usability based on user feedback.

Applications

Maintenance ensures system longevity, adaptability, and continuous value delivery.

Engineers must design systems expecting change rather than assuming permanence.

Summary

Software evolution is inevitable. Effective maintenance practices sustain system usefulness

and protect long-term investment.

25
Exercises

Short: Define maintenance; list one type.

Conceptual: Explain technical debt.
Application: Suggest maintenance needs for a digital library system.

Model Answers

Maintenance modifies deployed software; corrective maintenance; technical debt is the

future cost of shortcuts.
Application: Fixing search bugs, adapting to new formats, and improving the user interface.

Recommended Textbook Chapters

• Sommerville: Validation & Testing

• Pressman: Testing strategies
• Pfleeger: Quality and testing

Free Resources

• ISTQB glossary (free)

• Guru99 software testing tutorials
• Ministry of Testing resources

26
 TOPIC 11: HUMAN, ETHICAL, AND PROFESSIONAL ISSUES

Introduction

Software engineering decisions influence people, organisations, and society. Engineers must
therefore consider usability, security, privacy, and professional ethics. Technical
competence alone is insufficient without social responsibility.

Conceptual Explanation

Human Factors

Users may make mistakes or misinterpret instructions. Systems must therefore prioritise
usability, accessibility, and error tolerance.

Security and Privacy

Engineers are responsible for protecting systems from attacks and safeguarding sensitive
data. Ethical data handling and responsible storage are essential professional obligations.

Professional Ethics

Ethical practice requires honesty, avoidance of negligence, and prioritisation of public

interest. Engineers are accountable when system failures cause harm or violate ethical
standards.

Illustration

A mobile banking application handling customer data must ensure confidentiality and secure
authentication. Failure to protect user data could result in financial loss and erosion of trust.

Applications

Ethical awareness guides the responsible design of AI systems, digital payment platforms,
and public service software.

Summary

Software engineering integrates technical expertise with ethical responsibility and social
awareness.

Exercises

Short: Define professional ethics; mention one ethical responsibility.

Conceptual: Why is usability an ethical concern?
Application: Suggest ethical considerations for a student data management system.
27
Model Answers

Ethics involve responsible conduct, protecting user data; poor usability may cause harm.
Application: Privacy protection, data accuracy, secure access control.

Recommended Textbook Chapters

• Sommerville: Software Evolution

• Pressman: Maintenance and reengineering
• Engineering Software Products: DevOps awareness

Free Resources

• DevOps Handbook summaries

• AWS DevOps learning resources
• Atlassian DevOps tutorials

28
 TOPIC 12: CASE STUDIES AND SOFTWARE ENGINEERING IN THE REAL WORLD

Introduction

Case studies provide a vital bridge between software engineering theory and professional
practice. While theoretical concepts explain processes, models, and techniques, case studies
reveal how these ideas operate in real environments characterised by constraints,
uncertainties, and evolving requirements. By analysing real successes and failures, students
gain insight into cause–and–effect relationships that abstract explanations alone cannot
convey.

This topic also highlights the transition from academic programming to professional
software engineering. Whereas student programming often focuses on producing working
code, real-world software engineering emphasises reliability, scalability, maintainability,
and long-term system evolution. Understanding this distinction prepares students for
industry practice and lifelong professional growth.

Conceptual Explanation

Real-world software systems succeed or fail based on engineering decisions made across the
lifecycle. Common causes of failure include:

• Poorly defined or misunderstood requirements

• Weak architectural planning
• Inadequate testing and quality assurance
• Insufficient scalability considerations
• Neglect of maintenance and evolution

Conversely, successful systems typically demonstrate:

• Clear and validated requirements

• Thoughtful architectural design
• Comprehensive testing strategies
• Continuous maintenance and improvement
• Strong project management and stakeholder engagement

Case studies reinforce the insight that software success depends not only on technical
correctness but also on disciplined processes, engineering judgement, and contextual
awareness.

In addition, professional software engineering extends beyond system delivery. Engineers

must continuously update skills, adapt to emerging technologies, collaborate within teams,
and uphold professional and ethical standards. Software engineering, therefore, represents
both a technical discipline and a professional responsibility.

29
Illustration

An online admission portal that crashes during peak application periods illustrates the
consequences of inadequate scalability planning and performance testing. Although the
system may function correctly under normal load, failure to anticipate high user demand
results in service disruption and user frustration.

In contrast, many fintech platforms demonstrate the benefits of disciplined software

engineering. These systems often employ scalable architectures, rigorous testing practices,
and continuous monitoring to ensure reliable service delivery under high transaction
volumes.

Within Nigeria’s evolving digital ecosystem, examples such as e-learning platforms, digital
payment systems, and smart urban services highlight the growing relevance of robust
software engineering practices. These systems illustrate how engineering discipline
supports reliability, trust, and long-term sustainability.

Applications

The integration of case study analysis with real-world professional awareness enables
students to:

• Anticipate risks in software projects

• Learn from past successes and failures
• Apply engineering principles to complex systems
• Understand professional expectations in industry environments
• Prepare for advanced study and participation in large-scale development

This topic also emphasises that software engineering education provides a foundation rather
than an endpoint. Continuous learning, adaptation, and professional growth remain essential
throughout an engineer’s career.

Summary

Case studies strengthen engineering judgement by connecting theoretical knowledge with

real-world experience. They demonstrate that software success depends on sound
requirements, effective design, rigorous testing, and long-term maintenance planning. At the
same time, the realities of modern software development highlight the importance of lifelong
learning, teamwork, and professional responsibility. Software engineering is therefore both
a technical discipline and a continuing professional journey.

30
Exercises

Short Answer

1. Define a software engineering case study.

2. State one difference between student programming and professional software
engineering.

Conceptual Questions

1. Why do many software systems fail despite technically correct code?

2. Explain why lifelong learning is necessary in software engineering.

Application Questions

1. Identify lessons from a failed online registration system.

2. Outline skills needed for a career in large-scale software development.

Model Answers (Guide)

• A case study examines real software systems to connect theory with practice.
• Professional software engineering emphasises reliability, scalability, and
maintainability beyond functional correctness.
• Many systems fail due to weak processes, poor requirements, and inadequate testing
rather than coding errors.
• Lifelong learning is necessary because technologies, methodologies, and system
requirements continuously evolve.
• Lessons from system failures include the need for scalability planning, robust testing,
and architectural foresight.
• Essential career skills include teamwork, design thinking, testing competence,
architectural awareness, and effective communication.

Recommended Textbook Chapters

• Pressman: Case studies and project examples

• Pfleeger: Real-world project discussions
• Mythical Man-Month: Project management lessons

Free Resources

• Google engineering blog

• Netflix tech blog
• Microsoft engineering case studies

31
 FURTHER READING (ORDERED BY IMPORTANCE & EASE OF UNDERSTANDING)

1. Sommerville, I. (2016). Software engineering (10th ed.). Pearson.

[Link]
engineering/P200000003163

2. Mall, R. (2014). Fundamentals of software engineering (4th ed.). PHI Learning.

[Link]
software-engineering-rajib-mall

3. Pressman, R. S., & Maxim, B. R. (2020). Software engineering: A practitioner’s

approach (9th ed.). McGraw-Hill.

[Link]
approach-pressman-maxim/[Link]

4. Pfleeger, S. L., & Atlee, J. M. (2010). Software engineering: Theory and practice (4th
ed.). Prentice Hall.

[Link]
practice/P200000003365

5. Sommerville, I. (2019). Engineering software products: An introduction to modern

software engineering. Pearson.

[Link]
products/P200000003221

6. Jalote, P. (2005). An integrated approach to software engineering (3rd ed.).

Springer.

[Link]

7. Schach, S. R. (2011). Object-oriented and classical software engineering (8th ed.).

McGraw-Hill.

[Link]
engineering-schach/[Link]

8. IEEE Computer Society. (2014). Guide to the software engineering body of

knowledge (SWEBOK V3.0). IEEE.

[Link]

32
9. Kernighan, B. W., & Pike, R. (1999). The practice of programming. Addison-Wesley.

[Link]
programming/P200000003256

10. Brooks, F. P. (1995). The mythical man-month: Essays on software engineering.

Addison-Wesley.

[Link]
month/P200000003146

33