V-модель

V -модель — это графическое представление жизненного цикла разработки систем . Она используется для создания строгих моделей жизненного цикла разработки и моделей управления проектами. V-модель делится на три основные категории: немецкая V-модель , общая модель тестирования и стандарт правительства США. ^[2]

V-модель суммирует основные шаги, которые необходимо предпринять в сочетании с соответствующими результатами в рамках валидации компьютеризированной системы или разработки жизненного цикла проекта. Она описывает действия, которые необходимо выполнить, и результаты, которые необходимо получить в ходе разработки продукта.

Левая сторона «V» представляет собой декомпозицию требований и создание спецификаций системы. Правая сторона «V» представляет собой интеграцию частей и их проверку. ^{[3] [4] [5] [6] [7]} Однако требования должны быть сначала проверены на соответствие требованиям более высокого уровня или потребностям пользователя. Кроме того, есть также что-то вроде проверки моделей системы. Это может быть частично сделано и на левой стороне. Утверждать, что проверка происходит только на правой стороне, может быть неправильно. Самый простой способ — сказать, что проверка всегда соответствует требованиям (техническим терминам), а проверка всегда соответствует реальному миру или потребностям пользователя. Аэрокосмический стандарт RTCA DO-178B гласит, что требования проверяются — подтверждаются на истинность — и конечный продукт проверяется, чтобы убедиться, что он удовлетворяет этим требованиям.

Подтверждение может быть выражено вопросом «Вы строите правильную вещь?», а верификация — вопросом «Вы строите ее правильно?».

Существует три основных типа V-моделей.

«V-Modell» — официальный метод управления проектами правительства Германии. Он примерно эквивалентен PRINCE2 , но имеет более прямое отношение к разработке программного обеспечения. ^[8] Ключевым атрибутом использования представления «V» было требование доказательства того, что продукты из левой части V были приемлемы соответствующей организацией тестирования и интеграции, реализующей правую часть V. ^{[9] [10] [11]}

В мировом сообществе тестировщиков V-модель широко рассматривается как нечеткое иллюстративное описание процесса разработки программного обеспечения, описанного в программе Международного совета по квалификациям в области тестирования программного обеспечения для тестировщиков программного обеспечения. ^[12] Единого определения этой модели не существует, и оно более подробно рассматривается в альтернативной статье о V-модели (разработка программного обеспечения) .

В США также есть государственный стандарт V-модели, которая существует около 20 лет ^{[ когда? ]} , как и ее немецкий аналог. Ее сфера применения — более узкая модель жизненного цикла разработки систем, но гораздо более подробная и более строгая, чем большинство британских практиков и тестировщиков понимают под V-моделью. ^{[13] [14] [3] [4] [15] [16]}

Иногда говорят, что валидацию можно выразить вопросом «Вы строите правильную вещь?», а верификацию — «Вы строите ее правильно?» На практике эти термины используются по-разному.

Руководство PMBOK , также принятое IEEE в качестве стандарта (совместно поддерживаемое INCOSE, Советом по системным исследованиям SERC и Компьютерным обществом IEEE), в своем 4-м издании определяет их следующим образом: ^[17]

• " Валидация. Гарантия того, что продукт, услуга или система соответствуют потребностям клиента и других определенных заинтересованных сторон. Часто включает в себя принятие и пригодность для внешних клиентов. Противопоставляется верификации . "
• « Проверка . Оценка того, соответствует ли продукт, услуга или система регламенту, требованию, спецификации или наложенному условию. Часто это внутренний процесс. Сравните с валидацией ».

V-модель обеспечивает руководство по планированию и реализации проектов. Следующие цели должны быть достигнуты в результате реализации проекта:

• Минимизация рисков проекта : V-модель улучшает прозрачность проекта и контроль проекта, определяя стандартизированные подходы и описывая соответствующие результаты и ответственные роли. Она позволяет на ранней стадии распознавать отклонения и риски планирования и улучшает управление процессами, тем самым снижая риск проекта.
• Улучшение и гарантия качества : Как стандартизированная модель процесса, V-модель гарантирует, что предоставляемые результаты являются полными и имеют желаемое качество. Определенные промежуточные результаты могут быть проверены на ранней стадии. Единообразное содержание продукта улучшит читаемость, понятность и проверяемость.
• Сокращение общей стоимости на протяжении всего жизненного цикла проекта и системы : усилия по разработке, производству, эксплуатации и обслуживанию системы можно рассчитать, оценить и контролировать прозрачным образом, применяя стандартизированную модель процесса. Полученные результаты единообразны и легко отслеживаются. Это снижает зависимость приобретателя от поставщика и усилия для последующих действий и проектов.
• Улучшение коммуникации между всеми заинтересованными сторонами : стандартизированное и единообразное описание всех соответствующих элементов и терминов является основой для взаимопонимания между всеми заинтересованными сторонами. Таким образом, потери от трения между пользователем, приобретателем, поставщиком и разработчиком сокращаются.

Процесс системной инженерии (SEP) обеспечивает путь к повышению экономической эффективности сложных систем, которую владелец системы ощущает на протяжении всего срока службы системы, от концепции до вывода из эксплуатации. ^[1]

Он включает в себя раннее и всестороннее определение целей, концепцию операций, описывающую потребности пользователей и операционную среду, тщательные и проверяемые системные требования, детальное проектирование, реализацию, строгое приемочное тестирование внедренной системы для обеспечения ее соответствия заявленным требованиям (проверка системы), измерение ее эффективности в достижении целей (проверка системы), текущую эксплуатацию и обслуживание, модернизацию системы с течением времени и, в конечном итоге, вывод из эксплуатации. ^{[1] [3] [4] [7]}

Процесс подчеркивает проектирование и тестирование, основанные на требованиях. Все элементы дизайна и приемочные испытания должны прослеживаться до одного или нескольких системных требований, и каждое требование должно быть рассмотрено по крайней мере одним элементом дизайна и приемочным испытанием. Такая строгость гарантирует, что ничего не будет сделано лишнего, и все необходимое будет выполнено. ^{[1] [3]}

Поток спецификаций в основном состоит из:

• Спецификации требований пользователя
• Спецификации функциональных требований
• Технические характеристики конструкции

Поток тестирования обычно состоит из:

• Квалификация монтажа (IQ)
• Эксплуатационная квалификация (OQ)
• Квалификация производительности (PQ)

Поток разработки может состоять (в зависимости от типа системы и объема разработки) из настройки, конфигурирования или кодирования.

V-модель используется для регулирования процесса разработки программного обеспечения в рамках немецкой федеральной администрации. В настоящее время ^{[ когда? ]} она по-прежнему является стандартом для немецкой федеральной администрации и оборонных проектов, а также разработчиков программного обеспечения в регионе.

Концепция V-модели была разработана одновременно, но независимо, в Германии и США в конце 1980-х годов:

• Немецкая V-модель была первоначально разработана IABG в Оттобрунне, недалеко от Мюнхена, в сотрудничестве с Федеральным ведомством по оборонным технологиям и закупкам в Кобленце, для Федерального министерства обороны. Она была принята Федеральным министерством внутренних дел для сферы гражданских государственных органов летом 1992 года. ^[19]
• Американская V-модель, описанная в протоколах Национального совета по системной инженерии (NCOSE; с 1995 года — INCOSE) 1991 года ^[7] , была разработана для спутниковых систем, включающих аппаратное обеспечение, программное обеспечение и взаимодействие с человеком.
• Модель V впервые появилась в Hughes Aircraft около 1982 года как часть предварительного предложения по программе FAA Advanced Automation System (AAS). В конечном итоге она сформировала стратегию тестирования для предложения Hughes AAS Design Competition Phase (DCP). Она была создана, чтобы продемонстрировать подход к тестированию и интеграции, который был обусловлен новыми проблемами выявления скрытых дефектов в программном обеспечении. Необходимость в этом новом уровне обнаружения скрытых дефектов была обусловлена ​​целью начать автоматизировать процессы мышления и планирования авиадиспетчера, как это было предусмотрено программой автоматизированного управления воздушным движением на маршруте (AERA). Причина, по которой V настолько мощна, заключается в культуре Hughes, заключающейся в объединении всего текста и анализа с многомерными изображениями. Она была основой последовательной тематической организации публикаций (STOP) ^[20], созданной Hughes в 1963 году и использовавшейся до тех пор, пока Hughes не был продан Медицинским институтом Говарда Хьюза в 1985 году. ^[21]
• Министерство обороны США помещает взаимодействия процессов системной инженерии в V-образную модель взаимоотношений. ^[22]

В настоящее время он нашел широкое применение в коммерческих и оборонных программах. Его основное применение — управление проектами ^{[3] [4]} и на протяжении всего жизненного цикла проекта.

Одной из основных характеристик модели US V является то, что время и зрелость движутся слева направо, и вернуться назад во времени невозможно. Все итерации происходят по вертикальной линии к более высоким или более низким уровням в иерархии системы, как показано на рисунке. ^{[3] [4] [7]} Это оказалось важным аспектом модели. Расширение модели до концепции dual-Vee рассматривается в ссылке. ^[3]

Поскольку V-модель общедоступна, многие компании также используют ее. В управлении проектами это метод, сопоставимый с PRINCE2 , и описывает методы управления проектами, а также методы разработки систем . V-модель, хотя и жесткая в процессе, может быть очень гибкой в ​​применении, особенно когда она относится к области, выходящей за рамки обычных параметров жизненного цикла разработки системы.

Вот преимущества V-модели по сравнению с другими моделями разработки систем:

• Пользователи V-модели участвуют в разработке и обслуживании V-модели. Контрольный совет по изменениям публично поддерживает V-модель. Контрольный совет по изменениям собирается где угодно от каждого дня до недели и обрабатывает все запросы на изменения, полученные во время разработки и тестирования системы. ^[23]
• V-модель предоставляет конкретную помощь в реализации действия и его рабочих этапов, четко определяя события, необходимые для завершения рабочего этапа: каждая схема действия содержит инструкции, рекомендации и подробные объяснения действия. ^[24]

Следующие аспекты не охватываются V-моделью, они должны регулироваться дополнительно, или V-модель должна быть адаптирована соответствующим образом: ^{[25] [26]}

• Размещение договоров на оказание услуг не регламентируется.
• Организация и выполнение эксплуатации, обслуживания, ремонта и утилизации системы не охватываются V-моделью. Однако планирование и подготовка концепции для этих задач регламентируются V-моделью.
• V-модель рассматривает разработку программного обеспечения в рамках проекта, а не всей организации.

• Управление инженерной информацией (EIM)
• ARCADIA (как метод моделирования вспомогательных систем)
• IBM Rational Unified Process (как вспомогательный программный процесс)
• Водопадная модель разработки программного обеспечения
• Архитектура систем
• Системное проектирование
• Системная инженерия
• Системная инженерия на основе моделей
• Теория У

На Викискладе есть медиафайлы по теме V-модели .

• "INCOSE G2SEBOK 3.30: Vee-модель системного проектирования и интеграции". g2sebok.incose.org . Международный совет по системному проектированию . Архивировано из оригинала 27.09.2007.
• "Das V-Modell XT". cio.bund.de (на немецком языке). Федеральное ведомство по информационной безопасности (BMI).
• «Использование V-моделей для тестирования». insights.sei.cmu.edu . Институт программной инженерии , Университет Карнеги-Меллона . 11 ноября 2013 г.