해당 글은 ASPICE Annex D. Key concepts를 참고하여 작성되었습니다.
위 그림에서 각 프로세스 간에 연결되어 있는 선(Line)이 많이 보입니다. 선의 색에 따라서 추적성 (Traceability), 일관성 (Consistency)를 나타냅니다. 선이 많다는 것은 그만큼 추적성과 일관성이 많이 필요하다고 생각하시면 됩니다.
여기서, 추적성과 일관성은 다음을 의미합니다.
추적성 (Traceability): 작업 산출물 내 관련 요소들 간에 연결되어 추적 가능한지를 의미
일관성 (Consistency): 작업 산출물 내 관련 요소들 간에 내용과 의미가 일관되게 반영되어 있는지를 의미
추적성부터 간략하게 살펴보면 아래 그림과 같이 Requirements가 구현 그리고 Test case까지 연결되어 있습니다.
이러한 그림은 이해를 돕기 위한 예시입니다. 실제로는 1개의 Requirements에 여러개의 Architecture 문서의 Component로 그리고 다수의 Code module로 연결되는 그림을 가질 수 있습니다.
추적성의 필요한 이유를 다음의 몇 가지 부분들을 통해서 이해할 수 있습니다.
추적성 필요 이유1. 커버리지 분석 및 파악
예를 들면, 설계한 테스트 케이스가 요구사항을 얼마나 커버하는지 가능합니다. 요구사항을 위한 테스트 케이스의 누락은 없는지, (중요/이슈) 요구사항에 대해 추가 테스트 케이스가 필요한지 등 분석이 가능합니다.
추적성 필요 이유2. 변경에 대한 영향도 분석
예를 들면, 개발 중에는 여러 변경이 발생한다고 말씀 드렸습니다. 모든 변경을 원하는 계획(일정, 인원 등)대로 수행하는 일은 생각보다 적을 수 있습니다. 변경에 따른 수정해야 하는 산출물의 범위가 어떻게 되는지, 이를 위한 공수는 얼마가 될 것이고 개발 과정에서 수용 가능한 변경인지, 추가 계획이 필요한지 등을 분석해야 하는데, 이러한 경우에 추적성이 확보되어 있다면 분석이 용이합니다.
필요 이유3. 요구사항 구현 상태를 관리
(제가 얼마전에 들었던 황당?한 이야기는 Jira 티켓을 보고서 Done 여부를 확인하고 구현 완료로 체크하여 자료를 작성한 적이 있었습니다. 그때에 누군가는 구현한거 확인했어요? 네! Done 확인했습니다. 아니 그거 말고, 소스코드에서 확인했냐고요!!! 라고 하더군요. 저는 매우 당황스러웠습니다.;;)
요구사항이 구현되었다는 것은 개발자가 소프트웨어적으로는 코딩을 완료하였고, 하드웨어적으로는 아트웍이나 실물로 구현을 했다는 것이지요. 이런 경우 추적성이 연결되어 있다면 실제 산출물을 확인하지 않고 확인할 수 있습니다.
(개발자 외 인원들이 소스코드에서 확인하고, 아트웍을 보면서 구현 여부를 체크해야 한다고 생각 하시나요?)
추적성은 양방향 (Bidirectional) 연결을 요구합니다. 이전 글 V model에서 시스템 요구사항 작성 시, 시스템 케이스를 작성이 가능/준비 해야 한다고 말씀 드렸습니다. 이런 경우를 포함해서 테스트 케이스를 먼저 준비/작성 해야할 때, 관련된 요구사항이나 아키텍처가 무엇인지를 확인하기 위해서는 역방향 (Backward)의 경우도 포함될 수 있습니다.
필요 이유또한 추적성은 일관성을 보완할 수 있습니다.
일관성은 Project Management Plan을 가지고서 얘기해보겠습니다.
현재 재직하고 있는 회사에서는 PMP, Project Management Plan을 마스터 플랜으로 두고, Safety management plan, test plan, verification plan 등 다양한 Sub plan을 포함하는 형태로 구성되어 있습니다.
프로젝트 초기에 이러한 계획은 일관성을 확보하여 작성하겠죠? PMP에 작성된 프로젝트 범위와 Safety management plan의 범위가 같을 것이고, 계획서 내 일정과 그 일정을 고려한 Sub plan의 일정이 일관되게 유지될 것입니다.
그러나 revision 안되는 plan은 이 세상에서 가능할까요? 마음 깊이 머리속 깊이 살펴보아도, 여지껏 단 한번도 본적이 없습니다.
예를 들면, 프로젝트 일정이 상위 PMP에서 변경되었습니다. Sub plan들에서도 변경되는 일정을 고려한 계획이 업데이트 되어야 합니다. PM, Project Manager가 바빠서 Project management plan에서 업데이트 하지 않았습니다. 대신 구두상으로 SM, Safety manager에게 변경된 일정과 고려되는 사항들을 전달했습니다. SM도 바빠서 Safety management plan을 업데이트 하지 않았습니다. 추가로 다른 담당자들은 이러한 변경 사항을 놓치고 있습니다. 이런 경우, 유사한 일들이 반복되면서 산출물은 산출물의 유무로만 가치(?)가 존재할 수 있습니다.
제가 이전 여러 글에서도 많이 말씀 드렸습니다. 우리가 수행하는 개발과정에서 REVIEW는 선택이 아닌 필수입니다. REVIEW를 통해서 산출물들 간에 일관성을 확보하는 것은 기본적이면서 필수적인 활동입니다. 이점을 반드시 기억해주시기 바랍니다.
마지막으로 가장 상단의 그림에서 선(Line)에 추적성과 일관성이 함께 표기되어 있습니다. 이러한 이유는 이 둘은 상호보완 관계이기 때문입니다. 요구사항이 변경되는 경우 관련된 항목을 수정해야 하는데, 추적성이 확보되어 있다면 해당 산출물을 찾아서 용이하게 변경가능할 것입니다. 반대도 마찬가지고요.
이상 읽어주셔서 감사합니다.
'소프트웨어공학 (Software Engineering)' 카테고리의 다른 글
| [ASPICE 핵심 컨셉#6] "Evaluate", "Verification Criteria" and "Ensuring compliance" (0) | 2022.10.09 |
|---|---|
| [ASPICE 핵심 컨셉#5] "Agree" and "Summarize and Communicate" (0) | 2022.10.09 |
| [ASPICE 핵심 컨셉#3] 용어 "Element", "Component", "Unit", and "Item" (0) | 2022.10.09 |
| [ASPICE 핵심 컨셉#2] V-model 컨셉이란? (0) | 2022.10.09 |
| [ASPICE 핵심 컨셉#1] Plug-in이란? (0) | 2022.10.09 |