19-Soft-A7 Software Development Process · Undated paper
Nivaar worked solution (AI-drafted; not reviewed by a licensed engineer)
National Exams — 04-Soft-A7, Software Process (closed book, two aid sheets, 3 hours). Notes on the paper: eight questions constitute the exam paper; answer FIVE of the eight, and the first FIVE as they appear in the answer book are marked. Each question is of equal value, and each sub-question within a question is of equal value (shown here as 20 marks per question on a 100-mark basis) — this solution answers all eight as a full study resource. Question 3 asks for a Gantt/timeline schedule for a personal address-book application; Question 4 introduces a hospital patient-registration system that Question 5's Function-Point estimate builds on.
Reference texts. Sommerville, Software Engineering, 10th ed., Ch. 2 (Software Processes), Ch. 3 (Agile Software Development), Ch. 5 (System Modeling), Ch. 8–9 (Testing), Ch. 22–23 (Project Management, Configuration Management), Ch. 9 (Software Evolution/Maintenance); Pressman, Software Engineering: A Practitioner's Approach, 9th ed., Ch. 2–3 (Process Models, Agile), Ch. 23–24 (Project Management, Risk Management), Ch. 29 (Function-Point sizing), Ch. 22 (SQA), Ch. 24 (Software Configuration Management); IEEE/ISO 12207 (Software Life Cycle Processes); SWEBOK v4 (Software Engineering Process, Software Configuration Management, Software Maintenance KAs).
Question text not reproduced: the examination questions are © Engineers and Geoscientists BC. Open the official past paper (linked at the top of this page) to read the question, then follow the worked solution below.
Part a) — software development process vs. software life cycle. The software development process (Question 1a's five phases) covers only the activities that produce the system in the first place — from requirements through implementation and initial test/release. The software life cycle (IEEE/ISO 12207) is broader: it spans the system's entire existence, from initial concept and development through deployment, the whole operational/maintenance period (Part b), and eventual retirement/decommissioning. The development process is therefore one stage nested inside the larger life cycle, not a synonym for it — a registration system's life cycle continues for years after its development process is finished.
Part b) — major tasks in software maintenance (four categories).
| Maintenance category | Task |
|---|---|
| Corrective | Fix defects discovered in operational use (e.g. a bed-double-booking bug found after go-live). |
| Adaptive | Modify the system to keep working as its external environment changes (e.g. a new hospital-records interoperability standard). |
| Perfective | Enhance the system with new functionality or improved performance requested by users, beyond the original specification. |
| Preventive | Proactively restructure/document the system to keep it maintainable before a defect or environment change forces a harder fix later. |
Part c) — software evolution vs. maintenance. Maintenance is commonly understood as keeping an existing, largely stable system working — correcting, adapting, and modestly enhancing it (Part b) within its existing architecture. Software evolution is the broader, longer-term process of a system continuing to change to remain useful as requirements and environment shift over years, which can include changes maintenance alone does not cover: major architectural restructuring or re-platforming to support capability maintenance's incremental changes can no longer accommodate, substantial re-engineering (Part d) of legacy subsystems, and strategic technology migration (e.g. moving the registration system from a monolithic architecture to a services-based one). These evolution-only tasks go beyond patching the existing design and instead deliberately change the system's structure to extend its useful life.
Part d) — reverse engineering vs. re-engineering the entire system; when each is preferred. Reverse engineering is the process of analysing an existing system (often one with poor or missing documentation) to recover a higher-level understanding of its design and requirements — extracting the architecture, data model, and business rules without changing the system itself — typically as a precursor to a decision about what to do next. Re-engineering the entire system goes further: it rebuilds the system (or a major part of it) using the recovered understanding, actually replacing the old implementation with a new one. Reverse engineering alone is preferred, without full re-engineering, when the existing system's behaviour is still adequate and the goal is only to document/understand it — for example, recovering the registration system's undocumented bed-allocation business rules so a new interoperability interface (Part c's adaptive maintenance) can be added safely, without disturbing a system that otherwise still functions correctly. Full re-engineering becomes necessary only when the existing implementation itself (not just its documentation) is the problem — e.g. an architecture too brittle to keep evolving (Part c).
