Projektovanje IS DSM Projektovanje softvera IDEF 0 i

Projektovanje IS DSM Projektovanje softvera IDEF 0 i IDEF 1 X metodologije

Struktuirano projektovanje softvera • Struktuirano projektovanje softvera postignuto je onda kada svaki dio programa odgovara jednom, malom, dobro definisanom dijelu problema. • Struktuirano projektovanje koristi postavku problema za definisanje njegovog rješavanja. • Složenost sistema se nadvladava razbijanjem sistema u crne kutije (koja daje željeni rezultat na osnovu zadatih ulaza) i organizovanje u hijerarhijsku strukturu koja je pogodnija za implementaciju na računaru. • Koriste se grafička sredstva radi pogodnijeg predstavljanja i razumijevanja sistema. • Strukturirano projektovanje nudi niz strategija razvoja projektnih zadataka polazeći od postavki problema. • Strukturirano projektovanje nudi niz kriterijuma za evaluiranje kvaliteta dobijenih rješenja.

ZAHTJEVI Strukturirana sistem analiza (SSA) SPECIFIKACIJE U OBLIKU DTP I RP Strukturirano projektovanje modula programa (SP) SPECIFIKACIJE MODULA U OBLIKU DSM MODUL modulu (funkcija) se može definisati u gotovo svim višim programskim jezicima. Moduli imaju ulaz, izlaz, funkciju, internu logiku i interne podatke.

Grafičko predstavljanje modula i veza naziv modula A pozivajući modul B pozvani modul A p 1 pozivajući modul k 1 B parametar kontrolni indikator prenos podatka u i od modula p 2 pozvani modul

Grafičko predstavljanje modula i veza v 1 A a v 1 Da bi se izbjeglo presjecanje linija i da bi se više dijagrama međusobno povezalo koriste se konektori. B A B C D E Modul može pozvati više drugih modula. Redosljed pozivanja je od lijeva i iz dubine. Modul A prvo poziva modul B, zatim C zatim na osnovu ispunjenja nekog uslova D i na kraju više puta (u petlji) modul E.

Kriterijumi projektovanja Podjelu složenog sistema na module treba izvršiti tako da: Moduli budu što je više moguće nezavisni (kriterijum povezanosti modula); Modul izvršava cjelovitu problemski definisanu funkciju (kriterijum kohezije modula). Povezanost modula Smanjuje vjerovatnoću da će pojava greške u jednom produkovati pojavu greške u drugom modulu; Izmjena jednog modula ne uzrokuje izmjene drugih modula; Moduli su prosti i shvatljivi.

Povezanost modula Dva modula su normalno povezana ako modul A poziva modul B, poslije B povratak u A i veza između ovih modula se ostvaruju preko parametara. Tipovi povezanosti modula su: povezanost podacima (data coupling), povezanost strukturom podatka (stamp coupling), povezanost upravljanjem (control coupling), povezanost zajedničkom oblašću podataka (common coupling), povezanost po sadržaju (content coupling). Povezanost oblašću podataka može da stvori da jedan modul uzrokuje greške i u drugim modulima. Programi sa dosta zajedničkih oblasti umiju da budu teški za razumijevanje. Povezanost po sadržaju se dešava kada jedan modul direktno pristupa sadržaju drugog modula (upadanje u tok izvršavanja drugog modula, mijenja podatke unutar njega ili mu mijenja instrukcije).

Karakteristike tipova povezanosti modula Kohezija Funkcionalna, sekvencijalna, komunikaciona, proceduralna, vremenska, logička, koincidentalna (slučajna). • Funkcionalno kohezivni modul sadrži elemente koji izvršavaju jednu problemski definisanu funkciju.

Kohezija • Modul sa sekvencijalnom kohezijom obavlja više funkcija čiji se redosljed izvršavanje određuje na sljedeći način: izlaz iz prve funkcije je ulaz za drugu itd. • Komunikaciono kohezovan modul obavlja više funkcija koje koriste isti ulazni podatak. • Proceduralno kohezivan modul obuhvata više različitih i moguće problemski nepovezanih funkcija, redosljed izvršavanja je određen na osnovu prenošenja upravljanja sa jedne na drugu funkciju. • Vremenski kohezivan modul obavlja više funkcija čiji redosljed izvršavanja zavisi od vremena, prvo se obavlja funkcija koja se vremenski dešava prije ostalih funkcija. • Logički kohezivni modul je modul čiji su elementi raspoređeni po aktivnostima iste logičke cjeline. • Koincidentalno kohezivni modul je modul kod koga su elementi raspoređeni po aktivnostima međusobno različitim po smislu.

Specifične ocjene tipova kohezije Dodatni kriterijumi za projektovanje programskih sistema Faktorisanje, podjela odluke, poruke o greškama, editovanje, interna memorija, struktura podataka, FAN-OUT, FAN-IN. Faktorisanje je izdvajanje funkcija u novi modul iz sljedećih razloga: redukcije veličine modula, dijeljenja funkcionalno kohezivnih modula, minimizacija ponavljanja modula, formiranje korisnih modula, uprošćavanja implementacije.

Faktorisanje A B C je uključen u modul A kao njegov kod C D Podela odluke Odluka se sastoji iz dva različita djela: donošenje odluke i izvršenje odluke. Editovanje Osnovna pravila za editovanje su: editovati prvo poznato prije nepoznatog, editovati sintaksu prije semantike, editovati prvo komponente pa cjelinu, editovati interno prije eksternog.

Poruke o greškama Gdje treba locirati tekst poruke o grešci (dvije mogućnosti): svaku poruka o grešci locirati u modulu koji otkriva grešku, sve poruke o greškama locirati na jednom mjestu pa se poruci dodjeljuje šifra na osnovu koje se izdaje zahtjevana poruka. Prednosti druge metode su: manje dupliranje poruka, lakše usklađivanje poruka, lakše mijenjanje poruka. Problemi su što se sa zahtjevom za izdavanje poruke o grešci mora dostaviti i šifra poruke, manja čitljivost programa. Interna memorija Ovo je interni podatak koji se neizmijenjen čuva u modulu do sljedećeg poziva modula. Moduli sa internom memorijom mogu biti nepredvidljivi jer mogu različito raditi i davati različite izlaze. Greške u ovim modulima se veoma teško otkrivaju. Ako se radi sa internom memorijom treba poštovati određena pravila.

FAN IN i FAN OUT FAN-OUT je broj neposredno podređenih modula. Treba ga ograničiti (preporučuje se 7). Suviše veliki broj podređenih modula smanjuje se faktorisanjem. FAN-IN je broj nadređenih modula. Nadređeni moduli ne bi smjeli biti na različitim nivoima. Preporuke za pojedine kriterijume

DSM Zaključak • DSM još uvijek nudi najbolju metodologiju za ocjenu kvaliteta softverskog rješenja – nepristrasnu i preciznu. • Da li je DSM danas najbolji način da se prikažu veze modula? • Ne! • DSM je prevashodno u tom dijelu razvijen za strukturne programske jezike i ne podržava u najvećoj mogućoj mjeri objektno orijentisano programiranje. • Njega mogu nadomjestiti: dijagram klasa i dijagram komponenti u UML-u. • Prvi ćemo izučavati detaljno dok ćemo drugi pomenuti rudimentarno.

Osnovni modeli procesa razvoja softvera • Metod vodopada. ANALIZA DIZAJN IMPLEMENTACIJA TESTIRANJE RAZVOJ Očigledno radi se o sličnoj stvari kao što je razvoj na osnovu linearnog životnog ciklusa. Promjenjuje se samo kod jednostavnijih sistema i u slučaju da je problem duboko ispod nivoa iskustva programera. Spiralni model. Ovaj model se sastoji od više kratkih ciklusa razvoja (Analiza, Dizajn, Implementacija, Testiranje) i gdje na kraju svake faze nastaje izvršna verzija softvera. Da bi se ovako radilo tim gotovo istovremeno radi različite faze a ne provodi mnogo vremena odjednom na jednoj fazi. Relativno brzo se dobijaju informacije od korisnika i sagledavaju potencijalni problemi. Kod spiralnog razvoja svi se elementi koji su riskantni implementiraju ranije kako bi se taj dio softvera najduže testirao. Ova tehnika je pogodna i da bi se obim softverskog paketa sagledao relativno rano što je važno u cilju procjene potrebnih ljudskih resursa za realizaciju ovog softvera.

Osnovni modeli procesa razvoja softvera Pored toga lakše je implementirati nove tehnologije, postojanje verzije softvera relativno rano je dobro za moral zaposlenih. Takođe, procjena koliki dio softvera je stvarno završen se lakše obavlja. Međutim, postoje i određeni problemi sa ovim tipom razvoja softvera. Ovakav razvoj je asociran sa složenim programskim alatima koji štede mnogo vremena u programiranju (RAD – Rapid Application Developement) ali koji su istovremeno složeni za održavanje jer podliježu nestandardnim proširenjima programskih jezika i često su asocirani sa hakerskim alatima. Pored toga ovaj proces je znatno složeniji za kontrolu nego što je to metod vodopada. Iterativni, inkrementalni obrazac koji je standardizovan oko 2000. te godine. Ova procedura posmatra 4 faze: Sagledavanje, Elaboraciju, Konstrukciju i Tranziciju. Sagledavanje je namjenjeno da se sagleda ono što projekat treba da obuhvati kao i da se definiše generalna vizija projekta. Složeni projekti podrazumijevaju da je ova faza veoma razrađena dok jednostavni projekti mogu biti zasnovani na nekoliko sati neobaveznog razgovora. Naravno od interesa su jedino projekti čija složenost (kako programersko – realizatorska tako i složenost upravljanja) je dovoljna da zahtjeva implementaciju ove procedure. Osnovni rezultati ove faze su (ne moraju biti svi i obezbijeđeni): Dokument koji opisuje viziju ISa i/ili softvera; Objašnjenje inicijalnih korisničkih zahtjeva; Prva verzija rječnika projekta; Bussiness Case (ovaj dokument treba između ostalog da definiše kriterijume za procjenu uspjeha, finansijsku procjenu projekta i procjenu na koji način će se ulaganja u razvoj softvera isplatiti); Inicijalnu procjenu rizika; Plan projekta. Odnosno sredstvo za ovu fazu danas su slučajevi korišćenja. Druga faza se naziva Elaboracija. Namjena elaboracije je da analizira problem, razradi plan projekta i da eliminiše rizična mjesta u projektu.

Iterativni inkrementalni obrazac Na kraju ove faze projektni tim mora da razumije čitav projekat globalno ali ne mora da razumije sve detalje projekta. U fazi elaboracije se ponovo koriste slučajevi korišćenja a pored njih kreira se i klasni dijagram. U fazi konstrukcije se kreira sam softverski dio. U ovoj fazi se zapravo koriste iteracije. Svaka pojedinačna iteracija je mali metod vodopada i sastoji se od analize, dizajna, kodiranja i testiranja. Pojedine iteracije se preklapaju odnosno analiza za narednu iteraciju započinje još u fazi dizajna prethodne iteracije. Priprema koja je obavljena u fazama Sagledavanja i Elaboracije omogućava da Konstrukcija bude odrađivana iterativno tako što se prvo implementira nesporni dio koji slijedi na osnovu prve dvije faze a zatim se implementiraju djelovi koji slijede iz novih analiza napravljenih u ovoj fazi. Napominjemo, da cilj iteracija nije da naprave "čudo" već da riješe nekoliko uočenih problema. Time se izbjegavaju problemi koji su asocirani sa metodom vodopada. Posljednja faza je Tranzicija u kojoj softver prelazi iz ruke kreatora u ruke korisnika. Tipične aktivnosti u ovoj fazi su: izdavanje beta verzije za testiranje u okviru korisničke populacije; uvođenje softvera u sistem i rad u paraleli sa postojećim sistemom kojega želimo zamijeniti; unos podataka (rijetko je ručan osim ako je softver prva automatizacija koja se vrši u datoj organizaciji već je po pravilu u pitanju konvertovanje postojećih baza podataka u nove formate i importovanje podataka iz postojećih programa); trening korisnika; marketing softvera, distribucija i prodaja softvera, podrška korisnicima. Tranzicija nije testiranje već podrazumijeva da na početku tranzicije posjedujemo potpuno operativnu verziju softvera koja u nekim situacijama može da bude beta-verzija podložna testiranju i značajnim izmjenama.

Vrijeme i dizajn Ono što je ključni elemenat u opisanoj proceduri je zapravo trajanje iteracije. Danas se smatra da jedna tipična iteracija traje između dvije nedjelje i dva mjeseca i da sve preko dva mjeseca je potpuno neprihvatljivo jer podrazumijeva da je veliki dio softvera u novoj verziji po prvi put povezan a to može da dovede do velikih poteškoća u radu i "jurenja grešaka" na mnoštvo mijesta u kodu. Složeniji softveri ne podrazumijevaju duže iteracije već samo veći broj iteracija. Prve iteracije mogu da budu nešto duže nego ostale i da ostave prostora programerima da tu uvedu neke nove tehnologije i tehnike i da imaju više vremena za testiranje istih. Na dužinu iteracija mogu negativno da utiču početnici u timu, podjela tima za razvoj na podtimove kao i razdvojenost razvojnih timova. Takođe, projekti sa velikom dokumentacijom teže da imaju duže iteracije. Jedna radikalna strategije za rukovanje dužinom trajanja pojedine iteracije je – time boxing (vremensko limitiranje). Kod time boxinga postavlja se maksimalno vrijeme trajanja iteracije i ako planirane aktivnosti u iteraciji nijesu obavljene do tog trenutka iteracija se završava. Na kraju svake iteracije se pravi pregled što je urađeno i što treba da se uradi u narednoj iteraciji. Ciljeve iteracije postavlja šef razvojnog tima (ili neka druga osoba ili osobe sa iskustvom). Takođe, treba specificirati trajanje iteracije. Loše organizovan time boxing prouzrokuje da se jedan dio posla iz jedne iteracije presipa u naredne iteracije i da može da poveća u značajnoj mjeri broj iteracija. Implementacija time boxinga može biti neprijatna za učesnike jer forsira velike aktivnosti prije kraja jednog box-a (prekovremeni rad) i ponekad vojničku disciplinu.

Time-Boxing Međutim, mnogi razvojni timovi su je usvojili iz sljedećih razloga: forsira se planiranje i ponovno planiranje (svako probijanje roka traži novo planiranje; svaki otkriveni novi element u softveru isto a eventualno brže završavanje nekih faza opet zahtjeva promjene u dinamičkom planu) i na ovaj način se projekat čini veoma živim i aktivnim; male su šanse da projekat propadne jer revizija na kraju svakog time boxa će spriječiti da softver ode predaleko u pogrešnom pravcu; time boxing i revizije spriječavaju programere da pišu hakerske programe koji "rade" ali niko u timu nema pojma kako i zašto. Preporuka za svaku od faza iterativnog, inkrementalnog dizajna je sljedeća: Sagledavanje traje oko 10% vremena; Elaboracija (inicijalno planiranje) traje 30% vremena; konstrukcija traje oko 50% vremena i Tranzicija oko 10%. Projektovanje softvera neki zaključci • Projektovanje sistema se vrši Top-Down pristupom (od vrha ka dnu) sa stanovišta koje bi trebalo da bude vezano za menadžment preduzeća i tu bi trebalo da naglasak bude na ciljevima i resursima. Tu se definiše i model podataka. Uvođenje sistema, baza podataka, i automatizacija funkcija sistema se vrši Bottom-Up. • Ne treba vjerovati da je projekat moguće naručiti i izvesti po principu ključ u ruke te da projekat bilo kojeg većeg sistema moguć na taj način. Znači sistem sa 3 -4 računara i 2 -3 aplikacije nikada ne može biti prosto ključ u ruke.

Projektovanje softvera neki zaključci • Projektovanje se ne mora obaviti za manje sisteme ali za sve sisteme veće od desetak računara, više od jedne baze podataka, više od 4 -5 korisnika i više od 4 -5 aplikacija projektovanje se mora obaviti nekom jedinstvenom metodologijom primjenom CASE alata. Metodologije se nazivaju IDEF 0 i IDEF 1 X a alati su npr. BPwin i ERwin ili alati zasnovani na UML-u. Projektovanje sistema - metodologije • Modeliranje se provodi iz više razloga od kojih je jedan jasnoća. Ovo je posredan razlog važniji su dokumentovanje, jednostavno nadgrađivanje, mogućnost direktnog i reversnog inženjeringa. Projektovanje sistema nije jednostavan skup obrazaca već u mnogome zahtjevaju veliko iskustvo projektnog tima. IDEF 0 i IDEF 1 X su tehnike preporučene od strane IEEE-a 1993 -će i do danas su se održale sa dopunama u smislu objektno orjentisane tehnologije.

IDEF 0 i IDEF 1 X • IDEF 0 standard je osnova BPwin-a i omogućuje funkcionalno modelovanje kroz: – Izvršavanje funkcionalne dekompozicije i dizajna na svim nivoima, za sistem sastavljen od ljudi, mašina, materijala, računara i informacija; – Stvaranje dokumentacije, paralelno inžinjeringu poslovnih procesa; – Bolju komunikaciju između projektnog tima, korisnika i menadžera; – Diskusiju u projektnom timu da bi se postiglo međusobno razumijevanje; – Upravljanje velikim i složenim projektima; – Obezbjeđenje elemenata potrebnih za informaciono modeliranje. • IDEF 1 X metodologija za informaciono modeliranje je pojednostavljeno viđenje realnog sistema preko skupa objekata (entiteta), veza između njih i atributa entiteta. Ova metodologija je dobro podržana sa ERWin alatom. • Polazeći od ovih metodologija razvoj informacionog sistema se može pojednostaviti na: – Funkcionalno modeliranje (na osnovu zahtjeva korisnika i sagledavanja stanja definišu se funkcije koje sistem treba da sadrži, preduslovi za funkcije itd); – Informaciono modeliranje (entiteti, veze, atributi, poslovna pravila); – Aplikativno modeliranje (baze podataka, SUBP, aplikacije); – Implementacija (uvođenje, testiranje, održavanje).

IDEF 1 X tehnika za informaciono modeliranje • U okviru faze funkcionalno modeliranje postoje tri osnovne podaktivnosti: funkcionalna dekompozicija (treba da produkuje stablo poslovnih procesa u organizaciji); definisanje zahtjeva korisnika (na osnovu dokumentacije i intervjua određuje se što se treba promijeniti); tehnički preduslovi (hardver, softver, ljudstvo, dinamika realizacije). • Podaktivnosti u okviri informacionog modeliranja su: definisanje detaljnih zahtjeva (odrediti stare procese koji ostaju, nove koji se dodaju i izvršiti integraciju sa određivanjem novih pravila; sve se dokumentuje kroz dijagrame i verifikuje od strane menadžmenta); kreiranje ER modela (kreacija dijagrama - entiteta, veza i objekata; od strane projektanta - kreativna faza a na osnovu zahtjeva korisnika); definisanje atributa (definišu se atributi - osobine objekata, posebna pažnja na definisanju ključeva); definisanje poslovnih pravila (sinteza prethodnih faza u kojoj se definišu poslovna ograničenja i pravila ponašanja). • Aplikativno modeliranje se može podijeliti u faze: definisanje fizičkog dizajna (zapravo SUBP); generisanje šeme baze podataka (tabele i veze tabela itd); kreiranje aplikacije (korisnički pogled na aplikaciju, forme, upiti meniji, web-stranice itd).

Funkcionalna dekompozicija • Proćićemo sada kroz funkcionalno modelovanje i druge faze IDEF 0/IDEF 1 X procedure manje detaljno razmatrajući ono što smo već pomenuli. • Prva aktivnost u okviru funkcionalnog modeliranja je Funkcionalna dekompozicija koja se može podijeliti na: – Definisanje granica sistema – Definisanje stabla aktivnosti – Verifikacija stabla aktivnosti • U prvoj aktivnosti se nabrajaju objekti koji čine sistem. Ovi objekti se kasnije povezuju u stablo aktivnosti. Prilikom određivanja procesa/aktivnosti postavlja se niz pitanja: Zašto se proces modelira? Što će proces da prikaže? Što će korisnik modela da napraviti njime? Čemu služi model? Odgovori na ova pitanja nam služe u fokusiranju na problematiku. Nakon toga slijede pitanja tipa: Koji su zadaci na tom radnom mjestu? Koji je redosljed izvođenja koraka? Kako se izvodi kontrola? Koji se resursi koriste?

IDEF 0 prikaz • Tri načina se koriste da bi se izvršio IDEF 0 prikaz: grafički, tekstualni i rječnik. Suštinski IDEF 0 prikaz je jednostavan posjeduje pravougaonike (često nespecificirani dio cjeline a najčešće funkcijaaktivnost-proces) i strelice koje predstavljaju veze između njih. • Aktivnosti u pravougaoniku obično imaju tri karakteristike: radni glagol (koji može imati i argument ili subjekta); vremensku dimenziju (nije obavezna a može da se koristi da specificira vrijeme potrebno između početka i kraja aktivnosti); rezultat (ne mora se specificirati). Aktivnosti koje ne produkuju odgovarajući rezultat su kandidati za eliminisanje. • Strelice koje povezuju aktivnosti se mogu objedinjavati, račvati itd. Strelice prenose podatke i objekte između aktivnosti. Strelice se imenuju imenicama. Pravac iz kojeg strelica dolazi na kontrolu se koristi da naznači kojeg je tipa strelica. Ulazi i izlazi se crtaju horizontalno (ulazi sa lijeva a izlazi sa desna). Kontrole (odozgo), mehanizmi i poziv (odozdo) su prikazane vertikalno. Kontrola ICOM ili ICAM dijagram. Ulaz Izlaz Aktivnost Mehanizam Poziv

IDEF 0 prikaz • Mehanizam je nešto se koristi u aktivnosti a ne mijenja se. Kontrole determinišu na osnovu skupa pravila što će se pojaviti na izlazu. Poziv je specijalan tip mehanizma koji ukazuje da pozivajući pravougaonik nema detaljni dijagram već je prikaz izveden na nekom drugom pravougaoniku u istom ili nekom drugom modelu. Postupak o izvještavanju Postupak o definisanju šifrarnika Pravilnik o isplatama Izvještaj knjigovodstvu Zahtjev iz kadrovskog Zahtjev iz isplatu Primjer ICOM-a. PRAĆENJE ISPLATA Zahtjev za novu šifru Nalog za isplatu Zahtjev iz izvještaj SUBP Prevodioci Granice dekomponovanja se determinišu na sličan način kao kod SSA.

Karton isplata - Primjer Klasičan primjer lošeg dokumenta u IS-u (knjiga A. Veljović). Ovakav dokument se teško može automatizovati i smjestiti na smislen način u bazu podataka jer vrlo vjerovatno stavka primjedbe je smještena tu da objasni sve ono što tvorci dokumenta na druge načine nisu mogli da urade. Ovako neformatizovana stavka je besmislena sa stanovišta računara i ne može se prikazati na pravi način u bazi podataka. Vrlo vjerovatno ovdje se nalaze stavke koje se prikazuju listom, check boxovima ili na drugi način. U IS-u nema previše mjesta za kolokvijalne opise.

Karton isplata - primjer PRAĆENJE ISPLATA 0 • Većina dokumenata se može realizovati kroz tri aktivnosti: održavanje podataka, održavanje šifrarnika i izrada izvještaja. IZRADA IZVJEŠTAJA 3 2 3. 1 Izvještaj knjigovodstvu 1 2. 1 Održavanje šifrarnika jezika 3. 2 Izvještaj banci 1. 1 Održavanje osnovnih podataka 2. 2 Održavanje šifrarnika radnih mjesta 1. 2 Praćenje nivoa znanja jezika 2. 3 Održavanje šifrarnika odjeljenja 1. 3 Obračun isplate ODRŽAVANJA PODATAKA O PREVODIOCIMA ODRŽAVANJE ŠIFRARNIKA • Eventualna finija podjela zavisi od konkretne organizacije a veoma je bitno da ovaj dokument bude verifikovan od organa u organizaciji. Ovako organizovan posao i sa stanovišta IS pruža dosta prilika za automatizaciju odnosno oslikava pravac u kojem se treba vršiti automatizacija poslovanja. • Nakon funkcionalne dekompozicije vrši se definisanje zahtjeva korisnika. Ovo je proces u kojem projektanti "uče" što su zahtjevi korisnika. Sastoji se iz sljedećih podaktivnosti: – – Definisanje zahtjeva iz dokumenata Definisanje zahtjeva intervjuom Definisanje matrice odnosa Analiza zahtjeva korisnika.

Definisanje zahtjeva korisnika • U prvoj fazi potrebno je prikupiti ulazna dokumenta, izlazna dokumenta, uzorke izvještaja, statut i ostale propise, često i zakonska akta koja determinišu poslovanje, organizacione propise. Neke organizacije imaju službe zadužene za internu dokumentaciju ali je kod nas grubo pravilo da se ne možete pouzdati u to već morate ih sami prikupiti što je često dugo i zametno. Za svaki dokument mora da znate gdje se sve mora proslijediti, ko unosi podatke, odakle podaci stižu, gdje se smiještaju, koliko je kopija potrebno itd. Ova faza je daleko od naivne i kako se često shvata umjetničke "napraviti što ljepšu formu - dokument". Tek kada se dokumenti i podaci o njima prikupe imate šanse da postavite prava pitanja u intervjuu. • Pretpostavimo da je potrebno izvršiti analizu dokumenata "Karton isplata". Dokument "Karton isplata" nastao je zbog potrebnog evidentiranja prevodilačkih poslova u preduzeću. Ovaj dokument se smiješta u istoimenu kartoteku u kojoj se evidentiraju sve promjene vezane za aktivnosti prevodilaca. Podaci koji se unose u ovaj karton potiču iz kadrovske kartoteke a na osnovu evidencije o obavljenim prevodilačkim uslugama. Kao i svi ručni dokumenti i ovaj dokument ima nedorečenosti u smislu nedefinisanja svih zahtjeva koje korisnik može da zahtjeva, a ne može da ih upiše, jer ne postoje "rubrike".

Primjer - Karton isplata • Zbog nedorečenosti dokumenta ostavi se obično jedan dio dokumenta naslovljen kao "Primjedbe" ili "Opis" što pokazuje da onaj ko je projektovao dokument ne poznaje problematiku i da su podaci u dokumentu "Karton isplata" neažurni i netačni i da ne odražavaju trenutno stanje. Ovaj dokument ne omogućava pravljenje različitih analiza jer je nedorečen i ne sadrži sve informacije potrebne rukovodstvu, pa se stoga ne može "automatizovati" već se mora sprovesti intervju i saznati koje se informacije moraju definisati i projektovati. Nažalost dosta dokumenata prije sprovedenog reinžinjeringa poslovnih procesa je ovog tipa. Sa stanovišta informatičara informacije tipa "Opis" su bezvrijedne. Da bi se tekst iskoristio treba detaljno čitati sadržaj teksta i na osnovu toga napraviti novi dokumenat iz kojega će korisnik moći da izabere jednu od više ponuđenih kombinacija. Ovakva informacija se može statistički obraditi što je jedan od zahtjeva ISO 9000. • Definisanje zahtjeva intervjuom je pristup odozgo nadolje i treba da omogući definisanje: potreba za informacijama, ciljeva i problema kako ih vide rukovodioci i neposredni izvršioci. • Ova analiza treba da da odgovore vezane za primjenu Interneta u preduzeću. Već je opisana u dijelu priče o BSP.

CRUD matrica - Primjer Za primjer aktivnosti "Praćenje isplata" mogu se definisati sljedeće podaktivnosti: ODRŽAVANJE ISPLATA CRUD održavanje podataka o prevodiocima; PODATAKA O OSOBA CRUD održavanje šifrarnika; izrada izvještaja. U PREVOD. JEZIK R okviru ovako definisanih aktivnosti se CERTIFIKAT CRUD definišu entiteti (OSOBA, ISPLATA, CERTIFIKAT, ODJELJENJE, RADNO ODJELJENJE R MJESTO). Prethodna tabela prikazuje CRUD RMJESTO R veze između entiteta i aktivnosti. U ovoj ODRŽAVANJE JEZIK CRUD aktivnosti se definišu osnovne postavke dok ŠIFRARNIKA ODJELJENJE CRUD se u okviru aktivnosti "Definisanje detaljne RMJESTO CRUD matrice odnosa" detaljnije specificiraju i IZRADA ISPLATA R atributi korišćenja tzv. IRUN (Insert, Read, IZVJEŠTAJA JEZIK R Update, Nullify) matrica za atribute. Na ODJELJENJE R osnovu izvedenih prethodno opisanih aktivnosti u sljedećem koraku pristupa se OSOBA R analizi zahtjeva budućeg korisnika softverske CERTIFIKAT R aplikacije. Aktivnost "Analiza zahtjeva korisnika" znači da postavke definisane u prethodnim koracima treba da verifikuje odgovarajuće verifikaciono tijelo preduzeća. Zadatak verifikacionog tijela je da usvaja rezultate rada stručnog tima u kontrolnim tačkama koje predstavljaju okončanje pojedinih faza na izradi projekta. Treba naglasiti da sve navedene aktivnosti i podaktivnosti moraju ići ovim redosljedom i da definisanje tehničkih preduslova tek onda dolazi u razmatranje. U praksi se obično radi naopako. Naziv aktivnosti Naziv Entiteta CRUD

Aktivnost - Tehnički preduslovi • Tehnički preduslovi su prije svega: sistemski softver, hardver i dokumentacija. • Hardver uključuje mrežnu opremu. Najvažniji elemenat sistemskog softvera je operativni sistem koji može biti monokorisnički ili višekorisnički, prilagođen jednoj ili više platformi te prilagođen multiprocesorsko i/ili distribuirano izvršavanje. • Ova aktivnost se dijeli na tri podaktivnosti: – Definisanje arhitekture sistema – Kadrovske potrebe – Dinamika realizacije i troškovi • Prilikom dizajna sistema treba voditi računa da mora biti što je moguće savremeniji (da bi što je moguće duže trajao!? ): treba imati na umu mogućnosti Interneta, Intraneta, distribuirane obrade podataka, korišćenja baza podataka, itd. • Prilikom razmatranja tehničko tehnoloških resursa treba definisati 7 nivoa povezivanja računara i računarske opreme sa stanovišta otvorene arhitekture referentnog modela (OSI): • Nivo 7 Aplikacijski nivo; Nivo 6 Prezentacioni nivo; • Nivo 5 Nivo sesije; Nivo 4 Transportni nivo; • Nivo 3 Mrežni nivo; Nivo 2 Nivo podataka; • Nivo 1 Fizički nivo (bitovi).

Tehnički preduslovi • Sljedeće zahtjeve treba imati na umu prilikom definisanja tehničkih preduslova: kvalitetan komunikacioni sistem, visok stepen kompatibilnosti opreme, otvorenost mrežne arhitekture, modularnost opreme krajnjih korisnika, korišćenje softverskih proizvoda za razvoj aplikacije, treba da omogući integraciju informacija u obliku podataka, glasa, teksta, slike i crteža itd. Većina ovih elemenata se izučava u drugim kursevima (uglavnom komunikacionim i onima koji izučavaju administriranje sistemom) tako da ćemo detaljisanje o tim problemima preskočiti. • U slučaju da se implementira distribuirani sistem obrade podataka treba procijeniti složenost implementacije i troškove. Distribuirana obrada nudi mnoge povoljnosti ali ju je ponekad teže implementirati a ponekad inicijalna cijena ovog načina implementacije je veća. Veliki izazov kod ovih sistema predstavlja jedinstvenost podataka. Npr. više klijenata pokaže zahtjev za istim resursom (npr. nešto iz magacina ili avio karta). • Danas u razvoju aplikacija treba voditi računa da se koriste savremene tehnike kao što su: generatori izvještaja, neproceduralni jezici višeg nivoa kao što je SQL, generatori aplikacija, parametrizovani namjenski softverski paketi.

Tehnički preduslovi • Ako sistem zaglavljuje, pada, ne radi dobro, ne podržava veći broj korisnika postoji mogućnost da je njegov problem u tehničkim preduslovima na strani hardvera i komunikacione opreme. Što se tiče komunikacione opreme često je slučaj neadakvatan izbor mrežne arhitekture i nedovoljan ili neadekvatan izbor rutera i ostale mrežne opreme a rjeđe mali protok. Promjena mrežne arhitekture može biti složen problem. • Međutim, češći problem je softverske prirode odnosno neadekvatna implementacija baze podataka. Naime, baza podataka mora biti normalizovana po pravilu jedna stvar na jednom mjestu. Ključevi moraju na jedinstven način da identifikuju objekte. Ponekad programeri i dizajneri to implementiraju na početku ali se pokaže da reinženjering poslovnih procesa nije dobro proveden (bilo krivicom izvršilaca bilo lošim informacijama od poručilaca, mada i tu krivica pripada projektantu) pa se moraju vršiti prepravke a u prepravkama koje se provode "uživo" po pravilu se zaboravi na potrebu za normalizacijom baza i pravilnim indeksiranje. • Poznat je nedavni problem sa informacionim sistemom E-matica srednješkolskog sistema Republike Hrvatske koji je krahirao iz vjerovatno drugog seta razloga.

Softverski implementacioni sistemi • Svi viši programski jezici, sistemi za upravljanje bazama podataka, Internet alati, generatori koda, aplikacija i izvještaja su kandidati za implementaciju softverskog sistema. • Najvažniji kandidati su skupi ali veoma kvalitetni sistemi najvećih korporacija. • Programeri koriste programske jezike, razvojne alate i okruženja. Pored toga u modi su i relativno jeftini alati kao što su oni vezani za My. SQL, PHP platforme. Generalno govoreći većinu jednostavnih problema je moguće riješiti na svim današnjim popularnijim platformama i ako nešto ne funkcioniše krivica je kod implementatora a ne kod alata. • Ne zaboravite da koriste UML, Er. Win, BPWin i druge alate za modelovanje, razvoj aplikacija, generisanje koda i vođenje dokumentacije. • Na zapadu posebno u Velikoj Britaniji početne faze implementacije velikih IS ili velikih promjena u IS podrazumijevaju obuku korisnika odnosno kurseve. Smatra se da obučeni korisnici imaju veće šanse da pravilno ukažu na moguće pravce unapređenja IS-a od onih koji to nijesu. Kursevi obuhvataju one od elementarnih do veoma naprednih a stvarni sadržaj se prilagođava klijentima.

Mogući kursevi u obuci korisnicima • Mogući kursevi: – – – MS Office Internet i prateći alati MS Access i kreiranje prototipske aplikacije nad bazom podataka Alati za vođenje i praćenje projekat (MS Project) Modelovanje podataka. • Troškovi se planiraju u okviru grupa poslova kao što su: – troškovi razvoja aplikacija; – troškovi tehničko-tehnoloških resursa; – troškovi eksploatacije. • Svaka od ovih grupa poslova se takođe sastoji od posebnih troškova i otuda specifikacija troškova treba da čini sljedeća struktura: – troškovi razvoja (obuka projektnog tima; razvoj zajedničkih aplikacija; stručna pomoć pri razvoju; razvoj i dopuna sopstvenih aplikacija; softverski proizvodi za razvoj aplikacija); – troškovi tehničko-tehnoloških resursa (računarska oprema zajedničkih resursa; oprema komunikacionog sistema; dopuna i kompletiranje računarske opreme; prateća oprema i adaptacija prostora); – troškovi eksploatacije (održavanje opreme; potrošnja električne energije; korišćenje komunikacionih linija; amortizacija opreme; plate radnika). • Kao rezultat aktivnosti "1. Funkcionalno modeliranje" trebalo bi da proizađe dokument pod nazivom "Studija elemenata potrebnih za reinžinjering poslovnih procesa" na osnovu koje se sprovodi sljedeća aktivnost "2. Informaciono modeliranje. "