Tekst ten zawie­ra opis metod jakie sto­su­je i opis pro­duk­tów jakie dostar­czam w przy­pad­kach, gdy wyma­ga­ne jest opro­gra­mo­wa­nie dedy­ko­wa­ne (tak­że dedy­ko­wa­ne modu­ły ERP zwa­ne add-on). Adresatem tego wpi­su są moi klien­ci oraz dostaw­cy opro­gra­mo­wa­nia ERP i dewe­lo­pe­rzy, gdyż Opis Techniczny Oprogramowania (archi­tek­tu­ra i logi­ka prze­twa­rza­nia infor­ma­cji – model dzie­dzi­ny sys­te­mu) to wyma­ga­nie klien­ta w sto­sun­ku do pro­duk­tu zama­wia­ne­go u dewe­lo­pe­ra lub dostaw­cy opro­gra­mo­wa­nia. Deweloper/dostawca wraz z pro­jek­tem logi­ki dzia­ła­nia sys­te­mu otrzy­mu­je tak­że Analizę Biznesową jako opis kon­tek­stu jego użycia. 

Standardowo w pro­jek­tach ana­li­zu­ję otrzy­ma­ne mate­ria­ły źró­dło­we, pro­duk­tem tych ana­liz sá Analizę Biznesowa i Opis Techniczny Oprogramowania. Ten ostat­ni to doku­ment, zawie­ra­ją­cy opis mecha­ni­zmu dzia­ła­nia poszcze­gól­nych obsza­rów orga­ni­za­cji. Oprogramowanie, któ­re­go uży­wa lub pla­nu­je wdro­żyć do uży­cia ta orga­ni­za­cja, reali­zu­je (będzie reali­zo­wać ) część tego mecha­ni­zmu dzia­ła­nia: to jest logi­ka biznesowa. 

Systemy zarzą­dza­ją­ce infor­ma­cją zor­ga­ni­zo­wa­ne są wokół doku­men­tów i dzie­dzi­no­wych (kon­tek­sto­wych) reguł ich prze­twa­rza­nia. Dlatego naj­bar­dziej ade­kwat­na meto­dą ich pro­jek­to­wa­nia są wzor­ce opar­te na onto­lo­giach, dzie­dzi­no­wych kom­po­nen­tach, doku­men­tach i ich prze­ka­zy­wa­niu mię­dzy komponentami.

Zakres 1 to nie raz samo­dziel­ny pro­jekt biz­ne­so­wy, któ­re­go celem jest poten­cjal­na opty­ma­li­za­cja pro­ce­sów. Jeżeli jed­ną z reko­men­da­cji jest wdro­że­nie opro­gra­mo­wa­nia, reali­zo­wa­ny jest Zakres 2. Jeżeli oka­że sie, że na ryn­ku nie ma wyma­ga­ne­go opro­gra­mo­wa­nia, reali­zo­wa­ny jest Zakres 3. Oferta ceno­wa na stro­nie Dla Firmy.

Jeżeli moim zle­ce­nio­daw­cą jest dewe­lo­per, każ­do­ra­zo­wo usta­lam indy­wi­du­al­nie wyma­ga­nia wobec doku­men­ta­cji jaka ma powstać.

Poniższy opis to ogól­ne zasa­dy współpracy. 

W razie jakich­kol­wiek pytań pro­sze o kon­takt. Poniżej ogól­ny opis metod pracy.

Typowy podział na role w projekcie

Podział pra­cy w pro­jek­tach inży­nier­skich naj­czę­ściej ma cha­rak­ter wyni­ka­ją­cy nie tyle z roli co z dzie­dzi­ny wie­dzy. W pro­jek­tach IT mamy dwie dzie­dzi­ny: wie­dza o infor­ma­cji (infor­ma­tion scien­ce, infor­ma­tion sys­tems) i wie­dza o tech­no­lo­gii infor­ma­tycz­nej (infor­ma­tion tech­no­lo­gy) (patrz take cie­ka­wy opis: Information Technology vs. Information Systems). Jest to o tyle istot­ne, że wybór meto­dy imple­men­ta­cji roz­wią­za­nia i tech­no­lo­gii, powi­nien nastą­pić dopie­ro po opra­co­wa­niu same­go roz­wią­za­nia (logi­ki tego jakie dane i jak przetwarzamy).

Najczęściej jestem anga­żo­wa­ny do pro­jek­tów, w któ­rych usta­lo­no role: 

1. Zamawiający: jako Organizacja Analizowana zgła­sza cele biz­ne­so­we i pro­ble­my, udo­stęp­nia wie­dzę na swój temat, jest sta­łym recen­zen­tem pro­duk­tów ana­li­zy i pro­jek­to­wa­nia (zama­wia­ją­cy to eks­pert dzie­dzi­no­wy) w toku pro­jek­tu. To kadry kie­row­ni­cze Zamawiającego, wspie­ra­ne przez Asystenta-koor­dy­na­to­ra, dostar­cza­ją mate­ria­ły źró­dło­we opi­su­ją­ce opis ich dzia­ła­nia i potrzeby. 

2. Asystent-koor­dy­na­tor: oso­ba zaan­ga­żo­wa­na bez­po­śred­nio z zbie­ra­nie mate­ria­łów źró­dło­wych (wywia­dy, kolek­cjo­no­wa­nie doku­men­tów, itp.), z regu­ły jest to oso­ba anga­żo­wa­na (zatrud­nia­na, wyzna­cza­na) przez Zamawiającego.

3. Analityk: jako archi­tekt-pro­jek­tant (inży­nier sys­te­mów, obszar Information Systems), pro­wa­dzi ana­li­zę otrzy­ma­nych mate­ria­łów, opra­co­wu­je model biz­ne­so­wy orga­ni­za­cji (pro­ce­sy biz­ne­so­we, prze­pływ i logi­ka prze­twa­rza­nia infor­ma­cji), a potem opra­co­wu­je model dzie­dzi­no­wy roz­wią­za­nia jako archi­tek­tu­rę i logi­kę dzia­ła­nia sys­te­mu (patrz jak powsta­je Opis Techniczny Oprogramowania), jest ona wyma­ga­niem dla dostawcy. 

4. Deweloper (Programmer, obszar Information Technology): jako wyko­naw­ca imple­men­ta­cji roz­wią­za­nia, wybie­ra tech­no­lo­gię, narzę­dzia i śro­do­wi­sko apli­ka­cji, pro­jek­tu­je i wyko­nu­je imple­men­ta­cję, dostar­cza i wdra­ża oprogramowanie.

(źr.: https://​buil​tin​.com/​r​e​c​r​u​i​t​i​n​g​/​s​o​f​t​w​a​r​e​-​e​n​g​i​n​e​e​r​-​v​s​-​p​r​o​g​r​a​m​mer)

Poniżej zobra­zo­wa­no to jako pro­ces wytwarzania/dostarczania opro­gra­mo­wa­nia (w moim przy­pad­ku zorien­to­wa­ne­go na mode­le: MBSE). W przy­pad­ku wdra­ża­nia sys­te­mów stan­dar­do­wych, rolę dewe­lo­pe­ra peł­ni fir­ma wdra­ża­ją­ca dostar­czo­ne goto­we opro­gra­mo­wa­nie, któ­rej kon­sul­ta­cji kon­fi­gu­ru­ją dostar­czo­ny sys­tem, jed­nak w przy­pad­ku gdy wyma­ga­ne są funk­cjo­nal­no­ści dedy­ko­wa­ne, powsta­ją one jako dedy­ko­wa­ne kom­po­nen­ty (add-ons).:

Projekt roz­wią­za­nia to począt­ko­wo model przy­pad­ków uży­cia (UML) i ich spe­cy­fi­ka­cje (makie­ty, sce­na­riu­sze i logi­ka danych) oraz archi­tek­tu­ra inte­gra­cji HLD (kom­po­nen­ty, doku­men­to­wy model danych, sekwen­cje) . Na jego pod­sta­wie Dostawcy skła­da­ją oferty. 

Po wybo­rze Dostawcy pro­jekt jest reali­zo­wa­ny ite­ra­cyj­nie: kolej­ne przy­pad­ki uży­cia (usłu­gi apli­ka­cji) są wdra­ża­ne, a jeże­li wyma­ga­ne jest dedy­ko­wa­ne opro­gra­mo­wa­nie, przy­pad­ki uży­cia są dopre­cy­zo­wy­wa­ne (archi­tek­tu­ra LLD) i imple­men­to­wa­ne. Zgodnie z zale­ce­nia­mi pro­du­cen­tów sys­te­mów stan­dar­do­wych, nie dopusz­czam kasto­mi­za­cji stan­dar­do­we­go opro­gra­mo­wa­nia, bra­ku­ją­ce funk­cjo­nal­no­ści są dostar­cza­ne jako opro­gra­mo­wa­nie dedy­ko­wa­ne (patrz Kastomizacja…).

Od wie­lu lat pra­cu­ję wg. zasady: 

softwa­re deve­lo­per vs softwa­re engi­ne­er
Generally, softwa­re engi­ne­ers look after the big­ger pic­tu­re, whi­le softwa­re deve­lo­pers focus on one area to exe­cu­te the­ir plans. Engineers can act as deve­lo­pers, too, or sim­ply over­see deve­lo­pers who cre­ate func­tio­nal programs.

https://​www​.rand​stad​.co​.uk/​c​a​r​e​e​r​-​a​d​v​i​c​e​/​c​a​r​e​e​r​-​g​u​i​d​a​n​c​e​/​f​u​l​l​-​s​t​a​c​k​-​d​e​v​e​l​o​p​e​r​-​v​s​-​s​o​f​t​w​a​r​e​-​e​n​g​i​n​e​er/

Czym jest Projekt czyli Model Logiczny Systemu

Model Logiczny Systemu w nomen­kla­tu­rze MDA (Model-dri­ven Architecture) to Platform Independent Model (PIM) czu­li model mecha­ni­zmu jego dzia­ła­nia. Związek mię­dzy pro­jek­tem a dzia­ła­ją­cym opro­gra­mo­wa­niem wyglą­da tak:

Ważne jest to, by wie­dzieć, że: 1. kod nie jest swo­ją doku­men­ta­cją a jego ochro­na praw­na jest bar­dzo ogra­ni­czo­na, 2. pra­wo chro­ni pro­jekt opro­gra­mo­wa­nia (Platform Independent Model) jako utwór i jako know-how, kod jako odtwo­rze­nie pro­jek­tu w okre­ślo­nym języ­ku pro­gra­mo­wa­nia zawsze jest utwo­rem zależnym. 

Powyższe jest też czę­sto okre­śla­ne nazwą: archi­tek­tu­ra hek­sa­go­nal­na (Hexagonal Architecture). Podstawowym zało­że­niem jest tu wyraź­ne oddzie­le­nie stro­ny użyt­kow­ni­ka (User-Side), logi­ki biz­ne­so­wej (Business Logic) i stro­ny ser­we­ra czy­li śro­do­wi­ska wyko­ny­wa­nia apli­ka­cji (Server-Side) (patrz: Hexagonal Architecture: three prin­ci­ples and an imple­men­ta­tion exam­ple).

Powyższy dia­gram bywa przed­sta­wia­ny tak­że w innej formie: 

Obszar nazwa­ny Domain to nasz model PIM (logi­ka biz­ne­so­wa). Jest to czę­sto w prze­tar­gach doku­ment nazy­wa­ny Opis Techniczny Oprogramowania (lub Opis Przedmiotu Zamówienia), w rozu­mie­niu opi­su mecha­ni­zmu jego dzia­ła­nia. Ta część reali­zu­je wyma­ga­nia funk­cjo­nal­ne. Pozostałe kom­po­nen­ty odpo­wia­da­ją za reali­za­cję wyma­gań pozafunkcjonalnych.

Struktura i treść moich opracowań

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 pro­dukt Analizy Biznesowej, Mapa pro­ce­sów i ich mode­le 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 tego eta­pu pra­cy jest zro­zu­mie­nie tego jak okre­ślo­na orga­ni­za­cja dzia­ła i współ­dzia­ła z oto­cze­niem oraz prze­ka­za­nie tej wie­dzy dostaw­cy dostaw­cy roz­wią­za­nia w celu lep­sze­go zro­zu­mie­nia przez nie­go kon­tek­stu i ś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). Na tym eta­pie są reali­zo­wa­ne ewen­tu­al­ne zmia­ny w pro­ce­sach to-be i okre­śla­ny zakres projektu.

Projekt Rozwiązania

Ten etap to okre­śle­nie wyma­gań na opro­gra­mo­wa­nie. Najpierw powsta­ją: Diagram przy­pad­ków uży­cia (lista usług apli­ka­cji) i model HLD (pod­sys­te­my, inte­gra­cje). Jeżeli zawie­dzie poszu­ki­wa­nie na ryn­ku zgod­ne­go z tymi wyma­ga­nia­mi goto­we­go opro­gra­mo­wa­nia (np. ERP), usłu­gi apli­ka­cji wyma­ga­ją­ce wytwo­rze­nia, spe­cy­fi­ko­wa­ne są jako pro­jekt logi­ki sys­te­mu do imple­men­ta­cji (jako odręb­ne mikroserwisy). 

Z zasa­dy ope­ru­ję przy­pad­ka­mi uży­cia, ich sce­na­riu­sza­mi oraz mode­lem dzie­dzi­ny budo­wa­nym jako archi­tek­tu­ra sepa­ro­wa­nych od sie­bie usług apli­ka­cyj­nych (imple­men­to­wa­ne jako mikro­ser­wi­sy, kom­po­nen­ty) . Struktury infor­ma­cji są spe­cy­fi­ko­wa­ne jako doku­men­ty (potem XML/JSON), 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 ICONIX, DDD, micro ser­wi­sy i doku­men­to­we struk­tu­ry danych. Architektura mikro­ser­wi­sów opar­ta jest na poniż­szym schemacie:

To co obec­nie nazy­wa­my zwin­nym two­rze­niem opro­gra­mo­wa­nia (agi­le) to ​„raczej” szyb­ka ana­li­za cało­ści pro­ble­mu (ana­li­za biz­ne­so­wa), pro­jekt logi­ki biz­ne­so­wej roz­wią­za­nia, czy­li podział całe­go sys­te­mu na kom­po­nen­ty biz­ne­so­we (archi­tek­tu­ra HLD) oraz ite­ra­cyj­ne ich uszcze­gó­ła­wia­nie (archi­tek­tu­ra LLD każ­de­go kom­po­nen­tu) i kolej­ne, ite­ra­cyj­ne ich imple­men­to­wa­nie. Praktyka poka­zu­je, koszt prac ana­li­ty­ka pro­jek­tan­ta (tu inży­nier sys­te­mo­wy), zależ­nie od stop­nia zło­żo­no­ści pro­jek­tu, to ok. 10 – 20 % całe­go budże­tu na wyko­na­nie opro­gra­mo­wa­nia (kosz­ty śro­do­wi­ska: licen­cje, sprzęt itp. do dodat­ko­we kosz­ty), czy­li deve­lo­per to jed­nak zna­ko­mi­ta więk­szość pra­co­chłon­no­ści i budżetu.

Dlaczego moje projekty są zorientowane na dokumenty

Ważna uwa­ga! Poniższe doty­czy zarów­no apli­ka­cji two­rzo­nych od zera jak i apli­ka­cji już ist­nie­ją­cych i roz­wi­ja­nych. Poniższy opis doty­czy obu rodza­jów apli­ka­cji, w przy­pad­ku apli­ka­cji już ist­nie­ją­cych, doku­men­ty w mode­lu logicz­nym mogą być utrwa­la­ne w bazie i mode­lu rela­cyj­nym z pomo­cą dodat­ko­wej war­stwy ORM (mapo­wa­nie obiek­to­wo-rela­cyj­ne), ma to jed­nak opi­sa­ne niżej kon­se­kwen­cje. Najczęściej sto­so­wa­ne prze­ze mnie wzor­ce pro­jek­to­we to Repozytorium/Envelope, Active Record lub Active Table oraz DDD/Aggregate . Co do zasa­dy na eta­pie ana­li­zy i pro­jek­to­wa­nia nie two­rzę i nie uży­wam mode­li danych rozu­mia­nych jako ​„jed­na rela­cyj­na baza danych dla projektu”. 

Krótkie wyjaśnienie

Pojęcie ​„zbiór danych” więk­szo­ści nadal koja­rzy się z rela­cyj­nym mode­lem danych. 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 a doku­men­ty są z zasa­dy nie­za­leż­ny­mi od sie­bie byta­mi (to nie raz zawie­ra­ją powią­za­ne logicz­nie tre­ści nicze­go tu nie zmie­nia). Dokument to przede wszyst­kim kon­tekst dla danych na nim zgro­ma­dzo­nych. Dlatego tak zwa­ne Systemy Biznesowe czę­sto nazy­wa­ne są sys­te­ma­mi for­mu­la­rzo­wy­mi: z zasa­dy ope­ru­ją na doku­men­tach (for­mu­la­rzach), inte­gra­cja sys­te­mów – 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 i ich tre­ścią. 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 tabel rela­cyj­nych (do ich zapi­su i odczy­tu) to bar­dzo zło­żo­ne struk­tu­ry kodu, powo­du­ją­ce, że tak zor­ga­ni­zo­wa­ne bazy 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. 

W dzi­siej­szej erze big data moż­na zaob­ser­wo­wać ogrom­ną ewo­lu­cję w typach baz danych i ich wyko­rzy­sta­niu. Rozwiązania takie jak np. MySQL czy Oracle, nie są w sta­nie spro­stać współ­cze­snym wyma­ga­niom zwią­za­nym z obsłu­gą dużej róż­no­rod­no­ści, szyb­ko­ści, praw­dzi­wo­ści i, co waż­ne, obszer­nych zbio­rów danych. Bazy danych NoSQL są szyb­ki­mi roz­wią­za­nia­mi i dosko­na­le radzą sobie z tymi wyma­ga­nia­mi dzię­ki dodat­ko­wym cechom, takim jak ska­lo­wa­nie pozio­me, wyso­ka wydaj­ność, zgod­ność z ela­stycz­no­ścią i wszechstronność.

Dokument jako agregat

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 (lub JSON) w bazach doku­men­to­wych (NpSQL) i prze­cho­wy­wa­ne w posta­ci agre­ga­tów .

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ś struk­tu­ry takie jaki XML czy JSON, moż­na prze­twa­rzać i prze­sy­łać mię­dzy apli­ka­cja­mi ze znacz­nie więk­szą swo­bo­dą .

W moich pro­jek­tach dane są mode­lo­wa­ne jako hie­rar­chicz­ne agre­ga­ty (patrz wzor­ce obiek­to­we) prze­cho­wy­wa­ne w nie­za­leż­nych pła­skich (nie powią­za­nych rela­cyj­nie) tabe­lach: kolum­ny takiej tabe­li repre­zen­tu­ją meta­da­ne, cały doku­ment jako XML/JSON jest zawar­to­ścią jed­ne­go z pól. 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» (wiersz ww. tabe­li z doku­men­ta­mi) odpo­wie­dzial­ny jest za prze­cho­wa­nie doku­men­tu (patrz wzo­rzec «enve­lo­pe» ): ma 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 . Od pozo­sta­łej czę­ści apli­ka­cji oddzie­la go kom­po­nent reali­zu­ją­cy logi­kę dostę­pu do danych. 

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 . Dokument jest tu agre­ga­tem, któ­ry moż­na wyra­zić jako drze­wia­sta struk­tu­rę klas i mapo­wać na rela­cyj­na bazę danych:

A moż­na agre­gat uczy­nić (zaim­ple­men­to­wać) jako sta­tycz­ną struk­tu­rę np. XML i prze­cho­wy­wać go w bazie doku­men­to­wej (NoSQL):

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 w moto­rach SQL nie ma więk­sze­go zna­cze­nia, bo istot­ny jest tu nie­re­la­cyj­ny model danych .

Komunikacja i moja rola w projekcie

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).

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 (komu­ni­ka­cja asyn­chro­nicz­na w pro­jek­cie). Dokumenty to prze­sy­ła­ne mi mate­ria­ły opi­su­ją­ce potrze­by zama­wia­ją­ce­go, ele­men­ty obo­wią­zu­ją­ce­go pra­wa, wewnętrz­ne instruk­cje i regu­la­mi­ny, przy­kła­do­we doku­men­ty ope­ra­cyj­ne, itp. 

Jako ana­li­tyk biz­ne­so­wy i jed­no­cze­nie archi­tekt roz­wią­za­nia, jestem pro­jek­tan­tem. Na pod­sta­wie otrzy­ma­nych mate­ria­łów pro­jek­tu­ję roz­wią­za­nie i odsy­łam jego opis (opi­sa­ne sche­ma­ty blo­ko­we pre­zen­tu­ją­ce pro­ce­sy biz­ne­so­we, archi­tek­tu­rę inte­gra­cji, struk­tu­ry doku­men­tów i logi­kę ich popraw­no­ści, itp. (co do zasa­dy sto­su­ję stan­dar­dy: nota­cje BPMN, UML, SBVR, itp.). Jak i dla­cze­go dla­cze­go? Polecam poniż­szy refe­rat, któ­ry mam nadzie­ję wie­le wyjaśni:

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ę więc poka­zać tyl­ko wybra­ne opra­co­wa­nia. Sa to wyłącz­nie opu­bli­ko­wa­ne wcze­śniej doku­men­ty w prze­tar­gach publicz­nych lub opi­sy ​„demo” (tu jako arty­kuł: Projekt apli­ka­cji ? przy­kład). Poniższe opra­co­wa­nia to 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). 

Komentarze do pro­jek­tu Generator Ofert na stro­nie: Generator Ofert ? Komentarze

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 stro­nie: 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/.

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 zapra­szam do komen­ta­rzy pod tym tek­stem lub pro­szę o kon­takt.

Stale poszu­ku­ję deve­lo­pe­rów dla moich klien­tów: zare­je­struj się jako deve­lo­per na new­slet­ter.

Źródła: