Итеративная и инкрементальная разработка

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

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

Обзор

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

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

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

Фазы

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

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

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

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

Многие примеры раннего использования представлены в статье Крейга Лармана и Виктора Базили «Итеративная и поэтапная разработка: краткая история». ^[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]

Контраст с разработкой Waterfall

Основной причиной неудач проектов разработки программного обеспечения является выбор модели, поэтому к нему следует подходить с большой осторожностью. ^{[ нечеткий ]}^[7]

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

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

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

Хотя термин «итеративная и инкрементная разработка» появился в индустрии программного обеспечения, во многих аппаратного и встроенного программного обеспечения разработках используются итеративные и инкрементные методы.

Примеры этого можно увидеть в ряде отраслей. Одним из секторов, на который в последнее время существенно повлиял этот сдвиг в мышлении, стала индустрия космических запусков , в которой действуют существенные новые конкурентные силы, вызванные более быстрыми и обширными технологическими инновациями, вызванными образованием частных компаний, занимающихся космическими запусками. Эти компании, такие как SpaceX ^[8] и Ракетная лаборатория , ^[9] в настоящее время оба предоставляют коммерческие услуги по запуску на орбиту за последнее десятилетие, что до десятилетия делали только шесть стран. ^[10] назад. Новые инновации в подходах к разработке технологий, ценообразовании и предложениях услуг, включая существующую только с 2016 года возможность летать в космос на ранее летавшей (многоразовой) ступени ракеты-носителя , еще больше снижают цену получения доступа в космос. ^[11]^[8]

SpaceX открыто заявляет о своих усилиях по внедрению итеративных методов проектирования в космическую отрасль и использует эту технику в космических кораблях, ракетах-носителях, электронике и авионике, а также в эксплуатации летного оборудования. ^[12]

начинают менять свою практику долгосрочного развития с государственными учреждениями Поскольку отрасль начала меняться, другие конкуренты по запуску также . Например, крупный американский поставщик услуг по запуску United Launch Alliance (ULA) в 2015 году начал десятилетний проект по реструктуризации своего пускового бизнеса — сокращению двух ракет -носителей до одной — с использованием итеративного и поэтапного подхода для перехода к частично многоразовому использованию ракеты -носителя. и гораздо более дешевая система запуска в течение следующего десятилетия. ^[13]

См. также

Примечания

^ Ларман, Крейг (июнь 2003 г.). «Итеративная и поэтапная разработка: краткая история» (PDF) . Компьютер . 36 (6): 47–56. дои : 10.1109/MC.2003.1204375 . ISSN 0018-9162 . S2CID 9240477 . Мы занимались поэтапной разработкой еще в 1957 году в Лос-Анджелесе под руководством Берни Димсдейла [в IBM ServiceBureau Corporation]. Он был коллегой Джона фон Неймана , так что, возможно, он научился этому там или считал это совершенно естественным. Я помню, как Херб Джейкобс (в первую очередь, хотя мы все участвовали) разрабатывал большую симуляцию для Motorola, где, насколько я могу судить, использовалась техника…»
^ DOD-STD-2167 Разработка программного обеспечения для оборонных систем (4 июня 1985 г.) на Everyspec.com
^ Фарчич, Виктор (21 января 2014 г.). «Модели разработки программного обеспечения: итеративная и поэтапная разработка» . Технологические беседы .
^ Jump up to: ^а ^б Итеративная и поэтапная разработка: краткая история , Крейг Ларман и Виктор Базили, IEEE Computer, июнь 2003 г.
^ Кендалл, Фрэнк; Гилмор, Дж. Майкл; Халворсен, Терри (2 февраля 2017 г.). «Работа системы оборонных закупок» (PDF) . Выпуски Министерства обороны США . Заместитель министра обороны по закупкам, технологиям и логистике. стр. 12–14. Архивировано из оригинала (PDF) 9 августа 2017 г. Проверено 9 августа 2017 г.
^ ЮСАИД. «Эксплуатационная политика программного цикла главы 201 ADS» . Архивировано 23 октября 2019 г. на Wayback Machine . Проверено 19 апреля 2017 г.
^ Кудряшов Алексей (29 февраля 2024 г.). «Инкрементная и каскадная модель в разработке программного обеспечения» . Cyfrania: Разработка и консалтинг программного обеспечения на заказ . Выбор инкрементной модели для проектов со стабильными требованиями может привести к расширению масштабов и увеличению сложности, тогда как выбор каскадной модели может привести к негибкости и неэффективности адаптации к изменениям.
^ Jump up to: ^а ^б Бельфиоре, Майкл (9 декабря 2013 г.). «Ракетчик» . Внешняя политика . Архивировано из оригинала 10 декабря 2013 года . Проверено 11 ноября 2018 г.
^ «Эксклюзивный взгляд изнутри на ранее секретную новую мегафабрику Rocket Lab!» . Каждый день космонавт . 11 октября 2018 г. Архивировано из оригинала 12 октября 2018 г. Проверено 11 ноября 2018 г.
^ Кларк, Стивен (28 сентября 2008 г.). «Наконец-то сладкий успех ракеты Falcon 1» . Космический полет сейчас . Проверено 11 ноября 2018 г. первая частная ракета на жидком топливе, успешно достигшая орбиты.
^ Бергер, Эрик (25 июня 2018 г.). «Российская ракета «Протон», предшествовавшая «Аполлону», наконец перестанет летать. Факторами, способствующими этому, являются технические проблемы и рост популярности SpaceX» . АрсТехика . Проверено 26 июня 2018 г. Быстрый рост недорогих альтернатив, таких как ракета Falcon 9 от SpaceX, привел к тому, что количество запусков «Протонов» в данном году сократилось с восьми или около того до одного или двух.
^ Фернхольц, Тим (21 октября 2014 г.). «Что потребовалось SpaceX Илона Маска, чтобы разрушить Boeing, обойти НАСА и стать серьёзной космической компанией» . Кварц . Проверено 11 ноября 2018 г. Но SpaceX всегда считала себя технологической фирмой, и ее конфликты с НАСА часто принимали форму, которую разработчики компьютеров (или любой, кто знаком с проблемным внедрением Health.gov) признали бы поколением. SpaceX следовала итеративному процессу проектирования, постоянно совершенствуя прототипы в ходе испытаний. Традиционное управление продуктом требует четкого плана, выполняемого до конца, что является рецептом перерасхода средств.
^ Грусс, Майк (24 апреля 2015 г.). «Эволюция плана: руководители ULA объясняют логику выбора дизайна Vulcan» . Космические новости . Проверено 25 апреля 2015 г. Заявление ULA от 13 апреля о том, что оно разработает ракету под названием Vulcan, используя поэтапный подход, первая итерация которого по сути представляет собой Atlas 5, оснащенную новой первой ступенью.

Ссылки

Доктор Алистер Кокберн (май 2008 г.). «Использование как поэтапной, так и итеративной разработки» (PDF) . STSC CrossTalk . 21 (5). ВВС США Центр поддержки программных технологий : 27–30. ISSN 2160-1593 . Архивировано из оригинала (PDF) 26 мая 2012 г. Проверено 20 июля 2011 г.
Крейг Ларман, Виктор Р. Базили (июнь 2003 г.). «Итеративная и поэтапная разработка: краткая история» (PDF) . IEEE-компьютер . 36 (6). Компьютерное общество IEEE: 47–56. дои : 10.1109/MC.2003.1204375 . ISSN 0018-9162 . S2CID 9240477 . Проверено 10 января 2009 г.

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

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

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

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

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

[6] ЮСАИД. «Эксплуатационная политика программного цикла главы 201 ADS» . Архивировано 23 октября 2019 г. на Wayback Machine . Проверено 19 апреля 2017 г.

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

[fp20131209-8] Jump up to: ^а ^б Бельфиоре, Майкл (9 декабря 2013 г.). «Ракетчик» . Внешняя политика . Архивировано из оригинала 10 декабря 2013 года . Проверено 11 ноября 2018 г.

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

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

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

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

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

[1]

[2]

[3]

[4]

[5]

[6]

[7]

[8]

[9]

[10]

[11]

[12]

[13]