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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Дата добавления: 2015-04-25