Если смотреть издалека, то процесс оценки архитектуры программного обеспечения не значительно отличается от других процессов оценки и проверки.

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

Кроме того, важное значение имеет выбор конкретного этапа жизненного цикла для выполнения оценки.

1. Концу начального этапа, как правило, соответствует цикл начальной разработки архитектуры, когда о ней известны преимущественно общие сведения. Тем не менее, проверка может выявить невыполнимые требования, отсутствующие компоненты, пропущенные возможности повторного использования существующих продуктов и т.д.
2. Оптимальное время для оценки архитектуры программного обеспечения - конец этапа уточнения. На этом этапе основное внимание уделяется уточнению требованию и созданию контрольной версии архитектуры. На этой вехе RUP требует обязательной проверки архитектуры. Как правило, оценивается широкий перечень показателей архитектуры.
3. Более подробная оценка может потребоваться в ходе этапа построения (для проверки конкретных показателей, таких как производительность и безопасность), а также в конце этого этапа (для проверки оставшихся неполадок, делающих продукт неприемлемым для передачи пользователям).
4. Восстановительные оценки могут выполняться на этапах построения и даже внедрения, если в ходе проекта возникли серьезные затруднения: построение не удалось завершить или уровень неполадок установленной версии в ходе внедрения неприемлем.
5. И наконец, оценку можно выполнить в конце этапа внедрения, в частности с целью инвентаризации многоразовых ресурсов, подходящих для нового продукта или цикла разработки.

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

Проверку можно выполнить различными подходами:

• на основе представления
• на основе данных
• на основе сценария

Проверка на основе представления

Получите (или создайте) представление архитектуры, затем в соответствии с этим представлением поставьте вопросы и примите решения.

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

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

Проверка на основе данных

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

Проверка на основе сценариев

Данный подход представляет собой причинно-следственный анализ. Интересующие вас вопросы следует преобразовать в набор сценариев, через которые должна пройти система. Затем эти вопросы следует задать на основе сценариев. Примеры сценариев:

• Система выполняется на платформах X и Y. (Проверяется показатель переносимости.)
• Система поддерживает дополнительную функцию F. (Проверяется показатель расширяемости.)
• Система обрабатывает 200 запросов в час. (Проверяется показатель масштабируемости.)
• Система устанавливается пользователем в конкретной среде. (Проверяется показатель завершенности или удобства работы.)

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

На практике четкое разграничение между описанными подходами отсутствует и применяется их сочетание.

Определение неполадок

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

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

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

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

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