Построение информационной модели предприятия пищевой промышленности АНО «Центр интернет-образования»

Содержание Введение

1. Функциональное моделирование IDEF0

2. Функциональное моделирование IDEF1Х

Заключение

Список использованных источников

Приложение А (обязательное) скриншоты программы

Введение

Цель данного отчета — построение информационной модели предприятия пищевой промышленности АНО «Центр интернет-образования». Для достижения поставленной цели необходимо решить следующие задачи:

а) проанализировать и описать предметную область;

б) построить модели процессов предметной области в стандарте IDEF0;

в) построить модели процессов предметной области в стандарте IDEF1Х.

IDEF — методологии создавались в рамках предложенной ВВС США программы компьютеризации промышленности — ICAM, в ходе реализации которой выявилась потребность в разработке методов анализа процессов взаимодействия в производственных (промышленных) системах. Принципиальным требованием при разработке рассматриваемого семейства методологий была возможность эффективного обмена информацией между всеми специалистами — участниками программы ICAM (отсюда название: Icam DEFinition — IDEF другой вариант — Integrated DEFinition). После опубликования стандарта он был успешно применен в самых различных областях бизнеса, показав себя эффективным средством анализа, конструирования и отображения бизнес-процессов. Более того, собственно с широким применением IDEF (и предшествующей методолoгии — SADT) и связано возникновение основных идей популярного ныне понятия — BPR (бизнес-процесс реинжиниринг).

IDEF0 Function Modeling — методология функционального моделирования. С помощью наглядного графического языка IDEF0 изучаемая система предстает перед разработчиками и аналитиками в виде набора взаимосвязанных функций (функциональных блоков — в терминах IDEF0). Как правило, моделирование средствами IDEF0 является первым этапом изучения любой системы. Методологию IDEF0 можно считать следующим этапом развития хорошо известного графического языка описания функциональных систем SADT (Structured Analysis and Design Technique). При проведении сложных проектов обследования предприятий, разработка моделей в стандарте IDEF0 позволяет наглядно и эффективно отобразить весь механизм деятельности предприятия в нужном разрезе.

IDEF1X Information Modeling — методология моделирования информационных потоков внутри системы, позволяющая отображать и анализировать их структуру и взаимосвязи. IDEF1X (IDEF1 Extended) — Data Modeling — методология моделирования баз данных на основе модели «сущность-связь». Применяется для построения информационной модели, которая представляет структуру информации, необходимой для поддержки функций производственной системы или среды. Метод IDEF1, разработанный Т. Рэмей (T. Ramey), также основан на подходе П. Чена и позволяет построить модель данных, эквивалентную реляционной модели в третьей нормальной форме. В настоящее время на основе совершенствования методологии IDEF1 создана ее новая версия — методология IDEF1X. IDEF1X разработана с учетом таких требований, как простота изучения и возможность автоматизации. IDEF1X-диаграммы используются рядом распространённых CASE-средств (в частности, ERwin, Design/IDEF). Существует несколько очевидных причин, по которым IDEF1X не следует применять в случае построения нереляционных систем. Во-первых, IDEF1X требует от проектировщика определить ключевые атрибуты, для того чтобы отличить одну сущность от другой, в то время как объектно-ориентированные системы не требуют задания ключевых ключей, в целях идентифицирования объектов. Во-вторых, в тех случаях, когда более чем один атрибут является однозначно идентифицирующим сущность, проектировщик должен определить один из этих атрибутов первичным ключом, а все остальные вторичными. И, таким образом, построенная проектировщиком IDEF1X-модель и переданная для окончательной реализации программисту является некорректной для применения методов объектно-ориентированной реализации, и предназначена для построения реляционной системы. 1]

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

Отдел техподдержки занимается консультациями клиентов по настройкам интернет соединения.

Процесс планирования работы отдела в целом невозможен без подготовки производственной программы и оперативного планирования. Данные задачи входят в обязанности старшего специалиста.

1. Функциональное моделирование IDEF0

Цель разработки модели — описание всех процессов работы отдела техподдержки.

Вопросы, которые ставятся перед данной моделью:

а) как происходит заключение договоров;

б) как происходит планирование производства;

в) как ведется учет сведений о ходе производства.

Возможные точки зрения: специалист, старший специалист. В качестве точки зрения для моделирования выбирается точка зрения специалист, т.к. она включает в себя точку зрения клиента. И деятельность этой точки зрения способна ответить на все поставленные вопросы. Данный вывод можно сделать потому что:

а) специалист консультирует клиентов;

б) специалист проводит операции с договором клиента;

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

Границы модели: рассматривается от первичной диагностики до перевода звонка на другой отдел.

Рисунок 1 — Контекстная диаграмма А-0

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

Она представляет собой основной процесс предметной области, который рассматривается как совокупность нескольких процессов: первичная диагностика, поиск решения технической/финансовой проблемы, перевод звонка на другой отдел.

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

Процесс организации работы отдела техподдержки можно представить как организацию трех последовательных процессов:

Первичная диагностика;

Поиск решения технической/финансовой проблемы;

Перевод звонка на другой отдел.

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

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

Рисунок 3 — Декомпозиция процесса «Первичная диагностика»

На рисунке 3 представлена декомпозиция процесса «Первичная диагностика».

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

Рисунок 4 — Декомпозиция процесса «Планирование производства»

На рисунке 4 представлена декомпозиция процесса «Поиск решения технической/финансовой проблемы». Данная декомпозиция показывает сам ход полной диагностики проблемы клиента. В начале специалист предлагает самые стандартные виды решения проблемы. Если они не помогают, то специалист записывает все действия, которые произвел с клиентом и дальше выбирает ветку проблемы с клиентом (финансовую/техническую). Затем более подробно консультирует клиента по его проблемы и предлагает всевозможные методы решения. После этого оформляется финанльный отчет. В случае если проблемы решена заявка клиента закрывается. Если нет создается новая заявка в которой описаны в подробностях все действия которые специалист произвел с абонентом и отправляется в другой отдел

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

информационная модель контекстная диаграмма

2. Функциональное моделирование IDEF1Х Рисунок 5 — IDEF1x модель На рисунке 5 представлена IDEF1x модель. IDEF1X является методом для разработки реляционных баз данных и использует условный синтаксис, специально разработанный для удобного построения концептуальной схемы. Сущность в IDEF1X описывает собой совокупность или набор экземпляров похожих по свойствам, но однозначно отличаемых друг от друга по одному или нескольким признакам.

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

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

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

Заключение

В ходе выполнения отчета были решены следующие задачи:

а) проанализирована предметная область;

в) построены модели процессов предметной области в стандарте IDEF0;

г) построены модели процессов предметной области в стандарте IDEF1Х;

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

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

Улучшение уровня конкурентоспособности отдела и компании в целом можно обеспечить повышением квалификации специалистов и увеличением штата сотрудников.

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

Список использованных источников

1 Подоляка О. И. Практичные решения для эффективного управления компанией / О. И. Подоляка — Мусы, 2003.

2 Ехлаков Ю. П. Теоретические основы автоматизированного управления [Текст] / Ю. П. Ехлаков — Томск: ТГУ СУ и Р, 2001 — 337 с.

3 Калянов Г. Н. CASE-технологии. Консалтинг при автоматизации бизнес-процессов [Текст] / Г. Н. Калянов — 2-е изд. перераб. и доп. — М.: Горячая линия — Телеком, 2000 — 320 с.

4 Олькина Е. В. Методические указания по оформлению пояснительных записок к дипломным, курсовым проектам (работам) и отчетов по практикам в соответствии с требованиями государственных стандартов [Текст] / Олькина Е. В. — Орел: ОрелГТУ, 2007.

5 Вендров А. М Case-технологии. Современные методы и средства проектирования информационных систем / А. М. Вендров. — М: Финансы и статистика, 1998. — 176с. — 12 000экз. — ISBN: 5 279 019 798.

6 Дубейковский В. И Практика функционального моделирования с AllFusion Process Modeler 4.1. (BPwin) Где? Зачем? Как? [Текст] / В. И. Дубейковский. — М: Диалог-МИФИ, 2004. — 464с. — 3000экз. — Код 5−86 404−192−0

7 Глазунов Ю. Т. Моделирование процессов пищевых производств. Учебное пособие / Ю. Т. Глазунов — Колос, 2008 г.

8. Ивлев В. А., Попова Т. В. Что такое функционально-стоимостной анализ процессов и систем. Вып. 4. / В. А. Ивлев, Попова Т. В. — М.: ИздАТ, 2000. — С. 169 — 188).

Приложение А

(обязательное) Скриншоты программы Рисунок 6 — Скриншот программы На данном рисунке показан интерфейс программы контроля трафика. Интерфейс поделен на 3 отсека. Первый, где происходит добавление сеанса. Здесь необходимо заполнить все необходимые поля. Второй отсек показывает информацию об уж существующих сеансах. И третий отсек это календарь где выбираются нужный день для просмотра трафика клиента в этот день.

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

Рисунок 8 — Скриншот программы На данном скриншоте показан верный способ добавления и вноса данных в программу. После заполнения всех полей необходимо внести данные и закрепить за определенным днем в календаре. Сеансы можно так же редактировать и удалять.