Skip to main content
QMSQMS
QMS
  • Welcome to your QMS
  • Quality Manual
  • Procedures
    • GP-001 Control of documents
    • GP-002 Quality planning
    • GP-003 Audits
    • GP-004 Vigilance system
    • GP-005 Human Resources and Training
    • GP-006 Non-conformity, Corrective and Preventive actions
    • GP-007 Post-market surveillance
    • GP-008 Product requirements
    • GP-009 Sales
    • GP-010 Purchases and suppliers evaluation
    • GP-011 Provision of service
    • GP-012 Design, redesign and development
      • Deprecated
      • Templates
        • T-012-004 Software version release
        • T-012-005 Design change control
        • T-012-006 _Product name_ life cycle plan and report_YYYY_nnn
        • T-012-007 Formative evaluation plan_YYYY_nnn
        • T-012-008 Formative evaluation report_YYYY_nnn
        • T-012-009 Validation and testing of machine learning models_YYYY_nnn
        • T-012-010 Device backup verification_YYYY_nnn
        • T-012-012 Customers product version control_YYYY_nnn
        • T-012-013 Design stage review
        • T-012-014 Summative evaluation plan_YYYY_nnn
        • T-012-015 Summative evaluation report YYYY_nnn
        • T-012-016 Software usability test guide
        • T-012-017 Integration test review
        • T-012-019 SOUP
        • T-012-020 Predetermined Change Control Plan
        • T-012-021 Product Design Phase 1 Checklist
        • T-012-022 Software Design Phase 2 Checklist
        • T-012-023 Software Development Plan
        • T-012-024 Software Candidate Release Phase 3 Checklist
        • T-012-025 Software Verification Phase 4 Checklist
        • T-012-026 Product Validation Phase 5 Checklist
        • T-012-028 Software Requirement Specification
        • T-012-029 Software Architecture Description
        • T-012-030 Software Configuration Management Plan
        • T-012-031 Product Requirements Specification
        • T-012-033 Software Tests Plan
        • T-012-034 Software Test Description
        • T-012-035 Software Test Run
        • T-012-037 Labeling and IFU Requirements
        • T-012-038 Verified Version Release
        • T-012-039 Validated Version Transfer
        • T-012-040 Documentation level FDA
        • T-012-041 Software Classification 62304
        • T-012-042 Regulatory Requirement
        • T-012-043 Traceability Matrix
      • GP-012 [Old version] Design, Redesign and Development
      • Specific procedures
    • GP-013 Risk management
    • GP-014 Feedback and complaints
    • GP-015 Clinical evaluation
    • GP-016 Traceability and identification
    • GP-017 Technical assistance service
    • GP-018 Infrastructure and facilities
    • GP-019 Software validation plan
    • GP-020 QMS Data analysis
    • GP-021 Communications
    • GP-022 Document translation
    • GP-023 Change control management
    • GP-024 Cybersecurity Risk Management
    • GP-025 Usability and Human Factors Engineering
    • GP-027 Corporate Governance
    • GP-028 AI Development
    • GP-029 Software Delivery And Comissioning
    • GP-050 Data Protection
    • GP-051 Security violations
    • GP-052 Data Privacy Impact Assessment (DPIA)
    • GP-100 Business Continuity (BCP) and Disaster Recovery plans (DRP)
    • GP-101 Information security
    • GP-200 Remote Data Acquisition in Clinical Investigations
    • GP-026 Market-specific product requirements
    • GP-110 Esquema Nacional de Seguridad
  • Records
  • Legit.Health Plus Version 1.1.0.0
  • Legit.Health Plus Version 1.1.0.1
  • Licenses and accreditations
  • External documentation
  • Public tenders
  • Procedures
  • GP-012 Design, redesign and development
  • Templates
  • T-012-023 Software Development Plan

T-012-023 Software Development Plan

Software development project plan​

Instructions

This section must describe the arrangements put in place to the design and development of a product developed at AI LABS.

Project objectives​

Instructions

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​

Instructions

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​

Instructions

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.

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​

Instructions

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​

Instructions

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​

Instructions

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​

Instructions

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​

Instructions

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​

Instructions

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​

Instructions

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​

Instructions

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​

Instructions

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​

Instructions

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​

Instructions

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​
Instructions

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​

Instructions

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​

Instructions

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​

Instructions

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​
Instructions

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​
Instructions

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​
Instructions

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​

Instructions

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​

Instructions

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​

Instructions

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​

Instructions

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:

warning

Fill this section

Verification of the release candidate​

Instructions

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​

Instructions

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.

warning

add diagram

Suppport channels​

Instructions

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​

Instructions

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​

Instructions

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​

Instructions

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​

Instructions

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.

Previous
T-012-022 Software Design Phase 2 Checklist
Next
T-012-024 Software Candidate Release Phase 3 Checklist
  • Software development project plan
    • Project objectives
    • Project organization
    • Security class and software risk
      • Device Class
      • Security Class
    • Project planning
    • Project management tools
    • Relationships with project stakeholders
      • Customer or end-user involvement
      • Subcontractor management
      • Relationships with other teams
    • Communication
      • Meetings
      • Communication channels
    • Training
    • Document version control strategy
  • Activities and responsibilities
  • Software Development Activities
    • Development Process Phases
      • Product Design - Phase 1
      • Software Design - Phase 2
        • Other procedures Kickoff
      • Agile and iterative development - Phase 3
      • Software Verification - Phase 4
      • Product Validation - Phase 5
        • Final Risk Assessment and Risk-Benefit Analysis
        • Comissioning activities
        • Product Validation
    • Software development tools
    • Development Methodology
      • Product Backlog items creation & refinement
      • Sprint execution
      • Continuous amelioration
      • Continuous amelioration
      • Jira nomenclature
      • Verification of the release candidate
      • Distribution of the software for production
  • Software maintenance and Problem resolution
    • Suppport channels
    • Bug management
      • Bug triage meeting
      • Risk Assessment
      • Priority Level
  • SOUPs, Software Items and NPS Management
    • SOUPs and Software Items management
All the information contained in this QMS is confidential. The recipient agrees not to transmit or reproduce the information, neither by himself nor by third parties, through whichever means, without obtaining the prior written permission of Legit.Health (AI LABS GROUP S.L.)