Welcome to the System Life Cycle (SLC)!
Ever wondered how massive IT systems—like the one used by your favorite online shop or your school’s grading portal—actually get built? They don’t just appear overnight! They follow a strict set of steps called the System Life Cycle (SLC).
Think of the SLC like building a house. You wouldn't just start laying bricks, right? You’d talk to the owner, draw blueprints, build it, and then check if the roof leaks. In these notes, we’ll walk through each stage so you can master the process for your exams. Don't worry if it seems like a lot of steps at first—we'll break it down piece by piece!
1. Analysis: The "Detective" Phase
Before building anything, we need to understand the current problem. In this stage, a Systems Analyst looks at the existing system (even if it’s just a paper-based one) to see what’s working and what isn't.
Fact-Finding Methods
To get the full picture, the analyst uses several methods to gather information:
- Interviews: Talking one-on-one with managers or workers. Example: Asking a shop manager why they think their current checkout process is slow.
- Questionnaires: Giving out forms to many people at once. Great for getting a lot of data quickly from many users.
- Observation: Watching how the current system is used in real life. Sometimes people forget to tell you things in interviews that you only see by watching them work!
- Document Collection: Looking at existing paperwork, invoices, or digital files to see how data currently flows.
The Requirement Specification
Once the detective work is done, the analyst writes a Requirement Specification. This is a list of exactly what the new system MUST be able to do.
Analogy: This is like a shopping list before you go to the store. If it’s not on the list, it doesn't get bought!
Quick Review:
Analysis is about identifying the problem and the requirements using interviews, questionnaires, observation, and document review.
2. Design: The "Architect" Phase
Now that we know what is needed, we have to plan how it will look and work. This is the Design phase. We create the "blueprints."
What gets designed?
Everything the user sees and everything the computer does behind the scenes:
- Input Screens: What will the data entry forms look like? Are they easy to use?
- Output Formats: How will reports or receipts look?
- Data Structures: What tables and fields are needed in the database?
- Validation Rules: What rules will stop "junk" data from entering the system? (e.g., making sure a "Date of Birth" isn't in the future).
- Hardware and Software: What specific computers or operating systems are required?
Did you know?
If you get the design phase wrong, the whole project might fail. It’s much cheaper to fix a mistake on a drawing than it is to fix a mistake in a finished piece of software!
3. Development and Testing: The "Builder" Phase
This is where the actual coding happens. Once the system is built, we have to try and "break" it to make sure it's reliable. This is called Testing.
Types of Test Data
To be thorough, we use three specific types of data:
- Normal Data: Data that the system should accept. Example: If a system accepts ages 1 to 100, entering '25' is normal.
- Extreme Data: Data at the very edges of what is allowed. Example: Entering '1' or '100'.
- Abnormal (Erroneous) Data: Data that is clearly wrong and should be rejected. Example: Entering '-5', '150', or the word 'Banana' into an age field.
The Testing Methods
Tests are usually done in two main stages:
- Alpha Testing: Done by the developers themselves to find major bugs.
- Beta Testing: The system is given to a small group of "real users" to try out before the official launch.
Key Takeaway:
Never assume a system works! Always test it with Normal, Extreme, and Abnormal data to ensure it’s robust.
4. Implementation: The "Moving In" Phase
This is the big day! We turn off the old system and turn on the new one. There are four main ways to do this, and you need to know the pros and cons of each.
1. Direct Changeover
The old system is stopped completely, and the new one starts immediately.
Pro: It’s fast and the cheapest method.
Con: If the new system fails, you have nothing to fall back on! This is high risk.
2. Parallel Running
The old and new systems run at the same time for a while.
Pro: Very safe. If the new system crashes, you still have the old one.
Con: It’s a lot of extra work for staff because they have to enter data twice!
3. Phased Implementation
The new system is introduced one part at a time. Example: A supermarket might start using the new system for the "Bakery" section only, then move to "Frozen Foods" next week.
Pro: If something goes wrong, it only affects one small part of the business.
4. Pilot Running
The new system is installed in one branch or office to see how it goes.
Pro: If it works well there, it's rolled out to everyone else. If it fails, only that one branch is affected.
Memory Aid:
Think of Pilot like a TV Pilot episode. They make one episode first; if people like it, they make the whole season!
5. Documentation: The "Manuals"
No system is complete without instructions. There are two types of Documentation:
- User Documentation: Created for the people who will use the system every day. It includes "How-to" guides, FAQs, and troubleshooting for common errors.
- Technical Documentation: Created for IT professionals who might need to fix or upgrade the system later. it includes things like Data Dictionaries, Flowcharts, and Annotated Code.
Common Mistake:
Don't confuse the two! User docs are for running the system; Technical docs are for maintaining or repairing it.
6. Evaluation and Maintenance: The "Check-up"
A few weeks after implementation, we perform an Evaluation. We ask: "Does it actually meet the Requirements we wrote in Stage 1?"
Types of Maintenance
Systems often need changes after they are finished. We call this Maintenance:
- Corrective Maintenance: Fixing bugs that weren't caught during testing.
- Adaptive Maintenance: Changing the system because the world changed (e.g., a new government tax law or a new version of Windows).
- Perfective Maintenance: Making the system even better or faster, even if it wasn't strictly broken.
Final Quick Review:
The SLC is a cycle: Analysis -> Design -> Development -> Implementation -> Documentation -> Evaluation. Once evaluation is done, the cycle often starts all over again to make the system even better!