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

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
3.2

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

3.3

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

3.4
4.

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

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

ANALIZA KONKURENTSKIH REŠENJA ............................................................. 18
4.1

MaintSmart ........................................................................................................ 18

4.1.1

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

4.1.2

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

4.2
4.3

FastMaint ........................................................................................................... 21

4.4
5.

MStar (Mosaic’s Structured Testing and Assessment Repository)....................... 19
Primena Nielsen – ovih pravila ........................................................................... 25

STUDIJA IZVODLJIVOSTI .................................................................................... 28
5.1

6.

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

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
Prof. dr Ljubomir Lazić

Tim #4

2

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
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
9.

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

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

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


Tim #4

3

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

Tim #4

4

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

Tim #4

5

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

Tim #4

6

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


Tim #4

7






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).

Tim #4

8

Tabela 1.1 HCI sadržaj
N

Priroda HCI-a

N1 Meta-modeli HCI-a
U1 Ljudska socijalna organizacija i rad

U

Korišćenje i kontekst kompjutera

U2 Aplikaciona područja
U3 Čovek-kompjuter postavka i prilagođavanje
H1 Ljudsko informaciono procesiranje

H

Ljudske karakteristike

H2 Jezik, komunikacija, interakcija
H3 Ergonomija
C1 Ulazni i izlazni uređaji
C2 Tehnike dijaloga

C

Kompjuterski sistem i interfejs
arhitektura

C3 Vrsta dijaloga
C4

Kompjuterske grafike

C5 Arhitektura dijaloga
D1 Dizajn prilazi
D2 Implementacione tehnike
D

Proces razvoja

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 čovekkompjuter 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.

Tim #4

9

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.


Tim #4

10


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.


Tim #4

11


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.


Tim #4

12


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


Tim #4

13

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.


Tim #4

14

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.


Tim #4

15

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.


Tim #4

16

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.


Tim #4

17


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


Tim #4

18


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š

Tim #4

19

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.


Tim #4

20

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 povećava mogućnost 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čujući
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.

FastMaint

4.3

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;


Tim #4

21





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.


Tim #4

22


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.

Tim #4

23

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.


Tim #4

24

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.


Tim #4

25

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.


Tim #4

26

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.


Tim #4

27

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.


Tim #4

28

odrţavanje softvera za upravljanje prati dobra oprema zatim koristi
podatke da vam pomogne da optimizujete operaciju odrţavanja upravljanja. 65 poena.

MaintSmart

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


Tim #4

29



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,
 dva sistem administratora 50$/h,

Za MaintSmart potrebno je:
 tri programera 35$/h,
 jedan dizajner 35$/h,
 dva sistem administratora 45$/h,


Tim #4

30


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


Tim #4

31


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.


Tim #4

32


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.


Tim #4

33

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


Tim #4

34

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.

Tim #4

35

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.

Tim #4

36

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.


Tim #4

37

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.


Tim #4

38


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.


Tim #4

39

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

Tim #4

40

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.

17%

Ispravke
18%

65%

Prilagođavanje

Dodavanje funkcionalnosti
i modifikacije

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.


Tim #4

41

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,


Tim #4

42

 uklanjanje skrivenih aplikacija,
 povlačenje softvera iz upotrebe.

7%

5%
6%
2%
4%
3%

Testiranje modula
Kodiranje modula
Dizajn
Planiranje
Detaljan opis

67%

Zahtevi
Održavanje

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.


Tim #4

43

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.
Tim #4 44


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.


Tim #4

45


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.


Tim #4

46

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.
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.

Osnovni koraci


Tim #4

47

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.

Tim #4

48

-

-

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.


Tim #4

49

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
Opis

Osnovni koraci

OQT MAINT komponenta
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.
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);


Tim #4

50

9. Softver se šalje na upotrebu.
Zahtev
Rezultat

Korisnik zahteva održavanje softvera.
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.


Tim #4

51

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:

Osnovni koraci

- Korektivno
- Preventivno
- Adaptivno
- Perfektivno
- Troškovi
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;


Tim #4

52

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


Tim #4

53


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.


Tim #4

54

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;


Tim #4

55

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.
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;

Osnovni koraci


Tim #4

56


Zahtev

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.
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,


Tim #4

57

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.


Tim #4

58


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.


Tim #4

59


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.


Tim #4

60


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.


Tim #4

61

OptimalSQM MAINT sistem za odrzavanje

OptimalSQM MAINT sistem za odrzavanje

Empfohlen

Empfohlen

Weitere ähnliche Inhalte

Ähnlich wie OptimalSQM MAINT sistem za odrzavanje

Ähnlich wie OptimalSQM MAINT sistem za odrzavanje (20)

OptimalSQM MAINT sistem za odrzavanje