Jedno banalno pitanje, nije potcenjivanje: Da li si ikada radio neki poslovni softver? Posto vidim da si odskora poceo da ucis te alate na fakultetu, da nije mozda to tvoj zadatak za fakultet? Ako jeste, onda si trebao da naslovis temu "Potrebna pomoc u vezi seminarskog rada - IS apoteke".

Ne, nisam nikada radio neki poslovni softver. To je moja tema za seminarski rad za fakultet. Pa me zanima sta bi prvo uradili oko modeliranja baze podataka. Pa dobro ako sam pogresio u nazivu teme zašto bi to moralo da bude važno? Na fakultetu radim modeliranje baze podataka u BPWIN-u i ERWIN-u. I zaboravih reći, da bi jako volio da naučim da radim poslovne softvere.

Zato sto postoji velika razlika izmedju "Pravim softver za apoteku" i "Modeliram bazu podataka za apoteku u ERWIN-u" ;)

Ja sam samo pretpostavio da je to u pitanju i pokusao to da ti drugarski napomenem. U resavanju tvog problema sada treba da ucestvuju ono koji to i rade, a ne da ti se javljaju raznorazni koji ti ne mogu pomoci.

Srecno!

Hehe, ma ok je :) Dobro si to zaključio. Ajte ljudi malo me posavjetujte :)

Absolutno tacno. Ali, moze i dalje. Takodje postoji razlika izmedju "Modeliram bazu podataka za apoteku u ERWIN-u" i "Modeliram bazu podataka za apoteku".

"Modeliram bazu podataka za apoteku" moze potpuno da se izved pomocu olovke i papira. To je ono STA radis. ERWIN, BPWIN ili bilo sta drugo su samo alati koji mogu, ako znas da ih upotrebis, da ti skrate vreme potrebno za pisanje koda kojim se tvoj logicki model pretvara u fizicki (kreiranje tabela u odabranom RDBMS). ERWIN i BPWIN su dakle KAKO Ima jos ponekih dodatnih benefita (dokumantacija i slicno) gde stepen korisnosti zavisi od dostignutog nivoa organizovaniosti firme/pojedinca koji radi taj projekat.

Sta je tvoj problem? Moglo bi biti nesto od ovoga, ugrubo po redosledu dogadjanja:
- ne umes da odradis analizu problema (prethodi izradi logickog modela)
- ne umes da napravis logicki model baze podataka
- ne umes da koristis ERWIN i/ili BPWIN
- ne umes da logicki model prevedes na fizicki model
- ne umes sa gotovog modela baze podatka da predjes na izradu same aplikacije
- sve ovo i jos ponesto

Ili, jos bolje, sta je cilj seminarskog
- da naucis da koristis ERWIN/BPWIN
- da naucis da anliziras poslovni proces
- da naucis da radis logicki pa fizicki model, i da se pomognes alatima ERWIN/BPWIN
- da napravis aplikaciju (sa bazom podataka) koja ce zaista da radi neke stvari
- sve navedeno i jos ponesto

Pokusaj da odgovoris na ova pitanja i onda ce neko vec moci da ti pomogne. jedan od marfijevh zakona kaze 'kad god treba nesto da uradis, uvek ima nesto sta treba uraditi pre toga. E, sad smo u toj situaciji.

Ti si na potezu.

E ovako, pošto vidim da nisam dobru temu postavio :) sad ću da vam objasnim koliko mognem. Kad smo krenuli sa drugom godinom na faksu (neću da ga reklamiram) počeli smo iz informacioni sistema da prvo radimo modeliranje baze podataka za neki softver. Prvo šta smo radili jemo učili funkcije iz programa BPWIN-a ali nismo radil ERWIN. BPWIN i znam kako se radi ono osnovno šta trebam da znam u BPWIN-u. E sad, kod tog BPWIN-a postoje:

Ulazno-izlazni podaci kod IS Apoteke
Kontrola tih podataka
Mehanizam i
poziv

Kako bi to izgledalo? Evo link: http://img295.imageshack.us/my.php?image=osnovaxo3.jpg

E sad, radili smo informacioni sistem kafića

Kako izgleda početna faza? Evo link: http://img504.imageshack.us/my.php?image=iskaficawz2.jpg

E šta mene zanima kod IS Apoteke, tj. šta ne znam kako vi već kažete?

Ne znam šta su ulazni i izlazni podaci kod IS Apoteke, koji bi mehanizmi mogli da budu, kako se vrši kontrola tih podataka itd itd. Nadam se da sam sad malo bolje objasnio.

Hvale. Sad bolje razumemo sta je po sredi.


Problem je dakle analiza. Alat BWIN umes da koristis, i to sluzi koliko mi se cini, da na neki nacin opises poslovni proces. Ono B dolazi od Business izgleda Kao sto si uradio za kafic, uradi i za apoteku. Apoteka ti je kao maloprodaja robe. Kupuju se lekovi od dobavljaca, i prodaju se. E tu je pretpostavljam mala razlika u odnosu na bakalnice. Neki lekovi su u slobodnij prodaji a neki idu na recept. neki se prodaju slobodno, a neki uz uvid u licnu kartu. To ce najbolje da ti objasni neki apotekar. Ako nemas apotekara, onda malo razmisljaj sta se desava kad odes u apoteku, kakva je komunikacija izmedju tebe i apotekara, kakva razmena dokumenta, robe i novca se vrsi, sta se razmenjuje i kako.

Mene je uvek mucio problem kako sa dijagrama koji se nacrta u BPWIN preci na nesto sto ces nacrtati sa ERWIN. To je sustina onoga sto radis. Javi se kad nacrtas BPWIN dijagram, da ga vidimo i da onda mozda nekako sve pretvorimo u ERWIN. Mene jako zanima da vidim kako se taj proces transformacije BP dijagrama u ER dijagram odigrava.

Koliko znam, ima tu i proizvodnje, pripravljanje raznih pomada i sl. po odredjenim recepturama, dakle gotovi proizvodi, materijal ...

Iskusan sistem analiticar bi verovatno iz par intervjua saznao sve sto je potrebno, tebi ce trebati malo vise jer jos uvek ne znas koja su prava pitanja koja treba da postavis ...

Neću mnogo da detaljišem ali stvari stoje ovako:

BPwin - Business Process for Windows služi za funkcionalno modeliranje i upravo onako kako je Mr_Q007 započeo. Ulazi, Izlazi, Kontrole, Mehanizmi, Glavna aktivnost, Podaktivnosti, Grananja do željenog nivoa detaljnosti. Svrha je grafičko-tekstualna dokumentacija poslovvnog procesa i obavlja se onako kako je Goranvuc rekao, putem intervjua.
Definisanje zahteva intervjuom ( metodologija odozgo na dole ) daje širinu u pristupu.
Definisanje zahteva iz dokumenata ( metodologija odozdo na gore ) daje preciznost.

ERwin - Entity Relationships for Windows služi za informaciono modeliranje. Entiteti i atributi na logičkom nivou i Tabele i kolone na fizičkom nivou uz povezivanje i poštovanje kardinalnosti, referencijalnog integriteta i svega što prati relacione baze podataka. Ovde je moguć prelaz sa fizičkog nivoa na konkretni SUBP ili DBMS kako hoćete. Ovaj softver omogućava generisanje šeme baze podataka za veliki broj SUBP-ova. I tu je kraj automatizacije.

Sada da se nadovežem na ovo što je Zidar poželeo : “Mene jako zanima da vidim kako se taj proces transformacije BP dijagrama u ER dijagram odigrava.” I ja sam to odmah poželeo čim sam shvatio suštinu oba softvera :-)
Bar koliko ja znam ne postoji mogućnost da BpWin predloži ErWinu entitete i atribute na osnovu iskazanih aktivnosti, podaktivnosti, ulaza (dokumenti i informacije), izlaza (takođe dokumenti i informacije), kontrola (zakoni, propisi i sl.), mehanizama (ljudi i mašine za obavljanje aktivnosti).
Moglo bi putem Export/Import metode eventualno izvršiti uvoz u ErWin, međutim tada bi od početka modelovanja u BpWin-u trebalo razmišljati o kandidatima za entitete i atribute, što bi narušilo suštinu funkcionalnog modelovanja. Na nivou informacionog ne bi donelo ništa novo jer bi predstavljalo gubitak vremena. (To isto ste odmah mogli da otpčnete u Erwinu). Kada bi takav prelaz mogao da se uradi elegantno, po meni bi to bio zadivljujući softver koji bi nadmašio i najbolje današnje ISPO (inteligentne sisteme za podršku odlučivanju) iako se u ovakvom poređenju ne radi o istoj ravni.
Na stranu to što bi takav softver morao da preskoči osim barijere razmišljanja (što je još uvek privilegija čoveka) i jezičku barijeru jer bi morao da razmišlja lokalno.
I da ne ispadnem baš tako decidan ostaviću mogućnost da je nešto urađeno na tom planu u verziji Erwin 7.2 koju zaista nisam imao prilike da isprobam.

Na kraju poruka za Mr_Q007. Ovo što je Goranvuc već rekao. Raspitaj se malo oko apoteka, definiši zahteve tvog budućeg softvera, uporedi sa maloprodajama i kafićima koje je Zidar pomenuo, a toga ima dosta na ovom forumu. Kad budeš odlučio da li će tvoja apoteka samo da prodaje lekove ili pored toga i da pravi preparate, napravićeš prvi i glavni korak.



_{[Ovu poruku je menjao Getsbi dana 22.12.2007. u 10:28 GMT+1]}

Pre nego što se krene sa crtanjem u BPwinu i ERwinu treba izabrati metodologiju projektovanja. Ona će dati odgovor na gornja pitanja.

@ Mr_Q007
Evo konstruktivnosti radi jedan dobar link sa modelima koji bi bili smernica:
http://www.databaseanswers.org/data_models/
Samo ukucaj reč (Pharma) na Find on this page svog browsera i odvešće te na nekoliko linkova koji se tiču farmakologije. Pogledaj i druge srodne teme koje smo pominjali u prošlim postovima. Iza svakog od njih imaš ponešto ili o poslovnim zahtevima i pravilima ili pomoć oko razumevanja problema.

He, hvala ljudi na trudu najbolji ste. Kako ste vi rekli da porazgovaram s nekim akopotekarom. To ću sutra i da uradim. Znam nekoga ko radi u apoteci pa će mi ta osoba sve reći kako se to tamo radi. Kad napravim u BPWIN-u mogu okačiti ovde ako vas zanima. Hvala jos jednom.

Hvala Getsbi za ovaj link puno !!!!

Pošto smo pokretaču teme pomogli, a u želji da ne ostanem ne dorečen, napisaću još par rečenica bez želje da izazovem diskusiju, već da iznesem svoja iskustva.

Naravno da mi je poznato da se kroz BpWin funkcionalno modeliranje ostvaruje putem tri metodologije: Business Process Modeling (IDEFO), Proces Flow Modeling (IDEF3) i Data Flow Diagramming (DFD). Ova treća bi trebala da se najčešće koriste za implementaciju menadžment informacionih sitema. Ono što je mene odbilo od korišćenja zadnje pomenute metodologije u BpWinu i zašto koristim direktno ErWin bez Export/Import opcije je upravo ta kozmetička povezanost. Ako ja treba da predložim kandidate za entitete i veze između njih u BpWinu, da bi ih Exportovanjem on meni predložio kao gotove entitete u ErWinu i gde ja ponovo treba da radim na vezama, onda hvala lepo. Radije ću održavati jednu grafičko-tekstualnu dokumentaciju nego dve koje se suštinski ne razlikuju i gde od ove prve nemam baš neke koristi. Možda je bilo arogantno s moje strane, kada sam pomenuvši generisanje šeme baze podataka iz ErWina u druge SUBP-ove rekao da ju tu kraj automatizaciji ali moja iskustva su takva. Želja mi je da jednog dana vidim dovoljno inteligentan softver koji će predlagati entitete na osnovu Business Process Modeling-a, pa makar to za početak bilo isključivo na engleskom.
I na kraju, od svega je najvažnije da je Mr_Q007 zadovoljan i da smo ga svi skupa uputili na pravi put. :-)

Kako vam se čini Oracle CASE?

Od nove godine ću početi pisati TUTORIAL za ovo što sam mislio da pravim ili step by step. Tako da ova tema može da bude završena

Nisam slucajno postavio pitanje o prelasku sa biznis dijagrama na dijagram baze podatka
Naravno da ni jedan sistem to ne radi automatski niti moze. Ne postoji cak ni matod/algoritam koji bi ljudi koristili onako rucno, da se jedan dijagram prevede u drugi. kad bi postojao, neko bito vec automatizovao. Ovo je u sustini isto sto je Getsbi rekao. Nacrtati dijagram procesa je jedna stvar, a nacrtati model baze podatakaje nesto drugo. Dijagram procesa svakako pomaze, ali ne postoji skup pravila koji bi iz dijagrama procesa dao dijagram modela baze podataka (tabele i veze).

Koji alat i koju vrstu dijagrama koristiti, zavisi od situacije, pa i od ukusa onoga ko radi posao. Alata ima raznih, kao i metodologija. Za neke realne probleme bo,je je ovo, a za neke druge bolje je nesto drugo. ORACLE CASE*METHOD je samo jos jedan metodologija, podrzana gomilom alata i koja bi trebalo da lepo radi u ORACLE okruzenju. Nisam mnogo s tim radio, ali sam imao priliku da vidim kako to sve izgleda. Od cele price ima elementaa u crtanju functional depencdency diagrama koji mi se dopadaju, ostalo me nije oborilo s nogu. Naravno da ni tamo nema mapiranja sa funkcionalnog dijagrama na entitete i atribute.

Sve u svemu, ko se kako snadje

Da li je onda projektovanje baza podataka:

a) Inženjerska disciplina
b) Umetnost
c) Crna magija
d) Sve ovo zajedno
e) Ništa od gore navedenog...

???

:-)

Kakav je onda smisao ova dva dijagrama? Da li nam trebaju baš oba?

pa, valjda je potrebno prvo upoznati se sa stanjem/situacijom kako bi znao/otkrrio/shvatio šta je korisnicima konkretno potrebno

Nekako mi ona definicija pod a) Inženjerska disciplina, najviše odgovara, mada su ljudi skloni da sve što im izgleda iole komplikovano nazovu umetnost. :-) Pre bih to umesto umetnosti nazvao skupom iskustava stečenih radom na projektovanju informacionih sistema korišćenjem već ranije pominjanih pravila.

Zašto uopšte dijagrami?

Zato što je uopšteno govoreći mnogo lakše vršiti i razvoj i naknadne promene prilikom posedovanja grafičko-tekstualne dokumentacije, radilo se o timu developera ili pojedincu Posmatrano sa aspekta promene članova tima i njihove migracije sa projekta na projekat ova potreba postaje nužnost. Kada su veći projekti u pitanju, vlasnici sve češće zahtevaju standardizovanu dokumentaciju putem nadzornih organa.

Zašto oba?

Pretpostavljam da je prvi dijagram ili funkcionalno modeliranje koji se tiče poznavanja poslovnih procesa, aktivnosti, poslovnih pravila i svega drugog što je neophodno za samo projektovanje informacionog sistema nad jednim projektnim zadatkom, manje sporan. Iluzorno je i upuštati se u projektovanje nečeg o čemu nemate elementarna znanja i čiju problematiku uopšte ne poznajete. S druge strane ako se tim promeni ili pojedinac nešto zaboravi, hoće li vlasnik dozvoliti ponovno intervjuisanje po istim pitanjima.

Eventualno bi se moglo postaviti pitanje zašto dijagram baze podataka ili informacionog modela kada to isto ili nešto slično imamo u fizičkom modelu baze podataka ili ga iz njega možemo iscrpeti. Odgovor bi bio takođe zbog standardizacije. Kada posedujete standardizovanu dokumentaciju na logičkom nivou, onda je u mnogome olakšana komunikacija između članova tima koji u osnovi svi i ne moraju poznavati i raditi u istom SUBP-u. Pogotovo je ovo važno kada se prelazi sa jednog SUBP-a na drugi. Svi koji su se bavili konverzijama baza podataka, znaće o čemu pričam.

Getsbi je lepo odgovorio. Evo i mog dodatka:

Da li je onda projektovanje baza podataka:

a) Inženjerska disciplina
b) Umetnost
c) Crna magija
d) Sve ovo zajedno
e) Ništa od gore navedenog...

???


a) Inženjerska disciplina
Nazalost nije. Ali je na putu da to postane, pre ili kasnije. Inzinjerske discipline zasnivaju se na matematice, fizici i hemiji recimo, ali idu dalje od naucnih principa. Iz fizike se uci na primer kosi hitac, i svesno se zanemaruje otpor vazduha, kao nebitan uticaj u principu. Medjutim, u praksi je otpor vazduha i te kako bitan, toliko bitan da mu se vise paznje poklanja nego samom principu, koji se prihvata skoro zdravo za gotovo. Inzenjerske prihvataju principe iz fizike, koji definisu STA se radi. Inzenjerske discipline principe ne dokazuju, to je uradila fizika. One ih nadgradjuju i odatle proizilaze pravila KAKO se nesto radi. Ako gradjevinskom inzinjeru date da sracuna sile i momente za neki nosac, on to moze uraditi graficki, rucno, pomocu šibera, digitronom, racunarskim programom i razultati ce uvek biti isti. Provera tacnostije uveki ista i jednostavno se radi bez ikakvih pomagala: suma svih sila i momenta u bilo kom preseku nosaca mora biti nula. Za to ne treba ni digitron, rucno sabiranje je savrseno moguce.

Projektovanje baza podataka postace inzenjerska disciplina kada budemo mogli da pogledamo u dijagram baze i da vidimo da li je dijagram "dobar", na nacin na koji proveravanmo da li je zbir sila i momenata nula u svim tackama na nosacu. Za to moramo da znamo "vanjske sile koje deluju na sistem". U bazama podataka vanjske sile su poslovna pravila i uslovi integriteta, kardinalnost i slicno. Vanjske uticaje daje nam dijagram biznis procesa. Odatle sledi dijagram baza podatka. Kad imamo gotov dijagram baze podataka, i poznajemo vanjske uticaje, onda mozemo recimo da proverimo da li je baza podataka normalizovana. Znaci, pravila normalizacije treba primeniti na kraju, kao proveru da li je baza dobro uradjena. I zaista, kad projektujemo bazu, smisljamo tabele i sta u koju ide i kako se one odnose jedna prema drugoj, mi vidimo da nesto treba razbiti na vise tabela. Niko ne kaze "Prvo cu sve da stavim u flat tabelu. Pa cu sad cu sve da dovedem na 1NF. Dobro, sad cu da 1NF prevedem u 2NF i tako dalje". Posle ovoliko godina mi jednostavno 'znamo' da se fakture stavljaju u jednu tabelu, artikli u drugu a da se stavke fakture stavljaju u trecu tabelu koja povezuje artikle i fakture.

Rekosmo kako dijagramu baze podataka prethodi dijagram biznis procesa. U gradjevinarstvu, postoji arhitektonski crtez (1). Sa njega inzenjer je u stanju da vidi staticke uticaje, pa sledi dijagram nosaca sa silama koje na njega deluju (2). Onda sledi proracun (3), pa provera proracuna (4). A onda dodje dimenzionisanje elemenatka konstrukcije grede, ploce , zidovi, temelji (5) i onda neko to sve napravi i dobijemo gotov proizvod - kucu, most, vodovod (6)
Vidimo 6 jasno definisanih koraka. Svaki korak je regulisan pravilima prakse, profesionalnom etikom i drzavnim zakonima. Zakon zahteva da se pre koraka (6), izgradnja, napravi revizija projektne dokumntacije. Nezavistan inzenjer proverava da li su projektanti (tim) odradili sve korake, da li je svaki korak odradjen u skladu sa pravilima struke i po zakonima. Tek onda se ide u izgradnju, koja se opet kontrolise - imate nadzorni organ na gradilistu. Svega toga u projektovanju baza podataka i izradi informacionog sistema nema. Ima nekih elemenata, ali jasan sistem ne postoji, niti zakonska regulativa. A ne daj boze da se ztrazi revisija projektne dokumentacije, da se pogleda dizajn baze ili dizajn programskiog koda pre nego sto se pristupi pisanju aplikacija i fizickom kreiranju baze. Inzenejri kad god otkriju nesto novo, neki postupak, materijal, brze bolje trce da to objave negde da i ostali vide i mozda nauce. Softverasi se ubise pokusavajuci da sakriju kod od drugih, sto je jako glupo, ali ne vredi govoriti onom ko ne zeli da slusa.

Zato projektovanje baza podataka nije inzenjerska disciplina i ljudi ne zele da to postane. Ali ce morati d apostane inzenjerska disciplina li ce jednostavno nestati kao profesija. ne mozete sebe proglasiti inzenjerom. Ali i te kako mozete sebe da proglasite programerom ili projektantom baza podatka.

b) Umetnost
Jeste donekle. Za umetnost je potreban talenat, za projektovanje baza podatka takodje. Svaka inzenjerija je umetnost.

c) Crna magija
Nekada se alhemija smatrala hemijom, posto hemija nije postojala. Ukoliko prihvatimo da jos uvek ne postoji hemija za baze podataka kao inzenjerska disciplina, odgovor je da, jeste po malo i magija, bela ili crna, jer trenutno nemamo nista bolje na raspolaganju.

d) Sve ovo zajedno
Ocigledno je da jeste sve ovo zajedno, ali ce se verovatno kroz vreme zastupljenost pojedinih komponenti promeniti u korist rigorozne inzinjerske discipline.

e) Ništa od gore navedenog...
Posto je projektovanje baza podataka sve gore navedeno, onda ocigledno ne moze biti "nista od ovoga navedenog"

???

Evo kako bi moglo sa dijagranma biznis procesa da se dodje do modela baze podataka:
1) Procitati akcije koje se vide na dijagramu poslovnog procesa. Primer: Kupac kupuje robu od prodavca.
2) Svaka imenica u jednoj ovakvoj recenici je potencijalni entitet, sto ce mozda postati tabela. Imenice u jednoj reenici su ocigledno povezane. Eto potencijalnog Foreign Key. Slede entiteti/tabele tblKupci, tblRoba, tblKupljenaRoba
3) Pored akcija, mogu se uociti i neki dokumenti koji postoje ili nastaju u procesu. Dokumenti su u stvari nacin zapisivanja akcija. Primer: Kupac kupuje robu od prodavca. nastaje dokumet Racun. Racun ima zaglavlje i stavke. Racun se izdaje kupcu. Sve osim poslednje recenice imamo pokriveno tabelama do sada. Dodajemo novu tabelu, Racuni kojoj je roditelj Kopci, a dete je KupljenaRoba, koju mozemo preimenovati u StavkeRacuna

Znaci, (dijagram poslovnog procesa) => (recenice koje opisuju proces, dokumenti u procesu) => entiteti

Kad smo definisali nekoliko kljucnih entiteta, onda im dodamo atrinute, koji opet dolaze sa dijagrama procesa i/ili dokumenata.

4) Onda pogledamo da li trenutni raspored entiteta i njihovih veza dovodi do anomalija prilikom INSERT/UPDATE/DELETE operacija (Ovo se cesto predaje kao uvod u normalizaciju)
5) Pokusamo da otklonimo uocene anomalije pravljenjem novog rasporeda entiteta i atributa

6) Kad msilimo da imamo dobar raspored entiteta i atributa, proverimo da li trenutni model zadovoljava uslove normalnih formi, recimo do trece. Pravila prakse bi trebalo da definisu do kog stepena normalizaciej (do koje forme) treba ici u kom slucaju, kao i minimum. Na primer 3NF je minimum, a ako se uvodi vremenska komponenta u igru onda mora biti zadovoljena 5NF.

Ako bismo objavljivali radove i objasnjavali kako je sta uradjeno, ubrzo bismo naucili sta je najbolje raditi kad se projektuje IS za bakalnicu, a sta radi dobro kad se projektuje IS za autobusku stanicu ili aero saobracaj. Ili distribucija gasa, vode, struje. Ili sta je najbolje raditi kada se projektuje IS za skole ili lekarske ordinacije.

E tada cemo psotati inzenjerska disciplina.

Mislim da je projektovanje baza (ipak) inženjerska disciplina. To malo udara na našu bazadžijsku sujetu, ali je tako. Da je umetnost, izučavalo bi se na nekoj od umetničkih akademija. Baza ima sasvim praktičnu namenu i nije joj svrha neko izazivanje emocija (mada znam za neke korisnike koji prema svojim bazama gaje određene emocije :-) ). Kada kažem "inženjerska disciplina" mislim na sledeće: Za zadati skup problema (projektni zadak) do rešenja (projekta) se dolazi primenom izabrane metodologije (skupa pravila koji, kada se primene na uslove iz projektnog zadatka, sigurno dovode do rešenja). Mislim da su prednosti ovog pristupa očigledne i da ne zahtevaju detaljniju elaboraciju.

P.S.
Da li ona dva ranije pomenuta dijagrama imaju još neke funkcije osim dokumentovanja?

Dobro, neka je inzinjerska disciplina. To je najblize pameti.

Kako kome. Ja bez njih ne mogu da uradim nista vljano. Nije da nisam probao :)

Kad se kuća završi, onda zaista arhitektonski crteži i statički proračuni ne služe ničemu više osim za post projektnu dokumentaciju. Ali do tog momenta to je dokumentacija na osnovu koje se objekat gradi. Tako i ovo. Kad je sistem završen, nikoga više nije briga za dijagrame i šeme. Za razliku od građevinskih objekata, IT sitemi nikada nisu završeni, tako da dijagrami s vremena na vreme pritrebaju.

Lično još nisam spreman da prihvatim da je projektovanje baza podataka inženjerska disciplina. Trebalo bi da bude, ali nisu se još uvek stekli uslovi.

:-)

Može li mi neko dati link koji već dva sata tražim na forumu gde ima opis dijagrama za poslovanje za modeliranje IS-a. Našao sam dva puta i sad treći kad mi treba ne mogu da ga nadjem. U pitanju su početni dijagrami nulte razine.

Kao što sam rekao da ću pisati tutorijal za informacione sisteme pa evo nešto o metodi IDEF0 takozvanoj Funkcionalno modeliranje IDEF0.

– omogućuje sistematičnu analizu posla tj. za svaku poslovnu funkciju se obezbeđuje kontrola ispravnosti, planiraju se potrebni resursi potrebni da se funkcija realizuje, ulazi u poslovnu funkciju, kao i izlazi koji se na osnovu ulaza generišu.

– IDEF0 je tehnika modeliranja aktivnosti bazirana na kombinaciji grafike i teksta koji su predstavljeni na organizovan i sistematičan način da bi se povećala razumljivost, koja podržava analizu, obezbeđuje logiku za potencijalne izmjene, specifira zahtjeve, ili podržava analizu sistema po nivoima i integriše aktivnosti.

IDEF0 model se sastoji od hijerarhijskog niza dijagrama koji postepeno prikazuju sve više detalja o funkcijama i njihovoj međuvezi ( interface ) sa ostalim dijelovima sistema. IDEF0 ili workflow modeliranje omogućuje analizu osobina određenog poslovnog procesa sa ciljem njegovog maksimalnog unapređenja.

Postoje tri vrste dijagrama:

o grafički
o tekstualni
o rečnik ( glossary)

IDEF0 omogućuje:

• izvršenje sistema analize i dizajna na svim nivoima, za sistem sastavljen od ljudi, mašina, materijala, računara i informacija;
• stvaranje dokumentacije paralelno sa razvojem sistema koja služi kao osnova za integraciju novih sistema ili za unapređenje postojaćih sistema
• bolju komunikaciju između analitičara, dizajnera, korisnika i menadžera
• omogućuje diskusije u radnom timu da bi se postiglo međusobno razumijevanje
• omogućuje upravljanje velikim i složenim projektima
• obezbeđuje elemente potrebne za modeliranje podataka


Za početak je mislim sasvim dovoljno pa će nastavak biti sutra :)

Jel našao neko link onaj što sam tražio? još uvek ne mogu da ga nađem?

Ne znam o kojem linku se radi. Jel' o ovom ?
http://www.databaseanswers.org/data_models/

E tooooooooooooo hvala puno

Stoji ti na prvoj strani ove teme već dve nedelje. :-)

Ja kontam sve nije na ovoj temi pa nije negde sam drugdje našao uffff hvala brate :)

ima i u jednoj TOP temi takodje

Ima firma koja je uradila softver za apoteku, i ljudi koji su ga radili proveli su dve godine u apoteci da bi se upoznali sa poslom da bi mogli da urade program koji moze da zadovolji potrebe apotekara. Konkretno koristim taj program i nije ni malo naivno tako nesto napraviti. Zato razmisli jos jednom o toj ideji.

2 godine u apoteci da bi napravili program?
to mogu da razumem ako su (apsolutni) pocetnici u projektovanju

za 2 godine firma predje na ERP u celosti (kako koja i u zavosnosti od novca i korisnika, al' moze da se predje u potpunosti za 2 godine)

Dve godine? Možda je neki od projektanata/programera besplatno lečio čir na želucu. :-)
Šalim se naravno. Dužina uglavnom zavisi od kvaliteta tima. Brojnost članova, specijalnosti, iskustvo, dobar odabir i poznavanje alata za projektovanje i RDBMS-a, korišćenje metode intervjua, prikupljanje dokumenta.......
Ako sve ovo učite iz početka, onda vam je i dve godine malo.

Cekaj, cekaj
Nisu oni pravili program 2 godine, vec su proveli dve godine u apoteci da bi skontali sta treba da naprave :-D
Za to vreme su, valjda, da bi preziveli, radili kao apotekari, a hranu su im donosile zene i devojke :-D

To se zove extreme programming :-D

Mozda taj program zna sam da vodi apoteku, da da uputstva za pravljenje koje pomade ili nekog leka, zatrazi kupcu recept, kaze na koliko se pije lek i u kojim dozama:-)