| 69 | | == 6. 소프트웨어 개발 계획 == |
| 70 | | 제조자는 개발할 소프트웨어 안전 등급과 범위, 규모에 적합한 소프트웨어 개발 프로세스 활동을 수행하기 위한 소프트웨어 개발 계획을 수립해야 한다. |
| 71 | | |
| 72 | | 제조자는 개발 진행에 맞춰 다음과 같은 내용을 업데이트해야 한다. |
| 73 | | 1. 프로젝트 개요 |
| 74 | | 1. 참여자 및 책임과 권한 |
| 75 | | 1. 위험 관리 |
| 76 | | 1. 사이버보안 |
| 77 | | 1. 사용적합성 |
| 78 | | 1. 소프트웨어 개발 프로세스 (시스템 통합, 검증 및 밸리데이션 포함) |
| 79 | | 1. 소프트웨어 개발 문서 (추적성 포함) |
| 80 | | 1. 소프트웨어 개발 일정 (마일스톤 포함) |
| 81 | | 1. 소프트웨어 형상 관리 (SOUP 형상관리 아이템 및 개발 지원 소프트웨어 포함) |
| 82 | | 1. 소프트웨어 변경 관리 (SOUP 형상관리 아이템 및 개발 지원 소프트웨어 포함) |
| 83 | | 1. 소프트웨어 문제 해결 관리 |
| 84 | | 1. 소프트웨어 개발 환경 |
| 85 | | 1. 소프트웨어 개발 표준, 방법, 도구 포함 |
| 86 | | 1. 일반적인 소프트웨어 결함의 식별 및 회피 방법과 근거 |
| 87 | | |
| 88 | | == 7. 소프트웨어 위험 관리 == |
| 89 | | 의료기기 소프트웨어 개발 플랫폼은 기본적으로 ISO 14971에 따라 위험관리를 수행해야 한다. |
| 90 | | |
| 91 | | Figure: 위험관리 프로세스 [[BR]] |
| 92 | | [[Image(risk_management_process.png)]] |
| 93 | | [[BR]] |
| 94 | | 출처: [ISO 14971] |
| 95 | | |
| 96 | | === 7.1. 위험분석 === |
| 97 | | 위에서, 소프트웨어는 위해 또는 위해상황을 식별해야 하며, 다음가 같은 상황을 고려해야 한다: |
| 98 | | 1. 소프트웨어 요구사항 사양의 불완전 또는 부정확 |
| 99 | | 1. 소프트웨어 아이템의 기능상 결함 |
| 100 | | 1. SOUP에 의한 의도되지 않은 결과 또는 실패 |
| 101 | | 1. 소프트웨어의 예상하지 못한 동작의 결과로 인해 발생하는 하드웨어의 고장 |
| 102 | | 1. 타당하게 예상할 수 있는 잘못된 사용 |
| 103 | | |
| 104 | | 예상하지 못한 SOUP의 오류에 의해 소프트웨어 아이템에 잠재적 위해가 발생할 수 있을 경우, 최소한 SOUP공급자가 배포한 이상상황목록에 대해서는 발생할 수 있는 위해상황을 평가해야 한다. |
| 105 | | |
| 106 | | 소프트웨어 아이템과 관련된 위해상황은 위험관리 파일에 문서화한다. 식별된 위해상황에 의해 발생할 수 있는 이벤트에 대해 위험관리 파일에 문서화한다. |
| 107 | | |
| 108 | | === 7.2. 위험평가 === |
| 109 | | 1. 소프트웨어의 경우 발생가능성은 100%로 추정한다. |
| 110 | | 1. 소프트웨어 제품의 심각성 기준은 다음과 같다: |
| 111 | | |
| 112 | | ||= Level =||= Severity =||= Description =|| |
| 113 | | || 5 || Catastrophic || 환자의 사망을 발생하는 수준 || |
| 114 | | || 4 || Critical || 영구적 손상 또는 치명적 상해를 발생하는 수준 || |
| 115 | | || 3 || Serious || 전문적 의료시술이 필요한 상해 또는 손상을 발생하는 수준 || |
| 116 | | || 2 || Minor || 전문적 의료시술이 필요 없는 일시적인 상해나 손상을 발생하는 수준 || |
| 117 | | || 1 || Negligible || 불편 또는 일시적 곤란을 발생하는 수준 || |
| 118 | | |
| 119 | | 1. 위험 계산 방법: [[BR]] |
| 120 | | 위험 수준 (Risk Level) = 발생가능성 정도(Probability rating) x 심각성 정도(Severity rating) |
| 121 | | 1. 위험 허용 기준 |
| 122 | | 1. 허용 가능한 위험 수준 (AR, Acceptable Risk) = 1, 2 |
| 123 | | 1. 허용할 수 없는 위험 수준 (UR, Unacceptable Risk) = 3, 4, 5 |
| 124 | | |
| 125 | | === 7.3. 위험통제 === |
| 126 | | 제조자는 위험통제수단을 정의하고 문서화해야 한다. 위험통제수단이 소프트웨어의 기능 일부로 구현된 경우 다음과 같이 수행해야 한다: |
| 127 | | 1. 소프트웨어 요구사항에 위험통제수단을 포함시킨다. |
| 128 | | 1. 위험통제수단으로 제어하고 있는 위험에 근거하여, 위험통제수단의 구현에 기여하는 각 소프트웨어 항목에 소프트웨어 안전등급을 배정한다. |
| 129 | | |
| 130 | | === 7.4. 위험통제수단의 검증 === |
| 131 | | 문서화된 각 위험통제수단의 구현은 검증되어야 하며, 검증 결과를 문서화한다. 제조자는 위험통제수단을 검토하고, 위험통제수단이 새로운 위험상황을 초래할 수 있는지 확인하여야 한다. |
| 132 | | |
| 133 | | 제조자는 또한 다음과 같은 추적성 명시해야 한다: |
| 134 | | 1. 위해상황에서 소프트웨어 항목까지 |
| 135 | | 1. 소프트웨어 항목에서 특정 소프트웨어 원인까지 |
| 136 | | 1. 소프트웨어 원인에서 위험통제수단까지 |
| 137 | | 1. 위험통제수단에서 위험통제수단 검증까지 |
| 138 | | |
| 139 | | === 7.5. 소프트웨어 변경의 위험 관리 === |
| 140 | | 제조자는 SOUP를 포함하여 의료기기 소프트웨어에 대한 변경을 분석해야 한다: |
| 141 | | 1. 추가적인 잠재적 원인이 위해상황에서 발생할 수 있는지 |
| 142 | | 1. 추가적인 위험통제수단이 필요한지 |
| 143 | | |
| 144 | | == 8. 사이버보안 == |
| 145 | | 식품의약품안전평가원의 의료기기 사이버보안 허가심사 가이드라인 (민원인 안내서)를 따른다. |
| 146 | | |
| 147 | | == 9. 사용적합성 == |
| 148 | | TBD |
| 149 | | |
| 150 | | == 10. 소프트웨어 개발 프로세스 == |
| 151 | | 소프트웨어 개발 프로세스는 Rational Unified Process를 기반으로 삼는다. |
| 152 | | |
| 153 | | Figure: 소프트웨어 개발 프로세스[[BR]] |
| 154 | | [[Image(rational_unified_process.png)]] |
| 155 | | [[BR]] |
| 156 | | 출처: [RUP] |
| 157 | | |
| 158 | | 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. |
| 159 | | |
| 160 | | 프로세스는 두 개의 차원으로 설명할 수 있다. 수평 축은 단계, 반복, 마일스톤으로 표현되는 시간을 나타내며, 수평 축은 워크플로우를 나타낸다. 워크플로우는 관측 가능한 값으로 결과를 생성하는 일련의 활동이다. |
| 161 | | |
| 162 | | === 10.1. PHASES === |
| 163 | | |
| 164 | | ==== 10.1.1. INCEPTION PHASES (도입 단계) ==== |
| 165 | | During the inception phase, product concepts are defined. |
| 166 | | |
| 167 | | 도입 단계에서는 제품 컨셉을 정의한다. |
| 168 | | |
| 169 | | ==== 10.1.2. ELABORATION PHASE (정교화 단계) ==== |
| 170 | | 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. |
| 171 | | |
| 172 | | 정교화 단계의 목적은 문제 영역을 분석하고 튼튼한 구조 기반을 구축하고, 프로젝트 계획을 개발하고, 프로젝트의 가장 큰 리스크 요소를 제거하는 것이다. |
| 173 | | |
| 174 | | ==== 10.1.3. CONSTRUCTION PHASE (구축 단계) ==== |
| 175 | | During the construction phase, all remaining components and application features are developed and integrated into the product, and all features are thoroughly verified. |
| 176 | | |
| 177 | | 구축 단계에서는 모든 구성요소와 어플리케이션 기능을 개발하고 제품에 통합하며, 모든 기능을 철저하게 검증한다. |
| 178 | | |
| 179 | | ==== 10.1.3. TRANSITION PHASE (이관 단계) ==== |
| 180 | | The purpose of the transition phase is to transition the software product to a user outside of project team. |
| 181 | | |
| 182 | | 이관 단계의 목적은 소프트웨어 제품을 프로젝트 팀 외부의 사용자에게 이관하는 것이다. |
| 183 | | |
| 184 | | === 10.2. WORKFLOW (워크플로우) === |
| 185 | | |
| 186 | | ==== 10.2.1. BUSINESS MODELING (비즈니스 모델링) ==== |
| 187 | | 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. |
| 188 | | |
| 189 | | 비즈니스 모델은 조직에서 어떤 제품이 기획되고 어떤 비즈니스 프로세스가 지원될 필요가 있는지를 이해당사자 사이에 공통의 이해를 도모하기 위해 제품 컨셉과 비즈니스 프로세스를 기술한다. |
| 190 | | |
| 191 | | The deliverable of business modeling workflow is a software development plan. |
| 192 | | |
| 193 | | 비즈니스 모델링의 산출물은 소프트웨어 개발 계획 문서이다. |
| 194 | | |
| 195 | | ==== 10.2.2. REQUIREMENT (비즈니스 모델링) ==== |
| 196 | | 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. |
| 197 | | |
| 198 | | 요구사항 워크플로우의 목표는 시스템이 무엇을 할 지를 기술하고, 개발자와 고객이 기술한 바에 대해 동의할 수 있게 하는 것이다. |
| 199 | | |
| 200 | | The deliverable of requirements workflow is a risk management plan, a cyber security checklist and a software requirement specification. |
| 201 | | |
| 202 | | 요구사항 워크플로우의 산출물은 리스크 관리 계획 문서, 사이버 보안 점검표, 소프트웨어 요구사항 문서이다. |
| 203 | | |
| 204 | | ==== 10.2.3. ANALYSIS AND DESIGN (분석 및 설계) ==== |
| 205 | | The goal of the Analysis and Design workflow is to show how the system will be realized in the implementation phase. |
| 206 | | |
| 207 | | 분석과 설계 워크플로우의 목표는 구현 워크플로우에서 시스템을 어떻게 실현시킬 지를 보는 것이다. |
| 208 | | |
| 209 | | The deliverables of analysis and design workflow is a software architecture. |
| 210 | | 분석과 설계 워크플로우의 산출물은 소프트웨어 아키텍처이다. |
| 211 | | |
| 212 | | ==== 10.2.4. IMPLEMENTATION (구현) ==== |
| 213 | | The purpose of implementation is: |
| 214 | | - To define the organization of the code, in terms of implementation subsystems organized in layers. |
| 215 | | - To implement classes and objects in terms of components (source files, binaries, executables, and others) |
| 216 | | - To verify the developed components as units. |
| 217 | | - To integrate the results produced by individual implementers (or team), into an executable system. |
| 218 | | |
| 219 | | 구현 워크플로우의 목적은 다음과 같다: |
| 220 | | - 계층적으로 구조화된 서브시스템 구현의 관점에서 코드의 구성을 정의한다. |
| 221 | | - (소스 파일, 바이너리 파일, 이진 파일 등등의) 구성요소의 관점에서 클래스와 객체를 구현한다. |
| 222 | | - 개발된 구성요소를 소프트웨어 단위(software unit)로써 검증한다. |
| 223 | | - 개별적인 구현자(또는 팀)에 의해 생산된 결과를 실행가능한 시스템으로 통합한다. |
| 224 | | |
| 225 | | The deliverables of implementation workflow are detailed requirement specification, design specification, source code and software specification plan |
| 226 | | |
| 227 | | 구현 워크플로우의 산출물은 상세 요구사항 문서, 설계 문서, 소스 코드 및 소프트웨어 검증 계획 문서이다. |
| 228 | | |
| 229 | | ==== 10.2.5. VERIFICATION & VALIDATION (검증) ==== |
| 230 | | The purpose of verification is: |
| 231 | | - To verify the interaction between objects |
| 232 | | - To verify the proper integration of all components of the software |
| 233 | | - To verify that all requirements have been correctly implemented |
| 234 | | - To identify and ensure defects are addressed prior to the deployment of the software |
| 235 | | |
| 236 | | 검증의 목적은 다음과 같다: |
| 237 | | - 객체간 인터랙션(상호작용)을 검증한다. |
| 238 | | - 소프트웨어의 모든 구성요소가 적절하게 통합되었는지를 검증한다. |
| 239 | | - 모든 요구사항이 올바르게 구현되어 있는지를 검증한다. |
| 240 | | - 소프트웨어를 배포하기 전에 결함을 식별하고 해결한다. |
| 241 | | |
| 242 | | The deliverables of verification workflow are software verification reports, risk management report and software validation report. |
| 243 | | |
| 244 | | 검증 워크플로우의 산출물은 software verification reports와 risk management report 및 software validation report이다. |
| 245 | | |
| 246 | | ==== 10.2.6. DEPLOYMENT (배포) ==== |
| 247 | | The purpose of the deployment workflow is to successfully produce product releases, and deliver the software to its end users. |
| 248 | | |
| 249 | | 배포 워크플로의 목적은 제품을 성공적으로 출시해서 최종 사용자에게 소프트웨어를 전달하는 것이다. |
| 250 | | |
| 251 | | The deliverables of the deployment workflow are installable software, and release note. |
| 252 | | |
| 253 | | 배포 워크플로우의 산출물은 설치가능한 소프트웨어와 릴리즈 노트이다. |
| 254 | | |
| 255 | | ==== 10.2.7. PROJECT MANAGEMENT (프로젝트 관리) ==== |
| 256 | | 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. |
| 257 | | |
| 258 | | 소프트웨어 프로젝트 경쟁하는 목표들을 조율하고, 리스크를 관리하고 제약사항을 극복하여 성공적으로 고객과 사용자의 필요를 충족시키는 제품을 전달하는 행위이다. |
| 259 | | |
| 260 | | The deliverables of project management workflow are Software development plan and project meeting minutes. |
| 261 | | |
| 262 | | 프로젝트 관리의 산출물은 소프트웨어 개발 계획 문서와 프로젝트 회의록이다. |
| 263 | | |
| 264 | | ==== 10.2.8. CONFIGURATION AND CHANGE REQUEST MANAGEMENT ==== |
| 265 | | The purpose of the configuration and change request management workflow is to trace why, when, and by whom any deliverable was changed. |
| 266 | | |
| 267 | | 형상관리와 변경요청 관리 워크플로우의 목적은 이유, 시기 그리고 누구에 의해 산출물이 변경되었는지를 추적하는 것이다. |
| 268 | | |
| 269 | | The deliverables of the configuration and change request management workflow are configuration items and change requests. |
| 270 | | |
| 271 | | 형상관리와 변경요청 관리 워크플로우의 산출물은 형상관리 아이템들과 변경요청 사항들이다. |
| 272 | | |
| 273 | | Change request management workflow are activities for the problem resolve management process. |
| 274 | | |
| 275 | | 변경 요청 관리 워크플로우는 문제 해결 관리 프로세스를 위한 활동이다. |
| 276 | | |
| 277 | | ==== 10.2.9. ENVIRONMENT (개발환경) ==== |
| 278 | | 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. |
| 279 | | |
| 280 | | 환경 워크플로우의 목적은 소프트웨어 팀을 지원하기 위해 필요한 소프트웨어 개발 환경(프로세스와 도구)을 소프트웨어 개발 조직에게 제공하는 것이다. |
| 281 | | |
| 282 | | The deliverable of the environment workflow is a software development plan for a project. |
| 283 | | |
| 284 | | 환경 워크플로우의 산출물은 소프트웨어 개발 계획 문서이다. |
| 285 | | |
| 286 | | === 10.3. 산출물 === |
| 287 | | The process recommends software development documents (or deliverables) depending on Phase like as: |
| 288 | | 소프트웨어 개발 프로세스는 프로젝트 단계별로 다음과 같은 소프트웨어 개발 문서 (또는 산출물) 권장한다:[[BR]] |
| 289 | | |
| 290 | | Figure: 문서 구조[[BR]] |
| 291 | | [[Image(document_tree.png)]] |
| 292 | | [[BR]] |
| 293 | | |
| 294 | | == 11. 소프트웨어 형상관리 == |
| 295 | | |
| 296 | | === 11.1. 소프트웨어 형상관리 도구 === |
| 297 | | 소프트웨어 형상 관리 도구를 사용해야 한다. |
| 298 | | |
| 299 | | === 11.2. 소프트웨어 버전 === |
| 300 | | 소프트웨어 버전 형식은 다음과 같다: |
| 301 | | - major.minor.patch.build |
| 302 | | |
| 303 | | 위에서, |
| 304 | | - major는 주요한 기능이 추가되었을 때 증가시킨다. |
| 305 | | - minor는 기능이 개선되거나 단순한 기능이 추가되었을 때 증가시킨다. |
| 306 | | - patch는 출시된 버전의 오류를 해결했을 때 증가시킨다. |
| 307 | | - build는 전체 integration build를 할 때마다 증가시킨다. |
| 308 | | |
| 309 | | === 11.3. 소프트웨어 버전 트리 === |
| 310 | | 소프트웨어 버전은 다음과 같이 관리한다: |
| 311 | | Figure: 소프트웨어 버전 트리[[BR]] |
| 312 | | [[Image(software_version_tree.png)]] |
| 313 | | [[BR]] |
| 314 | | 출처: [] |
| 315 | | |
| 316 | | 위에서, |
| 317 | | - Tagging은 버전을 포함해야 하며, 전체 integration build가 성공하면, build 번호를 증가시켜야 한다. |
| 318 | | - Branching은 configuration item을 다르게 유지해야(evolving) 할 경우에 추가한다. |
| 319 | | - Commit을 할 경우에는 CR 번호 및 타이틀을 포함해야 한다. |
| 320 | | |
| 321 | | == 12. 소프트웨어 변경 및 문제 해결 관리 == |
| 322 | | |
| 323 | | === 12.1. 소프트웨어 변경 및 문제 해결 관리 도구 === |
| 324 | | 소프트웨어 변경 및 문제 해결 관리 도구를 사용해야 한다. |
| 325 | | |
| 326 | | === 12.2. 소프트웨어 변경 및 문제 해결 절차 === |
| 327 | | |
| 328 | | Figure: 소프트웨어 변경 및 문제 해결 절차 [[BR]] |
| 329 | | [[Image(change_request_process.png)]] |
| 330 | | [[BR]] |
| 331 | | |
| 332 | | CR을 등록할 경우 Reporter는 다음 사항을 명시한다: |
| 333 | | - 시스템 버전 |
| 334 | | - 변경 요청 사항 요약 (title) |
| 335 | | - 변경 요청 사항 상세 내용. 가능하면, 재발생 스텝을 포함한다. |
| 336 | | |
| 337 | | == 13. 소프트웨어 개발 환경 == |
| 338 | | |
| 339 | | === 13.1. 소프트웨어 개발 도구 === |
| 340 | | 각 프로젝트는 소프트웨어 빌드를 포함하여 개발 도구 명시한다. |
| 341 | | |
| 342 | | === 13.2. 소프트웨어 통합 === |
| 343 | | 매일 빌드를 수행할 경우, Daily integration을 수행하며, 프로세스는 다음과 같다: |
| 344 | | |
| 345 | | === 13.3. 소프트웨어 설치 파일 === |
| 346 | | 프로젝트는 소프트웨어 설치 파일을 이용하여 소프트웨어를 배포한다. (OS 이미지 제외) |
| 347 | | |
| 348 | | === 13.4. 서버 URL === |
| 349 | | 각 프로젝트는 사용하는 서버에 대해 URL을 포함한 정보를 명시한다. |
