IX Международная студенческая научная конференция Студенческий научный форум - 2017

Введение

За последние двадцать лет значительно возрос объём и оборот информации во всех сферах жизнедеятельности человека: экономической, финансовой, политической, духовной. И процесс накопления, обработки и использования знаний постоянно ускоряется. Учёные утверждают, что каждые десять лет количество информации увеличивается вдвое. В связи с этим возникает необходимость использования автоматических средств, позволяющих эффективно хранить, обрабатывать и распределять накопленные данные.

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

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

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

Целью данной работы является разработка АРМа менеджера по закупкам. Из всех задач, решаемых данной работой, можно выделить ряд основных задач, необходимость которых обязательна для любой информационной системы подобного рода. К таким задачам относятся:

· Учет товара, поступающего на склад;

· Учет товара, отгруженного со склада;

· Возможность постоянного контроля состояния склада;

· Формирование необходимой документации;

· Прогнозирование закупок материалов на определенный период.

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

Глава 1. Теоретическая часть. 1.1. Формализация процесса проектирования АРМ менеджера по снабжению.

Ключевыми задачами отдела снабжения предприятия являются (Рис.1):

 стратегическое управление

 анализ финансовых КПЭ (Ключевые Показатели Эффективности)

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

 долгосрочное планирование

 основные функции по сбору и анализу производственных КПЭ

 оперативное планирование и контроль доставки согласно заявок

Рис.1 Структура отдела снабжения

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

1.2. Применения выбранной технологии, методов и средств проектирования

Для проектирования АРМ диспетчера по снабжени. будут применяться следующие CASE-средства: Ramus, ERWin, ARIS.

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

Для создания моделей данных в ERwinможно использовать две нотации: IDEF1X и IE (Information Engineering). Первым этапом проектирования данных является создания независимой от конкретной СУБД логической модели. Палитра инструментов облегчает создание сущностей и атрибутов, и позволяет определять различные типы связей. Создание модели сводится просто к выбору соответствующих символов на палитре и добавлению их на рабочее пространство. Дополнительная информация по каждому объекту вводится посредством семейства редакторов. Как только две сущности связываются между собой связью, первичный ключ (ПК) автоматически перемещается из родительской сущности в дочернюю. При этом учитывается тип связи: по идентифицирующей связи ПК попадает в число ключевых атрибутов, а по неидентифицирующей связи - в число неключевых атрибутов дочерней сущности. После создания логической модели данных ERwin конвертирует ее в зависящую от конкретной, предварительно выбранной СУБД физическую. При этом автоматически определяются типы данных, преобразуются связи «многие ко многим» и иерархии наследования (категории). Другой способ создания модели - процесс обратного проектирования существующей базы данных. Модифицированная модель может быть затем загружена обратно в БД. Эта способность связи с БД в двух направлениях - важная особенность ERwin. Аналогичная процедура возможна и в отношении тех данных, которые переносятся в среду разработки. Могут быть выявлены отличия реальных данных и первоначальной модели, а затем и устранены в ходе проведения синхронизации. При этом проектировщик сам определяет направление синхронизации.

АРИС(ARIS – architecture of integrated information systems) позволяет создать концепцию моделирования бизнес-процессов. Концепция призвана соединить теорию и практику бизнеса с информационными и коммуникационными технологиями. Основа концепции АРИС заключается в представлении бизнес-процессов в форме диаграмм. Существует несколько взглядов (подходов) к моделированию бизнес-процессов. Каждый подход характеризуется определенными моделями, которые могут в себя включать много объектов и много соединений (отношений). Объекты, использующиеся в одной модели, могут появляться (использоваться) в других моделях. Для обеспечения структуры, все модели разделены на пять категорий:

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

• Информационные модели – модели информации бизнеса. Включают в себя модели данных, структуры знаний и навыков, информационных носителей и баз данных.

• Функциональные модели – модели действий процессов. Включают в себя иерархию функций, бизнес-целей, прикладных систем.

• Модель товаров и услуг, преобразуемых и получаемых в результате бизнес-деятельности компании.

• Процессные модели – динамические модели, которые показывают поведение процессов и их зависимость от ресурсов, данных и функций окружения бизнеса. Включают в себя событийно-управляемые модели (еЕРС), модели окружения функции (FAD), модель добавленной стоимости (VAD).

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

Глава 2. Практическая часть. 2.1. Моделирование предметной области

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

Модель IDEF0 всегда начинается с представления системы как единого целого – одного функционального блока с интерфейсными дугами, простирающимися за пределы рассматриваемой области (Рис.2). Диаграмма состоит из одной работы, которая называется «работа отдела снабжения».

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

В данной работе описаны стрелки типа вход (Input): «заявки на закупку», представляют собой входную информацию. Стрелка типа выход (Output) «Поступление заказов на склад» содержит в себе выходную информацию.

Стрелка «бухгалтерская система» являются стрелкой типа механизм (Mechanizm) и входят в нижнюю грань работы. Она показывают то, что процесс «Работа отдела снабжения» ведется под контролем бухгалтерской системы.

Стрелка «Внутренние правила компании» является стрелкой типа управление (Control), входит в верхнюю грань работы и показывает правила, процедуры.

Рис.2 Модель - IDEF0 «Управление закупками»

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

Декомпозиция наглядно отражает этапы процесса. Все подпроцессы находятся под контролем менеджера по закупкам.

Рис 3. Диаграмма декомпозиции IDEF0 «Управление закупками».

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

Рис.4 Модель - DFD «Управление закупками»

IDEF1(Рис.5) - это метод структурного анализа для проектирования сложных ИС. IDEF1 позволяет разрабатывать концептуальную модель предметной области системы баз данных в форме одной или нескольких ERдиаграмм, эквивалентных отношениям в третьей нормальной форме. Усовершенствованной версией IDEF1 является методология IDEF1X, разработанная с учетом таких требований, как простота изучения и возможность автоматизации. Методология IDEF1X адаптирована для совместного использования с IDEF0 в рамках единой технологии моделирования. То есть в рамках IDEF0 детализируются функциональные блоки, а в рамках IDEF1X детализируются стрелки, взаимодействующие с функциями.

Рис.5 Модель – IDEF1X

2.2. Обоснование выбора СУБД Access для разработки БД

Приложение Microsoft Access является мощной и высокопроизводительной 32-разрядной системой управления реляционной базой данных (далее СУБД). Практически все СУБД позволяют добавлять новые данные в таблицы. С этой точки зрения СУБД не отличаются от программ электронных таблиц (Microsoft Excel), которые могут эмулировать некоторые функции баз данных.

Существует три принципиальных отличия между СУБД и программами электронных таблиц:

- СУБД разрабатываются с целью обеспечения эффективной обработки больших объёмов информации, намного больших, чем те, с которыми справляются электронные таблицы.

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

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

Access - мощное приложение Windows. При этом производительность СУБД органично сочетаются со всеми удобствами и преимуществами Windows. Как реляционная СУБД Access обеспечивает доступ ко всем типам данных и позволяет одновременно использовать несколько таблиц базы данных. Можно использовать таблицы, созданные в среде Paradox или dBase. Работая в среде Microsoft Office, пользователь получает в своё распоряжение полностью совместимые с Access текстовые документы(Word), электронные таблицы(Excel), презентации(PowerPoint). С помощью новых расширений для Internet можно напрямую взаимодействовать с данными из World Wide Web и транслировать представление данных на языке HTML, обеспечивая работу с такими приложениями как Internet Explorer и Netscape Navigator. Access специально спроектирован для создания многопользовательских приложений, где файлы базы данных являются разделяемыми ресурсами в сети. В Access реализована надёжная система защиты от несанкционированного доступа к файлам. Несмотря на то, что Access является мощной и сложной системой, его использование не сложно для непрофессиональных пользователей.

2.3. Построение концептуальной модели предметной области

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

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

• должна быть понятна лицам, принимающим участие в создании и использовании. При разработке БД для менеджера по закупкам было проведено исследование предметной области, в результате выделены следующие сущности: маршрутный лист, справочник АЗС, справочник ТС, заявки. Каждая сущность в свою очередь имеет список атрибутов, по которым будут осуществляться связи. Тип связи будет определять отношения между атрибутами сущности. На основе вышеуказанного анализа произвели ER-моделирование сущностей и связей между ними. ER-диаграмма на логическом уровне представлена на рисунке 6. ER-диаграмма на физическом уровне представлена на рисунке 7.

Рис. 6 – ER-диаграмма на логическом уровне

Рис. 7 – ER-диаграмма на физическом уровне

2.4. Проектирование логической структуры базы данных

Логическая структура базы данных спроектирована и описана для конкретной СУБД. Для моей базы данных была выбрана СУБД MS Access. Необходимо перейти от ER-модели к таблицам в базе данных. База данных создается на основании таблиц, которые имеют связь между собой. Таблицы, а также связи отражаются в схеме данных базы (рис.8). Таблицы, показанные в схеме данных, имеют несколько параметров: наименование полей, тип данных, размер поля, описание таблиц приведено ниже (таблицы 1-5).

Рис. 8. Схема данных СУБД

№	Название поля	расшифровка	Тип данных	размер
1	Idzakaz	Порядковый номер заявки	Счетчик	10
2	Source	Источник заявки – наименование цеха или подразделения	Короткий текст	50
3	Namemater	Наименование материала	Короткий текст	100
4	Kol	Количество	Числовой	10
5	Datezakaz	Даты составления заявки	Дата/время	10

Таблица 1.Описание таблицы «Заказы»

№	Название поля	расшифровка	Тип данных	размер
1	Idsale	Порядковый номер поставщика	Счетчик	10
2	Namesale	Полное наименование поставщика	Короткий текст	100
3	Address	Фактический адрес	Короткий текст	100
	Addressyur	Юридический адрес	Короткий текст	100
4	Dogovor	Номер и дата договора с поставщиком	Короткий текст	100
5	Kontakt	ФИО сотрудника поставщика	Короткий текст	50
6	Phone	Телефон / факс	Короткий текст	20
7	Email	Адрес электронной почты	Короткий текст	50

Таблица 2.Описание таблицы «Поставщики»

№	Название поля	расшифровка	Тип данных	размер
1	Idtovar	Порядковый номер поступления(закупки)	Счетчик	10
2	Namemater	Наименование	Короткий текст	100
3	Datezakup	Дата поступления на склад	Дата/время	10
4	Price	цена	числовой	10

Таблица 3.Описание таблицы «Товары»

№	Название поля	расшифровка	Тип данных	размер
1	Idnomr	Порядковый номер товара	Счетчик	10
2	Namemater	Наименование	Короткий текст	100
3	Edizm	Единица измерения	Короткий текст	10

Таблица 4.Описание таблицы «Номенклатура»

№	Название поля	расшифровка	Тип данных	размер
1	Idzayavka	Порядковый номер заявки	Счетчик	10
2	Namesale	Наименование поставщика	Короткий текст	100
3	Namemater	Наименование материала	Короткий текст	10
4	Kol	Количество	числовой	10
5	price	Цена	числовой	10
6	Date	Дата заявки	Дата/время	10
7	Idzakaz	Порядковый номер заказа	числовой	10

Таблица 5.Описание таблицы «Заявки»

2.5. Проектирование физической структуры базы данных

Физическая модель (Рис.9) – это привязка логической модели к конкретной среде хранения и методам хранения данных. При проектировании физической модели базы данных необходимо описать среду и метод хранения информации. Для этого необходимо изучить особенности организации данных выбранной СУБД. Для проектирования базы данных была выбрана СУБД MS Access (2010). Для хранения данных в этой СУБД используются таблицы. В них хранится вся информация о предметной области.

Объекты, которых были описаны при построении инфологической модели предметной области, в базе данных являются таблицами. Представим описание объектов и связей между ними в виде физической ER-модели, основанной на методологии IDEF1X, созданной в CASE-средстве ERwin Data Modeler:

Рис. 9. Физическая модель, построенная при помощи программы Erwin

Рис.10 Таблица номенклатура.

Рис.11 Таблица поставщики

Рис.12 Таблица заказы

Рис.13 Таблица заявок

Рис.13 Таблица товаров

2.6. Организация ввода и корректировки данных в БД

База данных состоит из взаимосвязанных таблиц, которые наполняются записями. Ведение базы данных подразумевает под собой возможность управления записями: их добавление, изменение, удаление. Реализация данных возможностей возлагается на СУБД. Существует несколько способов реализации управления базой данных в MS Access. В частности, любое из указанных действий можно выполнить следующими способами:

• Через раздел СУБД «Таблицы», производя действия по изменению, добавлению или удалению непосредственно в таблице. Ввод информации в базу данных может осуществляться путем ввода данных в таблицу. Но такой способ имеет многие очевидные недостатки. Поэтому для этих целей обычно используются экранные формы.

• Через раздел СУБД «Формы», выполняя необходимые действия в таблице через интерфейс формы. Формы – это окна, через которые пользователь взаимодействует с программным кодом приложения и объектами данных.

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

Корректировка данных возможна в этих же формах. Существует 3 способа ввода данных:

• Ввод с клавиатуры;

• Сохранение данных, сформированных иными программными средствами;

• Импорт из других источников.

2.7. Разработка интерфейса приложения

Работа приложения начинается с открытия базы данных. После открытия базы данных автоматически загружается главная форма (рис. 14).

Рис.14 главная форма приложения

С формы осуществляет переход в следующие разделы программы: «внесение заказа», «внесение поставщика», «внесение материала», «просмотр заявок», «отчёт по закупкам». Раздел «Добавить заказа» нужен для того, чтобы вносить заявки поступающие от производства. При входе в данный раздел открывается форма «Добавить заказ» (Рис.15).

Рис.15 Форма «Добавить заявку»

Заключение

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

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

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

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

Затем приводится описание структуры диалога и его содержания. При разработке структуры диалога была спроектирована работа с первичными документами, со справочниками и отчетами.

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

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

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

1. Архипова Н.И. «Исследование систем управления». Учебно-методическое пособие. М., Издательство «ПРИОРТ», 2002 г.

2. Вейцман В.М. Проектирование экономических информационных систем: Учебное пособие. – Яр.: МубиНТ, 2002, - 213 с.: ил.

3. Кантарь И.Л. «Автоматизированные рабочие места управленческого аппарата». Учебно-методическое пособие для вузов, М.,1990 г.

4. Н.А. Белобородова, Ю.М. Фирсова/ Проектирование и построениеАСОИУ – Институт управления, информации и бизнеса, Ухта 2009

5. Кириллов К. В. Моделирование бизнес-процессов средствами ARIS / К.В. Кириллов // Молодой ученый. — 2012. — №6.

6. Келли Дж./ Самоучитель Access 2007 /Пер. с англ. - С-Пб.: "Питер", 2009.

7. Заботина Н.Н./ Проектирование информационных систем - НИЦ Инфра М, 2013

8. Пирогов В.Ю./ Информационные системы и базы данных: организация и проектирование : учеб. пособие - БХВ-Петербург, 2009

9. Емельянова Н. З., Попов И. И., Партыка Т. Л./ Проектирование информационных систем – Форум, 2009

Код для цитирования: Скопировать