Learner Name

Learner Registration No.

Study Centre Name shabir
Qualification Title

Unit Reference No.

Unit Title Software Engineering

Submission Date

Declaration of authenticity:
1. I declare that the attached submission is my own original work. No significant part of it has been submitted for
any other assignment and I have acknowledged in my notes and bibliography all written and electronic sources
used.
2. I acknowledge that my assignment will be subject to electronic scrutiny for academic honesty.
3. I understand that failure to meet these guidelines may instigate the centre’s malpractice procedures and risk
failure of the unit and / or qualification.

_________________ _________________
Learner signature Tutor signature
Date: Date:

1
2
 Table of contents
Introduction: 2

1 Task 01: 2

2 Task 02: 2

3 Task 03: 2

4 Task 04: 2

Conclusion 2

References 2

Appendix 2

3
 Introduction:
Software-intensive systems increasingly mediate everyday activities, including banking,
transport ticketing, clinical check-ins, and university portals. Project failures are rarely rooted in
complex mathematics; they more commonly arise from ambiguous requirements, implicit
assumptions, brittle designs, inadequate testing, or the use of ill-suited processes. Established
engineering principles mitigate these risks. In practice, this entails specifying requirements
explicitly, modelling before construction, working in small, iterative increments, maintaining
bidirectional traceability from requirements to tests, and operating short feedback loops to
enable early correction. These practices provide analysts, developers, testers, and managers with
a shared language for evaluating trade-offs and they support future modification of systems
(ISO/IEC/IEEE 29148:2018; Schwaber and Sutherland, 2020; Forsgren, Humble and Kim,
2018).

This assignment operationalises these principles. Task 1 presents the rationale and methods for
disciplined engineering: pragmatic modelling, dependable test planning, and staged automation
that remains maintainable over time. Task 2 advances from concept to design by modelling an
Automated Teller Machine (ATM) using standard Unified Modelling Language (UML) and
implementing a small prototype consistent with the model, avoiding speculative or non-
verifiable artefacts. Task 3 applies the same principles to a simple, testable Simon game to
practise clean code, incremental development, and rapid verification (Schwaber and Sutherland,
2020; ISTQB, 2018).

The report is guided by two guardrails. First, fitness for purpose: the objective is dependable
software that operates without ad hoc intervention rather than aesthetic elegance alone. Second,
proportionality: effort should be commensurate with risk and cost. Low-stakes features may
require only a brief sketch and a modest set of tests; functionality that affects money or safety
warrants end-to-end traceability from requirement to test, more rigorous reviews, and auditable
evidence. Relevant standards support scaling these practices without excessive documentation—
for example, establishing baseline requirement sets with traceability (ISO/IEC/IEEE
29148:2018) and adopting practical patterns for test documentation (ISO/IEC/IEEE 29119-
3:2021).

Finally, speed and quality are complementary. Teams that work in small batches, integrate
frequently, and measure outcomes reliably tend to deliver faster and with greater stability.
Accordingly, this report emphasises iteration, automation, and evidence-based practice, as these
approaches are empirically associated with improved delivery performance and outcomes
(Forsgren, Humble and Kim, 2018).

4
 1 Task 01:
(a) Modelling languages and why they help
Modelling languages for shared understanding
Before implementation, stakeholders require a shared representation of the intended system.
Extended meetings and lengthy prose rarely achieve this alignment. Standardised modelling
languages address the problem by providing agreed notations for structure, behaviour, data, and
workflow—concise visual artefacts that analysts, developers, and testers can interpret
consistently (ISO/IEC/IEEE 29148:2018; ISO/IEC/IEEE 42010:2011).

Overview of commonly used

modelling languages

1. UML (general software design).

Core diagram families include use case, sequence, class, activity, state machine,
component, and deployment. Use cases identify actor goals; sequence diagrams show
interactions and ordering; class diagrams establish domain vocabulary; state machines
specify behaviour over time. UML remains pertinent because it integrates with broader
architecture-description practices (ISO/IEC/IEEE 42010:2011; OMG, 2017).
2. BPMN (business processes).
For software embedded within wider processes—e.g., onboarding, claims, refunds—
BPMN clarifies responsibilities (lanes), decisions (gateways), and inter-team hand-offs
(message flows) more directly than UML (Freund and Rücker, 2019).
3. ER and logical data models (data semantics).
When clarifying the meaning of entities (e.g., “customer”) or key placement, entity–
relationship (ER) models make semantics explicit prior to schema commitment
(Silberschatz, Korth and Sudarshan, 2019; Elmasri and Navathe, 2019).
4. Statecharts (reactive behaviour).
Where behaviour depends on current state—e.g., card inserted vs not, session active vs
timed out—statecharts reduce conditional complexity by naming states, events, guards,
and transitions (Van Mierlo, 2020).
5. SysML (software + hardware + procedure).
For kiosks, vehicles, or devices combining software, physical components, and operator
steps, SysML extends UML to cover requirements, constraints, allocations, and
parametrics (Holt and Perry, 2018; OMG, 2019).

Benefits for real system design

1. Shared understanding beyond the meeting.

A one-page use case for “Reset password,” supported by a concise main-flow sequence,
surfaces policy questions—attempt limits, lockout, OTP (One-Time Password) expiry—
before coding begins (ISO/IEC/IEEE 29148:2018).
2. Separation of concerns in reviews.
Each diagram answers a distinct question: class = what exists; sequence = how
collaborators interact; deployment = where it runs. Reviews remain focused rather than
conflating data indexing with user-journey decisions (Freund and Rücker, 2019;
Silberschatz, Korth and Sudarshan, 2019).
3. Earlier discovery of edge cases and risk.
Statecharts expose critical scenarios (e.g., card removal mid-withdrawal; network

5
 timeout after debit but before printing) at modelling time, when remediation is least
costly (Van Mierlo, 2020).
4. Traceability under change.
Linking use cases → interfaces/classes → test cases ensures that requirement changes
identify precisely which artefacts and tests are affected. Contemporary test-
documentation standards support lightweight, consistent traceability (ISO/IEC/IEEE
29119-3:2021).
5. Improved naming, APIs, and tests.
Modelling prompts explicit responsibilities and collaborations, yielding cohesive
modules and well-defined seams that are straightforward to test; sequence diagrams
often supply the initial test set (ISO/IEC/IEEE 29119-3:2021; ISO/IEC/IEEE
29148:2018).
6. Tooling support without lock-in.
Layout assistance, conformance checks, and optional skeleton generation improve
readability and alignment with the codebase while avoiding full code generation or
vendor dependence (OMG, 2017).
7. Proportional effort.
Decisions are delimited to the minimum necessary for near-term work, and unused
artefacts are discarded. Architecture-description guidance scales the practice without
excessive documentation (ISO/IEC/IEEE 42010:2011).

Illustrative example: ATM

 Use cases.
Actors: customer and technician. Customer actions: authenticate, view balance, withdraw
cash, (optional) deposit cash, print receipt. Technician actions: enter service mode,
replenish cash, run diagnostics, apply firmware update (Freund and Rücker, 2019).
Stable nouns include ATM, session, card, account, host bank, cash dispenser, receipt
printer, and transactions such as withdrawal and balance enquiry (Silberschatz, Korth
and Sudarshan, 2019; Elmasri and Navathe, 2019).
 Sequence (withdraw).
The customer inserts a card and enters a PIN (Personal Identification Number); the
system validates the PIN and funds; the account is debited; cash is dispensed; a receipt is
printed; the session ends.
 Activity (replenish cash).
Authorise technician → open panel → inspect cassettes → load cash → run diagnostics
→ log the action. This activity aligns with audit-trail and tamper-evidence requirements
(ISO/IEC/IEEE 29119-3:2021).

Common pitfalls and mitigations

 Over-modelling. Retain only diagrams that support real decisions; remove others.
 Non-standard notation. Use the conventional symbols and semantics of the chosen
language.
 Diagrams disconnected from code or tests. Integrate models into code inspection and
test-design activities.
 Neglect of non-functional requirements. Capture latency within sequences and
capacity within deployment early, not late (ISO/IEC/IEEE 29119-3:2021; ISO/IEC/IEEE
42010:2011).

6
(b) Software testing management across strategies

Testing as a portfolio
Software testing is not a single activity but a portfolio of complementary practices. To achieve a
release-ready product, an effective test manager composes a mix that balances product risk,
release cadence, and team capability, and then ensures that this mix operates effectively by
providing stable environments, representative data, rapid feedback, and clear ownership. The
objective is not to accumulate techniques, but to integrate them so that risks become visible
early and delivery remains uninterrupted (ISO/IEC/IEEE 29119-3:2021; Forsgren, Humble and
Kim, 2018).

Strategy landscape and key

variants
V-model (stage-aligned testing)

A disciplined cross-check maps requirements ↔ acceptance tests, architecture/design ↔ system

tests, and components ↔ unit tests. The approach is effective in controlled contexts because
traceability and audit trails are intrinsic. Its typical failure mode is slow feedback when stages
harden into rigid boundaries. Mitigations include short iteration loops, intentional overlap
between activities (e.g., test design while refining requirements), and lightweight templates that
link artefacts without bureaucratic coupling (ISO/IEC/IEEE 29119-3:2021; ISTQB, 2018).

Risk-based testing

Not all areas require equal depth. Rank features by impact × probability so that payment flows,
personal data, security, and regulatory processes receive proportionately greater coverage, while
low-risk areas receive limited sanity checks. A simple heat-map workshop (features × risks)
makes trade-offs explicit and reduces deadline-driven escalation. For highly sensitive areas, map
risks to recognised control sets to avoid generic checks (NIST, 2020; OWASP, 2021).

TDD (unit-level test-driven development)

Short red–green–refactor cycles provide a rapid safety net and encourage designs with small,
testable components. TDD does not replace higher-level testing; rather, it reduces regressions
and enables safer refactoring, particularly when combined with continuous integration and
structured code review policies (Farley, 2021; Forsgren, Humble and Kim, 2018).

BDD (behaviour-driven development at acceptance level)

Business and engineering collaborate on behaviour specified as Given–When–Then scenarios.

Automated scenarios operate as living checks with less drift than long-form prose, especially at
service/UI boundaries where ambiguity often arises. Effective BDD also promotes a shared,
domain-specific language for APIs and acceptance criteria (Smart, 2023).

Structured exploratory testing

Time-boxed human exploration, guided by charters and concise note-taking, surfaces emergent
issues—race conditions, UX defects, and state-management anomalies—that scripted tests
7
frequently miss. Treat it as a first-class activity with clear charters, optional observers, and brief
debriefs so that findings feed back into risk registers, test suites, and the backlog (ISTQB, 2018).

Continuous testing in CI/CD (Continuous Integration/Continuous Delivery)

Each pull request triggers automated suites, with merges blocked on failure. Fast unit and
API/contract tests run first; slower end-to-end and performance jobs run nightly or on demand.
The intent is early defect detection while the change remains cognitively fresh. Quarantine flaky
tests promptly; invest in reliable environments, secure secrets management, and seeded datasets.
Organisations that institutionalise these practices tend to deliver faster and with greater stability
(Forsgren, Humble and Kim, 2018; Capgemini, Sogeti and OpenText, 2023).

Product-type-specific mixes

 Web/API systems. Emphasise fast, high-signal unit tests; keep UI automation thin
(smoke/sanity). Apply risk-based depth to authentication, authorisation, and payments,
including rate-limiting and negative tests for error contracts (OWASP, 2021).
 Mobile applications. Add scenarios for offline/roaming, background/restore, battery
impact, and permissions. Use device-matrix planning, exploratory charters, and contract
tests between app and back end to stabilise CI.
 Data/analytics. Incorporate data contracts and quality checks (schemas, null rates,
distribution drift), functional tests, schema-break tests, and lineage/audit provisions.
 Embedded/edge. Rely on state-based testing, fault injection, static analysis, and
hardware-in-the-loop; specify deterministic test modes to control flakiness under real-
time constraints.

Cross-cutting levers

 Levels and exit criteria. Define unit, integration, system, and acceptance levels with
“done” criteria at each gate. Keep artefacts lightweight yet auditable (ISO/IEC/IEEE
29119-3:2021).
 Coverage with judgement. Use coverage to identify blind spots rather than to pursue
100 per cent. Combine with risk, complexity, and code churn; track critical-flow
coverage separately (ISTQB, 2018).
 Defect lifecycle. Log severity and priority, track mean time to detect/repair, and measure
escaped defects. Improve the system (processes, checks, tooling) as well as the
individual fix (Capgemini, Sogeti and OpenText, 2023).
 Environments and data. Require reproducible builds, predictable stacks, seeded
synthetic/anonymised data that exercise edge cases, and clear handling of personal data
and secrets (NIST, 2020).
 People. Pair developers and testers, teach exploratory skills, and embed domain
knowledge in onboarding; many failures arise from domain misunderstandings rather
than tooling gaps (ISTQB, 2018).
 Reporting. Prefer concise dashboards with trends for a few critical indicators—high-risk
journeys, performance budgets, escape rate—over numerous vanity metrics (Forsgren,
Humble and Kim, 2018).

A concise, realistic blend

A small team delivers a bill-payment feature for a banking application. They apply TDD to
calculation components; BDD scenarios for “pay bill”, “cancel”, “insufficient funds”, and

8
“timeout retry”; risk-based depth for fraud controls; exploratory charters for network loss and
backgrounding; a thin UI smoke in CI; and a broader API regression suite nightly. They define a
performance budget (for example, API p95 < 300 ms) and use a canary rollout with error-budget
monitoring. The result is fast developer feedback, credible assurance for the business, and fewer
post-release issues, supported by traceable evidence aligned to recognised control frameworks
and test-documentation standards (ISO/IEC/IEEE 29119-3:2021).

(c) System testing stages and the role of automation tooling

System testing: practical flow and effective automation

System testing is most effective when executed as a simple, repeatable workflow recognised
across the team. Its aims are to surface risk early, gather trustworthy evidence, and maintain
feedback that is sufficiently rapid to influence the current release rather than the next. The stages
below are followed by an evidence-based view of where automation provides the greatest value.

Stages of system testing

(practical flow)

1. Planning
Define the objectives (which risks are being reduced), scope and responsibilities,
environments, data strategy, and exit criteria. Specify in advance how “pass” will be
determined; for example: no open critical defects, core journeys passing, and p95 latency
within the agreed budget. Keep the plan concise and use lightweight templates that map
cleanly to audits and handovers. Standards such as ISO/IEC/IEEE 29119-3:2021
provide sufficient structure without excessive paperwork.
2. Design
Derive tests from models and user scenarios. Cover input ranges using equivalence
classes and boundary values; include negative and recovery cases; state the test oracles
clearly (expected outcomes, contracts, invariants). Treat traceability as an enabler rather
than a bureaucracy by linking scenarios to tests so that changes propagate consistently.
3. Environment and data set-up
Control code, versions, and datasets. Where full integration is unnecessary, stub or
virtualise volatile dependencies. Plan observability (logs, metrics, traces) as a first-class
element of the suite; a failing test without diagnostic signal is not useful. Record controls
for secrets and personal data if realistic data is used.
4. Execution
Triage quickly, repair failing suites, and document defects clearly with supporting
evidence. Tag tests (smoke, regression, high-risk) to allocate resources efficiently: fast
checks on each run, heavier suites nightly. Short feedback loops within CI/CD
(continuous integration/continuous delivery) are consistently associated with faster and
more stable delivery (Forsgren, Humble and Kim, 2018).
5. Defect management
Reproduce → fix → re-test. Record severity and priority, and track escaped defects;
when an escape occurs, add at least one new assertion or checklist item to prevent
recurrence. Keep root-cause notes succinct and actionable, and feed lessons into risk
registers and test design. Industry studies indicate that a small set of outcome-based
measures is preferable to extensive “vanity” dashboards (Forsgren, Humble and Kim,
2018).

9
6. Reporting and closure
Compare results with exit criteria and make residual risk explicit (for example: CSV
export not performance-tested; low usage; behind a feature flag). Version the regression
pack so the next cycle starts from a known baseline. ISO/IEC/IEEE 29119-3:2021
supports concise, consistent artefacts for this purpose.

Automation tools—where they

provide value

 Static analysis and linters. Prevent classes of defects before runtime; integrate with
commits and CI (Farley, 2021).
 Unit-test frameworks (e.g., xUnit, pytest). Provide fast, low-cost checks for logic and
boundaries; keep tests small and numerous. Short, reliable cycles correlate with
improved outcomes (Forsgren, Humble and Kim, 2018).
 Mocks, fakes, and contract tests. Preserve testable seams without a full environment.
Consumer–provider contracts at service boundaries prevent inter-team integration
failures.
 API testing. Offer high signal with low brittleness; make these first-class in CI on every
change for service-oriented systems.
 UI automation. Use a thin smoke over core journeys; avoid pixel-sensitive scripts. Keep
most behavioural checks at the API/contract layer.
 Performance and load. Baseline throughput and latency early; ensure runs are
repeatable and trends are graphed. Tie thresholds to realistic SLO/SLA expectations.
 Security scanning. Run dependency and SAST continuously; schedule deeper DAST on
staging or pre-release branches. Align with recognised control sets (NIST SP 800-53
Rev. 5, 2020; OWASP ASVS 4.0.3, 2021).
 Data-quality gates (data-heavy products). Validate schemas, ranges, null rates, and
distribution drift automatically; fail builds on schema breaks. Treat data contracts like
API contracts.
 CI orchestration. Treat failing tests as merge blockers. Keep pipelines fast at unit/API
layers and move end-to-end/performance to scheduled jobs. Flaky tests are defects:
quarantine, fix, and re-enable (ISO/IEC/IEEE 29119-3:2021; Forsgren, Humble and
Kim, 2018).

Choosing what to automate (five

lenses)

1. Stability. Automate stable interfaces (pure functions, APIs); prefer exploratory testing
where the UI is volatile.
2. Frequency. Automate frequently used “golden paths”; keep rare administrative flows
manual unless risk is high.
3. Risk. Prioritise money, privacy, safety, and compliance; map automation to recognised
controls (NIST; OWASP ASVS).
4. Feedback time. Prefer tests that return results within minutes on each pull request; shift
long scenarios to nightly or release branches.
5. Maintenance cost. Assert outcomes rather than implementation details; avoid brittle
selectors and pixel checks; keep suites small, reliable, and owned.

Integrated execution plan

 On each commit: static checks, unit tests, and API/contract tests.

10
  On merge to main: thin UI smoke over core journeys.
 Nightly/weekly: broader end-to-end and performance baselines, plus scheduled security
scans.
 Throughout: exploratory charters targeting the newest or riskiest areas, with brief
debriefs feeding results into risk registers and regression packs.

This cadence provides rapid developer feedback, credible assurance for stakeholders, and
traceable evidence aligned with contemporary test-documentation standards (ISO/IEC/IEEE
29119-3:2021).

11
 2 Task 02:
Design and implement UML

a) Design UML diagrams for an ATM system (use-case, class, sequence, activity)
(Pressman and Maxim, 2019; ISO/IEC/IEEE, 2022)

Use-case specification
Actors.
Customer; Technician; host bank (external system) (Pressman and Maxim, 2019).

Customer use cases.

Authenticate; View balance; Withdraw cash; (optional) Deposit cash; Print receipt (Pressman
and Maxim, 2019).

Technician use cases.

Enter service mode; Replenish cash; Replace paper; Run diagnostics; Apply firmware update
(Pressman and Maxim, 2019).

Include relationships.

 Authenticate «include» Validate card; «include» Verify PIN (Pressman and Maxim,
2019).
 Withdraw cash «include» Debit account; «include» Dispense cash (Pressman and
Maxim, 2019).
 Enter service mode «include» Authenticate technician (Pressman and Maxim, 2019).

Standards alignment.
Notation and relationship usage follow recognised guidance for UML and architecture
description (ISO/IEC/IEEE 42010:2011; OMG UML 2.5.1, 2017).

Figure 1:-

12
Core Class sketch:

 ATM (id, location, state) — orchestrates interactions

 CardReader, Keypad, Screen, ReceiptPrinter, CashDispenser(cassettes)
 Bank ↔ Account(number, balance)
 Session(startTime, authenticated) ↔ Card(number, expiry)
 Transaction «abstract» → Withdrawal(amount), BalanceInquiry
 Technician(id, authFactor), MaintenanceLog(timestamp, action)

Figure 2:-

Sequence (Withdraw): Customer inserts a card and enters a PIN; the system validates
funds and the PIN; the account is debited and cash is dispensed; a receipt is printed and
the session ends.

Figure 3:-

Activity (Replenish Cash):

Authenticate technician → open panel → check cassette levels → load cash → close panel →
diagnostics → log action.

13
Figure 4:-

Activity Diagram

b) Refine diagrams for replenishment and upgrades

Design refinements

 Extend use cases.

Add Audit cash levels (extends Replenish cash) and Apply firmware update (includes
Verify package signature) to strengthen operational control and integrity (Pressman and
Maxim, 2019; ISO/IEC/IEEE 29119-3:2021; OWASP ASVS 4.0.3, 2021; NIST SP 800-
53 Rev. 5, 2020).
 Introduce classes.
Define FirmwarePackage (version, checksum, signature) and InventorySensor (level)
to model deployable artefacts and cash-cassette telemetry within the domain model
(OMG UML 2.5.1, 2017; ISO/IEC/IEEE 42010:2011; OMG SysML 1.6, 2019).
 Update sequence (upgrade).
Authenticate technician → Upload package → Verify signature → Enter maintenance
mode → Apply update → Self-test → Log result; record expected oracles and rollback
triggers at each step to support auditable, automated execution (Holt and Perry, 2018;
ISO/IEC/IEEE 29119-3:2021; Farley, 2021).

c) Prototype implementation

14
Develop a minimal console-based ATM application that conforms to the UML model and
mirrors the classes defined above. Keep the codebase compact and readable to support review
and testing. (Pressman and Maxim, 2019; OGC, 2022; ISO/IEC/IEEE, 2022)

15
16
 3 Task 03:
Simon game (memory sequence)
a) Create the game

“Listing X presents a concise Python (console) implementation of the Simon game. The
program displays a sequence of colours and prompts the player to reproduce it. On each
successful round, the sequence length increases; a mismatch terminates the session. The
implementation also records the player’s score.”

 The sequence increases by one colour each round; the player must reproduce it exactly.
 Input handling is case-insensitive; only the four required colour terms are accepted.
 The game terminates at the first mismatch and reports the final score.

b) Use of basic programming techniques

17
  Lists and indexing: the programme stores the target sequence in a list that grows each
round; a separate list records the player’s attempt.
 Control flow: a while loop advances rounds; if/else branches determine success or
termination.
 Functions: small, single-purpose functions (e.g., show_sequence, get_response, is_correct,
play) improve readability and cohesion.
 Input/output: input() is used for player entries, and concise print() prompts provide
guidance.
 Randomness: [Link](COLORS) introduces variation at each round.

c) Testing the game

Maintain lightweight but meaningful tests to provide clear evidence of correctness:

1. Happy path: reproduce the sequence correctly for three rounds → the displayed score
should be 3.
2. Failure path: intentionally mistype the second colour in round 2 → the game should end
and display the correct sequence.
3. Case handling: enter red, Green, blue → inputs should be accepted as RED, GREEN, BLUE.

Tiny automated checks

State that is_correct() is a pure function, which makes it straightforward to unit test—consistent
with foundational test-driven development practice (Beck, 2003). For the application as a whole,
manual, scenario-based tests are appropriate (Myers, Sandler and Badgett, 2011).

Short reflection (for the marker)

This version deliberately avoids frameworks to emphasise core programming constructs. Each
function has a single responsibility, which clarifies control flow and facilitates later extension
(for example, adding sound cues or a graphical user interface). The testing approach
demonstrates both deterministic checks (for the matching function) and exploratory/manual
checks for interactive behaviour, aligning with standard guidance on software testing.

18
4 Task 04:

19
 Conclusion
Disciplined, routine practices—not sporadic efforts—produce high-quality software (Farley,
2021; Forsgren, Humble and Kim, 2018). To make abstract concepts interpretable and
reviewable, diagrams were intentionally kept small and precise, enabling unambiguous cross-
referencing by stakeholders (ISO/IEC/IEEE 29148:2018; ISO/IEC/IEEE 42010:2011; OMG
UML 2.5.1, 2017). For example, concise use-case and short sequence diagrams reduced
miscommunication and surfaced critical questions early—such as entry points to flows,
behaviour on one-time-password expiry, and placement of error handling (Pressman and
Maxim, 2019; ISO/IEC/IEEE 29148:2018). The substantive value of modelling lies in creating a
shared understanding sufficient for sound decisions, rather than in visual spectacle (Holt and
Perry, 2018; OMG, 2019).

Testing practices followed the same rationale. There is no single “correct” approach; an
effective mix depends on risk and delivery velocity (ISO/IEC/IEEE 29119-3:2021; ISTQB,
2018). Unit checks and service-level tests provided immediate feedback while changes were still
cognitively fresh (Farley, 2021), a minimal UI smoke suite protected core user journeys without
brittle maintenance (ISO/IEC/IEEE 29119-3:2021), and structured exploratory sessions revealed
issues—such as flaky retries, edge cases, and timing sensitivities—that scripted tests commonly
miss (ISTQB, 2018). Risk-based prioritisation concentrated effort on high-impact domains
including payments, authentication, and privacy, with controls mapped to recognised
frameworks (Capgemini, Sogeti and OpenText, 2023; OWASP ASVS 4.0.3, 2021; NIST SP
800-53 Rev. 5, 2020). Integrating these checks into the daily CI pipeline and branch flow was
associated with faster and more stable delivery (Forsgren, Humble and Kim, 2018).

System testing provided the integrative framework: objectives and exit criteria were defined in
advance; scenarios were derived from models; reliable environments and data were prepared;
executions were triaged; and defects were fixed with succinct, actionable notes. This steady
cadence reduces late-stage surprises (ISO/IEC/IEEE 29119-3:2021). Automation delivered the
highest value where interfaces are stable—pure functions, APIs, and service contracts—and was
applied proportionately to avoid excessive maintenance cost (Farley, 2021; ISO/IEC/IEEE
29119-3:2021). Where surface behaviour changes frequently, informed manual exploration
supported by domain knowledge remained superior to fragile scripted checks (ISTQB, 2018).

Overall, the objective is not perfection but reliable delivery today with adaptability for
tomorrow. In practice, this entails retaining only those diagrams that support decisions, focusing
testing on what matters most, automating where it yields sustained value, and treating each
defect as an opportunity for systemic improvement. Applied consistently, these practices
increase confidence at release, reduce firefighting, and redirect effort to product improvement
(Forsgren, Humble and Kim, 2018; ISO/IEC/IEEE 29119-3:2021; Capgemini, Sogeti and
OpenText, 2023).

20
 References
Beck, K. (2003) Test-Driven Development: By Example. Boston, MA: Addison-Wesley.

Capgemini, Sogeti and OpenText (2023) World Quality Report 2023–24. Paris: Capgemini.

Elmasri, R. and Navathe, S.B. (2019) Fundamentals of Database Systems. 7th edn. Harlow: Pearson.

Farley, D. (2021) Modern Software Engineering: Doing What Works to Build Better Software
Faster. Boston, MA: Addison-Wesley.

Forsgren, N., Humble, J. and Kim, G. (2018) Accelerate: The Science of Lean Software and DevOps
—Building and Scaling High Performing Technology Organizations. Portland, OR: IT Revolution
Press.

Freund, J. and Rücker, B. (2019) Real-Life BPMN: Using BPMN 2.0 to Analyze, Improve, and
Automate Processes. 4th edn. Berlin: Camunda Press.

Holt, J. and Perry, S. (2018) SysML for Systems Engineering: A Model-Based Approach. 3rd edn.
London: The Institution of Engineering and Technology (IET).

ISTQB (2018) Certified Tester Foundation Level (CTFL) Syllabus v3.1. International Software
Testing Qualifications Board.

ISO/IEC/IEEE (2011) 42010:2011 Systems and software engineering — Architecture description.

Geneva: International Organization for Standardization.

ISO/IEC/IEEE (2018) 29148:2018 Systems and software engineering — Life cycle processes —
Requirements engineering. Geneva: International Organization for Standardization.

ISO/IEC/IEEE (2021) 29119-3:2021 Software and systems engineering — Software testing — Part
3: Test documentation. Geneva: International Organization for Standardization.

Myers, G.J., Sandler, C. and Badgett, T. (2011) The Art of Software Testing. 3rd edn. Hoboken, NJ:
John Wiley & Sons.

NIST (2020) Security and Privacy Controls for Information Systems and Organizations (SP 800-53,
Rev. 5). Gaithersburg, MD: National Institute of Standards and Technology.

OMG (2017) OMG Unified Modeling Language (OMG UML), Version 2.5.1. Needham, MA: Object
Management Group.

OMG (2019) OMG Systems Modeling Language (OMG SysML), Version 1.6. Needham, MA: Object
Management Group.

OWASP (2021) Application Security Verification Standard (ASVS), Version 4.0.3. Open Web
Application Security Project.

21
Pressman, R.S. and Maxim, B.R. (2019) Software Engineering: A Practitioner’s Approach. 9th edn.
New York, NY: McGraw-Hill.

Schwaber, K. and Sutherland, J. (2020) The Scrum Guide: The Definitive Guide to Scrum — The
Rules of the Game. [Link].

Silberschatz, A., Korth, H.F. and Sudarshan, S. (2019) Database System Concepts. 7th edn. New
York, NY: McGraw-Hill.

Smart, J.F. (2023) BDD in Action. 2nd edn. Shelter Island, NY: Manning.

Van Mierlo, E. (2020) Modelling Reactive Behaviour with Statecharts.

22
Appendix

23
 This section is solely for trainers,
And students shouldn’t edit, delete,
Or update any details here.
 Assessment Marking Sheet

OTHM LEVEL 5 EXTENDED DIPLOMA IN INFORMATION TECHNOLOGY (Qualification Number: 610/2571/9)

Unit name (F/617/2266)

(Please tick the appropriate Box) (Please tick the appropriate

Box) (Please tick the appropriate Box) (Please tick the appropriate Box)

Learner Name and OTHM Registration Number Pass

Final Result
Refer

Pass Grading Criteria

Learning Outcome – Assessment Criterion – Pass/ Assessor Comments
The learner will: The learner can: Refer
1. Understand the principles of 1.1 Explain how systems analysis and design contributes to the
systems analysis and design. software development life cycle.
Describe the components of systems analysis.
Analyse different approaches to system analysis and design.
Evaluate system design requirements.
Explain the importance of each stage in traditional software
lifecycle approaches.
Evaluate software development lifecycle models.
Explain hard and soft system methodologies.
1.2
1.3
1.4
1.5
1.6
1.7
2. Understand system design 2.1 Explain types of information systems.
methodologies and 2.2 Evaluate how the functionality of information systems varies
modelling. between different information systems.
2.3 Explain system design concepts.
2.4 Evaluate different system design methodologies.
 3. Understand human 3.1 Explain the principles of HCI.
computer interface (HCI). 3.2 Explain how HCI improves the user experience of a system.
3.3 Explain the considerations to make in relation to HCI when
designing a system.
3.4 Evaluate HCI methodologies.
4. Be able to produce a system 4.1 Create a system design document.
design using modelling 4.2 Produce a model of a software system.
techniques. 4.3 Produce a security and control design.

Overall Assessor Comments

Assessor Signature _____________________________

 Internal Quality Assurance

Internal Quality Assurance Report

OTHM LEVEL 5 EXTENDED DIPLOMA
Qualification Title Unit Title
IN INFORMATION TECHNOLOGY
Name of Assessor(s)
Name of Internal Verifier
(IQA)
Yes
If OTHM Assignment not used -
No Date of approval
Has assignment been approved by OTHM?

Name of learners in IQA sample

Assessor decision IQA decision

Number of 1 Referred
learners in cohort
IQA Comments on work of Assessors

Yes No Comments / Observations

Does the work meet all the assessment criteria?

Has the work been assessed accurately?

Is the feedback mapped to the assessment criteria?
Has the tutor feedback highlighted opportunities for
learners to improve performance?
Is there a learner declaration of authenticity on the learner
work?
Do you agree with the final decision?

Internal Quality Assurance

Internal Quality Assurance Report

Action Points for Assessors (to include date for completion)

Assessor signature
Date

IQA signature
Date

Note: A separate form should be used for each qualification.