25-Comp-A6 Software Engineering · December 2015
Nivaar worked solution (AI-drafted; not reviewed by a licensed engineer)
National Exams — December 2015 — 98-Comp-A6 Software Engineering. Three-hour, closed-book exam, no calculator permitted. Format: eight questions, candidates answer any five of the eight (all questions equal weight — each of the five counted questions is worth 20%; only the first five questions as they appear in the answer book are marked). All eight questions are solved below for completeness.
Reference texts: Sommerville, Software Engineering (10th ed., Pearson) — software process models, object-oriented and function-oriented design, software testing, requirements engineering, dependability and critical systems, configuration management, project/risk management; Pressman, Software Engineering: A Practitioner's Approach (9th ed.) — supplementary process and testing coverage; Leveson, Safeware: System Safety and Computers — hazard analysis and fault tree analysis for safety-critical software (applied to the Question 7 medical-device case).
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.
Risk management proceeds through four sequential stages, revisited continuously across a project rather than performed once. Risk identification lists possible project, technical, and business risks (staff turnover, requirements change, technology failure, budget/schedule pressure, and so on). Risk analysis assesses each identified risk's probability and the severity of its consequence, so effort can be prioritized. Risk planning devises, for each significant risk, a strategy to avoid it, to reduce its probability or impact, or to prepare a contingency to be triggered if it occurs. Risk monitoring continually reassesses the identified risks as the project proceeds, watching for indicators that a risk's probability or impact has changed, and feeds back into re-planning.
Technical excellence at programming and managerial excellence draw on largely disjoint skill sets. A software manager's core work is planning, estimating, negotiating scope and schedule with stakeholders, motivating and developing a team of people, and making decisions under uncertainty and incomplete information — interpersonal, organizational, and communication skills that have no necessary relationship to being able to write excellent code. In fact, the traits that make someone an outstanding individual contributor — deep, sustained focus on a single hard technical problem, a preference for working alone, sometimes an impatience with the ambiguity and compromise that management requires — can actively work against effectiveness as a manager, whose job is largely about enabling other people's work rather than personally producing more of it. Conversely, someone with strong management and communication skills but only moderate coding ability may excel at removing obstacles, negotiating realistic schedules, and getting the best out of a technically stronger team than they could assemble by coding alone.
This is fundamentally a professional-ethics question, not a purely technical one, and it should be worked through as such rather than simply complied with. As a professional engineer, the manager's first obligation is honesty about the actual state of the project: if the schedule genuinely cannot be met without unpaid overtime, that fact should be reported back up, together with the real trade-offs available — reduce scope, add resources, extend the schedule, or accept the overtime with informed, voluntary consent and (ideally) compensation. Simply acquiescing and privately extracting unpaid overtime from the team without disclosing to the manager that the estimate itself was unrealistic is dishonest both to the manager and to the team, and sets a precedent that unrealistic schedules will always be quietly absorbed by unpaid labour rather than surfaced and corrected.
Significant factors in the decision include: whether the schedule pressure is a one-time, genuinely exceptional circumstance (e.g. a contractual, hard external deadline) versus a recurring pattern of chronic under-estimation that management is simply passing down; whether overtime is requested with the team's informed, individual consent (a team member with young children may have caregiving obligations that make evening/weekend work materially harder for them than for others, and this should be an individual choice, not an imposed team norm); whether any compensation (time-off-in-lieu, pay) is offered; and the professional and safety consequences of a rushed delivery (Question 7 in this paper explores exactly this kind of pressure applied to a safety-critical system, where a schedule-driven shortcut can directly cause harm). On balance, the professionally and ethically sound response is to be transparent with the manager about the schedule risk and the human cost of the proposed solution, seek a mutually acceptable adjustment (scope, schedule, or resources) before overtime is even asked of the team, and treat overtime, if ultimately unavoidable, as something each team member consents to individually and is compensated for — not something silently expected because the schedule was optimistic.
