Исполнение процесса

После запуска процесса «Выбор темы» открывается форма с доступными заявками (см. рисунок 2.25).



Рисунок 2.25. Просмотр доступных тем

После выбора пункта «Создать новую заявку» открывается форма для ввода данных о заявке (см. рисунок 2.26). После заполнения полей и перехода к следующей операции открывается форма для выбора руководителя (см. рисунок 2.27). Затем руководитель проверяется на перегрузку и процесс завершается.



Рисунок 2.26. Создание новой заявки

Рисунок 2.27. Форма выбора руководителя

Симуляция выполнения процесса

Параметры симуляции:

1. Количество экземпляров процесса - 100, интервал подачи - 5 минут.

2. Шанс на создание новой заявки студентом - 50 %.

3. Вероятность перегрузки преподавателя - 20 %.

Результаты выполнения симуляции представлены в таблице 2.8.

Таблица 2.8. Симуляция процесса «Выбор темы»

Имя процесса или операции	Экземпляров выполнено	Минимальное время выполнения (мин)	Среднее время выполнения (мин)	Суммарное время выполнения (мин)
Выбор темы студентом (процесс)	100	7	14	1400
Проверка на перегрузку преподавателя	100	0	0	0
Просмотр существующих заявок	100	5	5	500
Создание новой заявки	50	15	15	750
Выбор заявки	50	1	1	50
Закрепление темы за студентом	76	0	0	0
Отбор заявок	100	0	0	0
Выбор руководителя	100	1	1	100

2.4 Автоматизация бизнес-процесса «согласование темы работы»

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

После того, как студент выбрал тему и согласовал с руководителем, ее должен утвердить академический руководитель. На рисунке 2.28 представлена модель бизнес-процесса «Согласование темы работы».

Рисунок 2.28. Согласование темы работы

Построение модели данных

Создана сущность процесса «TopicApproval». В качестве атрибутов выбраны коллекция заявок и логическая переменная «NeedModification».

Создание форм

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

Рисунок 2.29. Форма "Утверждение тем"



Форма «Изменение темы» также содержит таблицу с информацией о заявке, которую академический руководитель может изменить. (см. рисунок 2.30)

Рисунок 2.30. Форма «Изменение темы»

Определение бизнес-правил

Переход по развилке осуществляется в соответствии со значением атрибута NeedModification. Во время выполнения операции «Отбор заявок» выполняется выражение, присваивающее идентификатор выполняемого процесса соответствующему атрибуту экземпляров сущности «Applications» (см. рисунок 2.31). Это позволяет получить коллекцию заявок. Также на выходе с операции «Утверждение тем» установлено выражение, определяющее, остались ли заявки со статусом «на доработку» (см. рисунок 2.32).

Рисунок 2.31. Выражение отбора заявок

Рисунок 2.32. Выражение на выходе операции "Утверждение заявок"

Исполнение процесса

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

Рисунок 2.33. Форма утверждения заявок

Симуляция выполнения процесса

Для сценария симуляции выбраны следующие параметры:

1. Количество экземпляров процесса - 76, интервал подачи - 5 минут.

2. Вероятность необходимости доработки темы - 15%.

Параметры выбраны в соответствии с результатами и параметрами симуляции бизнес-процесса «as is» для возможности корректного сравнения эффективности моделей. Результаты симуляции представлены в таблице 2.9.

Таблица 2.9. Симуляция процесса «Утверждение темы»

Имя процесса или операции	Экземпляров выполнено	Минимальное время выполнения (мин)	Среднее время выполнения (мин)	Суммарное время выполнения (мин)
Утверждение темы (процесс)	76	1	4,13	314
Издание приказа	76	1	1	76
Отбор заявок	76	0	0	0
Утверждение тем	76	0	0	0
Интеграция данных в АСАВ	76	0	0	0
Консультация со студентом	14	15	15	210
Изменение темы	14	2	2	28

2.5 Автоматизация бизнес-процесса «изменение темы работы»

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

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

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

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

Рисунок 2.34. Изменение темы работы



Рисунок 2.35. Замена руководителя

Построение модели данных

Для процессов были созданы сущности «TopicChanging» и «SupervisorChange». Для них в качестве атрибута была добавлена сущность «Applications».

Создание форм

Формы для операций «Внесение изменений в ИС» обоих процессов содержат таблицу с информацией о заявках (см. рисунок 2.36). Элементы таблицы не редактируемы, кроме столбца «Тема работы» для процесса «Изменение темы работы» и столбца «Руководитель» для процесса «Замена руководителя».

Рисунок 2.36. Форма "Изменение темы работы"

Определение бизнес-правил

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

Исполнение процесса

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

Рисунок 2.37. Форма изменения данных о заявке

Симуляция выполнения процесса

Параметры симуляции сценариев процессов «Изменение темы работы» и «Замена руководителя»:

1. Количество подаваемых заявок - 20, интервал подачи - 30 минут.

2. Шанс на замену руководителя после получения заявления - 80 %.

Результаты симуляции процессов представлены в таблицах 2.10 и 2.11.



Таблица 2.10. Симуляция процесса «Изменение темы»

Имя процесса или операции	Экземпляров выполнено	Минимальное время выполнения (мин)	Среднее время выполнения (мин)	Суммарное время выполнения (мин)
Изменение темы (процесс)	20	35	35	700
Внесение изменений в ИС	20	5	5	100
Издание приказа	20	15	15	300
Написание заявления	20	15	15	300
Отбор заявок	20	0	0	0

Таблица 2.11. Симуляция процесса «Замена руководителя»

Имя процесса или операции	Экземпляров выполнено	Минимальное время выполнения (мин)	Среднее время выполнения (мин)	Суммарное время выполнения (мин)
Замена руководителя (процесс)	20	18	36	720
Внесение изменений в ИС	18	5	5	90
Написание заявления	20	15	15	300
Издание приказа	18	15	15	270
Отбор заявок	18	0	0	0
Принятие решения о замене руководителя	20	3	3	60



2.6 Автоматизация бизнес-процесса «загрузка студентом готовой работы»

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

Рисунок 2.38. Загрузка работы

Для процесса создана сущность «WorkUpload», хранящая один атрибут - файл работы. Была создана форма для загрузки файла работы (см. рисунок 2.39)

Рисунок 2.39. Форма "Загрузка работы в ИС"



Также на выходе из операции «Загрузка работы в ИС» было добавлено действие - выполнение выражения, с помощью которого загруженный файл сохраняется в базе данных. Код выражения представлен на рисунке 2.40. При выполнении выражения сначала находятся заявки, в которых в качестве студента указан текущий пользователь системы, а затем файл присваивается той заявке, в которую работа еще не загружена.

Рисунок 2.40. Выражение для сохранения файла

Во время исполнения процесса форма предлагает загрузить файл (см. рисунок 2.41).



Рисунок 2.41. Загрузка файла работы

2.7 Результаты автоматизации бизнес-процессов

Сравнение результатов симуляции моделей бизнес-процессов «as is» и «to be» представлено в таблице 2.12. Так как бизнес-процесс «Выбор, согласование и закрепление за студентом темы работы» был разделен на подпроцессы «Выбор темы» и «Утверждение темы», в таблицу вписано суммарное время их выполнения.

Бизнес-процесс	Длительность выполнения для модели «as is» (мин)	Длительность выполнения для модели «to be» (мин)
Предложение тем (100 экземпляров)	13039	3234,7
Выбор, согласование и закрепление за студентом темы работы (100 экземпляров)	2876	1714
Изменение темы работы (20 экземпляров)	600	700
Замена руководителя (20 экземпляров)	615	720

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

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

Что касается процессов изменения темы работы и замены руководителя, их продолжительность выше в моделях «to be», но их автоматизация позволяет решить проблему хранения в информационной системе неактуальных данных.



Заключение

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

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

Следующими этапами являются разработка и внедрение университетом спроектированной в данной работе информационной системы. Другим вариантом является приобретение продукта Bizagi Engine и доработка построенного прототипа до уровня полнофункциональной системы.



Библиографический список

1. Положение о курсовой и выпускной квалификационной работе студентов, обучающихся по программам бакалавриата, специалитета и магистратуры в Национальном исследовательском университете «Высшая школа экономики»: принято 28 ноября 2014 года. - 14 с.

2. Правила написания и оформления выпускных квалификационных работ студентов образовательной программы бакалавриата «Бизнес-информатика» по направлению подготовки 38.03.05 Бизнес-информатика»: утверждены 12 декабря 2017. - 37 с.

3. Hommes, B.-J. The Evaluation of Business Process Modeling Techniques / B.-J. Hommes // TU Delft. 2004

4. Бабкин, Э.А. Сравнительный анализ языковых средств, применяемых в методологиях бизнес-моделирования / Э.А. Бабкин, В.П. Князькин, М,С, Шиткова // БИЗНЕС-ИНФОРМАТИКА №2(16)-2011 г., с. 31-42.

5. Gabryelczyk, R. Does Experience Matter? Factors Affecting the Understandability / R. Gabryelczyk, A. Jurczuk // Procedia Engineering 182(2017), p. 198 - 205.

6. Коннолли, Т. Базы данных. Проектирование, реализация и сопровождение. Теория и практика / Т. Коннолли, К. Бегг - 3-е изд. -- М.: Вильямс, 2003. -- 1436 с.



Приложение А. Техническое задание

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

ТЕХНИЧЕСКОЕ ЗАДАНИЕ

На 10 листах

1. Общие сведения

1.1. Наименование системы

1.1.1. Полное наименование системы

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

1.1.2. Краткое наименование системы

Краткое наименование: Система.

1.2. Основания для разработки

Разработка ведется в рамках выполнения выпускной квалификационной работы. Регламентируется НИУ ВШЭ следующими документами:

· Положение о курсовой и выпускной квалификационной работе студентов, обучающихся по программам бакалавриата, специалитета и магистратуры НИУ ВШЭ, дата принятия 28.11.2014, вступил в силу 1.09.2015;

· Положение о государственной итоговой аттестации студентов образовательных программ высшего образования - программ бакалавриата, специалитета и магистратуры Национального исследовательского университета «Высшая школа экономики», дата принятия 7.04.2017, вступил в силу 20.04.2017;

· Правила подготовки выпускных квалификационных работ студентов образовательной программы бакалавриата «Бизнес-информатика» по направлению подготовки 38.03.05 Бизнес-информатика, Утверждены протоколом ученого совета НИУ-ВШЭ - Пермь от 17.09.2015 № 8.2.1.7-10/8.

1.3. Наименование Заказчика и Разработчика

1.3.1. Заказчик

Заказчик: Федеральное государственное автономное образовательное учреждение высшего образования «Национальный исследовательский университет «Высшая школа экономики», Пермский кампус. Адрес: 614070, г. Пермь, ул. Студенческая, д. 38. Телефон: (342) 205-52-50, факс: (342) 205-52-12.

1.3.2. Разработчик

Разработчик: Бажин Иван Сергеевич, телефон: +7(909)108-98-90, e-mail: isbazhin@edu.hse.ru.

1.4. Плановые сроки начала и окончания работы

Начало работ: 1.11.2017.

Окончание работ: 26.04.2018.

1.5. Порядок оформления и предъявления заказчику результатов работ

Результаты каждого этапа работ (см. пункт 5 данного технического задания) отправляются Заказчику в течение обозначенного времени выполнения этапа. Таким образом, Заказчик получает следующие результаты работы:

1) модели бизнес-процессов «to be» в нотации BPMN 2.0;

2) технический проект информационной системы;

3) установленная информационная система;

4) документация, разрабатываемая в процессе передачи системы.

2. Назначение и цели создания системы

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

Характеристика объекта автоматизации

Объектом автоматизации является процесс управления выполнением курсовых и выпускных квалификационных работ. В таблице А.1 представлена информация о подпроцессах с указанием возможности автоматизации каждого подпроцесса.

Табл. А.1. Список подпроцессов

Процесс	Возможность автоматизации	Решение об автоматизации
Предложение тем работ	Да	Автоматизировать
Выбор, согласование руководителем и закрепление темы;	Да	Автоматизировать
Изменение темы работы при необходимости;	Да	Автоматизировать
Написание студентом работы;	Нет	Нет
Сдача студентом готовой работы.	Да	Автоматизировать
Защита работы	Нет	Нет

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

3. Требования к системе

3.1. Требования к системе в целом

3.1.1. Требования к структуре и функционированию системы

Система должна быть реализована в виде web-приложения, иметь клиент-серверную архитектуру. Сервер приложений должен описывать уровень бизнес-логики. Система должна быть централизованной: все данные должны храниться на одном сервере. Сервер БД должен хранить базу данных, в которой хранится информация о заявках, студентах и руководителях; обеспечивать целостность и сохранность данных; выполнять операции ввода-вывода при доступе клиента к информации. Клиентская часть реализует уровень представления. Пользователи должны иметь доступ к Системе 24 часа в сутки 7 дней в неделю.

3.1.2. Требования к численности и квалификации персонала системы

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

Пользователи системы должны иметь опыт работы с персональным компьютером. Пользователь должен обладать базовыми умениями по навигации в сети Интернет и вводу данных на веб-страницах.

3.1.3. Требования к надежности

Надежная работа системы должна достигаться за счет:

· правильной установки и обслуживании программно-аппаратных средств;

· соблюдения правил эксплуатации программно-аппаратных средств пользователями;

· обучения пользователей и обслуживающего персонала перед работой с Системой;

· своевременного и безошибочного администрирования Системы;

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

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

3.1.4. Требования к эргономике и технической эстетике

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

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

· однозначно понимаемое назначение названий пунктов меню (функциональных элементов интерфейса) или их графических изображений;

· группировка элементов интерфейса по функциональному признаку.

· минимизация вертикальной и горизонтальной прокрутки;

· четко сформулированные и понятные пользователю сообщения об ошибках;

· цветовая гамма, выдержанная в спокойных тонах, не раздражающих пользователя;

· корректное отображение сайта на большинстве современных операционных систем и web-браузерах.

3.1.5. Требования к защите информации от несанкционированного доступа

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

1. студент;

2. руководитель;

3. академический руководитель;

4. сотрудник учебного офиса;

5. декан факультета;

6. представитель академического совета;

7. администратор.

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

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

3.1.6. Требования по сохранности информации при авариях

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

Также необходимо создать и регулярно обновлять резервную копию данных. Резервная копия данных и основная БД должны храниться на разных машинах.

3.2. Требования к функциям (задачам), выполняемым системой

Система должна выполнять следующие функции:

· создание заявки с предложением темы курсовой или выпускной квалификационной работы;

· согласование предложения темы работы академическим руководителем;

· выбор студентом или руководителем темы работы с проверкой на перегрузку преподавателя;

· утверждение выбора студента руководителем и академическим руководителем;

· изменение деканом факультета данных о заявках;

· загрузка студентом файла итогового варианта работы и его хранение в Системе;

· разграничение прав пользователей.

3.3. Требования к видам обеспечения

3.3.1. Требования к информационному обеспечению

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

3.3.2. Требования к техническому обеспечению

Система должна включать в себя сервер приложений и сервер БД. Клиентская часть представляет из себя браузер на компьютере пользователя. В таблице А.2 представлены ОС и браузеры, на которых система должна корректно работать.

Требования к серверным частям:

· CPU: Quad Core Xeon L5420 и выше;

· RAM: 16 GB;

· HD: MD (программный) RAID-10 массив, 4x500GB SATA.

Таблица А.2. Поддерживаемые браузеры и ОС

ОС	Браузер	Версии браузера
Windows	Google Chrome	35
	Mozilla Firefox	38
	Opera	18
	Internet Explorer	11
	Microsoft Edge	13
Linux	Google Chrome	35
	Mozilla Firefox	38
	Opera	18
Mac OS	Google Chrome	35
	Mozilla Firefox	38
	Opera	18
	Safari	8

3.3.3. Требования к организационному обеспечению

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

3.3.4. Требования к методическому обеспечению

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

4. Состав и содержание работ по созданию системы

Результаты и сроки выполнения этапов работ представлены в таблице А.3.

Табл. А.3. Этапы работ

№№	Этап работ	Результаты	Срок выполнения
1	Анализ процесса управления выполнением курсовых и выпускных квалификационных работ, формирование требований к ИС	Модели бизнес-процессов «to be», формирование видения системы	1.11.2017-10.04.2018
2	Разработка технического задания	Техническое задание на автоматизированную систему	11.04.2018-15.04.2018
3	Проектирование базы данных	Физическая модель данных	16.04.2018-18.04.2018
4	Описание функциональной и логической структуры ИС, описание алгоритмов работы ИС, проектирование интерфейса приложения	Технический проект ИС	19.04.2018-25.04.2018
5	Разработка ИС в соответствии с техническим проектом	Разработана ИС, реализованы все функции согласно техническому заданию	7 дней
6	Тестирование и отладка	Исправлены ошибки в реализации	2 дня
7	Передача системы Заказчику	Проведены все испытания системы и составлен акт о приемке Системы в постоянную эксплуатацию	58 дней
8	Обучение пользователей	Пользователи обучены	14 дней

5. Порядок контроля и приемки системы

После проведения Разработчиком тестирования и отладки начинается процесс передачи Системы Заказчику. Этапы передачи Системы Заказчику представлены в таблице А.4. Все этапы выполняются на территории Заказчика. В процесс передачи Системы включены все виды испытания автоматизированных систем согласно ГОСТ 34.603-92.

Табл. А.4. Приемка системы

Этап	Описание этапа	Время выполнения
Предварительные испытания Системы	1. Разработчик совместно с заказчиком разрабатывают программу комплексных испытаний и тесты для Системы. 2. Тестирование всех основных функций Системы, проверка надежности и устойчивости системы. 3. Оформление протокола комплексных испытаний.	14 дней
Опытная эксплуатация	1. Разработка программы опытной эксплуатации. 2. Во время опытной эксплуатации АС ведется рабочий журнал, в который заносятся сведения о продолжительности функционирования АС, отказах, сбоях, аварийных ситуациях, изменениях параметров объекта автоматизации, проводимых корректировках документации и программных средств, наладке, технических средств. 3. Оформление акта о завершении опытной эксплуатации и допуске системы к приемочным испытаниям.	21 день
Приемочные испытания	1. Разработка программы приемочных испытаний. 2. Проверка полноты и качества реализации функций Системы. 3. Проверка средств и методов восстановления работоспособности Системы после отказов. 4. Проверка комплектности и качества эксплуатационной документации. 5. Оформление протокола испытаний. 6. Оформление акта о приемке Системы в постоянную эксплуатацию.	21 день

6. Требования к составу и содержанию работ по подготовке объекта автоматизации к вводу системы в действие

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

Размещено на Allbest.ru

...