Краткий обзор методологии 3 другие модели процессов 4 Лучшее из двух миров 5 Базовые принципы msf 5
жүктеу/скачать 0.88 Mb.
|
- Бұл бет үшін навигация:
- Рамки проекта
- Управление компромиссами
- Треугольник компромиссов
- Матрица компромиссов проекта
Создание базовых версийВ модели процессов MSF базовая версия (baseline) – это известное и зафиксированное состояние чего-либо, используемое для последующего сравнения. Это понятие встречается в MSF весьма часто. Программный код, конфигурации серверов, планы и календарные графики, спецификации, руководства пользователей и бюджет – вот лишь часть тех составляющих проекта, для которых MSF рекомендует использовать базовые версии. Не имея базовых версий, нет возможности управлять изменениями. Рамки проектаРамки (scope) – это сумма всех составляющих проекта, которые должны стать результатом работы над ним, а также все предоставляемые услуги, имеющие отношение к проекту. Рамки проекта определяют, что должно быть сделано для реализации единого видения. Они являются результатом компромисса между сформулированными целями и условиями реальности и отражают приоритезацию заказчиком имеющихся требований к создаваемому решению. Частью процесса определения рамок проекта является вынесение менее важной функциональности из текущего проекта в планы на будущее. Четкое очерчивание рамок предоставляет возможность:
Необходимо определить рамки как для производимой работы и набора предоставляемых услуг, так и для функциональности создаваемого решения. Термин “рамки” имеет два аспекта: рамки решения и рамки проекта. Несмотря на то, что между ними имеется тесная взаимосвязь, они не тождественны друг другу. Понимание различий между ними помогает эффективному управлению календарным графиком и стоимостью проекта. Рамки решения (solution scope) определяют функциональность решения и его возможности (включая те, что не относятся к программному обеспечению). Возможность (функциональность, составляющая, feature) – это требуемый или желаемый аспект программного или аппаратного обеспечения. Например, предварительный просмотр перед печатью может быть возможностью текстового процессора; шифрование почтовых сообщений – возможностью почтовой программы. Сопроводительные руководства пользователей, интерактивные файлы помощи, операционные руководства и обучение также могут быть составляющими (features) решения. Рамки проекта (project scope) определяют объем работ, который должен быть выполнен проектной группой для поставки заказчику каждого из элементов, определенного рамками решения. Некоторые организации называют рамки проекта “описанием работы” (statement of work - SOW). Формулирование рамок проекта позволяет проектной группе:
Управление компромиссамиУправление рамками проекта критично для его успеха. Неудачи многих IT проектов, включая затягивание сроков и перерасход средств, обусловлены плохой организацией управления их рамками. Эта деятельность должна включать в себя раннее определение рамок проекта, хорошо организованные мониторинг его хода и управление изменениями. В силу свойственной IT-проектам неопределенности и рискованности, одним из ключевых факторов их успеха являются эффективные компромиссные решения (trade offs). Треугольник компромиссовХорошо известна взаимозависимость между ресурсами проекта (людскими и финансовыми), его календарным графиком (временем) и реализуемыми возможностями (рамками). Эти три переменные образуют треугольник, показанный на рис. 5. После достижения равновесия в этом треугольнике изменение на любой из его сторон для поддержания баланса требует модификаций на другой (двух других) сторонах и/или на изначально измененной стороне.
Нахождение верного баланса между ресурсами, временем разработки и возможностями – ключевой момент в построении решения, должным образом отвечающего нуждам заказчика. Иногда заказчики не хотят, чтобы в жертву приносились определенные (не необходимые) возможности продукта. Изображенный выше треугольник помогает проиллюстрировать им суть имеющихся ограничений и служит инструментом поиска компромиссных решений. Реализуемая функциональность должна иметь качество не ниже определенного уровня. Параметр качества может быть изображен в виде четвертого измерения, превращающего треугольник в тетраэдр (треугольную пирамиду). Хотя снижение порога качества (quality bar) дает возможность сократить затрачиваемые ресурсы/время и увеличить функциональность решения, это ведет, безусловно, к неизбежно плохому результату.
Рис. 6 показывает матрицу компромиссов проекта, используемую обычно проектными группами Майкрософт. Она помогает обозначить проектное ограничение, воздействие на которое практически невозможно (колонка “Фиксируется”), фактор, являющийся в проекте приоритетным (колонка “Согласовывается”), и третий параметр, значение которого должно быть принято в соответствии с установленными значениями первых двух величин (колонка “Принимается”). Нельзя произвольно сокращать функциональность решения. Как проектная группа, так и заказчик должны тщательно проанализировать все имеющиеся в проекте ограничения и быть готовыми идти на обусловленные ими уступки. Для иллюстрации использования матрицы компромиссов рассмотрим следующее предложение (вместо пропущенных слов могут быть вставлены “календарный график”, “ресурсы” и “функциональность”): Зафиксировав ___________, мы согласовываем ___________ и принимаем результирующий ___________.
Возможны такие логические взаимосвязи:
Принципиально важно наличие у проектной группы и заказчика единого, однозначного взгляда на матрицу компромиссов проекта. жүктеу/скачать 0.88 Mb. Достарыңызбен бөлісу:
|
