| Prototüüpimine | V-mudell | |
| Год появления | 1970 | в конце 1980-х |
| Количество основных этапов | 3 | 4 |
| Суть модели | процесс создания (с применением определенных методов или технологий) какого-то физического объекта для конкретных целей | усовершенствованная каскадная модель, в которой заказчик с командой программистов одновременно составляют требования к системе и описывают, как будут тестировать её на каждом этапе |
| Составление анализа и списка требований | Определение целей, сбор информации и анализ требований. | Сбор требований закасчика, определение типов требований. |
| Сложность в использовании | Доступность данных и ресурсов | Долгий цикл разработки |
| Контроль рисков | Опыт команды | Ограничение гибкости |
| Внесение изменений | Изменения в требований | Жесткая последовательность |
| Применение | машино- и приборостроении, программировании и во многих других областях техники | для управления процессом разработки программного обеспечения для немецкой федеральной администрации |
| Затраты | Сложность проекта | Подходит не для всех проектов |
| Плюсы | 1. Заказчик всегда видит прогресс в процессе разработки программного продукта 2. В процессе разработки всегда можно учесть новые, даже неожиданные требования заказчика 3. Благодаря реакции заказчика на прототип сводится к минимуму число неточностей в требованиях 4. Взаимодействие заказчика с разрабатываемой системой начинается на раннем этапе 5. Прототип представляет собой формальную спецификацию, воплощенную в программный продукт | 1. В модели предусмотрены аттестация и верификация всех внешних и внутренних полученных данных, а не только самого программного продукта 2. Модель определяет продукты, которые должны быть получены в результате процесса разработки, причём каждые полученные данные должны подвергаться тестированию. 3. Благодаря модели менеджеры проекта могут отслеживать ход процесса разработки, так как в данном случае вполне возможно воспользоваться временной шкалой, а завершение каждой фазы является контрольной точкой 4. В V-образной модели определение требований выполняется перед разработкой проекта системы, а проектирование ПО — перед разработкой компонентов 5. В модели особое значение придается планированию, направленному на верификацию и аттестацию разрабатываемого продукта на ранних стадиях его разработки. |
| Минусы | 1. Решение сложных задач может отодвигаться на будущее 2. Прототипирование может неоправданно затянуться 3. Перед началом работы неизвестно, сколько итераций придется выполнить 4. Заказчик может предпочесть получить прототип, а не законченную полную версию программного продукта; | 1. Модель не предусматривает работу с параллельными событиями 2. В модели не предусмотрено внесение требования динамических изменений на разных этапах жизненного цикла 3. Тестирование требований в жизненном цикле происходит слишком поздно, вследствие чего невозможно внести изменения, не повлияв при этом на график выполнения проекта 4. В модель не входят действия, направленные на анализ рисков 5. Некоторый результат можно посмотреть только при достижении низа буквы V |
Главная страница »