💻 Comprehensive Study Notes: The System Life Cycle (9626 A Level IT)
Welcome to Topic 16! This is a core A Level concept that explains the organized journey a new IT system takes, from a simple idea to a fully operational and maintained solution. Think of it like building a massive skyscraper: you can’t just start laying bricks—you need careful planning, design, and testing.
Understanding the System Life Cycle (SLC) is crucial because it helps project managers deliver high-quality systems on time and within budget. Let’s break it down step-by-step!
16.1 The Definition and Stages of a System
What is a System?
In IT, a system is a collection of components that work together to achieve a common goal.
- A hardware system: Components like servers, monitors, and networking cables working together.
- A software system: Programs and applications working together (e.g., a massive accounting package).
- Most often, it’s a combination of hardware and software, plus the people and procedures that use them (e.g., an online banking system).
The Core Stages of the System Life Cycle (SLC)
The SLC describes the stages of developing a new system. Although different models exist, the basic stages usually follow this order:
- Analysis (Understanding the problem)
- Design (Planning the solution)
- Development and Testing (Building the system and fixing bugs)
- Implementation (Putting the new system into use)
- Documentation (Writing manuals)
- Evaluation (Checking if it works as required)
- Maintenance (Keeping it running and improving it)
The relationship between these stages is sequential in older models (like Waterfall), but they often overlap or repeat in modern methods (like Agile).
16.2 Phase 1: Analysis – Understanding the Needs
The analysis stage is where you figure out exactly what the new system must do. You are defining the problem, not solving it yet.
Methods of Researching a Given Situation
How does the analyst gather information about the current system (if one exists) and the user needs? (Mnemonic: QIDO)
- Questionnaires: Useful for gathering data from a large number of users quickly.
Advantage: Cheap, fast. Disadvantage: Low response rate, cannot clarify answers. - Interviews: Face-to-face discussions with key stakeholders (users, managers).
Advantage: Detailed, clarify ambiguous answers. Disadvantage: Time-consuming, interview bias possible. - Observation: Watching employees use the existing system to see how tasks are really performed (not just how manuals say they should be).
Advantage: Captures current processes accurately. Disadvantage: Employees might work differently when observed (Hawthorne effect). - Document Analysis: Reviewing existing documents, forms, reports, and manuals.
Purpose: To see what inputs and outputs are currently used, and identify data flow.
Content and Purpose of Specifications
The analysis culminates in producing detailed specifications documents:
- User Requirements Specification (URS):
Purpose: Describes what the user wants the system to achieve. It is non-technical and focuses on functionality (what it does) and non-functional requirements (speed, security). - System Specification (SRS):
Purpose: Translates the URS into a detailed, technical document outlining hardware, software, and networking requirements needed to build the system. - Design Specification:
Purpose: Details how the system will be constructed, including module structure, data storage methods, input/output formats, and testing procedures. This is the blueprint for the programmers.
⛔ Common Mistake: Don't confuse the URS (What the user wants) with the Design Specification (How the programmer will build it).
16.3 Phase 2: Design – The Blueprint
In this phase, we design the structure of the system, including how data flows, how it is stored, and what the interface looks like.
System Processing and Flow of Data
Designers use diagrams to illustrate the structure and data movement:
1. System Flowcharts: Use standard symbols (see syllabus Appendix) to show the flow of operations within an entire system, including manual processes and hardware components (e.g., input via keyboard, processing on a server, output to a magnetic disk).
2. Data Flow Diagrams (DFDs): Show how data moves through the system, independent of the hardware or software used. They focus only on the data itself.
- Level 0 (Context-level): Shows the entire system as one single process, illustrating its major inputs and outputs to external entities (sources/destinations).
- Level 1: Breaks down the Level 0 process into 3-7 major sub-processes, showing internal data stores.
- Level 2: Breaks down a single process from Level 1 into even greater detail.
Data Storage Design
The structure for holding data is crucial:
- Databases: Often used for complex, structured data requiring relationships (refer back to Topic 10).
- Files (Input and Output): Simple text files or structured files used for temporary storage or batch processing.
Input Forms and Output Reports
The design must specify exactly how users will interact with the system:
- Input Screen Layouts: Must include features like clear headings, instructions, logical flow, and appropriate use of forms for data collection. Importantly, they must include fields designed for validation and checking of collected data (e.g., drop-down menus, presence checks).
- Output Screen Layouts: How information is displayed on screen (e.g., dashboards, tables).
- Printed Copy Layouts: Specifies the layout for hard-copy reports (e.g., invoices, monthly summaries), ensuring readability and professionalism.
16.4 Phase 3: Development and Testing – Building and Checking
This phase involves writing the code and rigorously checking if the system meets the requirements.
Test Plans and Test Data
A test plan is essential; it details the tests to be carried out, the expected outcomes, and the criteria for success.
- Need and Purpose: To ensure the system meets the specifications and operates without error under expected and unexpected conditions.
- Contents of a Test Plan: List of test cases, test data, expected results, and resources needed.
Types of Test Data:
- Normal Data: Typical, expected data within the valid range (e.g., entering an age of 30, when the range is 18–65).
- Extreme Data: Data at the boundaries of the valid range (e.g., entering age 18 or 65).
- Abnormal Data: Invalid data, designed to test error handling (e.g., entering age 100 or "apple").
Types of Testing
We use different methods to catch different types of errors:
1. Alpha and Beta Testing
- Alpha Testing: Conducted by internal employees/developers before the system is released to the public. Focuses on finding major bugs and crashes.
- Beta Testing: Conducted by a large group of external, real users in a real-world environment. Focuses on usability, performance, and minor flaws missed during alpha testing.
2. White Box and Black Box Testing
- White Box Testing: The tester has full knowledge of the internal structure, code, and logic. They design tests specifically to check all paths and loops in the code. (Done by developers).
- Black Box Testing: The tester has no knowledge of the internal workings. They test the system purely based on its specifications (inputs and outputs). (Done by independent testers or users).
Advantages of Different Testing Types:
- Testing ensures robustness, security, and compliance with the specification.
- Beta testing provides valuable real-world feedback, improving user experience (UX).
16.5 Phase 4: Implementation – Going Live
Implementation is the process of putting the new system into active use, replacing the old one.
Methods of Implementing a System
The choice of method depends heavily on the risk tolerance of the organisation. Don't worry, these concepts are straightforward!
- Direct Changeover (Big Bang):
Description: The old system is immediately stopped, and the new system takes over completely.
Suitability: Low risk applications (e.g., a simple website update), or when the old system is unusable.
Advantage: Cheap, fast. Disadvantage: Very high risk if the new system fails. - Parallel Running:
Description: The old and new systems run side-by-side for a set period. Data is input into both.
Suitability: High risk applications (e.g., payroll or banking).
Advantage: Extremely low risk; if the new system fails, the old one provides backup. Disadvantage: Expensive (double data entry), time-consuming. - Phased Implementation:
Description: The system is introduced module by module or department by department.
Suitability: Large, complex systems with distinct components (e.g., HR, accounting, and inventory modules).
Advantage: Staff training is gradual; easier to isolate errors. Disadvantage: Slow process; compatibility issues between old and new modules. - Pilot Implementation:
Description: The new system is used by a small group of users or in one location first (the 'pilot'). Once successful, it is rolled out globally.
Suitability: Multi-branch organisations (e.g., a supermarket chain testing a new till system in one store).
Advantage: Errors are limited to a small group; training focuses on a few users first. Disadvantage: Pilot group may feel singled out; delays global rollout.
16.6 Phase 5 & 6: Documentation and Evaluation
Documentation: Why it is Needed
Documentation is critical for future maintenance and user adoption.
1. Requirements and Design Documentation:
- Includes the URS, System Specification, and Design Specification.
- Need: Provides a historical record of the system’s goals and structure.
2. Technical Documentation:
- Content: Program code, flowcharts, DFDs, hardware setup details, file structure (data dictionary).
- Need: Used by programmers and engineers for maintenance and future upgrades.
3. User Documentation:
- Content: Tutorials, FAQs, troubleshooting guides, error messages guide.
- Need: Helps end-users operate the system correctly.
4. Marketing Documentation:
- Content: Promotional materials, feature lists, pricing.
- Need: To sell the product to potential customers.
Evaluation: Checking Success
After implementation, the system is evaluated to see if it meets its original goals.
Evaluation involves assessing:
- Efficiency: Does it process data quickly?
- Ease of Use: Is the user interface intuitive?
- Appropriateness: Does it fulfil the original intended use?
Evaluation Techniques:
- Checking Against Specifications: Does the final system meet all points listed in the URS?
- Meeting User Requirements: Did the new system solve the user's initial problems?
- Feedback from Users: Gathering subjective input via questionnaires or interviews on usability and satisfaction.
16.8 Methods of Software Development
The SLC can be implemented using various models. The model chosen impacts flexibility, speed, and cost.
1. Waterfall Model
- Stages/Process: Strict sequential flow (Analysis -> Design -> Development -> Testing -> Implementation). One stage must be completed before the next begins.
- Advantages: Simple to manage, clear stages, good for small/simple projects where requirements are fixed.
- Disadvantages: Extremely rigid; difficult to go back and change requirements after development has started.
2. Iterative/Incremental Models (Agile, Iterative, Incremental)
- Stages/Process: The system is developed in small, repeating cycles (iterations). Each cycle delivers a small, working part of the system (an increment).
- Agile: A philosophy focusing on rapid delivery of working software and continuous collaboration with the client.
- Advantages: Client feedback is integrated early and often; highly flexible to changing requirements.
- Disadvantages: Lack of final, overall documentation; risk of scope creep (project keeps growing).
3. Rapid Application Development (RAD)
- Stages/Process: Focuses on rapid iteration and intense user involvement. Heavy use of prototyping tools and automated code generators to speed up development.
- Advantages: Extremely fast delivery; high user satisfaction due to constant involvement.
- Disadvantages: Requires highly skilled developers and specific tools; may sacrifice system quality for speed.
16.9 Prototyping – Building a Mock-up
A prototype is a working model of a system, often focusing on the user interface, to help clarify requirements before the final system is built.
Types of Prototyping
- Evolutionary: The prototype is continually refined and expanded until it becomes the final, operational system.
Why needed: For projects where requirements are initially vague. - Incremental: Different parts (increments) of the final system are developed as separate prototypes and then merged.
Why needed: For large systems where components can be built independently. - Throwaway: The prototype is built quickly just to clarify requirements, and then discarded. The final system is built from scratch based on lessons learned.
Why needed: To prevent poor design choices in the final, complex system. - Rapid: A general term for building a quick model, usually focusing on speed over complete functionality.
Advantages of Prototyping: Reduces risk; users can test usability early; better requirements gathering. Disadvantages: Users might mistake the prototype for the final system; time wasted if the prototype is thrown away.
16.10 Phase 7: Maintenance – Keeping the System Alive
Maintenance occurs throughout the system's operational life. It’s not just fixing things, but also improving them.
Types of Maintenance (The Four P's and C)
Maintenance is necessary because systems always encounter changes, bugs, or opportunities for improvement.
- Corrective Maintenance:
Why Needed: To fix bugs or errors that were not found during the testing phase. (e.g., A report calculates totals incorrectly.)
How Carried Out: Debugging and applying patches. - Adaptive Maintenance:
Why Needed: To change the system to function in a new environment, or adapt to new laws/regulations. (e.g., Updating the system to run on a new operating system or adhering to a new tax rate.)
How Carried Out: Modifying system components that interface with the environment. - Perfective Maintenance:
Why Needed: To improve the efficiency, usability, or performance of the system based on user feedback. (e.g., Making a process run faster or improving the clarity of a menu.)
How Carried Out: Optimising code, redesigning modules. - Preventive Maintenance:
Why Needed: To increase the system's reliability and lifespan by making changes that forestall future problems. (e.g., Refactoring messy code or improving documentation.)
How Carried Out: Reviewing and restructuring internal code modules.
We’ve covered the entire journey of an IT system! Make sure you can define, describe, and compare the advantages and disadvantages of all the methods covered in these stages.