Wprowadzenie Na temat tak zwanych metod obiektowych często można spotkać teksty takie jak ten z wikipedii: Programowanie obiektowe (ang. object-oriented programming, OOP) ? paradygmat programowania, w którym programy definiuje się…
Architektura reprezentuje ważną decyzję projektową, która wpływa na kształt systemu, przy czym waga decyzji mierzona jest kosztami zmian, które wprowadza. — Grady Booch Jeśli myślisz, że dobra architektura jest droga,…
Właśnie dlatego analiza i wymagania powinny zawierać model dziedziny wraz z zaleceniami co do implementacji. Nie jest to dokument (ten model) dla sponsora projektu (w rozumieniu do czytania). Jego rola (wartość jaką wnosi do projektu) to minimalizacja ryzyka, że developer wykona coś czego nie chcemy.
Bardzo często zastanawiam się, nad przyczynami porażek projektów, przyczynami tego, że jedne są lepsze inne gorsze, a gorszy to taki, który wymyka się spod kontroli a ostateczny efekt (produkt), uzyskany po znacznie dłuższym czasie niż planowano, jest zaskoczeniem dla wszystkich. Na to nakłada się problem przekazywania wiedzy pomiędzy kolejnymi etapami projektu, gdzie największym ryzykiem jest zrozumienie problemu i przekazywanie wiedzy przez samego zamawiającego. Gdzie problem? Ten artykuł polecam "biznesowi" który szuka przyczyn swoich problemów, i tym (nie tylko analitykom), którzy mają ambicje robić coś w kierunku poprawy tego stanu rzeczy, zamiast uznawać obecne statystyki za pewnik bo "takie są fakty". [...] Ktoś może powiedzieć: biznes tego (notacje, modele itp.) nie rozumie. I ma racje, bo to narzędzia a nie produkty analiz. Produktem analizy dla biznesu są zawsze rekomendacje (wymagania na oprogramowanie to także rodzaj rekomendacji brzmiącej: zalecam by takie warunki spełniało to oprogramowanie). Zamawianie przez biznes modeli jako takich, to jakieś koszmarne nieporozumienie. To tak jak by np. prawnik, jako produkt zlecenia "opinia prawna" oddał wybrany stos kodeksów z komentarzami. Nie, dobry prawnik oddaje jedna stronę rekomendacji: opinie prawną. To, że skorzystał z tych kodeksów to jego narzędzie pracy, możliwe, że załączy je do tej tej opinii (ale raczej jako materiał dla innego prawnika lub audytora).
proszę programistów: róbcie to co rozumiecie i nie wmawiajcie nikomu, że wiecie lepiej jak zarządzać firmą Waszych klientów. Róbcie to co każdy dobry stolarz: poproście klienta o rysunek tego co ma powstać i zróbcie. Nie zapominajcie, że dobry stolarz to nie to samo do dobry projektant, jak klient nie potrafi rysować (a najczęściej nie, bo nie to jest jego kompetencją), dobry stolarz zawsze odeśle do projektanta po rysunek. Między innymi dlatego, by później nie być posądzonym o stronniczość czyli rysowanie tylko tego co jest łatwe w wykonaniu. Rzecz w tym, że nie ma być łatwe dla stolarza a dobre dla klienta.