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

Физическая модель представляет собой модель данных для конкретной СУБД (Система Управления Баз Данных). Именно по ней можно будет сгенерировать SQL (StructuredQueryLanguage) скрипты для создания базы данных. Если в логической модели использовались обобщения системы типов, то в процессе преобразования к физической, типы данных для всех атрибутов, полей, таблиц будут приведены к системе типов выбранной СУБД. Для того чтобы произвести преобразование логической модели в физическую и сгенерировать SQL скрипт на создание для СУБД MS Access, воспользуемся программным средством OpenModelSpher
...

Введение 4
1 Разработка плана – графика выполнения работы 5
2 Анализ предметной области и разработка функциональной модели IDEF0 "Как есть" 6
2.1 Основные понятия и определения 6
2.2 Объект исследования 7
2.3 Планирование проекта (диаграмма Ганта) 7
2.4 Разработка модели КАК ЕСТЬ 7
Основная функциональность: 10
Преимущества перед аналогами: 10
Модельный ряд: 11
3Разработка предложений по совершенствованию деятельности работника отдела 13
Разработка функциональной модели «Как должно быть» 14
Повышение эффективности работы отдела закупок на платформе 1С: Предприятие 16
Разработка технического задания 21
Разработка DFD - модели потоков данных 26
Разработка концептуальной модели базы данных на основе представления пользователя 29
Разработка логической модели базы данных 30
Список использованной литературы 31

В данной работе рассмотрим разработку проекта авизированной подсистемы .
Изначально будем опираться на теоритический поход сформированный авторами учебника «Технология разработки программных продуктов» [1]. Автор предлагает использовать различные модели для разработки программных продуктов.
Это, например модель,прототипирования, в ее основу положено использование прототипа будущей программы. Т.е. используется базовая модель, которая дорабатывается под новую задачу клиента.
Следующий вариант разработки модели это спиральная модель - когда разработка программы идет по спирали, плавно переходя от одного этапа к другому. Такое проектирование используется для дорогостоящих проектов.
Периодически применяется водопадная модель, в ней также все последовательно, но недостатком такой модели яв ляется то, что нет возможности вносить поправки от следующего этапа на предыдущем.

Функциональная модель строится в рамках концепции IDEF0 (Integration definition for function modeling), которая отражается в виде графической нотации, предназначенной для формализации и описания бизнес-процессов. Данный метод обеспечивает групповую работу над созданием модели, с непосредственным участием всех аналитиков и специалистов, занятых в рамках проекта. В нашем случае контекстная диаграмма отражает один функциональный блок, связанный с внешними объектами ТТП ПОП. Так как исходная функциональная модель является функционально упрощенной (состоит из одного блока) то используем процесс декомпозиции (рис. 2.1) для детализации блоков и функциональных связей. Декомпозиция позволяет постепенно и структурировано представлять модель системы в виде иерархической структуры отдельных диаграмм, что делает ее менее перегруженной и легко усваиваемой. В процессе изучения предметной области ТТП ПОП в программе iGrafx IDEF0 2007 была построена функциональная модель «Как есть» (Приложение 2.1). Она описывает одно из таких предприятий с позиции заведующего производством, который в нем работает и досконально знает все нюансы, в том числе неформальные. В дальнейшем данная модель в процессе применения средств автоматизации была трансформирована в соответствующее представление «Как должно быть» (Приложение 2.2). На основании этих изменений и выносится итоговое заключение, которое содержит в себе рекомендации по реорганизации системы управления и создании средств автоматизации.Ramus - кроссплатформенная система моделирования и анализа бизнес-процессовОсновная функциональность: разработка графических моделей бизнес-процессов (поддерживаются нотации IDEF0 и DFD);разработка систем классификации и кодирования (с привязкой к моделям процессов);формирование отчётности по моделям и системе классификации (в виде регламентов бизнес-процессов, должностных инструкций и т.п.).  Преимущества перед аналогами: Эргономичность графического редактора. Редактор поддерживает быструю навигацию по модели, шаблоны часто используемых типов диаграмм, возможность отмены последних действий, "умное" поведение стрелок.Поддержка неограниченного количества атрибутов различных типов.Автоматическое построение иерархических деревьев в классификаторах на основании значений атрибутов.Редактор отчётов поддерживает несколько вариантов настройки: упрощённую (с использованием инструментов редактора и набора ключевых слов) и расширенную (с использованием JavaScript). Шаблоны отчётов могут быть экспортированы и импортированы в формате файлов XML.Гибкий графический интерфейс пользователя.Кроссплатформенность. Использование технологии Java позволяет устанавливать систему под разными видами операционных систем и аппаратных платформ (MS Windows, Mac OS, Linux и т.д.). Модельный ряд: Локальная версия Ramus:Коммерческий продукт для широкого круга пользователей. Покупка может быть осуществлена on-line (см. соответвующий пункт меню).Сетевая версия Ramus:Данная версия предоставляется только корпоративным клиентам вместе с сопутствующими услугами по разворачиванию и поддержке. Функциональность существенно расширена по сравнению с локальной версией.Ramus Educational:Некоммерческий продукт. Ориентирован на использование в обучении.Доступен только в локальном варианте и ограничен по функциональности.Перечень основных ограничений по сравнению с коммерческой локальной версией:ограничен перечень доступных атрибутов классификаторов;отсутствует функциональность для работы с матричными проекциями классификаторов;отсутствует редактор отчётов;отсутствует навигатор по модели.Тем не менее Ramus Educational поддерживает единый формат файлов с локальной версией Ramus. Таким образом, файл созданный в Ramus Educational можно редактировать в локальной версии Ramus  и наоборот (за исключением атрибутов поддерживаемых только в локальной версии Ramus).Также имеется возможность импорта/экспорта файлов в формат IDL BPWin. Таким образом, обеспечивается частичная совместимость с CA ERwin Process Modeler (в части графических моделей IDEF0);В приложении 3 представлена декомпозиция изучаемой модели – декомпозиция это более подробное описание хода выполнения процесса. 3Разработка предложений по совершенствованию деятельности работника отдела После подробного анализа предметной области были выявлены следующие недостатки:менеджеры отдела продаж не всегда успевают вовремя формировать консолидированную заявку на поставку;нет мотивации поставщиков на работу с фирмой менеджер не владеет актуальной информацией по остаткам на складах.Информация о поставщиках хранится в ПП 1С в Бухгалтерии, куда менеджер не имеет доступа.Информация о контрагентах ведется в электронном виде в формате xls, что не отражается в общей системе и недоступно другим сотрудникам.После анализа выявленных недостатков, было принято решение внести изменения в порядок выполнения работы сотрудником Отдела снабжения.В свете разработки требований к подсистеме предлагается автоматизировать следующие выполняемые сотрудником функции.ПроблемаРешениеМенеджеры отдела продаж не всегда успевают вовремя формировать консолидированную заявку на поставкуРазработка единого программного продукта, доступного по сети определенным пользователям позволит отражать и видеть всю информацию. Нет мотивации поставщиков на работу с фирмой Клиент ориентированный подходМенеджер не владеет актуальной информацией по остаткам на складахРазработка единого программного продукта, доступного по сети определенным пользователям позволит отражать и видеть всю информацию.Информация о поставщиках хранится в ПП 1С в Бухгалтерии, куда менеджер не имеет доступаИнформационный обмен данными с помощью выгрузкиИнформация о контрагентах ведется в электронном виде в формате xls, что не отражается в общей системе и недоступно другим сотрудникам.Разработка единого программного продукта, доступного по сети определенным пользователям позволит отражать и видеть всю информацию.Разработка функциональной модели «Как должно быть»В соответствии с установленными проблемами присутствующими в работе сотрудника отдела снабжения.Была разработана функциональная модель автоматизации работы отдела снабжения. (рис 1)Рис. 1 Функциональная модель «Как должно быть»Здесь доминирующим фактором является программный продукт разработанный для автоматизации рабочего места сотрудника отдела снабжения. Под этим подразумевается следующее:Данный программный продукт доступен для работы по сети одновременно несколькими пользователями.Нормативная база соответствует действующим локальным нормативным актам.Поэтому было принято решение разработать техническое задание для создания требуемого программного продукта.Разработка технического заданияНа данном этапе для функционального рабочего места менеджера отдела были разработаны требования на автоматизацию и оформлено проектное задание «Техническое задание». Техническое задание на создание подсистемы «автоматизированное рабочее место сотрудника отдела снабжения» разработано и оформлено в соответствии с ГОСТ 34.602-89, состав которого был определен исходя из сложности объекта разработки.1. Общие сведения:1.1) Автоматизированное рабочее место сотрудника отдела снабжения;1.2)сроки выполнения работ - работы должны быть выполнены в период с 01.01.2014 – 01.04.2014;1.3) порядок предъявления результатов. В силу поэтапного выполнения работ, по окончании выполнения каждого этапа создается документ о его приемке и согласовании. После чего идет выполнение следующего этапа работ.2. Назначение и цели создания подсистемы:2.1)назначение подсистемы – АРМ сотрудника отдела снабжения;2.2) критерии выполнения работы:* сокращение временных затрат на обработку информации;* сокращение временных затрат на получение отчетной документации;* отображение в системе всего процесса работы с заказом;* повышение КПД сотрудника.3. Характеристики объекта автоматизации:3.1) объектом автоматизации является выполнение рабочего функционала сотрудника отдела снабжения, прозрачность информационного потока;3.2) условия эксплуатации системы на объекте автоматизации, ежедневное использование.4. Требования к системе:4.1. Требования к системе в целом:4.1.1) 5 МБ свободного места на жестком диске без учета базы данных;256 МБ оперативной памяти (512МБ для компьютеров с ОС Windows Vista);Требуется клавиатура и мышь;Принтер;Операционная система Windows XP (3-й пакет обновлений) или Windows Vista (1-й пакет обновлений);Процессор Intel Pentium или AMD Athlon с тактовой чистотой от 1000 МГц и выше;Установленная платформа Microsoft .NET Framework 3.0.4.1.2) режимам функционирования – ежедневной деятельности ;4.1.3) к перспективам развития и автоматизации – возможность доработки и дополнения по требованиям пользователей;4.1.4) к численности, квалификации и режиму работы персонала. Численность пользователей на этапе проектирования не ограничена;4.1.5)в случае выхода из строя аппаратной части, предусмотреть возможность восстановления рабочей базы;4.1.6) нет особых требований;4.1.7) к защите информации от несанкционированного доступа. Каждый пользователь системы должен иметь авторизованный доступ в программу;4.1.8) В случае возникновения форс-мажорных ситуация информация восстанавливается из архива. Архив данных базы выполняется через день. Объединяется по полугодиям и хранится на отдельном жестком диске ;4.2. Требования к функциям (задачам) подсистемы:4.2.1) перечень функций (в составе каждой компоненты системы) (оформить после разработки DFD-модели);4.2.2) регламент реализации каждой функции;4.2.3) для каждой функции требования к качеству, форме представления (входных и выходных) данных, точности, ресурсам выполнения.4.3.