Structured System Analysis

tools & tech­ni­qu­es by Chris Gane and Trish Sarson

Dzisiaj nie­co arche­olo­gii. Właśnie upo­lo­wa­łem książ­kę jak poni­żej :

Jednym z powo­dów był nie­daw­ny arty­kuł (Diagram Przepływu Danych…) na temat dia­gra­mów DFD i zobra­zo­wa­niu klu­czo­wych funk­cjo­nal­no­ści sys­te­mów. Książka napi­sa­na w 1977 roku, ja mam wyda­nie z 1989-go (!). 

Nie raz tu pisa­łem, że w bran­ży IT jest źle, nadal: The Standish Group report 83.9% of IT pro­jects par­tial­ly or com­ple­te­ly fail” (83%9 pro­jek­tów IT to poraż­ki). Ale cie­kaw­sze jest to, że tak jest od począt­ku tej bran­ży do dzi­siaj! Te sta­ty­sty­ki rok do roku są nie­mal­że iden­tycz­ne od dekad.

W ramach chwi­li luzu pomy­śla­łem, że kil­ka rze­czy z tek książ­ki tu przytoczę.

Pierwszy roz­dział zaty­tu­ło­wa­ny jest Potrzeba lep­szych narzę­dzi. Zawiera mię­dzy inny­mi Podrozdział Co poszło źle w ana­li­zie? I czy­ta­my np. że pro­jek­tu koń­czą sie czę­sto stwier­dze­niem: Zbudowaliśmy dosko­na­ły tech­nicz­nie sys­tem, ale nie tego chcie­li użyt­kow­ni­cy”. Znamy to wszy­scy, nie? ;). Albo: [zwy­kli] ludzie nie wie­dzą zbyt wie­le na temat elek­tro­nicz­ne­go prze­twa­rza­nia danych, dla­te­go są podat­ni na pro­pa­gan­dę, któ­ra obie­cu­je wie­le. To tez zna­my, nie? Analitycy zbyt szyb­ko rzu­ca­ją się na szcze­gó­ły (!). Dokumentacja wyma­gań jest prze­ła­do­wa­na szcze­gó­ła­mi tech­nicz­ny­mi (!). Jeżeli doku­men­ta­cja zawie­ra tyko to co zro­zu­mia­łe dla użyt­kow­ni­ka, sta­no­wi mało przy­dat­ne narzę­dzie dla pro­gra­mi­stów (!). Co jest pro­ble­mem? Brak mode­li i nad­miar natu­ral­ne­go języ­ka w specyfikacjach. 

Co pro­po­nu­ją auto­rzy? Proponują mode­le w posta­ci dia­gra­mów prze­pły­wu danych rozu­mia­ne jako prze­pły­wy logicz­ne, biz­ne­so­we. Proponują budo­wa­nie słow­ni­ków (nazwy doku­men­tów, ich atry­bu­tów, war­to­ści atry­bu­tów). Co cie­ka­we, książ­ka powsta­wa­ła gdy model rela­cyj­ny nie był w powszech­nym uży­ciu, poja­wia­ją się raczej poję­cia dane o książ­ce, dane o zamó­wie­niu”. Mowa jest o doku­men­tach i pli­kach w hie­rar­chii: plik -> wiersz -> pole -> pod­rzęd­ne pole (sys­te­my hie­rar­chicz­ne orga­ni­za­cji danych i język taki jak np. COBOL lub PL/I). Dane te mia­ły struk­tu­ry bar­dzo bli­skie dzi­siej­szym pli­kom XML. 

Logika biz­ne­so­wa? Albo pro­ste związ­ki mię­dzy pola­mi (takie jak więk­szy, mniej­szy, rów­ny), drze­wa decy­zyj­ne albo.… Tablice Decyzyjne ;), któ­re nie raz tu opi­sy­wa­łem, one prze­ży­wa­ją dzi­siaj rene­sans. Co cie­ka­we nie był żad­nych suge­stii do usu­wa­nia redun­dan­cji gdyż doku­men­ty (for­mu­la­rze) mia­ły swo­je indy­wi­du­al­ne cykle życia, i prze­pływ danych był rozu­mia­ny jako prze­pływ tych wypeł­nio­nych for­mu­la­rzy. Podział dużych sys­te­mów na pod­sys­te­my (modu­ły) był kon­se­kwen­cją dzie­dzi­ny (patrz boun­ded con­text).

Czy widzi­cie podo­bień­stwo do dzi­siej­szych wzor­ców pro­jek­to­wych? Mikroserwisy, nie­re­la­cyj­ne sys­te­my zarzą­dza­nia dany­mi, brak mono­li­tycz­nych roz­wią­zań, inte­gra­cja danych poprzez ich wymia­ną a nie współ­dzie­le­nie. Czy to cofa­nie się? Nie, to spraw­dzo­ne wzor­ce, współ­dzie­le­nie danych i usu­wa­nie redun­dan­cji, nie spraw­dza się… Systemy zno­wu są zorien­to­wa­ne na doku­men­ty biz­ne­so­we. A rela­cyj­ne sys­te­my danych? Są i pozo­sta­ną raczej tam, gdzie się spraw­dza­ją dosko­na­le: hur­tow­nie danych, big data, itp. 

Dawne doku­men­ty i modu­ły to dzi­siaj obiek­ty trans­fe­ru­ją­ce dane DTO, kom­po­nen­ty, mikro­ser­wi­sy, sys­te­my rozproszone. 

Tyle histo­rii na dzi­siaj. 🙂 Czy to jakaś for­ma nawo­ły­wa­nia do powro­tu do metod struk­tu­ral­nych? Nie. Ale dzi­siaj mamy meto­dy zorien­to­wa­ne na kom­po­nen­ty, na doku­men­ty, na logi­kę prze­twa­rza­nia nie będą­ca czę­ścią danych/dokumentów. Czy fak­tu­ra zawie­ra jakie­kol­wiek infor­ma­cje o tym jak powsta­ła? Nie! Czy Treść umo­wy zawie­ra infor­ma­cje o tym ile trwa­ły nego­cja­cje i skąd sie wzię­ły takie a nie inne ceny? Nie! Logika biz­ne­so­wa nie jest czę­ścią danych tak jak wzór na upust nie czę­ścią faktury. 

Mamy ogrom­ny postęp w tech­no­lo­gii i cały czas ten sam biznes. 

Źródła

Gane, C., & Sarson, T. (1977). Structured sys­tems ana­ly­sis: tools & tech­ni­qu­es (1st ed). Improved System Technologies.

Jarosław Żeliński

Jarosław Żeliński: autor, badacz i praktyk analizy systemowej organizacji: Od roku 1991 roku, nieprzerwanie, realizuje projekty z zakresu analiz i projektowania systemów, dla urzędów, firm i organizacji. Od 1998 roku prowadzi samodzielne studia i prace badawcze z obszaru analizy systemowej i modelowania (modele jako przedmiot badań: ORCID). Od 2005 roku, jako nieetatowy wykładowca akademicki, prowadzi wykłady i laboratoria (ontologie i modelowanie systemów informacyjnych, aktualnie w Wyższej Szkole Informatyki Stosowanej i Zarządzania pod auspicjami Polskiej Akademii Nauk w Warszawie.) Oświadczenia: moje badania i publikacje nie mają finansowania z zewnątrz, jako ich autor deklaruję brak konfliktu interesów. Prawa autorskie: Zgodnie z art. 25 ust. 1 pkt. 1) lit. b) ustawy o prawie autorskim i prawach pokrewnych zastrzegam, że dalsze rozpowszechnianie artykułów publikowanych w niniejszym serwisie jest zabronione bez indywidualnej zgody autora (patrz Polityki Strony).

Dodaj komentarz

Witryna wykorzystuje Akismet, aby ograniczyć spam. Dowiedz się więcej jak przetwarzane są dane komentarzy.