Глава 2 Разработка функциональной структуры деятельности компании «ТУНДРА»

Министерство образования и науки Российской Федерации

Федеральное государственное автономное образовательное учреждение

высшего образования

«Северо-Восточный федеральный университет имени М.К. Аммосова»

Институт математики и информатики

Кафедра математической экономики и прикладной информатики

 

 КУРСОВОЙ ПРОЕКТ

по дисциплине «Проектирование ИС» на тему:

ФУНКЦИОНАЛЬНОЕ МОДЕЛИРОВАНИЕ ДЕЯТЕЛЬНОСТИ ТРАНСПОРТНОЙ КОМПАНИИ «ТУНДРА»

Направление подготовки: 09.03.03 Прикладная информатика

Профиль: Прикладная информатика в государственном и муниципальном управлении

 

 

Выполнил: студент 3 курса группы БА-ПИ-17-2 ИМИ СВФУ	_____________________ подпись, дата	С.А. Стручков
Проверила: ст.преп. кафедры МЭПИ ИМИ СВФУ	_____________________ подпись, дата	И.И. Панова

 

Якутск 2019

СОДЕРЖАНИЕ

Введение. 3

ГЛАВА 1 Методологии функционального моделирования. 4

1.1 Методология IDEF0. 4

1.3 Методология DFD.. 14

глава 2 Разработка функциональной структуры деятельности компании «ТУНДРА». 21

2.1 Транспортная Компания Тундра. 21

2.2 Моделирование деятельности компании «Тундра». 22

Заключение. 33

Список использованных источников и литературы.. 34

 

 

Введение

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

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

Какова функциональная модель транспортной компании?

Целью данной работы является построение функциональной модели деятельности транспортной компании Тундра.

Задачи:

· Изучить деятельность компании Тундра;

· Рассмотреть основные функции и услуги компании;

· Построить функциональную модель деятельности транспортной компании Тундра.

 

ГЛАВА 1 Методологии функционального моделирования

Методология IDEF0

IDEF0 — методология функционального моделирования (англ. function modeling) и графическая нотация, предназначенная для формализации и описания бизнес-процессов. Отличительной особенностью IDEF0 является её акцент на соподчинённость объектов. В IDEF0 рассматриваются логические отношения между работами, а не их временная последовательность (поток работ).

Стандарт IDEF0 был разработан в 1981 году в США департаментом Военно-воздушных сил для автоматизации промышленных предприятий. В процессе разработки программного обеспечения разработчики столкнулись с необходимостью разработки новых методов анализа бизнес-процессов. В результате появилась методология функционального моделирования IDEF0, в которой для анализа применяются специальные нотации IDEF0.

Функциональная модель IDEF0 представляет собой набор блоков, каждый из которых представляет собой «чёрный ящик» со входами и выходами, управлением и механизмами, которые детализируются (декомпозируются) до необходимого уровня. Наиболее важная функция расположена в верхнем левом углу. А соединяются функции между собой при помощи стрелок и описаний функциональных блоков. При этом каждый вид стрелки или активности имеет собственное значение. Данная модель позволяет описать все основные виды процессов, как административные, так и организационные.

Стрелки могут быть:

· Входящие – вводные, которые ставят определённую задачу.

· Исходящие – выводящие результат деятельности.

· Управляющие (сверху вниз) – механизмы управления (положения, инструкции и пр.).

· Механизмы (снизу-вверх) – что используется для того, чтобы произвести необходимую работу.

Входящие и исходящие стрелки точнее было бы называть вводящими и выводящими, так как по-английски они называются Input и Output соответственно. Но особенности перевода и привычные названия выглядят уже так, как сложилось. И все же для правильного понимания терминов важно помнить их значение в данном случае. Это подтверждается ещё и тем, что данная нотация создана прежде всего для разработки ПО, и термины переводить правильнее в этой точки зрения.

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

IDEF0 – это очень простой и одновременно наглядный язык описания бизнес-процессов. С помощью этого стандарта возможна передача информации между разработчиками, консультантами и пользователями. Стандарт очень тщательно разрабатывался, он удобен для проектирования, универсален. Для работы с ним существует множество инструментов, например, VISIO, BPWIN, ERWIN, Bussines studio и т.д.

Кроме того, использование для создания бизнес-моделей IDEF0 — это не только удобно, это ещё и правильно. Этот инструмент был разработан для бизнес-аналитики, он прошёл длительную и тщательную отладку и шлифовку. А потому при помощи IDEF0 создать функциональную модель без ошибок намного проще, чем без применения этого стандарта.

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

Для того чтобы понять, как работать с функциональным моделированием, я приведу пример процесса написания статьи.

Основной блок – «Написать статью».

Рисунок 1 - Пример описания функциональной модели верхнего уровня

Входящие стрелки – «Опыт», «Информация из сторонних источников». Это те вводные, которые необходимы для начала работы.

Управляющие для написания статьи – это «План публикации», «Требования издателя», «Правила русского языка».

А в роли «Механизмов» выступают автор, копирайтер, корректор и программное обеспечение. В данном случае автор создаёт аудиоматериал, в котором собирает все мысли и идеи, которые должны быть отражены в статье. Копирайтер – это человек, который создаёт на основе этого материала, руководствуясь требованиями издателя, планом публикации и правилами русского языка, готовый текст статьи. Корректор проверяет материал на ошибки. А программное обеспечение – это те инструменты, которые используют в работе все участники процесса.

Таким образом, я задал основные параметры процесса, его вход, выход, а также все необходимое для успешного проведения процесса. Но это – только основные рамки процесса. Так описывается общая схема работы компании в целом.

На самом деле, процесс создания статьи, как и любой бизнес-процесс можно и нужно детализировать. Для этого я декомпозирую общий блок «написать статью» на связанные между собой элементы.

В нашем случае работа делится на 4 основных этапа:

· Подготовить аудио.

· Подготовить текст

· Подготовить текст к публикации.

· Разместить статью в издании.

Рисунок 2 - Пример описания функциональной модели бизнес процесса второго уровня

На схеме наглядно видно, на каком этапе какие управляющие элементы и какие механизмы задействованы.

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

При создании функциональной модели ключевыми параметрами являются цель и точка зрения. Исходя из них, моделирование одних и тех же процессов может выглядеть несколько по-разному. Например, в моем случае целью является «рассказать о процессе написания статьи». А точка зрения копирайтера – это «написание и публикация статьи с точки зрения руководителя процесса».

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

Такое моделирование не только наглядно, но и очень удобно для принятия эффективных управленческих решений.

 

1.2 Методология IDEF3

IDEF3 — важнейшая после IDEF0 и предназначена для описания потоков работ (Work Flow Modeling). IDEF3 является технологией, хорошо приспособленной для сбора данных, требующихся для проведения структурного анализа системы.

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

Рисунок 3 -  Описание процесса в методологии IDEF3

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

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

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

Аналогично другим технологиям моделирования действие, или в терминах IDEF3 «единица работы» (Unit of Work — UOW), — другой важный компонент модели. Диаграммы IDEF3 отображают действие в виде прямоугольника. Как уже отмечалось, действия именуются с использованием глаголов или отглагольных существительных, каж­дому из действий присваивается уникальный идентификационный номер. Этот номер не используется вновь даже в том случае, если в процессе построения модели действие удаляется. В диаграммах IDEF3 номер действия обычно предваряется номером его родителя (рис. 4)

Рисунок 4 - Изображение и нумерация действия в диаграмме IDEF3

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

Таблица 1 – Типы связей

Изобра­жение	Название	Назначение
	Временное предшест­вование (Temporal pre­cedence)	Исходное действие должно завершить­ся, прежде чем конечное действие смо­жет начаться
	Объектный поток (Object flow)	Выход исходного действия является входом конечного действия. Из этого, в частности, следует, что исходное действие должно завершиться, прежде чем конечное действие сможет начаться
	Нечёткое отношение (Relationship)	Вид взаимодействия между исходным и конечным действиями задаётся анали­тиком отдельно для каждого случая ис­пользования такого отношения

Завершение одного действия может инициировать начало выпол­нения сразу нескольких других действий или, наоборот, определённое действие может требовать завершения нескольких других действий до начала своего выполнения. Соединения разбивают или соединяют внутренние потоки и используются для описания ветвления процесса:

· разворачивающие соединения используются для разбиения пото­ка. Завершение одного действия вызывает начало выполнения не­скольких других;

· сворачивающие соединения объединяют потоки. Завершение од­ного или нескольких действий вызывает начало выполнения другого действия.

В табл. 2 приведены три типа соединений.

Таблица 2 – Типы соединений

Графическое обозначение	Название	Вид	Правила инициации
	Соединение «и»	Разворачи­вающее	Каждое конечное действие обяза­тельно инициируется
		Сворачи­вающее	Каждое исходное действие обяза­тельно должно завершиться
	Соединение «эксклюзивное "или"»	Разворачи­вающее	Одно и только одно конечное дей­ствие инициируется
		Сворачи­вающее	Одно и только одно исходное дей­ствие должно завершиться
	Соединение «или»	Развора­чивающее	Одно или несколько конечных действий инициируются
		Сворачи­вающее	Одно или несколько исходных действий должны завершиться

Примеры разворачивающих и сворачивающих соединений приведены на рис.5.

Рисунок 5 - Два вида соединений

«И»-соединения. Соединения этого типа инициируют выполнение конечных действий. Все действия, присоединённые к сворачивающему «и»-соединению, должны завершиться, прежде чем начнётся выполнение следующего действия.

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

Рисунок 6 - “И”-соединения

Соединение «эксклюзивное "или"». Вне зависимости от количест­ва действий, связанных со сворачивающим или разворачивающим соединением «эксклюзивное «или», инициировано будет только одно из них, и поэтому только оно будет завершено перед тем, как любое действие, следующее за сворачивающим соединением «эксклюзивное «или», сможет начаться. Если правила активации соединения известны, они обязательно должны быть документированы либо в его описа­нии, либо пометкой стрелок, исходящих из разворачивающего соединения, как показано на рис.7.

Рисунок 7 - Соединение «эксклюзивное “или”

На рис.7 соединение «эксклюзивное «или» используется для отображения того факта, что студент не может одновременно быть на­правлен на лекции по двум разным курсам.

Соединение «или» предназначено для описания ситуаций, которые не могут быть описаны двумя предыдущими типами соединений.

Указатели — это специальные символы, которые ссылаются на другие разделы описания процесса. Они используются при построе­нии диаграммы для привлечения внимания пользователя к каким-ли­бо важным аспектам модели.

Указатель изображается на диаграмме в виде прямоугольника, похожего на изображение действия. Имя указателя обычно включает его тип (например, ОБЪЕКТ, UOB и т.п.) и идентификатор (табл. 3).

Таблица 3 – Указатели

Тип указателя	Назначение
ОБЪЕКТ (OBJECT)	Для описания того, что в действии принимает участие какой-либо заслуживающий отдельного внимания объект
ССЫЛКА (GOTO)	Для реализации цикличности выполнения действий. Ука­затель ССЫЛКА может относиться и к соединению
ЕДИНИЦА ДЕЙ­СТВИЯ (Unit of Behavior — UOB)	Для многократного отображения на диаграмме одного и того же действия. Например, если действие «Подсчёт наличных» выполняется несколько раз, в первый раз оно создаётся как действие, а последующие его появления на диаграмме оформляются указателями UOB
ЗАМЕТКА (NOTE)	Для документирования любой важной информации обще­го характера, относящейся к изображённому на диаграм­мах. В этом смысле ССЫЛКА служит альтернативой методу помещения текстовых заметок непосредственно на диаграммах
УТОЧНЕНИЕ (Ela­boration — ELAB)	Для уточнения или более подробного описания, изображённого на диаграмме. Указатель УТОЧНЕНИЕ обычно используется для описания логики ветвления у соеди­нений

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

Для корректной идентификации действий в модели с множествен­ными декомпозициями схема нумерации действий расширяется и наряду с номерами действия и его родителя включает в себя порядко­вый номер декомпозиции. Например, в номере действия 1.2.5: 1 — но­мер родительского действия, 2 — номер декомпозиции, 5 — номер действия.

 

Методология DFD

DFD — общепринятое сокращение от англ. data flow diagrams — диаграммы потоков данных. Так называется методология графического структурного анализа, описывающая внешние по отношению к системе источники и адресаты данных, логические функции, потоки данных и хранилища данных, к которым осуществляется доступ.

Диаграмма потоков данных (data flow diagram, DFD) — один из основных инструментов структурного анализа и проектирования информационных систем, существовавших до широкого распространения UML. Несмотря на имеющее место в современных условиях смещение акцентов от структурного к объектно-ориентированному подходу к анализу и проектированию систем, «старинные» структурные нотации по-прежнему широко и эффективно используются как в бизнес-анализе, так и в анализе информационных систем.

Исторически синтаксис этой нотации применяется в двух вариантах — Йордана (Yourdon) и Гейна-Сарсона (Gane-Sarson). Различия между ними – на рис.8.

Рисунок 8 – Различие синтаксиса

Нотации DFD — удобный инструмент для создания нерегламентированных диаграмм, которые можно сделать быстро и с максимумом свободы.

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

· Из чего состоит информационная система?

· Что нужно, чтобы обработать информацию?

Непосредственно DFD нотация состоит из следующих элементов:

· Процесс (англ. Process), т.е. функция или последовательность действий, которые нужно предпринять, чтобы данные были обработаны. Это может быть создание заказа, регистрация клиента и т.д. В названиях процессов принято использовать глаголы, т.е. «Создать клиента» (а не «создание клиента») или «обработать заказ» (а не «проведение заказа»). Здесь нет строгой системы требований, как, например, в IDEF0 или BPMN, где нотации имеют жёстко определённый синтаксис, так как они могут быть исполняемыми. Но все же определённых правил стоит придерживаться, чтобы не вносить путаницу при чтении DFD другими людьми.

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

· Хранилище данных (англ. Data store). Внутреннее хранилище данных для процессов в системе. Поступившие данные перед обработкой и результат после обработки, а также промежуточные значения должны где-то храниться. Это и есть базы данных, таблицы или любой другой вариант организации и хранения данных. Здесь будут храниться данные о клиентах, заявки клиентов, расходные накладные и любые другие данные, которые поступили в систему или являются результатом обработки процессов.

· Поток данных (англ. Data flow). В нотации отображается в виде стрелок, которые показывают, какая информация входит, а какая исходит из того или иного блока на диаграмме.

Нотация DFD может описывать любые действия, в том числе, процесс продажи или отгрузки товара, работу с заявками от клиентов или закупки материалов, с точки зрения описания системы. Эта нотация помогает понять, из чего должна состоять система, что нужно для автоматизации бизнес-процесса. Но DFD не является описанием непосредственно бизнес-процесса. Здесь, например, нет такого важного параметра, как время. Также в этой нотации не предусмотрены условия и «развилки». В DFD мы рассматриваем откуда появляются данные, какие данные нужны, их обработку и куда результаты отправить. Т.е. в этой нотации описывается не столько непосредственно процесс, сколько движение потоков данных.

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

Последовательность получается такая:

· Клиент предоставляет свои данные и заявку.

· Менеджер проверяет и вносит полученные данные в систему.

· Работник склада формирует документы, например, расходную накладную, и отгружает товар.

· Клиент получает товар и пакет документов к нему.

Эту последовательность действий нам необходимо увидеть с точки зрения хранения данных и работы с ними в IT-системе.

С точки зрения DFD у нас имеются:

· Покупатель – это внешняя сущность, которая является источником данных и получением результата.

· Процесс обработки заказа (подтверждение и проводка данных в системе менеджером).

· Сбор заказа на складе (после получения заявки).

· Оформление отгрузки (создание необходимых документов).

Какие правила необходимо знать, чтобы создать DFD диаграмму:

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

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

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

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

· Декомпозиция. В DFD-диаграммах предусмотрена возможность создавать крупные процессы и декомпозировать их на подпроцессы с подробным описанием действий. Например, мы можем создать процесс «создание заявки», который потом декомпозировать на последовательность действий, например, на получение заявки, отдельно – проверку и получение данных клиента, если товар в интернет-магазине продаётся под заказ, то также при формировании заявки потребуется получить данные от поставщика о наличии нужных наименований и т.д. И тогда на верхней диаграмме у нас будет блок «обработка заявки», а при декомпозировании мы получим диаграмму с подробной последовательностью действий на этом этапе. При этом ни на одном этапе у нас не будет условий и ветвления. Будет процесс и его декомпозиция глубиной до 3-4 уровней.

 

Рисунок 9 - Диаграмма (без декомпозиции, верхний уровень)

Рисунок 10 - Декомпозиция основного элемента нашей диаграммы

DFD-диаграммы активно применяются при разработке программного обеспечения. При этом:

· хранилища данных – это электронные таблицы и базы данных,

· внешние сущности – клиенты или другие базы данных, в том числе, из других программ (интеграция и обмен данными),

· процессы – это выполняемые функции и модули в системе.

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

Например, для выявления проблем документооборота, дублирования документов или, наоборот, недостающей документации или электронных данных в системе, очень удобно создать отдельно – описание бизнес-процесса, а потом к нему – DFD-нотацию. Либо наоборот, предварительно для понимания основ работы бизнеса и особенностей реализации документооборота создаётся DFD-нотация. Она помогает выявить, например, отсутствие в системе автоматизации важных документов, которые на самом деле создаются (на бумаге), но в системе никак не отображаются. А потом уже строится оптимизированный бизнес-процесс с учётом выявленных нюансов документооборота.

 

глава 2 Разработка функциональной структуры деятельности компании «ТУНДРА»

Транспортная Компания Тундра

Транспортная Компания Тундра - профессионально осуществляет доставку сборных грузов по городам России, Белоруссии, Казахстана, Киргизии, Армении, Китая, ДНР, ЛНР и Европы. Перевозит грузы любых габаритов, массой от нескольких грамм до 20 тонн.

· Работает с 2004 года.

· 492 терминала «Тундра» по городам.

· 600 грузовых машин.

· 4500 сотрудников в организации.

· 35000 населённых пунктов в логической сети

Рисунок 11 – Организационная схема компании «Тундра»

Функции компании «Тундра»:

· Организация междугородных грузоперевозок с использованием, автомобильного транспорта;

· Осуществление контроля над всеми этапами по доставке груза;

· Выполнение задач грузоперевозки точно в установленные сроки;

· Обеспечение надёжности и безопасности грузоперевозок.

Цель транспортной компании «Тундра» - быть лидером в предоставления современных транспортно-экспедиционных услуг на международном уровне.

 

---

Дата добавления: 2020-12-22; просмотров: 238; Мы поможем в написании вашей работы!

Поделиться с друзьями:

---

---

Мы поможем в написании ваших работ!