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