T-012-023 Software Development Plan
Software development project plan
This section must describe the arrangements put in place to the design and development of a product developed at AI LABS.
Project objectives
In this section, briefly describe the main goals of the quality and development plan for the software project. Include objectives such as team alignment, risk reduction, product quality assurance, and methodological consistency. Tailor the wording to the specific project or organization.
Project organization
List the key roles involved in the project, along with a brief description of their responsibilities and the name of the person assigned to each role. Make sure the descriptions align with the actual duties and reflect the organizational structure of the project.
Security class and software risk
Device Class
Specify the medical device class based on the applicable regulations (e.g., MDR), referencing the device’s intended use and risk analysis. Include where the classification is documented for traceability.
Security Class
The risks caused or controlled by the device are taken into account to evaluate the class.
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
Indicate who is responsible for project planning and monitoring. Mention the tools or platforms used (e.g., Jira) and reference where the project milestones and timeline are documented.
Project management tools
Briefly describe the tools used for project management and documentation (e.g., Jira, Confluence). Explain their role in tracking progress, recording product information, and supporting project coordination.
Relationships with project stakeholders
Customer or end-user involvement
Explain how user needs are integrated into the development process. Mention the organization of regular meetings with end users and how their feedback is used to guide design decisions and feature prioritization.
Subcontractor management
State whether subcontractors are involved in the project. If not applicable, clearly indicate that all development activities are carried out internally by the project team.
Relationships with other teams
List the internal teams the software development team collaborates with and explain the purpose of each collaboration. Focus on how these interactions support technical alignment, regulatory compliance, product requirements, and user satisfaction.
Communication
Meetings
For each recurring meeting, specify the title, occurrence (frequency and duration), and objectives. Clearly define who leads the meeting and list the attendees. Describe the main activities typically covered (e.g., status updates, discussions, planning, Q&A). Use a consistent structure across all meetings to ensure clarity and comparability.
Communication channels
List the main tools and platforms used for communication and collaboration within the project. For each channel, briefly describe its specific purpose (e.g., instant messaging, documentation, task tracking). Focus on how each tool supports efficient team coordination.
Training
Describe the training areas relevant to the project team, including mandatory and role-specific topics. Indicate how often the training is conducted and its purpose (e.g., GDPR compliance, cybersecurity awareness, skill development). Focus on ensuring up-to-date competencies aligned with regulatory and technical needs.
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
Identify the main activities involved in the software development lifecycle and clearly assign responsibility for each. In small teams, one person may cover multiple roles, but all activities must have a designated owner to ensure clarity and accountability.
Software Development Activities
The section lists and describes the software development activities of HeartFocus project.
Development Process Phases
As describe in the Software Development Procedure, the software development process is divided into the following phases:
Product Design - Phase 1
Describe how the initial product design phase is triggered and what types of input are required (e.g., business, technical, regulatory). List the key outputs to be generated, where they are documented, and who is responsible for reviewing and approving them. Include references to templates or documentation tools used.
Software Design - Phase 2
Detail the expected deliverables and activities for the software design phase. Include documentation of development methodology, software requirements, architecture, test planning, and risk mitigation. Mention the required reviews and where traceability, classification (FDA, IEC 62304), and SOUP components must be recorded. Ensure all documents are referenced and linked appropriately.
Other procedures Kickoff
Explain that this phase initiates parallel procedures based on Phase 1 outputs. Specify the areas activated (Usability & Safety Risks, Clinical Evaluation, Cybersecurity, AI/ML development), the procedures they follow, and who is responsible for launching each. Include links to relevant plans or templates.
Agile and iterative development - Phase 3
Describe the goal of this phase as delivering a Release Candidate ready for verification and validation. Outline the criteria that must be met (e.g., versioning, implementation of requirements, completion of test plans, documentation review). Indicate who is responsible for validating the checklist and reviewing the outputs. Include links to relevant documents and checklists.
Software Verification - Phase 4
Explain that this phase involves executing the verification plan on the identified candidate release. List the required outputs, including the test run report and traceability matrix. State that the CTO must approve the release based on test results and that residual risks must be assessed. Mention the review process and checklist used to document approvals.
Product Validation - Phase 5
Summarize the goal of this phase as validating the verified software for release. List the documentation and records required from different areas (e.g., development, usability, clinical, AI/ML, risk, cybersecurity). Indicate who initiates and supports the process, and note that the design transfer must be formally documented before regulatory submission or market deployment.
Final Risk Assessment and Risk-Benefit Analysis
Describe how the overall risk of the software is assessed before release, using inputs like the Risk Matrix, Clinical Evaluation Report, and the Release Candidate. Explain that the product can only proceed if benefits outweigh the risks. List the final outputs required, including the Risk Management Report, regulatory classification documents, and security risk assessments.
Comissioning activities
Summarize the purpose of the commissioning phase as validating the software in real-world conditions before release. Describe the setup, testing, and reporting activities led by the Software Testing Team. Reference the procedures and checklist used to guide and document commissioning and delivery tasks.
Product Validation
Explain that this final review step involves validating all outputs from previous procedures. List the roles involved in the review and reference the checklist used. State that approval allows submission and release; otherwise, corrections must be made by returning to the appropriate phase.
Software development tools
List all software development tools used in the project, grouped by purpose (e.g., requirements management, design, coding, configuration). Describe how each tool supports the development lifecycle, including traceability and version control. Include programming languages used, obsolescence management practices, and reference any related validation or configuration plans. Leave placeholders or notes for sections pending completion (e.g., development rules and standards).
Development Methodology
Describe the development methodology used (e.g., Scrum, Agile). Mention the tools used to support and track the methodology (e.g., Jira). Optionally, include a diagram or visual that illustrates the framework applied during development.
Product Backlog items creation & refinement
Explain how Product Backlog items are created from approved requirements and maintained with traceability to satisfy IEC 62304. Describe the backlog grooming process, its frequency, who participates, the key activities, and the expected outcomes. Leave space for filling in good practices for activity execution.
Sprint execution
Summarize the sprint execution process, including sprint duration, key meetings (with purpose, timing, and participants), and task state transitions in the tracking tool. Describe the coding and code review workflow, including automated testing and CI checks. Make sure to explain how traceability, quality, and peer review are enforced before merging code and closing backlog items.
Continuous amelioration
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:
Fill this section
Verification of the release candidate
Explain that this phase verifies the release candidate against all software requirements using the defined test plan. The CTO confirms eligibility using a checklist, and the Software Testing Team executes and reports all tests in Jira. Emphasize that if changes occur mid-phase, impacted tests must be re-run, side effects analyzed, and risk management updated.
Distribution of the software for production
Describe how a validated software version is prepared and distributed for production. Indicate that the CTO initiates the process using the version delivery template, ensuring traceability, test reports, and documentation are complete. Reference the steps for final validation, including usability testing and production commissioning, and align with the servicing and delivery procedures.
Software maintenance and Problem resolution
Maintenance and servicing activities are carried out by the Support Team as described in the Servicing Activities. The CPO is responsible for the implementation and execution of the Servicing Activities. The following diagram illustrates the servicing activities.
add diagram
Suppport channels
Describe the support channels available to users (e.g., help desk, forums, support team) and reference the procedure governing servicing activities. Include the guaranteed response time and define the working hours during which support is provided.
Bug management
Explain how bugs are managed by logging them in Jira with detailed information (steps to reproduce, expected vs. actual results, evidence, version, and environment). State that a review meeting led by the CPO/CTO ensures proper tracking and resolution in line with medical device regulations.
Bug triage meeting
Describe the purpose of the bug triage meeting: to review and prioritize bugs in line with medical device standards. List the roles involved (CPO/CTO, developers, testers, QARA) and their responsibilities. Outline key activities: bug review, risk assessment, and prioritization based on impact and severity.
Risk Assessment
Explain that risk assessment during the bug triage meeting follows the FMEA method as defined in the Risk Management procedure. Describe how bugs are evaluated for probability and severity, how risk acceptability is determined, and how control measures are proposed. Document all results (including root cause and corrective actions) clearly. Ensure that each bug is linked to an existing or new risk in the risk register, and open a Change Request if required, referencing the Change Control procedure.
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
Describe how SOUPs (third-party software) and internally developed Software Items are managed, in compliance with ISO 13485 and EN 62304. Include steps for identification, classification by risk level, verification, and ongoing review. Explain how risks and vulnerabilities are assessed, and ensure all components are documented (e.g., SOUP list, SBOM, architecture). Mention that updates require CTO approval and must be reverified.