Итеративное и пошаговое развитие

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

Итеративная и инкрементальная разработка — это любая комбинация итеративного проектирования (или итеративного метода) и модели инкрементальной сборки для разработки .

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

Обзор

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

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

Итерация включает в себя перепроектирование и реализацию, которые должны быть простыми, понятными и модульными, поддерживающими перепроектирование на этом этапе или в качестве будущей задачи, добавленной в контрольный список проекта. ^{[ необходимо разъяснение ]} Уровень детализации проекта не диктуется итеративным подходом. В легком итеративном проекте код может представлять собой основной источник документации системы; однако в критическом итеративном проекте может использоваться формальный документ по проектированию программного обеспечения . Анализ итерации основан на отзывах пользователей и доступных средствах анализа программы. Он включает в себя анализ структуры, модульности, удобства использования , надежности, эффективности и достижения целей. Контрольный список проекта изменяется в свете результатов анализа.

Фазы

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

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

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

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

Множество примеров раннего использования приведены в статье Крейга Лармана и Виктора Базили «Итеративное и пошаговое развитие: краткая история» ^{[4] , одним из самых ранних из которых является}проект НАСА «Меркурий» 1960-х годов .

Некоторые из этих инженеров Mercury позже сформировали новое подразделение в IBM , где «еще одним ранним и ярким примером крупного успеха IID [было] самое сердце программного обеспечения космического челнока NASA — основная система программного обеспечения авионики, которую [они] создавали с 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]

Смотрите также

Ссылки

^ Ларман, Крейг (июнь 2003 г.). "Итеративное и инкрементальное развитие: краткая история" (PDF) . Компьютер . 36 (6): 47– 56. doi :10.1109/MC.2003.1204375. ISSN 0018-9162. S2CID 9240477. Мы занимались инкрементальным развитием еще в 1957 году в Лос-Анджелесе под руководством Берни Димсдейла [в IBM ServiceBureau Corporation]. Он был коллегой Джона фон Неймана , так что, возможно, он научился этому там или считал это совершенно естественным. Я помню, как Герб Джейкобс (в первую очередь, хотя мы все участвовали) разрабатывал большую симуляцию для Motorola, где использовалась техника, насколько я могу судить...'
^ DOD-STD-2167 Разработка программного обеспечения для оборонных систем (04 июня 1985 г.) на everyspec.com
^ Фарчич, Виктор (21 января 2014 г.). «Модели разработки программного обеспечения: итеративная и инкрементальная разработка». Technology Conversations .
^ ab Итеративная и инкрементальная разработка: краткая история, Крейг Ларман и Виктор Базили, IEEE Computer, июнь 2003 г.
^ Кендалл, Фрэнк; Гилмор, Дж. Майкл; Халворсен, Терри (2017-02-02). «Эксплуатация системы оборонных закупок» (PDF) . Выпуски DoD . Заместитель министра обороны по закупкам, технологиям и логистике. стр. 12–14 . Архивировано из оригинала (PDF) 2017-08-09 . Получено 2017-08-09 .
^ USAID. "ADS Chapter 201 Program Cycle Operational Policy" Архивировано 23 октября 2019 г. на Wayback Machine . Получено 19 апреля 2017 г.
^ Кудряшов, Алексей (29 февраля 2024 г.). «Инкрементальная и каскадная модели в разработке программного обеспечения». Cyfrania: Разработка и консалтинг на заказ программного обеспечения . Выбор инкрементальной модели для проектов со стабильными требованиями может привести к расползанию области действия и повышению сложности, в то время как выбор каскадной модели может привести к жесткости и неэффективности адаптации к изменениям.
^ ab Belfiore, Michael (9 декабря 2013 г.). "The Rocketeer". Foreign Policy . Архивировано из оригинала 10 декабря 2013 г. Получено 11 ноября 2018 г.
^ «Эксклюзивный взгляд изнутри на ранее секретную новую мегафабрику Rocket Lab!». Everyday Astronaut . 11 октября 2018 г. Архивировано из оригинала 12 октября 2018 г. Получено 11 ноября 2018 г.
^ Кларк, Стивен (28 сентября 2008 г.). «Наконец-то сладкий успех ракеты Falcon 1». Spaceflight Now . Получено 11 ноября 2018 г. . первая частная жидкотопливная ракета, успешно достигшая орбиты.
^ Бергер, Эрик (25.06.2018). «Российская ракета «Протон», которая предшествовала «Аполлону», наконец-то прекратит летать Технические проблемы и рост SpaceX являются способствующими факторами». arsTechica . Получено 26.06.2018 . Быстрый рост недорогих альтернатив, таких как ракета Falcon 9 компании SpaceX, привел к тому, что количество запусков «Протона» в данном году сократилось с восьми или около того до одного или двух.
^ Фернхольц, Тим (21 октября 2014 г.). «Что потребовалось SpaceX Илона Маска, чтобы подорвать Boeing, обойти NASA и стать серьезной космической компанией». Quartz . Получено 11 ноября 2018 г. . Но SpaceX всегда считала себя технологической фирмой, и ее столкновения с NASA часто принимали форму, которую разработчики компьютеров — или кто-либо, знакомый с проблемным развертыванием healthcare.gov — признали бы как поколенческую. SpaceX следовала итеративному процессу проектирования, постоянно улучшая прототипы в ответ на тестирование. Традиционное управление продуктами требует надежного плана, выполняемого до конца, что является рецептом перерасхода средств.
^ Грасс, Майк (24.04.2015). «Эволюция плана: руководители ULA излагают логику выбора конструкции Vulcan». Новости космоса . Получено 25 апреля 2015 г. 13 апреля ULA объявила о том, что будет разрабатывать ракету под названием Vulcan с использованием поэтапного подхода, первая итерация которого по сути представляет собой Atlas 5, оснащенную новой первой ступенью.

Дополнительное чтение

Доктор Алистер Кокберн (май 2008 г.). «Использование как инкрементальной, так и итеративной разработки» (PDF) . STSC CrossTalk . 21 (5). USAF Software Technology Support Center: 27– 30. ISSN 2160-1593. Архивировано из оригинала (PDF) 2012-05-26 . Получено 2011-07-20 .
Крейг Ларман, Виктор Р. Базили (июнь 2003 г.). «Итеративное и инкрементальное развитие: краткая история» (PDF) . IEEE Computer . 36 (6). IEEE Computer Society: 47– 56. doi :10.1109/MC.2003.1204375. ISSN 0018-9162. S2CID 9240477 . Получено 10.01.2009 .

[1] Ларман, Крейг (июнь 2003 г.). "Итеративное и инкрементальное развитие: краткая история" (PDF) . Компьютер . 36 (6): 47– 56. doi :10.1109/MC.2003.1204375. ISSN 0018-9162. S2CID 9240477. Мы занимались инкрементальным развитием еще в 1957 году в Лос-Анджелесе под руководством Берни Димсдейла [в IBM ServiceBureau Corporation]. Он был коллегой Джона фон Неймана , так что, возможно, он научился этому там или считал это совершенно естественным. Я помню, как Герб Джейкобс (в первую очередь, хотя мы все участвовали) разрабатывал большую симуляцию для Motorola, где использовалась техника, насколько я могу судить...'

[2] DOD-STD-2167 Разработка программного обеспечения для оборонных систем (04 июня 1985 г.) на everyspec.com

[3] Фарчич, Виктор (21 января 2014 г.). «Модели разработки программного обеспечения: итеративная и инкрементальная разработка». Technology Conversations .

[ieee2003-4] Итеративная и инкрементальная разработка: краткая история, Крейг Ларман и Виктор Базили, IEEE Computer, июнь 2003 г.

[DoDI_5000.02_rev2017-02-02-5] Кендалл, Фрэнк; Гилмор, Дж. Майкл; Халворсен, Терри (2017-02-02). «Эксплуатация системы оборонных закупок» (PDF) . Выпуски DoD . Заместитель министра обороны по закупкам, технологиям и логистике. стр. 12–14 . Архивировано из оригинала (PDF) 2017-08-09 . Получено 2017-08-09 .

[6] USAID. "ADS Chapter 201 Program Cycle Operational Policy" Архивировано 23 октября 2019 г. на Wayback Machine . Получено 19 апреля 2017 г.

[7] Кудряшов, Алексей (29 февраля 2024 г.). «Инкрементальная и каскадная модели в разработке программного обеспечения». Cyfrania: Разработка и консалтинг на заказ программного обеспечения . Выбор инкрементальной модели для проектов со стабильными требованиями может привести к расползанию области действия и повышению сложности, в то время как выбор каскадной модели может привести к жесткости и неэффективности адаптации к изменениям.

[fp20131209-8] Belfiore, Michael (9 декабря 2013 г.). "The Rocketeer". Foreign Policy . Архивировано из оригинала 10 декабря 2013 г. Получено 11 ноября 2018 г.

[eda20181111-9] «Эксклюзивный взгляд изнутри на ранее секретную новую мегафабрику Rocket Lab!». Everyday Astronaut . 11 октября 2018 г. Архивировано из оригинала 12 октября 2018 г. Получено 11 ноября 2018 г.

[sfn20080928-10] Кларк, Стивен (28 сентября 2008 г.). «Наконец-то сладкий успех ракеты Falcon 1». Spaceflight Now . Получено 11 ноября 2018 г. . первая частная жидкотопливная ракета, успешно достигшая орбиты.

[arstech20180625-11] Бергер, Эрик (25.06.2018). «Российская ракета «Протон», которая предшествовала «Аполлону», наконец-то прекратит летать Технические проблемы и рост SpaceX являются способствующими факторами». arsTechica . Получено 26.06.2018 . Быстрый рост недорогих альтернатив, таких как ракета Falcon 9 компании SpaceX, привел к тому, что количество запусков «Протона» в данном году сократилось с восьми или около того до одного или двух.

[qz20141021-12] Фернхольц, Тим (21 октября 2014 г.). «Что потребовалось SpaceX Илона Маска, чтобы подорвать Boeing, обойти NASA и стать серьезной космической компанией». Quartz . Получено 11 ноября 2018 г. . Но SpaceX всегда считала себя технологической фирмой, и ее столкновения с NASA часто принимали форму, которую разработчики компьютеров — или кто-либо, знакомый с проблемным развертыванием healthcare.gov — признали бы как поколенческую. SpaceX следовала итеративному процессу проектирования, постоянно улучшая прототипы в ответ на тестирование. Традиционное управление продуктами требует надежного плана, выполняемого до конца, что является рецептом перерасхода средств.

[sn20150424-13] Грасс, Майк (24.04.2015). «Эволюция плана: руководители ULA излагают логику выбора конструкции Vulcan». Новости космоса . Получено 25 апреля 2015 г. 13 апреля ULA объявила о том, что будет разрабатывать ракету под названием Vulcan с использованием поэтапного подхода, первая итерация которого по сути представляет собой Atlas 5, оснащенную новой первой ступенью.