Welcome to the Systems Development Life Cycle (SDLC)!
Hello there! Welcome to one of the most important chapters in your Information Management journey. If you have ever wondered how a company goes from saying "We need a new accounting software" to actually using it every day, you are in the right place.
The Systems Development Life Cycle (SDLC) is simply a step-by-step "roadmap" or "recipe" that organizations follow to build high-quality systems. Think of it like building a house: you wouldn't just start laying bricks on day one without a plan, right? You would talk to an architect, check your budget, and draw up blueprints first. That is exactly what the SDLC does for IT systems!
What is the SDLC?
The SDLC is a structured process used by organizations to plan, create, test, and deploy an information system. For a CPA, understanding this is vital because you will often be the person deciding if a project is worth the money, or you might be the "end-user" telling the IT team what the system needs to do.
Don't worry if this seems technical at first! We are going to break it down into five clear stages. A simple way to remember the flow is the acronym P-A-D-I-M:
1. Planning (and Feasibility)
2. Analysis
3. Design
4. Implementation
5. Maintenance
Stage 1: Systems Planning and Feasibility Study
This is the "Should we do this?" stage. Before spending millions of dollars, the company needs to know if the project makes sense.
The most important part of this stage is the Feasibility Study. We use the TELOS framework to check if the project is realistic:
T - Technical: Do we have the technology or skills to build this?
E - Economic: Do the benefits outweigh the costs? (As a CPA student, this is your home turf!)
L - Legal: Does the system follow data privacy laws (like PDPO in Hong Kong)?
O - Operational: Will the staff actually use it, or will they resist the change?
S - Schedule: Can we finish it in time?
Quick Review: If a project is technically possible but costs way too much, it fails the Economic Feasibility test and should probably be stopped here.
Stage 2: Systems Analysis
Now that we have decided to move forward, we need to ask: "What exactly does the system need to do?"
In this stage, the project team talks to stakeholders (the people who will use the system). They gather requirements.
Example: If you are designing a new payroll system, the "Analysis" stage involves asking the HR team, "What reports do you need? Do you need to calculate MPF automatically? Do you need to handle overtime?"
Common Mistake to Avoid: Skipping this stage or rushing it. If you don't define what you need now, you will end up with a system that doesn't work for the business later. This is often called "Requirement Creep" if you keep adding things later on!
Stage 3: Systems Design
In the Analysis stage, we looked at what the system needs to do. In the Design Stage, we decide how it will do it.
This is where we create the "blueprints." There are two parts:
1. Logical Design: The conceptual flow. How does data move from point A to point B?
2. Physical Design: The actual hardware, software, and database specs. Which servers will we use? What will the user interface (the screen) look like?
Analogy: If "Analysis" is saying "I want a car that can hold 5 people and goes fast," then "Design" is drawing the engine diagrams and picking the leather for the seats.
Stage 4: Systems Implementation
This is the "Action" stage! This is where the coding happens, the hardware is bought, and the system is actually put into the office.
A very important topic for your exam is System Conversion (moving from the old system to the new one). There are four ways to do this:
1. Direct Changeover: Turn off the old system on Sunday, turn on the new one on Monday.
Risk: High! If the new system crashes, you have nothing to fall back on.
2. Parallel Running: Run both the old and new systems at the same time for a while.
Risk: Low, but it is very expensive and double the work for staff.
3. Pilot Running: Try the new system in just one branch or department first.
Benefit: If it breaks, only one small part of the company is affected.
4. Phased Conversion: Introduce the new system in parts (e.g., start with the Invoicing module, then the Inventory module later).
Key Takeaway: Implementation also includes Testing and User Training. A system is useless if the employees don't know how to log in!
Stage 5: Systems Maintenance
The system is live! But the work isn't over. This stage is the longest because it lasts until the system is eventually replaced.
Maintenance involves:
- Corrective Maintenance: Fixing bugs that weren't found during testing.
- Adaptive Maintenance: Updating the system because something else changed (e.g., a change in tax laws).
- Perfective Maintenance: Making the system faster or better even if it isn't "broken."
Did you know? Most of the total cost of a system over its whole life actually happens in the Maintenance stage, not the building stage!
Summary Quick Review Table
Stage: Planning
Key Activity: Feasibility Study (TELOS)
Stage: Analysis
Key Activity: Gathering User Requirements
Stage: Design
Key Activity: Creating Blueprints (Logical & Physical)
Stage: Implementation
Key Activity: Coding, Testing, and Conversion (Direct, Parallel, etc.)
Stage: Maintenance
Key Activity: Fixing bugs and updating for new laws.
Final Tips for Success
When you see exam questions about SDLC, always ask yourself: "Where are we in the process?"
- If the question mentions budgets, think Planning.
- If it mentions interviews with staff, think Analysis.
- If it mentions risk of the system failing on day one, think Implementation (Conversion).
Keep practicing these stages, and you'll master this topic in no time! You've got this!