❗️V 모델 (V-Model)
Waterfall 모델에 대해서 공부하던 중, 확장된 Waterfall 모델인 V 모델을 알 수 있었다.
Waterfall 모델은 전 단계로 돌아가지 못하기 때문에 각 단계에서 매우 신중하게 진행해야 한다.
여기서 V 모델은, 각 단계에서 테스트를 진행한다고 하여, 좀 더 체계적인 느낌을 받았다.
🙋🏻♂️ V model이 무엇일까?
폭포수 모델의 확장된 형태로 분석이나 설계 등의 개발 단계마다 상응하는 테스트 단계가 존재하는 소프트웨어 프로세스 모델
V 모델은 폭포수 모델의 변형입니다.
폭포수 모델에서 테스트 단계를 중점적으로 추가한 모델입니다.
폭포수 모델은 문서중심이고, V 모델은 각 개발 단계를 검증하는 데 초점을 둡니다.
V 모델에서는 각 단계에 대응하는 테스트 단계가 있으며, 이 단계에서는 해당 단계에서 개발한 것이 제대로 동작하는지 검증합니다. 예를 들어, 요구사항 단계에서는 요구사항 명세서를 작성하고, 이 명세서에 대한 검증 단계에서는 요구사항이 제대로 이행되고 있는지를 검증합니다. 이것은 소프트웨어의 품질을 향상시키고, 개발 프로세스를 보다 안정적으로 만들어 줍니다.
V 모델은 소프트웨어 개발 프로세스의 각 단계가 다른 단계에 대한 입력으로 동작하는 것을 강조하며, 이는 Waterfall 모델과 유사합니다. 그러나 V 모델에서는 각 단계에서 개발된 내용을 테스트하는 단계가 반드시 수반되며, 이를 통해 품질을 보증할 수 있습니다. 따라서 V 모델은 Waterfall 모델과 비교하여, 보다 체계적인 검증과 검증 단계에서의 결함 발견과 수정에 대한 강조가 있습니다.
☘️ Testing 설계를 통한 검증(Verification) 단계
1. 요구사항 분석 -> 사용자 요구사항 문서
-
개발 될 시스템에 대한 요구사항은 시스템 사용자의 필요를 분석함으로써 얻을 수 있습니다.
-
목표로 하는 이상적인 시스템이 수행해야 할 기능에 대해서 고민해야 합니다.
-
소프트웨어가 어떻게 설계되고 구현될 것인지에 대한 사항은 다루지 않습니다.
-
사용자 요구사항 문서를 생성하게 됩니다. 사용자 요구사항 문서는 일반적으로 사용자가 기대하는 시스템의 기능적인 요구사항, 물리적 요구사항, 보안 등 다양한 요구사항을 기록합니다. 이 문서는 사용자를 만나 기능에 대한 의견을 청취하면서 생성합니다.
2. 시스템 설계 -> 소프트웨어 기술서
-
시스템 엔지니어는 사용자 요구사항 문서를 면밀히 검토하는 것을 통해 개발할 시스템에 대해 분석하고 이해합니다.
-
또한 사용자 요구사항을 구현 가능성과 필요한 기술들을 파악합니다.
-
시스템 설계를 거치면 개발 단계를 위한 청사진이 될 소프트웨어 기술서가 생성됩니다. 이 문서는 시스템의 구성과 메뉴 구조, 자료 구조 등을 기술합니다. 엔티티 다이어그램과 데이터 목록과 같은 기술자료 또한 산출됩니다.
3. 아키텍처 설계
-
고수준 설계 : 컴퓨터 아키텍처 및 소프트웨어 아키텍처 설계 단계를 합친 용어.
-
아키텍처를 선택함으로써 만들어지는 베이스라인은 일반적으로 모든 구현될 모듈 항목과 그 간략한 기능을 정의하고, 모듈 간의 인터페이스, 관계, 의존성을 기술하며, 필요한 적용기술 내역을 기술합니다.
-
이 단계에서 통합 테스트에 대한 설계가 이루어집니다.
4. 모듈 설계
-
저수준 설계 : 모듈 설계 단계의 또 다른 용어
-
작성될 저수준 설계 문서 또는 프로그램 명세서에서는 각 모듈의 상세한 기능 로직을 의사코드를 사용하여 기술하고, API 명세를 통해 의존성 관련 이슈를 포함한 모듈의 모든 인터페이스 상세 사항을 기술합니다.
-
이 단계에서 단위 테스트에 대한 설계가 이루어집니다.
☘️ Testing을 통한 검증(Validation) 단계
1. 단위 테스트
-
화이트 박스 테스트 : 코드를 직접 확인하는 테스트
-
단위 테스트는 테스트 프로세스의 첫 단계, 에러를 줄이기 위한 의도로 작성된 코드에 대한 분석을 진행 + 모든 함수, 메소드에 대한 테스트 케이스를 작성하는 절차입니다.
-
코드를 효율적으로 작성햇는지, 코딩 표준을 준수하는지 개발한 개발자가 직접 수행합니다.
2. 통합 테스트
-
블랙 박스 테스트 : 코드를 직접 확인하는 형태는 아님.
-
각각의 모듈을 통합하여, 통합된 컴포넌트 간의 인터페이스와 상호작용 상의 오류를 발견하는 작업을 수행합니다.
-
이 과정에서도 일반적으로 개발자가 진행합니다.
3. 시스템 테스트
-
실제 구현된 시스템과 계획된 사양간을 비교한느 작업입니다.
-
시스템 테스트에 대한 설계가 시스템 설계 문서로부터 도출되어 사용됩니다. 때로는 자동화 도구를 이용하여 진행하기도 합니다.
-
개발자와 다른 별도의 테스트 팀에 의해 수행됩니다.
4. 인수 테스트
-
제품의 인수를 위해 요구사항이 완벽하게 수행되는지를 정해진 인수절차에 따라 고객이 직접 테스트하는 과정입니다.
-
제대로 동작하는 시스템을 보면서 상황을 확인하고, 이 시스템이 자신이 직접 명세한 테스트를 통과하였는지 확인합니다.
-
요구사항 분석 단계에서 준비된 테스트 케이스를 이용합니다.
장점과 단점
☘️ 장점
1. 개발 생산성 향상:
- V 모델은 각 단계에서 검증과 검토를 통해 오류를 빠르게 발견하고 수정할 수 있습니다.
이를 통해 초기 오류 발견 및 수정으로 인한 개발 시간과 비용이 절감됩니다.
2. 품질 보장:
- V 모델은 개발 과정 중간에 테스트를 수행하고 검증하는 방식으로, 최종 결과물의 품질을 보장합니다.
또한 각 단계에서 테스트 케이스와 검증 계획을 작성하므로, 품질 관리에 대한 투명성을 확보할 수 있습니다.
3. 명확한 문서화:
- V 모델에서는 각 단계에서 개발하는 작업 내용을 문서화하므로, 전체 개발 과정을 이해하기 쉽습니다.
이를 통해 향후 유지보수 및 개선 작업이 용이해집니다.
4. 프로젝트 관리 용이성:
- V 모델에서는 각 단계에서 개발 작업의 완료 여부를 명확하게 확인할 수 있으므로, 프로젝트 일정을 관리하기 용이합니다.
🤬 단점
1. 엄격한 선형적 접근 방식:
- V 모델은 각 단계를 순차적으로 진행해야 하므로, 하나의 단계에서 발생한 문제가 전체 개발 과정에 영향을 미칩니다.
2. 초기 요구사항의 변경 어려움:
- V 모델에서는 초기에 요구사항을 명확히 정의하고 검증해야 합니다.
따라서 초기 요구사항이 변경되는 경우, 후반 단계에서 변경된 요구사항을 수용하기 어렵습니다.
3. 테스트 비용 증가:
- V 모델에서는 각 단계마다 테스트를 수행하므로, 전체적인 테스트 비용이 증가할 수 있습니다.
4. 고객 참여 부족:
- V 모델에서는 고객의 요구사항을 초기에 명확히 정의하고 검증합니다.
따라서 고객이 개발 과정 전체에 참여하지 않으면 개발 과정에서 발생하는 문제를 대처하기 어렵습니다.
