Question 8 of 8

Question 8 (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) — decomposing the system. The system decomposes naturally along the functional requirements identified in Question 7(a), into loosely coupled components communicating through the central database and a defined logging interface:

This decomposition follows a standard layered/service-oriented split: an extensible protocol-simulator layer (one module per protocol, so a new protocol can be added without touching the other layers — supporting the maintainability NFR from Question 7b), a log ingestion service that decouples the simulators from the database's own schema/availability, a central database as the single source of truth, a set of analysis services (auto-plot, search, raw-data export) that each read the database independently, and a secure web front-end gatekeeping all access from testers/service designers. Splitting along these seams means each piece can be developed, tested, and scaled independently — a new protocol simulator does not require redeploying the web front end, and the search service can be optimized without touching the ingestion path.

Part (b) — approach to project cost estimation. A defensible estimate combines more than one technique rather than relying on a single number:

1. Decompose the work first — build a WBS (Question 1c) down to each component identified in part (a), since estimating the whole system as one lump is far less accurate than summing estimates of well-understood pieces.
2. Apply an algorithmic model — e.g., COCOMO II, using a size estimate (function points from the requirements in Question 7a, or an analogous-project LOC estimate) and cost drivers (team experience, required reliability, platform constraints such as the dual OS X/Linux target) to produce an effort-in-person-months figure.
3. Cross-check with expert judgment / analogy — have engineers experienced with similar log-ingestion or client/server monitoring systems independently estimate each WBS component (or a Delphi/Wideband-Delphi group estimate), and compare against the algorithmic figure; a large disagreement flags a component that is poorly understood and needs more elicitation before the estimate can be trusted.
4. Convert to cost and add contingency — apply loaded labour rates to the effort estimate, and add an explicit risk-based contingency (Question 8c) rather than treating the point estimate as a guarantee.
5. Re-estimate at each milestone — treat the initial estimate as a rolling-wave starting point, refined as requirements and design firm up (the estimate for the protocol-simulator layer, for instance, is far more uncertain before the first protocol is actually simulated than after).

Part (c) — risk factors leading to errors and re-work.

• Protocol-specification risk — each simulated protocol (torrent-like, streaming-like, ...) must faithfully model a real-world protocol's traffic pattern; a misunderstood or incomplete specification produces a simulator that does not actually stress-test a router realistically, discovered only late during validation.
• Integration risk between independently developed components — the simulator clients, ingestion service, database, and analysis services (part a) are built by potentially different sub-teams against an interface contract; a mismatched log-file schema is a classic source of late, expensive rework.
• Platform-constraint violation — the OS X/Linux-only NFR (Question 7b) can be silently broken by a dependency that is not actually cross-platform, surfacing only during system/acceptance testing rather than during development.
• Security-requirement ambiguity — "secure web front end" without a specific authentication/encryption standard chosen up front risks the front-end team building to one interpretation and a security review demanding rework to another.
• Performance/scalability under-specification — without a concrete concurrent-stress-test target, the ingestion service and database may be sized for a light load and require significant rework once real stress-test volumes are attempted.
• Requirements volatility — as new protocols are added to the library (an explicitly extensible requirement), earlier design assumptions about log-file structure or database schema may no longer hold, forcing rework in components already believed complete.