Systems Development Life Cycle
Systems
Systems Development Life Cycle
Syllabus tag: KASNEB CPA | Foundation Level | CA16 Information Communication Technology | Topic 8 Systems Development Life Cycle
Lesson objectives
By the end of this topic, you will be able to:
- Set out the stages of the systems development life cycle
- Explain the purpose of a feasibility study
- Compare the waterfall, agile and prototyping approaches
- Compare methods of changeover
- Explain post-implementation review and maintenance
Why this matters
Most system failures are not technical. They come from building the wrong thing, testing it inadequately, or switching over badly — and an accountant is usually on the steering committee that approves each of those decisions.
The stages
- Preliminary investigation — is there a problem worth solving?
- Feasibility study — is a solution viable?
- Systems analysis — what does the system need to do?
- Systems design — how will it do it?
- Development — building and unit testing
- Testing — system, integration and user acceptance testing
- Implementation — changeover, training, data conversion
- Maintenance and review — keeping it working and useful
The cost of fixing an error rises sharply at each stage. A requirement misunderstood at analysis and discovered after implementation may mean rebuilding. This is the single strongest argument for spending time on analysis, and it is what candidates are expected to say.
The feasibility study
Five tests, remembered as TELOS:
| Test | Question |
|---|---|
| Technical | Can it be built with available technology? |
| Economic | Do the benefits exceed the costs? |
| Legal | Does it comply with data protection and other law? |
| Operational | Will it work in practice, and will staff use it? |
| Schedule | Can it be delivered in time to be useful? |
Operational feasibility is the one most often failed. A technically excellent system that staff resist, work around, or cannot use delivers nothing — and the resistance is usually predictable from how little those staff were consulted.
Economic feasibility uses cost-benefit analysis, and the difficulty is that costs are concrete — licences, hardware, training — while benefits are often intangible: better decisions, faster response, improved reputation.
Approaches to development
Waterfall. Each stage completed before the next begins. Well documented and easy to manage, and inflexible: requirements are fixed early, and users see nothing until the end. Suits stable, well-understood requirements.
Prototyping. A working model is built quickly, shown to users, and refined. Requirements emerge through use rather than being specified in advance. Suits unclear requirements, and risks endless revision and thin documentation.
Agile. Development in short iterations, each producing working software, with continuous user involvement. Responds well to change, and needs sustained user availability and disciplined teams to avoid drifting scope.
The choice follows the certainty of the requirements. Where they are known and stable, waterfall is efficient. Where they are unclear or likely to change, an iterative approach discovers them.
Testing
| Level | Purpose |
|---|---|
| Unit | Each component works alone |
| Integration | Components work together |
| System | The whole meets the specification |
| User acceptance (UAT) | Users confirm it meets their needs |
| Parallel run | Old and new produce the same results |
UAT is the one that matters here. System testing confirms the software does what the specification said; UAT confirms the specification was right. They are different questions and a system can pass one and fail the other.
Changeover
| Method | Description | Risk | Cost |
|---|---|---|---|
| Direct | Old system off, new on, at once | Highest | Lowest |
| Parallel | Both run together until confidence is gained | Lowest | Highest |
| Phased | Introduced module by module | Moderate | Moderate |
| Pilot | One site or department first | Moderate | Moderate |
Parallel running is the safest and the most expensive, because everything is processed twice and staff work double for the period. It is the standard choice for a payroll or general ledger, where an error is unacceptable and the old system provides a check.
Direct changeover is used where parallel running is impossible — where the two systems cannot coexist, or the volume makes duplication impractical. It is the highest-risk option and needs a tested fallback plan.
:::checkpoint A company plans a direct changeover of its payroll system on the last day of the month. Identify the risks and recommend an alternative, giving your reason. :::
Data conversion
Moving data from the old system to the new. It is routinely underestimated, and the reason is instructive: the old data usually contains duplicates, gaps and codes nobody now understands, all of which must be resolved before migration. Cleansing the data is often the longest task in the project.
Reconciling record counts and control totals before and after migration is the control, and it is the accountant's natural contribution.
Maintenance and review
| Type | Purpose |
|---|---|
| Corrective | Fixing faults |
| Adaptive | Responding to changes in the environment, such as a new tax rate |
| Perfective | Improving performance or usability |
| Preventive | Reducing the risk of future problems |
Post-implementation review asks whether the system delivered the benefits claimed in the feasibility study, and what the project should teach the next one. It is regularly skipped once the system is live and the team has moved on — which is exactly why the same mistakes recur.
:::checkpoint A feasibility study claimed a new system would save KES 4 million a year. Two years on, no one has checked. Explain what a post-implementation review would examine and why its absence matters beyond this one project. :::