V-Model

редактировать
V-модель процесса системной инженерии.

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

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

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

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

Содержание
  • 1 Типы
    • 1.1 V-Modell
    • 1.2 Общие испытания
    • 1.3 Стандарт правительства США
  • 2 Валидация и проверка
  • 3 Цели
  • 4 Темы V-модели
    • 4.1 Системное проектирование и проверка
    • 4.2 Два потока
      • 4.2.1 Поток спецификаций
      • 4.2.2 Тестовый поток
  • 5 Приложения
  • 6 Преимущества
  • 7 Ограничения
  • 8 См. Также
  • 9 Ссылки
  • 10 Внешние ссылки
Типы

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

V-Modell

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

Общие положения тестирование

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

правительственный стандарт США

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

Валидация против верификации

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

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

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

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

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

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

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

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

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

Два потока

Спецификационный поток

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

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

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

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

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

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

Приложения
Альтернативы вне ядра (иллюстрирующие восходящие и нисходящие итерации и измерение «Время и зрелость»). Источник - К. Форсберг и Х. Мооз 2004

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

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

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

Теперь он нашел широкое применение как в коммерческих, так и в оборонных программах. Его основное использование - в управлении проектами и на протяжении всего жизненного цикла проекта.

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

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

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

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

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

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

  • Заключение договоров на оказание услуг не регулируется.
  • Организация и выполнение эксплуатации, технического обслуживания, ремонта и утилизации системы не покрываются V-модель. Однако планирование и подготовка концепции для этих задач регулируются V-моделью.
  • V-модель предназначена для разработки программного обеспечения в рамках проекта, а не всей организации.
См. Также
Ссылки
Внешние ссылки
На Викискладе есть материалы, связанные с V-модели.
Последняя правка сделана 2021-06-18 07:19:47
Содержание доступно по лицензии CC BY-SA 3.0 (если не указано иное).
Обратная связь: support@alphapedia.ru
Соглашение
О проекте