Лекции по "Информационным системам"

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

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

 Тема 4. Фактографические системы: предметная область(ПО), концептуальные средства описания, модель сущность-связь. Модели данных. Представление данных в памяти ЭВМ. Программные средства реализации фактографических ИС.

1. Общие сведения о моделировании предметной области

 Концептуальное  проектирование является ядром всего  процесса проектирования БД. Подходы к концептуальному проектированию. Реализованные в разнообразных CASE-системах, отличаются друг от друга. Процессы концептуального моделирования чаще всего реализуются в среде DESIGN/IDEF и ERWin.

 

• Уточнение понятия концептуальной модели.

 Часть реального мира, представляющая интерес  для данного исследования, называется предметной областью. Для того, чтобы  БД адекватно отражала предметную область, проектировщик должен хорошо представлять себе все нюансы и уметь отобразить их в БД. Предметная область должна быть предварительно описана. Чаще используют искусственные формализованные языковые средства. Формализованное описание предметной области называется ее концептуальной моделью. Моделирование ПредОб выполняется с различными целями (реинжиниринг, прогнозирование, при проектировании БД и ПО). Подходы к проектированию БД различных классов будет существенно отличаться. Особый интерес представляют структурированные БД.

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

 

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

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

 Эти модели представляют собой графические  описания предметных областей в терминах «объект-свойство-связь» и являются элементами концептуальных моделей, имея целый ряд преимуществ, главными из которых является отсутствие привязки к конкретной СУБД. Существует большое число нотаций и методик построения . ER—моделей. В предметной области существует множество разнообразных объектов, под которыми понимают некие сущности, о которых собирается информация. Классом объектов называется совокупность объектов, обладающих одинаковым набором свойств. Объекты могут быть реальными и абстрактными. ER—модель строится на уровне классов объектов, а не экземпляров объектов. Каждому классу объектов присваивается уникальное имя. Именем класса объектов является грамматический оборот существительного. Если в предметной области имеет место синонимия, все имена следует зафиксировать и лишь одно выбрать за основное. Помимо имени классов может использоваться кодовое обозначение. Желательно дать интерпретацию каждой сущности. Уникальное имя экземпляра объекта будем называть идентификатором (ИО).

 

 Рис.1. Компоненты концептуальной модели.

 

• Разновидности объектов

 Объект  называется простым, если он рассматривается в данном исследовании как неделимый.

 Сложный объект представляет собой объединение  других объектов, простых и сложных, также объединяемых в ИС.

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

 Агрегированные  объекты соответствуют какому-либо процессу, в который оказываются  вовлечены другие объекты.

 

• Логическая  структура экономической информации

 Экономическая информация носит дискретный характер и может быть структурирована.Важнейшие виды структурных единиц информации:

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

 Составная единица информации – логически  взаимосвязанная совокупность реквизитов

 Показатель  – минимальная СЕИ, сохраняющая  информативность

 Документ  – СЕИ, представленная на бумажном носителе, имеющая самостоятельное значение.

 Реквизит-признак  – содержит качественную характеристику сущности, позволяющую идентифицировать объект

 Реквизит-основание  содержит количественную характеристику объекта, определяющую его состояние.

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

 Семантический анализ позволяет выявить функциональную зависимость реквизитов и выполнить  на этой основе структурирование экономической  информации. Такое структурирование позволяет построить информационно-логическую модель предметной области и осуществить проектирование БД

 Лекции 1-4

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

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

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

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

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

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

 

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


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

 В автоматических ИС все операции по переработке информации выполняются без участия человека.

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

 В зависимости  от характера обработки данных ИС делятся на информационно-поисковые и информационно-решающие

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

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

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

 В зависимости  от сферы применения различают следующие классы ИС.

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

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

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

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

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


 Таблица 1.

Таблица 1. Функциональное назначение модулей корпоративной ИС.  Подсистема  маркетинга  Производственные  подсистемы  Финансовые  и учетные подсистемы  Подсистема  кадров (человеческих ресурсов)  Прочие  подсистемы (например, ИС руководства)  Исследование  рынка и прогнозирование продаж  Планирование  объемов работ и разработка календарных планов  Управление  портфелем заказов  Анализ  и прогнозирование потребности  в трудовых ресурсах  Контроль  за деятельностью фирмы  Управление  продажами  Оперативный контроль и управление производством  Управление  кредитной политикой  Ведение архивов записей о персонале  Выявление оперативных проблем  Рекомендации  по производству новой продукции  Анализ  работы оборудования  Разработка  финансового плана  Анализ  и планирование подготовки кадров  Анализ  управленческих и стратегических ситуаций  Анализ  и установление цены  Участие в формировании заказов поставщикам  Финансовый  анализ и прогнозирование     Обеспечение процесса выработки стратегических решений  Учет  заказов  Управление  запасами  Контроль  бюджета, бухгалтерский учет и расчет зарплаты

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

 В таблице 2 приведен перечень наиболее популярных в настоящее время программных продуктов для реализации ИС организационного управления различных классов.

 Таблица 2

Таблица 2. Классификация  рынка информационных систем
Локальные системы	Малые интегрированные  системы	Средние интегрированные  системы	Крупные интегрированные системы (IC)
БЭСТ Инотек Инфософт Супер-Менеджер Турбо-Бухгалтер Инфо-Бухгалтер	Concorde XAL Exact NS-2000 Platinum PRO/MIS Scala SunSystems БЭСТ-ПРО 1C-Предприятие БОСС-Корпорация Галактика Парус Ресурс Эталон	Microsoft-Business Solutions - Navision, Axapta D Edwards (Robertson & Blums) MFG-Pro (QAD/BMS) SyteLine (COKAП/SYMIX)	SAP/R3 (SAP AG) Baan (Baan) BPCS (ITS/SSA) Oracle Applications (oracle)

 Существует  классификация ИС в зависимости от уровня управления, на котором система используется.

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

 Задачи, цели, источники информации и алгоритмы  обработки на оперативном уровне заранее определены и в высокой  степени структурированы.

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

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

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

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

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

 С точки  зрения программно-аппаратной реализации можно выделить ряд типовых архитектур ИС.

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

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

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

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

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

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

 Согласно  статистическим данным, собранным Standish Group (США), из 8380 проектов, обследованных  в США в 1994 году, неудачными оказались более 30% проектов, общая стоимость которых превышала 80 миллиардов долларов. При этом оказались выполненными в срок лишь 16% от общего числа проектов, а перерасход средств составил 189% от запланированного бюджета.

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

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

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

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

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

 Проектирование ИС охватывает три основные области:

• проектирование объектов данных, которые будут реализованы в базе данных;
• проектирование программ, экранных форм, отчетов, которые будут обеспечивать выполнение запросов к данным;
• учет конкретной среды или технологии, а именно: топологии сети, конфигурации аппаратных средств, используемой архитектуры (файл-сервер или клиент-сервер), параллельной обработки, распределенной обработки данных и т.п.

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

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

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

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

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

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

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

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

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

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

 Конечными продуктами этапа проектирования являются:

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

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

• будет ли это архитектура "файл-сервер" или "клиент-сервер";
• будет ли это 3-уровневая архитектура со следующими слоями: сервер, ПО промежуточного слоя (сервер приложений), клиентское ПО;
• будет ли база данных централизованной или распределенной. Если база данных будет распределенной, то какие механизмы поддержки согласованности и актуальности данных будут использоваться;
• будет ли база данных однородной, то есть, будут ли все серверы баз данных продуктами одного и того же производителя (например, все серверы только Oracle или все серверы только DB2 UDB). Если база данных не будет однородной, то какое ПО будет использовано для обмена данными между СУБД разных производителей (уже существующее или разработанное специально как часть проекта);.
• будут ли для достижения должной производительности использоваться параллельные серверы баз данных (например, Oracle Parallel Server, DB2 UDB и т.п.).

 Этап  проектирования завершается разработкой  технического проекта ИС.

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

 Этап  тестирования обычно оказывается распределенным во времени.

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

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

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

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

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

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

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

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


   
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 


 


  Обобщенная схема  жизненного цикла  ЭИС

1. Системный анализа (до направления совершенствования объекта)

 К основным целям процесса относится  следующее:

• сформулировать потребность в новой ЭИС (идентифицировать все недостатки существующей ЭИС)
• выбрать направление и определить экономическую целесообразность проектирования ЭИС.

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

2. Системный синтез (от ФА до проекта системы)

 Процесс предполагает

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

 Этап  по составлению функциональной архитектуры (ФА) представляющей собой совокупность функциональных подсистем и связей между ними (блок 4) является наиболее ответственным с точки зрения качества всей последующей разработки

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

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

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

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

 4. Эксплуатация и  сопровождение проекта. На этой стадии (блоки 11-12) выполняются этапы: эксплуатация проекта системы и модернизация проекта ЭИС.

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

 Важной  чертой жизненного цикла ЭИС является его повторяемость. Это соответствует  представлению о ней как о  развивающейся динамической системе.

 Другой  характерной чертой ЖЦ является наличие нескольких циклов внутри схемы:

 Первый  цикл (1-12) цикл первичного проектирования

 Второй  цикл (7-8, 6-7) – цикл, который возникает после опытного внерения, в результате которого выявляются частные ошибки в элементах проекта, исправляемые, начиная с 6-го блока

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

 Четвертый цикл (блоки12, 5-12) возникает если требуется модификация системной архитектуры в связи с необходимостью адаптации проекта к новым условиям функционирования системы

 Пятый цикл (блоки 12, 1-120 возникает, если проект системы совершенно не соответствует требованиям, предъявляемым к организационно-экономической системе ввиду того, что осуществляется моральное его старение и требуется полное перепроектирование системы.

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

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


 Лекция 8 (БД: ПРОЕКТИРОВАНИЕ ИНФОРМАЦИОННЫХ СИСТЕМ)

1. Методология проектирования

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

 Основой для проектирования любой сложной  системы служит ее концептуальная модель.

 Определение. Концептуальную модель можно определить как результат абстрагирования части реального мира, которую моделируют ИС. Для обозначения «части реального мира» используют термин «предметная область»

 Методологии, которые используют для абстрагирования  предметной области, отражают специфику применения ИС. Одни из них – OLTP-системы (Online Transaction Processing) предназначены для хранения данных в реальном масштабе времени– OLAP(OnLine Analitical processing)используют в процессе управления бизнесом.

 Выделяют  два типа ИС. Одни из них сопровождают операционные (OLTP), а другие – аналитические (OLAP) базы данных.

 OLTP – базы хранят данные в реальном масштабе времени, т.е. мгновенно фиксируют события (отгрузку товара со склада).

 OLAP хранят «историю» изменения БД. Т.е. в них сохраняют данные OLTP – базы с какой-то конкретной периодичностью.

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

 Эти задачи решают с помощью систем поддержки  принятия решений (Decision Support System, DSS) на основе данных OLAP-баз. Этот тип ИС ориентирован на решение стратегических вопросов типа прогнозирования сбыта. Поэтому OLAP-системы никогда не оперируют данными реального времени.

 К системам поддержки принятия решений относят, например, Excel. Большинство средств разработки ИС содержат библиотеки классов или компонентов. Так в Borland Delphi есть компоненты DecisionCube.

 Системы поддержки решений масштаба предприятия  строят на серверных OLAP-средствах: Oracle Express Server, MS SQL Server 2000 Analysis Services, Hyperion Essbase и др.

 В дальнейшем мы будем рассматривать OLTP-базы данных (OLTP-системы).

 Кратко  охарактеризовать OLTP-базы данных можно так – это большие объемы структурированной информации.

 Несмотря  на упрощенность определения, следует подчеркнуть два аспекта:

• Регулярная однородность данных (структурированность)
• Большие объемы информации

 Второй  аспект определяет область применения БД – относительно развитые бизнес-структуры, или автоматизация бизнеса с  небольшим оборотом и узкой номенклатурой товара нецелесообразна.

 Для моделирования систем и сопровождаемых ими БД используют методологии IDEF0 (Integrated Definition Function Modeling) DFD и (Data Flow Diagrams).

 Выбор методологии проектирования зависит  от степени сложности моделируемого информационной системой объекта. Если это сложный объект, то в начале проектирования ИС желательно использовать IDEF0. В настоящее время эта методология действует в качестве федерального стандарта США.

 МЕТОДОЛОГИЯ IDEF0

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

 IDEF0 – это подмножество SADT (Structured Analysis and Design Technique). Изначально эта методология применялась для проектирования систем общего назначения.

 Суть  методологии IDEF0 на примере производства товара.

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

 В терминах IDEF0 моделируемое ИС производство представляется блоком и дугами, как показано на рис.

   
 
 
 
 
 
 
 
 
 


 Рис. 1. Базовые элементы IDEF0 – модели

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

 Правила интерпретации модели:

 Функциональный  блок (функция) преобразует входные объекты в выходные;

 Управление определяет, когда и как это преобразование может или должно произойти;

 Исполнитель осуществляет это преобразование.

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

 Каждый  блок IDEF0 – диаграммы может быть представлен несколькими блоками, соединенными интерфейсными дугами на диаграмме следующего уровня. Эти блоки представляют подфункции исходной функции. Каждый из подмодулей может быть декомпозирован аналогичным образом. Число уровней не ограничено, но рекомендуют на диаграмме использовать от 3 до 6 блоков.

 Анализ  объекта на основе построения его  IDEF0- модели является этапом, который должен предварять разработку ИС по следующим причинам:

• При ознакомлении строят модель «как есть», которая фиксирует бизнес-процессы и используемые ими информационные потоки
• Функциональная модель «как есть» позволяет увидеть информационно-перегруженные бизнес-процессы – узкие места обследуемого объекта
• На основании модели «как есть» строится модель «как будет», т.е. предложить более совершенную структуру организации (реинжиниринг);
• В процессе построения модели «как есть» выявляются бизнес-правила – положения, которые регламентируют процесс функционирования моделируемого объекта;
• IDEF0 – модель  -  это лучший способ совместно с заказчиком разработать модель функционировании его фирмы.

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

 Тот факт, что IDEF0-модель не разделяет потоки данных на материальные, управляющие и информационные приводит разработчиков к необходимости использования диаграммы ПОТОКОВ ДАННЫХ. Это можно делать после этапа составления IDEF0-модели, либо вместо него, в зависимости от сложности моделируемого объекта или предпочтений исполнителя.

 Лекция 9.

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

 ДИАГРАММЫ ПОТОКОВ ДАННЫХ

 При построении DFD –диаграмм используют следующие элементы:

• Поток данных – некая информация, которая требует обработки;
• Процесс – преобразование входных потоков данных в выходные в соответствии с определенным алгоритмом;
• Внешняя сущность – источник или приемник данных, который является внешним по отношению к предметной области;
• Хранилище данных (data storage)

 Внешняя сущность – это объект, который не принадлежит моделируемому объекту и обменивается с ним потоками данных. Это, как правило, потребитель услуг моделируемого объекта. На концептуальной схеме его именуют существительным.

 В общем  случае, сущность – это объект или концепция, которая в рамках конкретной предметной области существует самостоятельно.

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

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

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

   
 
 
 
 
 
 
 
 
 
 
 
 


 Рис. 2. Концептуальная модель работы риэлтерской  конторы 


 Как видно из концептуальной модели заключения договора, внешние сущности – это  потенциальные Арендатор и Владелец. Поскольку элементами концептуальной модели являются одноименные хранилища: Арендатор и Владелец, то можно усомниться в правильности определения внешних сущностей. Но, так как потенциальные Арендатор и Владелец могут быть таковыми лишь после заключения договора, то конфликтов с определением здесь нет. Другими словами, это разные сущности.

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

 Наличие на диаграмме процесса «Подготовить договор аренды» - это следствие  того, что черновик договора аренды готовит клерк, а менеджер принимает решение о заключении договора. Это повышает эффективность работы фирмы в целом.

 РОЛЬ  МЕТОДОЛОГИЙ В АНАЛИЗЕ МОДЕЛИРУЕМОГО  ОБЪЕКТА

 В результате анализа моделируемого ИС объекта  на основе построения IDEF0 и DFD- диаграмм:

 Определяют  главную функцию проектируемой системы: например, сопровождать аренду недвижимости;

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

 Например:

 Заключать договора аренды

 Сопровождать  хранение информации об объектах недвижимости

 Определяют  обрабатываемые бизнес процессами информационные потоки. Например, отправка договора менеджеру.

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

 Примечание: Потоки данных – это прообразы процедур приложения, а хранилища данных – таблиц БД.

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

 ОПРЕДЕЛЕНИЕ МОДУЛЕЙ И ПРОЕКТИРОВАНИЕ БД.

 На  данном этапе проектирования ИС:

• На основе анализа назначения потоков концептуальной модели определяют модули приложений, которые позволяют реализовать функции системы
• Проектируют концептуальную схему БД. Эта схема не зависит от конечной реализации БД и аппаратной платформы.

 При разработке ИС немаловажную роль играет выбор среды. Объектно-ориентированная  методология позволяет рассматривать  разработку прикладных систем, как  процесс их конструирования из готовых классов.

 Модули  проектируемого приложения можно определить на основе назначения потоков концептуальной модели.

 Проектирование  БД.

 Возникновение ситуаций «аномалия удаления» и  «аномалия добавления».

 Необходимость разделения данных.

 Модель  данных должна состоять из совокупности файлов.

 Разделение  данных обеспечивают следующие модели: иерархическая, сетевая, реляционная  и объектно-ориентированная. Они  по разному связывают данные таблиц данных.

 Структуры данных иерархической  и сетевой моделей

  В иерархической модели данные упорядочены как главные (родительские) и подчиненные (дочерние). Достоинством является простота описания предметных областей с иерархической структурой. НО поиск информации возможен только сверху вниз. Почему? Физическое представление логической структуры иерархических моделей в компьютере – это совокупность записей различных типов, каждая из которых ссылается только на следующую  
 
 
 
 
 
 
 


 Рис. 3. Связь данных в иерархической  модели 


 Лекция 3

 3.1.Классификация  банков данных

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

 3.1.1. Классификация баз данных

 Центральным компонентом банка данных является БД и большинство классификационных признаков относится именно к ней. По форме представления информации различают визуальные и аудиосистемы, а также системы мультимедиа. Эта классификация показывает, в каком виде информация хранится в БД и выдается пользователям. «Изображение» используется в широком смысле: текст, графика, фото, карты, анимационные изображения. Классификация способов представления информации – это самостоятельная проблема.

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

 Структурированные БД по типу использованной модели делятся  на иерархические, сетевые, реляционные, смешанные и мультимодельные. Классификация по типу модели распространяется не только на БД, но и на СУБД.

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

 В иерархических  и сетевых моделях между информационными  единицами (записями разных файлов) могут задаваться связи. Графическое представление иерархической модели представляет граф типа «дерево». Сетевая модель – граф типа «сеть». Входом в такую структуру может являться любая вершина.. Каждая вершина может иметь несколько порожденных и/или несколько исходных вершин. Между парой вершин может быть объявлено несколько связей. Подавляющее большинство СУБД поддерживает простые сетевые структуры, т.е. между каждой парой типов записей поддерживается отношение 1 :М. Направление и характер связи в сетевых моделях не являются очевидными. Как в случае иерархической модели, поэтому при изображении структуры БД направление связи должно быть указано. В сетевой модели с однотипными файлами каждый файл может служить входом в структуру. Пара связанных файлов называется набором. В наборе тот файл, от которого идет связь называется владельцем набора, а файл, к которому направлена эта связь – членом набора. Тип файла жестко не зафиксирован.

 Кроме сетевых моделей с однотипными  файлами существуют модели и с разнотипными файлами. В них различают основные (главные) и зависимые файлы. Вход в структуру возможен только через главные файлы. Связываться могут только записи разных типов.

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


 

 

 

   


   


   


 

 

   


 

   


   
 


 Рис.3.1.Схема  сетевой модели с однотипными  файлами 
 
 


 

 

   


 

   


   


 Рис.3.2. Схема сетевой модели с разнотипными файлами. (Г- главный файл, З- зависимый файл) 


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

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

 По  типу хранимой информации БД делятся  на документальные, фактографические и лексикографические.

 Среди документальных БД различают библиографические, реферативные и полнотекстовые.

 К лексикографическим БД относятся различные словари (классификаторы, многоязычные словари, словари основ слов и т.п.)

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

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

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

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

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

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

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

 3.2. Классификация СУБД

 Классификационные признаки:

1. По языкам общения СУБД делятся на открытые, замкнутые и смешанные. Открытые системы – это системы, в которых для обращения к БД используются универсальные языки программирования. Замкнутые системы имеют собственные языки общения с пользователями БнД
2. По числу уровней в архитектуре различают одноуровневые. двухуровневые и трехуровневые системы. Возможно и большее количество уровней. Под архитектурным уровнем СУБД понимают функциональный компонент, механизмы которого служат для поддержки некоторого уровня абстракции данных (логический и физический вровень, а также «взгляд» пользователя – внешний уровень). В литературе используются понятия «внешняя», «концептуальная» и «внутренняя» модель/уровень, «логический» и «физический» уровень, а также «внешняя схема», «подсхема» и т.п.. Понятие «схема» относится обычно к описанию соответствующего уровня описания данных.
3. По выполняемым функциям СУБД делятся на информационные и операционные. Информационные СУБД позволяют организовать хранение информации и доступ к ней. Для выполнения более сложной обработки необходимо писать специальные программы. Операционные СУБД выполняют достаточно сложную обработку (автоматически получать агрегированные показатели, не хранящиеся непосредственно в БД.
4. По сфере возможного применения различают универсальные и специализированные, обычно проблемно-ориентированные СУБД.

 СУБД  поддерживают разные типы данных. Набор  данных в разных СУБД отличается. Некоторые  СУБД позволяют разработчику добавлять  новые типы данных и новые операции над этими данными. Такие системы называются расширяемыми БД (РСБД). Дальнейшим развитием концепции РСБД являются системы объектно-ориентированных БД.

5. По мощности СУБД делятся на настольные и корпоративные. Для настольных характерны невысокие требования к техническим средствам, ориентация на конечного пользователя, низкая стоимость. Корпоративные – обеспечивают работу в распределенной среде, высокую производительность, поддержку коллективной работы при проектировании систем, имеют развитые средства администрирования и более широкие возможности поддержания целостности. Оба типа систем интенсивно развиваются.
6. По ориентации на преобладающую категорию пользователей можно выделить СУБД для разработчиков и для конечных пользователей. Системы первого класса должны иметь качественные компиляторы и позволять отчуждать создаваемые продукты, обладать развитыми средствами отладки и др. Основными требованиями, предъявляемыми к системам для конечного пользователя является удобство интерфейса, высокий уровень языковых средств, наличие интеллектуальных модулей подсказок, повышенная защита от непреднамеренных ошибок и т.п.
7. Разделение СУБД по поколениям.

 3.2.1. Общая характеристика  проблемы выбора  СУБД

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

 Факторы, характеризующие саму СУБД и средства ее окружения.

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

 Факторы, связанные с особенностями предполагаемого  использования.

 СУБД  являются сложными языково-программными продуктами. Для обоснованного выбора СУБД необходимо иметь список СУБД - претендентов с описанием их параметров. Характеристики рассматриваются с разной степенью детализации, в зависимости от стоящих задач. Необходимо определить набор свойств, которыми обязательно обладать выбираемая СУБД. Сначала осуществляется предварительный отбор СУБД по качественным параметрам, а уж потом по количественным. При определении временных характеристик СУБД речь обычно идет о тестах на быстродействие. Формальное тестирование заключается в том, что на некотором заданном наборе данных выполняются некоторые операции или наборы операций. Такое тестирование проводят разработчики либо специальные лаборатории. Функциональное тестирование состоит в том. Что исследуются характеристики СУБД при решении определенной прикладной задачи, для реализации которой и выполняется выбор СУБД. Требуется реализовать заданные функции.

 3.2.2. Факторы влияния  на выбор СУБД

1. Платформы, на которых функционирует СУБД
2. Совместимость, открытость, масштабируемость
3. Уровень языковых средств

 - трудоемкость изучения

 - трудоемкость создания

 - гибкость

 - мощность

 - наличие языков разного уровня

 4. Функциональные возможности

 5. Обеспечение безопасности

 6. Обеспечение целостности

 7. Удобство интерфейса.

 8. Требования к техническим средствам,  операционной среде

 9. Ограничения, накладываемые СУБД

 10. Возможность создания «отчуждаемых»  приложений

 11. Степень универсальности

 12. Локализация

 13. Качество документации

 14. Устойчивость  работы, отлаженность  системы

 15. Наличие средств автоматизации  проектирования. Трудоемкость проектирования.

 16. Стоимость

 17. Мода. Тенденция

 Сюда  же относятся фирма –разработчик, распространенность, условия поддержки.

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

 На  выбор СУБД будет влиять квалификация сотрудников и наличие предшествующих наработок.

 СПИСОК  ИНФОРМАЦИОННЫХ СИСТЕМ

Компания  Названия  основных продуктов  1С  1С:Предприятие  АиТ  АиТ:\Управление персоналом  Baan  Baan IV  Microsoft  Axapta, Attain  Oracle  Oracle Applications  1С:Рарус  1С:Рарус  R-Style Software Lab  RS-Balance  SAP  R/3  АйТи  БОСС Компания  Аплана (бывш. подразделение АйТи)  БОСС Корпорация  Галактика  Галактика  Инталев  Инталев:Корпоративные  финансы, Инталев:Управление финансами  Интеллект-Сервис  БЭСТ-ПРО  Интерфейс  iRenaissance.ERP  Корпоративные финансовые системы  IFS  Парус  Парус Корпорация

    Версия Project Expert 5.0 является наиболее  мощной и расширенной из семейства  систем Project Expert, предназначенных для разработки и финансового анализа стратегического плана развития предприятия.

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


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

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

 Ключевые  показатели деятельности предприятий, практикующих применение принципов  стратегического управления ИС, оказываются  лучше, чем у их конкурентов, не применяющих  этих принципов. По данным IT Governance Institute 32% компаний из списка “Fortunate 500” имели комитеты стратегического управления ИТ и еще 29% компаний стратегический план развития ИТ разрабатывался и утверждался на уровне совета директоров. С другой стороны, средним показателем среди компаний, не использующих современные подходы к управлению ИС, являлся 75% уровень провалов проектов развития ИС.

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

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

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


 

 Рис. 1. ИС в организации

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


 Постановка задачи

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

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

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

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

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

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

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

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

 Основные  требования к системе

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


 
1. Он должен обеспечивать передачу из ERP-системы  в систему РБУ всей информации, которая необходима для формирования отчетности в соответствии с российскими  стандартами: это проводки хозяйственных  операций и все элементы справочников, на которые имеются ссылки в проводках.
2. Он должен обеспечивать передачу из системы РБУ в ERP-систему информации из тех разделов учета, которые по тем или иным причинам ведутся в системе РБУ, а данные из них требуются для работы разделов, обслуживаемых в ERP-системе.
3. Он должен гарантировать полноту передаваемой информации с учетом возможного внесения изменений и дополнений в информационную базу.
4. Он не должен допускать повторной передачи ранее переданных данных, которые после передачи не подвергались изменениям, если пользователь не требует такой передачи сознательно.
5. В нем должна присутствовать процедура верификации переданной информации.
6. Для настройки механизма обмена (в идеале) должно быть достаточно введения соответствующих настроечных параметров; это не должно требовать модификации текстов программных модулей.

  
Варианты реализации

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

 В таблицы ERP-системы, содержащие информацию о  проводках и сопутствующую им аналитику, добавляются триггеры, обеспечивающие периодический опрос состояния  соответствующих таблиц на предмет  наличия или отсутствия изменений. Программа управления обменом резидентно присутствует в памяти, через ODBC-драйвер следя за состоянием этих триггеров; при обнаружении факта модификации данных она передает произошедшие изменения в систему РБУ. Аналогично происходит передача в обратном направлении данных по кадрам и зарплате. Преобразование проводок из формата их хранения в ERP-системе в формат системы РБУ может выполняться как процедурами обслуживания соответствующих триггеров, так и программой управления обменом.

 Для такого варианта организации обмена данными характерна высокая оперативность. Однако для его успешной реализации требуется подробная информация об организации данных в обеих системах на табличном уровне представления. Далеко не во всех случаях такая информация доступна стороннему разработчику. Поэтому наилучшие результаты при реализации такого варианта будут достигнуты в том гипотетическом случае, если система обмена данными будет создаваться совместными усилиями фирм-разработчиков объединяемых ERP-системы и системы РБУ.

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

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

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

 Еще один подход - использование системы  РБУ как OLE-сервера. Естественно, он применим только при условии, что  система РБУ может выступать  в таком качестве.

 Этот  подход потенциально способен обеспечить максимальную оперативность обмена (вплоть до режима реального времени). Для его функционирования потребуется резидентное присутствие в памяти программы управления обменом и приложения системы РБУ, выступающего в роли OLE-сервера.

 В тех  же случаях, когда ERP-система допускает  непосредственное обращение к OLE-серверу, отпадает необходимость в программе управления обменом.

 Варианты  для iRenaissance

 Применительно к ERP-системе iRenaissance компании Ross Systems, кроме перечисленных вариантов реализации механизма передачи данных, есть еще два способа выборки необходимой информации из базы iRenaissance. Это связано с тем, что данные о проводках одних и тех же хозяйственных операций существуют в iRenaissance в нескольких экземплярах. С момента их возникновения эти данные хранятся в специализированных таблицах того функционального модуля, где они создавались. Далее они поступают в таблицу промежуточного хранения модуля главной книги GL_POSTINGS и после процедуры обновления главной книги попадают собственно в таблицы главной книги. Соответственно и извлечь эти данные можно как из таблиц главной книги, так и из таблиц функциональных модулей.

 Одна  из попыток создания системы обмена данными iRenaissance с системой РБУ принадлежит компании Interface Ltd.. В качестве системы РБУ была выбрана "1С:Предприятие" фирмы 1С. На выбор здесь повлияли следующие факторы:

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

 Обмен данными между iRenaissance и "1С:Предприятие"

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

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

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

 Реализованный прототип системы обеспечивает двусторонний обмен данными между iRenaissance и "1С:Предприятие" . В состав передаваемых данных входят проводки хозяйственных операций; аналитика передаваемых проводок по клиентам, поставщикам, подразделениям, товарам; виды и курсы используемых в проводках валют. Протокол обмена данными обеспечивает выполнение следующих функций:

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

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

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

 В заключение отметим, что отработанные в рамках данного проекта алгоритмы преобразования данных можно использовать при создании систем обмена данными между другими ERP-системами и системами РБУ.

 ОСОБЕННОСТИ ИЗУЧЕНИЯ СИСТЕМ

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

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

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

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

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

 Для описания систем используются понятия состояния и потоков. Состояние системы характеризуется значениями признаков системы в данный момент времени. Потоки определяют скорость изменения значений признаков системы. Поведение системы - это изменение состояний системы во времени. 


   


       
 


   
 
 
 
 
 
 
 
 
 
 
 
 


       Окружающая  среда       


 Рис. 4. Система, ее входы-выходы и окружающая среда 


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

 1. Определение  границ системы в целом и  границ ее окружения.

 2. Установление  целей системы.

 3. Определение структуры программ (наборов мероприятий и задач) и построение матрицы «программы-элементы».

 4. Описание  управления системой.

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

 Все информационные системы (ИС) включают один и тот же набор компонентов (рис. 1):

• функциональные компоненты
• компоненты систем обработки данных
• организационные компоненты.

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

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


 Рис.5. Компоненты информационной системы. 


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

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

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

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

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

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

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

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

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

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

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

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


 Выводы.

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

 Развитие  информационных систем и технологий в  организации

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

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

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