V-모델(소프트웨어 개발)

V-model (software development)
시스템 엔지니어링 [1]프로세스의 V-모델입니다.
시리즈의 일부:
소프트웨어 개발
핵심 활동
패러다임 및 모델
방법론 및 프레임워크
지원 분야
관행
도구들
지식의 표준 및 체계
용어집
개요

소프트웨어 개발에서 V-모델은[2] 워터폴 모델의 확장으로 간주될 수 있는 개발 프로세스를 나타내며, 보다 일반적인 V-모델의 예입니다.선형으로 아래로 이동하는 대신, 프로세스 단계는 코딩 단계 이후에 위쪽으로 구부러져 일반적인 V 모양을 형성합니다.V-Model은 개발 수명 주기의 각 단계와 관련 테스트 단계 간의 관계를 보여줍니다.수평 축과 수직 축은 각각 시간 또는 프로젝트 완료(왼쪽에서 오른쪽)와 추상화 수준(가장 거친 추상화)을 나타냅니다.

프로젝트 정의 단계

요구사항 분석

검증 프로세스의 첫 번째 단계인 요구사항 분석 단계에서는 사용자의 요구사항을 분석하여 시스템의 요구사항을 수집합니다.이 단계는 이상적인 시스템이 수행해야 할 작업을 결정하는 단계입니다.그러나 소프트웨어가 어떻게 설계되거나 구축될 것인지는 결정하지 않습니다.일반적으로 사용자를 인터뷰하고 사용자 요구사항 문서라는 문서가 생성됩니다.

사용자 요구사항 문서는 일반적으로 사용자가 예상하는 시스템의 기능, 인터페이스, 성능, 데이터, 보안 등의 요구사항을 설명합니다.비즈니스 분석가가 시스템에 대한 이해를 사용자에게 전달하는 데 사용됩니다.이 문서는 시스템 설계 단계에서 시스템 설계자의 지침이 될 수 있으므로 사용자는 이 문서를 주의 깊게 검토합니다.사용자 수용 테스트는 이 단계에서 설계됩니다.기능 요구 사항도 참조하십시오.

인터뷰, 설문지, 문서 분석, 관찰, 일회용 프로토타입, 사용 사례 및 사용자와의 정적 및 동적 뷰를 포함하여 소프트 방법론과 하드 방법론의 요구사항을 수집하는 다양한 방법이 있습니다.

시스템 설계

시스템 설계는 시스템 엔지니어가 사용자 요구사항 문서를 연구하여 제안된 시스템의 비즈니스를 분석하고 이해하는 단계입니다.그들은 사용자 요구사항이 구현될 수 있는 가능성과 기술을 파악합니다.요구 사항 중 하나라도 실행 가능하지 않으면 사용자에게 문제를 알립니다.해결 방법이 발견되고 그에 따라 사용자 요구사항 문서가 편집됩니다.

개발 단계의 청사진 역할을 하는 소프트웨어 사양 문서가 생성됩니다.이 문서에는 일반적인 시스템 구성, 메뉴 구조, 데이터 구조 등이 포함되어 있습니다.또한 비즈니스 시나리오 예제, 샘플 창 및 보고서를 참조하여 이해를 도울 수도 있습니다.엔티티 다이어그램, 데이터 사전과 같은 다른 기술 문서도 이 단계에서 생산될 것입니다.시스템 테스트를 위한 문서가 준비되어 있습니다.

건축설계

컴퓨터 아키텍처 및 소프트웨어 아키텍처의 설계 단계는 고급 설계라고도 할 수 있습니다.아키텍처를 선택할 때의 기준은 일반적으로 모듈 목록, 각 모듈의 간단한 기능, 인터페이스 관계, 종속성, 데이터베이스 테이블, 아키텍처 다이어그램, 기술 세부 정보 등으로 구성된 모든 것을 실현해야 한다는 것입니다.통합 테스트 설계는 특정 [3]단계에서 수행됩니다.

모듈 설계

모듈 설계 단계는 저수준 설계라고도 할 수 있습니다.설계된 시스템은 더 작은 단위 또는 모듈로 분할되고 프로그래머가 직접 코딩을 시작할 수 있도록 각각 설명됩니다.낮은 수준의 설계 문서 또는 프로그램 사양에는 모듈의 상세한 기능 논리가 의사 코드로 포함됩니다.

  • 데이터베이스 테이블, 유형 및 크기를 포함한 모든 요소
  • 완전한 API 참조가 포함된 모든 인터페이스 세부 정보
  • 모든 의존성 문제
  • 오류 메시지 목록
  • 모듈에 대한 전체 입력 및 출력.

이 단계에서는 단위 테스트 설계가 개발됩니다.

검증 단계

V-모델에서 각 검증 단계에는 검증 [4]단계에 해당하는 단계가 있습니다.다음은 V-Model의 일반적인 검증 단계입니다. 다른 이름으로도 알 수 있습니다.

유닛 테스트

V-Model에서는 모듈 설계 단계에서 유닛 테스트 계획(UTP)이 개발됩니다.이러한 UTP는 코드 수준 또는 장치 수준에서 버그를 제거하기 위해 실행됩니다.단위는 독립적으로 존재할 수 있는 가장 작은 개체(예: 프로그램 모듈)입니다.장치 테스트는 나머지 코드/장치에서 분리되었을 때 가장 작은 엔티티가 올바르게 작동하는지 확인합니다.

통합 테스트

통합 테스트 계획은 건축 설계 단계에서 개발됩니다.이러한 테스트는 독립적으로 생성되고 테스트된 장치가 서로 공존하고 통신할 수 있는지 확인합니다.테스트 결과를 고객 팀과 공유합니다.

시스템 테스트

시스템 테스트 계획은 시스템 설계 단계에서 개발됩니다.유닛 및 통합 테스트 계획과 달리 시스템 테스트 계획은 고객의 비즈니스 팀에 의해 구성됩니다.시스템 테스트는 개발된 애플리케이션의 기대치가 충족되는지 확인합니다.전체 애플리케이션은 기능성, 상호의존성 및 통신을 테스트합니다.시스템 테스트는 기능 및 비기능 요구 사항이 충족되었는지 확인합니다.부하 및 성능 테스트, 스트레스 테스트, 회귀 테스트 등은 시스템 테스트의 하위 집합입니다.

사용자 수락 테스트

사용자 인수 테스트(UAT) 계획은 요구사항 분석 단계에서 개발됩니다.테스트 계획은 비즈니스 사용자에 의해 구성됩니다.UAT는 실제 데이터를 사용하여 프로덕션 환경과 유사한 사용자 환경에서 수행됩니다.UAT는 제공된 시스템이 사용자의 요구 사항을 충족하고 실시간으로 시스템을 사용할 준비가 되었는지 확인합니다.

비판

V-Model은 다양한 [5][6][7]이유로 인해 Agile 지지자들과 다른 사람들로부터 소프트웨어 개발의 부적절한 모델이라는 비판을 받아왔습니다.비판은 다음과 같습니다.

  1. 소프트웨어 개발 프로세스를 정확하게 반영하기에는 너무 간단하며 관리자가 잘못된 보안 의식을 갖게 될 수 있습니다.V-Model은 소프트웨어 개발에 대한 프로젝트 관리 관점을 반영하며 소프트웨어 개발자나 사용자가 아닌 프로젝트 관리자, 회계사 및 변호사의 요구에 부합합니다.
  2. 초보자도 쉽게 이해할 수 있지만, 이러한 조기 이해는 초보자가 개발 프로세스와 V-Model이 실제로 어떻게 적용되고 확장되어야 하는지에 대해 더 깊이 이해하는 경우에만 유용합니다.실무자가 V-Model에 대한 단순한 견해를 고수할 경우 V-Model을 성공적으로 적용하는 데 큰 어려움을 겪게 됩니다.
  3. 이는 유연성이 없으며 소프트웨어 개발에 대한 엄격하고 선형적인 관점을 장려하며 변화에 대응할 수 있는 고유한 능력이 없습니다.
  4. 폭포수 모델에 약간의 변형만 제공하므로 해당 모델과 동일한 비판을 받습니다.테스트, 특히 초기 테스트 계획의 중요성을 더욱 강조합니다.그러나 V-Model에 대한 일반적인 실질적인 비판은 초기 단계가 오버런되었지만 구현 날짜가 고정된 상태에서 개발이 끝날 때 테스트가 엄격한 창에 비집고 들어가는 결과를 초래한다는 것입니다.
  5. 이는 테스트에 대한 비효율적이고 비효율적인 접근 방식과 일치하며, 따라서 암묵적으로 권장됩니다.탐색적 테스트보다는 사전에 테스트 스크립트를 작성하는 것을 암시적으로 장려합니다. 이는 테스트자들이 실제로 무엇이 있는지를 발견하는 것이 아니라 그들이 무엇을 발견할 것인지를 찾도록 장려합니다.또한 시험관이 가장 효과적이고 효율적인 시험 계획 및 실행 방법을 선택하도록 권장하는 것이 아니라 각 다리의 동등한 수준(예: 사용자 요구 사항 문서에서 도출되는 사용자 수용 시험 계획) 간의 엄격한 연계를 장려합니다.
  6. 그것은 일관성과 정확성이 부족합니다.V-Model이 정확히 무엇인지에 대한 혼란이 확산되고 있습니다.대부분의 사람들이 동의하는 요소로 요약하면 소프트웨어 개발에 대한 진부하고 도움이 되지 않는 표현이 됩니다.V-Model의 장점에 대한 의견 불일치는 종종 V-Model의 정의에 대한 공유된 이해 부족을 반영합니다.

현재 상태

V-Model의 지지자들은 V-Model이 시간이 지남에 따라 발전했으며 개발 프로세스 [8]전반에 걸쳐 유연성과 민첩성을 지원한다고 주장합니다.그들은 고도로 규율화된 접근 방식일 뿐만 아니라 안정적인 소프트웨어 제품을 구축하는 데 필요한 세심한 설계, 개발 및 문서화를 촉진한다고 주장합니다.최근, 그것은 의료기기 [9][10]산업에 채택되고 있습니다.

참고 항목

레퍼런스

  1. ^ Clarus 운영 개념.2009-07-05 Wayback Machine 간행물 번호 FHWA-JPO-05-072, 연방도로국(FHWA), 2005.
  2. ^ Kevin Forsberg와 Harold Moz, "프로젝트 사이클에 대한 시스템 엔지니어링의 관계", 1991년 10월, 57-65년 10월.
  3. ^ V 모델이란? - 장점, 단점 및 사용 시기
  4. ^ DeSpautz, Joseph; Kenneth S. Kovacs; Gerhard Werling (11 March 2008). "GAMP Standards For Validation of Automated Systems". Pharmaceutical Processing. Archived from the original on 8 May 2012. Retrieved 28 February 2012.
  5. ^ "V-모델의 죽음", 2013년 1월 6일 액세스
  6. ^ 2019년 9월 15일부터 보관된 버전인 "위험하고 유혹적인 V 모델"
  7. ^ "테스트 개발을 위한 새로운 모델", 2013년 1월 6일 액세스
  8. ^ "신속한 시스템 엔지니어링 프로세스로", 2022년 8월 9일 액세스
  9. ^ "의료기기 소프트웨어 개발 시 신속한 변화를 위한 관행 채택 장벽"
  10. ^ "의료기기 산업을 위한 소프트웨어 프로세스 개발, 평가 및 개선 프레임워크"

진일보한 내용

  • 로저 S. 프레스먼:소프트웨어 엔지니어링: 실무자의 접근법, McGraw-Hill Companies, ISBN 0-07-301933-X
  • Mark Hoffman & Ted Beaumont: 애플리케이션 개발: 프로젝트 라이프 사이클 관리, McPress, ISBN 1-883884-45-4
  • Boris Beizer: 소프트웨어 테스트 기술.제2판, 국제 톰슨 컴퓨터 출판사, 1990, ISBN 1-85032-880-3


Wikimedia Commons에는 V 모델과 관련된 미디어가 있습니다.