Architektura oprogramowania i UML dla programistów

Gorąco polecam programistom, by w ogóle zaczęli korzystać z UML a analitykom, by wyleczyli się z wielu mitów o UML rozpowszechnianych niestety na wielu, nie zawsze tanich, szkoleniach i w wielu kiepskich "poradnikach UML" (pisanych nie raz nawet przez uczelnianych doktorów i nie tylko)..... Może wtedy przestaną tworzyć nieprzydatne developerom dokumentacje.

Continue ReadingArchitektura oprogramowania i UML dla programistów

Produkty w procesie analizy wymagań

Konkluzja prawnika, by zawierać umowy o dzieło jeżeli tylko jest to możliwe, jest moim zdaniem słuszna. Tam gdzie nie mamy wystarczającej wiedzy by zawierać takie umowy, warto zainwestować czas by określić jednak przedmiot umowy, gdyż umowa zlecenia z ekspertem (dostawcą oprogramowania) powoduje, że Zamawiający kompletnie nie panuje nad umową: nie wie jakiego produktu oczekiwać, satysfakcja z wykonanej pracy może nadejść w trudnym do przewidzenia czasie. Druga uwaga: jeżeli cały proces, od pierwszej analizy do dostarczenia produktu, realizuje jedna firma, mamy do czynienia z sytuacją, w której dostawca sam kontroluje stawiane mu wymagania bo sam sobie definiuje to co ma następnie wytworzyć. Taki brak kontroli rodzi poważne ryzyko nierzetelności.

Continue ReadingProdukty w procesie analizy wymagań

Czas nie jest aktorem dla Systemu c.d. czyli projekt

aktorem absolutnie nie jest Czas, aktorem jest inny system, tu źródło sygnału czasu. Diagram UC jest zgodny ze standardem a my "zrozumieliśmy istotę rzeczy". Stosowanie w analizie standardów prowadzi do rozumienia i ma taką właśnie zaletę: analiza i modelowanie prowadzi do zrozumienia problemu, łamanie zasad notacji ukrywa niezrozumienie problemu (o co chodzi z tym oczekiwanym przez klienta czasem).

Continue ReadingCzas nie jest aktorem dla Systemu c.d. czyli projekt