A-SPICE
요구사항 변경이 설계와 시험에 미치는 영향을 설명하는 상황
Process의 목적과 산출물의 추적성을 함께 보아야 변경의 누락을 찾을 수 있다. 문서 개수보다 요구사항·설계·구현·검증 사이의 일관성이 중요하며 평가 범위와 버전을 구분해야 한다.
변경 요청을 요구사항·설계·구현·검증 결과와 연결하고 리뷰·기준선을 관리한다.
적용 범위
실행 예제의 주소·선택자·interface·설정값은 시험 환경에 맞게 변경한다. 규격의 적용 판과 도구 버전을 확인한다.
핵심 요약
Automotive SPICE는 자동차 개발 process를 평가하고 개선하기 위한 모델이다. 제품의 기능 안전 인증이나 software의 무결함을 보장하는 제도와 동일하지 않다.
기준 버전
Automotive SPICE 평가에는 계약·조직에서 지정한 PAM/PRM 버전을 적용한다. 3.1과 4.0의 process 정의·평가 지표는 구분한다.
요구사항에서 검증까지의 연결
요구사항 → 설계 → 구현 → 검증 결과의 연결을 추적한다. 문서가 존재하는지만 보는 대신, 변경된 요구사항이 설계와 테스트에 반영됐는지 확인할 수 있어야 한다.
software 개발에서 읽을 process
| 항목 | 설명 및 적용 기준 |
|---|---|
| SWE.1 | software 요구사항 분석. |
| SWE.2 | software 아키텍처 설계. |
| SWE.3 | 상세 설계와 유닛 구현. |
| SWE.4~SWE.6 | 유닛·통합·요구사항에 대한 검증 영역. 정확한 명칭과 기대 산출물은 적용 모델 버전을 따른다. |
- 구성 관리, 문제 해결 관리, 변경 요청 관리, 품질 보증은 개발 산출물과 상태를 유지하는 데 함께 고려한다.
추적성의 설명용 예시
REQ-001 → 설계 항목 DES-001 → 구현 단위 → 시험 TC-001 → 실행 결과의 연결을 구성한다. 예시 식별자는 실제 업무 자료가 아니다. link만 생성하는 것으로 끝내지 않고 요구사항 변경 시 영향과 재검증 범위를 확인한다.
검토할 근거
- 요구사항의 명확성·검증 가능성, 설계 선택의 근거.
- 리뷰 결과와 지적 사항의 조치 상태.
- 테스트 명세와 실제 실행 결과, 실패 처리 내역.
- 산출물의 버전·기준선과 변경 승인 기록.
평가 해석 시 주의
process 수행과 process 능력 수준을 구분한다. 팀의 평가 결과를 개인 자격이나 모든 개발 영역의 성숙도로 표현하지 않는다. 준수·평가 통과 여부는 실제 평가 범위와 근거가 있을 때만 기재한다.
공식 출처
VDA QMC Automotive SPICE 모델과 적용 버전 자료: https://vda-qmc.de/en/automotive-spice/
실습: 변경 한 건의 추적성
설명용 요구 REQ-001의 timeout 정책이 변경됐다고 가정한다. 변경 사유·영향 범위 → 설계 DES-001 → 구현 단위 → 시험 TC-001 → 실행 결과 → review 조치 상태를 연결한다.
기존 link가 존재하는지뿐 아니라 바뀐 timeout 값이 시험의 판정 기준에 반영됐는지 확인한다. 산출물마다 버전·기준선·승인 상태를 기록한다.
실무 산출물 양식
변경 ID / 영향 요구사항 / 설계·구현 영향 / 재시험 범위 / 리뷰 지적 / 조치 / 기준선 / 실행 결과 link.
시험을 실패한 상태로 남기고 이슈·재시험과 연결한다. 적용 PAM의 process명과 증거 요구는 버전별로 확인한다.
이해를 확인하는 질문
시험 결과만 있으면 요구사항 충족을 설명할 수 있을까?
시험 조건과 판정 기준이 해당 요구사항에 연결되어야 한다. 변경 영향과 재시험 범위도 추적할 수 있어야 한다.