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:

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