Управление содержанием проекта (Project Scope) Создание плана управления содержанием проекта Свойства и функции проекта План работ для достижения результата. Сбор требований Инструменты и методы сбора требований Что такое бизнес-требования? Определение функциональных требований Определение нефункциональных требований Правила описания требований Как описывать нефункциональные требования Структура документа для описания требованиий Матрица отслеживания требований. (документация)

1. Управление проектами. Модуль 4.

2. Лекция 19-20
Управление содержанием проекта (Project Scope)
● Создание плана управления содержанием проекта
● Свойства и функции проекта
● План работ для достижения результата.
● Сбор требований
● Инструменты и методы сбора требований
● Что такое бизнес-требования?
● Определение функциональных требований
● Определение нефункциональных требований
● Правила описания требований
● Как описывать нефункциональные требования
● Структура документа для описания требованиий
● Матрица отслеживания требований. (документация)

3. Управление содержанием проекта (Project Scope)
Управление содержанием проекта включает в себя процессы,
обеспечивающие включение в проект тех работ, которые необходимы для
успешного завершения проекта. Оно непосредственно связано с
определением и контролем того, что включено и что не включено в проекте.
Процессы управления содержанием проекта включают:
● Планирование управления содержанием — процесс создания плана управления
содержанием, документирующего, каким образом содержание проекта будет
определяться, подтверждаться и контролироваться.
● Сбор требований – процесс определения и документирования потребностей
заинтересованных сторон проекта для достижения целей проекта.
● Определение содержания – процесс разработки подробного описания проекта и
продукта.
● Создание иерархической структуры работ (ИСР) – процесс разделения
результатов проекта и работ проекта на более мелкие элементы, которыми легче
управлять.
● Подтверждение содержания – процесс формализованной приемки завершенных
результатов проекта.
● Управление содержанием – процесс мониторинга статуса проекта и содержания
продукта, а также управления изменениями базового плана по содержанию.

4. Термины
В контексте проекта термин «содержание» может
обозначать:
● Содержание продукта - свойства и функции, которые
характеризуют продукт, услугу или результат
● Содержание проекта - работы, которые необходимо
выполнить для создания продукта, услуги или результата с
указанными характеристиками и функциями.
В контексте проекта термин «требование» может
обозначать:
● Требования к проекту могут включать в себя бизнес
требования, требования к управлению проектом,
требования к поставке и т.д.
● Требования к продукту могут содержать информацию о
технических требованиях, требованиях к безопасности,
производительности и т.д

5. Планирование управления содержанием
● Планирование управления содержанием — процесс создания плана
управления содержанием, документирующего, каким образом содержание
проекта будет определяться, подтверждаться и контролироваться. Он
предоставляет руководство и указания относительно управления содержанием
проекта на протяжении всего проекта.
● План управления содержанием — компонент плана управления проектом или
программой, описывающий, каким образом содержание будет определяться,
разрабатываться, отслеживаться, контролироваться и проверяться. Разработка
плана управления содержанием и детализация содержания проекта начинается
с анализа информации, содержащейся в уставе проекта, последних одобренных
вспомогательных планов плана управления проектом, исторической
информации, которая содержится в активах процессов организации и других
соответствующих факторов среды предприятия. Данный план помогает снизить
риск расползания содержания проекта.

6. Планы управления содержанием и требованиями
Компоненты плана управления содержанием включают в себя:
● подготовка подробного описания содержания проекта
● процесс, который позволяет создавать ИСР из подробного описания содержания проекта;
● процесс, который определяет, как ИСР будет поддерживаться и одобряться;
● процесс, который устанавливает, как будет производиться формальная приемка
полученных поставляемых результатов проекта;
● процесс контроля обработки запросов на изменения в отношении подробного описания
содержания проекта.
План управления требованиями — это компонент плана управления проектом,
описывающий способы анализа, документирования требований и управления ими.
Включает:
● порядок планирования, отслеживания и составления отчетов о действиях в отношении
требований;
● действия по управлению конфигурацией, такие как порядок инициирования изменений
продукта, порядок анализа воздействий, их выявления, отслеживания и составления
отчетов о них, а также уровни полномочий, необходимые для одобрения данных
изменений;
● процесс приоритезации требований;
● используемые метрики продукта и обоснование их использования;
● структуру отслеживания, т. е. какие параметры требований будут отражены в матрице
отслеживания.

7. Сбор требований
Сбор требований — процесс определения, документирования и управления
потребностями и требованиями заинтересованных сторон для достижения целей
проекта. Ключевая выгода данного процесса состоит в том, что он предоставляет основу
для определения и управления содержанием проекта, включая содержание продукта.
Требования должны быть:
● Однозначны
● Измеримы
● Проверяемы
● Отслеживаемы
● Полными
● Последовательными
● Приемлемы для ключевых заинтересованных
сторон проекта

8. Сбор требований
● На успех проекта напрямую влияет тщательность сбора и
управления требованиями к проекту и продукту. Требования
включают в себя количественно определенные и
формализованные потребности и ожидания спонсора,
заказчика и прочих заинтересованных сторон проекта.
● Данные требования должны быть выявлены,
проанализированы и зарегистрированы с достаточной
степенью детализации так, чтобы их можно было измерить
после начала исполнения проекта. Сбор требований
представляет собой определение ожиданий заказчика и
управление ими.
● Требования становятся базой для ИСР. Планирование
стоимости, расписания и качества строится на основе этих
требований. Разработка требований начинается с анализа
информации, содержащейся в уставе проекта и в реестре и
плане заинтересованных сторон

9. Сбор требований
Требования могут быть сгруппированы в классы. Данные
классы включают в себя:
● Бизнес-требования
● Требования заинтересованных сторон.
● Требования к решению, описывающие свойства, функции и
характеристики продукта, услуги или результата, который
удовлетворит бизнес-требованиям и требованиям
заинтересованных сторон. Делятся на:
● Функциональные требования описывают поведение продукта.
● Нефункциональные требования дополняют функциональные и
описывают условия или качества среды, необходимые для обеспечения
эффективности продукта.
● Требования к переходу
● Требования к проекту
● Требования к качеству

10. Сбор требований- инструменты
● Интервью
● Фокус-группы
● Анализ документов
● Анализ интерфейса
● Наблюдение
● Прототипирование
● Семинары с участием модератора
● Анкеты и опросы
● Бенчмаркетинг
● Методы группового принятия решений
● Методы группового творчества
● Контекстные диаграммы

11. Техники бизнес-анализа
5 Whys Technique ( Техника “5 Почему”) – простая техника,
которая помогает найти быстро источник проблемы. Просто
задавайте вопросы вашему клиенту. Это метод изучения
причинно-следственных связей.
Задавая вопрос «Почему?» пять раз, вы определяете
характер проблемы, решение становится понятным.
Первым делом формулируется исходная
проблема. Затем исследователь задаёт
вопрос: «Почему это произошло
(происходит)?» Получив ответ, он снова
спрашивает: «Почему это произошло?» —
выясняя таким образом причину причины. В
результате выстраивается логическая
цепочка, ведущая к первопричине.
Предполагается, что именно воздействие на
первопричину будет наиболее эффективным
для решения исходной проблемы

12. Техники бизнес-анализа
CATWOE Technique - согласно своему создателю Питеру
Чикленду — это простое перечисление (чек-лист) пунктов
одного из шести параметров, которое помогает стимулировать
мышление и находить самые простые решения для таких
вопросов как:
● Что бизнес пытается достичь?
● Какую проблему пытаемся решить?
● Какое решение внедрим?
C - Клиенты
A - Действующие лица
T – Преобразование
W - Миропонимание
O - Владелец
E - Ограничения внешнего окружения

13. Техники бизнес-анализа
HEPTALYSIS Technique - используется для глубокого анализа
бизнес-целей и возможностей. HEPTALYSIS- это
моделирование, в котором обсуждаются фундаментальные
элементы бизнес-процессов и предлагаются способы систе-
матизации результатов и процесса оценки.
HEPTALYSIS Факторы:
● Возможности рынка
● Продукт/Решение
● План выполнения
● Финансовые средства
● Человеческий капитал
● Потенциальная прибыль
● Маржа безопасности

14. Техники бизнес-анализа
MOST/VMOST Analysis- один из методов стратегического анализа
организации, позволяющий контролировать и обеспечивать
согласованность 5 внутренних элементов предприятия (видения и
миссии, целей, стратегии, тактик) с целью достижения желаемого
результата в процессе его деятельности. Компоненты анализа:
(V)Видение — это цель организации с точки зрения ее
предназначения
(M) Миссия — сформулированное утверждение
относительного того, для чего или по какой причине
существует организация
(O) Цели — это конкретные задачи, достижение
которых необходимо для реализации миссии
(S)Стратегия — это некий общий план,
которому необходимо следовать, чтобы
достигать поставленных целей
(Т) Тактика — это конкретный набор действий,
необходимых для выполнения стратегии

15. Техники бизнес-анализа
SWOT/TOWS Analysis- оба используются для анализа внешней
среды (угрозы и возможности) и вашей внутренней среды
(слабость и сильные стороны). На практическом уровне
единственная разница между TOWS и SWOT заключается в том,
что TOWS подчеркивает внешнюю среду, в то время как SWOT
подчеркивает внутреннюю среду.
Cильные стороны – Какие преимущества? Что сделано хорошо?
Слабые стороны- Что можно было
бы улучшить? Что сделано плохо?
Возможности - Какие хорошие
возможности стоят перед
организацией?
Угрозы - С какими препятствиями
сталкивается организация?

16. Техники бизнес-анализа
PEST Analysis- является инструментом, призванным выявлять
политические (Pоlicy), экономические (Ecоnomy), социальные
(Sоciety) и технологические (Technоlogy) аспекты, способные
оказать влияние на стратегическое развитие предприятия.
Анализ выполняется по схеме «фактор — предприятие».
Результаты анализа оформляются в виде матрицы,
подлежащим которой являются факторы макросреды,
сказуемым — сила их влияния, оцениваемая в баллах, рангах
и других единицах измерения.
Результаты PEST-анализа позволяют
оценить внешнюю экономическую
ситуацию, складывающуюся в
сфере производства и коммерческой
деятельности в ближайшей
перспективе нескольких лет.

17. Техники бизнес-анализа
GAP Analysis- комплексное аналитическое исследование,
изучающее, несоответствия, разрывы между текущим
состоянием компании и желаемым. Этот анализ позволяет
выделить проблемные зоны, препятствующие развитию, и
оценить степень готовности компании к выполнению
перехода от текущего состояния к желаемому.
Этапы GAP анализа:
1. Определение основного интереса фирмы, выраженного в терминах стратегического
планирования
2. Выяснение реальных возможностей фирмы с точки зрения текущего
состояния среды и предполагаемого будущего состояния
3. Определение конкретных показателей стратегического плана, соответствующих
основному интересу фирмы
4. Установление разницы между показателями
стратегического и возможностями, диктуемыми реальным положением фирмы
5. Разработка специальных программ и способов действий,
необходимых для заполнения разрыва

18. Техники бизнес-анализа
McKinsey 7S Framework -представляет собой удобный инструмент
анализа внутренней организационной структуры и принципов
работы компании. Модель анализирует 7 ключевых элементов
микросреды организации и позволяет сделать выводы о том:
насколько правильно выстроены и налажены бизнес-процессы
внутри компании, насколько эффективно используются имеющиеся
ресурсы. Может быть использован, когда необходимо :
● улучшить производительность компании
● изучить возможные последствия
будущих изменений внутри компании
● выровнять отделы и процессы во
время слияния или приобретения
● определить, как наилучшим
образом реализовать
предлагаемую стратегию

19. Функциональные требования
Функциональные требования — это перечень сервисов, которые должна выполнять
система, причём должно быть указано, как система реагирует на те или иные входные
данные, как она ведёт себя в определённых ситуациях и т.д. В некоторых случаях
указывается, что система не должна делать.
Стандартные формы для специфицирования функциональных требований:
● Описание функции или объекта.
● Описание входных данных и их источники.
● Описание выходных данных с указанием пункта их назначения.
● Указание, что необходимо для выполнения функции.
● Если это спецификация функции, необходимо описание предварительных условий
(предусловий), которые должны выполняться перед вызовом функции, и описание
заключительного условия (постусловия), которое должно быть выполнено после
завершения выполнения функции.
● Описание побочных эффектов (если они есть).
Функциональные требования (functional requirements) определяют функциональность
ПО, которую разработчики должны построить, чтобы пользователи смогли выполнить
свои задачи в рамках бизнес-требований. Иногда они называются требованиями
поведения (behavioral requirements), они содержат положения с традиционным
«должен» или «должна»: «Система должна по электронной почте отправлять
пользователю подтверждение о заказе».

20. Нефункциональные требования
Определяют общие качества или атрибуты программной системы. Основными
нефункциональными ограничениями, которые имеют отношение к системе, являются
надежность, производительность, безопасность, удобство использования,
безопасность
Нефункциональные требования можно разделить на 3 основных типа:
● Продукт: удобство использования, надежность, безопасность,
производительность..
● Процессы: стандарты, поставка, внедрение
● Внешние требования: совместимость, законные и экономические ограничения
Требования к продукту указывают желаемые характеристики, которые должна иметь
система или подсистема:
● Надежность (Reliability)
● Безопасность (Security)
● Удобство использования (Usability)
● Производительность (Performance Efficiency)
● Удобство сопровождения (Maintainability)
● Совместимость (Compatibility)
● Требования безопасности (Safety)

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

22. Матрица отслеживания требований
Параметры, связанные с каждым требованием, могут быть записаны в матрице
отслеживания требований. Данные параметры помогают определить ключевую
информацию относительно требований.
Типичные параметры, используемые в матрице отслеживания требований, могут
включать в себя:
● уникальный идентификатор,
● текстовое описание требования,
● обоснование включения в список требований,
● владельца,
● источник,
● приоритет,
● версию,
● текущий статус (активный, отменен, отложен, добавлен,одобрен)
● дату выполнения.
Дополнительные параметры, позволяющие удостовериться, что требование
удовлетворяет заинтересованные стороны проекта, могут включать также
стабильность, сложность и критерии приемки.