Wprowadzenie

Oprogramowanie Generator Ofert zosta­ło zapro­jek­to­wa­ne prze­ze mnie dla Biura Polonijnego Kancelarii Senatu. Zadanie jakie dosta­łem to opra­co­wa­nie wyma­gań (Opis Przedmiotu Zamówienia) na apli­ka­cję, która:

• pozwa­la skła­dać wnio­ski na dofi­nan­so­wa­nie pro­jek­tów Polonii z całe­go świata,
• skła­dać wnio­ski sta­no­wią­ce for­mu­la­rze o bar­dzo roz­bu­do­wa­nej i zmien­nej w cza­sie struk­tu­rze, prze­cho­wy­wać ich kolej­ne wersje,
• pro­wa­dzić pro­ces oce­ny wnio­sków przez eks­per­tów Bura Polonii Kancelarii Senatu,
• two­rzyć i zawie­rać umo­wy, w któ­rych te wnio­ski są załącznikiem, 
• śle­dzić roz­li­cza­nie tych umów.
• pro­wa­dzi archi­wum tych dokumentów,

Analizę i pro­jekt zre­ali­zo­wa­łem zdal­nie sam, w cią­gu mie­sią­ca (komu­ni­ka­cja). W toku prze­tar­gu nie było żad­nych skarg na treść OPZ do KIO. Implementacja wyko­na­na w cią­gu pię­ciu mie­się­cy w pla­no­wa­nym budże­cie i ter­mi­nie, pod moim nad­zo­rem (nad­zór autorski). 

Całość jest na AZURE. Aplikacja dzia­ła do dziś w dobrej kon­dy­cji, jest rela­tyw­nie tania w utrzy­ma­niu mimo corocz­nych zmian prze­pi­sów (w tym for­mu­la­rzy). Poprzednie wyce­ny (nie­któ­re na bazie metod opar­tych o punk­ty funk­cyj­ne, inne na bazie wie­lo­dnio­wych warsz­ta­tów z pra­cow­ni­ka­mi Kancelarii Senatu czy te na bazie setek stron mode­li UML baz danych i nie­zro­zu­mia­łych dia­gra­mów UC), dawa­ły wie­lo­krot­nie (bywa­ły ponad 10 krot­nie) wyż­sze pro­gno­zy kosztów. 

Dokument sta­no­wią­cy Opis Przedmiotu Zamówienia (pro­jekt tech­nicz­ny) jest dostęp­ny na stro­nie BIP Kancelarii pod adre­sem: https://​www​.senat​.gov​.pl/​g​f​x​/​s​e​n​a​t​/​u​s​e​r​f​i​l​e​s​/​_​p​u​b​l​i​c​/​k​8​/​k​a​n​c​e​l​a​r​i​a​/​z​a​m​/​2​0​1​7​/​1​5​/​z​a​l​a​c​z​n​i​k​_​n​r​_​1​_​d​o​_​s​i​w​z​.​pdf dla­te­go czę­sto słu­ży mi za przy­kła­do­wą referencję. 

Kilka wyjaśnień

Z uwa­gi na to, że mie­wam pyta­nia o kon­struk­cję nie­któ­rych sche­ma­tów blo­ko­wych w tym doku­men­cie, omó­wię je tu pokrótce. 

Między inny­mi cał­ko­wi­cie zre­zy­gno­wa­łem z SQL i rela­cyj­ne­go mode­lu danych dla for­mu­la­rzy, dzię­ki cze­mu wie­lo­krot­nie spa­dła pra­co­chłon­ność wytwo­rze­nia oraz póź­niej­sze kosz­ty utrzy­ma­nia i roz­wo­ju (mię­dzy inny­mi co roku nie­co zmie­nio­ne formularze). 

W takich pro­jek­tach bar­dzo waż­ny jest nad­zór autor­ski, czy­li tu mój udział w pro­jek­cie w toku implementacji: 

1. nad­zo­ru­ję pra­cę dewelopera,
2. na bie­żą­co wyja­śniam wąt­pli­wo­ści deve­lo­pe­ra co do dokumentacji,
3. na bie­żą­co uzu­peł­niam doku­ment o nowe ele­men­ty (czas się nie zatrzy­mu­je w dniu ogło­sze­nia prze­tar­gu i pod­pi­sa­niu umo­wy z wykonawcą),
4. na bie­żą­co aktu­ali­zu­ję doku­men­ta­cję o wszel­kie pod­ję­te decy­zje architektoniczne,
5. w dniu odda­nia apli­ka­cji do użyt­ku, sta­le aktu­ali­zo­wa­ny OPZ, sta­no­wi aktu­al­ną doku­men­ta­cję powsta­łe­go sys­te­mu, tu na koniec nad­zo­ru, miał nie­co ponad 80 stron. 

(Dokument OPZ został w cało­ści wyko­na­ny z uży­ciem opro­gra­mo­wa­nia Visual-Paradigm: wbu­do­wa­ne­go edy­to­ra DocComposer pakie­tu Visual-Paradigm. Cały cykl pra­cy nad wyma­ga­nia­mi i ich doku­men­to­wa­niem nie wyma­ga uży­cia żad­nych narzę­dzi biu­ro­wych typu Office.)

Zakres projektu

Na tym dia­gra­mie kolo­ra­mi poka­za­no zakres odpo­wie­dzial­no­ści Zamawiającego i Wykonawcy. Kolor nie­bie­ski ozna­cza pro­duk­ty, któ­re ma dostar­czyć Wykonawca. Jest to dia­gram przy­pad­ków uży­cia nota­cji UML, na wcze­snym eta­pie zwa­ny Modelem kon­tek­stu (zakre­su) pro­jek­tu. Zależności (uza­leż­nie­nia) zosta­ły zamo­de­lo­wa­ne stan­dar­do­wym związ­kiem zależ­no­ści w UML. UWAGA! Notacja UML nie zabra­nia umiesz­cza­nia na tym dia­gra­mie innych sym­bo­li niż aktor, sys­tem i przy­pa­dek uży­cia, moż­na to robić pod warun­kiem zacho­wa­nia popraw­no­ści seman­ty­ki i syn­tak­ty­ki uży­wa­nych symboli.

Cele biznesowe

Powyższy dia­gram to model moty­wa­cji biz­ne­so­wej (BMM). Jest to bar­dzo waż­ny dia­gram w pro­jek­cie: słu­ży do okre­śle­nia celu biz­ne­so­we­go. Jest uży­wa­ny do selek­cji zgła­sza­nych wyma­gań biz­ne­so­wych. Do zakre­su pro­jek­tu powin­ny być kwa­li­fi­ko­wa­ne wyłącz­nie wyma­ga­nia wspie­ra­ją­ce cele biz­ne­so­we pro­jek­tu. Pozwala to sku­tecz­nie zarzą­dzać zakre­sem pro­jek­tu i nie popaść w zja­wi­sko zwa­ne ​„utra­ta pano­wa­nia na zakre­sem pro­jek­tu” (szyb­ko rosną­ca nie­kon­tro­lo­wa­na licz­ba wymagań).

Słownik i model pojęciowy

Co do zasa­dy pro­jekt powi­nien mieć Biznesowy słow­nik pojęć. Jest to lista pojęć wraz z ich defi­ni­cja­mi, któ­rej celem jest zagwa­ran­to­wa­nie jed­no­znacz­no­ści tre­ści całej doku­men­ta­cji. Są to poję­cia dzie­dzi­no­we a słow­nik ten sta­no­wi prze­strzeń poję­cio­wą dla innych dia­gra­mów. Diagram ten stan­dar­do­wo wyko­nu­ję jako Model Faktów nota­cji SBVR, ale jest to tak napraw­dę dia­gram klas skła­da­ją­cy się wyłącz­nie z klas (nazw), związ­ków gene­ra­li­za­cji i skie­ro­wa­nych aso­cja­cji. Celem jego budo­wy jest zagwa­ran­to­wa­nie spój­no­ści i nie­sprzecz­no­ści pojęć w słow­ni­ku. Cechą tego dia­gra­mu (meto­dą kon­tro­li jego popraw­no­ści) jest to, że każ­de dwa połą­czo­ne poję­cia two­rzą (muszą) popraw­ne zda­nie w języ­ku natu­ral­nym np. ​„metry­ka zawie­ra fak­ty z histo­rii spra­wy” czy ​„umo­wa jest szcze­gól­nym typem pisma”. Nazwy klas, atry­bu­tów, ope­ra­cji, akto­rów itp. na mode­lach archi­tek­tu­ry muszą pocho­dzić z tej prze­strze­ni pojęciowej!

Poglądowa mapa procesów biznesowych

Bardzo przy­dat­nym dia­gra­mem jest nie­for­mal­ny sche­mat blo­ko­wy obra­zu­ją­cy pro­ce­sy biz­ne­so­we ope­ra­cyj­ne. Każdy ​„pago­nik” to abs­trak­cja pro­ce­su, któ­re­go deta­le poka­za­ne zosta­ną na pod­rzęd­nych dia­gra­mach w nota­cji BPMN. Można taki dia­gram tak­że wyko­nać w nota­cji BPMN, jed­nak jego adre­sa­tem są spon­so­rzy pro­jek­tu, któ­rzy rzad­ko mają łatwość posłu­gi­wa­nia sie nota­cją BPMN. 

Podmioty w otoczeniu Kancelarii

Diagram współ­pra­cy nota­cji BPMN jest two­rzo­ny w celu inwen­ta­ry­za­cji pod­mio­tów zaan­ga­żo­wa­nych w pro­ce­sach obsłu­gi wnio­sków. Nazwy tych pod­mio­tów sta­no­wią poten­cjal­ne war­to­ści atry­bu­tów meta­da­nych doku­men­tów, będą tak­że uży­te jako pule na dia­gra­mach BPMN.

Zarządzanie przepływem dokumentów

Diagram BPMN, na któ­rym poka­za­no czyn­no­ści zwią­za­ne z pra­cą z doku­men­ta­mi. W takich przy­pad­kach, gdzie ludzie wyko­nu­ją czyn­no­ści sami dobie­ra­jąc ich kolej­ność wg. usta­lo­nych reguł (np. w instruk­cjach) nie ma sen­su mode­lo­wa­nie wszel­kich warian­tów z uży­ciem wiel­kiej ilo­ści bra­mek i moż­li­wych prze­pły­wów (spe­cy­fi­ka­cja BPMN 2.0.2, Figury 10.35, 10.36, 10.37).

Jeżeli prze­pływ pra­cy jest bar­dziej deter­mi­ni­stycz­ny powsta­ją dia­gra­my jak poniżej.

Przypadki użycia czyli usługi aplikacyjne

Diagram przy­pad­ków uży­cia ma poka­zać usłu­gi apli­ka­cyj­ne i inte­re­sa­riu­szy sys­te­mu (ludzi) oraz ewen­tu­al­nych akto­rów będą­cych inny­mi apli­ka­cja­mi (inte­gra­cje).

Tu wyjąt­ko­wo uży­łem dość rzad­kiej kon­struk­cji jaką jest gene­ra­li­za­cja (a nie dzie­dzi­cze­nie! któ­re­go nie ma w UML od 2015 roku, od wer­sji 2.5), poka­zu­ją­ca że zarów­no recen­zen­ci jaki refe­ren­ci to pra­cow­ni­cy Kancelarii. To uogól­nie­nie to słow­ni­ko­wy zabieg mają­cy na celu uprosz­cze­nie dia­gra­mu (jeden zwią­zek zależ­no­ści do gene­ra­li­za­cji zamiast dwóch do jej instan­cji). Jest to zabieg słow­ni­ko­wy, ana­lo­gicz­ny to tego, w któ­rym mówi­my ​„wete­ry­narz leczy zwie­rzę­ta” zamiast mówić ​„wete­ry­narz leczy psy, koty, świn­ki mor­skie” (sło­wo zwie­rzę­ta jest słow­ni­ko­wą gene­ra­li­za­cją kon­kret­nych zwie­rząt). Tej rzad­ko uży­wa­nej kon­struk­cji uży­łem tyl­ko z powo­du pre­sji cza­su i odra­dzam ją. Lepszą kon­struk­cją była by tu struk­tu­ral­na meta­kla­sa zamiast uogól­nie­nia i związ­ki «instanceOf» zamiast poję­cio­wej gene­ra­li­za­cji, a jesz­cze pro­ściej: poka­zać te zależ­no­ści wyłącz­nie na mode­lu pojęciowym. 

Model dziedziny

Został wyko­na­ny z uży­ciem stan­dar­do­we­go wzor­ca BCE, nie raz już opi­sy­wa­ne­go na tym blo­gu, po pra­wej stro­nie, poka­za­no wybra­ne deta­le struk­tu­ry repo­zy­to­riów jako realizacje.

Powyższe to wybra­ne klu­czo­we ele­men­ty projektu.

Podsumowanie

Pozostałe ele­men­ty OPZ dla Kancelarii Senatu wyda­ją mi się dość oczy­wi­ste, tu sta­ra­łem się sko­men­to­wać te ele­men­ty tego doku­men­tu, któ­re budzą naj­wię­cej pytań i emo­cji. Są to bar­dzo przy­dat­ne i nie­do­ce­nia­ne kon­struk­cje zarów­no w nota­cji UML jak i BPMN. Kompletny doku­ment moż­na tak­że pobrać tu:

Zainteresowanych podob­nym i upu­blicz­nio­nym pro­jek­tem zapra­szam tu: Inżynieria opro­gra­mo­wa­nia z uży­ciem narzę­dzia CASE – pro­jekt badawczy.