Obawiam się, że temat jakości procesu tworzenia oprogramowania to „never ending story” :). Ścierają się z sobą poglądy o tym czy to co sponsor projektu chce jest dobre czy złe, kompletne czy niekompletne itp.. a tak na prawdę moim zdaniem problem tkwi w tym, czy się to (tworzyć oprogramowanie) potrafi robić czy nie. Podobnie jest każdej innej dziedzinie.
Dzisiaj co nieco o formalizmach i o tym, że „od dawna wiadomo jak wytwarzać dobrej jakości oprogramowanie” tylko to wymaga pewnej wiedzy i umiejętności. Nie należy się bać, będę pisał do czego te formalizmy służą bez wnikania w nie, więc nie tylko zawodowcy „z branży” sa adresatami tego tekstu :). Na początek jednak mała uwaga może raczej przypomnienie dla uporządkowania wiedzy. Każdy projekt biznesowy, a wdrożenie oprogramowania wspomagającego zarządzanie do takich należy, to:
- postawienie problemu.
- zrozumienie przyczyny problemu,
- opisanie sposobu rozwiązania problemu,
- zaprojektowanie narzędzia wspomagającego rozwiązanie problemu.
I dalej. Dobre oprogramowanie to takie, które pomaga w rozwiązaniu problemu lub, czasami, nawet go rozwiązuje. Problem polega na tym, że umiejętność tworzenia rozwiązań technicznych nie oznacza umiejętności rozwiązywania problemów biznesowych. Dlatego dobry programista nie oznacza powstania dobrego oprogramowania. Ktoś wcześniej musi zidentyfikować problem (cel) i opracować rozwiązanie. Powyższe cztery punkty to etapy projektu. Jeżeli to projekt programistyczny to mamy odpowiednio:
- identyfikacja celu projektu,
- analiza biznesowa,
- specyfikowanie wymagań,
- wykonanie i implementacja.
Ścierają się zwolennicy tezy, że wszystko jest prostym rzemiosłem, które każdy może wykonać (w końcu podobno nie święci garnki lepią) z tezą, że ludzie dzielą się jednak na rzemieślników i artystów. Zwolenników drugiej tezy pozdrawiam, tych pierwszych zaś pytam: dlaczego ludzie tak wybrzydzają szukając np. fotografa na swój ślub zamiast dać aparat szwagrowi, niech pstryka?
Jakiej wiedzy i jakiej umiejętności tu potrzeba i brakuje jednocześnie? Zacytuję jeden z poprzednich artykułów (to wynik ankiet):
Przyznajemy jednak, że diagramy najlepiej wyjaśniające (uzupełniające) wątpliwości związane z wymaganiami to modele procesów i prototypy, jednak nie stosujemy ich. (Raport: Zarządzanie wymaganiami 2011)
Powyższe cztery etapy omówię dalej, w kontekście projektów wytwarzania oprogramowania.
Proces tworzenia oprogramowania czyli gdzie to modelowanie
(BIZNES ten rozdział można pominąć)
W 1989 roku (tak!) powstało OMG (Object Management Group). Jest to konsorcjum (obecnie ok. 700 członków), którego celem jest promowanie i standaryzacja obiektowych metod w inżynierii oprogramowania (nie tylko w kodowaniu/programowaniu o czym wielu zapomina!). Między innymi wzięło pod swoje skrzydła notację BPMN (modelowanie procesów biznesowych) i UML (modelowanie systemów w paradygmacie obiektowym). Ale nie tylko notacjami się OMG zajmuje. Jednym ze standardów (i dobrych praktyk) promowanych przez OMG jest proces MDA (Model Driven Architecture), jest to proces tworzenia oprogramowania dla biznesu, oparty na modelowaniu. Nie należy tu mylić procesu tworzenia oprogramowania z projektem tworzenia oprogramowania (to różne rzeczy).
Jak wygląda MDA?
Cały proces tworzenia oprogramowania ma tu cztery fazy:
- opisanie tego czemu będzie to służyło (model CIM, model organizacji, dla której powstanie oprogramowanie, na tym modelu wskazywany jest zakres projektu i nie ma na tym modelu żadnej technologii!),
- opisanie co i jak to oprogramowanie będzie robiło (model PIM, model logiki biznesowej, która zostanie – to jest cel projektu – odtworzona w tym oprogramowaniu),
- opisanie tego jak wykonać to oprogramowanie (model PSM, model kodu, który powstanie, tu wzorzec MVC: zakładamy, że warstwy View i Controller już istnieją tu model PIM to Model),
- wytworzenie kodu programu (tu mieści się także planowanie użycia gotowych, dostępnych na rynku komponentów, tak zwanych [[COTS ang. commercial off the shelf]], użycie frameworka/szkieletu MVC to także COTS))
(MDA sugeruje automatyzacje tego procesu ale to jest raczej jeszcze przed nami)
Praktyka pokazuje, że największym ryzykiem jest przejście z CIM do PIM bo nie istnieje jednoznaczne mapowanie CIM-PIM (zamiana wiedzy biznesowej na programistyczną). I tu z pomocą przychodzi praktyka (zbiór zaleceń, wzorce itp.) DDD, która mówi: skoro jest problem z mapowaniem to modelujmy tak, by mapowanie nie było potrzebne! Modelujmy (analizujmy) tak, by rola projektanta oprogramowania (Analityk Systemowy) stała się zbędna. To się da zrobić pod warunkiem, że Analityk Biznesowy poza procesami, zacznie modelować także „oprogramowanie” (w zasadzie przejmuje tu, pełni także, rolę Analityka Systemowego). Jak? Po swojemu! Swoim językiem! Ale jak to potem przekazać programistom? Należy model biznesu wykonać metodami obiektowymi (DDD i ubiquitous language)! Wykonać ten model tak, by był niejako symulacją bzinesu (tak, prawie jak gra komputerowa). W końcu po to tak na prawdę powstały obiektowe języki programowania (a nie po to by klasami opakować kod;)).
Gdyby to się udało to:
- Analityk Biznesowy staje się zarazem projektantem części oprogramowania opisującej logikę jaką ma ono realizować.
- Zbędne staje mapowanie PIM-PSM bo model PIM staje się częścią PSM (tworzenie modelu PSM to tylko „opakowanie” logiki biznesowej PIM elementami sterowania, bezpieczeństwa, interfejsami itp., przypominam, że to ponad 90% kodu!.
- Architektowi systemu w zasadzie pozostaje opracować kompletny model PSM (owe brakujące ponad 90% kodu!), zaplanować jego implementację i wykonać ją.
Tak więc DDD to sposób na wyeliminowanie z procesu wytwarzania oprogramowania najbardziej ryzykownego etapu: przełożenia wiedzy biznesowej (procesowej) na systemową (obiektowa). Niestety DDD jest często traktowane jako „kolejny sposób programowania” co postrzegam jako poważny błąd, i nie tylko ja:
Domain Driven Design is an approach that describes the approach to designing the business layer. It doesn?t say much about the other layers of an application. The main advice is to base the domain model on the language your customer uses: the ubiquitous language. This means that you should not have a method ?setAddress? on a Customer instance if your customer talks about ?register a relocation?. In fact, the last application I developed hardly contained any setter on any domain instance at all. (źr. The misunderstanding of Domain Driven Design ? Dutchworks Blog / Dutchworks: Enterprise Java, Open Source, software solutions, Amsterdam.)
Tak więc jest metoda. Praktyka pokazuje, że sprawdza się. Praktyka pokazuje także, że niestety nie jest to łatwe (modelowanie biznesu metodami obiektowymi, tu niestety nie da się powiedzieć, że „nie święci garnki lepią”) dlatego powstały pewne zalecenia i wzorce projektowe. Należy je zrozumieć, nauczyć się stosować i stosować, co i tak nie zastąpi „projektowania” czyli twórczego pierwiastka w tym procesie. Dokładnie tak samo jak nie da się automatycznie tworzyć kodu programu, do tego potrzebni są (dobrzy) programiści.
Z przekorą powiem też, że nie wiem jak zwinność metod programistycznych ([[Agile Manifesto]]) miała by ten proces uzdrowić i uczynić lepszym (nadal uważam, że brak dokumentacji, w tym opisanych modeli, raczej psuje projekty co potwierdza praktyka: ponad 70% projektów to wpadki i jednym z głównych powodów był brak dokumentów opisujących biznes i prototypy oprogramowania).
Polecana literatura (niestety w j.ang.):
Na zakończenie
Podsumowując można by powiedzieć, że etapy tworzenia oprogramowania to:
- Analiza biznesowa, której produktem są: model organizacji (model biznesowy) oraz opis tego co ma powstać (opis, wymagania na oprogramowanie). Całość (sformalizowane modele) pozwala na przetestowanie czy tak określone wymagania spełniają potrzeby biznesu.
- Wytworzenie oprogramowania polegające na: opracowaniu szczegółów architektury, rozwiązaniu problemów technicznych (wymagania niefunkcjonalne), kodowaniu oraz dostarczeniu i wdrożeniu.
Powyższe, tak udokumentowany projekt, pozwala także osiągnąć dodatkową korzyść: „wiedza organizacji” tkwi w wykonanym dokładnie opisie rozwiązania (modelu PIM) i developer (wykonawca, dostawca oprogramowania) nie może przejąć tej wiedzy (projektu) bez zgody autora, Analityka Biznesowego i sponsora projektu (prawo autorskie, na wszelki wypadek nie zlecaj jednak developerowi projektowania). Jest to sytuacja analogiczna do budowy domu i jego projektu: murarz nie może przejac projektu bo nie jest jego autorem co nie przeszkadza mu do zrealizować.
Dodam po raz kolejny: nie ma tu żadnego znaczenia to czy jest to projekt dedykowany w całości czy dostarczenie gotowego oprogramowania z elementami dopasowania (kastomizacja). Gotowe oprogramowanie (w wielu projektach biznesowych i tak dopasowywane) to po prostu gotowe komponenty oraz nowe, dedykowane moduły. Dlatego piszę: nie „kastostomizuj”, opisz to co potrzebujesz, sprawdź czy coś gotowego na rynku tu pasuje a jeśli tak to kup to, wykonaj brakującą resztę.
„Nie należy tu mylić procesu tworzenia oprogramowania z projektem tworzenia oprogramowania (to różne rzeczy).”
vs
„Z przekorą powiem też, że nie wiem jak zwinność metod programistycznych (Agile Manifesto) miała by ten proces uzdrowić i uczynić lepszym”
🙂
Chyba znowu nastąpiło pomieszanie pojęć ?
Dlaczego?
Ponieważ Agile to metodyka zarządzania projektami a MDA modelowania programowania. Agile mówi jak zarządzać procesem powstawania oprogramowania, jak radzić sobie z ryzykami i problemami (z czasem, zakresem, budżetem). MDA mówi (formalizuje) o tym tworzyć modele i diagramy i jak przejść z jednego modelu (diagramu) do drugiego.
MDA skupia się na formalizmach i dokumentacji, zaś Agile na efektywnym zarządzaniu procesem.
Żeby dobrze podświetlić różnice to nigdzie nie jest zabronione używanie MDA w Agile 🙂 Oczywiście będzie to wbrew idei lekkości, ale jeśli MDA komuś „ciężkie” nie będzie to nic nie stoi na przeszkodzie. Jedynymi wyznacznikami czy coś jest zwinne są” ilość pracy i czas.
mam na myśli co innego: skoro badania wskazują na to, że tworzenie zrozumiałych i przemyślanych modeli (prototypów) to droga do sukcesu a Agile mówi, że zamiast modeli i analiza „rozmowy z klientem i dążenie do celu” to jak to rozumieć? Pomieszania pojęć nie ma: MDA i projekty to dwa różne światy, bo Projekt nie spełnia definicji procesu – proces jest z definicji powtarzalny a projekt jest z definicji unikalny 🙂 czyż nie? Tak więc ja MDA z projektami w ogóle nie mieszam… Dodać wypada, że faktycznie MDA z natury nie jest Agile (w rozumieniu opisanym w Agile Manifesto).
„…a Agile mówi, że zamiast modeli i analiza ?rozmowy z klientem i dążenie do celu? to jak to rozumieć? ”
Nie słyszałem, żeby Agile coś takiego mówiło. Agile wręcz stawia na ciągłą analizę i minimalizuje gadanie.
„proces jest z definicji powtarzalny a projekt jest z definicji unikalny czyż nie?”
Nie. Proces może być unikalny i projekt może być powtarzalny – tego nie blokują definicje w IT i tak wynika z mojego doświadczenia w kilkudziesięciu projektach.
„Dodać wypada, że faktycznie MDA z natury nie jest Agile (w rozumieniu opisanym w Agile Manifesto).”
Oczywiście, że nie jest bo to coś całkiem innego – ale o tym już pisałem 🙂
proponuję:
stronę http://agilemanifesto.org o Agile, co do definicji projektu i procesu pozostanę przy klasycznych, wymyślanie swoich nowych prowadzi do utraty komunikacji. Ja nie używam „swoich” definicji, to ułatwia wymianę myśli… że nie wspomnę o jakości dokumentacji (każdej treści). Jeżeli uważa Pan, że projekt to rzecz także powtarzalna a proces to także unikalna to uznaję, ze wymieniliśmy poglądy i dalsza dyskusje nie jest potrzebna. Dalej: jako, że jestem gorącym zwolennikiem jakości dyskusji tworzonej poprzez imienne podpisywanie się, wracam do tego zwyczaju gdyż tak rewolucyjne treści powinny być imiennie zgłaszane.
Od tego momentu tylko podpisane imiennie wypowiedzi będą akceptowane.
polecam bardzo ciekawy artykuł umieszczający metodykę Agile (SCRUM) w procesie TPM (RUP).
Jak zawsze powtarzam – nie ma nic złego w Agile, jeśli potrafisz go używać. Jak każde narzędzie sprawdza się w obszarze swojego zastosowania.
Prawdopodobnie serie nieporozumień biorą się stąd, że faktycznie nie raz nie mówi się wprost czy słowo Agile w wypowiedzi dotyczy zarządzania projektem czy procesu wytwórczego oprogramowania … ja deklaruję to drugie 🙂
Ok. Jeśli mówimy o definicjach to:
Ja też polecam Panu wczytanie się w manifest http://agilemanifesto.org i poszukanie wzmianki o ?rozmowy z klientem i dążenie do celu?
Oraz pierwsza z brzegu definicja procesu : http://pl.wikipedia.org/wiki/Proces
i projektu: http://pl.wikipedia.org/wiki/Projekt_(zarządzanie) – proszę zwrócić uwagę, że unikalność w projekcie odnosi się nie do samego projektu tylko do produktu/celu projektu.
Oczywiście te obie definicje są ogólne i nie odnoszą się do IT, ale coś już mówią o tych terminach.
Mnie nie interesują definicje, a konkretne zastosowanie w praktyce, dlatego pozdrawiam starym krótkofalarskim OVER 🙂
Pozdrawiam
Jacek Wojtkowski
Co do definicji projektów polecam PMI/Privce2, co do definicji procesów raczej literaturę z zakresu zarządzania, Wikipedia, nie tylko na uczelniach, jest niepoważnym źródłem wiedzy … i nie chodzi już o udowadnianie prawd, a po prostu o nie wymyślanie od nowa tego co już raz wymyślono (brzytwa Ockhama…).. Over
I znów temat jest sprowadzany do dyskusji o/nad Agile. Co do ?od dawna wiadomo jak wytwarzać dobrej jakości oprogramowanie?, to od dawna wiadomo, że nie istnieje jedno uniwersalne podejście.
Przewrotnie trochę, cieszę się że podejście „klasyczne” znajduje na tym blogu ostoję. Redefiniowanie, po raz nie wiadomo który, podstawowych pojęć, w obawie, czy zbaczają odrobinę od obowiązującego nurtu (a tam gdzie ja żyję, obowiązuje agile), przyprawia mnie już o tiki nerwowe.
Z przyjemnością czytuję artykuły, ze świadomością, że chociaż z niektórymi pomysłami nie zgadzam się (może tylko w szczegółach), przekazują one solidny ładunek wiedzy o tworzeniu oprogramowania.
Co mnie mocno zastanawia, to koncepcja ochrony własności intelektualnej klienta, przez separowanie go od dostawcy oprogramowania. Hmm. Skądinąd wiem, że koncepcje zarządzania, organizacji procesów, nie podlegają ochronie prawnej, nie można ich patentować. Mam też przekonanie, że transfery pracowników są wystarczająco szerokim kanałem, przez który najbardziej skrywane koncepcje mogą się przedostać.
Jeżeli Klient obawia się nieuczciwego Dostawcy, to jak Analityk zdobywa zaufanie takiego klienta? Czy Analityk, po długotrwałym procesie odkrywania, razem z Klientem, szczegółów jego potrzeb, jest w stanie wyrzucić ten bagaż z pamięci, tak aby jakieś rozwiązania nie prześliznęły się do kolejnego projektu?
Wiele moich postów to „poprojektowe” przemyślenia. I po kolei kilka „tłumaczeń”.
Agile: to moi klienci patrząc u siebie na „krajobraz po bitwie” krytykują zwinne podejście jakie na nich ćwiczono, ja raczej tu tylko wyrażam te opinie. Z mojej strony mogę stwierdzić: nie potrafię obronić Agile u klientów, u których „po bitwie” nie zostało nic poza rozgrzebanym, mało-przydatnym systemem i żalem. Bo śladów po analizach, koncepcjach itp. możliwych do powtórnego użycia nie ma, a za analizę cudzego kodu nikt nie chce się łapać. Tezy, że kod dokumentuje projekt nie sprawdzają się.
Moje, i nie tylko moje klasyczne podejście, po protu się sprawdza i tyle tylko mogę powiedzieć. W kwestii „od dawna wiadomo jak wytwarzać dobrej jakości oprogramowanie? to tylko literatura (E.Yourdon i nie tylko) i doświadczenie.
W kwestii ochrony własności intelektualnej. Niestety znowu podnoszą ten problem klienci: oszukani lub w inny sposób wykorzystani w drenażu wewnętrznej wiedzy. Nie patentuje się „koncepcji”, ale prawo autorskie chroni „szczegółowy opis algorytmu” zaś tajemnica przedsiębiorstwa obejmuje „specyficzne metody pracy” bo czym są pieczołowicie wypracowywane reguły biznesowe? Klasycznym przykładem są systemy scoringowe banków: są pilnowane bo nie raz stanowią o przewadze rynkowej. I nie chodzi o to, że jakaś koncepcja wyjdzie wraz z byłym pracownikiem. Rzecz w tym, że ona i tak nie może stanowić przedmiotu projektu ani umowy. To jak z muzyką: co z tego, że ktoś skopiuje moje nuty skoro i tak nie może mojego utworu legalnie publicznie wykonywać bo naraża się na konsekwencje.
Analityk zdobywa zaufanie nie tym, że szybko zapomina lub obiecuje, ze zapomni. Analityk zdobywa (może) zaufanie a tym, że w umowie zapisuje przekazanie praw majątkowych Zamawiającemu do wszystkiego co u niego i dla niego zrobi. Nie chodzi o to, że coś wiem. Chodzi o to, że to co wiem nie może być publicznie oferowane na rynku.
Kilka moich ostatnich dyskusji z firmami programistycznymi i także z prawnikami, zaowocowały tym tekstem:
http://it-consulting.pl/autoinstalator/wordpress/prawa-autora-analizy-i-ochrona-know-how-organizacji-analizowanej/