Проблема масштаба проекта . Эти данные в значительной мере совпадают с результатами исследований группы Стендиша, свидетельствующими, что более половины проектов будут стоить примерно вдвое боль. Теперь мы, возможно, понимаем, почему. Небольшая история о масштабе проекта Однажды одну из наших студенток назначили на новую для нее должность менеджера разработки программного продукта. В прошлом она занималась многими аспектами разработки новых продуктов и маркетинга, но не имела непосредственного опыта в разработке программного обеспечения. Она выслушала ответы на наш вопрос о мас. Оглядев присутствующих, она сказала. Что происходит, когда проект развивается с изначально заданным масштабом . И эта половина не является целост. Следствием является серьезное недовольство заказчиков, чьи ожидания не оправдались, невыполнение маркетинговых обязательств, некачествен. Команда страдает и теряет мотивацию. К моменту сдачи каждая функция готова только на . Поскольку, как правило, существуют взаимозависимости между отдельными частями функции, ничто вообще не работает к окончанию срока. Срок сдачи проходит. В худшем случае вся команда увольняется после нескольких меся. Каково качество программного обеспечения в каждом из этих случаен. Заказчикам приходится выполнять как тестирование, так и действия по обеспе. В итоге заказчики реагируют на наши сверхусилия следующим образом. . . Управление масштабом Трудный вопрос Для того чтобы команда проекта имела хоть какую. Однако в типичном случае задача состоит в сокращении масштаба. Перед командой встает дилемма. Но еще не все потеряно. Глава . упорядоченного списка высокоуровневых функций, которые будут реализовываться в указанной версии продукта. Второй шаг состоит в приблизительном определении объема трудозатрат, необходимого для каждой из перечисленных базовых функций. Третьим шагом является оценка риска для каждой функции или вероятно . Используя эти данные, команда задает базовый уровень таким образом, чтобы гарантировать предоставление критически важных для успеха про. Базовый уровень требований Задача управления масштабом состоит в задании высокоуровневой базы требований для данного проекта. Базовый уровень это разбитое на элементы множество функций или требова. Представленный на рис. Другими словами, базовый уровень должен обладать следующими свойствами. Он должен быть, как минимум, . Должен иметь разумную вероятность успеха с точки зрения команды разработчиков. Функция . Базовый уровень требований Первый шаг при задании базового уровня состоит в простом перечислении функций, ко. Очень важно при этом следить за уровнем детали . Управление масштабом зации. Если их будет больше, то описание проекта будет слишком детализировано, что будет помехой при обсуж. Если же меньше — уровень детализации будет недостаточным для обеспечения удовлетворительного понимания приложения и оцен. Если мы следовали рекомендуемоигу для совещания по вопросу требований процессу . Этот список представляет собой разбитое на пункты высокоуровне. В качестве примера рассмотрим некий программный продукт, для которого был со. Поддержка внешней реляционной базы данных Функция . Многопользовательская безопасность Функция . Возможность клонирования проекта Функция . Порт для новой версии операционной системы . Импортирование внешних данных по стилям Функция . Реализация средств предупреждения Функция . Интеграция с подсистемой управления версиями Установка приоритетов Как уже отмечалось в части . Важно, чтобы заказчики и пользователи, менеджеры нижнего уровня или их представители — не команда разработчиков — определяли приоритеты, находясь в вашем отделе маркетинга. Первичная расстановка приоритетов должна производиться без за. Технические моменты можно будет учесть на более поздних фазах процесса расстановки приоритетов. Для нашего примера предположим, что мы провели голосование относительно приоритета каждой функции, используя шкалу . Таблица . Упорядоченные по приоритетам функции Функция Приоритет Функция . Поддержка внешней реляционной базы данных Критический Функция . Порт для повой версии ОС Критический Функция . Импортирование внешних данных по стилям Критический . Задание масштаба проекта . Возможность клонирования проекта Важный Функция . Многопользовательская безопасность Важный Функция . Реализация средств предупреждения Полезный Функция . Интеграция с подсистемой управления версиями Полезный Оценка трудозатрат Расстановка приоритетов — только часть представляющей масштаб картины. Если же мы не можем выполнить всю работу, необходимо определить, ка. Второй шаг заключается в определении приблизительного уровня трудозатрат для каждой из предлагаемых функций. Это достаточно сложно сделать, так как еще мало информации для оценки предстоящей работы. Лучшее, что можно сделать. Оценка трудозатрат на столь раннем этапе является сложной задачей. Тем не менее, первое сокраще. Предположим, что менеджер продукта является лидером нашего проекта и у него происходит следующий диалог с разработчиками проекта. Менеджер продукта. У нас до сих пор еще нет никаких требований или результатов проектирования. Менеджер продукта. Менеджер продукта. Эта грубая эвристическая оценка служит заменой более де. Затем, учитывая эти оценки и общее отведенное на проект время, команда может определить, где изначально проводить базовый уровень.