В этой статье говорится об использовании методов гибкой разработки, непрерывной интеграции (CI) и разработки через тестирование (TDD) в проектах по созданию встроенного программного обеспечения. Применяемые в рамках архитектурного подхода, эти комбинированные методы обеспечивают высокое качество и гибкость разработки.
Вот уже более десятилетия группы по разработке программного обеспечения используют методы гибкой разработки. Они с выгодой для себя освоили эти итеративные и инкрементные методы коллективной разработки решений. Традиционный, негибкий подход к созданию программного обеспечения обычно опирается на более регламентированный процесс разработки. Примером служит процесс типа "водопад", когда все действия по определению требований, проектированию, разработке и тестированию выполняются последовательно.
Хотя разработка методом "водопад" на протяжении многих лет оставалась стандартом разработки больших и сложных систем, она имеет несколько явных недостатков. Во-первых, много сил тратится впустую на составление документов перед началом проектирования и на проектирование перед началом программирования, хотя хорошо известно, что со временем требования будут меняться. Во-вторых, когда тестирование и интеграция откладываются до завершающих этапов проекта, проблемы часто выявляются слишком поздно, чтобы их можно было решить, не срывая установленных сроков. В мире, который развивался более медленными темпами, сочетание этих двух факторов, быть может, было терпимым. Но когда темпы создания инновационных систем ускорились, этот подход перестал удовлетворять потребности организаций.
Несмотря на то, что их популяризировали группы разработки ИТ-систем, гибкие методы в равной степени применимы и к разработке продуктов, состоящих из аппаратных средств, электроники и программного обеспечения. Разработка встроенного программного обеспечения отличается от разработки ИТ-приложений главным образом ограниченной доступностью целевых ресурсов установки, таких как ресурсы процессора и памяти. В этих стесненных условиях встроенное программное обеспечение часто решает сложные задачи в режиме реального времени. Подумайте о компьютеризированной системе типа той, что управляет подушками безопасности в вашем автомобиле. Они должны срабатывать немедленно ― и в то же время надежно. Первоначально гибкие методы предназначались для небольших, компактно расположенных групп, работающих в нерегулируемых отраслях. Потребовалось много лет, чтобы они распространились на более крупные и сложные проекты.
При применении в рамках архитектурного подхода методы непрерывной интеграции (CI) и разработки через тестирование (TDD) расширяют базовые методы гибкой разработки настолько, чтобы обеспечить высокое качество и гибкость проектов. В этой статье рассматриваются способы использования гибких методов, CI и TDD в контексте разработки встроенного программного обеспечения. В ней также описываются преимущества этой комбинации.
Сегодня большинство людей слышало о методах гибкой разработки. Идеи, которые они внесли в разработку программного обеспечения, изменили подход к организации работ, адаптации к меняющимся требованиям и выпуска программного обеспечения. Непрерывная интеграция предназначена для гибкой разработки, так что гибкий подход служит контекстом любых разговоров о CI. Она организует разработку с помощью функциональных пользовательских легенд (user stories). Этих легенды образуют отдельные группы задач, спринты (sprints).
Идея в том, чтобы не пытаться решить каждую проблему заранее, а сосредоточиться на уже известных вещах. Таким образом, группа проектирует, собирает и проверяет то, что наверняка обеспечит требуемую функциональность. Это приводит к созданию рабочего продукта, основанного на подмножестве полных требований. Затем группа переходит к следующему по приоритетности набору требований, и процесс повторяется. Конечно, это очень упрощенный взгляд, и существует много вариантов этого процесса, тем не менее ядро одно: пошаговое построение продукта с постепенным совершенствованием.
По словам Мартина Фаулера из ThoughtWorks, непрерывная интеграция ― это практика разработки программного обеспечения, которая требует от членов группы частой интеграции их работы. Каждый занимается интеграцией, по крайней мере, ежедневно, что приводит к множеству актов интеграции в день. Интеграция проверяется путем автоматической сборки с прохождением регрессивных тестов для скорейшего выявления ошибок. Этот подход приводит к значительно меньшему числу проблем интеграции и позволяет разработкам быстрее согласовать свое программное обеспечение.
Так мы подходим к последней детали, которая делает процесс CI успешным. Если идея непрерывной интеграции ― быстро выявить проблемы, так чтобы каждый разработчик видел результат своей работы, то должен быть способ быстро оценить эту работу. Эту задачу решает разработка через тестирование. Вы создаете тест, и затем разрабатываете функциональность до тех пор, пока код этот тест не пройдет. При каждом дополнении к коду в набор тестов добавляются испытания для него, и этот набор применяется к результату. Это гарантирует, что дополнения не нарушат то, что уже сделано, а те разработчики, чей код "нарушает сборку", быстро узнают об этом. Типичное сочетание непрерывной интеграции и разработки через тестирование иллюстрируется на рисунке 1.
Рисунок 1. Гибкая разработка с помощью непрерывной интеграции и разработки через тестирование
Проекты, которые выигрывают от непрерывной интеграции
Полигоном для методов гибкой разработки и CI были группы менее чем из 50 человек, работающие над несложными проектами. Но продукты становятся все более "интеллектуальными", и их сложность быстро повышается.
Количество встроенного программного обеспечения, присутствующего в традиционных изделиях, поражает воображение. Сегодня новый автомобиль оценивается не столько по мощности двигателя, сколько по технологии встроенного программного обеспечения (помощь при парковке, передовые меры безопасности, эффективное использование топлива, развлекательная система и т.п.). Сегодня при создании нового автомобиля пишется больше строк кода, чем было написано для истребителя F16.
Это увеличение сложности продукции сопровождается ускорением выпуска новых продуктов на рынок. Распространенность встроенного программного обеспечения в сочетании с более жесткими сроками привели разработчиков встраиваемых систем к гибким методам и CI.
Использование гибких методов для разработки встраиваемых систем
Гибкие методы позволяют группам разработки программного обеспечения и систем быстро реагировать на изменения. Гибкий подход уменьшает риск срыва сроков, связанный с традиционным проектированием ПО, при котором интеграция компонентов рассматривается как один из поздних этапов разработки. Эта поздняя интеграция приводит к тому, что неправильное толкование требований обнаруживается слишком поздно, чтобы успеть решить проблемы и не сорвать сроки выпуска.
Тем не менее, группы системной разработки, которые выпускают не только программные компоненты, скептически относятся к некоторым аспектам гибкого подхода. Если многое не спланировать заранее, утверждают они, то интеграция программного и аппаратного обеспечения будет плохой. Но без ранних и частых контрольных точек, когда ход разработки сверяется с архитектурным планом, компонент, способный функционировать в более широкой системе, может не получиться. Более того, разработчикам сложных систем, которым нужна возможность многократного использования конструкции или масштабирование для удовлетворения требований более крупного проекта, гибкие методы могут показаться ограниченными.
Эти опасения понятны, потому что методы гибкой разработки не предусматривают моделирования и архитектурного планирования. Но подход CI к разработке систем несет в себе несколько усовершенствований по сравнению с классическими методами гибкой разработки. CI помогает группам разработчиков систем гибко реагировать на быстрые изменения, в то же время гарантируя постоянную синхронизацию аппаратного и программного обеспечения на этапах разработки. CI позволяет членам группы эффективно работать, сосредоточившись на задачах, которые они решают лучше всего. В конце каждого дня они знают, что их вклад интегрирован в проект и что все составные части работают вместе. А если что-то не интегрировано, то это быстро выявляется.
Рассмотрим некоторые из основных ингредиентов разработки и выпуска сложной системы и то, как CI помогает решать эти задачи.
При создании сложной системы нельзя непрерывно добавлять функции без всякого плана. Без плана все, что достигнуто в ходе дополнительных итераций, становится кандидатом на переделку. Называйте это планом, моделью или архитектурой, но это обеспечивает прочный фундамент, от которого отталкивается итеративный процесс.
Архитектура может быть полезна и для небольших проектов, над которыми работают не более 50 человек, но когда этот размер превышен, необходима предварительная работа, которая приведет к пониманию состава, возможностей для повторного использования и степени изменяемости изделия. Этот предварительный анализ позволяет разбить коллектив на отдельные группы и в то же время получить скоординированный продукт. То же справедливо и тогда, когда аппаратное и программное обеспечения разрабатываются вместе, как это делается в случае создания сложных систем с встроенным ПО.
Моделирование
Превратив архитектуру в имитационную модель, можно увидеть, как система будет реагировать на различные события. Эта форма раннего тестирования позволяет проверить, что система работает как предполагалось, отвечая установленным требованиям. Это также позволяет выявить все непредвиденные особенности конструкции. Такие особенности очень трудно увидеть при изучении кода в виде текста. При моделировании системы они становятся гораздо более очевидными ― и еще более очевидным при наблюдении за этой моделью системы в действии.
Таким образом, моделирование и имитация позволяют приступить к тестированию и интеграции в самом начале работы над проектом, что исключает задержки, которые могли произойти, если бы встроенного оборудования еще не было. Они сэкономят значительные инвестиции в создание лишних, нежизнеспособных прототипов архитектуры. Даже когда оборудование уже есть, для непрерывной интеграции требуются все новые сборки.
Чем раньше нужно увидеть результат, тем дороже становится среда разработки. Поскольку основная цель CI ― скорейшее получение результатов, моделирование позволяет выполнять тестирование без чрезмерно высоких расходов на аппаратуру. К тому же оно облегчает передачу информации о функциональности компонентов, что может оказаться полезным для коллективного программирования и "обзоров кода", распространенных при гибкой разработке.
Для непрерывной интеграции требуется автоматизация сборки, то есть возможность автоматически компилировать программное обеспечение и соединять его в исполняемый файл. Это нужно делать быстро, потому что на большие сборки может уйти много времени. Без быстрого и надежного процесса сборки не будет обзора, необходимого для решения возникающих проблем интеграции. Когда выполняется интеграция сборки, разрешаются конфликты между изменениями, внесенными разными разработчиками. Когда обнаружена проблема, программист, работавший над разрешением конфликта предыдущей сборки, может проверить код с помощью аппаратного моделирования, не задерживая других разработчиков. Однако для достижения такой эффективности процесс интеграции сборок должен идти непрерывно, так что как только заканчивается работа над предыдущей сборкой, появляется новая. Это значительно отличается от ежедневного или еженедельного выпуска сборок, практикуемого другими процессами.
Конечно, для этого требуется автоматизация процесса сборки, потому что непрактично поручать человеку задачу многократного создания сборок ― снова и снова в течение всего рабочего дня. Более того, процесс сборки должен выполняться быстро, для чего часто требуется многопоточная сборка. При многопоточной сборке сборка разных компонентов программного обеспечения выполняется параллельно, что ускоряет весь процесс. Для это требуется больше оборудования и более сложный сценарий. А чем сложнее сценарий, тем полезнее становятся инструменты управления сборкой.
Управление работой
Основная идея гибкой разработки заключается в том, что работа разбивается на небольшие, управляемые фрагменты. Это же основная предпосылка CI: исправлять ошибки рано и часто. Это предотвращает их перерастание в более крупные проблемы, которые труднее решить.
Одно из преимуществ этого метода ― возможность выпускать действующие версии меньшего размера, собранные и протестированные много раз по ходу проекта. Каждый выпуск уменьшает риск для проекта, так как группа проверяет архитектуру, требования и оценивает сроки выпуска. В гибких методах еще не завершенная работа называется очередью задач (backlog). Когда начинают распределять работу малыми шагами, так называемыми спринтами , работа, отведенная спринту, называется очередью задач спринта (sprint backlog). Работа, оставшаяся для будущих спринтов, называется очередью задач проекта . В спринт должно включаться столько работы, чтобы ее можно было выполнить в сроки, отведенные для спринта.
Этот процесс сильно зависит от ряда параметров, так что группа может точно предсказать количество времени, которое потребуется для решения задачи, и, следовательно, количество задач, которые можно отвести для одного спринта. Однако сбор данных для оценки этих показателей ― очень трудоемкий процесс, даже для небольшой группы. Когда такие небольшие группы объединяются, чтобы произвести более сложный продукт, задача становится слишком грандиозной, чтобы ее можно было решить вручную.
На рынке много инструментов, помогающих организовать работу, отслеживать ее завершение и определить показатели, связанные с тем, в каком объеме, как быстро, как хорошо и т.д. выполнена работа. Если следовать методам CI, то к этой незавершенной работе нужно также быстро добавлять выявленные ошибки интеграции и переносить ее в начало списка высокоприоритетных работ. Лучшие продукты этого назначения на рынке обеспечивают некоторый уровень интеграции между новыми элементами работы и системой управления сборками, так что ошибки, выявленные в каждой сборке, можно быстро исправить и интегрировать результат с готовыми элементами работы, повысить его приоритет и направить нужной группе.
Управление качеством ― практика, гарантирующая, что в ходе разработки будут протестированы все требования, предъявляемые к продукту. Эти усилия должны быть организованы и понятны, чтобы при изменении требований можно было обновить соответствующие тесты. Менеджмент качества помогает руководителям проектов ответить на следующие вопросы:
- Если бы мой продукт нужно было выпустить на следующей неделе, какие части представляли бы наибольший риск?
- Можно ли выпустить продукт без соблюдения низкоуровневых требований?
- Будет ли это высококачественный выпуск?
Под давлением рынка, которое ускоряет циклы выпуска, быстрое получение ответов на эти вопросы может помочь предприятию уверенно выпускать свои продукты. Менеджеры лучше понимают, какие ресурсы добавить, какие функции продукта подрегулировать и какие сроки назначить, чтобы получить максимальное преимущество.
При разработке через тестирование идея тестирования приобретает центральное значение для проекта разработки. При TDD пишут тесты, основанные на требованиях, а затем разрабатывают код, пока он не пройдет эти тесты. Это гарантирует, что не будет никакой лишней функциональности, которая стала бы тем, что разработчики называют "позолотой". Даже если дополнительная функция или возможность кажется хорошей идеей, дополнительная работа без согласования соответствующих требований может повысить стоимость разработки и увеличить время выпуска. А это не способствует удовлетворенности заказчика конечным продуктом.
Автоматизированное тестирование
При создании множества сборок группа должна многократно тестировать функции, уже работающие в предыдущих сборках. Этот процесс повторного тестирования, который раньше называли "добротным кодом" (good code), носит имя регрессионного тестирования . Он гарантирует, что внесенные изменения не приведут к ошибкам в ранее протестированном коде. В случае CI в конце каждой сборки запускаются автоматические сценарии регрессионных тестов. Это позволяет разработчикам немедленно получать информацию об ошибках, найденных в новой сборке. Этот шаг предупреждает разработчиков, когда вновь созданный ими код не соответствует требованиям. Без регрессионных тестов разработчики знают только, что сборка выполнена. Поскольку тесты все равно должны создаваться, то TDD не добавляет дополнительную работу. Просто меняется порядок действий ― сначала создаются тесты, а затем код.
При традиционной разработке методом "водопад" проект мог обходиться без всякой автоматизации тестирования. Его можно было описывать, выполнять и испытывать бесконечно целой армией людей. Но как только начинаются регулярные выпуски, этот процесс сталкивается с проблемами. Просто невозможно тестировать систему вручную много раз в день.
Подразделение IBM Rational ― давний сторонник сотрудничества как критически важного элемента успешной разработки и поставки систем. Но в процессе CI, в котором участвуют группы разработчиков программного и аппаратного обеспечения, сотрудничество предусматривает не только эффективную передачу артефактов из одной группы в другую, но и полное понимание компромиссов между требованиями, возможностями и сроками.
Хорошая архитектура делает возможным такого рода сотрудничество, отчасти потому, что люди лучше понимают зависимость между различными компонентами проекта. Управление портфелем проектов помогает анализировать особенности, возможности повторного использования и распределение ресурсов. Но в проектах по совместной разработке аппаратного и программного обеспечения также важно управлять требованиями и принимать взвешенные решения о том, когда эти требования можно изменить, а когда нельзя.
В таких проектах обычно много ответственных лиц на разных уровнях принятия решений. Хорошее сотрудничество помогает удовлетворить больший процент заинтересованных лиц. Оно гарантирует создание требуемого продукта и быстрое выявление отклонений от более широких целей. Результатом становится продукт, который лучше удовлетворяет потребности клиентов.
С технической точки зрения CI помогает группам работать эффективнее. Это могут быть кроссфункциональные группы, создающие взаимодействующее аппаратное и программное обеспечение. Они могут быть географически распределены, потому что постоянная работа по интеграции гарантирует отсутствие отклонений от проекта. Люди могут работать в большом коллективе с уверенностью, что разные компоненты сложной системы будут правильно взаимодействовать. Это устраняет многие из тех препятствий, с которыми могут столкнуться группы нетрадиционной, гибкой разработки без CI. Сочетание CI с разработкой через тестирование собирает под знаменем гибкой разработки больше людей, потому что она позволяет гибким методам работать эффективнее.
С точки зрения бизнеса CI гарантирует лучшие результаты, позволяя группам убить сразу двух зайцев. Они могут быстрее выпускать продукты на рынок, выявляя проблемы на ранней стадии, пока те еще не приняли угрожающих размеров. И могут лучше реагировать на требования, появившиеся тогда, когда продукт уже находился в стадии разработки. Это позволяет предложить заказчику более качественный продукт, что и является целью гибкой разработки.