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 wyma­ga­nia na opro­gra­mo­wa­nie. 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 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.

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 doku­men­tu jest zro­zu­mie­nie tego jak dzia­ła okre­ślo­na orga­ni­za­cja 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 BPMN (Procesy biz­ne­so­we), UML (struk­tu­ry doku­men­tów biz­ne­so­wych) oraz SBVR (słow­nik pojęć i regu­ły biz­ne­so­we). Dokument ten 

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 sepa­ro­wa­ne usłu­gi apli­ka­cyj­ne (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, 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 zgromadzonych. 

Wady rela­cyj­ne­go mode­lu danych: 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, jest pozba­wio­ny kon­tek­stu , nie spraw­dza się w sys­te­mach zarzą­dza­ją­cych doku­men­ta­mi. Dokument, tak­że w sen­sie praw­nym, nie może być gene­ro­wa­ną dyna­micz­nie (zapy­ta­nia SQL do bazy rela­cyj­nej) struk­tu­rą, bo jest wte­dy wir­tu­al­nym bytem, a taki nie sta­no­wi doku­men­tu w pra­wie (Kodeks Cywilny), nie da się tak­że 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 uzu­peł­nia­ne posta­cią do czy­ta­nia i dru­ku” w for­ma­cie pdf (real­nie są to pli­ki pdf z załą­czo­ny­mi wer­sja­mi XML). 

Dlatego dane gru­po­wa­ne w doku­men­ty, 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 kil­ka rzę­dów razy 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 popularniejsze:

W moich pro­jek­tach dane są mode­lo­wa­ne jako struk­tu­ry doku­men­tów XML. Każdy doku­ment ma struk­tu­rę wyra­żo­ną w posta­ci hie­rar­chicz­ne­go agre­ga­tu 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 , . Zamiast gra­ficz­ne­go mock-up’u, struk­tu­ra ta może być wyra­żo­na w posta­ci zagnież­dżo­nej struk­tu­ry (agre­gat) wyko­na­nej w uży­ciem nota­cji UML .

Mechanizm utrwa­la­nia doku­men­tów XML, któ­rą są cią­ga­mi zna­ków ASCII, 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: 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 (regu­ły wali­da­cji doku­men­tów, sza­blo­ny XSD/DTD) prze­trzy­ma­na jest poza repo­zy­to­rium, może być wspól­na dla wie­lu doku­men­tów w okre­ślo­nym 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, jest więc to tak­że pro­ces zacho­dzą­cy wewnątrz państw wspól­no­ty EU. Dlatego 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. 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 nie są one obję­te tajem­ni­cą przed­się­bior­stwa, dla­te­go nie mogę poka­zać ich zbyt wie­le. Poniżej jed­nak dwa opra­co­wa­nia wyko­na­ne dla admi­ni­stra­cji publicz­nej jako Opis Przedmiotu Zamówienia i jed­no jako moje przy­kła­do­we demo. 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. 

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ć dedy­ko­wa­ny. 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 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 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/
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
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.
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.