Файл: Проектирование информационной системы “оптово-розничного склада”.pdf

наименование клиента;

код договора;

наименование договора;

адрес клиента;

код вида продукции;

наименование вида продукции;

количество;

код склада;

наименование склада;

код филиала;

наименование филиала.

Объем файла – 18 Мб. Частота возникновения одни раз в день.

Таблица с коэффициентами планирования содержит 234 987 строк. Объём файла – 8 мб. В сводной таблице 3 приведены основные характеристики справочников.

Таблица 3

Основные характеристики справочников

Реквизитный состав справочника «Виды продукции»:

код вида продукции;

наименование вида продукции;

литраж вида продукции;

стоимость.

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

Реквизитный состав справочника «Филиалы»:

код филиала;

название филиала;

фактический адрес филиала;

менеджер филиала;

контактная информация филиала.

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

Реквизитный состав справочника «Склады»:

код склада;

код филиала;

название склада;

вместимость склада;

фактический адрес склада;

менеджер склада;

контактная информация склада.

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

Реквизитный состав справочника «Контракты»:

код контракта;

наименование клиента;

наименование договора;

адрес;

контактная информация;

скидка;

статус договора;

дата подписания договора;

дата начала действия договора.

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

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

Входных таблиц девять: «Продажи», «Производство», «Сток», «Доставка», «План производства», «План продаж», «План доставок», «План складирования» и «Коэффициенты планирования». Изменения во всех таблицах, кроме таблицы «Коэффициенты планирования», вносятся функцией «Импорт данных» из файлов с отчётами.

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

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

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

1. «Отчет по согласованным заявкам»

Формируется на основе след таблиц и полей:

• Дата создания заявки
• Пользователь (заявитель)
• Ответственная группа
• Назначенный на заявку сотрудник
• Статус
• Приложенное исходное письмо (тема и тело письма в оригинале)

2. Отчет ”заявки по местоположению заявителя”:

Содержит таблицу со следующими полями:

• Дата создания заявки
• Даты писем по согласованию
• Пользователь (заявитель)
• Месторасположение(город)
• Адрес (улица, дом, корпус, офис)
• Ответственная группа
• Текущий статус переписки и зарегистрирована ли заявка
• Приложенное окончательное письмо (тема и тело письма в оригинале)

Данного рода отчеты имею в информационных поток предприятия служат скорее для получения статистики нежели для оперативного управления и принятия решений, а Информация в этих журналах является скорее уточняющей, нежели обобщающей. В итогах данной ведомостей за месяц можно понять насколько загружена горячая линия по регистрации заявок в ручную, сколько ошибок при регистрации допускает служба и допускает ли. на рисунке №14 представлена скриншот Журнала Созданных заявок в оду итерацию(без согласования) за 1/3/6 часов».

Рисунок 6 «Журнал Созданных заявок в одну итерацию за 1/3/6 часов»

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

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

Рисунок 6 Сценарий Диалога работы программы

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

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

Рисунок 7 Дерево функций

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

Базу данных ИС можно представить в виде следующей ER модели –

Рисунок 8 ER модель базы данных

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

Таблица «registered_letter» что означает обработанную накладную, имеет следующие поля – таблица 9.

Таблица 9

Таблица «registered_letter»

Таблица «Group», имеет следующие поля – таблица 10.

Таблица 10

Таблица «Group»

Таблица называется «IT_worker» и подразумевает список сотрудников склада, имеет следующие поля – таблица 11.

Таблица 11

Таблица «IT_worker»

Таблица «History», имеет следующие поля – таблица 12.

Таблица 12

Таблица «History

Таблица называется "Klassification" и подразумевает набор ключевых слов и по которым будут назначены исполнители заявки на складе – таблица 13.

Таблица 13

Таблица "Klassification"

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

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

Таблица 14

Таблица модулей разрабатываемого программного продукта

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

Для проведения анализа и реорганизации бизнес - процессов предназначено CASE-средство верхнего уровня All Fusion Process Modeler (BPwin), поддерживающее методологии:

▪ IDEF0 (функциональная модель);

▪ DFD (Data Flow Diagram);

▪ IDEF3 (Workflow Diagram).

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

Диаграммы потоков данных (DFD - Data flow diagram) описывают функции обработки информации, документы, объекты, а также сотрудников или отделы, которые участвуют в обработке информации. Диаграммы потоков данных обычно применяются при моделировании информационных систем, для описания документооборота и обработки информации.

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