|
|
Модели. 03 Модели жизненного цикла информационных систем (4). Модели жизненного цикла информационных систем Модели жизненного цикла ис
Модели жизненного цикла ИС
Модели
жизненного цикла
Каскадная
Инкрементная
Спиральная
Каскадная модель (однократный проход, водопадная или классическая модель)
Формирование требований
Анализ требований
Проектирование
Кодирование
Тестирование
Внедрение
Итоговый продукт
Сопровождение и эксплуатация
Каскадная модель Достоинства модели: - на каждой стадии формируется законченный набор документации, программного и аппаратного обеспечения, отвечающий критериям полноты и согласованности;
- выполняемые в четкой последовательности стадии позволяют уверенно планировать сроки выполнения работ и соответствующие ресурсы (денежные, материальные и людские).
Недостатки модели: - реальный процесс разработки информационной системы редко полностью укладывается в такую жесткую схему. Особенно это относится к разработке нетиповых и новаторских систем;
- основана на точной формулировке исходных требований к информационной системе. Реально в начале проекта требования заказчика определены лишь частично;
- основной недостаток – результаты разработки доступны заказчику только в конце проекта. В случае неточного изложения требований или их изменения в течение длительного периода создания ИС заказчик получает систему, не удовлетворяющую его потребностям.
Инкрементная модель (англ. increment – увеличение, приращение)
Формирование требований
Анализ требований
Проектирование
Кодирование
Тестирование
Внедрение
1 ОЧеРЕДЬ
(версия)
Формирование требований
Сопровождение и эксплуатация
Проектирование
Кодирование
Тестирование
Внедрение
2 ОЧеРЕДЬ
(версия)
Сопровождение и эксплуатация
Проектирование
Кодирование
Тестирование
Внедрение
N ОЧеРЕДЬ
(версия)
Сопровождение и эксплуатация
Инкрементная модель Данная модель жизненного цикла характерна при разработке сложных и комплексных систем, для которых имеется четкое видение (как со стороны заказчика, так и со стороны разработчика) того, что собой должен представлять конечный результат (информационная система). Разработка очередями (версиями) ведется в силу разного рода причин: - отсутствия у заказчика возможности сразу профинансировать весь дорогостоящий проект;
- отсутствия у разработчика необходимых ресурсов для реализации сложного проекта в сжатые сроки;
- требований поэтапного внедрения и освоения продукта конечными пользователями.
Достоинства и недостатки этой стратегии такие же, как и у классической. Но в отличие от классической стратегии заказчик может раньше увидеть результаты. Уже по результатам разработки и внедрения первой версии он может незначительно изменить требования к разработке, отказаться от нее или предложить разработку более совершенного продукта с заключением нового договора.
Спиральная модель
3 версия
2 версия
1 версия
Определение целей, альтернатив, ограничений (формирование требований)
Оценка альтернатив, выявление и устранение рисков (анализ требований)
Разработка и верификация (проектирование, кодирование, интеграция и тестирование, внедрение)
Планирование следующей фазы (сопровождение и эксплуатация)
Линия принятия решений
Спиральная модель Достоинства модели: - позволяет быстрее показать пользователям системы работоспособный продукт, тем самым, активизируя процесс уточнения и дополнения требований;
- допускает изменение требований при разработке информационной системы, что характерно для большинства разработок, в том числе и типовых;
- обеспечивает большую гибкость в управлении проектом;
- позволяет получить более надежную и устойчивую систему. По мере развития системы ошибки и слабые места обнаруживаются и исправляются на каждой итерации;
- позволяет совершенствовать процесс разработки – анализ, проводимый в каждой итерации, позволяет проводить оценку того, что должно быть изменено в организации разработки, и улучшить ее на следующей итерации;
- уменьшаются риски заказчика. Заказчик может с минимальными для себя финансовыми потерями завершить развитие неперспективного проекта.
Недостатки модели: - увеличивается неопределенность у разработчика в перспективах развития проекта;
- затруднены операции временного и ресурсного планирования всего проекта в целом. Для решения этой проблемы необходимо ввести временные ограничения на каждую из стадий жизненного цикла. Переход осуществляется в соответствии с планом, даже если не вся запланированная работа выполнена.
Сравнительный анализ моделей
Характеристика проекта
|
Модель (стратегия)
| | | | |
Каскадная
|
Инкрементная
|
Спиральная
|
Новизна разработки и обеспеченность ресурсами
|
Типовой. Хорошо проработаны технология и методы решения задачи
| |
Нетиповой (новаторский). Нетрадиционный для разработчика
| | |
Ресурсов заказчика и разработчика хватает для реализации проекта в сжатые сроки
|
Ресурсов заказчика или разработчика не хватает для реализации проекта в сжатые сроки
| |
Масштаб проекта
|
Малые и средние проекты
|
Средние и крупные проекты
|
Любые проекты
|
Сроки выполнения проекта
|
До года
|
До нескольких лет. Разработка одной версии может занимать срок от нескольких недель до года
| |
Заключение отдельных договоров на отдельные версии
|
Заключается один договор. Версия и есть итоговый результат проекта
|
На отдельную версию или несколько последовательных версий обычно заключается отдельный договор
| |
Определение основных требований в начале проекта
|
Да
|
Да
|
Нет
|
Изменение требований по мере развития проекта
|
Нет
|
Незначительное
|
Да
|
Разработка итерациями (версиями)
|
Нет
|
Да
|
Да
|
Распространение промежуточного ПО
|
Нет
|
Может быть
|
Да
|
Модификации программного обеспечения Ревизия (исправительную или опытную) – любые оперативные изменения программного и информационного обеспечения, а также БД, необязательные в данный момент к передаче на объекты внедрения и связанные с устранением ошибок и усовершенствованием. Модификация – любые оперативные изменения программного и информационного обеспечения, а также БД, обязательные для передачи на объекты внедрения и обусловливающие изменение эксплуатационных характеристик без изменения функций (предусмотренных ТЗ), а также изменения, связанные с устранением ошибок, усовершенствованием. Версия – любые изменения программного и информационного обеспечения, а также БД, обязательные для передачи на объекты внедрения, позволяющие выполнять заявленные или дополнительные функции, а также обеспечивающие переход на новые операционные системы и информационную среду. Развитие (очередь) – плановые изменения информационной системы, связанные с введением новых функций и улучшением эксплуатационных характеристик, переходом на новую информационную среду, внедрением новых комплексов технических средств, новых информационных технологий и пр.
Методология RAD (Rapid Application Development) Отличительные особенности: - небольшую команду программистов (до 10 человек);
- короткий, но тщательно проработанный производственный график (от 2 до 6 месяцев);
- повторяющийся цикл, при котором разработчики по мере того, как приложение начинает обретать форму, реализуют в продукте требования, полученные через взаимодействие с заказчиком.
Условия применения: - применима для относительно небольших проектов, разрабатываемых под конкретного заказчика;
- неприменима для построения сложных расчетных программ, операционных систем или программ управления космическими кораблями, т. е. программ, требующих написания большого объема (сотни тысяч строк) уникального кода;
- неприменима для разработки приложений, в которых отсутствует ярко выраженная интерфейсная часть, наглядно определяющая логику работы системы (например, приложения реального времени);
- неприменима для разработки приложений, от которых зависит безопасность людей (например, управление самолетом или атомной электростанцией), так как итеративный подход предполагает, что первые несколько версий, скорее всего не будут полностью работоспособны, что в данном случае исключается.
Методология XP (eXtreme Programming) Отличительные особенности: - частая смена версий и модификаций (длительность итераций вплоть до часов и минут, а обычно – 2 недели; в RAD – минимум 2 месяца);
- непрерывная связь с заказчиком – в группе все время находится квалифицированный представитель заказчика;
- простое проектирование – при разработке всегда выбирается наиболее простое решение. «Лучше сделать простую вещь сегодня и завтра заплатить еще немного за внесение небольших изменений, чем делать сегодня сложную вещь, которая завтра может не понадобиться»;
- простой дизайн – система должна быть спроектирована настолько просто, насколько это возможно на конкретный момент времени;
- коллективное владение кодом;
- программирование в парах;
- непрерывное и пересекающееся проектирование, разработка, интеграция и тестирование системы.
|
|
|
Скачать 296.59 Kb.