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

ВЕДЕНИЕ

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Роли:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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