Архитектура КИС Тема 3 1 Введение Современные

Архитектура КИС Тема 3 1

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

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

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

Примечание Первоначально КИС базировались на классической двухуровневой клиент-серверной архитектуре Данная клиент-серверная архитектура характеризуется наличием двух взаимодействующих самостоятельных модулей автоматизированного рабочего места (АРМа) и сервера базы данных, в качестве которого может выступать Microsoft SQL Server, Oracle, Sybase и другие. Сервер БД отвечает за хранение, управление и целостность данных, а также обеспечивает возможность одновременного доступа нескольких пользователей. Клиентская часть представлена так называемым “толстым” клиентом, то есть приложением (АРМ) на котором сконцентрированы основные правила работы системы и расположен пользовательский интерфейс программы. При всей простоте построения такой архитектуры, она обладает множеством недостатков, наиболее существенные из которых - это высокие требования к сетевым ресурсам и пропускной способности сети компании, а также сложность обновления программного обеспечения из-за “размазанной” бизнес-логики между АРМом и сервером БД. Кроме того, при большом количестве АРМов возрастают требования к аппаратному обеспечению сервера БД, а это, как известно, самый дорогостоящий узел в любой информационной системе. 5

Современная трехуровневая архитектура Современная клиент-серверная архитектура включает три уровня представления: − Уровень представления данных пользователем; − Уровень обработки данных приложением; − Уровень взаимодействия с базой данных Она позволяет помещать прикладные программы на отдельные серверы приложений , с которыми через APIинтерфейс (Application Program Interface) устанавливается связь клиентских рабочих станций. Работа клиентской части приложения сводится к вызову необходимых функций сервера приложения, которые называются «сервисами» . Прикладные программы в свою очередь обращаются к серверу базы данных с помощью SQL запросов. 6

Современная трехуровневая архитектура 7

Трехуровневая клиент – серверная архитектура Такая организация позволяет более повысить производительность и эффективность КИС за счет: − многократности повторного использования общих функций обработки данных в множестве клиентских приложений при существенной экономии системных ресурсов; − параллельности в работе сервера приложений и сервера базы данных, причем сервер приложений может быть менее мощным по сравнению с сервером базы данных; − оптимизации доступа к базе данных через сервер приложений из клиентских мест путем диспетчеризации выполнения запросов в вычислительной сети; - повышения скорости и надежности обработки данных в результате дублирования программного обеспечения на нескольких серверах приложений, которые могут заменять друга в сети в случае перегрузки или выхода из строя одного из них; − переноса функций администрирования системы по проверке полномочий доступа пользователей с сервера базы данных на сервер приложений 8

Вызовы процедур в архитектуре Клиент-Сервер Основой производительности систем, основанных на архитектуре "клиентсервер" является опора на программные пакеты, реализующие протоколы удаленного вызова процедур (RPC - Remote Procedure Call) и протоколы внешнего представления данных XDR (External Data Representation. При использовании таких средств обращение к сервису в удаленном узле выглядит как обычный вызов процедуры. Средства RPC, в которых, естественно, содержится вся информация о специфике аппаратуры локальной сети и сетевых протоколов, переводит вызов в последовательность сетевых взаимодействий. XDR Этот протокол определяет стандартный способ представления данных, скрывающий такие машинно-зависимые свойства как порядок байтов в слове, требования к выравниванию начального адреса структуры, представление стандартных типов данных и т. д. Тем самым, специфика сетевой среды и протоколов скрыта от прикладного программиста. При вызове удаленной процедуры программы RPC и XDR производят преобразование форматов данных клиента в промежуточные машинно-независимые форматы и затем преобразование в форматы данных сервера. При передаче ответных параметров производятся аналогичные преобразования. По существу протоколы представляет собой технологическую основу архитектуры "клиент-сервер" 9

Механизм RPC Независимость от конкретного машинного представления данных обеспечивается отдельно специфицированным протоколом XDR (External Data Representation - внешнее представление данных). Этот протокол определяет стандартный способ представления данных, скрывающий такие машинно-зависимые свойства как порядок байтов в слове, требования к выравниванию начального адреса структуры, представление стандартных типов данных и т. д. 10

Архитектуры КИС и Intеrnet-приложения 11

Возникновение и внедрение в широкую практику высокоуровневых служб Всемирной Сети Сетей Internet (e-mail, ftp, telnet, Gopher, WWW и т. д. ) естественным образом повлияли на технологию создания корпоративных информационных систем, породив направление, известное теперь под названием Intranet. По сути дела, информационная Intranet-система это корпоративная система, в которой используются методы и средства Internet. Такая система может быть локальной, изолированной от остального мира Internet, или опираться на виртуальную корпоративную подсеть Internet. 12

Хотя в общем случае в Intranet-системе могут использоваться все возможные службы Internet, наибольшее внимание привлекает гипермедийная служба WWW (World Wide Web Всемирная Паутина). Для этого имеются две основные причины. Во-первых, с использованием языка гипермедийной разметки документов HTML можно сравнительно просто разработать удобную для использования информационную структуру, которая в дальнейшем будет обслуживаться одним из готовых Web-серверов. Во-вторых, наличие нескольких готовых к использованию клиентских частей - браузеров, или "обходчиков" избавляет от необходимости создавать собственные интерфейсы с пользователями, предоставляя им удобные и развитые механизмы доступа к информации. В ряде случаев такая организация корпоративной информационной системы оказывается достаточной для удовлетворения потребностей компании. 13

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

Особенности логики приложения, применении Web-технологии существует возможность ее реализации на стороне Webсервера. Для этого используются два подхода - CGI (Common Gateway Interface) и API (Application Programming Interface). Оба подхода основываются на наличии в языке HTML специальных конструкций, информирующих клиента-браузера, что ему следует послать Web-серверу специальное сообщение, при получении которого сервер должен вызвать соответствующую внешнюю процедуру, получить ее результаты и вернуть их клиенту в стандартном формате HTTP 15

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

Доступ к базе данных в Intranetсистеме 17

Особенности архитектур КИАС 18

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

Особенности современного информационного обмена Современный информационный обмен характеризуется: Объемами получаемой информации. (ЛПР должно анализировать десятки и сотни мегабайт информации, а в крупных корпоративных и общегосударственных системах объемы достигают десятков терабайт 1012) , для примера объем книги 300 стр. примерно равен 5 мегабайт 106 байт. Качественными характеристиками: -многоплановостью; -сложностью отображаемых объектов и систем, а также связей между объектами, явлениями и процессами; -скрытостью явных закономерностей. 20

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

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

Архитектура ИАС 23

Сбор и хранение информации оформился в концепцию информационных хранилищ. Эта концепция состоит в том, что сведения о деятельности предприятия или иного объекта хозяйственной или иной деятельности накапливаются в течение длительного периода времени (годы) в информационном хранилище по определенным правилам. Хранилище данных (Data warehouse) — очень большая предметно-ориентированная информационная корпоративная база данных, специально разработанная и предназначенная для подготовки отчётов, анализа бизнес-процессов с целью поддержки принятия решений в организации. Строится на базе клиент-серверной архитектуры, реляционной СУБД и утилит поддержки принятия решений DW- используются в различных временных режимах для анализа, как источник данных для разного рода отчетности и работы с партнерами и для обоснования управленческих решений. 24

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

Анализ информации Два направления: – оперативный анализ данных (информации), широко распространена аббревиатура англоязычного названия – On. Line Analytical Processing – OLAP. Основной задачей оперативного или OLAP-анализа является быстрое (в пределах секунд) извлечение необходимой аналитику или ЛПР для обоснования или принятия решения информации. Интеллектуальный анализ информации – имеет также широко распространенное в русской специальной литературе англоязычное название Data mining. Предназначен для фундаментального исследования проблем в той или иной предметной области. Требования по времени менее жестки, но используются более сложные методики. При решении сложных задач в режиме Data mining приходится использовать весьма мощные специальные программные средства (With. Why, Statistica и др) 26

Структура интегрированной ИАС Системы * репортинга. ОLAP системы Data Mining системы витрины данных хранилище данных Сбор, очистка и согласование информации из внешних источников OLTP системы 27

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

Реинжиниринг бизнес процессов и КИС Тема 5 29

Определения Международная организация Wf. MC (Workflow Management Coalition) -, занимающейся стандартами систем и процессов (workflow ) определяет : Бизнес-процесс – это одна или более связанных между собой процедур или операций (функций), которые совместно реализуют некую бизнес-задачу или политическую цель предприятия, как правило, в рамках его организационной структуры. Поток работ - это упорядоченное во времени множество рабочих заданий, которые получают сотрудники и которые обрабатываются ими вручную или с помощью средств механизации/автоматизации, но с той последовательностью и в рамках тех правил, которые определены для данного бизнес-процесса 30

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

Авторитет в области разработки систем workflow Т. Кулопулос трактует взаимосвязь между бизнеспроцессом и workflow следующим образом: «Можно провести следующую аналогию: бизнес-процесс – это своего рода конвейер, работающий по своим правилам и технологиям, а поток заданий аналогичен потоку изделий (узлов, деталей), которые передвигает этот конвейер. Бизнес-процесс, по сути дела, объединяет поток работ и функции, которые должны выполняться над элементами (заданиями) этого потока, людей и оборудование, которые реализуют эти функции, а также правила, управляющие последовательностью выполнения этих функций. » 32

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

Менеджмент бизнеспроцессов зародился в рамках концепций всеобщего управления качеством (TQM – Total Quality Management) и непрерывного улучшения процессов (CPI – Continuous Process Improvement) , согласно которым предполагается сквозное управление бизнес-процессом, как единым целым, который выполняется взаимосвязанными подразделениями предприятия (компании), например, от момента поступления заказа клиента до момента его реализации. Управление бизнес-процессами целесообразно рассматривать и на уровне взаимодействия различных предприятий, когда требуется координация деятельности предприятий-партнеров в потоках товародвижения или в логистических процессах. Логистика породила методы организации поставок по принципу «Точно в срок» (JIT – just in time), реализация которых немыслима без управления бизнес-процессами как единым целым. Революцию в управление бизнес-процессами внесли достижения в области современных информационных технологий, которые дают возможность проведения инжиниринга (проектирование не существующего БП) и реинжиниринга (перепроектирование существующего БП) бизнес процессов. 34

Понятие «реинжиниринг бизнеса» 35

Корни РБП Инжиниринг бизнеса — это набор приемов и методов, которые компания использует для проектирования бизнеса в соответствии со своими целями. Реинжиниринг бизнес-процессов берет свое начало, как это общепризнанно, в двух статьях, написанных в 1990 году Хаммером (Hammer) и Давенпортом и Шортом (Davenport and Short). М. Хаммер и Дж. Чампи определяют реинжиниринг как «фундаментальное переосмысление и радикальное перепроектирование бизнеспроцессов организации для достижения коренных улучшений в актуальных основных показателях их деятельности: стоимость, качество, услуги и темпы» . Имеется в виду не небольшое усовершенствование бизнес-процессов организаций, а кардинальное повышение их эффективности – в десятки и даже сотни раз. При этом реинжиниринг рассматривается как необходимое условие выживания современных организаций в условиях жесткой конкурентной борьбы на мировом рынке. 36

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

Замечание В приведенном определении понятия «реинжиниринг» присутствует требование радикальности преобразований бизнес-процессов. Однако с того момента, как это определение было сформулировано М. Хаммером и Дж. Чампи, в методологии реинжиниринга и посвященных этой теме работам требование радикальности стало смягчаться. Действительно, во многих случаях трудно четко определить, какие преобразования являются радикальными, а какие – нет. Кроме того, сложность проведения реинжиниринга зачастую приводит к длительным срокам его проведения, а в этих условиях понятие радикальности частично утрачивается. В связи с этим в литературе и на практике начали употребляться термины «революционный реинжиниринг» и «эволюционный реинжиниринг» . Здесь мы сосредоточимся на методологии реинжиниринга, рассматривая ее во многом безотносительно к степени глубины и скорости проведения соответствующих мероприятий. 38

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

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

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

Типовая схема 42

Методики моделирования бизнес процессов IDEF 43

Понятие моделирование БП Важнейшим инструментом для проведения Реинжиниринга БП является моделирование. Модель— некоторый материальный или мысленно представляемый объект или явление, являющийся упрощённой версией моделируемого объекта или явления (прототипа) и в достаточной степени повторяющий свойства, существенные для целей конкретного моделирования (опуская несущественные свойства, в которых он может отличаться от прототипа). . Для проведения анализа состояния предприятия необходимо иметь модель двух видов: Модель «как есть (as is)» , представляющая собой описание реальное положение дел на предприятии (структура, протекающие бизнеспроцессы, используемые технологии и т. д. ). Такая модель позволяет понять как функционирует предприятие и какие процессы в нем протекают, а также выявить ошибки и узкие места бизнс – процессов и сформулировать предложения по их реинжинирингу Модель «как должно быть (as to be)» интегрирующая предложения руководства, сотрудников предприятия, экспертов и системных аналитиков и позволяющая сформулировать видение новых бизнес- процессов, оценить их эффективность и целесообразность реализации. 44

Два направления моделирования Бизнес Процессов Функциональное моделирование , использование методик IDEF , инструментарий All. Fusion Process Modeler (BPWin) Объектное моделирование использование методик UML, инструментарий Rational Rose , ARIS , Natural Engineering Workbench 45

МЕТОДОЛОГИЯ ФУНКЦИОНАЛЬНОГО МОДЕЛИРОВАНИЯ БИЗНЕС ПРОЦЕССОВ 46

Методики проектирования IDEF В 90 х гг. в США разработана совокупность методик, по программе компьютеризации промышленности ICAM (Integrated Computer-Aided Manufacturing), получила название IDEF (аббревиатура от Icam DEFinition или Integrated Definition). Некоторые из этих методик получили статус государственного стандарта США. IDEF-технологии находят успешное применение в самых различных областях бизнеса, показав себя эффективным средством анализа, конструирования и отображения бизнес-процессов. 47

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

Методики IDEF 49

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

Методика IDEF 0 предназначена для функционального моделирования, т. е. моделирования выполнения функций объекта, путём создания описательной графической модели, показывающей что, как и кем делается в рамках функционирования предприятия. Используется для построения двух видов моделей: Как есть (As Is); Как должно быть(As to Be) 51

Модель As Is При обследовании предприятия строится функциональная модель КАК ЕСТЬ, которая позволяет чётко зафиксировать, какие деловые процессы осуществляются на предприятии, какие информационные объекты используются при выполнении деловых процессов и отдельных операции Функциональная модель КАК ЕСТЬ является отправной точкой для анализа потребностей предприятия, выявления проблем и "узких" мест и разработки проекта совершенствования деловых процессов. 52

Модель As to Be Функциональная модель КАК БУДЕТ позволяет уже на стадии проектирования будущей Корпоративной информационной системы определить эти изменения. Применение функциональной модели КАК БУДЕТ позволяет не только сократить сроки внедрения КИС , но также снизить риски, связанные с невосприимчивостью персонала к информационным технологиям. 53

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

Методика IDEF 3 является методикой описания бизнес-процессов как упорядоченной последовательности событий с одновременным описанием объектов, имеющих отношение к процессу. Эта методика является средством документирования процессов, происходящих на предприятии, и предоставляет инструментарий для наглядного исследования и моделирования сценариев поведения. Позволяет: Определять и анализировать точки влияния потоков сопутствующего документооборота на сценарий технологических процессов. Определять ситуации, в которых требуется принятие решения, влияющего на жизненный цикл процесса, например изменение конструктивных, технологических или эксплуатационных свойств конечного продукта. Содействовать принятию оптимальных решений при реорганизации технологических процессов. Разрабатывать имитационные модели технологических процессов, по принципу "КАК БУДЕТ, ЕСЛИ. . . " 55

IDEF 4 — Object-Oriented Design — методология построения объектно-ориентированных систем, позволяют отображать структуру объектов и заложенные принципы их взаимодействия, тем самым позволяя анализировать и оптимизировать сложные объектно-ориентированные системы; Связана с использованием специальных графических средств и программного обеспечения для преобразования диаграмм в объектные программные модули 56

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

IDEF 6 Design Rationale Capture - Обоснование проектных действий, состоит в облегчении получения "знаний о способе" моделирования, их представления и использования при разработке систем управления предприятиями. Под "знаниями о способе" понимаются причины, обстоятельства, скрытые мотивы, которые обуславливают выбранные методы моделирования. Проще говоря, "знания о способе" интерпретируются как ответ на вопрос: "почему модель получилась такой, какой получилась? " Большинство методов моделирования фокусируются на собственно получаемых моделях, а не на процессе их создания. Метод IDEF 6 акцентирует внимание именно на процессе создания модели; 58

IDEF 8 User Interface Modeling - Метод разработки интерфейсов взаимодействия оператора и системы (пользовательских интерфейсов). Современные среды разработки пользовательских интерфейсов в большей степени создают внешний вид интерфейса. IDFE 8 фокусирует внимание разработчиков интерфейса на программировании желаемого взаимного поведения интефеса и пользователя на трех уровнях: выполняемой операции (что это за операция); сценарии взаимодействия, определяемом специфической ролью пользователя (по какому сценарию она должна выполняться тем или иным пользователем); и, наконец, на деталях интерфейса (какие элементы управления, предлагает интерфейс для выполнения операции). 59

IDEF 9 — Scenario-Driven IS Design (Business Constraint Discovery method) - Метод исследования бизнес ограничений был разработан для облегчения обнаружения и анализа ограничений в условиях которых действует предприятие. Обычно, при построении моделей описанию ограничений, оказывающих влияние на протекание процессов на предприятии уделяется недостаточное внимание. Знания об основных ограничениях и характере их влияния, закладываемые в модели, в лучшем случае остаются неполными, несогласованными, распределенными нерационально, но часто их вовсе нет. Это не обязательно приводит к тому, что построенные модели нежизнеспособны, просто их реализация столкнется с непредвиденными трудностями, в результате чего их потенциал будет не реализован. Тем не менее, в случаях, когда речь идет именно о совершенствовании структур или адаптации к предсказываемым изменениям, знания о существующих ограничениях имеют критическое значение; 60

IDEF 14 Network Design - Метод проектирования компьютерных сетей, основанный на анализе требований, специфических сетевых компонентов, существующих конфигураций сетей. Также он обеспечивает поддержку решений, связанных с рациональным управлением материальными ресурсами, что позволяет достичь существенной экономии 61

Не полностью разработанные методологии IDEF 7 - Information System Auditing – Аудит информационных систем. Этот метод определён как востребованный, однако так и не был полностью разработан; IDEF 10 — Implementation Architecture Modeling Моделирование архитектуры выполнения. Этот метод определён как востребованный, однако так и не был полностью разработан; IDEF 11 — Information Artifact Modeling. Этот метод определён как востребованный, однако так и не был полностью разработан; IDEF 12 — Organization Modeling - Организационное моделирование. Этот метод определён как востребованный, однако так и не был полностью разработан; IDEF 13 — Three Schema Mapping Design - Трёхсхемное проектирование преобразования данных. Этот метод определён как востребованный, однако так и не был полностью разработан; 62

Методология IDEF 0 63

1. IDEF 0 позволяет решать задачи описания классификации процессов, в рамках внедряемой на большинстве предприятий системы менеджмента качества. 2. IDEF 0 является стандартом для функционального моделирования в ряде стран, включая США и Россию, т. е. дает возможность ее использования в качестве единого языка. Результатом внедрения IDEF 0 становится модель, состоящая из диаграмм, текста и словаря терминов, имеющих перекрестные ссылки друг на друга. 64

Синтаксис языка Набор структурных компонентов языка, их характеристики и правила, определяющие связи между компонентами, представляют собой синтаксис языка. Компоненты синтаксиса IDEF 0 – блоки, стрелки, диаграммы и правила. Блоки представляют функции, определяемые как деятельность, процесс, операция, действие или преобразование ; Стрелки представляют данные или материальные объекты, связанные с функциями; Правила определяют, как следует применять компоненты; Диаграммы обеспечивают формат графического и словесного описания моделей. Формат образует основу для управления конфигурацией модели. 65

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

Нумерация блоков и диаграмм Все функциональные блоки IDEFO нумеруются. В номерах допускается использование префиксов произвольной длины, но в подавляющем большинстве моделей используется префикс А. Номер блока проставляется за префиксом. Контекстный блок всегда имеет номер АО. Префикс повторяется для каждого блока модели. Номера используются для отражения уровня декомпозиции, на котором находится блок. Блок АО декомпозируется в блоки А 1, А 2, A 3 и т. д. А 1 декомпозируется в А 11, А 12, А 13 и т. д. А 11 декомпозируется в А 111, А 112, А 113 и т. д. Для каждого уровня декомпозиции в конец номера добавляется одна цифра. 67

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

Использование стрелок В IDEFO также моделируются управление и механизмы исполнения. Под управлением понимаются объекты, воздействующие на способ, которым блок преобразует вход в выход. Механизм исполнения — объекты, которые непосредственно выполняют преобразование входа в выход, но не потребляются при этом сами по себе. Для отображения категорий информации, присутствующих на диаграммах IDEFO, существует аббревиатура ICOM, отображающая четыре возможных типа стрелок: I (Input) — вход — нечто, что потребляется в ходе выполнения процесса; С (Control) — управление — ограничения и инструкции, влияющие на ход выполнения процесса; О (Output) — выход — нечто, являющееся результатом выполнения процесса; М (Mechanism) — исполняющий механизм — нечто, что используется для выполнения процесса, но не потребляется само по себе. 69

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

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

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

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

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

75

Комбинированные стрелки В IDEFO существует пять основных видов комбинированных стрелок: выход — вход; выход — управление; выход — механизм исполнения; выход — обратная связь на управление; выход — обратная связь на вход. 76

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

Туннели Понятие связанные стрелки используется для управления уровнем детализации диаграмм. Если одна из стрелок диаграммы отсутствует на родительской диаграмме (например, ввиду своей несущественности для родительского уровня) и не связана с другими стрелками той же диаграммы, точка входа этой стрелки на диаграмму или выхода с нее обозначается туннелем. Пример, стрелка "корпоративная информационная система" — важный механизм исполнения для данной диаграммы, но, возможно, она более нигде не используется в модели. Туннель в данном случае используется как альтернатива загромождению родительских диаграмм помещением на них несущественных для их уровня стрелок Кроме того, туннели применяются для отражения ситуации, когда стрелка, присутствующая на родительской диаграмме, отсутствует в диаграмме декомпозиции соответствующего блока 78

Диаграммы IDEF 0 -модели состоят из трех типов документов: графических диаграмм, текста и глоссария. Эти документы имеют перекрестные ссылки друг н друга. Графическая диаграмма – главный компонент IDEF 0 модели, содержащий блоки, стрелки, соединения блоков и стрелок и ассоциированные с ними отношения. Блоки представляют основные функции моделируемого объекта. Эти функции могут быть разбиты (декомпозированы) на составные части и представлены в виде более подробных диаграмм; процесс декомпозиции продолжается до тех пор, пока объект не будет описан на уровне детализации, необходимом для достижения целей конкретного проекта. Диаграмма верхнего уровня обеспечивает наиболее общее или абстрактное описание объекта моделирования. За этой диаграммой следует серия дочерних диаграмм, дающих более детальное представление об объекте. 79

Диаграммы Типовая диаграмма IDEFO содержит на полях служебную информацию. Служебная информация состоит из хорошо выделенных верхнего и нижнего колонтитулов (заголовка и "подвала"). Элементы заголовка используются для отслеживания процесса создания модели. Элементы "подвала" отображают наименование модели, к которой относится диаграмма, и показывают ее расположение относительно других диаграмм модели. 80

Элементы заголовка диаграммы IDEFO 81

элементы "подвала" диаграммы 82

Контекстная диаграмма верхнего уровня. Каждая модель должна иметь контекстную диаграмму верхнего уровня, на которой объект моделирования представлен единственным блоком с граничными стрелками. Эта диаграмма называется A-0 (А минус нуль). Стрелки на этой диаграмме отображают связи объекта моделирования с окружающей средой. Поскольку единственный блок представляет весь объект, его имя –общее для всего проекта. Это же справедливо и для всех стрелок диаграммы, поскольку они представляют полный комплект внешних интерфейсов объекта. Диаграмма A-0 устанавливает область моделирования и ее границу. 83

Пример 84

Контекстная диаграмма A-0 должна содержать краткие утверждения, определяющие точку зрения должностного лица или подразделения, с позиций которого создается модель, и цель, для достижения которой ее разрабатывают. Эти утверждения помогают руководить разработкой модели и ввести этот процесс в определенные рамки. Точка зрения определяет, что и в каком разрезе можно увидеть в пределах контекста модели. Изменение точки зрения, приводит к рассмотрению других аспектов объекта. Аспекты, важные с одной точки зрения, могут не появиться в модели, разрабатываемой с другой точки зрения на тот же самый объект. Формулировка цели выражает причину создания модели, т. е. содержит перечень вопросов, на которые должна отвечать модель, что в значительной мере определяет ее структуру. 85

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

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

88

Дополнения диаграмм IDEF 0 Диаграммы потоков данных IDEF 3 Диаграммы моделирования IDEF 3 89

Диаграммы потоков данных (DFD) Диаграммы DFD используются для анализа документооборота в рамках моделируемого IDEF 0 процесса, основное назначение -анализ управляемости основного процесса. DFD – использующий понятия "поток данных" и "хранилище данных" для описания системы в виде набора диаграмм, отражающих и структурирующих требования к проектируемой системе. С их помощью эти требования разбиваются на функциональные компоненты (процессы) и представляются в виде сети, связанной потоками данных. 90

Основные компоненты диаграмм DFD Основными компонентами диаграмм потоков данных являются: внешние сущности; процессы; накопители данных; потоки данных. Для изображения DFD традиционно используются две различные нотации: Иодана и Гейна-Сарсона 91

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

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

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

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

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

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

Пример ветвления 98

Пример объединения 99

Пример сложной диаграммы DFD 10 0

Методика описания процессов IDEF 3 называемая также workflow diagramming, — методология моделирования, использующая графическое описание информационных потоков, взаимоотношений между процессами обработки информации и объектов, являющихся частью этих процессов. Диаграммы Workflow могут быть использованы в моделировании бизнес-процессов для анализа завершенности процедур обработки информации. С их помощью можно описывать сценарии действий сотрудников организации, например последовательность обработки заказа или события, которые необходимо обработать за конечное время. Каждый сценарий сопровождается описанием процесса и может быть использован для документирования каждой функции. 10 1

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

Средства IDEF 3 позволяют выполнять следующие задачи: Документировать имеющиеся данные о технологии процесса, выявленные, скажем, в процессе опроса компетентных сотрудников, ответственных за организацию рассматриваемого процесса. Определять и анализировать точки влияния потоков сопутствующего документооборота на сценарий технологических процессов. Определять ситуации, в которых требуется принятие решения, влияющего на жизненный цикл процесса, например изменение конструктивных, технологических или эксплуатационных свойств конечного продукта. Содействовать принятию оптимальных решений при реорганизации технологических процессов. Разрабатывать имитационные модели технологических процессов, по принципу "КАК БУДЕТ, ЕСЛИ 10 3

Элементы IDEF 3 Диаграммы. Диаграмма является основной единицей описания в IDEF 3. Единицы работы (Unit of Work, UOW) - основной компонент диаграммы IDEF 3. Работы изображаются прямоугольниками с прямыми углами и имеют имя, выраженное глаголом или отглагольным существительным, обозначающим процесс действия, одиночным или в составе фразы, и номер (идентификатор). Идентификатор работы присваивается при создании и не меняется никогда. Даже если работа будет удалена, ее идентификатор не будет вновь использоваться для других работ. Обычно номер работы состоит из номера родительской работы и порядкового номера на текущей диаграмме 10 4

Элементы IDEF 3 Связи (Links) - Связи, изображаемые стрелками, показывают взаимоотношения работ. Все связи в IDEF 3 однонаправлены и могут быть направлены куда угодно, но обычно диаграммы IDEF 3 стараются построить так, чтобы связи были направлены слева направо. В IDEF 3 различают три типа стрелок, изображающих связи, стиль которых устанавливается через меню Edit/Arrow Style: Связь предшествования (Precedence) – показывает, что прежде чем начнется работа-приемник, должна завершиться работа-источник. Обозначается сплошной линией. Связь отношения (Relational) - показывает связь между двумя работами или между работой и объектом ссылки. Обозначается пунктирной линией. 10 5

Элементы IDEF 3 Поток объектов (Object Flow) – показывает участие некоторого объекта в двух или более работах, как, например, если объект производится в ходе выполнения одной работы и потребляется другой работой. Обозначается стрелкой с двумя наконечниками. Перекрестки (Junctions) - используются в диаграммах IDEF 3, чтобы показать ветвления логической схемы моделируемого процесса и альтернативные пути развития процесса, которые могут возникнуть во время его выполнения. Различают два типа перекрестков: Перекресток слияния (Fan-in Junction) – узел, собирающий множество стрелок в одну, указывая на необходимость условия завершенности работ-источников стрелок для продолжения процесса. Перекресток ветвления (Fan-out Junction) – узел, в котором единственная входящая в него стрелка ветвится, показывая, что работы, следующие за перекрестком, выполняются параллельно или альтернативно 10 6

Классификация типов перекрестков. Обознач ение Наименование слияния стрелок разветвления стрелок Asynchronous AND Все предшествующие процессы должны быть завершены Все следующие процессы должны быть запущены Synchronous AND Все предшествующие процессы завершены одновременно Все следующие процессы запускаются одновременно Asynchronous OR Один или несколько предшествующих процессов должны быть завершены Один или несколько следующих процессов должны быть запущены Synchronous OR Один или несколько предшествующих процессов завершаются одновременно Один или несколько следующих процессов запускаются одновременно XOR (Exclusive OR) Только один предшествующий процесс завершен Только один следующий процесс запускается 107

Элементы IDEF 3 Объекты ссылок (Referents) - служат для выражения идей и концепций без использования специальных методов, таких как стрелки, перекрестки или работы. Объект ссылки изображается в виде прямоугольника, похожего на прямоугольник работы. Имя объекта ссылки задается в диалоге Referent (пункт всплывающего меню Name Editor), в качестве имени можно использовать имя какой-либо стрелки с других диаграмм или имя сущности из модели данных. Объекты ссылки должны быть связаны с единицами работ или перекрестками пунктирными линиями. При внесении объектов ссылок следует указывать имя и тип объекта ссылки 10 8

Объекты ссылок 10 9

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

Пример диаграммы 11 1

Инструментальная среда BPwin CASE-средство BPWIN 11 2

Интерфейс BPwin имеет достаточно простой и интуитивно понятный интерфейс пользователя. При запуске BPwin по умолчанию появляется основная панель инструментов, палитра инструментов (вид которой зависит от выбранной нотации) и, в левой части, навигатор модели — Model Explorer 11 3

Задание методики При создании новой модели возникает диалог, в котором следует указать, будет ли создана модель заново или она будет открыта из файла либо из репозитория Model. Mart, затем внести имя модели и выбрать методологию, в которой будет построена модель. BPwin поддерживает три методологии — IDEF 0, IDEF 3 и DFD, каждая из которых решает свои специфические задачи. В BPwin возможно построение смешанных моделей, т. е. модель может содержать одновременно диаграммы как IDEF 0, так и IDEF 3 и DFD. Состав палитры инструментов изменяется автоматически, когда происходит переключение с одной нотации на другую. 11 4

Модель в BPwin рассматривается как совокупность работ, каждая из которых оперирует с некоторым набором данных. Работа изображается в виде прямоугольников, данные — в виде стрелок. Если щелкнуть по любому объекту модели левой кнопкой мыши, появляется контекстное меню, каждый пункт которого соответствует редактору какого-либо свойства объекта. 11 5

Построение модели IDEF 0 На начальных этапах создания ИС необходимо понять, как работает организация, которую собираются автоматизировать. Руководитель хорошо знает работу в целом, но не в состоянии вникнуть в детали работы каждого рядового сотрудника. Рядовой сотрудник хорошо знает, что творится на его рабочем месте, но может не знать, как работают коллеги. Поэтому для описания работы предприятия необходимо построить модель, которая будет адекватна предметной области и содержать в себе знания всех участников бизнеспроцессов организации 11 6

Процесс моделирования системы в IDEF 0 начинается с создания контекстной диаграммы — наиболее абстрактного уровня описания системы в целом, содержащей определение субъекта моделирования, цели и точки зрения на модель. Под субъектом понимается сама система, при этом необходимо точно установить, что входит в систему, а что лежит за ее пределами, другими словами, определить, что будет в дальнейшем рассматриваться как компоненты системы, а что как внешнее воздействие. На определение субъекта системы будут существенно влиять позиция, с которой рассматривается система, и цель моделирования — вопросы, на которые построенная модель должна дать ответ. Другими словами, в начале необходимо определить область моделирования. Описание области как системы в целом, так и ее компонентов является основой построения модели. Хотя предполагается, что в ходе моделирования область может корректироваться, она должна быть в основном сформулирована изначально, поскольку именно область определяет направление моделирования. 11 7

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

Цель моделирования Цель моделирования определяется из ответов на следующие вопросы: Почему этот процесс должен быть смоделирован? Что должна показывать модель? Что может получить клиент? Точка зрения (Viewpoint). Под точкой зрения понимается перспектива, с которой наблюдалась система при построении модели. Хотя при построении модели учитываются мнения различных людей, все они должны придерживаться единой точки зрения на модель. Точка зрения должна соответствовать цели и границам моделирования. Как правило, выбирается точка зрения человека, ответственного за моделируемую работу в целом 11 9

Настройка отчета Результат описания модели можно получить в отчете Model Report. Диалог настройки отчета по модели вызывается из пункта меню Tools/Reports/Model Report. В диалоге настройки следует выбрать необходимые поля, при этом автоматически отображается очередность вывода информации в отчет 12 0