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

Содержание:

Введение

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

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

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

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

Проекты различаются в зависимости от:

• отрасли экономики и социальной сферы (промышленность, строительство, транспорт, здравоохранение, туризм и т.д.);
• срока реализации, объема необходимых инвестиций (краткосрочные, среднесрочные, долгосрочные);
• степени охвата этапов инновационного процесса (полные инновационные проекты, включающий НИР, ОКР, освоение новшества и его коммерциализацию, неполные инновационные проекты, включающие отдельные этапы инновационного процесса.
• Классификация проектов приведена в таблице 2.

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

ГЛАВА 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. Практический пример Проект «чумная шестерёнка»

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

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

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

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

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

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