| Разработка программного обеспечения |
|---|
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-модель широко рассматривается как расплывчатое иллюстративное изображение процесса разработки программного обеспечения, описанного в программе для тестировщиков программного обеспечения Международной комиссии по квалификационным экзаменам. [12] Не существует единого определения этой модели, которое более подробно рассматривается в альтернативной статье о V-модели (разработка программного обеспечения) .
Стандарт правительства США [ править ]
У США также есть правительственная стандартная V-образная модель, которая, как и ее немецкий аналог, существует около 20 лет назад. Ее область применения - более узкая модель жизненного цикла разработки систем, но гораздо более подробная и более строгая, чем большинство британских практиков и тестировщиков понимают под V-моделью. [13] [14] [3] [4] [15] [16]
Проверка и проверка [ править ]
Иногда говорят, что валидацию можно выразить запросом «Правильно ли вы строите?» и проверка "Правильно ли вы строите?" На практике эти термины используются по-разному.
Руководство PMBOK , также принятое IEEE в качестве стандарта (совместно поддерживаемое INCOSE, Советом по системным исследованиям SERC и IEEE Computer Society), определяет их следующим образом в своем 4-м издании: [17]
- « Валидация. Гарантия того, что продукт, услуга или система удовлетворяет потребности клиента и других идентифицированных заинтересованных сторон. Это часто включает принятие и соответствие внешним клиентам. В отличие от проверки ».
- « Верификация . Оценка того, соответствует ли продукт, услуга или система регламенту, требованию, спецификации или наложенному условию. Это часто внутренний процесс. В отличие от валидации ».
Цели [ править ]
V-модель обеспечивает руководство для планирования и реализации проектов. При реализации проекта предполагается достичь следующих целей:
- Минимизация рисков проекта : V-модель улучшает прозрачность проекта и контроль над проектом, определяя стандартизированные подходы и описывая соответствующие результаты и ответственные роли. Это позволяет заблаговременно распознавать отклонения и риски от планирования и улучшает управление процессами, снижая, таким образом, риск проекта.
- Улучшение и гарантия качества : как стандартизированная модель процесса V-модель обеспечивает полноту и желаемое качество получаемых результатов. Определенные промежуточные результаты можно проверить на ранней стадии. Единое содержание продукта улучшит читаемость, понятность и проверяемость.
- Снижение общих затрат на протяжении всего жизненного цикла проекта и системы : затраты на разработку, производство, эксплуатацию и обслуживание системы могут быть рассчитаны, оценены и контролируются прозрачным образом с применением стандартизированной модели процесса. Полученные результаты единообразны и легко прослеживаются. Это снижает зависимость покупателя от поставщика и снижает затраты на последующие действия и проекты.
- Улучшение коммуникации между всеми заинтересованными сторонами : стандартизованное и единообразное описание всех соответствующих элементов и терминов является основой взаимопонимания между всеми заинтересованными сторонами. Таким образом, снижаются потери на трение между пользователем, эквайером, поставщиком и разработчиком.
Темы V-модели [ править ]
Системная инженерия и проверка [ править ]
Процесс системной инженерии (SEP) обеспечивает путь для повышения экономической эффективности сложных систем, как показывает опыт владельца системы на протяжении всего срока службы системы, от концепции до вывода из эксплуатации. [1]
Он включал раннее и всестороннее определение целей, концепцию операций, описывающую потребности пользователей и операционную среду, всесторонние и проверяемые системные требования, подробный проект, реализацию, тщательное приемочное тестирование внедренной системы, чтобы убедиться, что она соответствует заявленным требованиям (проверка системы ), измерение ее эффективности в достижении целей (проверка системы), текущая эксплуатация и обслуживание, обновления системы с течением времени и возможный вывод из эксплуатации. [1] [3] [4] [7]
Особое внимание в процессе уделяется проектированию и тестированию на основе требований. Все элементы дизайна и приемочные испытания должны быть прослеживаемыми до одного или нескольких системных требований, и каждое требование должно быть удовлетворено, по крайней мере, одним элементом дизайна и приемочными испытаниями. Такая строгость гарантирует, что ничего не будет сделано без необходимости, а все необходимое будет выполнено. [1] [3]
Два потока [ править ]
Лента спецификаций [ править ]
Поток спецификации в основном состоит из:
- Спецификации требований пользователя
- Спецификации функциональных требований
- Технические характеристики конструкции
Лента тестирования [ править ]
Поток тестирования обычно состоит из:
- Квалификация установки (IQ)
- Операционная квалификация (OQ)
- Квалификация производительности (PQ)
Поток разработки может состоять (в зависимости от типа системы и объема разработки) настройки, конфигурации или кодирования.
Приложения [ править ]
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
Ссылки [ править ]
- ^ a b c d Концепция операций Clarus. Архивировано 5 июля 2009 г. в Wayback Machine , публикация № FHWA-JPO-05-072, Федеральное управление шоссейных дорог (FHWA), 2005 г.
- ^ "The Dangerous & Seductive V Model" , просмотрено 9 января 2013 г.
- ^ a b c d e f g h Форсберг, К., Мооз, Х., Коттерман, Х. Визуализация управления проектами, 3-е издание, John Wiley and Sons, New York, NY, 2005. Страницы 108-116, 242-248 , 341-360.
- ^ a b c d e Международный совет по системной инженерии (INCOSE), Справочник по системной инженерии, версия 3.1, август 2007 г., страницы с 3.3 по 3.8
- ^ Форсберг, К., MOOZ, H. (1998). «Системная инженерия для более быстрого, дешевого, лучшего» (PDF) . Центр системного менеджмента. Архивировано из оригинального (PDF) 20 апреля 2003 года. Цитировать журнал требует
|journal=( помощь )CS1 maint: несколько имен: список авторов ( ссылка ) - ^ "ЮВ ВЭЭ" . SEOR, Университет Джорджа Мейсона. Архивировано из оригинального 18 октября 2007 года . Проверено 26 мая 2007 года .
- ^ a b c d e Форсберг, К. и Мооз, Х., «Взаимосвязь системной инженерии и проектного цикла». Архивировано 27 февраля 2009 г. на Wayback Machine , первом ежегодном симпозиуме Национального совета по системной инженерии (NCOSE ), Октябрь 1991 г.
- ^ "Сайт V-Modell (на немецком языке)" , по состоянию на 10 июля 2020 г.
- ^ Немецкая директива 250, Стандарт разработки программного обеспечения для Федеральных вооруженных сил Германии, V-модель, Модель процесса жизненного цикла программного обеспечения, август 1992 г.
- ^ "Основы V-Modell" . Дата обращения 14 апреля 2016 .
- ^ "V-Modell XT, Часть 1: Основы V-Modell" (PDF) . Дата обращения 14 апреля 2016 .
- ^ "International Software Testing Qualification Board - Foundation Level Syllabus" , по состоянию на 9 января 2013 г.
- ^ "Системная инженерия для интеллектуальных транспортных систем" (PDF) . Министерство транспорта США. п. 10 . Проверено 9 июня 2007 года .
- ^ «Департамент транспорта США, Федеральное управление шоссейных дорог. Руководство по системному проектированию для ИТС» , просмотрено 9 января 2013 г.
- ^ «СОЗДАНИЕ НАСЛЕДИЕ: ОБНОВЛЕННЫЙ ФОКУС НА РАЗРАБОТКЕ СИСТЕМ В ОБОРОНЕ ПРИОБРЕТЕНИЯ» (PDF) . Дата обращения 14 апреля 2016 .
- ^ «Использование V-моделей для тестирования» . Дата обращения 14 апреля 2016 .
- ^ IEEE . Руководство IEEE - Принятие стандарта Института управления проектами (PMI). Руководство к своду знаний по управлению проектами (Руководство PMBOK) - четвертое издание . п. 452. DOI : 10,1109 / IEEESTD.2011.6086685 . ISBN 978-0-7381-6817-3. Проверено 7 декабря 2012 года .
- ^ Основы системной инженерии. Издательство Defense Acquisition University Press, 2001.
- ^ "Модель процесса жизненного цикла V-модели" . v-modell.iabg.de. Архивировано из оригинала 3 марта 2016 года . Проверено 24 декабря 2015 года .
- ^ «Последовательная тематическая организация публикаций (СТОП)» . Архивировано из оригинала 3 февраля 2008 года . Проверено 24 декабря 2015 года .
- ^ Sobkiw, Вальтер (2008-01-01). Устойчивое развитие возможно с творческой системной инженерией . ISBN 978-0615216300.
- ^ «Новая модель системного проектирования и старый, знакомый друг; Рис. 2 Взаимодействия процессов V-9» (PDF) . Защита AT&L. Апр 2006. с. 51 . Дата обращения 7 апреля 2016 .
- ^ «Дальнейшее развитие V-Modell (неработающая ссылка)» . v-modell.iabg.de. Архивировано из оригинального 23 апреля 2011 года . Проверено 24 декабря 2015 года .
- ^ «Обзор модели деятельности V-Modell (неработающая ссылка)» . v-modell.iabg.de. Архивировано из оригинального 19 июля 2011 года . Проверено 24 декабря 2015 года .
- ^ "Пределы модели" . v-modell.iabg.de. Архивировано из оригинального 21 мая 2011 года . Проверено 24 декабря 2015 года .
- ^ Кристиан Буканак, V-модель
Внешние ссылки [ править ]
 | Викискладе есть медиафайлы по теме V-моделей . |
- «INCOSE G2SEBOK 3.30: Vee-модель системного проектирования и интеграции» . g2sebok.inosis.org . Международный совет по системной инженерии . Архивировано из оригинала на 2007-09-27.
- "Das V-Modell XT" . cio.bund.de (на немецком языке). Федеральное ведомство по информационной безопасности (BMI).
- «Использование V-моделей для тестирования» . insights.sei.cmu.edu . Институт программной инженерии , Университет Карнеги-Меллона . 11 ноября 2013 г.
