SW FMEA의 Ground Rules - 사전활동, 준비물, 그라운드 룰

 

SW FMEA를 수행할 때는 반드시 그라운드 룰(Ground Rule)이 필요합니다.

물론, 이에 대한 정확한 원칙과 정답은 없을거 같아요.

하지만, 최소한의 기준 정도는 확보하고 있으면 많은 도움이 될거라고 생각합니다.

 

 

 

SW FMEA를 시작하기에 앞서, SW FMEA Ground Rule 정의는 꼭꼭 필요한 사항입니다.

SW FMEA의 Ground Rule은 분석의 일관성, 효율성, 명확성을 보장하고, 팀 간 협력과 의사소통을 원활하게 하며, 신뢰성 있는 결과를 도출하는 데 필수적입니다. 또한 Ground Rule은 분석 범위와 평가 기준을 명확히 설정해 체계적인 분석을 가능하게 하고, 리소스를 효율적으로 사용할 수 있도록 돕습니다. 

뿐만 아니라, 위험 평가의 일관성을 유지하고, 분석 결과를 문서화하여 추후 검토 및 문제 해결에 활용할 수 있게 합니다.

따라서, Ground Rule은 성공적인 FMEA 수행을 위한 기본적이면서도 중요한 기준입니다.

 

참고로, SW FMEA를 위한 위험성 평가 가이드는 별도로 정리해 두었습니다.

 

SW FMEA: 위험도 평가를 위한 심각도(Severity), 발생가능성(Occurrence), 검출가능성(Detection) 선정 기준

반응형

SW FMEA 사전 준비 (Prerequisites of SW FMEA)

SW FMEA를 효과적으로 수행하기 위해서는 사전 활동과 준비물이 매우 중요합니다. FMEA는 체계적인 분석 방법이기 때문에, 충분한 준비 없이는 분석 과정에서 혼란이 발생하거나 누락된 부분이 생길 수 있습니다. 따라서 FMEA를 수행하기 전에 필요한 사전 활동과 준비물을 철저히 갖추는 것이 성공적인 분석의 핵심입니다.

1. 소프트웨어 시스템에 대한 명확한 이해

소프트웨어 FMEA를 수행하기 전에 분석 대상이 되는 시스템에 대한 명확한 이해가 필요합니다. 이를 위해 시스템의 전반적인 아키텍처, 기능 요구사항, 설계 사양 등을 충분히 숙지해야 합니다. 즉, 소프트웨어 시스템의 전반적인 동작과 각 기능이 어떻게 작동하는지 이해하여, 고장 모드를 보다 쉽게 식별하고 분석할 수 있도록 합니다.

이를 위한 주요 활동들은 다음과 같습니다.

• 시스템의 구조, 모듈, 인터페이스를 분석: 시스템의 전반적인 아키텍처를 파악하여, 주요 컴포넌트들이 어떻게 연결되고, 상호작용하는지 확인하는 것으로, 주요 컴포넌트 및 모듈의 기능과 역할을 파악하고, 각 모듈이 다른 모듈과 어떻게 연계되는지 분석합니다. 또한 모듈간의 통신 및 데이터 교환 방식을 파악하여 인터페이스에서 발생할 수 있는 문제를 식별합니다.
• 주요 기능과 비기능적 요구사항 검토: 소프트웨어가 반드시 수행해야 하는 핵심 기능을 검토하여, 각 기능에서 발생할 수 있는 고장 모드를 식별합니다. 또한 성능, 보안, 확장성, 신뢰성 등 소프트웨어 품질 속성을 검토하여, 시스템 안정성과 사용자 경험에 영향을 미칠 수 있는 요소들을 파악합니다.

2. 요구사항 및 설계 사양 분석

요구사항 문서와 설계 사양을 철저히 분석하여 시스템이 어떻게 작동해야 하는지를 명확히 정의해야 합니다. 요구사항과 설계 사양을 기반으로 고장 모드와 그에 따른 영향을 식별할 수 있습니다. 즉, 요구사항 및 설계 사양을 기반으로 잠재적 고장 모드를 미리 파악하여 분석에 활용해야 합니다.

이를 위한 주요 활동들은 다음과 같습니다.

• 요구사항 명세서(Requirements Specification) 검토: 소프트웨어의 기능적 및 비기능적 요구사항을 명확히 이해하고, 이를 기반으로 잠재적인 고장 모드를 식별합니다. 요구사항 명세서를 검토함으로써, 시스템이 수행해야 할 작업과 이를 수행하는 데 필요한 조건들을 파악하고, 결함 발생 가능성을 사전에 분석할 수 있습니다.
• 시스템 설계 문서(System Design Specification) 분석: 시스템의 구조, 모듈, 인터페이스 등 설계 세부 사항을 분석하여 소프트웨어가 어떻게 동작하고, 기능을 수행하는지를 파악합니다. 

3. 팀 구성 및 역할 분담

SW FMEA는 다양한 전문가들의 협력이 필요한 분석 활동입니다. 소프트웨어 개발자, 시스템 아키텍트, 품질 관리 전문가, 제품 관리자 등 관련 팀원들이 적절히 구성되고 역할을 명확히 분담해야 합니다. 즉, 분석 과정에서 필요한 모든 지식과 역량을 갖춘 팀을 구성하고, 각 팀원이 자신에게 주어진 역할을 명확히 이해하도록 해야 합니다.

이를 위한 주요 활동들은 다음과 같습니다.

• 팀 내 역할 및 책임 할당
• 각 역할에 따른 분석 준비 및 도구 제공

4. 이전 FMEA 결과 및 실패 사례 검토

이전 프로젝트에서 수행한 FMEA 결과나 실패 사례를 검토하는 것이 도움이 됩니다. 비슷한 시스템이나 기능에 대한 분석 결과를 재사용하거나 참조하면, 새로운 FMEA 분석을 더 효율적으로 수행할 수 있습니다. 즉, 과거의 데이터를 활용하여 중복된 분석을 방지하고, 실수나 오류를 미리 방지할 수 있습니다.

이를 위한 주요 활동들은 다음과 같습니다.

• 기존 FMEA 문서 및 데이터 검토
• 과거 실패 사례 및 교훈을 확인하여, 분석에 반영

5. 분석 기준 및 범위 정의

SW FMEA를 수행할 때 분석의 범위와 기준을 사전에 정의해야 합니다. 어떤 기능이나 모듈을 분석할지, 어떤 평가 기준을 사용할지를 명확히 설정해야 합니다. 즉, 분석 범위를 명확히 정의하고, 우선적으로 분석할 부분을 결정하여 시간과 리소스를 효율적으로 사용할 수 있도록 합니다.

• 분석할 시스템 모듈, 기능, 또는 서브시스템을 선정
• 우선 순위가 높은 부분을 식별하고 분석 범위를 제한

6. 리스크 평가 기준 설정

SW FMEA에서 위험도를 평가할 때 사용할 기준(심각도, 발생 가능성, 검출 가능성)을 사전에 설정해야 합니다. 평가 기준은 일관성을 유지하기 위해 모든 팀원이 합의한 기준에 따라 사용해야 합니다. 즉, 분석 결과를 체계적으로 평가하고, 일관된 리스크 평가를 통해 중요한 고장 모드를 식별해야 합니다. 이를 위한 별도 기준은 따로 정리해 두었습니다.

 

SW FMEA: 위험도 평가를 위한 심각도(Severity), 발생가능성(Occurrence), 검출가능성(Detection) 선정 기준

 

리스크 평가 기준 설정 활동으로는 다음과 같습니다.

• 심각도(Severity), 발생 가능성(Occurrence), 검출 가능성(Detection) 점수 설정
• 리스크 우선순위 번호(RPN, Risk Priority Number) 계산 방식 합의

7. 도구 및 소프트웨어 준비

SW FMEA 수행을 돕는 도구나 소프트웨어를 사전에 준비해야 합니다. FMEA 전용 도구나 스프레드시트, 문서화 도구 등을 활용하면 분석을 체계적으로 진행할 수 있습니다. 즉, SW FMEA 수행 시 필요한 도구를 사전에 준비하여 분석 과정이 원활하게 이루어지도록 하는데 목적이 있습니다.

• SW FMEA 분석 도구 선정 및 설치
• 데이터 수집 및 문서화 도구 준비

8. 테스트 및 검증 계획 수립

SW FMEA 분석 결과로 도출된 고장 모드를 검증할 테스트 시나리오와 방법을 미리 계획해야 합니다. 검증 계획이 있어야 고장 모드를 실제로 테스트하고, 예방 조치를 통해 문제가 해결되었는지 확인할 수 있습니다. 즉, 도출된 고장 모드를 실제 환경에서 검증하고, 문제 해결을 위한 계획을 마련해야 합니다.

• 테스트 시나리오 작성
• 검증 절차와 대응 방법 계획 수립

 

SW FMEA 사전 준비물

산출물 명	설명 및 활용
요구사항 명세서 및 설계 문서	소프트웨어의 요구사항과 설계 사양을 담고 있는 문서입니다. 이 문서는 소프트웨어가 수행해야 할 기능과 설계에 대한 명확한 정보를 제공하므로, 요구사항과 설계를 바탕으로 고장 모드를 식별하고, 각 고장 모드가 어떻게 시스템에 영향을 미치는지 분석할 수 있습니다.
이전 SW FMEA 결과 또는  유사 시스템 데이터	과거에 수행된 FMEA 분석 결과나 유사한 시스템에서 발생했던 결함 데이터를 준비해야 합니다. 이는 비슷한 유형의 고장 모드가 다시 발생하지 않도록 예방하는 데 도움이 됩니다. (기존 데이터를 참조하여 새로운 시스템에 대한 고장 모드 식별을 효율적으로 수행)
FMEA 분석 도구 및 스프레드시트	FMEA를 수행할 때 데이터를 기록하고 평가할 수 있는 도구입니다. 이는 분석 과정에서 필요한 데이터를 체계적으로 기록하고, 리스크 평가를 쉽게 할 수 있도록 도와줍니다. (고장 모드, 영향, 원인, 평가 점수 등을 기록하여 FMEA 분석을 체계적으로 진행)
리스크 평가 기준표	각 고장 모드의 심각도, 발생 가능성, 검출 가능성을 평가할 수 있는 기준표입니다. 이 기준표를 사용하여 각 고장 모드의 위험 수준을 수치화하고, 우선순위를 결정할 수 있습니다. (일관된 평가 기준을 사용해 리스크 우선순위를 설정하고, 중요한 문제를 우선적으로 해결)
테스트 케이스 및 검증 시나리오	도출된 고장 모드를 검증하기 위해 필요한 테스트 케이스와 시나리오입니다. 이 문서는 분석 후 실제로 고장 모드가 발생하는지, 예방 조치가 효과적으로 작동하는지 확인하는 데 사용됩니다. (도출된 고장 모드에 대해 테스트를 진행하고, 문제가 해결되었는지 검증)
회사의 품질 및 안전 기준	소프트웨어 품질 및 안전성에 대한 회사의 기준입니다. 이는 고장 모드를 평가할 때 중요한 참조 자료가 되며, 소프트웨어 시스템이 어떤 수준의 품질을 유지해야 하는지 기준을 제공합니다. (고장 모드가 품질 기준에 맞지 않는 경우, 개선 조치를 결정하는 데 도움을 줍니다.)
피드백 및 교훈 문서	과거 프로젝트에서 얻은 피드백 및 교훈을 담은 문서입니다. 이를 통해 과거 실수를 되풀이하지 않도록 참고할 수 있으며, FMEA 수행 중 필요한 개선 사항을 반영할 수 있습니다. (과거 피드백을 기반으로 FMEA의 분석 결과를 더 신뢰성 있게 만듦)

 

 

SW FMEA Ground Rules

1. Common Ground Rules

1. 특정 레벨에 대한 모든 고장들이 식별되어야 합니다. (SW FMEA의 범위 식별)
   가령 컴포넌트 레벨에 대한 모든 고장을 식별한다든지 또는 서브 시스템의 모든 고장 혹은 소프트웨어 레벨의 모든 고장을 식별할 것인지를 결정해야 합니다.
2. 특정 레벨에서 어떤 고장이 존재하는지가 식별되어야 합니다. (잠재 고장 모드 식별)
   소프트웨어가 의도된 기능을 수행하지 못할 수 있는 모든 가능한 방법을 확인해야 합니다. 즉, 오류, 버그, 충돌 및 잘못된 출력과 같은 다양한 유형의 실패가 고려되어야 합니다.
3. 소프트웨어 컴포넌트의 내/외부 인터페이스가 식별되어야 합니다.
   인터페이스를 통해 전파되는 고장 모드가 어느정도 규모인지 또는 어떤 것들이 발생할 수 있는지에 대해 문서화가 이루어져야 합니다.
4. 소프트웨어 컴포넌트에 발생 가능한 고장의 영향이 결정되어야 합니다.
   고장 또는 다른 코드에 의해 야기되는 결함들은 상세 설계 단계에서 기능 및 객체 레벨에서 반드시 분석이 이루어져야 합니다.
5. 사람의 실수에 의해 야기되는 고장 모드는 FMEA에서는 고려하지 않습니다.
6. 위험 등급 평가 기준을 모든 팀원이 동일하게 적용하여 일관성 있는 분석을 유지해야 합니다.
7. 문서화 및 용어 표준을 설정하여 팀 내 의사소통을 명확하게 하고, 분석 결과가 쉽게 이해되도록 해야 합니다.
8. 하드웨어 아이템의 고장 모드에 대한 크리티컬리티(criticality) 분류는 최악의 잠재적 고장 효과를 가진다고 간주해야 합니다.
9. 동일한 기능을 수행하는 여러 아이템에 대한 고장 모드는 단지 하나의 고장 모드로만 식별해야 합니다.
10. 아이템들이 가지는 제약 구조들은 반드시 분석이 이루어져야 합니다.
11. 분석 과정에서 도출된 결과와 결함 데이터를 체계적으로 기록하여, 문제 해결 및 추후 검토가 가능하도록 추적성을 보장해야 합니다.

2. Organizational Ground Rules

1. 팀 구성 및 역할 분담이 정의되어야 합니다.
   SW FMEA를 수행할 때는 소프트웨어 엔지니어, 품질 관리 전문가, 시스템 아키텍트 등 다양한 역할이 필요합니다. 각 팀원의 역할과 책임을 명확히 정의하여 협력 체계를 구축합니다.
2. 전문가 참여가 보장되어야 합니다.
   시스템에 대한 전문 지식을 가진 팀원들이 분석에 참여하여, 고장 모드의 정확한 식별과 평가가 이루어지도록 해야 합니다.
3. 의사소통 및 협력 프로세스가 정의되어야 합니다.
   팀 간 원활한 의사소통을 위해 정기적인 회의와 피드백 루프를 설정하여, 분석 진행 상황을 공유하고 의견을 수렴합니다.

3. Schedule Ground Rules

1. 분석 일정에 대한 계획이 수립되어야 합니다.
   FMEA 분석을 프로젝트 일정 내에서 효과적으로 수행하기 위해, 명확한 일정과 단계별 마일스톤을 설정합니다. 각 분석 단계에 필요한 시간을 계획하고, 일정이 지연되지 않도록 관리해야 합니다.
2. 주요 기능에 대한 분석 우선순위가 설정되어야 합니다.
   시스템의 모든 부분을 한꺼번에 분석하는 것은 비효율적이므로, 위험성이 높고 중요한 기능에 우선순위를 두고 단계적으로 분석을 진행합니다.
3. 검토 및 피드백 주기가 설정되어야 합니다.
   일정에 따라 분석이 완료되면, 정기적으로 검토 및 피드백을 반영하여 문제를 조기에 발견하고 개선할 수 있도록 주기적인 피드백 과정을 설정합니다.

4. Resource Ground Rules

1. FMEA 수행에 필요한 리소스를 최적화하여 비용 낭비를 방지해야합니다.
   주요 고장 모드에 대한 분석에 집중하고, 중요하지 않은 부분에는 최소한의 리소스를 할당하는 방식으로 비용을 관리합니다.
2. 자동화 도구를 활용해야 합니다.
   FMEA 분석 도구나 자동화된 리스크 평가 도구를 도입하여, 분석 과정을 효율화하고 인적 자원의 부담을 줄여 비용을 절감합니다.
3. 분석 범위와 비용의 균형을 유지해야 합니다.
   분석의 범위와 깊이를 비용과 일정에 맞게 조정하여, 불필요한 분석을 피하고 효율적으로 리스크를 관리합니다.

5. 기타 사항

1. 테스트 및 검증 기준 수립: FMEA 분석에서 도출된 고장 모드와 그에 따른 리스크를 검증하기 위한 명확한 테스트 및 검증 기준을 설정해야 합니다. 이를 통해 도출된 문제들이 실제로 발생할 가능성을 테스트하고, 예방 조치의 유효성을 검증할 수 있습니다.
2. 피드백 루프 설정 및 지속적인 개선: FMEA는 한 번의 분석으로 끝나는 것이 아니라, 지속적으로 피드백을 반영하고 개선해야 합니다. 소프트웨어가 업데이트되거나 새로운 기능이 추가될 때마다 FMEA 결과를 검토하고, 새로운 리스크를 반영하는 피드백 루프를 설정합니다.
3. 결과의 문서화 및 공유 절차 강화: FMEA 분석 결과는 모든 이해관계자에게 투명하게 공유되고 쉽게 접근할 수 있어야 합니다. 이를 위해 분석 결과를 명확히 문서화하고, 적절한 공유 메커니즘을 설정합니다.
4. 위험 수용 기준 설정: 모든 리스크를 완전히 제거하는 것은 불가능하므로, 프로젝트나 조직 차원에서 수용 가능한 리스크 수준을 미리 정의해야 합니다. FMEA 결과로 도출된 리스크 중 어떤 것은 수용할 수 있고, 어떤 것은 반드시 해결해야 하는지 기준을 마련합니다.
5. 위험 관리 도구 및 기술 적용: FMEA 수행 시 다양한 위험 관리 도구 및 소프트웨어를 활용하여 고장 모드 식별, 리스크 평가, 데이터 관리 등의 작업을 자동화하고 체계적으로 처리할 수 있습니다. 적절한 도구와 기술을 선택하여 분석 속도와 정확성을 높입니다.
6. 커뮤니케이션 및 의사결정 프로세스 명확화: FMEA 분석 도중 발생할 수 있는 결함 및 문제에 대해 의사결정이 신속하고 정확하게 이루어지기 위한 명확한 커뮤니케이션 프로세스를 설정합니다. 각 단계에서 결정권자와 책임자들이 즉시 대응할 수 있도록 커뮤니케이션 구조를 정립합니다.
7. 리스크 관리 교육 및 훈련: FMEA 분석에 참여하는 모든 팀원이 리스크 관리 및 FMEA 기법에 대해 충분히 숙지할 수 있도록 사전 교육을 실시합니다. 이는 분석 과정에서 발생하는 오류를 줄이고, 각 팀원이 자신의 역할을 정확히 이해하게 합니다.

상세한 소프트웨어 고장 유형은 다음에 정리되어 있습니다.

SW FMEA: 위험도 평가를 위한 심각도(Severity), 발생가능성(Occurrence), 검출가능성(Detection) 선정 기준

---

이 글을 작성하며, 이미 잘 알지만, 쉽게 이행하기 어려운 말이 눈에 띄어 추가로 적어 봅니다.

 

“Try to think “outside the box”

 

SW FMEA를 수행함에 있어 특정 아이템이나 기능만을 볼것이 아니라 프로젝트 전체를 먼저 훑어 보고, 그에 따른 고장 모드를 식별한 연후에 개별적인 기능 및 아이템에 대한 고장 모드를 식별하는 것이 필요합니다.

또한 각 컴포넌트들간의 인터페이스를 정확하게 체크하고, 가정들, 제한 사항들, 그리고 일관성이 결여되는 것들은 없는지 정확하게 확인을 해야 합니다.