6. Прототипная модель

Прототипная (prototyping) модель (Рис. 12) начинается с составления плана, после чего делается его быстрый анализ, создание некоторой базы данных, где будут копиться все данные о проекте и его рабочих продуктах, разрабатывается пользовательский интерфейс и после него разрабатываются прототипы, реализующие те функции, которые определяются спецификациями. Эти прототипы несколько раз совершенствуются, и дополняются новыми, которые реализуют все большее количество функций или реализуют их во все большем объеме.

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

Таким образом, подход прототипной модели состоит в построении «быстрой» частичной реализации системы до или во время фазы сбора требований. Заказчик или потенциальные пользователи некоторое время работают с этим прототипом и дают свои выводы о его сильных и слабых сторонах. Затем по этим заключениям изменяются спецификации требований, чтобы отразить реальные потребности заказчика.

Впоследствии на основании собранных требований может быть создан новый программный продукт уже с использованием другой модели ЖЦ, учитывающей эти новые обстоятельства. Для быстро устаревающих продуктов прототипная модель может быть удачным решением по соотношению затраты/результат.

Рис. 12. Прототипная модель

7. Выбор модели жизненного цикла

Выбор той или иной модели жизненного цикла обычно диктуется особенностями проекта, его обоснованием служат учитываемые критерии. Следующие факторы, как правило, влияют на этот выбор:

1. Доступность ресурсов: низкая или некоторая – ресурсы нельзя оценить или они недоступны; высокая – ресурсы можно определить, и они доступны.

2. Сложность проекта: низкая – все критерии сложности низкие; средняя – критерии сложности смешаны: 1-2 высокие, 1-2 низкие; высокая – все критерии сложности высокие.

3. Стоимость приложения: низкая – оценка меньше некоторой суммы; средняя – оценка равна этой сумме; высокая – оценка больше этой суммы.

4. Стоимость будущих обновлений: низкая – оценка меньше некоторой суммы; высокая – оценка стоимости больше этой суммы.

5. Дискретное изменений требований: малое – задевает не более 5 интерфейсов и включает не более 10 процессов; большое – задевает более 5 интерфейсов и включает более 10 процессов.

6. Легкость в использовании: просто – фазы и поставки понятны, процесс сфокусирован на разработку, а не на поддерживающие процессы; сложно – поддерживающие процессы требуют управления, наряду с разработкой.

7. Функциональные потребности приложения: смутные – трудно определимые; разработчики формулируют их сами; специфицированные – хорошо определены, если они измеряемы и тестируемы.

8. Постепенное изменение требований: малое – задевают небольшой объем системы; большое – требуют пересмотра большого числа интерфейсов.

9. Время жизни приложения: краткое – краткосрочное решение, например, на несколько дней; среднее – от 3 до 5 лет; долгое – более 5 лет.

10. Технология производства продукта: существующая – современная технология, уже применявшаяся разработчиками; новая – технология, ранее не применявшаяся данными разработчиками.

11. Отдача приложения: низкая – результаты анализа стоимость/выгоды меньше заданного значения или если выгоды несущественны; высокая – результаты анализа стоимость/выгоды больше заданного значения.

12. Качество результатов: сразу – нужное качество достигается с первого раза; переработка – для достижения нужного качества требуются переделки.

13. Изменчивость требований: низкая – требования изначально хорошо заданы и стабильны; средняя – минимальные изменения в требованиях допустимы; высокая – при высокой изменчивости эффект движущейся мишени.

14. Повторное использование продуктов и документации: низкое – возможность использования продуктов из других реализаций ограничена; высокое – предполагается их использование в интеграции и тестировании.

15. Перспективы управления рисками: нет – не рассматривается; да – управление рисками должно быть включено в данный ЖЦ.

16. Неопределенность требований: нет – требования определены и предсказуемы; да – есть неопределенность, и ЖЦ должен это учитывать.

17. Неизвестные требования: нет – все требования выявлены; да – некоторые требования могут быть упущены.

Следующая таблица дает сводку по сравнению рассмотренных выше шести моделей жизненного цикла по перечисленным выше 17 критериям, для каждого из которых дается нечисловая оценка: низкий, средний, высокий или некоторый; большой или малый; существующий или новый; да или нет; сразу или после переработки.

Табл. 4. Матрица выбора модели ЖЦ

Критерии выбора	Водо- падная	RAD	V-об-разная	Поша- говая	Спи-ральная	Прото- типная
1.Доступность ресурсов	низкая	некот.	низкая	некот.	некот.	некот.
2.Сложность проекта	низкая	средняя	низкая	высокая	высокая	средняя
3.Стоимость приложения	низкая	низкая	низкая	средняя	высокая	низкая
4.Стоимость будущих обновлений	высокая	низкая	высокая	низкая	низкая	низкая
5.Дискретное изменений требований	большое	малое	большое	малое	малое	малое
6.Легкость в использовании	просто	просто	просто	сложно	сложно	просто
7.Функциональные потребности приложения	специф.	специф.	специф.	cмут-ные	смутные	смут-ные
8.Постепенное изменение требований	малое	малое	малое	боль-шое	большое	малое
9.Время жизни приложения	среднее	краткое	среднее	долгое	долгое	краткое
10.Технология производства продукта	существ.	новая	существ.	новая	новая	новая
11.Отдача приложения	высокая	низкая	высокая	высокая	высокая	низкая
12.Качество результатов	перераб.	перераб	перераб.	сразу	сразу	сразу
13.Изменчивость требований	низкая	низкая	низкая	средняя	высокая	низкая
14.Повторное использование продукта и документации	низкое	низкое	низкое	высокое	высокое	низкое
15.Перспективы управления рисками	нет	нет	нет	нет	да	да
16.Неопределенность требований	нет	нет	нет	да	да	да
17.Неизвестные требования	нет	нет	нет	да	да	да

Если сравнивать по легкости в использовании (критерий №6), то просто используемыми являются модели водопадная, быстрой разработки приложения (RAD), V-образная и прототипная, а более сложными – пошаговая и спиральная. Если же сравнивать по сложности проекта (критерий №2), то водопадная и V-образная модели подходят только для проектов с низкой сложностью, модели быстрой разработки приложения (RAD) и прототипная – для проектов средней сложности, а пошаговая и спиральная могут применяться и для проектов с высокой сложностью.

На основании этой матрицы можно будет сделать обоснование выбора модели ЖЦ. При этом важно еще такой выбор задокументировать, сохранив в документах проекта и матрицу, и значения соответствующих атрибутов проекта.

Подводя итог, можно дать следующие характеристики рассмотренным моделям жизненного цикла.

Водопадная модель подходит для небольших проектов с хорошо определенными требованиями и минимальным взаимодействием с заказчиком.

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

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

Пошаговая модель быстрее дает действующую систему, на основании которой можно ее развивать, и, что очень важно, в этой модели нет резких скачков от одного состояния (когда система полностью не работает) к следующему, когда она уже работает. Нечто работающее появляется уже в самом начале проекта, что постоянно развивается и совершенствуется с учетом поступающей обратной связи от заказчика.

Спиральная модель более интересна своим вниманием к анализу рисков и рассчитана на сложные проекты с большими неопределенностями. Она является, на самом деле, расширением водопадной модели, но только с обратной связью.

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

Табл. 5. Комбинация моделей ЖЦ в разработке MS-DOS, версии 6.0

Компонент	Модель жизненного цикла его разработки
Virus Backup	Внешняя разработка с последующей интеграцией
Fixes	V-образная
Disk Doublespace	Водопадная
File Recovery	Спиральная
Memory Management	Прототипная
Весь релиз 6.0	Пошаговая

При разработке больших программных систем могут применяться разные модели жизненного цикла для разных ее компонентов, как это показано в Табл. 5 на примере разработки ОС MS-DOS, версии 6.0.

Этот пример показывает, что к выбору модели ЖЦ следует подходить творчески, учитывая особенности данного проекта, создаваемого в нем продукта и его подсистем.