close

Вход

Забыли?

вход по аккаунту

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

код для вставки
8I0z rгэdб
ьиsэиdlииrfi' dиrrrиEвrg ниIоIIIеэ
ЕнЕэвIfохиц вэиdв1. Baoxg.(g
внgаstrЕнне_1 вниdэIвхЕ ввхсниhчIfив
fr
ц64,цоdyефвх.авg
чrrэ.lи7о gохf d кшнь,(вц
rнаЕ/.(rз
(чlrиф оdп)ч.r,соннэrнвdпв11
60 ихsоr.о.lЕоп оIинэшsвdrrвн
оц
\/Jo tIYd rYнноип\гхиФиIrYвх кYнхэ^LIIчв
(YgiIнgJdлJ.э.и
инэии JаJиэdавин^
иIчнн!I8J эdчY^ эоJ иш{хэ gоIгdо)
g Еш{I{frrжildiшал
rинчвоtYdgо оJIIIпэIч
ЕончIrпJvgоtvdgо цoHJTжYots ЕIоннаflJэdчYлэоJ
аонlш\idаrgФ
шfirvааYаФ иохэщ4э эоd их^Yн И ЬI,r,,.gо
EYd:Io о BJ эdЕIJ эинииI
МИНИСТЕРСТВО ОБРАЗОВАНИЯ
И НАУКИ РОССШZСКОЙ ФЕЛРАI+ТI4
ФЕДЕРАЛЬНОЕ ГОС УДАРС ТВ ЕННОЕ
БЮДЖЕТНОЕ ОБРАЗ ОВ АТЕЛЬНОЕ
-о.по"ЪНif
ЖffirЖffii?#fr ffi"J,ffi
и.с.тургЕнЕвА>
Ошryльтет
,имени
Физико-математический
Пlафедра
I|аправление подготовки
Шlаправленность (профилъ)
УТВЕРЖДАЮ
Селютин В.Щ.
< 12 > апреля 2018г.
зАflдццв
на выполнение ВЫtý/скной квалификационной
студента
работы
1. Тема В
Утвержд
3. Исходные данные
4.
Я:::::Т
:КР
к работе нет
(перечень вопросов, подлежащих
разработке)
.п
Перечень
графического матери€lJIа
|.
- не предусмотрен
б, Консулътанты по ВКР (с относящихся
к ним
рЕlзделов) -
".
предусмотрены
Щата выдачи заданиrI <12> апреля 2018г.
Нау.rный руководителъ
ВКР
Задание принял к исполнению
Зубкова Л.Н.
(Фио)
Вильчинская Е.Г.
КАЛЕIЦАРНЬЙ IUIAH
НаименованиБтапов ВКР
Анализ литературы
цредметной области
Рассмотрение бизнес-процессов
предприятия полиграфической
цромышленности
Построен"е дйiфамЙЗЙ".о
Выявление общйБйБа""t к
структуре и функционаJry
проектируемой
Разработка концепту€lJIьных
моделей системы
Структурирование матери€чIа,
arr/lll4
,//Zа
,.?2/lz.
xа//z
Ш-€ф,72/лz.
hT-flaavag&cp
й>Z-ае7rема
_
РиЕDъ
.//.ро/il:
аý
Сryдентка
Нау"rный руководитель
ВКР
Зубкова Л.Н.
4
АННОТАЦИЯ
Выпускная
квалификационная
работа
на
тему
«Проектирование
информационной системы мониторинга предприятия сферы услуг» содержит 58
страниц основного текста, 20 иллюстраций, 1 таблицу, список использованных
источников из 16 наименований.
В работе разрабатывается проект информационной системы мониторинга
полиграфического отдела при печатном издательстве, основной задачей которого
является подготовка и исполнение печатно-издательской деятельности издательства.
Для этого была исследована деятельность отдела и построен сценарий его
работы. В процессе анализа предметной области были определены основные
требования к разрабатываемой системе. На основании выявленных требований был
разработан проект информационной системы мониторинга.
5
ABSTRACT
Final qualification work on the subject "Design of an Information System of
Monitoring of the Enterprise of Services Sector" contains 58 pages of the main text, 20
illustrations, 1 table, the list of the used sources of 16 names.
In work the project of an information system of monitoring of printing department
at printing publishing house which main objective is preparation and execution of printing
publishing of publishing house is developed.
Activity of department was for this purpose studied and the scenario of its work is
constructed. In the course of the analysis of subject domain the main requirements to the
developed system were defined. On the basis of the revealed requirements the project of
an information system of monitoring was developed.
8
СОДЕРЖАНИЕ
ВВЕДЕНИЕ .................................................................................................................. 9
ГЛАВА 1 КРАТКАЯ ХАРАКТЕРИСТИКА ПРЕДПРИЯТИЯ И ЕГО
ДЕЯТЕЛЬНОСТИ...................................................................................................... 11
1.1 Основные сведения ............................................................................................. 11
1.2 Оформление договоров ....................................................................................... 11
1.3 Оформление заказов............................................................................................ 12
1.4 Расчет и оформление плановой калькуляции................................................... 14
1.5 Организационная структура ............................................................................... 16
1.6 Описание методик проектирования ИС ............................................................ 17
1.7 Описание бизнес-процессов предприятия в нотации IDEF0 .......................... 24
1.8 Построение диаграммы потоков данных .......................................................... 29
ГЛАВА 2 ПРОЕКТИРОВАНИЕ И РЕАЛИЗАЦИЯ ИНФОРМАЦИОННОЙ
СИСТЕМЫ МОНИТОРИНГА ДЕЯТЕЛЬНОСТИ ПОЛИГРАФИЧЕСКОГО
ОТДЕЛА ..................................................................................................................... 35
2.1 Общие требования к структуре информационной системы .......................... 35
2.2 Описание используемых при разработке технологий и моделей .................. 36
2.3 Варианты использования информационной системы ..................................... 41
2.4 Архитектура информационной системы .......................................................... 43
2.5 Разработка основных функциональных компонентов .................................... 48
2.6 Концептуальное проектирование базы данных ............................................... 52
2.7 Словарь проекта................................................................................................... 56
2.8 Словарь данных ................................................................................................... 58
ЗАКЛЮЧЕНИЕ ......................................................................................................... 61
БИБЛИОГРАФИЧЕСКИЙ СПИСОК ...................................................................... 63
9
ВВЕДЕНИЕ
Полиграфическая промышленность – одна из немногих, стабильно
развивающихся сегодня в нашей стране отраслей. Поэтому к полиграфии
обращается все больше людей, которые ищут наиболее рациональные современные
методы размножения информации – от однокрасочных бланков и листовок до
многокрасочных
журналов,
буклетов,
проспектов,
открыток
и
другой
высококачественной полиграфической продукции.
Техническое оснащение вновь создаваемой типографии зависит от того,
какую продукцию в ней собираются печатать. Чем больше задач по изданию
разнообразной продукции стоит перед организатором типографии, тем сложнее
будут выглядеть варианты её структуры, организации и оснащения.
На сегодняшний момент существует множество типографий, различающихся
как по размерам, так и по типам выполняемых работ. Типографии могут быть
универсальными или специализироваться на отдельных способах печати и видах
печатной продукции. Также существует ещё один критерий, по которому мы можем
классифицировать их — назовём его «статусом типографии». Существуют как
частные предприятия, преследующие только свои интересы, так и предприятия,
являющиеся подразделениями какого-либо учреждения и выполняющие строго
определённые поручения. Именно о типографии второго типа и пойдёт речь в
данной работе. Примером такой типографии является полиграфический отдел при
печатном издательстве.
Помимо выполнения своих прямых обязанностей, типография (если быть
точнее — работники типографии), находящаяся в подчинении у руководства
издательства обязана регулярно предоставлять отчётность о выполненных работах.
Понятно, что при отсутствии качественного и полного контроля за выполняемыми
работами начальник полиграфического отдела может столкнуться с огромными
трудностями и проблемами.
Любой полиграфический отдел (и вообще любое хозрасчетное структурное
подразделение) нуждается в автоматизированной системе контроля и учёта всех
10
выполняемых работ. Отсюда можно сформулировать основную цель работы —
проектирование системы, способной вести полный учёт работ типографии, которая
будет обладать интуитивно понятным интерфейсом.
Для достижения цели поставлены следующие задачи:
- изучение литературы предметной области;
- построение диаграмм бизнес-процессов предметной области;
- определение общих требований к структуре и функционалу проектируемой
системы;
- разработка концептуальной модели системы;
- разработка эффективного алгоритма шаблонной генерации отчётов;
Объектом исследования является полиграфический отдел предприятия.
Предметом исследования в данной ВКР служит система мониторинга
деятельности для предприятия сферы услуг с целью реинжиниринга его бизнеспроцессов.
Структура работы. Выпускная квалификационная работа состоит из
введения, двух глав основной части, заключения и списка использованных
источников.
11
ГЛАВА 1 КРАТКАЯ ХАРАКТЕРИСТИКА ПРЕДПРИЯТИЯ И ЕГО
ДЕЯТЕЛЬНОСТИ
1.1 Основные сведения
Как уже упоминалось в предыдущем разделе, объектом рассмотрения данной
работы является полиграфический отдел при печатном издательстве
Основной задачей полиграфического отдела является организация и
осуществление
изготовление
редакционно-издательской
книжной
и
иной
деятельности
продукции,
отвечающей
издательства:
требованиям
государственного стандарта.
Хозрасчетные структурные подразделения создаются в составе организации
с подчинением директору издательства в соответствии с профилем структурного
подразделения или в составе структурного подразделения.
Как уже говорилось ранее, основной упор в работе будет сделан не на
техническую составляющую работы полиграфического отдела, а на деятельность,
связанную с ведением отчётности. Другими словами — на документооборот.
1.2 Оформление договоров
Полиграфический отдел выполняют работы на основе заключенных
(оформленных) договоров и заказов. Работы (оказание услуг) выполняемые
структурным подразделением от лица издательства как юридического лица с одной
стороны и юридическим или физическим лицом с другой оформляются
договорами. Основанием для оформления договора является письмо руководителя
организации - заказчика, определяющее перечень выполняемых работ и
гарантирующих ее оплату.
Договор оформляется юридическим или физическим лицом - «Заказчиком» и
издательством (подготовку договора осуществляет правовое управление и
хозрасчетное структурное подразделение, заинтересованное в выполнении
12
договоров) – «Исполнителем».
Обязательным приложением к договору является калькуляция стоимости
выполняемых работ. Начальник типографии, выполняющей работы, рассчитывает
нормы расхода материала и его стоимость, трудоёмкость работ и вместе с
технической документацией передает в планово-экономический отдел для расчёта
калькуляции. Если срок выполнения заказа превышает два месяца «Исполнитель»
представляет вместе с расчетами план-график выполнения договора.
Планово-экономический отдел организации на основе представленных
структурным подразделением данных рассчитывает калькуляцию и передает ее на
утверждение директору. Утвержденная калькуляция вместе с технической
документацией возвращается структурному подразделению – исполнителю работ.
Договор считается заключенным после подписания его обеими сторонами.
Подписанный договор передается на регистрацию в коммерческо-договорной отдел
издательства. Договор оформляется в двух экземплярах по одному для каждой
стороны. После выполнения работ по договору, «Заказчик» и «Исполнитель» в
соответствии с ним, оформляют акт или накладные на выполненные работы.
1.3 Оформление заказов
Заказы
оформляются
на
работы,
выполняемые
структурными
подразделениями организации для других его структурных подразделений.
Основаниями для открытия заказа служат:
- перспективные планы работ, подтвержденные финансовыми ресурсами и
утверждённые директором организации;
- приказ директора;
- служебная записка с резолюцией директора;
- протоколы совещаний, утверждённые директором.
После
оформления
калькуляции
структурное
подразделение
–
«Исполнитель» вместе с Правовым управлением оформляют заказ. После
13
утверждения заказ регистрируется в Правовом управлении и подписывается
исполнителем в графе «Заказ к исполнению принял».
При необходимости
директор, согласовывающий заказ может направить его для дополнительного
рассмотрения в любое структурное подразделение организации (например,
редакционный отдел).
Оформление заказов производится следующим образом:
1. Содержание работ. Предусматривает описание выполняемой работы и её
название в соответствии с планом или служебной запиской.
2.
Исходные
данные
для
выполнения
работ
и
обеспеченность
техдокументацией. Определяет, на основании чего выполняется работа (служебная
записка с описанием работы, техническое задание, техдокументация, эскизы,
образец и т.д.).
3. Срок выполнения работы. Указывается срок начала и окончания работы.
Допускается изменять сроки выполнения работ, предусмотренные планом или
служебной запиской по согласованию с «Заказчиком» после проработки
технической документации.
4. Источник финансирования. Определяет за счёт каких средств выполняется
работа.
5. Стоимость работ. Рассчитывается и согласовывается в соответствии с
положением о работе полиграфического отдела. При выполнении проектноконструкторских работ может указываться предварительная стоимость работы,
которая должна быть уточнена по фактически выполненной работе (о чём делается
отметка в данном разделе).
6. Дополнительные
требования.
Заполняется
при
наличии
дополнительных требований к качеству изделия, применяемых материалов и т. д.
7. Примечание. Включает дополнительные условия, не оговорённые в
предыдущих пунктах.
14
1.4 Расчет и оформление плановой калькуляции
Целью расчета плановой калькуляции является экономически обоснованное
определение затрат необходимых для выполнения всех предусмотренных
договором (заказом) работ.
Плановая калькуляция является обязательным
приложением ко всем договорам и заказам, выполняемым полиграфическим
отделом.
Стоимость работ по договорам и заказам складывается из затрат, связанных с
использованием в процессе их выполнения сырья, материалов, энергии, трудовых
ресурсов и других затрат.
Устанавливается следующая группировка по статьям калькуляции:
- материалы;
- основная заработная плата;
- дополнительная заработная плата;
- начисления на заработную плату;
- накладные расходы структурного подразделения;
- накладные расходы организации;
- себестоимость.
Оформление калькуляций производится следующим образом:
1.
Статья
«Материалы»
включает
в
себя
стоимость
материалов
использованных на выполнение работ по договору или израсходованных на
производство единицы продукции. Стоимость материалов определяется на основе
норм
расхода
материалов,
рассчитанных
по
технической
документации,
являющейся приложением к договору. Расчет норм расхода материалов заносится в
таблицу на обратной стороне калькуляции или прилагается к ней.
2. Статья «Основная заработная плата» отражает расходы на оплату труда
основного производственного персонала или работников, непосредственно занятых
в выполнении работы по договорам и заказам. Статья включает в себя заработную
плату, соответствующую расчетной норме времени на выполнение работ по
15
договору с учетом тарифов, утвержденных на период оформления договора или
заказа и премии основным производственным рабочим за производственные
результаты. Результаты расчета основной заработной платы заносятся в таблицу на
обратной стороне калькуляции.
3. Статья «Дополнительная заработная плата» учитывает расходы, связанные
с начислением отпускных основным работникам. Отчисления на статью
«Дополнительная заработная плата» устанавливаются в процентном отношении к
размеру расходов по статье «Основная заработная плата». Уровень отчислений (%)
устанавливается распоряжением два раза в год на основе анализа результатов
хозяйственной деятельности за предыдущий период сроком от трех месяцев до
одного года.
4. Статья «Начисления на заработную плату» устанавливается в процентном
отношении к размеру расходов по статье «Основная заработная плата» Уровень
отчислений (%) определяется действующим законодательством.
5. Статья «Накладные расходы структурного подразделения» включает в себя
затраты по обеспечению работоспособности структурного подразделения, которые
не могут непосредственно относиться на выпускаемую продукцию. Размер
отчислений устанавливается в процентном отношении к размеру расходов по статье
«Основная заработная плата» на основе утвержденной в соответствии с настоящим
положением «Сметы накладных расходов структурного подразделения».
6. Статья «Накладные расходы организации» включает в себя расходы
издательства по обеспечению работы структурного подразделения. Размер
отчислений по этой статье устанавливается в процентном отношении к размеру
расходов по статье «Основная заработная плата» на основе утвержденного в
соответствии
с
настоящим
положением
«Расчета
накладных
расходов
организации».
7.
Статья
предыдущими
«Себестоимость»
статьями
равна
калькуляции.
сумме
Она
затрат,
определяет
предусмотренных
расходы
учебно-
производственного и научного подразделения по выполнению работ по договору
или выпуску продукции.
16
Данные для расчета калькуляции (стоимость материалов и основная
заработная плата) рассчитываются начальником структурного подразделения,
инициатором оформления договора (заказа) и представляются в экономический
отдел.
1.5 Организационная структура
Организационная структура полиграфического отдела представлена на
рисунке 1.
Рисунок 1. Организационная структура полиграфического отдела при
печатном издательстве
Оператор резательных машин -
работник, занимающийся размоткой и
нарезкой материалов и предоставляющий их в требуемом формате.
Инженер
компьютерной
графики осуществляет допечатную верстку
полиграфической продукции, а также является оператором печатающих устройств
с компьютерным интерфейсом.
Операторы множительной техники занимаются размножением тиражей.
Работники переплётного отделения осуществляют переплёт и схожие работы.
Печатники выполняют печать тиражей.
Начальник
полиграфического
отдела
—
руководитель
типографии.
Начальник обязан всегда быть в курсе всех технических и организационных
процессов. Состоит в подчинении у директора организации. Также, начальник
является лицом, непосредственно выступающим в роли «Исполнителя», поэтому
17
постоянно имеет дело с документами. Помимо этого, в обязанности начальника
входит составление материальных отчётов и калькуляций.
Предполагается,
что
проектируемая
система
будет
рассчитана
на
непосредственное администрирование начальником полиграфического отдела и
существенно сократит его труд по работе с документооборотом. Тем не менее, для
работы
с
системой
в
штат
может
быть
введён
и
непосредственный
администратор системы [3].
1.6 Описание методик проектирования ИС
Формализованное описание бизнес-процесса в целом, деловых процедур,
входящих в него, правил их выполнения и ролей участников процесса называют
моделью процесса. Построение модели делового процесса производится на этапе
проектирования системы и представляет собой достаточно трудоемкую работу. От
того, насколько удачно будет разработана модель, зависит эффективность
дальнейшего функционирования системы. Поэтому построению модели должно
предшествовать детальное обследование и анализ объекта на предмет оптимизации
его деятельности, необходим:

всесторонний анализ бизнес-процессов, на основе которого производится
разработка проекта реорганизации и обоснование заложенных в нем
решений;

использование
широкой
палитры
современных
методологий
и
инструментальных средств моделирования и проектирования систем;

детальная проработка и согласование с заказчиком всех этапов разработки
проекта, контрольных точек, требуемых ресурсов.
Для этого вполне применимы традиционные методологии системного анализа
и проектирования ИС, такие как SADT, DFD, IDEF.
Моделирование потоков данных (процессов). В основе данной методологии
лежит построение модели, анализируемой ИС – проектируемой или реально
18
существующей. В соответствии с методологией модель системы определяется как
иерархия диаграмм потоков данных, описывающих асинхронный процесс
преобразования информации от ее ввода в систему до выдачи пользователю.
Диаграммы верхних уровней иерархии (контекстные диаграммы) определяют
основные процессы или подсистемы ИС с внешними входами и выходами. Они
детализируются при помощи диаграмм нижнего уровня. Такая декомпозиция
продолжается, создавая многоуровневую иерархию диаграмм, до тех пор, пока не
будет достигнут такой уровень декомпозиции, на котором процесс становятся
элементарными и детализировать их далее невозможно.
Источники информации (внешние сущности) порождают информационные
потоки (потоки данных), переносящие информацию к подсистемам или процессам.
Те в свою очередь преобразуют информацию и порождают новые потоки, которые
переносят информацию к другим процессам или подсистемам, накопителям
данных или внешним сущностям – потребителям информации. Таким образом,
основными компонентами диаграмм потоков данных являются:

внешние сущности;

системы/подсистемы;

процессы;

накопители данных;

потоки данных.
Внешняя сущность представляет собой материальный предмет или
физическое каскадное лицо, представляющее собой источник или приемник
информации, например, заказчики, персонал, поставщики, клиенты, склад.
Определение некоторого объекта или системы в качестве внешней сущности
указывает на то, что она находится за пределами границ анализируемой ИС. В
процессе анализа некоторые внешние сущности могут быть перенесены внутрь
диаграммы анализируемой ИС, если это необходимо, или, наоборот, часть
процессов ИС может быть вынесена за пределы диаграммы и представлена как
внешняя сущность. Внешняя сущность обозначается квадратом, расположенным
19
как бы "над" диаграммой и бросающим на нее тень, для выделения среди прочих
обозначений (рисунок 2).
Рисунок 2. Обозначение внешней сущности.
При построении модели сложной ИС она может быть представлена в самом
общем виде на контекстной диаграмме в виде одной системы как единого целого,
либо может быть декомпозирована на ряд подсистем. Подсистема или система на
контекстной диаграмме изображается следующим образом (рисунок 3):
Рисунок 3. Изображение подсистемы на контекстной диаграмме
Номер подсистемы служит для ее идентификации. В поле имени вводится
наименование
подсистемы
в
виде
предложения
с
подлежащим
и
соответствующими определениями и дополнениями.
Процесс представляет собой преобразование входных потоков данных в
выходные в соответствии с определенным алгоритмом (рисунок 4). Физически
процесс может быть реализован различными способами: это может быть
подразделение организации (отдел), выполняющее обработку входных документов
и выпуск отчетов, программа, аппаратно-реализованное логическое устройство и
т.д.
20
Рисунок 4. Процесс.
Номер процесса служит для его идентификации. В поле имени вводится
наименование процесса в виде предложения с активным недвусмысленным
глаголом в неопределенной форме (вычислить, рассчитать, проверить, определить,
создать, получить), за которым следуют существительные в винительном падеже,
например:

"Ввести сведения о клиентах";

"Выдать информацию о текущих расходах";

"Проверить кредитоспособность клиента".
Использование таких глаголов, как "обработать", "модернизировать" или
"отредактировать" означает, как правило, недостаточно глубокое понимание
данного процесса и требует дальнейшего анализа.
Информация в поле физической реализации показывает, какое подразделение
организации, программа или аппаратное устройство выполняет данный процесс.
Накопитель данных представляет собой абстрактное устройство для
хранения информации, которую можно в любой момент поместить в накопитель и
через некоторое время извлечь, причем способы помещения и извлечения могут
быть
любыми.
Накопитель
буквой "D" и произвольным числом (рисунок 5).
Рисунок 5. Накопитель данных.
данных
идентифицируется
21
Имя накопителя выбирается из соображения наибольшей информативности
для проектировщика. Накопитель данных в общем случае является прообразом
будущей базы данных и описание хранящихся в нем данных должно быть увязано
с информационной моделью.
Поток данных определяет информацию, передаваемую через некоторое
соединение от источника к приемнику. Реальный поток данных может быть
информацией,
пересылаемыми
передаваемой
по
почте
по
кабелю
письмами,
между
двумя
компакт-дисками
устройствами,
или
дискетами,
переносимыми с одного компьютера на другой и т.д.
Поток данных на диаграмме изображается линией, оканчивающейся
стрелкой, которая показывает направление потока (рисунок 6).
Рисунок 6. Поток данных.
Первым шагом при построении иерархии диаграмм потоков данных является
построение контекстных диаграмм. Обычно при проектировании относительно
простых ИС строится единственная контекстная диаграмма со звездообразной
топологией, в центре которой находится так называемый главный процесс,
соединенный с приемниками и источниками информации, посредством которых с
системой взаимодействуют пользователи и другие внешние системы.
Для сложной системы не стоит ограничиться единственной контекстной
диаграммой, так как она будет содержать слишком большое количество
источников и приемников информации. Признаками сложности могут быть:

наличие большого количества внешних сущностей (десять и более);

распределенная природа системы;
22

многофункциональность системы с уже сложившейся или выявленной
группировкой функций в отдельные подсистемы.
Для сложных ИС строится иерархия контекстных диаграмм. При этом
контекстная диаграмма верхнего уровня содержит не единственный главный
процесс, а набор подсистем, соединенных потоками данных. Контекстные
диаграммы следующего уровня детализируют контекст и структуру подсистем.
Данный метод чаще всего применяется при информационном моделировании
– для описания информационной среды и идентификации отношений между
объектами.
Поддерживается такими CASE-средствами как Vantage Team Builder
(Westmount I-CASE) + Uniface, Silverrun, ERwin, BPwin, S-Designor.
Методология IDEF. Разработанные для проектирования ИС, средства DFD
ориентированы на системных аналитиков и разработчиков и не учитывают
особенностей восприятия менеджерами своей предметной области. Для описания
бизнес-процессов менеджерам требуются более мощные выразительные средства,
чем описание входов и выходов на диаграммах потоков данных.
Наиболее подходящим методом моделирования бизнес-процессов на стадии
создания моделей предметной области является IDEF:

IDEF0 – язык моделирования процессов;

IDEF1 – язык моделирования данных;
позже расширен до поддержки реляционных моделей:

IDEF1X и IDEF2 – для описания динамических систем.
Это язык моделирования появился в результате видоизменения SADT, к
настоящему времени IDEF0, как язык описания бизнес-процессов, стал
федеральным стандартом в США и быстро распространяется в Европе.
Отличительной особенностью языка IDEF0 является использование в
качестве основы естественного языка экспертов, который структурируется с
23
помощью графических средств. Это дает возможность эксперту или менеджеру
свободно описывать функционирование системы, пользуясь знакомой и удобной
терминологией, а, например, системному аналитику (как автору модели) легко и
просто перенести описание на естественном языке в графическое представление
языка IDEF0. Еще одним замечательным свойством IDEF0-моделей является
возможность их использования для функционально-стоимостного анализа бизнеспроцессов.
В стандарте IDEF0 описание системы организовано в виде иерархически
упорядоченных и взаимосвязанных диаграмм. Вершина этой древовидной
структуры представляет собой самое общее описание системы и ее взаимодействия
с внешней средой (аналог контекстной диаграммы SADT), а в ее основании
находятся наиболее детализированные описания выполняемых системой функций.
Диаграммы содержат функциональные блоки, соединенные дугами. Дуги
отображают взаимодействия и взаимосвязи между блоками. Функциональный блок
на диаграммах изображается прямоугольником и представляет собой функцию или
активную часть системы (рисунок 7).
стандарты и правила
Данные
пользователей
Виды данных
Отчеты
Проектирование
баз
данных
Разработка
согласование
с заказчиком
Рисунок 7. Функциональный блок и интерфейсные дуги в IDEF0.
Поэтому, названиями блоков служат глаголы или глагольные обороты.
Каждая сторона блока имеет особое, вполне определенное назначение. К левой
24
стороне блока подходят дуги входов, к верхней – дуги управления, к нижней –
механизмов реализации выполняемой функции, а из правой – выходят дуги
выходов.
Такое соглашение предполагает, что, используя управляющую информацию
об условиях и ограничениях и реализующий ее механизм, функция блока
преобразует свои входы в соответствующие выходы. На диаграмме блоки
упорядочены по степени важности, начиная с левого верхнего угла диаграммы и
кончая нижним правым углом.
Для обеспечения наглядности и лучшего понимания моделируемых
процессов рекомендуется использовать от 3-х до 6-ти блоков на одной диаграмме.
Такое
представление
модели
устраняется
неоднозначность,
присущую
естественному языку, и, благодаря этому, достигается необходимая для понимания
и анализа лаконичность и точность описания, без потери деталей и качества.
Метод IDEF1 позволяет построить модель данных, эквивалентную
реляционной модели в третьей нормальной форме. В настоящее время на основе
совершенствования методологии IDEF1 создана ее новая версия – методология
IDEF1X. IDEF1X разработана с учетом таких требований, как простота изучения и
возможность
автоматизации.
IDEF1X-диаграммы
используются
рядом
распространенных CASE-средств – ERwin, Design/IDEF.
1.7 Описание бизнес-процессов предприятия в нотации IDEF0
Описание системы с помощью IDEF0 называется функциональной моделью.
Функциональная модель предназначена для описания существующих бизнеспроцессов, в котором используются как естественный, так и графический языки.
Методология IDEF0 предписывает построение иерархической системы
диаграмм - единичных описаний фрагментов системы. Сначала проводится
описание системы в целом и ее взаимодействия с окружающим миром (контекстная
25
диаграмма), после чего проводится функциональная декомпозиция - система
разбивается на подсистемы, и каждая подсистема описывается отдельно
(диаграммы декомпозиции). Затем каждая подсистема разбивается на более мелкие
и так далее до достижения нужной степени подробности.
На верхнем уровне приводится описание системы в целом и её
взаимодействие
с
миром.
Контекстная
диаграмма
деятельности
полиграфического отдела представлена на рисунке 8.
Рисунок 8. Контекстная диаграмма
После построения контекстной диаграммы требуется изобразить описание
процессов предметной области более детально. Для этого была построена
декомпозиционная диаграмма (рисунок 9).
26
Возможности
типографии
Устав
организации
Отказ по причине невозможности выполнения
Основания для
заключения договора
Сопровождающая документация
План-график
Оформить заказ
Требования
Законодательство РФ
Договор
Предварительная стоимость
Уточненные требования
Техническая
документация
Оригинал-макет
Выполнить работы
Отчет о расходах
материалов
Накладные
Материалы
Продукция
Выдать заказ
Начальник
Продукция
Персонал
Оборудование
Заказчик
Рисунок 9. Декомпозиционная диаграмма
Полный процесс работы полиграфического отдела складывается из
последовательного выполнения следующих основных функций:
– оформить заказ;
– выполнить работы (по заказу);
– выдать заказ.
Рассмотрим подробно каждый из приведённых бизнес-процессов.
Выполнение любой работы по выпуску печатной продукции начинается с
заключения договора на оказание соответствующих услуг между Заказчиком и
Исполнителем.
Перед
заключением
договора
анализируются
требования,
которые предъявляет Заказчик. В процессе анализа требований выясняется,
способна ли типография выполнить требуемые работы, а также производится
предварительное согласование стоимости работ. В результате первоначальные
требования уточняются и служат основанием для выполнения последующих
работ по заказу. В случае большого объема запланированных работ составляется
27
план-график, который регламентирует порядок и сроки выполнения отдельных
работ. Для непосредственного выполнения работ (процесс «Выполнить работы»)
Заказчик предоставляет оригинал-макет. Изготовление печатных изделий требует
наличия соответствующих расходных материалов, расход которых регистрируется
и включается в отчетность по заказу. Изготовленная продукция выдается
Заказчику,
при
этом
факт
выдачи каждого изготовленного
экземпляра
фиксируется в накладной.
При осуществлении всех видов деятельности полиграфический отдел
руководствуется
Уставом
организации,
текущим
Положением,
а
также
Законодательством Российской Федерации.
Для углубления в предметную область осуществим декомпозицию процесса
«Оформить заказа» (рисунок 10).
На рисунке 10 представлена декомпозиционая диаграмма процесса
«Оформить заказ». В пояснение к данной диаграмме следует отметить, что при
заключении договора и оформлении задания на выполнение работ по заказу
производится предварительный расчет стоимости заказа. Фактическая стоимость
выполнения заказа может отличаться от сделанной по предварительному расчету.
28
Возможности типографии
Законодательство РФ
Устав
организации
Отказ по причине
невозможности выполнения
Основания
для заключения
договора
Проанализировать
состав заказа
Согласованный состав
Несогласуемость требований
План-график
Согласовать
требования
Требования
Уточненные требования
Заключить договор
Договор
Предварительная
Оформить
стоимость
сопроводительную
документацию
Начальник
Заказчик
Рисунок 10. Декомпозиция процесса «Оформить заказ»
Согласование
требований
с
Заказчиком
осуществляется
по
плану,
показанному на рисунке 11. Процесс «Согласование требований» осуществляется
путём принятия решений между Заказчиком и Исполнителем по четырём
основным критериям: выбору типа носителя (газетная бумага, 80-мм бумага,
ватман и т.п.), выбору типа переплёта (мягкий переплёт, жёсткий переплёт,
ламинирование и др.), выбор обложки (определение дизайна), согласование сроков.
В процессе согласования требований может возникнуть ситуация, в которой
Заказчика не устроят предлагаемые варианты. Это приводит к отказу от
заключения договора на выполнение заказа.
В рамках поставленной задачи процессы, возникающие при выполнении
типографских работ, не представляют интереса, считается важным лишь расход
материалов при их выполнении, выраженный в отчетах по расходам материалов,
и сопровождающая техническая документация (а также, очевидно, сама
29
произведенная продукция). По этой причине процесс «Выполнить работы» не
декомпозируется.
Рисунок 11. Декомпозиция процесса «Согласовать требования»
Анализируя полученную функциональную модель предметной области,
можно сказать, что на каждом этапе выполнения основной деятельности
производится большое количество разнообразной документации, которая должна
быть согласованной и полной. Ввиду столь большого объема производимой
информации имеет смысл подробно рассмотреть предметную область с точки
зрения существующих в ней информационных потоков [4][5].
1.8 Построение диаграммы потоков данных
Диаграммы потоков данных (Data Flow Diagramm) используются для
документирования механизмов передачи и обработки информации в моделируемой
системе. Диаграммы DFD обычно строятся для наглядного отображения текущей
работы системы документооборота организации.
30
В диаграммах потоков данных все используемые символы складываются в
общую картину, дающую четкое представление о том, какие данные используются и
какие функции выполняются системой документооборота. Следует также отметить,
что нотацию DFD можно эффективно применять для описания как потоков
документов, так и потоков материальных ресурсов (в том числе на одной и той же
диаграмме)[6].
Также, как и в предыдущем разделе, описание системы начнём с нулевого
уровня декомпозиции (рисунок 12).
Рисунок 12. Нулевой уровень декомпозиции диаграммы потоков данных
На данном уровне декомпозиции было принято решение выделить следующие
внешние сущности:
1.
«Заказчик» — лицо (физическое или юридическое), заинтересованное в
выполнении полиграфическим отделом работ и оказании им различного рода услуг.
Предоставляет полиграфическому отделу служебную записку, письмо, приказ,
протокол совещаний (являются взаимоисключающими), а также оплачивает заказ и
31
предоставляет свои требования. В свою очередь получает готовый заказ и
предъявляемый счёт.
«Руководство» и «Рынок материалов» - условно-названные внешние
2.
сущности, введённые для того, чтобы обосновать количественное значение норм
заработной платы на данный момент, а также цены на материалы и оборудование на
рынке.
«Склад материалов» - источник материалов для полиграфического отдела.
3.
Получает запрос, либо заказ на необходимые материалы, в зависимости от их
наличия.
«Бухгалтерия». Основной функцией бухгалтерии применительно к
4.
конкретной предметной области является соблюдение установленных правил
приемки и отпуска товарно-материальных ценностей. Является местом приёма
накладных.
5.
«Управление экономики». Структурное подразделение издательства.
Непосредственно взаимодействует с начальником типографии, принимая от него все
необходимые данные для расчёта калькуляции. Будучи составленной, она передаётся
к проректору по направлению.
6.
«Директор» - Глава организации. Получает и утверждает калькуляции с
последующим возвращением их в полиграфический отдел.
Процесс «Анализ заказа» (рисунок 13). Входным информационным
потоком является вся предоставляемая Заказчиком информация (служебная записка,
приказ, протокол совещаний, требования). Заказ оформляется и на выходе получаем
два потока данных: данные заказа и требования к материалам. В свою очередь данные
заказа вносятся в базу данных «Журнал заказов». В журнале отмечается уникальный
номер заказа, название тиражируемого (или размножаемого) экземпляра и прочая
дополнительная информация. Требования к материалам необходимы для выполнения
следующего процесса — получения материалов.
32
Рисунок 13. Декомпозиция процесса «Осуществлять деятельность полиграфическог
о отдела»
«Получение
материалов».
Для
выполнения
работ
начальник
полиграфического отдела должен заказать требуемые материалы, либо убедиться, что
материалы есть в наличии. Для осуществления первого случая требуются денежные
средства, предоставляемые Заказчиком.
«Выполнение работ» - исполнение прямых обязанностей типографии. После
выполнения — заказ готовый к отгрузке и информация о работах. Описание данного
процесса выходит за границы предметной области.
«Расчёт стоимости заказа» выполняется на основе предоставленных данных
после завершения работ. В стоимость заказа входят: стоимость используемых
материалов, основная зарплата сотрудников, дополнительная заработная плата,
начисления на заработную плату, накладные расходы полиграфического отдела.
Стоимость используемых материалов — сумма по всем составляющим (бумага,
клей, тонер, переплётная проволока и т. д.).
Основная заработная плата сотрудников складывается из выполненного объёма
работ (например, печать + переплёт + шелкография и т. д.).
33
Дополнительная заработная плата является отчислением на отпуск. Составляет
10 процентов от основной заработной платы.
Начисления на заработную плату — социальный налог. Составляет 26,2
процента.
Накладные расходы полиграфического отдела. Составляет 130 процентов от
полученной заработной платы. Включает в себя: заработную плату неосновных
сотрудников (например, наладчиков), канцелярские товары, проездные билеты для
сотрудников и т. п.
Процесс «Составление отчёта». Самый ответственный процесс работы
начальника типографии. На основе информации о работах, информации о расходе
материалов, норм заработной платы и цен на материалы он должен составить
материальный отчёт для предоставления его в экономический отдел для проверки.
Все копии материальных отчётов по каждому месяцу обязаны храниться в
полиграфическом
отделе,
поэтому
для
них
предусмотрена
база
данных
«Материальный отчёт».
После проверки материального отчёта экономическим отделом и составления
на его основе калькуляций, данные отправляются к проректору для утверждения.
После
проверки
утверждённая
калькуляция
и
технические
документации
возвращаются в полиграфический отдел для оформления накладной. Оформленные
накладные отправляются в бухгалтерию для проверки. Для лучшего понимания
процесса декомпозируем сущность «Составление отчёта» (рисунок 14).
34
Рисунок 14. Декомпозиция процесса «Составление отчёта»
«Оформление заказа». После выполнения работ по заказу и получив всю
информацию, начальник может приступить к оформлению заказа. Содержимое заказа
перечислялось в пункте 3 раздела 1. В это же время, начальник (если это необходимо)
составляет план-график работ. Это может быть необходимо, если на выполнение
заказа затрачивается больше месяца.
«Расчёт расхода материалов». По завершении работ сотрудники сообщают
начальнику о количестве затраченных материалов. Для каждого заказа расход
материалов равен сумме всех материалов, затраченных на его выполнение.
«Расчёт заработной платы». Процесс расчёта заработной платы аналогичен
расчёту материалов. Каждый вид работы имеет свою фиксированную стоимость. Эта
стоимость умножается на объём выполняемой работы.
«Расчёт фактических затрат». В отличие от плановой калькуляции отражает
реальную стоимость работ, так как зачастую получается, что конечная стоимость
заказа превышает стоимость, указанную в предварительном расчёте.
35
ГЛАВА 2 ПРОЕКТИРОВАНИЕ И РЕАЛИЗАЦИЯ ИНФОРМАЦИОННОЙ
СИСТЕМЫ МОНИТОРИНГА ДЕЯТЕЛЬНОСТИ ПОЛИГРАФИЧЕСКОГО
ОТДЕЛА
2.1 Общие требования к структуре информационной системы
Проанализировав функциональную модель и модель информационных
потоков
предметной
функциональным
области,
возможностям
можно
и
сформулировать
общие
структурные
требования
к
особенности
разрабатываемой информационной системы.
При проектировании ИС (информационной системы) важно учитывать, в каких
условиях, организационных и технических, предполагается ее использовать. При
этом желательно учесть возможность изменения работы организации.
На момент написания данной работы типография, в которую планируется
внедрять разрабатываемую ИС, является структурным подразделением печатного
издательства, насчитывает около десяти сотрудников и располагается в одном
здании. Ввиду этого имеет смысл рассматривать разрабатываемую ИС как
централизованную, с одним активным пользователем, и не требующую сетевого
взаимодействия между различными компонентами. Это приводит к тому, что
дополнительные расходы на выделение серверов (баз данных, веб-серверов и т.п.)
становится
экономически
нецелесообразным.
Таким
образом,
наиболее
рациональным решением является реализация ИС в виде устанавливаемого на
компьютер пользователя оконного приложения, взаимодействующего с локальной
«неуправляемой» (не нуждающейся в СУБД (системе управления базой данных)
базой данных. С другой стороны, следует учитывать возможность последующего
расширения данного структурного подразделения до размеров, при которых
организация сетевого взаимодействия в рамках модели «клиент-сервер» станет
оправданным. Это приводит к формулированию следующих требований к структуре
ИС:
36
–
наличие
уровня-прослойки
между
базой
данных
и
клиентским
приложением, от которого не зависит не структура БД (базы данных), ни структура
клиентского приложения;
– использование модели данных, которую возможно масштабировать для
использования в рамках клиент-серверной архитектуры ИС.
Для выполнения второго требования можно взять в качестве основной
модели данных реляционную модель. Использование так называемой «СУБД
уровня API», например, SQLite для локальной работы позволит в случае перехода
к клиент-серверной архитектуре практически не вносить изменения в логическую
структуру базы данных.
Указанное
требование
к
функциональности,
заключающееся
в
настраиваемости формата генерируемых отчетов, приводит к следующему
требованию к структуре ИС - наличию подсистемы шаблонной генерации
документации.
Данная подсистема должна реализовывать унифицированный алгоритм
составления отчетов и другого типа документации в соответствии с заданным
шаблоном. Это позволит, не внося изменений в структуру ИС путем
редактирования только шаблона получить документацию в требуемом формате.
2.2 Описание используемых при разработке технологий и моделей
Для выполнения всех предъявляемых к разрабатываемой системе требований
необходимо тщательно выбрать технологические решения и инструментарий
разработки. От адекватности данного выбора во многом зависят затраты на
реализацию и успешность проекта в целом.
На данный момент существует ряд доказавших свою эффективность
подходов к разработке программного обеспечения, как в области проектирования
программных систем, так и в области организации процесса разработки. В области
37
проектирования и разработки программных систем общепризнанными являются
следующие подходы:
1. Структурное программирование. В основе данного подхода лежит теорема
Ч.Хоара о том, что любой алгоритм может быть представлен с использованием трех
основных управляющих конструкций: передача управления, ветвление и цикл.
Использование структурного подхода к организации программ позволяет добиться
высокой производительности и надежности, однако, предполагает достаточно
низкий уровень абстракции, что делает его использование затруднительным для
создания крупных расширяемых систем в предметных областях с большим
количеством сущностей и сложной системой взаимодействий. Фактически, на
данный момент структурное программирование применяется при разработке
небольших подсистем, предоставляющих небольшие интерфейсы, но имеющие
сложную модель поведения;
2. Объектно-ориентированное программирование. Данный подход к
организации программной системы основан на представлении последней как
совокупности взаимодействующих по определенным правилам объектов, каждый
из которых имеет обособленную структуру и предоставляет некоторую
функциональность. Объектно-ориентированное программирование на данный
момент является де-факто стандартом организации сложных программных систем,
в том числе и программного обеспечения информационных систем, поскольку
важными его характерными особенностями являются легкость разделения работы
по реализации отдельных частей системы между большим количеством
исполнителей, а также возможность повторного использования кода. Следует
отметить, что объектно-ориентированный подход к разработке ПО упрощает
последующую его модернизацию, рефакторинг и реинжиниринг (при условии
адекватного проекта программной системы). К недостаткам данного подхода
можно отнести более низкое быстродействие получаемых программ, а также
сильную зависимость успешности реализации от качества проекта программной
38
системы (устранение проектных ошибок «налету» в процессе разработки
затруднительно и приводит к значительным временным и материальным затратам);
3.
Функциональное
программирование.
Функциональный
подход
к
разработке в данный момент набирает популярность ввиду большого количества
предоставляемых в рамках данного подхода возможностей, которые при решении
задач
определенного
типа
позволяют
добиться
значительно
большей
производительности (в плане разработки), чем это позволяет объектноориентированный подход. Существуют попытки интеграции функционального
подхода с объектно-ориентированным;
4. Компонентное программирование. Представляет собой развитие объектноориентированного программирования и предполагает построение программ из
блоков — компонентов, которые являются независимыми блоками кода (как
правило, скомпилированного), предоставляющими заданную функциональность,
при этом внутренняя структура и принципы работы отдельных компонентов не
важны для организации системы в целом. Компонентный подход позволяет
добиться очень высокой степени универсальности повторно используемого кода,
достаточно высокой надежности. Но в рамках данного подхода существует
большое количество ограничений, накладываемых на разработчика, что часто
является препятствием для использования.
Приведенный перечень не является полным и охватывает только основные из
используемых подходов к разработке программных систем.
Важным проектным решением, влияющим на успешность выполнения
поставленных задач, является выбор методологии разработки программного
обеспечения, т.е. способа организации процесса разработки. Из множества
существующих моделей процесса разработки ПО можно выделить следующие:
1. Модель водопада (каскадная модель). Представляет собой способ
организации рабочего процесса таким образом, что следующий этап разработки
начинается только после полного завершения предыдущего (рисунок 15).
39
Обследование
ТЗ
Опытный
вариант
Технический
проект
Разработка
Внедрение
Рисунок 15. Каскадная схема
Опасность использования данной модели заключается в том, что возможно
бесконечное (или неоправданно длительное) проведение работ на одном из этапов
разработки с целью, например, получения «идеального проекта». Однако, данная
модель
часто
является
наилучшим решением
для
разработки
сложных
систем, основное требование к которым - надежность.
Выделяют следующие проектные стадии:
 "запуск" – организация основания для деятельности и запуск работ: приказ
и/или договор о разработке автоматизированной системы, задание на
выполнение работ;
 "обследование" – предпроектное обследование, общий анализ ситуации на
предприятии, разработка общего обоснования целесообразности создания ИС;
 "концепция, техническое задание (ТЗ)" – исследования требований предприятия
и пользователей, выработка рекомендаций по разработке ИС, разработка ТЗ на
проектирование ИС в целом и по подсистемам;
 "эскизный проект" – разработка архитектуры будущей ИС в рамках эскизного
проекта;
 опытный вариант ИС – разработка упрощенного варианта, пилотного проекта
будущей ИС;
40
 опытное использование пилот-проекта ИС, разработка исправлений и
дополнений к ТЗ;
 разработка технического проекта ИС
 разработка рабочей документации проекта),
 "ввод в действие" – по-другому, "внедрение" ИС.
2. Модель водопада с обратной связью (рисунок 16). Является модификацией
каскадной модели так, что на каждом этапе разработки возможен возврат на (в
общем случае) любой предыдущий этап. Это позволяет устранить выявленные
ошибки по мере их обнаружения (например, проектные ошибки на этапе
реализации). Однако, такой подход может привести к увеличению общей
длительности и, соответственно, стоимости проекта.
Обследование
ТЗ
Опытный
вариант
Технический
проект
Разработка
Внедрение
Рисунок 16. Каскадная схема с обратной связью.
По результатам проведенного анализа предметной области было принято
решение использовать при разработке информационной системы объектноориентированный подход и каскадную модель процесса разработки. Данный выбор
продиктован достаточно высокой статичностью основных процессов предметной
области и «прозрачностью» представления основных структурных компонентов
предметной области в терминах объектов. Тем не менее, предметную область
41
нельзя считать совершенно статичной, протекание бизнес-процессов может
подвергаться изменениям вследствие изменений используемых технологий,
законодательства, политики организаций и прочих факторов. Ввиду этого, проект
информационной системы должен учитывать возможность, не требующую
значительных затрат времени и средств. Должна быть обеспечена близкая к
линейной зависимость затрат, требуемых на модификацию ИС от размера
вносимых изменений [7].
2.3 Варианты использования информационной системы
Основной деятельностью организации, требующей автоматизации путем
внедрения информационных технологий, является формирование связанной с
выполнением заказа сопровождающей документации. К этой документации
относятся наименование и присвоенный заказу номер, список израсходованных
материалов, включая их стоимость на момент выполнения заказа, сроки приема и
сдачи заказа, объем выполненных работ и т.п. Вся эта информация необходима для
формирования общих отчетов по работе подразделения за интересующий период.
Без использования информационных технологий, вручную, ведение отчетности
занимает значительное время, что негативно сказывается на эффективности работы
подразделения. Разрабатываемая информационная система призвана решить
данную проблему.
Основные функциональные возможности, которые должна реализовывать
ИС, представлены в виде диаграммы прецедентов UML на рисунке 17.
Из диаграммы можно видеть, что система рассчитана на работу с двумя
типами пользователей: Начальником и Работником. Начальник является
руководителем структурного предприятия, в его обязанности входит принятие
управленческих решений относительно выполняемых заказов. В его задачи также
входит обеспечение актуальности информации о расценках на расходные
материалы и нормах заработной платы на выполняемые работы. Только Начальник
42
вправе вносить изменения в состав заказа, вносить в смету заказа материалы и
изменять статус заказа.
Рисунок 17. Диаграмма вариантов использования информационной системы
Под статусом заказа понимается его текущее состояние, которое в базовом
варианте может принимать следующие значения: «обрабатывается», «выполнен» и
«аннулирован». Наличие последнего статуса (и соответствующего прецедента на
диаграмме вариантов использования) определяет то, что в системе хранится
информация обо всех поступивших на обработку заказах, вне зависимости от того,
был ли он фактически выполнен или нет.
43
Роль
«Работник»
представляет
собой
сотрудника
типографии,
не
наделенного полномочиями принимать управленческие решения. Работник может
просматривать заказы, находящиеся в обработке и при необходимости
регистрировать новый заказ. На этом его возможности заканчиваются.
Ключевой функцией ИС является формирование отчетности за указанный
период. Начальник должен иметь возможность указывать, какая информация
входит в отчет, а также форму предоставления отчета. Учитывая возможность
изменения нормативных актов, в соответствии с которыми должна формироваться
отчетность, формат отчета должен быть настраиваемым и его изменение не должно
требовать внесения изменений в структуру информационной системы[8].
2.4 Архитектура информационной системы
В функции разрабатываемой информационной системы входят:
- учет сведений о заказах, включая как выполненные заказы, так и заказы,
находящиеся в обработке;
- учет расходных материалов, включая их количество и текущую стоимость;
- учет расходов материалов на выполнение заказа;
- отслеживание текущего состояния заказа;
- автоматический расчет стоимости заказа;
- автоматический расчет заработной платы сотрудникам по объему
выполненных работ;
- автоматическая генерация отчетности.
Анализируя
перечисленные
требования
к
функциональности,
разрабатываемой ИС, можно выделить три основные задачи ИС:
- управление данными организации;
44
- расчет требуемых показателей на основании актуальных данных о
состоянии организации;
- генерация документов.
Кроме
того,
к
вышеперечисленным
задачам
следует
отнести
дополнительную, не выводимую из перечня требуемых функций - это обеспечение
безопасности и разделения прав доступа в соответствии со служебным положением
пользователя.
Обеспечение эффективного управления данными организации можно
назвать основной задачей с точки зрения архитектуры системы, поскольку только
при качественном её выполнении, возможно выполнение всех остальных функций.
В общепринятой терминологии подсистему, выполняющую функцию управления
данными, можно назвать «ядром» разрабатываемой информационной системы. Все
остальные подсистемы обращаются к функциям «ядра» для выполнения своих
задач. «Ядро», в свою очередь, является полностью автономным и не зависит от
других подсистем.
В задачу расчета требуемых показателей входят такие задачи, как расчет
стоимости заказа, расчет заработной платы и т.п. Важным моментом является то,
что схемы расчета не могут считаться статичными, они зависят от внешних
факторов и могут меняться со временем. Также для обеспечения работы
организации может требоваться расчет других показателей. Ввиду этого все
операции по расчету показателей следует выделить в отдельную подсистему.
Автоматическая генерация отчетности, в сущности, представляет собой
основную цель разработки данной ИС. Генератор отчетов можно рассматривать
как самостоятельный компонент, структура и функциональные свойства которого
не зависят от логики предметной области и определяются только заданным
форматом требуемых отчетов. Для выполнения своих функций генератор отчетов
обращается к другим компонентам системы с запросом требуемых данных (или,
45
точнее,
необходимые
данные
передаются
генератору
отчетов
при
его
инициализации другими подсистемами).
Подсистема обеспечения безопасности, условно говоря, отслеживает
действия,
проводимые
пользователем
в
системе,
проверяет
полномочия
пользователя на совершение этих действий и, в случае недостаточности
полномочий, прерывает их выполнение.
Общая структура информационной системы представлена на рисунке 18.
Рисунок 18. Диаграмма компонентов информационной системы
46
На данной диаграмме выделен дополнительный компонент: «Подсистема
манипулирования данными». В задачи данного компонента входит обеспечение
унифицированного обращения к базе данных через ее логическое представление.
Использование подобного подхода позволяет обеспечить дополнительную
гибкость и устойчивость системы к необходимости изменений, делая подсистему
управления данными независимой от особенностей, фактически используемой для
хранения данных базы данных.
Преимущество использования промежуточного звена между подсистемой
управления данными и базой данных можно проиллюстрировать на следующем
примере. В базовой версии информационной системы предполагается её
последовательное использование ограниченным числом сотрудников. Для этого
достаточно,
чтобы
информационная
система
представляла
собой
однопользовательский программный продукт, расположенный на персональном
компьютере конечного пользователя. Для хранения данных в данном случае
наиболее целесообразным представляется использование специализированных
файлов, либо СУБД уровня API.
Однако, подобные технологии обладают существенными ограничениями по
функциональности. При дальнейшем развитии может потребоваться увеличение
функциональности требований к БД, например, использование триггеров и
хранимых процедур, сетевое взаимодействие и т.п., что повлечет за собой
необходимость изменения технологии хранения данных. При непосредственном
взаимодействии подсистемы управления данными с базой данных, потребуется
вносить в первую очередь изменения вплоть до переписывания запросов, что
повлечет за собой дополнительные затраты на модификацию. Использование
промежуточного звена позволит устранить эту необходимость. В частности,
необходимость использования триггеров при использовании СУБД уровня API
можно решить через использование механизма виртуальных триггеров на уровне
подсистемы манипулирования данными. В случае необходимости замены СУБД,
возможно просто заменить текущую подсистему манипулирования данными на
47
предназначенную для работы с новой СУБД. Таким образом, необходимость
изменения «Ядра» системы будет исключена.
48
2.5 Разработка основных функциональных компонентов
Подсистема управления данными. Подсистема управления данными должна
предоставлять другим подсистемам удобный доступ к хранимым данным и способ
внесения новых данных. Применительно к конкретной задаче, подсистема
управления данными представляет собой объектную модель предметной области.
Данная модель представлена на диаграмме классов на рисунке 19.
Рисунок 19. Диаграмма классов подсистемы управления данными
Подсистема управления данными обеспечивает допустимые операции над
данными ИС через изменение значений свойств соответствующих объектов.
Помимо представленной иерархии классов, подсистема предоставляет функции
выбора всего множества объектов заданного класса, существующих в системе.
Например, функция выбора всех заказов возвращает хэш-таблицу объектов класса
49
«Заказ», ключом данной таблицы является номер заказа, что позволяет обеспечить
эффективный поиск нужного заказа.
Каждый класс на приведенной диаграмме является классом-фабрикой,
содержащим метод, который позволяет получить объект заданного класса с
указанным
идентификатором.
Использование
стандартного
механизма
конструктора объекта в таком случае, приводит к созданию нового объекта,
сведения о котором будут добавлены в базу данных[9].
При построении объектов подсистема управления данными обращается через
систему манипулирования данными к базе данных посредством SQL-запросов. В
данной работе при реализации подсистемы управления данными использовались
запросы, соответствующие стандарту SQL92, поскольку на данный момент именно
этот стандарт языка запросов поддерживается большинством современных
РСУБД. Следует отметить, что сложная логика управления данными и обеспечения
логической целостности, реализуется не подсистемой управления данных, а
подсистемой манипулирования данными и средствами используемой СУБД.
Генератор отчетов.
Проектируемая
информационная
система
должна
обеспечивать
автоматическую генерацию следующих типов отчетности:
- накладная на внутреннее перемещение;
- задание на выполнение заказа;
- калькуляция к заказу;
- материальный отчёт;
- ведомость фактических затрат отдела.
Приведенные отчеты имеют разное представление, разные электронные
форматы. Кроме того, все вышеперечисленные отчеты должны быть представлены
как в печатной форме, так и в форме электронного документа, допускающего
50
редактирование. Следует также учесть, что требуемая форма документа может
изменяться и система должна обладать гибкостью относительно подобных
изменений.
Вследствие анализа текущих форм отчетности, был сделан вывод, что
наилучшим решением является генерация документов по двухступенчатой схеме:
- генерация по заданному шаблону промежуточного результата в
унифицированном формате, содержащем все данные окончательного варианта
документа;
- трансляция промежуточного представления окончательного варианта
документа в выбранный электронный формат.
Шаблон представляет собой описания формата документа на языке
промежуточного
представления,
расширенном
метаконструкциями,
описывающими данные, которые должны быть включены в нужное место
документа. В совокупности эти метаконструкции определяют алгоритм генерации
промежуточного представления документа.
В соответствии с теоремой структурного программирования, любой
алгоритм может быть описан с помощью трех основных конструкций:
- последовательность;
- ветвление по условию;
- цикл по условию.
Поскольку метаконструкции в шаблоне определяют алгоритм генерации
документа,
сами
конструкции
удобно
ассоциировать
с
основными
алгоритмическими конструкциями. При этом цикл в рамках шаблона представляет
собой повторение некоторой процедуры обработки, последовательно над
некоторым множеством элементов. По этой причине, вместо цикла по условию,
удобнее использовать цикл по коллекции (т. н. цикл for each).
51
Некоторые данные в документе не являются передаваемыми из вне при
вызове генератора отчетов, а являются вычисляемыми. К таким данным относятся
суммы граф «итого», зарплаты с учетом налоговых сборов и т.п. Ввиду этого
шаблонная система должна содержать некий механизм вычисления требуемых
величин в процессе генерации (аналогично механизму формул в электронных
таблицах).
Приведенные отчеты можно разделить на документы двух типов:
- форматированный текст;
- электронная таблица.
Промежуточное представление, таким образом, должно позволять получать
документы обоих типов. В рамках данной информационной системы в качестве
промежуточного представления был выбран язык HTML. Данный язык достаточно
гибок,
чтобы
описать
как
текст,
содержащий
требуемые
элементы
форматирования, так и электронные таблицы. Метаконструкциями в таком случае
будут вставки специального вида: {% конструкция %} для алгоритмических
конструкций и {{ данные }} для вставки соответствующих данных. В качестве
механизма вычисления дополнительных значений, используются так называемые
фильтры, которые представляют собой «синтаксический сахар» для применения
функций из некоторого заданного набора к указанным данным. В качестве
оператора применения фильтра, использован символ «|». Фильтры могут иметь
параметры, определяющие способ преобразования данных, параметры передаются
в квадратных скобках через точку с запятой. Таким образом, выражение
«материалы|select[стоимость] |sum» приведет к выделению значений атрибутов
«стоимость» у каждого объекта из коллекции «материалы», после чего стоимости
будут просуммированы. Таким образом, применение такого каскада фильтров
позволит описать значение, которое может стоять в графе «итого».
52
2.6 Концептуальное проектирование базы данных
Эффективное выполнение возложенных на информационную систему
функций невозможно без эффективной организации хранения данных о текущем
состоянии организации. Хранимые данные должны быть полны, то есть в полном
объеме отражать все важные, с точки зрения решаемых задач, характеристики
предметной области, достоверны, актуальны, непротиворечивы и, по возможности,
не избыточны. Объем данных, обрабатываемых информационной системой,
достаточно велик, что приводит к необходимости их организации в виде базы
данных для эффективного хранения и использования.
Целям
разрабатываемой
информационной
системы
наиболее
полно
удовлетворяет реляционная модель данных. В рамках данной модели можно
наиболее полно и формально отразить основные аспекты предметной области и
добиться требуемых свойств.
На рисунке 20 показана концептуальная схема базы данных на логическом
уровне. На приведенной диаграмме сущность-связь присутствуют четыре
основные сущности:
1. Заказ. Данную сущность можно назвать основной, поскольку именно её
экземплярам соответствует основной объект деятельности организации — заказы
клиентов на выпуск печатной продукции. Атрибуты данной сущности определяют
важнейшие параметры заказа, которые фигурируют в отчетности.
2. Материал. Экземпляры данной сущности представляют собой описание
расходных материалов, используемых типографией при выполнении заказов. При
этом в каждый момент времени в базе данных должна храниться актуальная цена
на материал, поскольку только в таком случае возможно адекватно оценить
себестоимость заказа с учетом текущей рыночной ситуации. Данный момент
следует пояснить. Даже в том случае, когда материалы хранились на складе
достаточно давно и их отпускная цена была ниже (или выше) текущей, требуется
знать актуальную цену, поскольку расход материала приведет к необходимости
53
пополнения его запасов в ближайшем будущем. Во избежание убытков, стоимость
производства должна рассчитываться исходя из текущей стоимости материалов, а
не из стоимости на момент закупки.
3. Работа. При производстве печатных изделий проводятся различные
работы, такие как переплет, макетирование и т.п. В каждый момент времени в базе
данных должен храниться перечень всех работ, которые могут быть выполнены
организацией, и текущие расценки выполнения этих работ.
4. Сотрудник. Экземпляры данной сущности описывают сотрудников
организации.
Рисунок 20. Концептуальная схема базы данных
Логические взаимосвязи между основными сущностями описываются
посредством ассоциативных сущностей. Наиболее важной из них является
сущность «Продукт». Основу работы полиграфического отдела составляет
54
выполнение заказов по выпуску крупных серий однотипной печатной продукции,
то есть, в сущности, множества копий одного образца. Исходя из этого,
целесообразно рассматривать процесс выполнения и затраты не всего заказа в
целом, а одного экземпляра продукции в рамках данного заказа. При этом в рамках
одного заказа может изготавливаться несколько типов изделий.
Прежде чем приступить к непосредственному изготовлению печатного
изделия, требуется провести предварительные работы, такие как верстка,
макетирование и т.п. В результате может быть произведено достаточно большое
количество различных информационных материалов (макеты, обложки, списки
авторов и пр.), которые могут быть использованы в дальнейшем (например, при
повторении заказа). По этой причине с каждым экземпляром сущности «Продукт»
может быть ассоциировано несколько экземпляров сущности «Дополнительный
материал». Экземпляры сущности «Дополнительный материал» представляют
собой некий файл с описанием, хранимый в базе данных с целью его дальнейшего
использования.
На изготовление каждого печатного изделия расходуется определенное
количество материалов. Учет расхода материалов реализован через использование
сущности «Израсходованный материал». Значения атрибутов экземпляров в
данной сущности определяют количество израсходованного материала в принятых
единицах измерения, заказ, в рамках которого этот материал расходовался, а также
стоимость материала на момент расходования.
Модель базы данных должна адекватно отражать процессы, происходящие в
предметной области. В частности, в процессе работы организации вполне вероятно
возникновение ситуаций, когда по определенным причинам (например, брак,
неисправность техники и т.п.) на выполнение заказа уходит больше материалов,
чем необходимо для запланированного изготовления заданного числа экземпляров
продукции. Для учета подобных ситуаций, введена сущность «Дополнительный
расход», аналогичная сущности «Израсходованный материал». При указании
55
дополнительного расхода материалов обязательным является указание причины,
вызвавшей превышение запланированного расхода.
Работы, выполняемые сотрудниками в рамках заказа, целесообразнее
соотнести со всем заказом в целом, а не с отдельным типовым продуктом,
поскольку исполнители в процессе выполнения заказа могут меняться, при этом
объем выполненной работы может существенно отличаться для разных
сотрудников. По этой причине введена ассоциативная сущность «Выполненная
работа» между сущностями «Работа», «Сотрудник» и «Заказ». По причине,
аналогичной учету расхода материала, для экземпляров сущности «Выполненная
работа» сохраняется стоимость работы, действующая в момент ее выполнения. Это
позволяет в дальнейшем посчитать стоимость выполнения заказа в любой момент
времени.
Для представленной реляционной модели предметной области отсутствуют
сложные ограничения целостности (тем не менее, нельзя исключать появления их
в будущем при учете более сложных аспектов предметной области, например, при
учете запаса расходных материалов). Принимая во внимание этот факт, а также то,
что
в
изначальном
варианте
система
ориентирована
на
персональное
использование, было принято решение использовать СУБД SQLite3. Данная СУБД
уровня API предлагает достаточно высокую производительность при полной
поддержке стандарта языка запросов SQL92, что делает её оптимальным решением
для достижения поставленных задач проектирования. Отметим, что данная СУБД
не содержит средств обеспечения безопасности и разграничения прав доступа на
объекты базы данных, поэтому данные аспекты организованы на уровне
приложения[10][11].
56
2.7 Словарь проекта
Словарь проекта описывает весь проект, перечисляя все, что в нем
содержится – процессы (<PRO>), потоки (<DF>), внешние сущности (<EXT>) и
базы данных(<STR>):
<PRO> Выбор пользователя
<PRO> Проверка введенных данных
<PRO>Авторизация под начальником
<PRO>Авторизация под сотрудником
<PRO> Просмотр журнала заказов под сотрудником
<PRO> Просмотр журнала заказов под начальником
<PRO> Добавление заказа
<PRO> Удаление заказа
<PRO> Добавление имени заказчика
<PRO> Установка статуса заказа
<PRO> Простановка номера заказа вручную
<PRO> Простановка номера заказа автоматически
<PRO> Заполнение содержания работ по заказу
<PRO> Заполнение формы «Материалы»
<PRO> Заполнение названия материала
<PRO> Установка единицы измерения количества материала
<PRO> Установка цены материала
<PRO> Формирование материального отчета
<PRO>Добавление позиции материала к заказу
57
<PRO>Удаление позиции материала из заказа
<PRO>Автоматический расчет стоимости материалов по заказу
<PRO> Автоматический расчет стоимости материалов за период времени
<PRO> Формирование материального отчета в табличном формате
<PRO>Заполнение формы «Заработная плата»
<PRO>Заполнение поля «Тип работ»
<PRO>Установка стоимости работ
<PRO>Автоматический расчет стоимости работ по заказу
<PRO> Добавление позиции типа работ к заказу
<PRO> Удаление позиции типа работ из заказа
<PRO> Формирование готовых заказов в текстовом формате
<PRO> Экспорт в формат .doc
<PRO>Экспорт в формат .xls
<DF> Имя заказчика
<DF> Содержание работ
<DF> Сумма заказа
<DF> Номер заказа
<DF> Статус заказа
<DF> Нормы заработной платы
<DF> Количество выполненных работ
<DF> Тип работ
<DF> Стоимость выполненных работ
58
<DF> Значение НДС
<DF> Значение отчислений
<DF> Цена на материалы
<DF> Название материала
<DF> Единица измерения материала
<DF> Количество материала
<DF> Стоимость материалов
<DF> Материальный отчет
<DF> Текст заказа
<DF> Дата выполнения
<DF>ФИО сотрудника
<EXT> Начальник
<EXT>Сотрудник
<EXT>Заказчик
<EXT>Поставщик
<STR> База данных
2.8 Словарь данных
Словарь
данных
представляет
собой
определенным
образом,
организованный список всех элементов данных системы с их точными
определениями, что дает возможность различным категориям пользователей (от
системного аналитика до программиста) иметь общее понимание всех входных и
выходных потоков и компонентов хранилищ.
59
Таблица 1. Словарь данных
Поток
Сущность
Данные для входа в Сотрудник
систему
Проверенные
Логин (в БД не хранится)
Пароль (в БД не хранится)
Сотрудник
данные
Данные о
Атрибуты
Логин (в БД не хранится)
Пароль (в БД не хранится)
Сотрудник
сотруднике
Имя
Фамилия
Отчество
Должность
Данные о заказе
Заказ
Номер заказа
Исходные данные
Срок выполнения
Дополнительные требования
Заказчик
Данные о
Материал
материалах
Наименование
Единица измерения
Стоимость за единицу
Исполнение заказа
Продукт
Наименование
Количество экземпляров
Количество страниц
Формат
Цветность
60
Переплет
Данные о работах
Работа
Наименование
Стоимость
Материальный
-
Файл формата .xls
-
Файл формата .doc
отчет
Оформленные
заказы
61
ЗАКЛЮЧЕНИЕ
В любой организации, как большой, так и малой, возникает проблема
управления данными, которое обеспечило бы наиболее эффективную работу.
Некоторые организации используют для этого бумажные носители, однако
современные предприятия привлекают информационные системы, позволяющие
эффективно хранить, извлекать информацию и управлять большими объемами
данных. Сегодня в значительной степени возрастает интерес к информационным
технологиям, причем всплеск интереса отмечен в учреждениях всех форм
собственности – государственных, муниципальных, частных.
В результате работы была спроектирована информационная система
мониторинга
предприятия
сферы
услуг,
а
именно,
полиграфическая
промышленность. Данная система сократит время работы сотрудников и позволит
за короткое время получить необходимую информация.
В функции проектируемой информационной системы мониторинга входят:
– учет сведений о заказах, включая как выполненные заказы, так и заказы,
находящиеся в обработке;
– учет расходных материалов, включая их количество и текущую стоимость;
– учет расходов материалов на выполнение заказа;
– отслеживание текущего состояния заказов;
– автоматический расчет стоимости заказа;
– автоматический расчет заработной платы сотрудникам по объему
выполненных работ;
– автоматическая генерация отчетности.
Функционал данной системы не ограничен использованием её лишь в
пределах полиграфического отдела. Система может быть легко переопределена на
работу в ином хозрасчётном подразделении.
62
Очевидна
и
экономическая
эффективность
предлагаемой
системы
информационной поддержки деятельности полиграфического отдела.
Поскольку планируется использовать систему в течение довольно долгого
времени,
её
разработку
целесообразными.
и
внедрение
следует
признать
экономически
63
БИБЛИОГРАФИЧЕСКИЙ СПИСОК
1. Грофф, Дж. SQL: Полное руководство [Текст]: [пер. с англ.] / П. Вайнберг.
- 2-е изд., перераб. и доп. - К.: Издательская группа BHV, 2001. - 816 с., ил.
2. Molkentin, D. The Book of Qt 4: The Art of Building Applications [Текст] /
Daniel Molkentin - No Starch Press, 2007. - 442 с., ил.
3. QT 4.3: Справочная документация по QT (Выпуск Open Source)
[Электронный ресурс]. – Электрон. текстовые, граф. дан. – Режим доступа:
http://www.doc.crossplatform.ru/qt/4.3.2/.
4. Маклаков С.В. Моделирование бизнес-процессов с BPwin 4.0 / С.В.
Маклаков – М.: Диалог-МИФИ, 2002. – 85 с.
5. ГОСТ 2.105 – 95. Общие требования к текстовым документам [Текст].
Взамен ГОСТ 2.105–79, ГОСТ 2.906–71; введен 1996–07–01. – М.: Изд-во
стандартов, 1996. – 29 с. – (Единая система конструкторской документации).
6. Леоненков, А. Самоучитель UML 2 [Текст] / А. Леоненков - СПБ.: БХВПетербург, 2007. - 576 с., ил.
7. Библиотека ГОСТов, стандартов и нормативов [Электронный ресурс]. Режим доступа: http://www.standartov.ru/norma_doc/48/48122/ index.htm.
8. Положение о коммерческой службе типографии [Электронный ресурс].
Режим доступа: http://www.nrap.ru/pub20_40_1_1278.html
9.
Сущность
и
принципы
организации
хозрасчетных
отношений
[Электронный ресурс]. Режим доступа: http://www.raf.org.ru/raf0016.htm
10. Организация управления типографией [Электронный ресурс]. Режим
доступа:
http://www.compuart.ru/article.aspx?id=21739&iid=993#Организация
управления типографией
11. Август-Вильгельм Шеер, Бизнес-процессы: основные понятия, теории,
методы, Москва.: Просветитель, 1999.
12. Свиридов С., Курьян А.. IDEF0: функциональное моделирование деловых
процессов. Центр ОТСМ-ТРИЗ технологий, Минск, Беларусь 1997 [Электронный
ресурс]. Режим доступа: http://www.trizminsk.org
64
13. Черемных С.В., Семенов И.О., Ручкин В.С. Структурный анализ систем:
IDEF-технологии. — М.: Финансы и статистика, 2001. — 208 с.
14. Боуман, Д. Практическое руководство по SQL. [Текст] / Д. Боуман, С.
Эмерсон, М. Дарновски – Киев: Диалектика, 1997. - 145 с.: ISBN 5-596-00481-8.
15. Методологии разработки программного обеспечения [Электронный
ресурс]. Режим доступа: http://compress.ru/article.aspx?id=11321
16. Маслов С.Г. «SADT моделирование», 2007
65
1/--страниц
Пожаловаться на содержимое документа