UML version 2.5
Co prawda formalna publikacja wersji 2.5 UML to 1 marzec 2015 r. ale co ma wisieć nie utonie (spokojne przebrnięcie tych 794 stron wymaga czasu i cierpliwości), czyli wzmianka i…
Bezpieczny jak email czyli wcale
Korzystanie z własnego repozytorium daje ochronę bo: my nim administrujemy, w przeciwieństwie do sieci Internet, nie da się go "podsłuchiwać", i co najważniejsze: dokumenty są w sposób jednolity skatalogowane, wersjonowane itp. Jeżeli jedyne miejsce z dokumentami, ich wersjami itp, to nasze skrzynki pocztowe, to znaczy, że nikt nie ma wiarygodnej, kompletnej wiedzy o projekcie.
Dlaczego nie podoba mi się klasa Pracownik?
Swego czasu pod artykułem Business Model vs. System Model, wywiązała się dyskusja, po tym jak napisałem, że oprogramowanie reprezentuje narzędzie pracy, więc projekt tego oprogramowania raczej powinien zawierać pojęcie (klasę) Karteka Pracowników a nie Pracownicy. Jeden z czytelników napisał wtedy (dociekliwym polecam w tym momencie cała tę dyskusje pod artykułem): ... byt Pracownik jak najbardziej ma sens. Przecież tu jest zdefiniowane jego zachowanie (część jedynie z real world, ale jednak). Pracownik.pijeKaweRano().. przeciez nie KartotekaPracownika.pijeKaweRano() (Business Model vs. System Model). Gdzie problem? [...] No więc dlaczego nie podoba mi się klasa Pracownik? Bo pracownik to Aktor Systemu, a System ten przechowuje wybrane dane o tym pracowniku. Są to dane potrzebne np. do identyfikowania osób wystawiających dokumenty z Systemu, a do tego potrzebne są jedynie Karty Pracowników a nie Pracownicy. System (oprogramowanie) zastąpił papierowe Kartoteki Magazynowe dlatego są one teraz w Systemie, ale towary są w nadal magazynie 9a nie w Systemie), system "ma w środku" Kartę Towaru (zastąpiła papierową) zawierająca opis towaru i jego ilość w magazynie. Kartoteka Magazynowa to pudło zawierające Karty Towarów. Faktura VAT to obiekt w systemie, można ją wydrukować lub wysłać jej egzemplarz w postaci elektronicznej kontrahentowi.
Bo najważniejsi Panie są Aktorzy…
Bardzo często spotykam się z projektami, w których użytkownicy narzekają na dostawcę oprogramowania, uważają że program nie całkiem spełnia ich oczekiwania (wymagania podpisali... ale to nie rozwiązuje tego problemu). Problem polega na często spotykanym podejściu: analiza wymagań tylko w postaci wywiadów i w konsekwencji niepełne zrozumienie specyfiki biznesowej oraz fakt, że developer ma skłonności do uproszczeń i "normalizacji". Innym, moim zdaniem jeszcze gorszym podejściem, jest rozpoczęcie kodowania jeszcze w trakcie trwania wywiadów i tworzenie oprogramowania metodą codziennych, lub co tygodniowych spotkań z użytkownikiem opisującym kolejne aspekty systemu. Zbyt późne odkrywanie (a nie raz nawet niedostrzeganie tego), tego że pewne rzeczy są 'tymi samymi rzeczami" ale w innych kontekstach, prowadzi do bardzo wielu problemów z implementacją. Ale po kolei.
Jak udokumentować zakres projektu w sposób czytelny i jednoznaczny
Krótki wpis po pewnej nie długiej dyskusji na pewnym forum. Jeden z dyskutantów przytoczył definicję zakresu projektu publikowaną w WIKI: Zakres projektu jest to możliwie jak najdokładniejsze i całkowite określenie oczekiwanego wyniku projektu. Zakres nigdy nie określa konkretnych zadań mających na celu realizację projektu. Odpowiada na pytanie, co powinno być zrobione w projekcie. Wyznacza ramy do oszacowania kosztu projektu i czasu realizacji projektu. Zakres, koszt i czas tworzą parametry projektu, tzw. ?magiczny trójkąt?. (Zakres projektu ? Wikipedia, wolna encyklopedia). Tak więc mamy pytanie: "co powinno być zrobione w projekcie"? Pytanie jakie ja postawiłem: "czyim projekcie"? Zakres projektu dla kogo? [...] W moich oczach nie ma nic bardziej ryzykownego niż przekazanie Opisu Księgowej od razu programistom do wykonania. Bo mamy tak na prawdę trzy zakresy projektu, każdy inny, każdy ma innego adresata i każdy należy udokumentować inaczej, ale zawsze jednoznacznie postawić zadanie. Praca bez tego typu dokumentów, bez jasnego wydzielenia poszczególnych etapów analizy, tak często praktykowana przez wiele firm IT, to atak na twierdzę bez mapy terenu i strategii...