Системный анализ и принятие решений PDF
Document Details
Uploaded by Deleted User
Tags
Summary
Данный документ представляет собой набор лекционных материалов по системному анализу и принятию решений. Описываются основные понятия и этапы системного анализа, процедура исследования предприятий и интегрирующих факторов. Эта информация может быть полезной для студентов, изучающих системный анализ.
Full Transcript
Летучка 1. История развития 1. Перечислите основные системного анализа, науки о системах основные этапы 2. Перечислите 2. Базовые понятия динамические свойства системного анализа системы 3. Перечислите 3. Перечислите принципы статические св...
Летучка 1. История развития 1. Перечислите основные системного анализа, науки о системах основные этапы 2. Перечислите 2. Базовые понятия динамические свойства системного анализа системы 3. Перечислите 3. Перечислите принципы статические свойства системного анализа системы 4. Перечислите 4. Перечислите основные синтетические методы системного свойства системы анализа 5. Сущность системного 5. Основные этапы подхода системного анализа, их характеристика Системный анализ предприятий и учреждений Тема 2 4/4 Процедуры системного анализа для исследования предприятий: 1. Определить границы исследуемой системы Эти границы условны. Например, границы системы “корпорация” в одном случае могут быть определены списочным составом постоянного персонала, в другой задаче - постоянным персоналом плюс всеми акционерами компании, в третьем случае эти пределы расширяются за счет всех временно привлекаемых специалистов, экспертов, консультантов и т.д. 2. Определить все надсистемы, в которые входит исследуемая система в качестве части Так, если мы выясняем воздействие на предприятие экономической среды, именно она и будет той надсистемой, в которой следует рассматривать его функции. Любой объект, в частности, предприятие, можно изучать в качестве составной части многих систем - экономических, политических, государственных, региональных, социальных, экологических, международных исходя из цели анализа. 3. Выявить состав системы, т.е. определить части, из которых она состоит. В принципе процесс выделения частей, в плане проникновения вглубь системы может быть бесконечным; он ограничен лишь потребностями конкретной задачи. Так, в зависимости от решаемой задачи, рассматривая состав такой системы как предприятие, можно ограничиться, например перечнем цехов и отделов, а можно, при необходимости расчленить их на бригады, участки, отдельных работников, элементы деятельности каждого из них и т.д. 4. Определить структуру системы, представляющую собой совокупность связей между его компонентами Структура - это внутренняя форма системы, образно говоря ее “строение”. Ее нельзя, сводить лишь к составу системы, набору компонентов. Следует подчеркнуть многоструктурность любой системы. Например, на предприятии существует организационная структура, т.е. совокупность так называемых отношений субординации и координации, иначе говоря, отношений подчиненности и согласованности. На предприятии есть и информационная структура, выражающаяся в определенных формальных и неформальных потоках информации. Существуют также потоки материалов, сырья, деталей, готовых изделий, составляющих свои структуры. 5. Определить функции компонентов системы Эта процедура имеет особую значимость, поскольку в реальных процессах каждый компонент обладает не только полезными свойствами, обеспечивающими достижение целей системы в целом, но и негативными, мешающими чертами. Следует отделить провозглашаемые или предписанные функции компонентов от реально выполняемых. 6. Выявить причины, объединяющие отдельные части в систему, в целостность. Они носят название интегрирующих факторов. В целом интегрирующим фактором, создающим системы, является человеческая деятельность. Исходным, первичным интегрирующим фактором является цель. 7. Определить все возможные связи, коммуникации системы с внешней средой Для действительно глубокого, всестороннего изучения системы необходимо выявить ее связи со всеми надсистемами, которым она принадлежит. Например, можно определить все системы, которым принадлежат работники предприятия - профсоюзы, политические партии, семьи, системы социокультурных ценностей и этических норм, этнические группы и т.д. 8. Рассмотреть исследуемую систему в динамике, в развитии Это означает: сформулировать историю системы, источник ее возникновения, периоды становления, тенденции и перспективы развития, переходы к качественно новым состояниям. Применение методологий семейства IDEF для обследования деятельности компании Вопросы к летучке по основным понятиям системного анализа 1. История развития системного анализа, основные этапы 2. Базовые понятия системного анализа 3. Перечислите статические свойства системы 4. Перечислите основные методы системного анализа 5. Основные этапы системного анализа, их характеристика 6. Перечислите основные науки о системах 7. Перечислите динамические свойства системы 8. Перечислите принципы системного анализа 9. Перечислите синтетические свойства системы 10. Сущность системного подхода Видео https://youtu.be/9M0nFt3V7XY IDEF — методологии семейства ICAM (Integrated Computer-Aided Manufacturing) для решения задач моделирования сложных систем Семейство IDEF IDEFO - методология функционального моделирования; IDEF1 - методология моделирования информационных потоков; IDEF1X - методология построения реляционных структур; IDEF2 - методология динамического моделирования развития систем; IDEF3 - методология документирования процессов в системе; IDEF4 - методология построения объектно-ориентированных систем; IDEF5 — методология онтологического исследования сложных систем; IDEF6 — методология использования рационального опыта проектирования, позволяющая предотвратить возникновение структурных ошибок при новом проектировании информационных систем IDEF7 — методология аудита информационной системы; IDEF8— методология разработки модели графического интерфейса пользователя; IDEF9 — методология анализа существующих условий и ограничений, их влияния на принимаемые решения в процессе реинжиниринга; IDEF10 — методология моделирования архитектуры выполнения; IDEF11 — методология информационного моделирования артефактов IDEF12 — методология организационного моделирования; IDEF13 — методология проектирования трёхсхемного дизайна карт; IDEF14 — методология моделирования компьютерных сетей Стандарт моделирования бизнес-процессов IDEFo был принят в качестве такового в 1981 г. Исторически он возник из стандарта SADT (Structured Analysis and Design Teqnique), активно применявшегося с конца 1960-х гг., в частности Министерством обороны США. Семейство стандартов IDEF включает в себя ряд графических нотаций, которые могут быть использованы для моделирования БП: – IDEFo – стандарт описания бизнес-процессов; – DFD – диаграмма потока данных (DataFlow Diagram); – IDEF3 – стандарт моделирования потока работ (workflow).. Другие нотации для описания бизнес-процессов Кроме IDEF для моделирования БП активно рименяют и другие системы моделирования, например ARIS и UML ARIS расшифровывается как Arhitecture of Integrated Information Systems – архитектура интегрированных информационных систем Аббревиатура UML расшифровывается как Unified Modeling Language– унифицированный язык моделирования. UML предназначен в первую очередь для быстрого проектирования и разработки программных продуктов, и описание бизнес- процессов с его использованием целесообразно делать, если в конечном итоге требуется разработать корпоративную информационную систему, которая бы отражала особенности протекания бизнес- процессов на предприятии заказчика. Занятие 4 Основы нотаций описания бизнес-процессов IDEF0 В основе методологии IDEFo лежат три основных понятия: – функциональный блок (Activity Box); – интерфейсная дуга (Arrow); – декомпозиция (Decomposition). Функциональный блок Интерфейсная дуга Идентификатор Функциональный блок (Activity Box) Функциональный блок графически изображается в виде прямоугольника и олицетворяет собой некоторую конкретную функцию в рамках рассматриваемой системы. По требованиям стандарта название каждого функционального блока должно быть сформулировано в глагольном наклонении (например, «производить услуги», а не «производство услуг»). Каждая из четырех сторон функционального блока (рис.) имеет свое определенное значение (роль), при этом: верхняя сторона имеет значение «Управление» (Control); – левая сторона имеет значение «Вход» (Input); – правая сторона имеет значение «Выход» (Output); – нижняя сторона имеет значение «Механизм» (Mechanism). Каждый функциональный блок в рамках единой рассматриваемой системы должен иметь свой уникальный идентификационный номер. Интерфейсная дуга (Arrow) Интерфейсная дуга – второе важное понятие методологии IDEFo. Также интерфейсные дуги часто называют потоками или стрелками. Интерфейсная дуга отображает элемент системы, который обрабатывается функциональным блоком или оказывает иное влияние на функцию, отображенную данным функциональным блоком. Графическим отображением интерфейсной дуги является однонаправленная стрелка. Каждая интерфейсная дуга должна иметь свое уникальное наименование (Arrow Label). По требованию стандарта наименование должно быть оборотом существительного. С помощью интерфейсных дуг отображают различные объекты, в той или иной степени определяющие процессы, происходящие в системе. Вариант А Вариант Б Такими объектами могут быть элементы реального мира (детали, вагоны, сотрудники и т. д.) или потоки данных и информации (документы, данные, инструкции и т. д.). В зависимости от того, к какой из сторон подходит данная интерфейсная дуга, она носит название «входящей», «исходящей» или «управляющей» (рис.) Кроме того, «источником» (началом) и «приемником» (концом) каждой функциональной дуги могут быть только функциональные блоки, при этом «источником» может быть только выходная сторона блока, а «приемником» – любая из трех оставшихся. любой функциональный блок по требованиям стандарта должен иметь по крайней мере одну управляющую интерфейсную дугу и одну исходящую. Интерфейсные дуги при моделировании предприятий В случае рассмотрения предприятий и организаций существуют пять основных видов объектов: – материальные потоки (детали, товары, сырье и т. д.), – финансовые потоки (наличные и безналичные, инвестиции и т. д.), – потоки документов (коммерческие, финансовые и организационные документы), – потоки информации (информация, данные о намерениях, устные распоряжения и т. д.) – ресурсы (сотрудники, станки, машины и т. д.). При этом в различных случаях: – входящими и исходящими интерфейсными дугами могут отображаться все виды объектов, – управляющими дугами– только относящиеся к потокам документов и информации, – дугами механизмами – только ресурсы. Декомпозиция (Decomposition) Декомпозиция позволяет постепенно и структурированно представлять модель системы в виде иерархической структуры отдельных диаграмм, что делает ее менее перегруженной и легко усваиваемой Принцип декомпозиции применяется при разбиении сложного процесса на составляющие его функции. При этом уровень детализации процесса определяется непосредственно разработчиком модели. Модель IDEF0 всегда начинается с представления системы как единого целого – одного функционального блока с интерфейсными дугами, простирающимися за пределы рассматриваемой области. Такая диаграмма с одним функциональным блоком называется контекстной диаграммой, и обозначается идентификатором “А-0”. Важно отметить, что в каждом случае декомпозиции функционального блока все интерфейсные дуги, входящие в данный блок, или исходящие из него фиксируются на дочерней диаграмме. Этим достигается структурная целостность IDEF0 – модели. Конец занятия 27.02.21 След. летучка Сист. анализ Темы рефератов Летучка 1. История развития 1. Базовые понятия системного системного анализа, анализа основные этапы 2. Перечислите основные 2. Перечислите статические методы системного анализа свойства системы 3. Перечислите основные 3. Основные этапы науки о системах системного анализа, их 4. Перечислите принципы характеристика системного анализа 4. Перечислите динамические 5. Сущность системного свойства системы подхода 5. Перечислите синтетические свойства системы Тематика рефератов 1. Основные методологические принципы анализа систем. 2. Понятия устойчивости, управляемости и достижимости цели в теории систем 3. Понятие цели и её достижимости в системном анализе 4. Показатели и критерии эффективности функционирования систем 5. Методы многокритериальной оценки альтернатив. 6. Модели и методы принятия решений при нечеткой информации 7. Анализ практики принятия решения в отечественных и зарубежных компаниях. 8. Анализ проблем учета неопределенности в принятии управленческих решений. 9. Анализ проблем использования методов многокритериальной оценки при выборе управленческих решений. 10. Анализ проблем использования методов прогнозирования в процессе разработки управленческих решений. 11. Анализ особенностей использования информационных систем при разработке управленческих решений. 12. Проблемы эффективности управленческих решений. 13. Жизненный цикл управленческого решения. 14. Зарубежные представления о разработке управленческих решений. 15. Зарубежные методологии принятия решений экипажем воздушного судна 16. Особенности и методы принятия решений в сфере стратегического управления. 17. Особенности и методы принятия решений в сфере управления персоналом. 18. Особенности и методы принятия решений в сфере финансового менеджмента. 19. Особенности и методы принятия решений в маркетинге. 20. Особенности и методы принятия решений в управлении производством. «Тоннель» дуг (Arrow Tunnel) Часто бывают случаи, когда отдельные интерфейсные дуги не имеет смысла продолжать рассматривать в дочерних диаграммах ниже какого-то определенного уровня в иерархии или, наоборот, – отдельные дуги не имеют практического смысла выше какого-то уровня. Например, интерфейсную дугу, изображающую «деталь» на входе в функциональный блок «Обработать на токарном станке», не имеет смысла отражать на диаграммах более высоких уровней – это будет только перегружать диаграммы и делать их сложными для восприятия. Пояснительном текст к диаграмме В пояснительном тексте к контекстной диаграмме должна быть указана цель (Purpose) построения диаграммы в виде краткого описания и зафиксирована точка зрения (Viewpoint). Цель и точка зрения определяет соответствующие области в исследуемой системе, на которых необходимо фокусироваться в первую очередь. Модель деятельность предприятия с целью построения в дальнейшем на базе этой модели информационной системы, будет существенно отличаться от той, которую бы мы разрабатывали с целью оптимизации логистических цепочек. функциональные модели одного и того же предприятия с точек зрения главного технолога и финансового директора будут существенно различаться по направленности их детализации Глоссарий (Glossary) Для каждого из элементов IDEF0: диаграмм, функциональных блоков, интерфейсных дуг существующий стандарт подразумевает создание и поддержание набора соответствующих определений, ключевых слов, повествовательных изложений и т.д., которые характеризуют объект, отображенный данным элементом. Этот набор называется глоссарием и является описанием сущности данного элемента. Например, для управляющей интерфейсной дуги “распоряжение об оплате” глоссарий может содержать перечень полей соответствующего дуге документа, необходимый набор виз и т.д. Пример декомпозиции Используя функциональную модель "Произвести изделие", можно рассмотреть самую общую функцию " Произвести изделие", состоящую из следующих подфункций: – Планировать производство. – Разработать и вести план-график и сметы. – Планировать изготовление. – Обеспечить производственные ресурсы. – Получить производственные материалы. – Изготовить изделие. Детализация второго уровня Любая из этих подфункций может быть в дальнейшем детализирована. Функция "Планировать производство" может содержать подфункции: – Выбрать структуру и метод производства. – Оценить требования, стоимость и время производства. – Разработать планы производства. – Разработать план отдельной операции. Каждая из этих подфункций может быть снова декомпозирована с учетом полезности, знаний или имеющегося времени. Эта структура функций и подфункций может быть изображена как дерево узлов Структура функций и подфункций может быть также изображена как "индекс узлов" (Рис.). Формат индекса подобен формату содержания книги или формату списка материалов, используемых в промышленности Диаграмма А-0 "Произвести изделие" Детальная диаграмма А0 "Произвести изделие" Первый блок диаграммы А0 детализируется в диаграмме А1 "Планировать производство" Занятие 5 Видео Построение диаграммы IDEF0 на примере процесса «Варить борщ» Описание процесса «Увольнение» При увольнении сотрудник должен написать заявление об увольнении, завизировать его у непосредственного руководителя и отдать в отдел кадров для оформления приказа об увольнении. После этого он должен подписать обходной лист у членов уполномоченной комиссии. Затем сотрудник должен произвести расчеты в бухгалтерии, которой необходимы подписанный обходной лист и копия приказа об увольнении. После произведения расчетов сотрудник сдает обходной лист в отдел кадров, который оформляет (вносит соответствующие записи) и выдает трудовую книжку сотруднику. Выдача трудовой книжки фиксируется в книге учета хранения и выдачи трудовых книжек, в которой сотрудник должен поставить роспись о получении. В модели необходимо учесть следующие нюансы: увольнение сотрудника производится в соответствии с трудовым за- конодательством; компания использует систему 1С конфигурации «Зарплата и кадры»; обходные листы сдаются в архив; трудовые книжки хранятся в сейфе. Интерпретация входов Составить план выполнения работы – это будет последовательность функциональных блоков Задание Самостоятельно разработать диаграмму IDEF0 по приведенному примеру Для выполнения задания рекомендуется, изучив описание, составить план выполнения работы Этот план будет представлять блоки Activity (Функциональные блоки) детальной диаграммы верхнего уровня. Пример описания Занятие 6 Модель в нотации IDEF3 Модель в нотации IDEF0 это графический язык описания процессов происходящих в системе, позволяет получить общее представление о функциях, выполняемых моделируемой системой, и связях между функциями и действиями. Модель в нотации IDEF3 позволяет проследить логику взаимодействия процессов и функций. Можно сначала построить функциональную модель в нотации IDEF0, проведя исследования предметной области. Затем, используя полученные знания о предметной области, построить отдельную модель в нотации IDEF3 Основная цель, точка зрения и границы моделирования в нотации IDEF3 Основная цель нотации IDEF3 — дать аналитикам возможность описать ситуацию, когда процессы (действия) выполняются в определенной последовательности, а также описать объекты, участвующие совместно в одном процессе. Как и при моделировании в нотации IDEF0 сначала опрашиваются эксперты предметной области, определяется цель моделирования (набор вопросов, на которые будет отвечать модель), точка зрения, границы моделирования (какие объекты войдут, а какие не будут отображены в модели) Основной организационной единицей описания в IDEF3 является диаграмма. Основные элементы диаграмм в нотации IDEF3 Единица работы, действие В IDEF3 действия (Unit of Work, UOW) изображаются прямоугольниками с прямыми углами (рис.). Действия имеют имя, выраженное отглагольным существительным или глаголом, одиночным или в составе фразы с другим именем существительным, обычно отображающим основной выход (результат) работы, например, "Создание файла". Каждому действию присваивается уникальный номер (идентификатор), который никогда не меняется. Нотация IDEF3 позволяет декомпозировать (детализировать) действие многократно, т.е. включить в одну модель альтернативные описания процессов. Поэтому в номере действия стоит и порядковый номер декомпозиции родительского действия (рис.). Действия имеют входы и выходы, но не поддерживают управления и механизмы (как в нотации IDEF0, где есть особое назначение для стрелок сверху и снизу). Поэтому входы и выходы можно размещать с любой стороны. Связи Связи показывают существенные взаимоотношения между действиями. Все связи в IDEF3 однонаправлены, могут начинаться и заканчиваться на любой стороне блока. Обычно диаграммы IDEF3 стараются построить так, чтобы связи были направлены слева направо, сверху вниз. Типы связей В IDEF3 различают три типа связей. Связь "временное предшествование" изображается сплошной линией со стрелкой, связывающая единицы работ. Показывает, что работа-источник должна полностью закончиться прежде, чем работа-цель начнется. Во многих случаях завершение одного действия инициирует начало выполнения другого. Иногда изображается Временная шкала выполнения действий – Вертикальными линиями показано начало и окончание действий. Время окончания А1.1.1 и время начала А1.1.2 может совпадать, может не совпадать Связь «объектный поток» изображается стрелкой с двумя наконечниками Одновременно обозначает временную последовательность работ и материальный либо информационный поток. При этом выходом является объект, название которого надписано над стрелкой (в данном случае Файл). Эта связь также обозначает, что объект порождаемый первой работой, используется в последующих работах. Связь именуют так, чтобы четко определить передающийся объект. Временная семантика объектных связей аналогична связям предшествования. В данном случае вторая работа начинает выполняться после завершения первой работы. Здесь, файл является результатом выполнения действия А1.1.3 Связь "нечеткое отношение" изображается пунктирной линией. Используется, когда невозможно описать связи с использованием временное предшествование или объектных связей. Значение такой связи должно быть четко определено с помощью названия и описания стрелки, так как связи такого типа сами по себе не предполагают никаких ограничений. Нечеткое отношение может является альтернативой временному предшествованию и объектному потоку в смысле задания последовательности выполнения работ — работа-источник не обязательно должна закончиться, прежде чем работа-цель начнется. Соединения или перекрестки (Junction) Окончание одного действия может служить сигналом к началу нескольких действий, или же одно действие для своего запуска может ожидать окончания нескольких действий. То есть возникают специальные соединения или перекрестки. Перекрестки используются для отображения логики взаимодействия стрелок при слиянии и разветвлении. В отличие от IDEF0 в IDEF3 стрелки могут сливаться и разветвляться только через перекрестки. Различают перекрестки для слияния и разветвления стрелок. Перекресток не может использоваться одновременно для слияния и для разветвления. Все перекрестки на диаграмме нумеруются, каждый номер имеет префикс J. Типы перекрестков Асинхронное соединение "И" При слиянии стрелок, все предшествующие работы должны быть обязательно завершены (необязательно одновременно), прежде чем начнется выполнение следующей работы При разветвлении стрелок, все следующие работы должны быть обязательно запущены (необязательно одновременно) Пример Синхронное соединение "И" При слиянии стрелок, все предшествующие работы должны быть завершены одновременно При разветвлении стрелок, все следующие работы должны быть запущены одновременно Пример Асинхронное соединение "ИЛИ" При слиянии стрелок, одна или несколько предшествующих работ должны быть завершены (необязательно одновременно) При разветвлении стрелок, одна или несколько следующих работ должны быть запущены (необязательно одновременно) Пример Синхронное соединение "ИЛИ" При слиянии стрелок, одна или несколько предшествующих работ должны быть завершены одновременно При разветвлении стрелок, одна или несколько следующих работ должны быть запущены одновременно Эксклюзивное (исключающее) «ИЛИ» При слиянии стрелок, только одна предшествующая работа должна быть завершена, прежде чем сможет начаться следующая работа При разветвлении стрелок, только одна следующая работа должна быть запущена Пример Парность соединений Все соединения на диаграммах должны быть парными, т.е. любое разворачивающее соединение должно иметь парное себе сворачивающее соединение. Включение пожарной сигнализации 1.1.3 Обнаружение Набор Запись пожара O номера 01 O в журнале дежурств 1.1.2 J1 1.1.4 J2 1.1.6 Самостоятельное тушение пожара 1.1.5 Комбинации соединений. Перекрестки могут комбинироваться для создания сложных соединений 1.1.3 & & J2 J3 1.1.2 X 1.1.4 X 1.1.6 J1 J4 1.1.5 Объект ссылки (указатель) Объект ссылки в IDEF3 выражает некую идею, концепцию или данные, которые нельзя описать стрелкой, перекрестком или действием. Объект ссылки изображается в виде прямоугольника, похожего на прямоугольник работы. В качестве имени можно использовать имя какой-либо стрелки, процесса, действия с других диаграмм Объекты ссылки должны быть связаны с единицами работ или перекрестками линиями. Кроме имени следует указывать тип объекта ссылки Типы объектов ссылок Тип объекта Назначение ссылок 1. Object Используется для описания того, что в действии принимает участие какой-либо заслуживающий отдельного внимания объект 2. Ссылка Используется для реализации цикличности GOTO выполнения действий. Этот объект также может относиться к перекрестку 3. Единица Используется для многократного отображения на действий диаграмме одного и того же действия, но без цикла UOB (Unit of Behavior) Типы объектов ссылок Тип объекта Назначение ссылок 4. Заметка Используется для документирования какой-либо (Note) важной информации общего характера, относящейся к изображаемому на диаграммах. Служит альтернативой методу помещения текстовых заметок непосредственно на диаграммах 5. Уточнение Для уточнения или более подробного описания Elaboration изображаемого на диаграмме. Обычно (ELAB) используется для детального описания разветвления или слияния стрелок на перекрестках Пример построения модели IDEF3 Выполнение разделов к/р 1.1.4 Оформление Получение Подбор пояснит. задания литературы & & записки 1.1.2 1.1.3 J1 1.1.6 J2 Посещение консультаций 1.1.5 OBJECT/ Защита Преподаватель 1.1.7 Примечание: Обратите внимание на нумерацию единиц работ. Родительской является работа с собственным номером 1. Она декомпозируется первый раз, следовательно, версия декомпозиции = 1, далее следует собственный номер единицы работ в рамках модели (2-7). Пример построения модели IDEF3 Выполним декомпозицию UOW №4 – «Выполнение разделов к/р» ELAB/ Если есть ошибки в расчетах – внесение исправлений Выполнение расчетов 4.1.9 Написание Оформление теор.части Х & & Х 4.1.8 4.1.11 J6 J3 J4 J5 Построение графиков 4.1.10 Видео. Построение модели на основе idef3 Конец занятия 29.02.2020 Варианты заданий 1. «Обслуживание клиента в библиотеке» В процессе участвуют: библиотекарь, пользователь, которые выполняют функции поиск (подбор) литературы по запросу пользователя через информационную систему, при наличии требуемой литературы оформление формуляра, при отсутствие либо поиск похожей литературы либо завершение обслуживания. Для выполнения функций требуется читательский билет, информационная система библиотеки. 2. «Обслуживание клиента на автозаправочной станции» В процессе участвуют: клиент АЗС, заправщик и кассир, которые выполняют функции ознакомление с прайс-листом нефтепродуктов, выбор клиентом вида продукта, расчет стоимости заказа, если клиент согласен, то оплата заказа, заправка машины клиента в соответствии с его предпочтениями и параллельно оформление товарного чека. Если клиент не согласен со стоимостью, то либо повтор выбора, либо завершение обслуживания. Для выполнения функций требуется оборудование для заправки машин, нефтепродукты, касса, деньги, чек. 3. «Размещение клиента в гостинице» В процессе участвуют: администратор, клиент. Выполняемые функции: выслушать пожелания клиента, проверить наличие свободных номеров в соответствии с пожеланиями клиенты (одноместный, двухместный, полулюкс и т.п.), при наличии - заполнить регистрационную форму, оплатить услугу, зарегистрировать клиента. При отсутствии номеров в соответствии с пожеланиями клиента, предложить другие варианты номеров и перейти на заполнение регистрационной формы и далее либо завершить обслуживание клиента. Для выполнения функций требуется комплект документов, информационная система, деньги. Замечание Во всех вариантах Согласие клиента и несогласие клиента надо оформлять не действиями, а соответствующими надписями на стрелках, либо объектом ссылки ELAB/ Если клиент не согласен – предложение нового варианта Пожелания клиента 4.1.9 Х & & Х 4.1.8 4.1.11 J6 J3 J4 J5 Клиент не согласен Проверка наличия Клиент согласен 4.1.10 Конец занятия 19.03.21 След. занятие самостоятельная работа над диаграммой IDEF3 выбор варианта (придумать) не зачел Увольнение Николаева (нет входных и выходных стрелок) iDEF0 Яковлева (нет механизмов, кто будет делать) Лекция Диаграммы потоков данных (DFD) Возникновение диаграмм потоков данных Известен, пример использования прообраза DFD для реорганизации переполненного клерками офиса, относящийся к 20-м годам 20 века. Осуществлявший реорганизацию консультант обозначил кружком каждого клерка, а стрелкой - каждый документ, передаваемый между ними. Используя такую диаграмму, он предложил схему реорганизации, в соответствии с которой двое клерков, обменивающиеся множеством документов, были посажены рядом, а клерки с малым взаимодействием были посажены на большом расстоянии. Так родилась первая модель, представляющая собой потоковую диаграмму - предвестника DFD. Диаграммы потоков данных (DFD) DFD — общепринятое сокращение от англ. data flow diagrams — диаграммы потоков данных. DFD – это нотация, предназначенная для моделирования информационный систем с точки зрения хранения, обработки и передачи данных. Исторически синтаксис этой нотации применяется в двух вариантах — Йордана- Кода (Yourdon-Coad) и Гейна-Сарсона (Gane- Sarson). В системном анализе обычно используется нотация Йордана-Кода Задачи решаемые при DFD моделировании Нотация DFD может описывать любые действия, в том числе, процесс продажи или отгрузки товара, работу с заявками от клиентов или закупки материалов, с точки зрения описания системы. Эта нотация помогает понять, из чего должна состоять система, что нужно для автоматизации бизнес-процесса. Но DFD не является описанием непосредственно бизнес- процесса. Здесь, например, нет такого важного параметра, как время. Также в этой нотации не предусмотрены условия и «развилки». В DFD мы рассматриваем откуда появляются данные, какие данные нужны, их обработку и куда результаты отправить. Т.е. в этой нотации описывается не столько непосредственно процесс, сколько движение потоков данных. DFD можно использовать как дополнение к модели IDEF0 для более наглядного отображения текущих операций документооборота в корпоративных системах обработки информации. Пример. Заказ товара по телефону Видео Customer – покупатель; Ship Good – Доставка товара; D Customer – БД клиентов; Process Order – Обработка заказа; Issue Receipt – Выдача квитанции; D Transaction – БД Торговых операций; D Inventory – БД Склада; order Information – информация заказа; receipt – квитанция; updated product record - обновленная запись продукта; order details - подробные сведения о заказе Элементы DFD нотации Процесс (англ. Process) Функция или последовательность действий, которые нужно предпринять, чтобы данные были обработаны. Это может быть создание заказа, регистрация клиента и т.д. В названиях процессов принято использовать глаголы, т.е. «Создать клиента» (а не «создание клиента») или «обработать заказ» (а не «проведение заказа»). Внешние сущности (англ. External Entity) Это любые объекты, которые не входят в саму систему, но являются для нее источником информации либо получателями какой-либо информации из системы после обработки данных. Это может быть человек, внешняя система, какие- либо носители информации и хранилища данных. Хранилище данных (англ. Data store) Внутреннее хранилище данных для процессов в системе. Поступившие данные перед обработкой и результат после обработки, а также промежуточные значения должны где-то храниться. Это и есть базы данных, таблицы или любой другой вариант организации и хранения данных. Здесь будут храниться данные о клиентах, заявки клиентов, расходные накладные и любые другие данные, которые поступили в систему или являются результатом обработки процессов. Поток данных (англ. Data flow). В нотации отображается в виде стрелок, которые показывают, какая информация входит, а какая исходит из того или иного блока на диаграмме. Правила создания DFD диаграмм Каждый процесс должен иметь хотя бы один вход и один выход. Смысл процессов здесь заключается в обработке данных, а потому процесс должен получить данные (входящая стрелка) и отдать куда-то после обработки (исходящая стрелка); Процесс обработки данных должен иметь внешнюю входящую стрелку (данные от внешней сущности). Для того, чтобы любой подобный процесс начал работать, мало использовать данные из хранилища, должна поступить новая информация для последующей обработки; Стрелки не могут связывать напрямую хранилища данных, все связи идут через процессы. Нет смысла просто перемещать данные из одного места в другое, а именно так читается прямая связь двух хранилищ стрелкой. Данные поступают для того, чтобы производились какие-то действия, в нашем примере – осуществлялся процесс продажи. А это возможно только посредством обработки (процесса); Все процессы должны быть связаны либо с другими процессами, либо с другими хранилищами данных. Процессы не существуют сами по себе, а потому результат должен куда-то передаваться; Декомпозиция В DFD-диаграммах предусмотрена возможность создавать крупные процессы и декомпозировать их на подпроцессы с подробным описанием действий. Например, мы можем создать процесс «создание заявки» (Контекстная диаграмма или диаграмма нулевого уровня), который потом декомпозировать на последовательность действий. При этом ни на одном этапе у нас не будет условий и ветвления. Будет процесс и его декомпозиция глубиной до 3-4 уровней. Пример описания в нотации DFD Пример автоматизации продаж в нотации DFD Рассмотрим нотацию автоматизации продаж. Допустим, у нас есть клиент, который делает заявку через сайт или по телефону. Есть менеджер, который регистрирует эту заявку. Таким образом, в системе появляются данные – клиент и его заказ. Работник склада должен это увидеть и произвести отгрузку товара с оформлением всех необходимых документов и передать документы клиенту. Последовательность действий: 1. Клиент предоставляет свои данные и заявку. 2. Менеджер проверяет и вносит полученные данные в систему. 3. Работник склада формирует документы, например, расходную накладную, и отгружает товар. 4. Клиент получает товар и пакет документов к нему. С точки зрения DFD у нас имеются: – Покупатель – это внешняя сущность, которая является источником данных и получением результата. – Процесс обработки заказа (подтверждение и проводка данных в системе менеджером). – Сбор заказа на складе (после получения заявки). – Оформление отгрузки (создание необходимых документов). Диаграмма DFD (без декомпозиции, верхний уровень) Декомпозиция основного элемента диаграммы Применение DFD нотаций DFD-диаграммы активно применяются при разработке программного обеспечения. При этом: – хранилища данных – это электронные таблицы и базы данных, – внешние сущности – клиенты или другие базы данных, в том числе, из других программ (интеграция и обмен данными), – процессы – это выполняемые функции и модули в системе. Также DFD нотации удобны при анализе, когда система рассматривается с точки зрения документооборота. При этом можно наглядно увидеть, где хранятся данные, каким образом производится обмен документацией, где в этом процессе допущены ошибки организации бизнес-процессов и пр. DFD-нотация помогает выявить, например, отсутствие в системе автоматизации важных документов, которые на самом деле создаются (на бумаге), но в системе никак не отображаются. Видео Задание Разработать DFD диаграмму «Ответ курсанта на экзамене»