В данной статье я покажу, как внедрение этих методик «agile» помогает улучшить проект DO-178C за счет включения тестирования в мини-цикл разработки, сохраняя при этом его соответствие стандарту.
Сначала немного теории
Вкратце методика разработки через тестирование выглядит следующим образом: напишите тест, запустите его и убедитесь, что он дает отрицательный результат; затем напишите код, снова запустите тест и убедитесь, что он дает положительный результат (или скорректируйте код, если результат все еще отрицательный). Идея состоит в том, что нужно задать желательную для вас функциональность с помощью теста, а затем разработать код, который успешно проходит этот тест. На первый взгляд, методика TDD может показаться неприменимой к структуре проекта на основе стандарта DO-178C. Однако две небольшие корректировки совершенно меняют ситуацию: напишите основанный на требованиях тест и отдайте разработку кода и разработку теста двум разным людям. Таким образом, дух методики TDD может быть органично адаптирован к тяжеловесной методологии разработки.Непрерывная интеграция первоначально была методом частого внедрения рабочих копий программы в ее основную ветвь. Главной целью CI было решение проблем с интеграцией. В настоящее время этот метод рассматривается более широко. Обычно CI поддерживается автоматизированным процессом сборки и дополняется различными мероприятиями по обеспечению качества. Вместе с TDD непрерывная интеграция образует отличный фундамент для мониторинга состояния проекта и ощутимого роста качества. Моя статья «Оправдывает ли себя непрерывная интеграция? Уверен, что да» описывает метод CI более детально и проливает свет на его использование в проектах DO-178C.
От теории к практике
Типовые проекты DO-178 часто состоят из нескольких этапов. Эти этапы могут называться «выпуск», «сборка», «версия», «загрузка», «ярлык» и т. д. Продолжительность этапа обычно варьирует от двух до десяти месяцев или более. В свою очередь, работа на каждом этапе состоит из ряда запросов на изменение. После завершения работы по всем запросам на изменение происходит выпуск сборки и ее передача в группу по верификации на тестирование. После этого начинается работа над следующей сборкой параллельно с тестированием предыдущей.
Такой принцип работы по проекту часто приводит к тому, что дефект укореняется в жизненном цикле, внося турбулентность в ход работ и приводя к браку или лишним действиям. Также для таких проектов характерны неожиданности в последнюю минуту, незапланированные дополнительные этапы для устранения ошибок, отклонения от графика, срывы сроков и целый ворох известных, но не исправленных дефектов в поставляемом программном обеспечении.
Цель усовершенствования жизненного цикла проекта состоит в том, чтобы сократить распространение дефектов путем их выявления и исправления в ходе разработки соответствующей части кода.
Для этого необходимо внести корректировки в технологию и процесс. С технологической точки зрения, потребуются две вещи:
- средство для автоматизированной разработки и развертывания сборок;
- автоматизированные тестовые процедуры.
Хорошая базовая структура для тестовых запусков и визуализации результатов – желательное, но не обязательное условие. Эти два момента имеют существенное значение для успешной реализации методов TDD и CI. Никакое изменение процесса не принесет пользы, если последовательность тестов или сборки перегружена утомительными ручными операциями. Наладьте технологическую схему, прежде чем переходить к настройке процесса!
С точки зрения процесса глобальные модификации отсутствуют. Точно так же происходят «выпуски» и группировка работ по отдельным запросам на изменение. Доработке подвергается только процесс реализации запросов на изменение. Кроме того, в целях достижения согласованности и соответствия нужны еще несколько действий.
Во-первых, для каждого отдельного запроса на изменение необходимо реализовать следующие 7 этапов:
- Разработайте требования.
- Проведите проверку требований.
- Параллельно разрабатывайте код и тестовые примеры в соответствии с требованиями.
- Добавьте новый разработанный код и соответствующие тесты в конвейер сборки CI.
- Получите результаты тестов.
- Исправьте ошибки в коде и скорректируйте тесты (если нужно). Повторяйте шаги 3–6, пока не будет обеспечено необходимое покрытие требований и кода, а тестовые примеры не пройдут проверку с успешным результатом.
- Выполните оценку кода и тестов. Повторите шаги 3–6, если во время проверок будут найдены недостатки.
Этот 7-шаговый рецепт позволяет сделать то, к чему призывает название данного поста: переключиться с громоздкой, неуклюжей V-образной модели цикла на серию коротких и конкретных мини-V-образных циклов.
Во-вторых, не следует рассматривать результаты тестов, полученных в шаге 5, как результаты формальной верификации, требуемой стандартом DO-178C. Считайте эти операции частью цикла разработки, нацеленной на обеспечение высококачественного результата. Когда все запросы на изменения, запланированные для «выпуска», будут выполнены, перейдите к формальной процедуре выпуска и проведите запуск в стандартном режиме (он же «оценочный запуск»). На момент такого запуска у вас будут одобрены и проконтролированы все необходимые требования к коду, элементы кода и тесты. Это позволит обеспечить соответствие стандарту.
Запуск в стандартном режиме становится простым и предсказуемым процессом благодаря тому, что:
- проблемы были разрешены на этапе разработки;
- реализованный метод CI обеспечивает автоматическое развертывание процесса запуска.
Может показаться, что в этом случае работа добавляется или дублируется. Это действительно так, но этому есть обоснование. Измерьте издержки на такие «дополнительные» задачи и сравните их с общими затратами на незапланированный этап подчистки, отставание от графика или дефект, обнаруженный после поставки. Учтите также ощутимый рост качества продукта и положительное влияние на удовлетворенность заказчика. Разумнее будет потратить немного дополнительных усилий в определенный момент жизненного цикла, но сэкономить гораздо больше в долгосрочной перспективе. На практике рост общей эффективности проекта достигает 30 % после того, как такой гибкий переворот в стиле «agile» выполнен и ассимилирован.