Содержание Системное представление ЭИС. Определение и обобщенная схема ЭИС. .................2 Классификация ЭИС по режиму работы, способу распределения вычислительных ресурсов и концепции построения. ..............................................................................................6 Единицы структурирования экономической информации. Семантическая схема ЭИС. ................................................................................................................................................7 Системы поддержки принятия решений (СППР) как класс интеллектуальных ИС. Основные решаемые ими задачи. ................................................................................................8 Проектирование экспертных систем и систем искусственного интеллекта. Сравнение парадигмы решения проблем в этих системах. .......................................................9 Технологическая сеть проектирования, ее формализованное описание. Основные компоненты технологии проектирования ЭИС. .......................................................................16 Стандарты проектирования, документирования и интерфейса ЭИС. ........................19 Применение кибернетической схемы и GAP-анализа при проектировании ЭИС. ...20 Реинжиниринг бизнес-процессов при внедрении ЭИС. ..............................................21 Функционально-стоимостной анализ ЭИС. Совокупная стоимость владения ЭИС.25 Совокупная стоимость владения системой и риски .....................................................25 Выбор технологии проектирования экономических информационных систем. Типовое проектирование экономических информационных систем. ....................................27 Методика канонического проектирования ЭИС. .........................................................30 Методика индустриального проектирования ЭИС ......................................................32 Автоматизированное проектирование информационных систем с использованием технологий RAD, ERP, CASE.....................................................................................................33 Адаптация ЭИС с помощью CASE-средств. Обзор нотаций, используемых в CASEсредства ........................................................................................................................................40 Системное представление ЭИС. Определение и обобщенная схема ЭИС. Методологическую основу проектирования ЭИС составляет системный подход, в соответствии с которым любая система представляет собой совокупность взаимосвязанных объектов (элементов), функционирующих совместно для достижения общей цели. Для системы характерно изменение состояний объектов, которое с течением времени происходит в результате взаимодействия объектов в различных процессах и с внешней средой. В результате такого поведения системы важно соблюдение следующих принципов: • эмерджентности, то есть целостности системы на основе общей структуры, когда поведение отдельных объектов рассматривается с позиции функционирования всей системы; • гомеостазиса, то есть обеспечения устойчивого функционирования системы и достижения общей цели; • адаптивности к изменениям внешней среды и управляемости посредством воздействия на элементы системы; • обучаемости путем изменения структуры системы в соответствии с изменением целей системы. Структура экономической системы (промышленного предприятия, торговой организации, коммерческого банка, государственного учреждения и т.д.) с позиций кибернетики представлена на рис. 1.1, где основные информационные потоки между внешней средой, объектом и системой управления помечены метками над стрелками ИП1, ИП2, ИПЗ, ИП4 и связаны с поддерживающей их экономической информационной системой (ЭИС). В экономической системе объект управления представляет собой подсистему материальных элементов экономической деятельности (на промышленном предприятии: сырье и материалы, оборудование, готовая продукция, работники и др.) и хозяйственных процессов (на промышленном предприятии: основное и вспомогательное производство, снабжение, сбыт и др.). Система управления представляет собой совокупность взаимодействующих структурных подразделений экономической системы (например, на промышленном предприятии: дирекция, финансовый, производственный, снабженческий, сбытовой и другие отделы), осуществляющих следующие функции управления: планирование - функция, определяющая цель функционирования экономической системы на различные периоды времени(стратегическое, тактическое, оперативное планирование); учет - функция, отображающая состояние объекта управления в результате выполнения хозяйственных процессов; контроль - функция, с помощью которой определяется отклонение учетных данных от плановых целей и нормативов; оперативное управление - функция, осуществляющая регулирование всех хозяйственных процессов с целью исключения возникающих отклонений в плановых и учетных данных; анализ - функция, определяющая тенденции в работе экономической системы и резервы, которые учитываются при планировании на следующий временной период. Рис. 1.1 Структура экономической системы Экономическая информационная система (ЭИС) представляет собой совокупность организационных, технических, программных и информационных средств, объединенных в единую систему с целью сбора, хранения, обработки и выдачи необходимой информации, предназначенной для выполнения функций управления. ЭИС связывает объект и систему управления между собой и с внешней средой через информационные потоки: ИШ - информационный поток из внешней среды в систему управления, который, с одной стороны, представляет поток нормативной информации, создаваемый государственными учреждениями в части законодательства, а, с другой стороны, - поток информации о конъюнктуре рынка, создаваемый конкурентами, потребителями, поставщиками; ИП2 - информационный поток из системы управления во внешнюю среду, а именно: отчетная информация, прежде всего финансовая информация в государственные органы, инвесторам, кредиторам, потребителям; маркетинговая информация потенциальным потребителям; ИПЗ - информационный поток из системы управления на объект управления (прямая кибернетическая связь), представляющий совокупность плановой, нормативной и распорядительной информации для осуществления хозяйственных процессов; ИП4 - информационный поток от объекта управления в систему управления (обратная кибернетическая связь), который отражает учетную информацию о состоянии объекта управления экономической системой (сырья, материалов, денежных, энергетических, трудовых ресурсов, готовой продукции и выполненных услугах) в результате выполнения хозяйственных процессов. ЭИС накапливает и перерабатывает поступающую учетную информацию и имеющиеся нормативы и планы в аналитическую информацию, служащую основой для прогнозирования развития экономической системы, корректировки ее целей и создания планов для нового цикла воспроизводства. К обработке информации в ЭИС предъявляются следующие требования: полнота и достаточность информации для реализации функций управления; своевременность предоставления информации; обеспечение необходимой степени достоверности информации в зависимости от уровня управления; экономичность обработки информации: затраты на обработку данных не должны превышать получаемый эффект; адаптивность к изменяющимся информационным потребностям пользователей. В соответствии с характером обработки информации в ЭИС на различных уровнях управления экономической системой (оперативном, тактическом и стратегическом) выделяются следующие типы информационных систем (рис. 1.2): системы обработки данных (EDP) информационная система управления (MIS) система поддержки принятия решений (DSS) Рис 1.2 Обобщенная технологическая схема жизненного цикла ЭИС Системы обработки дачных (СОД) предназначены для учета и оперативного регулирования хозяйственных операций, подготовки стандартных документов для внешней среды (счетов, накладных, платежных поручений). Горизонт оперативного управления хозяйственными процессами составляет от одного до несколько дней и реализует регистрацию и обработку событий, например оформление и мониторинг выполнения заказов, приход и расход материальных ценностей на складе, ведение табеля учета рабочего времени и т.д. Эти задачи имеют итеративный, регулярный характер, выполняются непосредственными исполнителями хозяйственных процессов (рабочими, кладовщиками, администраторами и т.д.) и связаны с оформлением и пересылкой документов в соответствии с четко определенными алгоритмами. Результаты выполнения хозяйственных операций через экранные формы вводятся в базу данных. Информационные системы управления (ЦСУ) ориентированы на тактический уровень управления: среднесрочное планирование, анализ и организацию работ в течение нескольких недель (месяцев), например анализ и планирование поставок, сбыта, составление производственных программ. Для данного класса задач характерны регламентированность (периодическая повторяемость) формирования результатных документов и четко определенный алгоритм решения задач, например свод заказов для формирования производственной программы и определение потребности в комплектующих деталях и материалах на основе спецификации изделий. Решение подобных задач предназначено для руководителей различных служб предприятий (отделов материально-технического снабжения и сбыта, цехов и т.д.)- Задачи решаются на основе накопленной базы оперативных данных. Системы поддержки принятия решений (СППР) используются в основном на верхнем уровне управления (руководства фирм, предприятий, организаций), имеющего стратегическое долгосрочное значение в течение года или нескольких лет. К таким задачам относятся формирование стратегических целей, планирование привлечения ресурсов, источников финансирования, выбор места размещения предприятий и т.д. Реже задачи класса СППР решаются на тактическом уровне, например при выборе поставщиков или заключении контрактов с клиентами. Задачи СППР имеют, как правило, нерегулярный характер. Для задач СППР свойственны недостаточность имеющейся информации, ее противоречивость и нечеткость, преобладание качественных оценок целей и ограничений, слабая формализованность алгоритмов решения. В качестве инструментов обобщения чаще всего используются средства составления аналитических отчетов произвольной формы, методы статистического анализа, экспертных оценок и систем, математического и имитационного моделирования. При этом используются базы обобщенной информации, информационные хранилища, базы знаний о правилах и моделях принятия решений. Идеальной считается ЭИС, которая включает все три типа перечисленных информационных систем. В зависимости от охвата функций и уровней управления различают корпоративные (интегрированные) и локальные ЭИС. Корпоративная (интегрированная) ЭИС автоматизирует все функции управления на всех уровнях управления. Такая ЭИС является многопользовательской, функционирует в распределенной вычислительной сети. Локальная ЭИС автоматизирует отдельные функции управления на отдельных уровнях управления. Такая ЭИС может быть однопользовательской, функционирующей в отдельных подразделениях системы управления. Одним из основных свойств ЭИС является делимость на подсистемы, которая имеет ряд достоинств с точки зрения разработки и эксплуатации ЭИС, к которым относятся: упрощение разработки и модернизации ЭИС в результате специализации групп проектировщиков по подсистемам; упрощение внедрения и поставки готовых подсистем в соответствии с очередностью выполнения работ; упрощение эксплуатации ЭИС вследствие специализации работников предметной области. Обычно выделяют функциональные и обеспечивающие подсистемы. Функциональные подсистемы ЭИС информационно обслуживают определенные виды деятельности экономической системы (предприятия), характерные для структурных подразделений экономической системы и (или) функций управления. Интеграция функциональных подсистем в единую систему достигается за счет создания и функционирования обеспечивающих подсистем, таких, как информационная, программная, математическая, техническая, технологическая, организационная и правовая подсистемы. Классификация ЭИС по режиму работы, вычислительных ресурсов и концепции построения. способу распределения ЭИС представляет собой систему, функционирование которой во времени заключается в сборе, хранении, обработке и распространении информации о деятельности какого либо эк. объекта реального мира. ИС создается для конкретного эк. объекта и должна в определенной мере копировать взаимосвязи элементов объекта. ЭИС предназначены для: 1. решения задач обработки данных. (обработка и хранение эк. информации с целью выдачи сводной информации, которая может потребоваться для управления эк. объектами). 2. автоматизации конторских работ. Предполагает наличие в ЭИС системы ведения картотек, системы обработки текстовой информации, системы машинной графики, системы электронной почты в связи. 3. отдельных задач, основанных на методах искусств. интеллекта. Алгоритмы искусств. интеллекта необходимы для задач принятия управленческих решений, основанных на моделировании действий специалистов предприятия при принятии решений. Классификация ЭИС: 1. по функциональному признаку; 2. по способу распределения вычислит. ресурсов; 3. по режимам работы ЭИС. Среди ЭИС выделяют управляющие ИС (для управления технологическими процессами) и системы административно - организационного типа для обслуживания коллектива специалистов осуществляющих управление предприятием. С функциональной точки зрения: 1. Система обработки данных (СОД); 2. Автоматизированная система управления (АСУ); 3. Инф. поисковая система (ИПС); Многие ЭИС обладают чертами нескольких классов. СОД производит инф. обслуживание специалистов органов управления объектом, принимающих управленческое решение. Если СОД способна выполнять выбор управленческого решения, то она становится АСУ. Типичными для АСУ являются задачи оптимального управления запасами материалов. ИПС предназначены для отыскания, в каком то множестве документов тех, которые посвящены указанной в инф. запросе теме или содержат необходимые сведения. По режимам работы, можно выделить следующие: 1. Пакетные. Пакетная технология, или пакетный режим обработки данных: задания объединяются в пакет, а затем выполняются на ЭВМ без вмешательства пользователя. Задание - единица работы, определяемая пользователем и представляющая собой последовательность команд операционной системы для указания нужных характеристик и имен выполняемой программы и обрабатываемых ею данных. 2. Диалоговые. Диалоговый режим - режим работы, при котором происходит обмен сообщениями между пользователем и системой. Роль "активного" элемента пользователь и система выполняют попеременно. ЭИС активна от момента завершения ввода информации и команд пользователем до завершения обработки команд (запроса). Пользователь обдумывает результат обработки запроса и вводит данные для следующего запроса. Следует отметить, что последовательность команд, вводимых пользователем, не является фиксированным заранее, а существенно зависит от результатов ранее выполненных команд. По способу распределения выч. ресурсов: 1. Локальные. Используется 1 ПК. 2. Распределенные. Соединение ПЭВМ каналами связи. Каждый может выполнять свои функции. Единицы структурирования экономической информации. Семантическая схема ЭИС. Информация в ЭИС строится по иерархическому признаку. Минимальной неделимой единицей информации в ЭИС является реквизит. Реквизиты: 1.Реквизит – основания Это минимальная единица информации, которая характеризует объект с количественной стороны (числа, которые подвергаются математической обработке) 2.Реквизит – признак Это минимальная единица информации, которая характеризует объект с качественной стороны (слова, коды) Реквизиты, взятые по отдельности не обеспечивают всесторонний характеристики объекта, поэтому они объединяются в единицу более высокого уровня – показатель (строка в документе). Показатель состоит из реквизита – основания (числа) и относящихся к нему одного или нескольких реквизитов – признаков. Ряд реквизитов или показателей, одинаковых по форме, но разных по содержанию образуют массив. Массив – это набор однородных единиц информации. Массивы по различным признакам объединяются в информационные сообщения. Информационные сообщения в зависимости от функциональной принадлежности объединяют в информационные подсистемы. Информационные подсистемы объединяются в единицу информации самого высокого уровня – информационную систему (ИС). ИС – вся информация об объекте. Другой вариант ответа: В процессе обработки данных на ПК широко используется понятие структуры информации. Структурой определяется строение информации и предусматривается выделение определенных ее элементов (частей), которые называются единицами. Единицы бывают простыми и сложными. К простым относятся такие элементы, которые нельзя разделить на части. Сложные единицы составлены, образованны, из других информационных единиц, простых или сложных. При иерархической (многоуровневой) структуре экономической информации единицей низшего уровня является реквизит, составляющий единицу информации, не подлежит какому-либо членения. Реквизиты представляют собой слова или числа. Реквизиты, характеризующие объект управления качественно, называют признаками, а количественно - основаниями. Взятые отдельно реквизиты - признаки и основания - не обеспечивают всесторонней характеристики явлений в экономике. Поэтому они объединяются, образуя такую информационную единицу, как показатель. Он может быть простым (состоять из одной основы и одного признака) или сложным (насчитывать ряд признаков). В управлении используются также единицы информации, состоящие из самих реквизитовпризнаков. Такие единицы принято называть информационными сообщениями. Высший уровень информационной единицы - набор данных, есть совокупность однородных показателей и реквизитов-признаков на внешнем запоминающем устройстве. Набор данных называется файлом по терминологии ряда систем программирования. Набор данных (файл) делится на части, которые не совпадают с единицами информации; совокупность наборов данных, касающихся одного участка управленческой работы, часто называют информационным потоком. Любые составляющие информационной единицы (от отдельных показателей к информационной системе в целом) можно раскладывать, наконец, на информацию и тем самым подсчитывать количество минимальных единиц информации, которые лежат в основе ее структурных построений. С точки зрения мировой экономики можно рассмотреть вопрос следующим образом: Экономическая информация - это совокупность данных (сведений), используемых при осуществлении функции управления экономическими объектами. На мировом рынке экономическая информация подразделяется на следующие сектора: 1. сектор деловой информации: · биржевая и финансовая информация - информация о котировках ценных бумаг, валютных курсах, учетных ставках, рынке товаров и компьютеров, инвестициях, ценах и т.д. · экономическая и статистическая информация - числовая, демографическая или социальная информация в виде рядов динамики, прогнозных моделей или оценок. Представляется государственными службами или консалтинговыми фирмами. · коммерческая информация - информация по фирмам, о финансовом состоянии фирм, о связях, сделках, направлениях работы, продукции, ценах. Представляется информационными брокерами и специальными службами по запросам · деловые новости в сфере экономики и бизнеса 2. сектор научно-профессиональной информации (документированная, библиографическая, справочная информация в области фундаментальных и прикладных исследований отраслей производства и сфер экономики). 3. сектор массовой (потребительской) информации (новости, справочники, информация о курсах валют, услуги телетекста, различная информация о поездах, авиалиниях,..) 4. сектор социально-политической информации (эта информация представляется субъектами хозяйствования в органы государственного управления и охватывает статистическую, социальную, архивную и специальную экономическую информацию Семантическая сеть — информационная модель предметной области, имеющая вид ориентированного графа, вершины которого соответствуют объектам предметной области, а дуги (рёбра) задают отношения между ними. Объектами могут быть понятия, события, свойства, процессы. Таким образом, семантическая сеть является одним из способов представления знаний. В названии соединены термины из двух наук: семантика в языкознании изучает смысл единиц языка, а сеть в математике представляет собой разновидность графа — набора вершин, соединённых дугами (рёбрами). В семантической сети роль вершин выполняют понятия базы знаний, а дуги (причем направленные) задают отношения между ними. Таким образом, семантическая сеть отражает семантику предметной области в виде понятий и отношений. Системы поддержки принятия решений (СППР) как класс интеллектуальных ИС. Основные решаемые ими задачи. Система поддержки принятия решений или СППР (Decision Support Systems, DSS) — это компьютерная система, которая путем сбора и анализа большого количества информации может влиять на процесс принятия решений организационного плана в бизнесе и предпринимательстве. Интерактивные системы позволяют руководителям получить полезную информацию из первоисточников, проанализировать ее, а также выявить существующие бизнес-модели для решения определенных задач. С помощью СППР можно проследить за всеми доступными информационными активами, получить сравнительные значения объемов продаж, спрогнозировать доход организации при гипотетическом внедрении новой технологии, а также рассмотреть все возможные альтернативные решения. Классификации По взаимодействию с пользователем выделяют три вида СППР: пассивные помогают в процессе принятия решений, но не могут выдвинуть конкретного предложения; активные непосредственно участвуют в разработке правильного решения; кооперативные предполагают взаимодействие СППР с пользователем. Выдвинутое системой предложение пользователь может доработать, усовершенствовать, а затем отправить обратно в систему для проверки. После этого предложение вновь представляется пользователю, и так до тех пор, пока он не одобрит решение. По способу поддержки различают: модельно-ориентированные СППР, используют в работе доступ к статистическим, финансовым или иным моделям; СППР, основанные на коммуникациях, поддерживают работу двух и более пользователей, занимающихся общей задачей; СППР, ориентированные на данные, имеют доступ к временным рядам организации. Они используют в работе не только внутренние, но и внешние данные; СППР, ориентированные на документы, манипулируют неструктурированной информацией, заключенной в различных электронных форматах; СППР, ориентированные на знания, предоставляют специализированные решения проблем, основанные на фактах. По сфере использования выделяют общесистемные и настольные СППР. Общесистемные работают с большими СХД и применяются многими пользователями. Настольные являются небольшими системами и подходят для управления с персонального компьютера одного пользователя. СППР позволяет облегчить работу руководителям предприятий и повысить ее эффективность. Они значительно ускоряют решение проблем в бизнесе. СППР способствуют налаживанию межличностного контакта. На их основе можно проводить обучение и подготовку кадров. Данные информационные системы позволяют повысить контроль над деятельностью организации. Наличие четко функционирующей СППР дает большие преимущества по сравнению с конкурирующими структурами. Благодаря предложениям, выдвигаемым СППР, открываются новые подходы к решению повседневных и нестандартных задач. Проектирование экспертных систем и систем искусственного интеллекта. Сравнение парадигмы решения проблем в этих системах. Экспертные системы, методика построения В настоящее время сложилась определенная технология разработки ЭС, которая включает следующие шесть этапов: идентификация, концептуализация, формализация, выполнение, тестирование и опытная эксплуатация. Рис. 9.1. Методика (этапы) разработки ЭС Этап идентификации Этап идентификации связан, прежде всего, с осмыслением тех задач, которые предстоит решить будущей ЭС, и формированием требований к ней. Результатом данного этапа является ответ на вопрос, что надо сделать и какие ресурсы необходимо задействовать (идентификация задачи, определение участников процесса проектирования и их роли, выявление ресурсов и целей). Обычно в разработке ЭС участвуют не менее трех-четырех человек — один эксперт, один или два инженера по знаниям и один программист, привлекаемый для модификации и согласования инструментальных средств. Также к процессу разработки ЭС могут по мере необходимости привлекаться и другие участники. Например, инженер по знаниям может пригласить других экспертов, чтобы убедиться в правильности своего понимания основного эксперта, представительности тестов, демонстрирующих особенности рассматриваемой задачи, совпадения взглядов различных экспертов на качество предлагаемых решений. Кроме того, для сложных систем считается целесообразным привлекать к основному циклу разработки несколько экспертов. Однако в этом случае, как правило, требуется, чтобы один из экспертов отвечал за непротиворечивость знаний, сообщаемых коллективом экспертов. Идентификация задачи заключается в составлении неформального (вербального) описания, в котором указываются: общие характеристики задачи; подзадачи, выделяемые внутри данной задачи; ключевые понятия (объекты), их входные (выходные) данные; предположительный вид решения, а также знания, относящиеся к решаемой задаче. В процессе идентификации задачи инженер по знаниям и эксперт работают в тесном контакте. Начальное неформальное описание задачи экспертом используется инженером по знаниям для уточнения терминов и ключевых понятий. Эксперт корректирует описание задачи, объясняет, как решать ее и какие рассуждения лежат в основе того или иного решения. После нескольких циклов, уточняющих описание, эксперт и инженер по знаниям получают окончательное неформальное описание задачи. При проектировании ЭС типичными ресурсами являются источники знаний, время разработки, вычислительные средства и объем финансирования. Для эксперта источниками знаний служат его предшествующий опыт по решению задачи, книги, известные примеры решения задач, а для инженера по знаниям — опыт в решении аналогичных задач, методы представления знаний и манипулирования ими, программные инструментальные средства. При определении времени разработки обычно имеется в виду, что сроки разработки и внедрения ЭС составляют, как правило, не менее года (при трудоемкости 5 чел.-лет). Определение объема финансирования оказывает существенное влияние на процесс разработки, так как, например, при недостаточном финансировании предпочтение может быть отдано не разработке оригинальной новой системы, а адаптации существующей. При идентификации целей важно отличать цели, ради которых создается ЭС, от задач, которые она должна решать. Примерами возможных целей являются: формализация неформальных знаний экспертов; улучшение качества решений, принимаемых экспертом; автоматизация рутинных аспектов работы эксперта (пользователя); тиражирование знаний эксперта. Этап концептуализации На данном этапе проводится содержательный анализ проблемной области, выявляются используемые понятия и их взаимосвязи, определяются методы решения задач. Этот этап завершается созданием модели предметной области (ПО), включающей основные концепты и отношения. На этапе концептуализации определяются следующие особенности задачи: типы доступных данных; исходные и выводимые данные, подзадачи общей задачи; применяемые стратегии и гипотезы; виды взаимосвязей между объектами ПО, типы используемых отношений (иерархия, причина — следствие, часть — целое и т.п.); процессы, применяемые в ходе решения; состав знаний, используемых при решении задачи; типы ограничений, накладываемых на процессы, которые применены в ходе решения; состав знаний, используемых для обоснования решений. Существует два подхода к процессу построения модели предметной области, которая является целью разработчиков ЭС на этапе концептуализации. Признаковый или атрибутивный подход предполагает наличие полученной от экспертов информации в виде троек объект—атрибут—значение атрибута, а также наличие обучающей информации. Этот подход развивается в рамках направления, получившего название "формирование знаний" или "машинное обучение" (machine learning). Второй подход, называемый структурным (или когнитивным), осуществляется путем выделения элементов предметной области, их взаимосвязей и семантических отношений. Для атрибутивного подхода характерно наличие наиболее полной информации о предметной области: об объектах, их атрибутах и о значениях атрибутов. Кроме того, существенным моментом является использование дополнительной обучающей информации, которая задается группированием объектов в классы по тому или иному содержательному критерию. Тройки объект—атрибут—значение атрибута могут быть получены с помощью так называемого метода реклассификации, который основан на предположении что задача является объектно-ориентированной и объекты задачи хорошо известны эксперту. Идея метода состоит в том, что конструируются правила (комбинации значений атрибутов), позволяющие отличить один объект от другого. Обучающая информация может быть задана на основании прецедентов правильных экспертных заключений, например, с помощью метода извлечения знаний, получившего название "анализ протоколов мыслей вслух". При наличии обучающей информации для формирования модели предметной области на этапе концептуализации можно использовать весь арсенал методов, развиваемых в рамках задачи распознавания образов. Таким образом, несмотря на то, что здесь атрибутивному подходу не уделено много места, он является одним из потребителей всего того, что было указано в лекции, посвященной распознаванию образов и автоматического группирования данных. Структурный подход к построению модели предметной области предполагает выделение следующих когнитивных элементов знаний: 1. Понятия. 2. Взаимосвязи. 3. Метапонятия. 4. Семантические отношения. Выделяемые понятия предметной области должны образовывать систему, под которой понимается совокупность понятий, обладающая следующими свойствами: уникальностью (отсутствием избыточности); полнотой (достаточно полным описанием различных процессов, фактов, явлений и т.д. предметной области); достоверностью (валидностью — соответствием выделенных единиц смысловой информации их реальным наименованиям) и непротиворечивостью (отсутствием омонимии). При построении системы понятий с помощью "метода локального представления" эксперта просят разбить задачу на подзадачи для перечисления целевых состояний и описания общих категорий цели. Далее для каждого разбиения (локального представления) эксперт формулирует информационные факты и дает им четкое наименование (название). Считается, что для успешного решения задачи построения модели предметной области число таких информационных фактов в каждом локальном представлении, которыми человек способен одновременно манипулировать, должно быть примерно равно семи. "Метод вычисления коэффициента использования" основан на следующей гипотезе. Элемент данных (или информационный факт) может являться понятием, если он: используется в большом числе подзадач; используется с большим числом других элементов данных; редко используется совместно с другими элементами данных по сравнению с общим числом его применения во всех подзадачах (это и есть коэффициент использования). Полученные значения могут служить критерием для классификации всех элементов данных и, таким образом, для формирования системы понятий. "Метод формирования перечня понятий" заключается в том, что экспертам (желательно, чтобы их было больше двух) дается задание составить список понятий, относящихся к исследуемой предметной области. Понятия, выделенные всеми экспертами, включаются в систему понятий, остальные подлежат обсуждению. "Ролевой метод" состоит в том, что эксперту дается задание обучить инженера по знаниям решению некоторых задач предметной области. Таким образом, эксперт играет роль учителя, а инженер по знаниям — роль ученика. Процесс обучения записывается на магнитофон. Затем третий участник прослушивает магнитофонную ленту и выписывает на бумаге все понятия, употребленные учителем или учеником. При использовании метода "составления списка элементарных действий" эксперту дается задание составить такой список при решении задачи в произвольном порядке. В методе "составление оглавления учебника" эксперту предлагается представить ситуацию, в которой его попросили написать учебник. Необходимо составить на бумаге перечень предполагаемых глав, разделов, параграфов, пунктов и подпунктов книги. "Текстологический метод" формирования системы понятий заключается в том, что эксперту дается задание выписать из руководств (книг по специальности) некоторые элементы, представляющие собой единицы смысловой информации. Группа методов установления взаимосвязей предполагает установление семантической близости между отдельными понятиями. В основе установления взаимосвязей лежит психологический эффект "свободных ассоциаций", а также фундаментальная категория близости объектов или концептов. Эффект свободных ассоциаций заключается в следующем. Испытуемого просят отвечать на заданное слово первым пришедшим на ум словом. Как правило, реакция большинства испытуемых (если слова не были слишком необычными) оказывается одинаковой. Количество переходов в цепочке может служить мерой "смыслового расстояния" между двумя понятиями. Многочисленные опыты подтверждают гипотезу, что для двух любых слов (понятий) существует ассоциативная цепочка, состоящая не более чем из семи слов. "Метод свободных ассоциаций" основан на психологическом эффекте, описанном выше. Эксперту предъявляется понятие с просьбой назвать как можно быстрее первое пришедшее на ум понятие из сформированной ранее системы понятий. Далее производится анализ полученной информации. В методе "сортировка карточек" исходным материалом служат выписанные на карточки понятия. Применяются два варианта метода. В первом эксперту задаются некоторые глобальные критерии предметной области, которыми он должен руководствоваться при раскладывании карточек на группы. Во втором случае, когда сформулировать глобальные критерии невозможно, эксперту дается задание разложить карточки на группы в соответствии с интуитивным пониманием семантической близости предъявляемых понятий. "Метод обнаружения регулярностей" основан на гипотезе о том, что элементы цепочки понятия, которые человек вспоминает с определенной регулярностью, имеют тесную ассоциативную взаимосвязь. Для эксперимента произвольным образом отбирается 20 понятий. Эксперту предъявляется одно из числа отобранных. Процедура повторяется до 20 раз, причем каждый раз начальные концепты должны быть разными. Затем инженер по знаниям анализирует полученные цепочки с целью нахождения постоянно повторяющихся понятий (регулярностей). Внутри выделенных таким образом группировок устанавливаются ассоциативные взаимосвязи. Кроме рассмотренных выше неформальных методов для установления взаимосвязей между отдельными понятиями применяются также формальные методы. Сюда в первую очередь относятся методы семантического дифференциала и репертуарных решеток. Выделенные понятия предметной области и установленные между ними взаимосвязи служат основанием для дальнейшего построения системы метапонятий — осмысленных в контексте изучаемой предметной области системы группировок понятий. Для определения этих группировок применяют как неформальные, так и формальные методы. Интерпретация, как правило, легче дается эксперту, если группировки получены неформальными методами. В этом случае выделенные классы более понятны эксперту. Причем в некоторых предметных областях совсем не обязательно устанавливать взаимосвязи между понятиями, так как метапонятия, образно говоря, "лежат на поверхности". Последним этапом построения модели предметной области при концептуальном анализе является установление семантических отношений между выделенными понятиями и метапонятиями. Установить семантические отношения — это значит определить специфику взаимосвязи, полученной в результате применения тех или иных методов. Для этого необходимо каждую зафиксированную взаимосвязь осмыслить и отнести ее к тому или иному типу отношений. Существует около 200 базовых отношений, например, "часть — целое", "род — вид", "причина — следствие", пространственные, временные и другие отношения. Для каждой предметной области помимо общих базовых отношений могут существовать и уникальные отношения. "Прямой метод" установления семантических отношений основан на непосредственном осмыслении каждой взаимосвязи. В том случае, когда эксперт затрудняется дать интерпретацию выделенной взаимосвязи, ему предлагается следующая процедура. Формируются тройки: понятие 1 — связь — понятие 2. Рядом с каждой тройкой записывается короткое предложение или фраза, построенное так, чтобы понятие 1 и понятие 2 входили в это предложение. В качестве связок используются только содержательные отношения и не применяются неопределенные связки типа "похож на" или "связан с". Для "косвенного метода" не обязательно иметь взаимосвязи, достаточно лишь наличие системы понятий. Формулируется некоторый критерий, для которого из системы понятий выбирается определенная совокупность концептов. Эта совокупность предъявляется эксперту с просьбой дать вербальное описание сформулированного критерия. Концепты предъявляются эксперту все сразу (желательно на карточках). В случае затруднений эксперта прибегают к разбиению отобранных концептов на группы с помощью более мелких критериев. Исходное количество концептов может быть произвольным, но после разбиения на группы в каждой из таких групп должно быть не более десяти концептов. После того как составлены описания по всем группам, эксперту предлагают объединить эти описания в одно. Следующий шаг в косвенном методе установления семантических отношений — это анализ текста, составленного экспертом. Концепты заменяют цифрами (это может быть исходная нумерация), а связки оставляют. Тем самым строится некоторый граф, вершинами которого служат концепты, а дугами — связки (например, "ввиду", "приводит к", "выражаясь с одной стороны", "обусловливая", "сочетаясь", "определяет", "вплоть до" и т.д.) Этот метод позволяет устанавливать не только базовые отношения, но и отношения, специфические для конкретной предметной области. Рассмотренные выше методы формирования системы понятий и метапонятий, установления взаимосвязей и семантических отношений в разных сочетаниях применяются на этапе концептуализации при построении модели предметной области. Этап формализации Теперь все ключевые понятия и отношения выражаются на некотором формальном языке, который либо выбирается из числа уже существующих, либо создается заново. Другими словами, на данном этапе определяются состав средств и способы представления декларативных и процедурных знаний, осуществляется это представление и в итоге формируется описание решения задачи ЭС на предложенном (инженером по знаниям) формальном языке. Выходом этапа формализации является описание того, как рассматриваемая задача может быть представлена в выбранном или разработанном формализме. Сюда относится указание способов представления знаний (фреймы, сценарии, семантические сети и т.д.) и определение способов манипулирования этими знаниями (логический вывод, аналитическая модель, статистическая модель и др.) и интерпретации знаний. Этап выполнения Цель этого этапа — создание одного или нескольких прототипов ЭС, решающих требуемые задачи. Затем на данном этапе по результатам тестирования и опытной эксплуатации создается конечный продукт, пригодный для промышленного использования. Разработка прототипа состоит в программировании его компонентов или выборе их из известных инструментальных средств и наполнении базы знаний. Главное в создании прототипа заключается в том, чтобы этот прототип обеспечил проверку адекватности идей, методов и способов представления знаний решаемым задачам. Создание первого прототипа должно подтвердить, что выбранные методы решений и способы представления пригодны для успешного решения, по крайней мере, ряда задач из актуальной предметной области, а также продемонстрировать тенденцию к получению высококачественных и эффективных решений для всех задач предметной области по мере увеличения объема знаний. После разработки первого прототипа ЭС-1 круг предлагаемых для решения задач расширяется, и собираются пожелания и замечания, которые должны быть учтены в очередной версии системы ЭС-2. Осуществляется развитие ЭС-1 путем добавления "дружественного" интерфейса, средств для исследования базы знаний и цепочек выводов, генерируемых системой, а также средств для сбора замечаний пользователей и средств хранения библиотеки задач, решенных системой. Выполнение экспериментов с расширенной версией ЭС-1, анализ пожеланий и замечаний служат отправной точкой для создания второго прототипа ЭС-2. Процесс разработки ЭС-2 — итеративный. Он может продолжаться от нескольких месяцев до нескольких лет в зависимости от сложности предметной области, гибкости выбранного представления знаний и степени соответствия управляющего механизма решаемым задачам (возможно, потребуется разработка ЭС-3 и т.д.). При разработке ЭС-2, кроме перечисленных задач, решаются следующие: анализ функционирования системы при значительном расширении базы знаний; исследование возможностей системы в решении более широкого круга задач и принятие мер для обеспечения таких возможностей; анализ мнений пользователей о функционировании ЭС; разработка системы ввода-вывода, осуществляющей анализ или синтез предложений ограниченного естественного языка, позволяющей взаимодействовать с ЭС2 в форме, близкой к форме стандартных учебников для данной области. Если ЭС-2 успешно прошла этап тестирования, то она может классифицироваться как промышленная экспертная система. Этап тестирования В ходе данного этапа производится оценка выбранного способа представления знаний в ЭС в целом. Для этого инженер по знаниям подбирает примеры, обеспечивающие проверку всех возможностей разработанной ЭС. Различают следующие источники неудач в работе системы: тестовые примеры, ввод-вывод, правила вывода, управляющие стратегии. Показательные тестовые примеры являются наиболее очевидной причиной неудачной работы ЭС. В худшем случае тестовые примеры могут оказаться вообще вне предметной области, на которую рассчитана ЭС, однако чаще множество тестовых примеров оказывается слишком однородным и не охватывает всю предметную область. Поэтому при подготовке тестовых примеров следует классифицировать их по подпроблемам предметной области, выделяя стандартные случаи, определяя границы трудных ситуаций и т.п. Ввод-вывод характеризуется данными, приобретенными в ходе диалога с экспертом, и заключениями, предъявленными ЭС в ходе объяснений. Методы приобретения данных могут не давать требуемых результатов, так как, например, задавались неправильные вопросы или собрана не вся необходимая информация. Кроме того, вопросы системы могут быть трудными для понимания, многозначными и не соответствующими знаниям пользователя. Ошибки при вводе могут возникать также из-за неудобного для пользователя входного языка. В ряде приложения для пользователя удобен ввод не только в печатной, но и в графической или звуковой форме. Выходные сообщения (заключения) системы могут оказаться непонятны пользователю (эксперту) по разным причинам. Например, их может быть слишком много или, наоборот, слишком мало. Также причиной ошибок может являться неудачная организация, упорядоченность заключений или неподходящий пользователю уровень абстракций с непонятной ему лексикой. Наиболее распространенный источник ошибок в рассуждениях находится в правилах вывода. Важная причина здесь часто кроется в отсутствии учета взаимозависимости сформированных правил. Другая причина заключается в ошибочности, противоречивости и неполноте используемых правил. Если неверна посылка правила, то это может привести к употреблению правила в неподходящем контексте. Если ошибочно действие правила, то трудно предсказать конечный результат. Правило может быть ошибочно, если при корректности его условия и действия нарушено соответствие между ними. Нередко к ошибкам в работе ЭС приводят применяемые управляющие стратегии. Изменение стратегии бывает необходимо, например, если ЭС анализирует сущности в порядке, отличном от "естественного" для эксперта. Последовательность, в которой данные рассматриваются ЭС, не только влияет на эффективность работы системы, но и может приводить к изменению конечного результата. Так, рассмотрение правила А до правила В способно привести к тому, что правило В всегда будет игнорироваться системой. Изменение стратегии бывает также необходимо и в случае неэффективной работы ЭС. Кроме того, недостатки в управляющих стратегиях могут привести к чрезмерно сложным заключениям и объяснениям ЭС. Критерии оценки ЭС зависят от точки зрения. Например, при тестировании ЭС-1 главным в оценке работы системы является полнота и безошибочность правил вывода. При тестировании промышленной системы превалирует точка зрения инженера по знаниям, которого в первую очередь интересует вопрос оптимизации представления и манипулирования знаниями. И, наконец, при тестировании ЭС после опытной эксплуатации оценка производится с точки зрения пользователя, заинтересованного в удобстве работы и получения практической пользы Этап опытной эксплуатации На этом этапе проверяется пригодность ЭС для конечного пользователя. Пригодность ЭС для пользователя определяется в основном удобством работы с ней и ее полезностью. Под полезностью ЭС понимается ее способность в ходе диалога определять потребности пользователя, выявлять и устранять причины неудач в работе, а также удовлетворять указанные потребности пользователя (решать поставленные задачи). В свою очередь, удобство работы с ЭС подразумевает естественность взаимодействия с ней (общение в привычном, не утомляющем пользователя виде), гибкость ЭС (способность системы настраиваться на различных пользователей, а также учитывать изменения в квалификации одного и того же пользователя) и устойчивость системы к ошибкам (способность не выходить из строя при ошибочных действиях неопытного пользователях). В ходе разработки ЭС почти всегда осуществляется ее модификация. Выделяют следующие виды модификации системы: переформулирование понятий и требований, переконструирование представления знаний в системе и усовершенствование прототипа. Технологическая сеть проектирования, ее формализованное Основные компоненты технологии проектирования ЭИС. описание. Технологическая сеть проектирования Технологическая сеть проектирования — это одно из средств графического представления технологии создания проекта АС (Автоматизированной системы). Реализация всех операций технологической сети позволяет в конечном итоге создать проект системы. В частном случае, когда все операции проектирования показываются наиболее детально, имеет место каноническая технологическая сеть проектирования. Эта сеть построена на элементарных технологических операциях проектирования, однако такая сеть из-за большого количества операций и связей между ними является трудоёмкой, сложной и требует для своей реализации значительные ресурсы. Справедливо утверждение: Применение средств проектирования S позволяет путём композиции (объединения) некоторых фрагментов канонической сети построить укрупнённую сеть на основе обобщённых технологических операций. Получаемая в результате технологическая сеть, оказывается предпочтительнее с точки зрения производительности и эффективности выполнения проектных работ. Пусть дан фрагмент исходной техсети, которая состоит из 2-х техопреаций: W4 V3 W1 Пl : Sl , Rl V1 Пк : Sк , Rк W5 W2 V2 W3 Если перейти к обобщённой технологической операции: V1 W3 Пm : Sm , Rm V2 W4 Если рекурсивно продолжить композицию, то теоретически обосновать создание мощной САПР САУ, на входе которой проект САУ. V3 W5 можно Отчёт об обследовании КП Требование ТЭО поль-— зователя САПР САУ Проект САУ ТЭО Технико-экономическое обследование. Используя каноническую сеть, можно построить сети, ориентированные на определённый категории спецов (Системные аналитики, постановщики задач, программисты, спецы по ТО, проектированию ИО и других), включая руководителей проекта. Детализация определённых фрагментов сети должна производиться исходя из выполняемых спецами функций. Остальные фрагменты могут показываться обобщённо. Такое представление процесса проектирования позволяет каждому проектировщику видеть в комплексе весь процесс проектирования, в определённой степени повысить квалификацию и быть готовым к совмещению выполнения проектных работ. Например, технологическая сеть проектирования для постановщиков задач должна содержать методики, параметры, универсумы, используемые при проектировании постановок задач. Технологическая сеть ориентирована на руководителя проекта. В такой сети представляются операции получения документов техпроекта, рабочей документации, проведения контрольных операций и последовательность выполнения проектных работ, включая внедрение. Определение метода и технологии Метод проектирования ПО представляет собой организованную совокупность процессов создания ряда моделей, которые описывают различные аспекты разрабатываемой системы с использованием четко определенной нотации. На более формальном уровне метод определяется как совокупность составляющих: Концепций и теоретических основ. В качестве таких основ могут выступать структурный или объектно-ориентированный подход. Нотаций, используемых для построения моделей статической структуры и динамики поведения проектируемой системы. В качестве таких нотаций обычно используются графические диаграммы, поскольку они наиболее наглядны и просты в восприятии (диаграммы потоков данных, и диаграммы «сущность – связь» для структурного подхода, диаграммы вариантов использования, диаграммы классов и др. – для объектно-ориентированного подхода. Процедур, определяющих практическое применение метода (последовательность и правила построения моделей, критерии, используемые для оценки результатов). Методы реализуются через конкретные технологии и поддерживающие их методики, стандарты и инструментальные средства, которые обеспечивают выполнение процессов ЖЦ ПО. Технология проектирования определяется как совокупность технологических операций проектирования в их последовательности и взаимосвязи, приводящая к разработке проекта ПО. Требования к технологии Современная технология проектирования должна обеспечивать: 1. Соответствие стандарту ISO/IEC 12207: 1995 (поддержка всех процессов ЖЦ ПО). 2. Гарантированное достижение целей разработки ЭИС в рамках установленного бюджета, с заданным качеством и в установленное время. 3. Возможность декомпозиции проекта на составные части, разрабатываемые группами исполнителей ограниченной численности (3-7 чел.), с последующей интеграцией составных частей. 4. Минимальное время получения работоспособного ПО ЭИС. Речь идет не о сроках готовности всей ЭИС, а о сроках реализации отдельных подсистем. Практика показывает, что даже при наличии полностью завершенного проекта внедрение ЭИС идет последовательно по отдельным подсистемам. 5. Независимость получаемых проектных решений от средств реализации ЭИС (СУБД, ОС, языков и систем программирования). 6. Поддержка комплексом согласованных CASE – средств, обеспечивающих автоматизацию процессов, выполняемых на всех стадиях ЖЦ ПО. Реальное применение любой технологии проектирования ПО ЭИС в конкретной организации и конкретном проекте невозможно без выработки ряда стандартов (правил, соглашений), которые должны соблюдаться всеми участниками проекта. К таким стандартам относятся: 1. Стандарт проектирования. 2. Стандарт оформления проектной документации. 3. Стандарт интерфейса конечного пользователя с системой. Стандарты проектирования, документирования и интерфейса ЭИС. еальное применение любой технологии проектирования ПО ЭИС в конкретной организации и конкретном проекте невозможно без выработки ряда стандартов (правил, соглашений), которые должны соблюдаться всеми участниками проекта. К таким стандартам относятся: 1. Стандарт проектирования. 2. Стандарт оформления проектной документации. 3. Стандарт интерфейса конечного пользователя с системой. Стандарт проектирования должен устанавливать: o Набор необходимых моделей (диаграмм) на каждой стадии проектирования и степень их детализации. o Правила фиксации проектных решений на диаграммах, в том числе правила именования объектов (включая соглашения по терминологии), набор атрибутов для всех объектов и правила их заполнения на каждой стадии, правила оформления диаграмм (включая требования к форме и размерам объектов) и т.д. o Требования к конфигурации рабочих мест разработчиков, включая настройки ОС, настройки CASE – средств и т.д. o Механизм обеспечения совместной работы над проектом, в том числе правила интеграции подсистем проекта, правила поддержания проекта в одинаковом для всех разработчиков состоянии (регламент обмена проектной информацией, механизм фиксации общих объектов и т.д.), правила анализа проектных решений на непротиворечивость и т.д. Стандарт оформления проектной документации. Он должен устанавливать: комплектность, состав и структуру документации на каждой стадии проектирования (в соответствии со стандартом ГОСТ Р ИСО 9127 – 94 «Системы обработки информации. Документация пользователя и информация на упаковке потребительских программных пакетов»); требования к оформлению документации (включая требования к содержанию разделов, подразделов, пунктов, таблиц и т.д.); правила подготовки, рассмотрения, согласования и утверждения документации с указанием предельных сроков на каждой стадии; требования к настройке издательской системы, используемой в качестве встроенного средства подготовки документации; требования к настройке CASE – средств для обеспечения подготовки документации в соответствии с установленными правилами. Стандарт интерфейса конечного пользователя с системой. Он должен регламентировать: Правила оформления экранов (шрифты и цветовая палитра), состав и расположение окон и элементов управления. Правила использования клавиатуры и мыши. Правила оформления текстов помощи. Перечень стандартных сообщений. Правила обработки реакций пользователя. Применение кибернетической схемы и GAP-анализа при проектировании ЭИС. На рисунке 1 приведена схема производственной организации как кибернетической системы, состоящей из управляющей и управляемой подсистем, соединенных между собой каналами передачи информации и образующих вместе единое целое. ^ Систему, в которой реализуются функции управления, обычно называют системой управления и выделяют в ней две подсистемы: управляемую и управляющую. Управляющая подсистема осуществляет функции управления, а управляемая является ее объектом. На информационные входы управляющей подсистемы воздействует информация: маркетинговых исследований, проводящихся регулярно организацией; о наличии на рынке конкурентов; обо всех видах ресурсов (материалы, комплектующие изделия, оборудование, финансы, люди и т. п.); о существующих законах и происходящих в них изменениях; о политической ситуации в определенный момент времени; о состоянии хода процесса производства, поступающая из управляемой подсистемы. ^ Рис. 1. Схема функционирования производственной организации как кибернетической системы Выходами из управляющей подсистемы являются стратегические планы, бизнеспланы, оперативные планы, которые выдаются в соответствии с иерархией управления на уровень цехов, а затем – участков. Это так называемая управляющая информация. Управляемая подсистема соединена с выходами управляющей подсистемы, через которые поступает управляющая информация (прямая связь). На выходах из управляемой подсистемы поступает информация, отражающая внутренние результаты и состояние производственной деятельности – выпуск продукции, ее качество, производительность труда, расход материальных и других видов ресурсов. Эти выходы соединены со входами управляющей подсистемы с помощью обратной связи. Производственная организация как кибернетическая система имеет иерархическую структуру. В каждый вышестоящий комплекс входит несколько нижестоящих звеньев или элементов. Например, в управляющей подсистеме в соответствии с иерархией управления имеются на верхнем уровне (уровень организации) – генеральный директор, руководители служб главных специалистов, заместители генерального директора, аппарат управления; на среднем уровне (уровень цехов) – начальники цехов со своими заместителями; на нижнем уровне (уровень участков) –начальники участков, старшие мастера, бригадиры. В управляемой подсистеме имеются: организация, цехи, участки, линии, рабочие места. Особое значение в системе имеют люди, имеющие высокую степень самоуправления, включенные в сеть общего управления производственной организации. Реинжиниринг бизнес-процессов при внедрении ЭИС. Реинжиниринг бизнес-процессов - это совокупность методов и действий, служащих для перепроектирования процессов в соответствии с изменившимися условиями внешней и внутренней среды и/или целями бизнеса. Существует несколько базовых правил, которых следует придерживаться в процессе проведения реинжиниринга: разработка последовательных пошаговых процедур для перепроектирования процессов; использование в проектировании стандартных языков и нотаций; наличие эвристических и прагматических показателей, позволяющих оценить или измерить степень соответствия перепроектированного процесса или функциональности заданным целям; подход к решению частных задач и к их совокупности должен быть системным; даже небольшое улучшение должно давать быстрый положительный эффект. Реинжиниринг деловых процессов и функций начинается с пересмотра целей предприятия, его структуры, анализа потребностей внутренних пользователей и рынка, производимых продуктов и услуг (рис. 8.7). Перепланирование целей и задач предполагает пересмотр политики предприятия и ответа на следующие вопросы: Какие новые вызовы предъявляют нам изменившиеся условия бизнеса? Что представляет собой предприятие сейчас, и что мы хотим от него в будущем? Каких именно потребителей мы обслуживаем, насколько мы удовлетворяем их требования и ожидания, и что нужно сделать для привлечения новых? Какие именно показатели определяют эффективность деятельности предприятия, производительность труда и качество продукта, является ли это определение полным и адекватным? Какие именно информационные технологии и средства помогут нам в этом? Рис. 8.7. Для ответа на эти ключевые вопросы необходимо в первую очередь провести детальное описание бизнес-архитектуры предприятия, его бизнес-логики, построить функциональную модель взаимодействия бизнес-процессов, ресурсов и персонала и отразить ее в архитектуре ИС, содержании модулей информационных подсистем и визуализации форм представления информации. Необходимо также иметь методики и инструменты реорганизации процессов, решения прикладных задач и управления проектом реинжиниринга (рис. 8.8). Описание бизнес-архитектуры позволяет: построить схему основных потоков данных, работ, движения финансов и документов; понять, как информация распределяется между подразделениями и кто является конечным пользователем в том или ином бизнес-процессе; описать взаимодействие процессов и модулей информационной системы; определить критическую важность видов информации для конкретных уровней управления предприятием; выявить дублированные структуры и связи. Рис. 8.8. Базовая основа улучшения процесса Результатом такого описания является: уточненная карта сети процессов; матрица взаимосвязей процессов и подразделений, вовлеченных в эти процессы; информация о том, какие системы автоматизации существуют, при выполнении каких операций применяются, где и какие данные используются, какие системы автоматизации и информатизации необходимо разработать; функциональные схемы потоков данных (Data Flow), работ (Work Flow), финансовых потоков (Cash Flow), потоков управленческих воздействий (Control Flow) и документооборота (Doc Flow). Функциональная модель поможет составить точные спецификации всех операций, процедур и взаимосвязей между ними. Такая модель, если она построена правильно, обеспечивает исчерпывающее описание функционирующего процесса и всех имеющихся в нем потоков информации. Эта модель описывает состояние "Как есть" (As Is). По результатам анализа возможных путей улучшения от реальной модели нужно перейти к модели, характеризующей улучшения: модель "Как будет" (As To Be), вариант "Как должно быть" (рис. 8.9). Рис. 8.9. Схема реинжиниринга бизнес-процесса Функциональное моделирование является достаточно серьезной проблемой. Его полнота и соответствие построенной модели зависят как от средств моделирования, так и от квалификации специалистов, выполняющих это моделирование. Реинжиниринг бизнес-процессов является сложным и многоаспектным проектом, требующим тщательного планирования и проработки деталей. В таблице 8.1 показаны основные этапы реинжиниринга. Таблица 8.1. Этап Мероприятия Планировани Выявление главных причин проведения реформы на е и начало работ предприятии и оценка последствий отказа от такой реформы Выявление важнейших процессов, требующих реинжиниринга Выявление единомышленников среди руководства и создание рабочей группы из представителей администрации Обеспечение поддержки проекта руководством Подготовка плана проекта: определение объема, обозначение измеримых целей, выбор методологии, составление подробного графика Согласование целей и объемов проекта с руководством Формирование группы реинжиниринга я ние Выбор консультантов или внешних экспертов Проведение вводного совещания Доведение целей проекта до руководителей низшего звена; начальное информирование всей организации Обучение группы реинжиниринга Подготовка плана и начало работ Исследовани Аналитическое исследование опыта компаний с подобными процессами Опрос клиентов и контрольных групп для выявления существующих и будущих требований Опрос служащих и руководителей для выявления вопросов; мозговой штурм Поиск в литературе и прессе данных о тенденциях в отрасли и о чужом опыте Оформление подробных документов на исходные процессы и сбор рабочих данных; выявление недоработок Обзор изменений и вариантов технологий Опрос владельцев и представителей руководства Посещение кружков и семинаров Сбор данных от внешних экспертов и консультантов Проектирова Мозговой штурм и выработка новаторских идей; упражнения по творческому мышлению, чтобы "снять шоры" Проработка сценариев "а что, если?" и применение "шаблонов успеха" других компаний Создание при помощи специалистов 3-5 моделей; разработка комплексных моделей, в которых собрано лучшее от каждой из предыдущих Создание картины идеального процесса Определение моделей нового процесса и их графическое представление Разработка организационной модели в сочетании с новым процессом Определение технологических требований; выбор платформы для новых процессов Выделение краткосрочных и долгосрочных мер Утверждение Анализ затрат и преимуществ; расчет прибыли на капитал Оценка влияния на клиентов и служащих; оценка влияния на конкурентоспособность Подготовка официального документа для высшего руководства Проведение обзорных совещаний для ознакомления и утверждения деталей проекта оргкомитетом и высшим руководством Внедрение Завершение подробной разработки процессов и организационных моделей; определение новых рабочих обязанностей Разработка систем поддержки Реализация предварительных вариантов и первичные испытания Ознакомление работников с новым вариантом; разработка и осуществление плана реформы Разработка поэтапного плана; внедрение как таковое Разработка плана обучения; обучение работников новым процессам и системам Последующи Разработка мероприятий по периодической оценке; е мероприятия определение итогов нового процесса; внедрение программы непрерывного совершенствования нового процесса Предоставление окончательного отчета оргкомитету и администрации Функционально-стоимостной анализ ЭИС. Совокупная стоимость владения ЭИС. Для оценки эффективности существующих бизнес-процессов используются прежде всего методы и средства функционально-стоимостного анализа (ABC - Activity Based Costing), поддерживаемые, например, в ППП Design/IDEF, Easy ABC+, ARIS ABC и др. Так, функционально-стоимостной анализ позволяет выявить: наиболее трудоемкие и затратные функции; функции, не вносящие вклад в образование прибыли; функции с низким коэффициентом использования ресурсов. Для динамической оценки существующих бизнес-процессов при наличии развитой функционирующей информационной системы и информационного хранилища могут использоваться методы анализа реальной статистики. В противном случае применяются методы и средства имитационного моделирования, например, ППП ReThink, РДО, Pilgrim, Ithink, Workflow Analyser, Service Model и др. Совокупная стоимость владения системой и риски Как мы уже говорили, естественным критерием выбора архитектуры и инфраструктуры ИС является минимизация совокупной стоимости владения системой. По крайней мере, такой критерий является естественным для коммерческих организаций, эффективность деятельности которых определяется по затратам и доходам. К сожалению, интегральные затраты на систему могут быть полностью известны только после завершения проекта. В любой момент до завершения проекта интегральные затраты могут быть только оценены. В любой момент проекта дисконтированные интегральные затраты на систему могут быть оценены как (1) где — оценка дисконтированных интегральных затрат проекта в момент ; E— норма дисконтирования4; — дисконтированная сумма фактических интегральных затрат проекта к моменту ; T— период жизненного цикла системы; — оценка интегральных затрат на проект в периоде t; В свою очередь, оценку интегральных затрат на проект в периоде tможно представить как (2) где — плановые затраты на проект в периоде t; — оценка потерь, связанных с бизнес-рисками в периоде t. Далее, плановые затраты на проект определяются следующим образом: (3) где — затраты на приобретение готового программного обеспечения и технических средств в периоде t; — затраты на проектирование системы в периоде t; — затраты на строительно-монтажные работы в периоде t; — затраты на внедрение системы в периоде t; — эксплуатационные затраты в периоде t; — затраты на сопровождение в периоде t; Отметим, что в предложенном методе оценки затрат использована величина — оценка потерь, связанных с бизнес-рисками в периоде t. Конечно, мы будем использовать характеристики и чисто технических, ИТ-рисков. Для того, чтобы знать и правильно организовать описание всего набора возможных рисков, полезно опираться на некую общую модель архитектуры - как предприятия, так и его ИС. В качестве таких моделей могут применяться модели Захмана [3] или Зиндера [4]. По всей видимости, с каждой из ячеек этих моделей связаны свои специфические риски. А связи этих ячеек, предусмотренные неявно в [3] или явно в [4], позволяют, например, хорошо определять связи между техническими, операционными и бизнесрисками, которые будут разбираться далее. Кроме того, наличие временной оси в модели [4] позволяет работать не со статической "фотографией" проекта или жизни системы, но учитывать их существование во времени (имеется ввиду то самое время, которое "работает" в формульных оценках затрат). Кроме того, наличие этой оси времени позволяет вычленять бизнес-риски типа "неопределенность" (см. ниже) при рассмотрении проекта в бизнес-времени и проектным рискам при рассмотрении проекта в проектном времени. Вопросы соответствия различных типов рисков ячейкам архтектурной модели [4] и их связям требуют дополнительной теоретической проработки. Однако и без нее знакомым с вышеуказанными моделями нетрудно будет соотнести определенные ячейки архитектуры (architecturalframework) с различными рисками и таким образом составить, назвать и описать актуальные для проекта/системы группы рисков. Мы же - в рамках данной статьи - выделим несколько наиболее значимых и принципиально различных типов рисков: проектные риски при создании системы; риски бизнес-потерь, связанные с эксплуатацией системы (возникающие, в конечном счете, из-за технических рисков). Такие риски бизнес-потерь назовем бизнесрисками. Каждый бизнес-риск принадлежит по крайней мере одному из вариантов бизнесиспользования системы. Например, для интернет-магазина бизнес-риски “Покупатель не может сделать заказ и уходит” и “Покупатель делает заказ, но уходит рассерженный функционированием системы” принадлежат вариантов бизнес-использования “Сделать заказ”. риски бизнес-потерь, связанные с вариативностью бизнес-процессов. При этом потери происходят оттого, что а) бизнес-процессы надо изменять, а информационная система не готова к этому и потери связаны с неоптимальным функционированием бизнеса и б) оттого, что имеется стоимость модификации системы. Такие риски бизнес– потерь назовем неопределенностями (RUP упоминает аналогичные по смыслу "варианты изменения" (change cases)). технические риски, состоящие в простоях, отказах, потере или искажении данных и т.п.; Затраты на создание и эксплуатацию системы с некоторой точностью оцениваются достаточно прямолинейно. Динамические бизнес-риски количественно учесть невозможно и их следует оценивать исключительно качественно (на уровне понимания, насколько бизнес-процессы в организации являются определенными / застывшими / неустоявшимися). Наиболее интересной частью совокупной стоимости владения системой являются статические бизнес-риски и проектные риски. Каждый вариант бизнес-использования реализуется с помощью набора операций соответствующих бизнес-процессов. Соответственно, бизнес-риск возникает по причине неисполнения одной или нескольких операций бизнес-процесса — это мы называем операционными рисками. Таким образом, операционные риски являются источниками бизнес-рисков. Выбор технологии проектирования экономических информационных систем. Типовое проектирование экономических информационных систем. Технология проектирования ЭИС - это совокупность методологии и средств проектирования ЭИС, а также методов и средств организации проектирования (управление процессом создания и модернизации проекта ЭИС) - рис. 2.1. В основе технологии проектирования лежит технологический процесс, который определяет действия, их последовательность, состав исполнителей, средства и ресурсы, требуемые для выполнения этих действий. Так, технологический процесс проектирования ЭИС в целом делится на совокупность последовательно-параллельных, связанных и соподчиненных цепочек действий, каждое из которых может иметь свой предмет. Действия, которые выполняются при проектировании ЭИС, могут быть определены как неделимые технологические операции или как подпроцессы технологических операций. Все действия могут быть собственно проектировочными, которые формируют или модифицируют результаты проектирования, и оценочными действиями, которые вырабатывают по установленным критериям оценки результатов проектирования. Таким образом, технология проектирования задается регламентированной последовательностью технологических операций, выполняемых в процессе создания проекта на основе того или иного метода, в результате чего стало бы ясно, не только ЧТО должно быть сделано для создания проекта, но и КАК, КОМУ и в КАКОЙ ПОСЛЕДОВАТЕЛЬНОСТИ это должно быть сделано. Предметом любой выбираемой технологии проектирования должно служить отражение взаимосвязанных процессов проектирования на всех стадиях жизненного цикла ЭИС К основным требованиям, предъявляемым к выбираемой технологии проектирования, относятся следующие: созданный с помощью этой технологии проект должен отвечать требованиям заказчика; выбранная технология должна максимально отражать все этапы цикла жизни проекта; выбираемая технология должна обеспечивать минимальные трудовые и стоимостные затраты на проектирование и сопровождение проекта; технология должна быть основой связи между проектированием и сопровождением проекта; технология должна способствовать росту производительности труда проектировщика; технология должна обеспечивать надежность процесса проектирования и эксплуатации проекта; технология должна способствовать простому ведению проектной документации. Основу технологии проектирования ЭИС составляет методология, которая определяет сущность, основные отличительные технологические особенности. Методология проектирования предполагает наличие некоторой концепции, принципов проектирования, реализуемых набором методов проектирования, которые, в свою очередь, должны поддерживаться некоторыми средствами проектирования. Организация проектирования предполагает определение методов взаимодействия проектировщиков между собой и с заказчиком в процессе создания проекта ЭИС, которые могут также поддерживаться набором специфических средств. Методы проектирования ЭИС можно классифицировать по степени использования средств автоматизации, типовых проектных решений, адаптивности к предполагаемым изменениям. Так, по степени автоматизации методы проектирования разделяются на методы: ручного проектирования, при котором проектирование компонентов ЭИС осуществляется без использования специальных инструментальных программных средств, а программирование - на алгоритмических языках; компьютерного проектирования, которое производит генерацию или конфигурацию (настройку) проектных решений на основе использования специальных инструментальных программных средств. По степени использования типовых проектных решений различают следующие методы проектирования: оригинального (индивидуального) проектирования, когда проектные решения разрабатываются «с нуля» в соответствии с требованиями к ЭИС; типового проектирования, предполагающего конфигурацию ЭИС из готовых типовых проектных решений (программных модулей). Оригинальное (индивидуальное) проектирование ЭИС характеризуется тем, что все виды проектных работ ориентированы на создание индивидуальных для каждого объекта проектов, которые в максимальной степени отражают все его особенности. Типовое проектирование выполняется на основе опыта, полученного при разработке индивидуальных проектов. Типовые проекты как обобщение опыта для некоторых групп организационно-экономических систем или видов работ в каждом конкреном случае связаны со множеством специфических особенностей и различаются по степени охвата функций управления, выполняемым работам и разрабатываемой проектной документации. Методы типового проектирования ЭИС предполагают создание системы из готовых покупных типовых элементов (типовых проектных решений). Для этого проектируемая ЭИС должна быть декомпозируема на множество составляющих компонентов (подсистем, комплексов задач, программных модулей и т.д.), для которых подбираются и закупаются имеющиеся на рынке типовые проектные решения. Далее закупленные типовые элементы, как правило, включающие программные продукты, настраиваются на особенности конкретного предприятия или дорабатываются в соответствии с требованиями проблемной области. Под типовым проектным решением (ТПР) будем понимать представленное в виде проектной документации, включая программные модули, проектное решение, пригодное к многократному использованию. В качестве проектного решения может выступать реализация как отдельных компонентов ЭИС (программных модулей, функциональных задач, автоматизированных рабочих мест, локальных баз данных, локальных вычислительных сетей), так и взаимосвязанных комплексов компонентов (функциональных и обеспечивающих подсистем, ЭИС в целом). Типовые проектные решения также называют тиражируемыми продуктами. В зависимости от уровня декомпозиции системы различают элементный, подсистемный и объектный методы типового проектирования (рис. 14.1). При элементном методе типового проектирования ЭИС в качестве типового элемента системы используется типовое решение по задаче или по отдельному виду обеспечения задачи (информационному, программному, техническому, математическому, организационному) (рис. 14.2). Рис. 14.1. Классификация типовых методов проектирования Рис. 14.2. ТПР уровня Задача Сущность применения ТПР при элементном методе заключается в комплектации ЭИС из множества ТПР по отдельным разрозненным задачам. Если данного множества недостаточно для того, чтобы спроектировать систему, необходимые модули дорабатываются вручную. Достоинство элементного метода типового проектирования ЭИС связано с применением модульного подхода к проектированию и документированию ЭИС. К недостаткам применения метода относятся большие затраты времени на сопряжение разнородных элементов вследствие информационной, программной и технической несовместимости ТПР, а также плохая адаптивность (настраиваемость) элементов к особенностям предприятия. Следствием перечисленных недостатков являются большие затраты времени на доработку и комплексирование TПP отдельных элементов, сопоставимые со временем ручного оригинального проектирования ЭИС. В настоящее время элементные ТПР в основном применяются в качестве библиотек методо-ориентированных программ (библиотек классов объектов), например, при разработке графических интерфейсов, применении вычислительных и служебных функций. Типовые проектные решения для функциональных подсистем реализуются в виде пакетов прикладных программ (ППП), которые позволяют осуществлять: модульное проектирование; параметрическую настройку программных компонентов на различные объекты управления; сокращение затрат на проектирование и программирование взаимосвязанных компонентов; хорошее документирование отображаемых процессов обработки информации. В качестве примеров широкораспространенных функциональных ППП можно назвать: 1C Предприятие (автоматизация бухгалтерского учета, расчета заработной платы, складского учета), Фолио - Склад (автоматизация складских операций), Project Expert (бизнес-планирование), ИНЭК (финансовый анализ) и др. При объектном методе типового проектирования ЭИС в качестве типового элемента используется типовой проект для объектов управления определенной отрасли, который включает полный набор функциональных и обеспечивающих подсистем ЭИС. Современные типовые проекты отличаются: открытостью архитектуры, позволяющей устанавливать проекты на разных программно-технических платформах; масштабируемостью, допускающей конфигурацию ЭИС для переменного числа рабочих мест; конфигурируемостью, позволяющей выбирать подмножество компонентов, которые необходимы для конкретной проблемной области и параметрически настраиваются на особенности объекта управления. Несомненное преимущество объектного метода типового проектирования ЭИС перед подсистемным методом заключается в комплексируемости всех компонентов за счет методологического единства и информационной, программной и технической совместимости компонентов. Методика канонического проектирования ЭИС. Каноническое проектирование ЭИС отражает особенности ручной технологии индивидуального (оригинального) проектирования, осуществляемого на уровне исполнителей без использования каких-либо инструментальных средств, позволяющих интегрировать выполнение элементарных операций. Как правило, каноническое проектирование применяется для небольших локальных ЭИС. В основе канонического проектирования лежит каскадная модель жизненного цикла ЭИС. Процесс каскадного проектирования в жизненном цикле ЭИС в соответствии с применяемым в нашей стране ГОСТ 34601-90 «Автоматизированные системы стадий создания» делится на следующие семь стадий: 1. исследование и обоснование создания системы; 2. разработка технического задания; 3. создание эскизного проекта; 4. техническое проектирование; 5. рабочее проектирование; 6. ввод в действие; 7. функционирование, сопровождение, модернизация. В целях изучения взаимосвязанных приемов и методов канонического проектирования ЭИС перечисленные 7 стадий можно сгруппировать в часто используемые на практике четыре стадии процесса разработки ЭИС (рис. 3.1): Рис. 3.1. ТСП стадий и этапов канонического проектирования ЭИС: Д1.1 предметная область; Д1.2 - материалы обследования; Д1.3 - ТЭО, ТЗ на проектирование; Д1.4 - эскизный проект; Д2.1 - техно-рабочий проект (ТРП); Д3.1 - исправленный ТРП, переданный в эксплуатацию; Д3.2 - акт о приемке проекта в промышленную эксплуатацию; Д4.1 - модернизированный ТРП Традиционно этапы исследования предметной области - предприятия, обоснование проекта ЭИС для него и разработки технического задания объединяют термином «Предпроектная стадия» («Предпроектное обследование»), поскольку результаты выполнения работ на данных этапах не являются законченным проектным решением. Основное назначение «Предпроектной стадии» заключается в обосновании экономической целесообразности создания ЭИС и формулировании требований к ней. На первой «Предпроектной стадии» принято выделять два основных этапа: сбор материалов обследования; анализ материалое обследования и разработка техникоэкономического обоснования (ТЭО) и технического задания (ТЗ). В результате выполнения первого этапа проектировщики получают материалы обследования (Д1.2), которые должны содержать полную и достоверную информацию, описывающую изучаемую предметную область - предприятие, в том числе: цель функционирования; организационную структуру системы и объекта управления, т.е. его управленческие отделы, цехи, склады и хозяйственные службы; функции управления, выполняемые в этих подразделениях, протекающие в них технологические процессы обработки управленческой и экономической информации, а также материальные потоки и процессы их обработки, ресурсные ограничения. После выполнения второго этапа проектировщики получают количественные и качественные характеристики информационных потоков, описание их структуры и мест обработки, объемов выполняемых операций и трудоемкости их обработки. На основе этих материалов разрабатываются два документа: «Технико-экономическое обоснование проектных решений» (ТЭО), содержащее расчеты и обоснование необходимости разработки ЭИС для предприятия и выбираемых технологических и проектных решений (Д1.3), и «Техническое задание» (ТЗ), в состав которого входят требования к создаваемой системе и ее отдельным компонентам: программному, техническому и информационному обеспечению и целевая установка на проектирование новой системы (Д1.4). Эти документы являются основными для последующего проектирования ЭИС в соответствии с заданными требованиями. Для сложных ЭИС иногда на этой стадии включают третий этап - разработку «Эскизного проекта». На этапе «Эскизного проекта» сформулированные ранее требования служат основой для разработки предварительных решений по ЭИС в целом и отдельным видам обеспечения. Эти решения прорабатываются на логическом уровне, включая алгоритмы обработки информации, описание информационных потребностей пользователей на уровне названий документов и показателей. Вторая стадия «Технорабочее проектирование» выполняется в два этапа: техническое проектирование и рабочее проектирование. На этапе «Техническое проектирование» выполняются работы по логической разработке и выбору наилучших вариантов проектных решений, в результате чего создается «Технический проект». Этап «Рабочее проектирование» связан с физической реализацией выбранного варианта проекта и получением документации «Рабочего проекта». При наличии опыта проектирования эти этапы иногда объединяются в один, в результате выполнения которого получают «Технорабочий проект» (ТРП) - Д2.1. Третья стадия «Внедрение проекта» включает в себя три этапа: подготовка объекта к внедрению проекта; опытное внедрение проекта и сдача его в промышленную эксплуатацию. На этапе «Подготовка объекта к внедрению проекта» осуществляется комплекс работ по подготовке предприятия к внедрению разработанного проекта ЭИС. На этапе «Опытное внедрение» осуществляют проверку правильности работы некоторых частей проекта и получают исправленную проектную документацию и «Акт о проведении опытного внедрения». На этапе «Сдача проекта в промышленную эксплуатацию» осуществляют комплексную системную проверку всех частей проекта, в результате которой получают доработанный «Техно-рабочий проект» (Д3.1) и «Акт приемки проекта в промышленную эксплуатацию» (Д3.2). Четвертая стадия - «Эксплуатация и сопровождение проекта» включает этапы: эксплуатация проекта; сопровождение и модернизация проекта. На этапе «Эксплуатация проекта» получают информацию о работе всей системы в целом и отдельных ее компонентов и собирают статистику о сбоях системы в виде рекламаций и замечаний, которые накапливаются для выполнения следующего этапа. На этапе «Сопровождение проекта» выполняются два вида работ: ликвидируются последствия сбоев в работе системы и исправляются ошибки, не выявленные при внедрении проекта, а также осуществляется модернизация проекта. В процессе модернизации проект либо дорабатывается, т.е. расширяется по составу подсистем и задач, либо производится перенос системы на другую программную или техническую платформу с целью адаптации ее к изменяющимся внешним и внутренним условиям функционирования, в результате чего получают документы модернизированного «Технорабочего проекта» (Д4.1). Методика индустриального проектирования ЭИС Сочетание различных признаков классификации методов проектирования обусловливает характер используемой технологии проектирования ЭИС, среди которых выделяются два основных класса: каноническая и индустриальная технологии (таблица 2.1). Индустриальная технология проектирования в свою очередь разбивается на два подкласса: автоматизированное (использование CASE-технологий) и типовое (параметрически-ориентированное или модельно-ориентированное) проектирование. Использование индустриальных технологий проектирования не исключает использования в отдельных случаях канонической технологии. Таблица 2.1 Характеристики классов технологий проектирования Класс Степень Степень Степень технологии автоматизаци типизации адаптивности проектирован и ия Каноническое ручное оригинальное реконструкци проектирование проектирован проектирован я ие Индустриальн ое проектирование: е автоматизиро ванное ие Индустриальн ое проектирование: е типовое ие ие компьютерно проектирован ие компьютерно проектирован ие оригинальное реструктуриз проектирован ация модели (генерация ЭИС) сборочное параметризац проектирован ия и реструктуриз ация модели (конфигурация ЭИС) Для конкретных видов технологий проектирования свойственно применение определенных средств разработки ЭИС, которые поддерживают выполнение, как отдельных проектных работ, этапов, так и их совокупностей. Поэтому перед разработчиками ЭИС, как правило, стоит задача выбора средств проектирования, которые по своим характеристикам в наибольшей степени соответствуют требованиям конкретного предприятия. Средства проектирования должны быть: - в своем классе инвариантными к объекту проектирования; - охватывать в совокупности все этапы жизненного цикла ЭИС; - технически, программно и информационно совместимыми; - простыми в освоении и применении; - экономически целесообразными. Автоматизированное проектирование использованием технологий RAD, ERP, CASE. информационных систем с Термин CASE (Computer Aided System/Software Engineering) используется в довольно широком смысле. Первоначальное значение термина CASE, ограниченное вопросами автоматизации разработки только лишь программного обеспечения, в настоящее время приобрело новый смысл, охватывающий процесс разработки сложных ЭИС в целом. С самого начала CASE-технологии развивались с целью преодоления ограничений при использовании структурной методологии проектирования (сложности понимания, высокой трудоемкости и стоимости использования, трудности внесения изменений в проектные спецификации и т.д.) за счет ее автоматизации и интеграции поддерживающих средств. Таким образом, CASE-технологии не могут считаться самостоятельными, они только обеспечивают, как минимум, высокую эффективность их применения, а в некоторых случаях и принципиальную возможность применения соответствующей методологии. Большинство существующих CASE-систем ориентировано на автоматизацию проектирования программного обеспечения и основано на методологиях структурного (в основном) или объектно-ориентированного проектирования и программирования, использующих спецификации в виде диаграмм или текстов для описания системных требований, связей между моделями системы, динамики поведения системы и архитектуры программных средств. В последнее время стали появляться CASE-системы, уделяющие основное внимание проблемам спецификации и моделирования технических средств. CASE-технология в рамках методологии включает в себя методы, с помощью которых на основе графической нотации строятся диаграммы, поддерживаемые инструментальной средой. Методология определяет шаги и этапность реализации проекта, а также правила использования методов, с помощью которых разрабатывается проект. Метод - это процедура или техника генерации описаний компонентов ЭИС (например, проектирование потоков и структур данных). Нотация - отображение структуры системы, элементов данных, этапов обработки с помощью специальных графических символов диаграмм, а также описание проекта системы на формальных и естественных языках. Инструментальные средства CASE - специальные программы, которые поддерживают одну или несколько методологий анализа и проектирования ИС. Рассмотрим архитектуру CASE-средства, которая представлена на рис. 13.1. Рис. 13.1. Архитектура CASE-средства Ядром системы является база данных проекта - репозиторий (словарь данных). Он представляет собой специализированную базу данных, предназначенную для отображения состояния проектируемой ЭИС в каждый момент времени. Объекты всех диаграмм синхронизированы на основе общей информации словаря данных. Репозиторий содержит информацию об объектах проектируемой ЭИС и взаимосвязях между ними, все подсистемы обмениваются данными с ним. В репозитории хранятся описания следующих объектов: проектировщиков и их прав доступа к различным компонентам системы; организационных структур; диаграмм; компонентов диаграмм; связей между диаграммами; структур данных; программных модулей; процедур; библиотеки модулей и т.д. Графические средства моделирования предметной области позволяют разработчикам автоматизированных ИС в наглядном виде изучать существующую информационную систему, перестраивать ее в соответствии с поставленными целями и имеющимися ограничениями. Все модификации диаграмм, выполняемых разработчиками в интерактивном (диалоговом) режиме, вводятся в словарь данных, контролируются с общесистемной точки зрения и могут использоваться для дальнейшей генерации действующих функциональных приложений. В любой момент времени диаграммы могут быть распечатаны для включения в техническую документацию проекта. Графический редактор диаграмм предназначен для отображения в графическом виде в заданной нотации проектируемой ЭИС. Он позволяет выполнять следующие операции: создавать элементы диаграмм и взаимосвязи между ними; задавать описания элементов диаграмм; задавать описания связей между элементами диаграмм; редактировать элементы диаграмм, их взаимосвязи и описания. Верификатор диаграмм служит для контроля правильности построения диаграмм в заданной методологии проектирования ЭИС. Он выполняет следующие функции: мониторинг правильности построения диаграмм; диагностику и выдачу сообщений об ошибках; выделение на диаграмме ошибочных элементов. Документатор проекта позволяет получать информацию о состоянии проекта в виде различных отчетов. Отчеты могут строиться по нескольким признакам, например по времени, автору, элементам диаграмм, диаграмме или проекту в целом. Администратор проекта представляет собой инструменты, необходимые для выполнения следующих административных функций: инициализации проекта; задания начальных параметров проекта; назначения и изменения прав доступа к элементам проекта; мониторинга выполнения проекта. Сервис представляет собой набор системных утилит по обслуживанию репозитория. Данные утилиты выполняют функции архивации данных, восстановления данных и создания нового репозитория. Современные CASE-системы классифицируются по следующим признакам: 1) по поддерживаемым методологиям проектирования: функционально (структурно)-ориентированные, объектно-ориентированные и комплексноориентированные (набор методологий проектирования); 2) по поддерживаемым графическим нотациям построения диаграмм: с фиксированной нотацией, с отдельными нотациями и наиболее распространенными нотациями; 3) по степени интегрированности: tools (отдельные локальные средства), toolkit (набор неинтегрированных средств, охватывающих большинство этапов разработки ЭИС) и workbench (полностью интегрированные средства, связанные общей базой проектных данных - репозиторием); 4) по типу и архитектуре вычислительной техники: ориентированные на компьютеры, ориентированные на локальную вычислительную сеть (ЛВС), ориентированные на глобальную вычислительную сеть (ГВС) и смешанного типа; 5) по режиму коллективной разработки проекта: не поддерживающие коллективную разработку, ориентированные на режим реального времени разработки проекта, ориентированные на режим объединения подпроектов; 6) по типу операционной системы (ОС): работающие под управлением WINDOWS; работающие под управлением UNIX и работающие под управлением различных ОС (WINDOWS, UNIX, OS/2 и др.). В разряд CASE-систем попадают как относительно дешевые системы для персональных компьютеров с ограниченными возможностями (такие, как редакторы диаграмм), так и дорогостоящие системы для больших компьютеров. Современные CASE-системы охватывают обширную область поддержки различных технологий проектирования и программирования: от простых средств анализа и документирования ИС до полномасштабных средств автоматизации, покрывающих весь жизненный цикл ИС. Помимо поддержки начальных этапов разработки важное значение приобретают CASE-системы, ориентированные на проектирование и генерацию баз данных и пользовательских интерфейсов. Генерация интерфейсов с базами данных и возможность преобразования (конвертирования) между различными концептуальными схемами и моделями данных увеличивает мобильность прикладных систем при переходе в другие операционные среды. Генерация кода и (или) таблиц, описывающих интерфейс прикладной системы с базой данных, не только позволяет сократить время разработки, но и дает возможность отделить разработку приложений от ведения архива проектной документации. Наиболее трудоемкими этапами разработки ЭИС являются этапы анализа и проектирования, поэтому CASE-системы, как правило, предназначены для автоматизации отслеживания качества принимаемых проектных решений и подготовки документации. При этом большую роль играют методы визуального представления информации. Это предполагает построение структурных или иных диаграмм в реальном масштабе времени, использование многообразной цветовой палитры, сквозную проверку синтаксических правил. Стратегия выбора CASE-систем для конкретного применения зависит как от целей и потребностей самого проекта, так и от квалификации вовлеченных в процесс проектирования специалистов. В большинстве случаев одно средство не может обеспечить все потребности проекта. Разработчики, как правило, применяют набор средств. Например, одно средство наилучшим образом подходит для анализа, а другое для проектирования систем. В общем случае при выборе CASE-системы необходимо учитывать следующие аспекты. Наличие базы проектных данных, архива или словаря. СУБД и словари данных обеспечивают высокую степень интеграции данных и предоставляют широкие возможности для централизованного сбора, хранения и распределения проектной информации между различными этапами проекта и выполняемыми операциями. Интерфейсы с другими CASE-системами. В процессе проектирования ЭИС могут использоваться различные методологии, поэтому важно, чтобы используемые CASE-системы предоставляли возможности для эффективного использования нескольких методов. При этом должна быть обеспечена терминологическая совместимость различных методологий. Возможности экспорта/импорта. Спецификации, полученные на этапах анализа, проектирования и кодирования для одной ЭИС, могут быть использованы для проектирования другой системы. Повторное проектирование и кодирование могут быть обеспечены при помощи средств экспорта/импорта спецификаций в различные CASEсистемы. Многопользовательский режим. Развитые CASE-системы должны обладать возможностями разделения полномочий персонала разработчиков и объединения отдельных работ в общий проект. Открытая архитектура. Открытая к доступу проектировщиков информация об используемых форматах файлов и интерфейсах должна позволять безболезненно переходить от одной CASE-системы к другой. Расширение новыми методологиями. Как и любое программное средство, CASE-система должна обладать возможностью совершенствоваться с учетом появления новых требований или новых предметных областей. Наличие графических средств поддержки методологий проектирования. Большинство CASE-систем базируется на графическом отображении методологий. Графические элементы структурных диаграмм и объекты словаря должны позволять декомпозировать различные компоненты проекта и детализировать изображения с той степенью, с какой это необходимо для понимания проектных решений. Обеспечение качества проектной документации. Это требование относится к возможностям CASE-системы анализировать и проверять описания и документацию на полноту и непротиворечивость, а также на соответствие принятым в данной методологии стандартам и правилам. В результате анализа должна формироваться информация, указывающая на имеющиеся противоречия или неполноту проектной документации, находящейся в архиве или словаре. Автоматическая генерация отчетов о проектных решениях. Решения (спецификации), созданные в процессе проектирования, служат источником документирования системы. Часто возникает потребность получения твердой копии спецификаций в текстовой или графической форме. Генерация кодов программ. CASE-системы с жесткой ориентацией на конкретные СУБД должны обеспечивать возможность генерации программ в среде этих СУБД. Планирование и управление проектом. Использование CASE-систем не исключает потребности в эффективном управлении проектом. Многие развитые CASEсистемы имеют в своем составе средства планирования и управления проектом. Спецификации, которые используются этими средствами, представляют собой опорные точки управления, позволяющие определять сроки разработки. RAD (от англ. rapid application development — быстрая разработка приложений) — концепция создания средств разработки программных продуктов, уделяющая особое внимание быстроте и удобству программирования, созданию технологического процесса, позволяющего программисту максимально быстро создавать компьютерные программы. Практическое определение: RAD — это жизненный цикл процесса проектирования, созданный для достижения более высокой скорости разработки и качества ПО, чем это возможно при традиционном подходе к проектированию. С конца XX века RAD получила широкое распространение и одобрение. Концепцию RAD также часто связывают с концепцией визуального программирования. Технологию RAD целесообразно применять, когда четко определены некоторые приоритетные направления разработки проекта. Сравнение RAD и Каскадного метода 1. Необходимо выполнение проекта в сжатые сроки. Быстрое выполнение проекта позволяет создать систему, отвечающую требованиям сегодняшнего дня. Если система проектируется долго, то весьма высока вероятность, что за это время существенно изменятся фундаментальные положения, регламентирующие деятельность организации, то есть, система морально устареет ещё до завершения её проектирования. 2. Нечетко определены требования к ПО. В большинстве случаев заказчик весьма приблизительно представляет себе работу будущего программного продукта и не может четко сформулировать все требования к ПО. Требования могут быть вообще не определены к началу проекта либо могут изменяться по ходу его выполнения. 3. Проект выполняется в условиях ограниченности бюджета. Разработка ведется небольшими RAD-группами в короткие сроки, что обеспечивает минимум трудозатрат и позволяет вписаться в бюджетные ограничения. 4. Интерфейс пользователя (GUI) есть главный фактор. Нет смысла заставлять пользователя рисовать картинки. RAD-технология дает возможность продемонстрировать интерфейс в прототипе, причем достаточно скоро после начала проекта. 5. Возможно разбиение проекта на функциональные компоненты. Если предполагаемая система велика, необходимо, чтобы её можно было разбить на мелкие части, каждая из которых обладает четкой функциональностью. Они могут выпускаться последовательно или параллельно (в последнем случае привлекается несколько RADгрупп). 6. Низкая вычислительная сложность ПО. RAD-технология не является универсальной, то есть её применение целесообразно не всегда. Например, в проектах, где требования к программному продукту четко определены и не должны меняться, вовлечение заказчика в процесс разработки не требуется и более эффективной может быть иерархическая разработка (каскадный метод). То же касается проектов, ПО, сложность которых определяется необходимостью реализации сложных алгоритмов, а роль и объём пользовательского интерфейса невелик. Принципы RAD технологии направлены на обеспечение трех основных её преимуществ — высокой скорости разработки, низкой стоимости и высокого качества. Достигнуть высокого качества программного продукта весьма непросто и одна из главных причин возникающих трудностей заключается в том, что разработчик и заказчик видят предмет разработки (ПО) по-разному. Инструментарий должен быть нацелен на минимизацию времени разработки. Создание прототипа для уточнения требований заказчика. Цикличность разработки: каждая новая версия продукта основывается на оценке результата работы предыдущей версии заказчиком. Минимизация времени разработки версии, за счёт переноса уже готовых модулей и добавления функциональности в новую версию. Команда разработчиков должна тесно сотрудничать, каждый участник должен быть готов выполнять несколько обязанностей. Управление проектом должно минимизировать длительность цикла разработки. Принципы RAD применяются не только при реализации, но и распространяются на все этапы жизненного цикла, в частности на этап обследования организации, построения требований, анализ и дизайн и перепихивания. 1. планирование — совокупность требований, полученных при системном планировании и анализе процедуры разработки жизненного цикла (SDLC). На этом этапе пользователи, менеджеры и IT-специалисты обсуждают задачи проекта, его объём, системные требования, а также сложности, которые могут возникнуть при разработке. Фаза завершается согласованием ключевых моментов с RAD-группой и получением от руководителей проекта разрешения на продолжение. Модель быстрой разработки приложений (RAD) 2. Пользовательское проектирование — на протяжении данного этапа пользователи, взаимодействуя с системными аналитиками, разрабатывают модели и прототипы, которые включают в себя все необходимые системные функции. Для перевода пользовательских прототипов в рабочие модели RAD-группа обычно использует технику объединенной разработки приложений (JAD) и CASE-инструменты. Пользовательское проектирование оказывается длительным интерактивным процессом, который позволяет пользователям понять, изменить и в конечном счете выбрать рабочую модель, отвечающую их требованиям. 3. Конструирование — этап, в котором основная задача заключается в разработке программ и приложений. Аналогична стадии «реализация» в SDLC. В RAD, однако, пользователи продолжают принимать участие и по-прежнему могут предлагать изменения или улучшения в виде разработанных ими докладов. В их задачи входит программирование и разработка приложений, написание кода, интеграция модулей и системное тестирование. 4. Переключение — включает в себя операции по конверсии данных, тестирование, переход на новую систему и тренировку пользователей. По своим задачам напоминает финальную стадию SDLC. Сравнивая с традиционными методами разработки ПО, весь процесс оказывается сжатым по времени. Как результат, новая система оказывается быстрее построенной, доставленной до заказчика и установленной на рабочих местах. Технология быстрой разработки приложений (RAD) позволяет обеспечить: быстроту продвижения программного продукта на рынок; интерфейс, устраивающий пользователя; легкую адаптируемость проекта к изменяющимся требованиям; простоту развития функциональности системы. ERP (англ. Enterprise Resource Planning, планирование ресурсов предприятия) — организационная стратегия интеграции производства и операций, управления трудовыми ресурсами, финансового менеджмента и управления активами, ориентированная на непрерывную балансировку и оптимизацию ресурсов предприятия посредством специализированного интегрированного пакета прикладного программного обеспечения, обеспечивающего общую модель данных и процессов для всех сфер деятельности[1][2]. ERP-система — конкретный программный пакет, реализующий стратегию ERP. Концепция ERP сформулирована в 1990 году аналитиком Gartner как видение развития методик MRP II и CIM (англ.), в начале — середине 1990-х годов появилось несколько успешных тиражируемых ERP-систем для крупных организаций, наиболее известные — разработки компаний Baan (нидерл.), Oracle, PeopleSoft, SAP, JD Edwards[3], сформировался рынок услуг по внедрению ERP-систем с участием компаний большой четвёрки, в 2000-е годы произошла консолидация поставщиков, появилось значительное количество ERP-систем для малого и среднего бизнеса, наиболее известными поставщиками которых стали Sage Group и Microsoft[4]. Внедрение ERP-системы считается фактически необходимым условием для публичной компании и, начиная с конца 1990-х годов, ERP-системы, изначально внедрявшиеся только промышленными предприятиями, эксплуатируются большинством крупных организаций вне зависимости от страны, формы собственности, отрасли[ В качестве характеристической особенности ERP-стратегии отмечается принципиальный подход к использованию единой транзакционной системы для подавляющего большинства операций и бизнес-процессов организации, вне зависимости от функциональной и территориальной разобщённости мест их возникновения и прохождения, обязательность сведе́ния всех операций в единую базу для последующей обработки и получения в реальном времени сбалансированных планов[20]. Тиражируемость, то есть возможность применить один и тот же программный пакет для разных организаций (возможно, с разными настройками и расширениями), фигурирует как одно из обязательных условий ERP-системы[21]. Одной из причин повсеместного использования тиражируемых ERP-систем вместо разработки на заказ указывается возможность внедрения лучших практик посредством реинжиниринга бизнес-процессов согласно решениям, применённым в ERP-системе[22]. Однако, встречаются и упоминания интегрированных систем, разработанных для отдельной организации на заказ как ERP-систем[23]. Необходимость всеобъемлющего применения ERP-системы в территориальнораспределённых организациях требует поддержки в единой системе множества валют и языков[24]. Более того, необходимость поддерживать несколько организационных единиц (несколько юридических лиц, несколько предприятий), несколько различных планов счетов, учётных политик, различных схем налогообложения в едином экземпляре системы оказывается необходимым условием для применения в холдингах, транснациональных корпорациях. Применимость в различных отраслях накладывает на ERP-системы, с одной стороны, требования к универсальности, с другой стороны — поддержку расширяемости отраслевой спецификой. Основные крупные системы включают готовые специализированные модули и расширения для различных отраслей (известны специализированные решения в рамках ERP-систем для машиностроительных и обрабатывающих производств, предприятий добывающей промышленности, розничной торговли, дистрибуции, банков, финансовых организаций и страховых компаний, предприятий электросвязи, энергетики, организаций сектора государственного управления, сферы образования, медицины и других отраслей). Адаптация ЭИС с помощью CASE-средств. Обзор нотаций, используемых в CASE-средства Технологическая сеть проектирования ЭИС на основе использования объектноориентированной CASE-технологии Рассмотрим технологическую сеть проектирования ЭИС на основе использования объектно-ориентированной CASE-технологии, для которой характерны последовательное расширение и уточнение моделей на различных стадиях жизненного цикла ЭИС анализа системных требований, логического и физического проектирования, реализации. Технологическая сеть объектно-ориентированного проектирования ЭИС (рис. 13.18) представляет собой обобщение методологий Objectory [89] и Natural Engineering Workbench [110]. Рис. 13.18. Технологическая сеть объектно-ориентированного проектирования ЭИС: Анализ системных требований к ЭИС Технологическая сеть анализа системных требований к ЭИС представлена на рис. 13.19. На входе этапа анализа системных требований используется описание организационно-экономической системы (Ообсл), полученное в ходе работ по анализу и проектированию бизнес-процессов. Эти материалы содержат описание организационной структуры, структуры материальных, финансовых и информационных потоков, которое может быть выполнено либо с помощью традиционных средств графического отображения, либо с помощью определенных методологий бизнес-реинжиниринга, например с помощью той же объектно-ориентированной методологии. Рис. 13.19. Технологическая сеть системного анализа требований: Doбсл - описание организационно-экономической системы; D'пи - диаграмма прецедентов использования ЭИС, D'о - диаграмма классов объектов; D’c - диаграммы состояний объектов, D'пк диаграмма пакетов. Так, в объектно-ориентированной методологии анализа и проектирования бизнеспроцессов предусматриваются [107]: 1. Описание бизнес-процессов как прецедентов использования, актерами которых служат внешние участники бизнес-процессов (клиенты, поставщики, субподрядчики, инвесторы, финансовые компании, государственные органы). 2. Задание порядка разработки и автоматизации бизнес-процессов в соответствии с определенными критериями, например наибольшим эффектом для заказчика, простотой и быстротой разработки и т. д. 3. Неформальное словесное описание бизнес-процессов. Структура основных бизнес-объектов и их взаимодействии описывается в соответствии с требованиями модели классов объектов. Анализ системных требований начинается с идентификации основных прецедентов использования (D'пи) и объектов-сущностей (D'o), которые будут применяться в информационной системе. Работы по идентификации прецедентов использования и классов объектов-сущностей, как правило, выполняются параллельно. В случае объектноориентированного оформления результатов предпроектного обследования данная работа упрощается в силу однозначности соответствия бизнес-процессов и прецедентов использования ЭИС, бизнес-объектов и объектов-сущностей. Разработка D'пи -диаграммы прецедентов использования ЭИС (преобразователь ПИ) предполагает выделение тех последовательностей транзакций, которые будут автоматизировать требуемые бизнес-процессы. При этом определяются основные пользователи-актеры, взаимодействующие с прецедентами использования. Разработка D'o - диаграммы классов объектов (преобразователь П12) предполагает задание состава основных атрибутов и определение характера взаимосвязей классов объектов. Разработка D'с - диаграммы состояний объектов (преобразователь П13) осуществляется только для классов объектов со сложным поведением. При этом рассматриваются все прецеденты использования, в которых объекты данного класса используются и меняют свои состояния. Разработка D'пк - диаграммы пакетов (преобразователь П14) осуществляется путем группировки классов объектов по подсистемам. На этапе анализа системных требований определяется состав пакетов, относящихся к пакету «Проблемная область». При этом выделяются функциональные пакеты, которые объединяют классы объектов, реализующие функции управления, и базовые пакеты с нормативно-справочной информацией, общие для функциональных пакетов. Логическое проектирование ЭИС На этапе логического проектирования ЭИС осуществляются детализация моделей прецедентов использования, классов объектов, состояний, пакетов и разработка моделей взаимодействия объектов и деятельностей, которые определяют характер методов (процедур) обработки объектов (рис. 13.20). Рис. 13.20. Технологическая сеть логического проектирования: Детализация D''пи - диаграммы прецедентов использования (преобразователь П21) предполагает разработку основных и альтернативных потоков событий, которые могут быть представлены самостоятельными диаграммами прецедентов использования. Кроме того, могут быть выделены прецеденты использования, расширяющие набор функций основных прецедентов, или из нескольких прецедентов использования могут быть выделены общие функции в самостоятельные прецеденты. При этом соответственно задаются отношения расширения и использования. Детализация D''о - диаграммы классов объектов (преобразователь П22) выполняется путем уточнения классов объектов-сущностей и введения интерфейсных и управляющих классов объектов. Интерфейсные классы объектов соответствуют актерам прецедентов использования, а управляющие классы объектов - координирующим функциям обработки объектов-сущностей. Уточнение D"с- диаграммы состояний объектов (преобразователь П23) выполняется в связи с детализацией диаграммы прецедентов использования D''пи и диаграммы классов объектов D''o. Разработка D''в - диаграммы взаимодействий (преобразователь П24) выполняется для каждого прецедента использования с учетом построенных диаграмм классов объектов и состояний. В частности, сообщение от одного объекта к другому в диаграмме взаимодействия должно соответствовать событию, вызывающему переход состояния объекта получателя сообщения в диаграмме состояний. Аналогично внешнее событие в диаграмме взаимодействий, вызываемое актером, соответствует событию, осуществляющему переход состояния объекта в диаграмме состояний. Разработка D''д - диаграммы деятельностей (преобразователь П25) уточняет характер взаимодействия объектов не в одном, а в нескольких прецедентах использования. Если диаграммы взаимодействий объектов формируют набор методов обработки объектов, то диаграммы деятельностей дают спецификацию алгоритмов для последующего программирования процедур этих методов. Детализация D''пк-диаграммы пакетов (преобразователь П26) связана с уточнением состава классов объектов-сущностей и появлением интерфейсных и управляющих классов объектов. Например, интерфейсные и управляющие классы объектов могут быть выделены в самостоятельные обеспечивающие пакеты. Физическое проектирование ЭИС На этапе физического проектирования происходит детализация диаграмм классов объектов и пакетов с позиции их реализации в конкретной программно-технической среде (рис. 13.21). Рис. 13.21. Технологическая сеть физического проектирования: D''o, D"'o диаграммы классов объектов, D"с , D"'с - диаграммы состояний объектов; D"пк , D"'пк диаграммы пакетов; D"'к - диаграмма компонентов, D"'р - диаграмма размещения компонентов. Спецификация физической реализации D"'o - диаграммы классов объектов (преобразователь П31) предусматривает определение форматов данных для атрибутов и методов реализации отношений (ключей, указателей, процедур) классов объектов Детализация D"'пк - диаграммы пакетов (преобразователь П32) предполагает разработку обеспечивающих компонентов: базы данных, управления задачами, вспомогательных функций. Разработка D"'к - диаграммы компонентов (преобразователь ПЗЗ) и D"'р диаграммы размещения компонентов (преобразователь П34) реализует клиент-серверную технологию и определяет схему размещения компонентов по узлам вычислительной сети. Реализация ЭИС На этапе реализации ЭИС осуществляются кодогенерация классов объектов, программирование процедур методов классов объектов, наполнение баз данных и размещение компонентов по узлам вычислительной сети (рис. 13.22). Рис. 13.22. Технологическая сеть реализации ЭИС: Uооя, - универсум объектноориентированных языков программирования; D"'o - диаграмма классов объектов; D"'cдиаграммы состояний объектов; D"'пк - диаграмма пакетов; D"в - диаграммы взаимодействий; D"а- диаграмма активностей; D"'к - диаграмма компонентов; D"рдиаграмма размещения компонентов; Gо - классы объектов; Gш - шаблоны процедур методов класса объектов; Gм - процедуры методов. Генерация Go - классов объектов (преобразователь П41) в конкретной объектноориентированной программной среде (C++, Visual Basic, Pascal и т.д.), выбираемой из Uооя - универсума объектно-ориентированных языков программирования, осуществляется на основе диаграммы классов объектов D"'o . Генерация Gш - шаблонов процедур методов класса объектов (преобразователь П42) в конкретной объектно-ориентированной программной среде (C++, Visual Basic, Pascal и т.д.), выбираемой из универсума объектно-ориентированных языков программирования, производится на основе диаграммы взаимодействий объектов D"в. Программирование Gм процедур методов класса объектов (преобразователь П43) с помощью объектно-ориентированного языка программирования выполняется на основе Dш - шаблонов процедур методов классов объектов по спецификациям D"д - диаграмм деятельностей и D"с - состояний объектов. В разряд CASE-средств попадают как относительно дешевые системы для персональных компьютеров с весьма ограниченными возможностями, так и дорогостоящие системы для неоднородных вычислительных платформ и операционных сред. Ниже рассмотрены наиболее распространенные CASE-средства (слайд 7). AllFusion ERwin Data Modeler (ранее ERwin) Назначение Предназначен для проектирования, документирования и сопровождения баз данных, хранилищ данных и витрин данных (data marts). Поддерживает прямое (создание БД на основе модели) и обратное (генерация модели по имеющейся базе данных) проектирование для 20 типов СУБД. Также может использоваться для моделирования структуры информации в предметной области. Компания-производитель: Computer Associates. Веб-сайт: http://www.ca.com. Поддерживаемые методологии, нотации Поддерживает методологию структурного моделирования SADT и следующие нотации: нотацию IDEF1x для ER-диаграмм моделей данных, нотацию IE и специальную нотацию, предназначенную для проектирования хранилищ данных –DIMENSIONAL. Интеграция с другими CASE-средствами и программными продуктами СУБД: Oracle, InterBase, Ingres, Microsoft SQL Server, Clipper, ODBC, DB2, dBASE, Paradox, FoxPro, Rdb, HiRDB, Red Brick Warehouse, Informix, SAS, SQl Anywhere, Microsoft Access, SQL Base, Teradata, Sybase. Средства (среды) разработки: Delphi, PowerBuilder, Visual Basic, Oracle Designer и др. CASE-средства: Rational Rose, AllFusion Process Modeler (см.), Oracle Designer (, импорт-экспорт моделей, см.), AllFusion Model Manager (ранее ModelMart), AllFusion Component Modeler (ранее Paradigm Plus). Веб-сайты, содержащие дополнительную информацию http://www.interface.ru, http://erwin.interface.ru. AllFusion Process Modeler (ранее BPWin) Назначение Предназначен для визуального моделирования бизнес-процессов. Компания-производитель: Computer Associates. Веб-сайт: http://www.ca.com. Поддерживаемые методологии, нотации Поддерживает три нотации –IDEF0 (функциональное моделирование), DFD (Data Flow Diagram –моделирование потоков данных), IDEF3 (моделирование потоков работ, технологических процессов). В IDEF3 поддерживаются два взгляда на процесс: с точки зрения технологии обработки объектов и с точки зрения обрабатываемого объекта. Интеграция с другими CASE-средствами и программными продуктами Интегрирован с ERwin (см.), Paradigm Plus (моделирование компонентов программного обеспечения), Arena Software (имитационное моделирование). Веб-сайты, содержащие дополнительную информацию http://www.interface.ru, http://bpwin.interface.ru. Rational Rose (Rational Software) Назначение Предназначен для автоматизации этапов анализа и проектирования систем, а также для генерации программного кода на различных объектно- ориентированных языках программирования высокого уровня, а также для автоматизации выпуска проектной документации. В основе работы Rational Rose лежит построение различного рода диаграмм и спецификаций (на основе объектно-ориентированных технологий), определяющих логическую и физическую структуры модели, ее статические и динамические аспекты. В их число входят диаграммы классов, состояний, сценариев, модулей, процессов, спецификации классов, объектов, атрибутов и операций, заготовки текстов программ, модель разрабатываемой программной системы. Компанияпроизводитель: Rational Software Corporation, веб-сайт: http://www.rational.com. Поддерживаемые методологии, нотации Подмножество UML (Unified Modeling Language) в реализации компанией Rational Software Corporation. Интеграция с другими CASEсредствами и программными продуктами Rational Rose интегрируется со средством PVCS [расшифровка] для организации групповой работы и управления проектом и со средством SoDA [Software Documentation Automation] –для документирования проектов. SoDA (Software Documentation Automation), оригинальная разработка компании Rational, существенно упрощает и удешевляет процесс создания проектной документации и поддержания актуальности последней. SoDA будет особенно полезна при реализации крупных информационных проектов, в которых на составление документации и ее постоянную переработку часто тратится очень много времени и сил разработчиков. По задаваемым пользователем шаблонам SoDA "компилирует" документацию, собирая в один документ текстовые и графические данные из различных источников, например из моделей, созданных в Rational Rose. Потом пользователь может отредактировать этот документ с помощью Microsoft Word или Adobe FrameMaker+SGML. Веб-сайты, содержащие дополнительную информацию Microsoft Visio (Microsoft) Назначение Универсальное средство деловой графики, позволяющее оформлять структурные модели в виде схем и диаграмм в широком спектре нотаций. Поддерживает множество современных нотаций структурных моделей. В частности: диаграммы потоков данных (DFD), диаграммы «сущность-связь», диаграммы UML, блок-схемы алгоритмов, топологии ЛВС, абстрактные блок-схемы, сети Петри и т.п. Компания-производитель: Microsoft, веб-сайт: http://www.microsoft.com. Поддерживаемые методологии, нотации Поддерживает широкий спектр методологий и нотаций. Интеграция с другими CASEсредствами и программными продуктами Автоматическое создание диаграмм баз данных из баз данных Microsoft SQL Server и Microsoft Access, создание диаграмм программного обеспечения на языке UML из проектов Microsoft Visual Studio «.NET», создание веб-схем существующих веб-узлов, шкал времени из Microsoft Excel или Microsoft Project, календарей из Microsoft Outlook и организационных диаграмм из Microsoft Excel или Microsoft Exchange Server. Данные диаграмм Visio можно извлекать в формате XML и других форматах, экспортировать в файлы Microsoft Excel, Microsoft Word, Microsoft SQL Server и другие типы файлов для интеграции с бизнес-процессами и системами. Вебсайты, содержащие дополнительную информацию IDEF/Design Назначение Автоматизирует все этапы проектирования сложных систем различного назначения: формулировку требований и целей проектирования, разработку спецификаций, определение компонентов и взаимодействий между ними, документирование проекта, проверку его полноты и непротиворечивости. Компания-производитель: Meta Software Corp., веб-сайт: http://www.metasoftware.com. Поддерживаемые методологии, нотации Поддерживает методологии описания и моделирования системных функций (IDEF0/SADT), структур и потоков данных в системе (IDEF1, IDEF1x, ER-диаграммы) и поведения системы (IDEF/CPN –Colored Petri Network). Интеграция с другими CASEсредствами и программными продуктами Интеграция с Design/CPN (система динамического моделирования на базе сетей Петри), пакетом динамического анализа сложных систем WorkFlow Analyzer, пакетом функционально-стоимостного анализа EasyABC. Веб-сайты, содержащие дополнительную информацию System Architect Назначение Автоматизирует процесс разработки, поддержки и управления различными типами диаграмм: диаграммы потоков данных (DFD), сущность-связь (ER), структурные диаграммы, диаграммы состояний передачи, потоковые диаграммы и др. Компанияпроизводитель: Popkin Software & Systems Incorporated, веб-сайт: http://www.popkin.com. Поддерживаемые методологии, нотации Объектно-ориентированные методы: OMT (Rumbaugh), Booch ’, ’, Coad/Yourdon. Структурные нотации: реального времени УордаМеллора (Ward & Mellor), SSADM IV, IDEF0, IDEF1X, Йордона-ДеМарко (Yourdon/DeMarco), Гейна-Сарсона (Gane-Sarson), ER-диаграммы. Интеграция с другими CASE-средствами и программными продуктами Поддерживает СУБД большинства ведущих производителей: Oracle, Sybase, DB2, SQL Server, Informix, Sybase, Access, dBASE, Paradox и др. Веб-сайты, содержащие дополнительную информацию Silverrun Назначение Моделирование функционирования обследуемой организации или разрабатываемой ИС, построение моделей данных "сущность-связь" (как абстрактных, так и в привязке к конкретной реляционной СУБД). Компания-производитель Computer Systems Advisers Inc., веб-сайт: www.csawebs.com Поддерживаемые методологии, нотации Диаграммы потоков данных (DFD) в нотациях: Йордона-ДеМарко (Yourdon/DeMarco), Гейна-Сарсона (Gane-Sarson), Уорда-Меллора (Ward & Mellor) и др. Интеграция с другими CASE-средствами и программными продуктами СУБД: Oracle, Informix, DB2, Ingres, Progress, SQL Server, SQLBase, Sybase. Для передачи данных в средства разработки приложений имеются мосты к языкам 4GL: JAM, PowerBuilder, SQL Windows, Uniface, NewEra, Delphi. Веб-сайты, содержащие дополнительную информацию http://www.silverrun.com Встроенные CASE-средства СУБД Microsoft SQL Server Назначение Предназначен для разработки, моделирования, создания, модификации и генерации баз данных. Позволяет разрабатывать базы данных, работая с графическим представлением таблиц, колонок и взаимосвязей между ними Поддерживаемые методологии, нотации Поддерживает методологию IDEF1x. Интеграция с другими CASEсредствами и программными продуктами Нет. Веб-сайты, содержащие дополнительную информацию http://www.microsoft.com Встроенные CASE-средства СУБД Oracle (Oracle Designer) Назначение Позволяет моделировать бизнес-процессы, создавать диаграммы потоков данных и функциональные модели. Компания-производитель: Oracle, веб-сайт: http://www.oracle.com. Поддерживаемые методологии, нотации Диаграммы потоков данных (DFD) в нотации Йордона-ДеМарко (Yourdon/DeMarco), диаграммы "сущностьсвязь" в нотации Баркера (Barker). Интеграция с другими CASE-средствами и программными продуктами Интегрируется с СУБД: Oracle RDB, DB2, Microsoft SQL Server, Sybase, другими через ODBC. Веб-сайты, содержащие дополнительную информацию В настоящее время для объектно-ориентированного моделирования проблемной области широко используется унифицированный язык моделирования UML (Unified Modeling Language), который разработан группой ведущих компьютерных фирм мира OMG (Object Management Group) [89] и фактически является стандартом по объектноориентированным технологиям. Язык UML реализован многими фирмами производителями программного обеспечения в рамках CASE-технологий, например Rational Rose (Rational), Natural Engineering Workbench (Software AG), ARIS Toolset (IDS prof. Scheer) и др. Система объектно-ориентированных моделей в соответствии с нотациями UML включает в себя следующие диаграммы: 1) диаграмму прецедентов использования (Use-case diagram), которая отображает функциональность ЭИС в виде совокупности выполняющихся последовательностей транзакций; 2) диаграмму классов объектов (Class diagram), которая отображает структуру совокупности взаимосвязанных классов объектов аналогично ER-диаграмме функционально-ориентированного подхода; 3) диаграммы состояний (Statechart diagram), каждая из которых отображает динамику состояний объектов одного класса и связанных с ними событий; 4) диаграммы взаимодействия объектов (Interaction diagram), каждая из которых отображает динамическое взаимодействие объектов в рамках одного прецедента использования; 5) диаграммы деятельностей (Activity diagram), которые отображают потоки работ во взаимосвязанных прецедентах использования (могут декомпозироваться на более детальные диаграммы); 6) диаграммы пакетов (Package diagram), которые отображают распределение объектов по функциональным или обеспечивающим подсистемам (могут декомпозироваться на более детальные диаграммы); 7) диаграмму компонентов (Component diagram), которая отображает физические модули программного кода; 8) диаграмму размещения (Deployment diagram), которая отображает распределение объектов по узлам вычислительной сети.
