V-модель – это улучшенная версия классической каскадной модели. Здесь на каждом этапе происходит контроль текущего процесса, для того чтобы убедится в возможности перехода на следующий уровень. В этой модели тестирование начинается еще со стадии написания требований, причем для каждого последующего этапа предусмотрен свой уровень тестового покрытия.
1.Концепция V-образной модели была разработана Германией и США в конце 1980-х годов независимо друг от друга:
- Немецкая V-модель была разработана аэрокосмической компанией IABG в Оттобрунне рядом с Мюнхеном в содействии с Федеральным департаментом по закупке вооружений в Кобленце, для Министерства обороны Германии. Модель была принята немецкой федеральной администрацией для гражданских нужд летом 1992[1].
- Американская V-Model (VEE) была разработана национальным советом по системной инженерии (международным — с 1995 года) для спутниковых систем, включая оборудование, программное обеспечение и взаимодействие с пользователями.
Современной версией V-Model является V-Model XT, которая была утверждена в феврале 2005 года. V-модель используется для управления процессом разработки программного обеспечения для немецкой федеральной администрации. Сейчас она является стандартом для немецких правительственных и оборонных проектов, а также для производителей ПО в Германии. V-Model представляет собой скорее набор стандартов в области проектов, касающихся разработки новых продуктов. Эта модель во многом схожа с PRINCE2 и описывает методы как для проектного управления, так и для системного развития.
2. Цикл состоит из нескольких этапов — планирование и анализ потребностей, определение требований, проектирование архитектуры продукта, создание или разработка продукта, тестирование продукта, развертывание на рынке и сопровождение.
3.
4. Плюсы и минусы V-модели:
+ строгая этапизация;
+ планирование тестирования и верификация системы производятся на ранних этапах;
+ улучшенный, по сравнению с каскадной моделью, тайм-менеджмент;
+ промежуточное тестирование.
— недостаточная гибкость модели;
— собственно создание программы происходит на этапе написания кода, то есть уже в середине процесса разработки;
— недостаточный анализ рисков;
— нет работы с параллельными событиями и возможности динамического внесения изменений.
5.
| Название модели | V-модель | Водопадная модель |
| Год появления | конец 1980-х | 1970 |
| Количество основных этапов | 9 | 5 |
| Суть модели | Следование фиксированной последовательности | 1.следующий этап должен начинаться только после окончания предыдущего; перескакивать через этапы нельзя; 2.возвращаться на предыдущие этапы, чтобы что-то изменить, нельзя; 3.если изменились требования — переделываем ТЗ; 4.ошибки выявляют и исправляют только во время тестирования; 5. клиент не участвует в работе над проектом после создания ТЗ. |
| Составление анализа и списка требований | Требования определены заранее. До начала всей работы. | Требования. Самый первый этап, во время которого определяют и анализируют требования проекта: системные требования, требования к ПО, пожелания заказчика и т. д. и т. п. На основе всей этой информации создают входную документацию, где описывают, что должно получиться в итоге (не важно, что это будет — софт или авианосец), но не то, как именно это всё нужно будет делать. Короче, на этом этапе пишут первую, обобщённую, версию ТЗ. |
| Сложность в использовании | Все требования должны быть сразу известны. Сделать это очень сложно, потому что заказчик часто и сам не знает, чего он хочет. В таких ситуациях гибкие методологии сподручнее. | |
| Внесение изменений | Если при разработке архитектуры была допущена ошибка, то вернуться и исправить её будет стоить дорого, как и в «водопаде». | При работе с каскадной моделью основная задача — написать подробные требования к разработке. На этапе тестирования не должно выясниться, что в них есть ошибка, которая влияет на весь продукт. |
| Применение | Проекты со стабильными требованиями | Waterfall подойдёт, если: Заказчик хорошо понимает, что хочет. У него есть проработанная концепция, которая не изменится. Заказчик не планирует участвовать в проекте после принятия ТЗ, а полностью отдаёт его на аутсорс. Заказчик хочет заранее знать точные сроки и результаты каждого этапа. Заранее понятно, что, как и с помощью каких инструментов нужно будет делать. Это сложный продукт, который требует очень много затрат, и у которого есть очень чёткая последовательность разработки (сомнительно, что подводные лодки когда-нибудь будут делать по Agile). |
| Затраты | Дорогие измненения | Дорогие измненения |
| Плюсы | Количество ошибок в архитектуре ПО сводится к минимуму. | Разработку просто контролировать. Заказчик всегда знает, чем сейчас заняты программисты, может управлять сроками и стоимостью. Стоимость проекта определяется на начальном этапе. Все шаги запланированы уже на этапе согласования договора, ПО пишется непрерывно «от и до». Не нужно нанимать тестировщиков с серьёзной технической подготовкой. Тестировщики смогут опираться на подробную техническую документацию. |
| Минусы | Если при разработке архитектуры была допущена ошибка, то вернуться и исправить её будет стоить дорого, как и в «водопаде». | Тестирование начинается на последних этапах разработки. Если в требованиях к продукту была допущена ошибка, то исправить её будет стоить дорого. Тестировщики обнаружат её, когда разработчик уже написал код, а технические писатели — документацию. Заказчик видит готовый продукт в конце разработки и только тогда может дать обратную связь. Велика вероятность, что результат его не устроит. Разработчики пишут много технической документации, что задерживает работы. Чем обширнее документация у проекта, тем больше изменений нужно вносить и дольше их согласовывать. |