SDE

Software Development Guideline

1. 문서명 (Document Name)
   • 소프트웨어 개발 절차서 (Software Development Guideline)
2. 문서번호 (Document No.)
   • QM_SDG
3. 개정번호 (Revision No.)
   • 1
4. 개정날짜 (Release Date)
   • 2023.07.31
5. 작성자 (Author)
   • 이상림 (Sanglim LEE)
6. 검토자 (Reviewed)
7. 승인자 (Approved)

Revision History

1. 2023.07.31
   • 이상림 (Sanglim LEE)
   • 최초 개정 (Initial release)

1. Purpose

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

2. Scope

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

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

3. Reference

Acronym	Document
IEC14971	Medical devices – Application of risk management to medical devices
IEC62304	Medical device software – Software life cycle processes, 2015
MSDIC	Microsoft Computer Dictionary 5th ed., Microsoft Corporation, 2002.
RUP	Rational Unified Process: Best Practices for Software Development Teams
SCM

4. Definition

Terms and Definitions

5. 일반 요구사항 (General Requirements)?

5.1. 품질관리시스템

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

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

5.2. 위험관리

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

5.3. 소프트웨어 안전 등급

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

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

출처: [IEC62304]

초기 소프트웨어 안전 등급이 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: 위험관리 프로세스

출처: [ISO 14971]

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: 소프트웨어 개발 프로세스

출처: [RUP]

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.

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

10.2. WORKFLOW (워크플로우)

10.2.1. BUSINESS MODELING (비즈니스 모델링)

Business model describes product concept and business process to assure a common understanding among all stakeholders of what product is planned and what business process needs to supported in the organization.

비즈니스 모델은 조직에서 어떤 제품이 기획되고 어떤 비즈니스 프로세스가 지원될 필요가 있는지를 이해당사자 사이에 공통의 이해를 도모하기 위해 제품 컨셉과 비즈니스 프로세스를 기술한다.

The deliverable of business modeling workflow is a software development plan.

비즈니스 모델링의 산출물은 소프트웨어 개발 계획 문서이다.

10.2.2. REQUIREMENT (비즈니스 모델링)

The goal of the Requirements workflow is to describe what the system should do and allows the developers and the customer (product manager?) to agree on that description.

요구사항 워크플로우의 목표는 시스템이 무엇을 할 지를 기술하고, 개발자와 고객이 기술한 바에 대해 동의할 수 있게 하는 것이다.

The deliverable of requirements workflow is a risk management plan, a cyber security checklist and a software requirement specification.

요구사항 워크플로우의 산출물은 리스크 관리 계획 문서, 사이버 보안 점검표, 소프트웨어 요구사항 문서이다.

10.2.3. ANALYSIS AND DESIGN (분석 및 설계)

The goal of the Analysis and Design workflow is to show how the system will be realized in the implementation phase.

분석과 설계 워크플로우의 목표는 구현 워크플로우에서 시스템을 어떻게 실현시킬 지를 보는 것이다.

The deliverables of analysis and design workflow is a software architecture. 분석과 설계 워크플로우의 산출물은 소프트웨어 아키텍처이다.

10.2.4. IMPLEMENTATION (구현)

The purpose of implementation is:

• To define the organization of the code, in terms of implementation subsystems organized in layers.
• To implement classes and objects in terms of components (source files, binaries, executables, and others)
• To verify the developed components as units.
• To integrate the results produced by individual implementers (or team), into an executable system.

구현 워크플로우의 목적은 다음과 같다:

• 계층적으로 구조화된 서브시스템 구현의 관점에서 코드의 구성을 정의한다.
• (소스 파일, 바이너리 파일, 이진 파일 등등의) 구성요소의 관점에서 클래스와 객체를 구현한다.
• 개발된 구성요소를 소프트웨어 단위(software unit)로써 검증한다.
• 개별적인 구현자(또는 팀)에 의해 생산된 결과를 실행가능한 시스템으로 통합한다.

The deliverables of implementation workflow are detailed requirement specification, design specification, source code and software specification plan

구현 워크플로우의 산출물은 상세 요구사항 문서, 설계 문서, 소스 코드 및 소프트웨어 검증 계획 문서이다.

10.2.5. VERIFICATION & VALIDATION (검증)

The purpose of verification is:

• To verify the interaction between objects
• To verify the proper integration of all components of the software
• To verify that all requirements have been correctly implemented
• To identify and ensure defects are addressed prior to the deployment of the software

검증의 목적은 다음과 같다:

• 객체간 인터랙션(상호작용)을 검증한다.
• 소프트웨어의 모든 구성요소가 적절하게 통합되었는지를 검증한다.
• 모든 요구사항이 올바르게 구현되어 있는지를 검증한다.
• 소프트웨어를 배포하기 전에 결함을 식별하고 해결한다.

The deliverables of verification workflow are software verification reports, risk management report and software validation report.

검증 워크플로우의 산출물은 software verification reports와 risk management report 및 software validation report이다.

10.2.6. DEPLOYMENT (배포)

The purpose of the deployment workflow is to successfully produce product releases, and deliver the software to its end users.

배포 워크플로의 목적은 제품을 성공적으로 출시해서 최종 사용자에게 소프트웨어를 전달하는 것이다.

The deliverables of the deployment workflow are installable software, and release note.

배포 워크플로우의 산출물은 설치가능한 소프트웨어와 릴리즈 노트이다.

10.2.7. PROJECT MANAGEMENT (프로젝트 관리)

Software Project Management is the art of balancing competing objectives, managing risk, and overcoming constraints to deliver, successfully, a product in which meets the needs of customers and the users.

소프트웨어 프로젝트 경쟁하는 목표들을 조율하고, 리스크를 관리하고 제약사항을 극복하여 성공적으로 고객과 사용자의 필요를 충족시키는 제품을 전달하는 행위이다.

The deliverables of project management workflow are Software development plan and project meeting minutes.

프로젝트 관리의 산출물은 소프트웨어 개발 계획 문서와 프로젝트 회의록이다.

10.2.8. CONFIGURATION AND CHANGE REQUEST MANAGEMENT

The purpose of the configuration and change request management workflow is to trace why, when, and by whom any deliverable was changed.

형상관리와 변경요청 관리 워크플로우의 목적은 이유, 시기 그리고 누구에 의해 산출물이 변경되었는지를 추적하는 것이다.

The deliverables of the configuration and change request management workflow are configuration items and change requests.

형상관리와 변경요청 관리 워크플로우의 산출물은 형상관리 아이템들과 변경요청 사항들이다.

Change request management workflow are activities for the problem resolve management process.

변경 요청 관리 워크플로우는 문제 해결 관리 프로세스를 위한 활동이다.

10.2.9. ENVIRONMENT (개발환경)

The purpose of the environment workflow is to provide the software development organization with the software development environment – both processes and tools – that are needed to support the development team.

환경 워크플로우의 목적은 소프트웨어 팀을 지원하기 위해 필요한 소프트웨어 개발 환경(프로세스와 도구)을 소프트웨어 개발 조직에게 제공하는 것이다.

The deliverable of the environment workflow is a software development plan for a project.

환경 워크플로우의 산출물은 소프트웨어 개발 계획 문서이다.

10.3. 산출물

The process recommends software development documents (or deliverables) depending on Phase like as: 소프트웨어 개발 프로세스는 프로젝트 단계별로 다음과 같은 소프트웨어 개발 문서 (또는 산출물) 권장한다:

Figure: 문서 구조

11. 소프트웨어 형상관리

11.1. 소프트웨어 형상관리 도구

소프트웨어 형상 관리 도구를 사용해야 한다.

11.2. 소프트웨어 버전

소프트웨어 버전 형식은 다음과 같다:

• major.minor.patch.build

위에서,

• major는 주요한 기능이 추가되었을 때 증가시킨다.
• minor는 기능이 개선되거나 단순한 기능이 추가되었을 때 증가시킨다.
• patch는 출시된 버전의 오류를 해결했을 때 증가시킨다.
• build는 전체 integration build를 할 때마다 증가시킨다.

11.3. 소프트웨어 버전 트리

소프트웨어 버전은 다음과 같이 관리한다: Figure: 소프트웨어 버전 트리

출처: []

위에서,

• Tagging은 버전을 포함해야 하며, 전체 integration build가 성공하면, build 번호를 증가시켜야 한다.
• Branching은 configuration item을 다르게 유지해야(evolving) 할 경우에 추가한다.
• Commit을 할 경우에는 CR 번호 및 타이틀을 포함해야 한다.

12. 소프트웨어 변경 및 문제 해결 관리

12.1. 소프트웨어 변경 및 문제 해결 관리 도구

소프트웨어 변경 및 문제 해결 관리 도구를 사용해야 한다.

12.2. 소프트웨어 변경 및 문제 해결 절차

Figure: 소프트웨어 변경 및 문제 해결 절차

CR을 등록할 경우 Reporter는 다음 사항을 명시한다:

• 시스템 버전
• 변경 요청 사항 요약 (title)
• 변경 요청 사항 상세 내용. 가능하면, 재발생 스텝을 포함한다.

13. 소프트웨어 개발 환경

13.1. 소프트웨어 개발 도구

각 프로젝트는 소프트웨어 빌드를 포함하여 개발 도구 명시한다.

13.2. 소프트웨어 통합

매일 빌드를 수행할 경우, Daily integration을 수행하며, 프로세스는 다음과 같다:

13.3. 소프트웨어 설치 파일

프로젝트는 소프트웨어 설치 파일을 이용하여 소프트웨어를 배포한다. (OS 이미지 제외)

13.4. 서버 URL

각 프로젝트는 사용하는 서버에 대해 URL을 포함한 정보를 명시한다.

SDE