Software Development Plan

Software development project plan

This section describes the arrangements put in place to the design and development of the device. The document describes all the activities we carry out to develop the device.

Project objectives

This plan describes the processes of the quality management system and the resources implemented within the framework of the development project of the device.

This plan helps us achieve the following objectives:

• constitute a common reference for all members of the project team: it will ensure good consistency and homogeneity in the working methods,
• guarantee the quality of the product and of the services
• reduce risks as far as possible
• define the procedures to be followed, the tools to be used, the standards to be respected, the product development methodology and the checks planned for each activity.

Project organization

Role	Description and responsabilities	Person
JD-001	JD-001 General Manager	Andy Aguilar
JD-007	Technology Manager	Gerardo Fernández
JD-003	Design & Development Manager	Taig Mac Carthy
JD-004	Quality Manager & PRRC	Saray Ugidos
JD-017	Machine Learning Ops	Alejandro Carmena
JD-018	Clinical Research Coordinator	Jordi Barrachina

Each role and function are documented in the function sheets present in the QMS.

Security class and software risk

Device Class

As described in the device risk analysis, and taking into account the intended use of the device, regarding the MDR medical device class is Class 2b.

The software classification is documented in Technical Documentation of the the device device.

Security Class

The risks caused or controlled by the device are taken into account to evaluate the class.

to review

According to the flowchart above described in standard EN 62304:2006+A1:2015, and according to the risk analysis of the software T-013-002 Risk management record_YYYY_nnn, the intended use described in description and specifications the security class of the device is: Class B.

The software classification is documented in Software Classification 62304 and SF14.15_Documentation level FDA

Project planning

to review

The JD-003 is responsible for planning and monitoring the project planning. The main tasks and milestones of the project are managed in the overall project schedule. The project Roadmap is described in Jira.

Project management tools

Atlassian software suite helps to plan, allocate resources and monitor the the device project as a whole.

Atlassian Confluence and Jira are used to record product functionality, design, verification and validation as described in the following procedure.

Relationships with project stakeholders

Customer or end-user involvement

to review

To ensure the device meets the needs of its users, the development process regular meetings are held with end-user groups to discuss product features, address concerns, and ensure the software aligns with their expectations. These sessions provide valuable feedback that informs design decisions and prioritizes features based on user needs as described in the Usability plan and design methodology in this document.

Subcontractor management

Not applicable to this project, there is no subcontractor involved in the development of the the device software solution. All the development is done by AI LABS team.

Relationships with other teams

The software development team closely works:

• with the Medical Data Science Team to get a good understanding of the AI and machine learning algorithms used in the software.
• with the Product Owner and the JD-003 to ensure that the software meets the product requirements and user needs.
• with the Quality Assurance and Regulatory Affairs Team to ensure that the software meets the quality and regulatory requirements.
• with the Customer Success Team to ensure that the software meets the customer needs and expectations.

Communication

Meetings

Product Weekly

Occurrence

Once a week (30 minutes)

Objectives

Synchronize on the current status of ongoing product development projects, discuss challenges, and define next steps across different teams involved in the the device solution.

Responsibilities

• JD-003 animates the meeting.

Attendees

Representatives from the Software Development Team, Medical Data Science Team, Regulatory and Quality Team, and Product Team are present.

Activities

• Project Status Updates: Each team provides a concise update on their current projects, highlighting progress, completed tasks, and any blockers.
• Discussion & Alignment: Open discussion to address inter-team dependencies, resolve issues, and ensure alignment on product features and priorities.
• Next Steps: Key decisions are made, and clear next steps are defined and assigned for the upcoming week.

Business Development Weekly

Occurrence

Once a week (1 hour)

Objectives

Provide an overview of current and prospective customer engagements, gather insights on emerging market needs, and identify potential new requirements for AI LABS' products based on customer feedback.

Responsibilities

• CEO animates the meeting.
• Attendees: CEO, JD-003, and members of the Sales Teams are present.

Activities

• Customer Status Review: Sales Teams report on the status of current customer relationships and progress with prospective clients.
• Market Insights & Requirements Gathering: Discussion on customer pain points, requested features, and market trends that could influence product development.
• Strategic Discussion: Alignment on sales strategies and how product development can support business objectives.

Software Development Weekly

Occurrence

Once a week (45 minutes)

Objectives

Facilitate internal communication within the software development context by providing a dedicated forum for the Software Development Team to address questions, provide updates, and clarify any aspects of their ongoing development efforts for other internal teams.

Responsibilities

• Software Architect or a designated Software Development Team Lead typically animates the meeting.
• Attendees: Software Development Team and representatives from other teams (e.g., Product, Medical Data Science, Regulatory and Quality) who have inquiries regarding software development status or technical details.

Activities

• Q&A Session: The primary focus is to allow other teams to ask questions directly to the Software Development Team regarding features in progress, technical dependencies, timelines, or any other development-related topics.
• Brief Status Updates: The Software Development Team may provide quick updates on critical path items or recent completions to inform other teams proactively.
• Clarification & Issue Resolution: Addressing specific inquiries and working towards immediate clarity or defining follow-up actions for more complex issues.

info

All operational meetings with Software Development Team are described in the Development Methodology section.

Communication channels

Team exchanges and information sharing are carried out mainly through the following channels:

• Slack: Utilized for instant communication and quick discussions among team members.
• Google Workspace: Employed for collaborative creation and sharing of documents, including internal working files and customer proposals.
• Email: Used for formal communications, external correspondence, and general information exchange.
• Planka: Serves as a Kanban board to provide an overall visual representation of the current status of various development initiatives and projects.
• Jira: Leveraged for detailed task management, tracking, and collaboration on specific developments related to medical data science and medical device software.

Training

To ensure the team maintains the necessary competencies and remains up-to-date with critical regulations and skills, personnel involved in the the device project receive training in the following areas:

• Data Protection and GDPR: Mandatory annual training is provided to ensure all team members are fully aware of their responsibilities regarding data protection and compliance with the General Data Protection Regulation (GDPR).
• Cybersecurity and Risks: Regular training sessions are conducted to educate staff on cybersecurity best practices, threat identification, and risk mitigation strategies pertinent to medical device software development and data handling.
• Specific Skills Development: Team members are encouraged to undertake various online specific trainings to acquire new skills, tools, and technologies relevant to their roles and the evolving technical landscape of medical software development.

Document version control strategy

The document version control strategy is managed according to the GP-001 Control of documents. Proofreading and validation of documents is describe in the procedure.

Activities and responsibilities

Each activity has someone responsible, mandatory. For small teams, may be always the same person.

Activity	Responsibility
Project management	JD-007 / JD-003
Configuration management	JD-007 / Lead Dev
Setting up the Development tools	JD-007 / Lead Dev
Software specifications	JD-003 / Product Owner
Product Design	JD-003 / UI/UX Designer
Software architecture	JD-007 / Software Architect
Code reviews	Software Engineer

Software Development Activities

The section lists and describes the software development activities of HeartFocus project.

Development Process Phases

As describe in the GP-012, the software development process is divided into the following phases:

Product Design - Phase 1

This phase is initiated by AI LABS stakeholders, who generate and validate the inputs as a general device description. The inputs must come from business input, technical input, product ideas, regulatory requirements or Change Request.

This phase aims to produce the following elements:

• Description and specifications
• T-012-031 Product Requirements Specification

All the Product Requirements are entered, stored and traced in the corresponding Techical Documentation.

The CEO, JD-003, JD-007 and JD-004 review all the outputs of Phase 1. This review is documented in the T-012-021 Product Design Phase 1 Checklist.

Software Design - Phase 2

This phase focuses on initiating the software design based on the stakeholder-provided inputs. Here are the expected activities and outputs for this phase:

• Document the methodology used to implement the product: T-012-036 Software Development Plan.
• Define functional requirements, performances, physical characteristics, environment conditions in which the software will run, including safety and security risk mitigation, documented in T-012-028 Software Requirement Specification.
• Defining the Software Architecture considering all functional, safety, and security risks: T-012-029 Software Architecture Description.
• Plan and document the verification of the product based on the product requirements, risks and functional specification: T-012-033 Software Tests Plan and T-012-034 Software Test Description.
• Expose the traceability showing that all requirements, safety and security risk are handled by tests. Traceability Matrix.
• Document the software classification of the device regarding the applicable standards: Document Level FDA and Software Classification 62304.

warning

¿? Defining ergonomics requirements, including manual operations, human-machine interactions, and human factors. Additionally, a UI/UX prototype of the device will be produced (as outlined in the Design Methodology)

warning

¿? add link to traceability matrix document level FDA software classification 62304

The CEO, JD-003, JD-007 and JD-004 review all the outputs of Phase 2. This review is documented in T-012-022 Software Design Phase 2 Checklist.

Additionally, all SOUPs used in the development and architecture must be listed and documented in the T-012-019 SOUP template.

Other procedures Kickoff

The start of this phase declares the kickoff of other procedures base on the outputs of Phase 1 :

• Usability and Safety Risks activities are launched regarding the GP-025 Usability and Human Factors Engineering and T-013-001 Risk management plan by JD-003 and JD-004.
• Clinical activities are launched regarding the GP-015 Clinical evaluation, by the JD-018.
• Cyber Security activities are launched regarding the GP-012-002 Cybersecurity and Transparency Requirements by JD-003 and JD-004.
• AI/ML Development activities are launched regarding the R-TF-012-009 Validation and testing of machine learning models by JD-003 and JD-004.

warning

Link usability

Agile and iterative development - Phase 3

The methodology used by the AI LABS team to develop the software is described in detail in this Plan, section Development Methodology.

The objective of this phase is to produce Release Candidate that can verified and validate. The JD-007 must validate the operational checklist, which ensures that all criteria are met for proceeding with verification:

• the version is correctly identified in AI LABS's repository and version is tagged
• the software implements all the software requirements and safety and security risk mitigation.
• the Software Tests Plan and Software Test Description are completed.
• the technical documentation and records have been reviewed and approved.

The CEO, JD-007, JD-003 and JD-004 review all the outputs of Phase 3. This review is documented in Software Candidate Release Phase 3 Checklist.

Software Verification - Phase 4

After development is completed, a candidate release should be identified for executing the verification test plan. This candidate release is documented in the Software Candidate Release Phase 3 Checklist.

The Software Testing Team initiated the software verification process and produced all expected documentation, including:

• T-012-035 Software Test Run which details the execution results for each test and test step.
• T-012-043 Traceability Matrix, which demonstrates that the verification covers all requirements in the SRS, as well. as safety and security risks.

The JD-007 approves the Candidate Release only if the test report is acceptable. If not, a new Release Candidate must be produced and re-verified. A comprehensive risk assessment of all residual anomalies is conducted to ensure the product's safety for use.

The CEO, JD-003, JD-007 and JD-004 review all the outputs of Phase 4. This review is documented in Software Verification Phase 4 Checklist.

Product Validation - Phase 5

The JD-003 initiates the validation process with the intent to validate verified software. The JD-003, with the support of the clinical team, the regulatory team, the AI/ML team, and the software development team collects all the necessary data for releasing the product and its associated documentation generated throughout:

• GP-012 Software Development Procedure and associated records
• Usability records and associated records
• GP-015 Clinical evaluation and associated records
• R-TF-012-009 Validation and testing of machine learning models and associated records
• GP-013 Risk management plan and associated records
• Cybersecurity and Transparency Requirements and associated records

warning

add link to usability records

If validated, the released software along with its documentation can then be submitted to the regulatory body for approval or directly deployed in the target markets given their legislations.

The JD-007 should document the design transfer in T-012-038 Verified Version Release.

Final Risk Assessment and Risk-Benefit Analysis

The overall risk of the product is evaluated by analyzing all identified risks so far. If unacceptable risks exist, they are weighed against the benefits of the Medical Device as part of the Clinical Evaluation SOP and as specified by the Clinical Evaluation Report. We only continue to release the Medical Device if the benefits outweigh the risks.

If unacceptable risks remain which are not outweighed by the benefits, we consider adding new risk control measures and move back into the relevant step in the process.

The finalization of the Risk Management Plan is the prerequisite for finalizing the Software Safety Classification.

info

At this step, we are able to submit to the FDA or for the CE.

• Input:
  • Risk Matrix
  • Clinical Evaluation Report
  • Software (Release Candidate)
• Output:
  • T-013-003 Risk management report
  • Documentation level FDA
  • Software Classification 62304
  • Security Risk
  • R-TF-012-006 Lifecycle plan and report
  • SF26.02_Security Risk Assessment Report

Comissioning activities

Before a medical device is released for public use, it undergoes a rigorous commissioning process. This involves setting up the device in a real-world environment, mimicking its intended use scenario. Here, Software Testing Team meticulously test all the core functionalities to ensure the device performs as designed. This real-world testing helps validate the device's effectiveness and safety in the actual conditions it will encounter, ultimately ensuring it meets its intended purpose and delivers the expected benefits to patients.

All activities for distribution, installation and comissioning are described in the GP-029 Software Delivery And Comissioning. The Software Testing Team produce the test report executed for comissioning as described in Comissioning Checklist.

Product Validation

The CEO, JD-003, JD-007, JD-004 and JD-018 review all the report of other procedure. This review is documented in T-012-026 Product Validation Phase 5 Checklist.

If the review is successful, move forward to submission and final product release. If it's not, the output has to be reworked. In that case, move back to the relevat step above.

Software development tools

The section lists the software development tools used and describes their usage.

Workstation

• The typical workstation for a software or verification engineer is a computer.
• The engineer needs to log in on the workstation with its own credentials.
• The engineer accesses all project resources using authenticated and secure connections.

Requirements management and documentation

Tool	Used for
Atlassian Jira	Create/edit/manage Software Requirements, Test Cases, User stories, Tasks, Bugs, and manage sprint. Also used to demonstrate the traceability of the entire device, considering
Product Requirements, Safety and Security Risks, Regulatory Requirements as defined in the SOP.

See above a scheme representing the traceability implemented from Product Requirements to Test Cases. All of these items are tracked in the Software Development Factory (Jira and Confluence). Traceability is established during Phase 2 using Jira links between issue and updated throughout the project.

Software design

warning

Describe the software design tools used in the project, such as UML tools, architecture design tools, etc.

Coding and automate tests

Tool	Used to
Atlassian Bitbucket	Source code management, version control, and collaboration on code development.

Configuration management

The configuration management is detailed in the T-012-043 Software Configuration Management Plan.

Tool	Used to
Atlassian Bitbucket	Source code management, version control, and collaboration on code development

Obsolescence management

Updates are made when a new version of the software development tool comes up, with the following attention points:

• All updates are made using the official channel of the development tool.
• Before updating any tool, developers check the compatibility with the development tool. If not compatible, a message is clearly displayed, meaning it shouldn't be updated prior to a thorough investigation from the lead software engineer.
• If compatible with the development tool, developers update all the plugins and tools. This best practice guarantees they all have the latest features of these software. The lead software engineer ensures all developers make the updates.
• Note that these development tools are separated from the source code and do not affect the product

These updates shall respect the GP-019 Software validation plan.

Programming languages

• Python.

Software development rules and standards

warning

Fill this section

Development Methodology

The Software Development Team uses Scrum framework that is an agile methodology. This method is apply during the development of the product.

The entire Scrum methodology is tracked and managed using Atlassian Jira Software.

Product Backlog items creation & refinement

The Product Backlog gathers every functional, regulatory, security and maintenance need identified for the device. User stories are created directly from the approved Software Requirements Specification (SRS) and each story is bi-directionally linked to its originating requirement to maintain IEC 62304 traceability.

Backlog grooming

• Ownership & cadence: the Product Owner stewards the backlog and schedules a grooming session at least once per sprint with representatives from development, quality and regulatory.
• Activities
  1. Split or merge stories so they fit within a sprint.
  2. Clarify acceptance criteria and add Definition-of-Done (DoD) checks.
  3. Attach safety class and Fix Version fields to every item.
  4. Re-order items by business value, risk reduction and readiness.
• Outcome: A “Ready” top-of-backlog sized for the next sprint and fully traceable to SRS, risk or maintenance records.

Activites good practices

warning

Fill this section

Sprint execution

Sprints are two weeks long, producing a potentially shippable increment and updated documentation each iteration.

Meetings

Event	Purpose	Time-box	Key roles
Sprint Planning	Agree sprint goal, select backlog items, size tasks	60 min	Product Owner (facilitates), Dev Team
Daily Stand-up	Inspect progress vs. goal, adjust plan	10–15 min	All developers, JD-007
Sprint Review	Demonstrate increment, collect stakeholder feedback	60 min	Dev Team, Product Owner, stakeholders
Retrospective	Identify improvements for next sprint	60 min	Dev Team, JD-007 (facilitator)

Activity and task state management

Items flow through five explicit states in Jira:

1. BACKLOG
2. TO DO
3. IN PROGRESS
4. CODE REVIEW
5. DONE

Each story or task carries a Fix Version to tie the work to a release and a safety class to enforce gating rules.

Coding, Code review, Automated tests

The coding aims at writing:

• source code for the software items and software units,
• source code for the automated tests such as unit and integration tests,
• configuration files.

When a developer finishes the development of the feature or bug fix, he follows the Pull Request workflow as specified in Software Configuration Management Plan.

The corresponding backlog item status becomes CODE REVIEW automatically.

When the Pull Request is created by the developer (the author), the continuous integration system, Bitbucket Pipelines, runs the steps defined in the project source code. In general, the following steps are performed:

• Check coding style
• Build the application code
• Build and run all automated tests and code coverage of the application
• Run static analysis over the code base of the application
• Check static analysis coding rules over the code base of the application

If any of these steps fails, the build status of the Pull Request is marked failed, and the author is notified about the error via email or instant messaging. The author has to fix the build or static analysis error then he pushes the new modifications on the branch. This will trigger the continuous integration system automatically.

Combining coding rules and static analysis tool permit to identify categories of defects that may be introduced based on the programming technology used to develop the device.

When all continuous integration steps have passed, the author assigns other software engineers and verification engineers as reviewer of the Pull Request.

Each reviewer software engineer performs the code review in order to get a second opinion on the solution and implementation such as identifying bugs, logic problems, uncovered edge cases, or other issues.

There are no formal test cases in code reviews. The results of codes reviews are discussed between the reviewers and the author attached to the Pull Request and modifications made by the author to take into account the code reviews feedback. The corresponding test cases that reflect the expected behavior of the software may be pass. The verification engineer may update the test cases or may report to the author the implemented behavior doesn’t match the expectations.

When all reviewers have accepted the Pull Request and all continuous integration steps have succeeded, the author merges the Pull Request in the target branch. The corresponding sprint backlog item is marked as DONE.

info

The peer review shall:

• verify that unit and integration tests have passed
• verify that static analysis, coding rules and coding style checks have passed
• verify the definition of done of the task is complete
• at least one reviewer shall approve

Continuous amelioration

After each sprint the Retrospective inspects people, process, tools and DoD compliance, then records concrete actions. Peer-review checklists measure code quality, test completeness and static-analysis health; their results feed into the next sprint’s improvements. Continuous improvement metrics (cycle time, escaped defects, coverage) are trended to guide process updates and training.

Jira nomenclature

Jira software is used to manage all traceability requirements. The table below details the issue types and their corresponding nomenclature:

warning

Fill this section

Verification of the release candidate

The verification phase aims at verifying that the software meet the technical requirements by executing the tests of the T-012-033 Software Tests Plan. Every requirement of the Software Requirement Specification shall be verified by at least one Test Case.

The verification phase commences under the JD-007's responsibility. He documents and verify the release eligibility criteria using the T-012-024 Software Candidate Release Phase 3 Checklist to ensure the software meets all criteria, such as implementing all SRS, risk mitigations and acceptable test coverage.

Test activities are then completed by the Software Testing Team according to the plan. All Test Execution are reported in Jira Software and the team produce the final version of the T-012-035 Software Test Run and Traceability Matrix.

warning

If the software is modified in the middle of a tests phase, for example to fix a blocking bug, all tests on which the bug and the bug fix have an impact, shall be re-run, additional testing might be required to demonstrated that no unintended side effects have been introduced and risk management activities shall be performed. A new T-012-024 Software Candidate Release Phase 3 Checklist shall be documented.

Distribution of the software for production

For any version that AI LABS wish to put into production after evolution or correction of an anomaly, the Software Development Team is in charge of producing all the deliverables to ensure production.

The process of releasing a version follows the procedure described and the steps defined in the GP-017 Technical assistance service and GP-029 Software Delivery And Comissioning.

Delivery is initiated by the JD-007, who creates the distribution sheet from design transfer documented in T-012-027 Version delivery description:

• the traceability of the version in question, that is to say the version number and its changelog,
• version tag in the development factory,
• all automatic and manual test reports,
• the updated documentation to fill the DHF and TD,
• up-to-date user manuals.

The distribution sheet constitutes the final step in Product Validation Phase 5, as described in the process documented in T-012-026 Product Validation Phase 5 Checklist. Following this step, the validation activities will be performed:

• checking user manuals,
• regulatory verification,
• release to the pre-production environment,
• validation via usability tests on a pre-production environment,
• release on the production environment,
• verification of the installation and commissioning in the production environment (see Software Delivery and Comissioning)

Software maintenance and Problem resolution

Maintenance and servicing activities are carried out by the Support Team as described in the GP-017 Technical assistance service. The JD-003 is responsible for the implementation and execution of the servicing activities. The following diagram illustrates the servicing activities.

Suppport channels

Dedicated support channels, including help desks, online forums, and support teams, will be available to address user queries and issues related to the update, as defined in our GP-017 Technical assistance service procedure.

Support is provided for every customer/user request in all cases, within 48 working hours (first response). Working hours refer to the scheduled period during which Support Team is available at work, from 9am to 5pm.

Bug management

When technical issues are identified, they are immediately added to the project backlog in Jira Software. The reporter is responsible for providing the following initial information:

• Clear steps to reproduce the behavior : explain exactly how to trigger the issue
• Expected vs. Actual Results : describe what should happen compared to what actually happens
• Evidence : attach screenshots, recordings, or any other materials that demonstrate the issue
• Affected Version : specify the version of the software where the issue occurs
• Environment Details : clearly identify the environment, including the type of probe used, device model, and operating system version To Guarantee regulatory compliance, that all bugs are identified, documented, and addressed according to relevant medical device standards, a meeting is held under the responsibility of the JD-003 and/or JD-007.

Bug triage meeting

• Objectives. Review the bug backlog to ensure all bugs are documented and addressed according to the relevant medical device standards
• Responsibilities:
  • JD-003 and/or JD-007: animates the meeting, facilitates and guides the discussion, ensuring everyone participates and the team stays focused.
  • Software Development Team / Testing Team members: provides insights into the technical aspects and potential solutions based on their knowledge of the device.
  • QARA Manager: oversees the bug review process and ensures a thorough risk assessment is conducted for each bug. Provides guidance on regulatory considerations for bug classification and resolution based on relevant standards
• Activities
  • Bug Review : each bug undergoes a combined business and technical discussion
  • Risk Assessment : identify and categorize reported bugs based on their severity and potential impact on device functionality and safety
  • Prioritize bugs : define the priority of each bug regarding their Risk Assessment

Risk Assessment

During the Triage Meeting, attendees leverage the FMEA methodology (defined in GP-013 Risk management) to discuss and define how the bug affects the safety, security, or performance of the device:

• Risk Evaluation: this step involves defining two key factors Probability of Occurrence and Severity.
• Risk Acceptability : based on the Risk Priority Number (RPN) calculated by multiplying probability and severity, the team determines if the risk is acceptable
• Risk Assessment & Control Measure: the team analyzes the root cause of the bug, proposes a correction plan to address the bug, recommends control measures to mitigate the risk if necessary. Some preventive actions can result is the root cause could be mitigated.

The evaluation results, including the acceptability, risk assessment, and control measures, are documented in the bug ticket using a custom field within Jira.

::: warning Review the following part because the risk management doesn't talk about jira tickets :::

According to the method described in the product risk management plan and to the procedure, the ticket must be linked to a risk:

• Previously known hazardous situation, the ticket is linked to a RISK issue, and the estimated severity and probability of occurrence of this risk is reviewed and updated if needed.
• New dangerous situation or a sequence of events not yet identified, the new risk is evaluated, using the risk analysis method. A new RISK ticket is created in JIRA and linked to the Problem Report ticket.
• New risk control measures are required.

A Change Request should be opened in these three cases following GP-023 Change control management. If it is decided to take no action, this rationale should be documented on the JIRA ticket.

Priority Level

The priority is set based on the risk assessment. Following this, bugs or defects undergo the previously described analysis and refinement process.

SOUPs, Software Items and NPS Management

SOUPs and Software Items management

In accordance with ISO 13485 and EN 62304, a robust procedure for managing SOUPs and Software Items is essential for medical device development. This methodology prioritizes risk mitigation while ensuring software quality.

The JD-007 is responsible of SOUPs and Software Items management activities.

Here are described the activities:

• Identification: all third-party software components and Software Items developped in the device are thoroughly identified and documented.
  • SOUPs, this includes libraries, frameworks, and any embedded code, documented in T-012-019 SOUP, also exported in SBOM (add link)
  • Software Items will be listed and documented in T-012-029 Software Architecture Description
• Classification & Risk Management: each SOUP and Software Items are categorized based on its impact on the device's safety and functionality. Higher risk require stricter controls. If safety risks are identifie, measure control and mitigation should be properly documented. The risk level classification is defined as described in the table below.
  • Acceptable
  • AFAP (“As Far As Possible”). Review required, acceptable with current risk minimization measures.
  • Unacceptable
• Security vulnerabilities : for each SOUP, vulnerabilities should be listed.
• Verification: the functionality and safety of the software are rigorously tested to ensure it meets the device's requirements. This process encompasses both internally developed Software Items and SOUPs used within the device. Verification leverages a suite of Test Cases derived from the SRS. These Test Cases define specific scenarios and expected outcomes, allowing for a systematic evaluation of the software's behavior against the documented requirements. Through rigorous verification, we gain objective evidence that the software functions as intended and adheres to the critical safety standards outlined in the SRS.
• SOUPs Review and Update: the SOUP list (available at T-012-019 SOUP) is reviewed annually. Additionally, the team can initiate an update outside the annual cycle if deemed necessary. Any updates to SOUPs require JD-007 approval following verification of the changelog, potential regressions, and security vulnerabilities. A new revision of the T-012-019 SOUP and T-024-001 Software Bill of Materials. The functionality and safety of the software should be reverified.