|
Выбор приемлемой модели жизненного цикла разработки ПО
Таблица 7.1
Выбор модели жизненного цикла на основе характеристик требований
| Требования
| Каскад-
ная
| V-образ-
ная
| Прототи-
пирование
| Спираль-
ная
| RAD
| Инкре-
ментная
| | Являются ли требования легко определимыми и/или хорошо известными?
| Да
| Да
| Нет
| Нет
| Да
| Нет
| | Могут ли требования заранее определяться в цикле?
| Да
| Да
| Нет
| Нет
| Да
| Да
| | Часто ли будут изменяться требования в цикле?
| Нет
| Нет
| Да
| Да
| Нет
| Нет
| | Нужно ли демонстрировать требования с целью определения?
| Нет
| Нет
| Да
| Да
| Да
| Нет
| | Требуется ли для демонстрации возможностей проверка концепции?
| Нет
| Нет
| Да
| Да
| Да
| Нет
| | Будут ли требования отражать сложность системы?
| Нет
| Нет
| Да
| Да
| Нет
| Да
| | Обладает ли требование функциональными свойствами на раннем этапе?
| Нет
| Нет
| Да
| Да
| Да
| Да
|
Таблица 7.2
Выбор модели жизненного цикла на основе характеристик участников команды разработчиков
| Команда разработчиков проекта
| Каскад-
ная
| V-образ-
ная
| Прототи-
пирование
| Спираль-
ная
| RAD
| Инкре-
ментная
| | Являются ли проблемы предметной области проекта новыми для большинства разработчиков?
| Нет
| Нет
| Да
| Да
| Нет
| Нет
| | Является ли технология предметной области проекта новой для большинства разработчиков?
| Да
| Да
| Нет
| Да
| Нет
| Да
| | Являются ли инструменты, используемые проектом, новыми для большинства разработчиков?
| Да
| Да
| Нет
| Да
| Нет
| Нет
| | Изменяются ли роли участников проекта во время жизненного цикла?
| Нет
| Нет
| Да
| Да
| Нет
| Да
| | Могут ли разработчики проекта пройти обучение?
| Нет
| Да
| Нет
| Нет
| Да
| Да
| | Является ли структура более значимой для разработчиков, чем гибкость?
| Да
| Да
| Нет
| Нет
| Нет
| Да
| | Будет ли менеджер проекта строго отслеживать прогресс команды?
| Да
| Да
| Нет
| Да
| Нет
| Да
| | Важна ли легкость распределения ресурсов?
| Да
| Да
| Нет
| Нет
| Да
| Да
| | Приемлет ли команда равноправные обзоры и инспекции?
| Да
| Да
| Да
| Да
| Нет
| Да
|
Таблица 7.3
Выбор модели жизненного цикла на основе характеристик коллектива пользователей
| Коллектив
пользователей
| Каскад-
ная
| V-образ-
ная
| Прототи-
пирование
| Спираль-
ная
| RAD
| Инкре-
ментная
| | Будет ли присутствие пользователей ограничено в жизненном цикле?
| Да
| Да
| Нет
| Да
| Нет
| Да
| | Будут ли пользователи знакомы с определением системы?
| Нет
| Нет
| Да
| Да
| Нет
| Да
| | Буду ли пользователи ознакомлены с проблемами предметной области?
| Нет
| Нет
| Да
| Нет
| Да
| Да
| | Будут ли пользователи вовлечены во все фазы жизненного цикла?
| Нет
| Нет
| Да
| Нет
| Да
| Нет
| | Будет ли заказчик отслеживать ход выполнения проекта?
| Нет
| Нет
| Да
| Да
| Нет
| Нет
| Таблица 7.4
Выбор модели жизненного цикла на основе характеристик типа проектов и рисков
| Тип проекта и риски
| Каскад-
ная
| V-образ-
ная
| Прототи-
пирование
| Спираль-
ная
| RAD
| Инкре-
ментная
| | Будет ли проект идентифицировать новое направление продукта для организации?
| Нет
| Нет
| Да
| Да
| Нет
| Да
| | Будет ли проект иметь тип
системной интеграции?
| Нет
| Да
| Да
| Да
| Да
| Да
| | Будет ли проект являться
расширением существующей системы?
| Нет
| Да
| Нет
| Нет
| Да
| Да
| | Будет ли финансирование проекта стабильным на всем протяжении жизненного цикла?
| Да
| Да
| Да
| Нет
| Да
| Нет
| | Ожидается ли длительная эксплуатация продукта в организации?
| Да
| Да
| Нет
| Да
| Нет
| Да
| | Должна ли быть высокая степень надежности?
| Нет
| Да
| Нет
| Да
| Нет
| Да
| | Будет ли система изменяться, возможно, с применением непредвиденных методов, на этапе сопровождения?
| Нет
| Нет
| Да
| Да
| Нет
| Да
| | Является ли график ограниченным?
| Нет
| Нет
| Да
| Да
| Да
| Да
| | Являются ли «прозрачными» интерфейсные модули?
| Да
| Да
| Нет
| Нет
| Нет
| Да
| | Доступны ли повторное используемые компоненты?
| Нет
| Нет
| Да
| Да
| Да
| Нет
| | Являются ли достаточными ресурсы (время, деньги, инструменты, персонал)?
| Нет
| Нет
| Да
| Да
| Нет
| Нет
|
Методологические стратегии
Рис. 8.1. Конус операционных маршрутов проекта
Рис. 8.2. Выявление отклонений и корректировка траектории
Рис. 8.3. Последовательное развитие проекта.
Рис. 8.4. Итеративное наращивание возможностей системы
Таблица 8.1.
Сопоставление жесткой и быстрой стратегий в методологиях программирования
| Жесткие методологии
| Быстрые методологии
| | Ориентация на предсказуемые процессы разработки программного обеспечения с четко обозначенными целями
| Осознание того, что процессы разработки программного обеспечения в принципе непредсказуемы
| | Распознавание ситуаций и применение готовых методов
| Распознавание ситуаций и конструирование методов для работы в них
| | Планирование, в котором определяются этапы с объемом работ, ресурсами, сроками и уровнем качества работ
| Соблюдение баланса между параметрами проекта: объем работ, ресурсы, сроки и уровень качества работ
| | Заказчик – внешний по отношению к проекту субъект, влияющий на разработку только через предоставление ресурсов и контроль результатов, в том числе по поэтапным срокам выполнения проекта
| Заказчик (его представитель) – член команды разработчиков, наделенный правом влиять на разработку; его главной целью является отслеживание актуальности решаемых задач
| | Ролевое разделение труда работников проекта
| Совместная деятельность сотрудников и деперсонифицированная ответственность
| | Дисциплина и подчинение
| Самодисциплина и сотрудничество
| | Обезличенный процесс, исполнители которого определяются только по квалификационным требованиям
| Процесс, максимально учитывающий личностные качества исполнителей
|
Не нашли то, что искали? Воспользуйтесь поиском гугл на сайте:
|
