Файл: PRIS.doc

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

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

Миниспецификация является конечной вершиной иерархии DFD. Решение о завершении детализации процесса и использовании миниспецификации принимается аналитиком исходя из следующих критериев:

• наличия у процесса относительно небольшого количества входных и выходных потоков данных (2-3 потока);

• возможности описания преобразования данных процессом в виде последовательного алгоритма;

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

• возможности описания логики процесса при помощи миниспецификации небольшого объема (не более 20-30 строк).

Синтаксис DFD включает четыре основных элемента:

• поток данных;

• процесс;

• хранилище;

• внешняя сущность.

Рассмотрим эти элементы подробнее.

Поток данных

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

Потоки на диаграммах изображаются стрелками (обычно именованными), ориентация которых указывает направление движения информации (Error: Reference source not found).

ОПР.: Процесс преобразует значения данных.

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

Назначение процесса состоит в продуцировании выходных потоков из входных в соответствии с действием, задаваемым именем процесса. Это имя должно содержать глагол в неопределенной форме с последующим дополнением (например, «выдать пропуск»). Кроме того, каждый процесс должен иметь уникальный номер для ссылок на него внутри диаграммы. Этот номер может использоваться совместно с номером диаграммы для получения уникального индекса процесса во всей модели.

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

ОПР. 2: ХРАНИЛИЩЕ (НАКОПИТЕЛЬ) ДАННЫХ позволяет на определенных участках определять данные, которые будут сохраняться в памяти между процессами. Фактически хранилище представляет "срезы" потоков данных во времени. Информация, которую оно содержит, может использоваться в любое время после ее определения, при этом данные могут выбираться в любом порядке. Имя хранилища должно идентифицировать его содержимое и быть существительным. В случае, когда поток данных входит или выходит в/из хранилища, и его структура соответствует структуре хранилища, он должен иметь то же самое имя, которое нет необходимости отражать на диаграмме.

ОПР. 1: ВНЕШНЯЯ СУЩНОСТЬ (или ТЕРМИНАТОР) представляет сущность вне контекста системы, являющуюся источником или приемником системных данных. Ее имя должно содержать существительное. Предполагается, что объекты, представленные такими узлами, не должны участвовать ни в какой обработке.

ОПР. 2: Под внешней сущностью (External Entity) понимается материальный объект, являющийся источником или приемником информации.

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

7. Нотация IDEF3. Типы диаграмм в IDEF3. Синтаксис IDEF3. [8]

ОПР. 1: IDEF 3 – (workflow modeling, Рrocess Description Capture Method) методология описания бизнес-процессов (потоков работ).

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

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

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

• Определять и анализировать точки слияния и разделения потоков информации.

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

• Содействовать принятию оптимальных решений при реорганизации процессов.

• Разрабатывать модели процессов, по принципу "КАК БУДЕТ, ЕСЛИ..."

Как было отмечено выше, IDEF3 дополняет IDEFO и содержит все необходимое для построения моделей, которые в дальнейшем могут быть использованы для имитационного анализа

IDEF3-диаграмма

IDEF3 диаграмма (диаграмма потока, process flow diagram, IDEF3-diagram, workflow) - основная единица описания в IDEF3, являющаяся графическим представлением назначения системы или процесса и применяются для анализа завершенности процесса обработки информации (проверка модели ИС на целостность). Обычно IDEF3-диаграммы являются дополнением к IDEFO-диаграммам, т.к. содержат все необходимые сведения для построения моделей, которые в дальнейшем могут быть использованы для имитационного анализа. С помощью диаграмм IDEF3 можно анализировать сценарии из реальной жизни, например, как закрывать магазин в экстренных случаях или какие действия должны выполнить менеджер и продавец при закрытии. Каждый такой сценарий содержит в себе описание процесса и может быть использован, что бы наглядно показать или лучше задокументировать бизнес-функции организации.

Типы диаграмм в IDEF3

Существуют два типа диаграмм в стандарте IDEF3, представляющие описание одного и того же сценария технологического процесса в разных ракурсах (Error: Reference source not found):

• Диаграммы Описания Последовательности Этапов Процесса (Process Flow Description Diagrams, PFDD). С помощью диаграмм PFDD документируется последовательность и описание стадий обработки детали в рамках исследуемого технологического процесса.

• Диаграммы Состояния Объекта в и его Трансформаций Процессе (Object State Transition Network, OSTN). Диаграммы OSTN используются для иллюстрации трансформаций детали, которые происходят на каждой стадии обработки (анализ этого типа диаграмм в CA BPwin не поддерживается).

Иное встречающееся название для PFDD - диаграмма работ WFD (Work Flow Diagram).

Элементы IDEF3 диаграммы

Синтаксис IDEF3 оперирует тремя элементами (Error: Reference source not found):

• единицы работ;

• связи;

• перекрестки.

UOW (Unit of Work) единица работы/ действие

UOW (Unit Of Work, activity, единица работы) - центральные компоненты модели, предназначенные для описания процесса, действий, принимаемых решений и других процедур, происходящих в системе. В IDEF3 каждый функциональный элемент, изображенный в виде блока, представляет собой определенный сценарий моделируемого процесса и может являться частью другой функции.

На IDEF3-диаграммах UOW изображаются прямоугольниками с прямыми углами и имеют идентифицирующие их атрибуты, расположенные в специальных полях

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

JUNCTION (перекресток, узел). Методология IDEF3 включает элемент «перекресток», что позволяет описать логику взаимодействия между множеством событий и временной синхронизации активизации элементов диаграмм IDEF3. Перекрестки обеспечивают аналитика инструментом, описывающим возможные ветвления и параллельность выполнения ряда действий в описываемом процессе, усиливают описание временных отношений и отношений очередности выполнения различных частей процесса. Окончание одной UOW может служить сигналом к началу нескольких UOW, или же одна UOW для своего запуска может ожидать окончания нескольких UOW.

Asynchronous AND - асинхронное "И". При слиянии требуется, чтобы все предшествую-щие процессы были завершены. При разветвлении требуется, чтобы все следующие про-цессы были запущены

Synchronous AND - синхронное "И". При слиянии требуется, чтобы все предшествующие процессы завершались одновременно. При разветвлении требуется, чтобы все следующие процессы запускались одновременно

Asynchronous OR - асинхронное "ИЛИ". При слиянии требуется, чтобы один или несколько предшествующих процессов были завершены. При разветвлении требуется, чтобы один или несколько следующих процессов были запущены

Synchronous OR - синхронное "ИЛИ". При слиянии требуется, чтобы один или несколько предшествующих процессов завершались одновременно. При разветвлении требуется, чтобы один или несколько следующих процессов запускались одновременно

Exclusive OR - исключающее "или". При слиянии требуется, чтобы только один предше-ствующий процесс завершен. При разветвлении требуется, чтобы запускался только один следующий процесс

8. Комплексный подход к созданию ИС (Enterprise Architecture). Схема Захмана. [8]

Вспоминаете про 3 уровня иерархии(стратегический уровень, тактический и оперативный). Рассказываете о «различном видении» этих самых уровней на проблему. Встаёт вопрос, как это изменить и свести всё в одну кучу. Вспоминаем про обеспечивающие подсистемы (технический, информационный, организационный и программный). Понимаем, что всё это необходимо свести воедино и вспоминаем тут Схему Захмана. Выглядит, как таблица, сверху = вопрос, на который мы ищем ответ, сбоку – подсистема, а на пересечении – как оно должно выглядеть. Вопросов – до бесконечности.Почему так мало? А я не вижу в лекциях эту херню блять.

9. Корпоративные ИС. Стандарты APICS на корпоративные ИС. MRP, MRPII и ERP системы. [10]

В соответствии со Словарем APICS (American Production and Inventory Control Society), термин «ERP-система» (Enterprise Resource Planning — Управление ресурсами предприятия) может употребляться в двух значениях. Во-первых, это — информационная система для идентификации и планирования всех ресурсов предприятия, которые необходимы для осуществления продаж, производства, закупок и учета в процессе выполнения клиентских заказов. Во-вторых (в более общем контексте), это — методология эффективного планирования и управления всеми ресурсами предприятия, которые необходимы для осуществления продаж, производства, закупок и учета при исполнении заказов клиентов в сферах производства, дистрибьюции и оказания услуг.

Аббревиатура ERP используется для обозначения комплексных систем управления предприятием (Enterprise-Resource Planning – планирование - ресурсов предприятия). Ключевой термин ERP является Enterprise – Предприятие, и только потом – планирование ресурсов. Истинное предназначение ERP - в интеграции всех отделов и функций компании в единую компьютерную систему, которая сможет обслужить все специфичные нужды отдельных подразделений.

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

Возьмем, к примеру, обработку заказа. Обычно, когда клиент делает заказ, тот начинает долгое путешествие из одной папки для бумаг в другую. При этом информация по заказу попутно «вбивается» то в одну компьютерную систему, то в другую. Это неспешное путешествие ведёт к запаздыванию исполнения заказов и их потере, а также является причиной ошибок при многократном вводе информации в разные системы. Между тем, в нужный момент никто в компании по-настоящему не может сказать, каково реальное состояние заказа, потому что сотрудник фронт - офиса не может заглянуть в компьютеры склада и сказать, отгружен уже товар или нет. И разъяренный заказчик слышит только: «Позвоните, пожалуйста, на склад!»

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