DevProTalk

DevProTalk (http://www.devprotalk.com/index.php)
-   Planiranje i usability (http://www.devprotalk.com/forumdisplay.php?f=35)
-   -   Funkcionalna specifikacija (http://www.devprotalk.com/showthread.php?t=6513)

_korso_ 23. 10. 2008. 17:01

Funkcionalna specifikacija
 
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 23. 10. 2008. 17:18

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_ 23. 10. 2008. 17:29

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 23. 10. 2008. 17:45

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 23. 10. 2008. 18:09

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).
Citat:

Originalno napisao LiquidBrain (Napišite 62514)
Kreni od pocetka... prvo isprojektujte bazu...

Projektovanje baze je daleeko od početka.

misk0 23. 10. 2008. 22:12

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_ 24. 10. 2008. 10:57

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 09. 03. 2009. 18:57

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/...ine-prisustvo/

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

kodi 09. 03. 2009. 23:51

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


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 10. 03. 2009. 09:47

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


Vreme je GMT +2. Trenutno vreme je 18:28.

Powered by vBulletin® Verzija 3.6.8
Copyright ©2000 - 2018, Jelsoft Enterprises Ltd.
Copyright © DevProTalk. All Rights Reserved.

Mišljenja, saveti, izjave, ponude ili druge informacije ili sadržaji nastali na Sajtu su vlasništvo onoga ko ih je kreirao, a ne DevProTalk.com, tako da ne morate da se oslanjate na njih.
Autori poruka su jedini odgovorni za ovakve sadržaje. DevProTalk.com ne garantuje tačnost, kompletnost ili upotrebnu vrednost informacija, stavova, saveta ili datih izjava. Ne postoje uslovi pod kojima bi mi bili odgovorni za štetu ili gubitak koji je posledica bilo čijeg oslanjanja na nepouzdane informacije, ili bilo kakve informacije nastale kroz komunikaciju između registrovanih članova.
Web sajt može sadržavati linkove na druge web sajtove na Internetu ili neke druge sadržaje. Ne kontrolišemo niti podržavamo te druge web sajtove, niti smo pregledali bilo kakve sadržaje na takvim sajtovima. Mi nećemo biti odgovorni za legalnost, tačnost ili prikladnost bilo kog sadržaja, oglasa, proizvoda, usluga ili informacije lociranim na ili distribuiranih kroz druge web sajtove, niti za bilo kakvu štetu nastalu kao posledica takvih informacija. DevProTalk.com drži i čuva druga prava vlasništva na web sajtu. Web sajt sadrže materijale zaštićene copyright-om, zaštitne znakove i druge informacije o pravu vlasništva ili softver. Članovi mogu poslatu informacije zaštićene pravima vlasništva njihovih nosilaca i ona ostaju zaštićena bez obzira da li su oni koji prenose te informacije to naveli ili ne. Osim informacija koje su u javnom vlasništvu ili za koje dobijete dozvolu, nemate pravo da kopirate, modifikujete ili na bilo koji način menjate, objavljujete, prenosite, distribuirate, izvršavate, prikazujete ili prodajte bilo koju informaciju zaštićenu pravima vlasništva. Slanjem informacija ili sadržaja na bilo koji deo DevProTalk.com, Vi automatski dozvoljavate i predstavljate garanciju da imate pravo da dozvolite DevProTalk.com ili članovima DevProTalk.com bespovratnu, kontinualnu, neograničenu, globalnu dozvolu da koriste, kopiraju, izvršavaju, prikazuju i distribuiraju takve informacije i sadržaje i da iz takvih sadžaja koriste bilo koji deo u bilo koje svrhe, kao i pravo i dozvolu da koriste gore navedene sadržaje. Svi zaštitni znakovi (trademarks), logotipi, oznake usluga, firme ili imena proizvoda koji se pominju na ovom web sajtu su vlasništvo kojim raspolažu njihovi vlasnici.