-
Выбор модели жизненного цикла
Для выбора приемлемой модели жизненного цикла разработки КИС в таблице 4.1 приведен набор вопросов относительно требований, которые предъявляются к модели разработки систем корпоративного уровня.
Таблица 4.1
Выбор модели жизненного цикла на основе характеристик требований
|
Требования |
Каскадная |
V-образная |
Спираль-ная |
Прототипирование |
|
Являются ли требования легко определимыми и/или хорошо известными? |
Да |
Да |
Нет |
Нет |
|
Часто ли будут изменятся требования в цикле? |
Нет |
Нет |
Да |
Да |
|
Будут ли требования отражать сложность системы? |
Нет |
Нет |
Да |
Да |
|
Обладает ли требование функциональными свойствами на раннем этапе? |
Нет |
Нет |
Да |
Да |
|
Будет ли присутствие пользователей ограничено в жизненном цикле? |
Да |
Да |
Да |
Нет |
|
Будут ли пользователи вовлечены во все фазы жизненного цикла? |
Нет |
Нет |
Нет |
Да |
|
Будет ли проект иметь тип системной интеграции? |
Нет |
Нет |
Да |
Да |
|
Будет ли проект являться расширением существующей системы? |
Нет |
Нет |
Нет |
Нет |
|
Будет ли финансирование проекта стабильным на всем протяжении жизненного цикла? |
Да |
Да |
Нет |
Да |
|
Будет ли система изменяться, возможно, с применением непредвиденных методов, на этапе сопровождения? |
Нет |
Нет |
Да |
Да |
|
Является ли график ограниченным? |
Нет |
Нет |
Да |
Да |
|
Доступно ли повторное использование компоненты? |
Нет |
Нет |
Да |
Да |
Проанализировав сравнительную характеристику моделей ЖЦ, сделан вывод, что наиболее оптимальной для реализации КИС является модель прототипирования (рис. 4.1), поддерживающая следующие возможности, которые необходимо учитывать при разработке систем корпоративного уровня:
-
возможность частого изменения требований к системе;
-
вовлечение пользователей во все фазы жизненного цикла;
-
возможность изменения системы на этапе сопровождения;
-
повторное использование компонент;
-
разумный баланс между скоростью и качеством разработки.
"Быстрая" частичная реализация системы создается перед этапом определения требований или на его протяжении. Конечные пользователи системы используют ускоренный прототип, а затем путем обратной связи сообщают о своем достижении команде, работающей над проектом, для дальнейшего уточнения требований к системе. Процесс уточнения продолжается до тех пор, пока пользователь не получит то, что ему требуется. После завершения процесса определения требований путем разработки ускоренных прототипов, получают детальный проект системы, а ускоренный прототип регулируется при использовании кода или внешних утилит, в результате чего получают конечный рабочий продукт. В идеале можно вывести, при чем без излишних затрат, модель прототипирования высокого качества, не экономя на документации, анализе, проектировании, тестировании и т.д. Следовательно, она получила название "структурной модели быстрого прототипирования", как показано на рис. 4.1.
Рис. 4.1. Структурная модель быстрого прототипирования
При использовании прототипирования снижаются затраты и оптимизируется соблюдение графиков, поскольку каждый из его компонентов находит свое применение