2. Программный процесс и архитектурно-экономический цикл

Программным процессом (software process) называются действия по организации, нормированию и управлению разработкой программного обеспечения. Ниже приведён перечень операций направленных на создание программной архитектуры, ее применение для реализации проектного решения, а впоследствии — на реализацию или управление развитием целевой системы или приложения:

• создание экономической модели системы;

• выявление требований;

• создание новой или выбор существующей архитектуры;

• документирование и распространение сведений об архитектуре;

• анализ или оценка архитектуры;

• реализация системы на основе архитектуры;

• проверка соответствия реализации архитектуре.

1. Этапы разработки архитектуры

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

Создание экономической модели системы

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

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

Выявление требований

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

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

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

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