25-Comp-A6 Software Engineering · December 2014
Nivaar worked solution (AI-drafted; not reviewed by a licensed engineer)
National Exams — December 2014 — 98-Comp-A6 Software Engineering. Three-hour, closed-book exam, no calculator permitted. Format: ten questions, candidates answer any six (all questions equal weight — each question carries 20 marks, so the paper is marked out of 120; only the first six questions as they appear in the answer book are marked). All ten questions are solved below for completeness.
Reference texts: Sommerville, Software Engineering (10th ed., Pearson) — software process models, object-oriented and function-oriented design, real-time systems, software testing, configuration management, dependable/critical systems, reliability engineering, component-based software engineering; Pressman, Software Engineering: A Practitioner's Approach (9th ed.) — supplementary process/testing/quality coverage; IEEE/ISO 12207 — software life-cycle processes; SWEBOK — body-of-knowledge cross-reference.
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.
Software design translates an agreed requirements specification into a description precise enough to implement, and is conventionally decomposed into six activities, each producing its own document as an output. Architectural design identifies the overall structure of the system — its major sub-systems, their responsibilities, and the relationships between them — and produces the architectural design document. Abstract specification writes, for each sub-system identified by the architecture, a specification of its services and the constraints on its operation, producing a software specification for that sub-system. Interface design specifies precisely how each sub-system interfaces with the others (and with the outside world), producing an interface specification that becomes the contract independent teams can implement against without needing to see each other's internals. Component design allocates the system's required services to individual components and works out how each component behaves, producing a component design. Data structure design designs the data structures needed to hold the information manipulated by the system (records, tables, object attributes), producing a data structure specification. Algorithm design designs the algorithms that implement each component's services, producing an algorithm specification.
The diagram makes the key relationship explicit: architectural design is not merely "first in a list" but is the activity every other design activity depends on, because a sub-system's abstract specification, its interfaces, its components, its data structures and its algorithms are all meaningless without first knowing which sub-system they belong to and what that sub-system is responsible for. The five downstream outputs are largely produced in parallel once the architecture is fixed — interface design and component design for one sub-system do not need to wait for another sub-system's data structure design to finish — but they are not produced independently forever: a component design that turns out to need a service the interface design never exposed, or a data structure that cannot support an algorithm's required access pattern, forces a change back at the interface or even architectural level. This is why the process is drawn with a feedback path rather than a single one-way pipeline — in practice, design proceeds through several iterations of this diagram before the documentation set is internally consistent.
