Разработка модели предприятия тепличного хозяйства, используя методологии проектирования IDEF0, DFD

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

:

 

Содержание

 

1. Цель работы
2. . Описание предметной области
3. ОписаниеBPwin
4. Принцип построения модели IDEF0
5. Принцип построения модели DFD
6. Принцип построения модели IDEF3
7. Моделирование
8. Модель тепличного хозяйства
9. Математическая модель
10. Сравнительный анализ
11. 6 Методологии
12. Сравнение инструментальных средств
13. 7. Вывод

Литература

 

 

 

 

 

 

 

 

 

 

 

 

 

 

1. Цель работы

 

Целями данной курсовой работы были:

• применение методов предпроектного обследования предприятия;
• анализ полученных материалов для последующего моделирования;
• разработка модели процесса в стандартеIDEF0;
• описание документооборота и обработки информации в стандарте DFD;
• описания процессов в стандартеIDEF3;
• разработка смешанной модели описания процесса на основе стандартов IDEFO, DFD иIDEF3.
• создание сценариев работы предприятия;
• построение структурной схемы предприятия;
• создание математической модели данного предприятия.
• сравнительный анализ

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

.

2. Описание предметной области

 

Для рассмотрения в данной курсовой работе было взято за основу работа тепличного хозяйства. Это предприятие  специализируется на выращивании сельскохозяйственных культур. Реализация продукции производится по заявке заказчика.

Организация работы осуществляется по следующей схеме:

 

 

 

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

Во главе всего предприятия  стоит руководство, в лице начальника и его заместителя. Их основной функцией является контроль деятельности предприятия.

Далее идут основные отделы и службы предприятияСлужба охраны труда, основная функция которого подготовка персонала;

Бухгалтерский отдел занимается документооборотом;

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

Сектор технического обслуживания, занимается ремонтными работами.Отделы, службы и рабочие места данного предприятия представлены в таблице №1:

таблица №1

 

Задачи и функции нашего тепличного хозяйства показаны в таблице  №2:

 

Таблица №2

 

 

Документация представлена в таблицах№3:

 

таблица №3

 

Справочник организаций представлен в таблице №4:

 

таблица №4

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

Схема сценария работы предприятия

3. Описание BPwin

 

BPwin относится к малым интегрированным  средствам моделирования, которые поддерживают несколько типов моделей и методов.

Для проведения анализа и реорганизации  бизнес-процессовLogic Works предлагаетCASE-средство верхнего уровня- BPwin, поддерживающее методологииIDEF0 (функциональная модель), IDEF3 (WorkFlow Diagram)и DFD (DataFlow Diagram). Основной из трех методологий, является IDEF0. BPwin имеет достаточно простой и интуитивно понятный интерфейс пользователя, дающий возможность аналитику создавать сложные модели при минимальных усилиях.

BPwin автоматизирует задачи, связанные  с построением моделей развития, обеспечивая семантическую строгость, необходимую для гарантирования правильности и непротиворечивости результатов. Это достигается применением в BPwin следующих методологий:IDEF0, DFD и IDEF3.

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

В BPwin возможно построение смешанных  моделей, т. е.модель может содержать  одновременно как диаграммы IDEFO, так и IDEF3и DFD. Модель в BPwin рассматривается как совокупность работ, каждая из которых оперирует с некоторым набором данных.Работа изображается в виде прямоугольников, данные – в виде стрелок.

Все работы модели нумеруются. Номер состоит из префикса и числа. Может быть использован префикс любой длины, но обычно используют префикс А.Контекстная(корневая) работа дерева имеет номер А0. Работа декомпозиции А0 имеет номера Al, A2, A3 и т.д. Работы декомпозиции нижнего уровня имеют номер родительской работы и очередной порядковый номер, например работы декомпозицииA3 будут иметь номера А3.1 А3.2,АЗ.З, А3.4 и т. д.

В результате дополнения диаграмм, IDEFO диаграммами DFD и IDEF3может быть создана смешанная модель, которая наилучшим образом описывает все стороны деятельности предприятия. Иерархию работ смешанной модели можно увидеть в окнеModel Explorer.Работы в нотацииIDEFO изображаются зеленым цветом,DFD – синим.

BPwin так же как и локальные  интегрированные системы, практически  не позволяют выполнить комплексный  анализ систем,который в большей  или меньшей степени необходим  для создания малых, средних  и крупных ИСУП.С их помощью  можно разрабатывать локальные ИС или небольшие подсистемы,предназначенные для автоматизации отдельных бизнес-цепочек,т. е. когда нет необходимости в комплексном анализе предприятия.Типичная сфера использования малых интегрированных средств — решение задач так называемой“кусочной”автоматизации предприятия.

 

 

4. Принцип построения модели IDEFO

 

Основу методологии IDEFO составляет графический язык описания бизнес-процессов. Модель в нотации IDEFO представляет собой совокупность иерархически упорядоченных и взаимосвязанных диаграмм. Каждая диаграмма является единицей описания системы и располагается на отдельном листе.

IDEFO-модель  предполагает наличие четко сформулированной  цели единственного субъекта  моделирования и одной точки  зрения.

Модель  может содержать четыре типа диаграмм:

контекстную диаграмму (в каждой модели может быть только одна контекстная диаграмма);

диаграммы декомпозиции;

диаграммы дерева узлов;

диаграммы только для экспозиции(FEO).

Контекстная диаграмма является вершиной древовидной  структуры диаграмм и представляет собой самое общее описание системы и ее взаимодействия с внешней средой.

Этот  процесс называется функциональной декомпозицией, а диаграммы, которые описывают каждый фрагмент и взаимодействие фрагментов, называются диаграммами декомпозиции.

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

верхняя сторона имеет значение"управления";

левая - "входа";

правая - "выхода";

нижняя -"механизма".

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

Изобразительным элементом, представляющим"поток", является стрелка.

Управление— это что управляет деятельностью бюро, в данной разрабатываемой модели — это законы об индивидуальном ПУ.

Стрелки"входа" вносят функции  входных данных, в контекстной  диаграмме –это персональные данные работника.

Стрелки"выхода" –выходные данные.В  контекстной диаграмме –это различные сведения, которые подаются в Пенсионный фонд РФ.

Стрелка"механизма"— это влияющие на процессы данные. В диаграмме– это  персонал и ПК.

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

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

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

Все перекрестки на диаграмме нумеруются, каждый номер имеет префикс J. Можно редактировать свойства перекрестка при помощи диалога Definition Editor.

 

4.2 Принцип построения  модели DFD

 

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

Для изображения DFD традиционно используются две различные нотации: Йодана(Yourdon) и Гейна-Сарсона(Gane-Sarson). Далее при построении примеров будет использоваться нотация Йодана, все исключения будут предварительно оговариваться.

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

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

внешние сущности;

системы/подсистемы;

процессы;

накопители данных;

потоки данных.

 

5. Принцип построения модели IDEF3

 

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

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

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

Перекрестки(Junction). Окончание одной работы может служить сигналом к началу нескольких работ или же одна работа для своего запуска может ожидать окончания нескольких работ. Перекрестки используются для отображения логики взаимодействия стрелок при слиянии и разветвлении или для отображения множества событий, которые могут или должны быть завершены перед началом следующей работы. Типы перекрёстков представлены в табл.:

 

Типы перекрестков

 

Обозначение	Наименование	Смысл в случае слияния стрелок (Fan-in Junction)	Смысл в случае разветвления стрелок (Fan-out Junction)
||&	Asynchronous AND	Все предшествующие процессы должны быть завершены	Все следующие процессы должны быть запущены
||&||	Synchronous AND	Все предшествующие процессы завершены  одновременно	Все следующие процессы запускаются  одновременно
||O	Asynchronous OR	Один или несколько предшествующих процессов должны быть завершены	Один или несколько следующих  процессов должны быть запущены
||O||	Synchronous OR	Один или несколько предшествующих процессов завершены одновременно	Один или несколько следующих  процессов запускаются одновременно
||X	XOR (Exclusive OR)	Только один предшествующий процесс завершен	Только один следующий процесс  запускается