🚀 go-pugleaf

On Fri, 12 Mar 1999 11:54:24 +0100, Kazimierz Subieta
<subieta@ipipan.waw.pl> wrote:

>
>
>Artur Kasprzyk wrote:
>
>> Tak jest. Od dawna twierdze, ze ludzie myla notacje z metodologia,
>> szczegolnie w narzedziach CASE. Nie mialem w swoim zyciu przypadku,
>> aby przy projekcie stosowal jakas precyzyjna metodologie.
>>
>> Za malo :-) Gdyby Pan zastosowal sie do metodologii i polozyl trzy projekty,
>> wówczas bylby to argument za stwierdzeniem Pana Lewandowskiego.
>>
>> Uzywalem
>> po prostu notacji takich, jakie mi byly aktualnie potrzebne do przedstawienia
>> lub objasnienia danej sprawy.
>>
>> Prosze sie postawic w roli firmy, ktora wyrosla na podejsciu "na hura", i nagle
>> zetknela sie z wiekszym projektem, w ktorym musi poprowadzic formalna analize,
>> w jakiejs notacji i w jakims narzedzi do modelowania. Czy nie sadzi Pan, że duza
>> róznica dla nich bedzie otrzymanie metodologii nizli jedynie notacji ?
>
>Sytuacja jest mniej wiecej nastepujaca. Firmy, z ktorymi sie zetknalem, stosuja
>pewien wlasny przepis postepowania przy projektowaniu, wypracowany przez
>lata, obudowany formularzami i konwencjami, uwarunkowany wczesniejszymi
>doswiadczeniami i wiedza ludzi, ktorzy w nich pracuja. Czasami ten sposob
>postepowania nazywaja "metodyka", czesto pilnie go strzega przed konkurencja
>uwazajac go za dorobek sprzyjajacy powodzeniu firmy. Czesto chwala sie, ze
>ich metodyka jest oparta na OMT, Coad/Yourdon,... ale tak naprawde stosuja
>wlasna metodyke oraz elementy notacji OMT, Coad/Yourdon, etc..
>Metodyki (takie jak OMT) sa moim zdaniem idealistyczne, za malo precyzyjne
>i przywiazane do typowego, wyobrazanego przez ich tworcow procesu
>projektowego. Rozne uwarunkowania powoduja, ze nie odpowiadaja one
>czesto realnym sytuacjom. Zgodzic sie jednak nalezy, ze takie metodyki mozna
>uwazac jako case study, pozwalajace na wypracowanie wlasnej metodyki
>lepiej przystajacej do aktualnej sytuacji danej firmy.
>

Dobrze powiedziane...

>Chcialbym rowniez zwrocic uwage, ze notacja taka jak UML, to nie jest "tylko
>notacja". Kazdy jezyk, w tym UML, ma trzy strony: skladnie, semantyke
>i pragmatyke. Autorzy UML precyzuja skladnie, ale pod powierzchnia ich
>wysilkow tkwi semantyka (co te diagramiki znacza), a jeszcze glebiej tkwi
>pragmatyka (do czego je mozna zastosowac i po co). Jezeli wezmiemy
>te wszystkie strony UML i porowna np. z VDM, Design By Contracts, czy
>innymi tego rodzaju tworami, to latwiej dostrzec, ze w istocie UML okresla
>pewna metodyke postepowania i dotyczy wylacznie pewnej klasy projektow.
>Nie jestem np. pewny, czy nadaje sie do projektowania systemow
>uwarunkowanych czasowo, protokolow komunikacyjnych,
>rozproszonej relacyjnej bazy danych, czy tez monitora transakcji.
>W tym sensie napisalem, ze UML ma ograniczenia (jak zreszta wszystko).
>

Design by Contract nie jest metoidologia. Poza tym, dowolna notacja
ikonograficzna na semantyke i pragmatyke. Wezmy np. znaki dorgowe czy
schematy elektroniczne. UML tez. Tylko co z tego? 

Schemat elektroniczny czy rysunek mechaniczny jest KOMPLETNYM i
CALKOWITYM opisem systemu. Specom od oprogramowania marzy sie cos
takiego. Tyle ze UML nie jest completnym i calkowitym opisem systemu -
schemat UML musi byc poparty obszerna literatura, albowiem nie mowi on
"sam za siebie". Nie da sie zaimplementowac systemu na podstawie
diagramu UML. Jest to podstawowe ograniczenie wszystkich "notacji"
wymyslonych dla inzynierii programowania.

>> A na zakonczenie - co konkretnie nie podoba sie Panom w metodologiach:
>> * pisza bzdury ?
>> * pisza rzeczy niezgodne z Panow doswiadczeniem ?
>> * pisza rzeczy szkodliwe spolecznie ?
>> * pisza rzeczy oczywiste, o których ucza w przedszkolu ?
>> * wprowadzaja zbytni formalizm ?
>
>Nie wiem jak Pan Lewandowski, ale ja nie jestem przeciwnikiem
>metodyk i UML. Dostrzeganie slabych stron rzeczy
...
>Jezeli p. Lewandowski mowi, ze metodyki to zwykly pic, to
>(w moim odczuciu) chce wyrazic fakt, ze argumenty na rzecz
>stosowania danej metodyki nie sa wiarygodne, zas wojna
>na te argumenty zbyt czesto sprowadza sie do zwyczajnego
>pustoslowia i demagogii.
>

Metodyki wziely sie z glebokiego przekonania o mozliwosci stworzenia
"magicznego zaklecia" ktore rozwiaze wszystkie problemy. To zas
przekonanie generowane jest przez tabun niekompetentnych idiotow
ktorzy przez pomylke znalezli sie w inzynierii programowania. Grupa
cynikow zeruje na owej wierze wypuszczajac coraz nowe "metodologie".
Prawda zas jesty taka: inzynieria programowania jest INZYNIERIA i
stosuje sie do niej te same prawa co do, na przyklad, inzynierii
mechanicznej. Zeby zostac inzynierem mechanikiem trzeba sie dlugo
uczyc i dlugo praktykowac. Potem zas sie jest inzynierem takim sobie,
inzynierem dobrym lub inzynierem genialnym i stosownie do mozliwosci
swojego umyslu zajmuje sie odpowiednie stanowisko. Zareczam, ze
samolot Boeing 777 czy F-114 "Stealth" nie zostal zbudowany w oparciu
o "metodologie projektowania odrzutowych samolotow wojskowych", a
wlasnie przez owych genialnych i bardzo dobrych inzynierow.

W "inzynierii" programowania wystarczy umiec liczyc do 4 i skonczyc
tygodniowy kurs w rodzieju "jak zostac expertem od komputerow w ciagu
tygodnia nie przerywajac snu" i juz sie jest INZYNIEREM. Tyle tylko,
ze gdy przyjdzie cos zaprojektowac, rozgladamy sie za metodologia,
czyli krotko mowiac, SCIAGAWKA lyb BRYKIEM.

A jak idzie o cynicznosc... Przez wiele lat zajmowalem sie systemami
wspomagania decyzji oraz teoria decyzji. Niekwestionowanym "guru" w
tej dziedzinie jest profesor Howard Raiffa. Kiedys w instytucie gdzie
pracowalem profesor Raiffa mial wyklad dla mlodych adeptow sztuki.
Wykladal przeglad teoriii decyzji. Gdy przyszlo do zadawania pytan,
mlody czlowiek zapytal z szacunkiem: "Profesorze Raiffa, a jaka teorie
pan stosuje gdy kupuje pan samochod?". "Teorie?" oburzyl sie Raiffa.
"Jaka teroie?! Zadna teorie! TO SA MOJE PIENIADZE!!!".

Znam tylko jeden projekt gdzie metodologia naprawde zostala
zastosowana i odniosla sukces. Bylo to w bardzo duzej firmie
telekomunikacyjnej ktora ze wzgledow propagandowych nie mogla sobie
pozwolic na luksus nie uzywania metodologii. Na szczescie management
byl na tyle madry, ze umiescil grupe "metodologiczna" w osobnym
budynku oddzielonym od budynku wlasciwego autostrada. Zeby sie tam
dostac trzeba bylo jechac 5 kiolmetrow. Grupa metodologiczna z grupa
programistyczna nie byla nawet polaczona e-maijlem, obie grupy nie
eiedzialy o swoim istnieniu i nigdy nie wymienilu kawalka papieru.
Projekt zakonczyl sie sukcesem.

A.L.