Razvojni ciklus softvera
U softverskom inženjerstvu, metodologija za razvoj softvera (poznata i kao metodologija za razvoj sistema, razvoj softverskog životnog ciklusa, proces razvoja softvera, softverski proces) je razvoj softverskog rada u različitim fazama (ili faze) koji sadrži aktivnosti sa namerama za bolje planiranje i upravljanje. Često se smatra podskupom sistema razvoja životnog ciklusa. Metodologija može uključiti pre-definisanje konkretnih rezultata i artefakata koji su stvoreni i završeni od strane projektnog tima za razvoj ili održavanje aplikacije.[1]
Uobičajene metodologije uključuju vodopad model, izradu prototipova, iterativni i postepen razvoj, spiralni razvoj, brz razvoj aplikacija, ekstremno programiranje i razne vrste agilane metodologije. Neki ljudi smatraju da životni ciklus "modela" je opštiji termin za kategoriju metodologije i "procesa" razvoja softvera a konkretniji naziv se odnosi na konkretan proces po izboru određene organizacije. Na primer, postoje mnogi specifični procesi razvoja softvera koji se uklapaju u spiralni životni vek modela.
U praksi uredi
Mnoštvo tih okvira je evoluiralo tokom godina, svaki sa svojim priznatim prednostima i slabostima. Razvojni okviri metodologije softvera nije nužno pogodan za upotrebu od strane svih projekata. Svaki od raspoloživih metodologija okvira su najbolji odgovari za specifične vrste projekata, na osnovu različitih tehnika, organizacija, projekata i timova razmatranja.[1]
Organizacije za razvoj softvera sprovede proces metodologije da olakša proces razvoja. Ponekad, izvođači radova mogu da zahtevaju metodologiju zaposlenih, primer je američka odbrambena industrija, koja zahteva ocenu na osnovu procesa modela za dobijanje ugovora. Međunarodni standard za opisivanje načina odabira, sprovođenje i praćenje životnog ciklusa za softver je ISO/IEC 12207.
Višedecenijski cilj je bio da pronađu ponavljanje, predvidljivi procesi koji poboljšavaju produktivnost i kvalitet. Neki pokušavaju da sistematizuju ili formalizuju naizgled veseli zadatak za dizajniranje softvera. Drugi primenjuju tehnike upravljanja projektima u dizajniranju softvera. Bez efikasnog upravljanja projektima, softverski projekti mogli bi lako biti kasno isporučeni ili preko budžeta. Uz veliki broj softverskih projekata ne ispunjavaju njihova očekivanja po pitanju funkcionalnosti, troškova, ili o rokovima isporuke,jer efikasno upravljanje projektom izgleda da nedostaje.
Organizacije mogu stvoriti grupu softverskog inženjerstva, što je ključna tačka za poboljšanje procesa. Sastoji se od resornih praktičara koji imaju različite veštine, grupa je centar zajedničkog napora svih u organizaciji, koja se bavi poboljšanjem softverskog inženjerstva.
Posebno razvojni tim može da pristane na programsko okruženje detalja, kao što je integrisano razvojno okruženje koje se koristi, i jedan ili više dominantnih paradigmi programiranja, pravila programiranja stila ili izbor specifičnih softverskih biblioteka ili softverskih okvira. Ovi detalji uglavnom nisu diktirani izborom modela ili opštom metodologijom.
Istorija uredi
Razvoj metodologije softvera (takođe poznat kao SDM) nije nastao do 1960. godine. Prema Elliott (2004) razvoj životnog ciklusa sistema (SDLC) može se smatrati da je najstarija formalizovana metodologija okvira za izgradnju informacionih sistema. Osnovna ideja SDLC je bila "da nastavi razvoj informacionih sistema na organizovan i metodičan način, zahtevajući svaku fazu životnog ciklusa - od nastanka ideje do isporuke finalnog sistema - da bude obavljan strogo i redom[2] primenjujući kontekst okvira. Glavni cilj ove metodologije okvira u 1960. bio je "da se razvije veliki obim funkcionalnih poslovnih sistema u eri velikih poslovnih konglomerata. Informacioni sistemi aktivnosti vrti se oko teške obrade podataka i brojne rutine".[2]
Metodologije, procesi, i okviri u rasponu od specifičnih restriktivnih koraka koji se mogu direktno koristiti od strane organizacije u dan u dan rada, do fleksibilnih okvirima koje organizacija koristi da generiše prilagođeni skup koraka prilagođenih potrebama konkretnog projekta ili grupe. U nekim slučajevima "sponzor" ili "Održavanje" organizacija distribuira zvanični skup dokumenata koji opisuju proces. Specifični primeri uključuju:
- 1970
- Strukturirano programiranje od 1969. godine
- Cap Gemini SDM, poreklom iz PANDATE, prvi engleski prevod je objavljen 1974. SDM stoji za sistem metodologije za izradu
- 1980
- Strukturna sistemska analiza i metoda dizajna (SSADM) od 1980. pa nadalje
- Information Requirement Analysis/Soft systems methodology
- 1990
- Objektno orijentisano programiranje (OOP) razvijeno u ranim 1960-im, i postaloa dominantan pristup programiranju tokom sredine 1990-ih
- Brz razvoj aplikacija(RAD) od 1991.
- Metode razvoja dinamičskog sistema, od 1994
- Skram, od 1995
- Team software process, od 1998
- Rational Unified Process (RUP), održava ga IBM od 1998
- Ekstremno programiranje, od 1999. godine
- 2000
- Agile Unified Process (AUP) održava se od 2005. od strane Scott Ambler
Pristupi uredi
Nekoliko razvojnih softverskih pristupa se koristi od nastanka informacione tehnologije, u dve glavne kategorije. Tipičan pristup ili kombinacija pristupa je izabrano od strane menadžmenta ili razvojnog tima.
"Tradicionalne" metodologije, kao što je vodopad koji imaju različite faze se ponekad nazivaju razvojem životnog ciklusa softvera (SDLC), mada ovaj termin takođe može da se koristi uopšteno i da se odnosi na bilo koju metodologiju. A "životni ciklus" pristup sa odvojenim fazama je u suprotnosti sa Agile pristupima koji definišu proces ponavljanja, ali gde projektovanje, izgradnja i raspoređivanje različitih delova može doći istovremeno.
Razvoj vodopad modela uredi
Vodopad model je sekvencijalni pristup razvoju, u kojem se vidi kako razvoj teče nadole (kao vodopad) kroz nekoliko faza, tipično:
- Analiza rezultata uslova u zahtevima specifikacije softvera
- Softverski dizajn
- Implementacija
- Testiranje
- Integracija, ako postoji više podsistema
- Raspoređivanje (ili instalacija)
- Održavanje
Prvi formalni opis metoda se često navodi kao članka objavljenom od strane Winston W. Royce[3] 1970. godine iako Royce nije koristio termin "Vodopad" u ovom članku. Osnovni principi su:[1]
- Projekat je podeljen na uzastopne faze, sa nekim preklapanjima između faza.
- Naglasak je na planiranju, vremenskim rasporedom, rokovima, budžetim i realizacijom čitavog sistema u jednom trenutku.
- Stroga kontrola se održava tokom trajanja projekta putem obimne pisane dokumentacije, formalnih pregleda i odobrenja / isključenja od strane korisnika i informacione tehnologije upravljanja koja je nastala krajem većine faza pre početka sledeće faze.
Vodopad model je tradicionalni inženjerski pristup primenjen na softversko inženjerstvo. Strog pristup vodopadu obeshrabruje pregled i proveru bilo kakve faze nakon što je završena. Ova "nefleksibilnost" u čistom vodopad modelu je bio izvor kritika od strane pristalica drugih "fleksibilnih" modela. To je veliki blam za vladine projekte nekoliko velikih radova preko budžeta, tokom vremena i ponekad ne da ispuni zahteve usled velikog Dizajn napred pristupa. Osim kada je ugovorom potrebno, vodopad model je uglavnom zamenjen fleksibilnijom i razvijenijom metodologijom za razvoj softvera. Pogledajte kritike vodopad modela.
Vodopad model se takođe često uči sa mnemonikom Ples u mraku svakog ponedeljka, predstavlja analizu, dizajn, implementaciju, testiranje, dokumentaciju i izvođenje i održavanje.
Prototipovi uredi
Softver prototipa, je razvojni pristup aktivnosti tokom razvoja softvera, kreiranje prototipa, odnosno nepotpune verzije softvera se razvijaju.
Osnovni principi su:[1]
- Nesamostalana, kompletna metodologija razvoja, već je pristup da izdrži odabrane delove veće, tradicionalno razvojne metodologije (tj postepeni, spiralni, ili brz razvoj aplikacija (RAD)).
- Pokušaji da se smanji potencijalni rizik projekta razbijanjem projekta na manje segmente i pružanje više jednostavnih promena tokom procesa razvoja.
- Korisnik je uključen tokom razvojnog procesa, što povećava verovatnoću prihvatanja korisnika konačne realizacije.
- Malog obima makete sistema su razvijene iterativnim procesom modifikacije sve dok prototip evoluira u susret zahtevima korisnika.
- Dok većina prototipova je razvijeno sa očekivanjem da će biti odbačeni, moguće je u nekim slučajevima da evoluira od prototipa na rad sistema.
- Osnovno razumevanje osnovnog poslovnog problema neophodno je da se izbegne rešavanje problema
Postepeni razvoj uredi
Različite metode su prihvatljive za kombinovanje linearnih i iterativnih metodologija razvoja sistema, sa primarnim ciljem svakog da se smanji potencijalni rizik projekta razbijanjem projekat na manje segmente i pružanje više jednostavnosti tokom procesa razvoja.
Osnovni principi su[1]
- Niz mini vodopada se izvode, gde su sve faze vodopada završene za mali deo sistema, pre nego što pređete na sledeći prirast, ili
- Ukupni zahtevi su definisani pre nego što nastavite da evoluirate, razvoj pojedinih koraka mini-vodopada u sistemu, ili
- Prvobitni koncept softvera, analiza zahteva i dizajn arhitekture i sistema jezgra su definisani preko vodopada, a zatim iterativnom izradom prototipova, koji kulminiraju u instaliranju konačnog prototipa, radnog sistema.
Iterativni i postepeni razvoj uredi
Iteratni razvoj[4] propisuje izgradnju koja je u početku mala, ali uvek veće porcije softverskog projekta da se pomogne svima onima koji su uključeni da otkriju važne teme rano pred problemima ili neispravne pretpostavke koje mogu dovesti do katastrofe.
Spiralni razvoj uredi
Godine 1988, Barry Boehm je objavio razvoj sistema sofvera kao "spiralni model", koji kombinuje neke ključne aspeket vodopad modela i brzu izradu prototipova metodologije, u nastojanju da se kombinuju prednosti od vrha ka dnu i odozdo prema gore koncepata. Ona je dala naglasak u ključnoj oblasti koje su zapostavljene od strane drugih metodologija: namerno iterativnom rizičnom analizom, posebno pogodnom za veliki broj kompleksnih sistema.
Osnovni principi su:[1]
- Fokus je na proceni rizika i smanjenju rizika projekta razbijanjem projekta na manje segmente i pružanje dosta jednostavne promene tokom procesa razvoja, kao i pružanje prilike da ocene rizika vagaju razmatranje projekta tokom životnog ciklusa.
- "Svaki ciklus uključuje progresiju istom sekvencom koraka, za svaki deo proizvoda i za svaki njegov nivo izrade, iz ukupnog koncepta-of-operacije dokumenta dole na kodiranje svakog individualnog programa."[5]
- Svaki put oko spirale prelazi četiri osnovna kvadranata: (1) određuju ciljeve, alternative, i ograničenja u iteraciji; (2) procenjuju alternative; identifikacija i rešavanje rizika; (3) razvoj i verifikacija isporuke iz iteracije; i (4) planira sledeću iteraciju.[6]
- Počnite svaki ciklus sa identifikacijom aktera i njihovim "dobitnim uslovima", i na kraju svakog ciklusa sa pregledima i posvećenosti.[7]
Brzi razvoj aplikacija uredi
Brz razvoj aplikacija (RAD) je metodologija razvoja softvera, koja favorizuje iterativni razvoj i brzu izgradnju prototipova umesto velike količine up-front planiranja."Planiranje" razvoja softvera koristeći RAD je prošarano pisanje samog softvera. Nedostatak unapred planiranja generalno omogućava softveru da bude napisan mnogo brže, i olakšava da se promeni zahteve.
Brz razvoj procesa počinje sa razvojem preliminarnih modela podataka i poslovnih procesa modela koji koriste strukturirane tehnike. U narednoj fazi, zahtevi se verifikuju pomoću prototipa, na kraju da poboljšaju modele podataka i procesa. Ove faze se iterativno ponavljaju; dalji razvoj rezultata u "kombinovanim poslovnim zahtevima i tehničkoj dizajn izjavi se koristi za izgradnju novih sistema".[8]
Termin je prvi put upotrebljen da opiše proces za razvoj softvera koji je uveo James Martin 1991. Prema pisanju (2003), to je spajanje različitih strukturnih tehnika, naročito podaci Informatičkog inženjeringa, sa tehnikama za izradu prototipova da ubrzaju razvoj softverskih sistema.[8]
Osnovni principi brzog razvoja aplikacija su:[1]
- Ključni cilj je brz razvoj i isporuku visokog sistema kvaliteta u relativno niskoj ceni investicija.
- Pokušaji da se smanji potencijalni rizik projekta razbijanjem projekta na manje segmente i pružanje više jednostavne promene tokom procesa razvoja.
- Ima za cilj da proizvede visokokvalitetne sisteme brzo, pre svega preko iterativnih Prototipova (u bilo kojoj fazi razvoja), aktivno učešće korisnika, i kompjuterizovane razvojnim alatima. Ovi alati mogu uključivati Grafički korisnički interfejs (GUI) builders, Computer Aided Software Engineering (CASE) tools, Baza podataka (DBMS), Četvrta generacija programskog jezika, kod generatori i tehnike objektno orijentisane
- Ključni akcenat je na ispunjenju poslovne potrebe, dok je tehnološka ili inženjering izvrsnost od manjeg značaja.
- Kontrola Projekta uključuje prioritete razvoja i definisanja rokova isporuke ili "timeboxes". Ako se projekat provuče, naglasak je na smanjenju potreba da se uklopi u Timebok, ne u povećanju roka.
- Generalno podrazumeva zajednički dizajn aplikacija (JAD), gde korisnici su intenzivno uključeni u dizajnu sistema, preko konsenzusa u bilo strukturnim radionicama ili elektronski olakšanom interakcijom.
- Aktivno uključivanje korisnika je imperativ.
- Iterativni proizvodi za proizvodnju softvera
- Proizvodi dokumentacije neophodni da olakšaju budući razvoj i održavanje
- Standardna analiza sistema i metode dizajna mogu se ugraditi u ovaj okvir.
Agilni razvoj uredi
"Agilni razvoj softvera" se odnosi na grupu softverskih metodologija razvoja zasnovanog na iterativnom razvoju, gde zahtevi i rešenja evoluiraju preko saradnje samoorganizujućih kros-funkcionalnih timova. Termin je nastao u 2001. godini kada je formulisan agilni razvoj softvera.
Agilni razvoj softvera koristi iterativni razvoj kao osnovu, ali se zalaže za upaljač i više ljudi imaju orijentisano mišljenje tradicionalnih pristupa. Agilni procesi u osnovi uključe iteraciju i kontinuiranu povratnu informaciju da pruža sukcesivnu preradu i da dostavi softverski sistem.
Postoje mnoge agilne metodologije, uključujući:
Kod i popravka uredi
"Kod i popravka" razvoj nije toliko namerno strategija, kao rezultat pritiska na rasporedu programera.[9] Bez mnogo dizajna, programeri počinju odmah proizvodnjom koda. U jednom trenutku, ispitivanje počinje (često kasno u razvojnom ciklusu), a nezaobilazni bagovi onda moraju biti popravljeni pre nego što proizvod bude isporučen. Programiranje bez planiranog dizajna je takođe poznato kao kauboj kodiranje.
Lagane metodologije uredi
Lagana metodologija ima mali broj pravila. Neke od ovih metoda se takođe smatraju "agilnom".
- Adaprivni razvoj softvera opisao je Jim Highsmith, 1999., u svojoj knjizi Adaptive Software Development
- Crystal Clear porodica metodologije sa Alistair Cockburn,
- Ekstremno programiranje (XP), promovisan od strane ljudi kao što su Kent Beck i Martin Fowler. U ekstremnom programiranju, faze se sprovode u izuzetno malim (ili "kontinuiranim") koracima u odnosu na starije "batch" procese. Prvo, jedan piše automatizovane testove, da obezbedi konkretne ciljeve za razvoj. Sledeće je kodiranje (od strane programera koji rade u parovima, tehniku poznatu kao "par programiranja"), koje je završeno kada svi testovi prođu, a programeri ne mogu da se sete više testova koji su potrebni. Dizajn i arhitektura izlaze iz refaktorisanja, a dolaze nakon kodiranja. Isti ljudi koji rade kodiranje urade i dizajn. (Samo poslednja opcija - spajanje dizajna i koda - je zajedničko svim ostalim agilnim procesima.) . U ovom trenutku, praktikanti ponovo počinju pisanje testova za naredni najbitniji deo sistema.[10]
- Feature Driven Development (FDD) razvijen (1999) oda strane Jeff De Luca i Peter Coad
- ICONIX - UML-zasnovan objekat modeliranja sa slučajevima upotrebe, lagani uvod u Rational Unified Process
Drugo uredi
Ostale metodologije softversko projekta na visokom nivou su:
- Chaos model- Osnovno pravilo je uvek prvo reši najvažnija pitanja.
- Metodologija postepenog finansiranja - iterativni pristup
- Strukturna analiza sistema i metoda dizajna - posebna verzija vodopada
- Sporo programiranje, kao deo šireg sporog kretanja, naglašava pažljiv i postepen rad bez vremenskog pritiska. Sporo programiranje ima za cilj da se izbegnu greške i suviše brzo oslobađanje rasporeda.
- V-Model (Razvoj softvera) - produžetak vodopad modela
- Objedinjeni proces (UP) je ponavljanje metodologije za razvoj softverskog okvira, na osnovu Unified Modeling Language (UML). UP organizuje razvoj softvera u četiri faze, svaka se sastoji od jednog ili više izvršnih ponavljanja softvera u toj fazi razvoja početak, izradu, izgradnju i smernice. Mnogi alati i proizvodi postoje da bi se olakšalo UP implementaciju. Jedna od popularnijih verzija UP je Rational Unified Process (RUP).
Proces meta-modeli uredi
Neki "proces modeli" su apstraktni opisi za vrednovanje, upoređivanje i poboljšanje specifičnog procesa usvojenog od strane organizacije.
- ISO/IEC 12207 je međunarodni standard koji opisuje način da odaberete, implementirate i pratite životni ciklus za softver.
- Capability Maturity Model Integration (CMMI) je jedan od vodećih modela osnovu najbolje prakse. Nezavisne procene grade organizacije o tome kako dobro da prate svoje definisane procese, a ne na kvalitet tih procesa ili softvera proizvedenog. CMMI je zamenio CMM.
- ISO 9000 opisuje standarde za formalno organizovan proces za proizvodnju proizvoda i metode upravljanja i praćenja napretka. Iako je standardni prvobitno napravljen za proizvodni sektor, ISO 9000 standardi su primenjeni u razvoju softvera kao dobro. Kao CMMI, sertifikacija sa ISO 9000 ne garantuje kvalitet krajnjeg rezultata, oni su pratili formalizovane poslovne procese.
- ISO/IEC 15504 Informaciona tehnologija - Proces procene takođe poznat kao Proces mogućnosti određivanja softvera (SPICE), je "okvir za procenu softverskih procesa". Ovaj standard ima za cilj uspostavljanje jasnog modela za proces poređenja. SPICE se koristi slično kao CMMI. Modeli procesa za upravljanje, kontrolu, vodi i nadgleda razvoj softvera. Ovaj model se zatim koristi za merenje šta razvojna organizacija ili projektni tim zapravo radi tokom razvoja softvera. Ove informacije se analiziraju da identifikuju slabosti i poboljšanje diska. Takođe identifikuje prednosti koje može nastaviti ili integrisani u uobičajenoj praksi te organizacije ili tima.
- Metodologija soft sistema - opšti metod za poboljšanje procesa upravljanja
- Metod inženjeringa - opšti metod za poboljšanje procesa informacionog sistem
Formalne metode uredi
Formalne metode su matematički pristupi rešavanju softverskih (i hardvera) problema u zahtevima, nivo specifikacija i dizajna. Formalne metode se najverovatnije primenjuju za bezbednost kritičnog softvera i sistema, kao što je avionika softvera. Standardna bezbednost softvera , kao što je DO-178B, DO-178C, i opšte kriterijumima zahtevaju formalne metode u najvišim nivoima kategorizacije.
Za sekvencijalni softver, primeri formalnih metoda uključuju B-metod, jezike koji se koriste u specifikacijama automatizovanog dokazivanja teorema, RAISE, i Z zapis.
Formalizacija razvoja softvera je sitna, na drugim mestima, uz primenu Object Constraint Language (i specijalizacije, kao što je Java Modeling Language), a posebno sa modela pogon arhitekture dozvoljava izvršenje projekata, ako ne i specifikacije.
Za istovremeno softver i sistem, Petri mreže, proces algebre i konačne državne mašine (koje su zasnovane na teoriji automata - vidi virtuelni konačni automat) dozvoljavaju izvršavanje softvera specifikacije i može da se koristi da izgradi i potvrdi aplikaciju ponašanja.
Drugi nastojani trend u razvoju softvera je da napiše specifikaciju u nekom logičcnom obliku obično varijacija prvog reda logike(FOL) -i onda da direktno izvrši logiku kao da je program. Jezik OWL , na osnovu Opisne logike (DL), je primer. To je rad na mapiranju neke verzije engleskog (ili neki drugi prirodni jezik) automatski da i iz logike, i izvršavanje logike bude direktno. Primeri su Attempto Controlled English i Internet poslovna logika, koja ne traži da kontroliše vokabular ili sintaksu. Karakteristika sistema koji podržavaju dvosmerno mapiranje Engleske-logike i direktno izvršenje logike je da mogu da objasne svoje rezultate, na engleskom jeziku, na poslu ili naučnom nivou.
Vidi još uredi
- Softversko inženjerstvo računara (neki od ovih alata podržava specifične metodologije)
- Filozofija razvoja softvera
- Iza linije softverskog inženjerstva
- Projektni menadžment
- Razvoj softvera
- Procena napora razvoja softvera
- Životni ciklus softverskih izdanja
- Softverski dizajn
- Debagovanje
- Softversko raspoređivanje
- Održavanje softvera
- Konstrukcija softvera
- Testiranje softvera
- Analiza zahteva
- Softversko ineženjerstvo
Reference uredi
- ^ a b v g d đ e Centers for Medicare & Medicaid Services (CMS) Office of Information Service (2008).
- ^ a b Geoffrey Elliott (2004) Global Business Information Technology: an integrated systems approach.
- ^ Wasserfallmodell > Entstehungskontext, Markus Rerych, Institut für Gestaltungs- und Wirkungsforschung, TU-Wien.
- ^ ieeecomputersociety.org
- ^ Barry Boehm (1996., "A Spiral Model of Software Development and Enhancement".
- ^ Richard H. Thayer, Barry W. Boehm (1986).
- ^ Barry W. Boehm (2000).
- ^ a b Whitten, Jeffrey L.; Lonnie D. Bentley, Kevin C. Dittman. (2003).
- ^ McConnell, Steve (2000). „7: Lifecycle Planning”. Rapid Development. Redmond, Washington: Microsoft Press. str. 140.
- ^ Kent Beck, Extreme Programming, 2000.
Literatura uredi
- McConnell, Steve (2000). „7: Lifecycle Planning”. Rapid Development. Redmond, Washington: Microsoft Press. str. 140.
Spoljašnje veze uredi
- Selecting a development approach at cms.hhs.gov.
- Gerhard Fischer, "The Software Technology of the 21st Century: From Software Reuse to Collaborative Software Design", 2001
- Faze razvoja softvera