Funkcionalna specifikacija

[LiquidBrain]

Kreni od pocetka... prvo isprojektujte bazu... Dakle stavish na papir sve sta ti je potrebno da to radi, ostavish mogucnost da kasnije dodajesh dinamicki module, i krenesh sa projektovanjem baze...

Kada imash svu potrebnu logiku za samu bazu, ostatak nece biti problem...

[jablan]

Mislim da je ključna reč http://en.wikipedia.org/wiki/Software_prototyping

Savetujem takođe da funkcionalne specifikacije odrađujete pojedinačno, po nekim modulima ili kako je već organizovan program, i da se trudite da budu što kraće, do par stranica po funkcionalnosti (naravno, dovoljno opširne da prođu approval od strane inžinjera).

Originalno napisao LiquidBrain

Kreni od pocetka... prvo isprojektujte bazu...

Projektovanje baze je daleeko od početka.

[misk0]

Tebi zapravo treba Project Management a imas srecu jer ja to upravo ucim )
Na pocetku skupljas sve moguce i nemoguce informacije do kojih mozes da dodjes i dok ih skupljas - organizujes ih u neke tebi logicne cjeline (interfejs, brzina, broj klijenata, komunikacija, itd).
Pokusacu ukratko da ti iznesem neke smjernice pa mozda ti pomogne. Ako sta bude nejasno - pitas.. Ja cu ti napisati par koraka (uprostiti koliko budem mogao) a ti ces uzeti sta mislis da ti treba.

1. Project charter - dokument koji ukratko opisuje sta je krajnji proizvod, zelje i zahtjeve klijenta.
2. Assumptions & Constraints - znaci stvari koje znas i ne znas (ali podrazumjevas ih) u tom momentu. Tu moze ici recimo razvojna platforma, alati, verzije kao i milestones.
3. Scope - tu opisujes detaljno sta treba biti odradjeno, kako treba da izgleda, koji su dijelovi, karakteristike, mogucnosti i slicno. Jedan od dijelova Scope-a je i WBS - Work Breakdown Structure. To je dijagram koji pocinje od najkrupnijih cijelina i sitni se do nivoa na kom je moguce procjeniti vrijeme i potrebne resurse za rad. Na osnovu WBS-a ti i tvoja ekipa imate cistiju ideju sta treba biti uradjeno, kome pripada i slicno, kao i novi ljudi koji dodju i ukljuce se u projekat kasnije.
4. Schedule - tu uzmes sve pakete na koje si razbio gore aplikaciju i odredis im koja zavisi od koje (ne mozes praviti upis u bazu ako je nisi prethodno napravio) kao i koliko koja traje. Kad imas te info, onda napravis GANT dijagram koji ti pokazuje koji dio ide prije koga, koliko traje i slicno. Na to naravno mozes nasloniti i resurse tako da se zna tacno koji paket radi koji programer i kad.
5. Cost - nisi naznacio kako ide placanje pa ti ne mogu reci
6. Communication - ovde mozes definisati ko ce kome sta i kad javljati, kako komunikacija izmedju clanova tima tako i izvjestaji o razvoju i napredovanju projekta prema klijentu. Takodje mozes planirati sastanke i okupljanja.
7. Quality - testiranje i uskladjenost funkcionalnosti paketa sa specifikacijama.

To je otprilike to - za pocetak. Naravno, vecina tih dokumenata je podlozna izmjenama tako da trebas imati neki tracking soft kojim ces moci (moras zbog ostalih) evidentirati datume, razloge i vrste izmjena. Ovo je jako vazno - da sve izmjene (specifikacije, organizacija posla, odgovornost...) pishes da svi koji dodju poslije - mogu da skontaju pravac i tok razvoja.
Izostavio sam HR, Risk i Procurment management jer mislim da te manje interesuju za sad.

[_korso_]

Hvala puno svima na odgovorima. Mislim da mi daju dobru smernicu za pocetak i za dalji ulazak u problematiku. Ukoliko dodjem do nekih jos interesantnih stvari, sigurno cu napisati