Итеративная и инкрементальная разработка - Iterative and incremental development

Итеративная и инкрементальная разработка любая комбинация обоих итеративный дизайн или итерационный метод и модель инкрементальной сборки для развитие.

Использование термина началось в разработка программного обеспечения, с давним сочетанием двух терминов итеративный и добавочный[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]

Например, Развитие водопада парадигма завершает рабочие продукты проекта каждой дисциплины за один шаг, прежде чем перейти к следующей дисциплине на следующем шаге. Бизнес-ценность предоставляется сразу и только в самом конце проекта, тогда как откат[требуется разъяснение ] возможно при итеративном подходе. Сравнивая два подхода, начинают вырисовываться некоторые закономерности:[нужна цитата ]

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

Рекомендации по реализации

Рекомендации по внедрению и анализу программного обеспечения включают:[нужна цитата ]

  • Любые трудности при проектировании, кодировании и тестировании модификации должны сигнализировать о необходимости перепроектирования или перекодирования.
  • Модификации должны легко помещаться в изолированные и легко обнаруживаемые модули. Если они этого не сделают, возможно, потребуется некоторый редизайн.
  • Внесение изменений в таблицы должно быть особенно простым. Если какое-либо изменение таблицы не выполняется быстро и легко, указывается изменение дизайна.
  • По мере выполнения итераций вносить изменения будет проще. Если это не так, существует основная проблема, такая как недостаток дизайна или распространение патчи.
  • Патчи обычно должны существовать только в течение одной или двух итераций. Исправления могут потребоваться, чтобы избежать изменения дизайна на этапе реализации.
  • Существующую реализацию следует часто анализировать, чтобы определить, насколько хорошо она соответствует целям проекта.
  • Средства программного анализа должны использоваться всякий раз, когда они доступны, чтобы помочь в анализе частичных реализаций.
  • Реакцию пользователей следует запрашивать и анализировать на предмет выявления недостатков в текущей реализации.

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

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

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

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

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

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

Заметки

  1. ^ Ларман, Крейг (июнь 2003 г.). «Итеративная и инкрементальная разработка: краткая история» (PDF). Компьютер. 36 (6): 47–56. Дои:10.1109 / MC.2003.1204375. ISSN  0018-9162. Мы занимались инкрементной разработкой еще в 1957 году в Лос-Анджелесе под руководством Берни Димсдейла [из IBM's ServiceBureau Corporation]. Он был коллегой Джон фон Нейман, так что, возможно, он выучил это там или считал это совершенно естественным. Я действительно помню, как Херб Джейкобс (в первую очередь, хотя мы все участвовали) разрабатывал большую симуляцию для Motorola, в которой использовалась техника, насколько я могу судить ... '
  2. ^ DOD-STD-2167 Разработка программного обеспечения для систем защиты (4 июня 1985 г.) на everyspec.com
  3. ^ Фарчич, Виктор (21 января 2014 г.). «Модели разработки программного обеспечения: итеративная и инкрементная разработка». Беседы о технологиях.
  4. ^ а б Итеративная и инкрементальная разработка: краткая история, Крейг Ларман и Виктор Басили, IEEE Computer, июнь 2003 г.
  5. ^ Кендалл, Фрэнк; Гилмор, Дж. Майкл; Халворсен, Терри (02.02.2017). «Работа системы оборонных закупок» (PDF). Выпуски DoD. Заместитель министра обороны по закупкам, технологиям и логистике. С. 12–14. Архивировано из оригинал (PDF) на 2017-08-09. Получено 2017-08-09.
  6. ^ ТЫ СКАЗАЛ. «ADS Глава 201 Операционная политика программного цикла». Проверено 19 апреля 2017 г.
  7. ^ «Разница между водопадом и инкрементальной моделью». 19 мая 2016 года.[постоянная мертвая ссылка ]
  8. ^ а б Бельфиоре, Майкл (9 декабря 2013 г.). "Ракетчик". Внешняя политика. Получено 11 ноября 2018.
  9. ^ «Эксклюзивный взгляд изнутри на ранее секретную новую мегафабрику Rocket Lab!». Повседневный космонавт. 11 октября 2018 г.. Получено 11 ноября 2018.
  10. ^ Кларк, Стивен (28 сентября 2008 г.). «Наконец-то сладкий успех для ракеты Falcon 1». Космический полет сейчас. Получено 11 ноября 2018. первая частная ракета на жидком топливе, успешно достигшая орбиты.
  11. ^ Бергер, Эрик (25.06.2018). «Российская ракета« Протон », предшествовавшая« Аполлону », наконец, прекратит полеты. Технические проблемы, рост SpaceX - это способствующие факторы». arsTechica. Получено 2018-06-26. Быстрый рост недорогих альтернатив, таких как ракета SpaceX Falcon 9, привел к тому, что количество запусков Proton в конкретный год сократилось с восьми или около того до одного или двух.
  12. ^ Фернхольц, Тим (21 октября 2014 г.). «Что потребовалось SpaceX Илона Маска, чтобы разрушить Boeing, обойти НАСА и стать серьезной космической компанией». Кварцевый. Получено 11 ноября 2018. Но SpaceX всегда считала себя технологической фирмой, и ее столкновения с НАСА часто принимали форму, которую компьютерные разработчики - или любой, кто знаком с проблемным развертыванием healthcare.gov - признали бы поколениями. SpaceX следовала итеративному процессу проектирования, постоянно улучшая прототипы в ответ на испытания. Традиционное управление продуктом требует четкого и полного выполнения плана, что является рецептом для перерасхода средств.
  13. ^ Грусс, Майк (2015-04-24). «Эволюция плана: руководители ULA объясняют логику выбора дизайна Vulcan». Космические новости. Получено 25 апреля 2015. ULA объявило 13 апреля, что разработает ракету, получившую название Vulcan, с использованием поэтапного подхода, первая итерация которого, по сути, представляет собой Atlas 5 с новой первой ступенью.

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