DUNP - Racunarska Tehnika - SE - T3 - PISA, OQT BOX - Verzija 1.0

Dravni Univerzitet u Novom Pazaru Departman tehnikih nauka Raunarska tehnika
Predmet: Softversko inenjerstvo Projekat: Poslovna Inteligentna Simulativna Arhitektura (PISA) Paket: OQT BOX v1.0 Mentor: prof. dr Ljubomir Lazi Tim#3: 1. Miljan Puzovi, br. indeksa 02-017/07 2. Mehdija Puurica, n 02-513/07 3. Muhamed Zogi, br. indeksa 02-509/08
Novi Pazar, mart 2012.
Optimal SQM, OQT BOX
Sadraj
1 Softverska arhitektura................................................................................................ 5 1.1 1.2 2 Definicije ................................................................................................................ 5 Struktura ................................................................................................................. 6
Dizajn arhitekture sistema ......................................................................................... 9 2.1 2.2 2.3 Dvoslojna Klijent-Server arhitektura...................................................................... 9 Troslojna i vieslojna arhitektura klijent-server ................................................... 10 Middleware ........................................................................................................... 13 Middleware istorijat ............................................................................................. 13 CORBA ................................................................................................................ 14 2.4 2.5 Model od sloja do sloja (peer-to-peer) .............................................................. 18 SOA (Service Oriented Architecture)................................................................... 21 SOA istorijat ......................................................................................................... 21 Funkcionalna dekompozicija................................................................................ 22 Dijagram prvog nivoa ................................................................................ 22 Dijagram drugog nivoa .............................................................................. 23 Dijagram treeg nivoa ................................................................................ 24 J2EE Arhitektura .................................................................................................. 25
2.3.1 2.3.2
2.5.1 2.5.2 2.5.2.1 2.5.2.2 2.5.2.3 2.6 3
Modeli ivotnog ciklusa softvera ............................................................................. 29 3.1 3.2 3.3 3.4 3.5 3.6 3.7 Kaskadni model (model vodopada) ...................................................................... 29 V model ................................................................................................................ 30 Iterativno-inkrementalni model (fazni razvoj) ..................................................... 32 Prototipski model.................................................................................................. 33 Model specifikacije rada ....................................................................................... 34 Transformacioni model......................................................................................... 34 Spiralni model....................................................................................................... 35
4 5
Poslovni inteligenta simulaciona arhitektura (PISA) sa aspekta 4+1 pogleda .... 37 Opis projekta PISA ................................................................................................... 41 5.1 5.2 Biznis ideja ........................................................................................................... 41 Ciljevi projekta ..................................................................................................... 41
[1]
5.3 5.4 5.5 5.5.1 5.5.2 6
Koncept projekta................................................................................................... 41 Opis funkcija sistema OptimalSQM ..................................................................... 42 Definicija zahtevi i okviri projekta ....................................................................... 44 Nefunkcionalni zahtevi ........................................................................................ 46 Funkcionalni zahtevi ............................................................................................ 46
OQT-BOX .................................................................................................................. 47 6.1 Osnovne karakteristike OQT BOX-a ................................................................... 48
Testiranje softvera .................................................................................................... 49 7.1 Tehnike testiranja ................................................................................................. 51 Metoda bele kutije "White-box" ......................................................................... 51 Ciklomatska kompleksnost ........................................................................ 52 Metoda crne kutije "Black-box" ......................................................................... 53 Ekvivalentno particionisanje ...................................................................... 55 Analiza granine vrednosti ........................................................................ 55 Tabela odluivanja ..................................................................................... 56 Metoda sive kutije- Gray box ........................................................................... 56 Risk box................................................................................................................ 57 7.2 Metodologija testiranja softverskog proizvoda .................................................... 59 Odreivanje odgovarajueg standarda kvaliteta softvera..................................... 59 Odreivanje strategije testiranja softvera ............................................................. 59 Greke i otkazi ...................................................................................................... 60 Definicija softverske greke ................................................................................. 61 Kljuni aspekti (Key Issues)................................................................................. 61 Uloge u zadacima testiranja (checklist) ............................................................... 62 Estimacija veliine, vremena, napora i trokova OQT-BOX-a ............................ 62 8.1 Merenje broja funkcionalnih taaka ..................................................................... 63 Izraunavanje grubih funkcionalnih taaka .......................................................... 66 Izraunavanje broja podeenih funkcionalnih taaka........................................... 67 Izraunavanje broja linija koda ............................................................................ 68 8.2 Primena 12 Capers Jones-ovih pravila ................................................................. 69 Pravilo 1 - Estimacija veliine izvornog koda ..................................................... 69 Pravilo 2 Estimacija dokumentacije .................................................................. 69 Pravilo 3- Estimacija odudaranja korisnikih zahteva ......................................... 69 Pravilo 4- Estimacija broja sluajeva testiranja ................................................... 69
[2]
7.1.1 7.1.1.1 7.1.2 7.1.2.1 7.1.2.2 7.1.2.3 7.1.3 7.1.4
7.2.1 7.2.2 7.2.3 7.2.4 7.2.5 7.2.6 8
8.1.1 8.1.2 8.1.3
8.2.1 8.2.2 8.2.3 8.2.4
8.2.5 8.2.6 8.2.7 8.2.8 rad 8.2.9 8.2.10 8.2.11 8.2.12 8.3 8.3.1 8.3.2 8.3.3 8.3.4 8.3.5 8.4 8.4.1 9
Pravilo 5- Estimacija potencijalnog broja greaka ............................................... 69 Pravilo 6 Estimacija efikasnosti otklanjanja greke .......................................... 70 Pravilo 7- Estimacija efikasnosti organizovanog otklanjanja greaka ................. 70 Pravilo 8- Estimacija efikasnosti otklanjanja greaka nakon putanja softvera u 70 Pravilo 9- Estimacija trajanja realizacije projekta................................................ 71 Pravilo 10- Estimacija potrebnih ljudi za realizaciju projekta ............................ 71 Pravilo 11- Estimacija ljudi potrebnih za odravanje softvera ............................ 71 Pravilo 12- Estimacija ukupnih napora u realizaciji softverskog projekta ........... 71 Model zrelosti sposobnosti (CCM)....................................................................... 72 CMM Nivo 1 ........................................................................................................ 72 CMM Nivo 2 ........................................................................................................ 73 CMM Nivo 3 ........................................................................................................ 73 CMM Nivo 4 ........................................................................................................ 73 CMM Nivo 5 ........................................................................................................ 73 Cost benefit analiza .............................................................................................. 74 Trokovi osiguranja kvaliteta softvera [22] ......................................................... 75 Pregled konkurentskih reenja ................................................................................ 78 9.1 Mosaic-ov MSTAR paket za testiranje ................................................................ 78 Kljune karakteristike MSTAR paketa ................................................................ 79 Poreenje sa OQT BOX-om ................................................................................ 80 9.2 HP Quality Management solutions (HP ALM,HP Quality Center, HP QuickTest)81 Korist primenom HP ALM .................................................................................. 83 Razliiti scenariji u upotrebi HP softvera ............................................................ 86 Scenario 1: Regresiono testiranje sa HP FunctionalTesting .................. 86 Scenario 2: Test optereenja i performansi sa HP LoadRunner ............. 87 Scenario 3: Uteda kapitala sa HP LoadRunner ..................................... 88 Scenario 88 4: HP Quality Centerekonomija konsolidovanja i
9.1.1 9.1.2
9.2.1 9.2.2 9.2.2.1 9.2.2.2 9.2.2.3 9.2.2.4 centralizacije 9.2.3 9.2.3.1 9.2.3.2 9.2.4 9.3 9.3.1 9.3.2 9.3.3
Poslovni scenariji u upotrebi HP softvera ............................................................ 89 Scenario 1: Zatita prihoda ........................................................................ 89 Scenario 2: Smanjenje rizika od naputanja korisnika............................... 89 HP QuickTest Professional (QTP) ....................................................................... 90 QSM SLIM ........................................................................................................... 95 SLIM Estimate .................................................................................................. 95 SLIM Control .................................................................................................... 96 SLIM Metric ...................................................................................................... 97
[3]
9.3.4 9.3.5 10
SLIM EstimateExpress ................................................................................... 98 Poreenje sa OQT BOX-om ................................................................................ 99 Arhitektura sistema Optimal SQM ....................................................................... 100 Verifikacija i validacija softverske arhitekture ................................................... 100 Optimal SQM CORBA Arhitektura ................................................................ 101 Optimal SQM SOA Arhitektura ...................................................................... 105 Fiziki dizajn OptimalSQM ................................................................................... 115 Lista slika ................................................................................................................. 122 Reference ................................................................................................................. 124
10.1 10.1.1 10.1.2 11 12 13
[4]
1 Softverska arhitektura
Ako elimo da stvorimo uspean sloeni (Enterprise) softverski sistem, moramo imati itav niz slika u svom umu, slika budueg sistema iz mnogo razliitih perspektiva. Moramo nai nain da te slike dobiju stvaran oblik, vidljiv i razumljiv drugim ljudima, jer sloeni (Enterprise) sistem ne moemo stvoriti sami. Realizacija sloenih softverskih sistema je sinergija razliitih znanja i iskustava i kompromis izmeu razliitih miljenja i pristupa istom problemu. Jer ne postoji samo jedno reenje za sve probleme i sve softverske sisteme. Ako elimo da stvorimo uspean sloeni (Enterprise) softverski sistem, moramo imati snanu platformu za razvoj, moramo potovati minuli rad i iskustva naih prethodnika, ali istovremeno biti otvoreni za nova iskustva i dolazee tehnologije. [1] 1.1 Definicije Softverska arhitektura je organizaciona struktura i ponaanje nekog softverskog sistema.1Arhitektura se moe rekurzivno dekomponovati u delove koji sarauju putem interfejsa, relacije koje povezuju te delove i njihova ogranienja. Delovi koji sarauju putem interfejsa su klase, komponente i podsistemi. [1] Softverska arhitektura programa ili raunarskog sistema je struktura sistema, koja ukljuuje softverske komponente, eksterno2 vidljive osobine ovih komponenti i relacije izmeu njih. Softverska arhitektura predstavlja sam problem i domen reenja. Ona treba da omogui efektivno zadovoljenje arhitekturalno znaajnih eksplicitnih funkcionalnih zahteva, zahteva za kvalitetom i implicitnih zahteva proizvodnih linija (Product Families).3 [1] Na osnovu navedenih definicija moemo zakljuiti da softverska ahitektura: predstavlja strukturne elemente i interfejse od kojih je softverski sistem sastavljen. sadri i opisuje veze izmeu strukturnih elemenata softverskog sistema. opisuje ponaanje softverskog sistema, njegovih delova i saradnju izmeu razliitih delova softverskog sistema. sadri skup sutinskih pravila i ogranienja.
etiri najvanija faktora softverskih arhitektura su: Arhitekturalni stil. Konkretna arhitektura iz skupa koji je definisan arhitekturalnim stilom. Komponente i interfejsi. Podsistemi razliitog skupa komponenti. Na slici 1.1 prikazani su osnovni elementi softverske arhitekture (mikro i makro softverske arhitekture) i odnos softverskog sistema i softverske arhitekture.
Sistem je kolekcija povezanih jedinica koje su organizovane kako bi ispunile specifinu svrhu. Sistem moe biti opisanpomou jednog ili vie modela, po mogunosti iz razliitih perspektiva. 2Eksterno vidljive osobine komponenti mogu biti koriene od strane drugih komponenti. 3 Linije proizvoda (Product Families) predstavljaju grupu aplikacija\sistema koja sadri skup funkcionalnosti namenjenspecifinim potrebama odreenog trita.
1
[5]
Slika 1-1 Definicija softverske arhitekture Softverska arhitektura predstavlja opis arhitekturalno znaajnih elemenata softverskog sistema, alijednako koliko predstavlja opis ona predstavlja i konkretne elemente. Preciznije reeno ak i kadasoftverska arhitektura nekog sistema nije formalno opisana, odnosno kada ne postoji njena formalnadokumentacija, smatramo da realizovan softverski sistem ipak ima arhitekturu, jer ona predstavlja stub i osnovu postojanja svakog softverskog sistema. Softverska arhitektura mora apstraktovati neke informacije iz sistema, ali mora omoguiti dovoljno informacija da bi se shvatila sutinska osnova softverskog sistema. Ukoliko nema apstrakcije iizostavljanja nekih tehniko/tehnolokih detalja, tada ne govorimo o arhitekturi, ve o rezultatimadetaljnog projektovanja ili samoj realizaciji, koje je vano razlikovati od same softverske arhitekture. 1.2 Struktura Na osnovu prethodno navedenih definicija, zakljuujemo da softverska arhitektura predstavlja i opisuje strukturu, ponaanje i ogranienja softverskog sistema. Slika 1-2 prikazuje odnos softverskog sistema i njegove arhitekture, njihove osnovne gradive blokove i osnovne naine na koje se struktura,ponaanje i ogranienja realizuju. [1]
[6]
Slika 1-2 Struktura softverske arhitekture Nain na koji se realizuje struktura, ponaanje i ogranienja softverskog sistema zavisi od primenjene strategije projektovanja. Na primer ukoliko je primenjena objektno orijentisana strategija projektovanja, struktura softverskog sistema se predstavlja, odnosno realizuje, pomou klasa i skupa njihovih atributa (osobina). Ponaanje se predstavlja interfejsima i operacijama. Operacije predstavljaju specifikaciju usluga koje od objekta mogu biti zatraene, to ukljuuje naziv, nain na koji operaciju pozivamo (broj i tip argumenata koji se prosleuju pri pozivu) i format povratnih informacija koje se dobijaju kao rezultat izvrenja operacije. [1] Metode predstavljaju realizaciju samih operacija putem odgovarajuih algoritama. Operacije se mogu izloiti potencijalnim korisnicima putem interfejsa koji predstavlja specifikaciju javnih operacija neke klase. [1] Kao to je prethodno navedeno, pored strukture i ponaanja, softversku arhitekturu ine arhitekturalno znaajna ogranienja softverskog sistema. Ogranienja moemo klasifikovati na sledei nain: Vrednosna ogranienja Ogranienja tipa atributa. Ogranienja dozvoljenog skupa vrednosti atributa. Ogranienja meuzavisnosti vrednosti atributa jedne klase ili komponente. Ogranienja meuzavisnosti vrednosti atributa vie klasa ili komponenti. Strukturna ogranienja Ogranienja referencijalnog integriteta. Ogranienja kardinalnosti veza.
Grupisanje srodnih elemenata strukture i funkcionalnosti softverskog sistema je veoma bitno za softverski sistem i njegovu arhitekturu, jer predstavlja jedan od naina kojim se borimo sa sloenou softverskih sistema. Osnovni oblici grupisanja kod objektno orijentisanog i
[7]
pristupa projektovanju orijentisanog na komponente su grupisanje putem paketa, komponenti i podsistema. [1] Komponente predstavljaju skup udruenih elemenata softverskog sistema, koje zajedno pruaju koherentan skup funkcionalnosti kojoj se moe pristupiti putem javnog interfejsa. Dobro definisane komponente imaju jasno definisane interfejse i sposobnost viestruke iskoristivosti u sklopu razliitih softverskih sistema. [1] Softverska arhitektura se moe predstaviti preko softverskih uzora (paterna) koji se koriste u fazi projektovanja softvera, a dele se na uzore makro i mikroarhitekture. [1]
[8]
2 Dizajn arhitekture sistema

Dizajn arhitekture se sastoji od planova koji definiu pojedine komponente sistema, u prvom redu raunarsku opremu, programsku podrku, komunikacije, sistem zatite i globalnu podrku aplikacija. Specifikacija hardvera i softvera je podloga za nabavku opreme. [2] 2.1 Dvoslojna Klijent-Server arhitektura Klijent je jednokorisniki raunar. Sadri interfejs, a omoguava obradu i skladitenje podataka. Poseduje mogunost povezivanja na servere (prema potrebi i na druge klijente). Server je viekorisniki raunar. Omoguava rad sa deljenom bazom podataka, obradu podataka i servisiranje interfejsa. Poseduje mogunost povezivanja sa klijentima i drugim serverima. Korisnicima izgleda kao da jedan raunar obavlja celi posao. [2]
Slika 2-1 Dvoslojna arhitektura klijent-server [2] Prednosti dvoslojne arhitekture klijent-server (slika 2-1) su u izolaciji promena pojedinom sloju, kvalitetnijoj (lakoj) obradi i sredinjem upravljanju integritetom podataka na serveru. Nedostak ove arhitekture je u oteanom odravanju aplikacione logike (programa) na svim klijentima i pojava debelog klijenta. [2] Klasina ema funkcionisanja klijent-server arhitekture moe se videti na Slici 2-2. Pritom, klijent alje upit ka serveru, a server alje odgovor klijentu, to iziskuje odreeno vreme ekanja.
[9]
Slika 2-2 Upit-odgovor ponaanje u K/S arhitekturi [3] Debeli klijent [2] je onaj klijent kod koga je integrisana logika podataka. Nema obrade podataka na serveru ili je obrada minimalna. Poseduje minimalnu ili nikakvu elastinost na promenu poslovne politike. Prednosti debelog klijenta su: brzi poetni razvoj aplikacije, vea samostalnost klijenta i rastereenje glavnog raunara (servera). Moe imati lokalnu bazu podataka. Kao debeli klijenti mogu se koristiti jeftini raunari sa snanim procesorima. Nedostatak je da je poslovna logika integrisana na klijentu. Promena poslovne logike znai instalisanje nove verzije aplikacije na svim klijentima. Velika je mogunost rada sa zastarelim podacima. Ako sa vremenom aplikacija postane spora (zbog koliine podataka), treba promeniti sve klijente. Razvoj velike aplikacije sa vremenom postaje vrlo kompleksan (sav programski kod je na klijentu). Tanki klijent [2] je onaj klijent kod koga se logika podataka nalazi na serveru. Osnovna namena tankog klijenta je prikaz podataka. Veinom se koriste u poslovnim sistemima. Prednosti tankog klijenta su: promena poslovne logike ne znai obavezno i promenu u klijentskom delu aplikacije, promena poslovne logike moe se obaviti centralizovano, raunari ne moraju imati veliku procesorsku snagu, ukoliko sa vremenom obrada postane spora (zbog koliine podataka) moe se jednostavno poveati snaga sredinjeg raunara. Kao tanki klijent moe se koristiti npr. web pretraiva (dobro definisano i svima dostupno). Smanjena je mogunost rada sa zastarelim podacima (gotovo za svaku promenu ide se na server). Manja je kompleksnost razvoja velikih aplikacija (kod je podeljen na serverski deo i klijentski deo). Nedostaci su: veliko optereenje glavnog raunara, a to znai skupi glavni raunar. Ukoliko se kao klijent koristi web pretraiva moraju se potovati njegova ogranienja. Grafiki prikaz tankog i debelog klijenta moe se videti na slici 2-3.
Slika 2-3 Grafiki prikaz debelog i tankog klijenta [3] 2.2 Troslojna i vieslojna arhitektura klijent-server Kod troslojne arhitekture klijent-server (slika 2-4) distribucija baza podataka i poslovne logike je izvrena na zasebne servere, ime je dobijena arhitektura: server aplikacija + server baza podataka + klijent. Namena pojedinog sloja je sledea: Server aplikacija obavlja upravljanje transakcijama "preuzetih" sa servera podataka. Deo ili itava poslovna logika je "preuzeta" sa klijenta; Server baza podataka vri upravljanje podacima;
[10]
Klijent sadri korisniki interfejs. Takoe sadri deo poslovne logike, i to onaj deo koji se ne menja, ili logiku linog karaktera.
Slika 2-4 Komunikacija izmeu slojeva kod vieslojne K/S arhitekture [3]
Slika 2-5 Detaljnija komunikacija izmeu slojeva gde je Web server aplikacioni server Prednosti troslojne arhitekture su: bolja raspodela optereenja, vea skalabilnost, odnosno mogunost ekspanzije (npr. poveanja broja korisnika, bez preoptereenja ili potrebe za promenom procedura). Nedostaci su: sloeni (komplikovani) dizajn i razvoj, problem raspodele podataka, procesa, interfejsa, kao i vee optereenje mree. Vieslojna arhitektura se koristi za razvoj sloenih aplikacija. Programski kod se moe podeliti u vie nivoa, npr.: 1. Kod na prezentacionom sloju - formi (GUI - Graphic User Interface);
[11]
2. Kod u sloju poslovne logike (BLL - Business Logic Layer ); 3. Kod u sloju pristupa podacima (DAL - Data Access Layer); 4. Kod na bazi podataka (stored procedure). esto se vri podela u tri nivoa, i to: klijent - GUI (u web aplikaciji to je web pretraiva), server aplikacija odnosno BLL (npr. web servis) i baza podataka (npr. SQL Server).
Slika 2-6 Troslojna arhitektura klijent-server [2] Bitniji kriterijumi za odabir prave klijent-server arhitekture:
Dvoslojna K/S arhitektura sa tankim klijentima [2] Aplikacije: Nasleeni aplikativni sistemi gde je nepraktino i neisplativo odvojiti aplikativne obrade i upravljanje podacima. Raunarsko-zahtevne aplikacije sa vrlo malo ili bez obrade podataka. Podacima bogate aplikacije (pretraivanje i upiti) sa veoma malo ili bez aplikativne obrade.
Dvoslojna K/S arhitektura sa debelim klijentima [2] Aplikacije: Aplikacije gde se aplikativna obrada izvodi na klijentu sa COTS (Commercial Off-The Shelf Software) programskom podrkom. Aplikacije koje zahtevaju raunarsko zahtevne obrade podataka (npr. vizualizacija podataka interaktivno ili u izvetajima). Aplikacije sa relativno vrstom krajnje - korisnikom funkcionalnou, koriene u sredini gde je dobro uspostavljeno upravljanje sistemom.
[12]
Troslojna ili vieslojna K/S arhitektura [2] Aplikacije: Aplikacije velikog opsega sa stotinama ili hiljadama klijenata Sistemi u kojima su i podaci i aplikacije promenljivi. Aplikacije u kojima se integriu podaci iz viestrukih izvora
2.3 Middleware Middleware je sloj izmeu distribuiranih aplikacija i platformi (operativnih sistema). [3] - Treba da pomogne u postizanju (distributivne) transparentnosti - Sakriva: o Distribuiranost podataka o Distribuiranost procesiranja o Upravljanje iz aplikacija Postojei middleware-i su pratili specifine stilove u arhitekturi: - CORBA; Microsof DCOM adaptiran objektno-orijentisan stil - TIBCO prati stil arhitekture zasnovane na dogaajima Upotreba middleware namee arhitektonski stil - Savremena reenja DS trae prilagodljiv middleware Middleware je sastavni deo savremenih informacionih tehnologija zasnovanih na XML, SOAP, veb servisa, i servisno-orjentisane arhitekture. Slian je srednjem sloju troslojne K/S arhitekture, s tim to se posee kroz vie sistema ili aplikacija.
2.3.1 Middleware istorijat
Pojam middleware se javlja oko 1990. godine, ali middleware sistemi postoje mnogo pre tog datuma. Komunikacioni sistemi kao proizvodi su bili dostupni jos kasnih sedamdesetih godina. Klasina referenca Remote Procedure Call implementacije je Birrell and Nelson 1984, ali prvi slian RPC-u, jeziki specifian konstrukt je postojao i pre toga (originalna ideja o RPC se pojavila 1976. godine). Poetkom osamdesetih, posle brojnih istraivakih projekata pojavila se middleware podrka za distribuirane objekte, to je uslovilo pojavu kasnijih standarda i proizvoda. Rani projekti us bili Cronus i Eden. Kasniji projekti su ukljuili i Amoeba, ANSAware, Arjuna,Argus, Chorus/COOL, Clouds, Comandos, Emerald, Gothic, Guide, Network Objects, SOS, i Spring. Open Software Foundation (OSF), kasnije je postal Open Group, je napravljena 1988. kao pokuaj da se standardizuju I formalizuju razliite verzije Unix operativnog sistema. Kako ovaj cilj nikada nije dostignut, OSF je sprecijalizovala softversko reenje, Distributed Computing Environment (DCE), koji je ukljuivao neke middleware komponente kao RPC servis, distribuirani fajl system, distribuirani vremenski servis, I sigurnosni servis. Object Management Group (OMG) je napravljena 1989. godine i njen cilj je bio da definie standard za distribuirane middleware objekte. Prvi uspeh je bio CORBA 1.0 specifikacija, 1991. godine. Kasnije su se definisali standardi za modelovanje (UML, MOF) i za komponente (CCM). Object Database Management Group (ODMG) definie standard
[13]
primenljive na baze podataka objekata, i pravi vezu izmeu objektno-orjentisanog programiranja I postojeeg upravljanja podacima. Definisanje Java programskog jezika od strane Sun Microsystems kompanije 1995. godine dovelo je do pojave nekoliko middlware izdanja, kao to su Java Remote Method Invocation (RMI) i Entreprise JavaBeans (EJB), Ova dva reenja, pored jo nekih, ujedinjena su u zajedniku platformu J2EE. Microsoft je izneo na trite Distributed Component Object Model (DCOM), middleware baziran na kompozitnim distribuiranim modelima, a 1999. godine i poboljanu verziju COM+. Sledea njihova ponuda je bila .NET, softverska platform za distribuirani razvoj aplikacija i Veb servisa. Prva nauna konferencija u potpunosti posveena samo middleware-u je odrana 1998. godine. Trenutna istraivanja imaju za cilj adaptivni i refleksabilni middleware, kao i middleware za mobilne sisteme.
2.3.2
CORBA
OMG grupa od 1990. godine trai nain obezbeenja interoperabilnosti, kao i reenje problema integracije razliitih sistema ili nekompatibilnih delova istog sistema. CORBA je bio jedan od standarda za obezbeivanje interoperabilnosti, ija je specifikacija nezavisna od implementacione platforme. [4] CORBA predstavlja sutinu specifikacije OMG-ove (Object Managment Group) Object Managment Architecture. On predstavlja tehniku komunikacionu infrastrukturu izgraenu na distribuiranim objektima. Baziran na Object Request Broker-u CORBA arhitektura obezbeuje fundamentalni okvir omoguujui objektno-orijentisani udaljeni poziv procedura kako bi se podrala komunikacija i saradnja objekata koji su distribuirani u sistemu. CORBA je skraenica od Common Object Request Broker Architecture. Sutina ovog pristupa su intrerfejsi koji omoguavaju interoperabilnost razliitih sistema i aplikacija. Kljuni ciljevi i prednosti ovih standarda su ostvarenje interoperabilnosti i portabilnost softverskih aplikacija\sistema nastalih na ovim osnovama. CORBA objekat moe raditi na razliitim platformama odnosno operativnim sistemima i moe biti realizovan razliitim programskim jezicima. Primeri jezika kojima ovi objekti mogu biti realizovani su C, C++, Java, Cobol, Ada i Smalltalk. Javni interfejs CORBA servisa ili objekta definisan je jezikom ija je osnovna osobina nezavisnost od programskog jezika pomou koga e objekat ili servis biti implementiran. Ovaj jezik se naziva jezik za definiciju interfejsa (engl. Interface Definition Language - IDL). CORBA je kao okvir za implementaciju distribuiranih interoperabilnih sistema predstavljala velik korak u pravcu ostvarenja OMG ciljeva. OMG grupa se nije na tome zaustavila, ve je otila mnogo dalje. Cilj i obim istraivanja se krajem devedesetih godina prolog veka bitno proirio, a rezultat toga su bili standardi UML, MOF, XML (XMI) i Common Warehouse Model (CWM). 2001. godine OMG grupa je usvojila i promovisala MDA kao novi pristup korienju modela u razvoju softvera. Tehniki gledano, object adapter predstavlja vezu izmeu ORB-a i odgovarajue implementacije objekta. Object adapter povezuje CORBA objekte koji su specificirani pomou IDL-a. Kada ORB primi zahtev klijenta on rutira ovaj zahtev do ORB-a na serverskoj strani.
[14]
Zatim, ORB na serverskoj strani prenosi zahtev do object adaptera. Object adapter zatim treba da odredi prema kojoj implementaciji objekta treba da se prosledizahtev. [4] Unutar okvira CORBA specifikacije standardizovana su dva objekt adaptera: Basic Object Adapter (BOA) Portable Object Adapter (POA)
Basic Object Adapter je bio prvi object adapter koji je specifikovan od strane OMG-a, ali je ova specifikacija dosta kritikovana. Zbog neprecizne BOA specifikacije javljaju se problemi postavljanja postojeih apliakcija sa drugim ORB-ama. Ovo je uticalo na zamenu BOA specifikacije sa Portable Object Adapterom kod koga su izbegnuti ovi problemi portabilnosti. Sa specifikacijom POA, OMG uspostavlja po prvi put precizne definicije pojmova klijenta, servera, CORBA objekta, servant-a, identiteta objekta (object ID) i reference objekta. [4] Klijent - raunarski proces koji poziva udaljene operacije na objektu i iz tog razloga pristupa referenci objekta koja postoji za taj objekat. Server raunarski proces u kome postoji implementacija CORBA objekta. Na nivou operativnog sistema on je obino realizovan kao odvojeni proces. CORBA Objekat je virtuelni entitet koji ima identitet, interfejs i odgovarajuu implementaciju. Sa gledita klijenta, CORBA objekat se moe identifikovati preko reference objekta koja sadri identitet objekta. Sa serverske strane gledita identitetom objekta upravlja POA i implementiran je pomou servanta. Servant predstavlja entitet programskog jezika koji postoji u kontekstu servera i implementira IDL interfejs za jedan ili vie CORBA objekata. Servant je odgovoran za opsluivanje zahteva klijenata. Identitet objekta U kontekstu POA, pojam identiteta objekta se koristi da identifikuje odreene CORBA objekte. Identitetima objekta se upravlja pomou POA. Takoe je mogue da su identiteti objekata specifikovani za vreme implementacije serverske aplikacije. Referenca objekta predstavlja vezu izmeu klijenta i servera. On sadri sve informacije potrebne da se pozove operacija na udaljenom objektu. Prema tome, klijent mora imati referencu objekta da bi pozvao CORBA objekat jer referenca objekta enkapsulira detalje lokacije objekta. Interoperable Object Reference sadri IP adresu, broj porta i detalje vezane za identitet objekta. Klijent moe da se povee sa objektom na serveru statiki ako je interfejs servera poznat u vreme obrade. Takoe, klijent moe da koristi dinamiko povezivanje za odreeni server, prepoznavi njegov interfejs i kreiravi poziv ka serveru. Sledea slika (Slika 2-7) ilustruje metod gde klijent poziva server. [5]
Slika 2-7 Ilustracija kijentovog poziva ka serveru [5]

[15]
IDL konpajler se koristi za generisanje serverskog stuba (server stub), takoe poznatog i kao skelet, koji se povezuje sa serverskim programom. Server stub omoguuje statikom interfejsu da pozove metode za implementaciju objekta. IDL kompajler takoe generie prirodni jezik za interfejs koji olakava implementaciju na serveru, to moemo nazvati klijentskim stubom.
Slika 2-8 Kreiranje stubova (stubs) iz IDL opisa [5] CORBA takoe podrava interfejs dinamikog skeleta (dynamic skeleton interface - DSI), koji predstavlja mehanizam za kreiranje serverskih interfejsa u letu. Proces kreiranja statikog CORBA klijent-server modela se opisuje u sledeih nekoliko koraka [5]:
Slika 2-9 CORBA proces [5]
[16]
1. Specifikacija serverskog interfejsa u IDL. 2. Pokree IDL opis preko IDL kompajlera, koji generie interfejs prirodnog jezika, serverski stub i klijentski stub. U ovom koraku, IDL kompajler moe pciono da sauva kompajliran opis interfejsa u skladite (bazu). 3. Implementacija na server. 4. Kompajlira serverski program i prosleuje ga serverskom stubu koji je generisao IDL kompajler. Rezultat je izvrni serverski program koji moe da prihvati zahteve metoda preko CORBA-e. 5. Upisuje server u skladite za implementaciju (baza), navodei ime servera, komande za pokretanje, aktivacioni reim, kao i dozvole za pokretanje i pristup. Server je sada mogue aktivirati. 6. Implementira klijenta. Programer pie server-orjentisane metode pozivanja, koristei sintaksu i prirodni jezik programiranja klijenta. 7. Kompajlira klijentski program, i prosleuje ga klijentskom stubu koji je generisao IDL kompajler. 8. Kada se klijent izvrava, on koristi ORB da se vee za objekat servera i dobije objektnu referencu. 9. Koristei objektnu referencu, klijent poziva na serveru objektne metode. [5] Common Object Request Broker Architecture specifikuje osnovne servise za komunikaciju objekata, a bazira se na mehanizmu RPC-a. ORB konstituie arhitektonske komunikacione komponente i ponekad se naziva kao magistrala objekta ili jednostavno distributer poruka. Zadatak ORB je da uspostavi klijent server vezu izmeu objekata. Klijent je objekat koji poziva operaciju (funkciju) drugog objekta. Implementacija objekta u OMG terminologiji se zove servant, koji odreuje koje akcije trebaju da se izvre kada se operacija objekta pozove tj on definie odgovarajui metod objekta. Nekoliko implementacija objekta je integrisano u jedan izvrni program, koji onda ima ulogu servera. Klijent moe pozvati metod objekta, koji se nalazi na serveru, ili na istoj maini ili je instaliran na drugom raunaru negde na mrei. ORB prohvata poziv i zaduen je za nalaenje objekta koji nudi odgovarajui metod, isporuuje parametre poziva do odgovarajue implementacije objekta i ako ima potrebe za tim vraa rezultate poziva procedure. ORB je takoe zaduen za konverziju podataka u odgovarajui format za prenos. Klijent nema nikakvu informaciju gde se nalazi pozvani objekat, u kom je jeziku implementiran, koji operativni sistem ili hardware se nalazi u raunaru. [5] Skladite za implementaciju (Implementation repository IR) ima zadatak da smeta odnosno da uva definicije interfejsa CORBA objekata. IR sam po sebi predstavlja CORBA server koji treba da bude aktiviran odvojeno od klijentskog i serverskog procesa i moe biti smeten bilo gde u mrei. IR je opisan skupom IDL interfejsa odreujui tako nain kako se IR-u moe pristupiti udaljeno. Kako bi se vodila evidencija o razliitim imenima IDL tipova podataka, IR koristi Identitete Repozitorijuma (Repository Identities), koji predstavljaju jedinstvene nizove identifikatora. Prema tome, identiteti repozitorijuma se takoe generiu i u sluaju da se nijedan Repozitorijum Interfejsa ne koristi, iz razloga to IDL kompajler generie identitete repozitorijuma kada se generiu stub i skeleton fajlovi za CORBA aplikacije. U principu postoje razliiti naini za dobijanje inicijalnog pristupa Repozitorijumu Interfejsa. Bez obzira na izabrani tip pristupa, uvek je mogue odrediti kako je CORBA objekt struktuiran. Na primer, ako je klijent dobio referencu na CORBA objekat, ali nema informaciju o operacijama ili atributima, koje taj objekat ima, klijent moe zahtevati tu informaciju pri pokretanju aplikacije. Pozivanjem odgovarajue operacije, klijent dobija opis interfejsa, koji
[17]
pripada referenci prosleenoj tom pozivu operacije. Prema tome, klijent moe analizirati taj rezultat detaljnije, npr ispitivanjem koji argumente odreena operacija oekuje, koji tipovi argumenata treba da budu i da li treba da postoji povratna vrednost. Prema tome, klijent moe koristiti Dinamiki Poziv Interfejsa (Dynamic Invocation Interface) kako bi se poslao zahtev objektu. U CORBA verziji 2.0, po prvi put je uveden protokol koji omoguuje komunikaciju izmeu ORB-i razliitih proizvoaa. General Inter-ORB Protocol (GIOP), specifikuje standardizovanu sintaksu prenosa, Common Data Representation (CDR), zajedno sa nekoliko formata poruka. Jedna vana karakteristika CDR-a je ta da obezbeuje kompletno povezivanje svih tipova podataka definisanih u IDL jeziku. GIOP definicija ukljuuje sledee formate poruka: Zahtev ovaj format obezbeuje klijentima pristup do implementacije objekta Odgovor uz pomo ovog formata, izlaz odnosno povratna vrednost servera se alje nazad do klijenta. U sluaju da je promenjena lokacija implementacije objekta u formatu odgovor poruke se alje LocationForward poruka koji sadri referencu novog objekta ka kom trebaju da se preusmere novi zahtevi. OtkazivanjeZahteva (CancelRequest) Ovaj format se koristi da obavesti server da klijent vie ne oekuje odgovor za svoj zahtev koji je uputio. Lociranje Zahteva (LocateRequest) -Klijent moe poslati LocateRequest poruku da bi odredio da li je odreena referenca objekta validna ili ne. Lociranje Odgovora (Locate Request) server koristi ovaj format poruke da odgovori na klijentovu poruku LocateRequest. Ovaj odgovor sadri poruku da li je serveru poznat objekat ili ne. Ako je objekat promenio svoju lokaciju a server zna za to, vraa se nova validna referenca objekta. Zatvaranje Konekcije (CloseConnection) Ako server namerava da zatvori konekciju pre vremena i nee da opsluuje bilo koje dalje zahteve, ovaj format e se koristiti. Poruka Greke (MessageError) Ovaj format se koristi od strane klijenta i servera i ukazuje na komunikacione probleme.
2.4 Model od sloja do sloja (peer-to-peer) Peer-to-peer (P2P) arhitektura predstavlja vid distrubuiranog raunarstva u kome svaki vor (eng. node) ima dvostruku ulogu Svaki vor P2P mree komunikaciju sa ostalim lanovima P2P mree obavlja putem simetrinog softvera koji se moe ponaati i kao klijent (zahtevajui podatke ili usluge od ostalih vorova) i kao server (odgovarajui na zahteve ostalih vorova). Na ovaj nain P2P arhitektura omoguava veu autonomiju lanova mree. P2P arhitektura se uglavnom primenjuje kod potreba u kojima postoji vea tolerancija greke kod distribuirane odbrade. [6]
[18]
Slika 2-10 Peer-to-Peer arhitektura [6] Postoji vie razliitih arhitektura unutar P2P arhitekture: 1. decentralizovana arhitektura 2. centralizovana arhitektura 3. hibridna arhitektura Decentralizovana P2P arhitektura predstavlja arhitekturu najbliu osnovnom P2P modelu. Ona je sainjena iskljuivo od peer vorova koji meusobno komuniciraju direktno (Slika 2-11). [6]
Slika 2-11 ema decentralizovane P2P arhitekture Centralizovana P2P arhitektura predstavlja meavinu P2P i klijent-server arhitektura. Kao i kod decentralizovane P2P arhitekture mreu ine peer vorovi koji meusobno komuniciraju direktno sa tom razlikom da postoji centralni server (discovery server). (Slika 2-12)
[19]
Slika 2-12 ema centralizovane P2P arhitekture Hibridna P2P arhitektura predstavlja varijantu centralizovane P2P arhitekture koja se koristi u sluajevima kada se mrea sastoji od velikog broja peer vorova. Kod hibridne P2P arhitekture ulogu servera preuzima vei broj Supernode vorova. Ove vorove najblii peer vorovi koriste kao servere dok adresne informacije vezane za peer vorove supernode vorovi meusobno razmenjuju. (Slika 2-13)
Slika 2-13 ema hibridne P2P arhitekture
[20]
2.5 SOA (Service Oriented Architecture) SOA (Service Oriented Architecture) je novi pristup pri projektovanju softvera i informacionih sistema od starih i ve postojeih resursa. Sam cilj SOA-e je da odvoji poslovne procese od IT-a i da IS uini fleksibilnim i dovoljnim da ispuni sve zahteve modernih tokova poslovanja. SOA nije potpuno nova ideja, ona predstavlja poetak realizacije jedne ideje koja ima za cilj da spoji ceo IT sektor u jednu celinu i potini ga interesima poslovanja. Kao relativno mlada, u praktinoj primeni, ova filozofija zahteva izvesnu edukaciju i upoznavanje sa terminologijom, tehnologijom, metodama i pristupima izrade ovakvog sistema. [7]
2.5.1 SOA istorijat
Da bi bilo ta rekli o SOA istorijatu moramo se prvo osvrnuti na XML i Web Servise. Moglo bi se rei da je SOA nastala evolutivnim procesom iz ove dve tehnologije, koje su svojom pojavom i filozofijom otvorile mnoge mogunosti. Kao i HTML (Hypertext Markup Language), XML (Extensible Markup Language) je napravljen od strane W3C organizacije i izveden je iz SGML (Standard Generalized Markup Language) jezika, koji postoji jo od sedamdesetih godina. Ovaj meta jezik je omoguio organizacijama da sirovim podacima daju smisao i razmenjuju obeleene (tagged) podatke sa drugim organizacijama. [7] XML je razvijen kao odgovor na eBiznis pokret, koji je nastao kasnih devedesetih. Korienjem XML-a omogueno je informacijama, koje se alju internet protokolima, dati smisao i kontekst. XML nije samo posluio za standardizaciju podataka ve je kao jezik iskorien za razvoj dodadnih standarda, XSD (XML Schema Definition Language) i XSLT (XSL Transformation Language). Pored XML jezika ova dva standarda su danas kljuni delovi XML tehnologije. Ova arhitektura predstavljanja podataka je bazni sloj SOA tehnologije. U okviru nje, XML odreuje format i strukturu poruke koja se kree izmeu servisa. XSD eme uvaju integritet i validnost podataka poruke i XSLT se, kroz ematsko mapiranje koristi da bi se omoguila komunikacija izmeu razliitih formata podataka. Dave Winer, Don Box, Bob Atkinson i Mohsen Al-Ghosein su uz pomo Microsoft-a 1998. godine dizajnirali SOAP (Simple Object Acces Protocol). W3C je 2000. godine usvojio SOAP standard. Prevashodno je zamiljen da ujedini RPC (Remote Procedure Call) komunikaciju. Ideja je bila da se podaci, koji razmenjuju komponente serijalizuju pomou XML-a, transportuju i onda deserijalizuju u prvobitni format. Uskoro su korporacije i prodavci softvera uvideli ogroman potencijal za unapreenje eBiznis tehnologije kreiranjem okvira za komunikaciju koji nema vlasnitvo. Ovo je dovelo do ideje da se stvori distribuirana tehnologija bazirana na internet-u, koja ne koristi samo postojee internet protokole ve prua standardizovani okvir komunikacije da bi se premostile razlike u komunikacije u okviru i meu organizacijama. Ovaj koncept je nazvan WEB Servisi. Najbitniji deo WEB Servisa je javni interfejs koji on prua, to je ono to prua servisu identitet i omoguava njegovo pozivanje. Ba zato je jedna od prvih inicijativa, za podrku tehnologije WEB Servisa, bila WSDL(Web Service Definition Language). W3C je 2001. godine primila specifikaciju za WSDL i nastavila je da razvija ovaj standard. WSDL datoteka je centralni deo informacije koja opisuje veb servis. [7] Poslednji u nizu standarda, veb servisa prve generacije, je UDDI (Universal Description Discovery and Integration) specifikacija. Razvijena je od strane UDDI.org. Ova specifikacija omoguava kreiranje standardizovanih registara za opis servisa, u okviru i van organizacije. ovo prua mogunost registracije veb servisa na centralizovanoj lokaciji gde ih mogu otkriti korisnici. Kako je interesovanje za veb servise raslo, najvee softverske kompanije su uurbano dodavale nove specifikacije. Ove je poznato kao druga generacija veb servis standarda, ove
[21]
specifikacije su se pre svega odnosile na konkretne oblasti funkcionalnosti, sa konanim ciljem dovoenja tehnologije veb servisa na preduzetniki nivo. Uskoro su organizacije poele da shvataju da veb servisi, pored prilagoavanja postojeih distribuiranih aplikacija, mogu postati osnova za potpuno novu platformu, koja bi omoguila koncept deljenja poslovanja na seriju autonomnih servisa. Tako je nastao koncept koji danas zovemo SOA.
2.5.2 Funkcionalna dekompozicija
Dijagrami toka u ovom delu treba da nam pokau tano ta na sistem kao i sami na modul treba da radi. On ne pokazuje na koji nain treba da radi naa komponenta. Ovi dijagrami su takoe od velike vanosti za kasnije izraunavanje funkcionalnih taaka i estimacije.
2.5.2.1 Dijagram prvog nivoa
Na ovom dijagramu je prikazan na kompletan sistem Optimal SQM i njegov odnos prema korisniku i komunikacija. Dakle, u osnovi naem sistemu pristupaju eksterni klijenti. Oni na naem web sajtu zahtevaju odgovarajuu uslugu. Zatim na sistem na osnovu zahteva trai potrebne informacija od njih. Na kraju pre same usluge izdaje raun za uplatu i nakon uplate omoguava uslugu. Naravno, neke usluge e biti i besplatne ili e moi neke opcije da se probaju direktno na sajtu putem showroom-a.
Slika 2-14 Dijagram prvog nivoa
[22]

2.5.2.2 Dijagram drugog nivoa
Na ovom dijagramu sputamo se samo na nau komponentu i dajemo opti prikaz kretanja podataka unutar nje. Dakle na ulazu imamo dva interfejsa (MNGR modul i klijenta). Naa zamisao je da e svi ostali moduli unutar Optimal SQM-a komunicirati putem modula MNGR. Klijenti e na neki nain moi da pristupe naem modulu ali takoe i za te korisnike emo dobijati dodatne informacije iz MNGR-a koji u sebi sadri CRM komponentu. Nakon to dobije na modul za komunikaciju sa ovim interfejsima odreen zahtev on ga analizira i pakuje u formatiran zahtev koji se dalje alje ka ostalim komponentama BOX-a. Dakle na osnovu ovog zahteva pokreu se odreene tehnike testiranja i moduli koji su za to zadueni i vri se testiranje i zatim se alju korisniku koji ih je traio.
Slika 2-15 Dijagram drugog nivoa
[23]

2.5.2.3 Dijagram treeg nivoa
Na ovom dijagramu prikazujemo i samu komunikaciju i tok informacija izmeu samih komponenti unutar OQT BOX-a. Dakle imamo kao i u proloj dekompoziciji na poetku slanje zahteva ili direktno od korisnika ili od MNGR-a ili od nekog drugog modula, ali putem MNGRa. Na CRM modul analizira zahtev. Formira na osnovu njega odgovarauje formatirane zahteve i pokree odreene tehnike unutar testnih modula. U sluaju da su potrebni dodatni fajlovi od nekih drugih komponenti Bug manager ih zahteva i dobija, i prosleuje ih natrag testnim modulima kako bi izvrili testiranje. Nakon uspenog testiranja Bug manager analizira rezultate i generie odgovarajui izvetaj na izlazu prema MNGR-u ili klijentu.
Slika 2-16 Dijagram treeg nivoa
[24]
2.6 J2EE Arhitektura J2EE predstavlja specifikaciju, odnosno upustvo za razvijanje Enterprise aplikacionih servera. Osnovu J2EE arhitekture ine: a) Servleti (servlets) b) JSP strane (Java Server Pages) i c) EJB-ovi (Enterprise Java Beans) Uzimajui u obzir tronivojski uzor, JSP, servleti i apleti su zadueni za komunikaciju sa klijentom (prezentacioni nivo), dok su EJB-ovi zadueni za onaj deo poslovne logike aplikacije, koja nije ugraena u aplikacioni server, kao i za komunikaciju sa bazom (logiku pristupa podacima).
Slika 2-17 J2EE aplikacioni server - raspodela odgovornosti elemenata J2EE arhitekture [9] Aplikacioni server sastoji se iz sledeih elemenata: a) Home i Remote interface-a, b) Context-a, c) EJB-ova i d) Container-a, koji agregira navedene elemente (EJB Home i Remote interface, Context i EJB elemente). Scenario komunikacije izmeu klijenta i aplikacionog servera je sledei: Klijent poziva metodu Remote ili Home interface-a EJB-a. Container element presree poziv klijenta i proverava da li je poziv validan (da li je u skladu sa semantikom koju je definisao deployment descriptor). Ukoliko je poziv validan on ga dalje usmerava ka odgovarajuem EJB-u, koji kasnije komunicira sabazom podataka. Komunikacija sa bazom moe biti izvrena i preko container elementa. [8]
[25]
Container element obezbeuje okruenje na kome se izvravaju EJB-ovi. On kontrolie sve aspekte izvrenja jednog EJB-a. U tom smislu on obezbeuje sledee servise [8]: a) Registrovanje EJB-ova prilikom njihovog kreiranja i punjenja. b) Upravljanje ivotnim ciklusom EJB-a. c) Provera zatite i kontrola pristupa EJB-ovima. d) Serijalizacija poziva metoda EJB-ova. e) Koordinacija transakcija EJB-ova. f) Upravljanje perzistentnou EJB-ova. g) Praenje kontekstnih informacija svakog EJB-a u vreme izvrenja programa. Context element se pravi za svaki EJB. On u sebi uva informacije o klijentu, kontejneru i o samom EJB-u. EJB-ovi koriste ove informacije u obradi zahteva klijenta. EJB (Enterprise Java Bean) je u irem smislu arhitektura za razvoj sloenih (Enterprise) distribuiranih aplikacija koje su zasnovane na softverskim komponentama (Java Bean-sima). Shodnotome EJB u uem smislu predstavlja softversku komponentu [8]: koja se sastoji iz tri dela: 1. EJBHome interfejsa koji je odgovoran da specificira operacije: create(), find() i remove(), 2. EJBObject interfejsa koji je odgovoran da specificira ostale operacije koje zahteva klijent, 3. Klase (bean-a) koja implementira EJB interfejse. i koja je odgovorna da obezbedi transakcione i perzistentne servise. Postoje dve vrste EJB-ova: 1) Session bean i 2) Entity bean Session bean je odgovoran: a) za komunikaciju izmenu klijenta i servera i za b) poslovna pravila (ponaanje) aplikacije Entity bean je odgovoran: a) da predstavi poslovne podatke (strukturu) aplikacije b) i da komunicira sa bazom podataka. Postoji sledee poreenje izmenu session i entity bean-a: Session bean Izvrava zadatak ili proces za klijenta Jedna instanca po klijentu Entity bean Predstavlja poslovne objekte Deljena instanca za vie klijenata Nije perzistentan - kada klijent zavri rad sa Perzistentan je po zavretku binom isti nije vie na raspolaganju rada EJB stanje objekta je sauvano u bazi.
Odgovornost Deljeni pristup Perzistentnost
Iz navedenog izlaganja moemo da primetimo da su za transakcione i perzistentne servise zadueni i Container i Entity bean. U tom smislu postoji dva pristupa vezanih za perzistentnost Entity bean-a:
[26]
1. BMP ( Bean Managed Persistent) Entity Bean perzistentnost Entity bean-a se implementiraunutar Entity Bean klasa. 2. CMP (Container managed Persistent) Entity Bean perzistentnost Entity bean-a se implementira unutar Container elemenata. J2EE aplikacije su sastavljene od J2EE komponenti. J2EE komponente su samostalne funkcionalne softverske jedinice J2EE aplikacije u kojima su grupisane klase i fajlovi, a koje moe komunicirati sa drugim komponentama. J2EE specifikacija definie sledee komponente: Komponente koje se izvravaju na klijentu Web klijenti, aplikacioni klijenti i apleti, Web komponente koje se izvravaju na serveru - Java Servleti i JSP, Komponente poslovne logike koje se izvravaju na serveru - EJB (Enterprise Java Bean) komponente. J2EE komponente su napisane i kompajlirane u Java programskom jeziku. J2EE klijentske komponente - komponente koje se izvravaju na klijentu [8] Web klijenti - Web klijenti se sastoje iz dva dela: dinamikih Web strana razliitih tipova jezika za oznaavanje (HTML, XML, itd.) koje generiu Web komponente izvravajui se na Web sloju i Web browser-a koji prikazuje stranice primljene od servera. Web klijenti se esto nazivaju tankim klijentima (thin clients). Tanki klijenti obino ne rade stvari kao to su upiti u baze, izvravanje poslovne logike itd. ve to preputaju EJB komponentama koje se izvravaju na J2EE serveru. Apleti - Web stranica primljena od Web sloja moe sadrati i aplet. Aplet je mala klijentska aplikacija napisana u programskom jeziku Java koja se izvrava na Java virtualnoj maini (JVM) instaliranoj u Web browser-u (Klijent mora imati odgovarajui Java plug-in i security police datoteku). Iz tog razloga Web komponetne preferiraju API za kreiranje klijentskog programa. Takoe Web komponente omoguavaju istiji i modularniji dizajn aplikacije jer obezbeuju odvajanje programiranja aplikacije od dizajna Web strana. Personal koji uestvuje u dizajnu Web strana ne mora poznavati Java programski jezik. Aplikacioni klijenti - J2EE aplikacioni (debeli) klijenti izvravaju se na klijentskoj maini i imaju bogatiji grafiki korisniki interfejs (Graphical user interface - GUI), koji sadri Swing i AWT komponente mada je mogu i komandni interfejs. Aplikacioni klijenti direktno pristupaju Enterprice Java Bean ovima na poslovnom nivou. Takoe aplikacioni klijent moe otvoriti HTTP konekciju da uspostavi komunikaciju sa servletom koji se izvrava na Web serveru.
[27]
Slika 2-18 J2EE klijent, server i biznis prezentacija [9] Enterprise Java Beans (EJB) su J2EE komponete koji implementiraju EJB tehnologiju. EJB se izvravaju u EJB kontejneru, izvrnom okruenju unutar Sun Java System AS platforme. Mada transparentan aplikacionom developeru, EJB kontejner obezbeuje sistemske servise kao to su transakcije i sigurnost za svoje enerprajz binove. Ovi servisi omoguavaju brz razvoj i razmetaj enterprajz binova koji ine sr transakcionih J2EE aplikacija.
[28]
3 Modeli ivotnog ciklusa softvera

Svaki proces moe da se opie na razliite naine, pomou teksta, slika ili njihovom kombinacijom.
Slika 3-1 Model razvoja procesa Na slici 3-1 prikazan je model razvoja procesa. Kao to se vidi sa slike na ulazu je specifikacija zahteva, u modelu razvoja procesa vri se projektovanje i testiranje aplikacije isporuuje gotov proizvod. Modeli procesa razvoja, odnosno ivotnog ciklusa softvera su: Kaskadni model (model vodopada) V model Fazni razvoj (inkrementalni i iterativni) Prototipski model Model specifikacije rada Transformacioni model Spiralni model Agilne metode (ekstremno programiranje) 3.1 Kaskadni model (model vodopada) Model vodopada ili kaskadni model (Royce, 1970.) predstavlja veoma visok nivo apstrakcijerazvojnog procesa ije su faze kaskadno prikazane.Iako ima puno nedostataka, on slui kao osnova za druge, efikasnije modele ivotnog ciklusa. Umodelu vodopada, projekat napreduje kroz ureenu seriju koraka od inicijalnog koncepta softverado testiranja sistema. Projekat se preispituje na kraju svake faze, da bi se odredilo da li je spremanza prelazak u sledeu fazu. Za svaku aktivnost procesa definiu se kritine take i meuproizvodi,to olakava praenje stepena gotovosti projekta.Ukoliko projekat nije spreman za prelazak u sledeu fazu, ostaje u trenutnoj fazi dok ne bude spreman.Model vodopada je baziran na dokumentima (document driven), to znai da su dokumentiglavni radni proizvodi koji se prenose iz faze u fazu. [10]
[29]
Slika 3-2Kaskadni model razvojnog procesa softvera Prednosti: Jednostavnost koja olaka svih faza projektovanja. Dobijanje pune funkcionalnosti sistema. Eksplicitno ukazivanje na meuproizvode koji su faze. Pogodan za sluaj kada je neophodno odjednom zameniti stari sistem. Nedostaci: Ne podrava povratne sprege, koje zbog greaka i nepreciznosti postoje u stvarnosti. Sistem je obino preveliki da se uradi u jednoj iteraciji. Nije pogodan kod znatnih izmena zahteva. 3.2 V model V model (nemako Ministarstvo odbrane) je modifikovani kaskadni model koji pokazuje odnos testiranja i faza analize i projektovanja, inei eksplicitnim neke povratne sprege koje su skrivene u kaskadnom modelu. V model sugerie da testiranje delova i testiranje pri integraciji mogu da se koriste za verifikovanje projektovanog programa. Tokom testiranja delova i testiranja pri integrisanju programeri i lanovi tima za testiranje treba da se osiguraju da su svi aspekti ispravno implementirani u kodu. Slino tome, testiranje sistema treba da verifikuje projektovani sistem, uz potvrdu da su svi aspekti ispravno implementirani. [10]
[30]
Slika 3-3 V model razvojnog procesa softvera Validacija: proces evaluacije sistema ili komponente za vreme ili nakraju procesa razvoja da bi se utvrdilo da li zadovoljava zahteve definisane od strane korisnika. Kljuno pitanje vezano za validaciju bi bilo Da li kreiramo pravi proizvod?. Verifikacija: proces evaluacije sistema ili komponente kako bi se utvrdilo da li proizvod korektno implementira odreenu funkciju. Kljuno pitanje vezano za validaciju bi bilo Da li kreiramo proizvod na pravi n n?. Verifikacijom se utvruje da li proizvod zadovoljava zahteve definisane tokom prethodnih aktivnosti tokom ivotnog ciklusa, dok validacija proverava da li sistem zadovoljava korisnike zahteve na kraju ivotnog ciklusa. Testiranje delova, testiranje sistema pri integraciji i testiranje sistema utvruju ispravnost programa i mogu se koristiti za verifikovanje projekta programa.Zavrni test slui za validaciju zahteva, tj. proveru da li su svi zahtevi potpunoimplementirani.Ako se pronau problemi tokom verifikacije ili validacije, aktivnosti sa leve strane Vmodela mogu se ponoviti radi popravke i poboljanja zahteva, izgleda ili koda, prenego to se ponove testiranja na desnoj strani modela. Prednosti: Naredna faza poinje tek kada se predhodna faza zavri, Aktivnosti planiranja testiranja i kreiranje testova se izvrava pre kodiranja, Greke koje su nastale u predhodnim fazama bie otklonjene u tekuoj fazi. Nedostaci: Model je vrlo krut u pogledu izmena. Svaka promena u projektovanju povlaipromene u dokumentaciji i test dokumentaciji (odnosno promene samog testa). Moe se implementirati samo u velikim preduzeima. Potrebno je mnogo sredstava za primenu i odravanje ovog modela.
[31]
3.3 Iterativno-inkrementalni model (fazni razvoj) Koncept razvoja sistema pomou iteracija je poznat kao iterativno ikrementalni razvoj, iako se esto koristi termin iterativni razvoj. Fazni razvoj je nain projektovanja softvera koji omoguava isporuivanje sistema u delovima, tako da je korisnicima na raspolaganju jedan deo funkcija, dok je ostatak funkcija jo u razvoju.
Slika 3-4 Fazni razvoj procesa softvera Na slici vidimo da postoje dva sistema koji uporedo funkcioniu: produkcioni i razvojni sistem. Produkcioni sistem je onaj koji trenutno koriste naruilac i korisnik. Razvojni sistem predstavlja sledeu verziju koja se priprema da zameni postojei produkcionisistem. Sistemi se obino nazivaju prema rednom broju njihove verzije. Tako, projektni tim uvekradi na verziji n+1, dok je verzija n u fazi operativnog korienja. [10] Inkrementalni razvoj Inkrementalni razvoj podrazumeva da se sistem u skladu sa specifikacijom zahteva deli na podsisteme prema funkcijama. Verzije se definiu kao funkcionalni podsistemi, tako da se svakoj novoj verziji prikljuuju nove funkcije. Sistem se nadograuje do potpune funkcionalnosti. Na slici 3-5 je dat ilustrativan primer inkrementalnog razvoja. Svako blok koji je dodat predstavlja jedan podsistem koji je zavren.
Slika 3-5 Inkrementalni razvoj Iterativni razvoj Iterativni razvoj takoe podrazumeva podelu sistema na podsisteme prema funkcijama, ali se potpun sistem isporuuje u svim verzijama, s tim to se u svakoj novoj verziji menjaju funkcije svakog podsistema. Svaka sledea verzija unapreuje prethodnu. Na slici 3-6 je dat je prikaz iterativnog razvoja. Svakoi blok koji osenen ilustrativno prikazuje promenu funkcija tog podsistema.
[32]
Slika 3-6 Iterativni razvoj [10] 3.4 Prototipski model Prototipski model se zasniva na izradi prototipova. Ovaj model omoguava da se kompletan sistem ili delovi sistema brzo konstruiu radi razjanjenja ili boljeg razumevanja otvorenih pitanja, sve sa ciljem smanjenja rizika i neodreenosti prilikom projektovanja sistema. Komponente razvijenog softvera esto predstavljaju samo korisniki interfejs. Implementacija interfejsa u okviru prototipskog modela prua nam mogunost da dobijemo povratnu informaciju od korisnika pre specifikacije i projektovanja konanog reenja. Mada je razjanjenje korisnikog interfejsa jedan od ciljeva, prototip moe biti takoe iskorien kao koncept unutar konteksta drugog modela. U tom sluaju, drugi model moe posmatrati prototip kao jedan elemenat procesa,koji se koristi u razjanjenju ponaanja sistema u razliitim takama razvoja softvera. [10] Model obino prihvata neku vrstu funkcionalne specifikacije softvera kao ulaz, koji analizira i izvrava. Ovaj model omoguuje da aktivnosti preskoene ili premotene. Takoe, kasnije korisnik moe i sam razvijati. Korisniki razvoj je ukljuen u povratnu spregu za redefinisanje sistemskih specifikacija i Model prototipskog razvoja se najee upotrebljava i daje solidne rezultate u situacijama: o kada su od strane korisnika samo uopteno definisani ciljevi razvoja proizvoda, ali ne i detalji u pogledu ulaza, procedura i izlaza o kada je mogue simulirati rad softvera da bi korisnik mogao videti kako e budui softverski proizvod funkcionisati o kada same razvojne organizacije ele proveriti efikasnost algoritama ili sistema.
Slika 3-7Prototipski model razvojnog procesa softvera
[33]
3.5 Model specifikacije rada Model specifikacije rada (Zave, 1984.) omoguava projektnom timu i naruiocu da u ranim fazama projektovanja ispitaju zahteve sistema i njihove implikacije, i po potrebi ih koriguju. Zahtevi se pre poetka projektovanja ocenjuju ili izvravaju na nain koji pokazuje prirodu sistema, koristei programske pakete. Tako se izbegavaju problemi u kasnijim fazama koji mogu da nastanu usled neodreenosti vezane za zahteve sistema. Ovaj model, za razliku od tradicionalnih modela, objedinjuje funkcionalnost i projektovanje, time spaja potrebe naruioca sa implementacijom.
Slika 3-8 Model specifikacije rada [10] 3.6 Transformacioni model Transformacioni model (Balzer, 1981.) pokuava da redukuje mogunost greke primenom niza transformacija kojima se specifikacija zahteva pretvara u sistem koji moe da se isporui. Sekvence transformacija i odluka se uvaju kao formalni zapis u okviru projekta.
Slika 3-9 Transformacioni model procesa Na slici 3-9 je prikazan transformacion model. Na ulazu su zahtevi koje sistem mora da ispuni. Nakon toga se formira formalna specifikacija, porede se zahtevi i auriraju po potrebi. Nizom transformacija se pokuavaju redukovati greke, i specifikacija zahteva se pretvara u sistem koji dalje ide u fazu testiranja. Nakon testiranja imamo gotov softverski proizvod.
[34]
3.7 Spiralni model Spiralni model je definisao Barry Boehm A Spiral Model of Software Development andEnhancement 1986. godine. Spiralni model posmatra razvoj softvera u svetlu prisutnih rizika tako to kombinuje aktivnosti razvoja sa upravljanjem rizicima.Spiralni model je model ivotnog ciklusa softvera koji jesoftverski projekat u mini projekte. Svaki mini projekat obrauje jedan ili vie glavnih rizika doksvi rizici nisu obraeni. Koncept rizika je iroko definisan u ovom kontekstu, i moe da sena loe protumaene korisnike zahteve, lou arhitekturu, potencijalne probleme saperformansama, probleme u osnovnoj tehnologiji, itd. Osnovna ideja iza dijagrama spiralnog modela je da serizici pone malim koracima u sredini, ispitaju se rizici, napravi se plan za obradu rizika, i potom se posveti pristupu za sledeu iteraciju. Po spiralnom modelu, proces razvoja softvera se odvija u 4 iteracije (slika 3-10):
Slika 3-10 Faze razvoja softvera u spiralnom modelu U svakoj iteraciji, radi se analiza rizika koja identifikuje rizike i odreuje razliite varijante sa aspekta zahteva i ogranienja za njihovo minimiziranje. Zatim se izradom prototipova verifikuju izvodljivost i pogodnost varijanti pre nego to se odabere odgovarajua.
[35]
Slika 3-11 Ciklus razvoja softvera u spiralnom modelu [10] Tipina raspodela vremena, za koja ipak treba rei da variraju od ciklusa do ciklusa, je: o planiranje i projektovanje 20%, o procena rizika 5%, o realizacija (sa testiranjem) 40%, o revizija 15% i o ocenjivanje 20%.
[36]
4 Poslovni inteligenta simulaciona arhitektura (PISA) sa aspekta 4+1 pogleda
4+1 je pogled, dizajniran od strane Filipa Kruchten koji "opisuje arhitekturu softvera intenzivnih sistema, zasnovan na upotrebi viestrukih, zajednika vienja" stavove koriste za opisivanje sistema sa stanovita razliitih zainteresovanih strana, kao to su krajnji korisnici, programeri i rukovodioci projekata. etiri prikaza modela su logina, razvoj, proces i fiziki pregled. Pored toga izabrani sluajeve upotrebe ili scenarija se koriste da ilustruju arhitekturu slue kao pogled "plus jedan". Otuda model sadri 4 +1 pogled.
Slika 4-1 4+1 pogled Logiki pogled (Logical view): logiki pogled se bavi funkcionalnou da sistem prui krajnjim korisnicima. UML dijagrami se koristi za predstavljanje loginog pogleda ukljuujui dijagram klasa, dijagram komunikacije, dijagram sekvence. Razvoj pregleda (Development view): Razvoj pogleda ilustruje sistem iz perspektive programera i bavi se softverom za upravljanje. Ovaj stav je takoe poznat kao implementacija pogleda. Koristi UML dijagram komponenti da opie komponente sistema. UML dijagrami se koristi za predstavljanje pregled razvoja ukljuuju Paket dijagram. Proces pregleda (Process view): Proces pogleda bavi se dinaminim aspektima sistema, objanjava sistem procesa i kako oni komuniciraju, i fokusira se na runtime ponaanje sistema. Proces pogled adrese konkurentnosti, distribuciju, integratorima, performanse i skalabilnost. UML dijagrami predstavljaju pregled procesa ukljuuju dijagram aktivnosti.
[37]
Fiziki pregled (Physical view): fiziki pregled opisuje sistem iz sistema inenjera point of view. On je zabrinut sa topologije softverskih komponenti na fiziki sloj, kao i fizike veze izmeu ovih komponenti. Ovaj stav je takoe poznat kao rasporeivanja pogled. UML dijagrami se koristi za predstavljanje fizikih pregled ukljuuje razmetanje dijagram. Scenariji (Scenarios): opis arhitekture je ilustrovana korienjem mali skup sluajeva upotrebe ili scenarija koji postaju peti pogled. Scenarija opisuju sekvence interakcija izmeu objekata, kao i izmeu procesa. Oni se koriste da identifikuju arhitektonskih elemenata i da ilustruje i proveru dizajna arhitekture. Oni takoe slue kao polazna taka za testiranje arhitekture prototipa.
Slika 4-2 Forma za logovanje korisnika na sajtu Optimal SQM Slika 4-2 predstavlja obrazac, odnosno gormu za logovanje korisnika na sajtu PISA (OptimalSQM). Korisnik e imati trial, limitiran pristup OptimalSQM softveru, kako bi isprobao osnovne funkcije pre kupovine. Moemo na osnovu sluaja upotrebe prezentovati dijagram klasa, sekvencijalni dijagram, use case dijagram.
[38]
Slika 4-3 Logiki tok procesa
[39]
Slika 4-4 Dijagram klasa za sluaj logovanja korisnika
Slika 4-5 Procesni dijagram za sluaj logovanja korisnika
[40]
5 Opis projekta PISA

5.1 Biznis ideja Testiranje softvera (TS) je bitan preduslov za uspean razvoj i implementaciju Informacionog Sistema (IS). Ali, esto se testiranje softvera smatra avolskim poslom: zato to je komplikovan i nekontrolisan proces koji traje predugo, preskup je, a na kraju, najee ne dovodi do IS bez greaka tj. ozbiljnih problema. Naalost, u najveem broju sluajeva ova tvrdnja je potvrena.Softverski projekti su veoma rizini po pitanju uspeha. 5.2 Ciljevi projekta Osnovni koncept reenja PISA karakterie agilnost tj.aktivni pristup koji integrie tehnike analize uzroka nastajanja greaka u PRS i tehnike spreavanja tj. prevencije generisanja greaka, kontinualnog praenja i ocenjivanja kvaliteta Procesa Testiranja Softvera i Procesa Odravanja Softvera (PTS-POS) kroz: Integraciju aktivnosti TS kroz ceo PRS kao nezavisan i komplementaran proces Implementaciju aktivnosti planiranja, na samom poetku PRS, potrebnih resursa za pronalaenje optimalnog PTS-POS na osnovu simulacija moguih scenarija testiranja Softvera IS na svim nivoima apstrakcije Automatizaciju PTS-POS gde je to praktino izvodljivo radi poveanja efikasnosti PTS-POS Merenje i upravljanje PTS-POS kojim se minimizira rizik koji dovodi do uspeha projekta Primenu tehnika planiranog eksperimenta (EVOP, optimalni planovi, ortogonalni vektori i dr.) Primenu modelovanja i simulacija kombinovanih sa demonstracijom Softvera IS na maketama i prototipovima Kontinualno unapreenje PTS-POS primenom aktivnih tehnika analize korena nastanka greaka, prevencije njihovog generisanja (engl. root-cause and failure mode analysis) po modelu est sigma (6 ) engl. Six Sigma DMAIC/DFSS model Kontinualno praenje trokova (ekonomskih parametara) i rizika tj. optimalnosti PTS-POS.
Pomou razvijenih specifinih softverskih alata, obezbedie se svakoj, a posebno IK (ICT) kompaniji efikasan i lak pristup poslovnim podacima, analizu i meusobno deljenje informacija u cilju donoenja kvalitetnih, brzih i relevantnih odluka u poboljanju sveukupne poslovne efektivnosti (ROI ak 100:1) kroz adaptivno modelovanje i pronalaenje optimalnog reenja na bazi simulacije scenarija realizaije softverskog projekta. 5.3 Koncept projekta Industrija razvoja softvera troi vie od polovine svog budeta na aktivnosti povezane sa odravanjem. Testiranje softvera je nain da se obezbedi manji broj greaka, manji troak odravanja i sveukupne cene softvera. Ova inovativna ideja se usredsreuje na proces testiranja i
[41]
merenja softvera koja omoguavaju kvantitativnu procenu ovog kritinog dela procesa razvoja softvera. Testiranje softvera ukljuuje proces otkrivanja neusaglaenosti softvera kako bi one bile ispravljene pre nego budu instalirane u ivo okruenje koje je podrka za svakodnevni rad poslovnih jedinica kompanije. U poetku istorije razvoja softvera, testiranje je bilo svedeno na proveru zavrenog koda, mada je testiranje softvera vie od mehanizma kontrole kvaliteta. Brojne metodologije, alati i tehnike za testiranje i razvoj softvera su se pojavile tokom prethodnih nekoliko decenija obeavajui poboljanje kvaliteta softvera. Iako moemo da raspravljamo da li su i koliko postignuta odreena poboljanja, oigledno je da postoje mnoge specijalizovane tehnike i alati, koje su razvijene izolovano i za pojedine faze u ivotnom ciklusu ili funkcionalnoj oblasti. Ova inovativna ideja predstavlja skup najboljih modela i tehnika iz prakse, integrisanih u optimizovan i kvantitativno rukovoen proces testiranja i odravanja softvera , koji proiruju funkciju testiranja na itav SDLC (ivotni ciklus razvoja softvera). Ovo ukljuuje najbolje primere iz prakse iz oblasti eksperimentalnog dizajna, modelovanja i simulacije, integrisanog praktinog merenja softvera, est sigma strategije, upravljanje ekonomskom (ostvarenom) vrednou, metodologije upravljanja rizikom, kroz scenarije testiranja softvera zasnovane na simulaciji kroz razliite nivoe apstrakcije softvera koji testiramo, a u cilju postizanja stabilnog (predvidljivog i kontrolabilnog) procesa testiranja softvera sa najniim rizikom, po prihvatljivoj ceni i u prihvatljivom vremenu. PISA integralno softversko okruenje se sastoji u: kolekciji najboljih znanja reenja, metoda, ablona smetenih u bazi znanja, automatizovan proces adaptivnog modelovanja na bazi scenarija optimizacije procesa, angaovanja resursa u realnom vremenu konkretne kompanije, pogodno okruenje za komjutersko eksperimentisanje po principima planiranog eksperimenta (Design of Experiments) sa realnim sistemima preko arobnjaka tzv. wizards, grafiki korisniki interfejs za konkurentan rad veeg broja lanova tima, zasnovan na internet tehnologijama (web-based GUI) radi izvoenja velikog broja simulacija i deljenja rezultata obavljenih simulacija i da omogui razmeni podataka i dokumenata sa standardnim radnim okruenjem lanova tima jedne kompanije u obavljanju poslova planiranja, rasporeda poslova, estimacije trokova, resursa i td. kao to su: MS Office, MS Project, Excel, Risk+ i dr.). Ima puno kompanija u svetu koje imaju sline proizvode iz oblasti obezbeenja i kontrole kvaliteta softvera (SQA), meu koje spadaju:HP,IBM, MICROSOFT, COMPUWARE, AUTOMATEDQA i druge.Nedostatak njihovih reenja je taj da su ili preskupa ili nisu u dovoljnoj meri integrisali sve tehnike i znanja koje mi nudimo kroz OptimalSQM inovativnu ideju. Naa OptimalSQM inovativna ideja je skalabilna i zbog toga po ceni konkurentna, to znai da se moe skrojiti kako za potrebe malih, tako i za potrebe srednjih i velikih preduzea koje razvijaju ili adaptiraju i unapreuju tua softverska reenja. 5.4 Opis funkcija sistema OptimalSQM ta je OptimalSQM? OptimalSQM je razvojni projekat, iji je krajnji cilj PISA. Kroz realizaciju inovativne ideje OptimalSQM, kompanijama u oblasti IC tehnologija (u bankarskom, telekomunikacionom, obrazovnom sektoru), a i ire bi bio ponuen kao softverski proizvod Softversko okruenje Poslovne Inteligentne Simulacione Arhitekture (PISA) sa integrisanim
[42]
procesima, tehnikama, softverskim aplikacijama (EVOP Estimator Engine, IOP Test Engine i IOP Maintenance Engine i dr.), bazom znanja i podataka u oblasti testiranja i odravanja softvera i za neprekidnu/kontinualnu eksperimentalnu optimizaciju industrijskih procesa koji su intezivno softverski podrani. OptimalSQM sadri (OQT MNGR, OQT BOX, OQT MAINT, OQT OPST, OQT SIM) i dostupan je kao sveobuhvatni paket reenja za upravljanje testiranjem i simulacijom moguih scenarija procesa testiranja konkretne kompanije i konkretnog projekta. MNGR je u srcu sistema, prua integrisano i koherentno upravljanje multidisciplinarnim aspektima ispitivanja softvera i omoguava testiranje pravila u upravljanju procesom testiranja odreenog tipa softvera na optimalan nain, konkretne kompanije i konkretnog projekta putm simlacije moguih scenarija realizacije procesa testiranja u okviru planiranog budeta, trajanja i atribta kvaliteta softvera koji se razvija.
Slika 5-1 Statika arhitektura OptimalSQM reenja OQT-MNGR je komponenta koja se nalazi u srcu PISA-e, obezbeuje integrisano i koherentno upravljanje multidisciplinarnim aspektima operacija testiranja, omoguavajui naprednu generaciju pravila testiranja. MNGR sadri SaaS-ove (Softwere as a Service) paradigme pravila - koja e biti prvi industriski jezik scenarija za testiranje softvera sa lako prilagodljivim unapred definisanim predlocima pravila - za reavanje kritinih vektorskih (preko 100 promenljivih) u procesu upravljanja testiranjem. Takoe, vana funkcija MNGR komponente je da prui sve upitnike na projektu: aktivnosti razvoja procesa i bitne stavke produktivnosti procesa radi izraunavanja ogranienja procene rizika i radi postizanja odrive procene odreenih preduzea i projekata. OQT-SIM je komponenta koja simulira procese (scenarije) testiranje na osnovu uspostavljenih pravila i algoritama koji su bazirani na empirijskim rezultatima testiranja, kvalifikacijom potencijalne koristi ovih pravila pre primene. Zahvaljujui nadgledanjem planiranja, OQT-SIM takoe proverava poboljanje kvaliteta i efikasnosti postojeih pravila postavljenih tokom vremena, to omoguava poreenje stvarne koristi baziranih na akumulaciji informacija u realnom svetu procesa testiranja za razne vrste softverskih proizvoda, nivoa CMM i TMM zrelosti konkretne kompanije kojoj pruamo servis. OQT-SIM nudi tano razumevanje stvarne koristi i ROI postavljenih pravila, prua dokaz koncepta za vie scenarija stvarnih performansi konkretne kompanije i konkretnog projekta te kompanije (iz sopstvene metrike ili usrednjene baze merenih karakteristika tipa softverskog proizvoda koji se razvija, performansi razvojnog tima, procesa testiranja u datoj kompaniji i sl.), procenu optimalnog scenarija za dati projekat na bazi rezultata simulacije moguih scenarija testiranja spremljenog pre primene u
[43]
realizaciji datog konkretnog softverskog projekta.SIM nudi simulaciju ablona koji sadre algoritme iz razliitih porodica softverskih proizvoda, nivoa zrelosti softverskih kompanija, kao to su smanjenje vremena testiranja, napredna statistika kontrola procesa, kvalitet i pouzdanost, smanjenje naknadne dorade usled napravljenih greaka u svim fazama razvoja softvera. Svaka familija stimulacije je bogata sa pravilima koji su posebna meta poslovnih potreba. Potpuno integrisan sa svim drugim OQT-MNGR modelima, OQT-SIM omoguava simulaciju pravila i postavljena pravila definisana u OQT-pravilima, koji onda mogu biti objavljeni putem OQTMNGR u realnom vremenu ili kasnijem radnom okruenju. Simulacijoni tok je intuitivan, jednostavan za korienje i podran je jakom metodologijom. OQT-MAINT je komponenta koja razmilja o svim rezultatima testiranja radi poboljanja kontrole kvaliteta i upravljanja svim aspektima operacija testiranja u korektivnom, adaptivnom i perfektivnom odravanju softvera kako u toku razvoja tako i nakon isporuke softverskog proizvoda na upotrebu. MAINT komponenta vri unakrsne procene kvaliteta svih flota testiranja, za sve procene efikasnosti testiranja u otkrivanju i otklanjanju defekata (poveenje prinosa otkrivenih greaka), nudei ekstremni integritet podataka. Osim toga, MAINT komponenta poboljava pouzdanost softvera kroz SRE (Software Reliability Engineering) metodologiju metrike pouzdanosti softverskog proizvoda u predvianju i proceni kritinih faktora kao to su: stopa greaka po fazama razvoja softvera, konana stopa greaka nakon 6 meseci upotrebe softvera, gustine greaka na KSLOC ili FP metrici veliine softvera, profil greka itd. Na osnovu ovih podataka MAINT komponenta obezbeuje kompletnu tehniku podrku nakon putanja softverskih proizvoda u promet, odnosno program za aktivnosti odravanje tj.za korektivno, adaptivno, perfektivno i preventivno odravanje na optimizovan nain. OQT-OPST je komponenta (OPeratinonal Software Testing) koja treba timu za planiranje i sprovoenje testiranja konkretnog razvijanog softvera, konkretne kompanije (Project Specific Software Testing) omogui da na osnovu stvarnih performansi konkretne kompanije i konkretnog projekta te kompanije i pronaenog optimalnog scenarija za dati projekat na bazi REZULTATA izvrenih simulacija (OQT SIM komponente) moguih scenarija testiranja pre primene u realizaciji datog konkretnog softverskog projekta odredi karakteristike integralnog i optimalnog PTS (IOPTS). Dakle, na osnovu sopstvene metrike ili usrednjene baze merenih karakteristika tipa softverskog proizvoda koji se razvija, performansi razvojnog tima, zrelosti (TMM nivoa) procesa testiranja u datoj kompaniji i sl., odredi aktivnosti i objekte testiranja u takama provere artifakata datog PTS (SDLC), odredi adekvatne tehnike detekcije greaka koje obezbeuju zahtevani kvalitet tokom razvoja softverskog proizvoda u okvirima projektnih ogranienja tj. sve parametre IOPTS. 5.5 Definicija zahtevi i okviri projekta Na osnovu opisa naih komponenti i informacija prikupljenih o njima i konkurentskih reenja sada smo u situaciji da navedemo odreene zahteve i okvire naeg modula u okviru Optimal SQM-a. Dobro definisanje zahteva je krucijalno za realizaciju samog projekta. Na alost zahtevi se esto ne razumeju i to je ak prema nekim istraivanjima oko 60% greaka potie iz faze prikupljanja zahteva. Tako da zaposleni u razvoju softvera imaju mogunost da eliminiu veliku koliinu greaka ako detaljno izvre prikupljanje zahteva, a ne da brzo preu u narednu fazu razvoja. Kao rezultat, mnogo puta se desilo da je cena softvera bila mnogo vea, to je bilo posledica loeg prikupljanja i analize zahteva na poetku razvoja softvera. Samim tim je i kvalitet loiji. Da bi se pronali i kompletirali zahtevi neophodena je neka vrsta sistematskog procesa. Ovde se koristi opis toka podataka na odreeni nain. Kada se posmatra ovaj dijagram, treba imati u vidu da se proces ponavlja i razvija. Svaka aktivnost je predstavljena u pravougaoniku i njegova isporuka (predstavljena dokumentom ili strelicom) je prikazana na slici 5-2.
[44]
Slika 5-2 Prikaz aktivnosti definisanja zahteva
[45]

5.5.1 Nefunkcionalni zahtevi
Zahtevi predstavljaju svojstva i uslove koje sistem ili ire gledajui projekat mora da zadovolji [Larman]. U ovom delu emo navesti opte nefunkcionalne zahteve koji bi sistem trebao da zadovolji a samim tim i naa komponenta OQT-BOX. Postoje razliiti tipovi zahteva koje sistem mora da zadovolji i oni su kategorizovani prema FURPS+ (Functional Funkcionalnost, Usability - Upotrebljivost, Reliability - Pouzdanost, Performance Performanse, Supportability - Po vo t) modelu: Funkcionalnost predstavlja sposobnost (capabilities) sistema da obezbedi zahtevane funkcije (ponaanje sistema). Zatita (security) sistema predstavlja jednu od osnovnih funkcija koju sistem treba da obezbedi. Upotrebljivost predstavlja sposobnost sistema da se moe jednostavno koristiti. To se postie pomou raznih uputstava i dokumentcije koji opisuju nain njegovog korienja. Pouzdanost predstavlja sposobnost sistema da moe uspeno obraditi problem (failure) koji se deava u toku izvrenja sistema. U tom smislu sistem mora da obezbedi nain oporavka (recoverability) podataka u sluaju nasilnog prekida rada sistema. Takone sistem treba da omogui predvinanje (predictability) moguih ponaanja sistema. Performanse sistema se odnose na vreme odziva (response time) zahtevanih funkcija, propusnu mo (throughput) mree kroz koju prolaze podaci, tanost (accuracy) izvrenja funkcija, mogunost korienja odnosno raspoloivost (availability) funkcija sistema i nain korienje raspoloivih resursa (resource usage) sistema. Po vo t sistema se odnosi na lakou njegovog prilagoavanja (adaptability) i odravanja (maintainability), internacionalizaciju (internationalization) u smislu njegove prilagodljivosti razliitim znakovnim sistemima koji se koriste u svetu i nainu konfigurisanja (configurability) sistema.4
5.5.2 Funkcionalni zahtevi
U ovom delu emo navesti neke konkretne zahteve koji se odnose na nau komponentu. Zahtevi koji se odnose na ulazne interfejse: Zahtevi koji se dobijaju od klijenta se unose putem forme koja se nalazi na web sajtu naeg projekta. On e tom prilikom biti u situaciji da doda kao attachment i excel fajlove u kojima se nalaze vani podaci za testiranje. Zahtevi od MNGR-a e biti dogovorenog formata tako da e BOX-oc CRM moi lako da ih proita i pokrene akcije na osnovu njih. Zahtevi koji se odnose na izlazne interfejse: Rezultati od bug managera moraju biti itljivi i za klijenta i za MNGR-a. Rezultati moraju imati mogunost skladitenja u bazi znanja OQT-BOX-a. Rezultati moraju imati mogunost itljivosti od strane web browsera. Takoe, moraju imati utvren format za svaki tip testa. Zahtevi koji se odnose na unutranji rad izmeu testnih modula u samom OQT- BOX-u: Komunikacija izmeu modula mora biti strogo formatirana korienjem nekih od tehnologija, npr. XML. Komponente moraju biti veoma dobro istestirane kako bi omoguavale takvu komunikaciju i samo testiranje drugih projekata i modula. Komponente moraju imati i mogunost nadgledanja od strane menadera kako bi se pratio njihov rad.
4Dr
Sinia Vlaji, doc., Projektovanje softvera, Beograd 2009.
[46]
6 OQT-BOX
Kao deo OptimalSQM reenja, OQT-BOX e implementirati pravila koja su napravljena i simulirana i primeniti ih na sve SDLC testne aktivnosti kao i finalni test. OQT-BOX je prva industrijska i u realnom vremenu, univerzalna kontrolna jedinica za sve testere, rukovodioce i test programe. OQT-BOX je potpun process i nezavisan od ureaja koji podrava sve nivoe testiranja - i dostupan je kao samostalan proizvod ili deo OQT-TMS-a, gde se izvrava u realnom vremenu po zadatom algoritmu i pravilima kreiranim i objavljenim od strane OQT-MNGR.
Slika 6-1 Komponente OQT BOX-a
[47]
6.1 Osnovne karakteristike OQT BOX-a Univerzalnost opreme - OQT-BOX je nezavistan od opreme za testiranje, kontrolisanje bilo kojeg testera, rukovodioca, sistemskog-odobravanja ili neke druge pomone testne opreme sa standardnim GUI interfejsom. Kao univerzalna kontrolna stanica, OQT-BOX doprinosi utedi vremena i novca za treniranje i drugih dodatnih trokova za maksimalnu produktivnost. Nezavisnost od uredjaja - OQT-BOX je nezavisan proces i proizvod, koji kontrolie svaki proces ili ureaj putem komunikaicje u realnom vremenu sa test programom za bilo koji nivo paralelnog testiranja, i tako eliminie ogranienja performansi. Integrisana funkcionalnost - OQT-BOX izvrava realno-vremenski skup pravila koji je kreiran i izdat od strane OQT-MNGR- garantujui najveu dobit, kvalitet, i pouzdanost ureaja zajedno sa najmanjim trokovima testiranja. Lak, Brz inenjering - OQT-BOX daje mogunosti inenjeringa i rasporeda mogunosti radi lakog obeleavanja, otklanjanja greaka, ponovnog testiranja po izboru i drugih inenjerskih aktivnosti koje mogu biti izvodjene automatski ili po potrebi. Centralizovana kontrola - OQT-BOX moe da radi u tipu kontrolne sobe, dozvoljavajui punu kontrolu procesa testiranja iz jedne centralne lokacije - automatski ili po potrebi. Pouzdan, Dokazan na delu - Svaki OQT-BOX je unapred puten u rad i testiran pre nego se ugradi u vae proizvodno okruenje, i mogunosti su mu jedinstvene, npr. mehanizam povratak-nakon-neuspeha koji se koristi u sluaju prekinute proizvodnje.
Projekat
OQT BOX
Repozitorij znanja i tehnika
Okruenje
Slika 6-2 Generalni prikaz rada OQT BOX-a
[48]
7 Testiranje softvera
Prilikom pruanja usluga ili izrade proizvoda uvek se sledi niz koraka kako bi se izvrio neki skup zadataka. Zadaci se obino izvravaju u istom redosledu. Ureeni skup zadataka smatra se procesom: nizom koraka koji obuhvataju aktivnosti, ogranienja i resurse, a rezultiraju eljenim ostvarenjem. [10] Proces izrade nekog proizvoda se ponekad naziva ivotni ciklus. Zbog toga se nekada softverski razvojni proces naziva i ivotni ciklus softvera jer opisuje ivot softverskog proizvoda od formulisanja, preko implementacije do isporuke, upotrebe, operativnog korienja i odravanja. Procesi su vani jer omoguavaju strukturisanje i konzistentno predstavljanje skupa aktivnosti. Proces razvoja softvera moe biti fleksibilan u pogledu korienja alata i tehnika, koji pojedincima vie odgovaraju. Proces pomae da se odri nivo konzistentnosti i kvaliteta proizvoda ili usluga koje razliiti ljudi realizuju. [10] Proces je sloeniji pojam od postupka. Postupak je umeren nain kombinovanja alata i tehnika u cilju izrade proizvoda (softvera). Proces predstavlja skup postupaka, organizovanih tako da rezultujui proizvod zadovolji unapred postavljeni skup ciljeva i standarda. Na primer, proces moe da zahteva da proverimo delove projekta pre poetka procesa kodiranja. Provera moe da se izvede neformalnim pregledom ili formalnom inspekcijom, od kojih je svaki postupak za sebe, ali im je isti cilj. Razvoj softvera obino obuhvata sledee faze [10]: definisanje korisnikih zahteva, projektovanje, implementacija, testiranje, isporuka, odravanje. Faza Zapoinjanje Analiza Specifikacija T E S T I R A NJ E Implementacija Testiranje& Integracija Odravanje Aktivnost
Definisanje korisnikih zahteva, utvrivanje poslovnih potreba Intervjuisanje stejkholdera, istraivanje sistemskog okruenja Projektovanje, analiza inenjerskih aspekata sistema, definisanje koncepata sistema Programiranje, testiranje jedinica, integrisanje, dokumentovanje Isporuka, integrisanje svih komponenti, verifikacija, validacija, instalacija, obuka Popravljanje bagova, modifikacije, adaptacija
Izlaz
Biznis dokumenta Organizovana dokumentacija Logiki model sistema
Proverljiv sistem Resultati testiranja, funkcionalan sistem Verzije sistema
Slika 7-1 Proces razvoja softvera i pozicija testiranja u celom procesu

[49]
Iako postoji vie faza u procesu razvoja softvera, testiranje softvera odavno nije samo faza u procesu razvoja softvera ve paralelni pod-proces. Pravi stav prema kvalitetu je prevencija, mnogo je bolje izbei probleme nego ih ispravljati. Upravljanje kvalitetom smanjuje trokove razvoja ranije otkrivanje nedostataka smanjuje kasnije znatno vee trokove. Shodno tome, testiranje u OQT BOX-u nije aktivnost koja poinje samo nakon kompletiranja faze kodiranja. Testiranje softvera predstavlja proces analize elementa softvera kako bi se utvrdila razlika izmeu postojeeg stanja i zahteva (tj. bagovi) i kako bi se ustanovile karakteristike softvera. [10] Pouzdanost je sposobnost sistema ili njegove komponente da izvri zahtevane funkcije pod definisanim uslovima u odreenom vremenskom periodu.[10] OQT BOX je paket koji kao primarni cilj ima da se kvalitet softverskog proizvoda usmerava ka obezbeenju to je mogue manje greaka u softveru, njegovoj funkcionalnosti koja zadovoljava ili prevazilazi oekivanje korisnika softvera. Aktivnost testiranja softvera se normalno izvodi kao sredstvo pronalaenja greaka sa ciljem njihovog odstranjivanja iz softverskog proizvoda. Pristup testiranju softvera na bazi otklanjanja greaka je takoe proces koji je podloan grekama. Tester softvera mora da identifikuje i proprati uoen problem do mesta nastanka (izvora) greke u softveru. Za otklanjanje greaka u softveru se moraju istraiti sve prethodne verzije i dokumentacija o aktivnostima u svim prethodnim fazama u razvoju softvera, ukoliko su raspoloivi. Cilj da se pokae da softver nema greaka, kroz otkrivanje i otklanjanje greaka, je loija od strategije da se izvri analiza uzroka nastanka greaka pa tek onda izvri uklanjanje greaka. Jedna od vanijih stavki e biti prevencija greaka, jer je mnogo efikasnije spreiti nastanak greaka nego detektovati i otkloniti iste. To znai da treba testirati svaku proceduru ili modul odmah nakon njegovog pisanja. Testiranje u fazi integracije sistema se mora izvriti odmah nakon integracije komponenti softvera u sistem, to znai da se proces testiranja mora provlaiti kroz ceo proces razvoja softvera, o emu govori Slika 7-1. Paket OQT BOX e uvek stremiti ka poboljanju procesa testiranja i to je konstantan proces zajedno sa svim drugim elementima razvoja softvera. Angauju se sve vei resursi u proces testiranja i njegovo unapredjenje. Postoji vie aspekata koji doprinose poboljanju procesa testiranja: obuka kadrova za proces testiranja automatizacija procesa testiranja razvoj novih alata razvoj novih modela testiranja integracije procesa merenja parametara efikasnosti i efektivnosti procesa testiranja analize slabih i jakih strana postojeeg procesa testiranja identifikacije rizika i njihovih posledica na uspeh procesa razvoja
[50]
7.1 Tehnike testiranja 1. Jedinino testiranje (unittesting) primenjuje se na pojedine klase, module ili komponente programskog koda. Ova tehnika deli se na tehnike bele, crne i sive kutije (white box, black box, gray box). [10] 2. Integraciono testiranje primenjuje se na softverski sistem kao celinu. 3. U testiranja vieg reda spadaju [10]:

Testiranje sigurnosti (security testing): da li su funkcije dostupne onim i samo onim korisnicima kojima su i namenjene. Testiranje koliine podataka verifikovanje da li softver moe obraditi veliku koliinu podataka. Testiranje upotrebljivosti (usability testing) estetski aspekti, konzistentnost korisnikog interfejsa, korisnika dokumentacija. Testiranje integriteta (integrity testing) robusnost (otpornost na otkaze), konzistentna upotreba resursa i sl. Test u stresnim uslovima (stress testing) vrsta testa pouzdanosti sistema pod nenormalnim uslovima (velika optereenja sistema, nedovoljno memorije ili drugih resursa, neraspoloivi servisi i sl.). Etalonski test uporeivanje performansi novog sistema sa nekim, referentnim, poznatim sistemom. Test zaguenja provera da li sistem moe da zadovolji viestruke zahteve razliitih aktera za istim resursom. Test optereenja vrsta testa performansi kojim se procenjuju operativni limiti nepromenjivog sistema pod razliitim optereenjima ili razliitih konfiguracija sistema pri istom optereenju. Najee se mere protok i vreme odziva (srednja i granina vrednost). Test konfiguracije (configuration testing) testira ponaanje softvera u razliitim hardversko/softverskim okruenjima. Test instalacije (installation testing) testira instaliranje softvera na razliitim sistemima i u razliitim situacijama (npr. Prekid napajanja ili nedovoljno prostora na disku).
7.1.1
Metoda bele kutije "White-box"
Ovo testiranje proverava i analizira izvorni kod i zahteva dobro poznavanje programiranja, odgovarajueg programskog jezika, kao i dizajna konkretnog softverskog proizvoda. Plan testiranja se odreuje na osnovu elemenata implementacije softvera, kao to su programski jezik, logika i stilovi. Testovi se izvode na osnovu strukture programa. Kod ove metode postoji mogunost provere skoro celokupnog koda. [11] Kodna pokrivenost je navedena u 6 sledeih koraka:
[51]
Segment pokrivenost svaki segment koda u B/W kontroli strukture se izvrava makar jednom Podruna rasprostanjenost ili vorno testiranje svaki ogranak u kodu se koristi u jednom moguem smeru barem jednom Sloeno stanje rasprostranjenosti kada postoji vie uslova, mora se testirati ne samo svaki smer, ve i sve mogue kombinacije uslova, to se obino obavlja pomou kombinacijske tabele (Truth Table) Osnovni put testiranja svaka nezavisna staza kroz kod koristi prethodno definisan niz Testiranje toka podataka u ovom pristupu, skup srednjih staza kroz kod definie praenje specifinih promenljivih kroz svaki mogui proraun. Praenje se zasniva na svakom odabranom pojedinanom delu koda.Iako ove staze smatraju nezavisnim, zavisnosti izmeu viestrukih staza zapravo nisu testirane za ovaj pristup. DFT (Data Flow Testing) tei da odrava zavisnosti, ali to je uglavnom kroz manipulaciju sekvenci podataka. Ovaj pristup prikazuje skrivene bugove i koristi ih kao promenljive, deklarie ih ali ih ne koristi. Put testiranja put testiranja definie i pokriva sve mogue puteve kroz kod. Ovo testiranja su vrlo teka i dugotrajana. Testiranje petlje ove strategije se odnose na testiranju jedne petlje, grupnih petlji i ispletenih petlji. Zavisnost petlji je prilino jednostavno testirati, osim ako postoji meu petlja ili kod sadri B/W petlju.
U White box testiranju, koristi se kontrola strukture proceduralnog dizajna za dobijanje test sluajeva. Korienjem White box testing metoda jedan tester moe izvui probne sluajeve koji: Garantuju da sve nezavisne staze u modulu budu istestirane barem jednom. Izvravaju sve logike odluke o njihovoj istinitosti ili lanoj vrednosti Izvlae sve petlje na sopstvenim granicama i unutar svojih dozvoljenih operativnih granica. Upotrebljava unutranje strukture podataka kako bi obezbedio njihovu valjanost.
Prednosti u white box testiranju:
Poznavanjem unutranje strukture (tj. samog koda) vrlo lako je uvideti koji tip ulaznih podataka moe pomoi u efikasnom testiranju aplikacije, Pomo u optimizaciji koda, Uklanjenje suvinih linija koda koje mogu izazvati defekte.
Nedostaci u white box testiranju:
Poto je poznavanje unutranje strukture uslov, potreban je vet test inenjer koji e izvesti ovu vrstu testiranja. Ovo zahteva dodatne trokove, Gotovo je nemogue pogledati u svaki deo koda da bi se otkrile skrivene greke, to moe stvoriti problem koji rezultira neuspehom u primeni aplikacije.
7.1.1.1 Ciklomatska kompleksnost
Ciklomatska kompleksnost je softverska metrika razvijena od strane Thomasa McCabe-a i koristi se za merenje sloenosti programa. Ona direktno meri broj nezavisnih putanja izvornog koda. Ciklomatska kompleksnost se rauna korienjem grafa kontrole toka programa. [12]
[52]
Grafovi kontrole toka opisuju logiku strukturu softverskih modula. Modul odgovara jednoj funkciji ili potprogramu, ima jednu taku ulaza i izlaza i moe se koristiti kao komponenta celokupnog dizajna. Svaki graf toka se sastoji od vorova i ivica. vorovi predstavljaju raunske iskaze ili izraze dok ivice predstavljaju tranfer kontrole izmeu vorova. U grafu toka kontrole programa: rombovi predstavljaju uslovne iskaze pravougaonici predstavljaju mogue odgovore na uslovne iskaze vorovi predstavljaju delove softvera koji zamenjuju jedan ili vie pravougaonika ivice oznaavaju sekvence softvera Svaka mogua izvrna putanja softverskog modula ima odgovarajuu putanju od ulaznog do izlaznog vora kontrolnog grafa toka modula. To predstavlja osnovu metodologije strukturnog testiranja. Da bi se za odreeni program iscrtao graf toka kontrole potrebno je numerisati sve iskaze programa. Numerisani iskazi predstavljaju se vorovima u grafu toka kontrole. Izmeu dva vora postoji grana ukoliko, po izvrenju iskaza koji je pridruen izvorinom voru, kontrola moe da se prenese na iskaz koji je pridruen odredinom voru. Ciklomatska kompleksnost se definie za svaki modul kao e n + 2, gde su e i n broj ivica i vorova u grafu a takoe je poznata kao v(G), gde v oznaava ciklomatski broj u teoriji grafova, dok G oznaava da je kompleksnost funkcija grafa. Ciklomatska kompleksnost daje broj nezavisnih putanja kroz jako povezane, usmerene grafove. Jako povezan graf je onaj graf u kojem se bilo kojeg vora moe doi do bilo kojeg drugog vora sledei usmerene ivice grafa.
7.1.2 Metoda crne kutije "Black-box"
Analizira se samo izvravanje specificiranih funkcija i vri se provera ulaznih i izlaznih podataka. Tanost izlaznih podataka proverava se na osnovu specifikacije zahteva za softver. U ovim testovima se ne vri analiza izvornog koda. Problem funkcionalnog testiranja moe da se pojavi u sluaju dvosmislenih zahteva i nemogunosti opisivanja svih naina korienja softvera. Skoro 30% svih greaka u kodu posledica su problema nepotpunih ili neodreenih specifikacija. Sinonimi za black box ukljuuju: ponaanje, funckionalnost, neprozinost i zatvorenost. Test-primeri izvode se iskljuivo iz specifikacije dotinog dela softvera. Ili, drugaije reeno, softver se promatra kao crna kutija o kojoj jedino znamo da bi ona (prema specifikaciji) za zadane ulaze trebala proizvesti zadane izlaze. Zbog postojanja greaka, ulazi iz odreenog (nepoznatog) skupa (Ie) e izazvati neispravno ponaanje, koje emo prepoznati po izlazima iz skupa (Oe). U postupku testiranja nastojimo izabrati ulaze za koje postoji velika verovatnoa da pripadaju skupu Ie. Izbor takvih test primera najee se zasniva na iskustvu softverskog inenjera. Ipak, mogue je i sistematiniji pristup zasnovan na podeli skupa svih moguih ulaznih podataka (domene) na klase. Ovde re klasa nije upotrebljena u smislu objektno-orijentisanog pristupa, nego usmislu matematikog pojma klasa ekvivalencije. Oekujemo da e se program ponaati slino za sve podatke iz iste klase. Biramo barem po jedan test primer iz svake klase. Takoe je dobro isprobati ivice klasa.
[53]
Ulazni podaci
Ie
Testirani deo softvera
Izlazni rezultati
Oe
Slika 7-2Black box testiranje Testiranjem se pokuavaju pronai greke u sledeim kategorijama: Neispravna ili nepotpuna funkcija Greka interfejsa Greka u strukturi podataka ili u pristupu spoljnoj bazi podataka Greka performanse Greka inicijalizacije i greka izvravanja
Primenom metode crne kutije izrauje se skup test sluajeva koji ispunjavaju zahteve: Test sluaja koji smanjuju broj test sluaja na mogunost razumnog testiranja Test sluaja koji e nam prikazati prisutnost ili odsutnost klase greaka
Prednosti black box testiranja:
Testiranje moe biti netehniko (od testera se ne zahtevaju tehnika znanja, kao i poznavanje tehnikih termina). Ovo testiranje e najverovatnije pronai one greke koje bi korisnik pronaao. Testiranje pomae u identifikovanju nejasnoa i protivrenosti funkcionalnih specifikacija. Test sluajevi mogu biti izraeni po zavretku funkcionalnih specifikacija.
Nedostaci black box testiranja:
anse za ponavljanje testova koje je ve odradio programmer. Test ulaza (inputa) zauzima veliki deo prostora.
[54]

7.1.2.1
Teko je utvrditi sva mogua testiranja ulaza u ogranienom vremenu. Pisanje test sluaja je prilino sporo i teko. anse za posedovanje neidentifikovanih staza tokom testiranja.
Ekvivalentno particionisanje
Ekvivalentno particionisanje je metoda testiranja crne kutije koja deli ulazni softverski domen u klasu podataka od kojih se izrauju u test sluajevi. Idealan test sluaja otkriva klasu greaka pre nego to je greka detektovana. Ekvivalentnost particionisanja pokuava da identifikuje naznaenu klasu greaka u test sluaju. Dizajn test sluaja za ekvivalentnost particionisanja je zasnovano na planiranju ekvivalentnih vrednosti unosa (inputa). Ekvivalentne vrednosti prikazuju skup vaeih i nevaeih ulznih uslova (input conditions) u sistemu. [11] Dva glavna koraka koja treba preduzeti u korienju podele na klase ekvivalencije su: Identifikovati klase ekvivalencije za ulaz i izlaz. Izvesti najmanje dve klase za svaki ulazni i izlazni uslov koji je opisan u specifikaciji: o Jednu klasu koja zadovoljava uslov vaeu klasu o Jednu klasu koja ne zadovoljava uslov nevaeu klasu Dizajnirati testne sluajeve bazirane na izvedenim klasama ekvivalencije. Ekvivalentna vrednost moe da se odreuje na osnovu sledeeg: Ako je ulazni uslov (input conditions) specifian niz, jedna vaea i dve nevaee ekvivalentne vrednosti su definisane Ako ulazni uslov (input conditions) zahteva specifinu vrednost, jedna vaea i dve nevaee ekvivalentne vrednosti su definisane Ako je ulazni uslov (input conditions) lan specifinog niza, jedna vaea i jedna nevaea ekvivalentna vrednost je definisana Ako je ulazni uslov (input conditions) Bulova, jedna vaea i jedna nevaea ekvivalentna vrednost je definisana
7.1.2.2
Analiza granine vrednosti
Veoma mnogo greaka se pojavljuje u granicama ulaznog domena i iz tog razloga se koristi analiza granine vrednosti. Analiza granine vrednosti pripada dizajnu test sluaja koji upotpunjuje ekvivalentnost particionisanja. Analiza granine vrednosti izrauje test sluaja i za domen izlaza takoe. Analiza granine vrednosti se odreuje na osnovu sledeeg: Ako ulazni uslov specfikuje stanje oivieno u rasponu od vrednosti A do B, dobijamo test sluajeve sa vrednostima A i B, samo iznad i ispod A i B Ako ulaz specifira stanje razliitih vrednosti, test sluajevi treba da budu izraeni za vebu sa minimalnim i maksimalnim brojkama Ove dve stavke se primenjuju i na izlazne uslove (output conditions) Ako je softver interni, ije su strukture podataka u propisanim granicama,izrauje se test sluaja za vebu strukture podataka u granicama.
[55]

7.1.2.3 Tabela odluivanja
Tabele odluivanja se koriste za beleenje sloenih pravila koja moraju da budu implementirana u programu. Sam postupak tehnike dizajniranja testnih sluaja preko tabele odluivanja se sastoji od nekoliko koraka: 1. Identifikovanje ulaznih uslova (uzroka) i akcija (posledice), 2. Konstruisanje uzrono posledinog grafa, 3. Transformisanje uzrono posledinog grafa u tabelu odluke, 4. Konvertovanje pravila tabele odluke u testne sluajeve. Svaka kolona tabele odluke predstavlja testni sluaj. Uzrok predstavlja poseban ulazni uslov koji donosi unutranje promene u sistem. Posledica predstavlja izlazni uslov, transformaciju sistema ili stanje koje nastaje kombinacijom uzroka. Uzrok se identifikuje detaljnim ispitivanjem specifikacije. Uzrono-posledini graf se konstruieanalizom znaenja specifikacije. vorovima se predstavljaju uzroci, posledice i meuvorovi. Grane oznaavaju AND, OR i NOT zavisnosti meu vorovima, kao i ogranienja tipa I, E, O i R. Ta ogranienja su: I Inkluzija, bar jedan od povezanih vorova mora biti 1 (nedozvoljena kombinacija da su svi 0). E Ekskluzija, najvie jedan od povezanih vorova moe biti 1 (nije dozvoljeno da vie od jednog ima vrednost 1) O One&only one, tano jedan od povezanih vorova mora biti 1. R Requires, ako strelica ide od vora A ka voru B, to znai da bi A bilo 1 mora B biti 1 (nedozvoljena kombinacija B=0 i A=1, ostale su dozvoljene).
7.1.3 Metoda sive kutije- Gray box
Testiranje po metodi Siva kutija je softverska tehnika za testiranje koja koristi kombinaciju tesiranja po metodi Crne kutije i Bele kutije. Ovo testiranje nije Crna kutija zato to tester zna neke interne radnje softvera pod testom. U ovom testiranju, tester sprovodi ogranjienbroj scenarija do internih radnji softvera pod testom. U preostalom delu ovog testiranja, jednom pristupa poput crne kutije u primenjivanju inputa nasoftver pod testom i prati izlaze. Tehnika Sivog testiranja je veoma mona ideja.Koncept je jednostavan; ako neko zna neto o tome kako radi proizvod unutra, taj ga moe testirati bolje, ak i spolja. [12] Ukljuuje mogunost pristupa internim strukturama podataka i algoritama zbog potrebe izrade testnih sluajeva, ali i testiranja kod korisnika ili na black-box nivou. Manipulisanje ulaznim podacima i kreiranje izlaza, ne kvalifikuje se kao gray box jer je jasno da su ulaz i izlaz izvan crne kutije, koju nazivamo sistemom koji se testira.Ova razlika je posebno vana kada se sprovodi integraciono testiranje izmeu dva modula koda koji su napisala dva razliita programera gde su samo interfejsi izloeni testiranju.Meutim, modifikacija podataka se ne kvalifikuje kao gray box jer bi korisnik normalno mogao promeniti podatke izvan testiranog sistema. Gray box testiranje takoe moe da ukljuuje obrnuti (reverse) inenjering da bi se utvrdile, na primer, granine vrednosti ili poruke o grekama.
[56]

7.1.4 Risk box
Mnogi softver projekt menaderi preduzimaju korake u osiguranju svog projekta u vremenu izrade i u okvirima napora (effort) i trokova ogranienja. Meutim upravljanje zahteva mnogo vie napora od praenja i rasporeivanja projekta. Menader treba da utvrdi da li e se neke nepravilnosti pojaviti u toku razvoja i odravanja projekta i da planira njihovo izbegavanje, ili ako su one neizbene, da minimizira njihove negativne posledice. Projektni menaderi esto koriste risk management5 u cilju razumevanja i kontrolisanja rizika u svojim projektima. Risk management ukljuuje nekoliko vanih koraka: 1. Procena rizika projekta razumevanje ta se moe desiti u toku razvoja ili odravanja. Procena se sastoji od tri aktivnosti: identifikacija rizika, analiziranje i odreivanje prioriteta za svakog od njih. 2. Ako se izrauje slian sistem moe se iskoristiti spisak problema koji se mogu pojaviti, korienjem dokumentacije izrade prethodnog sistema 3. Napraviti proveru da li e projekat biti izloen navedenim rizicima 4. Proirenje spiska analizom svake aktivnosti u razvoju projekta dekomponovanjem procesa na manje delove, kada su u pitanju noviji sistemi 5. Analiziranje pretpostavki donoenje odluke o tome kako e projekat biti uraen, ko e voditi projekat i koje resurse e koristiti i najzad, procenjivanje pretpostavki radi utvrivanja rizika 6. Analiza rizika identifikovanje rizika i razumevanje kada, zato i gde se mogu pojaviti 7. Dodeljivanje prioriteta rizicima nacrt prioritetnih rizika omoguuje odvajanje odreenih resursa kojima preti neki rizik Na risk box ima sledee osobine: podrava proaktivno upravljanje rizicima, kontinualnu ocenu rizika i odluivanje tokom ivotnog ciklusa projekta. kontinualno procenjuje, nadgleda i aktivno upravlja rizicima. Upravljanje rizicima u ovom modulu definie est koraka tokom kojih tim upravlja tekuim rizicima, planira i izvrava strategije upravljanja rizicima: Identifikovanje rizika primenom brainstorming-a mogu se identifikovati svi potencijalni rizici. Analiza rizika prema proceni verovatnoe dogaaja rizika i njegovog uticaja na sistem, rizici se sortiraju prema prioritetu. Planiranje rizika koriste se informacije dobijene analizom rizika kako bi se formulisali planovi, strategije i akcije. Za svaki rizik se procenjuje njegov uticaj na ishod projekta, navode se naini njegovom umanjenja i koraci koje treba sprovoditi ukoliko do rizika doe. Praenje rizika nadgleda se status odreenih rizika. Kontrolisanje rizika proces izvravanja planova akcija i njihovog izvetavanja. Uenje iz rizika formuliu se nauene lekcije kako bi se to znanje ponovo upotrebilo u slinim sluajevima kod buduih projekata.
5
Boehm, B., Software Risk Management, IEEE Computer Society Press, Los AlamitosCalifornia, 1989.
[57]
Black Box
Gray Box
Srednja granularnost Unutranja struktura je delimino poznata. Unutranja struktura potrebna za testiranje je poznata. Drugi naziv # Translucent box testing.
White Box
Velika granularnost6 Unutranja struktura je u potpunosti poznata. Unutranji kod aplikacije i baze podataka je poznat. Drugi naziv # Glass box testing # Clear box testing # Design based testing # Logic based testing # Structural testing # Code based testing. # Potpuno obavljaju testeri i programeri..
1 2 3 4
Mala granularnost Unutranja struktura NIJE poznata. Unutranja struktura ne mora da se zna. Drugi naziv # Opaque box testing # Closed box testing # Input output testing # Data driven testing # Behavioral testing # Functional testing # Rade krajnji korisnici. (User acceptance testing). # Takoe, obavljaju i testeri i programeri.
5 6
# Rade krajnji korisnici. (user acceptance testing). # Takoe, obavljaju i testeri i programeri.. Metoda testiranja gde: # Unutranja struktura je delimino poznata (npr. gray), ali nije potpuno poznata (npr. white). #Test dizajn se zasniva na poznavanju algoritama, intervala stanja, arhitekture ili drugih visokih nivoa opisa ponaanja programa. Srednje iscrpna metoda testiranja. Bolja raznovrsnost/dubina u sluajevima testiranja, jer je unutranja struktura vie poznata. Takoe nee biti nedostataka opisanih u White Box testiranju.
Metoda testiranja gde: # Sistem se posmatra kao crna kutija (black box). # Interno ponaanje programa je ignorisano # Testiranje se bazira na eksternim specifikacijama
Metoda testiranja gde: # Unutranja struktura je u potpunosti poznata.
7 8 9 10 11 12 13
Najmanje iscrpna metoda testiranja od ove tri koje se porede. Zasnovana na zahtevima. Sluajevi testiranja su zasnovani na funkcionalnim specifikacijama, poto unutranja struktura nije poznata. Moe biti bazirano na specifikacijama, ako ne postoje nedostaci koji su opisani u testiranju White Box metode. Pogodan je za funkcionalno, odnosno testiranje u domenu biznisa. Nije pogodan za algoritamsko testiranje. Brine se o potvrivanju izaza za dati ulaz, gde se aplikacija tretira kao crna kutija.
Najiscrpnija metoda testiranja od tri navedene. Mogunost da se veba i testira kod u odnosu na razne situacije i podatke. Poto su sluajevi testiranja bazirani na kodu, specifikacije proputene u kodiranju nee biti otkrivene. Pogodan je za sve.
Pogodan je za funkcionalno, odnosno testiranje u domenu biznisa, sa veom dubinom testiranja. Nije pogodan za algoritamsko testiranje. Ovde imamo veu raznovrsnost ulaza i mogunost da izvuemo rezultate testiranja iz baze radi uporeivanja sa oekivanim izlazima. Moe da testira podatke domena, unutranje granice i prekoraenja, ako su poznati.
Pogodan je za algoritamsko testiranje. Olakava strukturalno testiranje. Omoguava logiko pokrivanje, pokrivanje izjava, odluka, uslova, puteva i kontrole toka unutar koda. Moe da odredi unutranje granice, podatke domena, i prekoraenja, i time bolje testira.
Moe testirati samo pokuaje i greke (podaci domena, unutranje granice i prekoraenja).
Slika 7-3Uporedni prikaz tehnika Black Box, Gray Box i White Box
6Granularnost je pojam koji oznaava u kojoj meri je sistem podeljen na male delove. Odnosi se na sam sistem, ili njegov opis ili posmatranje.
[58]
7.2 Metodologija testiranja softverskog proizvoda Glavni je cilj da se metodologija testiranja spaja sa: Odgovarajuim zahtevanim standardom kvaliteta softvera, Strategijom testiranja softvera. Odluke o dvema navedenim stvarima su fundamentalne i moraju se uraditi pre poetka planiranja testiranja.
7.2.1
Odreivanje odgovarajueg standarda kvaliteta softvera
Nivo standarda kvaliteta koji se bira za projekt zavisi uglavnom od karakteristika softverskih aplikacija. Bira se odgovarajui standard kvaliteta softvera: procenjuje se priroda i veliina tete (posledica) u sluajevima pada sistema. Ove tete se tiu i korisnika i programera sa druge strane. Uopeno, vei oekivani nivo tete prouzrokovanog grekom-nedostatkom, zahteva vei standard softverskog kvaliteta.
7.2.2 Odreivanje strategije testiranja softvera
Stvari koje treba odluiti ukljuuju [11]: Strategija testiranja: da li se usvaja integraciono testiranje (big bang) ili inkrementalnastrategija testiranja. Ako je preferirano inkrementalno testiranje, da li e se testiranjeizvriti od dna ka vrhu (bottom-up) ili od vrha ka dnu (top-down) pristupom? Koje delove testnog plana treba izvriti u skladu sa strukturalnim test modelom? Koje delove testnog plana treba izvriti u skladu sa automatizovanim test modelom? Testiranje softvera je proces verifikacije programa ili sistema sa ciljem otkrivanja i ispravljanjagreaka i predstavlja integralni deo razvoja softvera. Primenjuje se u svakoj fazi razvojnogciklusa, a obuhvata vie od 50% vremena potrebnog za razvoj softvera. Ciljevi testiranja softvera su: Verifikacija i validacija, kojima se proverava da li je softver saglasan sa specifikacijomzahteva, to ne znai uvek da je softver tehniki ispravan, pouzdan i bezbedan. Poboljanje kvaliteta softvera. Procena pouzdanosti.
[59]
Slika 7-4 Metodologija testiranja softverskog proizvoda a) Debagovanje podrazumeva otklanjanje sintaksikih i logikih greaka tokom razvojaaplikacije. b) Testiranje ispravnosti obuhvata - funkcionalno testiranje Black- box, - testiranje projekta White-box. c) Testiranje performansi obuhvata pronalaenje i otklanjanje problema koji degradiraju performanse softvera. Ispitivanje performansi najee obuhvata: iskorienje procesorskih resursa, protok podataka i vreme odziva. Tipini resursi koji se proveravaju su: propusni opseg, brzina procesora, iskorienje memorije, zauzetost prostora na disku. d) Testiranje pouzdanosti odreuje verovatnou funkcionisanja softvera bez greke i bez otkaza. Testiranje robusnosti i testiranje optereenjem su primeri testova pouzdanosti, koji pokuavaju da izazovu otkaz softvera u odreenim situacijama. e) Svrha testiranja bezbednosti je identifikacija i otklanjanje greaka koje potencijalno ugroavaju bezbednost, kao i validacija efikasnosti mera zatita. Simulacijom napada mogu se pronai osetljiva mesta softvera. f) Kada je u pitanju nadogradnja softvera, potrebno je proveriti da li je softver komaptibilan sa predhodnim verzijama, proveriti da li korisnik moe da koristi softver saznanjima steenim u predhodnim verzijama. Proces nadogradnje bi trebao da budejednostavan, da korisnici ne ulau puno vremena i sredstava za unapreenje proizvoda.Potebno je ponovno testiranje svih funkcionalnosti softvera, da bi se prepoznale novegreke koje su moda unete prilikom ispravljanja postojeih (regression testing). [11]
7.2.3 Greke i otkazi
Mnogo termina se u literaturi o softverskom inenjerstvu koristi radi opisa nedostataka, otkaza i greaka (eng. malfunction, fault, failure, error, i dr.). Ova terminologija je precizno definisana u standardu IEEE Standard 610.12-1990, Standard Glossary of Software Engineering Terminology (IEEE610-90). Kljuno je jasno razdvojiti uzroke kvara, za koje se esto koristi termin fault ili defect, i neeljenog efekta posmatranog u isporuenom sistemu, koju zovemo failure. Testiranje softvera moe otkriti failures, ali su faults ono to moe i mora biti uklonjeno. Treba prepoznati da uzrok za failure ne moe uvek biti nedvosmisleno identifikovan. Ne postoji teoretski kriterijum radi preciznog odreivanja koji fault je prouzrokovao posmatrani failure. Pojedina terminologija podrava naziv failure-causing inputs umesto faults, tj. onaj skup ulaza koji dovodi do pojave failure. [13]
[60]

7.2.4 Definicija softverske greke
Standard IEEE Std. 610.12 (1990) definie greku kao [13]: 1. Razliku izmeu izraunate, osmotrene, ili izmerene vrednosti ili stanja u odnosu na taan, specificiran ili teoretski dobijen rezultat ili stanje. Na primer, razlika od 10 metara izmeu izraunatog rastojanja i tanog rastojanja. 2. Pogrean korak, proces, ili definisanje podatka. Na primer, pogreno odabrana instrukcija u programu. 3. Pogrean rezultat. Na primer, izraunati rezultat je 11, a taan je 10. 4. ovekov potez koji proizvodi pogrean rezultat. Na primer, pogrean potez operatera na raunaru ili akcija programa na dati potezo peratera. Defekt/Otkaz se moe definisati i kao odstupanje ponaanja, misije softvera u odnosu na zahteve ili specifikaciju softverskog proizvoda. Defekt/Otkaz softvera je evidentan dogaaj postojanja greke u softveru tj. posledica, manifestacija greke u softveru. Skup greaka Potencijalni skup greaka u softveru je zbir greaka i to: Greaka u projektnim zahtevima Greaka u dizajnu softverskog proizvoda Greaka pri kodiranju softverskih komponenti Greaka u dokumentaciji Loe popravke detektovanih problema u softveru
Kljuni aspekti (Key Issues)

7.2.5
Kriterijum selekcije testa / Kriterijum adekvatnosti testa / Pravila okonanja predstavljaju nain odreivanja koji je prikladan skup test sluajeva. Kriterijum selekcije moe se koristiti za izbor test sluajeva ili za proveru da li je izabrani skup testova adekvatan, odnosno za odluivanje da li se i kada testiranje moe zaustaviti. [13] Efikasnost testiranja / Ciljevi testiranja Testiranje je posmatranje primera izvravanja programa. Izbor primera moe biti diktiran od razliitih ciljeva, ali samo u svetlu praenih ciljeva moe se evaluirati efikasnost skupa testova. Testiranje radi identifikacije defekata predstavlja za uspean test onaj koji prouzrokuje pad sistema. Ovo je razliito od testiranja radi demonstracije da softver ispunjava specifikacije ili druge eljene karakteristike, u kojima je testiranje uspeno ako nema padova. Oracle problem Oracle je bilo koji (ljudski ili mehaniki) agent koji odreuje da li se program ponaao korektno u datom testu i prema tome doneo odluku: proao test ili pao test. Postoji mnogo vrsta oracle-a, uz dodatak da oracle automatizacija moe biti vrlo teka i skupa.
[61]

7.2.6 Uloge u zadacima testiranja (checklist)
Projekt menadment
Programeri
Osiguranje kvaliteta
Zadaci
Distribucija sluajeva testiranja Matrica testiranja i sluajeva testiranja Analiza matrice testiranja Ureivanje zahteva matrice sledljivosti Ispitivanje i odobravanje izvetaja testa Ureivanje matrice za praenje testiranja Evaluacija praenja greaka Organizacija validacije korisnika Metrika odravanja Ukljuivanje korisnika u validacioni plan Priprema instalacije i pravljenje korisnikih upustava Testiranje programskog koda Testiranje validacije korisnika Testiranje ispravnosti korisnike dokumentacije Ostala testiranja Razvoj skupova test podataka Razvoj validacionog paketa za isporuku sa kodom Odluka o otklanjanju prijavljenih greaka Dokumentacija o grkama u svakom koraku korisnikog upustva Organizovanje beta testiranja
X X X X X X X X X X X X X X X X X X X X X X X X X
X X
8 Estimacija veliine, vremena, napora i trokova OQT-BOX-a

Glavno pitanje kvaliteta softvera predstavlja obezbeivanje alata i tehnologija koji e omoguiti softverskoj industriji da razvija softverske proizvode i usluge koje su sigurne, pouzdane, a sa druge strane zadovoljavaju ekonomske i finansijske okvire koji su definisani u projektima razvoja ili reinenjeringa softvera. Reavanje ovih pitanja moe u znaajnoj meri poboljati prilike u ICT industriji, kao i stanju IT sektora u domaoj privredi. Kvalitet softvera je vie dimenzionalni koncept koji se ne moe jednostavno definisati. Pri odreivanju kvaliteta softvera potrebno je meriti vie parametara. Ne postoji opta saglasnost koje karakteristike softvera je potrebno meriti, niti kako ih kvantifikovati. Da bi se ostvario potrebni kvalitet softvera, potrebno je reiti osnovnu grupu problema koja se javlja, i to: izbor potrebnih alata, tehnologija i costbenefit analiza. Naroito je bitna su bitne analize koje prethode razvoju ili reinenjeringu softverskog proizvoda i to: analiza moguih prilaza u impleemntaciji kvaliteta, analiza uvoenja promena, implementacija u koracima, odnos ostvarwnog kvaliteta i cene kotanja, analiza cene kotanja i ostzavrenih performansi i cost-benefit analiza. Jedan od izuzetno bitnih faktora u Cost/Benefit analizi je odreivanje cene kotanja razvoja novog softvera ili reinenjeringa starog . Sem toga, na
[62]
Korisnici
Pisac upustava
Kupci
trokovnoj strani moraju se uzeti u obzir trokovi nabavke novog softvera i eventualni trokovi koje bi nastali kao posledica procesa reinenjeringa informacionog sistema u preduzeu. Pri ovome je potrebno definisati veliki broj uticajnih parametara koji definiu sloenost i osobine projekta softverskog (re)inenjeringa. 8.1 Merenje broja funkcionalnih taaka Prvi i osnovni zadatak za estimiranje trokova, kvaliteta i ostalih parametara softvera je da se pronae broj funkcionalnih taaka. Mnogi softverski strunjaci tvrde da je funkcionalnost produkta daje bolju sliku o veliini produkta nego njegova duina. U ranoj fazi projektovanja intersantnija je funkcionalnost kada su u pitanju napor i vreme od same fizike veliine. Funkcionalne take mere koliinu funkcionalnosti sistema opisanog specifikacijom. Da bi se izraunale funkcionalne take potrebno je identifikovati raunljive diskretne komponente sledeeg tipa: Eksterni ulazi -procesni podaci ili upravljake informacije koje dolaze izvan Eksterni izlazi - procesni podaci podaci i upraravljake informacije koje idu van Eksterni upiti - interaktivni upiti koji zahtevaju izlaz Eksterne interfejs datoteke - mainski itljive za druge sisteme Interne matine datoteke - logike interne datoteke Albrecht je funkcionalne take FP raunao po formuli : Broj FP= broj ulaza x 4 + broj izlaza x 5 + broj upita x 4 + broj matinih datoteka x 10 + broj interfejsa x 7 sa tim da teinski faktori mogu varirati +/- 25% zavisno od kompleksnosti programa. Teinski faktori su prikazani u tabeli BAZNI ELEMENT TEINSKI FAKTOR JEDNOSTAVAN SREDNJI KOMPLEKSAN ULAZI IZLAZI UPITI EKSTERNI FAJLOVI 3 4 3 7 4 5 4 10 6 7 6 15
INTERNE DATOTEKE
10
Slika 8-1 Faktori za podeavanje FP-a

[63]
Pomou gornje formule se dobiju nepodeene funkcionalne take UFC. Podeene funkcionalne take se dobiju mnoenjem UFC sa faktorom tehnike kompleksnosti TCF koji ima 14 doprinoseih faktora (on-line ulazi, on-line auriranje, kompleksnost interfejsa, ponovna upotreba, komuniciranje sa podacima itd.) i varira od 0.65 do 1.35. Glavna namena FP je: merenje veliine produkta koja se koristi u predvianju napora i trokova u ranoj fazi ivotnog ciklusa softvera (specifikacija, projektovanje) predvianje broja linija izvornog koda konverzija veliine projekta pisanog u jednom jeziku u veliinu projekta pisanog u drugom jeziku jer su FP nezavisne od jezika merenje produktivnosti projekata koji su pisani u vie jezika normalizacija u odnosu na FP (defekti/FP, ovjek mjesece/FP itd. upotreba FP kao baze za ugovaranje. Nedostaci FP su: tekoa raunanja jer razliiti ljudi mogu da razliito raunaju FP i potrebna je vrlo detaljna specifikacija za razliku od LOC-a ne mogu se automatski raunati neke empirijske studije sugeriu da FP nisu vrlo dobre za predvianje napora i da su nepotrebno kompleksne problem sa subjektivitetom tehnolokog faktora problem sa aplikacionim domenom (komercijalne aplikacije, aplikacije u realnom vremenu, naune aplikacije)
Oekivani broj linija izvornog koda dobijen iz FP (ili na neki drugi nain) omoguava predvianje drugih karakteristika softvera. Na osnovu resurs modela , koji se sastoji od empirijskih jednauna, obino se predvia: E napor u ovek / mesecima D trajanje projekta DOC broj linija dokumentacije Meutim, treba imati u vidu da se empirijski podaci dobijaju na osnovu limitiranog i specifinog broja projekata i resurs model nije odgovarajui za sve klase softvera. Basili je resurs modele svrstao u etiri klase: statiki jednovarijabilni model statiki multivarijabilni model dinamiki multivarijabilni model teoretski model Statiki jednovarijabilni model ima sledeu formu: resurs = c1 x (oekivane karakteristike) c2
[64]
Konstante c1 i c2 se deriviraju iz prethodnih projekata. Kao primer Pressman navodi studiju Walston-a i Felix-a baziranoj na 60 razvojnih projekata na osnovu kijih su doli do sledeih rezultata, odnosno modela. E = 5.2 x L0.91 D = 4.1 x L0.36 D = 2.47 x E0.35 S = 0.54 x E0.06 DOC = 49 x L1.01 E, D (trajanje projekta i kalendarsko trajanje projekta) i DOC su izvedeni na osnovu L tj. broja linija izvornog koda u hiljadama. Alternativno, S (potrebni ljudi) i trajanje projekta mogu biti izraunati iz deriviranog ili predvienog napora E. Gornje jednaine se ne mogu uzeti generalno jer zavise od okruenja i specifinosti aplikacija. Ovakav model se derivira na osnovu lokalnog okruenja i istorijskih podataka. Ostali tipini modeli su : E = 5.5 X 0.73 L1.16 (Bailey-Basili model) 1.05 E = 3.2 X L (Bohem-ov jednostavni model) 1.12 E = 3.0 X L (Bohem-ov srednji model) E = 2.8 X L1.20 (Bohem-ov kompleksni model) 1.047 E = 5.288 X L (Doty model) Ove modele je veoma teko porediti zbog razliitih definicija L (npr. da li su uraunati komentari ili ne) i E (da li se odnosi samo na kodiranje ili i na ostale faze ivotnog ciklusa softvera). Upotrebom 217 Schaefer predvia broj ovek / meseci potrebnih za odravanje softvera godinje E.maint na sledei nain : E.maint = ACT x 2.4 x L1.05 gde se ACT definie sa : ACT = ( L - za sistem koji se odrava) / CI pri emu je CI broj linija koda koje su modifikovane ili dodane za vreme jednogodinjeg odravanja. Statiki multivarijabilni model ima sledeu formu : resurs = c11 x e1 + c21 x e2 + ... gde je ei i-ta softverska karakteristika a ci1 empirijski derivirana konstanta za i-tu karakteristiku softvera. Dinamiki multivarijabilni model projektuje zahteve za resursima kao funkciju vremena. Teoretski model pretpostavlja specifinu distribuciju napora u toku razvoja projekta i na osnovu toga prati ponaanje resursa.
21 - statiki jednovarijabilni resurs model [65]

8.1.1 Izraunavanje grubih funkcionalnih taaka
U prvom delu ovog poglavlja raunaemo broj grubih funkcionalnih taaka8. Prvo emo odrediti funkcionalne komponente sistema,a zatim emo ocenjivati sloenost tih komponenti. U naem sluaju mi emo se bazirati na nau komponentu OQT- BOX. Za nau komponentu na osnovu dijagrama toka podataka datog na sliciError! Reference source not found. moemo proitati sledee vrednosti: Korisniki ulazi: Komponenta MNGR i Client Broj korisnikih ulaza- 2 Korisniki izlazi: Komponenta MNGR i Client Broj korisnikih izlaza- 2 Unutranji procesi: Analiza zahteva, Black box testiranje, White box testiranje, Gray Box testiranje, Risk box procena i analiza dobijenih rezultata Broj unutranjih procesa- 6 Interni fajlovi: Fajlovi koji se razmenjuju izmeu komponenti i procesa Broj internih fajlova- 7 Eksterni fajlovi: Interna baza znanja i fajl koji se dobija na zahtev OQT Box komponente od ostalih komponenata sistema Broj eksternih fajlova- 2 Sada odreujemo nivo sloenosti za sve funkcionalne komponente( jednostavna, prosena, sloena). Nivo sloenosti smo odreivali na osnovu kompleksnosti podataka koje te komponeente nose. To je prikazano na sledeoj tabeli.
Komponente OQT-BOX-a Jednostavne
Broj Teinski faktor Take Broj
Nivo sloenosti Prosene

Teinski faktor Take Broj
Ukupno CFP Sloene

Teinski faktor Take
Korisniki ulazi Korisniki izlazi Unutranji procesi Interni fajlovi Eksterni fajlovi
A ----1 3 ---
B 3 4 3 7 5
C=AxB ----3 21 ---
D 1 1 1 2 ---
E 4 5 4 10 7
F=DxE 4 5 4 20 ---
G 1 1 4 2 2
H 6 7 6 15 10
I=GxH J=C+F+I 6 10 7 24 30 20 12 31 71 20
Ukupan broj CFP
144
crude function points CFP [66]
Slika 8-2 Izraunavanje grubih funkconalnih taaka

8.1.2 Izraunavanje broja podeenih funkcionalnih taaka
Dakle, u ovoj fazi estimacije moramo da uzmemo u obzir karakteristike nae komponente, razne specifinosti koje su dati u tabeli. Iz svega toga emo dobiti faktor za podeavanje i zatim emo biti u stanju izraunati podeene funkcionalne take. Br 1 2 3 4 5 6 7 8 9 10 11 12 13 14 Zahtev Uslov Zahtev za pouzdanim bekapom i oporavkom Zahtev za prenosom podataka (komunikacijama) Nivo distribuirane obrade Zahtevi za performansama Oekivano operativno okruenje Nivo onlajn ulaza za podatke Nivo multi-screen ili multi-operativnih onlajn ulaza za podatke Nivo onlajn auriranja master fajlova Nivo sloenih ulaza, izlaza, onlajn obavetenja i fajlova Nivo sloene obrade podataka Mera do koje trenutno razvijeni kod moe biti dizajniran za ponovno korienje Nivo konverzije i instalacije ukljuene u dizajn Nivo viestrukih instalacija u organizaciji i razliitim klijentskim organizacijama Mera promene i fokus na jednostavnost korienja Koeficijent za podeavanje( RCAF) Ocena 012345 012345 012345 012345 012345 012345 012345 012345 012345 012345 012345 012345 012345 012345 46
Slika 8-3 Forma za izraunavanje RCAF-a Sada imamo sve to nam je potrebno da izraunamo broj podeenih funkcionalnih taaka, to nam u stvari predstavlja priblino stvaran broj funkcionalnih taaka. Izraunavanje vrimo primenom navedene formule na sledei nain:
CFP(broj grubih funkcionalnih taaka)=144 RCAF(faktor podeavanja grubih funkcionalnih taaka) =46 FP = CFP x (0.65 + 0.01 x RCAF) = 144 x (0.65 + 0.01 x 46) = 159.84 FP
Izraz 1 Broj podeenih funkcionalnih taaka( FP)
[67]
Dakle, primenom navedene formule dobili smo 160 funkcionalnih taaka koji je estimiran za nau komponentu OQT- BOX.
8.1.3
Izraunavanje broja linija koda
Na osnovu FP moe se odrediti numeriki nivo jezika i to je taj nivo vii potrebno je manje linija koda po FP. Numeriki nivo jezika omoguava preicu za konvertovanje veliine softverskog produkta iz jednog jezika u drugi. U sledeoj tabeli dati su neki jezici, njihovi nivoi i srednji broj izvornih linija po FP prema : SREDNJI BROJ IZVORNIH LINIJA KODA PO FP ADA 95 6.50 49 ANSI COBOL 85 3.50 91 BASIC MS 3.50 91 C++ 6.00 53 CLIPPER 17.00 19 CLIPPER DB 8.00 40 COBOL 3.00 107 DELPHI 11.00 29 EIFFEL 25 21 FORTRAN 95 4.50 71 FRAMEWORK 50.00 6 HTML 3.0 22.00 15 JAVA 6.00 53 MOSAIC 50.00 6 ORACLE 8.00 40 POWERBILDER 20.00 16 SMALLTALK 15.00 21 VISUAL C++ 9.5 34 Slika 8-4 Relacije jezici nivoi - izvorne linije koda Ako predpostavimo da emo koristiti C++ ili Java jezik za programiranje onda smo u stanju estimirati broj linija koda koji e imati naa komponenta. Prosto pomnoimo broj funkcionalnih taaka sa prosenim brojem linija koda koji generie taj jezik po jednoj funkcionalnoj taki. JEZIK NIVO
FP(broj podeenih funkcionalnih taaka)=160 LOC(faktor ekspanzije funkcionalne take na broj linija koda)=53 L(broj linija izvornog koda)= FP x LOC= 160 x 53= 8480 LOC
Izraz 2 Broj linija izvornog koda
[68]
8.2 Primena 12 Capers Jones-ovih pravila9

8.2.1 Pravilo 1 - Estimacija veliine izvornog koda
Pravilo 1. se tie izraunavanja funkcionalnih taaka i pretvaranja u linije koda. To je pravilo demonstrirano u prethodnom poglavlju.
L= 160 x 53= 8480 LOC

ako koristimo C++ ili Javu.
8.2.2 Pravilo 2 Estimacija dokumentacije

Ovo pravilo nam omoguava da estimiramo svu dokumentaciju vezanu za softverski paket, ukljuujui specifikaciju i uputstva.
FP(broj podeenih funkcionalnih taaka)=160 Dokumentacija= FP1.15 stranica Dokumentacija=1601.15= 342 stranice
Izraz 3 Estimacija dokumentacije
8.2.3
Pravilo 3- Estimacija odudaranja korisnikih zahteva
Ovo pravilo kae da prilikom realizacije projekta odudaranje od korisnikih zahteva je u proseku oko 2 % meseno. Stoga je vano estimirati trokove ovakvog problema koji se pojavljuje.
8.2.4 Pravilo 4- Estimacija broja sluajeva testiranja
Funkcionalne take nam takoe omoguavaju da estimiramo broj test sluajeva koji su potrebni da se dobro testira softverski proizvod. Ta estimacija se radi na sledei nain:
FP(broj podeenih funkcionalnih taaka)=160 Broj test sluajeva= FP1.2 Broj test sluajeva=1601.2= 441 test sluajeva
Izraz 4 Izraunavanje broja test sluajeva
8.2.5
Pravilo 5- Estimacija potencijalnog broja greaka
Postoji pet velikih vrsta greaka u razvoju softvera: 1. Greke u zahtevima 2. Greke u dizajnu 3. Greke u kodiranju
9
Manual Techniques, Rules of Thumb, Prof. Dr. M. Glinz Arun Mukhija 2002. [69]
4. Greke u dokumentaciji 5. Loe ispravljene greke, tzv. sekundarne greke koje su prouzrokovane ispravljanjem neke druge greke. Vie od polovine svih softverskih greaka se isprave u prve dve faze. Nain na koji moemo da estimiramo mogunost defekta u naem softveru je sledei:
Potencijalni broj greaka=FP1.25

Potencijalni broj greaka za OQT BOX komponentu je:
Potencijalni broj greaka= 1601.25= 569 moguih greaka

Izraz 5 Estimacija potencijalnih greaka
8.2.6 Pravilo 6 Estimacija efikasnosti otklanjanja greke

Ovo pravilo nam govori kako je teko pronai greke prilikom testiranja. Ovo pravilo kae da svaki korak testiranja pronalazi i otklanja odreen broj greaka u svakoj fazi. Ti brojevi dati su u vidu tabele:
Slika 8-5 Matrica efikasnosti otklanjanja greke

8.2.7 Pravilo 7- Estimacija efikasnosti organizovanog otklanjanja greaka
Ovakav nain otklanjanje greaka je skuplji i zahtevniji vremenski ali i efikasniji. Ovo pravilo kae da svaka inspekcija dizajna e pronai i otkloniti odreen procenat greaka u tom trenutku. Ti procenti dati su na Slika 8-5 Matrica efikasnosti otklanjanja greke
8.2.8 Pravilo 8- Estimacija efikasnosti otklanjanja greaka nakon putanja softvera u rad
Programeri zadueni za odravanje softvera mogu ispraviti odreen broj greaka koji zavisi od TMM i CMM nivoa.
[70]

8.2.9 Pravilo 9- Estimacija trajanja realizacije projekta
Estimacija trajanja realizacije projekta DM (Development in months) predstavlja jednu od najvanijih informacija za klijente, project menadere i softverske programere. Izraunava se na sledei nain:
FP(broj podeenih funkcionalnih taaka)=160 DM=FP0.4 [KM] kalendarskih meseci DM= FP0.4=1600.4= 7.5 [KM] kalendarskih meseci
Izraz 6 Estimacija trajanja projekta Napomena: Ovo je samo gruba procena. Ne treba se uzimati toliko ozbiljno.
8.2.10 Pravilo 10- Estimacija potrebnih ljudi za realizaciju projekta
Za planiranje projekta je veoma vano koliko vam ljudi treba za realizaciju samog projekta. Ovo pravilo nam pomae u tome.
FP(broj podeenih funkcionalnih taaka)=160 Prosena produktivnost projektanata=150 Broj projektanata= FP/Prosena produktivnost projektanata Broj projektanata=160 /= 2 projektanta
Izraz 7 Estimacija ljudi potrebnih za projekat
8.2.11
Pravilo 11- Estimacija ljudi potrebnih za odravanje softvera
Slino prethodnom pravilu. Izraunava se na sledei nain:
FP(broj podeenih funkcionalnih taaka)=160 Broj ljudi za odravanje= FP/ prosena efikasnost odravanja Broj ljudi za odravanje=FP/ 750= 160 /750 = 1 ovek
Izraz 8 Estimacija ljudi potrebnih za odravanje
8.2.12
Pravilo 12- Estimacija ukupnih napora u realizaciji softverskog projekta
Ovo pravilo predstavlja kombinaciju pravila 9 i 10. Primenjuje se na sledei nain:
Ukupni Napor= Ukupno vreme * broj ljudi= 7.5*2 = 15 ovek-meseci
[71]
8.3 Model zrelosti sposobnosti (CCM) Model zrelosti sposobnosti (Capability Maturity Model, CMM) je razvijen od strane amerikog Instituta za softversko inenjerstvo (Software Engineering Institute, SEI) sa ciljem podrke Ministarstvu odbrane SAD prilikom procene kvaliteta ugovaraa. CMM je, inspirisan radovima Deminga (1989), poeo kao model zrelosti procesa u kome je razmatrana organizacija vrednovana na skali od 1 (nizak) do 5 (visok), na osnovu odgovora na 110 pitanja vezanih za primenjivani proces razvoja. Na slici 6-2 prikazan je sumarni pregled uzdizanja od niih nivoa zrelosti ka viim nivoima zrelosti. CMM koristi upitnik da bi se procenila zrelost razvojnog projekta, upitnik je dopunjen zahtevom da se daju dokazi koji potvruju odgovore, a ocenjuje na skali od pet stepeni. CMM opisuje principe i praksu za koje se uzima da daju bolje softverske proizvode, organizovan je u pet nivoa, ime obezbeuje put ka boljem uoavanju i kontroli procesa i ka poboljanim proizvodima koji iz toga proizilaze. Model ima dvojaku namenu: koriste ga potencijalni kupci da bi identifikovali jake i slabe take svojih dobavljaa i koriste ga projektanti da bi procenili sopstvene sposobnosti i sagledali puteve koji vode do poboljanja. [21]
Slika 8-6 Nivoi zrelosti definisani od strane Instituta za softversko inenjerstvo Pre samog testiranja, kompanija e morati da odgovori na pitanja, a na sonovu odgovora, mi emo im ponuditi odgovarajui sistem testiranja, shodno nivou zrelosti njihove kompanije. Takoe, kompaniji (klijentu) e biti ponuena pomo u vidu naih softverskih paketa. Ulazni podaci se obrauju, zatim se rade cost-benefit analiza, benchmarking i cost of quality.
8.3.1 CMM Nivo 1
Inicijalna faza: Testiranje softvera (TS) je haotian proces, loe je definisan i nije jasno razgranien sa fazom otklanjanja greaka (debugging). Testiranju se pristupa neplanirano i na kraju faze kodiranja programa. Cilj testiranja softvera je da se pokae da program radi. Softver se
[72]
iznosi na trite bez primene sistema obezbeenja kvaliteta. Nedostaju resursi, alati i adekvatno obuen kadar. Ovaj tip organizacije odgovara SEI/CMM Level 1, zrelosti softverske kompanije.
8.3.2 CMM Nivo 2
Faza Definisanja: Testiranje softvera je odvojeno od faze otklanjanja greaka (debugging) i definisano je kao odvojena faza nakon kodiranja. Mada je planirana kao aktivnost, Testiranje softvera na Nivou 2, je definisano nakon faze kodiranja zbog nezrelosti samog procesa Testiranja softvera. Glavni cilj Testiranja softvera, na ovom nivou zrelosti (CMM), je da se pokae da je softver zadovoljio specifikaciju. Primenjuju se osnovne tehnike i postupci. Mnogi problemi vezani za kvalitet softvera na ovom CMM nivou posledica su planiranja TS kasno u ciklusu razvoja softvera (SDLC). Dalje, greke (otkazi) softvera u ranim fazama prostiru se do poslednjih faza SDLC tj. ne otkrivaju se blagovremeno, odnosno onda kada se i generiu.
8.3.3 CMM Nivo 3
Faza Integrisanja: TS nije vie faza koja sledi fazu kodiranja, naprotiv, TS je integrisani deo SDLC. Organizacije koje su ovladale CMM Nivo 2, za razliku od CMM Nivoa 2, na Nivou 3 aktivnost TS se odvija i planira od poetka SDLC tj. projektnih zahteva za softver pa do kraja najee V modela SDLC. Ciljevi i zadaci TS su utvreni na bazi zahteva klijenata i moguih kupaca softvera i koriste se u fazi dizajna test primera i kriterijuma uspenog odziva testa. Organizaciono je uspostavljena grupa za TS, a TS je profesionalni posao lanova tima. Obuka kadra je fokusirana na oblast TS. Osnovna sredstva, alati za TS su u upotrebi. I ako organizacije na ovom CMM nivou znaju za znaaj kontrole i obezbeenja kvaliteta, ova funkcija nije formalno primenjena u SDLC. Program merenja kvaliteta TS kao i samog kvaliteta softvera kao proizvoda nije jo uspostavljen.
8.3.4 CMM Nivo 4
Faza Merenja i Upravljanja: Proces TS se meri i kvalitet (cena, efikasnost, efektivnost) ocenjuje. Inspekcije i revizije se primenjuju planski u svim fazama SDLC kao obavezna aktivnost u TS i kontroli kvaliteta. Softverski proizvod se testira radi ocene faktora kvaliteta kao to su pouzdanost, upotrebljivost i pogodnost za odravanje. Aurira se baza podataka o testprimerima sa svih projekata radi ponovne upotrebe pri regresionom (ponovljenom) testiranju. Otkazi, greke, se evidentiraju u bazi podataka o otkazima, grekama i dodeljuje im se znaaj (kritinost). Nedostatak TS na ovom CMM nivou je i dalje nedovoljno primenjena preventivna aktivnost generisanja softverskih greaka, slabo razvijena metrika kvaliteta TS kao i sredstva automatizacije TS.
8.3.5 CMM Nivo 5
Faza Optimizacije, Prevencije greaka i Kontrola kvaliteta: Nakon uspene izgradnje infrastrukture kroz sazrevanje CMM od Nivoa 1 do 4, za koji se moe rei da je TS definisan i kontrolisan, preko metrika kao to su trokovi, efikasnost, efektivnost sada se na CMM Nivo 5 pristupa finom podeavanju i stalnom unapreenju kvaliteta TS. Proces TS je kontrolisan statistikim postupcima uzorkovanja i merenja nivoa poverenja metrika kvaliteta TS kao to su trokovi, efikasnost, efektivnost. Uspostavljena je procedura za izbor i ocenu sredstava i alata za TS. Automatska sredstva TS se koriste u svim fazama testiranja softvera dizajnu test-primera, izvravanju testova, ponovnom izvravanju, auriranju baze podataka o otkazima, grekama, alati za metriku, praenje generisanja i analizu uzroka istih kao i sredstva odravanja tzv.Testware.
[73]
8.4 Cost benefit analiza COCOMO (COnstructive COst MOdel) predstavlja model za procenu cene kotanja softvera koji je razvijen kao otvoreni model od strane Direktora Centra za Softverski innjering na USC Dr Barry Boehm-a. Polazna osnova u izraunavanju u COCOMO modelu je korienje Effort Equation (jednaine ulaganja) koja ima za cilj procenjivanje veliine podatka osoba/mesec koja je neophodna za razvoje projekta. Svi ostali COCOMO rezultati, ukljuujui i procene sa zahtevima i odravanjem se izvode iz ove veliine. COCOMO prorauni se baziraju na procenjenoj veliini projekta koja se meri brojem linija izvornog koda Source Lines of Code (SLOC). SLOC se definie kao: jedino linije koda koje se isporuuju kao deo softverskog proizvoda se broje - drajveri za testiranje i drugi softver za podrku se ne raunaju; linije koda koji su generisali zaposleni programeri - kod kreiran od strane generatora koda se iskljuuje; jedan SLOC je jedna logika linija koda; deklaracije se raunaju kao SLOC; komentari se ne raunaju kao SLOC. COCOMO II model sdri i Scale Drivers - uticajne faktore koji najznaajnije utiu na vreme i trajanje projekta. Potrebno je proceniti pet uticajnih faktora koji su elementi jednaine ulaganja. Uticajni faktori su: specifinost, fleksibilnost razvoja, arhitektura / razreavanje rizika, kohezija tima i zrelost procesa. COCOMO II, takoe sadri i 17 uticajnih faktora na cenu. Cenovni uticajni faktori odreuju trud koji je neophodan za kompletiranje softverskog projekta. Na primer, ukoliko se razvija softver za kontrolu leta avio kompanije, uticajni faktor Zahtevana Pouzadnost Softvera - Required Software Reliability (RELY) i njegova cena bie postavljeni na vrlo visoku vrednost. Jednaina ulaganja u COCOMO II modelu procenjuje potreban broj osoba/meseci person/months - PM na osnovu procene veliine projekta merenog u hiljadama SLOC ili KASLOC. Effort=2.94*EAF*(KASLOC)E Gde je: KASLOC - broj adaptiranih linija koda EAF - faktor podeavanja ulaganja (Effort Adjustment Factor) koji pripada grupi cenovnih faktora (Cost Drivers) E - eksponent dobijen iz pet veliinskih uticajnih faktora (Scale Drivers) Faktori podeavanja ulaganja su proizvod svih uticajnih faktora. COCOMO II jednaina plana predvia broj meseci neophodnih za zavretak softverskog projekta. Vreme trajanja projekta se bazira na Effort jednaini: Duration=3.67*(Effort) SE Gde je: Effort - vrednost dobijena iz Effort jednaine SE - eksponent za jednainu plana dobijen iz pet veliinskih uticajnih faktora (Scale Drivers) Jedan od najbitnijih faktora je SCED ili Required Development Schedule koji ukazuje na potencijalnu mogunost da projekat zahteva vie rada za razvoj nego to je to predvieno kao optimum. Pri korienje USC-COCOMO II softvera polazimo od nekih osnovnih pretpostavki, a jedna od osnovnih je procenjivanje veliine projekta.
[74]
Sa slike se vidi kolika moe biti nepreciznost procenjivanja veliine i cene softvera u zavisnosti od faze projekta. Kako napreduje ivotni ciklus proizvoda, i kako se donose odluke bitne za razvoj proizvoda, priroda proizvoda i naravno veliina mogu bolje da se sagledaju. "Zavreni programi" predstavljaju sedam stvarnih projekata razvijenih od strane tima koji je predvodio autor metode, dok "USAF/ESD predlog" se odnose na pet predloga USA Air Force Electronic System Division koji su dati u cilju ocenjivanja metode. Poto cena softvera moe da se ocenjuje u razliitim fazama razvoja projekta uvedeni su moduli Rani dizajn (Early Design) i Zavrna arhitektura (Post- Architecture)
Slika 8-7 Procena veliine i cene softvera u zavisnoti od faze U Fazi Early Design modela ukljuuju se pitanja korienja alternativnih softvera/arhitekture sistema i koncepata. U ovom stadijumu, obino, nema dovoljno poznatih informacija za fino kalibrisanje modela. U ovoj fazi COCOMO II softvera koriste se 7 cenovnih uticajnih faktora (i dva Sposobnost zaposlenih Personnel Capability i Iskustvo zaposlenih Personnel Expirinece, dok se u drugoj fazi Post Arhitecture modela koriste 6 faktora i razliiti aspekti osposobljenosti, iskustva i kvaliteta zaposlnenih.) Post-Architecure model ukljuuje stvarni razvoj i odravanje softvera. Ova faza daje najbolje rezultate ukoliko razvija arhitekturu softvera, koja odgovara misiji sistema, konceptu funkcionisanja i ukoliko uspostavlja okvir za kompletan prozivod.
8.4.1
Trokovi osiguranja kvaliteta softvera [22]
Razmatramo TQM model (engl. Total Quality Management), to znai potpuno ukljuivanje svih funkcija i svih zaposlenih u preduzeu, dobavljaa i kupaca na ostvarivanju visokog kvaliteta uz najnie trokove. U inenjerstvu kvalitet softvera, cena i vreme su tri meusobno zavisna faktora. Ako su dva od ovih faktora konstante, trei faktor nije mogue kontrolisati. Ova tri elementa uzrokuju i najvee probleme, jer su trokovi i vreme isporuke softvera esto iznad predvienih veliina, a esto softver ne zadovoljava zahteve korisnika. Meutim, zadovoljstvo korisnika je osnovni cilj osiguranja kvaliteta.
[75]
Odravanje softvera je najskuplja faza ivotnog ciklusa softvera, jer se tu prave i najvei trokovi koje treba smanjiti delujui po odreenim modelima. Odravanje softvera definiemo sa etiri aktivnosti nakon to je program stavljen u upotrebu. 1) Korektivno odravanje:Nerezonski je pretpostaviti da se greke u velikim softverskim programima mogu otkriti u fazi testiranja. 2) Adaptivno odravanje: Dogaa se zbog estih izmena koje se dogaaju u svakom aspektu kompjuterizacije. 3) Perfektivno odravanje: Odravanje softvera zadovoljava zahteve korisnika ali preporuuju se nove mogunosti (modifikacije). 4) Preventivno odravanje: Kada se proces razvoja softvera menja kako bi se poboljala mogunost odravanja i pouzdanosti. Mnogi modeli se bave problemom smanjenja trokova a da su konkurentni na tritu i sa to boljim kvalitetom. Najvei uzroci nekvaliteta su greke koje nastaju u fazama zivotnog ciklusa proizvoda. Mi emo predstaviti i dati formulu trokova u fazi odravanja za tzv. Vodopadni model razvoja softvera: POD = Faza nastajanja Defekta (u fazi razvoja ili odravanja) PD = Proli (prebegli) Defekti (iz bive faze ili aktivnosti osiguranja kvaliteta) % FE = % Efikasnost filtriranja (u ovoj fazi efikasnost uklanjanja treba da je 100% jer samo na taj nain imamo kvalitetan softver) RD = Uklonjeni Defekti (broj) CDR = Trokovi Uklanjanja jedne greke (u fazi odravanja cena uklanjanja jedne greke je 110 puta vea nego da je ukljonjena u fazi kad je greka nastala) TRC = Totali trokovi uklanjanja: TRC = RD CDR. U sledeem primeru, uz predpostavku da nije napravljena nijedna greka u tekuoj fazi PD=10, %FE=100%, RD=svi pridoli, ukupni trokovi uklanjanja iznose: TRC= RD CDR =10*110=1100 jedinica cene (, Eur) ili TRC= RD CDR %FE=(10*110)*100%=1100 jed. cene. Ovi trokovi odravanja se mogu izbei ako se sprovedu odgovarajue mere iz modela TQM u predhodnim fazama gde uklanjanje jedne greke mnogo manje kota, kao na primer u fazi specifikacije zahteva, gde uklanjanje jedne greke kota 1 jedinica cene, u fazi Dizajna 2.5, u fazi Jedininog testiranja 6.5, Integracioni test 16, Sistem test 40 jedinica cene. Efikasnost detekcije defekta (procentualno) ili DDE pokazuje kolika je uspenost testiranja i detekcija greke, sto poboljava kvalitet softvera. Ova metrika se proraunava po formuli: DDE=TDFT/(TDFT+TDFC)*100 gde je: TDFT -ukupno defekata naeno testiranjem (rezultat test tima), a TDFC - ukupno defektata naeno kod korisnika (mereno do neke take od putanja softvera- 6 meseci). Efikasnost uklanjanja defekta ili DRE pokazuje kolika je uspenost aktivnosti Testiranja tj. uklanjanja detektovane greke, a izraunava se po formuli: DRE=TDCT/TDFT*100 gde je: TDCT - ukupno zatvorenih defekata tokom testiranja, a TDFT- ukupno defekata naenih tokom testiranja. Model trokova kvaliteta, obezbeuje metodologiju z klsifikciju trokova veznih z osigurnje kvlitet proizvod s ekonomskog spekt. Rzvijen je tko d odgovr zahtevanom kvlitetu u proizvodnoj orgnizciji te je model od velikog znaaja u praksi. Iz perspektive programera, postoje dva tipa koristi koje se mogu ostvariti implementacijom dobre prakse izrade kvalitetnog softvera i alata: novac i vreme. Finansijski
[76]
ROI traga za utedama u trokovima, vremenski ROI za utedama u rasporedu (vremenu). Direktni finansijski ROI je izraen u vidu napora, obzirom da je ovo najvei troak u projektu softvera. Postoji nekoliko razliitih modela koji mogu biti upotrebljeni za ocenu finansijkog ROI za kvalitet softvera. Prvi je, najee korieni ROI model. Pokazaemo da ovaj model nije adekvatan, zato to ne obraunava tano koristi ulaganja u softverskim projektima. Ovo ne znai da je model nekoristan (na primer, raunovoe sa kojima smo razgovarali preferiraju tradicionalni ROI model), samo to ga mi neemo primeniti u naim kalkulacijama. Metod povratka investicija (ROI) ukljuuje koristi, trokove, odnos koristi/trokovi, neto sadanju vrednost i prelomnu taku. To je predstavljeno na Sl. 5. ROI metode su, uopteno posmatrano, sasvim lake, neophodne, snano pojednostavljene i apsolutno neophodne u polju procesa softverskog poboljanja (SPI). Ironija je da ROI metode nisu deo uobiajene prakse.
[77]
9 Pregled konkurentskih reenja

9.1 Mosaic-ov MSTAR paket za testiranje Mosaic-ova10 metodologija testiranja se dokazala kao veoma pouzdana na mainframe, klijent-server, PC i Web sistemima, a primenjiva je i na proizvoljne sisteme, sisteme zasnovane na paketima kao i za out-source razvoj. U bazu znanja zasnovanu na internetu , Mstar inkorporira opirna uputstva, primere i gotove templejte za implementaciju proverenog procesa testiranja u format pogodan za itanje. Mosaicova metodologija testiranja, MSTAR vodi rauna i na visoku cenu testiranja i na rizik proizvodne greke sa procesom baziranim na riziku koji istie i testiranja i podatke dobijene testiranjem. MSTAR unapreuje efikasnost testiranja i maksimizuje sposobnost tima da identifikuje mane dovoljno rano da ne bi postale proizvodne greke. MSTAR takoe obezbeuje vrst temelj za automatsko testiranje- ukljuujui testiranje prerformansi.Automatsko testiranje je integrisani deo MSTAR-a. Kako MSTAR nije alat za automatsko testiranje, on upotpunjuje alat za automatsko testiranje sa procesom i arhitektonskim komponentama koje prevazilaze mnoge od tradicionalnih problema sa automatskim testiranjem, omoguavajui potpunu korist automatizovanih alata.
Slika 9-1 Izgled MSTAR reenja
10
http://www.mosaicinc.com/mosaicinc/mstar.asp [78]
Mozaik moe dati pojedinane specijaliste za testiranje da dopuni Va tim test ili da daju ceo tim koji bi preuzeo odgovornost za funkcionalno i/ili testiranje kritinih performansi vaeg projekta. Tipina angaovanja ukljuuju:
9.1.1
Testiranje sistema: Razvoj i testiranje sistema, zatim izrada planova za upravljanje rizikom koji moe dovesti do neuspeha. Testiranje: Razvoj i izvravanje testa planira da obezbedi sisteme koji bi ispunili zahteve performansi. Automatizacija testiranja: Iskoristiti isplativa automatizovana reenja za smanjenje trokova i rizika od nastanka problema. Test prihvatljivsoti: Rad sa korisnicima kojim bi se definisalo i izvrilo testiranje prihvatanja sistema kako bi se obezbedilo da poslovne potrebe korisnika budu ispunjene. Unapreenje procesa Testiranja / Menadmenta: Definisanje, implementacija i upravljanje testom u okruenju.
Kljune karakteristike MSTAR paketa
MSTAR je vitalni alat za sve lanove projektnog tima vezane za testiranje: Programere odgovorne za testiranje delova softvera Testere sistema odgovorne za verifikaciju integrisanog sistema Testere performansi odgovorne za verifikaciju performansi sistema Inenjere ija je dunost automatizacija procesa testiranja Korisnike odgovorne za krajnje testiranje
Poboljava efikasnost testiranja i poveava mogunost tima testiranja da se identifikuju nedostaci dovoljno rano tako da ne postanu propust prilikom izrade. MStar takoe obezbeuje solidnu osnovu za automatizaciju testiranja - ukljuujui i testiranje performansi. Korisnici mogu da pristupe smernicama i uzorcima za pravljenje ija se strategija nalazi u glavnoj MStar bazi. Alternativno, korisnici mogu da pristupe projektu za isporuku da bi pronali planove, standarde, zahteve i skripte u vezi sa njihovim specifinim projektom. Ovo obezbeuje centralizovano mesto za pristup svim testiranjima.
[79]

9.1.2 Poreenje sa OQT BOX-om
MStar je proizvod koji ima dobar pristup testiranju i Optimal SQM e imati dosta slinosti sa njim u pogledu svih prednosti koje on poseduje, ukljuujii i poboljanje nekih modula. MStar ima dobar koncept i ozbiljan pristup zahtevima testa, kao i njihovoj proceni.
Slika 9-2 Logika MSTAR-a Glavni problem MSTAR-a je to on koristi klasini vodopadni model. Taj se model pokazao kao vrlo neozbiljan kandidat kada su u pitanju srednji i veoma komplikovani projekti. Tako da, za praenje i realizaciju takvih projekata mora da se omogui mnogo bolja kontrola ulaznih i izlaznih podataka. Takoe problem sa mosaicom predstavlja i samo testiranje koje uopte ne postoji u fazi prikupljanja zahteva ili dizajna.
[80]
9.2 HP Quality Management solutions (HP ALM,HP Quality Center, HP QuickTest) HP Application Lifecycle Management (ALM) zadovoljava potrebe moderne primene ivotnog ciklusa softvera pruanjem jednake vanosti uloga svih timova, ukljuujui integraciju izmeu strategije i planiranja zadataka koje e obavljati timovi, te time stvara dobru praksu podsticanja inovacija i spreavanja taktikih odlaganja, i predstavlja most ka poslednjim koracima organizacije poslovanja. [14] HP Application Lifecycle Management je jedinstvena platforma dizajnirana da savlada ivotni ciklus softvera od poetka do kraja. Arhitektura HP Application Lifecycle Management se sastoji od sledeih fukcionalnih i taaka integracije: Upravljanje ivotnim ciklusom aplikacije Praenje i planiranje projekta Poduhvati za upravljanje razliitim izdanjima softvera Zahtevi Definisanje zahteva - HP ALM and HP Quality Center Upravljanje zahtevima - HP ALM and HP Quality Center Upravljanje razvojem Razvojna integracija Razliite platforme i proizvodi ukljuujui i Source Control Management i Integrisano razvojno o u nj (Integrated Development Environment - IDE) kao to su: Eclipse, Microsoft Visual Studio, i Collabnet. Upravljanje grekama - HP ALM and HP Quality Center Sigurnost u razvoju Fortify SCA (deo HP softvera) Upravljanje kvalitetom Funkcionalnost HP Quality Center i HP Unified Functional Testing (UFT) Performanse - HP Performance Center i LoadRunner Sigurnost - HP QA Inspect i HP Web Inspect Primena ivotnog ciklusa - HP ALM Proces praenja Proces standardizacije Izvetavanje Fleksibilnost Set ALM ponuda iz HP-a sa lakoom se integrie i sa levom i desom stranom ALM jednaine. Sa leve strane ALM jednaine, HP ALM se integrie sa strategijom i planiranjem timova i HP setom upravljanja projektima i upravljanja ponudama. Sa desne strane ALM jednaine, HP ALM se integrie sa operacionim timom, i u HP ponude za upravljanje performansama palikacije i ITSM.
[81]
Slika 9-3 HP ALM prati ivotni ciklus od poetka do kraja [14]
Uloge HP ALM HP ALM nudi reenja ivotnog ciklusa softvera za irok spektar zainteresovanih strana (klijanata): Zamenik pedsednika projekta Poslovni analitiar Razvojni direktor Direktor za obezbeivanje kvaliteta HP ALM nudi jedinstvenu platformu i kljune karakteristike za ivotne cikluse softvera svih klijenata. Unakrsno planiranje i praenje Deljenje sredstava i ponovna upotreba Podrka za vie razliitih pristupa procesima Praenje Podrku za integrisani razvoj zadataka Upravljanje i planiranje kvaliteta Manuelno i automatsko testiranje HP protoni model za upravljanje kvalitetom softvera sadri korisniki pogled, vrednosne propozicije, korisnike ROI scenarije, korisnike podatke. (Slika 9-4).
[82]
Slika 9-4 HP protoni model za upravljanje kvalitetom softvera
HP ALM sa svojim osnovnim funkcionalnostima i integracijom predstavlja jedno od boljihALM reenja na tritu za arhitekturu i planiranje softvera. Nedostaci HP ALM Nedostatak znaajne integracije sa ostalim reenjima za upravljanje projektima koja postoje na tritu Nedostatak virtuelne laboratorije (showroom) koja bi bila sredite za upravljanje ivotnim ciklusom softvera i koja bi virtualno povezala klijente sa ponuenim reenjima. HP nudi showroom preko svojih partnera, kompanija Citrix, Quest, i Vmware.
Prednosti HP ALM
9.2.1
Platformski neutralan Procesno neutralan Otvorena API podrka Proiriv i dinamian spraman da se prilagodi dinamici ivotnog ciklusa Zajednika platforma za sva HP reenja Jednostavna integracija sa bilo kojim softverskim reenjem open source ili koji je u vlasnitvu neke kompanije Postepen prelazak kroz ivotni ciklus iz bilo kog HP reenja Kompletan pristup ivotnom ciklusu i reenje Bezbednost tokom razvoja i testiranja
Korist primenom HP ALM
Du opstanak na t tu postie se primenom HP ALM u planiranju projekata i praenju. Mogunosti ukljuuju definisanje i praenje odrednica projekta,
[83]
dinaminu procenu zdravlja sistema, kao i automatsko auriranje projekta u odnosu na odrednice. Dostavljanje podataka t no na vreme postie se primenom HP ALM unakrsnog izvetavanja o projektu. Mogunosti ukljuuju prilagodljivu vidljivost projekta, analize trendova i uvida, kontrolne table, objedinjenih podataka i metrike za kvalitet, pokrivenost poetnih zahteva projekta, i aktuelne nedostatke. Smanjena dorada postie se primenom HP ALM sredstava za deljenje i ponovnu upotrebu. Mogunosti ukljuuju centralizovane biblioteke za upravljanje zahtevima, skripte za testiranje, resurse za testiranje, upravljanje promenama i konfiguracijama, kaoiodravanje praenih deljenih resursa, ukljuujui mogunostpraenja istorije izvrenja resursa koji se testiraju. Dobra primena u poslovnoj upotrebi postie se primenom HP ALM procesa standardizacije. Mogunosti ukljuuju definisanje ivotnog ciklusa standardizovanih procesa, izvrenja u skaldu sa najboljom praksom, centralizovano prilagoavanje projektnih predloaka (templates), i automatsko auriranje projekta u toku vremena. P on l nj najbolje metodologije pristupa omoguuje se kroz HP ALM multimetodoloku podrku procesa sa HP Agyle Accelerator. Mogunosti ukljuuju snimanje i praenje korisnike upotrebe kroz razvojne zadatke, testiranje nedostataka, praenje i upravljanje projektnih odrednica. Po za t n veze zm u poslovnih potreba i primena softvera omoguuje se kroz HP ALM praenje i analizu zahteva. Mogunosti ukljuuju Bussines Process Modeling (BPM), praenje odnosa izmeu dva procesa, kretanje procesa, greke i testiranje, i povezivanje zahteva sa testerskim zahtevima. Razvojna efikasnost i v kvalitet isporuke omoguuje se kroz HP ALM praenje i deljenje greaka. Mogunosti ukljuuju konzistentan proces upravljanja preko projekata, zbirne metrike nedostataka preko projekata (baza centralnih nedostataka), merenje i izvetavanje o unakrsnim projektnim grekama, praenje greaka u testiraju i zahtevima. U l v nj kvaliteta rada sa poslovnim ishodom omoguuje se kroz HP ALM upravljanje kvalitetom. Mogunosti ukljuuju procenu i suklaivanje zahteva visokog rizika, automatsko izraunavanje i fino podeavanje testiranja. Zadovoljavanje poslovnih o v nj kroz performanse, funkcionalnost i bezbednost omoguuje se kroz HP ALM kompletno planiranje testiranja. Mogunosti ukljuuju projektovanje, izgradnju, i manuelno i automatsko upravljanje testovima za funkcionalnost, performanse i bezbednost, koristei sluajeve testiranja iz Microsoft Word-a i Excel-a, obezbeujui pokrivenost kroz povezano praenje zahteva, upravljanje dopunama i izmenama zahteva.
[84]
Efikasnost manuelnog testiranja omoguuje se kroz HP Sprinter i integraciju sa HP ALM. Mogunosti ukljuuju testiranje procesa i automatsko beleenje rezultata u okviru HP ALM, trenutno oznaavanje i izvetavanje o nedostacima timovima za upravljanje kvalitetom i razvojnom timu, ubrzavajui izvrenje testiranja kroz automatizovano dostavljanje podataka, pojednostavljenje procesa testiranja sa prikazom i napomenom, i testiranje vie platformi jednim klikom preko HP Mirror Testing.
Dobiti primenom HP softvera se mogu videti na Slici 8-3, a dobiti na poslovnom planu na Slici 9-5 [15].
IT merne jedinice Efektivnost procesa za upravljanje kvalitetom Efektivnost procesa testiranja Kvalitet aplikacije
Koristi Bre, bolje
Vrednosna propozicija
Korisnici otkrivaju da automatizovanje kljunih procesa za upravljanje kvalitetom (upravljanje defektima, upravljanje testiranjem, osiguranje kvaliteta, upravljenje projektima) rezultira znaanim poboljanjima u: vremenu i uspenosti u planiranju testiranja, testiranju kroz nivoe i izvrenju, kao i globalnim kvalitetom celokupnog softvera. Korisnici otkrivaju da automatizovanjem ciklusi testiranja mogu biti izvreni 95% bre, to se ogleda u utedi na vremenu, trokovima i ljudima. Testirajui bre, korisnici mogu testirati razliite softvere u istim alatima, ili testirati isti softver bre. Ovo rezultira mogunou zavretka softvera bre i ee, sa boljim kvalitetom softvera, sa istim ili smanjenim trokovima. Korisnici otkrivaju da mogunost da planiraju i testiraju kljune procese testiranja na upravljan i automatizovan nain vodi ka broj identivikaciji veeg broja defekata, i boljem razumevanju stanja kvaliteta softvera. Ovo rezultira znaajnim poveanjem kvaliteta softvera. Korisnici otkrivaju da automatizovanje procesa validacije performansi i kapaciteta vodi ka boljoj identifikaciji problema koji mogu smanjiti performanse aplikacije ili usloviti poveanje vremena produkcije. Brim identifikovanjem vie ovih faktora, dobie se aplikacija sa boljim performansama za krae vreme. Upravljanje kvalitetom i testiranje su kritine komponente procesom upravljanja kvalitetom. Problemi u razumevanju stanja kvaliteta aplikacije i performansama su esti, i predstavljaju prepreke u razvoju softvera. Automatizovanjem ovih procesa, posao e biti zavren bre i efikasnije, rezultirajui brim kompletiranjem aplikacije i manjim bagovima u istoj. Korisnici otkrivaju da koristei HP reenja zani koristiti manje pomonih softvera prilikom izrade aplikacije. Manje je obraanja slubi za pomo, specijalistima za produkciju, a programeri imaju manje posla oko ispravljanja greaka i debugiranja. Ovo znai da se osoblje moe posvetiti radu na ostalim vanim projektima. Sa HP reenjima koja omoguavaju merenje i upravljanje procesima, korisnici otkrivaju da je lake postaviti zajednike ciljeve u poslovnim jedinicama koje podravaju. Rezultat se ogleda u manje provedenom vremenu u upravljanju zahtevima, testiranju korisnikog prihvatanja, i ispravci stvari koje nisu ispunile korisnika oekivanja, to omoguava timu da se posveti ostalim projektima.
Proizvodi HP Quality Center
Jo bolje, bre, jeftinije
HP QuickTest Pro, HP Quality Center, HP LoadRunner HP QuickTest Pro, HP Quality Center, HP LoadRunner HP LoadRunner
Bolje
Performanse aplikacije, dostupnost Upravljanje kvalitetom tima Upravljanje aplikacijom i podrka efektivnosti Biznis usklaivanje
Bolje, jeftinije
Bre
HP QuickTest Pro, HP Quality Center, HP LoadRunner HP QuickTest Pro, HP Quality Center, HP LoadRunner HP QuickTest Pro, HP Quality Center, HP LoadRunner
Jeftinije
Bre, jeftinije
Slika 9-5 Dobiti u IT industriji primenom razliitih HP reenja za upravljanje kvalitetom [15]
[85]

Poslovne merne jedinice Poslovni proces i produktinost zaposlenih Prihod Koristi Vrednosna propozicija
Bre, bolje, jeftinije
Poslovni proces sa boljim performansama i manji zastoj aplikacije znae da zaposleni mogu izvriti vie transakcija za manje vreme, to rezultira poslovnim dobicima kao to su smanjena cena plaanja zaposlenih, poboljan korisniki servis, i povean prihod. Aplikacije koje podravaju automatizovane poslovne procese su najee jezgro prihoda u kompaniji. Poveanjem kvaliteta, performansi i dostupnosti postiu se znaajne poslovne dobiti. Za aplikacije namenjene korisnicima, slabe performanse i zastoji aplikacije znae smanjenje prihoda i promeenu investiciju. Korisnici ele da poboljaju kvalitet, performanse i dostupnost, ime bi smanjili rizike u poslovanju. Svaki propust u aplikaciji moe kotati milione dolara u uloenom biznisu, produktivnosti zaposlenih i zadovoljstu korisnika. U nekim sluajevima, ovi izazovi dovode do materijalnog kolapsa kompanije i brisanjem sa trita. HP nudi reenja koja optimiziraju upravljanje kvalitetom, ime se smanjuje poslovni rizik. Kada god biznis zahteva primenu tehnologija ili poslovnih aplikacija, HP moe pomoi da se poboljaju koristi ulaganja u posao. Aplikacije koje su dostavljene na vreme vode ka brem ostvarenja koristi od istih, nego kada je aplikacija dostavljena sa zakanjenjem.
Vie, bre, jeftinije Bolje
Poslovni rizik
Oekivana poslovna vrednost
Vie
Slika 9-6 Dobiti u biznisu primenom razliitih HP reenja za upravljanje kvalitetom [15]
9.2.2
Razliiti scenariji u upotrebi HP softvera
Hipoteza Reenja i suma dobiti Softver Podaci, metrika i kalkulacioni primeri
Specifina izjava o vrednosti. Opis HP reenja koji ukazuje na izjavu o vrednosti, i kako se ona odnosi na vrednosni uspeh. Koje aplikacije je najbolje primeniti na ovaj scenario? Koja su bitna merenja koja treba sakupiti da bi se merila vrednost u ovom scenariju (na primer, broj ciklusa testiranja, uestalost ciklusa testiranja, broj testova po ciklusu ili broj testera)? Detaljnija izraunavanja u primeru ponekad pre i posle koja e demonstrirati kako pristupiti prevoenju vrednosti izjave + podataka korisnika u kvantifikovani ROI11.
Slika 9-7 Kljuni termini u scenarijima [15]
9.2.2.1
Scenario 1: Regresiono testiranje sa HP FunctionalTesting
Kompanija koja se bavi putnim servisima nudi tehnoloka reenja sektorima u oblasti putovanja kako bi kontrolisali trokove putovanja. Ovo je veoma konkurentno trite, uslovljeno kvalitetom usluga i tendencijom smanjenja ukupnih trokova. Shodno tome, ikustva korisnika, kvalitet proizvoda i trokova su od velikog znaaja. ROI scenario pokazuje kako automatizovano regresiono testiranje smanjuje duinu ciklusa testiranja za 60% i testiranje nivoa napora za 20% za samo jednu aplikaciju. [15]
11Return On Investment (ROI) metrika performansi koja se koristi za procenu efikasnosti investicija ili da se uporedi efikasnost vie razliitih ulaganja.
[86]
Hipoteza Reenja i suma dobiti
Softver ROI primer
Automatizacija test skripti u regresionom testiranju vodi ka smanjenju cene testiranja. HP Funcional Testing softver omoguuje automatizaciju funkcionalnog i regresionog testiranja podravajui brzu i fleksibilnu izradu aplikacija. Testovi koji su se ranije obavljali manuelno mogli su trajati satima ili danima, dok automatsko testiranje traje tek nekoliko mnuta ili sat vremena. Ovo rezultira mogunou da se obavi isti broj testova za krae vreme. Aplikacije namenjene agencijama za turizam.
Metrika Pre 100% manuelno testiranje = 110 35 3 75 3 225 8 1,350 $78 $105,300 12 $1,263,600 Posle 70% manuelno/30% automatizovano testiranje = 110 10 3 30 6 180 6 1,080 $78 $84,240 12 $1,010,880 $30,000 $222,720
Trajanje test ciklusa (dani) Broj test ciklusa po verziji Totalno utroeno vreme (dani) Testiranje nivoa napora (#FTE) Nivo napora (dani rada osoblja) Rad osoblja po danu Nivo napora (sati rada osoblja) Zarada po satu Trokovi po verziji Broj verzija u godini Godinji trokovi testiranja Trokovi pisanja test skripti UTEDA
60% bre
Slika 9-8 Automatizacija procesa testiranja rezultira poveanom IT produktivnou [15]

9.2.2.2 Scenario 2: Test optereenja i performansi sa HP LoadRunner
Zatita kompanije od gubitaka je postala vei izazov poveanjem IT kompleksnosti i poveanjem broja proizvoda i servisa. Shodno tome, kljuna stvar je da ako kompanija nudi kvalitetne aplikacije na trite, sa visokim performansama time smanjuje trokove izrade aplikacije. Koristei HP LoadRunner smanjuje se vreme koje kompanija potroi za dijagnostikovanje i reavanje problema za 63%. [15]
Hipoteza Testovi optereenja i performansi omoguavaju otkrivanje sistemskih i softverskih greaka pre nego se aplikacija pusti u izradu, jer bi u suprotnom ovakvi problemi poveali trokove dijagnostikovanja. HP LoadRunner omoguuje otkrivanje problema u testiranju, pre nego softver stigne do faze serijske proizvodnje i generalne upotrebe. Omo uslovljava smanjenje broja aplikacionih greaka, kao i vreme dijagnostikovanja problema, a time i poveava utedu novca. Integrisani poslovni sistem koji podrava otkrivanje greaka kroz ceo ivotni cikus softvera.
Metrika Broj ljudi u produkciji Proseka cena produkcije (po satu) Redukcija defekata kroz rigoroznije automatizovano testiranje (u %) Broj defekata u produkciji Redukcija u vremenu potrebnom za dijagnostikovanje ili reavanje problema Proseno vreme potrebno za dijagnostikovanje i reavanje problema (sati) Totalno vreme za dijagnostikovanje i reavanje problema (sati) Prosean broj osblja koji radi na jednom problemu Trokovi za dijagnostikovanje i reavanje problema po osobi (sati) Totalni trokovi za dijagnostikovanje i reavanje problema UTEDA Pretpostavka 5 $41 50% 162 25% 12 1944 2 $79,704 $159,408 9 729 2 $59,788 $59,788 $99,630 Problemi reeni 81 Pre Posle
Reenja i suma dobiti
Softver ROI primer
63% bre
Slika 9-9 Poveanje kvaliteta u IT produktivnosti [15]

[87]

9.2.2.3 Scenario 3: Uteda kapitala sa HP LoadRunner
Kompanija koja se bavi distribucijom gasa i hemikalija i forsira filozotiju jedna kompanija revidirala je svoj model poslovanja reila da otui one poslovne modele koji nisu usklaeni sa rastom trita. Kao deo strategije, kompanija je napravila vea ulaganja u tehnoloke inovacije u modele poslovanja, kao na primer implementaciju SAP. Koristei HP LoadRunner simulirae 60% proizvodnih transakcija po zapremini, tim za upravljanje kvalitetom je potvrdio smanjenje trokova. Rezultat je oekivana uteda, koja prevazilazi $5.000.000. [15]
Hipoteza Reenja i suma dobiti Poboljanjem performansi aplikacije tokom testiranja i performansi optimizacije smanjuju se zahtevi za dodavanjem infrastrukturnih kapaciteta. HP LoadRunner pomae u predvianju, validaciji i optimizaciji sistemskih performansi da bi se optimizovali infrastrukturni resursi a to dalje vodi ka smanjenju trokova ulaganja. Ovo takoe pomae kompaniji da odrava svoju filozofiju jedna kompanija i onoguuje konzistenciju poslovnih procesa kroz organizaciju. SAP testovi optereenja i performansi validiraju dizajn sa jednom instancom eliminiu potrebu za drugom instancom SAP u Evropi. Cena druge instance SAP = $3-5 miliona (obuhvena cena trokova druge instance mora biti najmanje kao i cena trenutnog SAP okruenja za oporavak od kolapsa) Dolja granica: uteda = $5 miliona (druga instanca bi zahtevala vee kapacitete za podrku poslovnog procesa)
Uteda $5.000.000
Softver ROI primer
Slika 9-10 Poveanje performansi i smanjenje trokova [15]

9.2.2.4 Scenario 4: HP Quality Centerekonomija konsolidovanja i centralizacije
Ciljevi wireless komunikacije su u skladu konsolidacije biznis ciljeva, kontrole trokova i poveanja kvaliteta biznis procesa. Servisi testiranja koriste HP softvere za upravljanje kvalitetom kako bi usavrili biznis procese. Kao rezultat, kompanija smanjuje trokove kroz centralizovane servise testiranja. Primer kompanije koja eliminie 19 servera i ini utedu od preko $900,000. [15]
Hipoteza Reenja i suma dobiti Softver ROI primer Centralizovana QA maksimizuje vrednost investicija u licenciranju i hardverskoj infrastrukturi, rezultirajui znaajnom utedom. HP Quality Center softver centralizuje upravljanje kvalitetom softvera. Centralizacija QA eliminie potrebu upotrebe novih resursa i servera. Svi softveri.
Metrika Godinja diskontna stopa Broj servera eliminisanih primenom centralizovane QA Godinji trokovi posedovanja jednog NT servera Totalni trokovi posedovanja NT servera Godina 1 3% 19 $15,946 $302,000 Godina 2 3% 19 $15,946 $302,000 Godina 3 3% 19 $15,946 $302,000 Uteda $900.000
Slika 9-11 Rezultati centralizacije i potranje u IT okruenju poboljane efikasnisti
[88]

9.2.3
9.2.3.1
Poslovni scenariji u upotrebi HP softvera

Scenario 1: Zatita prihoda
Preko $2.000.000.000 prihoda ubira hemijska kompanija svake godine. Kompanija i IT su investirali u rigorozne BTO prakse i tehnologije kako bi smanjili potencijalne slabe take koje bi dovele do gubitka prihoda. ROI scenario opisuje uticaj HP proizvoda na smanjenje gubitka u poslovanju. Rezultat je preko $400,000 zatite prihoda svake godine. [15]
Hipoteza Reenja i suma dobiti
Softver ROI primer
Potekoe u biznis procesu i ostvarenju godinjih prihoda rezultiraju smanjenjem produktivnosti. Smanjenjem defekata u aplikacijama koje kontroliu ovo moemo zatititi i osigurati prihode. Efektivna praksa testiranja tokom osiguranja kvaliteta vodi ka smanjenju kritinih defekata u produkciji. HP Functional Testing, HP LoadRunner i HP Quality Center pomau u poboljpanju biznis procesa. Ovo se postie automatizacijom testiranja. SAP
Metrika Godinji prihod upravljan SAP-om Dani u godini Sati u danu Prihod po satu Prosean prekid rada (sati) Oekivani procenat smanjenja incidenata korienjem automatizovanog testiranja Oekivani broj prekida rada po mesecu Gubitak rizika po mesecu Gubitak po godini UTEDA Pretpostavka $2,200,000,000 360 16 $381,900 1 50% Pre Posle
162 12 2 $763,889 $9,166,667
81 9 1 $381,900 $4,583,333 $458,000 $458,000 uteda
Slika 9-12 Automatizovani rezultati testiranja u slubi zatite prihoda

9.2.3.2 Scenario 2: Smanjenje rizika od naputanja korisnika
U borbi za poziciju na tritu, smanjenje cena nije dovoljno za turistiku agenciju. Ona se mora takoe zatititi od gubitka muterija. Kako bi sprovela ciljeve aurnosti i funkcionalnosti, automatizovanje testiranja njihovog softvera e ubrzati njihovo pojavljivanje i opstanak na tritu punom konkurencije. U ovom ROI scenariju, kompanija analizira uticaj naputanja pojedinih korisnika i njihovu povezanost sa prihodima. [15]
Hipoteza Reenja i suma dobiti Automatizacija testiranja omoguuje meseno napredovanje. HP softver podrava brz, fleksibilan development aplikacija usmeravajui testiranje i development ovih aplikacija u pravom smeru, istovremeno doputajui organizacijama da smanej ratu koju plaaju njihove muterije. Softver za turistike agencije.
Metrika Meseni prihod Broj aktivnih muterija Stopa osipanja na tromeseju i meseno Izgubljen prihod po mesecu Godinji izgubljen prihod Pretpostavka $360,000 140 5% $18,000 $216,00 10% $36,000 $432,000 $864,000 zatieno 20% $72,000 $864,000 Scenariji zatite prihoda
Softver ROI primer
Slika 9-13 Automatizacija testiranja i kontrole kvaliteta poveava prihod

[89]

9.2.4 HP QuickTest Professional (QTP)
Quick Test Professional je HP softver za funkcionalno testiranje softvera. To je alat koji ima odlian GUI, baziran na ikonicama. Omoguuje i regresiono testiranje softvera. Lak je za korienje, bilo da ga koriste profesionalni ili amaterski testeri, to nije sluaj sa ostalim softverima raznih proizvoaa a koji imaju istu namenu. Jezik koji koristi je VBScript, koji se lako ui i implementira, razumljiv je, njegov kod je lako implementirati ak i u kompleksim sluajevima testiranja Koristi Active Screen tehnologiju za uvanje skripti koja omoguuje korisniku da prati tok testiranja. Biblioteka sadri VBScript funkcije i rutine koje mogu biti dodate prilikom testiranja Podrava modern development okruenje [16]
Podrana okruenja su: Osnovne Web tehnologije HTML DHTML XML Internet pretraivai Netscape Internet Explorer AOL Napredne Web tehnologije JavaScript Java ActiveX Multimedijalne tehnologije Flash RealAudio/Real Video MS Media Player ERP Reenja mySAP.com Siebel 2001 Oracle PeopleSoft .NET Win Forms Web Forms NET Control Web Services XML WSDL Okruenja koja ne pdrava su [16]: PowerBuilder
[90]
Forte Delphi Centura Stingray SmallTalk ERP/CRM Baan PeopleSoft Windows Siebel 5, 6 GUI Clients Oracle GUI Forms
Glavni meni Paleta alatki
Test panel
Objekt
Prikaz akcija
Slika 9-14 Izgled glavnog ekrana HP QTP [16] Vanije palete alatki: Test toolbar: sadri dugmie koji su bitni tokom testiranja Debug toolbar:sadri dugmie za sistiranje totkom debagovanja Action toolbar:sadri dugmie i liste akcija, koje omoguuju pregled detalja svakog testa ponaosobili kompletnog ciklusa Test pane: sadri dva prikaza testa prikaz po kljunoj rei i ekspertski Test Details pane : sadri aktivni prikaz akcija Data Table:sadri dva ili vie tabova koji asistiraju u parametarizaciji testa globalni tab i akcioni tab [16]
[91]
HTML kod za dugme CALCULATE
<INPUT id=button1 type=button value=Calculate name= button1 title="" LANGUAGE=javascript onclick="return button1_onclick()">
Slika 9-15 Moete pozvati dugme pod imenom button ali QTP ga prepoznaje pod imenom Calculate [16]
Da bi se kreirao i pokrenuo test, treba pratiti sledee korake: 1 Otvoriti Quick Test. 2 Otvaranje testa [16]: Da bi se kreirao novi test, treba kliknuti na New Da bi se otvorio postojei test, treba kliknuti na Open 3 Da bi se izvrilo snimanje po prvi put, treba otvoriti dijalog Record and Run Settings
[92]
Slika 9-16 Pokretanje novog testa
Naravno, QTP dozvoljava i ekspertski pogled, to moemo videti na slici 9-17:
Eksperti koriste VBScript
Slika 9-17 Ekspertski pogled u QTP
[93]
Checkpoint test nije proao
Checkpoint test je proao
Slika 9-18 Analiziranje testa pomou checkpoint-a
Stablo rezultata testa
Detaljni rezultati testa
Sumiranje rezultata testa
Slika 9-19 Prozor koji prikazuje rezultate testiranja
[94]
9.3 QSM SLIM QSM nudi vie usluga i paketa, ali za nas je nainteresantniji SLIM paket jer je on u nekom pogledu konkurent naem Optimal SQM-u. On se sastoji od 5 paketa: SLIM- Estimate SLIM- Control SLIM- Metrics SLIM- EstimateExpress SLIM- Data manager Slino naem Optimal SQM-u i oni su u neku ruku komplementarni. Svaki je zaduen za neke oblasti razvoja softvera. U sutini, QSM SLIM omoguava sledee stvari:
9.3.1
Planiranje, praenje i uspeno realizovanje softverskih projekata Merenje efikasnosti softverske kompanije kao i softvera koji proizvode Optimizacija produktivnosti unutar kruga oblasti u kojima kreiraju softverske proizvode
SLIM Estimate
SLIM Estimate pomae u proceni vremena, napora i trokova koje moraju da zadovolje i daju skup zahteva i da odrede najbolju strategiju za projektovanje i implemetaciju softvera ili sistema projekta. Pored razvoja softvera, klijenti mogu da koriste alate za vie prejektovanje procesa ukljuujui razvoj, hardver, infrastrukturu, model zasnovan na razvoju, ininjering i arhitekturu, servisno orijentisana arhitekturu, centar razvoja i jo mnogo toga. SLIM Estimate je paket koji nudi razliite metode na dohvat ruke, za razliku od drugih paketa jedna veliina odgovara svim alatima. SLIM Estimate moe da bude kao to je prikazano na slici ili onako kako vi elite da ih napravi. Ponekad se mora odgovoriti na pitanja sa ogranienim informacijama u toku samog rada. SLIM Estimate nudi i arobnjaka koji nudi brze odgovore na uobiajena pitanja sa minimalnim unosom.
[95]
Slika 9-20 Slim-Estimate SLIM Estimate se isporuuje sa pet veliina tehnike i selekcijom MS Excel modela koji moete da prilagodite tako da odgovara svojim razvojnim procesima. Kada se jednom unes nekoliko pretpostavki i ogranienja za upravljanje SLIM Estimate je spreman za izraunavanje reenja. Ako su raspored, osoblje, trokovi, pouzdanost ili ogranienja tanki SLIM Estimate ima automatsko reenje koje pronalazi alternative, to se moe opisati kao da se ima sopstveno ugraen consultant po pozivu. Kada se jednom kreira i prijavi nekoliko reenja, potreban je praktian nain da se proceni i izabere najbolji plan.
9.3.2
SLIM Control
SLIM Control sadri statiki kontrolni proces tehnike koji je potreban da se proceni stanje projekta (tj. da se uporedi plan projekta sa stvarnim projektom i generisanje zavrnog projekta). SLIM Control nudi ugraene i korisniki definisane metrike, kao i ostvarene vrednosti grafikona i izvetaja. SLIM Control je integrisan sa ostalim paketima SLIM-a. Planovi koji su kreirani u SLIM Estimate ili u SLIM DataManager treba uneti runo ili isei i nalepiti iz Excel-a direktno. Primer SLIM Control je prikazan u slici ispod
[96]
Slika 9-21 Slim- Control

9.3.3 SLIM Metric
SLIM Metricsradi sa SLIM DataManager podacima iz skladinih alata koja prua ouvanje istorije projekta, vri procenu konkurentske pozicije, identifikuje prepreke, kvantifikuje korist od procesa poboljanja i brani budue procene projekta. SLIM DataMenager je alat za smetanje podataka koji je ukljuen u SLIM Metrics, i oni zajedno kreiraju komporativnu bazu podataka za kompletne projekte. Ta baza podataka se moe iskoristiti za analizu podataka i otrkivanje kljunih odnosa i najnovijih trendova.
[97]
Slika 9-22 Slim-Metrics SLIM Metrics daje mogunost da se: Kreiraju i uporeuju podaci podgrupe Kreiraju neogranieni grafikoni ili izvetaji Koriste trenutni standardi industrije Upotrebljavaju alati za statiku analizu Pogledaju detalji za bilo koju taku podataka Dodaju prilagoene beleke i druge funkcije Urade vrhunski grafikoni i tabele Da se exportuju podaci veoma lako
SLIM EstimateExpress

9.3.4
SLIM EstimateExpress je softver QSM paketa za procenu alata za organizaciju sa manjim zahtevima procene. EstimateExpress precizno izraunava cenu, rasporede, pouzdanost i sredstva za velike i male softverske projekte, a uz sve to prua mogunost da se pregovara i planira vii scenario projekta. Uz podrku QSM-a Express je veoma dobar izbor za razvoj softvera koji ne zahteva reenje preduzea.
[98]
Slika 9-23 Slim- Estimate Express Na osnovu svega dosad reenog moemo zakljuiti da je cilj QSM da prui sveobuhvatno reenje koje e pomoi da se sprovede projekat od planiranja projekta pa sve do zavretka projekta kao to i predstavlja cilj naeg reenja tj. Optimal SQM-a, i po tom pitanju moemo reci da imamo dosta slinosti ali da se odreeni paketi razlikuju. SLIM vri oko 80% simulacije, a to predstavlja samo jedan od paketa naeg reenja. U odnosu na na paket OPST nema puno dodirnih taaka i mislim da to predstavlja glavnu manu ovog SLIM reenja.
9.3.5 Poreenje sa OQT BOX-om
U pogledu testiranja kao to sami vidite iz izloenog Putnamov SLIM uopte ne pridaje veliku panju. Nemaju pojedinaan modul koji je zaduen za testiranje. ak tavie ne omoguava testiranje ni u okviru jednog od njegovih paketa i usluga, tako da je to veliki nedostatak ovog softverskog paketa. Stoga, Putnamov SLIM uopte nije konkurentan Optimal SQM-u u smislu testiranja jer je Optimal SQM obratio veliku panju na testiranje i omoguava razne vrste testiranja kao i simuliranje testiranja i uzima ga kao vaan parametar pri raznim estimacijama. Samim tim dolazimo do zakljuka da su sumnjive i estimacije koje dolaze iz ovog proizvoda koji ne rauna uopte trokove vezane za testiranje softvera.
[99]
10 Arhitektura sistema Optimal SQM

Ako elimo da stvorimo uspean sloeni (Enterprise) softverski sistem, moramo imati itav niz slika u svom umu, slika budueg sistema iz mnogo razliitih perspektiva. Moramo nai nain da te slike dobiju stvaran oblik, vidljiv i razumljiv drugim ljudima, jer sloeni (Enterprise) sistem ne moemo stvoriti sami. Realizacija sloenih softverskih sistema je sinergija razliitih znanja i iskustava i kompromis izmeu razliitih miljenja i pristupa istom problemu. Jer ne postoji samo jedno reenje za sve probleme i sve softverske sisteme. Ako elimo da stvorimo uspean sloeni (Enterprise) softverski sistem kao to je na OptimalSQM, moramo imati snanu platformu za razvoj, moramo potovati minuli rad i iskustva naih prethodnika, ali istovremeno biti otvoreni za nova iskustva i dolazee tehnologije. etiri najvanija faktora softverskih arhitektura su: Arhitekturalni stil. Konkretna arhitektura iz skupa koji je definisan arhitekturalnim stilom. Komponente i interfejsi. Podsistemi razliitog skupa komponenti. 10.1 Verifikacija i validacija softverske arhitekture Jedan od ciljeva naeg projekta predstavlja i odabir odgovarajue arhitekture koja e omoguiti implementaciju jednog ovako kompleksnog sistema kao to je Optimal SQM. U prethodnom poglavlju smo sagledali mogue arhitekture koje imaju potencijala da budu na izbor po pitanju arhitekture radi implementacija Optimal SQM-a. Dakle, opcije su bile sledee: Klijent-server Corba SOA U narednom delu cilj nam je da objektivno pokuamo da damo odgovor koja je arhitektura najbolja i koja odgovara realizaciji projekta Optimal SQM. Dakle, kao to smo ranije istakli, ovaj projekat bi mogao da se implementira sa navedene tri arhitekture. Klijent-server arhitektura je vrlo pogodna pri realizaciji projekata koji isto imaju takvu organizaciju tj. imaju klijenta i servera koji klijenta usluuje svojim uslugama. Vrlo esto se tu umetne i srednji sloj pa onda korisnik ne mora sve zahteve da alje direktno serveru ve i taj meusloj( middleware) obradi upit i da rezultat klijentu. Super to zvui, ali onda kada pogledamo tu celu kompleksu strukturu ovog sistema pod nazivom Optimal SQM vidimo koliko je ustvari teko to realizovati ovom arhitekturom, jer bi taj na meusloj trebao biti poprilino debeo da bi uopte mogla ovakva organizacija da se odri. Podseam vas da imamo 5 velikih podsistema unutur ovog velikog sistema, a unutar tih podsistema jo puno velikih, monih modula koji implementiraju razne usluge za klijenta. U tom sluaju shvatamo da klijent- server arhitektura je potpuno neprihvatljiva. Zatim na scenu stupa Corba arhitektura. Ona je takoe interesantno reenje, jer Corba je poznata po tome da je vrlo dobro razvila aplikacioni sloj tj. omoguava komunikaciju totalno razliitog hardvera i potpuno razliitih softvera u pogledu programskih jezika. Ali, naalost ni to nije dovoljno da ona bude prvi izbor, jer je ona ipak zasnovana na klijent-server arhitekturi na neki nain.
[100]
Onda nam na kraju preostaje reenje SOA, odnosno servisno orjentisana arhitektura. Ona je pravi izbor za ovaj na kompleksni sistem iz vie razloga: 1. Podrava funkcionalnu podelu Optimal SQM-a na najbolji mogui nain, tj. omoguava realizaciju naih 5 modula kroz web servise 2. Omoguava potpunu nezavisnost modula sistema i u hardverskom i softverskom pogledu jer se oni implementiraju kao web servisi. 3. Podravaju i funkcionalnu podelu unutar tih velikih web servisa jer u sutini i ti elementi unutar velikih modula su ponovo neki web servisi tako da je potpuno olakana njihova implementacija. 4. Najbolja komunikacija meu modulima, jer mi sami implementiramo nain njihove komunikacije.
10.1.1 Optimal SQM CORBA Arhitektura
Postavlja se pitanje, kako bi izgledao Optimal SQM ukoliko bi bio izgraen u CORBA arhitekturi. Savremene telekomunikacione mree i servisi, koji su predmet upravljanja, dobijaju sve sloeniju strukturu, njihova kompleksnost i heterogenost rastu, to takoe otvara potrebu za primjenom distribuiranih tehnika upravljanja. Istorijski gledano, poto u informacionim tehnologijama (IT) nije postojala opte prihvaena infrastruktura distribuirane obrade adekvatna zadatku upravljanja telekomunikacijama, razvijeno je vie proizvoakih infrastruktura. Prve realizacije mrea za upravljanje telekomunikacijama su bile bazirane na telemetrijskoj paradigmi, po kojoj elementi mree alju kontinualni tok nezavisnih notifikacija centralnoj nadzornoj jedinici. Kasnije tehnologije, kao to su SNMP (Simple Network Management Protocol) i CMISE (Common Management Information Service Element) koriste menader/agent paradigmu koja uvodi mogunost udaljene inteligencije i sposobnost interakcije i iniciranja operacija od strane centralnog prema udaljenom sistemu. Dananja IT industrija razvija tehnologiju distribuiranog procesiranja baziranu na distribuiranim objektima, pa industrija upravljanja telekomunikacijama migrira ka paradigmi distribuirane obrade sa ciljem da se smanje ukupni trokovi i unaprijede mogunosti odravanja. Ovakva orijentacija je rezultat procesa logike i fizike decentralizacije kroz koji prolaze telekomunikacione mree, posebno sa uvoenjem inteligentnih mrea (IN) i distribuiranja inteligencije u okviru mree. [17] Zastupljenost hardverske mrene opreme i softvera koji potiu od vie razliitih proizvoaa takoe doprinosi distribuiranosti i heterogenosti, to namee potrebu uvoenja distribuiranog okruenja koji bi povezao razliite distribuirane elemente mree i omoguio njihov meusobni rad. To dovodi i do uvoenja tehnologije distribuiranih obrada informacija u oblast mrea za upravljanje telekomunikacijama. Savremene telekomunikacione mree i servisi, koji su predmet upravljanja, dobijaju sve sloeniju strukturu, njihova kompleksnost i heterogenost rastu, to takoe otvara potrebu za primjenom distribuiranih tehnika upravljanja. Novi uslovi diktirani pojavom konkurencije u telekomunikacionom sektoru nameu jaku potrebu za smanjenjem trokova i organizacijom poslovnih procesa kojima se skrauje vrijeme izlaska proizvoda-servisa na trite. U tom svjetlu su mogunost meusobnog rada, postepeni rast prema potrebi i viestruko koritenje, glavne karakteristike koje savremeni sistemi za upravljanje moraju da ispune. Primena distribuirane klijent-server arhitekture na Optimal SQM, zastupljene u raunarskoj industriji, koja je ve raspoloiva i spremna za upotrebu, smanjuje trokove razvoja i
[101]
odravanja, to predstavlja znaajan razlog za uvoenje principa distribuiranih tehnika i u mree za upravljanje telekomunikacijama. Arhitektura OMA (eng. Object Management Architecture) definie modele distribuiranih objekata i njihove interakcije u platformski nezavisnim okruenjima. OMA se sastoji od modela objekata (eng. object model) i modela referenci (eng. reference model). Model objekata propisuje kako objekti distribuirani u heterogenom okruenju mogu biti opisani, dok model referenci opisuje meudjelovanje tih objekata. U modelu OMA objekt posjeduje nepromjenljiv identitet ije usluge mogu biti koritene samo putem vrsto definiranih suelja. Korisnici izdaju zahtjeve objektima u svrhu obavljanja usluga. Implementacija i lokacija pojedinog objekta nisu dostupni klijentu. Najpre, moramo navesti nekoliko nedostataka koje bi neminovno imao Optimal SQM ukoliko bi bio izgraen u CORBA arhitekturi. Prilikom opisa nedostataka, u prvi plan izbija snana zavisnost o performansama komunikacijskog kanala, a koja se oitava u brzini i dostupnosti delova sistema: brzina komunikacije izmeu dva raunara za otprilike dva reda veliine sporija je od komunikacije unutar sistema (komunikacije izmeu procesa istog sistema); zaguenjem komunikacijskog kanala drastino padaju performanse sistema; prekidom komunikacijskog kanala delovi sistema postaju nedostupni. Razvoj distribuiranih aplikacija namee neke probleme (izazove) s kojima se tokom razvoja nedistribuiranih (centraliziranih) aplikacije ne susreemo. Komunikacija - u distribuiranim sistemima je znatno sporija nego u centraliziranim sistemima, stoga je potrebno izbegavati distribuirana reenja kada obekti imaju intenzivnu meusobnu interakciju.
Slika 10-1 Uporedni prikaz centralizovanih i distribuiranih aplikacija Greke - Kada se svi objekti aplikacije nalaze unutar centraliziranog sistema oni bivaju zajedniki pogoeni grekama, tj. kada proces u kome se izvode prestane da funkcionie tada i svi objekti tog procesa prestaju s funkcijom. U distribuiranim sistemima je mogue izolirati procese i objekte u njima, a mogue je i realizirati sistem u kome aktivni procesi mogu preuzeti posao onih procesa koji trenutno nisu aktivni iz bilo kojeg razloga.
[102]
Raspoloivost centraliziranih sistema je uopteno govorei manja od raspoloivosti distribuiranih sistema. Ispadom jedne komponente centraliziranog sistema esto itav sistem postaje neupotrebljiv. Distribuirani sistemi pruaju mogunosti paralelnog izvravanja zadataka i preuzimanja funkcije onih komponenti koje su na udaljenom sistemu izvan funkcije. [18] Paralelni pristup u cenatraliziranim sistemima je est sluaj da se aplikativna logika izvrava unutar jedne niti izvoenja, a ukoliko elimo da podrimo paralelan pristup sistemu od strane vie istovremenih korisnika moramo uzeti u obzir kompleksnost realizacije vienitnog izvoenja aplikacije. Kod distruibuiranih sistema nuno postoji vie niti izvoenja, no one se mogu izvoditi unutar zasebnih procesa. Sigurnost - Kada se svi objekti aplikacije fizicki nalaze na jednom mestu i unutar istog procesa tada ne postoji problem meusobne autorizacije objekata. Kod distribuiranih sistema taj problem postoji jer objekti iz razliitih okruenja (procesa) meusobno pokuavaju uspostaviti komunikaciju te ih je potrebno meusobno identifikovati. No trenutno najvei problem distribuiranih sistema ini nedostatak adekvatne programske podrke. Iako se ulau veliki napori u svrhu pojednostavljenja oblikovanja i izrade, programska podrka distribuiranim sistemima kasni za razvojem hardvera usled postojanja bitnih razlika u oblikovanju i implementaciji programske podrke centraliziranih i distribuiranih sistema.
Prednosti koje bi imao Optimal SQM ukoliko bi bio izgraen u CORBA arhitekturi. CORBA je objektno-orijentisana arhitektura i infrastruktura koju koriste raunarske aplikacije za meusobnu saradnju u mrei, a nezavisna je od proizvoaa. Osnovna paradigma CORBA-e se moe definirati kao zahtev za uslugu (servis) od strane distribuiranog objekta. Usluge (servisi) koje objekti pruaju su raspoloivi pomou interfejsa, a interfejs je definisan IDL jezikom. Distribuirani objekti se mogu identifikovati pomou objektnih referenci, a iste se takoe definiu IDL jezikom. Korienjem standardnog IIOP (Internet Inter-ORB Protocol), CORBA programi bilo kod proizvoaa, na bilo kom raunaru, operativnom sistemu, programskom jeziku ili mrei mogu da komuniciraju sa CORBA programima istog ili drugog proizvoaa. Drugim reima, CORBA, omoguava interoperabilnost izmeu aplikacija u heterogenim distribuiranim okruenjima, bez obzira gde su one locirane. Glavna ideja iza CORBA-e je da m uop lno t izmeu objekata, koji se izvravaju na odreenim CORBA proizvodima razliitih izvora, bude mogua jer CORBA specifikuje svoje vlastite standardizovane komunikacijske protokole i Interface Definition Language (IDL). Zbog navedenog, barem u teoriji, svi srodni CORBA proizvodi moraju biti sposobni da meusobno obavljaju odreene operacije. CORBA ima svoj jezik za opisivanje interface objekata, Interface Description Language (IDL), koji moe biti preveden u mnogo jezika i za mnogo platformi. Ovako su CORBA interface-i nezavisni o programskom jeziku kojim e biti implementirani klijent i server objekti. CORBA takoe provodi svoje komunikacijske protokole koji se izvode iznad raznih standarnih protokola (npr. TCP/IP). CORBA je nezavisna o platformi i programskom jeziku i zbog toga omoguava integraciju software komponenti iz razliitih izvora. Integraciju omoguava preko mree sa raznolikim tehnologijama preko svojeg komunikacijskog protokola. CORBA protokoli standardizuju poruke i formate podataka tako da topologija i priroda mrenih protokola nije uopte vana. Najee
[103]
korieni CORBA protokol je Internet-Inter ORB Protokol (IIOP), koji specifikuje kako se CORBA poruke prenose na Internetu preko TCP/IP-a. Slika 10-2 Kreiranje stub-a i skeleta u CORBA arhitekturi Optimal SQM
[104]
Slika 10-3 Logiki pogled na sluaj registrovanja korisnika u CORBA OptimalSQM modelu
10.1.2
Optimal SQM SOA Arhitektura
Web servisi omoguavaju uvoenje nove softverske arhitekture pod nazivom SOA (Service Oriented Architecture Arhitektura zasnovana na uslugama) koja se temelji na reiskoritenju softvera (reusability) stvaranjem usluga koja se mogu koristiti iznova. Tradicionalna objektno orijentirana arhitektura promovie reusability kroz ponovno koritenje objekata i klasa. SOA koristi servis (uslugu) kao entitet koji se moe ponovo koristiti (reusability). Servisi se temelje nafunkcionalnosti koju pruaju putem svojih interfejsa. Servisi komuniciraju meusobno i sa svojim krajnjim korisnicima putem svojih interfejsa. Scenariji korienja servisa mogu biti vrlo jednostavni (npr. jednostavni request/response model ili prosleivanje poruka izmeu korisnika i usluge) i vrlo sloeni (sloena agregacija veeg broja servisa koji sarauju meusobno). U SOA arhitekturi postoje: servis ili usluga koja implementira poslovnu logiku i izlae (otvara, ini dostupnom) tu logiku putem dobro definisanih interfejsa, registar u kojem se objavljuju procesi pojedinih usluga kako bi ih potencijalni klijenti mogli pronai i iskoristiti te klijenti koji otkrivaju usluge u registrima i koriste ih putem njihovih interfejsa. Same usluge tj.servisi takoe mogu biti klijenti koji koriste druge usluge /servise.
[105]
Slika 10-4 Koncept SOA arhitekture
[106]
Slika 10-5 Primena SOA arhitekture Vana prednost SOA arhitekture u odnosu na ostale arhitekture je to omoguava izgradnju slabo povezanih raspodeljenih sastava (loosely coupled). Za ostvarenje takve arhitekture potrebno je imati mehanizam koji omoguava klijentima pristup uslugama i registru, mehanizma koji omoguava prijavljivanje usluga u registar te pretraivanje registra, te mehanizam za izlaganje interfejsa usluga kojem klijenti mogu pristupiti. U poslednjih 40 godina, principi konstrukcije softvera pojavili su se direktno iz raunarskih laboratorija iz razloga specifinih potreba informacionih sistema gde se moe izdvojiti pronalazak relacionog sistema za upravljanje bazama podataka.
[107]
Slika 9-6 prikazuje pojednostavljenu emu sastavljenu od konceptualnog (zahtevi), logikog (arhitektura) i fizikog (tehnologije) pogleda na modern konstrukciju informacionog sistema.
Slika 10-6 Maina za konstruisanje softvera [19] Modelu kompozitnog porgrama mete su tri aspekta konstrukcije softvera koje su ostale van domaaja tradicionalnog modela: Iskoristite poslovne informacije o dizajnu Podrite evoluciju to efikasnije Budite u mogunosti da iskoriste postojee imovine, a ne sistematski izgradnja novih Cilj takvih modela je da obezbedi reenje arhitekture koja je fleksibilna, prilagodljiva, i visokoproduktivna, omoguava brzo i neprekidano poravnanje izmeu poslovnih IT.
[108]
Slika 10-7 Logiki pogled modela komozitne aplikacije [19] Servisno orijentisana arhitektura predstavlja pristup koji se zasniva na raslanjivanju poslovnih procesa i niih nivoa aktivnosti u interoperabilne, na opte prihvaenim standardima bazirane XML WEB servise, koji se mogu meusobno kombinovati i rekombinovati u cilju ispunjavanja poslovnih zahteva. Ti servisi mogu biti specijalizovani, univerzalni, okrenuti prezentaciji, radu sa podacima i sve ono to je potrebno da se poslovni procesi nesmetano odvijaju. Sposobnost efiksnog upravljanja ivotnim ciklusom servisa (slika 9-8) je osnova za postizanje uspeha u implementaciji SOA.
Slika 10-8 ivotni ciklus servisa

[109]
U fazi identifikacije poslovnog procesa (ivotnog ciklusa servisa) detaljno se odreuje, kako usluga funkcionie sa poslovnog i organizacionog aspekta. Teite poslovnog modela je na poslovnim procesima, koji predstavljaju poslovnu logiku, koju treba primeniti kroz uslugu servis. U okviru poslovnog modela izrauju se modeli bitnih poslovnih procesa, koji predstavljaju osnovu za uslugu. Opseg i detaljnost poslovnog modeliranja zavise od sutine usluge. Ako neka usluga replikuje kompleksne poslovne procese, bitno je, da se izrade modeli postojeih poslovnih procesa. Na podruju modeliranja poslovnih procesa je karakterina upotrebavie tehnika. Najee koriena tehnika za modeliranje poslovnih procesa je UML procesni dijagram toka (engl. Flow chart). Na slici 10-9 prikazan je primer procesnog dijagrama.
Slika 10-9 Dijagram procesa Gore prikazani proces moe se izvoditi u tri odeljenja tj. organizacione jedinice. Izvoenje poinje u odeljenju 1, gde se i izvodi prva aktivnost. Izvoenje prve aktivnosti dovodi do prve odluke. U sluaju da je odgovor na prvu odluku da, nastavlja se sa drugom aktivnou. Sa izvoenjem druge aktivnosti se proces zavrava. U tom sluaju ceo proces tee unutar prvog odeljenja. Ako se na prvu odluku odgovori sa ne, izvoenje procesa se nastavlja u drugom odeljenju, gde se izvodi trea aktivnost. Izvoenje tree aktivnosti dovodi do druge odluke. U sluaju da je odgovor na drugu odluku da, izvoenje procesa se nastavlja u okviru prvog odeljenja; izvede se druga aktivnost. Izvoenje druge aktivnosti se time zavrava. Ako je odgovor na drugo pitanje ne, izvoenje procesa se nastavlja u treem odeljenju, gde se izvodi etvrta aktivnost. Izvoenjem etvrte aktivnosti dolazi se do tree odluke. U sluaju da je odgovor na treu odluku da, izvoenje procesa se nastavlja u okviru prvog odeljenja; izvede se druga aktivnost. Sa izvoenjem druge aktivnosti proces se zavrava. U sluaju da na treu odluku odgovorimo sa ne, proces se time zavrava.
[110]
Faza dizajna i modelovanja servisa podrazumeva ralanjivanje poslovnog procesa na funkcionalne delove da bi se odredilo sa kog stanovita ima smisla da budu realzovani u vidu servisa. Treba voditi rauna u kojoj meri e servisi biti specijalizovani jer je potrebno da budu upotrebljivi u budunosti i za neke druge poslovne procese (eng. reuse). S druge strane nije dobro dizajnirati servis za veliki broj razliitih sluajeva korienja jer je to onda slino dizajnu monolitne aplikacije. Na kraju ove faze postoje jasno definisani servisi koje je potrebno realizovati i povezati da bi se zadati poslovni proces realizovao. Za prikaz modela servisa upotrebljava se vie razliitih tehnika modeliranja. To su dijagrami sluajeva korienja (engl. use case dijagram), dijagrami interakcija (sekvencijalni dijagram i dijagram saradnje), dijagram klasa i domenski model. Na slici 10-10 je prikazan primer dijagrama sluajeva korienja.
Slika 10-10Primer dijagrama sluajeva korienja Korisnik 1 komunicira sa uslugama jedan, dva i tri. Usluga 1 povezana je sa uslugama 1.1 i 1.2 sa vezom ukljuuje, to znai, da u svom delovanju sadri i delovanje primera upotrebe 1.1 i 1.2. Korisnik 1 komunicira sa uslugom 2. Usluga 2 je povezana sa uslugom 4 sa vezom generalizacija. To znai da je usluga 2 specializacija usluge 4. Sa uslugom 3 komuniciraju korisnici 1 i 2. Usluga 3 je sa uslugom 2 povezana sa vezom proiruje. To znai da primer upotrebe 2 moe sadrati ponaanje koje je sadrano u primeru upotrebe 3. Primer sekvencijalnog dijagrama dat je na slici 10-11.
[111]
Slika 10-11 Primer sekvencijalnog dijagrama Korisnik poalje poruku 1 objektu klase 1. U tom trenutku se objekat klase 1 aktivira i poalje poruku 2 objektu klase 2. U tom trenutku se objekat klase 2 aktivira i poalje poruku 3 objektu klase 3. Objekat klase 3 se aktivira i poalje poruku 4 objektu klase 2. Objekat klase 2 poalje poruku 5 objektu klase 1. Objekat klase 1 poalje poruku 6 samom sebi (izvede rekurzivni poziv). Objekat klase 1 poalje poruku 7 korisniku i sa tim se proces zakljui. Primer dijagrama saradnje dat je na slici 10-12.
Slika 10-12 Primer dijagrama saradnje Faza izgradnje i sastavljanje softverskog servisa(engl. build and compose) je faza u kojoj se proverava da li neki od potrebnih servisa ve postoje (u katalogu aplikacija) a ako ih nema grade se od poetka, na osnovu projektnog zahteva u kome su jasno definisani. Pri izvedbi
[112]
web servisa je potrebno da funcionalno zadovoljava zahteve projekta. Nije vano u kom programskom jeziku su servisi izraeni niti je vano na kojoj se platformi vrte ni koje druge resurse koriste (baze podataka i sl.). Faza publikovanja softverskog servisa (engl. publising and provising) je faza u kojoj je potrebno obezbediti sve to je potrebno da bi se realizovao servis i uspostavili okviri njegovog korienja u SOA. U osnovi u ovoj fazi se uspostavljaju kontrolne take za SOA upravljanje. Definie se interfejs servisa i ugovori o korienju. U ovoj fazi, funkcionalnost i ispravnost rada samog servisa se ne razmatraju. Takoe u ovoj fazi je potrebno servise publikovati u UDDI poslovnom registru ako on postoji. Da bi korisnici mogli da koriste servis i njegovu funkcionalnost, potrebno je da postoji interfejs servisa koji na standardima zasnovanim mehanizmima to omoguava korisnicima. Preko svog intefejsa servis se objavljuje za upotrebu. Ugovor servisa treba da sadri funkcionalne metapodatke (kako treba interagovati sa servisom) i ne-funkcionalne metapodatke (koji uslovi i ogranienja postoje za korienje servisa). Veoma je vano da promene ugovora o korienju servisa ne zahtevaju i promene koda samog servisa. Faza integracije i primene (engl. integrate and deploy). Smisao razvoja servisno orjentisanie arhitekture je da se dobije fleksibilni modularni sistem koji se po potrebi moe prilagoavati promenama. Ponovno korienje pojedinih servisa je jedan od metoda koji to omoguavaju. Kada se u fazi izgradnje i sastavljanja servisa, servisi identifikuju,mogu se upotrebiti kao deo nove implementacije. Ono to se mora obezbediti je da se uvoenjem novog paketa servisa i novog poslovnog pravila u okruenje ne poremeti funkcionisanje sistema. Moe doi do neslaganja u verzijama i do nepredvienih meuzavisnosti tako da rad novog paketa servisa (u paketu mogu biti i neki servisi koji su ve u upotrebi u nekom drugom paketu servisa) utie negativno na ostatak sistema. Faza zatite i upravljanja (engl. secure and manage). Zatita je vana i potrebna za kontrolu pristupa web servisima i da bi se osigurala poverljivost i integritet podataka web servisa, posebno kada se vie servisa izvrava odjednom. Glavni predlog za zatitu web servisa je Web Service Security (WS-Security), to prua okvir za zatitu poruka od krajnje do krajnje take za poruke web servisa. Zaglavlja WS-Security ukljucuju mogucnost primenu autentifikacije kao to su Kerberos karte i mogu da se koristite tehnologije XML Encryption i XML potpisa za dodatnu zatitu sadraja poruke.Upravljanje servisima potrebno je za organizaciju, jer se servisi vremenom menjaju. Ako je veliki broj servisa koje organizacija prua korisnicima, od presudne je vanosti definisati mehanizam kontrole i upravljanja njima. Faza procene (engl. evaluate). U ovoj fazi se prati rad i upotreba servisa i vri procena njihove adekvatnosti. U sluaju da servis po svojoj funkcionalnosti ili nekom drugom kriterijumu ne zadovoljava oekivanja, proces se ponavlja od identifikacije poslovnog procesa do nove evaluacije. SOA predstavlja aplikacionu platformu koja povezuje poslovne procese sa operacionim resursima (slika 10-13). Ideja je da se pomou XML WEB servisa iskoriste svi postojei resursi koji u tradicionalnim arhitekturama ne bi mogli saraivati.
[113]
Slika 10-13 Stek SOA specifikacija [19]
[114]
11 Fiziki dizajn OptimalSQM

U ovom poglavlju emo razraditi izgled i funkcionisanje OQT-BOX-a. Prikazaemo izgled formi, testiranja, izvetaja, podeavanja kao i use case dijagrame koji ih objanjavaju. U prvom delu poglavlja navodimo samo interfejse do dolaska u korisniki meni, gde su omoguene prethodno pomenute opcije. Na slici 11-1 se nalazi izgled home stranice modula OQT BOX. Ona e biti prilagoena novim korisnicima. Nudie informacije za one koji ele da samo probaju taj modul, tj.da ga koriste. Dakle, korisnici mogu da kupe samo OQT BOX modul na primer ili mogu samo da koriste njegove usluge.
Slika 11-1 Poetna strana OptimalSQM
Na slici 11-2 je prikazana forma za prijavljivanje korisnika na sajtu OptimalSQM. Korisnik na home stranici moe odabrati paket koji eli da koristi u promotivnom periodu. U ovom sluaju, korisnik je odabrao OQT-BOX paket, i moemo videti da se od njega zahteva da unese korisniko ime ili e-mail kao i ifru da bi se uspeno prijavio za korienje.
[115]
Slika 11-2 Forma za prijavljivanje korisnika Na slici 11-3 je prikazana home stranica nakon logovanja korisnika na OQT-BOX modul. Moemo videti ponuene opcije da testira sluajeve upotrebe, uradi izvetaj ili menja podatke o sebi, o projektima koji su trenutno aktivni ili su odraeni. Takoe, moe se prijaviti na automatsko slanje novosti u radu sistema. Desno uvek ima napomenu jo koliko traje njegov rpomotivni period i opciju da nadogradi svoj paket, jer trial verzija ne prua maksimum koji poseduje OQT-BOX.
Slika 11-3 Korisnika home stranica nakon logovanja

[116]
Slika 11-4 Sekvencijalni dijagram prijavljivanja korisnika na sistem Na slici 11-4 prikazan je sekvencijalni dijagram logovanja korisnika na OptimalSQM sistem. Na slici 11-5 je prikazan korisniki interfejs po ulasku na sekciju Account, gde korisnik moe upravljati svojim projektima, kao i otkazati iste.
[117]
Slika 11-5 Dizajn interfejsa za upravljanje projektima Na slici 11-6 prikazan je dizajn korisnikog interfejsa u kome korisnik ulazi klikom na sekciju test cases na korisnikoj home strani, au kojoj ima mogunost upravljanja sluajevima testiranja u okviru odreenih projekata.
Slika 11-6 Dizajn interfejsa za upravljanje sluajevima testiranja
[118]
Na slici 11-7 prikazan je dizajn interfejsa u kome korisnik unosi parametre i podatke za kreiranje novog sluaja testiranja.
Slika 11-7 Kreiranje novog sluaja testiranja u OptimalSQM
[119]
Slika 11-8 Kreiranje novog test plana
[120]
Slika 11-9 Kreiranje novog izvetaja testiranja
[121]
12 Lista slika
Slika 1-1 Definicija softverske arhitekture ...........................................................................................................................6 Slika 1-2 Struktura softverske arhitekture ............................................................................................................................7 Slika 2-1 Dvoslojna arhitektura klijent-server [2] ................................................................................................................9 Slika 2-2 Upit-odgovor ponaanje u K/S arhitekturi [3] ..................................................................................................... 10 Slika 2-3 Grafiki prikaz debelog i tankog klijenta [3] ....................................................................................................... 10 Slika 2-4 Komunikacija izmeu slojeva kod vieslojne K/S arhitekture [3] ....................................................................... 11 Slika 2-5 Detaljnija komunikacija izmeu slojeva gde je Web server aplikacioni server ................................................... 11 Slika 2-6 Troslojna arhitektura klijent-server [2]................................................................................................................ 12 Slika 2-7 Ilustracija kijentovog poziva ka serveru [5] ........................................................................................................ 15 Slika 2-8 Kreiranje stubova (stubs) iz IDL opisa [5] .......................................................................................................... 16 Slika 2-9 CORBA proces [5] .............................................................................................................................................. 16 Slika 2-10 Peer-to-Peer arhitektura [6] ............................................................................................................................... 19 Slika 2-11 ema decentralizovane P2P arhitekture............................................................................................................. 19 Slika 2-12 ema centralizovane P2P arhitekture ................................................................................................................ 20 Slika 2-13 ema hibridne P2P arhitekture .......................................................................................................................... 20 Slika 2-14 Dijagram prvog nivoa ........................................................................................................................................ 22 Slika 2-15 Dijagram drugog nivoa ...................................................................................................................................... 23 Slika 2-16 Dijagram treeg nivoa ....................................................................................................................................... 24 Slika 2-17 J2EE aplikacioni server - raspodela odgovornosti elemenata J2EE arhitekture [9] ........................................... 25 Slika 2-18 J2EE klijent, server i biznis prezentacija [9] ..................................................................................................... 28 Slika 3-1 Model razvoja procesa ........................................................................................................................................ 29 Slika 3-2Kaskadni model razvojnog procesa softvera ........................................................................................................ 30 Slika 3-3 V model razvojnog procesa softvera ................................................................................................................... 31 Slika 3-4 Fazni razvoj procesa softvera .............................................................................................................................. 32 Slika 3-5 Inkrementalni razvoj ........................................................................................................................................... 32 Slika 3-6 Iterativni razvoj [10]............................................................................................................................................ 33 Slika 3-7Prototipski model razvojnog procesa softvera ...................................................................................................... 33 Slika 3-8 Model specifikacije rada [10] .............................................................................................................................. 34 Slika 3-9 Transformacioni model procesa .......................................................................................................................... 34 Slika 3-10 Faze razvoja softvera u spiralnom modelu ........................................................................................................ 35 Slika 3-11 Ciklus razvoja softvera u spiralnom modelu [10] .............................................................................................. 36 Slika 4-1 4+1 pogled........................................................................................................................................................... 37 Slika 4-2 Forma za logovanje korisnika na sajtu Optimal SQM ......................................................................................... 38 Slika 4-3 Logiki tok procesa ............................................................................................................................................. 39 Slika 4-4 Dijagram klasa za sluaj logovanja korisnika...................................................................................................... 40 Slika 4-5 Procesni dijagram za sluaj logovanja korisnika .................................................................................................40 Slika 5-1 Statika arhitektura OptimalSQM reenja ........................................................................................................... 43 Slika 5-2 Prikaz aktivnosti definisanja zahteva .................................................................................................................. 45 Slika 6-1 Komponente OQT BOX-a...................................................................................................................................47 Slika 6-2 Generalni prikaz rada OQT BOX-a ..................................................................................................................... 48 Slika 7-1 Proces razvoja softvera i pozicija testiranja u celom procesu .............................................................................. 49 Slika 7-2Black box testiranje .............................................................................................................................................. 54 Slika 7-3Uporedni prikaz tehnika Black Box, Gray Box i White Box................................................................................ 58 Slika 7-4 Metodologija testiranja softverskog proizvoda.................................................................................................... 60 Slika 8-1 Faktori za podeavanje FP-a................................................................................................................................ 63 Slika 8-2 Izraunavanje grubih funkconalnih taaka .......................................................................................................... 67 Slika 8-3 Forma za izraunavanje RCAF-a ........................................................................................................................ 67 Slika 8-4 Relacije jezici nivoi - izvorne linije koda ......................................................................................................... 68 Slika 8-5 Matrica efikasnosti otklanjanja greke ................................................................................................................ 70 Slika 8-6 Nivoi zrelosti definisani od strane Instituta za softversko inenjerstvo ............................................................... 72 Slika 8-7 Procena veliine i cene softvera u zavisnoti od faze............................................................................................ 75 Slika 9-1 Izgled MSTAR reenja ........................................................................................................................................ 78 Slika 9-2 Logika MSTAR-a................................................................................................................................................ 80 Slika 9-3 HP ALM prati ivotni ciklus od poetka do kraja [14] ....................................................................................... 82 Slika 9-4 HP protoni model za upravljanje kvalitetom softvera ........................................................................................ 83 Slika 9-5 Dobiti u IT industriji primenom razliitih HP reenja za upravljanje kvalitetom [15] ........................................ 85 Slika 9-6 Dobiti u biznisu primenom razliitih HP reenja za upravljanje kvalitetom [15] ................................................ 86 Slika 9-7 Kljuni termini u scenarijima [15] ...................................................................................................................... 86 Slika 9-8 Automatizacija procesa testiranja rezultira poveanom IT produktivnou [15] ................................................. 87
[122]

Slika 9-9 Poveanje kvaliteta u IT produktivnosti [15] ...................................................................................................... 87 Slika 9-10 Poveanje performansi i smanjenje trokova [15] ............................................................................................. 88 Slika 9-11 Rezultati centralizacije i potranje u IT okruenju poboljane efikasnisti ......................................................... 88 Slika 9-12 Automatizovani rezultati testiranja u slubi zatite prihoda .............................................................................. 89 Slika 9-13 Automatizacija testiranja i kontrole kvaliteta poveava prihod ......................................................................... 89 Slika 9-14 Izgled glavnog ekrana HP QTP [16] ................................................................................................................. 91 Slika 9-15 Moete pozvati dugme pod imenom button ali QTP ga prepoznaje pod imenom Calculate [16] ............... 92 Slika 9-16 Pokretanje novog testa....................................................................................................................................... 93 Slika 9-17 Ekspertski pogled u QTP ...................................................................................................................................93 Slika 9-18 Analiziranje testa pomou checkpoint-a............................................................................................................ 94 Slika 9-19 Prozor koji prikazuje rezultate testiranja ........................................................................................................... 94 Slika 9-20 Slim-Estimate ................................................................................................................................................... 96 Slika 9-21 Slim- Control..................................................................................................................................................... 97 Slika 9-22 Slim-Metrics...................................................................................................................................................... 98 Slika 9-23 Slim- Estimate Express ..................................................................................................................................... 99 Slika 10-1 Uporedni prikaz centralizovanih i distribuiranih aplikacija ............................................................................. 102 Slika 10-2 Kreiranje stub-a i skeleta u CORBA arhitekturi Optimal SQM ...................................................................... 104 Slika 10-3 Logiki pogled na sluaj registrovanja korisnika u CORBA OptimalSQM modelu ....................................... 105 Slika 10-4 Koncept SOA arhitekture ................................................................................................................................ 106 Slika 10-5 Primena SOA arhitekture ................................................................................................................................ 107 Slika 10-6 Maina za konstruisanje softvera [19] ............................................................................................................. 108 Slika 10-7 Logiki pogled modela komozitne aplikacije [19] .......................................................................................... 109 Slika 10-8 ivotni ciklus servisa ...................................................................................................................................... 109 Slika 10-9 Dijagram procesa............................................................................................................................................. 110 Slika 10-10Primer dijagrama sluajeva korienja ........................................................................................................... 111 Slika 10-11 Primer sekvencijalnog dijagrama .................................................................................................................. 112 Slika 10-12 Primer dijagrama saradnje ............................................................................................................................. 112 Slika 10-13 Stek SOA specifikacija [19] .......................................................................................................................... 114 Slika 11-1 Poetna strana OptimalSQM ........................................................................................................................... 115 Slika 11-2 Forma za prijavljivanje korisnika .................................................................................................................... 116 Slika 11-3 Korisnika home stranica nakon logovanja ..................................................................................................... 116 Slika 11-4 Sekvencijalni dijagram prijavljivanja korisnika na sistem .............................................................................. 117 Slika 11-5 Dizajn interfejsa za upravljanje projektima ..................................................................................................... 118 Slika 11-6 Dizajn interfejsa za upravljanje sluajevima testiranja .................................................................................... 118 Slika 11-7 Kreiranje novog sluaja testiranja u OptimalSQM .......................................................................................... 119 Slika 11-8 Kreiranje novog test plana ............................................................................................................................... 120 Slika 11-9 Kreiranje novog izvetaja testiranja ................................................................................................................ 121
[123]
13 Reference
[1] [2] [3] [4] [5] [6] [7] [8] [9] [10] [11] [12] [13] [14] [15] [16] [17] [18] [19] [20] [21] [22]
http://silab.fon.rs/index.php?option=com_docman&task=doc_download&gid=71&&Itemid=56 Poliuk E. Jaroslav, Projektovanje informacionih sistema http://ccd.uns.ac.rs/aus/drus/drus_doc/geomatika/D03%20Arhitektura.pdf Aleksy, Markus, Korthaus, Implementing Distributed Systems with Java and CORBA, Springer, 2005 http://www.omg.org/news/whitepapers/seguecorba.pdf Veinovi M., Jevremovi A., Uvod u http://bit.ly/wTI86f Vlaji S., Projektovanje softvera (skripta), Beograd, 2009. Dr_Lazic_-_Pregled_Arhitektura_2.ppt http://silab.fon.rs/index.php?option=com_docman&task=doc_download&gid=417&&Itemid=56 http://www.scribd.com/doc/18275748/6Faze-Testiranja-Softvera http://dc123.4shared.com/doc/D8UszZRY/preview.html http://www.link-elearning.com/linkdl/elearning/pregledJedinice.php?IDJedinice=4458 http://www.trustmarquesolutions.com/wp-content/uploads/2011/12/Voke_Solution-SnapshotReport_ALM-11.pdf http://www.sqaforums.com/attachments/593372-3120201.pdf http://bit.ly/yEGtGI http://www.telfor.rs/telfor2002/radovi/2-1.pdf http://www.slideshare.net/EsadBP/diplomski-rad Jean Jacques Dubray, Composite Software Construction, 2007 prevedena ceklista.xlsx http://www.link-elearning.com/dlmaterijali/materijali//DLKS/sadrzajNJpdf/KS_09.pdf http://2010.telfor.rs/files/radovi/TELFOR2010_10_26.pdf un m , Univerzitet Singidunum, Beograd, 2007
[124]

DUNP - Racunarska Tehnika - SE - T3 - PISA, OQT BOX - Verzija 1.0

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

DUNP - Racunarska Tehnika - SE - T3 - PISA, OQT BOX - Verzija 1.0

Uploaded by

Copyright:

Available Formats

Dravni Univerzitet u Novom Pazaru Departman tehnikih nauka Raunarska tehnika

Novi Pazar, mart 2012.

Optimal SQM, OQT BOX

2.5.1 2.5.2 2.5.2.1 2.5.2.2 2.5.2.3 2.6 3

Optimal SQM, OQT BOX

5.3 5.4 5.5 5.5.1 5.5.2 6

OQT-BOX .................................................................................................................. 47 6.1 Osnovne karakteristike OQT BOX-a ................................................................... 48

7.1.1 7.1.1.1 7.1.2 7.1.2.1 7.1.2.2 7.1.2.3 7.1.3 7.1.4

7.2.1 7.2.2 7.2.3 7.2.4 7.2.5 7.2.6 8

8.1.1 8.1.2 8.1.3

8.2.1 8.2.2 8.2.3 8.2.4

Optimal SQM, OQT BOX

Optimal SQM, OQT BOX

10.1 10.1.1 10.1.2 11 12 13

Optimal SQM, OQT BOX

Optimal SQM, OQT BOX

Optimal SQM, OQT BOX

Optimal SQM, OQT BOX

Optimal SQM, OQT BOX

2 Dizajn arhitekture sistema

Optimal SQM, OQT BOX

Optimal SQM, OQT BOX

Optimal SQM, OQT BOX

Optimal SQM, OQT BOX

Optimal SQM, OQT BOX

Optimal SQM, OQT BOX

Slika 2-7 Ilustracija kijentovog poziva ka serveru [5]

Optimal SQM, OQT BOX

Slika 2-9 CORBA proces [5]

Optimal SQM, OQT BOX

Optimal SQM, OQT BOX

Optimal SQM, OQT BOX

Optimal SQM, OQT BOX

Slika 2-13 ema hibridne P2P arhitekture

Optimal SQM, OQT BOX

Optimal SQM, OQT BOX

Slika 2-14 Dijagram prvog nivoa

Optimal SQM, OQT BOX

Slika 2-15 Dijagram drugog nivoa

Optimal SQM, OQT BOX

Slika 2-16 Dijagram treeg nivoa

Optimal SQM, OQT BOX

Optimal SQM, OQT BOX

Odgovornost Deljeni pristup Perzistentnost

Optimal SQM, OQT BOX

Optimal SQM, OQT BOX

Optimal SQM, OQT BOX

3 Modeli ivotnog ciklusa softvera

Optimal SQM, OQT BOX

Optimal SQM, OQT BOX

Optimal SQM, OQT BOX

Optimal SQM, OQT BOX

Slika 3-7Prototipski model razvojnog procesa softvera

Optimal SQM, OQT BOX

Optimal SQM, OQT BOX

Optimal SQM, OQT BOX

Optimal SQM, OQT BOX

4 Poslovni inteligenta simulaciona arhitektura (PISA) sa aspekta 4+1 pogleda

Optimal SQM, OQT BOX

Optimal SQM, OQT BOX

Slika 4-3 Logiki tok procesa

Optimal SQM, OQT BOX

Slika 4-4 Dijagram klasa za sluaj logovanja korisnika

Slika 4-5 Procesni dijagram za sluaj logovanja korisnika