Faze razvoja programa. Pripremna faza razvoja softvera

upravljanje softverom

Softverski proces sastoji se od mnogih različitih aktivnosti, metoda, tehnika i koraka koji se koriste za razvoj i razvoj softvera i srodnih proizvoda (planovi dizajna, dokumentacija, kod, testovi, korisnička dokumentacija).

Međutim, danas ne postoji univerzalni proces razvoja softvera - skup tehnika, pravila i propisa koji su prikladni za softver bilo koje vrste, za bilo koju tvrtku, za timove bilo koje nacionalnosti. Svaki trenutni razvojni proces koji provodi određeni tim u okviru određenog projekta ima veliki broj karakteristika i individualnosti. No, prije pokretanja projekta poželjno je isplanirati radni proces, definirati uloge i odgovornosti u timu, produkte rada (prelazne i završne), redoslijed sudjelovanja članova tima u njihovom razvoju i sl.

Proces izrade softvera nije ujednačen. Ova ili ona metoda razvoja softvera, u pravilu, određuje neku dinamiku implementacije određenih vrsta aktivnosti, odnosno određuje model procesa.

Model je dobra apstrakcija različitih metoda razvoja softvera, omogućujući da se one prikažu koncizno, koncizno i ​​informativno. Međutim, sama ideja o modelu procesa jedna je od najranijih u programskom inženjerstvu, kada se vjerovalo da je uspješan model najvažnija stvar koja pridonosi uspjehu razvoja. Kasnije se shvatilo da postoje mnogi drugi aspekti (npr. principi upravljanja i razvoja, struktura tima) koje je potrebno definirati u skladu jedan s drugim. I počele su se razvijati metodologije integriranog razvoja. Međutim, postoji nekoliko klasičnih modela procesa razvoja softvera.

Prvi model koji je postao široko poznat i koji je istinski strukturirao razvojni proces je kaskada ili vodopad. Nastao je nakon NATO-ove konferencije o znanosti i tehnologiji 1968., na kojoj su se razmatrala slična pitanja, a proces stvaranja softverskog proizvoda dijeli na uzastopne faze (treba napomenuti da su ga već koristili razni programeri, ali ni broj ni sadržaj etapa objedinjen).

Slika 1 - Modificirani vodopadni model razvoja softvera

Modificirani kaskadni model predvidio je mogućnost povratka na prethodne stupnjeve.

Kratko vrijeme nakon rođenja, kaskadni model modificirao je Winst Royce, uzimajući u obzir međuovisnost stupnjeva i potrebu vraćanja na prethodne stupnjeve, što može biti uzrokovano, na primjer, nepotpunim zahtjevima ili pogreškama u formiranju zadatak. U ovom “reverzibilnom” obliku, kaskadni model je postojao dugo vremena i bio je osnova za mnoge projekte (Slika 1).

Međutim, praktična primjena ovog modela otkrila je mnoge njegove nedostatke, od kojih je glavni taj što je prikladniji za tradicionalne vrste inženjerskih aktivnosti nego za razvoj softvera. Konkretno, jedan od najvećih problema pokazala se njegova “sklonost” mogućim nedosljednostima između dobivenog proizvoda i zahtjeva koji su pred njega postavljeni. Glavni razlog za to je što se potpuno oblikovani proizvod pojavljuje tek u kasnijim fazama razvoja, ali budući da su rad u različitim fazama obično izvodili različiti stručnjaci i projekt se prenosio iz jedne skupine u drugu, tada, prema načelu pokvarenog telefona, ispostavilo se da izlaz nije baš ono što se u početku očekivalo.

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

Slika 2 - Model razvoja softvera u obliku slova V

Model u obliku slova V omogućuje puno bolju kontrolu nad ishodom kako bi se osiguralo da ispunjava očekivanja jer je usredotočen na testiranje.

Model u obliku slova V omogućio je značajno poboljšanje kvalitete softvera zbog njegove usmjerenosti na testiranje, a također je uvelike riješio problem usklađenosti stvorenog proizvoda s postavljenim zahtjevima zahvaljujući postupcima verifikacije i certificiranja u ranim fazama razvoj (isprekidane linije na slici označavaju ovisnost o zadacima faza planiranja/proizvodnje i testiranja/prihvaćanja).

Međutim, općenito, model u obliku slova V samo je modifikacija kaskadnog modela 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), tada dobiveni proizvod može zapravo biti nepotreban kupcu, jer su se njegove potrebe značajno promijenile.

Softver se, za razliku od, primjerice, mikrosklopa, može pustiti u rad u dijelovima, što znači da se može razvijati i isporučivati ​​kupcu postupno. Upravo na tome se temelji inkrementalni model, koji uključuje fragmentaciju proizvoda na relativno neovisne komponente, koje se zasebno razvijaju i stavljaju u pogon.

Ovaj model je koristan i za kupca i za kreatora sustava, budući da vam omogućuje da idete naprijed poštujući interese obiju strana.

Međutim, ima i svojih nedostataka. Podjela na funkcionalne blokove općenito usporava proces, jer postaje potrebno osigurati njihovu interakciju. Za mnoga rješenja ova metoda nije primjenjiva jer je iz njih nemoguće izolirati pojedinačne komponente koje se mogu samostalno napajati i funkcionirati. Opterećenje upravljačkog osoblja također se značajno povećava zbog kompliciranja poslova koordinacije rada na pojedinim komponentama sustava, a povećavaju se i troškovi izmjene gotovih komponenti koje su već instalirane i rade s kupcem.

Predložen od strane Barryja Boehma 1988. godine, spiralni model bio je značajan napredak u razumijevanju prirode razvoja softvera, iako kombinira vodopadni pristup i iterativni proces dizajna temeljen na izradi prototipova (Slika 3).

Riža. 3.

Boehmov spiralni model usredotočen je na dizajn, razvoj softvera događa se tek na zadnjem zavoju spirale prema uobičajenom modelu vodopada, ali tome prethodi nekoliko iteracija dizajna temeljenih na izradi prototipa - pri čemu svaka iteracija uključuje fazu identificiranja i analize rizika i najteže probleme.

Budući da spiralni model uglavnom pokriva dizajn, u svom izvornom obliku nije bio široko korišten kao metoda za upravljanje cijelim životnim ciklusom razvoja softvera. No, njegova glavna ideja, da se proces rada na projektu može sastojati od ciklusa koji prolaze kroz iste faze, poslužila je kao polazište za daljnja istraživanja i postala temelj većine modernih modela procesa razvoja softvera.

Prvi put predložen od strane Philippea Crutchena 1995., iterativni model kombinira glavne prednosti spiralnih, inkrementalnih, vodopada, prototipa i objektno orijentiranih 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 životnog ciklusa razvoja softvera (pokretanje, istraživanje, izgradnja i implementacija). U svakoj fazi projekt prolazi kroz mnogo ponavljanja, što dovodi do stvaranja izvedivih verzija: u početnim fazama stvaraju se prototipovi, razjašnjavaju se zahtjevi i razrađuju se najsloženiji problemi; završni dovode do stvaranja proizvoda, njegovog poboljšanja i proširenja funkcionalnosti.

Iterativni model, osim glavnih faza, razlikuje još dvije skupine procesa: radne (upravljanje zahtjevima, analiza i dizajn, implementacija, testiranje, implementacija) i pomoćne (upravljanje konfiguracijom i promjenama, projektom i procesom). Broj i suština procesa variraju ovisno o potrebama programera, mogu imati i svoje cikluse, koji čak i ne moraju nužno odgovarati glavnim fazama. Međutim, tijek rada uvijek rezultira stvaranjem verzija proizvoda.

Iterativni model, poput spiralnog modela, omogućuje uspješno suočavanje s rizicima. Ako se tijekom rada na sljedećoj verziji utvrdi da su troškovi rada za implementaciju potrebne funkcionalnosti previsoki, tada se prekoračenja proračuna i propušteni rokovi mogu izbjeći usklađivanjem razvojnih prioriteta i troškova rada na početku svake iteracije. Stoga je ovaj model vrlo prikladan za većinu tipova softverskih projekata, no njegove su prednosti posebno uočljive u radu na proizvodima namijenjenim slobodnom tržištu, zbog početnog fokusa na izdavanje sekvencijalnih verzija.

Najpoznatijim i najmjerodavnijim standardom kvalitete treba smatrati Capability Maturity Model (CMM) - model za procjenu razine zrelosti razvojnih procesa zajedno sa svojim derivatima. Kreirao ga je SEI (Software Engineering Institute), koji financira Ministarstvo obrane SAD-a i strukturna je jedinica Sveučilišta Carnegie Mellon. Prva službena verzija standarda objavljena je 1993. godine, iako je rad na njemu započeo mnogo ranije - njegove glavne odredbe objavljene su još 1986. godine. Uspjeh CMM-a određen je nekoliko čimbenika. Ovaj je standard bio jedan od prvih koji je u početku uzeo u obzir specifičnosti stvaranja softvera. Pokazalo se da je prilično jednostavan i transparentan i za razumijevanje i za korištenje, te je regulirao "što", a ne "kako" raditi, te je stoga bio prikladan za različite modele životnog ciklusa, razvojne metodologije i nije nametnuo nikakva ograničenja standardima dokumentacije , alati, okruženje i jezici koji se koriste u projektima. I, možda, glavni čimbenik koji je unaprijed odredio popularnost CMM-a bila je suradnja SEI-a s američkim Ministarstvom obrane, što je de facto značilo korištenje standarda pri provedbi projekata koje je naručio ovaj odjel.

CMM model (Tablica 1) pruža pet razina zrelosti, od kojih svaka odgovara određenim ključnim procesnim područjima (Key Process Areas, KPA).

Tablica 1-HMM model

Naziv razine	Ključna procesna područja
1 - Početnik	Ako je organizacija na ovoj razini, onda za nju ne postoje ključna procesna područja
2 - Ponavljajuće	Upravljanje konfiguracijom softvera. Osiguravanje kvalitete programskih proizvoda. Upravljanje ugovorima izvođača. Praćenje napretka projekata. Planiranje softverskih projekata. Upravljanje zahtjevima
3 - Definirano	Stručne procjene. Koordinacija interakcija između projektnih timova. Inženjering softverskih proizvoda. Sveobuhvatno upravljanje softverom. Program obuke osoblja. Definicija organizacijskog procesa. Opseg organizacijskog procesa
4 - Upravljano	Upravljanje kvalitetom softvera. Upravljanje procesima temeljeno na kvantitativnim metodama
5 - Mogućnost optimizacije	Upravljanje promjenama procesa. Upravljanje tehnološkim promjenama. Prevencija kvarova

Podjela na razine i definiranje KPA za svaku omogućuje dosljednu implementaciju CMM-a, koristeći standard kao vodič koji može osigurati kontinuirano poboljšanje razvojnog procesa.

CMM standard se pokazao vrlo uspješnim, a potom je na njegovoj osnovi stvoren cijeli niz standarda, a dobio je novo ime - SW-CMM (Capability Maturity Model for Software), točnije odražavajući njegovu poziciju u prilično velikom obitelj standarda.

Međutim, praktična primjena standarda serije CMM pokazala je da oni ne daju bezuvjetan uspjeh u razvoju softvera. Ovi standardi nisu bili dobro usklađeni jedni s drugima - istodobna implementacija različitih modifikacija CMM-a mogla bi biti prilično složen zadatak i dovela je do zbunjenosti stručnjaka organizacija koje su se s njim susrele.

Također, značajan problem CMM-a je potreba za „usklađivanjem“ svih procesa. Ako organizacija želi biti certificirana za određenu razinu, tada mora osigurati da su svi njezini procesi na odgovarajućoj razini. Čak i ako specifičnosti, metodologija ili značajke razvoja ne dopuštaju implementaciju određenih procesa, certifikacija to zahtijeva.

Drugi problem proizlazi iz pozicije koju su CMM standardi zauzeli u modernoj softverskoj industriji. Budući da se od organizacije koja postiže visoku razinu CMM-a očekuje bolja izvedba softverskih proizvoda od onih certificiranih na nižim razinama, standard se počeo koristiti kao kriterij odabira za natječaje za razvoj softvera ili projekte eksternalizacije.

Ova situacija je bila moguća zbog nedostataka u procesu certifikacije. Certificiranju ne podliježe cijela organizacija kao cjelina, već samo određeni projekt. Ne postoji ništa što bi spriječilo organizaciju da stvori "model" projekta koji zadovoljava sve zahtjeve visokih razina CMM standarda, dobije odgovarajuću razinu certifikacije i izjavi da svi proizvodi zadovoljavaju tu razinu standarda.

Novi SEI standard - Capability Maturity Model Integrated (CMMI) - integrirani model za procjenu razine zrelosti razvojnih procesa dizajniran je za rješavanje većine problema CMM-a. Standard CMMI izvorno je stvoren na takav način da kombinira postojeće CMM opcije i eliminira sve kontradikcije u njegovoj praktičnoj primjeni u različitim područjima djelovanja visokotehnoloških tvrtki.

Kako bi eliminirao potrebu za "usklađivanjem" procesa organizacije i bio više prilagođen njezinim poslovnim potrebama, a ne obrnuto, CMMI standard ima dva oblika prezentacije - klasični, višerazinski, koji odgovara CMM-u, i novi , kontinuirano. Kontinuirani oblik prezentacije ne uzima u obzir razine zrelosti, već razine sposobnosti, koje se ocjenjuju za pojedina područja procesa (PA).

Tablica 2 prikazuje usklađivanje standardnih razina zrelosti CMM-a, kao i razine zrelosti CMMI slojevitog prikaza i razine sposobnosti CMMI kontinuiranog prikaza.

Tablica 2 - Sukladnost s razinama zrelosti standarda CMM i CMMI

SEI se udaljava od CMM-a i umjesto toga aktivno promiče CMMI, obećavajući da će pooštriti kontrolu nad procesom certifikacije, smanjiti troškove i učiniti ga privlačnijim za manje organizacije; osiguravanje kompatibilnosti s ISO standardima.

U modernim uvjetima posjedovanje certifikata određene razine CMM/CMMI nije tako značajan čimbenik kao prije nekoliko godina i prihvaća se bez dodatnih pitanja, osim u projektima koji se izvode prema državnim narudžbama.

Norma ISO/IEC 15504 namijenjena je ocjeni procesa razvoja informacijskih sustava, posebno softvera. Osmišljen je od samog početka kako bi uvelike zadovoljio industrijske standarde za procjenu procesa stvaranja softvera. Upravo je taj zahtjev odredio sličnost standarda s osnovnim načelima CMM/CMMI.

Model zrelosti razvoja softvera (CMM), koji je razvio Institut za softversko inženjerstvo na Sveučilištu Carnegie Mellon, predlaže pet razina zrelosti (tablica 3). Pomaže organizacijama da povećaju zrelost svojih procesa razvoja softvera i organizacije mogu biti ocijenjene i akreditirane prema tim razinama.

Tablica 3 - Razine zrelosti razvoja softvera

Razina 1 - ulazna razina	Proces razvoja softvera je spontan, a samo je nekoliko procesa regulirano. Uspjeh razvoja može ovisiti o pojedinim zaposlenicima.
Razina 2 - razina ponovljivosti	Stvoreni osnovni procesi upravljanja projektima za praćenje troškova, rasporeda i funkcionalnosti.
Razina 3 - razina regulacije	Proces razvoja softvera je dokumentiran, standardiziran i integriran sa standardnim procesom razvoja softvera organizacije za aktivnosti upravljanja i razvoja. Svi projekti koriste standardizirani proces.
Razina 4 - razina upravljivosti	Prikupljaju se detaljni pokazatelji procesa razvoja softvera i kvalitete proizvoda, što vam omogućuje razumijevanje i upravljanje procesom i proizvodima.
Razina 5 - razina optimizabilnosti	Kontinuirana optimizacija procesa osigurana je kvantitativnim povratnim informacijama iz procesa i pilot inovativnih ideja i tehnologija.

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

Prije nego ponudim pregled razvojnog procesa koji se razvijao tijekom godina, želio bih dati nekoliko općih pojašnjenja za koja mislim da su relevantna.

U informatici se bavim zadnjih 15 godina, iako sam se s programiranjem počeo baviti puno ranije. Glavni fokus mog djelovanja kao sistemskog arhitekta bio je organizacija razvoja programa, razvoj koncepata i arhitekture najviše razine te praćenje implementacije koncepta kroz projekt. Osim upravljanja razvojem softvera i izrade arhitekture, s vremena na vrijeme bavim se rješavanjem složenih tehničkih problema i pisanjem nekih kritičnih dijelova koda, gdje je potrebno ne samo poznavanje jezika i samog razvojnog okruženja, već i njihove interne organizacije, što ponekad predstavlja neugodna iznenađenja.

Projekti na kojima radim najčešće uključuju razvoj prilagođenog ili investicijskog softvera. Također sam morao raditi s ugrađenim softverom i programima usmjerenim na izdavanje "hitova" (koje, uz laganu ruku Joela Spolskog, sada nazivam softverom za igre, iako su zapravo neki projekti igara bliži investicijskim projektima).

Prilagođeni softver može biti namijenjen internom ili eksternom kupcu. Naručitelj dobiva ekskluzivna prava na izrađeni sustav, a rad na razvoju sustava može naknadno prenijeti na drugog izvođača.

Za razliku od softvera po narudžbi, radove na investicijskom softveru izvodi sam izvođač novcem internog ili eksternog investitora. Prava na sistemski kod u pravilu ostaju izvođaču, što potiče kontinuirani rad na poboljšanju proizvoda i dosljedno izdavanje verzija s naprednijim funkcionalnostima.

Firmware se isporučuje zajedno s hardverom i, grubo rečeno, ne podliježe održavanju, budući da je povlačenje serije uređaja od strane proizvođača vrlo skupa i stoga iznimna stvar.

Razvoj hitova igre također ne sadrži gotovo nikakvu fazu održavanja. Osim toga, korisnici gaming programa, čak i kada se suoče s greškom u igrici, vrlo rijetko preuzimaju ažuriranu verziju. Stoga razvoj igre u pravilu ima svoju ekonomiju i svoj razvojni proces.

Naši kupci su vladine agencije, velike državne i komercijalne organizacije i, naravno, mi sami. Stoga, u smislu prilagođenog softvera, često postoji razlika u našem procesu između razvoja proizvoda za interne i eksterne kupce. U ovom ću članku navesti neke nijanse. Razina formalizacije odnosa s kupcem uvelike varira od projekta do projekta. Općenito, što je veći proračun projekta, veća je formalnost. Državni kupac ili velika komercijalna poduzeća (osobito ona s državnim sudjelovanjem) obično imaju zakonska ograničenja na formiranje, postavljanje narudžbe i prihvaćanje rezultata rada. Još jedno ograničenje velikih organizacija je činjenica da njihovo osoblje, koje je izvor zahtjeva i glavni korisnik naših sustava, ima vrlo ograničenu dostupnost za izvođače, makar samo zbog svoje zauzetosti. Međutim, za male organizacije razina formalizacije opada i ponekad ide u suprotnu krajnost, gdje postoji nedovoljna razina odgovornosti korisnika unutar projekta.

Druga strana naših projekata po narudžbi su visoki zahtjevi za funkcionalnošću. To uključuje veliko opterećenje svih sustava, veliku geografsku distribuciju i visoke zahtjeve za točnost izračuna unutar vrlo ograničenog vremenskog okvira. Često se u našim projektima pojavljuju elementi istraživačkog rada i kreativnog traženja usmjerenog na rješavanje netrivijalnih dizajnerskih problema. Ponekad moramo kombinirati različite metodologije unutar jednog razvojnog procesa, na primjer, umetanje jedne ili više faza gotovo čistog Scruma u zajednički proces blizak RUP-u, stvarajući nešto poput projekta unutar projekta. To nam omogućuje održavanje niske razine uključenosti korisnika zbog prirode projekta, uz razvojnu fleksibilnost u uvjetima visoke neizvjesnosti zahtjeva. U tom smislu, za mene je važna pripremna faza tijekom koje možete odabrati potrebnu metodologiju i izgraditi optimalan proces razvoja. Opisao sam jedan primjer upotrebe fleksibilne metodologije u članku "Korištenje agilnosti pri razvoju projekta za državnog korisnika."

Kao primjer rada na investicijskom projektu mogu navesti razvoj cjelovitog sigurnosnog sustava koji smo kreirali kao “boxed” proizvod. Pod mojim vodstvom dosljedno su objavljene četiri verzije ovog sustava, čiji su korisnici bili razne komercijalne i državne organizacije, uključujući ured gradonačelnika Moskve, AFK Sistema, banke, poslovne centre i, naravno, naš vlastiti ured. Prva verzija nije bila baš uspješna, ali imali smo strategiju razvoja koja nam je omogućila da uspješno osvojimo tržište i preživimo teška krizna vremena. Iskustvo rada na ovom i nekoliko drugih investicijskih projekata također je uzeto u obzir pri formiranju razvojnog procesa kojim sam se služio.

Naš proces je niz specifičnih faza. Klasifikacija softvera koju sam dao napravljena je samo da pokaže moguću razliku u organizaciji razvoja različitih softverskih alata. U pregledu procesa razvoja, fokusirat ću se samo na razlike u samom procesu s obzirom na različite vrste softvera. Međutim, moramo imati na umu da su razlike između razvojnih procesa različitih vrsta softvera mnogo dublje, pa je pri planiranju svake faze potrebno uzeti u obzir te nijanse.

Važno je razumjeti da prijelaz procesa iz jedne faze u drugu nema jasnu granicu. U pravilu, rad u sljedećoj fazi počinje kada je 80-90% radova u prethodnoj fazi završeno. Ovo posebno vrijedi za razvojne zahtjeve, kada se u nekim slučajevima otklanjanje neizvjesnosti događa tek pri kraju projekta. Naravno, prisutnost takve neizvjesnosti u projektu je značajan rizik i treba biti pod stalnom kontrolom.

Prilagođeni proces razvoja softvera

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

Slika 1. Proces razvoja prilagođenog softvera.

Rad na projektu počinje pripremnom fazom. Svrha pozornice je na temelju prijedloga kupca izraditi neki koncept budućeg sustava i, polazeći od tog koncepta, procijeniti zahtjevnost i izvedivost projekta. Ako odluku o angažiranju izvođača donosi naručitelj na natječajnoj osnovi, tada je preliminarna faza zapravo faza pripreme potencijalnog izvođača za natječaj, uključujući i pripremu potrebne dokumentacije.

Nema potrebe gubiti vrijeme i resurse na projekt čiji se koncept smatra netraženim ili neostvarivim. Ovaj projekt mora biti dovršen. U nekim slučajevima potreban je iterativni rad s klijentom kako bi se ispravio koncept projekta dok se ne postigne prihvatljiva ravnoteža između zahtjeva korisnika i troškova izvođača ili dok se ne donese odluka o smanjenju radova.

Projekt čiji koncept izgleda prihvatljiv za realizaciju ulazi u fazu izrade zahtjeva. U ovoj fazi izvođač mora napraviti popis svih eksplicitnih i skrivenih potreba kupca. Često se pokaže da naručitelj ili nije odlučio o svojim potrebama, ili su njegove potrebe u sukobu jedna s drugom, s mogućnostima naručitelja ili s mogućnostima izvođača. Ciljevi etape su identificirati sve skrivene potrebe, riješiti konflikte zahtjeva, formulirati cjelovito tehničko rješenje i analizirati izvedivost pripremljenog rješenja.

Ponekad pojašnjenje zahtjeva dovodi do revizije koncepta projekta. Ako nakon razjašnjenja svih zahtjeva nije moguće pronaći prihvatljivo tehničko rješenje, projekt se mora skratiti ili odgoditi na neko vrijeme dok se čekaju prihvatljivije okolnosti.

Ako se pronađe tehničko rješenje, izvođač počinje razvijati arhitekturu budućeg sustava. Svrha ove faze je odrediti logičku i fizičku arhitekturu najviše razine koja u potpunosti pokriva sve zahtjeve korisnika. Prilikom izrade arhitekture preispituju se i pojašnjavaju koncept, zahtjevi i preliminarno tehničko rješenje, čime se mogu spriječiti najopasniji rizici.

Nakon završetka arhitektonskog projekta, potrebno je ponovno pregledati glavne parametre projekta i odlučiti je li izvođač u stanju dovršiti projekt. Korisno je napustiti nepotrebne i preglomazne funkcije u fazi razvoja arhitekture. Optimiziranje arhitektonskog rješenja često pomaže da se uklopi u prihvatljive parametre projekta. U drugim slučajevima potrebno je radikalnije smanjenje funkcionalnosti razvijenog sustava. Međutim, čak i zaustavljanje projekta u ovoj fazi, ako se 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 pronađena ravnoteža i stvorena prihvatljiva arhitektura sustava, izvođač može pristupiti implementaciji i isporuci sustava. Provedba se može odvijati u jednoj ili više faza. Za male projekte jednostupanjska isporuka svih funkcionalnosti sustava može biti sasvim prihvatljiva. Međutim, što je veći projekt, to su veće ovisnosti podsustava unutar stvorenog sustava. U takvim uvjetima implementaciju treba podijeliti u nekoliko faza kako bi na kraju svake faze razvojni tim imao proizvod spreman za isporuku. Međutim, najvažniju, temeljnu funkcionalnost treba rano razviti, a dodatke koji rade povrh ovih osnovnih komponenti treba implementirati kasnije. U tom će slučaju najopasnije pogreške za sustav biti ispravljene u prvim fazama, a rizik da će se aplikacijska funkcionalnost sustava temeljiti na nestabilnoj osnovi značajno će se smanjiti.
Nakon što je potpuno dovršen sustav isporučen, prilagođeni softverski projekt obično prelazi u probnu fazu. Svrha ove faze je provjera kvalitete razvijenog sustava u stvarnim radnim uvjetima. U pravilu, u ovoj fazi izvođač, zajedno s kupcem, mjeri kvantitativne metrike koje omogućuju određivanje kvalitete stvorenog sustava. Prije svega se provjeravaju funkcionalne karakteristike kvalitete, a zatim nefunkcionalne. Ako postoje nedosljednosti, izvođač prilagođava šifru sustava.

Potpuno otklonjeni i konfigurirani sustav pušten je u komercijalni rad. Izvođač u pravilu mora održavati sustav najmanje tijekom jamstvenog roka. Uočene nedosljednosti moraju se ispraviti. Korisnici i osoblje korisničke službe trebali bi dobiti brzu savjetodavnu podršku.

Napokon dolazi trenutak kada sustav iz nekog razloga prestaje odgovarati kupcu. Počinje faza razgradnje sustava. Međutim, za prilagođeni softver ova faza nije uvijek relevantna, jer naručitelj može iskoristiti svoja ekskluzivna prava na sustav i ukloniti izvođača iz daljnjeg rada na održavanju i razvoju sustava i prije nego što on izgubi na važnosti.

Svaki projekt na kraju dođe do svog završetka. Svrha faze prekida je analiza rezultata, unošenje promjena u razvojni proces na temelju stečenog iskustva i ažuriranje baze znanja programera novim učinkovitim rješenjima i upozorenjima, kao i novim gotovim komponentama koje se mogu koristiti u buduće projekte.

Ostaje uočiti još dvije faze razvojnog procesa. Dogodi se da okolnosti ne dopuštaju nastavak projekta, ali rezultati obavljenog rada pokazuju da projekt može imati budućnost. Prerano je zatvarati takav projekt. Stoga, umjesto potpunog prekida radova, izvođač može privremeno obustaviti projektne aktivnosti, evidentirajući postignute rezultate. Čim to okolnosti dopuste, projekt se može nastaviti ponovnim aktiviranjem infrastrukture, vraćanjem programera na projekt i vraćanjem stanja projekta. Važno je, međutim, nastaviti s radom od faze u kojoj je projekt prekinut, ponovno revidirajući postignute rezultate.

Proces razvoja investicijskog softvera

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

Slika 2. Proces razvoja investicijskog softvera.

Kao što lako možete vidjeti, kod razvoja investicijskog softvera odvijaju se iste faze koje smo gore spomenuli za proces razvoja prilagođenog softvera. Ali razlika je u tome što se faze ne odnose na cijeli proizvod, već na određenu verziju proizvoda. Iznimka je faza završetka projekta: projekt se ne može dovršiti dok je u tijeku rad na barem jednoj verziji proizvoda.

Imajte na umu kada započne rad na sljedećoj verziji proizvoda. Ovaj trenutak dolazi čim se završi faza stvaranja arhitekture trenutne verzije u razvoju. Prije toga, u fazama oblikovanja zahtjeva i izrade arhitekture, obično se raspravlja o tome koje funkcije treba implementirati u trenutnoj verziji, a koje treba prenijeti u buduću. I tek kada su zahtjevi za trenutnu verziju formulirani, pregledani i potvrđeni arhitekturom sustava, ima smisla razmišljati o sljedećoj verziji.

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

U načelu, možete odgoditi početak rada na sljedećoj verziji za kasniji datum. Na primjer, posve je prihvatljivo trenutnu verziju prvo staviti u pilot ili čak produkcijsku upotrebu, a tek onda početi raditi na sljedećoj verziji. Ali morate zapamtiti da takvo rješenje nije primjenjivo u slučaju velike konkurencije: jednostavno ćete biti ispred vas i istisnuti s tržišta. Odluka se mora donijeti na temelju cijelog niza okolnosti koje utječu na vaše poslovanje.

Govoreći o procesu razvoja investicijskog softvera, morate razumjeti da rad na nekoliko verzija ima niz očitih i skrivenih međuovisnosti između paralelnih grana procesa.

Prvo, ispravci nedosljednosti identificiranih u ranijoj verziji moraju se izvršiti na verziji u kojoj su otkriveni i na svim kasnijim verzijama, uključujući one u razvoju. To se ne odnosi samo na programski kod, već i na sve ostale artefakte projekta: tehničku i korisničku dokumentaciju, sustav pomoći, procjene i planove rada itd. Štoviše, ispravke je potrebno izvršiti odmah, budući da nećete moći smanjiti troškove ispravaka, ali ako ne izvršite ispravke odmah, njihov se trošak u kasnijim fazama može povećati desetke ili čak 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 nedosljednosti, automatsku montažu i pomoćne programe za testiranje itd. Ne može se dopustiti da rad na jednoj verziji proizvoda blokira rad na drugim verzijama samo zato što infrastruktura projekta ne dopušta izvođenje dvaju procesa izgradnje istovremeno za različite verzije proizvoda.

Posebnu pozornost treba obratiti na postolja na kojima se provodi testiranje: sve verzije proizvoda koje su ranije objavljene (barem one verzije koje su podržane) i sve verzije koje se trenutno razvijaju trebaju biti postavljene na njima.

Treće, isti sudionici mogu biti uključeni u rad na nekoliko verzija u isto vrijeme. Postoji veliki rizik da se ključni zaposlenik zaglavi u radu na jednoj verziji programa i značajno prekorači rokove na zadacima povezanim s drugom verzijom.

Četvrto, suprotna situacija događa se kada osoblje koje radi na jednoj verziji ne zna ništa o tome koje se odluke donose u sklopu rada na drugoj verziji. Dio problema je riješen ako se ispravci cjelokupne dokumentacije i koda odmah distribuiraju svim kasnijim verzijama, kao što sam gore spomenuo. No stvar se ne smije ograničiti samo na ispravke. Potrebno je da tim koji radi na jednoj verziji shvati zašto su određene odluke donesene prilikom rada na drugoj verziji. Da bismo to učinili, potrebna nam je baza znanja za programere - poseban informacijski sustav koji bi trebao opisati sve probleme s kojima su se programeri susreli radeći na pojedinoj verziji proizvoda, te načine rješavanja tih problema. Baza znanja treba slati obavijesti svim sudionicima projekta o primitku novih zapisa. Interakcija dvaju timova koji rade na različitim verzijama istog proizvoda ne može se prepustiti slučaju.

Proces razvoja ugrađenog softvera

Kao što je gore navedeno, ugrađeni softver razlikuje se od prilagođenog softvera po tome što ga je izuzetno teško održavati.

Recimo da proizvodite programe za hladnjake. Nakon što je softver isporučen proizvođaču, deseci tisuća uređaja počinju se raspršivati ​​po svijetu, a vi ne znate gdje će završiti. A ako jedan od hladnjaka pokvari zbog pogreške vašeg softvera, lakše je platiti kaznu nego vratiti hladnjak u tvornicu i provesti dijagnostiku. Naravno, moguće je obučiti inženjere zastupstva koji mogu obaviti dijagnostiku na licu mjesta i ažurirati firmware vašeg sustava, ali to je još uvijek vrlo skupo.

Stoga se pri razvoju ugrađenog softvera pojavljuje nekoliko važnih ograničenja odjednom.

Prvo, isporuka se provodi u samo jednoj fazi: nitko neće ugraditi napola radni softver u uređaje.

Drugo, prilikom isporuke morate obratiti posebnu pozornost na kvalitetu programa, jer od trenutka kada se implementira unutar željezne kutije, bit će ga vrlo teško promijeniti. Posebnu pozornost treba obratiti na fazu pilot rada, kada se program implementira u ograničenoj seriji uređaja, a ti uređaji prolaze sveobuhvatno testiranje u različitim načinima rada. Morate prikupiti što više informacija o dinamici ponašanja vašeg sustava, analizirati te informacije i modificirati softver.

Treće, nakon što uređaj s vašim softverom krene u proizvodnju, imate vrlo malo mogućnosti za ispravljanje pogrešaka. Zapravo, takvi su popravci mogući samo u slučaju softverskog defekta koji dovodi do neoperabilnosti cijele serije uređaja, zbog čega će proizvođač biti prisiljen povući tu seriju, a vi ćete dobiti veliku crnu mrlju na svom ugled.

Četvrto i konačno, ne postoji faza prestanka rada za ugrađeni softver. Program se jednostavno baci zajedno s uređajem. Stoga, čim istekne jamstveni rok za seriju uređaja u kojima radi vaš softver, možete pristupiti zatvaranju projekta.

Proces razvoja firmvera prikazan je na slici 3.

Slika 3. Proces razvoja ugrađenog softvera.

Proces razvoja igre

Softver za igre sam istaknuo zbog specifičnosti njihove proizvodnje i rada. Posao sa softverom za igrice temelji se na puštanju hitova. Jedan uspješan pogodak plaća troškove stvaranja nekoliko igara koje korisnici prolaze nezapaženo. Stoga je razvojni proces jedne igre međusobno povezan s razvojnim procesima drugih igara.

Još jedan faktor koji ističe produkciju igrica je činjenica da je igrica interesantna korisniku dok ne završi posljednju razinu ili dok mu se ne dogodi fatalna greška. To znači da neće kupiti drugu verziju igrice ili je čak besplatno preuzeti samo da popravi nekoliko grešaka.

Ovi čimbenici utječu na proces razvoja softvera za igre. Proces je prikazan na slici 4.

Slika 4. Proces razvoja softvera za igre.

Treba obratiti pozornost na sljedeće značajke procesa razvoja softvera za igre.

Prije svega, kvaliteta koncepta iznimno je važna pri proizvodnji igara. Ako vam koncept igre ne dopušta stvaranje pogotka, onda je daljnji rad besmislen. Situacija kada većina projekata završava u pripremnoj fazi tipična je za razvoj softvera za igre.

Pri razvijanju zahtjeva i arhitekture za softver za igre često se ponovno koristi rad naučen iz prethodnih projekata. U tom pogledu faza završetka projekta također dobiva dodatnu težinu, kada se svi korisni razvoji moraju zabilježiti u bazi znanja programera.

Softver za igre isporučuje se u jednoj fazi. Čak i ako se prvo kreira određeni kernel, “motor” sustava za igranje, njegov rad se ne može provjeriti bez implementacije svih funkcionalnosti sustava.

Ne postoje faze probnog rada i stavljanja izvan pogona za softver za igre. Igre idu u prodaju odmah, a nakon korištenja ih korisnik jednostavno izbriše jer izgubi interes za njih.

Zaključak

U sklopu članka pokušao sam dati pregled „najviše razine“ procesa razvoja aplikativnog softvera. Svaka faza procesa, naravno, zahtijeva zasebnu raspravu uz obavezno razmatranje značajki softvera koji se razvija.

Napominjem da je dijagram procesa o kojem se ovdje govori rezultat generalizacije mog osobnog iskustva u razvoju različitih softverskih alata. Kao i svaka generalizacija, moj dijagram je apstrakcija. I, kao svaka apstrakcija, ima svoje granice primjenjivosti. Ne možete nepromišljeno primijeniti ovu shemu na određeni projekt. Važno je razumjeti da svaki projekt ima svoje nijanse koje utječu na organizaciju procesa razvoja. I stoga, za svaki projekt, ovdje predstavljenu shemu treba prilagoditi, au nekim će slučajevima biti potrebno razviti bitno drugačiji pristup.

Faze razvoja softvera

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

– izrada modela i izbor metode rješenja;

– razvoj algoritma za rješavanje problema;

– kodiranje algoritma;

– kompilacija programa;

– testiranje programa;

– izrada dokumentacije;

– održavanje i rad.

Kao rezultat ove faze rada izrađuje se dokument pod nazivom „Zadatak razvoja softvera (tehnička specifikacija)“. U njemu se navodi sljedeće:

– naziv zadatka. Kratka definicija problema koji se rješava, navodi se naziv programskog paketa, programski sustav za njegovu implementaciju i hardverski zahtjevi;

- opis. Detaljno je opisana tvrdnja problema, svrha i namjena zadatka, njegovo mjesto i veze s drugim zadacima, sadržaj funkcija za obradu ulaznih informacija pri rješavanju problema te zahtjevi za učestalošću rješavanja problema. .

– upravljanje načinima rada programa. Formulirani su osnovni zahtjevi za način interakcije korisnika s programom (sučelje korisnik-računalo).

- ulazni podaci. Opisani su ulazni podaci, naznačene su granice unutar kojih se mogu mijenjati, vrijednosti koje ne mogu poprimiti itd., kao i izvor podataka, tj. uređaj kojim se moraju prenijeti u program.

- izlaz. Opisuju se izlazni podaci, naznačuje se u kojem obliku trebaju biti prikazani - numeričkom, grafičkom ili tekstualnom, vremenska ograničenja i točnost izlaznih informacija, te se navodi uređaj za prikaz tih podataka.

– greške. Navedene su moguće pogreške korisnika pri radu s programom (primjerice pogreške pri unosu podataka i sl.). Navedene su dijagnostičke metode (u ovom slučaju dijagnostika znači otkrivanje grešaka tijekom rada programskog paketa) i zaštita od tih grešaka u fazi projektiranja, kao i moguća reakcija korisnika kada počini pogrešne radnje i reakcija programskog paketa (računala) na te radnje.

– primjer rada programskog paketa. Dat je jedan ili više primjera rada programskog kompleksa na kojima se, u najjednostavnijim slučajevima, otklanjaju pogreške i testira.

Razvoj modela i izbor metode rješenja. U ovoj fazi stvara se matematički ili logički model fenomena stvarnog svijeta koji se proučava. Istodobno, potrebno je znati jezikom matematike formulirati konkretne probleme iz fizike, ekonomije, tehnologije itd. Nakon što je određen matematički model problema, potrebno je odabrati metodu za njegovo rješavanje. Ako je programabilni zadatak računalne prirode, tada se daje izlaz svih korištenih formula s detaljnim komentarima. Ako zadatak nije računalni, tada se daje verbalni opis logičkog modela, na primjer, u obliku akcijskog plana.

Razvoj algoritma za rješavanje problema. U ovoj fazi formira se opća struktura softverskog kompleksa. Algoritam – Riječ je o sustavu precizno formuliranih pravila koja definiraju proces pretvaranja prihvatljivih početnih podataka (ulaznih informacija) u željeni rezultat (izlazne informacije) u konačnom broju koraka.

U procesu razvoja algoritma mogu se koristiti različite metode njegovog opisa: verbalna notacija, dijagrami toka, pseudokod, strukturni dijagrami itd.

Rečenice koje nisu rečenice programskog jezika, iako su vrlo slične onome što pišemo u određenom programskom jeziku, nazivaju se pseudokod . Pseudokod vrlo učinkovit u razvoju programske logike. Nakon što vam se logika učini ispravnom, možete obratiti posebnu pozornost na detalje prijevoda pseudokod u pravi programski jezik. Prednost korištenja pseudokod je to što vam omogućuje da se koncentrirate na logiku i strukturu programa, a da još ne brinete o tome kako te ideje prevesti u strojni jezik. Ako želimo poboljšati program, prvo se moramo poboljšati algoritam!

Kodiranje algoritma. Faza kodiranja (programiranja) algoritama uključuje prevođenje algoritama razvijenih za svaki programski modul u programe na određenom programskom jeziku. Rezultat ove faze su datoteke s 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-u).

Sastavljanje programa. Nakon što se završi kodiranje (pisanje programa u programskom jeziku) i unese izvorni tekst programa u memoriju računala, program se kompajlira, tj. prijevod izvornog teksta u strojni kod. Ovaj proces provodi poseban program - kompajler. Slika 1 prikazuje dijagram za pripremu izvršnog programa.

Prvo se prenosi program predprocesor, koji obavlja direktive, koji se nalazi u njegovom tekstu (na primjer, #include - uključivanje datoteke u tekst programa).

Rezultirajući tekst prosljeđuje se na ulaz kompajler (Sastavljač) , koji identificira lekseme (pojedinačne riječi), a zatim na temelju gramatike jezika prepoznaje izraze i iskaze izgrađene od tih leksema. U tom slučaju, prevodilac otkriva sintaktičke pogreške i, ako ih nema, gradi objektni modul.

povezivač, ili uređivač linkova (Povezivač) , obrasci izvršni modul programe povezivanjem drugih objektnih modula s objektnim modulom, uključujući one koji sadrže bibliotečne funkcije koje su navedene u bilo kojem programu. Nakon uspješnog završetka procesa, generira se izvršna programska datoteka (datoteka s nastavkom EXE).

Testiranje programa. Postoje dvije vrste testiranja: autonomno i složeno. Tijekom offline testiranja testiraju se pojedinačni programski moduli koji čine programski paket. Sveobuhvatno testiranje sastoji se od provjere cijelog programskog paketa. Za testiranje se odabiru početni podaci za koje je unaprijed poznat rezultat izvođenja programa.

Izrada dokumentacije. Dokumentacija je klasificirana prema namjeni i može se podijeliti u nekoliko skupina: opis aplikacije, korisnički priručnik, programerski priručnik.

Opis primjene– opće karakteristike programskog proizvoda i područje njegove primjene, zahtjevi za temeljnu programsku podršku i skup alata za tehničku obradu.

Korisnički vodič– detaljan opis funkcionalnosti i tehnologije rada s programskim proizvodom za krajnjeg korisnika. Dokumenti ove vrste mogu se pripremiti u tiskanom obliku i (ili) "ugraditi" u programski paket (u potonjem slučaju pomoć u obliku savjeta poziva sam korisnik tijekom rada programskog paketa).

Programerski vodič namijenjen programerima i stručnjacima koji će ga pratiti. Glavni dokumenti uključeni u ovaj priručnik su:

Zadatak izrade softvera (tehnička specifikacija);

Specifikacija;

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

Shema podjele programskog paketa na programske module;

Dijagram protoka podataka programskog paketa;

Shema interakcije programskih modula;

Planovi i podaci za testiranje programskog paketa;

Ostali materijali koji ilustriraju projekt, na primjer: blok dijagrami programskog paketa i programskih modula.

Održavanje i rad. Nakon završenog testiranja programskog paketa, softver se pušta u rad. Tijekom rada može biti potrebno dodati nove funkcije u programski paket, ukloniti greške otkrivene tijekom rada itd. Ovakav rad s programskim paketom tijekom njegovog rada naziva se održavanje.

Postoji državni standard koji utvrđuje faze razvoja programa i softverske dokumentacije za računala, komplekse i sustave, bez obzira na njihovu namjenu i opseg.

Proces razvoja softvera može se podijeliti u stupnjeve (faze) prikazane na sl. 15.

Riža. 15. Faze razvoja softvera

Rad na softveru započinje izradom dokumenta pod nazivom “Zadatak razvoja softvera (tehnička specifikacija)”.

Samo pri rješavanju najjednostavnijih problema prikazanih na sl. 15 faza izvodi se jedna za drugom u slijedu u kojem su prikazane. Općenito, proces razvoja softvera zahtijeva stalno vraćanje na prethodne faze i unos promjena. S tim u vezi, na Sl. 15, pravokutnici s nazivima faza povezani su ne samo okomitim linijama, već i linijama koje omogućuju povratak s bilo koje faze na pozornicu iznad nje. To znači da se svaka faza može izvesti iznova.

Tehnički zadatak

Projektni zadatak uključuje tri faze: 1) obrazloženje potrebe izrade programa; 2) obavljanje istraživačkog rada; 3) izradu i odobravanje tehničkih specifikacija.

Prije početka izrade tehničke specifikacije, kupac mora ispravno postaviti zadatak. Izjava problema je stvoriti matematički ili logički model procesa ili fenomena koji se proučava. Ovdje je potrebno utvrditi je li programsko rješenje ispravno. Možda je bolje koristiti poznati aplikacijski softver (sustavi za upravljanje bazama podataka, proračunske tablice, itd.) ili jednostavno riješiti problem s nekoliko komada papira i olovke. Ako se odluči za razvoj novog programa, tada je potrebno odabrati i obrazložiti kriterije učinkovitosti i kvalitete programa koji se razvija. U slučaju razvoja velikog programskog paketa opravdana je potreba za istraživačkim radom.

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

Izrada i odobrenje tehničkih specifikacija uključuje:

Utvrđivanje programskih zahtjeva;

Izrada studije izvodljivosti za izradu programa;

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

Odabir programskih jezika;

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

Usklađivanje i odobravanje tehničkih specifikacija.

U ozbiljnim tvrtkama rezultat ove faze je opći opis sustava, uključujući zahtjeve za program i zahtjeve za pouzdanost programa. Zahtjevi za program ili softverski proizvod daju odgovore na sljedeća pitanja:

Što trebaju biti ulazni podaci?

Koji su podaci točni, a koji netočni?

Tko će koristiti softver i kakvo bi trebalo biti sučelje (način komunikacije s korisnikom)?

Koja se pojednostavljenja, pretpostavke i pretpostavke mogu učiniti u vezi s programima?

Što bi trebao biti izlaz?

Zahtjevi pouzdanosti određuju pouzdano funkcioniranje programa. Utvrđuju se greške koje je potrebno detektirati i poruke koje je poželjno prikazati korisniku u slučaju grešaka. Navedene su sve posebne situacije koje zahtijevaju dodatno razmatranje i posebno razmatranje.

Tehničkim specifikacijama određuju se uvjeti rada (temperatura okoline, relativna vlažnost zraka i sl. za odabrane vrste medija za pohranu podataka) pod kojima se moraju osigurati navedene karakteristike, kao i vrsta usluge, potreban broj i osposobljenost osoblja.

Oblikovati

Projektiranje uključuje dvije faze: idejni projekt i tehnički projekt. Idejni projekt sastoji se od preliminarne izrade strukture ulaznih i izlaznih podataka i općeg opisa algoritma za rješavanje problema. Pri izradi tehničkog projekta pojašnjavaju se strukture ulaznih i izlaznih podataka i određuju oblici njihovog prikazivanja. Specificiran je algoritam za rješavanje problema, određena semantika i sintaksa programskog jezika te razvijena struktura programa. Obje faze popraćene su obrazloženjem i studijom izvodljivosti.

Proces dizajna kritičan je dio svakog razvoja softvera. U skladu s tehnologijom top-down strukturiranog programiranja, programski kompleks je podijeljen na male dijelove - programske module. Svaki pojedinačni podzadatak mora biti relativno neovisan i predstavljati neki cjeloviti programski modul. Modularnost programa je njegovo važno svojstvo. Tijekom procesa projektiranja važno je detaljno opisati ne samo svrhu svakog modula, već i protok podataka između modula. Svaki modul karakteriziraju dva važna svojstva:

1) ima sredstva za interakciju s vanjskim okruženjem;

2) to je neovisna programska jedinica koja obavlja određene funkcije.

Dio sučelja su tokovi podataka. Prilikom njihovog opisa za svaki modul potrebno je odgovoriti na sljedeća pitanja:

Koji se podaci mogu proslijediti modulu prije nego što počne s izvođenjem?

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

Što se događa s podacima nakon što modul završi svoj rad?

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

Riža. 16. Primjer specifikacije modula

Nakon što se razvije cjelokupna programska struktura, potrebno je odrediti koji se knjižnični alati mogu koristiti i koje nove postupke treba razviti. Zatim se razvijaju algoritmi za novostvorene module.

Određuje se shema interakcije programskih modula, koja se naziva dijagram toka podataka softverskog kompleksa. Izrađuje se plan i početni podaci za testiranje programskih modula i cjelokupnog programskog paketa.

Radni nacrt

Radni projekt obuhvaća izradu programa i programske dokumentacije te testiranje programa.

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

Kodiranje bi trebalo biti jednostavno. Mora se poštovati tzv. KISS princip: Keep It Simple, Stupid (neka bude jednostavno, glupo!). Sofisticirano programiranje može biti skupo za otklanjanje pogrešaka i modificiranje programa. Neuobičajeno kodiranje (kao što je korištenje skrivenih značajki stroja) često sprječava otklanjanje pogrešaka programa i, naravno, otežava drugim programerima da ga koriste.

Iskusni programeri stvaraju univerzalne programe. Univerzalnost se odnosi na neovisnost programa o određenom skupu podataka. Na primjer, univerzalni program koristi varijable umjesto konstanti kao parametre, obrađuje degenerirane slučajeve itd. Svestranost programa štedi vrijeme u daljnjem radu na njemu i pruža široke mogućnosti korištenja. Razvojem takvih programa moguće je predvidjeti buduće promjene u specifikacijama tog programa.

Formati unosa trebali bi biti dizajnirani tako da budu lakši za korištenje i minimaliziraju mogućnost pogrešaka. Redoslijed varijabli i formata podataka koji su poznati korisniku pomoći će u izbjegavanju pogrešaka i olakšati korištenje programa. Izlazni formati mogu uvelike varirati. Ponekad se daju jasne upute i izlaz se prilagodi određenom standardu. Rezultati izračuna moraju biti čitljivi i razumljivi neprogrameru.

Nakon što su moduli ili program kodirani, dolazi vrijeme da se pokrene na izvršenje. Najvjerojatniji rezultat ovoga bit će poruka o pogrešci. Greška se nađe, ispravi i sve se ponovi iznova. Taj se proces naziva otklanjanje pogrešaka. Otklanjanje pogrešaka sastoji se od utvrđivanja gdje se greške pojavljuju, pronalaženja uzroka njihove pojave i uklanjanja tih uzroka.

Testiranje se obično provodi u dvije faze. Prvi je jedinično testiranje. Provjerava se ponašanje i pouzdanost svakog modula. Druga faza je integracijsko testiranje. Moduli se sastavljaju u zajednički program, a programer se brine za ispravnu interakciju modula. Program koji upravlja radom modula testira se odvojeno od modula. Sami moduli zamijenjeni su takozvanim "stubovima". “Stub modul” ima ulaz, izlaz i potrebnu poruku. Poruka može sadržavati popis podataka prenesenih u modul.

Testiranje je provjera funkcionalnosti programa. Otklanjanje pogrešaka događa se kada program očito ne radi ispravno. Otklanjanje pogrešaka uvijek počinje u očekivanju kvara programa. Ako se pokaže da program radi ispravno, tada se testira. Često se događa da se nakon izvođenja testova program mora ponovno otkloniti. Dakle, testiranjem se utvrđuje postojanje pogreške, a otklanjanjem pogrešaka otkriva njezin uzrok.

Za jednostavnu primjenu testiranje može biti jednostavno. Velike programe teško je testirati. Moguće je otkloniti greške tijekom faze rada.

Možete dati primjere grešaka u softverskim sustavima koje su nastale tijekom razvoja, a nisu otkrivene tijekom testiranja.

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

IF (Uvjet, VrijednostFalse, VrijednostTrue).

Međutim, u stvarnosti bi rad ove funkcije trebao izgledati ovako: IF (Uvjet, ValueTrue, ValueFalse). Ova je pogreška ispravljena u korisničkom priručniku Microsoft Works za Windows u Works 3.0.

Do neuspjeha lansiranja prvog američkog satelita na Veneru najvjerojatnije je došlo zbog pogreške u programu - umjesto tražene točke u operatoru programer je ubacio zarez. Fortran izjava je napisana

Do 50 i = 12,525

U stvarnosti je to trebalo izgledati ovako:

Do 50 i = 12,525

Uzrok komplikacija koje su nastale tijekom povratka na Zemlju sovjetsko-afganistanske i sovjetsko-francuske posade bile su pogreške u softveru ugrađenih računala.

Godine 1983. dogodila se poplava na jugozapadu Sjedinjenih Država. Razlog je bio taj što su računalu dostavljeni netočni vremenski podaci, zbog čega je poslalo pogrešan signal branama koje blokiraju rijeku Colorado.

Kako bi se osiguralo da korisnici ne dođu u situaciju da program radi, ali ne radi ono što bi trebao raditi, provodi se testiranje kako bi se identificirale "skrivene" pogreške. Prilikom testiranja koriste se planovi i podaci razvijeni već u fazi projektiranja. O testiranju je potrebno razmišljati kroz cijelo razdoblje razvoja programa (Tablica 2).

tablica 2

Vrste i uzroci grešaka

Vrsta greške	Razlog greške
Netočna izjava problema	Netočno formuliran zadatak
Pogrešan algoritam	Odabran je algoritam koji dovodi do netočnog ili neučinkovitog rješenja problema
Semantička pogreška	Semantička pogreška u programu koja nije povezana s kršenjem sintakse. Na primjer, varijable su netočno definirane, ulazni podaci nisu u skladu s graničnim vrijednostima danim u algoritmu, ispravno napisan operator programskog jezika se neispravno koristi itd. Pogreške ove vrste otkrivaju se u fazi testiranja i otklanjanja pogrešaka
Pogreške sintakse (pogreške vremena kompajliranja)	Programske pogreške koje se sastoje u kršenju gramatičkih struktura jezika. Pogreške ove vrste otkriva prevoditelj
Pogreške u izvođenju	Greške koje se javljaju tijekom izvođenja programa. Postoje I/O pogreške (na primjer, datoteka nije pronađena, nema dovoljno memorije za pokretanje programa, itd.) i kobne pogreške koje dovode do trenutnog prekida programa (na primjer, dijeljenje s nulom, pogreške prilikom provjere granica, preljeva prilikom izvođenja operacija s pomičnim zarezom itd.)
Greške u podacima	Neuspješno određivanje mogućeg raspona promjena ulaznih podataka
Greške u dokumentima	Korisnička dokumentacija ne odgovara trenutnoj verziji programa

U procesu izvođenja svih navedenih faza skuplja se određeno iskustvo koje će biti temelj za poboljšanje programa.

Faza "Izvedbeni projekt" završava preliminarnim državnim, interresornim, prijemnim i drugim vrstama ispitivanja. Programska dokumentacija se usklađuje prema rezultatima testiranja.

Provedba

Implementacija je faza životnog ciklusa programa u kojoj se program i programska dokumentacija prenose kupcu. Tijekom rada može biti potrebno dodati nove funkcije u programski paket, ukloniti greške otkrivene tijekom rada itd. Ova vrsta rada naziva se podrška.

Primjer dodavanja novih funkcija u programski paket je uređivač teksta Lexicon 1.3. Ova je verzija izvedena iz Word Processora 1.2 uključivanjem funkcije uvoza PCX grafičkih datoteka u tekstualne datoteke.

Dokumentacija

Na sl. 15, pravokutnik koji odražava svaku fazu razvoja programa povezan je s pravokutnikom "Dokument". U ovom slučaju, strelice su usmjerene u oba smjera. Ideje i rješenja koja se koriste u svakoj fazi utječu na dokumentaciju koja prati fazu, baš kao što dokumentacija utječe na ideje i odluke.

Razvoj dokumentacije počinje odmah od trenutka početka razvoja softvera. Dokumentacija se razvrstava prema namjeni i može se podijeliti u nekoliko skupina, a najmanje u dvije skupine. Prva skupina dokumenata namijenjena je programerima i stručnjacima koji će je pratiti, a druga je namijenjena korisnicima softvera.

Prva skupina uključuje, kao glavne dokumente, zadatak za razvoj softvera (tehničke specifikacije), specifikaciju i opis programa.

Projektni zadatak mora sadržavati sljedeće odjeljke:

Uvod;

Razlozi za razvoj;

Svrha razvoja;

Zahtjevi za program i softverski proizvod;

Zahtjevi za programsku dokumentaciju;

Tehničko-ekonomski pokazatelji;

Faze i stupnjevi razvoja;

Postupak kontrole i prijema.

Projektni zadatak može sadržavati priloge u kojima se, po potrebi, daje popis istraživanja i drugih radova koji opravdavaju razvoj, algoritamski dijagrami i drugi dokumenti koji se mogu koristiti u razvoju.

Specifikacija je glavni programski dokument i izrađuje se u skladu s GOST-om. Specifikacija je tablica koja se sastoji od stupaca: "Oznaka", "Naziv", "Napomena". U stupcu “Oznaka” upišite oznake navedenih dokumenata i programa. U stupcu “Dokumentacija” navedite naziv i vrstu dokumenta ili programa. U stupcu “Napomena” - dodatne informacije vezane uz programe zabilježene u specifikaciji.

Opis programa sadrži:

– komentirani izvorni tekstovi (listingi) programskih modula i upravljačkog modula;

– shema podjele programskog paketa na programske module;

– dijagram toka podataka programskog paketa;

– shema interakcije programskih modula;

– planove i podatke za testiranje programskog paketa;

– drugi materijali koji ilustriraju projekt, na primjer dijagrami algoritama.

Druga vrsta dokumenata sadrži podatke potrebne za rad s programskim paketom. Ti se dokumenti mogu ispisati i (ili) "ugraditi" u programski paket.

Disciplina programiranja važan je čimbenik uspjeha razvoja softvera. Principi razvoja programa predstavljeni u zadnjem poglavlju vrijede za proceduralne programske jezike i za objektno orijentirane jezike.

Verzija 6.0 Turbo Pascala, objavljena 1990., jasno je pokazala prednosti tehnologije objektno orijentiranog programiranja. Nova verzija uključivala je biblioteku Turbo Vision, koju su koristile mnoge tisuće programera za svladavanje principa OOP-a. U kratkom vremenu pojavili su se mnogi komercijalni programi temeljeni na Turbo Visionu. Ova će biblioteka doista revolucionirati proces razvoja interaktivnih programa, skraćujući vrijeme na minimum i osiguravajući programe najviše kvalitete.

Evolucija tehničkih sredstava osobnih računala dovela je do raširene zamjene dobrog starog MS-DOS OS-a puno moćnijim Windows sustavima, čije je programiranje mnogo teže od programiranja za MS-DOS. Izdavanjem Borland Pascala s objektima, Borland Corporation je programerima stavio na raspolaganje visoko učinkovite alate za razvoj programa i otklanjanje pogrešaka dizajnirane za rad pod Windows operativnom ljuskom. Ali ipak, prije nekoliko godina, prosječni programer mogao je samo sanjati o stvaranju vlastitih programa za Windows.

Formulacija problema. Izrada bilo kojeg programa počinje postavljanjem problema. U početku je zadatak formuliran u smislu predmetnog područja, a potrebno ga je prevesti

Riža. 26.1.

to u jezik koncepata bliži programiranju. Budući da programer rijetko ima temeljito razumijevanje predmetnog područja, a kupac rijetko ima temeljito razumijevanje programiranja (jednostavan primjer: trebate napisati 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 potpuno formulirati svoje zahtjeve i kriterije.

U ovoj se fazi također određuje okruženje u kojem će se program izvoditi: hardverski zahtjevi, OS i ostali softver koji se koristi.

Iskaz problema završava stvaranjem Tehničke specifikacije, i onda specifikacija vanjskog programa, uključujući:

■ opis izvornih podataka i rezultata (vrste, formati, točnost, način prijenosa, ograničenja);

■ opis zadatka koji provodi program;

■ način pristupa programu;

■ opis mogućih izvanrednih situacija i pogrešaka korisnika.

Dakle, program se promatra kao "crna kutija" za koju je definirana funkcija te ulazni i izlazni podaci.

Odabir modela i metode rješavanja problema. U ovoj fazi se analiziraju uvjeti problema, te se na temelju toga gradi model problema i utvrđuje opća metoda za njegovo rješavanje. Prilikom konstruiranja modela identificiraju se karakteristike problema koje su značajne sa stajališta razmatranja, tj. apstrahirano je. Ove karakteristike moraju biti predstavljene u modelu s potrebnom potpunošću i točnošću. Drugim riječima, u ovoj fazi formalizira se formulacija problema i na temelju toga se utvrđuje opća metoda za njegovo rješavanje. Ako postoji više metoda, odabire se najbolja na temelju kriterija složenosti, učinkovitosti, točnosti, ovisno o specifičnim zadacima s kojima se programer suočava.

Razvoj internih struktura podataka. Većina algoritama ovisi o tome kako su podaci organizirani, pa je intuitivno da dizajn programa ne treba započeti s algoritmima, već s razvojem struktura potrebnih za predstavljanje ulaznih, izlaznih i međupodataka. U ovom se slučaju uzimaju u obzir mnogi čimbenici, na primjer, ograničenja veličine podataka, potrebna točnost i zahtjevi za brzinom programa. Strukture podataka mogu biti statične i dinamičke.

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

■ Kolika je točnost podataka potrebna?

■ Koji je raspon vrijednosti podataka?

■ Postoji li maksimalno ograničenje podataka?

■ Je li ih potrebno istovremeno pohraniti u program?

■ Koje radnje treba izvršiti na podacima?

Na primjer, ako je maksimalna količina podataka iste vrste koju je potrebno obraditi poznata i mala, najlakši je način stvoriti statički niz za njihovu pohranu. Ako postoji mnogo takvih nizova, segmenti podataka i stog možda neće biti dovoljni, pa ćete morati dodijeliti prostor u dinamičkoj memoriji za te nizove.

Ako je maksimalna količina podataka nepoznata i stalno se mijenja dok program radi, tada se koriste dinamičke strukture za njihovu pohranu. Izbor tipa strukture ovisi o potrebnim operacijama nad podacima. Na primjer, za brzo traženje elemenata najprikladnije je binarno stablo, a ako podatke treba obraditi redoslijedom kojim pristižu, koristi se red čekanja.

Oblikovati. Pod, ispod dizajn programa odnosi se na definiranje opće strukture i interakcije modula.

U ovoj fazi se primjenjuje tehnologija dizajna odozgo prema dolje, čija je glavna ideja gore razmotrena. U ovom slučaju koristi se metoda detaljizacije korak po korak.

Možete zamisliti taj proces na način da se prvo program napiše na jeziku nekog hipotetskog stroja koji je sposoban razumjeti najopćenitije radnje, a zatim se svaka od njih opisuje na nižoj razini apstrakcije itd. Vrlo je važno u ovoj fazi specifikacija sučelja, oni. određivanje načina na koji podzadaci međusobno djeluju.

Za svaki podzadatak izrađuje se vanjska specifikacija slična onoj prethodno danoj. U istoj fazi rješavaju se pitanja podjele programa na module, pri čemu je glavni kriterij minimiziranje njihove interakcije. Jedan zadatak se može realizirati pomoću više modula, i obrnuto, više zadataka se može riješiti u jednom modulu. Na nižu razinu projektiranja prelaze tek nakon završetka projektiranja gornje razine. Algoritmi su napisani u generaliziranom obliku, kao što su riječi, generalizirani dijagrami toka ili druge metode.

PAŽNJA

Tijekom faze dizajna trebali biste razmotriti mogućnost budućih izmjena programa i nastojati dizajnirati program na način da su izmjene moguće što lakše.

Budući da se ne zna kakve će promjene biti potrebne, ta želja nalikuje stvaranju “opće teorije svega”; U praksi se moramo ograničiti na razumne kompromise. Programer na temelju svog iskustva i zdravog razuma odlučuje koje značajke programa treba promijeniti ili poboljšati u budućnosti.

Proces dizajna je iterativan jer je u programima stvarne veličine nemoguće smisliti sve detalje prvi put.

Strukturirano programiranje. Programiranje se ovdje smatra "u užem smislu", tj. shvaća se kao pisanje programa u programskom jeziku pomoću gotovog algoritma. Taj se proces često naziva kodiranje kako bi ga razlikovali od kompletnog ciklusa razvoja programa.

Kodiranje je također organizirano od vrha prema dolje: prvo se kodiraju moduli najviše razine i sastavljaju se testni slučajevi da bi se otklonile pogreške. U ovom slučaju, umjesto modula sljedeće razine koji još nisu napisani, postavljaju se stubovi koji u najjednostavnijem slučaju jednostavno prikazuju poruku da je kontrola prenesena na njih, a zatim je vraćaju pozivnom modulu. U drugim slučajevima, stub može proizvesti vrijednosti koje su unaprijed definirane ili izračunate pomoću pojednostavljenog algoritma.

Tako se najprije stvara logički kostur programa, koji se potom nadrasta mesom koda. Čini se logičnijim primijeniti tehnologiju odozdo prema gore na proces programiranja: prvo napisati i otkloniti pogreške u modulima niske razine, a zatim ih kombinirati u veće fragmente, ali ovaj pristup ima brojne nedostatke.

Prvo, u procesu kodiranja gornje razine mogu se otkriti određene poteškoće u dizajniranju nižih razina programa (jednostavno zato što se prilikom pisanja programa njegova logika promišlja pažljivije nego tijekom dizajna). Ako se takva pogreška otkrije zadnja, potrebni su dodatni troškovi za preradu gotovih modula niže razine.

Drugo, za debugiranje svakog modula, a potom i većih fragmenata programa, potrebno je svaki put sastaviti vlastite test slučajeve, a programer je često prisiljen imitirati okruženje u kojem modul mora raditi. Tehnologija programiranja odozgo prema dolje pruža prirodan redoslijed za izradu testova - mogućnost otklanjanja pogrešaka odozgo prema dolje, o čemu se govori u nastavku.

Faze dizajna i programiranja vremenski se kombiniraju: idealno je da se prvo dizajnira i kodira najviša razina, zatim sljedeća itd. Ova strategija se koristi jer smanjuje cijenu pogreške, budući da će možda biti potrebno napraviti promjene tijekom procesa kodiranja koje utječu na module niže razine.

Top-down testiranje. Ova faza se bilježi posljednja, ali to ne znači da se testiranje ne treba provoditi u prethodnim fazama. I dizajn i programiranje moraju biti popraćeni pisanjem paket za testiranje – verifikacijski početni podaci i odgovarajući skupovi standardnih reakcija.

Potrebno je razlikovati procese testiranja i otklanjanja pogrešaka programa. Testiranje je proces kojim se provjerava ispravnost programa. Testiranje je pozitivno i njegova je svrha pokazati da program radi ispravno i zadovoljava sve specifikacije dizajna. Otklanjanje pogrešaka– proces ispravljanja pogrešaka u programu, pri čemu cilj nije ispraviti sve pogreške. Ispravlja greške pronađene tijekom testiranja. Pri planiranju treba voditi računa da se proces otkrivanja grešaka pokorava zakonu zasićenja, tj. Većina pogrešaka otkrije se u ranim fazama testiranja, a što je manje pogrešaka ostalo u programu, to će dulje trebati da se svaka od njih pronađe.

Postoje dvije strategije testiranja: crna kutija i bijela kutija. Pri korištenju prvoga ne vodi se računa o unutarnjoj strukturi programa i testovi su koncipirani na način da se u potpunosti provjerava funkcioniranje programa na ispravne i netočne ulazne utjecaje.

Strategija bijele kutije uključuje testiranje svih grana algoritma. Ukupan broj grana određen je kombinacijom svih alternativa u svakoj fazi. To je konačan broj, ali može biti vrlo velik, pa se program razbija na fragmente, nakon čega se oni nakon iscrpnog testiranja tretiraju kao elementarni čvorovi dužih grana. Osim podataka koji osiguravaju izvršavanje naredbi u traženom nizu, testovi moraju sadržavati provjera rubnih uvjeta(na primjer, prijelaz prema uvjetu x> 10 mora se provjeriti za vrijednosti veće od, manje od i jednake 10). Odgovor programa na pogrešni izvorni podaci.

Hendikep Strategija “bijele kutije” je da je njome nemoguće otkriti granu koja nedostaje, a strategija “crne kutije” zahtijeva veliki broj ulaznih opcija, pa se u praksi koristi kombinacija obje strategije.

PAŽNJA

Ideja testiranja odozgo prema dolje sugerira da testiranje programa počinje prije nego što je njegov dizajn dovršen. To vam omogućuje ranije isprobavanje glavnih intermodularnih sučelja i uvjeravanje da program u osnovi zadovoljava zahtjeve korisnika. Tek nakon što je logička jezgra testirana do te mjere da postoji povjerenje u ispravnu implementaciju glavnih sučelja, počinjemo s kodiranjem i testiranjem sljedeće razine programa.

Naravno, nemoguće je potpuno testirati program dok je predstavljen u obliku kostura, ali dodavanjem svake sljedeće razine možete postupno proširiti područje testiranja.

Faza otklanjanja pogrešaka na razini sustava od kraja do kraja kod dizajna odozgo prema dolje traje kraće od dizajna odozdo prema gore i proizvodi manje iznenađenja jer je mnogo manje vjerojatno da će uvesti velike greške koje utječu na veliki dio sustava. Osim toga, za svaki modul spojen na sustav već je kreirano njegovo okruženje, a izlazni podaci debugiranih modula mogu se koristiti kao ulazni podaci za testiranje drugih, što olakšava proces testiranja. To ne znači da modul treba biti spojen na sustav potpuno “sirovi”; može biti zgodno provesti dio testiranja autonomno, jer je teško na ulazu sustava generirati sve opcije potrebne za testiranje zasebnog modula .

Kaskadni model u svom čistom obliku koristi se samo za jednostavne programe, jer je teško unaprijed predvidjeti sve detalje implementacije. Realističnija shema je s međukontrolom (slika 26.2). Kontrola koja se provodi nakon svake faze omogućuje, ako je potrebno, povratak na bilo koju višu razinu i uvođenje potrebnih promjena.

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

Riža. 26.2.

• Tipovi i formati ne odnose se na tipove programskih jezika.