이전 주제와 완전히 다른 얘기를 할껀데, 자동차 개발 프로세스에서 기능안전이 적용되는 프로젝트에 대해 얘기를 할거야, 내 질문은 뭐냐면, 만약에 공급업체의 개발 계획을 두 단계로 다음과 같이 나누어서 (첫 번째 단계: 소프웨어 기능을 80% 구현 하고 소프트웨어 통합검증, 임베디드 소프트웨어 검증, 시스템 통합 검증을 마치고, 마지막에 소프트웨어 기능을 100%구현한 것에 대해 소프트웨어 통합 검증, 임베디드 소프트웨어 검증, 시스템 통합 테스트 검증을 마치는게 계획인데, 우리가 기존에 기능을 80% 구현한 시점에 소프트웨어 통합, 임베디드 소프트웨어 검증을 마치고, 시스템 통합 테스도 마쳤거든? 근데 갑자기 80퍼센트 구현된 기능 부분에서 소프트웨어 수준에서 기능을 바꿔야 하는 부분이 생겼어 그랬을 경우 재검을을 해야 하자나? 근데 전체를 검증하는 것은 불합리하고 바뀌는 부분이 영향을 미치는 부분을 분석한 후에 영향 받는 부분만 검증을 하면 되는 것으로 알고 있는데 이게 소프트웨어 통합과, 임베디드 소프트웨어 검증에서는 영향 받는 부분만 검증하면 될 거 같거든? 그런데 이 바뀌는 부분으 소프트웨어 수준인데 이보다 상위 수준인 시스템 통합 테스트에서도 바뀐 부분이 영향이 미치는 것만 검증해도 될까?
안녕하세요. 자동차 기능안전 프로젝트에서 공급업체 개발 계획에 대한 질문이시군요. 질문 내용을 정리하면 다음과 같습니다.
- 현재 상황: 공급업체가 소프트웨어 기능 80%를 구현하고 SW 통합 검증, 임베디드 SW 검증, 시스템 통합 테스트를 완료했습니다.
- 문제 발생: 80% 구현된 기능 중 일부가 변경되어 소프트웨어 수준에서 수정이 필요합니다.
- 궁금한 점: 변경된 부분과 그 영향 범위만 재검증하는 것이 합리적인데, 소프트웨어 통합 및 임베디드 소프트웨어 검증뿐만 아니라, 더 상위 단계인 시스템 통합 테스트에서도 영향받는 부분만 재검증해도 되는지 여부입니다.
결론
네, 맞습니다. 소프트웨어 변경으로 인해 영향을 받는 부분만 선별적으로 재검증(재회귀 테스트)하는 것이 일반적이고 합리적인 접근 방식입니다. 이는 시스템 통합 테스트 단계에서도 동일하게 적용됩니다.
세부 설명
자동차 기능안전(ISO 26262) 개발 프로세스에서 변경 사항이 발생했을 때 전체를 재검증하는 것은 비효율적입니다. 대신 **영향 분석(Impact Analysis)**을 통해 변경 사항이 시스템 전체에 미치는 영향을 파악하고, 그에 따라 필요한 검증 활동을 계획하는 것이 중요합니다.
- 소프트웨어 수준의 변경
- 소프트웨어 통합 검증 (Software Integration Testing): 변경된 소프트웨어 모듈과 관련된 다른 모듈 간의 인터페이스 및 상호작용에 초점을 맞춰 재검증을 수행합니다.
- 임베디드 소프트웨어 검증 (Embedded Software Testing): 변경된 소프트웨어의 기능이 하드웨어와 정확하게 동작하는지 확인하기 위해 재검증합니다. 이는 변경된 기능에 대한 단위 테스트 및 통합 테스트를 포함합니다.
- 시스템 수준의 변경
- 시스템 통합 테스트 (System Integration Testing): 소프트웨어 수준의 변경이 시스템 전체 기능 및 성능에 미치는 영향을 평가하는 단계입니다. 단순히 소프트웨어 모듈만 바뀌었다고 해서 시스템 전체를 다시 테스트할 필요는 없습니다.
- 영향 분석의 중요성: 변경된 소프트웨어 기능이 시스템의 다른 기능, 센서, 액추에이터, 통신 프로토콜 등과 어떻게 상호작용하는지 철저히 분석해야 합니다. 이 분석 결과를 바탕으로, 변경된 부분과 직접적으로 연관된 시스템 요구사항(System Requirements)과 관련된 테스트 케이스들만 선별하여 재실행하면 됩니다.
실제 적용 예시
예를 들어, 차량의 차선 유지 보조 시스템(LKAS)에서 차선 감지 알고리즘의 일부 파라미터가 변경되었다고 가정해 보겠습니다. 이 경우,
- 소프트웨어 수준: 변경된 파라미터가 포함된 소프트웨어 모듈과 이 모듈을 호출하는 상위 소프트웨어 모듈 간의 인터페이스를 검증합니다.
- 시스템 수준: 시스템 통합 테스트에서는 변경된 알고리즘이 실제 차량 환경(시뮬레이션 또는 실제 도로)에서 차선을 올바르게 인식하고 차량을 안정적으로 유지하는지, 그리고 다른 시스템(예: 조향 장치)과 충돌 없이 잘 연동되는지 해당 기능에 한정하여 재검증을 수행합니다. 차량의 다른 기능들(예: 크루즈 컨트롤, 긴급 제동)은 이 변경으로 인해 영향을 받지 않는다면, 전체를 재테스트할 필요는 없습니다.
결론
정리하면, 소프트웨어 변경이 발생했을 때 상위 단계인 시스템 통합 테스트에서도 영향 분석을 통해 도출된, 변경된 부분과 연관된 기능만을 선별적으로 재검증하는 것이 올바른 접근입니다. 이는 개발 효율성을 높이면서도 기능안전의 무결성을 보장하는 핵심적인 방법론입니다.
혹시 변경 사항이 시스템 전반에 걸쳐 예상치 못한 영향을 미칠 가능성이 크다면, 예외적으로 더 광범위한 테스트를 고려할 수도 있지만, 일반적인 경우에는 영향 분석 기반의 선별적 재검증이 원칙입니다.
'실무 팁' 카테고리의 다른 글
| 요구사항 커버리지, 코드 커버리지 헷갈리지 말기 (0) | 2026.01.14 |
|---|---|
| 테스트 검증 활동이 오래 걸리는 이유? (0) | 2025.08.21 |
| 베이스라인 설정 (0) | 2025.02.04 |
| 첫 ASPICE 적용 프로젝트 시작하면서 회의에서 알게된 팁 (0) | 2024.04.04 |
| ASPICE_ 품질 점검 관점 (0) | 2023.11.15 |