OptimalSQM MAINT sistem za odrzavanje

706 views
531 views

Published on

- U bilo kom upotrebljivom softveru u praksi postoji beskonačan broj mogućih testova koje je praktično nemoguće sve izvesti iz razloga koji su navedeni u postojećoj literaturi. Zbog toga je nemoguće u razumnom vremenskom periodu, sa ograničenim resursima (ljudi, oprema i alati) izvršiti iscrpno (totalno) testiranje koje bi otkrilo sve greške u softveru. Kao moguće rešenje se u ovom radu daje opis komponenti softverske arhitekture sistema OptimalSQM koji omogućava razvoj kvalitetnog softvera na optimalan način. OptimalSQM predstavlja skup najboljih modela i tehnika iz prakse, integrisanih u optimizovan i kvantitativno rukovođen proces testiranja i održavanja softvera, koji proširuju funkciju testiranja na čitav SDLC (Životni ciklus razvoja softvera).

Published in: Technology
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
706
On SlideShare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
4
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

OptimalSQM MAINT sistem za odrzavanje

  1. 1. 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
  2. 2. 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
  3. 3. HCI PROJEKAT MAINT 2012 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 Prof. dr Ljubomir Lazić Tim #4 3
  4. 4. HCI PROJEKAT MAINT 2012 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 Prof. dr Ljubomir Lazić Tim #4 4
  5. 5. HCI PROJEKAT MAINT 2012 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 Prof. dr Ljubomir Lazić Tim #4 5
  6. 6. HCI PROJEKAT MAINT 2012 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 Prof. dr Ljubomir Lazić Tim #4 6
  7. 7. HCI PROJEKAT MAINT 2012 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 Prof. dr Ljubomir Lazić Tim #4 7
  8. 8. HCI PROJEKAT MAINT 2012     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). Prof. dr Ljubomir Lazić Tim #4 8
  9. 9. HCI PROJEKAT MAINT 2012 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. Prof. dr Ljubomir Lazić Tim #4 9
  10. 10. HCI PROJEKAT MAINT 2012 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. Prof. dr Ljubomir Lazić Tim #4 10
  11. 11. HCI PROJEKAT MAINT 2012 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. Prof. dr Ljubomir Lazić Tim #4 11
  12. 12. HCI PROJEKAT MAINT 2012 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. Prof. dr Ljubomir Lazić Tim #4 12
  13. 13. HCI PROJEKAT MAINT 2012 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 Prof. dr Ljubomir Lazić Tim #4 13
  14. 14. HCI PROJEKAT MAINT 2012 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. Prof. dr Ljubomir Lazić Tim #4 14
  15. 15. HCI PROJEKAT MAINT 2012 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. Prof. dr Ljubomir Lazić Tim #4 15
  16. 16. HCI PROJEKAT MAINT 2012 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. Prof. dr Ljubomir Lazić Tim #4 16
  17. 17. HCI PROJEKAT MAINT 2012 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. Prof. dr Ljubomir Lazić Tim #4 17
  18. 18. HCI PROJEKAT MAINT 2012 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 Prof. dr Ljubomir Lazić Tim #4 18
  19. 19. HCI PROJEKAT MAINT 2012 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š Prof. dr Ljubomir Lazić Tim #4 19
  20. 20. HCI PROJEKAT MAINT 2012 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. Prof. dr Ljubomir Lazić Tim #4 20
  21. 21. HCI PROJEKAT MAINT 2012 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 povećava moguć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čujuć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; Prof. dr Ljubomir Lazić Tim #4 21
  22. 22. HCI PROJEKAT MAINT 2012    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. Prof. dr Ljubomir Lazić Tim #4 22
  23. 23. HCI PROJEKAT MAINT 2012 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. Prof. dr Ljubomir Lazić Tim #4 23
  24. 24. HCI PROJEKAT MAINT 2012 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. Prof. dr Ljubomir Lazić Tim #4 24
  25. 25. HCI PROJEKAT MAINT 2012 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. Prof. dr Ljubomir Lazić Tim #4 25
  26. 26. HCI PROJEKAT MAINT 2012 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. Prof. dr Ljubomir Lazić Tim #4 26
  27. 27. HCI PROJEKAT MAINT 2012 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. Prof. dr Ljubomir Lazić Tim #4 27
  28. 28. HCI PROJEKAT MAINT 2012 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. Prof. dr Ljubomir Lazić Tim #4 28
  29. 29. HCI PROJEKAT MAINT 2012 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 Prof. dr Ljubomir Lazić Tim #4 29
  30. 30. HCI PROJEKAT MAINT 2012  Vremenska izvodljivost- realnost rokova u projektu (udeo od 25% u konačnoj ceni) Za izradu MaintSmart sistema potrebno je 7 meseci. 83.5poena. Za izradu FastMaint sistema potrebno je 10 meseci. 72.5poena. Za izradu MStar sistema potrebno je 11 meseci. 70poena. Slika 5.1.3 Dijagram vremenske izvodljivosti  Ekonomska izvodljivost- odnosi troškova projekata (udeo od 25% u konačnoj ceni). Za FastMaint potrebno je:  četiri programera 35$/h,  jedan dizajner 40$/h,  nemaju skladište,  jedan sistem administrator 45$/h,  jedan mreţni administrator 60$/h,  administrator baze podataka 55$/h. Ukupno 120.000$ za 10 meseci. 85 poena Za MStar potrebno je:  pet programera 50$/h,  dva dizajnera 35$/h,  nemaju skladište,  dva sistem administratora 50$/h,  jedan mreţni administrator 60$/h,  administrator baze podataka 70$/h. Ukupno 160.000$ za 12 meseci. 80 poena Za MaintSmart potrebno je:  tri programera 35$/h,  jedan dizajner 35$/h,  nemaju skladište,  dva sistem administratora 45$/h,  jedan mreţni administrator 55$/h,  administrator baze podataka 45$/h. Ukupno 90.000$ za 7 meseci. 95 poena Prof. dr Ljubomir Lazić Tim #4 30
  31. 31. HCI PROJEKAT MAINT 2012 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 Prof. dr Ljubomir Lazić Tim #4 31
  32. 32. HCI PROJEKAT MAINT 2012 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. Prof. dr Ljubomir Lazić Tim #4 32
  33. 33. HCI PROJEKAT MAINT 2012 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. Prof. dr Ljubomir Lazić Tim #4 33
  34. 34. HCI PROJEKAT MAINT 2012 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 Prof. dr Ljubomir Lazić Tim #4 34
  35. 35. HCI PROJEKAT MAINT 2012 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. Prof. dr Ljubomir Lazić Tim #4 35
  36. 36. HCI PROJEKAT MAINT 2012 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. Prof. dr Ljubomir Lazić Tim #4 36
  37. 37. HCI PROJEKAT MAINT 2012 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. Prof. dr Ljubomir Lazić Tim #4 37
  38. 38. HCI PROJEKAT MAINT 2012 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. Prof. dr Ljubomir Lazić Tim #4 38
  39. 39. HCI PROJEKAT MAINT 2012 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. Prof. dr Ljubomir Lazić Tim #4 39
  40. 40. HCI PROJEKAT MAINT 2012 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 Prof. dr Ljubomir Lazić Tim #4 40
  41. 41. HCI PROJEKAT MAINT 2012 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. Prof. dr Ljubomir Lazić Tim #4 41
  42. 42. HCI PROJEKAT MAINT 2012 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, Prof. dr Ljubomir Lazić Tim #4 42
  43. 43. HCI PROJEKAT MAINT 2012  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. Prof. dr Ljubomir Lazić Tim #4 43
  44. 44. HCI PROJEKAT MAINT 2012 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. Prof. dr Ljubomir Lazić Tim #4 44
  45. 45. HCI PROJEKAT MAINT 2012 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. Prof. dr Ljubomir Lazić Tim #4 45
  46. 46. HCI PROJEKAT MAINT 2012 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. Prof. dr Ljubomir Lazić Tim #4 46
  47. 47. HCI PROJEKAT MAINT 2012 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 Prof. dr Ljubomir Lazić Tim #4 47
  48. 48. HCI PROJEKAT MAINT 2012 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. Prof. dr Ljubomir Lazić Tim #4 48
  49. 49. HCI PROJEKAT MAINT 2012 - - 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. Prof. dr Ljubomir Lazić Tim #4 49
  50. 50. HCI PROJEKAT MAINT 2012 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); Prof. dr Ljubomir Lazić Tim #4 50
  51. 51. HCI PROJEKAT MAINT 2012 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. Prof. dr Ljubomir Lazić Tim #4 51
  52. 52. HCI PROJEKAT MAINT 2012 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; Prof. dr Ljubomir Lazić Tim #4 52
  53. 53. HCI PROJEKAT MAINT 2012 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 Prof. dr Ljubomir Lazić Tim #4 53
  54. 54. HCI PROJEKAT MAINT 2012 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. Prof. dr Ljubomir Lazić Tim #4 54
  55. 55. HCI PROJEKAT MAINT 2012 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; Prof. dr Ljubomir Lazić Tim #4 55
  56. 56. HCI PROJEKAT MAINT 2012 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 Prof. dr Ljubomir Lazić Tim #4 56
  57. 57. HCI PROJEKAT MAINT 2012 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, Prof. dr Ljubomir Lazić Tim #4 57
  58. 58. HCI PROJEKAT MAINT 2012 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. Prof. dr Ljubomir Lazić Tim #4 58
  59. 59. HCI PROJEKAT MAINT 2012 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. Prof. dr Ljubomir Lazić Tim #4 59
  60. 60. HCI PROJEKAT MAINT 2012 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. Prof. dr Ljubomir Lazić Tim #4 60
  61. 61. HCI PROJEKAT MAINT 2012 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. Prof. dr Ljubomir Lazić Tim #4 61

×