Сравнительная характеристика моделей жизненного цикла.
Знание различных моделей жизненного цикла и умение их применять на практике необходимы любому руководителю проекта. Правильный выбор модели позволяет грамотно планировать объемы финансирования, сроки и ресурсы, необходимые для выполнения работ, сократить риски как разработчика, так и заказчика. Это способствует повышению авторитета (имиджа) разработчиков в глазах заказчика и в свою очередь оказывает влияние на перспективу дальнейшего сотрудничества с ним и другими заказчиками. Считать, что спиральная модель лучше остальных, неверно. Ведь на каждый проект заключается отдельный договор с определенной стоимостью. Заключать договор на большую сумму с неопределенным итоговым результатом заказчик никогда не будет (если только он не альтруист). В этом случае он предложит вложить вначале небольшую сумму в проект и уже по результатам первой версии (итерации) будет решать вопрос о заключении дополнительного договора на развитие системы.
Каждая из моделей имеет свои достоинства и недостатки, а также сферы применения в зависимости от специфики разрабатываемой системы, возможностей заказчика и разработчика и т. п. В табл. 3.1 приводится сравнительная характеристика рассмотренных выше моделей, которая должна помочь в выборе стратегии для конкретного проекта.
Таблица 3.1. Сравнение моделей жизненного цикла
Характеристика проекта | Модель (стратегия)
| ||||
Каскадная | Поэтапная модель с промежуточным контролем | Спиральная | |||
Новизна разработки и обеспеченность ресурсами | Типовой. Хорошо проработаны технология и методы решения задачи | Нетиповой (новаторский). Нетрадиционный для разработчика | |||
Ресурсов заказчика и разработчика хватает для реализации проекта в сжатые сроки | Ресурсов заказчика или разработчика не хватает для реализации проекта в сжатые сроки | ||||
Масштаб проекта | Малые и средние проекты | Средние и крупные проекты | Любые проекты | ||
Сроки выполнения проекта | До года | До нескольких лет. Разработка одной версии может занимать срок от нескольких недель до года | |||
Заключение отдельных договоров на отдельные версии | Заключается один договор. Версия и есть итоговый результат проекта | На отдельную версию или несколько последовательных версий обычно заключается отдельный договор | |||
Определение основных требований в начале проекта | Да | Да | Нет | ||
Изменение требований по мере развития проекта | Нет | Незначительное | Да | ||
Разработка итерациями | Нет | Да | Да | ||
Распространение промежуточного ПО | Нет | Может быть | Да |
В табл. не стоит рассматривать значения «Да» и «Нет» как жесткие требования. Например, незначительное изменение требований по мере развития проекта при использовании каскадной модели (например, добавление некоторых непредусмотренных сервисных функций) встречается не так уж редко и в случае их реализации способствует улучшению взаимоотношений между сторонами. Аналогично распространение промежуточного программного обеспечения при спиральной модели необязательно, а иногда даже вредно отражается на процессах внедрения и опытной эксплуатации системы.
|
|
При разработке системы под итоговым продуктом и промежуточным программным обеспечением согласно следует понимать:
ревизию (исправительную или опытную) – любые оперативные изменения программного и информационного обеспечения, а также БД, необязательные в данный момент к передаче на объекты внедрения и связанные с устранением ошибок и усовершенствованием;
модификацию – любые оперативные изменения программного и информационного обеспечения, а также БД, обязательные для передачи на объекты внедрения и обусловливающие изменение эксплуатационных характеристик без изменения функций (предусмотренных ТЗ), а также изменения, связанные с устранением ошибок, усовершенствованием;
|
|
версию – любые изменения программного и информационного обеспечения, а также БД, обязательные для передачи на объекты внедрения, позволяющие выполнять заявленные или дополнительные функции, а также обеспечивающие переход на новые операционные системы и информационную среду;
развитие (очередь) – плановые изменения информационной системы, связанные с введением новых функций и улучшением эксплуатационных характеристик, переходом на новую информационную среду, внедрением новых комплексов технических средств, новых информационных технологий и пр.
В соответствии с приведенной классификацией итоговым продуктом для любой из моделей жизненного цикла является обязательная к передаче версия или очередь системы. Разработка очередями характерна при инкрементной стратегии. В качестве промежуточного программного обеспечения следует рассматривать ревизии и модификации. Как было отмечено выше, частая передача ревизий и модификаций конечным пользователям (особенно занятым другими производственными делами) нежелательна. Согласно смене версий информационных систем на железнодорожном транспорте должна выполняться не чаще одного - двух раз в год, а модификаций – не чаще раза в месяц.
Дата добавления: 2018-02-15; просмотров: 3470; Мы поможем в написании вашей работы! |
Мы поможем в написании ваших работ!