Проектирование и реализация автоматизированной системы «Автовокзал-2»: Комплексный план курсовой работы с учетом современных стандартов и методологий

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

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

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

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

Глава 1. Теоретические основы автоматизированных систем и программной инженерии

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

1.1. Основные понятия программной инженерии и системного анализа

В основе создания любой автоматизированной системы лежит строгий, дисциплинированный подход, который объединяет в себе элементы науки и искусства. Этот подход получил название программной инженерии. Согласно международному стандарту ISO/IEC/IEEE 24765:2017, программная инженерия определяется как приложение систематического, дисциплинированного, измеримого подхода к разработке, функционированию и сопровождению программного обеспечения, а также к исследованию этих подходов. Иными словами, это не просто написание кода, а комплексная инженерная дисциплина, охватывающая все стадии жизненного цикла ПО – от первоначальной спецификации до поддержки системы после её ввода в эксплуатацию. Программная инженерия стремится сделать процесс создания ПО предсказуемым, контролируемым и эффективным, используя лучшие практики, стандарты и инструменты. И что из этого следует? Понимание этих принципов позволяет создавать не просто работающий код, а надёжные, масштабируемые и безопасные решения, способные выдерживать высокие нагрузки и адаптироваться к изменяющимся условиям.

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

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

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

1.2. Жизненный цикл и архитектура информационных систем

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

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

• Каскадная (Waterfall) модель: Это классический линейный подход, где каждый этап (анализ, проектирование, реализация, тестирование, внедрение, сопровождение) завершается до начала следующего. Её преимущества в строгой документации и предсказуемости, что делает её подходящей для проектов с чётко определёнными требованиями, как, например, начальные этапы проектирования Автовокзал-2, где требуется глубокий анализ предметной области.
• Итеративная/Инкрементальная модель (RUP — Rational Unified Process): Предполагает разбиение проекта на итерации, каждая из которых включает в себя мини-цикл проектирования, реализации и тестирования. RUP фокусируется на раннем выявлении рисков и постоянной обратной связи, что полезно для постепенного наращивания функционала.
• Гибкие (Agile) методологии: Такие как Scrum или Kanban, ориентированы на быструю адаптацию к изменениям, тесное взаимодействие с заказчиком и итеративную разработку с короткими циклами. Agile подход может быть особенно ценен на этапах реализации и доработки системы Автовокзал-2, позволяя оперативно реагировать на меняющиеся потребности и уточнения.

Выбор модели жизненного цикла зависит от множества факторов: размера проекта, стабильности требований, доступности ресурсов и уровня риска. Для Автовокзал-2 можно рассмотреть гибридный подход, сочетающий элементы Waterfall для этапов глубокого анализа и проектирования, и Agile для итеративной реализации и тестирования. В чём кроется важный нюанс такого выбора? При таком подходе, фундаментальные архитектурные решения принимаются заранее, что снижает риски на поздних стадиях, а гибкие методы позволяют быстро адаптироваться к изменениям требований к функционалу, что особенно ценно в динамичной среде транспортных услуг.

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

1.3. Бизнес-процессы и модели данных

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

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

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

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

Глава 2. Анализ предметной области Автовокзал и требований к системе Автовокзал-2

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

2.1. Актуальность автоматизации автовокзалов

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

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

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

Внедрение автоматизированной системы Автовокзал-2 призвано полностью трансформировать эти процессы, обеспечивая ряд значительных преимуществ:

• Высокая слаженность работы и продуктивность: Автоматизация связывает все звенья цепочки — от кассира до диспетчера, обеспечивая мгновенный обмен информацией и координацию действий.
• Полный контроль над работой сотрудников и выручкой: Система предоставляет прозрачную статистику продаж, действий персонала и позволяет отслеживать финансовые потоки в реальном времени, минимизируя риски недобросовестных действий.
• Дополнительные доходы от предварительной и удалённой продажи билетов: Возможность онлайн-покупки, бронирования через терминалы или партнёрские сети значительно расширяет клиентскую базу и увеличивает оборот.
• Гибкие тарифы и увеличение объёмов/географии продаж: Автоматизированные инструменты позволяют быстро изменять ценовую политику, внедрять акции и расширять сеть продаж.
• Повышение качества обслуживания пассажиров: Онлайн-бронирование, SMS-информирование о статусе рейса, электронные табло с актуальной информацией и автоинформаторы создают комфортную и современную среду для пассажиров, значительно улучшая их опыт взаимодействия с автовокзалом.

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

2.2. Обзор существующих аналогов и рыночных решений

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

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

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

Примеры существующих решений:

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

Ключевые технологии и подходы, используемые в аналогах:

• Базы данных: Чаще всего используются реляционные СУБД (PostgreSQL, MySQL, MS SQL Server) для хранения структурированных данных о рейсах, билетах, пассажирах.
• Языки программирования и фреймворки: Для бэкенда — Java (Spring), Python (Django, Flask), C# (.NET), PHP (Laravel). Для фронтенда — JavaScript (React, Angular, Vue.js).
• Архитектуры: Часто используются многоуровневые архитектуры (клиент-сервер, веб-приложение), микросервисная архитектура для больших, распределённых систем.
• Облачные решения: Для обеспечения масштабируемости и доступности, некоторые системы размещаются в облачных средах (AWS, Google Cloud, Azure).

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

2.3. Функциональные требования к системе Автовокзал-2

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

Для системы Автовокзал-2 можно выделить следующие основные блоки функциональных требований:

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

Эти требования формируют ядро функциональности системы Автовокзал-2 и станут основой для разработки её архитектуры и интерфейсов.

2.4. Нефункциональные требования к системе Автовокзал-2

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

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

1. Надёжность (Reliability):
   • Доступность: Система должна быть доступна не менее 99,5% времени в рабочие часы (например, с 06:00 до 23:00 ежедневно).
   • Устойчивость к сбоям: Система должна корректно восстанавливаться после программных или аппаратных сбоев без потери данных.
   • Среднее время наработки на отказ (MTBF): Например, не менее 1000 часов непрерывной работы.
   • Среднее время восстановления (MTTR): Например, не более 15 минут для критически важных функций.
2. Безопасность (Security):
   • Аутентификация и авторизация: Система должна использовать надёжные механизмы аутентификации (например, многофакторная аутентификация) и авторизации на основе ролей (RBAC) для контроля доступа к функциям и данным.
   • Защита данных: Все конфиденциальные данные (личные данные пассажиров, платёжная информация) должны храниться в зашифрованном виде. Передача данных должна осуществляться по защищённым протоколам (HTTPS).
   • Журналирование действий: Система должна вести подробный журнал всех критически важных операций (продажа билетов, изменение расписания, действия администратора) с указанием времени и пользователя.
   • Защита от SQL-инъекций и XSS-атак: Система должна быть устойчива к распространённым уязвимостям веб-приложений.
3. Масштабируемость (Scalability):
   • Поддержка одновременных пользователей: Система должна стабильно поддерживать не менее 1000 одновременно активных пользователей на портале (для онлайн-продаж) и 50 активных пользователей в локальной сети автовокзала (для кассиров, диспетчеров) без деградации производительности.
   • Расширение функционала: Архитектура системы должна предусматривать возможность добавления новых модулей и функций без существенной переработки существующего кода.
   • Обработка данных: Система должна быть способна обрабатывать растущие объёмы данных (количество рейсов, пассажиров, транзакций) с сохранением приемлемой производительности.
4. Производительность (Performance):
   • Время отклика: Отклик на действия пользователя (например, поиск рейса, оформление билета, загрузка страницы) не должен превышать 2 секунд при нормальной нагрузке.
   • Время выполнения отчётов: Формирование стандартных отчётов должно занимать не более 10 секунд.
   • Скорость обработки транзакций: Операции по продаже билетов должны выполняться максимально быстро, не более 3 секунд.
5. Удобство использования (Usability):
   • Интуитивно понятный интерфейс: Интерфейс системы должен быть простым, логичным и понятным для пользователей с минимальным обучением.
   • Обратная связь: Система должна предоставлять чёткую и своевременную обратную связь пользователю о выполнении операций или возникших ошибках.
   • Эргономика: Интерфейс должен быть оптимизирован для минимизации количества кликов и ввода данных.
6. Доступность (Accessibility):
   • Поддержка мобильных устройств: Веб-интерфейс должен быть адаптивным и корректно отображаться на различных мобильных устройствах (смартфоны, планшеты).
   • Совместимость с браузерами: Система должна корректно работать во всех распространённых веб-браузерах (Chrome, Firefox, Edge, Safari).
7. Сопровождаемость (Maintainability) и Тестируемость (Testability):
   • Модульность: Код системы должен быть модульным, что упрощает поиск и исправление ошибок, а также внесение изменений.
   • Документирование кода: Код должен быть хорошо документирован.
   • Лёгкость тестирования: Система должна быть спроектирована таким образом, чтобы облегчить автоматизированное тестирование.
8. Локализация (Localization):
   • Поддержка нескольких языков (например, русский, английский) для интерфейса и документации.

Эти нефункциональные требования задают стандарты качества для системы Автовокзал-2 и будут использоваться для её оценки и тестирования.

Глава 3. Моделирование и проектирование архитектуры системы Автовокзал-2

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

3.1. Моделирование бизнес-процессов и вариантов использования (Use Case)

Основываясь на детальном анализе бизнес-процессов автовокзала, мы можем приступить к их формализованному описанию, которое станет отправной точкой для проектирования системы. В этом нам поможет UML (Unified Modeling Language — унифицированный язык моделирования) — открытый стандарт, язык графического описания для объектного моделирования, широко применяемый в разработке программного обеспечения, моделировании бизнес-процессов и системном проектировании.

Одной из самых важных поведенческих диаграмм UML является диаграмма вариантов использования (Use Case). Она описывает взаимодействие между системой и её пользователем (актором), помогая визуализировать и задокументировать требования к системе с точки зрения внешних сущностей.

Для системы Автовокзал-2 можно выделить следующих основных акторов:

• Пассажир: Конечный пользователь, покупающий билеты и пользующийся услугами автовокзала.
• Кассир: Сотрудник автовокзала, осуществляющий продажу и возврат билетов.
• Диспетчер: Сотрудник, управляющий расписанием, рейсами и контролирующий движение автобусов.
• Администратор: Сотрудник, отвечающий за настройку системы, управление пользователями и формирование отчётности.
• Система оплаты: Внешняя система, обеспечивающая обработку платежей.
• Система SMS-информирования: Внешняя система для отправки уведомлений.

Пример диаграммы вариантов использования (Use Case-диаграммы) для системы Автовокзал-2:

graph TD
    A[Пассажир] --> |Купить билет| UC1(Поиск рейса);
    A --> |Купить билет| UC2(Выбор места);
    A --> |Купить билет| UC3(Оплата билета);
    A --> |Возврат билета| UC4(Возврат билета);
    A --> |Просмотреть расписание| UC5(Просмотр расписания);
    A --> |Получить информацию о рейсе| UC6(Получение информации о рейсе);

    B[Кассир] --> |Оформить билет| UC1;
    B --> |Оформить билет| UC2;
    B --> |Оформить билет| UC3;
    B --> |Вернуть билет| UC4;
    B --> |Редактировать расписание| UC7(Редактирование расписания);
    B --> |Проконтролировать посадку| UC8(Контроль посадки);

    C[Диспетчер] --> |Управление расписанием| UC7;
    C --> |Управление рейсами| UC9(Управление рейсами);
    C --> |Мониторинг движения автобусов| UC10(Мониторинг автобусов);
    C --> |Диспетчеризация перронов| UC11(Диспетчеризация перронов);
    C --> |Формировать отчёт| UC12(Формирование отчётности);

    D[Администратор] --> |Управление пользователями| UC13(Управление пользователями);
    D --> |Управление ролями и правами| UC14(Управление ролями);
    D --> |Настройка системы| UC15(Настройка системы);
    D --> |Формировать отчёт| UC12;

    UC3 --> |Запросить оплату| E[Система оплаты];
    UC6 --> |Отправить SMS| F[Система SMS-информирования];
    UC9 --> |Получить данные GPS| G[Система GPS-мониторинга];

    subgraph Система "Автовокзал-2"
        UC1
        UC2
        UC3
        UC4
        UC5
        UC6
        UC7
        UC8
        UC9
        UC10
        UC11
        UC12
        UC13
        UC14
        UC15
    end

Детализация основных сценариев (Use Case):

1. Сценарий Купить билет (Пассажир, Кассир):
   • Предусловия: Пассажир находится на сайте/в приложении или Кассир авторизован.
   • Основные действия:
     1. Пользователь выбирает пункт отправления, пункт назначения и дату поездки.
     2. Система отображает доступные рейсы с информацией о времени, стоимости и свободных местах.
     3. Пользователь выбирает рейс и место в автобусе.
     4. Система запрашивает данные пассажира (ФИО, паспорт).
     5. Пользователь выбирает способ оплаты (банковская карта, наличные).
     6. Система обрабатывает платёж (через внешнюю систему оплаты).
     7. Система генерирует электронный билет и отправляет его на email/SMS пассажира.
   • Постусловия: Билет успешно продан, место забронировано, информация о продаже занесена в базу данных.
   • Альтернативные сценарии: Отказ от оплаты, отсутствие свободных мест, ошибка ввода данных.
2. Сценарий Управление расписанием (Диспетчер, Администратор):
   • Предусловия: Пользователь авторизован как Диспетчер или Администратор.
   • Основные действия:
     1. Пользователь выбирает опцию Управление расписанием.
     2. Система отображает текущее расписание рейсов.
     3. Пользователь выбирает рейс для редактирования или создаёт новый.
     4. Пользователь вносит изменения (время, маршрут, автобус, водитель).
     5. Система сохраняет изменения и уведомляет об этом заинтересованные стороны (например, Кассиров, Пассажиров).
   • Постусловия: Расписание обновлено, информация доступна всем акторам.
   • Альтернативные сценарии: Конфликт расписаний, невозможность назначить автобус/водителя.

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

3.2. Структурное моделирование системы (Диаграммы классов, компонентов, развертывания)

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

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

classDiagram
    class Пассажир {
        -id: int
        -ФИО: string
        -Паспорт: string
        -Телефон: string
        -Email: string
        +зарегистрироваться()
        +авторизоваться()
        +просмотретьБилеты()
    }

    class Билет {
        -id: int
        -НомерБилета: string
        -ДатаПродажи: datetime
        -Стоимость: decimal
        -Статус: enum
        -Место: string
        -РейсID: int
        -ПассажирID: int
        +оформить()
        +вернуть()
        +распечатать()
    }

    class Рейс {
        -id: int
        -НомерРейса: string
        -ДатаОтправления: date
        -ВремяОтправления: time
        -ДатаПрибытия: date
        -ВремяПрибытия: time
        -Статус: enum
        -МаршрутID: int
        -АвтобусID: int
        -ВодительID: int
        +изменитьСтатус()
        +добавитьОстановку()
    }

    class Маршрут {
        -id: int
        -Название: string
        -ПунктОтправления: string
        -ПунктНазначения: string
        -Расстояние: decimal
        +добавитьОстановку()
    }

    class Остановка {
        -id: int
        -Название: string
        -Координаты: string
        -ВремяСтоянки: time
    }

    class Автобус {
        -id: int
        -ГосНомер: string
        -Марка: string
        -Модель: string
        -Вместимость: int
        +проверитьСтатус()
    }

    class Водитель {
        -id: int
        -ФИО: string
        -НомерВодительскогоУдостоверения: string
        -Статус: enum
        +назначитьРейс()
    }

    class Пользователь {
        -id: int
        -Логин: string
        -ПарольHash: string
        -Роль: enum
        +авторизоваться()
    }

    class Сотрудник {
        -Должность: string
    }

    class Кассир {
        -Смена: string
        +продатьБилет()
    }

    class Диспетчер {
        +управлятьРасписанием()
        +мониторитьРейсы()
    }

    class Администратор {
        +управлятьПользователями()
    }

    Пассажир -- Билет : 1..* имеет
    Билет -- Рейс : 1..* относится к
    Рейс -- Маршрут : 1..* следует по
    Рейс -- Автобус : 1..* использует
    Рейс -- Водитель : 1..* управляет
    Маршрут -- Остановка : 1..* включает
    Пользователь <|-- Сотрудник
    Сотрудник <|-- Кассир
    Сотрудник <|-- Диспетчер
    Пользователь <|-- Администратор
    Пользователь <|-- Пассажир

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

componentDiagram
    [Модуль Продаж] --> [Модуль Расписания]
    [Модуль Продаж] --> [Модуль Учета]
    [Модуль Продаж] --> [База Данных]
    [Модуль Расписания] --> [База Данных]
    [Модуль Диспетчеризации] --> [Модуль Расписания]
    [Модуль Диспетчеризации] --> [База Данных]
    [Модуль Диспетчеризации] --> [Модуль Информирования]
    [Модуль Отчетности] --> [База Данных]
    [Модуль Пользователей] --> [База Данных]

    [Веб-интерфейс Пассажира] --> [Модуль Продаж]
    [Кассовый Интерфейс] --> [Модуль Продаж]
    [Мобильное Приложение] --> [Модуль Продаж]
    [Модуль Информирования] --> [SMS Gateway]
    [Модуль Диспетчеризации] --> [GPS Мониторинг]
    [Модуль Продаж] --> [Платежный Шлюз]

    cloud "Внешние Сервисы" {
        [SMS Gateway]
        [GPS Мониторинг]
        [Платежный Шлюз]
    }

    database "Хранилище Данных" {
        [База Данных]
    }

    component "Ядро Системы" as Core {
        [Модуль Продаж]
        [Модуль Расписания]
        [Модуль Диспетчеризации]
        [Модуль Отчетности]
        [Модуль Пользователей]
        [Модуль Учета]
        [Модуль Информирования]
    }

Диаграмма развёртывания (Deployment Diagram) иллюстрирует физическое развёртывание программных компонентов на аппаратных узлах. Она показывает, какие аппаратные ресурсы (серверы, рабочие станции) используются и как программные компоненты распределены по этим ресурсам.

graph LR
    subgraph Инфраструктура Автовокзала
        N1[Клиентская Рабочая Станция Кассира] -- Wi-Fi/LAN --> N2(Сервер Приложений);
        N1 -- Wi-Fi/LAN --> N3(Сервер Базы Данных);
        N4[Терминал Самообслуживания] -- LAN --> N2;
        N5[Диспетчерская Рабочая Станция] -- LAN --> N2;
        N6[Рабочая Станция Администратора] -- LAN --> N2;
        N7[Электронное Табло] -- LAN --> N2;
    end

    subgraph Облачная Инфраструктура
        N8(Веб-сервер) -- Интернет --> N2;
        N9(Сервер Мобильных Приложений) -- Интернет --> N2;
        N10(SMS Gateway) -- API --> N2;
        N11(Платежный Шлюз) -- API --> N2;
        N12(Сервис GPS-мониторинга) -- API --> N2;
    end

    subgraph Серверная Комната Автовокзала
        subgraph Сервер Приложений
            C1[Модуль Продаж]
            C2[Модуль Расписания]
            C3[Модуль Диспетчеризации]
            C4[Модуль Отчетности]
            C5[Модуль Пользователей]
            C6[Модуль Информирования]
        end
        subgraph Сервер Базы Данных
            DB[База Данных PostgreSQL/MySQL]
        end
    end

    N2 --> N3;
    N8 -- HTTPS --> C1;
    N9 -- HTTPS --> C1;
    C6 --> N10;
    C1 --> N11;
    C3 --> N12;

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

3.3. Моделирование поведения системы (Диаграммы последовательности, деятельности)

Помимо статической структуры, важно понимать, как система Автовокзал-2 будет вести себя при выполнении различных операций. Для этого мы используем поведенческие диаграммы UML, которые демонстрируют динамические аспекты взаимодействия между компонентами и потоки управления.

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

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

sequenceDiagram
    participant P as Пассажир
    participant WS as Веб-сайт/Мобильное приложение
    participant MPs as Модуль Продаж
    participant MR as Модуль Расписания
    participant DB as База Данных
    participant PS as Платежный Шлюз
    participant MS as Модуль SMS-информирования

    P->>WS: Открыть веб-сайт/приложение
    WS->>P: Отобразить форму поиска рейсов
    P->>WS: Ввести пункты отправления/назначения, дату
    WS->>MPs: Запросить доступные рейсы(пунктОтпр, пунктНазн, дата)
    MPs->>MR: Запросить рейсы(пунктОтпр, пунктНазн, дата)
    MR->>DB: SELECT * FROM Рейсы WHERE ...
    DB-->>MR: Список рейсов
    MR-->>MPs: Список рейсов
    MPs-->>WS: Список рейсов
    WS->>P: Отобразить список рейсов
    P->>WS: Выбрать рейс и место
    WS->>MPs: Забронировать место(РейсID, МестоID, ПассажирID)
    MPs->>DB: UPDATE Место SET Статус='Забронировано' WHERE ...
    DB-->>MPs: Подтверждение бронирования
    MPs-->>WS: Подтверждение бронирования, запрос оплаты
    P->>WS: Ввести данные карты
    WS->>PS: Отправить платёжные данные
    PS->>WS: Результат оплаты
    alt Успешная оплата
        WS->>MPs: Подтвердить оплату(БилетID)
        MPs->>DB: UPDATE Билет SET Статус='Продан' WHERE ...
        DB-->>MPs: Подтверждение
        MPs-->>WS: Отправить электронный билет
        MPs->>MS: Отправить SMS с номером билета
        MS->>P: SMS-уведомление
        WS->>P: Отобразить электронный билет
    else Неуспешная оплата
        WS->>MPs: Отменить бронирование(БилетID)
        MPs->>DB: UPDATE Место SET Статус='Свободно' WHERE ...
        DB-->>MPs: Подтверждение отмены
        MPs-->>WS: Сообщение об ошибке
        WS->>P: Сообщение об ошибке оплаты
    end

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

Пример Диаграммы деятельности для процесса Диспетчеризация рейса:

graph TD
    start((start)) --> A[Диспетчер открывает панель управления рейсами];
    A --> B{Выбрать рейс};
    B -- Существующий рейс --> C[Просмотреть детали рейса];
    B -- Новый рейс --> D[Создать новый рейс];
    C --> E{Изменить расписание?};
    D --> F[Ввести данные рейса (номер, маршрут, время)];
    F --> G[Назначить автобус и водителя];
    E -- Да --> H[Изменить время отправления/прибытия];
    H --> I[Проверить доступность перрона];
    I --> J{Перрон свободен?};
    J -- Нет --> K[Найти альтернативный перрон/время];
    J -- Да --> L[Сохранить изменения расписания];
    L --> M[Уведомить Кассиров и Пассажиров об изменениях];
    G --> N[Сохранить данные рейса];
    N --> O[Обновить статус рейса на "Планируется"];
    M --> O;
    O --> P{Время отправления подошло?};
    P -- Да --> Q[Оповестить водителя о готовности к отправлению];
    Q --> R[Начать мониторинг движения автобуса (GPS)];
    R --> S[Отметить рейс как "В пути"];
    S --> T{Рейс прибыл в пункт назначения?};
    T -- Да --> U[Зафиксировать время прибытия];
    U --> V[Отметить рейс как "Прибыл"];
    V --> W[Сформировать отчёт о рейсе];
    W --> end((end));
    K --> L;
    D --> G;
    C --> G;
    P -- Нет --> A;

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

3.4. Проектирование базы данных Автовокзал-2

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

Проектирование базы данных Автовокзал-2 включает в себя два основных этапа:

1. Разработка концептуальной модели базы данных (ER-диаграмма):
   Концептуальная модель описывает сущности предметной области (объекты, о которых нужно хранить информацию), их атрибуты (характеристики) и связи между ними, без привязки к конкретной СУБД. Она является высокоуровневым представлением данных, понятным как разработчикам, так и бизнес-пользователям. Наиболее распространённым инструментом для создания концептуальной модели является ER-диаграмма (Entity-Relationship Diagram — диаграмма сущность-связь).

Пример ER-диаграммы для системы Автовокзал-2:

erDiagram
    PASSENGER ||--o{ TICKET : имеет
    TICKET ||--|{ TRIP : относится_к
    TRIP ||--|{ ROUTE : следует_по
    TRIP ||--o{ BUS : использует
    TRIP ||--o{ DRIVER : управляет
    ROUTE ||--o{ STOP : включает
    USER ||--o{ PASSENGER : является_пользователем
    USER ||--o{ EMPLOYEE : является_сотрудником
    EMPLOYEE ||--o{ CASHIER : является_кассиром
    EMPLOYEE ||--o{ DISPATCHER : является_диспетчером
    EMPLOYEE ||--o{ ADMINISTRATOR : является_администратором

    PASSENGER {
        int id PK
        varchar FIO
        varchar Passport
        varchar Phone
        varchar Email
    }
    TICKET {
        int id PK
        varchar TicketNumber
        datetime SaleDate
        decimal Cost
        varchar Status
        varchar Place
        int TripID FK
        int PassengerID FK
    }
    TRIP {
        int id PK
        varchar TripNumber
        date DepartureDate
        time DepartureTime
        date ArrivalDate
        time ArrivalTime
        varchar Status
        int RouteID FK
        int BusID FK
        int DriverID FK
    }
    ROUTE {
        int id PK
        varchar Name
        varchar DeparturePoint
        varchar DestinationPoint
        decimal Distance
    }
    STOP {
        int id PK
        varchar Name
        varchar Coordinates
        time StopDuration
    }
    BUS {
        int id PK
        varchar LicensePlate
        varchar Brand
        varchar Model
        int Capacity
    }
    DRIVER {
        int id PK
        varchar FIO
        varchar DriverLicenseNumber
        varchar Status
    }
    USER {
        int id PK
        varchar Login
        varchar PasswordHash
        varchar Role
    }
    EMPLOYEE {
        int id PK
        varchar Position
        int UserID FK
    }
    CASHIER {
        int id PK
        varchar Shift
        int EmployeeID FK
    }
    DISPATCHER {
        int id PK
        int EmployeeID FK
    }
    ADMINISTRATOR {
        int id PK
        int EmployeeID FK
    }

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

Пример таблицы TRIPS (Рейсы):

Название поля	Тип данных	Описание	Ограничения
trip_id	INT	Уникальный идентификатор рейса	PRIMARY KEY, NOT NULL
trip_number	VARCHAR(50)	Номер рейса	NOT NULL, UNIQUE
departure_date	DATE	Дата отправления	NOT NULL
departure_time	TIME	Время отправления	NOT NULL
arrival_date	DATE	Дата прибытия	NOT NULL
arrival_time	TIME	Время прибытия	NOT NULL
status	VARCHAR(20)	Статус рейса (Например, ‘Планируется’, ‘В пути’, ‘Прибыл’, ‘Отменен’)	NOT NULL
route_id	INT	Ссылка на маршрут	FOREIGN KEY → ROUTES(route_id), NOT NULL
bus_id	INT	Ссылка на автобус	FOREIGN KEY → BUSES(bus_id), NOT NULL
driver_id	INT	Ссылка на водителя	FOREIGN KEY → DRIVERS(driver_id), NOT NULL

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

3.5. Принципы нормализации и обеспечения целостности данных

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

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

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

Наиболее распространённые нормальные формы:

1. Первая нормальная форма (1НФ): Требует, чтобы в таблице:
   • Все столбцы содержали атомарные (неделимые) значения. Например, поле ФИО не должно хранить Иванов Иван Иванович, а должно быть разбито на Фамилия, Имя, Отчество.
   • Не было повторяющихся групп атрибутов. Каждая строка должна быть уникальна и идентифицироваться уникальным первичным ключом.
   • Пример для Автовокзал-2: В таблице PASSENGERS поле FIO должно быть разделено на first_name, last_name, patronymic.
2. Вторая нормальная форма (2НФ): Требует выполнения 1НФ и отсутствия частичных функциональных зависимостей неключевых атрибутов от части первичного ключа (для таблиц с составным первичным ключом).
   • Пример для Автовокзал-2: Если бы первичный ключ таблицы TICKETS был (trip_id, place_number), а bus_brand зависел только от trip_id, то это нарушало бы 2НФ. bus_brand нужно вынести в таблицу BUSES.
3. Третья нормальная форма (3НФ): Требует выполнения 2НФ и отсутствия транзитивных функциональных зависимостей неключевых атрибутов от первичного ключа. Это означает, что неключевые атрибуты не должны зависеть от других неключевых атрибутов.
   • Пример для Автовокзал-2: Если в таблице TRIPS было бы поле route_distance (расстояние маршрута), которое зависит от route_id, а route_id уже является внешним ключом к таблице ROUTES, то route_distance должно быть вынесено в таблицу ROUTES.

Для системы Автовокзал-2 все таблицы будут спроектированы как минимум до 3НФ, что обеспечит оптимальный баланс между устранением избыточности и производительностью запросов.

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

Типы целостности данных и методы их обеспечения:

1. Логическая целостность (Entity Integrity):
   • Принцип: Каждая строка таблицы должна быть уникально идентифицируема.
   • Обеспечение: Использование первичного ключа (PRIMARY KEY), который не может содержать NULL-значений и должен быть уникальным для каждой записи.
   • Пример для Автовокзал-2: Поле id в каждой таблице (например, PASSENGERS, TRIPS) будет первичным ключом.
2. Ссылочная целостность (Referential Integrity):
   • Принцип: Отношения между первичным и внешним ключом должны быть корректными. Внешний ключ в одной таблице должен либо ссылаться на существующий первичный ключ в другой таблице, либо быть NULL.
   • Обеспечение: Использование внешних ключей (FOREIGN KEY) с правилами ON DELETE и ON UPDATE (например, CASCADE, RESTRICT, SET NULL).
   • Пример для Автовокзал-2: route_id в таблице TRIPS является внешним ключом, ссылающимся на route_id в таблице ROUTES. Нельзя удалить маршрут, если на него ссылается хотя бы один рейс.
3. Целостность полей/доменов (Domain Integrity):
   • Принцип: Каждое поле должно содержать только допустимые значения, соответствующие его типу данных и бизнес-логике.
   • Обеспечение: Использование типов данных (INT, VARCHAR, DATE, BOOLEAN), ограничений CHECK (например, CHECK (capacity > 0) для автобуса), NOT NULL (для обязательных полей), DEFAULT значений.
   • Пример для Автовокзал-2: Поле status в таблице TRIPS может иметь только предопределённые значения (‘Планируется’, ‘В пути’, ‘Прибыл’, ‘Отменен’).
4. Целостность таблицы (Table Integrity):
   • Принцип: Обеспечение уникальности записей в таблице.
   • Обеспечение: Использование уникальных индексов и ограничений UNIQUE на одно или несколько полей (например, UNIQUE(trip_number) для рейсов).

Тщательное применение этих принципов при проектировании базы данных Автовокзал-2 гарантирует её надёжность, согласованность и долговременную работоспособность.

Глава 4. Тестирование программного обеспечения и документация системы Автовокзал-2

Создание системы — это лишь часть пути; убедиться в её корректной работе и обеспечить её дальнейшее сопровождение не менее важно. Эта глава посвящена двум критически важным аспектам: тестированию программного обеспечения, которое гарантирует качество и надёжность Автовокзал-2, и разработке документации, обеспечивающей её понятность и поддерживаемость на протяжении всего жизненного цикла.

4.1. Методология и виды тестирования программного обеспечения

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

Основные виды тестирования, применимые к Автовокзал-2:

1. Модульное тестирование (Unit Testing):
   • Цель: Проверка наименьших, изолированных частей кода (модулей, функций, методов) на корректность их работы.
   • Когда проводится: На этапе разработки, разработчиками.
   • Особенности для Автовокзал-2: Тестирование отдельных функций, например, расчёт стоимости билета, проверка валидности данных пассажира, сохранение записи о рейсе в базу данных. Модульные тесты работают на очень низком уровне, близко к исходному коду приложения.
2. Интеграционное тестирование (Integration Testing):
   • Цель: Проверка совместной работы различных модулей, компонентов и сервисов, используемых приложением.
   • Когда проводится: После модульного тестирования, когда отдельные модули объединены.
   • Особенности для Автовокзал-2: Проверка взаимодействия модуля продаж с модулем расписания, модуля диспетчеризации с базой данных, интеграции с внешним платежным шлюзом или SMS-сервисом.
3. Функциональное тестирование (Functional Testing):
   • Цель: Проверка того, какие функции ПО реализованы, и насколько верно они реализованы, основываясь на анализе спецификации (функциональных требований).
   • Когда проводится: После интеграционного тестирования.
   • Особенности для Автовокзал-2: Тестирование полного цикла покупки билета (от поиска до получения), оформления возврата, изменения расписания диспетчером, формирования отчётов. Фокус на том, что система делает.
4. Нефункциональное тестирование (Non-functional Testing):
   • Цель: Проверка атрибутов компонента или системы, не относящихся к функциональности, и оценка, КАК программный продукт работает.
   • Когда проводится: На различных этапах тестирования, часто параллельно с функциональным.
   • Подвиды для Автовокзал-2:
     • Нагрузочное тестирование (Load Testing): Проверка производительности приложения под ожидаемой нагрузкой (например, 1000 одновременных пользователей, оформляющих билеты).
     • Стрессовое тестирование (Stress Testing): Проверка работоспособности системы в условиях экстремальной нагрузки (например, 2000-3000 одновременных пользователей) и оценка способности к регенерации (восстановлению после перегрузки).
     • Тестирование безопасности (Security Testing / Penetration Testing): Выявление уязвимостей (SQL-инъекции, XSS, слабые пароли, утечки данных) и проверка устойчивости к несанкционированному доступу.
     • Тестирование производительности (Performance Testing): Измерение времени отклика системы на различные действия при стандартной нагрузке.
     • Тестирование юзабилити (Usability Testing): Оценка удобства и интуитивности интерфейса для конечных пользователей (кассиров, пассажиров, диспетчеров).
5. Приемочное тестирование (Acceptance Testing):
   • Цель: Подтверждение того, что функции и модули приложения правильно работают с корректными данными и соответствуют ожиданиям заказчика/конечного пользователя.
   • Когда проводится: На заключительном этапе перед развёртыванием, обычно с участием представителей заказчика.
   • Особенности для Автовокзал-2: Заказчик (руководство автовокзала, ключевые пользователи) проверяет, что система полностью удовлетворяет их бизнес-потребностям.
6. Дымовое тестирование (Smoke Testing):
   • Цель: Быстрое тестирование для подтверждения общей работоспособности системы после внесения значительных изменений или выпуска новой версии.
   • Когда проводится: После каждой сборки или значительного обновления.
   • Особенности для Автовокзал-2: Проверка базовых функций: система запускается, можно войти, отображается расписание, можно начать продажу билетов.

Методология тестирования для Автовокзал-2 будет включать:

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

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

4.2. Разработка технического задания (ТЗ) на АС по ГОСТ 34.602-2020

Разработка сложной автоматизированной системы, такой как Автовокзал-2, невозможна без чёткого и исчерпывающего документа, регламентирующего весь процесс её создания. Таким документом является Техническое задание (ТЗ) на автоматизированную систему (АС). Оно служит основным ориентиром для всех участников проекта — от заказчика до разработчиков — и определяет требования, порядок создания и приёмки системы.

С 1 января 2022 года в России действует ГОСТ 34.602-2020 Информационные технологии. Комплекс стандартов на автоматизированные системы. Техническое задание на создание автоматизированной системы, который заменил предыдущий ГОСТ 34.602-89. Этот новый стандарт устанавливает состав, содержание и правила оформления ТЗ, делая его более современным и соответствующим текущим реалиям разработки ПО.

Структура и содержание Технического задания на АС Автовокзал-2 по ГОСТ 34.602-2020:

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

1. Общие сведения:
   • Полное наименование системы (Автоматизированная система Автовокзал-2) и её условное обозначение.
   • Наименование и реквизиты предприятий (организаций) заказчика и разработчика.
   • Основание для разработки (например, приказ, договор, протокол).
   • Сроки начала и окончания работ по созданию системы.
   • Источники финансирования и порядок приёмки работ.
2. Назначение и цели создания системы:
   • Назначение системы: Для чего предназначена система (например, автоматизация бизнес-процессов по управлению пассажирскими перевозками и продажей билетов на автовокзале).
   • Цели создания системы: Какие конкретные задачи должна решить система (например, повышение эффективности продаж билетов на 30%, сокращение времени обслуживания пассажиров на 50%, обеспечение полного контроля над выручкой).
3. Характеристика объектов автоматизации:
   • Подробное описание предметной области: структура автовокзала, используемые ресурсы (персонал, оборудование), основные бизнес-процессы (продажа билетов, диспетчеризация, учёт), текущие проблемы и узкие места.
   • Сведения о существующей автоматизации (если есть) и её недостатки.
   • Взаимодействие с другими системами (например, бухгалтерский учёт, системы GPS-мониторинга).
4. Требования к системе: Это наиболее объёмный и детализированный раздел.
   • 4.1. Требования к функциям (задачам), выполняемым системой:
     • Перечень функциональных требований, детально описанных в Главе 2.3, с указанием приоритетов.
     • Обязательные функции (продажа, расписание), дополнительные (SMS-информирование, онлайн-бронирование).
   • 4.2. Требования к видам обеспечения:
     • 4.2.1. Требования к программному обеспечению: используемые языки программирования, СУБД, операционные системы, фреймворки.
     • 4.2.2. Требования к техническому обеспечению: минимальная конфигурация аппаратного обеспечения для серверов, рабочих станций, терминалов.
     • 4.2.3. Требования к информационному обеспечению: Структура баз данных, принципы кодирования, классификаторы, форматы ввода/вывода данных.
     • 4.2.4. Требования к организационному обеспечению: Изменения в регламентах работы, должностные инструкции.
     • 4.2.5. Требования к методическому обеспечению: Методики обучения пользователей, регламенты работы.
     • 4.2.6. Требования к лингвистическому обеспечению: Терминология, языки интерфейса.
     • 4.2.7. Требования к правовому обеспечению: Соответствие законодательству (например, защита персональных данных).
   • 4.3. Требования к надёжности: Показатели доступности, времени восстановления, устойчивости к сбоям (см. Глава 2.4).
   • 4.4. Требования к безопасности: Аутентификация, авторизация, защита данных, логирование (см. Глава 2.4).
   • 4.5. Требования к эргономике и технической эстетике: Удобство интерфейса, цветовая схема, компоновка элементов.
   • 4.6. Требования к эксплуатации, техническому обслуживанию, ремонту: Процедуры запуска/остановки, мониторинга, резервного копирования.
   • 4.7. Требования к составу и параметрам технических средств: Спецификации оборудования.
   • 4.8. Требования к защите информации от несанкционированного доступа: Методы защиты, разграничение прав.
   • 4.9. Требования к защите от воздействия внешних факторов: Устойчивость к перепадам напряжения, электромагнитным помехам.
   • 4.10. Требования к патентной чистоте: Использование лицензионных продуктов и технологий.
5. Состав и содержание работ по созданию системы:
   • Перечень этапов работ (анализ, проектирование, разработка, тестирование, внедрение).
   • Сроки выполнения каждого этапа.
   • Результаты каждого этапа (документы, программный код).
6. Порядок контроля и приемки системы:
   • Виды, состав и методы испытаний (модульные, интеграционные, функциональные, приемочные).
   • Процедуры проведения испытаний и критерии успешности.
   • Перечень документов, представляемых при приёмке.
7. Требования к составу и содержанию работ по подготовке объекта автоматизации к вводу системы в действие:
   • Мероприятия по обучению персонала.
   • Подготовка помещений, оборудования.
   • Перенос данных из старых систем (если применимо).
8. Требования к документированию:
   • Перечень подлежащих разработке комплектов и видов документов, соответствующих требованиям ГОСТ 34.201-89 (например, Руководство пользователя, Руководство по инсталляции, Описание программы).
   • Требования к оформлению документов.
9. Источники разработки:
   • Перечень нормативных документов, технических решений, материалов, использованных при разработке ТЗ.

Тщательная проработка Технического задания по ГОСТ 34.602-2020 обеспечит прозрачность проекта Автовокзал-2, минимизирует риски недопонимания между заказчиком и разработчиком, а также станет основой для успешной реализации и дальнейшего сопровождения системы.

4.3. Требования к пользовательской документации и инсталляции

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

Требования к разработке руководства пользователя:

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

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

Требования к руководству по инсталляции системы:

Руководство по инсталляции предназначено для IT-специалистов, ответственных за развёртывание системы на серверах и рабочих станциях. Оно должно быть максимально подробным и технически точным.

• Назначение: Предоставление полной информации и пошаговых инструкций для успешной установки и настройки всех компонентов системы.
• Содержание:
  • Введение: Обзор архитектуры системы и её компонентов.
  • Минимальная конфигурация программно-аппаратного обеспечения:
    • Аппаратное обеспечение:
      • Сервер базы данных: Процессор (например, Intel Xeon E3-1505M v5 или аналогичный), RAM (не менее 16 ГБ), дисковое пространство (SSD, не менее 500 ГБ, с RAID 1 для надёжности), сетевая карта (Gigabit Ethernet).
      • Сервер приложений: Аналогичные требования, возможно, с большей RAM в зависимости от ожидаемой нагрузки.
      • Рабочие станции кассиров/диспетчеров: Процессор (Intel Core i3-10100 или аналогичный), RAM (не менее 8 ГБ), дисковое пространство (SSD, не менее 256 ГБ), монитор (1920×1080), принтер для билетов.
    • Программное обеспечение:
      • Операционная система: Linux (например, Ubuntu Server 22.04 LTS) или Windows Server 2022 для серверов; Windows 10/11 для рабочих станций.
      • Система управления базами данных (СУБД): PostgreSQL 14+ или MySQL 8+.
      • Веб-сервер: Nginx или Apache HTTP Server.
      • Среда выполнения: Java Runtime Environment (JRE) 17+ или .NET Runtime 6+.
      • Дополнительное ПО: Браузеры (Chrome, Firefox), драйверы для периферийных устройств (принтеры, сканеры).
  • Пошаговая инструкция по установке:
    • Подготовка операционной системы (установка необходимых пакетов, настройка сети).
    • Установка и настройка СУБД.
    • Развёртывание серверных компонентов (модулей приложения).
    • Настройка веб-сервера.
    • Установка клиентских приложений или настройка доступа к веб-интерфейсу.
    • Процедуры первоначальной настройки и инициализации данных.
  • Конфигурационные файлы: Описание параметров и их значений.
  • Устранение неполадок при инсталляции: Типовые проблемы и их решения.
• Формат: Документ в электронном виде (PDF) с возможностью копирования команд и примеров настроек.

Наличие качественной и актуальной документации для системы Автовокзал-2 является залогом её успешного внедрения, эффективной эксплуатации и долгосрочной поддерживаемости.

Заключение

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

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

Центральной частью работы стало моделирование и проектирование архитектуры системы Автовокзал-2 с использованием унифицированного языка моделирования UML. Были разработаны диаграммы вариантов использования, классов, компонентов и развертывания, обеспечивающие всестороннее представление о структуре и взаимодействии элементов системы. Поведенческие аспекты были отражены в диаграммах последовательности и деятельности, наглядно демонстрирующих ключевые сценарии работы. Отдельное внимание было уделено проектированию базы данных, где были подробно рассмотрены принципы нормализации (до 3НФ) и обеспечения целостности данных, что является критически важным для надёжного хранения и обработки информации.

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

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

Перспективы дальнейшего развития системы Автовокзал-2 включают:

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

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

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

1. ГОСТ 34.602-2020. Информационная технология (ИТ). Комплекс стандартов на автоматизированные системы. Техническое задание на создание автоматизированной системы. URL: https://babok.ru/gost-34-602-2020-trebovaniya-k-soderzhaniyu-tz-na-as-s-izmeneniyami-2022-goda/ (дата обращения: 12.10.2025).
2. ГОСТ 34.602-89. Техническое задание на создание автоматизированной системы. URL: https://docs.cntd.ru/document/1200004566 (дата обращения: 12.10.2025).
3. Анализ методов и алгоритмов решений. URL: https://namdu.uz/wp-content/uploads/2024/06/vvedenie-v-programmnuyu-inzheneriyu.pdf (дата обращения: 12.10.2025).
4. Виды и типы тестирования программного обеспечения. URL: https://www.lenal.ru/blog/vidy-i-tipy-testirovaniya-po/ (дата обращения: 12.10.2025).
5. Виды испытаний (тестирования) информационной системы. URL: https://it-concord.ru/useful/vidy-ispytanij-testirovaniya-informacionnoj-sistemy/ (дата обращения: 12.10.2025).
6. Классификация видов тестирования. URL: https://testplanet.ru/blog/vidy-testirovaniya/ (дата обращения: 12.10.2025).
7. Классификация видов тестирования: Часть 1. URL: https://vc.ru/dev/903080-klassifikaciya-vidov-testirovaniya-chast-1 (дата обращения: 12.10.2025).
8. МЕТОДЫ ТЕСТИРОВАНИЯ ИНТЕГРИРОВАННЫХ ИНФОРМАЦИОННЫХ СИСТЕМ. URL: https://cyberleninka.ru/article/n/metody-testirovaniya-integrirovannyh-informatsionnyh-sistem (дата обращения: 12.10.2025).
9. Методология и инструменты программной инженерии. URL: https://cs.hse.ru/se/news/173041927.html (дата обращения: 12.10.2025).
10. Нефункциональные Требования: Определение и Ключевые Элементы. URL: https://leadstartup.ru/blog/nefunktsionalnye-trebovaniya (дата обращения: 12.10.2025).
11. Нефункциональные требования к системе: что такое, примеры, что входит. URL: https://kaiten.ru/blog/nefunkcionalnye-trebovaniya/ (дата обращения: 12.10.2025).
12. Нормализация базы данных: для чего нужна нормализованная бд. URL: https://gitverse.ru/blog/normalization-data (дата обращения: 12.10.2025).
13. Нормализация данных: что это и зачем их нормировать — правила нормирования данных в БД. URL: https://practicum.yandex.ru/blog/chto-takoe-normalizatsiya-dannyh/ (дата обращения: 12.10.2025).
14. Описание нормализации базы данных. URL: https://support.microsoft.com/ru-ru/office/описание-нормализации-базы-данных-34a8a58a-6373-4556-912f-11eddf163a8a (дата обращения: 12.10.2025).
15. Обеспечение целостности данных. URL: https://www.sql.ru/articles/db/1999/11/0002/23_7_5.shtml (дата обращения: 12.10.2025).
16. Обеспечение целостности данных. URL: http://flenov.info/sql/sql_transact_sql_podlinnik_1_5.html (дата обращения: 12.10.2025).
17. Обеспечение целостности баз данных. URL: https://infopedia.su/2x692a.html (дата обращения: 12.10.2025).
18. Основы проектирования информационных систем. URL: https://www.elibrary.ru/item.asp?id=54415516 (дата обращения: 12.10.2025).
19. Основы проектирования информационных систем. URL: https://stepik.org/course/60183/ (дата обращения: 12.10.2025).
20. Программная инженерия. URL: https://ru.wikipedia.org/wiki/Программная_инженерия (дата обращения: 12.10.2025).
21. Системный анализ. URL: https://gtmarket.ru/concepts/7201 (дата обращения: 12.10.2025).
22. Системный анализ. URL: https://bigenc.ru/technology_and_technique/text/3660144 (дата обращения: 12.10.2025).
23. Словарь системного аналитика | Термины и понятия в системном анализе. URL: https://prodg.ru/blog/slovar-sistemnogo-analitika (дата обращения: 12.10.2025).
24. Теоретические основы проектирования ИС, Основные понятия и предметная область. URL: https://studfile.net/preview/1721516/ (дата обращения: 12.10.2025).
25. Теоретические основы проектирования информационных систем. URL: https://novinfo.ru/informacionnye-sistemy/lektsiya-1-teoreticheskie-osnovy-proektirovaniya-informacionnyh-sistem.html (дата обращения: 12.10.2025).
26. Теория систем и системный анализ. Словарь терминов. URL: https://infourok.ru/teoriya-sistem-i-sistemnyy-analiz-slovar-terminov-5347209.html (дата обращения: 12.10.2025).
27. Теория тестирования ПО просто и понятно. URL: https://habr.com/ru/articles/698716/ (дата обращения: 12.10.2025).
28. Тестирование информационных систем. URL: https://effective-tech.ru/services/testirovanie-informatsionnykh-sistem/ (дата обращения: 12.10.2025).
29. Требования ГОСТ на автоматизированные системы в ИБ-проектах. Что изменилось и как это применять? URL: https://habr.com/ru/companies/croc/articles/672728/ (дата обращения: 12.10.2025).
30. Функциональные и нефункциональные требования — что это, как разработать, примеры требований. URL: https://practicum.yandex.ru/blog/funktsionalnye-i-nefunktsionalnye-trebovaniya/ (дата обращения: 12.10.2025).
31. Функциональные и нефункциональные требования. URL: https://sky.pro/media/funkcionalnye-i-nefunkcionalnye-trebovaniya/ (дата обращения: 12.10.2025).
32. Целостность данных в базах данных: что это и зачем нужно. URL: https://www.staffcop.ru/blog/tcelostnost-dannykh-v-bazakh-dannykh-chto-eto-i-zachem-nuzhno (дата обращения: 12.10.2025).
33. Целостность данных в базе данных: почему это важно. URL: https://www.astera.com/ru/resources/data-integrity-in-database-why-it-matters/ (дата обращения: 12.10.2025).
34. Что за язык моделирования, преимущества использования — типы UML-диаграмм, как их создать, примеры. URL: https://practicum.yandex.ru/blog/chto-takoe-uml/ (дата обращения: 12.10.2025).
35. Что такое нефункциональные требования: типы, примеры и подходы. URL: https://visuresolutions.com/ru/blog/non-functional-requirements-types-examples-approaches/ (дата обращения: 12.10.2025).
36. Что такое нормализация баз данных? URL: https://www.1cbit.ru/blog/chto-takoe-normalizatsiya-baz-dannykh/ (дата обращения: 12.10.2025).
37. Что такое программная инженерия. Лекция в Яндексе. URL: https://habr.com/ru/companies/yandex/articles/307452/ (дата обращения: 12.10.2025).
38. Какие основные принципы нормализации баз данных существуют? URL: https://yandex.ru/q/question/kakie_osnovnye_printsipy_normalizatsii_baz_dannykh_9325c34e/ (дата обращения: 12.10.2025).
39. UML — Википедия. URL: https://ru.wikipedia.org/wiki/UML (дата обращения: 12.10.2025).
40. Знакомство с разными видами диаграмм UML. URL: https://www.lucidchart.com/pages/ru/raznovidnosti-diagramm-uml (дата обращения: 12.10.2025).
41. UML диаграммы, их основные типы и процесс разработки. URL: https://foxminded.ua/ru/blog/uml-diagrams/ (дата обращения: 12.10.2025).
42. UML диаграммы: что такое, виды с примерами, как создать Unified Modeling Language. URL: https://skillbox.ru/media/code/uml-diagrammy-chto-takoe-vidy-s-primerami-kak-sozdat-unified-modeling-language/ (дата обращения: 12.10.2025).
43. Какие бывают этапы и виды тестирования: подробный разбор. URL: https://ru.hexlet.io/blog/posts/what-are-the-stages-and-types-of-testing (дата обращения: 12.10.2025).
44. 50 терминов для системного аналитика — Полный справочник. URL: https://prodg.ru/blog/50-terminov-dlya-sistemnogo-analitika (дата обращения: 12.10.2025).
45. Введение в программную инженерию. Лекция 1: Замысел. Посвящение и благодарности. URL: https://www.intuit.ru/studies/courses/2481/617/lecture/14357?page=1 (дата обращения: 12.10.2025).
46. Различные виды тестирования ПО. URL: https://www.atlassian.com/ru/agile/testing/types-of-testing (дата обращения: 12.10.2025).
47. Введение в программную инженерию. URL: https://namdu.uz/wp-content/uploads/2024/06/vvedenie-v-programmnuyu-inzheneriyu.pdf (дата обращения: 12.10.2025).