Итеративни и постепен развој

Итеративни и постепен развој је било која комбинација оба итеративна дизајна или итеративне методе и појединачне израде модела за развој софтвера. Комбинација је дугог стајања ^[1] и нашироког предлагања за велике развојне напоре. На пример, 1985. ДОД-СТД-2167А помиње (у одељку 4.1.2): "Током развоја софтвера, више од једне итерације развоја софтверског циклуса могу бити у току у исто време." и "Овај процес се може описати као" еволутивна стицања 'или' постепена изградња "приступа."Однос између итерација и корака се одређује на основу укупног процеса методологије за развој софтвера и развоја софтвера. Тачан број и природу одређеног инкрементала гради и што је поновљено биће специфична за сваки појединачни развој напора.

Итеративни и постепен развој су битни делови Модификованог водопад модела, Рационалног обједињеног процеса, Екстремног програмирања и генерално разних оквира агилног развоја софтвера.

Из тога следи сличан процес са планом ПДЦА циклуса побољшања пословног процеса.

Преглед

Поједностављена верзија типичног постепеног циклуса у агилном управљању пројектима

Основна идеја ове методе је да се развије систем кроз поновљене циклусе (итеративне) и у мањим порцијама у времену (инкременталне), омогућавајући програмерима да искористе оно што је научено током развоја ранијих делова или верзија система. Учење долази и од развоја и коришћења система, где су могући кључни кораци у процесу стартовања са једноставном реализацијом подскупа софтверских захтевима и итеративно побољшање еволуирајуће верзије док је пуни систем имплементиран. У свакој итерацији, дизајн модификације су направљене и нове функционалне способности се додају.

Сама процедура се састоји од покретања корака, корака итерације, и контролне листе пројекта. Са почетним кораком ствара базу верзију система. Циљ ове почетне имплементације је да се створи производ на који корисник може да реагује. То би требало да понуди узорак кључних аспеката проблема и да обезбеди решење које је довољно једноставно за разумевање и лаку имплементацију. Да би водили процес понављања, листа управљања пројектима је створена да садржи евиденцију о свим задацима које треба извршити. То укључује ставке као што су нове могућности да се реализују и подручја редизајна постојећег решења. Листа контроле се стално ревидира као резултат фазе анализе.

Итерација укључује редизајн и имплементација понављања треба да буде једноставана, јасна и модуларна, подршка редизајна у тој фази или као задатак додат на листу за контролу пројекта. Ниво дизајна детаља се не диктира итеративним приступом. У лаганом итеративном пројекту код може представљати главни извор документације система; Међутим, у критичном итеративном пројекту може да се користи формална документација софтверског дизајна. Анализа итерацијом заснива се на повратним информацијама о корисницима, а објектна анализа програма на располагању. То подразумева анализу структуре, модуларност, употребљивости, поузданости, ефикасности, и постизање циљева. Листа управљања пројектима је модификована у светлу анализу резултата.

Итеративни развој.

Фазе

Постепен развој сече функционалност система у инкрементима (делови). У сваком прирасту, кришка функционалности се испоручује преко крос-дисциплине рада, од захтева за распоређивање. Обједињене процесне групе у фазама: почетак, разрада, конструкција, и транзиција.

Почетак идентификује обим пројекта, услове (функционалне и нефункционалне) и ризике на високом нивоу, али довољно детаљно да се посао може проценити.
Израда доноси радну архитектуру која ублажава горње ризике и испуњава не-функционалне захтеве.
Конструкција постепено испуњава-у архитектури са производњом-спремни код произведен из анализе, дизајна, имплементације и тестирања функционалних захтева.
Транзиција доноси систем у производњи радног окружења.

Свака од фаза може бити подељена на 1 или више итерација, које су обично временски-ограничене уместо одликоване. Архитекте и аналитичари раде једну итерацију испред програмера и тестера да задрже посао..

Употреба

Многи примери ране употребе су дати у Крејг Ларман и Виктор Басили чланку "Итеративни и постепен развој: Кратка историја",^[2] са једним од најранијих бића НАСА 1960. пројекат Mercury.

Други је "рани и упечатљив пример великог IID успеха је веома срчана НАСА-иног спејс шатл софтвера-примарна авионика софтверског система, који ФСД изграђен од 1977. до 1980. године. Тим примењује IID у серији од 17 итерација више од 31 месеца, у просеку око осам недеља по итерацији.Њихова мотивација за избегавање животног циклуса водопада је да су захтеви шатл програма променили током процеса развоја софтвера ".

Неке организације, као што је америчко министарство одбране, имају предност за итеративе методологије, почевши од МИЛ-СТД-498 "јасно подстицање тековина еволуције и IID".

Садашње ДоД Упутство 5000,2, објављено 2000. године, наводи јасну предност IID: "Постоје два приступа, еволутивни и један корак [водопад], до потпуне способности. Еволуциони приступ је пожељан. ... [У овом] приступ, крајња способност достављена кориснику подељена је на два или више блокова, са повећањем корака способности ... развој софтвера ће пратити итеративне спиралне процесе развоја у које се стално проширују верзије софтвера на основу учење из ранијег развоја. Може се урадити у фазама.

Контраст са развојем Водопада

Развој Водопада завршио посао-производе пројеката широм сваке дисциплине у једном кораку пре преласка на следеће дисциплине у следећем кораку. Пословна вредност се испоручује одједном, и то само на самом крају пројекта. Праћење позади је могуће у итеративном приступу.

Смернице за имплементацију

Смернице који покрећу реализацију и анализу укључују:

Било коју потешкоћу у дизајну, кодирање и тестирање модификације треба да сигнализира потребу за редизајн или ре-кодирање.
Промене би требало да се лако уклопе у изоловане и лако да пронађу модуле. Ако то не ураде, неки редизајн је вероватно потребан.
Измене табела би требало да буду посебно лако направити. Ако није брзо и лако урађена било која модификација, редизајн је назначен.
Промене би требало да постану лакше као напредак итерација. Ако нису, постоји основни проблем као што је дизајн грешке или ширење закрпа.
Фластери обично треба да дозволе да постоји само једна или две итерације. Фластери могу бити неопходне да се избегну преобликовање током фазе имплементације.
Постојећу имплементацију треба анализирати често да се утврди колико добро се мери до циљева пројекта.
Објекте анализе програма треба користити кад год је на располагању да помогну у анализи парцијалних имплементација.
Корисничка реакција треба прикупити и анализирати назнаке недостатака у тренутној имплементацији.

Коришћење хардвера и уграђених система

Иако је термин итеративни и постепен развој покренут у софтверској индустрији, многи хардвери и уграђени напори за развој софтвера користите итеративне и инкременталне технике. На пример, велики САД сервис провајдер за лансирање United Launch Alliance (УЛА) предузео је деценијски пројекат за реструктурирање лансирања пословно-смањење две лансирне летелице на једну-коришћењем итеративног и инкременталног приступа да дођу до делимично-вишекратне употребе и много јефтинијег покретања система током наредне деценије.^[3]

Види још

Референце

'^ Larman, Craig (2003). „Iterative and Incremental Development: A Brief History” (PDF). Computer. 36 (6): 47—56. ISSN 0018-9162. doi:10.1109/MC.2003.1204375. „We were doing incremental development as early as 1957, in Los Angeles, under the direction of Bernie Dimsdale [at IBM's ServiceBureau Corporation]. He was a colleague of John von Neumann, so perhaps he learned it there, or assumed it as totally natural. I do remember Herb Jacobs (primarily, though we all participated) developing a large simulation for Motorola, where the technique used was, as far as I can tell ...”
^ Iterative and Incremental Development: A Brief History, Craig Larman and Victor Basili, IEEE Computer, June 2003
^ Gruss, Mike (24. 4. 2015). „Evolution of a Plan : ULA Execs Spell Out Logic Behind Vulcan Design Choices”. Space News. Приступљено 25. 4. 2015.

Литература

Dr. Alistair Cockburn (2008). „Using Both Incremental and Iterative Development” (PDF). STSC CrossTalk. USAF Software Technology Support Center. 21 (5): 27—30. ISSN 2160-1593. Архивирано из оригинала (PDF) 26. 05. 2012. г. Приступљено 20. 7. 2011.
Craig Larman, Victor R. Basili (2003). „Iterative and Incremental Development: A Brief History” (PDF). IEEE Computer. IEEE Computer Society. 36 (6): 47—56. ISSN 0018-9162. doi:10.1109/MC.2003.1204375. Приступљено 10. 1. 2009.

[1] '^ Larman, Craig (2003). „Iterative and Incremental Development: A Brief History” (PDF). Computer. 36 (6): 47—56. ISSN 0018-9162. doi:10.1109/MC.2003.1204375. „We were doing incremental development as early as 1957, in Los Angeles, under the direction of Bernie Dimsdale [at IBM's ServiceBureau Corporation]. He was a colleague of John von Neumann, so perhaps he learned it there, or assumed it as totally natural. I do remember Herb Jacobs (primarily, though we all participated) developing a large simulation for Motorola, where the technique used was, as far as I can tell ...”

[2] Iterative and Incremental Development: A Brief History, Craig Larman and Victor Basili, IEEE Computer, June 2003

[sn20150424-3] Gruss, Mike (24. 4. 2015). „Evolution of a Plan : ULA Execs Spell Out Logic Behind Vulcan Design Choices”. Space News. Приступљено 25. 4. 2015.

[1]

[2]

[3]