Question 12 of 13: Major Steps in the Information System Development Process

Question 12 (Part D.1): Major Steps in the Information System Development Process (16 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.

Major Steps in the Development Process

The classic systems development life cycle (SDLC) breaks development into a sequence of stages, each producing the deliverable the next stage depends on.

• Systems analysis / feasibility study — define the problem or business driver (Question 1, term 8), gather and document requirements from stakeholders, and assess technical, economic (capital budgeting, term 10, and TCO, Question 11), and organizational feasibility before committing further resources.
• Systems design — translate the agreed requirements into a logical design (what the system will do: inputs, outputs, processes, data model — the conceptual schema of Question 1, term 18) and then a physical design (how it will do it: specific hardware, software, database technology, user-interface detail, and controls).
• Programming — write, or configure, the code that implements the design specification.
• Testing — unit testing of individual modules, system testing of the integrated whole, and acceptance testing in which the actual users confirm the system meets their requirements before it goes live.
• Conversion / implementation — cut over from the old system to the new one using a parallel, direct, pilot, or phased strategy (Question 1, term 13), the choice trading risk against cost and disruption.
• Production and maintenance — the system's operational life once live, including corrective maintenance (fixing defects), adaptive maintenance (responding to changing business or regulatory needs), and perfective maintenance (performance and usability improvements), all governed by the same change-control discipline (term 11) used during development.

Documentation, user training, and project management run throughout every stage above rather than being a discrete step of their own.

How the Process Differs by Project Size

A large project (several person-years, many stakeholders, high organizational impact) needs a formal, staged approach: extensive documented requirements and design specifications so a large, possibly geographically distributed team stays synchronized; formal project-management structure (a work-breakdown structure, a project charter, a steering committee spanning both business and IT, a portfolio/risk-analysis step at selection, Question 1's term 33) to manage the correspondingly larger risk (Question 13 develops why); a formal change-control board (term 11) because uncontrolled scope creep is far more damaging at this scale; extensive, staged testing and quality assurance; and typically a pilot or phased conversion strategy to limit the blast radius of any single failure. A small project (a few person-months, a small, often co-located team, narrow scope) can use a lighter-weight, iterative approach — prototyping or agile development (term 2), less formal documentation, a shorter feedback loop directly with the small set of end users, and often a direct or parallel conversion since the smaller scope makes the risk of cutting over quickly acceptable. Critically, the same conceptual steps (analysis → design → build → test → implement → maintain) still occur on a small project; what changes is the formality, documentation burden, and governance overhead wrapped around them, not the underlying process itself.