Проектирование Автоматизированной Информационной Системы «Автовокзал»: План курсовой работы с учетом ГОСТ 34, ФЗ №16-ФЗ и Технико-Экономического Обоснования

По экспертным оценкам, внедрение автоматизированной системы продажи билетов позволяет увеличить производительность оператора-кассира с 30-45 до 120 и более обслуженных пассажиров в час. Эта поразительная цифра красноречиво свидетельствует о трансформационном потенциале информационных систем в транспортной отрасли, где каждая секунда ожидания в очереди — это упущенная выгода и сниженная лояльность пассажиров. Что из этого следует? Автоматизация становится не просто конкурентным преимуществом, а фундаментальным требованием для выживания и развития в условиях современного рынка.

Введение

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

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

Теоретические и Методологические Основы Проектирования АИС

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

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

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

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

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

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

Концептуальное Моделирование Предметной Области

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

Ключевые термины:

• Автоматизированная Информационная Система (АИС): Совокупность технических средств, программного обеспечения, персонала и методов, предназначенная для сбора, хранения, обработки, поиска и выдачи информации, а также для автоматизации управленческих и производственных процессов.
• Система Управления Базами Данных (СУБД): Комплекс программных средств, предназначенный для создания, управления и обслуживания баз данных, обеспечения доступа к данным и их целостности.
• Функциональные требования: Описывают, что система должна делать, то есть её конкретные функции и сервисы. Например, «система должна продавать билеты», «система должна выводить расписание».
• Нефункциональные требования: Описывают, как система должна работать, то есть её качество, ограничения и характеристики. Например, «система должна быть надёжной», «система должна обеспечивать безопасность данных», «время обработки запроса не должно превышать 2 секунд».

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

На практике Информационно-логическая модель часто реализуется в виде Entity-Relationship (ER) модели (модели «Сущность-Связь»). Её основными компонентами являются:

• Сущности (Entity): Информационные объекты или предметы, о которых необходимо хранить информацию (например, «Маршрут», «Рейс», «Пассажир», «Билет»). Каждая сущность должна иметь уникальный идентификатор.
• Атрибуты (Attribute): Свойства, характеристики сущностей (например, для сущности «Пассажир» это могут быть «Фамилия», «Имя», «Отчество», «Паспортные данные»).
• Связи (Relationship): Взаимоотношения между сущностями, которые показывают, как они логически связаны друг с другом (например, «Пассажир» *покупает* «Билет», «Рейс» *состоит из* «Маршрута»).

ИЛМ создается по результатам тщательного предпроектного обследования предметной области. Она является критически важной для составления технико-экономического обоснования (ТЭО) банка данных и, что не менее важно, служит непосредственным основанием для разработки Технического Задания, обеспечивая единообразное понимание структуры данных всеми участниками проекта.

Анализ Бизнес-Процессов и Формирование Требований к АИС «Автовокзал»

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

Анализ Существующих Процессов (продажа билетов, управление расписанием)

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

Традиционно, процесс продажи билетов на автовокзалах часто сталкивается с рядом проблем:

• Ручное оформление: Заполнение бланков, поиск информации о рейсах по бумажным носителям, что приводит к значительным временным затратам (3-5 минут на оформление одного билета).
• Ошибки: Человеческий фактор при вводе данных, расчётах и поиске мест.
• Отсутствие актуальной информации: Сложность оперативного получения данных о наличии свободных мест и изменениях в расписании.
• Длинные очереди: Прямое следствие низкой производительности кассиров и неэффективности процессов.

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

Для детального функционального анализа существующих и предлагаемых процессов будут использоваться диаграммы моделирования:

• Диаграммы потоков данных (Data Flow Diagrams, DFD): Позволяют визуализировать движение информации в системе, идентифицировать источники и получателей данных, а также процессы их обработки. Например, можно построить DFD для процесса «Продажа билета», который покажет, как данные о запросе пассажира, наличии мест, оформлении и печати чека перемещаются между кассиром, базой данных расписания и фискальным регистратором.
• Диаграммы вариантов использования (UML Use Case Diagrams): Описывают функциональность системы с точки зрения взаимодействия акторов (пользователей или других систем) с системой. Например, варианты использования могут быть «Продать билет», «Забронировать место», «Оформить возврат билета», «Просмотреть расписание», «Изменить расписание». Каждый вариант использования сопровождается детальным текстовым описанием сценариев взаимодействия.

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

Формулирование Функциональных и Нефункциональных Требований

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

Ключевой функционал АИС «Автовокзал» должен включать:

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

Нефункциональные требования определяют качество и характеристики системы:

• Надёжность: Система должна обеспечивать бесперебойную работу 24/7, минимизацию сбоев и быстрое восстановление после них.
• Масштабируемость: Способность системы обрабатывать растущий объем данных и количество пользователей без существенной потери производительности.
• Производительность: Время отклика на запросы должно быть минимальным. Например, время оформления одного билета, включая ввод данных пассажира, должно сократиться до 10-20 секунд (время системной обработки запроса и печати), по сравнению с 3-5 минутами при ручном оформлении.
• Безопасность: Защита данных от несанкционированного доступа, изменения или уничтожения.
• Удобство использования (Usability): Интуитивно понятный интерфейс для кассиров и администраторов, минимизирующий обучение и вероятность ошибок.
• Сопровождаемость: Легкость внесения изменений, обновлений и устранения ошибок.
• Совместимость: Возможность интеграции с другими системами (например, с бухгалтерскими системами, платёжными шлюзами).

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

Проектные Решения и Разработка АИС

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

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

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

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

1. Клиентский уровень (Уровень представления, UI): Отвечает за взаимодействие с пользователем. В случае АИС «Автовокзал» это будет Автоматизированное Рабочее Место (АРМ) кассира, администратора, а возможно и веб-интерфейс для пассажиров. Этот уровень лишь отображает данные и отправляет запросы на сервер.
2. Серверный уровень (Уровень бизнес-логики): Содержит основную логику работы системы. Здесь обрабатываются запросы от клиентского уровня, выполняются бизнес-правила (например, проверка наличия мест, расчёт стоимости билета, применение скидок), и происходит взаимодействие с базой данных. На этом уровне часто применяются архитектурные шаблоны типа Model-View-Controller (MVC) или Model-View-ViewModel (MVVM), которые обеспечивают строгое разделение между представлением данных (View) и логикой их обработки (Controller/ViewModel). Это повышает тестируемость, модульность и сопровождаемость системы.
3. Уровень базы данных: Отвечает за постоянное хранение, извлечение и управление данными. Этот уровень абстрагирован от бизнес-логики, что позволяет использовать различные СУБД и оптимизировать хранение данных.

Преимущества многоуровневой архитектуры:

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

Логическое Моделирование Данных (ER-диаграмма)

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

Основные сущности (будущие таблицы в базе данных) логической модели данных для АИС «Автовокзал» включают:

• Маршруты: Информация о направлениях движения (например, «Москва – Санкт-Петербург»), продолжительность, промежуточные пункты.
• Рейсы: Конкретные отправления по маршруту с указанием даты, времени, номера автобуса, перевозчика.
• Билеты: Запись о каждом проданном билете, включая номер билета, пассажира, рейс, место, стоимость, статус оплаты.
• Пассажиры: Данные о пассажирах (ФИО, паспортные данные, контактная информация). Важно предусмотреть разделение данных на совершеннолетних и несовершеннолетних пассажиров для соблюдения правовых норм и учета специфики перевозки детей.
• Пользователи/Администраторы: Информация о сотрудниках системы, их ролях и правах доступа.
• Автобусы: Данные о транспортных средствах, их вместимости, характеристиках.
• Перевозчики: Информация о компаниях, осуществляющих перевозки.

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

• Один «Маршрут» может иметь много «Рейсов».
• Один «Рейс» может быть связан со многими «Билетами».
• Один «Пассажир» может приобрести много «Билетов».
• Один «Рейс» выполняется одним «Автобусом» и одним «Перевозчиком».

Критически важным шагом является приведение логической модели данных к нормальным формам — процессу нормализации. Этот процесс направлен на устранение избыточности данных, предотвращение аномалий при вставке, обновлении и удалении информации, а также обеспечение целостности данных. Минимально необходимым требованием для корректной эксплуатации реляционной базы данных АИС является достижение Третьей нормальной формы (3НФ). Это гарантирует, что каждый неключевой атрибут в таблице зависит только от первичного ключа, устраняя транзитивные зависимости (когда неключевой атрибут зависит от другого неключевого атрибута). Например, если в таблице «Рейсы» будет храниться название перевозчика, а не его идентификатор, то при изменении названия перевозчика придётся обновлять множество записей в таблице «Рейсы», что противоречит 3НФ. Что из этого следует? Достижение 3НФ критически важно для поддержания высокой производительности системы и минимизации ошибок при работе с данными в долгосрочной перспективе.

Проектирование Автоматизированного Рабочего Места (АРМ) Кассира

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

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

Ключевые особенности интерфейса АРМ Кассира:

• Единое окно для поиска и продажи: Быстрый доступ к выбору города отправления/прибытия, даты, времени рейса.
• Визуальное отображение наличия мест: Интерактивная схема автобуса с доступными/занятыми местами.
• Автоматическое заполнение данных: Минимизация ручного ввода, например, через выбор пассажира из существующей базы или сканирование паспорта.
• Различные способы оплаты: Поддержка наличного, безналичного расчёта (с возможностью подключения эквайрингового терминала).
• Быстрая печать билетов и чеков: Интеграция с печатающими устройствами.

Обязательные технические средства АРМ Кассира:

• Персональный компьютер: С достаточной производительностью для работы с системой.
• Подключение к локальной сети: Для взаимодействия с сервером бизнес-логики и базой данных.
• Фискальный регистратор (или чекопечатающая машинка): Критически важное устройство, соответствующее требованиям Федерального закона №54-ФЗ. Оно обеспечивает фиксацию каждой продажи, формирование и передачу чеков в налоговые органы.
• Принтер: Для печати билетов.
• Эквайринговый терминал (опционально): Для приема безналичной оплаты по банковским картам.

При продаже билета кассовый чек (или Бланк Строгой Отчетности – БСО), помимо общих фискальных реквизитов (согласно ФЗ-54), должен содержать транспортно-специфическую информацию, такую как: наименование маршрута (например, «Москва — Санкт-Петербург»), дату и время поездки, стоимость проезда и название перевозчика. Это не только требование законодательства, но и важный элемент для удобства пассажиров и контроля. Продажа билета кассиром производится только после поступления на АРМ подтверждения от сервера о наличии свободных мест в автобусе требуемого рейса, что исключает двойные продажи и гарантирует актуальность информации.

Обеспечение Информационной Безопасности (ИБ) Проекта

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

Нормативно-Правовая База ИБ

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

1. Конфиденциальность: Гарантия того, что информация доступна только авторизованным лицам и системам. Несанкционированный доступ третьих лиц к персональным данным пассажиров или коммерческой информации перевозчиков недопустим.
2. Целостность: Обеспечение неизменности и достоверности информации. Данные должны изменяться только уполномоченными лицами или системами, а любые попытки несанкционированного изменения должны быть предотвращены или обнаружены.
3. Доступность: Гарантия того, что авторизованные пользователи могут получить доступ к информации и ресурсам системы тогда, когда это необходимо. Сбои, ведущие к недоступности системы продажи билетов, напрямую влияют на прибыль и репутацию.

Для объектов транспортной инфраструктуры (ОТИ) в Российской Федерации действуют особые регуляторные требования. Критически важно подчеркнуть соответствие АИС «Автовокзал» Федеральному закону №16-ФЗ «О транспортной безопасности». Этот закон устанавливает правовые, организационные и экономические основы обеспечения транспортной безопасности, включая требования по оценке уязвимости объектов транспортной инфраструктуры и транспортных средств, их категорированию и разработке планов обеспечения транспортной безопасности. Это означает, что АИС «Автовокзал» должна быть спроектирована с учетом этих требований, чтобы пройти соответствующие проверки и сертификацию.

Технические и Административные Меры Защиты

Обеспечение ИБ — это комплексный подход, включающий как технические, так и организационные меры.

Технические меры защиты:

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

Административные меры защиты:

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

Согласно аналитическим отчетам российских ИБ-компаний за 2024–2025 гг., транспортная отрасль входит в число наиболее атакуемых хакерами, при этом основными методами атак являются использование вредоносного ПО (35%) и эксплуатация уязвимостей (18%). Более того, эти же отчеты указывают, что более 50% транспортных компаний сталкиваются с утечками информации по вине собственных сотрудников. Это подчеркивает критичность не только технических, но и административных, организационных мер защиты. Ошибки или умышленные действия персонала могут быть столь же разрушительны, как и внешние атаки. Что из этого следует? Инвестиции в комплексную систему ИБ с акцентом на человеческий фактор являются обязательным условием для обеспечения долгосрочной устойчивости и доверия к АИС «Автовокзал».

Для обеспечения целостности и достоверности данных, помимо резервного копирования, применяются:

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

Комплексный подход к ИБ, учитывающий как технические аспекты, так и человеческий фактор, а также соответствие отраслевым нормативам, является основой для создания надёжной и защищённой АИС «Автовокзал».

Технико-Экономическое Обоснование (ТЭО) Проекта АИС

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

Оценка Капитальных Затрат (CAPEX)

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

К = Соборуд + СПО + Свнедр

Где:

• К — общие капитальные затраты на создание АИС.
• С_оборуд — стоимость технических средств. Это включает в себя серверное оборудование (серверы базы данных, серверы приложений), рабочие станции для кассиров и администраторов, сетевое оборудование (маршрутизаторы, коммутаторы), фискальные регистраторы, принтеры, эквайринговые терминалы и другое периферийное оборудование. Например, для 10 АРМ кассиров и одного серверного комплекса стоимость может составлять от 1.5 до 3 миллионов рублей в зависимости от выбранной конфигурации и производителей.
• С_ПО — стоимость приобретения/разработки программного обеспечения и лицензий. Сюда входят лицензии на операционные системы для серверов и рабочих станций (например, Windows Server, Windows 10/11), лицензии на СУБД (например, Microsoft SQL Server, Oracle Database, или затраты на поддержку open-source решений типа PostgreSQL), лицензии на офисное ПО, а также стоимость разработки самого прикладного ПО АИС «Автовокзал» (если оно разрабатывается с нуля) или его приобретения.
• С_внедр — расходы на внедрение и обучение персонала. Включают затраты на установку и настройку оборудования, инсталляцию и конфигурацию ПО, миграцию данных (если есть старая система), проведение пусконаладочных работ, а также обучение конечных пользователей (кассиров, администраторов, диспетчеров).

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

Зэ = Wу ⋅ Сэ ⋅ Тв

Где:

• W_у — установленная мощность всего оборудования АИС (кВт). Рассчитывается как сумма мощностей серверов, рабочих станций, сетевого оборудования и периферии.
• С_э — стоимость электроэнергии (руб/кВт·ч). Это тариф, установленный для предприятия.
• Т_в — время работы системы в течение года (часы). Для круглосуточной работы 365 дней в году это будет 365 × 24 = 8760 часов.

Пример расчета: Если общая установленная мощность оборудования составляет 5 кВт, стоимость электроэнергии 7 руб/кВт·ч, а система работает 8760 часов в год, то З_э = 5 кВт ⋅ 7 руб/кВт·ч ⋅ 8760 ч = 306 600 руб/год.

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

Экономическая и Социальная Эффективность

Оценка эффективности АИС включает в себя несколько аспектов:

1. Функциональная эффективность: Определяется степенью соответствия качества информационного продукта (например, точность расписания, скорость продажи билета) требованиям потребителя (пассажира, кассира, руководства). Повышение скорости обслуживания, снижение количества ошибок — это прямые показатели функциональной эффективности.
2. Экономическая эффективность: Выражается в соотношении затрат на создание и эксплуатацию АИС и полученных результатов (дополнительные доходы, снижение издержек). Экономическая эффективность проявляется в абсолютных (например, чистый дисконтированный доход) и относительных эффектах. Ключевым относительным показателем оценки экономической эффективности ИТ-проекта является Коэффициент возврата инвестиций (Return on Investment, ROI).

Формула расчета ROI:

ROI = (Прибыльобщ - Затратыобщ) / Затратыобщ × 100%

Где:

• Прибыль_общ — общая прибыль от проекта. Включает увеличение выручки (например, за счет роста пассажиропотока благодаря улучшению сервиса, минимизации простоев), снижение операционных расходов (например, за счет оптимизации штата, уменьшения количества ошибок, снижения затрат на бумажные бланки).
• Затраты_общ — общие затраты на проект. Включают CAPEX и операционные затраты (OPEX) за период, в течение которого рассчитывается ROI.

Пример: Если общая прибыль от проекта за 3 года составила 10 млн руб, а общие затраты (CAPEX + OPEX за 3 года) — 5 млн руб, то ROI = (10 000 000 — 5 000 000) / 5 000 000 × 100% = 100%. Это означает, что инвестиции удвоились.

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

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

Заключение

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

Ключевые выводы, подтверждающие соответствие разработанного плана всем требованиям, включают:

1. Методологическая строгость: Проект базируется на фундаментальных принципах системного анализа и проектирования, с обязательной привязкой к российским государственным стандартам, в частности, ГОСТ 34.601-90 и ГОСТ 34.201-89. Это обеспечивает систематизированный подход к каждой стадии создания АИС, от формирования требований до разработки рабочей документации, гарантируя полноту и корректность проектных артефактов.
2. Глубокий анализ предметной области: Проведенное обследование бизнес-процессов позволило выявить критические точки (ручное оформление, очереди, ошибки) и сформулировать исчерпывающие функциональные и нефункциональные требования к АИС. Особое внимание уделено специфике АРМ кассира, включая необходимость интеграции с фискальным регистратором и отображения транспортно-специфической информации на чеке, что является прямой реализацией требований ФЗ-54.
3. Обоснованные проектные решения: Выбор многоуровневой (N-Tier) архитектуры обеспечивает масштабируемость, надежность и гибкость системы. Разработанная логическая модель данных с учетом достижения Третьей нормальной формы (3НФ) гарантирует целостность и минимизацию избыточности информации.
4. Комплексное обеспечение информационной безопасности: Проект учитывает специфику транспортной отрасли и основывается на требованиях Федерального закона №16-ФЗ «О транспортной безопасности». Детализированы как технические (контроль доступа, резервирование), так и административные меры защиты, что крайне важно в свете актуальных статистических данных об утечках по вине сотрудников.
5. Строгое технико-экономическое обоснование: Включение детального расчета капитальных затрат (CAPEX) и использование формулы для оценки коэффициента возврата инвестиций (ROI) придает проекту практическую ценность и демонстрирует экономическую целесообразность внедрения АИС.

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

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

1. ГОСТ 34.601-90. Информационная технология (ИТ). Комплекс стандартов на автоматизированные системы. Автоматизированные системы. Стадии создания. [Электронный ресурс]. URL: https://docs.cntd.ru/document/1200003058 (дата обращения: 06.10.2025).
2. Технико-экономическое обоснование создания автоматизированной информационной системы [Электронный ресурс]. URL: https://narod.ru (дата обращения: 06.10.2025).
3. Методики технико-экономического обоснования создаваемых проектов информационных систем в условиях высшего учебного заведения / cyberleninka.ru. [Электронный ресурс]. URL: https://cyberleninka.ru/article/n/metodiki-tehniko-ekonomicheskogo-obosnovaniya-sozdavaemyh-proektov-informatsionnyh-sistem-v-usloviyah-vysshego-uchebnogo-zavedeniya (дата обращения: 06.10.2025).
4. Рабочее место кассира [Авибус: Управление автовокзалами]. [Электронный ресурс]. URL: https://avibus.pro/ (дата обращения: 06.10.2025).
5. Автоматизированная информационная система продажи авиабилетов — Электронная библиотека ПГУ — Пензенский государственный университет. [Электронный ресурс]. URL: https://elib.pnzgu.ru/ (дата обращения: 06.10.2025).
6. Технико-экономическое обоснование создания автоматизированных систем и программных продуктов / ssau.ru. [Электронный ресурс]. URL: https://ssau.ru/ (дата обращения: 06.10.2025).
7. Sidorova D. 4 типа архитектуры программного обеспечения / NOP::Nuances of Programming. [Электронный ресурс]. URL: https://medium.com/@daria.sidorova/4-%D1%82%D0%B8%D0%BF%D0%B0-%D0%B0%D1%80%D1%85%D0%B8%D1%82%D0%B5%D0%BA%D1%82%D1%83%D1%80%D1%8B-%D0%BF%D1%80%D0%BE%D0%B3%D1%80%D0%B0%D0%BC%D0%BC%D0%BD%D0%BE%D0%B3%D0%BE-%D0%BE%D0%B1%D0%B5%D1%81%D0%BF%D0%B5%D1%87%D0%B5%D0%BD%D0%B8%D1%8F-4f2e51f0f3e6 (дата обращения: 06.10.2025).
8. Самые важные архитектурные шаблоны, которые нужно знать / Habr. [Электронный ресурс]. URL: https://habr.com/ru/articles/718306/ (дата обращения: 06.10.2025).
9. Защита информации в автоматизированных информационных системах / SearchInform. [Электронный ресурс]. URL: https://www.searchinform.ru/informatsionnaya-bezopasnost/zashchita-informatsii-v-avtomatizirovannykh-informatsionnykh-sistemakh/ (дата обращения: 06.10.2025).
10. Многоуровневые модели в архитектуре клиент-сервер / Открытые системы. [Электронный ресурс]. URL: https://www.osp.ru/os/2001/05/177995 (дата обращения: 06.10.2025).
11. ТЕХНОЛОГИЯ РАБОТЫ АВТОМАТИЗИРОВАННОЙ СИСТЕМЫ ПРОДАЖИ БИЛЕТОВ АВТОВОКЗАЛОВ И АВТОСТАНЦИЙ / Фундаментальные исследования (научный журнал). [Электронный ресурс]. URL: https://fundamental-research.ru/ru/article/view?id=43361 (дата обращения: 06.10.2025).
12. Методы обеспечения информационной безопасности — основные способы и приемы / smart-soft.ru. [Электронный ресурс]. URL: https://smart-soft.ru/metodyi-obespecheniya-informatsionnoy-bezopasnosti-osnovnyie-sposoby-i-priemyi (дата обращения: 06.10.2025).
13. Информационная безопасность в логистике и на транспорте / TAdviser. [Электронный ресурс]. URL: https://www.tadviser.ru/index.php/%D0%A1%D1%82%D0%B0%D1%82%D1%8C%D1%8F:%D0%98%D0%BD%D1%84%D0%BE%D1%80%D0%BC%D0%B0%D1%86%D0%B8%D0%BE%D0%BD%D0%BD%D0%B0%D1%8F_%D0%B1%D0%B5%D0%B7%D0%BE%D0%BF%D0%B0%D1%81%D0%BD%D0%BE%D1%81%D1%82%D1%8C_%D0%B2_%D0%BB%D0%BE%D0%B3%D0%B8%D1%81%D1%82%D0%B8%D0%BA%D0%B5_%D0%B8_%D0%BD%D0%B0_%D1%82%D1%80%D0%B0%D0%BD%D1%81%D0%BF%D0%BE%D1%80%D1%82%D0%B5 (дата обращения: 06.10.2025).
14. Информационно-логическая модель аис / studfile.net. [Электронный ресурс]. URL: https://studfile.net/preview/10255871/page:2/ (дата обращения: 06.10.2025).