Интеграция информационных систем предприятия

Рассмотрение взаимосвязи информационных подсистем предприятия. Характеристика сервис-ориентированной архитектуры информационных систем. Оценка реализации SOA-инфраструктуры на базе сервисной шины предприятия. Анализ бизнес-цели внедрения SOA-решений.

Рубрика Программирование, компьютеры и кибернетика
Вид контрольная работа
Язык русский
Дата добавления 28.03.2018
Размер файла 1,0 M

Отправить свою хорошую работу в базу знаний просто. Используйте форму, расположенную ниже

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

Размещено на http://www.allbest.ru/

Контрольная работа

Интеграция информационных систем предприятия

Содержание

1. Взаимосвязь информационных подсистем предприятия

2. Сервис-ориентированная архитектура ИС

3. Реализация SOA-инфраструктуры на базе сервисной шины предприятия

Литература

1. Взаимосвязь информационных подсистем предприятия

Каким образом связаны информационные системы внутри предприятия? Обычный путь для российской компании средних размеров - начинать внедрение информационных технологий с автоматизации работы бухгалтерии, отдела кадров и документооборота. Данные этих систем наиболее формализованы, процессы легко автоматизируются. Широко распространенные пакеты "1C: Бухгалтерия", "Босс: Кадровик", СЭД "ЕВФРАТ" и др. позволяют наращивать себя любыми приложениями и, таким образом, интегрировать их в общую информационную систему предприятия. Рис. 1 показывает, каким образом модули информационной системы предприятия связаны друг с другом. Модуль TPS обслуживает основные производственные и вспомогательные процессы, и обычно это главный источник для других информационных модулей. ESS - главный получатель данных и внутренних систем из внешней среды.

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

Рис. 1. Взаимодействие модулей ИС

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

Связи между DSS и совокупностью TPS, KWS, MIS намеренно показаны неопределенными. Иногда DSS тесно связана с другими подсистемами. Но это только в том случае, если предприятие отличается высокой степенью автоматизации всех процессов. Обычно подсистема DSS изолирована от основных производственных информационных систем и использует их данные и информационные потоки для работы своих аналитических систем.

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

2. Сервис-ориентированная архитектура ИС

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

В настоящее время при формировании информационной инфраструктуры предприятия, при проектировании и реализации КИС все чаще применяется сервис-ориентированная архитектура (Service-Oriented Architecture - SOA). Это такая архитектура ИС, в которой система строится из набора гетерогенных (состоящий из различных по составу, свойствам, происхождению частей; неоднородный) слабосвязанных компонентов (сервисов). SOA понимается как парадигма (греч. «пример, модель, образец» -- совокупность фундаментальных научных установок, представлений и терминов, принимаемая и разделяемая научным сообществом и объединяющая большинство его членов) организации и как использование распределенного множества функций, которые могут контролироваться различными владельцами. Базовыми понятиями в такой архитектуре являются "информационная услуга" и "композитное приложение".

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

Сервис обычно характеризуется следующими свойствами:

возможность многократного применения;

услуга может быть определена одним или несколькими технологически независимыми интерфейсами;

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

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

Использование такого подхода при построении архитектуры сложных интегрированных информационных систем позволяет:

создать систему корпоративных композитных приложений, основанных на системе корпоративных Web-сервисов;

организовать интеграцию приложений, бизнес-процессов, с автоматизацией бизнес-процессов;

использовать различные транспортные протоколы и стандарты форматирования сообщений, средства обеспечения безопасности, надежной и своевременной доставки сообщений;

существенно повысить скорость разработки прикладных приложений и снизить затраты на эти цели.

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

Обязательным условием построения и внедрения архитектуры системы на основе SOA является использование единой инфраструктуры описания сервисов (репозитория сервисов), разрешенных протоколов доступа и обмена сообщениями, форматов сообщений.

Упомянутая инфраструктура образует так называемую интеграционную шину (ИШ) (Enterprise Service Bus - ESB), являющуюся одним из центральных компонентов системы. Она устанавливает единые правила публикации сервисов, управления и информационного взаимодействия между приложениями различных систем, входящих в состав интегрированной системы. Это упрощает управление приложениями и их поддержку, а также снижает риск фрагментации приложений и процессов.

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

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

Изменение и совершенствование бизнес-процессов в компаниях занимает годы. По данным Gartner Group, 80% ИТ-бюджета - это расходы на сопровождение систем, из них 35% - затраты на интеграцию приложений, 60% стоимости внедрения корпоративной ИС составляют расходы на интеграцию, 50% ИТ-бюджета тратится на обеспечение интерфейсов систем. Использование SOA-архитектуры позволяет эффективно организовать оперативную адаптацию ИТ-систем под требования бизнеса, что дает стратегическое преимущество компании, выражающееся в следующем:

повышение скорости адаптации бизнеса к быстро меняющимся требованиям рынка (Agility);

расширение взаимодействия гетерогенных корпоративных информационных систем при сохранении сделанных в них инвестиций;

сокращение расходов на ИТ-системы на основе повторного использования их функциональных компонентов;

повышение производительности труда клиентов, партнеров и сотрудников.

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

Основные бизнес-цели внедрения SOA-решений состоят в ликвидации:

фрагментированности и дублирования данных;

дублирования реализаций бизнес-функций, процедур, процессов;

негибкой архитектуры.

Становление и развитие SOA происходило на базе практических требований бизнеса, заключавшихся прежде всего в разумной экономии программных и технологических средств и затрат на реализацию и сопровождение информационной инфраструктуры:

обеспечивать преемственность инвестиций в IT, сохранить существующие информационные системы и их совместное эффективное использование для повышения ROI (финансовый коэффициент, иллюстрирующий уровень доходности или убыточности бизнеса, учитывая сумму сделанных в этот бизнес инвестиций) от IT-вложений;

обеспечивать реализацию различных типов интеграции:

пользовательская интеграция - обеспечение взаимодействия информационной системы с конкретным персонифицированным пользователем; информационный подсистема архитектура бизнес

интеграция приложений - обеспечение взаимодействия приложений;

интеграция процессов - интеграция процессов в соответствии с бизнес-логикой деятельности предприятия;

информационная интеграция - интеграция с целью обеспечения доступности информации и данных;

интеграция новых приложений - интеграция новых приложений и сервисов в существующие информационные системы.

обеспечивать поэтапность внедрения вновь созданных и миграции существующих информационных систем;

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

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

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

3. Реализация SOA-инфраструктуры на базе сервисной шины предприятия

Аппаратно-программную платформу, реализующую инфраструктуру КИС с SOA-архитектурой называют сервисной шины предприятия (ESB). ESB-шина образует однородную среду информационного взаимодействия внутрикорпоративных (intranet-) и внешних (extranet-) приложений и является фундаментом для их интеграции (рис. 2). Она определяет, кем, где, каким образом, и в каком порядке должны обрабатываться запросы на сервисное обслуживание времени выполнения.

Рис. 2. Общая схема ESB-шины

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

Уровень ESB можно сформировать на основе нескольких топологий интеграции служб в зависимости от функциональных и нефункциональных требований. Для некоторых ситуаций вполне подходит топология, состоящая всего из одной системы обмена сообщениями (рис. 3).

Рис. 3. Топология «одна шина, один сервер»

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

Рис. 4. Топология «одна шина, несколько серверов»

ESB-шина устанавливает единые правила публикации сервисов, управления и информационного взаимодействия между приложениями различных систем, входящих в состав интегрированной системы. Это упрощает управление интегрированными приложениями и их поддержку, а также снижает риск фрагментации приложений и процессов. Важные инфраструктурные службы, которые входят в ESB, выполняют передачу данных, маршрутизацию, обеспечивающую качество услуг, посреднические функции и роль шлюзов. Каждая из служб взаимодействует не с остальными службами напрямую, а только с шиной. Таким образом, ESB _ это базовое промежуточное звено, способ связывания служб в компонентные логические наборы (рис. 4). Эти наборы отражают структуру бизнеса и предназначены для широкого распределенного использования в масштабе всего предприятия.

Шина ESB действует как логический, распределенный, транзакционный и управляющий сообщениями уровень для связывания приложений, разнотипных данных и других служб, которые распределены по вычислительной сети предприятия. Базовая роль магистрали для работы с синхронными и асинхронными сообщениями дополняется логическими возможностями трансформации и маршрутизации данных, что обеспечивает надежную передачу сообщений. ESB позволяет разработчикам вызывать и применять бизнес-функции, входящие в компоненты КИС, независимо от API (это интерфейс программирования, интерфейс создания приложений) или протокола, поскольку компоненты используются как службы, интерфейс которых имеет стандартное описание на языке Web Service Descrition Language (WSDL).

От развертывания систем на базе SOA пользователи получают следующие преимущества:

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

Упрощение и ускорение процесса разработки бизнес-приложений _ приложения строятся, как система взаимосвязанных компонентов и при этом используются наиболее подходящие компоненты из имеющихся на рынке;

Легкая интеграция новых функций в действующую корпоративную систему;

Возможность гибкого изменения и постоянного совершенствования бизнес-процессов предприятия;

Оптимизация процессов управления предприятием за счет упрощения процедур объединения информационных потоков и бизнес-процессов;

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

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

Этапы перехода к СОА

На предприятии переход к СОА состоит из трех этапов:

Создание сервисов. Подготовка всех существующих приложений к взаимодействию в рамках новой архитектуры и поиск или разработка недостающих сервисов.

Построение инфраструктуры сервис-ориентированной архитектуры.

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

Создание сервисов

Создание сервисов может происходить различными способами:

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

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

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

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

Осуществление поиска готовых сервисов. Сервис может быть уже доступен. Все больше и больше коробочных приложений предоставляют интерфейсы взаимодействия с ними, как с веб-сервисами. Большинство систем уровня предприятия (ERP, CRM) предоставляют программные интерфейсы приложений (API) для веб-сервисов;

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

Результат первого шага реализации СОА, должен поменять архитектуру взаимодействия существующих приложений, при которой появляется средний слой.

Построение инфраструктуры СОА

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

На рис. 5 под «кружочками» понимаются точки интеграции приложений, через которые идет взаимодействие систем между собой. На рис. 5а показаны взаимодействия приложений и систем без СОА, что требует использование специфических связей при каждом взаимодействии, т.е. для того, что бы связать n систем между собой нам необходимо n*(n-1) односторонних специфических связей. Очевидно, что изменение такой системы достаточно трудоемко и зачастую просто невозможно.

При наличии инфраструктуры СОА (рис. 5б) все точки взаимодействия находятся в одном пространстве взаимодействия, и поэтому не требуется наличие связей между системами, т.к. они работают независимо. При таком подходе нам надо написать в худшем случае не большее количество связей, но они качественно отличаются от связей без СОА. Данные связи описывают взаимодействие системы с абстрактной системой, что позволяет без особого труда перестраивать взаимодействие систем.

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

Использование СОА

Вместе с СОА процессы, представленные ниже, получают новое развитие, использование которых и называется правильное использование СОА:

- Бизнес-интеграция. Бизнес-интеграция становится максимально прозрачной для взаимодействующих сторон, что обусловлено наличием в СОА слабой связи приложение-приложение, т.е. приложения взаимодействуют не друг с другом напрямую, а через бизнес-процесс предприятия. Кроме того, однажды созданный и описанный сервис (бизнес-процесс) может участвовать в различных проявлениях как внутри, так и вне предприятия;

- Управление бизнес-процессами (Business Process Management, BPM). СОА позволяет существовать предприятию как управляемый бизнес-процесс. Что достигается за счет максимального сближения информационных технологий и бизнес-процессов предприятия. Т.е. сервис становится просто реализацией какого-то процесса, который может выступать как часть общего процесса предприятия (что чаще всего и встречается, т.к. все процессы предприятия подчинены одной цели), а также может участвовать как отдельная законченная функциональная единица.

- Отслеживание активности бизнеса (Business Activity Monitoring, BAM). Постоянное отслеживание процессов позволяет максимально быстро выявлять проблемы и реагировать на них. BAM, как и BPM, в большой степени зависят от правильности построения СОА инфраструктуры. При правильно построенной инфраструктуре некачественные процессы будут выпадать из стройной картины бизнеса в целом, что только ускорит реакцию предприятия на изменение таких процессов.

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

«Советские» предприятия

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

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

Литература

1. Б.Б.Желваков. ИТ-инфраструктура предприятия (конспект лекций). СПбГЭУ. - 2014

Дополнительная литература

1. Абросимова, М.А. Информационные технологии в государственном и муниципальном управлении: Учебное пособие / М.А. Абросимова. - М.: КноРус, 2013. - 248 c.

2. Акперов, И.Г. Информационные технологии в менеджменте: Учебник / И.Г. Акперов, А.В. Сметанин, И.А. Коноплева. - М.: НИЦ ИНФРА-М, 2013. - 400 c.

3. Атьков, О.Ю. Персональная телемедицина. Телемедицинские и информационные технологии реабилитации и управления здоровьем / О.Ю. Атьков, Ю.Ю. Кудряшов. - М.: Практика, 2015. - 248 c.

4. Афонин, П.Н. Информационные таможенные технологии: Учебник / П.Н. Афонин. - СПб.: Троицкий мост, 2012. - 352 c.

5. Балдин, К.В. Информационные технологии в менеджменте: Учеб. для студ. учреждений высш. проф. образования / К.В. Балдин. - М.: ИЦ Академия, 2012. - 288 c.

6. Барский, А.В. Параллельные информационные технологии: Учебное пособие / А.В. Барский. - М.: Бином, 2013. - 503 c.

7. Бартенев, В.А. Современные и перспективные информационные ГНСС-технологии в задачах высокоточной навигации / В.А. Бартенев, М.Н. Красильщиков. - М.: Физматлит, 2014. - 192 c.

8. Вдовин, В.М. Информационные технологии в налогообложении: Учебное пособие / В.М. Вдовин, Л.Е. Суркова, А.В. Смирнова. - М.: Дашков и К, 2012. - 208 c.

9. Вдовин, В.М. Информационные технологии в налогообложении: Практикум / В.М. Вдовин, Л.Е. Суркова. - М.: Дашков и К, 2012. - 248 c.

10. Вдовин, В.М. Информационные технологии в финансово-банковской сфере: Практикум / В.М. Вдовин. - М.: Дашков и К, 2012. - 248 c.

11. Вдовин, В.М. Информационные технологии в налогообложении: Практикум / В.М. Вдовин, Л.Е. Суркова. - М.: Дашков и К, 2014. - 248 c.

12. Вдовин, В.М. Информационные технологии в финансово-банковской сфере: Учебное пособие / В.М. Вдовин, Л.Е. Суркова. - М.: Дашков и К, 2016. - 304 c.

13. Вдовин, В.М. Информационные технологии в финансово-банковской сфере: Учебное пособие / В.М. Вдовин, Л.Е. Суркова. - М.: Дашков и К, 2013. - 304 c.

14. Вдовин, В.М. Информационные технологии в финансово-банковской сфере: Практикум / В.М. Вдовин, Л.Е. Суркова. - М.: Дашков и К, 2012. - 248 c.

15. Вдовин, В.М. Информационные технологии в финансово-банковской сфере.Учебное пособие / В.М. Вдовин, Л.Е. Суркова. - М.: Дашков и К, 2012. - 304 c.

16. Венделева, М.А. Информационные технологии в управлении: Учебное пособие для бакалавров / М.А. Венделева, Ю.В. Вертакова. - М.: Юрайт, 2013. - 462 c.

17. Венделева, М.А. Информационные технологии в управлении.: Учебное пособие для бакалавров / М.А. Венделева, Ю.В. Вертакова. - Люберцы: Юрайт, 2016. - 462 c.

18. Гаврилов, Л.П. Информационные технологии в коммерции: Учебное пособие / Л.П. Гаврилов. - М.: НИЦ ИНФРА-М, 2013. - 238 c.

19. Гаврилов, М.В. Информатика и информационные технологии: Учебник для бакалавров / М.В. Гаврилов, В.А. Климов; Рецензент Л.В. Кальянов, Н.М. Рыскин. - М.: Юрайт, 2013. - 378 c.

Размещено на Allbest.ru


Подобные документы

  • Ознакомление с проблемами реализации сервис-ориентированной архитектуры предприятия. Анализ активных элементов бизнес-архитектуры. Рассмотрение инструментов реализации языка ArchiMate в программном средстве Archi. Исследование мотивационных концепций.

    курсовая работа [2,0 M], добавлен 25.08.2017

  • Методология структурного анализа и проектирования информационных систем. Базовый стандарт процессов жизненного цикла программного обеспечения. Цели и принципы формирования профилей информационных систем. Разработка идеальной модели бизнес-процессов.

    презентация [152,1 K], добавлен 07.12.2013

  • Области применения и реализации информационных систем. Анализ использования Web-технологий. Создание физической и логической модели данных. Проектирование информационных систем с Web-доступом. Функции Института Искусств и Информационных Технологий.

    дипломная работа [3,8 M], добавлен 23.09.2013

  • Цели и задачи информационных систем (ИС). Выбор, требования, оценка эффективности внедрения ИС. Оценка эффективности внедрения ИС. ERP-cистема управления бизнес-процессами промышленного предприятия. Сравнение ERP-системы LAWSON M3.

    реферат [518,9 K], добавлен 07.08.2007

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

    презентация [158,5 K], добавлен 06.09.2015

  • Факторы угроз сохранности информации в информационных системах. Требования к защите информационных систем. Классификация схем защиты информационных систем. Анализ сохранности информационных систем. Комплексная защита информации в ЭВМ.

    курсовая работа [30,8 K], добавлен 04.12.2003

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

    отчет по практике [1,7 M], добавлен 11.09.2011

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

    реферат [26,4 K], добавлен 22.06.2011

  • Жизненный цикл информационных систем, методологии и технологии их проектирования. Уровень целеполагания и задач организации, классификация информационных систем. Стандарты кодирования, ошибки программирования. Уровни тестирования информационных систем.

    презентация [490,2 K], добавлен 29.01.2023

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

    курсовая работа [32,0 K], добавлен 16.10.2013

Работы в архивах красиво оформлены согласно требованиям ВУЗов и содержат рисунки, диаграммы, формулы и т.д.
PPT, PPTX и PDF-файлы представлены только в архивах.
Рекомендуем скачать работу.