Что должно быть включено в контрольный список архитектуры приложения?

Question

Я пытаюсь составить контрольный список или набор вопросов / критериев для оценки и оценки предложенных или возникающих архитектур (выполнить архитектурные проверки). Какие наиболее важные вопросы вы задаете при планировании, оценке или анализе архитектуры?

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

Код завершен обеспечивает достойную отправную точку:

Архитектура

• Является ли общая организация программы ясной, включая хорошую обзор архитектуры и обоснование?
• Хорошо ли определены модули, включая их функциональность и их интерфейсы к другим модулям?
• Все ли функции, перечисленные в требованиях, не слишком много или слишком мало модулей?
• Разработана ли архитектура для учета вероятных изменений?
• Включены ли необходимые решения о покупке против сборки?
• Описывает ли архитектура, как повторно используемый код будет соответствовать другие архитектурные задачи?
• Все ли основные структуры данных скрыты за процедурами доступа?
• Оправданы ли организация и содержание базы данных?
• Все ли ключевые алгоритмы описаны и обоснованы?
• Все ли основные объекты описаны и обоснованы?
• Описана ли стратегия обработки пользовательского ввода?
• Описана и обоснована ли стратегия обработки ввода-вывода?
• Определены ли ключевые аспекты пользовательского интерфейса?
• Является ли пользовательский интерфейс модульным, чтобы изменения в нем не влияли на Остальная часть программы?
• Оценки использования памяти и стратегия управления памятью описано и обосновано?
• Устанавливает ли архитектура пространство и скорость для каждого модуля?
• Является ли стратегия обработки описанных строк символьной строкой Смета хранения предоставляется?
• Предоставляется ли согласованная стратегия обработки ошибок?
• Управляются ли сообщения об ошибках как набор для представления чистого пользовательского интерфейса?
• Указан ли уровень надежности?
• Является ли какая-либо часть чрезмерной или недостаточно разработанной? Есть ожидания в эта область изложена явно?
• Четко ли сформулированы основные системные цели?
• Концептуально ли объединяется вся архитектура?
• Является ли дизайн верхнего уровня независимым от машины и язык, который будет использоваться для реализовать это?
• Предоставлены ли мотивы для всех основных решений?
• Вам, как программисту, который будет внедрять систему, удобно архитектура?

Я ищу практические знания с примерами, например, какие были самые болезненные моменты в архитектуре, которую вы создали?

Answer 1

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

Каждый из этих потенциальных кандидатов включает несколько различных категорий. Общая значимость этих категорий будет несколько различаться в зависимости от потребностей бизнеса. ИМХО, все нормально. Гораздо менее затратно задать другой вопрос при прохождении контрольного списка для проверки и исключить его, чем полностью пропустить вопрос или категорию, потому что это не казалось достаточно важным для первоначального включения в контрольный список.

• " Руководство по обзору архитектуры программного обеспечения " Александра Новака
• " Проверка контрольного списка для документа архитектурного проектирования [s] " Тома Верхоффа
• " Контрольный список: обзор архитектуры и дизайна " из Центра разработки и практики Майкрософт
• " Контрольный список концептуальной архитектуры " Крейга Борисовича
• " Руководство по Arch App 2.0 База знаний: Контрольный список - Архитектура и дизайн ", автор J.D. Meier, Alex Homer, et al. (найдено по ссылке Питера Стуера)
• " Контрольные списки проверки соответствия архитектуры TOGAF " из открытой группы
• " Процесс обзора архитектуры " Рики Хо

Похоже, что на эту тему написан официальный документ, хотя я его не читал. Он пытается ответить на этот вопрос в течение примерно 11 страниц.

• Обзоры архитектуры: практика и опыт Маранцано, Розсыпал и др.

Кроме того, коллега порекомендовал набор книг из Springer, хотя я сам не проверял ни одного из них:

• Серия Enterprise Engineering от Springer

Answer 2

Некоторые другие моменты для рассмотрения:

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

Две хорошие книги для большего количества идей:

• Архитектура систем программного обеспечения , Ник Розански и Эоин Вудс
• Архитектура программного обеспечения на практике , Лен Басс, Пол Клементс и Рик Казман

Answer 3

Соответствует ли архитектура рекомендациям и планам поставщиков технологий?

Вы хотите получить поддержку от выбранной вами платформы, а не бороться с ней.

например. Для решений, ориентированных на Microsoft, это означает документирование того, где и почему ваш выбор отклоняется от руководства Microsoft Architecture .

Answer 4

Использует ли он твердые принципы?

Answer 5

Как вы собираетесь это проверить

Answer 6

Есть ли один человек, который может быть ответственным за архитектуру с достаточным количеством (1) технические знания предлагаемой архитектуры, (2) опыт управления вещами, (3) стоять в компании, чтобы его решения не могли быть отменены руководством, которое ничего не знает.

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

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

Позже мысли

Я немного подумал о том, какие именно вопросы вы можете задать себе после написания спецификации, например, «Легко ли обновить ваш проект», «Позволяет ли это гибкость в конечных целях», «Будет ли это упростить поддержку »,« Есть ли проблемы с безопасностью »и т. д., но хотя и стоит задавать подобные вопросы, я просто не вижу, как их можно использовать для любой« оценки », потому что кроме фильтрации Из явных ошибок я не думаю, что какой-либо специфический вопрос сильно помог бы в «оценке архитектуры». Возможно, ваш вопрос выиграет от перефразирования?