Разработка системы диагностики для процесса разработка: разработка алгоритмов диагностики

1.1. Технико-экономическая характеристика предметной области и предприятия

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

Пример содержимого: АО «Алгоритмы диагностики» специализируется на создании программных решений для диагностики технологических процессов. Основной вид деятельности — разработка программного обеспечения. В компании трудится 45 человек, из них 28 — разработчики. Ежегодный объём разработок — более 12 проектов. Основная проблема — отсутствие единой системы диагностики, что приводит к задержкам в выявлении ошибок и увеличению трудозатрат.

Сложности:

• Получение достоверных данных о предприятии (часто студенты вынуждены их придумывать, что требует правдоподобия).
• Соблюдение баланса между техническими и экономическими аспектами.

Время выполнения: 8–10 часов.

1.2. Характеристика комплекса задач и обоснование необходимости автоматизации

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

Пример содержимого: Процесс разработка включает этапы: постановка задачи, проектирование, кодирование, тестирование, внедрение. На этапе тестирования отсутствует автоматическая диагностика, что приводит к ручному анализу логов и увеличению времени на исправление ошибок на 30%. Автоматизация позволит сократить трудозатраты и повысить качество ПО.

Сложности:

• Корректное описание бизнес-процесса без доступа к реальным данным.
• Обоснование необходимости автоматизации с точки зрения эффективности.

Время выполнения: 6–8 часов.

1.3. Анализ существующих разработок и выбор стратегии автоматизации

Проводится обзор аналогов: коммерческие и open-source системы диагностики (например, ELK Stack, Prometheus, Grafana). Оцениваются их функциональность, достоинства и недостатки. На основе анализа выбирается стратегия — полная разработка с нуля, модификация существующего решения или комбинированный подход.

Пример содержимого: Анализ показал, что существующие решения не адаптированы под специфику диагностики процесса разработка в условиях АО «Алгоритмы диагностики». Наиболее подходящим решением признано создание собственной системы на базе Python и интеграции с GitLab CI/CD.

Сложности:

• Необходимость глубокого понимания аналогов.
• Объективное сравнение и аргументированный выбор стратегии.

Время выполнения: 8–10 часов.

1.4. Обоснование проектных решений

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

Пример содержимого: Для реализации системы диагностики выбрана архитектура микросервисов. Основной язык — Python (библиотеки Pandas, Scikit-learn для анализа). База данных — PostgreSQL. Алгоритмы диагностики строятся на основе анализа логов и метрик производительности с применением методов машинного обучения.

Сложности:

• Техническая грамотность при описании архитектуры и технологий.
• Связь выбора решений с целями проекта.

Время выполнения: 6–8 часов.

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

Время выполнения: 4–6 часов.

2.1. Разработка проекта автоматизации

Описывается проектная модель системы: диаграммы прецедентов, последовательности, классов (UML). Формулируются требования к функциональности: сбор логов, анализ аномалий, визуализация результатов, уведомления.

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

Сложности:

• Построение корректных UML-диаграмм.
• Соответствие диаграмм описанию.

Время выполнения: 10–12 часов.

2.2. Информационное обеспечение задачи

Описывается структура базы данных: ER-модель, таблицы (логи, ошибки, пользователи, метрики). Приводятся примеры запросов и нормализация данных.

Пример содержимого: Таблица "Логи_разработки" содержит поля: ID, время, уровень_ошибки, сообщение, модуль. Нормализация до 3НФ исключает избыточность. Пример запроса: SELECT * FROM Логи_разработки WHERE уровень_ошибки = 'ERROR'.

Сложности:

• Построение логически корректной ER-модели.
• Понимание принципов нормализации.

Время выполнения: 8–10 часов.

2.3. Программное обеспечение задачи

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

Пример содержимого: Алгоритм диагностики анализирует частоту ошибок за последний час. Если количество превышает порог (например, 10 за 5 минут), система формирует уведомление. Реализация на Python с использованием библиотеки logging и модуля анализа.

Сложности:

• Написание понятного и грамотного описания алгоритмов.
• Связь кода с теоретической частью.

Время выполнения: 10–12 часов.

2.4. Контрольный пример реализации проекта и его описание

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

Пример содержимого: В ходе теста в систему загружены логи с 15 ошибками за 4 минуты. Система корректно распознала аномалию, сгенерировала уведомление и вывела отчёт с графиком частоты ошибок.

Сложности:

• Описание примера без реальной реализации (часто приходится моделировать).
• Детализация сценария.

Время выполнения: 6–8 часов.

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

Время выполнения: 4–6 часов.

3.1. Выбор и обоснование методики расчёта экономической эффективности

Обосновывается выбор методики: например, расчёт годового экономического эффекта, срок окупаемости, NPV. Указываются источники методик (например, учебники по экономике ИТ).

Пример содержимого: Для оценки эффективности выбрана методика расчёта годового экономического эффекта по формуле: Э = (З₁ - З₂) - Ен × (К₂ - К₁), где З — затраты, К — капитальные вложения, Ен — нормативный коэффициент эффективности.

Сложности:

• Правильный выбор и обоснование методики.
• Соответствие методики требованиям Синергии.

Время выполнения: 6–8 часов.

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

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

Пример содержимого: До внедрения система тестирования занимала 20 часов в неделю. После — 8 часов. Экономия времени — 12 часов × 40 недель = 480 часов в год. При стоимости часа труда 800 руб. — экономия 384 000 руб. Годовые затраты на систему — 120 000 руб. Годовой экономический эффект — 264 000 руб. Срок окупаемости — 5 месяцев.

Сложности:

• Аргументация исходных данных.
• Математическая корректность расчётов.

Время выполнения: 8–10 часов.

Выводы по главе 3
Расчёты показали, что внедрение системы диагностики экономически целесообразно. Годовой экономический эффект составляет 264 000 руб., срок окупаемости — менее полугода.

Время выполнения: 4–6 часов.