Проектирование информационных систем

КОНСПЕКТ ЛЕКЦИЙ по дисциплине «Проектирование информационных систем» Часть 1 Оглавление 2 ЛЕКЦИЯ 1. ТЕХНОЛОГИИ ФАЙЛ-СЕРВЕР И КЛИЕНТ-СЕРВЕР ........................................3 ЛЕКЦИЯ 2. СТАНДАРТЫ ПРОИЗВОДСТВЕННЫХ ИНФОРМАЦИОННЫХ СИСТЕМ ..5 ЛЕКЦИЯ 3. КЛАССИФИКАЦИЯ КОМПЬЮТЕРНЫХ СИСТЕМ УПРАВЛЕНИЯ ПРЕДПРИЯТИЕМ ................................................................................................................................7 ЛЕКЦИЯ 4. ЖИЗНЕННЫЙ ЦИКЛ ИНФОРМАЦИОННЫХ СИСТЕМ ..................................9 ЛЕКЦИЯ 5. НОВОЕ СИСТЕМНОЕ ПРОЕКТИРОВАНИЕ ......................................................12 ЛЕКЦИЯ 6. МЕТОДОЛОГИИ И ТЕХНОЛОГИИ ПРОЕКТИРОВАНИЯ ИС ......................15 ЛЕКЦИЯ 7. СТРУКТУРНЫЙ ПОДХОД К ПРОЕКТИРОВАНИЮ ИС .................................18 ЛЕКЦИЯ 8. МОДЕЛИРОВАНИЕ ДАННЫХ. МЕТОДОЛОГИЯ IDEF1 .................................20 ЛЕКЦИЯ 9. ОБЪЕКТНО-ОРИЕНТИРОВАННЫЙ ПОДХОД К ПРОЕКТИРОВАНИЮ ИНФОРМАЦИОННЫХ СИСТЕМ .................................................................................................22 ЛЕКЦИЯ 10. CASE-ТЕХНОЛОГИЯ ...............................................................................................24 ЛЕКЦИЯ 11. ХАРАКТЕРИСТИКА СОВРЕМЕННЫХ CASE-СРЕДСТВ ..............................27 ЛЕКЦИЯ 12. КОРПОРАТИВНЫЕ ИНФОРМАЦИОННЫЕ СИСТЕМЫ ..............................29 ЛЕКЦИЯ 13. ЭТАПЫ И СРЕДСТВА ПОСТРОЕНИЯ КИС ......................................................31 ЛЕКЦИЯ 14. ERP-СИСТЕМЫ: ОСНОВНЫЕ ЗАДАЧИ И ОБЛАСТЬ ПРИМЕНЕНИЯ ....33 ЛЕКЦИЯ 15. ПРИМЕНЕНИЕ ИГРОВОГО МОДЕЛИРОВАНИЯ В УПРАВЛЕНИИ .........35 ЛЕКЦИЯ 16. ИНТЕГРИРОВАННАЯ ИНФОРМАЦИОННО-УПРАВЛЯЮЩАЯ СИСТЕМА РГУ НЕФТИ И ГАЗА ИМ. И.М.ГУБКИНА ..................................................................................37 ЛЕКЦИЯ 17. ОБЕСПЕЧИВАЮЩИЕ ПОДСИСТЕМЫ ИИУС РГУ НЕФТИ И ГАЗА ИМ. И.М.ГУБКИНА....................................................................................................................................40 СОКРАЩЕНИЯ ..................................................................................................................................44 ЛИТЕРАТУРА .....................................................................................................................................45 3 ЛЕКЦИЯ 1. ТЕХНОЛОГИИ ФАЙЛ-СЕРВЕР И КЛИЕНТ-СЕРВЕР Технология файл-сервер (file/server) стала применяться, когда персональные компьютеры стали объединять в сеть, а пользователи - работать с общими данными, расположенными в виде файлов на специальном компьютере-сервере. Поиск и обработка данных происходит на рабочих станциях – клиентских местах. Технология подразумевает, что на каждой станции находится свой экземпляр СУБД и другое программное обеспечение. Сюда присылаются не только данные, необходимые конечному пользователю, но и данные, которые будут использоваться для выполнения запроса. Объем лишней информации может быть очень велик. Время обработки запроса складывается из времени передачи данных с файл-сервера на рабочую станцию и времени выполнения запроса на рабочей станции. Для сокращения этого времени надо увеличить скорость работы с диском, пропускную способность сетевой шины, а также взять в качестве рабочей станции более мощный компьютер (для каждой рабочей станции!). Файл-серверная система имеет следующие недостатки: большая нагрузка на сеть и повышенные требования к ее пропускной способности; повышенные требования к ПК ввиду того, что обрабатываются данные на рабочем месте пользователя; невозможность одновременной работы с данными; невозможность соблюдения безопасности данных. В технологии клиент-сервер (client/server) СУБД и обработка перенесены на сервер, а на рабочем месте пользователя только формируются запросы и отображаются результаты. Простейшей является двухзвенная архитектура клиент-сервер (рис.1.1). В этом случае вся прикладная часть информационной системы выполняется на рабочих станциях, сервером осуществляется только доступ к базе данных. Если логика прикладной части системы достаточно сложна, то такой подход порождает проблему "толстого" клиента. Каждая рабочая станция должна быть достаточно мощной . Рис.1.1.Традиционная двухзвенная архитектура клиент-сервер Чтобы клиенты стали ―тонкими‖, для повышения общей эффективности системы применяются трехзвенные архитектуры клиент-сервер (рис.1.2). Вводится промежуточный сервер приложений. Он поддерживает всю логику обработки информации. На стороне клиента выполняются только интерфейсные действия. Рис.1.2.Трехзвенная архитектура клиент-сервер с выделенным сервером приложений При больших вычислительных нагрузках применяется многозвенная архитектура. Программа клиент-сервер распределяется по дополнительным процессорам или звеньям, обеспечивающих дополнительную вычислительную мощность. 4 В технологии клиент-сервер узким местом является компьютер-сервер. Он должен обладать большими ресурсами. Обычно клиент посылает запросы базе данных в виде предложений на SQL. Язык структурированных запросов SQL (Structured Query Language) де-факто с 1976 г. (а с 1987 г. де-юре) является стандартом и реализован для большинства СУБД, работающих в режиме клиент-сервер. Например, ПК, работающий под управлением Windows 95 и выполняющий программу клиент-сервер Delphi, может представить на рассмотрение запрос серверу баз данных (скажем, программе Oracle7, редакция 7.2, запущенной на сервере Windows NT). Существуют три основных программных компонента архитектуры клиент-сервер: ПО конечного пользователя, промежуточное обеспечение и ПО сервера. К ПО конечного пользователя относятся средства разработки программ и генераторы отчетов (в том числе электронные таблицы, текстовые процессоры). Например, в пакете Microsoft Excel for Windows 95 используется интерфейс для связи с подавляющим большинством серверов баз данных и "перекачки" данных в ожидающую электронную таблицу для локальной обработки пользователем. Средства разработки ПО конечного пользователя - Delphi, PowerBuilder, Visual. Они обладают способностями быстрой разработки приложений RAD (Rapid application development), что позволяет разработчикам составлять прикладные программы из заготовленных компонентов. Для лиц, ответственных за принятие решений, клиент-сервер означает простой доступ к корпоративной информации с помощью систем, содействующих принятию решений (decision support system - DSS), многие из которых используют DSS-технологию, называемую оперативным анализом (online analytical processing - OLAP). Промежуточное обеспечение связывает ПО конечного пользователя с сервером. Его задача - оградить ПО конечного пользователя и сервер от сложностей взаимодействий с операционной системой, сетью и вызовов самого сервера. Имеются следующие виды промежуточного обеспечения: созданное специально для СУБД; использующее исключительно сообщения; использующее брокеров объектных запросов; выполняющее обработку транзакций. При создании многозвенных программ разработчики используют средства разделения прикладных программ или распределенные объекты. Главная задача ПО сервера - обеспечить надежный доступ к разделяемым данным для программклиентов. Большинство применяемых в настоящее время серверов - серверы реляционных баз данных (SQLсерверы или SQL-процессоры). Наиболее известны разработки фирм Oracle, Sybase, Informix. Но активно развиваются объектно-ориентированные серверы баз данных. Серверы объектно-ориентированных баз данных, такие как GemStone компании GemStone Systems, хранят информацию в форме объектов, что больше подходит для средств разработки программ-клиентов, которые работают с объектной моделью. В объектно-ориентированных СУБД лучше, чем в реляционных, организовано хранение сложных структур данных. ПО сервера обеспечивает не только поиск информации, но и защиту данных от параллельного и несанкционированного доступа, оптимизирует запросы, обеспечивает кэширование и контроль завершения транзакции. Пример широкомасштабной индустрии на базе технологии клиент-сервер - World Wide Web. Все клиенты Web выполняют стандартные программы конечного пользователя (такие, как Netscape). Все клиенты и серверы Web используют слой стандартного промежуточного обеспечения HTTP, их взаимодействие не зависит от используемого аппаратного обеспечения и ОС. Технология клиент-сервер работает как гардероб в театре, где каждый зритель передает гардеробщику номерок (запрос) и получает свое пальто (результат выполнения запроса). Технология файл-сервер работает как гардероб в школе, где в раздевалку врывается ватага школьников (несколько СУБД, выбирающие свои данные) и, толкаясь, забирает каждый свое пальто (данные). Лучше или хуже будет работать та или иная технология, будет зависеть от размеров БД, характера и интенсивности запросов, соотношения производительности аппаратных средств и многих других факторов. 5 ЛЕКЦИЯ 2. СТАНДАРТЫ ПРОИЗВОД- СТВЕННЫХ ИНФОРМАЦИОННЫХ СИСТЕМ Ядром каждой производственной системы являются воплощенные в ней рекомендации по управлению производством. Существует четыре свода таких рекомендаций и соответствующих стандарта производственных ИС. Исходным стандартом, появившимся в 70-х годах, был стандарт MRP (Material Requirements Planning), включавший только планирование материалов для производства. MRP-системы в настоящее время присутствуют практически во всех интегрированных информационных системах управления предприятием. Основная идея MRP-систем состоит в том, что любая учетная единица материалов или комплектующих, необходимых для производства изделия, должна быть в наличии в нужное время и в нужном количестве. Рис.2.1. Элементы MRP-системы    Входные элементы MRP: Основной производственный план-график (ОПП) - Master Production Schedule (MPS). Система MRP осуществляет детализацию ОПП в разрезе материальных составляющих. После проведения необходимых итераций ОПП утверждается как действующий и на его основе осуществляется запуск производственных заказов. Ведомость материалов (ВМ) и состав изделия (СИ). Состояние запасов. На основании входных данных MRP-система выполняет следующие основные операции: на основании ОПП определяется количественный состав конечных изделий для каждого периода времени планирования, к составу конечных изделий добавляются запасные части, не включенные в ОПП, для ОПП и запасных частей определяется общая потребность в материальных ресурсах в соответствии с ВМ и составом изделия с распределением по периодам времени планирования, общая потребность материалов корректируется с учетом состояния запасов для каждого периода времени планирования, осуществляется формирование заказов на пополнение запасов с учетом необходимых времен опережения. Результатами работы MRP-системы являются: план-график снабжения материальными ресурсами производства - количество каждой учетной единицы материалов и комплектующих для каждого периода времени для обеспечения ОПП. Для реализации плана-графика снабжения система порождает график заказов в привязке к периодам времени, который используется для размещения заказов поставщикам материалов и комплектующих или для планирования самостоятельного изготовления, изменения плана графика снабжения – внесение корректировок в ранее сформированный план-график снабжения производства, ряд отчетов, необходимых для управления процессом снабжения производства. 6 Одной из составляющих интегрированных информационных систем управления предприятием класса MRP является система планирования производственных мощностей. Основной задачей этой системы является проверка выполнимости MPS с точки зрения загрузки оборудования. Системы MRP-II (Manufacturing Resources Planning) являются дальнейшим развитием систем MRP и ориентированы на эффективное планирование всех ресурсов производственного предприятия. Стандарт APICS на системы класса MRP-II содержит описание 16 групп функций системы, среди которых, кроме MRP, планирование продаж и производства, управление спросом, управление складом, планирование потребностей в мощностях, контроль входа/выхода, управление финансами, моделирование, оценка результатов деятельности и др. Системы MRP-II предполагают вовлечение в информационную интеграцию финансовой составляющей (планирование бизнеса). В системах MRP-II предполагается специальный инструментарий формирования финансового плана и составления бюджетных смет, прогнозирования и управления движением денежных средств, на основании которых определяется возможность реализации производственного плана с точки зрения наличных и предполагаемых денежных средств. Фирма ―АйТи‖, разработчик системы ―БОСС-Корпорация‖, берется достичь соответствия ее стандарту MRP-II в 2003-2004 г., т.к. это потребует существенного пересмотра идеологии всей системы. ―Никос-Софт‖ называют 2002 г. для своей системы NS2000, в ―Атлант-Информ‖ по системе ―Аккорд‖ заявляют 2001 г. ―Информконтакт‖ систему ―Альфа‖ до MRP-II доводит уже в 2000 г. Лишь фирма ―Цефей‖ утверждает, что ее система ―Эталон‖ уже относится к ERP-классу. ERP-системы (Enterprise Resources Planning), кроме вышеуказанной функциональности, включают планирование ресурсов распределения (DRP – I, DRP – II), и ресурсов для проведения технологического обслуживания и выполнения ремонтов. Системы DRP обеспечивают оптимальное решение (планирование, учет и управление) транспортных задач по перемещению материально-технических ресурсов и готовой продукции. Кроме этого, для MRP-II и ERP систем характерно наличие специальной подсистемы управления реализацией долгосрочных проектов (Project Management), предполагающей полнофункциональное планирование материальных ресурсов, трудовых ресурсов, оборудования, формирования сетевых графиков работ, управление ходом выполнения и фактурирование реализуемых проектов. Последний по времени стандарт CSRP (Customer Synchronized Resource Planning) охватывает также и взаимодействие с клиентами: оформление наряд-заказа, техзадание, поддержка заказчика на местах и пр. Таким образом, если MRP, MRP-II, ERP ориентировались на внутреннюю организацию предприятия, то CSRP вышел "за ворота" отдельного предприятия и включил в себя полный цикл от проектирования будущего изделия, с учетом требований заказчика, до гарантийного и сервисного обслуживания после продажи. Внедрение подобных систем способно привести к сокращению запасов до 30 процентов, росту производительности труда на 27 процентов, возрастанию количества заказов, выполненных в срок - на 20 процентов. 7 ЛЕКЦИЯ 3. КЛАССИФИКАЦИЯ КОМПЬЮТЕРНЫХ СИСТЕМ УПРАВЛЕНИЯ ПРЕДПРИЯТИЕМ Финансово-управленческие системы Это локальные и малые интегрированные системы (западное название "Low End PC" и "Middle PC"). Такие системы предназначены для ведения учета по одному или нескольким направлениям (бухгалтерия, сбыт, склад, учет кадров и т.д.), универсальны, легко адаптируются к нуждам конкретного предприятия (есть специальные программы-конструкторы), способны работать на персональных компьютерах или локально, или в сетях под управлением Novell Netware или Windows NT, в основном опираются на технологию выделенного сервера базы данных (file server), в основном подготовлены настольными средствами разработки Clipper, FoxPro, dBase, Paradox, отдельные из предлагаемых в России систем такого класса разработаны для промышленных баз данных (Oracle, SYBASE, Progress, Informix, SQL Server) в технологии клиентсервер. Табл. 3.1. Локальные сиМалые интегриСредние интеКрупные интестемы рованные систе- грированные си- грированные симы стемы стемы Предста1С Concorde XAL JD SAP/R3 вители Exact NS-2000 Edwards (SAP AG) БЭСТ групп Platinum (Robertson Baan Инотек PRO/MIS & Blums) (Baan) ИНФИН Scala SunSystems MFG-Pro BPCS Инфософт (QAD/BM БОСС(ITS/SSA) ТурбоКорпорация S) Oracle Бухгалтер ГалактиSyteLine Application Инфока/Парус (СОКАП/ s Бухгалтер SYMIX) (Oracle) Ресурс + более Эталон 100 систем Внедрение Функциональ-ная полнота Соотношение затрат лицензия/ внедрение/ оборудование Ориентировочная стоимость Простое, коробочный вариант Учетные системы (по направлениям) Поэтапное или Только поэтапное Поэтапное, сложкоробочный ваБолее 6-9-ти меное риант сяцев Более 9-12-ти меБолее 4-х месяцев сяцев Комплексный Комплексное управление: учет, учет и управлеуправление, производство ние финансами 1/ 0.5/ 2 1/ 1/ 1 1/ 2/ 1 1/ 1-5/ 1 5-50 тысяч USD 50-300 тысяч USD 200-500 тысяч USD 500 тысяч, > 1 миллиона USD Производственные системы 8 Это средние и крупные интегрированные систе- мы ("High End PC", ERP-системы). Эти системы предназначены для управления и планирования, прежде всего, производственного процесса. Учетные функции, хотя и глубоко проработаны, выполняют вспомогательную роль. Информация, например, в бухгалтерию поступает автоматически из других модулей, значительно более сложны в установке, часто ориентированы на одну или несколько отраслей и/или типов производства: серийное сборочное, мало-серийное и опытное, дискретное (металлургия, химия, упаковка), непрерывное (нефте- и газодобыча), по многим параметрам значительно более жесткие, чем финансово-управленческие, эффект от внедрения производственных систем чувствуется на верхних эшелонах управления предприятием, когда видна вся взаимосвязанная картина работы, разработаны с помощью промышленных баз данных, в большинстве случаев используется технология клиент-сервер. могут работать на разных платформах (NT, UNIX, AS/400, мэйнфреймы). Современные ИС подразделяются также по масштабам применения на три основные класса: 1. Настольные - для работы одного человека. К ним следует отнести Автоматизированное Рабочее Место (АРМ) бухгалтера, АРМ кассира, АРМ расчетчика заработной платы и т.д. Внедрение таких программ не вызывает особых трудностей и для хороших систем может исчисляться днями. Основные проблемы возникают при объединении информации с разных участков учета - данные хранятся на разных компьютерах. Например, один и тот же объект (материал, товар, изделие) на разных АРМах может иметь разные коды. 2. Офисные - для работы отдела. Это сетевые бухгалтерские программы, программы автоматизации торгового зала, сетевые складские программы и т.д. Сотрудники всего отдела могут одновременно работать с единой базой данных, выполняя отдельную функцию управления предприятием. 3. Корпоративные - для работы целого предприятия или даже нескольких предприятий. 9 ЛЕКЦИЯ 4. ЖИЗНЕННЫЙ ЦИКЛ ИНФОР- МАЦИОННЫХ СИСТЕМ Жизненный цикл (ЖЦ) - одно из базовых понятий методологии проектирования ИС. Это непрерывный процесс, который начинается с момента принятия решения о необходимости создания ИС и заканчивается в момент ее полного изъятия из эксплуатации. Основным нормативным документом, регламентирующим ЖЦ, является международный стандарт ISO/IEC 12207 (ISO - International Organization of Standardization - Международная организация по стандартизации, IEC - International Electrotechnical Commission - Международная комиссия по электротехнике). Он определяет структуру ЖЦ, содержащую процессы, действия и задачи, которые должны быть выполнены во время создания ИС. Структура ЖЦ по стандарту ISO/IEC 12207 базируется на трех группах процессов: основные процессы ЖЦ (приобретение, поставка, разработка, эксплуатация, сопровождение); вспомогательные процессы (документирование, управление конфигурацией, обеспечение качества, аттестация, аудит, решение проблем); организационные процессы (управление проектами, создание инфраструктуры проекта, улучшение самого ЖЦ, обучение). Управление конфигурацией позволяет организовать, систематически учитывать и контролировать внесение изменений в ПО на всех стадиях ЖЦ. Обеспечение качества проекта - верификация, тестирование ПО. Верификация - это процесс определения того, отвечает ли текущее состояние разработки требованиям данного этапа. Для этого проводится тестирование. Управление проектом - планирование и организация работ, создание коллективов разработчиков, контроль за сроками и качеством выполняемых работ. Техническое и организационное обеспечение проекта включает выбор методов и инструментальных средств для реализации проекта, определение методов описания промежуточных состояний разработки, разработку методов и средств испытаний ПО, обучение персонала и т.п. Модель ЖЦ - структура, определяющая последовательность выполнения и взаимосвязи процессов, действий и задач, выполняемых на протяжении ЖЦ. Наибольшее распространение получили две основные модели ЖЦ: каскадная модель (70-85 гг.); спиральная модель (86-90 гг.). Каскадный способ - разбиение всей разработки на этапы, причем переход с одного этапа на следующий происходит только после того, как будет полностью завершена работа на текущем (рис.4.1). Положительные стороны применения каскадного подхода: на каждом этапе формируется законченный набор проектной документации, отвечающий критериям полноты и согласованности; выполняемые в логичной последовательности этапы работ позволяют планировать сроки завершения всех работ и соответствующие затраты. Каскадный подход хорошо зарекомендовал себя при построении ИС, для которых в самом начале разработки можно достаточно точно и полно сформулировать все требования. В эту категорию попадают сложные расчетные системы, системы реального времени и другие подобные задачи. 10 Рис.4.1. Схема каскадного подхода Однако реально в процессе создания ИС постоянно возникает потребность в возврате к предыдущим этапам, уточнении или пересмотре ранее принятых решений. Реальный процесс создания ИС принимает следующий вид (рис. 4.2): Рис.4.2. Реальный процесс создания ИС на базе каскадной модели Одно из использовавшихся в западной литературе названий такой схемы организации работ: "водопадная модель" (waterfall model). Основным недостатком каскадного подхода является существенное запаздывание с получением результатов. Модели (как функциональные, так и информационные) автоматизируемого объекта могут устареть одновременно с их утверждением. Другой недостаток – такое проектирование ИС ведет к примитивной автоматизации (по сути - "механизации") существующих производственных действий работников. В спиральной модели ЖЦ (рис. 4.3), делается упор на начальные этапы ЖЦ: анализ и проектирование. Реализуемость технических решений проверяется путем создания прототипов. Рис.4.3. Спиральная модель ЖЦ 11 Каждый виток спирали соответствует созданию нового фрагмента или версии ИС, на нем уточняются цели и характеристики проекта, определяется его качество и планируются работы следующего витка спирали. Один виток спирали при этом представляет собой законченный проектный цикл по типу каскадной схемы. Такой подход назывался также «Продолжающимся проектированием». Позднее в проектный цикл дополнительно стали включать стадии разработки и опробования прототипа системы. Это называлось: "быстрое прототипирование", rapid prototyping approach или "fast-track". Однако применение таких методов наряду с быстрым эффектом дает снижение управляемости проектом в целом и стыкуемости различных фрагментов ИС. Основная проблема спирального цикла - определение момента перехода на следующий этап. Переход осуществляется в соответствии с планом, даже если не вся запланированная работа закончена. План составляется на основе статистических данных, полученных в предыдущих проектах, и личного опыта разработчиков. 12 ЛЕКЦИЯ 5. НОВОЕ СИСТЕМНОЕ ПРОЕК- ТИРОВАНИЕ М. Хаммер (Michael Hammer) в 1990 г. выдвинул лозунги: "Реконструируйте работы не автоматизацией, а упрощением или удалением"; "Используйте компьютеры не только для автоматизации, но и для реконструкции существующих бизнес-процессов". Термин BPR (business process reengineering, реконструкция бизнес-процессов) был введен в 1993 г. в докладе Хаммера и Чампи. Его определение: "BPR - фундаментальное переосмысление и радикальная реконструкция бизнес-процессов с целью достижения значительных улучшений в критически важных в современных условиях уровнях критериев производительности, таких как стоимость, качество, услуги, скорость". "Бизнес-процессы - это логические серии взаимозависимых действий, которые используют ресурсы предприятия для создания или получения в обозримом или измеримо предсказуемом будущем полезного для заказчика выхода, такого как Продукт или Услуга". Главной целью BPR является резкое ускорение реакции предприятия на изменения в требованиях потребителей (или на прогноз таких изменений) при многократном снижении затрат всех видов. В BPR на первый план выведены цели и методы, диктуемые новой ситуацией в мире:  резкое снижение затрат времени на выполнение функций;  резкое снижение числа работников и затрат средств на выполнение функций;  глобализация бизнеса: работа с клиентами и партнерами в любой точке мира;  работа с клиентом в режиме 24*365;  опора на рост мобильности персонала;  работа на будущие потребности клиента;  ускоренное продвижение новых технологий;  движение в информационное общество (и "общество знаний"). Примером может быть банк, который готов предоставить свои услуги клиенту в любой точке, где есть телефон или банкомат. Другой пример - фирма-поставщик конторских компьютерных систем, которая примет заказ по телефону, рассмотрит план помещений и спецификацию, получив их по электронной почте, подпишет договор по почте с электронной подписью и поставит систему в офис заказчика, а тому не существенно, где физически расположены штаб-квартира, склад и т.п. В результате всей суммы произошедших изменений стало возможным говорить о возникновении нового направления разработки Автоматизированных Информационных Систем. Это направление, новое системное проектирование (НСП) - является интеграцией подходов бизнесреинжиниринга, новых Информационных Технологий (ИТ) и социопсихологических методов, позволяющих учесть то, что в производственных процессах и в ИС должны работать конкретные люди. Объявление НСП оправдано, в первую очередь, новыми требованиями к создаваемым корпоративным ИС, а также новыми методами проектирования, развиваемыми в самих ИТ. Схема на рис. 5.1 образована пересечением трех источников НСП: А - новые ИТ и их собственные методы проектирования систем, не связанные прямо с организационнопроизводственными приложениями; Б - бизнес-реинжиниринг как сумма методов реконструкции управления предприятием, причем методов той глубины и радикальности, которые нужны и допустимы в конкретном случае; С - социопсихология, психология труда, другие методы учета "человеческого фактора". Рис 5.1. Три составных части НСП Область АБ - пересечение А и Б - дает методы по- 13 строения ИС для современных корпораций, ко- торые еще не могут считаться законченными, так как в них не учтены возможности, цели и ограничения человека. Область БС - пересечение Б и С - дает методы бизнес-реинжиниринга с учетом всех необходимых рекомендаций социопсихологов и оргконсультантов, но без методов новых ИТ еще не дает нужных результатов ни для BPR, ни для тотального бизнес-реинжиниринга киберкорпораций. Область АС - пересечение А и С - дает методы построения приложений, пользовательских интерфейсов и т.п., учитывающих требования инженерной психологии и эргономики, но не методы проектирования систем для современных корпораций. Особенность этой схемы применительно к нашему времени и к НСП состоит в том, что каждый из трех источников приобрел критическую массу свойств. Степень пересечения и взаимопроникновения этих источников во много раз увеличилась по сравнению с 70-ми и даже 80-ми годами. В результате возникло реально существующее пересечение всех трех источников - область АБС, которая и представляет собой область Нового Системного Проектирования. Работы в НСП используются в той последовательности, которая адаптируется к условиям конкретного предприятия и проекта ИС. В соответствии с этим рис.5.2 иллюстрирует работы НСП в виде модели-"ромашки". Примеры работ НСП и используемых в них методов. Ситуационный и диагностический анализ положения предприятия. Применяются методы и программные инструменты: финансового анализа положения предприятия (финансовой устойчивости, ликвидности баланса, коэффициентов деловой активности и др.); степени и динамики прибыльности отдельных товаров и процессов (продуктов, услуг, технологий, работ); маркетингового анализа (товаров и услуг, имиджа предприятия и конкурентов и др.) на различных секторах рынка; социопсихологического анализа (установок руководства предприятия, кадровой ситуации в целом), его информационной поддержки и автоматизации. Рис. 5.2. Работы Нового Системного Проекти- 14 рования Маркетинговая организация фирмы как производителя рыночных товаров (услуг). Разрабатываются или покупаются информационно-аналитические системы для поддержки выполнения маркетинговых экспертиз в жизненном цикле товара, применяются системы поддержки хранилищ данных (Data WareHouse - DWH) и оперативной аналитической обработки (OLAP). Детальное обследование предприятия (или его частей) и построение моделей существующей структуры организации. Применяются CASE-системы и специальные инструменты моделирования: детальные функциональные модели бизнес-процедур, имитационные модели в терминах массового обслуживания, динамические модели на сетях Петри. 15 ЛЕКЦИЯ 6. МЕТОДОЛОГИИ И ТЕХНОЛО- ГИИ ПРОЕКТИРОВАНИЯ ИС Общие требования к методологии и технологии Методология проектирования ИС реализуется через конкретные технологии и поддерживающие их стандарты и инструментальные средства. Технология проектирования определяется как совокупность трех составляющих: пошаговой процедуры, определяющей последовательность технологических операций проектирования (рис.6.1); критериев и правил, используемых для оценки результатов выполнения технологических операций; нотаций (графических и текстовых средств), используемых для описания проектируемой системы. Рис.6.1. Представление технологической операции проектирования Технология проектирования, разработки и сопровождения ИС должна обеспечивать: поддержку полного ЖЦ; гарантированное достижение целей разработки ИС с заданным качеством и в установленное время; возможность выполнения крупных проектов в виде подсистем (т.е. возможность декомпозиции проекта на составные части, разрабатываемые группами исполнителей ограниченной численности с последующей интеграцией составных частей); возможность ведения работ по проектированию отдельных подсистем небольшими группами (3-7 человек); минимальное время получения работоспособной ИС; управление конфигурацией проекта, ведение версий проекта и его составляющих, возможность автоматического выпуска проектной документации и синхронизацию ее версий с версиями проекта; независимость выполняемых проектных решений от средств реализации ИС (СУБД, операционных систем, языков и систем программирования); Технология должна быть поддержана комплексом инструментальных средств, обеспечивающих автоматизацию процессов, выполняемых на всех стадиях ЖЦ. К стандартам относятся следующие: стандарт проектирования; стандарт оформления проектной документации; стандарт пользовательского интерфейса. Стандарт проектирования должен устанавливать: 16 на каждой стадии проектирования и стенабор необходимых моделей (диаграмм) пень их детализации; правила фиксации проектных решений на диаграммах; требования к конфигурации рабочих мест разработчиков, включая настройки ОС, инструментальных средств, общие настройки проекта; механизм обеспечения совместной работы над проектом. Стандарт оформления проектной документации должен устанавливать: комплектность, состав и структуру документации на каждой стадии проектирования; требования к ее оформлению; правила подготовки, рассмотрения, согласования и утверждения документации с указанием предельных сроков для каждой стадии; требования к настройке издательской системы, используемой в качестве встроенного средства подготовки документации; требования к настройке инструментальных средств для обеспечения подготовки документации в соответствии с установленными требованиями. Стандарт интерфейса пользователя должен устанавливать: правила оформления экранов (шрифты и цветовая палитра), состав и расположение окон и элементов управления; правила использования клавиатуры и мыши; правила оформления текстов помощи; перечень стандартных сообщений; правила обработки реакции пользователя. Модельно-базированный подход к проектированию ИС Этот подход предполагает, что разработка системы начинается с построения модели, описывающей систему с разных точек зрения. Полная модель складывается из отдельных проекций, отражающих разные аспекты системы. Выбор проекций модели зависит от подхода к проблеме и принятых решений. Ключом к построению проекций является абстрагирование, когда сосредоточиваются на наиболее существенных деталях, игнорируя при этом остальные. Например, проекция - функциональная модель показывает, что делает система в ответ на запросы пользователя (но не как она это делает), логическая модель описывает основные сущности и отношения между ними. Модели позволяют свести высокую сложность информационной системы до уровня, понимаемого человеком. Достигается это за счет иерархического принципа их построения и применения наглядной графической нотации. Иерархия уровней описания системы дает возможность резко сократить количество элементов, которые должен анализировать человек. Каждая модель может быть выражена с разными уровнями детализации. При этом на верхних уровнях иерархии опускаются детали реализации, которые проявляются на более низких уровнях. Построенные модели могут модифицироваться в течение всего жизненного цикла. Причин тому может быть много - изменения требований к системе, устранение ошибок, развитие системы, нахождение более удачных решений и т. д. При этом обязательно соблюдение соответствия между моделями и программными кодами. И для структурного, и для объектно-ориентированного подхода разработано немало методов моделирования систем. По определению Г.Буча, метод - это упорядоченный процесс создания множества моделей, описывающих различные аспекты программной системы, на основе строго определенной нотации. Методология RAD Одним из возможных подходов к разработке ПО в рамках спиральной модели ЖЦ является методология быстрой разработки приложений RAD (Rapid Application Development). Она содержит 3 элемента: небольшую команду программистов (от 2 до 10 человек); короткий, но тщательно проработанный производственный график (от 2 до 6 мес.); 17 работчики, по мере того, как приложение повторяющийся цикл, при котором разначинает обретать форму, запрашивают и реализуют в продукте требования, полученные через взаимодействие с заказчиком. Основные принципы методологии RAD: разработка приложений итерациями; необязательность полного завершения работ на каждом из этапов жизненного цикла; обязательное вовлечение пользователей в процесс разработки ИС; необходимое применение CASE-средств, обеспечивающих целостность проекта; применение средств управления конфигурацией, облегчающих внесение изменений в проект и сопровождение готовой системы; необходимое использование генераторов кода; использование прототипирования, позволяющее полнее выяснить и удовлетворить потребности конечного пользователя; тестирование и развитие проекта, осуществляемые одновременно с разработкой; ведение разработки немногочисленной хорошо управляемой командой профессионалов; грамотное руководство разработкой системы, четкое планирование и контроль выполнения работ. Жизненный цикл ПО по методологии RAD состоит из четырех фаз: анализ и планирование требований. Результатом данной фазы должны быть список и приоритетность функций будущей ИС, предварительные функциональные и информационные модели ИС; проектирование. Результатом данной фазы должны быть:  общая информационная модель системы;  функциональные модели системы в целом и подсистем, реализуемых отдельными командами разработчиков;  точно определенные с помощью CASE-средства интерфейсы между автономно разрабатываемыми подсистемами;  построенные прототипы экранов, отчетов, диалогов; построение. Результатом фазы является готовая система, удовлетворяющая всем согласованным требованиям; внедрение. Производится обучение пользователей, организационные изменения, параллельно с внедрением новой системы работает существующая (до полного внедрения новой). В отличие от традиционного подхода, при котором использовались специфические средства прототипирования, не предназначенные для построения реальных приложений, а прототипы выбрасывались после того, как выполняли задачу устранения неясностей в проекте, в подходе RAD каждый прототип развивается в часть будущей системы. Методология RAD хороша для относительно небольших проектов, разрабатываемых для конкретного заказчика, неприменима для построения сложных расчетных программ, операционных систем или программ управления космическими кораблями, т.е. программ, требующих написания большого объема (сотни тысяч строк) уникального кода. Не подходят для разработки по методологии RAD приложения, в которых отсутствует ярко выраженная интерфейсная часть, наглядно определяющая логику работы системы (например, приложения реального времени) и приложения, от которых зависит безопасность людей (например, управление самолетом или атомной электростанцией), так как итеративный подход предполагает, что первые несколько версий наверняка не будут полностью работоспособны, что в данном случае исключается. 18 ЛЕКЦИЯ 7. СТРУКТУРНЫЙ ПОДХОД К ПРОЕКТИРОВАНИЮ ИС Сущность структурного подхода к разработке ИС заключается в ее декомпозиции на автоматизируемые функции. Система разбивается на функциональные подсистемы, подфункции, задачи и так далее вплоть до конкретных процедур. При разработке системы "снизу-вверх" теряется целостность, возникают проблемы при стыковке отдельных компонентов. Основные принципы структурного подхода: "разделяй и властвуй" - принцип решения сложных проблем путем их разбиения на множество меньших независимых задач, легких для понимания и решения; иерархическое упорядочивание - принцип организации составных частей проблемы в иерархические древовидные структуры с добавлением новых деталей на каждом уровне. абстрагирование - выделение существенных аспектов системы и отвлечения от несущественных; формализация - необходимость строгого методического подхода к решению проблемы; непротиворечивость - обоснованность и согласованность элементов; структурирование данных - данные должны быть структурированы и иерархически организованы. Основные виды моделей (диаграмм) структурного подхода: SADT (Structured Analysis and Design Technique) модели и соответствующие функциональные диаграммы, DFD (Data Flow Diagrams) диаграммы потоков данных; ERD (Entity-Relationship Diagrams) диаграммы "сущность-связь". Методология SADT разработана Дугласом Россом и предназначена для построения функциональной модели объекта. На ее основе разработана, в частности, известная методология IDEF0 (Icam DEFinition), которая является основной частью программы ICAM (Интеграция компьютерных и промышленных технологий), проводимой по инициативе ВВС США Рис. 7.1. Функциональный блок и интерфейсные дуги SADT-модель состоит из диаграмм, фрагментов текстов и глоссария, имеющих ссылки друг на друга. Диаграммы - главные компоненты модели, все функции ИС и интерфейсы на них представлены как блоки и дуги. Управляющая информация входит в блок сверху, информация, которая подвергается обработке, показана с левой стороны блока, а результаты выхода показаны с правой стороны. Механизм (человек или автоматизированная система), который осуществляет операцию, представляется дугой, входящей в блок снизу (рис. 7.1). Модель SADT представляет собой иерархию диаграмм с сопроводительной документацией, разбивающих сложный объект на составные части, которые представлены в виде блоков. Детали каждого из основных блоков показаны в виде блоков на других диаграммах. Каждая детальная диаграмма является декомпозицией блока из более общей диаграммы. На каждом шаге декомпозиции более общая диаграмма называется родительской для более детальной диаграммы. 19 Для того, чтобы указать положение любой диаграммы или блока в иерархии, используются номера диаграмм. Например, А21 является диаграммой, которая детализирует блок 1 на диаграмме А2. Аналогично, А2 детализирует блок 2 на диаграмме А0, которая является самой верхней диаграммой модели. На рис. 7.2 показано типичное дерево диаграмм. Рис. 7.2. Дерево диаграмм При моделировании потоков данных (процессов) (методология Гейна-Сарсона) модель системы определяется как иерархия диаграмм потоков данных (ДПД или DFD), описывающих асинхронный процесс преобразования информации от ее ввода в систему до выдачи пользователю. Диаграммы верхних уровней иерархии (контекстные диаграммы) определяют основные процессы или подсистемы ИС с внешними входами и выходами. Они детализируются при помощи диаграмм нижнего уровня. Такая декомпозиция продолжается, создавая многоуровневую иерархию диаграмм, до тех пор, пока не будет достигнут такой уровень декомпозиции, на котором процессы становятся элементарными и детализировать их далее невозможно. Источники информации (внешние сущности) порождают информационные потоки (потоки данных), переносящие информацию к подсистемам или процессам. Те в свою очередь преобразуют информацию и порождают новые потоки, которые переносят информацию к другим процессам или подсистемам, накопителям данных или внешним сущностям - потребителям информации. Таким образом, основными компонентами диаграмм потоков данных являются: внешние сущности; системы/подсистемы; процессы; накопители данных; потоки данных. 20 ЛЕКЦИЯ 8. МОДЕЛИРОВАНИЕ ДАННЫХ. МЕТОДОЛОГИЯ IDEF1 Прежде чем данные помещаются в конкретную СУБД, необходимо получить концептуальную схему базы данных в форме модели. Для этого используют диаграммы "сущность-связь" (ERD), нотация которых введена П.Ченом. Сущность (Entity) – реальный или воображаемый объект, имеющий существенное значение для рассматриваемой предметной области. Сущность имеет уникальное имя, обладает атрибутами и связями с другими сущностями модели. Каждый экземпляр сущности должен отличаться от других экземпляров данного типа сущности. Связь (Relationship) – поименованная ассоциация между сущностями. Атрибут – любая характеристика сущности или выражение состояния сущности. Метод IDEF1, разработанный Т.Рэмей (T.Ramey), основан на подходе П.Чена. Версия IDEF1X разработана с учетом простоты изучения и возможности автоматизации. IDEF1Xдиаграммы используются рядом распространенных CASE-средств (в частности, ERwin, Design/IDEF). Сущность в методологии IDEF1X является независимой, если каждый экземпляр сущности может быть однозначно идентифицирован без определения его отношений с другими сущностями. Сущность называется зависимой, если однозначная идентификация экземпляра сущности зависит от его отношения к другой сущности (рис. 8.1). Рис. 8.1. Сущности Каждой сущности присваивается уникальное имя и номер, разделяемые косой чертой "/" и помещаемые над блоком. Связь может дополнительно определяться с помощью указания степени или мощности (количества экземпляров сущности-потомка, которое может существовать для каждого экземпляра сущности-родителя). В IDEF1X могут быть выражены следующие мощности связей: каждый экземпляр сущности-родителя может иметь ноль, один или более связанных с ним экземпляров сущности-потомка; каждый экземпляр сущности-родителя должен иметь не менее одного связанного с ним экземпляра сущности-потомка; каждый экземпляр сущности-родителя должен иметь не более одного связанного с ним экземпляра сущности-потомка; каждый экземпляр сущности-родителя связан с некоторым фиксированным числом экземпляров сущности-потомка. Если экземпляр сущности-потомка однозначно определяется своей связью с сущностьюродителем, то связь называется идентифицирующей, в противном случае - неидентифицирующей. Связь изображается линией, проводимой между сущностью-родителем и сущностью-потомком с точкой на конце линии у сущности-потомка. 21 Рис. 8.2. Идентифицирующая связь Идентифицирующая связь между сущностью-родителем и сущностью-потомком изображается сплошной линией (рис. 8.2). Сущность-потомок в идентифицирующей связи является зависимой от идентификатора сущностью. Сущность-родитель в идентифицирующей связи может быть как независимой, так и зависимой (это определяется ее связями с другими сущностями). Пунктирная линия изображает неидентифицирующую связь. Здесь сущность-потомок будет независимой от идентификатора, если она не является также сущностью-потомком в какой-либо идентифицирующей связи. Рис. 8.3. Атрибуты и первичные ключи Атрибуты изображаются в виде списка имен внутри блока сущности. Атрибуты, определяющие первичный ключ, размещаются наверху списка и отделяются от других атрибутов горизонтальной чертой (рис. 8.3). Рис. 8.4. Примеры внешних ключей Сущности могут иметь также внешние ключи (Foreign Key), которые могут использоваться в качестве части или целого первичного ключа или неключевого атрибута. Внешний ключ изображается с помощью помещения внутрь блока сущности имен атрибутов, после которых следуют буквы FK в скобках (рис. 8.4). 22 ЛЕКЦИЯ 9. ОБЪЕКТНООРИЕНТИРОВАННЫЙ ПОДХОД К ПРОЕКТИРОВАНИЮ ИНФОРМАЦИОННЫХ СИСТЕМ Структурный подход к созданию ИС имеет недостатки. Код клиентского приложения генерируется на основе информации о структуре БД. Данные хранятся в таблицах БД не всегда в той же форме, в которой они должны представляться на экранных формах. Другими словами, если код приложения генерируется не на основе описания предметной области, невозможно построить эффективное приложение со сложной бизнеслогикой. Кроме того, при структурном подходе к разработке ИС риск остается большим на всех этапах создания системы вплоть до этапа тестирования, когда мы можем обнаружить допущенные ошибки и оценить состоятельность системы. В случае обнаружения ошибки необходимо вернуться на тот этап разработки, на котором допущена ошибка, и заново пройти последующие этапы. В объектно-ориентированном (ОО) подходе используется итеративно-поступательный цикл создания ПО, перенос акцента проектирования с разработки алгоритмов функционирования системы на построения системы абстракций и их взаимодействия. Разработка состоит из ряда итераций, которые в дальнейшем приводят к созданию ИС. Каждая итерация может приводить к созданию фрагмента или новой версии и включает этапы выработки требований, анализа, проектирования, реализации и тестирования. Поскольку тестирование проводится на каждой итерации, риск снижается уже на начальных этапах жизненного цикла разработки. Проектирование рассматривается как последовательное отражение уровней абстракции создаваемой системы управления на программную модель. Каждый уровень представляет собой совокупность объектов. Эти объекты образуют иерархии при повышении уровня общности. В развитии ИС 90-е годы стали временем становления объектных технологий. Начал развиваться рынок объектных СУБД. Благодаря появлению в 1996-97 годах объектно-реляционных серверов баз данных компаний Oracle, Informix и IBM, происходит процесс миграции из реляционных сред в объектные. Указанные процессы стимулировали развитие объектных технологий анализа и проектирования систем. Появилось значительное количество различных методов и реализующих их коммерческих программных продуктов. Методы автоматизации производства ПО основаны на компонентных технологиях, визуальном программировании, использовании образцов (pattern) и инструментальных сред (framework). С апреля 1989 года функционирует группа OMG (Object Management Group), в состав которой входило к 1999 г. более 400 организаций. Цель OMG состояла в создании распределенной объектной системы, которая позволила бы совместно использовать объекты, реализованные на разных объектно-ориентированных языках программирования (С++, SmallTalk, CLOS, Eiffel, Object Pascal, J++ ), которая работала бы на любой неоднородной сети компьютеров под управлением различных операционных систем. Результатом ее деятельности явилось создание обзора по архитектуре управления объектами ОМА (Object Management Architecture). ОМА представляет собой полный набор рекомендаций по разработке распределенных объектных систем, среди которых основной является архитектура СОRВА (Common Object Request Broker Architecture, стандартная архитектура брокера объектных запросов). Это объектный стандарт, который определяет интерфейсы между сетевыми объектами, позволяющие им работать совместно. Брокеры объектных запросов (object request brokers, ORB), созданные в соответствии с CORBA, представляют собой новую форму промежуточного обеспечения для разработки систем "клиент-сервер". СОRВА решает базовые вопросы взаимодействия объектов, операционных систем, сетевых протоколов и т.п. Интерфейс объекта полностью отделен от его реализации, причем объектная модель имеет дело только с интерфейсами объектов. Такое решение позволило полностью абстрагироваться от конкретного языка реализации объектов. Интерфейсы объектов определяются на языке описания интерфейсов IDL (Interface Definition Language). Технология ОLЕ (Object Linking and Embedding - связывание и внедрение объектов) является реализацией модели клиент-сервер. Появление ОLЕ явилось следствием развития объектноориентированного программирования и связано с тем, что возникла необходимость во взаимодей- 23 ствии приложений на уровне объектов. ОLЕ яв- ляется основанием, на котором строятся объекты. Сейчас ОLЕ представляет собой целый набор технологий, среди которых подразумевают: унифицированную передачу данных; структурированное хранилище информации; автоматизацию (набор интерфейсов, позволяющий использовать приложение в качестве ОLЕ-объекта); динамические запросы о структуре объектов, позволяющие определять наличие методов и атрибутов объекта на стадии выполнения. UML - унифицированный языка моделирования Авторы наиболее распространенных ОО методов - Г.Буч, Д.Рамбо и И.Якобсон, - разработали унифицированный язык моделирования (Unified Modeling Language - UML). UML именно язык, а не метод, не процесс моделирования. В нем определен состав моделей и нотация, но не процесс построения моделей. В 1997 г. UML был утвержден OMG в качестве стандарта. Модель в UML представляет собой набор диаграмм, позволяющий представить различные взгляды на проектируемую систему. Он включает:  диаграммы классов (class diagram);  диаграммы вариантов использования (use case diagram);  поведенческие диаграммы (behavior diagrams), - деятельностей (activity diagram), последовательностей (sequence diagram) и сотрудничества (collaboration diagram);  диаграммы реализации (implementation diagrams), включающие диаграммы компонентов (component diagram) и распределения (deployment diagram). Для просмотра модели в Rational Rose используется иерархический навигатор модели— Browser. С помощью этих диаграмм можно показать статическую структуру, определяющую логические связи в системе, динамику работы отдельных компонент (классов), взаимодействие объектов в процессе функционирования системы, физическую структуру и т. д. Существует несколько CASE-средств, поддерживающих язык UML. Наиболее известными являются Paradigm Plus фирмы PLATINUM technology и Rational Rose фирмы Rational Software. Эти инструменты позволяют генерировать код приложения, в полной мере отвечающий бизнесправилам, и с наименьшим риском. Язык UML использует графическую нотацию и предназначен для спецификации, визуализации, конструирования и документирования систем программного обеспечения, разрабатываемых на основе объектно-ориентированных технологий и компонентного подхода. Язык не зависит от конкретных языков программирования, используемых при реализации разрабатываемых систем. Он не ориентируется также на какой-либо конкретный технологический процесс разработки. UML не является запатентованным средством и открыт для всех. Многие компании используют UML как стандарт в процессах разработки, связанных с такими областями, как моделирование бизнеса, управление требованиями, анализ и проектирование, программирование и тестирование. Как ожидается, UML в его текущем виде станет основой для многих инструментальных средств, в том числе, для сред визуального моделирования, имитационного моделирования, а также сред разработки. 24 ЛЕКЦИЯ 10. CASE-ТЕХНОЛОГИЯ CASE-технология (Computer-Aided Software/System Engineering) представляет собой совокупность методологий анализа, проектирования, разработки и сопровождения сложных систем и поддерживается комплексом взаимоувязанных средств автоматизации. Это инструментарий для системных аналитиков, разработчиков и программистов, заменяющий бумагу и карандаш компьютером, автоматизируя процесс проектирования и разработки ПО. Особенности CASE-технологии. Единый графический язык. CASE-технологии обеспечивают всех участников проекта, включая заказчиков, единым наглядным и интуитивно понятным графическим языком. Это двумерные схемы, которые проще в использовании, чем многостраничные описания. Обеспечивается также легкость сопровождения и внесения изменений в систему. Единая БД проекта. Основа CASE-технологии -- использование базы данных проекта (репозитория) для хранения всей информации о проекте, которая разделяется между разработчиками в соответствии с их правами доступа. Репозиторий может хранить свыше 100 типов объектов: структурные диаграммы, определения экранов и меню, проекты отчетов, описания данных, логика обработки, модели данных, исходные коды, элементы данных и т. п. Интеграция средств. На основе репозитория осуществляется интеграция CASE-средств и разделение системной информации между разработчиками. При этом возможности репозитория обеспечивают несколько уровней интеграции: общий пользовательский интерфейс по всем средствам, передачу данных между средствами, интеграцию этапов разработки через единую систему представления фаз жизненного цикла, передачу данных и средств между различными платформами. Поддержка коллективной разработки и управления проектом. CASE-технология поддерживает групповую работу над проектом, возможность работы в сети, экспорт-импорт любых фрагментов проекта для их модификации, а также контроль и взаимодействие, т. е. функции, необходимые в процессе разработки и сопровождения проектов. Эти функции также реализуются на основе репозитория. В частности, через репозиторий может осуществляться контроль безопасности (ограничения и привилегии доступа), контроль версий и др. Прототипирование. CASE-технология дает возможность быстро строить прототипы будущей системы, что позволяет заказчику оценить ее на ранних этапах разработки. Генерация документации. Вся документация по проекту генерируется автоматически на базе репозитория. Документация всегда отвечает текущему состоянию дел, поскольку любые изменения в проекте автоматически отражаются в репозитории. Верификация проекта. CASE-технология обеспечивает автоматическую верификацию и контроль проекта на полноту и состоятельность. Автоматическая генерация объектного кода. Генерация программ в машинном коде осуществляется на основе репозитория и позволяет автоматически построить до 85-90% объектного кода или текстов на языках высокого уровня. Сопровождение и реинжиниринг. Сопровождение системы в рамках CASE-технологии характеризуется сопровождением проекта, а не программных кодов. Средства реинжиниринга и обратного инжиниринга позволяют создавать модель системы из ее кодов и интегрировать полученные модели в проект, автоматически обновлять документацию при изменении кодов. Табл. 10.1 Традиционная технология разработРазработка с помощью CASE-технологий ки Основные усилия - на кодирование и Основные усилия - на анализ и проектирование тестирование "Бумажные" спецификации Быстрое итеративное макетирование Ручное кодирование Автоматическая генерация машинного кода Тестирование ПО Автоматический контроль проекта Сопровождение программного кода Сопровождение проекта 25 При использовании CASE-технологий из- меняются все фазы жизненного цикла ИС, причем наибольшие изменения касаются фаз анализа и проектирования. В табл.10.1 приведены основные изменения жизненного цикла ИС при использовании CASE-технологий по сравнению с традиционной технологией разработки. В табл.10.2 приведены оценки трудозатрат по фазам жизненного цикла ПО. Первая строка таблицы соответствует традиционной технологии разработки, вторая - разработке с использованием структурных методологий вручную, третья - разработке с использованием CASE-технологий. Табл. 10.2 Анализ Проектирование Программирование Тестирование 20% 15% 20% 45% 30% 30% 15% 25% 40% 40% 5% 15% CASE-технологии, в частности, позволяют вести разработку сложных ИС на основе концепции открытых систем. Основная цель создания систем как открытых состоит в возможности эффективного объединения в единую систему разных видов оборудования и ПО на основе применения стандартизованных интерфейсов между компонентами системы. Такой подход позволяет повторно использовать программные средства на разных вычислительных платформах без перепрограммирования и тем самым экономить значительные финансовые средства. С другой стороны, такой подход позволяет поэтапно наращивать вычислительную мощность прикладной системы в соответствии как с потребностями пользователя, так и с его финансовыми возможностями. Ни одно из CASE-средств не решает в целом все проблемы создания и сопровождения ПО. Это могут комплексы методологически и технологически согласованных инструментальных средств, поддерживающие полный ЖЦ ПО Один из наиболее развитых комплексов такого рода является комплекс технологий и инструментальных средств создания ИС, поддерживаемый фирмой "Аргуссофт Компани". В его основе лежит методология и технология DATARUN фирмы CSA. В состав комплекса входят следующие инструментальные средства: CASE-средство Silverrun; средство разработки приложений JAM; мост Silverrun-RDM <-> JAM; комплекс средств тестирования QA; менеджер транзакций Tuxedo; комплекс средств планирования и управления проектом SE Companion; комплекс средств конфигурационного управления PVCS; объектно-ориентированное CASE-средство Rational Rose; средство документирования SoDA. СУБД 26 BPwin IDEF0, DEF3 DFD Paradigm Plus UML Rational ROSE 1 MODEL MART 5 7 ERwin IDEF1X Powerbuilder Visual Basic Delphi ERwin Translation Wizart 6 3 2 Powerbuilder C++ Java 4 Рис.10.1. Схема взаимодействия комплекса инструментальных средств для проектирования ИС Другой комплекс предлагается на базе средств фирмы PLATINUM technology (см. рис.10.1). Для проведения анализа и реорганизации бизнес-процессов предлагается CASE-средство BPwin. На основе функциональной модели, полученной в BPwin, с помощью ERwin строится модель данных. Для этого имеется механизм двунаправленной связи BPwin — ERwin (стрелка 1 рис.10.1). ERwin имеет два уровня представления модели — логический и физический. На логическом уровне данные не связаны с конкретной СУБД. ERwin позволяет проводить процессы прямого и обратного проектирования БД (стрелка 2 рис.10.1). Это означает, что по модели данных можно сгенерировать схему БД или автоматически создать модель данных на основе информации системного каталога. ERwin интегрируется с популярными средствами разработки клиентской части— Powerbuilder, Visual Basic, Delphi (стрелка 2), что позволяет автоматически генерировать код приложения, который полностью готов к компиляции и выполнению (стрелка 4). Использующиеся на разных этапах и разными специалистами средства моделирования и разработки должны быть объединены общей системой организации совместной работы. Фирма PLATINUM technology предлагает систему Model Mart—хранилище моделей, к которому открыт доступ для участников проекта создания ИС (стрелка 5). Для генерации клиентской части приложения в комплексе предлагаются CASE-средства, поддерживающих языки объектно-ориентированного проектирования Paradigm Plus фирмы PLATINUM technology и Rational Rose (Rational Software). Они поддерживают не только прямую генерацию кода, но и обратное проектирование, т.е. создание объектной модели по исходному коду приложения (стрелка 6). Модуль ERwin Translation Wizard (PLATINUM technology) позволяет перегружать объектную модель Rational Rose в модель данных ERwin (и обратно) и, с помощью ERwin, сгенерировать схему БД (стрелка 7) на любой из поддерживаемых в ERwin СУБД. Для связывания объектной модели, созданной в PLATINUM Paradigm Plus, с моделью данных не требуется дополнительных утилит. Версия Paradigm Plus 3.6 полностью интегрирована с ERwin. 27 ЛЕКЦИЯ 11. ХАРАКТЕРИСТИКА СОВРЕ- МЕННЫХ CASE-СРЕДСТВ Современный рынок насчитывает около 300 различных CASE-средств. Компоненты полного комплекса CASE-средств:  репозиторий, являющийся основой CASE-средства. Он должен обеспечивать хранение версий проекта и его отдельных компонентов, синхронизацию поступления информации от различных разработчиков при групповой разработке, контроль метаданных на полноту и непротиворечивость;  графические средства анализа и проектирования, обеспечивающие создание и редактирование иерархически связанных диаграмм (потоков данных, "сущность-связь" и др.), образующих модели ИС;  средства разработки приложений, включая языки 4GL и генераторы кодов;  средства конфигурационного управления;  средства документирования;  средства тестирования;  средства управления проектом;  средства реинжиниринга. Классификация CASE-средств по типам в основном совпадает с компонентным составом CASE-средств и включает следующие основные типы: средства анализа (Upper CASE), предназначенные для построения и анализа моделей предметной области (Design/IDEF, BPwin); средства анализа и проектирования (Middle CASE), использующиеся для создания спецификаций компонентов и интерфейсов системы, архитектуры системы, алгоритмов и структур данных (Vantage Team Builder, Designer/2000, Silverrun, PRO-IV, CASE.Аналитик); средства проектирования БД, обеспечивающие моделирование данных и генерацию схем баз данных (ERwin, S-Designor и DataBase Designer (ORACLE). Средства проектирования баз данных имеются также в составе CASE-средств Vantage Team Builder, Designer/2000, Silverrun и PRO-IV; средства разработки приложений (средства 4GL (Uniface, JAM, PowerBuilder, Developer/2000, SQLWindows, Delphi и др.) и генераторы кодов, входящие в состав Vantage Team Builder, PRO-IV и частично - в Silverrun; средства реинжиниринга, обеспечивающие анализ программных кодов и схем баз данных и формирование на их основе различных моделей и проектных спецификаций. Средства анализа схем БД и формирования ERD входят в состав Vantage Team Builder, PRO-IV, Silverrun, Designer/2000, ERwin и S-Designor. В области анализа программных кодов наибольшее распространение получают объектно-ориентированные CASE-средства, обеспечивающие реинжиниринг программ на языке С++ (Rational Rose, Object Team). Помимо этого, CASE-средства классифицируют по следующим признакам: применяемым методологиям и моделям систем и баз данных; степени интегрированности с системами управления базами данных; доступным платформам. К настоящему времени наиболее интенсивное развитие получили два главных направления применения CASE-средств: 4. Реорганизация бизнес-процессов предприятия. 5. Системный анализ и проектирование, включающий функциональное, информационное и событийное моделирование как вновь создаваемой, так и уже имеющейся системы. Российский рынок программного обеспечения в 1999 г. располагал рядом CASE-средств, среди которых: Vantage Team Builder (Westmount I-CASE); Designer/2000; Silverrun; ERwin+BPwin; CASE.Аналитик; Rational Rose. 28 Silverrun американской фирмы Сomputer Systems Advisers, Inc. (CSA) используется для анализа и проектирования ИС бизнес-класса и ориентировано в большей степени на спиральную модель ЖЦ. Оно применимо для поддержки любой методологии, основанной на раздельном построении функциональной и информационной моделей (диаграмм потоков данных и ERдиаграмм). Система Silverrun реализована на трех платформах - MS Windows, Macintosh и OS/2 Presentation Manager - с возможностью обмена данными между ними. Vantage Team Builder представляет собой интегрированный программный продукт, ориентированный на реализацию каскадной модели ЖЦ ПО и поддержку полного ЖЦ ПО. Vantage Team Builder поставляется в различных конфигурациях в зависимости от используемых СУБД (ORACLE, Informix, Sybase или Ingres) или средств разработки приложений (Uniface). Конфигурация Vantage Team Builder for Uniface отличается от остальных некоторой степенью ориентации на спиральную модель ЖЦ ПО за счет возможностей быстрого прототипирования, предоставляемых Uniface. Vantage Team Builder функционирует на всех основных UNIX-платформах (Solaris, SCO UNIX, AIX, HP-UX) и VMS. Designer/2000 2.0 фирмы ORACLE является интегрированным CASE-средством, обеспечивающим в совокупности со средствами разработки приложений Developer/2000 поддержку полного ЖЦ ПО для систем, использующих СУБД ORACLE. Designer/2000 представляет собой семейство методологий и поддерживающих их программных продуктов. Базовая методология Designer/2000 (CASE*Method) - структурная методология проектирования систем, охватывающая полностью все этапы ЖЦ ИС. Генерация приложений, помимо продуктов ORACLE, выполняется также для Visual Basic. Designer/2000 можно интегрировать с другими средствами, используя открытый интерфейс приложений API (Application Programming Interface). Кроме того, можно использовать средство ORACLE CASE Exchange для экспорта/импорта объектов репозитория с целью обмена информацией с другими CASE-средствами. Среда функционирования Designer/2000 - Windows 3.x, Windows 95, Windows NT. ERwin - средство концептуального моделирования БД, использующее методологию IDEF1X. ERwin реализует проектирование схемы БД, генерацию ее описания на языке целевой СУБД (ORACLE, Informix, Ingres, Sybase, DB/2, Microsoft SQL Server, Progress и др.) и реинжиниринг существующей БД. ERwin выпускается в нескольких различных конфигурациях, ориентированных на наиболее распространенные средства разработки приложений 4GL. Для ряда средств разработки приложений (PowerBuilder, SQLWindows, Delphi, Visual Basic) выполняется генерация форм и прототипов приложений. Сетевая версия Erwin ModelMart обеспечивает согласованное проектирование БД и приложений в рабочей группе. BPwin - средство функционального моделирования, реализующее методологии IDEF0, IDEF3 и DFD. Вместе с ERwin составляет часть комплекса средств фирмы PLATINUM technology для проектирования ИС. CASE.Аналитик ("Эйтэкс") является единственным конкурентоспособным отечественным CASE-средством функционального моделирования. В его основе лежит классическая методология структурного системного анализа Гейна – Сарсона. Версия 1.1+ поддерживает следующие типы диаграмм: функциональной иерархии (дерево диаграмм проекта), контекстные, потоков данных, потоков управления, структурограммы данных, мини-спецификации (средства описания логики) процессов. Среда функционирования: процессор - 386 и выше, основная память - 4 Мб, дисковая память - 5 Мб, MS Windows 3.x или Windows 95. С помощью отдельного программного продукта (Catherine) выполняется обмен данными с CASE-средством Erwin. Rational Rose фирмы Rational Software Corp. (США) предназначено для автоматизации этапов анализа и проектирования ПО, а также для генерации кодов на различных языках и выпуска проектной документации. Rational Rose использует методологию объектно-ориентированного анализа и проектирования на базе языка UML. Основной вариант - Rational Rose/C++ позволяет разрабатывать проектную документацию в виде диаграмм и спецификаций, а также генерировать программные коды на С++. Rational Rose функционирует на различных платформах: IBM PC (в среде Windows), Sun SPARC stations (UNIX, Solaris, SunOS), Hewlett-Packard (HP UX), IBM RS/6000 (AIX). 29 ЛЕКЦИЯ 12. КОРПОРАТИВНЫЕ ИНФОРМА- ЦИОННЫЕ СИСТЕМЫ Под корпоративной информационной системой (КИС или EIS — Enterprise Information System) понимают информационную систему масштаба предприятия. Термин ―корпоративная‖ предполагает полнофункциональность. Если какое-либо ПО автоматизирует только деятельность бухгалтерии или склада, то это еще не КИС. Это одноаспектная (―лоскутная‖, ―островная‖) автоматизированная система учета и анализа (финансового, материального и проч.). Корпоративные системы охватывают всю финансово-хозяйственную и производственную деятельность предприятия, в т.ч. имеющего филиалы и дочерние фирмы, входящие в холдинговые компании и концерны. Отличительные черты корпоративных систем.  Автоматизируется документооборот предприятия Документы автоматически передаются от одного исполнителя к другому или на подпись руководителю, при этом сводится к нулю возможность неправильной адресации, забывания или потери документов. Система контролирует сроки исполнения работ и выдает напоминания ответственным исполнителям.  Моделируются бизнес-процессы Продумывая внедрение нового бизнес-процесса, руководитель описывает его в своей КИС, определяя при этом, какие документы участвуют в процессе и кто из специалистов отвечает за действия с этими документами. Далее система не позволит персоналу делать ошибки или нарушать технологию работы.  Убираются внутрифирменные барьеры Для обеспечения одновременной согласованной работы пользователей в КИС применяется технология клиент/сервер.  Открывается доступ в международные информационные сети Изображенная на рис.12.1 пирамида является одной из интерпретаций КИС со всеми сопутствующими связями. Главная роль КИС — поддержать функционирование и развитие предприятия, цель существования которого — получение прибыли за счет некоторой основной деятельности. Базирующиеся на MRP-II системы могут быстро просчитать возможность выполнения нового заказа к нужному сроку при текущей загрузке производства. Когда оказывается, что в сложившейся ситуации выполнить данный заказ в срок невозможно, система способна ответить на вопрос, во что обойдется заказчику выполнение заказа, если он все же на сроке настаивает. Средняя часть пирамиды, характеризующей управленческий срез предприятия, как раз и представляет собой КИС. В то же время на рынке присутствуют интегрированные системы управления предприятием, ИСУП. В редких случаях они покрывают все управленческие задачи (таковы возможности R/3, Baan, J.D.Edwards) и могут называться КИС. ИСУП охватывают слой, осуществляющий оперативный учет (OLTP — On-Line Transaction Processing), и слой, в котором хранятся структурированные корпоративные данные. Вместе они образуют управленческую ИС нижнего уровня (Management Information System — MIS). 30 Рис.12.1. Схема элементов управления предприятием Стратегический слой начинается с систем поддержки принятия решений (Decision Support System — DSS), которые могут включать в себя ситуационные центры, средства многомерного анализа данных и прочие инструменты аналитической обработки (On-Line Analytic Processing — OLAP). Используемые на этом уровне специальные математические методы позволяют прогнозировать динамику показателей, анализировать затраты по видам деятельности. Такие средства, как правило, не входят в состав ИСУП, а являются разработками третьих фирм. Главные отличия ИСУП от КИС: 1. ИСУП — фундамент КИС, поэтому КИС невозможна без ИСУП. 2. ИСУП отвечает за оперативный учет, КИС — за полный спектр управленческих действий. 3. ИСУП имеет отраслевую направленность, КИС носит более абстрактный характер. 31 ЛЕКЦИЯ 13. ЭТАПЫ И СРЕДСТВА ПО- СТРОЕНИЯ КИС Главными особенностями современного подхода к построению КИС предприятия являются: всесторонний анализ бизнес-процессов, на основе которого производится разработка проекта ИС и обоснование заложенных в нем решений; использование современных методологий и инструментальных средств моделирования и проектирования систем; детальная проработка и согласование с заказчиком всех этапов разработки проекта, контрольных точек, требуемых ресурсов. Этапы построения КИС: обследование предприятия и моделирование его деловых процессов; разработка плана реинжиниринга предприятия; выполнение сетевых проектов любой сложности; подбор, поставка, установка, техническая поддержка и сопровождение программнотехнических средств - компьютерного, сетевого и телекоммуникационного оборудования, системного и прикладного ПО; проектирование баз данных; разработка прикладных программ в технологии клиент/сервер; интеграция с существующими на предприятии ИС; обучение всех категорий пользователей; внедрение и техническая поддержка систем. Теоретическую основу работ составляет множество понятий, концепций и методологий, используемых для описания, анализа и оценки различных аспектов работы предприятия. Основными компонентами этого множества являются: Activity Based Costing - функционально-стоимостной анализ - метод определения стоABC имости и других характеристик изделий и услуг на основе функций и ресурсов, задействованных в бизнес-процессах Activity Based Budgeting - операционное планирование бюджета – планирование бюдABB жета компании или инвестиционного проекта с использованием ABC. Activity Based Management - операционное управление - методология, описывающая средства и способы управления организацией для совершенствования бизнесABM процессов и повышения прибыльности на основе информации, предоставляемой в результате ABC-анализа Activity Resource Planning - функциональное планирование ресурсов - метод планироARP вания ресурсов компании на основе анализа функций, задействованных в бизнеспроцессах и данных ABC-анализа Business Process Reengenering- реорганизация бизнес-процессов - направление деяBPR тельности, включающее перепланирование бизнес-процессов с целью повышения их эффективности в отношении затрат, качества и скорости выполнения Total Quality Management - глобальное управление качеством - направление деятельTQM ности, изучающее бизнес-процессы с целью такой их организации, которая гарантирует идеальное качество продукции Continuous Process Improvement – непрерывное совершенствование процессов - один CPI из подходов к совершенствованию качества бизнес-процессов в рамках TQM Structured Analysis and Design Technique технология структурного анализа и проектиSADT рования Entity-Relationship Diagrams - диаграммы "сущность-связь" - способ определения данERD ных и отношений между ними, обеспечивающий детализацию хранилищ данных Методология функционального моделирования, являющаяся составной частью SADT IDEF0 и позволяющая описать бизнес-процесс в виде иерархической системы взаимосвязанных функций 32 Методология информационного моделирования, являющаяся составной частью SADT IDEF1X и основанная на концепции "сущность-связь" (entity-relationship) Data Flow Diagrams - диаграммы потоков данных - методология структурного анализа, DFD описывающая внешние по отношению к системе источники и адресаты данных, логические функции, потоки и хранилища данных, к которым осуществляется доступ State Transition Diagrams - диаграммы переходов состояний - методология моделироSTD вания последующего функционирования системы на основе ее предыдущего и текущего функционирования Color Petri Nets - раскрашенные сети Петри - методология создания динамической модели бизнес-процесса, позволяющая проанализировать зависящие от времени характеCPN ристики выполнения процесса и распределение ресурсов, для входящих потоков различной структуры Рис. 13.1. Области использования различных методологий в работах по моделированию, анализу бизнес-процессов и построению КИС 33 ЛЕКЦИЯ 14. ERP-СИСТЕМЫ: ОСНОВНЫЕ ЗАДАЧИ И ОБЛАСТЬ ПРИМЕНЕНИЯ ERP-системы - набор интегрированных приложений, которые комплексно, в едином информационном пространстве поддерживают все основные аспекты управленческой деятельности предприятий: планирование ресурсов (финансовых, человеческих, материальных) для производства товаров (услуг), оперативное управление выполнением планов (включая снабжение, сбыт, ведение договоров), все виды учета, анализ результатов хозяйственной деятельности. Требования к ERP-системам: централизация данных в единой базе, близкий к реальному времени режим работы, сохранение общей модели управления для предприятий любых отраслей, поддержка территориально-распределенных структур, работа на широком круге аппаратно-программных платформ и СУБД. Рис.14.1.Системная архитектура ERP-программы На предприятии имеются три уровня планирования и управления. Долгосрочное. Среднесрочное. Краткосрочное (или оперативное). ERP-системы занимаются преимущественно двумя последними. ERP-системы интересует управление, ориентированное на договора или заказы, проходящие по цепочке "Снабжение-Производство-Сбыт". Договор, заказ - это единицы планирования и учета. Они рождают некие пучки вторичных процессов. Задачи ERP-системы в разрезе изделия охватывают полный "цикл жизни" изделия и выглядят, например, так: Поддержка разработки изделия (интерфейс с системой конструирования). Обеспечение изготовления и испытаний пилотных экземпляров. Обеспечение изготовления опытных и установочных партий. Обеспечение серийного и заказного производства. Поддержка изготовления модификаций и клонов. Организация выпуска семейства изделий. Снятие с производства изделий или замена вновь разработанными (сконструированными). 34 Инфраструктура для ERP-систем сервер(ы), клиентские станции, коммуникационные средства и системы, клиентское ПО: ПО для доступа к серверу ПО для представления информации, серверное ПО: ОС, СУБД, система администрирования, монитор транзакций, прикладное ПО коллективного пользования: ERP-система, другие прикладные пакеты (CAD\CAM\CAE,GIS и пр.). Предпочтение в категории "ОС для сервера приложений" пока отдают UNIX. Novell практически ушел из этой ниши, а NT - пока cлаб. О средствах сопровождения ERP-продукт изначально разрабатывался с учетом того, что его будут менять, "доводить до ума" и эксплуатировать 15-20 лет, что-то дописывая (возможно, своими силами). Поэтому для ERP-программы предусмотрены разные фазы "жизни". Для обеспечения этих переходов в приличной ERP-системе предусмотрены определенные инструменты, позволяющие разрабатывать, тестировать и делать безударную замену устаревших компонент. Примеры таких систем: R/3 (SAP), Baan IV (Baan), Oracle Applications (Oracle) и другие. В течение нескольких лет "большая четверка" разработчиков ERP-систем – SAP, Баан, Oracle, PeopleSoft - была представлена на отечественном рынке лишь германской фирмой SAP. К 1999 г. 70 законченных внедрений на предприятиях СНГ, оборот в 40 млн нем. марок (1997 г.). В 1999 г. среди клиентов R/3 (SAP) были ОАО "Газпром", НК "Лукойл", Сургутнефтегаз и др. В 1998 г в России начались около 10 проектов компании Баан. Это транснациональная компания со штаб-квартирами в Голландии и США. Стоимость одного клиентского ПО - 3 тыс. дол., комплект типовых модулей на 10 пользователей стоит 30 тыс. дол., на 50 человек - 150 тыс. дол. Соотношение цены ПО от Baan и расходов на его внедрение варьирует от 1:1 до 1:3. ERP-системы используются и на небольших, и на средних, и на крупных западных предприятиях. У Баан есть клиенты с 10 лицензиями, а самым большим заказчиком Баан является компания "Боинг" (50 тыс. одновременно работающих пользователей в единой системе). SAP, Баан сотрудничают с такими российскими компаниями, как TopS, "Ланит", "АйТи", IBS, "Юникон". Причины приобретения ERP-систем российскими предприятиями: требования зарубежных инвесторов, наличие брешей в материально-техническом снабжении, желание наладить контроль за промышленными предприятиями, входящими в холдинг, для небольших компаний ERP-система - это опора, облегчающая поиск путей дальнейшего развития бизнеса. 35 ЛЕКЦИЯ 15. ПРИМЕНЕНИЕ ИГРОВОГО МОДЕЛИРОВАНИЯ В УПРАВЛЕНИИ При проектировании и внедрении сложных систем необходимо использовать имитационную среду. Такая среда позволяет отработать стратегии функционирования системы. Для этих целей часто применяется игровой подход. Особенно успешно применяются деловые игры для отработки управленческих решений. Игры являются разновидностью активных методов обучения (АМО). Классификация АМО:  деловые игры,  метод анализа конкретных ситуаций,  метод разыгрывания ролей. Игры:  ролевые;  имитационные;  организационно-деятельностные (ОДИ);  деловые (ДИ). В имитационных играх часто имеется только одна тиражируемая роль, не моделируется деятельность руководства, остается лишь модель среды. ОДИ применяют для решения сложных социально-производственных задач, требующих объединения усилий различных специалистов. В ДИ сочетаются признаки метода анализа конкретных ситуаций и ролевых игр, т.е. основой ДИ является цельная модель, включающая и объект управления, и управляющую систему. Основными признаками деловых игр В.Я.Платов считает:  Наличие модели объекта.  Наличие ролей.  Различие ролевых целей при выработке решений.  Взаимодействие участников, исполняющих те или иные роли.  Наличие общей цели у всего игрового коллектива.  Коллективная выработка решений участниками игры.  Реализация в процессе игры ―цепочки решений‖.  Многовариантность решений.  Управление эмоциональным напряжением.  Разветвленная система индивидуального или группового оценивания и деятельности участников игры. Можно все АМО делить на два типа. Первые включают в себя проблемную лекцию, проблемно-активное практическое занятие, самостоятельное курсовое и дипломное проектирование, производственную практику на рабочем месте, олимпиады, научные конференции и т.п. Все они ориентированы на самостоятельную деятельность учащегося, проблемность, но в них отсутствует имитация реальных обстоятельств в условной ситуации. Вторые - имитационные АМО - подразделяются на неигровые и игровые. К неигровым относятся метод анализа конкретных ситуаций, тренажеры, имитационные упражнения на нахождение известного решения. Здесь есть моделирование реальных объектов и ситуаций, но отсутствует свободная игра с ролевыми функциями. К игровым имитационным АМО относятся деловые (управленческие) игры, метод разыгрывания ролей, индивидуальные игровые занятия на машинных моделях. Деловая игра - это метод имитации принятия управленческих решений в экономических, правовых, политических и других ситуациях путем игры группы людей или человека с ЭВМ в учебных или исследовательских целях. Прототипом деловых игр являются игры военные. Накануне второй мировой войны появились военно-политические игры, а после войны имитационные игры применяются в социологии, истории, психологии, криминалистике и др. Общепризнанным автором первой в мире деловой игры является Мария Мироновна Бирштейн. В 1932 г. ею была разработана и проведена деловая игра, посвященная пуску новостроек. 36 В 1980 г. в мире имелось свыше 2000 ДИ. Из них в капиталистических странах было учтено 1210 (в том числе в США около 1000), в СССР - около 300. Учебные. Используются в учебном процессе при подготовке или переподготовке специалистов, а также в системе экономического образования. Производственные. Применяются для решения реальных вопросов текущей деятельности или развития конкретного предприятия, а также для повышения квалификации непосредственно на предприятиях с использованием реального информационного материала. Исследовательские. Проводятся при экспериментировании в управлении и экономике. Важным элементом деловой игры является механизм создания игровой ситуации, близкой к реальности, имитационное моделирование Первая деловая игра с использованием ЭВМ была создана в США. КДИ можно разделить на два типа: коллективные и индивидуальные. В коллективных КДИ участвуют несколько игроков или групп, выполняющих роли лиц, принимающих решения (ЛПР) в изучаемом процессе. В индивидуальных КДИ моделируется не только условная среда, но и действия всех участников игры, кроме одного. Важно отметить, что ДИ в данном случае все равно остается коллективной. Просто отдельные роли в индивидуальной КДИ выполняют интеллектуальные имитаторы. Каждый тип имеет свои преимущества и недостатки. Коллективные КДИ могут быть более приближены к реальности вследствие исполнения ролей ЛПР живыми людьми, а не имитаторами. Здесь игра проходит острее, выше игровой интерес участников. При обмене ролями участники изучают процесс с разных позиций. Однако при низком начальном уровне подготовки участников, низкой квалификации руководителя игры эффект обучения может быть даже отрицательным. У участников возникнет неправильное понимание изучаемого процесса, недоверие к компьютерной программе, отрицательное отношение ко всему методу обучения. Большое преимущество индивидуальной КДИ - невысокие по сравнению с коллективной КДИ требования к квалификации преподавателя. Игра может проводиться вовсе без преподавателя, что весьма важно для дистанционного обучения и для самостоятельной работы учащегося. Конечно, если есть грамотный консультант-преподаватель, качество и скорость усвоения знаний будут выше. В индивидуальной КДИ больше свободы учащегося, он не зависит от уровня подготовки других участников учебного процесса, от темпа их работы и вообще от их присутствия. В обычной ДИ расчет одного цикла управления (партии деловой игры) занимает 2-4 часа, в коллективной КДИ 1-2 часа, в индивидуальной КДИ анализ и расчет занимают минуты. При отработке некоторых стратегий за минуту может быть сыграно несколько десятков партий, а затем по сохраненным результатам проведен анализ. Таким образом, индивидуальная КДИ, появившаяся сравнительно недавно, обладает новыми для ДИ свойствами и возможностями для использования в учебном процессе. Примеры:  Бизнес-курс,  Ижица,  Капитализм,  Дельта,  Комплекс КОББИ. 37 ЛЕКЦИЯ 16. ИНТЕГРИРОВАННАЯ ИНФОРМАЦИОННО-УПРАВЛЯЮЩАЯ СИСТЕМА РГУ НЕФТИ И ГАЗА ИМ. И.М.ГУБКИНА Цели ИИУС РГУ нефти и газа: 1. Оптимизация и повышение технологичности документооборота в университете; 2. Сглаживание неравномерной загрузки в течение учебного и календарного года; 3. Компенсация нехватки или временного отсутствия высококвалифицированных трудно заменяемых сотрудников; 4. Улучшение взаимодействия между подразделениями и повышение их взаимной информированности; 5. Устранение фрагментарности информации и обеспечение единого информационного пространства университета; 6. Хранение больших объемов информации; 7. Обеспечение качества, надежности, целостности, защиты и безопасности информации; 8. Обеспечение своевременности регистрации и поступления информации; 9. Ускорение поиска информации. Функциональная структура ИИУС РГУ нефти и газа включает 10 подсистем (рис.16.1). Требования к свойствам ИИУС РГУ нефти и газа и средства их обеспечения: надежность – обеспечивается использованием отказоустойчивых ЭВМ, устройств бесперебойного питания, надежного базового ПО, тестированием и верификацией разрабатываемого ПО; восстанавливаемость – обеспечивается резервированием базы данных ИИУС; масштабируемость – обеспечивается использованием перспективных базовых программных средств (Oracle, Delphi) и технологий проектирования (CASE-технология); открытость и расширяемость – обеспечивается модульной структурой ИИУС и едиными принципами проектирования и реализации ее составных частей; безопасность и защищенность – обеспечивается: 1) организационными мерами; 2) применеПодсистема сопровождения НИОКР Подсистема сопровождения архива данных Подсистема управления ресурсами Подсистема управления инфраструктурой Подразделения Ресурсы Подсистема обеспечения образовательной услуги Подсистема управления образовательной услугой Подсистема сопровождения образовательной услуги Образовательные услуги Физические лица Подсистема первичного учета физических лиц Подсистема вторичного учета физических лиц Юридические лица Подсистема учета юридических лиц Рис.16.1. Функциональная структура ИИУС РГУ нефти и газа нием СУБД Oracle, обладающей соответствующими развитыми средствами администрирования и санкционирования доступа к данным; 3) использование трех- и четырехзвенной схемы исполнения ИИУС, предусматривающей наличие серверов приложений, ограничивающих непосредственный доступ пользователей к информационным ресурсам; 38 инвариантность к организационным и структурным изменениям – обеспечивается выделением процесса сопровождения организационной структуры в самостоятельную задачу. Средства и методы разработки. Методы структурного моделирования (стандарт IDEF0), концептуального моделирования данных (стандарт IDEF1), экспертных оценок, структурного и визуального программирования, CASE-технология и технология управления проектом. Архитектура ИИУС имеет комбинированную трех- и четырехзвенную структуру, включающую следующие типовые элементы (звенья) (рис.16.2):  сервер данных;  сервер приложений;  интранет-сервер;  автоматизированное рабочее место пользователя ИИУС. Сервер данных предназначен для управления, администрирования, исполнения запросов, модификации, обеспечения целостности, непротиворечивости, безопасности и защиты данных, составляющих информационное обеспечение ИИУС. В качестве сервера данных используется Oracle-сервер. Сервер приложений предназначен для формирования запросов к данным и мониторинга работы пользователей ИИУС (определение – кто и с какого рабочего места вошел в систему, с каким модулем работает, исключение возможности работы одного пользователя с двух компьютеров в случае разглашения пароля или несанкционированного доступа). При двухзвенной архитектуре каждое рабочее место должно быть оснащено программными средствами, обеспечивающими работу с базами данных, что приводит к необходимости закупки большого числа лицензий Oracle. Многозвенная (трех- и четырехзвенная) архитектура предполагает наличие сервера приложений, образующего промежуточное звено между рабочими местами и сервером данных и обеспечивающего работу с базами данных. Это дает возможность устанавливать СУБД Oracle только на серверы приложений, минимизировать число закупаемых лицензий базового программного обеспечения. Ожидаемая экономия составляет около $90000 при условии сохранения полной функциINTERNET Intranet сервер РГУ Рабочие места Приложения ИИУС ЛОКАЛЬНАЯ СЕТЬ РГУ Сервер данных Сервер приложений Приложения ИИУС Рис.16.2. Архитектура ИИУС РГУ нефти и газа ональности системы без нарушения лицензионной чистоты. Кроме того, использование серверов приложений обеспечивает дополнительную степень защиты информации, так как предотвращает непосредственный доступ с рабочих мест к СУБД Oracle. 39 Интранет-сервер предназначен для реали- зации пользовательских приложений, вызов и доступ к которым с рабочих мест осуществляется с помощью web-броузера. Интранет-сервер позволяет перейти от трехзвенной архитектуры (технологии «толстого клиента») к четырехзвенной (технологии «тонкого клиента»). При трехзвенной архитектуре пользовательские приложения необходимо физически устанавливать на каждом компьютере. При этом любое изменение приложения требует переустановки программного обеспечения на каждом рабочем месте. Кроме того, загрузка приложений с единого файл-сервера оправдана только при небольшом количестве рабочих мест (от 5 до 10). В противном случае наблюдается резкий рост трафика сети (1,5–3 Мбайт), что бывает вызвано постоянными обращениями и загрузке «толстых» пользовательских приложений. При четырехзвенной архитектуре приложения располагаются на специальном выделенном сервере – интранет-сервере. В этом случае вызов пользовательского приложения на рабочем месте осуществляется обычным web-броузером. К числу недостатков четырехзвенной схемы относятся следующие:  при плохой организации безопасности локальной сети снижается безопасность системы, т.к. web-сервер может быть подвергнут вмешательству извне;  двукратно увеличивается трафик сети (эта проблема становится несущественной при обеспечении соответствующей пропускной способности сети);  обычные интернет-технологии имеют ограниченный набор выразительных средств создания пользовательского интерфейса. Принято решение о комбинировании трех- и четырехзвенной схемы. Автоматизированное рабочее место предназначено для обеспечения работы конечного пользователя с ИИУС. Для реализации рабочих мест приняты следующие технологические решения:  среда создания пользовательских приложений – Delphi 4;  технология создания пользовательских приложений – ActiveX, позволяющая одновременную реализацию как трех-, так и четырехзвенной архитектуры без изменения исходного кода программ;  в условиях использования однотипной операционной среды Windows, связь рабочих мест с сервером приложений можно осуществлять с помощью коммуникационного протокола Winsocket, являющегося составной частью операционной системы (вместо обычного использования оплачиваемых протоколов Corba или Midas – при стоимости одной лицензии около $150 общая экономия составит около $22500). 40 ЛЕКЦИЯ 17. ОБЕСПЕЧИВАЮЩИЕ ПОДСИСТЕМЫ ГАЗА ИМ. И.М.ГУБКИНА ИИУС РГУ НЕФТИ И Результаты обследования и функционального моделирования ИИУС:  в рамках обследования проведено более 100 опросов, в которых принимал участие 61 эксперт из 39 основных подразделений университета;  построены 27 функциональных моделей (около 250 диаграмм), описывающих около 50 управленческих задач;  выявлены и описаны в виде диаграмм основные взаимосвязи, существующие между подразделениями университета;  выявлены и описаны основные материальные и информационные объекты, их потоки и внутренняя структура; собраны формы документов первичного и вторичного учета объектов;  выявлены «узкие» места, снижающие эффективность и/или качество реализации отдельных управленческих процессов; разработаны предложения по их оптимизации;  выявлено существующее положение дел с автоматизацией и информатизацией процессов учета, контроля и управления, получено описание основных баз данных университета. Техническое обеспечение ИИУС включает аппаратно-технические средства для реализации:  автоматизированных рабочих мест пользователей ИИУС;  сервера данных и серверов приложений ИИУС;  корпоративной Intranet-сети РГУ нефти и газа. Ожидаемое количество автоматизированных рабочих мест ИИУС – 200–250. Увеличение дискового пространства сервера данных понадобится через 8–10 лет. Требования к техническому обеспечению ИИУС Таблица 17.1 Оборудование Рекомендуемые характеристики Характеристики, допустимые в течение одного года Сервер данных (СУБД Oracle) Sun Ultra450 / 512Mb / 20Gb Pentium III 450 256Mb / 10Gb Сервер приложений Pentium III 450 256Mb / 6Gb Pentium II 300 128Mb / 6Gb Автоматизированные рабочие места Pentium II 300 64Mb / 6Gb Pentium 32Mb / 2Gb Intranet сервер Pentium III 450 256Mb / 6Gb Pentium II 300 128Mb / 6Gb Локальная сеть 100 Мбит 10 Мбит Программное обеспечение. К программным средствам, обеспечивающим разработку ИИУС, относятся CASE-средства (BPwin, Power Designer), предназначенные для функционального и информационного моделирования ИИУС, среда программирования пользовательских приложений (Delphi) и среда создания баз данных (Oracle 8i) (табл.17.2). К программным средствам, обеспечивающим функционирование ИИУС, относятся операционные системы и оболочки (Windows NT Server, Windows 98 (95)), система управления базами данных (Oracle 8i), оригинальное прикладное программное обеспечение (пользовательские приложения), реализующее функции ИИУС и создаваемое в ходе разработки системы, приобретаемые прикладные программные продукты (пользовательские приложения), реализующие отдельные функции ИИУС (такие, как бухгалтерский учет, сопровождение фонда литературы и др.) Программное обеспечение ИИУС Табл. 17.2. Базовое программное обеспечение Назначение Oracle 8i (5 лицензий) Для разработки и управления базами данных BPWin (1 лицензия) Для функционального моделирования Power Designer (1 лицензия) Для информационного моделирования Delphi (3 лицензии) 41 Для разработки пользовательских приложений Windows NT Server Для функционирования сервера приложений Windows 98 (95) Для функционирования рабочих мест Прикладное программное обеспечение Более 60 оригинальных модулей Назначение Для реализации функций ИИУС Приобретаемые системы Для реализации функций ИИУС Информационное обеспечение ИИУС (табл.17.3) включает информационные хранилища двух видов: оперативные базы данных и хранилища данных. Ожидаемый объем оперативных баз данных – 2,5 Гбайт с ежегодным приростом около 600 Мбайт. Хранилища данных предназначены для архивного хранения информации, используемой в задачах анализа, прогнозирования и принятия управленческих решений. Базовые информационные массивы ИИУС Табл. 17.3. Массивы Назначение Преподаватель, Сотрудник, Абитуриент, Студент, Аспирант, Докторант, Соискатель, Школьник, Слушатель довузовской подготовки, Слушатель повышения квалификации, Посетитель Первичный учет физических лиц Карточки личного, учебного, педагогического, режимного, воинского, мобилизационного, охранного, медицинского, профсоюзного, читательского, имущественного, визового, регистрационного, квалификационного учета, безопасности труда Вторичный учет физический лиц Предприятие нефтегазовой отрасли, Вуз нефтегазовой отрасли, Предприятие, организация, Зарубежная организация, Попечитель Учет юридических лиц Учебный план (типовой, рабочий), Дисциплина, Должность, Управление, обеспечеРасписание занятий и экзаменов, Распределение нагрузки, ние, сопровождение обАудитория, Оборудование, Литература разовательных услуг Договор НИОКР, Диссертация, Патент, Лицензия, Свидетельство Сопровождение научноисследовательской деятельности Подразделение, Помещение, Площадь, Комната, Документ, Работа, Расход, Доход, Договор на обучение Управление инфраструктурой и ресурсами Хранилище данных Сопровождение архива данных Организационное обеспечение ИИУС предполагает реализацию ряда обязательных и рекомендуемых организационных и административных мер, обеспечивающих создание и эффективную эксплуатацию ИИУС. К основным обязательным мерам относятся:  возложение на должностных лиц ответственности за консультирование разработчиков пользовательских приложений ИИУС по вопросам организации работы подразделений РГУ нефти и газа;  формализация отдельных управленческих процессов в университете;  разработка, утверждение и внедрение классификаторов основных материальных и информационных объектов университета (подразделений, документов, физических лиц и др.);  унификация и оптимизация различных видов и документов учета всех категорий физических лиц в университете (включая различные категории студентов – иностранные, вечерние и др.), 42 уточнение и/или формирование порядка (организационного протокола) взаимодействия некоторых подразделений университета;  возложение на должностных лиц ответственности за ввод и поддержание в актуальном состоянии информационных массивов, находящихся в сфере их деятельности;  разработка процедуры согласования, издания и оборота документов в условиях эксплуатации ИИУС (включая процессы безбумажного согласования и утверждения документов);  принятие решения о приобретении и внедрении прикладного программного обеспечения, автоматизирующего отдельные функции ИИУС;  создание подразделения (группы), эксплуатирующей и сопровождающей ИИУС, переориентация и переподчинение разработчиков информационных систем в университете на задачи эксплуатации и сопровождения ИИУС. К основным рекомендуемым мерам относятся:  модернизация процесса оперативного планирования учебного процесса, включающего на сегодняшний день генерацию семестровых учебных планов, закрепление дисциплин за кафедрами, генерацию и распределение нагрузки;  определение статуса информации, хранящейся в электронном виде, и поэтапный переход (по возможности) на полностью или частично безбумажную технологию учета;  централизация маркетинговых функций взаимодействия с внешними организациями в одном созданном или выделенном подразделении (группе). Интеллектуальное обеспечение ИИУС включает алгоритмы формирования вторичной информации и алгоритмы принятия управленческих решений с помощью ИИУС. Интеллектуальное обеспечение создается в виде баз знаний отдельных подсистем ИИУС. Интеллектуальное обеспечение и функции поддержки решений являются объектами проектирования третьей очереди создания ИИУС. Кадровое обеспечение ИИУС включает 8 основных ролей специалистов, работающих с системой (табл.17.4). Для эффективной эксплуатации и сопровождения ИИУС рекомендуется создание соответствующего подразделения (или группы в рамках существующего подразделения). Роли специалистов, работающих с ИИУС Табл. 17.4  Роль Администратор базы данных Системный программист Прикладной программист Администратор сети Системный аналитик Оператор Коли Функции личе чество 1 Администрирование в СУБД Oracle, обслуживание данных 1 Программирование в СУБД Oracle Требования к подготовке Курсы, участие в разработке ИИУС То же Доработка и модернизация пользова- То же тельских приложений на Delphi 1 Администрирование ИИУС, обслуНаличие соответствующей живание пользователей квалификации 1 Анализ функционирования и развиСпособности к аналитичетие ИИУС ской работе 2 Ввод информационных массивов на Не требуется этапе внедрения ИИУС Менеджер 1 Управление группой эксплуатации и Опыт управления подобнысопровождения ИИУС ми разработками Пользователь 200Использование ИИУС по назначеВ ходе разработки, внедре250 нию, сопровождение информационния и опытной эксплуатации ных массивов приложения Финансовое обеспечение ИИУС включает финансирование процессов разработки, эксплуатации и модернизации системы (табл.17.5). Финансовые затраты на разработку ИИУС Табл. 17.5. 3 Статья затрат 43 Количество Стоимость Сервер данных (Oracle-сервер) 1 $ 10000 – 15000 Сервер приложений 1 $ 2500 – 3000 СУБД Oracle 8i 5 лицензий $ 515 х 5 = 2575 Пакет BPWin 2.5 1 $ 2870 Пакет Power Designer 1 $ 5490 Среда Delphi 4 3 $ 1498 х 3 = 4494 Разработка программного обеспечения 2 очереди 8–12 чел.-лет $ 50000 + 30000 = 80000 Обучение администратора Oracle 1 $ 469 Обучение программированию на Oracle 1 $ 420 Обучение программированию на Delphi 1 $ 469 44 СОКРАЩЕНИЯ АРМ БД ДИ ЖЦ ИИУС ИС ИСУП ИТ КДИ КИС (EIS) НСП ОС ПК ПО СУБД ЭВМ BPR CASE - Автоматизированное рабочее место База данных Деловая игра Жизненный цикл Интегрированная информационно-управляющая система Информационная система Интегрированная система управления предприятием Информационные технологии Компьютерная деловая игра Корпоративная информационная система (Enterprise Information System) - СОRВА - CSRP - DFD DSS ERD ERP MRP MRP-II OLAP ОLЕ RAD SADT - SQL UML - Новое системное проектирование Операционная система Персональный компьютер Программное обеспечение Система управления базами данных Электронно-вычислительная машина Business Process Reengineering - реконструкция бизнес-процессов Computer-Aided Software/System Engineering – автоматизированное проектирование ПО/систем Common Object Request Broker Architecture - архитектура брокера объектных запросов Customer Synchronized Resource Planning - планирование ресурсов, включающее взаимодействие с клиентами Data Flow Diagrams - диаграммы потоков данных Decision Support System - система поддержки принятия решений Entity-Relationship Diagrams – диаграммы "сущность-связь" Enterprise Resources Planning – планирование ресурсов предприятия Material Requirements Planning - планирование потребностей в материалах Manufacturing Resources Planning - планирование ресурсов производства Online Analytical Processing - оперативная аналитическая обработка Object Linking and Embedding - связывание и внедрение объектов Rapid Application Development - быстрая разработка приложений Structured Analysis and Design Technique – технология структурного анализа и проектирования Structured Query Language - язык структурированных запросов Unified Modeling Language - унифицированный язык моделирования 45 ЛИТЕРАТУРА Книги 1. Вендров А.М. CASE-технологии. Современные методы и средства проектирования информационных систем. –М.: Финансы и статистика, 1998. –176 с. 2. Маклаков С.В. BPwin и ERwin. CASE-средства разработки информационных систем. –М.: ДИАЛОГ-МИФИ, 1999. -256 с. 3. Разработка концепции ИИУС РГУ нефти и газа им. И.М.Губкина. Книга 1. –М.: SoftService,1999.–103 с. 4. Сапунцов В.Д. Компьютер в экономическом образовании. –М.: Новый век, 1999. – 232 с. 5. Фаулер М., Скотт К. UML в кратком изложении. Применение стандартного языка объектного моделирования. Пер. с англ. – М.: Мир, 1999. -191 с. Журнальные статьи 6. Зиндер Е.З. Новое системное проектирование: информационные технологии и бизнесреинжиниринг. СУБД № 4, 1995, № 1,2 1996. 7. Казанский Д.Л. Системы ERP: основные задачи и область применения. Сети и системы связи, №2, 1998, с.30. 8. Калянов Г.Н. Российский рынок CASE-средств. PC WEEK/RE, № 23, 1998. 9. Карпачев И.И. Классификация компьютерных систем управления предприятием. PC WEEK/RE, № 44, 1998. 10. Линтикам Д.С. Разгадка архитектуры клиент-сервер. PC Magazine, № 7, 1996. 11. Монахова Е.С. Приближаемся к MRP II или удаляемся от него? PC WEEK/RE, № 38, 1999, с.10. 12. Монахова Е.С., Никитина Н.К., Бобровский С.И. КИС и ИСУП: найдите шесть различий. PC WEEK/RE, № 33, 1999, с.18. 13. Новоженов Ю.В. JAVA- технологии. Средства визуального моделирования. Computer Weekly, № 39, 1998. Материалы сети Интернет 14. Баронов В.В., Попов Ю.И., Позин Б.А., Титовский И.Н. Особенности использования и внедрения ERP - систем в России. Материалы конференции "Корпоративные Информационные Системы", ЦИТ, 1999. 15. Вольфман Б.А. Pазработкa корпоративных систем с использованием современных инструментальных средств. Материалы Российского сервера CASE-технологий http://case.ru 16. Старыгин А.Н. Построение корпоративных информационных систем: технологии и решения. Материалы Сервера http://citforum.ru 17. Что такое OMG-UML и почему он важен. Материалы Object Management Group Press Release,1997, пер. с англ. Когаловский М. 18. Ямов С.И., Кабак И.С. Актуальность и перспективы использования объектноориентированного подхода при проектировании сложных гибких систем управления. Материалы сервера http://magazine.stankin.ru