Контекст задачи анализа требований

Методологии бизнес-анализа

Методологии бизнес анализа можно разделить на три категории по типам моделей:

• модели, преследующие цель анализа и улучшения организационной системы (например, SWOT , VCM, BPR, CPI/TQM/ISO9000, BSC),
• модели общего назначения, такие, как SADT, DFD, IDEF1, IDEF3, IDEF5 и другие,
• модели, специально разработанные для использования при автоматизации (например, ISA, BSP, ARIS, RUP).

Наиболее развитая модель описания проблемной области предлагается в методологии ARIS.

Архитектура ARIS [5.5] выделяет в организации следующие подсистемы.

• Организационная. Определяет структуру организации - иерархию подразделений, должностей и конкретных лиц, многообразие связей между ними, а также территориальную привязку структурных подразделений.
• Функциональная. Определяет функции, выполняемые в организации.
• Подсистемы входов/выходов. Определяют потоки используемых и производимых продуктов и услуг.
• Информационная (подсистема данных). Описывает получение, распространение и доступ к информации (данным).
• Подсистема процессов управления. Определяет логическую последовательность выполнения функций посредством событий и сообщений. Можно сказать, что подсистема управления - это совокупность разнесенных во времени сообщений разного рода.
• Подсистема целей организации. Описывает иерархию целей, достигаемых в ходе выполнения того или иного процесса.
• Подсистема средств производства. Описывает жизненный цикл основных и вспомогательных средств производства.
• Подсистема человеческих ресурсов. Описывает прием на работу, обучение и продвижение по службе персонала организации.
• Подсистема расположения организационных структур. Описывает территориальное расположение организационных единиц.

Данное разделение является в определенной мере условным; выделенные "подсистемы" не являются подсистемами в смысле системного анализа, т.к. взаимопроникают и пересекаются. Они представляют скорее совокупность предметов исследования, разных взглядов на исследуемый объект.

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

Требования и архитектура АИС

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

Метафора архитектуры RUP описывается в виде 4+1 представлений: логическое, представление процессов, представление реализации и физическое представление связываются между собой представлением вариантов использования (Use case), которое играет центральную роль в выработке архитектуры системы (рис. 5.2).

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

Рис. 5.2.

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

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

Это - нормальный, естественный путь развития требований и архитектуры. Но что делать, если требования изменились настолько, что архитектура перестала им соответствовать? Причины тому могут быть разные, например: неопытная архитектурная группа не проявила достаточно дальновидности; группа по сбору требований пропустила на ранних стадиях критичные, архитектурно значимые требования; в бизнес-сфере Заказчика произошли большие перемены, вызвавшие коренное изменение требований к системе. Следствия также могут быть различными: договоренность об увеличении сроков и сумм по контракту; исправление ситуации за счет Разработчика; разрыв контракта.

Альтернативный выход предлагается в методологии XP: архитектура - не догма, а всего лишь метафора. Если требования вошли вразрез с существующей архитектурой - значит, архитектуру нужно просто изменить. Следует понимать, что путь и рецепты XP при кажущейся простоте ориентированы далеко не на любой коллектив. Команда XP состоит из профессионалов, имеющих позитивный опыт работы в этой методологии.

Анализ требований и другие рабочие потоки программной инженерии

Рассмотрим краткий обзор рабочих потоков RUP и их связь с потоком работ АТ (рис. 5.3).

Рис. 5.3.

Поток работ "деловое моделирование" служит основой для анализа и формирования требований к АИС, позволяет избежать ошибок.

Поток работ "управление средой" предоставляет исходную информацию для рабочей группы АТ, регламентирующую форматы оформления, CASE-средства, регламенты работы.

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

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

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

Для потока работ "реализация" связь с требованиями не указана. Между тем автор считает, что требования должны анализироваться и учитываться во ВСЕХ рабочих потоках проекта, даже если это формально не предусмотрено выбранным группой процессом. Людям свойственно ошибаться и ошибки, совершенные на ранних стадиях проекта, при движении от этапа к этапу нарастают, как снежный ком. Поэтому любому участнику команды, заинтересованному в успехе проекта, нелишне заглянуть в спецификацию требований и убедиться в том, что та работа, которая ему поручена, соответствует тому или иному требованию. Это позволяет организовать обратную связь, позволяющую отследить ошибки в спецификациях. Многие проекты зашли в тупик именно из-за оторванности группы, отвечающей за реализацию от группы сбора и анализа требований.