... opracowanie założeń działania projektu
... skonstruowanie modelu danych
... projekt algorytmu
... programowanie
... testy

Czy wykorzystujecie "betatesterów"?
Jak przeliczacie czas na pieniądze?

Tródno powiedziec. Wszystko zależy od tego co się robi. Gdy jest to zupełnie nowy projekt to:
Ile czasu :
- skonstruowanie modelu danych i projekt algorytmu - planowanie - tyle ile potrzeba, przy "dużych" projektach ok tygodnia na wymyślenie odpowiedniego sposobu i struktury danych. Chyba, że jest to projekt podobny do tego który już robiłem, co zdarza się bardzo rzadko.
- programowanie i testy - też robie razem bo czasem coś działa na windzie a trzeba sprawdzić czy online też będzie dziłać lub wymyślać sposoby obejścia problemu

Nie wykorztstuje beta testerów, czasem tylko sadzam osoby postronne przed stroną i sprawdzam czy np. panel administracyjny jest "user friendly".

Co do pieniędzy to "przeliczam czas na pieniadze" 8)

1. projekt najwazniejszy. jesli ma zajac 50% czasu to sie oplaca.
2. programwoanie wg projektu.
3. testowanie przez siebie i laika ktory bawi sie w usera (spacje, etc)
4. testowanie przez kogos z ambicjami zhaczenia za wszelka cene ;)

czas na pieniadze? oj. kazdy ma inna szkole i malo kto chyba o niej lubi mowic ;)

U mnie zwykle rozkład czasu wygląda następująco:
[list]
[*]opracowanie wymagań funkcjonalnych i pozafunkcjonalnych: 10%
[*]opracowanie metod i algorytmów kodowania: 20%
[*]opracowanie modelu danych: 40%
[*]kodowanie: 20%
[*]testowanie: 10%
[list]

Na co warto zwrócić uwagę?

Przy w pierwszej fazie na dokładne rozeznanie problemu. Warto odpowiedzieć sobie na pytanie: "potrzeba jakich dodatkowych funkcjonalności może się pojawić już po zakończeniu pracy nad projektem?". Jeśli stworzymy produkt elastyczny i otwarty to zawsze będzie go można łatwo rozbudować (i policzyć sobie za dorobienie nowych funkcji, przy niewielkim nakładzie pracy :wink:).

Drugi krok poświęcam zwykle na przegląd czym dysponuję w danej chwili (biblioteki, gotowe moduły itd.) oraz czym dysponują inni. Może już ktoś to robił? Pisał o tym? Opublikował źródła? Potem zbieram wszystko do kupy i staram się wypracować jakąś spójną koncepcję. Zaniedbanie tego ktroku może powodować, że będziemy wyważać otwarte drzwi.

IMO, model danych jest najbardziej newralgicznym punktem aplikacji. Klienta zawsze można przebudować - źle skonstruowanej bazy danych zapełnionej 80 milionami rekordów jakby niezbyt... Byćmoże miałem do czynienia z wyjątkowo wrednymi bazami danych i mam spaczone patrzenie ale wnioski są sądzę uniwersalne.

Kodowanie - wiadomo. Chleb powszedni. Warto dbać o strukturę projektu - łatwo się w trakcie prac rozłazi. Trzeba sobie wydzielić środowisko projektowe (kodowanie i nasze sprawdzanie czy działa), testowe(czyjeś sprawdzanie czy działa - wtedy gdy nam się już wydaje, że tak) i użytkowe(to można pokazywać klientowi, jeśli chce śledzić postępy prac). I jeszcze jedno duże hasło: DOKUMENTACJA. Kodu i całości projektu. Zabiera nieco czasu ale nie należy sobie tego odpuszczać.

Testowanie powinno mieć mniej więcej takie fazy jak napisał kurtz. Zwykle jest tak: najpierw samodzielnie szukamy usterek, potem jakiś inny spec szuka usterek, potem jakiś laik bawi się interfejsem, na końcu napuszczamy 'hakera' i pozwalamy gnębić nam nasze dzieło

No na Ciebie to zawsze można liczyć I miło czytać tak sensownie napisane wypowiedzi. Aż samemu by sie chciało tak elokwentnym być...