Cześć,
Chciałbym poczytać i przyswoić wiedzę na temat projektowania aplikacji w różnego rodzaju firmach IT(korpo, software house etc) Przykładowo macie nowe zlecenie np. CRM i w jaki sposób podchodzicie do tego tematu (domene już znacie) rysujecie schemat EFD, DFD, use case, diagramy UML etc? Czy dzisiaj inaczej podchodzi się do tego typu zadań?
Może znacie w miarę nowe książki o inżynierii oprogramowania i projektowaniu aplikacji i czego używać?
Polecam podejście prototypowe + Scrum. Jakiś naprawdę zgrubny szkic aplikacji, research podobnych rozwiązań, szybki prototyp, feedback i częste iteracje. Im mniej papierów a więcej implementacji (ale na początku zgrubnej, tylko tyle, aby ustalić właściwy kierunek działań) tym lepiej. Optymalizacja na koniec ;p
Jedyna sytuacja kiedy spotkałem się z produkowaniem wszystkich możliwych dokumentów to było http://wwwis.win.tue.nl/2R690/doc/ECSS-E-ST-40C(6March2009).pdf i raczej nigdzie indziej (może jakieś critical systems i wojsko) się tak nie robi ze względów praktycznych.
@ekhart Dziękuję, poczytam o podejściu prototypowym.
@Shalom Ok, to jak przy innych projektach zbieracie wymagania, tak żeby ludzie wiedzieli co mają robić i jakie funkcjonalności musi mieć soft?
W kolejności: mózg, kartka papieru i długopis, biała tablica i mazaki, system śledzenia zadań (np. Jira).
somekind napisał(a):
W kolejności: mózg, kartka papieru i długopis, biała tablica i mazaki, system śledzenia zadań (np. Jira).
i kod.
Ja lubię mieć w głowie mentalny model tego, co chcę zrobić. Jak cała aplikacja będzie działać jako system powiązanych elementów, próbuję sobie wyobrazić przepływ danych/sterowania, jak trzeba to na poziomie pojedynczych wywołań funkcji (ta funkcja wywołuje tę), powiązania między obiektami itp. Szukam też dobrych metafor, nazw. Staram się nie kombinować, a robić coś prostego, co jednak pozwoli na elastyczność tam, gdzie będzie prawdopodobnie potrzebna (staram się od razu myśleć o tym, co może się zmienić).
Oczywiście nie zawsze się da wszystko przewidzieć czy zwizualizować, więc czasem piszę najpierw prototyp i buduję sobie ten model w głowie już w trakcie pisania kodu (tj. nie tylko pisania oczywiście, bo również odpalania go, patrzenia jak działa w praktyce, weryfikowania hipotez, zbierania nowych wymagań itp.).