Dual Vee Model

Разработка программного обеспечения

Процесс разработки ПО
Шаги процесса
Анализ • Проектирование • Программирование • Документирование • Тестирование
Модели
Итеративная • Спиральная • Каскадная • V-Model • Dual Vee Model
Методологии
Agile (XP, Lean, Scrum, FDD и др.) • Cleanroom • OpenUP • RAD • RUP • MSF • DSDM • TDD
Сопутствующие дисциплины
Конфигурационное управление • Управление проектами • Управление требованиями

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

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

Предпосылка

Модель водопада

Немодифицированная модель водопада.

Модель Водопада разбивает процесс разработки на разработку фаз. Название подразумевает, что проектные решения вытекают из требований, реализация вытекает из проекта и т. д. В большом проекте много различных людей работают только над определёнными частями проекта. Так проектировщик может спросить: «Что я пытаюсь спроектировать?» и ответ может быть: «Вы пытаетесь спроектировать что-то, что будет удовлетворять требованиям к продукту.» Разработчик может спросить: «Что я пытаюсь разработать?» и ответ может быть: «Вы пытаетесь разработать то, что было спроектировано.» и т. п.

V-Model

V-Model процесса разработки ИС.^[1]

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

Это ставит требования в начало рядом с функционированием продукта в конце и проектирование рядом с проверкой. Это имеет смысл, так как когда разработчик поставляет продукт клиенту, клиент может спросить: «Почему я должен принять этот продукт?» и разработчик должен ответить: «Потому что он отвечает вашим (клиентским) требованиям». Требования связаны с функционированием. При выполнении тестирования продукта, инженер-тестировшик может спросить: «Какие тесты я должен провести?» и проектировщик должен ответит: «Вы должны провести тесты, чтобы показать продукт, который был построен в соответствии с проектом.» Проверка связана с проектом. V-модель может быть расширена в нескольких направлениях для удовлетворения системных требований. Это может включать в себя семь INCOSE слоев сложности системы (например система, элемент, подсистема, сборка, подсборка, компонент и часть). Это может включать в себя разбиение, определение, интеграцию и проверку. Также это может включать участие пользователей/заинтересованных сторон, управление рисками и решения проблем.

Dual Vee Model

Двойная V модель основывается на V модели для управления системой систем. Архитектура V управляет системой и набором ветвей V модели исходящих из V архитектуры для управления подсистемами. Например, GPS включает в себя совокупность спутников, наземную сеть управления и миллионы пользователей по всему миру. Каждый спутник, наземный центр управления и GPS приёмник представляют собой сложную систему, которая может находиться под управлением отдельного объекта V модели. Разработка спутника может повлиять на проектирование, производство или стоимость приёмников. Подобно разработка приёмника может повлиять на проект, производство и стоимость спутников. Так что всё должно быть интегрировано в систему систем, которая разрабатывается в рамках более крупной Vee Архитектуры.

Vee Архитектура

При разработке сложных систем, системный инженер должен управлять итоговой конфигурацией системы от начала и до конца. Итоговая конфигурация может включать проектную документацию, руководства по эксплуатации, сам продукт и должна отвечать на вопросы Что, Почему? и Кто? по архитектуре системы. На каждой фазе разработки будут изменения в системе, которые приведут к изменению итоговой конфигурации. Ядро Vee является разивающаюся модель от начальных требований к готовой системе. Vee Архитектура отвечает на вопросы что, почему и кто (какой уровень системы) отвечает за архитектуру системы. Нисходящие из V ядра исследования усиливают процесс получения знаний для подтверждения итоговых архитектурных решений сделанных в ядре V. Восходящие из ядра взаимодействия с клиентами и пользователями усиливают поэтапное подтверждение поддерживая вовлечённость заинтересованных лиц в конечном продукте. Необходимо обратить внимание на то, что во всех V моделях представление времени и завершённости продукта движется слева направо. Так же как мы не можем перемещаться назад во времени, также мы не можем двигаться справа налево в V моделях. Последовательное приближение — это основное в разработке системы и все шаги делаются вертикально от ядра, вверх к пользователям и клиентам (что есть поэтапное подтверждение) и вниз к управлению рисками и новыми возможностями.

Левая ветвь Vee ядра сосредоточена вокруг того, какая концепция лучше и какая архитектура лучше для этой концепции. Например, коммерческие продукты обычно сталкиваются с дилеммой: батареи должны быть стандартными, уникальными, заменяемые или нет нисходящие из V ядра исследования и анализы могут ускорить определение наиболее желательного метода, который мог бы быть позже зафиксирован на V ядре если все заинтересованные лица согласны. Подобные исследования могут доказать жизнеспособность и технические возможности варианта концепции. Правая ветвь V ядра нисходящих исследований управляется на уровне исследования интеграционных аномалий для определения причин и устранения их. Восходящие взаимодействия с заинтересованными лицами определяют, согласны ли они с такой интеграцией и выполненной проверкой.

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

Структура V модели

Структура V модели показывает её разработку и реализацию, процесс который описывает как каждый объект будет получен (разработан, приобретён, повторно использован и т. д.) Модель Vee существует для каждого объекта архитектуры начиная с уровня системы вниз до уровня мельчайших конфигурационных элементов (LCI), такие как элементы компьютерного обеспечения или микросхемы. Все действия внутри объекта Vee находятся на том же самом уровне архитектура (Система, Подсистема, LCI). Левая ветвь Vee представляет определение модели, её развитие от черновых требований клиента, через определение концепции и до описания решения и полностью построенного образца. Правая ветвь Vee представляет последовательность сборки объекта и её гарантированная производительность, полученная посредством проверок и утверждений объекта.

В каждой разработке, существует зависимость между действиями на левой и правой ветви Объекта Vee. Это сделано специально. Метод проверки, которые будут использоваться в правой ветви Vee должны быть определены одновременно с разработкой требований на левой ветви, в противном случае могут быть созданы требования, которые не могут быть проверены. Например, «быть дружественным к пользователю» является подходящим требованием, но его проверить невозможно. Вместо этого, требование, которое утверждает что на экране компьютера может быть «не более пяти строк текста, набранным 14 шрифтом текста» определяет один пользовательский критерий требования «быть дружественным к пользователю» в измеримых величинах. План проверок должны быть согласован и зафиксирован чтобы гарантировать, что требования к проверкам и их методы известны и запланированы на этапе принятия решения по разработке, называемого Проверка Предварительного Проекта (Preliminary Design Review (PDR)). Черновые процедуры проверок основанные на требованиях к проверкам, плане проверок, и предложенном проекте объекта должны быть известны на этапе принятия решения по созданию и программированию, обычно называемом Окончательная Оценка Разработки (Critical Design Review (CDR)). Это снижает вероятность того, что проверка, в том виде котором она определена не может, быть выполнена. Вертикальное размер Vee Объекта это зафиксированная разработка на выбранном уровне архитектуры и ядро Vee Объекта представляющее итоговую последовательность разработки объекта. Также включены (по аналогии с Vee Архитектурой) действия, связанные с управлением возможностями и рисками, осуществляемые в нисходящем от ядра объекта направлении до уровня необходимого для оценки и решения проблемы. Например, лабораторные испытания компьютерного чипа или программного обеспечения могут быть необходимы для подтверждения технической пригодности.

В отличие от широко распространённого мнения о Модели Водопада, не существует запрета на выполнение пробной разработки и её анализа в любой точке проектного цикла для исследования или доказательства производительности или пригодности. В отличие от Спиральной Модели, в Vee модели исследования возможностей и рисков могут быть выполнены последовательно или в параллель с основной разработкой, а не проводиться постфактум или до процесса разработки решения. Аппаратные и программные требования понимания моделей или технической пригодности моделей приветствуются в начале проектного цикла для реализации таких возможностей, как новые технологии, и для снижения риска. Например, для оценки концепции ручной корректировки текста в сравнении с полностью автоматической корректировкой, техническая пригодность обоих концепций может быть смоделирована и выбор может быть сделан на основе сравнения времени и стоимости решений. Согласие клиента может также обеспечить необходимое в проектном цикле утверждение более предпочтительного метода.

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

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

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

Распределение точек принятия решения

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

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

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

Примечания

1. ↑ Clarus Concept of Operations. Publication No. FHWA-JPO-05-072, Federal Highway Administration (FHWA), 2005