Funkcionalna specifikacija

[_korso_]

Gledao sam malo po forumu ali nisam nasao nista sto bi mi koristilo u vecoj meri, osim mozda najstarije poruke na ovom forumu :-)
Pa sada, imam jedno pitanje manje-vise teoretsko-prakitcno,vezano za projektovanje i pisanje funkcionalne specifikacije aplikacije.

Treba da se radi na nekom velikom projektu.Na istom ce raditi troje ljudi. Vremenom
ce se mozda ukljuciti jos par njih, mada nije potpuno sigurno. Sve se radi from
scratch.
Neko optimalno vreme izrade je 8-9 meseci. Prva verzija, neka bude beta, se moze ocekivati,
za 5-6 meseci.
Ovo navodim, da bi se pribliznije shvatio obim posla.

Poznavanje problematike kojom ce se baviti aplikacija,
za sva tri coveka je relativno mala(u procentima, ako se moze tako iskazati je 20%).
E sada, prvo ce se prikupljati informacije jedno mesec dana, itd...(sto ne iskljucuje dalje dopunjivanje istima ). Planirati neke stvari koje se mogu planirati.
Kako je i obim i problematika posla, ne bas svakodnevna (sistem ce imati da kazem "module")
koji se inace i nalaze u Ecommerce-u, CRM-u, B2B-u i tako dalje, treba pazljivo prouciti sve aspekte, sve cinioce...

Sta je problem?

Kako posle prikupljenih informacija, naci pravu "meru", pa na osnovu toga napisati funkcionalnu specifikaciju sa raznim flow dijagramima, UML ili sta vec. (Nije lako ni kada radis na nekom slicnom projektu koji si vec radio).
Treba napisati nesto sto ce i kasnije ljudima koji se budu ukljucili u pricu, koristiti da sto pre pohvataju neke smernice, ali takodje i ljudima koji rade od pocetka da lakse stvore neku sliku u glavi.
Verovatno se je neko sretao sa ovakvim projektima.
Odakle poceti(osim prikupljanja informacija), da li imate neki savet, smernicu?
Nasao sam neke primere i template funk. spec. Vidim da neke imaju i po par stotina stranica.
I da dosta sistematizovano imaju izdeljene delove i celine.

Unapred hvala

[nixa]

Specifikacija moze da se napise prilicno na cemu hoces.

Zavisnosti na cemu radis treba da odvojis par dela.

Ja sam licno radio samo na kompleksnijim resenjima u web.dev-u , tako da cu da se ogradim od desktop sveta.

Ono sto prvo treba da se odvoji je logika i view.

Ja licno pristupam prvobitno resenju da u wireframe iskazem ponasanje aplikacije. Tu recimo Visio se lepo ponasa sa interface stencile.

Tu se recimo moze da razbije na par milestone, po samom interfejsu ili recimo na neke verzije ... ta i ta funcija se dodaje u tom i tom mileston-u, tj reviziji ili sta god.

Hipoteticki receno da imas sve vec reseno u wireframe/funcionalnst pregledu ide tezi deo kako ce to da radi .

Ja licno koristim wiki za to, ali uglavnom neko ko je glavni inzinjer sistema mora da pise taj deo oko funcionalnosti.

Tu se recimo razdvoji svaka stavka na zaseban item u wikiju i onda se elaborira kako ce da to radi interakciju sa core sistemom, framework-om ili kako vec ...

Uglavnom, pitanje je prilicno genericko da ima neki ultimativni odgovor :)

[_korso_]

Slazem se da je genericko, ali upravo i trazim bilo kakve smernice. Da imam
odakle da podjem. Naravno da je tesko dati odgovor tipa, to, to i to uradis.
Zaboravio sam da napomenem da je web aplikacija u pitanju, ako ima uopste neke veze.

[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).
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

[majstors]

Velika je istina da ovde ne postoji recept, te da skoro svaka firma (od Majlaba do Microsofta) ima svoj metod.

Evo još par hintova:

Mora se znati šta je realna namena specifikacije, to u mnogome diktira i formu i sadržaj.

Glupo je praviti specifikaciju ako ona neće imati namenu - specifikaciju radi nje same: glupo i skupo.

Postoji model razmišljanja koji može pomoći kod sadržaja spcifikacije. Po tom modelu u jednom uglu su korisnici, u drugom sadržaji, u trećem funkcije. Funkcionalna specifikacija treba da postavi relacije između ta tri ugla. "Atomi" funkcionalne specifikacije su rečenice čija je struktura SUBJEKAT (korisnik) PREDIKAT (funkcija) OBJEKAT (sadržaj).

U kontekstu specifikacije za web sajtove... pogledaj:
http://tribune.majlab.com/povedanje/stevino-pravilo-firma-koja-imace-kvalitetno-on-line-prisustvo/

Ima tu još "know how" hintova... i PPT prezentacija.

[kodi]

burdown chart moze da bude od velike pomoci, cak i ako se ne fura agile...
znaci podelis neki posao u neke jedinice. mozes ih meriti u recimo u satima developmenta.

Saberes sve to i to ispadne recimo 219 jedinica. (koristicu primer sa slike)
onda mozes recimo svakog petka da crtas ovakav grafik
http://weblogs.asp.net/blogs/jcogley/WindowsLiveWriter/LearningfromyourBurnDownchart_8A1/image_6.png

znaci prve nedellje imas 219 unita i nisi jos uradio nista.
sledece si uradio 10, ostalo ti je 209... i tako redom.


nije bas najpouzdanije sredstvo, i trazi dobru inicijalnu procenu ali vec negde na polovini mozes da *grubo* projektujes kraj projekta.

[Milos Vukotic]

Joel ima freški tekst na približno istu temu http://www.joelonsoftware.com/items/2009/03/09.html

[kodi]

stackoverflow.com

pitanje: What is the single most effective thing you did to improve your programming skills?


pobednicki odgovor:

i) learning other frameworks/languages, and seeing how they do things, and compare that to stuff that I already know

ii) reading about patterns, best practices, and then examining my old stuff and applying those patterns where necessary

iii) pair programming

iv) working with people far smarter than I

v) Always listening to what others have to say, regardless if they're junior, intermediate, senior or guru. title means **** all

vi) Disagreeing with everything Joel says. ;)