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.
Szczerze jestem ciekaw jak wyglądałaby analiza takich produktów jak np. system do przeliczania instalacji ciepłej/zimnej wody czy też centralnego ogrzewania. O ile można sobie pozwolić na takie szaleństwo projektowe przy pisaniu aplikacji stricte biznesowych (takich jak na przykład wystawianie faktur czy obsługa magazynu tudzież blogi) to programy obliczeniowe mają algorytmy na tyle złożone, że ich wyrażanie “na bloczkach” ma nikłe szanse powodzenia. W tym duchu chciałbym kiedyś zobaczyć jak narysować np. schemat działania sieci neuronowej w obrębie projektu obliczeniowego. Serio! Nigdy sie nad czymś takim nie zastanawiałem a może warto byłoby zobaczyć taki twór. Albo jeszcze ciekawsza rzecz i z pewnością bliższa każdemu: arkusz kalkulacyjny z jego mnogością wbudowanych formuł.
Nieco ponad rok temu pomagałem projektować system naliczania kar za emisje szkodliwych substancji. Oplata jest wynikiem zebrania w firmie (np. kopalnia, rafineria) danych o wszystkich emitujących urządzeniach, rodzaju substancji dla każdego oraz tego w jakich budynkach są zainstalowane. Do tego urządzenia te można przenosić pomiędzy budynkami a nawet placówkami danej firmy. Zaangażowano mnie, bo pracujący nad mega wzorem na wysokość kary i mega zapytaniem SQL informatycy zostali zjedzeni przez własny kod nad którym przestali panować (a nie byli to amatorzy).
Poza złożonością przepisów dochodzi to, że co roku liczba kar się zmienia, stawki są modyfikowane, pojawiają się nowe kary a do tego możliwe jest handlowanie na rynku zapasami limitów emisji. W dużym skrócie (wyniki pracy poufne bo to, oprogramowanie, produkt tej firmy) opracowałem model dziedzinowy oparty w zasadzie w 100% na DDD, testy poprawności możliwe były na diagramach zanim powstała choćby linijka kodu, wielkie złożone zapytania SQL zniknęły, a zamiast wielkiego wzoru na ostateczną wysokość kary pojawiła się sekwencja prostych metod,, których działanie polegało na “dogadaniu się” obiektów dziedziny odpowiedzialnych za wiedzę o emisji każdego emitującego obiektu. Każdy obiekt miał interfejs pozwalający na wprowadzanie ręczne danych i możliwość natychmiastowego przejścia na czytanie z czujników (system był w trakcie tworzenia).
To co opisałeś do właśnie doskonałe przykłady problemów, w których metody obiektowe i wcześniejsze ich projektowanie się sprawdzają, systemy biznesowe są “nudne” przy tego rodzaju problemach. Jednak nie zapominaj, że np. prognozowanie logistyki transportu to nie jest trywialny problem podobnie jak naliczenie wynagrodzenia w tym kraju (to także kiedyś uprościłem pewnej firmie z mega wzorów do prostych obiektowych sekwencji). Problemy biznesowe są złożone jako narzędzia dla ludzi i zapewniam, Cię że nie są trywialne ale faktycznie ciekawe wyzwania to systemy jak ten powyżej. I jest to wyzwanie w 100% projektowe a nie programistyczne (problem z naliczaniem wynagrodzeń to nie problem zakodowania a problem zaprojektowania jak to liczyć!).
W kwestii arkusza kalkulacyjnego (np. Excel) to w 100% obiektowe projekty, polecam strony MSDN, od pewnego czasu są bardzo kształcące: Microsoft od czasu jak powstał .NET stał się bardzo wysokiej klasy partnerem metod obiektowych (niestety nie biuro w Polsce). Polecam zacząć od tego: http://msdn.microsoft.com/en-us/library/dd409423(v=VS.100).aspx
“O ile można sobie pozwolić na takie szaleństwo projektowe przy pisaniu aplikacji stricte biznesowych (takich jak na przykład wystawianie faktur czy obsługa magazynu tudzież blogi) to programy obliczeniowe mają algorytmy na tyle złożone, że ich wyrażanie ?na bloczkach? ma nikłe szanse powodzenia.”
i problem w tym, że robi się to od dwóch dekad w przemyśle, z użyciem UML i potem jego rozszerzeniem SysML.
“Serio! Nigdy się nad czymś takim nie zastanawiałem a może warto byłoby zobaczyć taki twór.”
może w końcu warto zacząć.. 😉
https://www.sciencedirect.com/science/article/abs/pii/S1474034614000342
Być może błędnie pojmuję funkcję analityka systemowego, ale dla mnie projekt stworzony przez analityks musi wziąć pod uwagę zarówno wymagania funkcjonalnych, jak wymagania niefunkcjonalne (klienta) i (nasze) możliwości techniczne. Dobry projekt jest wypadkową tych czynników i powstaje w wyniku dialogu/iteracji między tymi czynnikami. Oczywiście na wysokim poziomie abstrakcji te czynniki mogą wydawać się odrębne, wszak trzeba jasno określić najpierw logikę biznesową (np. system ma sprawdzać czas na magazynie) i wymagania funkcjonalne (system ma to robić dla 2000 klientów na godzinię). Natomiast, szczegółowa specyfikacja techniczna powinna uwzględnia oba typy wymagań.
Joel Spolsky daje tutaj dobry przykład na podstawie swojego doświadczenia przy projekcie jako menadżer programu MS Excel (http://www.joelonsoftware.com/items/2009/03/09.html):
“The first thing I had to do was figure out what customers needed, which I did by talking to as many customers as I could until I started to get kind of bored because I kept hearing the same thing. I spent a lot of time talking to the development team to figure out what would be possible and reasonable to implement in a single 18 month release, and I spent a lot of time talking to the Visual Basic team to see if they could supply a compiler, code editor, and dialog box editor that could be used in Excel for our macro language.”
Być może trudno określić jedną granicę. Osobiście jestem zwolennikiem tezy, by na etapie analizy i projektowania powstała “wizja” rozwiązania, projekt nie ograniczony technologią (ale logicznie spójny). Teraz rola inżyniera: ma określić koszt i możliwość realizacji tej wizji. Po tej weryfikacji powstaje zakres projektu. Ten etap bywa nie raz nazywany “studium wykonywalności”. Moim zdaniem stawianie ograniczeń (nie raz bardzo subiektywnych) już na etapie analizy i projektowana prowadzi do powstawania tego co za Gierka (kto pamięta, lata 70-te :)) doprowadziło do tego, że wszystkie domki jednorodzinne były sześcianami ;).
Ale jedno jest prawdą: analityk projektant MUSI bardzo dobrze rozumieć technologię, której stawia wymagania.
te 2 linki w artykule nie działają
Pierwszy to:
dla moich klientów. Drugi to niestety strona mojego adwersarza, niestety już usunięta, zostały tylko cytaty w powyższym artykule.
autor chyba zawiesił działalność… 🙁
Rok później napisałem to: https://it-consulting.pl/autoinstalator/wordpress/2012/03/02/uml-process-czyli-od-biznesu-do-projektu-logiki-systemu/