close

Вход

Забыли?

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

Кирющенкова Надежда Ильинична.Проектирование информационной системы «Трубчевская районная общественная студенческая организация «Факел»

код для вставки
МИНИСТЕРСТВО ОБРАЗОВАНИЯ И НАУКИ РОССИЙСКОЙ ФЕДЕРАЦИИ
ФЕДЕРАЛЬНОЕ ГОСУДАРСТВЕННОЕ БЮДЖЕТНОЕ ОБРАЗОВАТЕЛЬНОЕ
УЧРЕЖДЕНИЕ ВЫСШЕГО ОБРАЗОВАНИЯ
«ОРЛОВСКИЙ ГОСУДАРСТВЕННЫЙ УНИВЕРСИТЕТ
имени И.С. ТУРГЕНЕВА»
ВЫПУСКНАЯ КВАЛИФИКАЦИОННАЯ РАБОТА
по направлению подготовки: 09.04.03 Прикладная информатика
направленность (профиль): Прикладная информатика в аналитической
экономике
Магистранта: Кирющенковой Надежды Ильиничны, шифр 150848
Факультет: физико-математический
Тема выпускной квалификационной работы
ПРОЕКТИРОВАНИЕ ИНФОРМАЦИОННОЙ СИСТЕМЫ
«ТРУБЧЕВСКАЯ РАЙОННАЯ ОБЩЕСТВЕННАЯ
СТУДЕНЧЕСКАЯ ОРГАНИЗАЦИЯ «ФАКЕЛ»
Магистрант: Кирющенкова Надежда Ильинична
(подпись)
Руководитель: Лебедева Елена Валерьевна
к.п.н., доцент
(подпись)
Зав. кафедрой / РОП: Селютин Владимир Дмитриевич
д.-р.п. н, профессор
(подпись)
Орёл 2017
2
АННОТАЦИЯ
Целью работы выступает проектирование информационной системы
для автоматизации деятельности Трубчевской районной общественной
студенческой организации «Факел».
В работе описана предметная область поставленной проблемы,
определена актуальность и практическая значимость работы. Выделены
основные бизнес-процессы организации. Выявлены основные этапы и
теоретические аспекты процесса автоматизации. Рассмотрены основные
принципы проектирования и регламентирующие их документы. Определена
целесообразность выбора определенных моделей для визуализации бизнеспроцессов. Проведен анализ наиболее распространенных методологий
моделирования. Описаны их функциональные средства, преимущества и
недостатки. Построены модели бизнес-процессов ТРОСО «Факел» в нотации
BPMN. Выделены участники этих процессов: руководитель и ответственный
за
мероприятия.
функциональных
Для
каждой
возможностей.
выделенной
Построены
роли
определен
проектные
ряд
модели
взаимодействия между участниками. Выделены классы, которые участвуют в
бизнес-процессах
деятельности
ТРОСО
«Факел».
Разобран
этап
изменения/добавления членов организации руководителем на диаграмме
последовательности. Построено дерево целей проекта, на основе которого
реализована Диаграмма Ганта и приведен расчет себестоимости проекта по
созданию информационной системы ТРОСО «Факел» для компанииразработчика.
Выпускная квалификационная работа занимает 58 страниц, содержит
10 рисунков и 9 таблиц.
Использованы материалы отечественных и зарубежных специалистов
по вопросам автоматизации деятельности, проектирования информационных
систем, моделирования бизнес-процессов. Проанализирована информация из
статей
международных
научно-практических
конференций,
учебных
3
пособий, журналов; использована информация, предоставленная в общем
доступе разработчиками программных средств.
Ключевые
слова:
бизнес-процессы,
информационная
система,
моделирование, BPMN, UML, нотации, этап жизненного цикла, оркестровка,
диаграмма
межпроцессного
взаимодействия,
хранилище,
диаграмма
прецедентов, диаграмма классов, диаграмма последовательности, диаграмма
Ганта
4
ANNOTATION
The aim of the work is the design of an information system for the automation of the activities of the Trubchevsky District Public Student Organization
"Fakel".
The paper describes the subject area of the problem, the relevance and practical significance of the work is determined. The main business processes of the
organization are identified. The main stages and theoretical aspects of the automation process are identified. The main design principles and documents regulating
them are considered. The expediency of choosing certain models for visualization
of business processes is determined. The most common modeling methodologies
are analyzed. Their functional means, advantages and disadvantages are described.
The models of business processes of TROSO "Torch" are built in the notation of
BPMN. Participants in these processes are singled out: the leader and the responsible for the activities. For each selected role, a number of functionality is defined.
Project models of interaction between participants are constructed. The classes that
participate in the business processes of the TROSO "Torch" are identified. The
stage of changing / adding members of the organization by the leader on the diagram of the sequence is disassembled. The goal tree of the project was constructed
on the basis of which the Gantt Chart was implemented and the calculation of the
cost of the project for the creation of the TROSO "Fakel" information system for
the developer company was provided.
Graduation qualification work takes 58 pages, contains 10 figures and 9 tables.
Materials of domestic and foreign experts on questions of automation of activity, designing of information systems, modeling of business processes are used.
The information from the articles of international scientific-practical conferences,
teaching aids, magazines was analyzed; The information provided by the software
developers in general access is used.
5
Keywords: business processes, information system, modeling, BPMN,
UML, notations, life cycle stage, orchestration, interprocess communication diagram, storage, pre-assignments diagram, class diagram, sequence diagram, Gantt
chart
6
СОДЕРЖАНИЕ
ВВЕДЕНИЕ .............................................................................................................. 7
ГЛАВА 1. АНАЛИЗ И МОДЕЛИРОВАНИЕ ПРЕДМЕТНОЙ ОБЛАСТИ .... 10
1.1 Актуальность темы исследования ................................................................. 10
1.2 Обзор существующих систем моделирования ............................................. 13
1.3 Моделирование процессов в нотации языка BPMN .................................... 22
ГЛАВА 2. ПОСТРОЕНИЕ ПРОЕКТНОЙ МОДЕЛИ ИНФОРМАЦИОННОЙ
СИСТЕМЫ ............................................................................................................. 27
2.1 Выявление требований к системе .................................................................. 27
2.2 Детальное проектирование............................................................................. 41
2.3 Расчет временной продолжительности проекта .......................................... 50
2.4 Оценка себестоимости разработки и внедрения информационной системы
ТРОСО «Факел» .................................................................................................... 52
ЗАКЛЮЧЕНИЕ ..................................................................................................... 59
СПИСОК ЛИТЕРАТУРЫ..................................................................................... 61
7
ВВЕДЕНИЕ
В
настоящее
время
происходит
глобальная
автоматизация
на
предприятиях малого, среднего и большого бизнеса всего мира, не
исключаются
и
общественные
объединения.
Это
обусловлено
необходимостью повышения качества выполняемых работ и уменьшения
трудозатрат на их выполнение.
Ведь в результате автоматизации любого процесса лежит сокращение
времени обслуживания клиентов и формирование необходимых документов
и отчетов, повышение точности управленческих отчетов и тем самым
понижение расходов и увеличение конкурентоспособности.
Таким образом, исходя из вышеперечисленного видно, что процесс
автоматизации
общественной
студенческой
организации
«Факел»
на
сегодняшний день является актуальным.
Практическая
значимость
работы
состоит
информационной системы, которая позволит
в
ввести учет
разработке
движения
студенческой молодежи в составе Трубчевской районной общественной
студенческой организации «Факел» (далее ТРОСО «Факел») и тем самым
сократить трудозатраты руководителей направлений ТРОСО «Факел».
Целью
данной
работы
является
разработка
и
внедрение
информационной системы ТРОСО «Факел».
Объектом исследования является процессы деятельности ТРОСО
«Факел».
При этом предметом исследования является моделирование и
проектирование бизнес-процессов для автоматизированной информационной
системы.
Для достижения данной цели были поставлены следующие задачи:

изучить и проанализировать процессы движения студенческой
молодежи в составе ТРОСО «Факел»;
8

изучить
и
проанализировать
достоинства
и
недостатки
существующих методов моделирования информационных систем;

смоделировать
основные
бизнес-процессы,
выполняемые
в
автоматизированной информационной системе;

обосновать
функции
разработанного
автоматизированного
рабочего места;

спроектировать информационную систему при помощи диаграмм
вариантов
использования,
диаграмм
классов
и
диаграммы
последовательности действий;

дать оценку затрат необходимых на разработку и внедрение
информационной системы ТРОСО «Факел».
Работа построена в соответствии с целью и задачами исследования, и
состоит из введения, двух глав, заключения, списка литературы, аннотации.
Во
введении
обосновывается
актуальность темы
исследования,
определяются предмет и объект исследования, формулируются цель и
основные задачи, приводится описание структуры работы.
В первой главе обоснована актуальность поставленной проблемы,
рассмотрены теоретические аспекты автоматизации систем, проведен анализ
имеющихся методик моделирования ИС. Также первая глава содержит
модели основных процессов для проектирования информационной системы
учета движения студенческой молодежи в составе ТРОСО «Факел».
Вторая
глава
проектирования
содержит
информационной
описание
системы
непосредственно
для
процесса
автоматизации
учета
движения студенческой молодежи в составе ТРОСО «Факел». Подробно
рассмотрены участники процессов, сами процессы, построены диаграммы
вариантов использования, классов, последовательности. Произведена оценка
затрат необходимых на разработку и внедрение информационной системы
ТРОСО «Факел».
9
Заключение представляет собой обобщение основных результатов
проведенной работы, описание их взаимосвязи с общей целью и
конкретными задачами, поставленными и сформулированными во введении.
Список
литературы
содержит
используемых при написании работы.
перечень
основных
источников,
10
ГЛАВА 1. АНАЛИЗ И МОДЕЛИРОВАНИЕ ПРЕДМЕТНОЙ ОБЛАСТИ
1.1 Актуальность темы исследования
Для правильного ведения хозяйственной деятельности и обеспечения
выполнения целей организации любого вида направления, необходимо все
время иметь информацию о ходе и результатах деятельности предприятия,
включая и состояние его средств, количества персонала и так далее. Данные
сведения могут быть получены только при помощи учета [26].
Под учетом понимаются наблюдение, регистрация и обобщение в
соответствующих
учетных
документах
хозяйственных
результатов,
полученных в ходе деятельности организации.
На сегодняшний день различают несколько видов учета:

внешний, который включает в себя финансовый учет;

внутренний, который включает в себя расчет затрат по видам,
анализ численных показателей, данных учета финансов и затрат для контроля
экономической эффективности и составление планов для предприятия в
целом и его подразделений [11].
Каждое из существующих в мире предприятий ведет оба вида учета, и
если внешний учет зачастую автоматизирован, то внутренний учет в
большинстве
случаев
ведется
вручную,
вследствие
чего
каждый
неавтоматизированный бизнес-процесс обладает рядом недостатков:

неэффективное ведение процессов сбора, передачи, обработки и
хранения информации, процессов выдачи ее результатов;

дублирование
потоков
информации,
приводящее
недостоверности результатов;

высокие затраты времени;

большой объем работ, снижающий качество управления [10].
Поэтому автоматизация внутреннего учета так необходима.
Автоматизация внутреннего учета способствует:
к
11

повышению прозрачности и управляемости предприятием;

повышению эффективности деятельности всех служб компании;

автоматическому предоставлению управленческую информацию
для руководства;

повышению качества и достоверности отчетных форм;

повышению оперативности получения отчетности;

снижению трудозатрат на оперативный учет;

снижению риска ошибок при формировании и переносе данных
вручную, прочих погрешностей в работе, связанных с человеческим
фактором.
Автоматизация
деятельности
предприятия
при
помощи
информационной системы, сегодня является наиболее популярным, быстрым
и эффективным способом улучшения деятельности предприятия [12].
В основе любой информационной системы лежит жизненный цикл,
который включает в себя несколько этапов:

предпроектный анализ (включая формирование функциональной и
информационной
моделей
объекта,
для
которого
предназначена
информационная система);

проектирование
системы
(включая
разработку технического
задания, эскизного и технического проектов и моделирование);

разработку
системы
(в
том
числе
программирование
и
тестирование прикладных программ на основании проектных спецификаций
подсистем, выделенных на стадии проектирования);

интеграцию и сборку системы, проведение ее испытаний;

эксплуатацию системы и ее сопровождение;

развитие системы [13].
Рассмотрим наиболее сложный этап жизненного цикла системы проектирование ИС. Проектирование информационной системы базируется
на
моделировании
предметной
области.
Для
того
чтобы
обладать
12
достоверным проектом ИС в виде совокупности правильно работающих
программных продуктов, необходимо обладать целостным, системным
представлением модели, которое содержит в себе и показывает все аспекты
функционирования будущей ИС.
При этом под моделью предметной области следует понимать
некоторую систему, которая имитирует структуру или функционирование
исследуемой предметной области и которая отвечает основному требованию
– адекватность этой области.
Предварительное моделирование предметной области способствует
сокращению времени и сроков проведения проектировочных работ и
получению
качественного
проекта.
Без
проведения
моделирования
предметной области вероятность допущения большого количества ошибок,
которые приводят к экономическим потерям и высоким затратам очень
велика. Поэтому все современные технологии проектирования ИС в первую
очередь базируются на применении методологии моделирования предметной
области [1].
На сегодняшний день существует ряд нормативных документов,
которые
регламентируют
процесс
автоматизации
-
четыре
межгосударственных стандарта вступивших в силу в 1990 году:
1. ГОСТ 34.201-89 «Виды, комплектность и обозначение документов
при
создании
распространяется
автоматизированных
на
все
систем»
-
стандарт,
который
автоматизированные
системы,
которые
применяются в различных сферах деятельности, включая их сочетание.
2. ГОСТ 34.601-90 «Автоматизированные системы. Стадии создания» стандарт, который содержит общее положение, стадии и этапы создания
автоматизированной системы, и справочное приложение.
3. ГОСТ
34.602-89
«Техническое
задание
на
создание
автоматизированной системы» - стандарт, который содержит информацию о
требованиях к техническому заданию, которые описаны в общем положении.
13
4. ГОСТ 34.603-92 «Виды испытаний автоматизированных систем»
стандарт, в котором расписаны общее положение, предварительные
испытания, опытная эксплуатация, приемочные испытания.
В рамках данной работы планируется автоматизировать основную
деятельность работы ТРОСО «Факел» с учетом существующих ГОСТов и
жизненного цикла ИС: процесс учета движения численности организации,
который будет включать в себя следующие функции:

учет вступивших в организацию членов за определенный период;

ведение картотеки всех членов организации за определенный
период;

учет мероприятий, проводимых ТРОСО «Факел».
Так как на данный момент на отечественном рынке информационных
систем, предназначенных для автоматизации деятельности работы ТРОСО
«Факел» отсутствуют ИС с подобным функционалом, то предполагается
собственная разработка под нужды ТРОСО «Факел».
1.2 Обзор существующих систем моделирования
Такой сложный процесс бизнес-моделирования может реализовываться
с использование различных методик, которые отличаются своим подходом к
представлению
различными
моделируемой
представлениями
организации
об
[14].
организации
В
соответствии
методики
делятся
с
на
объектные и функциональные (структурные) [15].
Функциональные методики рассматривают организацию в виде набора
функций, которые преобразуют поток входящей информации в поток
выходной информаций. Данный процесс потребляет определенные ресурсы
для преобразования информации. Основным отличием функциональной
методики от объектной методики заключается в четком отделении функций
от самих данных. Наиболее известными функциональными методиками
является методики IDEF и BPMN [4].
Методология IDEF0 по праву считается следующим этапом развития
14
хорошо известного графического языка описания функциональных систем
SADT (Structured Analysis and Design Technique). Исторически методология
IDEF0 как стандарт была разработана еще в 1981 году в рамках обширной
программы автоматизации промышленных предприятий, которая носила
обозначение ICAM (Integrated Computer Aided Manufacturing). Название
методологии IDEF является производным этой программы - Icam DEFinition,
последняя редакция которой была выпущена в декабре 1993 года
Национальным Институтом по Стандартам и Технологиям США (NIST).
Цель методики IDEF0 заключается в
построение функциональной
схемы исследуемой системы, которая смогла бы описать все необходимые
процессы с точностью, достаточной для однозначного моделирования
деятельности системы.
Данная методология базируется на четырех основных понятиях:

функциональный блок (Activity Box), который представляет собой
некоторую конкретную функцию в рамках изучаемой системы;

интерфейсная дуга (Arrow), которая отображает элемент системы,
обрабатывающийся функциональным блоком или оказывающий какое-либо
иное влияние на функцию, отображенную данным функциональным блоком.
Интерфейсные дуги зачастую носят название потоки или стрелки;

декомпозиция
(Decomposition),
которая
является
основным
понятием стандарта IDEF0. Принцип декомпозиции заключается в разбиении
сложного процесса на составляющие его функции. Следует отметить, что
уровень детализации процесса определяется непосредственно разработчиком
модели.

глоссарий (Glossary), который представляет из себя описание
сущности элемента[5].
Модели IDEF0 являются не только понятными даже для лиц, которые
не принимали участия в ее создании, но и эффективными для проведения
показов и презентаций.
BPMN
сегодня
является
самым
простым
и
гибким
языком
15
моделирования процессов. Простота достигается за счет наглядности, так как
BPMN
для
описания
использует
условные
обозначения,
которые
представлены в виде диаграмм и блок-схем. Гибкой нотацию делает набор
элементов и правил, благодаря которым создать схему может любой бизнеспользователь без навыков программирования. Помимо этого, неоспоримым
плюсом нотации BPMN
является то, что созданные модели являются
выполняемыми, а не просто документируются.
Нотация BPMN является синтезом передового опыта моделирования и
применяется для задач пошагового описания выполнения бизнес-процессов.
В результате, BPMN стала инструментом с широкими возможностями
описания детального алгоритма и его выполнения. Отличие этой нотации от
других заключается в том, что она обладает наибольшим количеством
графических элементов.
Нотация BPMN использует пять категорий элементов:

элементы потока: события, шлюзы (они же логические операторы)
– действия, события, логический оператор;

данные – объект данных, хранилище данных, сообщение;

зоны ответственности – дорожки и пулы;

соединяющие элементы – ассоциации, потоки сообщений, потоки
управления;

сноски (артефакты) – группа, аннотация, ссылка.
Целью функциональной методики потоков данных является построение
модели рассматриваемой системы в виде диаграммы потоков данных (Data
Flow Diagram, сокращенно DFD), которая обеспечивает правильное описание
выходов при заданном воздействии на вход системы. Диаграммы потоков
данных являются основным средством моделирования функциональных
требований к проектируемой информационной системе[6].
При разработке DFD применяются:

потоки данных, которые
отображают процесс
информации из одной части системы в другую;
передачи
16

процессы, состоящие из выходных потоков, продуцированных в
свою очередь, из входных в соответствии с действием, которое и задается
именем процесса;

хранилище (накопитель) данных, которое позволяет определять
данные, которые будут хранится в памяти между процессами;

внешняя сущность, которая представляет собой некоторый
материальный объект вне системы, который является источником или
приемником данных [7].
Объектно-ориентированная
методика
применяет
объектную
декомпозицию, при этом статическая структура изображается в терминах
объектов и связей между ними, а поведение системы описывается в терминах
обмена сообщениями между этими объектами.
Целью объектно-ориентированной методики является построение
бизнес-модели организации, которая позволяет перейти от модели сценариев
использования к модели, определяющей отдельные объекты, которые в свою
очередь участвуют в реализации бизнес-функций [8].
Основными понятиями объектно-ориентированного подхода являются
объект и класс.
Объектом называется предмет или явление, которое имеет четко
определенное поведение и которое обладает состоянием, поведением и
индивидуальностью.
Классом является некоторое множество объектов, которые связаны
общностью структуры и поведения.
Важным качеством объектного подхода является согласованность
моделей
деятельности
организации
и
моделей
проектируемой
информационной системы от стадии формирования требований до стадии
реализации. По объектным моделям может быть прослежено отображение
реальных сущностей моделируемой предметной области (организации) в
объекты и классы информационной системы.
Большинство существующих на сегодняшний день методов объектно-
17
ориентированного подхода включают язык моделирования и описание
процесса моделирования [16].
Процессом, при этом, следует называть некоторое описание шагов,
которые необходимо выполнить при разработке проекта.
В качестве языка моделирования объектного подхода применяется
унифицированный язык моделирования UML, который включает в себя
стандартный набор диаграмм для моделирования, то есть графическое
представление множества элементов, изображающееся зачастую в виде
связного графа [9].
При выборе графической нотации для описания типового постоянно
действующего бизнес-процесса предприятия по изменению каких-либо
производственных
процессов
(ТБПИ)
автоматизированной
системы
управления предприятием (АСУП) необходимо учитывать две группы
требований, предъявляемых к методологиям моделирования:
1)
возможность
представления
всех
существующих
процессов
предприятия, включая технологические, логистические и организационные
процессы;
2) представление сценариев ТБПИ.
Рассмотрим наиболее известные и популярные на сегодняшний день
графические нотации описания процессов: IDEF0, IDEF3, EPC, DFD,
графоаналитические схемы информационного взаимодействия (ГАС), BPMN
и язык UML.
Первая группа требований при выборе какой-либо графической
нотации моделирования включает в себя возможность представления в
графическом виде следующих особенностей деятельности предприятия:
1) процесса, операции;
2) одиночных входных и выходных ресурсов;
3) вектора входных и выходных ресурсов;
4) состава процесса (декомпозиция);
5) условия запуска процесса;
18
6) средств выполнения процесса;
7) ветвлений и слияний процессов;
8) асинхронных и синхронных процессов.
К
критериям
второй
группы
требований,
предъявляемых
к
методологиям моделирования относится возможность представления в
графическом виде следующих особенностей бизнес-процессов:
1) событие (например, инцидент, проблема, запрос и так далее);
2) роль (элемент организационной структуры) автоматизированной
системы управления;
3) элемент сценария действий бизнес-процесса (операция);
4) последовательность действий сценария (переходы с ветвлениями и
синхронизацией);
5) элемент информационной системы;
6) элемент документооборота;
7)
объектно-ориентированное
описание
архитектуры
автоматизированной системы управления [18].
Данные
требования
формируют
как
требования
к
средствам
визуализации СИМ, так и к средствам описания базы знаний предметной
области.
Ниже на основании описанных групп критериев представлены
результаты анализа нотаций.
1. IDEF0.
В IDEF0 одинаково изображаются ресурсные потоки и потоки событий
(инцидентов, проблем), однако роли и средства ТБПИ могут быть
представлены в виде механизмов. Главным недостатком IDEF0 является то,
что она
плохо ориентирована на описание архитектуры программного
обеспечения.
2. IDEF3.
В IDEF3, также как в IDEF0 одинаково изображаются ресурсные
потоки и потоки событий (инцидентов, проблем), роли и средства ТБПИ
19
могут быть представлены в виде механизмов. IDEF3, также как и IDEF0,
плохо ориентирована на описание архитектуры программного обеспечения.
Но в отличи от IDEF0, IDEF3 хорошо представляет логику синхронных и
асинхронных процессов и событий.
3. СИМ ARIS.
В СИМ ARIS для описания процессов применяется стандарт EPC
(Extended Event Driven Process Chain, с англ. расширенная нотация описания
цепочки процесса, управляемого событиями).
Основными достоинствами СИМ ARIS является то, что:
 процесс представляет собой последовательность процедур, которые
расположены в порядке их выполнения;
 хорошо идентифицированы ресурсные потоки и потоки событий,
при этом роли и средства ТБПИ разделяются;
 поддерживает выход на динамическое моделирование процессов.
Основными недостатками СИМ ARIS является то, что она плохо
ориентирована не только на описание технологических и логистических
процессов, в которых применяется огромное количество различных ресурсов
и средств (схемы становятся плохо воспринимаемыми), но и на описание
архитектуры программного обеспечения.
4. DFD.
Основными достоинствами DFD является то, что она хорошо
ориентирована
на
описание
архитектуры
(представление
информационных
потоков,
программного
функций
обеспечения
информационной
системы, хранилищ данных).
Но главными недостатками при этом являются:
 одинаковое изображение ресурсных потоки и потоков событий, при
этом роли и средства ТБПИ могут быть представлены в виде внешних
сущностей;
 плохая
ориентированность
на
описание
технологических
и
логистических процессов, в которых используется большое количество
20
разных ресурсов и средств (схемы становятся плохо воспринимаемыми,
целесообразнее
векторное
представление
потоков
ресурсов
и
его
детализация).
5. ГАС.
Диаграмма ГАС состоит из набора графических блоков и комментариев
к ним, которые служат для отображения выполнения функций, закрепленных
в свою очередь за соответствующими подразделениями. Все блоки
диаграммы связаны друг с другом отношениями передачи данных или
управляющих воздействий.
ГАС
при
этом прекрасно
отражает
динамику взаимодействия
подразделений в процессе функционирования в соответствии с требованиями
стандартов
серии
взаимодействия
ИСО
9000.
составляют
Основу
модели
классификаторы,
информационного
представляющие
собой
структурированное описание функций обеспечения деятельности, функций
управления, организационной структуры и бизнес-процессов предприятия.
В ГАС хорошо идентифицировать потоки событий. Роли и средства
ТБПИ
при этом разделяются и могут быть описаны в виде дорожек и
внешних модулей соответственно.
ГАС прекрасно ориентирована на описание архитектуры программного
обеспечения
(представление
информационных
потоков,
функций
информационной системы, хранилищ данных).
Главным недостатком ГАС является плохая ориентированность на
описание технологических
и
логистических
процессов:
нет средств
формализации потоков ресурсов, нет выхода на описание динамики
процессов, нет средств формализации асинхронных и синхронных процессов.
6. Нотация BPMN.
Нотация BPMN (Business Process Model and Notation, нотация и модель
бизнес-процессов) предназначена для описания диаграмм бизнес-процессов,
понятных как техническим специалистам, так и бизнес-пользователям.
Достоинствами BPMN является то, что:
21
 графические
аспекты
нотации
разделены
по
конкретным
категориям;
 хорошо идентифицировать потоки событий;
 роли и средства ТБПИ разделяются и могут быть описаны в виде
дорожек и внешних модулей соответственно;
 прекрасно ориентирована на описание архитектуры программного
обеспечения;
 представляет логику синхронных и асинхронных процессов и
событий, поддерживает выход на динамическое моделирование процессов.
Недостатком BPMN, является то, что она не ориентирована на
описание ресурсных потоков, что затрудняет описание технологических и
логистических процессов, использующих большое количество разных
ресурсов.
7. UML
В
UML
потоки
событий
могут
быть
представлены
как
информационные потоки (с использованием диаграмм активности, состояний
или последовательности), роли и средства ТБПИ могут быть представлены в
виде актеров. UML прекрасно ориентирована на описание архитектуры
программного обеспечения и поддерживает объектно-ориентированный
подход.
UML
плохо
ориентирована
на
описание
технологических
и
логистических процессов: отсутствуют средства формализации потоков
ресурсов и средств, выход на описание динамики процессов имеется только у
диаграмм активности и состояний, нет средств формализации асинхронных и
синхронных процессов.
Полученные результаты сведем в таблицу 1.
Таблица 1 – Сравнение методик моделирования ИС
IDEF0 IDEF3 СИМ DFD
ГАС
BPMN UML
22
ARIS
Графические
аспекты -
-
+
-
+
+
+
-
-
+
+
+
+
-
-
-
+
+
-
+
-
-
-
+
-
-
+
-
-
+
-
нотации разделены по
конкретным
категориям
Ориентированность на описание архитектуры
программного
обеспечения
Ориентированность на описание
технологических
и
логистических
процессов
Представление логики синхронных
и
асинхронных
процессов и событий
Выход
на -
динамическое
моделирование
процессов
Из таблицы 1 видно, что для описания процессов предприятия
(технологических, логистических, организационных) наиболее эффективным
будет использование методологии моделирования BPMN.
1.3 Моделирование процессов в нотации языка BPMN
Целью создания информационной системы является автоматизация
основной деятельности ТРОСО «Факел» в части:
23
– оптимизации затрат времени на учет вступивших в организацию
членов за определенный период;
– оптимизации затрат времени на учет мероприятий;
– упрощения обработки и хранения имеющейся информации.
Моделирование бизнес-процессов
является процессом отражения
субъективного видения реально существующих в организации процессов при
помощи различных способов представления [19].
Как было сказано выше наиболее популярной нотацией графического
моделирования является BPMN (BusinessProcessModelandNotation), которая
применяется для донесения широкого спектра информации до различных
категорий пользователей.
Для моделирования процессов, которые протекают на каждом этапе
учета движения численности организации будем использовать нотацию
BPMN 2.0.
Спецификация BPMN 2.0 регламентирует следующие типы диаграмм
бизнес-процессов:
1. Диаграммы оркестровки (схемы потока работ) - это схема, которая
показывает
закрытого
очередность
процесса
выполнения
представляет
операций
собой
схему
процесса.
процесса,
Диаграмма
который
моделируется внутри некоторого контейнера - пула. Данный контейнер
можно изображать на схеме явно или только подразумевать, в случае, когда
пул явно указывается на диаграмме процесса, схема будет называться
закрытой, в противном случае схема будет называется открытой.
2. Диаграммы взаимодействия участников одного или нескольких
бизнес-процессов (Collaboration) [20].
Диаграмма взаимодействия делятся на:
 диаграмму
приватного
взаимодействия
(private),
которая
отображает процесс, исполняемый в пределах какой-либо организации или
координируется из единого центра;
 диаграмму публичного взаимодействия (public), которая показывает
24
коммуникацию между двумя приватными процессами, следует отметить, что
у каждого из процесса свой собственный центр управления и каждый из них
имеет своего владельца. Диаграмма публичного взаимодействия может иметь
разную степень детализации.
3.
Диаграммы
диалогов
(Conversation),
которые
служат
для
отображения информационного обмена сообщениями, сгруппированными по
темам обсуждения. Например, заказ товаров, перевозка грузов, выписка счета
и так далее.
4. Диаграммы хореографии (Choreography), которые служат для
отображения последовательности процедур обмена сообщениями между
двумя и более участниками. В отличие от обычного процесса, который
обязательно изображается внутри пула, хореография обычно описывается без
пулов. В целом, хореография похожа на схему приватного процесса,
поскольку она так же состоит из цепочки задач хореографии, событий и
логических операций. Но, тем не менее, хореография отличается от схемы
оркестровки тем, что операции на ней отображают факт передачи сообщения
между двумя и более участниками.
В данной работе для моделирования процессов применены основные
диаграммы:
– диаграмма взаимодействия(Collaboration), которая показывает обмен
сообщениями между двумя и более участниками. Данный вид диаграмм
применяется для отображения состава и последовательности выполнения
двух и более процессов в виде пулов с указанием взаимодействий между
ними через потоки сообщений;
– диаграмма оркестровки, которая показывает последовательность и
логику выполнения заданий в рамках одного процесса. Так же как и на
диаграмме изображается взаимодействие между частным, рассматриваемым
процессом и другими процессами или участниками, которые в свою очередь
отображены в виде свернутых пулов [21].
Для проектируемой системы процесс взаимодействия ТРОСО «Факел»
25
и членов данной организации представлен на рисунке 1.1.
Как видно из рисунка 1.1 данная диаграмма отображает процесс
обработки учет движения студенческой молодежи
и мероприятий,
изображенный в виде 2 пулов (зоны ответственности), и связывающие их
потоки сообщений. В каждом пуле подробно и последовательно указаны
действия каждого из участников.
Рисунок 1.1 — Диаграмма взаимодействия
В пуле содержатся две дорожки, отображающие действия руководителя
и ответственного за мероприятия ТРОСО «Факел». Чтение процесса всегда
начинается со стартового события (зеленого кружка). После стартового
события – начала работы, руководитель рассматривает поступившие заявки
(операция,
указанная
в
прямоугольнике).
общественную
организацию
руководителю
ТРОСО,
поступают
руководитель
Заявки
через
на
вступление
в
потоки
сообщений
к
рассматривает
заявку
–
ищет
кандидатов в БД, отказывает или утверждает кандидата, распределяет его и
лишь затем регистрирует в БД, оформляет и формирует отчет по членам
ТРОСО «Факел».
Для деятельности ТРОСО «Факел» можно выделить 2 диаграммы
оркестровки: регистрация мероприятия ответственным сотрудником ТРОСО
«Факел»
(рисунок 1.2) и стадии прохождения заявки со стороны
руководителя ТРОСО «Факел» (рисунок 1.3).
26
Рисунок 1.2 — Диаграмма оркестровки с точки зрения ответственного
сотрудника за мероприятия
Рисунок 1.3 — Диаграмма оркестровки с точки зрения руководителя
Схемы взаимодействия показывают обмен сообщениями между двумя
и более участниками [24]. Участники по отдельности управляют своими
бизнес-процессами, у каждого есть свой владелец. Для изображения
участников на схеме взаимодействия обычно используют графический
элемент пул. Взаимодействие между участниками осуществляется при
помощи потоков сообщений. Следует учитывать, что схема определяет лишь
наличие потока сообщений, но не детализирует его содержимое. На схеме
показываются только операции, которые участвуют в обмене сообщениями.
Пул, изображающий участника, может быть пустым, не иметь внутри себя ни
одной операции. В этом случае, такой процесс называется «черный ящик».
Потоки сообщений могут изображаться только между пулами.
Определив бизнес-процессы взаимодействия ТРОСО «Факел» и
студента, а также порядок действия принятия решения, приступим к
проектированию системы.
27
ГЛАВА 2. ПОСТРОЕНИЕ ПРОЕКТНОЙ МОДЕЛИ
ИНФОРМАЦИОННОЙ СИСТЕМЫ
2.1 Выявление требований к системе
Так как ТРОСО «Факел» имеет в собственность свой сайт на
собственном домене и для того чтобы исключить закупку дополнительного
оборудования информационная система будет разработана в виде Webприложения.
Web-приложение
по
сравнению
с
консольными
приложениями
обладает рядом достоинств:
 единовременная настройка. Требуется одна установка на сервер для
всех
пользователей.
Благодаря
централизованности
моментально
выполняется обновление;
 наличие
разнообразного
интерфейса
взаимодействия
с
применением библиотек на JavaScript;
 платформо-независимое,
большинство
доменов
и
платформ
обладают последними версиями PHP И MySQL;
 веб-приложения настроены на совместный доступ;
 все обработки выполняются на сервере, кроссплатформенность, для
работы разработанного приложения необходим только браузер.
 После того, как определили вид разрабатываемого приложения,
построим диаграмму прецедентов, диаграмму вариантов использования и
диаграмму классов.
Как было сказано выше унифицированный язык моделирования UML,
который включает в себя стандартный набор диаграмм для графического
представления множества элементов, изображающееся зачастую в виде
связного графа [27].
Среди существующих типов диаграмм, которые включает в себя UML,
для выявления требований к системе воспользуемся диаграммой прецедентов
28
(вариантов
использования),
диаграммой
классов
и
диаграммой
последовательности.
Диаграммы прецедентов (вариантов использования) используются для
моделирования вида системы с точки зрения внешнего наблюдателя.
Действующее лицо (актер) является внешним источником, который
взаимодействует
с
системой
при
помощи
варианта
использования.
Действующие лица могут быть как реальными людьми, так и другими
компьютерными системами или внешними событиями.
При взаимодействии актера с информационной системой, последняя
выполняет ряд работ, которые образуют вариант использования системы.
Каждый
актер
может
использовать
систему
по-разному,
то
есть
инициировать выполнение разных прецедентов. Таким образом, каждый
вариант использования — есть некоторое функциональное требование к
системе [28].
Для построения модели вариантов использования проанализируем
актеры разрабатываемой системы.
В информационной системе ТРОСО
«Факел» будут работать руководитель ТРОСО «Факел» и ответственный за
мероприятия сотрудник.
Краткое описание актеров представлено в таблице 2.
Таблица 2 - Выявление актеров
Актер
Краткое описание
Руководитель
Занимает главную должность в организации, осуществляет
диалог, как с системой, так и с другими актерами.
Принимает заявление на вступление в организацию,
проверяет были ли они когда-нибудь зарегистрированы,
регистрирует членов организации и формирует по ним
отчет.
Ответственный Выполняет организацию мероприятия, назначает
29
за
ответственных за данным мероприятием, регистрирует
мероприятия
мероприятия и формирует по ним отчет.
сотрудник
Связи между актерами и вариантами отображаются с использованием
следующих отношений [2]:
 ассоциации;
 обобщения;
 включения;
 расширения.
Выявленные варианты использования сведены в таблицу 3.
Таблица 3 - Выявленные варианты использования
Основной актер
Руководитель
Руководитель
Наименование
Формулировка
Поиск данных по
На основании информации в
студентам
системе ищет данные.
Регистрация
Регистрирует данные студентов в
студентов, как
системе
членов организации
Руководитель
Формирование
Формирует отчет, на основании
отчета для анализа
информации по студентам.
деятельности
Ответственный за Поиск данных по
На основании информации в
мероприятия
системе ищет данные.
мероприятиям
сотрудник
Ответственный за Формирование
Формирует отчет, на основании
мероприятия
отчета для анализа
информации по мероприятиям.
сотрудник
деятельности
30
Ответственный за Регистрация
Регистрирует данные по
мероприятия
мероприятиям в системе
мероприятия
сотрудник
На
основании
выявленных
вариантов
использования
построим
диаграммы, отображенные на рисунке 2.1-22.
Рисунок 2.1 – Диаграмма прецедентов «Руководитель»
Рисунок 2.2 – Диаграмма прецедентов «Ответственный за мероприятия
сотрудник»
Анализ вариантов использования выявил следующие взаимосвязи.
1. Руководитель получает доступ к базе данных при условии успешной
проверки прав, после чего ему предоставляется возможность просматривать
записи в БД, создавать новые записи или удалять существующие.
2. Ответственный за мероприятия сотрудник получает доступ к базе
данных
при
условии
успешной
проверки
прав,
после
чего
ему
31
предоставляется возможность просматривать записи в БД или обновлять
записи.
Результирующая диаграмма вариантов использования показана на
рисунке 2.3.
Рисунок 2.3 – Диаграмма вариантов использования системы
Анализ, проведенный выше, не выявил исключенные варианты
использования, были выявлены некоторые прецеденты и взаимосвязи между
прецедентами.
А. Коберн [17]
предлагает способ представления вариантов
использования в виде текстовых спецификаций. Текстовая спецификация при
этом состоит из общей информации о варианте использования.
Спецификация прецедентов, изображенных на рисунке 2.3, приведена в
таблице 4.
Таблица 4 – Текстовая спецификация
Прецедент Предоставление доступа к записям БД
Название:
Предоставление доступа к записям БД
Цель:
Предоставление текущей информации по
членам организации и мероприятиям
Специальные требования:
Специальные требования не определены
32
Предусловия:
Имеются права у данного пользователя
Постусловия:
Система выдала результат
Дополнительные замечания:
Дополнительных замечаний нет
Основной поток:
А: Функции варианта использования начинают
выполняться с отображения записей,
существующих в БД (в случае, когда окно
текущих записей не может быть отражено, то
выполняется альтернативный поток А).
Вариант использования завершается.
Альтернативный поток:
А: Ошибка отображения окна записей; система
сообщает актеру о том, что в данный момент
информация недоступна; вариант
использования таким образом активизируется
и завершается.
Б: Не удается выполнить обновление записей;
система сообщает субъекту о том, что в
данный момент невозможно выполнить
обновление записей; актеру предлагается
повторить обновление или завершить вариант
использования. Вариант использования
завершается.
Прецедент Удаление данных
Название:
Удаление данных
Цель:
Удаление ненужных данных из БД
Специальные требования:
Специальные требования не определены
Предусловия:
Для удаления данных требуются права
Постусловия:
Система выдала сообщение
Дополнительные замечания:
Дополнительных замечаний нет
Основной поток:
А: Функции варианта использования начинают
выполняться с регистрации актера с заданием
33
его имени и пароля. Система проверяет пароль
на достоверность (если введенный пароль
неверен, то активизируется альтернативный
поток А).
Б: Отображаются все записи БД (в случае,
когда отображение в данный момент
невозможно, то выполняется альтернативный
поток Б, актер выбирает запись для удаления (в
случае, когда выбрать запись для удаления
невозможно, то выполняется альтернативный
поток В), для того чтобы удалить выбранную
запись актер подтверждает свой выбор (в
случае, когда не удается удалить запись, то
выполняется альтернативный поток Г).
Вариант использования завершается.
Альтернативный поток:
А: введен неверный пароль; выдача сообщения
ввода неверного пароля; субъекту
предоставляется возможность повторить ввод
пароля или завершить данный вариант
использования.
Б: Не удается отобразить записи; выдается
сообщение актеру о том, что в данный момент
не удается отобразить записи; вариант
использования завершается.
В: Не удается выбрать запись; выдается
сообщение актеру о том, что не удается
выбрать указанную запись; вариант
использования завершается.
Г: Не удается удалить запись; выдается
сообщение актеру о том, что не удается
34
удалить указанную запись; вариант
использования завершается. Вариант
использования завершается.
Прецедент Добавление данных (учебные заведения, члены организации,
мероприятия)
Название:
Добавление данных
Цель:
Добавление новых данных
Специальные требования:
Специальные требования не определены
Предусловия:
Для создания новых данных требуются права
Постусловия:
Созданы новые данные
Дополнительные замечания:
Дополнительных замечаний нет
Основной поток:
А: Функции варианта использования
начинают выполняться с регистрации актера с
заданием его имени и пароля. Система
проверяет пароль на достоверность (в случае,
когда указанный пароль неверен, то
активизируется альтернативный поток А).
Б: Создание новых данных отображает окно с
полями ввода. Актер вводит данные в поля
(при задании неверной информации
выполняется альтернативный поток Б) и актер
подтверждает ввод. Вариант использования
завершается.
Альтернативный поток:
А: введен неверный пароль; выдача
сообщения ввода неверного пароля; субъекту
предоставляется возможность повторить ввод
или завершить вариант использования.
Б: Неверный ввод данных в поля; система
сообщает актеру о неверном вводе
информации и предлагает повторить
35
операцию или завершить вариант
использования. Вариант использования
завершается.
Прецедент Проверка прав
Название:
Проверка прав
Цель:
Идентификация пользователя
Специальные требования:
Специальные требования не определены
Предусловия:
Предусловия не определены
Постусловия:
Изменено главное окно, открытие
дополнительных вкладок в меню
Дополнительные замечания:
Дополнительных замечаний нет
Основной поток:
А: Функции варианта использования
начинают выполняться с регистрации актера с
заданием его имени и пароля. Система
проверяет пароль на достоверность (в случае,
когда указанный пароль неверен,
активизируется альтернативный поток А).
Вариант использования завершается.
Альтернативный поток:
А: введен неверный пароль; выдача
сообщения ввода неверного пароля; субъекту
предоставляется возможность повторить ввод
или завершить вариант использования.
Вариант использования завершается.
Прецедент Обновление данных
Название:
Обновление данных
Цель:
Обновление данных – изменение данных
учебного заведения, членов организации,
мероприятий
Специальные требования:
Специальные требования не определены
Предусловия:
Для обновления заказа требуются права
36
Постусловия:
Выдача сообщения
Дополнительные замечания:
Дополнительных замечаний нет
Основной поток:
А: Функции варианта использования
начинают выполняться с регистрации актера
с заданием его имени и пароля. Система
проверяет пароль на достоверность(если
пароль неверен, активизируется
альтернативный поток А).
Б: Обновления данных отображает окно с
кнопками «сохранить» или «отмена». Актер
нажимает кнопку «сохранить» (при задании
неверной информации выполняется
альтернативный поток Б) и актер
подтверждает обновление. Вариант
использования завершается.
Альтернативный поток:
А: введен неверный пароль; выдача
сообщения ввода неверного пароля;
субъекту предоставляется возможность
повторить ввод или завершить вариант
использования.
Б: Система сообщает, что данные введены не
верно и предлагает изменить данные и
повторить операцию или завершить вариант
использования. Вариант использования
завершается.
Так как информационная система будет разработана в качестве webприложения, рассмотрим варианты использования системы не только со
стороны пользователя, но и со стороны сервера, как исполнителя всех
процедур по обработке данных и выдачи результатов.
37
Построим диаграмму вариантов использования сервера (рисунок 2.4).
Рисунок 2.4 – Диаграмма вариантов использования
системы со стороны сервера
В таблице 5 представлена текстовая спецификация диаграммы
вариантов использования со стороны сервера.
Таблица 5 – Текстовая спецификация
Прецедент Получить запрос от пользователя
Название:
Получить запрос от пользователя
Цель:
Получения запроса от пользователя на
выполнение той или иной операции
Специальные требования:
Специальные требования не определены
Предусловия:
Предусловия не определены
Постусловия:
Постусловия определены
Дополнительные замечания:
Дополнительных замечаний нет
Основной поток:
А: Функции варианта использования начинают
выполняться с получения запроса от
пользователя (в случае, когда запрос от
38
пользователя не может быть получен, то
выполняется альтернативный поток А).
Вариант использования завершается.
Альтернативный поток:
А: Ошибка соединения с сервером, система
сообщает субъекту о том, что в данный момент
невозможно получить запрос. Вариант
использования завершается.
Прецедент Предоставить запрашиваемую модель
Название:
Предоставить запрашиваемую модель
Цель:
Определить модель, которую необходимо
заполнить пользователю для обработки его
запроса
Специальные требования:
Специальные требования не определены
Предусловия:
Получен запрос от пользователя
Постусловия:
Отображение модели
Дополнительные замечания:
Дополнительных замечаний нет
Основной поток:
А: Функции варианта использования начинают
выполняться с получения запроса от
пользователя (в случае, когда запрос от
пользователя не может быть получен, то
выполняется альтернативный поток А).
Б: Запрашиваемая модель отображается в окне
с кнопками «сохранить» или «отмена» (при
отражении неверной модели выполняется
альтернативный поток Б). Вариант
использования завершается.
Альтернативный поток:
А: Ошибка соединения с сервером, система
сообщает субъекту о том, что в данный момент
невозможно получить запрос.
Б: Не удается предоставить запрашиваемую
39
модель, система сообщает субъекту о том, что
в данный момент невозможно получить
модель.
Вариант использования завершается.
Прецедент Интерпретировать результаты вычислений
Название:
Интерпретировать результаты вычислений
Цель:
Произвести вычисления и интерпретировать их
результаты
Специальные требования:
Специальные требования не определены
Предусловия:
Получение заполненной модели
Постусловия:
Результаты вычислений интерпретированы и
находятся в памяти сервера
Дополнительные замечания:
Дополнительных замечаний нет
Основной поток:
А: Функции варианта использования начинают
выполняться с получения модели от
пользователя (в случае, когда модель от
пользователя не может быть получена, то
выполняется альтернативный поток А).
Б: На основе полученных данных производятся
вычисления (при отражении неверной модели
выполняется альтернативный поток Б).
В: Результаты вычислений интерпретируются
в понятный для пользователя вид (при
невозможности интерпретации результатов
выполняется альтернативный поток В).
Вариант использования завершается.
Альтернативный поток:
А: Не удается предоставить запрашиваемую
модель, система сообщает субъекту о том, что
в данный момент невозможно получить
модель.
40
Б: Не удается произвести вычисления, система
сообщает субъекту о том, что в данный момент
невозможно произвести вычисления.
В: Не удается интерпретировать вычисления,
система сообщает субъекту о том, что в
данный момент невозможно интерпретировать
вычисления. Вариант использования
завершается.
Прецедент Вернуть результаты пользователю
Название:
Вернуть результаты пользователю
Цель:
Вернуть интерпретированные результаты
пользователю
Специальные требования:
Специальные требования не определены
Предусловия:
Результаты вычислений интерпретированы и
находятся в памяти сервера
Постусловия:
Отображение результата
Дополнительные замечания:
Дополнительных замечаний нет
Основной поток:
А: Функции варианта использования начинают
выполняться с проверки наличия
интерпретированных результатов вычислений
(в случае, когда модель от пользователя не
может быть получена, то выполняется
альтернативный поток А).
Б: На основе полученных данных
производится отображение данных в окне
браузера (при отражении неверной модели
выполняется альтернативный поток Б).
Вариант использования завершается.
Альтернативный поток:
А: Не удается найти в памяти
интерпретированные вычисления, система
41
сообщает субъекту о том, что данные не
найдены, ошибка в памяти сервера.
Б: Данные не отображаются в окне браузера,
система сообщает субъекту о том, что
проблемы с браузером и просит обновить
страницу.
Вариант использования завершается.
Таким
образом,
были
определены
основные
актеры
системы,
выявлены варианты использования, построены диаграммы прецедентов, на
основании которых была построена
диаграмма вариантов использования
информационной системы.
2.2 Детальное проектирование
Диаграмма классов (class diagram) на сегодняшний день является
основным
способом
описания
структуры
информационной
системы.
Диаграмма классов служит для отображения классов и их отношения в
логической схеме проектов и позволяет представить архитектуру системы
[29].
Как было сказано в первой главе, объектом называется предмет или
явление, которое имеет четко определенное поведение и которое обладает
состоянием, поведением и индивидуальностью.
Классом является некоторое множество объектов, которые связаны
общностью структуры и поведения.
В языке UML каждому атрибуту класса соответствует отдельная строка
текста, которая состоит из квантора видимости атрибута, имени атрибута, его
кратности, типа значений атрибута.
Квантор видимости
при этом может принимать одно из трех
возможных значений и отображается при помощи соответствующих
специальных символов:
 «+» обозначает атрибут с областью видимости типа общедоступный
42
(public), то есть атрибут доступен или виден из любого другого класса
пакета, в котором определена диаграмма;
 «#» обозначает атрибут с областью видимости типа защищенный
(protected), то есть атрибут недоступен или невиден для всех классов, за
исключением подклассов данного класса;
 «-» обозначает атрибут с областью видимости типа закрытый
(private) , то есть атрибут недоступен или невиден для всех классов без
исключения.
Квантор видимости может быть опущен. В этом случае его отсутствие
означает, что видимость атрибута не указывается [22].
Операции или методы класса записываются в третьей сверху секции
прямоугольника объекта.
Совокупность
операций
характеризует
функциональный
аспект
поведения класса.
Каждой операции класса соответствует отдельная строка, которая
состоит из квантора видимости операции, имени операции.
Помимо этого структуры классов на диаграмме UML соединены тремя
видами отношениями между классами:
 отношениями зависимости, которое применяется в такой ситуации,
когда некоторое изменение одного элемента модели может потребовать
изменения другого зависимого от него элемента модели и изображается
пунктирной линией между соответствующими элементами со стрелкой,
направленной от класса-клиента зависимости к независимому классу или
классу-источнику;
 отношениями
ассоциации,
которое
соответствует
наличию
некоторого отношения между классами. Данное отношение обозначается
сплошной линией, которое может использоваться с кратностью классов.
Кратность отдельного класса при этом обозначается в виде интервала целых
чисел. Интервал записывается рядом с концом ассоциации [23].;
 отношениями обобщения, которое является обычным отношением
43
между более общим элементом (предком) и более частным или специальным
элементом (потомком). Применительно к диаграмме классов данное
отношение описывает иерархическое строение классов и наследование их
свойств и поведения. При этом предполагается, что класс-потомок обладает
всеми свойствами и поведением класса-родителя, а также имеет свои
собственные свойства и поведение, которые отсутствуют у класса- родителя.
Следует отметить, что стрелка указывает на общий класс (класс- родитель
или суперкласс), а ее отсутствие — на специальный класс (класс-потомок
или подкласс) [30].
Для информационной системы «Трубчевская районная общественная
студенческая организация «Факел» определим следующие классы:

«Руководитель» — пользователь, который является руководителем
ТРОСО;

«Ответственный за мероприятие» — пользователи, которые
являются ответственными сотрудниками за мероприятия ТРОСО;
 «Идентификация
и
аутентификация»
—
класс,
являющийся
обобщаемым для всех пользователей системы, так как пользователи должны
быть зарегистрированы;
 «Образовательные учреждения» — класс, который хранит в себе
данные о существующих образовательных учреждениях;
 «Члены ТРОСО «Факел» — класс, который включает в себя все
поля и действия по членам ТРОСО;
 «Мероприятия» — класс, который содержит все данные о
мероприятиях ТРОСО.
Все
классы
с
соответствующими
атрибутами,
операциями,
интерфейсами и отношения между ними ИС ТРОСО «Факел» представлены
на рисунке 2.5.
Рисунок 2.5 — Диаграмма классов
44
45
Для подробного рассмотрения взаимодействия системы и сервера
выделены следующие классы:
 «Провайдер» — класс, содержащий понятие Интернет-соединения.
Так как ИС ТРОСО «Факел» представлена в виде Web-приложения, то при
отсутствие соединения, любое функционирование системы невозможно.

«Пользователь» – класс, отражающий пользователя системы. В
качестве пользователей системы выступают руководитель и ответственный
за мероприятие;

«Интерфейс» – класс, через который пользователь взаимодействует
с системой. Через интерфейс пользователь может узнать описание методов,
ввести исходные данные, авторизоваться, выбрать подходящий метод,
увидеть результаты работы системы и интерпретацию результатов.
 «Сервер» – класс, отвечающий за функционал системы. На сервере
выполняются операции по применению обработки данных согласно
выбранной модели, проверка аутентификации пользователя, отображению
интерфейса пользователя.
 «Механизм интерпретации результатов» – класс для интерпретации
выводимых
системой
результатов,
хранится
на
сервере.
Механизм
интерпретации работает с выводимыми результатами
 «Модель» – класс для предоставления пользователю методик
обработки данных – удаление, добавление, редактирование, просмотр.
 «Браузер» – класс для предоставления пользователю интерфейса.
Данное
взаимодействие
представлено на рисунке 2.6.
системы
с
сервером
и
провайдером
46
Рисунок 2.6 — Диаграмма классов взаимодействия системы с сервером и
провайдером
Диаграмма
взаимодействия
последовательностей
UML,
которые
относится
описывают
к
диаграммам
поведенческие
аспекты
информационной системы, но рассматривает взаимодействие объектов во
времени. Другими словами, диаграмма последовательностей отображает
временные особенности передачи и приема сообщений объектами.
Рассмотрим правила построения диаграммы последовательности:
 текст последовательности действий прецедента наносится в виде
комментария;
 объекты подписываются в формате «объект: класс» и размещаются
по горизонтали;
 время жизни объектов изображается вертикальными пунктирными
линиями, которые выходят из объектов снизу;
 сообщения, отражают взаимодействие объектов, включая и вызов
функций), изображаются горизонтальными стрелками, концы которых
располагаются на линиях жизни. Стрелки при этом направлены от
47
отправителя к адресату и упорядочены по времени при помощи так
называемой линии жизни. Выделяют три вида сообщений:
1. Синхронные
- вызов функции, который вызывает код получает
управление после того, как сообщение будет обработано, изображаются
сплошной линией с закрытой стрелкой.
2. Асинхронные - управление возвращается немедленное после
передачи сообщения, изображаются сплошной линией с открытой стрелкой.
3. Ответ на сообщение - результат вычислений, изображается
штриховой линией с открытой стрелкой.
 интервалы активности объектов отражают периоды, в рамках
которого методы объектов находится в стеке (обычно между получением
фокуса управления и завершением обработки). Иногда интервалы активности
позволяют различать на диаграмме с чем связана активность (какой метод
инициирует передачу сообщений), в остальных случаях их можно опустить,
так как их изображение является довольно трудоемким.
 создание объекта изображается на диаграмме стрелкой, которое
входит в символ объекта, а уничтожение – крестом на линии жизни [31].
Проектирование системы ТРОСО «Факел» в части учета членов
движения с помощью диаграммы последовательности представлено на
рисунке 2.7.
Инициатором данного процесса взаимодействия является руководитель
ТРОСО «Факел». Как видно из диаграммы, после того как подана заявка
студентов, руководитель проверяет ее на корректность введенных данных
путем поиска данных в членах организации.
Далее
организации.
происходит
добавление/изменения
статуса
студента
в
48
Рисунок 2.7 — Диаграмма последовательности действий в части учета
членов движения
Проектирование системы ТРОСО «Факел» в части обработки данных
сервером
и
браузером
с
помощью
диаграммы
последовательности
представлено на рисунке 2.8.
Рисунок 2.8 — Диаграмма последовательности действий в части
взаимодействия системы и сервера
49
2.3 Расчет временной продолжительности проекта
Оценка
предстоящих
затрат
на
разработку
и
внедрение
ИС
осуществляется в пределах периода его продолжительности. Поэтому
необходимо правильно выявить все возможные работы по созданию
информационной системы и рассчитать их длительность.
Центральным процессом планирования является расчет расписания
работ проекта, то есть процесс определения даты начала и окончания каждой
работы проекта.
В соответствии с ГОСТ Р ИСО/МЭК 12207-99 составлен перечень
работ, необходимых для создания автоматизированной системы ТРСОО
«Факел»:
 Подготовка к разработке;
 Анализ требований к системе;
 Проектирование системной архитектуры;
 Проектирование программной архитектуры;
 Программирование и тестирование программных средств;
 Сборка системы;
 Квалифицированные испытания системы;
 Ввод в действие ПО.
Декомпозиция данных работ представлена на дереве целей проекта,
изображено на рисунке 2.9.
50
Рисунок 2.9 – Дерево целей проекта
Для отображения работ, их взаимосвязи и последовательности, а также
для расчета общей продолжительности проекта на необходимо построить
календарный график.
Календарный график будем строить при помощи Диаграммы Ганта,
которая является популярным типом столбчатых диаграмм, и который
используется для иллюстрации плана, графика работ по какому-либо проекту
[3]. Диаграмма Ганта является одним из наиболее популярных методов
планирования проектов (рисунок 2.10).
Диаграмма Ганта отображает следующие параметры проекта:
 структуру работ, полученную на основе сетевого графика;
 состав используемых ресурсов и их распределение между работами;
 календарные даты, к которым привязываются моменты начала и
завершения работ [25].
51
Рисунок 2.10 – Диаграмма Ганта
Из диаграммы Ганта видно, что длительность проекта по разработке и
внедрении
ИС
«Трубчевской
районной
общественной
студенческой
организации «Факел» составит 88 дней.
2.4 Оценка себестоимости разработки и внедрения информационной системы
ТРОСО «Факел»
Для того, чтобы реализовать проектируемую информационную систему
ТРОСО «Факел», необходима команда по разработке проекта:
1. Менеджер проекта – руководитель проекта со стороны исполнителя.
Он отвечает за ведение переговоров с заказчиком, уточнение требований,
формирование
команды
разработки,
контроль
процесса
исполнения,
планирование спринтов. Менеджер проекта ответственен за сдачу проекта в
назначенный срок;
2. Проектировщик
–
человек,
технического проекта новой ИС;
отвечающий
за
проектирование
52
3. Web-разработчик – программист, отвечающий за написание кода и
реализацию
отображения
страницы
приложения
в
соответствии
с
нарисованным дизайном и требованиями заказчика;
4. Тестировщик – специалист, который занимается тестированием
программного обеспечения. В его обязанность входит поиск вероятных
ошибок и сбоев в функционировании программы;
5. Специалист по внедрению ИС – специалист, который занимается
контролем и постановкой задач в рамках внедрении новой ИС.
Заработная плата каждого специалиста, взятая средним показателем по
Орловской области, указана в таблице 6.
Таблица 6 – Заработные платы специалистов проекта
Специалист
Заработная
Заработная плата (руб/ч)
плата (руб/мес)
Менеджер проекта
30000
178,57
Web-программист
40000
238,10
Проектировщик
28000
166,67
Тестировщик
23000
136,90
Специалист по внедрению ПО
25000
148,81
Не все специалисты будут работать на протяжении длительности всего
проекта. Поэтому необходимо составить матрицу ответственности, которая
установит степень ответственность каждого участника проектной команды за
выполнение отдельных этапов и задач проекта.
При
составлении
матрицы
ответственности
проекта
будет
использоваться методика RACI, которая на сегодняшний день является
самым удобным и наглядным средством планирования ответственности
членов проектной команды при выполнении задач на каждом из этапов
проекта.
Термин RACI (или ARCI) является аббревиатурой:
53
 Ответственный (Accountable) – сотрудник, который полностью
отвечает за исполнение этапа/задачи, и который вправе принимать решения
по способу реализации.
 Исполнитель (Responsible) – сотрудник, который исполняет задачу,
не несет ответственность за выбор способа её решения, но отвечает за
качество и сроки реализации.
 Консультант (Consult before doing) – сотрудник, который оказывает
консультации в ходе решения задач проекта, контролирует качество
реализации.
 Наблюдатель (Inform after doing) – сотрудник, который может
оказывать консультации в ходе решения задач проекта, не несет
ответственности.
Матрица ответственности специалистов необходимых для создания
информационной системы ТРОСО «Факел» представлена в таблице 7.
Подготовка к разработке
Заключение контракта
0-1
ИО
Сбор команды
1-4
ИО
4-5
ИО
Выбор стандартов,
методов, инструментариев
и языков
программирования для
разработки ПО
Анализ требований к
системе
К
по внедрению
Специалист
Тестировщик
ик
Проектировщ
работ
Web-
Сроки
Менеджер
Работы
программист
Таблица 7 – Матрица ответственности
54
Проведение обследования
объекта автоматизации
5-12
К
ИО
12-14
К
ИО
14-17
О
И
17-25
Н
ИО
25-32
Н
ИО
интерфейса
32-42
Н
ИО
Проектирование БД
42-43
Н
ИО
43-44
Н
ИО
44-47
Н
ИО
учреждениями
47-52
Н
ИО
Разработка модуля
52-54
Н
ИО
Выявление технических
требований к системе
Составление и
утверждение ТЗ
Проектирование
системной архитектуры
Проектирование
программной
архитектуры
Проектирование модулей
Проектирование
Программирование и
тестирование
программных средств
Разработка модуля
авторизации и
аутентификации
пользователей в системе
Разработка модуля
управления членами
движения
Разработка модуля
управления
образовательными
55
управления
мероприятиями
Разработка модуля поиска
по БД
54-57
Н
ИО
57-63
Н
ПО
63-67
Н
ИО
Устранение ошибок
67-75
Н
ИО
75-80
Н
80-85
Н
заказчика
85-86
О
И
Обучение персонала
86-87
О
И
Сдача ПО
87-88
О
И
Тестирование каждого
модуля
ИО
Сборка системы
Сборка системы и отладка
Квалификационные
испытания системы
ИО
Ввод в действие ПО
Создание документации
пользователя
ИО
Установка и отладка ПО у
Рассчитаем заработную плату вышеописанным специалистам при
создании ИС с учетом количества отработанных рабочих дней и почасовой
заработной платы участников процесса разработки ИС ТРОСО «Факел».
Показатели отобразим в таблице 8.
Таблица 8 – Затраты на заработную плату по месяцам
2 месяц
(24-46 день)
3 месяц
(47-69 день)
4 месяц
(70-92 день)
внедрению
Специалист по
Тестировщик
программист
34666,8
30381,12
0
0
0
65047,92
26952,52
0
714,28
26238,24
0
53905,04
28642,88
8285,76
14047,72
6309,4
0
57285,76
8333,4
6309,4
2500
56380,96
28190,48 11047,68
Итого
Web-
(1-23 день)
Менеджер
1 месяц
Проектировщик
56
Кроме затрат на заработную плату специалистам проекта и отчислений
во все фонды, в проекте имеются и другие затраты, которые представлены в
таблице 9. Аренда помещения при этом составит 20000 рублей в месяц, но на
проект переносится только 10% затрат. Затраты на коммунальные платежи,
интернет услуги и услуги клининговой компании переносятся только на 50%.
Таблица 9 – Расчет себестоимости ПО
Всего
Показатели
(руб.)/Месяц проекта
Затраты на з/п
Отчисления в ПФРФ
(22%)
Отчисления в
ФФОМС (5,1%)
Отчисления в ФФС
затрат,
1
2
3
4
руб.
65047,9
53905,0
57285,8
56381
232620
14310,5
11859,1
12602,9
12403,8
51176,3
3317,4
2749,2
2921,6
2875,4
11863,6
1886,4
1563,3
1661,3
1635,1
6746
57
(2,9%)
Аренда (10%)
Коммунальные
платежи (50%)
Интернет (50%)
2000
2044
2089
2135
8268
2000
2044
2089
2135
8268
1500
1533
1566,7
1601,2
6200,9
1000
1022
1044,5
1067,5
4133,9
91062,3
76719,6
81260,6
80233,8
329276,2
Услуги
клиннинговой
компании (50%)
Всего затрат, руб.
Таким образом, себестоимость проекта по созданию информационной
системы ТРОСО «Факел» для компании-разработчика составит 329276,2
рублей.
ЗАКЛЮЧЕНИЕ
Проблема автоматизации бизнес-процессов вне зависимости от сферы
деятельности становится в последнее время наиболее актуальной. Все
больше компаний достигает необходимого уровня развития бизнеса, и
приходит к необходимости формализации деятельности и внедрения средств
для их автоматизации.
В связи с этим целью выпускной квалификационной работы было
проектирования
соответствующей
информационной
системы,
которая
позволила бы автоматизировать работу ТРОСО «Факел». В процессе
достижения поставленной цели были решены множественные задачи.
В результате проведенной работы были использованы материалы
отечественных и зарубежных специалистов по вопросам автоматизации
деятельности, проектирования информационных систем, моделирования
бизнес-процессов.
Была
не
только
проанализирована
информация,
полученная из учебных пособий, журналов, но и использована информация,
предоставленная в общем доступе разработчиками программных средств.
При анализе предметной области были выделены основные бизнеспроцессы, для
автоматизации которых предназначена проектируемая
информационная система. В процессе изучения различных информационных
источников были выявлены основные этапы и множественные теоретические
аспекты
процесса
проектирования,
автоматизации.
имеющиеся
Были
документы,
рассмотрены
регламентирующие
принципы
создание
автоматизированной информационной системы.
В результате был проведен анализ существующих методик
моделирования, определены их достоинства и недостатки, в результате чего
был сделан выбор в сторону методологии BPMN. На основе данной
методологии была построена не только диаграмма взаимодействия, которая
показывает обмен сообщениями между участниками ИС – руководитель
ТРОСО «Факел» и ответственный сотрудник за мероприятия, но диаграмма
59
оркестровки с точки зрения руководителя и с точки зрения ответственного
сотрудника за мероприятия.
Во второй главе работы для построения проектной модели бизнеспроцессов были выделены главные участники - актеры. Для каждой
выделенной роли был определен набор функциональных возможностей, в
результате чего были построены диаграмма прецедентов, на основе которых
были построены проектные модели взаимодействия между участниками.
Также были определены классы, которые участвуют в бизнес-процессах
деятельности
ТРОСО
мероприятие»,
«Факел»:
«Идентификация
«Руководитель»,
и
«Ответственный
за
аутентификация»,«Образовательные
учреждения», «Члены ТРОСО «Факел»,«Мероприятия».
Для однозначности понимания выделенных бизнес-процессов был
разобран на диаграмме последовательности этап добавление/изменения
нового члена ТРОСО.
На основе международных стандартах были описаны основные этапы
создания автоматизированной системы, построено дерево целей проекта, на
основе которого реализована Диаграмма Ганта
и приведен расчет
себестоимости проекта по созданию информационной системы ТРОСО
«Факел» для компании-разработчика, которая составила 329276,2 рублей.
Результаты
проведенной
работы
помогут
в
разработке
информационной системы для автоматизации деятельности, как для ТРОСО
«Факел», так и для любых организаций подобной сферы деятельности.
60
СПИСОК ЛИТЕРАТУРЫ
1. Алиев, Т.И. Основы моделирования дискретных систем: Учебное
пособие/ Т.И. Алиев – Спб.: СПбГУ ИТМО. – 2009. – 363 с.
2. Акперов, И.Г. Информационные технологии
в менеджменте:
Учебник / И.Г. Акперов, А.В. Сметанин, И.А. Коноплева. − М.: НИЦ
ИНФРА−М, 2013 − 400 c.
3. Балашов, А.И. Управление проектами: Учебник и практикум для
СПО / А.И. Балашов, Е.М. Рогова, М.В. Тихонова и др. - Люберцы: Юрайт,
2016. - 383 c.
4. Белов, В.В. Проектирование информационных систем: учеб. для
вузов / В. В. Белов, В. И. Чистякова. – М.: Академия, 2015. – 352 с.
5. Гвоздева,
В.А.
Основы
построения
автоматизированных
информационных систем / В.А. Гвоздева, И.Ю. Лаврентьева. – М.: Форум,
Инфра-М, 2016. – 320 c.
6. Гома, Х. UML. Проектирование систем реального времени,
параллельных и распределенных приложений / Х. Гома. / пер. с англ. – М.:
ДМК Пресс, 2016. – 700 с.
7. Грэди, Б. [GradyBooch] Объектно-ориентированный анализ и
проектирование
с
примерами
приложений
[Object-
OrientedAnalysisandDesignwithApplication] / Б. Грэди [и д.р.] / пер. с англ.
Д.А. Клюшин.– М.: Вильямс, 2010. – 720 с.
8. Дастин, Э. Тестирование программного обеспечения. Внедрение,
управление и автоматизация / Э. Дастин, Д. Рэшка, Д. Пол. /пер. с англ. М.
Павлов. – М.: Лори, 2013. – 567 c.
9. Дубейковский, В.И. Эффективное моделирование с Allfusion Process
Modeler 4.1.4 и Allfusion PM [Текст] / В.И. Дубейковский. – СПБ.:
«ДИАЛОГ-МИФИ», 2007. – 384 с.
10. Ездаков, А.Л. Функциональное и логическое программирование:
Учебное пособие / А.Л. Ездаков. - М.: Бином, 2016. - 119 c.
61
11. Елиферов, В.Г. Бизнес-процессы: Регламентация и управление /
В.Г. Елиферов. – М.: НИЦ ИНФРА-М, 2013. – 319 c.
12. Емельянова,
Н.З.
Проектирование
информационных
систем:
Учебное пособие / Н.З. Емельянова, Т.Л. Партыка, И.И. Попов. - М.: Форум,
2013. - 432 c.
13. Заботина, Н.Н. Проектирование информационных систем: Учебное
пособие / Н.Н. Заботина. - М.: НИЦ ИНФРА-М, 2013. - 331 c.
14. Исаев, Г.Н. Проектирование информационных систем: Учебное
пособие / Г.Н. Исаев. - М.: Омега-Л, 2013. - 424 c.
15. Йордан, Э. Объектно-ориентированный анализ и проектирование
систем / Э. Йордан. – М.: Лори, 2014. – 264 c.
16. Коноплева, И.А. Информационные технологии : учеб. пособие для
студ. вузов / И. А. Коноплева, О. А. Хохлова, А. Д. Денисов. – М.: Проспект,
2016. – 327 с.
17. Ларман, К. Применение UML 2.0 и шаблонов проектирования.
Введение
в
объектно-ориентированный
анализ,
проектирование
и
итеративную разработку / К. Ларман – Вильямс, 2013. – 736 с.
18. Миков, А.И. Информационные процессы и нормативные системы в
IT: Математические модели. Проблемы проектирования. Новые подходы /
А.И. Миков. - М.: КД Либроком, 2013. - 256 c.
19. Назаров, С.В. Архитектура и проектирование программных систем:
Монография / С.В. Назаров. - М.: НИЦ ИНФРА-М, 2013. - 351 c.
20. Орлов, С.А. Теория и практика программирования: учебник для
вузов. Стандарт 3-го поколения / С.А. Орлов. – СПб.: Питер, 2014. – 688с.
21. Палюх,
Б.В. Применение
современных
информационных
технологий для разработки информационных систем: Учеб. пособие [Текст] /
Б.В. Палюх, В.В. Алексеев, А.Ю. Клюшин, С.В. Котлинский. – 1-е изд. –
Тверь: ТГТУ, 2010. – 176 с.
22. Пантелеев, В.Н. Основы автоматизации производства: учебник для
учреждений начального профессионального образования / В.Н. Пантелеев,
В.М. Прошин. – М.: ИЦ Академия, 2013. – 208 c.
62
23. Репин, В.В. Процессный подход к управлению. Моделирование
бизнес-процессов / В.В. Репин, В.Г. Елиферов. – М.: Манн, Иванов и Фербер,
2012.–544с.
24. Реутов, А.П. Автоматизированные информационные системы:
методы построения и исследования / А.П. Реутов, М.В. Черняков, С.Н.
Замуруев. – М.: Радиотехника, 2010. – 328 c.
25. Ройс, У. Управление проектами по созданию программного
обеспечения / У. Ройс. - М.: Лори, 2014. - 424 c.
26. Розенков,
Д.А.
Классический
менеджмент:
организационные
структуры управления: учеб. пособие /Д.А. Розенков, Р.Г. Леонтьев. –
Хабаровск: Издательство ДВГУПС, 2012. – 192 с.
27. Соловьев,
И.В.
Проектирование
информационных
систем.
Фундаментальный курс: Учебное пособие для высшей школы / И.В.
Соловьев, А.А. Майоров; Под ред. В.П. Савиных. - М.: Акад. Проект, 2009. 398 c.
28. Федоров,
И.Г.
Моделирование
бизнес-процессов
в
нотации
BPMN 2.0: учеб. пособие / И.Г. Федоров. – М: Московский государственный
университет экономики, статистики и информатики, 2013. – 263 с.
29. Федоров, Н.В. Проектирование информационных систем на основе
современных CASE-технологий / Н.В. Федоров. - М.: МГИУ, 2008. - 280 c.
30. Хетагуров, Я.А. Проектирование автоматизированных систем
обработки информации и управления (АСОИУ) / Я.А. Хетагуров. - М.:
БИНОМ. Лаборатория знаний, 2015. - 240 c.
31. Чукарин, А.В. Бизнес-процессы и информационные технологии в
управлении современной инфокоммуникационной компанией / А.В. Чукарин.
– М.: Альпина Паблишер, 2016. – 512 c.
63
1/--страниц
Пожаловаться на содержимое документа