SOFTVERSKO INŽENJERSTVO ( SHARI LAWRENCE PFLEEGER )

1 ŠTA JE SOFTVERSKO INŽENJERSTVO

Prilikom rešavanja problema, softverski inženjeri koriste poznavanje računara i računarstva. Osnovno je razumeti prirodu problema koji je često u vezi sa računarom i računarskim tehnikama ali i ne mora biti odnosno ne mora biti u potpunosti. U procecu rešavanja problema, vidi se da li je neka vrsta računarskog sistema neophodna ili poželjna.

REŠAVANJE PROBLEMA

Istraživanje problema započinjemo analizom tj. razlaganjem problema na delove koje možemo da razumemo. Na osnovu toga možemo jedan problem opisati kao skup manjih, medjusobno povezanih problema ili potproblema gde je važno uočiti veze medju njima..

ANALIZA

Kada je obavljena analiza problema sledi sastavljanje kompletnog rešenja iz delova koji se odnose na različite aspekte problema tj sinteza kao suprotni proces analizi. To je sklapanje veće strukture na osnovu manjih gradivnih elemenata.

SINTEZA

PROBLEM

Problem 1 Problem 2

Problem 3

Problem 4

REŠENJE 1 REŠENJE 2

REŠENJE 3

Rešenje 4

REŠENJE

Rešavanje problema može biti potpomognuto različitim metodama( ili tehnikama), alatima,procedurama i paradigmama.

Metod ili tehnika je formalna procedura za pravljenje nečega

Alat je instrument ili automatizovani sistem koji pomaže da se nešto obavi na bolji način. To može značiti da pomoću alata radimo preciznije,efikasnije ili kao rezultat dobijemo kavalitetniji proizvod. Alat nije uvek neophodan da bi se nešto napravilo dobro.

Procedura je kao recept, kombinacija alata i tehnika koji, u medjusobnom skladu, čine proizvod.

Paradigma , kao stil rada, predstavlja poseban pristup ili filozofiju gradnje softvera. Kao primer je proceduralno ili objektno orijentisano projektovanja softvera, nije neki stil bolji od drugog već svaki ima neke prednosti u odredjenoj situaciji.

Softverski inženjeri koriste metode(tehnike), alate, procedure i paradigme da bi poboljšali kvalitet softverskih proizvoda.

GDE SE TU UKLAPA SOFTVERSKO INŽENJERSTVO

Treba da razumemo kako se softverski inženjer uklapa u svet računarske nauke. Možemo da to gledamo kroz računare i programske jezike, ili da gledamo kroz alate koji se koriste u projektovanju i primeni rešenja nekog problema.Softversko inženjerstvo predstavlja ovaj drugi pogled. Umesto da istražuje dizajn hardvera ili dokazuje teoreme iz teorija algoritama, softverski inženjer se usresredjuje na računar, kao sredstvo za rešavanje problema.

RAČUNARSKA NAUKA KUPAC

TEORIJA Funkcije računara Problem

SOFTVERSKO INŽENJERSTVO

Alati i tehnike za rešavanje problema

2 KOLIKO SMO BILI USPEŠNI

Suština rada softverskog inženjera je u projektovanju i razvoju visoko kvalitetnog softvera. Softver inženjeri proučavaju računarske mehanizme i teorije da bi ih učinili produktivnijim, efikasnijim.Ali isto tako oni projektuju računarske sisteme i pišu programe za obavljanje poslova na tim sistemima.

Da li su korisnici zadovoljni sa postojećim softverskim sistemima.Softver nam je omogućio da radimo poslove brže i efikasnije nego ikada do sada. Kako se radilo pre pojave programa za obradu teksta, radnih tabela,elektronske pošte... Softver podržava održavanje i spasavanje života u medicini, poljoprivredi, transportu itd..Softver je omogućio mikrooperativne zahvate, multimedijlno obrazovanje, robotiku itd..

Ali i softver se bori sa svojim problemima, sistemi često ne funkcionišu na način kako mi očekujemo.

Znamo da neki sistemi jedva da rade, postoji programi sa greškama, programi koji treba da se „pridržavaju“ dok rade, programi dovoljno dobri da se nešto prezentuje ali da niko ništa ne pita.Takav način rada nije prihvatljiv kada se razvija sistem koji treba isporučiti kupcu.

Greške su veoma različite u zavisnosti u kom sistemu su smeštene, nije isto ako je to seminarski rad ili sistem koji prati prodaju karata za autobus ili sistem za praćenje leta aviona. Ima grešaka koje su banalne, ima onih koje nas koštaju vremena i novca, ali ima i onih koje su opasne po život.

Znači, nije svejedno kada će sistem da otkaže, zbog greške ili nedostatka. Sistem može da pokaže grešku u toku projektovanja, testiranja, instalacije ali i eksploatacije.

Neočekivana upotreba sistema mora da se uzme u obzir u toku razvoja softvera.To se može obaviti na dva načina: zamišljanjem kako sve softver može biti pravilno upotrebljavan ili zloupotrebljavan pretpostavliti da će sistem biti zloupotrebljavan i projektovati softver kao odgovor na tu zloupotrebu.

Proizvodjači softvera teže izradi sistema bez mana ali i pored toga mnogi softveri sadrže nedostatke. Kako tržište zahteva brzi razvoj softvera, ostaje malo vremena za testiranje.Kod testiranja se obično obrati pažnja na one delove koji će se koristiti sa većom verovatnoćom ili one koji će najviše smetati korisniku. Zato su mnogi korisnici skeptični kod instalacije prve verzije softvera, znajući da obično ima grešaka.

Ako je u pitanju nedostatak, koji može biti posledica nesporazuma na relaciji programski zahtev – analitičar ili analitičar i korisnik - projektant, nekad je lakše napisati kompletan softver ispočetka, nego modifikovati postojeći sa nedostatkom.

Vrlo je bitno u kojoj fazi životnog ciklusa softvera se otkrije greška. Naravno, što je faza otkrivanja greške ranija, to greška manje košta.

3 ŠTA JE DOBAR SOFTVER

Kvalitet softvera posmatramo na najmanje tri načina:

Kvalitet proizvoda, kvalitet procesa , kvalitet u kontekstu poslovnog okruženja

KVALITET SOFTVERA

Kvalitet softvera gleda se u zavisnosti ko ga analizira, pa ako je to korisnik on će verovatno potencirati spoljašne karakteristike, nedostatke i broj otkaza, funkcionalnost, laku obuku i sl.

Ako softver procenjuju oni koji pišu kod, ili projektuju, ili čiji je zadatak dalje održavanje programa, oni teže razmatranju internih karakteristika proizvoda, često pre nego što je i isporučen kupcu. Oni posmatraju broj i tip nedostataka kao dokaz kvaliteta. Programeri mogu da prate broj nedostataka u okviru programskih zahteva i na osnovu toga donesu sud o kvalitetu.

Zato se prave modeli koji dovode u vezu spoljašnji pogled korisnika i unutrašnji pogled praktičara na softver.

KVALITET PROCESA

Mnoge aktivnosti utiču na konačni kvalitet softvera i ako neka od njih podje naopako to može da pogorša kvalitet. Zbog toga mnogi softverski inženjeri osećaju da je kvalitet postupka razvoja i održavanja važan isto kao i kvalitet proizvoda.

KVALITET U KONTEKSTU POSLOVNOG OKRUŽENJA

Unapredjenje tehničkih vrednosti se automatski odslikava na unapredjenje poslovne vrednosti i u tom aspektu se moze posmatrati kvalitet proizvoda u okviru neke kompanije. Neko meri kvalitet softvera na osnovu odnosa vremena operativnosti i vremena zastoja, troškova održavanja, troškove izmena i sl. Ako ne postoji jasna poslovna vrednost, projekat se ne pokreće.

4 KO SE BAVI SOFTVERSKIM INŽENJERSTVOM?

Komunikacija izmedju kupca i projektanta je kljčna za uspeh projekta. Da bi se napravio sistem koji će kupcu da olakša i ubrza posao, mora se razumeti šta mu je potrebno.

Koji su pojedinci uključeni u razvoj softvera?

Broj osoba koje su uključene u razvoj softvera zavisi od veličine projekta i stepena složenosti. Ma koliko ljudi da je uključeno, njihove uloge se jasno razlikuju. Kod velikog projekta, svim pojedincima ili grupama može biti dodeljena jedna od identifikovanih uloga. Kod malog projekta, jedna osoba može da ima istovremeno više uloga.

Najčešće, učesnici u projektu imaju jednu od tri uloge: kupac, korisnik i projektant.

KUPAC je kompanija, organizacija ili pojedinac koji plaća za softverski sistem koji se razvija

PROJEKTANT je kompanija, organizacija ili pojedinac koji pravi softverski proizvod za kupca, uključujući tu i rukovodioce potrebne za koordinaciju sa programerima i testerima.

KORISNIK je jedan ili više pojedinaca koji će stvarno koristirti sistem sedeći za terminalom, unoseći podatke i čitajući rezultate.

Iako kod nekih projekata, ista grupa ili pojedinac može da predstavljea i kupca i projektanta i korisnika,

u većini slučajeva se radi o različitim pojedincima ili grupama.

Ove tri grupe se prepliću i to se vidi u različitim primerima:

Firma može da bude toliko velika da ima sopstveni tim za razvoj softvera i tada taj sektor može da odluči da želi automatski alat koji će pratiti troškove sopstvenih projekata. Ako taj alat sami prave, taj sektor je istovremeno korisnik, kupac i projektant.

5 SISTEMSKI PRILAZ

Hardver i softver koje sastavljamo nisu nezavisni, već su u interakciji sa korisnicima softvera, sa drugim softverima, bazama podataka(kao pažljivo definisanim skupovima podataka i odnosima medju njima), ili čak sa drugim sistemima.Stoga je važno odrediti granice sistema tj šta je uključeno u projekt a šta ne.

(Primer : obračun zarada i izrada štampanih listića za plate )

U stvari postavlja se pitanje gde započinje projekt i gde se završava.

ELEMENTI SISTEMA

AKTIVNOSTI I OBJEKTI

Aktivnosti su neka dešavanja u sistemu, dogadjaj iniciran nekim okidačem, koji transformiše neku stvar dajući joj nove osobine. Kod IS tu su razne promene na podacima, kao premeštanje lokacijski, promena vrednosti, komponovanje sa drugim podacima da bi se napravio ulaz za novu aktivnost itd. Elementi uključeni u aktivnost zovu se objekti, koji mogu da budu grupisani u zapise. Npr. zapis o učešću radnika na poslu može biti zapisan na ovaj našin: Ime, Srednje slovo, Prezime, Adresa, Mesto, Poštanski broj, Satnica, Dodaci, Sati rada, Sati bolovanja, Slobodni sati Date su osobine kaotip podatka,početne pozicije i dužine polja ( npr. prezime varchar (50) ).

ODNOSI I GRANICE SISTEMA

Odnosi izmedju entiteta i aktivnosti su jasno definisani. Objekti mogu da se koriste u okviru posmatranog sistema ili ga koriste i drugi sistemi, ili posmatrani sistem koristi objekte iz drugih sistema. Sama ova pojava govori nam da sistem ima svoje granice. Ove granice sistema treba definisati.

Sada sistem možemo definisati kao: skup objekata(entiteta), skup aktivnosti, opis odnosa izmedju objekata i aktivnosti, definiciju granica sistema.

Primer granica sistema obračuna plata radnika:

KUPAC

Finansira razvoj sistema

PROJEKTANT

Gradi sistem

KORISNIK

Koristi sistem

6 INŽENJERSKI PRISTUP

Kada shvatimo prirodu sistema, spremni smo da započemo njegovo konstruisanje. Razvoj softvera podrazumeva korisnike, kupce i razvojni tim. Prvi korak je sastajanje sa kupcem radi definisanja zahteva. Ti programski zahtevi opisuju sistem.Bez poznavanja granica, entiteta i aktivnosti nemoguće je opisati softver, kao i to kako će on biti u interakciji sa okruženjem.

Ovde treba kupcu predstaviti snimke ekrana koji će se koristiti, izveštaje koji će se generisati, i sve ostalo što opisuje interakciju budućeg sistema i korisnika.

Kada kupac odobri projekat, on se koristi za generisanje podprojekata. Tek se sada uključuju programeri i prave se zahtevi za kodiranje.Kada se programi napišu,oni se testiraju kao pojedinačni delovi. Ako rade dobro, sastavljaju se u celinu i dolazi do faze integrativnog testiranja. Finalno testiranje ili testiranje sistema podrazumeva testiranje celokupnog sistema, da bi proverili da li su pravilni implementirane funkcije i interakcije koje su zadate na početku.Razvojni tim, kupac i korisnici proveravaju da li sistem služi svojoj nameni.

Dakle razvoj softvera obuhvata sledeće aktivnosti:

analiza i definisanje zahteva

projektovanje sistema

projektovanje programa

pisanje programa

testiranje jedinica

integrativno testiranje

testiranje sistema

isporuka sistema

održavanje

FIRMA koja obračunava plate

Kontrola

Datum isplate

Štampa

DISTRIBUCIJA

7 ČLANOVI RAZVOJNOG TIMA

Razvojni tim podrazumeva jednog ili više ANALITIČARA ZAHTEVA u radu sa kupcima, kako bi se ono što hoće kupac razložilo na pojedinačne zahteve

Dalje, kada zahtevi postanu poznati i dokumentovani, ANALITIČAR radi sa PROJEKTANTIMA na generisanju opisa funkcija sistema.

Sada PROJEKTANTI rade sa PROGRAMERIMA tako da ovi dobijaju zahteve za pisanje koda.

Posle generisanja programskog koda, on mora da se testira.Prvo testiranje obavljaju sami programeri. Ponekad se koriste drugi testeri, kao pomoć u otkrivanju grešaka koje previde sami programeri. Kada se jedinice koda integrišu u funkcionalne grupe, timovi za testiranje rade zajedno sa timom za implementaciju na verifikovanju ispravnosti rada u skladu sa zahtevima(specifikacijom).

Sada tim za testiranje zajedno sa kupcem rade na verifikovanju celokupnog sistema.

Iza toga INSTRUKTORI obučavaju korisike za operativno korišćenje sistema.

Tehnički prijem kod mnogih softvera ne znači i kraj razvoja. Ako se pojave neki nedostaci posle prijema sistema, njih ispravlja tim za održavanja. Pored toga, potrebe kupca se mogu menjati i da to inicira doradu ili promenu sistema.

ULOGE RAZVOJNOG TIMA

ANALIZA I DEFINISANJE SISTEMA Analitičar

PRPJEKTOVANJE SISTEMA Analitičar, Projektant

PROJEKTOVANJE PROGRAMA Projektant, Programer

IMPLEMENTACIJA PROGRAMA Programer

TESTIRANJE JEDINICA Testni inženjer,Programer

INTEGRATIVNO TESTIRANJE Projektant, Programer

TESTIRANJE SISTEMA Analitičar, Projektant, Programer

ISPORUKA SISTEMA Instruktor

ODRŽAVANJE

MODELOVANJE PROCESA I ŽIVOTNOG CIKLUSA

Softversko inženjerstvo je stvaralački I postupan proces, koji okuplja veliki broj ljudi na poslovima izrade različitih vrsta proizvoda.

1 ZNAČENJE TERMINA PROCES

Procesom možemo smatrati niz koraka koji obuhvataju aktivnosti, ograničenja I resurse, I rezultiraju željeno ostvarenje. Proces obično uključuje skup alata I tehnika.

Svaki proces poseduje sledeće karakteristike:

1 Proces propisuje sve glavne aktivnosti

2 Proces koristi resurse, koji podležu skupu ograničenja (kao što je raspored), I rezultira medjuproizvodima I finalnim proizvodima

3 Proces može da se sastoji od medjusobno povezanih podprocesa. Može biti definisan kao hijerarhija drugih procesa, organizovanih tako da je svaki podproces zasnovan na vlastitom modelu

4 Svaka aktivnost u sklopu procesa poseduje uslove za pokretanje I terminiranje

5 Aktivnosti su organizovane u sekvence, tako da je jasno kada se jedna aktivnost izvodi u odnosu na druge

6 Svaki process poseduje skup uputstava koja objašnjavaju ciljeve svake aktivnosti

7 Ograničenja ili kontrole mogu da se primene na aktivnosti, resurse ili proizvod.(npr. Budžet može da ograniči trajanje pojedine aktivnosti )

Ponekad proces izrade softverskog proizvoda nazivamo životni ciklus softvera jer opisuje “život” softverskog proizvoda od formulisanja, izrade, implementacije, operativnog korišćenja I održavanja.

Procesi su važni zato što omogućavaju stalni skup aktivnosti, posebno je to važno kada posedujemo znanja da nešto uradimo dobro, a želimo da I drugi to urade na isti način.( metodologiju uopšte). Proces razvoja softvera može se opisati fleksibilno tako da pojedinci mogu da koriste alate I resurse koji njima više odgovaraju, a da se pri tome održi nivo kvaliteta proizvoda.

Proces je složeniji pojam od postupka, on u sebi sadrži više postupaka I može da sugeriše da se različiti postupci ponavljaju, sve dok se ne postigne unapred zadati cilj.

Procesi su takodje važni jer omogućavaju evidentiranje iskustava I njihovo prosledjivanje drugima.

Videli smo da razvoj softvera obično obuhvata sledeće faze:

analiza i definisanje zahteva, projektovanje sistema,projektovanje programa,pisanje programa,testiranje jedinica, integrativno testiranje, testiranje sistema, isporuka sistema, održavanje

Svaka faza sama po sebi predstavlja proces ili skup procesa, koji se može opisati skupom aktivnosti pri čemu svaka aktivnost uključuje ograničenja, ulaze, izlaze I resurse. Npr. prva faza, analiza I definisanje zahteva kao početni ulaz koristi iskaze, koje je formulisao korisnik na neki od mogućih načina, vezane za tražene osobine proizvoda. Finalni rezultat ove faze je skup zahteva ali to može biti I medjuproizvod, jer

dijalog izmedju korisnika I razvojnog tima generiše izmene I različite varijante. (Ovo iznaloaženje raznih varijanti se mora ograničiti budžetom, terminom itd. kao I načinom zapisivanja aktivnosti u dokumentaciju).

Svaka faza razvoja može da se posmatra na više načina. Npr proces projektovanja može da zahteva izradu prototipa na kome se unapred mogu proveriti mnoge projektantske odluke.

Svaki proces može da se opiše na različite načine pomoću teksta, slika ili njihovom kombinacijom. Postoje različite forme takvih opisa, odnosno organizovani modeli koji sadrže ključne odlike procesa.

2 MODELI PROCESA IZRADE SOFTVERA

U oblasti softverskog inženjerstva, opisani su mnogi modeli procesa. Izrada modela procesa I razmatranje njegovih podprocesa pomažu projektnom timu da shvati razliku izmedju toga šta bi trebalo da bude I šta stvarno jeste. Kada grupa opiše process projektovanja koji primenjuje, opis postaje zajedničko shvatanje aktivnosti, resursa I ograničenja uključenih u razvoj softvera. Modelovanje procesa pomaže projektnom timu da pronadje nedoslednosti, viškove I izostavljene elemente u samom procesu ili njegovim delovima. Model treba da odražava ciljeve razvoja kao što je izrada softvera visokog nivoa kvaliteta, otkrivanje grešaka u ranim fazama razvoja, ostajanje u okvirima budžeta I rokava itd.

Svaki model procesa razvoja softvera kao ulaz koristi specifikaciju zahteva, a kao izlaz isporučeni proizvod.

MODEL VODOPADA

Model vodopada podrazumeva da jedna faza u razvoju softvera treba da se u potpunosti okonča, da bi druga započela. Zbog toga, tek kada su svi zahtevi kupaza iskazani, analizirani sa aspekta potpunosti I doslednosti, dokumentovani razvojni tim može da nastavi sa aktivnostima u vezi sa dizajnom sistema. Posle svake aktivnosti dati su I izveštaji, tako da rukovodioci projekta, na osnovu pojedinih modula mogu da mere stepen gotovosti projekta. Model vodopada je koristan zato što se jednostavno može videti šta još projektni tim treba da uradi.

Mnogi drugi, složeniji modeli, u stvari predstavljaju ulepšani model vodopada, kroz uključivanje povratnih sprega I dodatnih aktivnosti.

Najveći problem kod modela vodopada je što on ne odražava stvarni način na koji se projekat razvija. Osim samo za jednostavne problem, softver se razvija kroz veliki broj iteracija.

Analiza zahteva

Projektovanje sistema

Projektovanje programa

Kodiranje

Testiranje delova i celine

Testiranje sistema

Završno testiranje

Operativni rad i održavanje

Validacija

Verifikacija

Modifikovani model vodopada sa izradom prototipa

V MODEL

V model je modifikovani model vodopada, koji pokazuje odnos testiranja I faza analize I dizajna. Kodiranje je ishodište V modela, dok su na levoj strani analiza I projektovanje a na desnoj testiranje I održavanje. V model sugeriše da testiranje delova I testiranje pri integraciji mogu da se koriste za verifikovanje dizajna programa. Slično tome, testiranje sistema treba da verifikuje dizajn sistema. Završni test sistema služi validaciji zahteva.

Analiza zahteva

Projektovanje sistema

Projektovanje programa

Kodiranje

Testiranje delova i celine

Testiranje sistema

Završno testiranje

Operativni rad i održavanje

IZRADA PROTOTIPA

V model

PROTOTIPSKI MODEL

Izrada prototipa ne mora da bude samo dopuna modela vodopada već sama po sebi može da bude osnov za efikasno modelovanje procesa. Prototipski model omogućava da se kompletan sistem ili neki njegovi funkcionalni delovi brzo konstruišu I tako omoguće bolje razumevanje otvorenih pitanja.

FAZNI RAZVOJ: INKREMENTI I ITERACIJE

Današnja poslovna okrućenja ne tolerišu duga čekanja kod izrade softvera. Jedan od načina smanjenja vremena izrade prijekta je tkz. fazni razvoj. Sistem se projektuje tako da može da se isporučuje u delovima, omogućujući korisnicima da raspolažu sa nekim funkcijama, dok su druge još u razvoju. Tako imamo dva sistema, koji uporedo funkcionišu, produkcioni sistem I razvojni sistem. Produkcioni sistem je onaj koji trenutno koriste naručilac I korisnik. Razvojni sistem predstavlja sledeću verziju koja se priprema da zameni ( ili dopuni ) postojeći produkcioni sistem.

Analiza zahteva

Projektovanje sistema

Projektovanje programa

Kodiranje

Testiranje delova i celine

Testiranje sistema

Završno testiranje

Operativni rad i održavanje

Razvojni sistem

Produkcioni sistem

Dva najpopularnija pristupa faznom razvoju su inkrementalni razvoj I iterativni razvoj.

Kod inkrementalnog razvoja, sistem onako kako je definisan se deli na podsisteme prema funkcijama. Verzije se definišu kao mali funkcionalni sistemi, a zatim se svakoj novoj verziji pridodaju nove funkcije.

Kod iterativnog razvoja, isporučuje se odmah pun sistem, a zatim se menjaju funkcije podsistema u svakoj novoj verziji.

Neki delovi sistema u prvoj verziji mogu sadržati primitivna rešenja, toliko da se sagleda celina, izvrši obuka I sl.

Prednosti faznog razvoja su:

Obuka može da započne sa prvom verzijom. Izvršenje nekih funkcija može da sugeriše projektnom timu šta ispraviti u sledećim verzijama.

Na tržište može da se izadje vrlo rano, posebno ako se radi o funkcionalnostima koje ranije nisu obradjene.

Česte verzije omogućavaju projektnom timu da brzo otkloni nepredvidjene probleme

Projektni tim može da se usresredi na različite oblasti usavršavanja sistema

Izrada verzije 1 Izrada verzije 2

Upotreba verzije 1 Upotreba verzije 2 Upotreba verzije 3

Izrada verzije 3

PLANIRANJE PROJEKTA I UPRAVLJANJE NJIM

Ciklus razvoja softvera se sastoji od više koraka, od kojih se neki od njih ponavljaju, sve dok se ne postigne željeni cilj I naručilac I korisnik ne budu zadovoljni. Obično naručilac želi da zna koliko će projekat da košta, pre nego se I odobre sredstva. U ovoj temi ispitujemo aktivnosti koje su neophodne za planiranje razvojnog projekta I upravljanje njim.

Softversko inženjerstvo je stvaralački I postupan proces, koji okuplja velik broj ljudi na poslovima izrade različitih vrsta proizvoda.

1 PRAĆENJE NAPRETKA

Prilikom početne komunikacije, kada je naručilac izneo svoje potrebe, kao na primer:

Zdravstvena ustanova ima potrebu za izradu softvera kojim bi bilo omogućeno zakazivanje pregleda kod odredjenog lekara.

Obično naručilac ima nekoliko pitanja na koje treba dati odgovor:

Da li razumete moj problem I moje potrebe

Da li možete da projektujete sistem koji bi rešio moj problem I zadovoljio moje potrebe

Koliko vremena će vam biti potrebno da razvijete taj sistem

Koliko će koštati razvoj tog sistema

Odgovor na poslednja dva pitanja zahteva postojanje dobro osmišljenih rokova za aktivnosti na projektu. Projektni rokovi opisuju razvojni ciklus nekog softvera, sa fazama ili etapama od kojih je svaka razbijena na izolovane zadatke ili aktivnosti koje je potrebno realizovati, odslikava interakcije izmedju tih aktivnosti I odredjuje rokove I trajanje svakog zadatka ili aktivnosti. Dakle, rokovi predstavljaju vremensku osu koja prikazuje kada počinju aktivnosti I kada se završavaju.

U prepoznavanju potreba naručioca (kupca ili korisnika) kako bismo ih shvatili, istovremeno proveravamo da li su oni zadovoljni na koji način smo prepoznali njihove potrebe, I navodimo sve medjuproizvode tj. stavke koje naručilac očekuje da dobije tokom razvoja projekta. U medjuproizvode spadaju:

dokumenti

demonstracija funkcija

demonstracija podsistema

demonstracija tačnosti

demonstracija pouzdanosti, bezbednosti I performansi

Nakon toga utvrdjujemo koje aktivnosti moraju da se sprovedu u cilju realizacije projekta. Pažljivim ispitivanjem projekta možemo podeliti razvoj na niz faza, svaka faza se sastoji od niza koraka a svaki korak može biti predmet dalje podele.

Faza 1 Korak 1.1 Aktivnost 1.1.1

Korak 1.2 Aktivnost 1.1.2

Korak 1.3 Aktivnost 1.1.3

PROJEKAT Faza 2

Faza 3

STRUKTURA POSLOVA I GRAF AKTIVNOSTI

Analiza ove vrste se opisuje kao proces generisanja vrste poslova u okviru projekta, budući da opisuje projekat kao skup diskretnih poslova. Svaku aktivnost možemo opisati sa četiri parametra:

Prethodnik je dogadjaj ili skup dogadjaja, koji moraju da se dogode pre nego što posmatrana aktivnost započne.

Trajanje je vreme potrebno za kompletiranje aktivnosti

Krajnji rok je datum do kojeg aktivnost mora biti okončana, što je često definisano ugovorenim krajnjim rokovima

Krajnja ta čka je oznaka ili medjuproizvod koja kaže da je aktivnost završena.

Radi opisivanja zavisnosti, možemo nacrtati graf aktivnosti.

Graf aktivnosti možemo učiniti još korisnijim dodavanjem informacija o proceni vremena koje je potrebno za dovršetak svake aktivnosti. Za posmatranu aktivnost, odgovarajuću granu grafa označavamo brojem koji predstavlja procenjeno vreme realizacije.

Grafički opis projekta dosta govori o vremenskim rokovima projekta. Ovakva analiza putanja izmedju oznaka završenosti se naziva metod kriti čne putanje.Putanje mogu da pokažu minimalno potrebno vreme za završetak projekta, dajući nam procenu trajanja svake aktivnosti.

Graf aktivnosti sa trajanjima.

POČETAK

15 3

10

10

15

20

10 12

10 15

8 9

11

5 18

9 7

6 0

0 0

0

ZAVRŠETAK

1.2 1.1

1.3

1.4

2.1

2.2

2.3 3.1

2.4

2.5

2.6

2.7

3.2

3.3

3.4

3.5

3.6 2.8

2 OSOBLJE NA PROJEKTU

Da bi odredili rokove za projekat I procenili potreban rad I troškove, treba da, barem otprilike znamo broj ljudi koji će raditi na projektu, na kojim poslovima, kao I koje specijalnosti I iskustvo oni moraju posedovati radi efikasnog izvršavanja dodeljenih poslova.

ULOGE I KARAKTERISTIKE TIMA

Neki od ljudi zaposlenih na izradi projekta su zaduženi da razgovaraju sa korisnicima, neki na dizajniranju, neki pišu ili testiraju programe. Znači, ne izvršava svaki zadatak isti čovek ili grupa ljudi.

Dodeljivanje radnika zadacima zavisi od veličine projekta, iskustva I obučenosti osoblja. Velika je prednost ako se različiti zadaci dodeljuju različitim grupama ili pojedincima, zbog kontrole I izbalansiranosti sistema, koji omogućavaju otkrivanje grešaka u ranoj fazi razvoja. Tako je dobro da programeri ne testiraju programe, nego da taj posao obave testeri. Programer bi u testiranju lako prešao preko greške koju je napravio tokom programiranja. Slično, dobro je da projektanti sistema I projektanti programa ne budu iste osobe.

Nakon donošenja odluke o ulogama članova projektnog tima, neophodno je doneti i o ljudima koji su za svaku od njih potrebni. Osoblje projekta može da se razlikuje na više načina, I nije dovoljno da kažemo da projekat, na primer, zahteva jednog analitičara, dva projektanta I pet programera. Dve osobe koje konkurišu za isto radno mesto mogu da se razlikuju po najmanje jednom od sledećih kriterija:

sposobnost izvršavanja posla

interesovanje za posao

iskustvo sa sličnim aplikacijama

iskustvo sa sličnim alatima I jezicima

iskustvo sa sličnim tehnikama

iskustvo sa sličnim razvojnim okruženjem

obučenost

sposobnost komunikacije sa drugima

sposobnost podele odgovornosti sa drugima

sposobnost rukovodjenja

ORGANIZACIJA PROJEKTA

Članovi tima nekog projekta su organizovani na način koji doprinosi brzoj izradi kvalitetnog proizvoda. Izbor odgovarajuće strukture projekta zavisi od nekoliko činilaca, a to su:

biografije I stilovi rada članova tima

broj ljudi u timu

načini rukovodjenja koji primenjuju naručilac I razvojni tim

Dobri rukovodioci projekta su svesni tih pitanja i traže članove tima koji su dovoljno fleksibilni za interakciju sa svim učesnicima, bez obzira na stil rada.

Primer jedne organizacione strukture:

3 POTREBAN RAD

Jedno od prelomnih gledišta planiranja I upravljanja projektom jeste shvatanje koliko će projekat približno da košta. Prekoračenja troškova mogu dovesti do toga da se od projekta odustane a isto tako potcenjivanja cene rada može dovesti da projektni tim deo poslova radi bez finansijske nadoknade. Dobra procena troškova, u ranoj fazi životnog ciklusa projekta pomaže rukovodiocu projekta da utvrdi broj ljudi neophodnih za razvoj I dogovori da odgovarajuće osoblje bude na raspolaganju upravo kada je to potrebno.

Iz budžeta projekta pokriva se više vrsta troškova : sredstva, osoblje, metodi I alati

Sredstva obuhvataju: hardver, prostor, nameštaj, telefon, klimatizacija, kablovi, diskovi, papir, olovke,aparat za fotokopiranje I sve druge stavke koje čine fizičko okruženje u kom će raditi projektni tim. Pored toga potrebno je nabaviti softver I alate za podršku aktivnostima. Veliki udeo u troškovima uglavnom ima uloženi rad I zato je potrebno što pre odrediti koliko ja potrebno dana ljudskog rada za izradu projekta.

Predvidjanje troškova, rokova I potrebnog rada moraju da se urade u ranim fazama životnog ciklusa projekta, jer direktno utiču na dodeljivanje resursa I mogućnost realizacije projekta. Svakako ove procene treba revidirati više puta u toku razvoja, jer može biti u startu loša procena, ali mugu se desiti i novine koje utiču na troškove.

4 UPRAVLJANJE RIZICIMA

Rukovodioci moraju da odrede da li neki neželjeni dogadjaj može da se desi tokom razvoja, pa zato prave planove za izbegavanje tih dogadjaja ili minimizaciju njihovog uticaja na projekat, ako se oni ipak dese.

Glavni programer

Pomoćnik glavnog

programera

Stariji programeri Bibliotekar Administracija Tim za testiranje

Mladji programeri

5 PLAN PROJEKTA

Plan projekta u pisanom obliku sadrži korisnikove potrebe-zahteve I naše namere vezane za zadovoljenje tih potreba-zahteva. Planom iskazujemo predvidjene troškove, rokove, organizaciju, rizike I upravljanje njima I sl.

Dobar plan projekta mora da ima sledeće elemente:

Obim projekta

rokove projekta

organizaciju projektnog tima

tehnički opis predloženog sistema

standarde koji se u projektu koriste

plan osiguranja kvaliteta

plan upravljanja konfiguracijom

plan dokumentovanja

plan upravljanja podacima

plan upravljanja resursima

plan testiranja

plan obuke

plan bezbednosti

plan upravljanja rizicima

plan održavanja

EVIDENTIRANJE ZAHTEVA

Jedno ispitivanje iz 1995 godine je trebalo da utvrdi koji su uzroci neuspeha projekata I evo prvih osam na toj lestvici:

1 nekompletni zahtevi (13,1%)

2 nedovoljno učešće korisnika (12,4%)

3 nedoststak resursa (10,6%)

4 nerealna očekivanja (9,9%)

5 odsustvo podrške rukovodstva (9,3%)

6 izmene zahteva I specifikacija (8,7%)

7 odsustvo planiranja (8,1%)

8 sistem više nije bio potreban (7,5%)

1 PROCES VEZAN ZA ZAHTEVE

Naručilac kroz zahteve želi da automatizuje poslove koji se obavljaju ručno, poboljša već automatizovane poslove ili da radi poslove koji do sada nisu uopšte radjeni. Bez obzira na to da li je odredjena funkcionalnost stara ili nova, predloženi softverski sistem poseduje namenu, obično izraženu ciljevima ili željenim ponašanjem.

Zahtev predstavlja izraz željenog ponašanja. Zahtev se bavi objektima ili entitetima, stanjima u kojim oni mogu biti, kao I funkcijama koje se izvode radi promene stanja ili osobina objekta. Zahtev ne odredjuje implementaciju sistema, bazu podataka koja će se koristiti, koja arhitektura, koliko memorije na računaru treba da ima, koji programski jezik I sl. Cilj faze definisanja zahteva je razumevanje problema i potreba naručioca. Dakle, zahtevi su okrenuti naručiocu I problemu, a ne rešenju ili implementaciji. Kažemo da zahtevi označavaju kakvo ponašanje naručilac želi, bez izražavanja kako će to ponašanje biti ostvareno. Rasprava o rešenju je preuranjena sve dok se problem jasno ne definiše.

Tokom faze specifikacije zahteva, odlučićemo koje zahteve će projektovani softverski sistem da ispuni a koje, suprotno tome, će da odrade hardverski uredjaji posebne namene, drugi softverski sistemi, korisnici ili operateri.

Izvršilac posla evidentiranje zahteva je obično analitičar zahteva ili analitičar sistema. Analitičar zahteva prvo radi sa naručiocima na izvodjenju zahteva: postavlja pitanja, ispituje aktuelno ponašanje ili demonstrira slične sisteme. Zatim se zahtevi evidentiraju u obliku modela ili prototipa. Kada se postigne dobro razumevanje zahteva, posao se nastavlja izradom specifikacije, u kojoj se odlučuje koji će delovi zahtevanog ponašanja biti uključeni u softveru. Tokom validacije, proverava se da li specifikacija odgovara onome što naručilac želi da vidi u finalnom proizvodu. Aktivnosti analize I validacije mogu da otkriju probleme ili propuste u modelu I specifikaciji, što prouzrokuje ponovne posete naručiocu I revidiranje modela I specifikacije. Krajnji ishod ovog procesa je specifikacija softverskih zahteva, koja se koristi za komunikaciju

sa drugim članovima razvojnog tima (npr dizajniranje, testiranje, održavanje), o tome kako konačni proizvod treba da se ponaša.

Proces evidentiranja zahteva: Prikupljane korisničkih zahteva; Razumevanje I modelovanje željenog ponašanja; Dokumentovanje ponašanja predloženog softverskog sistema; Provera da li specifikacija odgovara korisničkim zahtevima.

2 IZVODJENJE ZAHTEVA

Izvodjenje zahteva je posebno važan deo procesa. Ponekad, kada se automatizuje neki ručni sistem, lako je otkriti šta sistem stvarno radi. Ako je problem potpuno nov, on se retko svodi na jednostavno postavljanje pitanja radi prikupljanja zahteva, koja naručilac ima u svojoj glavi. U ranoj fazi projekta zahtevi su nedovoljno formulisani i nedovoljno dobro shvaćeni. Naručilac ne može uvek dovoljno precizno da saopšti čta mu treba, a analitičar ne može uvek dovoljno dobro da shvati tudje poslovne probleme. Opisi naručioca mogu da sadrže žargone koji nisu bliski analitičaru I obratno. Do zajedničkog dogovora dolazi se jedino raspravom sa svima koji su zainteresovani, objedinjavanje svih tih pogleda na sistem u koherentni skup zahteva I dokumenata koji sadrže zahteve. Ako ne možemo da se usaglasimo oko zahteva, projekat je osudjen na propast. Ko su zainteresovani subjekti:

Klienti su oni koji finansiraju projekat

Kupci su oni koji kupuje softver nakon što je razvijen

Korisnici, poznaju postojeći I koristiće budući sistem

Stručnjaci iz konkretne oblasti primene

Istraživači tržišta

Advokati ili revizori

Softverski inženjeri I drugi tehnolozi

Izvodjenje Analiza Specifikacija Validacija Specifikacija

softverskih

zahteva

Kako projektanti vide korisnike

Korisnici ne znaju šta hoće

ne mogu da artikulišu ono što hoće

nisu sposobni da obezbede korisnu formulaciju svojih potreba

imaju suviše potreba koje su politički motivisane

sve hoće odmah

ne mogu da prate rokove

ne umeju da dodele prioritete svojim potrebama

nisu radi da prave kompromise

odbijaju da preuzmu odgovornost za sistem

nisu posvećeni razvojnim projektima

Kako korisnici vide projektante

Projektanti ne razumeju operativne potrebe

ne mogu jasno da prevedu navedene potrebe u uspešan sistem

postavljaju nerealne standarde za defenisanje zahteva

stavljaju veliki naglasak na tehnička pitanja

uvek kasne

ne mogu brzo da odgovore na legitimno izmenjene potrebe

uvek premašuju budžet

sve vreme govore “ne”

pokušavaju da nam kažu kako da radimo naš posao

3 TIPOVI ZAHTEVA

Kada se razmišlja o zhtevima, razmišlja se o traženoj funkcionalnosti tj. koje usluge treba da se obezbede? Šta treba da bude reakcija na odredjeni stimulans? Kako se zahtevano ponašanje menja u funkciji vremena? Funkcionalni zahtev opisuje obavezno ponašanje u funkciji neophodnih aktivnosti, kao što su: reakcija na ulaze i stanja svakog entiteta pre pojave i nakon okončanja svake aktivnosti. Npr. kod isplate plate radnicima se opisuje koliko često se vrši isplata, koji ulaz je potreban da bi se obračunala zarada, šta utiče na iznos zarade, kada se radnik sklanja sa platnog spiska itd. Funkcionalni zahtev odredjuje granice koje omedjuju prostor rešenja našeg problema. Zahtev u pogledu kvaliteta ili nefunkcionalni zahtev opisuje neke

karakteristike kvaliteta koje softversko rešenje mora da poseduje, kao što je kratko vreme odziva, lako korišćenje, visoka pouzdanost ili niski troškovi održavanja.

Prilikom pokušaja iskazivanja svih vrsta zahteva relevantnih zainteresovanih subjekata, sigurno će biti suprotstavljenih ideja kakvi zahtevi treba da budu. Korisno je tražiti da naručilac odredi prioritete zahteva, kroz koje će on ukazati na najvažnije neophodne osobine. Okvirna šema prioriteta mogla bi da klasifikuje zahteve u tri kategorije:

suštinski zahtevi koji apsolutno mora da se zadovolje

poželjni zahtevi koji su veoma poželjni ali nisu nužni

opcioni zahtevi koji se mogu ispuniti ali se mogu I izostaviti

DVE VRSTA DOKUMENATA O ZAHTEVIMA

Zahteve koriste različiti ljudi za različite namene, analitičari zahteva za iskazivanje stepena razumljivosti ponašanja sistema, projektanti kao ograničenja vezana za utvrdjeno prihvatljivo rešenje, tim za testiranje da bi formulisao završno testiranje, timu za održavanje kao pomoć, da ispravke koje se rade ne utiču na originalnu namenu sistema. Nekada je to jedan dokument ali su najčešće dva: definicija zahteva namenjena poslovnom auditorijumu, kao što su kupci, naručioci I korisnici I specifikacija zahteva namenjena tehničkom auditorijumu kao što su projektanti, timovi za testiranje I rukovodioci projekta.

Definicija zahteva predstavlja kompletan spisak svega što naručilac želi da postigne. Dokument sadrži neophodne zahteve, opis entiteta koji pripadaju okruženju u kojem će predloženi sistem biti instaliran, kao I željena ograničenja u vezi sa entitetima. Svrha predloženog sistema jeste realizacija tih zahteva pa prema tome zahtevi su potpuno iskazani u smislu okruženja i opisuju kako će predloženi sistem uticati na okruženje.

Zahtev za primer obrtne kapije na ulazu na utakmicu, predstavljen je sa : (1) niko ne treba da udje na utakmucu bez plaćanja ulaznice I (2) sistem ne treba da sprečava svaki plaćeni ulaz.

Specifikacija zahteva iskazuje zahteve u vidu specifikacije ponašanja predloženog sistema.Specifikacija je takodje iskazana u smislu okruženja, s tom razlikom što se odnosi samo na one entitete, kojima može da se pristupi posredstvom njegovog interfejsa. U primeru kapije, ako obrtna rampa poseduje uredjaj za detektovanje novca , moguće je utvrditi da li je ulaznica plaćena inače koncept samog ulaska može da bude izvan okvira sistema. Zato se u specifikaciju inosi : kada posetilac primeni određeni nivo sile na otključanu obrtnu kapiju, rampa se automatski rotira za jedan polukrug I završava u poziciji zaključano. Znači specifikacija predstavlja prečišćenu definiciju originalnog zahteva. Specifikaciju zahteva piše analitičar a koriste je ostali članovi razvojnog time. Pretvaranjem zahteva u specifikaciju, analitičar mora da uspostavi jednoznačnu korenspondenciju izmedju svakog zahteva koji pripada dokumentu definicije zahteva I zahteva u specifikacionom postupku.

Zahtevi prema specifikaciji

zahtevi

specifikacija

zajednički interfejs sistem

Okruženje

4 KARAKTERISTIKE ZAHTEVA

Da bi krajnji proizvod bio uspešan, važno je da zahtevi budu visoko kvalitetni. Zbog provere kvaliteta, poželjne osobine zahteva su:

Da li su zahtevi ispravni? I analitičar I naručilac zahteva treba da pregledaju zahteve I uvere se da su shvatanja zahteva uskladjena.

Da li su zahtevi dosledni? Da li postoje suprotstavljeni zahtevi? Npr. ako jedan zahtev navodi da maksimalno deset korisnika može istovremeno da napada sistem a drugi zahtev traži da u jednom momentu to može da čini dvadeset korisnika, onda su zahtevi nedosledni.

Da li su zahtevi nedvosmisleni? Zahtevi su višeznačni ako više osoba koje analiziraju dokument sa zahtevima dodje do različitih ali ispravnih interpretacija. Npr. zahtev kaže da radnik treba da dobije nadoknadu za topli obrok, a nije definisao za koje sate rada to važi.

Da li su zahtevi kompletni? Skup zahteva je kompletan ako specifikuje zahtevano ponašanje I izlaz za sve moguće kombinacije ulaza,u svim mogućim stanjima I pod svim mogućim ograničenjima. Npr. za sistem za obračun zarada treba definisati šta se dešava kada radnik uzme neplaćeno odsustvo, dobije povišicu ili traži akontaciju.

Da li su zahtevi izvodljivi? Da li uopšte postoji rešenje za zahtev naručioca? Npr. zahtev kaže da naručilac želi da glavnom računaru, koji je udaljen nekoliko hiljada kilometara svi korisnici imaju isto vreme pristupa, a to je iz tehničkih razloga nemoguće.

Da li je svaki zahtev relevantan? Ponekad zahtevi nepotrebno ograničavaju razvojni tim ili uključuju funkcionalnosti koje nisu u direktnoj vezi sa potrebama korisnika. Npr. general traži da novi softverski sistem omogući vojnicima da šalju I primaju elektronsku poštu. Zainteresovanim subjektima treba da pomognemo da se usresrede na suštinske I poželjne zahteve.

Da li je zahteve moguće testirati? Zahtevi se mogu testirati ako je moguće formulisati testove koji jasno definišu da li konačni proizvod zadovoljava te zahteve. Npr. ako zahtev kaže da sistem treba da obezbedi odgovor “brzo” mi ne znamo šta je to, ali ako kaže da treba da odgovori u roku od 1 sec mi taj zahtev možemo da testiramo.

Da li zahtevi mogu da se prate? Da li su zahtevi organizovani I jedinstveno označeni da mogu da se uporedjuju definicija I specifikacija zahteva?

5 DIJAGRAMI ODNOSA IZMEDJU ENTITETA (NOTACIJE MODEL A)

U ranoj fazi definisanja zahteva korisno je izgraditi konceptualni model problema koji identifikuje relevantne objekte ili entitete, njihov izgled ( definisanjem njihovih atributa) i medjusobne odnose. Takav model imenuje osnovne elemente problema. Oni se zatim ponovo koriste u drugim opisima zahteva, koji definišu kako će se objekti, njihovi atributi i medjusobni odnosi menjati tokom funkcionisanja predloženog sistema. Prema tome, konceptualni model pomaže da se različiti pogledi na zahteve i različiti opisi zahteva opišu.

Dijagram odnosa izmedju entiteta ili ER dijagram ( Entity-Relationship diagram) je popularna grafička notaciona platforma za predstavljanje konceptualnih modela. ER dijagrami predstavljaju osnovu većine objektno orijentisanih notacija za predstavljanje zahteva i dizajna, gde se ona koristi za modelovanje odnosa izmedju objekata iz domena problema ili za modelovanje strukture softverskog proizvoda. Isto tako ER dijagram moće da se koristi za prikazivanje šeme baze podataka.

ER dijagrami se zasnivaju na tri osnovna elementa: entitet, atribut i odnos (relacija), koje se kombinuju radi specifikovanja elemenata problema i njihovih veza. Entitet , predstavljen pravougaonikom, je skup, ili ponekad kažemo klasa, objekata iz realnog sveta koji imaju zajedničke osobine i ponašanja. Odnos ( ili ralacija) je predstavljen linijom koja spaja dva entiteta, sa rombom na sredini koji defineše tip odnosa. Atribut je obeležje entiteta, koji opisuje podatke ili svojstva pridružena entitetu.

vrednost cena ulaznice

m m 1

1

n

1

zaključana

broj ulazaka

Dijagram odnosa izmedju entiteta za problem obrtne rampe

posetilac

novčić otvor za novčić

rampa

poseduje ubačen

u

ulazii

ER dijagrami su popularni jer formulišu sveobuhvatan pregled problema kojim se bavimo, a I zbog toga što je taj pogled relativno stabilan kada dolazi do promena zahteva. Izmena zahteva je mnogo izvesnije posledica izmene ponašanja jednog ili više entiteta nego promena skupa entiteta. Zbog toga ER dijagram se koristi za modelovanje problema u ranoj fazi definisanja zahteva.

Nivo detalja modelovanja nekog problema nije uvek očigledan čak I kada postoje samo tri notacione konstrukcije.

KONAČNI AUTOMATI

Konačni automat je grafički opis svih komunikacija izmedju sistema I njegovog okruženja. Svaki čvor, koji se naziva stanje predstavlja postojan skup uslova koji se održavaju u intervalu izmedju pojave dogadjaja. Svaka grana, koja se naziva prelaz stanja, predstavlja promenu koju je dogadjaj proizveo u ponašanju ili u uslovima. Svaki prelaz iz jednog stanja u drugo obeležen je pobudnim dogadjajem, a ponekad I izlaznim dogadjasjem koji se generiše kada se dogodi prelaz.

Konačni automati su korisni za definisanje dinamičkog ponašanja, I za opis načina promene kao odgovor na prethodne dogadjaje. Posebno su pogodni za modelovanje načina na koji se odgovori sistema na isti ulaz menjaju tokom izvršavanja. Prelazi u drugo stanje, koji proističu iz nekog datog stanja, definisani su skupom dogadjaja koji mogu pobuditi te prelaze I definisani su odgovorom na taj skup dogadjaja.

Model konačnog automata za obrtnu rampu

Žeton / zvuk

novčić

rotirana guranje

zakljušana otključana

rotira

DEFINISANJE ZAHTEVA ZA INFORMACIONIM SISTEMOM

Ključne aktivnosti, koje se mogu izdvojiti u definisanju zahteva za informacionim sistemom, su prikupljanje informacija, prikupljanje podataka i ustanovljavanje činjenica.

PRIKUPLJANJE INFORMACIJA

Jedna od aktivnosti kod definisanja zahteva za IS su intervjui sa ključnim korisnicima i radni sastanci. Ako naručilac zapošljava informatičare, svakako ih treba uključiti u analizu. Sučeljavanje korisnika i informatičara ubrzava rešavanje protivrečnih iskaza. Kao zamena za intervjue koriste se upitnici i ankete, koji su pogodni i za prikupljanje informacija o resursima. Analiza dokumentacije podrazumeva prikupljanje cjelokupne dokumentacije značajne za poslovanje, radi boljeg utvrdivanja pravila, poslovne politike, ciljeva poslovanja i strukture informacija.

Nužna je ocena postojećih aplikacija i/ili racunarom podržanih podataka, radi analize podataka, ali i zbog njihove konverzije u novi sistem. Posmatranje, odnosno neposredni uvid u poslovne procese posmatranjem radnih sredina (nacin izrade I razmjene dokumenata, procesi osnovne delatnosti), je značajan vid definisanja zahteva za IS. Postupak analize mora biti prilagodjen korisniku

POSTUPAK INTERVJUISANJA

Intervju mora biti neusiljen i elastičan razgovor sa ispitanikom u obliku niza pitanja i odgovora. Ispitanik se pojavljuje u ulozi pasivnog sagovornika (!?). Sagovornici su rukovodioci, krajnji korisnici i ostali učesnici iz poslovnog sistema. Standardno uključuje dva sagovornika, ali može i više, i to korisnika i ispitivača. Individualni intervju je kada učestvuje jedan korisnik, ili učesnici koji rade isti posao, dok je intervjuisanje grupe kada se razgovara sa više korisnika iz različitih područja.

Informacije se prikupljaju nizom pojedinačnih razgovora. Prve razgovore treba voditi prema unapred dogovorenom planu i rasporedu, što treba da obezbedi koordinator intervjua. Postupak intervjua je spor i neefikasan, jer se organizacija razgovora mora obaviti za svaki pojedini razgovor. Nakon završetka analize i sinteze dobijenih informacija, neke razgovore (ponekad i čitavu seriju) treba ponoviti da bi se upotpunile dobijene informacije ili uskladili protivrečni iskazi. Ukupan broj razgovora ne može se unapred tačno odrediti i treba ga prilagoditi stvarnoj situaciji.

TEHNIKA INTERVJUISANJA

Priprema za razgovor treba da sadrži utvrdivanje informacija koje treba saznati, proučavanje postojeće dokumentacije i prethodnih nalaza, odredivanje dokumentacije koju treba prikupiti i priprema pitanja koja će biti postavljena tokom razgovora. Priprema pitanja podrazumeva izradu jezgra tema, to jest standardnih pitanja, i izradu sveobuhvatnog potsetnika i izdvajanje prikladnih pitanja.

Mogući plan i obavljanje razgovora može da se odvija na slijedeći nacin:

1. Trajanje prvog razgovora je 2 sata (okvirno 1,5 do 2,5 sata);

2. Početak razgovora, koji sadrži predstavljanje učesnika i upoznavanje sa

svrhom razgovora (prikupljanje informacija o … );

3. Vodenje razgovora, odnosno postavljanje pitanja i zapisivanje odgovora,

prikupljanje dokumentacije, ... ;

4. Završetak razgovora je približno 5 do10 minuta pre isteka planiranog vremena. Prekida se redosled postavljanja pitanja, proverava se da li postoji nešto što je sagovornik hteo reći a nije bilo pitano, proverava se da li treba proširiti krug sagovornika, dogovara se nastavak razgovora (dopunski razgovor) kada voditelj razgovora nije postavio sva planirana pitanja ili smatra da je razgovor nametnuo nova pitanja;

Preispitivanje i pojašnjenje sadržaja se sastoji od provera zapisanih navoda radi upotpunjavanja beleški: telefonom, elektronskom poštom ili novim sastankom.

Dokumentovanje razgovora sačinjavaju:

• Samostalno pisanje zapisnika (“Ko ne razume, ne može zapisivati.”). Kada u razgovoru sudeluje više analitičara, odreduje se voditelj razgovora koji je ujedno i zapisničar, a ostali ulažu primedbe;

• Zapisnik treba da sadrži: naziv projekta, vreme i mesto održavanja razgovora, spisak učesnika, sadržaj razgovora (tekst zapisnika), popis prikupljene dokumentacije i ime zapisnicara;

• Zapisnik mora sadržavati ono što je rečeno i slediti tok razgovora;

• Zapisnik ne sme nametati zaključke, jer su oni rezultat analize.

Autorizacija (overa) zapisnika se vrši tako da se zapisnik dostavlja na uvid sagovorniku, koji potvrduje verodostojnost zapisnika. Po potrebi sagovornik može nadopuniti delove za koje smatra da nisu evidentirani ili pojasniti delove za koje misli da su pogrešno protumačeni.

PREPORUKE ZA VODJENJE INTERVJUA

Tokom provodenja intervjua, treba pitati o svemu što se smatra važnim. Ništa nije samo po sebi razumljivo i svima jasno. Ne pretpostavljati da se unapred zna o čemu se radi. Repertoar i vrste pitanja može biti slijedeci:

1. Pitanja zatvorenog tipa: Koliko ... obradujete (u nekom razdoblju)?, Na koji nacin obradujete ... ?;

2. Pitanja otvorenog tipa: Što mislite o ... ?, Koji su najveci problemi ... ?;

3. “Probna” pitanja: Zašto?, Možete li navesti primer za takvu situaciju?, Molim detaljnije objašnjenje za ... .

Analizom odgovora se razdvajaju činjenice od mišljenja, utvrduje se da li pojedine činjenice odgovaraju drugima, analiziraju činjenice koje se ne poklapaju i vrši provera odgovora razlicitih sagovornika na isto pitanje.

Preporučuje se sledeće ponašanje: iskrenost i nepristranost (cilj je naći za korisnika najprikladnije rešenje, a ne naturati odredjeno programsko rešenje ili računarsku platformu), pažnja i jezgrovitost tj. “brzo misli, jasno govori”, izbegavanje sugestivnih pitanja, ne nametanje zaključaka i ležernost (plus praćenje reakcija sagovornika). Grupno intervjuisranje je potrebno izbegavati i po potrebi nadoknaditi radnim sastancima. Ovu vrstu intervjuisanja izuzetno provesti kada se želi utvrditi zajednički interes ili protivrečnost.

UPITNICI I ANKETE

Upitnik je, u suštini, pismeni intervju. Sadrži pitanja koja se postavljaju tokom razgovora (okvirno 20 pitanja). Može se dostaviti korisniku pre ili nakon intervjua. Nedostaci upitnika su sledeći: ispitanik može prilagoditi (kontrolisati) svoje odgovore, teško je proceniti iskrenost (spontanost) odgovora, a može i obeshrabriti ispitanika.

Anketa može da obuhvatiti više ispitanika. Pitanja su zatvorenog tipa, a odgovori I obrada odgovora mogu se standardizovati. Pogodna je za popis resursa.

Na osnovu navedenog, može se zakljuciti da je intervjuisanje najelastičnije! Pomoću intervjua se može više naučiti o stavovima, osećajima i motivaciji osoblja. Tokom intervjua analitičar i ispitanik se nalaze jedan nasuprot drugom, pa analitičar može posmatrati način na koji ispitanik odgovara i po potrebi proširiti ili usmeriti pitanja.

PROUČAVANJE DOKUMENATA

Prikupljaju se svi dokumenti do kojih se može doći. U prvom redu treba prikupiti dokumente koji su nastali kao rezultat analize procesa, tipične dokumente (pravilnici, zakoni, obrasci, izveštaji) i dokumente nastale analizom podataka. Poželjno je da dokumenti budu reprezentativni, tj. popunjeni na tipičan način (tako se može ustanoviti koje informacije se unose i na koji način). Reprezentativni dokumenti najčešće ne ukazuju na izuzetke, to jest podatke koji se retko javljaju, ali ipak trebaju. Stalno zapisivanje nekih podataka ne mora značiti da su ti podaci stvarno potrebni. Treba prikupiti više uzoraka iste vrste dokumenta!

Vrednost informacija o analiziranoj organizaciji prikupljena (samo) preko dokumenata je niska. Praksa može odudarati od pravilnika i administrativnih obrazaca. Treba shvatiti zašto i kada dokumenti nastaju, kako se popunjavaju, koliko su potrebni, te šta treba promeniti da bi se popravili (sadržaj, lakoća popunjavanja i čitanja). Nužno je modele (podataka), razmatrane analizom, proveriti kod korisnika.

EVIDENCIJA I ANALIZA POSTOJE ĆIH APLIKACIJA

Budući da su nedostaci opreme, podrške i podataka najčešci razlozi za izgradnju novog IS, potrebno ih je evidentirati i analizirati. Vrši se procena aplikacija i (baza) podataka u primeni, i to: korišteni programski jezici i alati, uključujući programe za kancelarijsko poslovanje (npr. Excel), podržane funkcije i način posluživanja programa, medusobna povezanost različitih aplikacija i podataka, postojeće platforme (računari, operativni sistem, mreža), kao i sastav i stepen informatičke obučenosti korisnika.

Analiziraju se nedostaci sistemske opreme i programske podrške. U prvom redu se analizira nepovezanost aplikacija (tzv. informatička ostrva), loša programska rešenja (funkcionalnost), nepouzdanost, integritet, zaštita i sigurnost podataka. Takodje se analizira nepostojanje programske dokumentacije, tehnološka zastarelost (programski jezici i alati, nemogućnost rada u višekorisničkom okruženju, grafički interfejs).

Nedostaci modela podataka mogu biti različiti. Najčešci nedostaci su različitost modela podataka postojećih aplikacija i nedostaci unutar pojedinih modela. Različitost modela podataka postojećih aplikacija se očituje u tome da entiteti iz stvarnog sveta nisu jednako zastupljeni u postojećim modelima, isti entitet iz stvarnog sveta pojavljuje se pod različitim nazivima, isti entitet iz stvarnog sveta opisan je različitim atributima, dva ili više entiteta iz stvarnog sveta su prikazani različitim brojem entiteta u modelu podataka. Nedostaci unutar pojedinih modela su, najčešce, nedefinisanost identifikatora (primarnih ključeva), nedefinisanost veza medu podacima, najčešce kao posledica nepostojanja primarnih ključeva, nedefinisanost veza i pored postojanja primarnih i drugih (stranih) ključeva. Navedene pojave su posledica razvoja tokom upotrebe i nedoslednosti tog razvoja, naglašenog ponavljanja uvedenog prilikom izrade zahtevnih ili složenih programskih rješenja, kao i ukupne nenormalizovanosti modela.

POSMATRANJE POSLOVNOG SISTEMA

Definisanje zahteva za IS se može dopuniti uvidom u poslovne procese, odnosno posmatranjem radnih sredina. Posmatra se lokacija i kretanje ljudi, tok izvršavanja poslova, fizički ulazi i izlazi sistema, zaprimanje, izrada i razmena dokumenata, procesi osnovne delatnosti, npr. proizvodnje. Prednost ovakvog pristupa je u

tome što je analitičar u stanju da realno sagleda poslovni proces. Ovaj pristup je efikasan, ako se dobro provede, i obezbeduje pouzdanost prikupljenih informacija. Nedostaci posmatranja poslovnog sistema su neefikasnost, ako se dobro ne provede, znatan utrošak vremena, ometanje i nelagodnost posmatranih osoba, prikrivanje uobicajenog kršenja radnih procedura od strane osoba u posmatranom procesu.

Podaci dobijeni iz malog broja kratkotrajnih posmatranja mogu biti nepouzdani I netačni. Posmatranje na licu mesta je najteža metoda za utvrdivanje činjenica.

RADNI SASTANCI

Radni sastanci se organizuju da analitičari i korisnici zajednički provode analizu i oblikovanje. Cilj sastanka je zajedničko pronalaženje najboljeg rešenja. Za to je potreban poseban prostor i izolacija, dnevni red i zapisnici .

Genijalnost grupe se koristi za prikupljanje ideja i definisanje informacionih potreba, pri čemu se korisnici potiču na aktivno i kreativno sudelovanje. Izvodi se tako da se od svakog ispitanika iz grupe traži da definiše svoj pogled na idealno rješenje. Svaki učesnik iznosi sve što mu pada na pamet u vezi sa problemom koji se rešava. Od predloženih rešenja odabira se najbolje prema realnoj izvodljivosti. Postupak je koristan tamo gdje postoje korisnici koji dobro poznaju sistem, ali teško prihvataju nove ideje.

Prednosti radnih sastanaka su njihova pogodnost za projekte kojima se rešavaju problemi važni za celi poslovni sistem ili veći deo poslovanja. Njihovim organizovanjem se izbegavaju specifični (egzotični) i nejasni zahtevi, preciznije se ustanovljava doseg projekta i bolje uočava protivrečnost zahteva. Nedostaci radnih sastanaka su pasivnost učesnika, “usitnjavanje” razgovora i cesto udaljavanje od tema. Sastanci treba da traju više dana (5 do 10) u nekoliko sedmica. Ovom zahtevu u praksi je vrlo teško udovoljiti zbog obaveza učesnika. Otpor sastanku je srazmeran nivou položaja konkretnog učesnika. Otpor je naročito naglašen kada poslovni sistem zapošljava informatičare, jer se podrazumeva da je informatizacija isključivo njihov posao.

RAZVOJ PROTOTIPA

Razvoj prototipa se koristi kada korisnik ne može tačno da definiše svoje informatičke potrebe pre nego što se izgradi informacioni sistem. Razlog tome može biti nedostatak postojećeg modela na kojem bi korisnik zasnivao svoje potrebe ili pak teška vizuelizacija budućeg sistema. Da bi se olakšala vizuelizacija budućeg sistema izgraduje se sistem koji zadovoljava neke osnovne, inicijalne potrebe. U radu sa takvim sistemom korisnik otkriva svoje informatičke potrebe, te se sistem modifikuje kako bi se zadovoljile te potrebe. Postupak korištenje sistema i modifikovanje istog iterativno se ponavlja, a informatičke potrebe korisnika otkrivaju korištenjem sistema.

Izrada prototipa pogodna je u onim okruženjima gdje je teško definisati konkretni model sistema, te u okruženjima gdje se informatičke potrebe korisnika menjaju ili razvijaju

NAJČEŠĆI PROBLEMI PRI PRIKUPLJANJU INFORMACIJA

Ponašanja korisnika često može da uzrokuje niz problema pri definisanju zahtjeva za IS. Informatickim žargonom su opisana ponašanja koja se mogu očekivati od korisnika.

1. Taktika “kuhinjskog sudopera”: korisnik navodi (preko)brojne potrebe, gomilu nepotrebnih izveštaja, ekranskih formi, sortiranja, izračunavanja i sl. Ovakav pristup obično je uzrokovan pomanjkanjem iskustva korisnika, koji ne zna šta bi mu stvarno moglo zatrebati, ili nije u stanju izdvojiti ono šta je bitno;

2. Taktika “dimne zavese”: korisnik traži više mogućnosti, a zapravo mu je potrebna samo jedna ili dvije. Dodatni zahtevi služe za postizanje bolje nagodbe sa analitičarom. Ova taktika obicno oslikava korisnika sa dobrim poznavanjem onoga šta želi, a zahteve treba reducirati na one realne I izvodljive;

3. Taktika "Treba mi isto, ali u boljem obliku": korisniku koji koristi ovu taktiku nedostaje volja ili znanje, a ponekad oboje. Šanse za uspešno definisanje problema su male, jer samo korisnik može izraziti svoje potrebe i probleme.

Korisnik je sklon da prećuti izuzetke, koji su bitni (nužni!) za uspešnu realizaciju, a obično izuzeci zahtevaju i najviše napora tokom ugradnje: "To je naša jedina procedura … (osim kada … )". Ne izjednačavati “tako se uvijek radi” sa “tako treba raditi”!