Итеративная и инкрементальная разработка — это любая комбинация итеративного проектирования (или итеративного метода) и модели инкрементальной сборки для разработки .
Использование термина началось в разработке программного обеспечения , с давней комбинации двух терминов итеративный и инкрементальный [1], которые широко предлагались для крупных усилий по разработке. Например, в документе DOD-STD-2167 1985 года [2] упоминается (в разделе 4.1.2): «Во время разработки программного обеспечения может одновременно выполняться более одной итерации цикла разработки программного обеспечения». и «Этот процесс можно описать как подход «эволюционного приобретения» или «инкрементальной сборки». В программном обеспечении связь между итерациями и инкрементами определяется общим процессом разработки программного обеспечения .
Основная идея этого метода заключается в разработке системы посредством повторяющихся циклов (итеративный) и меньшими порциями за раз (инкрементальный), что позволяет разработчикам программного обеспечения использовать то, что было изучено во время разработки более ранних частей или версий системы. Обучение происходит как из разработки, так и из использования системы, где возможные ключевые шаги в процессе начинаются с простой реализации подмножества требований к программному обеспечению и итеративно улучшают развивающиеся версии до тех пор, пока не будет реализована полная система. На каждой итерации вносятся изменения в конструкцию и добавляются новые функциональные возможности. [3]
Сама процедура состоит из шага инициализации, шага итерации и списка контроля проекта. Шаг инициализации создает базовую версию системы. Цель этой начальной реализации — создать продукт, на который пользователь может отреагировать. Он должен предлагать выборку ключевых аспектов проблемы и предоставлять решение, которое достаточно просто для понимания и реализации. Для руководства процессом итерации создается список контроля проекта, содержащий запись всех задач, которые необходимо выполнить. Он включает такие элементы, как новые функции, которые необходимо реализовать, и области переработки существующего решения. Список контроля постоянно пересматривается в результате фазы анализа.
Итерация включает в себя перепроектирование и реализацию, которые должны быть простыми, понятными и модульными, поддерживающими перепроектирование на этом этапе или в качестве будущей задачи, добавленной в контрольный список проекта. [ необходимо разъяснение ] Уровень детализации проекта не диктуется итеративным подходом. В легком итеративном проекте код может представлять собой основной источник документации системы; однако в критическом итеративном проекте может использоваться формальный документ по проектированию программного обеспечения . Анализ итерации основан на отзывах пользователей и доступных средствах анализа программы. Он включает в себя анализ структуры, модульности, удобства использования , надежности, эффективности и достижения целей. Контрольный список проекта изменяется в свете результатов анализа.
Инкрементальная разработка делит функциональность системы на инкременты (порции). В каждом инкременте часть функциональности поставляется посредством междисциплинарной работы, от требований до развертывания . Унифицированный процесс группирует инкременты/итерации в фазы: начало, разработка, построение и переход.
Каждая из фаз может быть разделена на 1 или более итераций, которые обычно ограничены по времени, а не по функциям. Архитекторы и аналитики работают на одну итерацию впереди разработчиков и тестировщиков, чтобы поддерживать свой бэклог по работе-продукту полным.
Множество примеров раннего использования приведены в статье Крейга Лармана и Виктора Базили «Итеративное и пошаговое развитие: краткая история» [4] , одним из самых ранних из которых является проект НАСА «Меркурий» 1960-х годов .
Некоторые из этих инженеров Mercury позже сформировали новое подразделение в IBM , где «еще одним ранним и ярким примером крупного успеха IID [было] самое сердце программного обеспечения космического челнока НАСА — основная система программного обеспечения авионики, которую [они] создавали с 1977 по 1980 год. Команда применила IID в серии из 17 итераций в течение 31 месяца, в среднем около восьми недель на итерацию. Их мотивацией для избежания жизненного цикла водопада было то, что требования программы челнока менялись в процессе разработки программного обеспечения». [4]
Некоторые организации, такие как Министерство обороны США, отдают предпочтение итеративным методологиям, начиная с MIL-STD-498, «явно поощряющего эволюционное приобретение и IID».
В инструкции Министерства обороны США 5000.2, выпущенной в 2000 году, четко указано предпочтение IID:
Существует два подхода к полной мощности: эволюционный и одношаговый [водопадный]. Эволюционный подход предпочтительнее. … [В этом] подходе конечная возможность, предоставляемая пользователю, делится на два или более блоков с увеличивающимися приращениями возможностей... разработка программного обеспечения должна следовать итеративному спиральному процессу разработки, в котором постоянно расширяющиеся версии программного обеспечения основаны на изучении более ранней разработки. Это также может быть сделано поэтапно.
Недавние изменения DoDI 5000.02 больше не ссылаются на «спиральную разработку», но поддерживают общий подход в качестве основы для программ разработки/закупок с интенсивным использованием программного обеспечения. [5] Кроме того, Агентство США по международному развитию (USAID) также использует итеративный и инкрементальный подход к развитию в своем цикле программирования для проектирования, мониторинга, оценки, изучения и адаптации международных проектов развития с подходом к управлению проектами, который фокусируется на включении стратегий сотрудничества, обучения и адаптации для итерации и адаптации программирования. [6]
Основной причиной неудач проектов по разработке программного обеспечения является выбор модели, поэтому к нему следует подходить с большой осторожностью. [ неопределенно ] [7]
Например, парадигма разработки Waterfall завершает общепроектные рабочие продукты каждой дисциплины за один шаг, прежде чем перейти к следующей дисциплине на последующем шаге. Бизнес-ценность предоставляется сразу и только в самом конце проекта, тогда как возврат назад [ необходимо разъяснение ] возможен при итеративном подходе. Сравнивая два подхода, начинают проявляться некоторые закономерности: [ необходима цитата ]
Руководящие принципы, определяющие реализацию и анализ программного обеспечения, включают: [ необходима ссылка ]
Хотя термины «итеративная и инкрементальная разработка» появились в индустрии программного обеспечения, многие разработки аппаратного и встроенного программного обеспечения используют итерационные и инкрементальные методы.
Примеры этого можно увидеть в ряде отраслей. Одним из секторов, который недавно существенно пострадал от этого изменения мышления, стала индустрия космических запусков , в которой появились новые существенные конкурентные силы, вызванные более быстрыми и обширными технологическими инновациями, появившимися в результате формирования частных компаний, занимающихся космическими запусками. Эти компании, такие как SpaceX [8] и Rocket Lab [9] , в настоящее время предоставляют коммерческие услуги по орбитальным запускам в последнее десятилетие, что делали только шесть стран до этого десятилетия [10] назад. Новые инновации в подходах к разработке технологий, ценообразовании и предложениях услуг, включая возможность, которая появилась только с 2016 года, летать в космос на ранее запущенной (многоразовой) ступени ускорителя , еще больше снижают стоимость получения доступа в космос. [11] [8]
SpaceX открыто заявила о своих усилиях по внедрению методов итеративного проектирования в космическую отрасль и использует эту технологию в космических аппаратах, ракетах-носителях, электронике и авионике, а также в эксплуатационных операциях летательного аппарата. [12]
Поскольку отрасль начала меняться, другие конкуренты по запуску также начинают менять свою долгосрочную практику разработки с государственными агентствами . Например, крупный американский поставщик услуг запуска United Launch Alliance (ULA) начал в 2015 году десятилетний проект по реструктуризации своего бизнеса по запуску — сократив два пусковых аппарата до одного — используя итеративный и инкрементный подход, чтобы в течение следующего десятилетия получить частично многоразовую и гораздо более дешевую систему запуска. [13]
Мы занимались инкрементальным развитием еще в 1957 году в Лос-Анджелесе под руководством Берни Димсдейла [в IBM ServiceBureau Corporation]. Он был коллегой Джона фон Неймана , так что, возможно, он научился этому там или считал это совершенно естественным. Я помню, как Герб Джейкобс (в первую очередь, хотя мы все участвовали) разрабатывал большую симуляцию для Motorola, где использовалась техника, насколько я могу судить...'
Выбор инкрементальной модели для проектов со стабильными требованиями может привести к расползанию области действия и повышению сложности, в то время как выбор каскадной модели может привести к жесткости и неэффективности адаптации к изменениям.
первая частная жидкотопливная ракета, успешно достигшая орбиты.
Быстрый рост недорогих альтернатив, таких как ракета Falcon 9 компании SpaceX, привел к тому, что количество запусков «Протона» в год сократилось с восьми до одного или двух.
Но SpaceX всегда считала себя технологической фирмой, и ее столкновения с NASA часто принимали форму, которую разработчики компьютеров — или кто-либо, знакомый с проблемным развертыванием healthcare.gov — могли бы распознать как поколенческую. SpaceX следовала итеративному процессу проектирования, постоянно улучшая прототипы в ответ на тестирование. Традиционное управление продуктами требует надежного плана, выполняемого до конца, что является рецептом перерасхода средств.
13 апреля ULA объявила о том, что будет разрабатывать ракету под названием Vulcan с использованием поэтапного подхода, первая итерация которого по сути представляет собой Atlas 5, оснащенную новой первой ступенью.