Pa ta znanja umeju da budu korisna, ali su kod domaćih fakulteta vrlo retko u pitanju stvarna znanja, više nabubani skup nepovezanih a često i besmislenih rečenica.

Evo jednog citata kao ilustracije:

Sve zavisi od tebe. Skola te nauci neku teoriju da se kasnije lakse snadjes. Ucis sta je sta ali ne na pravim primerima iz prakse. To ces kasnije videti. Ako znas teoriju lakse ti je da prihvatis nacin rada, da se uklapas u tim i slicno. Ali ako ces da se bavis informatikom to sto naucis shvati kao pocetak jer se mnoge stvari menjaju pa ces morati da pratis i ucis nove stvari.

Moram priznati da se kao student pitao sto ucimo neke stvari. Neke mi zaista nikad nisu trebale, neke posle kraceg ili duzeg vremena.

Ako ces dalje da se bavis naucnim radom trebace ti teorija.

Mislim da je Jablan pogodio temu i jednim citatom opisao ceo nas IT univerzitetski svet :)


Najveci problem je bas ta teorija sto nijedan profan ne moze (ili nece) da ti objasni gde je to stvarno primenjivo. Nedaj boze da sam se raspitivo o modelu vodopada slucajno dobio bih odgovor da je to "..model SDLC-a koji omogucava razvijanje aplikacije bez iterativnih koraka, i kad se dodje u fazu testiranja nema nazad!!!", a inace kako se pristupa analizi tih koraka sutra malo da dobijem.

Sticajem okolnosti vezbe iz nekih predmeta su nam drzali inzenjeri koji rade u jednoj vecoj softwerskoj firmi (programeri), i ne znam dal je to slucaj sa svim programerima (ne znam ih mnogo) nekako se ponasaju "misteriozno". Recimo ako ja pocnem da se raspitujem (a to me najvise zanima) kako izgleda jedan projekat, izrada neke aplikacije, svi se prave mutavi i elegantno me iskasiraju.
Primer: Sta radi vodja tima? Odgovor: Upravlja projektom, pocelo predavanje!
Ne znam mozda ja postavljam nebulozno pitanje, znam da to nekad radim :) ali nije mi bas svako pitanje nebulozno.
Iskoristicu malo da zloupotrebim svoju temu, ali moze li neko (ili je to neka vecita tajna :) ) da mi opise kad se dobije nalog za izradu nekog projekta kako tim koji treba da ga realizuje pristupa tome, sta rade, sta se radi pre, a sta posle, kako uopste tece razvoj aplikacije?

Valerij Zajcev vidi ovako:

1. napravimo model (UML)
2. modeliramo bazu
3. dobijemo nalog sa izmenama
4. unesemo izmene u model
5. kodiranje
6. shvatimo da imamo problem jer npr. palm racunari koje poslodavac/nalogodavac
koje je on nabavio imaju samo 64 MB Rama

7. krpimo kako znamo i umemo da bi stvar proradila

8. opet izmene

9. opet krpimo, dodajemo "helper" klase

10. postavimo u produkciju

//održavanje

while(!(nekoJeOdustao || nemaVisePotrebeZaTimStoSmoNapravili))
{
poslodavac/nalogodavac opet nešto menja
opet krpimo kako znamo
}

Hvala ti, Jablane, baš sam ovaj citat tražio umesto kanoničnog lorem ipsum za za jedan sajt. Bio sam zaboravio beše li "...putem koje je moguće..." ili "...putem kojih je moguće...". Zato sam stalno i padao Osnove organizacije.

Šta nam uradi Živko :)

Naravno da je to sto na faxu ucis jako korisno... sto se mozda tebi sada tako ne cini jer su to samo djelici koje ti treba da slozis. I ono sto ti profesor primjera radi kaze na predavanjima iz UML-a, nemoguce je bash odmah u potpunosti shvatiti i povezati dok ne dobijes projekat da odradis i da onda taj UML stavis u stvarnu upotrebu.

sstanko78 ti je fino objasnio kako to izgleda u praksi. samo bi ja to dopunio:
1.a. razgovor sa klijentom njegove potrebe i zahtjevi + uslovi u kojima treba da radi program(platforma, hardware...)
1. napravimo model (UML)
2. modeliramo bazu
3. dobijemo nalog sa izmenama
4. unesemo izmene u model
4.b. ponovni razgovor sa klijentom da se utvrdi da li je to ono sto je on trazio
4.c. izmjene
5. kodiranje
6. shvatimo da imamo problem jer npr. palm racunari koje poslodavac/nalogodavac
koje je on nabavio imaju samo 64 MB Rama ovaj korak moze da se izbjegne ali u 90% slucajeva je tu :S

7. krpimo kako znamo i umemo da bi stvar proradila
8.a. razgovor sa klijentom
8. opet izmene
9.a. testiranje User Interface dizajna i cijelog programa
9. opet krpimo, dodajemo "helper" klase

10. postavimo u produkciju

i sa mojim dodacima ima tu josh mnogo tacaka od kojih se mnoge izvrsavaju paralelno ali ugrubo je to to.

Fale i koraci da je neko drugi razvio sistem za klijenta A na koji se ti kalemiš, npr. bazu i Axapt-u, taj ko je to radio neće da ti preda dokumentciju a sve konsultacije koje od klijenta A naplaćuje papreno se teško zakazuju. A imaš i nadriiformatičare kod klijenta A koji su tu da ti postave debilne tabele u bazi, da ti postave debilne uslove koje tvoj softver mora da ispuni, da kad nešto što zahtevaju i ti uradiš naprasno stopiraju i još naprasnije se sete posle par meseci da to ipak treba da se pusti (da ne pominjem da tak kod više nije ispravan jer je milion izmena urađeno u međuvremenu i da si ti zaboravio šta si uopšte pisao), pa da ti zadaju zadatak a onda da se sete kako to ipak treba drugačije...

@Au197/79

Zaboravio si i da postoje razni servisi i serveri (koji nisu database), čiji API-ji ne rade kako
treba i slične zanimacije

predavanja iz UML-a? UML nije nuklearna fizika, naprotiv toliko je jednostavan (ako su ispunejni uslovi*) da se svi tipovi dijagrama mogu objasniti na konkretnim primerima za najvise 3h

*znanje OOP, osnova projektovanja, dodati po zelji

Greska u projektovanju cije ispravljanje kosta 1euro dok je josh u fazi projektovanja u fazi kodiranja kosta 100eura. sto samo govori koliko je modeliranje bitno u projektovanju nekog systema/aplikacije....... i koliko fatalne mogu da budu izmjene u fazi kodiranja, kao sto je Au197/79 rekao.

Osim ako i modeliranje ne vršite u nekom programskom jeziku. ;)

ironija?

I da i ne.

http://www.paulgraham.com/icad.html
http://memeagora.blogspot.com/...esign-patterns-in-dynamic.html
Google: "design patterns dynamic languages"

itsl.

nismo se bash razumjeli ali nema veze.

Da se odmah razumemo, slazem se sa fundamentalnom osnovom ove tvdnje da je post-design promena skuplja, ali 1:100?? Odakle si uopste dobio ovu cifru? Cak i ako iznivelisemo cenu rada svih ljudi na projektu, to bi znacilo da je za jednom satu projektovanja odgovarajuce 100 sati korektivnog kodiranja, to je veoma nerelano.

Pre nekoliko godina, radeći kao deo tima na RistanCASE DAC projektu, imali smo predočene neke analize iz vodećih automobilskih kompanija (inače, kupce tog proizvoda) baš u vezi koštanja u startu neadekvatno projektovanog a realizovanog podsistema. Nemam napismeno te podatke, ali sećam se da su pominjane brojke od 1:5 (kao minimum), 1:50 do 1:100 i više !

Kod automobila smo već čili da su fabrike na milion automobila često za DŽ menjali neki banalan deo koji kao ugrožava sigurnost. Nema ništa lakše nego reći korisnicima da kupe novi auto ili da o svom trošku odu kod majstora. To se ipak ne događa često kod velikih firmi, a jasno je i zašto.

Iako ovo deluje kao poređenje baba i žaba (u odnosu na softver), može se povući barem donekle slična paralela, pogotovo u specifičnim projektima kao što je DAC.

Ukratko, kod softvera problem je bio u očuvanju kompatibilnosti unazad, i siguran sam da svako za sebe može da nađe neki primer. (Da li je to struktura baze ili nešto sasvim treće)

Neću navoditi primere kod DAC projekta, jer ih ima previše, ali znam dobro o čemu pričam jer sam radio na popravljanju. Problemi mogu biti toliko banalni a veliki, koliko je banalno menjanje veličine nekog Buffera. Zapravo, nema ništa lakše nego ispraviti grešku u nekom podsistemu, jer su se zahtevi i potrebe vremenom iskristalisalale. Problem je što se tim skraćenim činom 'odeseče' značajan broj klijenata, koji zbog izlaganja dodatnim troškovima i nepoverenju napuštaju proizvod. Da bi se to sprečilo, pristupa se izradi špageti koda koji zaista jeste težak i skup za održavanje.

Mogu samo da zamislim koliko je M$ uložio truda da se očuva kompatibilnost prelaskom na Vistu.

P.S.
Da ne bude zabune. Ovime ja ne kažem da se greške ne bi događale da su se koristili alati za projektovanje informacionih sistema. Naprotiv, ako u glavi nije prethodno raščišćena situacija, sva je prilika da će i UML biti isto takav.

Mislim da je vazan faktor u tom odnosu metoda projektovanja. Recimo da je odnos 1:100 realan za waterfall metod gdje se sve projektuje / pishe / dokumentuje i onda pocinje raditi po tim instrukcijama. Cijena korekcije se exponencijalno povecava kako razvoj odmiche.
Takodje taj odnos je dosta manji u agilnim metodama vodjenja projekta.

Dobro je da sam dobio podrsku inace sam vec mislio da napustim temu :)

@misk0
Na takav jedan projekat sam mislio.

Ne pricamo o projektu POS kase ili webshopa vec o vecem projektu u kojem ucestvuje nekoliko programerskih timova svaki zaduzen za odredjeni dio posla. E sad zamisli scenu kad je projekat vec pri kraju 80%+ koda gotovo i dodje ti izmjena na bazi podataka u glavnoj tabeli i ti treba svakom timu da kazes da to promjeni a ta promjena se vuce kroz cijeli projekat. Treba taj kod ponovo prouciti prepraviti naravno dolaze tu i komplikacije koje ne treba zaboraviti. Naravno onda krece i komunikacija izmedju timova tu se isto gubi vrijeme, cekanja... probijanje rokova. U tom slucaju odnos je i veci od 1:100 naravno takve stvari se rijetko desavaju zato i sluzi projekat dokumentacija, ali se desavaju.

Prije godinu dana sam pricao sa kolegom sa faxa, zavrsna godina. Radi u IBM na projektu koji je procjenjen na 4 godine rada. Dok sam ja sa njim pricao rok je probijen za 2 godine + sto je jedan kompletan tim od 20 programera napustio tim, nezadovoljni projektom i pritiskom zbog stalnih izmjena i kasnjenja. Na kraju je navnodno usla i opcija kupovine takvog software zajedno sa cijelom firmom iz njemacke koja je takav posao vec odradila uz izmjene koje bi bile potrebne da zadovolje klijenta. Sta dalje reci...

ako je ovo tacno, onda je ceo taj projekat vodio neko ko nije inzenjer
postoji neko nepisano inzenjersko pravilo: zasto praviti nesto sto vec postoji?