Iterativni i postepen razvoj

Iterativni i postepen razvoj je bilo koja kombinacija oba iterativna dizajna ili iterativne metode i pojedinačne izrade modela za razvoj softvera. Kombinacija je dugog stajanja ^[1] i naširokog predlaganja za velike razvojne napore. Na primer, 1985. DOD-STD-2167A pominje (u odeljku 4.1.2): "Tokom razvoja softvera, više od jedne iteracije razvoja softverskog ciklusa mogu biti u toku u isto vreme." i "Ovaj proces se može opisati kao" evolutivna sticanja 'ili' postepena izgradnja "pristupa."Odnos između iteracija i koraka se određuje na osnovu ukupnog procesa metodologije za razvoj softvera i razvoja softvera. Tačan broj i prirodu određenog inkrementala gradi i što je ponovljeno biće specifična za svaki pojedinačni razvoj napora.

Iterativni i postepen razvoj su bitni delovi Modifikovanog vodopad modela, Racionalnog objedinjenog procesa, Ekstremnog programiranja i generalno raznih okvira agilnog razvoja softvera.

Iz toga sledi sličan proces sa planom PDCA ciklusa poboljšanja poslovnog procesa.

Pregled uredi

Pojednostavljena verzija tipičnog postepenog ciklusa u agilnom upravljanju projektima

Osnovna ideja ove metode je da se razvije sistem kroz ponovljene cikluse (iterativne) i u manjim porcijama u vremenu (inkrementalne), omogućavajući programerima da iskoriste ono što je naučeno tokom razvoja ranijih delova ili verzija sistema. Učenje dolazi i od razvoja i korišćenja sistema, gde su mogući ključni koraci u procesu startovanja sa jednostavnom realizacijom podskupa softverskih zahtevima i iterativno poboljšanje evoluirajuće verzije dok je puni sistem implementiran. U svakoj iteraciji, dizajn modifikacije su napravljene i nove funkcionalne sposobnosti se dodaju.

Sama procedura se sastoji od pokretanja koraka, koraka iteracije, i kontrolne liste projekta. Sa početnim korakom stvara bazu verziju sistema. Cilj ove početne implementacije je da se stvori proizvod na koji korisnik može da reaguje. To bi trebalo da ponudi uzorak ključnih aspekata problema i da obezbedi rešenje koje je dovoljno jednostavno za razumevanje i laku implementaciju. Da bi vodili proces ponavljanja, lista upravljanja projektima je stvorena da sadrži evidenciju o svim zadacima koje treba izvršiti. To uključuje stavke kao što su nove mogućnosti da se realizuju i područja redizajna postojećeg rešenja. Lista kontrole se stalno revidira kao rezultat faze analize.

Iteracija uključuje redizajn i implementacija ponavljanja treba da bude jednostavana, jasna i modularna, podrška redizajna u toj fazi ili kao zadatak dodat na listu za kontrolu projekta. Nivo dizajna detalja se ne diktira iterativnim pristupom. U laganom iterativnom projektu kod može predstavljati glavni izvor dokumentacije sistema; Međutim, u kritičnom iterativnom projektu može da se koristi formalna dokumentacija softverskog dizajna. Analiza iteracijom zasniva se na povratnim informacijama o korisnicima, a objektna analiza programa na raspolaganju. To podrazumeva analizu strukture, modularnost, upotrebljivosti, pouzdanosti, efikasnosti, i postizanje ciljeva. Lista upravljanja projektima je modifikovana u svetlu analizu rezultata.

Iterativni razvoj.

Faze uredi

Postepen razvoj seče funkcionalnost sistema u inkrementima (delovi). U svakom prirastu, kriška funkcionalnosti se isporučuje preko kros-discipline rada, od zahteva za raspoređivanje. Objedinjene procesne grupe u fazama: početak, razrada, konstrukcija, i tranzicija.

Početak identifikuje obim projekta, uslove (funkcionalne i nefunkcionalne) i rizike na visokom nivou, ali dovoljno detaljno da se posao može proceniti.
Izrada donosi radnu arhitekturu koja ublažava gornje rizike i ispunjava ne-funkcionalne zahteve.
Konstrukcija postepeno ispunjava-u arhitekturi sa proizvodnjom-spremni kod proizveden iz analize, dizajna, implementacije i testiranja funkcionalnih zahteva.
Tranzicija donosi sistem u proizvodnji radnog okruženja.

Svaka od faza može biti podeljena na 1 ili više iteracija, koje su obično vremenski-ograničene umesto odlikovane. Arhitekte i analitičari rade jednu iteraciju ispred programera i testera da zadrže posao..

Upotreba uredi

Mnogi primeri rane upotrebe su dati u Krejg Larman i Viktor Basili članku "Iterativni i postepen razvoj: Kratka istorija",^[2] sa jednim od najranijih bića NASA 1960. projekat Mercury.

Drugi je "rani i upečatljiv primer velikog IID uspeha je veoma srčana NASA-inog spejs šatl softvera-primarna avionika softverskog sistema, koji FSD izgrađen od 1977. do 1980. godine. Tim primenjuje IID u seriji od 17 iteracija više od 31 meseca, u proseku oko osam nedelja po iteraciji.Njihova motivacija za izbegavanje životnog ciklusa vodopada je da su zahtevi šatl programa promenili tokom procesa razvoja softvera ".

Neke organizacije, kao što je američko ministarstvo odbrane, imaju prednost za iterative metodologije, počevši od MIL-STD-498 "jasno podsticanje tekovina evolucije i IID".

Sadašnje DoD Uputstvo 5000,2, objavljeno 2000. godine, navodi jasnu prednost IID: "Postoje dva pristupa, evolutivni i jedan korak [vodopad], do potpune sposobnosti. Evolucioni pristup je poželjan. ... [U ovom] pristup, krajnja sposobnost dostavljena korisniku podeljena je na dva ili više blokova, sa povećanjem koraka sposobnosti ... razvoj softvera će pratiti iterativne spiralne procese razvoja u koje se stalno proširuju verzije softvera na osnovu učenje iz ranijeg razvoja. Može se uraditi u fazama.

Kontrast sa razvojem Vodopada uredi

Razvoj Vodopada završio posao-proizvode projekata širom svake discipline u jednom koraku pre prelaska na sledeće discipline u sledećem koraku. Poslovna vrednost se isporučuje odjednom, i to samo na samom kraju projekta. Praćenje pozadi je moguće u iterativnom pristupu.

Smernice za implementaciju uredi

Smernice koji pokreću realizaciju i analizu uključuju:

Bilo koju poteškoću u dizajnu, kodiranje i testiranje modifikacije treba da signalizira potrebu za redizajn ili re-kodiranje.
Promene bi trebalo da se lako uklope u izolovane i lako da pronađu module. Ako to ne urade, neki redizajn je verovatno potreban.
Izmene tabela bi trebalo da budu posebno lako napraviti. Ako nije brzo i lako urađena bilo koja modifikacija, redizajn je naznačen.
Promene bi trebalo da postanu lakše kao napredak iteracija. Ako nisu, postoji osnovni problem kao što je dizajn greške ili širenje zakrpa.
Flasteri obično treba da dozvole da postoji samo jedna ili dve iteracije. Flasteri mogu biti neophodne da se izbegnu preoblikovanje tokom faze implementacije.
Postojeću implementaciju treba analizirati često da se utvrdi koliko dobro se meri do ciljeva projekta.
Objekte analize programa treba koristiti kad god je na raspolaganju da pomognu u analizi parcijalnih implementacija.
Korisnička reakcija treba prikupiti i analizirati naznake nedostataka u trenutnoj implementaciji.

Korišćenje hardvera i ugrađenih sistema uredi

Iako je termin iterativni i postepen razvoj pokrenut u softverskoj industriji, mnogi hardveri i ugrađeni napori za razvoj softvera koristite iterativne i inkrementalne tehnike. Na primer, veliki SAD servis provajder za lansiranje United Launch Alliance (ULA) preduzeo je decenijski projekat za restrukturiranje lansiranja poslovno-smanjenje dve lansirne letelice na jednu-korišćenjem iterativnog i inkrementalnog pristupa da dođu do delimično-višekratne upotrebe i mnogo jeftinijeg pokretanja sistema tokom naredne decenije.^[3]

Vidi još uredi

Reference uredi

'^ 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. Pristupljeno 25. 4. 2015.

Literatura uredi

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. Arhivirano iz originala (PDF) 26. 05. 2012. g. Pristupljeno 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. Pristupljeno 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. Pristupljeno 25. 4. 2015.

[1]

[2]

[3]