Ministerstwo Cyfryzacji opu­bli­ko­wa­ło Wzorcowe klau­zu­le w umo­wach IT, jest to infor­ma­cja do wer­sji pilo­ta­żo­wej (Opublikowano: 22.11.2017).

Klauzule zosta­ły opra­co­wa­ne na zle­ce­nie Ministra Cyfryzacji przez zespół kan­ce­la­rii MARUTA WACHTA Sp. j. pod kie­row­nic­twem mec. Marcina Maruty i mec. Bartłomieja Wachty. Wykorzystano w nich rów­nież uwa­gi pra­cow­ni­ków admi­ni­stra­cji publicz­nej, zarów­no praw­ni­ków, jak i spe­cja­li­stów z dzie­dzi­ny IT. (źr. https://​www​.gov​.pl/​c​y​f​r​y​z​a​c​j​a​/​w​z​o​r​c​o​w​e​-​k​l​a​u​z​u​l​e​-​w​-​u​m​o​w​a​c​h​-it)

Jako, że w pod­pi­sie napisano:

Bardzo mile widzia­ne są wszel­kie dal­sze komen­ta­rze i uwa­gi do klau­zul. Należy je prze­sy­łać na adres: Klauzule@mc.gov.pl

Więc jako wie­lo­let­ni teo­re­tyk i prak­tyk, poczu­łem się w obo­wiąz­ku takie uwa­gi zgło­sić (te uwa­gi zosta­ły tak­że wysła­ne na powyż­szy adres, odpo­wie­dzi nie otrzymałem). 

Mimo, że to opra­co­wa­nie powsta­ło za pie­nia­dze podatnika…

…zaska­ku­je mnie zapis na stro­nie MC: klau­zu­le nie mogą być wyko­rzy­sty­wa­ne przez przed­się­bior­ców ani oso­by fizyczne”

Po zapo­zna­niu się z doku­men­tem, uzna­łem, że uwa­gi swo­je ogra­ni­czę do pierw­szej czę­ści: Definicje. Zawiera ona defi­ni­cje klu­czo­wych pojęć wraz z komen­ta­rza­mi. Definicje pojęć są klu­czo­we dla zro­zu­mie­nia umów i inter­pre­to­wa­nia ich zapi­sów w ich sto­so­wa­niu, a szcze­gól­nie w przy­pad­ku spo­rów. Innymi sło­wy, wady tej czę­ści umo­wy czy­nią wadli­wą (ryzy­kow­ną) całą umo­wę. Pozwoliłem więc sobie na kil­ka uwag wyłącz­nie do tej czę­ści opracowania.

Pojęcie błąd”

Autorzy reko­men­du­ją jego defi­nio­wa­nie w nastę­pu­ją­cy sposób:

Błąd – nie­pra­wi­dło­we dzia­ła­nie Oprogramowania, nie­za­leż­nie od przy­czy­ny takiej nie­pra­wi­dło­wo­ści. W szcze­gól­no­ści Błędem jest dzia­ła­nie Oprogramowania nie­zgod­nie z Dokumentacją. Błędom przy­pi­sa­ne są kate­go­rie [opcjo­nal­nie: priorytety].

W umo­wach bar­dzo czę­sto spo­ty­kam takie poję­cie błę­du, jed­nak rodzi ono wie­le pro­ble­mów. Słownik języ­ka pol­skie­go poda­je definicje:

błąd
1. nie­zgod­ność z obo­wią­zu­ją­cy­mi regu­ła­mi pisa­nia, licze­nia, wymo­wy itp.
2. nie­wła­ści­we posu­nię­cie
3. fał­szy­we mnie­ma­nie o czymś

Są jed­nak jesz­cze w języ­ku pol­skim w uży­ciu pojęcia:

nie­zgod­ny
1. będą­cy w sprzecz­no­ści z czymś
2. nie­do­bra­ny w porów­na­niu z czymś innym

nie­spraw­ny
1. źle zor­ga­ni­zo­wa­ny
2. nie­dzia­ła­ją­cy w ogó­le lub dzia­ła­ją­cy wadliwie

awa­ria – uszko­dze­nie maszy­ny lub inne­go urzą­dze­nia technicznego

Jak widać, tak­że w potocz­nym rozu­mie­niu, popeł­nie­nie błę­du doty­czy zacho­wań (nie­wła­ści­we posu­nię­cie, fał­szy­we mnie­ma­nie) lub ich skut­ków (uzy­ska­nie złe­go wyni­ku). Oprogramowanie powsta­je w wyni­ku umo­wy o dzie­ło, któ­re to dzie­ło jest w umo­wie wyspe­cy­fi­ko­wa­ne (opi­sa­ne). Tak więc opro­gra­mo­wa­nie może być nie­zgod­ne z wyma­ga­nia­mi, z dołą­czo­ną instruk­cją użyt­kow­nia np. opro­gra­mo­wa­nie może gene­ro­wać błęd­ne wyni­ki np. obli­czeń (istot­ne jest to, czy powsta­ło coś nie­zgod­nie z wyma­ga­nia­mi, czy może jest to ludz­ki błąd auto­ra kodu, to podob­nie jak zama­wia­nie opra­co­wań: struk­tu­ra tre­ści jest nie­zgod­na z zamó­wie­niem, czy w treść wkra­dły się błędy).

Oprogramowanie sta­no­wi tak­że inte­gral­ną część sys­te­mu infor­ma­tycz­ne­go skła­da­ją­ce­go się tak­że ze sprzę­tu, może nim być nie tyl­ko kom­pu­ter słu­żą­cy do pisa­nia lub księ­go­wa­nia ale tak­że linia pro­duk­cyj­na. Człowiek nigdy nie korzy­sta z same­go opro­gra­mo­wa­nia, zawsze jest to jakieś urzą­dze­nie (kom­pu­ter z edy­to­rem tek­stu, pral­ka z opro­gra­mo­wa­niem zamiast pro­gra­ma­to­ra mecha­nicz­ne­go, linia pro­duk­cyj­na z opro­gra­mo­wa­niem ste­ru­ją­cym, tele­fon komór­ko­wy z opro­gra­mo­wa­niem do pro­wa­dze­nia roz­mów czy korzy­sta­nia z Internetu itp.).

Tak więc z per­spek­ty­wy użyt­kow­ni­ka, korzy­sta on z cało­ści urzą­dze­nia, nie wie on czy winą za stwier­dzo­ną nie­pra­wi­dło­wość nale­ży obcią­żyć aku­rat opro­gra­mo­wa­nie (np. pral­ka nie pie­rze, sys­tem finan­so­wo-księ­go­wy nie księ­gu­je). Brak moż­li­wo­ści sko­rzy­sta­nia z tre­ści stron inter­ne­to­wych może być wyni­kiem awa­rii łącza inter­ne­to­we­go, awa­rii kom­pu­te­ra, błę­du kon­fi­gu­ra­cji sie­ci Wi-Fi itp. Dlatego w umo­wach takich bez­piecz­niej jest użyć poję­cia zro­zu­mia­łe­go dla użyt­kow­ni­ka, gdyż wte­dy, nie będąc spe­cja­li­stą, jest on w sta­nie stwier­dzić nie­zgod­ność dostar­czo­ne­go roz­wią­za­nia z opi­sem w umo­wie lub stwier­dzić awa­rię urzą­dze­nia (sys­te­mu). Po dru­gie jed­no urzą­dze­nie może zawie­rać wię­cej niż jed­ną apli­ka­cję, o czym użyt­kow­nik tak­że może nie wie­dzieć i nie będzie w sta­nie popraw­nie (zgod­nie z umo­wą, sku­tecz­nie) zgło­sić takiej wady. Mając tablet łatwo oce­nić czy korzy­sta­jąc z nie­go uległ on awa­rii czy nie, ale stwier­dze­nie błę­du kon­kret­ne­go opro­gra­mo­wa­nia na nim zain­sta­lo­wa­ne­go, może być nie­moż­li­we dla nieprofesjonalisty.

W mojej oce­nie, wyma­ga­nie od użyt­kow­ni­ka rozu­mie­nia dzia­ła­nia deta­li kon­struk­cyj­nych urzą­dze­nia (wska­zy­wa­nie, któ­ra apli­ka­cja «błęd­nie” dzia­ła), któ­re nabył, jest dużym nad­uży­ciem, gdyż prze­wa­ga mery­to­rycz­na jego dostaw­cy, i takie for­mu­ło­wa­nie uste­rek jak w recen­zo­wa­nym doku­men­cie (patrz do źró­dła, na koń­cu arty­ku­łu), powo­du­je trud­ność w dowo­dze­niu przed dostaw­cą tych nie­pra­wi­dło­wo­ści, co auto­rzy sami przy­zna­li w komentarzach.

W kwe­stii two­rze­nia kate­go­rii awa­rii dość powszech­nie przy­ję­tą prak­ty­ką w inży­nie­rii jest trzy­stop­nio­wa oce­na: w wyni­ku awa­rii (1) urzą­dze­nie sta­ło się nie­przy­dat­ne, (2) urzą­dze­nie ma ogra­ni­czo­ne moż­li­wość uży­cia ale zacho­wu­je przy­dat­ność, (3) spadł jedy­nie kom­fort korzy­sta­nia z urzą­dze­nia. Dotyczy to tak­że kom­pu­te­ra z oprogramowaniem.

Pojęcie ?dokumentacja?

Zapewne jest to drob­na spra­wa” ale tyl­ko pozor­nie. W pra­wie ope­ru­je się poję­ciem doku­men­tu (nie tyl­ko elek­tro­nicz­ne­go) a nie ?doku­men­ta­cji? (nie licząc np. pra­wa budow­la­ne­go). Dlatego lepiej jest napi­sać, że ?doku­ment zawierający/opisujący? coś to ?doku­men­ta­cja cze­goś? (doku­men­ta­cja może być doku­men­tem” elek­tro­nicz­nym, papie­ro­wym). Jeżeli mają być sto­so­wa­ne kate­go­rie lub typy doku­men­ta­cji, to logi­ka two­rze­nia tak­so­no­mii naka­zu­je uży­cie typów: doku­men­ta­cja tech­nicz­na, doku­men­ta­cja ana­li­tycz­na, doku­men­ta­cja pro­jek­to­wa. Zamiast więc defi­nio­wać poję­cie ?ana­li­za? lepiej jest for­mu­ło­wać treść zapi­su umo­wy w posta­ci ?doku­ment zawie­ra­ją­cy treść ana­li­zy (jakiej, cze­go)?, bo wte­dy samo ?ana­li­za? nie kwa­li­fi­ku­je ?tego cze­goś? jako doku­men­tu lub ?doku­men­ta­cji?, nie wie­my też czy ana­li­za” jest doku­men­tem czy pra­cą nad jego stwo­rze­niem (przy­ję­te jest w nauce, że ana­li­za i ana­li­zo­wa­nie to pra­ca a nie przed­miot, podob­nie jak ope­ra­cja i operowanie).

Pojęcie oprogramowanie”

Słownik języ­ka polskiego:

opro­gra­mo­wa­nie ?zbiór pro­gra­mów wpro­wa­dzo­nych do kom­pu­te­ra?
pro­gram ?ciąg instruk­cji napi­sa­nych w języ­ku zro­zu­mia­łym dla kom­pu­te­ra?
apli­ka­cja ?kom­pu­te­ro­wy pro­gram użytkowy?

Autorzy wzo­ru jed­nak rekomendują:

Oprogramowanie ? całość lub dowol­ny ele­ment opro­gra­mo­wa­nia dostar­cza­ne­go lub wyko­ny­wa­ne­go w ramach reali­za­cji Umowy.

Nie rozu­miem powo­dów, dla któ­rych w umo­wie, któ­ra w trak­cie spo­ru, będzie z zasa­dy inter­pre­to­wa­na w języ­ku pol­skim, ale też w tym języ­ku intu­icyj­nie będzie pro­wa­dzo­na kore­spon­den­cja pomię­dzy stro­na­mi umo­wy, zmie­nio­no defi­ni­cję słow­ni­ko­wą. Wprowadzanie typów opro­gra­mo­wa­nia: apli­ka­cyj­ne, sys­te­mo­we, dedy­ko­wa­ne, itp.. (bra­ku­je jed­nak dla kon­se­kwen­cji nie­de­dy­ko­wa­ne­go) nie sta­no­wi żad­nej war­to­ści, wręcz zaciem­nia obraz, a o roli tego opro­gra­mo­wa­nia decy­du­ją cechy użyt­ko­we a nie nada­na mu nazwa (np. z per­spek­ty­wy admi­ni­stra­to­ra ser­we­ra apli­ka­cje wspo­ma­ga­ją­ce jego pra­cę są apli­ka­cja­mi użyt­ko­wy­mi, dla prze­cięt­ne­go czło­wie­ka są to ?pro­gra­my admi­ni­stra­cyj­ne?). Po dru­gie wpro­wa­dza­nie takich nazw nie poma­ga a prze­szka­dza w sto­so­wa­niu poję­cia błędu/niezgodności/awarii.

Pojęcie system”, a może jednak rozwiązanie”

I w tym momen­cie wręcz kurio­zal­ne wyda­je się wpro­wa­dze­nie poję­cia sys­tem w brzmieniu:

System ? Oprogramowanie dosto­so­wa­ne do wyma­gań Umowy, w tym wyma­gań funk­cjo­nal­nych i pozafunkcjonalnych

Czyżby opro­gra­mo­wa­nie goto­we z pudeł­ka”, będą­ce przed­mio­tem umo­wy nie było by sys­te­mem (albo jego czę­ścią)? Pojęcie sys­tem w inży­nie­rii ma dość pre­cy­zyj­ne i ogól­niej­sze zna­cze­nie, słow­nik języ­ka pol­skie­go podaje:

sys­tem
1. ?układ ele­men­tów mają­cy okre­ślo­ną struk­tu­rę i sta­no­wią­cy logicz­nie upo­rząd­ko­wa­ną całość?
2. ?zespół wie­lu urzą­dzeń, dróg, prze­wo­dów itp., funk­cjo­nu­ją­cych jako całość?

Tak więc kom­pu­ter z opro­gra­mo­wa­niem, nowo­cze­sna linia pro­duk­cyj­na itp. To są sys­te­my, czę­ścią każ­de­go z nich jest wie­le róż­nych apli­ka­cji, każ­da z nich to pro­gram kom­pu­te­ro­wy. Pojęcie system„od wie­lu lat ma zde­fi­nio­wa­ne, zarów­no nauko­we i bran­żo­we zna­cze­nie: dowol­ny twór poję­cio­wy lub fizycz­ny, skła­da­jąc się z czę­ści wza­jem­nie powią­za­nych i oddzia­ły­wa­ją­cych na sie­bie” (Bertalanffy, Ackof), zbiór ele­men­tów i związ­ków mię­dzy nimi zdol­ny to reali­zo­wa­nia okre­ślo­nych celów” (www​.omg​.org, Model Driven Engineering).

Autorzy piszą, że ?System sta­no­wi dzie­ło w rozu­mie­niu prze­pi­sów kodek­su cywil­ne­go?. Kodeks Cywilny podaje:

Umowa o dzie­ło
Art. 627. Przez umo­wę o dzie­ło przyj­mu­ją­cy zamó­wie­nie zobo­wią­zu­je się do wyko­na­nia ozna­czo­ne­go dzie­ła, a zama­wia­ją­cy do zapła­ty wynagrodzenia.

KC nie defi­niu­je poję­cia dzie­ło, jed­nak słow­nik języ­ka pol­skie­go wyda­je się wystar­cza­ją­co precyzyjny:

dzie­ło
1. ?utwór lite­rac­ki, nauko­wy lub arty­stycz­ny, zwłasz­cza dużej war­to­ści?
3. ?efekt czy­jejś pra­cy lub jakichś procesów?

Ustawa Prawo autor­skie… stwierdza:

Przedmiot pra­wa autor­skie­go
Art. 1. 1. Przedmiotem pra­wa autor­skie­go jest każ­dy prze­jaw dzia­łal­no­ści twór­czej o indy­wi­du­al­nym cha­rak­te­rze, usta­lo­ny w jakiej­kol­wiek posta­ci, nie­za­leż­nie od war­to­ści, prze­zna­cze­nia i spo­so­bu wyra­że­nia (utwór).

Tak więc w pro­sty spo­sób wywo­dzi­my, że każ­dy utwór to dzie­ło (ale uwa­ga: nie każ­de dzie­ło to utwór). Tak więc dzie­łem jest zarów­no doku­men­ta­cja jak i opro­gra­mo­wa­nie (patrz Ustawa o pra­wach autor­skich ?). Jako, że dostar­cze­nie dzia­ła­ją­ce­go sys­te­mu? jest okre­ślo­nym efek­tem, dzia­łać może dopie­ro opro­gra­mo­wa­nie zain­sta­lo­wa­ne na kom­pu­te­rze, wyko­na­nie opro­gra­mo­wa­nia (utwór) i dostar­cze­nie lub zain­sta­lo­wa­nie go na kom­pu­te­rze (dopie­ro) jest dzie­łem (samo opro­gra­mo­wa­nie jako utwór, to tak­że – odręb­ne – dzie­ło). O ile tyl­ko ten efekt (dzie­ło) został pre­cy­zyj­nie opi­sa­ny w doku­men­ta­cji sta­no­wią­cej Opis Przedmiotu Zamówienia (czy­li w umo­wie) jest on przed­mio­tem tej umo­wy. Opis ten musi być jed­nak na tyle pre­cy­zyj­ny, by zama­wia­ją­cy był w sta­nie stwier­dzić ewen­tu­al­ne nie­zgod­no­ści z tym opi­sem, a tak­że stwier­dzić wystą­pie­nie ewen­tu­al­nej awa­rii, czy­li jest w sta­nie stwier­dzić, że dostaw­ca wywią­zał się nale­ży­cie z umowy.

Jak więc nazwać przed­miot umowy? 

Autorzy szu­ka­ją nazwy dla poję­cia Oprogramowanie dosto­so­wa­ne do wyma­gań Umowy, w tym wyma­gań funk­cjo­nal­nych i poza­funk­cjo­nal­nych”. Rzecz w tym, że przed­mio­tem umo­wy może być (i z regu­ły jest) coś znacz­nie bar­dziej zło­żo­ne­go niż opro­gra­mo­wa­nie, bo opro­gra­mo­wa­nie – jak już wyżej napi­sa­no – nigdy samo z sie­bie nie jest czymś dzia­ła­ją­cym”. Nie da się stwier­dzić popraw­no­ści dzia­ła­nia opro­gra­mo­wa­nia bez jego uru­cho­mie­nia na kom­pu­te­rze (w jakimś środowisku), 

dla­te­go samo opro­gra­mo­wa­nie NIGDY nie powin­no być przed­mio­tem umowy!

W bran­ży inży­nier­skiej, w IT tak­że, mówi się o roz­wią­za­niach infor­ma­tycz­nych, któ­re są sys­te­ma­mi (ale sys­tem to poję­cie szer­sze, bo może­my mówić o sys­te­mie ochro­ny zdro­wia, któ­re­go małą czę­ścią będzie oprogramowanie).

Słownik języ­ka pol­skie­go mówi:

roz­wią­za­nie ?pro­jekt i reali­za­cja zało­żeń archi­tek­to­nicz­nych, kon­struk­cyj­nych, pla­stycz­nych itp.?

Skoro więc uznać, że sys­te­my infor­ma­tycz­ne są i do cze­goś słu­żą”, że są wdra­ża­ne z okre­śla­ne­go, czę­sto biz­ne­so­we­go, powo­du, nale­ży więc mówić o roz­wią­za­niach”, bo wyma­ga­nia biz­ne­so­we opi­su­ją roz­wią­za­nie biz­ne­so­we­go pro­ble­mu. Rozwiązaniem” pro­ble­mu (cel biz­ne­so­wy) jest wdro­że­nie opro­gra­mo­wa­nia czy­li jego wytwo­rze­nie, dostar­cze­nie, uru­cho­mie­nie oraz dosto­so­wa­nie do nie­go ist­nie­ją­cych pro­ce­dur, prze­pro­wa­dze­nie szko­leń użyt­kow­ni­ków. Trudno sobie wyobra­zić poważ­ną umo­wę na dostar­cze­nie opro­gra­mo­wa­nia w posta­ci przy­sła­nia pudeł­ka z kodem na nośni­ku. Autorzy wspo­mi­na­ją o SLA, czy­li z góry zakła­da­ją, że przed­mio­tem umo­wy jest wła­śnie całe roz­wią­za­nie” (lub znacz­na jego część) a nie tyl­ko opro­gra­mo­wa­nie dosto­so­wa­ne do wyma­gań Umowy, w tym wyma­gań funk­cjo­nal­nych i pozafunkcjonalnych”.

Tak wiec przed­mio­tem umo­wy, poję­ciem uży­tym do jego nazwa­nia, opi­su­ją­cej nie­try­wial­ny pro­jekt tech­nicz­no-orga­ni­za­cyj­ny, raczej powin­no być sło­wo roz­wią­za­nie.

Na zakończenie

Autorzy piszą:

Definicje są jed­nym z naj­trud­niej­szych do opra­co­wa­nia ele­men­tów umo­wy. Nie ist­nie­ją wypra­co­wa­ne jed­no­znacz­ne stan­dar­dy, defi­ni­cje róż­nią się w zależ­no­ści od pro­jek­tu, a wie­lu pojęć nie da się zde­fi­nio­wać w peł­ni pre­cy­zyj­nie. Podane pro­po­zy­cje powin­ny być dokład­nie zwe­ry­fi­ko­wa­ne i zmo­dy­fi­ko­wa­ne na potrze­by kon­kret­nej umowy.

Należy się zgo­dzić z tym, że defi­nio­wa­nie pojęć jest bar­dzo trud­ne, jed­nak teza, że nie ist­nie­ją stan­dar­dy nie jest praw­dą (auto­rzy w doku­men­cie, prze­cząc sobie, przy­wo­łu­ją stan­dard jakim jest ITIL). Teza, że pew­nych pojęć nie da się zde­fi­nio­wać pre­cy­zyj­nie, jest w moich oczach nad­uży­ciem, gdyż albo w umo­wie poję­cie defi­niu­je­my, co pozwa­la użyć go w celu zacho­wa­nia jed­no­znacz­no­ści tre­ści zapi­sów umo­wy, albo nie nale­ży sto­so­wać tych defi­ni­cji. Definicje pojęć, popraw­nie zbu­do­wa­ne, sta­no­wią kry­te­rium pozwa­la­ją­ce jed­no­znacz­nie zakla­sy­fi­ko­wać np. zda­rze­nie jako awa­rię. Jeżeli defi­ni­cja na to nie pozwa­la, sku­tecz­ne zgło­sze­nie awa­rii sta­je się wąt­pli­we (nie­moż­li­we?).

Wielu auto­rów ksią­żek, nie tyl­ko w bran­ży IT, stan­da­ry­zu­je poję­cia jakich uży­wa w swo­ich opra­co­wa­niach, każ­da bran­ża ma swo­je, wypra­co­wa­ne jako stan­dar­dy lub zale­ce­nia, defi­ni­cje pojęć, część ma swo­je źró­dło w opra­co­wa­niach nauko­wych. Prowadzę i ja taki słow­nik, jest opu­bli­ko­wa­ny, poma­ga mi w komu­ni­ka­cji, tak­że na tym blo­gu: Słownik pojęć. O two­rze­niu defi­ni­cji pojęć pisa­łem tak­że tu: Słownik pojęć biz­ne­so­wych: naj­bar­dziej pod­sta­wo­we wyma­ga­nie.

Projekty inży­nier­skie to pro­jek­ty mul­ti­dy­scy­pli­nar­ne, opi­sa­nie przed­mio­tu umo­wy w pro­jek­tach inży­nier­skich jest trud­ne, dla­te­go moim zda­niem nale­ży przy­kła­dać ogrom­ną wage do pre­cy­zji for­mu­ło­wa­nia tre­ści takich umów. Jestem zda­nia, że podob­nie jak to ma miej­sce w innych dzie­dzi­nach inży­nie­rii, tu (inży­nie­ria opro­gra­mo­wa­nia) tak­że nale­ży sto­so­wać uzna­ne meto­dy opi­su dzie­ła w posta­ci sche­ma­tów blo­ko­wych, gdyż sło­wa­mi nie zawsze łatwo (nie raz jest to wręcz nie­moż­li­we) opi­sać inży­nier­ską kon­struk­cję (sys­tem). Projekty infor­ma­tycz­ne cechu­ją się coraz więk­szą zło­żo­no­ścią. Myślę, że nikt w dzi­siej­szych cza­sach nie wyobra­ża sobie zawar­cia umo­wy na wyko­na­nie inwe­sty­cji budow­la­nej, z uży­ciem wyłącz­nie tek­stu jako opi­su dzie­ła. Jest to prak­tycz­nie nie­moż­li­we. Dlatego brnię­cie w opi­sy tek­sto­we przed­mio­tów umów na dostar­cza­nie nie­try­wial­nych (auto­rzy wspo­mi­na­ją o pro­jek­tach wyso­kiej war­to­ści) sys­te­mów infor­ma­tycz­nych nale­ży dzi­siaj uznać za poważ­ny błąd. Oprogramowanie ma tak­że swo­ją spe­cy­fi­kę: jest to byt wir­tu­al­ny, dla­te­go tym bar­dziej pre­cy­zja sto­so­wa­nych pojęć sta­je się klu­czo­wa dla powo­dze­nia tych projektów.

Dokument recen­zo­wa­ny:
https://​www​.gov​.pl/​d​o​c​u​m​e​n​t​s​/​3​1​3​0​5​/​0​/​u​m​o​w​a​_​w​d​r​o​z​e​n​i​o​w​a​_​z​_​u​s​l​u​g​a​m​i​_​u​t​r​z​y​m​a​n​i​a​_​-​_​w​z​o​r​c​o​w​e​_​k​l​a​u​z​u​l​e​_​k​o​m​e​n​t​a​r​z​_​c​z​_​i​.​pdf

P.S.

Jako ciąg dal­szy pole­cam arty­kuł Opis Przedmiotu Zamówienia ? instruk­cja nie tyl­ko dla praw­ni­ków.

Jarosław Żeliński

Jarosław Żeliński: autor, badacz i praktyk analizy systemowej organizacji: Od roku 1991 roku, nieprzerwanie, realizuje projekty z zakresu analiz i projektowania systemów, dla urzędów, firm i organizacji. Od 1998 roku prowadzi samodzielne studia i prace badawcze z obszaru analizy systemowej i modelowania (modele jako przedmiot badań: ORCID). Od 2005 roku, jako nieetatowy wykładowca akademicki, prowadzi wykłady i laboratoria (ontologie i modelowanie systemów informacyjnych, aktualnie w Wyższej Szkole Informatyki Stosowanej i Zarządzania pod auspicjami Polskiej Akademii Nauk w Warszawie.) Oświadczenia: moje badania i publikacje nie mają finansowania z zewnątrz, jako ich autor deklaruję brak konfliktu interesów. Prawa autorskie: Zgodnie z art. 25 ust. 1 pkt. 1) lit. b) ustawy o prawie autorskim i prawach pokrewnych zastrzegam, że dalsze rozpowszechnianie artykułów publikowanych w niniejszym serwisie jest zabronione bez indywidualnej zgody autora (patrz Polityki Strony).

Dodaj komentarz

Witryna wykorzystuje Akismet, aby ograniczyć spam. Dowiedz się więcej jak przetwarzane są dane komentarzy.