Welcome to Design, Development, and Testing!
Welcome to one of the most exciting and practical stages of Systems Development! Once a systems analyst understands exactly what a business needs (from the analysis stage), it is time to turn those ideas into reality. In this chapter, you will learn how systems are planned on paper (Design), constructed into working software (Development), and checked thoroughly to make sure everything works perfectly (Testing).
Don't worry if this seems like a lot to take in at first! We will break each stage down step-by-step using clear, real-world examples so you can tackle exam questions with total confidence.
1. The Design Phase: Creating the Blueprint
Think of the Design Phase just like an architect drawing up detailed plans before builders lay a single brick. If the plans are flawed, the final building will have problems. The design stage specifies how the system will solve the problems identified during analysis.
A. Input Design
Input design focuses on how data gets into the system accurately, quickly, and easily for the user.
• User Interface (UI) and Data Capture Forms: Designing clean, intuitive on-screen forms. Good input design uses appropriate controls like drop-down lists (to prevent typing errors), radio buttons (for single-choice options), and checkboxes (for multiple choices).
• Data Validation: Setting automated checks to ensure entered data is sensible and reasonable before the system accepts it. Common checks include:
- Range check: Ensuring numbers fall within set limits (e.g. month value between \(1\) and \(12\)).
- Presence check: Ensuring a required field is not left blank.
- Length check: Ensuring data has a specific number of characters (e.g. a UK postcode).
- Type/Format check: Ensuring only letters are typed into a name field or numbers into a phone field.
B. Output Design
Output design decides how information will be presented to the end user once processed.
• Screen Displays: Dashboards, graphs, and confirmation messages that are easy to read at a glance.
• Printed Reports: Invoices, summary reports, and receipts formatted with clear headings, page numbers, and dates.
• Accessibility Considerations: Using high-contrast colours and scalable fonts so visually impaired users can read the outputs comfortably.
C. Processing Design and Logic
This outlines the step-by-step instructions (algorithms) that transform inputs into outputs.
• Pseudocode: A plain-English representation of programming logic.
• Flowcharts: Visual diagrams using standard geometric shapes to map decisions and processes.
• Structure Diagrams: Hierarchical top-down diagrams breaking a complex program into smaller, manageable subroutines or modules.
D. Data and File Structure Design
How the system organizes and stores data permanently.
• Data Dictionary: A comprehensive table documenting technical details for every data field, including Field Name, Data Type (e.g. Text, Integer, Boolean), Field Length, and Validation Rules.
• Entity-Relationship (ER) Diagrams: Visual models showing how different database tables link to one another.
• Key Fields: Identifying the Primary Key (a unique identifier for each record), Foreign Key (a link to a primary key in another table), and Composite Key (combining two or more fields to create a unique ID).
E. Security Design
Protecting data from unauthorized access or accidental loss from day one.
• User Access Levels: Restricting permissions so staff only see data relevant to their role (e.g. sales staff cannot view payroll data).
• Authentication: Password policies, two-factor authentication (\(2\text{FA}\)), and biometric logins.
• Backup and Recovery: Designing automated backup schedules (e.g. daily cloud backups) and disaster recovery procedures.
Quick Review: The design phase creates detailed blueprints for Inputs, Outputs, Processing, Data Structures, and Security.
2. The Development Phase: Building the System
The Development Phase is where programmers and technical specialists write the actual code and build the solution according to the design blueprints.
Key Activities in Development:
• Modular Programming (Top-Down Approach): Instead of writing one giant, unmanageable block of code, developers break the system into smaller independent units or subroutines. This makes code easier to write, debug, and maintain.
• Hardware and Software Setup: Procuring, installing, and configuring servers, operating systems, database management systems, and client workstations.
• Data Conversion: Writing scripts to clean and migrate existing data from the old legacy system into the new database format.
• Internal Code Documentation: Adding comments inside the source code to explain complex algorithms so future developers can understand and modify the software easily.
Did you know? Writing clear comments in code is just like leaving breadcrumbs in a forest. If a bug appears six months later, comments allow any programmer to quickly trace what the code was supposed to do!
Key Takeaway: Development turns design models into working software through modular coding, system configuration, and data migration.
3. The Testing Phase: Ensuring Quality and Reliability
No software is complete without thorough testing. Even minor software bugs can cause severe financial losses or system crashes. Testing confirms that the system functions correctly, meets every requirement from the analysis stage, and handles errors gracefully.
The Test Plan
Testing is never random; it is guided by a formal Test Plan created during the design/development stages. A standard test plan contains:
• Test ID / Description: What specific feature or input is being tested.
• Test Data: The exact values typed into the system.
• Test Type: Normal, Extreme, or Erroneous.
• Expected Result: What the system should do if working properly.
• Actual Result: What the system actually did when executed.
• Remedial Action: What needs to be fixed if the expected and actual results do not match.
4. Types of Test Data
To ensure total reliability, systems must be tested using three distinct types of test data. Memory Aid: Think of the mnemonic N-E-E (Normal, Extreme, Erroneous).
Scenario Example: An exam mark field that only accepts scores between \(0\) and \(100\).
• 1. Normal (Valid) Data: Data that is completely within the acceptable range and of the expected format. It tests whether the system works under standard everyday conditions.
Example: Entering \(45\) or \(82\).
Expected Outcome: Accepted successfully.
• 2. Extreme (Boundary) Data: Data that sits at the absolute outer boundaries of what is acceptable.
Example: Entering the exact edge values \(0\) and \(100\).
Expected Outcome: Accepted successfully (as both are valid edge values).
• 3. Erroneous (Invalid / Exceptional) Data: Data that is outside the permitted limits, or completely the wrong data type. It tests whether the system rejects bad data without crashing.
Example: Entering \(-5\), \(101\), or typing the word "Pass".
Expected Outcome: Rejected with a helpful error message.
Common Mistake to Avoid: Confusing Extreme data with Erroneous data. Extreme data is valid data on the edge (e.g. \(100\)); values just beyond the edge (e.g. \(101\)) are erroneous.
5. Methods and Levels of Testing
A. White-Box Testing vs. Black-Box Testing
• White-Box (Structural) Testing: Testing conducted by developers who have full access to the source code. Every internal path, logic branch, and loop is tested to ensure internal algorithms execute efficiently.
• Black-Box (Functional) Testing: Testing conducted without looking at the internal source code. Testers only look at what goes in (input) and what comes out (output), verifying whether the software matches the user specification.
B. Levels of Testing (From Small to Large)
• 1. Unit / Module Testing: Testing each subroutine or function on its own in isolation to prove it works before connecting it to other parts.
• 2. Integration Testing: Combining individual modules together and testing them as a group to check that data passes correctly between them without communication errors.
• 3. System Testing: Testing the entire completed system as a unified whole across different hardware and network configurations.
• 4. Acceptance Testing: The final stage before the system goes live, ensuring real users and clients are satisfied that it meets business requirements. This includes:
- Alpha Testing: Carried out internally by the in-house development team and software specialists to catch major remaining bugs before release.
- Beta Testing: Releasing a nearly finished version to a selected group of real external end users in a live environment to gather practical feedback and spot unexpected real-world issues.
Chapter Summary & Key Takeaways
• Design: Creates the technical blueprint (forms, reports, algorithms, data dictionaries, ER diagrams, access controls).
• Development: Writes modular code, configures hardware and software, converts data, and documents internal logic.
• Testing: Follows a structured Test Plan using Normal, Extreme, and Erroneous data.
• Testing Progression: Moves systematically from Unit testing \(\rightarrow\) Integration testing \(\rightarrow\) System testing \(\rightarrow\) Acceptance testing (Alpha & Beta).