Analiza Biznesowa i Opis Techniczny Oprogramowania

Adresatem tego wpi­su są oso­by roz­wa­ża­ją­ce zamó­wie­nie u mnie Analizy Biznesowej i Opisu Technicznego Oprogramowania oraz dostaw­cy opro­gra­mo­wa­nia, gdyż Opis Techniczny Oprogramowania to pro­jekt archi­tek­tu­ry i logi­ki, pre­fe­ro­wa­na prze­ze mnie for­ma doku­men­to­wa­nia wyma­gań na oprogramowanie. 

Jeżeli jesteś zain­te­re­so­wa­ny otrzy­my­wa­niem takich zapy­tań zapo­znaj się z poniż­szym opi­sem. Jeżeli jesteś zain­te­re­so­wa­ny zale­ce­niem mi wyko­na­nia takiej doku­men­ta­cji wyślij Zapytanie.

Struktura i treść moich opracowań

Tekst ten zawie­ra krót­ki opis pra­cy ze mną oraz opis i przy­kła­dy moich pro­duk­tów. Więcej na temat same­go pro­ce­su powsta­wa­nia tych pro­duk­tów w: Analiza Potrzeb i Opracowanie Wymagań na Oprogramowanie, wię­cej o sto­so­wa­nych meto­dach i stan­dar­dach: Metoda ana­li­zy i pro­jek­to­wa­nia sys­te­mów biz­ne­so­wych. Słownik sto­so­wa­nych metod i narzę­dzi jest dostęp­ny na stro­nie: Słownik meto­dycz­ny.

Model biznesowy

Jest to część opi­su­ją­ca mecha­ni­zmy rzą­dzą­ce pra­cą ana­li­zo­wa­nej i opi­sa­nej orga­ni­za­cji. Celem tej czę­ści Analizy Biznesowej jest zro­zu­mie­nie tego jak okre­ślo­na orga­ni­za­cja dzia­ła i współ­dzia­ła z oto­cze­niem i prze­ka­za­nie tej wie­dzy dostaw­cy roz­wią­za­nia, w celu lep­sze­go zro­zu­mie­nia przez nie­go śro­do­wi­ska w jakim roz­wią­za­nie będzie wdra­ża­ne. Model biz­ne­so­wy zawie­ra sche­ma­ty blo­ko­we wyko­na­ne z uży­ciem nota­cji BMM (Business Model Motivation) , BPMN (Procesy biz­ne­so­we), UML (struk­tu­ry danych doku­men­tów biz­ne­so­wych) oraz SBVR (słow­nik pojęć i regu­ły biz­ne­so­we).

Projekt logiki aplikacji czyli wymagania

Wymagania na opro­gra­mo­wa­nie są spe­cy­fi­ko­wa­ne jako pro­jekt logi­ki sys­te­mu (MDE). Z zasa­dy ope­ru­ję przy­pad­ka­mi uży­cia, ich sce­na­riu­sza­mi i mode­lem dzie­dzi­ny budo­wa­nym jako archi­tek­tu­ry sepa­ro­wa­nych od sie­bie usług apli­ka­cyj­nych (imple­men­to­wa­ne czę­sto jako mikro­ser­wi­sy). Struktury infor­ma­cji są spe­cy­fi­ko­wa­ne jako doku­men­ty (XML lub ana­lo­gicz­ne), co opi­sa­łem w tek­ście Projekt apli­ka­cji…. Ogólnie moje pro­jek­ty są opar­te na wzor­cach pro­jek­to­wych, szcze­gól­nie są to DDD, micro ser­wi­sy i doku­men­to­we struk­tu­ry danych. Architektura HLD z regu­ły opar­ta jest na poniż­szym schemacie:

Więcej na stro­nie: Wzorce pro­jek­to­we w ana­li­zie i pro­jek­to­wa­niu mode­lu dzie­dzi­ny sys­te­mu.

Dlaczego moje projekty są zorientowane na dokumenty

Pojęcie zbiór danych” więk­szo­ści nadal koja­rzy się z rela­cyj­nym mode­lem danych i języ­kiem SQL. Jednak my jako ludzie gro­ma­dzi­my infor­ma­cje w posta­ci redun­dant­nych doku­men­tów, ich struk­tu­ry odpo­wia­da­ją naszym potrze­bom i czy­nią doku­men­ty nie­za­leż­ny­mi od sie­bie. Dokument to tak­że przede wszyst­kim kon­tekst dla danych na nim zgro­ma­dzo­nych. Dlatego tak zwa­ne Systemy Biznesowe to sys­te­my for­mu­la­rzo­we: z zasa­dy ope­ru­ją na doku­men­tach, ich inte­gra­cja – wewnątrz orga­ni­za­cji jak i mię­dzy orga­ni­za­cja­mi – to wymia­na nazwa­nych zesta­wów danych: doku­men­tów .

Relacyjny model danych jest nie­ela­stycz­ny. Cechuje się pre­cy­zyj­nie zde­fi­nio­wa­ną struk­tu­rą danych, któ­ra jed­nak bar­dzo ją ogra­ni­cza. Musimy zde­fi­nio­wać sta­łą struk­tu­rę jak kolum­ny i wier­sze tabel oraz okre­ślić ich rela­cje, co jest póź­niej trud­ne do zmia­ny. Ponadto, jeśli dzie­dzi­na poję­cio­wa jest głę­bo­ko zagnież­dżo­na, uży­cie mode­lu rela­cyj­ne­go dla niej będzie wyma­ga­ło wie­lu tabel i złą­czeń. Relacyjne bazy danych mają sła­bą ska­lo­wal­ność pozio­mą. Mogą być ska­lo­wa­ne w pio­nie poprzez doda­nie więk­szej ilo­ści zaso­bów, takich jak pro­ce­sor i pamięć RAM. Ale nie mogą być ska­lo­wa­ne pozio­mo, tzn. łączyć wie­lu maszyn i two­rzyć kla­strów. Wynika to z wyma­gań doty­czą­cych spój­no­ści. Baza danych zorien­to­wa­na na doku­men­ty roz­wią­zu­je nie­któ­re z tych pro­ble­mów, z któ­ry­mi bory­ka się baza danych w mode­lu relacyjnym.

Główną wadą rela­cyj­ne­go mode­lu danych w sys­te­mach biz­ne­so­wych jest zapi­sy­wa­nie danych w posta­ci współ­dzie­lo­nych znor­ma­li­zo­wa­nych struk­tur poję­cio­wych, pozba­wio­nych redun­dan­cji, co powo­du­je, że dane są pozba­wio­ne kon­tek­stu , a w kon­se­kwen­cji model ten nie spraw­dza się w sys­te­mach zarzą­dza­ją­cych doku­men­ta­mi. Dokumenty biz­ne­so­we (dowo­dy księ­go­we ale tak­że umo­wy, ofer­ty i wie­le innych) to zło­żo­ne agre­ga­ty danych więc zapy­ta­nia SQL do ich zapi­su i odczy­tu to bar­dzo zło­żo­ne struk­tu­ry kodu, powo­du­ją­ce, że bazy takie szyb­ko sta­ją się nie­wy­daj­ne (zaso­by takie jak pro­ce­sor i RAM są ogra­ni­czo­ne a ska­lo­wa­nie pozio­mie tu jest nie­moż­li­we). Dodatkowo doku­ment, w sen­sie fizycz­nym nie może być gene­ro­wa­ną dyna­micz­nie struk­tu­rą (zapy­ta­nia SQL do bazy rela­cyj­nej), bo jest wte­dy tyl­ko wir­tu­al­nym chwi­lo­wym bytem, nie sta­no­wi tak­że doku­men­tu w sen­sie praw­nym (Kodeks Cywilny), nie da się też zarzą­dzać jego cyklem życia. 

Dlatego od dwóch dekad doku­men­ty w sys­te­mach infor­ma­tycz­nych są coraz czę­ściej wyra­ża­ne jako struk­tu­ry XML/XSD/DTD i prze­cho­wy­wa­ne w takiej posta­ci , czę­sto uzu­peł­nia­ne wer­sją do czy­ta­nia i dru­ku” w for­ma­cie pdf (real­nie są to czę­sto pli­ki pdf zawie­ra­ją­ce treść XML). 

Dane gru­po­wa­ne w doku­men­ty i prze­twa­rza­ne jako całe struk­tu­ry infor­ma­cyj­ne, a nie jako poje­dyn­cze pola danych, są coraz czę­ściej sto­so­wa­ną meto­dą budo­wa­nia archi­tek­tu­ry opro­gra­mo­wa­nia. Podejście takie daje znacz­nie więk­szą swo­bo­dę pro­jek­to­wa­nia, zaś pli­ki XML jako doku­men­ty, moż­na prze­twa­rzać i prze­sy­łać mię­dzy apli­ka­cja­mi ze znacz­nie więk­szą swo­bo­dą .

Operacje na zło­żo­nych danych (struk­tu­ral­ne doku­men­ty) z uży­ciem języ­ka SQL są nawet o kil­ka rzę­dów wol­niej­sze niż ana­lo­gicz­ne ope­ra­cje w bazach NoSQL. Dlatego bazy danych, sto­su­ją­ce inny niż rela­cyj­ny model danych, są coraz popu­lar­niej­sze jako repozytoria:

W moich pro­jek­tach dane są mode­lo­wa­ne jako hie­rar­chicz­ne agre­ga­ty (np. struk­tu­ry doku­men­tów XML). Każdy doku­ment ma okre­ślo­ną struk­tu­rę oraz zde­fi­nio­wa­ne regu­ły okre­śla­ją­ce jego popraw­ność (słow­nik i regu­ły biz­ne­so­we , . Struktura ta może być przej­rzy­ście wyra­żo­na w posta­ci dia­gra­mu UML .

Mechanizm utrwa­la­nia stan­dar­do­wo mode­lu­ję z uży­ciem wzor­ca repo­zy­to­rium. Obiekt «enti­ty» odpo­wie­dzial­ny jest za prze­cho­wa­nie doku­men­tu (patrz wzo­rzec «enve­lo­pe» ): ma atry­but tek­sto­wy prze­cho­wu­ją­cy całą struk­tu­rę XML (doku­ment to zawar­tość jed­ne­go atry­bu­tu), atry­but iden­ty­fi­ka­to­ra, oraz dodat­ko­we atry­bu­ty zawie­ra­ją­ce klu­czo­we meta­da­ne do reali­zo­wa­nia logi­ki biz­ne­so­wej oraz ope­ra­cje CRUD dla tego doku­men­tu .

Logika dzie­dzi­no­wa (tak­że wali­da­cja doku­men­tów) może być wspól­na dla wie­lu doku­men­tów w okre­ślo­nym dzie­dzi­no­wym kon­tek­ście .

Jednym z klu­czo­wych powo­dów powszech­ne­go sto­so­wa­nia XML jest tak­że stan­da­ry­za­cja doku­men­tów, głów­nie finan­so­wych i urzę­do­wych w ramach Unii Europejskiej oraz stan­da­ry­za­cja, tak­że w Unii, metod zarzą­dza­nia nimi (archi­wa) .

Z racji tego, że poję­cie doku­men­tu ma tak­że cha­rak­ter praw­ny, wyda­je się oczy­wi­stym, że zacho­wa­nie inte­ro­pe­ra­cyj­no­ści wyma­ga takiej stan­da­ry­za­cji. Jest to – stan­da­ry­za­cja – pro­ces postę­pu­ją­cy w ramach Unii Europejskiej i wewnątrz państw wspól­no­ty, dla­te­go z zasa­dy w moich pro­jek­tach wyma­ga­niem jest sto­so­wa­nie XML jako meto­dy zapi­su infor­ma­cji. To czy fizycz­nie będzie to motor bazy NoSQL czy pła­skie tabli­ce SQL nie ma więk­sze­go zna­cze­nia, bo istot­ny jest tu nie­re­la­cyj­ny model danych. 

Komunikacja w projekcie

Co do zasa­dy pra­cu­ję zdal­nie i pre­fe­ru­ję pisem­ną for­mę wymia­ny tre­ści i mate­ria­łów. Spotkania np. na Skype, są jak naj­bar­dziej pro­wa­dzo­ne, jed­nak ich celem są bie­żą­ce usta­le­nia, pla­no­wa­nie, pre­zen­ta­cje pro­to­ty­pów, itp. a nie np. warsz­ta­ty i zbie­ra­nie wyma­gań”. Pisemna for­ma prze­ka­zy­wa­nia wszel­kich mate­ria­łów zabez­pie­cza inte­res wszyst­kich trzech stron pro­jek­tów (spon­sor, pro­jek­tant, wyko­naw­ca). Więcej na stro­nie Komunikacja w pro­jek­cie, opis narzę­dzia jakie sto­su­ję w komu­ni­ka­cji na stro­nie: Visual Paradigm Postmania (bio­rą­cy udział w komu­ni­ka­cji spon­sor i deve­lo­per nie muszą nicze­go insta­lo­wać, ani kupo­wać jakich­kol­wiek licencji).

Przykłady specyfikacji wymagań

Prezentowanie przy­kła­do­wych spe­cy­fi­ka­cji jest moż­li­we wyłącz­nie wte­dy, gdy nie są one obję­te tajem­ni­cą przed­się­bior­stwa, mogę poka­zać wyłącz­nie opu­bli­ko­wa­ne wcze­śniej doku­men­ty w prze­tar­gach publicz­nych lub opi­sy demo”. Poniżej wybra­ne opra­co­wa­nia wyko­na­ne dla admi­ni­stra­cji publicz­nej jako Opis Przedmiotu Zamówienia i wybra­ne wer­sje demo. 

Poniższe opra­co­wa­nia do doku­men­ta­cja dedy­ko­wa­nych sys­te­mów, jed­nak nie każ­dy sys­tem musi być dedykowany. 

Projekty dla admi­ni­stra­cji były reali­zo­wa­ne z moim wspar­ciem (nad­zór autor­ski), zosta­ły wyko­na­ne w ter­mi­nie i w budże­cie, zama­wia­ją­cy dostał autor­skie pra­wa mająt­ko­we do pro­jek­tu, apli­ka­cje te nadal są w uży­ciu i są roz­wi­ja­ne przez ich właścicieli. 

Większość pro­jek­tów nasta­wio­na jest na zakup i wdro­że­nie opro­gra­mo­wa­nia goto­we­go, dla­te­go przy­go­to­wa­nie np. do wdro­że­nia sys­te­mu ERP to zawsze Analiza Biznesowa oraz archi­tek­tu­ra wyso­kie­go pozio­mu” (HLD) inte­gra­cji sys­te­mu. Jedynie tam, gdzie wyma­ga­ne są dedy­ko­wa­ne funk­cjo­nal­no­ści two­rzo­na jest archi­tek­tu­ra LLD (ww. spe­cy­fi­ka­cja techniczna). 

Przykład pro­ce­su pro­wa­dze­nia ana­li­zy i wyko­na­nia opi­su doku­men­ta­cji, wraz z fil­mem jak powsta­wał, znaj­dziesz na stronie: 

(arty­kuł: https://​it​-con​sul​ting​.pl/​2​0​2​0​/​1​2​/​1​1​/​a​n​a​l​i​z​a​-​b​i​z​n​e​s​o​w​a​-​o​d​-​z​l​e​c​e​n​i​a​-​d​o​-​k​o​m​p​l​e​t​n​e​g​o​-​p​r​o​j​e​k​t​u​-​t​e​c​h​n​i​c​z​n​e​g​o​-​z​-​u​z​y​c​i​e​m​-​n​a​r​z​e​d​z​i​a​-​c​a​se/, wyko­na­ne opra­co­wa­nie).

W razie jakich­kol­wiek pytań lub suge­stii co do tego, cze­go wg. Was deve­lo­pe­rów bra­ku­je w tych przy­kła­dach, pro­szę o kon­takt.

Źródła:

Andrew Davidson, Matthew Fuchs, Mette Hedin, Mudita Jain, Jari Koistinen, Chris Lloyd, Murray Maloney, & Kelly Schwarzhof. (1999, July 30). Schema for Object-Oriented XML. Schema for Object-Oriented XML 2.0. https://​www​.w3​.org/​T​R​/​N​O​T​E​-​S​OX/
Anna Benchy, & Gibin George. (2022). Migration of Relational Database to Document Oriented Database. International Journal of Advanced Research in Science, Communication and Technology, 153 – 157. https://​doi​.org/​1​0​.​4​8​1​7​5​/​I​J​A​R​S​C​T​-​4​923
Bernauer, M., Kappel, G., & Kramler, G. (2003). Representing XML Schema in UML – An UML Profile for XML Schema. 25.
Booch, G., Christerson, M., Fuchs, M., & Koistinen, J. (1999). UML XML Mapping Schema. 8.
Carlson, D. (2001). Modeling XML Applications with UML. Pearson Education, Inc.
Fowler, M. (1997). Analysis pat­terns: reu­sa­ble object models. Addison Wesley.
Gyorödi, C., Gyorödi, R., & Sotoc, R. (2015). A Comparative Study of Relational and Non-Relational Database Models in a Web- Based Application. International Journal of Advanced Computer Science and Applications, 6(11). https://​doi​.org/​1​0​.​1​4​5​6​9​/​I​J​A​C​S​A​.​2​0​1​5​.​0​6​1​111
Martin, R. C. (2018). Czysta archi­tek­tu­ra Struktura i design opro­gra­mo­wa­nia Przewodnik dla pro­fe­sjo­na­li­stów (W. Moch, Trans.). Helion SA.
O’Connor, R. V., Elger, P., & Clarke, P. M. (2017). Continuous softwa­re engineering‑A micro­se­rvi­ces archi­tec­tu­re per­spec­ti­ve. Journal of Software: Evolution and Process, 29(11), e1866. https://​doi​.org/​1​0​.​1​0​0​2​/​s​m​r​.​1​866
Paredaens, J., Bra, P. D., Gyssens, M., & Gucht, D. van. (2012). The Structure of the Relational Database Model. Springer Science & Business Media.
Pugh, K. (2006). Interface-orien­ted design. Pragmatic Bookshelf.
Document Content Description for XML. (1998, July 31). Document Content Description for XML. https://​www​.w3​.org/​T​R​/​N​O​T​E​-​dcd
Williams, S. P., Mosen, J., & Schubert, P. (n.d.). The Structure of Social Documents. 10.

Analitycy pytają…

F.A.Q.

29 Lipca 2018 r. w Sopocie mia­ło miej­sce pierw­sze popo­łu­dnio­we spo­tka­nie Analiza Biznesowa 3 mia­sto” zor­ga­ni­zo­wa­ne wspól­nie z por­ta­lem Analiza​.IT a celem było Stary ana­li­tyk odpo­wia­da na pyta­nia młodych” 🙂

W ramach pod­su­mo­wa­nia spo­tka­nia zebra­li­śmy pyta­nia zdo­by­wa­ją­cych doświad­cze­nie ana­li­ty­ków, wspól­nie uzna­ne za repre­zen­ta­tyw­ne dla całe­go spotkania.

Oto one i moje odpo­wie­dzi. Starałem się nicze­go nie ukry­wać, trak­tuj­cie to jak szcze­re kole­żeń­skie rady, obcią­żo­ne moim 20-let­nim doświad­cze­niem i subiektywizmem.

Znajdziecie tu i trosz­kę inży­nie­rii i tech­no­lo­gii, i trosz­kę filo­zo­fii i trosz­kę ety­ki zawodu…

Zapraszam

Jarek Żeliński

Nowy analityk w korporacji, jak ma się zachować gdy wchodzi w nieuporządkowany projekt i niezbyt uporządkowane, chaotycznie tworzone papiery”?

To chy­ba naj­trud­niej­sze pyta­nie i naj­prost­sza odpo­wiedź: ma być uczci­wy wzglę­dem sie­bie. Jeżeli wszedł w miej­sce poprzed­ni­ka by go po pro­stu zastą­pić (ana­li­tyk przy­jął zło­żo­ną mu ofer­tę pra­cy), to pozo­sta­je mu tego poprzed­ni­ka zastą­pić w sfe­rze tego jak ten pra­co­wał i jakie doku­men­ty two­rzył. Jeżeli ktoś został zatrud­nio­ny bo pra­co­daw­ca uznał, że poprzed­nik robił coś gorzej a nowy pra­cow­nik ma wie­dzę by popra­wić dotych­cza­so­wą jakość pra­cy, i być może wdro­żyć nowe i lep­sze prak­ty­ki, to zna­czy że ma speł­nić tę obietnicę ;).

Tu waż­na uwa­ga: nie da się refor­mo­wać fir­my bez wie­dzy i zgo­dy jej zarzą­du a pro­jek­tu bez wie­dzy i zgo­dy Kierownika Projektu. Można owszem świe­cić przy­kła­dem”, ale nale­ży przy tym pamię­tać, że to nie to samo co robie­nie ina­czej i lepiej niż inni”, bo tak moż­na roz­sa­dzić fir­mę (pro­jekt) od środka.

Tak więc podej­mu­jąc się nowej pra­cy nale­ży przy­jąć na sie­bie wszel­kie wyni­ka­ją­ce z tego obo­wiąz­ki, napra­wia­nie świa­ta nale­ży robić zawsze za wie­dzą i zgo­dą zwierzch­ni­ków :). Jednak pod­sta­wo­wym, moral­nym i etycz­nym zada­niem każ­de­go z nas, jest infor­mo­wa­nie prze­ło­żo­nych o dostrze­żo­nych ryzykach.

Czego i jak się uczyć, żeby zacząć pracować w analizie

Analiza biz­ne­so­wa (ana­li­za sys­te­mo­wa orga­ni­za­cji) i szu­ka­nie roz­wią­zań pro­ble­mów, to pra­ca bar­dzo podob­na do pra­cy nauko­wej. Przyjęcie ana­li­zy sys­te­mo­wej jako fun­da­men­tu metod pra­cy, pozwa­la nie tyl­ko upo­rząd­ko­wać pra­ce ana­li­tycz­ne, ale tak­że upo­rząd­ko­wać cały pro­ces szu­ka­nia roz­wią­za­nia. Każdemu, kto ma ocho­tę się roz­wi­jać, pole­cam osią­gnię­cia myśli­cie­li z obsza­ru filo­zo­fii nauki (patrz arty­kuł Wiedza a nauka i praw­da). […] Tu tak­że inny arty­kuł zaczy­na­ją­cy się od słów:

Analiza sys­te­mo­wa, ogól­na teo­ria sys­te­mów, świat to cha­os czy zło­żo­ność? Biznes i jego oto­cze­nie to zło­żo­ność, któ­ra dla wie­lu jest cha­osem. (Źródło: Wszystkie dro­gi pro­wa­dzą do Rzymu | | Jarosław Żeliński IT-Consulting).

Uogólniając, war­to się oswo­ić z filo­zo­fią ana­li­tycz­ną i logi­ką, bo na niej mię­dzy inny­mi opar­te są fun­da­men­ty nota­cji takich jak UML, BPMN i nie tyl­ko. Warto nauczyć się zapi­sy­wać zdo­by­tą wie­dzę o ana­li­zo­wa­nej orga­ni­za­cji z pomo­cą sche­ma­tów blo­ko­wych i for­mal­nych nota­cji, zgod­nie z maksymą:

jeże­li cze­goś nie potra­fisz popraw­nie nary­so­wać to zna­czy, że jesz­cze tego nie rozumiesz…

Ważna rzecz: gdy tyl­ko to moż­li­we, czy­tać cudze doku­men­ty i ana­li­zo­wać ich wady, w szcze­gól­no­ści wszyst­ko to, co oka­za­ło się nie­ja­sne i nie­jed­no­znacz­ne, to co było przy­czy­ną poraż­ki pro­jek­tu, bo to te wady doku­men­tów, któ­re nale­ży usu­wać w swo­jej wła­snej pracy.

I pod­sta­wa: nie być kon­for­mi­stą (ponad 3/4 pro­jek­tów IT to wto­py a nie suk­ce­sy.… wiec więk­szość nie ma racji). Na tej Stronie (mój blog) znaj­dzie­cie recen­zje wybra­nych ksią­żek, któ­re polecam.

Czy są gotowe zestawy dokumentów, w oparciu o które można napisać specyfikację

Osobiście nie spo­tka­łem takich i nie pole­cam ich szu­ka­nia… Każda ana­li­zo­wa­na fir­ma jest inna, więc każ­da ana­li­za będzie mia­ła inną wyni­ko­wą treść. Można mówić o ramie, czy­li klu­czo­wych eta­pach ana­li­zy i tym samym o klu­czo­wych roz­dzia­łach specyfikacji:

  1. wpro­wa­dze­nie czy­li cel biz­ne­so­wy pod­mio­tu ana­li­zo­wa­ne­go, tak­że to (opis) jak spraw­dzi­my, że fir­ma ten cel (po zakoń­cze­niu pro­jek­tu) zre­ali­zo­wa­ła (tu przy­da­je się nota­cja BMM),
  2. model dzia­ła­nia pod­mio­tu ana­li­zo­wa­ne­go poka­zu­je w jaki spo­sób orga­ni­za­cja dzia­ła, nale­ży przede wszyst­kim zba­dać i poka­zać jak powsta­ją doku­men­ty i ich treść, co powo­du­je (jakie fak­ty), że te doku­men­ty w ogó­le powsta­ją (tu mode­le pro­ce­sów biz­ne­so­wych, sza­blo­ny doku­men­tów, słow­ni­ki i regu­ły biz­ne­so­we, głów­nie nota­cje BPMN, SBVR, tu ewen­tu­al­nie UML jako narzę­dzie doku­men­to­wa­nia aktu­al­ne­go sta­nu IT w organizacji),
  3. pro­jekt roz­wią­za­nia pro­ble­mu, czy­li opis sta­nu doce­lo­we­go: jakie roz­wią­za­nie (zmia­ny orga­ni­za­cyj­ne, nowe sys­te­my IT, inne) nale­ży wdro­żyć by zre­ali­zo­wać cel biz­ne­so­wy; to etap napi­sa­nia wyma­gań na nowe roz­wią­za­nie, jeże­li zapa­da decy­zja że będzie to nowe lub aktu­ali­zo­wa­ne opro­gra­mo­wa­nie, pisze­my wymagania: 
    1. jeże­li ryzy­ko pro­jek­tu jest nie­zbyt duże, opi­sać je tra­dy­cyj­nie czy­li cecha­mi ocze­ki­wa­ny­mi, np. zgod­nie z nor­mą IEEE Std 830‑1998,
    2. jeże­li oka­że się, że opis meto­dą cech zewnętrz­nych jest zbyt ryzy­kow­ny (czy­li w zasa­dzie każ­dy nie­try­wial­ny sys­tem), idzie­my w MDA/MDE (model PIM w UML, INCOSE/SysML) opi­sy­wa­ne na tym blo­gu nie raz bo w tym się specjalizuję.

Dokumentacja w procesach prowadzonych zwinnie – czy jest potrzebna, jak dokładna powinna być, kiedy powinna być tworzona, kiedy się przydaje?

O zwin­no­ści w IT zapi­sa­no tony papieru :).

Każdy kto poszedł do skle­pu i wró­cił z nie­go bez waż­nych spra­wun­ków, wie po co pisze­my listy zaku­pów: nie mamy aż tak dobrej pamię­ci. Generalnie brak doku­men­ta­cji ma takie same skut­ki jak jej nad­miar: bar­dzo szko­dzi w pro­jek­cie i pod­no­si kosz­ty. Dokumentacja to komu­ni­ka­cja mię­dzy uczest­ni­ka­mi pro­jek­tu i same­mu z sobą (prze­czy­taj­cie swo­je doku­men­ty z przed kil­ku mie­się­cy, a nawet tyl­ko z przed tygodni).

Co do zasa­dy, doku­men­to­wać nale­ży wszyst­kie decy­zje, w szcze­gól­no­ści archi­tek­to­nicz­ne. Decyzjami są w szcze­gól­no­ści zatwier­dzo­ne wyma­ga­nia (klient zde­cy­do­wał, że chce TO mieć). Podstawowym celem two­rze­nia doku­men­ta­cji jest potrze­ba wie­dzy o tym CO ZOSTAŁO ZAMÓWIONE oraz CO ZOSTAŁO ZROBIONE i DLACZEGO TAK.

Pod poję­ciem zwin­no­ści rozu­miem takie pro­wa­dze­nie pro­jek­tu i doku­men­ta­cji, by nie powsta­wa­ły tre­ści (doku­men­ty) zbęd­ne, czy­li przede wszyst­kim nie powin­ny powsta­wać opi­sy zawierające:

  1. szyb­ko dez­ak­tu­ali­zu­ją­ce się deta­le, pro­jekt trwa w cza­sie a czas to zmia­na oto­cze­nia ryn­ko­we­go czy­li tak­że wymagań,
  2. zapi­sy tre­ści spo­tkań, zupeł­nie wystar­czy pier­wot­ny doku­ment wyma­gań (patrz wyżej pro­dukt ana­li­zy) i bie­żą­ce aktu­ali­zo­wa­nie go na pod­sta­wie zgło­szo­nych żąda­nych zmian lub pytań o kolej­ne szczegóły.

Tu podam przy­kład: doku­men­ta­cja wyma­gań dla Senatu mia­ła w momen­cie roz­po­czę­cia prac deve­lo­pe­ra (wyma­ga­nia na dzień ogło­sze­nie prze­tar­gu) 35 stron (war­tość ofer­ty na wyko­na­nie tego co w niej opi­sa­no to ok. 250 tys.). Plan komu­ni­ka­cji wyglą­dał tak, że odpo­wie­dzią na każ­de pyta­nie deve­lo­pe­ra była odpo­wiedź (nad­zór autor­ski) w posta­ci zak­tu­ali­zo­wa­nej w odpo­wied­nim miej­scu doku­men­ta­cji z począt­ku pro­jek­tu. Developer musiał z góry dekla­ro­wać wszyst­kie swo­je bie­żą­ce tech­nicz­ne decy­zje (kon­cep­cja wdro­że­nia), któ­re były tak­że nano­szo­ne w doku­men­ta­cji. W efek­cie w dniu zakoń­cze­nia two­rze­nia opro­gra­mo­wa­nia ist­nia­ła kom­plet­na jego doku­men­ta­cja: mia­ła 84 stro­ny. Reszta to deta­le w kodzie i doku­ment Koncepcji Wdrożenia czy­li to co opra­co­wał i wyko­nał deve­lo­per (ja się na to tyl­ko powołuję).

Nie jest też praw­dą, że doku­men­ta­cja jest (linio­wo?) tym więk­sza im więk­sza apli­ka­cja ma powstać. Im więk­sza apli­ka­cja tym dłu­żej w cza­sie trwa jej powsta­wa­nie, dla­te­go im więk­szy pro­jekt tym doku­men­ta­cja jest bar­dziej poli­ty­ką budo­wy sys­te­mu, jego archi­tek­tu­ra i kon­cep­cja, niż deta­licz­nym pro­jek­tem, co oczy­wi­ście wca­le nie zna­czy, że jej powsta­nie nie będzie kosz­tow­niej­sze: do prze­ana­li­zo­wa­nia jest duża orga­ni­za­cja i duży projekt.

Jakość tworzonej dokumentacji (temat omawiamy przy okazji wspomnienia o instrukcji wyłączenia kontroli składni w EA)

O jako­ści doku­men­ta­cji decy­du­je w 100% jej zro­zu­mia­łość (w tym tak­że więc jed­no­znacz­ność), spój­ność i kom­plet­ność (nie mylić z jako­ścią same­go opi­sa­ne­go w niej pro­jek­tu). To zaś ozna­cza, że wszel­kie odstęp­stwa od stan­dar­dów to pogor­sze­nie jako­ści. Ideałem jest taki doku­ment, któ­ry został w cało­ści prze­czy­ta­ny przez jego adre­sa­ta deve­lo­pe­ra (a więc nie­zbyt obszer­ny) i nie wyma­ga kon­tak­tu z jego auto­rem to by zro­zu­mieć jego treść i jed­no­znacz­nie ją zin­ter­pre­to­wać. W prze­tar­gach mier­ni­kiem jako­ści jest np. licz­ba pytań ofe­ren­tów do tre­ści wyma­gań a w każ­dym pro­jek­cie ilość wpro­wa­dza­nych zmian (ale nie roz­sze­rzeń). Tak więc odstęp­stwa od zasad sto­so­wa­nia uży­tych nota­cji, sto­so­wa­nie slan­gu w tre­ści, sto­so­wa­nie nie­stan­dar­do­wych i zamknię­tych licen­cja­mi metod i nota­cji, brak słow­ni­ka pojęć, to wszyst­ko powo­du­je, że doku­men­ta­cja sta­je się sama z sie­bie pro­ble­mem w projekcie.

Jedną z naj­gor­szych rze­czy jest nie­ste­ty łama­nie zasad uży­tej nota­cji, a nie raz po pro­stu nie­umie­jęt­ne (nie­za­mie­rzo­ne) jej sto­so­wa­nie. W jed­nej z ksią­żek na temat uży­cia UML, jej autor słusz­nie zauwa­ża we wstępie:

Wielu auto­rów doku­men­tów pro­jek­to­wych uży­wa UML (BPMN, itp.) nie jak sfor­ma­li­zo­wa­nych sys­te­mów nota­cyj­nych a jak biblio­te­ki sym­bo­li w Power Poincie, jest to tra­ge­dia tych autorów.

(o wali­da­cji w EA nie­daw­no pisa­łem wię­cej)

Narzędzia wspomagające pracę analityka – visual paradigm (VP) a enterprise architect (EA), co lepsze, jak dokonać wyboru

To kla­sycz­ne pyta­nie o narzę­dzia. Pierwsza rzecz: narzę­dzie, któ­re znasz jest zawsze lep­sze od tego, któ­re­go nie znasz. Warto też wie­dzieć, że na ryn­ku pra­cy stan­dar­dem de fac­to jest nadal EA (wystar­czy spoj­rzeć na ogło­sze­nia o pra­cę). Od tego momen­tu będzie subiektywnie ;):

  • EA jest rela­tyw­nie tani, dość powszech­ny, ale też mało ergo­no­micz­ny i bar­dzo pra­co­chłon­ny, nadal domi­nu­je w kor­po­ra­cjach i dużych fir­mach IT bo tu liczy się dostęp­ność kom­pe­ten­cji na ryn­ku pra­cy zaś koszt pro­jek­tów spa­da na dru­gi plan bo klien­ci i tak zapła­cą za men­dej­sy”.
  • VP jest droż­szy od EA, zaczy­na jed­nak domi­no­wać w małych fir­mach o małej rota­cji pra­cow­ni­ków i u fre­elan­ce­rów, bo jest ergo­no­micz­ny, ma bar­dzo dobre wspar­cie dla sfor­ma­li­zo­wa­nych nota­cji a tak­że dla meto­dyk zwin­nych, ma wer­sje pol­ską (w tym pol­ską kon­tro­lę orto­gra­fii), pozwa­la two­rzyć w locie doku­men­ta­cję bez potrze­by korzy­sta­nia z pakie­tów biu­ro­wych i pro­gra­mo­wa­nia SQL; VP daje bar­dzo wyso­kiej jako­ści usłu­gi w chmu­rze jaki­mi są ser­wer wer­sjo­nu­ją­cy pro­jek­ty i narzę­dzia do zdal­nej komu­ni­ka­cji z klien­ta­mi (1 GB na pro­jek­ty w cenie licencji).

Ja uży­wam VP od 2005 r., na warsz­ta­tach zaś nadal regu­lar­nie mie­wam uczest­ni­ków z EA, zawsze mają jakieś z two­rze­niem dia­gra­mów w zgo­dzie z nota­cją i meto­da­mi takim jak śla­do­wa­nie i zawsze two­rze­nie dia­gra­mów trwa dłu­żej niż i mnie z uży­ciem VP.

Od pra­wie 10 lat nie uży­wam pakie­tów biu­ro­wych (edy­to­rów tek­stów i arku­szy kal­ku­la­cyj­nych) do two­rze­nia doku­men­ta­cji (wyżej wska­za­na doku­men­ta­cja dla Senatu powsta­ła w 100% z uży­ciem VP).

Sami więc musi­cie wybrać…

Czy logowanie” jest przypadkiem użycia ( ? )

Logowanie nie jest powo­dem zaku­pu opro­gra­mo­wa­nia, logo­wa­nie to jed­na z moż­li­wych imple­men­ta­cji wyma­ga­nia ?tyl­ko auto­ry­zo­wa­ny użyt­kow­nik może korzy­stać z apli­ka­cji?, co nie prze­szka­dza więk­szo­ści ama­to­rów uży­wa­nia tych dia­gra­mów (w tym auto­rów ksią­żek) potrak­to­wa­nia logo­wa­nia jako przy­pad­ku uży­cia apli­ka­cji. Dobrym testem sen­su umiesz­cza­nia takich rze­czy na dia­gra­mach przy­pad­ków uży­cia jest zada­wa­nie sobie pyta­nia: ?czy kupił byś tę apli­ka­cję tyl­ko dla tego jed­ne­go przy­pad­ku użycia??

Tyle cytat z moje­go arty­ku­łu Ile przy­pad­ków uży­cia? | | Jarosław Żeliński IT-Consulting (pole­cam lek­tu­rę całe­go). Wiele nie­po­ro­zu­mień two­rzy książ­ka Alistaira Cockburn’a Stosowanie przy­pad­ków uży­cia: jego książ­ka nie ma nic wspól­ne­go z UML. Jeżeli powyż­sze jed­nak pyta­nie o przy­pad­ki uży­cia doty­czy dia­gra­mów w UML, to przy­pa­dek uży­cia jest tam defi­nio­wa­ny jako usłu­ga dla akto­ra świad­czo­na przez sys­tem, dla któ­rej to usłu­gi został on kupiony/stworzony”. Mam świa­do­mość ile jest tego rodza­ju przy­kła­dów (logo­wa­nie jako przy­pa­dek uży­cia) w sie­ci, ale war­to tu nie być konformistą…

Przypomnę, że tak­że opcja w menu każ­de­go opro­gra­mo­wa­nia [Exit/Zakończ/Wyloguj] jest kli­ka­na, ma dia­log [czy jesteś pewien TAK/NIE] i mimo to nie jest przy­pad­kiem uży­cia tego oprogramowania.

Jaka jest różnica między analitykiem biznesowym a analitykiem systemowym

Na to pyta­nie nie ma odpo­wie­dzi, bo te poję­cia nie mają ści­słej defi­ni­cji. Zwyczajowo się przyj­mu­je w wie­lu fir­mach podział na:

  • ana­li­tyk biz­ne­so­wy zbie­ra i porząd­ku­je wyma­ga­nia (eli­ci­ta­tion),
  • ana­li­tyk sys­te­mo­wy coś pro­jek­tu­je w UML (sys­tem description).

Patrząc na wcze­śniej­sze moje odpowiedzi:

  • czę­sto ana­li­ty­kiem biz­ne­so­wym nazy­wa się oso­bę two­rzą­cą SRS (System Requirements Specification, spe­cy­fi­ka­cja wyma­gań), naj­czę­ściej zgod­nie z IEEE Std 830‑1998,
  • czę­sto ana­li­ty­kiem sys­te­mo­wych nazy­wa się archi­tek­ta opro­gra­mo­wa­nia (co nie do koń­ca jest zgod­ne z praw­dą i faktami),
  • ale w MDA powsta­ją mode­le: CIM, PIM PSM, ana­li­tyk biz­ne­so­wy (patrz tak­że IIBA) powi­nien być auto­rem mode­li CIM i PIM, deve­lo­per (wyko­naw­ca) wyko­na imple­men­ta­cję i być może wyko­na tak­że model PSM; rola tak zwa­ne­go ana­li­tyk sys­te­mo­we­go zani­ka, nie tyl­ko w lite­ra­tu­rze, jako sztucz­na rola pomię­dzy tymi dwie­ma (ana­li­tyk pro­jek­tant i deve­lo­per czy­li wykonawca).

Cel biznesowy w dokumentacji – co zrobić, gdy: brak jasno sprecyzowanego celu biznesowego; cele biznesowe wykluczają się nawzajem; cele biznesowe wykraczają poza obszar projektu

To będzie krót­ka odpo­wiedź: nie reali­zo­wać takie­go pro­jek­tu. Wiem, że pra­co­daw­cy ana­li­ty­ka może się taka odpo­wiedź nie spodo­bać, ale pod­trzy­mu­ję swo­je zda­nie. Jeżeli nie uda się zama­wia­ją­ce­go namó­wić na usu­nię­cie tej wady pro­jek­tu, uczci­wy ana­li­tyk się wyco­fa… W prze­ciw­nym wypad­ku ktoś w koń­cu powie gło­śno: dosta­li­śmy dokład­nie to co chcie­li­śmy i zupeł­nie nie to cze­go potrzebujemy.

Czy rejestrować funkcjonalności, których realizacja została wykluczona podczas specyfikowania

Najlepszą zna­ną mi meto­dą zarzą­dza­nia wyma­ga­nia­mi jest zarzą­dza­nie ich sta­tu­sa­mi (w tym sta­tus: poza zakre­sem pro­jek­tu), więc nie usu­wa­my ich ze spe­cy­fi­ka­cji. To poma­ga póź­niej przy­po­mnieć innym, że wyma­ga­nie było i dla­cze­go zosta­ło usu­nię­te z zakre­su. Czasem jest ono prze­su­wa­ne do kolej­nej now­szej wer­sji. Dobrą prak­ty­ką jest zapi­sa­nie dla każ­de­go wyma­ga­nia: wła­ści­cie­la czy­li oso­by zgła­sza­ją­ce­go wyma­ga­nie po stro­nie zama­wia­ją­ce­go, sza­co­wa­ne­go kosz­tu imple­men­ta­cji, bie­żą­ce­go statusu.

Czy zawsze warto analizować organizacje i otoczenie biznesowe projektu

Zawsze :). Bez tego nie wie­my nic o sen­se i celu pro­jek­tu 🙂 … Tu uwa­ga: dobry ana­li­tyk to nie najem­nik, któ­ry jak mu zapła­cą zro­bi każ­da głu­po­tę… patrz wyżej pyta­nie o reali­za­cję pro­jek­tu mają­ce­go źle sfor­mu­ło­wa­ne cele.

Jak rejestrować uprawnienia użytkowników – macierz uprawnień?

Obecnie macierz to chy­ba (poza rzad­ki­mi wyjąt­ka­mi) naj­gor­sza meto­da. Zarówno z powo­du zmien­no­ści upraw­nień w trak­cie życia orga­ni­za­cji jak i nie raz ogrom­nych roz­mia­rów takiej macie­rzy. Uprawnienia doku­men­tu­je­my i zarzą­dza­my nimi w apli­ka­cjach z uży­ciem reguł biz­ne­so­wych. To pozwa­la by apli­ka­cja sama dyna­micz­nie tym upraw­nie­nia­mi zarzą­dza­ła, np. pra­wa dostę­pu do tre­ści doku­men­tu ma tyl­ko oso­ba pro­wa­dzą­ca spra­wę zwią­za­ną z tym doku­men­tem oraz jej bez­po­śred­ni prze­ło­żo­ny”. Zmiany kadro­we, prze­ka­za­nie spra­wy innej oso­bie, nie prze­ło­żą się na jaką­kol­wiek pra­co­chłon­ność zwią­za­ną z pra­wa­mi dostę­pu do doku­men­tu, admi­ni­stra­tor sys­te­mu jest wyłą­czo­ny z inge­ro­wa­nia te w pra­wa co dodat­ko­wo pod­no­si bez­pie­czeń­stwo cało­ści systemu.

Jedną, z chy­ba naj­gor­szych, metod doku­men­to­wa­nia upraw­nień jest dia­gram przy­pad­ków uży­cia, któ­ry dzię­ki temu natych­miast sta­je się nie raz mon­stru­al­nie roz­bu­do­wa­ny (czy­li nieczytelny).

I Ty zadaj pytanie…

Zachęcam do zada­wa­nia kolej­nych pytań i dys­ku­sji pod tym arty­ku­łem, szcze­gól­nie tych któ­rzy nie zna­leź­li tu odpo­wie­dzi na nur­tu­ją­ce ich pyta­nia, a chcą poznać moje zda­nie ;), i pamię­taj: zanim zadasz pyta­nie, upew­nij się, że chcesz poznać odpowiedź ;).

Audyt spójności wizji i misji organizacji z jej działaniami

Pod poję­ciem audy­tu orga­ni­za­cji, kry­je się przede wszyst­kim audyt doku­men­ta­cji jaką ona sama o sobie stwo­rzy­ła. Powinna ona być spój­na, kom­plet­na i nie­sprzecz­na”. Druga część, to oce­na zgod­no­ści sta­nu fak­tycz­ne­go z tre­ścią tej doku­men­ta­cji, czy­li spraw­dze­nie czy doku­men­ty mówią praw­dę. Popatrzmy jed­nak na samą doku­men­ta­cję orga­ni­za­cji i jej treść.

Każdy mój pro­jekt zaczy­na się od audy­tu doku­men­ta­cji. Jednak zanim zacznę ana­li­zo­wać doku­men­ty ope­ra­cyj­ne i mode­lo­wać pro­ce­sy biz­ne­so­we, spraw­dzam spój­ność wizji i misji fir­my. Dlaczego? Bo pro­ce­sy te wraz z opi­sem stra­te­gii pozwa­la­ją zwe­ry­fi­ko­wać cel pro­jek­tu, a nie raz w ogó­le go sfor­mu­ło­wać. Najgorszym celem biz­ne­so­wym jaki moż­na sobie wyobra­zić, jest wdro­że­nie cze­go­kol­wiek dla same­go wdro­że­nia. Wdrożenie roz­wią­za­nia z zasa­dy jest środ­kiem do osią­gnię­cia celu orga­ni­za­cji a nie celem samym w sobie (to może być cel kie­row­ni­ka pro­jek­tu odpo­wie­dzial­ne­go za samo wdrożenie).

Misja i wizja są (powin­ny być) z sobą powią­za­ne logicz­nie, sta­no­wią one pod­sta­wę dla usta­le­nia stra­te­gii i tak­ty­ki dzia­ła­nia fir­my. Wyznaczają przy­sło­wio­we świa­teł­ko w tune­lu”. Narzędziem dla ana­li­ty­ka zawsze powi­nien być for­ma­lizm, czy­li moż­li­wość spro­wa­dze­nia pozy­ska­nej wie­dzy do skoń­czo­nej licz­by pojęć i związ­ków mię­dzy nimi. Podobnie jak autor zesta­wów LEGO musi spro­wa­dzić dowol­ny kształt do skoń­czo­nej licz­by i typów kloc­ków. Jak wie­my, dowol­ne urzą­dze­nie skła­da się ze skoń­czo­nej licz­by pod­ze­spo­łów, dobre kon­struk­cje skła­da­ją się z pod­ze­spo­łów stan­da­ry­zo­wa­nych. Jeżeli uda się to ana­li­ty­ko­wi, to wte­dy dopie­ro może on powie­dzieć, że zro­zu­miał mecha­nizm tego co opisał”.

Narzędziem do ana­li­zy obsza­ru opi­su orga­ni­za­cji, jakim jest stra­te­gia i zarzą­dza­nie jej reali­za­cją, jest sys­tem poję­cio­wy (nota­cja) zna­ny jako Model Motywacji Biznesowej (1). Jego szkie­let to pla­no­wa­ny stan doce­lo­wy i środ­ki do jego osią­gnię­cia. Do tego doda­je­my oce­nę aktu­al­nej sytu­acji oraz ziden­ty­fi­ko­wa­ne czyn­ni­ki wpły­wu. Model ten kon­fron­tu­je­my z mode­lem dzia­ła­nia orga­ni­za­cji (pro­ce­sy biz­ne­so­we i to co się z nimi wią­że). Swego cza­su opi­sa­łem to:

Business Motivation Model (źr. wiki)
Business Motivation Model (źr. www​.omg​.org)

Notacja BMM uzu­peł­nia biz­ne­so­wy sys­tem nota­cyj­ny o obszar poję­cio­wy (prze­strzeń poję­cio­wą) mode­li biz­ne­so­wych i biz­ne­spla­nów. Pozwala opi­sać je w spo­sób for­mal­ny. Przestrzeń nazw, pod­sta­wo­we poję­cia opi­sa­ne w BMM: Ends (stan ocze­ki­wa­ny, przy­szły) iden­ty­fi­ku­ją cechy opi­su­ją­ce źró­dła moty­wa­cji (cele) two­rze­nia biz­ne­spla­nu, Means (środ­ki) iden­ty­fi­ku­ją narzę­dzia i środ­ki jakich pla­nu­je­my użyć by osią­gnąć (dopro­wa­dzić do) ocze­ki­wa­ny (pla­no­wa­ny) stan. Assessement (oce­na uwa­run­ko­wań) iden­ty­fi­ku­ją wie­dzę o warun­kach pro­jek­tu (w szcze­gól­no­ści ana­li­za SWOT), Influence (wpływ) iden­ty­fi­ku­ją pozna­ne czyn­ni­ki mogą­ce mieć (mają­ce) wpływ na osią­gnie­cie celu, Organisation (orga­ni­za­cja) iden­ty­fi­ku­je zaso­by i pro­ce­sy zaan­ga­żo­wa­ne w osią­gnię­cie celu. Całość sta­no­wi rodzaj ?listy kon­tro­l­nej? zro­zu­mie­nia posta­wio­ne­go pro­ble­mu, jakim jest pro­jekt biz­ne­so­wy. Pozwala upew­nić się, że zna­my i rozu­mie­my to co ma na nie­go wpływ. (2

Misja i Wizja

Skupmy się na misji i wizji, gdyż te budzą naj­wię­cej dys­ku­sji i nie­po­ro­zu­mień. Najpierw poję­cia i ich defi­ni­cje (słow­nik języ­ka pol­skie­go PWN):

wizja ?czy­jeś wyobra­że­nie jakichś zda­rzeń mają­cych zajść w przy­szło­ści, zwy­kle przed­sta­wia­ne w książ­ce lub w filmie?

misja ?posłan­nic­two, waż­ne odpo­wie­dzial­ne zada­nie do spełnienia?

Literatura przed­mio­tu zawie­ra nie­koń­czą­ce się spo­ry na temat wizji, doty­czą one okre­śle­nia tego o jaką i czy­ją przy­szłość cho­dzi. Idąc tro­pem tych, któ­rzy uwa­ża­ją, że wizja to opis sta­nu orga­ni­za­cji, docho­dzi­my to pew­nej koli­zji (sprzecz­no­ści) z pozo­sta­ły­mi ele­men­ta­mi opi­su orga­ni­za­cji. [aka­pit doda­ny dwa dni po publi­ka­cji] Jest pew­na zgo­da co do tego, że misja opi­su­je dla­cze­go orga­ni­za­cja ist­nie­je i jaki jest cel jej dzia­łań. Jeżeli ofe­ru­je ona coś ryn­ko­wi (klien­tom) to zna­czy, że ist­nie­je dla nich a nie dla sie­bie. Skoro zaś orga­ni­za­cja ist­nie­je dla klien­tów zna­czy, że jako orga­ni­za­cja ma jakieś wyobra­że­nie o tych klien­tach i o tym czym oni są, w kon­se­kwen­cji to wyobra­że­nie: wizja, to opis tego kim mogli by być klien­ci w przy­szło­ści dzię­ki tej orga­ni­za­cji. To daje spój­ność misji i wizji. Czym więc jest wizja fir­my mówią­ca będzie­my lide­rem na gieł­dzie”? Jest oświad­cze­niem prze­ciw­nym, jest for­mą ego­izmu: wyda­je­cie u nas pie­nią­dze i My, a nie Wy, mamy z tego korzyść. Skąd się bio­rą w pro­spek­tach emi­syj­nych wizje mówią­ce My.… będzie­my…”? Prospekty emi­syj­ne, ich treść, są adre­so­wa­ne do akcjo­na­riu­szy a nie do klien­tów tych firm. Jednak popraw­na misja i wizja fir­my to meto­da budo­wa­nia wize­run­ku na ryn­ku, więc adre­sa­tem misji i wizji nie są (nie powin­ni być) wła­ści­cie­le organizacji…

Na bazie mode­lu poję­cio­we­go nota­cji BMM (poję­cia i ich zna­cze­nia) moż­na stwo­rzyć taki oto, pod­sta­wo­wy model opi­su orga­ni­za­cji, zacho­wu­ją­cy spój­ność, kom­plet­no­ści i niesprzeczność:


Kluczowe ele­men­ty opi­su sta­nu przy­szłe­go” (doce­lo­we­go) to: wizja, zada­nia i rezul­ta­ty. Jeżeli więc zada­niem było­by zdo­by­cie pozy­cji lide­ra na ryn­ku a mier­ni­kiem reali­za­cji tego zada­nia była co naj­mniej trze­cia pozy­cja w ran­kin­gu, to zna­czy że wizja nie może być ani zada­niem ani tym bar­dziej rezul­ta­tem (logi­ka mode­li poję­cio­wych, w tym słow­ni­ków pojęć, wyma­ga by defi­ni­cje pojęć w tej samej dzie­dzi­nie wza­jem­nie się wykluczały).

Ważne! Oprogramowanie (sys­tem IT jako całość) to zasób i tyl­ko zasób. Warto pamię­tać, że z zaso­bów korzy­sta­ją ludzie w ramach reali­zo­wa­nych czyn­no­ści (pro­ce­sów biz­ne­so­wych). Bez peł­ne­go zro­zu­mie­nia co i po co robią ludzie oce­na sys­te­mu IT czy też spe­cy­fi­ko­wa­nie wyma­gań wobec nie­go są prak­tycz­nie pozba­wio­ne sensu.

Czym więc jest wizja firmy?

W arse­na­le ana­li­ty­ka, wśród narzę­dzi” dia­gno­zu­ją­cych i opi­su­ją­cych orga­ni­za­cję, jest bar­dzo popu­lar­na i łatwa w uży­ciu ana­li­za SWOT” z ang. Silne i Słabe stro­ny, Okazje i Zagrożenia (Strengths, Weaknesses, Opportunities, Threats). Silne i sła­be stro­ny to cechy orga­ni­za­cji a oka­zje i zagro­że­nia to cechy jej oto­cze­nia. Stan doce­lo­wy jest sta­nem ocze­ki­wa­nym, obser­wo­wal­nym z zewnątrz, ryn­ku oraz orga­ni­za­cji, któ­rą opi­su­ją jej zada­nia i ich mier­ni­ki. Jakimi środ­ka­mi orga­ni­za­cja osią­ga cele? Są to stra­te­gia i tak­ty­ki, któ­re razem reali­zu­ją Misję fir­my. Siłą spraw­czą są tu ludzie, Ci zaś reali­zu­ją swo­je zada­nia w ramach reali­zo­wa­nych procesów.

Powyższy dia­gram poka­zu­je dwa istot­ne obsza­ry opi­su orga­ni­za­cji: pra­wy to to, do cze­go ona dąży i jaki­mi środ­ka­mi. Lewa stro­na to oce­na sytu­acji. Gdybyśmy więc opi­sy­wa­li hipo­tecz­ną pie­kar­nię osie­dlo­wą, moż­li­wa była­by sytu­acja, w której:

  • Wizją pie­kar­ni było­by to, że ich osie­dle sku­pia wyłącz­nie miesz­kań­ców odży­wia­ją­cych się zdrowo, 
    • celem było by bycie pie­kar­nią pierw­sze­go wybo­ru dla wszyst­kich mie­szań­ców osiedla,
    • mier­ni­kiem była by ankie­ta, któ­ra potwier­dzi, że każ­dy bada­ny miesz­ka­niec osie­dla doko­nu­je zaku­pu pie­czy­wa w innej pie­kar­ni dopie­ro, gdy nie ma moż­li­wo­ści zaku­pu w pie­kar­ni badanej,
  • Misją pie­kar­ni było by krze­wie­nie zdro­we­go odży­wia­nia się poprzez ofe­ro­wa­nie wyłącz­nie zdro­wych i eko­lo­gicz­nych gatun­ków pie­czy­wa w akcep­to­wa­nych dla więk­szo­ści miesz­kań­ców cenach, 
    • stra­te­gią było by otwar­cie skle­pu na każ­dy tysiąc mieszkańców
    • tak­ty­ka na pierw­szy rok, były by pro­mo­cje doda­wa­nia zdro­wych bułek (po jed­nej) do każ­de­go zaku­pio­ne­go kilo­gra­ma chleba.

Analizy SWOT w deta­lach nie będę tu opi­sy­wał, jest to dość pro­ste i zro­zu­mia­łe narzę­dzie, o któ­rym napi­sa­no wie­le. Warto tu jedy­nie pod­kre­ślić i przy­po­mnieć, że zawie­ra ona oce­nę oto­cze­nia orga­ni­za­cji i jej samej.

Podsumowanie

Powyższy dia­gram poka­zu­je opi­sa­ne poję­cia oraz, co tu najważ­niej­sze, ich wza­jem­ne związ­ki. Całość dla zacho­wa­nia spój­no­ści, kom­plet­no­ści i nie­sprzecz­no­ści powin­na pozwa­lać na takie zobra­zo­wa­nie, a 3związ­ki mię­dzy tymi poję­cia­mi (typy tych związ­ków) nie mogą pro­wa­dzić do jakich­kol­wiek sprzecz­no­ści czy bra­ku logi­ki w toku ich czy­ta­nia (zgod­nie z kie­run­kiem i opi­sem strzałek).

W toku ana­li­zy sys­te­mo­wej orga­ni­za­cji zbie­ra­ne są więc infor­ma­cje i podej­mo­wa­na jest pró­ba odtwo­rze­nia (zbu­do­wa­nia) na ich pod­sta­wie ana­lo­gicz­ne­go jak powy­żej mode­lu. Wszelkie wykry­te luki i nie­spój­no­ści są natych­miast sygna­łem do tego by je wyja­śnić i – jeże­li taki jest cel ana­li­zy – uzu­peł­nić. Zapisy, jako­by wizją fir­my było np. osią­gnię­cie okre­ślo­ne­go puła­pu obro­tów, nie da się obro­nić na grun­cie logiki…

__________________
1.
BMM. OMG​.org. http://​www​.omg​.org/​s​p​e​c​/​B​MM/. Accessed October 6, 2017.
2.
Zelinski J. BMM | Jarosław Żeliński IT-Consulting. Jarosław Żeliński IT-Consulting. https://it-consulting.pl//?s=BMM. Accessed October 6, 2017.
3.
Kim jeste­śmy? Jaka jest nasza toż­sa­mość? Pytania, na któ­re zawsze war­to znać odpo­wiedź cz.II. PROMUJ NGO! . Accessed October 6, 2017.

Architektura kodu aplikacji jako pierwszy etap tworzenia oprogramowania

Tym razem trosz­kę cięż­szy kali­ber, czy­li dywa­ga­cje o tym co powszech­nie jest okre­śla­ne jako meto­dy obiek­to­we i o tym skąd kon­flik­ty i nie­po­ro­zu­mie­nia” mię­dzy pro­gra­mi­sta­mi i ana­li­ty­ka­mi pro­jek­tan­ta­mi.?*?

Wprowadzenie

Literatura przed­mio­tu zawie­ra wie­le róż­nych spo­so­bów gru­po­wa­nia metod pro­gra­mo­wa­nia w ?para­dyg­ma­ty?. Autorzy z regu­ły sku­pia­ją się na tym, czym są pro­gra­my rozu­mia­ne jako zor­ga­ni­zo­wa­na lista pole­ceń dla maszy­ny. Mogą to być sekwen­cje pro­stych pole­ceń, mogą to być wyko­ny­wa­ne wg. okre­ślo­ne­go sce­na­riu­sza funk­cje. Typowym przy­kła­dem takie­go gru­po­wa­nia jest np. wykład (tu jego spis tre­ści) dostęp­ny w sie­ci Internet:

Wstęp
1.1 Przykład pierw­szy: pro­gra­mo­wa­nie impe­ra­tyw­ne
1.2 Przykład dru­gi: pro­gra­mo­wa­nie obiek­to­we
1.3 Przykład trze­ci: pro­gra­mo­wa­nie funk­cyj­ne
1.4 Przykład czwar­ty: pro­gra­mo­wa­nie w logi­ce (pro­gra­mo­wa­nie logicz­ne) ?1?

Wykład ten, z uwa­gi na to, że pocho­dzi ze stron mimów.edu .pl (Uniwersytet Warszawski, Wydział Informatyki) w moich oczach, po lek­tu­rze kil­ku­na­stu podob­nych, jest repre­zen­ta­tyw­nym dla wie­lu śro­do­wisk aka­de­mic­kich podejściem.

Programowanie strukturalne

Jest to para­dyg­mat pro­gra­mo­wa­nia opie­ra­ją­cy się na podzia­le kodu źró­dło­we­go pro­gra­mu na pro­ce­du­ry i hie­rar­chicz­nie uło­żo­ne blo­ki z wyko­rzy­sta­niem struk­tur kon­tro­l­nych w posta­ci instruk­cji wybo­ru i pętli. Rozwijał się w opo­zy­cji do pro­gra­mo­wa­nia wyko­rzy­stu­ją­ce­go pro­ste instruk­cje warun­ko­we i sko­ki. Programowanie struk­tu­ral­ne zwięk­sza czy­tel­ność kodu i uła­twia ana­li­zę pro­gra­mów, co sta­no­wi zna­czą­cą popra­wę w sto­sun­ku do trud­ne­go w utrzy­ma­niu ?spa­ghet­ti code? czę­sto wyni­ka­ją­ce­go z uży­cia instruk­cji go to”. Nadal jest to jed­nak dłu­ga lista sil­nie powią­za­nych procedur.

Metody struk­tu­ral­ne ana­li­zy i pro­jek­to­wa­nia bazu­ją na uzna­niu, że opro­gra­mo­wa­nie to stos funk­cji ope­ru­ją­cych na bazach (skła­dach) danych. Innymi sło­wy pod­sta­wo­we zało­że­nie to ist­nie­nie odręb­nych bytów jaki­mi są baza danych oraz funk­cje, któ­re na tych danych wyko­nu­ją ope­ra­cje. W meto­dach struk­tu­ral­nych two­rzy dwa się rodza­je mode­li: model pro­ce­su prze­twa­rza­nia i model struk­tu­ry danych. Pierwszy wyko­rzy­stu­je nota­cję DFD (Data Flow Diagram, np. nota­cja Gane?a- Sarsona) a dru­gi nota­cja ERD (Entity Relationship Diagram, np. nota­cja Martina) do mode­lo­wa­nia struk­tur rela­cyj­nych baz danych.

Rysunek 1 Diagram DFD w nota­cji Gene’a – Sarsona

Struktura apli­ka­cji w posta­ci tak zwa­nej ?czar­nej skrzyn­ki? zosta­ła poka­za­na na Rysunku 1. W meto­dach struk­tu­ral­nych, na pozio­mie opi­su archi­tek­tu­ry, apli­ka­cja ?dzie­lo­na jest? na pod­funk­cje (patrz Rysunek 2.).

Rysunek 2 Dekompozycja funkcji

Starsze pod­ręcz­ni­ki infor­ma­ty­ki i pro­gra­mo­wa­nia powo­łu­ją się na ?zasa­dę?: algo­ryt­my + struk­tu­ry danych = opro­gra­mo­wa­nie (apli­ka­cje). Kod zawie­ra­ją­cy funk­cje jest z regu­ły dzie­lo­ny jest na czę­ści zwa­ne ?pod­pro­gram?, jed­nak nie­za­leż­nie od tego jak jest zor­ga­ni­zo­wa­ny, jest to zwar­ty i nie­po­dziel­ny sys­tem funk­cji i algo­ryt­mów, któ­ry zapi­su­je i odczy­tu­je dane ze współ­dzie­lo­ne­go ?maga­zy­nu danych?. Najczęściej tym maga­zy­nem jest rela­cyj­nie zor­ga­ni­zo­wa­na baza danych?2?, czy­li sys­tem powią­za­nych tablic, w któ­rym usu­wa się redun­dan­cje i two­rzy trwa­łe związ­ki logicz­ne mię­dzy tak zor­ga­ni­zo­wa­ny­mi danymi.

Modelowania struk­tur rela­cyj­nych baz danych (nota­cja ERD, Entity Relationship Diagram, tu nota­cja Martina)

Architektura taka nie spra­wia więk­szych pro­ble­mów do momen­tu gdy apli­ka­cja nie zaczy­na się roz­ra­stać i nie poja­wia się potrze­ba wpro­wa­dza­nia kolej­nych nowych lub zmie­nio­nych ele­men­tów mecha­ni­zmu jej dzia­ła­nia. Wtedy każ­da inge­ren­cja w tak zor­ga­ni­zo­wa­ną archi­tek­tu­rę doty­czy pra­wie zawsze całej apli­ka­cji. Stabilne kie­dyś oto­cze­nie (śro­do­wi­sko użyt­ko­wa­nia tych apli­ka­cji) pozwa­la­ło na pro­jek­to­wa­nie opro­gra­mo­wa­nia, od któ­re­go nikt nie ocze­ki­wał, że pozwo­li na łatwe i szyb­kie wpro­wa­dza­nie zmian. Po dru­gie, two­rze­niem opro­gra­mo­wa­nia zaj­mo­wa­ły się małe zespo­ły pro­gra­mi­stów, zaś logi­ka prze­twa­rza­nia pole­ga­ła raczej na reali­zo­wa­niu małej licz­by typów ope­ra­cji na wiel­kich ilo­ściach danych, to były głow­nie pro­jek­ty inży­nier­skie a nie badaw­cze. Zamawiający (tak zwa­ny dzi­siaj ?biz­nes?) musiał jedy­nie spi­sać dane i ope­ra­cje oraz wzo­ry (for­mu­ły) z jakich uży­ciem były one przeliczane.

Zmiana paradygmatu

Rosnąca zło­żo­ność opro­gra­mo­wa­nia wymu­si­ła szu­ka­nie nowych roz­wią­zań. Początkowo dzie­lo­no kod apli­ka­cji na sepa­ro­wa­ne czę­ści – modu­ły, jed­nak nadal sta­no­wi­ły one jed­ną całość z powo­du pra­cy z dany­mi w posta­ci jed­nej zwar­tej struk­tu­ry, jaką jest współ­dzie­lo­na rela­cyj­na baza danych. Fakt ten czę­sto jest postrze­ga­ny jako zale­ta: wska­zu­je się na brak redun­dan­cji, łatwy spo­sób uzy­ska­nia spój­no­ści danych, współ­dzie­le­nie jako łatwą inte­gra­cję. Problem w tym, że duże apli­ka­cje ope­ru­ją w wie­lu kon­tek­stach, co powo­du­je, że współ­dzie­lo­na baza danych o usta­lo­nej struk­tu­rze, musi sta­no­wić kom­pro­mis. Np. dane sta­no­wią­ce zapis kolej­nych zaku­pów amor­ty­zo­wa­nych środ­ków trwa­łych mają inną struk­tu­rę i logi­kę wza­jem­nych powią­zań, niż te same dane w kon­tek­ście zło­żo­nych kon­struk­cji mecha­nicz­nych jaki­mi są te środ­ki trwa­łe. Innym przy­kła­dem obra­zu­ją­cym kwe­stie kon­tek­sto­wo­ści jest przy­kład na blo­gu Martina Fowlera.?3?

Rysunek 3 Granice kon­tek­stu i zmia­na per­spek­ty­wy pojęć ?3?.

Jak widać na Rysunku 3., mamy tu dwa kon­tek­sty i redun­dan­cje (poję­cia Customer i Produkt powie­lo­ne po obu stro­nach: w obu dzie­dzi­nach). Powyższe powin­no być pod­sta­wą do podzia­łu pro­jek­tu na dwa odręb­ne kom­po­nen­ty z wła­sny­mi (nie współ­dzie­lo­ny­mi) dany­mi. Jak widać każ­dy kom­po­nent ope­ru­je poję­cia­mi Customer i Produkt, jed­nak inny jest ich kon­tekst. Inne cechy dzie­dzi­no­we tych pojęć nie są (nie powin­ny być) współ­dzie­lo­ną infor­ma­cją w jed­nej bazie danych, oba kom­po­nen­ty będą mia­ły swo­je odręb­ne mode­le danych, zapew­ne o róż­nią­cej struk­tu­rze. Powód pierw­szy to inne związ­ki poję­cio­we i być może nawet inne defi­ni­cje pojęć. Produkt w kon­tek­ście sprze­da­ży ma nazwę, cenę, dostęp­ność itp. Produkt w kon­tek­ście uszko­dzeń ma numer seryj­ny, wer­sję, użyt­kow­ni­ka itp. Inne będą regu­ły biz­ne­so­we w każ­dym kom­po­nen­cie. Drugi powód to łatwa dostęp­ność na ryn­ku spe­cja­li­zo­wa­nych pro­duk­tów typu CRM i TicketXXX, szu­ka­nie (two­rze­nie) jed­ne­go ?pakie­tu zin­te­gro­wa­ne­go? będzie bar­dzo trud­ne, bo kon­tek­stów sprze­da­ży a potem obsłu­gi uszko­dzeń czy rekla­ma­cji, jako pary, będą tysią­ce warian­tów. Wytworzenie (zakup) osob­no, i inte­gra­cja dwóch odpo­wied­nio dobra­nych kom­po­nen­tów (apli­ka­cji), będą znacz­nie łatwiejsze.

Powoli zaczę­ły swe­go cza­su powsta­wać apli­ka­cje dzie­dzi­no­we, jed­nak nadal wewnętrz­nie mia­ły one opi­sa­ne wyżej wady współ­dzie­le­nia danych w jed­nej bazie. Do tego ich inte­gra­cja pole­ga­ła na wza­jem­nym się­ga­niu do danych co sta­no­wi­ło bar­dzo duży pro­blem z powo­du róż­nych struk­tur tych danych, zaś wymia­na jed­nej z nich na inną wyma­ga­ła opra­co­wa­nia od nowa całej kon­cep­cji inte­gra­cji współ­dzie­lo­nych danych co poka­za­no na Rysunku 4.

Rysunek 4 Integracja apli­ka­cji strukturalnych

Obiektowy paradygmat

Co cie­ka­we powsta­nie metod obiek­to­wych nie było szu­ka­niem spo­so­bu usu­nię­cia wad sys­te­mów struk­tu­ral­nych. Pierwsze obiek­to­we narzę­dzia powsta­ły już w latach sześć­dzie­sią­tych XX w. narzę­dzia i pro­gra­my struk­tu­ral­ne tak­że powsta­ją do tej pory.

Do obec­nej popu­lar­no­ści metod obiek­to­wych dopro­wa­dzi­ły dwie ścież­ki: pro­blem rosną­cej zło­żo­no­ści kodu apli­ka­cji oraz potrze­ba utrzy­ma­nia zro­zu­mie­niu ?tego czym jest ta apli­ka­cja? po stro­nie zamawiającego.

Proces, powszech­nie zwa­ny ?zbie­ra­niem wyma­gań?, sta­je się coraz bar­dziej skom­pli­ko­wa­ny i ryzy­kow­ny, w mia­rę jak rośnie zło­żo­ność tych systemów.

Wymagania na opro­gra­mo­wa­nie nali­cza­ją­ce wyna­gro­dze­nia tysiąc­om pra­cow­ni­ków to ?jeden wzór? na nali­cze­nie wyna­gro­dze­nia oraz pew­na licz­ba cech jako­ścio­wych takich jak wydaj­ność czy dostęp­ność. Jednak opi­sa­nie tą meto­dą jed­nej” apli­ka­cji, ope­ru­ją­cej dzie­siąt­ka­mi doku­men­tów o róż­nych struk­tu­rach i ogrom­nej ilo­ści zależ­no­ści mię­dzy nimi, z pomo­cą ?listy cech? zaczy­na przy­bie­rać postać setek, a nie raz tysię­cy, linii i danych w tabe­lach. Przy takiej ilo­ści wyma­gań” prak­tycz­nie żaden spo­sób ich orga­ni­za­cji nie wpro­wa­dza war­to­ści doda­nej, zaś ich licz­ba prak­tycz­nie nie pozwa­la na kon­tro­lę kom­plet­no­ści i niesprzeczności.

Popatrzmy na komen­tarz auto­ra wykła­du?1? do obiek­to­we­go programowania:

W pro­gra­mo­wa­niu obiek­to­wym pro­gram to zbiór poro­zu­mie­wa­ją­cych się ze sobą obiek­tów, czy­li jed­no­stek zawie­ra­ją­cych pew­ne dane i umie­ją­cych wyko­ny­wać na nich pew­ne ope­ra­cje
- Ważną cechą jest tu powią­za­nie danych (czy­li sta­nu) z ope­ra­cja­mi na nich (czy­li pole­ce­nia­mi) w całość, sta­no­wią­cą odręb­ną jed­nost­kę ? obiekt.
- Cechą nie mniej waż­ną jest mecha­nizm dzie­dzi­cze­nia, czy­li moż­li­wość defi­nio­wa­nia nowych, bar­dziej zło­żo­nych obiek­tów, na bazie obiek­tów już ist­nie­ją­cych.
Zwolennicy pro­gra­mo­wa­nia obiek­to­we­go uwa­ża­ją, że ten para­dyg­mat dobrze odzwier­cie­dla spo­sób, w jaki ludzie myślą o świe­cie
- Nawet jeśli pogląd ten uzna­my za prze­jaw pew­nej egzal­ta­cji, to nie­wąt­pli­wie pro­gra­mo­wa­nie obiek­to­we zdo­by­ło ogrom­ną popu­lar­ność i wypa­da je uznać za para­dyg­mat obec­nie dominujący.

W cyto­wa­nym tek­ście widać ste­reo­ty­po­we podej­ście autora:

meto­dy obiek­to­we two­rze­nia opro­gra­mo­wa­nia, opie­ra­ją się na wyróż­nia­niu w two­rzo­nym opro­gra­mo­wa­niu dwóch rodza­jów skła­do­wych: pasyw­nych odzwier­cie­dla­ją­cych fakt prze­cho­wy­wa­nia w sys­te­mie pew­nych danych oraz skła­do­wych aktyw­nych odzwier­cie­dla­ją­cych fakt wyko­ny­wa­nia w sys­te­mie pew­nych ope­ra­cji. Metody obiek­to­we wyróż­nia­ją w sys­te­mie skła­do­we, któ­re łączą w sobie moż­li­wość prze­cho­wy­wa­nia danych oraz wyko­ny­wa­nia ope­ra­cji? (źr. wikipedia).

Schematycznie moż­na to przed­sta­wić tak:

Podejście, któ­re nazwę pro­gra­mi­stycz­nym, to uzna­nie, że trze­ba podzie­lić dużą apli­ka­cję na mniej­sze odręb­ne kom­po­nen­ty, z któ­rych każ­dy ma ?swo­je funk­cje i dane?. Tu tak­że pod­kre­śla­na jest kwe­stia re-uży­cia kodu w posta­ci tak zwa­ne­go dzie­dzi­cze­nia jako ?mecha­ni­zmu defi­nio­wa­nia nowych, bar­dziej zło­żo­nych obiek­tów, na bazie obiek­tów już ist­nie­ją­cych? .

Zupełnie inną dro­gą jest podej­ście opar­te na uzna­niu, że świat rze­czy­wi­sty to okre­ślo­ny mecha­nizm, któ­ry da się odwzo­ro­wać jako pew­na abs­trak­cja za pomo­cą kodu (jego struk­tu­ry). Tu struk­tu­ra kodu jest kon­se­kwen­cją struk­tu­ry tego obsza­ru świa­ta rze­czy­wi­ste­go?, któ­re­go doty­czy two­rzo­ne opro­gra­mo­wa­nie (o czym już na swo­im blo­gu nie raz pisałem).

Skutek jest ?taki sam?: pro­gram stwo­rzo­ny zgod­nie z obiek­to­wym para­dyg­ma­tem będzie się owszem skła­dał z klas obiek­tów, któ­re komu­ni­ku­ją się wza­jem­nie. Jednak podej­ście zorien­to­wa­ne na dzie­le­nie dużej apli­ka­cji na pod­pro­gra­my trak­tu­je obiek­ty jako ?jakieś? kom­po­nen­ty zawie­ra­ją­ce w sobie kod funk­cji i dane na jakich one ope­ru­ją. Podejście zorien­to­wa­ne na mode­lo­wa­nie ?świa­ta rze­czy­wi­ste­go? zaowo­cu­je obiek­ta­mi sta­no­wią­cy­mi abs­trak­cje (mode­le) ele­men­tów świa­ta rze­czy­wi­ste­go. Struktura takie­go kodu w obu przy­pad­kach będzie obiek­to­wa” ale jej sens nie raz jest skraj­nie inny np. obiekt fak­tu­ra będzie zawie­rał dane o sprze­da­ży ale nie będzie miał ope­ra­cji ?nowa fak­tu­ra?, bo fak­tu­ry nie two­rzą nowych fak­tur? (ani nie nio­są infor­ma­cji o tym jak powsta­wa­ły). Faktury będą two­rzo­ne przez inny obiekt np. Twórca fak­tur (albo jak w nie­któ­rych wzor­cach: fabry­ka fak­tur).?4?

Od lat sześć­dzie­sią­tych pro­wa­dzo­ne są pra­ce nad meto­da­mi obiek­to­wy­mi w inży­nie­rii opro­gra­mo­wa­nia, powsta­je języ­ka SIMULA w 1967 roku. W 1968 roku opu­bli­ko­wa­no pierw­sze ofi­cjal­ne wyda­nie Ogólnej Teorii Systemów Ludwiga von Bertalanffy’ego (publi­ka­cje na jej temat poja­wia­ły się od już 1964 roku). Teoria sys­te­mów mówi, że ?sys­tem to współ­pra­cu­ją­ce obiek­ty?, język SIMULA powstał do two­rze­nia (pro­gra­mów) symu­la­cji obiek­tów świa­ta rzeczywistego.

Oba wska­za­ne podej­ścia są zna­ne od lat, jed­nak podej­ście ?inży­nier­skie? (dzie­le­nie duże­go kodu na małe kawał­ki) domi­nu­je, nie tyl­ko jak widać w sys­te­mie kształcenia.

Ogólna teo­ria sys­te­mów trak­tu­je wszyst­ko jak ?sys­tem? (współ­pra­cu­ją­ce obiek­ty). Z zewnątrz sys­tem to obiekt reagu­ją­cy na bodź­ce. Reakcja ta może być opi­sa­na mecha­ni­zmem jej powsta­wa­nia, to wewnętrz­na struk­tu­ra sys­te­mu. Jeżeli uznać, że opro­gra­mo­wa­nie (i kom­pu­ter) zastę­pu­je okre­ślo­ną rze­czy­wi­stość (np. mecha­nicz­ny zegar zastą­pio­ny pro­gra­mem wyko­ny­wa­nym w kom­pu­te­rze) to moż­na przy­jąć, że kom­pu­ter to maszy­na abs­trak­cyj­na, jej imple­men­ta­cja reali­zu­je kon­kret­ne sys­te­my i (lub) ich kom­po­nen­ty?5?.

Nie cho­dzi więc o to by podzie­lić opro­gra­mo­wa­nie na ?skła­do­we, któ­re łączą w sobie moż­li­wość prze­cho­wy­wa­nia danych oraz wyko­ny­wa­nia ope­ra­cji?. Chodzi o to by mecha­nizm, o dowie­dzio­nej popraw­no­ści, zaim­ple­men­to­wać w okre­ślo­nej wybra­nej technologii. 

Chodzi też o to by nie uda­wać, że pro­gra­mo­wa­nie jako ?podzie­lo­ne na obiek­ty? par­tie kodu, nadal korzy­sta­ją­ce z jed­nej wspól­nej bazy danych, róż­ni się czym­kol­wiek od ?struk­tu­ral­ne­go kodu?. Chodzi o to by kod pro­gra­mu fak­tycz­nie imple­men­to­wał okre­ślo­ny (zba­da­ny i opi­sa­ny) mechanizm.

Tak więc ?obiek­to­wy para­dyg­mat? to nie ?nowe pro­gra­mo­wa­nie”, to archi­tek­tu­ra kodu: ?obiek­to­wa? archi­tek­tu­ra???.

Proces pro­jek­to­wa­nia opro­gra­mo­wa­nia, idąc tro­pem ana­li­zy sys­te­mo­wej i opi­sa­nia mecha­ni­zmu dzia­ła­nia tego cze­goś”, zaczy­na się już na eta­pie ana­li­zy. Programista imple­men­tu­je model a nie wymy­śla pro­gram”. Oczywiście pod warun­kiem, że mamy tu na myśli ana­li­zę obiek­to­wą i pro­jek­to­wa­nie sys­te­mu a nie jakiś podział kodu na klasy”.

Na zakoń­cze­nie jeden z moich ulu­bio­nych cyta­tów na temat ana­li­zy i pro­jek­to­wa­nia obiektowego:

(źr. Martin Fowler, Analysis Patterns, 1997)
(źr. Martin Fowler, Analysis Patterns, 1997)?6?

  1. ?*?
    Artykuł został opu­bli­ko­wa­ny w mate­ria­łach pokon­fe­ren­cyj­nych: https://www.academia.edu/37284192/Materiały_pokonferencyjne_III_Ogólnopolskiej_Konferencji_Interdyscyplinarnej_Współczesne_zastosowania_informatyki_Architektura_kodu_aplikacji_jako_pierwszy_etap_tworzenia_oprogramowania
  2. ???
    Wielu auto­rów przy­wo­łu­je tu poję­cie kom­po­nen­tów a nie obiek­tów. Komponentem jest tu każ­dy samo­dziel­ny, komu­ni­ku­ją­cy się z oto­cze­niem, obiekt nie­za­leż­nie od wiel­ko­ści i stop­nia złożoności. 

Źródła:

  1. 1.
    Paradygmaty programowania/Wykład 1: Co to jest para­dyg­mat pro­gra­mo­wa­nia? – Studia Informatyczne. MIMUW. http://wazniak.mimuw.edu.pl/index.php?title=Paradygmaty_programowania/Wykład_1:_Co_to_jest_paradygmat_programowania%3F. Accessed July 16, 2017.
  2. 2.
  3. 3.
    Fowler M. bli­ki: BoundedContext. mar​tin​fow​ler​.com. https://​mar​tin​fow​ler​.com/​b​l​i​k​i​/​B​o​u​n​d​e​d​C​o​n​t​e​x​t​.​h​tml. Published January 15, 2014. Accessed July 16, 2017.
  4. 4.
    Żeliński J. Analiza biz­ne­so­wa. Praktyczne mode­lo­wa­nie orga­ni­za­cji. one​press​.pl. http://​one​press​.pl/​v​i​e​w​/​2​2​3​9​k​/​s​f​o​m​o​d​.​htm. Accessed July 16, 2017.
  5. 5.
  6. 6.
    Martin Fowler, Analysis Patterns, 1997.

WIT – Praktyki zawodowe dla studentów

Zakres prac

Praktyki te są pra­cą pole­ga­ją­cą na bada­niu sku­tecz­no­ści sfor­ma­li­zo­wa­nych metod opi­su w ana­li­zie pod­mio­tów gospo­dar­czych. Celem jest nabra­nie doświad­cze­nia w ana­li­zie logicz­nej i poję­cio­wej pod­mio­tów gospo­dar­czych, wyko­na­nej z uży­ciem sfor­ma­li­zo­wa­nych metod. Do pra­cy pole­cam narzę­dzie Visual-Paradigm dostęp­ne na uczel­ni w ramach licen­cji aka­de­mic­kiej, na uży­tek wła­sny moż­na tak­że pobrać okro­jo­ną, dar­mo­wą wer­sję com­mu­ni­ty edi­tion tego oprogramowania.

Plan prac:

  1. Zapoznać się dokład­nie ze spe­cy­fi­ka­cją nota­cji Business Motivation Model? (BMM?), roz­dzia­ły 7. i 9. (pozo­sta­łe wg. woli), oraz przy­po­mnieć sobie ele­men­ty mode­lo­wa­nia poję­cio­we­go w UML. Zalecana moja książ­ka (Analiza Biznesowa)
  2. Wybrać (każ­dy prak­ty­kant) spo­śród firm obec­nych na Giełdzie Papierów Wartościowych spół­kę (jed­ną lub wię­cej, każ­da z innej bran­ży, licz­ba spół­ek uzgad­nia­nia ze mną), tu koniecz­ne spo­tka­nie u mnie w biu­rze.
  3. Dla każ­dej spół­ki opra­co­wać model zgod­nie z nota­cją BMM i model pojęciowy: 
    1. Schemat blo­ko­wy 1: misja i wizja, w nich cele, mier­ni­ki oraz stra­te­gia i taktyka
    2. Schemat blo­ko­wy 2: ana­li­za SWOT dla pro­duk­tu firmy
    3. Słownik klu­czo­wych pojęć biznesowych

Model Motywacji Biznesowej

Podstawą (szkie­le­tem) ana­li­zy biz­ne­so­wej jest tak zwa­ny Model Motywacji Biznesowej (ang BMM, Business Motivation Model, spec. https://​www​.omg​.org/​s​p​e​c​/​B​MM/. Model BMM ujmu­je kon­tekst pro­jek­tu biz­ne­so­wo w róż­nych wymia­rach, w celu uza­sad­nie­nia dla­cze­go Zarząd orga­ni­za­cji chce coś robić, do cze­go dąży, jak zamie­rza to osią­gnąć oraz jak oce­ni rezul­ta­ty. Główne ele­men­ty mode­lu BMM:

  • Stan koń­co­wy – Cele: Co (w odróż­nie­niu od jak) orga­ni­za­cja chce osiągnąć,
  • Metody – Środki : Jak i z pomo­cą cze­go orga­ni­za­cja zamie­rza osią­gnąć swo­je cele,
  • Strategia osią­gnię­cia celu: jak pla­nu­je­my osią­gnąć cel,
  • Taktyka: co będzie­my w związ­ku z tym robić.
  • Organizacja: Reguły biz­ne­so­we oraz Polityki, są to czę­ści mode­lu biz­ne­so­we­go Organizacji, zawie­ra­ją wewnętrz­ne zasa­dy funkcjonowania,
  • Czynniki wpły­wu, Ograniczenia: mają wpływ na orga­ni­za­cje i spo­sób jaki osią­ga ona swo­je cele albo korzy­sta ze swo­ich środków,
  • Ocena sytu­acji, ryzy­ka, ocze­ki­wa­ne zyski itp.: w jaki spo­sób Ograniczenia wpły­wa­ją na spo­sób w jaki orga­ni­za­cja z pomo­cą posia­da­nych środ­ki osią­ga cele,

Podstawowym celem opra­co­wa­nia tego mode­lu jest usys­te­ma­ty­zo­wa­nie posia­da­nej wie­dzy o celu pro­jek­tu, jego śro­do­wi­sku i jej ewen­tu­al­ne uzupełnienie.

Ustalenia te poma­ga­ją unik­nąć pro­ble­mów pod­czas usta­la­nia prio­ry­te­tów dla poszcze­gól­nych wyma­gań oraz zabez­pie­cza­ją przez bra­kiem moż­li­wo­ści stwier­dze­nia czy wdro­że­nie odnio­sło zamie­rzo­ny skutek.

W trak­cie całej ana­li­zy biz­ne­so­wej na eta­pie spe­cy­fi­ko­wa­nia wyma­gań powin­ny być te wyma­ga­nia wery­fi­ko­wa­ne, czy przy­czy­nia­ją się do osią­gnię­cia celu pro­jek­tu. Brak jasno zde­fi­nio­wa­ne­go celu oraz powią­za­nych z nim ele­men­tów takich jak czyn­ni­ki wpły­wu, dzia­ła­nia pozwa­la­ją­ce na osią­gnię­cie celu, pro­ce­sy biz­ne­so­we reali­zu­ją­ce stra­te­gie osią­ga­nia celu, pro­wa­dzi do sytu­acji, w któ­rej nie ma moż­li­wo­ści spraw­dze­nia czy dane wyma­ga­nie przy­czy­nia się do osią­gnię­cia celu pro­jek­tu. Brak kry­te­rium oce­ny pro­wa­dzi do zja­wi­ska zwa­ne­go puch­nię­ciem zakre­su pro­jek­tu: poja­wia­ją się nowe ocze­ki­wa­nia i nie ma narzę­dzia do ich akcep­ta­cji lub odrzucania.

Przykładowe mode­le moty­wa­cji wyra­żo­ne gra­ficz­nie poniżej:

Plan rozwojowy - diagram BMM
Plan roz­wo­jo­wy – dia­gram BMM

Model pojęciowy

Omawiany na zaję­ciach. Tu opis mode­li poję­cio­wych.

Inne pomoce

Opis two­rze­nia mode­li BMM (tuto­rial Visual-Paradigm)

Komunikacja

Napisz do mnie


    Prześlij plik

    (plik ma mieć roz­sze­rze­nie .pdf)

    Pytania

    Ogólne pyta­nia doty­czą­ce tego jak opra­co­wać doku­men­ty pro­szę wpi­sy­wać w toku dys­ku­sji poniżej.

    OMG’s MetaObject Facility

    Końcówka roku, wręcz ostat­ni jego dzień 😉 …

    Mając przed ocza­mi kolej­ny pro­jekt badaw­czy, kolej­ny raz gapię się na stro­ny OMG i mała reflek­sja: porząd­ki dobie­ga­ją koń­ca. W arty­ku­le o UML v.2.5. wspo­mi­na­łem, że zre­zy­gno­wa­no w koń­cu z poję­cia agre­ga­cji” (zwa­nej cza­sa­mi sła­bą kom­po­zy­cją”), odcho­dzi się od cał­ko­wi­cie zbęd­nych związ­ków extend” i inc­lu­de” w przy­pad­kach uży­cia (kon­struk­cje te nadal pozo­sta­ją w spe­cy­fi­ka­cji z uwa­gi na kom­pa­ty­bil­ność wstecz narzę­dzi CASE i doku­men­tów jakie w nich są nadal two­rzo­ne lub archi­wi­zo­wa­ne). Paradoksalnie spe­cy­fi­ka­cja UML jest uprasz­cza­na (sta­le tkwi w niej echo pier­wot­ne­go zlep­ku kil­ku nota­cji z lat 99-tych). Oczyma wyobraź­ni widzę jak ktoś, w toku prac nad UML, sta­le wyma­chu­je brzy­twą Ockhama”… 

    Czytaj dalej… OMG’s MetaObject Facility”