19-Soft-B6 Software Project Management, May 2018, Q4

Question 4 (10 marks)

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) — parts of a typical project plan. A software project plan (produced during the Planning framework activity, Question 1a) typically contains: scope and objectives (what the project will and will not deliver); estimates of effort, cost, and resources (derived from size/complexity metrics, part b); a schedule (tasks, milestones, dependencies, often shown as a Gantt/network chart); a staffing/organization plan (roles, responsibilities, team structure); a risk management plan (identified risks, their probability/impact, and mitigation strategy); a tracking and control mechanism (how actual progress will be measured against the plan); and a project management approach stating the chosen process model (Questions 1–3) and how it will be tailored to this project. Together these parts turn the process-model choice into a concrete, executable commitment: the schedule and estimates say when and at what cost, staffing says who, and risk management says what could derail either.

Part (b) — size, complexity, and quality metrics.

Metric family	Purpose	Examples
Size metrics	Quantify how much software is (or will be) produced, the base input to effort/cost estimation	Lines of code (LOC), function points (FP)
Complexity metrics	Quantify how difficult the internal structure is to understand, test, and maintain, independent of raw size	Cyclomatic complexity (independent paths through a module's control flow), coupling and cohesion measures, Halstead complexity measures
Quality metrics	Quantify how well the delivered product meets its requirements and how defect-prone it is	Defect density (defects per KLOC or per FP), defect removal efficiency, mean time between failures (MTBF)

The three families are complementary rather than substitutes for one another: a system can be large (high size metric) yet simple (low complexity), or small yet dangerously tangled (high complexity per LOC); and complexity metrics are predictive — a module with high cyclomatic complexity is statistically more likely to contain defects — while quality metrics are the after-the-fact confirmation of whether that prediction held.

Part (c) — why separate development and maintenance departments. A large software company benefits from separating these functions for several reasons:

Different skill and incentive profiles. Development rewards building new capability quickly under a schedule; maintenance rewards careful, low-risk change to a live system that must not regress existing behaviour — conflating the two incentivizes developers to rush fixes into a codebase they are simultaneously trying to extend under a delivery deadline.
Avoiding resource contention. If the same team owns both, an urgent production defect on an old release competes directly for the same engineers' time as the next release's new features, and one or the other is chronically starved; separate departments give each its own dedicated capacity.
Specialized process needs. Maintenance work follows the ISO/IEC 12207 maintenance process (Question 5) — problem/modification analysis, controlled implementation, regression-tested acceptance — a disciplined change-control process that differs from a development team's forward-looking design/build cadence; a dedicated maintenance department can be organized and measured against maintenance-specific metrics (mean time to repair, defect backlog) that would not fit a development team's velocity-based metrics.
Institutional knowledge retention. A dedicated maintenance department accumulates deep, product-specific knowledge of a legacy system's quirks and history across many change requests, which a rotating development team (moving on to the next new project after release) does not retain as reliably.

Topic: The standard parts of a software project plan, the complementary roles of size/complexity/quality metrics, and the organizational rationale for separating development and maintenance.

Key relations: Project plan = scope + estimates + schedule + staffing + risk plan + tracking/control + process approach. Metrics = size (how much) + complexity (how hard to change) + quality (how defect-prone), each answering a different project-management question. Dev/maintenance separation → distinct incentives, dedicated capacity, specialized process, retained institutional knowledge.

Why this works: a project plan is only as good as the estimates that feed it, which is why part (b)'s metrics matter directly to part (a) — size and complexity metrics are the inputs to the estimates section of the plan; and part (c) follows from recognizing that "maintenance" (Question 5) is itself a distinct ISO/IEC 12207 process with its own activities, not an afterthought tacked onto development.

Common pitfall: treating LOC as a sufficient size metric on its own — two modules of identical LOC can differ enormously in complexity and hence in real effort to maintain, which is exactly why complexity metrics exist as a separate family rather than being folded into size.

Source: Pressman, Software Engineering: A Practitioner's Approach, 9th ed., Ch. 22 (Metrics for Process and Projects) & Ch. 23 (Project Estimation); Sommerville, Software Engineering, 10th ed., Ch. 22 (Project Planning) & Ch. 9 (Maintenance).

Question 4 of 8

Question 4 (10 marks)