32
Бизнес-процесс «Работа по мероприятиям» разбивается на 2 работы
(рис.9):
учет заказчиков;
ведение журнала мероприятий;
Рис. 8 – Диаграмма декомпозиции бизнес-процесса «Работа с
мероприятиями»
33
Рис. 9– Диаграмма декомпозиции бизнес-процесса «Работа по
мероприятиям»
Входные данные:
Данные справочников;
Сведения о заказчике;
Сведения о мероприятии.
Промежуточные данные: список заказчиков.
Выходные данные: данные по мероприятиям.
Механизмы: сотрудник оргмассового отдела, АСУ «Мероприятия».
Управление: законодательство, нормативные документы,
регламенты и др.
Дерево узлов представлено на рис. 10.
34
Рис. 10 – Дерево узлов
2.3. Техническое задание на разработку АСУ «Мероприятия»
Полный текст технического задания на разработку АСУ
«Мероприятия» приведен в приложении 1.
Полное наименование разрабатываемой систем будет
Автоматизированная система управления «Мероприятия», которая
предназначена для повышения эффективности работы специалиста
организационно-массового отдела, за счет автоматизированного сбора
данных о мероприятиях, сроках и местах проведения и др.
Целью разработки является создание в организации, возможности в
автоматизированном режиме создавать форм такие, как: карточка
35
мероприятия; календарь мероприятий.
Объектом проектирования будет являться документация по работе с
мероприятиями, находящаяся в ведении специалиста организационно-
массового отдела. Данная система должна предоставлять пользователю
возможность создавать учетные формы, вносить в них записи, выполнять
их просмотр, редактирование и удаление, поиск нужной записи, а также
вывод на печать итоговых отчетов.
Основным требованием по совместимости разрабатываемой АСУ
должно бытьтребование совместимости с офисными приложениями ОС
Windows 2000/XP/Vista/7/8/10, а по по функциональности разрабатываемая
АСУ должна обеспечивать автоматизацию деятельности специалиста
организационно-массового отдела, а так же создавать первичные
документы.
В качестве СУБД будет выступать MS SQL Server 2008, среды
программирования – Delphi XE, языка проектирования – Case-средства
BPWin, ERWin.
Выводы по главе II
Для удобства разработки, изучения, применения и модернизации,
АСУ представляют в виде взаимосвязанного набора различных видов
«обеспечения». В соответствии с ГОСТ 24003-84 к основным видам
обеспечения АСУ относятся: информационное, техническое,
лингвистическое, математическое, организационное, программное и
правовое. Наиболее важными из данных видов являются информационное,
техническое, математическое, программное обеспечения.
В рамках выпускной квалификационной работы рассматриваем
математическое, информационное и программное обеспечения АСУ с
36
учетом предварительной формализации бизнес-процесса «Работа с
мероприятиями» и технического задания на разработку АСУ.
Формализация бизнес-процесса «Работа с мероприятиями» включает
в себя построение совокупности диаграмм в нотации IDEF0 (контекстная
диаграмма и диаграммы декомпозиции), а также диаграмму дерева узлов.
Техническое задание на разработку АСУ является
регламентирующим документом, определяющим процесс проектирования
и разработки АСУ «Мероприятия».
37
ГЛАВА 3. ПРОЕКТИРОВАНИЕ И РАЗРАБОТКА ВИДОВ
ОБЕСПЕЧЕНИЯ АСУ «МЕРОПРИЯТИЯ»
3.1. Проектирование и разработка информационного и
математического обеспечения системы
Проектирование и разработка информационного обеспечения
системы предполагает разработку информационной модели АСУ.
Информационная модель является схемой, отражающей преобразование
информационных реквизитов от источников информации до ее
получателей (процесс обработки информации в АСУ). Общий вид
информационной модели АСУ представлен на рис. 11.
Рис. 11 – Информационная модель АСУ
38
Информационная модель отображает процесс ввода исходных
данных и управляющих воздействий на систему, также то, в рамках
моделируемой задачи используются различные справочники и данные, при
этом каждый из справочников, формируется из таблицы. На выходе
моделируемая система предоставляет возможность формирования отчетов.
Анализ построенной информационной модели позволил выделить
ряд моментов:
работа с моделируемой системой осуществляется специалистом по
мероприятиям посредством соответствующей экранной формы;
база данных в рамках моделируемой задачи содержит справочную
и оперативную информацию;
все данные моделируемой системы хранятся в таблицах;
на выходе моделируемой системы специалист по мероприятиям
может получить, помимо данных, различные отчеты.
Классификатором является систематизированный список
наименований объектов, каждому из которых поставлен в соответствие
уникальный код.
В проектируемой АСУ используются системные классификаторы,
которые действуют в пределах конкретной АСУ (табл.2).
Таблица 2
Коды и классификаторы
Идентификатор
Тип кода
Система
кодирования
Метод
классификации
Количество
объектов
Код категории
Простой
Порядковая
Последовательный
Неограниченно
Код мероприятия
Простой
Порядковая
Последовательный
Неограниченно
Код заказчика
Простой
Порядковая
Последовательный
Неограниченно
Код записи
Простой
Порядковая
Последовательный
Неограниченно
39
Вся поступающая в информационную подсистему информация
может быть подразделена на следующие виды: условно-постоянная и
условно-переменная.
К условно-постоянной информации относятся сведения, которые
мало изменяются в течение длительного периода, при этом условно-
постоянная информация вводится в БД достаточно редко. В
проектируемой АСУ к условно постоянной информации относится
справочник категорий. Данные в справочник заносятся в АСУ при ее
первичном запуске.
К условно-переменной информации относятся:
Мероприятия: список названий мероприятий;
Заказчики: заказчик конкретного мероприятия;
Журнал мероприятий: информация о проводимых мероприятиях.
Данные, относящиеся к условно-переменной информации, вносятся
в АСУ по мере необходимости, общее количество – неограниченно. Ввод
данных в АСУ выполняется посредством соответствующих экранных
форм.
Результатная информация в проектируемой АСУ формируется в
виде электронных или бумажных документов. Перечень результатной
информации АСУ «Мероприятия» приведен в табл. 3.
Таблица 3
Результатная информация
Наименование
Периодичность
получения
Получатель
Список заказчиков
По необходимости
Специалист по мероприятиям
Календарь мероприятий
По необходимости
(не реже 1 раза в месяц)
Специалист по мероприятиям
Статистика по
мероприятиям
По необходимости
(не реже 1 раза в месяц)
Специалист по мероприятиям,
руководство фирмы
40
Характеристика и описание результатной информации
представлены в табл. 4.
Таблица 4
Характеристика и описание результатной информации
Идентификатор
Список
заказчиков
Календарь
мероприятий
Статистика по
мероприятиям
Форма представления
Электронный
документ
Электронный
документ
Электронный
документ
Периодичность и сроки
выдачи
По необходимости
По необходимости
(не реже 1 раза в
месяц)
По необходимости
(не реже 1 раза в
месяц)
Получатели
Специалист по
мероприятиям
Специалист по
мероприятиям
Специалист по
мероприятиям
Назначение
Оперативная
информация
Оперативная
информация
Анализ данных,
статистика
Источник данных
(таблицы)
Заказчики
Журнал мероприятий
Журнал мероприятий,
Категории
мероприятий
Перечень реквизитов
Название
заказчика, ФИО
контакта,
Контактный
телефон
Дата мероприятия,
название
мероприятия,
категория
мероприятия,
заказчик
Категория
мероприятия, год,
месяц, число
мероприятий
Выполним проектирование концептуальной модели данных. На
основе описания предметной области, а также моделей бизнес-процесса
выделим следующие сущности и атрибуты:
Категории мероприятий: название категории;
Заказчики: название заказчика, ФИО контакта, контактный телефон;
Мероприятия: название мероприятия;
41
Журнал мероприятий: дата мероприятия, мероприятие, заказчик,
категория мероприятия.
Определим связи между сущностями:
Каждое мероприятие относится к некоторой категории, при этом к
каждой категории может относиться несколько мероприятий (связь
«один-ко-многим»);
Каждое мероприятие проводится для некоторого заказчика
(соответствует запись в журнале мероприятий), при этом каждый
заказчик может заказать проведение нескольких мероприятий (связь
«один-ко-многим»);
Каждой записи в журнале мероприятий соответствует некоторое
мероприятие, при этом каждому мероприятию может
соответствовать несколько записей в журнале, если оно проводится
несколько раз (связь «один-ко-многим»).
ER-диаграмма (диаграмма «сущность-связь») приведена на рис. 12.
Рис. 12 – ER-диаграмма
Каждой сущности поставим в соответствие некоторое отношение,
каждому атрибуту – поле отношения, определим типы полей отношений.
Полученные отношения и их структура представлены в табл. 5-8.