Field Notes Archive
T Level Technical Qualification in Digital Production, Design and Development Mark Scheme Summer 2024 Occupational Specialism T Level Technical Qualification in Digital: Digital Pr...
Article Overview
Section 1
T Level Technical Qualification in Digital Production, Design and Development Mark Scheme Summer 2024 Occupational Specialism T Level Technical Qualification in Digital: Digital Production, Design and Development
T Level Technical Qualification in Digital: Digital Production, Design and Development - –
Section 2
Indicative content and marker guidance Students produce a proposal for a digital solution that they could develop to meet the needs of Riget Zoo Adventures (RZA)
Students’ proposals should be relevant to key requirements of the brief such as:
• Providing customers with help and information about the attractions and facilities • materials to support educational visits: • Online booking system. • account registration to allow customers to manage their bookings • Loyalty and reward scheme: • accessibility features to support a wide range of users
Section 3
The students’ proposals may refer to: • How the solution will handle data and pass it between back end and front end • How they will address issues/needs such as: ● Providing customers with help and information about the attractions and facilities o Interactive map o Real-time updates (e.g. closures, feeding times) ● materials to support educational visits: o Multimedia features o Tasks and activities o Content management system ● Online booking system: o Reserve and book tickets for zoo o check availability and book a stay at the hotel. ● account registration to allow customers to manage their bookings ● Loyalty and reward scheme: o Back-end for company (e.g. targeting customers, dashboard of information) o Customer facing features (e.g. account management, offers) o accessibility features to support a wide range of user • Digital content (e.g. Interactive map, quizzes, videos of animals, info about hotel rooms, hotel services ) • Accessibility features (e.g. alt text, resizable fonts, selectable colour schemes) – Possible reference to W3C Students’ proposals should refer to relevant risks and how they will mitigate these such as: • Malicious/inappropriate use – data input validation • Intercepting data / man in the middle attacks – use of SSL/Encryption/HTTPS. • Cross site scripting – content security policy/data input validation and sanitization. • SQL Injection – Sanitizing data input. • Anonymising data – privacy issues relating to loyalty scheme, personal info from ticket booking/hotel stays. • Mitigating localisation of data e.g., planning routes around the zoo, tracking location to maximise flow of people, booking specific times to visit busy/popular attractions.
Students’ rationale should refer to wider issues which are likely to include: • General issues such as: o Privacy o User support o feedback to users-errors (e.g. incorrect completion of forms, completion of transaction etc)
• Potential context-specific issues such as: o handling of personal and sensitive health data o users may be vulnerable due to specific health issues o licensing of APIs vs open-source data • Relevant regulations and guidelines (e.g. W3C, professional bodies, health advice/disclaimers) as well as legal requirements relating to software development and the context of the health industry. Students’ rationale should be relevant to current practice and/or emerging tech in the leisure and tourism sector • Apps and mobile devices • Maps and location-based services • Payment services (e.g. entry fees, purchases in the park, voucher and loyalty rewards) • Websites • AI – e.g., insights into busy times of day and potential busy dates.
Section 4
Students' rationale should include details of the functional and non- functional requirements, key performance indicators, user acceptance criteria that could be used to judge the success of a solution that they will implement. They must be appropriate for a solution that will meet the needs of
T Level Technical Qualification in Digital: Digital Production, Design and Development - –
Section 5
No rewardable material The proposal: • identifies some of the problems to be solved • Effectively decomposes some of the problems identified The proposed solution would effectively:
• meet some of the needs of the client and users • mitigating some of the potential risks • addressing some of the relevant regulatory guidelines and legal requirements, in relation to software development and the industry. The proposal: Identifies most of the problems to be solved Effectively decomposes most of the problems identified The proposed solution would effectively:
meet most of the needs of the client and users mitigate most of the potential risks address most of the relevant regulatory guidelines and legal requirements, in relation to software development and the industry. The proposal: • Fully identifies the problems to be solved • Effectively decomposes the problems identified The proposed solution would effectively: • meet the full needs of the client and users • mitigate the potential risks • address relevant regulatory guidelines and legal requirements, in relation to software development and the industry.
Section 6
1-3 4-6 7-9 Appreciation of wider issues in the context The proposal provides limited lines of reasoning that partially justify how:
• the recommended solution meets the needs of the client and users • potential risks will be mitigated • the proposed solution will address relevant regulatory guidelines and legal requirements, in relation to software development and the industry. The proposal provides good lines of reasoning that mostly justify how:
• the recommended solution meets the needs of the client and users • potential risks will be mitigated • the proposed solution will address relevant regulatory guidelines and legal requirements, in relation to software development and the industry. The proposal provides comprehensive lines of reasoning that fully justify how the:
Section 7
• the recommended solution meets the needs of the client and users • potential risks will be mitigated • the proposed solution will address relevant regulatory guidelines and legal requirements, in relation to software development and the industry. 1-2 3-4 5-6 Appreciation of the business context The proposal provides basic definitions of: • functional and non-functional requirements • key performance indicators • user acceptance criteria The proposal provides good definitions of: • functional and non-functional requirements • key performance indicators • user acceptance criteria The proposal provides comprehensive and perceptive definitions of: • functional and non-functional requirements • key performance indicators • user acceptance criteria
Section 8
Indicative content and marker guidance The design should provide details of the solution that is to be implemented by the student. The designs should be usable by third party to implement the intended solution. • layout and white space may include: o clear ‘zones’ which allow user to focus on specific content o Space between lines to aid readability. o related information is close together but do not encroach on each other o sensible breaks/separation of information to avoid overload o details of reactive layouts to suit different screens/devices (e.g. mobile and desktop version) • visual hierarchies may include: o Sensible and appropriate use of sizing if information/items to help optimize user information o Order of design elements (e.g. orders in navbars and menus) to signify significance or ‘route’ through information • common conventions include: o Include details of common design features which may include (but not limited to): • Common/recognizable icons (e.g. house = home) • Placement of navigation item (top or left) • Use of ‘hamburger’ button/collapsible menus for mobile layout. General ‘good’ design features to consider: • Clear branding • Aesthetic and minimalist design • Help and documentation • Feedback- give good error messages, actions need reactions- things to consider error prevention, auto detection of errors, clear error notification and possible hints solving problems • Use of imagery and other media to aid accessibility and understanding. • Avoiding inclusion of information which is irrelevant or rarely needed. • Ensuring good user experience through appropriate content and design.
Contextual considerations may include: • Booking form for hotel/tickets • Educational resources/quizes • Use of text, images, maps, graphs etc to make as appropriate to make information more accessible and relevant (e.g. map of the zoo, pictures of the rooms)
Section 9
Assessment focus Band 0 Ban d 1 Ban d 2 Ban d 3 0 1-2 3-4 5-6 Effectivenes s of the design interface
No rewardabl e material The proposed design interface is adequate as a result of reasonably effective use of: ● layout and white space ● visual hierarchies ● common conventions. The proposed design interface is good as a result of the effective use of: ● layout and white space ● visual hierarchies ● common conventions. The proposed design interface is excellent as a result of the sophisticated and highly effective use of: ● layout and white space ● visual hierarchies ● common conventions.
Section 10
Indicative content and marker guidance Decomposition coverage Students should select some key processes that would be appropriate to meet the needs of Riget Zoo Adventures. Key problems may include: • Handing user access e.g. Setting up an account, logging-in, changing password, • Accepting and processing payments for hotel/tickets • Collection and processing of data • Communication/data exchange between different platforms or between front-end and back-end systems • Key calculations e.g. cost of tickets, loyalty points • Data filtering and visualization e.g. park busy/quiet, personalised information based on loyalty scheme
Decomposition may be shown through descriptions or visualization e.g. decomposition diagrams, navigation maps etc.
Algorithms Maybe in the form of flowcharts, pseudocode, data flow diagrams, static and dynamic model diagrams or a combination of all three. Expected features of algorithm design may include: • the steps are clearly defined and depend on the input and the result of the preceding steps • the algorithm stops after a finite number of instructions are executed, two key constructs iterate and decide • the value/data for input is clearly identified and can be traced • type of output is clearly defined e.g., display to screen, return value from a function • logic of the algorithm is accurate • data flow is complete e.g. flow diagram doesn’t end unexpectedly, loops as appropriate etc. • correct use of symbols • Links to data, libraries and other resources clearly identified e.g. API, CSV, or Database file • Sensible names for functions, variables etc. • Use of keywords e.g. IF…THEN. WHILE…. • Indentation to aid readability and show logical dependency
Section 11
No rewardable material Basic decomposition of the identified problems that superficially cover the required: • inputs • processes • outputs Good decomposition of the identified problems that sufficiently cover the required: • inputs • processes • outputs Highly effective decomposition of the identified problems that comprehensively cover the required: • inputs • processes • outputs 1 - 2 3 -4 5 - 6
Application of logical thinking and conventions Algorithms would produce some correct outcomes as a result of: • some precise logic • some appropriate structure and sequence which is likely to be inefficient.
Some effective use of accepted conventions although inconsistencies still exist. Algorithms would produce mostly correct outcomes as a result of: • mostly precise logic • appropriate structure and sequence but which may lack efficiency.
Section 12
Mostly effective use of accepted conventions though some minor inconsistencies may still exist. Algorithms would produce consistently correct outcomes as a result of: • precise logic • efficient structure and sequence.
Section 13
Indicative content and marker guidance Data design may be in the form of: • data dictionaries, • entity-relationship diagrams, • data flow diagrams, • static and dynamic model diagrams or a combination as appropriate to describe the planned solution
Note – data normalisation may not be required depending on the identified/proposed solution.
Data considered should be appropriate for the needs of Riget Zoo Adventures which may include: • User profiles/accounts • Hotel availability • Ticket sales • Educational materials – e.g. quizes and learning exercises (keeping scores), personalisation based on age The design should show an understanding of error handling procedures which may include: • Data validation rules • Input masks • Type casting • Feedback to user/error messages • Limiting field/variable length
Section 14
No rewardabl e material Data requirements for the proposed solution are somewhat appropriate, including (as required): • variables • data structures • data types Data requirements for the proposed solution are mostly appropriate, including (as required): • variables • data structures • data types Data requirements for the proposed solution are fully appropriate, including (as required): • variables • data structures • data types Naming conventions used are mostly appropriate but are inconsistent. Naming conventions used are appropriate and mostly consistent. Thoroughly appropriate and consistent naming conventions are used throughout. Effective error handling procedures are identified for some inputs/processes that require them. Effective error handling procedures are identified for most inputs/processes that require them. Thoroughly effective error handling procedures are identified for the inputs/processes that require them. T Level Technical Qualification in Digital: Digital Production, Design and Development
Section 15
Indicative content and marker guidance Students produce a strategy of how they will test the for a digital solution that they intend to develop.
The test schedule should cover: • understanding of how components interrelate. This may include: o description of modules/functions that feed data into the component being tested o understanding of how correct/incorrect data form one part may impact on the component being tested o transition between unit testing and integration testing o Functional, non-functional and front-end testing • the order in which components should be tested: This may cover: o identification of pre-requisites and dependencies • the types of tests/testing techniques that are required to test the student’s solution such as: o Acceptance testing. o Alpha testing. o Beta testing. o Black box testing. o White box testing/structural testing
Section 16
No rewardable material The test strategy demonstrates a basic understanding of: • how components interrelate • the order in which components should be tested • the types of tests that are required. The test strategy demonstrates a good understanding of: • how components interrelate • the order in which components should be tested • the types of tests that are required The test strategy demonstrates a thorough and detailed understanding of: • how components interrelate • the order in which components should be tested • the types of tests that are required. T Level Technical Qualification in Digital: Digital Production, Design and Development
Section 17
Indicative content and marker guidance Appropriateness of communication of the design: • suitability for the intended audience • clarity • use of technical language • choice of tools / how information is presented.
No rewardable material 1-2 3-4 5-6 Quality of communication Some effective communication of the design as a result of: • some use of appropriate techniques, methods and formats • some use of technical language that is appropriate for the intended audience Mostly effective communication of the design as a result of: • the use of mostly appropriate techniques, methods and formats • the use of technical language that is mostly appropriate for the intended audience Communication of the design is consistently effective as a result of: • the use of consistently appropriate techniques, methods and formats • the use of technical language that is consistently appropriate for the intended audience T Level Technical Qualification in Digital: Digital Production, Design and Development
Section 18
Indicative content and marker guidance • Students demonstrate use of code to produce a solution that includes front-end and back-end processes to meet the needs of Riget Zoo Adventures
Functionality: ● Must demonstrate the use of two different languages, e.g. JS and PHP or SQL. Python and SQL etc. ● Use of logic and programming structure should be appropriate for the chosen language such as: o Modularisation o Appropriate interrelation of arts pf the program e.g. modules pass the correct data between each other, front-end and back-end processes have sufficient separation. o Suitable use of programming structures (sequence, selection and iteration) to solve problems in an efficient manner. o complex data models in database interlinking more than one table o Web service APIs and parsing JSON/XML to service a complex client- server model ● Examples of efficiency may include: o Avoidance of very linear structures to more logically and efficient approach e.g. the use of function and procedures o OOP design features (classes, inheritance etc.) o Recursive algorithms – reminder that if used in PHP here must be a mechanism (IF statement, etc.) that stops the recursion after the desired result has been found o Loading data only when necessary
Note – data normalisation may not be required depending on the identified/proposed solution
Section 19
The program should ensure correct outcomes to meet the needs of Riget Zoo Adventures for example: ● Handing user access e.g. Setting up an account, logging-in, changing password ● Collection and processing of data e.g. loyalty scheme, bookings for hotel/zoo, ● Key calculations e.g. loyalty/reward points, cost of stay, checking availability of rooms on specific dates, calculating maximum number of visitors ● Data filtering and visualisation e.g. red/amber/green for quiet/busy times, filtering upcoming and past bookings
Code organisation: ● Students should avoid multiple pages of nested if clauses and unnecessary repeated code that could more effectively be implemented as a called function ● Clear and meaningful indentation ● Code should consist of pieces of logic, classes, or objects, with proper structure. ● Comments should be used wherever possible to help explain the logic ● Good use of local variables and minimal use of global variables ● Use of constants ● consistent style throughout User Experience considerations: ● Inputs form the user are handled appropriately such as: o invalidation and sanitization o ease of user input e.g. GUI features, input masks o well-designed interface including UI/UX features: • Useful – does it meet the needs of the user? Are outputs etc. accurate • Usable – is it easy to use / intuitive? • Desirable – is it aesthetically pleasing? Does it represent a brand? Consistency. • Findable – is it easy to navigate around and find the required ● user guidance and error messages ensure that the product is easy to use and helpful which may include: o Short and meaning full error messages (avoid jargon) o Provides information about solution/corrective action that can be taken by the user o Help/instructions and/or meaningful feature labels to reduce errors ● A robust solution which may include: o good exception handling that can deal with unexpected or incorrect outputs o “fall back” code to deal with different systems and platforms without crashing o Appropriate use of validation
Section 20
● Accessibility has been considered and there should be evidence that their design takes different users in to account such as: o Selectable accessibility features (e.g. adjustable fonts, colours etc.) o Sensible font and colour base colour selection •Compatibility with different platforms has been considered (where appropriate) which may include: o Creating a standalone/self-contained program o Implementation of web-standards / program is accessible through a web browser o “fall back” code to deal with different systems and platforms ● legal and ethical considerations considered as appropriate to their solution which may include: o Cookie consent notice o GDPR considerations o Privacy and data policy/informing the user o Intellectual property consideration (see asset log) o Terms and conditions
T Level Technical Qualification in Digital: Digital Production, Design and Development Task 2 - –
Assessment focus Band 0 Band 1 Band 2 Band 3 Band 4 0 1-2 3-4 5-6 7-8 Functionality (Q02.1)
Section 21
No rewardable material The prototype implements code in a single language with some functionality but the code lacks efficiency and some major errors persist. The prototype implements code with some functionality in at least two different languages but the code lacks efficiency and some major errors persist. The prototype implements mostly efficient functional code in at least two different languages, but some minor errors still persist. The prototype implements consistently efficient functional code in at least two different languages. Uses some precise logic and programming structures which would result in some correct outcomes
Uses sufficient precise logic and programming structures which would result in adequate correct outcomes. Uses mostly precise logic and programming structures which would result in mostly correct outcomes. Uses precise logic and programming structures throughout which would result in consistently correct outcomes. 1-2 3-4 5-6 7-8 Code organisation (Q02.2)
Code is maintainable by a third party, but would present significant difficulties through the use of: • inconsistent naming conventions. • limited logical organisation • limited informative commenting. Code is maintainable by a third party, but would present some difficulties through the use of: • somewhat appropriate naming conventions. • Some logical organisation • some informative commenting. Code is maintainable by a third party, and would present only a few minor difficulties through the use of: • mostly appropriate naming conventions. • mostly logical organisation • mostly informative commenting. Code is easily maintainable by a third party through the use of consistently appropriate: • naming conventions. • logical organisation • informative commenting. 1-2 3-4 5-6 7-8 User experience (Q02.3)
Section 22
Basic user experience is provided through limited effective use of: • input handling • user guidance and error messages • outputs Adequate user experience is provided through somewhat effective use of: • input handling • user guidance and error messages • outputs Good user experience is provided through mostly effective use of: • input handling • user guidance and error messages • outputs Excellent user experience is provided through consistently effective use of: • input handling • user guidance and error messages • outputs
Section 23
The solution is adequately robust and effectively handles sufficient common and unexpected errors
The solution is largely robust and effectively handles most common and unexpected errors
The solution is fully robust and effectively handles common and unexpected errors T Level Technical Qualification in Digital: Digital Production, Design and Development
Section 24
Some effective application of standards and guidelines in relation to: ● accessibility ● compatibility ● legal and ethical considerations Mostly effective application of standards and guidelines in relation to: ● accessibility ● compatibility ● legal and ethical considerations Consistent and effective application of standards and guidelines in relation to: ● accessibility ● compatibility ● legal and ethical considerations Some effective application of procedures and security controls to ensure confidentiality, integrity and availability. A mostly effective application of procedures and security controls to ensure confidentiality, integrity and availability. Thoroughly effective application of procedures and security controls to ensure confidentiality, integrity and availability. T Level Technical Qualification in Digital: Digital Production, Design and Development
Section 25
Test data ● Suitable test data should be demonstrated (as appropriate to the student’s solution) which may include: o test-specific data: influence the system behaviour and reveal the case specifics under the test o test-reference data: have little influence on the test performance o application reference data: irrelevant to the behaviour under test, and are needed to start the application o valid test data does the system functions are in compliance with the requirements, does the system processes and stores the data as intended o invalid test data: check to see if the software correctly processes invalid values, shows the relevant messages, and notifies the user that the data are improper o boundary test data: help to reveal the defects connected with processing boundary values o wrong data: entering the data of inappropriate format, whether it shows the correct error messages thus showing the use of validation if appropriate o absent data: should check that the solution handles entering a blank field Use of testing to inform the iterative development process ● Learners should demonstrate how testing was used throughout the development to test and refine the solution. This may include reference to: o Runtime errors that occurred when implementing code o Fixing of syntax errors o How logical errors were detected through the use of appropriate test data o Descriptions of how issues were fixed o Refinements made in the code to mitigate issues o Details of regression testing o Comparison of manual calculations against program calculations to ensure logic and outputs are correct o Testing around boundaries to ensure logic of validation is correct
T Level Technical Qualification in Digital: Digital Production, Design and Development Task 2 -
Section 26
Assessment focus Band 0 Band 1 Band 2 Band 3 0 1-2 3-4 5-6 Suitability of test data. (Q02.5)
No rewardable material Tests selected show a basic understanding of how to effectively test inputs, calculations, validation and processes using test data which makes limited use of: • normal data • erroneous data • extreme data Tests selected show a good understanding of how to effectively test inputs, calculations, validation and processes using test data which includes: • normal data • erroneous data • extreme data Tests selected show a thorough and detailed understanding of how to effectively test inputs, calculations, validation and processes using test data which includes: • normal data • erroneous data • extreme data 1-2 3-4 5-6 Use of testing to inform the iterative development process (Q02.6)
Comments show a basic understanding of how errors/problems were identified and how they were rectified (as appropriate) for: ● inputs ● calculations ● validation and processes Comments show a good understanding of how errors/problems were identified and how they were rectified (as appropriate) for: ● inputs ● calculations ● validation and processes Comments show a comprehensive understanding of how errors/problems were identified and how they were rectified (as appropriate) for: ● inputs ● calculations ● validation and processes
Section 27
● The Student should provide information regarding the development process they followed it may include: o a commentary on the changes they have made and features included in the solution o a change log detailing significant changes at each stage of development o information relating to how testing outcomes impacted on changes made ● The student commentary should provide justification as to why changes where made which may refence: o Outcomes of testing in relation to the needs of o More efficient solutions that came out a result of development and/or further research o Order in which requirements were dealt with e.g. why V1 focused on a specific functional requirement and other requirements were implemented later, or not implement at all. ● The student demonstrates appropriate use of versioning such as: o Sensible and clear naming convention for each version o Suitable folder structures that make each version easy to find o Each version shows a notable change in the product e.g. additional functionality, error correction etc.
Section 28
● Limited and/or superficial records of changes made throughout the development stage ● A superficial or vague rationale for changes made. ● Some effective use of versioning An adequate iterative development process is demonstrated, including:
● Adequate recording of notable changes made throughout the development stage ● a supported rationale for some notable changes made ● mostly effective use of versioning An effective iterative development process is demonstrated, including: ● Thorough and detailed recording of notable changes made throughout the development stage ● Convincing and perceptive rationales for notable changes made ● fully effective use of versioning3 T Level Technical Qualification in Digital: Digital Production, Design and Development
Section 29
Indicative content and marker guidance Effectiveness of materials to support the feedback process The Student should provide evidence of having produced materials that would allow gathering of effective feedback. This may include (but not limited to): • screencasts : o demonstrate the prototype to both technical and non-technical audiences/users – may use two different screens (technical/non-technical) or may be in sections. o could be used alongside some method of collecting feedback from the user e.g. questionnaire, interview notes to be completed during/after watching. • questionnaires: o use of open and closed questions to ensure a range of quantitative and qualitative feedback o different sections or different questionnaires for different audiences o relevant questions that consider different aspects of the solution (appropriate for the targeted tester/user) • records of observation of users: o observation of people using the product o identification of ‘pain points’ o Types of observation may include – structured, unstructured, participant observation. • paired coding review records. o Technical review of code from an experienced coder o Identify issues that may not show up in testing e.g. efficiency, quality of commenting, code structures, alternative solutions
Section 30
The Student should provide evidence of the feedback they have gathered using their materials/methods. The evidence should show quality materials that would result in good feedback such as: • Meaningful e.g. graphs and quantitative data • Measurable: o Specific metrics that can be ‘re-tested’ to measure improvement – e.g. a rating out of 10 o Clear and specific improvements e.g. ‘Add a dark mode’ as opposed to ‘interface could be better’ • Completeness: o Focuses on specific aspects of the solution as required o Covers all relevant aspects of the solution o Systematically works through aspects of the solution to ensure coverage • Consistency: o Consistent approach to collecting data e.g. guidance/form so observations are all comparable o Use of follow up questions/interviews to ensure validity of responses to remove misinterpretation
Additional guidance – judgments should be made based on the quality of the materials and not just the quality of the feedback e.g. is the feedback good because the materials ensured it would be of high quality and not because the test user knew how to give good feedback.
T Level Technical Qualification in Digital: Digital Production, Design and Development Different audiences and users. The student should gather feedback form a range of appropriate users and/or testers for the services which may include: •range of ages and abilities •programming professionals •potential users
Section 31
Assessment focus Band 0 Band 1 Band 2 Band 3 Band 4 0 1-3 4-6 7-8 9-12 Effectiveness of materials to support the feedback process No rewardable material The materials would allow for the gathering of limited quality feedback for different aspects of the developed prototype The materials would allow for the gathering of adequate quality feedback for different aspects of the developed prototype The materials would allow for the gathering of good-quality feedback for different aspects of the developed prototype The materials would allow for the gathering of high-quality feedback for different aspects of the developed prototype. 0 1-2 3-4 5-6 Use of appropriate feedback tools to support the gathering of effective feedback
No rewardable materi10l The use of the tools has resulted in feedback that provides some opportunity for evidence- informed further iteration The use of the tools has resulted in feedback that mostly provides the opportunity for evidence-informed further iteration. The use of the tools has resulted in feedback that consistently provides the opportunity for evidence-informed further iteration. 0 1-2 3-4 5-6
Effectiveness of communication No rewardable material Quality of communication is only sometimes effective for both technical and non-technical audiences as a result of limited use of appropriate techniques, methods and formats
Section 32
Limited use of technical language that is appropriate for the intended audience The quality of communication is mostly effective for both technical and non- technical audiences as a result of the use of mostly appropriate techniques, methods and format
The use of technical language that is mostly appropriate for the intended audience The quality of communication is effective for both technical and non- technical audiences as a result of the consistent use of appropriate techniques, methods and formats
The use of technical language that is consistently appropriate for the intended audience
Section 33
3
Section 34
Effectiveness of assets and content The student should provide an evaluation of the assets and content within their prototype. • appropriateness of the assets selected which may include: o 3rd party data (e.g. to simulate user data, ticket prices, hotel bookings) o Multimedia content (e.g. zoo information, educational materials) o Snippets of pre-written code o Any other appropriate information (e.g. reward systems). • validity and reliability of the sources used which may consider: o primary and secondary information and data o websites used o information that is realistic/suitable for the scenario • legal and ethical implications of using the identified assets, which may consider: o copyright of content and IP o security and privacy of data and information e.g. GDPR, encryption, Privacy and data policy/informing the user o representation – e.g. range of gender, ethnicity, not conforming to/reinforcing stereotypes o Accessibility o Cookie consent notice o Terms and conditions
Evaluation of project outcomes The Student should provide an evaluation of the final product against measurable criteria defined in the proposal generated in Task 1. The evaluation should include: • Review of o the extent to which functional and non-functional requirements have been met o data to compare outcomes to key performance indicators (as appropriate) o the extent to which user acceptance criteria have been met
• Consideration of potential developments/improvements supported by: o Identification of how far requirements have been met o Feedback form test users o Clear explanation of why an improvement should be made (with reference to feedback and the needs of Riget Zoo Adventures and its stakeholders).
Section 35
• examples taken form their prototype and specific feedback extracts from feedback provided by test users.
Assessment Focus Band 0 Band 1 Band 2 Band 3 0 1-2 3-4 5-6 Effectiveness of assets and content No rewardable material A limited review of the content selected, including superficial consideration of the: ● appropriateness of the assets selected ● validity and reliability of the sources used ● legal and ethical implications of using the identified assets. A good review of the effectiveness of the content selected, including good consideration of the: ● appropriateness of the assets selected ● validity and reliability of the sources used ● legal and ethical implications of using the identified assets. A comprehensive review of the effectiveness of the content selected, including thorough consideration of the: ● appropriateness of the assets selected ● validity and reliability of the sources used ● legal and ethical implications of using the identified assets. The review is only sometimes supported by superficial consideration, comparison and corroboration across multiple sources. The review is mostly supported by good consideration, comparison and corroboration across multiple sources. The review is well supported by effective consideration, comparison and corroboration across multiple sources.
Section 36
Evaluation of project outcomes No rewardable material A basic or superficial evaluation of how well the prototype meets: ● functional and non-functional requirements of the system. ● key performance indicators (KPIs) ● user acceptance criteria for the proposed system. A good evaluation of how well the prototype meets: ● functional and non-functional requirements of the system. ● key performance indicators (KPIs) ● user acceptance criteria for the proposed system. A thorough and detailed evaluation of how well the prototype meets: ● functional and non-functional requirements of the system. ● key performance indicators (KPIs) ● user acceptance criteria for the proposed system.
Basic and/or simplistic rationale for future iteration is provided.
Good rationale for future iteration is provided.
Section 37
Convincing and perceptive rationale for future iteration is provided. Points made are supported by limited relevant: • selection of examples • consideration of feedback. Points made are supported by mostly relevant: • selection of examples • consideration of feedback. Points made are supported by an entirely relevant and perceptive: • selection of examples • consideration of feedback.
‘T-LEVELS’ is a registered trade mark of the Department f or Education. ‘T Level’ is a registered trade mark of the Institute f or Apprenticeships and Technical Education. The T Level Technical Qualif ication is a qualif ication approved and managed by the Institute f or Apprenticeships and Technical Education. ‘Institute f or Apprenticeships & Technical Education’ and logo are registered trade marks of the Institute f or Apprenticeships and Technical Education. Pearson Education Limited is authorised by the Institute f or Apprenticeships and Technical Education to develop and deliver this Technical Qualif ication. All the material in this publication is copyright © Pearson Education Limited 2024 T Level Technical Qualification in Digital: Digital Production, Design and Development