ГИБКАЯ РАЗРАБОТКА ВСТРОЕННОГО ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ

AGILE EMBEDDED SOFTWARE DEVELOPMENT

Vladimir Moiseev

Ph.D., Programming Engineer of FRPC JSC “RPA “Mars”,

Russia, Ulyanovsk,

Aleksandr Lushnikov

deputy Chief Designer of FRPC JSC “RPA “Mars”,

Russia, Ulyanovsk,

Tatiana  Davydova

Ph.D., Lead Engineer of FRPC JSC “RPA “Mars”,

Russia, Ulyanovsk,

АННОТАЦИЯ

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

ABSTRACT

The article deals with the applying of methods to embedded software development and continuous integration in embedded software creation projects. Continuous integration approach helps systems development teams be agile and respond to rapid changes while at the same time ensuring that the actual hardware and software under development are in constant synchronization. Integration errors are detected and reduced rapidly.

Ключевые слова: встроенное программное обеспечение; гибкая разработка; непрерывная интеграция.

Keywords: embedded software, agile development, continuous integration.

Набор методов разработки программного обеспечения (ПО), обеспечивающих постоянное сотрудничество между заинтересованными лицами и быстрый и частый выпуск функциональности небольшими порциями, называют гибкой разработкой. Существует множество видов гибкой разработки. Наиболее популярными являются: Scrum, Kanban, Feature-Driven Development, Lean Software Development, Extreme Programming. Гибкая разработка основана на инкрементальных и интерактивных подходах [1].

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

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

В настоящее время все больше групп разработчиков ВПО используют методы гибкой разработки. Примером негибкого подхода служит процесс типа «водопад», когда все действия по определению требований, проектированию, разработке и тестированию выполняются последовательно. Несмотря на то, что разработка методом «водопад» на протяжении многих лет оставалась стандартом разработки объемных и сложных систем, она имеет ряд недостатков. Во-первых, много сил тратится впустую на составление документов перед началом проектирования и на проектирование перед началом программирования, хотя хорошо известно, что со временем требования будут меняться. Во-вторых, когда интеграция и тестирование откладываются до заключительных этапов проекта, проблемы обычно выявляются слишком поздно, чтобы их можно было решить, не срывая установленных сроков [2, 3]. С ускорением темпов создания систем, негибкий подход перестал удовлетворять потребностям заказчиков и разработчиков.

С помощью функциональных пользовательских легенд организует разработку на основе непрерывной интеграции. Спринтами называются легенды, образующие отдельные группы задач. Рабочая группа проверяет, разрабатывает и собирает то, что полностью обеспечивает требуемую функциональность. Это приводит к созданию рабочего продукта, основанного на множестве полных требований. Далее процесс повторяется: группа переходит к следующему по приоритетности набору требований и реализует их [5]. Таким образом, выполняется пошаговое создание ВПО с постепенным усложнением.

Рисунок 1. Гибкая разработка на основе непрерывной интеграции

Ниже приводятся основные методов разработки и выпуска сложного ВПО.

Архитектура ПО – совокупность решений об организации программной системы. Архитектура содержит:

• структурные элементов и интерфейсы, на основе которых составлена система, и их поведение в рамках взаимодействия;
• соединение поведения и элементов структуры в более крупные системы;
• архитектурный стиль [6, 7].

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Список литературы:

1. Вигерс К., Битти Дж. Проекты гибкой разработки (agile) [Электронный ресурс] – Режим доступа. – URL:http://iiba.ru/requirements-analysis/agile-software-development/ (дата обращения 01.06.2017)
2. Вольфсон Б. Гибкие методологии разработки [Электронный ресурс], – http://adm-lib.ru/books/10/Gibkie-metodologii.pdf – статья в интернете.
3. Моисеев В.Н. Разработка встроенного программного обеспечения на основе процесса Harmony // Перспективы развития современных информационных технологий : сборник материалов XXXIII Международной научно-практической конференции / Под общ. ред. С.С. Чернова. – Новoсибирск : Издательствo  ЦPHC,  2016. – 214 с.
4. Documenting Software Architectures: Views and Beyond, 2010, P.1.1. Overview.
5. IBM Rational: Непрерывная интеграция в процессе гибкой разработки [Электронный ресурс] – Режим доступа. – http://www.interface.ru/home.asp?artId=33298 (дата обращения 01.06.2017)
6. Kruchten P. The Rational Unified Process-An Introduction, Addison-Wesley, 1998.
7. Rumbaugh J., Jacobsen I., Booch G. The Unified Modelling Language Reference Manual. Reading, Mass.: Addison-Wesley, 1999.