Temat: Dlaczego tak rzadko używa się UML w projektach IT?
Jarek Żeliński:
Paweł Grzegorz Kwiatkowski:
Często bywa tak, że "coś" już istnieje i jak do tego "czegoś" nagle zacząć stosować UML? Jeśli model już istnieje bądź tworzony jest od początku, to później można go rozwijać, ale co zrobić z istniejącą luką? Jaką wartość ma fragment modelu zrobiony przy okazji wprowadzania jakiejś funkcjonalności? Można rzecz jasna przeprowadzić analizę całości od 0, ale kto za to zapłaci / zainwestuje? Wydaje mi się, że w krótkim terminie koszty wprowadzenia UML na potrzeby konkretnego projektu wiążą się ze sporymi nakładami, które niekoniecznie muszą się zwrócić.
Istniejący już system, zamykamy jako czarną skrzynkę i definiujemy (budujemy) interfejs, nowe części projektujemy po nowemu jak trzeba...
podobnie jak tworzymy od zera modele procesów dawno istniejącej firmy by ją po protu zrozumieć (analiza biznesowa), tak czasem warto udokumentować logikę istniejąc od dawna systemu by go zrozumieć.
Dokumentowac - tak, ale niekoniecznie korzystajac z UMLa (a diagramy + strzałki, to przeciez nie musi byc UML). Mam wrazenie, ze to jednak odbieganie od podstawowego pytania, tj. dlaczego UMLa tak rzadko uzywa sie w projektach IT? Może to kwestia kiepskiej znajomosc tego narzedzia? Wydaje mi sie, ze to tak jak z katolicyzmem w Polsce, wiecej ludzi deklaruje niz praktykuje. I o ile zapytani o diagram cos tam powiedza, to w przypadku pytania np. o semantyke portu może pojawic sie zaklopotanie. Nawet jestli model UMLowy powstanie, to kto go później bedzie rozwijał? Znow pojawi sie
czarna skrzynka? ;) Czy proces biznesowy mozna opisac dobrze tylko w UMLu?
Po trzecie: jeżeli postawimy problem tak (cytuję) "w krótkim terminie koszty wprowadzenia UML na potrzeby konkretnego projektu wiążą się ze sporymi nakładami" to odpowiem: jak ktoś nie potrafi czegoś to faktycznie w krótkim terminie się nie nauczy i po prostu nie powinien się tej pracy podejmować.
O wiele prościej/szybciej/taniej jest "wystrugać" rysunki (za pomocą narzędzi klasy Excel/Paint... ;) ), które przekazują pewne idee niż stworzyć poprawny model.
czy mam rozumieć, że lepiej jest w krótkim czasie postawić szybko dom z gliny na ślinę zamiast uczyć się rysunku technicznego i stosowania właściwych materiałów? Chyba, że po tej budowie od razu ekipa wykonawcy ucieka na antypody do lasu....
Podazajac za przykladami budowlanymi, czy jest sens sprowadzac sprzet ciezki (buldozery, dzwigi,...), gdy klient chce tylko scianke dzialowa? I czy potrzebna jest deska kreślarska czy raczej inne narzędzia, np. poziomica? Innymi slowy, trzeba zachowac zdrowy rozsadek i dobierac narzędzia w taki sposób,by solidnie zrealizowac cel. Osobiscie uwazam, ze warto umiec poslugiwac sie rożnymi narzedziami i nie dac się zwariować, np. 'jestem mistrzem siekiery i kazdy problem jaki napotkam na swej drodze rozwiaze korzystając z tegoż narzędzia'. A UML to tylko narzedzie...
Reasumując, myślę że zależy to od dojrzałości organizacji
a moim zdaniem od uczciwości dostawcy, uczciwy developer powie, że domów z gliny się nie robi, nieuczciwy zrobi taki dom jak sobie klient zażyczy tanio.
i procesów wytwórczych.
raczej jakości ich efektów
Jeśli nie ma świadomości, że (byle)jakość kosztuje, to szuka się szybkich oszczędności, np. przez cięcia wydatków na szkolenia z UML, czy cięcia etatu kogoś kto będzie pilnował czy modele są tworzone, czy są poprawne itd.
to mogę zrozumieć u niedoświadczonych klientów ale nie pojmuje tego u wykonawców takich usług bo musiał bym uznać, że są właśnie takimi kanciarzami od kosztownych domów z gliny....
Zabrzmialo to jakby niestosowanie UMLa wynikalo z nieuczciwosci dostawców. Myślę, ze nie można w ten sposób generalizować. Szczerze mówiąc, nie spotkałem ani jednej firmy, w której byłoby podejście 'słuchaj, tu jest repozytorium, w repozytorium są modele, weź, zaktualizuj i wygeneruj szkielet i go uzupełnij - korzystamy w podejścia Model Driven Development, wdrożyliśmy wczoraj...', częściej 'repozytorium jest tu, jest tam dokumentacja, a UML? hmm, nie stosujemy UML. Mamy takie i takie standardy..'. Nie widzę też wartości dla klienta, posiadanie jakiegoś modelu UML w gąszczu black boxów. Żeby to miało sens, ktoś odgórnie powinien narzucić taki, a nie inny standard tworzenia dokumentów analitycznych bądź projektowych, a to wydaje mi się, że już temat o architekturze IT i dojrzałości przedsiębiorstw.