Файл: Управление требованиями проекта(ТЕОРЕТИЧЕСКИЕ АСПЕКТЫ УПРАВЛЕНИЯ ТРЕБОВАНИЯМИ ПРОЕКТА).pdf

ГЛАВА I . ТЕОРЕТИЧЕСКИЕ АСПЕКТЫ УПРАВЛЕНИЯ ТРЕБОВАНИЯМИ ПРОЕКТА

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

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

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

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

---

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

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

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

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

1. Единичность — требование описывает одну и только одну вещь.
2. Завершенность — требование полностью определено в одном месте и вся необходимая информация присутствует.
3. Последовательность — требование не противоречит другим требованиям и полностью соответствует документации.
4. Атомарность — требование нельзя разделить на более мелкие.
5. Отслеживаемость — требование полностью или частично соответствует деловым нуждам как заявлено заинтересованными лицами и задокументировано.
6. Актуальность — требование не стало устаревшим с течением времени.
7. Выполнимость — требование может быть реализовано в рамках проекта.
8. Недвусмысленность — требование определено без обращения к техническому жаргону, акронимам и другим скрытым формулировкам. Оно выражает объекты и факты, а не субъективные мнения. Возможна одна и только одна его интерпретация. Определение не содержит нечетких фраз, использование отрицательных и составных утверждений запрещено.
9. Обязательность — требование представляет собой определенную заинтересованным лицом характеристику, отсутствие которой ведет к неполноценности решения, которая не может быть проигнорирована. Необязательное требование — противоречие самому понятия требования.
10. Проверяемость — реализованность требования может быть проверена.В соответствии со стандартом ITILv3 (ITIL — самое распространенное в мире руководство по управлению ИТ-услугами)все требования в проекте можно разделить на следующие группы:

(ITIL v3 2011 (IT Infrastructure Library v3 2011 Edition)

Библиотека ITIL существует уже более 20 лет и за это время претерпела три редакции.

---

Поначалу ITIL была сфокусирована преимущественно на технических проблемах и развивалась вокруг практического применения информационных технологий.)

1. Функциональные (Functional) — реализуют саму бизнес-функцию.
2. Управленческие (Manageability) — требования к доступным и безопасным сервисам; относятся к размещению системы, администрированию и безопасности.
3. Эргономические (Usability) — к удобству работы конечных пользователей.
4. Архитектурные (Architectural) — требования к архитектуре системы.
5. Взаимодействия (Interface) — к взаимосвязям между существующими приложениями и программным средствами и новым приложением.
6. Сервисного уровня (Service Level) — описывают поведение сервиса, качество его выходных данных и другие качественные аспекты, измеряемые заказчиком.

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

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

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

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

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

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

1. IBM Rational RequisitePro - средство управления требованиями к приложениям и системам на протяжении всего жизненного цикла проекта. Позволяет команде разработчиков определять, систематизировать, отслеживать реализацию и изменение требований, возникающих на любом этапе жизненного цикла информационной системы.
2. Telelogic DOORS -улучшает качество, обеспечивая прозрачность целей создания продукта, требований клиентов, технических заданий, стандартов, условий и инструкций. Обладая широчайшими возможностями для сбора, компоновки, трассировки, анализа и управления изменениями требований, данное многоплатформенное решение обеспечивает полное соответствие проектного задания и окончательного результата при соблюдении нормативов и стандартов.
3. Sybase PowerDesigner  дает возможность управления изменениями на этапе проектирования, предлагает технику управления метаданными и содержит уникальную технологию анализа взаимосвязей моделей. Одновременно с поддержкой ведущих техник моделирования и управления метаданными, PowerDesigner также позволяет работать с моделями любых типов в единой интегрированной среде, а репозиторий метаданных PowerDesigner помогает наладить взаимодействие между всеми заинтересованными лицами компании, что обеспечивает более быстрый отклик на изменения в существующей бизнес-среде.
4. Borland Caliber RM  – это корпоративная система управления требованиями, которая облегчает совместную работу, что позволяет группам разработчикам подходить к вехам проекта вовремя и с запланированными затратами. Borland Caliber RM также помогает командам разработчиков удостовериться, что разрабатываемое приложение удовлетворяет пожеланиям конечных пользователей за счет непрерывного сбора пожеланий на всех этапах жизненного цикла от аналитиков, разработчиков, тестировщиков и других заинтересованных в проекте лиц. п

---

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

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

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

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

Реестр проектов должен содержать структурированную, специально подготовленную информацию о:

1. наименовании и заказчике проекта.
2. типах проектов.
3. финансовых характеристиках (фактическая и плановая информация);
4. параметрах сроков реализации и основных вехах (фактическая и плановая информация).
5. текущем статусе и проблемах.
6. менеджере и команде проекта.
7. принятых ранее решениях по проекту.
8. и другую информацию.

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

Глава II. Практический пример Проект «чумная шестерёнка»

Проект «чумная шестерёнка»

Цель проекта - создание организации по предоставлению услуг аниматоров на фестивалях ,концертах ,фотосессиях или где ещё захочет клиент

---