Сравнение моделей
| Сравнение моделей | V-Model | Прототипирование |
| Год появления | в конце 1980-х | в середине 1980-х |
| Количество основных этапов | 1.Анализ требований 2.Проектирование системы 3.Архитектурный дизайн 4.Разработка модулей | 1.Накопление требований 2.Интенсивное планирование 3.Итерация улучшения прототипа |
| Суть модели | Она предполагает, что тестирование продукта обсуждается и планируется на ранних этапах жизненного цикла разработки. | Модель прототипитования позволяет создать прототип программного продукта до или в течение этапа составления требований к программному продукту. |
| Составление анализа и списка требований | Да | Да |
| Сложность в использовании | Следующая фаза начинается только после завершения предыдущей. | Для работы нужны высококвалифицированные кадры |
| Контроль рисков | Hедостаточный анализ рисков | Oбеспечивается управление рисками |
| Внесение изменений | Hедостаточная гибкость модели | Позволяет вносить изменения |
| Применение | V-Model (или VEE модель) является моделью разработки информационных систем (ИС), направленной на упрощение понимания сложностей, связанных с разработкой систем. Она используется для определения единой процедуры разработки программных продуктов, аппаратного обеспечения и человеко-машинных интерфейсов. | Быстрое прототипирование особенно хорошо подходит для разработки интенсивно используемых систем пользовательского интерфейса, таких как индикаторные панели для контрольных приборов, интерактивные системы, новые в своем роде продукты, а также системы обеспечения принятия решений, среди которых можно назвать подачу команд, управление или медицинскую диагностику. |
| Затраты | Низкие | Высокие |
| Плюсы | + строгая этапизация; + планирование тестирования и верификация системы производятся на ранних этапах; + улучшенный, по сравнению с каскадной моделью, тайм-менеджмент; + промежуточное тестирование. | + конечный пользователь может «увидеть» системные требования в процессе их сбора командой разработчиков; таким образом, взаимодействие заказчика с системой начинается на раннем этапе разработки; + исходя из реакции заказчиков на демонстрации разрабатываемого продукта, разработчики получают сведения об одном или нескольких аспектах поведения системы, благодаря чему сводится к минимуму количество неточностей в требованиях; + снижается возможность возникновения путаницы, искажения информации или недоразумений при определении системных требований, что несомненно приводит к созданию более качественного конечного продукта; + в процесс разработки можно внести новые или неожиданные требования пользователя, что порой необходимо, так как реальность может отличаться от концептуальной модели реальности; + модель представляет собой формальную спецификацию, воплощенную в рабочую модель; + модель позволяет выполнять гибкое проектирование и разработку, включая несколько итераций на всех фазах жизненного цикла; + благодаря меньшему объему доработок уменьшаются затраты на разработку; + благодаря тому что проблема выявляется до привлечения дополнительных ресурсов сокращаются общие затраты; + обеспечивается управление рисками; + документация сконцентрирована на конечном продукте, а не на его разработке. |
| Минусы | – недостаточная гибкость модели; – собственно создание программы происходит на этапе написания кода, то есть уже в середине процесса разработки; -недостаточный анализ рисков; – нет работы с параллельными событиями и возможности динамического внесения изменений. Когда использовать V-модель: – В проектах, в которых существуют временные и финансовые ограничения; – Для задач, которые предполагают более широкое, по сравнению с каскадной моделью, тестовое покрытие. | – с учетом создания рабочего прототипа, качеству всего ПО или долгосрочной эксплуатационной надежности может быть уделено недостаточно внимания. – иногда в результате использования модели получают систему с низкой рабочей характеристикой, особенно если в процессе ее выполнения пропускается этап подгонки; – при использовании модели решение трудных проблем может отодвигаться на будущее. В результате это приводит к тому, что последующие полученные продукты могут не оправдать надежды, которые возлагались на прототип; – если пользователи не могут участвовать в проекте на итерационной фазе быстрого прототипирования жизненного цикла, на конечном продукте могут отразиться неблагоприятные воздействия, включая проблемы, связанные с его качественной характеристикой; – на итерационном этапе прототипирования быстрый прототип представляет собой частичную систему. Если выполнение проекта завершается досрочно, у конечного пользователя останется только лишь частичная система; – если язык или среда прототипирования не сочетаются с производственным языком или окружением, всесторонняя реализация продукционной системы может быть задержана; – прототипирование вызывает зависимость и может продолжаться слишком долго. Нетренированные разработчики могут попасть в так называемый цикл «кодирование — устранение ошибок» (code-and-fix cycle), что приводит к дорогостоящим незапланированным итерациям прототипирования; – структурные методы не используются, чтобы не помешать выполнению анализа. При прототипировании необходимо провести «реальный» анализ требований, осуществить проектирование и обратить внимание на качество с целью создания программы, допускающей сопровождение, точно так же, как и в любой другой модели жизненного цикла (хотя на эти действия может понадобиться меньше времени и ресурсов). |
Сравнение моделей
[googleapps domain=”docs” dir=”forms/d/e/1FAIpQLSet0GmFvKuBnbFo3KRzW-6myW4hJq_Rvhq8gm1bqzzzJzMjCw/viewform” query=”embedded=true” width=”640″ height=”1119″ /]