Существует множество вариантов или методик описания и проектирования архитектур, например, как стандарт IEEE 1471 или инициатива The Open Group под названием TOGAF, вы вправе выбирать наиболее понятную или подходящую к конкретной ситуации. В этом посте я хочу немного рассказать о довольно старой и хорошо известной модели или фреймовке Захмана (Zahman).

Раннее я приводил методику описания архитектуры по стандарту IEEE-1471, которая неплохо позволяет формализовать подход к описанию и определяет перечень артефактов, необходимых для проектирования архитектуры различных программных решений. В этом посте я хочу описать еще одну методику, а точнее framework, предназначенный для описания архитектуры приложений уровня предприятия: TOGAF

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

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

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

В предыдущем посте "Описание архитектуры приложения" я приводил вариант описания архитектуры приложения, а теперь хочу дать чуть более подробное описание методики составления архитектурного описания приложения или проекта. Эта методика является неким адаптированным вариантом стандарта IEEE 1471 и не претендует на полноту. Основная цель - помочь командам выбрать направление для документирования архитектуры их проектов.