kako dokumentujete svoj rad?

Da li uopste i kako dokumentujete svoj rad? Mislim na rad u Accessu, mad se 90% moze primeniti na bilo koju platformu, cak i web. Tacka 4) se razlikuje verovatno od platforme do platforme, sve ostalo je isto.

Da razbijemo na podpitanja, sva pocinju sa "Da li i kako. dokumentujete...":
1) zahtev korisnika
2) poslovni proces
3) model baze podataka
4) aplikaciju i objekte
5) korisnicki prirucnik - User manual

Ono pod 1) je jako korisno, jer moze da posluzi kod utvrdjivanja cene i naplate i 'prijame radova'

2),3) i 4) je jako korisno imati za sebe, mnogo olaksava posao

5) samo ako vam korisnik izricito trazi i posebno se naplacuje. Moze da bude u i vidu nekoliko casova obuke za rad sa sistemom, sa ili bez pisanog uputstva (koje niko inace ne cita)

Kakva su vam iskustva, frustracije, zelje i snovi?

Kad imam vremena, ovako ide kod mene:
1) Zahtev korisnika
- pocnemo od njihovog pisanog opisa onoga sta zele. Onda to razbijemo na nekolko delova koji postanu logicki moduli (celine) projekta. To kao nacrtamo, ako moze. Onda za svaki logicki modul izlistamo glavne objekte koje treba sagraditi (forme, subforme, liste na formama, reporte) i spomenemo kako se sta poziva

2) Poslovni proces: korisnik ovo ne trazi, ali zajedno sednemo pa nacrtamo nekakav dijagram. Probao sam USe Case i jos ponesto iz UML, uglavnom nije zadovoljavajuce. Najbolje se pokazao "cross functional chart" ili po naski "ko sta radi dijagram". Mozemo o tome detaljnije ako hocete.

3) Model baze podataka: obicno je Print Relationship Wizard iz Acsessa sasvim dovoljan. Cak ni alati tipa ERWIN i Visio ne mogu da tuku PR Wizard po brzini i potpunosti informacije. Ovo je jedini deo dokumentacije koji uvek, ali UVEK radimNa osnovu isprintanih relacija lako se dolazi do objektnog modela aplikacije - koje forme, koji reporti, koji bazni kveriji. A analizonm (citaj "gledanjem u") isprintanih relacija cesto se uoce propusti u prvoj fazi (Uzimanje Zahteva Korisnika)

4) Model Aplikacije i Objekata: obicno radim kad se stvari zakomplikuju, kad ne mogu vise da pohvatam koja foma otvara koju, koja subforma je na kojoj formi. Access verzije 2000+ donele su mogucnost visetrukog ugradjivanja datasheet formi (subdatasheets), sto strasno povecava mogucnosti korisnickog interfejsa, ali zadaje glavobolje programeru. Koristim jedan strasan stos, zasnvan na UML, i na listu papira, A4 ili A3 u teskim slucajevima, prikazem sta cini celu aplikaciju, kako su stvari povezane, ko koga poziva na klik ili 2klik. I ovo mozemo da pokazemo, ako nekoga interesuje. Ako se ovo uradi unapred, kao neki 'arhitektonski crtez aplikacije', moze se planirati potrebno vreme. Ako imate ikakvo iskustvo, mozete da pretpostavite koliko vremena treba za formu sa i bez subforme, za ovu ili onu vrstu reporta i slicno. A to pomaze kod odredjivanja cene, ako imate tu slobodu.

5) Upotstva za korisnika - uradio jednom, i nikada vise. Dan dva obuke pomaze mnogo vise, pogotovu ako je korisnik ukljucen u sve faze izrade a testiranje ide po objektima, a ne na kraju kad se sve skupi u celinu. Znaci, cim uradite frmu za prikaz podataka i pretrazivanje, testirate sami neke proste slucajeve, i odmah je date korisniku da proba. Pokazete kako se koriste Accessove ugradjene funkcije za sortiranje i filtriranje, dvogled ikonica, kako se modifikuje lokalno datasheet. Korisnik nauci nesto, a vi brzo otkrijete sta voli i sta ne voli na interfejsu, pa znate za sledeci objekat kako treba. I tako za sve celine aplikacije. Na taj naci testirate svoj sistem pre nego sto ste ga sklopili, deo po deo i ako nista, barem ste sigurni da svaki deo samostalno manje vise radi kako valja. Na kraju ih pokupite sve u jednu celinu, napravite Switchboard i eto vam aplikacije.

Prosto ko pasulj, zar ne?

Sad da cujemo iskustva, predloge i pitanja.

:-)

Evo moj mali doprinos za tacku 3
http://www.inet.ba/~mzonic/VB/

Potpis

zxz

Hvala izonicu na prilogu. Radi sa Access 97, ali ne i sa 2K+. Interesantan alat, fleksibilniji od Print relationship i pokazuje data type :-)

'Ajde da odradimo jedan primer. Evo ovako: na forumu se nekoliko puta pojavilo pitanje "Magacinsko Poslovanje". Pojavili su se i drugi primeri, ali mi se cini da je ovaj nazgodniji, barem za 'skolsku' upotrebu. Dakle, 'Magacinsko poslovanje'.

Dodje vam jednog dana prijatelj ili potencijalni klijent i kaze: "Slusaj, meni treba nesto jednostavno, nista veliko, znas, da mi vodi magacin. Ocu da znam sta je uslo, sta izaslo i koliko iam robe na lageru u svakom momentu. Jel' mozes ti to meni na brzaka, da bude prosto i da ne kosta mnogo?". To je prvi kontakt. Sta radi developer? Prvo, kreira folder na svom deveklopment PC, pod imenom Laza_Magacin. laza je ime prijatelja, a Magacin otprilike kazuje o cemu se radi. Onda u Laza_Magacin folderu otvori jedan Word dokument i nazove ga Laza_Magacin.DOC. To ce biti dnevnik dogadjaja vezanih za ovaj posao. Uglavnom ce se upisvati zahtevi i promene zahteva od strane klijenta. Prvi unos treba da ima danasnji datum i dve recenice o tome sta Laza hoce. Ne vise od dve recenice.

Onda developer zakaze satanak Lazi i pocne da postavlja pitanja. Obicno se to radi negde kod klijenta, ili moze i u kafani, zavisis kim radite. Posto nemate racunar sa sobom (a i ako imate laptop nepristojno je kuckati za vreme sastanka), kupite svesku i na njoj napisite Laza_Magacin i tu hvatajte beleske. Pitajte Lazu:
- cime se bavi njegova firma
- odakle dolazi roba koja ulazi u magacin
- da li je jedan ili vise magacina u pitanju
- gde odlazi roba iz magacina
- koji dokumanti postoje na ulazu robe a koji na izlazu robe
- uzmete kopije praznih i nekih popunjenih dokumeta
- koja roba je u pitanju, kako se mere kolicine

Ovde cemo da stanemo, to su opsta pitanja. Ajde sada neko kome treba magacnsko poslovanje da ostavi post i da bude nas Laza pa da on-line porazgovaramo o problemu. Moze i neki developer koji je radio magacin, ili treba da radi, neka se pretvara da je Laza. Ja cu samo da zadrzim pravo da modifikujem zahtev, da bi finalni produkt bio dovoljno mali da se moze zakaciti na poruke. Ne razvijamo ovde aplikaciju, samo pokazujemo kako se dokumentuje koja faza. A pokazacemo i nesto od analize i dizajna, kad to budemo dokumentovali. Ako bude interesa, mozemo i aplikaciju da razvijemo, ali za to moramo drugacije da se organizujemo. O tom potom.

:-)

Evo ja pravim jednu evidenciju za drugara, koja bi se mogla nazvati magacin. Da govorim onako laicki, postoji nekoliko entiteta:

- Dobavljaci
- Kupci
- Lager lista, i u skladu s tim
- Artikli (spisak)


S obzirom da on radi sa rashladnim uređajima i uređajima za gasno grejanje, treba mu i evidencija o radnicima, kao i "booking", kalendarski, kad je kog radnika planirao za koji teren. Mislim da ovo nije toliko bitno trenutno za magacinsku aplikaciju, tako da ćemo to sada zaobići.

Od zahteva koji su postavljeni:

- Izrada profakture
- Izrada fakture
- Klasična magacinska evidencija (koliko je robe izašlo, koliko ušlo, trenutno stanje)

Dakle, ovo je skroooooz uprošten korisnički zahtev za magacin, ali suština je tu. Ima li ko šta da doda?

Potpis

Bolje 100 godina biti milioner nego nedelju dana siromašak
(c) Alan ford

Dobro, uzecemoovaj deo:
To je sto bismo culi od gazda Laze na prvom sastanku. Posto radimo magacin, u prvoj fazi ignorisemo fakturu. Nije lose da se to zapise negde, u svesku, pa u dnevnik, tek da ne bude nevolje kad dodje vreme naplate.
lepo nama ovo Laza ponovi, ali nam ne rece u sustini nista novo - (koliko je robe izašlo, koliko ušlo, trenutno stanje)

Ajde sad gazda Lazo (Miko) odgovori nam na ova pitanja:
1) cime se bavi njegova firma " obzirom da on radi sa rashladnim uređajima i uređajima za gasno grejanje, "
2) odakle dolazi roba koja ulazi u magacin ?
3) da li je jedan ili vise magacina u pitanju ?
4) gde odlazi roba iz magacina " na teren, da se instalra kod kupca" ?
5) koji dokumanti postoje na ulazu robe a koji na izlazu robe ???
6) uzmete kopije praznih i nekih popunjenih dokumeta
7) koja roba je u pitanju, kako se mere kolicine - vidi pod 1), sve je na komad a nesto i na litar ili kg (freon, amonijak, ulje...)

Ajde molim te gazda lazo, jos ova pitnaj gde sam stavio upitnike, pa da idemo dalje.
:-)

Evo ga Laza, izvinjavam se što nisam odgovoarao jer nisam imao pristup kompjuteru.

Odgovori:

1. Firma - Bavi se instalacijom rashladnih i uređaja za gasno grejanje, dakle ima ulaz robe; na fakturi piše i spisak robe koja se fakturiše, i usluga instalacije.
2. Roba dolazi od više dobavljača koji njemu daju rabat na istu;
3. Magacin, za sada, samo jedan, mada ne bi bilo loše da se aplikacija generalizuje i za više magacina (da može više ljudi da upotrebi model aplikacije);
4. Upravo tako, roba iz magacina "odlazi" na teren, da se instalira kod kupca ili ako se kupac sam odluči na instalaciju, kupac odnosi robu (npr. klima);
5. ??? - Ovo ni meni nije baš najjasnije, za izlaz robe postoje otpremnica, profaktura i faktura, koliko ja znam, a za ulaz - prijemnica magacina, kao i (verovatno) faktura dobavljača;
6. Imam kopije
7. Uglavnom je sve na komad, ali iz istog razloga kao pod 3) treba generalizovati i na litar i na ostale jedinice.

Eto tako.

Ja trenutno razaznajem neke tabele. To su:

1. Dobavljači (Ime, adresa, telefon...)
2. Kupci (Ime, adresa, telefon)
3. Fakture (ova tabela gradi relaciju više-prema-više između gornje dve tabele)
4. Artikli (Ime, broj, jedinica mere, slika...)
5. Tabelu sa lagerom još nisam osmislio, ali ona treba da sadrži verovatno samo spisak ulaza i izlaza, pa da se stanje preračuna... mada ovo nije najsrećnije rešenje, jer ako je broj artikala 1000 (treba pretpostaviti) i broj dnevnih ulaza i izlaza npr. 100-ak, posle 2-3 godine bi trebalo sat vremena da se preračuna trenutno stanje. Opet, s druge strane, ne bi trebalo da se pamti neko stanje koje uvek može da se preračuna-Zidar, ti uvek forsiraš i ističeš da je ovo važno apsolutno se slažem s tobom!
6. Poslate profakture (ovo je lako), treba imati u evidenciji; Lakše se na osnovu njih može napraviti faktura


Eto ovo je neki preliminarni predlog, a sad cepajte sugestije!

Potpis

Bolje 100 godina biti milioner nego nedelju dana siromašak
(c) Alan ford

Zidar je bio bolestan pa nije radio u Utorak :-(
Pouka: Ako si stariji od 40 ne igraj fubal sa onima od 14.


Hvala majstor Lazi na pojasnjenjima. Ovo bih zapisao u onu svesku ili Word file:

"Forma Laza Komerc bavi se instalacijom rashladnih i grejnaih uredjaja koji rade na gas. Pri tome firma prodaje 1) opremu i 2) svoju uslugu instalacije.

Opremu kojiu ugradjuje, Laza dobija od svojih dobavljaca (ima vise dobavljaca). Dobavljaci Lazi daju rabat na prodatu opremu. Ovo znaci da Laza prodaje robu svojim klijentima po istoj ceni koju dobije od dobavljaca. Laza naplati robu, i zadrzi deo tog novca (rabat koji dobija od dobavljaca) a ostatak uplati nazad dobavljacu.

Dokmenta koja postoje u ne-kompjuterizovanom procesu su:
- Faktura dobavljaca
- Prijemnica magacina
- Profaktura za kupce
- fakture za kupce
- Izlaznica (?) iz magacina

Iz ovoga zakljucujemo da proces izgleda nekako ovako:

Kupac zeli da ugradi/promeni/poboljsa svoje hladjenje/grejanje. Kupac naziva Lazu i pita moze li to, koliko kosta i kad ce da bude gotovo. Laza ako moze, npravi profakturu i posalje kupcu, sa predlozenim rokovima instalacije. Ako nije sev jasno, Laza mora da posaklje nekoga na teren da utvrdi tacno sta klijentu treba. Ovo je kao neko projektovanje. Posle toga sledi profaktura. Ako kupac prihvati ponudjenu profakturu (=slozio se sa cenom i rokovima), onda Laza narucuje robu od dobavljaca. Roba stize u Lazin magacin, to se evidentira ulaz, a faktura dobavljaca ide u fasciklu otvorenu za ovoga kupca ili ovaj projekat. Laza pravi plan odlazaka na teren = bira datum i odredjuje radnika koji ce da obavi posao. Moze biti vise od jednog odlaska na teren, pa se u stvari odredjuje opseg datuma, od do. Po zavrsenom poslu, Laza pravi zavrsnu fakturu i salje je klijentu. Klijent plati, od jednom ili iz vise puta. Laza onda plati dobavljacu sta treba, odjednom ili iz vise puta. Moze se desiti da Laza mora da plati dobavljacu i pre nego sto dobije pare od klijenta.


Ovo pokazemo majstor Lazi i postavimo dodatna pitanja:
- da li se evidentiraju narudzbe koje Laza salje dobavljacima
- da li treba evidentirati uplate i isplate
- kako Laza naplacuje svoj rad - da li se rad pojavljuje kao zasebna stavka na fakturi za kupca ili se daje cena opreme, uvecana za neki faktor?
- kako se placaju radnici, po satu, po poslu ili imaju fiksnu platu
- ako je po satu ili po poslu, da li treba evidentirati radne sate ili poslove? (Trazen je samo Plan Odlazaka na Teren, ne i evidencija radnih sati)
- ako su radnici placeni fiksnu platu, da li se placaju prekovremeni sati i kako?

Dok cekamo odgovor, mozemo da nacrtamo kartu procesa. To je obecani dijagram "Ko sta radi". Nema veze sa bazama podataka niti sa programiranjem, ali pomaze mnogo da se shvati sta se desava i koji problem resavata. A to znanje o problemu pomaze da se napravi model podataka.

Ajde da postujem tekst, a malo kasnije cu da zakacim i sliku - dijagram

Evo da zakacimo "process chart". Prva stranica je "ko sta radi" dijagram za slucaj kad Laza prodaje i ugradjuje opremu. Drugi slucaj je cista prodaja - kupac dodje i odnese opremu pa sam instalira. Treci list je kao prvi, sa dodatim dokumentima koji postoje u procesu.

Dijagrami se prave lako, kao najobicniji dijagram toka. Jedina novost je sto se za svakog ucesnika u procesu napravi jedna "traka' i ono sta taj ucesnik radi u procesu crta se u toj traci.

Treci list dodaje jos jedan nivo informacije. Na svim akcijama gde se pojavljuju neki dokumenti, upisano je ime dokumenta.

Ceo dijagram nigde ne spominje kompjutere i baze podataka. To je jednostavno slika procesa i onoga STA se u procesu desava. KAKO se stvari desavaju u procesu, to je drugo pitanje. jedan od nacina je "sve rucno, papirima", a jedan od nacina je "sve kroz bazu podataka i neku pametnu aplikaciju". STA je vazno za shvatanje procesa, a KAKO nam kazuje sta bi nasa aplikacija trebala da ima.

Uzmimo prvi korak ,STA = "Klijent kontaktira Lazu". KAKO moze da bude na primer:
- klijent telefonira
- posalje e-mail
- dodje direktno u radnju
- loguje se na web site i tamo postavi narudzbinu
Svaka od ovih opcija moze da bude u nekoj vezi sa nasom buducom bazom podataka:
- klijent telefonira => ukucamo narudzbu u bazu
- posalje e-mail => procitamo mail i cut/paste u bazu
- dodje direktno u radnju => isto kao telefonom, ukucamo zahtev u bazu
- loguje se na web site => klijent kuca zahtev direktno u bazu, a Lazi se negde pojavi novi zahtev ili mu se automatski posalje e-mail kao upozorenje

Ovo je samo digresija, mi radimo magacinsko poslovanje.

Sto se tice magacina, najbolje za Lazu bi bilo da potpuno izbaci magacin iz igre. Umesto da placa zakup za prostor i magacionera, uz bolju koordinaciju sa dobavljacima i majstorime, roba bi mogla da ide direktno kod kupca, u zadato vreme, na zadato mesto. deo ustede od nedrzanja magacina i magacionera mogao bi da prebaci i na kupca i tako postane jeftiniji i konkurentniji, sa istim ili boljim kvalitetom usluge.

Naravno to necemo da mu kazemo, on nas placa da mu uradimo aplikaciju za magacinsko poslovanje.

Sutra ili prekosutra cemo da na osnovu dijagrama procesa sastavimo idejni model baze podataka.

:-)

1. Evidentiraju se narudžbe koje Laza šalje dobavljačima, da ne bude posle "e pa ti mi nisi poslao narudžbu", ili "poslao sam ti narudžbu, a ti mi ne ispostavljaš robu"
2. Evidentiranje uplata i isplata-mislim da je to više posao knjigovodstva i mislim da je to modul koji lako može da se dogradi (za vežbu npr.)
3. Laza naplaćuje svoj rad kao posebnu stavku u fakturi (instaliranje klime, grejnih tela itd.)
4. Radnici se plaćaju bilo po satu, bilo po poslu, bilo da imaju fiksnu platu - sve mogućnosti su u opticaju, mada ne znam zašto je to bitno kad smo rekli da u prvoj fazi nećemo evidentirati radnike ???
5. Po meni treba evidentirati i radne sate i poslove, nevezano za radnike već radi praćenja procesa i neke kasnije statistike (radni sati/kvadratnom metru prostora)
6. Vidi pod 4.

Takođe, bitna je i evidencija profaktura koje su poslate, čisto radi pregleda.

S obzirom da mi se dopada Zidarev metod izrade i predstavljanja proizvodnog procesa, imam pitanje- kako se zove ta metodologija? I naravno, u kojoj knjizi je opisana? Jedino što znam da nije UML.

Pozdrav!

Potpis

Bolje 100 godina biti milioner nego nedelju dana siromašak
(c) Alan ford

Malo o cross functional charts poznati i kao
- UML swim lane diagrams:
- deployment charts
- who does what charts

http://www.agilemodeling.com/s...ctivityDiagram.htm#_Toc6310263

http://www.hci.com.au/hcisite2/toolkit/flowchar.htm

http://philosophy.hku.hk/think/strategy/chart.php#a

http://www.oreilly.com/catalog/learnuml/chapter/ch08.pdf

http://www.blm.gov/ba/bpr/swimlane.htm

http://courses.washington.edu/ebus/pdf/ProcessMapIntro.pdf

http://www.dbpd.com/vault/9806arc.htm

http://www.cp.berkeley.edu/CPI...h_Cross_Functional_Aug2004.pdf

http://www.drma-seattle.org/200202-pdf.pdf

http://www.cs.uwlax.edu/~zheng/CS546Summer05/notes8a.ppt#14

Yeah, hvala na odgovoru puno!!!

Sorry, mislio sam da tvoj predlog nema mnogo sličnosti sa UML-om ali očigledno da sam pogrešio.

Potpis

Bolje 100 godina biti milioner nego nedelju dana siromašak
(c) Alan ford

Miko, ti si u pravu. Tu se svaka veza sa UML zavrsava. U UML se flowcharting ne potencira bas mnogo, mada u praksi osim Use Case jedino sto se koristi na veliko jesu Action Diagrams (klascini flow chart) i Swim lane diagrams (modifikovani obican flow chart). Use Case lepo izgleda ali nije previse koristan, Class diagrams se mnogo lakse razumeju ako se kaze da je to shema baze podataka.

U sustini, relacione baze podataka su u mnogo cemu u koliziji sa object oriented filozfijom. Ovo nisam izmislio ja nego izvesni C.J. Date, kolega covenog dase po imenu Codd. Date pise SQL standard, a Codd je izmislio relacionu teoriju. Nemam nista protiv OO koncepta, i molim da se ova diskusija ne pretvori u raspravu o OO i Rel. teoriji. Razlike u razmisljanju postoje a lepo je to objasnio jedan nas kolega, na forumu MS SQL https://www.elitesecurity.org/t110819, pogledajte post koji je ostavio MilovanB.

Xeex, znači bio sam ipak (malo) u pravu. OK.

Dakle, šta je sa Čika Lazom i njegovom firmom? Ja imam jedan model baze u glavi i hteo sam da ga implementiram, ali da budem iskren ovo što si ti ostavio je mnogo jasniji i racionalniji model, sa više mogućnosti za proširenje, tako da ću ipak da sačekam tvoj predlog. Gorim od želje da vidim specifikaciju tabela, ili bar njihovu naznaku, smernice itd. Posle toga ćemo napraviti gotov primer i okačiti ga ovde, slažete se?

Pozdrav!

Potpis

Bolje 100 godina biti milioner nego nedelju dana siromašak
(c) Alan ford

OK, vracamo se Lazi i njegovoj firmi za Ledene radnje. Jos uvek nemamo dizajn baze, u ovom momentu mozemo da napravimo neki kao 'idejni model baze'. siguran sam da vecina ima ideju, pa necu mnogo da ulazim u 'zasto'. Svrha crtanja modela baze u ovom momentu nije da nam tacno pokaze polja i tipove podataka. Nesto drugo je u pitanju, a to je pokrivanje modela podataka objektima aplikacije - reportima i formama

Prilozena shema ugrubo prikazuje koje nam sve tabele trebaju da pokrijemo poslovni proces.Ako se bolje pogleda, vidi se da shema nije idealna, moze se poboljsati, ali to nije cilj u ovom momentu. Cilj je ideja, i to slika ideje koja se moze nekome pokazati, da razume o cemu se radi. Ne pokazuje se gazda Lazi, on nece razumeti, niti ga je briga. Pokazuje se mozda kolegi developeru, a najcesce se koristi u sprezi sa dijagramom "ko sta radi", sa crtezom na kome se vide dokumenti u procesu.

Pogledajte model podataka i istovremeno pogledajte process chart. Onda postavite sebi pitanja:
- Da li su svi dokumenti sa process charat pokriveni nekim tabelama?
- Ima li tabela koje ne dolaze iz procesa? Zasto? Cemu bi one sluzile?
- Znaci li to da process chart nije kompletan (verovatno znaci)

I jedan i drugi dokument predstavljaju model procesa, prikazan na drugi nacin, pa se moraju na neki nacin i slagati.

Ako ste zadovoljni stepenom slaganja procesa i modela poadataka, onda se tabelama mogu pridruziti vidljivi objekti aplikacije - forme i reporti. Uocite na modelu podataka da na nekim tabelama pise F,DS ili slicno. F znaci 'za ovu tabelu napravicu formu u Form obliku'. DS znaci "za ovu tabelu treba mi Data Sheet forma".

Ja nisam stavio reporte, ali mozete ih dodati na dijagram. Na primer, na tabeli roba, vidm barem dva reporta:
1) Kartica Robe (Roba i sve promene ulazi/izlazi)
2) Stanje - lista artikala, i pise trenutno stanje

Za fakture, profakture, prijemnicu robe, otpremnicu, narudzbenice, svuda nam treba po jedan report koji ce nam dati odstampane kopije dokumenta. Upisite slovo R i u dve reci opis reporta i eto vam dokumentacije.

Ako prebrojite forme i reporte, imacete ideju koliko vam vremena treba da se to napravi. Ja obicno racunam 3 sata po formi i sat-dva po reportu.
Potrebno vreme = (broj formi * 3 + broj reporta*2)
Pa onda sve to pomnozim sa dva. Faktor 2 pokriva testiranje, ispravke u dizajnu, sve cega se setimo kasnije i slicno.

Broj sati puta satnica = cena projekta. S tim idemo kod Laze i kazemo "Burazeru, to ce da bude otprilike ovoliko" Ako ga ne strefi kap momentalno, idemo dalje. Ako covek dobije infarkt od cene, proverite da li je udovica mlada, pa probajte da je tesite.

Ako iskoristimo cinjenicu da su mnogi reporti i forme jako slicni, ako nista imacemo bar iste kverije za njih, a verovatno mozemo da dosta od dizajna kopiramo iz objekta u objekat. (Object inheritance :-)

Recimo da je Laza preziveo (nista od mlade udovice) i sad treba da se radi. U sledecoj fazi napravimo finalan dizajn baze. I razmislimo o formama i reportima koji su jako slicni. I onda pravimo ono sto bi se u gradjevinarstvu zvalo "Glavni Projekat Aplikacije".

To sutra ili sledece nedelje.

:-)

Ovo je kriticna faza projekta, Mi mislimo da znamo dovoljno o problemu koji resavamo za Lazu i verujemo, a i Laza sa nama, da ono sto njemu treba jeste sistem koji ce zameniti papirnu evidenciju ulaza i izlaza robe iz magacina. Zivot bi bio lak kad bi stvari bile tako jednostavne.

Proucavajuci dijagrame procesa (ej, dijagrame, ne dijagram, ima ih dva) shvatamo da se ovde radi o dve vrsta poslovanja:
- prodaja uredjaja sa instalacijom
- maloprodaja urdjaja i delova kupcima direktno, bez instalacije

Ako malo dalje procackamo, saznamo od Laze da:
- roba ne ide uvek u magacin, nekada dodje u radnju (znaci baska je radnja a baska magacin) pa je odatle ili preuzme kupac,
- roba dodje u radnju ili magacin, pa je majstori ponesu na mesto ugradnje
- kupac prima robu od odbavljaca direktno, a majstor odlaze samo da je instaliraju

Zamislite da se dobavljac nalazi u Zemunu. Lazina radnja i magacin su na Zvezdari. A kupac je na Novom Beogradu. Ima li smisla da roba putuje iz Zemuna na Zvezdaru da bi je mastoru vozoli na Novi Beograd. Za one iz Bosne, dobavljac je na Bas Carsiji, kupac na Marijin Dvoru a Lazina radnja na Ilidzi.

I zamislite kupca koji nije n Novom beogradu niti na Marijin Dvoru, nego recimo u Tuzli. i kupio prosle godine klima urdjaj, a sad mu crkla neka sijalica, ili mu treba freon. beograd mu inostranstvo, a Sarajevo daleko. sta ce jadan, naruci deo postom i ceka.

Da li nas model pokriva sve ovo? naravno da ne, ovo je samo da vas podstakne da razmisljate.

U ovom momentu moze da se desi da se vratite na pocetak i potpuno preradite lazin zahtev. A moze se desiti da se dodaju neki novi zahtevi (koji ce dodatno biti placeni). To sve upisite u vas dnevnik. Eto vam dokumentacije.

Ajde da se vratimo data modelu. Moguce su razlicite opcije. Na zakacenoj slici, opcija A) je veoma generalizovana slika. to je us stvari recenica "Laza prodaje kupcima robu koju dobija od dobavljaca". Opcija B) dodaj malo stvarnosti, uvodjenjem dokumentaka koji nose informaciju. I pretpostavimo da imamo zasebne tabele za:
- fakture od dobavljaca (koje ce Laza da plati),
- fakture za kupca (koje ce Laza da naplati)
- izdatnice iz magacina, koje radnici dobiju i potpisu da su robu uzeli, kad krenu na nstalaciju
- Prijemnca za magacin. kreira je magacioner kad prima robu

Uocavamo da sve nabrojane kombinacije imaju glavni dokument i stavke na dokumentu kojedolaze iz tabele Roba. Razlikuje se samo naziv dokumanta i vlasnik dokumanta. Sve ostalo je manje vise isto . Ovo se naziva "data model pattern" ili po naski "sablon". Da li to znaci da sve ove slucajeve treba strpati u jedan, tako sto dodamo naziv dokumenta u tabelu Dokumenti? To pokazuje slucaj C na prilozenoj slici. Objediniti ili ostaviti zasebno, pitanje je sad. Odgovor - moz da bidne ne mora da znaci. Razlog: rekli smo da je u svim slucajevima struktura manje vise ista. Uticaj i znacaj tog manje vise odredice finalnu strukturu modela podataka. Kakav god model da se usvoji, nacrtajte ga i upotrebite za pravljenje liste objekata aplikacije (forme i reporti).

Da se podetimo, ovo je tema o dokumentovanju, a ne o data modelima. Znaci, mogu delovi modela da izgledaju i nekako ovako (vidi attachment)

Ako gledamo samo data modele, jedan odličan link sa mnooogo primera modela nalazi se na:

http://www.databaseanswers.org/data_models/index.htm

(Mislim da sam to ovde na forumu pokupio, ali nije zgoreg podsetiti se).

Takođe i:

www.datamodel.org

Vratimo se na dokumentovanje rada. Konkretno, model podataka je objašnjen skoro u potpunosti (10x to Zidar), ali šta je sa modelom interfejsa? Npr. razvija se neka FE-BE aplikacija koja ima 100-ak tabela, 50-ak formi sa isto toliko podformi, komplikovana je veza forma-podforma, postoje prečice i dugmad kojima se određene forme startuju/gase, takođe postoje dugmad kojima se pokreću akcioni kveriji, VBA kod za povezivanje sa drugim aplikacijama... Interesuje me, ima li smisla praviti (i održavati) dokumentaciju koja se bavi interfejsom? Da li to vredi samo programeru koji je pravio dokumentaciju (da se lakše snađe; ali, s druge strane, on manje-više zna gde je šta pravio i postavljao-osim ako ne ode na 6-mesečni odmor ) ; ili je takva dokumentacija, ako se pravilno održava, dovoljna nekom novom programeru u timu da za par dana skonta kako i šta aplikacija radi?

Da li tu UML stupa na scenu i neizbežan je ili je dovoljan i neki meta-jezik? Npr. ja sam se oduševio Zidarevim dijagramom toka koji je nedvosmislen i mislim da ću ga usvojiti prilikom izrade novih aplikacija. Da li takav dijagram toka vredi i za forme i događaje u aplikacionom FrontEnd-u?

Pozdrav! Mnogo pitanja, nadam se ne mnogo teških.

Potpis

Bolje 100 godina biti milioner nego nedelju dana siromašak
(c) Alan ford

Zahvaljujem na intersovanju. Slika vredi 1K reci, pa evo slika, bez teksta, a zove se Dijagram Aplikacije. Ekvivalent u gradjevinarstvu: Arhitektonski plan, osnova 1:200

:-)

Evo jos jedna slika, lako se crta, a veoma je korisna - Deployment Diagram. Ekvivalent u gradjevinarstvu - geodetski plan, situacija 1:2500.

Sto se tice Mikinih pitanja sta ima smisla dokumantovati, odgovor je -sve sto mislis da ce ti trebati i pomoci da manje radis a vise postignes. Za interfejs je dobro posatviti standarde (font, velicna, rasapored polja, caption) i neke templates na pocetku rada, isto i za reporte, pa koriscenjem 'naming conventions' neke stvari busu samodokumentujuce.

Primetite da nigde nisam ni spomenuo (a i neceu) dokumentovanje koda, kao "odstampaj listing programskog koda". nepotrebno, jer to niko ne cita, svako otvori kod idrektno pa gleda. Dokumentovati i komentaristai unutar modula sa kodom, e to je drugo. Onoliko koliko vam treba.

Jos cu da postavim primer kako se dokumentuju kveriji, lako je i veoma korisno, cesto se radi i ad hoc, makar se i ne cuvalo u dokumentaciji. To sutra, dosta je za danas.


:-)

Hmmm, ovde je MNOGO korisnih informacija, ja sam spremam da ih sve uobličim u jedno omanje uputstvo u PDF-formatu, koje se tiče dokumentovanja aplikacije; Takođe, u jednom od TOP topica je pomenuto i standardizovano pisanje variabli (dakle, klasična forma po Microsoftu), tako da bih i to ubacio; mislim da bi ovo svima bilo korisno, da im bude standard za svaku novu aplikaciju;

Mislim da je koristan i deo oko intervjuisanja korisnika, za dokumentovanje aplikacije:ako pravilno "prevedete" njegove potrebe za izradom informacionog sistema, analizirate SVA dokumenta koja su potrebna za unos/izveštavanje onda štedite sebi vreme jer ćete možda imati i nekoliko intervjua na kojima će se uglavnom ponavljati korisnički zahtevi. U praksi se dobro pokazalo i snimanje intervjua diktafonom, za ozbiljnije i duže razgovore.

Zidar, primećujem da si koristio neku aplikaciju za izradu ovih dijagrama, ili je to samo neki template?

Pozdrav!

Potpis

Bolje 100 godina biti milioner nego nedelju dana siromašak
(c) Alan ford

:-)

Koristim Visio za crtanje, ali moze bilo sta, PowerPoint na primer. Nisu vazni ni simboli, mozete da upotrebite bilo sta, uz uslov da uz crtez ide legenda. Ja koristim nesto sto koliko toliko lici na UML simbole (koji su sve samo ne standardni i univerzalni). Bitno je da se prikaze koji objekt je deo drugog objekta (forma/subforma, subdatasheets na vise nivoa, dugmad na formi) i vaznije akcije (klik na ovo, dblclick na ono) i sta se desava posle tih akcija. Ograniceni ste samo velicinom papira i mastom. U mojoj praksi, ovi dijagrami koriste uglavnom meni. Na komplikovanim formama sa mnogo tabova , subformi i slicno, tesko je pratiti sta odakle dolazi i sta se kako zove. Zato nacrtam dijagrame i ne lutam. Ako dovoljno ljudi nauci da pravi i cita ove dijagrame aplikacije, mozda se i izrodi neki standard za dokumentovanje i prenosenje informacija sa jedne karike na drugu u lancu razvoja sistema. Na primer, glavni inzinjer aplikacije napravi nekoliko ovakvih dijgrama i onda junior progrmeri na osnovu "planova i crteza" razradjuju aplikaciju. Uz standarizovane naming conventions i standardizovan nacin pisanja nekih cesto ponavljanih kodova moze se znatno ubrzati rad i smanjiti broj gresaka koje treba popraviti kasnije. Tu vec dolazimo do problma organizovanja vece grupe programera.(Definicija vece grupe: N>1, N je broj programera na projektu).

:-)