Prototyp nie jest niczym ponad to, że jest tylko obrazkiem lub makietą

(developer nie jest w stanie stworzyć żadnego rozwiązania tylko na bazie obrazków). Trudno z tym artykułem polemizować, a jednak rzesze analityków, i o dziwo developerów, chyba większości firm IT, jako produkty analiz wymagań przedstawiają tylko owe prototypy czyli "user story", mock-up'y ekranów, tabele itp. W środku jest jakaś określona logika i to ona jest kluczowym wymaganiem.

Czytaj dalejPrototyp nie jest niczym ponad to, że jest tylko obrazkiem lub makietą

Model jako symulacja – także w analizie i projektowaniu oprogramowania

Model dziedziny nie powinien więc być diagramem słownikowym (diagram klas z gęsto powiązanymi klasami nafaszerowany dziedziczeniem i asocjacjami). Taki diagram to model pojęciowy (pojęcia słownikowe) nie nadający się do implementacji. Wymaga jeszcze wiele pracy. Jeżeli skażemy na nią programistę, osobę która nie zna tej "dziedziny", to z dużym prawdopodobieństwem powstanie "coś co nie koniecznie jest tym czymś co powinno powstać", i nie jest to wina tego programisty tylko tego, który mu dał opis tego co ma powstać w takiej właśnie, niezdefiniowanej postaci. [...] Tak więc szanowni klienci: sprawdzajcie co Wam dają analitycy, jeżeli model dziedziny systemu jest dla Was totalnie nie zrozumiały (to co mówi lub referuje analityk), to prawdopodobnie jest to zły model... Tak więc model dziedziny opisujący sprzedaż, powinien zawierać obiekt biznesowy Faktura ale obiekt ten nie powinien mieć operacji "nowa faktura", model powinien zawierać odrębny obiekt np. NarzędzieFakturzysty, mający "w sobie" wiedzę o tym jak się wystawia faktury. Powody są dwa: techniczny opisał powyżej kolega programista, drugi powód jest bardzo prozaiczny: bo faktury same się nigdzie nie wystawiają...

Czytaj dalejModel jako symulacja – także w analizie i projektowaniu oprogramowania

Koniec treści

Nie ma więcej stron do załadowania