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

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

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

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

Рис. 5.2.

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

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

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

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