Dual Vee Model

Материал из Википедии — свободной энциклопедии
Перейти к навигации Перейти к поиску
Разработка программного обеспечения
Процесс разработки ПО
Ключевые процессы
Анализ • Проектирование • Программирование • Конструирование • Тестирование • Отладка • Развёртывание • Сопровождение • Документирование
Парадигмы и модели
Agile • Cleanroom • Итеративная • Спиральная • Каскадная • V-Model • Dual Vee Model
Методологии
ASD • DevOps • DAD • DSDM • FDD • Канбан • Lean SD • LeSS • MDD • MSF • PSP • OpenUP • RAD • RUP • SAFe • Scrum • TSP • UP • XP
Инструменты
Компилятор • Отладчик • Профилирование • GUI-конструктор • ИСР • Автоматизация сборки • Автоматизация релиза • Инструменты тестирования

Dual Vee Model основывается на V-модели, чтобы показать сложности, связанные с проектированием и разработкой систем.

Модель изображает одновременное развитие архитектуры системы как одной V-модели с каждым объектом этой архитектуры как другую V модель, которая пересекает архитектуру V модели. Это явно показывает взаимодействия и последовательности в разработке сложных систем и систем систем.

Двойная Vee: Перекрещивающаяся архитектура и Модели Vee[править | править код]

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

Распределение точек принятия решения[править | править код]

Архитектурные объекты разрабатываются и интегрируются в архитектуру системы в заранее определённой последовательности в соответствии с лучшими примерами системной инженерии.

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

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

Примечания[править | править код]