OptimalSQM MAINT sistem za odrzavanje
-
Upload
denis-bogucanin -
Category
Technology
-
view
222 -
download
4
description
Transcript of 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
HCI PROJEKAT MAINT 2012
Prof. dr Ljubomir Lazić Tim #4 3
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
HCI PROJEKAT MAINT 2012
Prof. dr Ljubomir Lazić Tim #4 4
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
HCI PROJEKAT MAINT 2012
Prof. dr Ljubomir Lazić Tim #4 5
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
HCI PROJEKAT MAINT 2012
Prof. dr Ljubomir Lazić Tim #4 6
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
HCI PROJEKAT MAINT 2012
Prof. dr Ljubomir Lazić Tim #4 7
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
HCI PROJEKAT MAINT 2012
Prof. dr Ljubomir Lazić Tim #4 8
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).
HCI PROJEKAT MAINT 2012
Prof. dr Ljubomir Lazić Tim #4 9
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.
HCI PROJEKAT MAINT 2012
Prof. dr Ljubomir Lazić Tim #4 10
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.
HCI PROJEKAT MAINT 2012
Prof. dr Ljubomir Lazić Tim #4 11
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.
HCI PROJEKAT MAINT 2012
Prof. dr Ljubomir Lazić Tim #4 12
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.
HCI PROJEKAT MAINT 2012
Prof. dr Ljubomir Lazić Tim #4 13
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
HCI PROJEKAT MAINT 2012
Prof. dr Ljubomir Lazić Tim #4 14
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.
HCI PROJEKAT MAINT 2012
Prof. dr Ljubomir Lazić Tim #4 15
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.
HCI PROJEKAT MAINT 2012
Prof. dr Ljubomir Lazić Tim #4 16
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.
HCI PROJEKAT MAINT 2012
Prof. dr Ljubomir Lazić Tim #4 17
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.
HCI PROJEKAT MAINT 2012
Prof. dr Ljubomir Lazić Tim #4 18
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
HCI PROJEKAT MAINT 2012
Prof. dr Ljubomir Lazić Tim #4 19
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š
HCI PROJEKAT MAINT 2012
Prof. dr Ljubomir Lazić Tim #4 20
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.
HCI PROJEKAT MAINT 2012
Prof. dr Ljubomir Lazić Tim #4 21
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;
HCI PROJEKAT MAINT 2012
Prof. dr Ljubomir Lazić Tim #4 22
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.
HCI PROJEKAT MAINT 2012
Prof. dr Ljubomir Lazić Tim #4 23
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.
HCI PROJEKAT MAINT 2012
Prof. dr Ljubomir Lazić Tim #4 24
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.
HCI PROJEKAT MAINT 2012
Prof. dr Ljubomir Lazić Tim #4 25
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.
HCI PROJEKAT MAINT 2012
Prof. dr Ljubomir Lazić Tim #4 26
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.
HCI PROJEKAT MAINT 2012
Prof. dr Ljubomir Lazić Tim #4 27
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.
HCI PROJEKAT MAINT 2012
Prof. dr Ljubomir Lazić Tim #4 28
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
3. Pomoć i dokumentacija
4. Sloboda korisnika
5. Vidljivost statusa sistema
6. Fleksibilnost i efikasnost
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.
HCI PROJEKAT MAINT 2012
Prof. dr Ljubomir Lazić Tim #4 29
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
HCI PROJEKAT MAINT 2012
Prof. dr Ljubomir Lazić Tim #4 30
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,
jedan mreţni administrator 60$/h,
administrator baze podataka 70$/h.
Ukupno 160.000$ za 12 meseci. 80 poena
Za MaintSmart potrebno je:
tri programera 35$/h,
jedan dizajner 35$/h,
nemaju skladište,
dva sistem administratora 45$/h,
jedan mreţni administrator 55$/h,
administrator baze podataka 45$/h.
Ukupno 90.000$ za 7 meseci. 95 poena
HCI PROJEKAT MAINT 2012
Prof. dr Ljubomir Lazić Tim #4 31
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
HCI PROJEKAT MAINT 2012
Prof. dr Ljubomir Lazić Tim #4 32
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.
HCI PROJEKAT MAINT 2012
Prof. dr Ljubomir Lazić Tim #4 33
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.
HCI PROJEKAT MAINT 2012
Prof. dr Ljubomir Lazić Tim #4 34
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
HCI PROJEKAT MAINT 2012
Prof. dr Ljubomir Lazić Tim #4 35
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.
HCI PROJEKAT MAINT 2012
Prof. dr Ljubomir Lazić Tim #4 36
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.
HCI PROJEKAT MAINT 2012
Prof. dr Ljubomir Lazić Tim #4 37
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.
HCI PROJEKAT MAINT 2012
Prof. dr Ljubomir Lazić Tim #4 38
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.
HCI PROJEKAT MAINT 2012
Prof. dr Ljubomir Lazić Tim #4 39
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.
HCI PROJEKAT MAINT 2012
Prof. dr Ljubomir Lazić Tim #4 40
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
HCI PROJEKAT MAINT 2012
Prof. dr Ljubomir Lazić Tim #4 41
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
HCI PROJEKAT MAINT 2012
Prof. dr Ljubomir Lazić Tim #4 42
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,
HCI PROJEKAT MAINT 2012
Prof. dr Ljubomir Lazić Tim #4 43
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
HCI PROJEKAT MAINT 2012
Prof. dr Ljubomir Lazić Tim #4 44
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.
HCI PROJEKAT MAINT 2012
Prof. dr Ljubomir Lazić Tim #4 45
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.
HCI PROJEKAT MAINT 2012
Prof. dr Ljubomir Lazić Tim #4 46
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.
HCI PROJEKAT MAINT 2012
Prof. dr Ljubomir Lazić Tim #4 47
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.
HCI PROJEKAT MAINT 2012
Prof. dr Ljubomir Lazić Tim #4 48
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.
HCI PROJEKAT MAINT 2012
Prof. dr Ljubomir Lazić Tim #4 49
- 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.
HCI PROJEKAT MAINT 2012
Prof. dr Ljubomir Lazić Tim #4 50
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);
HCI PROJEKAT MAINT 2012
Prof. dr Ljubomir Lazić Tim #4 51
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.
HCI PROJEKAT MAINT 2012
Prof. dr Ljubomir Lazić Tim #4 52
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;
HCI PROJEKAT MAINT 2012
Prof. dr Ljubomir Lazić Tim #4 53
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
HCI PROJEKAT MAINT 2012
Prof. dr Ljubomir Lazić Tim #4 54
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.
HCI PROJEKAT MAINT 2012
Prof. dr Ljubomir Lazić Tim #4 55
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;
HCI PROJEKAT MAINT 2012
Prof. dr Ljubomir Lazić Tim #4 56
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;
HCI PROJEKAT MAINT 2012
Prof. dr Ljubomir Lazić Tim #4 57
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,
HCI PROJEKAT MAINT 2012
Prof. dr Ljubomir Lazić Tim #4 58
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.
HCI PROJEKAT MAINT 2012
Prof. dr Ljubomir Lazić Tim #4 59
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.
HCI PROJEKAT MAINT 2012
Prof. dr Ljubomir Lazić Tim #4 60
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.
HCI PROJEKAT MAINT 2012
Prof. dr Ljubomir Lazić Tim #4 61
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.
HCI PROJEKAT MAINT 2012
Prof. dr Ljubomir Lazić Tim #4 62
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
HCI PROJEKAT MAINT 2012
Prof. dr Ljubomir Lazić Tim #4 63
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.
HCI PROJEKAT MAINT 2012
Prof. dr Ljubomir Lazić Tim #4 64
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.
HCI PROJEKAT MAINT 2012
Prof. dr Ljubomir Lazić Tim #4 65
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.
HCI PROJEKAT MAINT 2012
Prof. dr Ljubomir Lazić Tim #4 66
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.
HCI PROJEKAT MAINT 2012
Prof. dr Ljubomir Lazić Tim #4 67
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.
HCI PROJEKAT MAINT 2012
Prof. dr Ljubomir Lazić Tim #4 68
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
HCI PROJEKAT MAINT 2012
Prof. dr Ljubomir Lazić Tim #4 69
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.
HCI PROJEKAT MAINT 2012
Prof. dr Ljubomir Lazić Tim #4 70
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;
HCI PROJEKAT MAINT 2012
Prof. dr Ljubomir Lazić Tim #4 71
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,
HCI PROJEKAT MAINT 2012
Prof. dr Ljubomir Lazić Tim #4 72
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.
HCI PROJEKAT MAINT 2012
Prof. dr Ljubomir Lazić Tim #4 73
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
HCI PROJEKAT MAINT 2012
Prof. dr Ljubomir Lazić Tim #4 74
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.
HCI PROJEKAT MAINT 2012
Prof. dr Ljubomir Lazić Tim #4 75
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.
HCI PROJEKAT MAINT 2012
Prof. dr Ljubomir Lazić Tim #4 76
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
HCI PROJEKAT MAINT 2012
Prof. dr Ljubomir Lazić Tim #4 77
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:
HCI PROJEKAT MAINT 2012
Prof. dr Ljubomir Lazić Tim #4 78
Slika 9.1.3: Izračunavanje vremena potrebnog za premeštanje fajla u drugi disk
Na osnovu standardnih vrednosti KLM operatora, koje smo naveli u tabeli, vreme izvršenja
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;
T(H) – Korisnik postavlja ruke na tastaturu;
HCI PROJEKAT MAINT 2012
Prof. dr Ljubomir Lazić Tim #4 79
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(H) – Korisnik postavlja ruku na miš;
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;
T(H) – Korisnik postavlja ruke na tastaturu;
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(H) – Korisnik postavlja ruku na miš;
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;
T(H) – Korisnik postavlja ruke na tastaturu;
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(H) – Korisnik postavlja ruku na miš;
T(P) – Korisnik postavlja strelicu miša na sledeće polje zvano “lozinka”;
T(B) – Klik mišem na polje “lozinka”;
T(H) – Korisnik postavlja ruke na tastaturu;
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(H) – Korisnik postavlja ruku na miš;
T(P) – Korisnik postavlja strelicu miša na sledeće polje zvano “provera lozinke”;
T(B) – Klik mišem na polje “provera lozinke”;
T(H) – Korisnik postavlja ruke na tastaturu;
8*T(K) – Korisnik u ovom polju mora da unese iste karaktere po istom redosledu kao i u
polju lozinka;
T(H) – Korisnik postavlja ruku na miš;
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(H) – Korisnik postavlja ruku na miš;
T(P) – Korisnik postavlja strelicu miša na polje “username”;
T(B) – Klik mišem na taster “username”;
T(H) – Korisnik postavlja ruke na tastaturu;
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(H) – Korisnik postavlja ruku na miš;
T(P) – Korisnik postavlja strelicu miša na polje “password”;
T(B) – Klik mišem na taster “password”;
T(H) – Korisnik postavlja ruke na tastaturu;
HCI PROJEKAT MAINT 2012
Prof. dr Ljubomir Lazić Tim #4 80
10*T(K) – Korisnik sa tastature unosi 10 karaktera u polje password. Broj unešenih
karaktera zavisi od toga ko je korisnik;
T(H) – Korisnik postavlja ruku na miš;
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;
T(H) – Korisnik postavlja ruke na tastaturu;
8*T(K) – Korisnik unosi isto ono korisničko ime koje je uneo u polju za registraciju;
T(H) – Korisnik postavlja ruku na miš;
T(P) – Korisnik pozicionira strelicu miša na polje za “unos lozinke”;
T(B) – Klik mišem na to polje;
T(H) – Korisnik postavlja ruke na tastaturu;
8*T(K) – Korisnik unosi istu lozinku koju je uneo u polju za registraciju;
T(H) – Korisnik postavlja ruku na miš;
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
HCI PROJEKAT MAINT 2012
Prof. dr Ljubomir Lazić Tim #4 81
Na osnovu standardnih vrednosti KLM operatora, koje smo naveli u tabeli, vreme izvršenja
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(H) - Korisnik postavlja ruku na miš;
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(H) - Korisnik postavlja ruku na miš;
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(H) - Korisnik postavlja ruku na miš;
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(H) - Korisnik postavlja ruku na miš;
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(H) - Korisnik postavlja ruku na miš;
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(H) - Korisnik postavlja ruku na miš;
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(H) - Korisnik postavlja ruku na miš;
T(P) - Korisnik pomera mišem strelicu na taster za kreiranje radnog naloga;
T(B) - Klik mišem na taster kreiraj;
HCI PROJEKAT MAINT 2012
Prof. dr Ljubomir Lazić Tim #4 82
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.
HCI PROJEKAT MAINT 2012
Prof. dr Ljubomir Lazić Tim #4 83
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
HCI PROJEKAT MAINT 2012
Prof. dr Ljubomir Lazić Tim #4 84
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.
HCI PROJEKAT MAINT 2012
Prof. dr Ljubomir Lazić Tim #4 85
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
HCI PROJEKAT MAINT 2012
Prof. dr Ljubomir Lazić Tim #4 86
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?
HCI PROJEKAT MAINT 2012
Prof. dr Ljubomir Lazić Tim #4 87
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.
# Pregled lista za proveru Ocena Komentari
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?
HCI PROJEKAT MAINT 2012
Prof. dr Ljubomir Lazić Tim #4 88
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.
# Pregled lista za proveru Ocena Komentari
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).
HCI PROJEKAT MAINT 2012
Prof. dr Ljubomir Lazić Tim #4 89
# Pregled lista za proveru Ocena Komentari
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.
HCI PROJEKAT MAINT 2012
Prof. dr Ljubomir Lazić Tim #4 90
Nedostatak je nepostojanje prečica prečice koje iskusniji korisnicima omogućavaju brţi
rad.
3. Pomoć i dokumentacija
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
4. Sloboda korisnika
OptimalSQM zadovoljava četvrto Nielsen-ovo pravilo jer duge operacije imaju mogućnost
prekida i svi dijalozi imaju dugme Cancel.
5. Vidljivost statusa sistema
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.
HCI PROJEKAT MAINT 2012
Prof. dr Ljubomir Lazić Tim #4 91
Slika 10.3.2: Vidljivost statusa sistema
6. Fleksibilnost i efikasnost
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
HCI PROJEKAT MAINT 2012
Prof. dr Ljubomir Lazić Tim #4 92
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
HCI PROJEKAT MAINT 2012
Prof. dr Ljubomir Lazić Tim #4 93
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
3. Pomoć i dokumentacija
4. Sloboda korisnika
5. Vidljivost statusa sistema
6. Fleksibilnost i efikasnost
7. Prevencije greške
8. Minimizovati rad sa
memorijom
9. Izveštaj dijagnoza i popravka grešaka
10. Estetski i minimalistički dizajn
HCI PROJEKAT MAINT 2012
Prof. dr Ljubomir Lazić Tim #4 94
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/