Файл: Управление требованиями проекта (Управление требованиями проекта: сущность и классификация ).pdf

Глава 1. теоретические аспекты управления требованиями проекта

Управление требованиями проекта: сущность и классификация

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

В таблице 1 можно увидеть классификацию проектов

Классификационные признаки	Типы проектов
По уровню проекта	Проект	Программа			Система
По масштабу (размеру) проекта	Малый	Средний			Мегапроект
По сложности	Простой	Органи-зационно сложный	Технически сложный		Ресурсно сложный		Комплексно сложный
По срокам реализации	Кратко-срочный	Средний			Долгосрочный
По требованиям к качеству и способам его обеспечения	Безде-фектный	Модульный			Стандартный
По совокупности проектов	Монопроект			Мультипроект
По уровню участников	Отечественный: - государственный; - территориальный; - местный.			Международный
По характеру целевой задачи	Антикризисный, Маркетинговый, Образовательный.			Реформирование, Инновационный, Чрезвычайный.
По объекту инвестиционной деятельности	Финансовый, Инвестиционный.			Реальный Инвестиционный
По главной причине возникновения проекта	Открывшиеся возможности			Необходимость структурно-функциональных преобразований		Реорганизация
						Реструктуризация

---

Таблица 1.Классификация проектов.

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

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

1. Условия или возможности, необходимые пользователю для решения проблем или достижения целей.
2. Условия или возможности, которыми должна обладать система или системные компоненты, чтобы выполнить контракт или удовлетворять стандартам, спецификациям или другим формальным документам;
3. Документированное представление условий или возможностей для пунктов 1 и 2.

Требование должно обладать следующими характеристиками:

1. Единичность — требование описывает одну и только одну вещь.
2. Завершенность — требование полностью определено в одном месте и вся необходимая информация присутствует.
3. Последовательность — требование не противоречит другим требованиям и полностью соответствует документации.
4. Атомарность — требование нельзя разделить на более мелкие.
5. Отслеживаемость — требование полностью или частично соответствует деловым нуждам как заявлено заинтересованными лицами и задокументировано.
6. Актуальность — требование не стало устаревшим с течением времени.
7. Выполнимость — требование может быть реализовано в рамках проекта.
8. Недвусмысленность — требование определено без обращения к техническому жаргону, акронимам и другим скрытым формулировкам. Оно выражает объекты и факты, а не субъективные мнения. Возможна одна и только одна его интерпретация. Определение не содержит нечетких фраз, использование отрицательных и составных утверждений запрещено.
9. Обязательность — требование представляет собой определенную заинтересованным лицом характеристику, отсутствие которой ведет к неполноценности решения, которая не может быть проигнорирована. Необязательное требование — противоречие самому понятия требования.
10. Проверяемость — реализованность требования может быть проверена.В соответствии со стандартом ITILv3 (ITIL — самое распространенное в мире руководство по управлению ИТ-услугами)все требования в проекте можно разделить на следующие группы:
11. Функциональные (Functional) — реализуют саму бизнес-функцию.
12. Управленческие (Manageability) — требования к доступным и безопасным сервисам; относятся к размещению системы, администрированию и безопасности.
13. Эргономические (Usability) — к удобству работы конечных пользователей.
14. Архитектурные (Architectural) — требования к архитектуре системы.
15. Взаимодействия (Interface) — к взаимосвязям между существующими приложениями и программным средствами и новым приложением.
16. Сервисного уровня (ServiceLevel) — описывают поведение сервиса, качество его выходных данных и другие качественные аспекты, измеряемые заказчиком.

---

Требования бывают:

• Стандартные требования –требование к качеству продукта или услуге.
• Модульные требования – это повышение требования к качеству в рамках конкретного блока или модуля не теряя качества в других аспектах.
• Бездефектные –требования с чрезвычайными(повышенными) требованиями к качеству.

Требования к проекту могут предъявлять участники проекта и люди которые будут использовать то в будущем. Основные требования предъявляют :

• Заказчик-основные требования к качеству предъявляет именно он.
• Руководитель проекта может помочь заказчику в том случае если он не знает, что именно должно быть или редактировать требования для.оптимизации процесса.
• Так же может быть произведён опрос среди будущих пользователей ,как должен выглядеть или какие функции должны быть (для большего удобства).
• Инвесторы так же могут принимать участи не в ущерб главным целям проекта.
• В случае если этот проект выполняется дочернем ответвлением крупной компании она так же может принять в этом участие так как от этого может зависеть имидж компании.

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

Теперь рассмотрим более подробно вопрос какие самые распространённые программы для управления требованиями проектаможно найти в интернете.
В настоящее время широкое распространение получили такие системы управления требованиями как:

1. IBM RationalRequisitePro - средство управления требованиями к приложениям и системам на протяжении всего жизненного цикла проекта. Позволяет команде разработчиков определять, систематизировать, отслеживать реализацию и изменение требований, возникающих на любом этапе жизненного цикла информационной системы.
2. TelelogicDOORS-улучшает качество, обеспечивая прозрачность целей создания продукта, требований клиентов, технических заданий, стандартов, условий и инструкций. Обладая широчайшими возможностями для сбора, компоновки, трассировки, анализа и управления изменениями требований, данное многоплатформенное решение обеспечивает полное соответствие проектного задания и окончательного результата при соблюдении нормативов и стандартов.
3. SybasePowerDesigner дает возможность управления изменениями на этапе проектирования, предлагает технику управления метаданными и содержит уникальную технологию анализа взаимосвязей моделей. Одновременно с поддержкой ведущих техник моделирования и управления метаданными, PowerDesigner также позволяет работать с моделями любых типов в единой интегрированной среде, а репозиторий метаданных PowerDesigner помогает наладить взаимодействие между всеми заинтересованными лицами компании, что обеспечивает более быстрый отклик на изменения в существующей бизнес-среде.
4. BorlandCaliberRM  – это корпоративная система управления требованиями, которая облегчает совместную работу, что позволяет группам разработчикам подходить к вехам проекта вовремя и с запланированными затратами. BorlandCaliber RM также помогает командам разработчиков удостовериться, что разрабатываемое приложение удовлетворяет пожеланиям конечных пользователей за счет непрерывного сбора пожеланий на всех этапах жизненного цикла от аналитиков, разработчиков, тестировщиков и других заинтересованных в проекте лиц. 

---

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

Ещё дополнили знания о приложениях которые позволяют повысить удобство работы команды проекта

1.2 Процессы управления требованиями проекта

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

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

На рис. 1 представлена общая схема процессов управления содержанием проекта, которые включают в себя следующее:

Рисунок 1. общая схема процессов управления содержанием проекта

Сбор требований — процесс определения, документирования и управления потребностями и требованиями заинтересованных сторон для достижения целей проекта. Ключевая выгода данного процесса состоит в том, что он предоставляет основу для определения и управления содержанием проекта, включая содержание продукта. Входы, инструменты и методы, а также выходы этого процесса показаны на рис. 3.

На рис. 2 показана диаграмма потоков данных процесса.

Рисунок 2.диаграмма потоков данных процесса.

Рисунок 3.Сбор требований

На рисунке «Основные составляющие управления требованиями» показаны базовые операции по управлению требованиями в четырех основных категориях:
— Управление версиями.
— Управление изменениями.
— Отслеживание состояния требований.
— Отслеживание связей требований.

На Рисунке 4 Пример Основных составляющих управления требованиями

Рисунок 4. Основные составляющие управления требованиями.

Матрица соответветствий требований  («TraceabilityMatrix») – двумерная таблица, содержащая соответствии функциональных требований (functionalrequirements) продукта и подготовленных тестовых сценариев (testcases). В заголовках колонок таблицы расположены требования, а в заголовках строк – тестовые сценарии. На пересечении – отметка, означающая, что требование текущей колонки покрыто тестовым сценарием текущей строки. Матрица обычно хранится в виде электронной таблицы.

---

Рисунок 5. Матрица соответветствийтребований

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

обеспечивает  структуру  для  управления  изменениями  содержания  продукта.

Этот  процесс  включает  в  себя,  не  ограничиваясь  только  отслеживанием,  следующие  элементы:

•   требования  к  бизнес-потребностям,  возможностям,  задачам  и  целям;
•   требования  к  целям  проекта;
•   требования  к  содержанию  проекта  /  результатам  ИСР;
•   требования  к  проектированию  продукта;
•   требования  к  разработке  продукта;
•   требования  к  стратегии  и  сценариям  проверки;
•   детализацию  требований  от  высокого  уровня  до  более  детальных  требований.

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

Типичные  параметры,  используемые  в  матрице  отслеживания  требований,  могут  включать  в  себя: 

• уникальный  идентификатор, 
• текстовое  описание  требования, 
• обоснование  включения  в  список  требований,
• владельца, 
• источник, 
• приоритет, 
• версию, 
• текущий  статус 
  • активный, 
  • отменен, 
  • отложен, 
  • добавлен,
  • Одобрен
• дату  выполнения. 

Дополнительные  параметры,  позволяющие  удостовериться,  что  требование

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

На рисунке 6. пример матрицы  отслеживания  требований

Рисунок 6.пример матрицы  отслеживания  требований

Из главы 1.2 мы узнали больше о Процессах управления требованиями проекта ,что такое реестр проекта и матрица соответствий.

---