Temat: Zrozumiałość diagramów

Stanisław Niepostyn:

Jakub Wojt:
Czy diagramy UML (ogólniej - dokumentacja) muszą być zrozumiałe ?

Nie i czasami nie są zrozumiałe zwłaszcza dla Klientów (aczkolwiek miałem przypadki, że programistów trzeba było szkolic z UML). Wtedy stosuje się inne notacje.

Jakie:D Masz programistę, który nie zna UML a zna inne notacje? Znaczy co on zna? Archimate?
Bo chyba niestrukturalizowanych bazgrołów wymyślonych metodą rysuj-i-mów na whiteboardzie, albo wklejaniem tabelek w mindmapę nie nazywasz notacją?

Temat: Zrozumiałość diagramów

Mateusz Kurleto:

Stanisław Niepostyn:

Jakub Wojt:
Czy diagramy UML (ogólniej - dokumentacja) muszą być zrozumiałe ?

Nie i czasami nie są zrozumiałe zwłaszcza dla Klientów (aczkolwiek miałem przypadki, że programistów trzeba było szkolic z UML). Wtedy stosuje się inne notacje.

Jakie:D Masz programistę, który nie zna UML a zna inne notacje? Znaczy co on zna? Archimate?
Bo chyba niestrukturalizowanych bazgrołów wymyślonych metodą rysuj-i-mów na whiteboardzie, albo wklejaniem tabelek w mindmapę nie nazywasz notacją?

Często znają poprzednika diagramu stanów:
http://pl.wikipedia.org/wiki/Automat_sko%C5%84czony
Czasem DFD:
http://pl.wikipedia.org/wiki/DFD
A najczęściej schemat blokowy:
http://pl.wikipedia.org/wiki/Schemat_blokowy

Temat: Zrozumiałość diagramów

Stanisław Niepostyn:
Często znają poprzednika diagramu stanów:
http://pl.wikipedia.org/wiki/Automat_sko%C5%84czony
Czasem DFD:
http://pl.wikipedia.org/wiki/DFD
A najczęściej schemat blokowy:
http://pl.wikipedia.org/wiki/Schemat_blokowy

Ale mówiliśmy o projektach systemów, a nie o algorytmice. Jak chcesz korzystając ze schematów blokowych projektować cokolwiek bardziej złożonego niż implementacja algorytmu?

Temat: Zrozumiałość diagramów

Mateusz Kurleto:

Jakub Płachecki:
Troszkę off-topic :-)

Mateusz Kurleto:

Jacek Sałacki:
Po przeczytaniu dowolnej książki, artykułu obejrzeniu filmu jesteś w stanie powiedzieć czy przekaz był dla ciebie zrozumiały, prawda? I to jest właśnie kluczowe komu, co i w jaki sposób przekazujesz.

No nie. Daj dziecku do przeczytania potop nie mówiąc nic o rozbiorach i opowie Ci zupełnie inną historię.

Wybitnie niefortunne porównanie, aż chce się zapytać "co ma piernik do wiatraka?" :-) Może w odniesieniu do tak istotnych wydarzeń historycznych nie jest to pytanie na miejscu, nie mniej jednak wydarzenia te oddziela od siebie przeszło 100 lat (potop - 1655-1660, I rozbiór Polski - 1772). Mam nadzieję, że nie muszę przypominać, że Szwedzi w rozbiorach udziału nie brali...

Piernik do wiatraka ma tyle, że Sienkiewicz pisał książki "wywrotowe" w czasie rozbiorów opisując sukcesy Polaków w przeszłości. Osoba, która o tym fakcie nic nie wie, czytając Potop pozna jedynie historię najazdu Szwedów, nie znajdując żadnej paraboli do rozbiorów, będzie za to przekonana, że świetnie zrozumiała Powieść, włącznie ze studium charakterów jej głównych bohaterów.
Natomiast faktycznie nie do końca ją rozumie, bo nie zna całego tła historycznego, ze współczesności autora, do którego tenże się odwołuje.
Wniosek z tego taki, że jako odbiorca nie zawsze jesteś w stanie powiedzieć, czy odbiór był dla Ciebie zrozumiały.

W takim kontekście się z Tobą zgodzę, natomiast w dalszym ciągu porównanie uważam za zbyt daleko idące, że tak się wyrażę - w końcu autorem diagramów nie kierują żadne "utajone" motywy, ani też nie chce wyrazić żadnych dodatkowych treści, ba - nie powinien nawet tego robić. Diagramy powinny dawać jak najmniej możliwości jeśli chodzi o ich alternatywną interpretację. I w takim z kolei kontekście powinno być dokładnie tak, jak pisze Jacek - fakt prawidłowego zrozumienia przekazu nie powinien budzić jakichkolwiek wątpliwości. Jeśli takowe są, a nie przychodzi nam do głowy taka modyfikacja diagramu, która spowodowałaby ich usunięcie, pozostają nam dwie rzeczy:
1. Opis muzyczno-słowny do diagramu - pamiętać należy, że celem używania notacji jest precyzyjne i nie budzące wątpliwości przekazanie informacji, a nie jest to sztuka dla sztuki. Ponoć dobry diagram (czy też rysunek) wart jest tysiąca słów. Niektórzy zaś twierdzą, że owszem, ale tylko wtedy, kiedy również tysiąc słów go opisuje. Niech nikt nie traktuje tego dosłownie, proszę :-) Cel jest tu najważniejszy. Jeśli ktoś w oparciu o same diagramy jest w stanie przekazać dokładnie to, co przekazać chce i nic więcej - chwała mu za to. Jeśli nie jest w stanie, a nie zechce wykorzystać opisu muzyczno-słownego z jakiegokolwiek powodu (np. żeby nie wyszedł na jaw brak umiejętności lub doświadczenia), to znaczy, że ta osoba zapomniała dlaczego robi to, co robi.
2. Popracowanie nad zawieraniem jednoznacznych i precyzyjnych informacji bez nadmiarowych opisów - diagramy same w sobie to swoiste opisy, jeśli musimy je jeszcze dodatkowo opisywać by były jasne i jednoznaczne, to wiemy już nad czym powinniśmy się "pochylić" w nieustannym dążeniu do doskonałości ;-)Jakub Płachecki edytował(a) ten post dnia 07.03.11 o godzinie 19:50

Temat: Zrozumiałość diagramów

Jakub Płachecki:
W takim kontekście się z Tobą zgodzę, natomiast w dalszym ciągu porównanie uważam za zbyt daleko idące, że tak się wyrażę - w końcu autorem diagramów nie kierują żadne "utajone" motywy, ani też nie chce wyrazić żadnych dodatkowych treści, ba - nie powinien nawet tego robić. Diagramy powinny

Ależ utajone motywy autora nie koniecznie są jedynym źródłem sytuacji w której odbiorca jest przekonany o prawidłowym przekazie, będąc tym samym w błędzie. Ja jedynie przeprowadziłem dowód exemplum in contrarium ukazujący nieprawdziwość tezy, że odbiorca zawsze jednoznacznie potrafi ocenić zrozumiałość przekazu.

dawać jak najmniej możliwości jeśli chodzi o ich alternatywną interpretację. I w takim z kolei kontekście powinno być dokładnie tak, jak pisze Jacek - fakt prawidłowego zrozumienia przekazu nie powinien budzić jakichkolwiek wątpliwości. Jeśli

A ludzie powinni być dobrzy i szlachetni, pomagać sobie bezinteresownie i nie krzywdzić wzajemnie.
Chociaż bardzo chcę, żeby tak było i wierzę w dobro ludzi to zamykam samochód, a PIN-u nie zapisuję markerem na karcie.
Niestety tak nie jest, ponieważ każdy ma inną percepcję oraz inne doświadczenia. Podawałem w którejś z dyskusji przykład zadania - narysuj rybę. W jednej z klas w USA niemal połowa dzieci narysowała prostokąt.

Temat: Zrozumiałość diagramów

Mateusz Kurleto:

Stanisław Niepostyn:
Często znają poprzednika diagramu stanów:
http://pl.wikipedia.org/wiki/Automat_sko%C5%84czony
Czasem DFD:
http://pl.wikipedia.org/wiki/DFD
A najczęściej schemat blokowy:
http://pl.wikipedia.org/wiki/Schemat_blokowy

Ale mówiliśmy o projektach systemów, a nie o algorytmice. Jak chcesz korzystając ze schematów blokowych projektować cokolwiek bardziej złożonego niż implementacja algorytmu?

Mowa była o programistach, którzy pracują nad różnymi fragmentami systemu.
Czasami jest tak, że po "przeczytaniu" dokumentacji programiści potakują z głebokim zrozumieniem, po czym .... muszę im wyjasniać za pomocą o wiele prostszych notacji sposób pracy fragmentu systemu, który mieli oprogramować ...

Temat: Zrozumiałość diagramów

Stanisław Niepostyn:

Mateusz Kurleto:

Stanisław Niepostyn:
Często znają poprzednika diagramu stanów:
http://pl.wikipedia.org/wiki/Automat_sko%C5%84czony
Czasem DFD:
http://pl.wikipedia.org/wiki/DFD
A najczęściej schemat blokowy:
http://pl.wikipedia.org/wiki/Schemat_blokowy

Ale mówiliśmy o projektach systemów, a nie o algorytmice. Jak chcesz korzystając ze schematów blokowych projektować cokolwiek bardziej złożonego niż implementacja algorytmu?

Mowa była o programistach, którzy pracują nad różnymi fragmentami systemu.
Czasami jest tak, że po "przeczytaniu" dokumentacji programiści potakują z głebokim zrozumieniem, po czym .... muszę im wyjasniać za pomocą o wiele prostszych notacji sposób pracy fragmentu systemu, który mieli oprogramować ...

Rozumiem, na niższym poziomie. Dzięki za wyjaśnienia:)

Temat: Zrozumiałość diagramów

Stanisław Niepostyn:

Jakub Wojt:
Czy diagramy UML (ogólniej - dokumentacja) muszą być zrozumiałe ?

Nie i czasami nie są zrozumiałe zwłaszcza dla Klientów (aczkolwiek miałem przypadki, że programistów trzeba było szkolic z UML). Wtedy stosuje się inne notacje.

Jeśli tak - czym jest owa "zrozumiałość" i jak ją mierzyć ?

Czy istnieją "współczynniki zrozumiałości" na podstawie których można stwierdzić, że dany zestaw diagramów jest "zrozumiały" ?

Rozumiem, że pytanie dotyczy architektury oprogramowania.
Cofnijmy się zatem 36 lat wstecz.[...]

Czy to znaczy "nie" ? :)Jakub Wojt edytował(a) ten post dnia 08.03.11 o godzinie 22:24

Temat: Zrozumiałość diagramów

Jakub Wojt:

Stanisław Niepostyn:

Jakub Wojt:
Czy diagramy UML (ogólniej - dokumentacja) muszą być zrozumiałe ?

Nie i czasami nie są zrozumiałe zwłaszcza dla Klientów (aczkolwiek miałem przypadki, że programistów trzeba było szkolic z UML). Wtedy stosuje się inne notacje.

Jeśli tak - czym jest owa "zrozumiałość" i jak ją mierzyć ?

Czy istnieją "współczynniki zrozumiałości" na podstawie których można stwierdzić, że dany zestaw diagramów jest "zrozumiały" ?

Rozumiem, że pytanie dotyczy architektury oprogramowania.
Cofnijmy się zatem 36 lat wstecz.[...]

Czy to znaczy "nie" ? :)Jakub Wojt edytował(a) ten post dnia 08.03.11 o godzinie 22:24

Uczestniczyłem w pewnym projekcie, w którym dokumentacja projektowa była robiona praktycznie tylko "pod Klienta". Programiści nie przejmowali się zbytnio odpowiedniością między modelami, a kodem. Główną przyczyną były zmiany wykonawcy systemu. Poprzedni nie był zainteresowany aktualizacją dokumentacji i ... się tak ciągnęło .... a czas zawsze gonił ... bo nie było czasu ... czyli typowe sprzężerze zwrotne, dobrze, że ujemne ...

Temat: Zrozumiałość diagramów

Stanisław Niepostyn:
Uczestniczyłem w pewnym projekcie, w którym dokumentacja projektowa była robiona praktycznie tylko "pod Klienta". Programiści nie przejmowali się zbytnio odpowiedniością między modelami, a kodem.

po co więc robić takie rzeczy?

Temat: Zrozumiałość diagramów

Jarek Żeliński:

Stanisław Niepostyn:
Uczestniczyłem w pewnym projekcie, w którym dokumentacja projektowa była robiona praktycznie tylko "pod Klienta". Programiści nie przejmowali się zbytnio odpowiedniością między modelami, a kodem.

po co więc robić takie rzeczy?

Tworzymy plan realizacji systemu informatycznego po to by zwiększyć szanse sukcesu tego projektu.
Brak takiej dokumentacji nie oznacza, że projekt zakończy się porażką, ale szanse porażki wtedy wzrastają.

Temat: Zrozumiałość diagramów

Stanisław Niepostyn:

Jarek Żeliński:

Stanisław Niepostyn:
Uczestniczyłem w pewnym projekcie, w którym dokumentacja projektowa była robiona praktycznie tylko "pod Klienta". Programiści nie przejmowali się zbytnio odpowiedniością między modelami, a kodem.

po co więc robić takie rzeczy?

Tworzymy plan realizacji systemu informatycznego po to by zwiększyć szanse sukcesu tego projektu.
Brak takiej dokumentacji nie oznacza, że projekt zakończy się porażką, ale szanse porażki wtedy wzrastają.

to odpowiedź na to pytanie? rozumiem, ze to o to chodzi:

Uczestniczyłem w pewnym projekcie, w którym dokumentacja projektowa była robiona praktycznie tylko "pod Klienta".

po protu pytam, po co robić dokumentację wiedząc, że idzie tylko na półkę, jako załącznik do faktury i autor dokumentacji wie że tak jest. Ciekawe także co ta dokumentacja dokumentuje... skoro nie jest wsadem do implementacji...

jeżeli zaś:

Programiści nie przejmowali się zbytnio odpowiedniością między modelami,
a kodem.

to gdzie była autor dokumentacji bądź co bądź projektowej?

Daleki jest od czepiania się Ciebie, po protu uważam, ze klient zamawiający analizę, projekt i ich dokumentację powinien zagwarantować sobie by wykonawca trzymał się projektu.Jarek Żeliński edytował(a) ten post dnia 09.03.11 o godzinie 09:50

Temat: Zrozumiałość diagramów

Jarek Żeliński:
Daleki jest od czepiania się Ciebie, po protu uważam, ze klient zamawiający analizę, projekt i ich dokumentację powinien zagwarantować sobie by wykonawca trzymał się projektu.Jarek Żeliński edytował(a) ten post dnia 09.03.11 o godzinie 09:50

Metodyki budowy oprogramowania, jak im się dokładniej przyjrzeć, mają pełno luk (tzw. gaps), które "wypełniane są" przez projektantów, czy architektów posiadających odpowiednie doświadczenie (heurystyki). Toteż realizacja projektu budowy systemu IT przez ludzi, którzy tego nigdy nie robili zazwyczaj kończy się katastrofą.
Opisane przeze mnie rozbieżności dotyczyły szczegółowych rozwiązań technicznych, nie zaś funkcjonalności systemu.
Realizując zaś system, wiadomo, że zaplanowane wcześniej rozwiązania szczegółowe bardzo często są korygowane, czy zmieniane w zależności od potrzeb związanych z budową systemu IT.
Dla osób uczestniczących w realizacji projektów budowy systemów IT jest to normalne i naturalne zjawisko.
Dlatego też testy akceptacyjne potwierdzały zgodność systemu z założeniami, jednakże dokumentacja projektowa nie była aktualizowana, gdyż wymagałoby to wykorzystania dodatkowych zasobów. Mając zaś perspektywę, że owa dokumentacja nie przysporzy jakichkolwiek profitów aktualnemu wykonawcy, stąd powstawały spore rozbieżności między rzeczywistą implementacją, a aktualnością dokumentacji projektowej.
Wydaje mi się, że błąd leżał po stronie Zamawiającego, który nie dość, że nie umieścił odpowiednich wymagań w umowie, ale też nie posiadał stosownych zasobów do weryfikacji tego typu zgodności.
Rozwiązaniem byłby audyt systemu firmy trzeciej.

Temat: Zrozumiałość diagramów

Stanisław Niepostyn:
Wydaje mi się, że błąd leżał po stronie Zamawiającego, który nie dość, że nie umieścił odpowiednich wymagań w umowie, ale też nie posiadał stosownych zasobów do weryfikacji tego typu zgodności.
Rozwiązaniem byłby audyt systemu firmy trzeciej.

dlatego uważam, że dobrym wyjściem jest model "budowlany": inwestor, wykonawca i biuro projektowe to obligatoryjnie trzy rożne podmioty nawzajem się nadzorujące..

... Wiele firm programistycznych ma etatowych, tak zwanych analityków wymagań, jednak oni z reguły nadal nie są projektantami. Raczej zapisują, w z góry ustalony sposób, to co mówi Zamawiający (z reguły zresztą bez pełnego zrozumienia co powiedziano). Bywa, że projektanta lub programistę wysyła się w roli analityka. To też nie działa z tych samych powodów komunikacyjnych, co potwierdza praktyka.

Czy wykonawca może mieć dobrego analityka projektanta? Może mieć, niejeden nawet ma ale… z jakiegoś powodu uznano, w znacznie starszej niż inżynieria oprogramowania, branży budowlanej, że Wykonawca nie powinien być autorem tego co należy wykonać dla Zamawiającego

jednak żeby model budowlany się sprawdził musi istnieć dla oprogramowania coś co spełni role rysunków technicznych, tu własnie mamy UML i nie może być mowy o "różnym zrozumieniu" a na pewno nie o "niezrozumieniu"...

(więcej tu: http://it-consulting.pl/autoinstalator/wordpress/index...

no i zawsze można wtedy sprawdzić jakość pracy biura projektowego: jak się ma produkt końcowy do projektuJarek Żeliński edytował(a) ten post dnia 09.03.11 o godzinie 12:19

Temat: Zrozumiałość diagramów

Jarek Żeliński:

Stanisław Niepostyn:
Wydaje mi się, że błąd leżał po stronie Zamawiającego, który nie dość, że nie umieścił odpowiednich wymagań w umowie, ale też nie posiadał stosownych zasobów do weryfikacji tego typu zgodności.
Rozwiązaniem byłby audyt systemu firmy trzeciej.

dlatego uważam, że dobrym wyjściem jest model "budowlany": inwestor, wykonawca i biuro projektowe to obligatoryjnie trzy rożne podmioty nawzajem się nadzorujące..

Rozdzielenie podmiotu projektującego od podmiotu implementującego spowodowałoby natychmiastowe rozmycie odpowiedzialności za produkt końcowy.

Temat: Zrozumiałość diagramów

dlatego uważam, że dobrym wyjściem jest model "budowlany": inwestor, wykonawca i biuro projektowe to obligatoryjnie trzy rożne podmioty nawzajem się nadzorujące..

Rozdzielenie podmiotu projektującego od podmiotu implementującego spowodowałoby natychmiastowe rozmycie odpowiedzialności za produkt końcowy.

Pewnie tak. Jedyny wniosek jest taki, że przy takim podziale obowiązków pociąga się do odpowiedzialności znaczeni rzadziej niż przy innych.

Podejrzewam, że inwestorowi bardziej zależy na zrealizowanym projekcie niż komforcie wyznaczania odpowiedzialnego za jego porażkę. Ostatecznie - to zawsze inwestor jest odpowiedzialny.

Temat: Zrozumiałość diagramów

dlatego uważam, że dobrym wyjściem jest model "budowlany": inwestor, wykonawca i biuro projektowe to obligatoryjnie trzy rożne podmioty nawzajem się nadzorujące..

[i]... Wiele firm programistycznych ma etatowych, tak zwanych analityków wymagań, jednak oni z reguły nadal nie są projektantami.

... bo projektanci dostają (po cichu) szału kiedy słuchają
(niestety najczęściej) niespójnego hm ... opowiadania klienta nt. jego własnej firmy. ;)

jednak żeby model budowlany

hm.. kilkukrotnie się spotkałem z tym porównaniem..

Jeśli uznać :
- specyfikacje modelu (najczęściej proza) ludzi "nietechnicznych" za lokalizacje i warunki terenowe projektu,
- fakt, że wydajność ludzi i sprzętu rośnie w tempie wykładniczym
- fakt, że technologia zmienia się w tempie < najprawdopodobniej > wykładniczym
- dobry murarz musi skończyć studia i mieć kilka lat praktyki
- ... i wiele innych

to myślę, że jest to dobry model ;)

się sprawdził musi istnieć dla oprogramowania coś co spełni role rysunków technicznych, tu własnie mamy UML i nie może być mowy o "różnym zrozumieniu" a na pewno nie o "niezrozumieniu"...

IMHO w temacie "rozumienia" diagramów powyższe trafia w sedno... :)Jakub Wojt edytował(a) ten post dnia 09.03.11 o godzinie 20:22

Temat: Zrozumiałość diagramów

Stanisław Niepostyn:
Rozdzielenie podmiotu projektującego od podmiotu implementującego spowodowałoby natychmiastowe rozmycie odpowiedzialności za produkt końcowy.

dlaczego?

Temat: Zrozumiałość diagramów

Jakub Wojt:
Ostatecznie - to zawsze inwestor jest odpowiedzialny.

jestem tego samego zdania

Temat: Zrozumiałość diagramów

Jarek Żeliński:

Stanisław Niepostyn:
Rozdzielenie podmiotu projektującego od podmiotu implementującego spowodowałoby natychmiastowe rozmycie odpowiedzialności za produkt końcowy.

dlaczego?

Czy uczestniczyłeś w projekcie, w którym jeden podmiot projektował, a jeszcze inny implementował system IT ?