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

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

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

Теоретические основы автоматизированных информационных систем

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

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

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

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

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

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

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

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

Существуют различные типы БД, каждый из которых имеет свои преимущества и области применения:

• Иерархические БД: данные организованы в виде древовидной структуры, где каждый потомок имеет только одного родителя.
• Сетевые БД: более гибкие, чем иерархические, позволяют потомкам иметь несколько родителей, создавая сложные связи.
• Реляционные БД (SQL): данные организуются в таблицы (сущности), состоящие из строк (записей) и столбцов (полей). Связи между таблицами устанавливаются с помощью первичных и внешних ключей. Это наиболее распространенный тип БД для структурированных данных, идеально подходящий для систем, где требуется высокая степень целостности данных и сложные запросы. В контексте нашей системы расписания и продажи билетов, реляционные БД, такие как PostgreSQL или MySQL, могут быть оптимальным выбором для хранения информации о судах, маршрутах, рейсах, расписаниях, пассажирах и билетах, так как они обеспечивают строгую структуру и высокую целостность данных.
• Нереляционные БД (NoSQL): предназначены для работы с большими объемами неструктурированных или полуструктурированных данных, обеспечивая высокую масштабируемость и гибкость. К ним относятся:
  • Документоориентированные БД (например, MongoDB): хранят данные в виде JSON-подобных документов.
  • Колоночные БД (например, Cassandra): оптимизированы для агрегации данных по столбцам.
  • Графовые БД (например, Neo4j): используются для данных с большим количеством сложных взаимосвязей.
  • Key-value хранилища (например, Redis): хранят данные в виде пар «ключ-значение», обеспечивая крайне высокую скорость чтения/записи.
• Объектно-ориентированные БД: хранят данные в виде объектов, что упрощает интеграцию с объектно-ориентированными языками программирования.

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

Специфика предметной области: речные суда, расписание и билетные системы

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

Классификация и эксплуатация речных судов: Согласно Российскому Речному Регистру, речные суда по конструкции делятся на 4 основных класса: «М», «О», «Р», «Л», а также дополнительные классы для судов смешанного плавания («М-СП», «М-ПР», «О-ПР»). Эта классификация влияет на разрешенные маршруты, условия эксплуатации и технические требования. Грузы, перевозимые речными судами, весьма разнообразны и включают:

• Массовые навалочные (песок, щебень, цемент, зерновые, уголь), составляющие около 45% от общего объема речных перевозок в России.
• Наливные (нефтепродукты, химические вещества).
• Рефрижераторные (скоропортящиеся).
• Лес, контейнеры, колесную технику.

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

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

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

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

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

• Создание и редактирование информации о мероприятии (в нашем случае — о рейсе): логотип, описание, маршрут, время, тип судна, информация о капитане, партнеры, фото и видео.
• Формирование формы регистрации или продажи билетов.
• Отображение контактов и карты места проведения/маршрута.
• Создание и настройка схемы судна, включая расположение мест, а также отдельные схемы для различных палуб и зон.
• Автоматизация процесса возврата билетов, программы лояльности и скидки.
• Поддержка наличной и безналичной оплаты, интеграция с внешними сервисами и CRM-системами.
• Мобильные приложения для контроля доступа по QR-кодам.

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

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

Анализ существующих аналогов и решений

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

• Сервис «Суда сюда!» (Москва): Этот сервис является частью единой билетной системы московского транспорта и позволяет покупать билеты онлайн, а также оплачивать проезд картой «Тройка». Его преимущество – интеграция с городской транспортной инфраструктурой, что обеспечивает удобство для пассажиров, привыкших к единым стандартам оплаты. Однако, возможно, он не обладает достаточной гибкостью для специфических требований небольших судоходных компаний или нестандартных круизных маршрутов.
• RIVER-TICKET.RU: Один из крупнейших онлайн-сервисов по продаже билетов на речные прогулки в Москве. Его сильная сторона – предложение билетов без наценок и сотрудничество с проверенными судоходными компаниями, что повышает доверие пользователей. Он демонстрирует эффективную модель агрегатора, но для отдельной компании, управляющей собственным флотом, может потребоваться более глубокая интеграция с внутренними бизнес-процессами.
• Boattour (Санкт-Петербург, Mobecan): Компания Mobecan разработала сервис для подбора водных круизов, включающий удобный инструмент для контроля и аналитики всех процессов, а также функционал для партнеров по сверке и аналитике продаж. Это решение выделяется развитыми аналитическими возможностями и инструментами для управления партнерскими отношениями, что весьма актуально для компаний, работающих с различными туроператорами или предлагающими комбинированные маршруты.

Выводы из анализа аналогов:

1. Интеграция: Успешные решения часто интегрированы в более крупные транспортные экосистемы или имеют развитые API для взаимодействия с партнерами.
2. Удобство для пользователя: Простота покупки билетов, различные способы оплаты, доступность информации о рейсах — ключевые факторы успеха.
3. Управление и аналитика: Для оператора важно иметь инструменты для контроля всех процессов, включая продажи, загрузку судов и финансовую отчетность.
4. Гибкость: Системы должны быть достаточно гибкими, чтобы учитывать особенности различных типов судов, маршрутов и сезонных изменений.

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

Анализ и моделирование бизнес-процессов

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

Моделирование бизнес-процессов — это критически важная дисциплина, которая помогает организациям анализировать и улучшать свои операционные процедуры. Оно повышает прозрачность, помогает идентифицировать «узкие места» и дублирующие функции, а также сокращает время выполнения процессов, что может привести к снижению затрат на 10-25% и улучшению качества продукции или услуг на 5-15%. Какой важный нюанс здесь упускается? Часто без адекватного моделирования компании внедряют автоматизацию «как есть», перенося существующие неэффективности в новую систему.

Для моделирования текущих бизнес-процессов формирования расписания движения речных судов и продажи билетов мы применим методологию BPMN 2.0 (Business Process Model and Notation). BPMN 2.0 является наиболее распространенной и эффективной, предоставляя стандартизированный графический набор символов и правил для описания процессов. Ее широкое распространение обусловлено интуитивно понятным графическим языком, позволяющим легко коммуницировать между бизнес-пользователями и техническими специалистами, а также поддержкой выполнения процессов в соответствующих системах.

Пример сценария BPMN 2.0 для продажи билетов:

1. Пул «Пассажир»:
   • Событие «Желание купить билет».
   • Задача «Выбрать маршрут и дату».
   • Задача «Выбрать рейс».
   • Задача «Выбрать место на судне».
   • Задача «Ввести данные пассажира».
   • Задача «Оплатить билет» (с возможностью «Возврат к выбору» в случае отказа).
   • Событие «Получить электронный билет».
2. Пул «Билетная система»:
   • Событие «Запрос на поиск рейсов».
   • Задача «Отобразить доступные рейсы» (шлюз «Есть места?» — если нет, уведомление «Мест нет»).
   • Задача «Зарезервировать место».
   • Задача «Обработать платеж» (шлюз «Платеж успешен?» — если нет, уведомление «Ошибка оплаты»).
   • Задача «Сформировать электронный билет».
   • Задача «Отправить билет пассажиру».

Анализ бизнес-процессов включает в себя:

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

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

Количественный анализ подразумевает детальный сбор информации, обработку и изучение показателей процесса (финансы, время, труд), показателей продукта (номенклатура, объем, брак) и показателей удовлетворенности клиентов. Например, сколько времени занимает оформление билета вручную, какова доля ошибок при ручном вводе, сколько времени уходит на составление расписания.

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

Формирование требований к автоматизированной системе

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

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

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

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

• Производительность: система должна обрабатывать большое количество запросов (например, до 1000 запросов в секунду в пиковые часы) и обеспечивать быстрое время отклика (не более 2-3 секунд).
• Безопасность: защита данных пассажиров и платежных операций, многофакторная аутентификация, шифрование.
• Масштабируемость: способность системы справляться с увеличением нагрузки (ростом числа рейсов, пассажиров, пользователей) без снижения производительности.
• Удобство использования (Usability): интуитивно понятный интерфейс для всех категорий пользователей.
• Надежность: устойчивость к сбоям, наличие механизмов восстановления данных.
• Совместимость: возможность интеграции с другими системами (например, с платежными шлюзами, CRM).
• Доступность: бесперебойная работа 24/7, минимальное время простоя.

Методы сбора бизнес-требований включают:

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

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

Архитектура и технические решения разрабатываемой системы

Обоснование выбора СУБД и языков программирования

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

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

Реляционные СУБД (SQL):

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

Нереляционные СУБД (NoSQL):

• MongoDB: Документоориентированная СУБД, гибкая для хранения полуструктурированных данных, может быть полезна для хранения логов, пользовательских профилей с изменяемым набором полей или динамического контента.
• Cassandra: Для очень больших объемов данных и высокой доступности с возможностью горизонтального масштабирования.
• Redis: Key-value хранилище, идеально подходит для кэширования данных, сессий пользователей, счетчиков (например, количества свободных мест), что значительно повышает скорость отклика системы.

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

Выбор языков программирования:
Для серверной части выбор языка существенно влияет на производительность, масштабируемость и удобство разработки. Неоптимизированный язык или фреймворк может привести к увеличению времени отклика системы на 20-50% при высокой нагрузке.

• Go (Golang): Разработан для создания высоконагруженных систем, использующих многопроцессорную архитектуру. Демонстрирует отличную эффективность при разработке серверных и сетевых приложений. Высокая производительность, встроенная поддержка конкурентности и относительно простой синтаксис делают его сильным кандидатом для бэкенда.
• Node.js (JavaScript): Поддерживает асинхронное программирование, что делает его отличным выбором для масштабируемых приложений с большим количеством I/O операций. Обширная экосистема NPM ускоряет разработку.
• Python: С развитой экосистемой и фреймворками (Django, Flask) подходит для быстрой разработки и работы с данными. Однако может уступать Go или Node.js в чистой производительности при очень высоких нагрузках без дополнительной оптимизации.
• C++/Rust: Для систем, требующих максимальной производительности и минимального использования ресурсов. Могут обрабатывать до миллионов запросов в секунду. Однако сложность разработки и отладки выше.

Обоснование выбора: Учитывая требования к масштабируемости, производительности и скорости разработки, для серверной части рекомендуется использовать Go (Golang) или Node.js (JavaScript). Go обеспечит высокую производительность и надежность, а Node.js – гибкость и асинхронность. Для клиентской части (веб-интерфейс) стандартно используются JavaScript с фреймворками, такими как React, Angular или Vue.js, что обеспечит современный и отзывчивый пользовательский интерфейс.

Архитектурные паттерны и принципы построения

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

Многоуровневая архитектура:

• Уровень представления (Presentation Layer): Отвечает за взаимодействие с пользователем (веб-интерфейс, мобильное приложение).
• Уровень бизнес-логики (Business Logic Layer): Содержит основные правила и алгоритмы работы системы (например, логика бронирования, расчета стоимости билетов).
• Уровень доступа к данным (Data Access Layer): Предоставляет интерфейс для работы с базой данных, абстрагируя бизнес-логику от деталей хранения данных.
• Уровень базы данных (Database Layer): Фактическое хранилище данных.

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

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

• Микросервисная архитектура: Позволяет разделять функциональность на слабосвязанные, повторно используемые компоненты (микросервисы), каждый из которых отвечает за свою область ответственности (например, микросервис расписания, микросервис билетов, микросервис пользователей). Это улучшает гибкость, поддерживаемость и масштабируемость, но может усложнять управление и взаимодействие компонентов (требует использования API Gateway, систем мониторинга и трассировки).
• API Gateway: Единая точка входа для клиентов в микросервисной архитектуре. Он обрабатывает маршрутизацию запросов, аутентификацию, агрегацию данных из различных микросервисов.
• Event Sourcing: Паттерн, предполагающий хранение состояния приложения как последовательности неизменяемых событий (например, «Билет забронирован», «Рейс отменен»). Это позволяет сохранять полную историю изменений и легко восстанавливать систему после сбоев, а также облегчает аудит и аналитику.
• CQRS (Command Query Responsibility Segregation): Повышает масштабируемость за счет разделения нагрузки между операциями чтения (Query) и записи (Command), позволяя использовать разные модели данных и технологии для каждой операции. Например, для записи может использоваться одна БД с высокой целостностью, а для чтения — оптимизированная для скорости чтения реплика или NoSQL-хранилище.
• Pub-Sub (Publish-Subscribe): Паттерн для асинхронной коммуникации и слабой связанности между компонентами системы. Компоненты публикуют события, а другие компоненты, подписанные на эти события, реагируют на них. Это повышает отказоустойчивость и облегчает масштабирование.
• Request-Response: Классический паттерн для предсказуемого взаимодействия, когда клиент отправляет запрос и ожидает немедленного ответа.

Для нашей АИС оптимальным будет сочетание микросервисной архитектуры с API Gateway для внешнего взаимодействия. Внутри системы для критически важных процессов, требующих сохранения полной истории, может быть рассмотрен Event Sourcing, а для оптимизации работы с данными — CQRS. Pub-Sub будет полезен для асинхронной обработки событий, таких как уведомления о покупке билетов или изменениях в расписании.

Меры по обеспечению безопасности и масштабируемости

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

• Многофакторная аутентификация (MFA): Обязательна для административных учетных записей и рекомендуется для пользователей.
• Шифрование данных: Как при хранении (at rest), так и при передаче (in transit) с использованием HTTPS, TLS.
• Регулярное сканирование на уязвимости: Использование автоматизированных инструментов для поиска уязвимостей в коде и инфраструктуре.
• Внедрение систем обнаружения вторжений (IDS) и систем предотвращения вторжений (IPS): Для мониторинга сетевого трафика на предмет аномалий и блокировки вредоносных действий.
• Использование файрволов и сегментации сети: Для изоляции различных компонентов системы и ограничения доступа.
• Защита от DDoS-атак: Применение специализированных сервисов и аппаратных решений, способных фильтровать трафик и распределять нагрузку.
• Управление доступом на основе ролей (RBAC): Для строгого разграничения прав пользователей.

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

• Вертикальное масштабирование (Scale Up): Увеличение мощности одного сервера (процессора, оперативной памяти, дискового пространства). Просто в реализации, но имеет физические ограничения.
• Горизонтальное масштабирование (Scale Out): Добавление новых серверов или экземпляров приложений для распределения нагрузки. Более сложно в реализации, но обеспечивает практически неограниченный потенциал роста.

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

В контексте нашей АИС, необходимо предусмотреть:

• Использование контейнеризации (Docker) и оркестрации контейнеров (Kubernetes) для легкого горизонтального масштабирования микросервисов.
• Кластеризацию СУБД (PostgreSQL) для обеспечения высокой доступности и возможности горизонтального чтения.
• Применение Redis для кэширования часто запрашиваемых данных (например, расписаний) для снижения нагрузки на основную БД.
• Использование CDN (Content Delivery Network) для ускорения доставки статического контента (изображений, скриптов).

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

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

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

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

Начальный этап — это разработка концептуальной модели данных с использованием ER-диаграммы (диаграммы «сущность-связь»). ER-диаграмма — это графическое представление сущностей и их взаимосвязей в системе, помогающее структурировать данные и оптимизировать процессы. Для создания ER-модели не нужны специальные инструменты; ее можно построить вручную или в любом графическом редакторе, используя простые символы (прямоугольники для сущностей, овалы для атрибутов, линии для связей). Однако для профессионального проектирования используются специализированные инструменты, такие как Microsoft Visio, Lucidchart, dbForge Studio for MySQL, ERwin Data Modeler, а также функции встроенных CASE-средств СУБД.

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

Ключевые сущности для нашей АИС:

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

Пример фрагмента ER-диаграммы (нотация Чена):

+-----------+       +----------------+       +--------------+
|   СУДНО   |<----->|     РЕЙС       |<----->|   МАРШРУТ    |
+-----------+       +----------------+       +--------------+
  |                   |        |                   |
  |                   |        |                   |
  |                   |        |                   |
  | (1)               | (N)    | (N)               | (1)
  ↓                   ↓        ↓                   ↓
+-----------+       +----------------+       +--------------+
| АТРИБУТЫ  |       | АТРИБУТЫ       |       | АТРИБУТЫ     |
| (название)|       | (дата, время)  |       | (название)   |
+-----------+       +----------------+       +--------------+
                      |
                      | (N)
                      ↓
                    +----------+
                    |  БИЛЕТ   |
                    +----------+
                      |
                      | (1)
                      ↓
                    +----------+
                    | ПАССАЖИР |
                    +----------+

Проектирование логической модели базы данных

После концептуального уровня следует детализация до логического уровня. На этом этапе ER-модель обогащается атрибутами сущностей, определяются типы связей (один-к-одному, один-ко-многим, многие-ко-многим) и ключевые поля. Для логического уровня более компактной и информативной является нотация Мартина, или «воронья лапка» (Crow’s Foot), которая позволяет более наглядно представить кардинальность и обязательность связей.

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

Принципы нормализации: Для минимизации избыточности данных и обеспечения их целостности, точности и удобного доступа необходимо применить принципы нормализации, как минимум, до Третьей нормальной формы (3НФ):

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

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

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

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

Пример структуры таблиц:

Таблица: Суда	Описание	Тип данных	Ограничения
id_судна	Первичный ключ	INT	PK, NOT NULL, AUTO_INCREMENT
название	Название судна	VARCHAR(255)	NOT NULL
тип	Тип судна	VARCHAR(100)
класс	Класс судна	VARCHAR(50)
вместимость	Пассажировместимость	INT	NOT NULL
год_постройки	Год постройки	YEAR
статус	Эксплуатационный статус	VARCHAR(50)	('в работе', 'в ремонте')

Таблица: Причалы	Описание	Тип данных	Ограничения
id_причала	Первичный ключ	INT	PK, NOT NULL, AUTO_INCREMENT
название	Название причала	VARCHAR(255)	NOT NULL
адрес	Адрес причала	TEXT
координаты	Географические координаты	VARCHAR(100)

Таблица: Маршруты	Описание	Тип данных	Ограничения
id_маршрута	Первичный ключ	INT	PK, NOT NULL, AUTO_INCREMENT
название	Название маршрута	VARCHAR(255)	NOT NULL
начальный_причал_id	Внешний ключ к Причалы	INT	FK (Причалы.id_причала)
конечный_причал_id	Внешний ключ к Причалы	INT	FK (Причалы.id_причала)

Таблица: Рейсы	Описание	Тип данных	Ограничения
id_рейса	Первичный ключ	INT	PK, NOT NULL, AUTO_INCREMENT
маршрут_id	Внешний ключ к Маршруты	INT	FK (Маршруты.id_маршрута)
судно_id	Внешний ключ к Суда	INT	FK (Суда.id_судна)
дата_отправления	Дата отправления	DATE	NOT NULL
время_отправления	Время отправления	TIME	NOT NULL
время_прибытия	Время прибытия	TIME	NOT NULL
цена_билета	Базовая цена билета	DECIMAL(10,2)	NOT NULL
статус_рейса	Статус рейса	VARCHAR(50)	('запланирован', 'отменен', 'завершен')

Таблица: Пассажиры	Описание	Тип данных	Ограничения
id_пассажира	Первичный ключ	INT	PK, NOT NULL, AUTO_INCREMENT
фамилия	Фамилия	VARCHAR(255)	NOT NULL
имя	Имя	VARCHAR(255)	NOT NULL
отчество	Отчество	VARCHAR(255)
телефон	Телефон	VARCHAR(20)
email	E-mail	VARCHAR(255)	UNIQUE

Таблица: Билеты	Описание	Тип данных	Ограничения
id_билета	Первичный ключ	INT	PK, NOT NULL, AUTO_INCREMENT
рейс_id	Внешний ключ к Рейсы	INT	FK (Рейсы.id_рейса)
пассажир_id	Внешний ключ к Пассажиры	INT	FK (Пассажиры.id_пассажира)
номер_места	Номер места на судне	VARCHAR(10)
цена_продажи	Фактическая цена продажи	DECIMAL(10,2)	NOT NULL
дата_покупки	Дата покупки	DATETIME	NOT NULL
статус_билета	Статус билета	VARCHAR(50)	('куплен', 'возвращен', 'использован')

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

Методология разработки и тестирования автоматизированной системы

Стадии и этапы создания АС согласно ГОСТ 34.601-90

Разработка автоматизированных систем, особенно для государственных или крупных коммерческих предприятий, регламентируется строгими стандартами. В России процесс создания АС регулируется ГОСТ 34.601-90 «Информационная технология. Комплекс стандартов на автоматизированные системы. Автоматизированные системы. Стадии создания». Этот стандарт устанавливает стадии и этапы создания АС, начиная от определения требований и проектирования до разработки, внедрения, эксплуатации и сопровождения, что обеспечивает качество, надежность, безопасность и соответствие требованиям заказчика.

Основные стадии создания АС по ГОСТ 34.601-90:

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

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

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

Для преодоления этих проблем необходимо:

• Четкое планирование и управление проектом: Использование гибких методологий (Agile) с итеративным подходом.
• Активное участие всех стейкхолдеров: Вовлечение пользователей на всех этапах разработки.
• Всестороннее обучение персонала: Проведение тренингов и создание подробных инструкций.
• Постепенное внедрение: Запуск системы по модулям или этапами.
• Использование стандартов: Следование ГОСТам и лучшим практикам.

Разве не очевидно, что грамотное управление изменениями является фундаментом успеха любого проекта по внедрению АИС?

Методы и виды тестирования системы

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

Основные методы тестирования информационных систем:

• Модульное тестирование (Unit testing): Цель — проверить работу кода отдельных модулей или функций в изоляции. Проводится разработчиками. Инструменты: JUnit (Java), PyTest (Python), Go test (Go), Jest (JavaScript).
• Интеграционное тестирование: Проверка взаимодействия между различными модулями системы.
• Системное тестирование: Проверка всей системы в целом на соответствие функциональным и нефункциональным требованиям.
• Приемочное тестирование (User Acceptance Testing, UAT): Проводится на заключительном этапе разработки ПО заказчиком или конечными пользователями для определения готовности продукта к вводу в эксплуатацию.

Виды тестирования:

• Функциональное тестирование: Проверка того, что система выполняет все заявленные функции в соответствии с требованиями. Может быть ручным или автоматизированным.
• Автоматизированное тестирование: Использование программных средств для выполнения тестовых сценариев. Помогает сократить время тестирования на 50-80%, упростить процесс и идеально подходит для повторения стандартных операций (регрессионное тестирование). Популярные инструменты: Selenium (для веб-интерфейсов), TestComplete, Ranorex. Методы автоматизированного тестирования включают Data-driven testing, где тестовые скрипты выполняются на основе данных, хранящихся в центральном хранилище.
• Нефункциональное тестирование:
  • Тестирование производительности: Оценка скорости и отзывчивости системы при нормальной нагрузке.
  • Нагрузочное тестирование: Определение работоспособности системы под ожидаемой пиковой нагрузкой (например, 1000 одновременных пользователей при продаже билетов).
  • Стресс-тестирование: Проверка поведения системы при экстремальных нагрузках, значительно превышающих ожидаемые, для выявления точек отказа.
  • Тестирование безопасности: Проверка системы на уязвимости к внешним и внутренним угрозам.
  • Тестирование удобства использования (Usability testing): Оценка простоты и интуитивности интерфейса для конечных пользователей.

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

Пример сценария контрольного примера (покупка билета):

1. Пользовательский интерфейс:
   • Скриншот главной страницы с формой поиска рейсов.
   • Скриншот страницы результатов поиска с доступными рейсами.
   • Скриншот страницы выбора места на судне (с визуализацией палуб и свободных/занятых мест).
   • Скриншот формы ввода данных пассажира.
   • Скриншот страницы оплаты.
   • Скриншот страницы подтверждения покупки с электронным билетом (QR-код).
2. База данных:
   • Пример записи в таблице Рейсы до покупки билета (указано свободное место).
   • Пример записи в таблице Пассажиры после регистрации/ввода данных.
   • Пример записи в таблице Билеты после успешной покупки.
   • ER-диаграмма, иллюстрирующая связи между этими таблицами.
3. Тестовый сценарий (автоматизированный):
   • Описание шагов, которые выполняет автоматизированный тест (например, с использованием Selenium для веб-интерфейса):
     • Открытие страницы.
     • Ввод параметров поиска.
     • Выбор рейса.
     • Клик по свободному месту.
     • Ввод тестовых данных пассажира.
     • Имитация успешной оплаты.
     • Проверка наличия электронного билета.
   • Результаты теста: «Тест успешно пройден» или «Обнаружен дефект: не удалось забронировать место».

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

Экономическое обоснование внедрения системы

Цели и задачи экономического обоснования

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

Ключевые цели внедрения АИС:

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

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

Расчет затрат на разработку и внедрение

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

Единовременные затраты на создание АИС:

1. Предпроектные затраты:
   • Анализ предметной области, сбор и формализация требований (рабочие часы аналитиков).
   • Исследование рынка существующих решений, анали�� конкурентов.
2. Затраты на разработку этапов проектирования:
   • Проектирование архитектуры системы (архитекторы).
   • Разработка информационной модели и структуры БД (специалисты по БД).
   • Разработка функциональной и технической документации.
   • Затраты на лицензии для CASE-средств, инструментов моделирования.
3. Затраты на разработку программного обеспечения:
   • Оплата труда программистов (бэкенд, фронтенд, мобильные разработчики).
   • Стоимость лицензий на используемое ПО (IDE, операционные системы, фреймворки).
   • Затраты на тестирование (тестировщики, автоматизированные инструменты).
4. Затраты на подготовку и переподготовку кадров:
   • Обучение конечных пользователей (кассиров, диспетчеров) работе с новой системой.
   • Обучение IT-специалистов по поддержке и обслуживанию АИС.

Затраты на внедрение корпоративной информационной системы (могут частично пересекаться с единовременными, но относятся к этапу запуска):

1. Стоимость программного обеспечения:
   • Лицензии на операционные системы серверов (например, Windows Server, RHEL).
   • Лицензии на СУБД (например, коммерческие версии PostgreSQL, Oracle, MS SQL Server – если выбраны).
   • Лицензии на вспомогательные продукты (системы мониторинга, безопасности).
   • Стоимость обновлений и технической поддержки ПО.
2. Затраты на внедрение:
   • Консалтинг: Услуги внешних экспертов по оптимизации процессов и интеграции.
   • Установка и настройка: Инсталляция ПО на серверы, конфигурирование.
   • Интеграция: Взаимодействие с существующими системами (платежные шлюзы, бухгалтерские системы).
   • Обучение персонала: Проведение тренингов для пользователей и администраторов.
3. Стоимость инфраструктуры:
   • Серверы: Физические или облачные серверы для размещения АИС и БД.
   • Телекоммуникационное оборудование: Сетевое оборудование, каналы связи.
   • Рабочие станции: Обновление компьютеров для пользователей.
   • Системы хранения данных, резервного копирования.
4. Затраты на персонал: Заработная плата IT-специалистов, отвечающих за эксплуатацию и поддержку системы.

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

Оценка экономической эффективности и срока окупаемости

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

Источники годового прироста прибыли:

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

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

1. Простой метод расчета срока окупаемости:
Этот метод не учитывает изменение стоимости денег со временем (инфляцию).
Формула: Период окупаемости = Инвестиционные расходы / Годовая прибыль
* Пример: Если инвестиционные расходы на АИС составляют 5 000 000 рублей, а ожидаемый годовой прирост прибыли (экономический эффект) составляет 1 250 000 рублей, то простой срок окупаемости будет:
5 000 000 руб. / 1 250 000 руб./год = 4 года.

2. Дисконтированный метод расчета срока окупаемости (DPP):
Этот метод учитывает инфляцию и снижение ценности денег во времени, что делает его более точным. Для этого используется коэффициент дисконтирования.
Коэффициент дисконтирования рассчитывается как k = 1 / (1 + r)a, где r — процентная ставка (ставка дисконтирования, например, средняя ставка по депозитам или инфляция, выраженная десятичной дробью), a — месяц (год) расчета.

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

Год	Инвестиции	Годовой прирост прибыли	Дисконтный множитель (при r=10%)	Дисконтированный прирост прибыли	Накопленный дисконтированный прирост
0	-5 000 000	0	1	0	-5 000 000
1	0	1 250 000	1 / (1 + 0.1)1 ≈ 0.909	1 136 250	-3 863 750
2	0	1 250 000	1 / (1 + 0.1)2 ≈ 0.826	1 032 500	-2 831 250
3	0	1 250 000	1 / (1 + 0.1)3 ≈ 0.751	938 750	-1 892 500
4	0	1 250 000	1 / (1 + 0.1)4 ≈ 0.683	853 750	-1 038 750
5	0	1 250 000	1 / (1 + 0.1)5 ≈ 0.621	776 250	-262 500
6	0	1 250 000	1 / (1 + 0.1)6 ≈ 0.564	705 000	442 500

В данном примере дисконтированный срок окупаемости наступает между 5-м и 6-м годом. Более точное значение можно определить интерполяцией: 5 + (262 500 / 705 000) ≈ 5.37 года.

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

Заключение

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

Мы начали с глубокого погружения в теоретические основы автоматизированных информационных систем, дав определения ключевых понятий, таких как АИС, базы данных и СУБД, а также детально рассмотрев специфику речных судов, принципы формирования расписаний и функционал современных билетных систем. Этот фундамент позволил нам перейти к тщательному анализу предметной области, включая изучение существующих аналогов, таких как «Суда сюда!», RIVER-TICKET.RU и Boattour, что помогло выявить лучшие практики и «слепые зоны» конкурентов.

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

В разделе, посвященном архитектуре и техническим решениям, был обоснован выбор оптимальной СУБД (PostgreSQL в сочетании с Redis) и языков программирования (Go или Node.js для бэкенда, JavaScript-фреймворки для фронтенда). Мы предложили многоуровневую архитектуру и рассмотрели применение современных архитектурных паттернов, таких как микросервисы, API Gateway, Event Sourcing и CQRS, для обеспечения модульности, масштабируемости и отказоустойчивости. Особое внимание было уделено мерам безопасности и подходам к масштабируемости, что критически важно для высоконагруженных систем.

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

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

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

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

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

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

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

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

1. Габец А.П., Гончаров Д.И., Козырев Д.В., Кухлевский Д.С., Радченко М.Г. Профессиональная разработка в системе 1С: Предприятие 8 / Под ред. М.Г. Радченко. М.: 1С-Паблишинг; СПб.: Питер, 2007. 808 с.
2. Радченко М.Г. 1С: Предприятие 8.0. Практическое пособие разработчика. Примеры и типовые приемы. М.: 1С-Паблишинг, 2004. 656 с.
3. Бобошко Д.Д. 1С: Предприятие 8.0. Программирование в примерах. М.: КУДИЦ-ПРЕСС, 2007. 384 с.
4. Алексеев А., Безбородов А., Виноградов А., Горностаев Е., Дамье Г., Чичерин А. и др. 1С: Предприятие 8.0 Описание встроенного языка. Москва: ЗАО «1С», 1996–2003.
5. Корнева Л.В. 1С: Торговля+Склад. Версия 8.0. Ростов н.Д: Феникс, 2005. 272 с.
6. Экономическая информатика: Введение в экономический анализ информационных систем: Учебник. М.: ИНФРА-М, 2005.
7. Шафер Д.Ф., Фартрел Т., Шафер Л.И. Управление программными проектами: достижение оптимального качества при минимуме затрат. Пер. с англ. М.: Вильямс, 2006.
8. Марка Д.А., МакГоуэн К. Методология структурного анализа и проектирования SADT.
9. Проектирование экономических информационных систем: учеб. / под ред. Ю. Ф. Тельнова. М., 2006.
10. Автоматизированные информационные технологии в экономике: Учебник / Под ред. проф. Г.А. Титоренко. М.: Компьютер, ЮНИТИ, 2006.
11. Маклаков С.В. Моделирование бизнес-процессов с AllFusion Process Modeler (BPwin 4.1). М., 2006.
12. Маклаков С.В. Создание информационных систем с AllFusion Modeling Suite. М.: ДИАЛОГ-МИФИ, 2005.
13. Фаулер М., Скотт К. UML в кратком изложении: применение стандартного языка объектного моделирования: пер. с англ. М., 2004.
14. Фаулер М. UML – основы. Руководство по стандартному языку объектного моделирования: Пер. с англ. СПб.: Символ, 2006.
15. Петров Ю.А., Шлимович Е.Л., Ирюпин Ю.В. Комплексная автоматизация управления предприятием: Информационные технологии — теория и практика. М.: Финансы и статистика, 2005.
16. Хомоненко А.Д. и др. Базы данных: Учебник для вузов / Под ред. проф. А.Д. Хомоненко. СПб.: КОРОНА принт, 2006. 736 с.
17. Автоматизированные информационные системы // Инфотактика. URL: https://infotaktika.ru/avtomatizirovannye-informacionnye-sistemy/ (дата обращения: 11.10.2025).
18. Оценка затрат на информационные системы // КиберЛенинка. URL: https://cyberleninka.ru/article/n/otsenka-zatrat-na-informatsionnye-sistemy (дата обращения: 11.10.2025).
19. Срок окупаемости проекта: как рассчитать, формула, норма // Финтабло. URL: https://fintablo.ru/blog/srok-okupaemosti-proekta/ (дата обращения: 11.10.2025).
20. Из чего складывается стоимость внедрения корпоративной информационной системы? // Яндекс Нейро. URL: https://yandex.ru/q/question/iz_chego_skladyvaetsia_stoimost_vnedreniia_7cf65377/ (дата обращения: 11.10.2025).
21. Лучшие языки программирования для высоконагруженных систем: обзор современных технологий и практик // iFellow. URL: https://ifellow.ru/blog/luchshie-yazyki-programmirovaniya-dlya-vysokonagruzhennykh-sistem (дата обращения: 11.10.2025).
22. ГОСТ 34.601-90 Информационная технология. Комплекс стандартов на автоматизированные системы. Автоматизированные системы. Стадии создания. // Сталь Партнёр. URL: https://stal-partner.ru/content/gost-34601-90-informacionnaya-tehnologiya-kompleks-standartov-na-avtomatizirovannye-sistemy-avtomatizirovannye (дата обращения: 11.10.2025).
23. Что такое срок окупаемости проекта и как его рассчитать // Сервис «Финансист». URL: https://finansist.ru/blog/srok-okupaemosti-proekta (дата обращения: 11.10.2025).
24. Бизнес-процессы в организации: что это такое и зачем они нужны // Яндекс Практикум. URL: https://practicum.yandex.ru/blog/biznes-protsessy-v-organizatsii/ (дата обращения: 11.10.2025).
25. Что такое билетная система — преимущества и обзор функций // Nethouse. URL: https://nethouse.ru/blog/257-chto-takoe-biletnaya-sistema (дата обращения: 11.10.2025).
26. Базы данных и информационные системы. URL: https://text.isu.pub/18602882/1 (дата обращения: 11.10.2025).
27. Online tickets system, что это? // Kinoplan. URL: https://www.kinoplan.ru/blog/online-tickets-system-chto-eto/ (дата обращения: 11.10.2025).
28. Бизнес-процесс на ладони: простые методы анализа и оптимизации // Business Studio. URL: https://www.businessstudio.ru/articles/chetyre_metoda_analiza_biznes_protsessa/ (дата обращения: 11.10.2025).
29. Речные прогулки на теплоходе по Москве-реке — купить билеты на речные трамвайчики с экскурсией 2024 | цены и расписание речных корабликов // RIVER-TICKET.RU. URL: https://river-ticket.ru/ (дата обращения: 11.10.2025).
30. Классификация речных судов // Аренда катера. URL: https://arenda-katera.ru/klassifikaciya-rechnyh-sudov.html (дата обращения: 11.10.2025).
31. Классификация речных судов // АрендаТеплохода.РФ. URL: https://xn--80abj0afpbc0ar.xn--p1ai/articles/klassifikatsiya-rekhnykh-sudov (дата обращения: 11.10.2025).
32. Топ-5 архитектурных паттернов для распределённых систем // Tproger. URL: https://tproger.ru/articles/5-arhitekturnyh-patternov-dlya-raspredelennyh-sistem/ (дата обращения: 11.10.2025).
33. Лекция 5 Функциональные требования к АИС. URL: https://www.vixri.com/d/Lekcia%205%20Funkcionalnye%20trebovanija%20k%20AIS.pdf (дата обращения: 11.10.2025).
34. Методика расчета экономической эффективности создания и внедрения информационных систем // Файловый архив студентов. URL: https://studfile.net/preview/6686309/page:14/ (дата обращения: 11.10.2025).
35. Методы тестирования интегрированных информационных систем // КиберЛенинка. URL: https://cyberleninka.ru/article/n/metody-testirovaniya-integrirovannyh-informatsionnyh-sistem (дата обращения: 11.10.2025).
36. ГОСТы в корпоративных информационных системах // ECM-Journal. URL: https://ecm-journal.ru/docs/Gosty-v-korporativnykh-informacionnykh-sistemakh.aspx (дата обращения: 11.10.2025).
37. Тестирование информационных систем // AT Consulting. URL: https://www.at-consulting.ru/services/testing-solutions/testirovanie-informatsionnyh-sistem (дата обращения: 11.10.2025).
38. Путь от бизнес-требований до функциональных в процессе разработки ПО // 66 Бит. URL: https://66bit.ru/blog/biznes-trebovaniya/ (дата обращения: 11.10.2025).
39. 11 языков программирования для DevOps и их применение // Habr. URL: https://habr.com/ru/companies/selectel/articles/679788/ (дата обращения: 11.10.2025).
40. Логическая модель данных (ER-диаграмма) системы автоматизации покупки билетов // Visual Paradigm. URL: https://www.visual-paradigm.com/ru/diagrams/examples/er-diagram-for-ticket-purchasing-system/ (дата обращения: 11.10.2025).
41. ER-диаграммы: что это, применение, нотации — как создать ER-диаграмму сущность-связь, примеры // Skillbox. URL: https://skillbox.ru/media/code/er-diagrammy-chto-eto-primenenie-notatsii-kak-sozdat-er-diagrammu-sushchnost-svyaz-primery/ (дата обращения: 11.10.2025).
42. Лучшие языки программирования для серверной части // Skypro. URL: https://sky.pro/media/yazyki-programmirovaniya-dlya-servernoy-chasti/ (дата обращения: 11.10.2025).
43. Анализ требований к информационным системам. URL: https://www.clarity.ru/upload/files/articles/2004-analiz-trebovaniy-k-informacionnym-sistemam.pdf (дата обращения: 11.10.2025).
44. Анализ бизнес-процессов: этапы и инструменты // TEAMLY. URL: https://teamly.ru/blog/analiz-biznes-protsessov-etapy-i-instrumenty/ (дата обращения: 11.10.2025).
45. Анализ и оптимизация бизнес-процессов организации // Jobers.ru. URL: https://jobers.ru/blog/analiz-i-optimizatsiya-biznes-protsessov-organizatsii (дата обращения: 11.10.2025).
46. Что такое база данных – особенности, принцип работы и выбора системы управления // GeekBrains. URL: https://gb.ru/blog/chto-takoe-baza-dannyh/ (дата обращения: 11.10.2025).
47. База данных: что это такое и зачем она нужна // Skillbox. URL: https://skillbox.ru/media/code/chto-takoe-baza-dannyh/ (дата обращения: 11.10.2025).
48. Как не сломать продакшен: 8 основных паттернов распределенных систем // Habr. URL: https://habr.com/ru/articles/718428/ (дата обращения: 11.10.2025).
49. Разработка функциональных требований к информационной системе «ООО // Уральский федеральный университет. URL: https://elar.urfu.ru/bitstream/10995/85145/1/m_e_is_fatttakhov_2020.pdf (дата обращения: 11.10.2025).
50. Как отследить автобус и другой общественный транспорт онлайн // М.Видео. URL: https://www.mvideo.ru/travel-blog/kak-otsledit-avtobus-i-drugoy-obshchestvennyy-transport-onlain-58823 (дата обращения: 11.10.2025).
51. Сервис продажи билетов на водные маршруты Boattour // Mobecan. URL: https://mobecan.com/cases/boattour (дата обращения: 11.10.2025).
52. Технико-экономическое обоснование дипломных проектов (работ), связанных с разработкой автоматизированных информационных систем (АИС) // Studbooks.net. URL: https://studbooks.net/1435773/ekonomika/tehniko_ekonomicheskoe_obosnovanie_diplomnyh_proektov_rabot_svyazannyh_razrabotkoy_avtomatizirovannyh (дата обращения: 11.10.2025).
53. Как рассчитать экономический эффект от внедрения системы мониторинга транспорта по расходу топлива // Блог TN-GROUP. URL: https://tn-group.org/blog/kak-rasschitat-ekonomicheskiy-effekt-ot-vnedreniya-sistemy-monitoringa-transporta-po-rashodu-topliva/ (дата обращения: 11.10.2025).
54. Заработал сервис для покупки билетов на прогулочные теплоходы и речные трамваи // Сайт Москвы. URL: https://www.mos.ru/news/item/108422073/ (дата обращения: 11.10.2025).
55. В Москве создадут единую систему продажи билетов на водный транспорт // Москвич Mag. URL: https://moskvichmag.ru/gorozhane/v-moskve-sozdadut-edinuyu-sistemu-prodazhi-biletov-na-vodnyj-transport/ (дата обращения: 11.10.2025).
56. Что такое бизнес-процессы, BPM: определение, примеры и классификация // ELMA365. URL: https://elma365.com/blog/chto-takoe-biznes-processy/ (дата обращения: 11.10.2025).
57. Срок окупаемости: формула и методы расчета, примеры // Блог Topfranchise. URL: https://topfranchise.ru/articles/srok-okupaemosti-formula-i-metody-rascheta-primery/ (дата обращения: 11.10.2025).
58. Срок окупаемости инвестиций, простой и дисконтированный способ расчета, индекс рентабельности // Банки.ру. URL: https://www.banki.ru/news/daytheme/?id=10972275 (дата обращения: 11.10.2025).
59. ГОСТ 34.601-90 ИТ. Стадии создания // Gostperevod.ru. URL: https://gostperevod.ru/gost-34-601-90-it-stadii-sozdaniya.html (дата обращения: 11.10.2025).
60. Как посмотреть, где сейчас едет автобус // Газпромбанк. URL: https://www.gazprombank.ru/personal/articles/58316/ (дата обращения: 11.10.2025).
61. Определение времени движения, сообщения, рейса, оборотного рейса // TransportGuide.Ru. URL: https://transportguide.ru/articles/organizaciya_v_transportnoj_otrasli/opredelenie_vremeni_dvizheniya_soobshcheniya_rejsa.html (дата обращения: 11.10.2025).
62. Как формируется расписание движения общественного транспорта в городских условиях? // Яндекс Нейро. URL: https://yandex.ru/q/question/kak_formiruetsia_raspisanie_dvizheniia_obshchestvennogo_d7328906/ (дата обращения: 11.10.2025).
63. Срок окупаемости: формула и методы расчета, пример // Бизнесменс.ру. URL: https://biznesmens.ru/finansy/srok-okupaemosti (дата обращения: 11.10.2025).
64. Разработка автоматизированной системы отчетной деятельности для малого бизнеса ООО «Паркет Трио» // РЕПОЗИТОРИЙ ТОЛЬЯТТИНСКОГО ГОСУДАРСТВЕННОГО УНИВЕРСИТЕТА. URL: https://repo.tltsu.ru/handle/items/22197 (дата обращения: 11.10.2025).
65. Разработка автоматизированной информационной системы управления продажами промышленного предприятия // EasySchool. URL: https://easyschool.ru/referats/razrabotka-avtomatizirovannoj-informacionnoj-sistemy-upravleniya-prodazhami-promyshlennogo-predpriyatiya (дата обращения: 11.10.2025).
66. Курсовая работа «Автоматизированные информационные системы поддержки процесса управления материально-техническим снабжением» // Инфоурок. URL: https://infourok.ru/kursovaya-rabota-avtomatizirovannie-informacionnie-sistemi-podderzhki-processa-upravleniya-materialnotehnicheskim-snabzheniem-5456209.html (дата обращения: 11.10.2025).