Sprawna Inżynieria Oprogramowania: Ekstremalna obiektowość

W projektach informatycznych najczęściej spotykamy: analityka wymagań (AW), analityka systemowego (AS), dewelopera w tym architekta systemu (D). W zasadzie trudno powiedzieć co jest produktem każdego z nich. Najczęściej AW dostarcza jakiś opis tego czego oczekuje klient, AS robi porządkuje to zrobił AW np. z pomocą przypadków użycia a D bierze to do ręki i musi zaprojektować i wykonać oprogramowanie. Jak widać, odpowiedzialność za to co powstanie jest rozmyta. Klient najpierw przekazuje swoje oczekiwania AW zaś otrzymuje produkt od D. Konia z rzędem temu, kto mi powie jak tego dokonać bez permanentnych iteracyjnych wyjaśnień i bombardowania Klienta pytania w rodzaju "co Państwo mieli na myśli pisząc...".

Czytaj dalejSprawna Inżynieria Oprogramowania: Ekstremalna obiektowość

Frameworks Introduction – czyli jak się psuje dobre ERP

Systemy zintegrowane ERP będą pewnymi zestawami gotowych funkcjonalności, zbudowanymi w oparciu o szkielety oprogramowania zaś integracja będzie bazowania nie na współdzieleniu danych a na wymianie ich pomiędzy modułami i zewnętrznymi systemami na równych prawach. Rozwój systemu w takim przypadku polega na tworzeniu nowych modułów tym środowisku a nie na modyfikacji już istniejących. Tak więc co mogę poradzić? Bardzo dokładne przyglądanie się rozdziałom oferty pod tytułem Dostosowanie systemu, Koncepcja wdrożenia oraz ile oczekiwanych przez Państwa funkcjonalności to te, których system w swej wersji standardowej nie oferuje. Powinny one być po dokładnej analizie, zaprojektowane i zaimplementowane. Jeżeli Konsultanci zaczynają negocjować rezygnację z części oczekiwań lub oferują coś podobnego w systemie, to pierwszy sygnał, że powinien ktoś im zacząć patrzeć na ręce, i nie mam tu na myśli ich przełożonego.

Czytaj dalejFrameworks Introduction – czyli jak się psuje dobre ERP

Domain Model – serce aplikacji

Całkiem niedawno pisałem o tworzeniu diagramów klas a konkretnie modelu dziedziny w odpowiedzi na post pewnego blogera. Wymiana poglądów skończyła się z e strony adwersarza na zwróceniu uwagi, iż diagram klas może pokazywać wiece niż mój (bo może) ja zaś zwróciłem uwagę na fakt, że diagram klas to jakiś model a model powinien modelowa jedne coś. Pokazanie na jednym diagramie klas dużo chyba mija się z celem bo można zabrnąć w rejon gdzie sprawdza się reklama Banki od wszystkiego są do niczego.

Czytaj dalejDomain Model – serce aplikacji

Na forach czyli znowu modelowanie

Wąskim gardłem jest przejście z procesów na model dziedziny i przypadki użycia, które to tak na prawdę powinny być sprowadzone jeden do jednego do modułów (klas) wykonawczych np. widoku i kontrolera wzorca MVC (który bardzo lubię :)) a model dziedziny wchodzi jeden do jednego w Model w MVC.

Czytaj dalejNa forach czyli znowu modelowanie

Koniec treści

Nie ma więcej stron do załadowania