Jest to opis dla każ­dej fir­my podej­mu­ją­cej (lub pla­nu­ją­cej) ze mną współ­pra­cę. Proszę się dokład­nie zapo­znać z poniż­szą tre­ścią, ten doku­ment opi­su­je stan­dar­do­wy spo­sób komu­ni­ka­cji w każ­dym moim pro­jek­cie. W tek­ście tym opi­su­ję dla­cze­go pra­cu­ję na doku­men­tach i jakich narzę­dzi uży­wam do pro­wa­dze­nia komu­ni­ka­cji i wymia­ny treści.

Wymagane mate­ria­ły źró­dło­we zosta­ły opi­sa­ne poni­żej i ozna­czo­ne sza­rym tłem. Rolą człon­ków zespo­łu Zamawiającego jest nie tyl­ko dostar­cza­nie mate­ria­łów źró­dło­wych ale tak­że aktyw­ny udział w roli recen­zen­tów powsta­ją­cych tre­ści, dla­te­go poni­żej opi­sa­no pod­sta­wo­we typy i cele two­rze­nia okre­ślo­nych sche­ma­tów blo­ko­wych, legen­dy uży­tych sym­bo­li oraz przy­kła­dy ich uży­cia. Opisano tak­że narzę­dzie słu­żą­ce do komu­ni­ka­cji. Wystarczającą umie­jęt­no­ścią recen­zen­ta jest czy­ta­nie tych sche­ma­tów, ich opi­sów i zgła­sza­nie mery­to­rycz­nych uwag (co jest nie­praw­dą, cze­go brakuje). 

Wszelkie wąt­pli­wo­ści są wyja­śnia­ne na cyklicz­nych spo­tka­niach statutowych. 

Na czym polega realizacja projektu analitycznego?

Pełny zakres pro­jek­tu ana­li­tycz­ne­go to opra­co­wa­nie tak zwa­nej Architektury Korporacyjnej. To nic inne­go jak zestaw powią­za­nych sche­ma­tów blo­ko­wych (mode­li) opi­su­ją­cych orga­ni­za­cję od jej stra­te­gii ryn­ko­wej, przez pro­ce­sy biz­ne­so­we, do infra­struk­tu­ry IT, w spo­sób iden­ty­fi­ku­ją­cy ich wza­jem­ne powią­za­nia i wpływ. Poniżej sche­mat obra­zu­ją­cy te mode­le i powiązania:

Pełny zakres ana­li­zy to opra­co­wa­nie: mode­lu map i mode­li pro­ce­sów biz­ne­so­wych (Business Process), listy potrzeb wobec sys­te­mu IT (Business Services), archi­tek­tu­ry inte­gra­cji wyso­kie­go pozio­mu (Components). Dostawcy sys­te­mów ofe­ru­ją swo­je roz­wią­za­nia i dostar­cza­ją spe­cy­fi­ka­cje tech­nicz­ne swo­ich pro­duk­tów (Operational Resources). Kluczowe dla cało­ści są: defi­ni­cje zadań i tego jak będą (są) reali­zo­wa­ne w sys­te­mie IT (task defi­ni­tion, task imple­men­ta­tion) oraz ich odwzo­ro­wa­nie na sys­te­my IT (Interface defi­ned by enter­pri­se seman­tic and requirements).

Zakres pro­jek­tu może być ogra­ni­czo­ny po uzgod­nie­niach z Zamawiającym. 

W toku ana­liz powsta­ją kolej­ne sche­ma­ty blo­ko­we i mode­le. Na eta­pie trwa­nia prac ana­li­tycz­no-pro­jek­to­wych ope­ru­je­my dra­ftem opra­co­wa­nia. Zamawiający i recen­zen­ci mają dostęp tyl­ko do odczy­tu”. Po prze­ka­za­niu doku­men­ta­cji Zamawiającemu (pra­wa mająt­ko­we wraz z pra­wem do two­rze­nia utwo­rów zależ­nych), może on two­rzyć jej kolej­ne wer­sje (jako autor prze­ka­zu­ję tak­że pra­wa do two­rze­nia utwo­rów zależ­nych) lub pra­ce te reali­zu­je autor doku­men­ta­cji w ramach zle­co­ne­go mu nad­zo­ru autor­skie­go i nad­zo­ru mery­to­rycz­ne­go nad pra­ca­mi dostaw­ców sys­te­mów. Przykładowe pro­duk­ty mojej pra­cy na stro­nie: BIBLIOTEKA

W dal­szej czę­ści opi­sa­no powsta­ją­ce w toku ana­li­zy i pro­jek­to­wa­nia pro­duk­ty i wyma­ga­ne mate­ria­ły źró­dło­we (ozna­czo­no sza­rym tłem).

Komunikacja asynchroniczna i synchroniczna

Praca zespo­ło­wa i zarzą­dza­nie cza­sem oraz efek­tyw­ność wyma­ga­ją pla­no­wa­nia. Nie od dziś też wia­do­mo, że spo­tka­nia są naj­mniej efek­tyw­nym spo­so­bem pra­cy. Dlatego od wie­lu lat dzie­li się komu­ni­ka­cje na syn­chro­nicz­ną (wszel­ki spo­sób pro­wa­dze­nia dia­lo­gu, któ­ry odby­wa się w cza­sie rze­czy­wi­stym, spo­tka­nie, tele­kon­fe­ren­cja, komu­ni­ka­to­ry, natych­mia­sto­we odpi­sy­wa­nie na ema­il) oraz asyn­chro­nicz­ną (w prze­ci­wień­stwie do komu­ni­ka­cji syn­chro­nicz­nej, nie odby­wa się w cza­sie rze­czy­wi­stym). Nie jest moż­li­we wyeli­mi­no­wa­nie syn­chro­nicz­nej komu­ni­ka­cji (np. krót­kie spo­tka­nia sta­tu­so­we w pro­jek­tach) jed­nak zna­ko­mi­ta więk­szość prac ana­li­tycz­no-pro­jek­to­wych tych spo­tkań nie wyma­ga spo­tkań i warsz­ta­tów, pra­ce tego typu są znacz­nie efek­tyw­niej­sze jako pra­ca reali­zo­wa zadaniowo. 

Dlatego od wie­lu lat pra­cu­ję zada­nio­wo, zdal­nie, meto­dą asyn­chro­nicz­ną, jedy­nie w wyjąt­ko­wych wypad­kach są to spo­tka­nia lub„dyżur” (natych­mia­sto­wa dostępność).

Metody i narzędzia komunikacji w projekcie

Narzędzia:

  • mój adres ema­il: j.zelinski@it-consulting.pl lub info@jaroslawzelinski.biz,
  • doku­men­ta­cja pro­jek­to­wa on-line: Postmania (powia­do­mie­nia przy­cho­dzą z adre­su: support@visual-paradigm.com),
  • ofer­ty, zamó­wie­nia i roz­li­cze­nia: FreshBook (powia­do­mie­nia przy­cho­dzą z adre­sów: mail@fb02.freshbooks.com, mail@fb05.freshbooks.com, welcome@fb02.freshbooks.com).

Podstawowym celem komu­ni­ka­cji jest dostar­cza­nie mi mate­ria­łów źró­dło­wych i recen­zo­wa­nie (uwa­gi do tre­ści) powsta­ją­cej lub aktu­ali­zo­wa­nej doku­men­ta­cji ana­li­tycz­no-pro­jek­to­wej: jest nią Analiza Biznesowa i Opis Techniczny Rozwiązania (dalej Specyfikacja). Dostawcą mate­ria­łów źró­dło­wych jest zawsze zespół orga­ni­za­cji ana­li­zo­wa­nej (tu Recenzent). 

Powyższa pętla to raz kil­ka godzin a raz natych­mia­sto­wa odpo­wiedź. Jest to typo­wa tak zwa­na komu­ni­ka­cja asyn­chro­nicz­na. Uczestnicy piszą lub odpi­su­ją w dogod­nym dla sie­bie momen­cie, co nie zabu­rza ich nor­mal­nej codzien­nej pra­cy i obo­wiąz­ków. Tak powsta­ją­ca i aktu­ali­zo­wa­na doku­men­ta­cja pro­jek­to­wa (ana­li­za biz­ne­so­wa, spe­cy­fi­ka­cja wyma­gań) to tak zwa­na Żyjąca doku­men­ta­cja.

W trak­cie pro­jek­tu nie uży­wam pakie­tów biu­ro­wych, nie two­rzę arku­szy kal­ku­la­cyj­nych ani doku­men­tów w edy­to­rach tek­stów. Produktem do czy­ta­nia” (i do ewen­tu­al­ne­go dru­ku) jest doku­ment PDF sta­no­wią­cy peł­ną spe­cy­fi­ka­cję z dia­gra­ma­mi i opi­su­ją­cym je tek­stem. Jako pro­dukt pra­cy prze­ka­zu­ję tak­że edy­to­wal­ny plik źró­dło­wy (Visual-Paradigm oraz w uni­wer­sal­nym for­ma­cie XMI) zawie­ra­ją­cy wszyst­kie opi­sy, opra­co­wa­ne mode­le i struktury. 

Dodatkowe spo­tka­nia i warsz­ta­ty na życze­nie Zamawiającego (nie doty­czy spo­tkań sta­tu­so­wych) są roz­li­cza­ne jako dodat­ko­we pra­ce T&M.

Do zdal­nej pra­cy wyko­rzy­stu­ję, i udo­stęp­niam klien­tom, jed­no z naj­lep­szych narzę­dzi wspie­ra­ją­cych takie pro­jek­ty na ryn­ku: opro­gra­mo­wa­nie PostMania fir­my Visual-Paradigm, z któ­re­go korzy­sta­ją naj­więk­sze kon­cer­ny na świe­cie (lista i refe­ren­cje wybra­nych użyt­kow­ni­ków pakie­tu Visual-Paradigm, bez­pie­czeń­stwo wyko­rzy­sty­wa­ne­go repo­zy­to­rium VP). Visual-Paradigm to narzę­dzie CASE (ang. Computer Aided System Engineering, kom­pu­te­ro­we wspo­ma­ga­nie inży­nie­rii sys­te­mów). Stosuję go w całym pro­ce­sie ana­li­zy i mode­lo­wa­nia, oraz w toku two­rze­nia doku­men­ta­cji pro­jek­to­wej i zarzą­dza­nia nią. 

Wszystkie prze­sła­ne mi doku­men­ty są na ser­we­rze chro­nio­ne (kodo­wa­ne), ich kopie zapa­so­we są wyko­ny­wa­ne w try­bie dobo­wym. Powstające tre­ści są wer­sjo­no­wa­ne, wpro­wa­dza­ne zmia­ny są śle­dzo­ne i doku­men­to­wa­ne. Każda nowa treść lub jej zmia­na (zwa­na korek­tą – revi­sion) jest odno­to­wy­wa­na, ozna­czo­na w cza­sie i numerowana. 

Zapoznaj się z opi­sem: Visual Paradigm PostMania – Przewodnik Recenzenta.

Analiza biznesowa – materiały źródłowe i produkty analizy 

Na tym eta­pie powsta­ją: opi­sy biz­ne­so­wych celów pro­jek­tu, model struk­tu­ry orga­ni­za­cyj­nej, mode­le pro­ce­sów biz­ne­so­wych, opi­sy doku­men­tów biz­ne­so­wych, biz­ne­so­wy słow­nik pojęć. Podstawowym mate­ria­łem źró­dło­wym są wszel­kie wewnętrz­ne i zewnętrz­ne regu­la­mi­ny i zasa­dy, przy­kła­do­we doku­men­ty i opi­sy, wypeł­nio­ne ankiety. 

Biznesowy cel projektu

Zalecanym począt­kiem ana­li­zy jest okre­śle­nie biz­ne­so­we­go celu pro­jek­tu na tle misji i wizji orga­ni­za­cji (patrz: Audyt spój­no­ści wizji i misji orga­ni­za­cji z jej dzia­ła­nia­mi):

  • misja: (jak sobie wyobra­ża­my nasz przy­szły rynek), 
  • wizja: (nasz wkład w osią­gnię­cie powyż­sze­go sta­nu rzeczy),
  • cel biz­ne­so­wy orga­ni­za­cji: (pla­no­wa­na pozy­cja na ryn­ku, fuzja, inne), 
  • klu­czo­wy pro­blem: (co jest głów­nym powo­dem ini­cja­cji projektu).
Przykładowa gra­ficz­na for­ma wyra­że­nia biz­ne­so­wych celów projektu.
Materiał źró­dło­wy:Dokumenty sta­tu­to­we orga­ni­za­cji, udo­ku­men­to­wa­ne opi­sy stra­te­gii ryn­ko­wej i pokrew­ne powią­za­ne doku­men­ty (jeśli istnieją).

Struktura organizacyjna

Podstawą zro­zu­mie­nia dzia­ła­nia orga­ni­za­cji jest jej struk­tu­ra orga­ni­za­cyj­na. Jest ona tak­że słow­ni­kiem ról i kom­pe­ten­cji na mode­lach pro­ce­sów biz­ne­so­wych. Dokumentowana jest poniż­szą metodą:

Struktura orga­ni­za­cyj­na jako hie­rar­chia komó­rek organizacyjnych

Powyższy sche­mat to sfor­ma­li­zo­wa­na struk­tu­ra orga­ni­za­cyj­na zobra­zo­wa­na jako drze­wo zależ­no­ści prze­ło­żo­ny-pod­wład­ny” (lub komór­ka nad­rzęd­na pod­rzęd­na). «Unit» ozna­cza komór­kę lub rolę (odpo­wie­dzial­ność).

Materiał źró­dło­wy:Udokumentowana struk­tu­ra orga­ni­za­cyj­na w dowol­nej formie

Przepływ pracy i dokumentów czyli procesy biznesowe

Definicja pro­ce­su biz­ne­so­we­go brzmi: 

zde­fi­nio­wa­ny zestaw dzia­łań biz­ne­so­wych, któ­re repre­zen­tu­ją kro­ki wyma­ga­ne do osią­gnię­cia celu biz­ne­so­we­go, obej­mu­je prze­pływ i wyko­rzy­sta­nie infor­ma­cji oraz zasobów.

Notacja BPMN, Glossary 

Dlatego model pro­ce­sów to dia­gram obra­zu­ją­cy łań­cuch aktyw­no­ści i ich celów (doku­men­ty jako infor­ma­cje). Zasoby są repre­zen­to­wa­ne przez role wyko­naw­ców. Detale każ­dej aktyw­no­ści, jeże­li są wyma­ga­ne, doku­men­to­wa­ne są osob­no jako komen­ta­rze i ich pro­ce­du­ry (patrz opis: Proces a pro­ce­du­ra)

Analityczny model pro­ce­su biz­ne­so­we­go wyko­na­ny w nota­cji BPMN. (zapo­znaj się z peł­ną legen­dą sym­bo­li nota­cji BPMN)

Na powyż­szym sche­ma­cie poka­za­no pro­ces biz­ne­so­wy: aktyw­no­ści oraz ich dane wej­ścio­we i wyj­ścio­we. Wszelkie dodat­ko­we deta­le nio­są doku­men­ty (sym­bo­le z zagię­ty­mi roga­mi na dia­gra­mie powy­żej), regu­ły biz­ne­so­we (spi­sy­wa­ne w posta­ci zesta­wie­nia w tre­ści opra­co­wa­nia lub na sche­ma­tach np. powy­żej: Budżetowanie. BR002).

Model pro­ce­sów biz­ne­so­wych zawie­ra nazwy doku­men­tów. Ich struk­tu­ry nio­są deta­licz­ne infor­ma­cje o prze­twa­rza­nych danych i związ­kach mię­dzy nimi, są dodat­ko­wo doku­men­to­wa­ne jako sza­blo­ny, np. jak ten poniżej:

Diagram: DOC Karta Wypożyczenia Każdy formularz ekranowy i wydruk muszą być udokumentowane w sposób pozwalający na zapewnienie spełnienia wszystkich wymagań biznesowych zamawiającego. Wszystkie atrybuty dokumentów muszą być zdefiniowane w Biznesowy słownik pojęć [SBVR] a logika biznesowa w Reguły Biznesowe [SBVR]. Struktura poszczególnych atrybutów jest definiowana jak typy strukturalne (patrz: Biblioteka DTO i typy).
Struktura doku­men­tów i for­mu­la­rzy (patrz tak­że opis: Makieta doku­men­tu, i dłuż­sze opra­co­wa­nie: Struktury for­mu­la­rzy jako for­ma wyra­ża­nia wyma­gań)

Struktury te uzu­peł­nia­my regu­ła­mi ich popraw­no­ści (regu­ły biz­ne­so­we), defi­ni­cje pól i obsza­rów to ele­ment biz­ne­so­we­go słow­ni­ka pojęć (zawie­ra mię­dzy inny­mi nazwy wszyst­kich klu­czo­wych ele­men­tów na dia­gra­mach opi­su­ja­cych doku­men­ty i formularze). 

Materiał źró­dło­wy:Treść regu­la­mi­nów, roz­po­rzą­dzeń, pro­ce­dur, instruk­cji sta­no­wi­sko­wych, wzo­ry i przy­kła­dy wytwa­rza­nych doku­men­tów i for­mu­la­rzy wraz z opi­sem reguł ich poprawności.

Biznesowy słownik pojęć – ontologia

Podstawą zro­zu­mia­ło­ści i jed­no­znacz­no­ści doku­men­ta­cji jest jed­no­li­ty, spój­ny i kom­plet­ny słow­nik pojęć dla całe­go pro­jek­tu (gene­ral­nie doty­czy całej orga­ni­za­cji). Celem jest zapew­nie­nie jed­no­znacz­no­ści tre­ści nie tyl­ko doku­men­ta­cji pro­jek­to­wej ale też wszyst­kich ele­men­tów na mode­lach pro­ce­sów, doku­men­tach (for­mu­la­rzach) i ekra­nach sys­te­mu jakim jest opro­gra­mo­wa­nie. Co do zasa­dy słow­nik ma postać alfa­be­tycz­nej listy, jed­nak klu­czo­we poję­cia dzie­dzi­no­we, dodat­ko­wo wery­fi­ku­je­my z pomo­cą tak zwa­ne­go mode­lu poję­cio­we­go (dia­gram klas UML, lub model fak­tów SBVR, ). Jest to sche­mat blo­ko­wy, na któ­rym umiesz­cza­my wybra­ne poję­cia i łączy­my je związ­kiem gene­ra­li­za­cji lub okre­ślo­nym fak­tem (pre­dy­kat). W ten spo­sób spraw­dza­my, czy poję­cia te two­rzą para­mi popraw­ne i praw­dzi­we zda­nia w języ­ku natu­ral­nym danej dzie­dzi­ny wie­dzy. Np. poniżej:

Ontologia (seman­ty­ka i syn­tak­ty­ka klu­czo­wych pojęć), przy­kład dla sys­te­mu zarzą­dza­ją­ce­go doku­men­ta­mi (Diagram fak­tów nota­cja SBVR, lub Diagram klas UML)

Powyższe czy­ta­my:

  • kopia doku­men­tu i ory­gi­nał doku­men­tu to rodzaj (typ) dokumentu
  • fak­tu­ra jest typem dokumentu
  • sys­tem kan­ce­la­ryj­ny zapew­nia popraw­ny obieg dokumentów
  • doku­ment jest przy­po­rząd­ko­wa­ny do sprawy

UWAGA! Ten dia­gram to nie jest pro­ces biz­ne­so­wy! To model poję­cio­wy sto­so­wa­ny do mode­lo­wa­nia i wery­fi­ka­cji słow­nic­twa dzie­dzi­no­we­go, podob­ny jak te budo­wa­ne w sys­te­mach sztucz­nej inteligencji.

Materiał źró­dło­wy:Wykorzystywane są te same mate­ria­ły, któ­re słu­ża do ana­ly­zy i mode­lo­wa­nie celów i pro­ce­sów biznesowych.

Wymagania na oprogramowanie

Wymaganiem na opro­gra­mo­wa­nie jest treść opi­su jego dzia­ła­nia: Opis Techniczny Oprogramowania (patrz: pro­ces ICONIX). Poniżej jego klu­czo­we opi­sa­no ele­men­ty. Jednak gorą­co odra­dzam tu samo­dziel­ne spi­sy­wa­nie co i jak sys­tem ma coś robić” albo, co gor­sza, samo­dziel­ne two­rze­nie nie­sfor­ma­li­zo­wa­nych sche­ma­tów blo­ko­wych i opi­sów pro­ce­sów czy sys­te­mów IT, gdyż przy­no­si to wię­cej szko­dy niż pożyt­ku: samo­dziel­ne opra­co­wy­wa­nie tych sche­ma­tów pro­sty­mi pro­gra­ma­mi biu­ro­wy­mi, przez nie­przy­go­to­wa­ne do tego i nie­do­świad­czo­ne oso­by, jest pra­co­chłon­ne a uzy­ska­ne efek­ty i tak zawsze wyma­ga­ją ana­li­zy i for­ma­li­za­cji przez ana­li­ty­ka .

Usługi systemu czyli Co system ma robić

Każde opro­gra­mo­wa­nie (apli­ka­cja) moż­na opi­sać skoń­czo­ną listą usług jakie to opro­gra­mo­wa­nie świad­czy ele­men­tom swo­je­go oto­cze­nia (użyt­kow­nik i inne apli­ka­cje). Jeżeli to opro­gra­mo­wa­nie jest dopie­ro pla­no­wa­ne do zaku­pu, to lista taka jest zbio­rem wyma­gań wobec tego nowe­go opro­gra­mo­wa­nia. Na tym eta­pie nie ma zna­cze­nia to czy będzie to opro­gra­mo­wa­nie stan­dar­do­we czy dedykowane.

Do zbu­do­wa­nia takiej listy moż­na użyć burzy mózgów, jed­nak z powo­dów opi­sa­nych na począt­ku, znacz­nie efek­tyw­niej­szą meto­dą jest ana­li­za biz­ne­so­wa i wska­za­nie na mode­lach pro­ce­sów aktyw­no­ści, któ­re chce­my wes­przeć opro­gra­mo­wa­niem (trans­for­ma­cja mode­lu pro­ce­sów na model wyma­ga­nych usług apli­ka­cji). W efek­cie powsta­je pro­sty dia­gram (dia­gram przy­pad­ków uży­cia UML), sta­no­wią­cy zobra­zo­wa­nie usług apli­ka­cji jakich ocze­ku­je­my od nowe­go oprogramowania:

Usługi Aplikacji wyra­żo­ne jako Diagram Przypadków Użycia (nota­cja UML) jako kon­tekst i zakres wdrożenia.
Materiał źró­dło­wy:Model pro­ce­sów biz­ne­so­wych oraz wypra­co­wa­na decy­zja o obsza­rze i zakre­sie wdrożenia. 

Potrzeby Zamawiającego czyli wymagania biznesowe

Kolejny etap to zebra­nie listy potrzeb przy­szłych użyt­kow­ni­ków. Są to wyra­żo­ne języ­kiem biz­ne­so­wym (natu­ral­nym) ocze­ki­wa­nia wobec tych usług.

Kluczowe poję­cie na tym eta­pie to

potrze­ba: funk­cja, któ­rej bra­ku­je (jest ocze­ki­wa­na) do osią­gnię­cia celu lub wyko­na­nia działania

Wymagania biz­ne­so­we (tak­że capa­bi­li­ty requ­ire­ment) to zesta­wie­nie potrzeb wyra­żo­nych jako «potrze­by inte­re­sa­riu­szy». Sa one przy­pi­sy­wa­ne do usług apli­ka­cji (przy­pad­ki uży­cia, poprzed­ni roz­dział). Zestawienie to nale­ży dostar­czyć w posta­ci zestawienia:

Materiał źró­dło­wy:Potrzeby użyt­kow­ni­ków spi­sa­ne w punk­tach, każ­dy punkt w posta­ci:
- potrzeba/cel (wysta­wia­nie fak­tur)
- jej uza­sad­nie­nie (doku­men­to­wa­nie sprze­da­ży)
- zało­że­nia (auto­ma­tycz­ne pod­po­wia­da­nie danych z zamó­wie­nia)
- waga (1‑niezbędny, 2‑oczekiwany, 3‑pomocny)
- wła­ści­ciel (oso­ba zgłaszająca).

Mechanizm działania systemu

Każda usłu­ga apli­ka­cji cechu­je się okre­ślo­nym mecha­ni­zmem jej reali­za­cji. Standardowo przy­pi­su­je się jej okre­ślo­ny doku­ment z mode­lu pro­ce­sów a ona sama sta­no­wi osob­ny kom­po­nent systemu. 

Stany i statusy dokumentów

Na eta­pie doku­men­to­wa­nia usług apli­ka­cji mogą sie poja­wić inne, uzu­peł­nia­ją­ce sche­ma­ty blokowe: 

Wymagane sce­na­riu­sze i pro­ce­du­ry reali­zo­wa­ne przez opro­gra­mo­wa­nie, doku­men­to­wa­ne są jako prze­pływ danych, (zapo­znaj się z legen­dą sym­bo­li dla algo­ryt­mów i sce­na­riu­szy pro­ce­dur)

Poszczególne dokumenty/formularze mogą mieć sta­ny i sta­tu­sy. Modelowane są one jak poniżej:

Dokumentowanie sta­tu­sów dokumentów
Materiał źró­dło­wy:Model pro­ce­sów biznesowych

Architektura systemu

Na eta­pie opi­su wyma­gań nie wia­do­mo, któ­re usług apli­ka­cji zre­ali­zu­je wybra­ne opro­gra­mo­wa­nie (np. ERP). Aplikacje dedy­ko­wa­ne wyma­ga­ją opi­sa­nia archi­tek­tu­ry HLD i LLD. Z uwa­gi na spe­cy­fi­kę każ­dej orga­ni­za­cji wyma­ga­ne jest tak­że zapro­jek­to­wa­nie inte­gra­cji sys­te­mów. Jednak adre­sa­tem tych doku­men­tów są inży­nie­ro­wie dostaw­ców, nie są one recen­zo­wa­ne przez Zamawiającego. 

Materiał źró­dło­wy:Uzgodniony model przy­pad­ków uży­cia, lista potrzeb i mode­le pro­ce­sów biznesowych.

Spotkania

W ramach reali­zo­wa­nej usłu­gi odby­wa­ją się spo­tka­nia sta­tu­so­we (usta­le­nia pla­no­wa­nych dzia­łań w pro­jek­cie). Wszelkie dodat­ko­we warsz­ta­ty ini­cjo­wa­ne przez Zamawiającego sta­no­wią dodat­ko­we płat­ne spotkania. 

Spotkania są reali­zo­wa­ne jako video- i tele- kon­fe­ren­cje. Standardowo wysy­łam link do spo­tka­nia on-line. Jeżeli macie Państwo w swo­jej fir­mie wdro­żo­ny swój wła­sny sys­tem wide­okon­fe­ren­cyj­ny, może być on uży­wa­ny w pro­jek­cie. Jedynym ogra­ni­cze­niem jest brak koniecz­no­ści insta­lo­wa­nia dedy­ko­wa­ne­go opro­gra­mo­wa­nia na moim komputerze. 

Etap realizacji po wyborze dostawcy

Po wybo­rze Wykonawcy, na pod­sta­wie doku­men­tu Analiza Biznesowa i Opis Techniczny Systemu (Analiza), Wykonawca opra­co­wu­je doku­ment Koncepcja Wdrożenia, któ­ry zawie­ra opis spo­so­bu speł­nie­nia wyma­gań opi­sa­nych w Analizie (pier­wot­nie sta­no­wi ona załącz­nik do Zapytania Ofertowego). Dotyczy to każ­de­go Wykonawcy z osob­na: mode­le inte­gra­cji są w Analizie. 

Formalna pętla zarzą­dza­nia doku­men­ta­cja w projekcie

Wszelkie wąt­pli­wo­ści doty­czą­ce tre­ści Analizy (bra­ku­ją­ce deta­le, nie­jed­no­znacz­no­ści itp.) Wykonawca wyja­śnia zada­jąc pyta­nia do tre­ści Analizy (pyta­nia prze­ka­zu­je auto­ro­wi Analizy lub Zamawiającemu). Po wypra­co­wa­niu odpo­wie­dzi po stro­nie Zamawiającego Analiza jest aktu­ali­zo­wa­na i prze­ka­zy­wa­na wyko­naw­cy jako odpo­wiedź na zada­ne pyta­nia. Co do zasa­dy Analiza jest jedy­nym doku­men­tem źró­dło­wym dla Wykonawcy. 

Koncepcja Wdrożenia, sta­no­wi szcze­gó­ło­wy opis tego co wyko­na i dostar­czy Wykonawca. W toku reali­za­cji jeże­li Wykonawca pyta o kolej­ne potrzeb­ne mu deta­le, w odpo­wie­dzi dosta­je uszcze­gó­ło­wio­ną Analizę. Na tej pod­sta­wie aktu­ali­zu­je Koncepcję Wdrożenia o kolej­ne deta­le reali­zo­wa­nej imple­men­ta­cji (wdro­że­nia). W takim cyklu postę­pu­ją kolej­ne pra­ce wdrożeniowe.

W ten spo­sób, w dniu zakoń­cze­nia pro­jek­tu doku­ment Analiza sta­no­wi doku­ment opi­su­ją­cy fir­mę Zamawiającego na dzień zakoń­cze­nia wdro­że­nia, a doku­ment Koncepcja Wdrożenia sta­no­wi doku­men­ta­cję powy­ko­naw­czą dostar­czo­ne­go roz­wią­za­nia . W całym pro­jek­cie Analiza i Koncepcja Wdrożenia, to jedy­ne for­mal­ne doku­men­ty pro­jek­to­we. Pisemne wnio­ski o ich uzu­peł­nie­nie sta­no­wią wyłącz­nie histo­rię przy­czyn zmian, załączniki. 

W całym pro­jek­cie pod­sta­wo­wym narzę­dziem komu­ni­ka­cji jest sys­tem Postmania. Inne narzę­dzia wyma­ga­ją uzgod­nie­nia, jed­nak sam pro­ces nie ule­ga zmia­nie: jedy­nym źró­dłem infor­ma­cji dla Wykonawcy jest ana­li­za, wszel­kie inne robo­cze doku­men­ty (notat­ki ze spo­tkań i roz­mów) sta­no­wią mate­riał źró­dło­wy do aktu­ali­za­cji Analizy. 

Formalne doku­men­to­we kana­ły komu­ni­ka­cyj­ne w pro­jek­cie: linie cią­głe to for­mal­ny prze­pływ infor­ma­cji. Inne kana­ły komu­ni­ka­cji (roz­mo­wy, ema­ile, itp.) sta­no­wią nie­for­mal­ną for­mę wyja­śnień jed­nak nie są wią­żą­ce. Linia prze­ry­wa­na poka­zu­je udo­stęp­nio­ne narzę­dzie komu­ni­ka­cji (Postmania).

Źródła

Object Management Group. (2017, December). Unified Modeling Language (UML) [OMG​.org]. UML. https://​www​.omg​.org/​s​p​e​c​/​U​ML/
Object Management Group. (2014, January). Business Process Model and Notation (BPMN). OMG​.Org. https://​www​.omg​.org/​s​p​e​c​/​B​P​MN/
Object Management Group. (2019). Semantics of Business Vocabulary and Business Rules (SBVR). OMG​.Org. https://​www​.omg​.org/​s​p​e​c​/​S​B​VR/
Šenkýř, D., & Kroha, P. (2019). Problem of Incompleteness in Textual Requirements Specification: Proceedings of the 14th International Conference on Software Technologies, 323 – 330. https://​doi​.org/​1​0​.​5​2​2​0​/​0​0​0​7​9​7​8​0​0​3​2​3​0​330
Street, K. (2006). Building a Service Oriented Architecture with BPM and MDA. 2(1), 8.