Создание базы данных для анализа неисправностей вагонов в MS Access: Проектирование, реализация и экономическое обоснование с учетом требований безопасности и экологичности

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

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

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

Объектом исследования является процесс учета и анализа неисправностей грузовых вагонов, а предметом — информационная система, реализованная на платформе MS Access. Методологическая база работы включает системный анализ, методы проектирования баз данных (ER-моделирование, нормализация), принципы программной инженерии, а также методы экономического обоснования и оценки рисков.

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

Обзор систем управления базами данных и реляционная модель

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

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

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

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

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

Классификация и формализация неисправностей вагонов

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

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

Одним из таких ключевых документов является «Классификатор основных неисправностей грузовых вагонов» (К ЖА 2005 05), утверждённый Комиссией Совета по железнодорожному транспорту полномочных специалистов вагонного хозяйства железнодорожных администраций. Этот классификатор использует серийно-порядковую систему кодирования с трёхзначным цифровым кодом (XYZ), который позволяет однозначно идентифицировать тип неисправности и её принадлежность к конкретному узлу вагона.

Рассмотрим структуру этого кода:

• Первая цифра (X): Указывает на укрупнённый узел вагона, к которому относится неисправность. Например:
  • 1 — колесная пара
  • 2 — тележка
  • 3 — автосцепное оборудование
  • 4 — автотормозное оборудование
  • 5 — кузов
  • 6 — рама вагона
• Вторая и третья цифры (YZ): Соответствуют порядковому номеру конкретной неисправности элемента узла.

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

Код X	Узел вагона	Код YZ	Тип неисправности	Допустимые нормы (пример)
1	Колесные пары	01	Тонкий гребень	Прокат > 9 мм или 7-9 мм до ближайшего ПТО.
1		02	Прокат по кругу катания выше нормы	Прокат > 9 мм или 7-9 мм до ближайшего ПТО.
1		03	Кольцевая выработка поверхности катания
1		04	Навар на поверхности катания
4	Автотормозное оборудование	01	Заклинивание авторегулятора рычажной передачи
4		02	Утеря ручек переключения режима воздухораспределителя
4		03	Обрыв поддерживающих скоб горизонтальных рычагов
4		04	Износы деталей тормозной рычажной передачи
—	Буксовые узлы	—	Выкрошивание подшипников
—		—	Износ подшипников
—		—	Выплавление баббитового слоя
—		—	Износы и трещины корпуса подшипников
—		—	Повреждения польстеров
—		—	Загрязнение и обводнение осевой смазки

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

Обоснование выбора СУБД MS Access

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

MS Access как СУБД: По своей сути, MS Access является гибридным продуктом, сочетающим в себе реляционную СУБД и средства разработки приложений. Это означает, что он не только позволяет создавать и управлять базами данных, но и предоставляет мощный набор инструментов для разработки пользовательского интерфейса (формы), создания запросов и отчётов, а также автоматизации с использованием Visual Basic for Applications (VBA).

Преимущества выбора MS Access:

1. Простота освоения и использования: Для студентов и начинающих разработчиков Access предлагает относительно низкий порог входа. Интуитивно понятный графический интерфейс, мастера создания объектов и широкая документация позволяют быстро освоить основные принципы работы с базами данных и разработки приложений.
2. Экономическая доступность: MS Access входит в состав пакета Microsoft Office, который широко распространён в образовательных учреждениях и на предприятиях, что исключает необходимость приобретения дорогостоящих серверных СУБД и инструментов разработки.
3. Достаточный функционал для средних задач: Для решения задачи анализа неисправностей вагонов на уровне отдельного пункта технического обслуживания или малого депо, функциональных возможностей Access более чем достаточно. Он позволяет эффективно хранить тысячи записей, выполнять сложные запросы и генерировать разнообразные отчёты.
4. Визуальная разработка: Возможность создавать формы, отчёты и запросы в визуальном режиме значительно ускоряет процесс разработки и позволяет сосредоточиться на логике предметной области, а не на синтаксисе SQL или программировании интерфейса с нуля.
5. Интеграция с другими продуктами Microsoft Office: Бесшовная интеграция с Excel, Word и Outlook облегчает импорт/экспорт данных и создание аналитических отчётов.

Несмотря на некоторые ограничения в масштабируемости по сравнению с корпоративными СУБД (например, SQL Server, Oracle), для целей дипломной работы, требующей демонстрации принципов проектирования, реализации и анализа, MS Access является идеальным инструментом, позволяющим студенту полностью реализовать проект от А до Я. И что из этого следует? Это означает, что для образовательных и небольших прикладных задач Access предоставляет полный цикл разработки без избыточной сложности и затрат, что делает его отличной стартовой площадкой для будущих специалистов.

Проектная часть: Проектирование информационной системы

Функциональные и нефункциональные требования к системе

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

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

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

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

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

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

Инфологическое и даталогическое проектирование базы данных

После определения требований начинается этап проектирования, который традиционно делится на инфологическое и даталогическое моделирование.

Инфологическое проектирование (или концептуальное моделирование) не зависит от конкретной СУБД и фокусируется на сущностях предметной области и связях между ними. Наиболее распространённым инструментом для этого является ER-диаграмма (Entity-Relationship Diagram – «сущность-связь»).

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

• Вагоны: Номер вагона, тип вагона, дата выпуска, завод-изготовитель.
• Неисправности: Уникальный идентификатор неисправности, код неисправности (из классификатора), описание, дата обнаружения, дата устранения, текущее состояние.
• Классификатор Неисправностей: Код неисправности (XYZ), укрупнённый узел (X), описание узла, порядковый номер (YZ), описание неисправности.
• Ремонты: Идентификатор ремонта, тип ремонта (плановый, текущий), дата начала, дата окончания, место проведения (депо), ответственный персонал.
• Персонал: Идентификатор сотрудника, ФИО, должность.
• Депо: Идентификатор депо, название, адрес.

Связи между сущностями:

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

Даталогическое проектирование (или логическое моделирование) преобразует инфологическую модель в структуру, понятную конкретной СУБД, в нашем случае — реляционную модель для MS Access. На этом этапе происходит перевод сущностей в таблицы, атрибутов — в поля таблиц, а связей — в отношения между таблицами с использованием первичных и внешних ключей. Ключевым шагом является нормализация таблиц до 3-й нормальной формы (3НФ), что позволяет устранить избыточность данных, предотвратить аномалии обновления, вставки и удаления.

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

Разработка структуры таблиц в MS Access

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

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

• Имя поля: Уникальное название столбца.
• Тип данных: Определяет тип информации, которую будет хранить поле (например, «Текстовый», «Числовой», «Дата/время», «Счётчик»).
• Описание: Пояснение назначения поля.
• Свойства поля: Дополнительные параметры, такие как размер поля, формат, значение по умолчанию, обязательность заполнения, индексирование.

Примеры таблиц и их полей:

1. Таблица «Вагоны»
   • КодВагона (Числовой, Длинное целое, Первичный ключ, Индексированное: Да (без совпадений)) – Уникальный номер вагона.
   • ТипВагона (Текстовый, 50) – Например, «Крытый», «Полувагон».
   • ДатаВыпуска (Дата/время)
   • ЗаводИзготовитель (Текстовый, 100)
   • Статус (Текстовый, 20) – Например, «В эксплуатации», «Списан».
2. Таблица «КлассификаторНеисправностей»
   • КодНеисправности (Текстовый, 3, Первичный ключ, Индексированное: Да (без совпадений)) – Код XYZ.
   • УзелВагона (Числовой, Целое) – Первая цифра кода X.
   • ОписаниеУзла (Текстовый, 100)
   • ПорядковыйНомер (Числовой, Целое) – Две последние цифры кода YZ.
   • ОписаниеНеисправности (Текстовый, 255) – Детальное описание.
   • Критичность (Текстовый, 20) – Например, «Высокая», «Средняя», «Низкая».
3. Таблица «Неисправности»
   • КодЗаписи (Счётчик, Первичный ключ) – Автоматически генерируемый уникальный идентификатор записи.
   • КодВагона (Числовой, Длинное целое, Внешний ключ) – Ссылка на таблицу «Вагоны».
   • КодНеисправности (Текстовый, 3, Внешний ключ) – Ссылка на таблицу «КлассификаторНеисправностей«.
   • ДатаОбнаружения (Дата/время, Обязательное поле)
   • МестоОбнаружения (Текстовый, 100)
   • ДатаУстранения (Дата/время)
   • Состояние (Текстовый, 50) – Например, «Обнаружена», «В ремонте», «Устранена».
   • Комментарий (Поле МЕМО)
4. Таблица «Ремонты»
   • КодРемонта (Счётчик, Первичный ключ)
   • КодЗаписиНеисправности (Числовой, Длинное целое, Внешний ключ) – Ссылка на таблицу «Неисправности».
   • ТипРемонта (Текстовый, 50) – Например, «Плановый», «Текущий».
   • ДатаНачалаРемонта (Дата/время)
   • ДатаОкончанияРемонта (Дата/время)
   • КодДепо (Числовой, Целое, Внешний ключ) – Ссылка на таблицу «Депо».
   • КодМастера (Числовой, Целое, Внешний ключ) – Ссылка на таблицу «Персонал».
   • СтоимостьРемонта (Денежный)

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

Обеспечение целостности данных

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

Для обеспечения целостности данных в MS Access необходимо выполнить следующие условия:

1. Ключевые поля: Связанное поле главной таблицы должно быть первичным ключом или иметь уникальный индекс. Это гарантирует, что каждая запись в главной таблице будет однозначно идентифицирована.
2. Совместимость типов данных: Связанные поля в главной и подчинённой таблицах должны иметь один тип данных. Исключением является поле типа «Счётчик», которое может быть связано с числовым полем типа «Длинное целое» или с другим полем типа «Код репликации».
3. Единство базы данных: Обе таблицы должны принадлежать одной базе данных Microsoft Access.

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

• Запрет на ввод несуществующих внешних ключей: Нельзя ввести в поле внешнего ключа связанной (подчинённой) таблицы значение, которое отсутствует в ключевом поле главной таблицы. Это предотвращает создание «сиротских» записей. (Допускается ввод Null для несвязанных записей, если поле внешнего ключа не является обязательным).
• Запрет на удаление связанных записей: Нельзя удалить запись из главной таблицы, если существуют связанные с ней записи в подчинённой таблице. Например, нельзя удалить запись о вагоне, если в таблице «Неисправности» существуют записи о его поломках.
• Запрет на изменение первичного ключа: Нельзя изменить значение первичного ключа в главной таблице, если существуют связанные с данной записью записи в подчинённой таблице.

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

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

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

Реализация информационной системы в MS Access

Создание пользовательского интерфейса: Формы и навигация

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

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

• Формы для ввода данных: Разработка форм для каждой основной сущности (например, «Ввод Вагона», «Регистрация Неисправности», «Учёт Ремонта»). Эти формы будут содержать поля для ввода информации, выпадающие списки (на основе данных из справочных таблиц, например, для выбора типа неисправности из «КлассификатораНеисправностей» или депо из таблицы «Депо»), кнопки для сохранения, удаления или перехода к следующей записи.
• Подчинённые формы: Для отображения связанных данных (например, список всех неисправностей для конкретного вагона) используются подчинённые формы, встроенные в главную форму. Это позволяет пользователю видеть всю необходимую информацию в одном окне.
• Элементы управления: Для повышения удобства будут использованы различные элементы управления: текстовые поля, кнопки, списки, переключатели, флажки. При добавлении новых объектов, таких как формы и отчёты, Microsoft Access 2010 может автоматически применять заданную тему Office для форматирования, обеспечивая единообразие дизайна.

Навигация по системе:
Для упрощения навигации и повышения доступности часто используемых форм и отчётов в MS Access можно создавать специальные формы навигации без написания кода. Главным элементом пользовательского интерфейса Microsoft Access является «Лента», на которой команды сгруппированы по тематическим вкладкам («Главная», «Создание», «Внешние данные» и «Работа с базами данных»). Форма навигации будет представлять собой главное окно, где в виде вкладок или кнопок будут представлены ссылки на ключевые формы и отчёты системы, например:

• «Ввод Вагонов»
• «Регистрация Неисправностей»
• «Журнал Ремонтов»
• «Отчёты по Неисправностям»
• «Справочники»

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

Разработка запросов для анализа данных

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

Для системы анализа неисправностей вагонов будут разработаны различные типы запросов:

1. Запросы на выборку (SELECT-запросы):
   • Поиск неисправностей по номеру вагона: Запрос, который выводит все зарегистрированные неисправности для конкретного вагона, включая детали о типе неисправности, датах обнаружения и устранения, а также информацию о проведённых ремонтах.
   • Список вагонов с критическими неисправностями: Запрос, который фильтрует вагоны по уровню критичности неисправности, основываясь на данных из «КлассификатораНеисправностей«.
   • Статистика неисправностей по узлам: Запрос, группирующий данные по полю «УзелВагона» из таблицы «КлассификаторНеисправностей» и подсчитывающий количество неисправностей для каждого узла. Это позволит выявить наиболее проблемные агрегаты.
   • Вагоны, находящиеся в ремонте: Запрос, отображающий все вагоны, у которых Состояние в таблице «Неисправности» равно «В ремонте».
   • Динамика неисправностей за период: Запрос, позволяющий отслеживать количество неисправностей за определённый временной интервал (месяц, квартал, год) с группировкой по типу неисправности или узлу.
2. Запросы на изменение данных:
   • Запросы на обновление (UPDATE-запросы): Например, для массового изменения статуса неисправности с «В ремонте» на «Устранена» для группы вагонов после завершения ремонтных работ.
   • Запросы на добавление (APPEND-запросы): Могут использоваться для импорта данных из внешних источников или для архивирования старых записей в отдельную таблицу.
   • Запросы на удаление (DELETE-запросы): Применяются для удаления устаревших или ошибочных данных, но с большой осторожностью и только после резервного копирования.
3. Перекрёстные запросы (CROSSTAB-запросы): Позволяют представить данные в виде сводной таблицы, что удобно для статистического анализа. Например, для отображения количества неисправностей каждого типа по месяцам.

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

Создание отчётов

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

Для системы анализа неисправностей вагонов будут разработаны следующие типы отчётов:

• Список неисправностей за период: Отчёт, выводящий все зарегистрированные неисправности за выбранный диапазон дат, с сортировкой по номеру вагона, типу неисправности или дате. Отчёт будет включать детальную информацию о каждой неисправности и связанном ремонте.
• Статистика неисправностей по узлам: Графический отчёт, возможно, с использованием встроенных в Access средств для построения диаграмм, отображающий распределение неисправностей по основным узлам вагона (колёсные пары, тележки, автосцепка и т.д.). Это позволит быстро оценить наиболее уязвимые места.
• Динамика отказов: Отчёт, представляющий тенденции изменения количества неисправностей с течением времени. Это может быть линейный график, показывающий число поломок в месяц/квартал.
• Отчёт по простоям вагонов в ремонте: Отчёт, подсчитывающий среднее время простоя вагона в ремонте для разных типов неисправностей или депо. Это позволит выявить узкие места в ремонтных процессах.
• Детальный отчёт по вагону: Отчёт, который по заданному номеру вагона выводит полную историю его неисправностей и ремонтов.

При разработке отчётов особое внимание будет уделено:

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

Отчёты могут быть экспортированы в различные форматы (PDF, Excel, Word) для дальнейшего использования и распространения.

Автоматизация процессов с использованием VBA

Для повышения функциональности, удобства использования и автоматизации рутинных операций в MS Access активно используется Visual Basic for Applications (VBA). VBA — это мощный объектно-ориентированный язык программирования, который позволяет расширить стандартные возможности Access, создавая собственные процедуры и функции.

Основной ряд событий, обработка которых позволяет связывать различные объекты в задачах обработки данных, возникает при работе в форме. Например, код VBA может быть связан с кнопкой, полем ввода или событием открытия/закрытия формы.

Примеры использования VBA в системе анализа неисправностей вагонов:

1. Автоматическое заполнение полей:
   • При выборе кода неисправности из выпадающего списка в форме регистрации неисправности, VBA может автоматически заполнять поля «УзелВагона» и «ОписаниеУзла» из таблицы «КлассификаторНеисправностей«.
   • Автоматическая подстановка текущей даты при регистрации неисправности.
2. Валидация данных:
   • Расширенная проверка корректности ввода данных, которая выходит за рамки стандартных правил валидации Access. Например, проверка, что дата устранения неисправности не раньше даты её обнаружения, или что номер вагона соответствует определённому формату.
   • Вывод пользовательских сообщений об ошибках.
3. Управление формами и отчётами:
   • Открытие или закрытие форм на основе определённых условий.
   • Фильтрация данных в отчёте перед его открытием, например, по выбранному в форме критерию.
   • Вызов внешних процедур из библиотечных баз данных MS Access (.mda) или библиотек динамической компоновки (.dll) для выполнения специализированных задач.
4. Сложные расчёты:
   • Вычисление времени простоя вагона в ремонте на основе дат обнаружения и устранения неисправности.
   • Расчёт статистических показателей, которые не могут быть легко реализованы стандартными запросами.
5. Пользовательские функции:
   • Создание собственных функций для специфических нужд, которые затем могут быть использованы в запросах или отчётах.
6. Управление безопасностью:
   • Программное управление доступом к определённым формам или данным в зависимости от прав текущего пользователя.

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

Организационно-экономическое обоснование проекта

Расчёт трудоёмкости и стоимости создания системы

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

Этапы разработки и оценка трудозатрат:

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

1. Анализ требований и предметной области:
   • Изучение классификаторов неисправностей, консультации со специалистами.
   • Формулирование функциональных и нефункциональных требований.
   • Трудоёмкость: 80-120 человеко-часов.
2. Проектирование базы данных:
   • Разработка ER-диаграммы.
   • Нормализация таблиц.
   • Определение структуры таблиц (поля, типы данных, ключи).
   • Разработка схемы данных и обеспечение целостности.
   • Трудоёмкость: 100-150 человеко-часов.
3. Реализация базы данных в MS Access:
   • Создание таблиц.
   • Разработка форм для ввода/просмотра данных.
   • Создание запросов для анализа.
   • Разработка отчётов.
   • Программирование на VBA (автоматизация).
   • Трудоёмкость: 200-300 человеко-часов.
4. Тестирование и отладка:
   • Функциональное тестирование, тестирование производительности, юзабилити-тестирование.
   • Исправление ошибок.
   • Трудоёмкость: 60-90 человеко-часов.
5. Разработка документации:
   • Создание технического задания (ТЗ).
   • Разработка инструкции пользователя.
   • Разработка технической документации (пояснительная записка, описание ПО).
   • Трудоёмкость: 80-120 человеко-часов.

Определение состава исполнителей и расчёт стоимости:

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

• Ведущий аналитик: 0,2 FTE (Full-Time Equivalent) на этапе анализа и проектирования.
• Разработчик БД (MS Access): 1.0 FTE на этапах проектирования и реализации.
• Тестировщик/Специалист по качеству: 0,1 FTE на этапе тестирования.
• Технический писатель: 0,1 FTE на этапе документирования.

Допустим, среднемесячная зарплата такого специалиста составляет 80 000 рублей.
С учётом налогов и отчислений (≈30%) это будет примерно 104 000 рублей в месяц или 650 рублей в час (при 160 рабочих часах в месяц).

Примерный расчёт стоимости:
Общая трудоёмкость: 520 — 780 человеко-часов.
Примем среднее значение 650 человеко-часов.

• Стоимость труда: 650 человеко-часов × 650 руб./человеко-час = 422 500 рублей.
• Накладные расходы (20%): 422 500 × 0,20 = 84 500 рублей. (Включают аренду рабочего места, амортизацию оборудования, административные расходы).
• Прочие расходы: Лицензия на MS Office (если не имеется), обучение (не применимо для студента). Для реального проекта — 0 руб. (так как MS Access обычно уже есть).
• Общая ориентировочная стоимость создания: 422 500 + 84 500 = 507 000 рублей.

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

Анализ экономической эффективности

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

Исходные данные для расчёта (гипотетические):

• Ежегодные потери от неавтоматизированного анализа неисправностей:
  • Простой вагонов из-за задержек в учёте и принятии решений: 50 вагоно-дней в год.
  • Средняя стоимость 1 вагоно-дня простоя: 3 000 руб.
  • Потери от простоя: 50 × 3000 = 150 000 руб./год.
  • Трудозатраты персонала на ручной сбор и обработку данных: 160 человеко-часов/год × 650 руб./час = 104 000 руб./год.
  • Ошибки в учёте, приводящие к некорректным ремонтам или штрафам: 30 000 руб./год.
  • Общие годовые потери до внедрения ИС: 150 000 + 104 000 + 30 000 = 284 000 руб./год.
• Эксплуатационные расходы новой ИС:
  • Поддержка и обслуживание (администратор БД): 0,1 FTE × 104 000 руб./мес. × 12 мес. = 124 800 руб./год (для малого депо может быть значительно меньше).
  • Допустим 50 000 руб./год на поддержку и мелкие доработки.
• Стоимость создания ИС (из предыдущего пункта): 507 000 рублей.

Расчёт показателей экономической эффективности:

1. Годовой экономический эффект (ГЭЭ):
   • ГЭЭ = (Годовые потери до внедрения ИС) — (Эксплуатационные расходы новой ИС)
   • ГЭЭ = 284 000 руб./год — 50 000 руб./год = 234 000 руб./год.
2. Срок окупаемости (Т_ок):
   • Т_ок = (Стоимость создания ИС) / (Годовой экономический эффект)
   • Т_ок = 507 000 руб. / 234 000 руб./год ≈ 2,17 года.
   • Вывод: Система окупится примерно за 2 года и 2 месяца, что является хорошим показателем для IT-проекта.
3. Чистый дисконтированный доход (NPV) и Индекс прибыльности (PI):
   • Для более точной оценки, особенно при долгосрочных проектах, используется дисконтирование. Предположим, что ставка дисконтирования (E) составляет 10% в год.
   • Формула NPV: NPV = ∑_t=1ⁿ (П_t / (1 + E)^t) — ИК
     • Где П_t — денежный поток за год t (в нашем случае, годовой экономический эффект), E — ставка дисконтирования, n — горизонт планирования (например, 5 лет), ИК — начальные инвестиции (стоимость создания ИС).

Год	Годовой эффект (Пt)	Коэффициент дисконтирования (1 + E)t	Дисконтированный эффект
1	234 000	(1 + 0,10)1 = 1,10	212 727
2	234 000	(1 + 0,10)2 = 1,21	193 388
3	234 000	(1 + 0,10)3 = 1,331	175 793
4	234 000	(1 + 0,10)4 = 1,464	160 095
5	234 000	(1 + 0,10)5 = 1,611	145 251
Сумма дисконтированных эффектов			887 254

• NPV = 887 254 — 507 000 = 380 254 рублей.
• Положительное значение NPV означает, что проект является экономически выгодным.

• Формула PI: PI = (Сумма дисконтированных эффектов) / (Начальные инвестиции)
• PI = 887 254 / 507 000 ≈ 1,75.
• Значение PI > 1 подтверждает экономическую привлекательность проекта.

Оценка упущенной выгоды

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

Источники упущенной выгоды без ИС:

1. Увеличение времени простоя вагонов: Без централизованного учёта и анализа, процесс выявления неисправностей, принятия решения о ремонте и контроля его выполнения замедляется. Каждый лишний час простоя вагона из-за организационных задержек — это потерянная прибыль от грузоперевозок.
   • Пример: Если система позволяет сократить среднее время простоя на 10%, это может сэкономить 15 000 руб./год (10% от 150 000 руб.).
2. Неоптимальное планирование ремонтов: Отсутствие точной статистики по типам и частоте неисправностей не позволяет эффективно планировать поставки запчастей, загрузку ремонтных бригад и график плановых ремонтов. Это ведёт к излишкам или дефициту запчастей, сверхурочной работе или простоям персонала.
   • Пример: Оптимизация закупок запчастей за счёт анализа статистики может принести экономию в 20 000 руб./год.
3. Снижение надёжности вагонного парка: Без глубокого анализа причин неисправностей трудно выявлять системные проблемы и принимать меры по повышению надёжности вагонов. Это может приводить к повторным поломкам, увеличению аварийности и, как следствие, репутационным потерям и штрафам.
   • Пример: Снижение повторных неисправностей на 5% может сократить дополнительные расходы на 10 000 руб./год.
4. Низкая эффективность использования персонала: Ручной сбор и обработка данных отнимает значительное время у квалифицированных специалистов, которые могли бы заниматься более продуктивной деятельностью, например, непосредственным ремонтом или контролем качества.
   • Пример: Высвобождение 10% рабочего времени сотрудников, занятых ручным учётом, может привести к экономии 10 400 руб./год (10% от 104 000 руб.).

Итоговая оценка упущенной выгоды:
Общая сумма упущенной выгоды, которую можно было бы избежать при внедрении ИС, может составлять, по гипотетическим оценкам, от 50 000 до 100 000 рублей в год, что является значимым фактором при оценке общей экономической целесообразности проекта.
Таким образом, внедрение системы анализа неисправностей вагонов не только окупает себя в относительно короткие сроки, но и приносит существенную дополнительную экономическую выгоду за счёт предотвращения потерь. Разве не удивительно, как небольшая инвестиция в автоматизацию может оказать такое значительное влияние на общую финансовую стабильность и эффективность предприятия?

Влияние «зелёного IT» на экономическую выгоду

В условиях обостряющегося внимания к экологическим проблемам, концепция «зелёного IT» (Green IT) становится не просто данью моде, но и важным фактором экономической стратегии. Внедрение IT-оптимизаций, направленных на экологичность, может привести к прямой экономии за счёт снижения потребностей в вычислительной мощности и, как следствие, операционных расходов. Этот аспект также должен быть учтён в экономическом обосновании проекта.

Как «зелёное IT» влияет на экономическую выгоду в контексте проекта:

1. Снижение энергопотребления:
   • Оптимизация кода и архитектуры базы данных в MS Access, хотя и не столь масштабна, как оптимизация серверных ЦОД, всё же способствует более эффективному использованию ресурсов компьютера пользователя. Чем быстрее и эффективнее работает система, тем меньше энергии требуется для её функционирования.
   • Пример: По оценкам экспертов, 30–40% ресурсов в ЦОД не используются. Применение облачных технологий позволяет использовать общие ресурсы с более высокой эффективностью, что сокращает энергетические затраты на 30–90% по сравнению с локальными серверами. Хотя MS Access является локальной СУБД, принципы оптимизации производительности применимы и здесь, снижая нагрузку на оборудование.
   • Прямая экономия на электроэнергии, если система используется на значительном количестве рабочих мест.
2. Продление срока службы оборудования:
   • Эффективно работающее программное обеспечение снижает нагрузку на аппаратное обеспечение, что может продлить срок службы компьютеров. Меньшая потребность в замене оборудования означает экономию на капитальных затратах и снижение количества электронных отходов.
3. Оптимизация бизнес-процессов:
   • Внедрение ИС само по себе является «зелёной» инициативой, так как позволяет сократить использование бумажных документов, минимизировать перемещения персонала для обмена информацией и повысить общую эффективность, что косвенно снижает углеродный след предприятия.
   • Пример: Электронный учёт неисправностей вместо бумажных журналов сокращает расходы на бумагу, печать и хранение архивов.
4. Повышение имиджа предприятия:
   • Предприятия, которые демонстрируют приверженность принципам устойчивого развития и «зелёного IT», улучшают свой корпоративный имидж. Это может привлечь экологически ориентированных клиентов и партнёров, а также улучшить отношения с регуляторами и общественностью. Хотя это не прямая экономическая выгода, она имеет долгосрочное стратегическое значение.
5. Соответствие нормативным требованиям:
   • В перспективе, ужесточение экологического законодательства может сделать «зелёные» практики обязательными. Внедрение таких решений сегодня позволяет предприятию быть готовым к будущим изменениям и избежать потенциальных штрафов.

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

Безопасность и сопутствующие аспекты проекта

Информационная безопасность базы данных

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

Microsoft Access, будучи локальной СУБД, предоставляет ряд традиционных способов защиты:

1. Установка пароля на базу данных: Это самый простой способ защиты. При установке пароля база данных может быть открыта только после ввода корректного пароля. Это предотвращает несанкционированный доступ к файлу .accdb (или .mdb).
2. Защита на уровне определения прав пользователей: Более сложный механизм, позволяющий ограничивать возможность получения или изменения информации для конкретного пользователя. В Access это реализуется через рабочие группы, где каждому пользователю или группе назначаются определённые разрешения (например, просмотр, редактирование, удаление, создание объектов).
3. Сохранение базы данных как файла MDE/ACCDE: Для предотвращения изменений структуры форм, отчётов и модулей (включая VBA-код) можно удалить изменяемую программу Visual Basic из базы данных, сохранив её как файл MDE (для Access 2003 и ниже) или ACCDE (для Access 2007 и выше). В таком файле пользователи могут работать с данными и запускать код, но не могут изменять дизайн объектов или просматривать исходный код VBA.

Актуальные угрозы информационной безопасности баз данных:

Несмотря на встроенные средства защиты, базы данных, в том числе и Access, подвержены ряду угроз:

• Ошибки в настройке и недоработанные конфигурации: Неправильная настройка прав доступа, использование стандартных паролей, отсутствие аудита доступа могут быть использованы злоумышленниками.
• SQL-инъекции: Хотя Access не является серверной СУБД, уязвимости могут возникнуть, если система взаимодействует с веб-приложениями или если в VBA-коде запросы строятся без должной фильтрации пользовательского ввода. Это позволяет внедрять вредоносный SQL-код.
• Киберпреступные атаки: Фишинг, вредоносное ПО, направленное на кражу файлов базы данных или учётных данных.
• Неправомерная эксплуатация данных: Даже при наличии прав доступа, недобросовестные пользователи могут использовать конфиденциальную информацию не по назначению.

Меры по предотвращению угроз:

1. Комплексный подход к парольной защите: Использование сложных, уникальных паролей и регулярная их смена.
2. Гранулированное разграничение прав доступа: Предоставление пользователям только минимально необходимых прав для выполнения их функций.
3. Хранение таблиц на сервере: Наилучшим способом защиты данных в Access, особенно для многопользовательской среды, является хранение таблиц на более защищённом сервере, например, на компьютере с Windows SharePoint Services или в виде связанных таблиц с серверной СУБД (SQL Server). В этом случае Access используется только как «фронтенд» для пользовательского интерфейса, а данные хранятся и обрабатываются на более мощном и защищённом сервере.
4. Регулярное резервное копирование: Создание регулярных резервных копий базы данных для возможности восстановления в случае сбоев или атак.
5. Обновление программного обеспечения: Своевременное обновление MS Access и операционной системы для устранения известных уязвимостей.
6. Обучение пользователей: Информирование пользователей о правилах информационной безопасности, угрозах и способах их предотвращения.

Охрана труда и безопасность жизнедеятельности

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

Требования к организации рабочего места (согласно СанПиН 2.2.2/2.4.1340-03):

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

Меры электробезопасности:

1. Проверка оборудования: Перед началом работы необходимо убедиться внешним осмотром в отсутствии посторонних предметов и в исправности всего оборудования, включая электрические разъёмы, шнуры и розетки.
2. Запреты: Категорически запрещается эксплуатировать неисправное оборудование (ПЭВМ, сканеры, принтеры и т.п., осветительные приборы), открывать защитные кожухи, прикасаться к токоведущим деталям и допускать попадание на них влаги.
3. Заземление: Розетки и вилки для подключения устройств должны иметь третью клемму защитного заземления.

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

Экологичность проекта

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

Экологические последствия IT-индустрии:

1. Углеродный след и энергопотребление: Информационные технологии могут оказывать значительное экологическое воздействие, связанное с производством оборудования, его использованием и утилизацией. Например, выбросы углекислого газа, связанные с работой дата-центров, составляют примерно 0,3% от мировых выбросов. Энергопотребление оборудования является основным источником углеродного следа IT-индустрии. Хотя локальная база данных на MS Access не имеет такого масштаба, как крупный дата-центр, принципы энергоэффективности остаются актуальными.
2. Электронные отходы (e-waste): Производство компьютеров и другой электроники требует значительных ресурсов и энергии. Утилизация устаревшего оборудования создаёт проблему электронных отходов, содержащих токсичные вещества.

Подходы к повышению экологичности проекта:

1. Оптимизация процесса разработки ПО:
   • Эффективный код: Разработка лёгкого, производительного и оптимизированного кода VBA и запросов в MS Access, который требует меньше вычислительных ресурсов. Менее «тяжёлая» программа потребляет меньше энергии при работе.
   • Минимализм в дизайне: Избегание излишних графических элементов и анимаций, которые могут нагружать процессор и видеокарту пользователя.
   • Тестирование и отладка: Качественное тестирование позволяет выявить и устранить неэффективные алгоритмы, снижая энергопотребление системы в процессе эксплуатации.
2. Повышение экологичности эксплуатации ИС:
   • Продление срока службы оборудования: Как уже упоминалось, эффективное ПО снижает нагрузку на аппаратное обеспечение, что способствует продлению срока службы компьютеров, уменьшая потребность в частой замене и, как следствие, объём электронных отходов.
   • Виртуализация и облачные технологии: Хотя MS Access — локальная СУБД, при развитии проекта в более масштабную систему, использование облачных служб может значительно повысить экологичность за счёт консолидации ресурсов и более эффективного использования оборудования ЦОД. Крупные ИТ-компании инвестируют в экологические проекты, переходят на возобновляемые источники энергии и внедряют инновационные решения для повышения энергоэффективности своих серверных центров. Многие крупные ИТ-компании стремятся к углеродной нейтральности, например, переходя на 100% возобновляемые источники энергии для питания своих дата-центров и офисов, а также компенсируя исторические выбросы углерода.
   • Безбумажный документооборот: Внедрение системы учёта неисправностей в электронном виде позволяет значительно сократить потребление бумаги, чернил и энергии, связанных с печатью и хранением бумажных документов.

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

Тестирование и документация

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

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

Виды тестирования по знанию системы:

1. Тестирование «чёрного ящика» (Black Box Testing):
   • Фокусируется на функциональности системы без учёта внутренней структуры кода. Тестировщик работает с системой как с «чёрным ящиком», подавая входные данные и проверяя выходные результаты на соответствие требованиям.
   • Применимо для БД: Проверка корректности ввода данных через формы, правильности выполнения запросов и формирования отчётов. Например, ввели данные о неисправности, ожидаем, что они появились в таблице и корректно отображаются в отчёте.
2. Тестирование «белого ящика» (White Box Testing):
   • Предполагает знание внутренней структуры, кода и архитектуры системы. Цель — проверить внутреннюю логику, пути выполнения кода, условия и циклы.
   • Применимо для БД: Проверка логики VBA-модулей, корректности построения SQL-запросов, правильности индексов и связей между таблицами.
3. Тестирование «серого ящика» (Gray Box Testing):
   • Комбинация «чёрного» и «белого» ящиков. Тестировщик имеет частичное знание внутренней структуры, что позволяет ему более эффективно разрабатывать тестовые сценарии.
   • Применимо для БД: Например, зная логику работы запроса, можно проверить его производительность при разных объёмах данных.

Виды тестирования по целям:

1. Функциональное тестирование:
   • Подтверждает, что система выполняет все заявленные функции в соответствии с требованиями.
   • Применимо для БД: Проверка всех форм (ввод, редактирование), запросов (выборка, изменение), отчётов.
2. Тестирование производительности:
   • Оценивает скорость, отзывчивость и стабильность системы под определённой нагрузкой.
   • Применимо для БД: Проверка времени выполнения сложных запросов и генерации объёмных отчётов при заданном количестве записей в таблицах.
3. Нагрузочное тестирование:
   • Изучает поведение системы при нормальной и пиковой нагрузке (например, одновременная работа нескольких пользователей, если Access используется в сетевом режиме).
   • Применимо для БД: Оценка отклика базы данных при одновременном выполнении нескольких ресурсоёмких операций.
4. Стресс-тестирование:
   • Проверяет поведение системы в экстремальных условиях, превышающих ожидаемые рабочие параметры (например, максимальное количество записей, некорректные входные данные).
5. Тестирование стабильности:
   • Проверяет работоспособность системы в течение длительного периода времени при постоянной нагрузке.
6. Конфигурационное тестирование:
   • Проверяет работу системы в различных аппаратных и программных конфигурациях (разные версии ОС, Access).
7. Юзабилити-тестирование (Тестирование удобства использования):
   • Оценивает, насколько легко и удобно пользователям взаимодействовать с системой.
   • Применимо для БД: Проверка интуитивности интерфейса форм, ясности навигации, понятности сообщений об ошибках.
8. Тестирование интерфейса пользователя:
   • Проверяет все элементы пользовательского интерфейса (кнопки, поля, меню) на корректность отображения и функциональность.
9. Тестирование безопасности:
   • Выявление уязвимостей, позволяющих несанкционированный доступ, модификацию или удаление данных.
   • Применимо для БД: Проверка работы парольной защиты, разграничения прав доступа.
10. Тестирование совместимости:
    • Проверка работы системы с другими программами и компонентами (например, экспорт в Excel).

Стратегия и план тестирования:

Для разработанной БД будет определена следующая стратегия:

• Модульное тестирование: Проверка отдельных VBA-модулей и SQL-запросов.
• Интеграционное тестирование: Проверка взаимодействия между формами, запросами и отчётами.
• Системное тестирование: Комплексная проверка всей ИС на соответствие функциональным и нефункциональным требованиям.
• Приёмочное тестирование: Проведение тестирования конечным пользователем (имитация) для подтверждения соответствия системы ожиданиям.

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

Разработка инструкции пользователя

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

Содержание и структура инструкции пользователя:

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

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

Принципы создания эффективной инструкции:

• Наглядность: Использование скриншотов с пошаговыми действиями.
• Лаконичность: Избегание «воды» и излишних деталей.
• Актуальность: Инструкция должна соответствовать текущей версии системы.
• Тестирование: Проверка инструкции на понятность и полноту целевыми пользователями.

Техническая документация согласно ГОСТ

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

Комплекс стандартов ГОСТ 34 (Автоматизированные системы):

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

Основные стандарты ГОСТ 34, применимые к проекту:

1. ГОСТ 34.601-90 «Автоматизированные системы. Стадии создания»: Определяет общие стадии создания АС, такие как:
   • Формирование требований к АС.
   • Разработка концепции АС.
   • Техническое задание.
   • Эскизный проект.
   • Технический проект.
   • Рабочая документация.
   • Ввод в действие.
   • Сопровождение АС.
   • В контексте дипломной работы, эти стадии будут отражены в соответствующих разделах.
2. ГОСТ 34.602-89 «Информационная технология. Комплекс стандартов на автоматизированные системы. Техническое задание на создание автоматизированной системы»: Устанавливает состав, содержание и правила оформления документа «Техническое задание» (ТЗ). ТЗ является основным документом, определяющим требования к системе и порядок её создания.
   • Содержание ТЗ: Общие сведения, назначение и цели создания системы, характеристика объекта автоматизации, требования к системе (к функциям, к надёжности, к безопасности, к эргономике), состав и содержание работ по созданию системы, порядок контроля и приёмки, требования к составу и содержанию документации.
3. ГОСТ 34.201-2020 «Информационная технология. Комплекс стандартов на автоматизированные системы. Виды, комплектность и обозначение документов при создании автоматизированных систем»: Устанавливает перечень и обозначение документов, разрабатываемых на различных стадиях создания АС.
   • Примеры документов: Пояснительная записка, описание программного обеспечения, описание применения, формуляр, ведомость эксплуатационных документов.

Комплекс стандартов ГОСТ 19 (Единая система программной документации — ЕСПД):

ГОСТ 19, или ЕСПД, устанавливает правила для разработки, оформления и работы с программным обеспечением и его документацией. Он дополняет ГОСТ 34 в части, касающейся непосредственно программного обеспечения.

1. ГОСТ 19.101-77 «Единая система программной документации. Виды программ и программных документов»: Определяет виды программ (модуль, компонент, комплекс, система) и программных документов (техническое задание, описание программы, инструкция по применению, текст программы).

Применимость к дипломной работе:

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

• Пояснительная записка: Описывает проект в целом, его актуальность, цели, задачи, основные технические решения, этапы разработки, экономическое обоснование, аспекты безопасности и экологичности. Соответствует общим требованиям к дипломным работам, но при этом интегрирует положения ГОСТ 34.
• Описание программного обеспечения (согласно ГОСТ 19): Детально описывает структуру базы данных, логику работы форм, запросов, отчётов и VBA-модулей. Включает схемы, алгоритмы, пояснения к коду.
• Инструкция пользователя (см. выше): Разработана в соответствии с требованиями к эксплуатационной документации.

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

Заключение

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

В ходе работы были глубоко проанализированы теоретические основы систем управления базами данных, включая реляционную модель и принципы нормализации, что стало фундаментом для проектирования надёжной и целостной структуры. Детальное изучение специфического «Классификатора основных неисправностей грузовых вагонов» (К ЖА 2005 05) позволило интегрировать отраслевые стандарты непосредственно в ядро базы данных, обеспечив адекватное и точное отражение реальных процессов. Выбор MS Access как платформы был обоснован его доступностью, простотой освоения и достаточным функционалом для решения поставленных задач в рамках дипломного проекта.

На этапе проектирования были сформулированы исчерпывающие функциональные и нефункциональные требования, создана инфологическая и даталогическая модель, а также разработана детализированная структура таблиц с обеспечением целостности данных посредством связей и каскадных операций. Реализация системы в MS Access включала создание интуитивно понятного пользовательского интерфейса с формами для ввода данных и навигации, разработку мощных запросов для многофакторного анализа неисправностей, а также формирование информативных отчётов. Применение Visual Basic for Applications (VBA) позволило автоматизировать рутинные операции и расширить функциональность системы, значительно повысив её эффективность.

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

Не менее важными аспектами стали вопросы безопасности и охраны труда. Были предложены меры по обеспечению информационной безопасности базы данных в MS Access, включая анализ актуальных угроз. Детально рассмотрены требования по охране труда при работе с ПЭВМ, соответствующие СанПиН, что гарантирует создание безопасных и эргономичных условий для пользователей. Аспекты экологичности проекта были оценены как на стадии разработки, так и на этапе эксплуатации, подтверждая приверженность принципам устойчивого развития.

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

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

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

1. Шумаков, П. В. Руководство разработчика баз данных / П. В. Шумаков, В. В. Фаронов. – М.: Нолидж, 2000. – 635 с.
2. Карпова, Т. Базы данных: модели, разработка, реализация. – СПб.: Питер, 2001. – 304 с.
3. Хабракен, Д. Microsoft Access 2000. Шаг за шагом. – М.: АСТ, Астрель, 2004. – 350 с.
4. Тимошок, Т. В. Microsoft Access 2002. Самоучитель. – М.: Диалектика, 2004. – 352 с.
5. Степанов, В. Microsoft Access 2003 для начинающих. – СПб.: Аквариум-Принт, Дом печати – Вятка, 2006. – 128 с.
6. Microsoft Access 2003. Русская версия (+ CD-ROM). – М.: Эком, 2008. – 432 с.
7. Мак-Дональд, М. Access 2007. Недостающее руководство. – СПб.: Русская Редакция, БХВ-Петербург, 2007. – 784 с.
8. Сергеев, А. Access 2007. Новые возможности. – М.: Питер, 2008. – 176 с.
9. Глушаков, С. В. Microsoft Access 2007. Лучший самоучитель / С. В. Глушаков, А. С. Сурядный, М. И. Шумилов. – М.: АСТ, АСТ Москва, 2008. – 448 с.
10. Кошелев, В. Е. Access 2007. Эффективное использование. – СПб.: Бином-Пресс, 2009. – 590 с.
11. Кронан, Д. Microsoft Access 2007 / Д. Кронан, Б. Сандберг. – М.: НТ Пресс, 2009. – 384 с.
12. Сеннов, А. Access 2010. – М.: Питер, 2010. – 288 с.
13. Фуллер, Л. У. Access 2010 для чайников / Л. У. Фуллер, К. Кук. – СПб.: Вильямс, 2011. – 384 с.
14. ГОСТ 34.201-2020. Документы при создании автоматизированных систем.
15. Классификатор «Основные неисправности грузовых вагонов» (К ЖА 2005 05) (утвержден Комиссией Совета по железнодорожному транспорту полномочных специалистов вагонного хозяйства железнодорожных администраций, протокол заседания от 23-25 марта 2004 года № 33) (с изменениями от 21.09.2005 г.).
16. «Классификатор коммерческих неисправностей грузовых вагонов» (утв. Распоряжением ОАО «РЖД» от 13.03.2020 N 551/р).
17. Обеспечение безопасности при эксплуатации компьютерной техники. URL: [дата обращения: 26.10.2025].
18. Обеспечение целостности данных. URL: [дата обращения: 26.10.2025].
19. Работа с СУБД MS ACCESS. URL: [дата обращения: 26.10.2025].
20. Безопасная эксплуатация вагонов при наличии неисправностей. Текст научной статьи по специальности «Строительство и архитектура». URL: [дата обращения: 26.10.2025].
21. Экологично ли ваше ПО? URL: [дата обращения: 26.10.2025].
22. Экологичность ИТ-гигантов: как заботятся (и заботятся ли) об экологии Google, Microsoft и Apple. URL: [дата обращения: 26.10.2025].
23. Документация для информационных систем по ГОСТ. URL: [дата обращения: 26.10.2025].
24. Разработка документации на автоматизированные системы. URL: [дата обращения: 26.10.2025].
25. Разработка по ГОСТ 19: Стандарты документации в ИТ. URL: [дата обращения: 26.10.2025].
26. Разработка проектов. URL: [дата обращения: 26.10.2025].
27. Руководство по пользовательскому интерфейсу Access. URL: [дата обращения: 26.10.2025].
28. Microsoft Access 2010 Руководство по продукту. URL: [дата обращения: 26.10.2025].
29. Access 2010 в примерах Учебное пособие. URL: [дата обращения: 26.10.2025].
30. Как пользоваться Microsoft Access (с иллюстрациями). URL: [дата обращения: 26.10.2025].
31. Тест по программе Microsoft Access: методические материалы на Инфоурок. URL: [дата обращения: 26.10.2025].
32. Тест по информатике на тему «MS Access»: методические материалы на Инфоурок. URL: [дата обращения: 26.10.2025].
33. Тесты по теме «Microsoft Access» онлайн. URL: [дата обращения: 26.10.2025].
34. Какие виды и методы существуют для тестирования базы данных Access? URL: [дата обращения: 26.10.2025].
35. Памятка по ГОСТ 34 — Разработка технической документации. URL: [дата обращения: 26.10.2025].
36. Функциональные и нефункциональные требования: ключевые различия. URL: [дата обращения: 26.10.2025].
37. Функциональные и нефункциональные требования к ПО: что важно знать. URL: [дата обращения: 26.10.2025].
38. Функциональные и нефункциональные требования — что это, как разработать, примеры требований. URL: [дата обращения: 26.10.2025].