V-модель - V-Model

Информацию о версии, относящейся к разработке программного обеспечения, см. V-Model (разработка программного обеспечения).

V-модель процесса системной инженерии.^[1]

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

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

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

Подтверждение может быть выражено запросом «Правильно ли вы строите?» и проверка "Правильно ли вы строите?"

Типы

Есть три основных типа V-модели.

V-Modell

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

Общее тестирование

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

Государственный стандарт США

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

Проверка и проверка

Основные статьи: Верификация и валидация и Валидация (производство лекарств)

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

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

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

Цели

V-модель предоставляет руководство для планирования и реализации проектов. При реализации проекта предполагается достичь следующих целей:

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

Темы V-модели

Системная инженерия и проверка.^[18]

Системная инженерия и проверка

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

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

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

Два потока

Спецификация потока

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

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

Поток тестирования

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

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

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

Приложения

Альтернативы вне ядра (иллюстрирующие восходящие и нисходящие итерации и измерение времени и зрелости). Источник - К. Форсберг и Х. Мооз, 2004 г.^[3][7]

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

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

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

Сейчас он нашел широкое применение как в коммерческих, так и в оборонных программах. Его основное использование - управление проектами.^[3][4] и на протяжении всего жизненного цикла проекта.

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

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

Преимущества

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

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

Пределы

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

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

Смотрите также

• IBM Rational Unified Process (как вспомогательный программный процесс)
• Системная архитектура
• Системный дизайн
• Теория U

Рекомендации

1. Концепция операций Clarus В архиве 2009-07-05 на Wayback Machine, Публикация № FHWA-JPO-05-072, Федеральное управление шоссейных дорог (FHWA), 2005 г.
2. "Опасная и соблазнительная модель V", по состоянию на 9 января 2013 г.
3. Форсберг, К., Мооз, Х., Коттерман, Х. Визуализация управления проектами, 3-е издание, John Wiley and Sons, New York, NY, 2005. Pages 108-116, 242-248, 341-360.
4. Международный совет по системной инженерии (INCOSE), Справочник по системному проектированию, версия 3.1, Август 2007 г., страницы 3.3–3.8.
5. Форсберг, К., Мооз, Х. (1998). «Системное проектирование для более быстрого, дешевого, лучшего» (PDF). Центр системного менеджмента. Архивировано из оригинал (PDF) 20 апреля 2003 г.
6. «ЮВ ВЭЭ». SEOR, Университет Джорджа Мейсона. Архивировано из оригинал 18 октября 2007 г.. Получено 26 мая, 2007.
7. Форсберг, К. и Мооз, Х., «Связь системной инженерии с проектным циклом» В архиве 2009-02-27 на Wayback Machine, Первый ежегодный симпозиум Национального совета по системной инженерии (NCOSE), октябрь 1991 г.
8. "Сайт V-Modell (на немецком языке)", по состоянию на 10 июля 2020 г.
9. Директива Германии 250, Стандарт разработки программного обеспечения для Федеральных вооруженных сил Германии, V-модель, Модель процесса жизненного цикла программного обеспечения, август 1992 г.
10. «Основы V-Modell». Получено 14 апреля 2016.
11. "V-Modell XT, Часть 1: Основы V-Modell" (PDF). Получено 14 апреля 2016.
12. "Международная квалификационная комиссия по тестированию программного обеспечения - программа базового уровня", по состоянию на 9 января 2013 г.
13. «Системная инженерия для интеллектуальных транспортных систем» (PDF). Департамент транспорта США. п. 10. Получено 9 июня, 2007.
14. «Департамент транспорта США, Федеральное управление шоссейных дорог. Руководство по системному проектированию для ИТС», по состоянию на 9 января 2013 г.
15. «СОЗДАНИЕ НАСЛЕДИЕ: ОБНОВЛЕННЫЙ ФОКУС НА ИНЖЕНЕРНЫЕ СИСТЕМЫ ДЛЯ ОБОРОНЫ» (PDF). Получено 14 апреля 2016.
16. «Использование V-моделей для тестирования». Получено 14 апреля 2016.
17. IEEE. Руководство IEEE - Принятие стандарта Института управления проектами (PMI). Руководство к своду знаний по управлению проектами (Руководство PMBOK) - четвертое издание. п. 452. Дои:10.1109 / IEEESTD.2011.6086685. ISBN  978-0-7381-6817-3. Получено 7 декабря, 2012.
18. Основы системной инженерии. Издательство Defense Acquisition University Press, 2001.
19. «Модель процесса жизненного цикла V-Model». v-modell.iabg.de. Архивировано из оригинал 3 марта 2016 г.. Получено 24 декабря, 2015.
20. «Последовательная тематическая организация публикаций (СТОП)». Архивировано из оригинал 3 февраля 2008 г.. Получено 24 декабря, 2015.
21. Собкив, Уолтер (01.01.2008). Устойчивое развитие возможно с творческой системной инженерией. ISBN  978-0615216300.
22. «Новая модель системного проектирования и старый, знакомый друг; Рис. 2 V-9, взаимодействие процессов» (PDF). Защита AT&L. Апр 2006. с. 51. Получено 7 апреля 2016.
23. «Дальнейшее развитие V-Modell (неработающая ссылка)». v-modell.iabg.de. Архивировано из оригинал 23 апреля 2011 г.. Получено 24 декабря, 2015.
24. «Обзор модели деятельности V-Modell (неработающая ссылка)». v-modell.iabg.de. Архивировано из оригинал 19 июля 2011 г.. Получено 24 декабря, 2015.
25. «Границы ВМодели». v-modell.iabg.de. Архивировано из оригинал 21 мая 2011 г.. Получено 24 декабря, 2015.
26. Кристиан Буканак, V-модель

внешняя ссылка

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