|
Выбор приемлемой модели жизненного цикла разработки ПО
Таблица 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.
Сопоставление жесткой и быстрой стратегий в методологиях программирования
Жесткие методологии
| Быстрые методологии
| Ориентация на предсказуемые процессы разработки программного обеспечения с четко обозначенными целями
| Осознание того, что процессы разработки программного обеспечения в принципе непредсказуемы
| Распознавание ситуаций и применение готовых методов
| Распознавание ситуаций и конструирование методов для работы в них
| Планирование, в котором определяются этапы с объемом работ, ресурсами, сроками и уровнем качества работ
| Соблюдение баланса между параметрами проекта: объем работ, ресурсы, сроки и уровень качества работ
| Заказчик – внешний по отношению к проекту субъект, влияющий на разработку только через предоставление ресурсов и контроль результатов, в том числе по поэтапным срокам выполнения проекта
| Заказчик (его представитель) – член команды разработчиков, наделенный правом влиять на разработку; его главной целью является отслеживание актуальности решаемых задач
| Ролевое разделение труда работников проекта
| Совместная деятельность сотрудников и деперсонифицированная ответственность
| Дисциплина и подчинение
| Самодисциплина и сотрудничество
| Обезличенный процесс, исполнители которого определяются только по квалификационным требованиям
| Процесс, максимально учитывающий личностные качества исполнителей
|
Не нашли то, что искали? Воспользуйтесь поиском гугл на сайте:
|