Pisząc doktorat postanowiłem zacząć tu cykl artykułów na temat analizy, modelowania i projektowania czyli tego jak od pierwszej rozmowy dobrnąć do … no własnie. Słowo “[[wymagania]]” pojawia się tak często w inżynierii oprogramowania i jest na tak wiele sposobów używane, że dodam coś od siebie. Szczególnie dlatego, że poza projektami często biorę udział w dyskusjach (nie raz na etapie składania oferty na usługi analityczne) na te tematy, wymieniam się poglądami i z praktykami i z teoretykami, że nie wspomnę o studentach. Będzie więc o tym jak przekazać wykonawcy (programistom) “to co ma powstać”. Nie wiem ile artykułów mi to zajmie 🙂 ale, w miarę czasu, będzie się coś tu na ten temat pojawiało a w razie pytań jak zawsze odpowiem.
Model
Na początek kilka słów o tym “na czym polega problem” czyli co nieco o komunikacji. Otóż problem polega na tym, by przekazać jakiś “obraz” (wyobrażenie) np. wykonawcy oprogramowania.
[singlepic id=61 w=640h=240 float=]
Co my tu mamy powyżej. Zacznijmy od tego, że na końcach diagramu są dwa obrazy: rzeczywisty i odebrany. Problem w tym, by jako nadawca “zapanować” nad tym co zostanie odebrane, a w każdym razie by wypracować metodę dająca jak największe prawdopodobieństwo zgodności obrazu odtworzonego z pierwotnym (rzeczywistym). Tu należy dodać, że pod pojęciem obrazu rzeczywistości mam na myśli to co “widzi (lub słyszy)” nadawca komunikatu: raz jest to coś, co widzimy przed sobą innym razem to, co sobie wyobrażamy (np. projekt przyszłego systemu lub jego części).
Diagram przedstawia dwóch aktorów tego procesu: nadawcę i odbiorce komunikatu. Tu pierwsze założenie: opisuję dwóch aktorów gdyż uważam, że wprowadzanie większej ich liczby drastycznie zmniejsza jakość przekazu (zgodność obrazu odtworzonego z rzeczywistym). Zjawisko to, podobnie jak i bardzo zabawną grę towarzyską, popularnie nazywamy “głuchy telefon”.
Nieco teorii komunikacji społecznej
Mamy tu nadawcę i odbiorcę komunikatu oraz kanał komunikacyjny jakim tu jest dokumentacja (diagram). Nie nazywam tu obrazu pierwotnego “obrazem przekazywanym” gdyż sama [[percepcja]] jest już pierwszą interpretacją. Tak więc Nadawca komunikatu nie opisuje rzeczywistości a to co “odebrał” (zrozumiał lub zinterpretował zależnie od sytuacji) i “ma w głowie”. Tak więc pierwszym etapem tego głuchego telefonu jest sama percepcja otoczenia przez naszego pierwszego aktora.
W wyniku tej percepcji powstaje obraz “zrozumiany”. Powstaje on na bazie interpretacji zobaczonego obrazu (lub wysłuchanej opowieści). Ten obraz jest złożeniem odbieranej rzeczywistości i doświadczenia obserwatora. W jego “głowie” powstanie tylko obraz tego co potrafił zinterpretować. Interpretacja to kolejny, drugi etap tego procesu, tu “rządzi” [[semiotyka]]. Obraz zrozumiany (odebrany, zinterpretowany) to efekt tego jak odebrane zostały poszczególne elementy tego co zobaczono (usłyszano). Ja patrząc na poruszający się szybko i hałasujący kawał żelaza na kołach zobaczę (doznam) samochód, buszmen prawdopodobnie zobaczy smoka.
Pora na papier lub np. ścianę jaskini:) ([[jaskinia Platona]]). Chcę przekazać (opowiedzieć) to co zobaczyłem. Muszę więc to jakoś utrwalić by ktoś inny, Odbiorca komunikatu, mógł “zobaczyć” to co ja widziałem. Narysuję (opiszę) to co zrozumiałem w sposób jaki potrafię (moja zdolność opisywania) to opisać. Powstaje utrwalony zapis, tu Diagram, ale może to być opis (lub rysunek naskalny). Do zapisu (opowieści) użyłem zestawu znaków (słów) języka komunikacji. Słownik jakim się posłużę to nic innego jak właśnie [[semantyka]] tego języka komunikacji. Składanie pojęć słownika (budowa zdań) także niesie informację. Istotne jest nie tylko to, jakiego słowa (znaku) użyto ale też jakie inne go otaczają (jak są ze sobą połączone). To (dopuszczalność i znaczenia połączeń) opisuje [[syntaktyka]] języka (czyli jego gramatyka).
Pora na odbiorcę. Ten, na bazie posiadanej znajomości języka użytego do nadania komunikatu (obrazu), coś “zrozumie” czytając (oglądając) zapis i odtworzy “sobie” w głowie obraz ziterpretowany, będzie on tym co zrozumiał odbiorca. Jak nietrudno się tu domyślić, to co zrozumiał odbiorca w 100% zależy od jego znajomości języka komunikacji. Wymagana więc tu wiedza to: [[semantyka]], [[syntaktyka]] i dodatkowo [[pragmatyka]] języka użytego do przekazu. Wiemy już czym jest semantyka (słownik pojęć) i syntaktyka (gramatyka), zaś pragmatyka to znaczenia pojęć (a pojęcia słownika mogą być wieloznaczne) wynikające z kontekstu (np. ten sam trójkąt w zeszycie do lekcji geometrii znaczy coś innego niż na drzwiach korytarza hotelu). Interpretację zaś znaków opisuje [[semiotyka]].
Ostatni etap komunikacji to to, co na bazie pozyskanej z zapisu “wiedzy” odtworzy (utrwali) Odbiorca komunikatu. Tu uwidacznia się głuchy telefon. Czujny czytelnik zapewne zauważył, że ten etap w zasadzie nie różni się, powiedział bym nawet, że jest powtórzeniem pierwszego etapu. Jednak gdy uznamy, że Odbiorca na bazie przekazu musi coś stworzyć (w myślach, przeżyć to), jakąś reprezentację tego o czym się dowiedział … ale o tym za chwilę.
Jak to się ma do inżynierii oprogramowania
Nazwijmy teraz Nadawcę komunikatu Analitykiem a Odbiorcą Wykonawcą. Pierwszy paradoks polega na tym, że analityk nie musi znać się na tym co widzi ale musi umieć to opisać. Wiem, wiem, że wielu ludzi się z tym nie zgadza (wymaganie: “analityk ma mieć wiedzę branżową”). W czym problem? W semantyce. Semantyka to słownictwo (zestaw pojęć i ich definicje). Tak więc by opisać cokolwiek w sposób zrozumiały wystarczy, że potrafię poprawnie zinterpretować i potem nazwać wszystko to co słyszę, widzę (wyobrażam sobie) i chce przekazać dalej (zapisać).
Klasycznym przykładem tego paradoksu jest malarz. Jeżeli potrafi wiernie namalować to co widzi (wyobraża sobie) oglądający bez problemu “odbierze” ten komunikat. Mamy z tym zjawiskiem kontakt z jednej strony przy portrecie z natury albo, w nieco trudniejszym wydaniu, przy tworzeniu portretów pamięciowych poszukiwanych osób. Przykładem bliższym naszej dziedziny jest architekt czy projektant wnętrz. Żaden z nich raczej nie potrafi dobrze zbudować domu czy wyremontować łazienki, jednak potrafi patrząc lub wyobrażając go sobie, opisać go tak by wykonawca zrealizował projekt i stworzył to co wyobraził sobie (zobaczył gdzie indziej) projektant. Co jest tu potrzebne? Tylko jedna rzecz: wspólny język komunikacji i zrozumienie kontekstu.
To jednak nie wszystko. W przypadku inżynierii oprogramowania Obrazem rzeczywistym jest sytuacja zastana lub oczekiwana (to co chcemy uzyskać) u zamawiającego oprogramowanie. Obrazem odtworzonym jest oprogramowanie jakie powstało (ma powstać) będący tym co zamówił (swoim językiem) Zamawiający.
I tu powoli wyłania się (moja) wizja procesu analizy wymagań oraz ich realizacji. Analityk:
- musi jak najlepiej (najwierniej) zrozumieć to co widzi,
- musi umieć to utrwalić by przekazać Wykonawcy.
Wykonawca:
- musi poprawnie to odczytać,
- musi to umieć zintepretować i wykonać.
Co mamy. Praktyka pokazuje, że zamawiający oprogramowanie ma swoja, biznesową, wizje rozwiązania. Jest nią to co chce uzyskać. Nie raz jednak nie potrafi zaprojektować stosownych zmian, tu potrzebne jest wsparcie w postaci analizy biznesowej i rekomendacji. Kolejny krok to, po wyborze jednego z rekomendowanych rozwiązań, wdrożenie pomysłu. Jeżeli tym rekomendowanym rozwiązaniem jest “jakieś oprogramowanie” pojawia się potrzeba opisania “co ma powstać”. Tu pora na polemikę :).
Skoro głuchy telefon jest ryzykowny to należy minimalizować jego wpływ, eliminując ogniwa pośrednie w komunikacji. Najczęściej spotykane podejście to:
- analiza i specyfikacja potrzeb,
- projektowanie rozwiązania,
- wykonanie.
Tradycyjnie pierwsze robi analityk wymagań (albo niestety sam zamawiający), pozostałe dwa wykonawca. Problem w tym, że trudno jest (zaryzykuję twierdzenie, że jest to NIEMOŻLIWE) przekazać wymagania jako listę potrzeb. Dlaczego? Bo nie istnieje język opisu potrzeb na tyle semantycznie jednoznaczny by interpretacja zapisu potrzeb była także jednoznaczna! Dalej: zamawiający powie co chce uzyskać ale nie powie “kim jest” (opis tego “co” będzie przedmiotem, na którym te potrzeby będą realizowane).
Jak można (próbować) rozwiązać problem?
[singlepic id=62 w=640 h=640 float=center] Przypomnę opisane wcześniej trzy etapy projektu:- analiza i specyfikacja potrzeb
- projektowania (koncepcji) rozwiązania
- wykonanie
Dać wykonawcy projekt (koncepcję) rozwiązania a nie opis potrzeb. Co z tego wynika? Analiza i projekt rozwiązania to praca dla jednej osoby (kasujemy głuchy telefon). Diagram powyżej (pierwszy) pokazuje typowe rozwiązanie: Zamawiający zapisuje swoje potrzeby swoim językiem. Zapis ten otrzymuje wykonawca, interpretuje go i tworzy obraz tego co “miało powstać” (a raczej było oczekiwane przez Zamawiającego). W sumie niewielkie ma tu znaczenie to, czy Zamawiający opowiadał a zapisywał Wykonawca czy Zamawiający zapisał i przekazał zapis Wykonawcy. Problem komunikacyjny jest dokładnie taki sam: projekt i wykonanie leży po stronie Wykonawcy a przekaz informacji wykonano językiem nieznanym jednej ze stron.
Czy czytelnik, po lekturze tekstu o teorii komunikacji widzi już w czym problem? Pewnie większość już go widzi. System pojęciowy Zamawiającego i system pojęciowy Wykonawcy to inne systemy! Przekaz nie może być wierny! Wykonawca tu, to właśnie buszmen słuchający opisu samochodu Zamawiajacego.
Rozwiązaniem jest rola Analityka. Analityk to taki osobnik, który ani nie potrafi być (nie jest lub nie chce) dobrym prezesem firmy ani dobrym programistą ale posługuje się sprawnie dwoma językami i zna kontekst pracy obu stron. Dokładnie tak jak architekt czy projektant: nie jest prezesem firmy inwestora ale rozumie co i o czym on mówi. Nie jest majstrem budowlanym ale potrafi opisać (zaprojektować i narysować) co należy zbudować.
Na zakończenie
Wiele firm programistycznych ma etatowych, tak zwanych analityków wymagań, jednak oni z reguły nadal nie są projektantami. Raczej zapisują, w z góry ustalony sposób, to co mówi Zamawiający (z reguły zresztą bez pełnego zrozumienia co powiedziano). Bywa, że projektanta lub programistę wysyła się w roli analityka. To też nie działa z tych samych powodów komunikacyjnych, co potwierdza praktyka.
Czy wykonawca może mieć dobrego analityka projektanta? Może mieć, niejeden nawet ma ale… z jakiegoś powodu uznano, w znacznie starszej niż inżynieria oprogramowania, branży budowlanej, że Wykonawca nie powinien być autorem tego co należy wykonać dla Zamawiającego. Zamawiający także nie powinien być projektantem. Dlaczego? Każda firma (jej Prezes) dąży do maksymalizacji swojego zysku (tu rentowności naszego projektu), interesy Zamawiającego i Wykonawcy są więc sprzeczne dlatego wymagana jest trzecia rola: niezależny projektant. I tak własnie to wygląda w projektach budowlanych, w których architekt to osobny podmiot. Zachowuje on także prawo nadzoru autorskiego nad realizacją swojego projektu by także na etapie realizacji panować nad nim. W trakcie realizacji nadal interesy Zamawiającego i Wykonawcy sprzeczne – Zamawiający maksymalizuje funkcjonalność czyli forsuje wzrost kosztów to zaś niszczy zysk Wykonawcy, który stara się tę funkcjonalność minimalizować.
Często można usłyszeć, że Zamawiający nie wiedzą czego chcą. Otóż z reguły wiedzą doskonale ale nie są rozumiani przez przyszłego wykonawcę bo ten operuje innym językiem (Z: chciał bym mieć możliwość bezpiecznego korzystania z danych w systemie partnera, W: czy potrzebna jest Państwa baza pośrednia [[SQL]]?).
Wielu Wykonawców wpisało już sobie w metodę pracy ten brak komunikacji i nazywa swoją metodykę “[[prototyp]]owaniem”. Innymi słowy, skoro raczej nie zrozumiałem tego, czego oczekuje Zamawiający, będę mu podsuwał kolejne prototypy tego co zrozumiałem, Zamawiający będzie mówił co należy zmienić by osiągnąć cel i może jakoś się uda.
A czy można od razu zaprojektować to co ma powstać? Można.
O czym będzie dalej? O analizie, projektowaniu i modelowaniu. Analiza to słuchanie i zapisywanie tego co usłyszano i zrozumiano. Projektowanie to tworzenie opisu tego co ma powstać. Modelowanie czyli jak sprawdzić czy nasz opis oddaje rzeczywistość i jak sprawdzić czy projekt jest tym czym ma być. O notacjach czyli o tym jak na etapie analizy i projektowania należy zapisywać to, co należy przekazać.
c.d.n.
Jarku!
Nie do końca się z Tobą zgadzam w zakresie, w którym piszesz, że Zamawiający wie czego chce. Otóż wie o ile pozostajemy w kategoriach biznesowych. Natomiast Zamawiający nader często nie jest świadom tego co może zaoferować mu konkretna technologia. Architekt zgodnie z życzeniem Zamawiającego projektuje w łazience muszlę klozetową i bidet, gdyż Zamawiający wyraził tą kategorię potrzeb. Jednak jak się okazało technologia umożliwia obecnie realizację muszli klozetowej wraz z bidetem w jednym obudowaniu, a na domiar w desce klozetowej ukryty jest mechanizm masowania pośladków (o czym nie wiedział ani Zamawiający, ani Architekt). Mamy do czynienia z Zamawiającym, który gdyby wiedział o takich możliwościach “biznesowych” z pewną wyraziłby takie życzenie.
Dążę do tego, że opisana przez Ciebie koncepcja jest niepełna i w założeniu jednorazowa (jeden kierunek przekazu), podczas, gdy prototypowanie w założeniu swym wpisuje komunikację (nie przekaz), za czym idzie wymiana informacji w obu kierunkach.
Przykładowo – chcę aby łazienka była zielona, ergonomiczna, dostępny był panel sterowania radem oraz żeby długo utrzymywała ciepło. Dostawca może tutaj zadać następujące pytanie “A co by Pan powiedział, gdybyśmy zamontowali dodatkowy panel TV z DVD nad wanną, bo jeden z naszych klientów miał manię oglądania filmów w wannie?! Inny kazał zamontować świetlne kafelki na podłodze bo w ten sposób mógł grać w ulubioną grę zręcznością z czasów dzieciństwa, a jeszcze chciał sceny świetlne zintegrowane z dmuchawami w ścianach i spięte z systemem Hi-Fi. Lubi Pan Whisky, czemu by nie zrobić podręcznego barku?”
Wykonawca zorientowany biznesowo często poświęca masę czasu i energii aby wyedukować Zamawiającego, dzięki czemu lista oczekiwań tego ostatniego ewoluuje.
Zakładam, że nawet najlepszy Analityk nie jest w stanie poznać możliwości wszystkich technologii, a zatem idealny stan rzeczy to taki gdy Analityk występuje w roli “tłumacza” w komunikacji pomiędzy Zamawiającym a Dostawcą.
Człowiek zatem całe życie się uczy zatem i Architekt z kolejnymi domami ma coraz większą wiedzę an temat tego o co i jak pytać Zamawiającego. Jednak ma poważną wątpliwość, czy zdolność akumulacji wiedzy przez Architekta ma tą samą dynamikę co rozwój wielu różnych technologii, które mogą w taki bądź inny sposób zaspakajać potrzeby klientów.
Reasumując:
– Rola Analityka – w 100% się zgadzam
– Czy klient wie czego chce – tak, zgodnie z bieżącym aparatem pojęciowym; czy klient wie czego mógłby chcieć – nie
– Czy klient wydając dziesiątki, czy setki tysięcy złotych chciałby dowiedzieć się co może zrobić więcej, bądź jak inni realizują tego typu potrzeby – zdecydowanie tak
– Czy Analityk jest w stanie powiedzieć klientowi czego ten mógłby chcieć – zależy od analityka, ale tak czy siak to nie jest w jego interesie
– Czy klient potrafi przed uruchomieniem projektu zakumulować wiedzę, na temat tego czego mógłby chcieć – niezbyt często
– Czy prototypowanie jest mechanizmem komunikacji – tak, bo często właśnie wtedy klient dowiaduje się czego mógłby chcieć, a czego wcześniej nikt mu nie powiedział
Wszystko to co napisałeś jest prawdą, gdzie więc widzę :haczyk”? W tym, że klient oczekuje rozwiązania wystarczająco dobrego na moment opracowania projektu a nie możliwie najlepszego. To oczywiście moja subiektywna opinia. Mała anegdota: podczas wieczoru przyszły Pan Młody żali się, boi się, czy dokonał dobrego wyboru. Na co jeden z doświadczonych kilkoma rozwodami kolega odparł: nie przejmuj się, i tak na drugi dzień po ślubie zobaczysz ładniejszą dziewczynę ale zapewniam Cie, że to zły powód do rozwodu by szukać nowej ładniejszej…
Zarówno analityk, lekarz, architekt, i nie tylko oni, studiują swoje branże by rozwiązania jakie proponują były możliwie najlepsze z ich perspektywy. Jednak zawsze będzie coś o czym nie będą wiedzieli ale czy to czyni ich złymi doradcami? Do ilu lekarzy ma sens iść? To zależy od ryzyka danej choroby… ale z reguły kończymy na jednym…
Czas i środki jakie poświęcamy na dokonanie wyboru są zawsze skończone… nie wiem czy zdolność akumulacji wiedzy przez kogokolwiek (jako jedna osoba) nadąża za tą czy inną branżą, być może nie w całości ale w pewnym ograniczonym, zdefiniowanym zakresie wierze że tak.
Masz racje, że można prototypowaniem wygenerować nowe fajne pomysły ale to moim zdaniem nie jeden a osobne projekty. Zapewniam Cię, że po skończonej budowie domu i tak szybko znajdziesz ładniejszy kibelek od tego który już masz ale czy to powód by żałować posiadanego? Jestem pewien, że każdy po skończeniu budowy domu za każdym razem znajduje w marketach budowlanych coś fajniejszego co chciał by mieć…
Ja w swojej “teorii i praktyce” właśnie z tego powodu zakładam, że projekty powinny być kompletne ale możliwie krótkie. Duża inwestycja jest dzielona na etapy, i projektuje się od razu koncepcje całości, a szczegóły w kolejnych etapach. Wtedy uda się i to co ja opisałem i to na Ty zwróciłeś uwagę. Architekt projektuje biurowiec “ogólnie”, jeżeli sieć informatyczna będzie instalowana rok po rozpoczęciu budowy, to nie będzie (nie powinna być) projektowana w dniu jej rozpoczęcia a jej projektantem i tak nie będzie architekt tylko specjalista od sieci, ten jednak będzie musiał się opierać na planach budynku i nie powinien chcieć burzyć ścian… 🙂
Tak wiec ja zakładam, że klient pyta mnie jakie są znane mi możliwości wygodnego załatwiania kluczowych potrzeb życiowych, ja projektuje łazienkę wg. najlepszej swojej wiedzy i potem ktoś realizuje projekt. Jednak nie przekraczam pewnego poziomu szczegółów, te “obsłuży” wykonawca, ma pewną swobodę (dobry architekt określi funkcje każdego sprzętu ale rzadko wskazuje egzemplarz i producenta) ale musi się zmieścić w budżecie. Zwróć uwagę na telefon komórkowy, na drugi dzień po zawarciu umowy trafisz na reklamę fajniejszego i tańszego, i co? I nic :), choć znam takich co zmieniają niemalże co kwartał :)))