![](/stc/img/evkova.png)
Управление требованиями проекта (Управление требованиями проекта: сущность и классификация )
Содержание:
Российская экономика развивается, опираясь на требования и принципы современной рыночной экономики - саморегулирующегося механизма, обеспечивающего производство, распределение, продвижение товара согласно закону спроса и предложения. Только рыночные отношения позволяют покупателям найти продавцов, а продавцам покупателей. В связи с этим важную роль начинают играть разные аспекты бизнеса, о которых знали ранее лишь узкопрофильные специалисты. Например, управление проектами.
На каждом предприятии очень важен проектный подход, в первую очередь, потому что с его помощью, возможно, создать гибкую организационную структуру, которая предназначена для решения задач, несущих в себе отклонения от намеченного процесса производства.
Проектная деятельность это корпоративно-управленческая активность сотрудников, направленная на разработку комплекса мероприятий, способствующих эффективному решению актуальных проблем культуры в условиях определенных временных рамок. Она позволит создать в стране цивилизованный рынок культурных благ и услуг для населения.
Проекты различаются по уровню, масштабам изменений, широте охвата, по требованиям к качеству и способам его обеспечения, по совокупности проектов, по уровню участников, по характеру целевой задачи, по объекту инвестиционной деятельности, по главной причине возникновения проекта.
Правление проектами - интегрированный процесс. Действия (или их отсутствие) в одном направлении обычно влияют и на остальные направления. Такая взаимосвязь заставляет балансировать между задачами проекта - часто улучшение в одной области может быть достигнуто лишь за счет ухудшения в другой. Для лучшего понимания интегрированной природы Управления Проектами опишем его через процессы, из которых оно состоит и их взаимосвязи.
Глава 1. теоретические аспекты управления требованиями проекта
Управление требованиями проекта: сущность и классификация
Проект-согласно новому стандарту ISO 21500 — уникальный набор процессов, состоящих из скоординированных и управляемых задач с начальной и конечной датами, предпринятых для достижения цели. Достижение цели проекта требует получения результатов, соответствующих определенным заранее требованиям, в том числе ограничения на получение результатов, таких как время, деньги и ресурсы.
В таблице 1 можно увидеть классификацию проектов
Классификационные признаки |
Типы проектов |
||||||
По уровню проекта |
Проект |
Программа |
Система |
||||
По масштабу (размеру) проекта |
Малый |
Средний |
Мегапроект |
||||
По сложности |
Простой |
Органи-зационно сложный |
Технически сложный |
Ресурсно сложный |
Комплексно сложный |
||
По срокам реализации |
Кратко-срочный |
Средний |
Долгосрочный |
||||
По требованиям к качеству и способам его обеспечения |
Безде-фектный |
Модульный |
Стандартный |
||||
По совокупности проектов |
Монопроект |
Мультипроект |
|||||
По уровню участников |
Отечественный: - государственный; - территориальный; - местный. |
Международный |
|||||
По характеру целевой задачи |
Антикризисный, Маркетинговый, Образовательный. |
Реформирование, Инновационный, Чрезвычайный. |
|||||
По объекту инвестиционной деятельности |
Финансовый, Инвестиционный. |
Реальный Инвестиционный |
|||||
По главной причине возникновения проекта |
Открывшиеся возможности |
Необходимость структурно-функциональных преобразований |
Реорганизация |
||||
Реструктуризация |
Таблица 1.Классификация проектов.
Требование — это любое условие, которому должна соответствовать разрабатываемая система или программное средство. Требованием может быть возможность, которой система должна обладать и ограничение, которому система должна удовлетворять.
В соответствии с Глоссарием терминов программной инженерии IEEE, являющимся общепринятым международным стандартным глоссарием, требование это:
- Условия или возможности, необходимые пользователю для решения проблем или достижения целей.
- Условия или возможности, которыми должна обладать система или системные компоненты, чтобы выполнить контракт или удовлетворять стандартам, спецификациям или другим формальным документам;
- Документированное представление условий или возможностей для пунктов 1 и 2.
Требование должно обладать следующими характеристиками:
- Единичность — требование описывает одну и только одну вещь.
- Завершенность — требование полностью определено в одном месте и вся необходимая информация присутствует.
- Последовательность — требование не противоречит другим требованиям и полностью соответствует документации.
- Атомарность — требование нельзя разделить на более мелкие.
- Отслеживаемость — требование полностью или частично соответствует деловым нуждам как заявлено заинтересованными лицами и задокументировано.
- Актуальность — требование не стало устаревшим с течением времени.
- Выполнимость — требование может быть реализовано в рамках проекта.
- Недвусмысленность — требование определено без обращения к техническому жаргону, акронимам и другим скрытым формулировкам. Оно выражает объекты и факты, а не субъективные мнения. Возможна одна и только одна его интерпретация. Определение не содержит нечетких фраз, использование отрицательных и составных утверждений запрещено.
- Обязательность — требование представляет собой определенную заинтересованным лицом характеристику, отсутствие которой ведет к неполноценности решения, которая не может быть проигнорирована. Необязательное требование — противоречие самому понятия требования.
- Проверяемость — реализованность требования может быть проверена.В соответствии со стандартом ITILv3 (ITIL — самое распространенное в мире руководство по управлению ИТ-услугами)все требования в проекте можно разделить на следующие группы:
- Функциональные (Functional) — реализуют саму бизнес-функцию.
- Управленческие (Manageability) — требования к доступным и безопасным сервисам; относятся к размещению системы, администрированию и безопасности.
- Эргономические (Usability) — к удобству работы конечных пользователей.
- Архитектурные (Architectural) — требования к архитектуре системы.
- Взаимодействия (Interface) — к взаимосвязям между существующими приложениями и программным средствами и новым приложением.
- Сервисного уровня (ServiceLevel) — описывают поведение сервиса, качество его выходных данных и другие качественные аспекты, измеряемые заказчиком.
Требования бывают:
- Стандартные требования –требование к качеству продукта или услуге.
- Модульные требования – это повышение требования к качеству в рамках конкретного блока или модуля не теряя качества в других аспектах.
- Бездефектные –требования с чрезвычайными(повышенными) требованиями к качеству.
Требования к проекту могут предъявлять участники проекта и люди которые будут использовать то в будущем. Основные требования предъявляют :
- Заказчик-основные требования к качеству предъявляет именно он.
- Руководитель проекта может помочь заказчику в том случае если он не знает, что именно должно быть или редактировать требования для.оптимизации процесса.
- Так же может быть произведён опрос среди будущих пользователей ,как должен выглядеть или какие функции должны быть (для большего удобства).
- Инвесторы так же могут принимать участи не в ущерб главным целям проекта.
- В случае если этот проект выполняется дочернем ответвлением крупной компании она так же может принять в этом участие так как от этого может зависеть имидж компании.
Управление требованиями — процесс, включающий идентификацию, выявление, документацию, анализ, отслеживание, приоретизацию требований, достижение соглашений по требованиям и затем управление изменениями и уведомление заинтересованных лиц. Управление требованиями — непрерывный процесс на протяжении всего жизненного цикла продукта.
Теперь рассмотрим более подробно вопрос какие самые распространённые программы для управления требованиями проектаможно найти в интернете.
В настоящее время широкое распространение получили такие системы управления требованиями как:
- IBM RationalRequisitePro - средство управления требованиями к приложениям и системам на протяжении всего жизненного цикла проекта. Позволяет команде разработчиков определять, систематизировать, отслеживать реализацию и изменение требований, возникающих на любом этапе жизненного цикла информационной системы.
- TelelogicDOORS-улучшает качество, обеспечивая прозрачность целей создания продукта, требований клиентов, технических заданий, стандартов, условий и инструкций. Обладая широчайшими возможностями для сбора, компоновки, трассировки, анализа и управления изменениями требований, данное многоплатформенное решение обеспечивает полное соответствие проектного задания и окончательного результата при соблюдении нормативов и стандартов.
- SybasePowerDesigner дает возможность управления изменениями на этапе проектирования, предлагает технику управления метаданными и содержит уникальную технологию анализа взаимосвязей моделей. Одновременно с поддержкой ведущих техник моделирования и управления метаданными, PowerDesigner также позволяет работать с моделями любых типов в единой интегрированной среде, а репозиторий метаданных PowerDesigner помогает наладить взаимодействие между всеми заинтересованными лицами компании, что обеспечивает более быстрый отклик на изменения в существующей бизнес-среде.
- 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. Краткая характеристика проекта
В данной главе будет реализован проект под названием «Чумная шестеренка».
Это малый по сути проект но, организационно сложный, долгосрочный проект, по требованиям проект стандартный. Этот проект представляет собой монопроект (территориальный) , но есть случаи международного участия.
Проект «чумная шестерёнка» создавался для создания конкуренции похожим проектам на ближайшей территории .
Проект «чумная шестерёнка» создавался для замены подобных, устаревших проектов на данной территории.
Цель проекта: цель проекта – реализация проекта «Чумная шестеренка».
результат – реализованный проект.
- Создание организации по предоставлению услуг аниматоров на фестивалях ,концертах ,фотосессиях или где ещё захочет клиент.
- Создание визуальных новелл по авторским персонажам при участии штатных художников
- Для фан базы создание мерча для коммерческой продажи
Так же создания стенда для продажи на мероприятиях мерча и новелл
- Стабильная работа пиар базы в социальных сетях и администрации групп
результат – реализованный проект
- Создана организация по предоставлению услуг аниматоров на фестивалях ,концертах ,фотосессиях или где ещё захочет клиент.
- Наладился стабильных выход новелл по авторским персонажам при участии штатных художников
- С участием сторонних мастерских (по обоюдно выгодной договорённости)создаётсямерч для продажи на мероприятиях и социальных сетях для фанатской базы
Так же группой проекта был создан стенд для продажи мерча и новелл на мероприятиях
- Создана администрация групп в социальных сетях (вконкте,инстаграмм)
Основными ограничениями проекта являются
- Необходимо реализовать проект в течении года
- Проект ограничен группой в размере 20 человек (не включая дополнительно 5 не постоянных участников)
- Качество костюмов ,подготовки персонажа для участников должен быть выполнен в хорошем качестве и улучшаться
- Проект ограничен в средствах при работе с сторонними мастерскими при изготовлении деталей для костюма высшего качества из сложных материалов
участники проекта: заказчик, спонсоры проекта, аналитики, команда проекта, будущие потребители, музыкальные группы, организаторы фестивалей и мероприятий .
команда проекта:
- Руководитель проекта 1 человек
- администрация сообществ в социальных сетях 2 человека
- группа художников 4 человека
- группа аниматоров 9человека
- команда сборки стенда 5людей
В задачи входит:
- следить за группой и его популяризацией
- ежедневный постинг
- реклама в других группах
- отслеживать в схожих по тематике группах за контентом с персонажами проекта
Так же на мероприятиях стенд по продаже мерча с персонажами и развлечение клиентов
Создание группой арт дизайнов для коллектива и принятие сторонних заказов
Требования к участникам проекта:
-
-
- качество костюмов в которых посещаются мероприятия
- в случае вспомогательного персонала это качество оборудования такие как; фото техника, видеокамера, света аппаратура
-
Глава 2.1.
1. Конкуренты проекта
Основными конкурентами можно назвать
Мкчд (московская коллегия чумных докторов) основной конкурент в Москве ,который надо обойти
Второстепенные это более малые проекты такие как
Клокворк
Волгоградские чумные доктора
Паровой отдел
Рисунок 7. ИСР проекта
Рисунок 7. ИСР проекта
Рисунок 8. Работа-Вершина.
Рисунок 9. Работа-дуга.
Рисунок 10. Календарный план проекта
ЗАКЛЮЧЕНИЕ
В ходе данной курсовой работе было разобрано расписание проекта и календарное планирование и все что с ними связано, был проделан анализ выбранного проекта и его подробное описание, также была построена ИСР проекта и просчитаны такие работы как работа-Вершина, работа-Дуга, календарный план проекта.
Результатом проекта будет непосредственное открытие полностью функционирующей групп в соц сетях и дальнейшее продвижение работ с выступлениями.
Для разработки календарного плана проекта, необходимо было построить Работу-Дугу, Работу-Вершину и ИСР, которые и помогли построить календарный план проекта.
Исходя из календарного плана проекта, можно сказать что проект имеет 15 работ, а его продолжительность равняется 30 дням.
Целью данной курсовой работы было описать календарной планирование проекта для работы с клиентами через группы, что и показано выше.
Список литературы
- Афонин, А. М. Управление проектами / А.М. Афонин, Ю.Н. Царегородцев, С.А. Петрова. - М.: Форум, 2016. – 184с.
- Борщевский, Г. А. Государственно-частное партнерство. Учебник и практикум / Г.А. Борщевский. - М.: Юрайт, 2015. - 346 c.
- Кемп, Сид Управление проектами. Без мистики / Сид Кемп. - М.: Гиппо, 2014. - 372 c.
- Проекты и управление проектами в современной компании: учебное пособие / Товб А.С., Ципес ГЛ.- М.: Олимп-Бизнес, 2010. - 304с.
- Управление проектами: Практическое руководство / Грей К.Ф.,
Ларсон Э.У. – М.: Дело и сервис, 2003. - 521с.
- ГОСТ Р 54869-2011 Проектный менеджмент требования к управлению проектом. – 2011. - Режим доступа: - http://docs.cntd.ru/document/gost-r-54869-2011
- ГОСТ Р 54870-2011 Проектный менеджмент. Требования к управлению портфелем проектов. – 2011. - Режим доступа: http://docs.cntd.ru/document/gost-r-54870-2011
- ГОСТ Р 54871-2011 Проектный менеджмент. Требования к управлению программой. – 2011. - Режим доступа: http://docs.cntd.ru/document/1200089606
- Microsoft Project - http://www.ms-project.ru.
- Московское отделение PMI - http://pmi.ru.
Сайт, посвященный управлению проектами - http://www.pmonline.ru.
- Управление требованиями проекта (ТЕОРЕТИЧЕСКИЕ АСПЕКТЫ УПРАВЛЕНИЯ ТРЕБОВАНИЯМИ ПРОЕКТА)
- Автоматизация продажи железнодорожных билетов (Технико-экономическая характеристика предметной области и предприятия0
- Понятие оперативно-розыскной деятельности (Понятие и правовая природа оперативно-розыскной деятельности)
- «Понятие, признаки и правовое регулирование несостоятельности (банкротства)»
- Физические и юридические лица. Общее понятие (Физические лица, как субъекты гражданского права)
- Понятие пенсии по инвалидности (Пенсия по инвалидности)
- Социально-экономические права и свободы граждан
- Обязательное социальное страхование в государственной системе социального обеспечения
- Выбор стиля руководства в организации
- Соотношение государства и гражданского общества (Понятие и признаки правового государства)
- Анализ процесса принятия решения о выборе места размещения потенциальными потребителями (Теоретические основы процесса принятия решений на потребительском рынке)
- Особенности корпоративного управления в России (Понятие и становление корпоративного управления в России)