Итеративно-инкрементная разработка программного обеспечения

Введение

Методология разработки
Итеративная и инкрементная разработка – это любая комбинация итеративного проектирования или итеративного метода и инкрементной модели сборки при разработке. Использование этого термина зародилось в разработке программного обеспечения, при этом длительное сочетание терминов «итеративный» и «инкрементный» широко рекомендовалось для крупных проектов разработки. Например, в DOD STD 2167 1985 года упоминается (в разделе 4.1.2): «В процессе разработки программного обеспечения одновременно может выполняться несколько итераций цикла разработки программного обеспечения» и «Этот процесс можно описать как подход «эволюционного приобретения» или «постепенной сборки»». В разработке программного обеспечения взаимосвязь между итерациями и инкрементами определяется общим процессом разработки программного обеспечения.

Обзор

Основная идея этого метода заключается в разработке системы посредством повторяющихся циклов (итераций) и небольшими порциями (инкрементами), что позволяет разработчикам программного обеспечения использовать опыт, полученный при разработке более ранних частей или версий системы. Обучение происходит как в процессе разработки, так и в процессе использования системы, при этом ключевые этапы процесса, где это возможно, начинаются с простой реализации подмножества программных требований и итеративно улучшают развивающиеся версии до полной реализации системы. На каждой итерации вносятся изменения в конструкцию и добавляются новые функциональные возможности. Сама процедура состоит из этапа инициализации, этапа итерации и Списка управления проектом. Этап инициализации создает базовую версию системы. Цель этой первоначальной реализации – создать продукт, на который пользователь сможет дать обратную связь. Он должен демонстрировать ключевые аспекты проблемы и предлагать решение, достаточно простое для понимания и легкой реализации. Для управления процессом итераций создается список управления проектом, содержащий перечень всех задач, которые необходимо выполнить. Он включает в себя такие пункты, как новые функции для реализации и области перепроектирования существующего решения. Список управления проектом постоянно пересматривается по результатам фазы анализа. Итерация включает в себя перепроектирование и реализацию, которые должны быть простыми, понятными и модульными, обеспечивая возможность перепроектирования на данном этапе или добавления задачи в список управления проектом в будущем. Уровень детализации проектирования не определяется итеративным подходом. В проектах с упрощенным итеративным подходом код может служить основным источником документации системы; однако в критически важных итеративных проектах может использоваться формальный документ по проектированию программного обеспечения. Анализ итерации основан на отзывах пользователей и средствах анализа программы. Он включает в себя анализ структуры, модульности, удобства использования, надежности, эффективности и достижения целей. Список управления проектом изменяется с учетом результатов анализа.

The basic idea behind this method is to develop a system through repeated cycles (iterative) and in smaller portions at a time (incremental), allowing software developers to take advantage of what was learned during development of earlier parts or versions of the system. Learning comes from both the development and use of the system, where possible key steps in the process start with a simple implementation of a subset of the software requirements and iteratively enhance the evolving versions until the full system is implemented. At each iteration, design modifications are made and new functional capabilities are added. The procedure itself consists of the initialization step, the iteration step, and the Project Control List. The initialization step creates a base version of the system. The goal for this initial implementation is to create a product to which the user can react. It should offer a sampling of the key aspects of the problem and provide a solution that is simple enough to understand and implement easily. To guide the iteration process, a project control list is created that contains a record of all tasks that need to be performed. It includes items such as new features to be implemented and areas of redesign of the existing solution. The control list is constantly being revised as a result of the analysis phase. An iteration involves redesign and implementation, which is meant to be simple, straightforward, and modular, supporting redesign at that stage or as a future task added to the project control list. The level of design detail is not dictated by the iterative approach. In a light weight iterative project the code may represent the major source of documentation of the system; however, in a critical iterative project a formal Software Design Document may be used. The analysis of an iteration is based upon user feedback and the program analysis facilities available. It involves analysis of the structure, modularity, usability, reliability, efficiency, and achievement of goals. The project control list is modified in light of the analysis results.

Фазы

Инкрементальная разработка разделяет функциональность системы на инкременты (части). В каждом инкременте, часть функциональности реализуется посредством совместной работы различных специалистов, от определения требований до развертывания. Унифицированный процесс объединяет инкременты/итерации в фазы: инициация, уточнение, реализация и внедрение. Фаза инициации определяет объем проекта, требования (функциональные и нефункциональные) и риски на высоком уровне, но с достаточной детализацией для оценки трудозатрат. Фаза уточнения предоставляет рабочую архитектуру, которая снижает основные риски и удовлетворяет нефункциональным требованиям. Фаза реализации постепенно дополняет архитектуру производственным кодом, полученным в результате анализа, проектирования, разработки и тестирования функциональных требований. Фаза внедрения обеспечивает развертывание системы в производственной среде. Каждая фаза может быть разделена на одну или несколько итераций, которые обычно ограничены по времени, а не по набору функций. Архитекторы и аналитики работают на одну итерацию впереди разработчиков и тестировщиков, чтобы поддерживать их рабочий бэклог в актуальном состоянии.

Использование/история

Многие примеры раннего использования приведены в статье Крейга Лармана и Виктора Базили "Итеративная и инкрементная разработка: краткая история", одним из самых ранних из которых является проект NASA "Меркурий" 1960-х годов. Некоторые из этих инженеров "Меркурия" позже сформировали новое подразделение в IBM, где "еще одним ранним и впечатляющим примером крупного успеха IID стало ядро программного обеспечения космического шаттла NASA – основная система авионики, которую они создавали с 1977 по 1980 год. Команда применяла IID в серии из 17 итераций за 31 месяц, в среднем по восемь недель на итерацию. Их мотивацией для отказа от каскадной модели разработки было то, что требования к программе шаттла менялись в процессе разработки программного обеспечения". Кроме того, Агентство США по международному развитию (USAID) также использует итеративный и инкрементный подход к разработке в своем цикле планирования для проектирования, мониторинга, оценки, обучения и адаптации международных проектов развития, применяя подход к управлению проектами, ориентированный на включение стратегий сотрудничества, обучения и адаптации для итераций и адаптации планирования.

Контраст с развитием водопада

Основной причиной неудачи проектов разработки программного обеспечения является выбор модели, поэтому к этому следует подходить с большой осторожностью. Например, каскадная модель разработки (Waterfall) завершает создание всех проектных результатов по каждой дисциплине за один этап, прежде чем переходить к следующей дисциплине на последующем этапе. Бизнес-ценность предоставляется единовременно и только в самом конце проекта, в то время как в итеративном подходе возможен возврат к предыдущим этапам. Сравнение этих двух подходов позволяет выявить некоторые закономерности:

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

Использование в аппаратных средствах и встроенных системах

В то время как термин "итеративная и инкрементальная разработка" возник в индустрии программного обеспечения, многие проекты по разработке аппаратного обеспечения и встроенного ПО используют итеративные и инкрементальные методы. Примеры этого можно встретить в различных отраслях. Одной из областей, которая в последнее время претерпела значительные изменения в этой связи, является космическая отрасль, где появились существенные новые конкурентные силы, обусловленные более быстрыми и масштабными технологическими инновациями, вызванными созданием частных компаний, занимающихся космическими запусками. Эти компании, такие как SpaceX и Rocket Lab, в течение последнего десятилетия предоставляют коммерческие услуги по выведению на орбиту, что ранее удавалось только шести странам. Новые инновации в подходах к разработке технологий, ценообразовании и спектре предлагаемых услуг – включая возможность, появившуюся лишь с 2016 года, летать в космос на ранее использованной (многоразовой) ступени ракеты-носителя – еще больше снижают стоимость доступа в космос. По мере изменения отрасли, другие участники рынка также начинают менять свои долгосрочные методы разработки, в том числе при работе с государственными организациями. Например, крупный американский поставщик услуг по запуску United Launch Alliance (ULA) начал в 2015 году десятилетний проект по реструктуризации своего бизнеса, сократив количество типов ракет-носителей с двух до одного, используя итеративный и инкрементальный подход для создания частично многоразовой и значительно более дешевой системы запуска в течение следующего десятилетия.