© Ian Sommerville 2004Software Engineering, 7th edition. Chapter 9 Slide 1 중대한 시스템 명세 배재대학교 멀티미디어 정보공학 연구실 발표자 : 이 상 조

© Ian Sommerville 2004Software Engineering, 7th edition. Chapter 9 Slide 2 Objectives l 중대한 시스템에 대한 확실성 요구사항을 그 시스템이 직면하고 있는 위험을 분석 함으로써 어떻게 찾아낼 수 있는지 이해

© Ian Sommerville 2004Software Engineering, 7th edition. Chapter 9 Slide 3 위험 중심 명세 l 위험 중심 명세는 시스템이 직면한 문제를 이해하고, 그것의 근본적인 원인을 발견하고, 그 위험을 관리하기 위한 요구사항을 생성하는 것 l 이 명세는 안정성 중심 시스템과 보안성 중심 시스템 개발자에게 널리 사용되는 방법

© Ian Sommerville 2004Software Engineering, 7th edition. Chapter 9 Slide 4 위험 분석의 방법 l 위험 식별 생길 수 있는 위험을 찾아냄 l 위험 분석과 분류 위험을 분리해서 고려 심각한 가능성이 있는 것과 가능성이 없는 것 l 위험 분할 근본적인 원인을 밝혀내기 위해 개별적으로 분석 l 위험 감소 평가 식별된 위험이 감소되거나 제거될 수 있는 방법에 대한 제안을 함

© Ian Sommerville 2004Software Engineering, 7th edition. Chapter 9 Slide 5 위험 기반 명세

© Ian Sommerville 2004Software Engineering, 7th edition. Chapter 9 Slide 6 위험 식별 l 위험 식별은 위험 분석 프로세스의 첫 단계 l 중대한 시스템이 직면해야 할 위험을 찾아내는 것 l 안전성 중심 시스템에서, 주요 위험은 사고로 연결될 수 있는 위험을 말함 l 위험의 종류 물리적 위험, 전기적 위험, 생물학적 위험, 서비스 고장의 위험 등

© Ian Sommerville 2004Software Engineering, 7th edition. Chapter 9 Slide 7 인슐린 펌프 시스템 l 인슐린 과다 투여 ( 서비스 고장 ) l 인슐린 과소 투여 ( 서비스 고장 ) l 전지 방전에 의한 전력 고장 ( 전기적 ) l 심장 조절기와 같은 다른 의료 장비와의 전기적 간섭 ( 전기적 ) l 부정확한 조절에 의한 센서와 작동기 접촉 불량 ( 물리적 ) l 환자의 몸에서 떨어져 나간 기계 부품 ( 물리적 ) l 기계 부착에 의한 감염 ( 생물학적 ) l 기계에서 사용된 인슐린 혹은 재료에 의한 알레르기 반응 ( 생물학적 )

© Ian Sommerville 2004Software Engineering, 7th edition. Chapter 9 Slide 8 위험 분석과 분류 l 시스템에 나타난 위험의 정도에 따라 분류 l 분석과 분류의 결과 종류 수용 불가능 사람의 생명이나, 사업의 재정 상태를 위협하면서 일어날 가능성이 있음 일어날 확률이 적음 덜 심각한 결과를 갖거나 발생될 확률이 적은 것 수용 가능 위험의 요소를 수용 가능하고 재정적인 위험을 제거하기 위해 추가 비용이 들지 않음

© Ian Sommerville 2004Software Engineering, 7th edition. Chapter 9 Slide 9 Levels of risk

© Ian Sommerville 2004Software Engineering, 7th edition. Chapter 9 Slide 10 위험 평가 l 위험 평가는 위험의 가능성과 위험의 심각성 정도를 측정하는 것 l 정확한 평가는 불가능하며 일반적으로 공학적 판단에 달려있음 l 가능성과 심각성 정도는 가능함, 거의 없음, 드뭄, 높음, 중간, 낮음과 같은 용어로 나타냄 l 과거의 시스템 경험을 통해 이러한 용어를 수치화할 수 있음

© Ian Sommerville 2004Software Engineering, 7th edition. Chapter 9 Slide 11 위험 분석 – 인슐린 펌프

© Ian Sommerville 2004Software Engineering, 7th edition. Chapter 9 Slide 12 위험 분할 l 위험 분할은 특정 시스템에 대한 위험의 근본 원인을 발견하는 과정을 말함 l 위험 분할은 하향식과 상향식이 있음 하향식의 연역적 방법은 위험으로부터 시작해서 가능한 시스템 고장에 이르기 때문에 사용하기 쉬움 상향식의 귀납적 방법은 제안된 시스템 고장으로 시작해서 고장에 이르게한 위험을 찾아내는 방법

© Ian Sommerville 2004Software Engineering, 7th edition. Chapter 9 Slide 13 결함 트리 l 사건을 식별하고 그 사건으로부터 위험의 가능한 원인을 발견하는 역방향 작업 l 안정성 중심 시스템을 위해서 개발 l 루트에 위험을 놓고 그 위험에 이르는 상태를 찾아냄 l 상태는 ‘or’, ‘and’ 기호로 연결 l 결함 트리의 목표는 사건의 원인의 수를 극소화 하기 위함

© Ian Sommerville 2004Software Engineering, 7th edition. Chapter 9 Slide 14 Insulin pump fault tree

© Ian Sommerville 2004Software Engineering, 7th edition. Chapter 9 Slide 15 위험 감소 평가 l 잠재적 위험과 그것에 대한 근본 원인이 식별되고 나면, 그 위험을 관리하고 사고가 일어나지 않도록 하는 시스템 확실성 요구사항을 만들어야 함 l 위험 감소 방법 위험 회피 위험 탐지 및 제거 손실 최소화

© Ian Sommerville 2004Software Engineering, 7th edition. Chapter 9 Slide 16 안전성 명세 l 비교적 최근까지 안전성 중심 시스템은 제어되고 있는 장비의 고장이 부상이 원인 이였음 l 1990 년대 컴퓨터 제어가 널리 퍼짐에 따라 안전 공학 단체에서는 국제 표준을 개발 l 안전성 명세와 보증에 대한 프로세스는, 안전 관리를 위한 국제 표준 IEC 에서 정의된 전체 안전성 생명주기의 일부분 임

© Ian Sommerville 2004Software Engineering, 7th edition. Chapter 9 Slide 17 © Ian Sommerville 2000Dependable systems specification Slide 17 The safety life-cycle

© Ian Sommerville 2004Software Engineering, 7th edition. Chapter 9 Slide 18 소프트웨어 신뢰성 명세 l 시스템의 컴포넌트는 상호의존적이기 때문에 한 컴포넌트의 고장은 시스템 전체에 퍼져나감 l 컴퓨터 기반 시스템에서 전체 시스템의 신뢰성을 지정할 때 다음과 같은 세가지 사항을 고려 하드웨어 신뢰성 하드웨어가 고장날 확률, 수리시간 소프트웨어 신뢰성 부정확한 결과를 낼 확률 운영자 신뢰성 시스템 운영자가 실수할 가능성

© Ian Sommerville 2004Software Engineering, 7th edition. Chapter 9 Slide 19 신뢰성 척도 l 신뢰성 척도는 하드웨어 컴포넌트를 위해서 처음 고안됨 l 하드웨어 컴포넌트 고장은 기계의 마모와 전기적 가열과 같은 물리적 요소 때문에 필연적 l MTTF 를 사용하여 고장 평균 시간을 척도 l 하드웨어 척도는 소프트웨어 컴포넌트 고장에 적용할 수 없기 때문에, 특정 입력에 대해서만 반영

© Ian Sommerville 2004Software Engineering, 7th edition. Chapter 9 Slide 20 신뢰성 척도 척도설명 POFOD 서비스 요청이 있을 때 시스템이 고장 날 확률 이면 1000 번에 한번의 고장이 난다는 의미 ROCOF 예상치 못한 행동이 일어나는 빈도 2/100 은 100 연산 시간 단위마다 두 번의 고장이 난다는 의미 MTTF 시스템 고장 간의 평균 시간 500 이란 의미는 매 500 단위 시간마다 고장이 난다는 의미 AVAIL 임의의 시점에서 시스템을 사용할 수 있는 확률 은 매 1000 단위 시간 동안 998 시간 동안 사용 할 수 있다는 의미