Проектирование реализации операций бизнес-процесса «управление запасами»

Содержание:

Введение

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

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

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

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

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

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

Таким образом, процедура учета складирования и управления ресурсами, как неотъемлемая часть любого производственного процесса, также должна быть подвержена определенной степени автоматизации. Поскольку учет на складе подразумевает операцию с ресурсами (по каждому из которых необходимо учитывать наборы данных, характеристик, и т.д.), документами, связанными с операциями поступлениями и оттока ресурсов, то применение информационных систем в этом случае – наиболее оптимальный способ повышения эффективности работы склада, а применение современных возможностей СУБД сделает процесс учета на складе простым в обслуживании и надежным с точки зрения хранения данных.

Объектом исследования в данной работе выступает Предприятие по сборке изделий из алюминиевого профиля под заказ.

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

Основные цели создания Системы:

• Повышение надежности хранения информации;
• Уменьшение времени поиска и обработки информации;
• Автоматизация выполнения типовых;
• Учет данных и основных операций деятельности;
• Оперативный доступ к любым данным;
• Разграничение прав доступа к различной информации и операциям.

В результате создания ИС должны быть достигнуты следующие показатели функционирования объекта автоматизации:

- повышение эффективности учета информации о комплектующих, их поступлении и оттока на складе;

- повышение надежности хранения данных;

- составление документов по операциям учета.

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

В данном отчете используются следующие сокращения:

BPMN (Business Process Model Notation) – нотация описания бизнес-процессов;

БД – база данных;

ИС – информационная система;

ООП – объектно-ориентированное программирование;

ПО – программное обеспечение;

СУБД – система управления базами данных;

SQL – Structured Query Language – язык структурированных запросов.

1. Аналитическая часть

1.1 Выбор комплекса задач автоматизации

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

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

1) увеличение реализации продукции;

2) улучшение качества продукции и услуг;

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

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

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

Управление запасами в рамках решаемой задачи будет сводиться к учету двух основных типов операций: расход в связи с выполнениями заказов и пополнение для обеспечения выполнения будущих заказов (и создания необходимых резервов).

1.2 Характеристика существующих бизнес – процессов

Для наглядной демонстрации бизнес-процессов Предприятия, анализа его архитектуры в целом и принятия решений об оптимизации его деятельности имеются специальные методики и языки моделирования [3]. Одной из технологий описания бизнес-процессов, относящихся к типу «work-flow» - моделей, является нотация моделирования BPMN (Business Process Model Notation) – технология моделирования и нотации бизнес-процессов [4]. Данная технология предлагает довольно обширные средства для отражения самых подробных и самых важных понятий моделируемого процесса. Благодаря абстрактному представлению модели нотация BPMN позволяет наглядным образом описывать модели бизнес-процессов независимо от среды их функционирования. Полученная в результате модель представляет собой сеть графических объектов, которые изображают действия и события, связанные между собой потоками управления.

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

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

Рисунок 1.1 – Укрупненная модель бизнес-процесса

Предложенная модель может быть детализирована. Определенная степень детализации модели приведена на рисунке 1.2.

В описании модели существуют три участника:

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

Рисунок 1.2 – Детализированная модель бизнес-процесса

Роли структурных подразделений предприятия:

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

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

Задания на сборку изделий направляются в цех сборки. Процесс сборки проходит в 4 этапа:

• Полученное задание анализируется и формируется список необходимых деталей или компонентов (комплектующих), которые необходимы для сборки всех изделий заказа. Описание этого этапа (подпроцесса) рассмотрено далее.
• Направление подготовленного на первом этапе списка компонентов на склад для их получения.
• Получение необходимых компонентов со склада в соответствии с составленным списком.
• Непосредственно сборка изделий заказа.

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

Уведомление о готовности заказа также направляется в отдел маркетинга для закрытия заказа и учета портфеля заказов.

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

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

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

Получив все запрошенные детали, отдел закупок выдает их в цех сборки для выполнения заказа – этап №3 сборки изделий начинается.

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

Рисунок 1.3 – Модель процесса «Подготовка списка компонентов»

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

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

1.3 Характеристика документооборота, возникающего при решении задачи

На рисунке 1.4 приведена схема документооборота, используемая в процессе сборки заказов на Предприятии. Основные этапы документооборота на схеме приведены в соответствии с BPMN-диаграммой описания бизнес-процессов, приведенной на рисунке 1.2.

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

1. Отсутствии систематизированной и централизованной базы комплектующих, необходимых для сборки;
2. Неэффективном информационном обмене;
3. Неэффективном учете комплектующих для сборки по заказам.

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

Рисунок 1.4 – Схема документооборота при выполнении заказа

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

Помимо этого, ИС будет содержать необходимые данные поставщиков деталей и компонентов.

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

На BPMN-диаграммах все связи поддержки информационной системы показаны точечными стрелками от и к хранилищу данных (DataStore), поскольку хранилище данных (в виде БД) является фундаментальным при реализации функционирования ИС.

Главные задачи, которые должна обеспечить новая информационная система учета деталей:

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

1.4 Обоснование проектных решений по информационному обеспечению

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

Таблица 1.1

Перечень входных и выходных документов

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

Анализ таблицы 1.1 показывает, что процесс управления запасами компонентов на складе становится существенно проще, поскольку теперь вся информация хранится в единой целостной БД.

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

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

На рисунке 1.5 приведена диаграмма проекта интерфейса программного обеспечения ИС, выполненная средствами Visual Paradigm. На ней стрелками показаны возможные переходы между экранными формами ИС.

Рисунок 1.5 – Диаграмма интерфейса ИС

В составе информационного обеспечения ИС УПРС будут использоваться классификаторы, описанные в таблице 1.2.

Таблица 1.2

Перечень классификаторов ИС

Наименование классификатора	Система кодирования	Система классификации	Вид классификатора
Изделие	Порядковая	Линейная	Локальный
Компонент	Порядковая	Линейная	Локальный
Производитель	Порядковая	Линейная	Локальный
Тип компонента	Порядковая	Линейная	Локальный
Операция	Порядковая	Линейная	Локальный

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

Все классификаторы имеют четырехразрядную структуру, структурная формула классификаторов: Ф = [ХХХХ].

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

1.5 Обоснование проектных решений по программному обеспечению

Выбор ОС

Операционная система Microsoft Windows 7/8/10 получила широкое распространение среди огромного числа пользователей – эта операционная система применяется в основе большинства корпоративных сетей общего назначения. Windows предлагает пользователю удобный графический интерфейс и позволяет работать в многозадачном режиме. Одновременно с этим, Windows предлагает огромный набор инструментов и функций, поддерживающих разработку приложений любой сложности – для программистов и разработчиков. Ядро Windows имеет в своем составе полный набор системных компонент для компоновки и реализации стандартных пользовательских интерфейсов, использовании функций управления памятью и доступа к дискам и другим периферийным устройствам, средств загрузки и компоновки программ.

Выбор СУБД

В качестве СУБД можно предложить MySQL. Данная СУБД оптимально использует предлагаемые провайдером хостинг-ресурсы. Высокая эффективность и высокая надёжность способствовали столь высокой популярности данной СУБД. По всем этим причинам MySQL стала незыблемым стандартом в области СУБД для web, а теперь в ней развиваются возможности для использования ее в любых критичных бизнес-приложениях. MySQL конкурирует на равных с такими производителями СУБД, как Oracle, IBM, Microsoft и Sybase.

Основные достоинства СУБД MySQL:

• многопоточность, поддержка нескольких одновременных запросов;
• оптимизация связей с присоединением многих данных за один проход;
• записи фиксированной и переменной длинны;
• наличие ODBC драйвера, в том числе и интегрированные средства для MS Visual Studio;
• гибкая поддержка форматов чисел, строк переменной длинны и меток времени;
• быстрая работа, масштабируемость;
• совместимость с ANSI SQL;
• распространяется согласно стратегии Open Source;
• хорошая поддержка со стороны провайдеров услуг хостинга.

Демонстрационная десктоп-версия ПО ИС разрабатывается и использованием файл-серверной СУБД SQLite.

Требования к специальному ПО

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

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

F – функциональные требования(functional);

U – требования к удобству использования (usability);

R– требования к надежности (reliability);

P – требования к производительности (performance);

S – требования к поддержке (supportability).

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

Рисунок 1.6 – Модель функциональных требований

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

На рисунке 1.7 представлена модель требований к удобству использования, выполненная средствами Visual Paradigm.

Рисунок 1.7 – Модель требований к удобству использования

Надежность системы является крайне важным показателем работы, поэтому все требования к обеспечению надежности ИС должны быть выполнены неукоснительно и в полном объеме.

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

На рисунке 1.8 представлена модель требований к надежности ИС, выполненная средствами Visual Paradigm.

Рисунок 1.8 – Модель требований к надежности

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

На рисунке 1.9 представлена модель требований к производительности ИС, выполненная средствами Visual Paradigm.

Рисунок 1.9 - Модель требований к производительности

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

На рисунке 1.10 представлена модель требований к сопровождению ИС, выполненная средствами Visual Paradigm.

Рисунок 1.10 – Модель требований к сопровождению

2. Проектная часть

2.1 Информационная модель и её описание

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

Рисунок 2.1 – Информационная модель ИС УПРС

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

Аналогично обновляются остатки при регистрации кладовщиком операции поставки компонентов от поставщиков. Руководящим документом этой операции является накладная, полученная от поставщика.

Администратор ИС может заниматься ведением основных справочников.

2.2 Характеристика нормативно-справочной, входной и оперативной информации

Вся входная информация заносится в ИС посредством соответствующих экранных форм. На рисунках 2.2 – 2.9 приведены прототипы форм (диалогов) ввода входной информации. Все прототипы форм выполнены в подсистеме моделирования пользовательского интерфейса пакета Visual Paradigm.

Форма formUser. Представлет диалоговое окно редактирования существующего или ввода данных нового пользователя.

Рисунок 2.2 – Макет формы formUser

Форма formDetail. Диалоговое окно редактирования данных существующей детали или ввода данных новой детали.

Рисунок 2.3 – Макет формы formDetail

Форма formManufacturer. Диалоговое окно редактирования данных существующего производителя или ввода данных нового производителя.

Рисунок 2.4 – Макет формы formManufacturer

Форма formCategory. Диалоговое окно редактирования данных существующей категории деталей или ввода данных новой категории деталей.

Рисунок 2.5 – Макет формы formCategory

Форма formProduct. Является диалогом при создании нового или редактировании данных старого изделия.

Рисунок 2.6 – Макет формы formProduct

Форма formComponent. Форма диалога при создании новых (или редактировании старых) компонентов (деталей), входящих в состав типового варианта изделий готовой продукции.

Рисунок 2.7 – Макет формы formComponent

Форма formQuery. Данная форма выполняет роль диалогового окна при создании / редактировании данных операции выдачи или запроса.

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

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

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

Рисунок 2.8 – Макет формы formQuery

Форма formQueryPosition. Является формой диалога при указании позиции при указании компонентов операции. Позволяет выбрать как отдельную деталь, так и набор деталей в комплекте типового варианта изделия.

Рисунок 2.9 – Макет формы formQueryPosition

2.3 Характеристика результатной информации

Вся выходная информация предоставляется пользователю в ИС посредством соответствующих экранных форм. На рисунках 2.10 – 2.18 приведены прототипы форм вывода информации. Все прототипы форм выполнены в подсистеме моделирования пользовательского интерфейса пакета Visual Paradigm.

Форма formMain. Является главным окном ИС с поддержкой многодокументного интерфейса (MDI). Имеет три основных панели: вверху – панель доступа к подсистемам; слева – панель доступа к командам управления данными; справа – панель доступа к системным функциям.

Рисунок 2.10 – Макет формы formMain

Форма formUsers. Выполнена в виде таблицы зарегистрированных пользователей.

Рисунок 2.11 – Макет формы formUsers

Форма formDetails. Форма справочника деталей представлена в виде учетной таблицы деталей с возможностью фильтрации и сортировки.

Рисунок 2.12 – Макет формы formDetails

Форма formManufacturers. Представляет собой учетную таблицу производителей.

Рисунок 2.13 – Макет формы formManufacturers

Форма formCategories. Представляет таблицу категорий деталей.

Рисунок 2.14 – Макет формы formCategories

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

Рисунок 2.15 – Макет формы formProducts

Форма formWareHouse. Форма учета деталей на складе, содержащая краткую статистическую информацию – количество деталей в наличии и общее количество выданных деталей каждого типа. Оснащена многокритериальным фильтром для поиска и сортировки данных.

Рисунок 2.16 – Макет формы formWareHouse

Форма formQueries. Форма учета операций всех типов: запросов и выдач. Представляет собой две таблицы: в одной (верхней) учтены все совершенные операции, во второй (нижней) перечислены компоненты, входящие в состав операции, выбранной из первой таблицы.

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

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

Рисунок 2.17 – Макет формы formQueries

Форма formDocument. Форма предназначена для вывода сгенерированных документов по операциям. Представляет собой WebBrowser, которому будет поступать HTML-код сгенерированных документов на отображение.

Рисунок 2.18 – Макет формы formDocument

2.4 Общие положения (дерево функций и сценарий диалога)

Функциональная структура ИС должна составлять совокупность подсистем, каждая из которых будет выполнять определенные функции, в соответствии с рисунком 2.19.

Рисунок 2.19 – Функциональная структура ИС

Функциональная структура ИС включает в себя 4 основные и обеспечивающие (сервисные) подсистемы.

Основные подсистемы:

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

• Справочник деталей и их категорий;
• Справочник производителей.

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

Подсистема базы типовых вариантов изделий. Данная подсистема предназначена для учета и использования данных в других подсистемах для упрощения работы. Данная подсистема должна предоставлять:

• Справочник типовых изделий;
• Средства для компоновки типовых изделий из учтенных деталей;
• Функции распознавания изделий, представленные в виде декомпозиции изделий на составляющие детали.

Подсистема учета склада. Данная подсистема должна обеспечивать:

• Учет количества всех деталей на складе;
• Перерасчет количества деталей по проведенным изменениям (получению или выдаче в сборочный цех).

Кроме того, данная подсистема должна предоставлять статистику по деталям: сколько есть сейчас, сколько было выдано.

Подсистема учета запросов и выдач. В рамках этой подсистемы должны быть предоставлены возможности:

• Учета операций получения (запросов) деталей на склад;
• Учета операций выдачи деталей в сборочный цех;
• Формирования документов по обоим видам операций;
• Декомпозиции изделий при учете деталей в запросе или выдаче.

Обеспечивающие (сервисные) подсистемы:

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

1. Для пользователя «сборщик» - доступ к подсистеме вариантов изделий с возможностью их создания, удаления и редактирования, доступ к подсистеме справочников в режиме «только чтение», блокировку в доступе к подсистеме учета запросов и выдач;
2. Для пользователя «кладовщик» - доступ к подсистеме вариантов изделий и подсистеме справочников в режиме «только чтение», доступ к подсистеме учета запросов и выдач с возможностью создания и редактирования (без удаления);
3. Для пользователя «администратор» должен быть открыт доступ ко всем подсистемам без ограничений.

Подсистема управления учетными данными пользователей должна также предоставить:

• Авторизацию каждого пользователя по его личному логину и паролю, которые должны храниться в БД;
• Возможность администратору создавать, удалять и изменять данные пользователей;
• Возможность иметь только одного пользователя администратора – операция добавления учетной записи нового администратора, как и операция удаления учетной записи текущего администратора, должна быть недопустима.

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

• Отправки и обработки SELECT-запросов к БД;
• Отправки запросов на вставку, удаление и обновление записей в БД;
• Бесперебойной стабильной связи с БД.

Рисунок 2.20 – Диаграмма вариантов использования

Схема общего сценария использования ИС представлена на рисунке 2.21 в виде диаграммы действий, выполненной в среде Visual Paradigm. На ней представлена роль ИС в деятельности предметной области и схема выполнения операций.

Рисунок 2.21 – Общий алгоритм работы ИС

На основании выданного задания на изготовление изделий определяется состав необходимых компонентов. При необходимости, если заданием определены требования заказчика к изготовлению нового типа изделий или применению нового типа компонентов, создаются необходимые учетные записи в подсистемах учета изделий и компонентов. Сценарии выполнения этих действий представлены на диаграммах на рисунках 2.22 и 2.23.

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

Рисунок 2.22 – Алгоритм ведения справочников деталей

Рисунок 2.23 – Алгоритм ведения справочника изделий

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

Рисунок 2.24 – Алгоритм создания запроса на закупку деталей

Алгоритм учетной операции регистрации выдачи деталей в сборочный цех аналогичен алгоритму регистрации операции запроса компонентов. Процесс создания соответствующей операции в ИС также состоит из добавления списка необходимых деталей (или изделий) в лист выдачи компонентов.

2.5 Характеристика базы данных

В таблице 2.1 описаны атрибуты сущностей логической модели БД. Имея спецификации сущностей, состав и описание их атрибутов, можно создать графическое представление логической модели БД в виде диаграммы сущность – связь (ERD, Entity Relationship Diagram).

Таблица 2.1

Спецификация сущностей

Сущность	Атрибут		Описание	Ключ
Categories – таблица учета категорий деталей	id		Уникальный номер	PK
	naming		Наименование категории деталей	-
Manufacturers – таблица учета производителей		id	Уникальный номер	PK
		naming	Наименование производителя	-
		description	Краткое описание	-
Details – таблица учета деталей		id	Уникальный номер	PK
		naming	Наименование детали	-
		features1	характеристики детали 1	-
		features2	характеристики детали 2	-
		quantity	Количество на складе	-
		Categoriesid	Номер категории детали	FK
		Manufacturersid	Номер производителя	FK
Products – таблица учета типовых вариантов изделий		id	Уникальный номер	PK
		naming	Наименование изделия	-
		description	Описание изделия	-
Components – таблица компонентов, входящих в состав изделий		quantity	Количество деталей в составе изделия	-
		Productsid	Код изделия и код детали в составе этого продукта	PK, FK
		Detailsid		PK, FK
Queries – таблица учета операций с деталями		id	Уникальный номер	PK
		description	Описание операции	-
		qdate	Дата операции	-
		qtime	Время операции	-
		employee	Ответственный сотрудник	-
		typeinout	Тип: выдача(0), запрос(1)	-
QueryPositions – таблица содержимого операций		quantity	Количество деталей в составе операции	-
		Detailsid	Код операции и код детали в составе этой операции	PK, FK
		Queriesid		PK, FK
Users – таблица учета пользователей системы и их прав доступа		id	Уникальный номер	PK
		personal	Личные данные пользователя- фамилия, имя, и т.д.	-
		login	Логин пользователя для входа в ИС.	-
		password	Пароль пользователя для входа в ИС.	-
		accesskey	Идентификатор прав доступа: 1= кладовщик, 2=сборщик, 3=администратор	-

Среда проектирования Visual Paradigm представляет средства для представления концептуальной модели в логическую.

На рисунке 2.25 представлена ER-диаграмма логической модели базы данных информационной системы.

Рисунок 2.25 – Логическая модель БД ИС

Физическая модель данных получается из логической с уточнением атрибутов сущностей и связей в соответствии с конкретной СУБД, в которой будет реализована БД. В таблице 2.2 приведены уточнения атрибутов сущностей в соответствии с применимостью к выбранной СУБД («++» в колонке «Тип» означает инкрементный счетчик).

Таблица 2.2

Спецификация физической схемы данных

Сущность	Атрибут		Тип		Уникальность		Обязательность
Categories	id		Integer (++)		Да		Да
	naming		Varchar[255]		-		Да
Manufacturers	id		Integer (++)		Да		Да
	naming		Varchar[255]		-		Да
	description		Varchar[255]		-		-
Manufacturers		id		Integer (++)		Да		Да
		naming		Varchar[255]		-		Да
		description		Varchar[255]		-		-
Details		id		Integer (++)		Да		Да
		naming		Varchar[255]		-		Да
		features1		Varchar[255]		-		-
		features2		Varchar[255]		-		-
		quantity		Integer		-		Да
		Categoriesid		Integer		-		Да
		Manufacturersid		Integer		-		Да
Products		id		Integer (++)		Да		Да
		naming		Varchar[255]		-		Да
		description		Varchar[255]		-		-
Components		quantity		Integer		-		Да
		Productsid		Integer		-		Да
		Detailsid		Integer		-		Да
Queries		id		Integer (++)		Да		Да
		description		Varchar[255]		-		Да
		qdate		Date		-		Да
		qtime		Time		-		Да
		employee		Varchar[255]		-		Да
		typeinout		Binary		-		Да
QueryPositions		quantity		Integer		-		Да
		Detailsid		Integer		-		Да
		Queriesid		Integer		-		Да
Users		id		Integer (++)		Да		Да
		personal		Varchar[255]		-		Да
		login		Varchar[255]		-		Да
		password		Varchar[255]		-		Да
		accesskey		Integer		-		Да

Отражение спецификации, приведенной в таблице 2.2, приведено на рисунке 2.26. На нем изображена диаграмма логической модели, приведенная средствами Visual Paradigm к физической модели данных.

Рисунок 2.26 – Физическая модель БД ИС

2.6 Структурная схема пакета (дерево вызова программных модулей)

В основе проекта классов для функционирования системы лежит идея использования 4-х уровней классов (цвета указаны для ориентировки на диаграмму проектных классов – рисунок 2.27). Уровни указаны в порядке приоритетного следования в ходе выполнения функций:

1. Уровень пользовательского интерфейса – уровень представления и манипулирования данными. Этот уровень можно разделить на 2 подуровня: сервисный (СЕРЫЙ), в состав которого входят главное пользовательское окно, окно представления отчетов и окно авторизации в системе; пользовательский (КРАСНЫЙ) – представлен классами дочерних MDI-форм, содержащих учетные таблицы с фильтрами данных. Основное назначение классов данного уровня – обеспечить пользователя представлениями информации (таблицами) и возможностью (сервисами) управлять данными. Пользовательские классы данного уровня содержат конструкторы, в которых им назначается MDI-родитель, и методы обновления данных в таблицах (UpdateTable()), которые вызываются при открытии форм или при применении фильтров. Сервисные классы имеют методы авторизации, назначения прав доступа пользователей и вывода отчетов.
2. Уровень ввода и редактирования данных (СИНИЙ). Данный уровень представлен классами форм диалогов для ввода и редактирования данных информационных таблиц. Методы классов данного уровня включают: конструкторы, обеспечивающие инициализацию диалогов, и методы предварительной установки значений в поля ввода диалогов – SetValues().
3. Уровень управляющих классов (ЗЕЛЕНЫЙ). Этот уровень является основным связующим звеном между действиями пользователя и управлением данными в БД. В классы данного уровня попадают все команды пользователя. Методы данных классов делятся на 4 типа:

Методы-отображения (Show…Table) обеспечивают создание и вызов форм учета (формы уровня пользовательского интерфейса).

Методы-команды (AddNew…, Delete…, Update…) принимают команды пользователя посредством главной формы (formMain). Данные методы формируют формы уровня ввода и редактирования данных и создают диалог с пользователем. По завершении диалога соответствующие команды и данные направляются в класс следующего, последнего уровня на исполнение.

Вспомогательные методы. Например, методы GetComponents() у классов Products и Operations. Вспомогательные методы позволяют получить необходимые данные для обеспечения работы других методов.

Сервисные (или специальные) методы. К ним относятся методы, обеспечивающие выполнение специальных функций ИС. Такие методы есть у классов: Operations: ShowReport(), HTMLDocumentText() – методы обеспечивают построение и вывод отчетов по операциям; TryLogin() – метод, позволяющий произвести авторизацию пользователя в системе.

1. Уровень поддержки БД (ЖЕЛТЫЙ). Данный уровень представлен всего одним классом – DATABASE. Этот класс содержит методы исключительно для взаимодействия с базой данных через соответствующие адаптеры таблиц данных. Реализует команды управления данными (удаление, обновление, вставку) и SELECT-запросы для организации выборок данных.

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

Рисунок 2.27 – Диаграмма проектных классов ИС

2.7 Описание программных модулей

Организацию взаимодействия и описание программных модулей можно описать с помощью динамических моделей. Динамические модели ИС наглядно могут быть описаны с помощью диаграмм коопераций или последовательности сообщений. Далее приведены диаграммы последовательности сообщений основных функций ИС, выполненные в Visual Paradigm. Все диаграммы приведены для действующего лица типа «администратор» (кроме авторизации – в этом случае используется абстрактный пользователь).

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

Рисунок 2.28 – Диаграмма добавления новой детали

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

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

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

Рисунок 2.29 – Диаграмма добавления нового типа изделий

Авторизация пользователя осуществляется при помощи специального метода TryLogin() управляющего класса Users, который инициирует вызов формы авторизации и обращается к классу DATABASE за проверкой введенных авторизационных данных.

Метод TryLogin() возвращает в главную форму результат авторизации и вызывает метод SetUserRights(), который устанавливает доступ к подсистемам ИС.

Рисунок 2.30 – Диаграмма авторизации

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

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

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

Перед тем, как применить и подтвердить данные для ввода их в БД, система проверяет возможность исполнения операции – метод CheckOperationOpportunity(). Данный метод проверяет каждую введенную позицию операции на предмет соответствия количества деталей, запрошенных в операции, и количества деталей, имеющихся на складе по факту. Если запрашивается деталей больше, чем есть, операция не выполняется. Такая проверка выполняется только для операций типа «Выдача», т.к. для операций поступления она не имеет смысла.

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

Рисунок 2.31 – Диаграмма создания новой операции

Диаграмма приведена с момента создания новой формы учета операций. С целью сокращения объема диаграммы процесс инициирования создания данной формы посредством класса Operations опущен. Инициирующие команды пользователя показаны через Found Message – tsbAdd_Click() и ShowReport().

2.8 Контрольный пример реализации проекта и его описание

Описание контрольного примера приведено в Приложении А – руководство пользователя ИС.

Заключение

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

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

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

Проектирование информационной системы было осуществлено с применением современных методов разработки и дизайна. Разработка всех моделей выполнена в среде проектирования Visual Paradigm for UML 7.1.

Cписок литературы

1. ГОСТ 19.505-79. «Руководство оператора. Требования к содержанию и оформлению».
2. Балдин К.В., Уткин В.Б. Информационные системы в экономике. М.– Издательский центр Академия, 2005 – 288 с.
3. Кулябов Д.С., Королькова А.В. Введение в формальные методы описания бизнес-процессов: Учеб. Пособие. – М.: РУДН, 2008. – 173 с.
4. Нотация BPMN. Электронный ресурс: [Режим доступа]: http://bpmsoft.org/bpmn/
5. Баранкова И.А. Нотация моделирования бизнес-процессов BPMN и ее применение при проектировании автоматизированных систем.: Молодежный научно-технический вестник. – Электронный журнал.: Изд. ФГБОУ ВПО «МГТУ им. Н.Э. Баумана». Эл. No. ФС77-51038.
6. Орлов С.А. Технология разработки программного обеспечения: Учебник для вузов [Текст] / С. А. Орлов. - СПб.: Питер, 2004. - 527 с.
7. SQLite – Википедия. Электронный ресурс: [режим доступа]: https://ru.wikipedia.org/wiki/SQLite
8. Visual Paradigm for UML 13. User’s guide.: Software documentation – user’s manual - 1485 pages.
9. Microsoft Visual Studio 2010. Visual C#. Руководство пользователя. // Техническая документация к среде разработки.
10. MSDN. Комплекс технической документации по продуктам Microsoft.
11. Jay A. Kreibich. Using SQLite. – O’Reilly Media, Inc., First Edition – 2010,August. 528 pages.
12. UML 2.0. Superstructure specification. – Final adopted specification – ptc/03-08-02; 2003, 640 p.