Pristupi razvoju softvera. Strukturalni pristup

1.Coding

U fazi razvoja softvera izvode se sljedeće glavne radnje: kodiranje; testiranje; razvoj referentnog sistema za softver; kreiranje korisničke dokumentacije; kreiranje verzije i instaliranje softvera,

Kodiranje je proces pretvaranja rezultata dizajna visokog i niskog nivoa u gotov softverski proizvod. Drugim riječima, kod kodiranja se opis kompajliranog PP modela odvija pomoću odabranog programskog jezika, koji može biti bilo koji od postojećih jezika. Izbor jezika se vrši ili na zahtjev kupca, ili uzimajući u obzir zadatak koji se rješava i lično iskustvo programera.

Prilikom kodiranja potrebno je pratiti standard za odabrani jezik, na primjer, za jezik C to je ANSI C, a za C++ ISO/IEC 14882 „Standart za C++ programski jezik“.

Pored opšte prihvaćenog standarda za programski jezik, kompanija može koristiti i sopstvene dodatne zahteve za pravila za pisanje programa. U osnovi, oni se odnose na pravila za formatiranje teksta programa.

Praćenje standarda i pravila kompanije omogućava vam da kreirate program koji radi ispravno, lak je za čitanje, razumljiv drugim programerima, sadrži informacije o programeru, datumu kreiranja, nazivu i svrsi, kao i potrebne podatke za upravljanje konfiguracijom.

U fazi kodiranja, programer piše programe i sam ih testira. Takvo testiranje se naziva testiranje jedinica. Sva pitanja vezana za testiranje softvera razmatraju se u Pogl. 10, takođe opisuje tehnologiju testiranja koja se koristi u fazi razvoja softvera. Ova tehnika se zove testiranje. "staklena kutija" (glassbox); ponekad se naziva i testiranjem "bijela kutija" (whitebox) za razliku od klasičnog koncepta "crne kutije" (blackbox).

U testiranju crne kutije, program se tretira kao objekat čija je unutrašnja struktura nepoznata. Tester unosi podatke i analizira rezultat, ali ne zna kako program radi. Prilikom odabira testova, specijalist traži ulazne podatke i uslove koji su mu interesantni, što može dovesti do nestandardnih rezultata. Prije svega, zanimaju ga oni predstavnici svake klase ulaznih podataka, u kojima će se najvjerovatnije pojaviti greške programa koji se testira.

Kod testiranja "staklene kutije" situacija je potpuno drugačija. Tester (u ovom slučaju sam programer) razvija testove na osnovu poznavanja izvornog koda, kojem ima pun pristup. Kao rezultat, on prima sljedeće beneficije.

1. Smjer testiranja. Programer može testirati program u dijelovima, razviti posebne test potprograme koji pozivaju jedinicu koja se testira i prosljeđuje podatke od interesa programeru. Jedan modul je mnogo lakše testirati upravo kao "staklenu kutiju".

2. Puna pokrivenost koda. Programer uvijek može odrediti koji fragmenti koda rade u svakom testu. On vidi koje su druge grane koda ostale neprovjerene i može odabrati uslove pod kojima će biti testirane. Sljedeće opisuje kako pratiti pokrivenost koda testova koje izvodite.

3. Sposobnost kontrole toka komandi. Programer uvijek zna koju funkciju treba izvršiti sljedeće u programu i kakvo bi njeno trenutno stanje trebalo biti. Da bi saznao da li program radi onako kako misli, programer može uključiti komande za otklanjanje grešaka koje prikazuju informacije o napretku njegovog izvršavanja ili koristiti poseban alat koji se zove debugger da to uradi. Debugger može učiniti mnogo korisnih stvari: pratiti i mijenjati redoslijed izvršavanja programskih naredbi, prikazati sadržaj svojih varijabli i njihove adrese u memoriji, itd.

4. Sposobnost praćenja integriteta podataka. Programer zna koji dio programa mora modificirati svaki element podataka. Prateći stanje podataka (koristeći isti debager), može identificirati greške kao što su promjene podataka od strane pogrešnih modula, njihova pogrešna interpretacija ili neuspješna organizacija.Programer može samostalno automatizirati testiranje.

5. Vizija unutrašnjih graničnih tačaka. U izvornom kodu su vidljive one granične točke programa koje su skrivene od vanjskog pogleda. Na primjer, za izvođenje određene radnje može se koristiti nekoliko potpuno različitih algoritama, a bez gledanja koda nemoguće je odrediti koji je programer odabrao. Drugi tipičan primjer bi bio problem prekoračenja bafera koji se koristi za privremeno pohranjivanje ulaznih podataka. Programer može odmah reći pri kojoj količini podataka će se bafer preliti i ne treba da sprovodi hiljade testova.

6. Mogućnost testiranja, određena odabranim algoritmom. Posebne tehnologije mogu biti potrebne za testiranje obrade podataka koja koristi vrlo složene računske algoritme. Matrična transformacija i sortiranje podataka su klasični primjeri. Tester, za razliku od programera, mora tačno da zna koji se algoritmi koriste, pa se mora obratiti na specijalizovanu literaturu.

Testiranje staklenih kutija dio je procesa programiranja. Programeri rade ovaj posao stalno, testiraju svaki modul nakon što je napisan, a zatim ponovo nakon što ga integrišu u sistem.

Prilikom izvođenja jediničnog testiranja, možete koristiti tehnike strukturalnog ili funkcionalnog testiranja ili obje.

Strukturalni Testiranje je jedna vrsta testiranja staklenih kutija. Njegova glavna ideja je ispravan izbor softverske putanje koja se testira. Za razliku od njega funkcionalan testiranje spada u kategoriju testiranja "crne kutije". Svaka funkcija programa se testira uzimanjem njenog ulaza i analizom izlaza. U ovom slučaju, interna struktura programa se vrlo rijetko uzima u obzir.

Dok strukturalno testiranje ima mnogo snažniju teorijsku osnovu, većina testera preferira funkcionalno testiranje. Ispitivanje konstrukcija je bolje za matematičko modeliranje, ali to uopće ne znači da je efikasnije. Svaka od tehnologija vam omogućava da identifikujete greške koje su propuštene u slučaju korištenja druge. Sa ove tačke gledišta, mogu se nazvati podjednako efikasnim.

Predmet testiranja može biti ne samo puna putanja programa (slijed naredbi koje izvršava od početka do završetka), već i njegovi pojedinačni dijelovi. Apsolutno je nerealno testirati sve moguće načine izvršavanja programa. Stoga stručnjaci za testiranje od svih mogućih puteva izdvajaju one grupe koje je potrebno sigurno testirati. Za odabir koriste posebne kriterije tzv kriterijumi pokrivenosti (coveragecriteria), koji određuju sasvim stvaran (čak i prilično veliki) broj testova. Ovi kriterijumi se ponekad nazivaju logični kriterijumi pokrivenosti, ili kriterijume kompletnosti.

3. Razvoj sistema pomoći za softverski proizvod. Kreiranje korisničke dokumentacije

Preporučljivo je imenovati jednog od zaposlenih na projektu za tehničkog urednika dokumentacije. Ovaj zaposlenik može obavljati i druge poslove, ali njegov glavni zadatak treba da bude analiziranje dokumentacije, čak i ako je drugi zaposleni razvijaju.

Često se dešava da na izradi softvera radi nekoliko ljudi, ali niko od njih nije u potpunosti odgovoran za njegov kvalitet. Kao rezultat toga, PP ne samo da nema koristi od činjenice da ga više ljudi razvija, već i gubi, jer svako podsvjesno prebacuje odgovornost na drugoga i očekuje da njegovi kolege obave ovaj ili onaj dio posla. Ovaj problem se rješava postavljanjem urednika koji je u potpunosti odgovoran za kvalitet i tačnost tehničke dokumentacije.

Softverski sistem pomoći formiran je na osnovu materijala izrađenog za korisnički priručnik. Formira ga i stvara odgovornog za obavljanje ovog posla. To može biti ili tehnički urednik ili jedan od programera zajedno sa tehničkim urednikom.

Dobro dokumentovan PP ima sledeće prednosti.

1. Jednostavnost upotrebe. Ako je PP dobro dokumentiran, onda ga je mnogo lakše primijeniti. Korisnici to brže uče, prave manje grešaka i kao rezultat toga rade svoj posao brže i efikasnije.

2. Niži troškovi tehničke podrške. Kada korisnik ne može da shvati kako da izvrši radnje koje su mu potrebne, on poziva proizvođača softvera u službu tehničke podrške. Održavanje takve usluge je veoma skupo. Dobar priručnik, s druge strane, pomaže korisnicima da sami riješe probleme i smanjuje potrebu za kontaktiranjem grupe za tehničku podršku.

3. Visoka pouzdanost. Nerazumljiva ili neuredna dokumentacija čini softver manje pouzdanim, jer je veća vjerovatnoća da će njegovi korisnici pogriješiti, teško im je shvatiti šta ih uzrokuje i kako se nositi s njihovim posljedicama.

Lakoća pratnje. Ogromna količina novca i vremena se troši na analizu problema koji nastaju greškama korisnika. Promjene napravljene u novim izdanjima softvera često su samo promjena u interfejsu starih funkcija. Uvedeni su kako bi korisnici konačno shvatili kako koristiti softver i prestali zvati službu tehničke podrške. Dobro vodstvo u velikoj mjeri

Prilikom razmatranja tehnologije razvoja softvera potrebno je koristiti sistematski pristup, koji podrazumijeva razmatranje ne pojedinih aspekata problema razvoja softvera, već problema u cjelini. Sistemski pristup je implementiran u prostoru i vremenu.

Sistematski pristup u vremenu razmatra slijed faza kreiranja softvera od trenutka formiranja nezadovoljene potrebe za softverom. do njegove dozvole i podršku u radu rezultirajućeg softverskog proizvoda.

Sistemski pristup u "svemiru" predviđa razmatranje softvera koji se razvija kao dio sistema. Istovremeno, na osnovu proučavanja informacionih potreba sistema, koji će uključivati ​​softver koji se razvija, formulišu se ciljevi i skup softverskih funkcija i analiziraju prototipovi softvera. Softverski zahtjevi su formirani i dokumentirani.

Moderna tehnologija razvoja softvera programiranje smatra jednom od razvojnih faza u lancu uzastopnih faza razvojnog ciklusa. Sve ove faze objedinjuje koncept životnog ciklusa softvera i moraju biti podržane odgovarajućim softverskim i hardverskim alatima.

U skladu sa međunarodnim standardom ISO/IEC 12207 „Informaciona tehnologija – Procesi životnog ciklusa softvera“, proces razvoja softvera sadrži sledeće faze životnog ciklusa softvera:

1) analiza sistemskih zahteva i obima;

2) projektovanje arhitekture sistema;

3) analiza softverskih zahteva (specifikacije, eksterni interfejsi,);

4) projektovanje softverske arhitekture;

5) detaljni projekat svake jedinice softvera;

6) softversko kodiranje (programiranje)

7) testiranje softverskih jedinica;

8) integracija (unifikacija softvera) i testiranje seta softverskih jedinica;

9) kvalifikacioni testovi softvera (integrisano testiranje);

10) jedinice strukture softvera za sistemsku integraciju treba da budu integrisane sa hardverskim jedinicama;

11) osposobljavanje sistema;

12) instalacija softvera.

Dakle, proces razvoja softvera počinje od sistema u kojem će se ovaj softver koristiti i završava ponovo u sistemu.

Nakon razvojnih faza u životnom ciklusu softvera, slijedi faza rada i održavanja softvera u radu. Ponekad je lista faza životnog ciklusa softvera data sa nekim generalizacijama (agregacijama) od 12 faza. Na primjer, faze dizajna sistema i definisanja softverskih zahtjeva, dizajn softverskog paketa, dizajn softverskog algoritma, programiranje (kodiranje), offline otklanjanje grešaka u softveru, otklanjanje složenih softverskih grešaka, rad softvera.

Zanemarujući faze projektovanja softvera, želja da se odmah počne sa programiranjem bez dovoljno proučavanja algoritama i pitanja interakcije softverskih strukturnih jedinica često dovodi do haotičnog procesa razvoja softvera sa malim izgledima za uspeh.

Spiralni model životnog ciklusa softvera. "Teške i lagane" (brze) tehnologije razvoja softvera

Razmatrani model životnog ciklusa (LC) pripada modelu kaskadnog tipa. Ovaj tip modela životnog ciklusa je dobar za softver za koji je na samom početku razvoja moguće u potpunosti i precizno formulisati sve zahteve za softver.

Shema spiralnog životnog ciklusa softvera. Međutim, pravi proces kreiranja softvera ne uklapa se uvijek u tako rigidnu shemu i često postoji potreba da se vratimo na prethodne faze uz pojašnjenje ili reviziju donesenih odluka.

Za softver, kao i za druge složene sisteme čiji početni zahtjevi nisu dovoljno potpuni, karakterističan je iterativni proces razvoja. Istovremeno, za neke tipove softvera čak je poželjno preći na sljedeću fazu što je brže moguće. Istovremeno, nedostaci koji su neizbježni kod ovako ishitrenog rada otklanjaju se u sljedećoj iteraciji ili ostaju zauvijek.

Glavni zadatak je da se što prije postigne funkcionalan softver, čime se aktivira proces pojašnjenja i dopune zahtjeva. Ovo je takozvani spiralni model životnog ciklusa softvera.

Na svakom zavoju spirale kreira se verzija proizvoda, specificiraju se softverski zahtjevi i planira se rad sljedećeg zavoja. Spiralni model životnog ciklusa softvera odražava objektivno postojeći proces iterativnog razvoja softvera (slika 8.2).

Vjeruje se da spiralna shema životnog ciklusa softvera nije namijenjena toliko brzopletim programerima, koliko softveru, čije su prve verzije niske kvalitete prihvatljive za funkcionalnu svrhu softvera.

Postoji pravac "brze tehnologije" razvoja softvera (Agile Software Development), koji daje ideološko opravdanje za stavove povezane sa spiralnim modelom životnog ciklusa. Ove tehnologije su zasnovane na četiri ideje:

Interaktivna interakcija pojedinaca važnija je od formalnih procedura i alata,

Rad softvera je važniji od posjedovanja dokumentacije za njega,

Saradnja sa kupcem važnija je od formalnih ugovora,

Brz odgovor na vanjske promjene važniji je od strogog pridržavanja planova.

Rice. 8.2 - Šema spiralnog životnog ciklusa softvera

Drugim riječima, brze tehnologije imaju za cilj da zamijene formalne i dugotrajne dokumentirane procedure interakcije tokom razvoja interaktivnim, što je moguće uz male veličine projekta, odabrane kvalitete zaposlenih, smještaj programera i kupaca „u istu prostoriju“ i za razvoj softvera za nekritične sisteme.

Teško je osporiti ispravnost ovih principa u određenoj mjeri kada razvoj softvera vrši mali broj kvalifikovanih i posvećenih „fanova“) za razvoj određenih tipova softvera. Međutim, Agile tehnologije i njihovi ideolozi prepoznaju da je ovo primjenjivo na softverske projekte određene klase i razmjera, baš kao i spiralni model životnog ciklusa općenito, naime, gdje softverske greške dovode do određenih neugodnosti ili gubitka nadoknadivih sredstava.

Tamo gdje neispravno funkcioniranje softvera dovodi do prijetnje ljudskom životu ili do velikih materijalnih gubitaka, potrebno je koristiti potpuno osmišljene tehnologije kako bi se osigurala pouzdanost softverskog proizvoda.

Sa povećanjem obima softverskog projekta - povećanjem broja ljudi koji u njemu učestvuju, povećava se potreba za krutom razvojnom tehnologijom koja čini kaskadni životni ciklus softvera. Ovdje je potrebna dokumentacija, jer je u svakom trenutku moguć gubitak bilo kojeg od programera, neophodna je formalizacija međuprogramskih komunikacija, upravljanje promjenama softvera itd. Nije uzalud u razvoj softvera uveden kaskadni model životnog ciklusa. standardima. Istovremeno, omogućava implementaciju iterativnog procesa razvoja zbog predviđenog faznog dizajna CTS-a i softvera za njih.

Za veoma velike softverske projekte (više od 100 programera), razvojna tehnologija je ključni faktor koji utiče ne samo na kvalitet softvera, već i na samu mogućnost njegovog stvaranja.

Tehnologije razvoja softvera "teške i lagane". . Programeri mnogih tipova softvera smatraju da je model životnog ciklusa vodopada previše reguliran, previše dokumentovan i težak, te stoga iracionalan. Postoji pravac "Brze tehnologije" (lake tehnologije) razvoja softvera (Agile Software Development), koji daje ideološko opravdanje za ove stavove. Ove tehnologije su zasnovane na četiri ideje:

1. interaktivna interakcija pojedinaca je važnija od formalnih procedura i alata,

2. radni softver je važniji od dostupnosti dokumentacije za njega,

3. saradnja sa kupcem je važnija od formalnih ugovora sa njim,

4. brza reakcija na vanjske promjene važnija je od striktnoga pridržavanja planova.

Ispravnost ovih principa, osim trećeg, u određenoj mjeri (razvoj softvera obavlja mali broj kvalifikovanih programera – „fanova“ kojima nije potrebna kontrola i dodatna motivacija) za razvoj softvera je teško osporiti. Međutim, Agile tehnologije i to prepoznaju i njihovi ideolozi su primjenjivi na softverske projekte određene klase i razmjera, kao i na spiralni model životnog ciklusa općenito, odnosno gdje softverske greške dovode do određenih neugodnosti ili gubitka nadoknadivih sredstava i gdje softver Zahtjevi se stalno mijenjaju, budući da su unaprijed bili loše definisani, te je potrebno brzo prilagođavanje tim promjenama.

Brze tehnologije - pokušava postići kompromis između stroge razvojne discipline i njenog potpunog odsustva u ime smanjenja toka papirologije koja prati razvoj Brze tehnologije ne mogu osigurati visoku pouzdanost softverskog proizvoda upravo zbog minimiziranja papirologije koja zakonski potvrđuje odgovornost programera .

Primjer Agile tehnologija je ekstremno programiranje (XP). Iteracije u XP-u su vrlo kratke i sastoje se od četiri operacije: kodiranje, testiranje, slušanje korisnika, dizajniranje. Principi XP-a - minimalizam, jednostavnost, participacija kupaca, kratko vrijeme ciklusa, bliska interakcija između programera - trebali bi sjediti u istoj prostoriji, svakodnevni operativni sastanci zajedno sa korisnikom izgledaju razumno i dugo se koriste ne samo u brzim tehnologijama, već i u XP-u su dovedeni do ekstremnih vrijednosti.

Analiza mnogih softverskih projekata pokazala je da su lagane tehnologije koje propovijedaju principe samoorganizacije, naglašavajući korištenje individualnih sposobnosti programera, kratke razvojne iteracije u spiralnom modelu, XP, SCRUM uobičajene i često također dovode do uspjeha, čineći većinu karakteristika rada u malim timovima.

Tamo gdje neispravan softver dovodi do prijetnje ljudskom životu ili do velikih materijalnih gubitaka, treba koristiti uredne, potpuno promišljene i predvidljive formalizirane "teške" tehnologije kako bi se osigurala pouzdanost softverskog proizvoda čak iu slučaju srednje kvalificiranih programera. Sa povećanjem obima softverskog projekta, povećanjem broja ljudi koji učestvuju u njemu, povećava se potreba za krutom i formalnom razvojnom tehnologijom koja fiksira odgovornost svakog učesnika u razvoju koji čini kaskadni životni ciklus softvera. . Nije uzalud model životnog ciklusa vodopada uveden u standarde razvoja softvera.

U velikim razvojnim timovima problem menadžmenta dolazi do izražaja.

Za vrlo velike softverske projekte ključna su pitanja urednog koordiniranog razvoja: strukturiranje, integracija, osiguranje ispravne interakcije programa, organiziranje neizbježnih promjena na ispravan i koordiniran način. i utiču na samu mogućnost njihovog nastanka.

U malim softverskim projektima odlučujuću ulogu imaju algoritamska usavršavanja, uticaj pojedinačnih talentovanih pojedinaca, dok su u velikim projektima ovi faktori nivelisani i nemaju odlučujući uticaj na razvojni proces.

Softverski programeri koji imaju prosječne sposobnosti, a oni su u većini, i koji održavaju tehnološku disciplinu u okviru prave tehnologije, trebali bi razviti softver traženog kvaliteta. "Održavajte red i on će vas čuvati."

Napomena: Fleksibilan pristup razvoju softvera, razmatraju se osnovni principi fleksibilnog razvoja. Dat je spisak tehnika koje u određenoj mjeri odgovaraju principima fleksibilnog razvoja softvera. Analiziraju se ključne vrijednosti i principi agilnog razvoja.

Prezentaciju za ovo predavanje možete preuzeti.

Svrha predavanja:

Steknite razumijevanje svrhe i osnovnih principa agilnog razvoja softvera.

Uvod

Agilna metodologija razvoja softvera fokusiran na upotrebu iterativnog pristupa, u kojem softvera stvara se postepeno, u malim koracima, uključujući implementaciju određenog skupa zahtjeva. Pretpostavlja se da se zahtjevi mogu promijeniti. Timovi koji koriste agilne metodologije formiraju se od svestranih programera koji obavljaju različite zadatke u procesu kreiranja softverskog proizvoda.

Kada se koriste agilne metodologije, minimizacija rizika se provodi svođenjem razvoja na niz kratkih ciklusa tzv. iteracije, u trajanju od 2-3 sedmice. Iteracija je skup zadataka koji se planiraju završiti u određenom vremenskom periodu. U svakoj iteraciji kreira se funkcionalna verzija softverskog sistema u kojoj je prioritet (za ovu iteraciju) zahtjevi kupaca. Svaka iteracija obavlja sve zadatke potrebne za kreiranje funkcionalnog softvera: planiranje, analiza zahtjeva, dizajn, kodiranje, testiranje i dokumentaciju. Iako jedna iteracija općenito nije dovoljna za izdavanje nove verzije proizvoda, podrazumijeva se da trenutna softvera spreman za izdavanje na kraju svake iteracije. Na kraju svake iteracije, tim ponovo postavlja prioritete prema zahtjevima za softverski proizvod, eventualno prilagođavajući razvoj sistema.

Principi i značenje agilnog razvoja

Za metodologiju agilnog razvoja deklarisani su ključni postulati koji omogućavaju timovima da postignu visoke performanse:

• ljudi i njihova interakcija;
• Isporuka radnog softvera;
• saradnja sa kupcem;
• odgovor na promjenu.

Ljudi i interakcija. Ljudi su najvažniji dio uspjeha. Pojedinačni članovi tima i dobra komunikacija su neophodni za timove sa visokim učinkom. Da bi se olakšala komunikacija, agilne prakse uključuju česte rasprave o rezultatima rada i promjenama odluka. Diskusije se mogu održavati svakodnevno po nekoliko minuta i na kraju svake iteracije uz analizu rezultata rada i retrospektivu. Da bi efikasno komunicirali na sastancima, članovi tima moraju se pridržavati sljedećih ključnih pravila ponašanja:

• poštovanje mišljenja svakog člana tima;
• budite iskreni u svakoj komunikaciji;
• transparentnost svih podataka, radnji i odluka;
• uvjerenje da će svaki učesnik podržati tim;
• posvećenost timu i njegovim ciljevima.

Pored efikasnog tima i dobre komunikacije, potrebni su savršeni softverski alati za stvaranje timova visokih performansi u agilnim metodologijama.

Radni softver je važniji od sveobuhvatne dokumentacije. Sve agilne metodologije ističu potrebu za isporukom malih dijelova radnog softvera kupcu u unaprijed određenim intervalima. Softver, po pravilu, mora proći nivo jediničnog testiranja, testiranje na nivou sistema. Količina dokumentacije treba svesti na minimum. Tokom procesa projektovanja, tim treba da ažurira kratak dokument koji sadrži obrazloženje odluke i opis strukture.

Saradnja sa kupcem važnija je od formalnih sporazuma po ugovoru. Da bi projekat bio uspešno završen neophodna je redovna i česta komunikacija sa naručiocem. Kupac mora redovno učestvovati u raspravi o odlukama donetim o softveru, izražavati svoje želje i komentare. Uključivanje kupca u proces razvoja softvera neophodno je za stvaranje kvalitetnog proizvoda.

Brzo reagovanje na promene važnije je od praćenja plana. Sposobnost da se odgovori na promjene u velikoj mjeri određuje uspjeh softverskog projekta. U procesu stvaranja softverskog proizvoda često se mijenjaju zahtjevi kupaca. Kupci često ne znaju tačno šta žele dok ne vide da to funkcioniše. softvera. Agilne metodologije traže povratne informacije od kupaca u procesu kreiranja softverskog proizvoda. Odgovor na promjene je od suštinskog značaja za stvaranje proizvoda koji pruža zadovoljstvo kupaca i poslovnu vrijednost.

Načela agilnog razvoja su podržana sa 12 principa. Agilne specifične metodologije definiraju procese i pravila koja su manje-više u skladu s ovim principima. Fleksibilne metodologije za kreiranje softverskih proizvoda zasnivaju se na sljedećim principima:

1. Najveći prioritet je zadovoljiti želje kupca kroz isporuku korisnog softvera u kratkom vremenu, praćeno stalnim ažuriranjem. Agilne prakse uključuju brzo početno izdanje i česta ažuriranja. Cilj tima je isporučiti radnu verziju u roku od nekoliko sedmica od početka projekta. Ubuduće, softverski sistemi sa inkrementalnom funkcionalnošću trebali bi se isporučivati ​​svakih nekoliko sedmica. Kupac može započeti komercijalni rad sistema ako ga smatra dovoljno funkcionalnim. Takođe, korisnik se može jednostavno upoznati sa trenutnom verzijom softvera, dati povratne informacije uz komentare.
2. Nemojte zanemariti promjene zahtjeva, čak ni kasno u razvoju. Fleksibilni procesi omogućavaju uzimanje u obzir promjena kako bi se osigurala konkurentska prednost kupca. Timovi koji koriste agilne metodologije nastoje da programsku strukturu učine kvalitetnom, uz minimalan uticaj promjena na sistem u cjelini.
3. Nove radne verzije softvera isporučujte često, u intervalima od jedne sedmice do dva mjeseca, uz prednost kraćih rokova. Istovremeno, cilj je isporučiti program koji zadovoljava potrebe korisnika, uz minimum prateće dokumentacije.
4. Kupci i programeri moraju raditi zajedno tokom cijelog projekta. Smatra se da za uspješan projekat, kupci, programeri i svi dionici moraju komunicirati često i na mnogo načina kako bi ciljano poboljšali softverski proizvod.
5. Projekte treba da realizuju motivisani ljudi. Dajte projektnom timu zdravo radno okruženje, pružite mu potrebnu podršku i vjerujte da će članovi tima obaviti posao.
6. Najefikasniji i produktivniji način prenošenja informacija razvojnom timu i razmjene mišljenja unutar njega je razgovor licem u lice. U agilnim projektima, glavni način komunikacije je jednostavna ljudska interakcija. Pisani dokumenti se kreiraju i ažuriraju postepeno kako se softver razvija i samo kada je to potrebno.
7. Radni program je glavni pokazatelj napretka projekta. Pristup agilnog projekta završetku se procjenjuje prema tome koliko dobro trenutni program ispunjava zahtjeve korisnika.
8. Agilni procesi potiču dugoročni razvoj. Kupci, programeri i korisnici moraju biti u mogućnosti da održavaju konstantan tempo neograničeno.
9. Neumoljiv fokus na inženjersku izvrsnost i kvalitetan dizajn povećava povrat agilnih tehnologija. Članovi agilnog tima nastoje stvoriti kvalitetan kod redovnim refaktoriranjem.
10. Jednostavnost je umjetnost postizanja više radeći manje. Članovi tima rješavaju tekuće zadatke što jednostavnije i efikasnije. Ako u budućnosti bude problema, moguće je izvršiti izmjene koda kvaliteta bez velikih troškova.
11. Najbolje arhitekture, zahtjevi i dizajni dolaze od samoorganizirajućih timova. U fleksibilnim timovima zadaci se ne dodjeljuju pojedinačnim članovima, već timu u cjelini. Tim sam odlučuje kako najbolje implementirati zahtjeve kupca. Članovi tima sarađuju na svim aspektima projekta. Svakom učesniku je dozvoljeno da doprinese zajedničkom cilju. Nijedan član tima nije isključivo odgovoran za arhitekturu, zahtjeve ili testove.
12. Tim bi trebao redovno razmišljati o tome kako postati još učinkovitiji, a zatim prilagoditi i fino prilagoditi svoje ponašanje u skladu s tim. Agilni tim stalno prilagođava svoju organizaciju, pravila, dogovore i odnose.

Gore navedeni principi, u određenoj mjeri, odgovaraju brojnim metodologijama razvoja softvera:

Agilno modeliranje	skup koncepata, principa i tehnika (praksa) koji vam omogućavaju da brzo i jednostavno izvršite modeliranje i dokumentaciju u projektima razvoja softvera;
Agilni objedinjeni proces (AUP)	pojednostavljena verzija IBM RationalUnifiedProcess(RUP), koja opisuje jednostavnu i razumljivu aproksimaciju (model) za izgradnju softvera za poslovne aplikacije;
Otvoriti	to je iterativno-inkrementalna metoda razvoja softvera. Pozicioniran kao lagana i fleksibilna RUP opcija;
AgileDataMethod	grupa iterativnih metoda razvoja softvera u kojima se zahtjevi i rješenja postižu kroz suradnju različitih međufunkcionalnih timova;
DSDM	metodologija za razvoj dinamičkih sistema zasnovana na konceptu brzog razvoja aplikacija (RapidApplicationDevelopment, RAD). Predstavlja iterativni i inkrementalni pristup koji naglašava kontinuiranu uključenost korisnika/potrošača u proces;
Ekstremno programiranje (XP)	ekstremno programiranje;
Adaptivni razvoj softvera (ADD)	adaptivni razvoj softvera;
Razvoj vođen funkcijama (FDD)	razvoj fokusiran na postepeno dodavanje funkcionalnosti;
Getting Real	iterativni pristup bez funkcionalnih specifikacija koji se koriste za web aplikacije;
MSFfogAgileSoftwareDevelopment	Agilna metodologija razvoja softvera iz Microsofta;
Scrum	uspostavlja pravila za upravljanje procesom razvoja i omogućava vam da koristite postojeće prakse kodiranja prilagođavanjem zahtjeva ili unošenjem taktičkih promjena [

Model vodopada Analiza zahtjeva Dizajn Implementacija Integracija Testiranje Izrada specifikacije proizvoda Izrada arhitekture proizvoda Razvoj izvornog koda Integracija dijelova izvornog koda Testiranje i otklanjanje grešaka

Model slučaja upotrebe objedinjenog procesa razvoja softvera (USDP) opisuje slučajeve u kojima će se aplikacija koristiti. Analitički model opisuje osnovne klase za aplikaciju. Model dizajna opisuje veze i odnose između klasa i namjenskih objekata, a model implementacije opisuje distribuciju softvera po računarima. Model implementacije opisuje unutrašnju organizaciju programskog koda. Testni model se sastoji od komponenti testa, testnih procedura i različitih test slučajeva.

Tipične komponente arhitekture softverskog proizvoda i tipični softverski zahtjevi Organizacija programa Osnovne klase sistema Organizacija podataka Organizacija podataka Poslovna pravila Korisnički interfejs Upravljanje resursima Sigurnost Performanse Skalabilnost Interakcija sa drugim sistemima (integracija) Internacionalizacija, lokalizacija Ulazno-izlazni podaci Rukovanje greškama

Komponente tipične arhitekture softverskog proizvoda i tipični softverski zahtjevi Tolerancija grešaka je skup sistemskih svojstava koja povećavaju pouzdanost sistema otkrivanjem grešaka, obnavljanjem i izolacijom loših posljedica za sistem. Prilikom projektovanja bilo kog stvarnog sistema koji će osigurati toleranciju grešaka, potrebno je predvidjeti sve moguće situacije koje mogu dovesti do kvara sistema i razviti mehanizme za rukovanje kvarovima. Pouzdanost je sposobnost sistema da izdrži razne kvarove i kvarove. Kvar je prelazak sistema kao rezultat greške u potpuno neoperativno stanje. Kvar je greška u radu sistema koja ne dovodi do kvara sistema. Što je manje kvarova i kvarova u određenom vremenskom periodu, sistem se smatra pouzdanijim.

Tipične komponente arhitekture softverskog proizvoda i tipični softverski zahtjevi Mogućnosti implementacije razvijene arhitekture. Mogućnosti implementacije razvijene arhitekture. redundantna funkcionalnost. redundantna funkcionalnost. Odlučivanje o kupovini gotovih softverskih komponenti. Odlučivanje o kupovini gotovih softverskih komponenti. Promijenite strategiju. Promijenite strategiju.

Da li je opća organizacija programa jasno opisana; da li specifikacija uključuje pregled arhitekture i njenog obrazloženja. Da li je opća organizacija programa jasno opisana; da li specifikacija uključuje pregled arhitekture i njenog obrazloženja. Da li su glavne komponente programa adekvatno definisane, njihova područja odgovornosti i interakcija sa ostalim komponentama. Da li su glavne komponente programa adekvatno definisane, njihova područja odgovornosti i interakcija sa ostalim komponentama. Da li su sve funkcije navedene u specifikaciji zahtjeva implementirane razumnim brojem komponenti sistema. Da li su sve funkcije navedene u specifikaciji zahtjeva implementirane razumnim brojem komponenti sistema. Da li su najvažnije klase opisane i opravdane. Da li su najvažnije klase opisane i opravdane. Da li je dat opis organizacije baze podataka. Da li je dat opis organizacije baze podataka. Da li su sva poslovna pravila definisana? Da li su sva poslovna pravila definisana? Da li je opisan njihov uticaj na sistem? Da li je opisan njihov uticaj na sistem? Kontrolna lista pitanja koja vam omogućavaju da donesete zaključak o kvaliteti arhitekture:

Kontrolna lista pitanja koja vam omogućavaju da donesete zaključak o kvaliteti arhitekture: Da li je opisana strategija dizajna korisničkog interfejsa. Da li je opisana strategija dizajna korisničkog interfejsa. Da li je korisnički interfejs napravljen modularno tako da promene na njemu ne utiču na ostatak sistema. Da li je korisnički interfejs napravljen modularno tako da promene na njemu ne utiču na ostatak sistema. Da li je dat opis I/O strategije. Da li je dat opis I/O strategije. Da li je izvršena analiza performansi sistema koji će biti implementiran koristeći ovu arhitekturu. Da li je izvršena analiza performansi sistema koji će biti implementiran koristeći ovu arhitekturu. Da li je izvršena analiza pouzdanosti projektovanog sistema? Da li je izvršena analiza pouzdanosti projektovanog sistema? Da li je izvršena analiza skalabilnosti i proširivosti sistema? Da li je izvršena analiza skalabilnosti i proširivosti sistema?

Kod za refaktoriranje softvera se ponavlja; implementacija metode je prevelika; previše ugniježđenja petlji ili je sama petlja vrlo velika; klasa ima lošu povezanost (osobine i metode klase treba da opisuju samo 1 objekat); interfejs klase ne formira konzistentnu apstrakciju; metoda uzima previše parametara. Trebali biste pokušati zadržati broj parametara na razumnom minimumu; pojedinačni delovi časa se menjaju nezavisno od ostalih delova časa; Refaktoring uključuje prilagođavanje softvera novom hardveru i novim operativnim sistemima, novim razvojnim alatima, novim zahtjevima i softverskoj arhitekturi i funkcionalnosti. Ovo je promjena interne strukture softvera bez promjene njegovog vanjskog ponašanja, dizajnirana da osigura modifikaciju softvera. Razumni razlozi za refaktoriranje:

Refaktoriranje softvera prilikom promjene programa zahtijeva paralelnu promjenu nekoliko klasa. Ukoliko dođe do takve situacije, potrebno je reorganizirati nastavu kako bi se minimizirala mjesta mogućih promjena u budućnosti; moraju paralelno promijeniti nekoliko hijerarhija nasljeđivanja; morate promijeniti nekoliko blokova padeža. Potrebno je modifikovati program na način da se izvrši implementacija bloka slučaja, i poziva ga potreban broj puta u programu; povezani članovi podataka koji se koriste zajedno nisu organizirani u klase. Ako više puta koristite isti skup elemenata podataka, onda je preporučljivo razmotriti kombinovanje ovih podataka i stavljanje operacija izvršenih na njima u posebnu klasu;

Metoda softverskog refaktoriranja koristi više elemenata druge klase nego svoje vlastite. To znači da metodu treba premjestiti u drugu klasu i pozvati iz stare; elementarni tip podataka je preopterećen. Za opisivanje suštine stvarnog svijeta, bolje je koristiti klasu nego preopteretiti bilo koji postojeći tip podataka; klasa ima suviše ograničenu funkcionalnost. Bolje je da se oslobodite ove klase prenošenjem njene funkcionalnosti u drugu klasu; "zalutali" podaci se prenose duž lanca metoda. Podaci koji se prosljeđuju metodi samo da bi bili proslijeđeni drugoj metodi nazivaju se zalutali podaci. Kada dođe do takvih situacija, pokušajte promijeniti arhitekturu klasa i metoda kako biste ih se riješili.

Refaktoriranje medijskog objekta ne čini ništa. Ako je uloga klase da preusmjerava pozive metoda na druge klase, onda je najbolje eliminisati taj proxy i direktno pozivati ​​druge klase; jedan razred zna previše o drugom razredu. U ovoj situaciji, potrebno je pooštriti inkapsulaciju kako bi se osiguralo da nasljednik ima minimalno znanje o svom roditelju; metoda ima nesrećno ime; podaci članovi su javni. Ovo zamagljuje granicu između interfejsa i implementacije, neizbežno prekida enkapsulaciju i ograničava fleksibilnost programa; postavite komentare u izvorni kod;

Potklasa za refaktoriranje softvera koristi samo mali dio metoda svojih predaka. Ova situacija se događa kada se kreira nova klasa samo da bi naslijedila nekoliko metoda iz osnovne klase, a ne da bi opisala bilo koji novi entitet. Da bi se to izbjeglo, potrebno je transformirati osnovnu klasu na takav način da daje pristup novoj klasi samo metodama koje su joj potrebne; kod sadrži globalne varijable. Samo varijable koje zapravo koristi cijeli program trebaju biti globalne. Sve ostale varijable moraju ili biti lokalne ili moraju postati svojstva nekog objekta; program sadrži kod koji bi jednog dana mogao biti potreban. Prilikom razvoja sistema, preporučljivo je predvidjeti mjesta gdje se izvorni kod može dodati u budućnosti.

U prvom dijelu, odabrali smo da uporedimo metodologije razvoja softvera kao što su pokazatelji kao što su omjer metodologije i iterativnog razvoja i stepen formalnosti u dizajnu radnih materijala i općenito u razvoju. U ovom dijelu koristimo ove metrike da uporedimo najpoznatije prakse razvoja softvera.

Videcemo kako ce biti…

Ajme, ovo je najteže opisati - uostalom, uključuje i proizvod grčevivog bacanja početnika koji po svaku cijenu pokušava dovršiti svoj prvi projekt, kao i prilično zrele i uhodane metodologije koje su upijale mnogo godina različitog iskustva pojedinih razvojnih timova, pa čak i opisanih u internim propisima. Pošto ljudi koji su sposobni da razviju sopstvenu metodologiju, po pravilu, mogu i sami da je procene u smislu iteracije i formalizacije, fokusiraćemo se na početnike. Nažalost, najčešće to znači da pravila za vođenje razvoja ili ne postoje, ili su izrađena i usvojena, ali se ne provode. Prirodan je u takvim uslovima izuzetno nizak nivo formalizma razvoja. Dakle, ovo je sve jasno.

Razvoj "Kako to radi"

Šta kažete na iterativni pristup? Nažalost, po pravilu se ne koristi u takvim projektima. Prije svega, jer bi to omogućilo već u prvim iteracijama da se projekt ocijeni kao krajnje sumnjiv i zahtijeva hitnu intervenciju višeg menadžmenta kako bi se uspostavio red. Uostalom, u iterativnom projektu, tradicionalni odgovor programera da je za njega sve spremno 90 posto traje samo do završetka prve iteracije...

Strukturne metodologije

Strukturne metodologije

Strukturne metode su grupa metodologija razvijenih, po pravilu, čak i prije široke upotrebe objektno orijentiranih jezika. Svi oni uključuju razvoj vodopada. Iako se, pokazalo se, i u tom članku, koji se često navodi kao prvo predstavljanje vodopada pristupa, rečeno da je poželjno započeti projekat izradom prototipa, odnosno izvesti najmanje dvije iteracije.

Ipak, osnova ovih metodologija je uzastopni prelazak sa posla na posao i prenošenje rezultata (dokumenata) sledeće faze na učesnike sledeće.

Takođe, sve ove metodologije pretpostavljaju visoko formalizovan pristup, iako se u njima mogu naći izjave o razumnoj količini dokumentacije. Jedan od neočiglednih primjera da se metodologije razvoja softvera razvijaju ne samo na Zapadu je citat iz knjige objavljene u našoj zemlji početkom 1980-ih, u kojoj se navodi da stepen formalizacije programskog zadatka treba odrediti na osnovu o tome koliko je dobar analitičar i programer. I to uprkos činjenici da je tema knjige uključivala razvoj prilično kritičnih, kako ih sada zovu, sistema, greške u kojima dovode do ozbiljnih gubitaka ili čak katastrofa.

Agilne metodologije

Agilne metodologije zasnivaju se na deset principa, od kojih ćemo navesti samo one koji određuju ocjenu ovih metodologija prema odabranim parametrima:

• glavna stvar je zadovoljiti kupca i dostaviti mu proizvod što je prije moguće;
• nova izdanja proizvoda trebala bi se pojaviti svakih nekoliko sedmica, u ekstremnim slučajevima - mjeseci;
• najefikasniji način prenošenja znanja učesnicima u razvoju i između njih je lična komunikacija;
• tekući program je najbolji pokazatelj napretka razvoja.

Stoga su ove metode jasno fokusirane na iterativni razvoj softvera i minimalnu formalizaciju procesa. Međutim, potrebno je napraviti rezervu u pogledu druge tačke: ove metode su fokusirane na minimalni nivo formalizacije prihvatljiv za dati projekat. Najmanje jedna od metodologija uključenih u fleksibilnu grupu - Crystal - ima modifikacije dizajnirane za izvođenje procesa s različitim brojem učesnika i različitom kritičnošću softvera koji se razvija (kritičnost softvera određena je mogućim posljedicama grešaka, koje mogu varirati od manji finansijski gubici zbog popravljanja greške do katastrofalne). Kako dalje poređenje sa fleksibilnim metodologijama nije besmisleno, daćemo kratke opise nekoliko od njih.

Ekstremno programiranje ili XP (ekstremno programiranje)

XP metodologija, koju su razvili Kent Beck, Ward Cunningham i Ron Jeffries, danas je najpoznatija od agilnih metodologija. Ponekad se sam koncept "agilnih metodologija" eksplicitno ili implicitno poistovjećuje sa XP-om, koji propovijeda društvenost, jednostavnost, povratne informacije i hrabrost. Opisuje se kao skup praksi: igra planiranja, kratka izdanja, metafore, jednostavan dizajn, refaktorisanje koda, razvoj testa unaprijed, programiranje u paru, kolektivno vlasništvo koda, 40-satna radna sedmica, prisustvo kupaca i standardi koda. Interesovanje za XP je raslo odozdo prema gore – od programera i testera, mučenih bolnim procesom, dokumentacijom, metrikom i drugim formalizmom. Nisu odbacivali disciplinu, ali nisu bili voljni da besmisleno slijede formalne zahtjeve i tražili su nove brze i fleksibilne pristupe razvoju visokokvalitetnih programa.

Pri korištenju XP-a, pažljivo preliminarni dizajn softvera zamjenjuje se, s jedne strane, stalnim prisustvom kupca u timu, spremnog da odgovori na svako pitanje i procijeni svaki prototip, a s druge strane redovnim revizijama koda (tzv. refaktoring). Temeljno komentiran kod se smatra osnovom projektne dokumentacije. Mnogo pažnje u metodologiji se poklanja testiranju. U pravilu se za svaku novu metodu prvo napiše test, a zatim se razvija stvarni kod metode sve dok test ne počne uspješno da se izvodi. Ovi testovi su pohranjeni u paketima koji se automatski izvršavaju nakon bilo kakve promjene koda.

Iako su programiranje u paru i 40-satna radna sedmica možda najpoznatije karakteristike XP-a, one su i dalje pomoćne prirode i doprinose visokoj produktivnosti programera i smanjenju grešaka u razvoju.

Kristalno jasno

Crystal je porodica metodologija koje određuju potreban stepen formalizacije procesa razvoja, u zavisnosti od broja učesnika i kritičnosti zadataka.

Crystal Clear metodologija je inferiorna u odnosu na XP u pogledu performansi, ali je što je moguće lakša za korištenje. Za njegovu implementaciju je potreban minimalan napor jer se fokusira na ljudske navike. Smatra se da ova metodologija opisuje prirodni redosled razvoja softvera, koji se uspostavlja u dovoljno kvalifikovanim timovima, ukoliko nisu angažovani na svrsishodnoj implementaciji druge metodologije.

Ključne karakteristike Crystal Clear:

• iterativni inkrementalni razvoj;
• automatsko regresijsko testiranje;
• korisnici su uključeni u aktivno učešće u projektu;
• sastav dokumentacije određuju učesnici projekta;
• po pravilu se koriste alati za kontrolu verzije koda.

Osim Crystal Clear-a, postoji nekoliko drugih metodologija u Crystal porodici dizajniranih za veće ili kritičnije projekte. Razlikuju se po nešto strožim zahtjevima za količinu dokumentacije i pratećih procedura, kao što su promjene i kontrola verzija.

Razvoj vođen funkcijama

Razvoj vođen funkcijama (FDD) funkcioniše u smislu sistemske karakteristike ili karakteristike, što je prilično blisko konceptu slučaja upotrebe RUP-a. Možda je najznačajnija razlika dodatno ograničenje: "svaka funkcija mora omogućiti implementaciju za najviše dvije sedmice." Odnosno, ako je slučaj upotrebe dovoljno mali, može se smatrati funkcijom, a ako je velik, onda ga treba razbiti na nekoliko relativno nezavisnih funkcija.

FDD uključuje pet procesa, pri čemu se posljednja dva ponavljaju za svaku karakteristiku:

• razvoj zajedničkog modela;
• sastavljanje liste potrebnih sistemskih funkcija;
• planiranje rada na svakoj funkciji;
• dizajn funkcije;
• konstrukcija funkcije.

Rad na projektu uključuje česte gradnje i podijeljen je na iteracije, od kojih se svaka implementira pomoću specifičnog skupa karakteristika.

Programeri u FDD-u se dijele na "majstore klase" i "glavne programere". Glavni programeri uključuju vlasnike uključenih klasa da rade na sljedećem posjedu. Poređenja radi: u XP-u nema lično odgovornih za klase ili metode.

Zajedničke karakteristike

Lista fleksibilnih metodologija trenutno je prilično široka. Ipak, metodologije koje smo opisali daju vrlo potpunu sliku cijele porodice.

Gotovo sve agilne metodologije koriste iterativni pristup, gdje je samo ograničena količina rada planirana u detalje, povezana s izdavanjem sljedećeg izdanja.

Gotovo sve agilne metodologije fokusirane su na najneformalniji pristup razvoju. Ako se problem može riješiti u toku normalnog razgovora, onda je bolje to učiniti. Štaviše, odluku je potrebno sastaviti u obliku papirnog ili elektronskog dokumenta samo kada se bez nje ne može.

Agilne metodologije

GOSTs

GOST-ovi, kao i zahtjevi CMM opisani u sljedećem odjeljku, nisu metodologije. Oni, po pravilu, ne opisuju same procese razvoja softvera, već samo formulišu određene zahtjeve za procese, kojima različite metodologije odgovaraju u ovoj ili onoj mjeri. Uspoređivanje zahtjeva prema istim kriterijima prema kojima upoređujemo metodologije pomoći će vam da odmah odlučite koje metodologije trebate koristiti ako trebate razvijati u skladu s GOST-om.

Trenutno su u Rusiji na snazi ​​stari GOST-ovi 19. i 34. serije i noviji GOST R ISO IEC 122207. GOST-ovi 19. i 34. serije su striktno fokusirani na kaskadni pristup razvoju softvera. Razvoj u skladu s ovim GOST-ovima provodi se u fazama, od kojih svaka uključuje izvođenje strogo definiranog posla, a završava se izdavanjem prilično velikog broja vrlo formaliziranih i opsežnih dokumenata. Dakle, odmah striktno pridržavanje ovih standarda ne samo da vodi ka vodopadnom pristupu, već i pruža vrlo visok stepen formalizacije razvoja.

GOST zahtjevi

GOST 12207, za razliku od standarda 19. i 34. serije, opisuje razvoj softvera kao skup glavnih i pomoćnih procesa koji mogu raditi od početka do kraja projekta. Model životnog ciklusa može se odabrati na osnovu karakteristika projekta. Dakle, ovaj GOST ne zabranjuje izričito upotrebu iterativnog pristupa, ali ne preporučuje eksplicitno njegovu upotrebu. GOST 12207 je također fleksibilniji u pogledu zahtjeva za formalnost procesa razvoja. Sadrži samo naznake potrebe da se dokumentuju glavni rezultati svih procesa, ali ne sadrži liste potrebnih dokumenata i uputstva o njihovom sadržaju.

Dakle, GOST 12207 dozvoljava iterativni i manje formalizirani razvoj softvera.

Modeli zrelosti razvojnog procesa (CMM, CMMI)

Pored nacionalnih i međunarodnih standarda, postoji nekoliko pristupa sertifikaciji razvojnog procesa. Najpoznatiji od njih u Rusiji su, očigledno, CMM i CMMI.

CMM (Capability Maturity Model) je model zrelosti procesa razvoja softvera, koji je dizajniran za procjenu stepena zrelosti razvojnog procesa u određenoj kompaniji. Prema ovom modelu postoji pet nivoa zrelosti razvojnog procesa. Prvi nivo odgovara razvoju „kako to ide“, kada programeri pristupaju svakom projektu kao podvigu. Drugi odgovara manje-više uhodanim procesima, kada je moguće sa dovoljno samopouzdanja računati na pozitivan ishod projekta. Treći odgovara prisutnosti razvijenih i dobro opisanih procesa koji se koriste u razvoju, a četvrti odgovara aktivnoj upotrebi metrike u procesu upravljanja za postavljanje ciljeva i praćenje njihovog postizanja. Konačno, peti nivo se odnosi na sposobnost kompanije da po potrebi optimizuje proces.

CMM i CMMI zahtjevi

Nakon pojave CMM-a, počeli su da se razvijaju specijalizovani modeli zrelosti za kreiranje informacionih sistema, za proces odabira dobavljača i neke druge. Na osnovu njih je razvijen integrisani CMMI model (Capability Maturity Model Integration). Osim toga, u CMMI-u je učinjen pokušaj da se prevaziđu nedostaci CMM-a koji su se u to vrijeme pojavili - preuveličavanje uloge formalnih opisa procesa, kada se prisustvo određene dokumentacije cijenilo mnogo više nego samo dobro uhodana, ali nije opisan proces. Međutim, CMMI je također fokusiran na korištenje visoko formaliziranog procesa.

Dakle, osnova CMM i CMMI modela je formalizacija procesa razvoja. Oni ciljaju programere na implementaciju procesa detaljno opisanog u propisima i uputstvima, što zauzvrat ne može a da ne zahtijeva izradu velike količine projektne dokumentacije za odgovarajuću kontrolu i izvještavanje.

Odnos CMM i CMMI prema iterativnom razvoju je indirektniji. Formalno, nijedna od njih nije postavila posebne zahtjeve za pridržavanje vodopada ili iterativnog pristupa. Međutim, prema nekim stručnjacima, CMM je kompatibilniji sa vodopadnim pristupom, dok CMMI također omogućava iterativni pristup.

RUP

Naravno, RUP je iterativna metodologija. Iako formalno nigdje u RUP-u nije naznačeno obavezno izvršavanje svih faza ili neki minimalni broj iteracija, cijeli pristup je usmjeren na to da ih ima dosta. Ograničeni broj iteracija ne dozvoljava vam da u potpunosti iskoristite prednosti RUP-a. Istovremeno, RUP se također može koristiti u gotovo kaskadnim projektima, koji zapravo uključuju samo nekoliko iteracija: jednu u fazi izgradnje i drugu u fazi prijenosa. Usput, ovo je broj iteracija koji se zapravo koristi u projektima vodopada. Na kraju krajeva, testiranje i probni rad sistema podrazumeva unošenje korekcija, koje mogu uključivati ​​određene radnje vezane za analizu, projektovanje i razvoj, odnosno one su zapravo još jedan prolaz kroz sve faze razvoja.

RUP metodologija

Što se tiče formalnosti metodologije, RUP korisniku pruža veoma širok spektar mogućnosti. Ako obavite sve poslove i zadatke, kreirate sve artefakte, i prilično formalno (sa službenim recenzentom, uz pripremu kompletne recenzije u obliku elektronskog ili papirnog dokumenta, itd.) izvršite sve recenzije, RUP može izvršiti kao krajnje formalna, teška metodologija. Istovremeno, RUP vam omogućava da razvijete samo one artefakte i izvršite samo one radove i zadatke koji su neophodni u određenom projektu. A odabrani artefakti se mogu izvršiti i pregledati uz proizvoljan stepen formalnosti. Moguće je zahtevati detaljnu studiju i pažljivo izvođenje svakog dokumenta, obezbeđivanje jednako pažljivo obavljene i formalizovane recenzije, pa čak i, po staroj praksi, svaku takvu recenziju odobriti na naučno-tehničkom savetu preduzeća. Ili se možete ograničiti na e-poštu ili skicu na papiru. Osim toga, uvijek postoji još jedna mogućnost: formirati dokument u svojoj glavi, odnosno razmisliti o relevantnom pitanju i donijeti konstruktivnu odluku. A ako se ova odluka tiče samo vas, onda se ograničite, na primjer, na komentar u programskom kodu.

Dakle, RUP je iterativna metodologija sa vrlo širokim spektrom mogućih rješenja u smislu formalizacije razvojnog procesa.

Hajde da rezimiramo drugi dio članka. RUP, za razliku od većine drugih metodologija, omogućava odabir stepena formalizacije i ponavljanja procesa razvoja u širokom rasponu, ovisno o karakteristikama projekta i organizacije koja se razvija.

A zašto je to toliko važno - razgovaraćemo u narednom delu.