Software Quality Management Policy.

High-Risk Software Development Change Management and Quality Policy

Introduction

Fiddlie is committed to developing high-quality software, both standalone and embedded, that meets and exceeds our clients' expectations. Our Change Management and Quality Policy ensures that all changes, extensions, and issues related to software development are handled efficiently, effectively, and in a manner that maintains the integrity and reliability of our software products.

This policy exists to cover change management and quality control for projects that are deemed “high-risk” or “fault-intolerant” such as medical devices, critical infrastructure, life-dependent devices and others. In general it is to be used where software quality should be prioritised over development velocity.

Change Management Policy

Any proposed changes to software, including extensions or modifications, must be clearly identified and documented. This includes changes in specifications, design, implementation, or any other aspect that could affect the software's functionality or performance.

Before any change is approved, its impact on the existing system, including potential risks, compatibility issues, and implications for system integrity, must be thoroughly assessed. This assessment must consider the entire software lifecycle.

Changes must be reviewed and approved by a designated Change Control Board (CCB) composed of representatives from development, quality assurance, and project management. The CCB will ensure that changes are justified, aligned with project goals, and that all risks are adequately managed.

Approved changes must be implemented in a controlled manner, with revisions to documentation, code, and other relevant artefacts. Comprehensive testing, including regression testing, must be conducted to ensure that changes do not adversely affect the existing system.

All changes must be documented, including the rationale for the change, impact assessment, test results, and approval. Documentation must provide traceability from requirements through to implementation and testing.

Quality Policy

Each software project must have a quality plan that outlines quality goals, standards, practices, resources, and timelines. The plan will guide project execution and ensure that quality objectives are met.

We adhere to rigorous quality assurance practices throughout the software development lifecycle. This includes code reviews, unit testing, integration testing, system testing, and user acceptance testing, ensuring that our software products are robust, reliable, and meet functional requirements.

Feedback from post-implementation reviews, customer feedback, and quality audits is used to continually improve our software development processes. Lessons learned are integrated into future projects to enhance quality and efficiency.

All personnel involved in software development are required to undergo regular training to maintain high competence levels in their respective areas. This ensures that our team is equipped with the latest skills and knowledge to produce quality software products.

Issues identified at any stage of the software development lifecycle are logged, assessed for impact, and addressed according to their severity and potential impact on project timelines and quality. Root cause analysis is conducted for significant issues to prevent recurrence.

Source Control

This section outlines how source control will be utilised to support our comprehensive approach to software development, ensuring integrity, traceability, and quality throughout the project lifecycle.

Branching & Access Model

All project artefacts, including code, documentation, and test scripts, will be stored in a central repository. This repository acts as the single source of truth, ensuring that all team members have access to the latest, approved versions of each artefact.

A structured branching model will be adopted to manage different lines of development. This model will support feature development, bug fixes, and releases, allowing for parallel development while minimising conflicts and disruptions to the main codebase.

Access to the source control repository will be controlled and restricted based on roles and responsibilities. This ensures that only authorised personnel can make changes to specific parts of the project, enhancing security and integrity.

Managing Changes through Source Control

New features and extensions will be developed in separate branches, isolated from the main codebase until they are fully tested and approved. This approach facilitates easier impact assessment and rollback if necessary.

Before any change is merged into the main branch, it must go through a merge request process, including a thorough code review by peers and designated reviewers. This ensures that all changes adhere to quality standards and are in line with project objectives.

Integration with continuous integration tools will ensure that changes are automatically built and tested, providing immediate feedback on the impact of changes. This automation supports the early detection of issues, reducing risks and improving quality.

Documentation and Traceability

All changes committed to the repository must include clear, descriptive commit messages that explain the reason for the change, the nature of the change, and any relevant issue or feature IDs. This practice enhances traceability and aids in understanding the project's history.

Automated tools will be used to generate change logs from the commit history, providing an auditable trail of all changes made to the project over time. This documentation is crucial for reviews, audits, and compliance.

Significant milestones, such as releases or the completion of major features, will be tagged with version numbers. This allows for easy identification of specific states of the software, facilitates rollback to stable versions if needed, and supports release management.

Issue Management Integration

The source control system will be integrated with the issue tracking system, allowing commits to be linked to specific issues or tickets. This provides a direct correlation between changes made and the issues or requirements they address, supporting efficient issue resolution and impact analysis.

Bugs and issues identified at any stage will be addressed in dedicated branches, ensuring that fixes can be developed, tested, and reviewed without impacting ongoing development in other areas of the project.