Лекция №1
Информационные процессы в экономике
и объективная необходимость их автоматизации

Информационные процессы в экономике и проблемы информатизации общества в России
См. Романов А.Н., Одинцов Б.Е. Информационные системы в экономике.-М.: Вузовский учебник, 2006.-300с.; с. 5-11.
Общие понятия
Информационная деятельность в РФ регулируется законом №149-ФЗ от 27.06.06.
В настоящем Федеральном законе (статья 2) используются следующие основные понятия:
1) информация - сведения (сообщения, данные) независимо от формы их представления;
2) информационные технологии - процессы, методы поиска, сбора, хранения, обработки, предоставления, распространения информации и способы осуществления таких процессов и методов;
3) информационная система - совокупность содержащейся в базах данных информации и обеспечивающих ее обработку информационных технологий и технических средств;
4) информационно-телекоммуникационная сеть - технологическая система, предназначенная для передачи по линиям связи информации, доступ к которой осуществляется с использованием средств вычислительной техники;
5) обладатель информации - лицо, самостоятельно создавшее информацию либо получившее на основании закона или договора право разрешать или ограничивать доступ к информации, определяемой по каким-либо признакам;
6) доступ к информации - возможность получения информации и ее использования;
7) конфиденциальность информации - обязательное для выполнения лицом, получившим доступ к определенной информации, требование не передавать такую информацию третьим лицам без согласия ее обладателя;
8) предоставление информации - действия, направленные на получение информации определенным кругом лиц или передачу информации определенному кругу лиц;
9) распространение информации - действия, направленные на получение информации неопределенным кругом лиц или передачу информации неопределенному кругу лиц;
10) электронное сообщение - информация, переданная или полученная пользователем информационно-телекоммуникационной сети;
11) документированная информация - зафиксированная на материальном носителе путем документирования информация с реквизитами, позволяющими определить такую информацию или в установленных законодательством Российской Федерации случаях ее материальный носитель;
12) оператор информационной системы - гражданин или юридическое лицо, осуществляющие деятельность по эксплуатации информационной системы, в том числе по обработке информации, содержащейся в ее базах данных.
Информационное обеспечение является составной частью более широкого понятия информационных технологий. Информационное обеспечение чаще всего соотносится с организационно-управленческой и производственно-технологической сферой. Поэтому под информационным обеспечением будем понимать совокупность процессов сбора, обработки, хранения, анализа и выдачи информации, необходимой для обеспечения управленческой деятельности и технологических процессов.
В плане оперирования с информацией в процессах ее создания (порождения), сбора, выдачи и потребления важное значение имеет понятие документированной информации.
Под документированием информации в широком смысле слова можно понимать выделение единичной смысловой части информации (данных) но некоторой предметной области в общей ее массе, обособление этой части с приданием ему самостоятельной роли (имя, статус, реквизиты и т. п.). Процесс документирования превращает информацию в информационные ресурсы.
Таким образом, документирование информации подводит к одному из самых фундаментальных понятии в сфере информационного обеспечения — информационным системам.
1.2 Понятие экономической информационной системы. Классы ИС
Понятие информационной системы многогранно и имеет несколько определений и подходов, например, нормативно-правовое (закон №149-ФЗ). Опыт, практика создания и использования автоматизированных информационных систем в различных сферах деятельности позволяет дать более широкое и универсальное определение, которое полнее отражает все аспекты их сущности.
Под информационной системой понимается организованная совокупность программно-технических и других вспомогательных средств, технологических процессов и функционально-определенных групп работников, обеспечивающих сбор, представление и накопление информационных ресурсов в определенной предметной области, поиск и выдачу сведений, необходимых для удовлетворения информационных потребностей установленного контингента пользователей - абонентов системы.
Информационные системы, в которых представление, хранение и обработка информации осуществляются с помощью вычислительной техники, называются автоматизированными, или сокращенно АИС.
Информационные системы можно классифицировать по целому ряду различных признаков. В основу рассматриваемой классификации положены наиболее существенные признаки, определяющие функциональные возможности и особенности построения современных систем. В зависимости от объема решаемых задач, используемых технических средств, организации функционирования, информационные системы делятся на ряд групп (классов) (рис.1.1).
По типу хранимых данных ИС разделяются на фактографические, документальные и геоинформационные.
Фактографические ИС накапливают и хранят данные и виде множества экземпляров одного или нескольких типов структурных элементов (информационных объектов). Каждый из таких экземпляров структурных элементов или некоторая их совокупность отражают сведения по какому-либо факту, событию и т. д., отделенному (вычлененному) от всех прочих сведений и фактов. Структура каждого типа информационного объекта состоит из конечного набора реквизитов, отражающих основные аспекты и характеристики сведений для объектов данной предметной области. Комплектование информационной базы в фактографических ИС включает, как правило, обязательный процесс структуризации входной информации из документального источника. Структуризация при этом осуществляется через определение (выделение, вычленение) экземпляров информационных объектов определенного типа, информация о которых имеется в документе, и заполнение их реквизитов.
В документальных ИС единичным элементом информации является нерасчлененный на более мелкие элементы документ и информация при вводе (входной документ), как правило, не структурируется, или структурируется в ограниченном виде. Для вводимого документа могут устанавливаться некоторые формализованные позиции —дата изготовления, исполнитель, тематика и т. д.
В геоинформационных ИС данные организованы в виде отдельных информационных объектов (с определенным набором реквизитов), привязанных к общей электронной топографической основе (электронной карте).
Основываясь на степени автоматизации информационных процессов в системе управления фирмой, информационные системы делятся на ручные, автоматические и автоматизированные.
INCLUDEPICTURE "Учебник%20ОПС/1/1-1.gif" \* MERGEFORMATINET Рис. 1.1.  Класcификация информационных систем
Ручные ИС характеризуются отсутствием современных технических средств переработки информации и выполнением всех операций человеком.
В автоматических ИС все операции по переработке информации выполняются без участия человека.
Автоматизированные ИС предполагают участие в процессе обработки информации и человека, и технических средств, причем главная роль в выполнении рутинных операций обработки данных отводится компьютеру. Именно этот класс систем соответствует современному представлению понятия "информационная система".
В зависимости от характера обработки данных ИС делятся на информационно-поисковые и информационно-решающие.
Информационно-поисковые системы производят ввод, систематизацию, хранение, выдачу информации по запросу пользователя без сложных преобразований данных. (Например, ИС библиотечного обслуживания, резервирования и продажи билетов на транспорте, бронирования мест в гостиницах и пр.)
Информационно-решающие системы осуществляют, кроме того, операции переработки информации по определенному алгоритму. По характеру использования выходной информации такие системы принято делить на управляющие и советующие.
Результирующая информация управляющих ИС непосредственно трансформируется в принимаемые человеком решения. Для этих систем характерны задачи расчетного характера и обработка больших объемов данных. (Например, ИС планирования производства или заказов, бухгалтерского учета.)
Советующие ИС вырабатывают информацию, которая принимается человеком к сведению и учитывается при формировании управленческих решений, а не инициирует конкретные действия. Эти системы имитируют интеллектуальные процессы обработки знаний, а не данных. (Например, экспертные системы.)
В зависимости от сферы применения различают следующие классы ИС.
Информационные системы организационного управления - предназначены для автоматизации функций управленческого персонала как промышленных предприятий, так и непромышленных объектов (гостиниц, банков, магазинов и пр.).
Основными функциями подобных систем являются: оперативный контроль и регулирование, оперативный учет и анализ, перспективное и оперативное планирование, бухгалтерский учет, управление сбытом, снабжением и другие экономические и организационные задачи.
ИС управления технологическими процессами (ТП) - служат для автоматизации функций производственного персонала по контролю и управлению производственными операциями. В таких системах обычно предусматривается наличие развитых средств измерения параметров технологических процессов (температуры, давления, химического состава и т.п.), процедур контроля допустимости значений параметров и регулирования технологических процессов.
ИС автоматизированного проектирования (САПР) - предназначены для автоматизации функций инженеров-проектировщиков, конструкторов, архитекторов, дизайнеров при создании новой техники или технологии. Основными функциями подобных систем являются: инженерные расчеты, создание графической документации (чертежей, схем, планов), создание проектной документации, моделирование проектируемых объектов.
Интегрированные (корпоративные) ИС - используются для автоматизации всех функций фирмы и охватывают весь цикл работ от планирования деятельности до сбыта продукции. Они включают в себя ряд модулей (подсистем), работающих в едином информационном пространстве и выполняющих функции поддержки соответствующих направлений деятельности. Типовые задачи, решаемые модулями корпоративной системы, приведены в таблице 1.1.
Анализ современного состояния рынка ИС показывает устойчивую тенденцию роста спроса на информационные системы организационного управления. Причем спрос продолжает расти именно на интегрированные системы управления. Автоматизация отдельной функции, например, бухгалтерского учета или сбыта готовой продукции, считается уже пройденным этапом для многих предприятий.
В таблице 1.2 HYPERLINK "file:///C:\\ИСЭ\\Учебник%20ОПС\\1\\2.html" \l "table.1.2#table.1.2" приведен перечень наиболее популярных в настоящее время программных продуктов для реализации ИС организационного управления различных классов.
Существует классификация ИС в зависимости от уровня управления, на котором система используется.
Информационная система оперативного уровня - поддерживает исполнителей, обрабатывая данные о сделках и событиях (счета, накладные, зарплата, кредиты, поток сырья и материалов). Информационная система оперативного уровня является связующим звеном между фирмой и внешней средой.
Задачи, цели, источники информации и алгоритмы обработки на оперативном уровне заранее определены и в высокой степени структурированы.
Информационные системы специалистов - поддерживают работу с данными и знаниями, повышают продуктивность и производительность работы инженеров и проектировщиков. Задача подобных информационных систем - интеграция новых сведений в организацию и помощь в обработке бумажных документов.
Информационные системы уровня менеджмента - используются работниками среднего управленческого звена для мониторинга, контроля, принятия решений и администрирования. Основные функции этих информационных систем:
сравнение текущих показателей с прошлыми;
составление периодических отчетов за определенное время, а не выдача отчетов по текущим событиям, как на оперативном уровне;
обеспечение доступа к архивной информации и т.д.
Стратегическая информационная система - компьютерная информационная система, обеспечивающая поддержку принятия решений по реализации стратегических перспективных целей развития организации.
Информационные системы стратегического уровня помогают высшему звену управленцев решать неструктурированные задачи, осуществлять долгосрочное планирование. Основная задача - сравнение происходящих во внешнем окружении изменений с существующим потенциалом фирмы. Они призваны создать общую среду компьютерной телекоммуникационной поддержки решений в неожиданно возникающих ситуациях. Используя самые совершенные программы, эти системы способны в любой момент предоставить информацию из многих источников. Некоторые стратегические системы обладают ограниченными аналитическими возможностями.
1.3 Типовые архитектуры ИС
С точки зрения программно-аппаратной реализации можно выделить ряд типовых архитектур ИС.
Традиционные архитектурные решения основаны на использовании выделенных файл-серверов или серверов баз данных. Существуют также варианты архитектур корпоративных информационных систем, базирующихся на технологии Internet (Intranet-приложения). Следующая разновидность архитектуры информационной системы основывается на концепции "хранилища данных" (DataWarehouse) - интегрированной информационной среды, включающей разнородные информационные ресурсы. И, наконец, для построения глобальных распределенных информационных приложений используется архитектура интеграции информационно-вычислительных компонентов на основе объектно-ориентированного подхода.
Индустрия разработки автоматизированных информационных систем управления зародилась в 1950-х - 1960-х годах и к концу века приобрела вполне законченные формы.
На первом этапе основным подходом в проектировании ИС был метод "снизу-вверх", когда система создавалась как набор приложений, наиболее важных в данный момент для поддержки деятельности предприятия. Основной целью этих проектов было не создание тиражируемых продуктов, а обслуживание текущих потребностей конкретного учреждения. Такой подход отчасти сохраняется и сегодня. В рамках "лоскутной автоматизации" достаточно хорошо обеспечивается поддержка отдельных функций, но практически полностью отсутствует стратегия развития комплексной системы автоматизации, а объединение функциональных подсистем превращается в самостоятельную и достаточно сложную проблему.
Создавая свои отделы и управления автоматизации, предприятия пытались "обустроиться" своими силами. Однако периодические изменения технологий работы и должностных инструкций, сложности, связанные с разными представлениями пользователей об одних и тех же данных, приводили к непрерывным доработкам программных продуктов для удовлетворения все новых и новых пожеланий отдельных работников. Как следствие - и работа программистов, и создаваемые ИС вызывали недовольство руководителей и пользователей системы.
Лекция №2
Методика создания информационных систем
управления экономической деятельностью
2.1 Методы программной инженерии в проектировании ИС
Следующий этап связан с осознанием того факта, что существует потребность в достаточно стандартных программных средствах автоматизации деятельности различных учреждений и предприятий. Из всего спектра проблем разработчики выделили наиболее заметные: автоматизацию ведения бухгалтерского аналитического учета и технологических процессов. Системы начали проектироваться "сверху-вниз", т.е. в предположении, что одна программа должна удовлетворять потребности многих пользователей.
Сама идея использования универсальной программы накладывает существенные ограничения на возможности разработчиков по формированию структуры базы данных, экранных форм, по выбору алгоритмов расчета. Заложенные "сверху" жесткие рамки не дают возможности гибко адаптировать систему к специфике деятельности конкретного предприятия: учесть необходимую глубину аналитического и производственно-технологического учета, включить необходимые процедуры обработки данных, обеспечить интерфейс каждого рабочего места с учетом функций и технологии работы конкретного пользователя. Решение этих задач требует серьезных доработок системы. Таким образом, материальные и временные затраты на внедрение системы и ее доводку под требования заказчика обычно значительно превышают запланированные показатели.
Согласно статистическим данным, собранным Standish Group (США), из 8380 проектов, обследованных в США в 1994 году, неудачными оказались более 30% проектов, общая стоимость которых превышала 80 миллиардов долларов. При этом оказались выполненными в срок лишь 16% от общего числа проектов, а перерасход средств составил 189% от запланированного бюджета.
В то же время, заказчики ИС стали выдвигать все больше требований, направленных на обеспечение возможности комплексного использования корпоративных данных в управлении и планировании своей деятельности.
Таким образом, возникла насущная необходимость формирования новой методологии построения информационных систем.
Цель такой методологии заключается в регламентации процесса проектирования ИС и обеспечении управления этим процессом с тем, чтобы гарантировать выполнение требований как к самой ИС, так и к характеристикам процесса разработки. Основными задачами, решению которых должна способствовать методология проектирования корпоративных ИС, являются следующие:
обеспечивать создание корпоративных ИС, отвечающих целям и задачам организации, а также предъявляемым требованиям по автоматизации деловых процессов заказчика;
гарантировать создание системы с заданным качеством в заданные сроки и в рамках установленного бюджета проекта;
поддерживать удобную дисциплину сопровождения, модификации и наращивания системы;
обеспечивать преемственность разработки, т.е. использование в разрабатываемой ИС существующей информационной инфраструктуры организации (задела в области информационных технологий).
Внедрение методологии должно приводить к снижению сложности процесса создания ИС за счет полного и точного описания этого процесса, а также применения современных методов и технологий создания ИС на всем жизненном цикле ИС - от замысла до реализации.
Проектирование ИС охватывает три основные области:
проектирование объектов данных, которые будут реализованы в базе данных;
проектирование программ, экранных форм, отчетов, которые будут обеспечивать выполнение запросов к данным;
учет конкретной среды или технологии, а именно: топологии сети, конфигурации аппаратных средств, используемой архитектуры (файл-сервер или клиент-сервер), параллельной обработки, распределенной обработки данных и т.п.
Проектирование информационных систем всегда начинается с определения цели проекта. В общем виде цель проекта можно определить как решение ряда взаимосвязанных задач, включающих в себя обеспечение на момент запуска системы и в течение всего времени ее эксплуатации:
требуемой функциональности системы и уровня ее адаптивности к изменяющимся условиям функционирования;
требуемой пропускной способности системы;
требуемого времени реакции системы на запрос;
безотказной работы системы;
необходимого уровня безопасности;
простоты эксплуатации и поддержки системы.
Согласно современной методологии, процесс создания ИС представляет собой процесс построения и последовательного преобразования ряда согласованных моделей на всех этапах жизненного цикла (ЖЦ) ИС. На каждом этапе ЖЦ создаются специфичные для него модели - организации, требований к ИС, проекта ИС, требований к приложениям и т.д. Модели формируются рабочими группами команды проекта, сохраняются и накапливаются в репозитории проекта. Создание моделей, их контроль, преобразование и предоставление в коллективное пользование осуществляется с использованием специальных программных инструментов - CASE-средств.
2.2 Этапы проектирования ИС
Процесс создания ИС делится на ряд этапов (стадий), ограниченных некоторыми временными рамками и заканчивающихся выпуском конкретного продукта (моделей, программных продуктов, документации и пр.).
Обычно выделяют следующие этапы создания ИС: формирование требований к системе, проектирование, реализация, тестирование, эксплуатация и сопровождение. (Последние два этапа далее не рассматриваются).
Начальным этапом процесса создания ИС является моделирование бизнес-процессов, протекающих в организации и реализующих ее цели и задачи. Модель организации, описанная в терминах бизнес-процессов и бизнес-функций, позволяет сформулировать основные требования к ИС. Это фундаментальное положение методологии обеспечивает объективность в выработке требований к проектированию системы. Множество моделей описания требований к ИС затем преобразуется в систему моделей, описывающих концептуальный проект ИС. Формируются модели архитектуры ИС, требований к программному обеспечению (ПО) и информационному обеспечению (ИО). Затем формируется архитектура ПО и ИО, выделяются корпоративные БД и отдельные приложения, формируются модели требований к приложениям и проводится их разработка, тестирование и интеграция.
Целью начальных этапов создания ИС, выполняемых на стадии анализа деятельности организации, является формирование требований к ИС, корректно и точно отражающих цели и задачи организации-заказчика. Чтобы специфицировать процесс создания ИС, отвечающей потребностям организации, нужно выяснить и четко сформулировать, в чем заключаются эти потребности. Для этого необходимо определить требования заказчиков к ИС и отобразить их на языке моделей в требования к разработке проекта ИС так, чтобы обеспечить соответствие целям и задачам организации.
Задача формирования требований к ИС является одной из наиболее ответственных, трудно формализуемых и наиболее дорогих и тяжелых для исправления в случае ошибки. Современные инструментальные средства и программные продукты позволяют достаточно быстро создавать ИС по готовым требованиям. Но зачастую эти системы не удовлетворяют заказчиков, требуют многочисленных доработок, что приводит к резкому удорожанию фактической стоимости ИС. Основной причиной такого положения является неправильное, неточное или неполное определение требований к ИС на этапе анализа.
На этапе проектирования прежде всего формируются модели данных. Проектировщики в качестве исходной информации получают результаты анализа. Построение логической и физической моделей данных является основной частью проектирования базы данных. Полученная в процессе анализа информационная модель сначала преобразуется в логическую, а затем в физическую модель данных.
Параллельно с проектированием схемы базы данных выполняется проектирование процессов, чтобы получить спецификации (описания) всех модулей ИС. Оба эти процесса проектирования тесно связаны, поскольку часть бизнес-логики обычно реализуется в базе данных (ограничения, триггеры, хранимые процедуры). Главная цель проектирования процессов заключается в отображении функций, полученных на этапе анализа, в модули информационной системы. При проектировании модулей определяют интерфейсы программ: разметку меню, вид окон, горячие клавиши и связанные с ними вызовы.
Конечными продуктами этапа проектирования являются:
схема базы данных (на основании ER-модели, разработанной на этапе анализа);
набор спецификаций модулей системы (они строятся на базе моделей функций).
Кроме того, на этапе проектирования осуществляется также разработка архитектуры ИС, включающая в себя выбор платформы (платформ) и операционной системы (операционных систем). В неоднородной ИС могут работать несколько компьютеров на разных аппаратных платформах и под управлением различных операционных систем. Кроме выбора платформы, на этапе проектирования определяются следующие характеристики архитектуры:
будет ли это архитектура "файл-сервер" или "клиент-сервер";
будет ли это 3-уровневая архитектура со следующими слоями: сервер, программное обеспечение (ПО) промежуточного слоя (сервер приложений), клиентское ПО;
будет ли база данных централизованной или распределенной. Если база данных будет распределенной, то какие механизмы поддержки согласованности и актуальности данных будут использоваться;
будет ли база данных однородной, то есть, будут ли все серверы баз данных продуктами одного и того же производителя (например, все серверы только Oracle или все серверы только DB2 UDB). Если база данных не будет однородной, то какое ПО будет использовано для обмена данными между СУБД разных производителей (уже существующее или разработанное специально как часть проекта);.
будут ли для достижения должной производительности использоваться параллельные серверы баз данных (например, Oracle Parallel Server, DB2 UDB и т.п.).
Этап проектирования завершается разработкой технического проекта ИС.
На этапе реализации осуществляется создание программного обеспечения системы, установка технических средств, разработка эксплуатационной документации.
Этап тестирования обычно оказывается распределенным во времени.
После завершения разработки отдельного модуля системы выполняют автономный тест, который преследует две основные цели:
обнаружение отказов модуля (жестких сбоев);
соответствие модуля спецификации (наличие всех необходимых функций, отсутствие лишних функций).
После того как автономный тест успешно пройдет, модуль включается в состав разработанной части системы и группа сгенерированных модулей проходит тесты связей, которые должны отследить их взаимное влияние.
Далее группа модулей тестируется на надежность работы, то есть проходят, во-первых, тесты имитации отказов системы, а во-вторых, тесты наработки на отказ. Первая группа тестов показывает, насколько хорошо система восстанавливается после сбоев программного обеспечения, отказов аппаратного обеспечения. Вторая группа тестов определяет степень устойчивости системы при штатной работе и позволяет оценить время безотказной работы системы. В комплект тестов устойчивости должны входить тесты, имитирующие пиковую нагрузку на систему.
Затем весь комплект модулей проходит системный тест - тест внутренней приемки продукта, показывающий уровень его качества. Сюда входят тесты функциональности и тесты надежности системы.
Последний тест информационной системы - приемо-сдаточные испытания. Такой тест предусматривает показ информационной системы заказчику и должен содержать группу тестов, моделирующих реальные бизнес-процессы, чтобы показать соответствие реализации требованиям заказчика.
Необходимость контролировать процесс создания ИС, гарантировать достижение целей разработки и соблюдение различных ограничений (бюджетных, временных и пр.) привело к широкому использованию в этой сфере методов и средств программной инженерии: структурного анализа, объектно-ориентированного моделирования, CASE-систем.
Этап тестирование завершается вводом системы в эксплуатацию.
2.3 Каноническое проектирование ИС
Организация канонического проектирования ИС ориентирована на использование главным образом каскадной модели жизненного цикла ИС. Стадии и этапы работы описаны в стандарте ГОСТ 34.601-90.
В зависимости от сложности объекта автоматизации и набора задач, требующих решения при создании конкретной ИС, стадии и этапы работ могут иметь различную трудоемкость. Допускается объединять последовательные этапы и даже исключать некоторые из них на любой стадии проекта. Допускается также начинать выполнение работ следующей стадии до окончания предыдущей.
Стадии и этапы создания ИС, выполняемые организациями-участниками, прописываются в договорах и технических заданиях на выполнение работ:
Стадия 1. Формирование требований к ИС.
На начальной стадии проектирования выделяют следующие этапы работ:
обследование объекта и обоснование необходимости создания ИС;
формирование требований пользователей к ИС;
оформление отчета о выполненной работе и тактико-технического задания на разработку.
Стадия 2. Разработка концепции ИС.
изучение объекта автоматизации;
проведение необходимых научно-исследовательских работ;
разработка вариантов концепции ИС, удовлетворяющих требованиям пользователей;
оформление отчета и утверждение концепции.
Стадия 3. Техническое задание.
разработка и утверждение технического задания на создание ИС.
Стадия 4. Эскизный проект.
разработка предварительных проектных решений по системе и ее частям;
разработка эскизной документации на ИС и ее части.
Стадия 5. Технический проект.
разработка проектных решений по системе и ее частям;
разработка документации на ИС и ее части;
разработка и оформление документации на поставку комплектующих изделий;
разработка заданий на проектирование в смежных частях проекта.
Стадия 6. Рабочая документация.
разработка рабочей документации на ИС и ее части;
разработка и адаптация программ.
Стадия 7. Ввод в действие.
подготовка объекта автоматизации;
подготовка персонала;
комплектация ИС поставляемыми изделиями (программными и техническими средствами, программно-техническими комплексами, информационными изделиями);
строительно-монтажные работы;
пусконаладочные работы;
проведение предварительных испытаний;
проведение опытной эксплуатации;
проведение приемочных испытаний.
Стадия 8. Сопровождение ИС.
выполнение работ в соответствии с гарантийными обязательствами;
послегарантийное обслуживание.
Oбследование- это изучение и диагностический анализ организационной структуры предприятия, его деятельности и существующей системы обработки информации. Материалы, полученные в результате обследования, используются для:
обоснования разработки и поэтапного внедрения систем;
составления технического задания на разработку систем;
разработки технического и рабочего проектов систем.
На этапе обследования целесообразно выделить две составляющие: определение стратегии внедрения ИС и детальный анализ деятельности организации.
Основная задача первого этапа обследования - оценка реального объема проекта, его целей и задач на основе выявленных функций и информационных элементов автоматизируемого объекта высокого уровня. Эти задачи могут быть реализованы или заказчиком ИС самостоятельно, или с привлечением консалтинговых организаций. Этап предполагает тесное взаимодействие с основными потенциальными пользователями системы и бизнес-экспертами. Основная задача взаимодействия - получить полное и однозначное понимание требований заказчика. Как правило, нужная информация может быть получена в результате интервью, бесед или семинаров с руководством, экспертами и пользователями.
По завершении этой стадии обследования появляется возможность определить вероятные технические подходы к созданию системы и оценить затраты на ее реализацию (затраты на аппаратное обеспечение, закупаемое программное обеспечение и разработку нового программного обеспечения ).
Результатом этапа определения стратегии является документ (технико-экономическое обоснование проекта), где четко сформулировано, что получит заказчик, если согласится финансировать проект, когда он получит готовый продукт (график выполнения работ) и сколько это будет стоить (для крупных проектов должен быть составлен график финансирования на разных этапах работ). В документе желательно отразить не только затраты, но и выгоду проекта, например время окупаемости проекта, ожидаемый экономический эффект (если его удается оценить).
Ориентировочное содержание этого документа:
ограничения, риски, критические факторы, которые могут повлиять на успешность проекта;
совокупность условий, при которых предполагается эксплуатировать будущую систему: архитектура системы, аппаратные и программные ресурсы, условия функционирования, обслуживающий персонал и пользователи системы;
сроки завершения отдельных этапов, форма приемки/сдачи работ, привлекаемые ресурсы, меры по защите информации;
описание выполняемых системой функций;
возможности развития системы;
информационные объекты системы;
интерфейсы и распределение функций между человеком и системой;
требования к программным и информационным компонентам ПО, требования к СУБД;
что не будет реализовано в рамках проекта.
На этапе детального анализа деятельности организации изучаются задачи, обеспечивающие реализацию функций управления, организационная структура, штаты и содержание работ по управлению предприятием, а также характер подчиненности вышестоящим органам управления. На этом этапе должны быть выявлены:
инструктивно-методические и директивные материалы, на основании которых определяются состав подсистем и перечень задач;
возможности применения новых методов решения задач.
Аналитики собирают и фиксируют информацию в двух взаимосвязанных формах:
функции - информация о событиях и процессах, которые происходят в бизнесе;
сущности - информация о вещах, имеющих значение для организации и о которых что-то известно.
При изучении каждой функциональной задачи управления определяются:
наименование задачи; сроки и периодичность ее решения;
степень формализуемости задачи;
источники информации, необходимые для решения задачи;
показатели и их количественные характеристики;
порядок корректировки информации;
действующие алгоритмы расчета показателей и возможные методы контроля;
действующие средства сбора, передачи и обработки информации;
действующие средства связи;
принятая точность решения задачи;
трудоемкость решения задачи;
действующие формы представления исходных данных и результатов их обработки в виде документов;
потребители результатной информации по задаче.
Одной из наиболее трудоемких, хотя и хорошо формализуемых задач этого этапа является описание документооборота организации. При обследовании документооборота составляется схема маршрута движения документов, которая должна отразить:
количество документов;
место формирования показателей документа;
взаимосвязь документов при их формировании;
маршрут и длительность движения документа;
место использования и хранения данного документа;
внутренние и внешние информационные связи;
объем документа в знаках.
По результатам обследования устанавливается перечень задач управления, решение которых целесообразно автоматизировать, и очередность их разработки.
На этапе обследования следует классифицировать планируемые функции системы по степени важности. Один из возможных форматов представления такой классификации - MuSCoW. Эта аббревиатура расшифровывается так: Must have - необходимые функции; Should have - желательные функции; Could have - возможные функции; Won't have - отсутствующие функции.
Функции первой категории обеспечивают критичные для успешной работы системы возможности.
Реализация функций второй и третьей категорий ограничивается временными и финансовыми рамками: разрабатывается то, что необходимо, а также максимально возможное в порядке приоритета число функций второй и третьей категорий.
Последняя категория функций особенно важна, поскольку необходимо четко представлять границы проекта и набор функций, которые будут отсутствовать в системе.
Модели деятельности организации создаются в двух видах:
модель "как есть"("as-is")- отражает существующие в организации бизнес-процессы;
модель "как должно быть"("to-be") - отражает необходимые изменения бизнес-процессов с учетом внедрения ИС.
На этапе анализа необходимо привлекать к работе группы тестирования для решения следующих задач:
получения сравнительных характеристик предполагаемых к использованию аппаратных платформ, операционных систем, СУБД, иного окружения;
разработки плана работ по обеспечению надежности информационной системы и ее тестирования.
Привлечение тестировщиков на ранних этапах разработки является целесообразным для любых проектов. Если проектное решение оказалось неудачным и это обнаружено слишком поздно (на этапе разработки или, что еще хуже, на этапе внедрения в эксплуатацию), то исправление ошибки проектирования обходится очень дорого. Чем раньше группы тестирования выявляют ошибки в информационной системе, тем ниже стоимость сопровождения системы. Время на тестирование системы и на исправление обнаруженных ошибок следует предусматривать не только на этапе разработки, но и на этапе проектирования.
Для автоматизации тестирования следует использовать системы отслеживания ошибок (bug tracking). Это позволяет иметь единое хранилище ошибок, отслеживать их повторное появление, контролировать скорость и эффективность исправления ошибок, видеть наиболее нестабильные компоненты системы, а также поддерживать связь между группой разработчиков и группой тестирования (уведомления об изменениях по e-mail и т.п.). Чем больше проект, тем сильнее потребность в bug tracking.
Результаты обследования представляют объективную основу для формирования технического задания на информационную систему.
Техническое задание- это документ, определяющий цели, требования и основные исходные данные, необходимые для разработки автоматизированной системы управления.
При разработке технического задания необходимо решить следующие задачи:
установить общую цель создания ИС, определить состав подсистем и функциональных задач;
разработать и обосновать требования, предъявляемые к подсистемам;
разработать и обосновать требования, предъявляемые к информационной базе, математическому и программному обеспечению, комплексу технических средств (включая средства связи и передачи данных);
установить общие требования к проектируемой системе;
определить перечень задач создания системы и исполнителей;
определить этапы создания системы и сроки их выполнения;
провести предварительный расчет затрат на создание системы и определить уровень экономической эффективности ее внедрения.
Эскизный проект предусматривает разработку предварительных проектных решений по системе и ее частям.
Выполнение стадии эскизного проектирования не является строго обязательной. Если основные проектные решения определены ранее или достаточно очевидны для конкретной ИС и объекта автоматизации, то эта стадия может быть исключена из общей последовательности работ.
Содержание эскизного проекта задается в ТЗ на систему. Как правило, на этапе эскизного проектирования определяются:
функции ИС;
функции подсистем, их цели и ожидаемый эффект от внедрения;
состав комплексов задач и отдельных задач;
концепция информационной базы и ее укрупненная структура;
функции системы управления базой данных;
состав вычислительной системы и других технических средств;
функции и параметры основных программных средств.
По результатам проделанной работы оформляется, согласовывается и утверждается документация в объеме, необходимом для описания полной совокупности принятых проектных решений и достаточном для дальнейшего выполнения работ по созданию системы.
На основе технического задания (и эскизного проекта) разрабатывается технический проект ИС. Технический проект системы - это техническая документация, содержащая общесистемные проектные решения, алгоритмы решения задач, а также оценку экономической эффективности автоматизированной системы управления и перечень мероприятий по подготовке объекта к внедрению.
На этом этапе осуществляется комплекс научно-исследовательских и экспериментальных работ для выбора основных проектных решений и расчет экономической эффективности системы.
В завершение стадии технического проектирования производится разработка документации на поставку серийно выпускаемых изделий для комплектования ИС, а также определяются технические требования и составляются ТЗ на разработку изделий, не изготовляемых серийно.
На стадии "рабочая документация" осуществляется создание программного продукта и разработка всей сопровождающей документации. Документация должна содержать все необходимые и достаточные сведения для обеспечения выполнения работ по вводу ИС в действие и ее эксплуатации, а также для поддержания уровня эксплуатационных характеристик (качества) системы. Разработанная документация должна быть соответствующим образом оформлена, согласована и утверждена.
Для ИС, которые являются разновидностью автоматизированных систем, устанавливают следующие основные виды испытаний: предварительные, опытная эксплуатация и приемочные. При необходимости допускается дополнительно проведение других видов испытаний системы и ее частей.
В зависимости от взаимосвязей частей ИС и объекта автоматизации испытания могут быть автономные или комплексные. Автономные испытания охватывают части системы. Их проводят по мере готовности частей системы к сдаче в опытную эксплуатацию. Комплексные испытания проводят для групп взаимосвязанных частей или для системы в целом.
Для планирования проведения всех видов испытаний разрабатывается документ "Программа и методика испытаний". Разработчик документа устанавливается в договоре или ТЗ. В качестве приложения в документ могут включаться тесты или контрольные примеры.
Предварительные испытания проводят для определения работоспособности системы и решения вопроса о возможности ее приемки в опытную эксплуатацию. Предварительные испытания следует выполнять после проведения разработчиком отладки и тестирования поставляемых программных и технических средств системы и представления им соответствующих документов об их готовности к испытаниям, а также после ознакомления персонала ИС с эксплуатационной документацией.
Опытную эксплуатацию системы проводят с целью определения фактических значений количественных и качественных характеристик системы и готовности персонала к работе в условиях ее функционирования, а также определения фактической эффективности и корректировки, при необходимости, документации.
Приемочные испытания проводят для определения соответствия системы техническому заданию, оценки качества опытной эксплуатации и решения вопроса о возможности приемки системы в постоянную эксплуатацию.
2. 4 Типовое проектирование ИС
Методы типового проектирования ИС достаточно подробно рассмотрены в литературе (Смирнова Г.Н., Сорокин А.А., Тельнов Ю.Ф. Проектирование экономических информационных систем М.: Финансы и статистика, 2002). В данной книге приведены основные определения и представлено задание для разработки проекта ИС методом типового проектирования (кейс "Проектирование ИС предприятия оптовой торговли лекарственными препаратами").
Типовое проектирование ИС предполагает создание системы из готовых типовых элементов. Основополагающим требованием для применения методов типового проектирования является возможность декомпозиции проектируемой ИС на множество составляющих компонентов (подсистем, комплексов задач, программных модулей и т.д.). Для реализации выделенных компонентов выбираются имеющиеся на рынке типовые проектные решения, которые настраиваются на особенности конкретного предприятия.
Типовое проектное решение (ТПР)- это тиражируемое (пригодное к многократному использованию) проектное решение.
Принятая классификация ТПР основана на уровне декомпозиции системы. Выделяются следующие классы ТПР:
элементные ТПР - типовые решения по задаче или по отдельному виду обеспечения задачи (информационному, программному, техническому, математическому, организационному);
подсистемные ТПР - в качестве элементов типизации выступают отдельные подсистемы, разработанные с учетом функциональной полноты и минимизации внешних информационных связей;
объектные ТПР - типовые отраслевые проекты, которые включают полный набор функциональных и обеспечивающих подсистем ИС.
Каждое типовое решение предполагает наличие, кроме собственно функциональных элементов (программных или аппаратных), документации с детальным описанием ТПР и процедур настройки в соответствии с требованиями разрабатываемой системы.
Реализация типового проекта предусматривает выполнение следующих операций:
установку глобальных параметров системы;
задание структуры объекта автоматизации;
определение структуры основных данных;
задание перечня реализуемых функций и процессов;
описание интерфейсов;
описание отчетов;
настройку авторизации доступа;
настройку системы архивирования.
2. 5 Структурный (функциональный) подход к проектированию ИС
В основе проектирования ИС лежит моделирование предметной области. Для того чтобы получить адекватный предметной области проект ИС в виде системы правильно работающих программ, необходимо иметь целостное, системное представление модели, которое отражает все аспекты функционирования будущей информационной системы. При этом под моделью предметной области понимается некоторая система, имитирующая структуру или функционирование исследуемой предметной области и отвечающая основному требованию – быть адекватной этой области.
Предварительное моделирование предметной области позволяет сократить время и сроки проведения проектировочных работ и получить более эффективный и качественный проект. Без проведения моделирования предметной области велика вероятность допущения большого количества ошибок в решении стратегических вопросов, приводящих к экономическим потерям и высоким затратам на последующее перепроектирование системы. Вследствие этого все современные технологии проектирования ИС основываются на использовании методологии моделирования предметной области.
К моделям предметных областей предъявляются следующие требования:
формализация, обеспечивающая однозначное описание структуры предметной области;
понятность для заказчиков и разработчиков на основе применения графических средств отображения модели;
реализуемость, подразумевающая наличие средств физической реализации модели предметной области в ИС;
обеспечение оценки эффективности реализации модели предметной области на основе определенных методов и вычисляемых показателей.
Для реализации перечисленных требований, как правило, строится система моделей, которая отражает структурный и оценочный аспекты функционирования предметной области.
Структурный аспект предполагает построение:
объектной структуры, отражающей состав взаимодействующих в процессах материальных и информационных объектов предметной области;
функциональной структуры, отражающей взаимосвязь функций (действий) по преобразованию объектов в процессах;
структуры управления, отражающей события и бизнес-правила, которые воздействуют на выполнение процессов;
организационной структуры, отражающей взаимодействие организационных единиц предприятия и персонала в процессах;
технической структуры, описывающей топологию расположения и способы коммуникации комплекса технических средств.
Для отображения структурного аспекта моделей предметных областей в основном используются графические методы, которые должны гарантировать представление информации о компонентах системы. Главное требование к графическим методам документирования — простота. Графические методы должны обеспечивать возможность структурной декомпозиции спецификаций системы с максимальной степенью детализации и согласований описаний на смежных уровнях декомпозиции.
С моделированием непосредственно связана проблема выбора языка представления проектных решений, позволяющего как можно больше привлекать будущих пользователей системы к ее разработке. Язык моделирования – это нотация, в основном графическая, которая используется для описания проектов. Нотация представляет собой совокупность графических объектов, используемых в модели. Нотация является синтаксисом языка моделирования. Язык моделирования, с одной стороны, должен делать решения проектировщиков понятными пользователю, с другой стороны, предоставлять проектировщикам средства достаточно формализованного и однозначного определения проектных решений, подлежащих реализации в виде программных комплексов, образующих целостную систему программного обеспечения.
Графическое изображение нередко оказывается наиболее емкой формой представления информации. При этом проектировщики должны учитывать, что графические методы документирования не могут полностью обеспечить декомпозицию проектных решений от постановки задачи проектирования до реализации программ ЭВМ. Трудности возникают при переходе от этапа анализа системы к этапу проектирования и в особенности к программированию.
Главный критерий адекватности структурной модели предметной области заключается в функциональной полноте разрабатываемой ИС.
Оценочные аспекты моделирования предметной области связаны с разрабатываемыми показателями эффективности автоматизируемых процессов, к которым относятся:
время решения задач;
стоимостные затраты на обработку данных;
надежность процессов;
косвенные показатели эффективности, такие, как объемы производства, производительность труда, оборачиваемость капитала, рентабельность и т.д.
Для расчета показателей эффективности, как правило, используются статические методы функционально-стоимостного анализа (ABC) и динамические методы имитационного моделирования.
В основе различных методологий моделирования предметной области ИС лежат принципы последовательной детализации абстрактных категорий. Обычно модели строятся на трех уровнях: на внешнем уровне (определении требований), на концептуальном уровне (спецификации требований) и внутреннем уровне (реализации требований). Так, на внешнем уровне модель отвечает на вопрос, что должна делать система, то есть определяется состав основных компонентов системы: объектов, функций, событий, организационных единиц, технических средств. На концептуальном уровне модель отвечает на вопрос, как должна функционировать система? Иначе говоря, определяется характер взаимодействия компонентов системы одного и разных типов. На внутреннем уровне модель отвечает на вопрос: с помощью каких программно-технических средств реализуются требования к системе? С позиции жизненного цикла ИС описанные уровни моделей соответственно строятся на этапах анализа требований, логического (технического) и физического (рабочего) проектирования. Рассмотрим особенности построения моделей предметной области на трех уровнях детализации.
Функциональные методики, наиболее известной из которых является методика IDEF, рассматривают организацию как набор функций, преобразующий поступающий поток информации в выходной поток. Процесс преобразования информации потребляет определенные ресурсы. Основное отличие от объектной методики заключается в четком отделении функций (методов обработки данных) от самих данных.
С точки зрения бизнес-моделирования каждый из представленных подходов обладает своими преимуществами. Объектный подход позволяет построить более устойчивую к изменениям систему, лучше соответствует существующим структурам организации. Функциональное моделирование хорошо показывает себя в тех случаях, когда организационная структура находится в процессе изменения или вообще слабо оформлена. Подход от выполняемых функций интуитивно лучше понимается исполнителями при получении от них информации об их текущей работе.
Функциональная методика IDEF0
Методологию IDEF0O можно считать следующим этапом развития хорошо известного графического языка описания функциональных систем SADT (Structured Analysis and Design Teqnique). Исторически IDEF0 как стандарт был разработан в 1981 году в рамках обширной программы автоматизации промышленных предприятий, которая носила обозначение ICAM (Integrated Computer Aided Manufacturing). Семейство стандартов IDEF унаследовало свое обозначение от названия этой программы (IDEF=Icam DEFinition), и последняя его редакция была выпущена в декабре 1993 года Национальным Институтом по Стандартам и Технологиям США (NIST).
Целью методики является построение функциональной схемы исследуемой системы, описывающей все необходимые процессы с точностью, достаточной для однозначного моделирования деятельности системы.
В основе методологии лежат четыре основных понятия: функциональный блок, интерфейсная дуга, декомпозиция, глоссарий.
Функциональный блок (Activity Box) представляет собой некоторую конкретную функцию в рамках рассматриваемой системы. По требованиям стандарта название каждого функционального блока должно быть сформулировано в глагольном наклонении (например, «производить услуги»). На диаграмме функциональный блок изображается прямоугольником (рис.2.1). Каждая из четырех сторон функционального блока имеет свое определенное значение (роль), при этом:
верхняя сторона имеет значение «Управление» (Control);
левая сторона имеет значение «Вход» (Input);
правая сторона имеет значение «Выход» (Output);
нижняя сторона имеет значение «Механизм» (Mechanism).
INCLUDEPICTURE "Учебник%20ОПС/6/6-1.gif" \* MERGEFORMATINET Рис. 2.1.  Функциональный блок
Интерфейсная дуга (Arrow) отображает элемент системы, который обрабатывается функциональным блоком или оказывает иное влияние на функцию, представленную данным функциональным блоком. Интерфейсные дуги часто называют потоками или стрелками.
С помощью интерфейсных дуг отображают различные объекты, в той или иной степени определяющие процессы, происходящие в системе. Такими объектами могут быть элементы реального мира (детали, вагоны, сотрудники и т.д.) или потоки данных и информации (документы, данные, инструкции и т.д.).
В зависимости от того, к какой из сторон функционального блока подходит данная интерфейсная дуга, она носит название «входящей», «исходящей» или «управляющей».
Необходимо отметить, что любой функциональный блок по требованиям стандарта должен иметь, по крайней мере, одну управляющую интерфейсную дугу и одну исходящую. Это и понятно – каждый процесс должен происходить по каким-то правилам (отображаемым управляющей дугой) и должен выдавать некоторый результат (выходящая дуга), иначе его рассмотрение не имеет никакого смысла.
Обязательное наличие управляющих интерфейсных дуг является одним из главных отличий стандарта IDEF0 от других методологий классов DFD (Data Flow Diagram) и WFD (Work Flow Diagram).
Декомпозиция (Decomposition) является основным понятием стандарта IDEF0. Принцип декомпозиции применяется при разбиении сложного процесса на составляющие его функции. При этом уровень детализации процесса определяется непосредственно разработчиком модели.
Декомпозиция позволяет постепенно и структурированно представлять модель системы в виде иерархической структуры отдельных диаграмм, что делает ее менее перегруженной и легко усваиваемой.
Последним из понятий IDEF0 является глоссарий (Glossary). Для каждого из элементов IDEF0 — диаграмм, функциональных блоков, интерфейсных дуг — существующий стандарт подразумевает создание и поддержание набора соответствующих определений, ключевых слов, повествовательных изложений и т.д., которые характеризуют объект, отображенный данным элементом. Этот набор называется глоссарием и является описанием сущности данного элемента. Глоссарий гармонично дополняет наглядный графический язык, снабжая диаграммы необходимой дополнительной информацией.
Модель IDEF0 всегда начинается с представления системы как единого целого – одного функционального блока с интерфейсными дугами, простирающимися за пределы рассматриваемой области. Такая диаграмма с одним функциональным блоком называется контекстной диаграммой.
В пояснительном тексте к контекстной диаграмме должна быть указана цель (Purpose) построения диаграммы в виде краткого описания и зафиксирована точка зрения (Viewpoint).
Определение и формализация цели разработки IDEF0-модели является крайне важным моментом. Фактически цель определяет соответствующие области в исследуемой системе, на которых необходимо фокусироваться в первую очередь.
Точка зрения определяет основное направление развития модели и уровень необходимой детализации. Четкое фиксирование точки зрения позволяет разгрузить модель, отказавшись от детализации и исследования отдельных элементов, не являющихся необходимыми, исходя из выбранной точки зрения на систему. Правильный выбор точки зрения существенно сокращает временные затраты на построение конечной модели.
Выделение подпроцессов. В процессе декомпозиции функциональный блок, который в контекстной диаграмме отображает систему как единое целое, подвергается детализации на другой диаграмме. Получившаяся диаграмма второго уровня содержит функциональные блоки, отображающие главные подфункции функционального блока контекстной диаграммы, и называется дочерней (Child Diagram) по отношению к нему (каждый из функциональных блоков, принадлежащих дочерней диаграмме, соответственно называется дочерним блоком – Child Box). В свою очередь, функциональный блок — предок называется родительским блоком по отношению к дочерней диаграмме (Parent Box), а диаграмма, к которой он принадлежит – родительской диаграммой (Parent Diagram). Каждая из подфункций дочерней диаграммы может быть далее детализирована путем аналогичной декомпозиции соответствующего ей функционального блока. В каждом случае декомпозиции функционального блока все интерфейсные дуги, входящие в данный блок или исходящие из него, фиксируются на дочерней диаграмме. Этим достигается структурная целостность IDEF0–модели.
Иногда отдельные интерфейсные дуги высшего уровня не имеет смысла продолжать рассматривать на диаграммах нижнего уровня, или наоборот — отдельные дуги нижнего отражать на диаграммах более высоких уровней – это будет только перегружать диаграммы и делать их сложными для восприятия. Для решения подобных задач в стандарте IDEF0 предусмотрено понятие туннелирования. Обозначение «туннеля» (Arrow Tunnel) в виде двух круглых скобок вокруг начала интерфейсной дуги обозначает, что эта дуга не была унаследована от функционального родительского блока и появилась (из «туннеля») только на этой диаграмме. В свою очередь, такое же обозначение вокруг конца (стрелки) интерфейсной дуги в непосредственной близи от блока–приемника означает тот факт, что в дочерней по отношению к этому блоку диаграмме эта дуга отображаться и рассматриваться не будет. Чаще всего бывает, что отдельные объекты и соответствующие им интерфейсные дуги не рассматриваются на некоторых промежуточных уровнях иерархии, – в таком случае они сначала «погружаются в туннель», а затем при необходимости «возвращаются из туннеля».
Обычно IDEF0-модели несут в себе сложную и концентрированную информацию, и для того, чтобы ограничить их перегруженность и сделать удобочитаемыми, в стандарте приняты соответствующие ограничения сложности.
Рекомендуется представлять на диаграмме от трех до шести функциональных блоков, при этом количество подходящих к одному функциональному блоку (выходящих из одного функционального блока) интерфейсных дуг предполагается не более четырех.
Стандарт IDEF0 содержит набор процедур, позволяющих разрабатывать и согласовывать модель большой группой людей, принадлежащих к разным областям деятельности моделируемой системы. Обычно процесс разработки является итеративным и состоит из следующих условных этапов:
Создание модели группой специалистов, относящихся к различным сферам деятельности предприятия. Эта группа в терминах IDEF0 называется авторами (Authors). Построение первоначальной модели является динамическим процессом, в течение которого авторы опрашивают компетентных лиц о структуре различных процессов, создавая модели деятельности подразделений. При этом их интересуют ответы на следующие вопросы:
Что поступает в подразделение «на входе»?
Какие функции и в какой последовательности выполняются в рамках подразделения?
Кто является ответственным за выполнение каждой из функций?
Чем руководствуется исполнитель при выполнении каждой из функций?
Что является результатом работы подразделения (на выходе)?
На основе имеющихся положений, документов и результатов опросов создается черновик (Model Draft) модели.
Распространение черновика для рассмотрения, согласований и комментариев. На этой стадии происходит обсуждение черновика модели с широким кругом компетентных лиц (в терминах IDEF0 — читателей) на предприятии. При этом каждая из диаграмм черновой модели письменно критикуется и комментируется, а затем передается автору. Автор, в свою очередь, также письменно соглашается с критикой или отвергает ее с изложением логики принятия решения и вновь возвращает откорректированный черновик для дальнейшего рассмотрения. Этот цикл продолжается до тех пор, пока авторы и читатели не придут к единому мнению.
Официальное утверждение модели. Утверждение согласованной модели происходит руководителем рабочей группы в том случае, если у авторов модели и читателей отсутствуют разногласия по поводу ее адекватности. Окончательная модель представляет собой согласованное представление о предприятии (системе) с заданной точки зрения и для заданной цели.
Наглядность графического языка IDEF0 делает модель вполне читаемой и для лиц, которые не принимали участия в проекте ее создания, а также эффективной для проведения показов и презентаций. В дальнейшем на базе построенной модели могут быть организованы новые проекты, нацеленные на производство изменений в модели.
2.6 Объектный подход к проектированию ИС
Объект — это сущность, которая используется при выполнении некоторой функции или операции (преобразования, обработки, формирования и т.д.). Объекты могут иметь динамическую или статическую природу: динамические объекты используются в одном цикле воспроизводства, например заказы на продукцию, счета на оплату, платежи; статические объекты используются во многих циклах воспроизводства, например, оборудование, персонал, запасы материалов.
На внешнем уровне детализации модели выделяются основные виды материальных объектов (например, сырье и материалы, полуфабрикаты, готовые изделия, услуги) и основные виды информационных объектов или документов (например, заказы, накладные, счета и т.д.).
На концептуальном уровне построения модели предметной области уточняется состав классов объектов, определяются их атрибуты и взаимосвязи. Таким образом строится обобщенное представление структуры предметной области.
Далее концептуальная модель на внутреннем уровне отображается в виде файлов базы данных, входных и выходных документов ЭИС. Причем динамические объекты представляются единицами переменной информации или документами, а статические объекты — единицами условно-постоянной информации в виде списков, номенклатур, ценников, справочников, классификаторов. Модель базы данных как постоянно поддерживаемого информационного ресурса отображает хранение условно-постоянной и накапливаемой переменной информации, используемой в повторяющихся информационных процессах.
Объектные методики рассматривают моделируемую организацию как набор взаимодействующих объектов – производственных единиц. Объект определяется как осязаемая реальность – предмет или явление, имеющие четко определяемое поведение. Целью применения данной методики является выделение объектов, составляющих организацию, и распределение между ними ответственностей за выполняемые действия.
Принципиальное отличие между функциональным и объектным подходом заключается в способе декомпозиции системы. Объектно-ориентированный подход использует объектную декомпозицию, при этом статическая структура описывается в терминах объектов и связей между ними, а поведение системы описывается в терминах обмена сообщениями между объектами. Целью методики является построение бизнес-модели организации, позволяющей перейти от модели сценариев использования к модели, определяющей отдельные объекты, участвующие в реализации бизнес-функций.
Концептуальной основой объектно-ориентированного подхода является объектная модель, которая строится с учетом следующих принципов:
абстрагирование;
инкапсуляция;
модульность;
иерархия;
типизация;
параллелизм;
устойчивость.
Основными понятиями объектно-ориентированного подхода являются объект и класс.
Объект — предмет или явление, имеющее четко определенное поведение и обладающие состоянием, поведением и индивидуальностью. Структура и поведение схожих объектов определяют общий для них класс. Класс – это множество объектов, связанных общностью структуры и поведения. Следующую группу важных понятий объектного подхода составляют наследование и полиморфизм. Понятие полиморфизм может быть интерпретировано как способность класса принадлежать более чем одному типу. Наследование означает построение новых классов на основе существующих с возможностью добавления или переопределения данных и методов.
Важным качеством объектного подхода является согласованность моделей деятельности организации и моделей проектируемой информационной системы от стадии формирования требований до стадии реализации. По объектным моделям может быть прослежено отображение реальных сущностей моделируемой предметной области (организации) в объекты и классы информационной системы.
Большинство существующих методов объектно-ориентированного подхода включают язык моделирования и описание процесса моделирования. Процесс – это описание шагов, которые необходимо выполнить при разработке проекта. В качестве языка моделирования объектного подхода используется унифицированный язык моделирования UML, который содержит стандартный набор диаграмм для моделирования.
Диаграмма (Diagram) — это графическое представление множества элементов. Чаще всего она изображается в виде связного графа с вершинами (сущностями) и ребрами (отношениями) и представляет собой некоторую проекцию системы.
Объектно-ориентированный подход обладает следующими преимуществам:
Объектная декомпозиция дает возможность создавать модели меньшего размера путем использования общих механизмов, обеспечивающих необходимую экономию выразительных средств. Использование объектного подхода существенно повышает уровень унификации разработки и пригодность для повторного использования, что ведет к созданию среды разработки и переходу к сборочному созданию моделей.
Объектная декомпозиция позволяет избежать создания сложных моделей, так как она предполагает эволюционный путь развития модели на базе относительно небольших подсистем.
Объектная модель естественна, поскольку ориентированна на человеческое восприятие мира.
К недостаткам объектно-ориентированного подхода относятся высокие начальные затраты. Этот подход не дает немедленной отдачи. Эффект от его применения сказывается после разработки двух–трех проектов и накопления повторно используемых компонентов. Диаграммы, отражающие специфику объектного подхода, менее наглядны.
2.7 Сравнение существующих методик
В функциональных моделях (DFD-диаграммах потоков данных, SADT-диаграммах) главными структурными компонентами являются функции (операции, действия, работы), которые на диаграммах связываются между собой потоками объектов.
Несомненным достоинством функциональных моделей является реализация структурного подхода к проектированию ИС по принципу «сверху-вниз», когда каждый функциональный блок может быть декомпозирован на множество подфункций и т.д., выполняя, таким образом, модульное проектирование ИС. Для функциональных моделей характерны процедурная строгость декомпозиции ИС и наглядность представления.
При функциональном подходе объектные модели данных в виде ER-диаграмм «объект — свойство — связь» разрабатываются отдельно. Для проверки корректности моделирования предметной области между функциональными и объектными моделями устанавливаются взаимно однозначные связи.
Главный недостаток функциональных моделей заключается в том, что процессы и данные существуют отдельно друг от друга — помимо функциональной декомпозиции существует структура данных, находящаяся на втором плане. Кроме того, не ясны условия выполнения процессов обработки информации, которые динамически могут изменяться.
Перечисленные недостатки функциональных моделей снимаются в объектно-ориентированных моделях, в которых главным структурообразующим компонентом выступает класс объектов с набором функций, которые могут обращаться к атрибутам этого класса.
Для классов объектов характерна иерархия обобщения, позволяющая осуществлять наследование не только атрибутов (свойств) объектов от вышестоящего класса объектов к нижестоящему классу, но и функций (методов).
В случае наследования функций можно абстрагироваться от конкретной реализации процедур (абстрактные типы данных), которые отличаются для определенных подклассов ситуаций. Это дает возможность обращаться к подобным программным модулям по общим именам (полиморфизм) и осуществлять повторное использование программного кода при модификации программного обеспечения. Таким образом, адаптивность объектно-ориентированных систем к изменению предметной области по сравнению с функциональным подходом значительно выше.
При объектно-ориентированном подходе изменяется и принцип проектирования ИС. Сначала выделяются классы объектов, а далее в зависимости от возможных состояний объектов (жизненного цикла объектов) определяются методы обработки (функциональные процедуры), что обеспечивает наилучшую реализацию динамического поведения информационной системы.
Для объектно-ориентированного подхода разработаны графические методы моделирования предметной области, обобщенные в языке унифицированного моделирования UML. Однако по наглядности представления модели пользователю-заказчику объектно-ориентированные модели явно уступают функциональным моделям.
Вывод: при выборе методики моделирования предметной области обычно в качестве критерия выступает степень ее динамичности. Для более регламентированных задач больше подходят функциональные модели, для более адаптивных бизнес-процессов (управления рабочими потоками, реализации динамических запросов к информационным хранилищам) — объектно-ориентированные модели. Однако в рамках одной и той же ИС для различных классов задач могут требоваться различные виды моделей, описывающих одну и ту же проблемную область. В таком случае должны использоваться комбинированные модели предметной области.
Лекция №3
Информационное обеспечение ИС
Информационное обеспечение ИС является средством для решения следующих задач:
однозначного и экономичного представления информации в системе (на основе кодирования объектов);
организации процедур анализа и обработки информации с учетом характера связей между объектами (на основе классификации объектов);
организации взаимодействия пользователей с системой (на основе экранных форм ввода-вывода данных);
обеспечения эффективного использования информации в контуре управления деятельностью объекта автоматизации (на основе унифицированной системы документации).
Информационное обеспечение ИС включает два комплекса: внемашинное информационное обеспечение (классификаторы технико-экономической информации, документы, методические инструктивные материалы) и внутримашинное информационное обеспечение (макеты/экранные формы для ввода первичных данных в ЭВМ или вывода результатной информации, структуры информационной базы: входных, выходных файлов, базы данных).
К информационному обеспечению предъявляются следующие общие требования:
информационное обеспечение должно быть достаточным для поддержания всех автоматизируемых функций объекта;
для кодирования информации должны использоваться принятые у заказчика классификаторы;
для кодирования входной и выходной информации, которая используется на высшем уровне управления, должны быть использованы классификаторы этого уровня;
должна быть обеспечена совместимость с информационным обеспечением систем, взаимодействующих с разрабатываемой системой;
формы документов должны отвечать требованиям корпоративных стандартов заказчика (или унифицированной системы документации);
структура документов и экранных форм должна соответствовать характеристиками терминалов на рабочих местах конечных пользователей;
графики формирования и содержание информационных сообщений, а также используемые аббревиатуры должны быть общеприняты в этой предметной области и согласованы с заказчиком;
в ИС должны быть предусмотрены средства контроля входной и результатной информации, обновления данных в информационных массивах, контроля целостности информационной базы, защиты от несанкционированного доступа.
Информационное обеспечение ИС можно определить как совокупность единой системы классификации, унифицированной системы документации и информационной базы.
3.1 Внемашинное информационное обеспечение. Кодирование экономической информации
Внемашинное информационное обеспечение (ИО) – это множество бумажных и других управленческих документов, воспринимаемых человеком, а также методов их построения.
Структура внемашинного ИО представлена на рис.3.1
Внемашинное
ИО
Экономические
показатели
Управленческие
документы
Входные
оперативные
Нормативно-
справочные
Результирующие





Рис.3.1 Структура внемашинного информационного обеспечения
Экономический показатель – это неделимая совокупность реквизитов-признаков и одного реквизита основания, образующих экономический смысл. Например, план поставок стального прутка для поставщика ООО «ЗЖБИ-100» в январе 2007 года равен 320 тонн. Реквизиты- признаки, подчеркнутые волнистой линией, предназначены для выполнения логических операций (поиск, группировка, сортировка) и характеризуют качественную сторону объекта (коды, наименование, единица измерения, время и т.п.). Реквизит-основание, подчеркнутый сплошной линией используется для выполнения арифметических операций и дает количественную характеристику объекта (план, факт, процент, коэффициент, объем и т.д.).
Экономические показатели составляют содержание большинства управленческих документов.
Бумажный документ – это информационное сообщение на естественном языке, зафиксированное рукописным или печатным способом на бланке. Бумажные документы бывают унифицированные, т.е. созданные на базе стандартов, (учетная, статистическая, финансовая, банковская, расчетно-платежная и другая документация) и произвольные (например, табель, калькуляция и т.п.).
Управленческие документы делятся на три группы: входные оперативные; нормативно-справочные (условно-постоянные) и результирующие. Во входных оперативных документах фиксируются факты финансово-хозяйственной деятельности. Справочная документация содержит расшифровки кодов поставщиков, материалов и т.д. Результирующие документы предназначены для конечного пользователя.
Основные понятия классификации технико-экономической информации
Для того чтобы обеспечить эффективный поиск, обработку на ЭВМ и передачу по каналам связи технико-экономической информации, ее необходимо представить в цифровом виде. С этой целью ее нужно сначала упорядочить (классифицировать), а затем формализовать (закодировать) с использованием классификатора.
Классификация – это разделение множества объектов на подмножества по их сходству или различию в соответствии с принятыми методами. Классификация фиксирует закономерные связи между классами объектов. Под объектом понимается любой предмет, процесс, явление материального или нематериального свойства. Система классификации позволяет сгруппировать объекты и выделить определенные классы, которые будут характеризоваться рядом общих свойств. Таким образом, совокупность правил распределения объектов множества на подмножества называется системой классификации.
Свойство или характеристика объекта классификации, которое позволяет установить его сходство или различие с другими объектами классификации, называется признаком классификации. Например, признак «роль предприятия-партнера в отношении деятельности объекта автоматизации» позволяет разделить все предприятия на две группы (на два подмножества): «поставщики» и «потребители». Множество или подмножество, объединяющее часть объектов классификации по одному или нескольким признакам, носит название классификационной группировки.
Классификатор — это документ, с помощью которого осуществляется формализованное описание информации в ИС, содержащей наименования объектов, наименования классификационных группировок и их кодовые обозначения.
По сфере действия выделяют следующие виды классификаторов: международные, общегосударственные (общесистемные), отраслевые и локальные классификаторы.
Международные классификаторы входят в состав Системы международных экономических стандартов (СМЭС) и обязательны для передачи информации между организациями разных стран мирового сообщества.
Общегосударственные (общесистемные) классификаторы, обязательны для организации процессов передачи и обработки информации между экономическими системами государственного уровня внутри страны.
Отраслевые классификаторы используют для выполнения процедур обработки информации и передачи ее между организациями внутри отрасли.
Локальные классификаторы используют в пределах отдельных предприятий.
Каждая система классификации характеризуется следующими свойствами:
гибкостью системы;
емкостью системы;
степенью заполненности системы.
Гибкость системы — это способность допускать включение новых признаков, объектов без разрушения структуры классификатора. Необходимая гибкость определяется временем жизни системы.
Емкость системы — это наибольшее количество классификационных группировок, допускаемое в данной системе классификации.
Степень заполненности системы определяется как частное от деления фактического количества группировок на величину емкости системы.
В настоящее время чаще всего применяются два типа систем классификации: иерархическая и многоаспектная.
При использовании иерархического метода классификации происходит «последовательное разделение множества объектов на подчиненные, зависимые классификационные группировки». Получаемая на основе этого процесса классификационная схема имеет иерархическую структуру. В ней первоначальный объем классифицируемых объектов разбивается на подмножества по какому-либо признаку и детализируется на каждой следующей ступени классификации. Обобщенное изображение иерархической классификационной схемы представлено на рис.3.1.
INCLUDEPICTURE "Учебник%20ОПС/9/9-1.gif" \* MERGEFORMATINET Рис. 3.2  Иерархическая классификационная схема
Характерными особенностями иерархической системы являются:
возможность использования неограниченного количества признаков классификации;
соподчиненность признаков классификации, что выражается разбиением каждой классификационной группировки, образованной по одному признаку, на множество классификационных группировок по нижестоящему (подчиненному) признаку.
Таким образом, классификационные схемы, построенные на основе иерархического принципа, имеют неограниченную емкость, величина которой зависит от глубины классификации (числа ступеней деления) и количества объектов классификации, которое можно расположить на каждой ступени. Количество же объектов на каждой ступени классификации определяется основанием кода, то есть числом знаков в выбранном алфавите кода. (Например, если алфавит – двузначные десятичные цифры, то можно на одном уровне разместить 100 объектов). Выбор необходимой глубины классификации и структуры кода зависит от характера объектов классификации и характера задач, для решения которых предназначен классификатор.
При построении иерархической системы классификации сначала выделяется некоторое множество объектов, подлежащее классифицированию, для которого определяются полное множество признаков классификации и их соподчиненность друг другу, затем производится разбиение исходного множества объектов на классификационные группировки на каждой ступени классификации.
К положительным сторонам данной системы следует отнести логичность, простоту ее построения и удобство логической и арифметической обработки.
Серьезным недостатком иерархического метода классификации является жесткость классификационной схемы. Она обусловлена заранее установленным выбором признаков классификации и порядком их использования по ступеням классификации. Это ведет к тому, что при изменении состава объектов классификации, их характеристик или характера решаемых при помощи классификатора задач требуется коренная переработка классификационной схемы. Гибкость этой системы обеспечивается только за счет ввода большой избыточности в ветвях, что приводит к слабой заполненности структуры классификатора. Поэтому при разработке классификаторов следует учитывать, что иерархический метод классификации более предпочтителен для объектов с относительно стабильными признаками и для решения стабильного комплекса задач.
Примеры применения иерархической классификации объектов в корпоративной ИС приведены на рис.3.2 и 3.3. Использование приведенных моделей позволяет выполнить кодирование информации о соответствующих объектах, а также использовать процедуры обобщения при обработке данных (при анализе затрат на заработную плату — по принадлежности работника к определенной службе, при анализе затрат на производство — по группам материалов: по металлу, по покупным комплектующим и пр.).
INCLUDEPICTURE "Учебник%20ОПС/9/9-2.gif" \* MERGEFORMATINET Рис. 3.3.  Организационная структура подразделения предприятия-цеха отгрузки
INCLUDEPICTURE "Учебник%20ОПС/9/9-3.gif" \* MERGEFORMATINET Рис. 3.4.  Классификатор материальных ресурсов для обеспечения производства
Недостатки, отмеченные в иерархической системе, отсутствуют в других системах, которые относятся к классу многоаспектных систем классификации.
Аспект — точка зрения на объект классификации, который характеризуется одним или несколькими признаками. Многоаспектная система — это система классификации, которая использует параллельно несколько независимых признаков (аспектов) в качестве основания классификации. Существуют два типа многоаспектных систем: фасетная и дескрипторная. Фасет — это аспект классификации, который используется для образования независимых классификационных группировок. Дескриптор — ключевое слово, определяющее некоторое понятие, которое формирует описание объекта и дает принадлежность этого объекта к классу, группе и т.д.
Под фасетным методом классификации понимается «параллельное разделение множества объектов на независимые классификационные группировки». При этом методе классификации заранее жесткой классификационной схемы и конечных группировок не создается. Разрабатывается лишь система таблиц признаков объектов классификации, называемых фасетами. При необходимости создания классификационной группировки для решения конкретной задачи осуществляется выборка необходимых признаков из фасетов и их объединение в определенной последовательности. Общий вид фасетной классификационной схемы представлен на рис.3.4.
INCLUDEPICTURE "Учебник%20ОПС/9/9-4.gif" \* MERGEFORMATINET Рис. 3.5.  Схема признаков фасетной классификации
Внутри фасета значения признаков могут просто перечисляться по некоторому порядку или образовывать сложную иерархическую структуру, если существует соподчиненность выделенных признаков.
К преимуществам данной системы следует отнести большую емкость системы и высокую степень гибкости, поскольку при необходимости можно вводить дополнительные фасеты и изменять их место в формуле. При изменении характера задач или характеристик объектов классификации разрабатываются новые фасеты или дополняются новыми признаками уже существующие фасеты без коренной перестройки структуры всего классификатора.
К недостаткам, характерным для данной системы, можно отнести сложность структуры и низкую степень заполненности системы.
В современных классификационных схемах часто одновременно используются оба метода классификации. Это снижает влияние недостатков методов классификации и расширяет возможность использования классификаторов в информационном обеспечении управления.
В качестве примера использования комбинированных схем классификации в корпоративных ИС можно привести следующую модель описания продукции предприятия.
Правила классификации продукции
Принята классификация выпускаемой продукции по следующему ряду уровней (Иерархическая классификация):
семейство продуктов;
группа продуктов;
серия продуктов.
Однако эта система классификации не обеспечивает идентификацию любого выпускаемого изделия. Для каждой единицы продукта должны указываться следующие атрибуты (Фасеты):
код серии продукта;
конфигурационные параметры;
свойства.
Код серии продукта – алфавитно-цифровой код, однозначно идентифицирующий отдельный продукт. Конфигурационные параметры – свойства, значения которых могут быть различными в зависимости от потребностей пользователей. Свойства – предопределенные характеристики отдельных продуктов, которые не могут меняться для одного и того же продукта.
Допустимые варианты записи кода серии для различных продуктов показаны на рис.3.5.
Признаки фасета «Конфигурационные параметры» для одного семейства продуктов приведены в таблице 3.1.
Рассмотренные выше системы классификации хорошо приспособлены для организации поиска с целью последующей логической и арифметической обработки информации на ЭВМ, но лишь частично решают проблему содержательного поиска информации при принятии управленческих решений.
INCLUDEPICTURE "Учебник%20ОПС/9/9-5.gif" \* MERGEFORMATINET Рис. 3.6.  Варианты записи кода серии продукта (серым цветом отмечены неиспользуемые элементы кода)
Для поиска показателей и документов по набору содержательных признаков используется информационный язык дескрипторного типа, которой характеризуется совокупностью терминов (дескрипторов) и набором отношений между терминами.
Содержание документов или показателей можно достаточно полно и точно отразить с помощью списка ключевых слов — дескрипторов. Дескриптор — это термин естественного языка (слово или словосочетание), используемый при описании документов или показателей, который имеет самостоятельный смысл и неделим без изменения своего значения.
Для того чтобы обеспечить точность и однозначность поиска с помощью дескрипторного языка, необходимо предварительно определить все постоянные отношения между терминами: родовидовые, отношения синонимии, омонимии и полисемии, а также ассоциативные отношения.
Все выделенные отношения явно описываются в систематическом словаре понятий — тезаурусе, который разрабатывается с целью проведения индексирования документов, показателей и информационных запросов.
Кодирование технико-экономической информации (см. Романов А.Н., Одинцов Б.Е. Информационные системы в экономике.-М.: Вузовский учебник, 2006.-300с.; с. 84-89).
Для полной формализации информации недостаточно простой классификации, поэтому проводят следующую процедуру — кодирование. Кодирование — это процесс присвоения условных обозначений объектам и классификационным группам по соответствующей системе кодирования. Кодирование реализует перевод информации, выраженной одной системой знаков, в другую систему, то есть перевод записи на естественном языке в запись с помощью кодов. Система кодирования — это совокупность правил обозначения объектов и группировок с использованием кодов. Код — это условное обозначение объектов или группировок в виде знака или группы знаков в соответствии с принятой системой. Код базируется на определенном алфавите (некоторое множество знаков). Число знаков этого множества называется основанием кода. Различают следующие типы алфавитов: цифровой, буквенный и смешанный.
Код характеризуется следующими параметрами:
длиной;
основанием кодирования;
структурой кода, под которой понимают распределение знаков по признакам и объектам классификации;
степенью информативности, рассчитываемой как частное от деления общего количества признаков на длину кода;
коэффициентом избыточности, который определяется как отношение максимального количества объектов к фактическому количеству объектов.
К методам кодирования предъявляются определенные требования:
код должен осуществлять идентификацию объекта в пределах заданного множества объектов классификации;
желательно предусматривать использование в качестве алфавита кода десятичных цифр и букв;
необходимо обеспечивать по возможности минимальную длину кода и достаточный резерв незанятых позиций для кодирования новых объектов без нарушения структуры классификатора.
Методы кодирования могут носить самостоятельный характер – регистрационные методы кодирования, или быть основанными на предварительной классификации объектов – классификационные методы кодирования.
Регистрационные методы кодирования бывают двух видов: порядковый и серийно-порядковый. В первом случае кодами служат числа натурального ряда. Каждый из объектов классифицируемого множества кодируется путем присвоения ему текущего порядкового номера. Данный метод кодирования обеспечивает довольно большую долговечность классификатора при незначительной избыточности кода. Этот метод обладает наибольшей простотой, использует наиболее короткие коды и лучше обеспечивает однозначность каждого объекта классификации. Кроме того, он обеспечивает наиболее простое присвоение кодов новым объектам, появляющимся в процессе ведения классификатора. Существенным недостатком порядкового метода кодирования является отсутствие в коде какой-либо конкретной информации о свойствах объекта, а также сложность машинной обработки информации при получении итогов по группе объектов классификации с одинаковыми признаками.
В серийно-порядковом методе кодирования кодами служат числа натурального ряда с закреплением отдельных серий этих чисел (интервалов натурального ряда) за объектами классификации с одинаковыми признаками. В каждой серии, кроме кодов имеющихся объектов классификации, предусматривается определенное количество кодов для резерва.
Классификационные коды используют для отражения классификационных взаимосвязей объектов и группировок и применяются в основном для сложной логической обработки экономической информации. Группу классификационных систем кодирования можно разделить на две подгруппы в зависимости от того, какую систему классификации используют для упорядочения объектов: системы последовательного кодирования и параллельного кодирования.
Последовательные системы кодирования характеризуются тем, что они базируются на предварительной классификации по иерархической системе. Код объекта классификации образуется с использованием кодов последовательно расположенных подчиненных группировок, полученных при иерархическом методе кодирования. В этом случае код нижестоящей группировки образуется путем добавления соответствующего количества разрядов к коду вышестоящей группировки.
Параллельные системы кодирования характеризуются тем, что они строятся на основе использования фасетной системы классификации и коды группировок по фасетам формируются независимо друг от друга.
В параллельной системе кодирования возможны два варианта записи кодов объекта:
Каждый фасет и признак внутри фасета имеют свои коды, которые включаются в состав кода объекта. Такой способ записи удобно применять тогда, когда объекты характеризуются неодинаковым набором признаков. При формировании кода какого-либо объекта берутся только необходимые признаки.
Для определения групп объектов выделяется фиксированный набор признаков и устанавливается стабильный порядок их следования, то есть устанавливается фасетная формула. В этом случае не надо каждый раз указывать, значение какого из признаков приведено в определенных разрядах кода объекта.
Параллельный метод кодирования имеет ряд преимуществ. К достоинствам рассматриваемого метода следует отнести гибкость структуры кода, обусловленную независимостью признаков, из кодов которых строится код объекта классификации. Метод позволяет использовать при решении конкретных технико-экономических и социальных задач коды только тех признаков объектов, которые необходимы, что дает возможность работать в каждом отдельном случае с кодами небольшой длины. При этом методе кодирования можно осуществлять группировку объектов по любому сочетанию признаков. Параллельный метод кодирования хорошо приспособлен для машинной обработки информации. По конкретной кодовой комбинации легко узнать, набором каких характеристик обладает рассматриваемый объект. При этом из небольшого числа признаков можно образовать большое число кодовых комбинаций. Набор признаков при необходимости может легко пополняться присоединением кода нового признака. Это свойство параллельного метода кодирования особенно важно при решении технико-экономических задач, состав которых часто меняется.
Наиболее сложными вопросами, которые приходится решать при разработке классификатора, являются выбор методов классификации и кодирования и выбор системы признаков классификации. Основой классификатора должны быть наиболее существенные признаки классификации, соответствующие характеру решаемых с помощью классификатора задач. При этом данные признаки могут быть или соподчиненными, или несоподчиненными. При соподчиненных признаках классификации и стабильном комплексе задач, для решения которых предназначен классификатор, целесообразно использовать иерархический метод классификации, который представляет собой последовательное разделение множества объектов на подчиненные классификационные группировки. При несоподчиненных признаках классификации и при большой динамичности решаемых задач целесообразно использовать фасетный метод классификации.
Важным вопросом является также правильный выбор последовательности использования признаков классификации по ступеням классификации при иерархическом методе классификации. Критерием при этом является статистика запросов к классификатору. В соответствии с этим критерием на верхних ступенях классификации в классификаторе должны использоваться признаки, к которым будут наиболее частые запросы. По этой же причине на верхних ступенях классификации выбирают наименьшее основание кода.
Понятие унифицированной системы документации
Основной компонентой внемашинного информационного обеспечения ИС является система документации, применяемая в процессе управления экономическим объектом. Под документом понимается определенная совокупность сведений, используемая при решении технико-экономических задач, расположенная на материальном носителе в соответствии с установленной формой.
Система документации — это совокупность взаимосвязанных форм документов, регулярно используемых в процессе управления экономическим объектом. Отличительной особенностью системы экономической документации является большое разнообразие видов документов.
Существующие системы документации, характерные для неавтоматизированных ИС, отличаются большим количеством разных типов форм документов, большим объемом потоков документов и их запутанностью, дублированием информации в документах и работ по их обработке и, как следствие, низкой достоверностью получаемых результатов. Для того чтобы упростить систему документации, используют следующие два подхода:
проведение унификации и стандартизации документов;
введение безбумажной технологии, основанной на использовании электронных документов и новых информационных технологий их обработки.
Унификация документов выполняется путем введения единых форм документов. Таким образом, вводится единообразие в наименования показателей, единиц измерения и терминов, в результате чего получается унифицированная система документации.
Унифицированная система документации (УСД) — это рационально организованный комплекс взаимосвязанных документов, который отвечает единым правилам и требованиям и содержит информацию, необходимую для управления некоторым экономическим объектом. По уровням управления, они делятся на межотраслевые системы документации, отраслевые и системы документации локального уровня, т. е. обязательные для использования в рамках предприятий или организаций.
Любой тип УСД должен удовлетворять следующим требованиям:
документы, входящие в состав УСД, должны разрабатываться с учетом их использования в системе взаимосвязанных ЭИС;
УСД должна содержать полную информацию, необходимую для оптимального управления тем объектом, для которого разрабатывается эта система;
УСД должна быть ориентирована на использование средств вычислительной техники для сбора, обработки и передачи информации;
УСД должна обеспечить информационную совместимость ЭИС различных уровней;
все документы, входящие в состав разрабатываемой УСД, и все реквизиты-признаки в них должны быть закодированы с использованием международных, общесистемных или локальных классификаторов.
3.2 Внутримашинное информационное обеспечение
К внутримашинному информационному обеспечению относятся файлы, базы и банки данных, базы знаний и хранилища данных.
Файл – это последовательное отображение однородных управленческих документов на машинном носителе в виде записей. Запись отражает один документ либо его строку, если документ многострочный.
Несмотря на появление файлов с произвольным доступом, быстро стало очевидным, что файловые системы любого типа обладают некоторыми врожденными недостатками:
Избыточность данных
Слабый контроль данных
Недостаточные возможности управления данными
Большие затраты труда программиста
Избыточность данных. Главная трудность состоит в том, что многие приложения используют свои собственные файлы данных. Таким образом, некоторые единицы данных повторяются в разных приложениях. Например, в банке одно и то же имя клиента встречается в файлах, содержащих сведения о текущих счетах, сберегательных счетах и ссудах. Более того, хотя это одно и то же имя клиента, соответствующие поля в разных файлах могут называться по-разному. Так, поле CNAME файла текущих счетов превращается в SNAME файла сберегательных счетов и в INAME файла ссуд. Одно и то же поле в разных файлах может, кроме того, иметь разную длину. Например, поле CNAME может содержать до 20 символов, а поля SNAME и INAME допускают максимальную длину 15 символов. Следствием такой избыточности данных являются лишние затраты на поддержание и хранение данных. Избыточность данных также порождает риск противоречий между разными версиями общих данных.
Предположим, что клиент изменил имя. Изменение могло быть сразу внесено в файл текущих счетов, через неделю — в файл сберегательных счетов, а в файл ссуд изменение могло оказаться внесенным неверно. По прошествии некоторого времени подобные расхождения могут существенно снизить качество информации, содержащейся в файлах данных. Такая несогласованность данных может также отразиться на точности отчетов. Информационные системы, использующие базы данных, позволяют избавиться от подобной избыточности данных, поскольку все приложения используют один и тот же набор данных. Существенная информация, например, имя или адрес клиента, будет записываться в базе данных всего один раз. Таким образом, мы сможем изменять адрес или имя клиента один раз, будучи при этом уверены, что все приложения будут пользоваться согласованными данными.
Слабый контроль данных. В файловых системах отсутствует централизованный контроль на уровне элементов данных. Весьма часто один и тот же элемент данных имеет несколько имен в зависимости от того, в какие файлы он входит.
На более фундаментальном уровне всегда существует вероятность того, что разные отделы компании пользуются терминологией, не согласованной с остальными. Например, банк может вкладывать в термин счет один смысл применительно к сбережениям и совсем другой применительно к ссудам. И наоборот, разные слова могут иметь одинаковые значения. Страховая компания может говорить о владельце полиса или о клиенте, вкладывая в эти два термина один и тот же смысл. Система управления базами данных осуществляет централизованный контроль данных и помогает избежать недоразумений, порожденных омонимами и синонимами.
Недостаточные возможности управления данными. Индексно-последовательные файлы позволяют обращаться к определенной записи по ключу, например, по идентификатору товара. Например, если мы знаем идентификатор настольной лампы, мы можем напрямую извлечь из файла PRODUCT относящуюся к ней запись. Этого достаточно до тех пор, пока нам нужна отдельная запись.
Однако предположим, что нам нужен целый ряд связанных между собой записей. Например, мы хотим найти все продажи клиенту Петрову. Допустим, что мы также хотим узнать общее число таких продаж, среднюю цену или же список товаров, купленных клиентом и кто является изготовителем этих товаров. Такую информацию будет трудно, если не невозможно, извлечь из файловой системы, поскольку файловые системы не позволяют устанавливать связь между данными разных файлов. Системы управления базами данных были специально разработаны для того, чтобы упростить связывание данных из разных файлов.
Большие затраты труда программиста. Новая прикладная программа часто требовала совершенно нового набора файлов. Даже если существующий уже файл содержал некоторые нужные данные, приложению часто требовался еще какой-либо набор элементов данных. В результате программисту приходилось перекодировать определения нужных элементов данных из существующих файлов, а также определять новые элементы данных. Таким образом, в файловой системе существовала жесткая зависимость между программами и данными.
Базы данных позволили разделить программы и данные, так что программа может быть в некотором смысле независима от деталей определения данных. Предоставляя доступ к множеству общих данных и поддерживая мощные языки управления данными, информационные системы, использующие базы данных, позволяют значительно сократить объем работ по созданию и поддержке программного обеспечения.
Было сделано немало попыток дать определение понятию база данных. В справочной литературе по информатике приводится следующее определение базы данных — «совокупность данных, организованных по определенным правилам, предусматривающим общие принципы описания, хранения и манипулирования данными, независимая от прикладных программ». Нормативно-правовая трактовка понятия базы данных представлена в законе «О правовой охране программ для ЭВМ и баз данных», согласно которому «база данных— это объективная форма представления и организации совокупности данных (например, статей, расчетов), систематизированных таким образом, чтобы эти данные могли быть найдены и обработаны с помощью ЭВМ». Для наших целей вполне подойдет следующее: база данных — это совокупность данных, организованная с определенной целью. Здесь слово организованная означает, что указанная совокупность включает данные, которые сохраняются, имеют определенный формат (отформатированы), к ним может быть обеспечен доступ (доступны), и они могут быть представлены потребителю информации в приемлемом виде (репрезентативны). Упоминанием в определении цели подчеркивается, что состав данных должен соответствовать некоторой задаче (или классу задач): с одной стороны, в базе не должны содержаться данные, не имеющие отношения к задаче, а с другой — должна содержаться вся информация, касающаяся задачи. Прекрасным и понятным примером базы данных может служить телефонный справочник. Он содержит данные, имеющие прямое отношение к цели его существования (в данном случае — имена абонентов), которые открывают доступ к номеру телефона. В справочнике отсутствует избыточная информация, скажем цвет аппарата абонента. То есть в этой простейшей базе содержится информация, непосредственно связанная с целью ее создания. Наиболее часто цель существования базы данных связана с деловой сферой, но в ней может содержаться и научная, военная и прочая информация, в ряде случаев не имеющая отношения к сфере бизнеса. Существуют деловые, научные, военные и прочие базы данных, причем список возможных областей человеческой деятельности, в которых находят применение данные, организованные таким образом, может быть продолжен практически неограниченно. Кроме разделения баз данных, основанного на областях их применения, можно предложить и другой подход, взяв за основу форматы включенной в них информации. Помимо текстовой и числовой это могут быть изображения, различного рода графики и схемы, аудио- и видеоинформация. В последнее время все чаще речь идет о составных документах, которые представляют собой связную совокупность различных видов информации.
Система управления базой данных (СУБД) позволяет получить доступ к данным, обеспечивает корректировку, пополнение, сохранение БД.
Различают логический и физический уровни организации данных. Физический уровень отражает организацию хранения БД на машинных носителях, а логический уровень — внешнее представление данных пользователю.
Логическая организация данных па машинном носителе зависит от используемых программных средств организации и ведения данных. Метод логической организации данных определяется используемыми типом структур данных и видом модели., которая поддерживается программным средством.
Модель данных — это совокупность взаимосвязанных структур данных и операций над этими структурами. Вид модели и используемые в ней типы структур данных отражают концепцию организации и обработки данных, используемую в СУБД, поддерживающей модель, или в языке системы программирования, на котором создается прикладная программа обработки данных.
Важно отметить, что для размещения одной и той же информации во внутримашинной сфере могут быть использованы различные структуры и модели данных. Их выбор возлагается на пользователя, создающего информационную базу, и зависит от многих факторов, в том числе от имеющегося технического и программного обеспечения, определяется сложностью автоматизируемых задач и объемом информации.
По способу организации БД разделяют на базы иерархические, сетевые, реляционные, объектно-реляционные и объектно-ориентированные базы данных.
Сетевые и иерархические модели. Более сложными моделями данных по сравнению с файловой являются сетевые и иерархические модели, которые поддерживаются в системе управления базами данных соответствующего типа. Тип модели данных, поддерживаемой СУБД на машинном носителе, является одним из важнейших признаков классификации СУБД.
Сетевая или иерархическая модель данных представляет соответствующий метод логической организации базы данных в СУБД.
Иерархическая модель представляет собой древовидную структуру с корневыми сегментами, имеющими физический указатель на другие сегменты. Одно из неудобств этой модели заключается в том, что реальный мир не может быть представлен в виде древовидной структуры с единственным корневым сегментом. Иерархические БД обеспечивали указатели между различными деревьями баз данных, но обработка данных с использованием таких связей была не всегда удобной.
В иерархических моделях непосредственный доступ, как правило, возможен только к объекту самого высокого уровня, который не подчинен другим объектам. К другим объектам доступ осуществляется по связям от объекта на вершине модели. В сетевых моделях непосредственный доступ может обеспечиваться к любому объекту независимо от уровня, на котором он находится в модели. Возможен также доступ по связям от любой точки доступа.
В отличие от иерархической БД в сетевой БД нет необходимости в корневой записи. Однако, как и в иерархических БД, связи поддерживаются с помощью физических указателей.
Сетевые модели данных по сравнению с иерархическими являются более универсальным средством отображения структуры информации для разных предметных областей. Взаимосвязи данных большинства предметных областей имеют сетевой характер, что ограничивает использование СУБД с иерархической моделью данных. Сетевые модели позволяют отображать также иерархические взаимосвязи данных. Достоинством сетевых моделей является отсутствие дублирования данных в различных элементах модели. Кроме того, технология работы с сетевыми моделями является удобной для пользователя, так как доступ к данным практически не имеет ограничений и возможен непосредственно к объекту любого уровня. Допустимы всевозможные запросы.
Реляционная модель данных. Концепция реляционной модели баз данных была предложена Э.Ф. Коддом в 1970 г. Как отмечал доктор Кодд, реляционная модель данных обеспечивает ряд возможностей, которые делают управление и использование базы данных относительно легким, предсказуемым и устойчивым по отношению к ошибкам. Наиболее важные характеристики реляционной модели заключены в следующем:
Модель описывает данные с их естественной структурой, не добавляя каких-либо дополнительных структур, необходимых для машинного представления или для целей реализации.
Модель обеспечивает математическую основу для интерпретации выводимости, избыточности и непротиворечивости отношений.
Модель обеспечивает независимость данных от их физического представления, от связей между данными и от соображений реализации, связанных с эффективностью и подобными проблемами.
Реляционные модели данных отличаются от рассмотренных выше сетевых и иерархических простотой структур данных, удобным для пользователя табличным представлением и доступом к данным. Реляционная модель данных является совокупностью простейших двумерных таблиц -отношений (объектов модели). Связи между двумя логически связанными таблицами в реляционной модели устанавливаются по равенству значений одинаковых атрибутов таблиц-отношений.
Таблица-отношение является универсальным объектом реляционных моделей. Это обеспечивает возможность унификации обработки данных в различных СУБД, поддерживающих реляционную модель. Операции обработки реляционных моделей основаны на использовании универсального аппарата алгебры отношений и реляционного исчисления.
Структуры данных реляционной модели. Таблица является основным типом структуры данных (объектом) реляционной модели. Структура таблицы определяется совокупностью столбцов. Данные в пределах одного столбца однородны. В таблице не может быть двух одинаковых строк. Общее число строк не ограничено.
Столбец соответствует некоторому элементу данных — атрибуту, который является простейшей структурой данных. В таблице не могут быть определены множественные элементы, группа или повторяющаяся группа, как в рассмотренных выше сетевых и иерархических моделях. Каждый столбец таблицы должен иметь имя соответствующего элемента данных (атрибута). Один или несколько атрибутов, значения которых однозначно идентифицируют строку таблицы, являются ключом таблицы.
В реляционном подходе к построению баз данных используется терминология теории отношений. Простейшая двумерная таблица определяется как отношение. Столбец таблицы со значениями соответствующего атрибута называется доменом, а строки со значениями разных атрибутов — кортежем.
Совокупность нормализованных отношений (реляционных таблиц), логически взаимосвязанных и отражающих некоторую предметную область, образует реляционною базу данных (РБД). В ходе разработки БД должен быть определен состав логически взаимосвязанных реляционных таблиц и определен состав атрибутов каждого отношения. Состав атрибутов должен отвечать требованиям нормализации. Реляционная модель данных зарекомендовала себя как модель, на основе которой могут разрабатываться реальные жизнеспособные приложения. В настоящее время эта модель данных является наиболее популярной.
Объектно-ориентированная модель данных. Реляционная модель данных оказалась эффективной не для всех приложений. Главными среди типов приложений, для которых трудно использовать реляционные базы данных, являются автоматизированное проектирование (Computer Aided design, CAD) и автоматизированная разработка программного обеспечения (Computer Aided Software Engineering, CASE). Разработчики коммерческих продуктов в таких областях, в которых для управления хранением данных используется реляционная СУБД, должны пойти на некоторые изменения данных для того, чтобы подогнать их к структуре строк и столбцов. Как показывает практика, в таких областях, как CAD и CASE более подходит объектно-ориентированная модель данных. В объектно-ориентированных базах данных (ООБД) важнейшее место отводится объектам, на основе которых могут определяться другие объекты благодаря использованию концепции, называемой наследованием. При этом некоторые или все атрибуты (либо свойства) определяющего объекта наследуются каким-то другим объектом, одни атрибуты и свойства добавляются, а другие могут удаляться.
Тенденции и перспективы развития технологий управления ресурсами данных
Перспективы развития архитектур СУБД связаны с развитием концепции обработки нетрадиционных данных и их интеграции, обмена данными из разных СУБД, многопользовательской технологии в локальных сетях.
Одной из важнейших тенденции развития СУБД является разработка «универсальных» СУБД, способных интегрировать в базе традиционные и нетрадиционные данные — тексты, рисунки, звук и видео, страницы HTML и др. Это особенно актуально для Web. Имеются два подхода к построению таких СУБД: объектно-реляццонный — совершенствование существующих реляционных СУБД и объектный.
Следует отметить, что современные реляционные СУБД уже способны интегрировать данные, однако нетрадиционные данные недоступны для внутренней обработки. «Универсальные» СУБД должны выполнять такую обработку. В таких системах не нужны разнородные программы, которыми сложно управлять. По пути создания объектно-реляционных СУБД пошли такие фирмы, как IBM, Informix и Oracle. В IBM разработана объектно-реляционная СУБД DB2 для ОС AIX и OS/2. На начальном этапе фирма Oracle выпустила реляционный продукт Oracle Universal Server, интегрирующий СУБД Oracle (версий 7.3 и выше) и специализированные серверы
(Web, пространственных данных, текстов, видеосообщений), поддерживающие данные в разных хранилищах. В объектно-реляционной Oracle 9 должны быть интегрированы реляционные и нетрадиционные типы данных. Informix создала объектно-реляционную СУБД Universal Server.
Корпорация Microsoft сделала ставку на объектно-ориентированный интерфейс OLE DB, который обеспечивает доступ к данным Microsoft SQL Server (реляционная СУБД).
Фирма Sybase ориентирована на использование специализированных серверов, а интеграцию данных намеревается проводить другими средствами, то есть идет по пути создания объектно-реляционной СУБД (Adaptive- Server).
СУБД с параллельной обработкой данных. Информационные хранилища на базе СУБД с параллельной обработкой рассчитаны на многопроцессорные системы. Такие СУБД разделяются по типу архитектуры — без разделения ресурсов и с совместным использованием дискового пространства. В первом случае за каждым из процессоров закреплены выделенные области памяти и диски, что дает хорошую скорость обработки. Во втором случае все процессоры делят между собой как оперативную память, так и место на диске.
Примерами СУБД без разделения ресурсов являются: DB2 (IBM), Informix Online Dynamic (Informix), Navigation Server (Sybase). СУБД с совместным использованием памяти является AdabasD версия 6.1 (Software AG). В СУБД Oracle 7.2 обеспечивается лучшая переносимость на различные платформы.
Следует заметить, что выбор СУБД целесообразно осуществлять не только по типу архитектуры и качеству внешнего интерфейса, но прежде всего исходя из функциональных возможностей. Важными критериями выбора являются способность обработки сложных запросов (и скорость обработки), возможность переноса между платформами. Хорошей скоростью обработки сложных запросов отличается СУБД DB2 (IBM), а также DSA (Informix).
К современным тенденциям в области хранения и доступа к данным, извлечения знаний относятся технологии Data Warehousing, OnLine Analytical Processing (OLAP), Data Mining
Базы знаний – это знания человека, представленные в памяти компьютера в соответствии с какой-либо моделью.
Можно выделить три способа организации БЗ:
1. Использование правил логического вывода.
2. Применение семантических сетей.
3. Создание БЗ, основанных на фреймах.
Термин знания означает информацию, которая необходима программе, чтобы она вела себя “интеллектуально”. Эта информация принимает форму фактов или правил.
Факт 1. Зажженная плита – горячая.
Правило 1. Если положить руку на зажженную плиту, то можно обжечься.
Факты и правила хранятся в компьютере в так называемой БЗ.
Упрощение (пешеход переходит улицу).
Многие правила ЭС являются эвристическими (упрощенными), которые эффективно ограничивают поиск решения. Алгоритмический метод гарантирует корректное или оптимальное решение задачи, тогда как эвристический метод дает приемлемое решение в большинстве случаев. Знания в ЭС организованы таким образом, чтобы знания о предметной области отделить от других типов знаний системы.
Представление знаний с использованием правил
Правила обеспечивают формальный способ представления рекомендаций, указаний или стратегий; они часто подходят в тех случаях, когда предметные знания возникают из эмпирических ассоциаций, накопленных за годы работы по решению задач в данной предметной области.
БЗ строится на описании фактов и правил вида ЕСЛИ <посылки>, ТО <следствия>. Иногда эти правила называют правилами продукции, а основанные на них системы – продукционными. Последовательность шагов, предпринятых системой для достижения цели, называется цепочкой выводов; в зависимости от алгоритма их построения различают прямую и обратную цепочки.
Процесс достижения целей, через факты, определяющие эти цели, называется прямой цепочкой рассуждений.
Пример:
Если горючая жидкость была разлита, то вызовите пожарных.
Если pH жидкости меньше 6, то разлившийся материал –кислота.
Если разлившийся материал – кислота, и он пахнет уксусом, то разлившийся материал – уксусная кислота.
1. Определение целей.
2. Определение фактов, имеющих отношение к этим целям.
3. Получение данных, соответствующих фактам, характерным для заданной ситуации или объекта.
4. Оценки данных, использование правила или механизма вывода.
Процесс, в котором заключение используется для поиска подтверждающих его данных, называется обратной цепочкой рассуждений.
Пример: полицейский. Заключение – подозреваемый; данные - оружие.
Представление знаний с использованием семантических сетей
Термин семантическая сеть применяется для описания метода представления знаний, основанного на сетевой структуре. Семантические сети были первоначально разработаны для использования их в качестве психологических моделей человеческой памяти, но теперь это стандартный метод представления знаний в ИИ.
СС состоят из точек, называемых узлами, и связывающих их дуг, описывающих отношения между узлами. Узлы в семантической сети соответствуют объектам, концепциям или событиям.
Обычно дуги включают два типа: является и имеет часть.
Представление знаний с использованием фреймов
В области искусственного интеллекта термин фрейм относится к специальному методу представления общих концепций и ситуаций.
Фрейм – это структура данных, представляющая стереотипную ситуацию.
Фрейм по своей организации во многом похож на семантическую сеть. Фрейм является сетью узлов и отношений, организованных иерархически, где верхние узлы представляют общие понятия, а нижние узлы более частные случаи этих понятий.
Пример:
Пока, что это выглядит точно так же как семантическая сеть. Но в системе, основанной на фреймах, понятие в каждом узле определяется набором атрибутов и значениями этих атрибутов, а атрибуты называют слотами. Каждый слот может быть связан с процедурами, которые выполняются, когда информация в слотах меняется.
Три типа процедур встречаются чаще всего:
Сравним базы данных и базы знаний. Для удобства сравнения данных и знаний можно выделить основные формы существования знаний и данных. Как представлено в таблице 3.2, у данных и знаний много общего. Однако знания имеют более сложную структуру, и переход от данных к знаниям является закономерным следствием развития и усложнения информационных структур, обрабатываемых на ЭВМ. Поэтому знания иногда называют хорошо структурированными данными.
Таблица 3.2
Сравнение структур знаний и данных
Технология хранилищ данных Data Warehousing
Во всем мире организации накапливают или уже накопили в процессе своей деятельности большие объемы данных. Эти коллекции данных хранят в себе большие потенциальные возможности по извлечению новой, аналитической информации, на основе которой можно и необходимо строить стратегию фирмы, выявлять тенденции развития рынка, находить новые решения, обусловливающие успешное развитие в условиях конкурентной борьбы. Для некоторых фирм такой анализ является неотъемлемой частью их повседневной деятельности, но большинство, очевидно, только начинает приступать к нему всерьез.
Попытки строить системы принятия решений, которые обращались бы непосредственно к базам данных систем оперативной обработки транзакций (OLTP-систем), оказываются в большинстве случаев неудачными.
Для того чтобы обеспечить возможность анализа накопленных данных, организации стали создавать хранилища данных (Data Warehouse — DW), которые представляют собой интегрированные коллекции данных, которые собраны из различных систем оперативного доступа к данным.
Концепция DW была предложена и в 1992 г. Биллом Инмоном в его книге "Building the Data Warehouse" и стала одной из доминирующих в разработке информационных технологий обработки данных 90-х годов. Англоязычный термин Data Warehousing, который сложно перевести лаконично на русский язык, означает создание, поддержку, управление и использование хранилища данных, что говорит о том, что речь идет о процессе. Цель этого процесса - непрерывная поставка необходимой информации нужным сотрудникам организации. Этот процесс подразумевает постоянное развитие, совершенствование, решение все новых задач и практически никогда не кончается, поэтому его нельзя уместить в более или менее четкие временные рамки, как это можно сделать для разработки традиционных систем оперативного доступа к данным.
Хранилища данных становятся основой для построения систем принятия решений.
Основная цель создания DW в том, чтобы сделать все значимые для управления бизнесом данные доступными в стандартизованной форме, пригодными для анализа и получения необходимых отчетов. Чтобы достигнуть этого, необходимо извлечь данные из существующих внутренних и внешних машиночитаемых источников.
Несмотря на различия в подходах и реализациях, всем хранилищам данных свойственны следующие общие черты: предметная ориентированность; интегрированностъ; привязка ко времени; неизменяемость.
Предметная ориентированность. Информация в хранилище данных организована в соответствии с основными аспектами деятельности предприятия (заказчики, продажи, склад и т.п.); это отличает хранилище данных от оперативной БД, где данные организованы в соответствии с процессами (выписка счетов, отгрузка товара и т.п.). Предметная организация данных в хранилище способствует как значительному упрощению анализа, так и повышению скорости выполнения аналитических запросов. Выражается она, в частности, в использовании иных, чем в оперативных системах, схемах организации данных. В случае хранения данных в реляционной СУБД применяется схема "звезды" (star) или "снежинки" (snowflake). Кроме того, данные могут храниться в специальной многомерной СУБД в n-мерных кубах.
Интегрированностъ. Исходные данные извлекаются из оперативных БД, проверяются, очищаются, приводятся к единому виду, в нужной степени агрегируются (то есть вычисляются суммарные показатели) и загружаются в хранилище. Такие интегрированные данные намного проще анализировать.
Привязка ко времени. Данные в хранилище всегда напрямую связаны с определенным периодом времени. Данные, выбранные из оперативных БД, накапливаются в хранилище в виде "исторических слоев", каждый из которых относится к конкретному периоду времени. Это позволяет анализировать тенденции в развитии бизнеса.
Неизменяемость. Попав в определенный "исторический слой" хранилища, данные уже никогда не будут изменены. Это также отличает хранилище от оперативной БД, в которой данные все время меняются, "дышат", и один и тот же запрос, выполненный дважды с интервалом в 10 минут, может дать разные результаты. Стабильность данных также облегчает их анализ.
Хранилища и киоски данных. Хранилища данных могут быть разбиты на два типа: корпоративные хранилища данных (enterprise data warehouses) и киоски данных (data marts).
Корпоративные хранилища данных содержат информацию, относящуюся ко всей корпорации и собранную из множества оперативных источников для консолидированного анализа. Обычно такие хранилища охватывают целый ряд аспектов деятельности корпорации и используются для принятия как тактических, так и стратегических решений. Корпоративное хранилище содержит детальную и обобщающую информацию; его объем может достигать от 50 Гбайт до одного или нескольких терабайт. Стоимость создания и поддержки корпоративных хранилищ может быть очень высокой. Обычно их созданием занимаются централизованные отделы информационных технологий, причем создаются они сверху вниз, то есть сначала проектируется общая схема, и только затем начинается заполнение данными. Такой процесс может занимать несколько лет.
Киоски данных содержат подмножество корпоративных данных и строятся для отделов или подразделений внутри организации. Киоски данных часто строятся силами самого отдела и охватывают конкретный аспект, интересующий сотрудников данного отдела. Киоск данных может получать данные из корпоративного хранилища (зависимый киоск) или, что более распространено, данные могут поступать непосредственно из оперативных источников (независимый киоск). Основные компоненты DW:
оперативные источники данных;
средства проектирования/разработки;
средства переноса и трансформации данных;
СУБД;
средства доступа и анализа данных;
средства администрирования.
Сферы применения DW:
Сегментация рынка.
Планирование продаж, прогнозирование и управление.
Забота о клиенте.
Разработка схем лояльности.
Проектирование и разработка новых видов продукции.
Интеграция цепочки поставок.
• Интеллектуальные технологии в организации бизнеса.
Программное обеспечение технологии DW. Процессы создания, поддержки и использования хранилищ данных традиционно требовали значительных затрат, что в первую очередь было вызвано высокой стоимостью доступных на рынке специализированных инструментов. Эти инструменты практически не интегрировались между собой, так как были основаны не на открытых и стандартных, а на частных и закрытых протоколах, интерфейсах и т.д. Сложность и дороговизна делали практически невозможным построение хранилищ данных в небольших и средних фирмах, в то время как потребность в анализе данных испытывает любая фирма, независимо от масштаба.
Корпорация Microsoft создала Microsoft Data Warehousing Framework — спецификацию среды создания и использования хранилищ данных. Данная спецификация определяет развитие не только новой линии продуктов Microsoft (например, Microsoft SQL Server 7.0), но и технологий, обеспечивающих интеграцию продуктов различных производителей. Открытость среды Microsoft Data Warehousing Framework обеспечила ее поддержку многими производителями ПО, что, в свою очередь, дает возможность конечным пользователям выбирать наиболее понравившиеся им инструменты для построения своих решений.
Основные поставщики ПО хранилищ данных: Arbor; Hewlett-Packard; IBM; Informix; Microsoft; Oracle; Platinum Technology; SAS Institute; Software AG; Sybase и др. Все эти фирмы имеют страницы в Internet, где приводятся подробные сведения об их продуктах и услугах
Лекция №4
Технологическое обеспечение ИС в экономике
4.1. Определение и состав информационных технологий
См. Романов А.Н., Одинцов Б.Е. Информационные системы в экономике.-М.: Вузовский учебник, 2006.-300с.; с. 118-124.
Особенности современных информационных технологий
Технология анализа OLAP
В предыдущем разделе были подробно рассмотрены технологии хранилищ данных. Теперь перейдем к следующему этапу. После того как данные получены, очищены, приведены к единому виду и помещены в хранилище, их необходимо анализировать. Для этого используется технология OLAP.
Двенадцать определяющих принципов OLAP были сформулированы в 1993 году Е.Ф.Коддом, "изобретателем" реляционных баз данных. OLAP — это OnLine Analytical Processing, то есть оперативный анализ данных. Позже определение Кодда было переработано в так называемый тест FASMI (Fast Analysis of Shared Multidimensional Information — быстрый анализ разделяемой многомерной информации), который требует, чтобы OLAP-приложение предоставляло следующие возможности быстрого анализа разделяемой многомерной информации: высокая скорость; анализ; разделение доступа; многомерность; работа с информацией..
Высокая скорость. Анализ должен производиться одинаково быстро по всем аспектам информации. При этом допустимое время отклика составляет не более 5 секунд.
Анализ. Должна существовать возможность производить основные типы числового и статистического анализа — предопределенного разработчиком приложения или произвольно определяемого пользователем.
Разделение доступа. Доступ к данным должен быть многопользовательским, при этом должен контролироваться доступ к конфиденциальной информации.
Многомерность. Основная, наиболее существенная характеристика OLAP.
Работа с информацией. Приложение должно иметь возможность обращаться к любой нужной информации, независимо от ее объема и места хранения.
Многомерное представление. OLAP предоставляет организациям максимально удобные и быстрые средства доступа, просмотра и анализа деловой информации. Что наиболее важно — OLAP обеспечивает пользователя естественной, интуитивно понятной моделью данных, организуя их в виде многомерных кубов (Cubes). Осями [L1][L2](dimensions) многомерной системы координат служат основные атрибуты анализируемого бизнес-процесса. Например, для процесса продаж это может быть категория товара, регион, тип покупателя. Практически всегда в качестве одного из измерений используется время. Внутри куба находятся данные, количественно характеризующие процесс, — так называемые меры (Measures). Это могут быть объемы продаж в штуках или в денежном выражении, остатки на складе, издержки и т.п. Пользователь, анализирующий информацию, может "нарезать" куб по разным направлениям, получать сводные (например, по годам) или, наоборот, детальные (по неделям) данные и осуществлять прочие операции, которые необходимы ему для анализа.
Хранение данных OLAP. В первую очередь нужно сказать о том, что, поскольку аналитик всегда оперирует некими суммарными (а не детальными) данными, в базах данных OLAP практически всегда хранятся наряду с детальными данными и так называемые агрегаты, то есть заранее вычисленные суммарные показатели. Примерами агрегатов может служить суммарный объем продаж за год или средний остаток товара на складе. Хранение заранее вычисленных агрегатов — это основной способ повышения скорости выполнения OLAP-запросов.
Однако построение агрегатов может привести к значительному увеличению объема базы данных.
Другой проблемой хранения OLAP-данных является разреженность многомерных данных. Например, если в 2000 году продаж в некотором регионе не было, то на пересечении соответствующих измерений куба не будет никакого значения. Если OLAP-сервер будет хранить в таком случае некое отсутствующее значение, то при значительной разреженности данных количество пустых ячеек (требующих, тем не менее, места для хранения) может во много раз превысить количество заполненных, и в результате общий объем неоправданно возрастет. Решения, предлагаемые для этого компанией Microsoft, приводятся ниже.
Разновидности OLAP. Для хранения OLAP-данных могут использоваться:
Специальные многомерные СУБД (OLAP-серверы). В этом случае говорят о MOLAP (Multidimensional OLAP). При выполнении сложных запросов, анализирующих данные в различных измерениях, многомерные СУБД обеспечивают большую производительность, чем реляционные. При этом скорость выполнения запроса не зависит от того, по какому измерению производится «срез» многомерного куба.
Традиционные реляционные СУБД — ROLAP (Relational OLAP). Применение специальных структур данных — схемы «звезды» (star) и «снежинки» (snowflake), а также хранение вычисленных агрегатов делают возможным многомерный анализ реляционных данных. Реляционные СУБД исторически более привычны, и в них сделаны значительные инвестиции, поэтому пока ROLAP более распространен.
Комбинированный вариант — HOLAP (Hybrid OLAP), совмещающий и тот и другой вид СУБД. Одним из вариантов совмещения двух типов СУБД является хранение агрегатов в многомерной СУБД, а детальных данных (имеющих наибольший объем) — в реляционной.
Компания Microsoft предлагает следующие средства OLAP-анализа:
В комплект Microsoft SQL Server 7.0 входит полнофункциональный OLAP-сервер — SQL Server OLAP Services. Сервер, естественно, предназначен для обслуживания запросов клиентов, а для этого требуется некий протокол взаимодействия и язык запросов. Например, для взаимодействия клиента с серверной реляционной СУБД — SQL Server — используются протоколы ODBC или OLE DB и язык запросов SQL. Для доступа к OLAP-серверу компанией Microsoft был разработан протокол OLE DB for OLAP и язык запросов к многомерным данным — MDX (MultiDimensional expression). Аналогично тому, как для упрощения и удобства над OLE DB разработан слой объектов ADO (ActiveX Data Objects), над OLE DB for OLAP построен ADO MD (MultiDimensional ADO).
Средства анализа данных в Microsoft Office Microsoft Excel содержит новый механизм сводных таблиц — OLAP PivotTable, который заменил собой одноименный механизм предыдущих версий. Наряду с прежними возможностями анализа реляционных данных, механизм PivotTable теперь включает возможности анализа OLAP-данных, то есть выступает в качестве OLAP-клиента. В качестве сервера может использоваться Microsoft SQL Server 7.0, а также любой продукт, поддерживающий интерфейс OLE DB for OLAP. Механизм сводных таблиц Excel в полном объеме поддерживает возможности, предоставляемые описанным выше сервисом PivotTable Services (PTS). Таким образом, анализируемые OLAP-данные могут находиться как в локальных кубах, так и на OLAP-сервере.
Microsoft Office содержит также набор ActiveX-компонентов, называемых Office Web Components, которые позволяют организовать анализ OLAP-данных средствами просмотра Web. К ним относятся следующие четыре компонента:
Spreadsheet — реализует ограниченную функциональность листа Excel.
PivotTable — "близнец" сводных таблиц Excel; может работать с данными OLAP Services.
Chart — позволяет строить диаграммы, основанные как на реляционных, так и на OLAP-данных.
Data Source — служебный компонент для привязки остальных компонентов к источнику данных.
При работе с OLAP-данными Web Components обращаются к PivotTable Services.
Технологии распределенной обработки данных. Модель клиент-сервер
Информационные системы, построенные на базе компьютерных сетей, обеспечивают решение следующих задач: хранение данных, обработка данных, организация доступа пользователей к данным, передача данных и результатов обработки данных пользователям. Потребность в данных коллективного пользования в последнее время все более возрастает. Это и послужило причиной усиливающегося внимания к различным системам распределенной обработки данных.
Существует несколько понятий в этой области, которые необходимо определить более точно. Вначале выделим эти понятия:
распределенная обработка данных;
базы данных с сетевым доступом;
архитектура «клиент-сервер»;
распределенные базы данных.
Под распределенной обработкой данных понимают обработку приложений несколькими территориально распределенными компьютерами.
Технология распределенной обработки данных базируется на двух концепциях. Первая концепция носит название «файл - сервер», а вторая — «клиент сервер».
Сервер — это машина, обеспечивающая функционирование той части сетевой версии СУБД, которая осуществляет управление данными в терминах базы данных и называется сервером файлов или файл-сервером (File Server).
Клиент — задача, рабочая станция или пользователь компьютерной сети. В процессе обработки данных клиент может сформировать запрос на сервер для выполнения сложных процедур, чтение файла, поиск информации в базе данных и т. д.
Предполагается, что центральная машина (сервер) обладает жестким диском достаточно большой емкости, на котором хранится совместно используемая централизованная база данных. Все другие машины сети выполняют функции рабочих станций (клиентов), с помощью которых поддерживается доступ пользователей системы к централизованной базе данных. В соответствии с пользовательскими запросами файлы базы данных передаются на рабочие станции, где в основном и производится их обработка. Рабочая станция должна иметь достаточно ресурсов для обеспечения приемлемого уровня реактивности при обработке пользовательских запросов.
Первая концепция распределенной обработки данных реализуется следующим образом. В сети имеется главный компьютер, который называется файловым сервером. Сервер предоставляет в совместное пользование информационные (файлы, базы данных) и аппаратные ресурсы (принтеры, модемы). Сетевая операционная система, обеспечивающая взаимодействие пользователей с сервером состоит из двух частей: одна (основная) часть находится на файловом сервере, а вторая (оболочка) устанавливается на компьютерах сети (рабочих станциях). Оболочка обеспечивает взаимодействие (является интерфейсом) между программами рабочей станции и сервера. Файловый сервер в рамках такой архитектуры используется только как хранилище данных, а их обработка осуществляется на компьютере пользователя (рабочей станции).
В рамках концепции «клиент — сервер» сервер используется не только как хранилище программ и данных, но и как вычислительная среда. Программное обеспечение в рассматриваемой модели состоит из двух взаимосвязанных программ: «файл-сервера» и программы клиента - пользователя. Программа - клиент формирует запрос и посылает его файл - серверу (программе), установленной на компьютере с общим доступом. Обработка данных и осуществляется на мощном компьютере общего пользования, а на компьютере-клиенте с помощью соответствующего протокола отображаются результаты выполненного запроса. При этом постарайтесь не запутаться в терминах: «сервером» называют как компьютер, так и программное обеспечение.
Системы баз данных, построенные с помощью сетевых версий, иногда неправомерно называют распределенными базами данных, в то время как они фактически являются лишь распределенным (сетевым) доступом к централизованной базе данных. Такие системы создаются на основе оборудования и программного обеспечения различных типов локальных вычислительных сетей.
Экспертные системы
Постоянно возрастающие требования к средствам обработки информации в экономике и социальной сфере стимулировали компьютеризацию процессов решения эвристических (неформализованных) задач типа «что будет, если», основанных на логике и опыте специалистов. Основная идея при этом заключается в переходе от строго формализованных алгоритмов, предписывающих, как решать задачу, к логическому программированию с указанием, что нужно решать на базе знании, накопленных специалистами предметных областей. Для решения задач подобного класса используются так называемые экспертные системы (ЭС).
Основу экспертных систем составляет база знаний, в которую закладывается информация о данной предметной области. Имеются две основные формы представления знаний в ЭС: факты и правила. Факты фиксируют количественные и качественные показатели явлений и процессов. Правила описывают соотношения между фактами, обычно в виде логических условий, связывающих причины и следствия.
Экспертные системы — это системы обработки знаний в узкоспециализированной области подготовки решений пользователей на уровне профессиональных экспертов.
Экспертные системы используются для таких целей как:
интерпретация состояния систем;
прогноз ситуаций в системах;
диагностики состояния систем;
целевое планирование;
устранение нарушений функционирования системы;
управление процессом функционирования; и т. д.
В качестве средств компьютерной реализации экспертных систем используют так называемые оболочки экспертных систем. Примерами оболочек экспертных систем, применяемых в экономике, являются: Шэдл (Диалог), Expert-Ease и др. Сложность создания ЭС и поддержки их в актуальном состоянии порождает их высокую стоимость.
См. Романов А.Н., Одинцов Б.Е. Информационные системы в экономике.-М.: Вузовский учебник, 2006.-300с.; с. 132-138.
Лекция №5
Защита информации в экономических информационных системах
5.1 Информационная безопасность — составляющая экономической безопасности
Становление рыночной экономики в России породило ряд проблем. Одной из таких проблем является обеспечение безопасности бизнеса. На фоне высокого уровня криминализации общества, проблема безопасности любых видов экономической деятельности становится особенно актуальной. Информационная безопасность среди других составных частей экономической безопасности (финансовой, интеллектуальной, кадровой, технико-технологической, политико-правовой, экологической, маркетинговой и физической) является одной из главных составляющих.
Термин "безопасность" в законе РФ «О безопасности» определяется как "состояние защищённости жизненно важных интересов личности, общества, государства от внутренних и внешних угроз». Состояние защищенности — это стабильно прогнозируемое во времени состояние окружения, в котором предприятие может осуществлять свои уставные задачи без перерывов, нарушений и потери конкурентоспособности
Следует различать понятия информационная безопасность и безопасность информации. Первое понятие охватывает более широкий круг проблем. Согласно Доктрине информационной безопасности России информационная безопасность — состояние защищённости информационной сферы (информационной среды общества), обеспечивающее её формирование и развитие в интересах граждан, организаций и государства. Жизненно важные интересы — совокупность потребностей, обеспечивающих существование и прогрессивное развитие. Объекты безопасности — личность, её права и свободы, общество — его духовные и материальные ценности, государство — его конституционный строй, суверенитет и территориальная целостность. С точки зрения информационной безопасности необходимо защитить граждан (информационная безопасность личности) от ненужной информации, от разрушающего психику и сознание потока информации. С другой стороны, необходимо обеспечить право граждан на информацию.
Информационная безопасность как составная часть экономической безопасности предпринимательской деятельности включает в себя: а) комплексную программу обеспечения безопасности информационных ресурсов предприятия и б) экономически обоснованную технологическую систему защиты, обеспечивающую должный уровень защищенности, готовности, надежности ИС и безопасность информации.
Безопасность информации — это обеспечение ее конфиденциальности, целостности и доступности законным пользователям. Безопасность информации - состояние защищённости информации, обрабатываемой средствами вычислительной техники (ВТ), находящуюся на машинных и традиционных носителях, от внутренних и внешних угроз.
Угрозам — случайным или намеренным действиям, выводящим фирму, независимо от рода ее деятельности, из состояния безопасности со стороны внешнего окружения и внутренних источников подвержены персонал, имущество, информация и товары при перемещении. Кроме того, фирма может быть признана виновной в судебном порядке за ущерб, нанесённый третьим лицам (включая и собственных служащих) или собственности.
Таким образом, можно определить цель обеспечения безопасности информации, которая заключается в защите прав собственности на неё, и задачи безопасности, которые заключаются в защите её от утечки, копирования, блокирования, модификации и утраты.
5.2. Концептуальная модель защиты информации
Для организации системы защиты на конкретном предприятии необходимо провести анализ источников и видов информации, требующих защиты, выполнить анализ угроз безопасности и возможные способы реализации угроз, а также выбрать соответствующие способы и средства защиты.
В самом общем виде решению такой задачи может помочь концептуальная модель защиты информации (см.рис.5.1)
Схема в виде последовательных блоков представляет содержание системы обеспечения защиты информации. Рассмотрим последовательно каждый из блоков.
Источники информации. Источник информации — это материальный объект, обладающий определёнными сведениями (информацией), представляющей конкретный интерес для злоумышленников или конкурентов. Выделяются следующие категории источников:
Люди (сотрудники, обслуживающий персонал, продавцы, клиенты и т.д.)
Документы различного характера и назначения. Публикации: доклады, статьи, интервью, проспекты, книги, специализированные периодические издания.
Технические носители информации. Наиболее точное описание носителей дано в законе "О государственной тайне" " Носители сведений —материальные объекты, в том числе физические поля, в которых сведения, составляющие тайну, находят своё отображение в виде символов, образов, сигналов, технических решений и процессов.
5. Технические средства обработки информации, средства связи и средства обеспечения производственной и трудовой деятельности.
Выпускаемая продукция.
Производственные и промышленные отходы.