Размещено на http://www.allbest.ru/

Размещено на http://www.allbest.ru/

Проектирование информационной системы управления методической работой университета

Аннотация

бизнес процесс управление программа информационный

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

Результаты данной работы будут полезны для руководителей НИУ ВШЭ - Пермь и начальника учебно-методического отдела для определения путей развития и совершенствования учебно-методической работы филиала.

Количество страниц: 99 стр.

Количество иллюстраций: 9.

Количество таблиц: 45.

Количество приложений: 27.

Год написания работы: 2019.

Кафедра информационных технологий в бизнесе НИУ ВШЭ - Пермь

Введение

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

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

Объектом исследования является организация методической работы в вузе, основные принципы и взаимосвязи её бизнес-процессов.

Предметом исследования является автоматизация бизнес-процессов для повышения эффективности организации методической работы.

Целью работы является проектирование информационной системы управления методической работой университета для Пермского филиала федерального государственного автономного образовательного учреждения высшего образования «Национальный исследовательский университет «Высшая школа экономики» (далее - НИУ ВШЭ - Пермь), которая способна интегрироваться с существующими корпоративными системами университета.

Для достижения цели поставлены следующие задачи:

1. Описать автоматизируемые бизнес-процессы и выделить проблемные области.

2. Сформулировать требования к информационной системе управления методической работой в НИУ ВШЭ - Пермь, в том числе разработать техническое задание на разработку информационной системы управления.

3. Провести обзор информационных систем управления университетом на предмет наличия модулей, позволяющих решить выделенную проблему.

4. Составить экономическое обоснование разработки информационной системы.

5. Разработать проект информационной системы управления методической работой НИУ ВШЭ - Пермь.

При проведении исследования используются термины и понятия процессного подхода к управлению университетом, в качестве основной методики исследования используются объектно-ориентированный подход и инструментарий языка UML.

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

1. Выявление проблемной области и определение путей совершенствования бизнес-процессов, относящихся к методической работе университета

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

1.1 Анализ бизнес-процессов, относящихся к методической работе университета

Объектом данной работы является организация методической работы в университете. Под методической работой понимается комплекс мероприятий, направленных на обеспечение образовательного процесса учебно-методической документацией, повышение педагогического мастерства преподавателей, совершенствование всех форм, видов и методов учебной работы с учётом состояния и перспектив развития организаций, для которых университет готовит выпускников. Таким образом, основной целью методической работы в вузе является создание условий, способствующих повышению эффективности и качества учебного процесса [1].

В курсовой работе Захаровой И.И. «Проектирование бизнес-процессов учебно-методического отдела» был составлен реестр бизнес-процессов, владельцем которых является учебно-методический отдел НИУ ВШЭ - Пермь (см. прил. А) [2].

К бизнес-процессам, относящимся к методической работе вуза относятся все бизнес-процессы пункта 3 данного реестра (3.1 - 3.7):

3. Управление системой методического обеспечения учебного процесса.

3.1. Планирование, организация, сопровождение и контроль образовательного процесса в НИУ ВШЭ - Пермь в части методической работы.

3.2. Организация процесса разработки программ учебных дисциплин (далее - ПУД), учет и хранение в базе данных, контроль за оформлением и утверждением ПУД.

3.3. Участие в проектной деятельности по оптимизации методической работы НИУ ВШЭ - Пермь.

3.4. Подготовка и организация проведения заседаний учебно-методического совета (далее - УМС).

3.5. Организация проверок учебной документации на кафедрах и департаментах.

3.6. Реализация проекта «Учебный ассистент» в НИУ ВШЭ - Пермь.

3.7. Организация мероприятий по повышению педагогической квалификации научно-педагогических работников (далее - ППС).

Было выявлено, что часть из них имеет проблемы и нуждается в совершенствовании. В частности, это весь процесс 3, а также подпроцессы 3.2, 3.5 (см. Прил. Б - Г)

Бизнес-процесс управления системой методического обеспечения учебного процесса имеет следующие проблемы:

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

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

Подпроцесс организации процесса разработки программ учебных дисциплин, учет и хранение в базе данных, контроль за оформлением и утверждением ПУД имеет следующие проблемы:

1. Не используются данные из имеющихся корпоративных систем - разработчику ПУД приходится все данные водить вручную.

2. Есть технические сложности с проверкой всех ПУД на соответствие шаблону - на данный момент проверяющие реализуют это вручную.

3. Подпроцесс является рутинным и очень трудоемким, на него тратится много времени как у исполнителей, так и у проверяющих.

4. Нет возможности контролировать на этапе создания корректность используемых разработчиками ПУД документов (образовательный стандарт, учебный план, матрица компетенций), все проблемы использования неправильных версий документов обнаруживаются только на этапе проверки.

5. Нет удобного и структурированного хранилища ПУД за прошлые периоды - в АСАВ и на портале загружаются только текущие версии ПУД. Кроме этого в эти системы ПУД загружаются в формате pdf, и если разработчик потерял документ ПУД в формате doc, то ПУД приходится набирать сначала вместо внесения корректировок.

Подпроцесс организации проверок учебной документации на кафедрах и департаментах имеет следующие проблемы:

1. Подпроцесс является трудоемким и на него тратится много времени.

2. Часть документооборота кафедр и департаментов переведена в электронный вид, а проверяющие по-прежнему требуют документы в бумажном виде.

В курсовой работе был сделан вывод, что для повышения эффективности организации учебно-методической работы в НИУ ВШЭ - Пермь в первую очередь необходимо совершенствовать саму систему организации методической работы и подпроцессы 3.2, 3.5 с помощью следующих средств:

1. Модифицировать систему организации методической работы в филиале (предложить новую модель организации методической работы в НИУ ВШЭ - Пермь с использованием различных ИТ-инструментов).

2. Разработать информационную систему для организации, хранения и осуществления проверок документации на кафедрах и департаментах.

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

Для бизнес-процессов третьей группы были сформулированы пути изменения технологий с помощью средств автоматизации процессов. Результаты приведены на диаграммах TO BE процессов (см. прил. Д - Ж). Предлагаемые изменения выделены красным цветом [2].

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

Описание требований к информационной системе управления методической работой в НИУ ВШЭ - Пермь

Важным этапом достижения цели работы - разработки и проектирования информационной системы управления методической работой университета в НИУ ВШЭ - Пермь (далее - ИСУ МР, Система) - является постановка требований к разрабатываемой Системе.

При создании ИСУ МР необходимо руководствоваться следующими общими принципами проектирования информационных систем:

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

2. Принцип модульности и развития - Система должна быть реализована как совокупность отдельных максимально независимых функциональных подсистем, включая модуль для разработки и хранения ПУД, модуль организации проверок учебно-методических документов (далее - УМД); Модульный принцип построения Системы позволяет комбинировать модули в соответствии с требованиями заказчика и осуществлять масштабирование полученного решения, а также предоставляет возможность пополнения функциональных модулей без нарушения функционирования Системы.

3. Принцип системности - при декомпозиции должны быть установлены такие связи между структурными элементами Системы, которые обеспечивают цельность Системы и ее взаимодействие с другими системами.

4. Принцип санкционированного доступа к информации - Система должна обеспечивать санкционированный доступ к информации. Система должна иметь функции администрирования, которые позволяют устанавливать пользователям права доступа к информации (в зависимости от ролей пользователей в системе и персональные права доступа).

5. Принцип совместимости - должны быть реализованы информационные интерфейсы, благодаря которым Система может взаимодействовать с другими корпоративными системами НИУ ВШЭ в соответствии с установленными правилами.

6. Принцип стандартизации - должны быть рационально применены типовые, унифицированные и стандартизованные элементы, проектные решения, пакеты прикладных программ, комплексы, компоненты [3].

Кроме этого существуют индивидуальные требования, связанные с особенностями организации автоматизируемого бизнес-процесса и удобством пользователей.

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

Во-вторых, учебно-методические процессы направлены на организацию методической поддержки учебного процесса с целью подготовки высококвалифицированных кадров. Поэтому в Системе должна обеспечиваться гибкость подстройки под режим работы пользователей (использование в удобное время и в комфортном месте).

В-третьих, необходимо обеспечить возможность хранения и отображения учебно-методической информации в едином месте, включая возможность загрузки УМД (программы учебных дисциплин, фонды оценочных средств, контрольно-измерительные материалы и т.п.) в единое хранилище вуза через интернет. Это будет несомненно преимуществом для владельцев учебно-методических процессов, т.к. позволит более оперативно собирать информацию, контролировать актуальность содержания материалов, преподаваемых студентам. Что в свою очередь приведет к реализации цели более высокого порядка - выпуск более качественного и современного «продукта», наиболее подходящего для заказчиков.

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

В-пятых, в ИСУ МР должен осуществляться вход через Единый личный кабинет НИУ ВШЭ для соблюдения политики безопасности университета, применения единой системы идентификации и в целях обеспечения удобства корпоративных пользователей [4].

Следующим требованием к Системе является наличие возможности автоматических уведомлений на корпоративную почту сотрудников о важных событиях в ИСУ МР.

Заключительным требованием к ИСУ МР является обеспечение совместимости с документами, разработанными в приложениях Microsoft Office Word, Microsoft Office Excel, инструментах Google, а также возможности формирования отчетов по шаблону с возможностью автоматической подстановки информации в нужные поля из других корпоративных информационных систем университета и последующего их скачивания в различных форматах.

Технические требования к разработке ИСУ МР представлены в техническом задании на разработку автоматизированной системы (см. прил. З). Техническое задание содержит полный список требований заказчика к объекту закупки и оформляется в соответствии с ГОСТ 34.602-89. Информационная технология. Комплекс стандартов на автоматизированные системы. Техническое задание на создание автоматизированной системы [5].

Глава 2. Экономическое обоснование разработки информационной системы управления методической работой в университете

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

Анализ информационных систем управления вузом

Примерами комплексных решений для автоматизации деятельности образовательного учреждения высшего образования являются такие программные комплексы как:

· 1С-Университет, который позволяет автоматизировать документооборот, делопроизводство, учет договоров, управление бизнес-процессами и ИТ - процессами, связанными с организацией учебной деятельности [6].

· Тандем. Университет - комплекс для автоматизации основных процессов поддержки управления основной деятельностью образовательных организаций высшего образования [7].

· Галактика. Управление вузом - комплекс, который позволяет автоматизировать управление контингентом студентов, планирование учебного процесса, проведение приемной кампании, работу с договорами [8].

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

За рубежом также существуют аналогичные системы. В статье «Совершенствование информационных систем управления вузом» Федяковой Н.Н. приведен обзор зарубежных аналогов рассматриваемых систем, например, «SIMS.net Capita Education (UNITe) [9]. В статье автор делает вывод о том, что и отечественные, и зарубежные разработчики реализуют одинаковый подход к разработке информационных систем управления вузом, заключающийся в комплексной реализации на общей информационной базе и использовании модульного характера приложений, каждое из которых автоматизирует определенную подсистему и органично интегрируется в общую систему. Кроме этого функциональные модули системы сходны между собой [10].

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

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

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

В статье «Обзор систем управления вузом» Аксенова К.А., Сафроновой Н.В. проведен сравнительный анализ информационным систем, разработанных вузами самостоятельно и готовых решений, предлагаемых внешними организациями. Вывод получился достаточно неоднозначный, и заключается в том, что каждый вуз, который решился на внедрение системы управления, должен сначала провести анализ рынка систем управления вузом, а затем принимать решение о покупке существующей, заказе разработки новой автоматизированной системы управления или разработке силами сотрудников вуза [11].

Третьим способом решения проблемы автоматизации методической работы вуза является разработка информационной системы локально с последующей её интеграцией в существующую корпоративную систему университета.

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

В частности, в статье «Создание web-сервиса разработки рабочих программ учебных модулей/дисциплин с использованием информационных систем университета» Ашурова А.П., Рабовской М.Я. описывается решение проблемы автоматизации создания и хранения программ учебных дисциплин [12].

Также в статье «Информационная система составления расписания факультета» Бурындиной А.В. описан вариант решения узкой задачи автоматизации формирования расписания [13].

Корпоративные информационные системы НИУ ВШЭ - Пермь

В НИУ ВШЭ - Пермь на данный момент используются следующие корпоративные системы, обеспечивающие автоматизацию управления образовательным процессом или его элементов:

· Учетно-аналитическая система управления учебным процессом (АСАВ) - система управления информацией об объединенных учебных планах, индивидуальных учебных планах студентов, их успеваемости, о распределении нагрузки преподавателей, об абитуриентах, школьниках Лицея НИУ ВШЭ, об аспирантах НИУ ВШЭ, о выпускниках и о слушателях дополнительного профессионального образования [14].

· Система онлайн поддержки учебного процесса (LMS) - система поддержки образовательного процесса НИУ ВШЭ [15].

· Система планирования расписаний учебных занятий (РУЗ) - система позволяет формировать и просматривать расписание занятий, анализировать загруженность аудиторий. Также имеется реализация приложения для мобильных телефонов.

· Система автоматизации процессов Вышка-BPM - система автоматизации бизнес-процессов и предоставления сервисов НИУ ВШЭ, в которой реализованы личные кабинеты работников НИУ ВШЭ, а также организован процесс взаимодействия административных работников между собой и пользователями в рамках оказания услуг НИУ ВШЭ (более 50 сервисов основных административных подразделений, а также бизнес-сервисы: управление регистрацией и поддержкой мероприятий, управление дедлайнами учебных офисов, управление базой контрагентов (практики студентов), регистрации и поддержки мероприятий, академические надбавки, заявки на конкурсы научного фонда, сбор отчетов кадрового резерва и др.).

· Система документационного обеспечения управления (СДОУ) - система согласования и хранения документов НИУ ВШЭ (общие распорядительные документы, локальные нормативные акты, служебные записки, договоры, официальная переписка и другие документы).

· Портал НИУ ВШЭ - часть информационно-образовательной среды вуза, информационный ресурс в интернет, в котором реализованы Личные кабинеты преподавателей и работников НИУ ВШЭ, ведется новостная лента, имеется форум, формы опросов и сбора данных, автоматизирован ряд бизнес-процессов [16].

· Корпоративная электронная почта для студентов и работников (домен hse).

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

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

Экономическое обоснование разработки информационной системы

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

В первую очередь необходимо сопоставить насколько себестоимость разработки информационной системы вузом обойдется дешевле себестоимости выполнения разработки внешними исполнителями.

В пособии «Технология разработки прикладного программного обеспечения», авторами которого являются Соловьев С.В., Цой Р.И., Гринкруг Л.С., отмечено, что оценка затрат на разработку предполагает выполнение трех шагов.

На первом шаге производится оценка размера разрабатываемого продукта.

В настоящее время размер рассчитывается не на основании количества строк кода, а на основании количества функциональных точек.

Под функциональной точкой понимается любой из следующих элементов разрабатываемого прикладного программного продукта:

· входной элемент приложения (входной документ или экранная форма);

· выходной элемент приложения (отчет, документ, экранная форма);

· запрос (пара «вопрос/ответ»);

· лог-файл (совокупность записей данных, используемых внутри приложения);

· интерфейс приложения [17].

На втором шаге производится оценка трудоемкости работы. Оценку трудоемкости разработки производят на основании систематизации составляющих затрат на разработку системы и ?учета значимости факторов, влияющих на них.

На заключительном шаге определяется оценка стоимости проекта с учетом оцененного размера Системы и трудоемкости её разработки.

В данной работе для оценки стоимости разработки ИСУ МР была применена Методика оценки трудоемкости и стоимости разработки и сопровождения прикладного программного обеспечения при создании информационных систем (методика CETIN, далее - Методика). Методика включает в себя все вышеописанные шаги и позволяет достаточно точно рассчитать стоимость разрабатываемой системы. Данной методикой пользуются разработчики, являющиеся исполнителями государственных заказов и проектирующие информационные системы для органов власти [18].

Для расчета трудоемкости и стоимости работ на создание Системы согласно Методике необходимо выполнить этапы:

1. Оценки функционального размера Системы.

2. Оценки базовой трудоемкости и определение значений поправочных коэффициентов трудоемкости.

3. Оценки срока разработки.

4. Оценки стоимости создания Системы.

Для оценки функционального размера необходимо определить:

1. Количество вариантов использования (Case) - C.

2. Количество типов объектов (Entity) - Е.

3. Количество свойств типов объектов (Tool) - Т.

4. Количество взаимодействий между типами объектов (Interaction) - I.

5. Количество типов узлов (Node) - N.

Базовая трудоемкость создания ИС {Sj, j=1-6} определяется на основе оценки трудоемкости каждого процесса разработки (бизнес моделирование, управление требованиями, проектирование, реализация, тестирование, развертывание)

Базовая трудоемкость Sj процесса разработки рассчитывается по формуле (1):

,(1)

где S_j - трудоемкость процесса разработки с номером j в человеко-месяц;

j - номер процесса разработки (значения от 1 до 6);

S_j(C) - норматив трудоемкости реализации одного варианта использования в процессе разработки с номером j=1,2,...,6;

S_j(E) - норматив трудоемкости реализации одного типа объектов в процессе разработки с номером j=1,2,...,6;

S_j(T) - норматив трудоемкости реализации одного свойства типа объекта в процессе разработки с номером j=1,2,...,6;

S_j(I) - норматив трудоемкости реализации одного взаимодействия между типами объектов в процессе разработки с номером j=1,2,...,6;

S_j(N) - норматив трудоемкости реализации одного типа узла в процессе

разработки с номером j=1,2,...,6;

165 - количество человеко-часов в одном человеко-месяце.

Дополнительно рассчитываются поправочные коэффициенты трудоемкости по формулам (2-7):

КП1 = К11хК16хК17, (2)

КП2 = К1х К2хК4хК5хК6хК7хК8хК9хК16хК17хК18(3)

КП3=К1хК2хК4хК5хК6хК7хК8хК9хК11хК12хК13хК14хК15хК16хК17хК18(4)

КП4=К1хК2хК4хК5хК6хК7хК8хК9хК10хК12хК13хК14хК15хК16хК17хК18(5)

КП5=К1хК2хК4хК5хК6хК7хК8хК9хК10хК11хК12хК13хК14хК15хК16хК17хК18(6)

КП6 = К1хК2хК11хК16хК18(7)

На основании поправочных коэффициентов делается расчет трудоемкости создания Системы по формуле (8):

Т= КП1 х ??1 + КП2 х ??2 + КП3 х ??3 + КП4 х ??4 + КП5 х ??5 + КП6 х ??6,(8)

где S - скорректированная трудоемкость процесса разработки ППО в человеко-месяцах;

S_j - базовая трудоемкость процесса разработки с номером j в человеко-месяцах;

КП_j - поправочный коэффициент трудоемкости процесса разработки с номером j.

На стоимость создания ИС влияют срок разработки проекта Г_ср, планируемое начало работ, место реализации, уровень ежегодной инфляции. Для каждого года реализации i определяем среднемесячную номинальную заработную плату З^??_ср по формуле (10):

(9).

Далее для каждого года реализации определяем соответствующую среднюю стоимость 1 человеко-месяца инженера-программиста С^??_ср по формуле (10):

)*(1+)*(1+),(10)

где ПСН - социальный налог с учетом отчислений в фонд обязательного социального страхования в процентах от среднемесячной заработной платы;

ПНР - накладные в процентах от среднемесячной заработной платы;

ПРП - расходы периода в процентах от среднемесячной заработной платы;

ПР - рентабельность;

ПНДС - налог на добавленную стоимость.

Определяем трудоемкость разработки ИС по годам реализации по формуле (11):

(11)

Совокупная стоимость работ на создание Системы рассчитывается по формуле (12):

(12)

Стоимость ИСУ МР, рассчитанная по методике CETIN получилась равной 273377,17 руб. Расчеты коэффициентов приведены в приложении И. Рыночная стоимость разработки аналогичных систем, предлагаемых различными компаниями колеблется от 300000 до 600000 рублей. По сравнению со средней рыночной стоимостью аналогичных систем, рассчитанная стоимость Системы является наиболее приемлемой и позволяет организации сэкономить часть финансовых средств.

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

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

Различают техническую, социальную и экономическую эффективность.

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

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

Экономическая эффективность оценивается сопоставлением показателей экономической результативности информационной системы со стоимостными затратами на реализацию этой системы, подсистемы или проекта. Основная проблема оценки разных видов эффективности - сопоставимость сравниваемых величин (по единицам измерения, периоду времени и т.д.). Проблема сопоставимости при расчете экономической эффективности ограничивается корректностью сопоставления временного промежутка, в течение которого оценивалась экономическая результативность, и временного промежутка, в течение которого оценивались затраты [19].

В данной задаче основными источниками экономической эффективности информационной системы являются:

1. Сокращение затрат рабочего времени, и, как следствие, сокращение расходов на оплату труда, выполняемого в рамках данных бизнес-процессов.

2. Сокращение затрат на материальные ресурсы (печать документов).

3. Сокращение потерь от наличия ошибок (перепечатывание документов, сокращение рабочего времени на контроль).

Автоматизируемые бизнес-процессы были проанализированы на предмет выявления источников экономической эффективности.

В первую очередь, было выявлено, что автоматизация бизнес-процессов управления методической работой сократит число рабочих часов, потраченных на выполнение операций в год в среднем с 564 часов до 102 часов. Средняя заработная плата специалиста по учебно-методической работе составляет 18000 руб. в месяц, или 102,27 руб. в час. Таким образом, экономия на трудозатратах составит (564 - 102) * 102,27 = 47250,00 руб. в год.

Для расчета экономии затрат на материальные ресурсы была выбрана оценка печати бумажных документов до и после внедрения информационной системы. Расходы на печать документов включают в себя расходы на бумагу и расходы на покупку (заправку) картриджа. Средняя стоимость одного листа бумаги 1,5 руб. Средняя стоимость покупки картриджа для печати одного листа 0,67 руб. Среднее количество листов в год, печатаемых до автоматизации бизнес-процессов, составляет 22400 листов, а после - 11080 листов. Таким образом, экономия на печати документов составляет 24526,67 руб. в год.

Однако внедрение информационной системы увеличит амортизацию оборудования, в частности компьютера, и увеличит потребление электроэнергии в организации. При расчете годовой амортизации учитывались средний срок службы оборудования (10 лет), средняя стоимость оборудования для одного рабочего места, интенсивность использования техники (до внедрения ИСУ МР используется коэффициент 0,5 - 50 % рабочего времени выполнения бизнес-процесса используется компьютер, после внедрения - коэффициент 1). При расчете затрат на электроэнергию использовалась средняя стоимость 1 кВт, равная 3,99 руб., средняя нагрузка 3 кВт в час, и учитывалась интенсивность использования компьютера и техники во время выполнения бизнес-процессов до и после автоматизации. В результате получилось, что внедрение информационной системы увеличивает амортизацию и затраты на электроэнергию на 2945,83 руб. в год.

Общая экономия ресурсов НИУ ВШЭ - Пермь в год по рассматриваемым источникам экономической эффективности приведена в таблице 2.1.

Таблица 2.1. Экономия ресурсов при автоматизации бизнес-процессов

расходы	расходы до внедрения ИС (руб.)	расходы после внедрения ИС (руб. )	Экономия в год (абсолютная, руб.)	Экономия в год (относительная, %)
трудозатраты	57681,82	10431,82	47250,00	82%
печать документов	48533,33	24006,67	24526,67	51%
амортизация	2400,00	4800,00	-2400,00	-100%
электроэнергия	675,11	1220,94	-545,83	-81%
ИТОГО в год	109290,26	40459,42	68830,83	63%

Абсолютная экономия ресурсов в денежном выражении равна 68830,83 руб. в год, что составляет 63% от начального уровня затрат.

После определения экономии необходимо определить срок окупаемости информационной системы. Срок окупаемости можно вычислить по формуле:

, (14)

где Т_Ок - срок окупаемости ИС,

И - инвестиции в проект (затраты на разработку информационной системы),

Эф - экономия от ИС (разность между доходом от ИС и текущими затратами).

Выше было получено, что затраты на разработку информационной системы составляют 273377,17 руб., а экономия ресурсов в абсолютном выражении составила 46405,83 руб. в год. Таким образом, срок окупаемости проекта составит примерно 4 года.

Рассчитанные показатели позволяют сделать вывод об экономической целесообразности внедрения ИСУ МР в НИУ ВШЭ - Пермь для автоматизации бизнес-процессов.

3. Проектирование информационной системы управления методической работой НИУ ВШЭ - Пермь

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

В качестве основного инструмента проектирования был использован язык UML. UML - это графический язык моделирования, представляющий собой систему обозначений, базирующуюся на диаграммах, и предназначенный для визуализации, спецификации, конструирования и документирования систем, в которых большая роль принадлежит программному обеспечению [20].

Также в качестве дополнительного инструмента визуализации был использован язык ArchiMate. Язык ArchiMate не фокусируется на деталях реализации и не заменяет UML, а дополняет его. В ArchiMate меньше возможностей по детализации, чем в UML, но он позволяет связать описания различных областей и разработать интегрированное представление процессов организации [21].

3.1 Описание акторов и прецедентов системы

Разрабатываемая ИСУ МР имеет 5 акторов: Учебно-методический отдел (далее - УМО), департамент (кафедру), академического руководителя, менеджера ОП и ППС.

1. Учебно-методический отдел является центром формирования методических компетенций для всех остальных акторов и должен осуществлять методическую поддержку как сотрудников департамента, ведущих методическую работу (далее - МР) с ППС, так и сотрудников факультета, отвечающих за методическую поддержку студентов. УМО представляет интересы стратегического стейкхолдера - руководства филиала и определяет рамки и ограничения, в которых будет функционировать заданная Система. Рамки и ограничения задаются с помощью учебно-методических материалов (далее - УММ), которые включают в себя инструкции, регламенты, порядок реализации различных процессов и другие регламентирующие документы. УММ разрабатываются на основе федеральных требований и под контролем Дирекции основных образовательных программ НИУ ВШЭ (ДООП).

2. Акторы среднего уровня - академические руководители (далее - АР ОП) и менеджеры ОП. Каждый из участников имеет собственный функционал и является держателем различных бизнес-процессов. Однако логически эти группы взаимосвязаны, поэтому академические руководители и менеджеры одной ОП должны иметь сайт для обмена информацией и хранения общих документов. Также у них должна быть возможность делегировать друг другу задания, полученные из УМО. Академические руководители в Системе являются представителями академических советов - совещательных органов, принимающих решение по развитию образовательных программ. Например, после обсуждения документа на академическом совете и его утверждения, академический руководитель образовательной программы изменяет статус документа в ИСУ МР от имени академического совета.

3. Следующий уровень акторов - это ППС. Преподаватели имеют достаточно ограниченные права в системе (просмотр информации и загрузка данных), однако они являются самыми многочисленными по количеству и основными “наполняющими” базы данных, загружая ПУД и УМД в Систему.

4. Среди ППС можно выделить отдельную группу лиц с расширенным функционалом - руководители департаментов (и кафедр). Кроме обычных функций ППС руководители могут согласовывать заявки, принимать запросы, проверять загруженные документы ППС и формировать отчеты для УМО.

Для автоматизируемых бизнес-процессов был создан проект взаимодействия акторов на площадках на языке ArchiMate (см. рис. 3.1).

Рисунок 3.1. Акторы методической работы в университете

Бизнес-процессы, в рамках которых взаимодействуют акторы, следующие:

1. Управление системой методического обеспечения учебного процесса.

2. Организация процесса разработки ПУД, учет и хранение в базе данных, контроль за оформлением и утверждением ПУД.

3. Организация проверок учебной документации на кафедрах и департаментах.

Для автоматизируемых бизнес-процессов на языке ArchiMate был разработан вид для руководителей организации о назначении ИСУ МР на общем уровне (без детализации) (см. рис. 3.2).

Система предназначена для ежегодного планирования, организации и контроля за выполнением методической работы университета, что на рисунке отображается событием, запускающим процесс управления методической работой в начале каждого года. Сам процесс разбит на бизнес-функции, выполняемые в рамках бизнес-процессов и подпроцессов. Также на рисунке показан слой приложений: веб-интерфейс ИСУ МР и взаимодействие с другими корпоративными системами университета, кроме этого показана взаимосвязь блоков, доступных пользователю через веб-интерфейс приложения, с бизнес-процессами и подпроцессами.

Рисунок 3.2. Вид для руководителей о назначении ИСУ МР

Далее с помощью элементов языка UML была разработана диаграмма прецедентов. Для удобства и повышения наглядности общая диаграмма прецедентов была разбита на логические части, соответствующие бизнес-процессам. Взаимодействие акторов в рамках реализуемых бизнес-процессов описано на диаграммах прецедентов (см. рис. 3.3 - 3.5).

Условные обозначения являются общими для всех трех диаграмм прецедентов. Фигурами людей на диаграмме обозначены акторы Системы. В овалах желтого цвета указаны основные прецеденты. В овалах розового цвета с пояснением «включить» отображены зависимые от основных дополнительные прецеденты (основной вариант использования, вызывает дополнительный прецедент). В овалах зеленого цвета с пояснением «расширить» отображены зависимые от основных дополнительные прецеденты (зависимый вариант использования расширяет определение основного).

Сплошными стрелками отображена взаимосвязь акторов с прецедентами (ассоциация). Длинными пунктирными стрелками показана зависимость прецедентов: одно определение зависит от другого. Например, нельзя ознакомиться с планом методической работы пока это план не создан; то есть прецедент «Ознакомление с планом МР» зависит от «Создание плана МР».

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

Общим прецедентом для всех пользователей является «Вход в систему».

Далее на диаграмме прецедентов описывается совокупность прецедентов в рамках бизнес-процесса управления методической работой в университете, владельцем которого является УМО. Сначала сотрудником УМО реализуется прецедент по разработке плана МР на учебный год. Затем в каждом плане на учебный год создается список задач. В рамках каждой задачи описывается условие, размещаются инструкции, регламенты и другие важные для выполнения задачи документы (или ссылки на них) - УММ, назначаются исполнители, устанавливаются сроки выполнения задачи. При необходимости размещаются формы для сбора данных. После этого сотрудники, которым задача была отправлена на исполнение, могут ознакомиться с условием задачи, а затем в соответствии со своей ролью - начать исполнять задачу или делегировать её. Руководители департамента могут поставить задачу ППС своего департамента, а академические руководители и менеджеры одной ОП могут делегировать задачу друг другу.

Поставленная руководителем департамента сотрудникам задача сначала попадает на проверку руководителю департамента. Руководитель департамента может принять задачу, изменив ее статус на «проверено руководителем департамента» и затем отправить на проверку в УМО, либо не принять, изменив статус на «возвращено на доработку». После выполнения задачи, она отправляется исполнителем постановщику задачи. Сотрудник УМО проверяет выполнение и может либо принять задачу, изменив ее статус на «проверено УМО», или не принять, изменив статус на «возвращено на доработку». Кроме этого сотрудник УМО в любое время может сформировать отчет о выполнении задачи, в котором должна быть информация о том, сколько подразделений выполнило задачу, сколько - не выполнило.

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

Рисунок 3.3. Диаграмма прецедентов (управление организацией методической работы вуза)

Две другие диаграммы (см. рис. 3.4 - 3.5) только детализируют вышеописанные подпроцессы и вынесены отдельно, чтобы не перегружать основную диаграмму прецедентов.

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

Рисунок 3.4. Диаграмма прецедентов (процесс разработки ПУД)

В данном бизнес-процессе участвуют 4 актора - УМО, руководитель департамента, ППС, академический руководитель ОП - каждый на своем этапе бизнес-процесса.

Начинается бизнес-процесс с того, что в Системе сотрудник УМО проверяет настройки шаблона (формы) ПУД: здесь возможно выбрать 2 варианта - ручная загрузка файла с исходными данными и интеграция с АСАВ. Если выбрана ручная загрузка файла, то академические руководители всех ОП загружают учебные планы, сформированные на основании образовательного стандарта, с учетом всех преподавателей, реализующих дисциплины ОП.

Затем руководители департаментов проверяют в ИСУ МР списки дисциплин, закрепленных за кафедрой в данном учебном году и ставят задачу перед ППС департамента по разработке (корректировке) формы ПУД. Если ПУД была ранее утверждена академическим руководителем программы, то изменения можно вносить только в определенные поля формы (допускается до 30% внесения изменений без переутверждения). Если изменений вносится больше, то ПУД автоматически теряет статус утвержденной и получает статус новой.

После заполнения формы или внесения более 30% разработчик отправляет ПУД на согласование руководителю департамента, который может либо согласовать ПУД, изменив ее статус на «одобрено руководителем департамента» и затем отправить на утверждение академическому руководителю, или не принять, изменив статус на «возвращено на доработку». Далее аналогичным образом ПУД утверждает или возвращает на доработку академический руководитель соответствующей ОП.

Если дисциплина не прикреплена ни к одной образовательной программе, то есть имеет вид дисциплины «Майнор», «МагоЛего», «Общеуниверситетский факультатив», то вместо академического совета она рассматривается на учебно-методическом совете, и вместо академического руководителя ОП её утверждает руководитель УМО от имени председателя учебно-методического совета.

После того, как ПУД получила статус утвержденной, она должна во время интеграции с Порталом НИУ ВШЭ отобразиться на странице соответствующего департамента и соответствующей ОП. Затем сотрудники УМО в ИСУ МР могут сформировать итоговый отчет о неутвержденных ПУД на определенную дату.

На рисунке 3.5 представлена диаграмма прецедентов для бизнес-процесса организации проверок УМД на кафедрах и департаментах. В процессе участвуют 3 актора - УМО, руководитель департамента, ППС.



Рисунок 3.5. Диаграмма прецедентов (организации проверок УМД)

Сначала сотрудником УМО настраиваются параметры блока «УМД», определяются сроки подготовки к проверке и сроки проверки, определяются проверяемые подразделения, выбирается состав УМД и уведомляются руководители проверяемых подразделений.

Затем руководители проверяемых подразделений могут сами или с привлечением ППС загрузить требуемые документы.

Если руководитель департамента ставил задачу перед ППС, то после выполнения задача сначала попадает на проверку руководителю департамента, который может либо принять задачу, изменив ее статус на «проверено руководителем департамента», или не принять, изменив статус на «возвращено на доработку». Руководитель департамента также может сформировать отчет о выполнении задачи, оценить процент готовности к проверке по наличию проверяемых УМД.

После выполнения задачи, она отправляется руководителем департамента постановщику задачи, сотрудник УМО проверяет выполнение и может либо принять задачу, изменив ее статус на «проверено УМО», или не принять, изменив статус на «возвращено на доработку». Кроме этого сотрудник УМО в любое время может сформировать отчет о выполнении задачи, оценить процент готовности к проверке по наличию проверяемых УМД как по каждому подразделению, так и по филиалу в целом.

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

3.2 Описание архитектуры информационной системы

Основной частью проектирования ИСУ МР является архитектура. Поэтому важно установить определенные требования к архитектуре Системы.

Описание набора требований приведено ниже:

1. Система должна представлять собой веб-приложение, в котором одновременно работает несколько пользователей, взаимодействующих через сеть Интернет.

2. Должен быть реализован вход в ИСУ МР через ЕЛК - единый личный кабинет пользователя НИУ ВШЭ.

3. Архитектура ИСУ МР должна быть распределенной многоуровневой клиент-серверной архитектурой.

4. ИСУ МР должна представлять собой единую централизованную систему, состоящую из набора взаимосвязанных подсистем. Система должна строиться по модульному принципу, допускающему раздельную разработку, установку, обновление и техническое обслуживание отдельных подсистем.

5. Все компоненты Системы должны быть готовы к реализации в облачной среде.

6. Серверные части Системы должны предусматривать развертывание на общих централизованных вычислительных мощностях.

Общий вид клиент-серверной архитектуры изображен на рис. 3.6.



Рисунок 3.6. Клиент-серверная архитектура

...