19-Soft-B6 Software Project Management, May 2015, Q1

Question 1 (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) — what is a software process model. A software process model (also called a software life-cycle model) is an abstract representation of the software development process — it describes, at a level independent of any one project's detail, the set of activities, the artifacts each activity produces or consumes, the roles that perform them, and the order or constraints under which they occur. It is a simplified, prescriptive view of how a real software process should be organized, used both to plan and communicate how a specific project will actually be run (which activities happen, in what sequence, with what checkpoints) and to compare and choose between different ways of organizing development (Waterfall, prototyping, incremental, agile, and so on, each a different process model applicable to different project risk profiles).

Part (b) — phases common to all process models. Despite their differences in sequencing, iteration, and emphasis, every software process model is built from the same generic set of framework activities:

Generic phase	What happens
Communication / Requirements	Establishing what the customer/stakeholders actually need — eliciting, analysing, and documenting requirements.
Planning	Estimating effort, schedule and resources, and defining the work to be done and the risks involved.
Modeling / Design	Translating requirements into an architecture and detailed design that can be implemented.
Construction	Coding and testing the design — producing an executable work product.
Deployment	Delivering the product to the customer, obtaining feedback, and evaluating it against requirements (feeding back into the next iteration where the model is iterative).

Every named process model is really a different arrangement of these same five phases — the Waterfall model performs them once, strictly in sequence; prototyping and the spiral model repeat modeling/construction/deployment in short cycles; agile methods compress and interleave all five within very short iterations — but no model can omit any of them, because each phase supplies an input the next phase depends on.

Part (c) — major project scope management processes. Project scope management (PMBOK) is the set of processes that ensures the project includes all, and only, the work required to complete it successfully:

Plan Scope Management — documenting how the project's scope will be defined, validated, and controlled.
Collect Requirements — determining and documenting stakeholders' needs to meet the project's objectives.
Define Scope — developing a detailed description of the project and the product, distinguishing what is in scope from what is explicitly out of scope.
Create WBS (Work Breakdown Structure) — subdividing project deliverables and work into smaller, more manageable components.
Validate Scope — formalizing acceptance of the completed deliverables with the customer/sponsor.
Control Scope — monitoring the status of the project's and product's scope and managing changes to the scope baseline (guarding against uncontrolled scope creep).

Together these processes form a plan → define → decompose → deliver → validate → control cycle: the first three establish agreement on what "done" means, the WBS turns that agreement into schedulable work, and the last two protect that agreement for the rest of the project.

Topic: The definition of a software process model, the five generic framework activities every model shares, and PMBOK's six scope-management processes.

Key relations: Process model = activities + artifacts + roles + ordering constraints. Generic phases = Communication → Planning → Modeling → Construction → Deployment. Scope management = Plan → Collect Requirements → Define Scope → Create WBS → Validate Scope → Control Scope.

Why this works: a process model is only useful if it is concrete enough to plan a real project against, yet general enough to be reused across projects — the five generic phases are the fixed skeleton that makes every model comparable, while scope management is the PMBOK-side discipline that keeps a chosen model's Requirements/Planning phases bounded to agreed work rather than drifting.

Common pitfall: treating "process model" and "project plan" as synonyms — the model is the reusable, abstract template (Waterfall, agile, ...); the project plan is the specific instantiation of that template's activities, dates, and resources for one project.

Source: Sommerville, Software Engineering, 10th ed., Ch. 2 (Software Process Models); Pressman, Software Engineering: A Practitioner's Approach, 9th ed., Ch. 2 (Process Models); PMBOK, 7th ed. (Scope Management knowledge area).

Question 1 of 8

Question 1 (10 marks)