| 1 | [.. 소프트웨어 개발 지침서 (Software Development Guideline)] |
| 2 | |
| 3 | = 일반 요구사항 (General Requirements) = |
| 4 | |
| 5 | == 5.1. 품질관리시스템 == |
| 6 | 제조자는 다음 중 하나 이상의 품질관리시스템을 확보해야 한다: |
| 7 | 1. ISO 13485 |
| 8 | 1. 국가 품질관리시스템 표준 |
| 9 | 1. 국가 품질관리시스템 인정서 (예, KGMP) |
| 10 | |
| 11 | == 5.2. 위험관리 == |
| 12 | 본 문서의 7. 소프트웨어 위험 관리를 따른다. |
| 13 | |
| 14 | == 5.3. 소프트웨어 안전 등급 == |
| 15 | 제조자는 다음과 같은 절차에 따라 의료기기 안전 등급을 정해야 한다. |
| 16 | |
| 17 | Figure: 소프트웨어 안전 등급 설정 프로세스[[BR]] |
| 18 | [[Image(software_safety_class_process.png)]] |
| 19 | [[BR]] |
| 20 | 출처: [IEC62304] |
| 21 | |
| 22 | 초기 소프트웨어 안전 등급이 B 또는 C로 분류된 경우, 제조자는 추가적인 위험 통제 조치를 소프트웨어 시스템 외부에 구현하고 (소프트웨어 시스템을 포함하는 소프트웨어 아키텍처 개정 포함) 추가적으로 새로운 소프트웨어 안전 등급을 설정한다. |
| 23 | |
| 24 | 제조자는 각 소프트웨어 시스템에 대한 소프트웨어 안전 등급을 위험 관리 파일에 명시해야 한다. |
| 25 | |
| 26 | == 5.4. 레거시 소프트웨어 == |
| 27 | 제조자는 레거시 소프트웨어를 사용하기 위해 다음과 같은 활동을 수행한다. |
| 28 | |
| 29 | === 5.4.1. 위험 관리 활동 === |
| 30 | 1. 레거시 소프트웨어에 대한 피드백을 평가한다. |
| 31 | 1. 다음과 같은 사항을 고려하여 레거시 소프트웨어를 계속 사용할 지 위험 관리 활동을 수행한다: |
| 32 | 1. 전반적인 의료기기 아키텍처에 레거시 소프트웨어의 통합 |
| 33 | 1. 레거시 소프트웨어의 일부로 구현된 위험 통제 조치의 지속적인 유효성 검증 |
| 34 | 1. 레거시 소프트웨어의 지속적인 사용과 관련된 위해상황 식별 |
| 35 | 1. 위해상황에 기여하는 레거시 소프트웨어의 잠재적 원인 식별 |
| 36 | 1. 위해상황에 기여하는 레거시 소프트웨어의 잠재적 원인에 대한 위험통제 조치 정의 |
| 37 | |
| 38 | === 5.4.2. 갭(격차) 분석 === |
| 39 | 1. 제조자는 활용가능한 산출물의 지속적인 유효성 검증을 평가해야 한다. |
| 40 | 1. 갭이 식별되면, 제조자는 누락된 산출물과 관련 활동들을 생성한 결과 위험의 잠재적 감소를 평가해야 한다. |
| 41 | 1. 이 평가에 따라, 제조자는 생성할 산출물과 관련된 활동들을 결정해야 한다. 최소한의 산출물은 소프트웨어 시스템 테스트 기록이어야 한다. |
| 42 | |
| 43 | === 5.4.3. 갭 종료 활동 === |
| 44 | 1. 제조자는 식별된 산출물을 생성하기 위한 계획을 수립하고 실행해야 한다. |
| 45 | 1. 이 계획은 레거시 소프트웨어와 산출물에서 발견된 문제를 처리하기 위한 문제 해결 프로세스를 사용해야 한다. |
| 46 | 1. 레거시 소프트웨어의 변경은 소프트웨어 유지보수 프로세스를 따라야 한다. |
| 47 | |
| 48 | === 5.4.4. 레거시 소프트웨어 사용근거 === |
| 49 | 제조자는 레거시 소프트웨어의 지속적인 사용에 대한 근본적인 이유와 함께 레거시 소프트웨어 버전을 문서화해야 한다. |
| 50 | |
| 51 | |
| 52 | == == |
| 53 | [.. 소프트웨어 개발 지침서 (Software Development Guideline)] |
| 54 | |