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.

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.

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 to ana­li­za sta­nu fak­tycz­ne­go (audyt orga­ni­za­cji). Na tym eta­pie nale­ży udo­ku­men­to­wać model biz­ne­so­wy i biz­ne­so­we cele pro­jek­tu (nie raz tak­że osza­co­wać budżet).

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

Projekt Techniczny: 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) wysy­łam na listę sub­skry­ben­tów moje­go ser­wi­su i publi­ku­ję na swo­im pro­fi­le LinkedIn (patrz nagłó­wek strony).

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 oferuję.

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. 

    Zapytanie Ofertowe

    Ź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.
    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.
    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: kw. 4, 2022 @ 09:15