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) — activities of the five major phases.
| Phase | Key activities |
|---|---|
| Requirements | Elicit stakeholder needs, analyse and negotiate conflicts, specify functional and non-functional requirements in a Software Requirements Specification, and validate the specification against the stakeholders' actual intent. |
| Design | Partition the system into architecture-level components and their interfaces, choose data structures/algorithms, and produce detailed design models (Question 4's UML use-case/class diagrams) that implementation will follow. |
| Implementation | Translate the design into source code, following coding standards, with unit-level self-checking (assertions, basic unit tests) as each module is written. |
| Test | Verify the implementation against the requirements at multiple levels — unit, integration, system, acceptance (Question 6) — and record/triage defects found. |
| Maintenance | Correct defects found in operation, adapt the system to a changed environment, and enhance it with new capability, for the system's entire operational life (Question 8). |
Part b) — software metrics. Software metrics are quantitative measures of some attribute of a software product, process, or project (Fenton/Pressman) — for example lines of code, defect density (defects per KLOC or per Function Point, Question 5), cyclomatic complexity, or effort (person-hours). They are used in the software process to: (1) estimate cost/schedule for a new project by calibrating against historical projects of known size; (2) track progress against the plan (Question 2's schedule and Question 7's baseline); (3) assess quality, e.g. flagging modules whose defect density is disproportionately high for targeted rework; and (4) evaluate process improvement, comparing the same metric release-over-release to see whether changes to the process are actually working.
Part c) — the iterative and incremental process model. The iterative and incremental model combines two ideas: the system is built as a series of increments (each increment adds working functionality to what exists), and each increment is itself developed through repeated iterations of specify–design–implement–evaluate, refining that increment's own requirements and design as understanding improves rather than freezing them up front (Pressman Ch. 2; Sommerville §2.1). Likely situation: when the customer's requirements are not fully known or are expected to change during development, and a working core system is needed early for user feedback — a patient registration system (Question 4) is a good example, since clinical staff can only fully specify the bed-allocation workflow once they see the registration core working. Pros: early, usable releases reduce project risk; requirements can be refined based on real feedback rather than up-front guesswork; problems surface earlier because each iteration is independently tested. Cons: requires a flexible architecture able to absorb requirements that were not known at the start (the same drawback as the pure incremental model), overall project scope/cost is harder to fix or quote up front, and without disciplined configuration management (Question 7) the accumulating iterations can drift into an unmanageable, poorly-documented system.
