Что должно быть включено в контрольный список Application Architecture?

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

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

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

Архитектура

  • Является ли полная организация программы понятной, в том числе хорошей архитектурный обзор и обоснование?
  • Являются ли модули определенными, включая их функциональность и их интерфейсы к другим модулям?
  • Все функции, перечисленные в требованиях, не слишком много или слишком мало модулей?
  • Является ли архитектура предназначена для размещения вероятных изменений?
  • Необходимы ли решения о покупке-vs.-build?
  • Описывает ли архитектура, как будет использоваться повторно используемый код для соответствия другие архитектурные цели?
  • Все ли основные структуры данных скрыты за процедурами доступа?
  • Является ли организация и содержание базы данных обоснованной?
  • Все ли ключевые алгоритмы описаны и обоснованы?
  • Все основные объекты описаны и обоснованы?
  • Описана ли стратегия обработки пользовательского ввода?
  • Является ли стратегия обработки I/O описанной и обоснованной?
  • Определены ли ключевые аспекты пользовательского интерфейса?
  • Является ли интерфейс пользователя модульным, чтобы изменения в нем не повлияли на остальная часть программы?
  • Имеются оценки использования памяти и стратегия управления памятью описаны и обоснованы?
  • Описывает ли архитектура пространство и бюджет скорости для каждого модуля?
  • Является стратегией обработки описанных строк и является символьной строкой оценки хранения?
  • Предоставляется ли согласованная стратегия обработки ошибок?
  • Являются ли сообщения об ошибках управляемыми как набор для представления чистого пользовательского интерфейса?
  • Определен ли уровень надежности?
  • Является ли какая-либо часть чрезмерной или недокритичной? Ожидаются ли эта область явно указана?
  • Четко ли сформулированы основные системные цели?
  • Концепция концептуально висит вместе в целом архитектуре?
  • Является ли дизайн верхнего уровня независимым от машины и язык, который будет использоваться для реализовать его?
  • Могут ли быть мотивы для всех основных решений?
  • Вы, как программист, который будет внедрять систему, архитектура?

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

Ответы

Ответ 1

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

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

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

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

Ответ 2

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

Ответ 3

Некоторые другие моменты, которые следует учитывать:

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

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

Ответ 4

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

Ответ 5

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

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

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

Ответ 6

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

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

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

Позже мысли

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