Итеративная и инкрементальная разработка
Итеративная и инкрементная разработка — это любая комбинация итеративного проектирования (или итеративного метода) и модели инкрементной сборки для разработки .
Использование этого термина началось в разработке программного обеспечения с давней комбинации двух терминов: итеративный и инкрементальный. [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]
См. также
[ редактировать ]- Адаптивное управление
- Гибкая разработка программного обеспечения
- Непрерывная интеграция
- DevOps § Постепенное внедрение
- Метод разработки динамических систем
- Целенаправленный процесс разработки программного обеспечения
- Дизайн взаимодействия
- Кайдзен
- Платформа решений Microsoft
- Объектно-ориентированный анализ и проектирование
- ПДКА
- Быстрая разработка приложений
- Выпускайте раньше, выпускайте чаще
Примечания
[ редактировать ]- ^ Ларман, Крейг (июнь 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, оснащенную новой первой ступенью.
Эта статья включает список общих ссылок , но в ней отсутствуют достаточные соответствующие встроенные цитаты . ( сентябрь 2010 г. ) |
Ссылки
[ редактировать ]- Доктор Алистер Кокберн (май 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 г.