guide root cause analysis steps
이 튜토리얼에서는 근본 원인 분석이란 무엇이며 피쉬 본 분석과 같은 다양한 근본 원인 분석 기법과 5 가지 이유 기법을 설명합니다.
RCA (근본 원인 분석) 소프트웨어 프로젝트 팀에서 문제의 근본 원인을 찾는 구조화되고 효과적인 프로세스입니다. 체계적으로 수행하면 팀 수준뿐 아니라 조직 전체에서 결과물과 프로세스의 성능과 품질을 향상시킬 수 있습니다.
이 자습서는 팀 또는 조직의 근본 원인 분석 프로세스를 정의하고 간소화하는 데 도움이됩니다.
이 튜토리얼은 근본 원인 분석의 기본 사항을 이해하기 위해 제공 관리자, 스크럼 마스터, 프로젝트 관리자, 품질 관리자, 개발 팀, 테스트 팀, 정보 관리 팀, 품질 팀, 지원 팀 등을 대상으로하며 템플릿과 예제를 제공합니다. .
학습 내용 :
근본 원인 분석이란?
RCA (근본 원인 분석) 원인을 식별하기 위해 결함을 분석하는 메커니즘입니다. 우리는 결함의 원인이 ' 테스트 미스 ',' 개발 미스 ”또는“ 요구 사항 또는 디자인 누락 ”.
RCA가 정확하게 수행되면 이후 릴리스 또는 단계에서 결함을 방지하는 데 도움이됩니다. 우리가 발견하면 결함이 디자인 미스 , 우리는 설계 문서를 검토하고 적절한 조치를 취할 수 있습니다. 마찬가지로 결함의 원인이 테스트 미스 , 테스트 사례 또는 메트릭을 검토하고 그에 따라 업데이트 할 수 있습니다.
RCA는 결함 테스트에만 국한되어서는 안됩니다. 생산 결함에 대해서도 RCA를 수행 할 수 있습니다. RCA의 결정에 따라 우리는 테스트 베드 해당 프로덕션 티켓을 회귀 테스트 케이스로 포함합니다. 이렇게하면 결함 또는 유사한 종류의 결함이 반복되지 않습니다.
근본 원인 분석 프로세스
RCA는 고객 사이트에서보고 된 결함뿐만 아니라 UAT 결함, 단위 테스트 결함, 비즈니스 및 운영 프로세스 수준 문제, 일상 생활 문제 등에 사용됩니다. 따라서 다음과 같은 여러 산업에서 사용됩니다. 소프트웨어 부문, 제조, 건강, 은행 부문 등
근본 원인 분석을 수행하는 것은 환자를 치료하는 의사의 작업과 유사합니다. 의사는 먼저 증상을 이해합니다. 그런 다음 그는 질병의 근본 원인을 분석하기 위해 실험실 테스트를 참조합니다.
질병의 근본 원인이 여전히 알려지지 않은 경우 의사는 스캔 검사를 의뢰하여 더 자세히 이해할 것입니다. 그는 환자의 질병의 근본 원인을 좁힐 때까지 진단과 연구를 계속할 것입니다. 모든 산업에서 수행되는 근본 원인 분석에도 동일한 논리가 적용됩니다.
따라서 RCA는 특정 단계 및 관련 도구를 따라 증상을 치료하지 않고 근본 원인을 찾는 것을 목표로합니다. 이러한 방법은 특정 문제에 대한 솔루션을 찾으려고하지만 RCA는 근본적인 원인을 찾으려고하기 때문에 결함 분석, 문제 해결 및 기타 문제 해결 방법과 다릅니다.
이름의 유래 근본 원인 분석 :
(영상 출처 )
잎, 줄기, 뿌리는 나무에서 가장 중요한 부분입니다. 땅 위에있는 잎 (증상)과 줄기 (문제)는 보이지만, 땅 밑에있는 뿌리 (원인)는 보이지 않고 뿌리가 깊어지고 예상보다 더 많이 퍼질 수 있습니다. 따라서 문제의 바닥을 파헤치는 과정을 근본 원인 분석이라고합니다.
근본 원인 분석의 장점
다음은 몇 가지 혜택입니다.
- 향후 동일한 문제의 재발을 방지합니다.
- 결국 시간이 지남에 따라보고되는 결함 수를 줄이십시오.
- 개발 비용을 줄이고 시간을 절약합니다.
- 소프트웨어 개발 프로세스를 개선하여 신속한 시장 출시를 지원합니다.
- 고객 만족도를 향상시킵니다.
- 생산성을 높이십시오.
- 시스템에서 숨겨진 문제를 찾습니다.
- 지속적인 개선을 돕습니다.
근본 원인의 유형
# 1) 인적 원인 : 인간이 만든 오류.
예 :
- 숙련됨.
- 지침을 제대로 따르지 않았습니다.
- 불필요한 작업을 수행했습니다.
# 2) 조직적 원인 : 사람들이 적절하지 않은 결정을 내리는 데 사용하는 프로세스입니다.
예 :
- 팀장으로부터 팀원들에게 모호한 지시가 주어졌습니다.
- 작업에 대해 잘못된 사람을 선택합니다.
- 품질을 평가하기위한 모니터링 도구가 없습니다.
# 3) 물리적 원인 : 어떤 방식 으로든 물리적 항목이 실패했습니다.
예 :
- 컴퓨터가 계속 다시 시작됩니다.
- 서버가 부팅되지 않습니다.
- 시스템에서 이상하거나 큰 소음.
근본 원인 분석을 수행하는 단계
효과적인 근본 원인 분석을 위해서는 구조화되고 논리적 인 접근 방식이 필요합니다. 따라서 일련의 단계를 따라야합니다.
# 1) RCA 팀 구성
모든 팀은 헌신적 인 근본 원인 분석 관리자 (RCA 관리자) 지원 팀에서 세부 정보를 수집하고 RCA 시작 프로세스를 시작합니다. 그는 명시된 문제에 따라 RCA 회의에 참석해야하는 자원을 조정하고 할당합니다.
회의에 참석하는 팀에는 문제에 가장 익숙한 각 팀 (요구 사항, 설계, 테스트, 문서화, 품질, 지원 및 유지 관리)의 직원이 있어야합니다. 팀에는 결함과 직접적으로 연결된 사람들도 있어야합니다. 예를 들면 고객에게 즉각적인 수정을 제공 한 지원 엔지니어
회의에 참석하기 전에 문제 세부 사항을 팀과 공유하여 초기 분석을 수행하고 준비 할 수 있도록합니다. 팀 구성원은 결함과 관련된 정보도 수집합니다. 사고 보고서에 따라 각 팀은 각 단계에서이 시나리오에 대한 잘못된 점을 추적합니다. 준비하면 다가오는 토론의 효율성이 높아집니다.
# 2) 문제 정의
사건 보고서, 문제 증거 (스크린 샷, 로그, 보고서 등)와 같은 문제의 세부 정보를 수집 한 다음 아래 질문을 통해 문제를 연구 / 분석합니다.
- 무엇이 문제입니까?
- 문제를 일으킨 일련의 사건은 무엇입니까?
- 어떤 시스템이 관련 되었습니까?
- 문제가 얼마나 오래 지속 되었습니까?
- 문제의 영향은 무엇입니까?
- 누가 참여했고 누가 인터뷰해야하는지 결정 했습니까?
'SMART'규칙을 사용하여 문제를 정의하십시오.
- 에스 특정
- 미디엄 용이함
- 에 CTION 지향
- 아르 자형 ELEVANT
- 티 NAME-BOUND
# 3) 근본 원인 파악
수행 브레인 스토밍 원인을 확인하기 위해 구성된 RCA 팀 내 세션. 사용 피쉬 본 다이어그램 또는 5 왜 분석인가 방법 또는 둘 다 근본 원인에 도달합니다.
RCA 관리자는 회의를 중재하고 브레인 스토밍 세션에 대한 규칙을 설정해야합니다. 예를 들어 규칙은 다음과 같을 수 있습니다.
- 다른 사람을 비판하거나 비난하는 것은 허용되지 않습니다.
- 다른 사람의 생각을 판단하지 마십시오. 어떤 아이디어도 나쁜 아이디어를 장려하지 않습니다.
- 다른 사람의 아이디어를 바탕으로 구축하십시오. 다른 사람의 아이디어를 기반으로 더 잘 만들 수있는 방법에 대해 생각해보세요.
- 각 참가자에게 자신의 견해를 공유 할 시간을줍니다.
- 틀에서 벗어난 사고를 장려하십시오.
- 집중하세요.
모든 아이디어는 기록되어야합니다. RCA 관리자는 회의 의사록을 기록하고 RCA 템플릿을 업데이트 할 구성원을 지정해야합니다.
# 4) 근본 원인 시정 조치 (RCCA) 구현
수정 조치에는 실제 근본 원인을 식별하여 솔루션을 수정하는 것이 포함됩니다. 이를 용이하게하려면 픽스를 구현해야하는 모든 버전과 제공 날짜를 결정할 수있는 제공 관리자가 있어야합니다.
RCCA는이 근본 원인이 앞으로 다시 발생하지 않도록 구현되어야합니다. 지원 팀에서 제공 한 수정 사항은 문제가보고 된 고객 사이트에 대해 일시적입니다. 이 수정 사항이 진행중인 버전에 병합되면 기존 기능이 손상되지 않도록 적절한 영향 분석을 수행하십시오.
수정 사항의 유효성을 검사하고 구현 된 솔루션을 모니터링하여 솔루션이 효과적인지 확인하는 단계를 제공합니다.
# 5) 근본 원인 예방 조치 (RCPA) 구현
팀은 이러한 유사한 문제를 향후 예방할 수있는 방법에 대한 계획을 마련해야합니다. 예를 들면 지침 매뉴얼 업데이트, 기술 향상, 팀 평가 체크리스트 업데이트 등. 적절한 예방 조치 문서를 따르고 팀이 취한 예방 조치를 준수하고 있는지 모니터링합니다.
이것을 참조하십시오 연구 논문 '소프트웨어 프로세스 품질 향상을위한 결함 분석 및 예방'에 대한 국제 소프트웨어 공학 및 응용 저널 각 소프트웨어 단계에서보고 된 결함 유형에 대한 아이디어를 얻고 이에 대한 예방 조치를 제안합니다.
RCA에서 얻은 정보는 고장 모드 및 영향 분석 (FMEA ) 솔루션이 실패 할 수있는 지점을 식별합니다.
도구 파레토 분석 일정 기간 동안 RCA 중에 확인 된 원인 (예 : 반년 또는 분기)을 통해 결함의 원인이되는 주요 원인을 식별하고 이에 대한 예방 조치에 중점을 둡니다.
근본 원인 분석 기법
# 1) 피쉬 본 분석
피시 본 다이어그램은 식별 된 문제의 가능한 원인을 식별하는 시각적 근본 원인 분석 도구이므로 원인 및 결과 다이어그램이라고도합니다. 이를 통해 증상을 해결하는 대신 문제의 실제 근본 원인을 파악할 수 있습니다.
이시카와 다이어그램이라고도합니다. Dr.Kaoru Ishikawa (일본 품질 관리 통계 학자). Herringbone 또는 Fishikawa 다이어그램이라고도합니다.
Fishbone 분석은 분석 단계에서 사용됩니다. 식스 시그마의 DMAIC 문제 해결을위한 접근 방식. 그것은 중 하나입니다 품질 관리의 7 가지 기본 도구 .
피쉬 본 다이어그램을 만드는 단계 :
피쉬 본 다이어그램은 물고기의 머리를 형성하는 문제가있는 물고기의 골격과 유사하며 물고기의 척추와 뼈를 형성합니다.
아래 단계에 따라 피쉬 본 다이어그램을 만듭니다.
- 쓰기 문제 ~에서 물고기의 머리 .
- 식별 원인 범주 그리고 쓰기 각 뼈의 끝 (원인 범주 1, 원인 범주 2 …… 원인 범주 N)
- 식별 주요 원인 각 범주 아래에 1 차 원인 1, 1 차 원인 2, 1 차 원인 N으로 표시하십시오.
- 원인을 다음으로 확장 2 차, 3 차 및 기타 수준 해당되는 경우.
소프트웨어 결함에 피시 본 다이어그램을 적용하는 방법의 예입니다 (아래 참조).
피쉬 본 다이어그램을 만드는 데 사용할 수있는 무료 및 유료 도구가 많이 있습니다. 이 튜토리얼의 Fishbone 다이어그램은‘ Creately’ 온라인 도구 . 피쉬 본 템플릿 및 도구에 대한 자세한 내용은 다음 튜토리얼에서 설명합니다.
# 2) 5 가지 이유 기법
5 기술이 개발 된 이유 Sakichi Toyoda 도요타의 제조업에 사용되었습니다. 이 기술은 각 답변이 Why 질문으로 응답되는 일련의 질문을 참조합니다. 아이가 어른들에게 질문하는 방법과 관련이있을 수 있습니다. 어른이주는 대답을 바탕으로 그들은 만족할 때까지 '왜'라는 질문을 몇 번이고 반복합니다.
5 문제의 근본 원인을 드릴 다운하기 위해 기술이 독립형으로 사용되거나 피시 본 분석의 일부로 사용되는 이유. 단계 수는 5 개로 제한되지 않습니다. 문제 진단에 도달 할 때까지 5 개 이하일 수 있습니다. 5 이유는 상대적으로 더 간단하고 근본 원인에 도달하는 더 빠른 방법입니다. 신속한 진단을 통해 증상을 배제하고 근본 원인에 도달 할 수 있습니다.
기술의 성공은 그 사람의 지식에 달려 있습니다. 동일한 이유 질문에 대해 다른 답변이있을 수 있습니다. 따라서 회의에서 올바른 방향과 초점을 선택하는 것이 중요합니다.
5 가지 이유 다이어그램을 만드는 단계
문제를 정의하여 브레인 스토밍 토론을 시작하십시오. 그런 다음 후속 이유와 대답을 따르십시오.
소프트웨어 결함에 5 가지 이유 다이어그램을 적용하는 방법의 예 :
5 Creately 온라인 소프트웨어를 사용하여 템플릿과 이미지를 그리는 이유.
결함을 일으키는 요인
결함이 발생하는 원인은 여러 가지가 있습니다.
- 불분명 / 누락 / 잘못된 요구 사항
- 잘못된 디자인
- 잘못된 코딩
- 불충분 한 테스트
- 환경 문제 (하드웨어, 소프트웨어 또는 구성)
RCA 프로세스를 수행하는 동안 이러한 요소를 항상 염두에 두어야합니다.
RCA는 결함에 대한 브레인 스토밍을 시작하고 진행합니다. RCA를하는 동안 우리가 스스로에게 묻는 유일한 질문은 '왜?'입니다. 그리고 뭐?' 수명주기의 각 단계를 조사하여 결함이 지속되는 위치를 추적 할 수 있습니다.
'왜?'부터 시작하겠습니다. 질문 (목록은 제한되지 않음). 외부 단계에서 시작하여 SDLC의 내부 단계로 이동할 수 있습니다.
최고의 유튜브 비디오 다운로더는 무엇입니까
- '왜'결함이 발견되지 않았습니다. 온 전성 테스트 생산 중?
- 테스트 중에 결함이 발견되지 않은 이유는 무엇입니까?
- '왜'테스트 케이스 검토 중에 결함이 발견되지 않았습니까?
- 결함이 발견되지 않은 '왜' 단위 테스트 ?
- “설계 검토”중에 결함이 발견되지 않은 이유는 무엇입니까?
- 요구 사항 단계에서 결함이 발견되지 않은 이유는 무엇입니까?
이 질문에 대한 답은 결함이 존재하는 정확한 단계를 제공합니다. 이제 단계와 이유를 확인하면 '무엇'부분이 나옵니다.
“앞으로 이것을 피하기 위해 무엇을 하시겠습니까?
이“무엇”질문에 대한 답을 구현하고 처리하면 동일한 결함이나 결함이 다시 발생하는 것을 방지 할 수 있습니다. 결함이나 결함의 원인이 반복되지 않도록 식별 된 프로세스를 개선하기위한 적절한 조치를 취하십시오.
RCA의 결과에 따라 문제 영역이있는 단계를 판별 할 수 있습니다.
예를 들어 대부분의 RCA 결함이 요구 사항 누락 , 그런 다음 더 많은 검토 또는 연습 세션을 도입하여 요구 사항 수집 / 이해 단계를 개선 할 수 있습니다.
마찬가지로 대부분의 결함이 테스트 미스 , 테스트 프로세스를 개선해야합니다. 다음과 같은 메트릭을 도입 할 수 있습니다. 요구 사항 추적 성 메트릭 , Test Coverage Metrics 또는 검토 프로세스 또는 테스트의 효율성을 향상시킬 것으로 생각되는 다른 단계를 계속 확인할 수 있습니다.
결론
결함을 앉아서 분석하고 제품 및 프로세스 개선에 기여하는 것은 전체 팀의 책임입니다.
이 자습서에서는 RCA에 대한 기본적인 이해, 효율적인 RCA를 수행하기 위해 따라야 할 단계 및 Fishbone 분석 및 5 Why Technique와 같은 다양한 도구를 사용할 수 있습니다. 다음 튜토리얼에서는 다양한 RCA 템플릿, 예제 및 구현 방법에 대한 사용 사례를 다룰 것입니다.