출처: https://m.blog.naver.com/sundol75/30169608034
이번 기고글에서는 프로젝트의 결함관리에 관해 기술해보겠습니다.
“결함”이라는 용어를 ISO 표준에서는 이렇게 정의하고 있습니다.
1) 요구된 기능을 수행하는데 실패의 원인이 되는 우발적인 조건
2) 소프트웨어에서 오류의 명시
결함은 일반적으로 프로젝트를 수행하면서 발생하는 모든 논리적 오류,
프로젝트 내부 관리 프로세스의 위반, 단순한 산출물 오류, 계획 대비 실적의 차이 등
전반적인 관리 차원에서 발생한 문제, 더 나아가서는 프로그램의 Bugs, Error까지
포괄하는 개념으로 이해하시는 것이 편하실 듯합니다.
http://www.flickr.com/photos/seduffel/3699232399/
결함은 당연히 품질과 직결되는 사항입니다.
아마 학부에서 소프트웨어 공학 수업을 들은 분들은 이해하실 겁니다.
결함이 초기에 빨리 수정되지 않으면 단계를 거쳐 가면서
더 많은 결함으로 커진다는 기본 사실을 말입니다.
분석 단계에서 1만큼의 노력(Cost)을 기울여서 수정할 수 있는 결함을 방치하면
나중에 구현/테스트 단계에서는 100(또는 그 이상)만큼의 노력을 들여야
해당 결함과 그로부터 파생된 결함을 수정할 수 있게 된다는 것이 상식 중의 상식이죠.
<정기원, 소프트웨어 프로세스와 품질>
위의 그래프를 보시면, 쉽게 이해가 되셨을 겁니다.
소프트웨어 프로젝트에서(특히 요구사항 정의 단계) 작은 결함을 발견하지 못하고
설계 단계로 넘어가게 될 경우, 이를 설계 단계에서 발견하고 수정하는데 드는
Cost(또는 Effort)는 훨씬 더 커지게 됩니다.
마찬가지로 설계 단계에서도 발견하지 못하고 구현 단계로 넘어가서야
이를 발견한다면, 더 커지겠지요.
그래서 가급적 프로젝트 초기 단계에 결함관리를 하기 위한 프로세스를
프로젝트 팀 내부에 적용해야 하며,
그를 위한 관련 양식 작성 및 배포도 빠를수록 좋습니다.
이는 소프트웨어 프로세스와 품질에 관련된 많은 서적과 논문에서
공통으로 말하는 점입니다.
이 내용에 관심 있으신 분들은 소프트웨어 품질 표준
(IEEE 12207, ISO 9000시리즈, ISO 9126, ISO 14598 등)을
살펴보시고, 요구공학(Requirement Engineering), 그리고 Clean room 프로세스 같은
내용을 공부해보시면 될 것 같습니다.
초반에 각각의 단위시스템별 산출물을 누가 검토하고,
검토한 결과를 어떻게 공유하며(일반적으로 결함관리 대장에 기입),
이에 대한 조치 책임은 누가 지며, 결함조치 결과를 확인하고 완결 처리하는
일련의 활동들의 R&R(Role & Responsibility)이 정의된 후 운영해야 합니다.
실제 프로젝트에서 결함관리를 하는 주요 방법에는
동료 검토, 합동 검토, QA 리뷰 정도가 일반적으로 쓰입니다.
분석/설계 단계에서는 산출물을 검토하고 오류 사항을 발견하여
이를 수정하는 작업이 반복적으로 수행되기 때문에,
검토를 반복해서 자주 수행할수록 산출물의 오류가 감소하게 되는 효과가 있습니다.
단지 일반적으로 국내 프로젝트에서는 분석/설계 단계가
그다지 길지 않은 일정으로 잡히는 경우가 많으며,
특히 설계 단계에서 요구사항을 정제하고 산출물 만들기도 바쁜데,
검토를 여러 번 한다는 것은 현실적으로 매우 어렵죠.
게다가 일반적으로 설계 단계는 산출물의 양이 가장 많은 단계입니다.
요구사항을 구현하기 위한 세부사항을 수립하고,
이를 정비해야 하므로 Agile 계열의 방법론을 사용하는 것이 아니라면,
작성할 산출물이 제일 많은 것이 일반적이죠.
게다가 자주 바뀌는 고객사의 요구사항 역시 결함관리를
어렵게 만드는 요소 중 하나입니다.
http://www.flickr.com/photos/saidosdaconcha/3595949998/
보통 SI 프로젝트에서 조직구성은
“개발자 - PL - 총괄PL(프로젝트가 클 경우) - 사업관리/품질관리 - PM”의
트리 형태로 계층구조를 취하는 것이 보통입니다.
프로젝트에서 중요하지 않은 역할이라는 건 없지만,
그중에서도 PL이 가장 핵심이라는 것은 지난 기고글에서 말씀드렸습니다.
이처럼 Hierarchy한 조직구조에서 PL이 모든 산출물을 다 작성한다는 것은
불가능에 가깝습니다. 그렇게 하기에 양이 너무 많습니다.
그래서 PL이 전체적인 내용의 흐름을 꿰고 있는 상태에서
개발자들에게 산출물 작성을 전달하고
이를 취합 및 정리하는 형태로 업무가 진행됩니다.
각 단위 시스템별 PL들은 완성된 산출물을
프로젝트 내부 프로세스에 의해 정해진 형상규칙에 의거하여 형상서버에 올립니다.
아울러 매주 주간보고 작성 시 이에 대한 보고를 올릴 것입니다.
그러면 프로젝트 QA(프로젝트 규모가 작을 때 사업관리자가 역할을 겸임)가
이를 1차적으로 검토합니다. 그래서 결함이라고 판단되는 사항을
결함관리대장에 기재합니다. 각 PL들은 결함관리대장을 주기적으로 모니터링하여
이 결함을 직접 또는 예하 개발자들에게 지시하여 시정조치를 합니다.
그리고 결함조치가 완료되면 결함관리대장의 상태 항목을
“조치완료”와 같은 형태로 바꿔놓겠죠.
프로젝트 QA는 마찬가지로 결함관리대장을 주기적으로 살펴보고
결함조치가 완료된 건에 관해 확인합니다.
그래서 결함 처리가 완료되면 “확인완료”와 같은 상태로 변경하는 것입니다.
이 프로세스를 간단하게 도식해보면 다음과 같습니다.
<결함관리 프로세스의 예시>
이 구조는 프로젝트에 따라 고객사 업무담당자들이 검토하는 단계가
추가될 수도 있고, 전사 QA의 검토 한 번만 수행하는 것으로 할 수도 있겠죠.
처음에 프로젝트의 특성을 반영하여
어떻게 검토활동을 수행할 것인지 결정하고 이를 실행하는 것입니다.
반복해서 말씀드리고 있지만
여러 단계로 수행하는 것이 품질수준 향상에는 유리합니다.
위 예시에서 보시면 PL이 1차 검토, 총괄 PL이 2차 검토, 프로젝트 QA가 3차 검토,
QA가 4차 검토를 수행하는 것을 확인하실 수 있습니다.
업무가 순환적으로 계속 반복되면서 검토를 수행할 때마다
결함관리 대장에는 검토를 통해 발견된 결함이 계속 쌓여갈 것입니다.
그리고 각 서브시스템의 PL들은 상시로 결함관리대장을 모니터링 하면서
기록된 결함을 조치하도록 개발자들에게 지시하고,
완료된 결함을 확인한 후 보고할 것입니다.
그 내용은 프로젝트 QA나 수행사 품질팀의 전사 QA가 확인한 후
품질보증활동결과서에 기록할 것입니다.
http://www.flickr.com/photos/jvk/6721198/
국내 SI 업체들은 보통 전사 품질관리팀(QA팀) 또는 그에 따르는 조직을 보유한 채로,
회사에서 수행하는 프로젝트들의 품질활동 지원업무를 수행합니다.
전사 품질팀 인력은 소프트웨어공학에서 얘기하는
SEPG(Software Engineering Process Group)의 구실을 하며,
프로젝트 수행팀에서 지원 요청이 들어오거나
단계 말 정기 품질보증활동 시점이 도래하면 프로젝트 수행팀에 파견 나와
품질검토, 관리체계 수립 지원, 감리준비에 대한 지원 등의 다양한 활동을 수행하고
이 결과를 품질보증활동결과서를 작성하는 형태로 PM과 전사품질팀에 보고합니다.
아울러 프로젝트 QA는 수시로 또는 단계 말에 전사 QA가 지원 나오기 전,
내부적인 검토 활동을 수행하고, 전사 QA의 지원을 요청합니다.
프로젝트 결과물의 품질을 높이고 감리에 대응하는 현실적인 목표 달성을 위해
품질보증활동의 수행과 그 결과물의 작성은 필수적입니다.
프로젝트의 규모와 특성에 따라 사업관리자가
프로젝트 QA를 겸임하거나(소형 프로젝트의 경우),
또는 별도의 인력을 프로젝트 QA로 상주시켜
품질관리 업무를 지원하도록 하거나 합니다.
규모가 매우 큰 프로젝트는 사업관리, 품질관리 업무 자체가
한 사람이 하기에는 분량이 광대해서 사업관리팀과 QA팀을 구축해서
프로젝트를 수행하기도 합니다.
결함관리를 위한 수단으로 활용되는 결함관리대장의 예시를 들어
간략하게 설명해보겠습니다.
| 결함 발견 | 결함 조치 | |||||||||||||||
| 결함ID | 발견 단계 |
심 각 도 |
영 향 도 |
처리 우선 순위 |
결함 발견 활동 |
결함 발견 산출물 |
결함 위치 |
발생원인 및 해결방안 |
발견 일자 |
발견자 | 현재 상태 |
처리 담당자 |
처리 예정일 |
처리 완료일 |
결함출처 | 비고 |
| FT-S1-001 | 분석 | 중 | 하 | 3 | 동료검토 | 요구사항 정의서 |
14 P 3~14줄 |
요구사항ID 미부여 항목 발견 | 12-08-02 | 허재 | 결함 조치 확인 완료 |
<st1:personname w:st="on">김유택</st1:personname> | 12-08-05 | 12-08-08 | PJ-S1-ReD-002_ 요구사항정의서_V0.8 |
- 요구사항 정의서 작성중 타 기관(프로농구협회)과의 연계를 위한 인터뷰 일정을 변경할 수 없어, 이를 먼저 수행함으로 인해 결함 처리가 3일 지연되었음. |
| FT-MG-001 | 분석 | 상 | 상 | 1 | 프로젝트QA검토 | 형상관리 계획서 |
2-1장 전체 |
형상관리계획의 R&R이 현재 전혀 정의되지 않음 | 12-08-14 | <st1:personname w:st="on">강동희</st1:personname> | 결함 수정중 |
<st1:personname w:st="on">한기범</st1:personname> | 12-09-01 | PJ-MG-CMP_ 형상관리계획서_V0.6 |
- 현재(9/3) 고객사 업무 담당자의 사업 참여도에 대한 범위가 확정되지 않아 계획 변경 미완료 상태임. | |
| FT-S1-002 | 분석 | 중 | 상 | 2 | QA검토 | 품질보증 계획서 |
8-1장 산출물목록 부분 |
개발단계 및 검토 대상물이 기준산출물 목록과 일치하지 않음 | 12-08-28 | <st1:personname w:st="on">강동희</st1:personname> | 결함 발견 |
<st1:personname w:st="on">한기범</st1:personname> | 12-09-12 | PJ-MG-QAP_ 품질보증계획서_V0.9 |
||
심각도와 영향도 판별에 의한 우선순위를 정하는 방법은
위험/이슈 관리에서도 다룬 적이 있으니 다들 아실 겁니다.
결함을 발견하는 순서에 따라 형상관리계획에서 수립한
결함ID 부여규칙에 따라 ID를 부여합니다.
결함 발견에 속하는 항목에서는 발견자가 기재하고,
결함 조치 항목은 실제 처리 담당자와 사업관리, 품질관리자가
기록과 업데이트를 합니다. 내용이 그다지 어렵지 않으니
예시에 대한 설명은 많이 하지 않겠습니다.
프로젝트가 진행되고 검토를 수행할수록,
결함관리대장 내용과 품질보증활동결과서가 쌓여갈 것입니다.
기본적으로 결함관리를 위한 내용이 많을수록 품질보증활동을 많이 수행했다고
생각하시는 게 맞습니다. 아울러 결함을 탐색하는 과정에서
PL, 사업관리자, QA간의 회의도 종종 수행될 것입니다.
이 회의록 내용도 품질보증활동을 수행한 근거자료가 되니,
내부 회의일지라도 회의록을 작성하여 보관하시는 것이 유리합니다.
엄밀하게는 구현단계 말에 수행하는 단위테스트, 시험 단계에 수행하는 통합테스트,
병행테스트, 사용자 테스트 시에 나오는 오류도 결함입니다만,
소스에 대한 테스트 결과는 별도의 양식을 준비하여 수행하시는 것이 편합니다.
결함관리 대장으로 테스트 결과까지 관리하기에는 결함관리대장에
작성할 수 있는 내용에 한계가 있고, 다양한 테스트 형태와
입력값, 결과값을 비롯한 테스트 케이스와 시나리오 관리가 어렵기 때문입니다.
경험상 산출물에 대한 결함관리는 결함관리대장과
위 예시의 프로세스를 따라 관리하시는 것이 편하고,
테스트는 별도 테스트 양식서, 시나리오 양식서를 가지고 관리하는 것이 편합니다.
이 부분에 대한 내용은 추후 시험 단계에 대한 기고글에서 정리해보도록 하겠습니다.
다음 기고글에서는 분석 단계에서 나오는 일반적인 개발산출물에 관해
이야기해보도록 하겠습니다.
http://xenerdo.com/1085 (제너시스템즈 블로그 참조)
이번 기고글에서는 프로젝트의 결함관리에 관해 기술해보겠습니다.
“결함”이라는 용어를 ISO 표준에서는 이렇게 정의하고 있습니다.
1) 요구된 기능을 수행하는데 실패의 원인이 되는 우발적인 조건
2) 소프트웨어에서 오류의 명시
결함은 일반적으로 프로젝트를 수행하면서 발생하는 모든 논리적 오류,
프로젝트 내부 관리 프로세스의 위반, 단순한 산출물 오류, 계획 대비 실적의 차이 등
전반적인 관리 차원에서 발생한 문제, 더 나아가서는 프로그램의 Bugs, Error까지
포괄하는 개념으로 이해하시는 것이 편하실 듯합니다.
http://www.flickr.com/photos/seduffel/3699232399/
결함은 당연히 품질과 직결되는 사항입니다.
아마 학부에서 소프트웨어 공학 수업을 들은 분들은 이해하실 겁니다.
결함이 초기에 빨리 수정되지 않으면 단계를 거쳐 가면서
더 많은 결함으로 커진다는 기본 사실을 말입니다.
분석 단계에서 1만큼의 노력(Cost)을 기울여서 수정할 수 있는 결함을 방치하면
나중에 구현/테스트 단계에서는 100(또는 그 이상)만큼의 노력을 들여야
해당 결함과 그로부터 파생된 결함을 수정할 수 있게 된다는 것이 상식 중의 상식이죠.
<정기원, 소프트웨어 프로세스와 품질>
위의 그래프를 보시면, 쉽게 이해가 되셨을 겁니다.
소프트웨어 프로젝트에서(특히 요구사항 정의 단계) 작은 결함을 발견하지 못하고
설계 단계로 넘어가게 될 경우, 이를 설계 단계에서 발견하고 수정하는데 드는
Cost(또는 Effort)는 훨씬 더 커지게 됩니다.
마찬가지로 설계 단계에서도 발견하지 못하고 구현 단계로 넘어가서야
이를 발견한다면, 더 커지겠지요.
그래서 가급적 프로젝트 초기 단계에 결함관리를 하기 위한 프로세스를
프로젝트 팀 내부에 적용해야 하며,
그를 위한 관련 양식 작성 및 배포도 빠를수록 좋습니다.
이는 소프트웨어 프로세스와 품질에 관련된 많은 서적과 논문에서
공통으로 말하는 점입니다.
이 내용에 관심 있으신 분들은 소프트웨어 품질 표준
(IEEE 12207, ISO 9000시리즈, ISO 9126, ISO 14598 등)을
살펴보시고, 요구공학(Requirement Engineering), 그리고 Clean room 프로세스 같은
내용을 공부해보시면 될 것 같습니다.
초반에 각각의 단위시스템별 산출물을 누가 검토하고,
검토한 결과를 어떻게 공유하며(일반적으로 결함관리 대장에 기입),
이에 대한 조치 책임은 누가 지며, 결함조치 결과를 확인하고 완결 처리하는
일련의 활동들의 R&R(Role & Responsibility)이 정의된 후 운영해야 합니다.
실제 프로젝트에서 결함관리를 하는 주요 방법에는
동료 검토, 합동 검토, QA 리뷰 정도가 일반적으로 쓰입니다.
분석/설계 단계에서는 산출물을 검토하고 오류 사항을 발견하여
이를 수정하는 작업이 반복적으로 수행되기 때문에,
검토를 반복해서 자주 수행할수록 산출물의 오류가 감소하게 되는 효과가 있습니다.
단지 일반적으로 국내 프로젝트에서는 분석/설계 단계가
그다지 길지 않은 일정으로 잡히는 경우가 많으며,
특히 설계 단계에서 요구사항을 정제하고 산출물 만들기도 바쁜데,
검토를 여러 번 한다는 것은 현실적으로 매우 어렵죠.
게다가 일반적으로 설계 단계는 산출물의 양이 가장 많은 단계입니다.
요구사항을 구현하기 위한 세부사항을 수립하고,
이를 정비해야 하므로 Agile 계열의 방법론을 사용하는 것이 아니라면,
작성할 산출물이 제일 많은 것이 일반적이죠.
게다가 자주 바뀌는 고객사의 요구사항 역시 결함관리를
어렵게 만드는 요소 중 하나입니다.
http://www.flickr.com/photos/saidosdaconcha/3595949998/
보통 SI 프로젝트에서 조직구성은
“개발자 - PL - 총괄PL(프로젝트가 클 경우) - 사업관리/품질관리 - PM”의
트리 형태로 계층구조를 취하는 것이 보통입니다.
프로젝트에서 중요하지 않은 역할이라는 건 없지만,
그중에서도 PL이 가장 핵심이라는 것은 지난 기고글에서 말씀드렸습니다.
이처럼 Hierarchy한 조직구조에서 PL이 모든 산출물을 다 작성한다는 것은
불가능에 가깝습니다. 그렇게 하기에 양이 너무 많습니다.
그래서 PL이 전체적인 내용의 흐름을 꿰고 있는 상태에서
개발자들에게 산출물 작성을 전달하고
이를 취합 및 정리하는 형태로 업무가 진행됩니다.
각 단위 시스템별 PL들은 완성된 산출물을
프로젝트 내부 프로세스에 의해 정해진 형상규칙에 의거하여 형상서버에 올립니다.
아울러 매주 주간보고 작성 시 이에 대한 보고를 올릴 것입니다.
그러면 프로젝트 QA(프로젝트 규모가 작을 때 사업관리자가 역할을 겸임)가
이를 1차적으로 검토합니다. 그래서 결함이라고 판단되는 사항을
결함관리대장에 기재합니다. 각 PL들은 결함관리대장을 주기적으로 모니터링하여
이 결함을 직접 또는 예하 개발자들에게 지시하여 시정조치를 합니다.
그리고 결함조치가 완료되면 결함관리대장의 상태 항목을
“조치완료”와 같은 형태로 바꿔놓겠죠.
프로젝트 QA는 마찬가지로 결함관리대장을 주기적으로 살펴보고
결함조치가 완료된 건에 관해 확인합니다.
그래서 결함 처리가 완료되면 “확인완료”와 같은 상태로 변경하는 것입니다.
이 프로세스를 간단하게 도식해보면 다음과 같습니다.
<결함관리 프로세스의 예시>
이 구조는 프로젝트에 따라 고객사 업무담당자들이 검토하는 단계가
추가될 수도 있고, 전사 QA의 검토 한 번만 수행하는 것으로 할 수도 있겠죠.
처음에 프로젝트의 특성을 반영하여
어떻게 검토활동을 수행할 것인지 결정하고 이를 실행하는 것입니다.
반복해서 말씀드리고 있지만
여러 단계로 수행하는 것이 품질수준 향상에는 유리합니다.
위 예시에서 보시면 PL이 1차 검토, 총괄 PL이 2차 검토, 프로젝트 QA가 3차 검토,
QA가 4차 검토를 수행하는 것을 확인하실 수 있습니다.
업무가 순환적으로 계속 반복되면서 검토를 수행할 때마다
결함관리 대장에는 검토를 통해 발견된 결함이 계속 쌓여갈 것입니다.
그리고 각 서브시스템의 PL들은 상시로 결함관리대장을 모니터링 하면서
기록된 결함을 조치하도록 개발자들에게 지시하고,
완료된 결함을 확인한 후 보고할 것입니다.
그 내용은 프로젝트 QA나 수행사 품질팀의 전사 QA가 확인한 후
품질보증활동결과서에 기록할 것입니다.
http://www.flickr.com/photos/jvk/6721198/
국내 SI 업체들은 보통 전사 품질관리팀(QA팀) 또는 그에 따르는 조직을 보유한 채로,
회사에서 수행하는 프로젝트들의 품질활동 지원업무를 수행합니다.
전사 품질팀 인력은 소프트웨어공학에서 얘기하는
SEPG(Software Engineering Process Group)의 구실을 하며,
프로젝트 수행팀에서 지원 요청이 들어오거나
단계 말 정기 품질보증활동 시점이 도래하면 프로젝트 수행팀에 파견 나와
품질검토, 관리체계 수립 지원, 감리준비에 대한 지원 등의 다양한 활동을 수행하고
이 결과를 품질보증활동결과서를 작성하는 형태로 PM과 전사품질팀에 보고합니다.
아울러 프로젝트 QA는 수시로 또는 단계 말에 전사 QA가 지원 나오기 전,
내부적인 검토 활동을 수행하고, 전사 QA의 지원을 요청합니다.
프로젝트 결과물의 품질을 높이고 감리에 대응하는 현실적인 목표 달성을 위해
품질보증활동의 수행과 그 결과물의 작성은 필수적입니다.
프로젝트의 규모와 특성에 따라 사업관리자가
프로젝트 QA를 겸임하거나(소형 프로젝트의 경우),
또는 별도의 인력을 프로젝트 QA로 상주시켜
품질관리 업무를 지원하도록 하거나 합니다.
규모가 매우 큰 프로젝트는 사업관리, 품질관리 업무 자체가
한 사람이 하기에는 분량이 광대해서 사업관리팀과 QA팀을 구축해서
프로젝트를 수행하기도 합니다.
결함관리를 위한 수단으로 활용되는 결함관리대장의 예시를 들어
간략하게 설명해보겠습니다.
| 결함 발견 | 결함 조치 | |||||||||||||||
| 결함ID | 발견 단계 |
심 각 도 |
영 향 도 |
처리 우선 순위 |
결함 발견 활동 |
결함 발견 산출물 |
결함 위치 |
발생원인 및 해결방안 |
발견 일자 |
발견자 | 현재 상태 |
처리 담당자 |
처리 예정일 |
처리 완료일 |
결함출처 | 비고 |
| FT-S1-001 | 분석 | 중 | 하 | 3 | 동료검토 | 요구사항 정의서 |
14 P 3~14줄 |
요구사항ID 미부여 항목 발견 | 12-08-02 | 허재 | 결함 조치 확인 완료 |
<st1:personname w:st="on">김유택</st1:personname> | 12-08-05 | 12-08-08 | PJ-S1-ReD-002_ 요구사항정의서_V0.8 |
- 요구사항 정의서 작성중 타 기관(프로농구협회)과의 연계를 위한 인터뷰 일정을 변경할 수 없어, 이를 먼저 수행함으로 인해 결함 처리가 3일 지연되었음. |
| FT-MG-001 | 분석 | 상 | 상 | 1 | 프로젝트QA검토 | 형상관리 계획서 |
2-1장 전체 |
형상관리계획의 R&R이 현재 전혀 정의되지 않음 | 12-08-14 | <st1:personname w:st="on">강동희</st1:personname> | 결함 수정중 |
<st1:personname w:st="on">한기범</st1:personname> | 12-09-01 | PJ-MG-CMP_ 형상관리계획서_V0.6 |
- 현재(9/3) 고객사 업무 담당자의 사업 참여도에 대한 범위가 확정되지 않아 계획 변경 미완료 상태임. | |
| FT-S1-002 | 분석 | 중 | 상 | 2 | QA검토 | 품질보증 계획서 |
8-1장 산출물목록 부분 |
개발단계 및 검토 대상물이 기준산출물 목록과 일치하지 않음 | 12-08-28 | <st1:personname w:st="on">강동희</st1:personname> | 결함 발견 |
<st1:personname w:st="on">한기범</st1:personname> | 12-09-12 | PJ-MG-QAP_ 품질보증계획서_V0.9 |
||
심각도와 영향도 판별에 의한 우선순위를 정하는 방법은
위험/이슈 관리에서도 다룬 적이 있으니 다들 아실 겁니다.
결함을 발견하는 순서에 따라 형상관리계획에서 수립한
결함ID 부여규칙에 따라 ID를 부여합니다.
결함 발견에 속하는 항목에서는 발견자가 기재하고,
결함 조치 항목은 실제 처리 담당자와 사업관리, 품질관리자가
기록과 업데이트를 합니다. 내용이 그다지 어렵지 않으니
예시에 대한 설명은 많이 하지 않겠습니다.
프로젝트가 진행되고 검토를 수행할수록,
결함관리대장 내용과 품질보증활동결과서가 쌓여갈 것입니다.
기본적으로 결함관리를 위한 내용이 많을수록 품질보증활동을 많이 수행했다고
생각하시는 게 맞습니다. 아울러 결함을 탐색하는 과정에서
PL, 사업관리자, QA간의 회의도 종종 수행될 것입니다.
이 회의록 내용도 품질보증활동을 수행한 근거자료가 되니,
내부 회의일지라도 회의록을 작성하여 보관하시는 것이 유리합니다.
엄밀하게는 구현단계 말에 수행하는 단위테스트, 시험 단계에 수행하는 통합테스트,
병행테스트, 사용자 테스트 시에 나오는 오류도 결함입니다만,
소스에 대한 테스트 결과는 별도의 양식을 준비하여 수행하시는 것이 편합니다.
결함관리 대장으로 테스트 결과까지 관리하기에는 결함관리대장에
작성할 수 있는 내용에 한계가 있고, 다양한 테스트 형태와
입력값, 결과값을 비롯한 테스트 케이스와 시나리오 관리가 어렵기 때문입니다.
경험상 산출물에 대한 결함관리는 결함관리대장과
위 예시의 프로세스를 따라 관리하시는 것이 편하고,
테스트는 별도 테스트 양식서, 시나리오 양식서를 가지고 관리하는 것이 편합니다.
이 부분에 대한 내용은 추후 시험 단계에 대한 기고글에서 정리해보도록 하겠습니다.
다음 기고글에서는 분석 단계에서 나오는 일반적인 개발산출물에 관해
이야기해보도록 하겠습니다.
http://xenerdo.com/1085 (제너시스템즈 블로그 참조)
이번 기고글에서는 프로젝트의 결함관리에 관해 기술해보겠습니다.
“결함”이라는 용어를 ISO 표준에서는 이렇게 정의하고 있습니다.
1) 요구된 기능을 수행하는데 실패의 원인이 되는 우발적인 조건
2) 소프트웨어에서 오류의 명시
결함은 일반적으로 프로젝트를 수행하면서 발생하는 모든 논리적 오류,
프로젝트 내부 관리 프로세스의 위반, 단순한 산출물 오류, 계획 대비 실적의 차이 등
전반적인 관리 차원에서 발생한 문제, 더 나아가서는 프로그램의 Bugs, Error까지
포괄하는 개념으로 이해하시는 것이 편하실 듯합니다.
http://www.flickr.com/photos/seduffel/3699232399/
결함은 당연히 품질과 직결되는 사항입니다.
아마 학부에서 소프트웨어 공학 수업을 들은 분들은 이해하실 겁니다.
결함이 초기에 빨리 수정되지 않으면 단계를 거쳐 가면서
더 많은 결함으로 커진다는 기본 사실을 말입니다.
분석 단계에서 1만큼의 노력(Cost)을 기울여서 수정할 수 있는 결함을 방치하면
나중에 구현/테스트 단계에서는 100(또는 그 이상)만큼의 노력을 들여야
해당 결함과 그로부터 파생된 결함을 수정할 수 있게 된다는 것이 상식 중의 상식이죠.
<정기원, 소프트웨어 프로세스와 품질>
위의 그래프를 보시면, 쉽게 이해가 되셨을 겁니다.
소프트웨어 프로젝트에서(특히 요구사항 정의 단계) 작은 결함을 발견하지 못하고
설계 단계로 넘어가게 될 경우, 이를 설계 단계에서 발견하고 수정하는데 드는
Cost(또는 Effort)는 훨씬 더 커지게 됩니다.
마찬가지로 설계 단계에서도 발견하지 못하고 구현 단계로 넘어가서야
이를 발견한다면, 더 커지겠지요.
그래서 가급적 프로젝트 초기 단계에 결함관리를 하기 위한 프로세스를
프로젝트 팀 내부에 적용해야 하며,
그를 위한 관련 양식 작성 및 배포도 빠를수록 좋습니다.
이는 소프트웨어 프로세스와 품질에 관련된 많은 서적과 논문에서
공통으로 말하는 점입니다.
이 내용에 관심 있으신 분들은 소프트웨어 품질 표준
(IEEE 12207, ISO 9000시리즈, ISO 9126, ISO 14598 등)을
살펴보시고, 요구공학(Requirement Engineering), 그리고 Clean room 프로세스 같은
내용을 공부해보시면 될 것 같습니다.
초반에 각각의 단위시스템별 산출물을 누가 검토하고,
검토한 결과를 어떻게 공유하며(일반적으로 결함관리 대장에 기입),
이에 대한 조치 책임은 누가 지며, 결함조치 결과를 확인하고 완결 처리하는
일련의 활동들의 R&R(Role & Responsibility)이 정의된 후 운영해야 합니다.
실제 프로젝트에서 결함관리를 하는 주요 방법에는
동료 검토, 합동 검토, QA 리뷰 정도가 일반적으로 쓰입니다.
분석/설계 단계에서는 산출물을 검토하고 오류 사항을 발견하여
이를 수정하는 작업이 반복적으로 수행되기 때문에,
검토를 반복해서 자주 수행할수록 산출물의 오류가 감소하게 되는 효과가 있습니다.
단지 일반적으로 국내 프로젝트에서는 분석/설계 단계가
그다지 길지 않은 일정으로 잡히는 경우가 많으며,
특히 설계 단계에서 요구사항을 정제하고 산출물 만들기도 바쁜데,
검토를 여러 번 한다는 것은 현실적으로 매우 어렵죠.
게다가 일반적으로 설계 단계는 산출물의 양이 가장 많은 단계입니다.
요구사항을 구현하기 위한 세부사항을 수립하고,
이를 정비해야 하므로 Agile 계열의 방법론을 사용하는 것이 아니라면,
작성할 산출물이 제일 많은 것이 일반적이죠.
게다가 자주 바뀌는 고객사의 요구사항 역시 결함관리를
어렵게 만드는 요소 중 하나입니다.
http://www.flickr.com/photos/saidosdaconcha/3595949998/
보통 SI 프로젝트에서 조직구성은
“개발자 - PL - 총괄PL(프로젝트가 클 경우) - 사업관리/품질관리 - PM”의
트리 형태로 계층구조를 취하는 것이 보통입니다.
프로젝트에서 중요하지 않은 역할이라는 건 없지만,
그중에서도 PL이 가장 핵심이라는 것은 지난 기고글에서 말씀드렸습니다.
이처럼 Hierarchy한 조직구조에서 PL이 모든 산출물을 다 작성한다는 것은
불가능에 가깝습니다. 그렇게 하기에 양이 너무 많습니다.
그래서 PL이 전체적인 내용의 흐름을 꿰고 있는 상태에서
개발자들에게 산출물 작성을 전달하고
이를 취합 및 정리하는 형태로 업무가 진행됩니다.
각 단위 시스템별 PL들은 완성된 산출물을
프로젝트 내부 프로세스에 의해 정해진 형상규칙에 의거하여 형상서버에 올립니다.
아울러 매주 주간보고 작성 시 이에 대한 보고를 올릴 것입니다.
그러면 프로젝트 QA(프로젝트 규모가 작을 때 사업관리자가 역할을 겸임)가
이를 1차적으로 검토합니다. 그래서 결함이라고 판단되는 사항을
결함관리대장에 기재합니다. 각 PL들은 결함관리대장을 주기적으로 모니터링하여
이 결함을 직접 또는 예하 개발자들에게 지시하여 시정조치를 합니다.
그리고 결함조치가 완료되면 결함관리대장의 상태 항목을
“조치완료”와 같은 형태로 바꿔놓겠죠.
프로젝트 QA는 마찬가지로 결함관리대장을 주기적으로 살펴보고
결함조치가 완료된 건에 관해 확인합니다.
그래서 결함 처리가 완료되면 “확인완료”와 같은 상태로 변경하는 것입니다.
이 프로세스를 간단하게 도식해보면 다음과 같습니다.
<결함관리 프로세스의 예시>
이 구조는 프로젝트에 따라 고객사 업무담당자들이 검토하는 단계가
추가될 수도 있고, 전사 QA의 검토 한 번만 수행하는 것으로 할 수도 있겠죠.
처음에 프로젝트의 특성을 반영하여
어떻게 검토활동을 수행할 것인지 결정하고 이를 실행하는 것입니다.
반복해서 말씀드리고 있지만
여러 단계로 수행하는 것이 품질수준 향상에는 유리합니다.
위 예시에서 보시면 PL이 1차 검토, 총괄 PL이 2차 검토, 프로젝트 QA가 3차 검토,
QA가 4차 검토를 수행하는 것을 확인하실 수 있습니다.
업무가 순환적으로 계속 반복되면서 검토를 수행할 때마다
결함관리 대장에는 검토를 통해 발견된 결함이 계속 쌓여갈 것입니다.
그리고 각 서브시스템의 PL들은 상시로 결함관리대장을 모니터링 하면서
기록된 결함을 조치하도록 개발자들에게 지시하고,
완료된 결함을 확인한 후 보고할 것입니다.
그 내용은 프로젝트 QA나 수행사 품질팀의 전사 QA가 확인한 후
품질보증활동결과서에 기록할 것입니다.
http://www.flickr.com/photos/jvk/6721198/
국내 SI 업체들은 보통 전사 품질관리팀(QA팀) 또는 그에 따르는 조직을 보유한 채로,
회사에서 수행하는 프로젝트들의 품질활동 지원업무를 수행합니다.
전사 품질팀 인력은 소프트웨어공학에서 얘기하는
SEPG(Software Engineering Process Group)의 구실을 하며,
프로젝트 수행팀에서 지원 요청이 들어오거나
단계 말 정기 품질보증활동 시점이 도래하면 프로젝트 수행팀에 파견 나와
품질검토, 관리체계 수립 지원, 감리준비에 대한 지원 등의 다양한 활동을 수행하고
이 결과를 품질보증활동결과서를 작성하는 형태로 PM과 전사품질팀에 보고합니다.
아울러 프로젝트 QA는 수시로 또는 단계 말에 전사 QA가 지원 나오기 전,
내부적인 검토 활동을 수행하고, 전사 QA의 지원을 요청합니다.
프로젝트 결과물의 품질을 높이고 감리에 대응하는 현실적인 목표 달성을 위해
품질보증활동의 수행과 그 결과물의 작성은 필수적입니다.
프로젝트의 규모와 특성에 따라 사업관리자가
프로젝트 QA를 겸임하거나(소형 프로젝트의 경우),
또는 별도의 인력을 프로젝트 QA로 상주시켜
품질관리 업무를 지원하도록 하거나 합니다.
규모가 매우 큰 프로젝트는 사업관리, 품질관리 업무 자체가
한 사람이 하기에는 분량이 광대해서 사업관리팀과 QA팀을 구축해서
프로젝트를 수행하기도 합니다.
결함관리를 위한 수단으로 활용되는 결함관리대장의 예시를 들어
간략하게 설명해보겠습니다.
| 결함 발견 | 결함 조치 | |||||||||||||||
| 결함ID | 발견 단계 |
심 각 도 |
영 향 도 |
처리 우선 순위 |
결함 발견 활동 |
결함 발견 산출물 |
결함 위치 |
발생원인 및 해결방안 |
발견 일자 |
발견자 | 현재 상태 |
처리 담당자 |
처리 예정일 |
처리 완료일 |
결함출처 | 비고 |
| FT-S1-001 | 분석 | 중 | 하 | 3 | 동료검토 | 요구사항 정의서 |
14 P 3~14줄 |
요구사항ID 미부여 항목 발견 | 12-08-02 | 허재 | 결함 조치 확인 완료 |
<st1:personname w:st="on">김유택</st1:personname> | 12-08-05 | 12-08-08 | PJ-S1-ReD-002_ 요구사항정의서_V0.8 |
- 요구사항 정의서 작성중 타 기관(프로농구협회)과의 연계를 위한 인터뷰 일정을 변경할 수 없어, 이를 먼저 수행함으로 인해 결함 처리가 3일 지연되었음. |
| FT-MG-001 | 분석 | 상 | 상 | 1 | 프로젝트QA검토 | 형상관리 계획서 |
2-1장 전체 |
형상관리계획의 R&R이 현재 전혀 정의되지 않음 | 12-08-14 | <st1:personname w:st="on">강동희</st1:personname> | 결함 수정중 |
<st1:personname w:st="on">한기범</st1:personname> | 12-09-01 | PJ-MG-CMP_ 형상관리계획서_V0.6 |
- 현재(9/3) 고객사 업무 담당자의 사업 참여도에 대한 범위가 확정되지 않아 계획 변경 미완료 상태임. | |
| FT-S1-002 | 분석 | 중 | 상 | 2 | QA검토 | 품질보증 계획서 |
8-1장 산출물목록 부분 |
개발단계 및 검토 대상물이 기준산출물 목록과 일치하지 않음 | 12-08-28 | <st1:personname w:st="on">강동희</st1:personname> | 결함 발견 |
<st1:personname w:st="on">한기범</st1:personname> | 12-09-12 | PJ-MG-QAP_ 품질보증계획서_V0.9 |
||
심각도와 영향도 판별에 의한 우선순위를 정하는 방법은
위험/이슈 관리에서도 다룬 적이 있으니 다들 아실 겁니다.
결함을 발견하는 순서에 따라 형상관리계획에서 수립한
결함ID 부여규칙에 따라 ID를 부여합니다.
결함 발견에 속하는 항목에서는 발견자가 기재하고,
결함 조치 항목은 실제 처리 담당자와 사업관리, 품질관리자가
기록과 업데이트를 합니다. 내용이 그다지 어렵지 않으니
예시에 대한 설명은 많이 하지 않겠습니다.
프로젝트가 진행되고 검토를 수행할수록,
결함관리대장 내용과 품질보증활동결과서가 쌓여갈 것입니다.
기본적으로 결함관리를 위한 내용이 많을수록 품질보증활동을 많이 수행했다고
생각하시는 게 맞습니다. 아울러 결함을 탐색하는 과정에서
PL, 사업관리자, QA간의 회의도 종종 수행될 것입니다.
이 회의록 내용도 품질보증활동을 수행한 근거자료가 되니,
내부 회의일지라도 회의록을 작성하여 보관하시는 것이 유리합니다.
엄밀하게는 구현단계 말에 수행하는 단위테스트, 시험 단계에 수행하는 통합테스트,
병행테스트, 사용자 테스트 시에 나오는 오류도 결함입니다만,
소스에 대한 테스트 결과는 별도의 양식을 준비하여 수행하시는 것이 편합니다.
결함관리 대장으로 테스트 결과까지 관리하기에는 결함관리대장에
작성할 수 있는 내용에 한계가 있고, 다양한 테스트 형태와
입력값, 결과값을 비롯한 테스트 케이스와 시나리오 관리가 어렵기 때문입니다.
경험상 산출물에 대한 결함관리는 결함관리대장과
위 예시의 프로세스를 따라 관리하시는 것이 편하고,
테스트는 별도 테스트 양식서, 시나리오 양식서를 가지고 관리하는 것이 편합니다.
이 부분에 대한 내용은 추후 시험 단계에 대한 기고글에서 정리해보도록 하겠습니다.
다음 기고글에서는 분석 단계에서 나오는 일반적인 개발산출물에 관해
이야기해보도록 하겠습니다.
http://xenerdo.com/1085 (제너시스템즈 블로그 참조)
이번 기고글에서는 프로젝트의 결함관리에 관해 기술해보겠습니다.
“결함”이라는 용어를 ISO 표준에서는 이렇게 정의하고 있습니다.
1) 요구된 기능을 수행하는데 실패의 원인이 되는 우발적인 조건
2) 소프트웨어에서 오류의 명시
결함은 일반적으로 프로젝트를 수행하면서 발생하는 모든 논리적 오류,
프로젝트 내부 관리 프로세스의 위반, 단순한 산출물 오류, 계획 대비 실적의 차이 등
전반적인 관리 차원에서 발생한 문제, 더 나아가서는 프로그램의 Bugs, Error까지
포괄하는 개념으로 이해하시는 것이 편하실 듯합니다.
http://www.flickr.com/photos/seduffel/3699232399/
결함은 당연히 품질과 직결되는 사항입니다.
아마 학부에서 소프트웨어 공학 수업을 들은 분들은 이해하실 겁니다.
결함이 초기에 빨리 수정되지 않으면 단계를 거쳐 가면서
더 많은 결함으로 커진다는 기본 사실을 말입니다.
분석 단계에서 1만큼의 노력(Cost)을 기울여서 수정할 수 있는 결함을 방치하면
나중에 구현/테스트 단계에서는 100(또는 그 이상)만큼의 노력을 들여야
해당 결함과 그로부터 파생된 결함을 수정할 수 있게 된다는 것이 상식 중의 상식이죠.
<정기원, 소프트웨어 프로세스와 품질>
위의 그래프를 보시면, 쉽게 이해가 되셨을 겁니다.
소프트웨어 프로젝트에서(특히 요구사항 정의 단계) 작은 결함을 발견하지 못하고
설계 단계로 넘어가게 될 경우, 이를 설계 단계에서 발견하고 수정하는데 드는
Cost(또는 Effort)는 훨씬 더 커지게 됩니다.
마찬가지로 설계 단계에서도 발견하지 못하고 구현 단계로 넘어가서야
이를 발견한다면, 더 커지겠지요.
그래서 가급적 프로젝트 초기 단계에 결함관리를 하기 위한 프로세스를
프로젝트 팀 내부에 적용해야 하며,
그를 위한 관련 양식 작성 및 배포도 빠를수록 좋습니다.
이는 소프트웨어 프로세스와 품질에 관련된 많은 서적과 논문에서
공통으로 말하는 점입니다.
이 내용에 관심 있으신 분들은 소프트웨어 품질 표준
(IEEE 12207, ISO 9000시리즈, ISO 9126, ISO 14598 등)을
살펴보시고, 요구공학(Requirement Engineering), 그리고 Clean room 프로세스 같은
내용을 공부해보시면 될 것 같습니다.
초반에 각각의 단위시스템별 산출물을 누가 검토하고,
검토한 결과를 어떻게 공유하며(일반적으로 결함관리 대장에 기입),
이에 대한 조치 책임은 누가 지며, 결함조치 결과를 확인하고 완결 처리하는
일련의 활동들의 R&R(Role & Responsibility)이 정의된 후 운영해야 합니다.
실제 프로젝트에서 결함관리를 하는 주요 방법에는
동료 검토, 합동 검토, QA 리뷰 정도가 일반적으로 쓰입니다.
분석/설계 단계에서는 산출물을 검토하고 오류 사항을 발견하여
이를 수정하는 작업이 반복적으로 수행되기 때문에,
검토를 반복해서 자주 수행할수록 산출물의 오류가 감소하게 되는 효과가 있습니다.
단지 일반적으로 국내 프로젝트에서는 분석/설계 단계가
그다지 길지 않은 일정으로 잡히는 경우가 많으며,
특히 설계 단계에서 요구사항을 정제하고 산출물 만들기도 바쁜데,
검토를 여러 번 한다는 것은 현실적으로 매우 어렵죠.
게다가 일반적으로 설계 단계는 산출물의 양이 가장 많은 단계입니다.
요구사항을 구현하기 위한 세부사항을 수립하고,
이를 정비해야 하므로 Agile 계열의 방법론을 사용하는 것이 아니라면,
작성할 산출물이 제일 많은 것이 일반적이죠.
게다가 자주 바뀌는 고객사의 요구사항 역시 결함관리를
어렵게 만드는 요소 중 하나입니다.
http://www.flickr.com/photos/saidosdaconcha/3595949998/
보통 SI 프로젝트에서 조직구성은
“개발자 - PL - 총괄PL(프로젝트가 클 경우) - 사업관리/품질관리 - PM”의
트리 형태로 계층구조를 취하는 것이 보통입니다.
프로젝트에서 중요하지 않은 역할이라는 건 없지만,
그중에서도 PL이 가장 핵심이라는 것은 지난 기고글에서 말씀드렸습니다.
이처럼 Hierarchy한 조직구조에서 PL이 모든 산출물을 다 작성한다는 것은
불가능에 가깝습니다. 그렇게 하기에 양이 너무 많습니다.
그래서 PL이 전체적인 내용의 흐름을 꿰고 있는 상태에서
개발자들에게 산출물 작성을 전달하고
이를 취합 및 정리하는 형태로 업무가 진행됩니다.
각 단위 시스템별 PL들은 완성된 산출물을
프로젝트 내부 프로세스에 의해 정해진 형상규칙에 의거하여 형상서버에 올립니다.
아울러 매주 주간보고 작성 시 이에 대한 보고를 올릴 것입니다.
그러면 프로젝트 QA(프로젝트 규모가 작을 때 사업관리자가 역할을 겸임)가
이를 1차적으로 검토합니다. 그래서 결함이라고 판단되는 사항을
결함관리대장에 기재합니다. 각 PL들은 결함관리대장을 주기적으로 모니터링하여
이 결함을 직접 또는 예하 개발자들에게 지시하여 시정조치를 합니다.
그리고 결함조치가 완료되면 결함관리대장의 상태 항목을
“조치완료”와 같은 형태로 바꿔놓겠죠.
프로젝트 QA는 마찬가지로 결함관리대장을 주기적으로 살펴보고
결함조치가 완료된 건에 관해 확인합니다.
그래서 결함 처리가 완료되면 “확인완료”와 같은 상태로 변경하는 것입니다.
이 프로세스를 간단하게 도식해보면 다음과 같습니다.
<결함관리 프로세스의 예시>
이 구조는 프로젝트에 따라 고객사 업무담당자들이 검토하는 단계가
추가될 수도 있고, 전사 QA의 검토 한 번만 수행하는 것으로 할 수도 있겠죠.
처음에 프로젝트의 특성을 반영하여
어떻게 검토활동을 수행할 것인지 결정하고 이를 실행하는 것입니다.
반복해서 말씀드리고 있지만
여러 단계로 수행하는 것이 품질수준 향상에는 유리합니다.
위 예시에서 보시면 PL이 1차 검토, 총괄 PL이 2차 검토, 프로젝트 QA가 3차 검토,
QA가 4차 검토를 수행하는 것을 확인하실 수 있습니다.
업무가 순환적으로 계속 반복되면서 검토를 수행할 때마다
결함관리 대장에는 검토를 통해 발견된 결함이 계속 쌓여갈 것입니다.
그리고 각 서브시스템의 PL들은 상시로 결함관리대장을 모니터링 하면서
기록된 결함을 조치하도록 개발자들에게 지시하고,
완료된 결함을 확인한 후 보고할 것입니다.
그 내용은 프로젝트 QA나 수행사 품질팀의 전사 QA가 확인한 후
품질보증활동결과서에 기록할 것입니다.
http://www.flickr.com/photos/jvk/6721198/
국내 SI 업체들은 보통 전사 품질관리팀(QA팀) 또는 그에 따르는 조직을 보유한 채로,
회사에서 수행하는 프로젝트들의 품질활동 지원업무를 수행합니다.
전사 품질팀 인력은 소프트웨어공학에서 얘기하는
SEPG(Software Engineering Process Group)의 구실을 하며,
프로젝트 수행팀에서 지원 요청이 들어오거나
단계 말 정기 품질보증활동 시점이 도래하면 프로젝트 수행팀에 파견 나와
품질검토, 관리체계 수립 지원, 감리준비에 대한 지원 등의 다양한 활동을 수행하고
이 결과를 품질보증활동결과서를 작성하는 형태로 PM과 전사품질팀에 보고합니다.
아울러 프로젝트 QA는 수시로 또는 단계 말에 전사 QA가 지원 나오기 전,
내부적인 검토 활동을 수행하고, 전사 QA의 지원을 요청합니다.
프로젝트 결과물의 품질을 높이고 감리에 대응하는 현실적인 목표 달성을 위해
품질보증활동의 수행과 그 결과물의 작성은 필수적입니다.
프로젝트의 규모와 특성에 따라 사업관리자가
프로젝트 QA를 겸임하거나(소형 프로젝트의 경우),
또는 별도의 인력을 프로젝트 QA로 상주시켜
품질관리 업무를 지원하도록 하거나 합니다.
규모가 매우 큰 프로젝트는 사업관리, 품질관리 업무 자체가
한 사람이 하기에는 분량이 광대해서 사업관리팀과 QA팀을 구축해서
프로젝트를 수행하기도 합니다.
결함관리를 위한 수단으로 활용되는 결함관리대장의 예시를 들어
간략하게 설명해보겠습니다.
| 결함 발견 | 결함 조치 | |||||||||||||||
| 결함ID | 발견 단계 |
심 각 도 |
영 향 도 |
처리 우선 순위 |
결함 발견 활동 |
결함 발견 산출물 |
결함 위치 |
발생원인 및 해결방안 |
발견 일자 |
발견자 | 현재 상태 |
처리 담당자 |
처리 예정일 |
처리 완료일 |
결함출처 | 비고 |
| FT-S1-001 | 분석 | 중 | 하 | 3 | 동료검토 | 요구사항 정의서 |
14 P 3~14줄 |
요구사항ID 미부여 항목 발견 | 12-08-02 | 허재 | 결함 조치 확인 완료 |
<st1:personname w:st="on">김유택</st1:personname> | 12-08-05 | 12-08-08 | PJ-S1-ReD-002_ 요구사항정의서_V0.8 |
- 요구사항 정의서 작성중 타 기관(프로농구협회)과의 연계를 위한 인터뷰 일정을 변경할 수 없어, 이를 먼저 수행함으로 인해 결함 처리가 3일 지연되었음. |
| FT-MG-001 | 분석 | 상 | 상 | 1 | 프로젝트QA검토 | 형상관리 계획서 |
2-1장 전체 |
형상관리계획의 R&R이 현재 전혀 정의되지 않음 | 12-08-14 | <st1:personname w:st="on">강동희</st1:personname> | 결함 수정중 |
<st1:personname w:st="on">한기범</st1:personname> | 12-09-01 | PJ-MG-CMP_ 형상관리계획서_V0.6 |
- 현재(9/3) 고객사 업무 담당자의 사업 참여도에 대한 범위가 확정되지 않아 계획 변경 미완료 상태임. | |
| FT-S1-002 | 분석 | 중 | 상 | 2 | QA검토 | 품질보증 계획서 |
8-1장 산출물목록 부분 |
개발단계 및 검토 대상물이 기준산출물 목록과 일치하지 않음 | 12-08-28 | <st1:personname w:st="on">강동희</st1:personname> | 결함 발견 |
<st1:personname w:st="on">한기범</st1:personname> | 12-09-12 | PJ-MG-QAP_ 품질보증계획서_V0.9 |
||
심각도와 영향도 판별에 의한 우선순위를 정하는 방법은
위험/이슈 관리에서도 다룬 적이 있으니 다들 아실 겁니다.
결함을 발견하는 순서에 따라 형상관리계획에서 수립한
결함ID 부여규칙에 따라 ID를 부여합니다.
결함 발견에 속하는 항목에서는 발견자가 기재하고,
결함 조치 항목은 실제 처리 담당자와 사업관리, 품질관리자가
기록과 업데이트를 합니다. 내용이 그다지 어렵지 않으니
예시에 대한 설명은 많이 하지 않겠습니다.
프로젝트가 진행되고 검토를 수행할수록,
결함관리대장 내용과 품질보증활동결과서가 쌓여갈 것입니다.
기본적으로 결함관리를 위한 내용이 많을수록 품질보증활동을 많이 수행했다고
생각하시는 게 맞습니다. 아울러 결함을 탐색하는 과정에서
PL, 사업관리자, QA간의 회의도 종종 수행될 것입니다.
이 회의록 내용도 품질보증활동을 수행한 근거자료가 되니,
내부 회의일지라도 회의록을 작성하여 보관하시는 것이 유리합니다.
엄밀하게는 구현단계 말에 수행하는 단위테스트, 시험 단계에 수행하는 통합테스트,
병행테스트, 사용자 테스트 시에 나오는 오류도 결함입니다만,
소스에 대한 테스트 결과는 별도의 양식을 준비하여 수행하시는 것이 편합니다.
결함관리 대장으로 테스트 결과까지 관리하기에는 결함관리대장에
작성할 수 있는 내용에 한계가 있고, 다양한 테스트 형태와
입력값, 결과값을 비롯한 테스트 케이스와 시나리오 관리가 어렵기 때문입니다.
경험상 산출물에 대한 결함관리는 결함관리대장과
위 예시의 프로세스를 따라 관리하시는 것이 편하고,
테스트는 별도 테스트 양식서, 시나리오 양식서를 가지고 관리하는 것이 편합니다.
이 부분에 대한 내용은 추후 시험 단계에 대한 기고글에서 정리해보도록 하겠습니다.
다음 기고글에서는 분석 단계에서 나오는 일반적인 개발산출물에 관해
이야기해보도록 하겠습니다.
http://xenerdo.com/1085 (제너시스템즈 블로그 참조)
이번 기고글에서는 프로젝트의 결함관리에 관해 기술해보겠습니다.
“결함”이라는 용어를 ISO 표준에서는 이렇게 정의하고 있습니다.
1) 요구된 기능을 수행하는데 실패의 원인이 되는 우발적인 조건
2) 소프트웨어에서 오류의 명시
결함은 일반적으로 프로젝트를 수행하면서 발생하는 모든 논리적 오류,
프로젝트 내부 관리 프로세스의 위반, 단순한 산출물 오류, 계획 대비 실적의 차이 등
전반적인 관리 차원에서 발생한 문제, 더 나아가서는 프로그램의 Bugs, Error까지
포괄하는 개념으로 이해하시는 것이 편하실 듯합니다.
http://www.flickr.com/photos/seduffel/3699232399/
결함은 당연히 품질과 직결되는 사항입니다.
아마 학부에서 소프트웨어 공학 수업을 들은 분들은 이해하실 겁니다.
결함이 초기에 빨리 수정되지 않으면 단계를 거쳐 가면서
더 많은 결함으로 커진다는 기본 사실을 말입니다.
분석 단계에서 1만큼의 노력(Cost)을 기울여서 수정할 수 있는 결함을 방치하면
나중에 구현/테스트 단계에서는 100(또는 그 이상)만큼의 노력을 들여야
해당 결함과 그로부터 파생된 결함을 수정할 수 있게 된다는 것이 상식 중의 상식이죠.
<정기원, 소프트웨어 프로세스와 품질>
위의 그래프를 보시면, 쉽게 이해가 되셨을 겁니다.
소프트웨어 프로젝트에서(특히 요구사항 정의 단계) 작은 결함을 발견하지 못하고
설계 단계로 넘어가게 될 경우, 이를 설계 단계에서 발견하고 수정하는데 드는
Cost(또는 Effort)는 훨씬 더 커지게 됩니다.
마찬가지로 설계 단계에서도 발견하지 못하고 구현 단계로 넘어가서야
이를 발견한다면, 더 커지겠지요.
그래서 가급적 프로젝트 초기 단계에 결함관리를 하기 위한 프로세스를
프로젝트 팀 내부에 적용해야 하며,
그를 위한 관련 양식 작성 및 배포도 빠를수록 좋습니다.
이는 소프트웨어 프로세스와 품질에 관련된 많은 서적과 논문에서
공통으로 말하는 점입니다.
이 내용에 관심 있으신 분들은 소프트웨어 품질 표준
(IEEE 12207, ISO 9000시리즈, ISO 9126, ISO 14598 등)을
살펴보시고, 요구공학(Requirement Engineering), 그리고 Clean room 프로세스 같은
내용을 공부해보시면 될 것 같습니다.
초반에 각각의 단위시스템별 산출물을 누가 검토하고,
검토한 결과를 어떻게 공유하며(일반적으로 결함관리 대장에 기입),
이에 대한 조치 책임은 누가 지며, 결함조치 결과를 확인하고 완결 처리하는
일련의 활동들의 R&R(Role & Responsibility)이 정의된 후 운영해야 합니다.
실제 프로젝트에서 결함관리를 하는 주요 방법에는
동료 검토, 합동 검토, QA 리뷰 정도가 일반적으로 쓰입니다.
분석/설계 단계에서는 산출물을 검토하고 오류 사항을 발견하여
이를 수정하는 작업이 반복적으로 수행되기 때문에,
검토를 반복해서 자주 수행할수록 산출물의 오류가 감소하게 되는 효과가 있습니다.
단지 일반적으로 국내 프로젝트에서는 분석/설계 단계가
그다지 길지 않은 일정으로 잡히는 경우가 많으며,
특히 설계 단계에서 요구사항을 정제하고 산출물 만들기도 바쁜데,
검토를 여러 번 한다는 것은 현실적으로 매우 어렵죠.
게다가 일반적으로 설계 단계는 산출물의 양이 가장 많은 단계입니다.
요구사항을 구현하기 위한 세부사항을 수립하고,
이를 정비해야 하므로 Agile 계열의 방법론을 사용하는 것이 아니라면,
작성할 산출물이 제일 많은 것이 일반적이죠.
게다가 자주 바뀌는 고객사의 요구사항 역시 결함관리를
어렵게 만드는 요소 중 하나입니다.
http://www.flickr.com/photos/saidosdaconcha/3595949998/
보통 SI 프로젝트에서 조직구성은
“개발자 - PL - 총괄PL(프로젝트가 클 경우) - 사업관리/품질관리 - PM”의
트리 형태로 계층구조를 취하는 것이 보통입니다.
프로젝트에서 중요하지 않은 역할이라는 건 없지만,
그중에서도 PL이 가장 핵심이라는 것은 지난 기고글에서 말씀드렸습니다.
이처럼 Hierarchy한 조직구조에서 PL이 모든 산출물을 다 작성한다는 것은
불가능에 가깝습니다. 그렇게 하기에 양이 너무 많습니다.
그래서 PL이 전체적인 내용의 흐름을 꿰고 있는 상태에서
개발자들에게 산출물 작성을 전달하고
이를 취합 및 정리하는 형태로 업무가 진행됩니다.
각 단위 시스템별 PL들은 완성된 산출물을
프로젝트 내부 프로세스에 의해 정해진 형상규칙에 의거하여 형상서버에 올립니다.
아울러 매주 주간보고 작성 시 이에 대한 보고를 올릴 것입니다.
그러면 프로젝트 QA(프로젝트 규모가 작을 때 사업관리자가 역할을 겸임)가
이를 1차적으로 검토합니다. 그래서 결함이라고 판단되는 사항을
결함관리대장에 기재합니다. 각 PL들은 결함관리대장을 주기적으로 모니터링하여
이 결함을 직접 또는 예하 개발자들에게 지시하여 시정조치를 합니다.
그리고 결함조치가 완료되면 결함관리대장의 상태 항목을
“조치완료”와 같은 형태로 바꿔놓겠죠.
프로젝트 QA는 마찬가지로 결함관리대장을 주기적으로 살펴보고
결함조치가 완료된 건에 관해 확인합니다.
그래서 결함 처리가 완료되면 “확인완료”와 같은 상태로 변경하는 것입니다.
이 프로세스를 간단하게 도식해보면 다음과 같습니다.
<결함관리 프로세스의 예시>
이 구조는 프로젝트에 따라 고객사 업무담당자들이 검토하는 단계가
추가될 수도 있고, 전사 QA의 검토 한 번만 수행하는 것으로 할 수도 있겠죠.
처음에 프로젝트의 특성을 반영하여
어떻게 검토활동을 수행할 것인지 결정하고 이를 실행하는 것입니다.
반복해서 말씀드리고 있지만
여러 단계로 수행하는 것이 품질수준 향상에는 유리합니다.
위 예시에서 보시면 PL이 1차 검토, 총괄 PL이 2차 검토, 프로젝트 QA가 3차 검토,
QA가 4차 검토를 수행하는 것을 확인하실 수 있습니다.
업무가 순환적으로 계속 반복되면서 검토를 수행할 때마다
결함관리 대장에는 검토를 통해 발견된 결함이 계속 쌓여갈 것입니다.
그리고 각 서브시스템의 PL들은 상시로 결함관리대장을 모니터링 하면서
기록된 결함을 조치하도록 개발자들에게 지시하고,
완료된 결함을 확인한 후 보고할 것입니다.
그 내용은 프로젝트 QA나 수행사 품질팀의 전사 QA가 확인한 후
품질보증활동결과서에 기록할 것입니다.
http://www.flickr.com/photos/jvk/6721198/
국내 SI 업체들은 보통 전사 품질관리팀(QA팀) 또는 그에 따르는 조직을 보유한 채로,
회사에서 수행하는 프로젝트들의 품질활동 지원업무를 수행합니다.
전사 품질팀 인력은 소프트웨어공학에서 얘기하는
SEPG(Software Engineering Process Group)의 구실을 하며,
프로젝트 수행팀에서 지원 요청이 들어오거나
단계 말 정기 품질보증활동 시점이 도래하면 프로젝트 수행팀에 파견 나와
품질검토, 관리체계 수립 지원, 감리준비에 대한 지원 등의 다양한 활동을 수행하고
이 결과를 품질보증활동결과서를 작성하는 형태로 PM과 전사품질팀에 보고합니다.
아울러 프로젝트 QA는 수시로 또는 단계 말에 전사 QA가 지원 나오기 전,
내부적인 검토 활동을 수행하고, 전사 QA의 지원을 요청합니다.
프로젝트 결과물의 품질을 높이고 감리에 대응하는 현실적인 목표 달성을 위해
품질보증활동의 수행과 그 결과물의 작성은 필수적입니다.
프로젝트의 규모와 특성에 따라 사업관리자가
프로젝트 QA를 겸임하거나(소형 프로젝트의 경우),
또는 별도의 인력을 프로젝트 QA로 상주시켜
품질관리 업무를 지원하도록 하거나 합니다.
규모가 매우 큰 프로젝트는 사업관리, 품질관리 업무 자체가
한 사람이 하기에는 분량이 광대해서 사업관리팀과 QA팀을 구축해서
프로젝트를 수행하기도 합니다.
결함관리를 위한 수단으로 활용되는 결함관리대장의 예시를 들어
간략하게 설명해보겠습니다.
| 결함 발견 | 결함 조치 | |||||||||||||||
| 결함ID | 발견 단계 |
심 각 도 |
영 향 도 |
처리 우선 순위 |
결함 발견 활동 |
결함 발견 산출물 |
결함 위치 |
발생원인 및 해결방안 |
발견 일자 |
발견자 | 현재 상태 |
처리 담당자 |
처리 예정일 |
처리 완료일 |
결함출처 | 비고 |
| FT-S1-001 | 분석 | 중 | 하 | 3 | 동료검토 | 요구사항 정의서 |
14 P 3~14줄 |
요구사항ID 미부여 항목 발견 | 12-08-02 | 허재 | 결함 조치 확인 완료 |
<st1:personname w:st="on">김유택</st1:personname> | 12-08-05 | 12-08-08 | PJ-S1-ReD-002_ 요구사항정의서_V0.8 |
- 요구사항 정의서 작성중 타 기관(프로농구협회)과의 연계를 위한 인터뷰 일정을 변경할 수 없어, 이를 먼저 수행함으로 인해 결함 처리가 3일 지연되었음. |
| FT-MG-001 | 분석 | 상 | 상 | 1 | 프로젝트QA검토 | 형상관리 계획서 |
2-1장 전체 |
형상관리계획의 R&R이 현재 전혀 정의되지 않음 | 12-08-14 | <st1:personname w:st="on">강동희</st1:personname> | 결함 수정중 |
<st1:personname w:st="on">한기범</st1:personname> | 12-09-01 | PJ-MG-CMP_ 형상관리계획서_V0.6 |
- 현재(9/3) 고객사 업무 담당자의 사업 참여도에 대한 범위가 확정되지 않아 계획 변경 미완료 상태임. | |
| FT-S1-002 | 분석 | 중 | 상 | 2 | QA검토 | 품질보증 계획서 |
8-1장 산출물목록 부분 |
개발단계 및 검토 대상물이 기준산출물 목록과 일치하지 않음 | 12-08-28 | <st1:personname w:st="on">강동희</st1:personname> | 결함 발견 |
<st1:personname w:st="on">한기범</st1:personname> | 12-09-12 | PJ-MG-QAP_ 품질보증계획서_V0.9 |
||
심각도와 영향도 판별에 의한 우선순위를 정하는 방법은
위험/이슈 관리에서도 다룬 적이 있으니 다들 아실 겁니다.
결함을 발견하는 순서에 따라 형상관리계획에서 수립한
결함ID 부여규칙에 따라 ID를 부여합니다.
결함 발견에 속하는 항목에서는 발견자가 기재하고,
결함 조치 항목은 실제 처리 담당자와 사업관리, 품질관리자가
기록과 업데이트를 합니다. 내용이 그다지 어렵지 않으니
예시에 대한 설명은 많이 하지 않겠습니다.
프로젝트가 진행되고 검토를 수행할수록,
결함관리대장 내용과 품질보증활동결과서가 쌓여갈 것입니다.
기본적으로 결함관리를 위한 내용이 많을수록 품질보증활동을 많이 수행했다고
생각하시는 게 맞습니다. 아울러 결함을 탐색하는 과정에서
PL, 사업관리자, QA간의 회의도 종종 수행될 것입니다.
이 회의록 내용도 품질보증활동을 수행한 근거자료가 되니,
내부 회의일지라도 회의록을 작성하여 보관하시는 것이 유리합니다.
엄밀하게는 구현단계 말에 수행하는 단위테스트, 시험 단계에 수행하는 통합테스트,
병행테스트, 사용자 테스트 시에 나오는 오류도 결함입니다만,
소스에 대한 테스트 결과는 별도의 양식을 준비하여 수행하시는 것이 편합니다.
결함관리 대장으로 테스트 결과까지 관리하기에는 결함관리대장에
작성할 수 있는 내용에 한계가 있고, 다양한 테스트 형태와
입력값, 결과값을 비롯한 테스트 케이스와 시나리오 관리가 어렵기 때문입니다.
경험상 산출물에 대한 결함관리는 결함관리대장과
위 예시의 프로세스를 따라 관리하시는 것이 편하고,
테스트는 별도 테스트 양식서, 시나리오 양식서를 가지고 관리하는 것이 편합니다.
이 부분에 대한 내용은 추후 시험 단계에 대한 기고글에서 정리해보도록 하겠습니다.
다음 기고글에서는 분석 단계에서 나오는 일반적인 개발산출물에 관해
이야기해보도록 하겠습니다.