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

 
Tri osnovna pristupa koja  razvojnog okvira metodologije softvera.

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
1980
1990
2000

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

 
Aktivnosti u procesu razvoja softvera predstavljeni u vodopad modelu. Postoji nekoliko drugih modela koji predstavljaju ovaj proces.

Vodopad model je sekvencijalni pristup razvoju, u kojem se vidi kako razvoj teče nadole (kao vodopad) kroz nekoliko faza, tipično:

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

 
Spiralni model (Boehm, 1988)

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

 
Model brzog razvoja aplikacija

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 LucaPeter 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.
  • 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.

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

Reference uredi

  1. ^ a b v g d đ e Centers for Medicare & Medicaid Services (CMS) Office of Information Service (2008).
  2. ^ a b Geoffrey Elliott (2004) Global Business Information Technology: an integrated systems approach.
  3. ^ Wasserfallmodell > Entstehungskontext, Markus Rerych, Institut für Gestaltungs- und Wirkungsforschung, TU-Wien.
  4. ^ ieeecomputersociety.org
  5. ^ Barry Boehm (1996., "A Spiral Model of Software Development and Enhancement".
  6. ^ Richard H. Thayer, Barry W. Boehm (1986).
  7. ^ Barry W. Boehm (2000).
  8. ^ a b Whitten, Jeffrey L.; Lonnie D. Bentley, Kevin C. Dittman. (2003).
  9. ^ McConnell, Steve (2000). „7: Lifecycle Planning”. Rapid Development. Redmond, Washington: Microsoft Press. str. 140. 
  10. ^ 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