Методологический план проектирования АИС учета успеваемости студентов ВУЗа: от анализа до оценки эффективности

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

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

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

Теоретические основы и методологии проектирования автоматизированных информационных систем

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

В основе понимания лежит само понятие Автоматизированной информационной системы (АИС) – это организованная совокупность программно-аппаратных средств, объединённых информационными потоками и предназначенная для сбора, хранения, обработки и выдачи информации с целью автоматизации различных процессов. В нашем случае речь идет об автоматизации учета успеваемости студентов. Неотъемлемой частью любой АИС является Система управления базами данных (СУБД) – специализированное программное обеспечение, предназначенное для создания, управления и организации баз данных (БД). Именно СУБД обеспечивает хранение, доступ, управление, а также безопасность и целостность данных, таких как информация о студентах, их оценках и учебных планах.

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

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

Принципы проектирования информационных систем

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

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

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

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

Экономическая целесообразность — это фундаментальное требование, которое означает, что затраты на создание и эксплуатацию АИС должны быть оправданы ожидаемыми выгодами. Принцип однократности ввода направлен на минимизацию ошибок и повышение эффективности: данные должны вводиться в систему только один раз, а затем использоваться во всех необходимых местах. «Дружелюбность» (или юзабилити) означает, что интерфейс должен быть интуитивно понятным и удобным для конечного пользователя, что напрямую влияет на его продуктивность и удовлетворенность.

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

Модели жизненного цикла информационных систем

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

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

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

Итеративная (поэтапная) модель, в отличие от каскадной, предполагает разбиение всего жизненного цикла продукта на ряд отдельных мини-циклов, или итераций. Каждая итерация включает в себя все ключевые этапы: определение и анализ требований (для текущей итерации), дизайн и проектирование, разработку и тестирование, а также фазу ревью. Это позволяет не требовать полного объема требований на начальном этапе, допуская их уточнение и изменение на протяжении итераций.

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

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

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

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

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

Стандарты и регламенты в проектировании ИС

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

Одним из основополагающих национальных стандартов является ГОСТ 34.601-90, который устанавливает стадии и этапы создания автоматизированных систем и содержание работ на каждом из них. Этот стандарт в большей степени соответствует каскадной модели жизненного цикла, предлагая строго последовательный подход. Согласно ГОСТ 34.601-90, процесс создания АС делится на следующие стадии:

• Формирование требований к АС: Инициализация проекта, сбор и анализ требований.
• Разработка концепции АС: Определение основных идей, принципов работы системы.
• Техническое задание (ТЗ): Детальное описание требований к системе, ее функционалу, характеристикам, методам испытаний. Это ключевой документ, регулирующий взаимоотношения между заказчиком и исполнителем.
• Эскизный проект: Разработка предварительных проектных решений, определение общей архитектуры.
• Технический проект: Детальная разработка всех компонентов системы, выбор технологий, проектирование базы данных, интерфейсов.
• Рабочая документация: Создание всех необходимых документов для реализации и эксплуатации системы (программный код, инструкции, методики).
• Ввод в действие: Установка, настройка, тестирование и запуск системы в эксплуатацию.
• Сопровождение АС: Поддержка, обслуживание, устранение ошибок и модернизация системы на протяжении всего ее жизненного цикла.

На международном уровне одним из важнейших документов является ISO/IEC 12207 (1995) — стандарт на процессы и организацию жизненного цикла программных средств. Он является более гибким и универсальным, чем ГОСТ 34.601-90, и может быть адаптирован под различные модели жизненного цикла, включая итеративные и спиральные. В Российской Федерации действует его обновленная версия — ГОСТ Р ИСО/МЭК 12207-2010 «Информационная технология. Системная и программная инженерия. Процессы жизненного цикла программных средств». Этот стандарт заменил ГОСТ Р ИСО/МЭК 12207-99 и устанавливает общую структуру процессов жизненного цикла программных средств, разделяя их на несколько категорий:

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

Важно отметить, что ГОСТ Р ИСО/МЭК 12207-2010 не предписывает определенной модели жизненного цикла системы, методологии или метода разработки, оставляя выбор за пользователями. Это дает гибкость в применении стандарта для различных проектов, включая АИС учета успеваемости, позволяя выбрать наиболее подходящую модель (например, итеративную или спиральную) и адаптировать процессы под ее специфику.

Дополнительно, ГОСТ Р 57193-2016 «Системная и программная инженерия. Процессы жизненного цикла систем» распространяется на полный жизненный цикл системы, от замысла до снятия с эксплуатации, включая процессы приобретения и поставки. Он также не предписывает конкретную модель ЖЦ, что подчеркивает современную тенденцию к гибкости в управлении проектами.

Использование этих стандартов при проектировании АИС учета успеваемости студентов обеспечивает:

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

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

Анализ предметной области и требования к АИС учета успеваемости студентов

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

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

• Избыточность данных: Одна и та же информация (например, ФИО студента) может дублироваться в разных местах, что увеличивает риск ошибок.
• Низкая оперативность: Сбор, обработка и агрегация данных для отчетов занимает много времени.
• Человеческий фактор: Ошибки при ручном вводе данных, неполнота информации.
• Отсутствие единого источника истины: Разные подразделения могут оперировать разными версиями данных.
• Сложность анализа: Из-за разрозненности данных трудно проводить комплексный анализ успеваемости, выявлять тенденции или прогнозировать риски.

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

Функциональные требования к АИС

Функциональные требования определяют, что именно система должна делать. Это своего рода «список возможностей», которые АИС предоставит своим пользователям. Для АИС учета успеваемости студентов в ВУЗе эти функции должны охватывать весь спектр образовательного процесса, связанного с контролем и фиксацией академических достижений.

Основные функциональные требования:

1. Управление контингентом студентов:
   • Добавление, изменение, удаление данных о студентах (ФИО, дата рождения, пол, адрес, контактная информация, гражданство, СНИЛС, номер студенческого билета).
   • Привязка студентов к группам, курсам, факультетам, специальностям.
   • Ведение истории обучения студента (переводы, академические отпуска, отчисления, восстановления).
   • Поиск и фильтрация студентов по различным критериям.
2. Управление контингентом преподавателей:
   • Добавление, изменение, удаление данных о преподавателях (ФИО, должность, ученая степень, кафедра, контактная информация).
   • Назначение преподавателей на дисциплины и учебные группы.
3. Управление учебным планом и дисциплинами:
   • Создание и редактирование списка дисциплин с указанием кода, наименования, количества часов, формы контроля (экзамен, зачет, курсовая работа).
   • Привязка дисциплин к учебным планам по специальностям и курсам.
   • Ведение данных о кафедрах и их структуре.
4. Учет успеваемости студентов:
   • Ввод и редактирование оценок по дисциплинам (баллы, буквенные оценки, «зачет/незачет»).
   • Фиксация результатов промежуточной аттестации (сессии).
   • Учет посещаемости занятий (по желанию).
   • Ведение журнала успеваемости по группам и дисциплинам.
5. Управление движением контингента:
   • Автоматизированное формирование приказов о зачислении, отчислении, переводе, предоставлении академического отпуска.
   • Отслеживание изменений статуса студента.
6. Формирование отчетов и статистики:
   • Формирование списков неуспевающих студентов по группам, курсам, дисциплинам.
   • Создание ведомостей успеваемости.
   • Генерация зачетных книжек и дипломов.
   • Составление статистических отчетов по успеваемости (средний балл, процент успеваемости).
   • Формирование отчетности для внутренних нужд ВУЗа (например, для деканатов, учебной части) и внешних органов (Минобрнауки).
   • Возможность экспорта отчетов в различные форматы (PDF, Excel).
7. Управление доступом:
   • Разграничение прав доступа для различных ролей пользователей (администратор, преподаватель, студент, сотрудник деканата).
   • Аутентификация и авторизация пользователей.

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

Нефункциональные требования к АИС (с детализацией «слепых зон»)

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

1. Надежность:
   • Устойчивость работы: Система должна обеспечивать бесперебойное функционирование.
     • Метрика: Процент доступности (Uptime) системы не менее 99,8% в течение рабочего времени (8:00-20:00). Это означает, что суммарное время простоя системы не должно превышать 1 час 26 минут в месяц.
     • Метрика: Среднее время восстановления после сбоя (MTTR — Mean Time To Recovery) не более 30 минут для критически важных функций.
   • Контроль ошибочности вводимых данных: Система должна предотвращать ввод некорректных или неполных данных.
     • Метрика: Количество ошибок валидации данных, обнаруженных системой, должно быть снижено на 95% по сравнению с ручным вводом.
     • Метрика: Процент некорректно введенных данных (по результатам аудита) не должен превышать 0,1%.
2. Производительность:
   • Скорость обработки данных и быстрота поиска: Система должна оперативно реагировать на запросы пользователей.
     • Метрика: Время ответа на стандартный поисковый запрос (например, поиск студента по ФИО, просмотр оценок группы) не должно превышать 1 секунды при одновременной работе до 100 пользователей.
     • Метрика: Время загрузки страницы с данными о сессии для группы из 25 студентов не должно превышать 2 секунд.
     • Метрика: Способность обрабатывать до 1000 транзакций в секунду (например, ввод оценки, изменение статуса студента) при пиковой нагрузке.
3. Масштабируемость: Система должна быть способна эффективно обрабатывать возрастающие объемы данных и количество пользователей без существенной потери производительности.
   • Метрика: Поддержка до 50000 студентов и 5000 преподавателей с возможностью увеличения этих показателей в 2 раза в течение 3 лет.
   • Метрика: Способность обслуживать до 500 одновременных пользователей с сохранением заявленной производительности.
4. Безопасность: Ключевые принципы функционирования систем – обеспечение конфиденциальности, целостности, доступности информации.
   • Конфиденциальность: Гарантирует, что доступ к информации имеют только авторизованные пользователи и процессы.
     • Метрика: Использование ролевой модели доступа с не менее чем 5 уровнями детализации прав.
     • Метрика: Применение алгоритмов шифрования данных при их передаче и хранении (например, TLS 1.2+ для сетевого трафика, AES-256 для критически важных данных в БД).
   • Целостность: Информация должна быть актуальной, правильной и полной, предотвращая несанкционированное искажение, модификацию или уничтожение данных.
     • Метрика: Внедрение механизмов контроля версий для критически важных документов.
     • Метрика: Использование транзакций БД для обеспечения атомарности операций.
     • Метрика: Ведение журнала аудита всех операций модификации данных с сохранением информации о пользователе, времени и изменении.
   • Доступность: Обеспечивает возможность авторизованным пользователям получить доступ к информации по требованию.
     • Метрика: Резервное копирование данных должно производиться ежедневно с возможностью восстановления данных за последний час.
     • Метрика: Наличие механизмов отказоустойчивости на уровне сервера БД и приложений.
5. Удобство использования (Юзабилити): Интуитивно понятный и простой интерфейс.
   • Метрика: Время обучения нового пользователя работе с основными функциями системы не более 2 часов.
   • Метрика: Уровень удовлетворенности пользователей (по результатам опросов) не менее 85%.
   • Метрика: Количество кликов для выполнения типовой задачи (например, выставление оценки студенту) не более 3.
6. Сопровождаемость: Легкость поддержки, отладки и модификации системы.
   • Метрика: Наличие актуальной технической документации.
   • Метрика: Модульная архитектура, позволяющая вносить изменения в отдельные компоненты без нарушения работы всей системы.
7. Переносимость: Возможность переноса системы на другую аппаратную или программную платформу.
   • Метрика: Поддержка нескольких операционных систем для развертывания сервера или использование контейнеризации (Docker).

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

Формирование технического задания

Техническое задание (ТЗ) — это фундаментальный документ, который служит мостом между заказчиком и разработчиком, четко определяя объем, функционал, требования к качеству и условия создания автоматизированной информационной системы. Без хорошо проработанного ТЗ проект рискует столкнуться с недопониманием, изменениями на поздних стадиях и, как следствие, с превышением бюджета и сроков. В Российской Федерации структура и содержание ТЗ на автоматизированные системы регламентируется ГОСТ 34.602-89.

Структура технического задания согласно ГОСТ 34.602-89 включает следующие разделы, каждый из которых должен быть максимально детализирован:

1. Общие положения:
   • Полное наименование системы и ее условное обозначение.
   • Основания для разработки АИС (например, приказ ректора, решение ученого совета, текущие проблемы).
   • Наименование и реквизиты организаций-заказчика и разработчика.
   • Плановые сроки начала и окончания работ по созданию системы.
   • Источники и порядок финансирования.
   • Порядок оформления и предъявления заказчику результатов работ.
   • Перечень документации, подлежащей разработке.
2. Назначение и цели создания системы:
   • Назначение: Описание основной функции системы (например, автоматизация процессов учета успеваемости, анализа академической деятельности, управления контингентом студентов).
   • Цели: Четко сформулированные результаты, которые должны быть достигнуты за счет внедрения АИС. Например, «повышение оперативности получения отчетов на 80%», «сокращение ручного труда на 50%», «обеспечение единой базы данных успеваемости». Цели должны быть SMART (Specific, Measurable, Achievable, Relevant, Time-bound).
3. Характеристика объекта автоматизации:
   • Описание текущего состояния предметной области (процессов учета успеваемости, документооборота, используемых инструментов).
   • Выявление проблем и «узких мест» в существующих процессах.
   • Описание организационной структуры ВУЗа, подразделений, которые будут пользоваться АИС.
   • Определение границ системы (что будет автоматизировано, а что нет).
4. Требования к системе:
   • Требования к функциональным возможностям: Детальное описание всех функций, которые должна выполнять система, как это было изложено в предыдущем разделе (ведение учета, формирование отчетов, управление доступом и т.д.). Каждая функция должна быть описана с точки зрения пользователя.
   • Требования к надежности: Устойчивость работы, контроль ошибок, механизмы восстановления.
   • Требования к производительности: Время отклика, пропускная способность, масштабируемость.
   • Требования к безопасности: Конфиденциальность, целостность, доступность данных, защита от несанкционированного доступа. Должно быть указано соответствие ФЗ №152-ФЗ.
   • Требования к эргономике и юзабилити: Удобство использования, интуитивно понятный интерфейс, минимизация утомляемости.
   • Требования к составу и параметрам технических средств: Типы серверов, рабочих станций, сетевое оборудование.
   • Требования к программному обеспечению: Операционные системы, СУБД, языки программирования, сторонние библиотеки.
   • Требования к информационному обеспечению: Структура базы данных, справочники, классификаторы, форматы ввода/вывода данных.
   • Требования к лингвистическому обеспечению: Используемые языки (русский, английский), терминология.
   • Требования к методическому обеспечению: Инструкции пользователя, администратора, методики обучения.
   • Требования к организации взаимодействия с другими системами: Описание интерфейсов для интеграции с внешними системами (например, система управления контингентом ВУЗа, 1С, ФГИС «Моя школа»).
5. Состав и содержание работ по созданию системы:
   • Перечень стадий и этапов работ в соответствии с выбранной моделью ЖЦ ИС (например, ГОСТ 34.601-90).
   • Описание содержания работ на каждом этапе, их результаты.
6. Порядок контроля и приемки системы:
   • Виды, состав, объем и методы испытаний (автономные, комплексные, опытная эксплуатация).
   • Критерии приемки.
   • Порядок устранения замечаний.
7. Требования к составу и содержанию документации:
   • Перечень всех документов, которые должны быть разработаны на каждом этапе.
8. Требования к подготовке персонала:
   • Описание программ обучения пользователей и администраторов системы.
9. Требования к гарантийному и постгарантийному обслуживанию:
   • Условия поддержки, сроки устранения ошибок.
10. Источники разработки:
    • Перечень документов, использованных при разработке ТЗ (стандарты, методические указания, аналоги).

Тщательное формирование каждого раздела ТЗ на основе ГОСТ 34.602-89 обеспечит прозрачность, управляемость и предсказуемость проекта, став надежной основой для последующего проектирования и реализации АИС учета успеваемости.

Архитектурные решения и моделирование данных для АИС

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

Архитектурные решения информационных систем рассматривают теоретические и практические вопросы их построения с позиций системного подхода. Архитектура информационной системы — это совокупность программно-технических, информационных и организационных решений, определяющих общую структуру и принципы функционирования системы. В современных ИТ-системах, особенно ориентированных на работу со знаниями, иногда выделяют архитектуру знаний (Knowledge Architecture), которая представляет собой отдельный тип архитектуры, сосредоточенный на структурировании, хранении и управлении знаниями внутри системы, что может быть актуально для систем, предоставляющих аналитику по успеваемости.

Архитектура информационных систем учета успеваемости

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

1. Двухуровневая клиент-серверная архитектура:
   • Описание: Клиентское приложение напрямую взаимодействует с сервером базы данных. Клиент выполняет логику приложения и пользовательский интерфейс, а сервер базы данных — хранение и обработку данных.
   • Применимость: Простые системы с небольшим количеством пользователей, где нет высоких требований к масштабируемости и гибкости.
   • Преимущества: Относительная простота разработки и развертывания, высокая производительность для небольших нагрузок.
   • Недостатки: Плохая масштабируемость (каждый клиент требует отдельного соединения с СУБД), сложность обновления клиентских приложений, высокая нагрузка на сервер СУБД при росте числа клиентов.
2. Многоуровневая (трехуровневая и более) архитектура:
   • Описание: Между клиентским приложением и сервером базы данных добавляется один или несколько промежуточных слоев (например, сервер приложений, бизнес-логика).
     • Уровень представления (клиентский): Пользовательский интерфейс (веб-браузер, десктопное приложение).
     • Уровень бизнес-логики (сервер приложений): Обрабатывает запросы клиента, реализует бизнес-правила, взаимодействует с уровнем данных.
     • Уровень данных: Сервер базы данных, хранящий информацию.
   • Применимость: Большинство современных корпоративных систем, включая АИС учета успеваемости, где требуется высокая масштабируемость, надежность, гибкость и централизованное управление бизнес-логикой.
   • Преимущества: Отличная масштабируемость (серверы приложений могут быть кластеризованы), гибкость (можно менять клиентскую часть или СУБД без изменения бизнес-логики), централизованное управление бизнес-правилами, улучшенная безопасность.
   • Недостатки: Усложнение архитектуры, более высокие требования к разработке и администрированию.
3. Облачная архитектура:
   • Описание: Система разворачивается и функционирует на базе облачных платформ (например, Amazon Web Services, Microsoft Azure, Google Cloud Platform). Это может быть Infrastructure as a Service (IaaS), Platform as a Service (PaaS) или Software as a Service (SaaS).
   • Применимость: Современные АИС, которые требуют высокой доступности, гибкой масштабируемости, глобального доступа и минимизации затрат на собственную инфраструктуру.
   • Преимущества: Автоматическое масштабирование, высокая доступность, оплата по мере использования, снижение затрат на аппаратное обеспечение и администрирование, быстрая разработка.
   • Недостатки: Зависимость от облачного провайдера, потенциальные вопросы безопасности и конфиденциальности данных (особенно для персональных данных), необходимость постоянного доступа к интернету.

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

Интеграция приложений является важной частью архитектуры. АИС учета успеваемости может потребоваться интегрировать с другими системами ВУЗа, такими как система управления контингентом, библиотечная система, портал студента и ФГИС «Моя школа». Это достигается через API (Application Programming Interface), общие шины данных (ESB — Enterprise Service Bus) или другие механизмы обмена данными.

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

Инфологическое и даталогическое проектирование базы данных

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

Инфологическое проектирование фокусируется на концептуальной модели данных, независимой от конкретной СУБД. Его цель – определить ключевые сущности предметной области, их атрибуты и взаимосвязи. Основным инструментом здесь является ER-диаграмма (Сущность-Связь). Это визуальная модель, отображающая взаимосвязи между ключевыми сущностями системы управления учебным заведением.

Для базы данных успеваемости студентов ВУЗа можно выделить следующие основные сущности и их атрибуты:

• Студенты:
  • Атрибуты: КодСтудента (первичный ключ), Фамилия, Имя, Отчество, ДатаРождения, Пол, АдресПрописки, Телефон, Email, НомерЗачетки, ДатаЗачисления, Статус (обучается, отчислен, в академ. отпуске), КодГруппы (внешний ключ).
• Группы:
  • Атрибуты: КодГруппы (первичный ключ), НазваниеГруппы (например, «ПИ-21»), Курс, Семестр, КодСпециальности (внешний ключ), ГодНачалаОбучения.
• Специальности:
  • Атрибуты: КодСпециальности (первичный ключ), НазваниеСпециальности, КодКафедры (внешний ключ), ШифрСпециальности.
• Кафедры:
  • Атрибуты: КодКафедры (первичный ключ), НазваниеКафедры, ЗаведующийКафедрой.
• Дисциплины:
  • Атрибуты: КодДисциплины (первичный ключ), НазваниеДисциплины, КоличествоЧасов, ФормаКонтроля (экзамен, зачет, курсовая работа), КодКафедры (внешний ключ).
• Преподаватели:
  • Атрибуты: КодПреподавателя (первичный ключ), Фамилия, Имя, Отчество, Должность, Ученая Степень, КодКафедры (внешний ключ).
• НазначенияДисциплин (для связывания преподавателей и групп с дисциплинами):
  • Атрибуты: КодНазначения (первичный ключ), КодДисциплины (внешний ключ), КодГруппы (внешний ключ), КодПреподавателя (внешний ключ), Семестр, УчебныйГод.
• Оценки:
  • Атрибуты: КодОценки (первичный ключ), КодСтудента (внешний ключ), КодНазначения (внешний ключ), ЗначениеОценки (например, 5, 4, 3, 2, «Зач», «Незач»), ДатаВыставления.

Пример ER-диаграммы (упрощенная)

erDiagram
    Студенты ||--o{ Группы : "состоит в"
    Группы ||--o{ Специальности : "обучается по"
    Специальности ||--o{ Кафедры : "относится к"
    Преподаватели ||--o{ Кафедры : "работает на"
    Дисциплины ||--o{ Кафедры : "преподается на"
    Студенты }|--|{ Оценки : "получает"
    НазначенияДисциплин }|--|| Дисциплины : "включает"
    НазначенияДисциплин }|--|| Группы : "преподается в"
    НазначенияДисциплин }|--|| Преподаватели : "ведет"
    Оценки }|--|| НазначенияДисциплин : "выставляется по"

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

Основные формы нормализации:

• Первая нормальная форма (1НФ): Каждый атрибут содержит атомарные значения, и в таблице нет повторяющихся групп атрибутов.
• Вторая нормальная форма (2НФ): Находится в 1НФ, и каждый неключевой атрибут полностью зависит от первичного ключа.
• Третья нормальная форма (3НФ): Находится во 2НФ, и отсутствуют транзитивные зависимости (неключевые атрибуты не зависят от других неключевых атрибутов).
• Бойса-Кодда нормальная форма (БКНФ): Более строгая версия 3НФ, где каждая нетривиальная функциональная зависимость X → Y имеет X в качестве суперключа.

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

Выбор технологического стека и системных компонентов

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

Системы управления базами данных (СУБД)

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

Основные функции СУБД включают:

• Управление данными во внешней и оперативной памяти.
• Журнализацию изменений для отката операций и восстановления после сбоев.
• Резервное копирование и восстановление данных.
• Поддержку языков баз данных (например, SQL).
• Управление доступом и безопасностью.

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

Классификация СУБД может осуществляться по нескольким признакам:

• По модели данных:
  • Иерархические: Данные организованы в древовидную структуру (родитель-потомок).
  • Сетевые: Более гибкие связи, чем в иерархических, позволяющие одному потомку иметь несколько родителей.
  • Реляционные (РСУБД): Наиболее распространенная модель, где данные организованы в таблицы (отношения), каждая строка которых представляет собой отдельную запись (кортеж), а столбцы — атрибуты. Реляционные СУБД управляют такими базами данных, обеспечивая согласованный интерфейс для приложений и пользователей.
  • Объектно-ориентированные: Хранят данные в виде объектов, аналогично объектам в объектно-ориентированных языках программирования.
  • Объектно-реляционные: Гибридный подход, сочетающий реляционную модель с элементами объектно-ориентированной.
• По степени распределённости:
  • Локальные: Все данные хранятся на одном сервере.
  • Распределённые: Данные распределены по нескольким серверам или узлам (например, MongoDB).

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

Сравнительный анализ реляционных СУБД:

Критерий	MySQL	PostgreSQL	MS SQL Server	Oracle Database
Лицензия	Dual (GPL/Proprietary)	BSD (Open Source)	Proprietary	Proprietary
Производительность	Высокая для простых запросов, веб-приложений.	Высокая, особенно для сложных запросов и аналитики.	Очень высокая для корпоративных нагрузок.	Выдающаяся для высоконагруженных корпоративных систем.
Масштабируемость	Хорошая, но с ограничениями на горизонтальное масштабирование.	Отличная, поддерживает репликацию, партиционирование.	Отличная, для очень больших данных и кластеров.	Лучшая в отрасли, для крупных корпораций.
Функционал	Базовый, но достаточный для большинства веб-приложений.	Расширенный, поддержка JSON, GIS, хранимых процедур, триггеров.	Полный набор функций для корпоративных нужд, OLAP, BI.	Самый полный, с расширенными возможностями безопасности, аналитики, HA.
Сообщество/Поддержка	Огромное сообщество, коммерческая поддержка Oracle.	Активное Open Source сообщество, множество сторонних компаний.	Коммерческая поддержка Microsoft, обширная документация.	Лидер коммерческой поддержки, стандарты отрасли.
Стоимость	Низкая (Community Edition) / Высокая (Enterprise).	Бесплатно.	Высокая.	Очень высокая.
Сложность администрирования	Относительно низкая.	Средняя.	Средняя.	Высокая.

Обоснование выбора оптимальной СУБД для АИС учета успеваемости:

Учитывая целевую аудиторию (студент ВУЗа, разрабатывающий курсовую работу), потребность в масштабируемости (ВУЗ может иметь десятки тысяч студентов), функциональности и стоимости, PostgreSQL является оптимальным выбором.

• Открытый исходный код (Open Source) и бесплатность: Это значительно снижает барьер входа для студента, исключая необходимость приобретения дорогих лицензий.
• Богатый функционал: PostgreSQL предлагает широкий набор возможностей, включая поддержку хранимых процедур, триггеров, сложных типов данных (например, JSONB), что позволяет реализовать гибкую и мощную систему.
• Высокая надежность и целостность данных: Известен своей стабильностью и строгим соответствием стандартам SQL.
• Хорошая масштабируемость: Подходит для работы с большим объемом данных и значительным количеством пользователей, что соответствует потребностям крупного ВУЗа.
• Активное сообщество: Наличие обширной документации и большого сообщества разработчиков облегчает поиск решений и поддержку.

Хотя MySQL также является популярным выбором, его лицензионная политика может быть менее прозрачной для коммерческого использования, а функционал PostgreSQL часто превосходит его в области работы со сложными данными и аналитикой. MS SQL Server и Oracle, будучи мощными корпоративными решениями, не подходят из-за высокой стоимости лицензий и более сложного администрирования, что нецелесообразно для курсовой работы.

Языки программирования и фреймворки

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

Для бэкенда (серверной части):

Язык/Фреймворк	Описание	Преимущества	Недостатки	Применимость для АИС
Python / Django, Flask	Python — высокоуровневый язык общего назначения. Django — мощный full-stack фреймворк для быстрой разработки веб-приложений. Flask — легковесный микрофреймворк.	Высокая скорость разработки, богатая экосистема библиотек, читаемый код, подходит для ML/AI.	Меньшая производительность по сравнению с Java/C# на высоконагруженных системах.	Отличный выбор для АИС: быстрая разработка, хорошая масштабируемость, поддержка PostgreSQL.
Java / Spring	Java — объектно-ориентированный, платформенно-независимый язык. Spring — мощный и гибкий фреймворк для корпоративных приложений.	Высокая производительность, надежность, широкое применение в энтерпрайзе, огромная экосистема.	Более сложный синтаксис, длительное время разработки для небольших проектов.	Хороший выбор для крупных корпоративных АИС, но может быть избыточен для курсовой.
C# / .NET	C# — объектно-ориентированный язык от Microsoft. .NET — платформа для разработки широкого спектра приложений.	Интеграция с экосистемой Microsoft, высокая производительность, богатый набор инструментов.	Зависимость от Microsoft (хотя .NET Core кроссплатформенный), иногда более высокая стоимость лицензий.	Подходит для корпоративных систем на базе технологий Microsoft.
PHP / Laravel, Symfony	PHP — скриптовый язык, широко используемый для веб-разработки. Laravel, Symfony — популярные фреймворки.	Простота изучения, огромное количество хостингов, быстрая разработка для веб.	Производительность может быть ниже, чем у Java/C#.	Подходит для веб-ориентированных АИС, но может уступать Python/Java в масштабе.

Для фронтенда (клиентской части):

Язык/Фреймворк	Описание	Преимущества	Недостатки	Применимость для АИС
JavaScript / React, Angular, Vue.js	JavaScript — основной язык веб-разработки. React (библиотека), Angular (фреймворк), Vue.js (фреймворк) — лидеры для создания SPA (Single Page Applications) и интерактивных интерфейсов.	Высокая интерактивность, динамичный UI, кроссбраузерность, огромное сообщество.	Сложность освоения для новичков (особенно Angular), быстрые изменения технологий.	Отличный выбор для современного веб-интерфейса АИС: обеспечивает эргономичность, скорость, отзывчивость.

Обоснование выбора:

Для курсовой работы по проектированию АИС учета успеваемости студентов целесообразно выбрать следующую связку:

• Бэкенд: Python с фреймворком Django. Это позволит быстро реализовать бизнес-логику, эффективно работать с базой данных (PostgreSQL) благодаря ORM (Object-Relational Mapping) Django и использовать обширную экосистему Python для, например, аналитических модулей.
• Фронтенд: JavaScript с библиотекой React. React известен своей компонентной архитектурой, что упрощает разработку сложных и интерактивных пользовательских интерфейсов, обеспечивая высокую отзывчивость и производительность, что напрямую влияет на эргономику системы.

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

Аппаратное и программное обеспечение

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

1. Требования к серверному оборудованию:
Для развертывания АИС учета успеваемости, особенно если она ориентирована на средний или крупный ВУЗ, потребуется высокопроизводительное серверное оборудование.

• Процессор: Многоядерные серверные процессоры. Например, Intel Xeon E5/E7 или AMD EPYC (от 8 ядер и выше). Выбор конкретной модели зависит от ожидаемой пиковой нагрузки и количества одновременно работающих пользователей.
• Оперативная память (ОЗУ): Значительный объем оперативной памяти критически важен для производительности СУБД и сервера приложений. Рекомендуется от 32 ГБ и выше, с возможностью наращивания. Для очень больших ВУЗов или систем с расширенной аналитикой может потребоваться 64 ГБ и более.
• Накопители: Для обеспечения высокой скорости работы базы данных необходимы быстрые накопители.
  • SSD (Solid State Drive) или NVMe: Для хранения самой базы данных и системных файлов. Они обеспечивают высокую скорость чтения/записи, что критически важно для производительности СУБД.
  • RAID-массив: Для повышения надежности хранения данных и производительности. Рекомендуется RAID 10 или RAID 5.
  • Объем: Объем дискового пространства должен быть рассчитан с учетом текущих данных, прогнозируемого роста в течение 5-10 лет, а также места для резервных копий и журналов. Например, от 1 ТБ для SSD/NVMe.
• Сетевое оборудование: Высокоскоростные сетевые адаптеры (1 Гбит/с или 10 Гбит/с) для обеспечения быстрого обмена данными между сервером и клиентами, а также с другими внутренними и внешними системами.
• Отказоустойчивость: Для критически важной системы желательны решения для обеспечения отказоустойчивости:
  • Резервные блоки питания (Hot-Swap Power Supplies).
  • Дисковые массивы с горячей заменой (Hot-Swap Drives).
  • Возможность кластеризации серверов баз данных и приложений для обеспечения непрерывной работы.

2. Требования к программному обеспечению сервера:

• Операционная система (ОС): Стабильная и безопасная серверная ОС.
  • Linux-дистрибутивы: Ubuntu Server, CentOS, Debian (предпочтительны из-за открытого исходного кода, безопасности и широкой поддержки).
  • Windows Server: Например, Windows Server 2019/2022 (если в экосистеме ВУЗа преобладают технологии Microsoft).
• СУБД: Установленная и настроенная СУБД (например, PostgreSQL актуальной версии).
• Среда выполнения и веб-сервер: Python Runtime Environment, Django/Flask, веб-сервер (Nginx или Apache) и WSGI-сервер (Gunicorn или uWSGI) для развертывания веб-приложения.

3. Требования к клиентским рабочим станциям:
Поскольку мы ориентируемся на веб-приложение («ультратонкий клиент»), требования к клиентским машинам будут минимальными.

• Процессор: Современные процессоры (например, Intel Core i5/i7, AMD Ryzen 5/7) для комфортной работы с браузером.
• Оперативная память (ОЗУ): Не менее 8-16 ГБ оперативной памяти для обеспечения достаточной производительности веб-браузера и многозадачности.
• Накопитель: Твердотельные накопители (SSD) значительно улучшат общую скорость работы системы.
• Операционная система: Актуальные версии клиентских операционных систем (Windows 10/11, macOS, различные дистрибутивы Linux).
• Веб-браузер: Современный веб-браузер (Google Chrome, Mozilla Firefox, Microsoft Edge) с поддержкой актуальных веб-стандартов.

4. Требования к сетевой инфраструктуре:

• Стабильное и высокоскоростное интернет-соединение для доступа к веб-приложению.
• Наличие локальной сети с достаточной пропускной способностью для внутреннего использования АИС.

Такая детализация требований к аппаратному и программному обеспечению позволяет создать надежную, производительную и безопасную основу для АИС учета успеваемости, способную удовлетворить потребности современного ВУЗа.

Проектирование пользовательского интерфейса и обеспечение эффективного взаимодействия

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

Основы инженерной психологии и эргономики в дизайне ИС

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

Низкая эффективность взаимодействия проявляется в ряде негативных последствий:

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

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

1. Простота и интуитивность: Интерфейс должен быть понятен без длительного обучения. Используйте общепринятые иконки, термины, шаблоны взаимодействия.
2. Последовательность: Однотипные операции должны выполняться одинаково, элементы управления должны быть расположены в предсказуемых местах.
3. Обратная связь: Система должна всегда информировать пользователя о своих действиях (например, «данные сохранены», «загрузка…»).
4. Толерантность к ошибкам: Предотвращение ошибок (например, через валидацию ввода), возможность отмены действий, понятные сообщения об ошибках с предложениями по их исправлению.
5. Настраиваемость: Возможность адаптации интерфейса под индивидуальные предпочтения пользователя (например, изменение размера шрифта, темы).
6. Эстетика: Приятный внешний вид, гармоничное сочетание цветов, шрифтов и элементов.
7. Минимализм: Отсутствие лишних элементов, которые отвлекают внимание или не несут функциональной нагрузки.

При проектировании интерфейса АИС учета успеваемости необходимо учитывать возможности, ограничения, предпочтения и ожидания различных категорий пользователей (студенты, преподаватели, сотрудники деканата, администраторы). Например, интерфейс для студента может быть более упрощенным и ориентированным на просмотр информации, тогда как для преподавателя потребуется более сложный функционал для ввода оценок и формирования ведомостей. Отвечает ли текущая реализация интерфейсов ожиданиям пользователей, и как оценить это на практике?

Эффективностная модель интерфейса взаимодействия

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

1. Результативность (как качество решения задачи):
   • Отражает, насколько точно и полно пользователь достигает поставленной цели, используя систему.
   • Примеры метрик:
     • Процент успешно выполненных задач (например, корректно введенные оценки, сформированные отчеты).
     • Количество ошибок, допущенных пользователем при выполнении типовой задачи.
     • Качество сформированных отчетов (например, отсутствие неверных данных, соответствие формату).
2. Оперативность (как скорость такого решения):
   • Характеризует, насколько быстро пользователь может выполнить задачу, используя интерфейс системы.
   • Примеры метрик:
     • Среднее время выполнения типовой задачи (например, время на выставление всех оценок по одной группе, время на поиск информации о студенте).
     • Количество кликов, необходимых для выполнения задачи.
     • Время отклика системы на действия пользователя.
3. Ресурсоэкономность (как сохранность пользователем затрачиваемых на решение ресурсов):
   • Оценивает, сколько умственных, физических и временных ресурсов тратит пользователь на взаимодействие с системой. Это включает в себя уровень утомляемости, когнитивную нагрузку и необходимость в дополнительном обучении.
   • Примеры метрик:
     • Субъективная оценка пользователя по шкале усилий/сложности (например, от 1 до 5, где 1 — очень легко, 5 — очень сложно).
     • Количество запросов в службу поддержки по вопросам использования интерфейса.
     • Время, затраченное на обучение нового пользователя.
     • Оценка уровня стресса или утомляемости пользователя (может быть получена через опросы).

Пример применения модели для АИС учета успеваемости:
Предположим, мы анализируем функцию «Ввод оценок за сессию».

• Результативность: 99% оценок введены корректно, 0 ошибок валидации.
• Оперативность: Среднее время ввода оценок для группы из 25 студентов — 5 минут. Количество кликов для ввода одной оценки — 2.
• Ресурсоэкономность: Средняя субъективная оценка сложности использования — 2 из 5. Количество обращений преподавателей с вопросами по вводу оценок за месяц — 0.

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

Типы пользовательских программных компонентов

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

1. «Тонкий клиент»:
   • Описание: Это клиентское приложение, в котором большая часть обработки данных и логики приложения выполняется на сервере. Клиентская часть отвечает преимущественно за ввод информации (отправку запросов на сервер) и вывод информации (отображение результатов, полученных от сервера). Сам тонкий клиент может быть как десктопным приложением, так и специализированным терминалом.
   • Преимущества:
     • Централизованное управление: Легче администрировать и обновлять, так как основная логика находится на сервере.
     • Низкие требования к ресурсам клиента: Клиентские машины могут быть менее мощными.
     • Повышенная безопасность: Дан данные не хранятся на клиентских машинах, что снижает риски утечек.
   • Недостатки:
     • Зависимость от сетевого соединения.
     • Возможная задержка при взаимодействии из-за сетевых задержек.
     • Может потребовать установки специализированного ПО на каждом клиентском компьютере.
   • Применимость для АИС: Мог бы использоваться в интранет-среде ВУЗа для сотрудников (деканат, учебная часть), где требуется более сложный функционал и контроль над клиентской средой.
2. «Ультратонкий клиент» (веб-приложение):
   • Описание: Это вариант тонкого клиента, доступ к которому осуществляется через стандартный веб-браузер. Вся логика и данные находятся на сервере, а браузер выступает в роли универсального клиента, отображая HTML-страницы, обрабатывая JavaScript и отправляя запросы на сервер по HTTP/HTTPS.
   • Преимущества:
     • Максимальная простота развертывания: Не требует установки никакого специализированного ПО на стороне клиента, достаточно веб-браузера.
     • Кроссплатформенность: Доступен с любого устройства и операционной системы, поддерживающей веб-браузер (ПК, ноутбуки, планшеты, смартфоны).
     • Легкость обновления: Обновления разворачиваются только на сервере, мгновенно становясь доступными всем пользователям.
     • Широкий доступ: Доступ из любой точки мира при наличии интернет-соединения.
   • Недостатки:
     • Более высокие требования к скорости и стабильности интернет-соединения.
     • Ограничения функционала по сравнению с нативными десктопными приложениями (хотя современные веб-технологии позволяют создавать очень сложные и функциональные веб-приложения).
     • Потенциально более высокая нагрузка на сервер из-за большего количества HTTP-запросов.
   • Применимость для АИС: Является наиболее предпочтительным вариантом для АИС учета успеваемости студентов. Это обеспечит максимальную доступность для всех категорий пользователей (студентов, преподавателей, администрации), минимизирует затраты на развертывание и поддержку клиентских рабочих мест, а также упростит процесс обновления системы.

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

Правовые аспекты и стандарты в создании АИС учета успеваемости

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

Защита персональных данных

Одним из ключевых нормативных актов, регулирующих обработку и защиту персональных данных в любых информационных системах, включая АИС в сфере образования, является Федеральный закон от 27 июля 2006 г. № 152-ФЗ «О персональных данных». Этот закон определяет понятие персональных данных, устанавливает принципы и условия их обработки, а также права субъектов персональных данных и обязанности операторов.

Ключевые требования ФЗ №152-ФЗ, которые необходимо учесть при проектировании АИС учета успеваемости:

1. Принципы обработки данных:
   • Законность и справедливость: Обработка данных должна осуществляться на законной и справедливой основе.
   • Целевое назначение: Данные должны собираться для конкретных, заранее определенных и законных целей. АИС должна использоваться строго для учета успеваемости и сопутствующих образовательных процессов.
   • Соразмерность: Объем и характер обрабатываемых данных должны соответствовать заявленным целям обработки. Нельзя собирать избыточную информацию.
   • Достоверность: Обеспечение точности и актуальности персональных данных.
   • Ограничение хранения: Хранение данных должно осуществляться не дольше, чем этого требуют цели обработки.
   • Конфиденциальность: Оператор обязан обеспечить конфиденциальность персональных данных, кроме случаев обезличивания или публичного доступа по закону.
2. Согласие субъекта персональных данных: Обработка персональных данных (например, ФИО, даты рождения, оценок студентов) по общему правилу возможна только с согласия субъекта. В контексте ВУЗа это может быть предусмотрено договором на оказание образовательных услуг или отдельным согласием.
3. Обязанности оператора (ВУЗа, как владельца АИС):
   • Назначение ответственного за организацию обработки персональных данных.
   • Издание локальных актов, определяющих политику в отношении обработки персональных данных.
   • Принятие правовых, организационных и технических мер для защиты персональных данных (например, разграничение прав доступа, шифрование, антивирусная защита, физическая защита серверов).
   • Уведомление уполномоченного органа по защите прав субъектов персональных данных (Роскомнадзора) о своем намерении осуществлять обработку персональных данных.
   • Обеспечение регистрации и учета всех действий с персональными данными.
4. Трансграничная передача данных: Если планируется передача данных за пределы РФ (например, при использовании облачных сервисов иностранных провайдеров), необходимо соблюдать дополнительные требования, включая получение согласия субъекта и проверку соответствия законодательства иностранного государства.

При проектировании АИС учета успеваемости необходимо заложить механизмы, обеспечивающие выполнение этих требований:

• Ролевая модель доступа: Строгое разграничение прав доступа к различным категориям данных в зависимости от роли пользователя (студент видит свои оценки, преподаватель — оценки своих групп, сотрудник деканата — оценки факультета).
• Аудит действий: Ведение журналов (логов) всех операций с персональными данными: кто, когда, что изменил/просмотрел.
• Шифрование: Использование шифрования данных при их передаче (по протоколу HTTPS) и, возможно, при хранении особо чувствительной информации.
• Резервное копирование: Регулярное резервное копирование данных с обеспечением их конфиденциальности и целостности при хранении резервных копий.
• Обезличивание данных: Возможность обезличивания данных для статистического анализа и отчетности, когда индивидуальная идентификация субъекта не требуется.

Государственные информационные системы в образовании

Помимо общих требований к защите персональных данных, информационные системы в сфере образования регулируются специальными законодательными актами. Федеральный закон «Об образовании в Российской Федерации» (от 29 декабря 2012 г., статья 98) регулирует создание, формирование и ведение государственных информационных систем в системе образования. Этот закон устанавливает, что ведение таких систем осуществляется в соответствии с едиными организационными, методологическими и программно-техническими принципами, обеспечивающими совместимость, взаимодействие, конфиденциальность и безопасность содержащихся в них персональных данных.

С 1 января 2023 года образовательные организации основного общего и среднего профессионального образования обязаны использовать исключительно государственные информационные системы (ГИС) в рамках образовательных программ. Ярким примером такой системы является Федеральная государственная информационная система (ФГИС) «Моя школа». Хотя это требование пока не распространяется напрямую на высшее образование, его появление указывает на общую тенденцию к централизации и стандартизации информационных систем в образовательной сфере. ВУЗы должны быть готовы к потенциальной интеграции своих внутренних АИС с такими государственными платформами.

Функционал ФГИС «Моя школа» включает:

• Библиотеку верифицированного образовательного контента.
• Цифровое расписание.
• Электронный журнал и дневник.
• Систему поддержки проектной деятельности и портфолио обучающегося.

Ключевые принципы создания и функционирования ФГИС «Моя школа» – обеспечение конфиденциальности, целостности, доступности информации, что полностью согласуется с принципами информационной безопасности, рассмотренными ранее. Минпросвещения России выступает единым функциональным заказчиком этого сервиса, а Минцифры России организует и разрабатывает программное обеспечение, обеспечивает его непрерывную работу и безопасность.

Для АИС учета успеваемости в ВУЗе это означает:

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

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

Оценка технико-экономической эффективности внедрения АИС

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

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

Методы оценки экономической обоснованности

Для оценки экономической обоснованности внедрения АИС чаще всего используются такие методы, как ROI (Return on Investment) и TCO (Total Cost of Ownership). Они позволяют получить количественную оценку выгод и затрат, что делает инвестиционное решение более прозрачным.

1. ROI (Return on Investment) — Коэффициент окупаемости инвестиций:
   • Определение: Это показатель окупаемости инвестиций, рассчитываемый как отношение чистой прибыли к затратам на инвестиции, выраженное в процентах. ROI демонстрирует, насколько выгодной оказалась инвестиция.
   • Формула:
     ROI = (Доход - Себестоимость) / Инвестиции × 100%
     где:
     • Доход – ожидаемые финансовые выгоды от внедрения АИС (например, экономия на оплате труда, сокращение бумажного документооборота, штрафов).
     • Себестоимость – операционные затраты на поддержку АИС после внедрения (обслуживание, лицензии, электроэнергия).
     • Инвестиции – первоначальные затраты на разработку и внедрение АИС (оплата труда разработчиков, покупка оборудования, ПО, обучение персонала).
   • Пример расчета (гипотетический):
     Предположим, затраты на разработку и внедрение АИС составили 500 000 рублей.
     Ожидаемая годовая экономия (Доход) за счет сокращения ручного труда и оптимизации процессов – 300 000 рублей.
     Ежегодные операционные расходы на поддержку АИС (Себестоимость) – 50 000 рублей.
     Чистая годовая прибыль = 300 000 − 50 000 = 250 000 рублей.

     Тогда ROI за первый год:
     ROI = (250 000 / 500 000) × 100% = 50%

     Это означает, что за первый год после внедрения АИС инвестиции вернулись на 50%. Для оценки окупаемости в годах, можно рассчитать срок окупаемости: Инвестиции / Чистая годовая прибыль = 500 000 / 250 000 = 2 года.
     Один из примеров внедрения АИС показал годовую экономию в 152 916 рублей, а срок окупаемости составил 1,1 месяца, что демонстрирует высокую эффективность подобных систем.

2. TCO (Total Cost of Ownership) — Общая стоимость владения:
   • Определение: Это комплексный показатель, включающий все прямые и скрытые затраты, связанные с приобретением, эксплуатацией, обслуживанием, поддержкой, модернизацией и выводом из эксплуатации системы на протяжении всего ее жизненного цикла. TCO позволяет увидеть полную «стоимость» системы, а не только первоначальные инвестиции.
   • Компоненты TCO:
     • Прямые затраты:
       • Стоимость приобретения/разработки ПО и оборудования.
       • Стоимость лицензий.
       • Затраты на внедрение (инсталляция, настройка, тестирование).
       • Затраты на обучение персонала.
       • Затраты на техническую поддержку и обслуживание.
       • Затраты на электроэнергию и охлаждение оборудования.
     • Скрытые затраты:
       • Потери от простоя системы.
       • Потери от ошибок в данных.
       • Затраты на администрирование и управление системой (трудозатраты IT-персонала).
       • Затраты на обновление и модернизацию.
       • Потери производительности пользователей из-за проблем с системой.
   • Пример анализа TCO:
     При расчете TCO для АИС учета успеваемости необходимо учесть:
     • Стоимость разработки (если собственная) или покупки (если готовое решение).
     • Стоимость серверов, сетевого оборудования, СУБД (если коммерческая).
     • Заработная плата IT-специалистов, поддерживающих систему.
     • Стоимость электроэнергии и обслуживания серверного оборудования.
     • Потенциальные затраты на устранение сбоев и восстановление данных.
     • Затраты на обучение новых сотрудников работе с АИС.

Сравнение TCO различных вариантов (например, разработка с нуля, покупка готового решения, использование облачного сервиса) позволяет выбрать наиболее экономически выгодный вариант в долгосрочной перспективе.

Качественные и количественные показатели эффективности

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

Качественные показатели эффективности:

• Оптимизация деловых процессов: Упорядочение и стандартизация процедур учета успеваемости, сокращение бюрократии.
• Повышение прозрачности управления: Руководство ВУЗа получает более полную и актуальную информацию для принятия решений.
• Улучшение доступа к информации: Быстрый и удобный доступ студентов, преподавателей и администрации к необходимым данным.
• Повышение исполнительской дисциплины: Четкие алгоритмы работы в системе снижают вероятность ошибок и задержек.
• Улучшение уровня информационной безопасности: Централизованное хранение и защита данных в соответствии с ФЗ №152-ФЗ.
• Повышение удовлетворенности студентов и преподавателей: Удобство использования системы и оперативный доступ к информации улучшают опыт взаимодействия с ВУЗом.
• Снижение рисков: Минимизация ошибок, связанных с ручной обработкой данных, сокращение вероятности потери информации.

Количественные показатели эффективности (кроме ROI и TCO):

• Сокращение продолжительности процедур обработки информации:
  • Метрика: Сокращение времени формирования ведомости успеваемости на 80% (например, с 2 часов до 20 минут).
  • Метрика: Уменьшение времени на обработку заявлений студентов (например, на перевод) на 50%.
• Уменьшение доли ручных операций:
  • Метрика: Сокращение ручного ввода данных на 90% за счет автоматического импорта и валидации.
  • Метрика: Уменьшение бумажного документооборота на 70%.
• Ускорение процессов документооборота:
  • Метрика: Сокращение времени согласования документов (например, приказов) на 60%.
• Повышение оперативности подготовки отчетов и статистических данных:
  • Метрика: Время генерации статистического отчета по успеваемости за семестр — до 1 минуты.
  • Метрика: Доступность актуальных данных об успеваемости в режиме реального времени.
• Экономия рабочего времени сотрудников:
  • Метрика: Средняя экономия рабочего времени сотрудников деканатов и учебной части — от 10 до 20 часов в месяц на каждого сотрудника, занимающегося учетом успеваемости.

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

Заключение

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

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

1. Теоретические основы и методологии: Мы определили ключевые понятия (АИС, СУБД, ЖЦ ИС, нормализация данных), детально рассмотрели принципы проектирования ИС (технологичность, адаптивность, безопасность) и провели сравнительный анализ моделей жизненного цикла (каскадная, итеративная, спиральная), обосновав выбор итеративного или спирального подхода для данного проекта. Обзор ГОСТ 34.601-90 и ГОСТ Р ИСО/МЭК 12207-2010 подчеркнул важность стандартизации.
2. Анализ предметной области и требования: Были сформулированы исчерпывающие функциональные требования к АИС, охватывающие управление контингентом, успеваемостью, учебными планами и отчетностью. Особое внимание было уделено детализации нефункциональных требований (надежность, производительность, безопасность, масштабируемость, юзабилити) с приведением конкретных количественных метрик, что значительно превосходит уровень детализации в существующих конкурентных материалах. Структура технического задания была описана в соответствии с ГОСТ 34.602-89.
3. Архитектурные решения и моделирование данных: Мы рассмотрели основные архитектурные решения, обосновав выбор многоуровневой (веб-ориентированной) архитектуры как наиболее оптимальной. Инфологическое и даталогическое проектирование базы данных было представлено с использованием ER-диаграмм для моделирования сущностей и принципов нормализации данных.
4. Выбор технологического стека: Проведен детальный сравнительный анализ реляционных СУБД, где PostgreSQL был выбран как наиболее подходящий вариант для проекта. Обоснован выбор Python с Django для бэкенда и JavaScript с React для фронтенда, а также даны конкретные требования к аппаратному и программному обеспечению сервера и клиентских рабочих станций.
5. Проектирование пользовательского интерфейса: Раскрыта важность инженерной психологии и эргономики в дизайне ИС, проанализированы проблемы низкой эффективности взаимодействия и предложена эффективностная модель интерфейса (результативность, оперативность, ресурсоэкономность) с примерами метрик. Обоснован выбор «ультратонкого клиента» (веб-приложения) как наиболее эффективного типа пользовательского компонента.
6. Правовые аспекты и стандарты: Детально проанализированы требования Федерального закона №152-ФЗ «О персональных данных» и Федерального закона «Об образовании в Российской Федерации» (статья 98) в контексте создания АИС. Рассмотрены особенности государственных информационных систем в образовании (ФГИС «Моя школа») и необходимость их учета.
7. Оценка технико-экономической эффективности: Предложены и детально рассмотрены методы ROI и TCO для оценки экономической обоснованности проекта, включая формулы и примеры расчетов. Проанализированы как качественные, так и количественные показатели ожидаемых положительных эффектов от внедрения АИС.

Таким образом, данная курсовая работа представляет собой не просто теоретическое исследование, а полноценный методологический план, который может служить практическим руководством для разработки реальной АИС учета успеваемости студентов в ВУЗе.

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

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

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

Список использованной литературы

1. Диго, С.М. Базы Данных. Москва: Финансы и статистика, 2005.
2. Боуман, Дж., Эмерсон, С., Дарновски, М. Практическое руководство по SQL.
3. Электронная встроенная гипертекстовая справочная система Microsoft Access, файл MSACC20.HLP, 4.7 Мбайт.
4. Хэлволсон, М., Янг, М. Эффективная работа с Microsoft Office. Санкт-Петербург: Питер, 2001.
5. Федеральный закон от 29 декабря 2012 г. № 273-ФЗ «Об образовании в Российской Федерации». Статья 98. Информационные системы в системе образования. Доступ из СПС «КонсультантПлюс». URL: https://www.consultant.ru/document/cons_doc_LAW_140174/33b092fb13a48e7e1f486d302a2818617833077e/ (дата обращения: 25.10.2025).
6. СУБД: что такое системы управления базами данных, классификация, виды, как работают современные СУБД. Platform V. URL: https://platformv.ru/blog/chto-takoe-subd (дата обращения: 25.10.2025).
7. Проблема эффективности человеко-компьютерного взаимодействия в автоматизированных информационных системах. КиберЛенинка. URL: https://cyberleninka.ru/article/n/problema-effektivnosti-cheloveko-kompyuternogo-vzaimodeystviya-v-avtomatizirovannyh-informatsionnyh-sistemah (дата обращения: 25.10.2025).
8. Школы и колледжи с 1 января должны использовать в образовательном процессе государственные информационные системы. Минпросвещения России. URL: https://edu.gov.ru/press/6406/shkoly-i-kolledzhi-s-1-yanvarya-dolzhny-ispolzovat-v-obrazovatelnom-processe-gosudarstvennye-informacionnye-sistemy/ (дата обращения: 25.10.2025).
9. СУБД (Системы управления базами данных) — что это, какие бывают. itglobal. URL: https://itglobal.com/ru/company/blog/subd-chto-eto-kakie-byvayut/ (дата обращения: 25.10.2025).
10. Архитектурные решения информационных систем. Учебник для вузов. Литрес. URL: https://www.litres.ru/v-v-cehanovskiy/arhitekturnye-resheniya-informacionnyh-sistem-uchebnik-dlya-vuzov-66178877/ (дата обращения: 25.10.2025).
11. Проектирование базы данных успеваемости студентов ВУЗА с использованием ER-диаграмм в MySQL Workbench. Бегемот. URL: https://begemot.media/stati/proektirovanie-bazy-dannyh-uspevaemosti-studentov-vuza-s-ispolzovaniem-er-diagramm-v-mysql-workbench/ (дата обращения: 25.10.2025).
12. СУБД: что такое системы управления базами данных, виды, где используются, для чего нужны. DIS Group. URL: https://disgroup.ru/blog/subd-chto-eto-vidy-i-gde-ispolzuyutsya/ (дата обращения: 25.10.2025).
13. ER-диаграмма базы данных колледжа. Creately. URL: https://creately.com/ru/diagram-examples/er-diagram-college-database/ (дата обращения: 25.10.2025).
14. Теоретические основы проектирования информационного ресурса в современной высшей школе. DsLib.net. URL: https://www.dslib.net/pedagogika/teoreticheskie-osnovy-proektirovanija-informacionnogo-resursa-v-sovremennoj-vysshej-shkole.html (дата обращения: 25.10.2025).
15. Архитектура информационных систем управления. Высшая школа экономики. URL: https://www.hse.ru/data/2019/02/10/1182586616/Архитектура_информационных_систем_управления.pdf (дата обращения: 25.10.2025).
16. Информационные системы/ресурсы. Рособрнадзор. URL: https://obrnadzor.gov.ru/gosudarstvennye-uslugi/informatsionnye-sistemy-resursy/ (дата обращения: 25.10.2025).
17. ГОСТ Р 57193-2016. Системная и программная инженерия. Процессы жизненного цикла систем. URL: https://docs.cntd.ru/document/1200140268 (дата обращения: 25.10.2025).
18. АРХИТЕКТУРА ИНФОРМАЦИОННЫХ СИСТЕМ. Казанский федеральный университет. URL: https://kpfu.ru/portal/docs/F_1017326265/arhitektura.informacionnyh.sistem.pdf (дата обращения: 25.10.2025).
19. Проектирование информационных систем (на примере методов структурно). Электронный научный архив УрФУ. URL: https://elar.urfu.ru/bitstream/10995/36021/1/978-5-7996-1335-5_2014.pdf (дата обращения: 25.10.2025).
20. Взаимодействие пользователя с информационной системой. Часть 1. Схема. Известия СПбГЭТУ «ЛЭТИ». URL: https://izv.etu.ru/assets/files/2018/7/068-074.pdf (дата обращения: 25.10.2025).
21. ГОСТ Р ИСО/МЭК 15271-02. Процессы жизненного цикла программных средств. URL: https://docs.cntd.ru/document/1200029314 (дата обращения: 25.10.2025).
22. ГОСТ Р 56923-2016. Информационные технологии. Системная и программная инженерия. Управление жизненным циклом. Часть 3. Руководство по применению ИСО/МЭК 12207 (Процессы жизненного цикла программных средств). AllGosts. URL: https://allgosts.ru/07/080/gost_r_56923-2016 (дата обращения: 25.10.2025).
23. Диссертация на тему «Интеллектуализация интерфейса взаимодействия пользователя с базой данных физических эффектов». disserCat. URL: https://www.dissercat.com/content/intellektualizatsiya-interfeisa-vzaimodeistviya-polzovatelya-s-bazoi-dannykh-fizicheskikh-effektov (дата обращения: 25.10.2025).
24. ИНФОЛОГИЧЕСКОЕ ПРОЕКТИРОВАНИЕ ПРИ РАЗРАБОТКЕ БАЗЫ ДАННЫХ «УСПЕВАЕМОСТЬ СТУДЕНТОВ»: методические материалы. Инфоурок. URL: https://infourok.ru/infologicheskoe-proektirovanie-pri-razrabotke-bazi-dannih-uspevaemost-studentov-2646636.html (дата обращения: 25.10.2025).
25. ER модель для деканата. Киберфорум. URL: https://www.cyberforum.ru/databases/thread2943261.html (дата обращения: 25.10.2025).
26. Информационная система учета и контроля успеваемости и посещаемости студентов ЮТИ ТПУ. Geum.ru. URL: https://www.geum.ru/next/art-197771.php (дата обращения: 25.10.2025).
27. СИСТЕМА УЧЕТА УСПЕВАЕМОСТИ СТУДЕНТОВ ПРИ ИСПОЛЬЗОВАНИИ ОБЛАЧНЫХ СЕР. Электронная библиотека УрГПУ. URL: https://elar.uspu.ru/bitstream/uspu/2311/1/Sistema-ucheta-uspevaemosti.pdf (дата обращения: 25.10.2025).