Inżynieria oprogramowania z użyciem narzędzia CASE – przykładowy projekt Biblioteka

W dniu 11.12.2020, uda­ło mi się w koń­cu prze­pro­wa­dzić pre­zen­ta­cję on-line. Celem była pre­zen­ta­cja reali­za­cji meto­dy MBSE z narzę­dziem CASE (tu Visual-Paradigm) i jej efek­tów. Adresatem są zarów­no ana­li­ty­cy, archi­tek­ci opro­gra­mo­wa­na jak i deve­lo­per (pro­gra­mi­ści) jako osta­tecz­ny adre­sat doku­men­tu. Podobną pre­zen­ta­cję pro­wa­dzi­łem wcze­śniej na Konferencji beIT 2020. Popularność tych pre­zen­ta­cji spo­wo­do­wa­ła, że całość prze­ro­dzi­ła się w pro­jekt badawczy. 

Czytaj dalej… Inżynieria opro­gra­mo­wa­nia z uży­ciem narzę­dzia CASE – przy­kła­do­wy pro­jekt Biblioteka”

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.

Przypadki użycia czy model procesu, czego używać?

Dość czę­sto spo­ty­kam sie z teza­mi, że uży­cie przy­pad­ków uży­cia nie wyma­ga mode­lo­wa­nia pro­ce­sów i odwrot­nie, albo że są to narzę­dzia” ofe­ru­ją­ce podob­ne lub takie same korzy­ści, np. tak jak tu:

So, as you can see we used dif­fe­rent tech­ni­qu­es and basi­cal­ly the result is the same. It was not real­ly impor­tant what tech­ni­qu­es were used unless solu­tion design is com­ple­te. It?s just a mat­ter of a habit so if you?re more com­for­ta­ble with use cases then stick to them or if you?re more fami­liar with pro­cess maps then draw a map. But note that in some cases you may be requ­ested to use a spe­ci­fic tech­ni­que that is a cor­po­ra­te stan­dard or becau­se the­re is an agre­ement that all BAs on the pro­ject will use one tem­pla­te (tech­ni­que) for con­si­sten­cy. (Źródło: Use cases or busi­ness pro­cess maps, what tech­ni­que to use?)

Sugeruję naj­pierw zapo­znać się z cyto­wa­nym powy­żej tek­stem a po zapo­zna­niu się z nim zapra­szam do dal­szej lek­tu­ry. Jak się komuś nie chce powyż­sze­go czy­tać, może potrak­to­wać mój tekst jak zwy­kły post a nie jak polemikę ;). 

Zacznę od mode­lu pro­ce­sów w BPMN jaki pre­zen­tu­je jego autor;

źr. http://​www​.moder​na​na​lyst​.com/​R​e​s​o​u​r​c​e​s​/​A​r​t​i​c​l​e​s​/​t​a​b​i​d​/​1​1​5​/​I​D​/​3​6​5​8​/​U​s​e​-​c​a​s​e​s​-​o​r​-​b​u​s​i​n​e​s​s​-​p​r​o​c​e​s​s​-​m​a​p​s​-​w​h​a​t​-​t​e​c​h​n​i​q​u​e​-​t​o​-​u​s​e​.​a​spx

Pierwsza rzecz: co do zasa­dy Klient i Podmiot go obsłu­gu­ją­cy to dwa odręb­ne pod­mio­ty więc dia­gram ten powi­nien zawie­rać dwie pule, a nie jed­ną wspól­ną pulę (albo jak kto woli base­ny). Dalej. BPMN w spe­cy­fi­ka­cji trak­tu­je tory wyłącz­nie jak uni­wer­sal­ne ele­men­ty gru­pu­ją­ce (nie są one jed­nak eks­por­to­wa­ne do pli­ków wymia­ny XPBL czy BPEL4WS), nie ma zaka­zu sto­so­wa­nie torów do repre­zen­to­wa­nia sys­te­mów”, model biz­ne­so­wy CIM (defi­ni­cja MDA) zaka­zu­je. Od sie­bie dodam, że to czym będą tory nale­ży zde­fi­nio­wać na począt­ku ana­li­zy (i powin­na to być jed­na spój­na definicja). 

Autor powyż­sze­go dia­gra­mu na jed­nym dia­gra­mie poka­zał wszyst­ko co wie, łamiąc nota­cyj­ne zasa­dy sto­so­wa­ni puli (base­nu) oraz dobre prak­ty­ki nie mie­sza­nia róż­nych kon­tek­stów na jed­nym modelu.

Model pro­ce­su powi­nien mieć zawsze kon­kret­ny kon­tekst i być osa­dzo­ny w jakiejś meto­dy­ce, bez tego trud­no pod­jąć decy­zję, któ­re infor­ma­cje są istot­ne i jakie deta­le poka­zy­wać (bo nota­cje są nad­mia­ro­we i nie są meto­dy­ką). Bez tego tak­że trud­no innej oso­bie taki dia­gram jed­no­znacz­nie zin­ter­pre­to­wać. Najgorsze wyj­ście to nie wiem, więc poka­że wszyst­ko co wiem” z czym tu mamy moim zda­niem do czynienia.

Jak to robić? Przyjmuję postę­po­wa­nie zgod­ne MDA/MDE (pisa­łem tu o tym nie raz), więc naj­pierw two­rzy­my model CIM (Computation Independent Model), któ­re­go celem jest zro­zu­mie­nie i udo­ku­men­to­wa­nie mecha­ni­zmu – tu – reje­stra­cji kon­ta, typo­wy mecha­nizm opt-in:

Co do zasa­dy aktyw­ność w pro­ce­sie to coś co sta­no­wi kom­plet­nie wyko­na­ną pra­cę (bo pro­ces to aktyw­ność prze­kształ­ca­ją­ca wej­ście w wyj­ście), więc dzie­le­nie jej na kawał­ki nie ma żad­ne­go uza­sad­nie­nia. Detale aktyw­no­ści poka­zu­je­my na odręb­nym dia­gra­mie, a czę­ściej jako zapi­sa­ną tek­stem pro­ce­du­rę (jest nie­po­dziel­na bo aktyw­ność jest jed­na). Np. aktyw­ność Rejestracja po stro­nie (w puli) Klienta to:

  1. ini­cja­cja reje­stra­cji konta
  2. SYSTEM wyświe­tla for­mu­larz Dane użytkownika
  3. wypeł­nie­nie pól for­mu­la­rza i potwierdzenie
  4. jeże­li 
    1. dane są popraw­ne – SYSTEM potwier­dza przy­ję­cie danych
    2. dane są nie­po­praw­ne – SYSTEM pre­zen­tu­je for­mu­larz Dane użyt­kow­ni­ka i wyświe­tla komu­ni­kat (lub idź do punkt 2.) 
  5. (koniec)

(cza­sa­mi doda­ję pseu­do krok pro­ce­du­ry koniec aby czy­tel­nik miał pew­ność, że to ukoń­czo­na praca).

Po stro­nie (w puli) Organizacji zaini­cjo­wa­ne żąda­nie reje­stra­cji spo­wo­du­je obsłu­gę pierw­sze­go dia­lo­gu z Klientem, tu ostat­nim kro­kiem pro­ce­du­ry jest wysła­nie moni­tu mailem. Następnie Organizacja cze­ka, jeże­li dosta­nie potwier­dze­nie to akty­wu­je kon­to Klienta, zaś po trzech dniach bez­czyn­no­ści, Dane użyt­kow­ni­ka zosta­ną usu­nię­te, i pro­ces reje­stra­cji zosta­nie uzna­ny za zakoń­czo­ny (tu niepowodzeniem).

Na tym eta­pie prac wie­my co i jak Organizacja robi w przy­pad­ku reje­stra­cji Klienta. Cały ten amba­ras jed­nak do cze­goś słu­ży, słu­ży do udo­stęp­nia­nia Klientowi moż­li­wo­ści skła­da­nia zamó­wień i danych o sta­nie jego roz­ra­chun­ków. W przy­kła­dzie mamy dia­gram przy­pad­ków uży­cia, więc i ja pój­dę tym tro­pem (zakres projektowania).

źr. http://​www​.moder​na​na​lyst​.com/​R​e​s​o​u​r​c​e​s​/​A​r​t​i​c​l​e​s​/​t​a​b​i​d​/​1​1​5​/​I​D​/​3​6​5​8​/​U​s​e​-​c​a​s​e​s​-​o​r​-​b​u​s​i​n​e​s​s​-​p​r​o​c​e​s​s​-​m​a​p​s​-​w​h​a​t​-​t​e​c​h​n​i​q​u​e​-​t​o​-​u​s​e​.​a​spx

Mamy tu czte­ry przy­pad­ki uży­cia. Skąd? O tym dalej. Pisałem już wcze­śniej o trans­for­ma­cji z mode­lu BPMN na model Przypadków uży­cia. Tu poka­że efekt końcowy. 

Dlaczego tak?

Przede wszyst­kim logo­wa­nie (wbrew wie­lu przy­kła­dom w sie­ci) nie jest przy­pad­kiem uży­cia, czy­li nie jest usłu­gą apli­ka­cji, jest cechą śro­do­wi­ska, jed­nym z wie­lu spo­so­bów auto­ry­zo­wa­nia użyt­kow­ni­ka do pra­cy (inne to LDAP, Activedirectory, odcisk pal­ca, itp., jest to meto­da reali­za­cji wyma­ga­nia poza­funk­cjo­nal­ne­go o nie­do­pusz­cza­niu do korzy­sta­nia z usług apli­ka­cji nie­au­to­ry­zo­wa­nych osób). Nie jest dobrym pomy­słem uzna­wa­nie takich czyn­no­ści jako usług apli­ka­cji (kto kupi coś co słu­ży wyłącz­nie do logo­wa­ni się?) 

Mamy tu przy­pa­dek uży­cia Zarządzanie kon­tem. Jest to usłu­ga pole­ga­ją­ca na two­rze­niu, aktu­ali­za­cji, pod­glą­dzie lub usu­nię­ciu danych użyt­kow­ni­ka (stan­dar­do­wo ozna­cza sie takie usłu­gi CRUD, ang. Create, Retrieve, Update, Delete, są to reje­stry pozba­wio­ne dzie­dzi­no­wej logi­ki biz­ne­so­wej, kon­tro­lu­je­my wyłącz­nie popraw­ność samych pól). Korzysta z niej Klient, pierw­sze uży­cie (kon­tekst Create) to nic inne­go jak reje­stra­cja w sys­te­mie, każ­de kolej­ne uży­cie to będzie kolej­na aktu­ali­za­cja danych (kon­tekst Update) lub osta­tecz­nie pole­ce­nie ich usu­nię­cia (kon­tekst Delete).

Scenariusz reje­stra­cji, opi­sa­ny wcze­śniej, wyglą­dał by tak:

To tu są poka­za­ne (udo­ku­men­to­wa­ne) kolej­ne kro­ki reali­zo­wa­ne przez pro­jek­to­wa­ny System. W tym przy­pad­ku cały pro­ces samo­ob­słu­gi Klienta (zarzą­dza­nie dany­mi o sobie) został zauto­ma­ty­zo­wa­ny (czy­li nie robią tego już pra­cow­ni­cy Organizacji a apli­ka­cja). W efek­cie model pro­ce­su biz­ne­so­we­go przy­bie­rze osta­tecz­ny kształt to-be”:

Jedynie Klient uży­wa apli­ka­cji, to kto jest wła­ści­cie­lem opro­gra­mo­wa­nia nie ma żad­ne­go zna­cze­nia i nie mode­lu­je­my tego. Wskazane na wcze­śniej­szym dia­gra­mie regu­ły biz­ne­so­we (np. ocze­ki­wa­nie na powie­dze­nie reje­stra­cji wyga­sa po trzech dniach) moż­na zebrać w posta­ci zesta­wie­nia i dołą­czyć do doku­men­ta­cji przy­pad­ków uży­cia, albo po pro­stu prze­ka­zać deve­lo­pe­ro­wi całą doku­men­ta­cję (oso­bi­ście powie­lam zesta­wie­nia reguł biz­ne­so­wych przy przy­pad­kach uży­cia, co pole­cam, zaś nad­mia­ro­wa doku­men­ta­cja jest łatwiej­sza w uży­ciu dla developera).

Autor cyto­wa­ne­go arty­ku­łu umie­ścił w nim tak­że taki diagram:

źr. http://​www​.moder​na​na​lyst​.com/​R​e​s​o​u​r​c​e​s​/​A​r​t​i​c​l​e​s​/​t​a​b​i​d​/​1​1​5​/​I​D​/​3​6​5​8​/​U​s​e​-​c​a​s​e​s​-​o​r​-​b​u​s​i​n​e​s​s​-​p​r​o​c​e​s​s​-​m​a​p​s​-​w​h​a​t​-​t​e​c​h​n​i​q​u​e​-​t​o​-​u​s​e​.​a​spx

Mogę to teraz sko­men­to­wać tak:

  1. jest to jakieś nie­for­mal­ne zesta­wie­nie funk­cjo­nal­no­ści”
  2. funk­cjo­nal­no­ści ozna­czo­ne 1, 2 oraz 3 to nic inne­go jak uży­cie, w róż­nym kon­tek­ście, przy­pad­ku uży­cia (CRUD) Zarządzanie kon­tem

Nie mode­lo­wa­łem już pro­ce­su skła­da­nia zamó­wie­nia (mam nadzie­ję że nie trze­ba :)). Kalendarz to pew­na for­ma zobra­zo­wa­nia ter­mi­nów (np. zamó­wień, jeże­li było takie wyma­ga­nie), być może na stro­nie panel Klienta” (robo­ta dla UX desi­gne­ra). Monitowanie (6. Notification) to nic inne­go jak kolej­ne poza­funk­cjo­nal­ne wyma­ga­nie (moni­to­wa­nie o czymś jako takie to nie jest przy­pa­dek uży­cia), reali­zo­wa­ne w spo­sób udo­ku­men­to­wa­ny na dia­gra­mie sekwen­cji (sce­na­riusz reali­za­cji przy­pad­ku uży­cia). Diagram sekwen­cji jak wyżej, po drob­nych korek­tach, będzie paso­wał do każ­dej ope­ra­cji z dany­mi Klienta, tak­że do aktyw­no­ści Zapoznanie się z tre­ścią danych w toku potwier­dza­nia reje­stra­cji (tu kon­tekst pro­ste­go potwier­dze­nia ope­ra­cji Retrive).

Przedstawiłem wer­sję, któ­ra nie wyma­ga uży­wa­nia żad­nych nie­for­mal­nych dia­gra­mów (UML i BPMN w zupeł­no­ści wystar­czą). Wersję, któ­ra jest zgod­na z MDA, więc wpi­su­je się dobrze w pro­ces ana­li­zy biz­ne­so­wej (model CIM), oddzie­lo­nej od pro­jek­to­wa­nia (model PIM) i imple­men­ta­cji (model PSM, tu pomi­nię­ty i real­nie rzad­ko wyko­ny­wa­ny u deve­lo­pe­ra). Wersję, któ­ra w 100% pozwa­la na śla­do­wa­nie wyma­gań. To co opi­sa­łem jest tak­że zgod­ne z zale­ce­nia­mi BABoK, two­rze­nia jako wyma­ga­nia mode­li bia­łej skrzyn­ki” czy­li pro­jek­tu roz­wią­za­nia (pro­duk­tu).

Jak widać, moż­li­we jest, że jeden przy­pa­dek przy­pa­dek uży­cia (doty­czy to szcze­gól­nie tych ozna­cza­nych CRUD) jako usłu­ga apli­ka­cji, będzie wyko­rzy­sty­wa­ny w wie­lu kon­tek­stach (podob­nie jak mło­tek i jego usłu­ga uderz w to”, może być uży­ty zarów­no do wbi­ja­nia gwoź­dzia jak i do wybi­ja­nia szyby). 

Chciałem tak­że kolej­ny raz poka­zać, że zamiast doku­men­to­wa­nia wyma­gań meto­dą mon­stru­al­nych opi­sów pro­zą i zesta­wień w tabe­lach, z któ­ry­mi to opi­sa­mi auto­rzy mają nie raz ogrom­ne pro­ble­my z utrzy­ma­niem ich kom­plet­no­ści, spój­no­ści i nie­sprzecz­no­ści zaś deve­lo­pe­rzy ogrom­ne pro­ble­my z inter­pre­ta­cją, war­to wyma­ga­nia prze­ka­zy­wać w posta­ci spój­ne­go i prze­te­sto­wa­ne­go i logicz­ne­go pro­jek­tu. Warto tak­że zadbać by sche­ma­ty blo­ko­we (mode­le) były two­rzo­ne zgod­ne z okre­ślo­ny­mi zasa­da­mi (nota­cje, dobre prak­ty­ki) bez cze­go będą trud­ne w jed­no­znacz­nej interpretacji. 

Moi zda­niem podej­ście MDA zapre­zen­to­wa­ne powy­żej jest znacz­nie sku­tecz­niej­sze i daje lep­sze zro­zu­mie­nie, niż wer­sja poka­za­na przez auto­ra arty­ku­łu Use cases or busi­ness pro­cess maps, what tech­ni­que to use?, ale oce­nę pozo­sta­wiam czy­tel­ni­kom (zachę­cam do zada­wa­nia pytań i dyskusji).

Co z tytu­ło­wym pyta­niem: Przypadki uży­cia czy model pro­ce­su, cze­go używać? 

Używać obu dia­gra­mów zgod­nie z ich przeznaczeniem…

computer model real world

Czynniki sukcesu w projektach programistycznych

Listopadowy numer Software Develper Journal zawie­ra bar­dzo cie­ka­wy arty­kuł: Czynniki suk­ce­su w pro­jek­tach pro­gra­mi­stycz­nych.

Wnioski z ankiet:

Wymagania i ich odpo­wied­nie prze­twa­rza­nie to klu­czo­we zagad­nie­nie w pro­jek­tach. Popełniane w tym obsza­rze błę­dy to głów­ne źró­dło pro­ble­mów w pro­jek­tach. Dlaczego tak się dzie­je? Oto głów­ne przy­czy­ny wska­za­ne przez oso­by badane:
  1. nie­zna­jo­mość metod i tech­nik zbie­ra­nia wymagań;
  2. trud­no dotrzeć do informacji;
  3. oso­by dostar­cza­ją­ce wyma­ga­nia są rzad­ko dostępne;
  4. nie­pre­cy­zyj­ne wymagania.

Wydają się oczy­wi­ste, a że z fak­ta­mi nie dys­ku­tu­je­my uzna­je­my je.

Ad.1. To chy­ba powszech­na bolącz­ka wie­lu dostaw­ców IT. Najczęściej obser­wu­ję meto­dę pole­ga­ją­ca na zbie­ra­niu wyma­gań” meto­dą pyta­nia cze­go Pan/Pani ocze­ku­je od sys­te­mu” i ta for­ma jest gwoź­dziem do trum­ny pro­jek­tu. Dlaczego? Odpowiedź zawar­ta jest w pozo­sta­łych trzech pun­kach: wywia­dy cier­pią bo trud­no dotrzeć do danych i ich posia­da­czy a ci ostat­ni naj­czę­ściej poda­ją wyma­ga­nia z gło­wy” co daje w efek­cie ład­nie sfor­ma­to­wa­ny ale nie­pre­cy­zyj­ny opis.

Pojawia się pró­ba dia­gno­zy. Pełna tak zwa­na śla­do­wal­ność wyma­gań (nazwa­na tu hiper­tra­ce­bi­li­ty) jest podob­no kosz­tow­na i trud­na do utrzy­ma­nia. Zaraz potem: nie­dba­łość w defi­nio­wa­niu wyma­gań – no to w koń­cu dokład­nie czy nie? Kolej na ana­li­ty­ków: zrzu­ca­nie odpo­wie­dzial­no­ści ? ana­li­ty­cy two­rzą doku­ment wyma­gań i wypy­cha­ją go do pro­gra­mi­stów. Oczywiście jest to pro­blem, co z tym? Analityk powi­nien pono­sić odpo­wie­dzial­ność za swój pro­dukt do koń­ca pro­jek­tu. Założenie, że moż­na stwo­rzyć skoń­czo­ny doku­ment wyma­gań. Otóż moż­na ale o tym za chwi­lę. Poza waż­ny­mi ele­men­ta­mi zarzą­dza­nia takim pro­jek­tem, w tym zarzą­dza­niem zespo­łem auto­rzy wska­za­li jed­ną z głów­nych moim zda­niem przy­czyn: brak doku­men­tu HLD (pro­jek­tu wysokopoziomego).

Otóż nie da się czymś tak zło­żo­nym jak opro­gra­mo­wa­nie (zakła­dam, że to nie try­wial­ny sys­tem), zarzą­dzać na pozio­mie deta­licz­nych szcze­gó­łów. Jedynym spo­so­bem jest uprasz­cza­nie i pra­ca z abs­trak­cja­mi. Czym są owe abs­trak­cje? Modele! Już w 1984 roku zauwa­żo­no, że:

I just read an idea by [[Stephen Hawking]] and [[Leonard Mlodinow]], cal­led [[Model-Dependent Realism]][2]: ?the idea that a phy­si­cal the­ory or world pic­tu­re is a model (gene­ral­ly of a mathe­ma­ti­cal natu­re) and a set of rules that con­nect the ele­ments of the model to obse­rva­tions.? (za Model-Dependent Realism: Is This the Worldview of Software Engineering? ? THINK IN MODELS).

I nie cho­dzi tu o to, że inży­nie­ria opro­gra­mo­wa­nia, to jakiś zło­żo­ny model mate­ma­tycz­ny. Chodzi w ogó­le o posłu­gi­wa­nie się mode­la­mi – abs­trak­cja­mi – na każ­dym eta­pie pro­jek­tu. To jedy­ny spo­sób by ogar­nąć pro­jekt” w cało­ści. Tak samo jak nie da się myśleć o samo­cho­dzie w kon­tek­ście tysię­cy jego pod­ze­spo­łów, tak nie da się tak myśleć o czym­kol­wiek podob­nie złożonym.

ad.2. Docieranie do infor­ma­cji para­dok­sal­nie nie jest trud­ne, jest ich po pro­tu mało w fir­mach. Bardzo czę­sto postę­po­wa­nie poszcze­gól­nych wyko­naw­ców jest efek­tem ich doświad­cze­nia, kom­pe­ten­cji oraz przy­zna­nych upraw­nień. Problemem, a może raczej wyzwa­niem jest zapi­sa­nie czę­ści tych reguł”.

ad.3. To dla mnie kurio­zal­ny powód. Jest raczej dowo­dem sła­bo­ści kie­row­ni­ka pro­jek­tu (bo nie analityka).

ad.4. Zacytuje dla przy­po­mnie­nia: nie­pre­cy­zyj­ne wyma­ga­nia”. Od tego jest ana­li­ty­ka by były pre­cy­zyj­ne. Problem ten poja­wia się czę­sto w sytu­acji gdy owym ana­li­ty­kiem” jest dostaw­ca opro­gra­mo­wa­nia, któ­ry cze­ka na wyma­ga­nia” mimo, że zawarł w ofer­cie i umo­wie pozy­cję ana­li­za wymagań”.