Softverski inenjering ili softversko inenjerstvo (software engineering) je skup aktivnosti i primenjenih metoda i tehnika, koje obuhvataju deo ivotnog ciklusa IS

SOFTVERSKI INENJERINGSoftverski inenjering ili softversko inenjerstvo (software engineering) je skup aktivnosti i primjenjenih metoda i tehnika, koje obuhvataju dio ivotnog ciklusa IS. Nema jedinstvenog stava meu strunjacima koji je to dio, jer inenjerstvo po svojoj prirodi polazi od ciljeva, a zatim kroz analizu procesa i podataka treba da omogui dobijanje krajnjeg proizvoda. U ovom sluaju to je softver, ija validnost i vrijednost se provjerava testiranjem softvera i kroz njegovu implementaciju u realnim uslovima. Ve iz ove prve naznake se moe naslutiti da softverski inenjering mora da obuhvati: arhitekturu aplikacija i dizajniranje procesa, dizajn podataka, DB dizajn (ukoliko je potrebna izrada dopunskog softvera za rad sa DB), dizajn i izradu prototipa ulaza u IS, dizajn i izradu prototipa izlaza iz IS, dizajn softvera, objektno orijentisani dizajn (kao nastavak dizajna softvera) i odravanje softvera.Zbog svog znaaja, mnogi autori izdvajaju dizajn softvera, koji obuhvata objektno orijentisani dizajn i strukturirani dizajn, i to izjednaavaju sa softverskim inenjeringom.Inenjering zahtjeva

Inenjering zahtjeva (Requirements engineering) obuhvata skup aktivnosti vezanih za utvrivanje dokumentacije i odravanje zahtjeva koji se postavljaju pred IS. Prefiks "inenjering" implicira primjenu sistematskih i ponovljivih tehnika koje omoguavaju da zahtjevi budu kompletni, konzistentni i relevantni za razvoj IS.Inenjering zahtjeva u oblasti analize i projektovanja ISIDEF (Integration DEFinition) je standardna tehnika kod modeliranja i projektovanja IS za sloene sisteme. IDEF pristup dekompoziciji i analizi procesa zasniva se na intenzivnoj primjeni IT uz korienje drugih metoda (simulacije i drugih).Osnovni model je IDEF0 u kome se svaki proces posmatra sa aktivnostima ulaza, kontrole, izlaza i resursa. Ka osnovu IDEF pristupa svaki proces se moe razloiti na niz IDEF modela koji se mogu hijerarhijski dekomponovati.

Savremeni strukturirani dizajn (engl. modern structured design) je procesno orijentisana tehnika za dekompoziciju velikog broja programa u hijerarhijski ureene module, ime se dobija aplikativni softver (program) laki za primjenu i odravanje (izmjene). Sinonimi za ovo su top - down dizajn programa (top - down program design) i strukturirano programiranje (structured programing).

Model softvera koji se dobija iz strukturiranog dizajna se naziva slika (dijagram) strukture (structure chart). Ova tehnika je popularna posebno kod aplikativnog softvera za mainframe sisteme, radi adresiranja veze i zahtjeva, kako bi bili zatvoreni na nivou centralnog sistema.Informacioni inenjering (IE - Information Engineering) je tehnika orijentisana na podatke ukljuivanjem analize poslovnih zahtjeva koje treba ugraditi u aplikativni softver po prioritetima. Aplikacije koje drugi analitiari sistema i dizajneri, koristei metode savremene strukturirane analize i modernog strukturiranog dizajna, izrade prototipa i OOA transformiu u programski kod.Arhitektura aplikacija i dizajniranje procesaArhitektura aplikacija (Application Architecture) odnosi se na opti dizajn IS, to ukljuuje arhitekturu primjenjene informacione tehnologije, strategije arhitekture aplikacija, modeliranje arhitekture aplikacije i procesa informacionog sistema i dizajniranje aplikacione arhitekture i procesa informacionog sistema.Arhitektura informacione tehnologijeU okviru arhitekture informacione tehnologije, jo jednom, se vri preispitivanje arhitekture mree, arhitekture podataka za distribuirane relacione DB, arhitekture interface-a i okruenja za razvoj softvera i menadment sistema.a) Arhitektura mreeArhitektura mree je posebno vana za sluaj klient/server pristupa. Pri tome su DB, interface i softver distribuirani u mrei klijenata i servera, koji rade zajedno obezbjeujui ciljeve sistema. Zbog toga je sinonim za klijent/server obradu, distribuirana obrada ili kooperativna obrada.Uloga mrene tehnologije nije samo da povee udaljene informacione resurse i omogui njihov skladan rad kroz razliite mrene topologije, ve prije svega da obezbjedi veu ekonominost u dobijanju informacija.b) Arhitektura podataka za distribuirane relacione DBSoftver koji omoguuje primenu distribuirane relacione DB se naziva sistem za upravljanje distribuiranom relacionom DB (distribuirani RDBMS - Relational Distributed DB Management System). Replikacijom podataka (Data Replication) dupliraju se podaci na jednom ili vie servera DB, pri emu RDBMS sprovodi monitoring celog postupka.c) Arhitektura interface-aU okviru arhitekture interface-a razmatraju se mogunosti ulaza, izlaza i korisnikog softvera za informaciju u okviru raunarskog sistema (midleware).Sa aspekta naina obrade definiu se aplikacije, koje e se obraivati u paketu (batch obrada), kao on - line obrada ili obrada podataka na daljinu (Remote batch), uz preispitivanje prednosti i nedostataka svakog naina obrade za konkretan sluaj softverskog inenjeringa.Sa aspekta ulaza analiziraju se mogui naini ulaza podataka bez korienja tastature.Sa aspekta grafikog korisnikog interface-a razmatra se primjena raznih tipova GUI-a (npr. Windows 2000), browser -a (npr. Internet Explorer pod Windows-om), elektronska pota, EDI.

Korisniki softver za integraciju u okviru raunarskog sistema (middleware) "premoava" ili spaja do tada nekompatibilne tehnologije i omoguava da se primjeni savremeno rjeenje povezivanja otvorenih DB.

d) Okruenje za razvoj softvera i menadment sistemom

Okruenje za razvoj softvera (SDE - Software Development Enviroment) praktino obuhvata jezike i alate za izradu softvera (npr. C++, Java, C, Visual Basic, Pascal itd.). Pri tome se razlikuju SDE za centralizovanu obradu i distribuiranu prezentaciju, klijent/server u dva nivoa, klijentiserver sa vie nivoa, klijentlserver u INTERNET /INTRANET okruenju (HTML - Hypertext Markup Language) i CGI (Computer Gateway Interface, Java).

Pored SDE, ovde se analizira i koncept menadmenta sistemom (npr. praenje obrade transakcija, upravljanje konfiguracijom itd.).Dizajn DB

Osnove fizikog dizajna DB

Dizajn podataka je polaz za dizajn DB.

Datoteke (files) su skupovi slinih slogova (npr. datoteka KUPCI, ZAPOSLENI itd.).Baze podataka (DB - Data Bases) su skupovi povezanih datoteka ili tabela. Pri tome je kljuna re povezan, jer se kod DB preko relacija (veza) u obliku tzv. "pointera" povezuju slogovi razliitih datoteka .Osnovna prednost DB je mogunost dijeljenja podataka za vie IS i aplikacija, to uz nezavisnost podataka i korienje savremenih sistema za upravljanje DB (DBMS) ini da je koncept DB istisnuo koncept datoteka, sem kod jednostavnijih i autonomnih IS.Da bi se iskoristile prednosti koncepta DB pri dizajnu DB, mora se fokusirati na PODATKE, tj. na shemu DB i zatim kroz proces projektovanja DB pretvoriti shemu DB u strukturu podataka koju podrava izabrana tehnologija DB.Za DB i datoteke zajedniki element je polje (field) ili atribut podatka koji se smjeta ili opisuje DB ili datoteku. Razlikuju se etiri tipa polja koja mogu biti: primarni kljuevi, sekundarni kljuevi, strani kljuevi i opisna polja.Primarni kljuevi su polja ije vrednosti identifikuju jedan i samo jedan zapis u datoteci (npr. BROJ KUPCA u slogu KUPAC).Sekundarni kljuevi su alternativni identifikatori za DB jer mogu identifikovati ili pojedinaan slog (kao sa primarnim kljuem) ili deo svih slogova (npr. STATUS NALOGA i prema tome izdvojiti NALOG-e sa kanjenjem). Datoteka ili tabela u bazi podataka moe imati samo jedan primarni klju i vie sekundarnih kljueva.Strani kljuevi su pointeri za vezu sa slogovima razliitih datoteka (tabela) u DB.

Opisna polja su polja u koja se smjetaju poslovni podaci.

Slogovi (records) su skupovi polja ureeni prema unaprijed poznatom redoslijedu i formatu.Datoteke su skupovi pojava svih atributa datih u strukturi sloga.Tabela je ekvivalent datoteke i odnosi se na relacione DB.Razlikuju se sledei tipovi datoteka i tabela:

master (glavna) datoteka (master files) ili tabela sadri slogove koji su relativno nepromenljivi ili se povremeno dodaju ili menjaju pojedini slogovi, transakciona datoteka (transaction file) ili tabela sadri slogove koji opisuju poslovne dogaaje i stoga imaju ogranieno vreme ivota za on-line pristup ili se posle isteka odreenog vremena ovakvi podaci smetaju u arhivsku datoteku, datoteka dokumenata (document file) ili tabele sadri memorisane kopije odreenih podataka na dokumentu, to je posebno korisno za datoteke, konstruktivnih crtea, tehnologije itd. arhivska datoteka (archival file), tabele maske i transakcione datoteke, koje se ne koriste za on-line obradu. tabela za posmatranje datoteka (table look-up file) sadri relativno statike podatke koji se koriste u veem broju aplikacija za odravanje njihove konzistentnosti i unapreenje performansi (npr. tablica taksi, inflacije, potanske brojeve itd.). tabela provere (audit file) su specijalni slogovi iz auriranih master i transakcionalnih datoteka, koji se koriste zajedno sa arhivskim datotekama za "restauraciju" (vraanje) izgubljenih podataka, to poseduju svi suvremeni DBMS.Arhitektura podataka (Data Architecture) obuhvata datoteke i baze podataka, tehnologiju za njihovo memorisanje i uvanje i organizacionu strukturu koja podrava podatke kao znaajan poslovni resurs.Pored centralne DB (skladita podataka - Data Warehouse), u arhitekturi podataka postoje i operativne DB u koje se smjetaju rezultati dnevne obrade.Arhitektura DB se odnosi na tehnologiju, upravljanje DB, ukljuujui alate i pomone programe. Osnovni element arhitekture DB je DBMS (sistem za upravljanje DB). To je specijalni softver za kreiranje, pristup, kontrolu i upravljanje radom DB.

Slika 2. Arhitektura podataka

Postupak fizikog dizajna DB

Fiziki dizajn DB obuhvata i dizajn datoteke kao jednostavniji pojavni oblik DB za jednu aplikaciju. Elementi dizajna datoteke (file design) su pristup datoteci (file access) i organizacija datoteke (file organization).Fiziki dizajn DB obuhvata sledee faze:a) utvivanje ciljeva i podloga za dizajn DBCiljevi dizajna DB su: DB mora omoguiti efikasno skladitenje, auriranje i dobijanje podataka, DB mora biti pouzdana, tj. mora se ostvariti visok nivo integriteta podataka i DB mora biti adaptibilna i skalabilna radi ugradnje novih, u poetku nepredvienih zahteva aplikacija.b) utvrivanje sheme DBShema DB (database shema) je fiziki model ili prikaz (blueprint) DB. Ona predstavlja tehniku implementaciju logikog modela podataka.Relaciona shema DB definie strukturu DB u obliku tabela, kljueva, indeksa i pravila integriteta, kao i detalja vezanih za mogunosti, terminologiju i ogranienja izabranog sistema za upravljanje DB (DBMS), jer svaki DBMS podrava razliite tipove podataka, pravila integriteta itd.c) odreivanje podataka i referentnog integritetaIntegritet DB je stvar povjerenja, ali i postupaka internih kontrola. Razlikuju se tri tipa integriteta podataka u DB i to: Integritet kljuevaSvaka tabela mora imati primarni klju koji se kontrolie tako to ne smije biti dva sloga u tabeli sa istom vrijednou primarnog kljua.

Integritet domenaMoraju se ugraditi kontrolni mehanizmi koji obezbjeuju da ne postoji polje ije vrijednosti prekorauju dozvoljene granice. Referentni integritetRelacije u modelu podataka se pretvaraju u tabele preko stranih kljueva.d) odreivanje uloga,e) izrada prototipa DB,f) planiranje kapaciteta DB ig) generisanje strukture DB.Dizajn i izrada prototipa ulaza u IS

Dizajn i izrada prototipa ulaza u IS obuhvata:a) metode i zahtjeve za obuhvatanje podataka i ulaze,b) kontrole grafikog korisnikog interface-a za dizajn ulaza ic) nain izrade prototipa i dizajniranje ulaza u IS.a) Metode i zahtjevi za obuhvatanje podataka i ulazeNajprije treba definisati osnovne pojmove u vezi ulaza u IS. Razlikuju se obuhvatanje podataka (data capture), ulaz podataka (data entry) i unos podataka (data input). Osnova za ovu podjelu je proces stvaranja podataka.Obuhvatanje podataka je identifikacija podataka koje treba unijeti u raunar. Najbolje je da se podaci unesu odmah posle njihovog deavanja. Drugo rjeenje je obuhvatanje podataka sa izvornih dokumenata (source documents) u obliku zapisa na papiru ili nekom drugom medijumu.Ulaz podataka je proces pretvaranja izvornog dokumenta u format koji raspoznaje raunarski sistem, u formatu spremnom za smjetanje na magnetni disk, traku, optiki disk i slino.Unos podataka je fiziki ulaz podataka, formata koji raspoznaje raunarski sistem, u odgovarajuu memoriju raunarskog sistema. Unos podataka moe biti: on - line ili paketski (batch input).

Paketski unos podataka je najstariji metod unosa podataka sa tastature - na disk (key-to-disk: KTD) i sa tastature-na-traku (key-to-tape: KTT). Zatim se unos preispituje sa aspekta tanosti, koriguju greke unosa i nakon toga prebacuju iz buffer memorije u odgovarajuu spoljnu memoriju.On - line unos praktino predstavlja obuhvatanje podataka sa izvora i direktan ulaz (u zahtjevanom formatu) u raunarski sistem. U ovom sluaju nisu potrebni operatori za unos podataka. Praenje unosa podataka vri se preko odgovarajueg grafikog korisnikog interface-a. (GUI).Kompromisno rjeenje izmeu on - line i paketskog unosa podataka je unos paketa preko komunikacionog sistema. U ovom sluaju preko mikroraunara se ostvaruje on - line unos, a zatim se ovako dobijeni paketi podataka obrauju preko centralnog raunara.

b) Kontrola grafikog korisnikog interface-a za dizajn ulazaZa unos podataka kod savremenih programskih sistema (npr. kod Visual Basic-a) koristi se grafiki korisniki interfejs umesto klasinog dizajniranja ekrana preko teksta sa poljima za unos podataka. Kontrola ovako unijetih podataka ostvaruje se pomou: prozora (box) za tekst (kada podaci imaju promjenljivu duinu i kada se ne zna unaprijed sadraj teksta), krugova za izbor opcija, prozora za provjeru, prozora za listanje podataka (opcija), padajuih lista, kombinovanih prozora sa elementima prozora za tekst i listanje i prozora sa strjelicama za pretraivanje unazad i unaprijed.c) Nain izrade prototipa i dizajniranje ulaza u ISPri dizajniranju ulaza u IS dizajner se fokusira na identifikaciju potrebnih ulaznih podataka, a u drugoj fazi dizajnira potreban GUI, da bi u treoj fazi izradio prototip ulaznog ekrana i u etvrtoj fazi dizajnirao ili izradio prototip izvornog dokumenta (ovo je opcionalno).Dizajn i izrada prototipa izlaza iz IS

Izlazi (outputs) iz IS mogu biti eksterni, povratni i interni.Eksterni izlazi (external outputs) su oni izlazi koje koriste sistemi primaoci za donoenje svojih odluka. Primjeri za ovo su bording karta, telefonski rauni, fakture itd.Povratni izlazi (tarnaround outputs) su oni izlazi koji se mogu koristiti kao ulazi za kasniju obradu (npr. za izradu naknadnih statistikih izvjetaja).Interni izlazi (intenal outputs) su izlazi koji ostaju unutar sistema kao podrka za rad korisnika i menadera, a posebno za potrebe izvjetavanja i podrke odluivanju. Razlikuju se tri vrste izvjetaja: detaljni izvjetaj, sumarni izvjetaj i izvjetaj o izuzecima.

Formati i vrste izlaznih medija su vrlo razliiti, to zavisi od primjenjenih izlaznih ureaja (printeri, mikrofilm, terminali). Pri tome se pod medijumom podrazumijeva nosilac informacija (papir, video ureaj), a pod formatom nain prikazivanja informacija na medijumu (npr. kolone brojeva). Poslednjih godina koriste se alternativni medijumi (alternative medio) za prikazivanje informacija.Dizajn i izrada prototipa korisnikog interface-a

Dizajn korisnikog interface-a je specifikacija konverzacije izmeu korisnika i raunarskog sistema. Konverzija se ostvaruje ulazom i/ili izlazom podatka. Korisniki interface moe biti dizajniran preko menija, seta instrukcija, dijaloga pomou pitanja i odgovora i/ili direktnom manipulacijom podataka.a) Izbor menija

Izbor menija (menu selection) je nain dizajna dijaloga po kome se korisniku daje lista alternativa ili opcija. To je najstariji nain jer koristi slova ili rijei za oznaavanje opcija.b) Set instrukcijaUmjesto menija ili zajedno sa menijem kod nekih klasinih aplikacija koristi se dijalog na osnovu seta instrukcija (instruction set), koji se naziva komandni jeziki interface. Pri tome se koristi tri tipa sintakse naredbi pomou:1. strukturiranog engleskog jezika,

2. mnemotehnike sintakse i

3. sintakse prirodnih jezika koja ima tendenciju rasta zbog primene ekspertnih sistema.

c) Dijalog pomou pitanja i odgovoraOvaj nain dizajna korisnikog interface-a se koristi kao dopuna dijalogu pomou menija ili seta instrukcija. Posebno je popularan kod dizajna interface-a sa monitorom bez ikona, koje koriste raunari starije generacije i mainframe raunari.d) Direktna manipulacija podacimaOvo je najnoviji i najpopularniji tip korisnikog interface-a koji dozvoljava da se vri direktna manipulacija grafikim objektima koji se pojavljuju na ekranu. Sutina je da dizajner korisnikog interface-a ima danas na raspolaganju mogunost grafike kontrole i uspostavljanja logikih odnosa u toku dijaloga.Dizajn softvera

U fazi studije sistema, dizajn sistema je skoro zavren jer su u okviru te faze dizajnirani DB, ulazi, izlazi i korisniki interface. Takoe, izabrana je i instalirana raunarska oprema (hardver, sistemski softver i pomoni programi). Ostalo je jo da se izvri dizajniranje softvera.Ovdje se pod dizajnom softvera ne podrazumijeva logiki, ve fiziki dizajn softvera. Fiziki dizajn softvera obuhvata: formiranje programskih specifikacija (programskih zadataka po ranije koritenoj terminologiji) i neposredno programiranje (kodiranje po ranijoj terminologiji) i testiranje programa.Ovdje e se razmatrati dizajn softvera samo u smislu programskih specifikacija, jer je programiranje predmet posebnih kurseva. Posmatrano u ovom smislu, dizajn softvera se sastoji iz dvije komponente i to: modularnog dizajna (modular design), kao dekompozicije programa u module (subrutine ili potprograme), kao grupe izvnih instrukcija koje se zajedno pojavljuju na ulazu i izlazu iz softvera i

integracije (packaging) specifikacije podataka, procesa, interface-a i komunikacije u okviru svakog modula.Strukturirani dizajnStrukturirani dizajn je najpopularnija tehnika modularnog dizajna razvijena za mainframe bazirane aplikacije poetkom 80 - tih godina (Ed Yourdon, Larry Constantine). Korienjem ove tehnike sloeni i veliki programi se dijele u hijerarhijski ureene module. Time se dobija program koji se lake primjenjuje i odrava. Osnovni alat, koji se koristi u strukturiranom dizajnu, je mapa strukture (structure chart) koja pokazuje nain segmentacije programa u module.

U tehnici strukturiranog dizajna pomou dijagrama toka podataka (DFD) opisuje se tok programa. Ranije opisani DFD se mijenja, tako da opisuje vie detalja.Analiza transformacije je ispitivanje DFD u cilju podjele procesa na one koji obavljaju ulaz i editovanje, one koji obrauju ili transformiu podatke (npr. proraunavanje) i one koji stvaraju izlaze.Analiza transakcija (transaction analysis) je drugi nain za dobijanje mapa strukture. Pri tome se preispituje DFD u cilju identifikacije procesa koji predstavljaju centre transakcija. Pod centrom transakcija (transaction center) podrazumijeva se proces koji u stvarnosti ne vri transformaciju ulaza, ve slui za preusmjeravanje podataka u razliitim pravcima. Ovaj nain dobijanja mapa strukture podravaju savremeni on - line sistemi i to sa veim brojem nivoa transakcija.

Za provjeru kvaliteta je razvijena metrika na osnovu veliine spregnutosti i kohezije modula.Spregnutost (coupling) je mjera zavisnosti izmeu modula. Razlikuju se spregnutost podataka izmeu modula, slogova podataka, kontrolnih informacija ili zastavica, zajednikih globalnih resursa (npr. kod jezika tree generacije kao to je COBOL) i sadraja (jedan modul moe modifikovati proceduralni sadraj drugog modula).Kohezija (cohesion) je druga mjera kvaliteta programa. Razlikuju se funkcionalna kohezija (instrukcije iz dva modula su povezane u cilju izvravanja zajednikog zadatka), sekvencijalna kohezija (izlaz postupka iz jednog modula je ulaz u drugi), komunikaciona kohezija (realizacija zadataka na daljinu za svaku aktivnost posebno), proceduralna kohezija, temporalna kohezija, logika kohezija i koincidentalna kohezija.Specifikacije programskog paketa

Koristei tehnike dizajna datih u prethodnom tekstu, definie se kompletna specifikacija programa koja se stavlja programeru na raspolaganje. To se naziva iskaz o tehnikom dizajnu softvera (technical design statement).Objektno orijentisani dizajnU fazi objektno orijentisane analize izvrena je identifikacija objekata koji predstavljaju aktuelne podatke i metode koje se primjenjuju nad tim podacima pri realizaciji poslovnih aktivnosti. Ovi objekti se nazivaju objekti entiteta (entity objects).U fazi objektno orijentisanog dizajna vri se "fina" analiza objekata entiteta, pri emu se identifikuju drugi tipovi objekata koji se uvode kao rezultat primjene odluka u praksi. To su objekti koji nastaju u interface-u korisnik - raunar, pa se nazivaju objekti interface-a (interface objects).Sledei tip objekata reprezentuje pravila odluivanja pa se nazivaju objekti kontrole (control objects). Na taj nain su svi objekti sistema podijeljeni u tri grupe (prema Ives Jacobson-u), to ini ovaj pristup slinim pristupu u Smalltalk programskom sistemu. Odravanje softvera je olakano jer su objekti jednostavniji i lake se njima upravlja ili kontrolie.Primjena informacionog sistema

Primjena informacionog sistema obuhvata izgradnju (konstrukciju) novog sistema i putanje u rad (svakodnevni rad sistema).U ovoj fazi se podaci, procesi, interface-i i komunikacije posmatraju iz ugla programera (system builders).Na slici 2. prikazane su fizike faze primjene IS i to faza izgradnje (konstrukcije) i faza putanja u rad IS.

Slika 3. Faze primjene ISFaza izgradnje (konstrukcije) u primeni IS-aZadatak faze izgradnje je: izgradnja i testiranje funkcionalnosti sistema (da li ispunjava zahtjeve poslovanja i dizajna) i primjena interface-a izmeu novog sistema i postojeeg proizvodnog informacionog sistema (produkcionog IS).U ovoj fazi projektni tim mora izgraditi DB, aplikativne programe, korisniki i sistemski interfejs i mreu.Faza isporuke u primjeni IS-a

Ovo je poslednja faza u ivotnom ciklusu IS, tj. stavljanje IS u pogon.Ulazi u ovu fazu su softverski paketi, programi korisnika, postojei programi i test podaci, a izlazi modifikacije na programima i iskaz o testu sistema.Sistemska podrka

Sistemska podrka (systems support) obuhvata aktivnosti odravanja sistema posle njegovog stavljanja u pogon, iz ega se vidi da je time obuhvaeno odravanje programa i unaprjeenje sistema. Ove aktivnosti ine i vie od 60% aktivnosti sistem analitiara, projektanta i programera.Razmatramo najprije odravanje programa (aplikacija), koje se vri stalno posle faze primjene (implementacije). Kae se da se aplikativni softver nalazi u produkciji kada je u stalnom radu, bilo da je to svakodnevna, nedeljna, mjesena ili druga frekvencija njihovog koritenja. Pri tome se koriste etiri razliita tipa DB: centralna DB za modele sistema i specifikacije, biblioteka programa, DB projekata i DB za poslovne aplikacije.Odravanje IS-a

Odravanje IS-a podrazumijeva otklanjanje greaka (nedostataka) u radu sistema to se opisuje pojmom produkcija. Ciljevi odravanja sistema su: ostvarivanje planiranih izmjena na postojeim programima radi korekcije greaka uinjenih u fazi dizajna i/ili implementacije, pri emu se iskljuuju poboljanja i novi zahtjevi i

ostvarivanje veze izmeu programa.Ostvarivanje ovih ciljeva zahtjeva stalno preispitivanje procesa, podataka, interfejsa, lokacija i tehnologija.Obnavljanje IS- a

IS kao sloen i dinamian sistem je podloan nepredvienim otkazima, usled ega moe doi do gubitka programa, podataka ili oteenje cijelog sistema. Zbog toga je potrebno povremeno, ali u tano definisanim rokovima, vriti aktivnosti obnavljanja (recovery) kojima se prevladava krah (crach) sistema.Reinenjering IS-a

U toku projektovanja i odravanja IS mogu se javiti novi poslovni zahtjevi koji mogu uticati na vlasnike sistema da pokrenu proces prilagoavanja novim zahtjevima. To se ostvaruje poboljanjem ili reinenjeringom postojeeg IS.

Standardi kvaliteta u razvoju, isporuci i odravanju softvera

Eksplozivan razvoj softvera poslednjih decenija i njegova sve intenzivnija primjena zahtjevali su da se posveti znaajna panja kvalitetu softvera. Meunarodna organizacija za standardizaciju (ISO) razvila je standarde za kvalitet softvera u fazama razvoja, isporuke i odravanje softvera.Softver se definie kao intelektualna usluga koja obuhvata programe, postupke, pravila i svu pripadajuu dokumentaciju neophodnu za rad sistema za obradu podataka, nezavisno od medija na kojem je zapisan.Softverski proizvod se definie kao zaokrueni skup raunarskih programa, postupaka i pridruene dokumentacije i podataka namijenjenih za isporuku korisniku.Softverski element je bilo koji identifikovani dio softverskog proizvoda u meufazi ili konanoj fazi razvoja.Razvoj obuhvata sve aktivnosti koje se sprovode da bi se napravio softverski proizvod.Faza je definisani segment rada, nezavisno od modela ivotnog ciklusa ili perioda razvoja softverskog proizvoda.Verifikacija softvera je proces ocjene softvera u datoj fazi, da bi se obezbjedila ispravnost i potpunost u odnosu na proizvode (softvere) i standarde koji su bili ulaz u tu fazu.Ocjenjivanje softvera je proces ocjene softvera da bi se obezbjedila usklaenost sa definisanim zahtjevima.

Slika 4. Struktura zahtjeva standarda u razvoju, isporuci i odravanju softveraOvaj segment definie sistem kvaliteta na osnovu odgovornosti rukovodstva isporuioca softvera, kupca i zajednikih preispitivanja, kao i nain uspostavljanja i odravanja sistema kvaliteta.U ovoj seriji standarda insistira se na odgovornosti isporuioca softvera (PRVI SEGMENT) da obezbjedi sve resurse za uspjean razvoj, isporuku i odravanje softvera. Zbog specifinosti softverskih proizvoda, preispitivanje vre isporuilac i kupac nezavisno i zajedniki, pri emu se: utvruje usklaenost softvera sa specifikacijama, verifikuju rezultati preispitivanja i dokumentuju rezultati preispitivanja radi prihvatanja od druge strane.DRUGI SEGMENT odnosi se na zahtjeve sistema kvaliteta u pogledu dokumentacije sistema kvaliteta, plana kvaliteta, naina vrenja internih provjera sistema kvaliteta i kolektivnih mjera.TREI SEGMENT odnosi se na aktivnosti u ivotnom ciklusu softvera, ijom kontrolom realizacije istih se utie na kvalitet softvera. Pri tome su posebno znaajne aktivnosti: preispitivanje ugovora sa aspekta elemenata ugovora koji se odnose na kvalitet (kriterijumi prihvatanja, promjena zahtjeva za vrijeme razvoja itd.), specifikacije zahtjeva kupca u smislu funkcionalnih zahtjeva, zatite, pouzdanosti, tajnosti, saradnje itd.,

izradu plana razvoja softvera,

izradu plana kvaliteta, projektovanje i realizaciju softvera, ispitivanje i ocjenjivanje, koje se vre od nivoa modela (softverskog elementa) do kompletnog softverskog proizvoda, prihvatanje softverskog proizvoda od strane kupca, a na osnovu prethodno dogovorenih kriterijuma i ugovornih obaveza, to se dokumentuje na ugovoreni nain, umnoavanje kopija, njihova isporuka i ugradnja, odravanje softvera.ETVRTI SEGMENT se odnosi na pomone aktivnosti, koje se ostvaruju nezavisno od faza. On obuhvata osam grupa aktivnosti:Prva grupa aktivnosti odnosi se na upravljanje konfiguracijom sistema. To je mehanizam za identifikovanje, kontrolisanje i praenje verzija svakog softvera. Druga grupa aktivnosti odnosi se na kontrolu dokumentacije za svaku fazu razvoja softverskog proizvoda, sa definisanim postupcima za odobravanje i izdavanje dokumenata, izmjenu dokumenata i zapise o kvalitetu.Trea grupa aktivnosti je mjerenje proizvoda i mjerenje procesa za utvrivanje mjere kvaliteta procesa razvoja i isporuke softvera.etvrta grupa aktivnosti odnosi se na pravila, praksu i konvencije u procesu razvoja, koji treba da su zajedniki za sve uesnike u razvoju softvera.Peta grupa aktivnosti odnosi se na koritenje pogodnih metoda i alata da bi sistem kvaliteta za dobijanje i ugradnju softvera bio efikasan i efektivan.esta grupa aktivnosti se odnosi na nabavku softverskih proizvoda ukljuenih u isporueni softver, pri emu se vri ocjenjivanje podugovaraa i ocjenjivanje nabavljenog softverskog proizvoda.Sedma grupa aktivnosti odnosi se na zahtjev kupca ili tree strane da isporuilac ukljui ili koristi softverski proizvod, pri emu provjera ispravnosti od strane isporuioca ne oslobaa naruioca odgovornosti da obezbjedi prihvatljiv proizvod.Osma grupa aktivnosti odnosi se na struno osposobljavanje osoblja isporuioca kako bi udovoljio novim i sve veim zahtjevima kupaca softvera.Funkcija ili aktivnost

Kontrole

Izlazi

Ulazi

Resursi

Slika 1.

Osnovni elementi grafikog predstavljanja aktivnosti IDEF0

PAGE 14