Pisząc dok­to­rat posta­no­wi­łem zacząć tu cykl arty­ku­łów na temat ana­li­zy, mode­lo­wa­nia i pro­jek­to­wa­nia czy­li tego jak od pierw­szej roz­mo­wy dobrnąć do … no wła­snie. Słowo „[[wyma­ga­nia]]” poja­wia się tak czę­sto w inży­nie­rii opro­gra­mo­wa­nia i jest na tak wie­le spo­so­bów uży­wa­ne, że dodam coś od sie­bie. Szczególnie dla­te­go, że poza pro­jek­ta­mi czę­sto bio­rę udział w dys­ku­sjach (nie raz na eta­pie skła­da­nia ofer­ty na usłu­gi ana­li­tycz­ne) na te tema­ty, wymie­niam się poglą­da­mi i z prak­ty­ka­mi i z teo­re­ty­ka­mi, że nie wspo­mnę o stu­den­tach. Będzie więc o tym jak prze­ka­zać wyko­naw­cy (pro­gra­mi­stom) ​„to co ma powstać”. Nie wiem ile arty­ku­łów mi to zaj­mie 🙂 ale, w mia­rę cza­su, będzie się coś tu na ten temat poja­wia­ło a w razie pytań jak zawsze odpowiem.

Model

Na począ­tek kil­ka słów o tym ​„na czym pole­ga pro­blem” czy­li co nie­co o komu­ni­ka­cji. Otóż pro­blem pole­ga na tym, by prze­ka­zać jakiś ​„obraz” (wyobra­że­nie) np. wyko­naw­cy oprogramowania.

[sin­gle­pic id=61 w=640h=240 float=]

Co my tu mamy powy­żej. Zacznijmy od tego, że na koń­cach dia­gra­mu są dwa obra­zy: rze­czy­wi­sty i ode­bra­ny. Problem w tym, by jako nadaw­ca ​„zapa­no­wać” nad tym co zosta­nie ode­bra­ne, a w każ­dym razie by wypra­co­wać meto­dę dają­ca jak naj­więk­sze praw­do­po­do­bień­stwo zgod­no­ści obra­zu odtwo­rzo­ne­go z pier­wot­nym (rze­czy­wi­stym). Tu nale­ży dodać, że pod poję­ciem obra­zu rze­czy­wi­sto­ści mam na myśli to co ​„widzi (lub sły­szy)” nadaw­ca komu­ni­ka­tu: raz jest to coś, co widzi­my przed sobą innym razem to, co sobie wyobra­ża­my (np. pro­jekt przy­szłe­go sys­te­mu lub jego części).

Diagram przed­sta­wia dwóch akto­rów tego pro­ce­su: nadaw­cę i odbior­ce komu­ni­ka­tu. Tu pierw­sze zało­że­nie: opi­su­ję dwóch akto­rów gdyż uwa­żam, że wpro­wa­dza­nie więk­szej ich licz­by dra­stycz­nie zmniej­sza jakość prze­ka­zu (zgod­ność obra­zu odtwo­rzo­ne­go z rze­czy­wi­stym). Zjawisko to, podob­nie jak i bar­dzo zabaw­ną grę towa­rzy­ską, popu­lar­nie nazy­wa­my ​„głu­chy telefon”.

Nieco teorii komunikacji społecznej

Mamy tu nadaw­cę i odbior­cę komu­ni­ka­tu oraz kanał komu­ni­ka­cyj­ny jakim tu jest doku­men­ta­cja (dia­gram). Nie nazy­wam tu obra­zu pier­wot­ne­go ​„obra­zem prze­ka­zy­wa­nym” gdyż sama [[per­cep­cja]] jest już pierw­szą inter­pre­ta­cją. Tak więc Nadawca komu­ni­ka­tu nie opi­su­je rze­czy­wi­sto­ści a to co ​„ode­brał” (zro­zu­miał lub zin­ter­pre­to­wał zależ­nie od sytu­acji) i ​„ma w gło­wie”. Tak więc pierw­szym eta­pem tego głu­che­go tele­fo­nu jest sama per­cep­cja oto­cze­nia przez nasze­go pierw­sze­go aktora.

W wyni­ku tej per­cep­cji powsta­je obraz ​„zro­zu­mia­ny”. Powstaje on na bazie inter­pre­ta­cji zoba­czo­ne­go obra­zu (lub wysłu­cha­nej opo­wie­ści). Ten obraz jest zło­że­niem odbie­ra­nej rze­czy­wi­sto­ści i doświad­cze­nia obser­wa­to­ra. W jego ​„gło­wie” powsta­nie tyl­ko obraz tego co potra­fił zin­ter­pre­to­wać. Interpretacja to kolej­ny, dru­gi etap tego pro­ce­su, tu ​„rzą­dzi” [[semio­ty­ka]]. Obraz zro­zu­mia­ny (ode­bra­ny, zin­ter­pre­to­wa­ny) to efekt tego jak ode­bra­ne zosta­ły poszcze­gól­ne ele­men­ty tego co zoba­czo­no (usły­sza­no). Ja patrząc na poru­sza­ją­cy się szyb­ko i hała­su­ją­cy kawał żela­za na kołach zoba­czę (doznam) samo­chód, busz­men praw­do­po­dob­nie zoba­czy smoka.

Pora na papier lub np. ścia­nę jaski­ni:) ([[jaski­nia Platona]]). Chcę prze­ka­zać (opo­wie­dzieć) to co zoba­czy­łem. Muszę więc to jakoś utrwa­lić by ktoś inny, Odbiorca komu­ni­ka­tu, mógł ​„zoba­czyć” to co ja widzia­łem. Narysuję (opi­szę) to co zro­zu­mia­łem w spo­sób jaki potra­fię (moja zdol­ność opi­sy­wa­nia) to opi­sać. Powstaje utrwa­lo­ny zapis, tu Diagram, ale może to być opis (lub rysu­nek naskal­ny). Do zapi­su (opo­wie­ści) uży­łem zesta­wu zna­ków (słów) języ­ka komu­ni­ka­cji. Słownik jakim się posłu­żę to nic inne­go jak wła­śnie [[seman­ty­ka]] tego języ­ka komu­ni­ka­cji. Składanie pojęć słow­ni­ka (budo­wa zdań) tak­że nie­sie infor­ma­cję. Istotne jest nie tyl­ko to, jakie­go sło­wa (zna­ku) uży­to ale też jakie inne go ota­cza­ją (jak są ze sobą połą­czo­ne). To (dopusz­czal­ność i zna­cze­nia połą­czeń) opi­su­je [[syn­tak­ty­ka]] języ­ka (czy­li jego gramatyka).

Pora na odbior­cę. Ten, na bazie posia­da­nej zna­jo­mo­ści języ­ka uży­te­go do nada­nia komu­ni­ka­tu (obra­zu), coś ​„zro­zu­mie” czy­ta­jąc (oglą­da­jąc) zapis i odtwo­rzy ​„sobie” w gło­wie obraz ziter­pre­to­wa­ny, będzie on tym co zro­zu­miał odbior­ca. Jak nie­trud­no się tu domy­ślić, to co zro­zu­miał odbior­ca w 100% zale­ży od jego zna­jo­mo­ści języ­ka komu­ni­ka­cji. Wymagana więc tu wie­dza to: [[seman­ty­ka]], [[syn­tak­ty­ka]] i dodat­ko­wo [[prag­ma­ty­ka]] języ­ka uży­te­go do prze­ka­zu. Wiemy już czym jest seman­ty­ka (słow­nik pojęć) i syn­tak­ty­ka (gra­ma­ty­ka), zaś prag­ma­ty­ka to zna­cze­nia pojęć (a poję­cia słow­ni­ka mogą być wie­lo­znacz­ne) wyni­ka­ją­ce z kon­tek­stu (np. ten sam trój­kąt w zeszy­cie do lek­cji geo­me­trii zna­czy coś inne­go niż na drzwiach kory­ta­rza hote­lu). Interpretację zaś zna­ków opi­su­je [[semio­ty­ka]].

Ostatni etap komu­ni­ka­cji to to, co na bazie pozy­ska­nej z zapi­su ​„wie­dzy” odtwo­rzy (utrwa­li) Odbiorca komu­ni­ka­tu. Tu uwi­dacz­nia się głu­chy tele­fon. Czujny czy­tel­nik zapew­ne zauwa­żył, że ten etap w zasa­dzie nie róż­ni się, powie­dział bym nawet, że jest powtó­rze­niem pierw­sze­go eta­pu. Jednak gdy uzna­my, że Odbiorca na bazie prze­ka­zu musi coś stwo­rzyć (w myślach, prze­żyć to), jakąś repre­zen­ta­cję tego o czym się dowie­dział … ale o tym za chwilę.

Jak to się ma do inżynierii oprogramowania

Nazwijmy teraz Nadawcę komu­ni­ka­tu Analitykiem a Odbiorcą Wykonawcą. Pierwszy para­doks pole­ga na tym, że ana­li­tyk nie musi znać się na tym co widzi ale musi umieć to opi­sać. Wiem, wiem, że wie­lu ludzi się z tym nie zga­dza (wyma­ga­nie: ​„ana­li­tyk ma mieć wie­dzę bran­żo­wą”). W czym pro­blem? W seman­ty­ce. Semantyka to słow­nic­two (zestaw pojęć i ich defi­ni­cje). Tak więc by opi­sać cokol­wiek w spo­sób zro­zu­mia­ły wystar­czy, że potra­fię popraw­nie zin­ter­pre­to­wać i potem nazwać wszyst­ko to co sły­szę, widzę (wyobra­żam sobie) i chce prze­ka­zać dalej (zapi­sać).

Klasycznym przy­kła­dem tego para­dok­su jest malarz. Jeżeli potra­fi wier­nie nama­lo­wać to co widzi (wyobra­ża sobie) oglą­da­ją­cy bez pro­ble­mu ​„odbie­rze” ten komu­ni­kat. Mamy z tym zja­wi­skiem kon­takt z jed­nej stro­ny przy por­tre­cie z natu­ry albo, w nie­co trud­niej­szym wyda­niu, przy two­rze­niu por­tre­tów pamię­cio­wych poszu­ki­wa­nych osób. Przykładem bliż­szym naszej dzie­dzi­ny jest archi­tekt czy pro­jek­tant wnętrz. Żaden z nich raczej nie potra­fi dobrze zbu­do­wać domu czy wyre­mon­to­wać łazien­ki, jed­nak potra­fi patrząc lub wyobra­ża­jąc go sobie, opi­sać go tak by wyko­naw­ca zre­ali­zo­wał pro­jekt i stwo­rzył to co wyobra­ził sobie (zoba­czył gdzie indziej) pro­jek­tant. Co jest tu potrzeb­ne? Tylko jed­na rzecz: wspól­ny język komu­ni­ka­cji i zro­zu­mie­nie kontekstu.

To jed­nak nie wszyst­ko. W przy­pad­ku inży­nie­rii opro­gra­mo­wa­nia Obrazem rze­czy­wi­stym jest sytu­acja zasta­na lub ocze­ki­wa­na (to co chce­my uzy­skać) u zama­wia­ją­ce­go opro­gra­mo­wa­nie. Obrazem odtwo­rzo­nym jest opro­gra­mo­wa­nie jakie powsta­ło (ma powstać) będą­cy tym co zamó­wił (swo­im języ­kiem) Zamawiający.

I tu powo­li wyła­nia się (moja) wizja pro­ce­su ana­li­zy wyma­gań oraz ich reali­za­cji. Analityk:

1. musi jak naj­le­piej (naj­wier­niej) zro­zu­mieć to co widzi,
2. musi umieć to utrwa­lić by prze­ka­zać Wykonawcy.

Wykonawca:

1. musi popraw­nie to odczytać,
2. musi to umieć zin­te­pre­to­wać i wykonać.

Co mamy. Praktyka poka­zu­je, że zama­wia­ją­cy opro­gra­mo­wa­nie ma swo­ja, biz­ne­so­wą, wizje roz­wią­za­nia. Jest nią to co chce uzy­skać. Nie raz jed­nak nie potra­fi zapro­jek­to­wać sto­sow­nych zmian, tu potrzeb­ne jest wspar­cie w posta­ci ana­li­zy biz­ne­so­wej i reko­men­da­cji. Kolejny krok to, po wybo­rze jed­ne­go z reko­men­do­wa­nych roz­wią­zań, wdro­że­nie pomy­słu. Jeżeli tym reko­men­do­wa­nym roz­wią­za­niem jest ​„jakieś opro­gra­mo­wa­nie” poja­wia się potrze­ba opi­sa­nia ​„co ma powstać”. Tu pora na polemikę :).

Skoro głu­chy tele­fon jest ryzy­kow­ny to nale­ży mini­ma­li­zo­wać jego wpływ, eli­mi­nu­jąc ogni­wa pośred­nie w komu­ni­ka­cji. Najczęściej spo­ty­ka­ne podej­ście to:

1. ana­li­za i spe­cy­fi­ka­cja potrzeb,
2. pro­jek­to­wa­nie rozwiązania,
3. wyko­na­nie.

Tradycyjnie pierw­sze robi ana­li­tyk wyma­gań (albo nie­ste­ty sam zama­wia­ją­cy), pozo­sta­łe dwa wyko­naw­ca. Problem w tym, że trud­no jest (zary­zy­ku­ję twier­dze­nie, że jest to NIEMOŻLIWE) prze­ka­zać wyma­ga­nia jako listę potrzeb. Dlaczego? Bo nie ist­nie­je język opi­su potrzeb na tyle seman­tycz­nie jed­no­znacz­ny by inter­pre­ta­cja zapi­su potrzeb była tak­że jed­no­znacz­na! Dalej: zama­wia­ją­cy powie co chce uzy­skać ale nie powie ​„kim jest” (opis tego ​„co” będzie przed­mio­tem, na któ­rym te potrze­by będą realizowane).

Jak można (próbować) rozwiązać problem?

1. ana­li­za i spe­cy­fi­ka­cja potrzeb
2. pro­jek­to­wa­nia (kon­cep­cji) rozwiązania
3. wyko­na­nie

Dać wyko­naw­cy pro­jekt (kon­cep­cję) roz­wią­za­nia a nie opis potrzeb. Co z tego wyni­ka? Analiza i pro­jekt roz­wią­za­nia to pra­ca dla jed­nej oso­by (kasu­je­my głu­chy tele­fon). Diagram powy­żej (pierw­szy) poka­zu­je typo­we roz­wią­za­nie: Zamawiający zapi­su­je swo­je potrze­by swo­im języ­kiem. Zapis ten otrzy­mu­je wyko­naw­ca, inter­pre­tu­je go i two­rzy obraz tego co ​„mia­ło powstać” (a raczej było ocze­ki­wa­ne przez Zamawiającego). W sumie nie­wiel­kie ma tu zna­cze­nie to, czy Zamawiający opo­wia­dał a zapi­sy­wał Wykonawca czy Zamawiający zapi­sał i prze­ka­zał zapis Wykonawcy. Problem komu­ni­ka­cyj­ny jest dokład­nie taki sam: pro­jekt i wyko­na­nie leży po stro­nie Wykonawcy a prze­kaz infor­ma­cji wyko­na­no języ­kiem nie­zna­nym jed­nej ze stron.

Czy czy­tel­nik, po lek­tu­rze tek­stu o teo­rii komu­ni­ka­cji widzi już w czym pro­blem? Pewnie więk­szość już go widzi. System poję­cio­wy Zamawiającego i sys­tem poję­cio­wy Wykonawcy to inne sys­te­my! Przekaz nie może być wier­ny! Wykonawca tu, to wła­śnie busz­men słu­cha­ją­cy opi­su samo­cho­du Zamawiajacego.

Rozwiązaniem jest rola Analityka. Analityk to taki osob­nik, któ­ry ani nie potra­fi być (nie jest lub nie chce) dobrym pre­ze­sem fir­my ani dobrym pro­gra­mi­stą ale posłu­gu­je się spraw­nie dwo­ma języ­ka­mi i zna kon­tekst pra­cy obu stron. Dokładnie tak jak archi­tekt czy pro­jek­tant: nie jest pre­ze­sem fir­my inwe­sto­ra ale rozu­mie co i o czym on mówi. Nie jest maj­strem budow­la­nym ale potra­fi opi­sać (zapro­jek­to­wać i nary­so­wać) co nale­ży zbudować.

Na zakończenie

Wiele firm pro­gra­mi­stycz­nych ma eta­to­wych, tak zwa­nych ana­li­ty­ków wyma­gań, jed­nak oni z regu­ły nadal nie są pro­jek­tan­ta­mi. Raczej zapi­su­ją, w z góry usta­lo­ny spo­sób, to co mówi Zamawiający (z regu­ły zresz­tą bez peł­ne­go zro­zu­mie­nia co powie­dzia­no). Bywa, że pro­jek­tan­ta lub pro­gra­mi­stę wysy­ła się w roli ana­li­ty­ka. To też nie dzia­ła z tych samych powo­dów komu­ni­ka­cyj­nych, co potwier­dza praktyka.

Czy wyko­naw­ca może mieć dobre­go ana­li­ty­ka pro­jek­tan­ta? Może mieć, nie­je­den nawet ma ale… z jakie­goś powo­du uzna­no, w znacz­nie star­szej niż inży­nie­ria opro­gra­mo­wa­nia, bran­ży budow­la­nej, że Wykonawca nie powi­nien być auto­rem tego co nale­ży wyko­nać dla Zamawiającego. Zamawiający tak­że nie powi­nien być pro­jek­tan­tem. Dlaczego? Każda fir­ma (jej Prezes) dąży do mak­sy­ma­li­za­cji swo­je­go zysku (tu ren­tow­no­ści nasze­go pro­jek­tu), inte­re­sy Zamawiającego i Wykonawcy są więc sprzecz­ne dla­te­go wyma­ga­na jest trze­cia rola: nie­za­leż­ny pro­jek­tant. I tak wła­snie to wyglą­da w pro­jek­tach budow­la­nych, w któ­rych archi­tekt to osob­ny pod­miot. Zachowuje on tak­że pra­wo nad­zo­ru autor­skie­go nad reali­za­cją swo­je­go pro­jek­tu by tak­że na eta­pie reali­za­cji pano­wać nad nim. W trak­cie reali­za­cji nadal inte­re­sy Zamawiającego i Wykonawcy sprzecz­ne – Zamawiający mak­sy­ma­li­zu­je funk­cjo­nal­ność czy­li for­su­je wzrost kosz­tów to zaś nisz­czy zysk Wykonawcy, któ­ry sta­ra się tę funk­cjo­nal­ność minimalizować.

Często moż­na usły­szeć, że Zamawiający nie wie­dzą cze­go chcą. Otóż z regu­ły wie­dzą dosko­na­le ale nie są rozu­mia­ni przez przy­szłe­go wyko­naw­cę bo ten ope­ru­je innym języ­kiem (Z: chciał bym mieć moż­li­wość bez­piecz­ne­go korzy­sta­nia z danych w sys­te­mie part­ne­ra, W: czy potrzeb­na jest Państwa baza pośred­nia [[SQL]]?).

Wielu Wykonawców wpi­sa­ło już sobie w meto­dę pra­cy ten brak komu­ni­ka­cji i nazy­wa swo­ją meto­dy­kę „[[prototyp]]owaniem”. Innymi sło­wy, sko­ro raczej nie zro­zu­mia­łem tego, cze­go ocze­ku­je Zamawiający, będę mu pod­su­wał kolej­ne pro­to­ty­py tego co zro­zu­mia­łem, Zamawiający będzie mówił co nale­ży zmie­nić by osią­gnąć cel i może jakoś się uda.

A czy moż­na od razu zapro­jek­to­wać to co ma powstać? Można.

O czym będzie dalej? O ana­li­zie, pro­jek­to­wa­niu i mode­lo­wa­niu. Analiza to słu­cha­nie i zapi­sy­wa­nie tego co usły­sza­no i zro­zu­mia­no. Projektowanie to two­rze­nie opi­su tego co ma powstać. Modelowanie czy­li jak spraw­dzić czy nasz opis odda­je rze­czy­wi­stość i jak spraw­dzić czy pro­jekt jest tym czym ma być. O nota­cjach czy­li o tym jak na eta­pie ana­li­zy i pro­jek­to­wa­nia nale­ży zapi­sy­wać to, co nale­ży przekazać.

c.d.n.