• Produkt: Opis Przedmiotu Zamówienia (opra­co­wa­nie spe­cy­fi­ka­cji SWS) zawie­ra­ją­cy zarów­no udo­ku­men­to­wa­ny Model Biznesowy Organizacji jak i Projekt Techniczny Rozwiązania, reali­zo­wa­ny jest tak­że nad­zór autor­ski nad realizacją.
  • Korzyści: ochro­na know-how Zamawiającego, kom­plet­ne i spój­ne wyma­ga­nia wyra­żo­ne jako pro­jekt tech­nicz­ny, obiek­ty­wi­za­cja prac wykonawcy.

Wymagania

Wymagania mają dwa wymiary: 

  • biz­ne­so­we wyma­ga­nia wobec roz­wią­za­nia (któ­re tu jest czar­ną skrzynką) 
  • tech­nicz­ne wobec roz­wią­za­nia (któ­re tu są mode­lem mecha­ni­zmu dzia­ła­nia roz­wią­za­nia, czę­sto zwa­ne bia­łą skrzynką)

Norma IEEE tak defi­niu­je wymaganie:

1. waru­nek lub zdol­ność potrzeb­na użyt­kow­ni­ko­wi do roz­wią­za­nia pro­ble­mu lub osią­gnię­cia celu
2. waru­nek lub zdol­ność, któ­re muszą być speł­nio­ne lub posia­da­ne przez sys­tem lub kom­po­nent sys­te­mu w celu speł­nie­nia wymo­gów umo­wy, stan­dar­du, spe­cy­fi­ka­cji lub inne­go for­mal­nie narzu­co­ne­go doku­men­tu
3. udo­ku­men­to­wa­na repre­zen­ta­cja warun­ku lub moż­li­wo­ści jak w (1) lub (2)

(źr.: nor­ma IEEE1998)

Pierwsze to wyma­ga­nia biz­ne­so­we, dru­gie to już pro­jekt roz­wią­za­nia. Czym jest udo­ku­men­to­wa­na repre­zen­ta­cja”? Tu mamy wybór: może to być opis w języ­ku natu­ral­nym i ochro­ni go pra­wo autor­skie, a może to być pro­jekt tech­nicz­ny wyra­żo­ny w usta­lo­nej stan­dar­do­wej for­mie. Jeżeli jest to for­ma algo­ryt­mów, wzo­rów mate­ma­tycz­nych, sfor­ma­li­zo­wa­nych sche­ma­tów blo­ko­wych, to nie tyl­ko chro­ni go pra­wo autor­skie, ale dodat­ko­wo tak­że pra­wo doty­czą­ce paten­tów i wzo­rów prze­my­sło­wych, taki doku­ment sta­je się tak­że wie­dzą chro­nio­ną jako know-how (patrz Ochrona war­to­ści inte­lek­tu­al­nych i know-how w orga­ni­za­cji).

Jednak same wyma­ga­nia to nie jedy­ny pro­dukt na eta­pie zbie­ra­nia wyma­gań”. Udokumentowana repre­zen­ta­cja zawie­ra (powin­na) opis logi­ki zbie­ra­nia i prze­twa­rza­nia infor­ma­cji, a dostaw­ca powi­nien dostać udo­ku­men­to­wa­na repre­zen­ta­cję tego co ma dostarczyć. 

Rolą dostaw­cy opro­gra­mo­wa­nia jest dostar­cze­nie i wdro­że­nie opro­gra­mo­wa­nia zgod­ne­go z przed­sta­wio­ny­mi mu wyma­ga­nia­mi i zapew­nie­nie jego jako­ści, a nie ana­li­za wyma­gań kupu­ją­ce­go na tle moż­li­wo­ści ofe­ro­wa­ne­go przez sie­bie pro­duk­tu. Dlatego wyma­ga­nia i logicz­ny pro­jekt roz­wią­za­nia powin­ny być opra­co­wa­ne przed wybo­rem jego dostaw­cy.

Dlatego koniecz­ny jest etap ana­li­zy i pro­jek­to­wa­nia, jego pro­duk­ty poka­za­no poniżej:

Dokumenty i zakres odpo­wie­dzial­no­ści w inżynierii.

Na eta­pie ana­li­zy i pro­jek­to­wa­nia (reali­zu­je to ana­li­tyk-pro­jek­tant sys­te­mów) orga­ni­za­cja dostar­cza doku­men­ty do ana­li­zy nio­są­cę wie­dze o niej. Dlaczego nie wywia­dy? Niestety, meto­dy bazu­ją­ce na zaufa­niu w moc wywia­dów z pra­cow­ni­ka­mi i burz mózgów, w wie­dzę” wie­lo­let­nie­go pra­cow­ni­ka i doświad­cze­nie dostaw­cy okre­ślo­ne­go opro­gra­mo­wa­nia, stwa­rza­ją pro­ble­my z wdra­ża­niem sys­te­mów ERP. Wiele nie­uda­nych pro­jek­tów koń­czy się sło­wa­mi: Problem pole­gał na tym, że dostar­czo­no nam dokład­nie to co chcie­li­śmy, a nie to co jest nam potrzeb­ne. „. Spisywanie wyma­gań w języ­ku natu­ral­nym to ogrom­ne ryzy­ko nie­spój­no­ści i niekompletności:

Niestety same spi­sa­ne funk­cjo­nal­no­ści pro­gra­mu czy­li spe­cy­fi­ka­cja (lista) wyma­gań funk­cjo­nal­nych to wyłącz­nie idea jego powsta­nia (wyrok SA w Poznaniu z dnia 4 stycz­nia 1995 r. I ACr 422/94). Precyzję opi­su, dają­cą ochro­nę w posta­ci peł­ne­go pra­wa do powsta­łe­go pro­duk­tu, uzy­sku­je się dopie­ro opra­co­wu­jąc pro­jekt jego kon­struk­cji, struk­tur danych i mecha­ni­zmu dzia­ła­nia, sto­su­jąc wzo­ry mate­ma­tycz­ne, algo­ryt­my, uni­kal­ne struk­tu­ry i sche­ma­ty blo­ko­we.

Dlatego popraw­nym pro­duk­tem ana­li­zy sys­te­mo­wej przed­się­bior­stwa jest pro­jekt archi­tek­tu­ry i logi­ki dzia­ła­nia roz­wią­za­nia a nie kon­kret­ne oprogramowanie!

Udokumentowanie pro­ble­mu, dostęp­nych roz­wią­zań i pla­nu dostar­cze­nia war­to­ści pozwa­la wszyst­kim osią­gnąć suk­ces. Przynajmniej w ten spo­sób sta­je się jasne, jaki pro­blem ty i twój zespół pró­bu­je­cie roz­wią­zać i jakie roz­wią­za­nia są dostęp­ne i któ­re z nich wybra­łeś, spra­wia, że jest jasne dla każ­de­go, kto to czy­ta (zespół, inte­re­sa­riu­sze, zarząd, klient), w jaki spo­sób zamie­rzasz dostar­czyć war­tość. Jeśli nie możesz tego zapi­sać i uzy­skać zgo­dy inte­re­sa­riu­szy, i tak musisz wyko­nać tę pra­cę: po pro­stu zanur­ku­jesz w kodo­wa­nie mając nadzie­ję, że wszyst­ko się uło­ży. Jednak nadzie­ja nie jest dobrą strategią.

Warsztaty

Czy orga­ni­za­cja (jej pra­cow­ni­cy) powin­na sama opi­sać swo­je potrze­by? Prawo Conway’a mówi, że orga­ni­za­cje same pro­jek­tu­ją sys­te­my, któ­re odzwier­cie­dla­ją ich wła­sną struk­tu­rę komu­ni­ka­cyj­ną. Nazwa pocho­dzi od pro­gra­mi­sty kom­pu­te­ro­we­go Melvina Conwaya, któ­ry wpro­wa­dził tę ideę w 1967 r.. Jego ory­gi­nal­ne sfor­mu­ło­wa­nie brzmiało:

Każda orga­ni­za­cja, któ­ra pro­jek­tu­je sys­tem (zde­fi­nio­wa­ny sze­ro­ko), wytwo­rzy pro­jekt, któ­re­go struk­tu­ra jest kopią struk­tu­ry komu­ni­ka­cyj­nej organizacji.

(źr.: http://​www​.mel​con​way​.com/​H​o​m​e​/​C​o​n​w​a​y​s​_​L​a​w​.​h​tml)

Innymi sło­wy:

orga­ni­za­cje w któ­rych wyma­ga­nia na sys­tem infor­ma­tycz­ny są spi­sy­wa­ne przez ich pra­cow­ni­ków i zara­zem przy­szłych użyt­kow­ni­ków tego sys­te­mu, dosta­ną sys­tem, któ­ry utrwa­la stan obec­ny, a nie zmie­nia go na lepsze. 

Metoda ta ma tak­że inne wade: opis taki jest bar­dzo czę­sto nie­jed­no­znacz­ny, dość ogól­ny i w żaden spo­sób nie chro­ni know-how i dorob­ku zamawiającego:

Niekompletność jest typo­wym pro­ble­mem, któ­ry poja­wia się, gdy inte­re­sa­riu­sze (np. eks­per­ci dome­ny) posia­da­ją pew­ne infor­ma­cje i uzna­ją je za ogól­nie zna­ne, i nie wspo­mi­na­ją o nich ana­li­ty­ko­wi. Model opar­ty na nie­kom­plet­nych wyma­ga­niach cier­pi z powo­du bra­ku­ją­cych obiek­tów, wła­ści­wo­ści lub relacji.

Dzieje się tak nie dla­te­go, że ludzie ci mają złą wolę, a dla­te­go że sto­so­wa­nie intu­icji w miej­scu gdzie nale­ży użyć twar­dych reguł i fak­tów, pra­wie zawsze pro­wa­dzi do błę­dów .

Tworzenie sys­te­mów zawie­ra­ją­cych opro­gra­mo­wa­nie obej­mu­je wie­le pozio­mów abs­trak­cji, pro­wa­dzą­cych od wyma­gań do kodu. Posiadanie abs­trak­cyj­nych kon­cep­cji poma­ga zde­fi­nio­wać kod i upew­nić się, że kom­po­nen­ty opro­gra­mo­wa­nia zacho­wu­ją się w ocze­ki­wa­ny spo­sób. Istnieje luka, któ­ra nie może być zamknię­ta przez zwy­kłe meto­dy pro­gra­mo­wa­nia, ale któ­ra może być zamknię­ta, jeśli pro­gra­mo­wa­nie jest wspie­ra­ne przez odpo­wied­nie ramy modelowania.

Dlatego zaan­ga­żo­wa­nie do tego celu ana­li­ty­ka-pro­jek­tan­ta z zewnątrz i sfor­ma­li­zo­wa­nie doku­men­ta­cji jest klu­czo­we, tak­że dla­te­go, że stan­dar­do­wo pro­wa­dzi on tak­że nad­zór autor­ski nad pra­ca­mi wykonawcy.

ZARZĄDZANIE PROJEKTEM WE WŁASNYM ZAKRESIE JEST KRYTYCZNE: Integratorzy sys­te­mów mogą być cen­nym ele­men­tem cyfro­wej trans­for­ma­cji, ale nigdy nie powin­ni mieć cał­ko­wi­tej, nie­kon­tro­lo­wa­nej wła­dzy nad całym przedsięwzięciem.

(źr. PORAŻKA CYFROWEJ TRANSFORMACJI W FIRMIE HERTZ, oryg. : 4 LESSONS FROM THE HERTZ VS. ACCENTURE DISASTER)

Systemy ERP

Skrót ERP to Planowanie Zasobów Przedsiębiorstwa (ang. ERP, Enterprise Resource Planning). Oznacza to zin­te­gro­wa­ne zarzą­dza­nie głów­ny­mi pro­ce­sa­mi biz­ne­so­wy­mi, czę­sto w cza­sie rze­czy­wi­stym i za pośred­nic­twem opro­gra­mo­wa­nia i tech­no­lo­gii. ERP jest zwy­kle okre­śla­ne jako kate­go­ria opro­gra­mo­wa­nia do zarzą­dza­nia przed­się­bior­stwem – zazwy­czaj pakiet zin­te­gro­wa­nych apli­ka­cji – któ­re orga­ni­za­cja może wyko­rzy­sty­wać do gro­ma­dze­nia, prze­cho­wy­wa­nia, zarzą­dza­nia i inter­pre­to­wa­nia danych z wie­lu dzia­łań biz­ne­so­wych. Integracja ta może odby­wać się poprzez współ­dzie­le­nie jed­nej bazy danych lub poprzez wymia­nę danych na pozio­mie logi­ki biznesowej. 

Wspólna współ­dzie­lo­na baza danych czy­ni taki sys­tem mono­li­tem nie­podat­nym na zmia­ny (a ich ewen­tu­al­ne wpro­wa­dza­nie – kasto­mi­za­cja sys­te­mu – jest bar­dzo kosz­tow­ne i ryzy­kow­ne). Dlatego, przy obec­nym pozio­mie tech­no­lo­gii, inte­gra­cja spe­cja­li­zo­wa­nych sys­te­mów jest znacz­nie efek­tyw­niej­sza i nie wyma­ga kosz­tow­nych kasto­mi­za­cji. Tradycyjne sys­te­my ERP budo­wa­ne na jed­nej cen­tral­nej bazie danych są obec­nie uwa­ża­ne za star­szą technologię.

Wielu dostaw­ców star­szych tech­no­lo­gii, inte­gru­ją­cych funk­cje z pomo­cą jed­nej wspól­nej bazy danych, pro­mu­je tezy takie jak ta:

W przy­pad­ku opro­gra­mo­wań zamknię­tych część funk­cji sys­te­mu jest sztyw­na, a fir­ma wdra­ża­ją­ca je w swo­je struk­tu­ry musi liczyć się ze zmia­ną wła­snych pro­ce­dur w taki spo­sób, by dopa­so­wać się do wymo­gów opro­gra­mo­wa­nia. […] Niestety, poraż­ka jest nie­unik­nio­na, jeśli fir­ma chce zarów­no wdro­że­nia nowe­go sys­te­mu, jak i pozo­sta­nia przy wcze­śniej­szym spo­so­bie funk­cjo­no­wa­nia. W przy­pad­ku sys­te­mu ERP takie zało­że­nie się wyklucza.”

Jest to kon­se­kwen­cja mono­li­tycz­nej, nie­podat­nej na zmia­ny, archi­tek­tu­ry. W bar­dzo wie­lu przy­pad­kach suge­stia, że nabyw­ca ma porzu­cić swój wypra­co­wa­ny lata­mi ope­ra­cyj­ny styl pra­cy, dla­te­go bar­dzo wie­le wdro­żeń mono­li­tycz­nych ERP koń­czy sie poraż­ką , bywa, że upór wdra­ża­ją­cych jest dro­gą do biz­ne­so­we­go samobójstwa.

Podstawowym celem wdro­żeń sys­te­mów ERP jest popra­wa funk­cjo­no­wa­nia orga­ni­za­cji, osią­ga­my ją poprzez stan­da­ry­za­cję i opty­ma­li­za­cję. Standaryzacja ma sens tam, gdzie stan­da­ry­za­cję narzu­ca pra­wo, dobre prak­ty­ki itp., naj­czę­ściej jest to obszar admi­ni­stra­cji. Optymalizację wpro­wa­dza­my wszę­dzie tam, gdzie to my decy­du­je­my o kształ­cie pro­ce­sów i procedur. 

Poniżej zna­ny od lat, tak zwa­ny model wewnętrz­ne­go łań­cu­cha war­to­ści Portera .

Obszar sza­ry to obszar stan­dar­do­wych pro­ce­sów i pro­ce­dur, w tej czę­ści prak­tycz­nie każ­da orga­ni­za­cja pra­cu­je tak samo, to obszar w zna­ko­mi­tej więk­szo­ści regu­lo­wa­ny pra­wem. Dlatego obszar sza­ry stan­da­ry­zu­je­my i tu ma sens ERP z pół­ki, a w zasa­dzie tyl­ko jego stan­dar­do­we modu­ły FK. 

Obszar ozna­czo­ny kolo­ra­mi to klu­czo­wy obszar two­rzą­cy ryn­ko­wą war­tość doda­ną i prze­wa­gę kon­ku­ren­cyj­ną: to tu sie­dzi” know-how orga­ni­za­cji. Ten obszar opty­ma­li­zu­je­my, i tu wiel­kie ERP” jako mono­li­ty na jed­nej bazie danych”, nie­ste­ty nie mają abso­lut­nie nic do zaofe­ro­wa­nia poza wyrów­na­niem w dół do resz­ty kon­ku­ren­tów”, a prak­tycz­nie każ­da pró­ba kasto­mi­za­cji ERP w tym obsza­rze koń­czy się kosz­tow­ną poraż­ką .

Dlatego naj­pierw nale­ży wyko­nać audyt pro­ce­sów biz­ne­so­wych i ziden­ty­fi­ko­wać w orga­ni­za­cji jej kolo­ro­wy obszar”. Należy bar­dzo dobrze prze­ana­li­zo­wać go od stro­ny infor­ma­cji jaki­mi tu zarzą­dza­my (opro­gra­mo­wa­nie nie zastę­pu­je ludzi ani maszyn, ono TYLKO zarzą­dza dany­mi na ich temat!), wynik ana­li­zy (w tym ewen­tu­al­ne stan­da­ry­za­cje i opty­ma­li­za­cje!) udo­ku­men­to­wać jako wyma­ga­nie, i teraz dopie­ro dobrać na ryn­ku pasu­ją­ce roz­wią­za­nia (nie raz dla każ­de­go dzie­dzi­no­we­go obsza­ru osob­no) i zin­te­gro­wać. I takie podej­ście daje wyni­ki nie raz nawet po roku i nie raz o rząd wiel­ko­ści mniej­szym kosztem.

Owszem bywa, że potrzeb­ne są dedy­ko­wa­ne roz­wią­za­nia… wte­dy są one imple­men­ta­cją logi­ki biz­ne­so­wej udo­ku­men­to­wa­nej w wyni­kach ana­li­zy biznesowej.

W dal­szej czę­ści opi­sa­łem po kolei jak to zrobić.

Idealizacja jako metoda

Idealizacja to meto­da opra­co­wa­nia wyma­gan na real­ne roz­wią­za­nie. Polega na opra­co­wa­niu rapor­tu z audy­tu orga­ni­za­cji, okre­śle­nia biz­ne­so­we­go celu pro­jek­tu i na tej pod­sta­wie, okre­śle­niu doce­lo­wej posta­ci (mecha­ni­zmu dzia­ła­nia) orga­ni­za­cji czy­li jej doce­lo­we­go mode­lu. Pośrednim eta­pem jest model ide­al­nej posta­ci doce­lo­wej oraz stu­dium wyko­nal­no­ści tego ide­ału . Produktem osta­tecz­nym jest kom­pro­mis poka­za­ny poniżej:

Idealizacja jako meto­da pla­no­wa­nia zakre­su pro­jek­tu (opra­co­wa­nie wła­sne na pod­sta­wie oraz Studium wyko­nal­no­ści)

Pierwszym eta­pem jest więc okre­śle­nie sta­nu ide­al­ne­go, dru­gim, oce­na moż­li­wo­ści jego osią­gnię­cia i pod­ję­cie decy­zji o osta­tecz­nym zakre­sie pro­jek­tu (to wyma­ga­nia na roz­wią­za­nie). Ideał jest czę­sto wyma­ga­niem, stan moż­li­wy to Koncepcja Wdrożenia opra­co­wa­na przez dostaw­cę (to on opra­co­wu­je stu­dium wyko­nal­no­ści wymagań).

Podstawowym narzę­dziem w toku prac jest tak zwa­ne mode­lo­wa­nie. Stosuję stan­dard doku­men­ta­cyj­ny zna­ny jako MDA/MDE (ang. Model Driven Architecture, Model Driven Engineering, więc w MDA…). Wszystkie śred­nie i duże pro­jek­ty reali­zu­ję meto­da ite­ra­cyj­no-przy­ro­sto­wą (patrz tak­że opis poję­cia sto­żek niepewności).

Etapy projektu

Projekt reali­zo­wa­ny zgod­nie z MBSE (Model Driven System Engineering) ma nastę­pu­ją­cą strukturę:

Etapy pro­jek­tu MBSE

Nazwy i cele klu­czo­wych eta­pów pra­cy Analityka Projektanta :

Kluczowe dwa eta­py pro­jek­tu ana­li­tycz­ne­go i ich skład­ni­ki. Bardzo waż­ne: wyma­ga­nia biz­ne­so­we są kon­se­kwen­cją pro­ce­sów biz­ne­so­wych oraz Celów Biznesowych Projektu, te ostat­nie Zamawiający musi sam opi­sać na eta­pie ini­cja­cji pro­jek­tu (na pod­sta­wie ).

Praktycznie wszyst­kie moje pro­jek­ty mają podob­ny scenariusz:

  1. Analityk jest w pro­jek­cie infor­ma­tycz­nym jak archi­tekt w pro­jek­cie budow­la­nym . Produktem Analizy Biznesowej jest model, któ­ry opi­su­je cel pro­jek­tu, mecha­nizm dzia­ła­nia orga­ni­za­cji, ale bez zbęd­nych deta­li. Stanowi sobą pew­ną ide­ali­za­cję orga­ni­za­cji . Produktem są Wymagania Biznesowe .
  2. Na pod­sta­wie Wymagań Biznesowych okre­śla­ny jest zakres pro­jek­tu (Przypadki uży­cia) i powsta­je Opis Techniczny Rozwiązania zwa­ny tak­że PIM , zawie­ra­ją­cy mię­dzy inny­mi model reali­za­cji logi­ki biz­ne­so­wej i prze­twa­rza­nia infor­ma­cji oraz archi­tek­tu­rę inte­gra­cji sys­te­mu . Projekt ten jest wyma­ga­niem (PIM) wobec opro­gra­mo­wa­nia .
  3. Wybór dostaw­ców.
  4. Nadzór autor­ski w toku prac wdro­że­nio­wych Wykonawcy.

CIM (Computation Independent Model) Audyt i Model Biznesowy organizacji

CIM to model biz­ne­so­wy abs­tra­hu­ją­cy od tech­no­lo­gii. Jego celem jest zro­zu­mie­nie mecha­ni­zmów dzia­ła­nia orga­ni­za­cji. Stosowane prze­ze mnie meto­dy opar­te są na ana­li­zie fak­tów (doku­men­tów) i opra­co­wa­niu mode­lu ich powsta­nia (pro­ce­sy biz­ne­so­we) .

Ten etap jest reali­zo­wa­ny jako audyt oraz pro­jekt ana­li­zy i reor­ga­ni­za­cji. Został opi­sa­ny osob­no jako Analiza i opra­co­wa­nie Architektury Biznesowej orga­ni­za­cji.

PIM (Platform Independent Model) Opracowanie Projektu Technicznego czyli projektowanie rozwiązania

Przypadki Użycia to opis z per­spek­ty­wy użyt­kow­ni­ka, ich spe­cy­fi­ka­cja to model PIM: opis tech­nicz­ny. Jest to model opi­su­ją­cy archi­tek­tu­rę i logi­kę dzia­ła­nia wyma­ga­ne­go roz­wią­za­nia (dedy­ko­wa­ne­go modu­łu). Tak opra­co­wa­na doku­men­ta­cji chro­ni tak­że know-how Zamawiającego.

Projektowanie archi­tek­to­nicz­ne jest dzia­łal­no­ścią inte­lek­tu­al­ną, w któ­rej archi­tekt prze­cho­dzi od abs­trak­cji do rze­czy­wi­sto­ści. W tym pro­ce­sie, abs­trak­cja repre­zen­tu­je logicz­ne rozu­mo­wa­nie w jaki spo­sób for­ma archi­tek­to­nicz­na jest skon­fi­gu­ro­wa­na lub ustruk­tu­ry­zo­wa­na, pod­czas gdy rze­czy­wi­stość odno­si się do osta­tecz­nej for­my fizycz­nej. Diagramy sta­ją się inte­gral­ną czę­ścią pro­jek­tu kon­cep­cyj­ne­go ponie­waż pośred­ni­czą pomię­dzy tymi dwo­ma sferami. 

Od daw­na wia­do­mo, że rosną­ca zło­żo­ność opro­gra­mo­wa­nie nie daje już szans czło­wie­ko­wi na napi­sa­nie kodu pro­gra­mu bez­błęd­nie za pierw­szym razem. Luka pomię­dzy wyma­ga­nia­mi a dzia­ła­ją­cym kodem rośnie i będzie rosła. Dlatego od daw­na lukę tę wypeł­nia się eta­pem mode­lo­wa­nia, któ­re nie narzu­ca tech­no­lo­gii imple­men­ta­cji, uwzględ­nia moż­li­wość mie­sza­nia dostęp­nych na ryn­ku goto­wych kom­po­nen­tów, a na eta­pie pro­to­ty­po­wa­nia jest wie­lo­krot­nie tań­sze tań­sze od kodowania,

Model (PIM) jako wypeł­nie­nie luki mię­dzy wyma­ga­nia­mi a Działającym opro­gra­mo­wa­niem .

Projekt rozwiązania jako Specyfikacja Wymagań

?First, solve the pro­blem. Then, wri­te the code. ? ? John Johnson

Najpierw powsta­je tak zwa­na Architektura Wysokiego Poziomu (ang. HLD, High-Level Design) dla cało­ści pro­jek­tu. Tam gdzie wyma­ga­ne będa dedy­ko­wa­ne modu­ły, pro­jekt jest uzu­peł­nia­ny o Architekturą Niskiego Poziomu (amg. LLD, Low-Level Design) czy­li pro­jekt tech­nicz­ny (nadal tyl­ko logi­ka). Są to dwie co naj­mniej iteracje. 

Etap pro­jek­to­wa­nia roz­wią­za­nia jest więc reali­zo­wa­ny zawsze (jest zale­ca­ny), gdy celem jest wdro­że­nie opro­gra­mo­wa­nia. Także dla­te­go, że może sie oka­zać, że więk­szość, a bywa że 100%, tego co potrze­bu­je­my (wie­my co bo mamy już model) moż­na już kupić na ryn­ku. Taki model sta­je wyma­ga­niem dla dostaw­cy systemu. 

Tu zno­wu przy­to­czę dia­gram obra­zu­ją­cy kolej­ne war­stwy mode­lo­wa­nia :

Mając już model biz­ne­so­wy (w tym mode­le pro­ce­sów biz­ne­so­wych) i wyma­ga­nia biz­ne­so­we (enter­pri­se con­text) spe­cy­fi­ku­je­my wyma­ga­ne usłu­gi apli­ka­cyj­ne (busi­ness servi­ces). Powstaje zakres pro­jek­tu. Jest doku­ment opi­su­ją­cy usłu­gi apli­ka­cji, zawie­ra­ją­cy: spe­cy­fi­ka­cję usług, powią­za­nych z nimi doku­men­tów, mapo­wa­nie ich na model pro­ce­sów biz­ne­so­wych, reali­zo­wa­ne wyma­ga­nia biz­ne­so­we (dostar­czo­ne przez zama­wia­ją­ce­go). Produktem tego eta­pu jest opra­co­wa­nie zgod­ne ze spe­cy­fi­ka­cją Model Driven Architecture/Computation Independent Model (źr. www​.omg​.org/​m​da/), etap ten (jako opra­co­wa­nie) sta­no­wi wynik trans­for­ma­cji mode­lu biz­ne­so­we­go na usłu­gi apli­ka­cyj­ne (jej przy­pad­ki użycia).

Usługi apli­ka­cji to kon­tekst sys­te­mu wyra­żo­ny jako opis jako czar­nej skrzyn­ki, co mode­lu­je­my jako przy­pad­ki uży­cia sys­te­mu. Praktyka poka­zu­je, że sam opis czar­nej skrzyn­ki nie sta­no­wi spe­cy­fi­ka­cji sys­te­mu, dla­te­go w inży­nie­rii (opro­gra­mo­wa­nia tak­że) sto­su­je się zasa­dę: model jako spe­cy­fi­ka­cja (MBSE: ang. Model-Based System Engineering) . Innymi sło­wy spe­cy­fi­ko­wa­nie wyma­gań na sys­tem pole­ga na jego zapro­jek­to­wa­niu, a pro­jekt ten jest odpo­wie­dzią na wyma­ga­nia biznesowe. 

Związek mię­dzy wyma­ga­nia­mi wobec sys­te­mu a jego mode­lem czy­li wewnętrz­ną struk­tu­rą i zachowaniem 

Projekt sys­te­mu to model opi­su­ją­cy struk­tu­rę (archi­tek­tu­rę) i zacho­wa­nia. Zachowania sys­te­mu to jego reak­cje na bodź­ce z zewnątrz, to jego przy­pad­ki użycia. 

Dane to informacje dla człowieka

Kluczowym ele­men­tem tego opi­su są struk­tu­ry doku­men­tów wyra­żo­ne w spo­sób sformalizowany: 

Przykład opi­su struk­tu­ry infor­ma­cyj­nej doku­men­tu (nota­cja UML)

Zawierają one opis spo­so­bu reali­za­cji więk­szo­ści wyma­gań biz­ne­so­wych (np. jeże­li sys­tem ma pozwa­lać na kon­tro­le wyko­rzy­sta­nia urlo­pów” to zna­czy, że wnio­sek urlo­po­wy powi­nien zawie­rać dane: typ urlo­pu oraz licz­ba dni, co nale­ży udo­ku­men­to­wać jak wyżej). Więcej w arty­ku­le Dokumentowani przy­pad­ków uży­cia.

Jeżeli oka­że się, że nie zaofe­ro­wa­no pro­duk­tu ist­nie­ją­ce­go już na ryn­ku (lub nie speł­nia­ją one wyma­gań w 100%), to zna­czy że powsta­ną dedy­ko­wa­ne kom­po­nen­ty. Jest to sytu­acja, w któ­rej mecha­nizm (logi­ka biz­ne­so­wa) wybra­ne­go obsza­ru dzia­ła­nia orga­ni­za­cji jest uni­kal­na, bar­dzo czę­sto mecha­nizm ten sta­no­wi chro­nio­ny know-how tej orga­ni­za­cji. W takiej sytu­acji powsta­je pro­jekt tech­nicz­ny tego kom­po­nen­tu, a od wyko­naw­cy ocze­ki­wa­na jest ofer­ta na wyko­na­nie implementacji. 

(Dalsza część jest prze­zna­czo­na tak­że dla dostaw­ców i wyko­naw­ców oprogramowania)

Programming is not sole­ly abo­ut con­struc­ting software?programming is abo­ut desi­gning software. 

(Programowanie nie doty­czy wyłącz­nie kon­stru­owa­nia opro­gra­mo­wa­nia – pro­gra­mo­wa­nie doty­czy pro­jek­to­wa­nia opro­gra­mo­wa­nia. , więc od nie­daw­na jestem programistą 🙂 )

Poprzedzanie pro­gra­mo­wa­nia pro­jek­to­wa­niem jest klu­czo­wym eta­pem obni­ża­ją­cym ryzy­ko pro­jek­tu .

Niezależnie od tego ile prze­pro­wa­dzisz roz­mów z mistrza­mi gry w bilar­da i ile godzin fil­mów nakrę­cisz nad sto­łem bilar­do­wym, nie zbli­żysz się nawet do stwo­rze­nia dość dobrej gdy w bilar­da. Jednak wystar­czy, poświę­cić czas na zro­zu­mie­nie i zapi­sa­nie praw fizy­ki rzą­dzą­cych ruchem kul na sto­le bilar­do­wym, by napi­sać grę dosko­na­łą”.  

Projekt archi­tek­tu­ry apli­ka­cji to tak­że wyma­ga­nie: wyma­ga­my dostar­cze­nia tego co zapro­jek­to­wa­no. Nie jest to deta­licz­ny pro­jekt opro­gra­mo­wa­nia czy pro­ce­dur, jest to opis archi­tek­tu­ry opro­gra­mo­wa­nia (sys­te­mu IT), ocze­ki­wa­nej (ide­ali­za­cja) logi­ki biz­ne­so­wej mecha­ni­zmu jego działania. 

Co do zasa­dy pro­jek­to­wa­na jest tak zwa­na archi­tek­tu­ra wyso­kie­go pozio­mu (model PIM wg. OMG​.org/​MDA), czy­li sys­tem zło­żo­ny z dzie­dzi­no­wych kom­po­nen­tów, ich inte­gra­cja, model infor­ma­cyj­ny. Model infor­ma­cyj­ny to opis zawar­to­ści (struk­tur) doku­men­tów ujaw­nio­nych w pro­ce­sach w Analizie Biznesowej, logi­ka popraw­no­ści danych na doku­men­tach oraz logi­ka wią­żą­ca doku­men­ty mię­dzy sobą. 

Dedykowane moduły – add-on’s

Wdrożenie w fir­mie jed­ne­go mono­li­tu, czy­li sys­te­my ERP speł­nia­ją­ce­go wszyst­kie wyma­ga­nia, jest prak­tycz­nie nie­moż­li­we, a jego kasto­mi­za­cja są naj­czę­ściej kata­stro­fal­ne dla nie­go. Dlatego powszech­na prak­ty­ką jest inte­gro­wa­nie z nim dedy­ko­wa­nych modu­łów kupo­wa­nych na ryn­ku lub reali­zo­wa­nych jako dedykowane:

Czym jest moduł dodat­ko­wy w sys­te­mie ERP? W skró­cie, jest to skład­nik opro­gra­mo­wa­nia, któ­ry zapew­nia dodat­ko­we moż­li­wo­ści, któ­re roz­sze­rza­ją i inte­gru­ją się z pakie­tem pod­sta­wo­wym ofe­ro­wa­nym przez dostaw­cę ERP. Czasami orga­ni­za­cje wybie­ra­ją modu­ły dodat­ko­we od róż­nych dostaw­ców, co jest uwa­ża­ne za naj­lep­sze podejście.

https://​www​.pano​ra​ma​-con​sul​ting​.com/​w​h​a​t​-​i​s​-​a​d​d​-​o​n​-​m​o​d​u​l​e​-​i​n​-​e​rp/

W przy­pad­ku gdy na rynek nie ofe­ru­je goto­we­go roz­wią­za­nia (wie­le firm ma swo­ją spe­cy­fi­kę) pozo­sta­je zapro­jek­to­wa­nie go i implementacja. 

Programowanie nie pole­ga już wyłącz­nie na pisa­niu kodu, pro­gra­mo­wa­nie pole­ga na pro­jek­to­wa­niu. .

Projekt dedy­ko­wa­ne­go opro­gra­mo­wa­nia to tak zwa­ny Opis Techniczny Rozwiązania to tak zwa­ny model PIM (ang. Platform Independent Model) i jest to – ten pro­jekt – wyma­ga­nie. Stanowi on spe­cy­fi­ka­cję usług jakich ocze­ku­je się od opro­gra­mo­wa­nia oraz opis logi­ki jaką ma ono reali­zo­wać (dokład­niej­szy opis w tek­ście Analiza Biznesowa i Opis Techniczny Oprogramowania Dedykowanego).

Przypadki uży­cia, wypro­wa­dza­ne z mode­li pro­ce­sów biz­ne­so­wych, są dodat­ko­wo doku­men­to­wa­ne z uży­ciem sce­na­riu­szy, te zaś wyko­rzy­stu­ją kom­po­nen­ty reali­zu­ją­ce logi­kę biz­ne­so­wą (tak zwa­ny model dzie­dzi­ny). Poniżej struk­tu­ra mode­li (per­spek­ty­wy) jakie powsta­ją (patrz tak­że pro­ces OMG SPEM):

(źr. )
Powyższy dia­gram sta­no­wi ilu­stra­cję struk­tu­ry pro­jek­tu. Od cza­su publi­ka­cji tego pod­ręcz­ni­ka defi­ni­cja obiek­to­we­go para­dyg­ma­tu ule­gła pew­nej ewo­lu­cji: cen­tral­na część, model dzie­dzi­ny sys­te­mu (wyra­żo­ny jako dia­gram klas UML), pocho­dzi z metod struk­tu­ral­nych, a nie obiek­to­wych, i obec­nie nie nale­ży go tak tworzyć.

Model logi­ki apli­ka­cji poka­za­ny powy­żej to zgod­ny z podej­ściem MDA/MDE, jest to pro­jekt logi­ki i archi­tek­tu­ry przy­szłej apli­ka­cji (w nota­cji UML). Całość jest wyko­na­na w czy­tel­ny dla adre­sa­ta spo­sób (niu­an­se nota­cji musi znać autor dia­gra­mów, ich odbior­com wystar­czy opi­sa­na legen­da symboli).

Tworzenie kodu obej­mu­je wie­le pozio­mów abs­trak­cji, pro­wa­dzą­cych od wyma­gań do kodu. Posiadanie abs­trak­cyj­nych kon­cep­cji mode­lo­wa­nia dostęp­nych jako wyso­ko­po­zio­mo­we kon­struk­cje pro­gra­mi­stycz­ne poma­ga zde­fi­nio­wać kod i upew­nić się, że kom­po­nen­ty opro­gra­mo­wa­nia zacho­wu­ją się w ocze­ki­wa­ny spo­sób. Istnieje luka, któ­rej nie moż­na wypeł­nić zwy­kły­mi meto­da­mi pro­gra­mo­wa­nia, ale któ­rą moż­na wypeł­nić, jeśli pro­gra­mo­wa­nie jest wspie­ra­ne przez odpo­wied­nie ramy mode­lo­wa­nia (meto­dę pro­jek­to­wa­nia i ana­li­zy oraz język).

Metody obiek­to­we mają ogrom­ne zale­ty, są zna­ne od lat, są sto­so­wa­ne… są mało popu­lar­ne bo są trud­ne … ale ja robię to od 20 lat… 

(Designing Object Systems: Object-Oriented Modelling with Syntropy Textbook Binding ? November 18, 1994 by Steve Cook (Author), John Daniels (Author))

Opis bar­dziej tech­nicz­ny oraz przy­kła­do­wą spe­cy­fi­ka­cję znaj­dzie­cie Państwo na stro­nie Analiza, wyma­ga­nia i uspraw­nia­nie orga­ni­za­cji czy­li MBSE. Omówiony przy­kład OPZ dla admi­ni­stra­cji publicz­nej na stro­nie Generator Ofert. Przykładowy doku­ment pro­jek­to­wy i to jak powsta­wał na stro­nie Biblioteka.

Podsumowanie

  • wyma­ga­nia funk­cjo­nal­ne są doku­men­to­wa­ne jako usłu­gi apli­ka­cji (jej przy­pad­ki uży­cia) i for­mu­la­rze (patrz Projekt apli­ka­cji)
  • w opi­sach for­mu­la­rzy i doku­men­tów posłu­gu­ję się stan­dar­do­wo ich tre­ścią i struk­tu­rą (XML),
  • komu­ni­ka­cja ze mną w toku nad­zo­ru autor­skie­go i roz­wo­ju odby­wa się z pomo­cą moje­go repo­zy­to­rium: Postmania.
  • osta­tecz­ne decy­zje i szcze­gó­ły powsta­ją w toku Nadzoru Autorskiego (patrz Nadzór Autorski)

(na pod­sta­wie: P.Sienkiewicz, L.Koźmiński, P.Miller, OMG​.org)

Sku­tecz­ny opis wyma­gań to spe­cy­fi­ka­cja wyra­żo­na języ­kiem o skoń­czo­nej licz­bie pojęć, pozwa­la­ją­ca pro­gra­mi­stom ?wlać? ją do kolej­nej ?for­mal­nej for­my? jaką jest język pro­gra­mo­wa­nia. (patrz: Logika wnio­sko­wa­nia deduk­cyj­ne­go czy­li czym jest popraw­na ana­li­za i mode­lo­wa­nie)

Tu pole­cam refe­rat na temat pro­jek­to­wa­nia: jak i po co. 

Wybór dostawców i umowa

Ten etap to ogło­sze­nie (roze­sła­nie) zapy­ta­nia ofer­to­we­go. Standardowo w pierw­szym kro­ku ogła­szam RFI (zapy­ta­nie o goto­wość do zło­że­nia ofer­ty) bez poda­nia danych Zamawiającego, na moich pro­fi­lach w mediach spo­łecz­no­ścio­wych (mam kil­ka tysię­cy obser­wu­ją­cych osób i firm). Firmy, któ­re zgło­si­ły się w tym eta­pie są oce­nia­ne przez Zamawiającego, któ­ry wybie­ra kil­ka. Wybranym fir­mom prze­ka­zy­wa­ne jest peł­ne zapy­ta­nie RFP z Opisem Przedmiotu Zamówienia Przedmiotem Zamówienia są okre­ślo­ne w zapy­ta­niu usłu­gi (np. wdro­że­nie, szko­le­nia itp.) oraz wynik Analizy Biznesowej i Opis Techniczny Oprogramowania) . Wybierany jest Wykonawca, któ­ry zło­żył naj­ko­rzyst­niej­szą ofer­tę, kry­te­ria­mi są zawsze cena, kom­pe­ten­cje i doświad­cze­nie oraz zaofe­ro­wa­na technologia.

Na tym eta­pie, zgod­nie z Art.634 KC, Wykonawca powi­nien zgło­sić wszel­kie ewen­tu­al­ne swo­je zastrze­że­nia do mate­ria­łów (doku­men­ta­cja) jakie otrzy­mał, i robić to na bie­żą­co tak­że w toku reali­za­cji pro­jek­tu, jeże­li otrzy­ma jakie­kol­wiek nowe materiały.

Ogłoszenia i zapy­ta­nia ofer­to­we moich klien­tów (w tym tak­że Opis Przedmiotu Zamówienia) stan­dar­do­wo wysy­łam na listę sub­skry­ben­tów moje­go ser­wi­su.

Podpisanie Umowy i nadzór autorski

Wyma­ga­nia na począt­ku pro­jek­tu nie są osta­tecz­nym pro­duk­tem analityka

Wszystkie deta­le tech­no­lo­gicz­ne opra­co­wu­je Wykonawca, któ­ry skła­da­jąc ofer­tę zade­kla­ro­wał, że dostar­czy roz­wią­za­nie zgod­ne z Projektem Technicznym, a w swo­im doku­men­cie, jakim jest Koncepcja Wdrożenia, Wykonawca powi­nien opi­sać to, jak zre­ali­zu­je pro­jekt z uży­ciem tech­no­lo­gii jaką zaoferował.

Koncepcja nad­zo­ru autor­skie­go zakła­da, że pro­jek­tant (autor), na zle­ce­nie inwe­sto­ra, pro­jek­tu­je roz­wią­za­nie a następ­nie, po wybo­rze wyko­naw­cy, nad­zo­ru­je reali­za­cję roz­wią­za­nia i uzu­peł­nia treść pro­jek­tu o wyma­ga­ne szcze­gó­ły, odpo­wia­da­jąc na pyta­nia zarów­no inwe­sto­ra jak i wyko­naw­cy. Dokumentacji pro­jek­to­wej nie da się zamro­zić” na czas trwa­nia nie raz wie­lo­mie­sięcz­ne­go pro­jek­tu. Dlatego więk­sze pro­jek­ty są reali­zo­wa­ne kom­po­nent po kom­po­nen­cie w pętli iteracyjno-przyrostowej.

Po zakoń­cze­niu imple­men­ta­cji, uzu­peł­nia­ne w toku pro­jek­tu, powią­za­ne z sobą Projekt roz­wią­za­nia (uzu­peł­nia­ny w toku nad­zo­ru autor­skie­go) i Opis imple­men­ta­cji (uzu­peł­nia­ny przez Wykonawcę), sta­no­wią kom­plet­ną doku­men­ta­cję dostar­czo­ne­go pro­duk­tu. Całość zobra­zo­wa­no na poniż­szym diagramie:

Produkty powsta­ją­ce w toku ana­li­zy, pro­jek­to­wa­nia i imple­men­ta­cji. Pokazano klu­czo­we ele­men­ty umo­wy z dostaw­cą opro­gra­mo­wa­nia. Możliwa jest sytu­acja, w któ­rej nie ma ryn­ku opro­gra­mo­wa­nia speł­nia­ją­ce­go wyma­ga­nia, i wte­dy całość dosta­wy (przed­miot umo­wy) sta­no­wi opro­gra­mo­wa­nie dedykowane.

Dostawca roz­wią­za­nia nie robi żad­nej swo­jej ana­li­zy przed-wdro­że­nio­wej. Na pod­sta­wie otrzy­ma­nych mate­ria­łów opra­co­wu­je Koncepcję Wdrożenia, któ­rą reali­zu­je w toku projektu. 

Praktyka poka­zu­je, że pro­ble­my z wdro­że­niem sys­tem ERP są powo­do­wa­ne, przez zało­że­nie kupu­ją­ce­go, że dostaw­ca ma doświad­cze­nie i wie jak wdro­żyć swój sys­tem. Problem w tym, że dostaw­ca w dobrej wie­rze, wdro­ży to co ma, osob­ną kwe­stia jest upew­nie­nie się, że to co ma jest tym cze­go potrze­bu­je­my. To dla­te­go wybór dostaw­cy roz­wią­za­nia powi­nien być ostat­nim, a nie pierw­szym eta­pem pro­jek­tu przy­go­to­wa­nia do wdro­że­nia. Istotne jest tak­że, co poka­za­no na powyż­szym dia­gra­mie, ści­słe roz­dzie­le­nie kodu licen­cjo­no­wa­ne­go od wytwo­rzo­ne­go w toku wdro­że­nia (patrz: Kastomizacja).

Polecam tak­że arty­kuł Wymagania umar­ły…?1?

Dodatek: Podmioty publiczne i PZP

Na zakoń­cze­nie kil­ka słów o zamó­wie­niach publicz­nych, sku­pię jed­nak wyłącz­nie na kwe­stiach usług jakie oso­bi­ście ofe­ru­ję. Jestem gorą­cym zwo­len­ni­kiem poniż­szej tezy:

Kryteria poza­ce­no­we nazy­wam pozor­ny­mi, dla­te­go, że na eta­pie oce­ny ofert są one w zasa­dzie nie­moż­li­we do zwe­ry­fi­ko­wa­nia Niestety w prze­tar­gach na usłu­gi IT kry­te­ria poza­ce­no­we czę­sto nicze­mu nie słu­żą, a osta­tecz­nie i tak decy­du­je cena.

(mec Monika Wandzel, źr.: Jak zwe­ry­fi­ko­wać jakość ofe­ren­tów?)

Dlatego zga­dzam się z opi­nia­mi mówią­cy­mi, że naj­sku­tecz­niej­szą meto­dą wyra­ża­nia wyma­gań na roz­wią­za­nie jest pro­jekt tego roz­wią­za­nia, a nie opis jego cech. 

Od wie­lu lat moimi zle­ce­nio­daw­ca­mi są tak­że pod­mio­tu publicz­ne (mię­dzy inny­mi: PFRON, Urząd Miasta Warszawy, PSE, KGHM SA, Żandarmeria Wojskowa, Kancelaria Senatu). Przetargi publicz­ne z zasa­dy są pro­jek­ta­mi okre­śla­ny­mi jako fixed-pri­ce” (cał­ko­wi­ty koszt okre­śla­ny w momen­cie zamó­wie­nia) co czy­ni je trud­niej­szy­mi na eta­pie przy­go­to­wa­nia. Pojawiają się publi­ka­cje na temat sto­so­wa­nia zwin­nych metod w admi­ni­stra­cji publicz­nej”, fir­mo­wa­ne nawet przez zna­ne kan­ce­la­rie praw­ne, jed­nak prak­ty­ka poka­zu­je, że two­rze­nie OPZ w posta­ci otwar­te­go zarzą­dzal­ne­go zakre­su pro­jek­tu” nie roz­wią­zu­je prak­tycz­nie żad­nych pro­ble­mów, za to stwa­rza ogrom­ne ryzy­ko prze­ję­cia zarzą­dza­nia zakre­sem pro­jek­tu przez dostaw­cę („dosta­niesz to co chce Ci dostar­czyć dostaw­ca a nie to cze­go potrze­bu­jesz”), Jeden z moich komen­ta­rzy na ten temat tu: Agile w PZP (2017).

W Czerwcu 2020 roku, Urząd Zamówień Publicznych opu­bli­ko­wał doku­ment: POSTĘPOWANIE O UDZIELENIE ZAMÓWIENIA PUBLICZNEGO NA SYSTEM INFORMATYCZNY. We wstę­pie auto­rzy piszą: 

Zakup sys­te­mów infor­ma­tycz­nych to zło­żo­ny pro­ces, któ­ry wyma­ga od zama­wia­ją­cych rze­tel­ne­go przy­go­to­wa­nia. Istotny wpływ na powo­dze­nie zamie­rze­nia inwe­sty­cyj­ne­go zwią­za­ne­go z zama­wia­nym sys­te­mem IT ma wie­le czyn­ni­ków, wśród któ­rych przy­kła­do­wo moż­na wymie­nić zna­jo­mość roz­wią­zań IT wystę­pu­ją­cych na ryn­ku, aktu­al­ność posia­da­nych przez zama­wia­ją­ce­go w tym zakre­sie infor­ma­cji, czy też świa­do­mość co do moż­li­wo­ści wła­snych zama­wia­ją­ce­go w zakre­sie pra­wi­dło­we­go i wyczer­pu­ją­ce­go przy­go­to­wa­nia postę­po­wa­nia na zakup sys­te­mu IT. Prawidłowe przy­go­to­wa­nie zama­wia­ją­ce­go do prze­pro­wa­dze­nia postę­po­wa­nia, tj. na eta­pie jesz­cze przed wsz­czę­ciem postę­po­wa­nia o udzie­le­nie zamó­wie­nia publicz­ne­go, pozwa­la mini­ma­li­zo­wać pro­ble­my, jakie mogą wystą­pić w pro­wa­dzo­nym w przy­szło­ści postę­po­wa­niu, a tak­że w trak­cie reali­za­cji oraz eks­plo­ata­cji przed­mio­tu zamó­wie­nia, szcze­gól­nie w przy­pad­ku naby­wa­nia zło­żo­nych roz­wią­zań technologicznych.

Jak widać zwra­ca się szcze­gól­ną uwa­gę na kom­pe­ten­cje wyma­ga­ne do opra­co­wa­nia nie­zbęd­nej doku­men­ta­cji oraz na wewnętrz­ne przy­go­to­wa­nie do przy­szłe­go wdro­że­nia i eks­plo­ata­cji sys­te­mu infor­ma­tycz­ne­go. Autorzy zwra­ca­ją uwa­gę, że:

…choć obo­wią­zek prze­pro­wa­dze­nia ana­li­zy potrzeb i wyma­gań, o któ­rej mowa w art. 83 usta­wy PZP doty­czy tyl­ko nie­któ­rych zama­wia­ją­cych i postę­po­wań (tzn. nie doty­czy zamó­wień o war­to­ściach nie­prze­kra­cza­ją­cych pro­gów unij­nych oraz zamó­wień sek­to­ro­wych), to jed­nak prze­pro­wa­dze­nie ana­lo­gicz­ne­go pro­ce­su może być uza­sad­nio­ne tak­że w wypad­kach, w któ­rych nie jest on obligatoryjny.

Ważny zapis:

W nowej usta­wie PZP okre­ślo­ny został próg war­to­ścio­wy wyzna­cza­ją­cy obo­wią­zek sto­so­wa­nia przez zama­wia­ją­ce­go prze­pi­sów tej usta­wy. Obowiązek ten powsta­je, jeże­li war­tość zamó­wie­nia osią­gnie ten próg. Zgodnie z prze­pi­sem art. 2 ust. 1 pkt 1 usta­wy PZP, jej prze­pi­sy sto­su­je się, co do zasa­dy, do udzie­la­nia zamó­wień publicz­nych oraz orga­ni­zo­wa­nia kon­kur­sów, któ­rych war­tość jest rów­na lub prze­kra­cza kwo­tę 130 000 zł, przez zama­wia­ją­cych publicznych.

W dal­szej czę­ści doku­men­tu czytamy: 

Zamawiający powi­nien zwe­ry­fi­ko­wać kom­pe­ten­cje wła­sne­go zespo­łu i spraw­dzić, czy dys­po­nu­je spe­cja­li­sta­mi, któ­rzy: (-) przy­go­tu­ją opis przed­mio­tu zamó­wie­nia w spo­sób wystar­cza­ją­co pre­cy­zyj­ny i dokład­ny, a tak­że uwzględ­nia­ją­cy ade­kwat­ne potrze­by zama­wia­ją­ce­go, naj­now­sze stan­dar­dy i wytycz­ne, nor­my bran­żo­we, w tym tak­że w zakre­sie cyber­bez­pie­czeń­stwa sys­te­mów IT, (-) zapew­nią spraw­ną reali­za­cję postę­po­wa­nia zamó­wie­nio­we­go (np. w zakre­sie odpo­wie­dzi na pyta­nia wyko­naw­ców, oce­ny ofert,) (-) zapew­nią nale­ży­tą reali­za­cję umo­wy zawar­tej w ramach zamówienia.

Przygotowanie do prze­tar­gu (ana­li­za potrzeb i opra­co­wa­nie OPZ), wspar­cie w toku postę­po­wa­nia oraz rocz­ny nad­zór autor­ski (wie­le wdro­żeń sys­te­mów infor­ma­tycz­nych, jakie pro­wa­dzi­łem, mie­ści sie w gra­ni­cach roku od pod­pi­sa­nia umo­wy z dostaw­cą), to w moim przy­pad­ku, to usłu­ga o war­to­ści bar­dzo czę­sto poni­żej 130 tys. zł, wraz z kosz­tem. Oznacza to, że może­cie Państwo zle­cić mi taką usłu­gę (przy­go­to­wa­nie do prze­tar­gu) bez stra­ty cza­su na kon­kur­sy (bez nad­zo­ru autor­skie­go jest to koszt 40 tys. zł). Wystarczająca jest oce­na dorob­ku, kom­pe­ten­cji i doświad­cze­nia oraz (co bar­dzo waż­ne) pod­pi­sa­nie oświad­cze­nia o bra­ku kon­flik­tu interesu: 

Zamawiający musi więc pamię­tać o tre­ści art. 85 oraz art. 108 ust. 1 pkt 6 usta­wy PZP, któ­re naka­zu­ją prze­ciw­dzia­łać sytu­acji, w któ­rej udział dane­go wyko­naw­cy w przy­go­to­wa­niu postę­po­wa­nia zakłó­ci kon­ku­ren­cję, a jeże­li tego zakłó­ce­nia wyeli­mi­no­wać się nie da, naka­zu­ją wyklu­czyć z postę­po­wa­nia wyko­naw­cę, któ­ry był zaan­ga­żo­wa­ny przy przy­go­to­wa­niu postępowania.

Autorzy zale­ceń piszą także:

Wobec dyna­mi­ki zmian zacho­dzą­cych w zakre­sie roz­wią­zań infor­ma­tycz­nych, zama­wia­ją­cy powi­nien szcze­gól­nej uwa­dze pod­dać aktu­al­ność posia­da­nych infor­ma­cji. Mając na uwa­dze powyż­sze, istot­ne jest rów­nież to, aby zama­wia­ją­cy pla­no­wał prze­pro­wa­dze­nie postę­po­wa­nia w taki spo­sób, aby zapo­bie­gać prze­wle­kło­ści pro­ce­su zaku­po­we­go, gdyż powo­du­je ona ryzy­ko dez­ak­tu­ali­za­cji opra­co­wa­nej dokumentacji.

Jednak część for­mal­na SWZ” powin­na być przy­go­to­wa­nia przez Zamawiającego i jego służ­by praw­ne. Autorzy zwra­ca­ją tu uwa­gę, że: 

Nie moż­na też zapo­mnieć o tre­ści pro­jek­to­wa­nych posta­no­wień umo­wy ? ich przy­go­to­wa­nie bez dogłęb­nej wie­dzy o przed­mio­cie zamó­wie­nia oraz prze­bie­gu jego reali­za­cji, jest błę­dem, na któ­ry nie może sobie pozwo­lić żaden zamawiający.

Poniżej treść oma­wia­ne­go dokumentu:

Polecam lek­tu­rę powyż­sze­go doku­men­tu w całości. 

Dodatek: Opis odwoływania się, w Koncepcji Wdrożenia, do wymagań

Każdy dostaw­ca roz­wią­za­nia, jako pierw­szy pro­dukt w reali­za­cji Umowy (lub na eta­pie ofer­to­wa­nia) musi (powi­nien) opra­co­wać doku­ment Koncepcja Wdrożenia (stu­dium wyko­nal­no­ści, ana­li­za fit-gap, lub odpo­wied­nik), opi­su­ją­cy to jak pro­po­nu­je, wdra­ża­jąc ofe­ro­wa­ny pro­dukt, zre­ali­zo­wać Wymagania Zamawiającego.

Analiza Biznesowa i Projekt Techniczny Rozwiązania” (dalej Analiza) zawie­ra mię­dzy inny­mi roz­dzia­ły: Model Procesów Biznesowych oraz Model Kontekstowy Systemu IT (Zamawiającego). Pierwszy zawie­ra opis dzia­ła­nia orga­ni­za­cji, dru­gi zawie­ra zakres wdro­że­nia w posta­ci listy wyma­ga­nych usług apli­ka­cyj­nych (wyra­żo­nych jako przy­pad­ki uży­cia UML oraz ich spe­cy­fi­ka­cje, to wyma­ga­nia wyra­żo­ne meto­dą MDA/MBSE).

Opis każ­dej wyma­ga­nej usłu­gi apli­ka­cji w Analizie (przy­pad­ki uży­cia) zawiera: 

  • kon­tekst i celu jej uży­cia i wska­za­nie jej akto­ra (pra­cow­nik, klient, inny sys­tem itp..),
  • sza­blon for­mu­la­rza ekranowego/wydruku i wali­da­cję pól,
  • archi­tek­tu­rę i logi­kę reali­za­cji wymia­ny danych z inny­mi for­mu­la­rza­mi i inny­mi apli­ka­cja­mi, jeże­li to wyma­ga­ne (inte­gra­cja).

Dostawca roz­wią­za­nia w tre­ści pro­po­no­wa­nej Koncepcji Wdrożenia (to pro­dukt dostawcy): 

  1. albo orga­ni­zu­je ten doku­ment w taki spo­sób, że wska­zu­je w nim jak zre­ali­zu­je każ­dą wyma­ga­ną usłu­gę apli­ka­cji (wte­dy pod­sta­wą spi­su tre­ści Koncepcji Wdrożenia są wyma­ga­ne usłu­gi aplikacji),
  2. albo orga­ni­zu­je ten doku­ment w taki spo­sób, że wska­zu­je (przy­wo­łu­je) w np. stan­dar­do­wym opi­sie dostar­cza­ne­go roz­wią­za­nia (np. Instrukcja Obsługi) miej­sca (np. funk­cje apli­ka­cji w menu), któ­re reali­zu­ją okre­ślo­ną, wyma­ga­ną usłu­gę apli­ka­cji (wte­dy pod­sta­wą spi­su tre­ści Koncepcji Wdrożenia jest opis funk­cjo­nal­ny dostar­cza­nej aplikacji). 

Pierwszy przy­pa­dek np.: wyma­ga­na usłu­ga [nazwa usłu­gi: przy­pad­ku uży­cia ] jest reali­zo­wa­na przez [tu wska­za­nie, któ­re stan­dar­do­we funk­cje dostar­cza­ne­go opro­gra­mo­wa­nia ją reali­zu­ją i jak]”.

Drugi przy­pa­dek: Nasze opro­gra­mo­wa­nie ma funk­cje [tu nazwa i opis tej funk­cji], któ­ra reali­zu­je potrze­by opi­sa­ne jako [tu nazwa usłu­gi apli­ka­cji – przy­pa­dek uży­cia – w Analizie]”.

Jeżeli dostar­czo­ne opro­gra­mo­wa­nie w wer­sji stan­dar­do­wej nie reali­zu­je jakiejś wyma­ga­nej w Analizie usłu­gi, powin­na się poja­wić taka infor­ma­cja wraz z pro­po­zy­cją meto­dy roz­sze­rze­nia funk­cjo­nal­no­ści stan­dar­do­wej wer­sji dostar­cza­ne­go opro­gra­mo­wa­nia. Tak zor­ga­ni­zo­wa­ny doku­ment Koncepcji Wdrożenia jest tak­że czę­sto nazy­wa­ny ana­li­zą fit-gap” , tak­że: , , . Patrz tak­że powy­żej: Idealizacja jako meto­da.

Źródła

Ackoff, R. L., Magidson, J., Addison, H. J., & Ehrlich, A. (2007). Projektowanie ide­ału: kształ­to­wa­nie przy­szło­ści orga­ni­za­cji. Wyższa Szkoła Przedsiębiorczości i Zarządzania im. Leona Koźmińskiego : Wydawnictwa Akademickie i Profesjonalne.
Ackoff, R. L., Magidson, J., & Addison, H. J. (2006). Idealized design: cre­ating an organization’s futu­re. Wharton School Pub.
Alassaf, N., & Clayton, M. (2021). The Use of Diagrammatic Reasoning to Aid Conceptual Design in Building Information Modeling (BIM). Building Information Modelling, Volume 2, 10.
Ancveire, I. (2018). Fit Gap Analysis Methods for ERP Systems Literature Review. 2018 IEEE 12th International Symposium on Applied Computational Intelligence and Informatics (SACI), 000161 – 000166. https://​doi​.org/​1​0​.​1​1​0​9​/​S​A​C​I​.​2​0​1​8​.​8​4​4​0​972
Arlow, J., & Neustadt, I. (2004). Enterprise pat­terns and MDA: buil­ding bet­ter softwa­re with arche­ty­pe pat­terns and UML. Addison-Wesley.
Bajaj, M. (n.d.). Satellites to Supply Chains, Energy to Finance — SLIM for Model-Based Systems Engineering. Part 1: Motivation and Concept of SLIM. 27.
Bajaj, M., Cole, B., & Zwemer, D. (2016, September 13). Architecture To Geometry – Integrating System Models With Mechanical Design. AIAA SPACE 2016. AIAA SPACE 2016, Long Beach, California. https://​doi​.org/​1​0​.​2​5​1​4​/​6​.​2​016 – 5470
Belli, F., Budnik, C. J., & White, L. (2006). Event-based model­ling, ana­ly­sis and testing of user inte­rac­tions: appro­ach and case stu­dy. Software Testing, Verification and Reliability, 16(1), 3 – 32. https://​doi​.org/​1​0​.​1​0​0​2​/​s​t​v​r​.​335
Börger, E. (2018). Why Programming Must Be Supported by Modeling and How. In T. Margaria & B. Steffen (Eds.), Leveraging Applications of Formal Methods, Verification and Validation. Modeling (Vol. 11244, pp. 89 – 110). Springer International Publishing. https://​doi​.org/​1​0​.​1​0​0​7​/​978 – 3‑030 – 03418-4_6
Brambilla, M., Cabot, J., & Wimmer, M. (2012). Model-dri­ven softwa­re engi­ne­ering in prac­ti­ce. Morgan & Claypool.
Cohn, D., & Hull, R. (2009). Business arti­facts: A data-cen­tric appro­ach to mode­ling busi­ness ope­ra­tions and pro­ces­ses. IEEE Data Eng. Bull., 32(3), 3 – 9.
Cook, S., & Daniels, J. (1994). Designing object sys­tems: object-orien­ted model­ling with Syntropy. Prentice Hall.
Dennis, A., Wixom, B. H., & Roth, R. M. (2012). Systems ana­ly­sis and design (5th ed). John Wiley.
expert​pro​gram​ma​na​ge​ment​.com/. (2021, March). Porter’s Value Chain – Strategy Training from EPM [Blog]. Expert Program Management. https://​expert​pro​gram​ma​na​ge​ment​.com/​2​0​2​1​/​0​3​/​p​o​r​t​e​r​s​-​v​a​l​u​e​-​c​h​a​in/
Fowler, M. (1997). Analysis pat­terns: reu­sa­ble object models. Addison Wesley.
Kiec, M. (2021). FIT-GAP ANALYSIS AS INTRODUCTION STEP TO BUSINESS PROCESS STANDARDIZATION. Scientific Journal of Silesian University of Technology. Series Transport, Issue No. 153, 193. https://​doi​.org/​1​0​.​2​9​1​1​9​/​1​641 – 3466.2021.153.14
Kitchenham, B. A., Budgen, D., & Brereton, P. (2016). Evidence-based softwa­re engi­ne­ering and sys­te­ma­tic reviews. CRC Press.
Kumar, R. N. P., & Patil, S. (2019). A System and Method for impro­ving the Model Based Systems Engineering Environment capa­bi­li­ty. INCOSE International Symposium, 29(S1), 277 – 290. https://​doi​.org/​1​0​.​1​0​0​2​/​j​.​2​334 – 5837.2019.00685.x
Object Management Group. (2014, June 18). Model Driven Architecture (MDA). OMG​.Org. https://​www​.omg​.org/​m​da/
Ozkaya, I. (2020). Building Blocks of Software Design. IEEE Software, 37(2), 3 – 5. https://​doi​.org/​1​0​.​1​1​0​9​/​M​S​.​2​0​1​9​.​2​9​5​9​049
Porter, M. E. (1998). Competitive advan­ta­ge: cre­ating and susta­ining supe­rior per­for­man­ce: with a new intro­duc­tion (1st Free Press ed). Free Press.
Schmidt, D. C. (2006). COVER FEATURE Model-Driven Engineering.
Š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
Zelinski, J. (2020). Synthesis of MOF, MDA, PIM, MVC, and BCE Notations and Patterns. In Applications and Approaches to Object-Oriented Software Design: Emerging Research and Opportunities (pp. 78 – 89). IGI Global. https://​www​.igi​-glo​bal​.com/​b​o​o​k​/​a​p​p​l​i​c​a​t​i​o​n​s​-​a​p​p​r​o​a​c​h​e​s​-​o​b​j​e​c​t​-​o​r​i​e​n​t​e​d​-​s​o​f​t​w​a​r​e​/​2​3​5​699
Żeliński, J. (2017). Architektura kodu apli­ka­cji jako pierw­szy etap two­rze­nia opro­gra­mo­wa­nia. Materiały pokon­fe­ren­cyj­ne III Ogólnopolskiej Konferencji Interdyscyplinarnej Współczesne zasto­so­wa­nia infor­ma­ty­ki”, 6 – 14. https://​www​.wzi​.uph​.edu​.pl/​o​k​i​w​z​i​3​/​w​p​-​c​o​n​t​e​n​t​/​u​p​l​o​a​d​s​/​2​0​1​7​/​0​9​/​2​017 – 08-22 – 22-22.pdf#page=7
Service orien­ted archi­tec­tu­re Modeling Language (SoaML) – Specification for the UML Profile and Metamodel for Services (UPMS). (n.d.). 167.

Zapytanie