Software Engineering and Application Development

Introduction

Software has become the operational foundation of modern organisations. Banking, healthcare, education, manufacturing, government, transport and entertainment all depend on applications that are reliable, secure, maintainable and adaptable. Developing such applications is not simply a matter of writing code. It requires disciplined requirements analysis, architectural design, programming, testing, deployment, monitoring and continuous improvement.

Software engineering is the systematic application of engineering principles to the specification, development, operation and maintenance of software. Application development is the practical process through which software products are conceived, designed, implemented and delivered. At Advanced Diploma level, students should be able to connect programming principles with professional development practices, including object-oriented design, web and mobile architectures, APIs, version control, testing, secure coding, Agile methods, continuous integration and DevOps.

Learning Objectives

By the end of this chapter, students should be able to:

• explain the software development life cycle and compare development approaches;
• apply object-oriented principles to application design;
• distinguish major web and mobile architectures;
• design and consume APIs responsibly;
• use version control and collaborative branching practices;
• select appropriate testing techniques and interpret test results;
• identify common secure-coding risks and suitable controls;
• explain Agile, continuous integration, continuous delivery and DevOps;
• evaluate application quality, maintainability and operational risks;
• propose an integrated development approach for a realistic project.

1. Software Engineering as a Discipline

A software system has at least three dimensions: functionality, quality and operational context. Functionality describes what the system does. Quality attributes describe how well it does it, including performance, security, usability, reliability, maintainability and scalability. Operational context includes users, legal requirements, infrastructure, business processes and other systems.

A useful distinction is between functional requirements and non-functional requirements. A functional requirement might state that a library system shall allow a member to reserve a book. A non-functional requirement might state that reservation searches shall respond within two seconds for 95 percent of requests under the expected workload. Both are necessary: an application that provides features but loses data or exposes passwords is not successful.

Important quality attributes include:

The software development life cycle (SDLC) normally includes requirements, analysis, design, implementation, testing, deployment and maintenance. These activities are not always strictly sequential. In iterative development, each cycle produces a usable increment and revisits earlier decisions as new evidence becomes available.

Development approaches

The waterfall model proceeds through relatively distinct phases. It can be appropriate when requirements are stable, regulation requires extensive documentation, or physical dependencies make change expensive. Its weakness is that users may not see working software until late in the project.

Agile development treats software development as an adaptive, incremental activity. Work is prioritised in a product backlog, developed in short iterations, demonstrated to stakeholders and revised using feedback. Agile does not mean the absence of planning or documentation; it means that plans and documentation are proportionate and responsive to evidence.

Spiral development emphasises repeated risk analysis. Each cycle identifies major risks, investigates alternatives and develops an appropriate solution. It is useful for technically uncertain or high-risk systems, although it can be demanding to manage.

A professional team chooses a process according to risk, regulation, team capability, product uncertainty and delivery constraints rather than adopting a method by fashion.

2. Programming Principles and Object-Oriented Design

Good programming is concerned with more than making code execute. Code should express a clear model of the problem, isolate change, avoid unnecessary duplication and be understandable to other developers.

Core programming principles

• Abstraction represents essential characteristics while hiding irrelevant detail.
• Encapsulation places data and the operations that protect it within a controlled boundary.
• Modularity divides a system into components with clear responsibilities.
• Separation of concerns prevents unrelated responsibilities from becoming tightly coupled.
• DRY (Don't Repeat Yourself) reduces duplicated knowledge, although forced abstraction can be worse than limited repetition.
• KISS (Keep It Simple) encourages solutions whose complexity is justified by requirements.
• Defensive programming validates assumptions and handles invalid input and failure conditions explicitly.

In object-oriented programming, a class defines the structure and behaviour of objects, while an object is a runtime instance of a class. Encapsulation is commonly implemented through controlled access to fields and methods. Inheritance allows a specialised class to reuse or extend a general class, but excessive inheritance can create rigid dependencies. Polymorphism allows different object types to respond to a common interface in type-specific ways.

Composition is often preferred to inheritance. For example, a ReportService can contain a Formatter object rather than inheriting from every possible formatter. This permits a formatter to be replaced without changing the reporting service.

Design principles and patterns

The SOLID principles provide guidance for maintainable object-oriented designs:

• Single Responsibility Principle: a class should have one principal reason to change.
• Open–Closed Principle: software entities should be open for extension but closed for unnecessary modification.
• Liskov Substitution Principle: a subtype should be usable wherever its declared supertype is expected without breaking correctness.
• Interface Segregation Principle: clients should not depend on interfaces containing methods they do not use.
• Dependency Inversion Principle: high-level policy should depend on abstractions rather than concrete implementation details.

Design patterns are recurring solutions, not mandatory templates. The Factory pattern centralises object creation; Strategy allows an algorithm to be selected at runtime; Observer supports notification of dependent objects; and Repository separates domain logic from data-access mechanisms. Patterns should be used when they reduce complexity, not merely to make a design appear sophisticated.

A layered application commonly separates presentation, application or service logic, domain logic and data access. This arrangement improves testing and allows a database or user interface to change with less effect on business rules. However, poorly designed layers can become pass-through code that adds ceremony without real separation.

3. Web and Mobile Application Architectures

A web application usually involves a client, a network and one or more servers. In a traditional server-rendered architecture, the server generates HTML for each request. In a single-page application, the browser downloads application code and communicates with backend services, often using JSON. Hybrid systems combine both approaches.

A typical web request follows this sequence:

1. The client constructs a request containing a method, URL, headers and possibly a body.
2. The request passes through network infrastructure and reaches an application endpoint.
3. The server authenticates and validates the request.
4. Application logic retrieves or changes data.
5. The server returns a status code, headers and a response body.
6. The client presents the result or handles an error.

HTTP methods communicate intended operations. GET retrieves a representation, POST commonly creates a subordinate resource or requests an action, PUT replaces a resource representation, PATCH partially updates it, and DELETE requests removal. A service should use status codes consistently: 2xx indicates success, 4xx generally indicates a client or request problem, and 5xx indicates a server-side failure.

A REST-style API exposes resources through uniform URLs and HTTP semantics. REST is not merely “JSON over HTTP”; it also values stateless interactions, cacheability where appropriate and a uniform interface. An API contract should document authentication, resources, schemas, validation rules, pagination, error formats, rate limits and versioning.

GraphQL provides a schema through which clients request selected fields. It can reduce over-fetching but requires careful controls for query complexity and authorisation. Event-driven architectures use messages or events so producers and consumers can be decoupled. They can improve resilience and scalability, but introduce concerns such as eventual consistency, duplicate messages and ordering.

Mobile architecture

Mobile applications commonly use a layered or clean architecture consisting of a user-interface layer, presentation or state-management layer, domain services and data sources. A mobile application may be:

• native, built specifically for an operating system;
• cross-platform, using a shared codebase that produces platform applications; or
• web-based or progressive, delivered primarily through browser technologies.

Important mobile constraints include limited battery, intermittent connectivity, changing screen sizes, privacy permissions, device loss and variable processing power. Applications should cache appropriate data, minimise unnecessary network requests, protect local secrets and provide useful offline or degraded behaviour where the business context permits it.

4. APIs and Data Integration

An API is a defined interface through which one software component requests capabilities or data from another. A sound API has a stable contract, explicit error behaviour and security controls. API design should begin with consumer needs and domain concepts rather than with database tables alone.

A typical response should distinguish success from failure without revealing sensitive implementation details. For example, a validation error may identify an invalid date, whereas an authentication failure should not disclose whether a username exists. API inputs must be validated for type, length, range, format and authorisation context.

Authentication establishes identity; authorisation determines permitted actions. Common approaches include session cookies, signed tokens and delegated authorisation frameworks such as OAuth 2.0. A token must have appropriate scope, lifetime and storage protection. Transport encryption using HTTPS protects data in transit, but it does not replace server-side authorisation or secure input handling.

API versioning can be implemented through URL paths, headers or compatible evolution. Breaking changes should be announced, documented and supported through a defined transition period. Rate limiting, audit logging and monitoring help protect public APIs from misuse and operational overload.

5. Version Control and Collaborative Development

Version control records changes to source code and associated artefacts. A distributed system such as Git gives each developer a local repository containing history, while a shared remote repository supports collaboration.

A commit should represent a coherent, tested change and should have a meaningful message. Developers should avoid committing passwords, private keys, generated build output or personal configuration. A .gitignore file reduces accidental inclusion, but it is not a security control if a secret has already entered repository history; exposed credentials must be revoked and replaced.

A team may use a short-lived feature-branch model, trunk-based development or a controlled release-branch model. Long-lived branches increase merge conflicts and delay integration. Pull requests provide a point for code review, automated checks and discussion. Review should evaluate correctness, security, maintainability, tests and alignment with requirements rather than merely formatting preferences.

A useful workflow is: update the local branch, create a focused branch, implement a small change, run local tests, commit, push, open a review, resolve findings, merge after required checks and monitor the resulting build or deployment.

6. Software Testing and Quality Assurance

Testing provides evidence about software behaviour; it cannot prove that a sufficiently complex system contains no defects. A mature quality strategy combines different test levels.

• Unit tests isolate a small function or class and execute quickly.
• Integration tests examine interactions with databases, queues or external components.
• System or end-to-end tests exercise a complete user or business flow.
• Acceptance tests assess whether stakeholder needs have been met.
• Regression tests detect reintroduced defects after change.
• Performance tests examine response time, throughput and resource use.
• Security tests look for weaknesses such as injection, broken access control and insecure configuration.

The test pyramid recommends many fast unit tests, fewer integration tests and a smaller number of expensive end-to-end tests. This is a heuristic, not a law: systems with complex integration boundaries may legitimately require substantial integration testing.

For a test result, distinguish a software failure from a test-environment failure. Test cases should have clear preconditions, inputs, expected outcomes and cleanup. Boundary-value analysis tests values at and around limits. Equivalence partitioning divides inputs into classes expected to behave similarly. Property-based testing checks general properties over many generated inputs.

A simple test coverage percentage can be calculated as:

Here, “items” might mean statements, branches or requirements. The measure is meaningful only when the item definition is stated. High statement coverage does not guarantee good assertions, adequate security tests or correct requirements.

7. Secure Coding

Secure software protects confidentiality, integrity and availability while respecting privacy and legitimate use. Security should be addressed throughout the SDLC, not added immediately before release.

Common controls include:

• validate input on the server, using allow-lists where practical;
• use parameterised queries or safe data-access libraries to prevent injection;
• encode output according to its context to reduce cross-site scripting;
• apply authentication and least-privilege authorisation on every protected operation;
• use approved cryptographic libraries rather than inventing algorithms;
• hash passwords with a modern, deliberately slow password-hashing algorithm and unique salts;
• protect secrets with a managed secret store;
• log security-relevant events without recording passwords, tokens or unnecessary personal data;
• configure secure headers, dependency updates, backups and recovery procedures;
• model threats before implementation and review them after architectural change.

A key principle is that client-side checks improve user experience but cannot enforce trust. A malicious client can bypass them, so the server must repeat validation and authorisation. Error messages should support legitimate diagnosis without exposing stack traces, database details or internal credentials.

Security also has ethical and governance dimensions. Teams must minimise personal-data collection, define retention periods, obtain appropriate consent where required, respect accessibility obligations and investigate vulnerabilities responsibly. Regulatory requirements vary by jurisdiction and sector, so developers should consult organisational policy and applicable law rather than assuming that a technical control alone establishes compliance.

8. Agile, CI/CD and DevOps

Agile development uses frequent delivery and stakeholder feedback to manage uncertainty. A product owner or equivalent role prioritises value; developers and testers build quality into increments; stakeholders inspect results. Scrum is one Agile framework, with events such as planning, daily coordination, review and retrospective. Kanban focuses on visualising workflow, limiting work in progress and improving flow. These frameworks are tools, not substitutes for engineering competence.

Continuous integration (CI) means that changes are integrated frequently and automatically built and tested. Continuous delivery keeps software in a releasable state, while continuous deployment automatically releases validated changes to production. A pipeline may contain source checkout, dependency installation, static analysis, unit tests, integration tests, packaging, security checks, deployment to a test environment and controlled promotion.

DevOps extends beyond tools. It promotes shared responsibility among development, operations, security and business teams. Infrastructure as code makes environments repeatable. Observability combines logs, metrics and traces to help teams understand runtime behaviour. Deployment strategies include blue-green deployment, in which traffic switches between two environments, and canary release, in which a small user segment receives a change before wider rollout.

Useful operational measures include deployment frequency, lead time for changes, change failure rate and time to restore service. Metrics should encourage learning rather than blame; otherwise teams may hide failures or optimise numbers at the expense of users.

9. Applied Case: Illustrative Community Clinic Platform

Background

A community clinic uses paper forms and disconnected spreadsheets for appointments, patient notifications and staff scheduling. The clinic wants a secure web and mobile-accessible platform.

Problem analysis

The system must support appointment search, booking, cancellation, reminders and role-based access. Personal and health-related information makes confidentiality essential. Requirements are initially incomplete because reception staff, clinicians and patients have different workflows.

Approach and solution

The team begins with stakeholder interviews and maps the appointment domain. It chooses a modular web architecture with a browser client, a REST-style service layer and a relational database. The domain model separates patients, appointments, practitioners and notification preferences. A repository abstraction isolates persistence, while a notification strategy supports email and text providers.

The team defines API contracts before implementation. Requests are validated server-side, access is checked against the user's role, and sensitive fields are excluded from general appointment responses. Passwords are stored using an approved password-hashing service; transport uses HTTPS; secrets are stored outside source control. Audit events record access to sensitive records without storing unnecessary clinical content.

Work is divided into small increments. Each pull request runs formatting checks, static analysis, unit tests and integration tests against an isolated test database. Acceptance tests verify that a patient cannot view another patient's appointment. A staging deployment uses synthetic data, and a canary release is monitored before full production deployment.

Outcome

The illustrative system reduces duplicate bookings and gives staff a shared schedule. More importantly, the team can demonstrate traceability from requirements to tests, controlled access to information and a repeatable release process. Remaining risks include dependence on external notification services, data recovery, device security and the need for continuing privacy reviews.

Learning points

The case demonstrates that architecture, security, testing and operations are interconnected. A technically elegant API would still be unacceptable without authorisation. Automated deployment would still be dangerous without reliable tests and rollback. Agile delivery is effective because it exposes workflow problems early, not because it removes the need for analysis.

10. Challenges, Limitations and Contemporary Practice

Software projects face uncertainty in requirements, technical dependencies, staffing, legacy systems and organisational priorities. Technical debt is the future cost created by expedient decisions, obsolete dependencies or insufficient tests. Debt is sometimes deliberate and rational, but it should be recorded, monitored and repaid where it threatens safety or delivery.

Cloud platforms, containers, serverless functions and managed services can accelerate delivery, but they create new responsibilities concerning cost, vendor dependence, data location, identity management and observability. Artificial intelligence tools can assist with code completion, test generation, documentation and defect investigation. They can also produce insecure, incorrect or legally problematic output. Generated code must undergo human review, testing, dependency analysis and licensing assessment. Confidential source code or personal data should not be entered into an AI service unless organisational controls explicitly permit it.

Best practice is therefore a socio-technical process: clarify the problem, design for change, automate repeatable checks, protect users, measure real outcomes and learn from production evidence. No single framework guarantees quality. Quality results from appropriate engineering judgement applied consistently.

Chapter Summary

Software engineering applies systematic principles to the complete life cycle of software. Effective application development combines requirements analysis, architecture, programming, testing, deployment and maintenance. Object-oriented concepts such as encapsulation, abstraction, composition and polymorphism support modular designs when used carefully. Web and mobile systems require attention to protocols, state, connectivity, performance and platform constraints.

APIs provide contracts between components and must address validation, authentication, authorisation, versioning and operational protection. Version control enables traceable collaboration, while code review and automated checks improve integration quality. Testing should combine unit, integration, system, acceptance, performance and security techniques; coverage is useful only when interpreted correctly.

Secure coding requires least privilege, safe data handling, protected secrets, appropriate cryptography and privacy-aware governance. Agile methods manage uncertainty through incremental delivery and feedback. CI/CD automates integration and release activities, while DevOps joins development, operations and security around shared responsibility, observability and reliable recovery. The central professional principle is that software quality is designed and evidenced throughout the life cycle, not inspected into a finished product.

Key Terms

Software engineering: Systematic application of engineering principles to software development and operation.

Functional requirement: A statement of behaviour or capability the system must provide.

Non-functional requirement: A constraint or quality expectation concerning how a system operates.

SDLC: The software development life cycle from requirements through maintenance.

Abstraction: Representation of essential features while hiding unnecessary detail.

Encapsulation: Bundling data and behaviour behind a controlled interface.

Polymorphism: Ability to use different implementations through a common type or interface.

Composition: Building a class from collaborating objects rather than relying primarily on inheritance.

API: A defined interface through which software components communicate.

REST: An architectural style emphasising resources, uniform interaction and stateless communication.

Authentication: Process of establishing the identity of a user or system.

Authorisation: Process of determining what an authenticated identity may do.

Version control: System for recording and managing changes to files and source code.

Regression test: Test that checks whether existing behaviour remains correct after change.

Threat modelling: Structured identification and analysis of security threats and controls.

Continuous integration: Frequent integration of changes with automated build and test checks.

Continuous delivery: Practice of keeping software ready for controlled release.

DevOps: Collaborative culture and practices joining development, operations and related disciplines.

Technical debt: Future cost created by expedient or insufficiently maintainable technical decisions.

Observability: Ability to understand internal system behaviour through outputs such as logs, metrics and traces.

Review Questions

Short Answer Questions

1. Distinguish between a functional requirement and a non-functional requirement.
2. What is the difference between authentication and authorisation?
3. State two advantages of using version control.
4. Why are unit tests generally faster than end-to-end tests?
5. What is the purpose of continuous integration?

Long Answer Questions

1. Compare waterfall, Agile and spiral development, including situations in which each may be appropriate.
2. Explain how object-oriented principles and SOLID principles contribute to maintainable software.
3. Describe the main components of a secure REST-style API.
4. Explain how a CI/CD pipeline can improve software quality and release reliability.
5. Discuss the relationship between software architecture, testing and operational monitoring.

Analytical / Application Questions

1. A university wants a mobile attendance application that must operate during intermittent connectivity. Propose an architecture and explain how you would address synchronisation, security and testing.
2. A team has frequent production defects despite reporting 95% test coverage. Analyse why the coverage figure may be misleading and recommend a broader quality strategy.
3. Design a development and deployment approach for an online health service. Identify major threats, governance concerns, API decisions, testing levels and a suitable release strategy.

Multiple Choice Questions with Answers

Question 1

Which statement best distinguishes a non-functional requirement?

A. The system shall allow users to reserve books.

B. The system shall create a patient record.

C. The system shall respond to 95% of searches within two seconds.

D. The system shall send an appointment reminder.

Correct Answer: C. The system shall respond to 95% of searches within two seconds.

Question 2

Which object-oriented principle allows different implementations to be used through a common interface?

A. Polymorphism

B. Compilation

C. Serialisation

D. Normalisation

Correct Answer: A. Polymorphism

Question 3

Which HTTP method is most commonly associated with retrieving a resource representation?

A. POST

B. GET

C. PATCH

D. DELETE

Correct Answer: B. GET

Question 4

What is the primary purpose of authorisation?

A. To encrypt network traffic

B. To establish a user's identity

C. To determine permitted actions

D. To compress an API response

Correct Answer: C. To determine permitted actions

Question 5

Which practice most directly helps prevent SQL injection?

A. Using parameterised queries

B. Increasing screen resolution

C. Adding more client-side buttons

D. Disabling version control

Correct Answer: A. Using parameterised queries

Question 6

What does continuous integration require teams to do?

A. Release every change directly to production

B. Integrate changes frequently with automated checks

C. Avoid automated testing

D. Maintain only one annual software release

Correct Answer: B. Integrate changes frequently with automated checks

Question 7

A test that checks interaction between an application and its database is usually classified as what?

A. Unit testing

B. Integration testing

C. Acceptance testing only

D. Usability testing only

Correct Answer: B. Integration testing

Question 8

If 80 of 100 defined test items have been exercised, what is the coverage according to the chapter's formula?

A. 0.8%

B. 8%

C. 80%

D. 125%

Correct Answer: C. 80%

Question 9

Why should client-side validation not be treated as a security control?

A. Clients cannot display error messages

B. A malicious client can bypass it

C. It always slows network traffic

D. It prevents server-side validation

Correct Answer: B. A malicious client can bypass it

Question 10

Which deployment strategy first exposes a release to a small proportion of users?

A. Canary release

B. Waterfall release

C. Big-bang deletion

D. Static linking

Correct Answer: A. Canary release