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

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

Использование этого термина началось в разработке программного обеспечения с давней комбинации двух терминов: итеративный и инкрементный. ^[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 г.). «Модели разработки программного обеспечения: итеративная и поэтапная разработка» . Технологические беседы .
^ Перейти обратно: ^а ^б Итеративная и поэтапная разработка: краткая история , Крейг Ларман и Виктор Базили, IEEE Computer, июнь 2003 г.
^ Кендалл, Фрэнк; Гилмор, Дж. Майкл; Халворсен, Терри (2 февраля 2017 г.). «Работа системы оборонных закупок» (PDF) . Выпуски Министерства обороны США . Заместитель министра обороны по закупкам, технологиям и логистике. стр. 12–14. Архивировано из оригинала (PDF) 9 августа 2017 г. Проверено 9 августа 2017 г.
^ ЮСАИД. «Эксплуатационная политика программного цикла главы 201 ADS». Архивировано 23 октября 2019 г. на Wayback Machine . Проверено 19 апреля 2017 г.
^ Кудряшов Алексей (29 февраля 2024 г.). «Инкрементная и каскадная модель в разработке программного обеспечения» . Cyfrania: Разработка программного обеспечения и консалтинг на заказ . Выбор инкрементальной модели для проектов со стабильными требованиями может привести к расширению масштабов и увеличению сложности, тогда как выбор каскадной модели может привести к негибкости и неэффективности адаптации к изменениям.
^ Перейти обратно: ^а ^б Бельфиоре, Майкл (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] Перейти обратно: ^а ^б Итеративная и поэтапная разработка: краткая история , Крейг Ларман и Виктор Базили, 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] Перейти обратно: ^а ^б Бельфиоре, Майкл (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]