V-Model(V-Cycle)
V-Model 혹은 V-Cycle이라고 불린다. V 모델은 소프트웨어 개발 프로세스로 폭포수 모델의 확장된 형태 중 하나이다. 말 그대로 V자 형태로 개발이 진행되며 검증과 유효화 검사로 나뉘게 된다. 이 프로세스는 자동차 분야 뿐 아니라 전체적인 개발 진행 과정에서 통용되는 용어로 사전에 설명했던 ISO26262, ASPICE 같은 표준에 들어가는 방법론이다.
![](https://velog.velcdn.com/images/gks970113-woo/post/8108daf0-1950-46cd-ad96-a05e39fd5901/image.png)
Verification(검증)
V자 제일 아래있는 Coding 기준으로 왼쪽 부분에 있는 단계들을 Verification. 즉, 검증 단계라고 한다.
(여담으로 정보처리기사 공부할때 배웠던 내용들이 새록새록 기억난다. 그땐 이런게 뭔지 이해가 안가고 왜 배우는지 몰랐지만 현업에 오니 알게 되는구나)
요구사항 분석(Requirements Analysis)
- 요구사항 분석은 말 그대로 사용자의 필요를 분석해서 정리하는 과정
- 무엇을 원하는지 기능에 대한 의견을 듣고 문서화
- 기능적, 물리적, 인터페이서, 성능, 데이터, 보안 요구사항으로 나뉘어 기록
- 밑그림이 되는 초기 과정이기 때문에 사용자도 문서화한 요구사항들을 잘 확인하고 합의하는 과정이 필요함
시스템 설계(System Design)
- 고객의 요구사항을 다 확인하고 문서화된 자료를 통해 개발할 시스템에 대해 분석하고 이해함
- 구현이 불가능하거나 어려운 점이 있다면 사용자와 다시 협의를 통해 요구사항 문서를 수정
- 이 단계에선 자료구조, 메뉴 구조, 시스템 구성 등 개발에 필요한 소프트웨어 기술서를 작성함
- entity diagrams, data dictionary, 시스템 테스트를 위한 문서를 작성하고 전반적으로 공사를 위한 기둥을 세운다고 생각하면 된다
아키텍처 설계(Architecture Design)
- 구현할 모듈 항목과 간략한 기능들을 설명하는 설계를하고 그 내용을 문서화 한다
- 모듈 간의 인터페이스, 관계, 의존성을 기술하고 필요한 데이터베이스 테이블, 아키텍처 다이어그램, 적용기술 내역을 기술한다
- 통합 테스트에 대한 설계를 함
모듈 설계(Module Design)
- 아키텍처 설계는 고수준 설계라고하며, 모둘 설계는 저수준 설계라고 부르기도 함
- 아키텍처 설계에서 정의하고 내용을 설명했던 모듈 항목을 세분해 각각의 모듈에 대한 기술을 작성
- 프로그래머들이 코딩을 할 수 있도록 함수의 역할과 관계 이름을 만들어 준다고 생각하면 됨
- 이전 과정에서 처럼 상세하게 문서화하기 보다 의사 코드(pseudocode)를 활용해 기술한다
- API 명세를 통해 의존성 관련 이슈와 인터페이스 상세 사항을 기술하고 각 모듈의 에러 코드와 메시지를 기술
- 모듈의 입력과 출력, 필요한 경우 모듈의 데이터 베이스 테이블의 구조와 요소별 타입과 크기또한 기술함
- 단위 테스트를 위한 설계를 함
Coding
- 위에서 정의한 요구사항 문서와 시스템 문서, 모듈 문서를 가지고 개발을 진행
Validation(유효화 검사)
단위 테스트(Unit Testing)
- V 모델 방식에서 Coding 기준으로 오른쪽에 있는 과정에서 첫 번째이다. 테스트 과정의 시작이라고 보면 됨
- 앞의 Verification 과정들에서는 고객이 원하는 프로그램을 개발하기 위해 요구사항을 이해하고 시스템 구조를 짜고 내부의 자세한 기능들을 짜면서 큰 틀 -> 작은 틀로 진행됐지만 실질적인 Validation 과정에서는 구현한 함수들의 테스트, 통합 테스트, 시스템 테스트, 인수 테스트와 같은 작은 틀 -> 큰 틀로 진행되는 테스트 단계를 저친다
- 즉, 단위 테스트는 모듈 설계에서 구현한 모듈들에서 코드가 효율적으로 작성 되었는지 코드 표준을 준수하는지를 검증
- 모듈 설계 단계에서 준비한 테스트 케이스를 가지고 개발자가 직접 수행하며 화이트박스 테스트라고 불리기도 함
통합 테스트(Integration Testing)
- 각각의 모듈을 통합해 통합된 컴포넌트 간의 인터페이스와 상호 작용 상의 오류를 발견하는 테스트를 진행
- 블랙박스 테스트를 일반적으로 사용하며 대체로 코드를 직접 확인하지 않음
- 아키텍처 설계 단계와 연결되며 이 과정에서 준비했던 테스트 케이스를 사용해 테스트를 진행한다
- 마찬가지로 테스팅은 개발자가 보통 진행
시스템 테스트(System Testing)
- 구현된 시스템과 계획된 사양을 서로 비교하는 작업이 이루어짐
- 자동화 도구를 이용해 시스템 테스트를 자동화하기도 함
- 모듈을 통합한 후에 시스템 레벨의 에러들이 여기서 발견될 수 있음
- 개발자가 아닌 별도의 테스트 팀에 의해 수행됨
- 자동차 부분에선 차량 제어기를 소프트웨어 팀이 개발하고 성능 검증 팀에서 이 제어기가 어떻게 동작하는지 확인하는 과정과 유사하다고 생각하면 될듯
인수 테스트(Acceptance Testing)
- 시스템이나 시스템의 일부 또는 특정한 비기능적인 특성에 대해 확신을 얻는 작업
- 여러 검색을 통해 내가 이해한 바로는 결함을 찾기 위해 테스트하는 과정이 아닌 시스템을 배포하거나 실제로 사용할만한 준비가 되었는지에 대해 평가하는 과정이다
- 고객들의 요구사항과 만들어진 결과물이 일치하고 살제로 배포될 수 있는가를 확인한다
- 그림 상에서는 제일 마지막에 있지만 사용자 관점에서 테스팅을 할 수 있고 운영적으로도 테스팅을 진행할 수 있다
ASPICE & ISO26262
V-Model이 사용되는 파트
ASPICE, ISO26262 둘다 V 모델이 적용이 된다. ASPICE는 차량의 소프트웨어 개발 프로세스를 정의하고 있으며 ISO26262는 전기 전자적인 기능 안전 요건을 정의하고 있다. ASPICE는 아래 그림과 같이 ISO26262의 10파트 중에 6번째 SW Level에 존재한다고 보면 되며 둘다 결과론 적으로 개발 프로세르를 다루기 때문에 V 모델이 적용된다고 보면 된다.
![](https://velog.velcdn.com/images/gks970113-woo/post/0b3258b2-8cc7-424b-8df8-1ccb08b8d744/image.png)