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

Федеральное агентство по образованию РФ
ГОУ ВПО Нижегородский государственный университет им. Н.И. Лобачевского
Факультет Вычислительной математики и кибернетики
Кафедра Математического обеспечения ЭВМ
УЧЕБНЫЙ КУРС
«Технологии программирования.
Курс на базе Microsoft Solutions Framework (MSF)»
для подготовки по направлению «Информационные технологии»
СТРУКТУРА ПРОЕКТА
Нижний Новгород
2006
Содержание*
1. Цели и Задачи ................................................................................................ 3
2. Предположения и Ограничения .................................................................. 4
3. Рамки проекта ............................................................................................... 4
3.1.
Матрица компромиссов проекта ............................................................................. 5
3.2.
Вехи проекта ............................................................................................................. 7
3.3.
Сметы проекта .......................................................................................................... 9
3.4.
План-график проекта................................................................................................ 9
4. Роли и ответственности.............................................................................. 10
4.1.
Знания, умения и навыки ....................................................................................... 10
4.2.
Структура команды ................................................................................................ 10
5. Протоколы проекта ..................................................................................... 11
*
5.1.
Управление рисками .............................................................................................. 11
5.2.
Управление конфигурацией .................................................................................. 12
5.3.
Управление изменениями ...................................................................................... 12
5.4.
Управление внедрениями ...................................................................................... 13
5.5.
Достижение качества проекта ............................................................................... 13
5.6.
Рабочая среда проекта ............................................................................................ 14
В документе использованы материалы белых книг (white papers) “MSF Process Model”, “MSF Risk Management Discipline”, “MSF
Team Model” (http://www.microsoft.com/msf), их переводов “Модель процессов MSF”, “Дисциплина управления рисками MSF”,
“Модель проектной группы MSF” выполненных в 2003 году корпораций eLine Software (http://www.elinesoftware.com), а также
официальных курсов Microsoft 2710B и 1846A.
Документ “Структура проекта” включает в себя информацию об организации
проектной группы, персонификации ролей и ответственности. Также документ
разъясняет схемы взаимодействия проектной группы с заказчиком и заказчика – с
проектной группой.
1. Цели и Задачи
Формирование концепции решения начинается с выяснения у заинтересованных
сторон, описания и фиксации проектной группой целей проекта. Далее каждая цель
разбивается на измеримые компоненты – задачи.
Содержание данного раздела повторяет содержание раздела 2.1 документа “Концепция
проекта”.
Система должна уметь решать трехкритериальную задачу поиска кратчайших путей на
графах. Критерии:
 Время
 Цена
 Комфорт
Система должна быть распределенной, так как в каждом аэропорте своя база
направлений полетов самолетов. Знают о рейсе только аэропорты – соседи по рейсам.
Требование, выдвигаемое компанией, состоит в том чтобы не делать базу
централизованной, т.к. иначе имеющиеся серверы не будут справляться с нагрузкой, а
новое оборудование слишком дорого.
Выделенные объекты системы:

распределенное хранилище рейсов

покупатель билетов.
Распределенное хранилище рейсов:
Включает следующие атрибуты:

название рейсов

номера

тип самолетов

класс самолета по комфорту

стоимость билетов.
Покупатель:
Выделены следующие атрибуты:

ФИО

Сумма денег.
Покупатель на сайте задает параметры, связанные с суммой, которую он хочет
потратить, комфорт и время. Система в ответ должна подобрать оптимальные
маршруты. Если таковых не находится, то система должна дать в ответе причину, по
которой не получается подобрать маршрут. Среди причин:

Отсутствие вообще рейсов в том направлении даже с пересадками на данный
момент
 Сумма слишком мала
 Комфорт слишком завышен
В ответ пользователь должен иметь возможность поменять параметры с учетом
предыстории.
2. Предположения и Ограничения
В процессе формирования концепции решения проектная группа постоянно
взаимодействует с заинтересованными сторонами, собирая необходимую информацию
о требованиях к функциональности будущего решения. Тем не менее, неизбежная
неполнота информации приводит к тому, что относительно некоторых
функциональных возможностей решения могут потребоваться предположения
(assumptions). Помимо функциональных требований заинтересованные стороны
могут выдвигать качественные требования, задающие ограничения на создаваемое
решение. Также ограничения могут порождаться средой, в которой должно будет
функционировать решение после внедрения.
Содержание данного раздела повторяет содержание раздела 2.2 документа “Концепция
проекта”.
На первую систему есть существенные ограничения:

Система не распределена

Нет разграничения прав между менеджерами и пользователями

Весь интерфейс представлен в одном окне

Система должна демонстрировать визуальные формы и способы хранения и
взаимодействия данных
3. Рамки проекта
Рамки (scope) определяют пространство параметров, в котором будет создаваться
решение, детализируя функциональность , определяя, что останется за рамками
решения и указывая критерии, по которым заинтересованные лица будут судить о
готовности решения. Рамки создаются на основе единого видения, являются
результатом компромисса между сформулированными целями и условиями реальности
и отражают приоритезацию заказчиком имеющихся требований к создаваемому
решению. Частью процесса определения рамок проекта является вынесение менее
важной функциональности из текущего проекта в планы на будущее.
Рамки проекта (project scope) определяют объем работ, который должен быть
выполнен проектной группой для поставки заказчику каждого из элементов,
определенного рамками решения.
Управление рамками проекта критично для его успеха. MSF предлагает определять и
фиксировать рамки решения и проекта, используя треугольник компромиссов и
матрицу компромиссов проекта .
3.1. Матрица компромиссов проекта
Хорошо известна взаимозависимость между ресурсами проекта (людскими и
финансовыми), его календарным графиком (временем) и реализуемыми возможностями
(рамками). Эти три переменные образуют треугольник компромисов (tradeoff
triangle), показанный на рис. 1.
После достижения равновесия в этом треугольнике изменение на любой из его сторон
для поддержания баланса требует модификаций на другой (двух других) сторонах
и/или на изначально измененной стороне.
Рисунок 1. Треугольник компромиссов*
Нахождение верного баланса между ресурсами, временем разработки и возможностями
– ключевой момент в построении решения, должным образом отвечающего нуждам
заказчика.
Рисунок заимствован из белой книги (white paper) “Модель процессов MSF” в переводе корпорации
eLine Software 2003 года.
*
Рисунок 2. Матрица компромиссов*
Другое весьма полезное средство для управления проектными компромиссами –
матрица компромиссов проекта (project tradeoff matrix), показанная на
рис. 2. Она отражает достигнутое на ранних этапах проекта соглашение между
проектной группой и заказчиком о выборе приоритетов в возможных в будущем
компромиссных решениях. В определенных случаях из этой приоритезации могут
делаться исключения, но в целом следование ей облегчает достижение соглашений по
спорным вопросам.
Рис. 2 показывает матрицу компромиссов проекта, используемую обычно проектными
группами Майкрософт. Она помогает обозначить проектное ограничение, воздействие
на которое практически невозможно (колонка “Фиксируется”), фактор, являющийся в
проекте приоритетным (колонка “Согласовывается”), и третий параметр, значение
которого должно быть принято в соответствии с установленными значениями первых
двух величин (колонка “Принимается”).
Принципиально важно наличие у проектной группы и заказчика единого, однозначного
взгляда на матрицу компромиссов проекта.
Укажите здесь оценки (в выбранных вами единицах) параметров треугольника
компромиссов: ресурсы, которыми располагает ваш проект; имеющееся для реализации
проекта время; возможности решения, которые, согласно описанию в документе
“Концепция проекта”, будут вами реализованы. Расставьте приоритеты и постройте на
их основе матрицу компромиссов.
Для разработки первой версии системы у нас имеются следующие ресурсы и
возможности
Ресурсы:
Для первой версии нам выделили 1000 единиц ресурса
Для разработки системы у нас имеется команда из 6-ти человек
Мы располагаем временем:
3 месяца (90 дней включая выходные)
Возможности, которые мы собираемся реализовать:

Хранилище находится в оперативной памяти

Добавление аэропортов по нажатию кнопки
o Проверка корректности введеных данных

Проверка существования аэропорта с введенным номером
o Создание визуальной формы для отображения аэропорта

Добавление рейсов
o Проверка корректности введеных данных

Проверка существования рейса с введенным номером

Проверка на существование аэропортов рейса
o Добавление в визуальные формы аэропортов информации о добавленных
рейсах

Удаление аэропортов
o Удаление всех сопутствующих рейсов

Удаление рейсов

Поиск минимального по стоимости маршрута
Заказ билетов на найденные маршруты
В итоге обсуждений мы приняли следующую матрицу компромиссов:
Фиксируется
Согласовывается
Принемается
Время
Возможности
Ресурсы
Красным обозначены достигнутые решения по компромиссам.
3.2. Вехи проекта
Вехи проекта – это существенные события в жизни проекта. На фазе выработки
концепции обычно “выставляются” внешние вехи, которые показывают достижение
видимых целей проекта. На самом верхнем уровне в качестве внешних вех могут
рассматриваться окончания фаз выполнения проекта. В зависимости от природы
проекта вехи могут быть основаны на финансовых затратах, на прогрессе в проекте, на
временных интервалах и т.д.
Раннее определение вех позволяет установить точки на временном графике проекта, по
которым заинтересованные стороны и проектная группа будут судить о ходе его
выполнения.
Выберите и аргументируйте подход к определению вех в вашем проекте. Определите и
опишите здесь вехи, на которые вы будете ориентироваться в ходе выполнения
проекта.
В ходе проекта выделены следующие вехи:

Фаза выработки концепции
o Ядро проектной группы сформировано
o Черновой вариант концепции проекта составлен

Фаза планирования
o Верификация технологий
o Базовая версия функциональной спецификации создана
o Базовая версия сводного плана проекта создана
o Базовая версия сводного календарного графика проекта создана
o Среды разработки и тестирования развернуты

Фаза разработки
o Концепция подтверждена
o Билд 1 завершен (шаблоны функциональных выделенных классов)
o Билд 2 завершен (реализована функциональность выделенных классов)
o Билд 3 завершен (реализована JNL прослойка)
o Билд 4 завершен (реализована
визуальную оболочку)

вся
функциональность,
Фаза стабилизации
o Точка конвергенции достигнута
o Точка достижения нуля
o Версия-кандидат 1
o Версия-кандидат 2
o Контрольное тестирование завершено
o Тестирование приемлемости для потребителей завершено
o Пилотное внедрение завершено

Фаза внедрения
o Ключевые компоненты развернуты
o Внедрение на местах завершено
o Внедренное решение стабилизировано
включая
3.3. Сметы проекта
Выполнение проекта предполагает использование ресурсов и подразумевает наличие
затрат. Ресурсы включают в себя людей, оборудование, различные расходные
материалы и т.д. Затраты рассчитываются на основе тарифов (расценок) на каждый вид
требуемого ресурса. В данном разделе должна быть представлена информация о:

списке видов ресурсов,

требуемом количестве каждого ресурса,

тарифе на каждый вид ресурса,

общей стоимости каждого ресурса,

общей стоимости всех ресурсов, необходимых проектной группе.
На основе информации данного раздела должен рассчитываться бюджет проекта.
Также этот этап – хорошая возможность идентифицировать специфические ресурсы,
которые могут потребоваться для выполнения проекта.
Укажите, какие виды ресурсов необходимы вашей проектной группе для выполнения
проекта, определите в выбранных единицах количество каждого ресурса, оцените
общие ожидаемые затраты по ресурсам.
Ресурсы
Люди
Тренер для персонала
Рабочие станции
Сервера
Ноутбуки
Аренда помещения
Итого
Стоимость одной
единицы ресурса
60
100
10
20
15
2
Количество единиц
6
2
6
2
2
90
Суммарная
стоимость
360
200
60
40
30
180
870
3.4. План-график проекта
На этом этапе строится первый вариант графика выполнения проекта на основе
выделенных вех и уже сформулированных задач, для каждой из которых задаются даты
начала и окончания.
Процесс построения графика проекта итеративен. На фазе выработки концепции
график строится на основных вехах проекта. На фазе планирования график становится
более детальным в процессе выделения отдельных задач проекта.
На основе выделенных выше вех, а также сформулированных целей и задач определите
ожидаемую временную протяженность проекта и постройте предварительный график
выполнения проекта (см. файл по ссылке).
4. Роли и ответственности
В данном разделе описывается организация проектной группы. Четкие требования к
квалификации, ролям и ответственностям членов проектной группы позволяют
менеджеру проекта правильно подобрать команду и дают каждому понимание его
личного вклада в общий успех проекта.
4.1. Знания, умения и навыки
Участники проектной группы должны удовлетворять определенным требованиям для
успешного выполнения проекта. Эти требования выражаются в терминах знаний,
умений и навыков и должны включать технические, управленческие и иные
возможности. На самом верхнем уровне формулировки необходимых знаний, умений и
навыков могут основываться на стандартных ролях MSF.
На основе имеющейся к данному моменту информации о разрабатываемом решении и
способе его реализации сформулируйте требования к знаниям, умениям и навыкам,
которые необходимы участникам проектной группы. В процессе формулирования
учитывайте, что требования должны касаться всех ролевых кластеров команды (более
подробно см. документ “Модель проектной группы MSF”).
Необходимы следующие знания и умения:

Навыки архитектора систем

Навыки создания дизайна интерфейса

Навыки управления средними проектами

Программистские навыки, знания и умения
o Знания С/С++
o Знание Java
o Знание JNL
4.2. Структура команды
Структура команды определяет организационные единицы (менеджер проекта,
спонсоры, лидеры команд, и т.д.), задает отношения между ними и зоны их
ответственности.
Распределите роли, предлагаемые моделью проектной группы MSF, в вашей команде и
опишите здесь это распределение.

Участник 1 – менеджер проекта и релиз-менеджер

Участник 2 – архитектор и разработчик

Участник 3 – бизнес-аналитик и тестер

Участник 4 – разработчик

Участник 5 – разработчик

Участник 6 – разработчик
5. Протоколы проекта
Протоколы проекта – это набор описаний процессов в проекте, которые должны быть
утверждены, чтобы все участники команды действовали в одинаковом ключе.
Стандартизация повышает производительность и облегчает общение как внутри
проектной группы так и с заинтересованными сторонами.
5.1. Управление рисками
MSF уделяет большое внимание работе с рисками в проекте. На стадии выработки
концепции этому посвящен отдельный документ “Оценка рисков”. Здесь же
необходимо привести общее описание, содержащее:

выбранные проектной группой методы и средства для управления рисками;

расписание мероприятий по управлению рисками в ходе выполнения проекта;

роли и ответственности членов проектной группы в процессе управления рисками.
Основываясь на материале документа “Оценка рисков”, кратко опишите выбранные
проектной группой методы и средства управления рисками. Добавьте к разработанному
выше предварительному графику выполнения проекта расписание мероприятий по
управлению рисками. Распределите мероприятия по управлению рисками между
членами проектной группы и опишите здесь это распределение.
Управление рисками осуществляется путем отслеживания первых трех наиболее
приоритетных рисков.
За отслеживание наступления рисков ответственен Менеджер проекта.
Менеджер проекта обязан, вырабатывает план действий на случай наступления
рисков.
В отведенный запас времени Менеджер проводит мероприятия по снижению
риска наступления рисков. Примерами мероприятий являются:

Обучение персонала

Повторное тестирование сомнительных компонент системы

Мозговые штурмы возможности наступления рисков

Дает команде разработчиков больше времени на отдых для восстановления
морального настроя работников

Проводит «посмертное вскрытие прошедших стадий»
5.2. Управление конфигурацией
Многие составляющие решения в процессе работы над проектом претерпевают
неоднократные изменения, следовательно, проект нуждается в некоторой стратегии
управления конфигурацией , определяющей выбранные методы отслеживания
изменений, ведения отчетности и др. Управление конфигурацией должно охватывать
проектную документацию, среды разработки и тестирования и любые изменения в
проектной среде в целом.
Данный раздел включает:

описание методов и средств управления конфигурацией;

описание шагов по запросу и принятию изменений в конфигурации;

роли и ответственности в управлении конфигурацией;

выбор и/или описание требований к системе контроля версий.
Опишите стратегию управления конфигурацией в проекте в соответствии с
представленными выше пунктами.
5.3. Управление изменениями
Одна из существенных идей, лежащих в основе MSF – ориентированность на
изменения. В то же время порядок внесения предложений, утверждения и реализации
изменений и отслеживания результатов должен быть определен и зафиксирован. Кроме
того, все изменения в проекте должны проводиться в соответствии с принятыми и
утвержденными рамками решения и рамками проекта. В данном разделе должны
быть описаны:

процесс управления изменениями;

форма запроса на изменение;

роли и ответственности в процессе управления изменениями;

действия в случае, если предложенные изменения могут отразиться на контракте с
заказчиком (в том числе, если эти действия были инициированы самим заказчиком,
см. треугольник компромиссов).
Опишите стратегию управления
представленными выше пунктами.
изменениями
в
проекте
в
соответствии
с
Процесс управления изменениями включает в себя несколько стадий:

Отправка
запроса
на
изменение
функциональности
продукта
Заказчик обязан написать запрос в форме определенной ниже к проектно группе

Стадия на верификации на предмет конфликта с матрицей компромиссов

Стадия утверждения изменения проектным менеджером

Стадия утверждения изменения архитектором системы

Стадия окончательного принятия изменение с подписанием скорректированного
план графика
Форма запроса:
Я заказчик (<Расшифровка с указанием всех реквизитов>) системы <Названия
системы>, прошу внести следующие изменения и добавления к продукту:
Добавить функциональность (внести изменения в функциональность):
<Подробное описание функциональности>
За принятие функциональности я согласен на внесения следующих изменений
ресурсов:
Время:
<Описание>
Ресурсов:
<Описание>
Подпись _______________ Дата ____”________”________
С другой стороны ответственные со стороны исполнителя люди не против
добавления (внесения изменений) данной функциональности:
Менеджер проекта (<Расшифровка с указанием всех реквизитов>):
Подпись _______________ Дата ____”________”________
Архитектор (<Расшифровка с указанием всех реквизитов>):
Подпись _______________ Дата ____”________”________
5.4. Управление внедрениями
В MSF работа над решением не заканчивается с окончанием этапа разработки. Важным
аспектом, требующим внимания, является и процесс внедрения как пилотных так и
финальных версий решения. В данном разделе должны быть описаны способы и
средства по подготовке релизов и управлению их внедрением, как в тестовые, так и в
производственные окружения.
Сформулируйте и опишите здесь мероприятия, необходимые для будущего внедрения
решения, которое будет разработано в ходе проекта.
5.5. Достижение качества проекта
Данный раздел описывает, каким образом в ходе выполнения проекта будут
удовлетворяться ожидания заказчика и будущих пользователей к качеству
создаваемого решения, как с точки зрения разработчиков, так и со стороны управления.
Достижение требуемого качества решения должно быть описано через:

ожидания к качеству решения;

процесс проверки качества;

процесс управления достижением качества;

роли и ответственности в процессе достижения качества.
Сформулируйте и опишите стратегию по достижению требуемого качества проекта.
Порогом достижения качества является не более пяти некритических ошибок.
Для достижения качества продукта вводится разбиение разработки продукта на
несколько итераций:

Билд 1 завершен (шаблоны функциональных выделенных классов)

Билд 2 завершен (реализована функциональность выделенных классов)

Билд 3 завершен (реализована JNL прослойка)

Билд 4 завершен (реализована вся функциональность, включая визуальную
оболочку)

Версия-кандидат 1

Версия-кандидат 2
Итерация считается завершенной только в том случае, если количество ошибок
выявленных после тестирования не преодолевает допустимый порог количества
ошибок.
Ответственным за утверждение окончания стадии является менеджер проекта.
5.6. Рабочая среда проекта
В данном разделе должен быть описан подход к созданию рабочей среды проекта,
определяющий как организационные требования (размещение членов команды,
комнаты для митингов и т.д.), так и требования к оборудованию (компьютеры, столы,
телефоны и т.д.). Здесь же должны определяться требования к инструментам и
системам, таким как системы контроля версий, среды разработки, инструменты
тестирования и др.
Сформулируйте и опишите требования к рабочей среде проекта.
Необходимо обеспечить:

Отдельную комнату для рабочей группы

В рабочей комнате должны быть
o Шесть рабочих
обеспечением
станций
со
всем
необходимым
o Рабочие станции должны быть связаны в сеть
программным

Рабочей группе необходим удаленный доступ к двум серверам

Для представления результатов необходимо два ноутбука

В комнате должна быть доска и стол для совещаний рабочей группы