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

Содержание:

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

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

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

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

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

Глава 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 мы узнали больше о Процессах управления требованиями проекта ,что такое реестр проекта и матрица соответствий.

Так же ознакомились что такое Управление содержанием проекта вместе с Сбором требований.

Все эти пункты важны для установки требований дополнений и отслеживания для удобства работы проекта.

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

2.1. Краткая характеристика проекта

В данной главе будет реализован проект под названием «Чумная шестеренка».

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

Проект «чумная шестерёнка» создавался для создания конкуренции похожим проектам на ближайшей территории .

Проект «чумная шестерёнка» создавался для замены подобных, устаревших проектов на данной территории.

Цель проекта: цель проекта – реализация проекта «Чумная шестеренка».

результат – реализованный проект.

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

Так же создания стенда для продажи на мероприятиях мерча и новелл

1. Стабильная работа пиар базы в социальных сетях и администрации групп

результат – реализованный проект

1. Создана организация по предоставлению услуг аниматоров на фестивалях ,концертах ,фотосессиях или где ещё захочет клиент.
2. Наладился стабильных выход новелл по авторским персонажам при участии штатных художников
3. С участием сторонних мастерских (по обоюдно выгодной договорённости)создаётсямерч для продажи на мероприятиях и социальных сетях для фанатской базы

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

1. Создана администрация групп в социальных сетях (вконкте,инстаграмм)

Основными ограничениями проекта являются

• Необходимо реализовать проект в течении года
• Проект ограничен группой в размере 20 человек (не включая дополнительно 5 не постоянных участников)
• Качество костюмов ,подготовки персонажа для участников должен быть выполнен в хорошем качестве и улучшаться
• Проект ограничен в средствах при работе с сторонними мастерскими при изготовлении деталей для костюма высшего качества из сложных материалов

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

команда проекта:

• Руководитель проекта 1 человек
• администрация сообществ в социальных сетях 2 человека
• группа художников 4 человека
• группа аниматоров 9человека
• команда сборки стенда 5людей

В задачи входит:

• следить за группой и его популяризацией
• ежедневный постинг
• реклама в других группах
• отслеживать в схожих по тематике группах за контентом с персонажами проекта

Так же на мероприятиях стенд по продаже мерча с персонажами и развлечение клиентов

Создание группой арт дизайнов для коллектива и принятие сторонних заказов

Требования к участникам проекта:

• • 1. качество костюмов в которых посещаются мероприятия
    2. в случае вспомогательного персонала это качество оборудования такие как; фото техника, видеокамера, света аппаратура

Глава 2.1.
1. Конкуренты проекта

Основными конкурентами можно назвать

Мкчд (московская коллегия чумных докторов) основной конкурент в Москве ,который надо обойти

Второстепенные это более малые проекты такие как

Клокворк

Волгоградские чумные доктора

Паровой отдел

Рисунок 7. ИСР проекта

Рисунок 7. ИСР проекта

Рисунок 8. Работа-Вершина.

Рисунок 9. Работа-дуга.

Рисунок 10. Календарный план проекта

ЗАКЛЮЧЕНИЕ

В ходе данной курсовой работе было разобрано расписание проекта и календарное планирование и все что с ними связано, был проделан анализ выбранного проекта и его подробное описание, также была построена ИСР проекта и просчитаны такие работы как работа-Вершина, работа-Дуга, календарный план проекта.

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

Для разработки календарного плана проекта, необходимо было построить Работу-Дугу, Работу-Вершину и ИСР, которые и помогли построить календарный план проекта.

Исходя из календарного плана проекта, можно сказать что проект имеет 15 работ, а его продолжительность равняется 30 дням.

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

Список литературы

1. Афонин, А. М. Управление проектами / А.М. Афонин, Ю.Н. Царегородцев, С.А. Петрова. - М.: Форум, 2016. – 184с.
2. Борщевский, Г. А. Государственно-частное партнерство. Учебник и практикум / Г.А. Борщевский. - М.: Юрайт, 2015. - 346 c.
3. Кемп, Сид Управление проектами. Без мистики / Сид Кемп. - М.: Гиппо, 2014. - 372 c.
4. Проекты и управление проектами в современной компании: учебное пособие / Товб А.С., Ципес ГЛ.- М.: Олимп-Бизнес, 2010. - 304с.
5. Управление проектами: Практическое руководство / Грей К.Ф.,

Ларсон Э.У. – М.: Дело и сервис, 2003. - 521с.

1. ГОСТ Р 54869-2011 Проектный менеджмент требования к управлению проектом. – 2011. - Режим доступа: - http://docs.cntd.ru/document/gost-r-54869-2011
2. ГОСТ Р 54870-2011 Проектный менеджмент. Требования к управлению портфелем проектов. – 2011. - Режим доступа: http://docs.cntd.ru/document/gost-r-54870-2011
3. ГОСТ Р 54871-2011 Проектный менеджмент. Требования к управлению программой. – 2011. - Режим доступа: http://docs.cntd.ru/document/1200089606
4. Microsoft Project - http://www.ms-project.ru.
5. Московское отделение PMI - http://pmi.ru.

Сайт, посвященный управлению проектами - http://www.pmonline.ru.