6. RAZVOJ PROGRAMSKE POTPORE

U poglavlju 3.4.3. već su navedene faze razvoja programske potpore. Karakter programa uslovljava način rješavanja po pojedinim etapama od kojih je za digitalno računalo specifična etapa pisanja i unošenja programa jednim od jezičkih procesora, a ilustrirana je u poglavlju 6.2. prema primjeru iz narednog podpoglavlja.

Kojim se od jezičkih procesora koristiti ovisi o vrsti problema koji se riješava te o mogućnostima i vrsti DRS na kojoj će se primjeniti. Stoga tu nema strogih zakonitosti. Jednostavnije zadaće rješavati će se na PC-računala s QBASIC ili VISUAL BASIC jezičkim procesorom, a za knjigovodstvene svrhe ili obradu studentske populacije koristiti će se alati koji mogu uporabiti neki od poslužitelja baze podataka kao DELPHI. Jedna od vrhunskih programski potpora za praćenje rada velikih firmi i ustanova, LOTUS-NOTES, vrlo je učinkovito ali i vrlo skupo rješenje.

U poglavlju 3.4.3 navedeno je da postoje dvije osnovne grupe jezičkih procesora s obzirom na kreiranje izvršnog koda i sam način izvršavanja izvršnog koda. Ukratko: KOPAJLERI i INTERPRETERI. Za prevodjenje nekog napisanog izvornog koda služi Kompajler (prevodioc) koji stvara izvršivu datoteku (.exe ili .com tipa) od izvornog koda, znači prevodi izvorni kod u izvršivu (binarnu) verziju koja se potom može primijeniti i testirati rezultat, i ako se primijeti greška u radu programa moraju se ispraviti u izvornom kodu, kojeg potom opet treba prevesti i novu izvršivu datoteku te opet je pokrenuti i testirati. Interpreter to radi drugačije. Prevodi se jedna po jedna instrukcija izravno iz izvornog koda u realnom vremenu i po prevođenju izvršava. Prevedeni rezultat nigdje se ne čuva. Izmjene u samom izvornom kodu mogu se odmah provjeriti a mogu se vršiti i za vrijeme samog izvršavanja kreiranog programa. Uzastopno prevođenje instrukcija sigurno daje značajno sporije rezultate glede brzine obrade podataka, ali je otklanjanje grešaka jednostavnije. Poneki jezički procesori, kao QuickBASIC, imaju osobitost i interpretiranja izvornog koda i njegovog prevođenja u izvršivu datoteku.

No bez obzira koji se od jezičkih procesora primjeni, postupak kreiranja konačnog rezultata sagledan u etapama njegove kreacije je sličan. Broj etapa i način njihove primjene ovisi od 'škole programiranja', a najjednostavniji prikaz njihovog slijeda značaja opisan je u narednom poglavlju. Etape razvoja programske potpore prikazane su u narednim poglavljima kroz nekoliko primjera, ali bez prikaza riješenja s uporabom jednog od jezičkih procesora.

6.1. FAZE RAZVOJA PROGRAMSKE POTPORE

Svakodnevno se u životu susrećemo s problemima koji nam se nameću i koje moramo riješiti na način koji smo odabrali kao najpogodniji, bilo da je to nešto posve novo ili rutinski dio za koji ćemo iskoristiti već poznata saznanja i rješenja.

Jedan od svakodnevnih primjera je priprema objeda za porodicu, kada naše mame na primjer za blagdan spremaju kolače. U narednoj tablici objašnjen je taj postupak u usporedbi s već prije navedenih 7 faza razvoja programske potpore u poglavlju 3.4.3.

Faza Izrada kolača Opis Zadaci u razvoju programske potpore 1. Kakav želimo? Uočavanje i opća definicija problema. 2. Što nam treba? Precizna formulacija problema. 3. Koji su omjeri? Matematički model ponašanja. 4. Kako se miješa? Redoslijed akcija - dijagram tijeka. 5. Gdje se peče? Izbor jezičkog procesora. 6. Kako je ispalo? Testiranje i ispravak uočenih grešaka. 7. Konačni recept. Izrada programske dokumentacije i uputa.

Tablica 6.1.1 Faze razvoja izrade blagdanskog kolača.

Navedeni primjer je ilustracija kako pristupiti rješavanju bilo kojeg zadatka. U narednim primjerima prikazane su prve četiri faze rješavanja problema pretvorbe u brojevnim sustavima. Prve tri faze su skup dobro definiranih podataka, uvjeta te njihove međusobne povezanosti i podrazumijevaju opis akcija koje vode ka konačnom rješenju i nazivaju se algoritam. Algoritam je postupak raščlanjivanja problema (zadatka) u precizne sitne korake. Dijagram tijeka je grafički prikaz algoritma u kojem se redoslijed akcija i njihova međusobna veza prikazuje međusobno povezanim geometrijskim likovima, odnosno standardiziranim grafičkim simbolima za početak, kraj, naredbu, odluku i drugo.

Treba imati na umu da u informatici parametri ili varijable tijekom postupka programiranja obično za početnu vrijednosti imaju veličinu ' 0 ' za npr. prvo polje u matrici podatka ili gornji lijevi piksel u grafičkom prikazu i slično. Već je prije navedeno da su opisane faze samo jedan od mogućih primjera kako pristupiti rješavanju zadaće, te da programerske firme imaju svoje postupke razvijene prema njihovim načelima i potrebama, najčešće opisane kroz više koraka u odnosu na prethodno opisani primjer. Navedenih sedam faza su nekakva temeljna struktura koja ne mora biti pravilo, ali može poslužiti kao osnova za uspostavu složenije razvojne strukture. Složenija razvojna struktura pogoduje razvojnim timovima i u sebi će sadržavati sprege između pojedinih timova ili članova unutar tima u svrhu koordinacije postupaka i uvida učesnika u razvoju programske potpore u rezultate rada pojedinih članova tima ili samih timova.

Razvoj programske potpore nije trivijalan posao. Moguće su pogreške u dizajnu i samom programskom kodu. Tako ispravka jedne pogreške (bug-a) može dovesti do više novih da bi se postupno njihov broj smanjivao i sveo na najmanju moguću mjeru prije objelodanjivanja rezultata. Dakle, cijeli postupak je rekurzivan, iz trenutne faze moguć je povratak u prethodne da bi se uočeni nedostaci uklonili. Kad se gotov proizvod objelodani gotovo uvijek se naknadno ustanovi da ima nekakvih propusta. Nije popularno objelodaniti da je ispravljen nekakav propust (bug), već marketinški puno ljepše zvuči da je izvršen UPDATE, kako nekakva dogradnja ili slično. Nije .. nego ..  :-). 'Update' je 'zakrpa' koji proizvođač obično nudi besplatno. U navedenom smislu sličan je termin UPGRADE, koji podrazumijeva nove osobitosti proizvoda (uz prešutno zakrpane bug-ove naravno) i za koje treba nešto i nadoplatiti.

Postupak opisivanja bilo kojeg proizvoda u razvoju programske potpore mora biti kvalitetno dokumentiran. Tu nema mjesta strahu da će netko drugi uradak po takvom dokumentu iskoristiti, jer ga tvorac neće nikome dati. Dapače, opisi i naznake (remark) upravo kreatoru programske potpore služe da se podsjeti što je radio, jer će nakon par mjeseci sigurno zaboraviti 'neke male sitne detalje koje samo on razumije'. U naizgled najjednostavnijem poslu instalacije operativnog sustava na računalo postoji niz postavki koje treba podesiti da bi sustav bio učinkovit i djelotvorno zaštićen. Postupak se opisuje u dokumentu koju se uobičajeno naziva TO-DO lista (postupak izrade), koji sadrži više od stotinu u tančine opisanih radnji. Lista je uobičajeno sastavljena od tri stupca: redni broj radnje, opis postupka koji treba provesti da bi se radnja izvršila i oznake izvršenja / neizvršenja radnje (kvačica). To omogućava da se bez velikih 'prisjećanja' sutradan nastavi postupak prema listi koji je do jedne točke prethodnog dana izvršen i tako do zaključenja provedbe svih opisanih radnji. Lista se ne može izraditi za jedan dan, već je to dokument koji se dinamički mijenja prema potrebama i u koji je 'ugrađeno' iskustvo jednog ili više kreatora liste. Kvalitetna lista svoju opravdanost pokazati će tek nakon cijele godine njenog redovnog ažuriranja. Dakle, lista - DA, ali njeno javno objavljivanje - NE. Opisani postupci u prilozima pod i.) samo su šturi dio jedne od takvih lista.

Nema gore stvari i bruke glede isporučene programske potpore korisniku od vječitog ispravljanja bug-ova. Kvalitetna dokumentacija sigurno smanjuje postupak otklanjanja istih, i olakšava implementaciju dodatnih programskih rješenja za koja se je tijekom vremena nametnula potreba za njihovu izradu, kao što je na primjer dogradnja zbog promjene neke zakonske regulative u knjigovodstvenim programima. Programska potpora ne stvara se 'preko noći' i ponekad treba i koja godina vremena dok ne 'sazre' za konačnu uporabu. Za primjer može se uzeti bilo koja programska potpora i pratiti njen razvoj kroz opise nadopuna pojedinih verzija u dokumentu koji obični ima naziv 'Changelog...' ili 'What's new...'. Treba malo vremena da programska potpora dosegne verziju 1.0 :-). Popularno nazvana osoba 'programer' samo je jedna od osoba koja učestvuje u izradi programske potpore. Ovisno o vrsti iste u timu koji je radi biti će matematičar, ekonomista, građevinac ... Timski rad sve je izraženiji u odnosu na individualnost u tom poslu. Važnost tima u fazi testiranja programske potpore veoma je važna stavka i uobičajeno se obavlja kako je navedeno u poglavlju 6.2.2; dio opisa programerskog alata QBASIC.