Материал: Организация управления требованиями

программный управление требование

Процесс «Управление изменениями»

Показатели процесса «Управление изменениями» описаны в таблицах 19-24.

Таблица 19

Описание показателя F1

Таблица 20

Описание показателя F2

Таблица 21

Описание показателя F3

Таблица 22

Описание показателя F4

Таблица 23

Описание показателя F5

Таблица 24

Описание показателя F6

Разработанные показатели эффективности процессов представлены на рисунке ниже.

Рисунок 12 - Показатели эффективности процессов управления требованиями

2. Оценка текущих процессов в компании и разработка рекомендаций

2.1 Оценка процессов управления требованиями в реализованных проектах компании

Проект P1 - Автоматизация социальной защиты. ГБУ «Кризисный центр помощи женщинам и детям»

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

·  Автоматизация основных бизнес-процессов;

·        Ведение электронного документооборота;

·        Система ключевых показателей работы Центра в реальном времени;

·        Формирование расписания всех мероприятий клиентов и специалистов Центра;

·        Учет оказанных услуг;

·        Управление отношениями с клиентами.

Оценка процессов управления требованиями в проекте представлена в Приложении 7.

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

Исходя из показателей, много времени было потрачено на сбор требований, что в основном связано с плохой доступностью заинтересованных сторон для сбора у них требований (значение показателя превышает критический уровень). Но и количество и качество в итоге собранных требований оказалось недостаточным - покрытие предметной области всего на 70%. Качество сбора требований отразилось и на других показателях - большое количество новых выявленных требований и требований подлежащих корректировке на этапе анализа, измененных требований на этапе проектирования системы и значительное количество новых выявленных требований впоследствии.

В итоге стоимость принятых изменений оказалась экономически невыгодной. Имеются неудовлетворительные значения показателей «F5. Количество требований, потерявших актуальность» и «F6. Процент нереализованных требований».

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

Проект P2 - Автоматизация ООО Частное охранное предприятие «Русский Витязь»

Разработанная система позволяет:

·  Вести учет сотрудников охранного предприятия, охраняемых объектов;

·        Проводить инспекцию сотрудников и объектов;

·        Включает наглядную систему показателей эффективности работы сотрудников.

Оценка процессов управления требованиями в проекте представлена в Приложении 8.

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

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

Проект P3 - Автоматизация ООО «СПОРТФИШ ТУР»

Разработанная система управления клиентами позволяет не только эффективно взаимодействовать с клиентами:

·  Учет бронирования туров;

·        Автоматическое формирование пакета документов для оформления заказа;

·        Учет оплат и предоплат, отслеживание неоплаченных заказов;

·        Интеграция с сайтом.

Оценка процессов управления требованиями в проекте представлена в Приложении 9.

В ходе данного проекта значительная часть времени была потрачена на сбор требований, что в основном было обусловлено несогласованностью заинтересованных сторон в отношении требований к будущей системе. Эта несогласованность прослеживалась на всем этапе реализации проекта, что можно увидеть из значений показателей «E1. Количество замечаний, поступивших от Заказчика», «F1. Количество несогласованных требований», «F3. Количество новых выявленных требований», «F4. Стоимость выявленных изменений», «F5. Количество требований, потерявших актуальность».

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

Проект P4 - Автоматизация Российских студенческих отрядов

Российские студенческие отряды, организация с более 200 тыс. членов. Для достижения целей развития организации было предложено специальное решение:

·  Создание единой информационной среды;

·        Управление работой с партнерами и заказчиками;

·        Координация работы подразделений;

·        Создание единого реестра бойцов;

·        Управление проектами и задачами;

·        Ведение электронного документооборота.

Оценка процессов управления требованиями в проекте представлена в Приложении 10.

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

Проект Р5 - Автоматизация открытых R&D центров - ФРИП ТПП

Было разработано приложение на базе комплекса «Простой бизнес» с возможностями социальной сети, которое позволяет:

·  Выявить потребности крупного бизнеса в области инновационного развития;

·        Управлять системой открытых R&D центров с целью применения научно-технического потенциала инновационных предприятий, ВУЗов и НИИ вне зависимости от их географического положения;

·        Наладить диалог между крупным и малым бизнесом.

Оценка процессов управления требованиями в проекте представлена в Приложении 11.

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

2.2 Рекомендации по повышению качества процессов управления требованиями в компании

На рисунке ниже представлена общая ситуация по процессам по итогам оценок пяти проектов.

Рисунок 13 - Общая оценка процессов управления требованиями в компании

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

В связи с этим, для повышения качества данных процессов рекомендуется провести изменения, основанные на методологии RUP.

Для процесса «Управление изменениями» предлагается следующий алгоритм управления запросами на изменения [35], который представлен на рисунке ниже в виде диаграммы действий.

Рисунок 14 - Диаграмма действий для запроса на изменение

В Приложении 12 представлено описание задач и роли процесса управления запросами на изменения.

В компании не существует единой формы запроса на внесение изменений, поэтому предлагается использовать форму, представленную в методике RUP (Приложение 13).

Для сбора требований в компании преимущественно используется метод интервьюирования. Рекомендуется в дополнение применение метода анализа вариантов использования [36].

Предлагаемый вариант изменений в процессе сбора требований представлен в виде диаграммы действий на рисунке 15.

Рисунок 15 - Ход процесса сбора требований

Описание задач процесса сбора требований и ролей представлено в Приложении 15.

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

В компании недостаточно эффективно отлажены процессы тестирования. В связи с этим предлагается использовать активности/задачи, связанные с тестированием, предложенные в методике RUP [37]. В целом процесс тестирования представлен на рисунке ниже.

Рисунок 16 - Процесс тестирования

Описание задач и ролей процесса тестирования представлено в Приложении 15.

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