Что такое хороший метод для оценки облегченной архитектуры?

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

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

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

У кого-нибудь есть опыт выполнения облегченной предварительной оценки архитектуры? Если да, то каковы хорошие практики?

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

Могу порекомендовать две книги, в которых рассматриваются эти два (несколько связанных) подхода.

Архитектурное ПО Intensive Systems от Энтони Латтанце представляет методологию проектирования, ориентированную на архитектуру, и рассматривает упрощенные оценки на основе сценариев. Вы можете узнать Латтанце на семинаре по атрибутам качества SEI, и в этом есть схожие идеи.

Достаточно архитектуры программного обеспечения: подход, основанный на оценке риска, Джорджа Фэрбенкса представляет собой подход, основанный на оценке риска, для проектирования и оценки архитектуры программной системы. На его сайте также есть несколько бесплатных глав, если вы хотите превью. Несмотря на то, что принципы, изложенные в этой книге, применимы сразу, этот подход не связан с конкретным методом, поэтому вам нужно будет объединить идеи из других областей. Я настоятельно рекомендую непрерывный подход к управлению рисками в SEI для определения / определения приоритетов рисков.

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

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

Прежде чем ты начнешь:

• Приоритетные сценарии качества или риски (могут быть неформальными, если это все, что у вас есть)
• Четкое определение для принятия решения «пойти / не пойти» (откуда вы знаете, что архитектура «достаточно хороша»)
• Самый последний фрагмент описания архитектуры (артефакт, который вы оцениваете)

Сядьте на сеанс оценки:

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

После окончания сеанса:

• Просмотрите выявленные проблемы и определите, соблюдаются ли критерии go / no-go. Обычно требуется около 3 отзывов, чтобы все получилось. Если не выполнено, продолжайте совершенствовать и экспериментировать (или уменьшать архитектурные риски).
• Это не оценка «все или ничего» - различные части вашей архитектуры могут «пройти», в то время как другие все еще нуждаются в уточнении.

Чтобы дать вам представление о том, на что может быть похож подход, основанный на сценариях, есть некоторая публичная документация проекта capstone, над которым я работал в аспирантуре. Документация немного грубовата, но она может помочь привести некоторые примеры сценарного подхода в контексте ACDM. Мы были командой из 5 человек и создали типичное веб-приложение, около 35 KLOC Java / GWT.

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

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