Курсовая работа на тему Информационная система учёт пропущенных занятий студентами. Курсовой проект на тему

Название	Курсовой проект на тему
Анкор	Курсовая работа на тему Информационная система учёт пропущенных занятий студентами
Дата	03.03.2023
Размер	0.85 Mb.
Формат файла
Имя файла	Kurs.docx
Тип	Курсовой проект #966594

Учреждение образования Федерации профсоюзов Беларуси

«Международный университет «МИТСО»

Рег. № Кафедра информационных

Дата 2022 г. технологий

КУРСОВОЙ ПРОЕКТ
на тему

Информационная система учёт пропущенных занятий студентами

по дисциплине: Системный анализ и проектирование информационных систем (с модулем разработки веб приложений)

Основные замечания:

_________

_

_

_

_

______________________________________

_

_

_

_

_

_
Отметка о допуске курсовой работы к защите:

_______

Дата: 2022 г.

Подпись научного руководителя:

Студент: _

(подпись)

Воротилин Евгений Сергеевичч

Курс 2 группа 2020

Факультет: экономический;

Специальность: информационные системы и технологии;

Научный руководитель:

Преподаватель

Литвинский Игорь Евгеньевич

С

Минск, 2022

Учреждение образования Федерации профсоюзов Беларуси

«Международный университет «МИТСО»
Экономический факультет
Кафедра информационных технологий
Специальность 1-40 05 01 Информационные системы и технологии
УТВЕРЖДАЮ

Заведующий кафедрой

__А.Н.Лепёхин

«_»_2022 г.

ЗАДАНИЕ НА КУРСОВОЙ ПРОЕКТ
Студент: Воротилин Евгений Сергеевич_

Номер группы: 2020_

Тема: Информационная система учёт пропущенных занятий студентами

Руководитель: Литвинский Игорь Евгеньевич, доцент кафедры информационных технологий, кандидат технических наук, доцент кафедры информационных технологий учреждения образования Федерации профсоюзов Беларуси «Международный университет «МИТСО»

Дата выдачи задания: 10.02.2022 г.

Срок сдачи законченной работы: 24.05.2022 г.

Исходные материалы к проекту:

Гвоздева, Т. В. Проектирование информационных систем. Планирование проекта. Лабораторный практикум : учебное пособие / Т. В. Гвоздева. - Санкт-Петербург : Москва : Краснодар : Лань, 2019. – 114 с.

Гвоздева, Т. В. Проектирование информационных систем. Стандартизация : учебное пособие / Т. В. Гвоздева, Б. А. Баллод. - Санкт-Петербург : Москва : Краснодар : Лань, 2019. - 249 с.

Остроух, А. В. Проектирование информационных систем : монография / А. В. Остроух, Н. Е.Суркова. - Санкт-Петербург : Москва : Краснодар : Лань, 2019. - 161 с.

Рочев, К. В. Информационные технологии. Анализ и проектирование информационных систем : учебное пособие / К. В. Рочев. - 2-е изд., исправленное . - Санкт-Петербург : Москва : Краснодар : Лань, 2019. - 127 с.

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

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

Описание информационных потоков бизнес-процессов в выбранной предметной области;

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

Разработка технического задания на разработку информационной системы для выбранной предметной области согласно ГОСТ 34.

Перечень вопросов, которые подлежат разработке:

Название раздела

Срок

Составление плана курсового проекта

12.02.2022

Введение

29.02.2022

Основная часть

20.04.2022

Заключение

24.04.2022

Оформление курсового проекта

04.05.2022

Защита курсового проекта

По расписанию

РУКОВОДИТЕЛЬ_____

(ФИО, подпись)

Задание принял к исполнению

(дата и подпись студента)

ВВЕДЕНИЕ 4

ГЛАВА 1. ОПИСАНИЕ ПРЕДМЕТНОЙ ОБЛОСТИ 5

ГЛАВА 2. ИНФОРМАЦИОННЫЕ ПОТОКИ 6

2.1. Описание модели As is (как есть) 6

2.2. Определение проблемных мест, нуждающихся в информатизации. 10

2.3. Определение требований к автоматизированной информационной системе 10

2.4. Описание модели To be (как должно быть) 11

ГЛАВА 3: МОДЕЛИ И МОДЕЛИРОВАНИЕ ИС 12

3.1. Модель Захмана 12

3.2. Выбор типовых проектных решений по каждому виду обеспечений 13

2.3 Описание ER модели данных 15

3.4 Архитектура приложения 16

3.5 Схема технологических маршрутов 18

3.6 Аппаратура передачи данных 19

ГЛАВА 4. ТЕХНИЧЕСКОЕ ЗАДАНИЕ 21

ГЛАВА 5. ЭКОНОМИЧЕСКОЕ ОБОСНОВАНИЕ 22

СПИСОК ЛИТЕРАТУРЫ 24

ВВЕДЕНИЕ

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

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

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

Задачи:

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

Реализация данной задачи будет проводиться на языке программирования Java(back-end) и Angular(front-end).

ГЛАВА 1. ОПИСАНИЕ ПРЕДМЕТНОЙ ОБЛОСТИ

На каждый учебный день установлены пары для группы.

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

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

Факт отметки посещаемости соответствует добавлении записи о посещении пары студентом в разрабатываемом ПО.

Преподаватель имеет список групп и студентов, которые должны присутствовать на паре.

Анализ предметной области позволил выявить минимальный набор из 3-х сущностей. Это будут:

Студент – информация о студенте.
Группа — информация о группе, к который прикреплены студенты
Пара – информация о паре, к которой прикреплены группы.

ГЛАВА 2. ИНФОРМАЦИОННЫЕ ПОТОКИ

2.1. Описание модели As is (как есть)

Для начала стоит определить, что значит модель «как должно быть».

При изучении данной модели стало известно, что в моделировании бизнес-процессов есть разделение на 2 части: As is (как есть) и на To be (как должно быть).

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

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

Рисунок 2.1 – Модель As is (как есть)

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

Рисунок 2.2 – Этап выбора групп

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

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

2.2. Определение проблемных мест, нуждающихся в информатизации.

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

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

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

2.3. Определение требований к автоматизированной информационной системе

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

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

2.4. Описание модели To be (как должно быть)

В моделировании бизнес-процессов есть разделение на 2 части: As it (как есть) и на To be (как должно быть).

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

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

Рисунок 2.6 – Модель To be

ГЛАВА 3: МОДЕЛИ И МОДЕЛИРОВАНИЕ ИС

3.1. Модель Захмана

Разработка архитектуры ИС Схема Захмана (технический, программный, информационный компоненты).

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

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

• «ЧТО делается», или объекты/данные;

• «КАК делается», или функции/процессы;

• «ГДЕ делается», – размещение или инфраструктура;

• «КТО делает» – люди, организационные единицы;

• «КОГДА делается» – графики событий и работ;

• «ЗАЧЕМ делается» – стимулы, мотивы и стратегии деятельности.

Cхема Захмана выглядит следующим образом:

Владелец: концептуальная модель данных, модель бизнес-процессов, схема логистики, модель потока работ(workflow), Мастер-план реализации, бизнес-план.

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

Разработчик №1: Описание структуры данных, программный код, сетевая архитектура, архитектура безопасности, определение временных привязок,

Разработчик №2: Данные, работающие программы, сеть, реальные люди и организации, бизнес-события, работающие бизнес-стратегии.

3.2. Выбор типовых проектных решений по каждому виду обеспечений

Ни для кого не секрет, что чем крупнее проект или программное обеспечение или же информационная система, тем больше проект зависит от результатов работы отдела аналитики. Несмотря на то что уже давно есть чёткое определение “проектное решение” в ГОСТе 34.003-90. в результате проб и ошибок протоколирования требований, был разработан контрольный лист оценки качества проектных решений, в котором были перечислены основные разделы, которые по мере необходимости, должны были отражаться в проектном решении. Таким образом, любое проектное решение должно проверяться со следующих позиций:

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

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

Описание порядка применения программного обеспечения (use case), которое может включать:

Oписание автоматизируемого процесса (как правило, в формате BPMN – не забывайте отмечать, как выполняется то или иное действие: автоматически, автоматизировано или вообще без компьютера) и предполагаемого результата.
Определение необходимости ведения истории изменения объектов учета (необходимость хранения и последующего анализа предыдущих значений атрибутов объекта) – пренебрежение данным пунктом может увеличить время разработки в разы,
Определение необходимости протоколирования действий пользователей (определение таких действий, связь с историей изменения объекта).

Описание доработки:

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

Электронный обмен данными:

описание форматов и регламента взаимодействия через API;
описание форматов и регламента (последовательности) загрузки внешних данных в «ручном» режиме (в виде файлов);
описание форматов и регламента (последовательности) выгрузки данных в «ручном» режиме в виде файлов.

Oсновным критерием хорошего описания постановки задачи (проектного решения) является не выполнение формальных требований ГОСТ, а однозначное описание условий успешного завершения работ по выполнению требований заказчика. С этой точки зрения, фактически неотъемлемой частью любого проектного решения является описание тестовых заданий по проверке требований.

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

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

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

2.3 Описание ER модели данных

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

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

Рисунок 3.1 – Логическая модель базы данных

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

3.4 Архитектура приложения

Разработка будет проходить на платформе Java и для создания UI будем использвать фреймворк Angular, использующий TypeScript

Presentation layer (уровень представления): это тот уровень, с которым непосредственно взаимодействует пользователь. Этот уровень включает компоненты пользовательского интерфейса, механизм получения ввода от пользователя. Применительно к asp.net mvc на данном уровне расположены представления и все те компоненты, который составляют пользовательский интерфейс (стили, статичные страницы html, javascript), а также модели представлений, контроллеры, объекты контекста запроса.

Business layer (уровень бизнес-логики): содержит набор компонентов, которые отвечают за обработку полученных от уровня представлений данных, реализует всю необходимую логику приложения, все вычисления, взаимодействует с базой данных и передает уровню представления результат обработки.

Data Access layer (уровень доступа к данным): хранит модели, описывающие используемые сущности, также здесь размещаются специфичные классы для работы с разными технологиями доступа к данным, например, класс контекста данных Entity Framework. Здесь также хранятся репозитории, через которые уровень бизнес-логики взаимодействует с базой данных.

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

Уровень доступа к данным не зависит от других уровней, уровень бизнес-логики зависит от уровня доступа к данным, а уровень представления – от уровня бизнес-логики.

Компоненты, как правило, должны быть слабосвязанными (loose coupling), поэтому неотъемлемым звеном многоуровневых приложений является внедрение зависимостей.

Классическая трехуровневая система состоит из следующих уровней:

Рисунок 3.2 Схема Архитектуры

3.5 Схема технологических маршрутов

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

Рисунок 3.2 – Реализация логической модели маршрутов обработки данных

Процедура авторизации – ввод логина и пароля и последующая проверка.

Процедура регистрации – ввод логина и пароля и его сохранение.

Процедура “модуль пользователя” – происходит выбор операции из следующих вариантов:

Удаление данных.
Сортировка.
Редактирование данных.
Просмотр данных.
Добавление данных.

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

3.6 Аппаратура передачи данных

На рисунке 4.1 изображена структурная схема локальной сети абонентского отдела.

Рисунок 3.3 – Структурная схема локальной сети
Локальная сеть ИС «Университет» состоит из следующих элементов:

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

АРМ пользователей абонентского отдела подключаются к серверу ПО через коммутатор.

Управляемый коммутатор 2 уровня D-Link DGS-3700 с 8 портами 10/100/1000Base-T + 4 комбо-портами 1000Base-T/Mini GBIC (SFP).

Интерфейсы:

8 Портов 10/100/1000BASE-T;
4 Комбо-порта 10/100/1000BASE-T/SFP;
1 консольный порт RS-232;
1 порт управления RJ-45;
1 сигнальный порт RJ-45;

Модульные компоненты:

фильтр для очистки от пыли;
вентилятор;
источник питания постоянного/переменного тока;

Производительность:

коммутационная матрица: 24Гбит/с;
скорость перенаправления пакетов: 17,86Mpps;
буфер пакетов: 1МБ;
таблица МАС-адресов: до 16K записей;
размер Jumbo-фреймов: 13 312 Байт;

Физические параметры:

Источник питания (модульный):
1. Переменный ток: 100240В, 50/60МГц.
2. Постоянный ток: 3675В @ 3A (макс.).
Потребляемая мощность (макс.):
1. Переменный ток: 46,2В.
2. Постоянный ток: 38,9В.
Размеры – 441х210х44 мм.
Ширина – для монтажа в 19-дюймовую стойку, размер 1U.
Вес – 3,4 кг.
Рабочая температура от 0° до 65°C
Температура хранения от -40° до 70°C
Рабочая влажность от 10% до 90% (без конденсата).
Влажность хранения от 5% до 90% (без конденсата).

10. Электромагнитная безопасность FCC Class A, CE, C-Tick, VCCI.

11. Безопасность cUL, CB.

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

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

ГЛАВА 4. ТЕХНИЧЕСКОЕ ЗАДАНИЕ

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

Автоматизации подлежит система работы со студентами общежития.

Данная информационная система будет служить для решения следующих задач:

Работа с базой данных (добавление, удаление, изменение).
Поиск информации в базе данных.
Сортировка информации в базе данных.

Цели создания системы

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

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

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

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

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

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

ГЛАВА 5. ЭКОНОМИЧЕСКОЕ ОБОСНОВАНИЕ

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

Затраты труда на исследование предметной области:

Затраты труда на описание задачи:

Затраты труда на разработку алгоритма решения задачи:

Затраты труда на составление программы по готовой блок-схеме:

Затраты на отладку программы

Затраты труда на подготовку документации:

Полные трудовые затраты:

Расчёт технико-экономического обоснования автоматизирования

Инженер-Программист 2 категория:

Sч=

=48,34

Инженер-бизнес аналитик:

=48,34

Затраты на аналитику:

Время на документирование:

Основная зп:

Дополнительная зп:

Отчисления на соц. Нужды:

Затраты на расходные материалы =200;

Затраты на обслуживание вт и пт:

Итого себестоимость:

Расчет экономического эффекта от внедрения ПП

K=C=86111

Срок окупаемости составит примерно 2 года. Это достаточно большой срок, но всё ещё уместно внедрения ПП для оптимизации работы предприятия. Расчёт проводился с учётом дальнейшего улучшения ПО и оптимизации приложения, а также для использования API и возможного в дальнейшем масштабируемости в облачный сервис.

СПИСОК ЛИТЕРАТУРЫ

Иванов, В. М. Интеллектуальные системы : учеб. пособие для вузов / В. М. Иванов ; под науч. ред. А. Н. Сесекина. – М. : Издательство Юрайт, 2017. – 91 с.
Кубенский, А. А. Функциональное программирование : учебник и практикум для академического бакалавриата / А. А. Кубенский. – М. : Издательство Юрайт, 2019. – 348 с.
Кудрина, Е. В. Основы алгоритмизации и программирования на языке c# : учеб. пособие для СПО / Е. В. Кудрина, М. В. Огнева. – М. : Издательство Юрайт, 2019. – 322 с.
Кудрина, Е. В. Основы алгоритмизации и программирования на языке c# : учеб. пособие для бакалавриата и специалитета / Е. В. Кудрина, М. В. Огнева. – М. : Издательство Юрайт, 2019. – 322 с.
Кудрявцев, К. Я. Методы оптимизации : учеб. пособие для вузов / К. Я. Кудрявцев, А. М. Прудников. – 2-е изд. – М. : Издательство Юрайт, 2019. – 140 с.
Лаврищева, Е. М. Программная инженерия и технологии программирования сложных систем : учебник для вузов / Е. М. Лаврищева. – 2-е изд., испр. и доп. – М. : Издательство Юрайт, 2019. – 432 с.