ASPICE SWE.3의 역할과 범위
자동차 소프트웨어 개발에서 SWE.3는 소프트웨어 상세 설계와 유닛 구현을 의미한다. SWE.1에서 소프트웨어 요구사항을 정의하고, SWE.2에서 소프트웨어 아키텍처를 설계했다면, SWE.3에서는 각 소프트웨어 컴포넌트를 실제 구현 가능한 수준으로 세분화한다. 쉽게 말해 아키텍처에서 나눈 모듈을 함수, 로직, 알고리즘, 상태 전이, 데이터 처리 방식까지 구체적으로 설계하고 코드로 구현하는 단계다.
SWE.3의 핵심은 설계와 구현의 일관성이다. 개발자는 단순히 기능이 동작하도록 코드를 작성하는 것이 아니라, 소프트웨어 요구사항과 아키텍처 설계가 상세 설계와 코드에 제대로 반영되었는지 설명할 수 있어야 한다. 예를 들어 특정 입력 신호를 판단하여 출력 신호를 제어하는 기능이 있다면, 어떤 조건에서 입력을 읽고, 어떤 판단 로직을 거치며, 어떤 예외 조건에서 출력을 제한하는지 상세 설계에 명확히 표현되어야 한다.
상세 설계 단계에서는 함수의 역할, 입력값과 출력값, 내부 변수, 호출 관계, 상태 전이, 오류 처리 조건을 구체적으로 정의해야 한다. 자동차 ECU 소프트웨어는 다양한 신호와 상태 조건에 따라 동작하기 때문에 로직이 모호하면 구현자마다 다르게 해석할 수 있다. 특히 진단 처리, 통신 오류, 센서값 비정상 범위, 타이밍 조건처럼 실제 차량에서 문제가 될 수 있는 부분은 설계 단계에서 빠지지 않도록 확인해야 한다.
ASPICE SWE.3에서 중요한 요소 중 하나는 추적성이다. 상세 설계와 구현 코드는 상위 소프트웨어 요구사항 및 아키텍처 설계와 연결되어야 한다. 하나의 요구사항이 어떤 함수나 모듈에서 구현되었는지 확인할 수 있어야 하고, 반대로 특정 코드가 어떤 요구사항을 만족하기 위해 존재하는지도 설명할 수 있어야 한다. 추적성이 확보되면 요구사항 변경 시 수정해야 할 코드 범위를 빠르게 파악할 수 있다.
구현 단계에서는 코딩 규칙 준수가 중요하다. 자동차 소프트웨어는 품질과 안정성이 중요하기 때문에 회사 내부 코딩 가이드, MISRA C 같은 규칙, 정적 분석 기준을 따르는 경우가 많다. 코딩 규칙은 단순히 코드 스타일을 맞추기 위한 것이 아니라 잠재적인 오류, 메모리 문제, 가독성 저하, 유지보수 어려움을 줄이기 위한 기준이다. 따라서 구현 이후에는 코드 리뷰와 정적 분석 결과를 통해 품질을 확인해야 한다.
또한 SWE.3에서는 모듈 간 의존성을 줄이고 역할을 명확히 나누는 것이 중요하다. 하나의 함수나 모듈이 너무 많은 기능을 담당하면 수정과 테스트가 어려워진다. 반대로 기능별 책임이 잘 분리되어 있으면 유닛 테스트를 작성하기 쉽고, 결함이 발생했을 때 원인 분석도 빨라진다. 자동차 소프트웨어는 장기간 유지보수되고 여러 차종에 재사용될 수 있으므로 처음부터 구조를 깔끔하게 설계하는 것이 좋다.
SWE.3의 주요 산출물에는 소프트웨어 상세 설계서, 함수 설계 설명, 상태 전이표, 알고리즘 설명, 인터페이스 정의, 소스 코드, 코드 리뷰 기록, 정적 분석 결과 등이 포함될 수 있다. 중요한 것은 문서와 코드가 서로 맞아야 한다는 점이다. 설계에는 존재하지만 코드에 구현되지 않은 기능이 있거나, 요구사항 없이 작성된 코드가 많다면 ASPICE 관점에서 문제가 될 수 있다.
결론적으로 ASPICE SWE.3는 소프트웨어 요구사항과 아키텍처를 실제 코드로 연결하는 중요한 단계다. 좋은 유닛 설계와 구현은 요구사항을 정확히 반영하고, 모듈의 역할을 명확히 하며, 코딩 규칙과 리뷰를 통해 품질을 확보해야 한다. ECU 개발자라면 SWE.3를 단순한 코딩 단계로 보지 말고, 요구사항과 설계, 검증을 연결하는 핵심 실무 프로세스로 이해하는 것이 필요하다.