Pristupi razvoju softvera. Strukturni pristup

1.Kodiranje

U fazi razvoja softvera izvode se sljedeće glavne radnje: kodiranje; testiranje; razvoj PP sustava pomoći; izrada korisničke dokumentacije; izradu verzije i instalaciju softvera,

Kodiranje je proces pretvaranja rezultata dizajna visoke i niske razine u gotov softverski proizvod. Drugim riječima, prilikom kodiranja, kompajlirani programski model opisuje se odabranim programskim jezikom, koji može biti bilo koji od postojećih jezika. Izbor jezika provodi se ili na zahtjev kupca ili uzimajući u obzir problem koji se rješava i osobno iskustvo programera.

Prilikom kodiranja morate slijediti standard za odabrani jezik, npr. za jezik C to je ANSI C, a za C++ ISO/IEC 14882 “Standard for the C++ ProgrammingLanguage”.

Osim općeprihvaćenog standarda za programski jezik, tvrtka može razviti i vlastite dodatne zahtjeve za pravila pisanja programa. Uglavnom se tiču ​​pravila za oblikovanje programskog teksta.

Poštivanje standarda i pravila tvrtke omogućuje vam da izradite program koji radi ispravno, jednostavan je za čitanje i razumljiv drugim programerima, koji sadrži informacije o programeru, datumu stvaranja, imenu i namjeni, kao i potrebne podatke za upravljanje konfiguracijom.

U fazi kodiranja, programer piše programe i sam ih testira. Ova vrsta testiranja naziva se jedinično testiranje. Sva pitanja vezana uz testiranje softvera razmatraju se u poglavlju. 10, ovdje je također opisana tehnologija testiranja koja se koristi u fazi razvoja softvera. Ova tehnologija se zove testiranje "staklena kutija" (glassbox); ponekad se naziva i testiranje "bijela kutija" (whitebox) za razliku od klasičnog koncepta “crne kutije”.

U testiranju crne kutije, program se tretira kao objekt čija je unutarnja struktura nepoznata. Tester unosi podatke i analizira rezultat, ali ne zna točno kako program radi. Pri odabiru testova stručnjak traži ulazne podatke i uvjete koji su mu zanimljivi, što može dovesti do nestandardnih rezultata. Primarno ga zanimaju oni predstavnici svake klase ulaznih podataka kod kojih postoji najveća vjerojatnost pojave grešaka u programu koji se testira.

Kod testiranja “staklene kutije” situacija je potpuno drugačija. Tester (u ovom slučaju sam programer) razvija testove temeljene na poznavanju izvornog koda, kojemu ima puni pristup. Kao rezultat toga, on prima sljedeće pogodnosti.

1. Smjer ispitivanja. Programer može testirati program u dijelovima, razviti posebne testne potprograme koji pozivaju testirani modul i prenose mu podatke od interesa za programera. Mnogo je lakše testirati zasebni modul kao "staklenu kutiju".

2. Potpuna pokrivenost kodom. Programer uvijek može odrediti koji fragmenti koda rade u svakom testu. On vidi koje druge grane koda ostaju neprovjerene i može odabrati uvjete pod kojima će biti testirane. U nastavku opisujemo kako pratiti stupanj pokrivenosti koda izvedenih testova.

3. Sposobnost kontrole tijeka naredbi. Programer uvijek zna koja bi funkcija trebala biti sljedeća u programu i kakvo bi trebalo biti njegovo trenutno stanje. Kako bi saznao radi li program onako kako misli da radi, programer može uključiti naredbe za ispravljanje pogrešaka koje prikazuju informacije o njegovom napretku ili za to upotrijebiti poseban softverski alat koji se zove program za ispravljanje pogrešaka. Debugger može učiniti puno 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 treba promijeniti svaki element podataka. Prateći stanje podataka (koristeći isti program za ispravljanje pogrešaka), on može identificirati pogreške kao što su podaci koje mijenjaju pogrešni moduli, njihova netočna interpretacija ili neuspješna organizacija.Programer može sam automatizirati testiranje.

5.Vizija unutarnjih graničnih točaka. U izvornom kodu vidljive su one granične točke programa koje su skrivene od pogleda izvana. Na primjer, nekoliko potpuno različitih algoritama može se koristiti za izvođenje određene akcije, a bez uvida u kôd nemoguće je utvrditi koji je programer odabrao. Još jedan čest primjer bio bi problem prelijevanja u međuspremniku koji se koristi za privremeno pohranjivanje ulaznih podataka. Programer može odmah reći pri kojoj će se količini podataka međuspremnik preliti i ne mora provoditi tisuće testova.

6. Mogućnost testiranja određena odabranim algoritmom. Testiranje obrade podataka koja koristi vrlo složene računalne algoritme može zahtijevati posebne tehnologije. Klasični primjeri uključuju transformaciju matrice i sortiranje podataka. Tester, za razliku od programera, treba točno znati koji se algoritmi koriste, pa se mora obratiti stručnoj literaturi.

Testiranje staklene kutije dio je procesa programiranja. Programeri rade taj posao stalno, testiraju svaki modul nakon što je napisan, pa opet nakon integracije u sustav.

Prilikom izvođenja jediničnog testiranja možete koristiti strukturnu ili funkcionalnu tehnologiju testiranja ili oboje.

Strukturalni testiranje je vrsta ispitivanja staklene kutije. Njegova glavna ideja je ispravan odabir softverskog puta koji se testira. Nasuprot njemu funkcionalni testiranje spada u kategoriju testiranja crne kutije. Svaka funkcija programa testira se unosom ulaznih podataka i analizom izlaza. Pritom se vrlo rijetko uzima u obzir unutarnja struktura programa.

Iako strukturalno ispitivanje ima mnogo jaču teorijsku osnovu, većina ispitivača preferira funkcionalno ispitivanje. Strukturno ispitivanje bolje je podložno matematičkom modeliranju, ali to ne znači da je učinkovitije. Svaka vam tehnologija omogućuje prepoznavanje pogrešaka koje ste propustili korištenjem one druge. S ove točke gledišta, mogu se nazvati jednako učinkovitima.

Objekt testiranja može biti ne samo cijeli put programa (slijed naredbi koje izvršava od početka do kraja), već i njegovi pojedinačni dijelovi. Apsolutno je nerealno testirati sve moguće načine izvršavanja programa. Stoga stručnjaci za testiranje iz svih mogućih puteva identificiraju one skupine koje apsolutno trebaju biti testirane. Za odabir koriste posebne kriterije tzv kriteriji pokrivenosti (coveragecriteria), koji određuju vrlo stvaran (čak i prilično velik) broj testova. Ti se kriteriji ponekad nazivaju logički kriteriji pokrivenosti, ili kriteriji potpunosti.

3. Razvoj sustava pomoći za programski proizvod. Izrada korisničke dokumentacije

Preporučljivo je imenovati jednog od djelatnika projekta za tehničkog urednika dokumentacije. Ovaj zaposlenik može obavljati i druge poslove, ali bi njegova glavna zadaća trebala biti analiza dokumentacije, čak i ako je izrađuju i drugi zaposlenici.

Često se događa da na izradi softvera radi više ljudi, ali nitko od njih ne snosi punu odgovornost za njegovu kvalitetu. Time softver ne samo da nema koristi od činjenice da ga razvija više ljudi, nego i gubi jer svatko podsvjesno prebacuje odgovornost na drugoga i očekuje da će njegovi kolege obaviti ovaj ili onaj dio posla. Ovaj problem je riješen imenovanjem urednika koji snosi punu odgovornost za kvalitetu i točnost tehničke dokumentacije.

PP sustav pomoći formiran je na temelju materijala razvijenog za korisnički priručnik. Formira ga i stvara osoba odgovorna za obavljanje ovog posla. To može biti ili tehnički urednik ili jedan od programera zajedno s tehničkim urednikom.

Dobro dokumentiran PP ima sljedeće prednosti.

1. Jednostavnost korištenja. Ako je softver dobro dokumentiran, mnogo ga je lakše primijeniti. Korisnici to brže uče, manje griješe i kao rezultat rade svoj posao brže i učinkovitije.

2. Niži troškovi tehničke podrške. Kada korisnik ne može shvatiti kako izvršiti radnje koje su mu potrebne, on poziva službu tehničke podrške proizvođača PCB-a. Vođenje takve usluge je vrlo skupo. Dobar priručnik pomaže korisnicima da sami riješe probleme i smanji potrebu za kontaktiranjem tima tehničke podrške.

3. Visoka pouzdanost. Nerazumljiva ili neuredna dokumentacija čini softver manje pouzdanim, jer je vjerojatnije da će njegovi korisnici činiti pogreške i teško im je razumjeti što ih je uzrokovalo i kako se nositi s njihovim posljedicama.

Lakoća održavanja. Ogromna količina novca i vremena troši se na analizu problema koji su uzrokovani korisničkim pogreškama. Promjene napravljene u novim izdanjima softvera često su jednostavno promjene sučelja starih funkcija. Uvode se kako bi korisnici konačno shvatili kako koristiti softver i prestali zvati tehničku podršku. Dobro upravljanje u velikoj mjeri

Pri razmatranju tehnologije razvoja softvera potrebno je koristiti sustavan pristup, koji podrazumijeva razmatranje ne pojedinih pojedinačnih aspekata problema razvoja softvera, već problema u cjelini. Sistemski pristup provodi se u prostoru i vremenu.

Sustavni pristup u vremenu razmatra slijed faza stvaranja softvera od trenutka nastanka nezadovoljene potrebe za softverom dok se ne riješi i podrška u radu dobivenog softverskog proizvoda.

Sustavni pristup u "svemiru" uključuje razmatranje softvera koji se razvija kao dijela sustava. Istovremeno, na temelju proučavanja informacijskih potreba sustava, koji će uključivati ​​razvijeni softver, formuliraju se ciljevi i skup funkcija softvera, te se analiziraju prototipovi softvera. Softverski zahtjevi su generirani i dokumentirani.

Suvremena tehnologija razvoja softvera programiranje smatra jednom od razvojnih faza u nizu uzastopnih faza razvojnog ciklusa. Sve te faze objedinjuje koncept životnog ciklusa softvera i moraju biti podržani odgovarajućim softverskim i hardverskim alatima.

U skladu s međunarodnom normom ISO/IEC 12207 “Informacijska tehnologija - Procesi životnog ciklusa softvera”, proces razvoja softvera sadrži sljedeće faze životnog ciklusa softvera:

1) analiza zahtjeva sustava i opsega primjene;

2) projektiranje arhitekture sustava;

3) analiza softverskih zahtjeva (specifikacije, vanjska sučelja);

4) dizajn softverske arhitekture;

5) detaljni dizajn svake programske cjeline;

6) softversko kodiranje (programiranje)

7) testiranje programskih jedinica;

8) integracija (softverska kombinacija) i testiranje skupa programskih jedinica;

9) testovi kvalifikacije softvera (sveobuhvatno testiranje);

10) programske strukturne jedinice integracije sustava moraju biti integrirane sa hardverskim jedinicama;

11) testove kvalifikacije sustava;

12) instalacija softvera.

Dakle, proces razvoja softvera počinje od sustava u kojem će se softver koristiti i ponovno završava u sustavu.

Nakon razvojnih faza u životnom ciklusu softvera, slijedi faza rada softvera i održavanja tijekom rada. Ponekad se daje popis faza životnog ciklusa softvera s nekim generalizacijama (povećanjima) zadanih 12 faza. Na primjer, faze projektiranja sustava i određivanje softverskih zahtjeva, dizajn programskog paketa, dizajn softverskog algoritma, programiranje (kodiranje), autonomno otklanjanje pogrešaka softvera, integrirano otklanjanje pogrešaka softvera, rad softvera.

Zanemarivanje faza dizajna softvera, želja da se odmah krene u programiranje bez dovoljno razrađenih algoritama i problematika interakcije strukturnih jedinica softvera često dovodi do kaotičnog procesa razvoja softvera s malim izgledima za uspjeh.

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

Razmatrani model životnog ciklusa (LC) je model kaskadnog tipa. Ovakav model životnog ciklusa dobar je za softver za koji je moguće potpuno i točno formulirati sve softverske zahtjeve na samom početku razvoja.

Shema softvera spiralnog životnog ciklusa. Međutim, stvarni proces stvaranja softvera ne uklapa se uvijek u tako krutu shemu i često postoji potreba za vraćanjem na prethodne faze uz pojašnjenje ili reviziju donesenih odluka.

Softver, kao i druge složene sustave za koje početni zahtjevi nisu dovoljno potpuni, karakterizira iterativni proces razvoja. Štoviše, za neke vrste softvera čak je poželjno prijeći na sljedeću fazu što je brže moguće. Istovremeno, nedostaci koji su neizbježni pri tako žurnome radu eliminiraju se u sljedećoj iteraciji ili ostaju zauvijek.

Glavni zadatak je postići što brži rad softvera, čime se aktivira proces pojašnjenja i dopune zahtjeva. To je takozvani spiralni model životnog ciklusa softvera.

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

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

Postoji smjer “Brze tehnologije” razvoja softvera (Agile Software Development), koji daje ideološko opravdanje za stavove vezane uz spiralni model životnog ciklusa. Te se tehnologije temelje na četiri ideje:

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

Softver koji radi je važniji od dokumentacije za njega,

Suradnja s kupcem važnija je od formalnih ugovora,

Brza reakcija na vanjske promjene važnija je od strogog pridržavanja planova.

Riža. 8.2 - Shema softvera životnog ciklusa spirale

Drugim riječima, brze tehnologije usmjerene su na zamjenu formalnih i radno intenzivnih dokumentiranih postupaka interakcije tijekom razvoja interaktivnim, što je moguće uz malu veličinu projekta, odabrane kvalitete zaposlenika, smještanje programera i korisnika „u istu prostoriju“ te za razvoj softver za nekritične sustave.

Ispravnost ovih načela u određenoj mjeri, kada se razvojem softvera bavi mali broj kvalificiranih i predanih “ljubitelja”) razvoja određenih vrsta softvera, teško je osporiti. Međutim, Agile tehnologije, a to prepoznaju i njihovi ideolozi, primjenjive su u softverskim projektima određene klase i razmjera, baš kao i spiralni model životnog ciklusa općenito, odnosno gdje softverske pogreške dovode do neugodnosti ili gubitka nadoknadivih sredstava.

Tamo gdje neispravan softver dovodi do prijetnje ljudskim životima ili velikim materijalnim gubicima, treba koristiti sveobuhvatne, dobro promišljene tehnologije kako bi se osigurala pouzdanost softverskog proizvoda.

S povećanjem razmjera softverskog projekta i povećanjem broja ljudi koji u njemu sudjeluju, raste potreba za krutom razvojnom tehnologijom koja čini kaskadni životni ciklus softvera. Ovdje je potrebna dokumentacija, budući da je gubitak bilo kojeg od programera moguć u bilo kojem trenutku, potrebno je formalizirati međuprogramske veze, upravljati promjenama softvera itd. Nije uzalud kaskadni model životnog ciklusa uključen u softver razvojni standardi. U isto vrijeme, također vam omogućuje implementaciju iterativnog procesa razvoja zbog propisanih faza u dizajnu STS-a i softvera za njih.

Za vrlo velike softverske projekte (tim programera od više od 100), razvojna tehnologija je ključni čimbenik koji utječe ne samo na kvalitetu softvera, već i na samu mogućnost njegove izrade.

“Teške i lagane” tehnologije razvoja softvera . Razvojni programeri mnogih tipova softvera smatraju da je model životnog ciklusa vodopada previše reguliran, previše dokumentiran i težak te stoga iracionalan. Postoji smjer “Brze tehnologije” (light technology) razvoja softvera (Agile Software Development), koji daje ideološko opravdanje za ovakva stajališta. Te se tehnologije temelje na četiri ideje:

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

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

3. suradnja s kupcem važnija je od formalnih ugovora s njim,

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

Ispravnost ovih načela, osim trećeg u određenoj mjeri (razvojom softvera bavi se mali broj kvalificiranih programera – „fanova“ kojima nije potrebna kontrola i dodatna motivacija) za razvoj softvera teško je osporiti. Međutim, Agile tehnologije, a to priznaju i njihovi ideolozi, primjenjive su u softverskim projektima određene klase i razmjera, kao iu spiralnom modelu životnog ciklusa općenito, naime gdje softverske pogreške dovode do nekih neugodnosti ili gubitka nadoknadivih sredstava i gdje se programski zahtjevi stalno mijenjaju, budući da su unaprijed loše definirani, te je potrebna brza prilagodba tim promjenama.

Brze tehnologije – pokušava postići kompromis između stroge razvojne discipline i njezinog potpunog izostanka u ime smanjenja protoka papira koji prate razvoj.Brze tehnologije ne mogu osigurati visoku pouzdanost softverskog proizvoda upravo zbog minimiziranja papira koji pravno potvrđuju odgovornost programera. .

Primjer Agile tehnologije je Extreme Programming (XP). Iteracije u XP-u su vrlo kratke i sastoje se od četiri operacije: kodiranje, testiranje, slušanje kupca, projektiranje. Načela XP-a - minimalizam, jednostavnost, sudjelovanje korisnika, kratki ciklus, bliska interakcija između programera - trebali bi sjediti u istoj prostoriji, dnevni operativni sastanci s korisnikom čine se razumnim i odavno se koriste ne samo u brzim tehnologijama, već iu XP-u dovode se 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 česte i često također dovode do uspjeha, čineći većina značajki rada u malim timovima.

Tamo gdje neispravno funkcioniranje softvera dovodi do prijetnje ljudskim životima ili velikim materijalnim gubicima, treba koristiti uredne, potpuno promišljene i predvidljive formalizirane "teške" tehnologije, osiguravajući pouzdanost softverskog proizvoda čak iu slučaju srednje kvalificiranih programera S povećanjem razmjera softverskog projekta, povećanjem broja sudionika. U ovom području raste potreba za krutom i formalnom razvojnom tehnologijom koja utvrđuje odgovornost svakog sudionika u razvoju koji čini kaskadni životni ciklus softvera. . Nije uzalud kaskadni model životnog ciklusa uključen u standarde razvoja softvera.

U velikim razvojnim timovima problem upravljanja dolazi do izražaja.

Za vrlo velike softverske projekte ključna su pitanja urednog, koordiniranog razvoja: strukturiranje, integracija, osiguravanje ispravne interakcije programa, organiziranje ispravne i koordinirane provedbe neizbježnih promjena te utjecati na samu mogućnost njihova nastanka.

Kod malih softverskih projekata odlučujuću ulogu imaju algoritamske dorade i utjecaj pojedinih talentiranih pojedinaca, dok su kod velikih projekata ti faktori nivelirani i nemaju presudan utjecaj na napredak razvoja.

Programeri prosječnih sposobnosti, kojih je većina, koji održavaju tehnološku disciplinu unutar prave tehnologije, moraju razvijati softver potrebne kvalitete. “Održavajte red i on će vas podržati.”

Napomena: Razmatran je fleksibilni pristup izradi softvera i osnovni principi fleksibilnog razvoja. Naveden je popis tehnika koje u određenoj mjeri odgovaraju načelima fleksibilnog razvoja softvera. Analizirane su 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 je usmjeren na korištenje iterativnog pristupa, u kojem softver stvara se postupno, u malim koracima, uključujući implementaciju određenog skupa zahtjeva. Pretpostavlja se da se zahtjevi mogu promijeniti. Agilne timove čine svestrani programeri koji obavljaju različite zadatke u procesu kreiranja softverskog proizvoda.

Kada se koriste agilne metodologije, rizici se minimiziraju svođenjem razvoja na niz kratkih ciklusa tzv. ponavljanja, u trajanju od 2-3 tjedna. Iteracija je skup zadataka koji se planiraju izvršiti tijekom određenog vremenskog razdoblja. U svakoj iteraciji kreira se funkcionalna verzija softverskog sustava, koja implementira najviši prioritet (za ovu iteraciju) korisnički zahtjevi. Svaka iteracija obavlja sve zadatke potrebne za stvaranje radnog softvera: planiranje, analizu zahtjeva, dizajn, kodiranje, testiranje i dokumentacija. Iako jedna iteracija općenito nije dovoljna za izdavanje nove verzije proizvoda, to podrazumijeva da trenutni softver spreman za puštanje na kraju svake iteracije. Na kraju svake iteracije, tim ponovno procjenjuje prioritete zahtjeva za softverski proizvod, moguće prilagođavajući razvoj sustava.

Principi i značenje agilnog razvoja

Metodologija agilnog razvoja proglasila je ključne postulate koji timovima omogućuju postizanje visoke produktivnosti:

• ljudi i njihove interakcije;
• isporuka radnog softvera;
• suradnja s kupcem;
• reakcija na promjenu.

Ljudi i interakcija. Ljudi su najvažnija komponenta uspjeha. Individualni članovi tima i dobra komunikacija važni su za timove s visokim učinkom. Kako bi se olakšala komunikacija, agilne metode uključuju česte rasprave o rezultatima rada i promjenama odluka. Rasprave se mogu voditi dnevno u trajanju od nekoliko minuta i na kraju svake iteracije uz analizu rezultata rada i retrospektivu. Za učinkovitu komunikaciju tijekom sastanaka, članovi tima trebaju se pridržavati sljedećih ključnih pravila ponašanja:

• poštivanje mišljenja svakog člana tima;
• biti iskren u svim komunikacijama;
• transparentnost svih podataka, radnji i odluka;
• povjerenje da će svaki sudionik podržati tim;
• predanost timu i njegovim ciljevima.

Za stvaranje timova visokih performansi u fleksibilnim metodologijama, osim učinkovitog tima i dobre komunikacije, potrebni su i savršeni softverski alati.

Softver koji radi je važniji od sveobuhvatne dokumentacije. Sve agilne metodologije naglašavaju potrebu isporuke malih dijelova radnog softvera kupcu u određenim intervalima. Softver, u pravilu, mora proći razinu jediničnog testiranja, testiranje na razini sustava. U ovom slučaju količina dokumentacije treba biti minimalna. Tijekom procesa projektiranja, tim bi trebao održavati ažuran kratki dokument koji sadrži obrazloženje odluke i opis strukture.

Suradnja s kupcem važnija je od formalnih ugovornih dogovora. Kako bi se projekt uspješno završio potrebna je redovita i česta komunikacija s kupcem. Kupac mora redovito sudjelovati u raspravi o donesenim odlukama o softveru, izražavati svoje želje i komentare. Uključivanje korisnika u proces razvoja softvera nužno je za stvaranje kvalitetnog proizvoda.

Brzo reagiranje na promjene važnije je od slijeđenja plana. Sposobnost reagiranja na promjene uvelike određuje uspjeh softverskog projekta. Tijekom procesa stvaranja softverskog proizvoda, korisnički zahtjevi. Kupci vrlo često ne znaju točno što žele dok ne vide nešto što funkcionira. softver. Agilne metodologije traže povratne informacije od kupaca tijekom procesa stvaranja softverskog proizvoda. Spremnost na promjene ključna je za stvaranje proizvoda koji zadovoljava kupca i pruža poslovnu vrijednost.

Načela agilnog razvoja podupiru 12 načela. Specifične agilne razvojne metodologije definiraju procese i pravila koja se više ili manje pridržavaju ovih načela. Fleksibilne metodologije za izradu softverskih proizvoda temelje se na sljedećim načelima:

1. Najveći prioritet je zadovoljiti želje kupca kroz isporuku korisnog softvera u kratkom vremenu, nakon čega slijedi kontinuirano ažuriranje. Agilne metodologije uključuju brzu isporuku početne verzije i česta ažuriranja. Cilj tima je isporučiti radnu verziju unutar nekoliko tjedana od početka projekta. Ubuduće, softverski sustavi s postupno sve većom funkcionalnošću trebali bi se isporučivati ​​svakih nekoliko tjedana. Kupac može započeti s komercijalnim radom sustava ako ga smatra dovoljno funkcionalnim. Također, korisnik se može jednostavno upoznati s trenutnom verzijom softvera i dati svoje povratne informacije s komentarima.
2. Nemojte ignorirati promjenjive zahtjeve, čak ni u kasnim fazama razvoja. Agilni procesi omogućuju prilagođavanje promjenama kako bi se kupcu pružila konkurentska prednost. Timovi koji koriste agilne metode nastoje osigurati kvalitetnu programsku strukturu, s minimalnim utjecajem promjena na sustav u cjelini.
3. Nove radne verzije softvera isporučujte često, u intervalima od tjedan do dva mjeseca, uz prednost kraćim rokovima. Cilj je isporučiti program koji zadovoljava potrebe korisnika uz minimum popratne dokumentacije.
4. Klijenti i programeri moraju raditi zajedno tijekom cijelog projekta. Vjeruje se da za uspješan projekt korisnici, programeri i sve zainteresirane strane moraju često i opsežno komunicirati kako bi svrhovito poboljšali softverski proizvod.
5. Projekte moraju provoditi motivirani ljudi. Stvorite normalne uvjete za rad projektnog tima, pružite potrebnu podršku i vjerujte da će članovi tima dovesti posao do kraja.
6. Najučinkovitiji i najučinkovitiji 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 stvaraju i ažuriraju postupno kako se razvija softver i samo kada je to potrebno.
7. Radni program je glavni pokazatelj napretka u projektu. Pristup dovršetku agilnog projekta ocjenjuje se prema tome koliko dobro trenutno dostupan softver zadovoljava zahtjeve korisnika.
8. Agilni procesi potiču dugoročni razvoj. Kupci, programeri i korisnici moraju biti u mogućnosti održavati konstantan tempo unedogled.
9. Neumorni fokus na tehničku izvrsnost i kvalitetan dizajn povećava utjecaj agilnih tehnologija. Agilni članovi tima nastoje proizvesti kvalitetan kod redovitim refaktoriranjem.
10. Jednostavnost je umjetnost postizanja više radeći manje. Članovi tima rješavaju trenutne probleme što jednostavnije i učinkovitije. Ako se u budućnosti pojavi bilo kakav problem, moguće je napraviti izmjene u visokokvalitetnom kodu bez velikih troškova.
11. Najbolje arhitekture, zahtjevi i dizajni dolaze od samoorganizirajućih timova. U agilnim timovima zadaci se ne dodjeljuju pojedinačnim članovima, već timu kao cjelini. Tim odlučuje kako najbolje implementirati zahtjeve korisnika. Članovi tima rade zajedno na svim aspektima projekta. Svaki sudionik može doprinijeti zajedničkoj stvari. Ne postoji član tima koji je isključivo odgovoran za arhitekturu, zahtjeve ili testove.
12. Tim mora redovito razmišljati o tome kako postati još učinkovitiji, a zatim prilagoditi i prilagoditi svoje ponašanje u skladu s tim. Agilni tim kontinuirano prilagođava svoju organizaciju, pravila, dogovore i odnose.

Gore navedena načela u određenoj mjeri odgovaraju brojnim metodologijama razvoja softvera:

Agilno modeliranje	skup koncepata, principa i tehnika (praksa) koji vam omogućuju brzo i jednostavno izvođenje modeliranja i dokumentacije u projektima razvoja softvera;
AgileUnifiedProcess (AUP)	pojednostavljena verzija IBM RationalUnifiedProcess(RUP), koja opisuje jednostavnu i razumljivu aproksimaciju (model) za kreiranje softvera za poslovne aplikacije;
Otvoriti	To je iterativno-inkrementalna metoda razvoja softvera. Pozicioniran kao lagana i fleksibilna verzija RUP-a;
AgileDataMethod	skupina iterativnih metoda razvoja softvera u kojima se zahtjevi i rješenja postižu kroz suradnju različitih međufunkcionalnih timova;
DSDM	metodologija razvoja dinamičkih sustava temeljena na konceptu brzog razvoja aplikacija (RapidApplicationDevelopment, RAD). To je iterativni i inkrementalni pristup koji naglašava stalnu uključenost korisnika/potrošača u proces;
Ekstremno programiranje (XP)	ekstremno programiranje;
Adaptivni razvoj softvera (ADD)	adaptivni razvoj softvera;
Razvoj vođen značajkama (FDD)	razvoj usmjeren na postupno dodavanje funkcionalnosti;
GettingReal	iterativni pristup bez funkcionalnih specifikacija koji se koristi za web aplikacije;
MSFogAgileSoftwareDevelopment	Microsoftova fleksibilna metodologija razvoja softvera;
Ološ	uspostavlja pravila za upravljanje procesom razvoja i omogućuje vam korištenje postojeće prakse kodiranja, prilagodbu zahtjeva ili pravljenje taktičkih promjena [

Vodopadni model Analiza zahtjeva Dizajn Implementacija Integracija Testiranje Kreiranje specifikacije proizvoda Kreiranje arhitekture proizvoda Razvoj izvornog koda Integracija pojedinačnih dijelova izvornog koda Testiranje i otklanjanje nedostataka

Model slučaja upotrebe Unified Software Development Process (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 dodijeljenih objekata Model implementacije opisuje distribuciju softvera preko računala. Implementacijski model opisuje unutarnju organizaciju programskog koda. Testni model sastoji se od testnih komponenti, testnih procedura i raznih testnih slučajeva.

Tipične komponente arhitekture softverskog proizvoda i tipični softverski zahtjevi Organizacija programa Osnovne klase sustava Organizacija podataka Poslovna pravila Korisničko sučelje Upravljanje resursima Sigurnost Performanse Skalabilnost Interakcija s drugim sustavima (integracija) Internacionalizacija, lokalizacija Ulaz/izlaz podataka Rješavanje grešaka

Tipične komponente arhitekture softverskog proizvoda i tipični softverski zahtjevi Tolerancija na greške je skup svojstava sustava koji povećava njegovu pouzdanost otkrivanjem grešaka, oporavkom i lokaliziranjem loših posljedica za sustav. Prilikom projektiranja bilo kojeg stvarnog sustava kako bi se osigurala tolerancija na kvarove, potrebno je predvidjeti sve moguće situacije koje mogu dovesti do kvara sustava i razviti mehanizme za postupanje s kvarovima. Pouzdanost je sposobnost sustava da izdrži razne kvarove i kvarove. Kvar je prijelaz sustava u potpuno neoperativno stanje kao rezultat pogreške. Kvar je greška u radu sustava koja ne dovodi do kvara sustava. Što je manje kvarova i kvarova u određenom vremenskom razdoblju, sustav se smatra pouzdanijim.

Tipične komponente arhitekture programskog proizvoda i tipični programski zahtjevi Mogućnosti implementacije razvijene arhitekture. Mogućnost implementacije razvijene arhitekture. Redundantna funkcionalnost. Redundantna funkcionalnost. Donošenje odluke o kupnji gotovih programskih komponenti. Donošenje odluke o kupnji gotovih programskih komponenti. Promjena strategije. Promjena strategije.

Je li cjelokupna organizacija programa jasno opisana; uključuje li specifikacija pregled arhitekture i njezino obrazloženje. Je li cjelokupna organizacija programa jasno opisana; uključuje li specifikacija pregled arhitekture i njezino obrazloženje. Jesu li glavne komponente programa, njihove odgovornosti i interakcije s drugim komponentama adekvatno definirane? Jesu li glavne komponente programa, njihove odgovornosti i interakcije s drugim komponentama adekvatno definirane? Jesu li sve funkcije navedene u specifikaciji zahtjeva implementirane razumnim brojem komponenti sustava. Jesu li sve funkcije navedene u specifikaciji zahtjeva implementirane razumnim brojem komponenti sustava. Postoji li opis najvažnijih klasa i njihovo obrazloženje? Postoji li opis najvažnijih klasa i njihovo obrazloženje? Je li dan opis organizacije baze podataka? Je li dan opis organizacije baze podataka? Jesu li definirana sva poslovna pravila? Jesu li definirana sva poslovna pravila? Je li opisan njihov utjecaj na sustav? Je li opisan njihov utjecaj na sustav? Kontrolni popis pitanja koji vam omogućuje da izvučete zaključak o kvaliteti arhitekture:

Kontrolni popis pitanja koji vam omogućuje prosuđivanje kvalitete arhitekture: Je li opisana strategija dizajna korisničkog sučelja? Je li opisana strategija dizajna korisničkog sučelja? Je li korisničko sučelje izrađeno modularno tako da promjene na njemu ne utječu na ostatak sustava. Je li korisničko sučelje izrađeno modularno tako da promjene na njemu ne utječu na ostatak sustava. Postoji li opis strategije unosa/izlaza podataka? Postoji li opis strategije unosa/izlaza podataka? Je li analizirana izvedba sustava koji će biti implementiran pomoću ove arhitekture? Je li analizirana izvedba sustava koji će biti implementiran pomoću ove arhitekture? Je li provedena analiza pouzdanosti projektiranog sustava? Je li provedena analiza pouzdanosti projektiranog sustava? Je li provedena analiza skalabilnosti i proširivosti sustava? Je li provedena analiza skalabilnosti i proširivosti sustava?

Refactoring softvera Kod se ponavlja; implementacija metode je prevelika; ima previše ugniježđenih petlji ili je sama petlja jako velika; klasa ima lošu povezanost (svojstva i metode klase trebaju opisivati ​​samo 1 objekt); sučelje klase ne tvori dosljednu apstrakciju; Metoda uzima previše parametara. Potrebno je nastojati da broj parametara bude razumno minimalan; pojedini dijelovi razreda mijenjaju se neovisno o ostalim dijelovima razreda; Refactoring uključuje prilagodbu softvera novom hardveru i novim operativnim sustavima, novim razvojnim alatima, novim zahtjevima, kao i arhitekturi i funkcionalnosti softvera. Ovo je promjena unutarnje strukture softvera bez promjene njegovog vanjskog ponašanja, osmišljena da osigura modifikaciju softvera. Razumni razlozi za refaktoriranje:

Refactoring softvera: Prilikom promjene programa potrebno je paralelno promijeniti nekoliko klasa. Ukoliko dođe do takve situacije, potrebno je reorganizirati nastavu kako bi se mjesta mogućih promjena u budućnosti svela na minimum; morate paralelno promijeniti nekoliko hijerarhija nasljeđivanja; morate promijeniti nekoliko blokova slova. Potrebno je modificirati program na način da se implementira case block, te ga pozove potreban broj puta u programu; povezani elementi podataka koji se koriste zajedno nisu organizirani u klase. Ako više puta koristite isti skup podatkovnih elemenata, tada je korisno razmotriti kombiniranje tih podataka i stavljanje operacija koje se na njima izvode u zasebnu klasu;

Metoda refaktoriranja softvera koristi više elemenata druge klase nego vlastite. To znači da metodu treba premjestiti u drugu klasu i pozvati iz stare; primitivni tip podataka je preopterećen. Za opisivanje entiteta iz stvarnog svijeta, bolje je koristiti klasu nego preopteretiti postojeći tip podataka; Klasa ima previše ograničenu funkcionalnost. Bolje se riješiti ove klase premještanjem njezine funkcionalnosti u drugu klasu; "zalutali" podaci prenose se nizom metoda. Podaci koji se prosljeđuju metodi samo da bi bili proslijeđeni drugoj metodi nazivaju se "zalutali". Ako dođe do takvih situacija, pokušajte promijeniti arhitekturu klasa i metoda kako biste ih se riješili.

Refaktoriranje softverskog proxy objekta ne čini ništa. Ako je uloga klase preusmjeravanje poziva metoda na druge klase, onda je najbolje eliminirati takav posrednički objekt i izravno pozivati ​​druge klase; jedna klasa zna previše o drugoj klasi. U ovoj situaciji, potrebno je učiniti enkapsulaciju strožom kako bi se osiguralo da nasljednik ima minimalno znanje o svom roditelju; metoda ima nesretan naziv; članovi podataka su javni. Ovo briše granicu između sučelja i implementacije, neizbježno prekida enkapsulaciju i ograničava fleksibilnost programa; mjesto komentara u izvornom kodu;

Podklasa refaktoriranja softvera koristi samo mali dio metoda svojih predaka. Ova situacija se događa kada se nova klasa kreira samo da naslijedi nekoliko metoda od osnovne klase, a ne da opiše novi entitet. Kako bi se to izbjeglo, potrebno je transformirati osnovnu klasu tako da novoj klasi daje pristup samo metodama koje su joj potrebne; kod sadrži globalne varijable. Samo one varijable koje stvarno koristi cijeli program trebaju biti globalne. Sve ostale varijable moraju biti ili lokalne ili moraju postati svojstva nekih objekata; program sadrži kod koji će vam jednog dana možda zatrebati. Prilikom razvoja sustava, preporučljivo je osigurati mjesta gdje se u budućnosti može dodati izvorni kod.

U prvom smo dijelu za usporedbu metodologija razvoja softvera odabrali pokazatelje kao što su odnos metodologije prema iterativnom razvoju i stupanj formalnosti u dizajnu radnih materijala i općenito u procesu razvoja. U ovom dijelu ove pokazatelje koristimo za usporedbu najpoznatijih metoda razvoja softvera.

Vidjet ćemo kako će ići…

Jao, ovo je kategorija koju je najteže opisati - uostalom, ona uključuje i proizvod bjesomučnog bacanja početnika koji pod svaku cijenu pokušava dovršiti svoj prvi projekt, kao i prilično zrele i etablirane metodologije koje su upile mnoge godine raznolika iskustva specifičnih razvojnih timova i čak su opisani u internim pravilnicima Budući da ljudi koji su sposobni razviti vlastitu metodologiju, u pravilu je mogu sami ocijeniti u smislu iterativnosti i formalizacije, usredotočit ćemo se na početnike. Nažalost, najčešće to znači da pravila razvoja ili uopće ne postoje, ili su razvijena i usvojena, ali se ne poštuju. Prirodno je u takvim uvjetima imati izrazito nizak stupanj formalizma u razvoju. Dakle, s ovim je sve jasno.

Razvoj “Kako ispada”

Što je s iterativnim pristupom? Nažalost, u pravilu se ne koristi u takvim projektima. Prije svega zato što bi to omogućilo da se projekt već u prvim iteracijama ocijeni kao krajnje dvojben i zahtijeva hitnu intervenciju višeg rukovodstva da se uspostavi red. Doista, u iterativnom projektu, programerov tradicionalni odgovor da ima sve 90% spremno traje samo do završetka prve iteracije...

Strukturalne metodologije

Strukturalne metodologije

Strukturalne metode su skupina metodologija koje su se u pravilu razvile i prije raširene uporabe objektno orijentiranih jezika. Svi oni uključuju razvoj vodopada. Iako je, kako se pokazalo, čak iu tom članku, koji se često navodi kao prvi prikaz vodopadnog pristupa, rečeno da je uputno projekt započeti izradom prototipa, odnosno izvesti najmanje dvije iteracije.

Ipak, temelj ovih metodologija je dosljedan prijelaz s rada na posao i prijenos rezultata (dokumenata) sljedeće faze na sudionike sljedeće.

Također, sve te metodologije zahtijevaju visoko formalizirani pristup, iako se u njima mogu pronaći izjave o razumnoj količini dokumentacije. Jedan od neočitih primjera da su se metodologije razvoja softvera razvile ne samo na Zapadu je citat iz knjige objavljene kod nas početkom 1980-ih, u kojoj stoji da se stupanj formalizacije programskog zadatka treba odrediti na temelju toga koliko je dobro analitičar i programer. I to usprkos činjenici da je predmet knjige uključivao razvoj prilično kritičnih, kako se sada nazivaju, sustava, pogreške u kojima dovode do ozbiljnih gubitaka ili čak katastrofa.

Agilne metodologije

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

• glavno je zadovoljiti kupca i isporučiti mu proizvod što je prije moguće;
• nova izdanja proizvoda trebala bi se pojavljivati ​​svakih nekoliko tjedana ili najviše mjeseci;
• najučinkovitiji način prijenosa znanja na sudionike razvoja i između njih je osobna komunikacija;
• radni program je najbolji pokazatelj napretka razvoja.

Stoga su ove metode jasno usmjerene na iterativni razvoj softvera i minimalnu formalizaciju procesa. Međutim, što se tiče druge točke, potrebno je napraviti rezervu: navedene metode usmjerene su na minimalnu razinu formalizacije prihvatljivu za određeni projekt. Najmanje jedna od metodologija uključenih u skupinu fleksibilnih - Crystal - ima modifikacije dizajnirane za izvođenje procesa s različitim brojem sudionika i različitom kritičnošću softvera koji se razvija (kritičnost softvera određena je mogućim posljedicama grešaka koje mogu variraju od manjih financijskih gubitaka do ispravljanja pogrešaka prije katastrofalnih). Kako daljnja usporedba s fleksibilnim metodologijama ne bi bila besmislena, dat ćemo kratke opise nekoliko njih.

eXtreme Programming ili XP (ekstremno programiranje)

Metodologija XP, koju su razvili Kent Beck, Ward Cunningham i Ron Jeffries, najpoznatija je od današnjih agilnih metodologija. Ponekad se sam koncept “agilnih metodologija” eksplicitno ili implicitno poistovjećuje s XP-om koji propovijeda komunikaciju, jednostavnost, povratnu informaciju i hrabrost. Opisuje se kao skup praksi: igra planiranja, kratka izdanja, metafore, jednostavan dizajn, refaktoriranje, testni razvoj, programiranje u paru, zajedničko vlasništvo koda, 40-satni radni tjedan, stalna prisutnost korisnika i standardi koda . Interes za XP rastao je odozdo prema gore - od programera i testera, izmučenih bolnim procesom, dokumentacijom, metrikom i drugim formalizmom. Nisu odbacivali disciplinu, ali nisu bili voljni besmisleno se pridržavati formalnih zahtjeva i tražili su nove, brze i fleksibilne pristupe razvoju kvalitetnih programa.

Pri korištenju XP-a pažljivo preliminarno projektiranje softvera zamjenjuje se, s jedne strane, stalnom prisutnošću kupca u timu, spremnog odgovoriti na svako pitanje i procijeniti svaki prototip, as druge, redovitim revizijama koda (tzv. refaktoriranje). Pomno komentirani kodeks smatra se temeljem projektne dokumentacije. Puno pažnje u metodologiji posvećeno je testiranju. U pravilu se za svaku novu metodu prvo napiše test, a zatim se razvija stvarni kod metode dok se test ne počne uspješno izvoditi. Ti su testovi pohranjeni u paketima testova koji se automatski izvršavaju nakon bilo kakve promjene koda.

Dok su programiranje u paru i 40-satni radni tjedan možda najpoznatije značajke XP-a, one su po prirodi potporne i doprinose visokoj produktivnosti programera i smanjenju pogrešaka u razvoju.

Kristalno čisto

Crystal je obitelj metodologija koje određuju potreban stupanj formalizacije razvojnog procesa ovisno o broju sudionika i kritičnosti zadataka.

Metodologija Crystal Clear inferiorna je u odnosu na XP u smislu performansi, ali je iznimno jednostavna za korištenje. Zahtijeva minimalan napor za provedbu jer je usmjeren na ljudske navike. Smatra se da ova metodologija opisuje prirodni redoslijed razvoja softvera koji se uspostavlja u dovoljno kvalificiranim timovima, ako oni nisu angažirani u ciljanoj implementaciji druge metodologije.

Ključne značajke Crystal Clear:

• iterativni inkrementalni razvoj;
• automatsko regresijsko testiranje;
• korisnici se pozivaju na aktivno sudjelovanje u projektu;
• sastav dokumentacije određuju sudionici projekta;
• Obično se koriste alati za kontrolu verzije koda.

Uz Crystal Clear, obitelj Crystal uključuje nekoliko drugih metodologija dizajniranih za rukovanje većim ili kritičnijim projektima. Imaju nešto strože zahtjeve za opseg dokumentacije i prateće procedure kao što su promjena i kontrola verzija.

Razvoj vođen značajkama

Feature Driven Development (FDD) radi s konceptom funkcije ili značajke sustava, što je prilično blisko konceptu slučaja upotrebe koji se koristi u RUP-u. Možda je najznačajnija razlika dodatno ograničenje: "svaka funkcija mora omogućiti implementaciju za najviše dva tjedna." To jest, ako je slučaj upotrebe dovoljno mali, može se smatrati funkcijom, a ako je velik, mora se podijeliti na nekoliko relativno neovisnih funkcija.

FDD uključuje pet procesa, pri čemu se zadnja dva ponavljaju za svaku funkciju:

• razvoj općeg modela;
• sastavljanje popisa potrebnih funkcija sustava;
• planiranje rada na svakoj funkciji;
• dizajn funkcija;
• konstrukcija funkcije.

Rad na projektu uključuje česte nadogradnje i podijeljen je na iteracije, od kojih se svaka implementira pomoću određenog skupa funkcija.

Programeri u FDD-u dijele se na “majstore” i “glavne programere”. Glavni programeri uključuju vlasnike uključenih klasa u rad na sljedećem svojstvu. Usporedbe radi, u XP-u nema osoba odgovornih za klase ili metode.

Zajedničke značajke

Popis fleksibilnih metodologija trenutno je prilično širok. Ipak, metodologije koje smo opisali daju vrlo cjelovitu sliku cijele obitelji.

Gotovo sve fleksibilne metodologije koriste iterativni pristup, u kojem je samo ograničena količina posla povezana s izdavanjem sljedećeg izdanja detaljno planirana.

Gotovo sve fleksibilne metodologije usmjerene su na najneformalniji pristup razvoju. Ako se problem može riješiti normalnim razgovorom, onda je bolje učiniti upravo to. Štoviše, potrebno je formalizirati donesenu odluku u obliku papirnatog ili elektroničkog dokumenta samo kada je bez nje nemoguće.

Agilne metodologije

GOST standardi

GOST-ovi, poput zahtjeva modela CMM opisanih u sljedećem odjeljku, nisu metodologije. U pravilu, oni ne opisuju same procese razvoja softvera, već samo formuliraju određene zahtjeve za procese, koje različite metodologije ispunjavaju u različitim stupnjevima. Usporedba zahtjeva koristeći iste kriterije prema kojima uspoređujemo metodologije pomoći će vam da odmah odlučite koje metodologije trebate koristiti ako trebate provesti razvoj 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 strogo su usmjereni na kaskadni pristup razvoju softvera. Razvoj u skladu s ovim GOST-ovima provodi se u fazama, od kojih svaka uključuje provedbu strogo definiranog rada, a završava izdavanjem prilično velikog broja vrlo formaliziranih i opsežnih dokumenata. Stoga neposredno strogo pridržavanje ovih standarda ne samo da dovodi do vodopadnog pristupa, već također osigurava vrlo visok stupanj 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 funkcionirati od početka do završetka projekta. Model životnog ciklusa može se odabrati na temelju karakteristika projekta. Dakle, ovaj GOST ne zabranjuje izričito korištenje iterativnog pristupa, ali također izričito ne preporučuje njegovu upotrebu. GOST 12207 također je fleksibilniji u pogledu zahtjeva za formalnošću procesa razvoja. Sadrži samo upute o potrebi dokumentiranja glavnih rezultata svih procesa, ali nema popisa potrebnih dokumenata i uputa o njihovom sadržaju.

Dakle, GOST 12207 dopušta iterativni i manje formalizirani razvoj softvera.

Modeli zrelosti procesa razvoja (CMM, CMMI)

Osim državnih i međunarodnih standarda, postoji nekoliko pristupa certificiranju procesa razvoja. Najpoznatiji od njih u Rusiji su, očito, CMM i CMMI.

CMM (Capability Maturity Model) je model zrelosti procesa kreiranja softvera, koji je dizajniran za procjenu razine zrelosti razvojnog procesa u određenoj tvrtki. Prema ovom modelu postoji pet razina zrelosti razvojnog procesa. Prva razina odgovara razvoju "kako se događa", kada programeri pristupaju svakom projektu kao da je podvig. Drugi odgovara više ili manje uspostavljenim procesima, kada se s razumnim povjerenjem može računati na pozitivan ishod projekta. Treća odgovara prisutnosti razvijenih i dobro opisanih procesa koji se koriste u razvoju, a četvrta odgovara aktivnoj uporabi metrike u procesu upravljanja za postavljanje ciljeva i praćenje njihovog postizanja. Konačno, peta razina odnosi se na sposobnost tvrtke da optimizira proces prema potrebi.

CMM i CMMI zahtjevi

Nakon pojave CMM-a počeli su se razvijati specijalizirani modeli zrelosti za stvaranje informacijskih sustava, za proces odabira dobavljača i neki drugi. Na temelju njih razvijen je integrirani CMMI (Capability Maturity Model Integration) model. Osim toga, CMMI je pokušao prevladati nedostatke CMM-a koji su se do tada pojavili - preuveličavanje uloge formalnih opisa procesa, kada se prisutnost određene dokumentacije ocjenjivala mnogo višom od samo dobro uspostavljene, ali ne i opisane. postupak. Međutim, CMMI je također usredotočen na korištenje vrlo formaliziranog procesa.

Dakle, osnova CMM i CMMI modela je formalizacija procesa razvoja. Oni imaju za cilj programere da provedu proces detaljno opisan u propisima i uputama, koji, zauzvrat, ne mogu a da ne zahtijevaju izradu velike količine projektne dokumentacije za odgovarajuću kontrolu i izvješćivanje.

Veza između CMM-a i CMMI-ja i iterativnog razvoja više je neizravna. Formalno, ni jedan ni drugi ne postavljaju posebne zahtjeve za pridržavanje vodopada ili iterativnog pristupa. Međutim, prema nekim stručnjacima, CMM je kompatibilniji s vodopadnim pristupom, dok CMMI također dopušta korištenje iterativnog pristupa.

RUP

Naravno, RUP je iterativna metodologija. Iako obavezni zahtjev za dovršetkom svih faza ili određenog minimalnog broja iteracija nije formalno naznačen nigdje u RUP-u, cijeli pristup je fokusiran na činjenicu da ih ima dosta. Ograničeni broj ponavljanja ne dopušta da se u potpunosti iskoriste sve prednosti RUP-a. U isto vrijeme, RUP se također može koristiti u praktički vodopadnim projektima, koji zapravo uključuju samo nekoliko iteracija: jednu u fazi "Build", a drugu u fazi "Transfer". Usput, u vodopad projektima ovaj broj ponavljanja se zapravo koristi. Uostalom, testiranje i probni rad sustava uključuje i korekcije koje mogu uključivati ​​određene radnje vezane uz analizu, projektiranje i razvoj, odnosno zapravo su još jedan prolaz kroz sve faze razvoja.

RUP metodologija

Što se tiče formalnosti metodologije, RUP korisniku pruža vrlo širok raspon mogućnosti. Ako obavite sve poslove i zadatke, izradite sve artefakte i provedete sve preglede sasvim formalno (sa službenim recenzentom, pripremate potpuni pregled u obliku elektroničkog ili papirnatog dokumenta itd.), RUP može ispasti biti krajnje formalna, teška metodologija. U isto vrijeme, RUP vam omogućuje da razvijate samo one artefakte i obavljate samo one poslove i zadatke koji su nužni u konkretnom projektu. A odabrani artefakti mogu se izvršiti i pregledati s proizvoljnim stupnjevima formalnosti. Možete zahtijevati detaljnu razradu i brižljivu izradu svakog dokumenta, davanje jednako pažljivo dovršene i izvedene recenzije, pa čak i, prema staroj praksi, odobrenje svake takve recenzije od strane znanstveno-tehničkog vijeća poduzeća. Ili se možete ograničiti na e-mail ili skicu na papiru. Osim toga, uvijek postoji još jedna mogućnost: oblikovati dokument u svojoj glavi, odnosno razmisliti o relevantnom pitanju i donijeti konstruktivnu odluku. A ako se ova odluka tiče samo vas, ograničite se, na primjer, na komentar u programskom kodu.

Dakle, RUP je iterativna metodologija s vrlo širokim rasponom mogućih rješenja u smislu formalizacije procesa razvoja.

Rezimirajmo drugi dio članka. RUP, za razliku od većine drugih metodologija, omogućuje odabir u širokom rasponu stupnja formalizacije i iterativnosti procesa razvoja, ovisno o karakteristikama projekta i organizacije u razvoju.

Razgovarat ćemo o tome zašto je to toliko važno u sljedećem dijelu.