Wstęp będzie na końcu…

Dla mnie model, diagram, rysunek nie jest niczym innym jak pustą obietnicą zrealizowania wymagań klienta.

A czym jest wobec tego, umowa?

dostarczony system po “reverse engeeneringu” kodu z powrotem do UML nie ma nic wspólnego z początkowym projektem

Sa dwa tego wytłumaczenia: projekt był zły lub wykonawca zignorował projekt.

Model jest obietnicą bez pokrycia

To niestety jest jednak tezą subiektywną, wypadało by dodać “mój model”, “model” i tu jego autor. Testując kształt samochodu czy samolotu w tunelu aerodynamicznym także powiemy, że model jest obietnica bez pokrycia?

Ja lubię odwoływać się w tym momencie do Biblii (sic!). Jak wiemy tworzona była w różnych językach i narzeczach, następnie przetłumaczona na grekę i później na łacinę. Jeśli przyjrzymy się jej wersji w języku polskim tłumaczonym z greki i łaciny, dostaniemy dwa dokumenty, które różnią się w kilku kluczowych fragmentach, a których interpretacja przez biblistów wywołuje gorące dyskusje i kontrowersje. Dla mnie droga od modelu do działającego systemu jest niczym innym jak translacją, procesem w którym giną szczegóły stanowiące o kompletności systemu.

To porównanie mnie dziwi, a nawet wcale nie jeśli brać pod uwagę kto się tym porównaniem posłużył. Biblia to niespójny dokument wielu autorów, wybór z pośród większej liczby pism. Jest dokładnym odpowiednikiem najgorszych praktyk w projektach, gdy dokumentacje tworzy zespól pisarzy a dokument wynikowy jest dziełem kierownika projektu, którego pobudki są raczej polityczne niż merytoryczne. Jednak Biblia nie musi być spójna, w przeciwieństwie to projektów.

Co do analogii do samolotów, która jest mi szczególnie bliska ze względu na moją obecną firmę chciałbym zauważyć, że zanim pierwszy samolot braci Wright wzbił się w powietrze, historia lotnictwa pamięta cała masę prototypów, które upadły nisko, zanim kolejny z nich wzbił się w powietrze…

Hm… czyżby autor, powołując się na ten przykład, tkwił w tamtych czas ze swoim podejściem do tworzenia oprogramowania?

“model – system założeń, pojęć i zależności między nimi pozwalający opisać (zamodelować) w przybliżony sposób jakiś aspekt rzeczywistości.” (źr. wikipedia)

Przykro, ja już wyrosłem ze społecznych źródeł wiedzy jakim jest Wikipedia i przytoczę definicję z książek mających konkretnego autora, Yourdon (celowo ten Pan, to facet znany u programistów) pisze:  “model to uproszczenie rzeczywistości”. Polega to na skupieniu się na rzeczach istotnych w kontekście badanego problemu (polecam także Sienkiewicz, Analiza Systemowa, tam opis analizy i dowodzenia tez metodą testowania modeli). Tak więc model procesu, to to, co robi Pan księgowy z zaniedbaniem koloru jego garnituru.

Jestem też ogromnie ciekaw jak wygląda testowanie diagramów i modeli UML? Przyznaję, że w tym obszarze jestem kompletnym ignorantem i być może przespałem któreś spotkanie w firmie.

Nie wiem co kolega przespał, jak i do czego się nie przykładał, ale modele się testuje. Polecam: Sienkiewicz, Analiza systemowa, materiały na ,  oraz kilka “skrótów” https://it-consulting.pl//?s=dla+moich+klient%C3%B3w+. Testowanie opisaniem tu: UML proces…

Jestem ciekaw co stoi za masą “kiepskich analiz” i “bełkotu”? Moim zdaniem dwie proste przyczyny.Pierwsza to niejednoznaczność modeli do modelowania (czytaj meta-języków). Przy pomocy “przybliżonego opisu” opisujemy “przybliżony aspekt rzeczywistości”.

Hm.. nie wiem co mam powiedzieć, oprogramowanie nie odtwarza żadnej rzeczywistości a jej opis, jeśli oczywiście pominiemy gry komputerowe. Dobry program ma klasę UserInfo a nie User. User siedzi przed komputerem. Owe kiepskie analizy (bełkot) to próby opisania niejednoznaczną prozą czegoś, co (kod w jakimś języku programowania) potem przepuścimy przez kompilator.

Druga przyczyna to testowanie modelu. Ale tutaj oddaje się całkiem w ręce mego adwersarza i czekam na promyk nadziei. Skoro mój oponent potrzebuje kartki papieru i 1000zł na przetestowanie, to dlaczego dostaję taką ilość “bełkotu”?

Tu jednak sprawdzają się słowa, mojego przyjaciela programisty, który mnie bardzo uczy pokory mawiając, Jarek ja nie czytam ja programuję. Owo testowanie i 1000zł dotyczyło (co podtrzymuję) jednego, przeciętnie złożonego i opracowanego już,  przypadku użycia.  Nie będę jednak się rozwijał z tłumaczeniem co znaczy “przeciętnie złożony”.

Autor na zakończenie spisał niemalże memoriał, którego tu nie będę cytował. Wbrew posądzeniom czytałem cały jego artykuł (może to mnie jednak pogrąża).

A teraz wstęp

Na stronie http://primitive.jogger.pl/2011/05/23/porzadnie-mi-sie-oberwalo/, jej autor broni się przed moimi zarzutami jakie miałem do tego co napisał (odnośniki do moich tekstów są na jego stronie).

Powyższe to cytaty i moje komentarze. Ostatni cytat:

gdy testowany diagram sekwencji w kontekście ołówka i papieru nie wytrzymuje zderzenia z rzeczywistością tysięcy zapytań na sekundę, przy ograniczonej, skończonej, przepustowości sieci nie wińmy programistów. Bo łatwo jest umyć ręce od odpowiedzialności, jednak ja wierzę w tzw. “ownership” i jednakową odpowiedzialność za dostarczony produkt na każdym poziomie drabiny produkcji oprogramowania

powalił dość mocno moją wiarę w tego programistę. Dlaczego? Bo szkolną (podobno)  wiedzą jest to, że wymagania funkcjonalne, czyli logika biznesowa systemu, oraz wymagania pozafunkcjonalne takie jak wydajność, to odrębne rzeczy. Testowanie logiki biznesowej systemu z pomocą diagramu sekwencji to testowanie logiki, wydajność, owe tysiące zapytań na sekundę to wymagania pozafunkcjonalne.  Tak wiec jeżeli ktoś myli testowanie tego czy wystawienie faktury się uda na bazie zawartości magazynku i rejestru klientów z tym ile tych faktur będzie tworzonych na sekundę, to ja nie wiem co mam powiedzieć…

Na zakończenie dodam coś do manifestu: ludzie, szanujmy na wzajem swoje kompetencje bo bez tego nie da się współpracować. Po drugie, nie tylko w kontekście owych modeli, których kolega nie doświadczył: to że ktoś nigdy nie widział czarnego łabędzie nie stanowi żadnego dowodu na jego nieistnienie. Dodam od siebie: to że ktoś czegoś nie potrafi nie znaczy, ze to nie możliwe. By nie budzić zbędnych emocji: obecnie nie potrafię już dobrze programować (co by to nie miało znaczyć) ale w swym rozsądku nie neguję istnienia oprogramowania.

Jakie to było piękne gdy do mojego mieszkania wpadła ekipa remontowa: Pani projektant oraz stolarz, murarz i hydraulik. Pani projektant wypytała mnie co na co dzień robię w pokoju, łazience, sypialni i narysowała to czego powinien się spodziewać po remoncie. To był załącznik do umowy z fachowcami. Ci zaś, zamiast psioczyć na pomysły Pani projektant, wysilili swoje inżynierskie umysły i z kilkom drobnymi korektami, stworzyli to co zostało narysowane. Nie odwodzili mnie od malowania pod kątem w dwa kolory szafy, nie wmawiali mi, że nikt tak nie robi. Tego od nich oczekiwałem… szacunku fachowców dla Pani projektant i szacunku Pani projektant dla fachowców. Jej doświadczenie i znajomość ograniczeń technologii budziły podziw. Ale projektując chodzi o ograniczenia technologii a nie ludzi.