RAZVOJ I PRIMJENA INFORMACIJSKIH SUSTAVA

Zagreb, 2012

Sadržaj B.1 Proces i metode razvoja sustava...............................................................................................1

B.1.1 Softver u sustavima za obradu podataka..........................................................................1 B.1.2 Životni ciklus razvoja sustava..........................................................................................4

B.1.2.1 Vodopadni model......................................................................................................6 B.1.2.2 Prototipni model.......................................................................................................7 B.1.2.3 Spiralni model...........................................................................................................8 B.1.2.4 Iterativno inkrementalni model..............................................................................10 B.1.2.5 Brzi razvoj aplikacija..............................................................................................12 B.1.2.6 Formalni Model......................................................................................................14 B.1.2.7 ESA Razvojni modeli ............................................................................................15 B.1.2.8 Dokumentiranje razvoja sustava ............................................................................17

B.1.3 Alati za razvoj sustava...................................................................................................19 B.1.4 Testiranje i uvođenje sustava .........................................................................................22 B.1.5 Kontrola i sigurnost sustava .........................................................................................25 B.1.6 Trendovi u razvoju sustava ...........................................................................................27

B.1.6.1 ISO Standardi ........................................................................................................27 B.1.6.2 IEEE .......................................................................................................................29 B.1.6.3 SEI/CMMI .............................................................................................................30 B.1.6.4 SIX SIGMA ...........................................................................................................31 B.1.6.5 Agilne metodologije ...............................................................................................33 B.1.6.6 Arhitektura aplikacija..............................................................................................35

B.1 Proces i metode razvoja sustava

B.1.1 Softver u sustavima za obradu podataka

Obrada podataka je proces pretvorbe podataka u korisne informacije i znanje. Sustav u kojem se takva obrada vrši naziva se sustav za obradu podataka (SOP) i prikazan je IPO-S1 modelom.

Postupak obrade podataka uključuje korak pretvorbe ulaznih podataka iz oblika koji sustav može interpretirati, korak obrade ulaznih podataka i kao završni korak pretvorbu obrađenih podataka u željeni izlazni oblik (audio, video, tekst, brojevi, ...).

Računalni sustav za obradu podataka sastoji se od hardvera i softvera. Fizički dijelovi računala, uključivši i elektroničke dijelove čine hardver računala koji je postojan u odnosu na softver u računalu, jer se softver često mijenja, dodaje ili briše. Prefiks soft opisuje osobinu promjenjivosti. Ugrađeni softver ili firmware je posebna je vrsta softvera koji se rijetko ili nikada ne mijenja, a pohranjen je u memorijskim uređajima koje nisu dizajnirani za česte izmjene podataka ili za izmjene uopće (ROM, PROM, EPROM, ...) Prefiks firm opisuje osobinu postojanosti.

Softver se dijeli u dvije osnovne skupine sistemski softver i aplikacijski softver. Sistemski softver je softver odgovoran za kontrolu i upravljanje hardverom na način da se aplikacijski softver može izvršavati na nekom hardveru. Glavni predstavnici sistemskog softvera su operacijski sustavi kao što su Windows, Unix, Linux, Solaris, QNX, VxWorks. S druge strane, aplikacijski softver je softver koji pruža specifičnu uslugu krajnjem korisniku sustava, kao što su obrada teksta ili multimedija.

Sistemski softver obavlja zadatke kao što je prijenos podataka između diska i memorije, prikaz teksta ili grafike na zaslonu, upravljanje memorijskim resursima i procesima. Posebna vrstu sistemskog softvera čine programi za pokretanje operacijskog sustava, pogonski programi (engl. device drivers), tzv. utility programi.

Softverske biblioteke koje pružaju opću funkcionalnost programima, također se mogu smatrati sistemskim softverom (npr. gnu c/c++ biblioteka), dok situacija nije u potpunost i jasna kod npr.

1 IPO+S- Input-Processing-Output ( + Storage) model

1

UL

AZ

OBRADA IZL

AZ

POHRANA

Slika 1: IPO+S model sustava za obradu podataka

PODATAK INFORMACIJA

OpenGL biblioteka ili biblioteka za rad s bazama podataka koje, s jedne strane, pružaju podršku programima,a s druge strane njihova primjena je specifična za neku aplikaciju.

Kad je softver pohranjen na nepromjenjivoj memoriji, tada govorimo o ugrađenom softveru (firmware). Pojam firmware prvi puta se javno spominje 1967. godine u časopisu za računala Datamation - termin se izvorno odnosio na sadržaj promjenljivog kontrolnog spremnika koji je sadržavao procesorski mikrokod (mikrokod definira i implementira instrukcije procesora na nivou mikrooperacija). Naknadno se definicija mijenja i podrazumijeva bilo koji tip sistemskog softvera koji se nalazi u memoriji samo za čitanje (ROM, PROM) ili izbrisljivoj memoriji (EPROM) . Danas termin opisuje bilo koji tip softvera pohranjen u flash memoriju.

Ugrađeni softver nalazi se između hardvera i ostalog softvera na računalu. S jedne strane, riječ je o programu koji se izvršava na nekom mikroprocesoru ili mikrokontroleru, dok s druge strane, usko je vezan uz hardver na kojem se izvršava i nema bitnu korist izvan tog okruženja.

ESCD ili Extended System Configuration Data dio je neizbrisive BIOS2 memorije (CMOS memorija) na matičnoj ploči računala, u kojoj su pohranjene informacije o ISA PnP uređajima (IRQ, memorijska područja korištenja, ...) .

Sadržaj ESCD memorije mijenja se svaki puta kada dolazi do promjene hardvera, npr. kada se

2 BIOS – Basic Input Output System

2

Slika 2: Hijerarhija softvera u informacijskom sustavu

promijeni struktura korištenja prekida (IRQ) ili memorijskih područja za neku hardversku komponentu na računalu. Jednom pohranjena konfiguracija ne mijenja se sve do iduće promjene hardvera što čini pokretanje računala bržim ( dodjela resursa se ne provjerava svaki put iznova, već se koristi konfiguracija iz ESCD memorije).

Sadržaj ESCD-a se može mijenjati pomoću posebnih alata kao što je npr. Windows Device Manager. Isto tako, proizvođači matičnih ploča i prijenosnih računala često nude aplikaciju kojom je moguće mijenjati sadržaj ESCD memorije na njihovom hardveru.

Unified Extensible Firmware Interface (UEFI) je specifikacija koja definira softversko sučelje između operacijskog sustava i ugrađenog softvera platforme. Namjena ovog sučelja je zamjena starog BIOS sučelja koje se koristi od vremena prvog IBM PC računala. Novo sučelje prilagođeno je suvremenim hardverskim arhitekturama i zaobilazi ograničenja starog BIOS sučelja.

Aplikacijski softver je softver koji koristi svojstva računala u svrhu izvršavanja specifičnog zadatka koji korisnik računala želi izvršiti. Za obavljanje neke specifične radnje, aplikacijki softver koristi resurse računala koja su dostupna putem sistemskog softvera.

Aplikacija računala razlikuje se u odnosu na operacijski sustav (na kojem se izvršava), namjenu (za koju je implementirana) i programskom jeziku ( u kojem je napisana ).

Ovisno o namjeni aplikacijski softver se može podijeliti u više skupina, a neke od njih su:

• Aplikacije opće namjene tekst procesori, tablični kalkulatori, prezentacijski programi , mail klijenti, web preglednici

• Izdavaštvo i multimedija obrada slika, audio/video sadržaja, prelom teksta, izrada multimedijalnog sadržaja

• Zabavni programi računalne igre, reprodukcija audio/video zapisa

• Profesionalni alati računalom potpomognut dizajn (CAD), statistička i numerička analiza, projekt menadžment

• Poslovne aplikacije ERP, CRM, Analiza tržišta, Upravljanje projektima

• Aplikacije posebne namjeneDizajnirane za specifičnu namjenu

Iako postoje tendencije, Razvojni softver ne predstavlja zasebnu skupinu softvera. U različitim publikacijama razvojni softver, kao što su: prevodelji (engl. compilers), povezivači (engl. linkers), programi za traženje grešaka (engl. debuggers) svrstava se malo u aplikacijski, malo u sistemski

3

softver. Npr. kod operacijskog sustava Linux, razvojno GNU okruženje sastavni je dio operacijskog sustava, a njegove biblioteke omogućuju normalno izvođenje aplikacijskog softvera. U tom slučaju, razvojni softver može se gledati kao sistemski softver, dok kod drugih operacijskih sustava i platformi, razvojni softver nije uvijek usko integriran s operacijskim sustavom i može ga se promatrati kao na aplikacijski softver s obzirom da pruža specifičnu namjenu korisniku (programeru).

B.1.2 Životni ciklus razvoja sustava

Informacijski sustav (softver) predstavlja proizvod ili rezultat razvoja sustava. Razvoj sustava dijeli se u više faza koje uključuju postupke planiranja, analize, dizajna, razvoja, testiranja, uvođenja i održavanja sustava. Glavni cilj razvoja je razviti sustav koji zadovoljava potrebe njegovih korisnika.

Prvi korak kod dizajna novog sustava je korak planiranja. On uključuje analizu domene sustava radi boljeg razumijevanja što bi budući sustav trebao raditi. U tom postupku provodi se analiza sustava slične namjene u cilju utvrđuju karakteristična svojstva za sustave tog tipa.

Idući korak, i jedan od najvažnijih koraka pri stvaranju informacijskog sustava, predstavlja analiza zahtjeva. Klijent (korisnik) često nema jasnu zamisao kakav sustav želi. Stoga je potrebno prepoznati nepotpune, dvosmislene, a ponekad i kontradiktorne zahtjeve tražene od strane klijenta. Prilikom analize zahtjeva česta je praksa izgradnje prototipa sustava koji olakšava pronalaženje problematičnih zahtjeva i usaglašavanje nedoumica s klijentom.

Jednom kada su usuglašeni korisnički zahtjevi, potrebno je pokrenuti postupak analize kojim se definiraju svojstva sustava. U ovom postupku izrađuje se dokument u kojem se definira popis zahtjeva sustava koji će se implementirati. Isto tako, taj dokument sadrži popis traženih zahtijeva koji se neće implementirati i razloge (cijena, izvedivost i sl.). Dokument predstavlja dogovor

4

između klijenta i izvođača, i kao takav može poslužiti u eventualnom naknadnom sporu između dviju strana.

Dizajn je postupak u kojem se detaljno opisuje budući sustav. Najprije se definira generalna arhitektura budućeg sustava, a zatim se detaljno definira dizajn svake komponente sustava zasebno. U postupku dizajna sustava definiraju se konvencije, standardi i alati koji će se koristi tijekom razvoja sustava. Konvencije mogu definirati strukturu dokumenta, ali i način pisanja koda (npr. coding standard, secure coding standard3)

Razvoj sustava dio je razvojnog procesa u kojem programeri kodiraju budući sustav. To je prva faza projekta unutar koje jedan od izlaznih artefakata je i kôd budućeg sustava.

Jednom izgrađen sustav potrebno je testirati. Testiranje čini vrlo važnu ulogu prilikom razvoja sustava, jer omogućuje otkrivanje pogrešaka,a cilj je da se pogreške otkriju što je ranije moguće. Dio testiranja obavlja se već prilikom samog razvoja sustava (unit test) dok se u zasebnoj fazi testira sustav kao cjelina (integration test, sistem test).

Jednom testirani sustav spreman je za uvođenje. U toj fazi vrše se pripreme za uvođenje sustava koje uključuju pripremu dokumentacije, obučavanje budućih korisnika i osoblja koje će u budućnosti održavati sustav.

Jednom kada je sustav uveden kod klijenta ili krajnjeg korisnika, projekt prelazi u fazu održavanja. U toj fazi posebno obučeno osoblje stoji na raspolaganju klijentima u razrješavanju mogućih problema u radu sustava, a poseban tim razvojnih inženjera radi na otklanjanju mogućih nedostataka, ispravljanju pogrešaka i mogućoj nadogradnji sustava.

Nakon faze održavanja nadogradnja sustava i ispravci eventualnih pogrešaka više nisu mogući. Projekt tada dolazi u završno stanje, tzv. end-of-life, te ovisno o planovima stari sustav može se redizajnirati i pokrenuti novi razvojni ciklus.

Postupci i tehnike razvoja sustava

Postupci i tehnike razvoja sustava ovise o razvojnoj metodologiji. Metodologija razvoja sustava definira skup postupaka i metoda koje definiraju strukturu, plan i kontrolu procesa razvoja informacijskog sustava. Metodologija dijeli zadatke u više faza koje se mogu izvršavati linearno ili iterativno. Svaka faza ima definirane početne preduvjete, aktivnosti za vrijeme trajanja faze i konačne rezultate po završetku faze (deliverables, artefacts).

Postoji velik broj različitih metodologija za razvoj informacijskih sustava, no većina njih se zasniva se na jednom od slijedećih modela:

• Vodopadni (Waterfall)

• Prototipni

• Spiralni

• Inkrementalni

• Brzi Razvoj Aplikacija

• Formalni

3 http://www.cert.org/secure-coding/scstandards.html

5

Ne postoji najbolja metoda, već prikladnija. Prikladnost metode ovisi o različitim elementima projekta kao što su, npr. kompleksnost projekta, vrsta aplikacije, članovi tima (broj , iskustvo), iskustvo voditelja projekta i projekt menadžera, iskustvo klijenta s primjenom aplikacije, organizacijska struktura projekta, itd.

B.1.2.1 Vodopadni model

Predstavlja jedan od najstarijih razvojnih metodologija. Karakteristike metodologije su linearno izvođenje faza jedna za drugom, bez ponavljanja. Uvijek po završetku faze, pored ostalih rezultata, postoji neki oblik dokumenta koji opisuje izvršene zadatke. Na kraju svake faze obavlja se revizija dokumenata koja za posljedicu može imati reviziju i nekog drugog rezultata faze (dizajna, koda, ...)

Model je izvorno osmislio Winston W. Royce, 1970. godine. Izvorni model sastojao se od slijedećih faza:

• Specifikacija

• Dizajn

• Razvoj

• Integracija

• Testiranje

• Uvođenje

• Održavanje

Model je jednostavan za učenje što ga čini pogodnim za neiskusne članove tima i voditelje. Napredak razvoja sustava je mjerljiv, jer je kraj faze striktno definiran. Uređen slijed faza, striktna kontrola dokumentacije i revizije dizajna doprinosi kvaliteti, pouzdanosti i lakoći u održavanju sustava.

Glavni nedostaci modela su nefleksibilnost, sporost razvoja i veća cijena razvoja. Model je posebno osjetljiv o definiranim zahtjevima klijenata. Klijenti često ne znaju točno definirati zahtjeve u ranoj fazi projekta, a naknadna izmjena zahtjeva čini ovaj model neefikasnim. Ako se većina problema otkrije tek u fazi testiranja, znatno se povećavaju troškovi ispravka s obzirom da cijena ispravljanja pogrešaka raste s vremenom otkrivanja proteklim od faze analize. S obzirom da su izmjene u kasnim fazama razvoja skupe, one se često izbjegavaju što umanjuje funkcionalnost sustava. Struktura i sadržaj specifikacija kod ovog modela često su nerazumljive pa im je korisnost upitna.

• Prikladnost modela◦ Veliki i složeni projekti ◦ Projekti s jasnim ciljem ◦ Zahtjevi se ne mijenjaju tijekom životnog ciklusa ◦ Članovi tima i/ili voditelji su neiskusni ◦ Velika vjerojatnost fluktuacije članova tima ◦ Kod projekata s dislociranim timovima ◦ Korisnik je iskusan i razumije primjenu

6

• Neprikladan ◦ Projekti kod kojih zahtjevi nisu dobro specificirani ili se često mijenjaju ◦ Kod projekata gdje se traži brz razvoj sustava

B.1.2.2 Prototipni model

Nije potpuna metodologija, već pristup koji se primjenjuje kod većih, tradicionalnih metodologija (inkrementalne, spiralne, vodopadne, ... ) Kod ovog modela korisnik je uključen u razvojni proces za cijelo vrijeme njegovog trajanja. Model se zasniva na izradi prototipa sustava iterativnim postupkom sve dok se ne ispune zahtjevi korisnika.

Ovaj model pruža brzu izradu početnog sustava uz vrlo rano uočavanje nesporazuma na relaciji između klijenta i programera te usuglašavanja nejasnih ciljeva. Isto tako, pomaže brzom i jednostavnom identificiranju nejasnih te otkrivanju nepostojećih funkcionalnosti sustava. Vrlo je koristan za bolje modeliranje pojedinih aspekata sustava kod klasičnih metodologija. Model potiče inovativne ideje i omogućuje brz razvoj nepotpunog, ali funkcionalnog sustava.

Glavni nedostaci modela predstavljaju procesi potvrde i kontrole koji nisu striktni, kao ni dokumentiranje. Mogućnost čestih i znatnih promjena zahtijeva može rezultirati neefikasnošću i kašnjenjem izrade konačnog proizvoda. Izrada prototipa uglavnom daje naglasak na one vidljive dijelove sustava, što može dovesti do krivog očekivanja klijenta koji može biti (krivo) uvjeren da je sustav gotov, iako to nije.

Ovisno u implementaciji detalja kod prototipa, razlikuju se horizontalni i vertikalni prototipovi prototipa. Horizontalni prototipovi djelomično implementiraju svu funkcionalnost sustava, ali samo one vidljive dijelove. S druge strane vertikalni prototipovi ne implementiraju sve funkcionalnosti već samo neke, ali u potpunosti.

Izrada prototipova karakteristična je za sve grane industrije, no kod razvoja informacijskih sustava postoje određeni oblici koji se razlikuju po svojim svojstvima:

• Brza izrada prototipova (prototip “napravi i baci”)

◦ Izradu prototipa koji služi za bolje definiranje zahtijeva, a čija namjena nije integracija u budući sustav

• Evolucijska izrada prototipova

◦ Izrada robusnog prototipa s namjenom poboljšavanja i kasnijom integracijom u budući sustav

• Inkrementalna izrada prototipova

◦ Izrada odvojenih prototipova koji se u konačnici spajaju zajedno u jedan sustav.

• Ekstremna izrada prototipova

◦ Specifična metodologija za izradu web stranica podijeljena u 3 faze. U prvoj fazi izrađuju se statički elementi stranice (HTML sadržaj), a zatim se kreće u izradu programa za upravljanje stranica, ali uz simuliranje implementacije servisa. U zadnjoj fazi u potpunosti se implementiraju servisi.

• Prikladnost modela◦ Projektni zahtjevi su nejasni

7

◦ Postoji želja za brzom implementacijom ◦ Česta izmjena funkcionalnosti ◦ Korisnik ne posjeduje dovoljna znanja o projektu ◦ Članovi razvojnog tima su vrlo iskusni ◦ Voditelj projekta je iskusan ◦ Ne traži se inovativan i fleksibilan dizajn koji je prigodan kasnijim izmjenama ◦ Veliki projekt s mnogo korisnika i s velikim brojem funkcionalnosti◦ Kada se žele minimalizirati rizici prilikom definiranja zahtijeva

• Neprikladan ◦ Velikih (mainframe) sustava ◦ E-business sustava ◦ Struktura razvojnog tima nije stabilna ◦ Kada postoji potreba za budućom skalabilnosti sustava ◦ Ciljevi su jasni i ne postoje veći izvori rizika povezani s definiranjem zahtijeva

B.1.2.3 Spiralni model

Model je izvorno predstavio Barry Bohem – 1986g. On predstavlja kombinaciju linearnog i iterativnog modela u kojem se analiza rizika vrši tijekom čitavog trajanja projekta. Podjelom projekta na male dijelove omogućuju se lakše izmjene sustava tokom trajanja projekta, uz minimalizaciju rizika. Svaka iteracija opisana je petljom spirale u kojoj su definirani zadaci specifični za tu petlju. Trajanje izvođenja jedne petlje određuje se zasebno, no u izvornom modelu svaka petlja trajala je od 6 mjeseci do 2 godine.

8

Slika 3: Spiralni model razvoja sustava

Počevši od ishodišta, svaka petlja(iteracija) prolazi kroz 4 radna područja (kvadranta) unutar kojih se vrše slijedeće grupe zadataka:

• Definiranje ciljeva• Identifikacija i upravljanje rizicima• Razvoj i testiranje• Planiranje iduće iteracije

Implementacija metodologije sastoji se od izvođenja niza zadataka za svaku iteraciju. • Iteracija 1

◦ definiranje koncepta rada sustava• Iteacija 2

◦ specifikacija zahtjeva sustava• Iteracija 3

◦ izrada koncepta sustava• Iteracija 4

◦ finalni dizajn i implementacija

Analiza zahtjeva ponavlja se kroz više iteracija i kroz različita radna područja. Svaka iteracija završava izradom prototipa. Na kraju svake iteracije vrši se planiranje za iduću na osnovu stečenih znanja iz tekuće iteracije. Za veći broj implementacija sustava, cijela spirala može se izvršiti više puta.U početnoj implementaciji, autor metodologije (Barry Bohem) uključio je i "iteraciju 0" u kojoj se izrađivala studija izvedivosti, no ta iteracija nije namijenjena u standardnoj implementaciji.

Pozitivna strana ovog modela predstavlja napredno upravljanje rizicima. Isto tako, model je koristan kod odabira najbolje metodologije za pojedinu iteraciju razvoja (ovisno o riziku). Može koristiti vodopadnu, prototipnu ili inkrementalnu metodologiju tijekom pojedinog ciklusa.

Problem modela predstavlja složenost određivanja pojedine metodologije za svaki ciklus/iteraciju, a jednom kada se ona odredi model postaje usko prilagođen samo za taj projekt. To ga čini neiskoristivim u drugim projektima. Kod implementacije ovog modela voditelj projekta treba znati kako primijeniti metodu na pojedini projekt. Neadekvatnom primjenom može se desiti da se model u konačnici svede na klasični vodopadni model, što nije poželjno. Model ne definira čvrste rokove, ne postoji uvjet završetka pojedinog ciklusa i to čini važne nedostatke.

• Prikladnost modela ◦ Sustavi za rad u realnom vremenu ◦ Sustavi visokog stupnja sigurnosti ◦ U projektima gdje minimalizacija resursa nije glavni prioritet ◦ Iskusan voditelj projekta ◦ Kod projekata gdje se traži visok stupanj točnosti

• Neprikladan ◦ Ako je minimalizacija resursa prioritet ◦ Ako analiza rizika nije prioritet ◦ Kod projekata gdje se ne traži visok stupanj točnosti ◦ Ako funkcionalnost ima prednost nad implementacijom

9

B.1.2.4 Iterativno inkrementalni model

Iterativni i inkrementalni razvojni model pokušava ispraviti slabosti klasičnog vodopadnog modela. Iako se pojmovi iterativni i inkrementalni koriste kao sinonimi, riječ je o terminima koji definiraju različite pristupe razvoja.

Inkrementalni razvoj opisuje razvojnu strategiju kod koje se dijelovi sustava razvijaju u različitim vremenskim periodima ili intervalima, a integriraju se u cjelovit sustav kada su gotovi. Ova strategija ne definira razvojnu metodologiju, već predstavlja alternativu tzv. "big-bang" integraciji sustava kod koje se sustav odjednom, a ne u koracima, spaja u jedinstvenu cjelinu.

Iterativni razvoj odnosi se na razvoj sustava u više koraka, omogućujući ponavljanje jedne ili više faza razvojnog ciklusa. Zasniva se na ideji da se početno razvije mali dio većeg sustava, koji se zatim proširuje korak po korak. Takav pristup omogućuje programerima i budućim korisnicima da ranije uoče potrebne nedostatke te brzo omoguće nove izmjene na implementaciji sustava.

Iterativni razvoj čine serije mini-vodopadnih iteracija koje se ponavljaju određen broj iteracija. Cijeli projekt se početno razbija na niz jednostavnijih segmenata koji se periodički integriraju u sustav. Rana implementacija početne verzije sustava daje mogućnost ranog usuglašavanja s klijentom i budućim korisnicima sustava.

Primjer iterativno inkrementalnog modela su Unified Process metodologije. Ove metodologije dijele životni ciklus na 4 osnovne faze koje se mogu podijeliti u više iteracija.

• Početak(inception)

◦ Definiranje korisnosti, izvedivosti, rizika i projektne strukture

• Razrada(elaboration)

10

Slika 4: Faze UP razvojnog procesa

◦ Analiza sustava i definiranje razvojne arhitekture

• Razvoj(construction)

◦ Razvoj na osnovu prethodno definiranog dizajna i testiranje komponenti i sustava u cijelini

• Tranzicija(transition)

◦ Utvrđivanje prihvatljivosti rješenja i isporuka sustava

Unutar svake iteracije provode se različite discipline zadataka, različitim intenzitetom. Na slici 4 prikazana je metodologija koja definira ukupno 9 disciplina i grafički je prikazan intenzitet rada na pojedinim disciplinama ovisno o fazi projekta. Za razliku od gore prikazane metodologije, metodologija OpenUP definira slijedeće discipline:

• Arhitektura – kako razviti arhitekturu sustava iz prikupljenih zahtjeva. • Razvoj – kako dizajnirati i razviti tehničko riješenje sukladno definiranoj arhitekturi i

definiranim zahtjevima• Projekt menadžment – kako voditi i potpomagati tim, pomažući mu kod susretanja s

problemima i kod upravljanja rizicima• Upravljanje zahtjevima – kako otkriti, analizirati, specificirati, verificirati i rukovati

zahtjevima sustava• Testiranje – kako odrediti zrelost sustava dizajnom, implementacijom, izvođenjem i

vrednovanjem testova

Svaka od gore navedenih disciplina ima definirane zadatke koji su namijenjeni određenim članovima tima, ovisno o funkciji koju imaju na projektu. UP metodologije definiraju skupinu funkcija (uloga) za svakog člana tima uključenog u razvoj sustava. Tako npr. OpenUP metodologija definira slijedeće uloge za članove tima.

• Analitičar• Arhitekt• Razvojni inženjer• Projekt menadžer• Tester• Stakeholder4

Iterativno inkementalne metodologije omogućuju korištenje iskustva iz prethodnih iteracija kako bi ispravile pogreške ili poboljšale rad sustava. Metodologija definira određen skup dokumenata za koje se koriste postupci revizije, čime se pruža umjerena kontrola tijekom čitavog trajanja projekta. Postepena implementacija sustava omogućuje praćenje utjecaja pojedinih inkremenata i izoliranje eventualnih problema.

Problem kod ovih metodologija mogu nastati ako se teži poslovi odgađaju u kasnije inkremente da bi se pružili rani pozitivni rezultati menadžmentu. To u konačnici daje krivi uvid u trenutni napredak razvoja. Važno je da se početno dobro definiraju sučelja među komponentama jer se komponente ne razvijaju uvijek u istim inkrementima. Ponekad, rad u inkrementima može dovesti do manjka razumijevanja rada cjelokupnog sustava, kada se poslovi fokusiraju samo na pojedini inkrement.

4 Član interesni skupine ljudi vezane uz razvoj projekta (korisnik, kupac, programer, projekt menadžer, ... )

11

• Prikladost modela◦ Veliki projekti gdje zahtjevi nisu razumljivi, ili su podložni čestim promjenama ◦ Veliki projekti kojima se često mijenja budžet ili tehnologija ◦ Web servisi ◦ Visoko kvalitetne aplikacije

• Neprikladan ◦ Vrlo mali i kratkotrajni projekti ◦ Mali integracijski i arhitekturalni rizici ◦ Interaktivni sustavi kod kojih barem djelomično postoji projektni podaci

Predstavnici

• Unified Process

◦ Agile UP

▪ http://www.ambysoft.com/unifiedprocess/agileUP.html

◦ Enterprise UP

▪ http://www.enterpriseunifiedprocess.com/

◦ Open UP

▪ http://epf.eclipse.org/wikis/openup/

◦ Oracle UM

▪ http://www.oracle.com/us/products/consulting/resource-library/oracle-unified- method-069204.pdf

◦ Rational UP

• Feature Driven Develpment

◦ http://www.featuredrivendevelopment.com/

• Scrum

◦ http://www.scrum.org

• eXtreme Programming

◦ http://www.extremeprogramming.org

B.1.2.5 Brzi razvoj aplikacija

Model brzog razvoja aplikacija (RAD5) omogućuje vrlo brzi razvoj sustava visoke kvalitete uz

5 Rapid Application Development

12

pomoć korištenja CASE alata. Na uštrb detaljnom planiranju, uz podjelu poslova na kraće vremenske odsječke, izrađuju se inkrementalni prototipovi. Projektni rizici smanjuju se podjelom projekta na manje cjeline. Poseban naglasak daje se na želje korisnika, a manje na dizajn sustava. Kod isporuke sustava poseban naglasak je na poštivanje rokova (bolje smanjiti broj funkcionalnosti koje će se implementirati, nego odgoditi rok isporuke) . Model se služi standardnim tehnikama analiza i dizajna te prakticira izradu dokumentacije radi lakše nadogradnje i održavanja sustava.

Ovaj model prvi puta uspješno je primijenjen 1970. u tvrtci (NewYork Telephone Co – Dan Giealn), 1990. prvi puta je opisan u knjizi (James Martin),a nastao je kao odgovor na probleme prethodnih (linearnih) metodologija koje nisu uspijevale upravljati projektima kod kojih su se često mijenjali zahtjevi.

Model ima znatne prednosti i nedostatke. Radna verzija sustava dostupna je u vrlo kratkom roku. Troškovi razvoja su niski uz znatnu uštedu vremena, ljudskih i novčanih resursa. Proces razvoja je usredotočen na elemente koji su važni za korisnika te omogućuje brzu prilagodbu i izmjenu zahtjeva.

S druge strane, brzina i niži troškovi razvoja mogu uzrokovati manju kvalitetu sustava, što nije poželjno. Zbog čestih izmjena zahtjeva i brzih isporuka sustava javljaju se problemi s ažurnošću dokumentacije i s pridržavanjem konvencijama kodiranja. Brzina dizajna može uzrokovati lošu skalabilnost sustava. Kako se teži problemi odgađaju za zadnje faze, kako bi se prikazao rani učinak menadžmentu, nije moguće točno definirati stvarni napredak razvoja.

• Prikladnost modela◦ Mali i kratkotrajni projekti ◦ Veći dio funkcionalnost sustava vidljiv je na samom korisničkom sučelju ◦ Kod projekata gdje korisnik posjeduje kompletna znanja o području primjene ◦ Kada zahtjevi sustava nisu dovoljno jasni, ili su nepoznati ◦ Kad je moguća stabilnost razvojnog tima. ◦ Definirana je jasna razvojna arhitektura

• Neprikladan

13

◦ Dugotrajni i vrlo veliki infrastrukturni projekti s velikim brojem timova ◦ Sustavi za rad u realnom vremenu i visoko pouzdani sustavi ◦ Širok opseg projekta, i nejasni poslovni ciljevi ◦ Veliki broj osoba uključeno u odlučivanju, ali oni nisu uvijek dostupni i geografski su

dislocirani ◦ Veliki broj članova tima ili veći broj razvojnih timova ◦ Nedostatak korisničkih resursa◦ Kada se razvoj vrši pomoću nove, još nepoznate tehnologije

B.1.2.6 Formalni Model

Omogućuje razvoj informacijskog sustava koristeći različite matematičke metode. Matematičkim postupcima vrši se specifikacija, razvoj i testiranja softvera

Primjer formalnih metoda i notacija

• Petrijeve mreže

• Z-Notacija

• B-Metoda

• Prednosti ◦ Smanjuje se mogućnost pogrešaka i propusta ◦ Moguće je dokazati da je implementacija sukladna sa specifikacijom ◦ Dvosmislenost, nepotpunost te nekonzistentnost lako se otkrije i ispravlja

• Nedostaci ◦ Razvoj može biti dugotrajan i skup◦ Velika vjerojatnost da kupac nije upoznat s ovim modelom◦ Kompleksan za naučiti te traži puno vremena za savladavanje

14

B.1.2.7 ESA6 Razvojni modeli

Ozbiljne organizacije s vlastitim razvojnim informatičkim odijelima posebnu pažnju skreću na kontrolu kvalitete. Kontrolu kvalitete provodi poseban odjel, a jedan od zadataka tog odjela je i definiranje skupa razvojnih metodologija koje se koriste unutar organizacije. Primjer takve organizacije je Europska svemirska agencija koja ima definirane tri vrste razvojnih metodologija. Svaka od ESA metodologija primjenjuju se ovisno o vrsti projekta, budžetu, razvojnom timu i sl. Sve ESA metodologije koriste neki od prethodno predstavljenih razvojnih modela.

ESA vodopadni model

Definira šest faza razvoja koje koriste tzv. Waterfalli model gdje se svaka faza u potpunosti završava prije prijelaza na novu fazu.

UR – Definiranje korisničkih zahtjeva, SR - Definiranje zahtjeva softvera , AD – Definiranje arhitekturalnog dizajna, DD – Detaljni dizajn i razvoj koda , TR – Priprema softvera za uvođenje, OM – Uvođenje i održavanje softvera

FAZA Glavne aktivnosti Ciljni artefakti

UR Definiranje radne okolineIdentificiranje korisničkih zahtjeva

UR dokument

SR Izrada logičkog modelaDefiniranje zahtjeva softvera

SR dokument

AD Izrada fizičkog modelaDefiniranje glavnih komponenti sustava

AD dokument

DD Dizajn komponentiKodiranjeTestiranje komponenteIntegracijsko testiranjeSistemsko testiranje

DD dokumentKôdSUM dokument

TR InstalacijaPočetni test prihvatljivosti

ST dokument

6 European Space Agency (www.esa.intl)

15

OM Konačni test prihvatljivostiUvođenje u radOdržavanje koda i dokumentacije

PH dokument

ESA Inkrementalni model

Model je prikladan kod velikih projekata, gdje se izbjegava samo jedna objava softvera. To mogu biti npr. slijedeće situacije:

• Ako neke od funkcionalnosti trebaju biti gotove prije nego li se počne s razvojem drugih (inkrementalna implementacija funkcionalnosti)

• Ograničenje broja članova tima ima za posljedicu podjelu projekta u više etapa • Proračun projekta podijeljen je na manje iznose, ali kroz dulji period, čime nije moguć

kontinuirani rad na projektu

Svaka od verzija treba biti potpuno uporabljiva i pružati potpuno implementirane funkcionalnosti.

Nedostatak ovog modela su dodatni troškovi i napor prilikom testiranja dijela/cijelog sustava, koje se treba obavljati nakon svake iteracije.

Faze DD + TR + OM – podijeljene u više iteracija

ESA evolucijski model

Evolucijski model zasniva se na nadogradnji, izmjeni prethodne verzije softvera. Može se koristiti u situacijama, npr.:

• Kada korisniku sustava treba određeno iskustvo da definira korisničke zahtjeve sustava • Neki od dijelova sustava ovise o tehnologiji koja još nije gotova (npr. razvoj softvera za

hardver u razvoju) • Postoji vjerojatnost naknadnih korisničkih zahtjeva u tijeku razvoja sustava • Neki od korisničkih zahtjeva traže dulje vrijeme implementacije

16

Nedostatak modela predstavljaju nejasni zahtjevi koji mogu za posljedicu imati česte promjene koda. Privremeni dijelovi kod mogu biti ugrađeni u sustav čineći ga nepogodnim za nadogradnju.

DEV = UR + SR + AD + DD + TR

B.1.2.8 Dokumentiranje razvoja sustava

Različite metodologije koriste različitu strukturu dokumenata koji se isporučuju po završetku pojedine faze ili inkremenata faze, u slučaju inkrementalnih metodologija. Isto tako, različite metodologije definiraju blažu ili strožu disciplinu vezanu uz pisanje dokumentacije. S jedne strane, klasične linearne metodologije definiraju striktnu strukturu dokumenata koji se isporučuju po završetku svake faze, S druge strane, neke radikalne inkrementalne metodologije izbjegavaju pisanje klasičnih dokumenata, već pribjegavaju boljem dokumentiranju samog koda uz korištenje alata za automatizirano dokumentiranje.

S obzirom da linearne metodologije koriste striktno definiranje dokumenata, u daljnjem tekstu pokazana je struktura waterfall metodologije korištene u Europskoj svemirskoj agenciji.

Ovisno o fazi razvoja dostavljaju se slijedeći dokumenti:

• Dokument zahtjeva korisnika • Dokument zahtjeva softvera • Dokument dizajna arhitekture • Dokument detaljnog dizajna • Korisnički priručnik softvera• Dokument prijenosa softvera • Dokument povijesti projekta

17

Dokument zahtjeva korsinika (URD7)

Definira zahtjeve korisnika za željenim svojstvima softvera, a piše ga korisnik softvera (uz pomoć programera). U svrhu prikupljanja zahtjeva provode se intervjui te izrađuju prototipi sustava radi boljeg specificiranja zahtjeva.

Sve ESA spcifikacije, po završetku faze u kojima se pišu, provjeravaju se od strane korisnika, inženjera i menadžera (tzv. Technical review)

Dokument zahtjeva softvera (SRD8)

Opisuje rezultate analiza u kojoj se definira što softver treba raditi. Ovaj dokument ne sadrži dijelove vezane za implementaciju. Svi zahtjevi sustava se podjele na funkcionalne i nefunkcionalne zahtjeve.

Po završetku, dokument se provjerava od strane korisnika, inženjera i menadžera

Dokument dizajna arhitekture (ADD9)

Definira strukturu softvera te opisuje komponente sustava i sučelja među komponentama. Definira dizajn sustava kao skup više komponenata definirajući kontrolu i tok podataka između njih. Povezuje zahtjeve softvera s odgovarajućim komponentama koristeći tablicu u kojoj definirani zahtjevi referiraju na definiranu komponentu sustava.

Po završetku, dokument se provjerava od strane korisnika, inženjera i menadžera

Dokument detaljnog dizajna (DDD10)

Opisuje detaljni opis dizajna svih komponenata. Sastoji se od dva dijela. U prvom djelu dokumenta navode se opće informacije vezane za razvoj cijelog sustava, kao što su: primijenjeni/podržani standardi, primjenjene konvencije (kodiranja, dokumentiranja, testiranja), alati i postupci za proces razvoja. Ovaj dokument treba biti gotov prije početka samog razvoja sustava.

Drugi dio dokumenta se popunjava u hodu, kako dizajn napreduje. Struktura drugog dijela treba se u potpunosti poklapati sa strukturom koda. Sadržaj se sastoji od popisa komponenata i detaljnog opisa dizajna svake od komponente uz definiranje tipa i funkcije komponente, ovisnosti komponente o ostalim komponentama, ili vanjskim sustavima, definicija sučelja komponente, strukture podataka koju komponenta koristi.

Korisnički priručnik softvera (SUM11)

Ovaj dokument se počinje pisati za vrijeme DD faze zajedno s pisanjem dokumenta detaljnog dizajna sustava. Ovaj dokument sadrži upute korisnicima za korištenje softvera. Struktura ovog priručnika oslanja se na standard ANSI/IEEE Std 1063-1987 “Software User Documentation”

Definira se slijed upute korištenja, uređene od jednostavnih operacija ka složenim. Popis operacija

7 eng. User Requirements Document 8 eng. Software Requirements Document9 eng. Architectural Design Document 10 eng. Detailed Design Document 11 eng. Software User Manual

18

je uređen (najčešće) abecednim redom, a treba sadržavati i popis referenci prema ostalim dokumentima i primjere korištenja sustava.

Dokument prijenosa softvera (STD12)

Dokument definira postupke za transfer sustava, kako ga izgraditi i uvesti u rad. Sadrži izvješća o testiranju prihvaćanja softvera, uočenim greškama i promjenama koje su se desile tijekom TR faze

Dokument povijesti projekta (PHD13)

Ovaj dokument piše projekt menadžer koristeći princip upitnika na svim članovima projekta. Namjena dokumenta je bolje planiranje budućih projekata. Sadržaj se sastoji od sumiranja iskustva stečenih tijekom trajanja projekta, kao što su:

• Usporedba procjene resursa sa stvarno potrošenim resursima (vrijeme, ljudi, novac, ...)

• Sastavljanje tima

• Popis dobre prakse i loše prakse, uočene tijekom trajanja projekta

• Uspoređuje planove s ostvarenim rezultatima

B.1.3 Alati za razvoj sustava

Razvojni proces sastoji se od niza različitih aktivnosti koji se vrše tijekom pojedinih ili više faza razvoja sustava. U svrhu olakšavanja tih aktivnosti mogu se koristiti tzv. CASE14 alati, odnosno alati za računalom potpomognuto softversko inžinjerstvo. Osnovna namjena CASE alata je pomoć u razvoju i održavanju informacijskih sustava.

Pojam CASE izvorno potječe iz ranih 1980. godina od strane tvrtke Nastec Corporation. Tvrtka je proizvela nekolicinu alata od integriranih uređivača teksta i grafike, do alata za logičku i semantičku evaluaciju softvera i dijagrame dizajna sustava. Većina prvih CASE alata bila je specijalizirana za dizajn procesa (programa, modula) ili za dizajn podataka. Prvi CASE alati prvenstveno su se fokusirali na kreiranje i analizu grafičkog prikaza dizajna softvera te su predstavljali most između metodologije razvoja sustava i projekt menadžmenta. Uglavnom su nastali u velikim kompanijama (Nastec, IBM, ...), a izvršavali su se na velikim mainframe računalima.

Vrhunac u korištenju CASE alata bile su početak 1990. godina, no nestankom velikih mainframe računala nestali su i veliki CASE alati čime se otvorilo tržište za manje alate koje se koriste danas.

Tipični alati za razvoj softvera su:

• Alati za generiranje koda

• UML editori

12 eng. Software Transfer Document13 eng. Project History Document 14 Computer-Aided Software Engineering

19

• Alati za refactoring

• Alati za transformaciju modela (QVT15)

• Alati za upravljanje konfiguracijama (CM16)

• Alati za testiranje modula/sustava

CASE alati se mogu podijeliti na dvije skupine:

• Upper CASE

Alati vezani uz strategiju i planiranje (upravljanje resursima, generiranje projekt plana, upravljanje zahtjevima, ...)

• Lower CASE

Alati za pomoć u razvoju softvera (generiranje koda, generiranje shema baze podataka, testiranja koda/sustava, upravljanje konfiguracijom )

Različite faze razvoja sustava, traže različite alate za podršku:

• Projektni menadžment:

◦ Sastavljanje i praćenje projektnog plana

◦ Upravljanje resursima

• Prikupljanje i analiza zahtjeva

◦ Prikupljane podataka i analiza

◦ Modeliranje business procesa

◦ izrada prototipova;

◦ Upravljanje zahtjevima: dokumentiranje, definiranje prioriteta, upravljanje verzijama, povezivanje zahtjeva uz softverske komponente ...

◦ Sastavljanje modela podataka i rječnik; pomaže da se izbjegnu razlike u razumijevanju dupliciranje podataka

◦ reverzni inženjering

• Unaprjeđenje dizajna arhitekture sustava:

◦ omogućuje se vizualizacija arhitekturalnog rješenja, uz podršku standardne notacije, UML, E-R dijagrami i sl.

◦ opis komponenata sustava i sučelja

• Kreiranje koda i testiranje

◦ automatizirano generiranje koda na osnovu dizajna arhitekture, uključujući ulazne forme i izvještaje

◦ izvršavanje i testiranje koda kora-po-korak

15 Query/View/Transformation16 Configuration Management

20

◦ automatizirano pokretanje testova, uz mogućnost prikaza rezultata i izrade dokumentacije

◦ komentiranje i dokumentiranje koda

◦ upravljanje verzijama koda

• Upravljanje konfiguracijom produkta

◦ upravljanje verzijama koda

• Upravljanje greškama

◦ sustava za automatiziranu prijavu greške uz mogućnost povezivanja s CM sustavom

Primjer lower CASE alata

• Alati za upravljenja konfiguracijama ClearCase, SVN, CVS, Git, Mercurial

• Alati za testiranje komponente sustava JUnit, CUnit, CppUnit

• MDA alati Modelio, ArgoUML, Rational Rose Developer, StarUML, BoUML, Innovator, Sparx Enterprise Architect, Poseidon UML, Visual Paradigm for UML

• Alati za “refactoring” Eclipse, NetBeans, MS Visual Studio, ReSharper, CodeBrush

• Alati za statičku analizu koda Splint, lint, FindBugs, PMD, JSLint, StyleCop

• Alati za generiranje dokumentacije DoxyGen, javadoc, Doc-O-Matic, DOC++, NDoc, ROBODoc

• Alati za modeliranje podataka CASEWise, DataArchitect, PowerDesigner, DB Constructor, Oracle SQL Developer Data Modeler

• Integrirana razvojna okruženja NetBeans, Visual Studio, Eclipse, JDeveloper, IntelliJ IDEA, wxDevCPP, MonoDevelop, SharpDevelop, Rational Aplication Developer

• Alati za automatizirano testiranje sustava HP Quality Center, IBM Rational TestManager, MKS Integrity, HP WinRunner, IBM Rational Functional Tester

• Alati za praćenje pogrešaka Jira, BugZilla ,IBM Rational ClearQuest, BugTracker.NET, Tigris Scarab

21

B.1.4 Testiranje i uvođenje sustava

Kvaliteta nekog proizvoda najviše ovisi o postupku pripreme procesa, znanju, sposobnosti i motivaciji članova tima (analitičarima, arhitektima, programerima, ... ). Povećanjem znanja članova tima u obliku stručnih treninga može utjecati na kvalitetu izrade konačnog sustava. S druge strane, kvaliteta sustava može se poboljšati i kvalitetnim testiranjem sustava.

Testiranje se koristi u različitim segmentima ljudskih aktivnosti. Promatranje i eksperimenti se koriste za testiranje hipoteza i teorija u znanosti; studenti se testiraju putem pismenih i usmenih provjera tijekom studija; proizvodi se testiraju u industrijskoj proizvodnji.

Testiranje softvera je u direktnoj vezi s kvalitetom softverskog proizvoda. Testiranje treba omogućiti provjeru je li razvijeni sustav sukladan početno definiranim zahtjevima korisnika i može li pružiti mogućnost otkrivanja nedostataka u sustavu. U praksi nije moguće postići apsolutnu sigurnost da neki sustav ne sadrži greške, no moguće je postići da se sustav ponaša pouzdano za specificirane uvijete.

Testiranje sustava sa svim mogućim ulaznim parametrima, uz očekivanje željenih izlaznih parametara teško je ili čak nemoguće izvedivo. Važno je odabrati efektivne metode testiranja uz pažljivi odabir test podatka s kojima će se pokrenuti testiranje. Iako uvijek nije moguće, poželjno je za većinu testova omogućiti automatsko testiranje. U tu namjenu mogu pomoći specijalizirani alati i okruženja za automatizirano testiranje.

Jednom otkrivena pogreška u sustavu ili nadogradnja sustava, treba se testirati na način da se provjeri da li novonastala promjena uzrokuje neke nove greške na sustavu.

Pripreme za testiranje potrebno je započeti od prvih faza razvoja sustava. V-Model testiranja pokazan na slici 5 pokazuje ovisnost početnih faza razvoja s vrstom testiranja sustava. Npr. jednom

22

Slika 5: V-Model testiranja

definirani zahtjevi sustava predstavljaju početnu točku za specificiranje testa prihvatljivosti. Isto tako, kod dizajna komponente (modula) potrebno je specificirati testiranje tog modula.

Ovisno o fazi razvoja, testiranje se provodi na različitim dijelovima sustava pa tako razlikujemo:

• Modul testiranje - koristi se za testiranje konkretnog softverskog modula. Modul se testira od strane programera koji razvija sam modul i to prije nego li se modul integrira u sam sustav. Kod ovog testa najčešće se primjenjuje tzv. white-box testiranje

• Integracijsko testiranje – koristi se za testiranje sustava kao cjeline. Provodi se provjera da li moduli koji zasebno rade, rade ispravno i nakon što se povežu s ostalim modulima. Test najčešće provodi osoba koja nije direktno sudjelovala u razvoju modula. Iz V-Modela vidljivo je da priprema za integracijsko testiranje proizlazi iz dizajn specifikacija svih softverskih modula.

• Sistemsko testiranje – omogućuje testiranje sustava kao cjeline. Sustav se testira u zaštićenom okruženju na hardveru za koji je sustav razvijen. Najčešće se primjenjuje tzv. black-box testiranje, a specifikacija testa se definira na osnovu arhitekture sustava i dizajna sustava.

Ovisno o namjeni testiranja, razlikuju se slijedeće vrste:

• Regresijsko testiranje – koristi se u svrhu provjere izmjena na sustavu. Npr. nakon otklanjanja otkrivene i potvrđene pogreške u sustavu, provjerava se da li izmjena koja ispravlja pogrešku uvodi novu nepravilnost ili grešku u radu sustava

• Testiranje prihvatljivosti – provodi se od strane klijenta da se provjeri da li sustav radi s unaprijed dogovorenim zahtjevima. Test se vrši unutar radnog okruženja kod klijenta (korisnika)

• Alfa testiranje – predstavlja testiranje kompletnog sustava u razvojnom okruženju, a najčešće od strane klijenata ili/i posebnog tima sastavljenoga od razvojnih inženjera. Primjer: MS Windows Alpha verzije testiraju se od strane odabranih inženjera/programera i ostalih djelatnika tvrtke.

• Beta testiranje – se primjenjuje po završetku alfa testiranja, ali se ono provodi u ciljanom okruženju kod krajnjeg korisnika. Primjer: MS Windows Beta instalacije distribuiraju se krajnjim korisnicima koji mogu biti uključeni u program beta testiranja, gdje im je pružena mogućnost pružanja povratne informacije vezano za beta verziju sustava.

Kod svih vrsta testova postoje različite metode koje se koriste ovisno o kojem testu je riječ.

Testiranje Metode

Izvornog koda revizija, inspekcija

Komponente black-box, funkcionalni i strukturni white-box

Integracije Funkcionalna integracija, black-box, white-box

Sustava black-box, funkcionalno testiranje

Prihvatljivosti black-box

Tablica 1: Metode testiranja

23

Black box testiranje - ne izvodi se od strane programera koji je napisao izvorni kod. Odabir test podataka i interpretacija rezultata izvodi se na osnovu funkcionalnih osobina softvera. Testiranje se fokusira na opću funkcionalnost sustava, a često se provodi od strane trećih osoba.

White box testiranje - izvodi se od strane programera koji je upoznat s internom strukturom programa.

Osim klasičnih postupka testiranja, kvaliteta koda može se postići i drugim tehnikama kao što su revizije i inspekcije. Revizija predstavlja grupni proces koji uključuje sastanke i diskusiju. Potrebno je odrediti stanje projekta te detektirati slabe točke. Rezultati se prikazuju u obliku izvještaja, a postupci revizije uključuju slijedeće postupke:

Tehnički sastanci - uključuju dizajnere, ocjenjivače i ljude koji sudjeluju u narednim fazama projekta. Inspekcija izvornog koda/dokumentacije

Dizajneri i ocjenjivači prolaze kroz izvorni kod/dokumentaciju u potrazi za mogućim nepravilnostima u načinu kodiranja

Vanjske revizije Provode se od strane vanjskih osoba radi provjere suglasnosti sa zahtjevima, standardima, procedurama…

Slijedivost je postupak bilježenja izmjena/rada na projektu. Razlikuju se dvije vrste sljedivosti:

• Slijedivost unaprijed - bilježenje početnih zahtijeva i promjena od početne faze projekta (definiranje zahtijeva korisnika) do završnih faza projekta (uvođenja i održavanja) omogućuje identifikaciju područja pogođenim izmjenama kod uvođenja novih zahtjeva.

• Slijedivost unazad - U završnim fazama razvoja (uvođenje, održavanje), otkrivanjem pogrešaka započinje proces pretraživanja slijeda izvršenih radnji u prethodnim fazama razvoja u svrhu otkrivanja dijelova, komponenti ili zahtijeva koji su moguće povezani s uzrokom pogreške.

Formalni test - definira testiranje koje matematičkim metodama određuje ispravnost softvera. Kompleksnost metode čini je vrlo nepraktičnom za primjenu i tešku za učenje. Ograničena primjena ovog testiranja svodi se najčešće na testiranje algoritama enkripcije, komunikacijskih protokola te implementacije različitih standarda.

Ovisno koji se zahtjevi sustava testiraju razlikuju se dvije osnovne skupine testova:

• Funkcionalno testiranje – provjera rada sustava s prethodno definiranim zahtjevima.• Nefunkcionalno testiranje – testiranje sustava na tražene nefunkcionalne zahtjeve kao što

su:◦ sigurnost – provjera sustava na sigurnosne zahtjeve definirane na početku razvoja◦ uporabljivost – testiranje sustava u skladu s pravilima uporabljivosti (usability).

Orijentirano je prema lakoći korištenja sustava i intuitivnosti korištenja.◦ stabilnost – često se primjenjuje tzv. stress-test kojim se sustav testira u graničnom

okruženju i uz najveća moguća opterećenja

24

◦ pouzdanost – testiranje sustava uz praćenje ispravnosti izvođenja operacija ◦ portabilnost – testiranje mogućnosti promjene ciljne platforme

Kao pomoć pri testiranju postoji niz alata koji olakšavaju postupak testiranja od testiranja modula, do sistemskog testiranja. Vrlo bitno je bilježiti sve ispravke na sustavu, a u tu namjenu se koriste alati za praćenje pogrešaka (issue management) preko kojih se bilježi svaka novootkrivena pogreška i povezuje se s komponentom na koju se pogreška odnosi, i s odgovornom osobom (programerom) zaduženim za tu komponentu sustava. Sustav za praćenje pogrešaka omogućuje detaljan opis greške te naknadnu promjenu problematične komponente, s obzirom da je čest slučaj da se greška prijavi na komponentu koja je u stvarnosti ispravna. Ovi alati su povezani s alatima za upravljanje konfiguracijama koji se koriste za pohranu svih verzija datoteka izvornog koda. Jednom ispravljena datoteka izvornog koda treba imati oznaku s brojem greške koja je ispravljena tom verzijom.

Ovaj postupak se koristi od faza sistemskog testiranja do cijelog trajanja održavanja sustava.

Jednom testiran sustav treba pripremiti za uvođenje. Uvođenje sustava uključuje različite postupke priprema koje su potrebne da bi se sustav uspješno uveo kod krajnjeg korisnika i pripremu projekta za fazu održavanja. Ono što čini ovu fazu posebnom u donosu na sve prethodne faze je činjenica da su se sve projektne aktivnosti do ove faze obavljale unutar sigurnog, zaštićenog i osiguranog okruženja. Jednom kad se sustav uvede kod krajnjeg korisnika, više to neće biti slučaj. Svi problemi koji se budu javljali nakon uvođenja imati će značajni utjecaj na razvojnu organizaciju. Npr. samo prisustvo kod organizacije klijenta može tražiti posebna dopuštenja, a vrijeme potrebno za ispravljanje pogrešaka najčešće se dodatno naplaćuje, ako sustav do tada ne može normalno raditi. Faza uvođenja može se podijeliti na tri koraka

• Priprema uvođenja sustava - ključuje sve postupke priprema kojima se omogućuje jednostavno uvođenje sustava. Sama priprema uključuje razne intervjue, pripremu dokumentacije, koordinaciju logistike za osposobljavanje budućih korisnika i organiziranje prijenosa odgovornosti unutar razvojne organizacije kad sustav krene u rad i započne faza održavanja.

• Puštanje u rad - podrazumijeva postupke instalacije sustava (hardvera i softvera) kod korisnika, migraciju i inicijalizaciju podataka te osposobljavanje krajnjih korisnika.

• Prijenos odgovornosti - priprema odjela/grupe unutar razvojne organizacije za preuzimanje odgovornosti o održavanju sustava. Razvojni tim, u obliku dokumentacije, edukacije i drugih vrsta pomoći priprema poseban tim/odjel za održavanje sustava .

B.1.5 Kontrola i sigurnost sustava

Sve informacije pohranjene kao podaci, uključujući izvorni kôd softverskog proizvoda, predstavlja vrijednost za čovjeka. Stoga je potrebno osigurati podatke kako bi se zaštitila njihova vrijednost. Aspekti sigurnosti informacijskog sustava trebaju se uzeti u razmatranje od samog početka razvoja sustava kako bi se lakše i bolje implementirali.

Postoje 3 osnovna elementa koji definiraju sigurnost informacijskog sustava(CIA17) .

17 Confidentiality, Integrity, Availability

25

• Dostupnost – definira dostupnost podataka u bilo kojem trenutku, odnosno kada god to korisnik zaželi. Potrebno je definirati postupke dupliciranja podataka i metode sigurnosti podataka. U tu svrhu mogu se koristiti okruženja za repliciranje podataka (pasivna i aktivna replikacija), kompletni sustavi velike dostupnosti18 i postupci zaštite o DoS19 napada.

• Integritet – odnosi se na nepravilne i neprimjetne izmjene podataka ili funkcionalnosti sustava. Potrebno je definirati pouzdane sustave za prijenos i pohranu podataka te koristiti tehnike kodiranja radi očuvanja integriteta podataka (npr. ECC memorije)

• Povjerljivost – podrazumijeva uskraćivanje pristupa podacima ili sustavu od strane neautoriziranih korisnika. Povjerljivost je vezana uz podatke i operacije koje se mogu izvoditi na samom sustavu. U svrhu osiguranja povjerljivosti koriste se metode enkripcije i zaštite pristupa korisnicima.

2002. godine Donn B. Parker, uvodi dodatna tri elementa koja opisuju sigurnost sustava

• Posjed i kontrola – opisuje gubitak kontrole nad podacima u trenutku kada se izgubi posjed podataka. Npr. gubitak koverte s bankovnom karticom i identifikacijskim brojem kartice ne znači i gubitak povjerljivosti do onog trenutka dok se koverta ne otvori.

• Autentičnost – definira postupak potvrde autentičnosti podataka. Podatak može zadovoljavati sve CIA elemente, ali još uvijek nije sigurno je je podatak autentičan. U tu namjenu može se koristiti digitalni potpis kao potvrda autentičnosti elektroničke informacije.

• Korisnost – Opisuje korisnost podataka u trenutku kada su zadovoljeni svi CIA elementi sigurnosti. Kao primjer služi gubitak ključa za dekriptiranje podataka na računalu.

18 eng. High Availability System19 Denial of Service

26

B.1.6 Trendovi u razvoju sustava

Većina razvojnih metodologija vuče korijene iz vojne industrije ili su nastale u velikim softverskim kompanijama. Iako postoje različite metodologije razvoja sustava, postoje i definirani standardi koji opisuju postupke vezane za razvoj softvera.

B.1.6.1 ISO Standardi

ISO 9000

ISO 9000 dio je ISO standarda koji regulira razvoj, distribuciju, unaprjeđenje i održavanje. Standard zahtjeva da organizacija, koja implemenira standard, identificira ključne procese i odabere metodologije i tehnike u svrhu kvalitetnog provođenja procesa. Način odabira procesa nije propisan Poseban naglasak dan je na neprekidnom poboljšanju procesa i identifikatora, koji se koriste za kontrolu kvalitete procesa i proizvoda.

ISO12207

ISO 12207 poznat je pod imenom System and software enigineering – Software life cycle process definira sve zadatke potrebne za razvoj i održavanje softvera. Standard omogućuje prilagođavanje procesa specifičnom okruženju, a certifikat norme se određuje nadgledanjem performansi procesa, aktivnosti i zadataka.

ISO 12207 definira ukupno 23 procesa, 95 aktivnosti, 325 zadataka i 224 ishoda .

• 5 osnovnih procesa ◦ prikupljanje, opskrba, razvoj, rad, održavanje

• 8 procesa podrške

27

Slika 6: Evolucija standarda životnog ciklusa

◦ dokumentiranje, upravljanje konfiguracijom , kontrola kvalitete, verifikacija i testiranje, validacija, grupna provjera, revizija, rješavanje problema

• 4 organizacijska procesa ◦ upravljanje, infrastruktura, usavršavanje, trening

ISO27000

ISO 27000 definira familiju standarda za sustav upravljanja informacijskom sigurnošću. Podijeljene je na 6 standarda od kojih svaki ima specifičnu namjenu.

• ISO 27001 - Zahtjevi za Sustav Upravljana Informacijskom Sigurnošću (SUIS)

Određuje potrebe za utemeljenje, implementaciju, nadzor i pregled te održavanje i poboljšanje sustava upravljanja – u grubo to je okvir za upravljanje rizicima informacijske sigurnosti organizacije.

• ISO 27002 - Pravila dobre prakse za upravljanje sigurnošću informacija

Opisuje praktične metode managementa informacijske sigurnosti te se najčešće koristi kao pomoć kod implementacije SUIS-a po ISO 27001 standardu. Pruža primjere najbolje prakse u upravljanju informacijskom sigurnošću za osobe koje planiraju, implementiraju te održavaju sustav upravljanja informacijskom sigurnošću

• ISO 27003 - Upute za implementaciju SUIS-a

Pruža upute za implementaciju kao pomoć osobama koje implementiraju ISO 27000 standarde. U osnovi se bazira na smjernicama iz ISO 27001 standarda te pruža vodstvo sve do pokretanja SUIS projekta

• ISO 27004 - Mjerenja učinkovitosti sustava informacijske sigurnosti

Pomoć organizacijama za mjerenje, izvještavanje i na temelju toga sustavno poboljšanje kvalitete SUIS-a. Pruža smjernice za razvoj i korištenje mjerenja u svrhu procjene efektivnosti implementiranih kontrola i cijelog sustava SUIS, sukladno standardu ISO 27001. To uključuje politike, procjenu rizika, kontrolne ciljeve, kontrole, procese i procedure.

• ISO 27005 - Upravljanje rizikom SUIS-a

Pruža upute za upravljanje rizikom SUIS-a. Podržava osnovne koncepte iz 27001 i namijenjen je da pomaže zadovoljavajuću implementaciju informacijske sigurnosti bazirane na metodologijama za upravljanje rizicima. Ne određuje, preporuča ni imenuje neku od metoda upravljanja rizika, već opisuje strukturirani, sistematični i strogi proces od same procjene rizika do plana za rukovanje rizicima.

• ISO 27006 - Zahtjev za SUSI akreditaciju

Akreditacijski standard koji vodi certifikacijska kroz formalni proces certifikacije SUIS

28

organizacija prema ISO 27001 standardu. Navodi sve potrebe i upute kako izvesti certifikaciju i koje uvjete organizacija mora zadovoljiti.

B.1.6.2 IEEE

Propisuje skup standarda na području elektrotehnike, elektronike i računarstva

• Standardi za razvoj sustava

◦ IEEE/ANSI Std 730 - Standards for Software Quality Assurance Plans

◦ IEEE Std 1028-1997 - IEEE Standard for Software Reviews

◦ ANSI/IEEE 1042-1987 - IEEE Guide to Software Configuration Management

◦ IEEE Std 1016-1998 - IEEE Recommended Practice for Software Design Descriptions

◦ IEEE Std 1074-2006 - IEEE Standard for Developing Software Life Cycle Processes

◦ IEEE/EIA 12207-2008 - IEEE Systems and software engineering-Software life cycle processes

• Standardi za verifikaciju i testiranje

◦ ANSI/IEEE 829-1983 - IEEE Standard for Software Test Documentation

◦ IEEE Std 829-1998 - IEEE Standard for Software Test Documentation

◦ ANSI/IEEE 1008-1987 - IEEE Standard for Software Unit Testing

◦ IEEE Std 1012-1986/2004 - IEEE Standard for Software Verification and Validation

◦ IEEE Std 1059-1993 - IEEE Guide for Software Verification and Validation Plans

• Standardi iz područja elektronike i računarstva

◦ IEEE 754 - Standard for Floating Point Arithmetic

◦ IEEE 1394 - Standard for Serial Bus Interface (Firewire)

◦ IEEE 1284 - Standard for bi-directional parallel communication,

◦ IEEE 802.11x - Standards for wireless area network,

◦ IEEE 802.16 - Group of Broadband wireless Access Standards (WiMAX),

29

B.1.6.3 SEI/CMMI

SEI20 je istraživački centar čija je misija napredak postojećih praksa u softverskom inženjerstvu u svrhu poboljšanja kvalitete sustava koji ovise o softveru.

CMMI21 je postupak poboljšanja razvojnog procesa u svrhu poboljšanja rezultata neke organizacije.

Definira organiziran skup elemenata koji opisuju određeni aspekt zrelosti u organizaciji i pomaže pri definiranju i razumijevanju organizacijskog procesa.

Određuje 5 nivoa zrelosti u organizaciji

• Inicijalni (initial) - kaotičan, ad-hoc

Razvojni procesi su slabo dokumentirani, a razvojni proces je teško ponovljiv. Nije definirana organizacijska struktura

• Ponovljivi (repeatable) - PM, projektna disciplina

Pojedini razvojni procesi su ponovljivi, a procesna disciplina nije stroga.

• Definiran (defined) – institucionaliziran

Postoji skup definiranih i dokumentiranih procesa, a razvojni proces je ponovljivi.

• Upravljiv (managed)

Koristeći metriku razvojnog procesa omogućuje jednostavno praćenje napretka procesa. Ima mogućnost podešavanja i prilagođavanja procesa različitim projektima.

• Optimizirajući (optimizing) – poboljšanje razvojnog procesa

Prisutna je kontinuirana optimizacija procesa.

20 Software Engineering Institute (SEI) - http://www.sei.cmu.edu21 Capability Maturity Model Integration (CMMI) - http://www.sei.cmu.edu/cmmi

30

Slika 7: CMMI

B.1.6.4 SIX SIGMA

Poslovna strategija razvijena 1986. godine unutar tvrtke Motorola. Pruža mogućnost poboljšanja razvojnog procesa.

Strategija definira metriku (3.4DPMO22), metodologije (DMAIC, DMADV) i sustav upravljanja.

Cilj strategije je prepoznavanje i uklanjanje pogrešaka u procesu proizvodnje i razvojnom procesu radi postizanja visoke razine kvalitete ( 99,9997 % ). U softverskoj industriji primjenjuje se na izvornom kodu i na operacijama koje taj kod izvodi.

SIGMA NIVO DPMO Efikasnost

1σ 690000 31,00%

2σ 308537 69.15%

3σ 66807 93.32%

4σ 6210 99.379%

5σ 233 99.977%

6σ 3,4 99.9997%

Table 1: SixSigma

Primjena six sigma metode u razvojnom procesu fokusira organizaciju na

• Razumijevanje i rukovanje zahtjevima korisnika

• Definiranje ključnih procesa za ostvarivanje tih zahtijeva

• Smanjivanje oscilacije u ključnim procesima koristeći strogu analizu podataka

• Brzo i kontinuirano upravljanje poboljšanja razvojnog procesa

22 DPMO - Defective Parts per Million Opportunities

31

Slika 8: SixSigma

Temelji metodologije predstavljaju dva modela

• DMAIC - model za usavršavanje razvojnog procesa

Define opportunity, Measure performance, Analyze opportunity, Improve performance, Control performance

• DMADV - model za razvoj novih proizvoda ili procesa

Define design goals, Measure and identify CTQs, Analyze to develop and design alternatives, Design details, Verify the design

Poznat i pod imenom DFSS - (Design For Six Sigma)

Sama strategija koristi različite alate i metode, a neki od njih su:

• 5 Whys

• Analysis of variance

• ANOVA Gauge R&R

• Axiomatic design

• Business Process Mapping

• Catapult exercise on variability

• Cause & effects diagram (also known as fishbone or Ishikawa diagram)

• Chi-square test of independence and fits

• Control chart

• Correlation

• Cost-benefit analysis

• CTQ tree

• Quantitative marketing research through use of Enterprise Feedback Management (EFM) systems

• Design of experiments

• Failure mode and effects analysis (FMEA)

• General linear model Histograms, Homoscedasticity

• Quality Function Deployment (QFD)

• Pareto chart

• Pick chart

• Process capability

• Regression analysis

• Root cause analysis

• Run charts

32

• SIPOC analysis (Suppliers, Inputs, Process, Outputs, Customers)

• StratificationQuantitative marketing research through use of Enterprise Feedback Management (EFM) systems

B.1.6.5 Agilne metodologije

11.-13.02.2001., Snowbird skijalište, planine Wasatch , američka savezna država Utah; 17 osoba iz područja razvojnih metodologija zajednički je raspravljalo kako razvoj softvera učiniti bržim, lakšim i kvalitetnijim. Kao rezultat okupljanja nastao je proglas o metodi žustrog razvoja softvera - Agile Manifesto u kojem opisuju osnovne principe Agile metodologije.

Proglas o metodi žustrog razvoja softvera

Tražimo bolje načine razvoja softvera razvijajući softver i pomažući drugima pri njegovom razvoju. Takvim radom smo naučili da više cijenimo:◦ Ljude i njihove međusobne odnose nego procese i

oruđa

◦ Upotrebljiv softver nego iscrpnu dokumentaciju

◦ Suradnju s korisnicima nego pregovaranje oko ugovora

◦ Reagiranje na promjenu nego ustrajanje na planu.

Drugim riječima, iako cijenimo vrijednosti na desnoj strani, više vjerujemo u one na lijevoj.

Table 2: Agile Manifesto (http://agilemanifesto.org/iso/hr)

33

Načela na kojima se zasniva proglas o žustrom razvoju softvera. Rukovodimo se sljedećim načelima:

• Najvažnije nam je zadovoljstvo korisnika koje postižemo pravovremenom i stalnom isporukom vrijednog softvera.

• Spremno prihvaćamo promjene zahtjeva, čak i u kasnoj fazi razvoja. Žustri razvoj koristi promjene da korisniku stvori tržišnu prednost.

• Redovito isporučujemo upotrebljiv softver, u razmacima od nekoliko tjedana do nekoliko mjeseci, nastojeći da to bude što češće.

• Poslovni ljudi i informatičari moraju zajedno raditi svakodnevno, tijekom cjelokupnog trajanja projekta.

• Projekte ostvarujemo oslanjajući se na motivirane pojedince. Pružamo im okruženje i podršku koja im je potrebna, i prepuštamo im posao s povjerenjem.

• Razgovor uživo je najučinkovitiji način prijenosa informacija razvojnom timu i unutar tima.

• Upotrebljiv softver je osnovno mjerilo napretka.

• Žustri procesi potiču i podržavaju održivi razvoj. Pokrovitelji, informatičari i korisnici moraju biti u stanju stalno raditi, usklađenim tempom, nezavisno od trajanja projekta.

• Neprekinuti naglasak na tehničkoj izvrsnosti i dobar dizajn pospješuju žustrost.

• Jednostavnost – umješnost povećanja količine posla kojeg ne treba raditi – je od suštinske važnosti.

• Najbolje arhitekture, projektne zahtjeve i dizajn, stvaraju samo–organizirajući timovi.

• Timovi u redovitim razmacima razmatraju načine da postanu učinkovitiji, zatim se usklađuju i prilagođavaju svoje ponašanje.

Skup razvojnih metoda koja su dio agilnih metodologija su:

• Scrum

• XP – eXtreeme Programming

• DSDM – Dynamic System Development Metology

• FDD – Feature Driven Development

• AUP – Agile Unified Process

• EssUP – Essential Unified Process

• OpenUP – Open Unified Process

• Agile Data Method

• Lean Software Development

34

Osim metodologija, agile se koristi i određenim tehnikama pri razvoju sustava.

• Test Driven Development(TDD) – pisanje testova prije pisanja implementacije koja se testira

• Behavior Driven Development (BDD) – proširenje TDD metodologije na način da se testovi opisuju prirodnim jezikom

• Continuous Integration – neprekidna integracija novih funkcionalnosti

• Pair programming – kodiranje u paru

• Planning Poker – tehnika za procjenu razvoja komponente sustava bazirana na konsenzusu

• RITE23 Method – definira testiranje uporabljivosti sustava

B.1.6.6 Arhitektura aplikacija

Unazad nekoliko godina, najčešći pristup strukturiranja aplikacija bio je podjela na dvije komponente, klijent i poslužitelj. Ova arhitektura još je poznata kao dvoslojna arhitektura. Klijent omogućuje komunikaciju s poslužiteljem, a poslužitelj poslužuje više klijenata. Baza podataka i dio aplikacijske logike sustava je smještena na poslužitelju, dok klijent sadrži drugi dio aplikacijske logike i implementaciju sučelja s korisnikom. Nedostatak ove arhitekture predstavlja nadogradnja sustava, koja je nužna kako na poslužitelju, tako i u svim klijentima. Isto tako, kod ove arhitekture količina podataka između klijenta i poslužitelja je znatna.

23 Rapid Iterative Testing and Evaluation

35

Slika 9: Troslojna arhitektura softvera

Nedostatke dvoslojne arhitekture pokušava riješiti troslojna arhitektura aplikacija. Kod troslojne arhitekture aplikacija, aplikacijska logika odvaja se u zasebnu komponentu koja može samostalno postojati na jednom ili više različitih računala.

• Prezentacijski sloj (Presentation Tier) - Krajnji sloj prema korisniku, koji je zadužen za prikaz podataka. Direktno komunicira s aplikacijskim slojem.

• Aplikacijski sloj - (Application Tier; Business Logic/Logic Tier) – Izdvojeni sloj, koji kontrolira funkcionalnost aplikacije izvršavajući detaljnu obradu podataka.

• Podatkovni sloj (Data Tier) – Sastoji se od poslužitelja baze podataka koji je zadužen za pohranu i dohvat informacija. Podaci su pohranjeni neovisno o aplikacijskom poslužitelju.

Ovisno o broju slojeva razlikuju se slijedeće arhitekture

• 1-tier – samostalna aplikacija koja integrira svu funkcionalnost na jednom mjestu

• 2-tier – klasična klijent-poslužitelj arhitektura. Klijent je tzv. thick-client, dok poslužitelj, osim pohrane podataka obavlja i aplikacijski dio.

• 3-tier – Napredna prezentacija/aplikacija/podaci arhitektura kod koje se svaki sloj može izvršavati na odvojenom hardveru. Klijent, odnosno prezentacijski sloj se implementira kao thin-client, odnosno ne implementira aplikacijsku logiku.

• n-tier – 3-tier arhitektura s distribuiranim aplikacijskim slojem

36

A Dodatak - Predlošci ESA dokumenata

A.1 URD – Dokument zahtjeva korisnika

1 Uvod 1.1 Svrha dokumenta 1.2 Namjena softvera 1.3 Definicije, akronimi, kratice 1.4 Reference 1.5 Opis dokumenta

2 Opći opis 2.1 Namjena proizvoda 2.2 Opća svojstva 2.3 Opća Ograničenja 2.4 Svojstva korisnika 2.5 Radno okruženje 2.6 Pretpostavke i zavisnosti

3 Specifični zahtjevi 3.1 Popis svojstava softvera 3.2 Popis ograničenja softvera

A.2 SRD - Dokument zahtjeva softvera

1 Uvod 1.1 Svrha dokumenta 1.2 Namjena softvera 1.3 Definicije, akronimi, kratice 1.4 Reference 1.5 Opis dokumenta

2 Opći opis 2.1 Ovisnost s ostalim projektima 2.2 Ovisnost s prethodnim, narednim projektima 2.3 Funkcija i namjena 2.4 Specifičnosti okruženja 2.5 Ovisnost s ostalim sustavima 2.6 Opća ograničenja 2.7 Opisa modela

3 Specifični zahtjevi 3.1 Funkcionalni zahtjevi 3.2 Nefunkcionalni zahtjevi performanse, sučelja, resursi, verifikacija, testiranje, dokumentiranje, zaštita, portabilnost, kvaliteta, pouzdanost, održavanje, sigurnost

4 Tablica korisničkih zahtjeva i softverskih zahtjeva

37

A.3 ADD - Dokument dizajna arhitekture

1 Uvod 1.1 Svrha dokumenta 1.2 Namjena softvera 1.3 Definicije, akronimi, kratice 1.4 Reference 1.5 Opis dokumenta

2 Pregled sustava 3 Kontekst sustava 4 Dizajn sustava

4.1 Metode dizajna 4.2 Opis dekompozicije

5 Opis komponente sustava 5.n [Identifikator komponente] 5.n.1 Tip 5.n.2 Namjena 5.n.3 Funkcija 5.n.4 Podređene komponente 5.n.5 Ovisnost 5.n.6 Sučelja 5.n.7 Resursi 5.n.8 Reference 5.n.9 Obrada 5.n.10 Podaci

6 Izvedivost i procjena resursa 7 Tablica softverskih zahtjeva i komponenata

A.4 DDD - Dokument detaljnog dizajna

1. Dio – Opći opis 1 Uvod

1.1 Svrha dokumenta 1.2 Namjena softvera 1.3 Definicije, akronimi, kratice 1.4 Reference 1.5 Opis dokumenta

2 Standardi, konvencije i postupci 2.1 Standardi dizajna 2.2 Standardi dokumentiranja 2.3 Konvencije naziva 2.4 Standardi kodiranja 2.5 Razvojni alati

2. dio – Specifikacija dizajna komponenata n [Komponenta] n.1 Tip n.2 Namjena n.3 Funkcija n.4 Podređene komponente n.5 Ovisnosti

38

n.6 Sučelja n.7 Resursi n.8 Reference n.9 Obrada n.10 Podaci

Dodatak A Ispis izvornog koda

Dodatak B Tablica softverskih zahtjeva i komponenata

A.5 SUM - Korisnički priručnik softvera

1 Uvod 1.1 Kome je dokument namijenjen 1.2 Primjenjivost 1.3 Namjena 1.4 Kako koristiti se ovim dokumentom 1.5 Srodni dokumenti 1.6 Konvencije 1.7 Upute za prijavi pogrešaka

2 [Pregled] 3 [Upute]

(a) Funkcijski opis (b) Oprezi i upozorenja (c) Procedure (d) Moguće greške i njihovi uzroci

4 [Reference] (a) Funkcionalan opis (b) Oprezi i upozorenja (c) Formalni opis (d) Primjeri (e) Moguće poruke grešaka i njihovi uzroci (f) Povezanost s ostalim operacijama

Dodatak A Poruke o greškama i postupci oporavka Dodatak B Popis pojmova Dodatak C Indeksi (za priručnike dulje od 40 strana)

A.6 STD - Dokument prijenosa softvera

1 Uvod 1.1 Svrha dokumenta 1.2 Namjena softvera 1.3 Definicije, akronimi, kratice 1.4 Reference 1.5 Opis dokumenta

2 Postupci instalacije 3 Postupci izgradnje 4 Konfiguracija

39

5 Sažetak izvješća testa prihvaćanja 6 Izvješća o greškama softvera 7 Izvješća o promjenama softvera 8 Izvješća o preinakama softvera

A.7 PHD - Dokument povijesti projekta

1 Opis projekta 2 Projekt menadžment

2.1 Ugovorni pristup 2.2 Organizacija projekta 2.3 Korištene metode 2.4 Planiranje

3 Produkcija softvera 3.1 Procijenjena i ostvarena količina koda 3.2 Dokumentacija 3.3 Procijenjeni i ostvareni rad 3.4 Računalni resursi 3.5 Analiza faktora produktivnosti

4 Izvješće osiguranja kvalitete 5 Financijsko izvješće 6 Zaključci 7 Performanse sustava u OM fazi.

40

B LITERATURA:

B.1 Proces i metode razvoja sustava

• Beck, Kent

◦ Extreme Programming Explained

ISBN-13: 978-0201616415

• Beedle Mike, Schwaber Ken

◦ Agile Software Development with Scrum

ISBN-13: 978-0130676344

• Bernstein, Lawrence; Yuhas, C. M.

◦ Trustworthy Systems Through Quantitative Software Engineering

ISBN-13: 978-0471696919

• Booch, Grady, Jacobson, Ivar and Rumbaugh, James:

◦ Object-Oriented Analysis and Design with Applications (3d Edition)

ISBN-13: 978-0201895513

• Brooks P., Frederick

◦ The Mythical Man-Month: Essays on Software Engineering, Anniversary Edition (2nd Edition)

ISBN-13: 978-0201835953

• Budgen, David:

◦ Software Design 2nd Edition

ISBN-13: 978-0201722192

• Kruchten, Phillippe

◦ The Rational Unified Process: An Introduction (2nd Edition)

ISBN-13: 978-0321197702

• McConnell, Steve

◦ Rapid Development

ISBN-13: 978-1556159008

• McConnell, Steve

◦ Code Complete 2nd Edition

ISBN-13: 978-0735619678

• Shore, James; Shane, Warden

◦ The Art of Agile Development

ISBN-13: 978-0596527679

41