Моделирование бизнес процессов кафедры в университете

Моделирование бизнес-процессов на основе объектно-ориентированной методологии
Уланов А. А., Аветисян Г. Г.
Уланов Алексей Александрович – кандидат технических наук, кафедра – информационные технологии транспорта, факультет бизнес информатики.
Аветисян Григор Гарникович – студент, кафедра информационные технологии транспорта, факультет бизнес информатики, Сибирский государственный университет путей сообщения.
АННОТАЦИЯ
В дипломном проекте реализовано моделирование бизнес-процессов кафедры вуза, на основе объектно-ориентированной методологии
ANNOTATION
In the diploma project the modeling of business processes of the department of the university was realized, on the basis of object-oriented methodology
Ключевые слова: моделирование, бизнес-процессы, кафедра, вуз, преподаватели, студент.
В различных подразделениях Сибирского государственного университета путей сообщения используются множество программных продуктов собственной разработки, учитывающие специфику и особенности работы.
Целью дипломного проекта стало создание программного продукта, позволяющего автоматизировать и оптимизировать функции специалиста, составляющего учебные планы и рассчитывающего учебную нагрузку, а также обеспечить возможность подключения к локальной сетевой базе, реализованной в InterBase.
Программный продукт должен позволить:
своевременное, оперативное и правильное оформление документации;
автоматизировать процесс расчета учебной нагрузки;
уменьшить временные затраты на оформление документов;
более полный контроль и организацию при расчете учебной нагрузки и составлении календарных планов.
Прежде чем приступить к созданию программного продукта предполагается построить модель программы по средствам технологии UML для наглядного представления внутренней структуры, работы продукта и внутреннего взаимодействия его составных частей.
1. Общие положения
Кафедра является основным учебно-научным структурным подразделением университета, обеспечивающим проведение учебной, научной и воспитательной работы.
Кафедра непосредственно подчиняется декану факультета. В состав кафедры входят профессора, профессора-консультанты, доценты, старшие преподаватели, преподаватели, преподаватели-стажеры, аспиранты, учебно-вспомогательный персонал, а также сотрудники созданных при кафедре научных подразделений.
Кафедра может иметь учебные лаборатории, кабинеты и другие подразделения, обеспечивающие учебный процесс.
Кафедра работает по годовым и пятилетним планам, охватывающим все виды деятельности, соответствующие ее функциям в вузе. Структуру кафедры и ее штаты утверждает ректор СГУПС.
Кафедра организуется и ликвидируется приказом ректора на основании решения Ученого совета университета. Основаниями для создания кафедры служат учебные потребности вуза.
Кафедра организуется в составе не менее пяти преподавателей, из которых не менее двух должны иметь ученые степени или звания, а на кафедрах физического воспитания, иностранных языков, русского языка, графики — не менее одного преподавателя, имеющего ученую степень или звание.
1.1.2 Основные функции кафедры
К основным функциям кафедры относятся следующие:
— проведение на высоком научном и методическом уровнях всех видов учебных занятий, экзаменов и зачетов, предусмотренных учебными планами и программами по дисциплинам кафедры (Рисунок А.2);
— проведение воспитательной работы среди студентов;
— разработка рабочих программ дисциплин на основе Государственных образовательных стандартов, утвержденных квалификационных характеристик специалистов, учебных планов специальностей и типовых программ с отражением новейших достижений науки, техники и культуры, перспектив их развития, отраслевых и региональных условий и особенностей подготовки специалистов, внутри — и междисциплинарных логических связей, роли фундаментальных наук в теоретической и практической подготовке специалистов;
— написание учебников, учебных и методических пособий, указаний, других руководств и наглядных пособий, необходимых для проведения всех видов учебных занятий, а также составление заключений по поручению декана факультета на рабочие программы, учебники, учебные пособия и другие учебно-методические издания, подготовленные преподавателями других вузов и кафедр;
— выполнение научных исследований по фундаментальным и прикладным вопросам, соответствующим профилю кафедры, проблемам педагогики высшей школы в тесной связи с задачами повышения качества подготовки специалистов. Обсуждение законченных научно-исследовательских, научно-методических и опытно-конструкторских работ, представление их к опубликованию, участие в доведении законченных работ до практического применения (Рисунок А.3);
— изучение, обобщение и распространение опыта лучших преподавателей; оказание помощи начинающим преподавателям в овладении педагогическим мастерством; разработка и осуществление мероприятий по использованию современных технических средств и новых технологий обучения;
— подготовка научно-педагогических кадров через аспирантуру, соискательство и другими способами, рассмотрение диссертаций, представляемых к защите членами кафедры или, по поручению декана факультета, другими соискателями;
— подбор кадров, работа с резервом на замещение вакантных должностей;
— установление связей и развитие сотрудничества с предприятиями, учреждениями и организациями транспорта, строительства и других отраслей в целях наиболее полного удовлетворения их потребностей в специалистах с высшим образованием. Проведение работы по заключению договоров на обучение студентов по заявкам предприятий, в том числе на компенсационной основе;
— повышение квалификации специалистов, занятых в различных отраслях народного хозяйства;
— установление и поддержание деловых связей с родственными кафедрами города, России и зарубежных стран.
1.1.3 Выпускающая кафедра
Статус выпускающей по конкретной специальности кафедра приобретает на основании решения Ученого совета, утверждаемого приказом ректора.
Количество выпускающих кафедр, как правило, не превышает числа специальностей или специализаций. Возможно создание выпускающей кафедры по нескольким близким специальностям одного направления. В этом случае на кафедре создают соответствующие циклы и назначают их руководителей.
Выпускающая кафедра ведет занятия по специальностям, а также некоторым родственным общепрофессиональным и естественнонаучным дисциплинам, перечень которых утверждает проректор по учебной работе по представлению декана факультета и учебного отдела.
При открытии новой специальности выпускающую кафедру создают не позднее, чем студенты этой специальности будут переведены на третий курс.
Выпускающую кафедру комплектуют, как правило, из специалистов, имеющих производственный опыт работы по специальности.
Выпускающая кафедра может иметь учебно-производственный центр (филиал) на предприятии или в организации и организует часть учебного процесса в производственных условиях (выездные занятия, производственные практики и другое).
Выпускающая кафедра может по договоренности передавать часть своих работ и обязанностей другим кафедрам, сохраняя за собой необходимый контроль. Например, она может часть контингента дипломников передать другой кафедре при сохранении за собой прав на утверждение тематики и подбор руководителей дипломного проектирования, утверждение заданий на выполнение и допуск проектов к защите.
В связи с расширенным кругом обязанностей преподавателям выпускающей кафедры утверждается уменьшенный на 10…20 процентов объем учебной работы относительно среднего по вузу для каждой категории преподавателей.
На выпускающую кафедру дополнительно возложены следующие функции:
1) Разработка учебных планов специальностей и специализаций.
2) Согласование рабочих программ всех дисциплин учебного плана специальности.
3) Организация и руководство производственными и преддипломными практиками и дипломным проектированием.
4) Участие в работе по заключению договоров на подготовку специалистов и трудоустройстве выпускников.
5) Участие в подборе состава Государственной аттестационной комиссии.
6) Разработка тестовых заданий и проведение итогового междисциплинарного экзамена по специальности.
7) Профориентационная работа при организации нового набора.
1.1.4 Руководство кафедрой
Руководит кафедрой ее заведующий, избираемый Ученым советом СГУПС на 5 лет. По окончании этого срока Ученый совет вуза или факультета заслушивает отчет заведующего о работе кафедры. После этого объявляется конкурс на замещение вакантной должности заведующего кафедрой. Возраст заведующего кафедрой не должен превышать 65 лет. В соответствии с решением Ученого совета работа в должности заведующего может быть в отдельных случаях разрешена ректором СГУПС до 70 лет.
Заведующий кафедрой относится к администрации вуза. В его обязанности входит руководство работой коллектива кафедры по выполнению возложенных на нее обязанностей. А также он участвует в работе всех подразделений высшего учебного заведения, где обсуждаются и решаются вопросы деятельности кафедры; проводит заседания кафедры; утверждает планы работы кафедры, индивидуальные планы работы преподавателей и другие документы на уровне кафедры; распределяет учебную нагрузку и функциональные обязанности между работниками кафедры; представляет руководству СГУПС предложения по приему на работу, увольнению и перемещению работников кафедры, их моральному иматериальному поощрению, а также о мерах дисциплинарного воздействия: требует от структурных подразделений и служб вуза принятия мер, обеспечивающих необходимые условия для проведения учебно-воспитательного и научно-исследовательского процессов.
Заведующий кафедрой несет личную ответственность за деятельность кафедры. Индивидуальный план заведующего кафедрой утверждает декан факультета. На кафедрах с большим количеством дисциплин и годовой учебной нагрузкой более 10 тыс. часов приказом ректора может быть назначен заместитель заведующего по учебной и методической работе.
Обязанности заведующего кафедрой в области охраны труда и техники безопасности:
— осуществляет непосредственное руководство и постоянный контроль за обеспечением безопасных и безвредных условий труда;
— отвечает за организацию и проведение учебного процесса в соответствии с действующим трудовым законодательством, нормами и правилами по ТБ;
— обеспечивает составление планов и графиков испытаний, проведения планово-предупредительных ремонтов и осмотров приборов, оборудования и инженерно-технических коммуникаций, контроль за их реализацией;
— обеспечивает проверку знаний и выполнение сотрудниками и студентами правил и инструкций по ТБ;
— обеспечивает составление санитарно-технических паспортов аудиторий и лабораторий, закрепленных за кафедрой.
Для эффективного выполнения заведующим кафедрой своих обязанностей ему создаются необходимые условия, а также предоставляются полномочия: издавать распоряжения, давать обязательные указания работникам кафедр в пределах их должностных обязанностей, проверять и оценивать работу сотрудников кафедры, объявлять благодарность работникам кафедры, объявлять замечания работникам кафедры за нарушения трудовой дисциплины.
Обсуждение хода и итогов выполнения планов работы кафедры, индивидуальных планов работы преподавателей и других вопросов деятельности кафедры проводится на заседаниях кафедры под председательством заведующего, в которых принимает участие профессорско-преподавательский состав кафедры. На заседание могут быть приглашены другие работники кафедры и других кафедр, вузов, организаций.
Заседание кафедры является совещательным мероприятием, однако по ряду вопросов решения, принимаемые голосованием на заседании не могут быть заменены распоряжениями заведующего кафедрой, а именно:
— отчеты преподавателей о выполнении индивидуальных планов;
— утверждение годовых и пятилетних планов работы кафедры и отчетов об их выполнении;
— представления (рекомендации) к участию в конкурсах на замещение вакантных должностей;
— включение в план издания СГУПС и представление к изданию учебников, учебных пособий и методических указаний, подготовленных сотрудниками кафедры или работниками других организаций.
Замещение должностей профессорско-преподавательского состава и научного персонала кафедры производится в форме конкурсного отбора с последующим заключением контракта.
Кафедра ведет документацию:
— годовые планы и отчеты о работе кафедры;
— протоколы заседаний кафедры;
-учебно-методические комплекты всех ведомых дисциплин, содержащие типовые и рабочие программы, календарные планы занятий, методические указания по проведению всех видов занятий и всех видов самостоятельной работы студентов, образцы выполненных студентами домашних заданий;
— другую документацию, перечень которой определяется инструкцией по делопроизводству высшего учебного заведения.
2. Унифицированный язык визуального моделирования Unified Modeling Language (UML)
UML представляет собой объектно-ориентированный язык моделирования, обладающий следующими основными характеристиками:
является языком визуального моделирования, который обеспечивает разработку репрезентативных моделей для организации взаимодействия заказчика и разработчика ИС, различных групп разработчиков ИС;
содержит механизмы расширения и специализации базовых концепций языка.
UML — это стандартная нотация визуального моделирования программных систем, принятая консорциумом Object Managing Group (OMG) осенью 1997 г., и на сегодняшний день она поддерживается многими объектно-ориентированными CASE-продуктами.
UML включает внутренний набор средств моделирования (модулей) («ядро»), которые сейчас приняты во многих методах и средствах моделирования. Эти концепции необходимы в большинстве прикладных задач, хотя не каждая концепция необходима в каждой части каждого приложения. Пользователям языка предоставлены возможности:
строить модели на основе средств ядра, без использования механизмов расширения для большинства типовых приложений;
добавлять при необходимости новые элементы и условные обозначения, если они не входят в ядро, или специализировать компоненты, систему условных обозначений (нотацию) и ограничения для конкретных предметных областей.
В рамках языка UML все представления о модели сложной системы фиксируются в виде специальных графических конструкций, получивших название диаграмм.
Диаграмма (diagram) — графическое представление совокупности элементов модели в форме связного графа, вершинам и ребрам (дугам) которого приписывается определенная семантика. Нотация канонических диаграмм — основное средство разработки моделей на языке UML.
В нотации языка UML определены следующие виды канонических диаграмм:
вариантов использования (use case diagram);
классов (class diagram);
кооперации (collaboration diagram);
последовательности (sequence diagram);
состояний (statechart diagram);
деятельности (activity diagram);
компонентов (component diagram);
развертывания (deployment diagram).
Перечень этих диаграмм и их названия являются каноническими в том смысле, что представляют собой неотъемлемую часть графической нотации языка UML. Более того, процесс ООАП (объектно-ориентированного анализа и проектирования) неразрывно связан с процессом построения этих диаграмм. При этом совокупность построенных таким образом диаграмм является самодостаточной в том смысле, что в них содержится вся информация, которая необходима для реализации проекта сложной системы.
Каждая из этих диаграмм детализирует и конкретизирует различные представления о модели сложной системы в терминах языка UML. При этом диаграмма вариантов использования представляет собой наиболее общую концептуальную модель сложной системы, которая является исходной для построения всех остальных диаграмм.
Для диаграмм языка UML существуют три типа визуальных графических обозначений, которые важны с точки зрения заключенной в них информации:
Геометрические фигуры на плоскости, играющие роль вершин графов соответствующих диаграмм. При этом сами геометрические фигуры выступают в роли графических примитивов языка UML, а форма этих фигур (прямоугольник, эллипс) должна строго соответствовать изображению отдельных элементов языка UML (класс, вариант использования, состояние, деятельность). Графические примитивы языка UML имеют фиксированную семантику, переопределять которую пользователям не допускается. Графические примитивы должны иметь собственные имена, а, возможно, и другой текст, который содержится внутри границ соответствующих геометрических фигур или, как исключение, вблизи этих фигур.
Графические взаимосвязи, которые представляются различными линиями на плоскости. Взаимосвязи в языке UML обобщают понятие дуг и ребер из теории графов, но имеют менее формальный характер и более развитую семантику.
Специальные графические символы, изображаемые вблизи от тех или иных визуальных элементов диаграмм и имеющие характер дополнительной спецификации (украшений).
Все диаграммы в языке UML изображаются с использованием фигур на плоскости. Отдельные элементы — с помощью геометрических фигур, которые могут иметь различную высоту и ширину с целью размещения внутри них других конструкций языка UML. Наиболее часто внутри таких символов помещаются строки текста, которые уточняют семантику или фиксируют отдельные свойства соответствующих элементов языка UML. Информация, содержащаяся внутри фигур, имеет значение для конкретной модели проектируемой системы, поскольку регламентирует реализацию соответствующих элементов в программном коде.
Диаграмма вариантов использования (use case diagram) — диаграмма, на которой изображаются отношения между актерами и вариантами использования.
Диаграмма вариантов использования — это исходное концептуальное представление или концептуальная модель системы в процессе ее проектирования и разработки. Создание диаграммы вариантов использования имеет следующие цели:
Определить общие границы и контекст моделируемой предметной области на начальных этапах проектирования системы.
Сформулировать общие требования к функциональному поведению проектируемой системы.
Разработать исходную концептуальную модель системы для ее последующей детализации в форме логических и физических моделей.
Подготовить исходную документацию для взаимодействия разработчиков системы с ее заказчиками и пользователями.
Назначение данной диаграммы состоит в следующем: проектируемая программная система представляется в форме так называемых вариантов использования, с которыми взаимодействуют внешние сущности или актеры. При этом актером или действующим лицом называется любой объект, субъект или система, взаимодействующая с моделируемой бизнес-системой извне. Это может быть человек, техническое устройство, программа или любая другая система, которая служит источником воздействия на моделируемую систему так, как определит разработчик. Вариант использования служит для описания сервисов, которые система предоставляет актеру. Другими словами каждый вариант использования определяет набор действий, совершаемый системой при диалоге с актером. При этом ничего не говорится о том, каким образом будет реализовано взаимодействие актеров с системой и собственно выполнение вариантов использования.
Диаграмма классов (class diagram) — диаграмма языка UML, на которой представлена совокупность декларативных или статических элементов модели, таких как классы с атрибутами и операциями, а также связывающие их отношения.
Диаграмма классов предназначена для представления статической структуры модели системы в терминологии классов объектно-ориентированного программирования. При этом диаграмма классов может содержать интерфейсы, пакеты, отношения и даже отдельные экземпляры классификаторов, такие как объекты и связи. Когда говорят о данной диаграмме, имеют в виду статическую структурную модель проектируемой системы, то есть графическое представление таких структурных взаимосвязей логической модели системы, которые не зависят от времени.
Диаграмма кооперации предназначена для описания поведения системы на уровне отдельных объектов, которые обмениваются между собой сообщениями, чтобы достичь нужной цели или реализовать некоторый вариант использования. С точки зрения аналитика или архитектора системы в проекте важно представить структурные связи отдельных объектов между собой. Такое представление структуры модели как совокупности взаимодействующих объектов и обеспечивает диаграмма кооперации.
Кооперация (collaboration) — спецификация множества объектов отдельных классов, совместно взаимодействующих с целью реализации отдельных вариантов использования в общем контексте моделируемой системы.
Понятие кооперации – одно из фундаментальных в языке UML. Цель самой кооперации состоит в том, чтобы специфицировать особенности реализации отдельных вариантов использования или наиболее значимых операций в системе. Кооперация определяет структуру поведения системы в терминах взаимодействия участников этой кооперации.
Диаграмма последовательности (sequence diagram) — диаграмма, на которой показаны взаимодействия объектов, упорядоченные по времени их проявления.
Особенности взаимодействия элементов моделируемой системы могут быть представлены на диаграммах кооперации и последовательности. Диаграммы кооперации используются для спецификации динамики поведения систем, хотя время в явном виде в них отсутствует. Однако временной аспект поведения может иметь существенное значение при моделировании синхронных процессов, описывающих взаимодействие объектов. Именно для этой цели в языке UML используются диаграммы последовательности, которые и станут предметом изучения в настоящей лекции.
На диаграмме последовательности неявно присутствует ось времени, что позволяет визуализировать временные отношения между передаваемыми сообщениями. С помощью диаграммы последовательности можно представить взаимодействие элементов модели как своеобразный временной график «жизни» всей совокупности объектов, связанных между собой для реализации варианта использования программной системы, достижения бизнес-цели или выполнения какой-либо задачи.
Диаграмма состояний (statechart diagram) — диаграмма, которая представляет конечный автомат.
Главное назначение диаграммы состояний — описать возможные последовательности состояний и переходов, которые в совокупности характеризуют поведение моделируемой системы в течение всего ее жизненного цикла. Диаграмма состояний представляет динамическое поведение сущностей, на основе спецификации их реакции на восприятие некоторых конкретных событий. Системы, которые реагируют на внешние действия от других систем или от пользователей, иногда называют реактивными. Если такие действия инициируются в произвольные случайные моменты времени, то говорят об асинхронном поведении модели.
Диаграммы состояний чаще всего используются для описания поведения отдельных систем и подсистем. Они также могут быть применены для спецификации функциональности экземпляров отдельных классов, то есть для моделирования всех возможных изменений состояний конкретных объектов. Диаграмма состояний по существу является графом специального вида, который служит для представления конечного автомата.
Конечный автомат (state machine) — модель для спецификации поведения объекта в форме последовательности его состояний, которые описывают реакцию объекта на внешние события, выполнение объектом действий, а также изменение его отдельных свойств.
Диаграммы деятельности — частный случай диаграмм состояний. Они позволяют реализовать в языке UML особенности процедурного и синхронного управления, обусловленного завершением внутренних действий и деятельности. Основным направлением использования диаграмм деятельности является визуализация особенностей реализации операций классов, когда необходимо представить алгоритмы их выполнения. При этом каждое состояние может являться выполнением операции определенного класса либо ее части, позволяя использовать диаграммы деятельности для описания реакций на внутренние события системы.
Каждое состояние на диаграмме деятельности соответствует выполнению некой операции, а переход в следующее состояние происходит только после завершения выполнения этой операции. Диаграмма деятельности представляется в форме графа деятельности, вершинами которого являются состояния действия или деятельности, а дугами — переходы от одного состояния действия к другому.
Диаграмма компонентов, в отличие от ранее рассмотренных диаграмм, описывает особенности физического представления системы. Диаграмма компонентов позволяет определить архитектуру разрабатываемой системы, установив зависимости между программными компонентами, в роли которых может выступать исходный, бинарный и исполняемый код. Во многих средах разработки модуль или компонент соответствует файлу. Пунктирные стрелки, соединяющие модули, показывают отношения взаимозависимости, аналогичные тем, которые имеют место при компиляции исходных текстов программ. Основными графическими элементами диаграммы компонентов являются компоненты, интерфейсы и зависимости между ними.
Компонент (component) — физически существующая часть системы, которая обеспечивает реализацию классов и отношений, а также функционального поведения моделируемой программной системы.
Компонент предназначен для представления физической организации ассоциированных с ним элементов модели. Дополнительно компонент может иметь текстовый стереотип и помеченные значения, а некоторые компоненты – собственное графическое представление. Компонентом может быть исполняемый код отдельного модуля, командные файлы или файлы, содержащие интерпретируемые скрипты.
Диаграмма развертывания (deployment diagram) — диаграмма, на которой представлены узлы выполнения программных компонентов реального времени, а также процессов и объектов.
Диаграмма развертывания применяется для представления общей конфигурации и топологии распределенной программной системы и содержит изображение размещения компонентов по отдельным узлам системы. Кроме того, диаграмма развертывания показывает наличие физических соединений — маршрутов передачи информации между аппаратными устройствами, задействованными в реализации системы.
Диаграмма развертывания предназначена для визуализации элементов и компонентов программы, существующих только на этапе ее исполнения (run-time). При этом представляются только те компоненты программы, которые являются исполнимыми файлами или динамическими библиотеками. Компоненты, не используемые на этапе исполнения, на диаграмме развертывания не показываются. Так, компоненты с исходными текстами программ могут присутствовать только на диаграмме компонентов. На диаграмме развертывания они не указываются.
Диаграмма развертывания содержит графические изображения процессоров, устройств, процессов и связей между ними. В отличие от диаграмм логического представления, диаграмма развертывания является единственной для системы в целом, поскольку должна отражать все особенности ее реализации. Эта диаграмма, по сути, завершает процесс ООАП для конкретной программной системы и ее разработка, как правило, последний этап спецификации модели. Диаграмма развертывания разрабатывается совместно системными аналитиками, сетевыми инженерами и системотехниками.
3 Функциональное моделирование бизнес-процессов
Проведение исследований в области бизнес моделирования показало, что существуют уже сотни методик, методологий, процессов, стандартов, регламентирующих те или иные детали выбора и комплексирования потоков работ при разработке автоматизированных информационных систем. Работы, связанные с бизнес-анализом и бизнес-моделированием до недавнего времени были не популярны у проектировщиков ИС. Их роль не столь очевидна и принимается далеко не всеми методологиями. Возникает вопрос собирать информацию о предприятии, для которого разрабатывается (выбирается) АИС в виде бизнес-моделей или стоит пропустить этот этап и сразу формировать требования к системе и приступать к её разработке?
Заказчик и Разработчик всегда говорят на разных языках. Общее понимание вырабатывается с трудом, этот процесс занимает время, но важность его трудно переоценить: ведь успешная реализация проекта в области и внедрения АИС во многом зависит от того, удастся ли выработать и документировать их общее представление о предмете разработки. Если же Разработчик идет еще дальше и вникает в особенности ведения дел на предприятии Заказчика – он, во-первых, сможет добиться лучшего понимания требований к АИС и, во-вторых, участвовать наряду с Заказчиком в формулировке требований, анализе пропущенных требований и пр.
Задачу анализа бизнес-процессов (деловое моделирование), столь популярную в последние десятилетия ввиду устойчивой конъюнктуры, следует рассматривать, как часть более общей задачи, анализа проблемной области3. Работы, посвященные анализу проблемной области, появились в отечественной литературе в середине прошлого века; данная тематика неразрывно связано с задачным подходом и инженерией экспертных систем. Первые шаги в области моделирования были проведены в построении интеллектуальных систем. Для такой более приземленной задачи, как задача построения АИС – эти методы начали применяться позднее. Стратегии извлечения знаний во многом пересекаются с работой аналитика, методы решения задачи путем редукции на подзадачи и поиска в пространстве состояний нашли свое отражение во множестве методик бизнес-анализа, анализа и синтеза программных систем и этот список можно продолжать
ЗАКЛЮЧЕНИЕ
В данном дипломном проекте была разработана автоматизированная система учета нагрузки кафедры, которая позволяет осуществлять своевременное, оперативное и правильное оформление документации по нагрузке, уменьшить временные затраты, а также упростить и облегчить выполнение ежедневных обязанностей.
Для выполнения поставленной цели была проанализирована область применения программного обеспечения. Были смоделированы основные бизнес-процессы выпускающей кафедры и работы программного обеспечения, а также разработана логическая структура программного продукта, внутреннее взаимодействие его составных частей и руководство пользователя.
В рамках создания программного продукта были реализованы следующие функции:
подключение к базе данных;
выборка необходимых данных из базы для дальнейшей работы;
подсчет нагрузки;
формирование формы с подсчитанной нагрузкой.
В качестве перспективы развития программного продукта можно отметить, что предусмотрена возможность интеграции разработанного ПО в АСУ ВУЗ.
HYPER13PAGE HYPER15
71

Скачать работу

МОДЕЛИРОВАНИЕ БИЗНЕС-ПРОЦЕССОВ КАФЕДРЫ ВЫСШЕГО УЧЕБНОГО ЗАВЕДЕНИЯ

• Аннотация
• Об авторах
• Список литературы

Просмотров: 24

Многие организации пересматривают традиционные бизнес-модели в сторону увеличения роли дистанционного обучения. Так рынок онлайн образования увеличился в период с 2016 по 2021 год на 248%. На этом фоне возросла потребность в цифровизации привычных для образовательного учреждения бизнес-процессов, построенных на взаимодействия между преподавателями, студентами и административным персоналом.

Рассказываем, как можно эффективно проектировать и управлять бизнес-процессами в онлайн образовании с помощью Low-code платформы.

Классификация бизнес-процессов в образовательном учреждении

Бизнес-процессы делятся на три группы: операционные, вспомогательные и процессы управления. Для образовательной организации операционным процессом — будет преподавание дисциплин, а также организация методической и исследовательской работы.

В рамках операционного блока можно выделить несколько типовых процессов:

• подготовка к учебной деятельности,
• организация учебного процесса,
• управление преподавателями,
• управление обучающимися,
• контроль качества преподавательской деятельности,
• контроль результатов обучения.

Каждый блок можно декомпозировать на отдельные подпроцессы. Например, управление обучающимися — это сквозной бизнес-процесс, который начинается с приема студента и заканчивает его выпуском из ВУЗА (или отчислением, тут как повезет). Иначе процесс можно назвать «жизненным циклом студента», по аналогии с жизненным циклом продукта.

Посмотрим, в каких подпроцессах может участвовать студент во время обучения.

Блок управление студентами:

• прием студента на обучение,
• выдача справок, дипломов, других документов,
• запись на сессию и пересдачи,
• прием оплаты за обучение,
• отчисление по собственному желанию (или за неуспеваемость).

Структура и глубина декомпозиции бизнес-процессов определяется на этапе моделирования.

Особенности бизнес-процессов в образовании

По мнению экспертов, бизнес-процессы в образовании похожи на те, которые используются в промышленности. Однако есть и своя специфика. Например, для образовательной организации тяжело составить карту бизнес-процессов, используя цепочку создания ценности Портера. Модель Портера построена на превращении материальных ресурсов в продукт, в то время как бизнес-модель в образовании построена на передаче знаний от преподавателя к студенту.

Есть и другие существенные отраслевые особенности. Приведем лишь некоторые из них.

• большое количество внешних и внутренних связей: между отдельными кафедрами, учебными заведениями, исследовательскими лабораториями и т.д.
• высокая роль государства в стандартизации процессов обучения;
• ВУЗы часто работают на государственные субсидии и гранты, при этом прибыль не может служить показателем эффективности обучения;
• основные бизнес-процессы построены вокруг создания, накопления и передачи знаний;
• для учебных организаций характерна автономность структурных подразделений, что усложняет взаимодействие между ними;
• низкий уровень цифровизации образовательных услуг, особенно в государственном секторе (см. подробнее отчет ВШЭ).

Несмотря на все перечисленные особенности, для моделирования бизнес-процессов можно использовать стандартные методологии и методики, в том числе построенные на нотации BPMN 2.0.

Методы моделирования бизнес-процессов в образовании

Нотация BPMN не единственная в арсенале бизнес-аналитика, однако у нее есть ряд преимуществ.

• BPMN 2.0 можно приложить к любой системе менеджмента;
• Нотации наглядно показывает порядок взаимодействия между участниками бизнес-процесса, причем на любом уровне детализации;
• Диаграммы BPMN 2.0 удобно использовать при итерационном моделировании;
• Семантика нотации понятна ИТ-специалистам и менеджерскому персоналу;
• Полученные диаграммы легко использовать в информационных системах.

Для проектирования сегмента онлайн образования логично разбить портфель-услуг по отдельным кластерам. Например, компания продает онлайн курсы по программированию, проджект-менеджменту и интернет-маркетингу. Это отдельные продукты, которые включают свои учебные программы, требования к преподавательскому составу, способы проверки полученных знаний и т.д. У каждого кластера будут свои бизнес-процессы, которые будут отличаться друг от друга.

При моделировании бизнес-процессов важно понимать значение и роль децентрализации управления.

Различные структурные единицы образовательного учреждения регулярно взаимодействуют в рамках учебного курса. Это касается приемных комиссий, деканата, кафедр, учебных советов и т.д. Их взаимодействие построено на регламентах, которые описывают, что нужно сделать при наступлении определенного события. При этом сотрудники подразделений взаимодействуют друг с другом по горизонтали, минуя вышестоящих руководителей, которые только контролируют выполнение регламентов. Это и есть основа процессного подхода в любой организации.

Примеры моделирования бизнес-процессов в образовании

Рассмотрим пример того, как можно использовать BPMN 2.0 для создания исполняемых диаграмм бизнес-процессов в Comindware Business Application Platform. Слово «исполняемые» означает, что на основе диаграмм будет создано рабочее бизнес-приложение, в которое можно сразу пусть пользователей.

Возьмем небольшой подпроцесс «зачисление студента». В качестве основы для моделирования используем регламент НИУ ВШЭ, которые размещен на сайте ВУЗа.

Регламент ВШЭ предусматривает 2 варианта зачисления в ВУЗ:

• по квотам,
• по результатам вступительных испытаний.

Каждый из этих вариантов поступления можно представить в качестве отдельного подпроцесса, который можно детализировать до уровня отдельных операций.

Если рассматривать поступление по котам, то приемная комиссия должна сформировать список поступающих, ранжировать кандидатов по критериям и определить, кто из них поступит на бюджет, а кто поступит на обучение за счет НИУ ВШЭ или не поступит вовсе.

Процесс можно детализировать дальше — это основное преимущество итерационного моделирования. Мы создаем вначале общую модель процесса, а затем шаг за шагом уточняем сценарии и последовательность действий для каждого из них. Например, можно добавить шаг для автоматического запроса сведений в ФИС ФРДО, если организация может получить к ней доступ.

Создание бизнес-приложений для автоматизации образования

В Comindware Business Application Platform диаграмм в нотации BPMN 2.0 для создания рабочих бизнес-приложений в образовании. Для этого также потребуется создать модель данных и электронные формы для взаимодействия с этой моделью данных. Например, через электронную форму можно запросить у студента его персональные данные и пакет документов, которые необходимы для прохождения приемной комиссии.

Работа в Comindware Business Application Platform требует минимальных навыков программирования, которые практически не потребуются на этапе проектирования бизнес-приложения. Таким образом можно быстро создать предельно детализированную модель процесса, не затрачивая на данный этап проекта много времени.

Моделирование бизнес-процессов вуза при внедрении процессного управления

https://doi.org/10.21686/1818-4243-2014-1(102-4-11

• Аннотация
• Об авторах
• Список литературы

Просмотров: 2101