Developing software to support the aerospace industry.
This occupation is predominately found in the aerospace sector but may also be used more widely. The occupation can be found in large, medium and small employers across the world. Aerospace software engineers may work on specific aerospace products. They may also work on bespoke tooling and associated integrated aerospace environments and infrastructure. Employment examples include:
The broad purpose of the occupation is to design, develop and test, real-time safety-critical software. They develop embedded aircraft software and stand-alone applications used in aircraft support. They develop and test tools that support the creation of aerospace related software. They support customers and suppliers by maintaining and improving software utilities and tools. They develop processes for the development and test of products. They review performance, design, test and use project management and continuous improvement techniques. They proactively find solutions to problems and identify areas for business improvement.
Aerospace software engineers are typically office-based. They may be required to work in simulation rig testing facilities, or in operational environments.
In their daily work, an employee in this occupation may interact with customers. They may also interact with system operators, other specialist engineers, technicians, partners and suppliers. They also interact with colleagues across other areas in their organisation. For example, manufacturing, project management, quality assurance, finance, human resources and procurement.
They typically report to Senior Engineers, Senior Specialists or Chief Engineers depending on the organisation.
An employee in this occupation is responsible for working ethically and professionally. They work to Civil and Military Aviation regulatory requirements. They must meet statutory and company regulations. For example, health and safety, environment and sustainability, cost, quality, accuracy and efficiency. Aerospace Software Engineers work individually and as part of a team. They are responsible for the safety and security of the product they create. Depending on the size and structure of the organisation they may manage software technicians or teams of engineers.
This is a summary of the key things that you – the apprentice and your employer need to know about your end-point assessment (EPA). You and your employer should read the EPA plan for the full details. It has information on assessment method requirements, roles and responsibilities, and re-sits and re-takes.
An EPA is an assessment at the end of your apprenticeship. It will assess you against the knowledge, skills, and behaviours (KSBs) in the occupational standard. Your training will cover the KSBs. The EPA is your opportunity to show an independent assessor how well you can carry out the occupation you have been trained for.
Your employer will choose an end-point assessment organisation (EPAO) to deliver the EPA. Your employer and training provider should tell you what to expect and how to prepare for your EPA.
The length of the training for this apprenticeship is typically 48 months. The EPA period is typically 9 months.
The overall grades available for this apprenticeship are:
When you pass the EPA, you will be awarded your apprenticeship certificate.
The EPA gateway is when the EPAO checks and confirms that you have met any requirements required before you start the EPA. You will only enter the gateway when your employer says you are ready.
The gateway requirements for your EPA are:
For the aerospace software engineer, the qualification required is:
bachelor honours degree in software engineering (BEng), computer science (BSc), or other degree that directly aligns to the KSBs in the degree-apprenticeship
Project with report
You will complete a project and write a report. You will be asked to complete a project. The title and scope must be agreed with the EPAO at the gateway. The report should be a maximum of 6000 words (with a 10% tolerance).
You will have 32 weeks to complete the project and submit the report to the EPAO.
You need to prepare and give a presentation to an independent assessor. Your presentation slides and any supporting materials should be submitted at the same time as the project output. The presentation with questions will last at least 60 minutes. The independent assessor will ask at least 6 questions about the project and presentation.
Professional discussion underpinned by a portfolio of evidence
You will have a professional professional discussion with an independent assessor. It will last 60 minutes. They will ask you at least 8 questions. The questions will be about certain aspects of your occupation. You need to compile a portfolio of evidence before the EPA gateway. You can use it to help answer the questions.
The EPAO will confirm where and when each assessment method will take place.
You should speak to your employer if you have a query that relates to your job.
You should speak to your training provider if you have any questions about your training or EPA before it starts.
You should receive detailed information and support from the EPAO before the EPA starts. You should speak to them if you have any questions about your EPA once it has started.
If you have a disability, a physical or mental health condition or other special considerations, you may be able to have a reasonable adjustment that takes this into account. You should speak to your employer, training provider and EPAO and ask them what support you can get. The EPAO will decide if an adjustment is appropriate.
This apprenticeship aligns with The Royal Aeronautical Society for Incorporated Engineer (IEng). This degree-apprenticeship standard aligns with the Engineering Council’s learning outcomes, indicated in ‘Accreditation of Higher Education Programmes’ (AHEP) and the competence framework detailed in UK-SPEC for Incorporated Engineer (IEng). The experience gained and responsibility held by the apprentice on completion of the degree-apprenticeship will either wholly or partially satisfy the requirements for registration at this level.
Please contact the professional body for more details.
This apprenticeship aligns with The Chartered Institute for IT (BCS) for Registration for IT Technicians (RITTech). The experience gained and responsibility held by the apprentice on completion of the degree-apprenticeship will either wholly or partially satisfy the requirements for registration at this level.
Please contact the professional body for more details.
This occupation is predominately found in the aerospace sector but may also be used more widely. The occupation can be found in large, medium and small employers across the world. Aerospace software engineers may work on specific aerospace products. They may also work on bespoke tooling and associated integrated aerospace environments and infrastructure. Employment examples include:
The broad purpose of the occupation is to design, develop and test, real-time safety-critical software. They develop embedded aircraft software and stand-alone applications used in aircraft support. They develop and test tools that support the creation of aerospace related software. They support customers and suppliers by maintaining and improving software utilities and tools. They develop processes for the development and test of products. They review performance, design, test and use project management and continuous improvement techniques. They proactively find solutions to problems and identify areas for business improvement.
Aerospace software engineers are typically office-based. They may be required to work in simulation rig testing facilities, or in operational environments.
In their daily work, an employee in this occupation may interact with customers. They may also interact with system operators, other specialist engineers, technicians, partners and suppliers. They also interact with colleagues across other areas in their organisation. For example, manufacturing, project management, quality assurance, finance, human resources and procurement.
They typically report to Senior Engineers, Senior Specialists or Chief Engineers depending on the organisation.
An employee in this occupation is responsible for working ethically and professionally. They work to Civil and Military Aviation regulatory requirements. They must meet statutory and company regulations. For example, health and safety, environment and sustainability, cost, quality, accuracy and efficiency. Aerospace Software Engineers work individually and as part of a team. They are responsible for the safety and security of the product they create. Depending on the size and structure of the organisation they may manage software technicians or teams of engineers.
Whilst any entry requirements will be a matter for individual employers, typically an apprentice might be expected to have already achieved academic qualifications of 96* UCAS points or above at A-Level standard or equivalent, to include two STEM-based subjects such as Maths, Physics, ICT, Computing or Electronics, plus five GCSEs at Grade 4 and above** including Mathematics, English and Double Science or equivalent qualification. (*Equal to 240 UCAS points prior to 2017, **Equal to Grades C and above).
| Duty | KSBs |
|---|---|
|
Duty 1 Define and maintain the engineering plan detailing the implementation of Aerospace software engineering solutions. In collaboration with multidisciplinary teams and organisational stakeholders. |
K1 K2 K3 K4 K5 K6 K7 K8 K9 K10 K11 K12 K13 K14 K15 K16 K17 K18 K19 K20 K21 K22 K23 K24 |
|
Duty 2 Identify, evaluate, derive, analyse and maintain software requirements for customer and projects. |
K1 K2 K3 K7 K10 K12 K14 K17 K18 K20 K21 K22 K24 K26 |
|
Duty 3 Define and maintain the architecture and design of software products, tools, utilities and applications to meet project requirements. |
K1 K4 K5 K6 K7 K10 K12 K13 K14 K15 K17 K18 K19 K20 K21 K22 K23 K26 S1 S2 S3 S4 S5 S6 S7 S11 S12 S13 S14 S15 S17 S19 S20 S21 S22 |
|
Duty 4 Implement Aerospace software design from combinations of new, modified and existing components to meet project requirements. |
K1 K7 K8 K9 K10 K11 K12 K13 K14 K15 K17 K23 K25 K26 K27 S1 S2 S3 S4 S5 S6 S7 S8 S11 S13 S14 S15 S16 S17 S18 S19 S20 S22 S23 S24 |
|
Duty 5 Develop, define and execute testing of Aerospace software products to verify functionality and performance. |
K1 K2 K3 K4 K5 K6 K10 K11 K12 K13 K14 K16 K17 K18 K20 K21 K25 K26 K27 |
|
Duty 6 Analyse and review the Aerospace software outputs. |
K1 K2 K4 K5 K7 K8 K11 K12 K14 K15 K16 K17 K18 K20 K21 K25 K26 |
|
Duty 7 Undertake and complete build, configure and release of the Aerospace software product. |
K12 K13 K15 K16 K18 K19 K20 K23 K24 K25 K26 K27 |
|
Duty 8 Verify that software processes and procedures comply with standards throughout the life cycle. These include local, national and international regulatory, legislative, customer and company standards. For example, cyber security, development, environmental, anti-bribery and corruption. Official Secrets Act, export control, safety standards. |
K1 K2 K4 K6 K7 K8 K10 K12 K13 K14 K15 K16 K17 K19 K20 K21 K22 K23 K25 K26 |
|
Duty 9 Review the in-service performance of software products, processes and systems. Assess the cause of any faults or problems and propose solutions. |
K7 K12 K13 K14 K16 K18 K25 K26 |
|
Duty 10 Manage stakeholders by communicating project status, technical and commercial information. For example, communicate success, risks and issues to all levels of the business. |
K12 K15 K16 K17 K18 K19 K20 K21 K22 K23 K24 |
|
Duty 11 Define, monitor and co-ordinate the continuous improvement of software processes and methods. |
K1: Mathematics: the mathematical techniques and analytical methods required to model software and hardware systems: algebra, calculus, geometry, Boolean Logic, trigonometry and statistics.
Back to Duty
K2: Software requirements development: the requirement lifecycle from concept to release; gathering, specifications, validation.
Back to Duty
K3: Software requirements engineering: maintenance, operating environment, identification of software security, modelling, human computer interaction, and identification of system safety.
Back to Duty
K4: Software architecture: operating system concepts and architectural considerations.
Back to Duty
K5: Software design development: structures, methodologies, techniques and validation.
Back to Duty
K6: Software design engineering: software functions and interconnection, flexibility, coupling and cohesion, readability, maintainability, testability, safety, security and design verification.
Back to Duty
K7: Modelling and simulation: creation and simulation of design models.
Back to Duty
K8: Software implementation development: creation of executable code.
Back to Duty
K9: Software implementation engineering: underlying concepts of computational thinking, abstraction, representation and modelling, language specifications including assembler, analysis, and inspection methodologies.
Back to Duty
K10: Testing the software solution: test environments; debugging and profiling facilities.
Back to Duty
K11: Test methodologies: methods used to test software; criticality.
Back to Duty
K12: Configuration control: configuration management methods, software build processes, tools and change control.
Back to Duty
K13: Software development environment: tool configurations, library functions, operating environment, compiler process and options, scripting and hardware or software integration.
Back to Duty
K14: System security: statutory, regulatory, organisational and certification principles in a software product.
Back to Duty
K15: Principles of quality: process conformations and assurance in an aerospace software engineering environment.
Back to Duty
K16: Continuous improvement principles and techniques: Plan-do-check-act (PDCA), Lean, 6 Sigma, and Statistical Process Control (SPC). Lean manufacturing tools. Process mapping.
Back to Duty
K17: Safety requirements: statutory, regulatory, organisational and certification principles (software safety integrity levels) in an aerospace software environment.
Back to Duty
K18: Teamwork: conflict management, people development techniques, performance management, diversity and inclusivity.
Back to Duty
K19: Information technology: general data protection regulation (GDPR), digital tools for presentation of data, digital communication and collaboration packages.
Back to Duty
K20: Communication techniques: verbal, written and presentations.
Back to Duty
K21: Time management techniques.
Back to Duty
K22: Environment and sustainability: role of software design and implementation in the end-to-end value chain for sustainable products; optimising energy and resource consumption; relationship between obsolescence and sustainability.
Back to Duty
K23: Project management: project planning, management of risks, commercial awareness, financial management and resourcing.
Back to Duty
K24: Report writing techniques and methods. IT applications for technical reporting.
Back to Duty
K25: Problem solving tools and techniques: lateral thinking, root cause analysis (RCA).
Back to Duty
K26: Software development techniques: Waterfall, Agile, and Hybrid.
Back to Duty
K27: Software integration techniques.
Back to Duty
S1: Apply analytical methods; use mathematics and associated toolsets to characterise properties and behaviour of software.
Back to Duty
S2: Read, interpret and use Software Engineering data. For example, requirements, design, code, test and release documentation.
Back to Duty
S3: Develop and apply Algorithms. For example, produce specification, design and implementation for algorithms.
Back to Duty
S4: Select the design approach and tools for a given software engineering application and environment.
Back to Duty
S5: Apply model-based techniques. For example, using simulations to verify the compliance to the parent requirements.
Back to Duty
S6: Produce system and software designs. For example, produce state machine diagrams.
Back to Duty
S7: Setup and configure tools and the environment. For example, verification tool to target hardware requirements, management tool to design tool, and configuration tool to development tools.
Back to Duty
S8: Implement functional software solutions. For example, developing software solutions that incorporate new, legacy or commercial components.
Back to Duty
S9: Develop and execute Aerospace software test plans.
Back to Duty
S10: Analyse and review Aerospace software outputs. For Example, design reviews, code walkthroughs, test script reviews.
Back to Duty
S11: Use problem solving tools and techniques. For example: lateral thinking, root cause analysis (RCA), Kaizen, Lean manufacturing and Kanban.
Back to Duty
S12: Apply configuration management and software build processes.
Back to Duty
S13: Communicate with internal and external stakeholders; verbal and written.
Back to Duty
S14: Write reports. For example, data, technical information, drawings, outcomes and recommendations.
Back to Duty
S15: Present information. For example, presenting project progress and key performance indicators (KPI's) such as cost, quality, time, risk and opportunities. Presenting technical results into design reviews.
Back to Duty
S16: Use information technology: digital tools for presentation of data, digital communication and collaboration packages.
Back to Duty
S17: Use continuous improvement techniques and make recommendations. For example, Kaizen, Lean manufacturing and Kanban.
Back to Duty
S18: Use project management techniques. For example, in estimating, risk, cost and budget control, time management and resource management.
Back to Duty
S19: Identify and comply with legal and statutory requirements. For example: cyber security, software certification requirements, data protection, Aerospace software safety, environmental protection and sustainability.
Back to Duty
S20: Plan and manage own time.
Back to Duty
S21: Apply and uphold ethical principles.
Back to Duty
S22: Apply team working principles.
Back to Duty
S23: Apply software development techniques. For example, Waterfall, Agile, or Hybrid.
Back to Duty
S24: Apply software integration techniques. For example, networks, hardware or system integration.
Back to Duty
B1: Lead by example and promote health and safety.
Back to Duty
B2: Lead by example and promote environment, ethical and sustainable practices.
Back to Duty
B3: Adapt to challenging or changing situations and be resilient to the effects.
Back to Duty
B4: Collaborate and promote teamwork across disciplines.
Back to Duty
B5: Lead by example to promote accessibility, diversity and inclusion.
Back to Duty
B6: Commits to their own and others' professional development.
Back to Duty
Apprentices without level 2 English and maths will need to achieve this level prior to taking the End-Point Assessment. For those with an education, health and care plan or a legacy statement, the apprenticeship’s English and maths minimum requirement is Entry Level 3. A British Sign Language (BSL) qualification is an alternative to the English qualification for those whose primary language is BSL.
Level: 6 (integrated degree)
None
This standard aligns with the following professional recognition:
This is a regulated occupation.
Civil Aviation Authority
Training Provider does not require approval by regulator body
EPAO does not require approval by regulator body
V1.1
This document explains the requirements for end-point assessment (EPA) for the aerospace software engineer degree-apprenticeship. End-point assessment organisations (EPAOs) must follow this when designing and delivering the EPA.
Aerospace software engineer apprentices, their employers and training providers should read this document.
A degree-apprenticeship enables the awarding of a degree within the achievement of an apprenticeship. This means the degree learning outcomes must be aligned with the knowledge, skills and behaviours (KSBs) in the apprenticeship. Therefore, the apprenticeship and the degree must be completed, passed and awarded together to achieve the aerospace software engineer degree-apprenticeship.
Apprentices must complete and pass all on and off-the-job training before completing an EPA to determine occupational competence.
A degree-apprenticeship must be delivered by a Higher Education Provider (HEP) that is on both the register of apprenticeship training providers (RoATP) and the register of end-point assessment organisations (RoEPAO). The apprentice's employer must select an HEP who is on both registers.
If the HEP is using a credit framework, the EPA must contribute to the total credit value, and must be delivered in accordance with this assessment plan. However, the number of credits devoted to EPA may vary across HEPs. The recommended EPA contribution is a 12th of the total credit value.
A full-time apprentice typically spends 48 months on-programme (this means in training before the gateway) working towards occupational competence as an aerospace software engineer. All apprentices must spend at least 12 months on-programme. All apprentices must complete the required amount of off-the-job training specified by the apprenticeship funding rules.
This EPA should then be completed within an EPA period lasting typically 9 months.
Occupational competence is outlined by the EPA grade descriptors and determined, when assessed in accordance with this EPA plan, by an independent assessor who is an occupational expert and confirms the overall EPA grade.
This EPA has 2 assessment methods.
The grades available for each assessment method are:
Assessment method 1 - project report and presentation with questions:
Assessment method 2 - professional discussion underpinned by a portfolio of evidence:
The result from each assessment method is combined to decide the overall apprenticeship grade. The following grades are available for the apprenticeship:
|
On-programme - typically 48 months
|
The apprentice must:
|
|---|---|
|
End-point assessment gateway
|
For the apprentice to pass gateway, the employer must confirm that the apprentice is working at or above the level of occupational competence. The apprentice must:
Apprentices must submit all gateway evidence to the EPAO as required, including any relevant organisation specific policies and procedures as requested by the EPAO.
|
|
End-point assessment - typically 9 months
|
Grades available for each assessment method: Project report and presentation with questions
Professional discussion underpinned by a portfolio of evidence
Overall EPA and apprenticeship can be graded:
|
|
Professional recognition
|
This degree-apprenticeship aligns with The Royal Aeronautical Society for Incorporated Engineer (IEng). This degree-apprenticeship standard aligns with the Engineering Council’s learning outcomes, indicated in ‘Accreditation of Higher Education Programmes’ (AHEP) and the competence framework detailed in UK-SPEC for Incorporated Engineer (IEng). The experience gained and responsibility held by the apprentice on completion of the degree-apprenticeship will either wholly or partially satisfy the requirements for registration at this level. This degree-apprenticeship aligns with The Chartered Institute for IT (BCS) for Registration for IT Technicians (RITTech). The experience gained and responsibility held by the apprentice on completion of the degree-apprenticeship will either wholly or partially satisfy the requirements for registration at this level. |
The EPA is taken in the EPA period. The EPA period starts when the EPAO confirms the gateway requirements have been met and is typically 9 months.
The EPAO should confirm the gateway requirements have been met and the EPA should start as quickly as possible.
The apprentice’s employer must confirm that they think their apprentice is working at or above the occupational standard as an aerospace software engineer (degree). The apprentice will then enter the gateway. The employer may take advice from the apprentice's training provider(s), but the employer must make the decision.
The apprentice must meet the following gateway requirements before starting their EPA.
These are:
Portfolio of evidence requirements:
The apprentice must compile a portfolio of evidence during the on-programme period of the apprenticeship. It should only contain evidence related to the KSBs that will be assessed by this assessment method. It will typically contain 8 discrete pieces of evidence. Evidence must be mapped against the KSBs. Evidence may be used to demonstrate more than one KSB; a qualitative as opposed to quantitative approach is suggested.
Evidence sources may include:
This is not a definitive list; other evidence sources can be included.
The portfolio of evidence should not include reflective accounts or any methods of self-assessment. Any employer contributions should focus on direct observation of performance (for example, witness statements) rather than opinions. The evidence provided should be valid and attributable to the apprentice; the portfolio of evidence should contain a statement from the employer and apprentice confirming this.
The EPAO should not assess the portfolio of evidence directly as it underpins the professional discussion. The independent assessors should review the portfolio of evidence to prepare questions for the professional discussion. They are not required to provide feedback after this review.
Apprentices must submit all gateway evidence to their EPAO as required, including any relevant organisation specific policies and procedures as requested by the EPAO.
The assessment methods can be delivered in any order.
The result of one assessment method does not need to be known before starting the next.
A project involves the apprentice completing a significant and defined piece of work that has a real business application and benefit. The project must start after the apprentice has gone through gateway.
The project: report and presentation with questions must be structured to give the apprentice the opportunity to demonstrate the KSBs mapped to this assessment to the highest available grade.
The project must meet the needs of the employer’s business and be relevant to the apprentice’s occupation and apprenticeship. The EPAO must refer to the grading descriptors to ensure that projects are pitched appropriately.
This assessment method has 2 components:
Together, they give the apprentice the opportunity to demonstrate the KSBs mapped to this assessment method.
This assessment method is being used because:
The project report and presentation with questions must be structured to give the apprentice the opportunity to demonstrate the KSBs mapped to this assessment method to the highest available grade.
The apprentice must start the project after the EPA gateway. The employer should ensure the apprentice has the time and resources, within this period, to plan and complete their project.
The apprentice may work as part of a team to complete the project, which could include internal technical experts or external support. The apprentice must however, complete their project report and presentation unaided and they must be reflective of their own role and contribution. The apprentice and their employer must confirm this when the report, presentation slides and any supporting materials are submitted.
The apprentice’s project can be based on any of the following:
The project must cover the following themes:
To ensure the project allows the apprentice to meet the KSBs mapped to this assessment method to the highest available grade, the EPAO must confirm the project’s subject, title and scope are suitable at the gateway.
Assessment and grading decisions
The project report and presentation with questions must be assessed by two assessors - an independent academic assessor and an independent occupational assessor.
The project report and presentation with questions must be assessed holistically to decide the grade for this assessment method.
The independent academic assessor must assess the project report and presentation with questions against the EPA grading descriptors. The independent occupational assessor must review the EPA grading decisions. In the case of differing EPA grading decisions between the two assessors, the independent occupational assessor’s decision is final.
The independent assessors must keep accurate records of the assessment. They must record:
The apprentice must produce a report.
They must submit the project report to the EPAO by the end of week 26 of the EPA period.
The report must include at least:
The project report has a word count of 6000 words. A tolerance of 10% above or below the word count is allowed at the apprentice’s discretion. Appendices, references and diagrams are not included in this total. The project report must map, in an appendix, how it evidences the KSBs mapped to this assessment method.
In the presentation with questions, the apprentice must deliver a presentation to both independent assessors on their project at the same time. The independent assessors must ask questions following the presentation.
The presentation should cover:
The apprentice must prepare and submit their presentation slides and any supporting materials to the EPAO at the same time as the report - by the end of week 26 of the EPA period.
The apprentice must notify the EPAO, at that point, of any technical requirements for the presentation. During the presentation, the apprentice must have access to:
The independent assessors must have at least 2 weeks to review the project report and presentation speaker notes and supporting materials, to allow them to prepare questions.
The EPAO must give the apprentices at least 2 weeks notice of the date and time of the presentation with questions.
The purpose of the independent assessors' questions will be to assess the following themes:
The purpose of the independent assessors' questions will also be to:
The presentation and questions must last 60 minutes. This will typically include a presentation of 25 minutes and questioning lasting 35 minutes. The independent assessors can increase the total time of the presentation and questions by up to 10%. This time is to allow the apprentice to complete their last point or respond to a question if necessary.
The independent assessors must ask at least 6 questions. They must use the questions from the EPAO’s question bank or create their own questions in-line with the EPAO’s training. Follow up questions are allowed where clarification is required.
The independent assessors must use the full time available for questioning.
The presentation with questions must take place in a suitable venue selected by the EPAO (for example the EPAO’s or employer’s premises).
The presentation with questions should take place in a quiet room, free from distractions and influence.
The presentation with questions can be conducted by video conferencing. The EPAO must have processes in place to verify the identity of the apprentice and ensure the apprentice is not being aided.
The EPAO must develop a purpose-built assessment specification and question bank. It is recommended this is done in consultation with employers and professional engineering institutions (PEI) of this occupation. The EPAO should maintain the security and confidentiality of EPA materials when consulting employers. The assessment specification and question bank must be reviewed at least once a year to ensure they remain fit-for-purpose.
The assessment specification must be relevant to the occupation and demonstrate how to assess the KSBs mapped to this assessment method. The EPAO must ensure that questions are refined and developed to a high standard. The questions must be unpredictable. A question bank of sufficient size will support this.
The EPAO must ensure that the apprentice has a different set of questions in the case of re-sits or re-takes.
The EPAO must produce the following materials to support the project report and presentation with questions:
The EPAO must ensure that the EPA materials are subject to quality assurance procedures including standardisation, training, and moderation.
In the professional discussion, independent assessors and the apprentice have a formal conversation.
The apprentice can refer to and illustrate their answers with evidence from their portfolio of evidence. It gives the apprentice the opportunity to demonstrate the KSBs mapped to this assessment method.
This assessment method is being used because:
it allows for testing of responses where there are a range of potential answers
it is cost effective, as apart from a venue, it does not require additional resources
The professional discussion must be structured to give the apprentice the opportunity to demonstrate the KSBs mapped to this assessment method to the highest available grade.
An independent academic assessor and an independent occupational assessor must conduct the professional discussion.
The purpose of the independent assessors' questions will be to assess the following themes:
The EPAO must give an apprentice 2 weeks notice of the professional discussion.
The independent assessors must have at least 2 weeks to review the supporting documentation.
The apprentice must have access to their portfolio of evidence during the professional discussion.
The apprentice can refer to and illustrate their answers with evidence from their portfolio of evidence however, it is not directly assessed.
The professional discussion must last for 60 minutes. The independent assessors can increase the time of the professional discussion by up to 10%. This time is to allow the apprentice to respond to a question if necessary.
The independent assessors must ask at least 8 questions. Follow-up questions are allowed where clarification is required. The independent assessors must use the questions from their EPAO’s question bank or create their own questions in-line with the EPAO’s training.
Assessment and grading decisions
The professional discussion underpinned by a portfolio of evidence must be assessed by an independent occupational assessor and an independent academic assessor.
The independent occupational assessor assesses the professional discussion underpinned by a portfolio of evidence against the EPA grading descriptors. The independent academic assessor must review the EPA grading decisions. In the case of differing EPA grading decisions between the two assessors, the independent occupational assessor’s decision is final.
The independent assessors must keep accurate records of the assessment. They must record:
The professional discussion must take place in a suitable venue selected by the EPAO (for example the EPAO’s or employer’s premises).
The professional discussion can be conducted by video conferencing. The EPAO must have processes in place to verify the identity of the apprentice and ensure the apprentice is not being aided.
The professional discussion should take place in a quiet room, free from distractions and influence.
The EPAO must develop a purpose-built assessment specification and question bank. It is recommended this is done in consultation with employers and professional engineering institutions (PEI) of this occupation. The EPAO should maintain the security and confidentiality of EPA materials when consulting employers. The assessment specification and question bank must be reviewed at least once a year to ensure they remain fit-for-purpose.
The assessment specification must be relevant to the occupation and demonstrate how to assess the KSBs mapped to this assessment method. The EPAO must ensure that questions are refined and developed to a high standard. The questions must be unpredictable. A question bank of sufficient size will support this.
The EPAO must ensure that the apprentice has a different set of questions in the case of re-sits or re-takes.
The EPAO must produce the following materials to support the professional discussion underpinned by a portfolio of evidence:
The EPAO must ensure that the EPA materials are subject to quality assurance procedures including standardisation, training, and moderation.
|
Theme
KSBs
|
Pass
Apprentices must demonstrate all the pass descriptors
|
Distinction
Apprentices must demonstrate all the pass descriptors and all of the distinction descriptors
|
|---|---|---|
|
Software design analysis
K2 S2 S4 |
Analyses and uses software engineering data to select the design approach and tools for a software engineering application and environment in line with the project requirements. (K2, S2, S4) |
Critically evaluates the selected design approach and tools for a software engineering application and environment in line with the project requirements. (K2, S2, S4) |
|
Software design development
K1 K5 K26 K27 S1 S3 S6 S23 S24 |
Applies analytical methods using mathematics and associated toolsets to characterise properties and behaviour of software when developing and applying algorithms in line with the requirements of the project. (K1, S1, S3) Produces system and software designs which include structures, methodologies, techniques and validation appropriate to the project requirements. (K5, S6) Applies software development techniques for example, Waterfall, Agile or Hybrid in line with the project requirements. (K26, S23) Applies software integration techniques, for example networks, hardware or system integration. (K27, S24) |
Critically evaluates the advantage to the business of using their chosen methods and algorithms within aerospace software engineering activities. (K1, S1, S3) |
|
Software development testing
K10 S9 S10 |
Develops and executes aerospace software test plans to test the software solution. Reviews and analyses the software outputs in line with the project requirements. (K10, S9, S10) |
None |
|
Implementation
K8 K12 K13 S7 S8 S12 |
Applies configuration management methods and software build processes to set up and configure tools and the software development environment which include tool configuration, library functions, operating environment, compiler process and options, scripting and hardware or software integration in line with the project requirements. (K12, K13, S7, S12) Implements functional software solutions, including executable code to meet the project requirements. (K8, S8) |
Critically evaluates how their choice of configuration management and software build processes benefitted the project outcomes. (K12, K13, S7, S12) Critically evaluates the extent to which the functional software solution satisfies the project requirements. (K8, S8)
|
|
Project management, continuous improvement, and communication
K16 K21 K23 K24 S14 S17 S18 S20 B3 |
Applies project management techniques which consider planning, risk, commercial awareness and resourcing in line with organisational policies and the brief. (K23, S18) Applies time management techniques to the project, adapting with resilience to challenging and changing situations in line with organisational values and project requirements. (K21, S20, B3) Evaluates the application of continuous improvement techniques such as Plan-do-check-act (PDCA), Lean, 6 Sigma, and Statistical Process Control (SPC) used to provide solutions to issues or processes in their own work. (K16, S17) Writes reports conveying technical information, such as data and drawings, with outcomes and recommendations that meet the project requirements. (K24, S14) |
Critically evaluates the impact of the project management techniques used in achieving project objectives. (K23, S18) |
|
Theme
KSBs
|
Pass
Apprentices must demonstrate all the pass descriptors
|
|---|---|
|
Software engineering requirements and architecture
K3 K4 |
Defines different methods suitable for the software engineering requirements including maintenance, operating environment, identification of software security, modelling, human computer interaction, and identification of system safety influence. (K3) Defines the operating system concepts and architectural considerations of software architecture. (K4)
|
|
Software design and test methodologies
K6 K11 |
Defines the software design engineering life cycle including software functions and interconnection, flexibility, Coupling and Cohesion, readability, maintainability and testability and design verification. (K6) Describes test methodologies and methods used to test software including criticality. (K11) |
|
Software implementation
K7 K9 S5 |
Articulates how underlying concepts of computational thinking, abstraction, representation, modelling and simulation, language specifications including assembler, analysis, and inspection methodologies are applied when using model-based techniques and design verification. (K7, K9, S5) |
|
Problem solving
K25 S11 |
Critically evaluates their application of lateral thinking and root cause analysis to diagnose and resolve software problems. ( |
|
Software certification and licencing
K14 K15 K17 S19 |
Evaluates how statutory, regulatory, organisational and certification principles for the safety and security of software products and systems are applied in the aerospace software environment. (K14, K17) Analyses how the principles of quality including process conformations and assurance are applied in an aerospace software engineering environment and how they identify and comply with legal and statutory requirements. (K15, S19) |
|
Data and information technology
K19 S15 S16 |
Evaluates the use of digital tools in collating and presenting data and how they are used to support digital communication and collaboration packages in line with GDPR regulations. (K19, S15, S16) |
|
Communication, teamwork, professional and leadership behaviours
K18 K20 K22 S13 S21 S22 B1 B2 B4 B5 |
Articulates how they collaborate, promote and apply team working principles such as conflict management, people development techniques and performance management within their own team in line with organisational policies. (K18, S22, B4) Articulates how they use written and verbal communication methods when communicating with internal and external stakeholders. (K20, S13) Evaluates their role in leading by example and promoting environmental, ethical and sustainability practices, including equality and diversity and health and safety in line with organisational guidelines. (K22, S21, B1, B2, B5) |
|
Continuous professional development
B6 |
Demonstrates evidence of a commitment to professional development and incorporates new ideas and methods into their work and interactions. (B6) |
Performance in the EPA determines the apprenticeship grade of:
The EPAO must combine the individual assessment method grades to determine the overall EPA grade.
If the apprentice fails one or more assessment methods, they will be awarded an overall fail.
To achieve an overall pass, the apprentice must achieve at least a pass in both assessment methods. To achieve an overall distinction, the apprentice must achieve a distinction in the project report and presentation with questions and a pass in the professional discussion underpinned by a portfolio of evidence.
Aggregation of the degree apprenticeship
The outcome of the EPA must be aggregated with the outcome of the on-programme degree modules to enable the degree apprenticeship to be awarded. Once the overall EPA grade has been determined, aggregation can be achieved in a variety of ways. This will be determined by the HEP during the creation of the degree apprenticeship. Examples include:
HEPs can explore other ways of aggregating the EPA with the degree outcomes in line with the latest IfATE degree apprenticeship policy.
Grades from individual assessment methods must be combined in the following way to determine the grade of the EPA overall.
| Project report and presentation with questions | Professional discussion underpinned by a portfolio of evidence | Overall Grading |
|---|---|---|
| Any grade | Fail | Fail |
| Fail | Any grade | Fail |
| Pass | Pass | Pass |
| Distinction | Pass | Distinction |
If the apprentice fails one or more assessment methods, they can take a re-sit or a re-take at their employer’s discretion. The apprentice’s employer needs to agree that a re-sit or re-take is appropriate. A re-sit does not need further learning, whereas a re-take does.
The apprentice should have a supportive action plan to prepare for a re-sit or a re-take.
The employer and EPAO agree the timescale for a re-sit or re-take. A re-sit is typically taken within 3 months of the EPA outcome notification. The timescale for a re-take is dependent on how much re-training is required and is typically taken within 6 months of the EPA outcome notification.
If the apprentice fails the project assessment method, they must amend the project output in line with the independent assessors' feedback. The apprentice will be given 4 weeks to rework and submit the amended report.
Failed assessment methods must be re-sat or re-taken within a 6-month period from the EPA outcome notification, otherwise the entire EPA will need to be re-sat or re-taken in full.
Re-sits and re-takes are not offered to an apprentice wishing to move from pass to a higher grade.
The apprentice will get a maximum EPA grade of pass for a re-sit or re-take, unless the EPAO determines there are exceptional circumstances.
| Roles | Responsibilities |
|---|---|
|
Apprentice |
As a minimum, the apprentice should:
|
|
Employer |
As a minimum, the apprentice's employer must:
|
|
EPAO (HEP) |
As a minimum, the EPAO (HEP) must:
|
|
Training provider (HEP) |
As a minimum, the training provider (HEP) must:
|
|
Independent academic assessor |
As a minimum, an independent academic assessor must:
|
|
Independent occupational assessor |
As a minimum, the independent occupational assessor must:
|
The EPAO must have reasonable adjustments arrangements for the EPA.
This should include:
Adjustments must maintain the validity, reliability and integrity of the EPA as outlined in this EPA plan.
Internal quality assurance refers to the strategies, policies and procedures that EPAOs must have in place to ensure valid, consistent and reliable end-point assessment decisions.
EPAOs for this EPA must adhere to the requirements within the roles and responsibilities table and:
Apprentices seeking to achieve IEng recognition, following completion of the EPA, must also be assessed by an occupational assessor who holds the relevant PEI qualification.
Affordability of the EPA will be aided by using at least some of the following:
This apprenticeship aligns with:
| Knowledge | Assessment methods |
|---|---|
|
K1
Mathematics: the mathematical techniques and analytical methods required to model software and hardware systems: algebra, calculus, geometry, Boolean Logic, trigonometry and statistics. Back to Grading |
Project report and presentation with questions |
|
K2
Software requirements development: the requirement lifecycle from concept to release; gathering, specifications, validation. Back to Grading |
Project report and presentation with questions |
|
K3
Software requirements engineering: maintenance, operating environment, identification of software security, modelling, human computer interaction, and identification of system safety. Back to Grading |
Professional discussion underpinned by a portfolio of evidence |
|
K4
Software architecture: operating system concepts and architectural considerations. Back to Grading |
Professional discussion underpinned by a portfolio of evidence |
|
K5
Software design development: structures, methodologies, techniques and validation. Back to Grading |
Project report and presentation with questions |
|
K6
Software design engineering: software functions and interconnection, flexibility, coupling and cohesion, readability, maintainability, testability, safety, security and design verification. Back to Grading |
Professional discussion underpinned by a portfolio of evidence |
|
K7
Modelling and simulation: creation and simulation of design models. Back to Grading |
Professional discussion underpinned by a portfolio of evidence |
|
K8
Software implementation development: creation of executable code. Back to Grading |
Project report and presentation with questions |
|
K9
Software implementation engineering: underlying concepts of computational thinking, abstraction, representation and modelling, language specifications including assembler, analysis, and inspection methodologies. Back to Grading |
Professional discussion underpinned by a portfolio of evidence |
|
K10
Testing the software solution: test environments; debugging and profiling facilities. Back to Grading |
Project report and presentation with questions |
|
K11
Test methodologies: methods used to test software; criticality. Back to Grading |
Professional discussion underpinned by a portfolio of evidence |
|
K12
Configuration control: configuration management methods, software build processes, tools and change control. Back to Grading |
Project report and presentation with questions |
|
K13
Software development environment: tool configurations, library functions, operating environment, compiler process and options, scripting and hardware or software integration. Back to Grading |
Project report and presentation with questions |
|
K14
System security: statutory, regulatory, organisational and certification principles in a software product. Back to Grading |
Professional discussion underpinned by a portfolio of evidence |
|
K15
Principles of quality: process conformations and assurance in an aerospace software engineering environment. Back to Grading |
Professional discussion underpinned by a portfolio of evidence |
|
K16
Continuous improvement principles and techniques: Plan-do-check-act (PDCA), Lean, 6 Sigma, and Statistical Process Control (SPC). Lean manufacturing tools. Process mapping. Back to Grading |
Project report and presentation with questions |
|
K17
Safety requirements: statutory, regulatory, organisational and certification principles (software safety integrity levels) in an aerospace software environment. Back to Grading |
Professional discussion underpinned by a portfolio of evidence |
|
K18
Teamwork: conflict management, people development techniques, performance management, diversity and inclusivity. Back to Grading |
Professional discussion underpinned by a portfolio of evidence |
|
K19
Information technology: general data protection regulation (GDPR), digital tools for presentation of data, digital communication and collaboration packages. Back to Grading |
Professional discussion underpinned by a portfolio of evidence |
|
K20
Communication techniques: verbal, written and presentations. Back to Grading |
Professional discussion underpinned by a portfolio of evidence |
|
K21
Time management techniques. Back to Grading |
Project report and presentation with questions |
|
K22
Environment and sustainability: role of software design and implementation in the end-to-end value chain for sustainable products; optimising energy and resource consumption; relationship between obsolescence and sustainability. Back to Grading |
Professional discussion underpinned by a portfolio of evidence |
|
K23
Project management: project planning, management of risks, commercial awareness, financial management and resourcing. Back to Grading |
Project report and presentation with questions |
|
K24
Report writing techniques and methods. IT applications for technical reporting. Back to Grading |
Project report and presentation with questions |
|
K25
Problem solving tools and techniques: lateral thinking, root cause analysis (RCA). Back to Grading |
Professional discussion underpinned by a portfolio of evidence |
|
K26
Software development techniques: Waterfall, Agile, and Hybrid. Back to Grading |
Project report and presentation with questions |
|
K27
Software integration techniques. Back to Grading |
Project report and presentation with questions |
| Skill | Assessment methods |
|---|---|
|
S1
Apply analytical methods; use mathematics and associated toolsets to characterise properties and behaviour of software. Back to Grading |
Project report and presentation with questions |
|
S2
Read, interpret and use Software Engineering data. For example, requirements, design, code, test and release documentation. Back to Grading |
Project report and presentation with questions |
|
S3
Develop and apply Algorithms. For example, produce specification, design and implementation for algorithms. Back to Grading |
Project report and presentation with questions |
|
S4
Select the design approach and tools for a given software engineering application and environment. Back to Grading |
Project report and presentation with questions |
|
S5
Apply model-based techniques. For example, using simulations to verify the compliance to the parent requirements. Back to Grading |
Professional discussion underpinned by a portfolio of evidence |
|
S6
Produce system and software designs. For example, produce state machine diagrams. Back to Grading |
Project report and presentation with questions |
|
S7
Setup and configure tools and the environment. For example, verification tool to target hardware requirements, management tool to design tool, and configuration tool to development tools. Back to Grading |
Project report and presentation with questions |
|
S8
Implement functional software solutions. For example, developing software solutions that incorporate new, legacy or commercial components. Back to Grading |
Project report and presentation with questions |
|
S9
Develop and execute Aerospace software test plans. Back to Grading |
Project report and presentation with questions |
|
S10
Analyse and review Aerospace software outputs. For Example, design reviews, code walkthroughs, test script reviews. Back to Grading |
Project report and presentation with questions |
|
S11
Use problem solving tools and techniques. For example: lateral thinking, root cause analysis (RCA), Kaizen, Lean manufacturing and Kanban. Back to Grading |
Professional discussion underpinned by a portfolio of evidence |
|
S12
Apply configuration management and software build processes. Back to Grading |
Project report and presentation with questions |
|
S13
Communicate with internal and external stakeholders; verbal and written. Back to Grading |
Professional discussion underpinned by a portfolio of evidence |
|
S14
Write reports. For example, data, technical information, drawings, outcomes and recommendations. Back to Grading |
Project report and presentation with questions |
|
S15
Present information. For example, presenting project progress and key performance indicators (KPI's) such as cost, quality, time, risk and opportunities. Presenting technical results into design reviews. Back to Grading |
Professional discussion underpinned by a portfolio of evidence |
|
S16
Use information technology: digital tools for presentation of data, digital communication and collaboration packages. Back to Grading |
Professional discussion underpinned by a portfolio of evidence |
|
S17
Use continuous improvement techniques and make recommendations. For example, Kaizen, Lean manufacturing and Kanban. Back to Grading |
Project report and presentation with questions |
|
S18
Use project management techniques. For example, in estimating, risk, cost and budget control, time management and resource management. Back to Grading |
Project report and presentation with questions |
|
S19
Identify and comply with legal and statutory requirements. For example: cyber security, software certification requirements, data protection, Aerospace software safety, environmental protection and sustainability. Back to Grading |
Professional discussion underpinned by a portfolio of evidence |
|
S20
Plan and manage own time. Back to Grading |
Project report and presentation with questions |
|
S21
Apply and uphold ethical principles. Back to Grading |
Professional discussion underpinned by a portfolio of evidence |
|
S22
Apply team working principles. Back to Grading |
Professional discussion underpinned by a portfolio of evidence |
|
S23
Apply software development techniques. For example, Waterfall, Agile, or Hybrid. Back to Grading |
Project report and presentation with questions |
|
S24
Apply software integration techniques. For example, networks, hardware or system integration. Back to Grading |
Project report and presentation with questions |
| Behaviour | Assessment methods |
|---|---|
|
B1
Lead by example and promote health and safety. Back to Grading |
Professional discussion underpinned by a portfolio of evidence |
|
B2
Lead by example and promote environment, ethical and sustainable practices. Back to Grading |
Professional discussion underpinned by a portfolio of evidence |
|
B3
Adapt to challenging or changing situations and be resilient to the effects. Back to Grading |
Project report and presentation with questions |
|
B4
Collaborate and promote teamwork across disciplines. Back to Grading |
Professional discussion underpinned by a portfolio of evidence |
|
B5
Lead by example to promote accessibility, diversity and inclusion. Back to Grading |
Professional discussion underpinned by a portfolio of evidence |
|
B6
Commits to their own and others' professional development. Back to Grading |
Professional discussion underpinned by a portfolio of evidence |
| KSBS GROUPED BY THEME | Knowledge | Skills | Behaviour |
|---|---|---|---|
|
Software design analysis
K2 S2 S4 |
Software requirements development: the requirement lifecycle from concept to release; gathering, specifications, validation. (K2) |
Read, interpret and use Software Engineering data. For example, requirements, design, code, test and release documentation. (S2) Select the design approach and tools for a given software engineering application and environment. (S4) |
None |
|
Software design development
K1 K5 K26 K27 S1 S3 S6 S23 S24 |
Mathematics: the mathematical techniques and analytical methods required to model software and hardware systems: algebra, calculus, geometry, Boolean Logic, trigonometry and statistics. (K1) Software design development: structures, methodologies, techniques and validation. (K5) Software development techniques: Waterfall, Agile, and Hybrid. (K26) Software integration techniques. (K27) |
Apply analytical methods; use mathematics and associated toolsets to characterise properties and behaviour of software. (S1) Develop and apply Algorithms. For example, produce specification, design and implementation for algorithms. (S3) Produce system and software designs. For example, produce state machine diagrams. (S6) Apply software development techniques. For example, Waterfall, Agile, or Hybrid. (S23) Apply software integration techniques. For example, networks, hardware or system integration. (S24) |
None |
|
Software development testing
K10 S9 S10 |
Testing the software solution: test environments; debugging and profiling facilities. (K10) |
Develop and execute Aerospace software test plans. (S9) Analyse and review Aerospace software outputs. For Example, design reviews, code walkthroughs, test script reviews. (S10) |
None |
|
Implementation
K8 K12 K13 S7 S8 S12 |
Software implementation development: creation of executable code. (K8) Configuration control: configuration management methods, software build processes, tools and change control. (K12) Software development environment: tool configurations, library functions, operating environment, compiler process and options, scripting and hardware or software integration. (K13) |
Setup and configure tools and the environment. For example, verification tool to target hardware requirements, management tool to design tool, and configuration tool to development tools. (S7) Implement functional software solutions. For example, developing software solutions that incorporate new, legacy or commercial components. (S8) Apply configuration management and software build processes. (S12) |
None |
|
Project management, continuous improvement, and communication
K16 K21 K23 K24 S14 S17 S18 S20 B3 |
Continuous improvement principles and techniques: Plan-do-check-act (PDCA), Lean, 6 Sigma, and Statistical Process Control (SPC). Lean manufacturing tools. Process mapping. (K16) Time management techniques. (K21) Project management: project planning, management of risks, commercial awareness, financial management and resourcing. (K23) Report writing techniques and methods. IT applications for technical reporting. (K24) |
Write reports. For example, data, technical information, drawings, outcomes and recommendations. (S14) Use continuous improvement techniques and make recommendations. For example, Kaizen, Lean manufacturing and Kanban. (S17) Use project management techniques. For example, in estimating, risk, cost and budget control, time management and resource management. (S18) Plan and manage own time. (S20) |
Adapt to challenging or changing situations and be resilient to the effects. (B3) |
| KSBS GROUPED BY THEME | Knowledge | Skills | Behaviour |
|---|---|---|---|
|
Software engineering requirements and architecture
K3 K4 |
Software requirements engineering: maintenance, operating environment, identification of software security, modelling, human computer interaction, and identification of system safety. (K3) Software architecture: operating system concepts and architectural considerations. (K4) |
None |
None |
|
Software design and test methodologies
K6 K11 |
Software design engineering: software functions and interconnection, flexibility, coupling and cohesion, readability, maintainability, testability, safety, security and design verification. (K6) Test methodologies: methods used to test software; criticality. (K11) |
None |
None |
|
Software implementation
K7 K9 S5 |
Modelling and simulation: creation and simulation of design models. (K7) Software implementation engineering: underlying concepts of computational thinking, abstraction, representation and modelling, language specifications including assembler, analysis, and inspection methodologies. (K9) |
Apply model-based techniques. For example, using simulations to verify the compliance to the parent requirements. (S5) |
None |
|
Problem solving
K25 S11 |
Problem solving tools and techniques: lateral thinking, root cause analysis (RCA). (K25) |
Use problem solving tools and techniques. For example: lateral thinking, root cause analysis (RCA), Kaizen, Lean manufacturing and Kanban. (S11) |
None |
|
Software certification and licencing
K14 K15 K17 S19 |
System security: statutory, regulatory, organisational and certification principles in a software product. (K14) Principles of quality: process conformations and assurance in an aerospace software engineering environment. (K15) Safety requirements: statutory, regulatory, organisational and certification principles (software safety integrity levels) in an aerospace software environment. (K17) |
Identify and comply with legal and statutory requirements. For example: cyber security, software certification requirements, data protection, Aerospace software safety, environmental protection and sustainability. (S19) |
None |
|
Data and information technology
K19 S15 S16 |
Information technology: general data protection regulation (GDPR), digital tools for presentation of data, digital communication and collaboration packages. (K19) |
Present information. For example, presenting project progress and key performance indicators (KPI's) such as cost, quality, time, risk and opportunities. Presenting technical results into design reviews. (S15) Use information technology: digital tools for presentation of data, digital communication and collaboration packages. (S16) |
None |
|
Communication, teamwork, professional and leadership behaviours
K18 K20 K22 S13 S21 S22 B1 B2 B4 B5 |
Teamwork: conflict management, people development techniques, performance management, diversity and inclusivity. (K18) Communication techniques: verbal, written and presentations. (K20) Environment and sustainability: role of software design and implementation in the end-to-end value chain for sustainable products; optimising energy and resource consumption; relationship between obsolescence and sustainability. (K22) |
Communicate with internal and external stakeholders; verbal and written. (S13) Apply and uphold ethical principles. (S21) Apply team working principles. (S22) |
Lead by example and promote health and safety. (B1) Lead by example and promote environment, ethical and sustainable practices. (B2) Collaborate and promote teamwork across disciplines. (B4) Lead by example to promote accessibility, diversity and inclusion. (B5) |
|
Continuous professional development
B6 |
None |
None |
Commits to their own and others' professional development. (B6) |
| Version | Change detail | Earliest start date | Latest start date | Latest end date |
|---|---|---|---|---|
| 1.1 | Standard and end-point assessment plan revised. Funding band revised but remained | 06/11/2023 | Not set | Not set |
| 1.0 | Approved for delivery | 03/09/2015 | 05/11/2023 | Not set |
Crown copyright © 2024. You may re-use this information (not including logos) free of charge in any format or medium, under the terms of the Open Government Licence. Visit www.nationalarchives.gov.uk/doc/open-government-licence