Перфоманс Лаб

разработка ПО
29 августа, 2016

Адаптивная инфраструктура для контроля качества разработки

Время чтения: 10 мин.
29 августа, 2016

Зачем это нужно?

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

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

Говоря о коммерческих продуктах, стоит отметить, что одной из важнейших целей при их разработке является сокращение времени от появления идеи до выпуска продукта на рынок. В более общем случае – время до его представления конечному пользователю. Для этого необходим гибкий контроль на всех стадиях разработки.
На рынке существует определенное количество решений для комплексного управления процессом разработки программных продуктов, но они не позволяют построить цикл разработки по методологии Agile. Мы же будем рассматривать построение стека для контроля качества разработки из нескольких open-source продуктов. Это позволит гибко контролировать необходимую функциональность и даст возможность для экспериментов, затраты на которые будут включать только время и не будут включать лицензирование крупных продуктов.

Что такое контроль качества разработки?

Хорошо декомпозированные требования позволяют создать структурированное и целостное техническое задание. В свою очередь, хорошее техническое задание (при выборе подходящего стека) должно элегантно ложиться на выбранные технологии. Кроме того, полное техническое задание является хорошей основой для создания плана тестирования верхнего уровня, помогающего определить типы тестов и этапы, на которых они необходимы. На каждом из этапов неизбежно будет возникать множество вопросов, от результатов решения которых, будет зависеть конечное качество разрабатываемого ПО. В этом и заключается контроль качества разработки – в процессе принятия решений.

Что такое адаптивность контроля качества разработки?

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

Гибкая методология разработки

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

Инструментарий

В нашем примере, для отслеживания состояния хода разработки, мы будем использовать методологию «Quality Gates». Она позволяет разбить процедуру создания ПО на этапы, по достижению которых к продукту будет предъявлен ряд требований. Если требования выполняются – продукт переходит на следующий этап (или «ворота»). Главным критерием при дальнейшем подборе инструментов будет возможность программ собирать конкретные метрики, при помощи которых можно будет оценивать качество всего процесса.

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

Для осуществления планирования и учёта мы будем рассматривать трекер задач Redmine.  При должном подходе он позволяет:

  • Планировать задачи по времени.
  • Фиксировать ход выполнения задачи и трудозатраты.
  • Оценивать темп работы.
  • Выявлять характерные ошибки планирования.

В качестве инструментов сбора метрик рассмотрим несколько различных продуктов.

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

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

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

Testlink – инструмент составления тестового плана и фиксирования его прохождения на различных этапах разработки.

Взаимно проинтегрированный стек всех эти инструментов осуществляет сбор следующих метрик:
• скорость разработки;
• сходимость дефекта;
• качество кода;
• технический долг;
• recidivism rate для задачи/бага;
• качество сборки.

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

Чтобы узнать подробнее о наших услугах