MDE czyli Model Driven Engineering

MDE to skrót od Model Driven Engineering, nazwy ogól­ne­go tren­du w świe­cie inżynierii.

Od pew­ne­go już cza­su da się zaob­ser­wo­wać, że ludzie i ich umie­jęt­no­ści nie nadą­ża­ją za zło­żo­no­ścią sys­te­mów… Nie jest to jakieś wiel­kie odkry­cie, bo pro­blem ten wystą­pił w inży­nie­rii maszyn kil­ka­dzie­siąt lat temu… mniej wię­cej w cza­sie gdy zaczę­ły się poja­wiać pierw­sze samo­cho­dy, potem było już coraz gorzej: licz­ba deta­li maszyn idzie w tysią­ce (pojaz­dy) a nie raz i milio­ny (samo­lo­ty pasa­żer­skie, pociągi).

Jedynym spo­so­bem zapa­no­wa­nia nad zło­żo­no­ścią obec­nych kon­sy­tu­acji inży­nier­skich jest reduk­cja zło­żo­no­ści ich opi­sów, a moż­li­we jest to jeże­li zacznie­my two­rzyć abs­trak­cje opi­su­ją­ce wybra­ne aspek­ty tych kon­struk­cji. Jest to tak­że zgod­ne z podej­ściem nauko­wym (ogól­na teo­ria sys­te­mów, meto­do­lo­gia nauki), pole­ga­ją­cym na generalizowaniu.

W inży­nie­rii od lat sto­so­wa­ne są rysun­ki tech­nicz­ne poglą­do­we, doku­men­to­wa­nie kon­struk­cji od ogó­łu do szcze­gó­łu. Po poja­wie­niu się kom­pu­te­rów oso­bi­stych poja­wi­ły się ich – desek kre­ślar­skich – odpo­wied­ni­ki w posta­ci apli­ka­cji CAD/CAM.

W inży­nie­rii opro­gra­mo­wa­nie nota­cje, odpo­wied­ni­ki rysun­ków tech­nicz­nych, poja­wi­ły się już w latach 80-tych. Rozwijały się wraz z roz­wo­jem inży­nie­rii pro­gra­mo­wa­nia i tech­no­lo­gii infor­ma­tycz­nych. Języki pro­gra­mo­wa­nia tak­że roz­wi­ja­ją się w stro­nę coraz wyż­sze­go pozio­mu abs­trak­cji (od asem­ble­ra do języ­ków skryp­to­wych takich jak Pyton czy Ruby on Rails). Rubikon został prze­kro­czo­ny gdy poja­wi­ły się meto­dy obiek­to­we w inży­nie­rii opro­gra­mo­wa­nia i nota­cja UML (co meto­do­lo­gicz­nie nie­mal­że zrów­na­ło inży­nie­rię opro­gra­mo­wa­nia z innym obsza­ra­mi inżynierii).

W kon­se­kwen­cji w inży­nie­rii opro­gra­mo­wa­nia na pierw­szy plan wysu­wa się rola archi­tek­ta roz­wią­za­nia, przed rola­mi zwią­za­ny­mi z imple­men­ta­cją. Architekt to ktoś kto wie co i po co ma powstać, pro­jek­tu­je roz­wią­za­nie na pozio­mie abs­trak­cji igno­ru­ją­cej deta­le a sku­pia­ją­cej się na cechach użyt­ko­wych. Bardzo waż­ne: archi­tekt nie jest developerem.

W obsza­rze inży­nie­rii opro­gra­mo­wa­nia orga­ni­za­cja stan­da­ry­zu­ją­ca Object Management Group (OMG​.org) opra­co­wa­ła spe­cy­fi­ka­cję MDA (Model Driven Architecture). MDA na tle MDE wyglą­da tak:

Kluczowy jest tu obszar ozna­czo­ny kolo­rem zie­lo­nym (model dri­ven deve­lop­ment), to obszar pra­cy z abs­trak­cją sys­te­mu, pozwa­la­ją­cy na dopra­co­wa­niu kon­struk­cji i jej testo­wa­niu, bez koniecz­no­ści two­rze­nia real­nych pro­to­ty­pów, któ­re są naj­kosz­tow­niej­szą czę­ścią pro­jek­tów inżynierskich.

Jednym z klu­czo­wych pojęć w pro­ce­sie two­rze­nia abs­trak­cji – mode­lu – roz­wią­za­nia jest poję­cie meta­mo­de­lu. Metamodel to abs­trak­cja budo­wa­na w opar­ciu o kla­sy ele­men­tów sys­te­mu. jest to dość trud­ne poję­cie jed­nak nie raz sto­so­wa­ne intu­icyj­nie: pisząc w doku­men­ta­cji wyma­gań Faktura naj­czę­ściej mamy na myśli wszyst­kie doku­men­ty będą­ce fak­tu­rą, a nie kon­kret­ną fak­tu­rę FV/1234/2018. Użycie poję­cia Faktura to nic inne­go jak nazwa­nie (wyod­ręb­nie­nie) kla­sy doku­men­tów mają­cych pew­ne wspólne.

Autor cyto­wa­nej pre­zen­ta­cji opi­su­je tak­że aspek­ty gene­ro­wa­nia kodu z mode­li, jed­nak tu oso­bi­ście jestem scep­ty­kiem. Wyeliminowanie ludzi z pro­ce­su two­rze­nia kodu jest w moich oczach taką samą uto­pią jak 100% eli­mi­na­cja ludzi z pro­ce­su two­rze­nia i reali­za­cji kon­struk­cji dra­pa­czy chmur czy samochodów.

A teraz zapra­szam do lek­tu­ry cyto­wa­nej pre­zen­ta­cji. Co praw­da opu­bli­ko­wa­na w 2013 roku ale nie stra­ci­ła wie­le na aktualności.

Prawa autorskie w architekturze … oprogramowania

Pojęcie nad­zo­ru autor­skie­go budzi wie­le emo­cji, w bran­ży IT jest to chy­ba temat tabu, głów­nie z powo­du nad­użyć twór­ców i dostaw­ców opro­gra­mo­wa­nia, a tak­że dla­te­go, że tu (bran­ża IT) pra­wo nie zabra­nia peł­nie­nia przez jeden pod­miot roli pro­jek­tan­ta i wykonawcy.

Z danych Panorama Consulting wyni­ka, że zale­d­wie 12% przed­się­biorstw nie wpro­wa­dza żad­nych mody­fi­ka­cji sys­te­mu ERP jed­nak 70% firm wpro­wa­dza mody­fi­ka­cje w apli­ka­cji się­ga­ją­ce 25% (źr. 2017-ERP-Report):

Na budowie

Autor pew­ne­go blo­ga praw­ne­go poru­szył cie­ka­wy pro­blem, któ­ry wystę­pu­je tak­że w pro­jek­tach IT. Tu nie­zbyt czę­sto (a szko­da) ale wystę­pu­je pra­wie zawsze w moich pro­jek­tach, bo ja aku­rat reali­zu­je pro­jek­ty, w któ­rych jestem zewnętrz­nym pro­jek­tan­tem. Inwestorzy to moi klien­ci, deve­lo­per reali­zu­je mój projekt.

Warto tu zwró­cić uwa­gę na to, że pro­jek­ty pro­gra­mi­stycz­ne są w pra­wie (pra­wo autor­skie i ochro­na know-how) peł­ną ana­lo­gią pro­jek­tów budow­la­nych, i prze­pi­sy te sto­su­je się odpo­wied­nio. Więcej napi­sa­łem o tym w arty­ku­le o ochro­nie know-how.

Problem, o któ­rym pisze autor jest zarzą­dza­nie zmia­ną (w IT mówi­my o kasto­mi­za­cji sys­te­mów np. ERP):

Wybudowanie obiek­tu to zło­żo­ny i dłu­go­trwa­ły pro­ces. Od pro­jek­tu do obiek­tu upły­wa dużo cza­su, a inwe­stor czę­sto zmie­nia zda­nie co do osta­tecz­ne­go kształ­tu powsta­ją­ce­go budyn­ku. Czy inwe­stor może żądać wpro­wa­dze­nia wszel­kich zmian, wedle wła­sne­go uzna­nia? Czy może zle­cić doko­na­nie zmian inne­mu pro­jek­tan­to­wi? Czy twór­ca może się zmia­nom sprze­ci­wić? Jak wyglą­da ta spra­wa na grun­cie pra­wa autor­skie­go? Wcześniej pisa­łem o zmia­nach na eta­pie pro­jek­to­wa­nia, dziś o zmia­nach na eta­pie budowania.

Projekt z dzie­dzi­ny inży­nie­rii opro­gra­mo­wa­nia, pro­wa­dzo­ny zgod­nie z naj­lep­szy­mi prak­ty­ka­mi, ma etap ana­li­zy pro­ble­mu, pro­jek­to­wa­nia archi­tek­tu­ry roz­wią­za­nia oraz two­rze­nia (dostar­cze­nia i dosto­so­wa­nia) same­go roz­wią­za­nia, któ­re reali­zu­je wybra­ny wyko­naw­ca. Tu tak­że ma miej­sce nad­zór auto­ra pro­jek­tu nad jego reali­za­cją (wytwa­rza­niem, dosto­so­wa­niem aplikacji).

To cze­go fak­tycz­nie inwe­stor może się oba­wiać, a z cze­go nie­ste­ty nagmin­nie korzy­sta­ją twór­cy opro­gra­mo­wa­nia, to nad­uży­wa­nie pozy­cji mono­po­lu autorskiego:

[…] Warto zasy­gna­li­zo­wać jesz­cze jeden aspekt zwią­za­ny ze źró­dłem poten­cjal­ne­go kon­flik­tu mię­dzy pro­jek­tan­tem, a inwe­sto­rem. Mianowicie zda­rza­ją się w prak­ty­ce sytu­acje, gdy archi­tek­ci uza­leż­nia­ją wpro­wa­dze­nie zmia­ny do pro­jek­tu zgod­nie z zamy­słem inwe­sto­ra od usta­no­wie­nia dodat­ko­we­go wyna­gro­dze­nia. W takim przy­pad­ku, pro­jek­tant powo­łu­je się na swo­je autor­skie pra­wa oso­bi­ste, któ­re zaka­zu­ją oso­bą trze­cim zmie­niać jego utwór, chcąc uzy­skać dodat­ko­wą korzyść mająt­ko­wą. Inwestor w takich sytu­acjach czę­sto był­by zupeł­nie pozba­wio­ny ochro­ny. W lite­ra­tu­rze poja­wi­ły się suge­stie, mimo licz­nych wąt­pli­wo­ści, żeby w takich przy­pad­kach powo­ły­wać się na art. 5 kc, zarzu­ca­jąc pro­jek­tan­tom nad­uży­cie swo­ich praw. (Źródło: Prawa autor­skie w ARCHITEKTURZE – Potencjalny kon­flikt inwe­sto­ra z pro­jek­tan­tem na tle pra­wa autor­skie­go – część 2 | IPblog – o pra­wie wła­sno­ści inte­lek­tu­al­nej i nowych technologii)

Oprogramowanie

W bran­ży inży­nie­rii opro­gra­mo­wa­nia dość powszech­na jest sytu­acja, gdy pro­gra­mi­sta jest tak­że pro­jek­tan­tem, inny­mi sło­wy pro­gra­mi­sta ma peł­nię praw autor­skich do kodu jaki two­rzy a jego klient żad­nych mimo, że jest inwe­sto­rem! Poniżej przy­kład zapi­su w umo­wie, któ­rą nie­daw­no audytowałem:

Wykonawca nie prze­no­si na Zamawiającego jakich­kol­wiek autor­skich praw mająt­ko­wych do Oprogramowania (co doty­czy tak­że wszyst­kich adap­ta­cji, mody­fi­ka­cji i kopii Oprogramowania oraz jego Dokumentacji).

Ten zapis ozna­cza, że dostaw­ca opro­gra­mo­wa­nia, np. opra­co­wał (udo­ku­men­to­wał) jakiś mecha­nizm dzia­ła­nia swo­je­go klien­ta (na pod­sta­wie wywia­dów z nim) i zaim­ple­men­to­wał go w wytwa­rza­nym (roz­wi­ja­nym, kasto­mi­zo­wa­nym) opro­gra­mo­wa­niu, jed­nak sta­je się tak­że posia­da­czem praw autor­skich oso­bi­stych i mająt­ko­wych do tak opra­co­wa­nej logi­ki biz­ne­so­wej, któ­rą potem sprze­da­je (a kon­kret­nie tyl­ko licen­cjo­nu­je) swo­je­mu spon­so­ro­wi (i innym swo­im klien­tom, nie raz tak­że kon­ku­ren­tom spon­so­ra). Ta logi­ka bar­dzo czę­sto sta­no­wi know-how spon­so­ra projektu!

Zapis w innej audy­to­wa­nej umo­wie doty­czą­cy prac kasto­mi­za­cyj­nych w sys­te­mie ERP, doko­ny­wa­nych przez fir­mę wdra­ża­ją­ca a nie przez pro­du­cen­ta producenta:

W przy­pad­ku wyko­na­nia mody­fi­ka­cji i dosto­so­wa­nia opro­gra­mo­wa­nia do potrzeb Zamawiającego, Wykonawca z dniem zapła­ty wyna­gro­dze­nia za Usługi dodat­ko­we obej­mu­ją­ce ww. mody­fi­ka­cje, udzie­la Zamawiającemu licen­cji na korzy­sta­nie z tych mody­fi­ka­cji przez Zamawiającego, na warun­kach na jakich udzie­lo­no uprzed­nio licen­cji na korzy­sta­nie z Oprogramowania. Wynagrodzenie za wyko­na­nie przed­mio­to­wych mody­fi­ka­cji wska­za­nych powy­żej wydzie­lo­nych czę­ści opro­gra­mo­wa­nia, obej­mu­je wyna­gro­dze­nie z tytu­łu udzie­le­nia licencji.

To już jest kurio­zum, zna­ne z aneg­dot w rodza­ju: kon­sul­tant, by odpo­wie­dzieć na pyta­nie Która jest teraz godzi­na, pro­si Klienta o jego zega­rek, odpo­wia­da na pyta­nie, a zabra­ny Klientowi zega­rek wypo­ży­cza mu za sowi­tym wynagrodzeniem”.

Ta wadli­wa sytu­acja, jaką tu opi­sa­łem, to np. cecha wszyst­kich pro­jek­tów agi­le i tych gdzie pro­gra­mi­sta jest tak­że ana­li­ty­kiem i pro­jek­tan­tem (jeże­li taki etap jest w pro­jek­cie). W efek­cie projektant/wykonawca bar­dzo czę­sto wyko­rzy­stu­je swo­ją pozy­cję podwój­nie: nie wpro­wa­dza zmian dla sie­bie nie­ko­rzyst­nych (np. trud­na i kosz­tow­na reali­za­cja) i narzu­ca zmia­ny popra­wia­ją­ce mar­że na reali­zo­wa­nym pro­jek­cie (uprasz­cza­nie), z cze­go spon­sor z regu­ły nie zda­je sobie spra­wy. Trzecim narzę­dziem” budo­wy mar­ży jest godze­nie się na wszel­kie pro­po­zy­cje inwe­sto­ra mając kon­trakt T&M, bez ostrze­ga­nia go o kon­se­kwen­cjach wpro­wa­dza­nych zmian dla całe­go pro­jek­tu (a jest nią z regu­ły dodat­ko­wa pracochłonność).

Bardzo wie­le pro­jek­tów pro­gra­mi­stycz­nych koń­czy się nie dla­te­go, że uzy­ska­no ocze­ki­wa­ną funk­cjo­nal­ność a dla­te­go, że wyczer­pa­no budżet lub czas, lub oba te zasoby.

Czy można inaczej? Oczywiście.

źr. Figure 1: Computers, Models, and the Embedding World (Smith 1985)

W umo­wie nale­ży zazna­czyć, że wszel­kie pra­ce pro­gra­mi­stycz­ne poprze­dza­ne są udo­ku­men­to­wa­ną ana­li­zą i pro­jek­to­wa­niem, i że pra­wa mająt­ko­we do tre­ści tych doku­men­tów prze­cho­dzą na Zamawiającego. Taka sytu­acja nadal jest jed­nak nie­zdro­wa, bo nadal wyko­naw­ca łączy rolę pro­jek­tan­ta i deve­lo­pe­ra (cze­go np. pra­wo budow­la­ne zabra­nia z uwa­gi na powsta­łą tak uprzy­wi­le­jo­wa­ną pozy­cję developera).

Ideałem, któ­ry moż­na łatwo osią­gnąć, jest cał­ko­wi­te oddzie­le­nie ana­li­zy i pro­jek­to­wa­nia od reali­za­cji (dla pro­jek­tów IT zale­ca to UZP w doku­men­cie z 2009 roku). W razie bra­ku takich kom­pe­ten­cji po stro­nie Zamawiającego, wystar­czy zatrud­nić pro­jek­tan­ta. Po pra­wej stro­nie powy­żej, ilu­stra­cja z 1985 roku: MODEL to owa pre­cy­zyj­na doku­men­ta­cja (to zna­czy musi być pre­cy­zyj­na, by moż­na ją było uznać za pro­jekt – utwór – chro­nio­ny prawem).

Model opro­gra­mo­wa­nia (źr. Large Scale Software Architecture, A prac­ti­cal Guide Using UML)

Co cie­ka­we, moż­na to zro­bić w dowol­nej chwi­li nawet po pod­pi­sa­niu nie­ko­rzyst­nej umo­wy (zawie­ra­ją­cej zapi­sy jak te omó­wio­ne powy­żej). W takiej sytu­acji, wyko­naw­ca, reali­zu­jąc pro­jekt, otrzy­mu­je od Zamawiającego, nie ust­ne czy nawet pisem­ne, ogól­ne idee swo­ich potrzeb, a doku­men­ty zawie­ra­ją­ce dokład­ne opra­co­wa­nie pro­jek­tu imple­men­ta­cji (logi­ka biz­ne­so­wa i archi­tek­tu­ra), któ­rą Wykonawca ma zgod­nie z umo­wą zre­ali­zo­wać. Warunkiem powo­dze­nia jest to, by autor­skie pra­wa mająt­ko­we do tych doku­men­tów były przy Zamawiającym (pro­jek­tant powi­nien prze­ka­zać pra­wa mająt­ko­we do pro­jek­tu w pisem­nie zawar­tej umo­wie). W takiej sytu­acji Wykonawca wyko­nu­je pra­wa zależ­ne do utwo­ru i mimo, że jest auto­rem imple­men­ta­cji, nie ma żad­nych praw do dys­po­no­wa­nia nią.

Autor cyto­wa­ne­go arty­ku­łu powo­łu­je się pod jego koniec na waż­ny, i czę­sto zapo­mi­na­ny para­graf Kodeksu Cywilnego:

Art. 5. Nie moż­na czy­nić ze swe­go pra­wa użyt­ku, któ­ry by był sprzecz­ny ze spo­łecz­no-gospo­dar­czym prze­zna­cze­niem tego pra­wa lub z zasa­da­mi współ­ży­cia spo­łecz­ne­go. Takie dzia­ła­nie lub zanie­cha­nie upraw­nio­ne­go nie jest uwa­ża­ne za wyko­ny­wa­nie pra­wa i nie korzy­sta z ochro­ny. (KC)

I tym akcen­tem, zakoń­czę ten krót­ki wpis 🙂 i pole­cam też lek­tu­rę całe­go cyto­wa­ne­go artykułu.

Podstawy techniczne inżynierii oprogramowania

PodstawyTechniczneInżynieriiOprogramowania1Tym razem anty­kwa­riat :). Książka leży u mnie nie­mal­że od dnia wyda­nia czy­li od roku 2004-go:
Podstawy tech­nicz­ne inży­nie­rii opro­gra­mo­wa­nia (Dick Hamlet, Joe Maybee, WNT Warszawa 2003).

Przypomniałem sobie o niej gdy stu­dent popro­sił o zale­ca­ną lite­ra­tu­rę. Zaryzykuję tezę, że to lek­tu­ra obo­wiąz­ko­wa każ­de­go ana­li­ty­ka biz­ne­so­we­go pro­jek­tan­ta (tak, ana­li­tyk biz­ne­so­wy to tak­że pro­jek­tant, odkryw­ca i pro­jek­tant logi­ki biz­ne­so­wej aplikacji).

Książka zawie­ra czte­ry części:

  1. Inżynieria opro­gra­mo­wa­nia
  2. Wymagania i specyfikacja
  3. Projektowanie i kodowanie
  4. Testowanie

Od razy zazna­czą, że mało tam o suchym kodo­wa­niu”. To była pierw­sza książ­ka, któ­ra otwo­rzy­ła mi oczy na inży­nie­rię two­rze­nia opro­gra­mo­wa­nia, klu­czo­wą role ana­li­ty­ka, któ­ry jest pro­jek­tan­tem, i zro­zu­mie­nia tego czym jest tak zwa­ny para­dyg­mat obiek­to­wy. Autorzy pre­cy­zyj­nie i dobit­nie zara­zem opi­su­ją róż­ni­cę pomię­dzy rze­mio­słem a inżynierią…

Poniżej kil­ka słów o two­rze­niu dokumentacji:

PodstawyTechniczneInżynieriiOprogramowania3

PodstawyTechniczneInżynieriiOprogramowania2

Gorąco pole­cam polo­wa­nie w antykwariatach… 🙂

Inżynieria wymagań

W grud­niu 2011 roku napi­sa­łem na zakoń­cze­nie pew­ne­go arty­ku­łu o wymaganiach:

Większość pro­jek­tów takich jak np. wdra­ża­nie nowych metod kon­tro­lin­gu, zrów­no­wa­żo­nej kar­ty wyni­ków, nowych sys­te­mów IT itp. cier­pi głów­nie z powo­du posia­da­nia nad­mia­ru infor­ma­cji z jed­nej stro­ny i kom­plet­ne­go jej nie­zro­zu­mie­nia z dru­giej. Sławne już w bada­niach ?złe i nie­kom­plet­ne wyma­ga­nia? czy ?zmia­ny zakre­su pro­jek­tu w trak­cie jego trwa­nia? to kla­sycz­ne skut­ki złej (a czę­sto pomi­ja­nia!) ana­li­zy biz­ne­so­wej. Koszty tych pora­żek wie­lo­krot­nie prze­wyż­sza­ją koszt takich ana­liz. (Analiza biz­ne­so­wa ? sku­tecz­ne mode­lo­wa­nie a ryzy­ko pro­jek­tu).

Specyfikowanie wyma­gań, zarzą­dza­nie wyma­ga­nia­mi, inży­nie­ria wyma­gań, to jak widać bar­dzo trud­ny etap pro­jek­tu. Trudność bie­rze się stad, że dostęp­ne zale­ce­nia okre­śla­ją, że wyma­ga­nia maja być np. spój­ne i kom­plet­ne ale zupeł­nie nie opi­su­ją jak to osią­gnąć (a nawet jak to spraw­dzić).

Często moż­na się spo­tkać z poję­ciem inży­nie­ria wyma­gań”. Budzi ono mój opór z dwóch powo­dów: zna­cze­nie sło­wa inży­nie­ria w j.polskim i nie­ade­kwat­ność tego sło­wa do dzie­dzi­ny jaką jest spe­cy­fi­ko­wa­nie wyma­gań, któ­re są po pro­tu listą warunków.

Zajrzyjmy do słow­ni­ka języ­ka polskiego:

inży­nie­ria ?pro­jek­to­wa­nie i kon­stru­owa­nie obiek­tów oraz urzą­dzeń technicznych?

wyma­ga­nie ?waru­nek lub zespół warun­ków, któ­rym ktoś lub coś musi odpowiadać?

Więc jak rozu­mieć zło­że­nie inży­nie­ria wyma­gań”? Ja nie wiem, chy­ba, że ktoś uwa­ża, że wyma­ga­nia się kon­stru­uje”, i że są to zagad­nie­nia tech­nicz­ne. Za to ma sens inży­nie­rii sys­te­mów”. Mamy def. poję­cia system:

sys­tem ?układ ele­men­tów mają­cy okre­ślo­ną struk­tu­rę i sta­no­wią­cy logicz­nie upo­rząd­ko­wa­ną całość?

Gdyby defi­ni­cje sło­wa inży­nie­ria” okro­ić z tech­nicz­nych” albo uznać, że sys­te­my są tak­że nie tech­nicz­ne (bo są np. spo­łecz­ne) to mamy wdzięcz­na definicję:

inży­nie­ria sys­te­mów ?pro­jek­to­wa­nie i kon­stru­owa­nie ukła­dów ele­men­tów mają­cych okre­ślo­ną struk­tu­rę i sta­no­wią­cy logicz­nie upo­rząd­ko­wa­ną całość?

Jeden z moich ulu­bio­nych auto­rów aka­de­mic­kich, Ian Sommeville (lubię go tak­że za to, że książ­ki pisze w pubach popi­ja­jąc piwo ;)) defi­niu­je inży­nie­rię wyma­gań tak:

Requirements engi­ne­ering (RE) refers to the pro­cess of for­mu­la­ting, docu­men­ting and main­ta­ining softwa­re requ­ire­ments (źr. Kotonya G. and Sommerville, I. Requirements Engineering: Processes and Techniques. Chichester, UK: John Wiley & Sons)

(poję­cie inży­nie­rii wyma­gań odno­si do pro­ce­su for­mu­ło­wa­nia, doku­men­to­wa­nia i zarzą­dza­nia wymaganiami)

Tak więc uzna­jąc, że wyma­ga­nia na sys­te­my to ele­ment inży­nie­rii tych sys­te­mów, niniej­szym godzę się uży­wać poję­cia inży­nie­ria wyma­gań” w zna­cze­niu jakim opi­sał to Sommerville :).

Po co tyle glę­dze­nia o sło­wach i ich zna­cze­niach? Poza szu­ka­niem” ali­bi dla ist­nie­nia poję­cia inży­nie­ra wyma­gań” chcę poka­zać, że sło­wa mają zna­cze­nie, zanie­dby­wa­nie tego pro­wa­dzi do wie­lu nie­po­ro­zu­mień (nie­jed­no­znacz­ność) a po dru­gie zwra­cam uwa­gę, że ana­li­za poję­cio­wa to jeden z klu­czo­wych ele­men­tów ana­li­zy w ogó­le (i czę­sto zaniedbywana).

Skoro wyma­ga­nia to warun­ki, to aż pro­si się by te warun­ki spraw­dzać. Patrzmy do słownika:

spraw­dzać ?skon­tro­lo­wać, zba­dać, czy coś jest zgod­ne z praw­dą, czy coś zosta­ło zro­bio­ne prawidłowo?

Tak więc wnio­sek jest pro­sty: wyma­ga­nie (każ­de!) powin­no być spraw­dzal­ne! Bez tego nie jeste­śmy w sta­nie okre­ślić czy coś” speł­nia te wyma­ga­nia, czy­li czy zda­nie: dostar­czo­ny pro­dukt jest zgod­ny z wyma­ga­nia­mi” jest praw­dzi­we czy nie (a nie chce­my oddać roz­strzy­ga­nia tego prawnikom ;)).

Inżynieria wymagań

Skoro więc ugią­łem się i uzna­łem poję­cie inży­nie­rii wyma­gań, popa­trz­my na to sys­te­mo­wo. Jak zawsze pro­ste jest pięk­ne więc co ana­li­zu­je­my w inży­nie­rii sys­te­mo­wej i inży­nie­rii wymagań:

Granice systemu

matrioszkaPojęcie sys­tem” to tak­że super­sys­tem (sys­tem nad­rzęd­ny) i pod­sys­tem (sys­tem pod­rzęd­ny, część sys­te­mu). To trosz­kę jak zna­ne wam, być może, matriosz­ki 🙂 (figur­ki jed­na w drugiej…).

Jest to, nazew­nic­two, bar­dzo waż­ne, bo w jed­nym pro­jek­cie (doku­men­ta­cji) nale­ży zacho­wać bez­względ­ną dys­cy­pli­nę poję­cio­wą, czy­li sło­wo System powin­no się odno­sić wyłącz­nie do kon­kret­ne­go pozio­mu opi­su, resz­ta to ele­men­ty sys­te­mu nad­rzęd­ne­go lub podrzędnego.

Mianem sys­tem okre­śla się zwy­cza­jo­wo spe­cy­fi­ko­wa­ne opro­gra­mo­wa­nie, jed­nak pro­blem poja­wi się natych­miast, gdy dotknie­my takich pojęć jak wyma­ga­nia funk­cjo­nal­ne na opro­gra­mo­wa­nie i wyma­ga­nia biz­ne­so­we. To ostat­nie nie­sie pew­ną nie­ja­sność. Bo nie wiem czy cho­dzi o wyma­ga­nia wobec (w sto­sun­ku do) biz­ne­su (np. popra­wa jako­ści obsłu­gi klien­ta o 5% w naj­bliż­szym bada­niu jako­ści ISO) czy wyma­ga­nia biz­ne­su wobec (w sto­sun­ku do) opro­gra­mo­wa­nia (np. mini­ma­li­za­cja do zera otrzy­ma­nych i zagu­bio­nych zapy­tań ofertowych).

Popatrzmy na powyż­szy dia­gram. Mamy tu dwa Systemy:

  1. Organizacja jest pod­sys­te­mem, jest ele­men­tem sys­te­mu, któ­rym tu jest rynek na jakim ta orga­ni­za­cja funkcjonuje.
  2. Organizacja jest ana­li­zo­wa­nym sys­te­mem, opro­gra­mo­wa­nie jest jed­nym z zaso­bów tej orga­ni­za­cji (opro­gra­mo­wa­nie jest tu podsystemem).

Wymagania może­my tu odno­sić w sto­sun­ku do Organizacji i w sto­sun­ku do Oprogramowania. To dla­te­go jasno wyod­ręb­nia­my ana­li­zę biz­ne­so­wą (pro­duk­tem są mode­le biz­ne­so­we i wyma­ga­nia biz­ne­so­we) od ana­li­zy wyma­gań na opro­gra­mo­wa­nie (mode­le i wyma­ga­nia na opro­gra­mo­wa­nie). Jak widać wyma­ga­nia na opro­gra­mo­wa­nie to wyma­ga­nia, któ­rych źró­dłem jest biz­nes, któ­ry ma kon­kret­ne cele do osią­gnię­cia. Nie powin­ny być one poboż­ny­mi życze­nia­mi użyt­kow­ni­ków, aż do momen­tu gdy spon­sor pro­jek­tu nie powie np.: moim celem jest wygo­da pra­cy moich pra­cow­ni­ków. Oczywiście, ta wygo­da jest zawsze wyma­ga­na ale nie musi ona być celem samym w sobie i nie musi mieć naj­wyż­sze­go priorytetu.

Wymagania inte­re­sa­riu­szy. Moja defi­ni­cja inte­re­sa­riu­sza (jed­na z wie­lu): oso­ba (pod­miot) zain­te­re­so­wa­na zaist­nie­niem pro­duk­tu, na któ­rą poja­wie­nie się pro­duk­tu ma wpływ. Nie raz jestem pyta­ny czy inte­re­sa­riusz ma pra­wo zgła­sza­nia wyma­gań. Jeżeli ma coś do powie­dze­nia pod­czas odbio­ru pro­duk­tu to zna­czy, że ma wyma­ga­nia. One mogą być jed­nak nie­jaw­ne czy­li taki inte­re­sa­riusz nie zgła­sza wyma­gań ale ma wpływ na odbiór pro­duk­tu, nale­ży go koniecz­nie ziden­ty­fi­ko­wać. Jeżeli zaś ktoś nie ma nic do gada­nia przy odbio­rze pro­duk­tu nie jest inte­re­sa­riu­szem (ang. sta­ke­hol­der, klu­czem jest tu «hol­der» czy­li dys­po­nent mają­cy coś do powie­dze­nia, mają­cy wpływ). Tak wiec inte­re­sa­riusz to ktoś kto, na swo­im pozio­mie ogól­no­ści, tak­że musi umieć okre­ślić, kie­dy uzna, że pro­dukt speł­nia jego wyma­ga­nia. Jak nie potra­fi, ktoś musi mu pomóc…analityk :)).

I tu rola ana­li­ty­ka. Interesariusz spi­su­je co mu przyj­dzie do gło­wy swo­im języ­kiem, ana­li­tyk upew­nia się, że zro­zu­miał, dopro­wa­dza je do posta­ci testo­wal­nej i kla­sy­fi­ku­je wyma­ga­nia” jako źró­dło: kon­kret­ny inte­re­sa­riusz” (bo każ­de wyma­ga­nie musi mieć wła­ści­cie­la). Proszę zwró­cić uwa­gę, że inte­re­sa­riu­szem jest tak­że użyt­kow­nik jeże­li tyl­ko ma coś go powie­dze­nia w projekcie :).

Popatrzmy na wymaganie:

Wymagania

Wymaganie jest jed­no (waru­nek jaki coś musi speł­nić) ale może ono mieć wie­le atry­bu­tów i tu widzę zło­żo­ność” wyma­gań (ich [[tak­so­no­mia]]). Zarówno wysta­wia­nie fak­tur VAT” jak i dostęp­ność 99,99% cza­su” to rów­no­praw­ne wyma­ga­nia bo opro­gra­mo­wa­nie np. wspo­ma­ga­ją­ce sprze­daż jest bez­war­to­ścio­we zarów­no gdy nie pozwa­la wysta­wiać fak­tur jak wte­dy, gdy czę­sto się psu­je. Owszem, jed­no jest funk­cjo­nal­ne dru­gie jest poza-funk­cjo­nal­ne ale jed­no i dru­gie to rów­no­praw­ny waru­nek przy­dat­no­ści” czy­li Wymaganie wobec oprogramowania.

Jak wspo­mnia­łem, wyma­ga­nia są (war­to tak robić) kla­sy­fi­ko­wa­ne za pomo­cą atry­bu­tów. Najczęściej spo­ty­ka­ne to: rodzaj (Kind), źró­dło wyma­ga­nia (Source), pole­cam tak­że prio­ry­tet, meto­dę wery­fi­ka­cji (np. test, audyt zgod­no­ści z opi­sem w doku­men­ta­cji), sta­tus (pla­no­wa­ne, zaakc­pe­to­wa­ne, odrzu­co­ne, …) i inne, zależ­nie od wyma­gań i typu projektu.

Ważna uwa­ga i zale­ce­nie IIBA: zarzą­dza­nie wyma­ga­nia­mi zabra­nia” ich usu­wa­nia (albo renu­me­ra­cji po usu­nię­ciu). usu­wa­nie powo­du­je to nie­spój­ność wer­sjo­no­wa­nej doku­men­ta­cji, któ­ra tak­że ma swój cykl życia. Ja od dłuż­sze­go cza­su sto­su­ję dodat­ko­wy sta­tus odrzu­co­ne”, co daje mi cią­głość doku­men­ta­cji a tak­że pozwa­la na odwie­sze­nie” wcze­śniej zde­fi­nio­wa­ne­go wyma­ga­nia, gdy ktoś jed­nak uzna, że coś co było zbęd­ne nagle zno­wu sta­je się konieczne :).

Liczba pytań i suge­stii (tak­że na kil­ku forach dys­ku­syj­na) skło­ni­ła mnie do pod­ję­cia pró­by zbu­do­wa­nia tak­so­no­mii wyma­gań. Jak już wspo­mnia­łem wyżej, zale­ce­nia takie jak FURPS to nie­ste­ty tyl­ko pła­ska lista cech” (i nie wszyst­kich). Wydaje mi się, że struk­tu­ra wyma­gań, ich tak­so­no­mia wza­jem­ne zależ­no­ści oraz rela­cje do udzia­łow­ców pro­jek­tu (inte­re­sa­riu­sze) i przy­szłych użyt­kow­ni­ków roz­wią­za­nia, wyma­ga­ją bar­dziej for­mal­ne­go podej­ścia. Celem jest uzy­ska­nie moż­li­wo­ści spraw­dza­nia czy wyma­ga­nia – jako przed­miot inży­nie­rii wyma­gań – speł­nia­ją jakieś, trze­ba je stwo­rzyć, wymagania.

Taksonomia wymaganPowyżej pró­ba usys­te­ma­ty­zo­wa­nia wyma­gań” na bazie wyżej cyto­wa­nych defi­ni­cji tego pojęcia.

Na koniec jesz­cze kolej­na waż­na rzecz. Warto wska­zy­wać, któ­re ele­men­ty logi­ki biz­ne­so­wej (Model) odpo­wia­da­ją (są powią­za­ne) z danym wyma­ga­niem bo np. szcze­gó­ło­wo opi­su­ją wyma­ga­ny spo­sób reali­za­cji dane­go wyma­ga­nia (np. sys­tem upu­stów albo kon­kret­ny przy­pa­dek uży­cia, tak­że Model). Warto tak­że, jeże­li opis wyma­ga­nia nie jest testem, zapro­jek­to­wać test (przy­pa­dek testo­wy), któ­ry potwier­dzi speł­nie­nie wyma­ga­nia np. opro­gra­mo­wa­nie ma pozwa­lać na wyli­cza­nie pier­wiast­ków dru­gie­go i trze­cie­go stop­nia”. Tu war­to podać kil­ka kon­kret­nych danych wej­ścio­wych wraz z pra­wi­dło­wy­mi wyni­ka­mi (może to doty­czyć nap. tabe­li upu­stów, sys­te­mu sko­rin­gu klien­tów itp.).

Tego typu meto­dy maja nazwę deklaratywnych:

Programowanie dekla­ra­tyw­ne ? rodzi­na para­dyg­ma­tów pro­gra­mo­wa­nia, któ­re nie są z natu­ry impe­ra­tyw­ne. W prze­ci­wień­stwie do pro­gra­mów napi­sa­nych impe­ra­tyw­nie, pro­gra­mi­sta opi­su­je warun­ki, jakie musi speł­niać koń­co­we roz­wią­za­nie (co chce­my osią­gnąć), a nie szcze­gó­ło­wą sekwen­cję kro­ków, któ­re do nie­go pro­wa­dzą (jak to zro­bić). Programowanie dekla­ra­tyw­ne czę­sto trak­tu­je pro­gra­my jako pew­ne hipo­te­zy wyra­żo­ne w logi­ce for­mal­nej, a wyko­ny­wa­nie obli­czeń jako ich dowo­dze­nie. Programowanie dekla­ra­tyw­ne jest szcze­gól­nym przed­mio­tem zain­te­re­so­wa­nia naukow­ców, gdyż dzię­ki mini­ma­li­za­cji lub eli­mi­na­cji skut­ków ubocz­nych może zna­czą­co upro­ścić two­rze­nie pro­gra­mów współ­bież­nych. Paradygmat pro­gra­mo­wa­nia dekla­ra­tyw­ne­go obej­mu­je sze­ro­ką gamę języ­ków pro­gra­mo­wa­nia i bar­dziej szcze­gó­ło­wych para­dyg­ma­tów pod­rzęd­nych. (Programowanie dekla­ra­tyw­ne ? Wikipedia, wol­na ency­klo­pe­dia).

TOGAF or not TOGAF więc może Zachman

Badanie przy­dat­no­ści TOGAF/ArchiMate mam chy­ba za sobą (zapew­ne nie na mia­rę dok­to­ra­tu ale trosz­kę jed­nak tak, cho­ciaż…;)). Na stro­nie moje­go kole­gi: ArchitekturaKorporacyjna​.pl (pole­cam ana­li­ty­kom), w jed­nym z arty­ku­łów poja­wia się cie­ka­we stwierdzenie:

TOGAF wska­zu­je, że nie­wła­ści­we pod­czas mode­lo­wa­nia jest bez­po­śred­nie wią­za­nie pro­ce­su [biz­ne­so­we­go, jak sądzę] z apli­ka­cją go wspie­ra­ją­cą ? ele­men­tem pośred­nim powin­na być funk­cja ? czy­li: apli­ka­cja wspie­ra reali­za­cję funk­cji, a funk­cja obej­mu­je cały pro­ces lub jego frag­ment (w zależ­no­ści od pozio­mu dekom­po­zy­cji funk­cji biz­ne­so­wej). (Komentarze do TOGAF ? meta­mo­del zawar­to­ści (cz. II) | Architektura Korporacyjna).

i to jest coś co jako pierw­sze mnie zra­zi­ło w nota­cji ArchiMate: prze­rost poję­cio­wy (roz­drob­nie­nie albo jak kto woli nad­mier­na gra­da­cja). Umieszczenie dodat­ko­we­go poję­cia – funk­cja – pomię­dzy pro­ce­sem biz­ne­so­wym (pamię­ta­my, że samo­dziel­na czyn­ność to tak­że pro­ces) a narzę­dziem pra­cy jakim jest opro­gra­mo­wa­nie wyda­je się sztucz­ne. To trosz­kę jak umiesz­cze­nie pomię­dzy młot­kiem a pro­ce­sem wbi­ja­nia gwoź­dzia funk­cji wbi­ja­nie”, nie wiem jaką war­tość wno­si to do mode­lu, sko­ro mło­tek ma funk­cję (przy­pa­dek uży­cia) wbi­ja­nie” (pamię­taj­my, że opro­gra­mo­wa­nie to narzę­dzie pra­cy akto­ra, zasób).

Prowadzi to do nie­kom­pa­ty­bil­no­ści z sys­te­mem poję­cio­wym para­dyg­ma­tu obiek­to­we­go (MDA/OMG), na któ­ry ArchiMate się powo­łu­je, tym bar­dziej, że jed­nak MDA to stan­dard pro­ce­su obiek­to­we­go two­rze­nia opro­gra­mo­wa­nia więc po co z nim wal­czyć? Testowałem mode­le ArchiMate na ludziach” i oka­zy­wa­ło się, że dla wie­lu z nich tak­że są one nie­in­tu­icyj­ne. Trudno mi też wytłu­ma­czyć ten nad­miar poję­cio­wy: sko­ro w natu­rze” czyn­ność jest wspie­ra­na usłu­gą sys­te­mu” to po co pako­wać mię­dzy nie, mię­dzy tę wód­kę a zaką­skę” ;), poję­cie biz­ne­so­wej funk­cji opro­gra­mo­wa­nia sko­ro ono świad­czy jakąś usłu­gę, bo jest ona funk­cjo­nal­no­ścią tego oprogramowania.

Trzy warstwy modelowaniaAutorzy ArchiMate wska­zu­ją, że tam gdzie ArchiMate jest zbyt ogól­ne, nale­ży użyć odpo­wied­nio BPMN lub UML. Ale tu poja­wia się pro­blem: w UML usłu­ga opro­gra­mo­wa­nia to przy­pa­dek uży­cia powią­za­ny bez­po­śred­nio z akto­rem, któ­ry ma swój cel dzia­ła­nia (uży­cia sys­te­mu w trak­cie reali­za­cji pro­ce­su biz­ne­so­we­go). Czyli usłu­ga opro­gra­mo­wa­nia jest jed­nak poję­cio­wo bez­po­śred­nio zwią­za­na z czyn­no­ścią w pro­ce­sie, któ­rą wspie­ra (cel pra­cy akto­ra). To tyl­ko jed­na z nie­spój­no­ści. Jeżeli uznać, że pro­ces two­rze­nia opro­gra­mo­wa­nia to trzy fazy MDA opi­sa­ne przez OMG czy­li CIM, PIM i PSM (model biz­ne­so­wy, model logi­ki sys­te­mu, model jego imple­men­ta­cji), to nie­ste­ty TOGAF i ArchiMate są z nim nie­kom­pa­ty­bil­ne a TOGAF/ArchiMate nie daje nic w zamian, więc jest problem…

Z dru­giej stro­ny potrzeb­ne jest w każ­dym więk­szym pro­jek­cie upo­rząd­ko­wa­nie wie­dzy o orga­ni­za­cji z pomo­cą mode­li (któ­rych tu będzie wię­cej nią jeden) czy­li zro­zu­mie­nie jej zacho­wa­nia, wyma­ga to uję­cia tych mode­li w struk­tu­rę. Po co? By mieć mier­nik pozwa­la­ją­cy odpo­wie­dzieć na pyta­nie: Czy mamy już wszyst­kie potrzeb­ne mode­le, czy rozu­mie­my tę orga­ni­za­cję. Modele te to: pro­ce­sy biz­ne­so­we oraz obiek­to­we struk­tu­ry opro­gra­mo­wa­nia. Do tego mode­le poję­cio­we i regu­ły biz­ne­so­we. Wszystko to – nota­cje i ich mode­le poję­cio­we – jest bar­dzo dobrze opra­co­wa­ne w przez OMG. Czego bra­ku­je? Metamodelu cało­ści. Tu z pomo­cą przy­cho­dzi tak zwa­na [[Siatka Zachmana]]. Cóż to jest?

Siatka Zachmana (ang. Zachman Framework) ? sza­blon i spo­sób postę­po­wa­nia, któ­ry pozwa­la w spo­sób for­mal­ny i ści­śle ustruk­tu­ra­li­zo­wa­ny defi­nio­wać archi­tek­tu­rę sys­te­mów kor­po­ra­cyj­nych. Używa siat­ki bazu­jąc na sze­ściu pod­sta­wo­wych pyta­niach (Co, Jak, Gdzie, Kto, Kiedy, Dlaczego) zada­nych pię­ciu gru­pom użyt­kow­ni­ków (Planujący, Właściciel, Projektant, Twórca, Podwykonawca) aby przed­sta­wić holi­stycz­ny obraz przed­się­bior­stwa, któ­re jest mode­lo­wa­ne. (Siatka Zachmana ? Wikipedia, wol­na ency­klo­pe­dia).

Taka kom­plet­na siat­ka (matry­ca) wyglą­da tak:

Siatka Zachmana zakres analizy

Jest to peł­ny opis orga­ni­za­cji. Nie zawsze jest potrze­ba two­rze­nia cało­ści. Na eta­pie typo­wej ana­li­zy biz­ne­so­wej i ana­li­zy wyma­gań potrzeb­ne są eta­py CIM i PIM. W siat­ce Zachmana moż­na pomi­nąć zbęd­ne (tu nad­mia­ro­we, Zachman dopusz­cza czę­ścio­we struk­tu­ry) kolum­ny i wier­sze nadal zacho­wu­jąc kom­pa­ty­bil­ność z MDA:

Siatka Zachmana zakres analizy CIM PIM

Powyższe to nic inne­go jak matry­ca pozwa­la­ją­ca zbu­do­wać upo­rząd­ko­wa­ny model orga­ni­za­cji i umie­ścić w nim ist­nie­ją­ce, wspie­ra­ją­ca ją opro­gra­mo­wa­nie i (lub) opi­sać to, któ­re powin­no się w niej poja­wić czy­li wyma­ga­nia. Powyższe mapu­je się w 100% na model MDA: CIM i PIM. Nie trze­ba więc nicze­go zmie­niać a model poję­cio­wy jest spój­ny. Jeżeli ktoś korzy­sta z mode­lu MDA/OMG, bez pro­ble­mu może przy­po­rząd­ko­wać polom (prze­cię­cia wier­szy i kolumn) mode­le nota­cji BPMN, UML i BMM, a tak­że sys­te­my reguł biz­ne­so­wych i słow­nik pojęć dzie­dzi­no­wych. (powyż­sze zrzu­ty ekra­no­we narzę­dzia Agilian)

Z każ­dym kolej­nym pro­jek­tem skła­niam się ku tezie, że Architektura Korporacyjna, jako cało­ścio­we (lub jak kto woli: holi­stycz­ne) podej­ście do doku­men­to­wa­nia (mode­lo­wa­nia) orga­ni­za­cji, bliż­sza jest Siatce Zachmana niż TOGAF’owi, któ­ry w moich oczach jest po pro­tu prze­kom­bi­no­wa­ny i nie­kom­pa­ty­bil­ny z nota­cja­mi, od któ­rych raczej nie ma uciecz­ki (BPMN, UML, BMM a nawet struk­tu­ral­ne ERD i DFD).

Powyższy uprosz­czo­ny (wyłą­czo­ne nie­uży­wa­ne wier­sze i kolum­ny) kształt Siatki Zachmana, coraz czę­ściej słu­ży mi jako zakres pro­jek­tu ana­li­tycz­ne­go i korzeń jego struk­tu­ry. Poszukując mate­ria­łów na ten temat zna­la­złem opra­co­wa­nie opu­bli­ko­wa­ne na stro­nie Business Process Trends już w 2003 roku o wdzięcz­nym tytu­le: [[The Zachman Framework and the OMG’s Model Driven Architecture]]. Poniżej, na zakoń­cze­nie, dwa dia­gra­my zapo­ży­czo­ne z tego opracowania:

- mapo­wa­nie MDA na Siatkę Zachmana:

MDA2Zachman

oraz wska­za­nie, gdzie zasto­so­wać nota­cje UML:

UML2ZachmanPowyższy dia­gram war­to uzu­peł­nić uwa­gą, że zasto­so­wa­nie nota­cji BPMN w obsza­rze pro­ce­sów biz­ne­so­wych wyda­je się być obec­nie znacz­nie roz­sąd­niej­sze (w 2003 roku, nie była sto­so­wa­na), zaś w obsza­rze moty­wa­cji dosko­na­le spra­wu­je się BMM. OMG daje tak­że upo­rząd­ko­wa­ne sys­te­mu zapi­su reguł biz­ne­so­wych i słow­ni­ków pojęć.

TOGAF ma ambi­cje porów­ny­wa­nia się z Siatką Zachmana, jed­nak w moim odczu­ciu obsza­ro­we porów­na­nie – zgod­ność – to nie to samo z kom­pa­ty­bil­ność (tu już jej brak) z sys­te­ma­mi poję­cio­wy­mi (uzna­ny­mi za stan­dar­dy nota­cja­mi), bo to tu tkwi sens i sed­no pro­ble­mu. Jak na razie nie sądzę, by nota­cja ArchiMate – język wyra­zu TOGAF’a – wypar­ło doro­bek OMG, a nie­ste­ty nie jest w sta­nie go zastą­pić. Obecna postać Siatki Zachman v.3.0. to już ugrun­to­wa­na onto­lo­gia. (czy­sty pla­kat ZachmaFramework 3.0, widać na nim bar­dzo waż­ną rzecz: śla­do­wa­nie, mapo­wa­nie pomię­dzy modelami).

Siatka Zachmana w uży­ciu – pakiet Visual-Paradigm.

c.d.n.

Słabości tradycyjnych metod wytwarzania IT – czy na pewno słabości?

SCRUM

Nie jestem zwo­len­ni­kiem kla­sycz­ne­go, kaska­do­we­go pro­ce­su pro­jek­to­wa­nia i wytwa­rza­nia opro­gra­mo­wa­nia. Preferuje pro­ces podob­ny do kaska­do­we­go, z pro­to­ty­pa­mi odrzu­ca­ny­mi, jed­nak pro­to­ty­pem jest u model (pro­jekt) a nie żywy kod. Proces taki opi­su­je np. meto­dy­ka MDA (wię­cej na stro­nie OMG, przyj­dzie pora i na nie­go tu). Jednak pro­pa­gan­da mówi, że jak powszech­nie wiadomo”…

…model kaska­do­wy ska­zu­je klien­ta na dłu­gi czas ocze­ki­wa­nia na efekt koń­co­wy. Bardzo dużo cza­su pochła­nia­ją ana­li­zy przed­wdro­że­nio­we i szcze­gó­ło­we pro­jek­ty, a ich wynik jest widocz­ny wyłącz­nie ?na papie­rze?. (za Scrum eli­mi­nu­je sła­bo­ści tra­dy­cyj­nych metod wytwa­rza­nia IT).

I od razu do rze­czy. Powyższe nie jest praw­dą. Badania pro­jek­tów poka­zu­ją coś zupeł­nie odwrotnego:

Statystyka pracochłonności projektów IT

Jak widać, popraw­na (o takiej tu mowa) ana­li­za wyma­gań, skra­ca czas imple­men­ta­cji (pro­jek­to­wa­nie i wyko­na­nie) o ponad poło­wę. Po dru­gie owe zwin­ne ite­ra­cje to nic inne­go jak odkry­wa­nie wyma­gań meto­dą prób i błę­dów, co jest cza­so­chłon­ne i kosz­tow­ne, co widać na powyż­szym dia­gra­mie (poka­zu­je on sta­ty­sty­ki ukoń­czo­nych projektów).

A co jest prawdą?

To, że ów czas trwa­nia pro­jek­tu jest dłu­gi, to naj­czę­ściej efekt zbyt duże­go zakre­su tego pro­jek­tu a nie tej czy innej meto­dy­ki. Po pro­stu sys­tem mają­cy 200 pla­no­wa­nych cech funk­cjo­nal­nych będzie budo­wa­ny dłu­go nie dla­te­go, że wybra­no kaska­do­wą meto­dy­kę” tyl­ko dla­te­go, że jest duży”.

Cytowany arty­kuł (zachwa­la­ją­cy meto­dy­kę SCRUM) wska­zu­je na kil­ka wad” ana­li­zy i pro­jek­to­wa­nia, zobacz­my co tu jest wadą…

Ryzyko uzy­ska­nia nie­ade­kwat­ne­go roz­wią­za­nia ? model kaska­do­wy ska­zu­je klien­ta na dłu­gi czas ocze­ki­wa­nia na efekt koń­co­wy. Bardzo dużo cza­su pochła­nia­ją ana­li­zy przed­wdro­że­nio­we i szcze­gó­ło­we pro­jek­ty, a ich wynik jest widocz­ny wyłącz­nie ?na papierze?.

  • Z punk­tu widze­nia klien­ta, ana­li­zy to bar­dzo istot­ny koszt, któ­ry dłu­go się zwra­ca ? klient pła­ci za doradz­two, czę­sto nie widząc żad­ne­go real­ne­go rezul­ta­tu poza doku­men­ta­mi. Skomplikowane i zło­żo­ne pro­jek­ty to dla orga­ni­za­cji wiel­ka odpo­wie­dzial­ność, tym­cza­sem w podej­ściu kaska­do­wym im bar­dziej zło­żo­ne pro­jek­ty, tym moc­niej rośnie ryzy­ko zwią­za­ne z rezul­ta­tem końcowym.
  • Przy zasto­so­wa­niu Scrum takie ryzy­ko prak­tycz­nie nie ist­nie­je. Obie stro­ny wie­dzą, że w okre­sie współ­pra­cy mogą wypra­co­wać roz­wią­za­nie, któ­re­go nie moż­na było prze­wi­dzieć na począt­ku pro­jek­tu. Przy tym zwin­nym podej­ściu coś takie­go jak osta­tecz­na defi­ni­cja final­nej wer­sji pro­duk­tu na począt­ku pro­jek­tu nie ist­nie­je.

I to jest ten moment, gdy ja pytam: na co zawar­to umo­wę i z cze­go jest roz­li­cza­ny dostaw­ca? Tak więc dostaw­ca jest prak­tycz­nie bez­kar­ny, bo może dostar­czyć cokol­wiek… jak nazwać to ryzy­ko? Po dru­gie kry­ty­ka pro­ce­su ana­li­zy jako zbęd­ne­go poże­ra­cza cza­su i środ­ków wyma­gań nijak się ma do prak­ty­ki, co poka­zu­je przy­to­czo­ny na począt­ku wynik badań.

I dalej:

Opóźniony rezul­tat ? celem IT bar­dziej niż kie­dy­kol­wiek wcze­śniej jest dziś wspie­ra­nie biz­ne­su w jego codzien­nych dzia­ła­niach i szyb­kie reago­wa­nie na dyna­micz­ne zmia­ny w oto­cze­niu biz­ne­so­wym. W mode­lu kaska­do­wym na rezul­tat pro­jek­tu cze­ka się dłu­go, ponie­waż okre­śla go peł­na, final­na wer­sja produktu.

Dobry pro­jekt ma wizję i eta­py. Każdy etap to ogra­ni­czo­na licz­ba funk­cjo­nal­no­ści, moż­li­wych do dostar­cze­nia w cza­sie wyma­ga­nym przez biz­nes. Nie widzę powo­dów, by dzia­ła­ją­ce pod­sys­te­my dostar­czać np. kwar­tal­nie, i tak się dzieje.

Bardzo mała ela­stycz­ność pod­czas pro­jek­tu ? biz­nes ule­ga cią­głym zmia­nom, co w oczy­wi­sty spo­sób pocią­ga za sobą zmia­ny ocze­ki­wań doty­czą­cych funk­cjo­nal­no­ści zama­wia­ne­go opro­gra­mo­wa­nia. Model kaska­do­wy kon­trak­tu­je pro­jekt na eta­pie ana­liz (lub nawet wcze­śniej), po czym obu stro­nom trud­no jest bez ryzy­ka wno­sić istot­ne zmia­ny do zapla­no­wa­nych prac.

Po pierw­sze nie wiem skąd autor wziął tezę o tym, że Model kaska­do­wy kon­trak­tu­je pro­jekt na eta­pie ana­liz (lub nawet wcze­śniej”. Model kaska­do­wy nie ma tu nic do rze­czy. Dobra umo­wa zawie­ra zakres pro­jek­tu, a pro­jekt ma cel biz­ne­so­wy, i nie powin­no nim być zatrud­nie­nie pro­gra­mi­stów na kwar­tał po jakiejś staw­ce, a wytwo­rze­nie cze­goś kon­kret­ne­go i nazwa­ne­go w kon­kret­nym czasie.

System, w któ­rym imple­men­ta­cję poprze­dza ana­li­za i pro­jek­to­wa­nie dzie­li się na eta­py jak każ­dy inny. Po dru­gie nie praw­dą jest, że kon­trak­tu­je się od razu całość. Dobry pro­jekt ma oddzie­lo­ny etap pro­jek­to­wa­nia od wyko­na­nia, klu­czem jest raczej to na jaki zakres rzu­ca się”, zamawiający.

Potencjalnie więk­sze kosz­ty ? w pro­jek­tach IT liczy się nie tyl­ko zwrot z inwe­sty­cji (ROI), ale też czas, w jakim ponie­sio­ne inwe­sty­cje zaczy­na­ją się zwracać.

Tu odno­szę wra­że­nie, że autor nie rozu­mie co napi­sał albo jest to błąd redak­cyj­ny… zwrot z inwe­sty­cji to zysk w cza­sie, więc nie ma zna­cze­nia nic poza cał­ko­wi­tym kosz­tem i cza­sem w jakim go liczymy.

Biznes jest dziś tak dyna­micz­ny, że dużą korzy­ścią jest dla nie­go względ­nie szyb­ki dostęp do dosta­tecz­nie dobrych roz­wią­zań. W podej­ściu kaska­do­wym czas ocze­ki­wa­nia na final­ny pro­dukt jest bar­dzo długi.

Kolejna nie­praw­da, czas ocze­ki­wa­nia jest dokład­nie taki jaki zapla­no­wa­no… moż­na pla­no­wać podział duże­go pro­jek­tu na pod­sys­te­my (jak wyżej).

Duże ryzy­ko złych rela­cji ? model kaska­do­wy z zało­że­nia dzie­li obie stro­ny kon­trak­tu na dwa obo­zy: dostaw­cy i odbior­cy rozwiązania.

To cie­ka­wost­ka, nie wiem skąd autor wysnuł taki wniosek.…

Marnotrawstwo cza­su i pie­nię­dzy przez biu­ro­kra­cję ? pra­ca opar­ta na czę­stych ite­ra­cjach i powta­rzal­nym pro­ce­sie (sprin­tach) pozwa­la bar­dzo szyb­ko iden­ty­fi­ko­wać nie­do­sko­na­ło­ści spe­cy­fi­ka­cji i luki w pier­wot­nej kon­cep­cji. Strony mogą szyb­ko zorien­to­wać się, że na eta­pie przy­go­to­waw­czym np. nie wzię­to pod uwa­gę istot­nych kom­po­nen­tów lub inter­fej­sów. W mode­lu wodo­spa­do­wym wno­sze­nie zmian wią­że się naj­czę­ściej z pisa­niem anek­sów i rene­go­cjo­wa­niem kontraktu.

Kolejna nie­praw­da. czę­ste ite­ra­cje to czę­ste popraw­ki pro­jek­tu w poszu­ki­wa­niu wła­ści­we­go roz­wią­za­nia”. Takie same ite­ra­cje robi ana­li­tyk na eta­pie ana­li­zy i pro­jek­to­wa­nia, two­rząc pro­jekt na papie­rze”, rzecz w tym, że ana­li­tyk na papie­rze robi to sam w cią­gu poje­dyn­czych godzin a zespół pro­gra­mi­stów robi to kil­ka dni kosz­tem kil­ku­na­stu oso­bod­nió­wek” tego zespo­łu. Koszty i czas łatwo sobie porównać…

W Scrum wszyst­kie nie­do­pa­trze­nia moż­na natych­miast uwzględ­nić na każ­dym eta­pie reali­za­cji pro­jek­tu, bez koniecz­no­ści uru­cha­mia­nia nie­wy­god­nej dla obu stron, i czę­sto burzą­cej rela­cje biz­ne­so­we, pro­ce­du­ry obsłu­gi zmian (Change Requests). Jeśli podej­ście słu­ży pro­jek­to­wi, a tak jest w przy­pad­ku Scrum, dostaw­ca i odbior­ca ela­stycz­nie dopa­so­wu­ją się do sie­bie nie­za­leż­nie od tego, jak dale­ce zmie­nia­ją się ocze­ki­wa­nia i potrze­by biznesowe.

Jeżeli autor uwa­ża, że wpro­wa­dza­nie ad-hoc nie­for­mal­nych zmian w zakre­sie pro­jek­tu czy­ni pro­jekt lep­szym, to pozo­sta­wiam go z tym przeświadczeniem.

Scrum pole­ga na wspól­nym widze­niu celu, jakim jest roz­wią­za­nie kon­kret­ne­go pro­ble­mu biz­ne­so­we­go. Jest to czę­sto dale­kie odej­ście od sztyw­nej inter­pre­ta­cji zapi­sów kon­trak­to­wej spe­cy­fi­ka­cji wyma­gań, któ­re same w sobie narzu­ca­ją zespo­łom pro­jek­to­wym ogra­ni­cze­nia reali­za­cyj­ne (tech­nicz­ne) nie­za­leż­nie od pro­ble­mu jaki jest rze­czy­wi­ście do roz­wią­za­nia. Zaletą Scrum jest przej­rzy­stość i wyso­ka ela­stycz­ność projektu.

Tu przy­to­czę sło­wa moje­go kole­gi prawnika:

Największym pro­ble­mem spo­rów przed sądem, w spo­rach z fir­ma­mi pro­gra­mi­stycz­ny­mi jest to, że wie­le tych firm nicze­go nie doku­men­tu­je i tak na praw­dę nie wia­do­mo o co toczy się spór. Większość takich spraw zakła­da­ją pokrzyw­dzo­ne fir­my, nabyw­cy usług pro­gra­mi­stycz­nych. W zasa­dzie więk­szość tych spraw, te fir­my wła­śnie prze­gry­wa­ją, bo nie wia­do­mo co mia­ło powstać a wia­do­mo ile mia­ło kosz­to­wać. Tu sądy są bez­sil­ne… wygry­wa­ją pro­gra­mi­ści, mając pie­nią­dze mimo, że nie osią­gnię­to celu zama­wia­jąc. Ale win­ni są sobie wyłącz­nie zama­wia­ją­cy, godzą­cy się na taką treść tych umów…

A co mówią statystyki?

Analysts report that as many as 71 per­cent of softwa­re pro­jects that fail do so becau­se of poor requ­ire­ments mana­ge­ment, making it the sin­gle big­gest reason for pro­ject failure?bigger than bad tech­no­lo­gy, mis­sed deadli­nes or chan­ge mana­ge­ment fia­sco­es. ( źr. Fixing the Software Requirements Mess CIO​.com).

Parząc na powyż­sze (wytłusz­cze­nie: w więk­szo­ści z ponad 71% złych pro­jek­tów pro­gra­mi­stycz­nych, powo­dem kło­po­tów było złe zarzą­dza­nie wyma­ga­nia­mi, co czy­ni­ło więk­sze szko­dy niż pozo­sta­łe powo­dy, takie jak tech­no­lo­gie, napię­te ter­mi­ny czy zarzą­dza­nie zmia­na­mi, razem wzię­te). I niech nikt mi nie mówi, że 29% to same SCRUM’y a pozo­sta­łe 71% to kaska­do­we” pro­jek­ty bo to nieprawda.

Na zakończenie

Tak więc zasta­nów­my się czy aby na pew­no brak pro­jek­tu i spe­cy­fi­ka­cji wyma­gań to dobry spo­sób na pro­jekt IT. Czy meto­dy wytwa­rza­nia bazu­ją­ce na bra­ku pier­wot­ne­go pro­jek­tu, fak­tycz­nie są zba­wie­niem pro­jek­tów pro­gra­mi­stycz­nych… Państwo sami muszą wybrać… Dodam na koniec, że powyż­sze doty­czy w takim samym stop­niu sys­te­mów dedy­ko­wa­nych jak i goto­wych a wyma­ga­ją­cych kasto­mi­za­cji” bo to (nowe funk­cjo­nal­no­ści sys­te­mu) tak­że pro­jekt dedykowany.

Dilbert wymagania na oprogramowanie