swtest
IEC 62304 의료기기 소프트웨어 표준 수업 노트
by Kitle · 2018. 04. 11.
일시 2018. 04. 11.
IEC 62304 의료기기 소프트웨어 표준 수업 요약 노트
전통적 - Verification& Validation 이란?
Verification - Spec대로 되었느냐
Validation - Spec이 올바르게 되었느냐 - 사용자 만족 관점인 밸리데이션이 더 중요하다.
> 사실상 현재까지도 두개를 명확히 구분하여 하기 어렵다.
Fault Detection & removing
> 테스팅 기술로 커버 : 본질적으로 시스템에 오류가 없다는 것을 개런티 할 수 없다.
Dependable Processes 프로세스란
Dependable Processes는 테스팅 기술의 한계를 벗어나기 위해 하는 방법이다. 즉 제품을 만드는 과정이 좋으면 결과가 좋을 것이다라는 관점으로 접근한다.
> Process자체를 Dependable하게 만들자. 잘짜여진 공정으로 만들자의 관점으로 볼 수 있다.
IEC 62304 Life cycle process
기본 철학 좋은 프로세스를 만들면 좋아지고 안정적이지 않겠는가에 대한 출발이다.
이 부분에 System Engineering(시스템 공학)을 기본으로 한다. 좋은 공정 - 시스템 엔지니어가 관리.
좋은 공정이 개런티 되려면?
몇가지의 생명주기가, 어느정도 수준이상이 되었을 때 개런티 된다고 본다.
SW는 4가지 (프로세스)를 중요하다고 본다.
1)개발 공정 (V모델)
2)리스크매니지먼트 프로세스
3) 형상관리
4) 변화관리
*QA : 품질관리는 기본으로 깔려 있다.
IEC 62304 Define - Requirements 를 다 실행했느냐를 검증, 제품에 대한 검증이 아니다.
전제조건 - 회사가 품질관리 시스템을 가지고 있어야 한다.
ISO 23485 - Quality management systems 하에 4가지 프로세스를 가지고 있어야 한다
Software Process
(SW공학관점) A structured set of activities required to develop a software system.
수행되어야 할 다양한 작업(액티비티)들이 연관을 가지고 진행되어야 하는지 작업의 구조 이것을 프로세스라고 함
62304 에서의 Process 3가지
1) 목표를 달성하기 위한 일련의 작업 관계를 정의한 것 전체를 하나의 프로세스라고 봄
- 액티비티들의 모임, 그냥 모인 것이 아니라 연관관계(또는 sequence)를 가지고 있음
- 액티비티 : Set of Tasks, (62304에서 가장 작은 작업 단위는 Task입니다)
- Task : Task는 수행하는 Role이 Define되어 있다.
모든 Task에는 Input:Documents / Output:work product or 아티팩트 가 정해져있다.
메소드 - 일하는 작업 방식에 대한 설명
체크리스트 - 작업이 잘 되었는지 평가하는 기준
Process Define Sample
1) 액티비티 및 흐름 정의 - 병렬 / 순차 수행 정의
2) 액티비티 하나하나에 대한 Task 정의, 역할 선택, 입력 문서, 출력 문서 정의
62304 에는 몇가지 Task가 있으면 만족할까? 30-40개 정도의 Task 필요
62304의 3가지 요구사항 - Process에 관한, plan에 관한, management 에 관한.
Process정의 -> plan 가능 -> management
▽
productivity
Quality
process 없는 Plan은 ad-hoc한 plan이다
62304는 프로세스들을 잘 수행했는지 문서화 하여 제출 ->
Software Process Planing
Plan
process가 잘 정의되어있으면 이미 되어있는 것이다.
schedule - Task를 누가 언제 얼마의 리소스를 사용해서 할 것인지 들어간다.
ex) Staff allocation chart / Tasks, durations, and dependencies / Activity bar chart 등으로 표현
62304 does not do
- 조직이 반드시 어떻게 구성 되어야 한다 등의 요구사항은 없음
중요한 것은 문서의 Content / format 을 정의하지 않는다.
예) SVR: S/W Validation Report - 목차 주루룩 해서 1개의 Document로 할 수도 있고 쪼갤 수도 있다. 특정 도구를 쓰고 파일 등으로 낼 수도 있다.
그러나 어떤 형태로든 심사하는 사람이 보기 쉽게 만들어 주는 것이 좋음.
- 특정 생명주기 규정 없음 - ex) Waterfall, Iterative
인증을 위해서는 결국 문서 Deliverables 가 필요
Process
- Development
- Risk management
- Change management
- Quality management
- Maintenance
Plan
- Development & V&V
- Risk management
- Change management
- Quality management
- Maintenance
전체가 꼭 별개의 Document일 필요는 없다. 선택하기 나름이다.
Requirements
System Requirements
SW Requirements
> 두가지가 꼭 분리되어 있어야 한다. 두 요구사항 사이에 연관성이 정의되어 있어야 함
1) 시스템 요구사항 먼저 정리
아이템화 하여야 함, ID 부여 해야 함, Ex) 요구사항 하나당 한문 장 or Usecase 방식으로 해도 됨
2) SW요구사항도 요구사항 <-> ID 연관관계 추적성 관리 해야함
*가장 중요한 것은 Traceability 확보가 중요함
요구사항이 변경된 경우 관리 할 수 있도록, 관리(Tool활용) 필요
Design
Architecture Design _ 아키텍쳐 설계
- 전체 시스템에 소프트웨어 요소(item)이 있다는걸 정의
*item 또한 요구사항과 연관성이 있음 - 이런 요구사항으로 인해, 모듈이 필요하다라는 이야기
Module(Unit) _ 모듈(Unit) 설계
- 어떤 필요에 의해 개발 되었고, 그것에 대한 Test case를 통 해 테스트는 어떻게 되었다. 를 기술하는 것이 기본이다.
이부분은 Risk M. 과 연관이 있다.
해저드에 대한 원인이 무엇이고 리스크를 낮추기 위해 Risk control measure 로 인해 어떻게 만들고 추가하고 했다
와 연관이 있음
62304 의 요구사항에는 다른것도 있다 아키텍처를 검증하라, 플랜을 검증하라
리뷰를 통해서 가능하다. 리뷰 Task 만들면 된다.
V&V
Review & Inspection
Testing - Unit / Integration & System
Risk Analysis
Configuration management
- configuration audit finding
software problem resolution
Unresolved Anomalies
결국 기록을 남기는 것이다.
——
예시 소개 1)
각 Phase 정리
Role 정리
Task 에 대한 정리
- 산출물 ( IN/OUT)
Work Products
- 산출물 총 정리, 각각의 산출물 정리
예시2) 소프트웨어 아키텍쳐 설계 - 레이저 치료기(가상)
2. 소프트웨어 구조
전체 시스템 구조 - 및 서브 시스템 연관 관계 표현
각 서브 시스템에 대한 구조의 SW 요소 - Component 로 쪼개고 인터페이스 표현
unit -> item(component) -> items(components) -> system
구성 요소 컴포넌트에 대한 설명
(이렇게 구성하면 SW Req. 부터 다 연결 되어진다)
——
IEC 62304 1.1 2015-06 문서
실제 요구사항은 4장부터
General Req.
등등등
주요 목차 & 내용
4. General Requirements
4.1 Quality management system
품질 관리 체계를 가지고 있는 것으로 가정하고 본다. ISO 13485 에 합당한 체계가 있거나 다른 체계거나,
다른 품질 관리 체계 ISO 9003 등 품질관리 인증체계, 없다면 품질 관리 체계를 Define 해야 한다.
4.2 Risk Management
… with ISO14971
4.3 software safety classification
A/B/C 클래스는 전체 시스템에 대해 결정 하고, 예를들어 전체 시스템이 C라면 해당 Item 들도 C 기준이다.
몇개는 B라면 입증 할 수 있도록 기술 해야 한다.
4.4 Legacy software
risk management
Gap analysis
- 과거 시스템과 현재 시스템 차이 분석, 변화관리 시스템에 입각해서
5. Software development process
5.1 Software development planning
plan이 있기 전 반드시 프로세스가 있어야 한다.
plan은 반드시 프로세스를 제시해야 한다.
Traceability 도 포함
activity와 task에서 어떤 산출물이 나오는지 plan에서 제시하게 되어 있다.
5.1.2 Software development keep plan updated
5.1.4 standards, methods, and tools planning
허나, process에서 정의하고 레퍼런스
5.1.5 integration and integration testing planning
5.1.6 software verification planning
5.1.7 risk management planning
5.1.8 documentation planning
5.2 software requirements analysis
5.3.1 transform software requirements into an architecture
5.6.6 regression testing
등의 항목들이 존재한다.