V-Model(소프트웨어 개발)

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

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

프로젝트 정의 단계

요건 분석

검증 프로세스의 첫 단계인 요구 분석 단계에서는 사용자의 요구를 분석하여 시스템의 요구 사항을 수집한다.이 단계에서는 이상적인 시스템이 수행해야 할 작업을 결정합니다.다만, 소프트웨어의 설계나 구축 방법을 결정하는 것은 아닙니다.통상, 유저를 인터뷰 해, 유저 요건 문서라고 불리는 문서가 작성된다.

사용자 요건 문서에는 일반적으로 사용자가 기대하는 시스템 기능, 인터페이스, 성능, 데이터, 보안 등의 요건이 기재되어 있습니다.비즈니스 분석가가 시스템에 대한 자신의 이해를 사용자에게 전달하기 위해 사용합니다.이 문서는 시스템 설계 단계에서 시스템 설계자의 가이드라인이 되므로 사용자는 이 문서를 주의 깊게 검토해야 합니다.사용자 수용 테스트는 이 단계에서 설계되었습니다.「기능 요건」도 참조해 주세요.

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

시스템 설계

시스템 설계는 시스템 엔지니어가 사용자 요건 문서를 검토함으로써 제안된 시스템의 비즈니스를 분석하고 이해하는 단계입니다.이들은 사용자 요건을 구현할 수 있는 가능성과 기술을 파악합니다.실행할 수 없는 요건이 있는 경우 사용자에게 문제가 통지됩니다.해결 방법이 발견되고 그에 따라 사용자 요구 문서가 편집됩니다.

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

아키텍처 설계

컴퓨터 아키텍처 및 소프트웨어 아키텍처 설계 단계는 고급 설계라고도 합니다.아키텍처를 선택할 때의 기준은 모듈 목록, 각 모듈의 간단한 기능, 인터페이스 관계, 의존관계, 데이터베이스 테이블, 아키텍처 다이어그램, 테크놀로지 세부사항 등으로 구성되는 모든 것을 파악해야 한다는 것입니다.통합 테스트 설계는 특정 [3]단계에서 수행됩니다.

모듈 설계

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

  • 데이터베이스 테이블, 유형 및 크기를 포함한 모든 요소
  • 완전한 API 참조를 포함한 모든 인터페이스 세부 정보
  • 모든 의존관계 문제
  • 오류 메시지 목록
  • 모듈의 입력 및 출력을 완료합니다.

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

검증 단계

V-모델에서는 검증 단계의 각 단계는 검증 [4]단계의 대응 단계를 가진다.다음은 V-Model의 일반적인 검증 단계이지만 다른 이름으로도 알려져 있습니다.

유닛 테스트

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

통합 테스트

통합 테스트 계획은 아키텍처 설계 단계에서 작성됩니다.이러한 테스트는 독립적으로 생성 및 테스트된 장치가 공존하고 서로 통신할 수 있는지 확인합니다.테스트 결과는 고객의 팀과 공유됩니다.

시스템 테스트

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

사용자 수용 테스트

User Acceptance Test(UAT; 사용자 수용 테스트) 계획은 요건 분석 단계에서 작성됩니다.테스트 계획은 비즈니스 사용자에 의해 작성됩니다.UAT는 실제 가동 환경과 유사한 사용자 환경에서 실제 데이터를 사용하여 수행됩니다.UAT는 제공된 시스템이 사용자의 요구 사항을 충족하고 시스템을 실시간으로 사용할 수 있는지 확인합니다.

비판

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

  1. 소프트웨어 개발 프로세스를 정확하게 반영하는 것은 너무 단순하고 관리자가 잘못된 보안 의식을 갖게 할 수 있습니다.V-Model은 소프트웨어 개발에 대한 프로젝트 관리 관점을 반영하며 소프트웨어 개발자 또는 사용자가 아닌 프로젝트 관리자, 회계사 및 변호사의 요구에 부합합니다.
  2. 초보자도 쉽게 이해할 수 있지만, 개발 프로세스와 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월, 제1회 전국 시스템 엔지니어링 평의회 심포지엄 진행: 57~65.
  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. ^ 2013년 1월 6일 "V-모델의 죽음"에 액세스
  6. ^ 2013년 1월 6일 "위험하고 유혹적인 V 모델"에 접속
  7. ^ "테스트 개발을 위한 새로운 모델", 2013년 1월 6일 액세스
  8. ^ 2013년 1월 6일 액세스한 "신속한 시스템 엔지니어링 프로세스 지향"
  9. ^ "의료 기기 소프트웨어를 개발할 때 신속한 변화를 위한 방법을 채택하는 데 걸림돌"
  10. ^ "의료기기 산업을 위한 소프트웨어 프로세스 개발, 평가 및 개선 프레임워크

추가 정보

  • Roger S. Pressman:소프트웨어 엔지니어링: 실무자의 접근법, McGraw-Hill Companies, ISBN 0-07-301933-X
  • Mark Hoffman & Ted Beaumont: 어플리케이션 개발: 프로젝트 라이프 사이클 관리, Mc Press, ISBN 1-883884-45-4
  • Boris Beizer: 소프트웨어 테스트 기술.제2판, International Thomson Computer Press, 1990, ISBN 1-85032-880-3


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