Повышение качества программных продуктов за счёт использования средств автоматизации

Коротко: как применить эту тему в ВКР

Интеграция средств автоматизации (CI/CD, модульное тестирование, статический анализ) в выпускную квалификационную работу позволяет перевести её из разряда «теоретических» в «практически значимые». Комиссия высоко оценивает наличие измеримых метрик: снижение времени регрессионного тестирования на 40%, увеличение покрытия кода (code coverage) до 80% и уменьшение количества дефектов на этапе продакшена. Используйте стандарты ГОСТ Р ИСО/МЭК 25010-2015 для обоснования выбора метрик качества.

1. С чем сталкиваются студенты: реальные проблемы защиты

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

Качество ПО — это не субъективное ощущение, а набор измеримых характеристик. Без внедрения инструментов автоматизации (например, автотестов или анализаторов кода) доказать улучшение этих характеристик практически невозможно. Комиссия ждет цифр: сколько часов сэкономлено, насколько снизился технический долг. Именно автоматизация дает эти цифры.

2. Методологическая база: на какие ГОСТы опираться

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

• ГОСТ Р ИСО/МЭК 25010-2015 «Системная и программная инженерия. Требования и оценка качества систем и программных продуктов». Это ваша библия. Здесь описаны характеристики: функциональная пригодность, надежность, сопровождаемость, безопасность.
• ГОСТ 34.602-2020 «Техническое задание на создание автоматизированной системы». Используйте его для формулирования требований к подсистеме тестирования или контроля качества.
• ГОСТ Р 7.0.100-2018 «Библиографическая запись. Библиографическое описание». Обязателен для оформления списка литературы.

3. Архитектура решения: сравнение подходов

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

Совет: Для ВКР по информационной безопасности добавьте в таблицу критерий «Соответствие требованиям ФСТЭК по контролю целостности кода».

4. Пошаговая реализация: пример для проектной главы

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

Пример: Фрагмент конфигурации GitHub Actions для автоматического запуска тестов и проверки качества (файл .github/workflows/quality.yml)

name: Quality Assurance Pipeline

on: [push, pull_request]

jobs:
  test-and-analyze:
    runs-on: ubuntu-latest
    steps:
      - name: Checkout code
        uses: actions/checkout@v3
      
      - name: Set up Python
        uses: actions/setup-python@v4
        with:
          python-version: '3.10'
          
      - name: Install dependencies
        run: pip install -r requirements.txt pytest pytest-cov
        
      - name: Run tests with coverage
        run: pytest --cov=app --cov-report=xml
        
      - name: SonarQube Scan
        uses: SonarSource/sonarqube-scan-action@master
        env:
          SONAR_TOKEN: ${{ secrets.SONAR_TOKEN }}

Как это описать в тексте: «Для обеспечения непрерывного контроля качества был настроен CI/CD пайплайн. На этапе Run tests with coverage выполняется оценка покрытия кода тестами. Если метрика падает ниже порогового значения 80%, сборка помечается как failed, что предотвращает попадание некачественного кода в основную ветку (согласно требованию надежности из ГОСТ Р ИСО/МЭК 25010-2015)».

5. Типичные ошибки и как их избежать

6. Чек-лист перед сдачей нормоконтролеру

Рекомендуемая структура дипломной работы (для данной темы)

7. FAQ: ответы на вопросы из студенческих чатов

В: Обязательно ли писать свои автотесты, или можно использовать готовые фреймворки?

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

В: Как посчитать экономию, если в компании нет реальных данных о времени тестирования?

О: Используйте метод экспертных оценок. Опишите в тексте: «На основании интервью с ведущим разработчиком ООО "Х", время ручной проверки одного модуля составляет 2 часа». Это допустимый подход для ВКР, если он явно указан в тексте.

В: Какой процент покрытия кода (code coverage) указать в дипломе, чтобы не придрались?

О: Указывайте реалистичные цифры. 100% покрытие выглядит как подделка. Оптимальный и защищаемый диапазон для ВКР — 75–85%. Обязательно укажите, что покрытие измерялось для критически важных модулей системы.

Проверьте свою тему ВКР перед стартом

• □ Есть ли реальная организация (или ее детальная модель) для анализа процессов?
• □ Можно ли получить или смоделировать метрики «до» и «после» внедрения автоматизации?
• □ Позволяет ли тема построить наглядные диаграммы процессов (BPMN/IDEF0)?
• □ Есть ли доступ к документации на выбранные инструменты автоматизации для списка литературы?