для чего используют матрицу компромиссов

Матрица компромиссов

Она отражает достигнутое на ранних этапах проекта соглашение между проектной группой и Заказчиком о выборе приоритетов в возможных в будущем компромиссных решениях.

Матрица компромиссов помогает обозначить проектное ограничение, воздействие на которое практически невозможно (колонка «Фиксируется«), фактор, являющийся в проекте приоритетным (колонка «Согласовывается«), и третий параметр, значение которого должно быть принято в соответствии с установленными значениями первых двух величин (колонка «Принимается«).

Принципиально важно наличие у проектной группы и Заказчика единого, однозначного взгляда на матрицу компромиссов проекта.

При работе с матрицей желательно стремиться к тому, чтобы только один из параметров был зафиксирован, второй – согласовывался, и по третьему проводился окончательный расчет.

Источник

Ассоциация московских вузов

При составлении устава проекта для предварительной оптимизации проекта может использоваться матрица компромиссов. Ее используют для учета особенностей проект в части ограничения по срокам, по стоимости и по содержанию предстоящих работ.

Вначале определяется, какое из ограничений жестко фиксировано. В качестве фиксированного ограничения берется то, на которое в дано проекте влиять практически невозможно. Например, при строго оговоренном объеме финансирования фиксируется стоимость. Если строго оговорена дата получения конечного продукта, то фиксируются сроки. Если жестко оговорен набор характеристик продукта или услуги, то фиксируется содержание.

Затем определяется, по какому из ограничений есть возможность для оптимизации (улучшения). Обычно для оптимизации из двух оставшихся ограничений выбирают то, по которому в конце проекта желательно получить наилучшие показатели. Например, если желательно выполнить проект как можно быстрее, то оптимизируются сроки. Если важна экономия по деньгам, то оптимизируется стоимость. Если заказчику хочется получить изделие с максимально возможным диапазоном использования, то оптимизация ведется по содержанию.

Так как три вида ограничений проекта взаимосвязаны, то параметры третьего ограничения определяются параметрами первых двух. Поэтому оставшееся после выбор первых двух третье ограничение просто пересчитывается. В этом пересчитанном виде параметры последнего из трех ограничений учитываются для дальнейшей разработки проекта.

При заполнении матрицы компромиссов стремятся к тому, чтобы только оно из ограничений было зафиксировано, только в отношении одного проводилась оптимизация, только по одному из трех указанных поводился окончательный расчет. Если это правило нарушается, то либо теряется возможность для маневра, либо нарастает степень неопределенности последствий принимаемых решений. В конечном итоге это ведет к существенному увеличению рисков проекта.

В качестве примера в табл.4 показан такой вариант матрицы компромиссов, в котором зафиксированы сроки реализации проекта, принято решение искать наилучший вариант содержания работ (оптимизировать по содержанию), а затем произвести расчет стоимости, которая будет принята к исполнению.

Источник

Учебный курс «Технологии программирования. Курс на базе Microsoft Solutions Framework (MSF)» для подготовки по направлению «Информационные технологии»

Федеральное агентство по образованию РФ

ГОУ ВПО Нижегородский государственный университет им.

Факультет Вычислительной математики и кибернетики

Кафедра Математического обеспечения ЭВМ

«Технологии программирования.
Курс на базе Microsoft Solutions Framework (MSF)»

для подготовки по направлению «Информационные технологии»

Содержание[*]

2. Предположения и Ограничения. 4

3.1. Матрица компромиссов проекта. 5

3.3. Сметы проекта. 9

3.4. План-график проекта. 9

4. Роли и ответственности. 11

4.1. Знания, умения и навыки. 11

4.2. Структура команды.. 11

5. Протоколы проекта. 11

5.1. Управление рисками. 11

5.2. Управление конфигурацией. 12

5.3. Управление изменениями. 12

5.4. Управление внедрениями. 12

5.5. Достижение качества проекта. 13

5.6. Рабочая среда проекта. 13

Документ “Структура проекта” включает в себя информацию об организации проектной группы, персонификации ролей и ответственности. Также документ разъясняет схемы взаимодействия проектной группы с заказчиком и заказчика – с проектной группой.

1. Цели и Задачи

Формирование концепции решения начинается с выяснения у заинтересованных сторон, описания и фиксации проектной группой целей проекта. Далее каждая цель разбивается на измеримые компоненты – задачи.

Содержание данного раздела повторяет содержание раздела 2.1 документа “Концепция проекта”.

Система должна уметь решать трехкритериальную задачу поиска кратчайших путей на графах. Критерии:

Система должна быть распределенной, так как в каждом аэропорте своя база направлений полетов самолетов. Знают о рейсе только аэропорты – соседи по рейсам. Требование, выдвигаемое компанией, состоит в том чтобы не делать базу централизованной, т. к. иначе имеющиеся серверы не будут справляться с нагрузкой, а новое оборудование слишком дорого.

Выделенные объекты системы:

распределенное хранилище рейсов покупатель билетов.

Распределенное хранилище рейсов:

Включает следующие атрибуты:

название рейсов номера тип самолетов класс самолета по комфорту стоимость билетов.

Выделены следующие атрибуты:

Покупатель на сайте задает параметры, связанные с суммой, которую он хочет потратить, комфорт и время. Система в ответ должна подобрать оптимальные маршруты. Если таковых не находится, то система должна дать в ответе причину, по которой не получается подобрать маршрут. Среди причин:

Отсутствие вообще рейсов в том направлении даже с пересадками на данный момент Сумма слишком мала Комфорт слишком завышен

В ответ пользователь должен иметь возможность поменять параметры с учетом предыстории.

2. Предположения и Ограничения

В процессе формирования концепции решения проектная группа постоянно взаимодействует с заинтересованными сторонами, собирая необходимую информацию о требованиях к функциональности будущего решения. Тем не менее, неизбежная неполнота информации приводит к тому, что относительно некоторых функциональных возможностей решения могут потребоваться предположения (assumptions). Помимо функциональных требований заинтересованные стороны могут выдвигать качественные требования, задающие ограничения на создаваемое решение. Также ограничения могут порождаться средой, в которой должно будет функционировать решение после внедрения.

Содержание данного раздела повторяет содержание раздела 2.2 документа “Концепция проекта”.

На первую систему есть существенные ограничения:

Система не распределена Нет разграничения прав между менеджерами и пользователями Весь интерфейс представлен в одном окне Система должна демонстрировать визуальные формы и способы хранения и взаимодействия данных

3. Рамки проекта

Рамки (scope) определяют пространство параметров, в котором будет создаваться решение, детализируя функциональность, определяя, что останется за рамками решения и указывая критерии, по которым заинтересованные лица будут судить о готовности решения. Рамки создаются на основе единого видения, являются результатом компромисса между сформулированными целями и условиями реальности и отражают приоритезацию заказчиком имеющихся требований к создаваемому решению. Частью процесса определения рамок проекта является вынесение менее важной функциональности из текущего проекта в планы на будущее.

Рамки проекта (project scope) определяют объем работ, который должен быть выполнен проектной группой для поставки заказчику каждого из элементов, определенного рамками решения.

Управление рамками проекта критично для его успеха. MSF предлагает определять и фиксировать рамки решения и проекта, используя треугольник компромиссов и матрицу компромиссов проекта.

Матрица компромиссов проекта

Хорошо известна взаимозависимость между ресурсами проекта (людскими и финансовыми), его календарным графиком (временем) и реализуемыми возможностями (рамками). Эти три переменные образуют треугольник компромисов (tradeoff triangle), показанный на рис. 1.

После достижения равновесия в этом треугольнике изменение на любой из его сторон для поддержания баланса требует модификаций на другой (двух других) сторонах и/или на изначально измененной стороне.

Рисунок 1. Треугольник компромиссов*

Нахождение верного баланса между ресурсами, временем разработки и возможностями – ключевой момент в построении решения, должным образом отвечающего нуждам заказчика.

Рисунок 2. Матрица компромиссов*

Другое весьма полезное средство для управления проектными компромиссами – матрица компромиссов проекта (project tradeoff matrix), показанная на
рис. 2. Она отражает достигнутое на ранних этапах проекта соглашение между проектной группой и заказчиком о выборе приоритетов в возможных в будущем компромиссных решениях. В определенных случаях из этой приоритезации могут делаться исключения, но в целом следование ей облегчает достижение соглашений по спорным вопросам.

Рис. 2 показывает матрицу компромиссов проекта, используемую обычно проектными группами Майкрософт. Она помогает обозначить проектное ограничение, воздействие на которое практически невозможно (колонка “Фиксируется”), фактор, являющийся в проекте приоритетным (колонка “Согласовывается”), и третий параметр, значение которого должно быть принято в соответствии с установленными значениями первых двух величин (колонка “Принимается”).

Принципиально важно наличие у проектной группы и заказчика единого, однозначного взгляда на матрицу компромиссов проекта.

Укажите здесь оценки (в выбранных вами единицах) параметров треугольника компромиссов: ресурсы, которыми располагает ваш проект; имеющееся для реализации проекта время; возможности решения, которые, согласно описанию в документе “Концепция проекта”, будут вами реализованы. Расставьте приоритеты и постройте на их основе матрицу компромиссов.

Для разработки первой версии системы у нас имеются следующие ресурсы и возможности

Для первой версии нам выделили 1000 единиц ресурса

Для разработки системы у нас имеется команда из 6-ти человек

Мы располагаем временем:

3 месяца (90 дней включая выходные)

Возможности, которые мы собираемся реализовать:

Хранилище находится в оперативной памяти Добавление аэропортов по нажатию кнопки
Проверка корректности введеных данных
Проверка существования аэропорта с введенным номером

Создание визуальной формы для отображения аэропорта

Добавление рейсов

Проверка корректности введеных данных
Проверка существования рейса с введенным номером Проверка на существование аэропортов рейса

Добавление в визуальные формы аэропортов информации о добавленных рейсах

Удаление аэропортов

Удаление всех сопутствующих рейсов

Удаление рейсов Поиск минимального по стоимости маршрута

Заказ билетов на найденные маршруты

В итоге обсуждений мы приняли следующую матрицу компромиссов:

Красным обозначены достигнутые решения по компромиссам.

Вехи проекта

Вехи проекта – это существенные события в жизни проекта. На фазе выработки концепции обычно “выставляются” внешние вехи, которые показывают достижение видимых целей проекта. На самом верхнем уровне в качестве внешних вех могут рассматриваться окончания фаз выполнения проекта. В зависимости от природы проекта вехи могут быть основаны на финансовых затратах, на прогрессе в проекте, на временных интервалах и т. д.

Раннее определение вех позволяет установить точки на временном графике проекта, по которым заинтересованные стороны и проектная группа будут судить о ходе его выполнения.

Выберите и аргументируйте подход к определению вех в вашем проекте. Определите и опишите здесь вехи, на которые вы будете ориентироваться в ходе выполнения проекта.

В ходе проекта выделены следующие вехи:

Фаза выработки концепции
Ядро проектной группы сформировано Черновой вариант концепции проекта составлен

Фаза планирования

Верификация технологий Базовая версия функциональной спецификации создана Базовая версия сводного плана проекта создана Базовая версия сводного календарного графика проекта создана Среды разработки и тестирования развернуты

Фаза разработки

Концепция подтверждена Билд 1 завершен (шаблоны функциональных выделенных классов) Билд 2 завершен (реализована функциональность выделенных классов) Билд 3 завершен (реализована JNL прослойка) Билд 4 завершен (реализована вся функциональность, включая визуальную оболочку)

Фаза стабилизации

Точка конвергенции достигнута Точка достижения нуля Версия-кандидат 1 Версия-кандидат 2 Контрольное тестирование завершено Тестирование приемлемости для потребителей завершено Пилотное внедрение завершено

Фаза внедрения

Ключевые компоненты развернуты Внедрение на местах завершено Внедренное решение стабилизировано

Сметы проекта

Выполнение проекта предполагает использование ресурсов и подразумевает наличие затрат. Ресурсы включают в себя людей, оборудование, различные расходные материалы и т. д. Затраты рассчитываются на основе тарифов (расценок) на каждый вид требуемого ресурса. В данном разделе должна быть представлена информация о:

§ списке видов ресурсов,

§ требуемом количестве каждого ресурса,

§ тарифе на каждый вид ресурса,

§ общей стоимости каждого ресурса,

§ общей стоимости всех ресурсов, необходимых проектной группе.

На основе информации данного раздела должен рассчитываться бюджет проекта. Также этот этап – хорошая возможность идентифицировать специфические ресурсы, которые могут потребоваться для выполнения проекта.

Укажите, какие виды ресурсов необходимы вашей проектной группе для выполнения проекта, определите в выбранных единицах количество каждого ресурса, оцените общие ожидаемые затраты по ресурсам.

Источник

Microsoft Solutions Framework Белая книга

Матрица компромиссов проекта

Другое весьма полезное средство для управления проектными компромиссами – матрица компромиссов проекта (project tradeoff matrix), показанная на рис. 6. Она отражает достигнутое на ранних этапах проекта соглашение между проектной группой и заказчиком о выборе приоритетов в возможных в будущем компромиссных решениях. В определенных случаях из этой приоритезации могут делаться исключения, но в целом следование ей облегчает достижение соглашений по спорным вопросам.

Рис. 6 показывает матрицу компромиссов проекта, используемую обычно проектными группами Майкрософт. Она помогает обозначить проектное ограничение, воздействие на которое практически невозможно (колонка “Фиксируется”), фактор, являющийся в проекте приоритетным (колонка “Согласовывается”), и третий параметр, значение которого должно быть принято в соответствии с установленными значениями первых двух величин (колонка “Принимается”).

Нельзя произвольно сокращать функциональность решения. Как проектная группа, так и заказчик должны тщательно проанализировать все имеющиеся в проекте ограничения и быть готовыми идти на обусловленные ими уступки.

Для иллюстрации использования матрицы компромиссов рассмотрим следующее предложение (вместо пропущенных слов могут быть вставлены “календарный график”, “ресурсы” и “функциональность”):

Характеристики модели процессов MSF

Подход, основанный на вехах

Характеристики подхода, основанного на вехах

Главные и промежуточные вехи

Вехи как точки синхронизации

Главные вехи – это моменты жизненного цикла проекта, когда полученные на той или иной фазе результаты синхронизируются членами проектной группы друг с другом и с ожиданиями заказчика. В этот момент заказчиком, заинтересованными сторонами и проектной группой производится формальный анализ достигнутого прогресса. Успешное прохождение главной вехи знаменует согласие проектной группы и заказчика продолжать далее работу над проектом.

Хотя в принципе возможно отодвинуть время окончания проекта на неограниченно долгий срок, минимизировав тем самым всю имеющуюся в нем неопределенность, такое решение дорого стоит и не отвечает реальным бизнес-нуждам. Вехи позволяют заказчику и проектной группе проверить соответствие рамок проекта потенциально изменяющимся требованиям, и если необходимо, скорректировать их, а также отреагировать на возникающие риски.

Источник