Отчет по практике специальности «Прикладная математика и информатика»

Практическое задание 3

Задание 3.1. Построить логическую модель программного продукта.

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

Рис. 7 — Логическая модель базы данных

При разработке информационной системы понадобилось создать три основных подсистемы. Четвертая подсистема — это стандартная подсистема «Рабочий стол».

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

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

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

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

Основные пункты меню включают в себя:

•  – абитуриентов;
• – зачисление студентов (документ «Создание приказа»);
• – повышение квалификации сотрудников;
• – добавление успеваемости студентов (подсистема «Учебная часть»);
• – просмотр и печатная форма расписания (подсистема «Учебная часть»);
• – создание расписания (подсистема «Учебная часть»);
• – просмотр расписания (подсистема «Учебная часть»);
• – сохранение параметров при техническом сбое программы.

Задание 3.2. Построить логическую модель базы данных.

Архитектура разрабатываемой информационно-аналитической системы мониторинга успеваемости и посещаемости студентов для ERP системы «Галактика» представлена на рисунке 8.

Рис. 8 – Трехзвенная архитектура информационной системы

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

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

Методология структурного анализа IDEF0 (Function Modeling) используется для создания контекстной диаграммы (функциональное моделирование), которая является структурированным отображением функций производственной системы или среды, информации и объектов, связывающих эти функции.

На рисунке 9 продемонстрирована контекстная диаграмма (функциональная модель) осуществления мониторинга успеваемости студентов, выполненная в методологии структурного анализа и проектирования системы SADT.

На контекстной диаграмме «КАК ЕСТЬ» («AS-IS») представлен основной бизнес-процесс «Осуществить мониторинг успеваемости студентов».

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

Точки зрения: деканат общеобразовательной организации.

Рисунок 9 – Контекстная диаграмма

На вход процесса А-0 поступает потребность в осуществлении мониторинга, виды инструментария и данные на обработку; на выходе из процесса формируются: оценка качества успеваемости студентов и различные виды отчётов. Для выполнения процесса требуются ресурсы и управляющие воздействия, которые осуществляют управление работой и определяют порядок выполнения работ.

Процесс «Мониторинг успеваемости студентов» выделяет выполнение следующих процессов: «Определить цели исследования», «Выбрать инструментарий», «Собрать данные о посещаемости и успеваемости студентов», «Обработать полученные данные», «Проанализировать полученные данные» и «Сформировать отчётность».

На диаграмме (рис. 10) продемонстрирована декомпозиция контекстной диаграммы «AS-IS».

Рисунок 10 – Декомпозиция процесса «Мониторинг успеваемости студентов»

Процесс: А1 – определить цели исследования

Входные данные: Потребность в осуществлении мониторинга. Выходные данные: решения по исследованию.

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

Процесс: А2 – Выбрать инструментарий.

Входные данные: виды инструментария. Выходные данные: выбранный инструментарий.

Алгоритм выполнения: после определения целей исследования начальник управления сопровождения учебным процессом осуществляет выбор инструментария, при помощи которого будет выполнен мониторинг успеваемости студента.

Процесс: А3 – Собрать данные о посещаемости и успеваемости студентов.

Входные данные: данные на обработку. Выходные данные: архив данных.

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

Процесс: А4 – Обработать полученные данные.

Входные данные: архив данные. Выходные данные: обработанные данные.

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

Процесс: А5 – проанализировать полученные данные.

Входные данные: обработанные данные. Выходные данные: проанализированные данные и оценка качества успеваемости студентов.

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

Процесс: А6 – Сформировать отчётность.

Входные данные: оценка качества успеваемости студентов. Выходные данные: сформированные отчёты.

Алгоритм выполнения: после выполнения мониторинга начальник управления сопровождения учебным процессом на основе проанализированных данных формирует лист отчётности.

Анализ осуществления мониторинга успеваемости и посещаемости студентов с использованием структурного моделирования позволил выделить следующие недостатки:

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

Для демонстрации того, как будет применяться автоматизированное решение для обозначенных проблем была предложена функциональная модель «КАК БУДЕТ» («TO BE») – автоматизация мониторинга успеваемости и посещаемости студентов.

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

На рисунке 11 представлена функциональная модель проектируемой информационно-аналитической системы, на которой отображены основные функции проектируемой системы.

Рис. 11 – Функциональная модель проектируемой информационно-аналитической системы

УСУП – управление сопровождения учебного процесса.

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

• — прием заявок;
• — выбор инструментария;
• — сбор данных о посещаемости и успеваемости студентов;
• — обработка полученных данных;
• — анализ полученных данных;
• — формирование отчетов.

На рисунке 12 изображена диаграмма последовательности, на которой отображено взаимодействие объектов, а также обмен сигналами и сообщениями между ними.

Рис. 12 – Диаграмма последовательности управления сопровождения

учебным процессом по осуществлению мониторинга

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

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

Работа с системой ERP Галактика осуществлялась с разработанной тестовой базой данных, однако реальная работа производилась с использованием существующих хранилищ данных.