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

Содержание:

ВЕДЕНИЕ

Название проекта: «Мастерская». «Мастерская» - проект для коммерческого использования, для личных нужд и получения прибыли. Причина проекта – множество неквалифицированных сервисных центров. Целью данного проекта является открыть мастерскую по ремонту электронной техники, результатом – открытие мастерской.

Также, были посчитаны возможные допущения проекта: превышение сроков на 10 дней; превышение бюджета на 250 тыс. руб. Требуется: качественный ремонт, конкурентно способные цены на услуги, квалифицированные рабочие, современное оборудование. Руководителем проекта были установлены укрупнённый бюджет и риски. Бюджет составляет 1.5 миллиона рублей. Риски некачественного оборудования, неквалифицированные рабочие.

Были выявлены критерии успешности данного проекта:

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

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

• выполнить ремонт за 24 недели;
• уложить все затраты в 1,5 млн. руб.

В данном проекте заинтересованы следующие стороны:

• Владелец;
• Руководитель проекта;
• Команда проекта.

Другие участники – они же поставщики оборудования, материалов и ресурсов.

Актуальность выбранной темы. Управления требованиями проекта – огромная сфера, считается что она сформировалась относительно недавно, но это отнюдь не так. Начало было положено ещё в XIX веке. С тех пор эта наука стремительно росла, к её развитию приложили руку социальные методы, научные подходы и бизнес подходы. Современное управление проектами больше напоминает методики структуризации работ и сетевое планирование, которые были разработаны в конце 50-ых годов XX века в США.

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

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

В соответствие с поставленной целью необходимо решить следующие задачи:

- изучить учебную, справочную литературу и теоретический материал по управлению требованиями проекта;

- описать процессы управления требованиями проекта;

- реализовать практический проект и описать его процессы.

Предметом курсовой работы являются управления требованиями проекта «Мастерская».

Объектом исследования является проект «Мастерская».

Были использованы методы исследования: анализ; наблюдение; измерение; описание; сравнение; моделирование.

Структура курсовой работы состоит из введения; двух глав; заключения.

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

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

Требование – это характеристика или условие, которому должна удовлетворять ПС.

Функциональные требования определяют действия, которые должна выполнять ПС, без учета физических ограничений. Тем самым они определяют поведение системы при вводе и выводе. Процесс выявления функциональных требований весьма сложный и трудоемкий. Это объясняется следующими причинами:

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

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

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

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

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

Цели анализа и моделирования требований:

Целями анализа и моделирования требований являются:

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

Роли:

• Системный аналитик – специалист организации-разработчика, который возглавляет и координирует работы по выявлению и моделированию требований.
• Разработчик ВИ – специалист организации-разработчика, который детализирует и уточняет модели требований.
• Заинтересованные лица – люди, предоставляющие информацию.
• Эксперт – представитель заказчика, участвующий в разработке модели требований.
• Разработчик пользовательского интерфейса – специалист организации-разработчика, который создает прототип пользовательского интерфейса ПС.

Для достижения поставленных целей предусматривается создание следующих документов:

• Предварительное соглашение – текстовый документ, который описывает, что будет включено в ПС и что решено исключить, то есть, он ограничивает системную функциональность. В нем отражаются пожелания заинтересованных лиц, а также указываются основные нефункциональные требования.
• Модель требований служит для достижения соглашения между заказчиком и разработчиками, давая возможность заказчику убедиться в том, что система будет делать то, что они ожидают, а разработчикам создать то, что требуется. Модель требований позволяет, во-первых, установить иерархию требований, что способствует лучшему пониманию человеком, во-вторых, дает наглядное графическое представление требований и зависимостей между ними, в-третьих позволяет связать графическую форму представления с текстовой. Модель включает актеров и ВИ, показывает, как система взаимодействует с актерами и что она делает в каждом ВИ.
• Спецификация требований (Software Requirements Specification) – основной документ, используемый при проектировании и разработке ПС. Она включает модель требований и дополнительные спецификации, которые представляют собой текстовое описание требований к конечному продукту, но не к процессу его разработки и не содержат деталей реализации требований.
• Прототип пользовательского интерфейса обеспечивает визуальное представление интерфейса пользователя с ПС.
• Глоссарий – текстовый документ, содержащий определения основных понятий и терминов, которые должны одинаково пониматься заказчиком и разработчиком. Источниками данных для создания перечисленных артефактов могут, в частности, служить артефакты, созданные при бизнес-анализе.

Базовое соглашение о требованиях

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

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

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

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

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

• откладывание или полный отказ от реализации требований с низкими приоритетами;

• привлечение дополнительных сотрудников или аутсорсинг части работы;

• продление графика или добавление дополнительных итераций в проект гибкой разработки;

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

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

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

Управление версиями требований

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

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

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

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

• Управление версиями;
• Управление изменениями;
• Отслеживание состояния требований;
• Отслеживание связей требований.

На русинке 1 представлены основные составляющие управления требованиями.

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

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

Обратите внимание на следующее:

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

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

Важно! Если никто из участников проекта не несет ответственности за выполнение этапов управления требованиями, не следует ожидать их выполнения. Аналогично, если отвечают «все», то каждый человек может ожидать, что кто-то другой выполнит те или иные действия, поэтому они могут легко остаться невыполненными.

ГЛАВА 2. АНАЛИЗ УПРАВЛЕНИЯ ТРЕБОВАНИЯМИ ПРОЕКТА НА ПРИМЕРЕ ПРОЕКТА РЕМОНТ ЭЛЕКТРОННОЙ ТЕХНИКИ

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

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

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

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

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

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

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

Руководителем проекта были установлены укрупнённый бюджет и риски. Бюджет составляет 1.5 миллиона рублей. Риски некачественного оборудования, неквалифицированные рабочие.

Заинтересованные стороны проекта:

• заказчик;
• руководитель проекта;
• команда проекта;
• поставщики;
• будущие потребители.

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

Таблица 1. Реестр заинтересованных сторон.

ЗС (должность)	ФИО	Роль в проекте	Интерес к проекту	Что могут предложить проекту	Что может предложить проект
Владелец	Попов Максим Денисович	Владелец	Личная	Бюджет	Мастерскую по ремонту
Руководитель проекта	Григорьев Николай Андреевич	Руководитель	Выполнить проект, получить прибыль	План действий	Выполненный проект
Команда проекта		Исполнители	Выполнить проект, получить прибыль	Рабочая сила	Рабочие места
Поставщики		Поставка ресурсов	Получить прибыль	Ресурсы	Место сбыта ресурсов

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

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

Таблица 2. Матрица ответственности.

Работы проекта	Участники проекта
	Владелец	Руководитель проекта	Команда проекта
Поиск места для сервиса	У/С	О	И
Арена помещения	У	О	И
Ремонт помещения	У	К/О	И
Закупка оборудования	У/С	К/О	И
Поиск сотрудников	К/С	О	И
Подготовка к работе	У	С/О	И

Расшифруем некоторые обозначения таблицы 1: У - Утверждает; К - Координирует; С - Согласовывает; О - Организует; И - Исполняет

Как можно увидеть по данным из таблицы 2. Владелец проекта лишь утверждает действия по проекту, а команда проекта исполняет все действия.

Таблица 3 - реестр требований описывает классы и виды требований каждого из заинтересованной стороны к проекту, описывает дату их выполнения и способы проверки.

Таблица 3. Реестр требований проекта.

ЗС	Дата выполнения проекта	Качество выполнения	Требования к выполнению	Соблюдение бюджета	Способ проверки
Владелец	20.12.2020	Качество важнее	Сроки, качество	Есть небольшой запас	Осмотр хода работ
Руководитель проекта	20.12.2020	Не допускать ошибок	Сроки, качество	Придерживаться изначальному плану	Контроль хода работ
Команда проекта	20.12.2020	Придерживаться плана	Сроки	Не выходить за рамки	Выполнения хода работ
Поставщики	20.12.2020	Как можно скорее	Подготовить и отправить заказ	Выполнить заказ на поставленных условиях	Выполнение заказа

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

На рисунке 2 показана организационная структура проекта.

Рисунок 2. Организационная структура.

В первой главе были рассмотрены основные характеристики процессов управления проектами: инициации, планирования, исполнения, мониторинга и контроля, закрытия. Рассмотрим содержание указанных процессов для проекта по ремонту электронной техники.

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

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

Также была выполнена координация людей и других ресурсов для выполнения плана.

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

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

Начинаются с процесса инициации.

Процессы завершения – формализация выполнения проекта и подведение его к упорядоченному финалу.

Рассмотрим процессы с точки зрения разбиения их на фазы проекта и учтем работы проекта.

Таблица 4. Процессы и фазы проекта.

№ п/п	Процесс	Фаза	Работа	Длительность, недели
1	Инициация	Прединвестиционная	Формирование новой идеи	2 недели
2			Начальный план реализации	2 недели
3			Поиск помещения	1 неделя
4	Планирование	Разработка	План ремонта помещения	2 неделя
5			План рабочих мест	1 недели
6			План будущей рекламы	2 недели
7			Поиск ресурсов	3 недели
8			Поиск оборудования	3 недели
9	Исполнение	Реализация	Закупка материалов	2 недели
10			Закупка оборудования	2 недели
11			Ремонт помещения	5 недель
12			Установка оборудования	2 недели
13			Отладка оборудования	2 недели
14			Обучение новых рабочих	4 недели
15	Мониторинг и контроль		Проверка качества работ	3 недели
16			Пробные работы	1 недели
17			Финальная отладка всего	2 недели
18	Закрытие	Завершение	Оплата работ	2 недели
19			Расформирование команды проекта	1 неделя
20			Открытие мастерской	1 неделя

По данным из таблицы 4 видим процессы и фазы проекта, количество работ и их длительность в проекте. Так же самая долгая фаза в данном проекте – фаза реализации.

На рисунке 3 показана иерархическая структура работ, далее на основе которой будет построен сетевой график, данная ИСР была построена на основании фаз проекта.

Рисунок 3. Иерархическая структура работ.

Список работ, их продолжительность описана в таблице 5, построена данная таблица на основе ИСР.

Таблица 5. Определение последовательности операций.

Операции	Обозначение операции	Предшествующая операция	Длительность операций, недели
Формирование новой идеи	A	-	2
Начальный план реализации	B	A	2
Поиск помещения	C	B	1
План ремонта помещения	D	-	2
План рабочих мест	E	D	1
План будущей рекламы	F	E	2
Поиск ресурсов	G	F	3
Поиск оборудования	H	G	3
Закупка материалов	I	-	2
Закупка оборудования	J	I	2
Ремонт помещения	K	J	5
Установка оборудования	L	K	2
Отладка оборудования	M	L	2
Обучение новых рабочих	N	M	4
Проверка качества работ	O	N	3
Пробные работы	P	O	1
Финальная отладка всего	Q	P	2
Оплата труда	R	-	2
Расформирование команды проекта	S	R	1
Открытие мастерской	T	S	1

В таблице 5 приведена информация по количеству работ, наименования работ, и её продолжительность. Данная таблица построена на основе ИСР.

Ниже на рисунке 4 изображён сетевой график вида «Работа-Вершина», который был построен по дынным из таблицы 5. На этом графике показывается количество работ и её последовательность, критический путь с резервами работ, и жизненный цикл, что позволяет чётко увидеть сколько времени потребуется на завершение проекта.

Рисунок 4. Сетевой модель вида «Работа-Вершина».

У данной сетевой модели один критический путь и длительность составляет 23 недели.

На рисунке 5 представлена сетевая модель вида «Работа-Дуга», построена по данным из таблицы 5, по которым видно последовательность, жизненный цикл проекта. Принцип данной модели отличается от предыдущей, но сроки у этих работ совпадают. Над каждой не пунктирной стрелочкой должна быть написана работа

Рисунок 5. Сетевой модель вида «Работа-Дуга».

Сетевая модель вида «Работа-Дуга», строится на основании данных представленных в таблице 5, по которым видно последовательность работ, жизненный цикл проекта.

Данные представленные на рисунке 6 это календарный план проекта. В нём прекрасно видны работы, длительность работ и их резерв времени.

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

На календарном плане прекрасно видны работы, длительность работ и их резерв времени.

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

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

Таблица 6. Реестр требований проекта.

ЗС	Класс требований	Вид требований	Описание требований	Номер требования	Дата выполнения	Способ проверки
Владелец	Требования к качеству	Требования к проекту и результату	Качественно сделанный ремонт	Т1	20.12.20	Документ
Владелец	Требования к качеству	Требования к проекту	Доставить оборудование	Т2	С начала диагностики до завершения ремонта	Документ
Владелец	Требования ЗС	Требования к проекту	Квалифицированные рабочие	Т3	С начала диагностики до завершения ремонта	Документ
Руководитель проекта	Требования ЗС	Требования к результату	Заработная плата	Т4	20.12.20	-
Команда проекта	Требования ЗС	Требования к результату	Заработная плата	Т5	20.12.20	-

Таблица 7. Матрица отслеживания требований проекта.

Название проекта	«Мастерская»
Описание проекта	Ремонт электронной техники
Цель проекта	Открытие мастерской по ремонту техники
Номер требований	Источник требований	Описание требований	Класс требований	Дата выполнения	Текущий статус
Т1	Владелец	Качественно сделанный ремонт	Требования к качеству	20.12.20	В процессе
Т2	Владелец	Доставить оборудование	Требования к качеству	С начала диагностики до завершения ремонта	В процессе
Т3	Владелец	Квалифицированные рабочие	Требования к качеству	С начала диагностики до завершения ремонта	В процессе
Т4	Руководитель проекта	Заработная плата	Требования ЗС	20.12.20	В процессе
Т5	Команда проекта	Заработная плата	Требования ЗС	20.12.20	В процессе

Таблица 8. Матрица зависимостей требований.

Требование	Т1	Т2	Т3	Т4	Т5
Т1	Х	Х	Х	Х	Х
Т2		Х	Х	Х	Х
Т3			Х	Х	Х
Т4	Х	Х	Х		Х
Т5	Х	Х	Х	Х

Руководитель проекта выдвинул ряд требований к подбору персонала. Подбор персонала состоит из:

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

• Опыт в ремонтных работах;
• Умение работать с инструментами;
• Организованность;
• Профессиональность;
• Умение работать в команде;
• Честность, порядочность;
• Оперативность.

Вопросы к собеседованию:

• Расскажите немного о себе.
• Какое отношение ваше образование имеет к данной работе?
• Чем вы можете быть полезны для проекта?
• Какого типа работу вы больше всего любите?

Анкета

1. Ф.И.О._______________________________________________________
2. Дополнительная информация
   Дата рождения________________________________________________
   Образование__________________________________________________
   Адрес проживания и телефон____________________________________
   Семейное положение___________________________________________
3. Трудовой опыт________________________________________________
   _____________________________________________________________
   _____________________________________________________________
4. Дополнительные навыки _______________________________________________________________________________________________________________________________________________________________________________________

ЗАКЛЮЧЕНИЕ

Подведем итоги данной курсовой работы. В данной работе была рассмотрена тема «Управления требованиями проекта».

В ходе курсовой работы была изучена и выполнена цель проекта, также были выполнены поставленные задачи:

- была изучена учебная, справочная литература и теоретический материал по управлению проектами;

- было определено что такое управление требованиями проекта;

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

- реализован практический проект.

Данные процессы были изучены на практике на примере проекта «Мастерская». Соответственно, предметом курсовой работы являлись процессы управления требованиями проектом, а объектом исследования является сам проект.

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

Цель проекта – открытие мастерской по ремонту техники. Также составлены критерии успешности:

• успешное завершение проекта;
• уложить в поставленные сроки
• не выйти за рамки установленного бюджета
• попытаться выполнить всё в рамках предоставленных ресурсах.

И описали требования проекта.

Также в теоретической части были рассмотрены жизненный цикл проекта, фазы, организационные структуры. В укрупнённом виде были рассмотрены требования проекта.

Владелец он же заказчик выдвинул ряд своих требований. Требуется:

• качественный ремонт;
• конкурентно способные цены на услуги;
• квалифицированные рабочие;
• современное оборудование.

На основе изученных процессов проекта были построены таблицы:

• реестр требований проекта;
• матрица отслеживания требований проекта;
• матрица зависимостей требований.

Так же в процессе руководитель проекта выдвинул ряд требований к подбору персонала. Подбор персонала состоит из:

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

• Опыт в ремонтных работах;
• Умение работать с инструментами;
• Организованность;
• Профессиональность;
• Умение работать в команде;
• Честность, порядочность;
• Оперативность.

Вопросы к собеседованию:

• Расскажите немного о себе.
• Какое отношение ваше образование имеет к данной работе?
• Чем вы можете быть полезны для проекта?

Была составлена анкета.

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

СПИСОК ЛИТЕРАТУРЫ

1. Локк, Д. Основы управления проектами / Д. Локк. – М.: Гиппо (Hippo), 2016 – 516с.

2. Зуб, А. Т. Управление проектами: учебник и практикум для академического бакалавриата / А. Т. Зуб. – М.: Издательство Юрайт, 2018. – 422 с

3. Руководство к своду знаний по управлению проектами (Руководства PMBOK®): пер. с англ.: [16+]. – 5-е изд. – Москва: Олимп-Бизнес, 2018. – 613 с.

4. Левушкина С. В., Управление проектами: учебное пособие, Ставропольский государственный аграрный университет, 2017, - 204 с.

5. Сироткин Н. А., Кузнецов С. М. Учебно-методическое пособие к выполнению курсового проекта по дисциплине «Организация, планирование и управление строительством», Директ-Медиа, 2018, - 81 с.

6. Бучаев Г. А.,Управление проектами : курс лекций: учебное пособие, Издательство: ДГУНХ, 2017, - 104 с.

7. Орлова, Е.Р. Методическое пособие по курсу «Системный анализ и управление проектами» / Е.Р. Орлов. – М.: Ленанд, 2016. – 516 с.

8. Руководство к Своду знаний по управлению проектами (Руководство PMBOK). Седьмое издание. – 2018. – 586 с.

9. Лившиц В. Н., Виленский П. Л., Смоляк С. А. Оценка эффективности инвестиционных проектов: Теория и практика. Учебное пособие. – 5-е изд., перераб. И доп. – М.: Поли Принт Сервис, 2015. – 1135-1136 с.

10. Управление проектами: учебное пособие, СФУ, 2017, - 132с.

11. Уколов А. И., Оценка рисков: учебник, Издательство: Директ-Медиа, 2018, - - 627 с.

12. Управление человеческими ресурсами: учебник для бакалавриата и магистратуры / Н.Д. Гуськова, И.Н. Краковская, А.В. Ерасова, Д.В. Родин. – 2-е изд., испр. И доп. – М.: Издательство Юрайт, 2018. – 212

13. Руководство к своду знаний по управлению проектами (Руководства PMBOK®): пер. с англ.: [16+] – 5-е изд. – Москва: Олимп-Бизнес, 2018. – 613 с.

14. Балашов А.И., Рогова Е.М., Тихонова М.В., Ткаченко Е.А. Управление проектами: учебник и практикум для академического бакалавриата. М.: Издательство Юрайт, 2015. – 383 с.

15. Лившиц В. Н., Виленский П. Л., Смоляк С. А. Оценка эффективности инвестиционных проектов: Теория и практика. Учебное пособие. – 5-е