19-Soft-B6 Software Project Management · May 2018
Nivaar worked solution (AI-drafted; not reviewed by a licensed engineer)
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) — a common software process framework. A software process framework identifies the small set of framework activities that apply to every software project, regardless of size or the specific process model (Waterfall, spiral, agile, ...) later chosen to arrange them:
| Framework activity | What happens |
|---|---|
| Communication | Establishing what the customer/stakeholders actually need — eliciting, negotiating, and documenting requirements before committing resources to build anything. |
| Planning | Creating a project plan (Question 4a) — the work to be done, the risks involved, the resources required, the work products produced, and a schedule. |
| Modeling | Creating models (analysis + design) so the team and the customer better understand the requirements and the software design that will satisfy them. |
| Construction | Code generation (manual or tool-assisted) and the testing needed to uncover errors in the code. |
| Deployment | Delivering the software (or an increment) to the customer, who evaluates it and provides feedback based on that evaluation. |
These five activities are called a framework because they are performed on every project, but their emphasis and ordering differ by model: Waterfall performs each once, in strict sequence; the V-model (Question 3a) folds construction between paired specification/test activities; agile compresses and repeats all five within very short iterations. Underneath the framework activities sit umbrella activities that apply throughout the project rather than to one phase — software project tracking and control, risk management, software quality assurance, formal technical reviews, measurement, and configuration management — and it is exactly these two layers (a fixed set of framework activities, arranged and repeated differently by the chosen process model, plus continuous umbrella activities) that make one process framework describable at all despite the wide variety of named models built on top of it.
Part (b) — types of software architectures, and why the choice matters. Common architectural styles include:
Choosing the right style is important because architecture is the earliest design decision that fixes the system's quality attributes: it constrains how easily the system can later be modified (e.g., layering isolates a database swap to one layer), how it scales (client–server and microservices can scale tiers/services independently; a monolithic layered system typically cannot), how testable it is (pipe-and-filter's stateless filters are individually testable in isolation), and how much coordination overhead a development team will carry (microservices let separate teams own separate services, at the cost of distributed-systems complexity that a single layered application never faces). An architectural style chosen to fit the dominant quality attribute the project actually needs (extensibility, throughput, team autonomy, testability) is far cheaper to build around from day one than to retrofit after construction has begun — architecture decisions are the most expensive of all design decisions to reverse, since every module written afterward implicitly depends on them.
