Unit 3: Systems Development - Building the Digital World

Hello future IT architects! Welcome to the Systems Development chapter. Don't worry if this sounds intimidating; it’s simply about understanding the organised process we use to create new software, apps, or complex business IT systems.

Think of systems development like building a skyscraper. You can't just start laying bricks! You need plans, permits, budgets, and constant testing. This chapter teaches you the essential steps and tools required to build robust and successful IT solutions from scratch. Understanding this process is fundamental to the entire field of Information Technology. Let's get started!

1. Introduction to the Systems Development Life Cycle (SDLC)

The Systems Development Life Cycle (SDLC) is the structured framework that defines the stages involved in the creation, modification, or replacement of an information system. It ensures that systems are built efficiently, meet user needs, and stay within budget.

Key Stages of the SDLC

The SDLC is usually broken down into a series of mandatory, sequential steps. We will explore each in detail, but here is the basic flow:

  1. Analysis and Feasibility (What needs to be done? Can we do it?)
  2. Design (How will it look and work?)
  3. Implementation (Building and Testing)
  4. Evaluation and Maintenance (Is it working? How do we keep it running?)

Quick Review: The SDLC is like a blueprint for building an IT system. It ensures every base is covered before, during, and after construction.

2. Phase 1: Investigation, Analysis, and Feasibility

This is arguably the most important stage. If you get the requirements wrong here, the whole system will fail.

2.1 The Feasibility Study (Can We Do It?)

Before starting a project, a feasibility study is conducted to determine if the proposed system is viable and practical. This stops companies from wasting money on impossible projects.

We use the mnemonic TELOS to check the five areas of feasibility:

  • Technical: Do we have the necessary hardware, software, and skills to build this?
  • Economic: Is the system cost-effective? Will the benefits (e.g., increased profit, time savings) outweigh the costs of development? (This is often called a Cost/Benefit Analysis.)
  • Legal: Does the system comply with laws (e.g., Data Protection, accessibility regulations)?
  • Operational: Will the system actually work within the organisation's existing processes and culture? Will the staff use it?
  • Schedule: Can the project be completed within the required timescale?

Memory Aid: Imagine telling your boss, "I've checked the T E L O S for the project, and it's viable!"

2.2 Fact-Finding Techniques (What Do They Need?)

The goal of analysis is to figure out exactly what the users need. This is where the systems analyst acts like a detective, gathering facts about the existing system and the requirements for the new one.

Here are common Fact-Finding Techniques:

  1. Interviews: Face-to-face meetings with users, managers, and stakeholders.
    • Benefit: Allows for detailed questions and immediate clarification.
    • Drawback: Time-consuming; users might exaggerate problems.
  2. Questionnaires: Surveys distributed to many users (especially useful for large organisations).
    • Benefit: Quick way to gather data from many people; easily quantifiable results.
    • Drawback: No opportunity for follow-up or clarification of answers.
  3. Observation: Watching users perform their tasks in the current system.
    • Benefit: Gathers data on what users actually do, not just what they say they do.
    • Drawback: Users might change their behaviour if they know they are being watched (the Hawthorne effect).
  4. Document Analysis: Studying existing manuals, forms, reports, and procedures.
    • Benefit: Provides solid, concrete evidence of current processes and data flow.
    • Drawback: Documents may be outdated or incomplete.

Key Takeaway: Analysis defines the 'What'. Fact-finding tools help define the user requirements clearly, leading to the User Requirements Specification (URS).

3. Phase 2: Design

The design phase translates the ‘what’ (from the Analysis phase) into the ‘how’. The system analyst creates a detailed blueprint for the system components.

Components of System Design
  1. Input Design: How data is entered (e.g., designing data entry screens, forms, validation rules).
  2. Output Design: How information is presented (e.g., designing reports, screen layouts, summaries).
  3. File/Database Design: Designing the structure of the data storage (e.g., deciding which tables and fields are needed, relationships between data).
  4. Processing/Algorithm Design: Specifying the logic and steps the computer will follow to process the data.
  5. User Interface (UI) Design: Creating the look and feel of the system that the user interacts with, ensuring it is user-friendly and accessible.

Did you know? A good design requires minimal training because the system feels intuitive. A bad design can make an excellent program unusable!

4. Phase 3: Implementation and Testing

This phase involves the actual creation (coding) of the system, setting it up, and making sure it works correctly before rolling it out to the users.

4.1 Testing Strategies

Testing is crucial to finding and fixing bugs (errors) before the system goes live.

  • Module/Unit Testing: Testing individual parts (modules) of the code to ensure they work in isolation.
  • Integration Testing: Testing that different modules work correctly together when linked.
  • System Testing: Testing the entire system as a whole to see if it meets all the requirements specified during analysis.
  • Acceptance Testing (User Testing): Testing performed by the future users (the client) to ensure the system meets their needs and is ready for deployment. If it fails acceptance testing, the system is sent back for fixing.

Don't worry if this seems tricky at first: Think of testing a car. Unit testing is checking the engine, the brakes, and the steering wheel individually. Integration testing is checking if the brakes stop the wheels. System testing is driving the whole car to check performance. Acceptance testing is the buyer taking it for a final test drive!

4.2 Installation and Changeover Methods

Once tested, the new system must replace the old one (the legacy system). There are four main ways to do this:

  1. Direct Changeover (or Plunge): The old system is switched off immediately, and the new system is switched on.
    • Advantage: Cheapest and fastest.
    • Disadvantage: Highest risk. If the new system fails, there is no backup.
  2. Parallel Running: Both the old system and the new system run simultaneously for a period.
    • Advantage: Very low risk. Data can be compared, and if the new system fails, the old one is still operating.
    • Disadvantage: Requires double work and high running costs (staff must input data into two systems).
  3. Phased Implementation: The new system is introduced section by section or module by module.
    • Advantage: Allows users to slowly adapt and provides time for bugs in each phase to be fixed.
    • Disadvantage: Can be slow, and integration between the new and old sections may be complex.
  4. Pilot Running: The new system is introduced only in one specific branch or department of the organisation first.
    • Advantage: If problems occur, they are contained within a small area. Provides excellent user feedback before a full rollout.
    • Disadvantage: Staff in the pilot branch are under high pressure.

Common Mistake to Avoid: Parallel running means running *both systems* at the same time. Phased running means implementing *one piece of the new system* at a time.

5. Phase 4: Evaluation and Maintenance

The final stage ensures the system continues to meet the needs of the organisation over its lifespan.

5.1 Evaluation

After the system is installed, a formal evaluation checks its performance against the original User Requirements Specification (URS) and the initial objectives set in the analysis phase.

Key questions asked:

  • Did the system meet the functional requirements?
  • Is the system reliable and fast enough?
  • Is the system user-friendly and easy to maintain?
5.2 Types of Maintenance

Once operational, the system will always require maintenance to keep it relevant and bug-free.

  1. Corrective Maintenance: Fixing bugs and errors discovered after the system has gone live. (This should happen less frequently if testing was thorough.)
  2. Adaptive Maintenance: Modifying the system to cope with changes in the environment, such as new operating systems, new legal requirements, or changes in business policy.
  3. Perfective Maintenance: Improving system performance, usability, or efficiency based on user feedback (e.g., speeding up reports, refining screen layouts).

Key Takeaway: Maintenance is a continuous loop. It often leads back to the Analysis phase to define new requirements for upgrades.

6. Systems Development Methodologies

The SDLC defines the steps, but the methodology defines the *order* and *manner* in which those steps are executed.

6.1 Waterfall Model (Traditional Approach)

The Waterfall Model is a sequential, linear design process. Each phase must be fully completed and documented before the next phase can begin. It flows strictly downwards, like a waterfall.

Analogy: Building a house strictly according to the original blueprint.

  • Advantage: Simple to manage, clear documentation, good for projects where requirements are fixed and unlikely to change.
  • Disadvantage: Very inflexible. If a requirement error is found late in the Design or Implementation phase, it is very costly and difficult to go back and fix the Analysis phase. User feedback is often received too late.
6.2 Iterative/Evolutionary (Agile) Models

Iterative models (like Agile methodologies) break the development into small, rapid cycles (iterations). A small version of the system is built, tested, and reviewed by the user quickly, and then the process repeats to add more features.

Analogy: Baking a cake and tasting it after every major ingredient is added, allowing adjustments before the final product.

  • Advantage: High flexibility, requirements can change easily, constant user feedback ensures the final product meets exact needs, and users get a working system (even if basic) very quickly.
  • Disadvantage: Requires strong communication and commitment from the client. Documentation can sometimes be rushed or incomplete. Estimating the total time and cost can be difficult.

Quick Review Box:
Waterfall: Rigid, good for known requirements, sequential steps.
Agile: Flexible, good for changing requirements, uses cycles/iterations.