Разработка автоматизированной системы контроля и учета для IT-отдела: Структура и содержание дипломной работы

Введение

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

Типичной проблемой, особенно для активно растущего бизнеса, становится отсутствие централизованной системы учета и контроля. На примере IT-отдела компании «Эльдорадо», где эксплуатируется более 50 автоматизированных рабочих мест (АРМ) и используется разнородное программное обеспечение, мы видим классическую картину: учет активов ведется разрозненно, отсутствует единая система для регистрации и отслеживания инцидентов (багтрекинга), а обработка запросов от пользователей не систематизирована. По мере развития интернет-магазина и роста числа клиентских обращений возникла острая необходимость в создании полноценной сервисной службы, способной эффективно обрабатывать жалобы, заявки и технические проблемы.

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

• Объектом исследования являются процессы контроля и учета в IT-отделе.
• Предметом исследования выступает процесс разработки и внедрения автоматизированной системы для их оптимизации.

Главная цель дипломной работы — повышение эффективности работы IT-отдела за счет разработки и внедрения комплексной автоматизированной системы контроля и учета. Для достижения этой цели были поставлены следующие задачи:

1. Провести детальный анализ предметной области, изучив современные подходы к управлению IT-инфраструктурой.
2. Сформулировать функциональные и нефункциональные требования к будущей системе на основе анализа проблем объекта автоматизации.
3. Спроектировать архитектуру системы, структуру базы данных и пользовательские интерфейсы.
4. Выполнить программную реализацию ключевых модулей системы в соответствии с проектом.
5. Провести комплексное тестирование разработанного продукта для подтверждения его работоспособности и соответствия требованиям.

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

Глава 1. Аналитический обзор предметной области и существующих решений

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

1.1. Современные концепции управления IT-инфраструктурой

В основе современного подхода к управлению IT лежат две ключевые концепции:

• IT Asset Management (ITAM) — управление IT-активами. Это практика, которая позволяет организации управлять всем жизненным циклом своих технологических активов (оборудование, ПО), оптимизируя их использование и снижая совокупную стоимость владения (TCO). Ключевые показатели эффективности (KPI) в этой области включают утилизацию лицензий, процент незадействованного оборудования и общую стоимость владения IT-активами.
• IT Service Management (ITSM) — управление IT-услугами. Это более широкий подход, который рассматривает IT как поставщика услуг для бизнеса. Центральным элементом здесь являются Соглашения об уровне обслуживания (SLA), которые формализуют обязательства IT-отдела перед бизнес-подразделениями (например, максимальное время решения инцидента).

1.2. Классификация и жизненный цикл ключевых IT-процессов

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

Жизненный цикл инцидента (любого события, прерывающего работу сервиса) обычно включает следующие этапы:

1. Идентификация и регистрация
2. Классификация и начальная поддержка
3. Приоритезация (на основе влияния на бизнес и срочности)
4. Диагностика и эскалация (при необходимости)
5. Решение и восстановление сервиса
6. Закрытие инцидента

Жизненный цикл дефекта (ошибки в программном обеспечении) несколько отличается:

1. Обнаружение и детальное описание (с шагами для воспроизведения)
2. Подтверждение и регистрация в багтрекинговой системе
3. Назначение ответственного разработчика
4. Исправление дефекта
5. Верификация исправления тестировщиком
6. Закрытие дефекта

1.3. Сравнительный анализ существующих программных продуктов

На рынке существует множество готовых систем для управления IT-процессами. Среди наиболее популярных можно выделить Jira, Redmine и ServiceNow. Каждая из них обладает мощным функционалом для управления задачами, инцидентами и проектами. Однако после анализа их возможностей в контексте нужд «Эльдорадо» был сделан вывод о нецелесообразности их внедрения по ряду причин:

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

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

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

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

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

2.1. Характеристика объекта автоматизации

Объектом автоматизации является IT-отдел компании «Эльдорадо». Как было отмечено, в его ведении находится более 50 АРМ, используется широкий спектр программного обеспечения. Текущие процессы имеют ряд «узких мест»:

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

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

2.2. Разработка требований к системе

На основе анализа проблем были сформулированы следующие требования.

Функциональные требования (что система должна делать):

1. Система должна предоставлять возможность для регистрации, учета и отслеживания всех IT-активов компании (оборудование и ПО).
2. Система должна реализовывать полный жизненный цикл управления инцидентами, от создания заявки до ее закрытия.
3. Система должна включать модуль багтрекинга для отслеживания дефектов в ПО.
4. Система должна поддерживать ролевую модель доступа (администратор, инженер, пользователь).
5. Система должна генерировать отчеты по ключевым метрикам (количество заявок, среднее время решения и т.д.).

Нефункциональные требования (как система должна работать):

1. Производительность: Время отклика на основные операции пользователя не должно превышать 2 секунд.
2. Надежность: Система должна быть доступна 99.5% времени.
3. Пользовательский интерфейс: Система должна иметь интуитивно понятный, современный и адаптивный веб-интерфейс.
4. Безопасность: Система должна быть защищена от базовых веб-уязвимостей.
5. Масштабируемость: Архитектура должна позволять наращивать функциональность и выдерживать рост нагрузки.

Четко определенные требования являются фундаментом для следующего, самого ответственного этапа — технического проектирования системы.

Глава 3. Проектирование архитектуры и компонентов системы

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

3.1. Выбор и обоснование архитектуры

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

3.2. Обоснование выбора технологического стека

Для реализации каждого уровня архитектуры был выбран следующий технологический стек:

• Frontend (Клиентская часть): Библиотека React. Выбрана за ее компонентный подход, который ускоряет разработку сложных интерфейсов, а также за огромное сообщество и высокую производительность.
• Backend (Серверная часть): Язык Python и фреймворк Django. Этот выбор обусловлен высокой скоростью разработки, наличием готовых решений для аутентификации и администрирования («batteries included»), а также строгой структурой, способствующей написанию чистого и поддерживаемого кода.
• СУБД (База данных): PostgreSQL. Эта реляционная СУБД выбрана за ее надежность, соответствие стандартам SQL, поддержку сложных запросов и транзакций, что критически важно для системы учета.

3.3. Проектирование базы данных

Основой любой учетной системы является грамотно спроектированная база данных. Была разработана реляционная модель данных, а ее структура визуализирована с помощью ER-диаграммы (Entity-Relationship). Ключевыми сущностями в базе данных стали:

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

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

3.4. Проектирование пользовательского интерфейса

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

• Главная панель (Dashboard): Отображает сводную статистику по открытым заявкам и инцидентам.
• Таблица активов: Позволяет просматривать, фильтровать и искать IT-активы.
• Карточка актива: Содержит полную информацию о конкретном устройстве или лицензии.
• Форма создания инцидента/дефекта: Интуитивно понятная форма для быстрой регистрации новой заявки.

3.5. Моделирование системы с использованием UML

Для визуализации и формализации проектных решений использовался язык моделирования UML (Unified Modeling Language). Были построены следующие диаграммы:

• Диаграмма вариантов использования (Use Case Diagram): Описывает основные сценарии взаимодействия пользователей разных ролей с системой (например, «Пользователь создает инцидент», «Администратор добавляет новый актив»).
• Диаграмма классов: Отображает статическую структуру системы, ее основные классы и отношения между ними на уровне backend-кода.
• Диаграмма последовательности (Sequence Diagram): Демонстрирует динамику взаимодействия объектов во времени для ключевых сценариев, например, пошагово показывает, как система обрабатывает запрос на «Регистрацию нового инцидента».

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

Глава 4. Программная реализация ключевых модулей системы

Этот раздел демонстрирует переход от проектирования к созданию работающего программного продукта и включает примеры кода для иллюстрации ключевых моментов разработки.

4.1. Настройка среды разработки и создание структуры БД

Первым шагом было развертывание проекта. Были установлены все необходимые зависимости для Python/Django и React. Затем, на основе спроектированной ER-диаграммы, с помощью механизма миграций Django были автоматически созданы все необходимые таблицы в базе данных PostgreSQL. Этот подход обеспечивает версионирование структуры БД и упрощает развертывание на других машинах.

4.2. Реализация серверной части (API)

Серверная часть была реализована в виде RESTful API. Для каждой ключевой сущности (активы, инциденты, дефекты) были созданы эндпоинты, обрабатывающие стандартные CRUD-операции (Create, Read, Update, Delete). Была реализована бизнес-логика, описывающая жизненные циклы инцидентов и дефектов — например, изменение статуса заявки при назначении ответственного или ее закрытии. Особое внимание было уделено валидации данных и обработке прав доступа на уровне API.

4.3. Реализация клиентской части (пользовательского интерфейса)

На стороне клиента с использованием HTML, CSS и JavaScript (React) были созданы интерактивные UI-компоненты. Эти компоненты (таблицы, формы, дашборды) взаимодействуют с серверным API для получения, отображения и отправки данных. Например, при открытии страницы со списком активов, React-компонент отправляет GET-запрос на соответствующий эндпоинт API, получает данные в формате JSON и динамически отрисовывает таблицу без перезагрузки всей страницы.

4.4. Описание реализованных модулей

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

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

Разработанная система готова. Прежде чем говорить о ее внедрении, необходимо убедиться в ее качестве и корректности работы.

Глава 5. Тестирование и отладка разработанной системы

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

5.1. Разработка стратегии и плана тестирования

Была принята многоуровневая стратегия тестирования для обеспечения всесторонней проверки качества продукта. План включал следующие виды тестирования:

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

5.2. Проектирование тестовых сценариев (тест-кейсов)

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

Пример тест-кейса: «Создание и закрытие инцидента»

Шаги для выполнения	Ожидаемый результат	Фактический результат
1. Авторизоваться в системе под ролью «Пользователь». 2. Перейти в раздел «Инциденты» и нажать «Создать». 3. Заполнить все обязательные поля и сохранить форму.	Новый инцидент появляется в общем списке со статусом «Открыт». Инициатору приходит email-уведомление.	Совпадает с ожидаемым.
1. Авторизоваться под ролью «Инженер». 2. Назначить себя ответственным за созданный инцидент.	Статус инцидента меняется на «В работе».	Совпадает с ожидаемым.
1. Выполнить необходимые действия по инциденту. 2. Нажать «Закрыть инцидент» и добавить комме��тарий о решении.	Статус меняется на «Закрыт». Инцидент становится недоступным для редактирования.	Совпадает с ожидаемым.

5.3. Описание процесса и результатов тестирования

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

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

Раздел, посвященный вопросам безопасности системы

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

• Разграничение доступа на основе ролей (RBAC): В системе реализованы роли (администратор, инженер, менеджер), каждая из которых имеет строго определенный набор прав. Пользователь может выполнять только те действия, которые разрешены его роли.
• Защита от основных веб-уязвимостей: Приняты меры для предотвращения наиболее распространенных атак:
  • SQL-инъекции: Использование Django ORM гарантирует, что все запросы к базе данных параметризуются, что исключает возможность инъекции вредоносного SQL-кода.
  • Cross-Site Scripting (XSS): Все данные, выводимые в HTML-шаблоны, по умолчанию экранируются, что предотвращает выполнение вредоносных скриптов в браузере пользователя.
• Политика паролей и хранения учетных данных: Пароли пользователей не хранятся в открытом виде. Вместо этого в базе данных сохраняются их хешированные значения с использованием надежных криптографических алгоритмов, что делает невозможным их восстановление.

Система не только функциональна, но и защищена. Теперь оценим ее экономическую целесообразность.

Раздел, посвященный экономическому обоснованию проекта

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

Расчет затрат на разработку включает в себя:

• Трудозатраты разработчика, аналитика и тестировщика, рассчитанные на основе времени, потраченного на проект, и их ставок.
• Стоимость программного обеспечения (в данном случае минимальна, так как использовался Open Source стек).
• Затраты на оборудование для развертывания (стоимость аренды или покупки сервера).

Оценка ожидаемой выгоды складывается из нескольких факторов:

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

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

• Срок окупаемости (ROI — Return on Investment): Показывает, за какой период времени сэкономленные средства покроют затраты на разработку.
• Чистая приведенная стоимость (NPV — Net Present Value): Оценивает общую экономическую эффективность проекта с учетом стоимости денег во времени.

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

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

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

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

Руководство администратора

Это руководство предназначено для IT-специалистов, ответственных за развертывание и поддержку системы. Оно включает:

1. Системные требования: Описание необходимой конфигурации сервера (ОС, версия СУБД, Python и т.д.).
2. Инструкция по развертыванию: Пошаговый алгоритм установки приложения из исходного кода, включая настройку подключения к базе данных и запуск веб-сервера. Рассматривается возможность интеграции с системами непрерывной интеграции и доставки (CI/CD) для автоматизации этого процесса.
3. Основные настройки: Описание конфигурационных файлов и параметров системы, которые может понадобиться изменить (например, настройки почтового сервера для уведомлений).

Руководство пользователя

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

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

Все аспекты работы — от идеи до эксплуатации — рассмотрены. Осталось подвести итоги проделанной работы.

Заключение

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

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

• Проведен анализ предметной области и обоснована целесообразность собственной разработки.
• Сформулированы детальные функциональные и нефункциональные требования к системе.
• Спроектирована надежная трехуровневая архитектура, структура базы данных и пользовательские интерфейсы.
• Разработана и реализована программная система с использованием современного стека технологий (Python, Django, React, PostgreSQL).
• Система успешно прошла все этапы тестирования, подтвердив свою работоспособность и соответствие требованиям.
• Подготовлено экономическое обоснование и необходимая пользовательская документация.

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

В качестве возможных направлений для дальнейшего развития проекта можно выделить:

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

Список использованных источников

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

Приложения

В приложения выносятся объемные материалы, которые загромождали бы основной текст работы, но являются важным подтверждением проделанной работы.

• Приложение А: Листинги ключевых файлов исходного кода (например, модели Django, основные компоненты React, сложные участки бизнес-логики).
• Приложение Б: Полный набор разработанных UML и ER-диаграмм в крупном и читаемом масштабе.
• Приложение В: Полное, иллюстрированное скриншотами, руководство пользователя и руководство администратора.
• Приложение Г: Акт о внедрении или отчет об опытной эксплуатации системы (в случае, если система была внедрена на предприятии на момент защиты работы).