Domain 3: Information Systems Acquisition, Development and Implementation

1. 1 Business case Approved before real money is spent.
2. 2 Stage gates Is the project still worth it? Ready for the next stage?
3. 3 Change control Scope, budget and time changes approved at the right level.
4. 4 Status reports Honest progress, risks and issues.
5. 5 Closure Acceptance, handover, lessons learned.

A project shows green status every month, but the auditor finds the baseline schedule was quietly reset three times without steering committee approval.

Imagine making Sunday lunch. The roast takes 2 hours; the vegetables take 30 minutes; you can't carve before the roast is done. Some jobs can happen at the same time, some must wait for others, and one long chain decides when lunch is ready.

Project schedules work the same way. Three tools help: Gantt charts, PERT and the critical path.

A Gantt chart shows each task as a bar along a timeline, often with milestones and how far along each task is. Easy to read and great for tracking progress. Its weakness: you can't easily see which tasks depend on which, so you can't tell which delays will push out the end date.

Before you can estimate cost and time, you need to know how big the job is. A builder estimates a house by floor area, not by counting bricks after it's built.

Function points are the 'floor area' of software: a measure of how much it does for its users, which you can count from the requirements before any code exists.

1. 1 Count The five components, from requirements.
2. 2 Weight Low, average or high complexity.
3. 3 Adjust For things like performance needs or complex processing.
4. 4 Function points The system's size.
5. 5 Effort and cost Using past productivity, e.g. hours per function point.

'We've spent half the budget and we're halfway through the schedule.' Sounds fine. But what if only a third of the work is done?

Earned value management answers the real question: how much work have we actually done, compared with the plan and with what we've spent?

1. 1 Identify Early and often: workshops, past lessons.
2. 2 Assess How likely, how bad.
3. 3 Respond Avoid, mitigate, transfer, accept; contingency.
4. 4 Assign owners Someone responsible for each risk.
5. 5 Monitor Risk register reviewed at steering meetings.

Before buying a car, you'd think about why you need it, what you could afford, the running costs as well as the price, and whether a bike or the bus would do instead.

A business case does the same for an IT project. It's owned by the sponsor and it's the reason the project exists.

A warehouse system was approved at 1.2 million, promising 400,000 a year in savings. Halfway through, costs are forecast at 2.5 million and half the warehousing has been outsourced, halving the savings.

Buying a gym membership doesn't make you fit. Going to the gym does. In the same way, a new system working perfectly doesn't deliver value until people use it and the business changes how it works.

Benefits realisation is about making sure the promised value actually shows up.

If you ask a builder for 'a nice kitchen', you'll get their idea of nice. Ask for 'a 4-metre worktop, a double sink under the window, and space for a dishwasher', and you'll get what you want.

Requirements are that precise list for a system. Most failed projects trace back to requirements that were vague, incomplete or never really agreed.

1. 1 Find stakeholders Users, owners, security, compliance, operations.
2. 2 Gather Interviews, workshops, observation, prototypes.
3. 3 Write down Clear, testable statements or user stories.
4. 4 Check with users Complete and accurate?
5. 5 Sign off and baseline Later changes through change control.

Requirements are the wish list: 'three bedrooms, a big kitchen'. Design is the architect's blueprint: where every wall, pipe and socket goes.

Builders follow the blueprint. If it doesn't show a smoke alarm, nobody fits one. Software is the same: if the design doesn't specify a control, developers won't build it.

1. 1Input, processing and output controls for critical data.
2. 2Audit trails: who did what and when, with before and after values for sensitive changes.
3. 3Access roles that support segregation of duties.
4. 4Error handling and exception reports.
5. 5Interface controls such as record counts and control totals.

Before coding starts, users, QA, security, operations and sometimes the auditor review the design against the requirements.

Gaps found here cost a meeting. Once approved, the design becomes a baseline, and later changes go through change control.

Each phase finishes and is approved before the next starts: requirements, design, build, test, implement.

It gives clear structure, strong documentation and defined approvals, which suits stable requirements and regulated work. The catch: users only see the system near the end, and changing requirements late is expensive.

A quick working model lets users react to something real, which clarifies fuzzy requirements. But prototypes are built fast and loose.

1. 1Controls, security and audit trails are left out.
2. 2The prototype gets put into production as-is.
3. 3Scope creep from endless feedback.
4. 4Users expect the real system as fast as the prototype.

Imagine renovating a house one room at a time. You finish the kitchen, live with it for a couple of weeks, then decide what the bathroom needs based on what you've learned. That's agile.

Instead of one big delivery at the end, the team delivers working software every two to four weeks (a sprint), and users steer what comes next.

Old-style IT shipped software like a removal van: a huge load every few months, packed by one team and driven by another. DevOps works more like a conveyor belt in a factory: small items move along constantly, and every one passes through the same automated checks.

Development and operations work as one team, and automation does the repetitive, error-prone work.

RAD delivers quickly through user workshops, iterative prototypes, small skilled teams, reusable parts and timeboxing: the delivery date is fixed and scope flexes to fit.

Low-code and no-code platforms (the modern form of 4GLs) let business users build apps by dragging and dropping. That's powerful, and risky: apps appear outside IT's SDLC with no access roles, no audit trail, no separate test environment and live connections to sensitive data.

A newspaper has a style guide so every article reads the same, and an editor who reads every piece before it's printed. Writers don't edit their own work, because you never spot your own mistakes.

Software works the same way: coding standards are the style guide, and code review is the editor.

Review by someone other than the author finds logic errors, security holes, departures from standards, and unauthorised or malicious code such as back doors and logic bombs.

1. 1Restrict who can read and change source code.
2. 2Version control records who changed what, when and why.
3. 3Developers have no write access to production libraries.
4. 4Production executables must match an approved source version.
5. 5Source changes go through change management.

Users run real business scenarios in a production-like environment, then user management formally signs off. That sign-off is a key go-live control. QA testing (QAT) covers the technical side: standards, documentation, operations.

After any change, rerun the earlier tests with the same data and the same expected results. Any difference means the change broke something.

Needed after every change: enhancements, bug fixes, patches, configuration changes, even emergency fixes. Automated test suites make it practical.

Does the new or changed system live happily alongside the other systems on the same platform? It mustn't hog resources, clash over shared libraries or damage shared data.

This is about coexistence, not just the data passing between systems, which is interface or integration testing.

When you buy a new flat, you walk round with a snagging list: cracked tile, door that sticks, missing socket. The builder fixes each one, and you check it yourself before ticking it off. You don't take the builder's word for it.

Defect management is the same discipline for software.

Test exit criteria set the limit, for example zero critical defects and only a few high ones with workarounds. If the business still wants to go live with known defects:

1. 1Workarounds are documented and shared with users.
2. 2The business owner formally accepts the risk.
3. 3Fixes are scheduled.

When you move house, you decide what to take, throw out the junk, label the boxes, and count them at the other end. If a box goes missing, you want to know before the van leaves.

Data conversion is moving house for data. A shiny new system is useless if the balances, customers or reference data arrive wrong or incomplete.

IT runs the conversion. But the data belongs to the business, so the data owner reviews the reconciliation and signs off that the data is complete and accurate.

Dirty data should be cleaned in the source first. Migrating it just moves the mess into the new system.

1. 1Keep a backup of the source data and the conversion logs.
2. 2They're needed for audit, legal retention and investigating differences.
3. 3And for fallback, if the new system has to be abandoned.
4. 4Conversion programs are programs: tested and change-controlled like any other.

Think about switching to a new phone. You could carry both for a week until you trust the new one (parallel). You could move your contacts first, then photos, then apps (phased). Your partner could try the model first (pilot). Or you could drop the old phone in a drawer and go (abrupt).

Organisations face the same choice when a new system replaces an old one.

1. 1How critical is the system? How much disruption can the business take?
2. 2Can old and new physically run side by side?
3. 3Is there budget and staff for double work?
4. 4How many locations and users?
5. 5Is the new system modular?

Every changeover needs a written rollback plan, with the conditions for using it agreed in advance. It matters most for abrupt changeover, where the old system may be hard to restart once data has moved on.

Other go-live controls: a formal go/no-go decision, a cutover runbook with checkpoints, reconciled data before users start, extra support (hypercare), and clear user communication.

Go-live is when test shortcuts become real risks. Check that:

1. 1Production access matches approved roles.
2. 2Test, vendor and developer accounts are removed or disabled.
3. 3Default passwords are changed.
4. 4The system is hardened.

Before go-live, the auditor checks: control and security requirements met, testing adequate and signed off, conversion reconciled, access set up correctly, procedures documented, rollback plan in place.

A problem found now costs far less to fix than one found after go-live.

The project office, an independent team or internal audit. Whoever it is must be independent of the project.

An auditor who helped design the system's controls, or approved it, shouldn't review it. That would be marking their own homework.

1. 1An assessment against the business case and requirements.
2. 2Issues and corrective actions, each with an owner.
3. 3Lessons learned, fed back into the SDLC and project methodology.

1. 1Signatures or approval on source documents.
2. 2Access controls, so only authorised users can enter each transaction type.
3. 3Unique user IDs, so every entry can be traced to a person.
4. 4Workflow approval by a supervisor above set thresholds.
5. 5Terminal or location restrictions for sensitive inputs.

1. 1Before-and-after image reports, so every change can be reviewed.
2. 2Approval required for master file changes.
3. 3Transaction logs for the audit trail and recovery.
4. 4File labels and version checks, so the right file is used.
5. 5File security: only authorised users and programs update data.
6. 6One-for-one checking and prerecorded input to cut keying errors.

1. 1Distribution lists approved by the data owner.
2. 2Secure printing (release by badge or PIN) or secure electronic delivery.
3. 3Sensitive reports clearly labelled.
4. 4Recipients confirm receipt of critical reports or files.

Moving 500 from savings to your current account is two steps: take 500 out, put 500 in. What if the system crashes in between? What if your partner moves money at the same moment?

Databases follow four rules, ACID, so the answer is always 'your money is safe'.

Without isolation, transactions running at the same time cause trouble:

1. 1Lost update: two people edit the same record; one overwrites the other.
2. 2Dirty read: reading data another transaction hasn't committed yet.
3. 3Inconsistent read: data changes between two reads in the same transaction.

Data integrity tests are substantive tests, often run with CAATs over the whole database.

Relational integrity tests check fields and records: valid values, formats, required fields. Referential integrity tests check across tables: no orphans, relationships intact. Totals are also reconciled between related tables and systems.

Businesses used to post each other purchase orders and invoices. Each paper document carried a signature, a letterhead and a postmark, all evidence of who sent what and when.

Electronic data interchange (EDI) swaps the paper for standard electronic messages sent system to system. It's faster and cheaper, but every bit of evidence the paper gave you now has to be designed in.

A functional acknowledgement only says 'message received, and the format is valid'. It doesn't mean the supplier accepts the order; that needs a business-level reply.

And acknowledgements are useless unless someone chases the ones that never arrive.