Temat: Dlaczego tak rzadko używa się UML w projektach IT?

Katarzyna Kowalska:
Mysle ze z czasem (X) dotrzemy do momentu ze wszystko bedziemy prowadzic w EA :-) Osobiscie chcialabym :)

Niektórzy już tak robią ;-)
No, może nie "wszystko wszystko", ale to tylko ze względu na fakt, że niektórych elementów używa się lub nie - zależnie od przyjętego sposobu np. na szacowanie pracochłonności. Po odpowiedniej kalibracji metoda use case points daje się używać, ale dla projektów "niestandardowych" i tak trzeba uzyskane szacowanie modyfikować. Poza tym jeśli jakiś inny używany sposób się sprawdza, to nie ma sensu "na siłę" robić wszystkiego w jednym narzędziu, choćby nie wiem jak rozbudowane było i nie wiadomo jakie dawało możliwości.

W każdym razie jeśli chodzi o rejestrowanie produktów analizy i generowanie z nich np. specyfikacji funkcjonalnych, jest to bardzo przyjemne narządko, przynajmniej w przypadku najprostszych zastosowań w postaci 1 prowadzony projekt = 1 EAP. Sprawa się nieco komplikuje, gdy chcemy pobawić się w repozytorium bazodanowe z wersjonowaniem, na którym pracuje kilka zespołów analityczno-programistycznych i w którym siedzi model całego core'owego systemu, który jest ciągle rozwijany. To jest wyzwanie, no i masa frajdy dla "geeków" :-)

Polecam gorąco :-)

Temat: Dlaczego tak rzadko używa się UML w projektach IT?

Jakub Płachecki:
W każdym razie jeśli chodzi o rejestrowanie produktów analizy i generowanie z nich np. specyfikacji funkcjonalnych, jest to bardzo przyjemne narządko, przynajmniej w przypadku najprostszych zastosowań w postaci 1 prowadzony projekt = 1 EAP. Sprawa się nieco komplikuje, gdy chcemy pobawić się w repozytorium bazodanowe z wersjonowaniem, na którym pracuje kilka zespołów analityczno-programistycznych i w którym siedzi model całego core'owego systemu, który jest ciągle rozwijany. To jest wyzwanie, no i masa frajdy dla "geeków" :-)

Polecam gorąco :-)

Nie koniecznie musi to być EA. Ja np dokładnie tak samo pracuję korzystając z pakietów Visual Paradigm.
Generalnie dobra znajomość obiektowego paradygmatu, wykorzystywanie BPMN i UML oraz znajomość narzędzi CASE jest dzisiaj ogromną przewagą.

Temat: Dlaczego tak rzadko używa się UML w projektach IT?

Szkoda tylko, że tak wiele osób uważa, że BPMN i UML to tylko obrazki. Nie rozumiejąc, że dostosowanie narzędzia, w którym wytwarza się analizę daje ogromne możliwości na przetwarzanie jej treści do najróżniejszych postaci np. "UKOCHANYCH EXCELi" .

Temat: Dlaczego tak rzadko używa się UML w projektach IT?

Wojciech Kłujszo:
Szkoda tylko, że tak wiele osób uważa, że BPMN i UML to tylko obrazki. Nie rozumiejąc, że dostosowanie narzędzia, w którym wytwarza się analizę daje ogromne możliwości na przetwarzanie jej treści do najróżniejszych postaci np. "UKOCHANYCH EXCELi" .

a może dobrze, Ci co wyrośli z Exela mają fajne zlecenia ;)

Temat: Dlaczego tak rzadko używa się UML w projektach IT?

Jarek Żeliński:

Wojciech Kłujszo:
Szkoda tylko, że tak wiele osób uważa, że BPMN i UML to tylko obrazki. Nie rozumiejąc, że dostosowanie narzędzia, w którym wytwarza się analizę daje ogromne możliwości na przetwarzanie jej treści do najróżniejszych postaci np. "UKOCHANYCH EXCELi" .

a może dobrze, Ci co wyrośli z Exela mają fajne zlecenia ;)

:)) No właśnie problem polega na tym że nie wszyscy z tego wyrośli :)

Temat: Dlaczego tak rzadko używa się UML w projektach IT?

:)) No właśnie problem polega na tym że nie wszyscy z tego wyrośli :)

zaryzykuje tezę, że większość jeszcze nie... ;), poza tym chyba mnie to nie martwi ;)Jarek Żeliński edytował(a) ten post dnia 25.02.11 o godzinie 11:35

Temat: Dlaczego tak rzadko używa się UML w projektach IT?

Jarek Żeliński:

zaryzykuje tezę, że większość jeszcze nie... ;), poza tym chyba mnie to nie martwi ;)Jarek Żeliński edytował(a) ten post dnia 25.02.11 o godzinie 11:35

Jak przejdę na "freelance'erkę" to również nie będę się tym martwił :) a puki co pozostaje smutek :)

Temat: Dlaczego tak rzadko używa się UML w projektach IT?

Wojciech Kłujszo:

Jarek Żeliński:
zaryzykuje tezę, że większość jeszcze nie... ;), poza tym chyba mnie to nie martwi ;)Jarek Żeliński edytował(a) ten post dnia 25.02.11 o godzinie 11:35

Jak przejdę na "freelance'erkę" to również nie będę się tym martwił :) a puki co pozostaje smutek :)

tak zwana "freelancerka" na wady i zalety, ale rozumiem Twój smutek...

Temat: Dlaczego tak rzadko używa się UML w projektach IT?

Mateusz K.:
Ja mam inne doświadczenia. W mojej firmie używamy UML intensywnie. Nie istnieje ani jeden stworzony przez nas projekt, który nie posiada przynajmniej wysokopoziomowej analitycznej dokumentacji stworzonej z wykorzystaniem UML. Tak jest dużo lepiej i taniej testować pewne koncepcje i rozwiązania. Zmniejsza to ilość iteracji na etapie implementacji nawet 2-3 krotnie.
Pracowałem natomiast kilka razy dla dużych firm - w żadnej nie spotkałem UML-a - ba jakiejkolwiek formalnej notacji. Wydaje mi się, że wynika to z tego, że w dużych firmach metody prowadzenia projektów, wytwarzania oprogramowania itp tworzyli ludzie, którzy UML nie znają. To ludzie którzy tworzyli systemy strukturalnie - systemy duże i bardzo duże i robili to bez UML a swoje koncepcje przedstawiali na niedefiniowalnych schematach blokowych własnej produkcji metodą kartki i ołówka.
A młodszy staff nie ma możliwości przebicia się z nowymi tematami, bo "bieżączka" zabija takie projekty.

Mam podobne doświadczenia. Pracowałem w róźnych "renomowanych" firmach konsultingowych. Nie spotkałem UMLa na projektach, a jesli gdzieś był zastosowany to w sposób chaotyczny wyłącznie do wykonania fragmentarycznej dokumentacji, której później nikt nie aktualizował.
Z mojej obserwacji wynika, że pracownicy firm IT - dużych i małych - nie potrafią modelować systemów przy wykorzystaniu UMLa. Modelowanie architektury i designu systemów IT jest w pewnym zakresie sztuką. Nie każdy jest jednak artystą...

Temat: Dlaczego tak rzadko używa się UML w projektach IT?

Adrian O.:

Jarek Żeliński:
ale czy to nie przypomina argumentu: "po co mi lepszy silnik, który mniej pali, skoro jeżdżę tym co mam, paki dużo ale klienci płacą..."

Wszystko rozbija się o kontekst...

Czasem ten silnik, który się ma, pali tyle, że jest OK. Są samochody, które mają 75KM i 350KM. Czasem ma się samochód, który spala 12/100, a mógłby 9/100, ale nie stanowi to wielkiego obciążenia domowego budżetu, a inne zalety auta rekompensują spalanie. Zawsze można lepiej, zawsze można więcej, ale nie zawsze trzeba :)

Pytanie raczej dotyczy sytuacji, gdy faktycznie trzeba było, a nie - można było. I myślę, że dotyczy to konkretnego projektu. To jak z programowaniem - czasem programik można nastukać w VBA w Excelu (i zaprzęganie do tego "best practices" i "top tools" byłoby nie tylko przerostem formy nad treścią, ale i właśnie naciąganiem na zbędne koszty) i naprawdę wystarczy, a czasem trzeba stawiać hurtownię danych i zatrudniać "finalistów olimpiad programistycznych" (taki skrót myślowy).

Problem pojawia się wtedy, jak się naciąga klientów na koszta, których można było uniknąć przez stosowanie właściwego podejścia do problemu,a klient się na to godzi, bo się nie orientuje.

Symptomatyczne jest podejście wielu menedżerów i właścicieli firm IT. Jeden w przerwie konferencji zapytał mnie kiedyś wprost: "po co Pan takie rzeczy opowiada, nie lepiej jak prac za każdy protokół wykonanych prac????? "

A, tam, gdzie rządzi manager-od-słupków, który nie był nigdy "technicznym", za to często bywał na tzw. "szkoleniach" typu "wydaj-kasę-za-gadanie", to choćby Pan z siebie wyszedł..... :)

W przypadku UML'ach wszyscy mówia o kosztach i klient widzi tylko koszty związane z modelowaniem. Nie widziałem jeszcze nikogo, kto użytkowniko biznesowym potrafiłby wytłumaczyć w bardzo prosty sposób wytłumaczyć jakie korzyści będą wynikały z zastosowania UML i właściwego podejścia do modelowania.
Analogiczny problem napotykają konsultanci IT, gdy dochodzi z klientem do dyskusji na temat architektury systemu.

Temat: Dlaczego tak rzadko używa się UML w projektach IT?

Wojciech K.:
Szkoda tylko, że tak wiele osób uważa, że BPMN i UML to tylko obrazki. Nie rozumiejąc, że dostosowanie narzędzia, w którym wytwarza się analizę daje ogromne możliwości na przetwarzanie jej treści do najróżniejszych postaci np. "UKOCHANYCH EXCELi" .

Ogromne i ułatwiające życie. Ostatnio zakochałem się w możliwościach Enterprise Architecta w zakresie zarządzania wymaganiami (moja firma po prostu używa EA). Modyfikując specyfikację wymagań nie muszę edytować wielkiego dokumentu napisanego w Wordzie. Wystarczy zmodyfikować model i go na nowo wygenerować.
Dodatkowa godzina(y) architekta zaoszczędzona i Project Manager oraz klient też szczęśliwi.

Temat: Dlaczego tak rzadko używa się UML w projektach IT?

Marcin W.:
W przypadku UML'ach wszyscy mówia o kosztach i klient widzi tylko koszty związane z modelowaniem. Nie widziałem jeszcze nikogo, kto użytkowniko biznesowym potrafiłby wytłumaczyć w bardzo prosty sposób wytłumaczyć jakie korzyści będą wynikały z zastosowania UML i właściwego podejścia do modelowania.
Analogiczny problem napotykają konsultanci IT, gdy dochodzi z klientem do dyskusji na temat architektury systemu.

Bo tego się nie tłumaczy, to się pokazuje ..... a tak na prawdę największymi szkodnikami są Ci, którzy oferują analizę i projektowanie jako opcję w projekcie, wtedy klient po prostu - nie rozumiejąc - rezygnuje z elementów opcjonalnych.

Zawsze mówię klientom, ze analiza jako opcja świadczy tylko o tym, ze dostawca szuka dodatkowych dochodów w umowie czas i materiał i pzrerzuca 100% ryzyka na kupującego. Wystarczy wymusić umowę fixed-price... Drugi powód: jak można wycenić implementacje tego co nie zostało zaprojektowane? Kolejne oszustwo.

Mi wystarczy krotka rozmowa i albo klient "rozumie" albo faktycznie wierzy "innym firmom" i ryzykuje.