Welcome to Unit A2 2: Application Development (Case Study)
Welcome to your study guide for Unit A2 2: Application Development (Case Study) in CCEA GCE Digital Technology (Subject Code: 2650). This unit represents your major controlled assessment portfolio, accounting for 20% of your total A Level (and 40% of your A2 year). Over approximately 60 hours of controlled assessment time, you will work through an annual CCEA pre-released case study to design, build, test, and evaluate a fully functional relational database system for a real-world client.
Don't worry if building a complete software solution seems daunting at first! We will break the entire Systems Development Life Cycle (SDLC) down into five clear, structured stages. Let's explore each stage step by step so you can maximize your portfolio marks.
Stage 1: Analysis — Understanding the Problem
Before designing any software, an analyst must first understand what the client actually needs. If you build the wrong thing, it doesn't matter how well it works!
1. Identifying User Requirements
You must carefully comb through the pre-released case study scenario and extract two types of requirements:
• Functional Requirements: What the system must actually do (e.g., "The system must calculate total booking fees" or "The system must produce monthly sales summary reports").
• Non-Functional Requirements: How the system should perform in terms of quality, usability, or security (e.g., "Passwords must be encrypted" or "The interface must load records in under 2 seconds").
2. System Boundaries and Scope
Every system has limits. You must establish:
• Inputs: Data entered by staff or customers (e.g., customer name, booking dates).
• Processes: Actions performed on data (e.g., validating telephone numbers, calculating discounts).
• Outputs: Information generated (e.g., invoices, dispatch notes, on-screen confirmations).
• Constraints: Deadlines, budget limits, hardware restrictions, or software environment boundaries.
3. Data Flow Diagrams (DFDs)
A Data Flow Diagram (DFD) is a visual tool that maps how information travels through a system. In your portfolio, you will produce two standard levels using standard Gane & Sarson or Yourdon/DeMarco conventions:
Level 0 (Context Diagram): This provides a high-level bird's-eye view. It shows the entire system as a single central process bubble interacting with External Entities (such as 'Customer' or 'Manager') via inbound and outbound data flows.
Level 1 Diagram: This decomposes the Level 0 bubble into detailed subprocesses (e.g., 1.0 Register Customer, 2.0 Process Order, 3.0 Generate Invoice), showing the specific Data Stores (tables/files) where information is saved or retrieved.
Key DFD Symbols to remember:
• External Entity: A person, organization, or external system that sends or receives data (drawn as a rectangle).
• Process: An activity that transforms data (drawn as a rounded rectangle or circle).
• Data Store: A place where data is held at rest, such as a database table (drawn as an open-ended rectangle).
• Data Flow: An arrow showing the direction of data movement, labelled with the noun describing the data.
Key Takeaway for Stage 1: Clear requirements and accurate DFDs form the foundation of your entire project. Every feature you build later must link back to these initial user needs.
Stage 2: Design — Structuring the Solution
Once you know what the system must do, you design how it will work. Stage 2 requires precision and technical rigor.
1. Data Normalisation (0NF to 3NF)
Normalisation is a mathematical technique used to organize data into relational tables. Its purpose is to eliminate data redundancy (duplicate data) and prevent insert, update, and delete anomalies. You must show the step-by-step derivation from 0NF to 3NF in your portfolio:
• Unnormalised Form (0NF): Data in its raw state containing repeating groups (multiple values in a single field) and non-atomic data (e.g., full names that have not been split into first and last names).
• First Normal Form (1NF): Eliminate repeating groups. Make all data atomic (indivisible units) and identify a Primary Key (often a composite key).
• Second Normal Form (2NF): Must be in 1NF and all partial dependencies removed. Every non-key attribute must be fully functionally dependent on the entire primary key (applies to tables with composite primary keys).
• Third Normal Form (3NF): Must be in 2NF and all transitive dependencies removed. No non-key attribute can depend on another non-key attribute ("every field must depend on the key, the whole key, and nothing but the key").
2. Entity-Relationship (ER) Modelling
An Entity-Relationship Diagram (ERD) provides a graphical blueprint of your database tables (entities) and the logical links between them.
• Primary Key (PK): A unique identifier for every record in a table.
• Foreign Key (FK): A primary key from one table placed into another table to establish a link.
• Cardinality: Relationships can be One-to-One (\(1:1\)), One-to-Many (\(1:M\)), or Many-to-Many (\(M:N\)).
• Crucial Rule: A database cannot directly implement a Many-to-Many (\(M:N\)) relationship. You must resolve it by placing a junction entity (link table) between them, creating two \(1:M\) relationships!
3. The Data Dictionary
A comprehensive technical reference table specifying every field in your database. It must include:
• Entity Name: The table where the field lives.
• Attribute / Field Name: A sensible naming convention (e.g., CustomerID).
• Data Type: E.g., Short Text, Integer, Decimal/Currency, Date/Time, Boolean.
• Field Length / Size: Maximum characters allowed (e.g., 8 characters for a Postcode).
• Validation Rules: The technical criteria the field must meet.
• Validation Text / Error Message: The user-friendly message displayed if invalid data is entered.
• Key Designation: Clearly marked as PK (Primary Key) or FK (Foreign Key).
4. Interface and Navigation Design
Plan out user screens using wireframes and storyboards. Ensure your layouts adhere to standard Human-Computer Interface (HCI) principles: consistent colour schemes, intuitive navigation buttons, clear form field alignments, and readable fonts.
5. Process / Logic Design
Before writing code or building macros, use algorithmic flowcharts or structured pseudocode to plan automated routines, such as calculating discounts, checking stock availability, or running validation checks.
Key Takeaway for Stage 2: Never skip steps in normalisation! Show 0NF \(\implies\) 1NF \(\implies\) 2NF \(\implies\) 3NF clearly to secure maximum marks.
Stage 3: Development & Implementation — Building the System
This is where your designs come to life inside your relational database management software.
1. Tables and Referential Integrity
Construct your normalised tables. When creating relationships, always enforce referential integrity. This prevents orphan records (e.g., an order being created for a customer ID that does not exist in the Customer table) and allows cascading updates or deletes where appropriate.
2. Data Validation vs Data Verification
It is vital not to mix these two concepts up:
• Validation: An automated software check to ensure entered data is sensible, reasonable, and conforms to defined rules.
- Presence Check: Ensures mandatory fields are not left blank.
- Range Check: Ensures numbers/dates fall between lower and upper limits (e.g., \(1 \le \text{Age} \le 120\)).
- Format / Picture Check: Ensures data matches a specific pattern (e.g., LLNN NLL for postcodes).
- Length Check: Ensures data has a specific number of characters.
- Lookup Check: Restricts input to a predefined list of options.
• Verification: Checking that data has been accurately copied from the source document (e.g., double-entry verification or on-screen visual checks before submitting).
3. Database Objects
• Queries: Build selection queries, parameter queries (prompting the user for input), calculated queries, and Action Queries (INSERT, UPDATE, DELETE, append/make-table) using SQL or query design grids.
• Forms: User-friendly input screens featuring master-detail subforms, drop-down combo boxes, and command buttons powered by macros or event code.
• Reports: Professional management summary documents that group, sort, and calculate summary statistics (e.g., totals, averages) matching client specifications.
• Security Features: Implementing role-based user access permissions, login screens, input masking (hiding password characters), and automated backup mechanisms.
Key Takeaway for Stage 3: A great implementation combines robust table structures, airtight validation rules, and intuitive interface forms that make data entry effortless.
Stage 4: Testing — Proving System Reliability
Testing is not just clicking around to see if things work; it must be rigorous, structured, and fully documented.
1. The Structured Test Plan
CCEA requires a formal 7-column test plan table for your portfolio:
1. Test Number: A unique identifier for each test (e.g., Test 01).
2. Test Purpose / Requirement Tested: What functional requirement or validation rule is being verified.
3. Test Data Type: The classification of the data:
• Valid / Normal Data: Typical, expected data within acceptable limits.
• Boundary / Extreme Data: Data on the exact upper and lower limits of acceptable values.
• Invalid / Erroneous Data: Data outside acceptable boundaries or in the incorrect format.
4. Test Data Input: The exact values typed into the system.
5. Expected Result: What should happen according to your design specification.
6. Actual Result: What genuinely happened when the test was run.
7. Action Taken / Remediation: The fix or correction applied if a test failed.
2. Evidence of Testing
Every test listed in your plan must be supported by annotated screenshots showing the actual data entered, the resulting output, or the error message triggered.
Key Takeaway for Stage 4: Include boundary and invalid data tests! Testing only "happy paths" (normal data) is one of the most common pitfalls that loses marks.
Stage 5: Evaluation & User Documentation
The final phase reflects critically on what you have accomplished and equips the client to use the system.
1. Requirement-by-Requirement Review
Go back to the functional and non-functional user requirements you identified in Stage 1. Evaluate each requirement individually and categorize it explicitly as:
• Fully Met
• Partially Met
• Not Met
You must provide a clear technical justification explaining how your queries, forms, or automated code fulfilled that requirement.
2. Evaluation of Implementation & Limitations
Provide an honest, mature critique of your software:
• System Strengths: Highlight efficient query design, intuitive HCI features, and robust data validation.
• System Weaknesses & Performance Limitations: Identify areas where the system could struggle (e.g., scalability under heavy multi-user loads, file size bloat).
• Future Developments: Suggest realistic future upgrades (e.g., migration to cloud hosting, integration with mobile web interfaces).
3. User Guide and Technical Documentation
Provide clear step-by-step instructions with screenshots so that non-technical client staff can navigate the system, log in, enter records, run reports, and perform basic troubleshooting.
Key Takeaway for Stage 5: An evaluation is an evidence-based technical audit, not a personal reflection. Always link your success back to the Stage 1 requirements!
Quick Reference: Common Pitfalls to Avoid
• Vague Terminology: Avoid informal phrases like "connecting boxes" or "keeping it tidy". Always use proper technical terminology: referential integrity, foreign key constraint, transitive dependency, and atomic data.
• Incomplete Normalisation: Do not jump directly from 0NF to 3NF. You must show the working for 1NF and 2NF along the way.
• Unresolved Many-to-Many Relationships: Never leave an \(M:N\) relationship in your final ERD. Always resolve it with a linking junction entity.
• Missing Boundary Tests: Always test the edge values (e.g., if valid marks are \(0\) to \(100\), test \(-1\), \(0\), \(100\), and \(101\)).
• Generic Evaluations: Avoid vague statements like "The database worked well." Base every comment on specific user requirements from Stage 1.