Podjela softvera po namjeni:

• Sistemski softver (Podrška ostalim aplikacijama)

• Aplikacijski softver (Pruža specifičnu funkcionalnost korisniku računala)
Svojstva sistemskog softvera (npr. BIOS,OS,ljuske OS-a,graf.okruženja : Gnome,Aero,pomoćni prog.za analizu konfig.
i optimizaciju računala)
• Upravljanje sklopovljem
• Upravljanje procesima
• Upravljanje memorijskim resursima
• Korisničko sučelje
• Prikrivanje kompleksnosti sklopovlja
• Pružanje osnovne funkcionalnost korisniku računala
• Izvodi se u privilegiranom načinu rada
Razvojni proces:Definira skup zadataka s ciljem proizvodnje visokokvalitetnog proizvoda
Životni ciklus razvoja softvera:
• Planiranje (Analiza tržišta, isplativosti i izvedivosti proizvoda)
• Analiza ( Prikupljanje i obrada zahtijeva (šTO); Analiza rizika
• Dizajn (Dizajn programa (KAKO) )
• Razvoj (Pisanje programa – kodiranje)
• Testiranje i integracija (Provjera ispravnosti pojedinih komponenata i programa kao cjeline)
• Uvođenje (Uvođenje programa kod kupca)
• Održavanje (Ispravljanje pogrešaka)
Metodologija razvoja sustava
• Skup metoda koji definiraju strukturu, plan i kontrolu procesa razvoja informacijskog sustava
• Podjela u više faza koje se izvršavaju
o linearno
o iterativno
• Za svaku fazu definiraju se
o preduvjeti
o aktivnosti
o rezultati (deliverables)
Danas su poznate različite metodologije razvoja informacijskih sustava.
Ne postoji najbolja, već prikladnija metodologija ovisno o različitim elementima (Kompleksnost projekta,Vrsta
aplikacije,Broj članova tima,Iskustvo članova tima,Organizacijska struktura projekta)
• Većina metodologija za razvoj informacijskih sustava bazira se na jednom od slijedećih modela
o Vodopadni (Waterfall)
o Prototipni
o Spiralni
o Inkrementalni
o Formalni
o Brzi Razvoj Aplikacija (Rapid Aplication Development)
Vodopadni model
• Izvorni model (Winston W.Royce – 1970. ) sastojao se od slijedećih faza:
o Specifikacija
o Dizajn
o Razvoj
o Integracija
o Testiranje
o Uvođenje
o Održavanje
• Osobine
o Linearan
o Faze se izvode jedna za drugom, bez ponavljanja
o Prelazak u novu fazu nakon što se obavi revizija prethodne
o Svaka se faza detaljno dokumentira
o Jednostavan i organiziran model
• Prednosti
o Jednostavan za učenje - pogodan za neiskusne članove tima i voditelje
o Napredak razvoja je mjerljiv
o Uređen slijed faza, striktna kontrola dokumentacije i revizije dizajna doprinosi kvaliteti,
pouzdanosti i lakoći u održavanju sustava
• Nedostaci
o Nefleksibilan, skup i spor
o Ovisi o unaprijed definiranim zahtjevima korisnika, koji često ne znaju točno definirati zahtjeve u
ranoj fazi projekta
o Većina problema otkrije se tek u testnoj fazi što povećava troškove izmjene
o Izmjene u kasnim fazama razvoja su skupe pa se često izbjegavaju
o Specifikacije su često nerazumljive korisnicima
• Prikladan
o Veliki i složeni projekti
o Projekti s jasnim ciljem
o Zahtijevi se ne mijenjaju tijekom životnog ciklusa
o Članovi tima i/ili voditelji su neiskusni
o Velika vjerojatnost fluktuacije članova tima
 o Kod projekata sa dislociranim timovima
o Korisnik je iskusan i razumije primjenu
• Neprikladan
o Projekti kod kojih zahtjevi nisu dobro specificirani ili se često mijenjaju
o Kod projekata gdje se traži brz razvoj sustava
Prototipni model
• Osobine
o Iterativan
o Nije potpuna metodologija, već pristup obrade pojedinih dijelova većih, tradicionalnih metodologija
(inkrementalne, spiralne, vodopadne, ... )
o Korisnik je uključen u razvojni proces za cijelo vrijeme njegovog trajanja
o Izrada prototipa sustava iterativnim postupkom sve dok se ne ispune zahtijevi korisnika
• Prednosti
o Brza izrada početnog sustava vrlo rano uočava nesporazum na relaciji između korisnika i programera
o Koristan za bolje modeliranje pojedinih aspekata sustava kod klasičnih metodologija
o Koristan kod rješavanja nejasnih ciljeva
o Potiče inovativne ideje
o Pomaže jednostavnom identificiranju nejasnih i otkrivanju nepostojećih funkcionalnosti
o Omogućuje brz razvoj nepotpunog, ali funkcionalnog sustava
• Nedostaci
o Proces potvrde i kontrole nije striktan
o Mogućnost čestih i znatnih promjena zahtijeva
o Može dovesti do krivih očekivanja – korisnik (krivo) uvjeren da je sustav gotov iako to nije
o Zapostavljanje dokumentacije
o Mogućnost nedostatak dovoljnih provjera
• Prikladan
o Projektni zahtjevi su nejasni
o Postoji želja za brzom implementacijom
o Česta izmjena fukcionalnosti
o Korisnik ne posjeduje dovoljna znanja o projektu
o Članovi razvojnog tima su vrlo iskusni
o Voditelj projekta je iskusan
o Ne traži se inovativan i fleksibilan dizajn koji je prigodan kasnijim izmjenama
o Veliki projekt sa mnogo korisnika, veliki brojem funkcionalnosti,a rizici prilikom definiranja
zahtijeva trebaju se minimizirati
• Neprikladan
o Velikih (mainframe) sustava
o E-business sustava
o Struktura razvojnog tima nije stabilna
o Kada postoji potreba za budućom skalabilnosti sustava
o Ciljevi su jasni i ne postoje veći izvori rizika povezani sa definiranjem zahtijeva
• Vrste softverskih izrada prototipova
o Brza izrada prototipova (prototip “napravi i baci”)
-Izradu prototipa koji služi za bolje definiranje zahtijeva
o Evolucijska izrada prototipova (Robustan prototip s namjenom poboljšavanja)
o Inkrementalna izrada prototipova (Svaki prototip se nezavisno razvija, a u konačnici se svi zajedno
spajaju u gotov proizvod )
o Ekstremna izrada prototipova (Izrada prototipova u više koraka gdje se svaki novi oslanja na
prethodni (web dizajn) )
Spiralni model
Barry Bohem – 1988g.U izvornom modelu svaka petlja trajala je od 6 mjeseci do 2 godine.
Svaka petlja unutar spirale predstavlja jedan ciklus u kojoj se provode faze pojednostavljenog vodopadnog modela.
• Osobine
o Kombinacija linearnog i iterativnog
o Analizu rizika tijekom čitavog trajanja projekta
o Minimizacija rizika podjelom projekta na male dijelove omogućujući lakše izmjene
o U svakom ciklusu obavljaju se jednaki koraci počevši od dokumentiranja koncepta rada do izrade
samog programa
o Svaki ciklus završava izradom prototipa
o Na kraju svakog ciklusa vrši se planiranje za idući
• Prednosti
o Napredno upravljanje rizicima
o Koristan kod odabira najbolje metodologije za pojedinu iteraciju razvoja, ovisno o riziku
o Može se služiti vodopadnim, prototipnom ili inkrementalnom metodologijom
• Nedostaci
o Složenost određivanja pojedine metodologije za svaku iteraciju
o Usko prilagođen za pojedini projekt što ga ne čini ponovno iskoristivim
o Voditelj projekta treba biti vrlo iskusan kod primjene na pojedini projekt
o Nema čvrstih rokova, ne definira uvjet završetka pojedinog ciklusa
o Neadekvatnom primjenom može se desiti da se model u konačnici svede na vodopadni
• Prikladan
o Sustavi za rad u realnom vremenu
o Sustavi visokog stupnja sigurnosti
 o U projektima gdje minimizacija resursa nije glavni prioritet
o Iskusan voditelj projekta
o Kod projekata gdje se traži visok stupanj točnosti
• Neprikladan
o Ako je minimizacija resursa prioritet
o Ako analiza rizika nije prioritet
o Kod projekata gdje se ne traži visok stupanj točnosti
o Ako funkcionalnost ima prednost nad implementacijom
Inkrementalni model
• Faze:
o Početak (Definiranje korisnosti, izvedivosti rizika)
o Razrada (Definiranje razvojne arhitekture)
o Razvoj (Razvoj na osnovu definiranog dizajna)
o Tranzicija (Utvrđivanje prihvatljivosti riješenja)
• Discipline
o Poslovno modeliranje
o Definiranje zahtjevi
o Analiza i dizajn
o Implementacija
o Testiranje
o Dostava
• Osobine
o Serije mini-vodopadnih iteracija
o Razbijanje projekta na niz jednostavnijih segmenata
o Rana implementacija početne verzije sustava daje mogućnost ranog usuglašavanja sa kupcem
• Prednosti
o Korištenje iskustva prethodnih iteracija
o Daje mogućnost boljeg uvida u stanje projekta
o Dokumentiranje i revizije pružaju umjerena kontrola tijekom čitavog trajanja projekta
o Postepena implementacija omogućuje praćenje utjecaja pojedinih inkremenata i izoliranje
eventualnih problema (lakša mogućnost izmjena)
• Nedostaci
o Teži poslovi odgađaju se u kasnije inkremente da bi se pružili rani pozitivni rezultati menadžmentu
o Potrebno je dobro definirati sučelja među komponentama, s obzirom da se komponente ne razvijaju
u istim inkrementima
o Rad u inkrementima može dovesti do manjka razumijevanja cjelokupnog problema
• Prikladan
o Veliki projekti gdje zahtjevi nisu razumljivi, ili su podložni čestim promjenama
o Veliki projekti kojima se često mijenja budžet ili tehnologija
o Web servisi
o Visoko kvalitetne aplikacije
• Neprikladan
o Vrlo mali i kratkotrajni projekti
o Mali integracijski i arhitekturalni rizici
o Interaktivni sustavi kod kojih barem dijelomično postoji projektni podaci
• Primjeri iterativo-inkrementalnih postupaka
o UP (Unified Process) : AUP, BUP, OpenUP, EUP, OUM
o FDD (Feature Driven Develpment)
o Scrum
o XP (eXtreme Programming)
Brzi Razvoj Aplikacija (RAD)
• Osobine
o Brzi razvoj i isporuka sustava visoke kvalitete
o Niski troškovi razvoja
o Projektni rizici se smanjuju podjelom projekta na manje cijeline
o Iterativni prototipovi, aktivno sudjelovanje klijenata/korisnika, korištenje CASE alata
o Naglasak na želje korisnika, manje na dizajnu sustava
o Podjela poslova na vremenske odsječke
o Naglasak na poštivanje rokova (Smanjivanje zahtijeva prioritet nad pomicanju rokova)
o Koristi Iterativnu izradu prototipova
o Izrada dokumentacije za lakšu nadogradnju i održavanje sustava
o Koristi se standardnim tehinkama analize i dizajna
• Prednosti
o Radna verzija sustava dostupna u vrlo kratkom roku
o Niski troškovi izgradnje
o Fokusiranje na korisničku bitne elemente sustava
o Brza i laka prilagodba na izmjene specifikacija
o Ušteda vremenskih, ljudskih i nočanih resursa
• Nedostaci
o Brzina i niži troškovi mogu uzrokovati manju kvalitetu sustava
o Moguća inkonzistentnost dokumentacije, ne pridržavanje konvencijama kodiranja
o Brzi dizajn može uzrokovati lošu skalabilnost sustava
o Teži problemi odgađaju se za zadnje faze, kako bi se prikazao rani učinak menadžmentu
 • Prikladan
o Mali i kratkotrajni projekti
o Veći dio funkcionalnost sustava vidljiv je na samom korisničkom sučelju
o Korisnik posjeduje kompletna znanja o području primjene
o Zahtjevi sustava nisu dovoljno jasni, ili su nepoznati
o Stabilnost razvojnog tima
o Definirana i jasna razvojna arhitektura
• Neprikladan
o Vrlo veliki infrastrukturalni projekti
o Sustavi za rad u realnom vremenu
o Visoko pouzdani sustavi
o Širok opseg projekta,i nejasni poslovni ciljevi
o Veliki broj osoba uključeno u odlučivanju, ali oni nisu uvijek dostupni i geografski su dislocirani
o Veliki broj članova tima, ili veći broj razvojnih timova
o Nedostatak korisničih resursa
o Korištenje novih tehnologija po prvi puta
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,Metode iz teorija automata)
• Prednosti
o Smanjuje se mogućnost pogrešaka i propusta
o Moguće je dokazati da se implementacija poklapa sa specifikacijom
o Dvosmislenost, nepotpunost i nekonzistentnost lako se otkrije i ispravlja
• Nedostatci
o Koristeći formalni model, razvoj je dugotrajan i skup
o Velika vjerojatnost da kupac nije upoznat s ovim modelom
o Kompleksan za naučiti i traži puno vremena za savladavanje
Dokumentacija faza razvoja sustava
Dokumentiranje pojedine faze predstavlja ulaznu iduće faze u ciklusu.
• Vrste specifikacija:
o Korisnička specifikacija (User Requirements Document)
o Specifikacija softvera (Software Requirements Document)
o Funkcionalna dizajn specifikacija (Architectural Design Document)
o Detaljna dizajn specifikacija (Detailed Design Document)
o Transfer specifikacija (Softver Transfer Document)
o Specifikacija održavanja (Project History Document)
• User Requirements Document (URD)
o Uvod
ƒ Namjena dokumenta, svrha projekta, akronimi..
o Opći Opis
ƒ Namjena proizvoda
ƒ Osobine kupca
ƒ Opća ograničenja
ƒ Pretpostavke
ƒ Radno okruženje
o Specifični zahtjevi
ƒ Najvažniji dio dokumenta
ƒ Opis zahtijevanih funkcija i operacija
ƒ Ograničenja
• Software Requirements Document (SRD)
o Uvod
ƒ Namjena dokumenta, svrha projekta, akronimi..
o Opći Opis
ƒ Povezanost s ostalim projektima
ƒ Funkcije i ciljevi
ƒ Okruženje
ƒ Mjesto, korisnik, oprema, os, …
ƒ Ovisnost o ostalim sustavima
ƒ Opća ograničenja
ƒ Logički model
o Specifični zahtjevi
ƒ Funkcije (što, a ne kako), performanse, sučelja, radni zahtjevi, resursi, verifikacija,
dokumentacija, povjerljivost, prenosivost, kvaliteta, pouzdanost, održavanje, sigurnost
• Architectural Design Document (ADD)
o Uvod
ƒ Namjena dokumenta, svrha projekta, akronimi..
o Opći Opis sustava
o Okruženje sustava
o Dizajn sustava
ƒ Metoda, dekompozicija
o Opis komponenata
ƒ Identifikatori, tipovi, svrha, funkcija, ovisnosti, sučelja, resursi, reference, obrada, podaci
 o Procjena izvedivosti
• Detailed Design Document (DDD)
o Uvod
ƒ Namjena dokumenta, svrha projekta, akronimi..
o Standardi:
ƒ Dizajna
ƒ Dokumentacije
ƒ Kodiranja
ƒ Konvencije
ƒ Razvojni alati
o Specifikacija komponenti
o Dodaci:
ƒ Izvorni kod programa, ..
• Software User Manual (SUM)
o Uvod
ƒ Korisnik dokumenta
ƒ Primjena
ƒ Povezani dokumenti
ƒ Konvencije
ƒ Mogući problemi
o Pregled
ƒ Povezanost s ostalim projektima
ƒ Opis procesa
ƒ Veza korisnik-sustav
o Upute za korištenje
o Radna obilježja
ƒ Lista funkcionalnosti
o Dodaci:
o Opis grešaka, pojmovnik, indeks
• Software Transfer Document (STD)
o Uvod
ƒ Namjena dokumenta, svrha projekta, akronimi..
o Opis Instalacije
o Razvojna procedura
o Opis konfiguracije
o Rezultati testa
o Izvještaj problema
o Zahtjev za izmjenom
o Izvještaj o modifikaciji
• Project History Document (PHD)
o Opis projekta
o Projekt menadžment
ƒ Projektna organizacija
ƒ Metode
ƒ Planiranje
o Produkcija softvera
ƒ Kodiranje
ƒ Dokumentacija
ƒ Ljudstvo, računalni resursi
ƒ Analiza produktivnosti
o Očuvanje kvalitete
o Troškovi
o Zaključak
o Performanse u radnoj fazi
Alati za razvoj sustava.
Svaka faza razvoja sustava sastoji se od niza zadataka.Korištenjem specifičnih alata može se ubrzati proces razvoja
sustava.
• CASE alati – Computer-Aided Design Engineering)
o UPPER CASE Tools (Vezani uz strategiju, planiranje)
o LOWER CASE Tools (Vezani uz razvoj softvera,dizajn, razvoj, testiranje, dokumentiranje,
ispravljanje pogrešaka, integracija, održavanje, reverzni inženjering)
• Osobine CASE alata
o Omogućuju brz razvoj sustava
o Nisu dovoljno standardizirani
o Visoki troškovi uvođenja
o Potrebna specijalna edukacija
• Vrste CASE alata
o Alati za modeliranje podataka
o Configuration Management Alati
o Alati za testiranje sustava
o UML alati
o Alati za praćenje pogrešaka
o Alati za “refactoring”
o Alati za statičku analizu koda
 o Alati za generiranje dokumentacije
• UML Strukturni dijagrami
o Dijagram klasa
o Dijagram objekata
o Dijagram paketa
o Dijagram komponenti
o Dijagram profila
o Distribucijski dijagram
o Dijagram kompozitne strukture
• UML Dijagrami ponašanja
o Dijagram slučaja korištenja
o Dijagram aktivnosti
o Dijagram stanja
• UML Dijagrami interakcija
o Dijagram slijeda
o Dijagram komunikacija
o Vremenski dijagram
o Dijagram pregleda interakcija
Testiranje i uvođenje sustava
• Dobar sustav : sustav koji svojom funkcionalnošću udovoljava korisničkim zahtjevima.
• Kvaliteta programa znatno ovisi o kvaliteti testiranja.
• Radnje u postupku verifikacije softvera
o Revizija
o Sljedivost
o Formalni test
o Testiranje
• Revizija
Grupni proces koji uključuje sastanke i diskusiju.Potrebno odrediti stanje projekta te detektirati slabe točke.Rezultat
revizije pruža se u obliku izvještaja.
• Tehnički sastanci
o Uključuje dizajnere i ocjenjivače
o Uključuje ljude koji su sudjeluju u idućim fazama projekta
• Inspekcija izvornog koda/dokumentacije
o Dizajneri i ocjenjivači prolaze kroz izvorni kod/dokumentaciju u potrazi za mogućim
nepravilnostima
• Vanjske revizije
o Provode se od strane vanjskih osoba radi provjere poklapanja s zahtjevima, standardima,
procedurama…
• Sljedivost
o “Sljedivost prema naprijed”
ƒ Bilježenje zahtijeva od početne faze projekta (definiranje zahtijeva korisnika) do završnih
faza projekta (uvođenja i održavanja)
ƒ Omogućuje detekciju izmjena uzrokovanih naknadnim promjenama zahtjeva u kasnim
fazama projekta
o “Sljedivost 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
• Formalni test
o Matematičkim metodama odrediti ispravnost softvera (Koristi se u formalnim modelu razvoja
sustava)
o Kompleksnost metode čini je vrlo nepraktičnom (Nije jednostavna za učenje)
o Ograničena primjena (enkripcija, komunikacijski protokoli)
• Testiranje
Najčešća i najizravnija metoda provjere ispravnosti.
Za unaprijed definirani ulaz, provjerava se izlaz programa i uspoređuje s očekivanom vrijednošću
Vrlo je teško testirati sustav na sve moguće ulazne parametre i stanja sustava
Potrebno je unaprijed odrediti efikasnu metodu kojom ćemo moći detaljno ispitati ispravnost sustava
• Black box testiranje
o Ne izvodi se od strane programera koji je pisao izvorni kod
o Odabir test podataka i interpretacija rezultata izvodi se na osnovu funkcionalnih osobina softvera
o Fokusira se na opću funkcionalnost sustava
o Često se provodi od strane trećih osoba
• White box testiranje
o Potrebno je vrlo dobro poznavanje programa koji se testira
o Tehnika se bazira se na poznavanju struktura i naredbi samog programa
• Uvođenje sustava
Omogućuje se dostupnost sustava namijenjenoj grupi korisnika.
Za razliku od prethodnih faza životnog ciklusa, ne obavlja se unutar sigurnog i zaštićenog okruženja.
Omogućuje krajnjem korisniku korištenje novog sustava.
Definira zadatke unutar organizacije za prelazak u fazu održavanja sustava.
• Koraci u fazi uvođenja sustava
o Priprema za uvođenje sustava
 o Puštanje u rad
o Prijenos odgovornosti
• Priprema za uvođenje sustava
o Zadaci
ƒ Intervjui
ƒ Dostava dokumentacije
ƒ Koordinacija logistike za osposobljavanje korisnika
ƒ Organizacija prijenosa odgovornosti
o Rezultati
ƒ Organizacija okruženja i skupine odgovorne za uvođenje sustava
• Puštanje u rad
o Zadaci
ƒ Instalacija i konfiguracija sustava
ƒ Osposobljavanje korisnika
ƒ Migracija i inicijalizacija podataka
o Rezultati
ƒ Migrirani i inicijalizirani podaci
ƒ Sustav pušten u rad
• Prijenos odgovornosti
o Zadaci
ƒ Priprema odjela/grupe za preuzimanje odgovornosti o održavanju sustava
ƒ Razvojni tim u obliku dokumentacije, edukacije i drugih vrsta pomoći priprema tim/odjel
za održavanje sustava
o Rezultati
ƒ Odgovornost sustava je u nadležnosti tima/odjela za održavanje
Kontrola i sigurnost sustava
• Okruženja u razvoju sustava
o Razvojno
o Testno
o Produkcijsko
• Razvojno okruženje
o Naglasak na korištenje alata za upravljanje konfiguracijama (Configuration Management)
o Korištenje dodatnih pomoćnih alata u fazi razvoja
ƒ Alati za traženje grešaka (debuggers)
ƒ Alati za statiču analizu koda
ƒ Alati za automatsko generiranje dokumentacije
ƒ Alati za testiranje performansi (profilers)
o Konfiguracija gornjih alata treba biti automatizirana i dostupna putem CM-a
• Testno okruženje
o Integracija CM alata sa alatima za praćenje pogrešaka
o Sve greške na sustavu trebaju se evidentirati kroz sustav za praćenje grešaka
o Izmjene izvornih datoteka omogućeno samo ako postoji otvoreni nalog (issue ticket) u sustavu za
praćenje pogrešaka
• Produkcijsko okruženje
o Automatska produkcija inačice softvera uz pomoć CM sustava
o Produkcija je moguća samo ako su rezultati testova
• Elementi sigurnosti sustava
Uključivanje sigurnosnih mehanizama u fazi razvoja efikasnije je i ekonomičnije nego u fazi kada je proizvod već
izražen.
Tehnike analize rizika i otkrivanja kritičnih točaka često se koriste u identifikaciji, klasifikaciji i upravljanju
uklanjanja ili smanjenju radnji vezanih za pojavu opasnosti.
• FMEA – Failure Mode Effect Analysis
Potekao iz svemirske industrije (Apollo program)
o Definira 3 osnovna koraka i pripremu
ƒ Priprema
ƒ Opisati sustav i njegovu funkcionalnost
ƒ Izrada bloka dijagrama sustava
o Osnovni koraci - Izrada tablice za analizu
ƒ Učestalost
ƒ Ozbiljnost
ƒ Detekcija
o FMEA Tablica
ƒ Tablica omogućuje analizu svake funkcije sustava i identifikaciju neželjenih efekata.
ƒ Svi uzroci i neželjene popratne pojave se određuju hipotetski
ƒ Određuju se vjerojatnosti pojedinih uzroka, ozbiljnost efekata i razina otkrivanja
ƒ Na kraju se određuje indeks rizika za svaki mogući uzrok
• Nepovredivost
• Onemogućavanje nepravilne izmjene podataka ili funkcionalnosti sustava
• Način pristupa podacima i prijenosa podataka
• Korištenje tehnika kodiranja informacija radi očuvanja integriteta podataka
• Dostupnost
• Postupci dupliciranja podataka
• Definiraju se metode sigurnosti nad podacima
 • Povjerljivost
• Odnosi se na podatke u sustavu i procedure u samom programu
• Definiranje različita prava pristupa pojedinim podacima u sustavu
• Enkripcija podataka
Trendovi u razvoju sustava
• ISO 9000
• ISO 27000
• IEEE
• SEI/CMM
• SIX SIGMA
• ISO 12207
• Agile metodologije
• Arhitektura aplikacija
o ISO 9000
ƒ Familija standarda za upravljanje kvalitetom,Uključuje različite vrste procesa (Revizija
ugovora,Dokumentiranje,Dizajn,Razvoj,Testiranje,Uvonenje,Podrška,Održavanje)
o ISO 12207
ƒ Pripada ISO familiji normi (International Standard Organization)
• Definira ukupno 23 procesa, 95 aktivnosti, 325 zadataka i 224 ishoda
• 5 osnovnih procesa:
– Prikupljanje
– Opskrba
– Razvoj
– Izvršavanje
– Održavanje
– 8 procesa podrške:
• Dokumentiranje
• Upravljanje konfiguracijom
• Kontrola kvalitete
• Verifikacija i testiranje
• Validacija
• Grupna provjera
• Revizija
• Rješavanje problema
– 4 organizacijska procesa:
• Upravljanje
• Infrastruktura
• Usavršavanje
• Trening
– Norma omogućuje prilagonavanje procesa specifičnom okruženju.
– Certifikat norme se odrenuje nadgledanjem performansi procesa, aktivnosti i zadataka
o ISO 27000
ƒ Familija standarda za informacijsku sigurnost:
-Zahtijevi za Sustav Upravljana Sigurnošću Informacija
-Pravila dobre prakse za upravljanje sigurnošću informacija
o IEEE - www.ieee.org
Institute of Electrical and Electronics Engineering
• Propisuje skup standarda na području elektrotehnike, elektronike i računarstva
o 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,IEEE Standard for Software Verification and Validation Plans
• IEEE Std 1012-1998,IEEE Standard for Software Verification and Validation
• IEEE Std 1059-1993,IEEE Guide for Software Verification and Validation Plans
o Standardi razvoj sustava
• Standards for Software Quality Assurance Plans,IEEE/ANSI Std 730
• 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-1997 IEEE Standard for Developing Software Life Cycle Processes
• IEEE Std 1209-1992 IEEE Recommended Practice for the Evaluation and Selection of CASE Tools
o Standardi iz područja elektronike i računarstva:
• Standards for Software Quality Assurance Plans,IEEE/ANSI Std 730
• Standard for Floating Point Arithmetic, IEEE 754
• Standard for Serial Bus Interface (Firewire), IEEE 1394
• Standard for bi-directional parallel communication,IEEE 1284
• Standards for wireless area network, IEEE 802.11x
• Group of Broadband wireless Access Standards (WiMAX), IEEE 802.16
o SEI/CMMI Software Engineering Institue,Capability Maturity Model Integration
• Odrenuje zrelost razvojnog procesa :Organiziran skup elemenata koji opisuju odreneni aspekt
zrelosti u organizaciji i pomaže pri definiranju i razumijevanju organizacijskog procesa
• Početno definiran od strane američke vlade :Skup alata za ocjenjivanje kvalitete razvojnog procesa
ugovaratelja poslova vezanih uz razvoj softvera
Definira 5 nivoa zrelosti u organizaciji
– Inicijalni (initial) - kaotičan, ad-hoc
• Razvojni procesi slabo dokumentirani
• Razvojni proces teško ponovljivi
• Nedefinirana organizacijska struktura
– Ponovljivi (repeatable) - PM, projektna disciplina
• Pojedini razvojni procesi su ponovljivi
• Procesna disciplina nije stroga
– Definiran (defined) – institucionaliziran
• Postoji skup definiranih i dokumentiranih procesa
• Razvojni proces je ponovljivi
– Upravljiv (managed)
• Koristeći metriku razvojnog procesa omogućuje jednostavno praćenje procesa
• Mogućnost podešavanja i prilagonavanja procesa pojedinim projektima
– Optimizirajući (optimizing) – poboljšanje razvojnog procesa
• Kontinuirana optimizacija procesa
Unutar svakog nivoa postoje 5 procesno ključna područja:
• Ciljevi
• Obaveze
• Sposobnosti
• Mjerljivost
• Verifikacija

SIX SIGMA
– Poslovna strategija početno razvijena unutar tvrtke Motorola 1986. godine
• Metrika :3.4 DPMO
• Metodologija:DMAIC, DMADV
• Sustav upravljanja
• Cilj:
– Prepoznavanje i uklanjanje pogrešaka u procesu proizvodnje i razvojnom procesu radi postizanja
visoke razine kvalitete ( 99,9997 % )
– U softverskoj industriji primjenjuje se na samom kodu i na operacijama koje taj kod izvodi
• Defective Parts per Million Opportunities
One Sigma = 690000 DPMO = 31% efficiency
Two Sigma = 308000 DPMO = 69.2% efficiency
Three Sigma = 66800 DPMO = 93.32% efficiency
Four Sigma = 6210 DPMO = 99.379% efficiency
Five Sigma = 230 DPMO = 99.977% efficiency
Six Sigma = 3.4 DPMO = 99.9997% efficiency
o Primjena six sigma metode u razvojnom procesu fokusira organizaciju na:
• Razumijevanje i rukovanje zahtijevima 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
o Temelji metodologije predstavljaju dva modela:
1.DMAIC (model za usavršavanje razvojnog procesa)
2.DMADV (model za razvoj novih proizvoda ili procesa)
1.DMAIC model:
• Define opportunity
• Measure performance
• Analyze opportunity
• Improve performance
• Control performance
2.DMADV model Poznat i pod imenom DFSS – (Design For Six Sigma)
• Define design goals
• Measure and identify CTQs
• Analyze to develop and design alternatives
• Design details
• Verify the design
Alati i metode korišteni od strane SIG SIGMA
• 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
• SIPOC analysis (Suppliers, Inputs, Process, Outputs,Customers)
• StratificationQuantitative marketing research through use of Enterprise Feedback Management (EFM)
systems
o Agile metodologije
• 11.-13.02.2001 Snowbird skijalište, planine Wasatch ,američka savezna država Utah
• 17 osoba i područja razvojnih metodologija zajednički raspravljalo kako razvoj softvera učiniti bržim,
lakšim i kvalitetnijim
• Definirali tzv. Agile manifest u kojem opisuju osnovne principe Agile metodologije
ƒ Osnovne karakteristike:
• Prilagodljivost zahtjevima korisnika
• Češće isporuke, manje izmjene
– tendencija razbijanja većih projekata na više manjih
• Naglasak na testiranje
• Veća komunikacija izmenu članova tima
ƒ Skup razvojnih metoda
• 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
ƒ Agile tehnike
• TDD – Test Driven Development
• BDD – Behavior Driven Development
• Continuous Integration
• Pair programming
• Planning Poker
• RITE Method
Arhitektura aplikacija
ƒ SOA
ƒ multi tier
Multi-Tier aplikacije
• 2-tier
– klasična klijent-server arhitektura
– klijent :prezentacijski i aplikacijski sloj
– Server:podatkovni sloj
• 3-tier
– aplikacijska logika smještena na posebni server
• n-tier
– aplikacijska logika distribuirana na više servera
Multi-Tier Arhitektura
– Prezentacija
– Aplikacija
– Podaci
Tehnike i metode dizajna software-a
Poželjne karakteristike softvera
• Pouzdanost (Povratni rezultat programa odgovara početno definiranim zahtjevima uz minimalno
odstupanje)
• Nadogradivost (Mogućnost lake nadogradnje/izmjene softvera)
• Iskoristivost (Mogućnost korištenja pojedinog dijela softvera u druge namjene)
• Robusnost (Stabilnost izvođenja neovisno o nepravilnostima u ulaznim podacima, okruženju)
Dekompozicija
• Top-down
o Sustav se dijeli na više manjih podsustava koji se implementiraju zasebno (analiza)
o Karakteristika razvoja s proceduralnim jezicima
• Bottom-up
o Integracija manjih jednostavnih komponenti u kompleksni sustav (sinteza)
o Prisutan kod razvoja s objektno orijentiranim jezicima
Modularnost
• Kohezija (Mjera za određivanje stupnja povezanosti elemenata unutar istog modula.Bolja kohezija
znači i bolji dizajn)
 • Uparenost (Mjera za određivanje stupnja povezanosti)
• Dostatnost (Modul sadrži dovoljno svojstava apstrakcije za suvislo korištenje)
• Potpunost (Modul sadrži sva suvisla svojstva apstrakcije)
• Primitivnost (svojstvo operacije da se može izvršiti samo direktnim pristupom na temeljni prikaz
apstrakcije)
Programske paradigme
• Deklarativno programiranje
• Imperativno programiranje
• Komponentno programiranje
• Meta programiranje
Deklarativno programiranje
• U ovu skupinu spadaju slijedeće paradigme
o Funkcionalno programiranje
o Ciljem navođeno programiranje
Suprotno imperativnom programiranju ne definira slijed naredbi kako riješiti neki problem, već skup pravila kojima se
definira što treba riješiti.Programi se satoje od niza formalnih pravila.
• Funkcionalno programiranje
o Koraci obrade izvršavaju se nalik matematičkim funkcijama
o Izrazi su sastavljeni od funkcija koje uporabljaju osnovne vrijednosti
o Programski jezici: (LISP, Haskell)
Imperativno programiranje
• Nestrukturirano (Iterativno)
• Strukturirano
ƒ Proceduralno programiranje
ƒ Modularno
ƒ Objektno orijentirano programiranje
ƒ Aspektno orijentirano programiranje
Naredba=najmanji element i imperativnom programu
Imperativni program=skup naredbi koje mijenjaju njegovo stanje;definiran slijed naredbi koje računalo treba izvršiti
Programski jezici ove skupine=Fortran, Pascal
• Strukturirano programiranje
o Uveo Edsger W. Dijkstra u kasnim 60ima (Razumljiviji kod,Minimiziranje grešaka)
o Niz pravila kako napraviti dobar softver (Izbjegavanje goto i jump naredbi)
o Usko vezano uz proceduralno programiranje
• Proceduralno programiranje
o Vrsta imperativnog programiranja u kojem su naredbe strukturirane unutar procedura
o Dekompozicija programa na dijelove (module - units)
o Svaka dio se sastoji od procedura ili funkcija koje obavljaju jednostavnije zadatke
• Modularno programiranje
o Modul:
ƒ Skup rutina koje zajedno obavljaju neku globalnu funkciju
ƒ Logički neovisna cjelina
ƒ Ima definirano sučelje
ƒ Elementi sučelje su globalno vidljivi ostalim modulima
o Ada, Fortran, Pascal, Modula-2, Perl, Python, Ruby
• Objektno orijentirano programiranje
o Program je skup objekata koji međusobno komuniciraju
o Objekt može biti fizički (vidljiv i opipljiv) ili konceptualan (rezultat je procesa apstrakcije).
o Svaki objekt ima definirane operacije i svojstva
o Opis objekta definiran klasama
• Aspektno orijentirano programiranje
o Složene sustave nije lako moguće opisati pomoću jedne paradigme
o Aspekt
ƒ predstavlja svojstvo sustava i ne opisuje njegovu funkcionalnost
ƒ često se presijeca sa drugim aspektima na raznim mjestima unutar koda
o Pojmovi:
ƒ Concern (Svojstva programa)
ƒ Core concern (Osnovno svojstvo nekog dijela programa)
ƒ Cross-cutting concern (Dodatna svojstva programa raspršena unutar različitih
dijelova programa)
ƒ Advice (Postupak definiranja koda koji će se izvršiti na određenoj točki spajanja)
ƒ Aspect (Opis svojstva sustava)
ƒ Točke spajanja (join points):Mjesto pokretanja advice-a
ƒ Pointcut (Postupak definiranja točki spajanja)
ƒ Uplitanje (Weaving) :Spajanje aspekata na nivou izvršnog koda
• Komponentno programiranje
o Komponenta
ƒ Softverski paket ili modul koji sadrži skup zadanih operacija i podataka
ƒ Svi procesi sustava su odjeljeni u zasebne komponente
ƒ Svaka komponenta ima definirano sučelje putem koje omogućuje obavljanje
određene funkcionalnosti
ƒ Predstavlja baznu platformu za servisno orijentirane sustave.
ƒ Koriste se u web servisima i SOA
 • komponente se nadgrađuju u servise
• Metaprogramiranje
o Metaprogrami = Programi koji mogu manipulirati kodom drugih programa ili sebe samih
o Metajezik = Jezik kojim je pisan metaprogram
o Refleksivnost = Svojstvo programskog jezika koji je sam svoj metajezik
o Refleksivno programiranje = Svojstvo kojim programa može opažati i mijenjati vlastitu
strukturu i ponašanje
Nasljeđeni sustavi
• Stari sustavi unutar organizacija, koji su važni za normalan rad organizacije
• Osobine
o “mission critical” aplikacije
o Sustav u koji je uložena velika količina sredstava
o Glomazni sustavi raspodjeljeni na više aplikacija
o Sustavi razvijeni prije više desetljeća
o Pisani u jezicima ranih generacija (asm, COBOL
o Slabo dokumentirani
o Najčešći dizajn je “function oriented”
o Koriste IPO logiku (Input - Process – Output)
o Koriste strare sustave za upravljanje bazama podataka, često baziranim na tekstualnim
datotekama
Prikaz podataka u memoriji:
• LittleEndian, BigEndian (Redoslijed znamenki heksadecimalnih brojeva u memoriji)
• Dvojni komplement (Prikaz cijelih brojeva sa predznakom)
• LBC (Lead by Count), TBZ (Tail by Zero) : (Nizovi znakova)
• IEEE 754 (prikaz brojeva sa pokretnim zarezom)
• ASCII, EBCDIC, UNICODE (Kodiranje znakova)
Tipovi podataka
• Brojevi (cijeli, realni, kompleksni, sa ili bez predznaka)
• Adrese (Cijeli brojevi koji se odnose na lokaciju u memoriji računala)
• Znakovi (Kodirani (ASCII, EBCDIC, UNICODE))
• Niz znakova (Može biti zaseban tip ili polje znakova)
Organizacija podataka u programu
- Varijabla:
Simbol koji pohranjuje vrijednost koja se može mijenjati
Pohranjeni podatak određen je svojim tipom
– Struktura :
Skup neovisnih podataka koji zajedno tvore informacijski skup
Mogu se vektorizirati – polje struktura
Implementacija struktura podataka
o Homogena organizacija podataka
• Homogeni prostor memorije podijeljen na dijelove jednakih dimenzija
• U programu pristup elementima vrši se putem indeksa
• Na nižoj razini koriste se pokazivači
o Nehomogena organizacija
• Svaki element strukture može biti u bilo kojem dijelu memorije
• Element strukture sadrži prostor za podatke i pokazivač na idući/iduće element(e) u strukturi
• Pokazivači se koriste na višoj razini (unutar programa)
Strukture podataka:
• Polje
• Lista
• Red
• Stog
• Skup
• Mapa
• Stablo
• Graf
1.Polje (Array)
• zbirka od elemenata jednakog tipa podataka
• sadrži unaprijed definiran broj elemenata
• nije moguće naknadno mijenjati broj elemenata polja
• može biti višedimenzionalno
– 1D vektori, 2D matrice, …
• elementima se pristupa putem indeksa koji definiraju poziciju unutar polja
2.Lista (List)
• Povezana
– koristi pokazivače (adrese) za pristup elementima
• Dinamička
– Koristi organizaciju polja za pohranu/pristup elementima
-broj elemenata u listi ograničen je jedino memorijskim prostorom
-Primjer operacija nad elementima liste : add,get,remove,set,size
• jednostruko povezana lista
• dvostruko povezana lista
• cirkularna lista
3.Red (Queue)
 • FIFO (First-In-First-Out) princip pisanja-čitanja
• Odvojen ulaz i izlaz za podatke
• Primjer operacija nad elementima reda :add,peek,poll
4.Stog (Stack)
• LIFO (Last-In-First-Out) princip pisanja-čitanja
• Zajednički ulaz i izlaz podataka
• Primjer operacija nad elementima stoga:push,pop,peek,empty,search
5.Skup (Set)
• Zbirka jedinstvenih podataka – nisu dozvoljeni duplikati
• Može se implementirati koristeći polje, povezane liste, stabla ili hash tablice
• Primjer operacija nad elementima skupa:add,remove,contains, size,clear
6.Mapa (Map)
• Zbirka parova (ključ, podatak)
• Svi ključevi u mapi su jedinstveni (skup ključeva)
• Operacije :put,get,remove,containsKey,containsValue,size,clear
7.Stablo (Tree)
• Vrste
– Binarna stabla, B-stabla, AVL stabla, …
• Karakteristike
– Izrazito brz dohvat podataka
– Koriste se pri indeksiranju baza podataka
» Informix, MySQL - B-stabla
– Koriste ih datotečni sustavi za organizaciju datoteka
» Windows NTFS - B-stabla
» Sun Solaris ZFS - AVL stabla
8.Hash tablice
• Svaki podatak treba imati definirani ključ (npr. Ime, Adresa, JMBG ... )
• Hash funkcija kao argument uzima ključ podatka te generira vrijednost (hash) koja označava poziciju
elementa u tablici (polju).
• Kolizija = – generirani hash već postoji, tada se elementi pohranjuju u listu
• Vrijeme dohvata jednako vremenu izračunavanja hash koda za pojedini ključ
• Pogodne za u aplikacijama gdje se traži brza dostupnost podataka
• Koriste ih programi prevoditelji (compilers)
9.Grafovi
• Graf G sastoji se od dva skupa
– G = (V,E), – V – skup čvorova, – E – skup grana – par elemenata iz V;» E = ( vx, vy )
• Usmjereni i neusmjereni grafovi
• Incidencija
• Susjedni čvorovi :Čvorovi povezani jednom granom
• Put (B):Skup čvorova i grana izmeñu polaznog i završnog čvora
• Ciklus (C):Zatvoreni put – put kod kojeg su početni i završni čvor jednaki
• Povezani graf (A, B, C):Za svaka dva čvora postoji put s početkom u jednom čvoru i krajem u drugom
čvoru.
• Slobodno stablo (E)
– Graf bez ciklusa
10.Algoritmi
– Big O notacija
• Koristi se kod definicije se složenost algoritama:
• O(k) – konstantna složenost
– push, pop kod stoga
• O(n) – linearna složenost
– linearno pretraživanje liste
• O(nk) – polinomijalna složenost
– Bubble sort algoritam
• O(log n) – logaritamska složenost
– Binarno pretraživanje sortirane liste
• O(n*log n) – “n log n” složenost
– QuickSort, MergeSort algoritmi sortiranja
• O(an), (a>1) – eksponencijalna složenost
– Rekurzivni Fibonacci, mostovi Hanoja
O(k) < O( log n ) < O (n log n) < O (nk) < O (an)
– Sortiranje
• Quick sort
• Heap sort
• Merge sort
• Shell sort
• Bubble sort
-Algoritmi za pretraživanje podataka
• Linearno pretraživanje
o Uspoređuju se sve vrijednosti u polju/listi
o Potrebno je prosječno N/2 usporedbi za pronalaženje podataka
o Radi na sortiranim i nesortiranim podacima
o Složenost algoritma je O(N)
• Binarno pretraživanje
 o Radi isključivo na sortiranim podacima
o Prosječan broj usporedbi je: log2(N)- 1
o Složenost algoritma je O(log N)
Programski jezici
• Podjela na generacije: 1GL, 2GL, 3GL, 4GL, 5GL
• Podjela s obzirom na proces prevođenja i izvođenja
o „kompajlerski jezici”
o skriptni (interpreterski) jezici
• Strojni jezici (1GL)
o Naredbe predstavljaju skup binarnih ili heksadecimalnih brojeva
o Naredbe su usko vezane uz računala na kojima se izvode
• Mnemonici – assemblers (2GL)
o Strojne naredbe su predstavljene u simboličkom obliku
o Jedna simbolička naredbe predstavlja ekvivalent jednoj strojnoj naredbi
o Naredbe su i dalje usko vezane uz arhitekturu procesora na kojoj se izvode
• Viši programski jezici – (3GL) Cobol,Basic, C,C++,Fortran,Java,Pascal
o Jedna naredba višeg programskog jezika se prevodi u više strojnih naredbi
o Programi nisu usko vezani uz arhitekturu procesora
• Jezici četvrte generacije (4GL) SQL, RPG IBM
o Neproceduralni jezici
o Smanjuju složenost, vrijeme i troškove razvoja
o Zbog specifične namjene često se uspoređuju sa tzv. Domain specific programming
lanugages
o Rijetko se prevode u mašinski kod, češće se interpretiraju prilikom izvođenja
• Jezici pete generacije (5GL) Prolog,Mercury,OPS5
o Programski jezici orijentirani na rješavanje problema
ƒ problemi umjetne inteligencije
o Ne izvršavaju algoritme
o Koriste predikatnu logiku
Faze prevođenja programa
• Preprocesiranje
o Prevodi direktive koda ( # )
o Prevodi makro naredbe
• Prevođenje
o Provjerava ispravnost koda
ƒ Leksička analiza
ƒ Sintaksna analiza
o Generiranje međukoda
• Optimiranje (opcionalno)
o Po potrebi optimira korištenje memorije ili pokušava generirati brži kod
ƒ Optimira korištenje registara
• Generiranje strojnog koda
o Pretvorba assemblerskog koda ili međukoda u strojni jezik
o Stvara se tzv. objektni kod
o Adrese globalnih podataka i funkcija su relativne
• Povezivanje
o Povezuje objektni kod sa standardnim bibliotekama
o Definira apsolutne adrese za globalne podatke i funkcije
o Generira izvršnu datoteku
Objektno orijentirano programiranje
• Objekt
o Stanje
ƒ Ugrađena svojstva objekta i trenutne vrijednosti tih svojstava.
ƒ Mijenja se kao posljedica ponašanja objekta
o Ponašanje
ƒ Reakcija objekta na promjene stanja i primanje poruka.
o Identitet
ƒ Svojstvo po kojem se neki objekt jednoznačno razlikuje od ostalih.
ƒ Nije određeno samo njegovim stanjem ili samo načinom pristupa.
• Klasa
o Definira svojstva i operacije objekta
o Predstavlja nacrt/predložak koji opisuje svojstva i ponašanja objekta
o Svojstva (varijable/atributi)
o Ponašanje (operacije/metode)
• Operacija nad objektima
o Konstruktor (inicijalizacija objekta)
o Destruktor (oslobađanje stanja objekta)
o Modifikator (mijenjanje stanja objekta)
o Selektor (dohvaćanje stanja objekta bez izmjene istog)
o Iterator (dohvat svih dijelova objekta po unaprijed određenom redoslijedu)

Operatori (Omogućuju određene operacije)

• Poredbeni operatori : >, < , >=, <=, ==, !=
 • Aritmetički operatori – +, -, *, /, %
• Logički operatori & (logički i ), | (ili), ! (ne)
• Bitovni operatori &, |, ^, >>, << ,~ ( jedinični komplement)
• Operatori pridruživanja =, +=, -=, *=, %=, /=, \=, >>=, <<=
• Operatori promjene tipa (cast operatori) – (novi_tip)
• Ternarni operator ‘?’
Testiranje
• Projekt
o Rezultat unaprijed točno definiranog napora
o Ne smije se voditi metodom pokušaja i pogrešaka
o Potrebne su prikladne metode i alati za nadgledanje, verifikaciju i korekciju
o Uspješnost ovisi o mjeri koliko su zadovoljeni zahtjevi korisnika
• Validacija
o Postupak utvrđivanja sukladnosti softvera s zahtjevimakorisnika
ƒ Korisnički zahtjevi prikupljaju se u fazi analize
ƒ Metode i tehnike prikupljanja zahtjeva često mogu biti nejasne, nepotpune i
netočne
ƒ Korisnik ne može, ili ne zna precizno opisati zahtjeve
o Zbog neformalne prirode definiranja zahtjeva, ne pružaprihvatljiv nivo pouzdanosti i
točnosti proizvoda
• Verifikacija
o U odnosu na validaciju je komplementarna aktivnost
o Zahtjeva korištenje formalnih zahtjeva
ƒ Sustavne, potpune i dobro definirane strukture, metode i tehnike
• Neispravnost (failure)
o Loše funkcioniranje programa kao posljedica njegovog ponašanja, a ne njegove strukture ili
izvornog koda
• Pogreška (error)
o “bug”
ƒ Sinonim za nepravilnost ili kvar
o IEEE
ƒ pogreška = izvor nepravilnosti
o Vrste pogrešaka
ƒ Konceptualne pogreške u fazi razvoja
ƒ Uzrokovane krivom interpretacijom zahtjeva
ƒ Uzrokovane nepoznavanja razvojne okoline
ƒ Uzrokovane greškom pri tipkanju ili nepažnjom
• Tehnike verfikacije softvera
o Formalno testiranje
ƒ Cilj: dokazivanje nepostojanja nepravilnosti u programu
o Testiranje
ƒ Statička analiza
ƒ Dinamička analiza
o Traženje pogrešaka (debugging)
• Statička analiza koda
o U procesu prevođenja izvornog koda mogu se pronaći osnovne pogreške u programu
ƒ Leksička analiza
ƒ Sintaksna analiza
ƒ Provjera tipova
o Korištenjem dodatnih opcija prevoditelja moguće je otkriti potencijalne izvore grešaka u
obliku upozorenja (warnings)
o Prevoditelji ne mogu otkriti sve nepravilnosti u kodu
o Greške koje se otkrivaju statičkom analizom
ƒ Podatkovne pogreške
• Korištenje varijabli prije deklaracije
• Nekorištenje deklariranih varijabli
• Dvostruko dodjeljivanje vrijednosti varijabli bez prethodnog korištenja
• Pristup elementima polja izvan deklariranog područja
• Nedeklarirane varijable
ƒ Kontrolne pogreške
• Nedohvatljiv kod
• Bezuvjetan skok u petlju
ƒ Ulazno/Izlazne pogreške
• Ispis varijable bez prethodne dodijele vrijednosti
ƒ Greške sučelja
• Krivi tip parametara
• Krivi broj parametara
• Ignoriranje povratne vrijednosti funkcije
• Nekorištene funkcije i procedure
ƒ Greške s pokazivačima
 • Neinicijalizirani pokazivači
• Greške u pokazivačkoj aritmetici
• Dinamička analiza koda
o Otkrivanje pogrešaka prilikom izvršavanjaprograma
o BlackBox
ƒ Funkcionalni test
ƒ Ignorira se interna struktura programa
ƒ Unit, Integration, Regression
o WhiteBox
ƒ Strukturalni test
ƒ Detaljno testiranje internih struktura programa
ƒ Driver, Stub
ƒ Vrste WhiteBox testova
• Basis Path Testing
• Control-flow/Coverage Testing
• Data Flow Testing
• Failure (“Dirty”) Test Cases
• Integracijsko testiranje
o Testiranje sustava kao cjeline
o Inkrementalno testiranje
ƒ Jednom testirani dio programa proširuje se novim dijelovima
ƒ Potrebno je manje “driver” i “stub” dijelova
ƒ “top-down” ili “bottom-up” strategija testiranja
o Neinkrementalno testiranje
ƒ Svi dijelovi sustava, koji su već zasebno testirani, testiraju se zajedno
• Sistemsko testiranje
o Stress testiranje
ƒ Testiranje ponašanje sustava pri opterećenjima većim od specificiranih u
zahtjevima
o Sigurnosno testiranje
ƒ Testiraju se svojstva privatnosti i prava pristupa pojedinim dijelovima sustava
o Konfiguracijsko testiranje
ƒ Testiranje sustava u svim mogućim konfiguracijama definiranim prilikom dizajna
sustava
• Testiranje prihvatljivosti
o Pokreće ga krajnji korisnik koristeći upute za uporabu, instalaciju i konfiguraciju sustava
dostavljen od strane proizvođača istog
• Regresijsko testiranje
o Testiranje nove verzije sustava kao posljedica ispravljanja pogrešaka i/ili dodavanja novih
funkcionalnosti u sustav
o Verificira se kompatibilnost i razlike nove verzije sustava u odnosu na staru verziju
o Često se provodi u sklopu automatiziranih testovi
• Traženje pogrešaka – debugging
o Postupci verifikacije i validacije u svrhu ispravljanja pogreške koja uzrokuje nepravilno
izvođenje programa
o Omogućava otkrivanja manjeg broja pogrešaka u istom vremenskom roku u usporedbi s
postupkom testiranja
Dokumentiranje
• Potrebe dokumentiranja
o Edukacija
ƒ Predstavlja izvor informacija za edukaciju novih zaposlenika, ili vanjskih suradnika
o Komunikacija
ƒ Sredstvo komunikacije između razvojnih timova
ƒ Koristi se i od strane odjela za podršku/pomoć
o Informiranje
ƒ Sadrži informacije korisne za fazu dizajna/razvoja i testiranja
• Dokumentiranje kroz faze razvoja sustava
o Dizajn
ƒ Dijeljenje informacija unutar razvojnog tima vezanih za arhitekturu ili
funkcionalnih zahtjeva
ƒ Usklađuje razumijevanje između razvojnog tima i korisnika
o Razvoj
ƒ Dokumentacija je više tehnički orijentirana
ƒ Specificira razvoja sustava
o Uvođenje
ƒ Priručnik za korisnike
ƒ Upute za uporabu
o Vrste specifikacija
ƒ Neformalna
• pisana je prirodnim jezikom
• omogućuje bolje razumijevanje između razvojnog tima i kupca
• Namijenjena laicima na tehničkom području
• Nedostaci
 o Zbog svoje netehničke prirode potencijalni je izvor nejasnoća
o Nije dobro strukturirana
o Često neprecizna zbog nedostatka pravila vezanih za kreiranje
specifikacije
ƒ Formalna
• Koristi strogo definirana formalna pravila
• Strogi matematički formalizam može predstavljati problem kod
jednostavnih oblika specifikacija
• Prednosti
-Potpuno i strogo definirana u skladu s pravilima korištene sintakse
-Omogućuje korištenje alata za analizu nalik prevoditelju izvornog koda
-Pojedine vrste specifikacija su bliske samim simulacijskim jezicima
o Ovisno o nivou formalizma razlikuju se:
ƒ Operacijski model (Mogućnost preciznog opisa različitih stanja sustava)
ƒ Opisni model (Omogućuje bolje opće razumijevanje modeliranog sustava)
Alati za dokumentiranje:
Pseudo kod
Stablo odluke
Tablica odluke
UML
Pravila vezana uz osobine softvera
o Pravilo promjenjivost
ƒ Sustav se mora mijenjati evoluirati zbog promjena u okolini u kojoj se sustav
koristi
o Pravilo rasta kompleksnosti
ƒ Utvrđivanje strukture sustava koji postaje kompleksniji
o Evolucija velikih softverskih sustava
ƒ Veličina sustava, raspon izlaska novih verzija, broj grešaka
o Stabilnost organizacije
ƒ Konstantna brzina razvoja sustava
o Očuvanje osobina
ƒ Konstantan broj promjena u novim verzijama sustava
Vrste održavanja (IEEE 1219-1993 – Standard for Software Maintenance)
o Korektivno (Ispravljanje pogrešaka)
o Adaptivno (Prilagodba na promjene funkcionalnosti)
o Usavršavajuće (Poboljšanje performansi sustava)