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

o Инициируются действующим лицом;

o   Представляют собой взаимодействие между пользователем и системой;

o   Определяют последовательность действий;

o   Содержат в себе функциональные требования;

o   Имеют некоторое значение для действующего лица;

o   Представляют собой имеющий смысл сценарий событий.

Рисунок 3 - Модель процессов управления требованиями в RUP. Источник - Филипп Крачтен «Введение в Rational Unified Process»

·  Дополнительная спецификация. Содержит описание нефункциональных требований (удобство работы, надежность, производительность и др.), а также некоторые функциональные требования.

·        Создание тестовых сценариев (Test Cases) из сценариев использования (Use Case). Тестовые сценарии показывают тестеровщикам шаги работы в системе для проверки требований.

·        Создание тестовых сценариев (Test Cases) из дополнительной спецификации;

·        Проектирование системы. Основой процесса являются требования. Проектирование зачастую сопровождается применением Универсального Языка Моделирования - Unified Model Language (UML) [14, 15].

На рисунке 3 можно ознакомиться с моделью управления требованиями согласно RUP.

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

В библиотеке ITIL (IT <https://ru.wikipedia.org/wiki/%D0%98%D0%BD%D1%84%D0%BE%D1%80%D0%BC%D0%B0%D1%86%D0%B8%D0%BE%D0%BD%D0%BD%D1%8B%D0%B5_%D1%82%D0%B5%D1%85%D0%BD%D0%BE%D0%BB%D0%BE%D0%B3%D0%B8%D0%B8> Infrastructure Library) работа с требованиями представлена в рамках двух процессов: Проектирование услуг (Service Design) и Преобразование услуг (Service Transition) [16]. В первом процессе описана классификация требований и инструменты для их выявления.

Управление изменениями требований представлено в одноименном процессе Управление изменениями (Change Management) и включает в себя следующие шаги [10]:

·  Формирование запроса на изменение;

·        Рассмотрение запросов и предложений на изменения;

·        Анализ и оценка влияния изменений на сервис и активы.

·        Авторизация изменений:

o Получение разрешения/отказа на реализацию изменения;

o   Оповещение заинтересованных сторон.

·  Обновление планов;

·        Управление выполнения изменений;

·        Рассмотрение и закрытие изменений:

o Рассмотрение изменений и внесение правок в документацию;

o   Закрытие документации.

С моделью процесса управления изменениями можно ознакомиться на рисунке 4.

Рисунок 4 - Модель управления изменениями в ITIL. Источник «ITIL Version 3.0. Service Transition»

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

Свод лучших знаний BABOK (Business Analysis Body Of Knowledge) раскрывает вопрос управления требованиями в главе «Управление требованиями и коммуникации». Ниже представлен перечень основных этапов работы с требованиями [17].

·  Управление границами решения и их требованиями (Manage Solution Scope&Requirements). Данная задача состоит из обеспечения утверждения требований всех заинтересованных сторон, управления анализом требований. Задача включает в себя:

o Управление рамками решений (Solution Scope Management);

o   Управление конфликтами (Conflict and Issue Management);

o   Представление требований для обзора (Presenting Requirements For Review);

o   Утверждение (Approval).

·  Управление прослеживаемостью требований (Manage Requirements Traceability). Целью является создание и поддержка отношений между бизнес-целями, требованиями и компонентами. Задача состоит из следующих шагов:

o Определение отношений (Relationships) между требованиями;

o   Анализ влияния (Impact Analysis) изменения;

o   Система управления конфигурацией (Configuration Management System).

·  Поддержка требований для повторного использования (Maintain Requirements for Re-use) - управление знаниями о требованиях после их выполнения. Шаги задачи:

o Текущие требования (Ongoing Requirements) - требования, которые могут быть использованы на постоянной основе: договорные обязательства, соглашения об уровне обслуживания, бизнес-правила, бизнес-процессы, стандарты качества;

o   Удовлетворенные требования (Satisfied Requirements).

·  Подготовка пакета требований (Prepare Requirements Package). Цель данной задачи − выбор и структурирование требований в набор так, чтобы обеспечить эффективные коммуникации, понимание и применение требований всеми заинтересованными сторонами проекта. Шаги задачи:

o Рабочие проекты и результаты (Work Products and Deliverables);

o   Формат (Format). В зависимости от типа требований может меняться формат их представления.

·  Коммуникация требований (Communicate Requirements). Цель - общее понимание требований всеми заинтересованными участниками. Включает в себя беседы, дискуссии, заметки, документы, презентации.

o Общие коммуникации (General Communication);

o   Презентации (Presentations).

В целом процесс управления требований представлен на рисунке 5.

Рисунок 5 - Процесс управления требованиями по BABOK. Источник «A Guide to the Business Analysis Body Of Knowledge. Version 2.0»

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

SWEBOK (Guide to the Software Engineering Body of Knowledge) выделяет в работе с требованиями следующие этапы:

·  Выявление требований (Requirements Elicitation);

·        Анализ требований (Requirements Analysis) - включает в себя выявление и разрешение конфликтов между требованиями, определение границ программного продукта, разработку системных требований. Этап состоит из следующих задач:

o Классификация требований (Requirements Classification);

o   Концептуальное моделирование (Conceptual Modeling) - выполняется для понимания сути проблемы;

o   Архитектурное проектирование и распределение требований (Architectural Design and Requirements Allocation);

o   Согласование требований (Requirements Negotiation).

·  Спецификация требований (Requirements Specification) - документы, полученные в результате сбора и анализа требований, их моделирования и архитектурного проектирования. Чаще всего используются следующие виды спецификации:

o Определение системы (System Definition) - формируется документ, который описывает системные требования, определяет высокоуровневые требования и стратегические цели программного продукта;

o   Системные требования (System Requirements) - документ-спецификация описывает действия системных инженеров;

o Программные требования (Software Requirements) -определяются соглашения между Заказчиком и исполнителем в отношении того, что должна делать система.

·  Проверка требований (Requirements Validation) [18, 19].

Описанный процесс представлен на рисунке 6.

Рисунок 6 - Работа с требованиями по SWEBOK

В главе «Конфигурационное управление» (Software Configuration Management) SWEBOK рассматриваются вопросы управления изменениями. Описание включает в себя, какие именно изменения должны быть сделаны, какие полномочия необходимы для утверждения изменений, в чем состоит поддержка реализации этих изменений. К данному процессу относятся такие этапы, как [20]:

·  Предложение, оценка и утверждение изменений (Requesting, Evaluating, and Approving Software Changes). Включает формальные процедуры по предложению и регистрации запросов на изменения, оценки стоимости и влияния предлагаемых изменений, а также утверждение или отказ от внесенных предложений по изменениям.

·        Реализация изменений (Implementing Software Changes).

·        Отклонения и отказ от изменений (Deviations and Waivers). Отклонение - утверждение изменений с некоторой корректировкой условий и работ.

Описанный процесс представлен на рисунке 7.

Рисунок 7 - Процесс управления изменениями по SWEBOK

1.7 Особенности разработки заказного программного обеспечения

Заказные разработки на текущий момент являются неотъемлемой составляющей современного ИТ-рынка и применяются в самых разнообразных отраслях экономики. Создание программного обеспечения на заказ учитывает характерные особенности бизнес-процессов Заказчика. В большинстве случаев к услугам создания заказного программного обеспечения обращаются в таких ситуациях:

·  Для решения поставленной задачи не существует тиражируемого программного обеспечения;

·        Тиражируемое программное обеспечение существует, но оно не удовлетворяет в полной мере всем требованиям Заказчика;

·        Слишком дорогая лицензия на существующее тиражируемое программное обеспечение [22, 23].

Чаще всего разработка на заказ и внедрение программного продукта используется при решении таких задач [24, 25]:

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

·        Адаптация существующих систем к новым нестандартным требованиям Заказчика;

·        Интеграция существующих информационных систем;

·        Усовершенствование существующих систем: расширение функциональности, создание мобильного приложения или веб-интерфейса и т.д.;

·        Интеграция с информационными системами предприятий-партнеров;

·        Интеграция данных из территориально распределенных подразделений компании.

Для удачного завершения проектов заказного программного обеспечения выделяют факторы [22, 24, 25, 26]:

·  Четкая ориентация на бизнес-цели Заказчика;

·        Активное участие всех заинтересованных сторон;

·        Постоянная коммуникация между заинтересованными сторонами;

·        Детальная проработка требований на ранних этапах проекта;

·        Готовность к изменениям требований на всех этапах проекта, в том числе и на поздних;

·        Многократная поставка результатов;

·        Тестирование выполняется непрерывно;

·        Во главу ставится соответствие готового решения бизнес-требованиям;

·        Гибкость к модификациям и масштабируемость системы под требования растущего бизнеса.

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

1.8 Критерии сравнения методик

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

При реализации заказного программного обеспечения важную роль играют детально проработанные на ранних этапах требования, в связи с чем следует выбирать методику, в которой изложен пошаговый процесс идентификации, детализации, оценки требований, инструменты сбора требований, указаны роли и их функции в данном процессе. Значительное место занимает раннее предоставление результатов, поэтому приветствуются методики, которые используют методы прототипирования. Заказная разработка программного обеспечения подразумевает изменение требований Заказчика вплоть до поздних этапов проекта, поэтому важно наличие в методике детального определения этапов выявления, анализа, утверждения или отклонения изменений. Следует обратить внимание на методики, определяющие этап проверки, тестирования требований, формирования критериев оценки выполнения требования [22, 25, 26].

Исходя из представленных особенностей заказной разработки ПО совместно с группой экспертов были выделены следующие критерии для сравнения перечисленных выше методик:

·  Инструменты и техники выявления требований;

·        Описание потребных характеристик требований;

·        Выделение и спецификация ролей;

·        Инструменты демонстрации результатов на ранних этапов;

·        Формализация этапа анализа требований;

·        Наличие алгоритма внесения изменений в требования;

·        Наличие методики проверки/тестирования требований.

·        Ориентация на заказную разработку;

·        Степень полезности (определяет, насколько методика полезна в понимании и создании эффективной модели управления требованиями);

·        Соответствие этапов методики этапам проекта;

·        Нейтральность по отношению к масштабам проекта;

·        Степень формализма (наличие документов, представленных в методике. Данный критерий выделен, т.к. формализм в данном случае оказывает влияние на скорость и трудоемкость выполнения разработки).

1.9 Выбор методики для проектов заказной разработки программного обеспечения

На основе сформированных критериев выполним сравнение методик с помощью метода анализа иерархий (метод Саати). Критерии сравнения и альтернативы выбора представляются в виде иерархии, которая представлена в Приложении 1.

Для определения весов критериев и оценки методик по каждому критерию применяется метод попарного сравнения [27]. Для регистрации результата сравнения пары использовалась шкала, представленная в таблице 1.

Таблица 1

Шкала сравнения пары альтернатив

Результаты парных сравнений заносятся в матрицу. Для каждой матрицы определяется вектор приоритетов. Для определения весов использовался следующий способ: из произведения n элементов каждой строки извлекаем корень n-й степени и нормализуем полученные значения [28, 29].

Исходя из сформированной иерархии выполняется попарное сравнение всех методик по каждому из критерию, определяется вес критериев и выполняется линейная свертка.

Также проводим расчет показателей согласованности. Отклонение от согласованности называют индексом согласованности (ИС), которое рассчитывается по следующей формуле:

Главное значение матрицы -  определяем следующим образом: суммируем произведения векторов приоритетов на суммы элементов каждого столбца. Далее определяем отношение согласованности как