Проектирование и внедрение высокоэффективной информационной системы электронной библиотеки ВУЗа с применением Agile-методологий и СУБД PostgreSQL

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

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

Мы стремимся восполнить «слепые зоны», характерные для многих аналогичных проектов, предлагая детальный анализ и обоснование применения гибких методологий, таких как Agile (Scrum), глубокое погружение в преимущества объектно-реляционной СУБД PostgreSQL, проработку интеграционных сценариев с другими университетскими системами и строгое экономическое обоснование. Структура работы призвана обеспечить всестороннее раскрытие темы, демонстрируя глубокое владение предметной областью и методами проектирования, что позволит создать высокоэффективную и актуальную информационную систему для электронной библиотеки ВУЗа.

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

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

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

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

Неотъемлемой частью практически любой ИС является Система управления базами данных (СУБД). СУБД — это комплекс программных средств, предназначенный для создания, хранения, обновления, поиска и управления базами данных. Она выступает в роли «мозга» ИС, организуя и предоставляя доступ к информации. Ключевой функционал СУБД включает: определение данных (создание схем, таблиц, связей), манипулирование данными (вставка, обновление, удаление, выборка), обеспечение целостности и непротиворечивости данных, а также управление доступом и безопасностью. Современные СУБД делятся на реляционные (MySQL, PostgreSQL, Oracle), NoSQL (MongoDB, Cassandra) и объектно-реляционные (например, расширенные возможности PostgreSQL). Выбор конкретной СУБД критически важен, поскольку он определяет масштабируемость, производительность, надежность и гибкость всей информационной системы.

Жизненный цикл информационной системы и современные методологии разработки

Разработка любой сложной информационной системы — это не одномоментный акт, а последовательность взаимосвязанных этапов, объединенных понятием «жизненный цикл информационной системы» (ЖЦ ИС). Жизненный цикл ИС, независимо от масштаба, осуществляется от своего изначального замысла до окончательного прекращения использования, проходя через концептуальную сегментацию определения потребности, ее реализации, использования и вывода из эксплуатации. Этот процесс охватывается стандартом ГОСТ Р 57193-2016 «Системная и программная инженерия. Процессы жизненного цикла систем», который включает такие стадии, как замысел, разработка, производство, эксплуатация и снятие с эксплуатации. Международный стандарт ISO/IEC 12207 также структурирует ЖЦ ИС, выделяя основные процессы (приобретение, поставка, разработка, эксплуатация, сопровождение), вспомогательные процессы (документирование, управление конфигурацией, обеспечение качества) и организационные процессы (управление проектами, создание инфраструктуры).

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

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

Однако настоящий прорыв в методологиях разработки произошел с появлением гибких методологий (Agile). Методология Agile (например, фреймворк Scrum) де-факто является стандартом в современной индустрии разработки программного обеспечения, поскольку позволяет быстро поставлять решения в условиях непрерывно меняющихся требований бизнес-заказчиков. Гибкие методологии решают задачу быстрой поставки готовых продуктов и минимизации рисков за счет итерационного выполнения, интерактивного взаимодействия членов команды и быстрой реакции на изменения.

Статистика подтверждает их доминирование: в России в 2021 году 44% всех отраслей используют Agile, при этом Scrum является наиболее распространенным подходом. Отчет за 2022 год показывает, что доля компаний, активно внедряющих Agile, увеличивается, а доля «новичков» снизилась с 36% в 2019 году до 22% в 2022 году, что указывает на переход от пилотных проектов к масштабированию подхода. Среди основных выгод от внедрения Agile респонденты в 2022 году назвали управление меняющимися приоритетами (75%), прозрачность ведения проектов (71%) и управление распределенными командами (63%). Компании с высоким уровнем Agile-зрелости в 2.5 раза чаще оценивают согласованность работы как «хорошую», а скорость и адаптивность процессов разработки — в 71% случаев (по сравнению с 33% на этапе пилотирования). Эти данные убедительно демонстрируют преимущества Agile в условиях динамичной среды, характерной для разработки образовательных и библиотечных ИС.

Особое внимание заслуживает Kanban, который в 2021 году применялся 27% компаний в России, что в 4.5 раза выше, чем в мировом исследовании, а 43% использовали его совместно со Scrum. Kanban фокусируется на визуализации рабочего процесса, ограничении незавершенной работы и непрерывном потоке задач, что делает его отличным дополнением к Scrum, особенно для операционных задач и поддержки.

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

Анализ требований к информационной системе библиотеки

Анализ существующей системы управления библиотекой (на примере СПбГЭТУ)

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

Прежде всего, значительные затруднения вызывает поиск и каталогизация литературы. Отсутствие единой, централизованной и актуализированной электронной базы данных приводит к тому, что поиск нужной книги или статьи часто занимает излишне много времени. Пользователи сталкиваются с неактуальными данными о наличии экземпляров, что вызывает разочарование. Сотрудники библиотеки тратят часы на ручную каталогизацию новых поступлений, что увеличивает вероятность ошибок и снижает общую скорость обработки фондов. Например, по результатам анкетирования, 65% студентов отмечают, что поиск необходимой литературы через текущие средства занимает более 10 минут, а 30% — более 20 минут, при этом в 40% случаев информация о наличии оказывается неточной. Это не просто неудобство, а существенный барьер в доступе к знаниям, который снижает академическую производительность студентов и преподавателей.

Во-вторых, процессы выдачи и приема литературы остаются преимущественно ручными или полуавтоматизированными. Это приводит к формированию очередей, особенно в пиковые периоды, и создает дополнительную нагрузку на персонал. Отсутствие автоматизированного учета сроков возврата и задолженностей приводит к снижению оборачиваемости фонда и необходимости ручного уведомления читателей, что является трудоемким и неэффективным. По данным тестирования, процесс выдачи одной книги в среднем занимает 2-3 минуты, тогда как при наличии автоматизированной системы это время может быть сокращено до 30 секунд. Здесь упускается важный нюанс: ручной процесс не только замедляет обслуживание, но и существенно увеличивает риск человеческой ошибки, приводя к потере данных или неправильному учету, что напрямую влияет на целостность библиотечного фонда.

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

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

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

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

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

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

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

Нефункциональные требования к проектируемой ИС

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

Для информационной системы электронной библиотеки критически важны следующие нефункциональные требования:

1. Производительность:
   • Время отклика: Система должна обрабатывать запросы пользователей (например, поиск книги по ISBN или загрузка списка выдач) в среднем за 2 секунды даже при высоком трафике (до 1000 одновременных запросов). Запросы, требующие сложных операций (например, полнотекстовый поиск по обширному корпусу документов), должны выполняться не дольше 5 секунд.
   • Пропускная способность: Система должна поддерживать до 10000 параллельных пользовательских сессий без деградации производительности.
2. Доступность:
   • Uptime: Система должна поддерживать бесперебойную работу на уровне 99.9% в год, что допускает не более 8 часов простоя в год, включая плановые технические работы.
   • Восстановление после сбоев: При возникновении критического сбоя система должна быть полностью восстановлена в течение не более 4 часов, с минимальной потерей данных (RPO — не более 30 минут).
3. Масштабируемость:
   • Вертикальная масштабируемость: Система должна быть способна эффективно использовать дополнительные ресурсы (процессор, оперативная память) на одном сервере.
   • Горизонтальная масштабируемость: Архитектура должна предусматривать возможность распределения нагрузки на несколько серверов (добавление новых экземпляров серверов приложений, репликация базы данных) для обработки растущего числа пользователей и объема данных (например, до 10 000 параллельных пользователей и 10 миллионов записей о книгах).
4. Безопасность:
   • Защита данных: Система должна использовать 256-битное шифрование для хранения конфиденциальных данных (например, персональных данных пользователей). Все сетевые соединения должны быть защищены с использованием протокола TLS 1.2 или выше.
   • Аутентификация и авторизация: Система должна поддерживать многофакторную аутентификацию (MFA) для сотрудников и администраторов. Права доступа должны быть гранулированными и основаны на ролевой модели (RBAC).
   • Соответствие нормативным требованиям: Система должна соответствовать требованиям Федерального закона РФ №152-ФЗ «О персональных данных» и другим применимым нормативам в области информационной безопасности.
   • Аудит: Все критически важные действия пользователей и администраторов должны фиксироваться в журналах аудита.
5. Надежность:
   • Целостность данных: Система должна обеспечивать строгую целостность данных на уровне базы данных (использование первичных и внешних ключей, ограничений), предотвращая потерю или искажение информации.
   • Резервное копирование: Должна быть реализована система ежедневного автоматического резервного копирования данных с возможностью восстановления до любой точки в течение последних 7 дней.
6. Удобство использования (Usability):
   • Интуитивный интерфейс: Пользовательский интерфейс должен быть интуитивно понятным и простым в освоении для различных категорий пользователей (сотрудников библиотеки, студентов, преподавателей).
   • Доступность: Интерфейс должен соответствовать стандартам доступности (WCAG 2.1) для пользователей с ограниченными возможностями.
7. Сопровождаемость:
   • Модульность: Архитектура системы должна быть модульной для упрощения модификации, расширения и исправления ошибок.
   • Документация: Вся система должна быть тщательно задокументирована (архитектура, API, код).

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

Интеграционные требования ИС в цифровую экосистему ВУЗа

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

1. Интеграция с АСУ ВУЗа/Учетом студентов:
   • Автоматическая верификация статуса пользователя: Система библиотеки должна получать актуальные данные о статусе пользователя (студент, преподаватель, сотрудник) из АСУ ВУЗа. Это позволит автоматически регистрировать новых читателей и обновлять информацию об их статусе (например, об изменении факультета, группы, отчислении).
   • Управление абонементом на основе статуса: На основании полученных данных система должна автоматически корректировать права доступа к ресурсам и управлять абонементом. Например, при наличии академической задолженности или при отчислении студента должна автоматически блокироваться возможность выдачи новых книг и активироваться механизм уведомления о необходимости возврата текущих изданий. Это значительно снизит рутинную нагрузку на сотрудников библиотеки и повысит дисциплину возврата литературы.
   • Синхронизация персональных данных: Обеспечение регулярной синхронизации базовых персональных данных (ФИО, дата рождения, контактная информация) между АСУ ВУЗа и библиотечной ИС для поддержания актуальности информации.
2. Интеграция с СДО/LMS (Системой дистанционного обучения / Learning Management System):
   • Встраивание прямых ссылок на электронные ресурсы: Преподаватели должны иметь возможность встраивать прямые, стабильные ссылки на электронные ресурсы библиотеки (например, учебники, научные статьи, методические пособия) непосредственно в материалы учебных курсов в СДО/LMS. Это обеспечит бесшовный доступ студентов к необходимой литературе в контексте изучаемого материала.
   • Автоматическое формирование списков рекомендованной литературы: Возможность автоматического формирования списков рекомендованной литературы для курсов на основе данных из СДО/LMS, с последующим отображением доступности этих ресурсов в библиотечной ИС.
   • Аутентификация через СДО/LMS: Рассмотрение возможности единой точки входа (Single Sign-On, SSO) для пользователей, чтобы они могли получить доступ к библиотечным ресурсам, будучи уже авторизованными в СДО/LMS.

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

Проектирование архитектуры информационной системы и базы данных

Общая архитектура информационной системы библиотеки

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

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

1. Пользовательский интерфейс (Presentation Layer):
   • Веб-интерфейс для читателей: Основной канал взаимодействия для студентов, преподавателей и сотрудников, предоставляющий функции поиска, просмотра каталога, управления абонементом, доступа к электронным ресурсам. Должен быть адаптивным для работы на различных устройствах (ПК, планшеты, смартфоны).
   • Административный веб-интерфейс: Отдельный интерфейс для сотрудников библиотеки и администраторов системы, предназначенный для каталогизации, управления фондом, выдачей/приемом, настройкой прав доступа и генерации отчетов.
   • API для интеграции: Набор программных интерфейсов (например, RESTful API), который позволит другим университетским системам (АСУ ВУЗа, СДО/LMS) взаимодействовать с библиотечной ИС, обмениваться данными и вызывать ее функции.
2. Слой бизнес-логики (Application/Business Logic Layer):
   • Сервер приложений: Основной компонент, реализующий всю бизнес-логику системы. Здесь обрабатываются запросы от пользовательского интерфейса и API, выполняются операции с данными, применяются правила доступа и бизнес-процессы (например, проверка наличия книги перед выдачей, расчет штрафов).
   • Модули: Функционально выделенные блоки, такие как модуль каталогизации, модуль управления фондом, модуль абонемента, модуль авторизации, модуль поиска, модуль отчетности. Каждый модуль отвечает за свою специфическую часть функционала.
   • Интеграционные шлюзы: Компоненты, ответственные за взаимодействие с внешними системами (АСУ ВУЗа, СДО/LMS) через их API или другие протоколы обмена данными.
3. Слой доступа к данным (Data Access Layer):
   • ORM (Object-Relational Mapping): Технология, которая абстрагирует работу с базой данных, позволяя разработчикам работать с данными как с обычными объектами в коде, а не напрямую с SQL-запросами. Это повышает скорость разработки и упрощает изменение СУБД в будущем.
   • Драйверы СУБД: Компоненты, обеспечивающие непосредственное соединение и взаимодействие с выбранной системой управления базами данных.
4. Слой хранения данных (Data Layer):
   • База данных: Ядро системы, где хранятся все структурированные данные (информация о книгах, экземплярах, пользователях, выдачах, авторах). Выбор СУБД (PostgreSQL) для этого слоя будет подробно обоснован ниже.
   • Файловое хранилище: Отдельное хранилище для неструктурированных данных, таких как обложки книг, полнотекстовые версии электронных документов (PDF, EPUB) и другие медиафайлы. Это может быть локальное файловое хранилище или облачное решение.

Схема взаимодействия слоев:

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

graph TD
    subgraph "Пользовательский интерфейс"
        A[Веб-интерфейс Читателя]
        B[Административный Веб-интерфейс]
        C[API для интеграции]
    end

    subgraph "Слой бизнес-логики"
        D[Сервер приложений]
        E[Модуль Каталогизации]
        F[Модуль Абонемента]
        G[Модуль Поиска]
        H[Модуль Отчетности]
        I[Интеграционные Шлюзы]
    end

    subgraph "Слой доступа к данным"
        J[ORM]
        K[Драйверы СУБД]
    end

    subgraph "Слой хранения данных"
        L[База данных (PostgreSQL)]
        M[Файловое хранилище (Электронные документы)]
    end

    A -- HTTP/HTTPS --> D
    B -- HTTP/HTTPS --> D
    C -- REST/JSON --> D
    D -- Вызывает --> E
    D -- Вызывает --> F
    D -- Вызывает --> G
    D -- Вызывает --> H
    D -- Взаимодействует --> I
    D -- Использует --> J
    J -- Через --> K
    K -- SQL --> L
    D -- Читает/Записывает --> M
    I -- Обмен данными --> O[АСУ ВУЗа/Учет студентов]
    I -- Обмен данными --> P[СДО/LMS]

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

Концептуальное моделирование базы данных (ER-диаграмма)

Концептуальное моделирование является критически важным шагом в проектировании базы данных, позволяя визуализировать структуру данных и взаимосвязи между ними до их физической реализации. ER-диаграмма (Entity-Relationship Diagram) — это графическое представление структуры базы данных, которое показывает сущности, их атрибуты и связи между ними, являясь инструментом для проектирования реляционных баз данных. В отличие от UML-диаграммы классов, которая сфокусирована на структуре кода программы (объекты, атрибуты, методы, наследование) в рамках объектно-ориентированной разработки, ER-диаграмма служит именно для моделирования структуры хранения данных.

В основе ER-модели для библиотечной системы лежат ключевые сущности, отражающие основные объекты предметной области:

• Книга (Издание): Представляет собой метаданные об издании (название, ISBN, год издания, издательство).
• Автор: Информация об авторах книг.
• Экземпляр: Конкретная физическая или электронная копия книги, имеющая свой уникальный инвентарный номер и статус.
• Пользователь (Читатель): Информация о читателях библиотеки.
• Выдача: Запись о факте выдачи конкретного экземпляра книги конкретному пользователю на определенный срок.

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

1. Сущности и их атрибуты:

• Сущность: Книга
  • ID_Книги (Первичный ключ)
  • Название
  • ISBN
  • Год_издания
  • Издательство
  • Количество_страниц
  • Аннотация (может быть текстовым полем для хранения подробного описания)
  • Тип_издания (книга, статья, журнал, электронный ресурс)
  • Метаданные (например, JSONB поле для гибкого хранения дополнительных, неструктурированных данных)
• Сущность: Автор
  • ID_Автора (Первичный ключ)
  • ФИО
  • Дата_рождения
  • Страна
• Сущность: Экземпляр
  • ID_Экземпляра (Первичный ключ)
  • Инвентарный_номер
  • ID_Книги (Внешний ключ к сущности Книга)
  • Статус (доступен, выдан, в ремонте, списан)
  • Дата_поступления
  • Место_хранения (например, номер полки, URL для электронного экземпляра)
• Сущность: Пользователь
  • ID_Пользователя (Первичный ключ)
  • ФИО
  • Номер_студенческого_билета / Паспортные_данные
  • Дата_регистрации
  • Контактный_телефон
  • Email
  • Статус_пользователя (студент, преподаватель, сотрудник)
  • Логин
  • Пароль_хеш
• Сущность: Выдача
  • ID_Выдачи (Первичный ключ)
  • ID_Пользователя (Внешний ключ к сущности Пользователь)
  • ID_Экземпляра (Внешний ключ к сущности Экземпляр)
  • Дата_выдачи
  • Дата_возврата
  • Предполагаемая_дата_возврата
  • Штраф (если применимо)

2. Связи и кардинальность:

• Автор — Книга: Отношение «многие-ко-многим». Одна книга может быть написана несколькими авторами, и один автор может написать много книг.
  • Для реализации этого отношения потребуется промежуточная сущность (таблица): Автор_Книга
    • ID_Автора (Внешний ключ к Автор, часть составного первичного ключа)
    • ID_Книги (Внешний ключ к Книга, часть составного первичного ключа)
• Книга — Экземпляр: Отношение «один-ко-многим». Одна книга может иметь много экземпляров, но каждый экземпляр относится к одной книге.
  • Кардинальность: 1:N
• Пользователь — Выдача: Отношение «один-ко-многим». Один пользователь может иметь много выдач, но каждая выдача принадлежит одному пользователю.
  • Кардинальность: 1:N
• Экземпляр — Выдача: Отношение «один-ко-многим». Один экземпляр может быть выдан много раз (в разное время разным пользователям), но каждая запись о выдаче относится к одному конкретному экземпляру.
  • Кардинальность: 1:N

ER-диаграмма (пример):

erDiagram
    AUTHOR {
        int ID_Автора PK
        varchar ФИО
        date Дата_рождения
        varchar Страна
    }

    BOOK {
        int ID_Книги PK
        varchar Название
        varchar ISBN
        int Год_издания
        varchar Издательство
        int Количество_страниц
        text Аннотация
        varchar Тип_издания
        jsonb Метаданные
    }

    INSTANCE {
        int ID_Экземпляра PK
        varchar Инвентарный_номер
        int ID_Книги FK "Книга"
        varchar Статус
        date Дата_поступления
        varchar Место_хранения
    }

    USER {
        int ID_Пользователя PK
        varchar ФИО
        varchar Номер_студенческого_билета
        date Дата_регистрации
        varchar Контактный_телефон
        varchar Email
        varchar Статус_пользователя
        varchar Логин
        varchar Пароль_хеш
    }

    LOAN {
        int ID_Выдачи PK
        int ID_Пользователя FK "Пользователь"
        int ID_Экземпляра FK "Экземпляр"
        date Дата_выдачи
        date Дата_возврата
        date Предполагаемая_дата_возврата
        decimal Штраф
    }

    AUTHOR ||--o{ AUTHOR_BOOK : "написал"
    BOOK ||--o{ AUTHOR_BOOK : "имеет"
    BOOK ||--o{ INSTANCE : "состоит из"
    USER ||--o{ LOAN : "осуществил"
    INSTANCE ||--o{ LOAN : "был выдан"

    AUTHOR_BOOK {
        int ID_Автора PK,FK "Автор"
        int ID_Книги PK,FK "Книга"
    }

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

Выбор и обоснование СУБД

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

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

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

PostgreSQL:
Для создания сложных корпоративных приложений, требующих сложной обработки данных, расширяемости и строгой приверженности стандартам SQL, часто предпочитают PostgreSQL. PostgreSQL — это объектно-реляционная СУБД, известная своей надежностью, целостностью данных и поддержкой расширенного набора типов данных, включая массивы, JSONB (бинарный JSON) и геопространственные данные.

• Преимущества:
  • Надежность и целостность данных: PostgreSQL строго соответствует стандартам ACID (Atomicity, Consistency, Isolation, Durability), обеспечивая высокую целостность и сохранность данных, что критически важно для библиотечных систем, где точность учета фондов и читателей имеет первостепенное значение.
  • Расширенные типы данных и объектно-реляционные возможности: Поддержка JSONB позволяет гибко хранить неструктурированные и полуструктурированные метаданные для книг (например, информацию о редкости, дополнительных тегах, ссылках на обзоры), без необходимости постоянного изменения схемы базы данных. Это особенно ценно для электронных библиотек, где объемы и форматы метаданных могут быть весьма разнообразны.
  • Масштабируемость и производительность: PostgreSQL обладает мощными механизмами для горизонтального и вертикального масштабирования, включая репликацию, партиционирование таблиц и эффективное управление индексов. Postgres Professional, российский разработчик на базе PostgreSQL, занимает второе место в мире по вкладу в развитие открытой системы PostgreSQL и разработала 64-битные счетчики транзакций для высоконагруженных систем, обеспечивающие устойчивость при миллиардах пользователей.
  • Расширяемость: Благодаря возможности создавать пользовательские функции, типы данных и операторы, PostgreSQL может быть адаптирован под специфические требования.
  • Поддержка стандартов SQL: Строгая приверженность стандартам SQL упрощает миграцию и взаимодействие с другими системами.
  • Актуальность в РФ и импортозамещение: PostgreSQL является основной платформой импортозамещения в российском банковском секторе, и к 2025 году до 85% СУБД в банках могут составлять решения на базе PostgreSQL. Крупные российские компании, такие как РЖД, «Росатом», «Газпромнефть», Федеральная налоговая служба, Федеральное казначейство и МИД, используют Postgres Pro (базирующуюся на PostgreSQL) для enterprise-задач. Это подчеркивает ее надежность и применимость для крупных и ответственных проектов в России. На российском рынке СУБД в 2024 году общий объем составил 89,5 млрд рублей, что на 34% больше, чем в 2023 году, при этом 48% приходится на СУБД общего назначения, а 32% на аналитические системы. Прогнозируется, что к 2031 году российские СУБД займут до 99% рынка.

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

Исходя из требований к проектируемой ИС электронной библиотеки, PostgreSQL является оптимальным выбором.

• Во-первых, потребность в высокой целостности и надежности данных (учет книг, экземпляров, читателей) полностью покрывается строгим соблюдением ACID-свойств PostgreSQL.
• Во-вторых, гибкость в работе с разнообразными метаданными электронных ресурсов является ключевым преимуществом. Нативная поддержка JSONB в PostgreSQL позволяет эффективно хранить и индексировать произвольные атрибуты для книг и других изданий, что не столь развито в MySQL.
• В-третьих, масштабируемость PostgreSQL критически важна для университетской библиотеки, которая со временем будет обслуживать растущее число студентов и фондов.
• Наконец, актуальность и поддержка PostgreSQL в российском корпоративном секторе соответствует стратегическим задачам импортозамещения и обеспечивает уверенность в долгосрочной поддержке и развитии выбранной СУБД.

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

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

Функциональные модули информационной системы

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

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

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

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

Для успешной реализации проекта создания/модернизации ИС электронной библиотеки необходимо разработать детальное техническое задание (ТЗ) и спецификацию аппаратного и программного обеспечения.

Техническое задание (ТЗ)

ТЗ является основным документом, регламентирующим содержание, сроки, порядок выполнения работ по созданию ИС, а также требования к ее функциям, качеству и условиям эксплуатации. Оно будет разработано в соответствии с ГОСТ 34.602-2020 «Информационные технологии. Комплекс стандартов на автоматизированные системы. Техническое задание на создание (развитие) автоматизированной системы».

Основные разделы ТЗ будут включать:

1. Общие положения:
   • Полное наименование ИС: «Информационная система электронной библиотеки СПбГЭТУ».
   • Цели и задачи создания/модернизации ИС.
   • Перечень документации, на основе которой создается ИС (данная дипломная работа, стандарты, нормативные акты).
2. Назначение и цели создания (модернизации) ИС:
   • Детальное описание проблем, которые решает ИС (см. раздел «Анализ существующей системы»).
   • Ожидаемые результаты и эффекты от внедрения.
3. Характеристика объекта автоматизации:
   • Описание библиотеки как объекта автоматизации, ее структуры, основных функций, текущих процессов.
   • Описание пользователей ИС (читатели, сотрудники, администраторы).
4. Требования к ИС:
   • Требования к функционалу (см. раздел «Функциональные требования»):
     • Управление каталогом и фондом.
     • Управление абонементом (выдача/прием, задолженности).
     • Управление пользователями.
     • Поиск и доступ к ресурсам.
     • Отчетность и аналитика.
     • Администрирование.
   • Требования к нефункциональным характеристикам (см. раздел «Нефункциональные требования»):
     • Производительность (время отклика, пропускная способность).
     • Надежность (доступность, восстановление после сбоев, целостность данных, резервное копирование).
     • Безопасность (аутентификация, авторизация, шифрование, соответствие 152-ФЗ).
     • Масштабируемость.
     • Сопровождаемость.
     • Удобство использования.
   • Требования к видам обеспечения:
     • Информационное обеспечение (структура БД, форматы данных).
     • Программное обеспечение (системное, прикладное).
     • Аппаратное обеспечение.
     • Организационное и методическое обеспечение (регламенты, инструкции).
     • Правовое обеспечение.
   • Требования к интеграции:
     • Взаимодействие с АСУ ВУЗа (верификация статуса, управление абонементом).
     • Взаимодействие с СДО/LMS (встраивание ссылок, синхронизация учебных курсов).
5. Состав и содержание работ по созданию (модернизации) ИС:
   • Перечень этапов и стадий работ (в соответствии с выбранной Agile-методологией).
   • Результаты каждого этапа (документация, прототипы, рабочие версии).
6. Порядок контроля и приемки ИС:
   • Виды, объем и порядок испытаний (автономные, комплексные, опытная эксплуатация).
   • Критерии приемки.
7. Требования к составу и содержанию работ по подготовке объекта автоматизации к вводу ИС в действие:
   • Обучение персонала.
   • Подготовка инфраструктуры.
8. Требования к документированию:
   • Перечень необходимой документации (пользовательская, административная, проектная).
9. Источники разработки:
   • Перечень использованных стандартов, нормативных документов, исследований.

Спецификация аппаратного/программного обеспечения

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

Аппаратное обеспечение (серверная часть):

• Сервер базы данных (PostgreSQL):
  • Процессор: 8-ядерный процессор (например, Intel Xeon E5 или AMD EPYC), 2.5 ГГц и выше.
  • ОЗУ: 64 ГБ DDR4 (рекомендуется 128 ГБ для больших объемов данных и высокой нагрузки).
  • Дисковая подсистема: SSD NVMe ёмкостью от 2 ТБ (минимум 1 ТБ), RAID 10 для обеспечения производительности и отказоустойчивости.
  • Сетевой интерфейс: 2 x 1 Гбит/с Ethernet.
• Сервер приложений (Web-сервер):
  • Процессор: 4-ядерный процессор, 2.0 ГГц и выше.
  • ОЗУ: 32 ГБ DDR4.
  • Дисковая подсистема: SSD SATA ёмкостью 500 ГБ (RAID 1).
  • Сетевой интерфейс: 1 Гбит/с Ethernet.
• Резервное копирование: Отдельный накопитель или сетевое хранилище (NAS/SAN) с достаточным объемом для хранения резервных копий.

Программное обеспечение:

• Операционная система для серверов:
  • Linux (например, Ubuntu Server LTS, CentOS Stream, Astra Linux Special Edition) — предпочтительно, как более стабильная, безопасная и экономичная платформа для СУБД и веб-серверов.
• СУБД:
  • PostgreSQL (версия 15 или выше) — с учетом всех обоснований, приведенных ранее. Возможно использование Postgres Pro Enterprise для поддержки enterprise-функций.
• Среда выполнения приложений:
  • Python (версия 3.9+) с фреймворком Django/Flask или Java (OpenJDK 17+) с фреймворком Spring Boot.
  • Веб-сервер: Nginx (для обратного проксирования и статики) или Apache HTTP Server.
• Контейнеризация (опционально, но рекомендуется):
  • Docker и Docker Compose для упрощения развертывания и управления компонентами.
• Система контроля версий: Git.
• Средства мониторинга: Prometheus, Grafana.
• Система управления задачами: Jira, YouTrack (для Agile-разработки).

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

Демонстрация решения выявленных проблем

Предложенное техническое решение, основанное на модульной архитектуре, гибких методологиях разработки и СУБД PostgreSQL, адресно устраняет конкретные проблемы управления библиотекой, выявленные на этапе анализа. Рассмотрим, как каждый аспект разработанного проекта способствует разрешению этих «болевых точек»:

1. Проблема: Затрудненный поиск и каталогизация литературы, неактуальные данные о наличии экземпляров, ручная обработка.
   • Решение:
     • Модуль каталогизации и управления фондом: Полностью автоматизирует ввод, хранение и обновление информации о книгах и их экземплярах. Использование PostgreSQL с типом данных JSONB позволяет гибко хранить разнообразные метаданные, значительно упрощая и обогащая процесс каталогизации. Электронные экземпляры (PDF, EPUB) будут централизованно храниться и индексироваться.
     • Модуль поиска и доступа к ресурсам: Реализует расширенный и полнотекстовый поиск, позволяя студентам и преподавателям быстро находить нужную литературу по множеству критериев, включая содержимое электронных документов. Актуальность данных о наличии экземпляров гарантируется онлайн-обновлением информации при каждой операции выдачи/приема.
     • Результат: Время на поиск сокращается с 10-20 минут до нескольких секунд. Точность информации о фонде достигает почти 100%. Сотрудники библиотеки освобождаются от рутинной работы, минимизируются ошибки каталогизации.
2. Проблема: Ручные или полуавтоматизированные процессы выдачи/приема, очереди, неэффективный учет задолженностей.
   • Решение:
     • Модуль абонемента и выдачи/приема: Полностью автоматизирует все операции: сканирование штрих-кода экземпляра и идентификатора пользователя для выдачи; автоматическая фиксация даты возврата; расчет штрафов. Система автоматически отправляет уведомления о приближающемся сроке возврата или просрочке.
     • Результат: Сокращение времени выдачи/приема одной книги с 2-3 минут до 30 секунд. Устранение очередей в пиковые часы. Повышение оборачиваемости фонда и дисциплины возврата благодаря автоматизированным уведомлениям и расчету штрафов.
3. Проблема: Отсутствие полноценной интеграции с другими университетскими системами (АСУ ВУЗа, СДО/LMS).
   • Решение:
     • Интеграционные требования и API: Разработанные интеграционные шлюзы и API позволяют библиотечной ИС взаимодействовать с АСУ ВУЗа для автоматической верификации статуса пользователя, его регистрации и управления абонементом (например, блокировка выдачи при отчислении). Интеграция с СДО/LMS обеспечивает возможность встраивания прямых ссылок на электронные ресурсы библиотеки в учебные курсы.
     • Результат: Создание единого цифрового пространства университета. Автоматизация верификации пользователей, что снижает административную нагрузку. Увеличение доступности и использования электронных ресурсов библиотеки через прямое встраивание в учебный процесс.
4. Проблема: Неудобный доступ и негибкая система хранения электронных ресурсов.
   • Решение:
     • PostgreSQL с JSONB и файловое хранилище: Объектно-реляционная СУБД PostgreSQL с поддержкой JSONB позволяет эффективно хранить структурированные и полуструктурированные метаданные электронных ресурсов, а выделенное файловое хранилище обеспечивает надежное размещение самих файлов (PDF, EPUB). Полнотекстовый поиск по этим документам значительно улучшает возможности обнаружения контента.
     • Модуль поиска и доступа к ресурсам: Предоставляет интуитивно понятный интерфейс для доступа к электронным ресурсам, включая возможность просмотра онлайн и скачивания (с учетом прав доступа).
     • Результат: Улучшение пользовательского опыта при работе с электронными ресурсами. Гибкость в управлении разнообразными форматами и метаданными.
5. Проблема: Отсутствие актуальной отчетности и аналитики для принятия управленческих решений.
   • Решение:
     • Модуль отчетности и аналитики: Автоматически генерирует детальные отчеты по всем аспектам работы библиотеки (фонд, активность читателей, задолженности). Возможность экспорта данных и визуализации помогает администрации принимать обоснованные решения.
     • Результат: Повышение прозрачности и управляемости библиотечными процессами, возможность оперативного анализа и планирования.

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

Экономическое обоснование эффективности внедрения ИС

Расчет капитальных и операционных затрат

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

1. Капитальные затраты (КЗ) — разовые вложения:

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

• 1.1. Стоимость лицензий (если применимо):
  • Поскольку в качестве СУБД выбрана PostgreSQL (с открытым исходным кодом), прямые лицензионные отчисления на СУБД отсутствуют. Однако, если будет выбрана коммерческая сборка (например, Postgres Pro Enterprise), могут возникнуть затраты на лицензии и поддержку. Для данного проекта, ориентирующегося на открытые решения, принимаем 0 руб.
  • Стоимость лицензий на операционные системы (например, Astra Linux Special Edition) для серверов: 2 лицензии × 30 000 руб. = 60 000 руб.
  • Прочее ПО (например, коммерческий BI-инструмент для отчетности, если потребуется, или инструменты разработки): 50 000 руб.
  • Итого стоимость лицензий: 110 000 руб.
• 1.2. Стоимость аппаратного обеспечения (серверов):
  • Сервер базы данных: 350 000 руб. (включая дисковую подсистему и резервное питание).
  • Сервер приложений: 200 000 руб.
  • Сетевое оборудование (коммутатор, кабели): 50 000 руб.
  • Итого стоимость аппаратного обеспечения: 600 000 руб.
• 1.3. Стоимость разработки/внедрения: Это наиболее значительная статья затрат, включающая трудозатраты проектной команды. Расчет будет производиться исходя из трудоемкости и средней стоимости часа работы специалистов.
  • Аналитик: 200 часов × 1500 руб./час = 300 000 руб. (сбор требований, проектирование, документирование)
  • Разработчик (backend): 500 часов × 2000 руб./час = 1 000 000 руб. (разработка логики, интеграций, API)
  • Разработчик (frontend): 400 часов × 1800 руб./час = 720 000 руб. (разработка пользовательских интерфейсов)
  • Специалист по базам данных: 150 часов × 1700 руб./час = 255 000 руб. (проектирование БД, оптимизация, настройка)
  • Тестировщик: 250 часов × 1200 руб./час = 300 000 руб. (функциональное, интеграционное, нагрузочное тестирование)
  • Менеджер проекта: 100 часов × 2500 руб./час = 250 000 руб. (управление проектом, коммуникации)
  • Консалтинг и обучение: 150 000 руб. (экспертная поддержка, обучение персонала библиотеки).
  • Итого стоимость разработки/внедрения (З_{Пр, оц}): 2 975 000 руб.

Суммарные капитальные затраты (З_{К, оц} + З_{Пр, оц}) = 110 000 (Лицензии) + 600 000 (Оборудование) + 2 975 000 (Разработка) = 3 685 000 руб.

2. Операционные затраты (TCO — Total Cost of Ownership) — ежегодная поддержка:

Операционные затраты — это стоимость ежегодной поддержки внедренного решения.

• 2.1. Содержание внутренней команды поддержки / Аутсорсинг:
  • Поддержка СУБД и серверов (частичная занятость администратора): 0.25 ставки × 100 000 руб./месяц × 12 месяцев = 300 000 руб./год.
  • Поддержка ПО и исправление ошибок (частичная занятость разработчика): 0.2 ставки × 150 000 руб./месяц × 12 месяцев = 360 000 руб./год.
  • Итого затраты на поддержку персонала: 660 000 руб./год.
• 2.2. Стоимость электроэнергии и охлаждения серверов:
  • 2 сервера × (400 Вт × 24 часа × 365 дней / 1000) кВт·ч × 8 руб./кВт·ч = 2 × 3504 × 8 ≈ 56 064 руб./год.
• 2.3. Обновление лицензий (если применимо):
  • Ежегодное обновление лицензий на ОС и прочее ПО (10% от первоначальной стоимости): 110 000 руб. × 0.1 = 11 000 руб./год.
• 2.4. Обновление аппаратного обеспечения (амортизация):
  • Примем срок амортизации серверов 5 лет. Ежегодные отчисления: 600 000 руб. / 5 лет = 120 000 руб./год.

Суммарные ежегодные операционные затраты (З_{Тек, оц}): 660 000 + 56 064 + 11 000 + 120 000 = 847 064 руб./год.

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

Расчет годового экономического эффекта и возврата инвестиций (ROI)

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

1. Оценка экономии затрат (базовый вариант до внедрения):

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

• 1.1. Фонд оплаты труда сотрудников, занятых рутинными операциями:
  • Каталогизация и учет: 2 сотрудника × 60 000 руб./месяц × 12 месяцев = 1 440 000 руб./год. (частичная занятость на ручной каталогизации, сверке, инвентаризации).
  • Выдача/прием и работа с задолженностями: 3 сотрудника × 55 000 руб./месяц × 12 месяцев = 1 980 000 руб./год. (обслуживание читателей, ручное уведомление о просрочках).
  • Итого ФОТ на рутинные операции: 3 420 000 руб./год.
• 1.2. Затраты на бумажные носители, расходные материалы:
  • Печать формуляров, уведомлений, отчетов: 50 000 руб./год.
• 1.3. Штрафы/потери из-за неэффективного учета:
  • Потери от невозврата книг, списание из-за утери (гипотетически): 100 000 руб./год.
  • Упущенная выгода от неоптимального использования фонда (например, несвоевременное пополнение популярных книг): 200 000 руб./год.
  • Итого потери: 300 000 руб./год.

Суммарные текущие затраты по базовому варианту (З_{Тек, б}): 3 420 000 + 50 000 + 300 000 = 3 770 000 руб./год.

2. Расчет годового экономического эффекта (Эф):

Эф = З_{Тек, б} − З_{Тек, оц}

Где:

• З_{Тек, б} = 3 770 000 руб./год (текущие затраты до внедрения)
• З_{Тек, оц} = 847 064 руб./год (операционные затраты после внедрения)

Эф = 3 770 000 − 847 064 = 2 922 936 руб./год.

Таким образом, годовой экономический эффект от внедрения новой информационной системы составит 2 922 936 рублей.

3. Расчет коэффициента возврата инвестиций (ROI):

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

ROI = (Пр_оц + З_{Тек, б} − З_{Тек, оц}) / (З_{К, оц} + З_{Пр, оц})

Где:

• Пр_оц — суммарная прибыль за весь период. В данном случае, прямая прибыль от библиотечной системы отсутствует, поэтому Пр_оц = 0. Все выгоды рассматриваются как сокращение затрат.
• З_{Тек, б} − З_{Тек, оц} = Эф = 2 922 936 руб./год.
• З_{К, оц} + З_{Пр, оц} = 3 685 000 руб. (суммарные капитальные и проектные затраты).

Для расчета ROI необходимо определить период, за который он рассчитывается. Обычно для IT-проектов рассматривается период от 3 до 5 лет. Возьмем период в 3 года.

Суммарный экономический эффект за 3 года = Эф × 3 года = 2 922 936 руб./год × 3 = 8 768 808 руб.

Теперь подставим значения в формулу ROI:

ROI = (0 + 8 768 808) / 3 685 000 ≈ 2.38

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

Определение срока окупаемости капиталовложений

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

Для расчета простого срока окупаемости используется формула:

Т_ок = (З_{К, оц} + З_{Пр, оц}) / (Годовая_Пр + Эф)

Где:

• З_{К, оц} + З_{Пр, оц} = 3 685 000 руб. (суммарные капитальные и проектные затраты).
• Годовая_Пр — годовая прибыль от внедрения ИС. В нашем случае прямая прибыль отсутствует, поэтому Годовая_Пр = 0.
• Эф = 2 922 936 руб./год (годовой экономический эффект, или годовая экономия затрат).

Подставим значения в формулу:

Т_ок = 3 685 000 / (0 + 2 922 936) ≈ 1.26 лет.

Полученный срок окупаемости составляет приблизительно 1 год и 3 месяца.

Анализ полученного результата:

Для IT- и онлайн-сервисов нормальным сроком окупаемости может быть 6-12 месяцев. В целом, окупаемость проекта за 1-3 года считается хорошим показателем. Для небольших проектов нормальный срок окупаемости составляет от полутора до 3 лет, для крупных — может достигать 10-15 лет.

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

Анализ рисков проекта

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

1. Технические риски:

• Несовместимость с существующей инфраструктурой: Новая ИС может плохо интегрироваться с устаревшим оборудованием или ПО.
  • Меры минимизации: Тщательное предварительное аудирование существующей IT-инфраструктуры, разработка детальной спецификации оборудования и ПО, проведение пилотных проектов и интеграционного тестирования.
• Ошибки в проектировании или разработке: Недостатки в архитектуре БД, ошибки в коде или некорректная реализация функционала.
  • Меры минимизации: Применение стандартизированных методологий (Agile, Scrum), регулярные ревью кода, автоматизированное тестирование (юнит-тесты, интеграционные тесты), привлечение опытных специалистов.
• Проблемы с производительностью СУБД: Недостаточная производительность PostgreSQL при высокой нагрузке или больших объемах данных.
  • Меры минимизации: Проектирование с учетом масштабируемости, нагрузочное тестирование, оптимизация запросов, настройка СУБД, использование возможностей PostgreSQL (партиционирование, индексирование).

2. Организационные и управленческие риски:

• Недостаточная поддержка со стороны руководства: Отсутствие полной поддержки проекта на высоком уровне может привести к нехватке ресурсов или задержкам.
  • Меры минимизации: Регулярное информирование руководства о ходе проекта, демонстрация промежуточных результатов, обоснование выгод.
• Сопротивление изменениям со стороны персонала: Сотрудники библиотеки могут не принять новую систему из-за страха перед новым, нежелания учиться или потери рабочих мест.
  • Меры минимизации: Активное вовлечение сотрудников в процесс проектирования (сбор требований), обучение, демонстрация преимуществ для их работы, разъяснительная работа, создание системы мотивации.
• Недостаточная квалификация команды проекта: Нехватка компетенций у разработчиков, аналитиков или тестировщиков.
  • Меры минимизации: Привлечение квалифицированных специалистов, организация обучения, аутсорсинг критически важных компетенций, тщательный подбор команды.
• Изменение требований в ходе проекта: Непредвиденные изменения в функциональных или нефункциональных требованиях.
  • Меры минимизации: Использование Agile-методологий, которые позволяют гибко реагировать на изменения, итерационная разработка с частыми обратными связями от заказчика.

3. Финансовые риски:

• Превышение бюджета: Непредвиденные расходы, недооценка стоимости ресурсов.
  • Меры минимизации: Детальное планирование бюджета, резервирование средств на непредвиденные расходы (до 15-20% от общего бюджета), постоянный мониторинг фактических затрат.
• Недостаточная окупаемость инвестиций: Экономический эффект оказался ниже ожидаемого.
  • Меры минимизации: Реалистичная оценка экономического эффекта, регулярный анализ ROI после внедрения, корректировка бизнес-процессов для максимизации отдачи.

4. Риски безопасности:

• Утечка данных: Несанкционированный доступ к конфиденциальной информации пользователей или фондов.
  • Меры минимизации: Внедрение строгих политик безопасности (шифрование данных, MFA, RBAC), регулярный аудит безопасности, использование защищенных протоколов связи, соответствие законодательству (152-ФЗ).
• Вредоносные атаки: DDoS-атаки, вирусы, попытки взлома.
  • Меры минимизации: Использование брандмауэров, систем обнаружения вторжений, регулярное обновление ПО, резервное копирование, создание плана восстановления после сбоев (DRP).

5. Риски интеграции:

• Сложности интеграции с АСУ ВУЗа/СДО/LMS: Проблемы с обменом данными, несовместимость API или форматов данных.
  • Меры минимизации: Детальное изучение документации по API внешних систем, создание тестовых сред для интеграции, поэтапное внедрение интеграционных модулей, тесное взаимодействие с владельцами внешних систем.

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

Заключение

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

Мы начали с детального анализа предметной области, актуализировав понятия информационных систем и систем управления базами данных, а также подробно рассмотрели жизненный цикл ИС в соответствии с ГОСТ Р 57193-2016. Особое внимание было уделено обоснованию выбора гибких методологий разработки, таких как Agile (Scrum), опираясь на актуальную статистику их успешного применения в российской IT-индустрии и их способность эффективно реагировать на меняющиеся требования.

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

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

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

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

Основные преимущества разработанной ИС:

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

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

1. Внедрение элементов искусственного интеллекта: Разработка рекомендательных систем для читателей на основе их истории выдач и предпочтений, а также для автоматической категоризации новых поступлений.
2. Мобильное приложение: Создание нативного мобильного приложения для iOS и Android, расширяющего доступность сервисов библиотеки.
3. Расширение функционала электронных ресурсов: Интеграция с агрегаторами научных статей и электронных книг, развитие функционала онлайн-чтения с возможностью аннотирования.
4. Улучшение аналитики: Внедрение более сложных аналитических инструментов и BI-дашбордов для глубокого анализа данных о фонде и читателях.
5. Блок управления доступом к платным ресурсам: Интеграция с системами подписки для управления доступом к коммерческим базам данных и журналам.

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

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

1. Бакаревич, Ю. Б. MS Access 2007 за 30 занятий. Санкт-Петербург : БХВ-Петербург, 2010. 510 с.
2. Бакаревич, Ю. Б. Самоучитель Microsoft Access 2000. Санкт-Петербург : БХВ-Петербург, 2001. 468 с.
3. Братищенко, В. В. Проектирование информационных систем. Иркутск : Изд-во БГУЭП, 2004. 84 с.
4. Вендров, А. М. CASE-технологии. Современные методы и средства проектирования информационных систем. Москва : Финансы и статистика, 2004. 202 с.
5. Горелик, О. М. Управленческий учет и анализ : учебное пособие для вузов по специальности «Прикладная информатика (по обл.)» и др. экон. специальностям. Москва : КноРус, 2007. 252 с.
6. Граничин, О. Н. Информационные технологии в управлении : учебное пособие для студентов вузов, обучающихся по специальностям «Прикладная информатика (по областям)» и «Менеджмент организации (по специализации «Информационный менеджмент»)». Москва : Интернет-Ун-т Информ. Технологий, 2010. 335 с.
7. Гринберг, А. С. Информационные технологии управления : Учебное пособие для вузов по специальностям 351400 «Прикладная информатика (по обл.)», 061100 «Менеджмент орг.», 061000 «Гос. и муницип. упр.». Москва : ЮНИТИ, 2010. 479 с.
8. Диго, С. М. Базы данных: проектирование и использование : Учебное пособие для вузов по специальности «Прикладная информатика (по обл.)». Москва : Финансы и статистика, 2010. 591 с.
9. Золотова, С. И. Практикум по Access. Москва : Финансы и статистика, 2010. 144 с.
10. Кен Блюттман, Уайн Фриз. Анализ данных в Access. Сборник рецептов. Москва : Финансы и статистика, 2010. 215 с.
11. Лайхер, Р. Способы расчета затрат и прибыли. Москва : Омега-Л, 2006. 144 с.
12. Проектирование экономических систем : Учебник / Г.Н.Смирнова, А.А.Сорокин, Ю.Ф.Тельнов. Москва : Финансы и статистика, 2010. 352 с.
13. Федоров, А. В. Проектирование информационных систем. Москва : Финансы и статистика, 2003. 544 с.
14. AGILE-ПОДХОД К РАЗРАБОТКЕ ПРОГРАММНЫХ ПРОДУКТОВ: ИСТОКИ И ПЕРСПЕКТИВЫ. URL: https://cyberleninka.ru/article/n/agile-podhod-k-razrabotke-programmnyh-produktov-istoki-i-perspektivy
15. ER-диаграммы для системы управления библиотекой: Полное руководство. URL: https://wondershare.com.ru/mind-map/library-management-system-er-diagram.html
16. PostgreSQL против MySQL: комплексное сравнение по 8 факторам. URL: https://www.astera.com/ru/blogs/postgresql-vs-mysql/
17. PostgreSQL vs MySQL: чем отличаются и что лучше из этих СУБД? URL: https://cyberprotect.ru/blog/postgresql-vs-mysql
18. Интегративная функция библиотеки в информационно-образовательном пространстве вуза. URL: https://cyberleninka.ru/article/n/integrativnaya-funktsiya-biblioteki-v-informatsionno-obrazovatelnom-prostranstve-vuza
19. Интеграция библиотеки в ИТ-инфраструктуру вуза: вызовы и перспективы. URL: https://libinform.ru/magazine/library-integration-into-university-it-infrastructure-challenges-and-prospects
20. ЖИЗНЕННЫЙ ЦИКЛ ИНФОРМАЦИОННЫХ СИСТЕМ. URL: https://cyberleninka.ru/article/n/zhiznennyy-tsikl-informatsionnyh-sistem
21. Методология Agile для реализации проектов по разработке информационных систем. URL: https://cyberleninka.ru/article/n/metodologiya-agile-dlya-realizatsii-proektov-po-razrabotke-informatsionnyh-sistem
22. Особенности программной архитектуры предприятия: элементы и объекты IT-архитектуры. URL: https://www.xcom.ru/articles/osobennosti-programmnoj-arhitektury-predpriyatiya-elementy-i-obekty-it-arhitektury.html
23. ПРАКТИКА ПРИМЕНЕНИЯ МЕТОДОЛОГИЙ AGILE, SCRUM В ИТ-ПРОЕКТАХ. URL: https://cyberleninka.ru/article/n/praktika-primeneniya-metodologiy-agile-scrum-v-it-proektah
24. Расчет ROI при внедрении информационной системы. URL: https://www.osp.ru/articles/2012/0329/13012976/
25. СОВРЕМЕННЫЕ ПОДХОДЫ К РАЗРАБОТКЕ ИНФОРМАЦИОННЫХ СИСТЕМ. URL: https://cyberleninka.ru/article/n/sovremennye-podhody-k-razrabotke-informatsionnyh-sistem
26. Функциональные и нефункциональные требования: ключевые различия. URL: https://scand.com/ru/article/funkcionalnye-i-nefunkcionalnye-trebovaniya/
27. Функциональные и нефункциональные требования — что это, как разработать, примеры требований. URL: https://yandex.ru/business/academy/articles/funktsionalnye-i-nefunktsionalnye-trebovaniya
28. Что выбрать для проектирования БД: сравнение UML-диаграммы классов и ER-диаграммы. URL: https://getanalyst.ru/blog/uml-vs-er-diagrams
29. ЭКОНОМИКА ИНФОРМАЦИОННЫХ СИСТЕМ. URL: https://fa.ru/fil/omsk/news/2021/Documents/26.pdf