Файл: Сравнительный анализ методик оригинального и типового проектирования архитектуры предприятия (Цикл развития архитектуры предприятия).pdf

ВУЗ: Не указан

Категория: Реферат

Дисциплина: Не указана

Добавлен: 06.07.2023

Просмотров: 71

Скачиваний: 2

ВНИМАНИЕ! Если данный файл нарушает Ваши авторские права, то обязательно сообщите нам.

Введение

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

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

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

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

Цикл развития архитектуры предприятия

Архитектура предприятия определяет общую структуру и функции систем (бизнес- и ИТ-) в рамках всей организации в целом (включая партнеров и другие организации, формирующие так называемое «предприятие реального времени»), и обеспечивает общую рамочную модель (framework), стандарты и руководства для создания архитектуры уровня отдельных проектов. Общее видение, обеспечиваемое архитектурой предприятия, создает возможность единообразного проектирования систем адекватных с точки зрения обеспечения потребностей организации и способных к взаимодействию и интеграции там, где это необходимо. [8]

Архитектура предприятия развивается циклично. В ходе разработки стратегии развития предприятия выявляются изменения в его бизнес-архитектуре, позволяющие оптимизировать бизнес-процессы, изменение которых непосредственно влияет на изменение ИТ — архитектуры. Следующим шагом становится разработка плана миграции, в ходе выполнения которого происходит переход из текущего состояния в планируемое. При этом процесс миграции является лишь очередным шагом на пути преобразования предприятия, и его окончание означает переход организации на новый виток развития, вновь начинающийся с разработки стратегии. [1]


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

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

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

Оригинальное проектирование архитектуры предприятия

Методы оригинального проектирования являются традиционными, они начали применяться с начала 60-х годов и ориентированы только на одно конкретное предприятие. Поэтому наиболее характерной чертой, присущей этому методу, является разработка оригинальных методик обследования объекта, его внедрения, создания необходимой проектной документации в виде индивидуального проекта. Отсюда основное его достоинство - отражение в проекте АИС специфических особенностей объекта автоматизации. К недостаткам можно отнести сравнительно высокую трудоемкость и большие сроки разработки, низкий показатель функциональной надежности и адаптируемости к изменяющимся условиям. [7]

Проекты, созданные оригинальным методом, поддаются модернизации.

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


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

Типовое проектирование архитектуры предприятия

Типовое проектирование ИС предполагает создание системы из готовых типовых элементов. Основополагающим требованием для применения методов типового проектирования является возможность декомпозиции проектируемой ИС на множество составляющих компонентов (подсистем, комплексов задач, программных модулей и т.д.). Для реализации выделенных компонентов выбираются имеющиеся на рынке типовые проектные решения, которые настраиваются на особенности конкретного предприятия. [9]

В зависимости от уровня декомпозиции системы различают элементный, подсистемный и объектный методы типового проектирования (ТПР) (рис. 1).

Рисунок 1. Классификация типовых методов проектирования.

Основами элементного проектирования являются ТПР [10], которые представляют собой результат выполнения нескольких взаимосвязанных технологических операций проектирования и поэтому при разработке проекта используется уже это готовое решение с небольшими модификациями, а не разрабатывается новое. Комплекс типовых проектных решений подразделяется на три большие группы: "Техника", "Задача", "Персонал". Первая группа связана с выбором и комплектацией всех видов технических средств вычислительных центров или других организационных форм их применения. Группа "Задача" содержит документацию по организационно-экономической сущности каждой задачи, алгоритмы ее решения, описание входной и выходной информации, соответствующие программные модули с их описаниями и инструкциями по применению (рис. 2). В группу ТПР "Персонал" входят должностные инструкции всех категорий работников, определяющие их права и обязанности. [2]


Рисунок 2. ТПР уровня задача

Типовое проектное решение (ТПР) — это тиражируемое (пригодное к многократному использованию) проектное решение. [9]

Сущность применения ТПР при элементном методе заключается в комплектации ЭИС из множества ТПР по отдельным разрозненным задачам. Если данного множества недостаточно для того, чтобы спроектировать систему, необходимые модули дорабатываются вручную. [6] Достоинство элементного метода типового проектирования ЭИС связано с применением модульного подхода к проектированию и документированию ЭИС.

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

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

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

Типовые проектные решения для функциональных подсистем реализуются в виде пакетов прикладных программ (ППП), которые позволяют осуществлять:

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

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


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

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

Несомненное преимущество объектного метода типового проектирования ЭИС перед подсистемным методом заключается в комплексируемости всех компонентов за счет методологического единства и информационной, программной и технической совместимости компонентов. [3, 4]

Принятая классификация ТПР основана на уровне декомпозиции системы. Выделяются следующие классы ТПР:

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

Каждое типовое решение предполагает наличие, кроме собственно функциональных элементов (программных или аппаратных), документации с детальным описанием ТПР и процедур настройки в соответствии с требованиями разрабатываемой системы. [10]

Основные особенности различных классов ТПР приведены в таблице 1.

Таблица 1.

Достоинства и недостатки ТПР

Класс ТПР

Реализация ТПР

Достоинства

Недостатки

Элементные ТПР Библиотеки методо-ориентированных программ

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

Подсистемные ТПР Пакеты прикладных программ

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

Объектные ТПР Отраслевые проекты ИС

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