Faze razvoja programa. Pripremna faza razvoja softvera

upravljanje softverom

Proces kreiranja softvera je mnoštvo različitih aktivnosti, metoda, tehnika i koraka koji se koriste za razvoj i razvoj softvera i srodnih proizvoda (planovi dizajna, dokumentacija, programski kod, testovi, korisnička dokumentacija).

Međutim, danas ne postoji univerzalni proces razvoja softvera – skup metoda, pravila i propisa pogodnih za softver bilo koje vrste, za bilo koju kompaniju, za timove bilo koje nacionalnosti. Svaki trenutni razvojni proces koji sprovodi određeni tim u okviru određenog projekta ima veliki broj karakteristika i ličnosti. Ipak, preporučljivo je planirati radni proces prije početka projekta, definirajući uloge i odgovornosti u timu, proizvode rada (srednji i završni), proceduru učešća članova tima u njihovom razvoju i sl.

Proces razvoja softvera nije ujednačen. Određeni način razvoja softvera, po pravilu, određuje neku dinamiku razvoja određenih vrsta aktivnosti, odnosno određuje procesni model.

Model je dobra apstrakcija različitih metoda razvoja softvera, omogućavajući im da budu predstavljeni sažeto, sažeto i informativno. Međutim, sama ideja procesnog modela jedna je od najranijih u softverskom inženjerstvu, kada se vjerovalo da je uspješan model najvažnija stvar koja doprinosi uspjehu razvoja. Kasnije je došlo do spoznaje da postoji mnogo drugih aspekata (npr. principi upravljanja i razvoja, struktura tima) koje je potrebno definirati u skladu jedni s drugima. Počele su se razvijati integralne razvojne metodologije. Međutim, postoji nekoliko klasičnih modela procesa razvoja softvera.

Prvi model koji je postao široko poznat i istinski strukturirao proces razvoja je vodopad ili model vodopada. Nastao je nakon NATO konferencije o nauci i tehnologiji 1968. godine, na kojoj su se razmatrala slična pitanja, a proces kreiranja softverskog proizvoda dijeli na uzastopne faze (treba napomenuti da su ga u to vrijeme već koristili razni programeri, ali ni broj niti sadržaj faza ujedinjeni).

Slika 1 - Modificirani model razvoja softvera vodopada

Modifikovani model vodopada dao je mogućnost povratka na prethodne faze.

Ubrzo nakon svog nastanka, Winst Royce je modificirao kaskadni model, uzimajući u obzir međuzavisnost faza i potrebu vraćanja na prethodne faze, što može biti uzrokovano, na primjer, nepotpunim zahtjevima ili greškama u formiranju zadatka. U ovom „reverzibilnom“ obliku, model vodopada je postojao dugo vremena i postao je osnova za mnoge projekte (slika 1).

Međutim, praktična upotreba ovog modela otkrila je mnoge njegove nedostatke, od kojih je glavni bio da je pogodniji za tradicionalne vrste inženjerskih aktivnosti nego za razvoj softvera. Konkretno, jedan od najvećih problema bila je njegova "predispozicija" za moguće odstupanja između rezultirajućeg proizvoda i zahtjeva koji su mu se postavljali. Glavni razlog za to je što se potpuno formiran proizvod pojavljuje tek u kasnijim fazama razvoja, ali pošto su posao u različitim fazama obično obavljali različiti stručnjaci i projekat se prenosio iz jedne grupe u drugu, tada je, prema mišljenju principu oštećenog telefona, pokazalo se da izlaz nije baš ono što je prvobitno predloženo.

Kako bi se otklonili nedostaci modela vodopada, predložen je model razvoja softvera u obliku slova V ili zglobni (slika 2).

Slika 2- Model razvoja softvera u obliku slova V

Model u obliku slova V omogućava mnogo bolju kontrolu rezultata u smislu ispunjavanja očekivanja, jer se fokusira na testiranje.

Model u obliku slova V omogućio je značajno poboljšanje kvaliteta softvera zbog njegove orijentacije na testiranje, a također je u velikoj mjeri riješio problem usklađenosti kreiranog proizvoda sa postavljenim zahtjevima zbog procedura verifikacije i certifikacije u ranim fazama razvoj (isprekidane linije na slici označavaju zavisnost faza planiranja/uprizorenja zadataka i testiranja/prihvatanja).

Međutim, općenito, model u obliku slova V samo je kaskadna modifikacija i ima mnoge svoje nedostatke. Konkretno, oba su slabo prilagođena mogućim promjenama u zahtjevima kupaca. Ako proces razvoja traje dugo (ponekad i do nekoliko godina), onda nastali proizvod može zapravo biti nepotreban za kupca, jer su se njegove potrebe značajno promijenile.

Softver, za razliku od, na primjer, mikrokola, može se puštati u rad u dijelovima, što znači da se može razvijati i postepeno isporučivati ​​kupcu. To je ono na čemu se temelji inkrementalni model, koji uključuje podjelu proizvoda na relativno nezavisne komponente koje se razvijaju i puštaju u rad odvojeno.

Takav model je koristan i za kupca i za kreatora sistema, jer omogućava kretanje naprijed, poštujući interese obje strane.

Međutim, to ima svoje nedostatke. Podjela na funkcionalne blokove u cjelini usporava proces, jer postaje neophodno osigurati njihovu interakciju. Za mnoga rješenja ova metoda je neprimjenjiva, jer je od njih nemoguće izolirati pojedinačne komponente koje se mogu isporučivati ​​i samostalno funkcionisati. Opterećenje rukovodećeg osoblja također se značajno povećava zbog usložnjavanja zadataka koordinacije rada na pojedinačnim komponentama sistema, povećavaju se troškovi izmjena gotovih komponenti koje su već instalirane i rade kod kupca.

Spiralni model, koji je predložio Barry Boehm 1988. godine, bio je značajan napredak u razumijevanju prirode razvoja softvera, iako kombinuje pristup vodopada i iterativni proces dizajna zasnovan na izradi prototipa (slika 3).

Rice. 3.

Boehmov spiralni model fokusira se na dizajn, razvoj softvera se događa samo u posljednjoj petlji konvencionalne vodopadne spirale, ali tome prethodi nekoliko iteracija dizajna zasnovanog na prototipu - pri čemu svaka iteracija uključuje fazu identifikacije i analize rizika i najtežih problema. .

Budući da spiralni model uglavnom pokriva dizajn, onda u svom izvornom obliku nije bio široko korišten kao metoda za upravljanje cjelokupnim životnim ciklusom razvoja softvera. Međutim, njegova osnovna ideja, a to je da se proces rada na projektu može sastojati od ciklusa koji prolaze kroz iste faze, poslužila je kao polazna tačka za dalja istraživanja i postala osnova za većinu savremenih modela procesa razvoja softvera.

Prvi put koji je predložio Philip Crachten 1995. godine, iterativni model kombinuje glavne prednosti spiralnih, inkrementalnih, vodopadnih, prototipnih i objektno orijentisanih razvojnih metoda (slika 4). Stekao je veliku popularnost i koristi se u ovom ili onom obliku u mnogim modernim projektima.

Slika 4 - Iterativni model razvoja softvera

Prema iterativnom modelu, postoje četiri glavne faze u životnom ciklusu razvoja softvera (početak, istraživanje, izrada i implementacija). U svakoj fazi projekat prolazi kroz mnoge iteracije, što dovodi do stvaranja izvodljivih verzija: u početnim se kreiraju prototipovi, razjašnjavaju se zahtjevi, razrađuju najsloženiji problemi; završni dovode do stvaranja proizvoda, njegovog poboljšanja i proširenja funkcionalnosti.

Iterativni model, pored glavnih faza, razlikuje još dvije grupe procesa: radničke (upravljanje zahtjevima, analiza i dizajn, implementacija, testiranje, implementacija) i pomoćne (upravljanje konfiguracijom i promjenama, projekt i proces). Broj i priroda procesa variraju u zavisnosti od potreba programera, oni mogu imati i svoje cikluse, koji čak ne moraju ni da odgovaraju glavnim fazama. Međutim, rezultat tokova rada je uvijek kreiranje verzija proizvoda.

Iterativni model, poput spiralnog modela, omogućava uspješno upravljanje rizicima. Ako se tokom rada na sljedećoj verziji utvrdi da su troškovi rada za implementaciju potrebne funkcionalnosti previsoki, onda se prekoračenje budžeta i kršenje rokova može izbjeći korelacijom razvojnih prioriteta i troškova rada na početku rada. svaka iteracija. Dakle, ovaj model je vrlo pogodan za većinu tipova softverskih projekata, ali su njegove prednosti posebno uočljive kada se radi na proizvodima namijenjenim za slobodno tržište, zbog početne orijentacije na izdavanje sekvencijalnih verzija.

Najpoznatijim i najmjerodavnijim standardom kvaliteta treba smatrati Capability Maturity Model (CMM) – model za procjenu stepena zrelosti razvojnih procesa zajedno sa njegovim derivatima. Kreirao ga je SEI (Institut za softversko inženjerstvo), koji finansira Ministarstvo odbrane SAD i strukturna je jedinica Univerziteta Carnegie Mellon. Prva zvanična verzija standarda objavljena je 1993. godine, iako je rad na njemu počeo mnogo ranije - njegove glavne odredbe objavljene su još 1986. godine. Nekoliko faktora je unaprijed odredilo uspjeh CMM-a. Ovaj standard je bio jedan od prvih koji je u početku uzeo u obzir specifičnosti razvoja softvera. Pokazalo se da je prilično jednostavan i transparentan, kako za razumijevanje, tako i za korištenje, i regulirao je "šta", a ne "kako" raditi, te je stoga bio pogodan za različite modele životnog ciklusa, razvojne metodologije i nije nametao nikakva ograničenja u dokumentaciji. standardi, alati, okruženje i jezici koji se koriste u projektima. I, možda, glavni faktor koji je predodredio popularnost CMM-a bila je saradnja SEI-a sa Ministarstvom obrane SAD-a, što je de facto značilo korištenje standarda pri realizaciji projekata koje je naručio ovaj odjel.

CMM model (Tabela 1) pruža pet nivoa zrelosti, od kojih svaki odgovara određenim ključnim procesnim oblastima (Key Process Areas, KPA).

Tabela 1-CMM model

Naziv nivoa	Ključna područja procesa
1 - početnik	Ako je organizacija na ovom nivou, onda za nju ne postoje ključne procesne oblasti.
2 - Ponavljanje	Upravljanje softverskim konfiguracijama. Osiguranje kvaliteta softverskih proizvoda. Upravljanje ugovorom sa ugovaračem. Praćenje napretka projekata. Planiranje softverskih projekata. Upravljanje zahtjevima
3 - Definisano	Stručne procjene. Koordinacija interakcija između projektnih timova. Inženjering softverskog proizvoda. Sveobuhvatno upravljanje softverom. Program obuke osoblja. Određivanje organizacionog procesa. Obim organizacionog procesa
4 - Upravljeno	Upravljanje kvalitetom softvera. Kvantitativna kontrola procesa
5 - Optimizirano	Upravljanje promjenama procesa. Upravljanje tehnološkim promjenama. Sprečavanje kvarova

Podjela na nivoe i definicija KPA za svaki od njih omogućava dosljednu implementaciju CMM-a, koristeći standard kao vodič koji može osigurati kontinuirano poboljšanje procesa razvoja.

CMM standard se pokazao vrlo uspješnim, a potom je na njegovoj osnovi stvoren čitav niz standarda koji je dobio novo ime - SW-CMM (Capability Maturity Model for Software), što preciznije odražava njegovu poziciju u prilično brojne porodice standarda.

Međutim, praktična primjena standarda CMM serije pokazala je da oni ne daju bezuslovni uspjeh u razvoju softvera. Ovi standardi nisu bili dobro usklađeni jedni s drugima - istovremena implementacija različitih modifikacija CMM-a mogla bi biti prilično težak zadatak i zbunila je stručnjake organizacija koje su se s tim suočile.

Takođe, značajan problem kod CMM-a je potreba da se svi procesi „usklade“. Ako organizacija pokušava sertifikovati na određenom nivou, onda mora osigurati odgovarajući nivo za sve svoje procese. Čak i ako specifičnost, metodologija ili karakteristike dizajna ne pogoduju izvršavanju određenih procesa, certifikacija to zahtijeva.

Drugi problem proizlazi iz pozicije koju su CMM standardi zauzeli u današnjoj softverskoj industriji. Budući da organizacija sa visokim nivoom u skladu sa CMM mora da obezbedi veće performanse softverskih proizvoda u odnosu na one koji su sertifikovani na nižim nivoima, standard je počeo da se koristi kao kriterijum izbora za učešće na tenderima za razvoj softvera ili projekte outsourcinga.

Ovakvu situaciju omogućili su nedostaci procesa sertifikacije. Certificiranju ne podliježe cijela organizacija u cjelini, već samo određeni projekat. Ništa ne sprečava organizaciju da kreira "izlog" projekat koji ispunjava sve zahteve visokog nivoa CMM standarda, dobije odgovarajući nivo sertifikata i izjavi da svi proizvodi zadovoljavaju takav nivo standarda.

Novi SEI standard - Capability Maturity Model Integrated (CMMI) - dizajniran je da riješi većinu problema CMM - integrisanog modela za procjenu nivoa zrelosti razvojnih procesa. CMMI standard je prvobitno kreiran na način da kombinuje postojeće verzije CMM-a i eliminiše sve kontradikcije u njegovoj praktičnoj primeni u različitim oblastima visokotehnoloških kompanija.

Kako bi se eliminisala potreba da se procesi organizacije „usklade“ i budu više prilagođeni njenim poslovnim potrebama, a ne obrnuto, CMMI standard ima dva oblika prezentacije – klasični, višeslojni, koji odgovara CMM-u i novo, kontinuirano. Kontinuirana prezentacija ne uzima u obzir nivoe zrelosti, već nivoe sposobnosti, koji se procenjuju za pojedinačna područja procesa (PA).

Tabela 2 pokazuje korespondenciju između nivoa zrelosti CMM i nivoa zrelosti CMMI slojevite prezentacije i nivoa sposobnosti CMMI kontinuirane prezentacije.

Tabela 2- Korespondencija nivoa zrelosti CMM, CMMI standarda

SEI se udaljava od CMM-a i zauzvrat aktivno promoviše CMMI, obećavajući da će pooštriti kontrolu nad procesom sertifikacije, smanjiti troškove i učiniti ga privlačnijim za male organizacije; osiguravanje kompatibilnosti sa ISO standardima.

U savremenim uslovima, prisustvo sertifikata određenog nivoa CMM/CMMI nije tako značajan faktor kao što je bio pre nekoliko godina i prihvata se bez dodatnih pitanja, osim u projektima koji se izvode po nalogu Vlade.

Standard ISO/IEC 15504 namijenjen je procjeni procesa razvoja informacionih sistema, posebno softvera. Prvobitno je dizajniran da bude usko usklađen sa industrijskim standardima za evaluaciju razvoja softvera. Upravo je ovaj zahtjev odredio sličnost standarda sa osnovnim principima CMM / CMMI.

Model zrelosti procesa razvoja softvera (CMM), koji je razvio Institut za softversko inženjerstvo na Univerzitetu Carnegie Mellon, nudi pet nivoa zrelosti (Tabela 3). Pomaže organizacijama da povećaju zrelost svojih procesa razvoja softvera, a organizacije mogu biti procijenjene i akreditovane prema ovim nivoima.

Tabela 3-Nivoi zrelosti razvoja softvera

Nivo 1 - početni nivo	Proces razvoja softvera je spontan, a samo nekoliko procesa je regulirano. Uspjeh razvoja može ovisiti o pojedinačnim zaposlenima.
Nivo 2 - nivo ponovljivosti	Osnovni procesi upravljanja projektima su kreirani za praćenje troškova, rasporeda i funkcionalnosti.
Nivo 3 - Regulatorni nivo	Proces razvoja softvera je dokumentovan, standardizovan i integrisan sa standardnim procesom razvoja softvera organizacije za upravljanje i razvojne operacije. Svi projekti koriste standardizirani proces.
Nivo 4 - nivo upravljivosti	Detaljne metrike procesa razvoja softvera i kvaliteta proizvoda se prikupljaju tako da se proces i proizvodi mogu razumjeti i upravljati njima.
Nivo 5 - nivo optimizacije	Kontinuirana optimizacija procesa je obezbeđena kvantitativnim povratnim informacijama od procesa i od pilot inovativnih ideja i tehnologija.

Stoga su trenutni modeli i metode koje se koriste u stvarnim projektima razvoja softvera prilično raznoliki. Svaki od njih ima svoje prednosti, koje se manifestuju u odgovarajućim uslovima. Čak je i zastarjeli model vodopada savršeno adekvatan za neke projekte. Svaki proces također ima niz karakteristika koje ograničavaju područje njegove efektivne upotrebe. Ova situacija je prilično tipična za razvoj softvera, gdje su mnoge tehnologije i tehnike već akumulirane, ali ne postoji univerzalna metoda koja bi bila optimalna za bilo koji zadatak.

Prije nego što ponudim pregled razvojnog procesa koji je nastao kao rezultat gomilanja iskustva u proteklim godinama, želio bih dati nekoliko općih objašnjenja koja mi se čine bitnim.

U IT-u se bavim zadnjih 15 godina, iako sam programiranjem počeo mnogo ranije. Glavno područje mog djelovanja kao sistemskog arhitekte bila je organizacija razvoja softvera, razvoj koncepata i arhitekture visokog nivoa, te praćenje implementacije koncepta tokom cijelog projekta. Osim upravljanja razvojem softvera i kreiranjem arhitekture, s vremena na vrijeme se bavim rješavanjem složenih tehničkih problema i pisanjem nekih kritičnih dijelova koda, gdje je potrebno ne samo poznavati sam jezik i razvojno okruženje, već i njihovu unutrašnju organizaciju. , što ponekad predstavlja neugodna iznenađenja.

Projekti na kojima radim najčešće su vezani za razvoj prilagođenog ili investicijskog softvera. Takođe sam morao da radim sa ugrađenim softverom i programima fokusiranim na izdavanje „hitova“ (koje, uz laku ruku Joela Spolskog, nazivam daljim softverom za igre, iako su u stvari neki projekti igara bliži investicionim projektima).

Prilagođeni softver može biti za internog ili eksternog kupca. Kupac dobija ekskluzivna prava na razvijeni sistem, a rad na razvoju sistema može se u budućnosti preneti na drugog izvođača.

Za razliku od prilagođenog softvera, radove na investicionom softveru izvodi sam izvođač o trošku internog ili eksternog investitora. U pravilu, prava na sistemski kod ostaju izvođaču, što stimulira kontinuirani rad na poboljšanju njihovog proizvoda i dosljedno izdavanje verzija sa naprednijom funkcionalnošću.

Ugrađeni softver se isporučuje sa hardverom i, grubo rečeno, ne podleže održavanju, jer je proizvođačev opoziv serije uređaja veoma skup i samim tim izuzetan.

Razvoj pogodaka iz igre također praktično ne sadrži fazu pratnje. Osim toga, korisnici programa za igre, čak i kada se suoče s greškom u igri, vrlo rijetko preuzimaju ažuriranu verziju. Stoga razvoj igara obično ima svoju ekonomiju i vlastiti razvojni proces.

Naši kupci su državni organi, velike državne i komercijalne organizacije i, naravno, mi sami. Stoga, u smislu prilagođenog softvera, često postoji određena razlika u našem procesu između procesa razvoja proizvoda za interne i eksterne kupce. Istaknut ću neke od nijansi u ovom članku. Nivo formalizacije odnosa sa kupcem varira od projekta do projekta veoma široko. Generalno, što je veći budžet projekta, to je veća formalnost. Državni kupac ili velika komercijalna preduzeća (posebno sa državnim učešćem) obično imaju zakonska ograničenja u formiranju, izdavanju naloga i prihvatanju rezultata rada. Još jedno ograničenje velikih organizacija je činjenica da njihovo osoblje, koje je izvor zahtjeva i glavni korisnik naših sistema, ima vrlo ograničenu dostupnost izvođačima, makar samo zbog zaposlenja. Međutim, za male organizacije nivo formalizacije opada i ponekad ide u suprotnu krajnost, gde postoji nedovoljan nivo odgovornosti korisnika u okviru projekta.

Druga strana naših projekata po mjeri su visoki zahtjevi za funkcionalnošću. Ovo je i veliko opterećenje na svim sistemima, i velika geografska distribucija, i visoki zahtjevi za preciznošću proračuna sa vrlo ograničenim vremenskim okvirom. Često u našim projektima postoje elementi istraživanja i kreativnog traženja usmjerenih na rješavanje netrivijalnih problema dizajna. Ponekad moramo kombinovati različite metodologije unutar jednog razvojnog procesa, na primjer, ubacivanje jedne ili više faza gotovo čistog scrum-a u opći proces, blizak RUP-u, što dovodi do nečega poput projekta unutar projekta. To nam omogućava da održimo nizak nivo uključenosti korisnika povezan sa prirodom projekta, uz fleksibilnost razvoja u okruženju visoke neizvjesnosti zahtjeva. S tim u vezi, za mene je važna pripremna faza tokom koje možete izabrati potrebnu metodologiju i izgraditi optimalan razvojni proces. Jedan od primjera upotrebe agilne metodologije opisao sam u članku "Korišćenje agilnog u razvoju projekta za državnog kupca".

Kao primjer rada na investicionom projektu mogu navesti razvoj integrisanog sigurnosnog sistema koji smo kreirali kao “boxed” proizvod. Pod mojim vodstvom, uzastopno su objavljene četiri verzije ovog sistema koje su koristile razne komercijalne i vladine organizacije, uključujući Ured gradonačelnika Moskve, AFK Sistema, banke, poslovne centre i, naravno, našu vlastitu kancelariju. Prva verzija nije bila baš uspješna, ali smo imali strategiju razvoja koja nam je omogućila da uspješno osvojimo tržište i preživimo teška vremena krize. Iskustvo rada na ovom i nekoliko drugih investicionih projekata takođe je uzeto u obzir prilikom formiranja razvojnog procesa koji sam koristio.

Naš proces je niz određenih faza. Klasifikacija softvera koju sam dala je napravljena samo da pokaže moguću razliku u organizaciji razvoja različitih softverskih alata. Dajući pregled procesa razvoja, fokusiraću se samo na razlike u samom procesu u odnosu na različite tipove softvera. Međutim, moramo imati na umu da su razlike između procesa razvoja različitih vrsta softvera mnogo dublje, pa se pri planiranju svake faze moraju uzeti u obzir ove nijanse.

Važno je shvatiti da prelazak procesa iz jedne faze u drugu nema jasne granice. Po pravilu, rad sledeće faze počinje kada se završi 80-90% radova na prethodnoj fazi. Ovo se posebno odnosi na razvoj zahtjeva, kada se u nekim slučajevima otklanjanje neizvjesnosti događa tek do kraja projekta. Naravno, prisustvo takve neizvjesnosti u projektu predstavlja značajan rizik i treba ga stalno pratiti.

Proces razvoja softvera po narudžbi

Započnimo naš pregled procesa razvoja s najčešćim slučajem - razvojem softvera po narudžbi. Dijagram toka procesa prikazan je na slici 1.

Slika 1. Prilagođeni proces razvoja softvera.

Rad na projektu počinje pripremnom fazom. Svrha faze je kreiranje određenog koncepta budućeg sistema na osnovu prijedloga korisnika i na osnovu tog koncepta procijeniti relevantnost i izvodljivost projekta. Ako odluku o privlačenju izvođača donosi naručilac na konkursnoj osnovi, onda je preliminarna faza zapravo faza pripreme potencijalnog izvođača za konkurs, uključujući i formiranje potrebne dokumentacije.

Nema potrebe za gubitkom vremena i resursa na projekat čiji je koncept prepoznat kao nepotražen ili neostvariv. Takav projekat mora biti završen. U nekim slučajevima, potreban je iterativni rad s klijentom da bi se ispravio koncept projekta, sve dok se ne postigne prihvatljiva ravnoteža između zahtjeva kupca i troškova izvođača, ili dok se ne donese odluka o smanjenju posla.

Projekat, čiji koncept izgleda prihvatljivo za implementaciju, ulazi u fazu izrade zahtjeva. U ovoj fazi izvođač mora formirati listu svih eksplicitnih i skrivenih potreba kupca. Često se ispostavi da je kupac ili neodlučan o svojim potrebama, ili njegove potrebe dolaze u sukob jedna s drugom, sa mogućnostima kupca ili sa mogućnostima izvođača. Ciljevi faze su identifikovanje svih latentnih potreba, rješavanje sukoba zahtjeva, formiranje holističkog tehničkog rješenja i analiza izvodljivosti pripremljenog rješenja.

Ponekad razjašnjavanje zahtjeva dovodi do revizije koncepta projekta. Ako nakon razjašnjenja svih zahtjeva nije moguće pronaći prihvatljivo tehničko rješenje, projekat se mora smanjiti ili odgoditi za neko vrijeme u očekivanju prihvatljivijih okolnosti.

Ukoliko se pronađe tehničko rješenje, izvođač prelazi na razvoj arhitekture budućeg sistema. Cilj ove faze je definiranje logičke i fizičke arhitekture visokog nivoa koja u potpunosti pokriva sve zahtjeve kupaca. U toku razvoja arhitekture vrši se pregled i dorada koncepta, zahtjeva i idejnog tehničkog rješenja, što omogućava prevenciju najopasnijih rizika.

Nakon završetka arhitektonskog projekta potrebno je ponovo revidirati glavne parametre projekta i odlučiti da li je izvođač u mogućnosti da završi projekat. Korisno je u fazi projektovanja arhitekture napustiti nepotrebne i preglomazne funkcije. Optimizacija arhitektonskog rješenja često pomaže da se uklopi u prihvatljive parametre projekta. U drugim slučajevima potrebno je radikalnije smanjenje funkcionalnosti sistema koji se razvija. Međutim, čak i zaustavljanje projekta u ovoj fazi, ako se to dogodi iz dobrih razloga, treba shvatiti kao pobjedu: nastavak rada u ovom slučaju može dovesti samo do još većih gubitaka.

Ako je ravnoteža pronađena i bilo je moguće kreirati prihvatljivu arhitekturu sistema, izvođač može pristupiti implementaciji i isporuci sistema. Implementacija se može odvijati u jednoj ili više faza. Za male projekte, isporuka svih funkcionalnosti sistema u jednoj fazi može biti sasvim prihvatljiva. Međutim, što je veći projekat, to su veće zavisnosti podsistema unutar sistema koji se kreira. U ovim uslovima implementaciju treba podeliti u nekoliko faza tako da na kraju svake faze razvojni tim ima proizvod spreman za isporuku. U ovom slučaju, najvažniju, fundamentalnu funkcionalnost treba razviti u ranoj fazi, a dodatke koji rade na ovim osnovnim komponentama treba implementirati kasnije. U ovom slučaju, najopasnije greške za sistem će biti ispravljene u prvim fazama, a rizik da će primenjena funkcionalnost sistema biti zasnovana na nestabilnoj osnovi biće značajno smanjen.
Nakon isporuke potpuno završenog sistema, prilagođeni softverski projekat obično prelazi u fazu probnog rada. Svrha ove faze je testiranje kvaliteta razvijenog sistema u realnim uslovima rada. U pravilu, u ovoj fazi izvođač, zajedno sa naručiteljem, mjeri kvantitativne metrike koje omogućavaju određivanje kvaliteta kreiranog sistema. Prije svega se provjeravaju funkcionalne karakteristike kvaliteta, a zatim one nefunkcionalne. Ako postoje nedosljednosti, izvođač ispravlja šifru sistema.

Potpuno otklonjen i podešen sistem pušten je u komercijalni rad. Kao opšte pravilo, izvođač mora pratiti sistem najmanje tokom garantnog perioda. Sve identificirane neusklađenosti treba ispraviti. Korisnici i osoblje korisničke službe treba da dobiju brzu i savjetodavnu podršku.

Konačno, dolazi trenutak kada sistem iz nekog razloga prestaje da odgovara kupcu. Počinje faza dekomisije sistema. Međutim, za prilagođeni softver ova faza nije uvijek relevantna, jer kupac može iskoristiti svoja isključiva prava na sistem i udaljiti izvođača od daljeg rada na održavanju i razvoju sistema i prije nego što on izgubi na važnosti.

Svaki projekat na kraju dođe do kraja. Faza završetka projekta ima za cilj analizu rezultata, unošenje promjena u razvojni proces na osnovu stečenog iskustva i dopunu baze znanja programera novim efikasnim rješenjima i upozorenjima, kao i novim gotovim komponentama koje se mogu koristiti u budući projekti.

Ostaje napomenuti još dvije faze procesa razvoja. Dešava se da okolnosti ne dozvoljavaju nastavak projekta, ali rezultati obavljenog posla pokazuju da projekat može imati budućnost. Prerano je zatvarati takav projekat. Stoga, umjesto potpunog zaustavljanja radova, izvođač može privremeno obustaviti projektne aktivnosti, popravljajući postignute rezultate. Čim okolnosti dozvole, projekat se može nastaviti ponovnim aktiviranjem infrastrukture, vraćanjem programera u projekat i vraćanjem stanja projekta. Važno je, međutim, nastaviti rad od faze u kojoj je projekat prekinut ponovnom revizijom postignutih rezultata.

Proces razvoja investicionog softvera

Proces razvoja investicijskog softvera razlikuje se po tome što se paralelno može raditi na nekoliko verzija proizvoda odjednom: dok se prva verzija održava, druga se već implementira, a zahtjevi su formulirani za treću. Proces je prikazan na slici 2.

Slika 2. Proces razvoja investicionog softvera.

Kao što je lako vidjeti, prilikom razvoja investicionog softvera, odvijaju se iste faze koje su gore razmotrene za proces razvoja prilagođenog softvera. Međutim, razlika je u tome što se koraci ne odnose na cijeli proizvod, već na pojedinačnu verziju proizvoda. Izuzetak je faza završetka projekta: projekat se ne može završiti dok se radi na najmanje jednoj verziji proizvoda.

Obratite pažnju na trenutak početka rada na sljedećoj verziji proizvoda. Ovaj trenutak dolazi čim se prođe faza kreiranja arhitekture trenutne razvojne verzije. Prije toga, u fazama formiranja zahtjeva i kreiranja arhitekture, po pravilu se vodi rasprava o tome koje funkcije treba implementirati u tekućoj verziji, a koje prenijeti u budućnost. I tek kada su zahtjevi za trenutnu verziju formulirani, pregledani i potvrđeni arhitekturom sistema, ima smisla razmišljati o sljedećoj verziji.

Osim toga, nakon razvoja arhitekture, po pravilu, analitičari i projektni arhitekti imaju određenu slobodu djelovanja, jer glavni teret pada na programere u fazama isporuke. Ova sloboda se može koristiti za izradu koncepta i zahtjeva za sljedeću verziju.

U principu, početak rada na sljedećoj verziji možete odgoditi za kasniji datum. Na primjer, sasvim je prihvatljivo prvo staviti trenutnu verziju u probnu ili čak komercijalnu radnju, a tek onda započeti rad na sljedećoj verziji. Ali morate imati na umu da takvo rješenje nije primjenjivo u slučaju velike konkurencije: jednostavno ćete biti nadmašeni i istisnuti s tržišta. Odluka se mora donijeti na osnovu čitavog kompleksa okolnosti koje utiču na vaše poslovanje.

Govoreći o procesu razvoja investicionog softvera, morate shvatiti da rad na nekoliko verzija ima brojne eksplicitne i skrivene međuzavisnosti između paralelnih grana procesa.

Prvo, ispravke za nedosljednosti identificirane u ranijoj verziji trebale bi biti unesene i na verziju u kojoj su pronađene i na sve kasnije verzije, uključujući one u razvoju. Ovo se ne odnosi samo na programski kod, već i na sve ostale artefakte projekta: tehničku i korisničku dokumentaciju, sistem pomoći, procjene i planove rada itd. Štaviše, ispravke treba izvršiti odmah, jer nećete moći smanjiti troškove ispravki, ali ako odmah ne izvršite ispravke, njihova cijena u kasnijim fazama može se povećati desetke, pa čak i stotine puta.

Drugo, za paralelni rad na nekoliko verzija potrebna je posebna projektna infrastruktura, uključujući organizaciju kontrole verzija koda i dokumentacije, kontrolu zadataka i neusklađenosti, automatske programe za izgradnju i testiranje itd. Rad na jednoj verziji proizvoda ne bi trebao biti dopušten da blokira zadatke na drugim verzijama samo zato što infrastruktura projekta ne dozvoljava pokretanje dva procesa izgradnje u isto vrijeme za različite verzije proizvoda.

Posebnu pažnju treba obratiti na štandove na kojima se vrši testiranje: na njima treba postaviti sve verzije proizvoda koje su ranije objavljene (barem one verzije koje su podržane) i sve verzije koje se trenutno razvijaju.

Treće, isti saradnici mogu biti uključeni u rad na više verzija u isto vrijeme. Postoji veliki rizik da se ključni zaposlenik može zaglaviti u radu na jednoj verziji programa i dozvoliti značajno prekoračenje zadataka koji se odnose na drugu verziju.

Četvrto, dešava se suprotna situacija, kada osoblje koje radi na jednoj verziji ne zna ništa o tome koje odluke se donose u okviru rada na drugoj verziji. Problem je djelimično riješen ako se ispravke cjelokupne dokumentacije i koda odmah distribuiraju na sve kasnije verzije, kao što sam već pomenuo. Ali stvar ne bi trebala biti ograničena samo na ispravke. Tim koji radi na jednoj verziji mora razumjeti zašto su određene odluke donesene pri radu na drugoj verziji. Za to je potrebna baza znanja za programere – poseban informacioni sistem koji treba da opiše sve probleme sa kojima su se programeri susreli dok su radili na određenoj verziji proizvoda i kako da te probleme reše. Baza znanja treba da šalje obavještenja o novim unosima svim učesnicima projekta. Ne možete dopustiti da interakcija dva tima koja rade na različitim verzijama istog proizvoda ide svojim tokom.

Proces razvoja ugrađenog softvera

Kao što je gore navedeno, firmver se razlikuje od prilagođenog firmvera po tome što ga je izuzetno teško održavati.

Recimo da puštate programe za frižidere. Jednom kada se softver pošalje proizvođaču, desetine hiljada uređaja počinju da se raspršuju širom svijeta, a vi nemate pojma gdje će završiti. A ako se jedan od frižidera pokvari zbog greške vašeg softvera, onda je lakše platiti odštetu nego vratiti frižider u fabriku i obaviti dijagnostiku. Naravno, moguće je obučiti inženjere u zastupnicima koji mogu izvršiti dijagnostiku na licu mjesta i zamijeniti firmver vašeg sistema, ali je to i dalje veoma skupo.

Stoga, prilikom razvoja ugrađenog softvera, odjednom se pojavljuje nekoliko važnih ograničenja.

Prvo, isporuka se odvija u okviru samo jedne faze: niko neće ugrađivati ​​napola radni program u uređaje.

Drugo, prilikom isporuke treba obratiti posebnu pažnju na kvalitet programa, jer će ga od trenutka kada se unese u željeznu kutiju biti vrlo teško promijeniti. Posebnu pažnju treba posvetiti fazi probnog rada, kada se program implementira u ograničenoj seriji uređaja, a ovi uređaji prolaze sveobuhvatna testiranja u različitim režimima rada. Morate prikupiti što je više moguće informacija o dinamici ponašanja vašeg sistema, analizirati ove informacije i modificirati softver.

Treće, kada se uređaj sa vašim softverom serijalizuje, imate vrlo malo mogućnosti da ispravite greške. Zapravo, ovakvi popravci su mogući samo u slučaju softverskog kvara, koji dovodi do nefunkcionalnosti cijele serije uređaja, zbog čega će proizvođač biti primoran da povuče ovu seriju, a vi ćete dobiti veliku crnu tačku na svom reputacija.

Konačno, četvrto, ne postoji faza dekomisije za firmver. Program se jednostavno baca zajedno sa uređajem. Stoga, čim istekne garantni rok za seriju uređaja na kojima je pokrenut vaš softver, možete nastaviti sa zatvaranjem projekta.

Proces razvoja firmvera prikazan je na slici 3.

Slika 3. Proces razvoja ugrađenog softvera.

Proces razvoja igre

Softver za igre sam odabrao zbog specifičnosti njihove proizvodnje i rada. Posao sa softverom za igre je sve o udarcima. Jedan uspješan pogodak plaća troškove stvaranja više igara koje korisnici ne primjećuju. Stoga je razvojni proces jedne igre međusobno povezan sa razvojnim procesima drugih igara.

Drugi faktor koji razlikuje proizvodnju igara je činjenica da je igra interesantna korisniku ili dok ne prođe zadnji nivo, ili dok ne napravi fatalnu grešku. To znači da neće kupiti drugu verziju igre ili je čak besplatno preuzeti samo da bi popravio nekoliko grešaka.

Ovi faktori utiču na proces razvoja softvera za igre. Proces je prikazan na slici 4.

Slika 4. Proces razvoja softvera za igre.

Treba napomenuti sljedeće karakteristike procesa razvoja softvera za igre.

Prije svega, kvalitet koncepta je izuzetno važan u proizvodnji igara. Ako vam koncept igre ne dozvoljava da napravite pogodak, onda je dalji rad besmislen. Situacija kada se većina projekata završava u pripremnoj fazi tipična je za razvoj softvera za igre.

Kada se razvijaju zahtjevi i arhitektura za softver za igre, često je slučaj da se lekcije naučene iz prethodnih projekata ponovo koriste. U tom smislu, faza završetka projekta takođe dobija dodatnu težinu, kada svi korisni razvoji moraju biti zabeleženi u bazi znanja programera.

Isporuka softvera za igre se odvija u jednoj fazi. Čak i ako se isprva kreira određeno jezgro, "motor" sistema igre, njegov rad se ne može provjeriti bez implementacije svih funkcionalnosti sistema.

Za softver za igre ne postoje faze probnog rada i prestanka rada. Igre odmah idu u prodaju, a nakon upotrebe ih korisnik jednostavno briše jer gubi interesovanje za njih.

Zaključak

U okviru članka pokušao sam da pružim pregled „najvišeg nivoa“ procesa razvoja aplikativnog softvera. Svaka faza procesa, naravno, zahtijeva posebnu raspravu uz obavezno razmatranje posebnosti razvijenog softvera.

Imajte na umu da je dijagram toka koji se ovdje razmatra rezultat generalizacije mog ličnog iskustva u razvoju različitih softverskih alata. Kao i svaka generalizacija, moja shema je apstrakcija. I, kao i svaka apstrakcija, ima svoje granice primjenjivosti. Ne možete nepromišljeno primijeniti ovu šemu na određeni projekat. Važno je shvatiti da svaki projekat ima svoje nijanse koje utječu na organizaciju procesa razvoja. I stoga, za svaki projekat, shema koja je ovdje navedena treba se prilagoditi, au nekim slučajevima bit će potrebno razviti fundamentalno drugačiji pristup.

Faze razvoja softvera

Proces razvoja softvera može se podijeliti na faze (faze):

- razvoj modela i odabir metode rješenja;

- razvoj algoritma za rješavanje problema;

- algoritamsko kodiranje;

- sastavljanje programa;

- testiranje programa;

- izrada dokumentacije;

- održavanje i rad.

Kao rezultat ove faze rada sastavlja se dokument pod nazivom "Zadatak za razvoj softvera (tehnički zadatak)". U njemu se navodi sljedeće:

- naziv zadatka. Daje se kratka definicija problema koji se rešava, navodi se naziv softverskog paketa, sistem programiranja za njegovu implementaciju i hardverski zahtevi;

- opis. Detaljno su prikazani iskaz problema, svrha i svrha problema, njegovo mjesto i veze sa drugim problemima, sadržaj funkcija obrade ulaznih informacija pri rješavanju problema, zahtjevi za učestalost rješavanja problema.

- kontrola načina rada programa. Formulirani su osnovni zahtjevi za način interakcije između korisnika i programa (sučelje korisnik-računar).

- ulazni podaci. Opisani su ulazni podaci, granice u kojima se mogu mijenjati, vrijednosti koje ne mogu preuzeti itd., kao i izvor podataka, tj. uređaj sa kojim će se prenijeti u program.

- izlaz. Opisani su izlazni podaci, naznačeno je u kom obliku ih treba prikazati - numerički, grafički ili tekstualno, ograničenja u vremenu i tačnosti izlaznih informacija, a naznačeno je i uređaj za prikazivanje ovih podataka.

- greške. Navedene su moguće greške korisnika pri radu sa programom (npr. greške prilikom unosa podataka i sl.). Metode dijagnostike (u ovom slučaju dijagnostika znači otkrivanje grešaka tokom rada softverskog paketa) i zaštita od ovih grešaka u fazi projektovanja, kao i mogući odgovor korisnika kada počini pogrešne radnje i odgovor softverskog paketa (računara) na ove radnje.

- primjer rada softverskog paketa. Dat je jedan ili više primjera rada programskog kompleksa na kojima se, u najjednostavnijim slučajevima, debagira i testira.

Razvoj modela i izbor metode rješenja... U ovoj fazi stvara se matematički ili logički model istraživanog fenomena stvarnog svijeta. Istovremeno, morate biti u stanju da formulišete jezikom matematike specifične probleme fizike, ekonomije, tehnologije itd. Nakon što je određen matematički model problema, potrebno je odabrati metodu za njegovo rješavanje. Ako je programirani zadatak računske prirode, tada se daje izlaz svih korištenih formula sa detaljnim komentarima. Ako zadatak nije računski, tada se daje verbalni opis logičkog modela, na primjer, u obliku akcionog plana.

Razvoj algoritma za rješavanje problema... U ovoj fazi se formira opšta struktura softverskog paketa. Algoritam – to je sistem precizno formulisanih pravila koji određuje proces pretvaranja dozvoljenih ulaznih podataka (ulaznih informacija) u željeni rezultat (izlazne informacije) u konačnom broju koraka.

U procesu razvoja algoritma mogu se koristiti različiti načini njegovog opisivanja: verbalna notacija, blok dijagrami, pseudokod, strukturni dijagrami itd.

Rečenice koje nisu rečenica nekog programskog jezika, iako su vrlo slične onome što pišemo u ovom programskom jeziku, nazivaju se pseudokod . Pseudocode veoma efikasan u dizajniranju programske logike. Nakon što vam se logika učini ispravnom, možete obratiti posebnu pažnju na detalje prijevoda. pseudokod u pravi programski jezik. Prednost korištenja pseudokod je to što vam omogućava da se koncentrišete na logiku i strukturu programa, bez brige o tome kako prevesti ove ideje na jezik mašine. Ako želimo poboljšati program, prvo ga moramo unaprijediti algoritam!

Algoritamsko kodiranje. Faza kodiranja (programiranja) algoritama se sastoji u prevođenju algoritama razvijenih za svaki softverski modul u programe na određenom programskom jeziku. Rezultat ove faze su datoteke sa izvornim kodom programa. Ove datoteke su tekstualne prirode, samo što sadrže tekstove napisane u programskom jeziku (u našem slučaju to su tekstovi napisani u C).

Kompilacija programa. Nakon što se završi kodiranje (pisanje programa na programskom jeziku) i izvorni kod programa se unese u memoriju računara, program se kompajlira, tj. prevod izvornog teksta u mašinski kod. Ovaj proces izvodi poseban program - kompajler. Slika 1 prikazuje dijagram pripreme izvršnog programa.

Prvo, program se prenosi pretprocesor koji izvodi direktive sadržane u njegovom tekstu (na primjer, #include - uključujući datoteku u tekstu programa).

Rezultirajući tekst se prosljeđuje na ulaz kompajler (Kompajler) , koji izdvaja tokene (pojedinačne riječi), a zatim, na osnovu gramatike jezika, prepoznaje izraze i operatore izgrađene od ovih tokena. U ovom slučaju, kompajler otkriva sintaktičke greške i, ako ih nema, gradi objektni modul.

linker, ili uređivač linkova (Linker) , forme izvršni modul programe povezivanjem drugih objektnih modula sa objektnim modulom, uključujući one koji sadrže funkcije biblioteke, na koje se poziva bilo koji program. Nakon uspješnog završetka procesa formira se izvršna datoteka programa (datoteka sa ekstenzijom EXE).

Testiranje programa. Postoje dvije vrste testiranja: samostalno i složeno. Autonomno testiranje uključuje pojedinačne softverske module koji čine softverski paket. Sveobuhvatno testiranje se sastoji u provjeri cjelokupnog softverskog paketa. Za testiranje se biraju takvi početni podaci za koje je unaprijed poznat rezultat izvršenja programa.

Izrada dokumentacije. Dokumentacija je klasifikovana prema namjeni i može se podijeliti u nekoliko grupa: opis aplikacije, korisnički priručnik, priručnik za programere.

Opis aplikacije- opšte karakteristike softverskog proizvoda i obim njegove primene, zahtevi za osnovni softver, skup tehničkih alata za obradu.

Korisnički vodič- detaljan opis funkcionalnosti i tehnologije rada sa softverskim proizvodom za krajnjeg korisnika. Dokumenti ove vrste mogu se izdati u štampanom obliku i (ili) "ugraditi" u softverski paket (u ovom drugom slučaju pomoć u obliku nagoveštaja poziva sam korisnik tokom rada softverskog paketa).

Programer's Guide namijenjeno programerima i stručnjacima koji će ga pratiti. Ovo uputstvo uključuje kao ključne dokumente:

Zadatak za razvoj softvera (tehnički zadatak);

Specifikacija;

Komentirani izvorni tekstovi (listine) programskih modula i upravljačkog modula;

Šema podjele softverskog paketa na softverske module;

Dijagram toka podataka softverskog paketa;

Shema interakcije softverskih modula;

Planovi i podaci za testiranje softverskog paketa;

Drugi materijali koji ilustruju projekat, na primer: blok dijagrami softverskog paketa i softverskih modula.

Održavanje i rad. Nakon završenog testiranja softverskog paketa, softver se pušta u rad. Tokom rada može biti potrebno dodati nove funkcije softverskom paketu, eliminisati greške otkrivene tokom rada itd. Ovakav rad sa softverskim paketom tokom njegovog rada naziva se održavanje.

Postoji državni standard koji utvrđuje faze razvoja programa i softverske dokumentacije za računare, komplekse i sisteme, bez obzira na njihovu namenu i oblast primene.

Proces razvoja softvera može se podijeliti na faze (faze) prikazane na Sl. 15.

Rice. 15. Faze razvoja softvera

Rad na softveru počinje izradom dokumenta pod nazivom "Zadatak izrade softvera (tehnički zadatak)".

Samo pri rješavanju najjednostavnijih problema prikazanih na sl. 15 koraka se izvodi jedan za drugim u redoslijedu kojim su prikazani. Općenito, proces razvoja softvera zahtijeva stalno vraćanje na prethodne faze i promjene. S tim u vezi, na sl. 15 pravougaonika sa nazivima bina povezanih je ne samo okomitim linijama, već i linijama koje omogućavaju povratak sa bilo koje pozornice na pozornicu koja se nalazi iznad nje. To znači da se svaki korak može izvesti iznova.

Tehnički zadatak

Projektni zadatak uključuje tri faze: 1) obrazloženje potrebe za razvojem programa; 2) obavljanje istraživačkog rada; 3) izradu i davanje saglasnosti na tehničke specifikacije.

Prije nego što nastavi sa razvojem tehničkih specifikacija, kupac mora ispravno postaviti zadatak. Iskaz problema je stvoriti matematički ili logički model istraživanog procesa ili fenomena. Ovdje je potrebno utvrditi da li će softversko rješenje biti ispravno. Možda bi bilo bolje koristiti dobro poznati aplikativni softver (sisteme za upravljanje bazama podataka, procesore proračunskih tablica, itd.) ili jednostavno riješiti problem sa nekoliko listova papira i olovkom. Ako se napravi izbor u korist izrade novog programa, onda je potrebno odabrati i opravdati kriterijume za efektivnost i kvalitet razvijenog programa. U slučaju razvoja velikog softverskog paketa, potreba za istraživanjem i razvojem je opravdana.

Kao rezultat istraživačkog rada utvrđuju se strukture ulaznih i izlaznih podataka, vrši se preliminarni odabir metoda za rješavanje problema i obrazlaže temeljna mogućnost rješavanja problema.

Izrada i odobravanje tehničkih specifikacija uključuje:

Određivanje programskih zahtjeva;

Izrada studije izvodljivosti za razvoj programa;

Određivanje faza, faza i rokova izrade programa i dokumentacije za njega;

Izbor programskih jezika;

Utvrđivanje potrebe za istraživačkim radom u narednim fazama;

Koordinacija i odobravanje tehničkih specifikacija.

U ozbiljnim firmama rezultat ove faze je opšti opis sistema, uključujući zahteve za program i zahteve za pouzdanost programa. Zahtjevi za program ili softverski proizvod daju odgovore na sljedeća pitanja:

Šta treba da bude unos?

Koji su podaci tačni, a koji netačni?

Ko će koristiti softver i kakav bi trebao biti interfejs (sredstvo komunikacije sa korisnikom)?

Koja se pojednostavljenja, pretpostavke i pretpostavke mogu napraviti u vezi sa programima?

Kakav bi trebao biti izlaz?

Zahtjevi za pouzdanost definiraju obezbjeđenje pouzdanog rada programa. Utvrđuju se greške koje je potrebno otkriti i poruke koje je poželjno prikazati korisniku u prisustvu grešaka. Navedene su sve posebne situacije koje zahtijevaju dodatno računovodstvo i posebno razmatranje.

Projektnim zadatkom određuju se uslovi rada (temperatura ambijenta, relativna vlažnost itd. za odabrane vrste nosača podataka), pod kojima se moraju osigurati navedene karakteristike, kao i vrsta usluge, potreban broj i kvalifikacija osoblja. .

Dizajn

Projektovanje uključuje dvije faze: idejni projekat i tehnički projekat. Nacrt projekta sastoji se od preliminarnog razvoja strukture ulaznih i izlaznih podataka i opšteg opisa algoritma za rješavanje problema. Prilikom izrade tehničkog projekta specificiraju se strukture ulaznih i izlaznih podataka i određuju njihovi oblici prezentacije. Naveden je algoritam za rješavanje problema, određena semantika i sintaksa programskog jezika i razvijena struktura programa. Obje faze su praćene napomenom s objašnjenjem i studijom izvodljivosti.

Proces dizajna je bitan dio svakog razvoja softvera. U skladu sa tehnologijom top-down strukturiranog programiranja, softverski paket je podijeljen na male dijelove - softverske module. Svaki pojedinačni podzadatak treba da bude relativno nezavisan i da predstavlja neki kompletan modul programa. Modularnost programa je njegova važna osobina. Tokom procesa dizajna, važno je detaljno opisati ne samo svrhu svakog modula, već i tokove podataka između modula. Svaki modul ima dva važna svojstva:

1) ima sredstva za interakciju sa spoljnim okruženjem;

2) je samostalna softverska jedinica koja obavlja određene funkcije.

Tokovi podataka su dio interfejsa. Prilikom njihovog opisivanja za svaki modul potrebno je odgovoriti na sljedeća pitanja:

Koji podaci se mogu proslijediti modulu prije nego što počne da se izvršava?

Koja su pojednostavljenja, pretpostavke i pretpostavke napravljene u vezi sa modulom?

Šta će se dogoditi s podacima nakon što modul završi svoj rad?

Na sl. 16 prikazuje primjer opisa modula koji se koristi za sortiranje cijelih brojeva.

Rice. 16. Primjer specifikacije modula

Nakon što je razvijena cjelokupna struktura programa, potrebno je utvrditi koji bibliotečki alati se mogu koristiti i koje nove procedure treba razviti. Zatim se razvijaju algoritmi za novostvorene module.

Određena je šema interakcije softverskih modula, nazvana shema tokova podataka softverskog kompleksa. U toku je izrada plana i početnih podataka za testiranje softverskih modula i cjelokupnog softverskog paketa.

Radni nacrt

Radni projekat obuhvata izradu programske i programske dokumentacije, kao i testiranje programa.

Faza algoritama kodiranja sastoji se u prevođenju algoritama razvijenih za svaki softverski modul u programe na određenom programskom jeziku. Ova faza nije glavna u programiranju, iako se nastavlja tokom ostatka životnog ciklusa proizvoda. Ako se faza dizajna provodi u dobroj namjeri, sučelja modula su ispravno definirana, tada se kodiranje provodi prilično brzo.

Kodiranje bi trebalo biti jednostavno. Mora se poštovati takozvani princip KISS: Keep It Simple, Stupid (neka bude jednostavan, budalo!). Sofisticirano programiranje može biti skupo prilikom otklanjanja grešaka i modifikacije programa. Neobično kodiranje (na primjer, iskorištavanje skrivenih mogućnosti mašine) često ometa otklanjanje grešaka u programu i, naravno, otežava drugim programerima da ga koriste.

Iskusni programeri kreiraju univerzalne programe. Svestranost je nezavisnost programa od specifičnog skupa podataka. Na primjer, program opće namjene koristi varijable kao parametre, a ne konstante, obrađuje degenerirane slučajeve itd. Svestranost programa štedi vrijeme za daljnji rad na njemu i pruža široke mogućnosti za korištenje. Razvojem takvih programa možete predvidjeti buduće promjene u specifikacijama ovog programa.

Formati unosa treba da budu dizajnirani sa maksimalnom jednostavnošću za korisnika i minimalnim potencijalom greške na umu. Redoslijed varijabli i formata podataka poznatih korisniku pomoći će da se izbjegnu greške i olakšaju korištenje programa. Izlazni formati mogu se jako razlikovati. Ponekad se daju jasne instrukcije i rezultat je prilagođen određenom standardu. Rezultati proračuna bi trebali biti čitljivi i razumljivi za one koji nisu programeri.

Nakon što su moduli ili program kodirani, dolazi trenutak njegovog pokretanja za izvršenje. Najvjerovatniji rezultat ovoga će biti poruka o grešci. Greška je pronađena, ispravljena i sve se ponavlja iz početka. Ovaj proces se naziva otklanjanje grešaka. Otklanjanje grešaka se sastoji u određivanju lokacija grešaka, otkrivanju uzroka njihovog nastanka i eliminisanju ovih uzroka.

Testiranje se obično radi u dvije faze. Prvi je jedinično testiranje. Provjerava se ponašanje i pouzdanost svakog modula. Druga faza je integracijsko testiranje. Moduli su povezani u zajednički program, a programer se brine da moduli ispravno komuniciraju. Program koji kontroliše rad modula testira se odvojeno od modula. Sami moduli su u njemu zamijenjeni takozvanim "stubovima". Lažni modul ima ulaz, izlaz i potrebnu poruku. Poruka može sadržavati listu podataka prenesenih u modul.

Testiranje je testiranje performansi programa. Otklanjanje grešaka se dešava kada program očigledno ne radi ispravno. Otklanjanje grešaka uvijek počinje u očekivanju neuspjeha programa. Ako se pokaže da program radi ispravno, onda se testira. Često se dešava da nakon pokretanja testova program mora ponovo da se otkloni greške. Dakle, testiranjem se utvrđuje činjenica da postoji greška, a otklanjanje grešaka otkriva njen uzrok.

Za jednostavnu primjenu, testiranje može biti jednostavno. Velike programe je teško testirati. Moguće otklanjanje grešaka u fazi rada.

Možemo navesti primjere grešaka u softverskim kompleksima koje su nastale tokom razvoja, a nisu otkrivene tokom testiranja.

U "Microsoft Works Reference" u online pomoći paketa za integriranu obradu informacija Works 2.0, funkcija IF je opisana kao

IF (Uvjet, ValueFalse, ValueTrue).

Međutim, u stvarnosti, rad ove funkcije trebao bi biti sljedeći: IF (Uslov, ValueTrue, ValueFalse). Works 3.0 Microsoft Works korisnički vodič za Windows rješava ovaj problem.

Neuspjeh lansiranja prvog američkog satelita na Veneru dogodio se, najvjerovatnije, zbog programske greške - umjesto traženog perioda u operateru, programer je stavio zarez. Fortran operator je napisan

Uradite 50 i = 12,525

U stvari, trebalo je da izgleda ovako:

Uradite 50 i = 12,525

Komplikacije koje su nastale prilikom povratka sovjetsko-avganistanske i sovjetsko-francuske posade na Zemlju uzrokovane su greškama u softveru kompjutera na brodu.

Godine 1983. dogodila se poplava na jugozapadu Sjedinjenih Država. Razlog je taj što su u kompjuter uneseni netačni vremenski podaci, zbog čega je dao pogrešan signal na kapije koje blokiraju rijeku Kolorado.

Kako bi se spriječilo da korisnici dođu u situaciju da program radi, ali ne radi ono što bi trebao raditi, provodi se testiranje kako bi se identifikovale „skrivene“ greške. Testiranje koristi planove i podatke koji su već razvijeni u fazi projektovanja. O testiranju je potrebno razmišljati tokom čitavog perioda razvoja programa (Tabela 2).

tabela 2

Vrste i uzroci grešaka

Vrsta greške	Razlog greške
Netačna izjava problema	Netačno formulisan problem
Nevažeći algoritam	Odabire se algoritam koji dovodi do netočnog ili neefikasnog rješenja problema
Semantička greška	Semantička greška u programu, koja nije povezana sa kršenjem sintakse. Na primjer, varijable su pogrešno definirane, ulazni podaci nisu u skladu s graničnim vrijednostima navedenim u algoritmu, nepravilno napisan operator programskog jezika se koristi pogrešno, itd. Greške ovog tipa se otkrivaju tokom testiranja i otklanjanja grešaka. faza
Sintaktičke greške (greške u vrijeme kompajliranja)	Greške u programiranju koje krše gramatičke strukture jezika. Greške ove vrste detektuje prevodilac.
Runtime errors	Greške koje se javljaju tokom izvršavanja programa. Pravi se razlika između I/O grešaka (na primjer, datoteka nije pronađena, nema dovoljno memorije za pokretanje programa, itd.) i fatalnih grešaka koje dovode do trenutnog prekida programa (na primjer, podjela za nulu, greške pri provjeravanju granica, prelivanje pri izvođenju operacija s pomičnim zarezom itd.)
Greške u podacima	Loše određivanje mogućeg opsega promjene ulaznih podataka
Greške u dokumentima	Korisnička dokumentacija ne odgovara trenutnoj verziji programa

U procesu izvođenja svih navedenih faza akumulira se određeno iskustvo koje će dati osnovu za unapređenje programa.

Faza "Radni nacrt" završava se preliminarnim državnim, međuresornim, prijemnim i drugim vrstama ispitivanja. Dokumentacija softvera se koriguje u skladu sa rezultatima testiranja.

Implementacija

Implementacija je faza životnog ciklusa programa u kojoj se program i programska dokumentacija prenose do kupca. Tokom rada može biti potrebno dodati nove funkcije softverskom paketu, eliminisati greške pronađene tokom rada itd. Ova vrsta posla se zove podrška.

Primjer dodavanja novih funkcija softverskom paketu je uređivač teksta Lexicon 1.3. Ova verzija je dobijena iz procesora teksta 1.2 uključivanjem funkcija - uvoz grafičkih datoteka u PCX formatu u tekstualne datoteke.

Dokumentacija

Na sl. 15 pravougaonik koji predstavlja svaku fazu razvoja programa povezan je sa pravougaonikom „Dokument“. U ovom slučaju, strelice su usmjerene u oba smjera. Ideje i rješenja korištena u svakoj fazi utječu na dokumentaciju koja prati fazu, baš kao što dokumentacija utječe na ideje i rješenja.

Razvoj dokumentacije počinje odmah od početka razvoja softvera. Dokumentacija je klasifikovana prema namjeni i može se podijeliti u nekoliko grupa, najmanje u dvije grupe. Prva grupa dokumenata namijenjena je programerima i stručnjacima koji će je održavati, a druga - korisnicima softvera.

Prva grupa kao glavni dokumenti obuhvataju zadatak za izradu softvera (tehnički zadatak), specifikaciju i opis programa.

Projektni zadatak treba da sadrži sljedeće dijelove:

Uvod;

Osnova za razvoj;

Svrha razvoja;

Zahtjevi za program i softverski proizvod;

Zahtjevi za softversku dokumentaciju;

Tehnički i ekonomski pokazatelji;

Faze i faze razvoja;

Procedura kontrole i prihvatanja.

Dozvoljeno je uključivanje priloga u projektni zadatak, gdje se, po potrebi, navodi lista istraživačkih i drugih radova koji opravdavaju razvoj, algoritamski dijagrami i drugi dokumenti koji se mogu koristiti u izradi.

Specifikacija je glavni programski dokument i sastavljena je u skladu sa GOST-om. Specifikacija je tabela koja se sastoji od kolona: “Designation”, “Name”, “Note”. U koloni “Oznaka” upisuju se oznake navedenih dokumenata i programa. U koloni "Dokumentacija" navedite naziv i vrstu dokumenta ili programa. U koloni "Napomena" - dodatne informacije vezane za programe snimljene u specifikaciji.

Opis programa sadrži:

- komentarisani izvorni tekstovi (listing) programskih modula i upravljačkog modula;

- šema podjele softverskog kompleksa na softverske module;

- dijagram toka podataka programskog paketa;

- šema interakcije softverskih modula;

- planovi i podaci za testiranje softverskog paketa;

- drugi materijali koji ilustriraju projekat, na primjer, dijagrami algoritama.

Druga vrsta dokumenata sadrži informacije potrebne za rad sa softverskim paketom. Ovi dokumenti se mogu izdati u štampanom obliku i (ili) „ugraditi“ u softverski paket.

Disciplina programiranja je važan faktor u uspjehu razvoja softvera. Principi programiranja u posljednjem poglavlju primjenjuju se na proceduralne programske jezike i objektno orijentirane jezike.

Verzija 6.0 Turbo Pascal-a, objavljena 1990. godine, jasno je demonstrirala prednosti objektno orijentirane tehnologije programiranja. Paket isporuke nove verzije uključuje Turbo Vision biblioteku, na kojoj su hiljade programera savladale principe OOP-a. Za kratko vrijeme pojavilo se mnogo komercijalnih programa baziranih na Turbo Visionu. Ova biblioteka zaista revolucionira proces interaktivnog razvoja softvera, minimizirajući vrijeme isporuke i isporučujući softver najvišeg kvaliteta.

Evolucija tehničkih sredstava personalnih računara dovela je do široko rasprostranjene zamene dobrog starog MS – DOS OS-a mnogo moćnijim Windows sistemima, za koje je programiranje mnogo komplikovanije od programiranja za MS – DOS. Izdavanjem Borland Pascal-a sa objektima, Borland je programerima pružio visoko efikasne alate za razvoj i otklanjanje grešaka dizajniranih da rade pod Windows operativnim sistemom. Ali ipak, prije nekoliko godina, običan programer je mogao samo sanjati o stvaranju vlastitih programa za Windows.

Formulacija problema. Kreiranje bilo kog programa počinje navođenjem problema. Zadatak se u početku formuliše u terminima predmetne oblasti, a potrebno ga je prevesti

Rice. 26.1.

to u jezik koncepata koji je bliži programiranju. Budući da je programer rijetko dobro upućen u predmetnu oblast, a kupac je u programiranju (jednostavan primjer: potrebno je da napišete računovodstveni program), postavljanje problema može postati vrlo težak iterativni proces. Osim toga, prilikom postavljanja zadatka, kupac često ne može jasno i u potpunosti formulirati svoje zahtjeve i kriterije.

Ova faza također određuje okruženje u kojem će se program izvoditi: hardverski zahtjevi, korišteni OS i drugi softver.

Izjava o problemu završava se stvaranjem tehničke specifikacije, i onda eksterna specifikacija programa, koji uključuje:

■ opis ulaznih podataka i rezultata (vrste, formati, tačnost, način prenosa, ograničenja);

■ opis zadatka koji se izvršava programom;

■ način pristupa programu;

■ opis mogućih hitnih situacija i grešaka korisnika.

Dakle, program se posmatra kao "crna kutija" za koju se definiraju funkcija i ulazni i izlazni podaci.

Izbor modela i metode za rješavanje problema. U ovoj fazi se analiziraju uslovi problema i na osnovu toga se gradi model problema i utvrđuje opšti metod za njegovo rešavanje. Prilikom konstruisanja modela izdvajaju se karakteristike problema koje su značajne sa stanovišta razmatranja, tj. vrši se njegova apstrakcija. Ove karakteristike treba prikazati u modelu sa potrebnom potpunošću i tačnošću. Drugim riječima, u ovoj fazi se formalizira formulacija problema i na osnovu toga se utvrđuje opći način njegovog rješavanja. U prisustvu nekoliko metoda, najbolja se bira na osnovu kriterijuma složenosti, efikasnosti, tačnosti, u zavisnosti od specifičnih zadataka sa kojima se programer suočava.

Razvoj internih struktura podataka. Većina algoritama zavisi od toga kako su podaci organizovani, tako da je intuitivno jasno da treba započeti dizajn programa ne sa algoritmima, već sa razvojem struktura neophodnih za predstavljanje ulaznih, izlaznih i međupodataka. U ovom slučaju se uzimaju u obzir mnogi faktori, na primjer, ograničenja veličine podataka, potrebna tačnost, zahtjevi za izvođenje programa. Strukture podataka mogu biti statične ili dinamičke.

Kada odlučujete kako će podaci biti organizirani u programu, korisno je postaviti sebi sljedeća pitanja.

■ Koliko je tačna prezentacija potrebnih podataka?

■ Koji raspon su vrijednosti podataka?

■ Da li je maksimalna količina podataka ograničena?

■ Da li ih je potrebno istovremeno pohraniti u program?

■ Koje radnje trebate poduzeti u vezi s podacima?

Na primjer, ako je maksimalna količina podataka istog tipa koju treba obraditi poznata i mala, najlakši način je kreiranje statičkog niza za njihovo pohranjivanje. Ako postoji mnogo takvih nizova, segmenti podataka i steka možda neće biti dovoljni i morat ćete dodijeliti prostor za ove nizove u hrpi.

Ako je maksimalna količina podataka nepoznata i stalno se mijenja dok je program pokrenut, tada se za njihovo pohranjivanje koriste dinamičke strukture. Izbor tipa strukture ovisi o potrebnim operacijama podataka. Na primjer, binarno stablo je najpogodnije za brzo pronalaženje stavki, a ako se podaci trebaju obraditi po redoslijedu dolaska, koristi se red čekanja.

Dizajn. Ispod dizajn programa razume se definicija opšte strukture i interakcije modula.

Ovaj korak se primjenjuje tehnologija dizajna odozgo prema dolje, glavna ideja o kojoj je gore razmotreno. U ovom slučaju koristi se metoda detaljne obrade korak po korak.

Ovaj proces možete zamisliti na način da se prvo program napiše na jeziku neke hipotetičke mašine, koja je u stanju da razume najopćenitije akcije, a zatim se svaka od njih opisuje na nižem nivou apstrakcije, itd. U ovoj fazi je veoma važno specifikacija interfejsa, one. određivanje načina interakcije podzadataka.

Za svaki podproblem izrađuje se eksterna specifikacija, slična onoj ranije datoj. U istoj fazi rješavaju se pitanja podjele programa na module, a glavni kriterij u ovom slučaju je minimiziranje njihove interakcije. Jedan zadatak se može implementirati pomoću više modula, i obrnuto, više zadataka se može riješiti u jednom modulu. Oni prelaze na niži nivo projektovanja tek nakon završetka projektovanja gornjeg nivoa. Algoritmi se pišu u generaliziranom obliku, na primjer verbalno, u obliku generaliziranih dijagrama toka ili na druge načine.

PAŽNJA

Faza dizajna treba da razmotri mogućnost budućih modifikacija programa i da teži da se program dizajnira na način da promene budu što je moguće lakše.

Budući da se ne zna koje promjene će se morati napraviti, ova želja podsjeća na stvaranje „opšte teorije svega“; u praksi, neophodno je da se ograničimo na razumne kompromise. Programer, na osnovu svog iskustva i zdravog razuma, odlučuje koja svojstva programa će možda trebati promijeniti ili poboljšati u budućnosti.

Proces dizajna je iterativan, jer je u programima realne veličine nemoguće promisliti kroz sve detalje prvi put.

Strukturirano programiranje. Programiranje se ovdje razmatra "u užem smislu", tj. Podrazumijeva se pisanje programa u programskom jeziku prema gotovom algoritmu. Ovaj proces se često naziva kodiranje da se razlikuje od punog ciklusa razvoja programa.

Kodiranje je također organizirano prema principu "odozgo prema dolje": prvo se kodiraju moduli najvišeg nivoa i kompajliraju se testni slučajevi za njihovo otklanjanje grešaka. Istovremeno, na mjesto modula sljedećeg nivoa koji još nisu napisani, postavljaju se stubovi, koji u najjednostavnijem slučaju jednostavno izdaju poruku da im je kontrola prenijeta, a zatim je vraćaju modulu za pozivanje. U drugim slučajevima, stub može vratiti unaprijed definirane ili pojednostavljene vrijednosti.

Tako se prvo kreira logički kostur programa, koji zatim postaje obrastao u meso koda. Činilo bi se logičnijim primijeniti tehnologiju odozdo prema gore na proces programiranja: prvo napisati i otkloniti greške u modulima nižeg nivoa, a zatim ih kombinirati u veće fragmente, ali ovaj pristup ima nekoliko nedostataka.

Prvo, u procesu kodiranja gornjeg nivoa mogu se otkriti određene poteškoće u dizajniranju nižih nivoa programa (jednostavno zato što se pri pisanju programa njegova logika promišlja pažljivije nego pri dizajniranju). Ako se takva greška otkrije posljednja, potrebni su dodatni troškovi za preradu gotovih modula nižeg nivoa.

Drugo, da biste otklonili greške svakog modula, a zatim i većih fragmenata programa, svaki put morate sastaviti svoje testne slučajeve, a programer je često primoran da imitira okruženje u kojem bi modul trebao raditi. Tehnologija programiranja odozgo prema dolje pruža prirodan redoslijed kreiranja testova — mogućnost otklanjanja grešaka odozgo prema dolje, o čemu se govori u nastavku.

Faze dizajna i programiranja su kombinovane u vremenu: idealno, najprije se dizajnira i kodira najviši nivo, zatim sljedeći itd. Ova strategija se koristi jer smanjuje cijenu greške, jer će možda biti potrebno izvršiti promjene tokom procesa kodiranja koje utiču na module nižeg nivoa.

Testiranje odozgo prema dolje. Ova faza se evidentira posljednja, ali to ne znači da testiranje ne treba provoditi u prethodnim fazama. I dizajn i programiranje moraju biti popraćeni pisanjem test paket – validacijski ulazni podaci i odgovarajući skupovi referentnih reakcija.

Potrebno je razlikovati procese testiranja i otklanjanja grešaka u programu. Testiranje To je proces kojim se provjerava ispravnost programa. Testiranje je pozitivne prirode, njegova svrha je da pokaže da program radi ispravno i da ispunjava sve specifikacije dizajna. Otklanjanje grešaka- proces ispravljanja grešaka u programu, u kojem nije postavljen cilj ispravljanja svih grešaka. Ispravlja greške pronađene tokom testiranja. Prilikom planiranja treba imati na umu da proces detekcije greške poštuje zakon zasićenja, tj. većina grešaka se pronađe u ranim fazama testiranja, a što je manje grešaka u programu, to je duže potrebno da se traži svaka od njih.

Postoje dvije strategije testiranja: crna kutija i bijela kutija. Prilikom korištenja prvog, interna struktura programa se ne uzima u obzir i testovi su dizajnirani tako da se u potpunosti provjeri funkcioniranje programa na ispravne i netačne ulazne utjecaje.

Strategija "bijele kutije" uključuje testiranje svih grana algoritma. Ukupan broj grana je određen kombinacijom svih alternativa u svakoj fazi. Ovo je konačan broj, ali može biti vrlo velik, pa se program dijeli na fragmente, nakon iscrpnog testiranja kojih se smatraju elementarnim čvorovima dužih grana. Pored podataka koji osiguravaju izvršenje naredbi u traženom nizu, testovi moraju sadržavati provjera graničnog stanja(na primjer, prijelaz po uvjetu NS> 10 treba provjeriti za vrijednosti veće od, manje od i jednake 10). Reakcija programa na pogrešni početni podaci.

Nedostatak Strategija "bijele kutije" je da je nemoguće otkriti granu koja nedostaje uz pomoć nje, a strategija "crne kutije" zahtijeva veliki broj varijanti ulaznih radnji, stoga se u praksi koristi kombinacija koristi se obje strategije.

PAŽNJA

Ideja testiranja odozgo prema dolje pretpostavlja da testiranje programa počinje prije nego što je njegov dizajn završen. Ovo vam omogućava da ranije isprobate glavna intermodulska sučelja i da se uvjerite da program u osnovi ispunjava zahtjeve korisnika. Tek nakon što je logičko jezgro testirano toliko da postoji povjerenje u ispravnost implementacije glavnih sučelja, počinju kodiranje i testiranje sljedećeg nivoa programa.

Naravno, potpuno testiranje programa dok je predstavljen u obliku skeleta je nemoguće, međutim dodavanje svakog sljedećeg nivoa omogućava vam da postepeno proširite područje testiranja.

Složena faza otklanjanja grešaka na nivou sistema kod dizajna odozgo prema dolje oduzima manje vremena od dizajna odozdo prema gore i donosi manje iznenađenja jer je šansa da ozbiljne greške utiču na većinu sistema mnogo manja. Osim toga, za svaki modul povezan sa sistemom, njegovo okruženje je već kreirano, a izlaz debagovanih modula može se koristiti kao ulaz za testiranje drugih, što olakšava proces testiranja. To ne znači da modul mora biti povezan na sistem potpuno "sirov"; ponekad je zgodno dio testiranja provesti autonomno, jer je teško generirati na ulazu sistema sve opcije potrebne za testiranje posebnog modula.

Model čistog vodopada koristi se samo za jednostavne programe, jer je teško unaprijed predvidjeti sve detalje implementacije. Šema sa srednjom kontrolom je realističnija (sl. 26.2). Kontrola koja se provodi nakon svake faze omogućava, ako je potrebno, povratak na bilo koji viši nivo i uvođenje potrebnih promjena.

Glavna opasnost korištenja takve sheme povezana je s činjenicom da razvoj nikada neće biti dovršen, jer je stalno u stanju usavršavanja i poboljšanja.

Rice. 26.2.

• Tipovi i formati ne znače tipove programskog jezika.