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

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

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

Использование этого термина началось в разработке программного обеспечения , причем давняя комбинация двух терминов «итеративный » и «инкрементный» ^[1] широко предлагалась для крупных проектов разработки. Например, в DOD-STD-2167 ^[2] 1985 года упоминается (в разделе 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] и Rocket Lab , ^[9] в настоящее время обе предоставляют коммерческие услуги по запуску на орбиту за последнее десятилетие, что до десяти лет назад ^[10] назад делали только шесть стран. Новые инновации в подходах к разработке технологий, ценообразовании и предложениях услуг, включая существующую только с 2016 года возможность летать в космос на ранее летавшей (многоразовой) ступени ракеты-носителя , еще больше снижают цену получения доступа в космос. ^{[11] [8]}

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

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

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

• Адаптивное управление
• Гибкая разработка программного обеспечения
• Непрерывная интеграция
• DevOps § Постепенное внедрение
• Метод разработки динамических систем
• Целенаправленный процесс разработки программного обеспечения
• Интерактивный дизайн
• Кайдзен
• Платформа решений Microsoft
• Объектно-ориентированный анализ и проектирование
• OpenUP/Базовый
• ПДКА
• Быстрая разработка приложений
• Выпускайте раньше, выпускайте чаще

Примечания

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 г.). «Модели разработки программного обеспечения: итеративная и поэтапная разработка». Технологические беседы .
4. Итеративная и поэтапная разработка: краткая история , Крейг Ларман и Виктор Базили, IEEE Computer, июнь 2003 г.
5. Кендалл, Фрэнк; Гилмор, Дж. Майкл; Халворсен, Терри (2 февраля 2017 г.). «Работа системы оборонных закупок» (PDF) . Выпуски Министерства обороны США . Заместитель министра обороны по закупкам, технологиям и логистике. стр. 12–14. Архивировано из оригинала (PDF) 9 августа 2017 г. Проверено 9 августа 2017 г.
6. ЮСАИД. «Эксплуатационная политика программного цикла главы 201 ADS». Архивировано 23 октября 2019 г. на Wayback Machine . Проверено 19 апреля 2017 г.
7. «Разница между водопадом и инкрементной моделью». 19 мая 2016 г.^{[ постоянная мертвая ссылка ]}
8. Бельфиоре, Майкл (9 декабря 2013 г.). «Ракетчик». Внешняя политика . Архивировано из оригинала 10 декабря 2013 года . Проверено 11 ноября 2018 г.
9. «Эксклюзивный взгляд изнутри на ранее секретную новую мегафабрику Rocket Lab!». Каждый день космонавт . 11 октября 2018 г. Архивировано из оригинала 12 октября 2018 г. Проверено 11 ноября 2018 г.
10. Кларк, Стивен (28 сентября 2008 г.). «Наконец-то сладкий успех ракеты Falcon 1». Космический полет сейчас . Проверено 11 ноября 2018 г. первая частная ракета на жидком топливе, успешно достигшая орбиты.
11. Бергер, Эрик (25 июня 2018 г.). «Российская ракета «Протон», предшествовавшая «Аполлону», наконец перестанет летать. Факторами, способствующими этому, являются технические проблемы и подъем SpaceX». АрсТехика . Проверено 26 июня 2018 г. Быстрый рост недорогих альтернатив, таких как ракета Falcon 9 от SpaceX, привел к тому, что количество запусков «Протонов» в данном году сократилось с восьми или около того до одного или двух.
12. Фернхольц, Тим (21 октября 2014 г.). «Что потребовалось SpaceX Илона Маска, чтобы разрушить Boeing, обойти НАСА и стать серьезной космической компанией». Кварц . Проверено 11 ноября 2018 г. Но SpaceX всегда считала себя технологической фирмой, и ее столкновения с НАСА часто принимали форму, которую разработчики компьютеров (или любой, кто знаком с проблемным внедрением Health.gov) признали бы поколением. SpaceX следовала итеративному процессу проектирования, постоянно совершенствуя прототипы в ходе испытаний. Традиционное управление продуктом требует четкого плана, выполняемого до конца, что является рецептом перерасхода средств.
13. Грусс, Майк (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-компьютер . Компьютерное общество IEEE. 36 (6): 47–56. дои : 10.1109/MC.2003.1204375. ISSN  0018-9162. S2CID  9240477 . Проверено 10 января 2009 г.