V-Model

728x90

V-Model(V-Cycle)

V-Model 혹은 V-Cycle이라고 불린다.

V 모델은 소프트웨어 개발 프로세스로 폭포수 모델의 확장된 형태 중 하나이다.

말 그대로 V자 형태로 개발이 진행되며 검증과 유효화 검사로 나뉘게 된다.

이 프로세스는 자동차 분야 뿐 아니라 전체적인 개발 진행 과정에서 통용되는 용어로 ISO26262, ASPICE 같은 표준에 들어가는 방법론이다.

V-Model에서 왼쪽이 개발진행 단계이고 오른쪽이 검증단계로 표현되는데 실제 업무에서 System Testing과 Acceptance testing 단계가 SW QA의 Role인 경우가 대다수이다.

V-Model과 더불어 V&V라는 용어를 많이 접하게 될텐데 V&V는 Validation & Verification의 약자이다.

Varification은 명세 기반으로 기능이 정상적으로 동작함을 검증하는 행위이다.

이는 요구사양 명세서 review, Designe 문서 review, Process audit등의 행위가 해당한다.

어떻게보면 개발과정이 올바르게 진행되는지 보는 행위라고도 이해할 수 있다.

Validation은 사용자의 needs에 얼마나 부합하게 S/W가 동작하는지 검증하는 행위를 나타낸다.

이 과정에서 기능을 점검하는 functional test외에도 non-functional test, perfomance test, stress test, UX test, Tester 경험적 기반 test등을 진행하게 된다.

더 나아가 다른 연동 system과의 호환성을 보는 호환성 test, end-to-end test등 다양한 test 종류가 존재한다.

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)

시스템이나 시스템의 일부 또는 특정한 비기능적인 특성에 대해 확신을 얻는 작업
여러 검색을 통해 내가 이해한 바로는 결함을 찾기 위해 테스트하는 과정이 아닌 시스템을 배포하거나 실제로 사용할만한 준비가 되었는지에 대해 평가하는 과정이다
고객들의 요구사항과 만들어진 결과물이 일치하고 살제로 배포될 수 있는가를 확인한다
그림 상에서는 제일 마지막에 있지만 사용자 관점에서 테스팅을 할 수 있고 운영적으로도 테스팅을 진행할 수 있다