Analiza Potrzeb i Opracowanie Wymagań na Oprogramowanie

  • 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.
  • Koszt: wyma­ga eta­pu Analiza Biznesowa. (20 tys. zł net­to), po zde­fi­nio­wa­niu wyma­gań biz­ne­so­wych i zakre­su wdro­że­nia, opra­co­wy­wa­ny jest Opis Techniczny Oprogramowania. trwa ok. trzech mie­się­cy (koszt ok. 20 – do 40 tys. zł net­to, zależ­nie od tego czy pla­no­wa­ny jest sys­tem goto­wy czy dedy­ko­wa­ny), dal­szy nad­zór autor­ski (bie­żą­ce utrzy­ma­nie i aktu­ali­za­cję, nad­zór mery­to­rycz­ny nad dostaw­cą sys­te­mu, gene­ro­wa­nie na żąda­nie mode­li pro­ce­sów i sys­te­mu z róż­nych per­spek­tyw, mode­le dostęp­ne on-line), od 3 tys. zł net­to miesięcznie. 

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 przed­się­wzię­ciem (źr. PORAŻKA CYFROWEJ TRANSFORMACJI W FIRMIE HERTZ, oryg. : 4 LESSONS FROM THE HERTZ VS. ACCENTURE DISASTER)

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.

Wstęp

Kilka fak­tów:

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.

…ana­li­za wyma­gań i pro­jek­to­wa­nie to jest pra­ca Zamawiającego wyko­na­na by opi­sać to cze­go ocze­ku­je­my. UWAGA! Zgodnie z regu­la­cją zawar­tą w art. 24 ust. 1 pkt 19 Pzp, z postę­po­wa­nia o udzie­le­nie zamó­wie­nia wyklu­cza się wyko­naw­cę, któ­ry brał udział w przy­go­to­wa­niu tego postę­po­wa­nia lub któ­re­go pra­cow­nik, a tak­że oso­ba wyko­nu­ją­ca pra­cę na pod­sta­wie umo­wy zle­ce­nia, o dzie­ło, agen­cyj­nej lub innej umo­wy o świad­cze­nie usług, bra­ły udział w przy­go­to­wa­niu takie­go postę­po­wa­nia (art. 24, utp 1 i 19 PZP)

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łowami:

Problem pole­gał na tym, że dostar­czo­no nam dokład­nie to co chcie­li­śmy, a nie to co jest nam potrzebne. 

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 , zaś dostaw­ca, robiąc ana­li­zę wyma­gań, ma potęż­ny kon­flikt inte­re­su spe­cy­fi­ku­jąc wyma­ga­nia na wła­sny pro­dukt: dostar­czy to co ma, a nie to cze­go potrze­bu­je zama­wia­ją­cy. Skuteczne meto­dy audy­tu i ana­li­zy to bada­nie fak­tów i doku­men­tów oraz mode­lo­wa­nie. Specyfikacje opra­co­wa­ne jako zebra­ne wyma­ga­nia wyra­żo­ne jeży­kiem natu­ral­nym nigdy nie są kom­plet­ne i zawsze niespójne:

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.

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.

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 nie­pew­no­ś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ń

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

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: Projekt Techniczny jako Opis Przedmiotu Zamówienia

Wymagania na opro­gra­mo­wa­nie to obec­nie pro­jek­to­wa­nie apli­ka­cji inter­ne­to­wych… 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. .

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

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)

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.

    Zapytanie Ofertowe

    Chcę być infor­mo­wa­ny o nowo­ściach na stro­nie fir­my IT​-Consulting​.pl

    Ź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.
    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.
    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
    OMG​.org. (2014, June 18). Model Driven Architecture (MDA). 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
    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
    Żeliński, J. (2017). Analiza biz­ne­so­wa: prak­tycz­ne mode­lo­wa­nie orga­ni­za­cji (Grupa Wydawnicza Helion, Ed.). Wydawnictwo Helion.
    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.

    Ostatnia aktu­ali­za­cja: lip 29, 2022 @ 15:36