ACCTING2503 · Accounting Systems And Analytics
Systems Design, Implementation & Operation
This chapter carries the AIS from a finished analysis all the way to a running, maintained system across four SDLC phases: conceptual design (what/which alternative), physical design (the code-ready how), implementation and conversion (build, train, document, test, switch over), and operation and maintenance. The headline exam skill is matching a data-conversion strategy — direct, parallel, phased or pilot — to a scenario's risk-versus-cost constraint. It is examined in Test 1 and is a recurring case-study target in the closed-book final.
What this chapter covers
- 011. Conceptual (general) design — evaluate design alternatives, prepare specifications, deliver the conceptual-design report
- 022. Physical (detailed) design — the six code-ready areas: Output, File/DB, Input, Program, Procedures, Controls (OFIP + PC)
- 033. Output design and the four report types — scheduled, demand, exception (all pre-specified) and analysis (ad hoc)
- 044. Input design — media, source-data automation, good form design and error detection at the point of capture
- 055. Program design — the eight-step mini-cycle (needs, plan, code, test/debug, document, train, install, use/modify)
- 066. Controls design and the audit trail — validity, authorisation, accuracy, security; trace source to output and back
- 077. Implementation and conversion — planning, three documentation types, three testing types (walk-through, test data, acceptance)
- 088. Data conversion — direct vs parallel vs phased vs pilot, the risk/cost trade-off, plus the post-implementation review
Recommend a data-conversion strategy (case, short-answer)
- +1Direct (big-bang): stop the old system and switch the new one on at a single cut-over — cheapest, but highest risk because there is no fallback if it fails.
- +1Parallel: run the old and new systems together and reconcile until confidence is gained — safest, but most expensive because everything is processed twice.
- +1Phased: introduce the new system module by module over time — spreads risk across stages but stretches the timeline.
- +1Pilot: implement fully at one site first, then propagate to the rest once it is proven — contains any problem to a single location.
- +3Recommend pilot: run the new AIS at one representative store first. Low risk tolerance rules out direct (no fallback), and a tight budget makes a full parallel run across all 14 stores too costly. A pilot limits any checkout error to one store while validating the system cheaply, and doubles as live training before roll-out.
- +1State the trade-off explicitly: the binding constraints are many-similar-sites plus tight-budget plus low-error-tolerance, which is exactly the profile a pilot fits — cheaper than parallel-everywhere, safer than direct. (A short parallel run within the pilot store is a strong belt-and-braces addition.)
Key terms
- Conceptual (general) design
- The high-level 'what' of the new system — evaluating design alternatives, setting general specifications for outputs, storage, inputs and processing, and delivering the conceptual-design report that guides detailed work.
- Physical (detailed) design
- The code-ready 'how' — translating the chosen concept into detailed specs across six areas: Output, File/database, Input, Program, Procedures and Controls (mnemonic OFIP + PC).
- Output report types
- Scheduled (pre-specified content on a regular calendar), demand (pre-specified, on user request), exception (pre-specified, triggered by an abnormal condition) and analysis/special-purpose (ad hoc, content not pre-specified).
- Direct conversion
- The old system is stopped and the new one switched on at a single cut-over — cheapest but riskiest, because there is no fallback if the new system fails.
- Parallel conversion
- Old and new systems run together and are reconciled for a period — the safest approach because results can be compared, but the most expensive because everything is processed twice.
- Pilot conversion
- The new system is fully implemented at one site or branch first, then propagated once proven — localises any problem and allows live-environment training before a wider roll-out.
- Acceptance test
- An end-to-end test of the whole system on real transactions and files against criteria the users set; the users — not the analysts — make the final decision to accept the system and go live.
- Post-implementation review
- A structured evaluation after go-live asking whether the system meets its goals, satisfies users, delivered the expected benefits/costs, and is reliable, accurate, secure and well documented; its findings feed ongoing maintenance.
Systems Design, Implementation & Operation FAQ
How is this chapter examined in ACCTING 2503?
Systems development is tested in Test 1 (the case-study based, 50-question test covering the systems-development process) and is a recurring target in the closed-book final exam's six case-study questions. The classic items are a conversion-strategy recommendation, a conceptual-versus-physical 'distinguish' question, and name-and-describe lists (report types, testing types, documentation types). Marks come from reasoning and trade-offs, not one-word labels.
What is the difference between conceptual and physical design?
Conceptual design decides the 'what' — it evaluates design alternatives and sets general specifications, delivered as the conceptual-design report. Physical design decides the code-ready 'how' — the exact output layouts, file/record structures, input screens, program logic, procedures and controls. A quick test: if a description names a specific layout, field or record it is physical; if it weighs options or gives a general spec it is conceptual.
How do I choose between direct, parallel, phased and pilot conversion?
Read the scenario's binding constraint. Cannot tolerate any error or downtime (mission-critical financial data) and can afford it → parallel. Many similar sites or branches → pilot. A large system you want to de-risk in stages → phased. Simple, cheap and low-stakes → direct. Always state the cost-versus-risk trade-off explicitly — that sentence is where the marks are.
Who decides whether the new system is accepted?
The users, through the acceptance test — they set the acceptance criteria and make the final go decision. A common exam catch is to say the analysts or the project team accept the system; that loses the mark. The users own acceptance.
What are the three documentation types and three testing types?
Documentation: development (system description, layouts, program flowcharts, test results, sign-offs), operations (run schedules, files accessed, equipment/security/retention needs) and user (procedures manual and training materials). Testing: walk-through (step-by-step review of logic), processing test data (valid data plus every error condition) and acceptance test (real data against user-set criteria). Dropping one item from either list is an easy way to lose marks.
What is the accountant's role in systems design?
You do not write the code, but you set the information requirements the system must satisfy and insist on internal controls and an audit trail at design time — far cheaper than bolting them on after go-live. In the exam, 'the accountant's role' almost always cashes out as information requirements plus control and auditability.
Exam move
Anchor the chapter on the four data-conversion strategies — they are the signature exam figure and the most-mixed-up content. Build a two-line mental table (direct = cheapest/riskiest, parallel = safest/costliest, phased = by module, pilot = one site) and, more importantly, drill matching a strategy to a scenario's binding constraint, because that is what the case questions test. Next, lock the conceptual-versus-physical distinction (what/alternatives vs code-ready how) and memorise the six physical-design areas as OFIP plus Procedures and Controls. Then commit the small lists to memory as sets you can reel off: four output report types (three pre-specified, one ad hoc), three documentation types, three testing types. Practise every answer in a STATE to APPLY to EVALUATE to CONCLUDE shape — state the definitions, apply them to the facts, name the trade-off, then give a justified recommendation — and always remember it is the users who sign off the acceptance test.
