자동차 임베디드에서 사실상 표준이고, ISO 26262 도 이 구조를 전제한다.
SR ────────────────────────── 인수 시험
SysRS ─────────────── 시스템 시험
SWRS · HWRS ─── 통합 시험
설계 ─── 단위 시험
구현
점선(가로 대응)이 전부다
| 왼팔 | 짝이 되는 시험 | 무엇을 확인하나 |
|---|---|---|
| SR | 인수 시험 | 사용자가 원한 것이 되는가 |
| SysRS | 시스템 시험 | 시스템이 요구대로 동작하는가 |
| SWRS/HWRS | 통합 시험 | 노드끼리 붙였을 때 맞는가 |
| 설계 | 단위 시험 | 모듈 하나가 설계대로 도는가 |
시험 명세를 구현 전에 쓴다
이게 V모델을 쓰는 실질적 이유다. 구현을 다 하고 "이제 뭘 시험하지"를 고민하지 않는다. 그래서 §9 가 요구사항을 검증 가능성 기준으로 쪼개라고 하는 것 — 요구사항 하나가 시험 항목 하나가 되어야 이 대응이 성립한다.
폭포수와 다르다
왼팔을 다 끝내고 오른팔로 가야 하는 게 아니다. 기능 단위로 V 를 여러 번 돌 수 있고(반복 V), 이 프로젝트도 그렇게 간다 — M1 벤치 실험 수치가 TBD 를 닫으면서 왼팔로 되돌아간다.
V모델이 강제하는 건 순서가 아니라 대응 관계다.
이 프로젝트의 공백
SR 은 있고 SysRS 가 없다. §9 가 "Controller 간 명령 전달·상태 교환·중재는 SysRS 에서 정의한다"고 미뤄 둔 자리가 통째로 비어 있고, 09·10편이 임시로 채우고 있다. TBD 32건 중 상당수가 사실 SysRS 에서 결정될 항목이다.