wiki:SDG

Version 5 (modified by admin, 20 months ago) (diff)

--

SDE

Software Development Guideline

Document Name Software Development Guideline (소프트웨어 개발 절차서)
Document No. QM-SDG
Revision No. 1
Release Date 2023.07.31
Company Name GIRJAESOFT Co., Ltd.
Author Sanglim LEE
Reviewed
Approved

Revision History

Revision No. Date Changes Author
1 2023.07.31 First release Sanglim LEE

1. Purpose

본 문서는 의료기기 소프트웨어 프로젝트를 진행할 때 준수해야 할 절차에 대해 기술한다. 만약 개별 프로젝트에서 본 문서에서 기술된 바와 다른 절차를 적용할 경우, 소프트웨어 개발 계획서에 별도로 명시한다.

2. Scope

본 문서는 소프트웨어 개발자가 이해할 수 있는 수준에서 작성되며, 본 문서에서 다루는 기술적 범위는 다음과 같다:

  1. 일반 요구사항
  2. 소프트웨어 개발 계획
  3. 소프트웨어 위험 관리
  4. 사이버 보안
  5. 사용적합성
  6. 소프트웨어 개발 프로세스
  7. 소프트웨어 형상관리
  8. 소프트웨어 변경 및 문제해결 관리
  9. 소프트웨어 개발 환경

3. Reference

AcronymDocument
IEC14971 Medical devices – Application of risk management to medical devices
IEC62304 Medical device software – Software life cycle processes
MSDIC Microsoft Computer Dictionary 5th ed., Microsoft Corporation, 2002.

4. Definition

5. 일반 요구사항

5.1. 품질관리시스템

제조자는 다음 중 하나 이상의 품질관리시스템을 확보해야 한다:

  1. ISO 13485
  2. 국가 품질관리시스템 표준
  3. 국가 품질관리시스템 인정서 (예, KGMP)

5.2. 위험관리

본 문서의 7. 소프트웨어 위험 관리를 따른다.

5.3. 소프트웨어 안전 등급

제조자는 다음과 같은 절차에 따라 의료기기 안전 등급을 정해야 한다.

Figure: 소프트웨어 안전 등급 설정 프로세스

초기 소프트웨어 안전 등급이 B 또는 C로 분류된 경우, 제조자는 추가적인 위험 통제 조치를 소프트웨어 시스템 외부에 구현하고 (소프트웨어 시스템을 포함하는 소프트웨어 아키텍처 개정 포함) 추가적으로 새로운 소프트웨어 안전 등급을 설정한다.

제조자는 각 소프트웨어 시스템에 대한 소프트웨어 안전 등급을 위험 관리 파일에 명시해야 한다.

5.4. 레거시 소프트웨어

제조자는 레거시 소프트웨어를 사용하기 위해 다음과 같은 활동을 수행한다.

5.4.1. 위험 관리 활동

  1. 레거시 소프트웨어에 대한 피드백을 평가한다.
  2. 다음과 같은 사항을 고려하여 레거시 소프트웨어를 계속 사용할 지 위험 관리 활동을 수행한다:
    1. 전반적인 의료기기 아키텍처에 레거시 소프트웨어의 통합
    2. 레거시 소프트웨어의 일부로 구현된 위험 통제 조치의 지속적인 유효성 검증
    3. 레거시 소프트웨어의 지속적인 사용과 관련된 위해상황 식별
    4. 위해상황에 기여하는 레거시 소프트웨어의 잠재적 원인 식별
    5. 위해상황에 기여하는 레거시 소프트웨어의 잠재적 원인에 대한 위험통제 조치 정의

5.4.2. 갭(격차) 분석

  1. 제조자는 활용가능한 산출물의 지속적인 유효성 검증을 평가해야 한다.
  2. 갭이 식별되면, 제조자는 누락된 산출물과 관련 활동들을 생성한 결과 위험의 잠재적 감소를 평가해야 한다.
  3. 이 평가에 따라, 제조자는 생성할 산출물과 관련된 활동들을 결정해야 한다. 최소한의 산출물은 소프트웨어 시스템 테스트 기록이어야 한다.

5.4.3. 갭 종료 활동

  1. 제조자는 식별된 산출물을 생성하기 위한 계획을 수립하고 실행해야 한다.
  2. 이 계획은 레거시 소프트웨어와 산출물에서 발견된 문제를 처리하기 위한 문제 해결 프로세스를 사용해야 한다.
  3. 레거시 소프트웨어의 변경은 소프트웨어 유지보수 프로세스를 따라야 한다.

5.4.4. 레거시 소프트웨어 사용근거

제조자는 레거시 소프트웨어의 지속적인 사용에 대한 근본적인 이유와 함께 레거시 소프트웨어 버전을 문서화해야 한다.

6. 소프트웨어 개발 계획

제조자는 개발할 소프트웨어 안전 등급과 범위, 규모에 적합한 소프트웨어 개발 프로세스 활동을 수행하기 위한 소프트웨어 개발 계획을 수립해야 한다.

제조자는 개발 진행에 맞춰 다음과 같은 내용을 업데이트해야 한다.

  1. 프로젝트 개요
  2. 참여자 및 책임과 권한
  3. 위험 관리
  4. 사이버보안
  5. 사용적합성
  6. 소프트웨어 개발 프로세스 (시스템 통합, 검증 및 밸리데이션 포함)
  7. 소프트웨어 개발 문서 (추적성 포함)
  8. 소프트웨어 개발 일정 (마일스톤 포함)
  9. 소프트웨어 형상 관리 (SOUP 형상관리 아이템 및 개발 지원 소프트웨어 포함)
  10. 소프트웨어 변경 관리 (SOUP 형상관리 아이템 및 개발 지원 소프트웨어 포함)
  11. 소프트웨어 문제 해결 관리
  12. 소프트웨어 개발 환경
    1. 소프트웨어 개발 표준, 방법, 도구 포함
    2. 일반적인 소프트웨어 결함의 식별 및 회피 방법과 근거

7. 소프트웨어 위험 관리

의료기기 소프트웨어 개발 플랫폼은 기본적으로 ISO 14971에 따라 위험관리를 수행해야 한다.

Figure: 위험관리 프로세스

7.1. 위험분석

위에서, 소프트웨어는 위해 또는 위해상황을 식별해야 하며, 다음가 같은 상황을 고려해야 한다:

  1. 소프트웨어 요구사항 사양의 불완전 또는 부정확
  2. 소프트웨어 아이템의 기능상 결함
  3. SOUP에 의한 의도되지 않은 결과 또는 실패
  4. 소프트웨어의 예상하지 못한 동작의 결과로 인해 발생하는 하드웨어의 고장
  5. 타당하게 예상할 수 있는 잘못된 사용

예상하지 못한 SOUP의 오류에 의해 소프트웨어 아이템에 잠재적 위해가 발생할 수 있을 경우, 최소한 SOUP공급자가 배포한 이상상황목록에 대해서는 발생할 수 있는 위해상황을 평가해야 한다.

소프트웨어 아이템과 관련된 위해상황은 위험관리 파일에 문서화한다. 식별된 위해상황에 의해 발생할 수 있는 이벤트에 대해 위험관리 파일에 문서화한다.

7.2. 위험평가

  1. 소프트웨어의 경우 발생가능성은 100%로 추정한다.
  2. 소프트웨어 제품의 심각성 기준은 다음과 같다:
Level Severity Description
5 Catastrophic 환자의 사망을 발생하는 수준
4 Critical 영구적 손상 또는 치명적 상해를 발생하는 수준
3 Serious 전문적 의료시술이 필요한 상해 또는 손상을 발생하는 수준
2 Minor 전문적 의료시술이 필요 없는 일시적인 상해나 손상을 발생하는 수준
1 Negligible 불편 또는 일시적 곤란을 발생하는 수준
  1. 위험 계산 방법:
    위험 수준 (Risk Level) = 발생가능성 정도(Probability rating) x 심각성 정도(Severity rating)
  2. 위험 허용 기준
    1. 허용 가능한 위험 수준 (AR, Acceptable Risk) = 1, 2
    2. 허용할 수 없는 위험 수준 (UR, Unacceptable Risk) = 3, 4, 5

7.3. 위험통제

제조자는 위험통제수단을 정의하고 문서화해야 한다. 위험통제수단이 소프트웨어의 기능 일부로 구현된 경우 다음과 같이 수행해야 한다:

  1. 소프트웨어 요구사항에 위험통제수단을 포함시킨다.
  2. 위험통제수단으로 제어하고 있는 위험에 근거하여, 위험통제수단의 구현에 기여하는 각 소프트웨어 항목에 소프트웨어 안전등급을 배정한다.

7.4. 위험통제수단의 검증

문서화된 각 위험통제수단의 구현은 검증되어야 하며, 검증 결과를 문서화한다. 제조자는 위험통제수단을 검토하고, 위험통제수단이 새로운 위험상황을 초래할 수 있는지 확인하여야 한다.

제조자는 또한 다음과 같은 추적성 명시해야 한다:

  1. 위해상황에서 소프트웨어 항목까지
  2. 소프트웨어 항목에서 특정 소프트웨어 원인까지
  3. 소프트웨어 원인에서 위험통제수단까지
  4. 위험통제수단에서 위험통제수단 검증까지

7.5. 소프트웨어 변경의 위험 관리

제조자는 SOUP를 포함하여 의료기기 소프트웨어에 대한 변경을 분석해야 한다:

  1. 추가적인 잠재적 원인이 위해상황에서 발생할 수 있는지
  2. 추가적인 위험통제수단이 필요한지

8. 사이버보안

식품의약품안전평가원의 의료기기 사이버보안 허가심사 가이드라인 (민원인 안내서)를 따른다.

9. 사용적합성

TBD

10. 소프트웨어 개발 프로세스

소프트웨어 개발 프로세스는 Rational Unified Process를 기반으로 삼는다.

Figure: 소프트웨어 개발 프로세스

The process can be described in two dimensions – the horizontal axis represents time expressed in phases, iterations, and milestones. The vertical axis represents workflows. A workflow is a sequence of activities that produces a result of observable value.

프로세스는 두 개의 차원으로 설명할 수 있다. 수평 축은 단계, 반복, 마일스톤으로 표현되는 시간을 나타내며, 수평 축은 워크플로우를 나타낸다. 워크플로우는 관측 가능한 값으로 결과를 생성하는 일련의 활동이다.

10.1. PHASES

10.1.1. INCEPTION PHASES (도입 단계)

During the inception phase, product concepts are defined.

도입 단계에서는 제품 컨셉을 정의한다.

10.1.2. ELABORATION PHASE (정교화 단계)

The purpose of the elaboration phase is to analyze the problem domain, establish a sound architectural foundation, develop the project plan, and eliminate the highest risk elements of the projects.

정교화 단계의 목적은 문제 영역을 분석하고 튼튼한 구조 기반을 구축하고, 프로젝트 계획을 개발하고, 프로젝트의 가장 큰 리스크 요소를 제거하는 것이다.

10.1.3. CONSTRUCTION PHASE (구축 단계)

During the construction phase, all remaining components and application features are developed and integrated into the product, and all features are thoroughly verified.

구축 단계에서는 모든 구성요소와 어플리케이션 기능을 개발하고 제품에 통합하며, 모든 기능을 철저하게 검증한다.

10.1.3. TRANSITION PHASE (이관 단계)

The purpose of the transition phase is to transition the software product to a user outside of project team.

이관 단계의 목적은 소프트웨어 제품을 프로젝트 팀 외부의 사용자에게 이관하는 것이다.

SDE