Napomena: Koncept procesa razvoja softvera. Univerzalni proces. Trenutni proces. Specifičan proces. Standardni proces. Poboljšanje procesa. Pull/Push strategije. Klasični modeli procesa: model vodopada, model spirale. Faze i aktivnosti.

Prednost ovog modela je što ograničava mogućnost povratka na proizvoljan korak unatrag, na primjer, od testiranja do analize, od razvoja do rada na zahtjevima itd. Uočeno je da bi takvi povrati mogli katastrofalno povećati troškove projekta i vrijeme njegovog završetka. Na primjer, ako se tijekom testiranja otkriju pogreške u dizajnu ili analizi, njihovo ispravljanje često dovodi do potpunog redizajna sustava. Ovaj model dopuštao je povratak samo na prethodni korak, na primjer, od testiranja do kodiranja; od softvera, ovaj model aktivno su kritizirali gotovo svi autori relevantnih članaka i udžbenika. Postalo je općeprihvaćeno mišljenje da ne odražava karakteristike razvoja softvera. Nedostaci modela vodopada su:

• utvrđivanje faza i aktivnosti, što za posljedicu ima gubitak razvojne fleksibilnosti, posebno poteškoće u podržavanju iterativnog razvojnog procesa;
• zahtjev za potpuni završetak faze aktivnosti, konsolidacija rezultata u obliku detaljnog izvornog dokumenta (tehnički zadatak, projektna specifikacija); međutim, iskustvo u razvoju softvera pokazuje da je nemoguće u potpunosti dovršiti razvoj zahtjeva, dizajn sustava itd. – sve je to podložno promjenama; a razlozi za to nisu samo promjenjivo projektno okruženje, već i to što se mnoge odluke ne mogu unaprijed točno odrediti i formulirati, već se pojašnjavaju i specificiraju tek kasnije;
• integracija svih razvojnih rezultata događa se na kraju, zbog čega se problemi integracije osjećaju prekasno;
• korisnici i kupac ne mogu se upoznati s opcijama sustava tijekom razvoja, a rezultat vide tek na samom kraju; stoga ne mogu utjecati na proces kreiranja sustava, pa se stoga povećavaju rizici od nesporazuma između programera i korisnika/kupca;
• model je nestabilan na neuspjehe u projektnom financiranju ili redistribuciji sredstava; započeti razvoj zapravo nema alternative “usput”.

Međutim ovaj model i dalje se koristi u praksi - za male projekte ili u razvoju standardnih sustava, gdje iterativnost nije toliko tražena. Uz njegovu pomoć prikladno je pratiti razvoj i provoditi postupnu kontrolu nad projektom. Ovaj se model također često koristi u offshore projektima 1 Od engleskog offshore - izvan obale, u proširenoj interpretaciji - izvan jedne zemlje. sa satnicama. Model vodopada ugrađen je kao komponenta u druge modele i metodologije, kao što je MSF.

Spiralni model predložio je Barry Boehm 1988. kako bi se prevladali nedostaci modela vodopada, prvenstveno radi boljeg upravljanja rizicima. Prema ovom modelu, razvoj proizvoda se odvija u spirali, čiji je svaki zavoj određena faza razvoja. Za razliku od modela vodopada, spiralni model nema unaprijed zadani i obvezni skup zavoja, svaki zavoj može biti i posljednji tijekom razvoja sustava, po njegovom završetku izrađuju se planovi za sljedeći zavoj. Konačno, revolucija je upravo faza, a ne vrsta aktivnosti, kao u modelu vodopada, u njezinom okviru može se odvijati više različitih vrsta aktivnosti, odnosno model je dvodimenzionalan.

Redoslijed poteza može biti sljedeći: u prvom koraku se donosi odluka o izvedivosti izrade softvera, u sljedećem se donose odluke Zahtjevi sustava , zatim je sustav dizajniran, itd. Okreti mogu imati i druga značenja.

Svaki zavoj ima sljedeću strukturu (sektore):

• definiranje ciljeva projekta, ograničenja i alternativa;
• procjena alternativa, procjena i rješavanje rizika; moguće je koristiti izradu prototipova (uključujući izradu niza prototipova), simulaciju sustava, vizualno modeliranje i analizu specifikacija; fokusiranje na najrizičnije dijelove projekta;
• razvoj i testiranje – ovdje je moguće koristiti vodopadni model ili koristiti druge modele i metode razvoja softvera;
• planiranje sljedećih iteracija - analiziraju se rezultati, planovi i resursi za kasniji razvoj, donosi se (ili ne donosi) odluka o novom krugu; analizira ima li smisla nastaviti razvijati sustav ili ne; razvoj se može obustaviti, na primjer, zbog neuspjeha financiranja; spiralni model omogućuje vam da to učinite ispravno.

Zasebna spirala može odgovarati razvoju neke softverske komponente ili uvođenju redovitih promjena u proizvod. Dakle, model može imati treću dimenziju.

Spiralni model nije preporučljivo koristiti u projektima s niskim stupnjem rizika, s ograničenim proračunom, za male projekte. Osim toga, nedostatak dobra sredstva izrada prototipova također može učiniti spiralni model nezgodnim za korištenje.

Spiralni model nije pronašao široka primjena u industriji i važan je, prije u povijesnom i metodološkom smislu: to je prvi iterativni model, ima prekrasnu metaforu - spiralu - i, poput modela vodopada, kasnije je korišten za stvaranje drugih modela procesa i metodologija razvoja softvera.

Razvoj softverskih proizvoda poznaje mnoge vrijedne metodologije - drugim riječima, 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 uzastopno prolaženje faza, od kojih svaka mora biti u potpunosti dovršena prije nego što započne sljedeća. Model Waterfall olakšava upravljanje projektom. Zahvaljujući svojoj krutosti, razvoj se odvija brzo, trošak i rok su unaprijed određeni. Ali ovo je dvosjekli mač. Waterfall model će dati izvrsne rezultate samo u projektima s jasno i unaprijed definiranim zahtjevima i načinima njihove provedbe. 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 promjena je visok jer zahtijeva čekanje dok se cijeli projekt ne završi da bi se on pokrenuo. Međutim, fiksni trošak često nadmašuje nedostatke pristupa. Ispravljanje nedostataka uočenih tijekom izrade je moguće, a prema našem iskustvu zahtijeva jedan do tri dodatna dogovora uz ugovor s malom tehničkom specifikacijom.

Koristeći model vodopada, izradili smo mnoge projekte od nule, uključujući samo razvoj tehničkih specifikacija. Projekti o kojima je pisano na Habréu: srednji - , mali - .

Kada koristiti metodologiju vodopada?

• Tek kada su zahtjevi poznati, shvaćeni i zabilježeni. Nema proturječnih zahtjeva.
• Nema problema s dostupnošću programera s potrebnim kvalifikacijama.
• U relativno malim projektima.

2. "V-model"

Naslijedio strukturu "korak po korak" od kaskadnog modela. Model u obliku slova V primjenjiv je za sustave kojima je posebno važan neprekinuti rad. Na primjer, aplikacijski programi u klinikama za praćenje pacijenata, integrirani softver za upravljačke mehanizme za hitne zračne jastuke u vozilima i tako dalje. Posebnost modela je što je usmjeren na temeljitu provjeru i testiranje proizvoda koji je već u početnoj fazi projektiranja. Faza testiranja provodi se istovremeno s odgovarajućom fazom razvoja, na primjer, jedinični testovi se pišu tijekom kodiranja.

Primjer našeg rada po V-metodologiji - mobilna aplikacija za Europljane mobilni operater, što štedi troškove roaminga tijekom putovanja. Projekt se provodi prema jasnoj specifikaciji, 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đa novca i kredita je nemoguće.

Kada koristiti V-model?

• Ako je potrebno temeljito testiranje proizvoda, tada će V-model opravdati svoju inherentnu ideju: validaciju i provjeru.
• Za male i srednje projekte gdje su zahtjevi jasno definirani i fiksni.
• U uvjetima dostupnosti 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 sastavljanja softvera korak po korak. Odvija se nekoliko 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. Postupak razvoja prema inkrementalnom modelu uključuje izdavanje proizvoda s osnovnom funkcionalnošću u prvoj velikoj fazi, a zatim sekvencijalno dodavanje novih funkcija, tzv. 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 elektroničkih knjižnica Vivaldi.

Kao primjer, opisat ćemo suštinu jednog inkrementa. zamijenio DefView. DefView je povezan s jednim poslužiteljem dokumenata i sada se može povezati s mnogima. Poslužitelj za pohranu podataka instaliran je na mjestu institucije koja svoj sadržaj želi emitirati određenoj publici, koja izravno pristupa dokumentima i pretvara ih u traženi 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. U isto vrijeme, neki detalji mogu biti poboljšani tijekom vremena.
• Potrebno je rano uvođenje proizvoda 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 vrsta 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 vrlo brzo klijentu pružite nešto što radi na pregled kako bi mogao primiti Povratne informacije i unošenje promjena.

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 prethodnoj fazi koriste se za određivanje objekata i drugih entiteta potrebnih za kruženje informacija.
• Modeliranje procesa: Tokovi informacija povezuju objekte radi postizanja razvojnih ciljeva.
• Izradite aplikaciju: koristi automatizirane alate za sklapanje 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 je velik za plaćanje ovih stručnjaka zajedno s cijenom gotovih automatiziranih alata za montažu. RAD model se može odabrati s pouzdanim poznavanjem ciljanog poslovanja i potrebe za hitnom proizvodnjom sustava unutar 2-3 mjeseca.

5. “Agilni model” (fleksibilna metodologija 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.

Ova vrsta se temelji na kratkim dnevnim sastancima - “Scrum” i sastancima koji se redovito ponavljaju (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 tijekom rada.

Metodologija je prikladna za velike projekte ili one koji imaju dug životni ciklus, uz stalno prilagođavanje tržišnim uvjetima. Sukladno tome, zahtjevi se mijenjaju tijekom procesa implementacije. Vrijedno je zapamtiti klasu kreativnih ljudi koji imaju tendenciju stvarati, smišljati i isprobavati nove ideje na tjednoj ili čak dnevnoj bazi. Agilni razvoj je najprikladniji za ovu vrstu menadžera. Razvijamo interne startupe tvrtke koristeći Agile. Primjer projekata klijenata je elektronički sustav medicinskog 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 koja je temeljna za uspjeh u 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 zahtijeva samo malo planiranja da bi se projekt pokrenuo.

6. “Iterativni model” (iterativni ili iterativni model)

Iterativni model životnog ciklusa ne zahtijeva kompletnu specifikaciju zahtjeva za početak. Umjesto toga, stvaranje počinje implementacijom dijela funkcionalnosti, koji postaje temelj za definiranje daljnjih zahtjeva. Ovaj proces se ponavlja. Verzija možda nije savršena, glavna stvar je da radi. Razumijevajući konačni cilj, težimo tome 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 dio po dio, proizvod se sastoji od dijelova. Za razliku od iterativnog modela, svaki komad predstavlja cjelovit element.

Primjer iterativnog razvoja je prepoznavanje glasa. Prva istraživanja i priprema znanstvene aparature započela su davno, prvo u mislima, a potom i 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 optimalno koristiti iterativni model?

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

7. "Spiralni model" (spiralni model)

“Spiralni model” sličan je inkrementalnom modelu, ali s naglaskom na analizi rizika. Dobro funkcionira za rješavanje kritičnih poslovnih problema kada je neuspjeh nekompatibilan s aktivnostima tvrtke, u kontekstu izdavanja novih linija proizvoda, kada su potrebna znanstvena istraživanja i praktična ispitivanja.

Spiralni model uključuje 4 stupnja za svaki zavoj:

1. planiranje;
2. analiza rizika;
3. oblikovati;
4. evaluacija rezultata i, ako je kvaliteta zadovoljavajuća, prijelaz na novu fazu.

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

Sažmimo

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

U suvremenoj praksi modeli razvoja softvera su multivarijantni. Ne postoji jedan pravi model za sve projekte, početne uvjete i modele plaćanja. Čak ni Agile, koji nam je toliko drag, ne može se svugdje primijeniti zbog nepripremljenosti pojedinih kupaca ili nemogućnosti fleksibilnog financiranja. Metodologije se dijelom preklapaju u sredstvima, a dijelom su slične jedna drugoj. Neki drugi koncepti korišteni su samo za promicanje vlastitih prevoditelja i nisu unijeli ništa novo u praksu.

O razvojnim tehnologijama:
.
.
.
.

Koje metodologije koristite?