OptimalSQM MAINT sistem za odrzavanje

Drţavni Univerzitet u Novom Pazaru

Tehnički fakultet – Računarskta tehnika

Predmet: Interakcija čovek - računar

Projekat: OQT MAINT

Mentor: dr Ljubomir Lazić

Tim#4:

Adis Numanović, 02-018/09

Denis Bogućanin, 02-507/10

Nenad GloĎović, 02-510/09

HCI PROJEKAT MAINT 2012

Prof. dr Ljubomir Lazić Tim #4 2

SADRŢAJ

Contents

1. POJAM INTERAKCIJE ČOVEK - RAČUNAR ......................................................... 6

1.1 Ciljevi .................................................................................................................. 9

1.2 Vizija ................................................................................................................. 10

1.3 Misija ................................................................................................................. 10

1.4 Analiza zahteva .................................................................................................. 10

2. PISA - Poslovno Inteligentna Simualaciona Arhitektura ............................................ 11

3. INTERAKCIJA KOMPONENTE OQT MAINT SA DRUGIM KOMPONENTAMA13

3.1 Interakcija sa OQT MNGR komponentom.......................................................... 14

3.2 Interakcija sa OQT SIM komponentom .............................................................. 15

3.3 Interakcija sa OQT BOX komponentom ............................................................. 16

3.4 Interakcija sa OQT OPST komponentom ............................................................ 17

4. ANALIZA KONKURENTSKIH REŠENJA ............................................................. 18

4.1 MaintSmart ........................................................................................................ 18

4.1.1 Pokretanje MaintSmart ............................................................................... 18

4.1.2 Kreiranje radnog naloga .............................................................................. 19

4.2 MStar (Mosaic’s Structured Testing and Assessment Repository)....................... 19

4.3 FastMaint ........................................................................................................... 21

4.4 Primena Nielsen – ovih pravila ........................................................................... 25

5. STUDIJA IZVODLJIVOSTI .................................................................................... 28

5.1 Kriterijumi izvodljivosti ..................................................................................... 28

6. MAINT FUNKCIJA ................................................................................................. 32

6.1 IOP Maintance Engine ....................................................................................... 32

6.2 Šest Sigma Engine .............................................................................................. 33

6.3 Razvojni postupci – EVOP ................................................................................. 35

6.4 Estimator Engine ................................................................................................ 36

6.5 DOE Engine ....................................................................................................... 37

6.6 Reliability expert ................................................................................................ 38

6.7 Usluge OQT MAINT-a ...................................................................................... 39

6.8 Kako čitati zahteve, dizajn i izvorni kod ............................................................. 39

6.9 Starenje softvera ................................................................................................. 40

6.10 Vrste odrţavanja................................................................................................. 41



6.11 Toškovi odrţavanja ............................................................................................ 42

6.11.1 PredviĎanje troškova odrţavanja ................................................................. 42

6.11.2 Detaljnije predviĎanje troškova ................................................................... 42

6.12 Aktivnosti odrţavanja ......................................................................................... 42

6.13 Zaključak ........................................................................................................... 44

7. DEFINISANJE LOGIČKOG DIZAJNA ................................................................... 44

7.1 Konceptualno rešenje ......................................................................................... 44

7.2 Kontekst dijagram .............................................................................................. 45

7.3 Upoznavanje sa use case dijagramom ................................................................. 46

7.4 Use Case Model izrade softvera.......................................................................... 47

7.5 Dijagram klase za izradu softvera ....................................................................... 48

7.6 Dijagram sekvenci za razvoj softvera ................................................................. 49

7.7 Use Case Model OQT MAINT ........................................................................... 50

7.8 Dijagram sekvenci za OQT MAINT ................................................................... 51

7.9 Use Case Model za vrste odrţavanja ................................................................... 52

7.10 Dijagram klasa za vrste odrţavanja ..................................................................... 53

7.11 Use Case Model za 6 sigma eXpert .................................................................... 54

7.12 Use Case Model estimator eXpert ....................................................................... 55

7.13 Use Case Model reliability expert ....................................................................... 56

7.14 Use Case Model za logovanje na sajt BISA ........................................................ 57

7.15 Osnovni dijagrami aktivnosti .............................................................................. 58

7.16 Tabela aktivnosti ................................................................................................ 61

8. FIZIČKI DIZAJN ..................................................................................................... 63

8.1 Prototip (skiciranje) ............................................................................................ 66

8.2 Pokretanje programa........................................................................................... 68

8.3 Prijavljivanje ...................................................................................................... 69

8.4 Registracija ........................................................................................................ 69

8.5 Home prozor ...................................................................................................... 70

8.6 Evidencija radnih naloga .................................................................................... 72

8.7 Dizajn IOP Maintenance Engine u okviru softvera OptimalSQM ....................... 73

9. KLM teorija .............................................................................................................. 74

9.1 GOMS model ..................................................................................................... 74

9.2 Hick-ov zakon .................................................................................................... 82

9.3 Primena Hick-ovog zakona na ............................................................................ 82

9.4 Fitts-ov zakon ..................................................................................................... 83

9.5 Primena Fitts-ovog zakona ................................................................................. 84



10. TESTIRANJE SOFTVERA ...................................................................................... 85

10.1 Razlozi zbog kojih nastaju greške na softveru ..................................................... 85

10.2 Testiranje ........................................................................................................... 86

10.2.1 Vidljivost stanja sistema ............................................................................. 86

10.2.2 Podudaranje sistema i realnog sveta ............................................................ 87

10.2.3 Veštine ....................................................................................................... 88

10.2.4 Fleksibilnost minimalistički dizajn .............................................................. 88

10.3 Primena Nielsen-ovih pravila na naše softversko rešenje .................................... 89

11. Literatura .................................................................................................................. 94

SADRŢAJ SLIKA

Slika 1.1 Interakcija čovek računar ....................................................................................7

Slika 1.2 Strukturni blokovi HCI .......................................................................................8

Slika 2.1 Novi logo PISA (Poslovno Inteligentna Simualaciona Arhitektura) kompanije.. 11

Slika 2.2 Funkcije BISA-e ............................................................................................... 12

Slika 3.1. Interakcija komponente OQT OPST sa ostalim komponentama........................ 13

Slika 3.1.1 OQT MNGR paket OptimalSQM .................................................................. 14

Slika 3.2.1 OQT SIM paket OptimalSQM....................................................................... 15

Slika 3.3.1 OQT BOX paket OptimalSQM .................................................................... 16

Slika 3.4.1 OQT OPST paket OptimalSQM .................................................................... 17

Slika 4.1.1.1 Početni izgled pokrenutog programa ........................................................... 18

Slika 4.1.2.1 Postupno, slikovito, obijašnjeno kreiranje naloga ........................................ 19

Slika 4.2.1 Izgled MStar-а ............................................................................................... 21

Slika 4.3.1 Početni prozor FastMaint-a ............................................................................ 22

Slika 4.3.2 Opis radnog naloga ........................................................................................ 23

Slika 5.1.1 Dijagram operativne izvodljivosti .................................................................. 29

Slika 5.1.2 Dijagram tehničke izvodljivosti ...................................................................... 29

Slika 5.1.3 Dijagram vremenske izvodljivosti .................................................................. 30

Slika 5.1.4 Dijagram ekonomske izvodljivosti ................................................................. 31

Slika 5.1.5 Dijagram ukupne izvodljivosti ....................................................................... 31

Slika 6.1.1 IOP Maintance Engine ................................................................................... 33



Slika 6.2.1.1 Faze Šest Sigma metodologije ..................................................................... 34

Slika 6.2.1.2 DMAIC ciklus uvoĎenja 6 Sigma ................................................................ 35

Slika 6.10.1 Vrste odrţavanja .......................................................................................... 41

Slika 6.12.1 Troškovi odrţavanja softvera ....................................................................... 43

Slika 7.1.1 Konceptualno rešenje ..................................................................................... 45

Slika 7.2.1 Izgled kontekst dijagrama .............................................................................. 46

Slika 7.4.1 Use Case Model izrade softvera ..................................................................... 47

Slika 7.5.1 Dijagram klase za izradu softvera ................................................................... 48

Slika 7.6.1 Sekvencijalni dijagram za razvoj softvera....................................................... 49

Slika 7.7.1 Model slučaja upotrebe OQT MAINT komponente ........................................ 50

Slika 7.8.1 Dijagram sekvenci za OQT MAINT komponentu .......................................... 51

Slika 7.9.1 Use Case Model za IOP Maintenance ............................................................. 52

Slika 7.10.1 Dijagram klasa za IOP Maintenance ............................................................. 53

Slika 7.11.1 Use Case Model 6 Sigma ............................................................................. 54

Slika 7.12.1 Dijagram slučaja upotrebe stručnjaka za estimaciju ...................................... 55

Slika 7.13.1 Dijagram slučaja upotrebe eksperta pouzdanosti........................................... 56

Slika 7.14.1 Dijagram slučaja upotrebe pristup sajtu BISA .............................................. 57

Slika 7.15.1 Dijagram aktivnosti za registraciju i logovanje na sajt BISA ........................ 59

Slika 7.15.2 Dijagram aktivnosti planiranja projekta ........................................................ 60

Slika 7.15.3 Dijagram aktivnosti ofrţavanja softvera ....................................................... 61

Slika 8.1: Pokazivački ureĎaji (miš) ................................................................................. 64

Slika 8.2: Primer dizajna ikonica ..................................................................................... 65

Slika 8.3: Dizajn i redizajn ikonica .................................................................................. 65

Slika 8.2.2 - Početni prozor nakon pokretanja .................................................................. 68

Slika 8.2.1 - Ikonica OptimalSQM-a ................................................................................ 68

Slika 8.3.1 Pokretanje naše komponente .......................................................................... 69

Slika 8.4.1 Izgled prozora za registraciju naše OQT Maint komponente ........................... 70

Slika 8.5.1 Izgled početne strane softvera OptimalSQM .................................................. 71

Slika 8.6.1 Prozor radnog naloga, i spisak naloga ............................................................ 72

Slika 8.7.1: Pet tipova odrţavanja .................................................................................... 73

Slika 9.1.1 GOMS model ................................................................................................. 75

Slika 9.1.2: Izračunavanje vremena potrebnog za premeštanje fajla u drugi disk .............. 76

Slika 9.1.3: Izračunavanje vremena potrebnog za premeštanje fajla u drugi disk .............. 78



Slika 9.1.4 Izračunavanje vremena za pristup random nalogu .......................................... 80

Slika 9.4.1: Odvojeni pokreti prema meti ........................................................................ 83

Slika 9.5.1 Primer Fitts-ovog zakona ............................................................................... 84

Slika 10.3.1: Obeleţena lokacija e-mail na radnoj površini .............................................. 90

Slika 10.3.2: Vidljivost statusa sistema ............................................................................ 91

Slika 10.3.3: Estetski i minimalni dizajn .......................................................................... 92

SADRŢAJ TABELA

Tabela 1.1 HCI sadrţaj ......................................................................................................9

Tabela 4.4.1 Nielsen - ova pravila ................................................................................... 28

Tabela 7.4.1: Opis slučaja upotrebe izrade softvera ......................................................... 47

Tabela 7.7.1 Opis slučaja upotrebe OQT MAINT komponente ........................................ 50

Tabela 6.9.1 Opis slučaja upotrebe za IOP Maintenance .................................................. 52

Tabela 7.11.1 Opis slučaja upotrebe 6 Sigma eXperta ..................................................... 54

Tabela 7.12.1 Opis slučaja upotrebe stručnjaka za estimaciju .......................................... 55

Tabela 7.13.1 Opis slučaja upotrebe za Reliability eXpert ............................................... 56

Tabela 7.14.1 Opis slučajeva upotrebe pristupa sajtu BISA ............................................. 57

Tabela 7.16.1 Aktivnosti OptimalSQM paketa ............................................................... 62

Tabela 9.1.1: Tipovi operatora u GOMS modelu ............................................................. 77

Tabela 10.3.1 Konačna tabela Nielsen-ovih pravila za OptimalSQM ............................... 93

1. POJAM INTERAKCIJE ČOVEK - RAČUNAR

Human-Computer Interaction (HCI) bavi se proučavanjem interakcije

(meĎudejstva) izmeĎu ljudi (korisnika) i računara. Interdisciplinarnost je oblast povezana

sa računarskom naukom preko više naučnih oblasti. HCI je disciplina koja se odnosi na

projektovanje, evalvaciju i implementaciju interaktivnih kompjuterskih sistema koje

koriste ljudi pri čemu se proučavaju i glavni fenomeni koji ih okruţuju. HCI takoĎe



proučava: performanse zadataka koje zajednički obavljaju ljudi i kompjuteri, strukturu

komunikacije čovek-kompjuter, sociološku i organizacionu interakciju tokom

projektovanja sistema, čovekove mogućnosti da koristi kompjuter (uključujući mogućnost

da uči), algoritme i programiranje samog interfejsa, inţenjerske probleme koji se

pojavljuju tokom projektovanja i izgradnje interfejsa i procese specifikovanja,

projektovanja i implementacije interfejsa.

Slika 1.1 Interakcija čovek računar

Interakcija izmeĎu korisnika i računara pojavljuje se kao korisnički interfejs (ili

prosto interfejs) koji obuhvata i hardver (tj. ulazne i izlazne urenaje) i softver (na primer,

odreĎivanje koja informacija je predstavljena korisniku na ekranu i kako je predstavljena).

Često se koristi i pojam interakcija čovek-mašina, Man–Machine Interaction (MMI)

kao alternativa HCI-u i odnosi se pre svega na velike sisteme, npr. avioni, hidrocentrale i

sl. Interakcija čovek-računar je naučna disciplina koja se bavi projektovanjem,

evaluacijom, i primenom interaktivnih računarskih sistema koje koristi čovek, uz

proučavanje osnovnih fenomena koji ih okruţuju. HCI se razvija kao specijalna oblast

interesovanja unutar nekoliko disciplina, gde se svaka disiplina drugačije ističe.

Uz računarsku nauku i informacionu tehnologiju, u HCI su uključene i sledeće

oblasti:

estetika

antropologija

veštačka inteligencija

kognitivna nauka

dizajn

ergonomija

ljudski faktori



bibliotečko-informatička nauka

psihologija

socijalna psihologija

sociologija

Slika 1.2 Strukturni blokovi HCI

Moţe se reći da je HCI disciplina koja koja se bavi dizajnom, evaluacijom i

implementacijom interaktivnog kompjuterskog sistema za ljudsku upotrebu i studija

najvećih fenomena koji je okruţuju. Razmatramo pet aspekata čovek-kompjuter interakcije

koji su meĎusobnom odnosu:

(N) priroda čovek-kompjuter interakcije,

(U) korišćenje i kontekst kompjutera,

(H) ljudske karakteristike,

(C) kompjuterski sistem i interfejs arhitektura i

(D) proces razvoja.

Kompjuterski sistem postoji unutar velike socijalne, organizacione i radne sredine

(U1). Unutar ovog konteksta postoje aplikacije za koje ţelimo da zaposlimo kompjuterski

sistem (U2). Ali proces postavljanja kompjutera u rad znači da se ljudski, tehnički i radni

aspekti situacije postavljanja moraju podesiti sa svakim drugim kroz ljudsko učenje,

prilagoĎavanje sistemu ili drugim strategijama (U3). Kao dodatak korišćenju socijalnog

konteksta kompjutera, na strani ljudi moraju se uzeti u obzir ljudsko informaciono

procesiranje (H1), komunikacija (H2) i fizičke karakteristike korisnika (H3). Na strani

kompjutera razvijene su različite tehnologije za podršku interakcije sa ljudima: ulazni i

izlazni ureĎaji dovode u vezu čoveka i mašinu (C1). Oni se koriste u brojnim tehnikama za

organizovanje dijaloga (C2). Ove tehnike se koriste za implementiranje velikih dizajn

elemenata, kao što je metafora interfejsa (C3). Ulazeći dublje u supstrat mašine

podrţavanja dijaloga, dijalog moţe opseţno koristiti kompjuterske grafičke tehnike (C4).



Tabela 1.1 HCI sadržaj

N Priroda HCI-a N1 Meta-modeli HCI-a

U Korišćenje i kontekst kompjutera

U1 Ljudska socijalna organizacija i rad

U2 Aplikaciona područja

U3 Čovek-kompjuter postavka i prilagođavanje

H Ljudske karakteristike

H1 Ljudsko informaciono procesiranje

H2 Jezik, komunikacija, interakcija

H3 Ergonomija

C Kompjuterski sistem i interfejs

arhitektura

C1 Ulazni i izlazni uređaji

C2 Tehnike dijaloga

C3 Vrsta dijaloga

C4 Kompjuterske grafike

C5 Arhitektura dijaloga

D Proces razvoja

D1 Dizajn prilazi

D2 Implementacione tehnike

D3 Tehnike evaluacije

D4 Uzorni dizajni

Sloţeni dijalozi vode ka razmatranju sistemske arhitekture neophodne za podršku

karakteristika kao što su interkonektivni aplikacioni programi, odgovor u realnom

vremenu, mreţne komunikacije, višekorisnički i kooperativni interfejsi i više-zadatni

objekti dijaloga (C5). Konačno, tu je proces razvoja koji inkorporiše dizajn (D1) za čovek-

kompjuter dijaloge, tehnike i alate (D2) za njihovu implementaciju (D2), tehnike za

njihovu evaluaciju (D3) i brojne uzorne dizajne za proučavanje (D4). Svaka od ovih

komponeneti procesa razvoja je sa ostalima u meĎusobnom odnosu. Donešene odluke u

jednom području stvaraju uticaj na izbor i dostupne opcije u ostalim područjima.

1.1 Ciljevi

Cilj ovog projekta jeste izrada novog softvera gde ćemo njegovom aktivnom

primenom unaprediti kvalitet koji obezbeĎuje kompletnu tehničku podršku nakon puštanja

softverskih proizvoda u promet, odnosno program za aktivnosti odrţavanje tj.za

korektivno, adaptivno, perfektivno i preventivno odrţavanje na optimizovan način

odrţavanja softvera.



Uz stalno i redovno osveţavanje informacija na sajtu privlačit ćemo veliki broj

korisnika koji ţele nešto kupiti ili prodati.

1.2 Vizija

Posetioci Web stranice "Poslovno Inteligentna Simualaciona Arhitektura (PISA)"

zainteresovani su za korisne informacije, posebno ako one mogu odgovoriti na njihove

zahteve i ispuniti njihove specifične potrebe. TakoĎe ih privlači mogućnost da dobiju neki

poklon, da neku vrednu informaciju dobiju besplatno ili da se besplatno zabave, a to je

glavni razlog zbog koga će posećivati neko Web mesto. Privući će ih i laka registracija na

tom sajtu kao i lep izgled stranice sa uočljivim detaljima za lakšu interakciju.

Poboljšanjem interakcije izmeĎu čoveka i modernih tehnologija je bitna vizija koja

će ubrzati poslovanje i olakšati rad.

1.3 Misija

Implementacijom novog softverskog rešenja, PISA će doprineti brţem poslovanju,

uštedi novca i vremena. Lakom registracijom, brzom pretragom kao i širokim izborom

artikala privući ćemo veliki broj registrovanih korisnika koji na jednom mestu mogu naći

sve što im treba.

1.4 Analiza zahteva

Najznačajniji ciljevi savremenog poslovanja su postizanje poslovne izvrsnosti i

dostizanje svetske klase usluga. Ovako postavljeni ciljevi, u uslovima globalnog trţišta,

stvaraju preduslove za dugoročni rast i razvoj. Pitanje postizanja zadovoljstva

kupaca/korisnika usluga sajta PISA postaje jedno od ključnih pitanja daljeg razvoja.

Ovo potencira:

neophodnost razumevanja zahteva korisnika;

kreiranje i unapreĎivanje vrednosti usluga za korisnika;

adekvatna realizacija aktivnosti;

potreba za permanentnom inovacijom znanja.

Zadovoljstvo kupaca je globalni fenomen, a postizanje tog zadovoljstva na sajtu

PISA biće naš imperativ.

Prosto rečeno PISA je:

Precizno planiranje(resursa, troškova, trajanja, obuke kadra i td.)

Identifikaciju, procenu i kontrolu rizika na softverskom projektu

UtvrĎivanje merenja kvaliteta softverskog proizvoda

Kvantitativno upravljanje procesom testiranja tj. aktivnostima osiguranja

kvaliteta softvera u cilju povećanja efikasnosti otkrivanja grešaka u toku

razvoja softvera.



2. PISA - Poslovno Inteligentna Simualaciona Arhitektura

Slika 2.1 Novi logo PISA (Poslovno Inteligentna Simualaciona Arhitektura) kompanije

Evo kratkog opisa nivoa koncepta PISE. PISA se sastoji od 5 komponenti –

MNGR, OPST, MAINT, SIM, i BOX, dostupnih modularno ili kao sveobuhvatni paket

rešenja za upravljanje testiranjem. Okruţenje zа simulаciju scenаrijа rаzvojа kvаlitetnog

softverа koje omogucаvа minimizаciju troškovа i rizikа, izborom аlternаtivnih plаnovа

testirаnjа koji zаdovoljаvаju ogrаničenjа u pogledu slobodnih resursа, kriterijumа

optimаlnosti i performаnsi dаte kompаnije i ekonomski model kvаlitetа softverа zа ocenu

isplаtivosti predloţenih аktivnosti SQA, mere zа poboljšаnje PRS-PTS (Proces Razvoja

Softvera, Proces Testiranja Softvera) nа osnovu ekonomskih pаrаmetаrа. Razvoj softvera

troši više od polovine svog budţeta na aktivnosti povezane sa testiranjem u toku

projektovanja softvera i na odrţavanju softvera nakon njegove predaje na upotrebu.

Razvoj softvera obuhvata:

precizno planiranje (resursa, troškova, trajanja, obuka kadra I td.)

identifikaciju, procenu i kontrolu rizika na softverskom projektu

utvrĎivanje merenja kvaliteta softverskog proizvoda

Kvantitivno upravljanje procesom testiranja to jest aktivnostima osiguranja

kvaliteta softvera u cilju povećanja efikasnosti otkrivanja grešaka u toku

razvoja softvera.



Slika 2.2 Funkcije BISA-e

MNGR se nalazi u srcu BISA-e, obezbeĎuje integrisano i koherentno

upravljanje multidisciplinarnim aspektima operacija testiranja, omogućavajući naprednu

generaciju pravila testiranja. MNGR sadrţi SaaS-ove (Softwere as a Service) paradigme

pravila - koja će biti prvi industriski jezik scenarija za testiranje softvera sa lako

prilagodljivim unapred definisanim predloţcima pravila - za rešavanje kritičnih vektorskih

upravljanja testiranjem. TakoĎe, vaţna funkcija MNGR komponente je da pruţi sve

upitnike na projektu aktivnosti razvoja procesa i bitne stavke produktivnosti procesa radi

izračunavanja ograničenja procene rizika i radi postizanja odrţive procene odreĎenih

preduzeća i projekata.

SIM komponenta je nova mogućnost industrije koja omogućava simulaciju

pravila testiranja softvera na stvarne rezultate testa spremišta pre primene u proizvodnji.

SIM pomaţe u kvantifikovanju beneficija upravljanja projektom, prati raspored i izvršava

"šta ako" scenario za maksimalnu efikasnost i najbolji povraćaj ulaganja.

BOX će biti najbolja praksa univerzalne tehnika za testiranje softvera u

industriji, koja će biti spremljena za sve testere, probere, hendlere i kupljene softverske

alate za testiranje. BOX će biti potpuno nezavisna od procesa i ureĎaja, podrţavajući sve

nivoe paralelizma testiranja. Kao deo rešenja OptimalSQM-a, izvršavaće pravila koja su

kreirana i simuliraće ih i sprovodi za sve SDLC aktivnosti testa i završni test.



MAINT razmišlja o svim rezultatima testiranja radi poboljšanja kontrole

kvaliteta i upravljanja nad svim aspektima vaših operacija testiranja. MAINT vrši unakrsne

procene kvaliteta svih flota testiranja, za sve procene efikasnosti testiranja i otkrivanje i

otklanjanje defekata prinosa, nudeći ekstremni integritet podataka. Osim toga, MAINT

poboljšava pouzdanost softvera kroz SRE (pouzdanost metrike u predviĎanju i proceni

kritičnih faktora kao što su stopa početnih neuspeha, konačna stopa neuspeha, gustine

grešaka, profil greška itd) i druge napredne tehnike za otkrivanje izbora eksploatacije

dizajna na eksperimentalnom znanju. Na osnovu ovih podataka MAINT obezbeĎuje

kompletnu tehničku podršku nakon puštanja softverskih proizvoda u promet, odnosno

program za odrţavanje, za korektivno, adaptivno, perfektivno i preventivno odrţavanje

aktivnosti na optimizovan način.

OPST integriše skup centralizovanih rešenja operacija testiranja koja

omogućavaju Software Testing Center of Excellence za SMEs. On podrţava potrebu za

produktivnim i efikasnim upravljanjem testiranja dok precizno pronalazi neefikasnosti

omogućavajući brz odgovor. OPST pruţa kompletno planiranje, kontrolu, izvršavanje i

praćenje aktivnosti testiranja softvera i operacije završnog testa i izveštaje.

3. INTERAKCIJA KOMPONENTE OQT MAINT SA DRUGIM

KOMPONENTAMA

Slika 3.1. Interakcija komponente OQT OPST sa ostalim komponentama



3.1 Interakcija sa OQT MNGR komponentom

Slika 3.1.1 OQT MNGR paket OptimalSQM

OQT MNGR komponenta se nalazi u srcu PISA-e, obezbeĎuje integrisano i

koherentno upravljanje multidisciplinarnim aspektima operacija testiranja, omogućavajući

naprednu generaciju pravila testiranja.

MNGR sadrţi SaaS-ove (Softwere as a Service) paradigme pravila - koja će biti

prvi industriski jezik scenarija za testiranje softvera sa lako prilagodljivim unapred

definisanim predloţcima pravila - za rešavanje kritičnih vektorskih (preko 100

promenljivih) u procesu upravljanja testiranjem.

TakoĎe, vaţna funkcija MNGR komponente je da pruţi sve upitnike na projektu:

aktivnosti razvoja procesa i bitne stavke produktivnosti procesa radi izračunavanja

ograničenja procene rizika i radi postizanja odrţive procene odreĎenih preduzeća i

projekata.



3.2 Interakcija sa OQT SIM komponentom

Slika 3.2.1 OQT SIM paket OptimalSQM

OQT SIM komponenta simulira procese (scenarije) testiranje na osnovu

uspostavljenih pravila i algoritama koji su bazirani na empirijskim rezultatima testiranja,

kvalifikacijom potencijalne koristi ovih pravila pre primene. Zahvaljujući nadgledanju

planiranja, OQT-SIM takoĎe proverava poboljšanje kvaliteta i efikasnosti postojećih

pravila postavljenih tokom vremena, što omogućava poreĎenje stvarne koristi baziranih na

akumulaciji informacija u realnom svetu procesa testiranja za razne vrste softverskih

proizvoda, nivoa CMM i TMM zrelosti konkretne kompanije kojoj pruţamo servis.

OQT-Sim nudi tačno razumevanje stvarne koristi i ROI postavljenih pravila, pruţa

dokaz koncepta za više scenarija.

SIM nudi simulaciju šablona koji sadrţe algoritme iz različitih porodica softverskih

proizvoda, nivoa zrelosti softverskih kompanija, kao što su smanjenje vremena testiranja,

napredna statistička kontrola procesa, kvalitet i pouzdanost, dispozitiv i naknadna obrada.

Svaka familija stimulacije je bogata pravilima koji su posebna meta poslovnih potreba.

Potpuno integrisan sa svim drugim OQT-MNGR modelima, OQT-Sim omogućava

simulaciju pravila i postavljena pravila definisana u OQT-pravilima, koji onda mogu biti

objavljeni putem OQT-MNGR u realnom vremenu ili kasnijem radnom okruţenju.

Simulacioni tok je intuitivan, jednostavan za korišćenje i podrţan je jakom metodologijom.



3.3 Interakcija sa OQT BOX komponentom

Slika 3.3.1 OQT BOX paket OptimalSQM

OQT BOX je paket koji kao primarni cilj ima da se kvalitet softverskog proizvoda

usmerava ka obezbeĎenju što je moguće manje grešaka u softveru, njegovoj

funkcionalnosti koja zadovoljava ili prevazilazi očekivanja korisnika softvera. Aktivnost

testiranja softvera se normalno izvodi kao sredstvo pronalaţenja grešaka sa ciljem

njihovog odstranjivanja iz softverskog proizvoda.

Kao deo OptimalSQM rešenja, on ć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 stanica

za sve testere, rukovodioce i test programe. OQT-BOX je potpun process i nezavisan od

ureĎaja koji podrţava sve nivoe testiranja - i dostupan je kao samostalan proizvod ili deo

OQT-TMS-a, gde se izvršava u realnom vremenu po zadatom algoritmu i pravilima

kreiranim i objavljenim od strane OQT-MNGR.



3.4 Interakcija sa OQT OPST komponentom

Slika 3.4.1 OQT OPST paket OptimalSQM

Tim za planiranje i sprovoĎenje testiranja konkretnog razvijanog softvera

(OPeratinonal Software Testing), konkretne kompanije (Project Specific Software Testing)

imaće zadatak da na osnovu stvarnih performansi konkretne kompanije i konkretnog

projekta te kompanije i pronaĎenog optimalnog scenarija za dati projekat na bazi

REZULTATA izvršenih simulacija (OQT SIM komponente) mogućih 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 tačkama provere artifakata datog PTS (SDLC), odredi

adekvatne tehnike detekcije grešaka koje obezbeĎuju zahtevani kvalitet tokom razvoja

softverskog proizvoda u okvirima projektnih ograničenja tj. sve parametre IOPTS.



4. ANALIZA KONKURENTSKIH REŠENJA

Analizom konkurentskih rešenja koja postoje na trţistu moguće je pronaći prednosti

i mane njihovog pristupa testiranju. To nam moţe posluţiti da iskoristimo dobre ideje i

uradimo da se nedostaci, koji kod njih postoje, kod nas ne pojave ili da se smanji njihov

uticaj na najmanju moguću meru. Konkurentski proizvodi koje ćemo mi uporediti su

MPRO 2000, FastMaint i Mstar.

4.1 MaintSmart

Proizvod MaintSmart (http://www.maintsmart.com na ovom sajtu moţete se bolje

upoznati sa funkcijama ovog proizvoda i imate mogućnost preuzimanja proizvoda) je

preventivno namenjen za odrţavanje softvera za upravljanje sistemom "(CMMS softver) je

napravljen sa veoma jednostavnim interfejsom sa radnim nalozima, preventitivnim

odrţavanje softvera, upravljanja zalihama i još mnogo toga. MaintSmart je jedini softver

koji integriše pouzdanost analize (AMSAA vojni standard) u PM sistem pruţanja

optimizovane preventivne liste zadataka odrţavanja. MaintSmart radi kako bi sistem

obezbedio 8 različitih formata radnog naloga, automatski inventar delova koji povezuju,

osoblje više na svakom radnom nalogu, OPC povezivanje korisničkih definisanih metara

koji automatski kreira radne naloge zasnovane na očitavanja brojila. Upravljanje

odrţavanje rada je više nego jednostavno kreiranje radnih naloga i liste zadataka.

MaintSmart odrţavanje softvera za upravljanje prati dobra oprema zatim koristi ove

podatke da vam pomogne da optimizujete operaciju odrţavanja upravljanja. MaintSmart

CMMS softver se koristi širom sveta velikih proizvodnih preduzeća, vojska, obrazovanje,

gostoprimstvo i CMMS softver izbora u 35 zemalja.

MaintSmart proizvod ima razvijenu 6 Sigma metodologiju i poseduje Estimaciju

softvera koje se vrši u nekoliko faza.

4.1.1 Pokretanje MaintSmart

Slika 4.1.1.1 Početni izgled pokrenutog programa

http://www.maintsmart.com/



4.1.2 Kreiranje radnog naloga

Slika 4.1.2.1 Postupno, slikovito, obijašnjeno kreiranje naloga

4.2 MStar (Mosaic’s Structured Testing and Assessment Repository)

Prilikom izrade softvera moguće je doći do nekih grešaka koje će veoma uticati na

ugled firme u javnosti I na gubitak prihoda, zadovoljstva korisnika, ali I gubitka udela na

trţištu. Mozaik (http://www.mosaicinc.com/mosaicinc/html/mstar.html na ovom sajtu

moţete se bolje upoznati sa funkcijama ovog proizvoda i imate mogućnost preuzimanja

proizvoda) obezbeĎuje isplativo testiranje rešenja za upravljanje i minimizira rizik od

neuspeha softvera. Mozaik moţe dati pojedinačne specijaliste za testiranje da dopuni Vaš

http://www.mosaicinc.com/mosaicinc/html/mstar.html



tim test ili da daju ceo tim koji bi preuzeo odgovornost za funkcionalno i/ili testiranje

kritičnih performansi vašeg projekta. Tipična angaţovanja uključuju:

Testiranje sistema: Razvoj i testiranje sistema, zatim izrada planova za upravljanje rizikom

koji moţe dovesti do neuspeha.

Testiranje: Razvoj i izvršavanje testa planira da obezbedi sisteme koji bi ispunili zahteve

performansi.



Slika 4.2.1 Izgled MStar-а

Test automatizacije: Iskoristiti isplativa automatizovana rešenja za smanjenje troškova i

rizika od nastanka problema.

Test strategije podataka: Definisati i implementirati strategiju podataka testa da omoguci

ponavljanje, regresiju testova za višekratnu upotrebu dovoljno velike da zadovolji potrebe

upravljanja rizikom kako bi Vaš sistem evoluirao u susret poslovnim potrebama.

Prihvatljivo testiranje: Rad sa korisnicima kojim bi se definisalo i izvršilo testiranje

prihvatanja sistema kako bi se obezbedilo da poslovne potrebe korisnika budu ispunjene.

Testiranje unapređenje procesa: Sprovesti unapredjeno testiranje i test automatizivane

prakse kojim bi se obezbedila mogucnost za testiranje koja je potrebna da bi se zadovoljila

potreba za upravljanje rizikom.

Test LAB Podešavanja / Menadžmenta: Definisanje, implementacija i upravljanje testom u

okruţenju.

MStar poboljšava efikasnost testiranja i povecava mogucnost timu koji se bavi

testiranjem da identifikuje nedostatke dovoljno rano tako da ne postanu propust prilikom

izrade. MStar takodje obezbedjuje solidnu osnovu za automatizaciju testiranja - uključujuci

i testiranje performansi. Test automatizacije je sastavni deo MStar-a. Korisnici mogu da

pristupe smernicama i uzorcima za pravljenje testa automatizacije čija se strategija nalazi u

glavnoj MStar bazi. Alternativno, korisnici mogu da pristupe projektu za isporuku da bi

pronašli planove, standarde, zahteve, testiranje planova i skripte u vezi sa njihovim

pecifičnim projektom. Ovo obezbeĎuje centralizovano mesto za pristup svim testiranjima.

4.3 FastMaint

CMMS FastMaint (http://www.smglobal.com na ovom sajtu moţete se bolje

upoznati sa funkcijama ovog proizvoda i imate mogućnost preuzimanja proizvoda)

Odrţavanje softvera je softver pogodan za upravljanje kako neplaniranih tako i planiranih

radnih naloga odrţavanja. On je projektovan tako da bude brz za podešavanje i korišćenje,

bez potrebnog treninga. Dostupan je za jednog (Osnovna / Standardna izdanja) ili za više

korisnika. FastMaint proizvod ima razvijenu 6 Sigma metodologiju i poseduje Estimaciju

softvera koje se vrši u nekoliko faza.

Ključne karakteristike FastMainta:

Podrţava rad više korisnika;

Ograničena prava od stane korisnika ili grupe (zaštita osetljivih podataka);

Web bazirani rad zahteva modula (add-on) (mogućnost korišćenja web pretraţivača

za podnošenje zahtevaza rad i proveru statusa radnog naloga;

Email ili text radna nareĎenja isključivo za odrţavanja softvera;

Email ili text (SMS) obaveštenja o radu predaje zahteva i prerade (sa web radnog

zahteva modula);

Proces poštom ili tekstualnim porukamaradnog naloga. Ispravke odrţavanja

osoblja.

Automatsko generisanje izveštaja i e-mejlova;

Mogućnost pravljenja šablona zadataka za neplanirano i planirano odrţavanje

radnih naloga. Smanjiti unos podataka kreiranjem sličnih radnih naloga;



Raspored odrţavanja po datumima, očitavanje brojila ili alarmnim uslovima na

opremi. Automatski prilagodi termin radnog naloga u slučaju praznika.

Podrţava ubacivanja slika i linkova ka drugim dokumentima u radnim nalozima;

Omogućuje Vam da definišete svoja prilagoĎena polja na radnim nalozima,

opreme, delova i tako dalje

Prilikom prvog startovanja programa FastMaint dobija se sledeći prozor:

Slika 4.3.1 Početni prozor FastMaint-a

Glavni program prikazan na slici je vaša polazna tačka u sistemu. Iz glavnog

programa moguće je:

Kreiranje i aţuriranje radnih naloga o opremi ili loaciji;

Pregledanje različitih izveštaja kao što su svi izvedeni radovi na opremi, do

radnih naloga, troškova odrţavanja i tako dalje;

Praćenje odrţavanja na osnovu opreme, lokacije i drugih sredstava;

Praćenje potrošnje i troškova odrţavanja rezervi, pravljenje poruĎbina i tako

dalje;

Kreiranje hijerarhiskog stabla opreme da bi lakše pratili i rasporedili

odrţavanjem itd.



Slika 4.3.2 Opis radnog naloga

Oprema (Equipment) predstavlja sredstvo na kojem se zahteva odrţavanje. Neke

od stvari koje moţete da uradite su:

Radni nalozi (Work Orders): lako pregledanje aţuriranje celog uraĎenog

posla na opremi;

Delovi (Parts): pretraga delova potrebnih za opremu;

Alarm: definisanje brojača ako je potrebno da se zakaţe nareĎenje za radne

zadatke;

Zahtevi kvarova (Requests/Breakdowns): lako zakazati neplanirano

odrţavanje;

Oprema log (Equipment log): unos ostale informacije na primer časopis,

operatorske komentare;

Ostalo (Others): kreiranje sopstvenih polja na primer garancije datumima,

nabavna cena i tako dalje.

Lokacije (locations) mogu predstavljati zgrade, prostorije i tako dalje u vašoj

ustanovi. Oni vam pomaţu da organizujete i upravljate vašim objektima za odrţavanje.

Neke od stvari koje moţete da uradite:

Radni nalozi (Work Orders): lako pregledanje odţavanje svog uraĎenog

posla na lokaciji;

Opreme (Eguipment): upravljanje opremom na lokaciji;

Delovi (Parts): praćenje delova (ako ih ima) sačuvanih na lokaciji;

Ostalo (Others): kreiranje sopstvenih polja na primer brojeva telefona,

troškova centara i tako dalje.



Zadaci (Tasks) su šabloni za preventivno odrţavanje radnih naloga. Grupa za

odrţavanje radnih mesta u ponovljenim zadacima. Omogućava uštedu vremena i smanjeno

ponavljanje unosa podataka. Prednost korišćenja zadataka:

Identifikacija i klasifikacija standardnih postupaka odrţavanja.

Pruţa isti interfejs za upravljanje planiranim i neplaniranim odrţavanjem.

Ušteda vremena za stvaranje budućih radnih naloga (mnogo informacija se

kopira iz zadataka).

Mogućnost korišćenja moćnog modula za planiranje da sakupi, planira i

rasporedi aktivnosti odrţavanja.

Hvatanje najboljih praksi (u zadatom uputstvu) iz radnog naloga.

Organizacija klasifikacija radnih rezultata dovodi do bolje analize i

identifikacije područja za poboljšanje.

Održavanje radnih naloga za planirano i neplanirano održavanje (Maintenance

work orders for planned and unplanned maintenance) stvoreni su van zadatih šablona na

osnovu zadatih frekvencija podešavanja. Radni nalozi su unapred popunjeni sa

informacijama iz zadataka smanjujući unos podataka i olakšavajući da se setite šta treba da

se uradi. Promene u radnom nalogu mogu biti da odrţava različite

opreme/delove/zaposlene sa zadatkom. Dakle ako je za radni nalog potrebno manje delova

nego za precizirani zadatak moţete veličinu podesiti na radni nalog.

Delovi/rezervni delovi (Parts/Spares) sluţe za efikasno odrţavanje sistema

upravljanja, pomaţe jedinstveno praćenje rezervnih delova koji se koriste za odrţavanje

opreme. Stručnjaci kaţu da je za efikasno upravljenje zalihama proizvoda oko 50%

zasluţno korišćenje odrţavanje softvera za upravljanje. FastMaint omogućava povezivanje

delova sa zadacima i radnim nalozima. Beleţi rezervne delove, proizvoĎače oprema i

delova, obezbeĎuje podršku za kreiranje naruĎbine i praćenje njihovog statusa. FastMaint

takoĎe pruţa niz izveštaja (delova za ponovni rad, deo istorije upotrebe i tako dalje).

Proizvođači/dobavljači (Vendors/Suppliers), FastMaint vam omogućava da

poveţete dobavljača sa rezervnim delovima i opremom. Moţete da odredite jedan ili više

kontakta za razne usluge prodaje, na primer garantna podrška, ţalba i tako dalje. Polje

Vendor Rating je odličan način da označite ţeljene dobavljače za delove. Kupovina naloga

moţe biti kreirana za prodavce.

Osoblje za održavanje (Maintenance team), ovde imate mogućnost da unesete

podatke o vašem timu za odrţavanje (osoblje, tehničari, ugovarači) koji će završiti posao

odrţavanja. Moguće je uneti informacije o radnim danima, plati, kontakt informacije i tako

dalje. Svaka osoba moţe imati drugačije radno vreme, na primer “Full Time Employee”

kalendar, “Part Time Employee” calendar i tako dalje. Satnice se koriste za izračunavanje

troškova radne snage za odreĎenog radnika.

Plan održavanja – kreiranje dnevnih i nedeljnih planova rada (Maintenance

Planning – Create dailz/weekly work plans), planiranje izveštaja olakšava kreiranje radnih

planova i email/print radne naloge za bilo koji navedeni period. Moţete da prilagodite

izveštaj i štampani rad da odgovaraju vašim potrebama.



Izveštaj dizajnera (Report Designer) vam omogućava da kreirate prilagoĎene

izveštaje koristeći poznatu WYSIWYG obradu okruţenja. Moţete koristiti

postojećeizveštaje kao predloge za kreiranje prilagoĎenih izveštaja. PrilagoĎeni izveštaji

koje kreirate mogu biti dostupni drugim korisnicima ili samo za sopstvenu upotrebu.

4.4 Primena Nielsen – ovih pravila

Kriterijum po kojem smo ocenili ova tri softvera su Nilsenova pravila. Nilsenova

pravila se koriste kada treba da se oceni upotrebljivost neke aplikacije ili sistema.

Nilsenova pravila se sastoje od deset pravila koje mi navodimo i ujedno ocenjujemo naša

tri slučaja:

1. Softver mora da odgovora realnom svetu.

MaintSmart zadovoljava prvo Nielsen-ovo pravilo, jer su fajlovi i strukture

podataka skriveni od krajnih korisnika.

FastMaint zadovoljava prvo Nielsen-ovo pravilo, jer su fajlovi i strukture

podataka skriveni od krajnih korisnika.

MStar zadovoljava prvo Nielsen-ovo pravilo. Sve radnje izvršavaju se u realnom

vremenu.

2. Konzitentnost i standardi

MaintSmart zadovoljava drugo Nielsen-ovo pravilo jer su operacije

kooperativne, klikom na ikonicu MaintSmart automatski pristupamo programu.

Softveru moţemo pristupiti i selektovanjem ikonice a zatim klikom na taster

ENTER pristupiti korisničkom interfejsu softvera. TakoĎe je omogućeno

koršćenje standarda na koje su korisnici naviknuti. Nedostatak je nepostojanje

prečica.

FastMaint zadovoljava drugo Nielsen-ovo pravilo jer su operacije kooperativne,

klikom na ikonicu MaintSmart automatski pristupamo programu. Softveru

moţemo pristupiti i selektovanjem ikonice a zatim klikom na taster ENETER

pristupiti korisničkom interfejsu softvera. TakoĎe je omogućeno koršćenje

standarda na koje su korisnici naviknuti. Poseduje prečice koje iskusniji

korisnicima omogućavaju brţi.

MStar zadovoljava drugo Nielsenovo pravilo, poput gore navedena dva

softvera. TakoĎe test automatizacije je sastavni deo ovog softvera. Test

automatizacije integriše proces planiranja testa i olakšava njegovu primenu

tamo gde je potrebno da se poboljša efikasnost testiranja.



3. Pomoć i dokumentacija

MaintSmart zadovoljava treće Nielsen-ovo pravilo jer obezbeĎuje objašnjenje

grešaka i pomoć zasnovanu na sadrţaju.

FastMaint zadovoljava treće Nielsen-ovo pravilo jer Sistem za pomoć

omogućava pretraţivanje, prepoznavanje sadrţaja, orijentisano prema

zadacima, konkretno, kratko.

MStar zadovoljava treće Nielsen-ovo pravilo. Poseduje onlain pomoć i dosta

pomaţe u radu korisnika.

4. Sloboda korisnika

MaintSmart zadovoljava četvrto Nielsen-ovo pravilo jer duge operacije imaju

mogućnost prekida i svi dijalozi imaju dugme Cancel.

FastMaint zadovoljava četvrto Nilsen-ovo pravilo, isto kao i MaintSmart.

MStar zadovoljava četvrto Nilsen-ovo pravilo, korisnici su integrisani u procesu

testiranja.

5. Vidljivost statusa sistema

MaintSmart nezadovoljava peto Nielsen-ovo pravilo. Sve akcije i alati nisu

jasno vidljivi.

FastMaint zadovoljava peto Nilsen-ovo pravilo, Podrţava mod rada drag/drop,

obeleţavanje selektovanih objekata i td. Boje su dobro usaglašene i alati su

jasno vidljivi i dostupni.

MStar zadovoljava peto Nielsenovo pravilo. Podrţava mod rada drag/drop,

obeleţavanje selektovanih objekata i td.

6. Fleksibilnost i efikasnost

MaintSmart nezadovoljava šesto Nielsen-ovo pravilo nije fleksibilan u

njegovom GUI ne postoje prečice za operacije koje se najčešće koriste kako bi

olakšale rad korisnika.

FastMaint zadovoljava šesto Nielsen-ovo pravilo to jest softver je fleksibilan i

efikasan. TakoĎe postoji istorija najčešće korišćenih operacija.

MStar nezadovoljava šesto Nielsen-ovo pravilo. Ovo resenje u pogledu

odrţavanja softvera nema svoj odredjen deo koji se bavi time i to predstavlja

njegov veliki nedostatak.



7. Prevencija grešaka

MaintSmart zadovoljava sedmo Nielsen-ovo pravilo jer su zabranjene nelegalne

komande. Ako korisnik pogreši u radu i pritisne nelegalnu komandu neće se

aktivirati poruka koja će korisnika obavestiti da obustavi operaciju

FastMaint nezadovoljava sedmo Nielsen-ovo pravilo, nelegalne komande nisu

propisno zabranjene. Ako korisnik pogreši u radu i pritisne nelegalnu komandu

neće se aktivirati poruka koja će korisnika obavestiti da obustavi operaciju.

Mstar poput MaintSmart zadovoljava sedmo Nielsen-ovo pravilo.

8. Minimizovati rad sa memorijom

MaintSmart zadovoljava osmo Nielsen-ovo pravilo, koristi menije a ne

komandni jezik, koristiti generičke komande uvek gde je moguće (Open, Save,

Copy), sve informacije su dostubne i jasno vidljive.

FastMaint nezadovoljava osmo Nielsen-ovo pravilo, kao i MaintSmart. Ne

koristi polja za potvrdu umesto tekst polja.

MStar zadovoljava osmo Nielsenovo pravilo.

9. Izveštaj, dijagnoza i oporavak greški

MaintSmart zadovoljava deveto Nielsen-ovo pravilo. Predlaţe konstruktivnu

pomoć zašto se greška dogodila i kako je otkloniti, takoĎe ne koristiti poruke

kao što sufatal error ili illegal.

FastMaint zadovoljava deveto Nielsen-ovo pravilo. Predlaţe konstruktivnu

pomoć zašto se greška dogodila i kako je otkloniti. Ne koristi koristiti poruke

kao što sufatal, error ili illegal, i pritom poseduje bogat help sadrţaj. Sakriveni

su tehničke detalje, dok ih korisnik ne zatraţi.

MStar zadovoljava deveto Nielsen-ovo pravilo. Testiranje softvera je

fokusirano na način koji će doneti najbolje poboljšanje. Informacije Analize

kvara se koriste da bi se usaglasila strategija pokrivenosti rizika, predvideli

rasporedi i stekao uvid u pitanja razvoja i u probleme.

10. Estetski i minimalni dizajn

MaintSmart nezadovoljava deseto Nielsen-ovo pravilo. Boje i labele nisu dobro

izabrane.

FastMaint zadovoljava deseto Nielsen-ovo pravilo. Korišćen je koncizan jezik,

boje i labele su paţljivo birane i ikonice imaju standardne simbole.



MStar zadovoljava deseto Nielsen-ovo pravilo. Korišćen je koncizan jezik.

Koristi nekoliko, dobro izabranih boja i fontova grupisanih sa belim razmakom.

Labele su paţljivo birane.

Tabela 4.4.1 Nielsen - ova pravila

NIELSEN - OVA PRAVILA MStar MaintSmart FastMaint

1. Slaganje izmeĎu sistema i

realnog sveta

2. Konzistentnost i standardi





7. Prevencije greške

8. Minimizovati rad sa

Memorijom

9. Izveštaj dijagnoza i popravka

grešaka

10. Estetski i minimalistički dizajn

5. STUDIJA IZVODLJIVOSTI

U ovom poglavlju ćemo razmatrati pitanje izvodljivosti projekta sa aspekta

operativne, tehničke i ekonomske izvodljivosti. U cilju predočavanja realne situacije našem

klijentu izvršit ćemo realnu ocenu svih faktora koji su od ključne vaţnosti.

5.1 Kriterijumi izvodljivosti

Operativna izvodljivost - odnosi se na to kako će rešenje stvarno

funkcionisati u praksi, i koliko će korisnici biti zadovoljni korišćenjem sistema

(udeo od 25% u konačnoj oceni).

MStar je dosta lak za registraciju korisnika. Svi artikli su dobro rasporeĎeni po

kategorijama, ali ima dosta nepreglednu naslovnu stranu.70 poena.

FastMaint poseduje dobru klasifikaciju artikala po kategorijama i najlakši je za

korišćenje jer ima dosta pregledan glavni meni. Ovaj sistem ima probnu (trial) verziju.

90 poena.



MaintSmart odrţavanje softvera za upravljanje prati dobra oprema zatim koristi

podatke da vam pomogne da optimizujete operaciju odrţavanja upravljanja. 65 poena.

Slika 5.1.1 Dijagram operativne izvodljivosti

Tehnička izvodljivost odnosi se na funkcionalnost i praktičnost tehničkog

rešenja u okviru raspoloţivih tehničkih resursa. (25% udeo).

MStar zahteva sistem za distribuirano računarstvo, računarsku mreţu, oracle bazu,

redhat servere, deseto-gigabitne mreţe unutar lana, sistem za back up podataka 85 poena.

FastMaint zahteva IBM mainframe računare, redhat servere, sistem za back up

podataka 70 poena.

MaintSmart windows servere, IBM mainframe računare, DB2, sistem za back up

podataka 60.5 poena.

Slika 5.1.2 Dijagram tehničke izvodljivosti



Vremenska izvodljivost- realnost rokova u projektu (udeo od 25% u konačnoj

ceni)

Za izradu MaintSmart sistema potrebno je 7 meseci. 83.5poena.

Za izradu FastMaint sistema potrebno je 10 meseci. 72.5poena.

Za izradu MStar sistema potrebno je 11 meseci. 70poena.

Slika 5.1.3 Dijagram vremenske izvodljivosti

Ekonomska izvodljivost- odnosi troškova projekata (udeo od 25% u konačnoj

ceni).

Za FastMaint potrebno je:

četiri programera 35$/h,

jedan dizajner 40$/h,

nemaju skladište,

jedan sistem administrator 45$/h,

jedan mreţni administrator 60$/h,

administrator baze podataka 55$/h.

Ukupno 120.000$ za 10 meseci. 85 poena

Za MStar potrebno je:

pet programera 50$/h,

dva dizajnera 35$/h,

nemaju skladište,

dva sistem administratora 50$/h,




Za MaintSmart potrebno je:

tri programera 35$/h,

jedan dizajner 35$/h,

nemaju skladište,

dva sistem administratora 45$/h,






Slika 5.1.4 Dijagram ekonomske izvodljivosti

UKUPNA OCENA (100% udeo):

MStar= 0.25 ∗ 90 + 0.25 ∗ 85 + 0.25 ∗ 70 + 0.25 ∗ 80 FastMaint = 0.25 ∗ 70 + 0.25 ∗ 70 + 0.25 ∗ 72.5 + 0.25 ∗ 85 MaintSmart = 0.25 ∗ 65 + 0.25 ∗ 60.5 + 0.25 ∗ 83.5 + 0.25 ∗ 95

Slika 5.1.5 Dijagram ukupne izvodljivosti



6. MAINT FUNKCIJA

OQT MAINT funkcija je zaduţena za odrţavanje softvera. Odrţavanje obuhvata

modifikaciju i dopune programa nakon što je pušten u upotrebu. Odrţavanje ne bi trebalo

da uključuje velike promene na arhitekturi sistema. Promene se implementiraju

modifikovanjem postojećih komponenti i dodavanjem novih komponenti u sistem. Zahtevi

za odrţavanjem su sastavni deo svakog ugovaranja posla.

Odrţavanje isporučenog softverskog sistema obično zahteva više vremena i

sredstava od same realizacije i implementacije sistema. Moguće je angaţovanje razvojnog

ili posebno formiranog tima na odrţavanju. Odrţavanje obuhvata:

ispravljanje grešaka

prilagoĎavanje novom operativnom okruţenju

dodavanje novih funkcionalnosti.

Ako odrţavanje sistema ne moţe da se sprovede u skladu sa gore navedenim

zahtevima, postavlja se pitanje opravdanosti i dalje upotrebljivosti čitavog sistema.

6.1 IOP Maintance Engine

OptimalSQM će svojim klijentima preko OQT MAINT funkcije ponuditi sledeće

kategorije odrţavanja aplikativnog softvera:

Korektivno, podrazumeva isprvaljanje grešaka pronaĎenih u softveru i

otklanjanje uzroka zastoja u radu sistema.

Preventivno, podrazumeva praćenje i podešavanje svih parametara sistema koji

utiču na rad aplikacije i sprečavanje eventualnih problema u radu pre nego se

pojave.

Adaptivno, odrţavanje inicirano promenama u softverskoj okolini (novi hardver,

novi sistemski softver) i izmene programa u skladu sa novim zakonskim

propisima ili promenama u internoj regulativi korisnika softvera koji suštinski ne

menjaju bazu podataka i instaliranu aplikaciju.

Perfektivno, predstavlja sve izmene modula koje nisu greške u radu sistema i

koje ne spadaju u adaptivno odrţavanje, a imaju za cilj poboljšanje postojećih

funkcija, te se odnosi na promene softvera kako bi se udovoljilo novim i

modifikovanim potrebama korisnika – koje suštinski ne menjaju bazu podataka i

instaliranu aplikaciju.

Troškovi, razumevanje kategorija softverskog odrţavanja pomaţe u razumevanju

strukture troškova softverskog odrţavanja. TakoĎe, razumevanje faktora koji utiču

na lakoću odrţavanja sistema moţe pomoći u sagledavanju troškova. Neki od

tehničkih i netehničkih faktora koji utiču na troškove softverskog odrţavanja su:

tip aplikacije, noviteti u softveru (Software novelty), raspoloţivost osoblja za

odrţavanje, hardverske karakteristike, kvalitet dizajna, konstrukcije,

dokumentacije i testiranja.



Slika 6.1.1 IOP Maintance Engine

6.2 Šest Sigma Engine

Od devedesetih godina XX veka sve šire se primenjuje popularni metod sa

skromnim nazivom „šest sigma“. Kao modni hit metod se koristi za unapreĎenje kvaliteta

proizvoda i poslovanja kompanija. Metod nosi različite atribute poput: magija i filozofija

kvaliteta, put ka hramu biznisa, vizija koja stremi savršenstvu itd. Šest sigma je

unapreĎenje biznisa zasnovano na pronalaţenju i eliminisanju grešaka i uzroka pojave

grešaka ili defekata u biznisu (procesima), usredsreĎivanjem paţnje na izlazne parametre,

kritično vaţne za kupca ili korisnika. Šest sigma je strategijski prilaz za sve procese,

proizvode i kompanije. Prilaz je prva razvila kompanija Motorola, čiji su proizvodi poznati

kao trţna marka (brend). Trend sve veće primene metoda 6 sigma izazvan je ekonomskim

dostignućima Motorole.

Kompanija Allied Signal je ukazala na efekat od 800 miliona dolara, ostvaren od

1995. - 1997. na račun usavršavanja po principima šest sigma. Kompanija General Electrik

(GE) je, u trećem kvartalu 1997., ostvarila efekat od oko 600 miliona dolara (povećanje sa

13,8 % na 14,5 %), isključivo zahvaljujući inicijativi šest sigma. Kratka informacija

pokazuje da je metod šest sigma, kompaniji GE, u 1999. obezbedio efekat više od 2

milijarde dolara. Zato kompanija GE kaţe da je šest sigma vizija kvaliteta izraţena kroz

svega 3,4 defekta na milion mogućnosti za svaku proizvodnju ili uslugu. Primena

metodologije i koncepta 6 sigma pokazala je tesnu povezanost i sa finansijskim rezultatima

rada kompanija. Prema tim rezultatima kompanije se, u svetskim razmerama, i razvrstavaju

na svetsku klasu, srednju klasu i nekonkurentne.

''Šest sigma metodologija'' je, u osnovi, usmerena na:

Poboljšavanje satisfakcije (zadovoljstva) korisnika (kupaca),

Skraćenje vremena izrade proizvoda (smanjenje siklusnog vremena) i

Smanjenje broja defekata (grešaka) na proizvodima i uslugama.



UnapreĎenja u ove tri oblasti obezbeĎuju visok nivo kvaliteta proizvoda, velike

uštede i visok profit kompanijama, zadrţavanje postojećih korisnika/kupaca, osvajanje

novih trţišta i podizanje nivoa ugleda i imidţa kompanija. Ovakvi ciljevi zahtevaju

značajna poboljšavanja i napredak u svim procesima kompanije.

Osnovni ciljevi koncepcije „šest sigma“, u statističkom smislu, su:

1. eliminisati defekte i

2. minimizirati varijacije procesa.

Naime, koncepcija 6 Sigma ne zasniva se toliko na broju defekata na milion mogućnosti

(tabela 2), koliko na postupku postepenog smanjenja rasipanja procesa. Time se, prema

Tagučiju, smanjuju gubici (slika 3) i povećava profit.

Koncepcija šest sigma obezbeĎuje za:

korisnike (klijente) - visok nivo kvaliteta i nisku cenu (punu satisfakciju),

akcionare - povećanje profita,

menađere – nove mogćnosti dostizanja uspeha i ostvarivanja ciljeva i

saradnike (izvršioce) - otkrivanje širokih mogućnosti unapreĎenja rada i

pruţanje zadovoljstva, ponosa i gordosti u ispunjenju zadataka.

Slika 6.2.1.1 Faze Šest Sigma metodologije



Merenje, primenom odgovarajućih metoda i metrike, obezbeĎujemo prikupljanje

podataka i informacija o tekućem stanju. Na osnovu informacija i podataka ocenjuje se

bazni nivo pokazatelja rada i izdvajaju problemi koji zahtevaju najveću paţnju.

Kroz analizu identifikuju se osnovni (glavni) uzroci problema obezbeĎenja

kvaliteta, uz proveru podataka, primenom specijalnih alata analize podataka.

Na četvrtoj etapi, unapređenje, uvode se rešenja orijentisana na otklanjanje

problema (osnovnih uzroka) utvrĎenih tokom analize. Rešenja mogu biti sredstva

upravljanja projektima i drugi alati planiranja i upravljanja kvalitetom.

Cilj pete etape, kontrola, je ocena i monitoring rezultata prethodnih faza. Na etapi

se potkrepljuje (verifikuje) modifikacija sistema stimulacije i stvara skup novih pravila,

procedura, instrukcija zaposlenim i drugih normi.

Slika 6.2.1.2 DMAIC ciklus uvoĎenja 6 Sigma

Svaka od navedenih etapa pretpostavlja primenu specijalnih analitičkih računskih

metoda iz širokog spiska metoda preporučenih ne samo za 6 sigma, već i za menadţment

kvalitetom. Izbor konkretnih metoda odreĎen je preradom procesa.

6.3 Razvojni postupci – EVOP

Box G.E.P je davno predloţio korišćenje Razvojne Methode-EVOP (Evolutionary

OPeration) za neprekidno poboljšanje industrijskih procesa. Osnova ove filozofije je da je

nefikasno proizvoditi samo proizvod, odnosno proces pored proizvoda proizvodi i

informacije o tome kako ga poboljšati. EVOP methodologija koristi paţljivo planirane

male promene u procesnim faktorima standardnog procesa, koje se rutinski ponavljaju do

završetka jednog ciklusa promena.



Efekti ovako malih promena procesnih faktora su nevidljivi jer su maskirani

velikom greškom-šumom industrijskog procesa. MeĎutim, pošto se proizvod proizvodi

neprekidno to znači da će se ponavljati i male planirane promene (koje nemaju značajan

efekat na proces u kratkom periodu), teorijski beskonačno a to ponavljanje omogućiće da

efekti malih promena procesnih faktora postanu statistički značajni.

6.4 Estimator Engine

Estimacija softvera se vrši u šest dimenzija o kojima će u narednom testu biti reč:

1. Dimenzija - Definisanje estimacionog modela pod-ciljeva

Ovde menadţeri mogu da pokušaju da procene trajanje i cenu direktno, ili mogu

podeliti proces u nekoliko pod-ciljeva, prema proceni veličine i napora. Ovde se treba

brinuti da li podatak sadrţi srednju meru i tamo gde je najveća varijacija verovatno je da će

se desiti neki dogaĎaj . Projektni menadţeri treba da budu sposobni da se prilagode prema

nekim procenama uvaţavanja produktivnosti. Boehm, na primer, zalaţe višestepeni model:

𝑇𝑟𝑢𝑑 = 𝑎 𝑣𝑒𝑙𝑖č𝑖𝑛𝑎𝑏 𝑖 𝑇𝑟𝑎𝑗𝑎𝑛𝑗𝑒 = 𝑐 𝑡𝑟𝑢𝑑𝑑

gde tipična vrednosti za b (malo veca, gde je povecana veličina povezana sa vec_im

sloţenošču i teškoc_om, ili malo niţa gde postoJi efekat učenja tokom projekta kao i

ekonomija obima). Parametar a (odraţavanje produktivnosti) i c (koji predstavlja

mogucnost za koordinaciju članova tima kad se rade paralelni zadaci) zavise od mernih

jedinica. Troškovi se generalno slaţu s linearnom funkcijom napora.

2. Dimenzija - Podela na faze projekta (makro u odnosu na mikro procenu)

Nezavisno od modela procene pod-ciljeva, postoji potreba da se utvrdi stepen

podele projekta. To je, veličina i tip projekta, zajedno sa nivoom detalja dostupnih

podataka razvojnog sistema koji će dovesti do izbora izmeĎu dve opcije,da se vrši procena

odozgo nadole ili obrnuto.

Izbor za početnu procenu je:

jedinstvena estimacija celog projekta

definisanje nekoliko faza zasnovanih na nekim razvojnim paradigmama, a

zatim izvršiti mikro procenu svakog od njih.

3. Dimenzija- Podela na komponente proizvoda

Nezavisno od estimacije pod-ciljeva i faza projekta, postoji mogucnost razmatranja

celog softverskog sistema, kao monolitni entiteta ili estimacija komponenti pojedinačno.

Opet će to biti odredeno u zavisnosti od ukupne veličine projekta i dostupnosti podataka o

komponentama od drugih projekata. Proizvod je podeljen u više pod-sistema, verovatno

koristeći Vork Breakdovn strukturu, a potom agregaciju pojedinačnih estimacija. Ovo je

posebno korisno za inkrementalne estimacije. U zamenu za dodatni napor, to je osnova za

davanje više detalja i kontrolu-upravljanja.



4. Dimenzija - Rukovanje neizvesnošću

Jasno je da je korisno imati domen greške izraţen kao deo estimacije. Mnoge

metode i alati obezbeĎuju to, ali neki ne. Postoji značajna razlika izmeĎu menadţera koji

kaţe da će projekat trajati 27 meseci i drugog koji kaţe 27 meseci ili manje jedan mesec.

Sa druge strane, tu je interval poverenja, sigurno na osnovu procene rizika projekta.

5. Dimenzija – Osnova računarskog modela

Ovaj faktor se bavi načinom na koji se upravlja ulazima procesa estimacije. Ovi

ulazi mogu da predstavljaju atribute (veličina, kompleksnost) od sistema ili ţivotnu sredinu

i produktivnost faktora koji se generalno odnosi na drajvere. Ulazi ili drajver metod

estimacija moţe biti izvedena u skladu sa:

Aditivnim modelom koji je uglavnom previše pojednostavljen, ali praktično

koristan

Multiplikativni model koji je takoĎe ograničen brojem pretpostavki, ali koji

generalno upravlja interakcijom bolje

Tabela - pogon metod koji se obično koristi kod analize vaţnih zahteva

velikog broja projekata i zbog toga moţe biti neprikladan za male softverske

organizacije.

6. Dimenzija -Tehnika estimacije

Poslednji faktor koji se bavi problematikom produktivnosti, veličinom, naporom,

trajanjem ili procenom troškova. Suština ove dimenzije je način na koji je znanje od

prošlih projekata sačuvano i prilagoĎeno za osmišljanje sledećeg projekta. Ovo moţe da

varira, jer zavisi od čisto subjektivnog oslanjanja na memoriju osobe da se potpuno

realizuje upotreba prošlih podataka. Tako svaki nivo obično predstavlja neko povec_anje

matematičke sofisticiranosti. To je faktor koji je najšire istraţen i sadrţan u softverskim

tekstovima inţenjering upravljanja.

6.5 DOE Engine

Design of Experiments (DOE) je metodologija koja je efektivna za opšte

rešavanje problema, kao i za poboljšanje ili optimizaciju dizajna proizvoda i proizvodnih

procesa. Specifična primena DOE uključuje identifikaciju podesnih dimenzija dizajna i

tolerancija, postizanje robusnog dizajna, generisanjem predvidivih matematičkih modela

koji opisuju ponašanje fizičkog sistema i odreĎivanje postavljanja idealne proizvodnje.

Koristi: obezbeđuje dokumentovane suštinske uštede za hiljade kompanija

rešavanjem teških problema u kvalitetu, smanjuje varijaciju proizvoda i procesa i

optimizira performanse i konzistenciju proizvoda / procesa.

Design of Experiment (DOE) – metodologija za dizajniranje proizvoda i procesa

nivoa kvaliteta 6 sigma.



Dato je sedam koraka za uspešan DOE:

1. Definisati cilj eksperimenta: Šta sve konkretno pokušavamo da postignemo?

2. Definisanje odgovora (kvalitativne karakteristike) koji će se meriti i kojim

kriterijumima.

3. Odlučite koji faktori ce biti ispitivani u DOE. Nabavite kolege, tehničke

profesionalce s kojima će te meĎusobno razmenjivati ideje, to će verovatno

dovesti do veoma velikog broja potencijalnih promenljivih.

4. Izaberite dizajn koji će dati ţeljene količine informacija u razumnom broju.

Prilikom vašeg prvog dizajna, pokušajte da identifikujete sve glavne efekte i

interakcije onoliko koliko moţete u okviru ograničenja na vreme, materijal,

troškove i dr.

5. Kada je izabran dizajn, potraţite kombinacije uslova koji se ne mogu ispuniti.

TakoĎe, paţljivo razmislite o logistici, kao šta ljudi treba da urade eksperiment

i dostupnost testiranja opreme.

6. U ovom trenutku, DOE moţe da se pokrene. U toku svog izvršenja očekuju

nezgoda ili dva. Tada se isplati postojanje statističkih eksperata dostupanih u

veoma kratkom roku.

7. Nakon što se podaci prikupe, analiza počinje. Više pitanja će se pojaviti, ali se

nadamo da će se poboljšanja pojaviti.

Vrlo je verovatno da se ovaj proces ponovi dva do tri puta pre nego što doĎe do

optimalnih uslova rada.

6.6 Reliability expert

Jedan od vaţnih elemenata u proceni kvaliteta gotovog softverskog proizvoda jeste

njegova pouzdanost. Pouzdanost kao svojstvo sistema često se poistovećuje sa pojmom

poverenje u sistem. Naime, svaki korisnik ţeli pouzdan softver, odnosno ţeli da u softver

moţe imati poverenja da će on kontinuirano funkcionisati u normalnim okolnostima u

skladu sa zahtevima koji su postavljeni pri stvaranju sastava.

Kvalitet softvera moţemo analizirati kroz kategorije kao što su: raspoloţivost,

pouzdanost, sigurnost, zaštita. U tom smislu:

Raspoloţivost softvera iskazuje se kroz sposobnost softvera da obavlja

funkcije koje se od njega traţe ili očekuju,

Pouzdanost softvera iskazuje se kroz sposobnost softvera da pruţa usluge

odnosno obavlja aktivnosti koje su specificirane u zahtevima postavljenim

pred sistem,

Sigurnost sofvera ogleda se u sposobnosti softvera da radi (funkcionira) bez

posljedica koje bi mogle ugroziti kontinuirani proces rada softvera,

Zaštita softvera odnosi se na sposobnost softvera da se sam zaštiti protiv

slučajnih ili namernih nedozvoljenih aktivnosti koje bi mogle ugroziti

sistem.



6.7 Usluge OQT MAINT-a

U MAINT centru, su istaknuti i precizno definisani sledećih pet tipova odrţavanja:

1) Hitno korektivni, kada postoji greška u sistemu koji ga blokira i mora biti

odmah ispravljena.

2) Ne-urgentno korektivni, kada postoji greška u sistemu koja ga trenutno ne

blokira.

3) Okončani, kada je potrebno dodavanje novih funkcionalnosti.

4) Preventivni, kada će neki interni softverski atributi biti promenjeni

(odrţavanje, ciklomatična kompleksnost, itd), ali bez promene

funkcionalnosti ili oblika upotrebe sistema.

5) Prilagodljivi, kada će sistem biti prilagoĎen novom operativnom okruţenju.

Ova razlika dozvoljena je za izgradnju različitih tehničkih vodiča za svaku vrstu,

koje su bile postepeno refinirane. MeĎutim, u konačnoj verziji naše usluge odrţavanja smo

grupisali poslednja četiri tipa u jednu grupu, jer se otkrilo da praktična primena

metodologije oporavka i načina izvršenja tih vrsta odrţavanja su veoma slična. Dakle, oni

su grupisani u jedinstveni naziv, planneable odrţavanje, ostavljajući na taj način hitne

korektivne kao ne-planneable odravanje.

6.8 Kako čitati zahteve, dizajn i izvorni kod

Onog trenutka kada se problem odrţavanja preda stručnjacima za odrţavanje, oni

moraju menjati izvorni kod. MeĎutim mnogi softverski sistemi se sastoje od milion linija

izvornog koda. Svaka linija izvornog koda je potencijalno mesto pojavljivanja problema.

Ali odakle da počnemo?

Softverski serviseri će potraţiti sve dostupne informacije: o zahtevima, o dizajnu,

priručnicima, u drugoj dokumentaciji i naravno u samom izvornom kodu. Cilj je razumeti

efekte izmena u softveru, pre nego što su izmene izvršene. Svako ko je pisao softver

upoznat je da ćemo promenom dela softvera uticati i na njegove druge delove i

perfomanse. Zato je sistemski prikaz neophodan.

Imaj na umu staru poslovicu: „ako se izvorni kod ili bilo koji od zahteva, dizajna ili

dokumentacije ne slaţu, oboje su pogrešni“! U tom slučaju izvorni kod je siguran vodič jer

pokazuje kako sistem radi trenutno. Dostupni izvorni kod je siguran vodič jer pokazuje

kako sistem radi trenutno. Dostupni izvorni kod se uvek čita u procesu odrţavanja.

Da pretpostavimo da razmatramo samo izvršni kod. Šta ćemo prvo traţiti?

Odgovor se sastoji iz više delova. Mogli bi početi traţeći izveštaje o odrţavanju

sličnih situacija da bi potrţaili nagoveštaje gde da traţimo probleme. TakoĎe bi mogli

upotrebiti samo bilo koji CASE alat da analiziramo izvorni kod i pokaţemo programsku

strukturu. Nakon što smo skupili dovoljno informacija da ograničimo našu paţnju na manji

broj modula, svaki od njih treba proveriti istim nivoom detaljnosti kao kad vršimo

proveravanje u toku pisanja programa.



6.9 Starenje softvera

Programi kao i ljudi, stare. Mi ne moţemo zaustaviti starenje, ali moţemo da

shvatimo uzroke starenja softvera, da preduzmemo korake koji bi ograničili efekte ovog

procesa, privremeno popravimo neke od posledica koje je starenje uzrokovalo i

pripremimo se za dan kada taj softver više nije odrţiv. Ne smemo da se koncentrišemo

samo na prvu predstavu softvera već i na dugoročno zdravlje našeg prizvoda. Starenje

softvera je neizbeţan proces u nogome sličan staranju ljudi. Moguće je usporiti proces,

ponekad moţemo čak da obrnemo proces starenja (revitalizacija).

Sa vremenom raste značaj starenja softvera:

rast ekonomske vaţnosti softvera,

softver predstavlja veliki deo kapitala mnogih modernih kompanija,

mnogi programi su postali oslonac današnjeg društva,

zastarevanje programa koči dalji razvoj sistema koji ih koriste.

Autori i vlasnici novog softvera na proces starenja softvera često gledaju sa

prezirom.

Postoje dva glavna uzroka starenja softvera:

izostanak napredka – starenje kao posledica nemogućnosti programera da

izvrši potrebne izmene programa kako bi ušao u korak sa vremenom

narušavanje dizajna – promene u kodu programa koje uzrokuju narušavanje

originalnih principa dizajna.

Posledice starenja softvera:

neodrţivost,

gubitak perfomansi i

smanjena pouzdanost.

Dok stari softver postaje sve veći. Najlakši način da se doda nova funkcionalnost u

već postojeći softver je dodavanje novog koda u softver. Modifikacije postaju sve teţe sa

povećanjem veličine softvera jer raste veličina koda koji treba modifikovati i sve je teţe

naći delove koje treba promeniti. Kao rezultat dešava se to da se korisnik prebaci na mlaĎi

softver u potrazi za novim funkcijama.

Kako se veličina programa povećava on zahteva više memorije za rad. Brzina

izvršavanja opada zbog lošeg dizajna dobijenog ad-hoc odrţavanjem, što podrazumeva

brza rešenja koja nisu obavezna i najoptimalnija. Korisnici moraju da poboljšaju svoje

računare kako bi od programa dobili prihvatljiv odziv.

Kako brinemo za starenje softvera:

1) Zaustavljanjem propadanja - Ovo se vrši uvoĎenjem, odnosno

ponavljanjem strukture kada se naprave promene. Primenjujući iste principe

dizajna, ako je promenjena odluka o dizajnu sistema, nova struktura

podataka ili algoritam moţe biti sakriven (zatvoren) na način koja i čine sve



buduće izmene, na aspkt slabijeg sistema. Paţljivi pregledi moraju da

obezbede da je svaka promena u skladu sa namerom originalnog dizajnera.

2) Novokreirani dokumenti se pregledaju - Kod se mora proveriti da se

uverite da je u raĎen u skladu sa ovim novim dokumenatima. Oko 10 do 25

odsto razvoja sistema i odrţavanje napor je staviti u razvoju i odrţavanju

dokumentacije.

6.10 Vrste odrţavanja

Postoji više vrsta aktivnosti koje nazivamo odrţavanjem, ali su tri osnovne:

Odrţavanje u smislu ispravke softverskih grešaka

Odrţavanje u smislu prilagoĎavanja softvera različitim operativnim

okruţenjima

Odrţavanje u smislu dodavanja i modifikacija sistemskih funkcionalnosti.

Slika 6.10.1 Vrste odrţavanja

Sa slike se vidi da najveći deo odrţavanja, gotovo dve trećine otpada na dodavanje

funkcionalnosti i modifikacije, dok manji uzimaju ispravke i prilagoĎavanja.

17%

18%

65%

Ispravke

Prilagođavanje

Dodavanje funkcionalnosti i modifikacije



6.11 Toškovi odrţavanja

Troškovi odrţavanja su veći od troškova razvoja. Povećavaju se trajanjem

softverskog odrţavanja, odnosno odrţavanje utiče na softversku strukturu oteţavajući dalje

odrţavanje. Timska saradnja i podrška igraju značajnu ulogu u ovom procesu, a sami

troškovi odrţavanja su manji, ako je angaţovano isto osoblje kao i na razvoju. MeĎutim,

najčešće su situacije kada je angaţovan poseban tim na odrţavanju, koji uglavnom nema

iskustvo, veštinu i znanje razvojnog tima.

6.11.1 Predviđanje troškova odrţavanja

Shodno velikom udelu u troškovima poţeljno je na vreme uraditi planiranje i

predvideti:

koji delovi sistema će najverovatnije biti podloţni zahtevima za promene

koliki broj zahteva za promenama se moţe očekivati

koji delovi sistema će biti najskuplji za odrţavanje

kako će izgledati troškovi odrţavanja prema vremenu korišćenja sistema

koliki će biti troškovi odrţavanja sistema u narednom vremenskom periodu

(npr. na godišnjem nivou)

analizom obuhvatiti i sredstva i vreme utrošeno za odrţavanje (izlazak na

teren, vreme zadrţavanja i sl.).

6.11.2 Detaljnije predviđanje troškova

Detaljnije analize pokazuju da se najviše vremena i sredstava troši na odrţavanju i

prepravkama relativno malog broja sistemskih komponenti. U tim slučajevima, troškovi

zavise od kompleksnosti tih komponenti. Kompleksnost komponente zavisi od:

kompleksnosti kontrolnih struktura;

kompleksnosti struktura podataka;

veličine procedura i modula.

Poţeljno je uraditi procenu broja zahteva za promenama pri odrţavanju, kao i

procenu utrošenog vremena na jednoj prosečnoj promeni na osnovu zahteva. TakoĎe,

značajna stavka je i provedeno vreme i broj izlazaka na teren radi odrţavanja.

6.12 Aktivnosti odrţavanja

Aktivnosti u odrţavanju softvera, a koji sluţe i kao pokazatelji kvaliteta softverskog

proizvoda su:

prerada softverskog koda,

optimizacija performansi softvera,

migracija na druge platforme,

konverzija u nove arhitekture,

uklanjanje neaktivnog koda,



uklanjanje skrivenih aplikacija,

povlačenje softvera iz upotrebe.

Slika 6.12.1 Troškovi odrţavanja softvera

Ostale aktivnosti tokom procesa odrţavanja su:

kontakti sa klijentima

pisana korespondencija

izlasci na teren i dr.

Na slici 5.12.1. su prikazani troškovi ţivotnog ciklusa razvoja softvera. Relativno

mali deo troškova softverskog razvoja, oko 5%, troši se na kodiranje. Najveći deo troškova

otpada na odrţavanja.

7%5%

6%

2%

4%

3%

67%

Testiranje modula

Kodiranje modula

Dizajn

Planiranje

Detaljan opis

Zahtevi

Održavanje



6.13 Zaključak

Odrţavanje isporučenog softverskog sistema obično zahteva više vremena i

sredstava od same realizacije i implementacije sistema. Moguće je angaţovanje razvojnog

ili posebno formiranog tima na odrţavanju. Odrţavanje obuhvata:

ispravljanje grešaka;

prilagoĎavanje novom operativnom okruţenju i

dodavanje novih funkcionalnosti.

Ako odrţavanje sistema ne moţe da se sprovede u skladu sa gore navedenim

zahtevima, postavlja se pitanje opravdanosti i dalje upotrebljivosti čitavog sistema.

7. DEFINISANJE LOGIČKOG DIZAJNA

Logički dizajn je definisan kao proces opisivanja rešenja u oblicima organizacije,

strukture i interakcije delova sa stanovišta projektnog tima. Logički dizajn obraĎuje

sledeće:

Definiše sastavne delove rešenja

Omogućava infrastrukturi da sadrši sve delove rešenja zajedno

Ilustruje kako rešenje ukomponovano i sa korisnicima i drugim rešenjima

Kada se kreira logički dizajn tim uzima u obzir sve poslovne, korisničke, sistemske

i operativne zahteve i odreĎuje potrebu za bezbednošću, praćenjem, logovanjem,

skalabilnosti, upravljanjem porukama, obradom grešaka, licenciranjem, globalizacijom,

arhitekturom aplikacije i integracijom sa drugim sistemima.

Logički dizajn moţe početi i pre nego se završi konceptualni dizajn. Odluka o

početku logičkog dizajna se donosi od slučaja do slučaja u zavisnosti od projekta i od

projektnog tima. Kada projektni tim nastavi sa konceptualnog na logički dizajn menja se i

perspektiva projekta. Za vreme konceptualnog dizajna, projektni tim definiše poslovni

problem baziran na sakupljenim podacima iz poslovnog i korisničkog okruţenja, dok kod

logičkog dizajna daje se rešenje iz sopstevog pogleda.

Dobar logički dizajn zavisi od dobrog konceptualnog dizajna. Ako projektni tim

kreira dobar logički dizajn, onda bi trebalo da bude lako svakom novom članu tima da

sagleda dizajn, odredi vaţne delove rešenja i rezime kako delovi rade zajedno da bi rešili

poslovni problem. Često se dešava da rad na logičkom dizajnu se preklapa sa radom na

fizičkom dizajnu.

7.1 Konceptualno rešenje

Na slici su prikazani osnovni učesnici u našem sistemu. Strelicama su obeleţeni

tokovi informacija izmeĎu učesnika. Ovakav način rada je efikasan, produktivan i

smanjuje broj grešaka, svaka interakcija je obeleţena strelicama i tekstom koji opisuje

osnovni zadatak te komunikacije.



Slika 7.1.1 Konceptualno rešenje

7.2 Kontekst dijagram

Kontekst dijagram predstavlja vaţne faktore za definiciju našeg sistema. U kontekst

dijagramu je dat spisak procesa pomoću kojih naš sistem intereaguje sa ostalim učesnicima

u njegovom fukncionisanju. To je interakcija sa spoljašnjim faktorima i akcijama kojima

oni mogu jedni na druge da utiču.

Kontekst dijagram je veoma vaţan jer pomoću njega predstavljamo aktivne,

pasivne, kooperativne, autonomne učesnike u radu našeg sistema. Kontekst dijagram se

koristi u početnim fazama projektovanja i sluţi za istraţivanja rada sistema.



Slika 7.2.1 Izgled kontekst dijagrama

7.3 Upoznavanje sa use case dijagramom

Slučajevi korišćenja predstavljaju formalan, strukturiran pristup tumačenja radnih

tokova i procesa. Use case je dizajniran da opiše odreĎeni cilj i da istraţi interakciju

izmeĎu korisnika i stvarnih sistema komponente. Komponente ovih dijagrama su akteri,

uloge, slučajevi upotrebe i relacije.

Akteri predstavljaju nekoga ili nešto što se nalazi izvan sistema ili organizacije (u

zavisnosti od vrste dijagrama), a u interakciji je sa njim. Uloge se koriste samo prilikom

izrade dijagrama slučajeva upotrebe poslovnog procesa i predstavljaju nekoga ili nešto što

se nalazi unutar organizacije i u interakciji je sa funkcionalnostima posmatranog dela

organizacije.

Slučajevi upotrebe i slučajevi upotrebe poslovnog procesa sluţe da bi se prikazale

konkretne funkcionalnosti sistema, odnosno organizacije. Ovi dijagrami predstavljaju

vodilju za kompletan proces razvoja softvera, pa se često za razvoj zasnovan na UML-u

kaţe da je usmeravan slučajevima upotrebe.



7.4 Use Case Model izrade softvera

Slika 7.4.1 Use Case Model izrade softvera

Tabela 7.4.1: Opis slučaja upotrebe izrade softvera

Ime scenarija Izrada softvera

Opis Ovaj scenario ukratko opisuje postupak izrade softvera. Neophodno je da korisnik

dostavi zahtev za izradu softvera. Komponente Optimal SQM-a su zadužene za

izradu i oržavanje proizvoda.

Osnovni koraci 1. Korisnik dostavlja zahtev za izradu softvera komponenti Optimal SQM-a zvanoj

OQT MNGR. Korisnik plada i koristi gotov proizvod, al ii podnosi zahtev za njegovo

oržavanje.

2. OQT MNGR obrađuje zahtev i prosleđuje ga ostalim komponentama u sistemu

Optimal SQM. Takođe analizira rad ostalih komponenti, vrši dokumentaciju i voddi

procenu troškova izrade projekta.

3. OQT SIM je komponenta zadužena za izradu simulacije

4. Nakon simulacije proizvod se testira OQT BOX komponentom po principima crne,

bele i sive kutije.

5. Nakon testiranja sledi održavanje softvera (OQT MAINT). Održavanje obuhvata

modifikaciju i dopunu programa nakon što je pušten u upotrebu.

6. OQT OPST komponenta Optimal SQM-a ptrebna je timu za planiranje i

sprovođenje testiranja konkretnog razvijanog softvera.



Zahtev Korisnik podnosi zahtev za izradu softvera.

Rezultat Korisnik je od kompanije dobio efikasan proizvod za korišdenje i sistem za

održavanje svog proivoda.

7.5 Dijagram klase za izradu softvera

Slika 7.5.1 Dijagram klase za izradu softvera

Dijagram klasa je strukturni dijagram koji predstavlja skup klasa, interfejsa, društva

saradnika i njihove meĎusobne relacije.

- Atributi korisnika su: ime, prezime i sifra. Korisnik podnosi zahtev

kompaniji za izradu softvera, testiranje softvera ili odrţavanje softvera.

- Atributi zahteva su: naziv i šifra. Zahtev se prosleĎuje u bazu podataka.

- Atributi baze podataka su: naziv i šifra. ObezbeĎuje pristup komponentama

OptimalSQM i pritom obezbeĎuje zaštitu od pristupa neţeljenih članova.

- Atributi OQT MNGR su: šifra i broj članova. ProsleĎuje zahteve ostalim

komponentama, vodi dokumentaciju o uraĎenom poslu, pristupa bazi

podataka.

- Atributi komponente OQT SIM su: šifra i broj članova. Operacija ove

komponente je izvršavanje simulacije rešenja. U bazi podataka upisuje

izvršen posao, odakle MenaĎeri mogu da imaju uvid o odraĎenom zadatku.



- Atributi komponenta OQT BOX su: šifra i broj članova. Ova komponenta

vrši testiranje rešenja. Rezultate testiranja upisuje u bazu podataka.

- Atributi komponente OQT MAINT su: sifra i broj članova. Ova

komponenta razmišlja o svim rezultatima testiranja i vrši unakrsne procene

testiranja radi otkrivanja i uklanjanja grešaka. Rezultate odrţavanja upisuje

u bazu podataka.

- Atributi komponente OQT OPST su: šifra i broj članova. Ova komponenta

treba timu za planiranje i sprovoĎenje testiranja konkretnog razvijanog

softvera.

Nakon izrade rešenje iz bazee podataka preuzima OQT MNGR komponenta i zatim

šalje i naplaćuje kupcu kreiran proizvod. Korisnik plaća uslugu razvoja softvera.

7.6 Dijagram sekvenci za razvoj softvera

Slika 7.6.1 Sekvencijalni dijagram za razvoj softvera

Ovaj dijagram sekvenci pokazuje tok podataka u vremenu, poruke koje se nalaze na

višem nivou gledajući vertikalno se izvrsavaju prve. Uspravni izduţeni pravougaonici

predstavlja trajanje date operacije.



7.7 Use Case Model OQT MAINT

Slika 7.7.1 Model slučaja upotrebe OQT MAINT komponente

Tabela 7.7.1 Opis slučaja upotrebe OQT MAINT komponente

Ime scenarija OQT MAINT komponenta

Opis Ovaj scenario ukratko opisuje postupak održavanja softvera. Održavanje

isporučenog softverskog paketa obično zahteva više vremena i sredstava od samo

realizacije i implementacije sistema.

Osnovni koraci

1. Korisnik podnosi zahtev;

2. Zahtev se prosleđuje OQT MAINT timu;

3. OQT MAINT preko IOP maintenance Engine nudi razne kategorije održavanja;

4. Preko 6 Sigma Engine unapređuje biznis;

5. OQT MAINT sa razvojnim postupcima nudi poboljšanje održavanja softvera

(EVOP);

6. Ulaže u eksperimentalni dizajn (DOE Engine);

7. Ispitivanje pouzdanosti softverskog sistema (Reliability eXpert);

8. Vrši estimaciju softvera (Estimator eXpert);



9. Softver se šalje na upotrebu.

Zahtev Korisnik zahteva održavanje softvera.

Rezultat MAINT komponenta pruža kompletnu tehničku podršku i program za aktivnosti

održavanja.

7.8 Dijagram sekvenci za OQT MAINT

Dijagram sekvenci na (slici 6.8.1) pokazuje tok podataka u vremenu, poruke koje se

nalaze na višem nivou gledajući vertikalno se izvrsavaju prve. Uspravni izduţeni

pravougaonici predstavlja trajanje date operacije.

Slika 7.8.1 Dijagram sekvenci za OQT MAINT komponentu

Korisnik podnosi zahtev za odrţavanje softvera komponenti OptimalSQM-a OQT

MNGR koja taj zahtev upisuje u bazu podataka. OQT MAINT uzima potrebne podatke iz

baze podatak i izvršava zadatke. OQT MAINT komponenta nudi korisnicima pet tipova

odrţavanja. OQT MAINT u svom timu poseduje stručnjake za pouzdanost softvera, razvoj,

estimaciju, eksperimentalni dizajn i tako dalje. Gotovo rešenje odrţavanja softvera upisuje

se u u bazu podataka odakle clanovi komponente OQT MNGR imaju pristup razvojnom

rešenju i odrţavanom softveru. Menadţeri pristupaju bazi podataka i uzimaju gotov

proizvod koji prosleĎuju korisniku na korišćenje.



7.9 Use Case Model za vrste odrţavanja

Slika 7.9.1 Use Case Model za IOP Maintenance

Tabela 6.9.1 Opis slučaja upotrebe za IOP Maintenance

Ime scenarija IOP Maintenance

Opis scenarija OptimalSQM de svojim klijentima preko OQT MAINT funkcije ponuditi 5

kategorija za održavanje aplikativnog softvera:

- Korektivno

- Preventivno

- Adaptivno

- Perfektivno

- Troškovi

Osnovni koraci 1. Korisnik podnosi zahtev za održavanjem;

2. Menađeri prenose zahtev OQT MAINT komponenti, i vrše analizu rada

sektora za odršavanje;

3. Adaptivno održavanje vrši izmene programa u skladu sa novim zakonskim

propisima ili inicirano promenama u softverskoj okolini;

4. Korektivno održavanje ispravlja greške pronađene u softveru i ispravlja iste;

5.Preventivno održavanje vrši pradenje i podešavanje svih parametara sistema

koji utiču na rad aplikacije;

6. Perfektivno održavanje vrši sve izmene softvera koje nisu greške u radu

sistema;

7. Procena troškova održavanja;



8. Korisnik plada usluge održavanja.

Zahtev Korisnik šalje softver na održavanje.

Rezultat Korisnik dobija plansko održavanje svog softvera.

7.10 Dijagram klasa za vrste odrţavanja

Opis klasnog dijagrama sa (slike 6.10.1):

- Atributi korisnika su: ime, prezime i sifra. Korisnik podnosi zahtev kompaniji

za testiranje softvera ili odrţavanje softvera.

- Atributi proizvoda su: naziv, vrsta i šifra. Podaci o proizvodu su zaštićeni u bazi

podataka. Operacije proizvoda zavise od njegove namene i zbog toga nisu

striktno navedene u dijagramu na slici.

- Atributi zahteva su: naziv i šifra. Zahtevi mogu biti različiti od uklanjanja

kvarova, nadogradnje novim programima i prilagoĎavanjem novim

standardima, pa sve do odrţavanja softverskog rešenja.

- Atributi OQT MNGR su: šifra i broj članova. ProsleĎuje zahteve OQT MAINT

komponenti, i ima pristup bazi podataka.

- Atributi komponente OQT MAINT su: sifra i broj članova. Ova komponenta

pomoću IOP Maintenance nudi korisniku 5 tipova odrţavanja:

Adaptivno;

Korektivno;

Perfektivno;

Preventivno;

Troškovi.

Slika 7.10.1 Dijagram klasa za IOP Maintenance



7.11 Use Case Model za 6 sigma eXpert

Slika 7.11.1 Use Case Model 6 Sigma

Tabela 7.11.1 Opis slučaja upotrebe 6 Sigma eXperta

Ime scenarija 6 Sigma eXpert

Opis scenarija Šest sigma je unapređenje biznisa zasnovano na pronalaženju i

eleminisanju grešaka i uzroka pojave grešaka,

usredsređivanjem pažnje na korisnika. Obezbeđuje za:

korisnike – visok nivo kvaliteta i nisku cenu;

akcionare – povećanje profita;

menađere – nove mogućnosti dostizanja uspeha i ostvarivanje

ciljeva;

saradnike - unapređenje rada i pruđanje zadovoljstva.



7.12 Use Case Model estimator eXpert

Slika 7.12.1 Dijagram slučaja upotrebe stručnjaka za estimaciju

Tabela 7.12.1 Opis slučaja upotrebe stručnjaka za estimaciju

Ime scenarija Estimator eXpert (stručnjak estimacije)

Opis scenarija Estimacija se vrši u šest dimenzija.

Osnovni koraci 1. Korisnik podnosi zahtev za projekat;

2. OQT MNGR komponenta prima i analizira zahtev a zatim

prosleđuje ka komponenti OQT MAINT;

3. Definišu se ciljevi projekta;

4. Projekat se podeli na faze;

5. Podela projekta na komponente;

6. Rukovođenje neizvesnoću;

7. Definisanje osnova računarskog modela;

8. Tehnika estimacije;



9. Gotov projekat se daje u upotrebu korisniku.

Zahtev Korisnik podnosi zahtev za izradu projekta.

Rezultat Estimizovan proizvod se šalje na upotrebu.

7.13 Use Case Model reliability expert

Slika 7.13.1 Dijagram slučaja upotrebe eksperta pouzdanosti

Tabela 7.13.1 Opis slučaja upotrebe za Reliability eXpert

Ime scenarija Relibility eXpert

Opis scenarija Ovaj scenarijo ukratko opisuje pouzdanost softverskog paketa.

Predviđa kada će softver pasti. Postoji mnogo razloga da softver

propadne. Obično, softver ne uspeva zbog problema u dizajnu. Za

razliku od pouzdanosti održavanja, softverska pouzdanost

vremenom raste.

Osnovni koraci 1. Korisnik podnosi zahtev;

2. OQT MNGR komponenta prima i analizira zahtev a zatim

prosleđuje ka komponenti OQT MAINT;

3. Tim za održavanje beleži vreme između kvarova;

4. Tim za održavanje beleži stopu neuspeha;



5. Tim za održavanje beleži kumulativni broj neuspeha;

6. Menađeri podnose izveštaj o radu tima za održavanje;

7. Obaveštavanje korisnika o pouzdanosti softvera.

Zahtev Korisnik podnosi zahtev za proveru pouzdanosti softvera.

Rezultat Isporuka pouzdanog softvera

7.14 Use Case Model za logovanje na sajt BISA

Slika 7.14.1 Dijagram slučaja upotrebe pristup sajtu BISA

Tabela 7.14.1 Opis slučajeva upotrebe pristupa sajtu BISA

Ime scenarija Logovanje

Opis Ovaj scenario opisuje korake potrebne za logovanje na sajtu BISA, logovanje je neophodno da bi se pristupilo svim funkcionalnostima koje sistem BISA nudi.

Osnovni koraci Sistem klikom na dugme LOGIN prikazuje stranicu sa mestima za unos KORISNIČKOG IMENA i LOZINKE,

Registrovani korisnik unosi KORISNIČKO IME,

Registrovani korisnik unosi LOZINKU,

Pritiska na dugme LOGIN,

Sistem proverava tačnost podataka,



Sistem se povezuje sa bazom podataka u kojoj su smešteni podaci o korisniku i prikazuje početnu stranu prilagođenu tom korisniku.

Mogući izuzeci Ako u koraku 5. sistem ne potvrdi tačnost podataka, izbacit će poruku da su lozinka ili korisničko ime pogrešni.

Ako u koraku 6. dođe do greške u bazi podataka, sistem obaveštava korisnika da je došlo do greške i ispisuje poruku da pokuša da se prijavi kasnije.

Zahtev Registrovani korisnik želi da se informiše o funkcijama OPTIMAL SQM.

Rezultat Registrovani korisnik je prijavljen i može da počne sa orišćenjem funkcija sajta.

7.15 Osnovni dijagrami aktivnosti

Svi kursevi iz testiranja softvera i kursevi obuke za osiguranje kvaliteta su na

raspolaganju za Vašu kompaniju, povećajte znanje uz minimalne troškove. Imate i

mogućnost da se registruje na sajt BISA (www.bisa.rs/PISA).

Na (slici 6.15.1) su prikazani osnovni učesnici u našem sistemu. Strelicama su

obeleţeni tokovi informacija izmeĎu učesnika.

Ovim dijagram aktivnosti ukratko je opisana aktivnost pristupanja sajtu BISA. Neki

od osnovnih koraka su:

1. Unos podataka u polja predviĎena za registraciju

2. Sistem proverava unešene podatke i obaveštava korisnika. Ukoliko je unos

nekorektan (nije popunio sva polja, e-mail adresa već postoji itd..) korisnik se vraća

na prvi korak.

3. Ukoliko je registracija korektana to jest ukoliko je korisnik registrovan, on moţe da

krene sa unosom podataka za prijavu na sajt.

4. Sistem proverava unešenu lozinku korisnika. Ukoliko unos nije ispravan korisnik

ponovo mora da unese podatke sa prijavu na sajt. Za to ima tri pokušaja, ukoloko

ne uspe da se prijavi njegov nalog biće zaključan u sistemu.

http://www.bisa.rs/PISA



Slika 7.15.1 Dijagram aktivnosti za registraciju i logovanje na sajt BISA

Ukoliko je lozinka uspešno uneta i prihvaćena od strane sistema, korisniku se

omogućava pristup sajtu. Aktivnost dizajniranja softvera data je na (slici 6.16.2).

Osnovni koraci su:

1. Definisanje ciljeva za izradu projekta;

2. Prikupljanje zahteva, obraĎuju se konkurentska rešenja i prikupljaju se pozitivne

osobine koje ćemo primeniti na naš projekat;

3. Obrada zahteva, izvode se procene troškova, vremenste izvodljivosti i

funkcionalnosti. Definiše se vrsta softvera;

4. Izrada logičkog dizajna, osnovne informacije o projektu izrada slučajeva upotrebe i

neophodnih dijagrama aktivnosti, klasa, sekvenci itd. Definiše se veličina softvera

pomoću funkcionalnih tačaka;

5. Izrada detaljnog dizajna.



Slika 7.15.2 Dijagram aktivnosti planiranja projekta

MAINT komponenta vrši unakrsne procene kvaliteta svih flota testiranja, za sve

procene efikasnosti testiranja u otkrivanju i otklanjanju defekata (povećenje prinosa

otkrivenih grešaka), nudeći ekstremni integritet podataka.



Slika 7.15.3 Dijagram aktivnosti ofrţavanja softvera

7.16 Tabela aktivnosti

Tabela aktivnosti opisuje dogaĎaje, njihove okidače tj. dogaĎaje koji su ih izazvali,

izvor, aktivnost koja se tom prilikom izvršava, odziv sistema posle dogaĎaja i odredište,

tabela 1.



Tabela 7.16.1 Aktivnosti OptimalSQM paketa

Redni

broj

Događaj Okidač Izvor Aktivnost Odziv Odredište

1 Korisnik želi da

napravi nalog na

sajtu BISA

Podnošenje

registracionog

obrasca

Korisnik Kreira korisnički

nalog

Odobrenje

naloga

Korisnik

2 Korisnik se

prijavljuje na

sistem

Log-in prijava

korisnika

Korisnik Autorizacija Glavni

meni

Korisnik

3 Korisnik podnosi

zahtev za razvoj

softvera

Podnošenje

obrasca za razvoj

softvera

Korisnik Podnosi opis

rešenja koji

zahteva i

delatnost za koju

mu je potreba

Zahtev je

prosleđem

e-mail-om

Opimal-

SQM

4 Članovi tima za

OptimalSQM

primaju zahtev za

razvoj softvera

Pristizanje

zahteva za razvoj

softvera

Korisnik Precizno

planiranje(resur-

sa, troškova,

trajanja izrade)

Merenje

kvaliteta

Kontrola rizika

Priprema

za razvoj

kvalitetnog

softvera

Optimal-

SQM

5 Zahtev za OQT

SIM

Menađeri

podnose zahtev

za simulaciju

OQT

MNGR

Simulira procese

razvijanog

rešenja

Simulacija

softvera

Optimal-

SQM

6 Zahtev za OQT

BOX

Menađeri

podnose zahtev

za testiranje

OQT

MNGR

Testiranje

metodama:

crene, sive i bele

kutije

Testiran

softver

Opimal-

SQM

7 Zahtev za OQT

MAINT

Menađeri

podnose zahtev

za OQT MAINT

OQT

MNGR

Korektivno,

adaptivno,

perfektivno i

preventivno

održavanje. Vodi

evidenciju o

troškovima

Održavanje

softvera

Opimal-

SQM

8 Zahtev za OQT

OPST

Menađeri

podnose zahtev

za OQT OPST

OQT

MNGR

Plan

održavanja

Opimal-

SQM



9 Gotov proizvod Menađer

napladuje gotov

proizvod

Funkcije

OptimalS

QM-a

Korisnik plada

proizvod

Softver

dostupan

za

korišdenje

Korisnik

8. FIZIČKI DIZAJN

Dizajnirati grafički korisnički interfejs je, na neki način, umetnost. Treba napraviti

sistem koji je prijatan za oko, sa jedne strane intuitivan i jednostavan za korišćenje, a sa

druge strane efikasan i omogućava završavanje ţeljenog posla za kratko vreme. Nije uvek

lako na jednostavan način, predstaviti sve informacije koje treba da se nalaze na ekranu.

Interakcija izmeĎu računara i čoveka se nije bitno promenila poslednje dve decenije, pa

više ne odgovara niti naraslim mogućnostima računara, niti novim potrebama korisnika.

Korisnički interfejs je usko grlo u komunikaciji.

Do sada se nije vodilo mnogo računa o specifičnostima čovekovih komunikacionih

sposobnosti, što ograničava mogući kapacitet kanala izmeĎu čoveka i računara. Da bi se

ovo poboljšalo treba uvaţiti niz faktora prilikom kreiranja korisničkog interfejsa. Da bi se

novi korisnički interfejs pribliţio komunikaciji čoveka i računara, treba uzeti u obzir

sledeće faktore:

- čovekovu senzorsku fiziologiju,

- čovekovu anatomiju,

- čovekovu percepciju,

- saznajne mehanizme, i

- socijalnu interakciju.

Treba uzeti u obzir i karakteristike medija i fizičkog okruţenja korisnika.

Sa druge strane, razvoj korisničkog interfejsa treba da uvaţi i karakteristike

hardverskih ureĎaja koji se koriste u komunikaciji sa korisnikom, dostupne softverske

resurse, kao i karakteristike programskih sistema koji treba da koriste korisnički interfejs.

Prema korišćenoj tehnološkoj bazi i paradigmi interakcije, pristupi rešavanju problema

komunikacije izmeĎu čoveka i računara mogu da se podele u sledeće grupe:

- Hardverske korisničke interfejse,

- Terminalske korisničke interfejse,

- Grafičke korisničke interfejse,

- Percepcijske korisničke interfejse,

- Korisničke interfejse zasnovane na paţnji i

- Elektro-fiziološke korisničke interfejse.



Većina korisnika je danas u interakciji sa računarima putem kucanja, pokazivanja i

"kliktanja" korišćenjem grafičkih korisničkih interfejsa (eng. graphical user interfaces -

GUI). Komunikacija je zasnovana na:

- upotrebi prozora kao radne površine,

- ikona kao reprezenta mogućih aplikacija,

- menija kao mehanizma odlučivanja i

- pokazivača kao reprezenta poloţaja korisnika u virtuelnom svetu generisanog

programskom logikom, naziva se i WIMP paradigma (eng. windows, icons, menus,

pointer) prema osnovnim konceptima na kojima se zasniva.

Danas uobičajena neposredna interaktivna komunikacija se zasniva na korišćenju

nekog pokazivačkog uređaja poput miša. Interaktivna komunikacija u kojoj se direktno

manipuliše grafičkim objektima na ekranu, prvi put je demonstrirana u Sketchpad sistemu.

Ovaj sistem je razvio Ivan Sutherland 1963. godine, kao deo svoje doktorske teze sa

svetlosnom olovkom kao pokazivačkim ureĎajem.

Slika 8.1: Pokazivački ureĎaji (miš)

David Canfield Smith je u svojoj doktorskoj tezi 1975. godine uveo u upotrebu

termin "ikona", koji je primenio u okviru sistem interaktivnog grafičkog komuniciranja,

poznat pod nazivom Pygmalion. David Canfield Smith je kasnije postao glavni projektant

Xerox Star sistema, i zasluţan je za širu upotrebu ikona u grafičkim korisničkim

interfejsima iz kojih su preuzeti osnovni koncepti u kasnijim realizacijama.

Prvi komercijalni sistemi koji su koristili koncept interaktivne grafičke

komunikacije bili su Xerox Star 1981. godine, Apple Lisa 1982. godine i Macintosh

1984.godine.



Slika 8.2: Primer dizajna ikonica

Za prikazivanje objekata treba kreirati ikonice ili sličice koje su slične stvarima iz

svakodnevnog ţivota.

Slika 8.3: Dizajn i redizajn ikonica

Sledeći bitan element tehnologije korisničkih interfejsa jesu prozori (eng.

windows). Prva demonstracija sistema sa više prozora u obliku pločica (eng. tiled

windows) prikazana je 1968. godine u Engelbart-ovom NLS sistemu.

Alan Kay je 1969. godine u svojoj doktorskoj tezi prvi predloţio ideju

preklapajućih (eng. overlaped) prozora.

Iako je i ranije bilo nekih komercijalnih upotreba prozora, glavni sistemi koji su

popularizovali prozore bili su XeroxStar 1981. godine, Apple Lisa 1982. godine i moţda

najvaţniji Macintosh 1984. godine. Rane verzije Start sistema i Microsoft Windows-a

koristili su prozore kao pločice, ali su kasnije i oni prešli na koncept preklapajućih prozora.



Dobra slika sistema – interfejsa:

• Sistem treba da bude “blizak” korisniku:

– Prikazuje način kako “razmišlja”

– Koristi konkretne stvari i ne zahteva mnogo razmišljanja

– Omogućava dvosmerne informacije

• Podrţava i omogućava lagano učenje

• Uklanja tehničke podatke o modelu sistema koje korisnik ne mora da zna

• Reflektuje tekući status – promene moraju da se verifikuju

• Podrška je uvek aktivna

• Smanjuje potrebe za obukom ili treningom.

8.1 Prototip (skiciranje)

Prototip interfejsa predstavlja model ili simulaciju ekrana, forme ili izveštaja u

sistemu. Obično se pravi za svaki interfejs i sluţi da pokaţe korisnicima i programerima

kako će se sistem ponašati. Ranije se u tu svrhu, koristio papir na kome se prikazivalo šta

će biti prikazano u pojedinim delovima sistema. Iako se danas i dalje koriste prototipovi

na papiru, sve češća je upotreba nekih kompjuterskih alata za pravljenje prototipova. tri

najčešća pristupa dizajniranju prototipova interfejsa su ureĎena šema (storyboard), HTML

prototip i jezički prototip.

Na slici 8.4 predstavljeni su prototipovi dizajna mogućih kartica za kreiranje,

voĎenje evidencije i pronalaţenje klijentima u našem softverskom rešenju zvanom

OptimalSQM.

Treba nacrtati svaku scenu na računaru, iscrtati tankim linijama horizontalni i prototip ne

treba posebno obraćati paţnju na polja gde dolazi do interakcije (ne treba ih naznačavati ili

bojiti).

UreĎena šema je najjednostavniji prototip. Za njegovo kreiranje potrebni su samo

papir i olovka. Sastoji se iz nacrtanih figura na papiru koje predstavljaju kako bi trebalo

ekran da izgleda. Prikazuju i prelaze iz jednog ekrana u drugi, na isti način na koji šema

crtanog filma pokazuje prelazak iz scene u scenu. Primer ureĎene šeme prikazan je na slici

ispod.



Slika 8.1.1: Izgled papir prototipa za evidenciju korisnika

Pomoću papirnog prototipa moţe se naučiti:

Konceptualni model,

Funkcionalnost,

Navigacija i tok izvršavanja,

Terminologija,

Sadrţaj ekrana.

Nasuprot tome nemamo predstavu o:

Izgledu: boja, font, prazan prostor,

Osećaj – da li su elementi preblizu,

Vreme odgovora,

Da li se primećuju male promene,

Istraţivanje.

Sagledavajući sve ranije navedene aspekte kao i analize konkurentskih rešenja, u

ovom delu projekta bavićemo se detaljnim dizajnom kako našeg softverskog rešenja tako i

kompletne interakcije izmeĎu našeg potencijalnog korisnika i OQT MAINT komponente.



8.2 Pokretanje programa

Nakon instalacije programa, potrebno ga je pokrenuti kako bi mogao da se koristi.

Kada se završi instalacija na desktopu će se pojaviti ikonica (Slika 8.2.1). Pokretanje

programa je moguće dvostrukim klikom levog klika mišem, odnosno moguće je selektovati

ikonicu i pritisnuti Enter na tastaturi.

Kada pokrenemo program pojavljuje se sledeći prozor:

Slika 8.2.2 - Početni prozor nakon pokretanja

Sa desne strane je ispisana poruka dobrodošlice korisniku a sa leve strane korisnik

treba da izabere komponentu koju ţeli.

Pošto je naša komponenta MAINT, kursor miša je prikazan na MAINT u sledećem

prozoru se pokreće komponenta MAINT na slici (8.3.1).

Slika 8.2.1 - Ikonica OptimalSQM-a



8.3 Prijavljivanje

Pošto je prvo na šta će korisnik naići kada pokrene našu komponentu prijavljivanje,

isto tako prvo što ćemo mi obraĎivati jeste prijavljivanje na naš sistem.

Slika 8.3.1 Pokretanje naše komponente

Korisnici koji su se već registrovali odmah mogu da se prijave, dok korisnici koji

prvi put koriste naše rešenje moraju prvo da se registruju kako bi se prijavili.

8.4 Registracija

Ukoliko korisnik koji ţeli koristiti naše usluge odrţavanja softvera, a ne poseduje

nalog na našem sistemu, kao i u našoj bazi podataka, biće upućen na stranicu za

registraciju. Svaki korisnik koji ţeli koristiti naše usluge, mora se nalaziti u našem sistemu.

Prozor za registraciju prikazan je na slici (8.4.1). Prototip je tako dizajniran, da za

registraciju nije potrebno puno vremena, kao ni puno optimalnog zalaganja.



Slika 8.4.1 Izgled prozora za registraciju naše OQT Maint komponente

Korisnik mora uneti elementarne podatke o sebi. Isto tako korisnik mora posedovati

jednu validnu email adresu. Pomoć je uvek dostupna na levoj strani prozora, gde se

korisnik moţe informisati o onome što je potrebno da odradi, kako bi registraciju uspešno

odradio.

8.5 Home prozor

Nakon uspešne registracije i prijave na naš sistem, korisniku će biti omogućene

opcije odrţavanja softvera, prvi prozor koji korisnik uočava nakon prijave na naš sistem

jeste takozvani 'Home' prozor. Ovde korisnik moţe započeti odrţavanje softvera. Izgled

početnog prozora je prikazan na slici (8.5.1).

MAINT Koordinator sistem se sastoji od niza pojedinačnih modula. Ovi moduli su

zapravo kompletni programi koji obavljaju odreĎene funkcije. Obezbedićemo da ovi

programi rade nezavisno jedan od drugog, a informacije bi delili preko Microsoft Office

Access ™ baze podataka.

Početna strana našeg softverskog paketa sadrţi sledeće opcije:

Dodaj radni fajl;

Otvori radni fajl;

Izbriši radni fajl;

Pretraţi radni nalog;

Klijenti;

Obrasci i radne dozvole;

E-mail;

Kalendar;

Kategorija odrţavanja;



Oprema;

Sigurnost sistema;

Osoblje;

Radni nalog i

Statistika odrţavanja.

Slika 8.5.1 Izgled početne strane softvera OptimalSQM

Na radnoj površini ispisana je dobrodošlica korisniku, i ukratko je objašnjeno čemu

sluţi OptimalSQM. Sada korisnik ima mogućnost da započne radna na našem softveru.

Klikom na ikonicu dodaj ima mogućnost da kreira fajl za kreiranje radnog naloga za

odrţavanje programa. U ponudi su i tasteri meĎu kojima su:

Kalendar koji sluţi za evidenciju kada je odrţavanje započeto i do kada je

krajnji rok za završetak posla,

Kategorija koja nudi 5 osnovnih tipova odrţavanja koja su u poglavlju MAINT

opisanana, i to su korektivno, adaptivno, preventivno, perfektivno i troškovi,

Operma koja sadrţi spisak ponuĎenih i dostupnih alata za izvršavanje zadataka,

Sigurnost provera koliko je softver siguran i zaštićen,



Osoblje sadrţi spisak ljudi koji su angaţovani u procesu odrţavanja softvera.

Ovo polje sadrţi učinak i osnovne podatke za svakog radnika pojedinačno.

Ovde imamo mogućnost da dodamo novog radnika na odrţavanju i vršimo

pretragu radnika po nekim kategorijama i

Radni nalog sluţi za evidenciju u kreirane radne naloge, za dodavanje novih

radnih naloga i za pretragu po odrĎenim kategorijama.

8.6 Evidencija radnih naloga

Slika 8.6.1 Prozor radnog naloga, i spisak naloga

Korisnik našeg softvera ima pristup evidenciji kreiranih radnih naloga. Da bi imao

uvid u kreirane radne naloge potrebno je da klikne levim tasterom miša na taster radni

nalog. Na slici 8.6.1 primećujemo da je radni prostor podeljen u šest delova. Prvi deo

zauzima informacija o broju radnog naloga, drugi deo površine zauzimaju zadaci ili

vrsta odrţavanja, treći deo radnog prostora zauzimaju rokovi predviĎeni za završetak

predviĎenih radnih zadataka, četvrti deo radnog prostora zauzima podatak o vremenu

početka odrţavanja programskog paketa, peti deo radnog prostora zauzima informacija o

statusu radnog zadatka odrţavanja, šesti deo radne površine zauzima informacija o

prioritetu radnog zadatka koji teba izvršiti.



Drugu stvar koju uočavamo na radnom prostoru jeste da su radni nalozi koji su završeni

obeleţeni zelenom boljom dok su radni nalozi koji još uvek nisu završeni i arhivirani

označeni crvenom boljom.

Prilikom odrţavanja softvera jako je bitan i prioritet koji se deli u tri osnovna dela:

Visok nivo prioriteta radnoga naloga

Srednji nivo prioriteta radnoga naloga

Nizak nivo prioriteta radnog naloga.

8.7 Dizajn IOP Maintenance Engine u okviru softvera OptimalSQM

IOP Maintenance Engine nudi kategorije odrţavanja aplikativnog softvera, kao što

su: korektivno, preventivno, adaptivno i perfektivno, kao i predvidjanje troškova

odrţavanja koja predstavlja vrlo bitnu stavku u procesu MAINT-a.

Ove kategorije odrţavanja i vodjenje evidencije o troškovima će biti u sklopu

MAINT Koordinatora, u kome će inţinjeri MNGR-a imati uvid i kontrolu procesa

odrţavanja. Odrţavanje softvera u koordinatoru odrţavanju se sastoji od serije proizvoda

koja je dizajnirana ne samo da izgleda izuzetno moćno i sa mnoštvo funkcija, već i da

obezbedi korisnički interfejs koji je izuzetno jednostavan za upotrebu.

Slika 8.7.1: Pet tipova odrţavanja



Klikom na taster kategorija (slika 8.7.1) na radnoj površini korisniku se nudi izbor jedne

od ponuĎenih kategorija.

Kriterijum dizajna je fokusiran na fleksibilnost koja će biti pruţena, jer neće biti

kompletno spreman za korišcenje sistema, već će se takoĎe ostaviti i prostor za nove

načine da se izgrade sopstvena rešenja.

Naš cilj je da se obezbedi jedinstveni stil dizajna MAINT funkcije za odrţavanja

softvera, zatim da bude izuzetno efikasan, ali i veoma lak za korišcenje i učenje.

9. KLM teorija

KLM je praktičan dizajn alat koji moţe da snima i izračunava fizičke aktivnosti

koje će korisnik morati da sprovede da završi odreĎene zadatke. Sluţi za kreiranje

multimedijalnih, interaktivnih obrazovnih sadrţaja. Od izuzetne je vaţnosti upoznati

modele interakcije. Oni treba da doprinesu podizanju stepena upotrebljivosti kreiranih

sistema. Pod modelima interakcije se podrazumevaju opisi ulaza korisnika, akcija

aplikacije i prikaza rezultata. Modeli interakcije su zasnovani na formalizmima čime je

obezbeĎena njihova implementacija u okviru alata za razvoj interfejsa. TakoĎe, prisutan

formalizam je omogućio nekim modelima da se koriste i za specifikovanje ponašanja

interfejsa na najniţem nivou.

9.1 GOMS model

GOMS model predstavlja opis potrebnog znanja korisnika za izvršavanje nekog

zadatka na nekom sistemu ili ureĎaju. Ovo znanje podrazumeva znanje tipa „kako nešto

uraditi“ – „how to do it“, koje je zahtevano od strane sistema da bi se izvršili ţeljeni

zadaci. Akronim GOMS potiče od Goals, Operators, Methods, Selection rules. GOMS

model se sastoji od opisa postupaka (Methods) potrebnih za izvršavanje nekog specifičnog

cilja (Goals). Metod označava seriju koraka koji se sastoje od Operatora koje korisnik

mora da izvrši. Metod moţe da stvori i dodatni cilj (Goals) koji je potreban za njegovo

izvršavanje, što znači da metod ima hijerarhijsku strukturu. Ako postoji više metoda za

izvršavanje odreĎenog ciljnog zadatka, GOMS model koristi pravila selekcije (Selection

Rules), koja odabiraju ogdovarajući metod u zavisnosti od konteksta problema koji se

rešava.



Slika 9.1.1 GOMS model

GOMS model omogućava donošenje ispravnih odluka u dizajniranju interfejsa

prema korisniku na osnovu iskustava prikupljenih od samih korisnika putem GOMS

modela. TakoĎe, GOMS model propisuje šta korisnici moraju da znaju i šta bi trebalo da

nauče, tako da se GOMS model moţe koristiti i za osmišljavanje trening kurseva, kao i

korisničke dokumentacije.

GOMS analiza obuhvata definisanje i opis korisnikovih ciljeva (Goals), operatora

(Operators), metoda (Methods) i pravila selekcije (Selection rules).

Primer jednostavne GOMS analize

Kao primer, uzećemo brisanje nekog objekta sa desktopa. U ovom primeru naš cilj (Goal)

jeste brisanje objekta sa desktopa. Metod za rešavanje ovog cilja sastoji se iz sledećih

koraka:

1. Izvršavanje ciljnog zadatka: prevlačenje objekta u korpu;

2. Povratak sa izršenim ciljem.



Slika 9.1.2: Izračunavanje vremena potrebnog za premeštanje fajla u drugi disk

Moţemo razlikovati šest tipova operatora, od kojih svaki zahteva odreĎeni interval

vremena za njegovo izvršavanje:

1. K: pritisnuti taster ili dugme, 2. B: klik mišem,

3. P: pokazati mišem na objekat na ekranu,

4. H: postaviti ruke na tastaturu ili drugi ureĎaj,

5. D: iscrtati deo linije, 6. M: mentalna priprema za izvršavanje neke akcije,

7. R: vreme koje korisnik provede čekajući odgovor sistema.

Kako svaki od ovih operatora zahteva odreĎeno vreme izvršavanja, vreme

izvršavanja kompletnog zadatka moţemo predstaviti kao funkciju oblika:

Texecute = TK + TB+ TP + TH + TD + TM + TR



Tabela 9.1.1: Tipovi operatora u GOMS modelu

OPERATOR OPIS VREME (s)

K Pritisak tastera

najbolji daktilograf (135 karaktera u minuti) 0.08

dobar daktilograf (90 karaktera u minuti) 0.12

prosečan daktilograf (55 karaktera u minuti) 0.22

prosečan daktilograf (40 karaktera u minuti) 0.28

kucanje kompleksnih kodova 0.75

kucanje n karaktera n*t(karakter)

P Pokazati mišem na objekat na ekranu 1.10

B Kliknuti mišem 0.10/0.20

H Postaviti ruke na tastaturu ili ureĎaj 0.40

D(n,l) Iscrtati n segmenata duţine l 0.9 * n+0.16 * l

M Mentalna priprema/odgovor 1.35

R Čekanje na odgovor sistema t sec

Dodatni operatori i vreme njihovog izvršavanja

Pomeranje očiju na odreĎenu lokaciju 2.3

Uzimanje stavke iz memorije 12

Odabir meĎu metodama 12

KLM aktivnost premeštanje fajla:

Na osnovu standardnih vrednosti KLM operatora, koje smo naveli u tabeli, vreme izvršenja

aktivnosti prosleĎivanja fajla sa desktopa na removable disk za prosečnog korisnika iznosi:

T=T(M)+T(H)+T(P)+T(B)+T(B)+T(B) T=T(M)+T(H)+T(P)+3*T(B)=1,35+1,10+3*0,20

T=1,35+0,4+1,1+0,8=3,65(s)

T(M): Korisnik locira fajl na dektopu,

T(H): Korisnik postavlja ruku na miš,

T(P): Korisnik postavlja kursor miša na ikonu fajla,

T(B): Korisnik pritiska desni taster miša na ikoni fajla,

T(B): Korisnik pomoću miša klikće na opciju send to,

T(B): Korisnik pomoću miša klikće na na opciju removable disk gde ţeli da prenese fajl.

KLM aktivnost registracija i logovanje na sajt BISA:



Slika 9.1.3: Izračunavanje vremena potrebnog za premeštanje fajla u drugi disk


aktivnosti registrovanja na sajt BISA za prosečnog korisnika iznosi:

T=T(M)+T(H)+T(P)+2*T(B)+T(H)+12*T(K)+T(H)+T(P)+T(B)+T(P)+T(H)+14*T(K)+

T(H)+T(P)+T(B)+T(H)+8*T(K)+T(H)+T(P)+T(B)+T(H)+20*T(K)+T(H)+T(P)+T(B)+

T(H)+8*T(K)+T(H)+T(P)+T(B)+T(H)+8*T(K)+T(H)+T(P)+T(B)+T(P)+T(B)+14*T(K)+

T(H)+T(P)+T(B)+T(H)+20*T(K)+T(H)+T(P)+T(B)+T(H)+10*T(K)+T(H)+T(P)+T(B)+

T(P)+T(B)+T(P)+T(B)+T(P)+T(B)+T(P)+T(B)+T(H)+8*T(K)+T(H)+T(P)+T(B)+T(H)+

8*T(K)+T(H)+T(P)+T(B)

T = T(M) + 22*T(H) + 17*T(P) + 17*T(B) + 130*T(K) = 1.35 + 22*0.4 + 17*1.1 +

17*0.20 + 130*0.22

T=60.04 (s)

T(M) - Korisnik se mentalno priprema za registrovanje i razmišlja na koju ikonicu da

klikne;

T(H) - Korisnik postavlja ruku na miš;

T(P) - Korisnik pomera strelicu miša na ikonicu;

2*T(B) - Dupli klik mišem na ikonicu;

T(H) – Korisnik postavlja ruke na tastaturu;

12*T(K) – Korisnik u polje za pretragu unosi www.bisa.rs i klik na enter;

T(H) – Korisnik postavlja ruku na miš;

T(P) – Korisnik locira strelicu miša polje registracija;

T(B) – Korisnik pomoću miša pritiska polje registracija;

T(P) – Korisnik postavlja strelicu miša na polje ime;


http://www.bisa.rs/



14*T(K) – Korisnik u polje za unos punog imena i prezimena unosi 14 karaktera (na

primer Petar Petrović). Broj unešenih karaktera nije uvek isti, to jeste zavisi od duţine

korisnikovog imena i prezimena.;


T(P) – Korisnik postavlja strelicu miša na sledeće polje zvano korisničko ime;

T(B) – Klik mišem na polje korisničko ime;


8*T(K) – Korisnik u polje za unos korisničkog imena unosi 8 karaktera sa tastature (na

primer Legionar). Broj unešenih karaktera nije uvek isti i moţe da varira u zavisnosti od

korisnika;


T(P) – Korisnik postavlja strelicu miša na sledeće polje zvano adresa elektronske pošte;

T(B) – Klik mišem na polje adresa elektronske pošte;


20*T(K) – Korisnik u polje za unos adrese elektronske pošte, unosi 20 karaktera sa

tastature (na primer [email protected]). Broj unešenih karaktera nije uvek isti, to jeste

zavisi od duţine korisnikovog mejla;


T(P) – Korisnik postavlja strelicu miša na sledeće polje zvano “lozinka”;

T(B) – Klik mišem na polje “lozinka”;


8*T(K) – Korisnik u polje za unos lozinke proizvoljno i po svojoj volji moţe da unese

duţinu lozinke koja ne sme biti manja od 8 karaktera. Za ovaj primer mi smo uzeli da je

duţina unešenih karaktera sa tastature jednaka 8. Naravno duţina lozinke zavisi isključivo

od volje korisnika i moţe biti različitih veličina;


T(P) – Korisnik postavlja strelicu miša na sledeće polje zvano “provera lozinke”;

T(B) – Klik mišem na polje “provera lozinke”;


8*T(K) – Korisnik u ovom polju mora da unese iste karaktere po istom redosledu kao i u

polju lozinka;


T(P) – Korisnik postavlja strelicu miša na taster “registruj se”;

T(B) – Klik mišem na taster “registruj se”;

T(P) – Korisnik postavlja strelicu miša na taster taster “nova kartica”;

T(B) – Klik mišem na taster “nova kartica”;

14*T(K) – Korisnik u pretrazi unosi 14 karaktera sa tastature (www.gmail.com i pritiska

enter);


T(P) – Korisnik postavlja strelicu miša na polje “username”;

T(B) – Klik mišem na taster “username”;


20*T(K) – Korisnik sa tastature unosi 20 karaktera u polje username. Broj unešenih

karaktera zavisi od toga ko je korisnik. Korisničko ime je za svakog korisnika različito,

mada broj unešenih karaktera moţe biti isti;


T(P) – Korisnik postavlja strelicu miša na polje “password”;

T(B) – Klik mišem na taster “password”;


mailto:[email protected]

http://www.gmail.com/



10*T(K) – Korisnik sa tastature unosi 10 karaktera u polje password. Broj unešenih

karaktera zavisi od toga ko je korisnik;


T(P) – Korisnik postavlja strelicu miša na taster “sign in”;

T(B) – Klik mišem na taster “sign in”, korisnik pristupa svom mejlu;

T(P) – Nakon što se ulogovao na svoj mejl korisnik postavlja strelicu miša na poruku koja

mu je stigla od sistema;

T(B) – Klik mišem na taj aktivacioni mejl, i tom prilikom sistem otvara sadrţaj poruke

korisniku;

T(P) – Korisnik postavlja strelicu miša na link za aktivaciju korisničkog naloga;

T(B) – Klik mišem na taj aktivacioni link, time je korisnik aktivirao svoj korisnički nalog u

sistemu i sada je u mogućnosti da se prijavi na sajt www.bisa.rs. Sve što treba da uradi

jeste da se vrati na sajt bise i da popuni polja za prijavu na sajt;

T(P) – Korisnik strelicu miša locira na karticu gde je otvorena početna strana bias sajta;

T(B) – Klik mišem na tu karticu;

T(P) – Korisnik pozicionira strelicu miša na polje za “unos korisničkog imena”;

T(B) – Klik mišem na to polje;


8*T(K) – Korisnik unosi isto ono korisničko ime koje je uneo u polju za registraciju;


T(P) – Korisnik pozicionira strelicu miša na polje za “unos lozinke”;

T(B) – Klik mišem na to polje;


8*T(K) – Korisnik unosi istu lozinku koju je uneo u polju za registraciju;


T(P) – Korisnik pozicionira strelicu miša na taster “prijavi se”;

T(B) – Klik mišem na taster “prijavi se”, time se korisnik prijavio na sajt www.bisa.rs.

Slika 9.1.4 Izračunavanje vremena za pristup random nalogu

http://www.bisa.rs/

http://www.bisa.rs/




aktivnosti otvaranja radnog naloga koristeći naše softversko rešenje za prosečnog korisnika

iznosi:

T=T(M)+T(H)+T(P)+2*T(B)+T(P)+T(B)+T(P)+T(B)+T(H)+T(P)+T(B)+10*T(K)+T(H)+

T(P) +T(B) +8*T(K) +T(H) +T(P) +T(B) +8*T(K) +T(H) +T(P) +T(B) +T(H) +T(P)

+T(B)+50*T(K) +T(H) +T(P) +T(B)

T=T(M)+7*T(H)+9*T(P)+10*T(B)+76*T(K) = 1.35+7*0.4+9*1.1+10*0.2+76*0.22

T = 32.74 (s)

T(M) - Korisnik se mentalno priprema za izradu radnog naloga;


T(P) - Korisnik pomera mišem strelicu na ikonicu;

2*T(B) - Dupli klik na ikonicu;

T(P) - Korisnik pomera mišem strelicu na taster radni nalog;

T(B) - Klik na taster radni nalog;

T(P) - Korisnik pomera mišem strelicu na taster DODAJ RN (RN je skraćenica za radni

nalog);

T(B) - Klik na taster;


T(P) - Korisnik pomera mišem strelicu na polje za unos imena firme (ili klijenta);

T(B) - Klik na polje za unos imena firme;

10*T(K) – Korisnik sa tastature unosi proizvoljan broj karaktera (za naš primer uzeli smo

8 karaktera) u polje predvoĎeno za unos imena firme;


T(P) - Korisnik pomera mišem strelicu na polje za unos šifre;

T(B) - Klik na polje za unos šifre;

8*T(K) – Unos šifre proizvoljne duţine;


T(P) - Korisnik pomera mišem strelicu na polje za unos lokacije;

T(B) - Klik na polje za unos lokacije;

8*T(K) – Unos lokacije proizvoljne duţine;


T(P) - Korisnik pomera mišem strelicu na polje za odabir kategorije odrţavanja;

T(B) - Klik mišem na jedno od 5 ponuĎenih kategorija odrţavanja;


T(P) - Korisnik pomera mišem strelicu na polje za unos opisa radnog naloga;

T(B) - Klik na polje za unos opisa radnog naloga;

50*T(K) – Unos opisa radnog naloga proizvoljne duţine;


T(P) - Korisnik pomera mišem strelicu na taster za kreiranje radnog naloga;

T(B) - Klik mišem na taster kreiraj;



9.2 Hick-ov zakon

Hick-ov zakon, ili Hick-Hyman-ov zakon, predstavlja model čovek-kompjuter

interakcije koji opisuje vreme potrebno korisniku da donese odluku kao funkciju mogućih

izbora koje on ili ona imaju. Davanjem n jednako verovatnih izbora, prosečno reakciono

vreme T zahtevano za izbor je pribliţno (Sears & Jacko, 2008).

T = blog2(n+1)

gde b predstavlja konstantu koja se moţe empirijski determinisati podešavanjem linije

odmerenih podataka. Prema Stuart Card-u, Thomas P. Moran-u i Allen Newell -u (1983), n+1 je

„zbog toga što postoji neizvesnost u pogledu da li da se odgovori ili ne, kao i o tome koji odgovor

dati”. Zakon se moţe uopštiti u slučaju izbora sa nejednakom verovatnoćom pi dogaĎanja, u

T = bH

Sa H koje predstavlja entropiju informacione teorije, definisanu kao

Mogući razlog za postojanje logaritamske forme Hick-ovog zakona je što ljudi dele

celokupnu kolekciju izbora u kategorije, eliminišući oko polovinu ostalih izbora u svakom

koraku, pre nego da razmatraju sasvim i svaki izbor jedan po jedan, što zahteva linearno

vreme.

Hick-ov zakon ponekad navodi sloţene meni dizajnirane odluke. Primenjivanje

modela na menije mora se uraditi sa posebnom paţnjom. Da bi se našla data reč (npr. ime

komande) u nasumice poreĎanoj listi reči (npr. meniju), potrebno je brzo pregledati svaku

reč, trošeći linearno vreme, tako da se Hick-ov zakon ne moţe primeniti. MeĎutim, ako je

lista reči data u alfabetnom redu, korisnik će biti u stanju da koristi strategiju podele na

manje delove, koja će zahtevati logaritamsko vreme. Naravno, dobro dizajnirani podmeniji

dozvoljavaju automatsko deljenje.

Još jedna situacija je kada korisnik ne zna tačno ime komande koju traţi u meniju,

ali moţe je prepoznati kada je vidi. U ovom slučaju, korisnik moţe ali i ne mora da koristi

traţenje strategijom podele na manje delove, u zavisnosti od delova na koje su predmeti u

meniju kategorizovani i koliko dobro korisnik moţe koristiti kategorije kako bi ubrzao

potragu.

9.3 Primena Hick-ovog zakona na

Primenom Hickovog zakona izračunaćemo vreme koje je potrebno korisniku da

izabere ţeljenu opciju na našem softveru za uvid u radni nalog.

Na sofrveru nalazi se 14 tastera. Verovatnoća da će korisnik izabrati ţeljeni taster je

1/14. Dakle 𝑝𝑖=1/14.



H=1/14* log2(14+1)=1/14* log215=0.071*3.906891=0.27739

b=150 msec

T=b*H=150*0.27739=41,6085 msec

9.4 Fitts-ov zakon

Po svojoj formi, sličan sa Hick-ovim zakonom je i Fitts-ov zakon. U ergonomiji,

Fitts-ov zakon je model ljudskog pokreta, koji predviĎa vreme potrebno za brzi pokret od

početne pozicije do finalnog ciljanog područja, kao funkcija razdaljine do mete i veličine

mete. Fitts-ov zakon se koristi kao model radnje pokazivanja, na primer sa rukom ili

prstom na kompjuteru, ili sa mišem. Objavio ga je Paul Fitts, 1954. godine (Sears & Jacko,

2008).Matematički, Fitts-ov zakon je bio formulisan na nekoliko različitih načina.

Najčešća forma je Shannon-ovo formulisanje za pokret duţ jedne dimenzije:

𝑇 = 𝑎 + 𝑏 log2 𝐷

𝑊+ 1

T je prosečno vreme potrebno da se završi kretanje. Istraţivači koriste simbol MT

za T, da bi označili vreme kretanja.

a i b su empirijske konstante, i mogu se determinisati postavljenjem prave linije na

izmerene podatke.

D je razdaljina od početne tačke do središta mete. Istraţivači često koriste simbol

A za razdaljinu, kako bi označili amplitudu kretanja.

W je širina mete ili ţeljena preciznosti sa kojom se kursor mora spustiti, merena

duţ ose kretanja. Krajnja tačka kretanja mora se nalaziti unutar ± W/2 centra mete.

Prema tome dobijamo: MT = a + b log2(2A/W)

Što znači da je vreme kretanje linearno sa logaritmom izraza (2A/W), koji

predstavlja indeks teškoće kretanja.

Slika 9.4.1: Odvojeni pokreti prema meti



Slika 9.4.1 prikazuje odvojene korake kroz četiri ciklusa shvatanja i kretanja.

Dijagram pokazuje kako pokreti u svakom koraku postaju postepeno manji kako se

pribliţavamo meti. Zato što su greške proporcionalne razdaljini, pokreti postaju

geometrijski manji. Kako imamo niz pokreta, svaki od njih geometrijski smanjuje

razdaljinu do mete i svaki uzima isto vreme. Kada je preostala razdaljina takva da je krug

greške preostalog pokreta manja od veličine mete, tada moţemo stvarno pomeriti i doći

unutar mete.

9.5 Primena Fitts-ovog zakona

Slika 9.5.1 Primer Fitts-ovog zakona

Rastojanje D od tastera PRETRAŢI do tastera RADNI NALOG iznosi D=12cm.

Širina tastera RADNI NALOG iznosi S=3cm.

Na osnovu datih veličina izračunaćemo vreme koje je potrebno korisniku da sa polja

PRETRAŢI pomeri strelicu mišem na polje RADNI NALOG.

Kako T zavisi samo od indeksa teţine, dobili smo da je T= 0,93.



10. TESTIRANJE SOFTVERA

Testiranje sistema se odnosi na ispitivanje i promatranje ponašanja softverskog proizvoda

Uključuje implementaciju sistema sa test podacima, ispitivanje izlaznih rezultata i provera

da li se ponašanje sistema odvija na način kako je to zahtevano.

Razlikujemo dva tipa testiranja:

1.Testiranje nedostataka

2.Statističko testiranje.

Testiranje nedostataka ima za cilj da pronaĎe nepodudarnosti izmeĎu programa i njegove

specifikacije. Testovi se oblikuju tako da otkriju nedostatke, uspešan je onaj test koji uspe

otkriti postojanje nedostataka u sistemu.

Statističko testiranje primenjuje se za testiranje karakteristika programa i njegove

pouzdanosti. Proverava koliko je program delotvoran u datim uslovima. Meri se vreme

izmeĎu svake uočene greške. Nakon što je uočen statistički signifikantan broj grešaka

moguće je utvrditi pouzdanost testiranog softvera.

10.1 Razlozi zbog kojih nastaju greške na softveru

50% svih problema proizlazi iz nepotpunih zahteva , uključujuci :

- Ne definisan scenario upotrebe

- Nepoznat kupac

- Neprihvatljivi kriterijumi

- “Catcall izjave, … sistem mora biti pouzdan”

- Nenapisani zahtevi

25% zbog problema sa performansama

- Nesaobraćajna specifikacija profila

- Nema modela u ponudi koji je na raspilaganju

- Količina izgubljenih podataka

- Gomila procese za obradu opterećenja

- Nepostojanje budţetskih resursa

- Neopravdana očekivanja linearne skalabilnosti

10% od Nepoznate operacije, administracije, odrţavanja ili rezervisanja (OAM&P)

- Neanaliziranje prednosti sistema

- Za oporavak sistema zaostaje on -line sistem , tako da nije bilo mogucnosti za baze

podataka da se pastave na glavni prekid

- Neadekvatni alati baze podataka

- Nedostatak alata za konverziju



5% greška pri uklanjanju nedostataka

5% korišćenje neadekvatne tehnologije

5% zbog nedostataka analize podsistema i modula zavisnosti

10.2 Testiranje

U ovoj fazi vršićemo detaljno testiranje našeg softvera, koristeći module firme XEROX i

NIELSEN Tu se nalazi trinaest modula po kojim ćemo vršiti simulaciju testiranja

aplikacije OptimalSQM, ali mi ćemo koristiti četiri modula i to:

1. Vidljivost stanja sistema

2. Podudaranje sistema i realnog sveta

3. Veštine

4. Fleksibilnost i minimalistički dizajn

10.2.1 Vidljivost stanja sistema

Sistem treba uvek odrţavati kako bi korisnik bio informisan o tome šta se dogaĎa , kroz

odgovarajuće povratne informacije u razumnom roku .

# Pregled lista za proveru Ocena Komentari

1.1 Da li svaki ekran počinje sa naslovom ili

zaglavljem koji opisuje sadrţaj na ekranu?

1.2 Da li postoji konzistentan dizajn šema ikona i

stilskih tretman u sistemu?

1.3 Ako je jedinstvena, selektovana ikona je jasno

vidljiva kada je okruţena neselektovanim

ikonama?

1.4 Da li se meni instrukcija, uputstava, i poruka

o greškama pojavljuju na istom mestu na

svakom meniju?

1.5 U višestrukim unosima podataka, svaka

stranica je označena da pokaţe svoj odnos

prema ostalima?

1.6 Ako su overtipe i insert mod istovremeno

dostupni, da li postoji vidljiva indikacija da bi

se videlo u kom je modu korisnik?

1.7 Ima li vizuelne povratne informacije u

menijima ili dijalogu o tome koje su opcije

izabrane?



1.8 Da li postoji vizuelnu povratna informacija,

kada se objekti biraju ili pomeraju?

1.9 Je li trenutni status ikone jasno označen?

1.10 Da li je vreme odziva odgovarajuce za dati

zadatak?

1.11 Da li je meni za imenovanje terminologije u

skladu sa domenom korisničkog zadatka?

1.12 Ako se korisnici moraju kretati izmeĎu više

prozora, da li sistem koristi kontekst oznake,

meni karte, i mesto markera kao navigaciona

pomagala?

10.2.2 Podudaranje sistema i realnog sveta

Sistem treba da ”govori” jezikom korisnika, sa rečima, frazama i pojmovima koji su

poznati korisniku, bolji sistem orijentisan uslovima koji su dati od strane korisnika.

Praćenje konvencija realnog sveta , trudeći se da se informacije pojavljuju u prirodnom i

logičnom redosledu.


2.1 Da li su ikone konkretne i poznate?

2.2 Da li je izbor menija izabran na najlogičniji

način, s obzirom na korisnika, imena stavki, i

varijable zadatka?

2.3 Ako postoji odreĎen redosled na izboru

menija, da li se koristi?

2.4 Da li se izabrane boje slaţu sa opštim

pravilima za boje?

2.5 Kada se traţi da se impliciraju pravne radnje,

da li su reči u poruci u skladu za tu radnju?

2.6 Da li se tasteri za reference podudaraju sa

stvarnim imenima ključeva?

2.7 Podaci na ekranu su opisani teminologijom

zadatka koja je poznata korisnicima?

2.8 Da li su naslovi menija napisani gramatički?



2.9 Da li GUI meni nudi aktivaciju: „To je to”?

10.2.3 Veštine

Sistem treba da podrţi, proširi, dopuni ili poboljša sposobnosti korisnika, pozadinu znanje i

stručnost ne zamene njima.


11.1 Korisnici mogu da biraju izmeĎu ikona i teksta

prikazivanje informacija?

11.2 Da li su operacije lake za pamćenje i korišćenje?

11.3 Da li je sistem automatski kodiran bojom, sa malo

ili nimalo napora za upotrebu?

11.4 Ako sistem podrţava i početnike i iskusne

korisnici, da li su višestruki nivoi detalja na

raspolaganju.

11.5 Da li sistem vrši prevoĎenje podataka za korisnike?

11.6 Da li vrednosti polja izbegavaju mešanje alfa i

numeričkih znakove kad god je to moguće?

11. 7 Da li su kursorski tasteri rasporeĎeni u stilu

obrnutog T. (najbolje za eksperte) ili krst konfiguraciji (najbolje za početnike)?

11.8 Da li ima dovoljno funkcijskih tastera za podršku

funkcionalnosti, ali ne toliko da je skeniranje i

pronalaţenje teško?

11.9 Da li su funkcijski tasteri zadataka u skladu preko

ekrana, podsistema i srodnih proizvoda?

11.10 Da li je sistem pravilno predvidljiv i brz za

izvesnog korisnika sledeću aktivnost?

10.2.4 Fleksibilnost minimalistički dizajn

Akceleratori-neprimećen od strane novih korisnika, često moţe ubrzati interakciju za

stručne korisnike tako da sistem moţe zadovoljiti i neiskusne i iskusne korisnike. Dozvoliti

korisnicima da prilagode česte akcije. Obezbediti alternativne načine pristupa i rada za

korisnike koji se razlikuju od "proseka" korisnika (na primer, fizičkih ili kognitivnih

sposobnosti, kulturu, jezik, itd).




8.2 Da li novim korisnicima sistem omogućava da

koriste gramatiku ključnih reči i stručnjacima

za korišćenje pozicione gramatike?

8.3 Korisnici mogu da definišu svoje sinonime za

komande?

8.4 Da li novim korisnicima sistem omogućava da

uĎu najjednostavniji, najčešći oblik svake

komande, i omogućavaju korisnicima da dodaju stručne parametre?

8.5 Da li iskusni korisnici imaju mogućnost unosa

više komandi u jednoj niski?

8.6 Da li sistem obezbeĎuje funkcijske tastere za

visoke frekvencijske komande?

8.7 Da li sistem nudi "Find Next" i "NaĎi

prethodno" prečice za bazu podataka pretrage?

8.8 Na meni, da li korisnici imaju mogućnost ili

klikom direktno na stavku menija ili pomoću prečice na tastaturi?

8.9 U dijalozima, da li korisnici imaju mogućnost

ili klikom direktno na okvir za dijalog opcija

ili pomoću prečice na tastaturi?

10.3 Primena Nielsen-ovih pravila na naše softversko rešenje

Postoji više načina da se definišu principi razvoja efektnog dizajna. Najpoznatija su

Nielsen-ova pravila. Nilsenova pravila se sastoje od deset pravila koje mi navodimo i

ujedno ocenjujemo naš softver.

1. Slaganje između sistema i realnog sveta

OptimalSQM zadovoljava prvo Nielsen-ovo pravilo. Sve radnje izvršavaju se u realnom

vremenu, a takoĎe fajlovi i strukture podataka skriveni su od krajnih korisnika.

2. Konzitentnost i standardi

OptimalSQM zadovoljava drugo Nielsen-ovo pravilo jer su operacije kooperativne, klikom

na ikonicu OptimalSQM automatski pristupamo programu. Softveru moţemo pristupiti i

selektovanjem ikonice a zatim klikom na taster ENTER pristupiti korisničkom interfejsu

softvera. TakoĎe je omogućeno koršćenje standarda na koje su korisnici naviknuti.



Nedostatak je nepostojanje prečica prečice koje iskusniji korisnicima omogućavaju brţi

rad.


OptimalSQM zadovoljava treće Nielsen-ovo pravilo. Korisnici se za pomoć obraćaju

potem mejla. Pomoć našeg servisa oseduje sistem za pomoć koje omogućava

pretraţivanje, prepoznavanje sadrţaja, orijentisano prema zadacima, konkretno i kratko.

Slika 10.3.1: Obeleţena lokacija e-mail na radnoj površini


OptimalSQM zadovoljava četvrto Nielsen-ovo pravilo jer duge operacije imaju mogućnost

prekida i svi dijalozi imaju dugme Cancel.


OptimalSQM zadovoljava peto Nilsen-ovo pravilo, Podrţava mod rada drag/drop,

obeleţavanje selektovanih objekata i td. Boje su dobro usaglašene i alati su jasno vidljivi i

dostupni.



Slika 10.3.2: Vidljivost statusa sistema


OptimalSQM zadovoljava šesto Nielsen-ovo pravilo to jest softver je fleksibilan i efikasan.

TakoĎe postoji istorija najčešće korišćenih operacija.

7. Prevencija grešaka

OptimalSQM zadovoljava sedmo Nielsen-ovo pravilo jer su zabranjene nelegalne

komande. Ako korisnik pogreši u radu i pritisne nelegalnu komandu aktiviraće se poruka

koja će korisnika obavestiti da obustavi operaciju.

8. Minimizovati rad sa memorijom

OptimalSQM zadovoljava osmo Nielsen-ovo pravilo, koristi menije a ne komandni jezik,

koristiti generičke komande uvek gde je moguće (Open, Save, Copy), sve informacije su

dostubne i jasno vidljive.

9. Izveštaj, dijagnoza i oporavak greški

OptimalSQM zadovoljava deveto Nielsen-ovo pravilo. Predlaţe konstruktivnu pomoć

zašto se greška dogodila i kako je otkloniti. Ne koristi koristiti poruke kao što sufatal, error



ili illegal, i pritom poseduje bogat help sadrţaj. Sakriveni su tehničke detalje, dok ih

korisnik ne zatraţi.

10. Estetski i minimalni dizajn

OptimalSQM zadovoljava deseto Nielsen-ovo pravilo. Korišćen je koncizan jezik, boje i

labele su paţljivo birane i ikonice imaju standardne simbole.

Slika 10.3.3: Estetski i minimalni dizajn



Tabela 10.3.1 Konačna tabela Nielsen-ovih pravila za OptimalSQM

NIELSEN - OVA PRAVILA OptimalSQM

1. Slaganje izmeĎu sistema i realnog sveta

2. Konzistentnost i standardi





7. Prevencije greške

8. Minimizovati rad sa

memorijom

9. Izveštaj dijagnoza i popravka grešaka

10. Estetski i minimalistički dizajn



11. Literatura

Dizajn korisničkog interfejsa. (25. Novembar 2011). Preuzeto 5. Januar 2013 iz

ms1pki.etf.rs: http://ms1pki.etf.rs/predavanja/PKI%2005.pdf

Ivetić, D. (5. Decembar 2011). Interakcija čovek računar. Preuzeto 5. Januar 2013 iz

faton.freehost.mk: http://faton.freehost.mk/Shkarko/HCI_E_skripta.pdf

Nielsen, J. (1999). Designing Web Usability. U J. Nielsen, Designing Web Usability.

Fremont : Nielsen Norman Group.

CIM GRUPA, Design of Experiments (DOE ), Preuzeto 17. Novembra 2012 iz

http://www.cimcollege.rs/sr/ShowSeminar.aspx?ID=164

MaintSmart, CMMS software. http://www.maintsmart.com/

SMGlobal FastMaint, CMMS software http://www.smglobal.com/index.asp

EVOP System, Razvojni postupci (EVOP), Preuzeto 1. Novembra 2012 iz

http://bellsouthpwp2.net/e/v/evop/EVOPS/evop.htm

Nikola Morena, Uvod u filozofiju dizajna softvera, Preuzeto 7. Januar 2013 iz

http://nikolamorenaict.blogspot.com/

http://www.cimcollege.rs/sr/ShowSeminar.aspx?ID=164

http://www.maintsmart.com/

http://www.smglobal.com/index.asp

http://bellsouthpwp2.net/e/v/evop/EVOPS/evop.htm

http://nikolamorenaict.blogspot.com/

Technology

OptimalSQM MAINT sistem za odrzavanje