Итеративная и инкрементная разработка - это любая комбинация итеративного проектирования или итеративного метода и модели инкрементальной сборки для разработки .
Использование этого термина началось в разработке программного обеспечения , с давнишнего сочетания двух терминов итеративный и инкрементный [1], которые широко предлагались для крупных усилий по разработке. Например, 1985 DOD-STD-2167 [2] упоминает (в разделе 4.1.2): «Во время разработки программного обеспечения может выполняться более одной итерации цикла разработки программного обеспечения одновременно». и «Этот процесс можно описать как подход« эволюционного приобретения »или« постепенного наращивания »». В программном обеспечении взаимосвязь между итерациями и приращениями определяется общим процессом разработки программного обеспечения .
| Разработка программного обеспечения |
|---|
Обзор [ править ]
Основная идея, лежащая в основе этого метода, заключается в разработке системы посредством повторяющихся циклов (итеративно) и небольшими частями за раз (инкрементально), что позволяет разработчикам программного обеспечения использовать преимущества того, что было изучено во время разработки более ранних частей или версий системы. Обучение происходит как при разработке, так и при использовании системы, где возможные ключевые этапы процесса начинаются с простой реализации подмножества требований к программному обеспечению и итеративно улучшают развивающиеся версии до тех пор, пока не будет реализована вся система. На каждой итерации вносятся изменения в дизайн и добавляются новые функциональные возможности. [3]
Сама процедура состоит из шага инициализации, шага итерации и контрольного списка проекта. На этапе инициализации создается базовая версия системы. Цель этой первоначальной реализации - создать продукт, на который пользователь может реагировать. Он должен предлагать выборку ключевых аспектов проблемы и предлагать решение, достаточно простое для понимания и легкого внедрения. Для управления итерационным процессом создается контрольный список проекта, содержащий записи всех задач, которые необходимо выполнить. Он включает в себя такие элементы, как новые функции, которые будут реализованы, и области редизайна существующего решения. Контрольный список постоянно обновляется в результате фазы анализа.
Итерация включает в себя редизайн, и реализация итерации должна быть простой, понятной и модульной, поддерживая редизайн на этом этапе или в качестве задачи, добавленной в контрольный список проекта. [ требуется пояснение ] Уровень детализации проекта не диктуется итеративным подходом. В облегченном итеративном проекте код может представлять собой основной источник документации системы; однако в критически важном итеративном проекте можно использовать формальный документ по разработке программного обеспечения . Анализ итерации основан на отзывах пользователей и доступных средствах анализа программы. Включает в себя анализ структуры, модульности, удобства использования., надежность, эффективность и достижение целей. Контрольный список проекта модифицируется с учетом результатов анализа.
Фазы [ править ]
Инкрементальная разработка разбивает функциональность системы на инкременты (части). В каждом приращении часть функциональности предоставляется через междисциплинарную работу, от требований до развертывания . В унифицированном процессе приращение групп / итерации в фазы: начало, разработка, строительство и переход.
- Начало определяет объем проекта, требования (функциональные и нефункциональные) и риски на высоком уровне, но достаточно подробно, чтобы можно было оценить работу.
- Разработка обеспечивает рабочую архитектуру, которая снижает основные риски и выполняет нефункциональные требования.
- Построение постепенно заполняет архитектуру готовым к производству кодом, полученным в результате анализа, проектирования, реализации и тестирования функциональных требований.
- Transition вводит систему в производственную операционную среду.
Каждую из фаз можно разделить на 1 или несколько итераций, которые обычно ограничены по времени, а не по функциям. Архитекторы и аналитики опережают разработчиков и тестировщиков на одну итерацию, чтобы заполнить список невыполненных работ.
Использование / История [ править ]
Многие примеры раннего использования представлены в статье Крейга Лармана и Виктора Базили «Итеративное и инкрементное развитие: краткая история» [4], одним из самых ранних из которых является проект НАСА « Меркурий » 1960-х годов .
Некоторые из этих инженеров Mercury позже сформировали новое подразделение в IBM , где «еще одним ранним и ярким примером крупного успеха IID [было] самое сердце программного обеспечения космического шаттла НАСА - основной системы программного обеспечения авионики, которую [они] построили с 1977 года. по 1980 год. Команда применяла IID в серии из 17 итераций в течение 31 месяца, в среднем около восьми недель на итерацию. Их мотивация избежать жизненного цикла водопада заключалась в том, что требования программы шаттла менялись в процессе разработки программного обеспечения ». [4]
Некоторые организации, такие как Министерство обороны США, отдают предпочтение итерационным методологиям, начиная с MIL-STD-498, «явно поощряющего эволюционное приобретение и IID».
В инструкции DoD 5000.2, выпущенной в 2000 году, явно отдавалось предпочтение IID:
Есть два подхода, эволюционный и пошаговый [водопад], к полной возможности. Предпочтительно эволюционный подход. … [В этом] подходе конечные возможности, предоставляемые пользователю, делятся на два или более блока с увеличивающимися приращениями возможностей ... Разработка программного обеспечения должна следовать итеративному спиральному процессу разработки, в котором постоянно расширяющиеся версии программного обеспечения основаны на извлечении уроков из опыта. более ранняя разработка. Это также можно делать поэтапно.
Последние версии DoDI 5000.02 больше не относятся к «спиральной разработке», но отстаивают общий подход как основу для программно-интенсивных программ разработки / закупок. [5] Кроме того, Агентство США по международному развитию (USAID) также использует итеративный и поэтапный подход к своему программному циклу для разработки, мониторинга, оценки, изучения и адаптации проектов международного развития с подходом к управлению проектами, который фокусируется на включении стратегии сотрудничества, обучения и адаптации для повторения и адаптации программирования. [6]
Контраст с разработкой Waterfall [ править ]
| Парадигмы программирования |
|---|
|
Основная причина неудач проектов по разработке программного обеспечения - выбор модели, поэтому к нему следует подходить с большой осторожностью. [ расплывчато ] [7]
Например, парадигма разработки Waterfall завершает рабочие продукты проекта каждой дисциплины за один шаг перед переходом к следующей дисциплине на следующем шаге. Ценность для бизнеса предоставляется сразу и только в самом конце проекта, тогда как при итеративном подходе возможен возврат [ требуется пояснение ] . Сравнивая два подхода, начинают выявляться некоторые закономерности: [ необходима цитата ]
- Вовлеченность пользователя : в каскадной модели пользователь участвует в двух этапах модели: требования и приемочное тестирование и, возможно, создание учебных материалов для пользователей. Тогда как в инкрементальной модели клиент участвует на каждом этапе.
- Вариативность : программное обеспечение предоставляется пользователю только после завершения этапа сборки жизненного цикла для пользовательского приемочного тестирования. С другой стороны, каждое приращение доставляется пользователю, и после одобрения пользователя разработчику разрешается переходить к следующему модулю.
- Человеческие ресурсы : в инкрементной модели потенциально требуется меньше персонала по сравнению с водопадной моделью.
- Ограничение по времени : рабочий продукт доставляется через несколько месяцев, в то время как в инкрементальной модели продукт предоставляется пользователю в течение нескольких недель.
- Размер проекта : модель водопада не подходит для небольших проектов, в то время как инкрементная модель подходит как для небольших, так и для крупных проектов.
Рекомендации по реализации [ править ]
Рекомендации по внедрению и анализу программного обеспечения включают: [ необходима цитата ]
- Любые трудности в дизайне, кодировании и тестировании модификации должны сигнализировать о необходимости перепроектирования или перекодирования.
- Модификации должны легко помещаться в изолированные и легко обнаруживаемые модули. Если они этого не сделают, возможно, потребуется некоторый редизайн.
- Внесение изменений в таблицы должно быть особенно простым. Если какое-либо изменение таблицы не выполняется быстро и легко, указывается изменение дизайна.
- По мере выполнения итераций вносить изменения будет проще. Если это не так, существует основная проблема, такая как недостаток дизайна или большое количество исправлений .
- Исправлениям обычно разрешается существовать только в течение одной или двух итераций. Исправления могут потребоваться, чтобы избежать переделки на этапе реализации.
- Существующую реализацию следует часто анализировать, чтобы определить, насколько хорошо она соответствует целям проекта.
- Средства программного анализа должны использоваться всякий раз, когда они доступны, чтобы помочь в анализе частичных реализаций.
- Реакцию пользователей следует запрашивать и анализировать на предмет выявления недостатков в текущей реализации.
Использование в аппаратных и встроенных системах [ править ]
Хотя термин « итеративная и инкрементная разработка» появился в индустрии программного обеспечения, во многих разработках аппаратного и встроенного программного обеспечения используются итеративные и инкрементные методы.
Примеры этого можно увидеть в ряде отраслей. Один из секторов, на который в последнее время существенно повлиял этот сдвиг мышления, - это индустрия космических запусков , где действуют новые существенные конкурентные силы, вызванные более быстрыми и обширными технологическими инновациями, вызванными образованием частных компаний, занимающихся запусками в космос. Эти компании, такие как SpaceX [8] и Rocket Lab , [9] в настоящее время предоставляют услуги коммерческого орбитального запуска за последнее десятилетие, что сделали только шесть стран до этого десятилетия [10].тому назад. Новые инновации в подходах к разработке технологий, ценообразовании и предложениях услуг, в том числе возможность, которая существовала только с 2016 года, летать в космос на ранее использовавшейся (многоразовой) ступени ускорителя, что еще больше снижает стоимость доступа в космос. [11] [8]
SpaceX открыто заявляет о своих усилиях по внедрению методов итеративного проектирования в космическую отрасль и использует эту технику на космических кораблях, ракетах-носителях, электронике и авионике, а также в операциях с эксплуатационным летным оборудованием. [12]
По мере того, как отрасль начала меняться, другие конкуренты, запускающие запуск, также начинают менять свои методы долгосрочного развития с государственными учреждениями . Например, крупный американский провайдер пусковых услуг United Launch Alliance (ULA) в 2015 году начал десятилетний проект по реструктуризации своего стартового бизнеса - сокращение двух пусковых аппаратов до одного - с использованием итеративного и поэтапного подхода для перехода к частичному повторному использованию и гораздо более дешевую систему запуска в течение следующего десятилетия. [13]
См. Также [ править ]
- Адаптивное управление
- Гибкая разработка программного обеспечения
- Непрерывная интеграция
- DevOps § Постепенное внедрение
- Метод разработки динамических систем
- Целеустремленный процесс разработки программного обеспечения
- Интерактивный дизайн
- Кайдзен
- Платформа решений Microsoft
- Объектно-ориентированный анализ и дизайн
- OpenUP / Basic
- PDCA
- Быстрая разработка приложений
- Выпускайте раньше, выпускайте часто
Заметки [ править ]
- ^ Ларман, Крейг (июнь 2003 г.). «Итеративная и инкрементальная разработка: краткая история» (PDF) . Компьютер . 36 (6): 47–56. DOI : 10,1109 / MC.2003.1204375 . ISSN 0018-9162 . S2CID 9240477 .
Мы занимались инкрементальной разработкой еще в 1957 году в Лос-Анджелесе под руководством Берни Димсдейла [из IBM's ServiceBureau Corporation]. Он был коллегой Джона фон Неймана., так что, возможно, он выучил это там или считал это совершенно естественным. Я действительно помню, как Херб Джейкобс (в первую очередь, хотя мы все участвовали) разрабатывал большую симуляцию для Motorola, в которой использовалась техника, насколько я могу судить ... '
- ^ DOD-STD-2167 Разработка программного обеспечения для оборонных систем (4 июня 1985 г.) на everyspec.com
- ^ Farcic, Виктор (21 января 2014). «Модели разработки программного обеспечения: итеративная и инкрементная разработка» . Технологии разговоров .
- ^ a b Итеративное и постепенное развитие: краткая история , Крейг Ларман и Виктор Басили, IEEE Computer, июнь 2003 г.
- ^ Кендалл, Фрэнк; Гилмор, Дж. Майкл; Халворсен, Терри (02.02.2017). «Работа системы оборонных закупок» (PDF) . Проблемы Министерства Обороны . Заместитель министра обороны по закупкам, технологиям и логистике. С. 12–14. Архивировано из оригинального (PDF) 09.08.2017 . Проверено 9 августа 2017 .
- ^ USAID. «ADS Глава 201 Операционная политика программного цикла» . Проверено 19 апреля 2017 г.
- ^ «Разница между водопадом и инкрементальной моделью» . 19 мая 2016 года.[ постоянная мертвая ссылка ]
- ^ a b Белфиоре, Майкл (9 декабря 2013 г.). «Ракетчик» . Внешняя политика . Проверено 11 ноября 2018 года .
- ^ "Эксклюзивный взгляд на ранее секретную новую Mega Factory Rocket Lab!" . Повседневный космонавт . 11 октября 2018 . Проверено 11 ноября 2018 года .
- ↑ Кларк, Стивен (28 сентября 2008 г.). «Наконец-то сладкий успех для ракеты Falcon 1» . Космический полет сейчас . Проверено 11 ноября 2018 года .
первая частная ракета на жидком топливе, успешно достигшая орбиты.
- ^ Бергер, Эрик (2018-06-25). «Российская ракета« Протон », которая предшествовала« Аполлону », наконец, прекратит полеты. Технические проблемы, рост SpaceX - это способствующие факторы» . arsTechica . Проверено 26 июня 2018 .
Быстрый рост недорогих альтернатив, таких как ракета SpaceX Falcon 9, привел к тому, что количество запусков Proton в конкретный год сократилось с восьми или около того до одного или двух.
- ^ Fernholz, Тим (21 октября 2014). «Что потребовалось SpaceX Илона Маска, чтобы разрушить Boeing, обойти NASA и стать серьезной космической компанией» . Кварц . Проверено 11 ноября 2018 года .
Но SpaceX всегда считала себя технологической фирмой, и ее столкновения с НАСА часто принимали форму, которую разработчики компьютеров - или любой, кто знаком с проблемным развертыванием healthcare.gov - признали бы поколениями. SpaceX следовала итеративному процессу проектирования, постоянно улучшая прототипы в ответ на испытания. Традиционное управление продуктом требует четкого и полного выполнения плана - рецепта перерасхода средств.
- ^ Gruss, Майк (2015-04-24). «Эволюция плана: руководители ULA объясняют логику выбора дизайна Vulcan» . Космические новости . Проверено 25 апреля 2015 года .
ULA объявило 13 апреля, что разработает ракету, получившую название Vulcan, с использованием поэтапного подхода, первая итерация которого, по сути, представляет собой Atlas 5 с новой первой ступенью.
 | Эта статья включает в себя список общих ссылок , но он остается в значительной степени непроверенным, поскольку в нем отсутствует достаточное количество соответствующих встроенных ссылок . ( Сентябрь 2010 г. ) ( Узнайте, как и когда удалить этот шаблон сообщения ) |
Ссылки [ править ]
- Доктор Алистер Кокберн (май 2008 г.). «Использование как инкрементальной, так и итеративной разработки» (PDF) . STSC CrossTalk . Центр поддержки программных технологий USAF . 21 (5): 27–30. ISSN 2160-1593 . Архивировано из оригинального (PDF) 26 мая 2012 года . Проверено 20 июля 2011 .
- Крейг Ларман, Виктор Р. Базили (июнь 2003 г.). «Итеративная и инкрементальная разработка: краткая история» (PDF) . Компьютер IEEE . Компьютерное общество IEEE. 36 (6): 47–56. DOI : 10,1109 / MC.2003.1204375 . ISSN 0018-9162 . S2CID 9240477 . Проверено 10 января 2009 .
| vтеПрограммная инженерия | |||||||
|---|---|---|---|---|---|---|---|
| Поля |
| ||||||
| Концепции |
| ||||||
| Ориентации |
| ||||||
| Модели |
| ||||||
| Инженеры- программисты |
| ||||||
| Связанные поля |
| ||||||
| |||||||
Категория
Commons