해당 글은 ASPICE Annex D. Key concepts를 참고하여 작성되었습니다.
아래 그림과 같이 Requirements 가 왼쪽에 있다면, Qualification Test가 오른쪽에 있습니다.
아키텍처가 왼쪽에 있는 경우 통합 테스트가 오른쪽에 있듯이요.
이러한 V자는 시스템에서 도메인 Software level로 이어지더라도 동일하게 적용됩니다.
구현(코딩) 시 Unit Verification 이 맵핑되듯이요.
그럼 왜 V model을 기반으로 프로세스를 구성하였을까요? / 고려해서 생각해야 할까요?
일반적으로 소프트웨어 프로세스는 아래와 같은 단계를 거치게 됩니다.
이러한 단계를 한번 씩 수행하면서 요구사항 부터, 테스트 단계까지 쭈욱 이어가는 것을 Waterfall (폭포수) 모델이라고 하였고, 오랫동안 산업에서는 이러한 생명주기와 개발 단계를 고려하였었습니다.
Waterfall (폭포수) 모델은 다음과 같은 특징과 성격을 가집니다.
- 설계 이전에 요구사항이 완료되어야 합니다. (변경되지 말아야 합니다)
- 구현(코딩) 이전에 설계가 완료되어야 합니다. (역시 변경되어서는 안됩니다)
- 시스템 컴포넌트들의 통합은 한 번에 수행되어야 합니다.
- 시스템 컴포넌트 통합 이후 시스템 테스트도 한 번에 수행되어야 합니다.
위와 같이 진행되기 위해서는 변경이 이뤄지는 것을 피해야 합니다. 즉 단계 별로 철저한 검토와 확인을 거쳐야 합니다.
완벽하게 (Completely), 일관되게 (Consistency), 모호하지 않게 (Unambiguously)하게 하는 것은 굉장히 어렵습니다.
추가 설명 및 예시1.
프로젝트 초기에 ① 부족한 요구사항, ② 변경 가능한 요구사항, ③ 추가 요구사항에 대해서 기술되어야 합니다. (현실을 생각해보면 불가능에 가깝지 않나요?, 양산을 몇 차례 수행한 제품에도 변경은 발생하기 마련입니다)
추가 설명 및 예시2.
테스트를 마지막에 수행한다는 것은 굉장히 위험합니다. 시스템이 끝날 떄까지 데모 가능한 형태의 제품을 볼 수 없다는 것도 현실에서 먼 얘기일 수 있습니다.
테스트를 위한 계획, 검증 기준, 결함 및 검증 프로세스에 따른 이행 등이 개발과정에서 함께 이뤄져야 합니다.
이러한 부분들을 보완하고 효과적, 효율적으로 운영하기 위해서 V-model, V 모델이 요구되게 되었습니다.
V-model, V 모델의 장점은 여러가지가 있겠지만,
1. 개발/테스트를 병행함으로써 일정을 단축할 수 있습니다.
예를 들면, 시스템 개발 계획서 (System development plan)에서 테스트 담당자와 테스트 전략과 방법 등을 고려할 수 있습니다. / 고려해야 합니다. 프로젝트 초기부터 병행해서 생각/고려 해야 합니다.
2. 작업 산출물에 대한 품질을 향상시킬 수 있습니다.
예를 들면, 시스템 요구사항 검증 시, 소프트웨어 담당자, 하드웨어 담당자 뿐만 아니라 시스템 테스트 담당자까지 참여하여 시스템 Qualification Test 관점에서 산출물을 검토할 수 있습니다. (다시 말씀 드리지만, 검토해야 합니다.)
각 담당자들은 본인이 속해있는 영역, 할당된 역할을 고려해서
프로젝트 시간 순, 이슈 건 등에 대해서 참여해야 할 일들을 찾아야 합니다. (자세한 내용은 글 제목과 맞지 않으니 PASS 합니다)
이상 읽어주셔서 감사합니다.
'소프트웨어공학 (Software Engineering)' 카테고리의 다른 글
| [ASPICE 핵심 컨셉#4] Traceability (추적성) and Consistency (일관성) (0) | 2022.10.09 |
|---|---|
| [ASPICE 핵심 컨셉#3] 용어 "Element", "Component", "Unit", and "Item" (0) | 2022.10.09 |
| [ASPICE 핵심 컨셉#1] Plug-in이란? (0) | 2022.10.09 |
| SW 테스팅 인터넷 강의 - 오답노트 (0) | 2022.10.09 |
| 소프트웨어 공학에서 '공학' 에 대한 생각해보기 (0) | 2022.10.04 |