Реферат: Разработка ИС музыкального магазина Аккорд с использованием диаграмм 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. Первая версия 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 Визуальное представление элементов моделирования
5 Правила применения элементов моделирования.
Первый компонент — это элементы модели, второй — нотация и третий — принципы использования.
Одной из важных проблем, решаемых при применении визуальных методов моделирования, является все возрастающая сложность систем и проектов. Наступает момент, когда становится невозможным представить всю систему в целом, появляется отрывочность знаний о системе, и происходит потеря управления.
Второе значительное достоинство — упрощение общения заказчика и разработчика. Это связано как с повышенной наглядностью модели, так и с ее гибкостью и динамичностью.
Само собой, решаются вопросы уменьшения времени, затрачиваемого на разработку проекта, его стоимости и повышения качества.
1.1.Диаграмма прецедентов (use case diagram)
На диаграмме прецедентов представлены прецеденты и актеры (частный случай классов), а также отношения между ними. Диаграммы прецедентов относятся к статическому виду системы с точки зрения прецедентов использования. Они особенно важны при организации и моделировании поведения системы.
Диаграммы использования описывают функциональность ИС, которая будет видна пользователям системы. «Каждая функциональность» изображается в виде «прецедентов использования» (use case) или просто прецедентов. Прецедент — это типичное взаимодействие пользователя с системой, которое при этом:
• описывает видимую пользователем функцию,
• может представлять различные уровни детализации,
• обеспечивает достижение конкретной цели, важной для пользователя.
Прецедент обозначается на диаграмме овалом, связанным с пользователями, которых принято называть действующими лицами (актеры, actors). Действующие лица используют систему (или используются системой) в данном прецеденте. Действующее лицо выполняет некоторую роль в данном прецеденте. На диаграмме изображается только одно действующее лицо, однако реальных пользователей, выступающих в данной роли по отношению к ИС, может быть много. Список всех прецедентов фактически определяет функциональные требования к ИС, которые лежат в основе разработки технического задания на создание системы.
На диаграммах прецедентов, кроме связей между действующими лицами и прецедентами, возможно использование еще двух видов связей между прецедентами: «использование» и «расширение» (рис. 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.4 Диаграмма состояний прохождения академического курса
1.5.Диаграмма деятельности (activity diagram)
Диаграмма деятельности — это частный случай диаграммы состояний; на ней представлены переходы потока управления от одной деятельности к другой внутри системы. Диаграммы деятельности относятся к динамическому виду системы; они наиболее важны при моделировании ее функционирования и отражают поток управления между объектами. Этот вид диаграмм обычно используется для описания поведения, включающего в себя множество параллельных процессов.
Основными элементами диаграмм деятельности являются:
•овалы, изображающие действия объекта;
• линейки синхронизации, указывающие на необходимость завершить или начать несколько действий (модель логического условия «И»};
• ромбы, отражающие принятие решений по выбору одного из маршрутов выполнения процесса (модель логического условия «ИЛИ»);
• стрелки — отражают последовательность действий, могут иметь метки условий.
На диаграмме деятельности могут быть представлены действия, соответствующие нескольким вариантам использования. На таких диаграммах появляется множество начальных точек, поскольку они отражают теперь реакцию системы на множество внешних событий. Таким образом, диаграммы деятельности позволяют получить полную картину поведения системы и легко оценивать влияние изменений в отдельных вариантах использования на конечное поведение системы.
Любая деятельность может быть подвергнута дальнейшей декомпозиции и представлена в виде отдельной диаграммы деятельности или спецификации (словесного описания).
Рис. 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» («Бухгалтерия», «Торговля», «Зарплата», «Кадры», «Касса», «Банк») для работы бухгалтерии.
2) Две собственные разработки на базе конфигуратора «1С» — «Закупки» и «Продажи».
3) Собственная разработка на базе FOXPRO для финансового отдела.
4) Excel для планирования продаж.
Таблица 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 | Договор комиссии_Д/М/Г по услугам нам |
Код справочника отражает уровни иерархии. Справочники клиентов и договоров имеют трехуровневую структуру. Справочник поставщиков — двухуровневую структуру. В коде справочника для отображения уровня применен символ подчеркивания. Например, в коде справочника клиентов первый уровень обозначен символами «Pl»-покупатель; второй уровень — «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 |
Подписи Директор М.П. Гл. бухгалтер |