Действия

Разработка архитектуры решения

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

Операция: Разделение системы на подсистемы

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

Для создания гибкой архитектуры в MSF применяется создание временного прототипа ( shadowing ). Приложение-прототип ( shadow ) позволяет применить принцип нисходящего проектирования в любой итерации. В начале итерации, когда существует лишь проект, прототип опережает рабочий программный код. В этот период проектные конструкции не синхронизованы с кодом. В рамках прототипа выполняются все изменения архитектуры или дизайна, которые необходимы для предохранения основного кода от превращения его в "дымоход", "спагетти-код" и прочих проблем, связанных с плохим проектированием. По мере реализации элементов начального предваряющего прототипа ( leading shadow ), архитектура все больше соответствует рабочему коду. Те части системы, которые были спроектированы, но не были реализованы, теперь становятся действительными. Когда архитектура соответствует рабочему коду, прототип называется завершающим ( trailing shadow ). Это сумма конструкций из всех предыдущих итераций.

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

Операция: Определение интерфейсов

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

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

Операция: Разработка модели угроз

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

Операция: Разработка модели производительности

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

Операция: Создание архитектурной модели

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

Операция: Создание архитектуры инфраструктуры

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