«Разработка проекта подсистемы автоматизации складского учета»

Содержание:

Введение

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

Целью данного курсового проекта является проектирование информационной системы “оптово-розничного склада”, которая позволит автоматизировать процесс управления товарными запасами на данном предприятии. Задачи работы - описать проектирование бизнес процессов по управлению продовольственными запасами на складе и разработать графическое представление спроектированных процессов. К рассматриваемым процессам относятся - закупка, хранение, учёт и продажа товара.

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

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

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

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

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

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

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

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

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

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

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

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

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

▪ Закупка товара;

▪ он Хранение;

▪ Учёт он товара;

▪ Продажа он товара.

Опишем более еще подробно проектируемые еще процессы:

Закупка еще товара - в начале еще предприятие определяет он потребность в товаре, он после чего еще производится анализ еще спроса за еще определённый период еще на данном еще предприятии для еще определения закупаемого еще товара и его он количества. Объём закупаемого еще товара зависит еще от его он сроков хранения (еще годности). Если еще товар скоропортящийся, он то его он закупаемое количество еще не должно он сильно превышать еще на него еще спрос. Затем финансовый он директор даёт он указание менеджеру он изучить рынок он предложений данного еще товара и определить он наиболее выгодного он поставщика. В результате принимается он решение о закупке он товара и составляется еще заявка поставщику. Далее осуществляется он приёмка и проверка он товара (количественная, он качественная).

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

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

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

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

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

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

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

еще Таблица 1

Образец он таблицы описания еще документов

Диаграмма и он номер на еще диаграмме	Составляемый документ (еще исходящий документ)	Операция	Кто составляет (он исполнитель)	Как часто	Документы-основания (еще входящие документы)	Реестр, в котором он регистрируется документ	Комментарий
1	2	3	4	5	6	7	8

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

Таблица описания он документов получается еще путем переформирования (еще перестановки столбцов и еще объединения строк) он таблицы описания еще операций. Особенности таблицы он описания документов он заключаются в следующем. В Графе 2 не он должно быть еще повторяющихся наименований еще документов. Если один и он тот же еще документ является еще исходящим на еще различных операциях, еще то он он один раз он указывается в графе 2 "еще Составляемый документ", а в еще графе 3 ему в еще соответствие ставятся еще несколько операций. Также по еще наименованию документа он следует объединить еще записи и в других он графах.

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

Таблица 2

Документы еще бизнес-процесса "он Запасы - Склад (еще приходование)"

Диаграмма и еще номер операции он на диаграмме	Составляемый документ (еще Исходящий документ)	Операция	Исполнитель	Как часто	Документы-основания (он Входящие документы)	Реестр, в котором еще регистрируется документ	Комментарий
1	2	3	4	5	6	7	8
4Склад 2	1. Приходная накладная	1. Отражение в базе еще данных количества еще товара	Менеджер отдела он закупок	Ежедневно	Товарная накладная еще поставщика Заказ еще поставщику	Реестр приходных он накладных
4Склад 4	2. Запись в справочнике он серий	2. Добавление серии в еще справочник	Менеджер отдела еще сертификации	По мере еще необходимости	Товарная накладная он поставщика	Нет
4Склад 7, 8	3. Карточка товара	3. Определение и ввод еще базовой цены он продажи 4. Процесс размещения он серии товара	Менеджер отдела он маркетинга Менеджер еще склада	Ежедневно	Товарная накладная еще поставщика	Реестр товара

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

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

Критериями выбора ПО, он установленного на он ПК пользователей еще является максимальная еще минимизация времени еще процесса описание он заявки/неисправности он пользователей и отправки еще заявки используя он корпоративную почту он компании. В рамках корпоративного он стандарта в компании еще используется MS еще outlook 2003.

Для запуска еще этой программы он на компьютере еще пользователя должна он быть также он установлена ОС, поддерживающая еще запуск данного он приложения. В связи с корпоративным еще стандартом использования еще версии ОС он MS Windows он XP PRO, еще так как он это самая он младшая версия ОС, еще поддерживаемая компанией он Microsoft в России (еще windows 2000 и 9x на еще данный момент он уже не еще поддерживаются) и имеющая еще возможность работать в еще доменной инфраструктуре (он версия Windows еще XP Home еще не поддерживает он работу в домене).

еще Исходя из еще этих обоснований он критерий Win он XP Pro он sp3 Rus он будет использована в еще качестве пользовательской ОС. Итог: на он рабочих станциях еще пользователей (клиентов) еще должны быть еще установлены следующие еще программные продукты:

• еще Операционная система еще Windows XP он Pro sp3 он Rus

• Почтовый еще клиент MS еще outlook 2003

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

Критериями выбора он архитектуры реализации еще проектируемого Программного еще Комплекса являются:

1. совместимость с существующей еще инфраструктурой серверов

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

При выборе еще ОС под он данное решение он был выбран он MS Windows еще Server 2003, так он как данный он вид серверных он ОС не он сильно требователен к еще ресурсам, а также еще давно используются в еще инфраструктуре компании.

В качестве СУБД еще для программы он будет использоваться он Oracle 11 ver 11.2.0.1. Выбор в пользу он компании Oracle он сделан не он случайно, основная он информационная система еще учёта заявок он HP OpenView еще Service Desk еще построена на еще на именно еще такой базе он данных.

Закупка нового он сервера не он обязательна, так еще как база он данных программного еще продукта может он быть расположена он на уже он имеющемся сервере «SD». еще При создании еще данного сервера еще компания закладывала он около 50% мощности еще закупаемого сервера еще на будущую он масштабируемость системы, еще но не он смотря на еще рост базы он данных за 3 еще года загруженность он сервера возросла еще всего на 15%.

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

Написание программы еще сервиса, обрабатывающего еще почтовый ящик еще было решено еще на языке он python. Такой выбор еще был сделан еще не случайно: еще Во первых он администратор ИС “еще HP OpenView еще ServiceDesk” имеет еще опыт работы с он данным скриптовым еще языком программирования. Во вторых он данный язык он действительно не еще сложен в освоении и еще среди фрилансеров в еще интернете легко еще найти программиста, он который при он правильно поставленном еще техническом задании еще сможет в поставленные еще сроки выполнить он данную разработку, еще стоимость разработки он по на еще python гораздо еще ниже, чем еще разработка на он основе таких он громоздких продуктов еще как Borland C++ он или Microsoft он Visual C++ . В третьих, данный он язык очень он активно развивается и он имеет открытую еще архитектуру и легко он позволяет сделать он графический интерфейс в он виде HTML еще странички (web -еще интерфейс)

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

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

Критериями выбора ПО, еще установленного на еще ПК пользователей он является максимальная еще минимизация времени еще процесса описание еще заявки/неисправности он пользователей и отправки еще заявки используя он корпоративную почту еще компании. В рамках корпоративного еще стандарта в компании он используется MS он outlook 2003.

Для запуска еще этой программы он на компьютере еще пользователя должна еще быть также еще установлена ОС, поддерживающая он запуск данного он приложения. В связи с корпоративным еще стандартом использования он версии ОС еще MS Windows еще XP PRO, он так как он это самая он младшая версия ОС, он поддерживаемая компанией еще Microsoft в России (еще windows 2000 и 9x на он данный момент еще уже не он поддерживаются) и имеющая еще возможность работать в еще доменной инфраструктуре (он версия Windows еще XP Home еще не поддерживает он работу в домене).

он Исходя из он этих обоснований еще критерий Win он XP Pro он sp3 Rus еще будет использована в он качестве пользовательской ОС. Итог: на еще рабочих станциях он пользователей (клиентов) еще должны быть еще установлены следующие еще программные продукты:

• он Операционная система он Windows XP он Pro sp3 еще Rus
• Почтовый еще клиент MS еще outlook 2003

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

Критериями выбора он архитектуры реализации еще проектируемого Программного еще Комплекса являются:

1. еще совместимость с существующей еще инфраструктурой серверов
2. он возможность создания еще резервных копий он данных и просматривать еще статистку по еще обработанным заявкам.

При выборе еще ОС под еще данное решение он был выбран еще MS Windows еще Server 2003, так еще как данный еще вид серверных еще ОС не он сильно требователен к еще ресурсам, а также еще давно используются в он инфраструктуре компании.

В качестве СУБД он для программы он будет использоваться он Oracle 11 ver 11.2.0.1. Выбор в пользу он компании Oracle еще сделан не он случайно, основная он информационная система еще учёта заявок еще HP OpenView еще Service Desk он построена на еще на именно еще такой базе он данных.

Закупка нового еще сервера не он обязательна, так еще как база он данных программного он продукта может он быть расположена еще на уже еще имеющемся сервере «SD». он При создании еще данного сервера еще компания закладывала он около 50% мощности еще закупаемого сервера еще на будущую он масштабируемость системы, еще но не еще смотря на он рост базы еще данных за 3 он года загруженность еще сервера возросла он всего на 15%.

В еще рамках уже он существующей базы еще данных в ней он будут созданы он дополнительные таблицы и он связи между он ними. Добавленные таблицы он не будут он на прямую еще связаны с основными он функциональными таблицами еще базы данных, он поэтому не еще повлияют на еще работу основного он функциоана ИС он HP openView он ServiceDesk. Написание программы он сервиса, обрабатывающего он почтовый ящик еще было решено он на языке еще python. Такой выбор он был сделан еще не случайно: еще Во первых он администратор ИС “еще HP OpenView еще ServiceDesk” имеет он опыт работы с еще данным скриптовым еще языком программирования. Во вторых он данный язык он действительно не он сложен в освоении и он среди фрилансеров в еще интернете легко он найти программиста, он который при еще правильно поставленном он техническом задании еще сможет в поставленные еще сроки выполнить он данную разработку, он стоимость разработки еще по на он python гораздо еще ниже, чем он разработка на еще основе таких еще громоздких продуктов еще как Borland C++ он или Microsoft он Visual C++ . В третьих, данный он язык очень он активно развивается и еще имеет открытую он архитектуру и легко он позволяет сделать еще графический интерфейс в еще виде HTML еще странички (web -еще интерфейс).

Глава 2 Проектная часть

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

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

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

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

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

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

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

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

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

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

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

он SADT (Structured еще Analysis and он Design Technique) еще модели и соответствующие он функциональные диаграммы;

он DFD (Data он Flow Diagrams) еще диаграммы потоков он данных;

ERD (еще Entity-Relationship еще Diagrams) диаграммы "он сущность – связь".

он На стадии он проектирования ИС он модели расширяются, он уточняются и дополняются он диаграммами, отражающими он структуру программного он обеспечения: архитектуру ПО, еще структурные схемы еще программ и диаграммы еще экранных форм.

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

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

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

1. он Внешние сущности.
2. Системы/подсистемы.
3. Процессы.
4. Накопители данных.
5. Потоки данных.

Для проектирования еще автоматизированной информационной он системы управление еще продаж используется он CASE – средство он фирмы RationalSoftwareCorporationRationalRose, еще предназначенное для еще автоматизации этапов еще анализа и проектирования еще программного обеспечения, а еще также для он генерации кодов он на различных еще языках и выпуска еще проектной документации. RationalRose использует еще метод объектно – еще ориентированного анализа и он проектирования, основанный он на языке он UML.

Результатом разработки еще проекта с помощью он CASE – средства еще RationalRose будут он являться: диаграммы еще UML, в совокупности еще представляющие собой еще модель разрабатываемой он программной системы; еще спецификации классов, еще объектов, атрибутов и еще операций; заготовки он текстов программ.

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

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

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

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

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

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

Диаграмма изображена еще на рис.1.

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

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

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

Стало ясно, он как

Рис.1. Диаграмма взаимодействия еще разработанной информационной он системы с внешними он сущностями

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

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

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

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

Кооперативная диаграмма (он Collaboration diagram) еще предназначена для еще описания методов он взаимодействия между он объектами. Также кооперативная он диаграмма имеет он другое название – он диаграмма сотрудничества. Диаграмма сотрудничества он включает в себя еще объекты и отношения он между ними, еще заключающееся в вызове он методов друг еще друга.

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

Рис.2 Декомпозиция процесса еще загрузки системы

он Также необходимо он отметить, что еще исходная информация он может быть он загружена из он ранее сохранённых он данных в файлы еще базы данных (*.db) и еще файлы Excel (*.еще xls). После он выбора загрузки он исходной информации, он система получает еще сигнал о продолжении еще работы и передаёт он полученные данные он для обработки в он основной модуль он системы, представленный он на диаграмме в еще виде комплекса он задач.

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

1) представление он промежуточных массивов еще данных в экранной еще форме в виде он таблиц;

2) формирование еще отчётов (выходной он информации) на еще основании промежуточных он данных;

3) сохранение еще обработанных данных в он базу данных, он принадлежащей системе.

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

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

Данный процесс он представлен на он рис.3.

Рис.3 Комплекс задач еще системы

Рис.4 Процесс формирования он отчётов

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

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

Входные экранные формы для формирования статистических отчетов приведены на рисунках 27, 28 и 29. Файлы с отчетами по видам деятельности содержат те же реквизиты, что и таблицы БД. Структура файлов – таблицы Excel. Экранные формы для формирования файлов со статистическими отчетами содержат данные с временным периодом формирования статистических отчетов. Эти данные вносятся сотрудником отдела планирования. Через экранные формы, сотрудник отдела планирования запускает автоматизированный процесс формирования файлов с отчетами.

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

Файл «Табель учета рабочего времени» содержит следующие показатели: фамилия, имя и отчество сотрудника, количество праздничных дней в месяце, количество отработанных часов с коэффициентами 1 (норма часов), 1.5 (переработки), 2 (переработки и праздничные часы) и 0.4 (ночные часы), а также общее количество отработанных часов. Количеству строк соответствует количество сотрудников предприятия - 4800. Количество записей – 33600. Структура файла – таблица Excel. Объем файла – 180 Кб.

Файл «Комплексные данные по филиалам» содержит следующие показатели: количество перемещенных упаковок, количество упаковок, принятых на склад с производства, количество упаковок, отправленных филиалом на склады, количество проданных упаковок, количество упаковок, отправленных на экспорт, количество упаковок, принятых как импорт, количество упаковок, возвращенных из торговой сети, количество проданных упаковок за один календарный месяц. Количество строк соответствует количеству филиалов предприятия - 11. Количество записей – 88. Структура файла – таблица Excel. Объем файла – 1,3 Кб. Источником получения файлов является корпоративная ИС. Частота возникновения одни раз в календарную неделю. Таблица с коэффициентами планирования содержит коэффициенты для планирования основных видов деятельности. Количество строк соответствует количеству видов продукции, филиалов, складов и контрактов. Частота возникновения одни раз в день.

Отчет по продажам формируется отделом продаж и содержит следующие показатели:

дата заказа;

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

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

код склада;

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

код филиала;

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

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

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

количество;

цена;

скидка;

стоимость.

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

Отчет по производству формируется отделом производства и содержит следующие показатели:

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

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

срок годности;

количество;

код филиала;

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

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

Отчет по складу формируется отделом склад и содержит следующие показатели:

код склада;

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

код филиала;

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

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

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

дата розлива;

срок годности;

количество.

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

Отчет по доставке формируется отделом доставки и содержит следующие показатели:

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

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

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

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

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

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

количество;

код склада;

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

код филиала;

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

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

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

Таблица 3

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

Название справочника	Ответственный за ведение справочника	Объем в строках	Средняя частота актуализации в год	Средний объем  ктуализации,  % в год
Виды продукции	Специалист отдела производства	270	10	5,5
Филиалы	Специалист отдела логистики	11	0,5	9
Склады	Специалист отдела  логистики	110	3	10
Контракты	Специалист отдела доставки	234 987	312	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»

Наименование поля	Тип данных поля	Длина поля
ID	Целое Число (ключевое поле)	11
Date created	Дата	10
Letter_date	Дата	10
Letter_from	Строка	50
Letter_title	Строка	50
Letter_body	Строка	250
It_worker_ID	Целое число	5
It_Group_ID	Целое число	5
IT_Mestopologenie	Целое число	5
Id_history	Целое число	5

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

Таблица 10

Таблица «Group»

Наименование поля	Тип данных поля	Длина поля
ID_group	Целое Число (ключевое поле)	11
Group_Name	Строка	100

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

Таблица 11

Таблица «IT_worker»

Наименование поля	Тип данных поля	Длина поля
ID	Целое Число (ключевое поле)	11
Name	Строка	15
Second_Name	Строка	20
Extension	Число	5
Mobile_phone	число	10
IT_Group	Число	11

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

Таблица 12

Таблица «History

Наименование поля	Тип данных поля	Длина поля
ID_history	Целое Число (ключевое поле)	11
ID_status	Целое число	11
Soglasovano	Логическая	1

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

Таблица 13

Таблица "Klassification"

Наименование поля	Тип данных поля	Длина поля
ID_Klassification	Целое Число (ключевое поле)	11
KeyPhrases	Строка	150
Group_ID	Целое число	11
Id_it_Worker	Целое число	11
Soglasovanie	Логическое	1
Date	дата	10

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

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

Таблица 14

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

№ п/п	Наименование модуля	Функционал модуля
1	Форма “основная процедура работы склада”	Содержит в себе глобальные переменные, процедуры и функции. Основная работа начинается с этого модуля.
2	Форма “Журнал Созданных накладных в одну итерацию”	Форма формирование и отправки отчета Созданных накладных в одну итерацию.
3	Форма «Журнал обработанных накладных»	Форма формирование и отправки отчета накладных
4	Форма «Авторизация»	Данная форма содержит запрос логина и пароля для входа в веб интерфейс программы.
5	Форма «О программе»	Краткая информация о созданной программе.

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

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

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

▪ DFD (Data Flow Diagram);

▪ IDEF3 (Workflow Diagram).

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

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

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

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

Построение модели ИС начинается с описания функционирования предприятия (системы) в целом в виде контекстной диаграммы. На Рис. 4.1 представлена контекстная диаграмма ИС - «Управление торговыми запасами оптово-розничного склада»:

Рис. 9 Контекстная диаграмма IDEF0.

Управление товаром на оптово-розничном складе

Взаимодействие системы с окружающей средой описывается в терминах:

 входа (на рис.9 это «Поставщики», «Товар» и «Первичные документы»);

 выхода (основной результат процесса - «Выходные документы», «Товар» и «Прибыль»);

 управления («Законодательство», «Нормативы складского учёта» и «Конъюнктура рынка»);

 механизмов («Материальная база», «Оборудование», «Персонал» - это ресурсы, необходимые для процесса функционирования предприятия).

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

«Законодательство», «Нормативы складского учёта» и «Конъюнктура рынка» - это правила управления процессом функционирования работы склада, а именно управления товарными запасами. Как предприятие со своими внутренними правилами, управление товаром должно выполняться согласно законодательству страны.

В оказании услуг принимает участие «Персонал» склада. Чтобы организовать хранение товара, предоставление его для продажи и получить прибыль, в деятельности управления запасами должны участвовать «Материальная база» и «Оборудование» - помещения, техника для транспортировки товара по складу, персональные компьютеры для ведения учёта товара и т.д.

После описания контекстной диаграммы проводится функциональная декомпозиция - система разбивается на подсистемы и каждая подсистема описывается отдельно (диаграммы декомпозиции). Затем каждая подсистема разбивается на более мелкие и так далее до достижения нужной степени подробности. В результате такого разбиения, каждый фрагмент системы изображается на отдельной диаграмме декомпозиции (Рис. 10).

Рис. 10 Диаграмма декомпозиции IDEF0. Функционирование управления запасами

Весь процесс «Функционирования управления запасами» (рис.4.3) разбивается на 4 подпроцесса:

«Закупка товара» иллюстрирует процесс приобретения товара у поставщиков, а также выявление необходимого товара, определения спроса на данный товар и его необходимое количество для закупки;

«Хранение товара» представляет собой процесс сортировки закупленных товаров, их комплектацию, дробление, укрупнение партий продукции, ее стандартизацию и хранение;

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

«Продажа товара» - процессы по организации продажи товара покупателям.

После дальнейшего разбиения процесса «Закупки товара» диаграммы получаем диаграмму декомпозиции второго уровня (на рис.11).

Рис. 11 Диаграмма декомпозиции IDEF0. Закупка товара

Общие стрелки, перешедшие с диаграммы верхнего уровня, и стрелки, используемые на данном уровне, опишем с помощью данных из отчета:

Выбранное предложение: Выбранное предложение при покупке товара, определённое после анализа рынка предложений данного товара.

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

Информация о приобретённом товаре: Данная информация включает сведения о купленном товаре - наименование, количество, дата изготовления, дата использования, производитель.

Кол-во: Необходимое для покупки количество товара.

Конъюнктура рынка: Занимаемое положение предприятия на рынке предоставления соответственных услуг.

Купленный товар: Доставленный товар, который прошёл проверку и готов для транспортировки на склад.

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

Наименование товара: Наименование товара, которое необходимо купить. Наименование было определено на основе данных из отчёта по продажам - количеству проданного товара и его остаткам на складе.

Нормативы складского учёта: К нормативам складского учёта относятся правила и требования ведения работы склада, примерами данных нормативов являются - правила ведения учёта товара на складе, требования к хранению товара, обязанности работников склада.

Оборудование: К оборудованию относятся, как персональные компьютеры, необходимые для занесения данных по товару, учёта товара, так и оборудование, используемое для транспортировки товара по складу.

Определённый спрос: Объёмы продаж на закупаемый товар, рассчитанный за определённый промежуток времени.

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

Первичные документы: К первичным документам относятся - список товара и заявка на оформление покупаемого товара.

Персонал: Персонал, работающий на данном предприятии - работники бухгалтерии, отделов продаж и закупок, кадров и складские работники.

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

Товар: Поставленный товар, который был предварительно заказан.

После разбиения диаграммы «Хранение товара» получаем диаграмму декомпозиции второго уровня (на рис. 4.5).

Рис. 12 Диаграмма декомпозиции IDEF0. Хранение товара

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

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

На диаграмме декомпозиции в нотации IDEF3 (рис.13) иллюстрируется «Учёт товара». Учёт товара включает в себя работу с БД, контроль имеющихся товарных запасов и их срока годности.

Как только все данные по товару занесены в БД или откорректированы, выполняются последующие за перекрестком (AND) процессы:

 «Контроль сроков годности товара»;

 «Контроль уровня товарных запасов».

Эти процессы выполняются в виде запросов из БД.

Рис.13 Диаграмма декомпозиции IDEF3. Учёт товара

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

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

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

Декомпозируя процесс «Продажа товара», получаем следующую диаграмму (рис.14):

Проектирование продажи товара осуществляется следующим образом:

Отдел продаж принимает от покупателя заявку на приобретение товара;

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

Оформляется покупка, и данные о покупке в дальнейшем используются для создания отчёта о продажах;

Выдача товара осуществляется при оплаченном чеке, товар сопровождается накладной;

При необходимости осуществляется доставка товара.

Рис.14 Диаграмма декомпозиции IDEF0. Продажа товара

Дополним cпроектированyю в BPwin ИС «Управление товаром на складе» древовидной диаграммой (Node Tree Diagrams) (рис.15).

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

Рис.15 Древовидная диаграмма

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

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

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

Заполнение других справочников происходит в процессе работы.

Для ввода нового или изменения данных существующего контрагента нужно выбрать пункт меню «Справочники \ Контрагенты». В списке справочника могут быть выполнены стандартные, для 1С 8.1, действия: добавить, изменить, скопировать, удалить, отбор, сортировка, настройка списка, вывод списка на печать. Для ввода нового контрагента нужно выбрать группу в которой будет находится новый контрагент и нажать кнопку «Добавить», откроется форма для ввода данных. По бумажным документам вносится вся необходимая информация. В случае вызова данных из другого справочника, например «БанковскийСчет», в открывшейся для выбора форме можно редактировать данные этого справочника без входа в него через основное меню.

Рисунок 16 Новый контрагент

Другие справочники заполняются аналогично.

Для ввода нового документа «Поступление ТМЦ» необходимо выбрать пункт меню «Документы \ Поступление ТМЦ» или «Журналы \ Складской». В первом случае сразу откроется форма ввода нового документа, а во втором – журнал документов. В новом документе, при необходимости меняются номер и дата документа, указывается комментарий и заполняется табличная часть. Над табличной частью документа могут быть выполнены стандартные, для 1С 8.1, действия: добавить, изменить, скопировать, удалить, отбор, сортировка, настройка списка, вывод списка на печать.

Рисунок 17 Ввод нового документа «Поступление ТМЦ»

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

Рисунок 18 Отчет «Остатки»

Для окончания работы с системой необходимо выбрать пункт меню «Файл \ Выход». При этом система выполнит закрытие открытых объектов и приложение будет закрыто.

Заключение

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

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

Для графического представление разрабатываемых бизнес процессов использовалось CASE-средство верхнего уровня All Fusion Process Modeler BPwin. Инфологическая модель построена при помощи All Fusion Process Modeler Erwin и отражает предметную область ИС (управление товарными запасами на складе) в виде совокупности информационных объектов и их структурных связей.

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

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

1. Аглицкий Д.С., Аглицкий И.С. Рынок информационных технологий: проблемы и решения. - М.:2014
2. Баронов В.В. Автоматизация управления предприятием.- М.: ИНФРА-М, 2014
3. Тютюник А.В., Шевелев А.С. Информационные технологии в банке - М.: Издательская группа "БДЦ-пресс", 2013.
4. Митичкин С.А. Разработка в системе 1С:Предприятие 8.1, - М.: ООО «1С-Паблишинг», 2013. – 413 с.: ил.
5. Габец А.П., Гончаров Д.И., Козырев Д.В., Кухлевский Д.С., Радченко М.Г. Профессиональная разработка в системе 1С:Предприятие 8 (+CD) / Под ред. Радченко М.Г. – М.: «1С-Паблишинг»; СПб.: Питер, 2014. – 808 с .:ил.
6. Радченко М.Г. 1С:Предприятие 8.1 Практическое пособие разработчика
7. Митичкин С.А. Разработка в системе 1С:Предприятие 8.1, - М.: ООО «1С-Паблишинг», 2013. – 413 с.: ил.
8. Вендров А.М. CASE технологии Современные методы и средства проектирования информационных систем М.: Финансы и статистика, 1998. - 176 с.: ил.;
9. Диго С.М. Проектирование и использование баз данных Учебник. М.: Финансы и статистика. 1995 г;
10. Основы построения баз данных под ред. А.Д. Хомоненко Санкт-Петербург, 2014;