Welcome to Design, Development, and Testing!
Imagine you want to build a brand-new house. You wouldn't just grab bricks and start laying them without a plan, would you? First, an architect draws detailed blueprints (Design). Next, builders construct the walls and fit the pipes (Development). Finally, inspectors check that the roof doesn't leak and the electrical wiring is completely safe (Testing).
Creating computer systems follows the exact same journey! In this chapter of AS 1: Approaches to Systems Development, we will explore how software systems move from ideas on paper to fully functional, bug-free applications. Don't worry if some of these terms seem tricky at first — we'll break everything down step-by-step with simple analogies and real-world examples.
1. The Design Stage
The Design Stage takes the requirements identified during systems analysis and turns them into a technical blueprint. The goal is to plan every single detail before writing any code, saving time, money, and headaches later on.
A. User Interface (UI) Design
The User Interface is how a human interacts with the computer system. Good interface design focuses on usability, clarity, and consistency.
Key elements of interface design include:
• Input Screens & Data Capture Forms: Designing text boxes, radio buttons, drop-down lists, and checkboxes so users can enter data easily and without confusion.
• Output Screens & Reports: Ensuring that information presented on-screen or in printed reports is clearly structured, readable, and uses appropriate charts, tables, or headings.
• Navigation: Creating logical menus, navigation bars, and buttons (like "Next", "Back", and "Submit") so users never get lost.
• Accessibility & Aesthetics: Using clear fonts, high-contrast colour schemes, and consistent layouts across all screens.
B. Data Structures & File Design
System designers must decide how data will be stored efficiently and securely behind the scenes.
• Database Tables: Grouping related data into tables (e.g., tblCustomer, tblOrders).
• Field Definitions: Assigning appropriate Data Types (e.g., Text, Integer, Boolean, Date/Time) and Field Sizes to conserve storage space.
• Keys: Choosing a Primary Key (a unique identifier for each record, such as StudentID) and setting up Foreign Keys to create relationships between tables.
C. Process & Algorithm Design
Designers must plan the logic of how data flows through the system. Instead of jumping straight into programming languages, they use standard planning tools:
• Structure Charts: Visual diagrams that break a large system down into smaller, manageable sub-routines (known as a top-down modular approach).
• Flowcharts: Diagrams using standard geometric shapes (like diamonds for decisions and rectangles for processes) to show the step-by-step logic of an algorithm.
• Pseudocode: A structured way of writing algorithms using plain English combined with programming-like structures (e.g., IF... THEN... ELSE, WHILE... DO).
D. Data Validation and Verification
Computers follow the rule: GIGO (Garbage In, Garbage Out). If bad data enters the system, bad results will come out. Designers must specify robust checks to prevent errors.
1. Validation: An automatic computer check to ensure data entered is reasonable, sensible, and acceptable according to set rules.
Common validation checks include:
• Presence Check: Ensures a required field cannot be left blank (e.g., entering an email address when registering).
• Range Check: Ensures numbers fall within an acceptable upper and lower limit (e.g., exam marks between \(0\) and \(100\)).
• Length Check: Ensures data contains an exact or maximum number of characters (e.g., a UK postcode must not exceed 8 characters).
• Format / Picture Check: Ensures data follows a specific pattern of letters and digits (e.g., National Insurance number: LL 99 99 99 L).
• Type / Character Check: Ensures only the correct type of characters are entered (e.g., only numbers in a telephone field).
• Lookup Check: Compares entered data against a predefined list of acceptable values (e.g., selecting a title from Mr, Mrs, Miss, Dr).
• Check Digit: A mathematical calculation performed on the digits of an identification number to produce an extra final digit, used to verify transmission or scanning accuracy (e.g., ISBN book barcodes).
2. Verification: Checking that data has been copied across or entered accurately from the original source document.
The two main methods of verification are:
• Double Data Entry: Entering the same data twice by two different people (or by the same person twice, such as when creating a new password). The computer compares both entries and flags any differences.
• Visual Check (Proofreading): The user manually reads through the data on screen and compares it against the original paper document before submitting.
Memory Trick:
• Validation = Is it valid? (Does it follow the rules?)
• Verification = Is it verified? (Is it an exact match to the source?)
Quick Review: The Design Stage
• Design creates the technical blueprint (screens, reports, databases, algorithms).
• Validation checks if data is reasonable (automatic).
• Verification checks if data is correct against the source (double entry or visual check).
2. The Development (Implementation) Stage
During the Development Stage, software engineers take the blueprints produced in the design phase and construct the actual working system.
A. Modular Programming
Rather than writing one massive, messy program, developers use a modular approach. They break the software into small, independent chunks called modules, functions, or procedures.
Benefits of modular programming:
• Teamwork: Different programmers can work on separate modules at the same time.
• Easier Debugging: Errors can be isolated and fixed inside a specific module without breaking the whole system.
• Reusability: A well-written module (e.g., a tax calculation function) can be reused across different parts of the program or in future projects.
B. Coding Standards and Good Practice
To make sure code can be easily understood, maintained, and updated by other developers in the future, good programmers follow strict conventions:
• Meaningful Variable Names: Using self-explanatory identifiers like totalStudentScore rather than vague letters like x or temp.
• Comments / Annotations: Adding explanatory notes within the code (e.g., // Calculate discount based on customer type).
• Indentation & White Space: Indenting loops and conditional blocks cleanly so the code hierarchy is easy to read.
• Constants: Using named constants (e.g., VAT_RATE = 0.20) instead of hardcoding raw numbers.
C. Dealing with Programming Errors
No programmer writes perfect code on the first try! Developers must identify and resolve three types of errors:
• Syntax Errors: Mistakes in the grammar or spelling of the programming language (e.g., typing PRNT instead of PRINT). The program will not compile or run until these are fixed.
• Runtime / Execution Errors: Errors that occur while the program is running, causing it to crash unexpectedly (e.g., dividing a number by zero or trying to open a file that doesn't exist).
• Logic Errors: The code runs without crashing, but it produces the wrong result because the underlying algorithm or formula is flawed (e.g., writing area = width + height instead of area = width * height).
Quick Review: The Development Stage
• Modular programming splits problems into manageable, reusable components.
• Good coding style (comments, indentation, meaningful names) makes code maintainable.
• Errors come in three flavours: Syntax (broken rules), Runtime (crashes mid-run), and Logic (wrong answer produced).
3. The Testing Stage
Testing is not something left until the very last minute — thorough planning begins during the design phase! Testing ensures the system is robust, reliable, meets all user requirements, and handles unexpected events gracefully.
A. Creating a Test Plan
A Test Plan is a structured document that specifies exactly what will be tested, how it will be tested, and what outcome is expected.
A comprehensive test plan usually contains:
• Test ID: A unique reference number (e.g., T01).
• Test Description: What feature is being tested (e.g., Age validation on sign-up form).
• Test Data: The exact values entered into the system.
• Type of Test Data: Normal, Boundary, or Erroneous.
• Expected Result: What the system should do (e.g., Display error message "Age must be 18 or older").
• Actual Result: What the system actually did when tested.
• Remedial Action: What changes need to be made if the test failed.
B. Types of Test Data
To test a system thoroughly, developers must feed it three distinct types of test data.
Example Scenario: A system only accepts ages from \(18\) to \(65\) inclusive.
• Normal (Valid) Data: Data that is completely acceptable and falls well within the expected limits. It should be processed successfully.
Example: \(25\), \(40\), \(52\)
• Extreme / Boundary Data: Data that sits right on the outer edges of acceptability (the minimum and maximum allowed values), as well as values immediately outside the boundary. This checks whether boundary conditions (e.g., \(<\) vs \(\le\)) are coded correctly.
Example: \(18\) (valid minimum), \(65\) (valid maximum), \(17\) (just below minimum), \(66\) (just above maximum)
• Erroneous / Invalid Data: Data that is completely incorrect or of the wrong type and should always be rejected with a clear error message.
Example: \(-5\), \(120\), "Twenty", "!#$%", or leaving the field completely blank.
C. Testing Strategies and Methods
System testing is carried out using different viewpoints and techniques:
1. Black-Box Testing vs. White-Box Testing:
• Black-Box Testing: The tester checks inputs and outputs without looking at or knowing the internal code. They test the system from the perspective of an end-user to ensure functional requirements are met.
• White-Box Testing: The tester has full access to the source code and designs tests to check every possible logic path, loop, and branch in the program code to ensure structural integrity.
2. Levels of Testing:
• Unit Testing: Testing individual modules or sub-routines independently to ensure they work in isolation.
• Integration Testing: Combining individual modules together to verify that data passes correctly between them without interface errors.
• System Testing: Testing the entire completed system as a unified whole against the original user requirements and performance specifications.
• Acceptance Testing: The final phase where the actual client or end-users evaluate the software to confirm whether it is ready for real-world deployment.
D. Alpha vs. Beta Testing
Acceptance testing typically happens in two distinct phases:
• Alpha Testing: Carried out internally by the software company's in-house testing team or developers in a simulated environment. The goal is to catch major bugs before any real customers see the software.
• Beta Testing: The software is released to a selected group of real external users (often volunteers or early-access customers) who use it in their actual everyday environments. These users report real-world bugs, performance issues, and general feedback back to the developers.
Quick Review: The Testing Stage
• Test plans compare Expected Results with Actual Results.
• Three data types: Normal (typical), Boundary/Extreme (edges), and Erroneous (invalid).
• Black-Box = inputs/outputs only; White-Box = inspecting internal source code logic.
• Alpha = internal in-house testing; Beta = external real-world user testing.
Common Exam Pitfalls to Avoid
• Mixing up Validation and Verification: Remember, validation is an automatic algorithm check for reasonableness (e.g., range check), while verification checks for accuracy against the source (e.g., double entry). A piece of data can be valid but completely incorrect (e.g., mistyping an age as \(22\) instead of \(21\) passes a range check, but fails verification!).
• Vague Boundary Data Examples: When asked for boundary/extreme data for a rule like "between 1 and 10 inclusive", give the exact boundary numbers: \(1\) and \(10\) (and the immediate outside values \(0\) and \(11\)). Don't just write "numbers near the edge".
• Confusing Alpha and Beta Testing: Remember that Alpha is internal (developers/in-house staff), whereas Beta is external (real end-users in real operating conditions).