Схема Захмана при разработке требований к ИС

Мадорская Ю.М.

Схема Захмана  [2] – одна из первых работ в области разработки архитектурных каркасов информационных систем.

Архитектурный каркас информационной системы — это структура свойств системы, которые должны быть заданы в ходе ее проектирования. Например, цели создания, роли и функции — всё это свойства системы, а заодно и требования к ней. Поэтому архитектурный каркас — это  также и классификация требований к информационной системе.

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

Схема Захмана является наиболее полным архитектурным каркасом и определяет общие свойства информационных систем на том уровне, когда они еще не зависят от парадигмы проектирования, технологии и средств разработки. Она систематизирует знания об архитектуре информационной системы, охватывая все аспекты проектирования за счет использования системы шести универсальных вопросов «Что? Кто? Где? Когда? Как? Почему?».

zachman-rows-01

Рисунок 1. Столбцы схемы Захмана

Захман адаптировал эти вопросы к проектированию информационных систем и уточнил срезы проектирования.

Срезы Что и Как отдаются для описания Данных и Функций информационной системы — объективному ядру систем этого класса.

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

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

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

zachman-circle2-01

Рисунок 2. Свертка схемы Захмана

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

Интересно, что Захман не включил в исходную версию схемы три среза: «люди», «время», «мотивация» — они появились только во втором, расширенном варианте [5]. Захман был обеспокоен тем, что люди не захотят принять то, что это такие же опорные срезы проектирования, как и остальные. Сравните это с современной ситуацией — большинство методологий управления проектами фокусируются именно на Людях и Мотивации.

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

Итак, уровни:

  • предметная область — контекст создания системы, ее границы,
  • модель предприятия — бизнес-категории и связанные с ними бизнес-правила,
  • модель системы — логическая модель архитектуры, данных, функций,
  • модель технологии — особенности физической реализации,
  • компоненты — конкретные объекты и настройки системы,
  • функционирующая система и ее свойства.
zachman-layers-01

Рисунок 3. Уровни детализации требований к ИС по схеме Захмана

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

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

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

Также в схеме приводятся, но не навязываются, типы моделей для описания каждого среза системы. При этом связи между ними не предопределены.

Рисунок 4. Расширенная схема Захмана в русском адаптированном переводе

На втором этапе Захман предложил расширенную модель архитектуры информационной системы [3]. Он дополнил 2, 3 и 4 слой (бизнес, система и технологии) ER- диаграммами, отражающими связи между понятиями схемы, и предложил использование формального аппарата концептуальных графов для описания информационной системы. Но описание расширенной схемы отсутствует и это исключает возможность ее применения на практике.

sowa_ext_zachman

Рисунок 5. Фрагмент расширенной схемы Захмана

Движение в сторону проработки связей между ячейками исходной схемы имеет важное значение. Хотя все ячейки имеют самостоятельную ценность — они не могут существовать обособленно. Для каждого требования к ИС, соответствующего какой-либо ячейке, должны быть определены связи с требованиями из других ячеек. Например, бизнес-процесс (КАК) всегда работает с данными (ЧТО), и мы не сможем спроектировать систему, описав структуру бизнес-процессов отдельно от данных, которые они используют. И, конечно, эти связи хотелось бы понимать уже на уровне архитектурного каркаса.

В своей статье о расширенной  схеме [3] Захман подчеркивает важность описания связей между моделями различных слоев. Это необходимо, чтобы сохранить представление  о системе в целом и о контексте ее использования в ходе всех циклов проектирования. Фактически, он говорит о необходимости обеспечения сквозной трассировки требований и расширенная схема — это и есть попытка разработать модель такой трассировки.

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

Интересно отметить, что в 2008 году Захман в своей публикации «Точное определение схемы Захмана» определяет свою схему как онтологию [4]. Возможно это дань моде, а возможно необходимо, чтобы точнее классифицировать работу и выделить ее из серии  новых архитектурных каркасов, которые стали включать не таксономию архитектуры, а процесс по ее разработке. Сам автор мотивирует это тем, что процессы, основанные на онтологической структуре, будут более предсказуемы и будут выдавать повторяемые результаты. Заметим, что сама схема при этом не изменена.

Схема Захмана — отличное средство для обучения начинающих аналитиков-постановщиков, а также механизм тестирования требований и контроля качества проектирования.

Работая над требованиями к системе, держите распечатку схемы под рукой и «прокатывайте» каждое требование по каждому срезу. Эта не займет много времени, но за счет активации ассоциативных связей позволит выявлять требования за меньшее число шагов взаимодействия с заказчиком. Фактически, многие техники креативности и мозгового штурма используют именно такой подход.

Хотите сослаться на эту статью? Используйте правильную ссылку:

Мадорская Ю.М., Схема Захмана при разработке требований к ИС //Практика проектирования систем.-2015. [электронный ресурс] — Режим доступа: http://reqcenter.pro/zachman-framework/, свободный. — Загл. с экрана

Литература

[11] Данилин А. Архитектура и стратегия  / А. Данилин,  А. Слюсаренко. –  М. Интернет-Ун-т Информ. Технологий,  2005. – 504 с.

[2] Zachman J. A. A framework for information systems architecture. // IBM Syst. J. 26, 3, 1987. – P.  276-292.

[3] Zachman J. A., Sowa J. F. Extending and formalizing the framework for information systems architecture // IBM Systems Journal, 1992, 31, №3. – P.  590-561.

[4] Zachman J. A. John Zachman’s Concise Definition of the The Zachman Framework. Zachman International. 2008. URL: http://www.zachmaninternational.com/concise%20definition.pdf

[5] Zachman P. The Zachman Framework Evolution. 2009 URL:  https://www.cob.unt.edu/itds/faculty/becker/BCIS5520/Readings/The%20Zachman%20Framework%E2%84%A2%20Evolution.pdf

Опубликовано в: