LOGO
Table of Contents
1 2 3 4 5
Document Change History ........................................................................................................ 2 Purpose ...................................................................................................................................... 2 Scope .......................................................................................................................................... 2 Roles & Responsibilities ............................................................................................................ 2 Procedure ................................................................................................................................... 3 5.1 5.2 6 6.1 6.2 6.3 6.4 6.5 6.6 6.7 6.8 7 7.1 7.2 7.3 7.4 8 8.1 8.2
Introduction ....................................................................................................................... 3 Software Safety Classification and Level of Concern ...................................................... 5 Software Development Planning ...................................................................................... 6 Software Requirements Analysis ..................................................................................... 7 Software Architecture Design........................................................................................... 8 Software Detailed Design .................................................................................................. 8 Software Unit Implementation and Verification ............................................................. 9 Software Integration and Integration Testing ................................................................ 9 Software Verification and Validation ............................................................................. 10 Software Release ............................................................................................................. 10 Software maintenance planning..................................................................................... 11 Software change analysis ................................................................................................ 11 Change implementation .................................................................................................. 11 Software end of life .......................................................................................................... 11 Risk analysis and evaluation .......................................................................................... 11 Risk control ...................................................................................................................... 12
Software Development Process ............................................................................................... 6
Software Maintenance Process .............................................................................................. 11
Software Risk Management Process ...................................................................................... 11
9 Software Configuration Management Process ...................................................................... 12 10 Software Problem Resolution Process............................................................................... 13 11 Review Cycle ........................................................................................................................ 14 12 Definitions ............................................................................................................................ 14 13 References ............................................................................................................................ 15 14 Appendix A: Deliverables based on Software Safety Classification ................................. 16
Page 1 of 16
SOP-011Software Lifecycle Processes
LOGO
1 Document Change History
Version 01 Reason for change Initial Release Effective from 2 Purpose
The purpose of this procedure is to describe the software lifecycle processes during development and maintenance phases of medical device software that are compliant with the regulatory requirements.
3 Scope
This procedure covers the full software lifecycle from project initiation to the first software product release and the subsequent maintenance activities until the end-of-life of the software product.
This procedure describes expected activities and deliverables regardless of development methodology. The development methodology used for development, e.g., agile, waterfall, is at the discretion of the project team.
The procedure applies to all medical device software products developed by Shanghai Akon.
External development may be conducted following this procedure or the external company’s own procedure(s) if that company’s procedure(s) meets all elements of design controls.
The procedure does not apply to non-product software solutions. The non-product software solutions follow the Lifecycle Management of Computerized Systems SOP[7].
4 Roles & Responsibilities
Role Software Team Head Software Team Quality Team Owner of this procedure Responsible for following this procedure when conducting software development activities Ensures all software development activities are in compliance withthis procedure Responsibilities
Page 2 of 16
SOP-011Software Lifecycle Processes
LOGO
5 Procedure
5.1 Introduction
5.1.1 Software Lifecycle Overview
A software lifecycle, as illustrated in Figure1, starts with the project initiation and ends with the end-of-life of the software product.The software lifecycle includes a software development phase and a software maintenance phase. The handover from software development to software maintenance is called software transition. Although, this transition can be a relatively short phase, it has to be properly defined, prepared and executed to ensure high quality software throughout the entire lifecycle.
Software LifecycleReleaseProject InitiationSoftwareDevelopmentTransitionSoftwareMaintenanceRelease(s)SoftwareProduct end-of-life Figure 1: Software Lifecycle Overview
Page 3 of 16
SOP-011Software Lifecycle Processes
LOGO
5.1.2 Software Lifecycle Core Processes
Figure 2: Software Lifecycle Core Processes
Page 4 of 16
SOP-011Software Lifecycle Processes
LOGO
5.1.3 Mapping IEC 62304 Tasks to Activities
The list below shows the mapping of the IEC 62304 [1] tasks to the activities described in this document. The IEC 62304 tasks are referenced via the IEC 62304 chapter that describes them. The activities are referenced by the chapter in this document that describes them.
IEC 62304 chapter and tasks 4.3 Software safety classification 5.1 Software development planning 5.2 Software requirements analysis 5.3 Software architectural design 5.4 Software detailed design 5.5 Software unit implementation and verification 5.6 Software integration and integration testing 5.7 Software system testing 5.8 Software release 6 Software maintenance process 7 Software risk management process 8 Software configuration management process 9 Software problem resolution process In the above list, some of the IEC 62304 general requirements do not appear, because they are covered in the following:
Quality management system
A quality management system has been established to ensure that medical device software consistently meets customer requirements and applicable regulatory standards. Risk management
A risk management process has been established in compliance with EN ISO 14971 [2].
Chapter in this document 5.2Software Safety Classification and Level of Concern 6.1Software DevelopmentPlanning 6.2 Software RequirementsAnalysis 6.3 Software Architecture Design 6.4 Software Detailed Design 6.5 Software Unit Implementation and Verification 6.6 Software Integration and Integration Testing 6.7 Software Verification and Validation 6.8 Software Release 7 Software Maintenance Process 8 Software Risk Management Process 9 Software Configuration Management Process 10 Software Problem Resolution Process 5.2 Software Safety Classification and Level of Concern
5.2.1 Software Safety Classification
Page 5 of 16
SOP-011Software Lifecycle Processes
LOGO
A software safety class (A, B, or C) shall be assigned to each software product according to the possible effects on patient, operator, or other people, resulting from a hazard to which the software productcan contribute.
The software safety classes shall initially be assigned based on thehighest severity levelthat resulted from the software risk management process.
Class A No injury or damage to health is possible Class B Non-serious injury is possible Class C Death or serious injury is possible
5.2.2 Software Level of Concern
Software Level of Concern (Minor, Moderate, Major) shall be analyzed and documented following the FDA Guidance for the Content of Premarket Submissions for Software Contained in Medical Devices [3].
6 Software Development Process
6.1 Software Development Planning
A software development plan (SDP) shall be created for each software development project. This software development plan describes activities, deliverables, procedures, and practices according to the scope and the software safety classification and the software level of concern.
The software development plan may be used to explain a process deviation from the processes defined in this document or establish project specific processes. Approval of the software development plan indicates acceptance of the deviations.
The software development plan shall address the following for a project:
Page 6 of 16
SOP-011Software Lifecycle Processes
LOGO
Alignment between software development activities and the systems
development activities
Deliverables, timeline, milestones, resources and scope Software Safety Classification
Roles and responsibilities for deliverables
Deviations from company and regulatory procedures, if any Software interaction design and usability evaluations
Software requirements management and traceability analysis Software development environment
Software development methodologies, tools and standards Software implementation and unit verification Software design reviews
Software integration and integration testing Software verification and validation activities Software risk management approach Software problem resolution approach
Software configuration management(including versioning strategy) Software Of Unknown Provenance (SOUP) components
Plan development and validation activities for tools used to support software
product development Software release activities
Project handover from software development to software maintenance
6.2 Software Requirements Analysis
6.2.1 Software Requirements Content
Software requirements are derived from the system-level product requirements and risk controls.
The output of software requirements analysis isa set of software requirements and specifications (SRS). These SRSs shall be documented and updated as necessary during the project. The SRS shall address the following:
Functional requirements
Software system inputs and outputs
Interactions between the software system and other systems Software-driven alarms, warnings, and operator messages Security requirements Usability requirements
Data definition requirements
Operation and maintenance requirements Regulatory requirements
Installation and acceptance requirements Risk control requirements, if applicable
6.2.2 Software Requirements Review
The software requirements shall be reviewed to ensure the following:
Page 7 of 16
SOP-011Software Lifecycle Processes
LOGO
Address the system-level product requirements assigned to software
including those related to risk controls Do not contradict one another
Are clearly and unambiguously defined Can be implemented
Are verifiable and documented in a manner that permits establishment of
acceptance criteria and permits creation of tests to determine whether the acceptance criteria has been met Are uniquely identified
Are traceable to system-level product requirements , risk controls, and/or
other source
6.2.3 Software Requirements Traceability Analysis
Traceability analysis shall be performed to ensure the system-level product requirements are implemented and the risks (if applicable) are mitigated. Results of the traceabilityanalysis shall be documented.
6.3 Software Architecture Design
Software architecture defines the high level organizational structure of a software system based on the software requirements. The software architecture also defines the interactions between the software items within the system as well as the interactions with external software.
The software architecture shall show the software item segregation and the effectiveness of the segregation to safeguard the risk controls defined in the risk management process.
The software architecture design shall be documented and updated. It can be a standalone document or it can be combined with the software detailed design document.
The software architecture shall address the following:
Architectural goals and constraints including quality, safety, security and
performance
Architecture decomposition
Relationships between decomposed software items as well as external software Support for SOUP components
Risk segregation between software items
Safety classification (A, B or C) of software items
List any alternative architectures considered along with a discussion as to why they
were not selected
Software architecture design shall be reviewed via software technical design review and results of the review shall be documented in the software technical design review report.
6.4 Software Detailed Design
Page 8 of 16
SOP-011Software Lifecycle Processes
LOGO
Software detailed design defines how each software unit will be constructed in detail. The software detailed design shall address the following:
Detailed design of the software, based on the architecture and the requirements Software units and their functional behavior
Interfaces between internal units as well as to external software Hardware and software required by SOUP software
Software detailed design shall be reviewed via software technical design review and results of the review shall be documented in the software technical design review report.
6.5 Software Unit Implementation and Verification
Software unit implementation creates the source code for the software units and verifies the software units to ensure they meet the acceptance criteria prior to integration into larger software items.
6.5.1 Source Code Development
Implement software features and functions by creating source code based on
software detailed design specification and coding guidelines Source code is under configuration control
6.5.2 Unit Verification
Define, create and run unit tests to ensure software units meet acceptance
criteria prior to integration into larger software items Plan and execute code reviews
Document the results of the unit tests and code reviews
6.6 Software Integration and Integration Testing
Software integration combines the developed software units into larger software items and finally to the entire software system. During integration testing, the correct functionality of the software units, the integrated software items and the software system isverified against the relevant specifications and requirements.
Software integration and integration testing shall include the following:
Plan the integration and the integration testing
Define acceptance criteria for successfully integrated software units Integrate software units
Conduct integration testing and verify that the integrated units work according to
their specification and meet their acceptance criteria
Record any issues found and process them according to software problem resolution Document software integration and the integration testing results
Page 9 of 16
SOP-011Software Lifecycle Processes
LOGO
6.7 Software Verification and Validation
Software Verification ensures that the software completely and correctly fulfils all software requirements and specifications.Software verification is performed by means of tests, reviews, inspections, or analysis in accordance with approved software verification test plan.
Software Validation ensures that the software conforms to user needs and intended uses. Itis typically performed as part of the Systems Design Validation. Validation is the sum of all activities that focus on the examination of the system in an environment that is equivalent to its use in production under actual or simulated use conditions. Systems Design Validation is performed by means of testing and inspection.
6.7.1 Software Verification
Establish software verification test plan
Establish test procedures and pass/fail criteria
Execute tests according to the software verification test plan Document all tests and test results including deviations
Report and correct issues found via software problem resolution
When changes made to resolve an issue, retest the software to ensure that the issue has been corrected and no unintended side effects have been introduced
Create traces between tests and software requirements to ensure all
software requirements are tested
6.7.2 Software Validation
Software validation is performed as part of the Systems Design Validation. See Verification & ValidationSOP [5] for tasks and more details.
6.8 Software Release
Software release is the activity to distribute the software together with the release documentation. Only if the software verification is completed and results evaluated via release review, can the software be released. The release review shall include participation by independent reviewer who does not have direct responsibility for the design development.
6.8.1 Release Report
The release report shall include the following:
The version of the software that is being released Remaining software issues
A description ofnew features and changes, compatibility with other systems
or system components, dependencies, installation instructions, etc.
Page 10 of 16
SOP-011Software Lifecycle Processes
6.8.2 Release review
LOGO
A release review shall be conducted prior to a software release. The release review shall cover the following:
The software verification test is completed and results are acceptable.
The remaining software anomalies do not contribute to unacceptable risks. All other software deliverables are completed as defined in the software
development plan.
7 Software Maintenance Process
Software maintenance process begins after the first release of a software product. The main goal of software maintenance process is to preserve the integrity and quality of the software product while it undergoes changes or upgrades.
7.1 Software maintenance planning
Establish the plans and procedures for the software transition and all software maintenance activities. This includes creating and maintaining a maintenance plan, executing the software transition, implementing procedures to manage, document and process change requests and issues, and updating the configuration management.
7.2 Software change analysis
Consist of the monitoring, investigation and assessment of all software issues. Based on the issue assessment, possible resolutions of the issue are evaluated using the problem resolution process. Part of the issue resolution evaluation is the risk management process of the software solution.
7.3 Change implementation
Product upgrades, change requests and the resolution of issues are executed using the software development activities documented in Chapter 6.
7.4 Software end of life
If during the maintenance phase of a project it is anticipated that one or more software components will reach their end of life, the software maintenance plan should address end-of-life concerns.
8 Software Risk Management Process
The software risk management activitiessupports the product risk management as defined inRisk Management SOP[6].
8.1 Risk analysis and evaluation
Page 11 of 16
SOP-011Software Lifecycle Processes
LOGO
Identify software items that contribute to hazardous situation (including software
changes).
Identify potential causes that contribute to hazardous situation such as the following:
Incomplete functional specification Software failures (including SOUP) Hardware failures Foreseeable misuse Cybersecurity
Usability related operator errors
Evaluate effects on existing risk control measures when changes are made to the software.
Evaluate published SOUP anomaly lists for contribution to hazardous situations. Document potential causes of software items that contribute to hazardous situation. Document sequence of events that lead to the hazardous situation.
8.2 Risk control
Define risk control measures to avoid risk or reducerisk.
Implement risk control measures such as add/update software requirements, re-assess safety classification (A,B or C), etc. Verify risk control measures.
Ensure risk control measures do not introduce new hazardous situations. Document risk control effectiveness.
Document traceability among software risks, software risk controls, and risk
verification.
9 Software Configuration Management Process
Software configuration management safeguards and maintains the configuration of the software by identified configuration items. In the software configuration management plan, the configuration items are defined. Possible items are the documentation, the development environment, the source code repository, the build process, the deployment, etc.
Software Configuration Management Process focuses on the following activities:
Establish the software configuration management plan Define the configuration items of the project
Assign a configuration item ID to each SOUP software used
Define how changes to configuration items and software changes are managed Implement and verify approved changes to configuration items and software
Document all changes made to the configuration items, their implementation and
verification
Page 12 of 16
SOP-011Software Lifecycle Processes
LOGO
10 Software Problem Resolution Process
Software problem resolution documents all reported issues, informs the affected stakeholders, investigates the issues, and evaluates possible resolutions. Approved resolutions are implemented and verified for the effectiveness of the issue resolution. Regression testing may be performed to ensure no adverse side effects to the already verified software units.
Software Problem Resolution Process focuses on the following activities:
Define the process to handle issues including the form to report issues (e.g. title, type,
scope, product risk, issue description, etc.)
Investigate issues reported to determine root cause
Inform stakeholders about issues found, their causes and resolutions Implement the changes Verify modified software
Document issues, investigation results, changes, their verification and impacts
Page 13 of 16
SOP-011Software Lifecycle Processes
LOGO
11 Review Cycle
This procedure is subject to a review cycle of no more than 36 months. Before the end of this period, the document must be re-released, even if it remains valid without changes.
12 Definitions
Acronyms should be expanded upon their first use within context. Term Definition FMEA IEC ISO Failure Mode and Effects Analysis International Electrotechnical Commission International Organization for Standardization Medical Device SOFTWARE SYSTEM that has been developed for the purpose of being Software incorporated into the MEDICAL DEVICE being developed or that is intended for use as a MEDICAL DEVICE in its own right (IEC 62304 term) OTSS SDP Software Item Software System Software Unit SOUP SRS Of The Shelf Software (Commercial and Open Source) Software Development Plan Any identifiable part of a computer program Integrated collection of software items organized to accomplish a specific function or set of functions Software item that is not subdivided into other items Software Of Unknown Provenance (IEC 62304 term) Software Requirements and Specification
Page 14 of 16
SOP-011Software Lifecycle Processes
13 References Document Number IEC62304 EN ISO14971 N/A SOP-001 SOP-00x SOP-002 SOP-00x LOGO
Reference Documents [1] International Standard Medical Device Software – Software Life Cycle Processes CEI/IEC 62304:2006 [2] Medical devices – Application of risk management to medical devices EN ISO 14971:2012 [3] FDA Guidance for the Content of Premarket Submissions for Software Contained in Medical Devices [4] Product Development Process SOP [5] Design Verification & Validation SOP [6] Risk Management SOP [7] Lifecycle Management of Computerized Systems SOP Page 15 of 16
SOP-011Software Lifecycle Processes
LOGO
14 AppendixA: Deliverables based on Software Safety Classification
Item # 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 *** x o
Software Deliverables Software Safety Classification and Level of Concern Software Development Plan Risk Management Plan (including OTSS risk, IT Security risk) Risk Management Report Configuration Management Plan Usability Engineering File Requirement Management Plan Software Traceability Analysis Software Development Environment Description (list of software tools and programs used ) Software Supporting Tools Validation Plan and Report (compiler, bug tracking system, etc.) Software FMEA Report Software Maintenance Plan Software Requirements and Specification (including UI specifications and IT security requirements) Software Architecture Design Software Interface Specifications (if applicable, such as communication interfaces) Software Detailed Design Software Unit Test Plan Software Unit Test Report Software Integration Test Plan (could be combined) Software Integration Test Report (could be combined ) Software System Verification Plan Software System Verification Report Software Release Report Software Technical Design Reviews (including code reviews) 21 CFR Part 11 Compliance Assessment Report, if applicable OTSS Assessment Report (License, Legal, etc.), if applicable Outstanding Anomaly Report Software Code Sets (source code and executables) IEC62304 Compliance Report Part of system level deliverables Required optional
Safety Class A B , C x x x o o x o x x o o o x x o o o o o o o x x x o x x o x x
x x x x x x x x x x x x x x x x x x x x x x x x x x x x
*** *** *** *** ***
Page 16 of 16
因篇幅问题不能全部显示，请点此查看更多更全内容