Danas se proces stvaranja složenih softverskih aplikacija ne može zamisliti bez podjele na faze životnog ciklusa. Pod životnim ciklusom programa podrazumijevamo niz faza:

• Analiza predmetnog područja i izrada tehničke specifikacije (interakcija s kupcem)
• Dizajn strukture programa
• Kodiranje (skup programskog koda prema projektnoj dokumentaciji)
• Testiranje i otklanjanje pogrešaka
• Provedba programa
• Programska podrška
• Raspolaganje

Pogledajmo pobliže proces dizajna. Tijekom procesa projektiranja, arhitekt ili iskusni programer izrađuje projektnu dokumentaciju, uključujući tekstualne opise, dijagrame i modele budućeg programa. U ovoj teškoj stvari pomoći će nam jezik UML.

UML je grafički jezik za vizualizaciju, opis parametara, dizajn i dokumentaciju raznih sustava (posebno programa). Dijagrami se izrađuju pomoću posebnih CASE alata kao što su Rational Rose (http://www-01.ibm.com/software/rational/) i Enterprise Architect (http://www.sparxsystems.com.au/). Temeljen na UML tehnologiji, jedinstveni informacijski model. Gornji CASE alati sposobni su generirati kod u raznim objektno orijentiranim jezicima, a također imaju vrlo korisna značajka obrnuti inženjering. (Obrnuti inženjering vam omogućuje stvaranje grafičkog modela iz postojećeg programskog koda i komentara na njega.)

Razmotrite vrste dijagrama za vizualizaciju modela (ovi su obavezni, iako postoji mnogo više vrsta):

Dijagram slučaja uporabe

Dizajnirani sustav je predstavljen kao skup entiteta ili aktera koji su u interakciji sa sustavom koristeći takozvane presedane. U ovom slučaju, akter (glumac) ili akter je bilo koji entitet koji izvana komunicira sa sustavom. Drugim riječima, svaki slučaj upotrebe definira određeni skup radnji koje sustav izvodi kada razgovara s glumcem. Pritom se ništa ne govori o tome kako će se provoditi interakcija aktera sa sustavom.

Dijagram klasa (dijagram klasa)

Dijagram klasa služi za predstavljanje statičke strukture modela sustava u terminologiji klasa objektno orijentiranog programiranja. Dijagram klasa može posebno odražavati različite odnose između pojedinačnih entiteta predmetnog područja, kao što su objekti i podsustavi, a također opisuje njihovu unutarnju strukturu (polja, metode ...) i vrste odnosa (nasljeđivanje, implementacija sučelja . ..). Ovaj dijagram ne pruža informacije o vremenskim aspektima rada sustava. S ove točke gledišta, dijagram klasa je daljnji razvoj konceptualnog modela projektiranog sustava. U ovoj fazi neophodno je poznavanje OOP pristupa i obrazaca dizajna.

Dijagram stanja (dijagram stanja)

Glavna svrha ovog dijagrama je opisati moguće nizove stanja i prijelaza koji zajedno karakteriziraju ponašanje elementa modela tijekom njegovog životnog ciklusa. Dijagram stanja predstavlja dinamičko ponašanje entiteta, temeljeno na specifikaciji njihovog odgovora na percepciju nekih specifičnih događaja.

Dijagram slijeda

Za modeliranje interakcije objekata u UML jeziku koriste se odgovarajući dijagrami interakcije. Interakcije objekata mogu se razmatrati u vremenu, a zatim se dijagram sekvence koristi za predstavljanje vremena prijenosa i primanja poruka između objekata. Objekti u interakciji međusobno razmjenjuju neke informacije. U tom slučaju informacije imaju oblik cjelovitih poruka. Drugim riječima, iako poruka ima informacijski sadržaj, ona dobiva dodatno svojstvo usmjerenog utjecaja na primatelja.

Dijagram suradnje

U dijagramu suradnje objekti koji sudjeluju u interakciji prikazani su u obliku pravokutnika koji sadrže naziv objekta, njegovu klasu i, eventualno, vrijednosti atributa. Kao iu dijagramu klasa, asocijacije između objekata naznačene su u obliku različitih povezujućih linija. U ovom slučaju možete eksplicitno odrediti nazive pridruživanja i uloge koje objekti igraju u ovom pridruživanju.
Za razliku od dijagrama sekvenci, dijagram suradnje prikazuje samo odnose između objekata koji igraju određene uloge u interakciji.

Dijagram komponenti

Dijagram komponenti, za razliku od prethodno razmatranih dijagrama, opisuje značajke fizičkog prikaza sustava. Dijagram komponenti vam omogućuje da odredite arhitekturu sustava koji se razvija uspostavljanjem ovisnosti između softverskih komponenti, koje mogu biti izvorni, binarni i izvršni kod. U mnogim razvojnim okruženjima, modul ili komponenta odgovaraju datoteci. Točkaste strelice koje povezuju module pokazuju odnose ovisnosti slične onima koji se javljaju prilikom prevođenja izvornog koda programa. Glavni grafički elementi dijagrama komponenti su komponente, sučelja i ovisnosti između njih.

Dijagram postavljanja

Dijagram implementacije dizajniran je za vizualizaciju elemenata i komponenti programa koji postoje samo u fazi njegovog izvođenja (runtime). U ovom slučaju prikazane su samo komponente instance programa koje su izvršne datoteke ili dinamičke biblioteke. One komponente koje se ne koriste tijekom izvođenja nisu prikazane u dijagramu postavljanja.
Dijagram postavljanja sadrži grafičke slike procesore, uređaje, procese i veze između njih. Za razliku od logičkih dijagrama prikaza, dijagram implementacije je isti za sustav kao cjelinu, jer mora u potpunosti odražavati značajke njegove implementacije. Ovaj dijagram u biti dovršava OOAP proces za određeni programski sustav a njegov razvoj obično je posljednji korak u specifikaciji modela.

Ovo zaključuje naš pregled dijagrama posebno i dizajna općenito. Vrijedno je napomenuti da je proces dizajna odavno postao standard razvoja softvera, ali često se morate nositi s lijepo napisanim programom, koji zbog nedostatka odgovarajuće dokumentacije dobiva nepotrebne sporedne funkcionalnosti, štake, postaje glomazan i gubi svoju prijašnja kvaliteta. =(

Uvjeren sam da je programer prije svega koder - on NE treba komunicirati s kupcem, NE treba razmišljati o arhitekturi sustava, ne treba izmišljati sučelje programa, on treba samo kodirati - implementirati algoritme, funkcionalnost, izgled, upotrebljivost, ali ne više…. Projektant, počevši od apstraktnih dijagrama (koji opisuju predmetno područje) do dijagrama koji predstavljaju strukturu podataka, klase i procese njihove interakcije, mora sve detaljno opisati korak po korak. Odnosno, složenost posla i plaća dizajnera trebala bi biti red veličine veća od one programera == kodera. Oprostite na laprdanju....

Razvoj softverskih proizvoda poznaje mnoge vrijedne metodologije - drugim riječima, dobro uspostavljene najbolje prakse. Izbor ovisi o specifičnostima projekta, proračunskom sustavu, subjektivnim preferencijama, pa čak i temperamentu upravitelja. U članku su opisane metodologije s kojima se redovito susrećemo u Edisonu.

1. "Model vodopada" (kaskadni model ili "vodopad")

Jedan od najstarijih, uključuje uzastopni prolazak faza, od kojih svaka mora biti u potpunosti dovršena prije početka sljedeće. Lako je upravljati projektom u modelu Vodopad. Zbog svoje krutosti, razvoj je brz, cijena i vrijeme su unaprijed određeni. Ali ovo je dvosjekli mač. Model vodopada dobro će funkcionirati samo za projekte s jasno definiranim zahtjevima i načinom na koji će se oni provoditi. Ne postoji način da se napravi korak unatrag, testiranje počinje tek nakon što je razvoj dovršen ili gotovo dovršen. Proizvodi razvijeni prema ovom modelu bez opravdanog izbora mogu imati nedostatke (popis zahtjeva se ne može prilagoditi u bilo kojem trenutku), koji postaju poznati tek na kraju zbog strogog slijeda radnji. Trošak unošenja izmjena je visok jer morate čekati da cijeli projekt završi da biste ga pokrenuli. Međutim, fiksni trošak često nadmašuje nedostatke pristupa. Ispravak nedostataka uočenih tijekom izrade je moguć, a prema našem iskustvu zahtijeva jedan do tri dodatna dogovora uz ugovor s malom tehničkom specifikacijom.

Uz pomoć modela vodopada stvorili smo mnoge projekte od nule, uključujući razvoj samo tehničkih specifikacija. Projekti o kojima piše na Habréu: srednji - , mali - .

Kada koristiti metodologiju vodopada?

• Tek kada su zahtjevi poznati, shvaćeni i fiksni. Nema proturječnih zahtjeva.
• Nema problema s dostupnošću programera potrebnih kvalifikacija.
• Za relativno male projekte.

2. "V-model"

Naslijedio strukturu korak po korak od modela vodopada. Model u obliku slova V primjenjiv je za sustave koji su posebno važni za nesmetan rad. Na primjer, aplikacijski programi u klinikama za praćenje pacijenata, integrirani softver za upravljačke mehanizme zračnih jastuka za hitne slučajeve u vozilima i tako dalje. Značajkom modela može se smatrati da je usmjeren na temeljitu provjeru i testiranje proizvoda, koji je već u početnim fazama dizajna. Faza testiranja provodi se istodobno s odgovarajućom razvojnom fazom, na primjer jedinični testovi se pišu tijekom kodiranja.

Primjer našeg rada po V-metodologiji - mobilna aplikacija za europski mobilni operater, što štedi troškove roaminga tijekom putovanja. Projekt se provodi prema jasnom TOR-u, ali uključuje značajnu fazu testiranja: praktičnost sučelja, funkcionalnost, opterećenje, uključujući integraciju, koja bi trebala potvrditi da nekoliko komponenti različitih proizvođača radi zajedno stabilno, krađu novca i zajmovi su nemogući.

Kada koristiti V-model?

• Ako je potrebno temeljito testiranje proizvoda, tada će V-model opravdati temeljnu ideju: validaciju i provjeru.
• Za male i srednje projekte gdje su zahtjevi jasno definirani i fiksni.
• S obzirom na dostupnost inženjera s potrebnim kvalifikacijama, posebno ispitivača.

3. "Inkrementalni model" (inkrementalni model)

U inkrementalnom modelu, kompletni zahtjevi sustava podijeljeni su u različite sklopove. Terminologija se često koristi za opisivanje postupne izgradnje softvera. Postoji više razvojnih ciklusa, a zajedno čine životni ciklus s više vodopada. Ciklus je podijeljen na manje lako kreirane module. Svaki modul prolazi kroz faze definiranja zahtjeva, dizajna, kodiranja, implementacije i testiranja. Razvojni postupak prema inkrementalnom modelu uključuje puštanje proizvoda u prvu veću fazu osnovne funkcionalnosti, a zatim dosljedno dodavanje novih značajki, tzv. "inkremenata". Proces se nastavlja sve dok se ne stvori kompletan sustav.

Inkrementalni modeli se koriste tamo gdje su pojedinačni zahtjevi za promjenama jasni i mogu se lako formalizirati i implementirati. U našim smo projektima njime izradili čitač DefView, a potom i mrežu digitalnih knjižnica Vivaldi.

Kao primjer, opišimo bit jednog inkrementa. zamijenio DefView. DefView se prije povezivao s jednim poslužiteljem dokumenata, ali sada se može povezati s mnogima. Na stranici institucije koja svoj sadržaj želi emitirati određenoj publici, instaliran je poslužitelj za pohranu podataka koji izravno pristupa dokumentima i pretvara ih u željeni format. Pojavio se korijenski element arhitekture - središnji Vivaldi poslužitelj, koji djeluje kao jedan pretraživač na svim poslužiteljima za pohranu instaliranim u raznim institucijama.

Kada koristiti inkrementalni model?

• Kada su osnovni zahtjevi za sustav jasno definirani i razumljivi. Istodobno, neki se detalji s vremenom mogu poboljšati.
• Zahtijeva rano lansiranje na tržište.
• Postoji nekoliko rizičnih značajki ili ciljeva.

4. "RAD Model" (model brzog razvoja aplikacija ili brzi razvoj aplikacija)

RAD model je varijacija inkrementalnog modela. U RAD modelu, komponente ili funkcije razvija nekoliko visoko kvalificiranih timova paralelno, poput nekoliko mini-projekata. Vremenski okvir jednog ciklusa je strogo ograničen. Stvoreni moduli se zatim integriraju u jedan radni prototip. Sinergija vam omogućuje da klijentu brzo predstavite nešto što radi na pregled kako biste dobili povratnu informaciju i napravili promjene.

Model brzog razvoja aplikacije uključuje sljedeće faze:

• Poslovno modeliranje: definiranje popisa protoka informacija između različitih odjela.
• Modeliranje podataka: Informacije prikupljene u prethodnom koraku koriste se za definiranje objekata i drugih entiteta potrebnih za kruženje informacija.
• Modeliranje procesa: Tokovi informacija povezuju objekte radi postizanja ciljeva dizajna.
• Sastavljanje aplikacije: koristi automatizirane alate za sastavljanje za pretvaranje CAD modela u kod.
• Testiranje: testiraju se nove komponente i sučelja.

Kada se koristi RAD model?

Može se koristiti samo s visoko kvalificiranim i visoko specijaliziranim arhitektima. Proračun projekta dovoljno je velik da plati ove stručnjake, zajedno s cijenom gotovih automatiziranih alata za montažu. RAD model možete odabrati ako pouzdano poznajete ciljni posao i trebate hitno proizvesti sustav u roku od 2-3 mjeseca.

5. "Agilni model" (metodologija agilnog razvoja)

U "agilnoj" metodologiji razvoja, nakon svake iteracije kupac može promatrati rezultat i shvatiti zadovoljava li ga ili ne. Ovo je jedna od prednosti fleksibilnog modela. Njegovi nedostaci uključuju činjenicu da je, zbog nedostatka specifičnih formulacija rezultata, teško procijeniti troškove rada i troškove potrebne za razvoj. Ekstremno programiranje (XP) jedna je od najpoznatijih primjena agilnog modela u praksi.

Ovaj tip se temelji na kratkim dnevnim sastancima - "Scrum" i redovito ponavljajućim sastancima (jednom tjedno, jednom svaka dva tjedna ili jednom mjesečno) pod nazivom "Sprint". Na dnevnim sastancima članovi tima raspravljaju o:

• izvješće o obavljenom poslu od posljednjeg Scruma;
• popis zadataka koje zaposlenik mora obaviti prije sljedećeg sastanka;
• poteškoće koje su se pojavile u toku rada.

Metodologija je prikladna za velike ili dugoročne projekte koji se stalno prilagođavaju tržišnim uvjetima. Sukladno tome, u procesu implementacije zahtjevi se mijenjaju. Vrijedno je zapamtiti klasu kreativnih ljudi koji imaju tendenciju generirati, izdavati i testirati nove ideje tjedno ili čak svakodnevno. Agilni razvoj najbolje odgovara ovoj vrsti vođe. Razvijamo interne startupe tvrtke koristeći Agile. Primjer klijentskih projekata je Elektronički sustav medicinskih pregleda, stvoren za provođenje masovnih medicinskih pregleda u nekoliko minuta. U drugom odlomku ove recenzije naši američki partneri opisali su vrlo važnu stvar, temeljnu za uspjeh na Agileu.

Kada koristiti Agile?

• Kada se potrebe korisnika neprestano mijenjaju u dinamičnom poslovanju.
• Agilne promjene provode se po nižoj cijeni zbog čestih povećanja.
• Za razliku od modela vodopada, agilni model treba samo malo planiranja za početak projekta.

6. "Iterativni model" (iterativni ili iterativni model)

Iterativni model životnog ciklusa ne zahtijeva potpunu specifikaciju zahtjeva za početak. Umjesto toga, izrada počinje implementacijom dijela funkcionalnosti, koji postaje temelj za određivanje daljnjih zahtjeva. Ovaj proces se ponavlja. Verzija možda nije savršena, glavna stvar je da radi. Razumijevajući krajnji cilj, težimo mu tako da svaki korak bude učinkovit, a svaka verzija izvediva.

Dijagram prikazuje iterativni "razvoj" Mona Lise. Kao što vidite, u prvoj iteraciji postoji samo skica Mona Lise, u drugoj se pojavljuju boje, a treća iteracija dodaje detalje, zasićenost i dovršava proces. U inkrementalnom modelu, funkcionalnost proizvoda se gradi malo po malo, proizvod se sastoji od dijelova. Za razliku od iterativnog modela, svaki komad je integralni element.

Primjer iterativnog razvoja je prepoznavanje glasa. Prva istraživanja i priprema znanstvenog aparata započela je davno, u početku - u mislima, zatim - na papiru. Sa svakom novom iteracijom, kvaliteta prepoznavanja se poboljšavala. Međutim, savršeno prepoznavanje još nije postignuto, stoga problem još nije u potpunosti riješen.

Kada je najbolje vrijeme za korištenje iterativnog modela?

• Zahtjevi za konačni sustav jasno su definirani i unaprijed razumljivi.
• Projekt je velik ili vrlo velik.
• Glavni zadatak mora biti definiran, ali detalji implementacije mogu se razvijati tijekom vremena.

7. "Spiralni model" (spiralni model)

„Spiralni model“ sličan je inkrementalnom modelu, ali s naglaskom na analizi rizika. Dobro radi za kritične poslovne izazove gdje je neuspjeh nekompatibilan s poslovanjem tvrtke, novim linijama proizvoda, istraživanjem i terenskim ispitivanjima.

Spiralni model pretpostavlja 4 stupnja za svaki zavoj:

1. planiranje;
2. analiza rizika;
3. građenje;
4. evaluacija rezultata i, ako je kvaliteta zadovoljavajuća, prijelaz u novi krug.

Ovaj model nije prikladan za male projekte, razuman je za one složene i skupe, kao što je razvoj sustava za upravljanje dokumentima za banku, kada svaki sljedeći korak zahtijeva više analize za procjenu posljedica nego programiranje. Na projektu razvoja EDMS-a za ODU Sibira SO UES, dva sastanka o promjeni kodifikacije odjeljaka elektroničke arhive oduzimaju 10 puta više vremena nego programeru koji kombinira dvije mape. Državni projekti u kojima smo sudjelovali započeli su pripremom stručne javnosti jednog skupog koncepta, koji nipošto nije uvijek beskoristan, jer se isplati u nacionalnim razmjerima.

Sažmimo

Slajd prikazuje razlike između dvije najčešće metodologije.

U suvremenoj praksi modeli razvoja softvera su multivarijantni. Ne postoji isti za sve projekte, početne uvjete i modele plaćanja. Čak ni svima nama toliko dragi Agile ne može se primijeniti svugdje zbog nepripremljenosti pojedinih kupaca ili nemogućnosti fleksibilnog financiranja. Metodologije se djelomično preklapaju u sredstvima i donekle su slične jedna drugoj. Neki drugi koncepti korišteni su samo za promicanje vlastitih prevoditelja i nisu donijeli ništa novo u praksu.

O razvojnim tehnologijama:
.
.
.
.

Koje metodologije koristite?