[A-SPICE] 설계·구현·검증 및 테스팅과 형상 관리

 

설계·구현·검증

자동차 소프트웨어 개발에서 설계·구현·검증 단계는 요구사항을 실제로 동작하는 소프트웨어로 만들어 가는 핵심 과정이다.
이 단계에서는 “무엇을 만들 것인가”에서 나아가 “어떻게 만들고, 올바르게 만들어졌는가”를 확인한다.

 

---

 

소프트웨어 설계

소프트웨어 설계는 구현에 앞서 소프트웨어를 구성하는 요소와 구조를 정의하는 활동이다.
설계는 이후 구현과 테스트의 기준이 되며, 변경과 확장에 유연하게 대응하기 위한 기반을 만든다.

설계는 크게 두 단계로 나뉜다.

 

1. 아키텍처 설계

상위 수준에서 소프트웨어 구성 요소들 간의 관계를 정의하는 활동이다.
구조 설계, 데이터베이스 설계, 인터페이스 설계가 포함되며, 시스템 전반의 흐름과 책임 분리를 결정한다.

아키텍처는 이해관계자 간 공통의 의사소통 수단이 되며,

기능성, 신뢰성, 사용성, 효율성, 유지보수성, 이식성과 같은 품질 속성에 대한 기준을 제공한다.

 

2. 상세 설계
아키텍처 설계에서 정의된 구성 요소 내부를 구체화하는 단계이다.
컴포넌트의 내부 데이터 구조, 변수, 자료형, 알고리즘 로직 등을 설계하며,
구현 단계에서 개발자가 참고하는 직접적인 설계 기준이 된다.

 

---

 

소프트웨어 구현 및 통합

소프트웨어 구현은 설계된 내용을 바탕으로 개별 소프트웨어 단위를 실행 가능한 형태로 개발하는 활동이다.
일반적으로 프로그래밍이라고 부르는 단계이며, 코드 작성과 함께 문서화가 이루어진다.

소프트웨어 통합은 개발된 단위 모듈들을 통합 계획에 따라 결합하여 완전한 소프트웨어 구조를 만드는 과정이다.
이 과정에서 모듈 간 인터페이스 오류나 데이터 흐름 문제가 집중적으로 발생할 수 있다.

 

---

 

검증과 확인의 개념

소프트웨어 개발에서는
Verification(검증)과 Validation(확인)을 명확히 구분한다.

 

Verification은 “제품이 올바르게 만들어지고 있는가?”를 확인하는 활동이다.
요구사항 명세서와 설계서 등 사양(Spec)에 맞게 소프트웨어가 구현되었는지를 검증한다.

 

Validation은 “올바른 제품을 만들고 있는가?”를 확인하는 활동이다.
사용자가 의도한 환경과 목적에 맞게 소프트웨어가 동작하는지를 확인한다.

 

V-Model에서는 설계와 구현 단계에서 정의된 산출물이 검증과 확인 단계에서 기준으로 사용된다.

 

---

 

⭐️ 테스팅과 형상 관리

 

소프트웨어 테스팅의 목적

소프트웨어 테스팅은 정상 조건과 비정상 조건 사이의 차이를 발견하기 위해 소프트웨어를 분석하고 실행하는 프로세스이다.

테스팅의 목적은 단순히 오류를 찾는 것이 아니라, 결함을 발견하려는 의도를 가지고 소프트웨어의 품질을 확인하는 데 있다.

에러(Error)는 사람의 실수로 인해 발생하며,
결함(Defect)은 제품에 포함된 결점이다.
이 결함이 실행될 때 나타나는 현상이 실패(Failure)이다.

 

---

 

테스팅 단계의 구분

소프트웨어 테스팅은 V-Model 구조에 따라 단계적으로 수행된다.

1. 단위 테스트(Unit Testing)
개별 단위 모듈을 대상으로 하며, 개발자가 개발 환경에서 수행한다.
주로 화이트박스 테스트 방법을 사용한다.

 

2. 통합 테스트(Integration Testing)
단위 테스트가 완료된 모듈들을 통합하여 수행한다.
모듈 간 인터페이스와 데이터 흐름을 확인하며, 그레이박스 테스트 방법이 사용된다.

 

3. 시스템 테스트(System Testing)
통합된 전체 소프트웨어를 대상으로 수행한다.
기능뿐만 아니라 성능과 같은 비기능 요구사항도 검증하며, 실제와 유사한 환경에서 테스터가 수행한다.

 

4. 인수 테스트(Acceptance Testing)
실제 사용 환경에서 사용자 또는 고객이 요구사항 만족 여부를 확인하는 단계이다.
블랙박스 테스트 방법이 사용된다.

 

---

 

블랙박스 테스트와 화이트박스 테스트

블랙박스 테스트
소스 코드 내부 로직을 고려하지 않고 출력 결과를 기준으로 검증하는 방법이다.
요구사항 명세서나 설계서를 기반으로 테스트 케이스를 도출한다.

 

화이트박스 테스트
소스 코드의 구조와 제어 흐름을 기준으로 모든 독립 경로를 수행해보며 결함을 찾는 방법이다.
함수 커버리지, 문장 커버리지, 분기 커버리지, 경로 커버리지 등이 있다.

https://jelong.tistory.com/entry/Java-%EB%B8%94%EB%9E%99-%EB%B0%95%EC%8A%A4-%ED%85%8C%EC%8A%A4%ED%8A%B8-%ED%99%94%EC%9D%B4%ED%8A%B8-%EB%B0%95%EC%8A%A4-%ED%85%8C%EC%8A%A4%ED%8A%B8-%EC%BB%A4%EB%B2%84%EB%A6%AC%EC%A7%80Coverage-%EC%98%88%EC%8B%9C

 

---

 

소프트웨어 형상 관리

소프트웨어 형상 관리는 요구사항 명세서, 설계서, 소스 코드, 테스트 결과와 같은 산출물의 구성을 관리하는 활동이다.

 

형상 관리는 형상 항목을 식별하고, 변경을 통제하며, 현재 상태를 모니터링함으로써 무결성과 추적성을 확보한다.

 

형상 식별 단계에서는 형상 관리 대상 항목과 식별자, 베이스라인을 정의한다.
베이스라인은 공식적으로 검토되고 합의된 상태로, 정해진 변경 관리 절차를 통해서만 수정될 수 있다.

 

형상 통제는 변경 요청을 평가하고 승인하는 과정이며, 형상 상태 보고를 통해 현재 개발 상태에 대한 가시성을 제공한다.

 

형상 감사는 형상 관리 계획에 따라 형상 관리 활동이 제대로 수행되고 있는지를 확인하는 활동이다.

 

---

 

추적 관리의 중요성

추적 관리는 요구사항과 설계, 구현, 테스트 산출물 간의 연결 관계를 관리하는 활동이다.

요구사항 변경 시 어떤 설계와 코드, 테스트에 영향을 미치는지 즉시 파악할 수 있어야 하며,
이를 통해 변경으로 인한 리스크를 최소화할 수 있다.

 

ALM(Application Lifecycle Management)은 소프트웨어 생명주기 전반을 통합적으로 관리하기 위한 접근 방법이다.

 

---

 

📝 정리

설계·구현·검증과 테스팅·형상 관리는 각각 독립적인 단계가 아니라,
V-Model을 중심으로 서로 긴밀하게 연결된 활동이다.

명확한 설계와 체계적인 형상 관리가 있을 때 테스트는 효과적으로 수행될 수 있으며,
결과적으로 소프트웨어 품질을 안정적으로 확보할 수 있다.