ASPICE Assessment에서 확인하는 핵심 항목
자동차 소프트웨어 개발 프로젝트에서 ASPICE Assessment는 개발 조직의 프로세스가 정해진 기준에 맞게 수행되고 있는지 확인하는 평가 활동이다. 단순히 문서가 많이 있는지를 보는 것이 아니라, 요구사항 분석부터 설계, 구현, 검증, 변경관리, 형상관리까지 실제 업무 흐름이 일관성 있게 운영되었는지를 확인한다. 따라서 ASPICE Assessment를 준비할 때는 산출물의 개수보다 각 산출물이 서로 연결되어 있고, 개발 활동의 근거로 설명 가능한지가 중요하다.
가장 먼저 확인해야 할 항목은 요구사항 관리다. 고객 요구사항, 시스템 요구사항, 소프트웨어 요구사항이 명확하게 정리되어 있는지 확인해야 한다. 요구사항은 모호한 표현을 피하고 검증 가능한 문장으로 작성되어야 한다. 예를 들어 “빠르게 동작한다”보다 “입력 신호 발생 후 100ms 이내에 출력한다”처럼 판단 기준이 분명해야 한다. 또한 상위 요구사항이 하위 요구사항으로 누락 없이 반영되었는지도 확인해야 한다.
두 번째는 추적성이다. ASPICE Assessment에서 자주 확인되는 부분이 요구사항, 설계, 코드, 테스트 간 연결 관계다. 하나의 요구사항이 어떤 설계 항목으로 반영되었고, 어떤 테스트 케이스로 검증되었는지 설명할 수 있어야 한다. 반대로 테스트 케이스가 어떤 요구사항을 확인하기 위한 것인지도 거슬러 올라갈 수 있어야 한다. 양방향 추적성이 부족하면 요구사항 누락이나 검증 누락으로 지적될 가능성이 높다.
세 번째는 설계 산출물의 완성도다. 시스템 아키텍처와 소프트웨어 아키텍처, 상세 설계가 요구사항을 기반으로 작성되어야 한다. 설계 문서에는 컴포넌트 구조, 인터페이스, 데이터 흐름, 상태 전이, 오류 처리 조건 등이 명확히 포함되어야 한다. 설계 내용이 코드와 맞지 않거나 최신 변경사항이 반영되지 않은 경우 평가 과정에서 문제가 될 수 있다.
네 번째는 검증 자료다. 유닛 테스트, 통합 테스트, 소프트웨어 적격성 테스트가 계획대로 수행되었는지 확인해야 한다. 테스트 케이스는 요구사항이나 설계와 연결되어야 하며, 테스트 결과와 실패 항목의 조치 이력도 관리되어야 한다. 실패한 테스트가 수정 없이 남아 있거나, 결함 조치 후 재검증 결과가 없다면 프로세스 수행 증거가 부족하다고 볼 수 있다.
다섯 번째는 리뷰와 승인 기록이다. 요구사항, 설계, 코드, 테스트 결과는 관련 담당자의 검토와 승인을 거쳐야 한다. 리뷰 기록에는 검토 일자, 참석자, 발견된 이슈, 조치 결과가 남아 있어야 한다. 단순히 문서가 존재하는 것보다 실제로 검토가 이루어졌고, 발견된 문제가 해결되었는지를 보여주는 것이 중요하다.
여섯 번째는 변경관리와 형상관리다. 요구사항 변경, 결함 수정, 고객 요청이 발생했을 때 영향 분석과 승인 절차가 수행되었는지 확인해야 한다. 또한 어떤 문서 버전과 소스 코드 버전, 테스트 결과가 하나의 릴리즈를 구성하는지 설명할 수 있어야 한다. 형상이 불명확하면 평가뿐 아니라 실제 프로젝트 관리에서도 혼선이 생긴다.
결론적으로 ASPICE Assessment 준비는 심사 직전에 문서를 모으는 작업이 아니라, 프로젝트 전 과정에서 수행한 활동을 일관성 있게 정리하는 과정이다. 요구사항의 명확성, 산출물 간 추적성, 설계와 코드의 일치성, 테스트 결과, 리뷰 기록, 변경관리 이력을 중심으로 점검해야 한다. 이러한 체크리스트를 미리 관리하면 ASPICE 대응뿐 아니라 자동차 소프트웨어 개발 품질을 높이는 데도 큰 도움이 된다. 결국 평가 준비의 핵심은 보여주기 위한 문서가 아니라, 실제 업무가 기준에 맞게 수행되었다는 근거를 체계적으로 남기는 것이다.