МИНОБРНАУКИ РОССИИ Федеральное государственное бюджетное образовательное учреждение высшего образования «МИРЭА – Российский технологический университет» РТУ МИРЭА Институт Информационных технологий Кафедра Математического обеспечения и стандартизации информационных технологий Отчет по практическим работам №5-8 по дисциплине «Системная и программная инженерия» Выполнили: Студенты группы ИКБО-11-21 Проверил: Анищенков Роман Владимирович Басс Олег Александрович Матвиенко Диана Алексеевна Чиркинян Карина Арамовна ассистент Новичков Д.Е. МОСКВА 2024 г. СОДЕРЖАНИЕ ПРАКТИЧЕСКАЯ РАБОТА 5......................................................................................................4 ПРАКТИЧЕСКАЯ РАБОТА 6....................................................................................................10 ПРАКТИЧЕСКАЯ РАБОТА 7....................................................................................................12 Архитектура системы ..............................................................................................................12 Матрица требований ................................................................................................................13 Таблица 1 – Матрица требований ..........................................................................................13 ПРАКТИЧЕСКАЯ РАБОТА 8....................................................................................................18 Техническое задание ...............................................................................................................19 ВВЕДЕНИЕ ..................................................................................................................................19 1 Общие сведения ........................................................................................................................20 1.1 Полное наименование системы и ее условное обозначение ....................................20 1.2 Номер договора .............................................................................................................20 1.3 Наименование организаций – Заказчика и Разработчика .........................................20 1.4 Основания для разработки системы............................................................................20 1.5 Плановые сроки начала и окончания работы по созданию системы .......................20 1.6 Источники и порядок финансирования работ............................................................20 1.7 Порядок оформления и предъявления заказчику результатов работ по созданию системы .....................................................................................................................................20 1.8 Перечень нормативно-технических документов, методических материалов, использованных при разработке ТЗ .......................................................................................21 1.9 Список терминов и определений.................................................................................21 1.10 Описание бизнес-ролей ................................................................................................21 2 Назначение и цели создания (развития) системы .................................................................23 2.1 Назначение системы ..........................................................................................................23 2.2 Цели создания системы .....................................................................................................23 3 Характеристика объекта автоматизации ................................................................................24 3.1 Краткие сведения об объекте автоматизации .................................................................24 3.2 Сведения об условиях эксплуатации объекта автоматизации ......................................24 4 Требования к системе ...............................................................................................................25 4.1 Требования к системе в целом ..........................................................................................25 4.1.1 Требования к структуре и функционированию системы ............................................25 4.1.2 Требования к численности и квалификации персонала системы и режиму его работы .......................................................................................................................................26 4.1.3 Показатели назначения...................................................................................................26 2.1.4 Требования к надежности ..............................................................................................27 4.1.5 Требования к безопасности ............................................................................................27 4.1.6 Требования к эргономике и технической эстетике .....................................................27 4.1.7 Требования к эксплуатации, техническому обслуживанию, ремонту и хранению компонентов системы ..............................................................................................................28 4.1.8 Требования к защите информации от несанкционированного доступа ....................28 4.1.9 Требования по сохранности информации при авариях ..............................................28 4.1.10 Требования по стандартизации и унификации ..........................................................29 4.2 Требования к функциям (задачам), выполняемым системой ........................................29 4.3 Функциональная структура системы ...............................................................................30 4.4 Требования к видам обеспечения .....................................................................................31 4.4.1 Требования к математическому обеспечению системы ..........................................31 4.4.2 Требования к информационному обеспечению системы ........................................31 4.4.3 Требования к лингвистическому обеспечению системы ........................................31 4.4.4 Требования к программному обеспечению системы...............................................31 4.4.5 Требования к техническому обеспечению системы ................................................32 4.4.6 Требования к метрологическому обеспечению системы ........................................32 4.4.7 Требования к организационному обеспечению системы ........................................32 4.4.8 Требования к методическому обеспечению системы..............................................32 5 Состав и содержание работ по созданию (развитию) системы ...........................................33 6 Порядок контроля и приемки системы...................................................................................35 7 Требования к составу и содержанию работ по подготовке объекта автоматизации к вводу системы в действие......................................................................................................................36 7.1 Приведение поступающей в систему информации к виду, пригодному для обработки с помощью ЭВМ....................................................................................................36 7.2 Создание условий функционирования объекта автоматизации, при которых гарантируется соответствие создаваемой системы требованиям, содержащимся в ТЗ ...36 7.3 Сроки и порядок комплектования штатов и обучения персонала ................................36 8 Требования к документированию ...........................................................................................37 9 Порядок контроля и приемки системы...................................................................................38 ПРАКТИЧЕСКАЯ РАБОТА 5 Диаграмма классов – структурная диаграмма языка моделирования UML, демонстрирующая общую структуру иерархии классов системы, их коопераций, атрибутов (полей), методов, интерфейсов и взаимосвязей между ними, представлена на рисунке 1. Рисунок 1 –Диаграмма классов Для демонстрации совокупности моделируемых объектов и связей между ними в фиксированный момент времени разработана диаграмма объектов, представлена на рисунке 2. Рисунок 2 –Диаграмма объектов На рисунке 3 представлена контекстная диаграмма проектируемой информационной системы. Рисунок 3 – Контекстная диаграмма процесса «Взаимодействие с системой» для ИС EngSprint На рисунке 4 изображена декомпозиция A0 на подпроцессы: сбор и анализ данных пользователя, разработка курса, предоставление индивидуальных учебных материалов и обработка обращений. Рисунок 4 – Декомпозиция функционального блока A0 Для дальнейшей детализации процесса "Взаимодействие с системой" в информационной системе "EngSprint" декомпозируем процессы A1-A4, результаты представлены на рисунках 5-8. Рисунок 5 – Декомпозиция функционального блока A1 Рисунок 6 – Декомпозиция функционального блока A2 Рисунок 7 – Декомпозиция функционального блока A3 Рисунок 8 – Декомпозиция функционального блока A4 ПРАКТИЧЕСКАЯ РАБОТА 6 Диаграмма потоков данных в нотации DFD представлена на рисунках 9-10. Рисунок 9 – Верхний уровень Рисунок 10 – Декомпозиция верхнего уровня Модель базы данных представлена на рисунке 11. База данных состоит из 6 таблиц: users (пользователи), courses (обучающие курсы), study_plan (какой курс закреплен за пользователем и прогресс по курсу), stuff (сотрудники), requests (запросы в ТП от пользователей), support (запрос, ответственный и статус заявки). Рисунок 11 – Модель базы данных ПРАКТИЧЕСКАЯ РАБОТА 7 Архитектура системы Язык реализации: Kotlin Платформа: Android SDK Обоснование выбора: Kotlin является современным и безопасным языком программирования, который стал основным языком для разработки под Android благодаря своей совместимости с Java, улучшенной синтаксической конструкцией и поддержке со стороны Google. Android SDK предоставляет все необходимые инструменты для разработки, тестирования и отладки приложений под Android. База данных: Система управления базами данных (СУБД): PostgreSQL Обоснование выбора: PostgreSQL – это мощная, открытая, объектно-реляционная СУБД, которая поддерживает как SQL (реляционные), так и JSON (неструктурированные) данные, что делает ее идеальным выбором для сложных приложений, требующих высокой надежности, гибкости и масштабируемости. Серверная часть: Система создания вебинаров: Zoom API Обоснование выбора: приложение подключается к серверной части, которая, в свою очередь, взаимодействует с внешним API сервиса Zoom для организации видеовстреч или вебинаров. Рисунок 12 – Сервис-ориентированная архитектура системы Матрица требований Таблица 1 – Матрица требований № Требование Суть Автор Ссылки Критерий проверки Компоненты архитектуры 1 Мобильное приложение. Роль пользователь. 1.1 Управление учетными записями Мобильное приложение должно позволять регистрацию и аутентификацию пользователей, управление профилями и настройками конфиденциальности Басс О.А. https://xakep.ru/ 2016/08/01/mob ile-oauth/ Успешная регистрация и аутентификаци я пользователя Ввод данных реализован на устройстве пользователя, обработка происходит на сервере, хранение в единой базе данных https://clck.ru/3 9GpmR 1.2 Доступ к курсам Мобильное приложение должно предоставлять доступ к текстовым, аудио и видеоматериалам курсов, адаптированных под уровень владения языком пользователя Анищенков Р.В. https://habr.com /ru/companies/la rian/articles/329 032/ Доступность всех типов материалов Вывод данных реализован на устройстве пользователя, обработка происходит на сервере, хранение в единой базе данных 1.3 Входное тестирование Мобильное приложение должно включать функционал для проведения тестирования и отслеживания прогресса обучения Чиркинян К.А. https://habr.com /ru/articles/5341 90/ Корректность работы модуля тестирования Ввод и вывод данных реализован на устройстве пользователя, обработка происходит на сервере, хранение в единой базе данных 1.4 Итоговое тестирование по модулю Мобильное приложение должно предоставлять интерактивные задания для развития языковых навыков Матвиенко Д.А. https://swiftbook .ru/post/tutorials /kotlin-build-asimple-quiz/ Наличие и функционирова ние интерактивных заданий Ввод и вывод данных реализован на устройстве пользователя, обработка происходит на сервере, хранение в единой базе данных 1.5 Отображение прогресса Мобильное приложение должно систематически отслеживать и отображать прогресс пользователя Матвиенко Д.А. https://www.gee ksforgeeks.org/a ndroid-progressnotifications-inkotlin/ Актуальное отображение прогресса пользователя Вывод данных реализован на устройстве пользователя, обработка происходит на сервере, хранение в единой базе данных Продолжение таблицы 1 № Требование Суть Автор Ссылки Критерий проверки Компоненты архитектуры 2 Мобильное приложение. Роль методист. 2.1 Управление учебными материалами Мобильное приложение должно позволять методисту добавлять, редактировать и удалять учебные материалы и курсы Матвиенко Д.А. https://www.geeks forgeeks.org/andr oid-build-a-booklibrary-app-usingkotlin/ Успешное добавление и редактирование материалов Ввод и вывод данных реализован на устройстве пользователя, обработка происходит на сервере, хранение в единой базе данных 2.2 Отчёты эффективност и обучения Приложение должно предоставлять отчеты и аналитику по успеваемости и вовлеченности учащихся Чиркинян К.А. https://androidexa mple365.com/anal ytics-tools-forkotlinmultiplatformmobile-ios-andandroid/ Генерация отчетов об успеваемости учащихся Ввод и вывод данных реализован на устройстве пользователя, обработка происходит на сервере, хранение в единой базе данных 2.3 Уведомление о вебинарах Приложение должно давать возможность уведомить учащихся о проведении вебинаров для учащихся Анищенков Р.В. https://sendbird.co m/developer/tutori als/kotlin-videogroup-chat-app Уведомление о предстоящем вебинаре Ввод и вывод данных реализован на устройстве пользователя, обработка происходит на сервере, хранение в единой базе данных 2.4 Сбор отзывов пользователей Приложение должно обеспечивать сбор обратной связи от пользователей для улучшения учебных материалов Басс О.А. https://spark.ru/sta rtup/avtoekspert/b log/18190/kaksobirat-otzivi-vprilozheniyah-irabotat-s-nimi Получены отзывов пользователей Ввод и вывод данных реализован на устройстве пользователя, обработка происходит на сервере, хранение в единой базе данных Продолжение таблицы 4 № Требование Суть 3 Правовые нормы регулирования деятельности компании 3.1 Закон «О защите персональны х данных» Программная система, при получении, хранении и обработки персональных данных пользователей системы, должна руководствоваться нормами «Федерального закона “О персональных данных” от 27.07.2006 N 152-ФЗ редакция) 3.2 Закон «Об авторском праве и смежных правах» Автор Ссылки Критерий проверки Компоненты архитектуры Чиркинян К.А. https://www.cons ultant.ru/documen t/cons_doc_LAW _464808/3d0cac6 0971a511280cbba 229d9b6329c0773 1f7/ Прохождение теста на невозможность получения закрыт ых персональных данных третьими лицами Выполнение норм должны обеспечивать все компоненты программной системы Чиркинян К.А. https://www.cons ultant.ru/documen t/cons_doc_LAW _2238/ Прохождение теста на невозможность присвоения авторских работ третьими лицами Выполнение норм должны обеспечивать все компоненты программной системы Чиркинян К.А. https://clck.ru/39 Gv3Y Прохождение теста о согласии пользователей на использование материалов и сервисов интернет-сайта Выполнение норм должны обеспечивать все компоненты программной системы (последняя Программная система, при получении данных пользователей системы об авторстве, должна руководствоваться нормами Федерального закона “Об авторском праве и смежных правах” от 09.07.1993 N 5351-1 (ред. от 20.07.2004) 3.3 Документ «Соглашение об использовани и материалов и сервисов приложения (пользователь ское соглашение)» Программная система, при получении данных пользователей, должна руководствоваться документом “Пользовательское соглашение” Продолжение таблицы 4 № Требование Суть Автор Ссылки Критерий проверки Компоненты архитектуры 4 Нефункциональные требования 4.1 Совместимость с Android Мобильное приложение должно функционировать под версии Android 9.0 и выше Басс О.А. https://habr.com /ru/articles/1115 60/ Запуск приложения на устройствах с Android 9.0 и выше Мобильное приложение на Kotlin: Разработка с использованием Android Studio и целевая платформа Android API 14+ для обеспечения совместимости. 4.2 Требования к оперативной памяти Объём оперативной памяти устройства не менее 8 ГБ, объем свободной памяти не менее 1 ГБ Басс О.А. https://androidin sider.ru/os/googl e-rasskazalaskolkooperativnojpamyatinuzhnoandroid.html Запуск приложения на устройствах с минимальными характеристиками Оптимизация производительности: Минимизация использования ресурсов приложением, оптимизация работы с памятью. 4.3 Адаптивность интерфейса Приложение должно корректно отображаться на различных типах устройств, включая разные размеры экранов Анищенков Р.В. https://developer .android.com/de velop/ui/views/l ayout/responsive -adaptivedesign-withviews Тестирование на устройствах с различной диагональю экрана Дизайн и разработка UI/UX: Использование Android Material Design для адаптивного дизайна, поддерживающего разные размеры экранов. 4.4 Время запуска приложения Время на полный запуск приложения не должно превышать 7 секунд Басс О.А. https://developer .android.com/to pic/performance /vitals/launchtime Время запуска приложения менее 7 секунд Оптимизация загрузки приложения: Асинхронная загрузка ресурсов, ленивая инициализация компонентов. 4.5 Время отклика на пользовательск ий ввод Приложение должно отвечать на пользовательский ввод не более чем за 500 мс в стандартных условиях сети Басс О.А. https://developer .android.com/to pic/performance /anrs/keep-yourapp-responsive Время отклика менее 500 мс Увеличение допустимых пиковых нагрузок на сервер достигается с помощью улучшения характеристик серверного оборудования, а также улучшения методов работы с данными Продолжение таблицы 4 № Требование Суть Автор Ссылки Критерий проверки Компоненты архитектуры 4.6 Время отклика БД Время отклика БД на запрос не более 100 миллисекунд Басс О.А. https://developer.a ndroid.com/topic/ performance/sqlite -performancebest-practices Скорость обработки запросов БД менее 100 мс База данных PostgreSQL: Оптимизация запросов, индексация данных для ускорения поиска и доступа. 4.7 Время работы (uptime) Приложение должно иметь время uptime в год 80% Чиркинян К.А. https://www.cossa .ru/special/mobile/ 324894/?ysclid=lt r7jszrt720955539 4 Мониторинг работы приложения в течение года Использование инструментов Android SDK для надежности и оптимальной работы приложения. 4.8 Резервное копирование БД Полное резервное копирование базы данных должно производиться не менее чем 1 раз в месяц Анищенко в Р.В. https://habr.com/r u/articles/516428/ Проверка журналов резервного копирования Настройка автоматического резервного копирования и экспорта данных 4.9 Время ответа техподдержки Время ответа техподдержки не более 30 минут Матвиенк о Д.А. https://dzen.ru/a/Y ViNaVnHe1a_VF Ua Тех. поддержка отвечает менее чем за 30 минут Система управления обращениями 4.10 Использование SHA256 для хэширования пароля Для хэширования пароля необходимо использовать алгоритм SHA256 Басс О.А. https://habr.com/r u/companies/selec tel/articles/530262 / Пароли хранятся в зашифрованном виде с помощью алгоритма SHA256 Аутентификация Firebase Auth: Использование встроенных механизмов безопасности и хэширования для защиты учетных записей пользователей. 4.11 Многоуровнев ая модель управления доступом Система должна содержать многоуровневую модель управления доступом Басс О.А. https://habr.com/r u/companies/digit alleague/articles/7 22232/ Функционал распределен согласно уровням пользователей Конфигурация правил безопасности для контроля доступа к данным на уровне базы данных. 4.12 Устойчивость к атакам Система должна обеспечивать устойчивость к разным видам атак Анищенко в Р.В. https://alfarabifm. kz/advancedmobiledevelopment/osno vnye-uyazvimostimobilnykh-prilo/ Система прошла успешное тестирование к различным видам атак Восстановление всей системы, за исключением случаев физического повреждения серверов. ПРАКТИЧЕСКАЯ РАБОТА 8 Выбран ГОСТ 34.602-2020 для разработки технического задания системы "EngSprint" по следующим пунктам: Соответствие современным стандартам: ГОСТ 34.602-2020 является более современной версией стандарта и лучше соответствует текущим требованиям к информационным системам. Он учитывает последние тенденции в разработке программного обеспечения и информационных технологий, что делает его более актуальным и применимым для проектов, основанных на новейших технологических решениях. Полнота охвата этапов разработки: ГОСТ 34.602-2020 детализирует этапы разработки информационной системы, начиная от сбора и анализа требований и заканчивая сопровождением и обн овлением системы. Это обеспечивает комплексный подход к разработке и большую структурированность процесса по сравнению с устаревшим ГОСТ 19.201-78. Фокус на интеграцию и совместимость: в отличие от ГОСТ 19.201-78, новый стандарт уделяет больше внимания вопросам интеграции систем и их совместимости с другими программными и техническими средствами. Для "EngSprint", которому необходимо интегрироваться с внешними API и существующими платформами, такой подход к разработке ТЗ является более предпочтительным. Техническое задание ВВЕДЕНИЕ В современном мире знание английского языка открывает новые возможности для общения, образования и карьерного роста. В связи с этим, спрос на инновационные и эффективные методы изучения английского языка непрерывно растет. Это подчеркивает актуальность и необходимость в разработке современных информационных систем для обучения английскому языку, которые могут предложить пользователям персонализированный подход и адаптированный контент, отвечающий их индивидуальным потребностям и уровню владения языком. Информационная система для обучения английскому языку, основанная на методике Стивена Крашена, предназначена для того, чтобы сделать процесс изучения языка более естественным, интерактивным и эффективным. Она направлена на максимальное погружение в языковую среду и предоставляет широкий спектр инструментов для развития навыков чтения, письма, аудирования и говорения. Целью разработки данной системы является создание мощного инструмента, который будет способствовать быстрому и качественному освоению английского языка, учитывая современные требования и тенденции в области образования. 1 Общие сведения 1.1 Полное наименование системы и ее условное обозначение Наименование системы: EngSprint. Условное обозначение: ES. 1.2 Номер договора Шифр темы: АИС-ES. Номер контракта: №1/11-11-11-111 от 10.03.2024. 1.3 Наименование организаций – Заказчика и Разработчика Заказчиком системы является РТУ МИРЭА. Адрес заказчика: Москва, проспект Вернадского, д. 78. Разработчиком системы является ООО «Динозаврики». 1.4 Основания для разработки системы Основанием для разработки системы "EngSprint" стал анализ рынка программных продуктов, который выявил потребность в гибких и персонализированных подходах к изучению английского языка. Требования к мобильности и доступности образовательных ресурсов подтолкнули к созданию платформы, способной предоставлять качественные языковые услуги без привязки к времени и месту. Разработка информационной системы позволит усовершенствовать методикотехнологический подход к процессу обучения, упростить и облегчить образовательный процесс, тем самым повысив интенсивность обучения и заинтересованность обучаемых. 1.5 Плановые сроки начала и окончания работы по созданию системы Плановый срок начала работ по созданию ИС EngSprint – 17 февраля 2024 года. Плановый срок окончания работ по созданию ИС EngSprint – 17 июня 2024 года. 1.6 Источники и порядок финансирования работ Собственные средства разработчика системы. 1.7 Порядок оформления и предъявления заказчику результатов работ по созданию системы Результаты работ передаются Заказчику в порядке, определенном контрактом в соответствии с Календарным планом работ контракта на основании Актов сдачи-приемки выполненных работ (этапа работ). Документация ES передается на бумажных (два экземпляра, один экземпляр после подписания Заказчиком должен быть возвращен Исполнителю) и на машинных носителях (USB) (в двух экземплярах). Текстовые документы, передаваемые на машинных носителях, должны быть представлены в форматах PDF. Все материалы передаются с сопроводительными документами Исполнителя. 1.8 Перечень нормативно-технических документов, методических материалов, использованных при разработке ТЗ При разработке автоматизированной системы и создании проектноэксплуатационной документации Исполнитель должен руководствоваться требованиями следующих нормативных документов: ГОСТ 19.106-78. Единая система программной документации. Требования к программным документам, выполненным печатным способом. ГОСТ 34.602 – 2020. Информационные технологии. Комплекс стандартов на автоматизированные системы. Техническое задание на создание автоматизированной системы ГОСТ Р 59793-2021. Информационные технологии. Комплекс стандартов на автоматизированные системы. Автоматизированные системы. Стадии создания. ГОСТ 34.201–2020. Информационные технологии. Комплекс стандартов на автоматизированные системы. Виды, комплектность и обозначение документов при создании автоматизированных систем. 1.9 Список терминов и определений ИС (Информационная Система) – система, предназначенная для хранения, поиска и обработки информации, и соответствующие организационные ресурсы (человеческие, технические, финансовые и т. д.), которые обеспечивают и распространяют информацию. СУБД (Система Управления Базами Данных) – совокупность программных и лингвистических средств общего или специального назначения, обеспечивающих управление созданием и использованием баз данных. Методика Стивена Крашена – комплекс теоретических положений и практических рекомендаций, разработанных Стивеном Крашеном для обучения второму языку, основанный на понятиях естественного приобретения языка и погружения в языковую среду. Интерактивное задание – упражнение, требующее активного участия пользователя для выполнения задач на понимание или производство языка. Персонализация – адаптация контента и процесса обучения к индивидуальным потребностям, уровню владения языком и предпочтениям пользователя. 1.10 Описание бизнес-ролей Гость – человек, посетивший информационную систему «EngSprint», имеющий ограниченный доступ к функционалу. Пользователь – человек, который занимается изучением английского языка. Пользователи имеют доступ к обучающим материалам, интерактивным заданиям и инструментам для отслеживания собственного прогресса. Они могут адаптировать обучение под свои индивидуальные потребности и уровень знаний. Методист – специалист, ответственный за разработку учебной программы и образовательного контента, основываясь на методике Стивена Крашена и других современных подходах к обучению английскому языку. Методисты создают и поддерживают актуальность учебных материалов, разрабатывают методические рекомендации для эффективного изучения языка, и оценивают образовательный прогресс учащихся. Администратор – лицо, ответственное за настройку и поддержание работоспособности информационной системы. Администраторы управляют доступом к различным уровням системы, обеспечивают ее безопасность и решают технические проблемы. Они отвечают за обновление программного обеспечения, мониторинг производительности системы и предотвращение потенциальных угроз безопасности. Техническая поддержка – команда специалистов, предоставляющих помощь пользователям в решении технических проблем и вопросов, возникающих при использовании системы. Техническая поддержка обеспечивает бесперебойную работу системы, быстро реагируя на запросы пользователей и предоставляя четкие инструкции по устранению неполадок. 2 Назначение и цели создания (развития) системы 2.1 Назначение системы Информационная система обучения английскому языку EngSprint предназначена для эффективного обучения английскому языку через методику Стивена Крашена, с использованием интерактивных методов обучения для пользователей любого уровня. 2.2 Цели создания системы Основными целями создания ИС являются: обеспечение доступа к современным методам обучения английскому языку, основанным на методике Стивена Крашена; содействие самостоятельному изучению английского языка через частичное (искусственное) погружение в языковую среду; улучшение языковых навыков пользователей, включая понимание на слух, говорение, чтение и письмо; повышение мотивации и вовлеченности пользователей через интерактивные элементы, игровые механизмы; предоставление персонализированного обучающего контента в соответствии с уровнем владения языком и интересами пользователей. 3 Характеристика объекта автоматизации 3.1 Краткие сведения об объекте автоматизации Объектом автоматизации является процесс изучения английского языка. В независимости от рода занятий пользователя. 3.2 Сведения об условиях эксплуатации объекта автоматизации Условия эксплуатации комплекса технических средств Системы должны соответствовать условиям эксплуатации группы 2 ГОСТ 21552-84 «Средства вычислительной техники. Общие технические требования, приемка, методы испытаний, маркировка, упаковка, транспортировка, хранение». Условия эксплуатации персональных компьютеров Системы соответствуют Гигиеническим требованиям к видео-дисплейным терминалам, персональным электронновычислительным машинам и организации работы (Санитарные правила и нормы. СанПиН 2.2.2.542-96). Исполнитель должен проверить соблюдение условий эксплуатации комплекса технических средств на этапе технического проектирования. 4 Требования к системе 4.1 Требования к системе в целом 4.1.1 Требования к структуре и функционированию системы Система имеет модульную структуру, включающую в себя следующие модули: модуль управления пользователями – управление учетными записями пользователей, включая регистрацию, аутентификацию, управление профилями и настройками конфиденциальности; модуль учебных материалов – содержит образовательный контент, включая тексты, аудио и видеоматериалы, адаптированные под разные уровни владения языком; модуль тестирования и оценки – предоставляет функционал для проведения тестирования уровня знаний пользователей и последующего отслеживания прогресса; модуль аналитики – сбор и анализ данных о действиях пользователей в системе для улучшения учебных материалов и персонализации обучения; модуль управления контентом – инструменты для создания, редактирования и распределения учебных материалов методистами. Система должна выполнять следующие функции: персонализация обучения – адаптация учебного плана и материалов в соответствии с индивидуальным уровнем знаний и предпочтениями пользователя; управление учебными материалами – создание, редактирование и организация учебных материалов в удобной для пользователей форме; проведение тестирований – проведение тестов для оценки уровня знания языка и прогресса обучения; интерактивное обучение – предоставление аудио/видео материалов и других интерактивных заданий для развития языковых навыков; отслеживание прогресса – систематическое отслеживание и отображение прогресса пользователя в изучении языка; аналитика и отчетность – сбор и анализ данных об использовании системы для оптимизации процесса обучения и управления контентом; возможность уведомлять пользователей о предстоящем вебинаре с методистом; техническая поддержка – предоставление пользователям помощи по вопросам использования системы и решения технических проблем. 4.1.2 Требования к численности и квалификации персонала системы и режиму его работы Разработчики мобильного приложения – команда разработчиков, специализирующихся на создании мобильных приложений для Android. Должны обладать знаниями в области программирования на Kotlin или Java, понимании принципов проектирования мобильных интерфейсов. Методисты – специалисты, знакомые с методикой Стивена Крашена и способные адаптировать образовательный контент под мобильный формат. Тестировщики ПО – сотрудники, ответственные за проверку качества и стабильности работы мобильного приложения. Должны обладать навыками работы с инструментами автоматизированного и ручного тестирования мобильных приложений. Специалисты технической поддержки – команда поддержки пользователей, которая помогает решать возникающие вопросы и проблемы при работе с приложением. Необходимы навыки работы с клиентами и понимание основ работы мобильных приложений. Администраторы – лица, отвечающие за обновление и управление образовательным контентом в приложении. Требуется понимание принципов создания и редактирования мультимедийных образовательных материалов. Разработчики, методисты, тестировщики ПО и администраторы контента работают в стандартном режиме с возможностью гибкого графика для оптимизации рабочего процесса. В случае критических ошибок или сбоев в работе приложения могут быть задействованы вне стандартного рабочего времени. Специалисты технической поддержки должны быть доступны в режиме, максимально покрывающем активное время использования приложения пользователями в разных часовых поясах, что может включать сменный или круглосуточный режим работы. Режим работы других пользователей не ограничен. 4.1.3 Показатели назначения Подсистемы, разработанные и доработанные в рамках данного раздела, обязательно должны отвечать следующим требованиям: 1. Время на полный запуск приложения не должно превышать 7 секунд. 2. Коэффициент юзабилити не менее 90%. 3. Коэффициент интерактивности не менее 90%. 4. Коэффициент достоверности информации не менее 95%. 5. Ответ технической поддержки на вопрос пользователя не более 30 минут. 6. Частота обновления учебного контента и добавление новых материалов не реже раза в месяц. 7. Приложение должно отвечать на пользовательский ввод не более чем за 500 мс в стандартных условиях сети (скорость подключения не менее 100 мбит/с) Требования к аппаратной части и масштабированию для обеспечения перечисленных показателей должны быть определены на этапе технического проектирования. 2.1.4 Требования к надежности Информационная система должна быть способна функционировать непрерывно, без сбоев и остановок, не менее 80% времени в год. В случае сбоев или аварийных ситуаций время восстановления работы системы не должно превышать 1 часа с момента обнаружения проблемы. Для предотвращения потери данных необходимо обеспечить автоматизированное регулярное резервное копирование всех критически важных данных. Резервные копии должны создаваться не реже одного раза в сутки. Надежность требуемого уровня достигается путем комплексного применения организационных и организационно-технических мероприятий. При этом необходимо использовать соответствующие требованиям программно-аппаратные средства. В частности, можно использовать следующие базовые подходы: системное и базовое ПО и технические средства, соответствующие классу решаемой задачи; четкое соблюдение правил эксплуатации, а также регламентных сроков обслуживания используемых программно-аппаратных средств. 4.1.5 Требования к безопасности Безопасность данных пользователей должна обеспечиваться шифрованием, для хэширования пароля необходимо использовать алгоритм SHA256. Система должна содержать многоуровневую модель управления доступом, ограничивая доступ к чувствительным функциям и данным в соответствии с ролями. А также обеспечивать устойчивость к разным видам атак: DDoS-атаки, SQL-инъекции. 4.1.6 Требования к эргономике и технической эстетике Код информационной системы "EngSprint" должен следовать принципам чистоты, читаемости и обслуживаемости, обеспечивая высокую эргономику для разработчиков и технических специалистов. Это подразумевает использование ясных и понятных имен переменных, функций и классов, а также соблюдение соглашений по стилю кодирования и форматирования, утвержденных для проекта. Необходимо строгое следование принципам DRY (Don't Repeat Yourself) и KISS (Keep It Simple, Stupid), чтобы код был лаконичным и не содержал ненужных повторений, что упрощает его тестирование и отладку. Документация кода должна быть актуальной, полной и доступной, с четким описанием функциональности каждого модуля и метода. Комментарии в коде следует применять умеренно, только там, где это действительно необходимо для пояснения сложных алгоритмов или решений, которые не очевидны из самого кода. Структура проекта должна быть интуитивно понятной, с логическим разделением на модули и пакеты, что облегчает навигацию по коду и его дальнейшее расширение. Важно также уделить внимание технической эстетике кода, что включает в себя единообразие и симметричность в блоках кода, правильное выравнивание и использование пробелов для улучшения визуального восприятия структуры программы. Эти требования не только способствуют эффективной командной работе и легкости поддержки кода, но и отражают профессионализм и культуру разработки внутри компании. 4.1.7 Требования к эксплуатации, техническому обслуживанию, ремонту и хранению компонентов системы Техническим обслуживанием, ремонтом и хранением сервера АС занимаются сетевые инженеры-техники, специалисты по серверным и сетевым технологиям, а также мастера по ремонту компьютерного и другого технического оборудования из сторонней обслуживающей организации. 4.1.8 Требования к защите информации от несанкционированного доступа Система содержит многоуровневую модель управления доступом, ограничивая доступ к чувствительным функциям и данным в соответствии с ролями. При работе с системой необходимо, чтобы данные могли быть восстановлены в случае потери, информация компании и пользователей была защищена от доступа или модификации несанкционированными лицами. 4.1.9 Требования по сохранности информации при авариях Для обеспечения сохранности данных требуется предусмотреть резервное копирование. А также необходимо внедрить стратегию комплексного бэкапа, включающую холодное и горячее резервное копирование. Холодное резервирование предполагает периодическое сохранение копий данных на отдельные физические или облачные носители на срок до 365 дней. Горячее резервирование предусматривает сохранение данных в реальном времени на срок до 14 дней. 4.1.10 Требования по стандартизации и унификации Для разработки Android приложения необходимо использовать Kotlin или Java, следуя стандартам Material Design и рекомендациям Google по разработке. Необходимо использование современных библиотек компонентов интерфейса, обеспечивающих единообразие и удобство использования приложения на различных устройствах и версиях операционных систем. Использование адаптивного дизайна, гарантирующего корректное отображение интерфейса на экранах различных размеров и разрешений. 4.2 Требования к функциям (задачам), выполняемым системой Таблица 4.1 – Требования к функциям, выполняемым системой Функция Обработка трафика большого объема Информирование о сбоях Работа с учащимися Работа с методистом Работа с администратором Работа с тех. поддержкой Функция поиска и просмотра Задача Эффективная запись данных в БД Быстрая выгрузка данных в оперативную память Оптимизация запросов к БД для минимизации времени отклика Автоматическая отправка уведомлений о сбоях администратору Логирование ошибок для последующего анализа Регистрация и авторизация пользователей Просмотр учебных материалов Выполнение тестов и заданий Отслеживание прогресса обучения Добавление и редактирование учебных материалов Анализ эффективности обучающих программ Организация и проведение вебинаров и обучающих сессий для учащихся Управление учетными записями пользователей Настройка параметров безопасности системы Мониторинг состояния системы и ее компонентов Прием и обработка запросов от пользователей Предоставление технической помощи и инструкций Поиск по учебным материалам и ресурсам системы Просмотр учебных материалов, видео и аудио ресурсов Продолжение таблицы 4.1 Обработка, хранение и поддержка БД Персонализация обучения Резервное копирование и восстановление данных БД Обеспечение целостности и безопасности данных Адаптация учебного плана под уровень и предпочтения пользователя Предложение рекомендаций и учебных материалов на основе анализа активности пользователя 4.3 Функциональная структура системы Рисунок 1 – Структурная диаграмма Связь между Подсистемой управления контентом и Подсистемой пользовательского интерфейса: обеспечивает доступность учебных материалов для пользователей после их создания или обновления. Связь между Подсистемой тестирования и отслеживания прогресса и Подсистемой пользовательского интерфейса: позволяет пользователям проходить тестирование и видеть свой прогресс в приложении. Связь между Подсистемой тестирования и отслеживания прогресса и Подсистемой аналитики и отчетности: использует данные об успеваемости для формирования персонализированных рекомендаций. Связь между Подсистемой пользовательского интерфейса и Подсистемой поддержки: управляет обработкой обращений пользователей и предоставлением технической помощи. Связь между Подсистемой аналитики и отчетности и Подсистемой управления контентом: позволяет методистам анализировать эффективность учебных материалов и вносить соответствующие изменения. Связь между Подсистемой работы с БД и Подсистемой пользовательского интерфейса: обеспечивает пользователю доступ к медиафайлам для обучения. Связь между Подсистемой обработки, хранения и поддержки БД и Подсистемой работы с БД: определяет работу администратора с данными в БД по всем пользователям на уровне сервера. 4.4 Требования к видам обеспечения 4.4.1 Требования к математическому обеспечению системы Математическое обеспечение системы должно обеспечивать реализацию перечисленных в данном ТЗ функций, а также выполнение операций конфигурирования, программирования, управления базами данных и документирования. Алгоритмы должны быть разработаны с учетом возможности получения некорректной входной информации и предусматривать соответствующую реакцию на такие события. 4.4.2 Требования к информационному обеспечению системы Состав, структура и способы организации данных в системе должны быть определены на этапе технического проектирования. Данные, используемые системой, должны храниться в реляционной СУБД. Структура базы данных определяется с учетом особенностей внутренней модели системы принятия решений. Информационный обмен между серверной и клиентской частями системы должен осуществляться по протоколу HTTPS. 4.4.3 Требования к лингвистическому обеспечению системы Информационная система для обучения английскому языку по методике Стивена Крашена должна быть реализована на русском языке. 4.4.4 Требования к программному обеспечению системы Программное обеспечение клиентской части должно удовлетворять следующим требованиям: Операционная система: Android 9.0 и выше. 4.4.5 Требования к техническому обеспечению системы Платформа, на которой будет развернута серверная часть системы, должна удовлетворять следующим минимальным требованиям: не менее 16 GB оперативной памяти; не менее 1000 GB свободного места на жестком диске; OC на базе Linux или ОС Windows; поддерживаемый протокол передачи данных HTTP/HTTPS, скорость передачи данных 1 Гбит/с; процессор с тактовой частотой не менее 4.6 GHz. 4.4.6 Требования к метрологическому обеспечению системы Требования к метрологическому обеспечению не предъявляются. 4.4.7 Требования к организационному обеспечению системы Требования к организационному обеспечению не предъявляются. 4.4.8 Требования к методическому обеспечению системы Необходимо разработать несколько типов руководств: руководство пользователя для учащихся; руководство пользователя для методистов; руководство пользователя для администраторов системы; FAQ и база знаний. 5 Состав и содержание работ по созданию (развитию) системы Разработка системы предполагается по укрупненному календарному плану, приведенному в таблице 5.1. Таблица 5.1 – Календарный план работ по созданию АИС ES. Этапы работ 1. Исследование и Содержание работ Сроки 1.1 Обследование (сбор и анализ 17.02.2024 – обоснование данных) 24.02.2024 создания АС автоматизированного объекта, включая сбор сведений о зарубежных и отечественных аналогах 2. Составление 2.1 Разработка функциональных и 25.02.2024 – технического нефункциональных требований к 04.03.2024 задания системе 3. Эскизное проектирование 3.1. Разработка предварительных 04.03.2024 – решений по выбранному варианту АС 10.03.2024 и отдельным видам обеспечения 4. Техническое 4.1. Разработка диаграмм проектирование 11.03.2024 – 17.03.2024 4.2. Разработка макетов интерфейса 18.03.2024 – 25.03.2024 5. Разработка программной части 5.1. Разработка модуля управления 25.03.2024 – пользователями 30.04.2024 5.2. Разработка модуля учебных 25.03.2024 – материалов 30.04.2024 5.3. Разработка модуля тестирования и 25.03.2024 – оценки 30.04.2024 5.4. Разработка модуля аналитики 25.03.2024 – 30.04.2024 5.5. Разработка модуля управления 25.03.2024 – контентом 30.04.2024 Продолжение таблицы 5.1 6. Предварительные 6.1. Проверка работоспособности 01.05.2024 – комплексные системы в условиях, приближенных к 12.05.2024 испытания реальным 7. Опытная эксплуатация 8. Ввод в промышленную эксплуатацию 7.1. Эксплуатация с привлечением 13.05.2024 – небольшого количества участников 19.05.2024 7.2. Устранение замечаний, 20.05.2024 – выявленных при эксплуатации АС 02.06.2024 8.1. Приемка АС в промышленную 10.06.2024 – эксплуатацию (внедрение АС) 17.06.2024 6 Порядок контроля и приемки системы В соответствии с разделом 5 необходимо на каждой стадии создания системы установить контроль и приемку результатов работ. На стадии 5 происходит прием готовой версии программного продукта (модели), а остальные результаты работ представляются в виде документов согласно таблице 5.1. Приемка этапа включает в себя рассмотрение и оценку объема работ и предоставленной технической документации в соответствии с требованиями технического задания. Организацию и проведение приемки системы должен осуществлять заказчик, а приемка системы должна производиться только после того, как будут выполнены все задачи системы. Заказчик обязан предоставить материальную часть (технические средства), проектную документацию и специально выделенный персонал. Последним этапом при приемке системы является составление акта приемки. 7 Требования к составу и содержанию работ по подготовке объекта автоматизации к вводу системы в действие Для обеспечения готовности объекта к вводу системы в действие провести комплекс мероприятий: завершить работы по установке технических средств; провести диагностику устойчивости сети к нагрузкам; провести обучение сотрудников. 7.1 Приведение поступающей в систему информации к виду, пригодному для обработки с помощью ЭВМ Информация вводится в строковом, числовом и логическом формате. 7.2 Создание условий функционирования объекта автоматизации, при которых гарантируется соответствие создаваемой системы требованиям, содержащимся в ТЗ Для функционирования создаваемой системы требуется платформа, технические характеристики которой соответствуют предъявленным. 7.3 Сроки и порядок обучения персонала Подготовка сотрудников должна быть завершена до начала опытной эксплуатации системы. 8 Требования к документированию Проектная документация должна быть разработана в соответствии с ГОСТ 34.2012020 и ГОСТ 7.32-2017. Отчетные материалы должны включать в себя текстовые материалы (представленные в виде бумажной копии и на цифровом носителе в формате MS Word) и графические материалы. Предоставить документы: 1) схема функциональной структуры автоматизируемой деятельности; 2) описание технологического процесса обработки данных; 3) описание информационного обеспечения; 4) описание программного обеспечения АС; 5) схема логической структуры БД; 6) руководство пользователя; 7) описание контрольного примера (по ГОСТ 24.102); 8) протокол испытаний (по ГОСТ 24.102). 9 Порядок контроля и приемки системы ГОСТ 34.602-2020. Информационные технологии. Комплекс стандартов на автоматизированные системы. Техническое задание на создание автоматизированной системы. ГОСТ Р 59793-2021. Информационные технологии. Комплекс стандартов на автоматизированные системы. Автоматизированные системы. Стадии создания. ГОСТ 34.201-2020. Информационные технологии. Комплекс стандартов на автоматизированные системы. Виды, комплектность и обозначение документов при создании автоматизированных систем. ГОСТ 19.105-78. Единая система программной документации. Общие требования к программным документам.
