Информационные системы обеспечивают сбор, хранение, обработку, поиск, выдачу информации , необходимой в процессе принятия решений задач из любой области.
Информационная система — взаимосвязанная совокупность средств, методов и персонала, используемых для хранения, обработки и выдачи информации в интересах достижения поставленной цели.
АИС – это человеко-машинная система, обеспечивающая автоматизированную подготовку, поиск и обработку информации.
Используется в рамках интегрированных сетевых, компьютерных и коммуникативных технологий для оптимизации экономической и другой деятельности в различных сферах управления.
Техническое обеспечение (ТО) — комплекс технических средств, предназначенных для работы информационной системы, а также соответствующая документация на эти средства и технологические процессы.
Информационное обеспечение (ИО) – совокупность единой системы классификации и кодирования информации, унифицированных систем документации, схем информационных потоков, циркулирующих в организации, а также методология построения баз данных.
Назначение ИО состоит в своевременном формировании и выдаче достоверной информации для принятия управленческих решений.
· Системы обработки данных
· Системы бухгалтерского учета и т.д.
Функциональная подсистема
Математическое и программное обеспечение (МО, ПО) — совокупность математических методов, моделей, алгоритмов и программ для реализации целей и задач информационной системы, а также нормального функционирования комплекса технических средств.
Организационное обеспечение (ОО) -совокупность методов и средств, регламентирующих взаимодействие работников с техническими средствами и между собой в процессе разработки и эксплуатации информационной системы.
Правовое обеспечение (Пр.О) — совокупность правовых норм, определяющих создание, юридический статус и функционирование информационных систем, регламентирующих порядок получения, преобразования и использования информации.
Главная цель Пр.О — укрепление законности.
Модели ИС
Наши представления о реальных системах носят приближенный, модельный характер.
Описывая в какой-либо форме реальную систему, мы создаем ее информационную модель . Существуют различные варианты модельного описания систем.
Модель «Черного ящика»
Всякая система – это нечто цельное и выделенное из окружающей среды. Система и среда взаимодействуют между собой.
Вход системы – это воздействие на систему со стороны внешней среды, а выход – это воздействие, оказываемое системой на окружающую среду.
Модель «черного ящика» используется в тех случаях, когда внутреннее устройство системы не представляет интереса, но важно описать ее внешние взаимодействия.
В любой инструкции по использованию бытовой техники дается описание работы с ней на уровне входов и выходов: как включить, как регулировать работу, что получим на выходе.
Такое представление может быть вполне достаточным для пользователя данной техникой.
• модель черного ящика компьютера
Разумеется, такой модели недостаточно для того, чтобы понять, как функционирует школа.
И все-таки она дает более подробное представление, чем модель «черного ящика».
Модель состава системы
Модель состава системы дает описание входящих в нее элементов и подсистем, но не рассматривает связей между ними.
Модель состава системы «Школа»
Модель состава компьютера
Структурная модель системы
Такую модель часто называют
структурной схемой.
На структурной схеме отражается состав системы и ее внутренние связи.
Наглядным способом описания структурной модели системы являются графы .
Структурная модель компьютера
Здесь стрелки обозначают информационные связи между элементами системы. Направление стрелок указывает на направление передачи информации.
Граф-модель компьютера (со связью по управлению)
Структурную модель удобно изображать в виде графа, который отображает элементный состав системы и структуру связей между ее элементами.
Местность и автомобильные дороги между группами застроек А, Б, В, Г, Д.
Это не карта местности. Здесь не выдержаны направления по сторонам света, не соблюден масштаб. На этой схеме отражен лишь факт существования пяти поселков и дорожной связи между ними.
Построение модели для ИС «Студенты»
Модель «черного ящика»
Модель состава системы «Студенты»
Модель структуры системы «Студенты»
Модель объекта
Она представлена в виде информации, что описывает существенные для конкретного случая параметры и переменные, связи между ними, а также входы и выходы для данных, при подаче на которые можно влиять на получаемый результат. Их нельзя увидеть или потрогать. В целом они не имеют материального воплощения, поскольку строятся на использовании одной информации.
Сюда относятся данные, что характеризуют состояния объекта, существенные свойства, процессы и явления, а также связь с внешней средой. Это процесс называется описанием информационной модели. Это самый первый шаг проработки.
Полноценной информационной моделью является обычно сложная разработка , которая может иметь много структур , что в рамках статьи сведены в три основных типа:
1. Описательная . Сюда относятся модели, которые создаются на естественных языках. Они могут иметь любую произвольную структуру, которая удовлетворит составляющего их человека.
2. Формальная . Сюда относят модели, которые создаются на формальных языках (научных, профессиональных или специализированных). В качестве примеров можно привести такое: все виды таблиц, формул, граф, карт, схемы и прочих подобных структурных формаций.
3. Хроматические . Сюда относят модели, которые были созданы с применением естественного языка семантики цветовых концептов, а также их онтологических предикатов. Под последними понимают возможность распознавания значений цветовых канонов и смыслов. В качестве примера хроматических моделей можно навести те, что были построены с использованием соответствующей теоретической базы и методологии.
Основной составляющей являются данные, их структура и процедура обработки . Развивая мысль, можно дополнить, что информационная модель является схемой, в которой описана суть определённого объекта , а также все необходимые для его исследования процедуры . Для более полного описания характеристик используют переменные. Они замещают атрибут цели, которая прорабатывается. И здесь имеет значительную важность структура информационной модели.
Опыт практического применения АИС показал, что наиболее точной, соответствующей самому назначению АИС следует считать классификацию по степени сложности технической, вычислительной, аналитической и логической обработки используемой информации. При таком подходе к классификации можно наиболее тесно связать АИС и соответствующие информационные технологии.
Соответственно можно выделить следующие виды АИС :
· автоматизированные системы обработки данных (АСОД);
· автоматизированные информационно-поисковые системы (АИПС);
· автоматизированные информационно-справочные системы (АИСС);
· автоматизированные информационно-логические системы (АИЛС);
· автоматизированные рабочие места (АРМ);
· автоматизированные системы управления (АСУ);
· автоматизированные системы информационного обеспечения (АСИО);
· экспертные системы (ЭС) и системы поддержки принятия решений.
Методологически важно наряду с рассмотренными моделями среды ИС предложить модель создания ИС, которая имела бы те же аспекты функциональных групп компонентов (пользователи, функции, данные, коммуникации). Такой подход обеспечит сквозной процесс проектирования и сопровождения на всех стадиях эксплуатации ИС, а также возможность обоснованного выбора стандартов на разработку систем и документирование проектов.
Определение » компания » является сложной онтологической (понятийной) структурой , состоящей из определенной совокупности сущностей и взаимосвязей . Взаимодействия между ее элементами, определяемые бизнес-логикой и закрепленные в наборе бизнес-правил , и являются деятельностью компании. Информационная система «отражает» логику и правила, организуя и преобразуя информационные потоки, автоматизирует процессы работы с данными и информацией и визуализирует результаты в виде наборов отчетных форм.
Поэтому для начала следует создать бизнес-модель предприятия, являющуюся отображением предприятия и его информационно-управляющей системы.
При создании модели формируется «язык общения» руководителей предприятия, консультантов, разработчиков и будущих пользователей, позволяющий выработать единое представление о том, ЧТО и КАК должна делать система управления предприятием (корпоративная система управления).
Источник: dzen.ru
Методики описания архитектур. Модели Захмана и Gartner, методики META Group и TOGAF
Первая строка соответствует уровню планирования бизнеса в целом ( бизнес-модель ). На этом уровне вводятся достаточно общие основные понятия, определяющие бизнес – например, продукты и услуги, клиенты, расположение объектов бизнеса, а также формулируется бизнес-стратегия (колонка 6 – мотивация). Фактически, данная строка определяет контекст всех последующих строк.
Вторая строка ( концептуальная модель ) предназначена для определения в терминах бизнеса структуры организации, ключевых и вспомогательных бизнес-процессов .
Третий уровень ( логическая модель ) соответствует рассмотрению с точки зрения Системного Архитектора. Здесь бизнес-процессы описываются уже в терминах информационных систем, включая различные типы данных, правила их преобразования и обработки для выполнения определенных на уровне 2 бизнес-функций.
На четвертом уровне – технологической или физической модели – осуществляется привязка данных и операций над ними к выбранным технологиям реализации. Например, здесь может быть определен выбор реляционной СУБД , или средств работы с неструктурированными данными, или объектно-ориентированной среды.
Пятый уровень соответствует детальной реализации системы, включая конкретные модели оборудования, топологию сети, производителя и версию СУБД , средства разработки и собственно готовый программный код. Многие из работ на данном уровне часто выполняются субподрядчиками.
Рассмотрим теперь, как осуществляется последовательная детализация отдельных аспектов описания системы, для чего обратим внимание на различные колонки таблицы. Напомним, что порядок расположения колонок в таблице, вообще говоря, произволен.
Так, первая колонка отвечает на вопрос «ЧТО?» и определяет используемые в системе данные. На верхнем уровне достаточным будет простое перечисление основных объектов, используемых в бизнесе.
На втором уровне данные объекты объединяются в семантическую модель высокого уровня и обычно описываются в виде диаграммы «сущности-связи» (E-R диаграммы) с отражением основных связей и наиболее существенных бизнес-ограничений. На третьем уровне эта модель приводится к нормализованной форме , определяются все атрибуты и ключи. Четвертый уровень представляет собой физическую модель данных в системе (в объектно-ориентированном подходе – иерархию классов). Следующий уровень содержит описание модели на языке управления данными для формирования таблиц, готовые библиотеки классов, табличные пространства СУБД . Наконец, последний уровень может описывать фактические наборы данных, в том числе такие характеристики, как журналы доступа, размеры реально занимаемого дискового пространства, статистику обращений и т.п. Конечно, можно отметить определенное несовершенство данной модели при использовании объектно-ориентированного подхода – фактически модель предписывает раздельное рассмотрение данных (свойств) и функций (методов) классов.
Колонка функций (ответ на вопрос «КАК?») предназначена для последовательной детализации описания того, как миссия предприятия реализуется на уровне отдельных операций. В частности, на первом уровне достаточным будет простое перечисление бизнес-процессов. Второй уровень будет содержать модель бизнес-процессов, которая впоследствии детализируется в операции над данными и архитектуру приложений (уровень 3), методы классов (уровень 4), программный код (уровень 5) и, наконец, исполняемые модули. При этом, начиная с 4-го уровня, рассмотрение ведется уже не в рамках Предприятия в целом, а по отдельным подсистемам или приложениям.
Следующая колонка (вопрос «ГДЕ?») определяет пространственное распределение компонент системы и сетевую организацию. На уровне планирования бизнеса здесь достаточно определить расположение всех производственных объектов.
На следующем уровне эти объекты объединяются в модель со связями, характеризующими взаимодействие между собой, – будь то обмен информацией или поставки товаров. На третьем уровне системной архитектуры осуществляется привязка компонент информационной системы к узлам сети.
Четвертый уровень служит для определения физической реализации в терминах аппаратных платформ, системного программного обеспечения, а также средств промежуточного уровня (так называемое » middleware «), используемых для интеграции различных компонент информационной системы между собой. Типичным примером могут являться брокеры запросов или средства обмена сообщениями. На пятом уровне определяются используемые протоколы и спецификации каналов связи. Последний уровень описывает функционирование реализованной сети.
Колонка таблицы, отвечающая на вопрос «КТО?», определяет участников процесса. На уровне планирования бизнеса здесь представлен список подразделений предприятия и выполняемые ими функции. На следующем уровне приводится полная организационная диаграмма , а также могут быть определены общие требования к информационной безопасности. Далее последовательно определяются участники бизнес-процессов и их роли (в RUP используются диаграммы событий и описание вариантов использования), требования к интерфейсам пользователя и правила доступа к отдельным объектам, физическая их реализация на уровне кода или операторов определения доступа к таблицам в СУБД . Последний уровень описывает обученных пользователей системы.
Пятая колонка отвечает на вопрос «КОГДА?» и определяет временные характеристики бизнес-процессов и работы системы. Опять-таки детализация осуществляется сверху вниз, начиная от календарного плана (уровень 1) и основных параметров, характеризующих выполнение бизнес-процессов, – например, требование ко времени оформления сделки (уровень 2).
На третьем уровне определяются события, вызывающие изменение состояния информационных объектов и инициацию операций над ними. На следующем уровне эти события транслируются в программные вызовы (триггеры) или передаваемые сообщения. Пятый уровень определяет физическую реализацию обработки таких событий. Наконец, на 6-м уровне – фактическая история функционирования системы.
Последняя колонка («ПОЧЕМУ?» или «ЗАЧЕМ?») служит для определения мотивации и задает порядок перехода от задач бизнеса к требованиям и элементам информационных систем. Исходной точкой является бизнес-стратегия, которая затем последовательно транслируется в бизнес-план, затем в правила и ограничения для реализации бизнес-процессов, а на уровне 4 – в соответствующие приложения, необходимые для включения в состав информационных систем и, в дальнейшем, в их физическую реализацию.
Такая модель описания в целом полезна для идентификации возможных ограничений. Эти ограничения могут «распространяться» как от верхних уровней к нижним (например, указание руководства компании о выборе тех или иных средств, продуктов или принципов работы), так и в обратном направлении – например, возможности существующих технологий беспроводной связи в значительной степени определяют спектр предлагаемых услуг и организацию бизнес-процессов у провайдеров этих услуг.
Важным принципом предложенной модели является необходимость последовательного перехода при углублении детализации рассмотрения. Пропуск отдельных элементов, например, прямой переход от описания модели бизнес-процесса к физической реализации системы требует «привлечения магии» и почти всегда приводит к неудаче. На практике это часто случается при попытке разработки программы на основании только устного описания требований пользователя.
Основными характеристиками данной модели Захмана, как отмечено в [5.6], являются следующие:
- простота для понимания как техническими, так и нетехническими специалистами;
- целостность в отношении предприятия, то есть каждая проблема может быть соотнесена с предприятием в целом;
- поддержка обсуждений сложных вопросов с использованием относительно небольшого количества нетехнических понятий;
- возможность применения для планирования, позволяющего лучше принимать решения за счет того, что решение никогда не будет выноситься «в пустоте» (в отрыве от остальных аспектов деятельности предприятия);
- применимость для решения задач, то есть возможность работать с абстракциями и сущностями, выделяя и изолируя отдельные параметры системы без потери восприятия Предприятия как целого;
- нейтральность, то есть независимость от каких-либо инструментов; благодаря этому каждый инструмент и методология могут быть отображены на данную модель и могут явно показать, что они делают и чего они не делают.
Созданная модель архитектуры служила простым, но мощным инструментом по применению системного подхода для планирования работ по созданию и использованию информационных систем и их стыковки. Захман писал, что схема архитектуры позволяет концентрироваться на отдельных аспектах системы и в то же время не терять ощущения общего контекста или «холистической» перспективы (то есть, взгляда на предприятие в целом). Он подчеркивал, что именно потеря такой перспективы, в частности, разработка систем субподрядчиками, находящимися «вне контекста», уже около пятидесяти лет составляет причину появления неинтегрируемых и не поддерживающих предприятие должным образом систем, которые к тому же весьма дорого заменять.
Баланс между сущностью реализации отдельных ячеек и интегрированным взглядом на систему поддерживается моделью Захмана за счет того, что она:
- облегчает понимание и общение людей, имеющих разные роли в процессах создания, развития и использования системы;
- ясно определяет фокус внимания на (относительно) независимых параметрах для целей анализа;
- но в то же время обеспечивает поддержку контекстных взаимосвязей, важных для сохранения целостности системы.
Рассмотрим, как может использоваться подход, предложенный Захманом, на практике. Во-первых, данную модель удобно применять для классификации всей информации, описывающей предприятие и информационные системы этого предприятия, выявления «белых пятен» и координации работ . Во-вторых, данную модель можно использовать на метауровне – для сравнения различных реализаций создания архитектур предприятия. Наконец, она может являться удобным средством для использования в отдельных проектах. Например, в проекте по созданию корпоративного информационного портала необходимо определить элементы в строках 3-5 колонки 4 – соответственно, требования пользователей к представлению данных, интерфейсы и спецификацию по разграничению доступа с учетом существующих «унаследованных» компонент информационной системы. Эта существующая технологическая архитектура , в свою очередь , рассматривается в ячейке на пересечении четвертой строки и третьего столбца таблицы.
Нельзя, конечно, считать, что данная модель лишена недостатков. Один из них заключается в том, что при применении ее на практике возникают определенные трудности, связанные с отсутствием «встроенного механизма» распространения изменений между элементами таблицы. Действительно, предположим, что изменилась организация процесса поставок в компании (схема логистики). Это потребует отслеживания «вручную» всех взаимосвязей, проверки актуальности и внесения изменений в модели и другие артефакты во всех потенциально «затрагиваемых» ячейках.
Другим ограничением модели является отсутствие рассмотрения системы в динамике. Действительно, каждый элемент таблицы может содержать как описание существующего состояния («как есть»), так и целевого, а также всех промежуточных состояний. При этом сама модель не содержит средств для четкого разделения этих различных «временных срезов».
Тем не менее, существуют специализированные продукты, такие как Popkin Software Architect , которые фактически основаны на модели Захмана и позволяют достаточно эффективно управлять созданием моделей и артефактов описания архитектуры предприятия.
Соответствующее обобщение подхода Захмана было предложено в работах Е.Б. Зиндера [5.7]. Основная идея заключается в обеспечении возможностей отражения постоянного развития предприятия (и его информационных систем) как непрерывной последовательности трансформаций.
Вместо традиционной двумерной таблицы было предложено ввести трехмерную схему, добавив к плоским схемам ось стратегического времени. На этой оси располагаются отрезки времени осуществления различных проектов и стадий развития информационных систем и всего предприятия.
Таким образом, была создана «объемная» схема архитектуры предприятия или модель «3D-предприятие», которая строится в трех измерениях с учетом временного пространства.
При этом, по предложению автора данной работы, первые два измерения аналогичны тем, которые использовал Захманом, но не совпадают с оригиналом полностью по содержанию и трактовке. Третья ось позволяет явно определять те изменения, которые происходили и будут происходить с предприятием, его существующими информационными системами, а также с различными проектами развития и трансформации.
Стоит отметить, что предложенный вариант развития исходного подхода Захмана не является единственно возможным. Существует большое количество модельных схем, которые в той или иной мере используют данный подход, хотя визуальное представление модели в целом может достаточно сильно отличаться. Одним из таких примеров может служить предложенная Институтом разработок архитектуры предприятия модель Extended Enterprise Architecture Framework (E2AF) [5.8]. Эта модель содержит 4 области рассмотрения (бизнес, информация , информационная система, технологическая инфраструктура ) и следующие 6 уровней абстракции:
- контекстуальный (Зачем?)
- уровень взаимодействия (с Кем?)
- концептуальный (Что?)
- логический (Как?)
- физический (с помощью Чего?)
- трансформационный (Когда?)
Другой пример – это так называемая модель 4-доменной архитектуры (Four Domains architecture , FDA ) [5.9], в которой предлагается, в частности, провести как бы условное разбиение ячеек исходной модели Захмана на 2 компоненты – архитектуру описания ( Architecture -in-Design) и архитектуру исполнения ( Architecture -in-Operation). При этом первая компонента описывает ход, средства и артефакты процесса разработки архитектуры предприятия, в то время как вторая предназначена для описания непосредственно бизнес-процессов и реализации ИТ-систем.
Источник: intuit.ru
Представление бизнес модели ис включает следующие уровни
6. МЕТОДИКИ ОПИСАНИЯ АРХИТЕКТУР
6.1. Модели жизненного цикла информационной системы
Существующие модели ЖЦ:
- Каскадная модель. Весь объем работ разбивается на этапы (рис.18). Переход на следующий этап разработки только после окончания работ на предыдущем этапе. Этап заканчивается формированием полного комплекта документов [28].
Рис. 18. Каскадная модель разработки
Каскадная модель не потеряла своего значения и сегодня. Достоинство ее в том, что для ее реализации в самом начале разработки необходимо сформулировать все требования к информационной системе. Это позволит избежать неточностей и ошибок на следующих этапах. К недостаткам относят то, что на практике происходит задержка во времени на каждом этапе.
Недостатки модели выясняются на более поздних этапах, когда приходится возвращаться назад и переделывать или доделывать полностью законченный предыдущий этап. Высокая информационная насыщенность каждого этапа при невозможности распараллелить работы.
- Спиральнаямодель. Основное внимание направлено на начальные этапы ЖЦ: анализ требований к системе, спецификации, предварительное проектирование (рис.19). Технические решения, создаваемые на этих этапах, проверяются. Уточняются цели и характеристики проекта, уточняются детали. Каждый виток спирали создает свою версию системы. Далее работа уточняется, углубляются и поэтапно конкретизируются детали проекта. В итоге выбирается наиболее приемлемый вариант системы, который доводится до реализации [28].
Рис. 19. Спиральная модель жизненного цикла системы
6.2. Модель Захмана
IT-архитектура компании –единое описание важнейших направлений организации, которые имеют связь с информационной средой, прикладными системами и технологиями, при этом учитывается вoздействие на основные функции и процессы компании [14].
ИсследованиеIT-архитектуры компании несет в себе составляющие, связанные с мнoгoфункциональной архитектурой, IT-технологиями и управлением. IT-структура компании– целостное описание главных стратегий и целей организации, связанных с технологиями, прикладными системами и информацией. И с воздействием их на бизнес-функции и бизнес-процессы организации [6].
Рассмотрение IT-архитектуры компании производится в определенном контексте имеющихся в компании текстур управления и взаимодействия.
Есть разные модели и способы описания IT-архитектуры. Все эти способы задают классификацию главных областей и единичные взгляды для их описания. Существуют различные способы отображения примeняемых стереотипов, действий, моделей для oпределения разных частей IT-архитектуры, например [7]:
- методики аналитических компаний: Gartner, Giga, META и др.;
- модель Захмана;
- методика TOGAF;
- методика POSIX 1003.23i и др.
Методика – инструмент для создания широкого диапазона разнообразных архитектур [32]. Она включает в себя определение методов проектирования IT-структуры в понятиях использования определенных «строительных блоков», описание того, как эти «строительные блоки» связаны между собой, набор средств для определения частей архитектуры.
Методики включают в себя список рекомендуемых стандартов и совместимых продуктов, которые могут использоваться для воплощения разнообразных частей структуры. Методики конкретизируют, как все эти элементы описания связаны между собой[26]. Определены индустриальные стандарты, чтобы описать ИТ-архитектуру предприятия. Отдельно друг от друга эти стандарты не могут дать разработчикам IT-архитектуры полного набора незаменимых инструментов с точки зрения этой методики и с точки зрения стандартов, которые нужны, чтобы описать архитектуру.
Отображение IT-архитектуры служит детальным руководством, определяющим первоначальные, стандартные или типовые элементы IT-систем, взаимодействие между собой, а также процессы управления информационными системами. Можно сформулировать такие требования [26]:
- высокая степень детализации для практического применения специалистами в сфере IT при исследовании новейших систем;
- простоту для осмысления не специализированной целевой группы;
- динамику рассмотрения, т.е. переход от «Архитектуры как есть» к «Задачам архитектуры на заданные промежутки времени», к «Стратегическим планам»;
- адаптация к новым условиям бизнеса и возможность реализации новых планов.
Для правильного описания IT-архитектуры организации могут применять разные форматы. Принципиально, чтоб организация употребляла такой формат описания, который бы давал простой для понимания метод руководства по развитию всех качеств IТ в компании [35].
Почти все термины IT-архитектуры считаются произошедшими от единых понятий, относящихся к архитектуре компании в целом. Поэтому для описания и прогнозирования IT-архитектуры используются инструментальные и методологические средства моделирования, созданные для наиболее обобщенных задач.
Схема Захмана [4, 11] основывается на предмете традиционной архитектуры и формирует единый словарь и набор возможностей или структур для описания основных усложненных корпоративных систем. В собственном труде Дж. Захман обозначил архитектуру компании как «набор описательных моделей, применимых для описания предприятия в соответствии с требованиями управленческого персонала, которые могут развиваться в течение определенного периода». Понятие «архитектура» не случайно, оно выделяет существующую аналогию между внутренней текстурой теоретического объекта – компанией, и сложным искусственным объектом, таким, как башня либо аэродром.
Модель архитектуры, которую предложил Захман, преследует две главные цели [4, 11]:
— с одной стороны, упорядочить описание архитектуры, разбив ее на отдельные сегменты для лучшего восприятия и возможности анализа;
-с другой – иметь возможность рассмотрения всей архитектуры с интересующих точек.
До этого широко употребляемым подходом при описании системы использовалось понятие жизненного цикла системы, которое содержало рассмотрение таких этапов, как планирование, анализ, проектирование, разработка, документирование, внедрение и промышленная эксплуатация. На каждом из этих этапов анализируются и основные функции системы, и данные.
Ученый внес предложение вместо стандартного подхода, опирающегося на рассмотрение отдельных аспектов работы системы как бы в разные факторы времени, рассматривать системы с разных точек зрения [4, 11].
Первоначально модель Захмана была оформлена конкретно для IT-систем. Данный подход в следующем труде ученого был обобщен для рассмотрения и для описания компании в целом. Поэтому можно считать рассматриваемую модель пригодной для описания архитектур производственных систем различной сложности, вне зависимости от типа.
Главная мысль заключается в том, чтобы обеспечить возможность поочередного описания каждого отдельного аспекта системы в связи со всеми остальными. Связать характеристики системы с задачами в области бизнеса. В основе лежит то правило, что ни одна система не достигает цели функционирования в области бизнеса без использования какой-либо пригодной для этих целей системы. А информационная система состоит из процессов, которые выполняют люди, и процессов, которые выполняют компьютеры.
Модель предприятия задается в виде матрицы (рис. 20). Фактически модель изображается в виде таблицы, имеющей 5 строчек и 6 столбцов. Именно модель, которая соответствует уровню описания архитектуры, содержит точно 5 строк. Строки отражают категории специалистов, которые участвуют в деятельности предприятия. Столбцы отражают основные аспекты производственной деятельности.
Шестая строка в данной модели соответствует уровню работающей системы.
Две верхние строчки отображают наиболее общие представления и довольно обширно поясняют имеющееся окружение, намерения и цели. Если провести аналогию со строительством, то данные значения несут в себе сведения о местоположении и функции возведенного сооружения, а также намерения и изображения, которые конструктор обговаривает с владельцем строящегося здания. Следующий этап «логической модели» считается наиболее определенным, однако всё ещё довольно отвлеченным. Наверное, это схемы, которые архитектор этого здания обязан демонстрировать поставщикам и заказчикам.
Рис. 20. Модель Захмана
На любом из уровней участники разработки архитектуры рассматривают одни и те же вопросы, соответствующие столбцам таблицы. Ответы на эти вопросы будут соответствовать их компетенциям и отличаться уровнем абстракции и детализации. Колонки озаглавлены так [4, 11]:
- входные данные (что?);
- процессы и функции (как?);
- место реализации данных процессов (где?);
- участники (кто?);
- события (когда?);
- цели и ограничения работы системы (почему?).
Основные правила при заполнении таблицы:
- каждая отдельная клетка не зависит от других, а вместе они составляют функционально единое пространство для описания системы («базис»);
- порядок расположения столбцов не имеет особого значения;
- любая ячейка включает в себя соответствующее описание аспекта применения системы в виде конкретной модели;
- стандартные модели для любой из колонок являются неповторимыми;
- совокупности моделей в ячейках любого ряда образуют широкое описание системы с конкретно обозначенного ракурса;
- запись в ячейки должна производиться постепенно, а именно «сверху вниз».
Участники могут фокусировать свое внимание на различных деталях, рассматривать разные вопросы, но в итоге должно сформироваться общее видение архитектуры, отражающее реальную картину. Проектировщик должен понимать точку зрения заказчика и наоборот. Строки представляют разные точки зрения.
Предложенная модель архитектуры является простым, однако очень значимым инструментом для организации и планирования работ по созданию и применению информационных систем, основанным на системном подходе. Модель архитектуры дает концентрацию на частных аспектах системы и в то же время не утрачивает чувство всеобщего контекста, т.е. взгляда на компанию в целом.
Диаграмма на рис. 21 иллюстрирует несколько методов моделирования [31]. Пересечение методов используется для формирования матрицы Захмана.
В табл. 6 приведено, какие модели на каких стадиях описания систем рекомендуется использовать.
Рис. 21. Методы моделирования
Таблица 6
Модели развития систем
Источник: www.aup.ru