Справочная таблица: Документ архитектуры программного обеспечения

Общие

В целом архитектура системы выглядит хорошо по следующим причинам:

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

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

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

Хорошим индикатором может служить прошлый опыт работы с архитектурой: если в архитектуру вносится мало изменений даже при реализации новых функций, можно считать, что она стабилизируется. Если же реализация каждого нового сценария требует изменения архитектуры, такая архитектура все еще находится в фазе развития, и ее рано считать стабилизировавшейся.
Сложность системы соответствует набору задач, которые она выполняет.
Сложность характеризуется с учетом навыков и опыта заинтересованных лиц, в число которых входят:
- пользователи
- операторы
- разработчики
У системы единая связная архитектура
Рационально подобраны количество и типы компонентов
В системе предусмотрена целостная инфраструктура защиты. Компоненты инфраструктуры защиты обеспечивают слаженную защиту системы.
Система отвечает требованиям к коэффициенту готовности.
В архитектуре предусмотрена возможность оперативного восстановления системы в случае выхода из строя.
Продукты и технологии, на которых основана система, соответствуют предполагаемому жизненному циклу системы.
- Временные системы с ограниченным жизненным циклом, предназначенные для решения локальных (тактически) задач, можно строить на основе старых технологий, поскольку эти системы в любом случае недолговечны.
- Системы с длительным жизненным циклом (к этой категории относится большинство систем) следует строить на основе современных технологий и методов, чтобы обеспечить максимальное удобство обслуживания и расширения таких систем в будущем.
В архитектуре четко прописаны интерфейсы, что позволяет максимально распараллелить разработку программного обеспечения.
Архитектура содержит достаточно информации для того, чтобы проектировщики могли проектировать и разрабатывать элементы модели.
Применение принципа пакетов сокращает сложность системы и делает ее более понятной.
Внутренняя структура пакетов связна, при этом сами пакеты в минимальной степени зависят друг от друга.
Были рассмотрены аналогичные решения из числа массовых систем.
Предложенное решение доступно для понимания лицам с базовой подготовкой в предметной области.
Все члены коллектива сходятся в своем видении архитектуры, представленной разработчиком архитектуры.
Документ архитектуры программного обеспечения отражает текущее состояние архитектуры.
Выполнены рекомендации по проектированию.
Все технические риски устранены или учтены в плане на случай возникновения непредвиденных обстоятельств. Проанализировано и задокументировано вероятное влияние новых рисков.
Решение удовлетворяет основным требованиям к производительности (установленным бюджетам).
Выбраны конфигурации тестирования, средства тестирования и тестовые наборы.
Архитектура не производит впечатления чрезмерной.
- Выбранные механизмы достаточно просты в использовании.
- Количество механизмов невелико и соответствует требованиям предметной области и масштабу системы.
Все реализации прецедентов, включенные в текущую итерацию, выполнимы в рамках архитектуры, что показано на диаграммах, иллюстрирующих следующие обстоятельства:
- Взаимосвязь между объектами
- Взаимосвязь между задачами и процессами
- Взаимосвязь между физическими узлами

Модели

Общие характеристики модели

Подробность модели соответствует установленным в ней целям.

На этапе уточнения в бизнес-модели, модели требований или модели проекта нет избыточной информации о деталях реализации.

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

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

Концепции смоделированы максимально просто.

Модель удобна в развитии; реализация ожидаемых изменений не составит труда.

Понятность и простота структуры не принесены в жертву простоте внесения потенциальных изменений.

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

Диаграммы

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

Документация

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

Исправление ошибок

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

Внедрение и установка

Разработана и протестирована процедура модернизации существующей системы без потери данных и функциональных возможностей.
Разработан и протестирован процесс импорта данных из прошлых версий.
Продолжительность модернизации или установки системы прогнозируема и задокументирована.
Систему можно вводить в строй на уровне отдельных вариантов.

Администрирование

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

Производительность

Требования к производительности адекватны и соответствуют текущему уровню развития предметной области; эти требования рациональны.

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

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

Использование памяти

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

Стоимость и график выпуска

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

Переносимость

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

Надежность

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

Безопасность

Выполнены требования к безопасности.

Организационные вопросы

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

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

Раздел представления прецедентов в документе архитектуры программного обеспечения:

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

Логическое представление

Раздел логического представления в документе архитектуры программного обеспечения:

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

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

Использование ресурсов

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

Производительность

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

Отказоустойчивость

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

Модульность

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

Представление развертывания

Требования к производительности удовлетворены путем распределения нагрузки между различными узлами; предусмотрены меры предотвращения возникновения узких мест.
Если информация распределена по нескольким узлам или реплицирована на нескольких узлах, предусмотрены средства обеспечения целостности данных.
Выполнены требования к надежности применяемых средств передачи сообщений.
Выполнены требования к защищенности применяемых средств передачи сообщений.
Нагрузка распределяется между узлами таким образом, чтобы минимизировать нагрузку на сеть и время ответа, при этом учтены вопросы целостности и наличия ограниченного количества ресурсов.
Выполнены требования к коэффициенту готовности системы.
- Определена максимальная допустимая продолжительность простоя системы при выходе сервера или сети из строя, и эта продолжительность допустима в рамках требований, предъявляемых к системе.
- Резервные и запасные серверы настроены таким образом, что ни при каких обстоятельствах роль основного сервера не может быть назначена нескольким серверам одновременно.
Задокументированы все потенциальные режимы сбоев.
Предусмотрены средства локализации, диагностики и устранения сетевых неполадок.
Установлена величина резерва процессорных мощностей при работе системы и разработан метод определения этой величины.
Предусмотрена стратегия действий на случай превышения предельной нагрузки на процессор.

Рекомендации по анализу архитектуры

Общая информация

Подсистемы

Классы

Общие характеристики модели

Использование ресурсов

Производительность

Отказоустойчивость

Модульность