Occupational Specialism: Project 2024

Introduction

The T-Level Digital Production, Design and Development Occupational Specialism Project (OSP) is a substantial piece of coursework that forms a critical component of the T-Level qualification. The OSP is designed to assess learners’ ability to apply technical knowledge and skills in a realistic workplace context, demonstrating competency across multiple domains, including software development, project planning, testing methodologies, and professional practices. The project requires learners to design, develop, and evaluate a complete digital solution that addresses a defined business need, whilst adhering to industry standards for code quality, security, accessibility, and regulatory compliance.

The purpose of the OSP within the qualification framework is to provide evidence of occupational competence that goes beyond theoretical knowledge, requiring learners to demonstrate practical application of skills in a sustained, complex project. Assessment criteria encompass not only the technical implementation but also the quality of planning, the effectiveness of testing and iterative development, the appropriateness of design decisions, and the ability to reflect critically on the development process. This holistic assessment approach ensures that learners develop the breadth and depth of skills required for employment in digital technology roles.

I undertook this project with a dual purpose. Firstly, as an educator delivering the T-Level qualification, I wanted to gain firsthand experience of the OSP requirements and assessment criteria to better support my learners through their own projects. By completing the OSP myself, I could identify potential challenges, understand the time and effort required, and develop more effective teaching strategies and resources. Secondly, I wanted to deepen my own understanding of what constitutes high-quality work at this level, enabling me to provide more accurate and constructive feedback to learners and to set appropriate expectations for project scope and quality.

This report documents my approach to the OSP, the decisions I made throughout the development process, the technical implementation details, and a critical reflection on areas for improvement. By articulating my reasoning and evaluating my work against the assessment criteria, I aim to demonstrate the level of insight and self-awareness expected of learners, whilst also creating a resource that can inform my teaching practice and support learners in understanding what is expected of them in their own OSP submissions.

Table of Contents

• Introduction
• 1. Project Overview
• 2. Logic Behind My Decisions
• 3. Technical Detail
• 4. Implementation
  • 4.1 Functionality
  • 4.2 Code Organisation
  • 4.3 User Experience
  • 4.4 Legal and Regulatory Guidelines and Standards
  • 4.5 Suitability of Test Data
  • 4.6 Use of Testing to Inform Iterative Development
  • 4.7 Quality of Iterative Development Process
• 5. Improvements
  • 5.1 Functionality Improvements
  • 5.2 Code Organisation Improvements
  • 5.3 User Experience Improvements
  • 5.4 Legal and Regulatory Compliance Improvements
  • 5.5 Test Data Improvements
  • 5.6 Testing Process Improvements
  • 5.7 Iterative Development Process Improvements
• 6. Collecting Feedback
  • 6.1 Gathering Feedback from Technical Users
  • 6.2 Gathering Feedback from Non-Technical Users
  • 6.3 Methods and Tools for Collecting Actionable Feedback
• 7. Expected Marks and Justification
  • Overall Expected Grade: Distinction
  • Marks Breakdown

1. Project Overview

The Riget Zoo Adventures project is a comprehensive web-based booking and management system designed for a fictional zoo attraction. The system serves as a complete digital solution for managing visitor bookings, educational tours, animal information, and administrative functions. The project demonstrates the practical application of web development principles, database management, and user-centred design within a real-world business context.

The primary purpose of this project is to create a functional, user-friendly platform that enables visitors to explore animal information, book tickets and hotel accommodation, arrange educational tours, and contact the zoo administration. Simultaneously, the system provides administrative staff with robust tools to manage bookings, respond to enquiries, and maintain the zoo’s digital presence. The project encompasses both public-facing features and secure administrative functionality, demonstrating a complete understanding of full-stack web development.

This project is particularly important as it addresses the real-world challenge of digitising customer-facing services in the leisure and tourism sector. By implementing online booking capabilities, the system reduces administrative overhead, improves customer experience through 24/7 accessibility, and provides valuable data insights for business operations. The project showcases the ability to translate business requirements into technical solutions whilst maintaining security, usability, and regulatory compliance.

Furthermore, the project serves as evidence of competency across multiple technical domains required for the T-Level qualification, including server-side programming, database design, user interface development, testing methodologies, and adherence to legal and regulatory standards. The comprehensive nature of the system demonstrates not only technical proficiency but also project planning, iterative development, and professional documentation practices essential for industry readiness.

2. Logic Behind My Decisions

My approach to this project was fundamentally driven by the principle of creating a maintainable, scalable, and user-centred solution. I began by thoroughly analysing the project brief and mark scheme to identify the core functional requirements and assessment criteria. This analysis informed my decision to adopt a modular architecture that separates concerns between database operations, business logic, and presentation layers. By establishing clear boundaries between these components, I ensured that the codebase would remain manageable as complexity increased and that individual components could be tested and modified independently.

The planning phase involved creating a comprehensive directory structure that reflects industry best practices. I organised the project into distinct folders for database operations (db/), reusable functions (functions/php/), templates (templates/), and assets (assets/). This structure was chosen to facilitate code reuse, improve navigation for developers, and support the principle of separation of concerns. I also implemented an initialisation system (init.php) that handles environment detection and path configuration, making the application relocatable and suitable for deployment in various hosting environments, including subdirectories.

One of the key challenges I faced was balancing feature richness with development time constraints. To address this, I prioritised core functionality first, establishing the database schema, implementing user authentication, and creating the primary booking workflows. Once these foundational elements were stable, I iteratively added enhanced features such as the loyalty programme, educational tour requests, and administrative dashboards. This incremental approach allowed me to maintain a working system throughout development whilst progressively adding value, which also facilitated continuous testing and validation.

Another significant decision involved the choice of database schema design. I opted for a relational approach using SQLite, with separate tables for users, bookings, animals, settings, and educational requests. This normalised structure prevents data redundancy and ensures data integrity through foreign key relationships. I also implemented a migration system within the Database.php class that automatically adds missing columns when the schema evolves, demonstrating an understanding of database versioning and backwards compatibility—critical considerations for real-world applications that must support ongoing development without data loss.

3. Technical Detail

The project is built primarily using PHP for server-side logic, HTML5 for semantic markup, CSS3 for styling and responsive design, and JavaScript for client-side interactivity. PHP was chosen as the core backend language due to its widespread adoption in web hosting environments, extensive documentation, and native support for database operations through PDO (PHP Data Objects). PHP’s procedural and object-oriented capabilities allowed me to structure the application using both functional programming for simple operations and object-oriented design for complex components like the Database class.

For data persistence, I selected SQLite as the database engine. SQLite is a lightweight, serverless database that stores data in a single file, making it ideal for development, testing, and small to medium-scale deployments. This choice eliminated the need for separate database server configuration, simplified deployment, and reduced infrastructure complexity whilst still providing full SQL capabilities and ACID compliance. The use of PDO for database interactions ensures that the code could be adapted to other database systems (such as MySQL or PostgreSQL) with minimal modifications, demonstrating portability and adherence to abstraction principles.

Alternative technologies I considered included Node.js with Express for the backend, which would have provided a JavaScript-based full-stack solution and potentially better performance for concurrent connections. However, I decided against this due to the additional complexity of managing asynchronous operations and the steeper learning curve for server-side JavaScript. I also considered using a full-fledged relational database like MySQL, but opted for SQLite to reduce deployment complexity and focus development effort on application logic rather than database administration. For the frontend, I considered using a JavaScript framework such as React or Vue.js, but chose vanilla JavaScript to maintain simplicity, reduce dependencies, and demonstrate fundamental DOM manipulation skills without framework abstractions.

The chosen technology stack directly supported the project’s functional requirements by providing robust server-side processing for form handling, session management, and database operations through PHP; reliable data storage and querying through SQLite; semantic, accessible markup through HTML5; responsive, modern styling through CSS3; and enhanced user interactivity through JavaScript. This combination represents a proven, industry-standard approach to web application development that balances functionality, maintainability, and deployment simplicity whilst demonstrating comprehensive technical competency across the full web development stack.

4. Implementation

4.1 Functionality

The project’s functionality was implemented through a series of interconnected PHP scripts and database operations. Core features include user registration and authentication (handled by auth.php and login.php), booking submission and management (booking-submit.php, query-bookings.php), educational tour requests (education-tour-submit.php), and contact form processing (contact-submit.php). Each functional module follows a consistent pattern: validate user input, sanitise data to prevent SQL injection and XSS attacks, perform database operations using prepared statements, and provide user feedback through session-based flash messages.

The booking system supports multiple booking types (tickets and hotel accommodation) with dynamic pricing based on room type, number of nights, and ticket quantities. I implemented a loyalty programme that automatically calculates discounts based on user tier (Bronze, Silver, Gold, Platinum), demonstrating complex business logic integration. The administrative interface provides CRUD (Create, Read, Update, Delete) operations for managing bookings, users, and educational requests, with role-based access control ensuring that only authenticated administrators can access sensitive functions.

Session management is implemented throughout the application to maintain user state, store authentication credentials securely, and display contextual messages. The helpers.php file contains utility functions for common operations such as redirecting users, displaying flash messages, checking authentication status, and formatting data for display. This centralisation of helper functions promotes code reuse and maintains consistency across the application.

Database operations are abstracted through the Database class, which provides static methods for initialisation, schema management, and data retrieval. The class implements automatic schema migrations that detect missing columns and add them dynamically, ensuring backwards compatibility as the database schema evolves. This approach demonstrates an understanding of database versioning and the challenges of maintaining data integrity during iterative development.

4.2 Code Organisation

The codebase is organised using a modular directory structure that separates concerns and promotes maintainability. The db/ directory contains database-related files including the Database class, installer script, and the SQLite database file. The functions/php/ directory houses all business logic and utility functions, organised by purpose (authentication, booking operations, form processing, helpers). The templates/ directory contains reusable header and footer components that are included across all pages, ensuring consistent layout and reducing code duplication.

Each PHP file begins with comprehensive documentation comments that describe the file’s purpose, author, and package affiliation. Functions are documented with parameter types, return types, and descriptions following PHPDoc conventions. This documentation serves both as inline reference for developers and as input for automated documentation generation tools. The use of consistent naming conventions (camelCase for functions, snake_case for database columns) and indentation improves code readability and reduces cognitive load when navigating the codebase.

The application follows the principle of separation of concerns by isolating database operations, business logic, and presentation layers. Database queries are never embedded directly in presentation files; instead, they are encapsulated in dedicated functions or class methods. This separation facilitates testing, as business logic can be validated independently of the user interface, and improves security by centralising data access patterns where they can be audited and secured consistently.

Configuration management is handled through the init.php file, which defines constants for root directory paths and base URLs. This centralised configuration approach makes the application relocatable—it can be deployed in different directory structures or hosting environments without modifying individual files. The installer script (db/installer.php) automates initial setup by creating the database schema, seeding example data, and creating the default administrator account, demonstrating an understanding of deployment automation and user onboarding.

4.3 User Experience

User experience was prioritised through responsive design, intuitive navigation, and clear feedback mechanisms. The interface employs a consistent visual hierarchy with prominent headings, clearly labelled form fields, and descriptive button text. CSS media queries ensure that the layout adapts gracefully to different screen sizes, providing an optimal viewing experience on desktop, tablet, and mobile devices. The navigation menu is positioned prominently and includes contextual links based on user authentication status (e.g., “Login” for guests, “My Bookings” and “Logout” for authenticated users).

Form validation is implemented both client-side (using HTML5 validation attributes and JavaScript) and server-side (using PHP validation functions) to provide immediate feedback whilst maintaining security. Error messages are displayed clearly using session-based flash messages that appear at the top of the page, styled distinctively to draw attention. Success messages use a different colour scheme to provide positive reinforcement when operations complete successfully. This dual-layer validation approach balances user convenience with robust security.

The booking workflow is designed to minimise cognitive load by breaking complex processes into logical steps. For hotel bookings, users first select their check-in date and number of nights, then choose a room type with clearly displayed pricing, and finally review their booking details before confirmation. Each step provides clear instructions and visual cues (such as required field indicators and date pickers) to guide users through the process. The confirmation page summarises the booking details and provides a reference number, giving users confidence that their transaction was successful.

Accessibility considerations include semantic HTML5 elements (such as <nav>, <main>, <article>, and <section>) that provide structural meaning for assistive technologies, descriptive alt text for images, sufficient colour contrast ratios for text readability, and keyboard-navigable interfaces. Form labels are explicitly associated with their input fields using the for attribute, ensuring that screen readers can correctly announce field purposes. These accessibility features ensure that the application is usable by the widest possible audience, including users with disabilities.

4.4 Legal and Regulatory Guidelines and Standards

The project adheres to several legal and regulatory standards relevant to web applications and data processing. Password storage follows security best practices by using PHP’s password_hash() function with the bcrypt algorithm, ensuring that user credentials are never stored in plain text. This approach complies with data protection principles that require appropriate technical measures to secure personal data. User authentication is implemented using secure session management with HTTP-only cookies to prevent client-side script access, mitigating XSS attack vectors.

Data validation and sanitisation are applied consistently across all user inputs to prevent SQL injection, cross-site scripting (XSS), and other injection attacks. All database queries use prepared statements with parameterised inputs, ensuring that user-supplied data is treated as data rather than executable code. Output encoding is applied when displaying user-generated content to prevent malicious scripts from executing in other users’ browsers. These security measures align with OWASP (Open Web Application Security Project) guidelines for secure web application development.

The application collects and processes personal data including names, email addresses, postal addresses, and booking information. Whilst a full privacy policy and cookie consent mechanism were not implemented due to project scope constraints, the data collection is limited to information necessary for the booking service, demonstrating the principle of data minimisation required by GDPR (General Data Protection Regulation). In a production environment, additional features such as privacy notices, consent management, data retention policies, and user rights mechanisms (access, rectification, erasure) would be essential for legal compliance.

The codebase includes attribution comments and licensing information where appropriate, acknowledging the use of third-party resources and demonstrating respect for intellectual property rights. The project repository includes documentation that describes the system’s purpose, installation procedures, and usage instructions, supporting transparency and maintainability. These practices reflect professional standards for software development and demonstrate an understanding of the legal and ethical responsibilities associated with creating digital products.

4.5 Suitability of Test Data

Test data was carefully designed to represent realistic usage scenarios whilst covering edge cases and boundary conditions. The animal database includes diverse species across multiple categories (Birds, Mammals, Reptiles, Aquatic), each with detailed descriptions, habitat information, dietary requirements, and conservation status. This variety ensures that the animal browsing functionality can be tested with different data volumes and content types, validating that the interface handles both short and long descriptions appropriately.

User test accounts were created with different roles (standard users and administrators) to validate role-based access control and ensure that administrative functions are properly restricted. Test bookings include various combinations of booking types (tickets and hotel), dates (past, present, future), quantities, and room types to verify that pricing calculations, date validations, and booking confirmations work correctly across different scenarios. The inclusion of cancelled bookings tests the cancellation workflow and ensures that cancelled items are handled appropriately in booking lists and administrative reports.

Educational tour requests include diverse scenarios such as different group sizes, age ranges, mobility requirements, and special considerations (allergies, behavioural needs). This comprehensive test data validates that the form correctly captures all required information and that the administrative interface displays it clearly for review. Contact form submissions include various enquiry types and message lengths to test form validation, data storage, and administrative response workflows.

The test data was designed to be representative of real-world usage whilst remaining appropriate for an educational context. No sensitive personal information (real names, addresses, payment details) was included, and all test accounts use clearly identifiable test credentials (e.g., [email protected]) to prevent confusion with production data. This approach demonstrates an understanding of data privacy principles and the importance of maintaining clear boundaries between test and production environments.

4.6 Use of Testing to Inform Iterative Development

Testing was integrated throughout the development process using an iterative approach that combined manual testing, user feedback, and systematic validation against requirements. After implementing each major feature, I conducted functional testing to verify that the feature worked as intended, followed by integration testing to ensure that it interacted correctly with existing components. This continuous testing approach allowed me to identify and resolve issues early, reducing the accumulation of technical debt and preventing defects from propagating through dependent features.

Manual testing involved systematically working through user workflows (registration, login, booking, cancellation) and verifying that each step produced the expected results. I maintained a test log documenting test cases, expected outcomes, actual outcomes, and any defects identified. When defects were discovered, I prioritised them based on severity and impact, addressing critical issues (such as authentication failures or data corruption) immediately whilst scheduling minor issues (such as cosmetic inconsistencies) for later iterations. This prioritisation ensured that the application remained functional throughout development.

User feedback was gathered informally from peers and instructors who reviewed the application and provided observations about usability, clarity, and functionality. This feedback informed several iterative improvements, including the addition of confirmation messages after booking submissions, clearer labelling of form fields, and improved error messages that provide actionable guidance rather than generic warnings. The iterative incorporation of user feedback demonstrates a user-centred development approach that prioritises real-world usability over purely technical correctness.

Regression testing was performed after each significant code change to ensure that new features or bug fixes did not inadvertently break existing functionality. This involved re-running previously successful test cases and verifying that outcomes remained consistent. The modular code organisation facilitated regression testing by limiting the scope of potential side effects – changes to the booking module, for example, were unlikely to affect the authentication system due to clear separation of concerns. This systematic testing approach provided confidence that the application remained stable and reliable as it evolved through multiple development iterations.

4.7 Quality of Iterative Development Process

The iterative development process was structured around clearly defined milestones that corresponded to major functional areas: database setup and schema design, user authentication, booking system, administrative interface, and educational features. Each milestone represented a complete, testable increment of functionality that added value to the application. This milestone-based approach provided clear progress indicators and ensured that development remained focused on delivering working features rather than incomplete prototypes.

Version control was employed throughout development using Git, with meaningful commit messages that describe the purpose and scope of each change. Commits were made frequently (after completing discrete units of work) to create a detailed history of the project’s evolution. This version control discipline facilitated experimentation – I could try alternative implementations knowing that I could revert to a previous working state if necessary. The commit history also serves as documentation of the development process, showing how the project evolved from initial wireframes through to the final implementation.

Code reviews and refactoring were performed periodically to improve code quality and maintainability. After implementing a feature, I would review the code for opportunities to extract common patterns into reusable functions, improve naming clarity, or simplify complex logic. For example, the initial booking submission code contained duplicated validation logic that was later refactored into a shared validation function. This continuous refactoring prevented the codebase from becoming unwieldy and demonstrated an understanding that code quality is not a one-time achievement but an ongoing practice.

Documentation was maintained alongside code development, with inline comments explaining complex logic and README files describing installation procedures and system architecture. The development log tracked major decisions, challenges encountered, and solutions implemented, providing a narrative of the development process that complements the technical artefacts. This comprehensive documentation approach ensures that the project is understandable to other developers and supports knowledge transfer, demonstrating professional development practices essential for collaborative software projects.

5. Improvements

5.1 Functionality Improvements

Whilst the current functionality meets the core requirements, several enhancements could improve the system’s capabilities and user value. Implementing a payment gateway integration (such as Stripe or PayPal) would enable real financial transactions, transforming the system from a booking request platform into a complete e-commerce solution. This would require additional security measures (PCI DSS compliance), transaction logging, and refund handling capabilities. Adding email notifications for booking confirmations, cancellations, and administrative updates would improve communication and provide users with permanent records of their transactions.

The booking system could be enhanced with availability checking that prevents double-booking of hotel rooms and limits ticket sales based on daily capacity. This would require implementing a calendar-based availability system with real-time inventory management. Adding a booking modification feature would allow users to change dates or quantities without cancelling and re-booking, improving flexibility and user satisfaction. Implementing a waiting list system for sold-out dates would capture demand and enable automatic notifications when capacity becomes available.

The administrative interface could be expanded with analytics dashboards showing booking trends, revenue reports, popular dates, and customer demographics. These insights would support data-driven decision-making for pricing, marketing, and capacity planning. Adding bulk operations (such as cancelling all bookings for a specific date due to weather or maintenance) would improve administrative efficiency. Implementing an audit log that tracks all administrative actions would enhance accountability and support compliance with data protection regulations.

The educational tour system could be enhanced with automated scheduling that proposes available time slots based on group size and staff availability, reducing back-and-forth communication. Adding customisable tour packages with different themes (conservation, animal behaviour, habitat ecology) would provide educational value and differentiate the offering. Implementing post-tour feedback collection would enable continuous improvement of educational programmes and provide evidence of learning outcomes.

5.2 Code Organisation Improvements

The current code organisation could be improved by adopting a more formal architectural pattern such as Model-View-Controller (MVC), which would further separate data models, business logic, and presentation layers. This would involve creating dedicated Model classes for each entity (User, Booking, Animal), Controller classes to handle request processing and orchestration, and View templates for rendering HTML. This structure would improve testability by allowing unit tests for models and controllers independently of the web interface.

Implementing dependency injection would reduce tight coupling between components and improve flexibility. Currently, many functions directly instantiate the Database class or access global session variables, making them difficult to test in isolation. Using dependency injection would allow mock objects to be substituted during testing, enabling comprehensive unit testing without requiring a live database. This would also facilitate future changes, such as swapping the SQLite database for MySQL, without modifying business logic code.

The error handling could be standardised using a custom exception hierarchy and centralised error logging. Currently, errors are handled inconsistently with some functions return false on failure, others set flash messages, and some throw exceptions. Implementing a consistent error handling strategy with custom exception types (ValidationException, DatabaseException, AuthenticationException) would make error handling more predictable and improve debugging. Centralised logging to files or external services would support production monitoring and troubleshooting.

The configuration management could be improved by externalising configuration values into environment-specific configuration files or environment variables. Currently, values such as database paths and pricing are embedded in code, making it difficult to maintain different configurations for development, testing, and production environments. Using a configuration management approach (such as .env files with a library like phpdotenv) would support environment-specific settings without code changes, improving deployment flexibility and security (by keeping sensitive credentials out of version control).

5.3 User Experience Improvements

The user interface could be enhanced with progressive disclosure techniques that show advanced options only when needed, reducing initial complexity whilst maintaining full functionality for power users. For example, the booking form could initially show only essential fields (date, quantity) with an “Advanced Options” section for loyalty programme details and special requests. Implementing auto-save functionality for partially completed forms would prevent data loss if users navigate away accidentally, improving resilience and user confidence.

The visual design could be modernised with a cohesive design system that defines colour palettes, typography scales, spacing units, and component styles. Currently, styles are defined ad-hoc in individual CSS files, leading to inconsistencies in spacing, colours, and component appearance. Adopting a design system (potentially using a framework like Bootstrap or creating a custom system) would ensure visual consistency, improve maintainability, and accelerate future development by providing reusable styled components.

Accessibility could be enhanced by conducting formal accessibility audits using tools like WAVE or axe DevTools and addressing identified issues. Implementing ARIA (Accessible Rich Internet Applications) attributes would improve the experience for screen reader users, particularly for dynamic content updates and complex interactive components. Adding keyboard shortcuts for common actions and ensuring full keyboard navigability would benefit users who cannot or prefer not to use pointing devices. Providing alternative text for all images and captions for any video content would ensure that visual information is accessible to users with visual impairments.

The mobile experience could be optimised with touch-friendly interface elements (larger tap targets, swipe gestures), simplified navigation for smaller screens, and performance optimisations to reduce load times on slower mobile connections. Implementing progressive web app (PWA) features such as offline functionality and home screen installation would enhance the mobile experience and provide app-like capabilities without requiring native app development. Adding location-based features (such as directions to the zoo using device GPS) would provide contextual value for mobile users.

5.4 Legal and Regulatory Compliance Improvements

To achieve full GDPR compliance, the application would need to implement comprehensive privacy notices that clearly explain what data is collected, why it is collected, how it is used, and how long it is retained. A cookie consent mechanism would be required to obtain user consent before setting non-essential cookies, with granular controls allowing users to accept or reject different cookie categories. Implementing data subject rights mechanisms would enable users to access their personal data, request corrections, request deletion, and object to processing, as required by GDPR Articles 15-21.

Security could be enhanced by implementing HTTPS encryption for all communications, protecting data in transit from interception and tampering. Adding Content Security Policy (CSP) headers would mitigate XSS attacks by restricting the sources from which scripts and other resources can be loaded. Implementing rate limiting on authentication endpoints would prevent brute-force password attacks. Adding two-factor authentication (2FA) would provide an additional security layer for user accounts, particularly for administrative accounts with elevated privileges.

The application should implement comprehensive audit logging that records all access to personal data, including who accessed what data, when, and for what purpose. This supports accountability requirements under GDPR and provides evidence for compliance audits. Implementing automated data retention policies that delete personal data after defined periods (unless there is a legal basis for continued retention) would demonstrate compliance with data minimisation principles. Adding data breach detection and notification procedures would ensure a timely response to security incidents as required by GDPR Article 33.

Accessibility compliance could be formally validated against WCAG (Web Content Accessibility Guidelines) 2.1 Level AA standards, with documented conformance claims and remediation plans for any identified gaps. Implementing an accessibility statement that describes the application’s accessibility features and known limitations would demonstrate a commitment to inclusive design. Providing alternative contact methods (phone, email, postal address) for users who cannot access the web interface would ensure that services remain accessible to all potential customers regardless of digital capability.

5.5 Test Data Improvements

The test data could be expanded to include more comprehensive edge cases and boundary conditions. For example, testing bookings with very large quantities (to validate that the system handles high-value transactions correctly), bookings far in the future (to test date handling and calendar systems), and bookings with special characters or unusual formatting in names and addresses (to validate input sanitisation and display handling). Including test cases for concurrent bookings (multiple users booking the same resource simultaneously) would validate transaction handling and prevent race conditions.

Implementing automated test data generation using tools like Faker would enable the creation of large, realistic datasets for performance testing and stress testing. This would help identify scalability issues before they impact real users. Creating test scenarios that represent different user personas (families, school groups, individual enthusiasts, international visitors) would ensure that the system meets diverse user needs and validates that the interface is understandable across different contexts and user backgrounds.

The test data could include negative test cases designed to trigger error conditions and validate error handling. For example, attempting to book with invalid dates (past dates, non-existent dates), invalid quantities (negative numbers, zero, extremely large numbers), and malformed inputs (SQL injection attempts, XSS payloads) would verify that validation and sanitisation functions work correctly. Including test cases for authentication failures (incorrect passwords, non-existent accounts, expired sessions) would validate security mechanisms.

Implementing a test data reset mechanism would enable consistent testing by restoring the database to a known state before each test run. This would eliminate dependencies between tests and ensure that test results are reproducible. Creating separate test databases for different testing purposes (unit testing, integration testing, user acceptance testing) would prevent test interference and support parallel testing activities. Documenting the test data structure and providing scripts to generate or restore test data would support collaboration and ensure that all team members can conduct testing effectively.

5.6 Testing Process Improvements

The testing process could be enhanced by implementing automated testing using frameworks such as PHPUnit for unit testing and Selenium or Cypress for end-to-end testing. Automated tests would enable regression testing to be performed quickly and consistently after each code change, reducing the manual effort required and increasing confidence in code stability. Implementing continuous integration (CI) that automatically runs tests on each commit would provide immediate feedback about code quality and prevent defective code from being merged into the main codebase.

The test coverage could be measured using code coverage tools that identify which lines of code are executed during testing. This would highlight untested code paths and guide the creation of additional test cases to improve coverage. Aiming for high code coverage (typically 80% or above for critical components) would increase confidence that the application behaves correctly across diverse scenarios. Implementing mutation testing, which introduces deliberate bugs to verify that tests detect them, would validate that tests are effective rather than merely achieving coverage metrics.

Performance testing could be conducted using tools like Apache JMeter or Gatling to simulate concurrent users and measure response times, throughput, and resource utilisation under load. This would identify performance bottlenecks and validate that the system can handle expected traffic volumes. Implementing performance budgets (maximum acceptable response times for key operations) would ensure that performance remains acceptable as features are added. Conducting security testing using tools like OWASP ZAP or Burp Suite would identify vulnerabilities such as SQL injection, XSS, CSRF, and authentication weaknesses.

User acceptance testing (UAT) could be formalised by creating detailed test scripts that guide testers through realistic scenarios and collect structured feedback. Involving actual end users (or representatives of target user groups) in UAT would provide authentic feedback about usability, clarity, and value. Implementing A/B testing for interface variations would enable data-driven decisions about design choices by measuring which variants perform better according to defined metrics (conversion rates, task completion times, user satisfaction scores). This evidence-based approach would improve the effectiveness of iterative improvements.

5.7 Iterative Development Process Improvements

The iterative development process could be formalised using an agile methodology such as Scrum or Kanban, with defined sprint cycles, backlog management, and regular retrospectives. This would provide structure for planning, prioritisation, and continuous improvement. Implementing sprint planning sessions would ensure that work is appropriately scoped and aligned with project goals. Conducting sprint reviews would provide opportunities to demonstrate progress to stakeholders and gather feedback. Holding retrospectives would enable the team to reflect on what worked well and what could be improved, fostering continuous process improvement.

The project could benefit from more comprehensive requirements documentation that captures functional requirements, non-functional requirements (performance, security, usability), and acceptance criteria in a structured format. Using user stories (“As a [user type], I want [goal] so that [benefit]”) would ensure that requirements are expressed from the user’s perspective and clearly articulate value. Implementing a requirements traceability matrix would link requirements to design decisions, implementation artefacts, and test cases, ensuring that all requirements are addressed and validated.

Code quality could be maintained through automated code analysis using tools like PHP_CodeSniffer (for coding standards compliance), PHPStan or Psalm (for static analysis), and SonarQube (for comprehensive quality metrics). These tools would identify potential bugs, code smells, security vulnerabilities, and deviations from coding standards automatically, providing objective quality metrics and actionable improvement recommendations. Implementing quality gates that prevent code from being merged if it fails quality checks would maintain high standards throughout development.

Collaboration could be enhanced through more structured code review processes using pull requests with defined review checklists and approval requirements. Implementing pair programming for complex features would improve code quality through real-time collaboration and knowledge sharing. Conducting regular knowledge-sharing sessions where team members present technical topics, demonstrate features, or discuss challenges would build collective expertise and improve team cohesion. Maintaining comprehensive project documentation (architecture diagrams, API documentation, deployment guides) would support onboarding of new team members and ensure that knowledge is preserved beyond individual contributors.

6. Collecting Feedback

6.1 Gathering Feedback from Technical Users

To collect feedback from technical users (such as developers, system administrators, or technical reviewers), I would implement several structured approaches. Code reviews would be conducted using pull request workflows in GitHub, where reviewers can comment on specific lines of code, suggest improvements, and approve or request changes. This provides detailed, contextual feedback directly within the development workflow. I would create a review checklist covering code quality criteria (readability, maintainability, performance, security) to ensure consistent and comprehensive reviews.

Technical documentation reviews would be conducted by sharing architecture diagrams, API documentation, and deployment guides with technical stakeholders and requesting feedback on clarity, completeness, and accuracy. Using collaborative documentation platforms like Confluence or GitHub Wiki would enable inline comments and suggestions. Conducting technical walkthroughs where I present the system architecture, database schema, and key implementation decisions to technical peers would facilitate discussion and surface alternative approaches or potential issues that may not be apparent from code review alone.

Static analysis tool reports (from tools like PHPStan, SonarQube, or security scanners) would provide objective technical feedback about code quality, potential bugs, security vulnerabilities, and adherence to coding standards. Sharing these reports with technical reviewers and discussing findings would provide concrete improvement opportunities. Implementing automated testing with coverage reports would demonstrate which code paths are tested and which require additional test coverage, providing a basis for technical discussion about testing strategy and quality assurance.

Performance profiling and load testing results would provide quantitative feedback about system performance under various conditions. Sharing these metrics with technical users and discussing bottlenecks, resource utilisation, and scalability considerations would inform optimisation priorities. Conducting security assessments (penetration testing, vulnerability scanning) and sharing findings with security-focused technical reviewers would identify security weaknesses and validate that security controls are effective. These technical feedback mechanisms would ensure that the system meets professional standards for quality, performance, and security.

6.2 Gathering Feedback from Non-Technical Users

To gather feedback from non-technical users (such as end customers, administrative staff, or business stakeholders), I would employ user-centred research methods that focus on usability, clarity, and value rather than technical implementation details. Usability testing sessions would involve observing users as they attempt to complete realistic tasks (such as booking tickets or finding animal information) whilst thinking aloud about their experience. This would reveal usability issues, confusing interface elements, and workflow problems that may not be apparent to developers who are intimately familiar with the system.

User surveys would be deployed using tools like Google Forms or SurveyMonkey to collect structured feedback from a larger user base. Surveys would include both quantitative questions (rating scales for satisfaction, ease of use, likelihood to recommend) and qualitative questions (open-ended feedback about what worked well and what could be improved). Distributing surveys after users complete key actions (such as submitting a booking) would capture feedback whilst the experience is fresh. Analysing survey responses would identify common themes and prioritise improvement areas based on frequency and severity of issues.

User interviews would provide deeper insights through one-on-one conversations with representative users. Semi-structured interviews with open-ended questions would allow users to describe their experiences, needs, and pain points in their own words. Conducting interviews with different user segments (families, school groups, individual visitors, administrative staff) would ensure that diverse perspectives are captured. Recording and transcribing interviews would enable detailed analysis and identification of recurring themes and unexpected insights.

Analytics and usage data would provide objective evidence of how users interact with the system. Implementing web analytics (using tools like Google Analytics or Matomo) would track metrics such as page views, bounce rates, conversion rates, and user flows. Analysing this data would reveal which features are used most frequently, where users abandon processes, and which pages have usability issues. Implementing event tracking for key actions (button clicks, form submissions, errors encountered) would provide granular insights into user behaviour. Combining quantitative analytics data with qualitative feedback from surveys and interviews would provide a comprehensive understanding of user experience and inform evidence-based improvements.

6.3 Methods and Tools for Collecting Actionable Feedback

To ensure that feedback is actionable, I would implement structured feedback collection processes with clear objectives, defined metrics, and systematic analysis. Creating feedback templates or forms with specific questions would ensure that feedback addresses relevant aspects of the system (functionality, usability, performance, value). For example, a usability testing script would define specific tasks for users to complete, observation criteria for researchers, and post-task questions to gather subjective impressions. This structure would ensure consistency across feedback sessions and facilitate comparison of results.

Implementing a feedback management system (such as a dedicated issue tracker or customer feedback platform like UserVoice or Canny) would centralise feedback from multiple sources (user surveys, support requests, code reviews, analytics insights) in a single location. Categorising feedback by type (bug report, feature request, usability issue, performance concern) and priority (critical, high, medium, low) would support systematic triage and planning. Linking feedback items to specific code changes or project milestones would enable tracking of how feedback is addressed and demonstrate responsiveness to user needs.

Conducting regular feedback review sessions with the development team and stakeholders would ensure that feedback is analysed and acted upon systematically. These sessions would involve reviewing recent feedback, identifying themes and patterns, prioritising issues based on impact and effort, and planning remediation actions. Documenting decisions made during these sessions would create an audit trail showing how feedback influenced development priorities. Communicating back to users about how their feedback was used (through release notes, blog posts, or direct responses) would demonstrate that feedback is valued and encourage continued engagement.

Implementing continuous feedback mechanisms (such as in-app feedback widgets, post-interaction surveys, or support chat) would enable users to provide feedback at the point of experience, when issues are most salient. Making feedback submission easy and low-friction would increase participation rates and capture more diverse perspectives. Analysing feedback trends over time would reveal whether changes are improving user experience and whether new issues are emerging. This continuous feedback loop would support ongoing iterative improvement and ensure that the system evolves in response to real user needs and experiences.

7. Expected Marks and Justification

Overall Expected Grade: Distinction

Estimated Total Marks: 85 to 95%

This project demonstrates comprehensive technical competency across all assessment criteria. The functionality is complete and polished, the code organisation is professional and maintainable, the user experience is well considered and accessible, security and regulatory awareness is evident, test data is appropriate and comprehensive, testing informed iterative improvements, and the development process was systematic and well documented.

The implementation includes a complete booking system supporting multiple booking types with dynamic pricing, user authentication with role based access control, an administrative interface with full CRUD operations, educational tour request management, and a contact system. The loyalty programme demonstrates advanced business logic with tier based discount calculations. All core user journeys are fully functional from registration through booking to cancellation, with appropriate validation, error handling, and user feedback at each stage.

The codebase demonstrates professional level organisation with clear separation of concerns, modular architecture, and consistent structure. Documentation is comprehensive with PHPDoc comments for functions, inline comments explaining complex logic, and HTML comments tracking development progress. The user interface employs responsive design, intuitive navigation, and clear feedback mechanisms with accessibility features including semantic HTML5 elements and keyboard navigability.

Security measures include password hashing using bcrypt, prepared statements for SQL queries, session management with HTTP only cookies, and input validation and sanitisation throughout. Test data is comprehensive and realistic, covering diverse scenarios, edge cases, and different user roles. Testing was integrated throughout development using an iterative approach combining manual testing, user feedback, and systematic validation against requirements.

Whilst there are areas for improvement (as detailed in Section 5), these represent opportunities for enhancement beyond the core requirements rather than deficiencies in meeting the brief. The project demonstrates not only technical skills but also professional practices including documentation, version control, iterative development, and user-centred design. The comprehensive nature of the implementation, attention to detail, and evidence of systematic development practices justify an overall grade in the Distinction band.

Marks Breakdown

Assessment Criterion	Expected Marks (%)	Justification Summary
Functionality	90 to 95	Comprehensive features including booking system, user authentication, admin interface, loyalty programme, and educational tours. All core journeys fully functional with appropriate validation and error handling.
Code Organisation	85 to 90	Professional level organisation with modular architecture, clear separation of concerns, comprehensive documentation, and consistent naming conventions throughout.
User Experience	80 to 85	Responsive design, intuitive navigation, clear feedback mechanisms, accessibility features, and logical workflows. Clean and professional interface appropriate for context.
Legal and Regulatory Compliance	75 to 80	Appropriate security measures implemented (password hashing, prepared statements, session management). GDPR features not fully implemented but awareness demonstrated.
Suitability of Test Data	85 to 90	Comprehensive, realistic test data covering diverse scenarios, edge cases, different user roles, and various booking types. Appropriate for educational context.
Use of Testing to Inform Development	80 to 85	Systematic manual testing, user feedback integration, regression testing, and test log documentation. Automated testing not implemented but manual approach thorough.
Quality of Iterative Development	85 to 90	Well structured milestones, version control with meaningful commits, periodic refactoring, and comprehensive documentation maintained throughout development.
TOTAL (Average)	85 to 90	Distinction Grade: Demonstrates comprehensive technical competency and professional development practices across all criteria.