23-Ind-B4 Design of Information Systems · December 2017
Nivaar worked solution (AI-drafted; not reviewed by a licensed engineer)
National Exams — December 2017 — 98-Ind-B4, Design of Information Systems. 3 hours; closed book, no calculator permitted. The exam comprises four parts: Part A (select 20 terms from the list given and explain each in a sentence or two, no more than 50 words, 2 marks each = 40 marks), Parts B and C (select 2 of 5 questions in each part, 11 marks each = 22 marks per part), and Part D (select 1 of 2 questions, 16 marks). Complete answers to every term and every question in all four parts follow below, not only the minimum selection a candidate would submit on exam day.
Reference texts: Laudon & Laudon, Management Information Systems: Managing the Digital Firm, 15th ed.; Schwalbe, Information Technology Project Management, 9th ed.
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.
The traditional SDLC is a sequential, "waterfall" set of stages, each producing a formal deliverable the next stage depends on. Systems analysis defines the problem and business driver (Question 1, term unrelated but same discipline), gathers detailed requirements from stakeholders, and assesses technical, economic, and organizational feasibility. Systems design translates the agreed requirements into a logical design (what the system will do — the conceptual schema, inputs, outputs, processes) and a physical design (how it will do it — specific hardware, software, database technology, and controls). Programming writes or configures the code implementing the design specification. Testing covers unit, system, and acceptance testing, with acceptance testing having actual users confirm the system meets their requirements before go-live. Conversion/implementation cuts over from the old system using a parallel, direct, pilot, or phased strategy. Production and maintenance is the system's operational life once live, including corrective, adaptive, and perfective maintenance.
Uses powerful development tools, prototyping, and small, dedicated teams to produce a working system much faster than the sequential SDLC, often compressing analysis and design into a shorter, more iterative process rather than a single long upfront phase. Difference: speed is prioritized over exhaustive upfront documentation, at some cost in long-term maintainability if not disciplined.
Delivers working software in short, fixed-length iterations (sprints), with continuous customer feedback shaping each subsequent iteration, rather than a single, complete specification agreed at the start. Difference: requirements are expected and allowed to evolve throughout development, trading some upfront predictability of total scope/cost for a much faster response to changing business needs — the opposite of the waterfall SDLC's assumption that requirements are fully knowable in advance.
Brings end users, business stakeholders, and IT staff together in structured, facilitated workshops to define requirements and review design collaboratively, in real time, rather than through a sequence of separate interviews and written documents passed back and forth. Difference: compresses the traditional analysis stage's iterative back-and-forth into concentrated joint sessions, catching misunderstandings immediately instead of after a lengthy written-requirements review cycle.
A cultural and technical approach that merges software development (Dev) and IT operations (Ops) into one continuous, highly automated pipeline — continuous integration, automated testing, and automated deployment — so new code can be released to production frequently, sometimes many times a day, rather than in large, infrequent releases. Difference: collapses the traditional SDLC's separate, sequential programming/testing/conversion/maintenance stages into one continuous, automated cycle with no long "release" boundary between them.
Builds a quick, working (though often incomplete) preliminary version of a system, gets it in front of end users for feedback, and refines it through repeated cycles until it either becomes the final system or clarifies requirements well enough to inform a full build. Difference: replaces the traditional SDLC's assumption that requirements must be fully specified before any building begins with the assumption that users often cannot fully articulate what they need until they see and react to something concrete.
Every alternative approach relaxes the same core waterfall assumption — that requirements can and should be completely specified before design and construction begin — replacing it with iteration, continuous stakeholder involvement, or automation that shortens the feedback loop. Digital firms favour these approaches because they compete in markets where requirements and competitive pressure change faster than a multi-year waterfall project can adapt to.
