Загрузка...
Учебная работа. Реферат: Разработка ИС музыкального магазина Аккорд с использованием диаграмм UML
ГОУ ВПО «Санкт-Петербургский муниципальный
инженерно-экономический институт»
Филиал в г. Чебоксары
отчет
по учебной практике по специализации
на тему «Разработка ИС музыкального магазина «Аккорд»
с внедрением диаграмм UML»
Выполнил:
студент гр 92-05
Моргалев С. О.
Проверила:
Алякина А. А.
Чебоксары 2010
Содержание
Введение___________________________________________________________4
1. Виды диаграмм UML _____________________________________________6
1.1. Диаграмма прецедентов___________________________________________7
1.2. Диаграмма классов_______________________________________________9
1.3. Диаграмма последовательностей___________________________________10
1.4. Диаграмма состояний____________________________________________11
1.5. Диаграмма деятель_________________________________________12
2. Разработка ИС музыкального магазина «Аккорд»_____________________14
2.1. Подготовительная информация_____________________________________14
2.1.1.Короткая информация о компании_________________________________14
2.2.Видение выполнения проекта______________________________________15
2.3 .отчет о обследовании___________________________________________15
2.3.1.Анализ имеющегося уровня автоматизации______________________15
2.3.2.Общие требования к ИС_________________________________________16
2.3.3.Формы документов_____________________________________________17
2.3.4.Описание системы учета_________________________________________18
2.3.5. Перечень типовых хозяйственных операций и их отражение в провод- ках_______________________________________________________________19
2.3.6.Организационная диаграмма_____________________________________20
2.3.7.Описание состава автоматизируемых бизнес-процессов______________21
2.3.8.Диаграммы прецедентов_________________________________________21
2.3.9.Физическая диаграмма__________________________________________23
2.3.10.Описания бизнес-процессов_____________________________________23
2.3.11.Формирование бизнес-процессов________________________________24
2.3.12. Спецификации опций ИС____________________________________29
2.3.13. Проектирование реализации операций бизнес-процесса в информационной системе____________________________________________31
Заключение________________________________________________________34
Перечень использованной литературы___________________________________35
приложение________________________________________________________36
Введение
В крайнее десятилетие в компьютерном мире наметилась тенденция моделирования сложных систем зрительными (приятными) моделями. При этом в новейших способах проектирования сложных компьютерных систем, к примеру ООП и ООАП, приятные модели весьма нередко связываются с таковыми зрительными видами как «взоры», направленные на сложную систему с разных точек зрения. Набор из нескольких приятных моделей (модельных взглядов) делает в сознании профессионалов интегральный образ сложной компьютерной системы, которую они вместе проектируют. Совместно с тем, приятные модели служат действенным средством документирования компьютерных систем и их программных обеспечений, также языком общения меж программерами, системными аналитиками и заказчиками систем.
Более известными зрительными моделями, применяемыми для проектирования компьютерных систем и их программных обеспечений, являются диаграммы языка UML и эталона IDEF0, таблицы и диаграммы эталона IDEF1X. Эти зрительные модели имеют математическую базу в виде теорий графов, множеств и матриц.
Исходный шаг внедрения информационной системы на предприятии – это проработка проекта ИС на шаге консалтинга. На данном шаге нужно предугадать сбор первичных данных, на базе которых будут рассчитываться характеристики системы. Решения о том кто, когда, по какому событию, при каких критериях регистрирует эти данные в ИС, должны быть зафиксированы в документах проекта: ролях юзеров, бизнес-процессах, регламентах, требованиях к функционалу.
Также нужно учитывать и юридический нюанс. В современных ИС имеются развитые средства реализации финансово-юридических структур компаний, но для опции этих средств, структура и документооборот должны быть проанализированы и описаны на шаге формирования проекта. Таковым образом, будет достигнута Интеграция ИС с финансово-юридическим уровнем системы управления предприятием.
Интеграция информационной системы и системы управления на процедурном уровне обеспечивается на шаге консалтинга путём разработки, оптимизации и согласования бизнес-процессов. Бизнес-процессы разрабатываются в тесноватой связи с иными документами организационного дизайна компанией. к примеру, права участников бизнес-процессов должны быть согласованы со структурой управления, а выполняемые функции — с должностными инструкциями. При внедрении ИС нужно детализировать бизнес-процессы до документов ИС, что дозволяет в предстоящем употреблять их, в качестве инструкций операторов, также для формирования сценариев обучения юзеров.
В итоге исследования состава, содержания и процедур формирования главных документов, которые создаются в процессе типового проектирования информационной системы, требуется создать диаграммы бизнес-процессов на базе их вербального описания, которое выходит в итоге обследования деятель гипотетичного компании «Аккорд».
Целью моей работы является разработка документов, нужных для опции типовой ИС, и проектирование реализации операций бизнес-процесса в информационной системе.
1.Виды диаграмм UML
Свою историю унифицированный язык объектно-ориентированного моделирования ведет с конца 80х — начала 90х годов. Фактически создание UML началось в 1994 году. В это время Грэйди Буч (Grady Booch) и Джеймс Рэмбо (James Rambaugh) начали соединять воединыжды несколько способов объектно-ориентированного моделирования в фирме Rational Software. И уже в 1995 году была представлена спецификация способа, нареченного Unified Method. 1-ая версия UML была принята консорциумом OMG (Object Management Group) в январе 1997 года. Утвержденная же в сентябре версия UML 1.1 была принята на вооружение главными компаниями — производителями программного обеспечения, таковыми, как Microsoft, IBM, Hewlett-Packard и производителями CASE-средств, которые реализовали поддержку UML в собственных программных продуктах (Paradigm Plus, Microsoft Visual Modeler for Visual Basic, Delphi и др.)
Создатели и создатели UML представляют его как язык для определения, представления, проектирования и документирования программных систем, бизнес-систем и остальных систем различной природы. UML описывает нотацию и метамодель. Нотация представляет собой совокупа графических объектов, которые употребляются в моделях; она является синтаксисом языка моделирования.
Всепригодный язык объектного моделирования UML не зависит от языков программирования и, вследствие этого, может поддерживать хоть какой объектно-ориентированный язык программирования. Он является открытым и дозволяет расширять ядро.
Зрительные модели обширно употребляются в имеющихся разработках управления проектированием систем, сложность, масштабы и функциональность которых повсевременно растут. В практике эксплуатации программных информационных систем повсевременно приходится решать такие задачки как перераспределение вычислений и данных, обеспечение проведения параллельных вычислений, репликация баз данных, обеспечение сохранности доступа к информационным системам, оптимизация балансировки перегрузки систем, устойчивость к сбоям и почти все другое.
Языки и способы моделирования состоят, обычно, из последующих составных частей:
3 Концепции моделирования, их семантика.
4 Зрительное одной из принципиальных заморочек, решаемых при применении зрительных способов моделирования, является все растущая сложность систем и проектов. Наступает момент, когда становится неосуществимым представить всю систему в целом, возникает отрывочность познаний о системе, и происходит утрата управления.
2-ое существенное достоинство — упрощение общения заказчика и разраба. Это соединено как с завышенной наглядностью модели, так и с ее гибкостью и динамичностью.
Само собой, решаются вопросцы уменьшения времени, затрачиваемого на разработку проекта, его цены и увеличения свойства.
1.1.Диаграмма прецедентов (use case diagram)
На диаграмме прецедентов
представлены прецеденты и актеры (личный вариант классов), также дела меж ними. Диаграммы прецедентов относятся к статическому виду системы исходя из убеждений прецедентов использования. Они в особенности важны при организации и моделировании поведения системы.
Диаграммы использования обрисовывают функциональность ИС, которая будет видна юзерам системы. «Любая функциональность» изображается в виде «прецедентов использования» (use case) либо просто прецедентов. Прецедент — это обычное взаимодействие юзера с системой, которое при всем этом:
• обрисовывает видимую юзером функцию,
• может представлять разные уровни детализации,
• обеспечивает достижение определенной цели, принципиальной для юзера.
Прецедент обозначается на диаграмме овалом, связанным с юзерами, которых принято именовать действующими лицами (актеры, actors). Действующие лица употребляют систему (либо употребляются системой) в данном прецеденте. Действующее лицо делает некую роль в данном прецеденте. На диаграмме изображается лишь одно действующее лицо, но настоящих юзеров, выступающих в данной роли по отношению к ИС, быть может много. Перечень всех прецедентов практически описывает многофункциональные требования к ИС, которые лежат в базе разработки технического задания на создание системы.
На диаграммах прецедентов, не считая связей меж действующими лицами и прецедентами, может быть внедрение еще 2-ух видов связей меж прецедентами: «внедрение» и «расширение» (рис. 1.1). Связь типа «расширение» применяется, когда один прецедент подобен другому, но несет несколько огромную многофункциональную нагрузку. Ее следует использовать при описании конфигураций в обычном поведении системы. Связь типа «внедрение» дозволяет выделить некоторый фрагмент поведения системы и включать его в разные прецеденты без повторного описания.
Рис. 1.1 Диаграмма прецедентов учебного заведения
1.2.Диаграмма классов (class diagram)
Класс (class) — категория вещей, которые имеют общие атрибуты и операции.
Продолжая тему, скажем, что классы — это строй блоки хоть какой объектно-ориентированной системы. Они представляют собой описание совокупы объектов с общими атрибутами, операциями, отношениями и семантикой. При проектировании объектно-ориентированных систем диаграммы классов неотклонимы.
Классы употребляются в процессе анализа предметной области для составления словаря предметной области разрабатываемой системы. Это могут быть как абстрактные понятия предметной области, так и классы, на которые опирается разработка и которые обрисовывают программные либо аппаратные сути.
Диаграмма классов — это набор статических, декларативных частей модели. Диаграммы классов могут применяться и при прямом проектировании, другими словами в процессе разработки новейшей системы, и при оборотном проектировании — описании имеющихся и применяемых систем. информация с диаграммы классов впрямую отображается в начальный код приложения — в большинстве имеющихся инструментов UML-моделирования вероятна кодогенерация для определенного языка программирования (обычно Java либо C++). Таковым образом, диаграмма классов — конечный итог проектирования и отправная точка процесса разработки.
Рис. 1.2. Диаграмма классов учебного заведения
1.3.Диаграмма последовательностей (sequence diagram)
Диаграммы последовательностей и кооперации являются личными вариантами диаграмм взаимодействия. Этот вид диаграмм употребляется для четкого определения логики сценария выполнения прецедента. Диаграммы последовательностей показывают типы объектов, взаимодействующих при выполнении прецедентов, сообщения, которые они отправляют друг другу, и любые возвращаемые значения, ассоциированные с этими сообщениями. Диаграммы взаимодействия относятся к динамическому виду системы. При всем этом диаграммы последовательности отражают временную упорядоченность сообщений, а диаграммы кооперации — структурную компанию обменивающихся сообщениями объектов. Эти диаграммы являются изоморфными, другими словами могут быть преобразованы друг в друга. Прямоугольники на вертикальных линиях демонстрируют «время жизни» объекта. Полосы со стрелками и надписями заглавий способов означают вызов способа у объекта.
Рис. 1.3 Диаграмма последовательностей работы лифта
1.4.Диаграмма состояний (statechart diagram)
Д
иаграммы состояний (Statechart diagrams) употребляются для описания поведения сложных систем. На диаграммах состояний представлен автомат, включающий в себя состояния, переходы, действия и виды действий. Диаграммы состояний относятся к динамическому виду системы; в особенности они важны при моделировании поведения интерфейса, класса либо кооперации. Они определяют все вероятные состояния, в каких может находиться объект, также процесс смены состояний объекта в итоге неких событий. Эти диаграммы обычно употребляются для описания поведения 1-го объекта в нескольких прецедентах.
Прямоугольниками представляются состояния, через которые проходит объект во время собственного поведения. Состояниям соответствуют определенные значения атрибутов объектов. Стрелки представляют переходы от 1-го состояния к другому, которые вызываются выполнением неких функций объекта. Имеется также два вида псевдо-состояний: изначальное состояние, в каком находится лишь что сделанный объект, и конечное состояние, которое объект не покидает, как туда перебежал.
Рис. 1.4 Диаграмма состояний прохождения академического курса
1.5.Диаграмма деятель (activity diagram)
Диаграмма деятель
— это личный вариант диаграммы состояний; на ней представлены переходы потока управления от одной деятельности к иной снутри системы. Диаграммы деятель относятся к динамическому виду системы; они более важны при моделировании ее функционирования и отражают поток управления меж объектами. Этот вид диаграмм обычно употребляется для описания поведения, включающего в себя огромное количество параллельных действий.
Главными элементами диаграмм деятель являются :
•овалы, изображающие деяния объекта;
• линейки синхронизации, указывающие на необходимость окончить либо начать несколько действий (модель логического условия «И»};
• ромбы, отражающие принятие решений по выбору 1-го из маршрутов выполнения процесса (модель логического условия «ИЛИ»);
• стрелки — отражают последовательность действий, могут иметь метки критерий.
На диаграмме деятель могут быть представлены деяния, надлежащие нескольким вариантам использования. На таковых диаграммах возникает огромное количество исходных точек, так как они отражают сейчас реакцию системы на огромное количество наружных событий. Таковым образом, диаграммы деятель разрешают получить полную картину поведения системы и просто оценивать воздействие конфигураций в отдельных вариантах использования на конечное деятельность быть может предана предстоящей декомпозиции и представлена в виде отдельной диаграммы деятель либо спецификации (словесного описания).
Рис. 1.5 Диаграмма деятель дизайна заказа в Интернет-магазине
Глава 2. Разработка ИС музыкального магазина «Аккорд»
2.1. Подготовительная информация
2.1.1.Короткая информация о компании «Аккорд»:
Магазин «Аккорд» закупает музыкальные инструменты и концертное оборудование в больших компания Рф и забугорных государств и продаёт их в розницу и оптом.
Главные бизнес-процессы компании — закупки, складирование припасов, реализации, взаиморасчеты с поставщиками и покупателями.
Уровень конкуренции для компании в крайнее время возрос, потому что на Рынок вышли 2 новейших соперника, к которым перебежала часть клиентов и ряд более обученных служащих ООО «Аккорд».
По подготовительным данным компания хочет прирастить количество магазинов до 3 (на данный момент один магазин).
Адреса и телефоны
Чебоксары, 428000, улица Афанасьева, д.10а
телефон: (8352) 666-666, факс: (8352) 777-77
Контактные лица
Иванов Иван Иванович – Генеральный директор
Петров Петр Петрович – Исполнительный директор
Сидоров Алексей Алексеевич – Директор по маркетингу
Сотрудники:
На момент проведения Диагностики штат организации составляет 5 человек. Главными целями проекта автоматизации организации «Аккорд» являются:
· Разработка и внедрение всеохватывающей автоматической системы поддержки логистических действий компании.
· Увеличение эффективности работы всех подразделений компании и обеспечение ведения учета в единой информационной системе.
2.2. Видение выполнения проекта и границы проекта
В рамках проекта развертывание новейшей системы предполагается выполнить лишь в последующих подразделениях ООО «Аккорд»:
· Отдел закупок;
· Отдел приемки;
· Отдел продаж;
· Отдел маркетинга;
· Группа планирования и маркетинга;
· Группа логистики;
· Учетно-операционный отдел;
· Учетный отдел;
· Отдел сертификации
· Бухгалтерия (лишь в части учета закупок, продаж, поступлений и платежей).
Не рассматривается в границах проекта автоматизация учета главных средств, расчета и начисления зарплаты, управления кадрами. Выходит за рамки проекта автоматизация действий отношений с клиентами.
количество рабочих мест юзеров — 5.
2.3. Отчет о обследовании
2.3.1. Имеющийся уровень автоматизации
Перечень программного обеспечения, применяемого компанией на момент обследования
1) «1С: Предприятие 7.7» («Бухгалтерия», «Торговля», «Заработная плата», «Кадры», «Касса», «Таблица 1
Имеющийся уровень автоматизации
Количество рабочих станций, всего:
47
количество служащих отдела IT
5
количество ПК , сразу работающих в сети
43
наличие и форма связи с удаленными объектами
Терминальная связь со складом
количество рабочих станций на удаленном объекте
15
свойства компов
От Pentium 4 2000 и выше
Операционная система
Windows XP
системы, которые представляется вероятным бросить без конфигурации
«1С: Предприятие 7.7» в модульном составе «Бухгалтерия», «Заработная плата», «Кадры», для работы бухгалтерии
2.3.2. Общие требования к информационной системе
Одно из главных требований организации «Аккорд» к будущему решению заключается в том, чтоб оно было выстроено на фундаменте единой встроенной системы, а работа всех служащих велась в одном информационном пространстве.
Главные многофункциональные требования к информационной системе:
1. Массивные средства защиты данных от несанкционированного доступа. Разграничения доступа к данным в согласовании с должностными обязательствами.
2. Возможность удаленного доступа.
3. Управление припасами. Оперативное получение инфы о остатках на складе.
4. Управление закупками. Планирование закупок в разрезе поставщиков.
5. Управление продажами. Контроль лимита задолженности с возможностью блокировки формирования отгрузочных документов.
6. Полный контроль взаиморасчетов с поставщиками и клиентами.
7. Получение управленческих отчетов в нужных аналитических срезах — как детализированных для менеджеров, так и агрегированных для управляющих подразделений и директоров компании.
2.3.3. Примеры форм отчетных документов
Таблица 2
Примеры форм отчетных документов
отчет о дебиторской задолженности
Регистрацион-ный номер
Кли-ент
Контракт
Дата догово-ра
Сумма по договору
Сумма задолженности
Ожидаемый срок платежа
Коммен-тарий
Итого
отчет о кредиторской задолженности
Информация о материалах/девайсов, услугах, работах
Постав-щик
№ дого-вора
Сумма по дого-вору
Срок оплаты по договору
Дата оплаты
Сумма задолжен-ности
Коммен-
тарий
Инвентарныйкод
Названиематериалатовара
Едизмерения
Требуетсязакупить
Предшествующая дата приобретения
Заглавие поставщика
Дата крайнего приобретения
Стоимость приобретения
2.3.4. Описание системы учета
ООО «Аккорд» употребляет типовой русский план счетов, три аналитики (контрагенты, контракта, регионы).
Таблица3
Фрагмент плана счетов компании
Номер бухг. счета
Наименование счета
01.000
Главные средства
02.000
Амортизация главных средств
03.000
Доходные вложения в вещественные ценности
04.000
Нематериальные активы
05.000
Амортизация нематериальных активов
08.000
Вложения во внеоборотные активы
10.000
Материалы
10.100
Сырье и материалы
10.200
Остальные материалы
10.300
Инвентарь и хозяйственные принадлежности
14.000
Резервы под понижение цены МЦ
16.000
Отклонение в цены МЦ
19.000
НДС по приобретениям
…
…
2.3.5.Перечень типовых хозяйственных операций и их отражение в проводках
Фрагмент описания справочников, применяемых для автоматизации организации «Аккорд», приведен в таблице.
Таблица 4
Справочники, применяемые для автоматизации компании
№
Наименование справочника
Код
Наименование
Клиенты
AC_Pl_00001
клиент
AC_Pk_00001
Покупатель_Постоянные клиенты
Поставщики/подрядчики
B_00001
Банки
L_00001
Личные лица
I_0001
Страховые организации
OTHER_00001
Остальные
Контракта
1- наши услуги
1_COM_D/M/E
Контракт комиссии_Д/М/Г
1_SERV_D_/M/E
Контракт на оказание наших услуг_Д/М/Г
2 — услуги нам
2_COM_D/M/E
Контракт комиссии_Д/М/Г по услугам нам
2_SERV_D/M/E
Контракт на указание Г услуг нам _Д/М
2_COM_D/M/E
Контракт комиссии_Д/М/Г по услугам нам
Код справочника отражает уровни иерархии. Справочники клиентов и договоров имеют трехуровневую структуру. Справочник поставщиков — двухуровневую структуру. В коде справочника для отображения уровня использован знак подчеркивания. к примеру, в коде справочника клиентов 1-ый уровень обозначен знаками «Pl»-покупатель; 2-ой уровень — «Pk»-постоянные клиенты.
2.3.6.Организационная диаграмма
Рис. 2.1. Организационная диаграмма ООО «Аккорд»
2.3.7. Описание состава автоматизируемых бизнес-процессов
Бизнес-процессы компании, подлежащие автоматизации, приведены в последующей таблице:
Таблица 5
Бизнес-процессы, подлежащие автоматизации
№ п.п
Код бизнес-процесса
Наименование бизнес-процесса
1.
Закуп-1
Закупки
Любой бизнес-процесс имеет собственный неповторимый номер. Нумерация бизнес-процессов построена по последующему принципу: «префикс-номер», где префикс обозначает группу описываемых бизнес-процессов, а номер — порядковый номер бизнес-процесса в перечне.
2.3.8 Диаграммы прецедентов
Проектирование хоть какой АИС лучше всего начинать с построения диаграммы прецедентов, описывающей внешнюю границу АИС. Таковая диаграмма именуется главной диаграммой прецедентов. Основная диаграмма прецедентов показана на Рис.2.2.
Рис.2.2. Диаграмма прецедентов ООО «Аккорд»
2.3.9 Физическая диаграмма
Взаимодействие с наружными контрагентами представлено на рис.2.3.
Рис.2.3. Физическая диаграмма ООО «Аккорд»
2.3.10 Описания бизнес-процессов
Бизнес-процессы компании, подлежащие автоматизации, приведены в последующей таблице:
Таблица 6
Бизнес-процессы, подлежащие автоматизации
Номер бизнес-процесса
Заглавие бизнес-процесса
1Пл_Зак
Планирование закупок
2.3.11.Формирование бизнес-процессов.
Бизнес – процесс «Планирование закупок, формирование заказов поставщикам»
Общее описание бизнес— процесса.
1. Менеджер группы планирования и маркетинга ежесуточно получает от контрагентов данные наружной и внутренней статистики продаж медикаментов в виде отчетов продаж.
2. Для планирования закупок медикаментов Менеджергруппы планирования и маркетинга раз в неделю на основании статистики продаж производит расчет потребности в товаре. В итоге расчета формируется Таблица потребностей в товаре.
3. Определив количество и номенклатуру заказываемых продуктов, менеджер отдела закупок приступает к анализу предложений поставщиков. Данный процесс осуществляется каждый месяц либо при необходимости. Выбираются более прибыльные условия поставки. Для этого сравниваются цены поставщиков. Данные сведения берутся из прайс-листа для закупок. При выбирании поставщика принципиально учитывать предоставляемую отсрочку платежа. Эта информация берется из договоров, отмеченных как приоритетные (действующие). В итоге формируется перечень поставщиков, каждой позиции присваивается признак основного и запасных поставщиков в порядке убывания приоритета.
4. Менеджеротдела закупок каждый месяц на основании Таблицы потребностей в товаре и перечня избранных поставщиков сформировывает графики поставок с указанием сроков и периодичности, но без количества поставки.
5. Каждый месяц опосля определения потребности в товаре Менеджергруппы логистики рассчитывает нужное количество закупок. Нужное количество закупок рассчитывается на основании фактических припасов на складе, нужного малого и наибольшего уровня припасов. Нормы малого и наибольшего количества припасов инсталлируются в деньках. При расчете нужного количества закупки учитывается также время продукта в пути. Таковым образом, данный расчет должен обеспечить возможность бесперебойного отпуска продукта со склада. По результату расчетов формируется план заявок на месяц.
6. Потом в группе логистики раз в день по плану заявок, графику поставок, прайс-листам поставщиков формируются заказы поставщикам.
7. Если предстоит создать заказ ввезенному поставщику, то менеджер группы логистики рассчитывает Издержки на сертификацию, создается отчет о издержек на сертификацию. Издержки на сертификацию проверяются на соответствие внутрифирменным нормам. Данная операция делается при необходимости.
8. Если Издержки на сертификацию превосходят внутрифирменные нормы, то Менеджергруппы логистики повторяет процесс формирования заказов поставщикам. Формируются новейшие заказы.
9. Раз в день приготовленный заказ поставщику акцептуется, заказ должен подписать Менеджерпо логистике и директор Департамента маркетинга и управления товарными припасами.
10. Раз в день Менеджергруппы логистики направляет заказ в отдел закупок. Менеджеротдела закупок направляет заказ поставщику.
Диаграмма деятель
Рис.2.4 Диаграмма действий бизнес-процесса « Планирование закупок, формирование заказов поставщикам»
Формирование таблицы операций.
Таблица 7
Описание операций
Диаграмма и номер операции
Операция
Исполнитель
Как нередко
Входящие документы (документы-основания)
Исходящий документ
1Пл_Зак
1
1. Получение наружной статистики продаж
Менеджергр. планирования и маркетинга
Ежесуточно
Отчет-таблица продаж наружных источников
Нет
1Пл_Зак
2
2. Расчет потребностей в товаре
Менеджергр. планирования и маркетинга
Раз в неделю
Отчет-таблица собственных продаж
отчет-таблица продаж наружных источников
Таблица потребностей в товаре
1Пл_Зак
3
3. Ввод в систему прайс-листов поставщиков
Менеджеротдела закупок
Каждый месяц
Прайс-листы поставщиков
Прайс-листы поставщиков
1Пл_Зак
4
4. анализ предложений поставщиков и работающих договоров
Менеджеротдела закупок
Каждый месяц и при необходимости
Прайс-листы поставщиков
Договоры действующие
Перечень поставщиков
1Пл_Зак
5
5. Выбор поставщиков
Менеджеротдела закупок
Каждый месяц и при необходимости
Перечень поставщиков
Перечень поставщиков с расстановкой ценностей
1Пл_Зак
6
6. Формирование заказов поставщикам с учетом складских остатков, продукта в пути и запасного припаса
Менеджергруппы логистики
Раз в день по плану заявок
План заявок на месяц, график поставок, прайс-листы поставщиков
Заказы поставщику
1Пл_Зак
7
7. Подпись заказа менеджером по логистике, директором ДМ
Менеджергруппы логистики
Раз в день
Заказы поставщику
Заказы поставщику акцептованные
1Пл_Зак
8
8. Направление заказа в отдел закупок
Менеджергруппы логистики
Раз в день
Заказы поставщику акцептованные
Заказы поставщику акцептованные
1Пл_Зак9
9. Направление заказа поставщику
Менеджеротдела закупок
Раз в день
Заказы поставщику акцептованные
Заказы поставщику акцептованные
Таблица 8
Формирование таблицы описания документов
Диаграмма №
Составляемый документ
Операция
Исполнитель
Как нередко
Документы-основания
Реестр, в каком
1Пл_Зак
1
1. Таблица потребностей в товаре
Расчет потребностей в товаре
Менеджергр. планирования и маркетинга
Еженедель-но
отчет-таблица собственных продаж
Реестр статистических отчетов
1Пл_Зак
2
2. Перечень поставщиков с расстановкой ценностей
Выбор поставщиков
Менеджеротдела закупок
Каждый месяц и при необходимости
Перечень поставщиков
Нет
1Пл_Зак
3
3. Заказы поставщику
Формирование заказов поставщикам с учетом складских остатков, продукта в пути и запасного припаса
Менеджергруппы логистики
Раз в день по плану заявок
План заявок на месяц, график поставок, прайс-листы поставщиков
Реестр заказов
1Пл_Зак
4
4. Заказы поставщику акцептованные
Подпись заказа менеджером по логистике, директором ДМ
Направление заказа в отдел закупок
Направление заказа поставщику
Менеджергруппы логистики
Раз в день
Заказы поставщику
Заказы поставщику акцептованные
Реестр заказов
Пример документа на оформление заказа приведен в приложении.
2.3.12. Спецификации опций ИС
Логистика
· Прогноз закупок, продаж, припасов.
· Описание хранения с внедрением склада, палет и размещения.
· ABC-анализ по данным юзером аспектам ABC-анализа по реализации, себестоимости и марже.
· Просмотр номенклатуры на карантинном складе на любом шаге контроля свойства.
· Поддержка штрих-кодов.
Сводное планирование
· Расчет потребности в материалах и мощностях.
· Прогнозы закупок и продаж. Возможность обзора длительных потребностей по закупке, производству и ресурсам.
· Возможность расчета короткосрочных потребностей на базе имеющихся заказов и/либо прогнозного планирования.
· Получение сводного плана по заказам.
· Система может предложить внести последующие конфигурации к имеющимся и спланированным заказам: Повышение количества заказа, Уменьшение количества заказа, Отложить выполнение заказа либо закупки
Учет договоров
· Ведение юридической инфы о договорах с клиентами и поставщиками, критериях оплаты, контактах и ответственных
· Привязка затратных и оплат к определенному договору (указание контракта в строчках журналов ГК, заказах, закупках, затратных и оплатах с следующим переносом в проводку по клиенту/поставщику)
· Включение атрибутов договоров в предложения по оплате
· Автоматическое/периодическое сравнение проводок по контрагентам и договорам
· Форма ручного сравнения в рамках договоров
· Сальдо расчетов в рамках отдельного контракта
· Номер контракта в проводках по курсовой разнице
· Переход от моделей предметной области к многофункциональной модели системы
2.3.13. Проектирование реализации операций бизнес-процесса в информационной системе
Таблица 9
Реализация операций бизнес-процесса
«Планирование закупок и размещение заказов поставщикам»
Номер операции на диаграмме
Операция
Нужные разработки
Специфичность опции
Функциональность (модуль) системы
ПлЗак
Получениевнутреннейстатистики
Разработка узла хранения данных статистики продаж
Коды клиентов в файле соответствуют шифровке в Системе
Продажиклиенты
Разработка механизма импорта статистики
Единицы измерения номенклатуры соответствуют единицам измерения в Системе
2 (1Пл_Зак)
2. Расчет потребностей в товаре
Разработка механизма автоматического формирования малого и наибольшего припаса препаратов (ассортиментный план на период планирования) эффективности закупок (ABC и XYZ систематизации)
Сводное планирование, логистика, торговля
3 (1Пл_Зак)
3. Регистрация прайс-листов поставщиков в системе
Разработка механизма импорта электрической версии прайс-листа в форму «коммерческого соглашения»
В системе регестрируется один базисный прайс-лист, на его базе формируются все остальные прайс-листы
Коммерческие соглашения
4 (1Пл_Зак)
4. Формирование заказов поставщикам с учетом складских остатков, продукта в пути и запасного припаса
Разработка взаимосвязанных данных таблиц Заказов, Складских остатков, продукта в пути, Запасных заказов
При заполнении в заказе поля «количество» система сначала «просматривает» количество продуктов на складе. При недостающем количестве продуктов на складе система обращается к таблице с данными о запасных припасах. При недостающем количестве запасных припасов система производит поиск данной в заказе номенклатуры в таблице продукты в пути
Сводное планирование, логистика, торговля
5
(1Пл_Зак)
5. Проверка суммы издержек на сертификацию на непревышение нормы
Разработка метода проверки суммы издержек на сертификацию на непревышение внутрифирменной нормы
Сводное планирование, логистика, торговля
6
(1Пл_Зак)
6. Подпись заказа менеджером по логистике, директором
Создать функцию утверждения строк спланированных заказов
Результатом процедуры «Сводное планирование» в форме «Спланированные заказы» являются строчки. Опосля оценки строк в форме спланированные заказы нужно провести функцию одобрения (утверждения) строк спланированных заказов
Сводное планирование, логистика, торговля
7
(1Пл_Зак)
7. Напраление заказа в отдел закупок
Разработка многопользовательской системы, прав доступа к документам
Сводное планирование, логистика, торговля
Заключение
Перспектива развития объектно-ориентированного способа проектирования довольно велика. Его различает последующее:» объектно-ориентированные системы наиболее открыты и легче поддаются внесению конфигураций, так как их система базируется на устойчивых формах. Это дает возможность системе развиваться равномерно и не приводит к полной ее переработке даже в случае существенных конфигураций начальных требований.» К недочетам относятся: некоторое понижение производительности функционирования ПО и высочайшие начальные Издержки, эти недочеты не настолько существенны в целом и на чаше весов перевес будет в сторону плюсов.
В данной работе было проведено обследование бизнес-процесса «Планирование закупок, формирование заказов поставщикам» деятель организации «Аккорд».
В итоге исследования состава, содержания и процедур формирования главных документов, были разработаны диаграммы: организационная, прецедентов, физическая, также диаграмма деятель бизнес-процесса «Планирование закупок и размещение заказов поставщикам» и спроектирована реализация операций бизнес-процесса в информационной системе.
Данный шаг проектирования информационной системы завершает стадию разработки технического задания и дозволяет перейти к предстоящей разработке ИС – стадии рабочего проектирования.
Перечень использованной литературы:
1. Бойко В.В., Савинков В.М. Проектирование баз данных информационных систем. – М.: деньги и статистика, 2004. – 351 с.
2. Джексон Г. Проектирование реляционных баз данных для использования с микроЭВМ. -М.: мир, 2005. – 252 с.
3. Лемке Джуди. Microsoft Office Visio 2003. Шаг за шагом: практ.пособие/ Пер. с англ. – М.: «СП ЭКОМ», 2006. -252 с.
4. Леоненков А. Самоучитель UML. Серия «Самоучитель». — СПб.: BHV-Санкт-Петербург, 2007 — 304 с.: ил.
5. Мартин Дж. Планирование развития автоматических систем. – М.: Деньги и статистика, 2005. – 196 с.
6. Мейер М. Теория реляционных баз данных. – М.: мир, 2006. – 608 с.
7. Проектирование информационных систем: курс лекций: учебное пособие для студентов вузов, обучающихся по специальностям в области информационных технологий / В.И. Грекул, Г.Н. Денищенко, Н.Л. Коровкина. – М.:веб-Институт Информационных технологий, 2005. – 304 с.
приложение
Шбл=16+8+3*(64+8)+0,5*5+2,2*5=253,5
Шгр=3*(18+1)=57, 33, 9, 48, 27, 18, 21
Вбл=8+8+20+9*8+6*2+0,5*5+2,2*5+11=140,7
Затратная
Отг
Код___
Склад №___
Дата_____
Шифрформы
Регистр №
________
№
Наименование
продукции
Шифр продукции
Ед. изм.
количество
Наличие на складе
Стоимость руб.
Контрольная сумма
1
2
3
4
5
6
7
5+6+7
Подписи Директор М.П.
Гл. бухгалтер
]]>