Prawo autorskie w projektach IT

Ten arty­kuł to pew­ne­go rodza­ju kon­ty­nu­acja poprzed­nie­go: Vendor lock-in. Starałem się tu wyja­śnić czym jest pro­jekt i wska­zać, że pew­ne wywo­dy praw­ni­ków wyda­ją się nie mieć żad­ne­go uzasadnienia. 

Prawo autorskie

Pomysł, aby ochro­nę roz­wią­zań bran­ży IT oprzeć na pra­wie autor­skim nie był spe­cjal­nie szczę­śli­wy. Prawo autor­skie stwo­rzo­no z myślą o twór­cach oraz odbior­cach. (źr.: Prawa autor­skie w pro­jek­tach IT. Głównie o róż­ni­cach mię­dzy prze­nie­sie­niem praw a licen­cja­mi)

Zaskakuje mnie taka teza, bo pra­wo autor­skie, jak sama nazwa wska­zu­je, stwo­rzo­no z myślą o auto­rach. To, że ta kon­kret­na usta­wa zawie­ra wie­le odnie­sień np. do muzy­ki nie zmie­nia fak­tu, że regu­lu­je wszel­kie prze­ja­wy twór­czej dzia­łal­no­ści o indy­wi­du­al­nym cha­rak­te­rze”. Ta usta­wa dosko­na­le sobie radzi z każ­dą inży­nie­rią, i uwa­żam, że inży­nie­ria opro­gra­mo­wa­nia nie jest tu żad­nym wyjąt­kiem. Być może Pan Maruta dzia­ła tu jako lob­by­sta edżaj­lo­wych pro­gra­mi­stów”, cze­mu chy­ba daje wyraz, np. tu:

Wdrożenia sys­te­mów infor­ma­tycz­nych to zde­cy­do­wa­nie jed­ne z naj­bar­dziej skom­pli­ko­wa­nych przed­się­wzięć w bran­ży IT. Ta oczy­wi­sta oczy­wi­stość znaj­du­je swo­je potwier­dze­nie cho­ciaż­by w kosz­tach zwią­za­nych z reali­za­cją wdro­żeń oraz ska­lą ryzy­ka wyni­ka­ją­cą z ewen­tu­al­ne­go nie­po­wo­dze­nia pro­jek­tów wdro­że­nio­wych. (źr.: Jak pisać umo­wy dla pro­jek­tów IT reali­zo­wa­nych w mode­lu Agile? Cz. I.)

Słowa oczy­wi­sta oczy­wi­stość” to czę­sty wybieg reto­rycz­ny praw­ni­ków, mówią­cy roz­mów­cy nawet nie pró­buj pod­wa­żać tego co powie­dzia­łem”. Otóż nie­ste­ty wiel­ko­ści budże­tów nie są jakieś spe­cjal­nie wiel­kie na tle innych inży­nie­rii (Pan Maruta stra­szy kil­ko­ma ewe­ne­men­ta­mi, rzecz w tym, że podał przy­kła­dy głów­nie złe­go zarzą­dza­nia zakre­sem pro­jek­tów), a ska­la ryzy­ka pro­jek­tów IT jest dale­ko mniej­sza, bo nie­po­wo­dze­nia pro­jek­tów IT nie powo­du­ją np. ofiar w ludziach jak w przy­pad­ku kata­strof budow­la­nych czy komu­ni­ka­cyj­nych. A więc nie jest to żad­na oczy­wi­sta oczywistość”. 

Teza Pana Maruty i jego wywo­dy o IT natych­miast przy­po­mnia­ły mi inny arty­kuł (pole­cam):

TWÓJ PRAWNIK ROZUMIE KONTRAKT LEPIEJ NIŻ TWOI LUDZIE Z BIZNESU? COŚ TU JEST NIE TAK (źr.: https://www.linkedin.com/pulse/tw%C3%B3j-prawnik-rozumie-kontrakt-lepiej-ni%C5%BC-twoi-ludzie-warchol-lewicka/ )

Teza auto­ra (Marcin Maruta): Pomysł, aby ochro­nę roz­wią­zań bran­ży IT oprzeć na pra­wie autor­skim nie był spe­cjal­nie szczę­śli­wy”, jest co naj­mniej nie­zro­zu­mia­ła, a sam autor jej nie uza­sad­nia. Autor wska­zu­je na rosną­cą kom­pli­ka­cje tego pra­wa, ale nie­ja­ko sam wska­zu­je źró­dło: lob­bing pra­co­daw­ców w celu zła­go­dze­nia ochro­ny twór­ców (auto­rów czy­li ich pra­cow­ni­ków: pro­gra­mi­stów, pro­jek­tan­tów, archi­tek­tów opro­gra­mo­wa­nia). Ten wątek pozo­sta­wię bez komentarza. 

USTAWA z dnia 4 lute­go 1994 r. o pra­wie autor­skim i pra­wach pokrew­nych , mówi mie­dzy innymi: 

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

To zna­czy, że istot­ny jest indy­wi­du­al­ny cha­rak­ter czy­li uni­kal­ność powsta­łej tre­ści, nie jest istot­ny spo­sób jej wyra­że­nia (tekst, rysun­ki, głos), istot­ny jest fakt jej utrwa­le­nia (usta­le­nie). Artykuł ten jest bar­dzo istot­ny, bo zapis ten cał­ko­wi­cie abs­tra­hu­je od bran­ży, zasto­so­wa­nia i przy­dat­no­ści utwo­ru. Coś jest utwo­rem bo jest uni­kal­ne i powsta­ło w wyni­ku twór­czej (a więc celo­wej) dzia­łal­no­ści czło­wie­ka (czło­wie­ka bo Prawo doty­czy ludzi). Ustawa mówi wprost: 

2. W szcze­gól­no­ści przed­mio­tem pra­wa autor­skie­go są utwo­ry:
1) wyra­żo­ne sło­wem, sym­bo­la­mi mate­ma­tycz­ny­mi, zna­ka­mi gra­ficz­ny­mi
(lite­rac­kie, publi­cy­stycz­ne, nauko­we, kar­to­gra­ficz­ne oraz pro­gra­my
kom­pu­te­ro­we);[…]

3. Utwór jest przed­mio­tem pra­wa autor­skie­go od chwi­li usta­le­nia, cho­ciaż­by miał postać nieukończoną

Jak widać for­ma (treść lite­rac­ka, sche­ma­ty, wzo­ry mate­ma­tycz­na, pro­gram kom­pu­te­ro­wy itp.) nie ma żad­ne­go zna­cze­nia, liczy się wyłącz­nie fakt zma­te­ria­li­zo­wa­nia się utwo­ru w jakiej­kol­wiek postaci. 

Art. 2. 1. Opracowanie cudze­go utwo­ru, w szcze­gól­no­ści tłu­ma­cze­nie,
prze­rób­ka, adap­ta­cja, jest przed­mio­tem pra­wa autor­skie­go bez uszczerb­ku dla pra­wa do utwo­ru pier­wot­ne­go.
2. Rozporządzanie i korzy­sta­nie z opra­co­wa­nia zale­ży od zezwo­le­nia twór­cy utwo­ru pier­wot­ne­go (pra­wo zależ­ne), chy­ba że autor­skie pra­wa mająt­ko­we do utwo­ru pier­wot­ne­go wyga­sły. W przy­pad­ku baz danych speł­nia­ją­cych cechy utwo­ru zezwo­le­nie twór­cy jest koniecz­ne tak­że na spo­rzą­dze­nie opracowania

Tu waż­na uwa­ga: moż­na bez pro­ble­mu opra­co­wy­wać cudze utwo­ry do szu­fla­dy”, jed­nak jakie­kol­wiek roz­po­rzą­dza­nie takim opra­co­wa­niem (nawet publi­ka­cja), wyma­ga już zgo­dy auto­ra utwo­ru pier­wot­ne­go. To bar­dzo istot­ne, bo w inży­nie­rii reali­za­cje są opra­co­wa­niem ich pro­jek­tu. Tak jak budow­la jest reali­za­cją jej pro­jek­tu wyko­na­ne­go na desce kre­ślar­skiej, tak opro­gra­mo­wa­nie może być reali­za­cją (opra­co­wa­niem) pro­jek­tu logi­ki dzia­ła­nia i archi­tek­tu­ry opro­gra­mo­wa­nia wyra­żo­nych sło­wem, sym­bo­la­mi mate­ma­tycz­ny­mi, zna­ka­mi gra­ficz­ny­mi” (parz tak­że ).

Innymi sło­wy jeże­li pro­gram powstał bez takie­go pro­jek­tu, jest on fak­tycz­nie samo­dziel­nym utwo­rem pro­gra­mi­sty (co zresz­tą bar­dzo czę­sto ma miej­sce). Jeżeli jed­nak pro­gram (opro­gra­mo­wa­nie, apli­ka­cja) powstał jako opra­co­wa­nie pro­jek­tu wyra­żo­ne­go w for­mie j.w. (sche­ma­ty blo­ko­we, wzo­ry, tabli­ce, algo­ryt­my itp. ) jest wyłącz­nie imple­men­ta­cją (efekt sta­ran­ne­go dzia­ła­nia), lub utwo­rem zależ­nym, jeże­li autor oddał pew­ną okre­ślo­ną swo­bo­dę pro­ga­mi­ście. To, że to jest to rzad­ka sytu­acja (ist­nie­nie pro­jek­tu), nie zmie­nia fak­tu, że jest pro­gram nie jest tu utwo­rem a wyko­na­niem utwo­ru .

Rzesze pro­gra­mi­stów (i ich praw­ni­ków) zwal­cza­ją tą tezę bo ude­rza ona w ich monopol. 

Uważam, że orzecz­nic­two jest jed­nak po stro­nie pro­jek­tan­tów i archi­tek­tów sys­te­mów, w tym opro­gra­mo­wa­nia. Więcej o tym zagad­nie­niu napi­sa­łem w arty­ku­le Ochrona know-how. Tu sku­pię się na pro­jek­cie opro­gra­mo­wa­nia jako samo­dziel­nym i peł­no­praw­nym utwo­rze będą­cym spe­cy­fi­ka­cją opro­gra­mo­wa­nia jakie ma powstać (pro­jekt jako wymaganie).

Projektowanie

Zacznijmy od pro­ste­go przy­kła­du i słyn­ne­go zara­zem wyna­laz­ku i paten­tu (w USA). Poniższy rysu­nek to model (spe­cy­fi­ka­cja) mecha­ni­zmu dzia­ła­nia regu­la­to­ra. Nie jest to nawet rysu­nek tech­nicz­ny wyko­naw­czy. Jest to utwór w rozu­mie­niu usta­wy, bo: sta­no­wi prze­jaw dzia­łal­no­ści twór­czej o indy­wi­du­al­nym cha­rak­te­rze, usta­lo­ny zna­ka­mi gra­ficz­ny­mi. Nie mniej jed­nak sta­no­wi bar­dzo pre­cy­zyj­ny opis mecha­ni­zmu dzia­ła­nia odśrod­ko­we­go regu­la­to­ra obrotów. 

PODSTAWY CYBERNETYKI REGULACJA PROCESÓW FIZJOLOGICZNYCH - ppt video online  pobierz

Poniższe zdję­cie to jed­na z wie­lu moż­li­wych imple­men­ta­cji (opra­co­wa­nia) powyż­sze­go mecha­ni­zmu. I co cie­ka­we, udo­wod­nie­nie, że jest to imple­men­ta­cja (utwór zależ­ny) mecha­ni­zmu opi­sa­ne­go powy­żej, nie zaj­mie żad­ne­mu sądo­wi zbyt wie­le czasu. 

Historia automatyki - Wikiwand

Tak więc jed­no jest tu pew­ne: kon­kret­na kon­struk­cja na zdję­ciu powy­żej jest opra­co­wa­niem utwo­ru jakim jest sche­mat opi­su­ją­cy mecha­nizm dzia­ła­nia odśrod­ko­we­go regu­la­to­ra obro­tów Watta. I nie­za­leż­nie od tego ile wła­snej inwen­cji wło­żył w to inży­nier kon­struk­tor tego kon­kret­ne­go regu­la­to­ra, jest to – kon­struk­cja na zdję­ciu – utwór zależ­ny. Poniżej inna kon­struk­cja (imple­men­ta­cja) tego same­go mecha­ni­zmu, to tak­że jest utwór zależny. 

Regulator odśrodkowy obrotów silnika rozbryzgiwacz oleju Briggs 691968 -  skladczesci.pl

Pewną cie­ka­wost­ką jest sta­no­wi­sko pol­skie­go usta­wo­daw­cy, mówią­ce że: 

Art. 28 pkt. 5 usta­wy o wła­sno­ści prze­my­sło­wej sta­no­wi, iż za wyna­la­zek nie może być uzna­wa­ny ?pro­gram do maszyn cyfro­wych?. Wynika z tego jasno, iż pro­gram kom­pu­te­ro­wy nie może być zatem zgło­szo­ny do wła­ści­we­go urzę­du paten­to­we­go celem jego reje­stra­cji i uzy­ska­nia sto­sow­ne­go paten­tu. Autorzy pro­gra­mu kom­pu­te­ro­we­go mogą pró­bo­wać jedy­nie opa­ten­to­wać wyna­la­zek, któ­ry wspo­ma­ga­ny jest pro­gra­mem kom­pu­te­ro­wym, nie­zbęd­nym do jego pra­wi­dło­we­go funk­cjo­no­wa­nia. (źr.: Ochrona praw­na pro­gra­mów kom­pu­te­ro­wych)

Absolutnie nie jestem zwo­len­ni­kiem paten­to­wa­nia opro­gra­mo­wa­nia, a nawet gene­ral­nie jestem prze­ciw­ni­kiem paten­tów, czy­li trwa­łych mono­po­li na wyna­laz­ki ludz­kie. Skąd teza mówią­ca, że za wyna­la­zek nie może być uzna­wa­ny ?pro­gram do maszyn cyfro­wych?”?. Wydaje się ona nielogiczna.

Popatrzmy na to. Poniżej zdję­cie mecha­ni­zmu mecha­nicz­ne­go pro­gra­ma­to­ra pral­ki: zawie­ra sil­nik i tak zwa­ne krzyw­ki ste­ru­ją­ce sty­ka­mi sterownika. 

Mechaniczny pro­gra­ma­tor pralki

Identyczne funk­cje, jako mecha­nizm ste­ru­ją­cy, reali­zu­je poniż­szy nowo­cze­sny ste­row­nik będą­cy tak na praw­dę kom­pu­te­rem (mikro­kon­tro­ler)

Programator pralki Aquamatic AQUA 100 +blokada+ silnik Sosnowiec -  Sprzedajemy.pl
Mikrokontroler peł­nią­cy funk­cję pro­gra­ma­to­ra pral­ki automatycznej. 

W pew­nych obsza­rach mecha­nizm wyko­na­ny (opra­co­wa­ny, wyna­le­zio­ny) jako kon­struk­cja mecha­nicz­na (moż­li­wa do opa­ten­to­wa­nia) może być zre­ali­zo­wa­ny w 100% z uży­ciem kom­pu­te­ra: mecha­nicz­ny aryt­mo­metr został zastą­pio­ny elek­tro­nicz­nym kal­ku­la­to­rem (to jest kom­pu­ter), mecha­nicz­ny zegar tak­że pro­gra­mem kom­pu­te­ra (czy­taj tak­że Model czy abs­trak­cja). Ładnie to opi­su­je autor publi­ka­cji nauko­wej zaty­tu­ło­wa­nej Komputer jako uni­wer­sal­ny mecha­nizm . Innymi słowy: 

sko­ro kom­pu­ter to pro­ce­sor, pamięć i pro­gram, i sko­ro 100% reali­zo­wa­nych funk­cji kom­pu­te­ra reali­zu­je pro­gram, to zna­czy sam pro­gram, bez wzglę­du na for­mę jego wyra­zu, z zasa­dy jest tu kom­plet­nym opi­sem mecha­ni­zmu dzia­ła­nia, pod­le­ga­ją­cym poten­cjal­nie ochro­nie praw­no-autor­skiej i/lub know-how.

Dokładnie z tego same­go powo­du gar­nek nie jest inte­gral­ną czę­ścią chro­nio­ne­go prze­pi­su potra­wy kuli­nar­nej (a są one chro­nio­ne pra­wem np. jako pro­duk­ty spo­żyw­cze regio­nal­ne, np. takie jak oscypek). 

Od dekad mamy do czy­nie­nia z postę­pem tech­no­lo­gii gdzie jeden z obsza­rów inży­nie­rii: sze­ro­ko poję­te sys­te­my ste­ro­wa­nia, jest sys­te­ma­tycz­nie pochła­nia­ny przez kom­pu­te­ry. Mechaniczne kon­struk­cje takie jak sys­te­my zli­cza­ją­ce, cza­so­mie­rze, kal­ku­la­to­ry, ste­ro­wa­nie opar­te o cię­gna, sys­te­my auto­ma­ty­ki, sys­te­my zobra­zo­wa­nia (np. wska­zów­ko­we: moni­tor zamiast mecha­nicz­ne­go wskaź­ni­ka) itp. są zastę­po­wa­ne przez kom­pu­ter (rozu­mia­ny jako pro­ce­sor, pamięć i pro­gram). Kolejne kon­struk­cje, do nie­daw­na wyłącz­nie mecha­nicz­ne, są zastę­po­wa­ne kom­pu­te­rem (patrz tak­że nie­daw­ny arty­kuł: Inteligentna pral­ka czy­li czym jest mecha­tro­ni­ka). Proces ten postę­pu­je, powsta­ła nota­cja (roz­sze­rze­nie UML) pozwa­la­ją­ca na mode­lo­wa­nie (spe­cy­fi­ko­wa­nie) takich mie­sza­nych kon­struk­cji: SysML:

Wszystkie powyż­sze kon­struk­cje są chro­nio­ne pra­wem autor­skim, jako ich pro­jek­ty wyko­na­ne w posta­ci udo­ku­men­to­wa­nych (usta­lo­nych) opi­sów (spe­cy­fi­ka­cji) wyko­na­nych z uży­ciem sche­ma­tów blo­ko­wych, zapi­sów związ­ków logicz­nych i wzo­rów mate­ma­tycz­nych. Tak więc teza, jako­by opro­gra­mo­wa­nie wyma­ga­ło jakie­goś inne­go spe­cjal­ne­go podej­ścia, jest moim zda­niem nie do obro­ny: jeże­li kom­pu­ter (czy­li tak­że pro­gram) może być rów­no­praw­nym funk­cjo­nal­nie zamien­ni­kiem kon­struk­cji mecha­nicz­nej (co wyka­za­no powy­żej), to zna­czy że moż­na wobec nie­go i kon­struk­cji mecha­nicz­nych, sto­so­wać te same zapi­sy w prawie. 

Podsumowanie

Czy moż­li­we jest więc opra­co­wa­nie spe­cy­fi­ka­cji dla wyko­na­nia opro­gra­mo­wa­nia, ana­lo­gicz­nej jak dla urzą­dze­nia mecha­nicz­ne­go? Oczywiście! Powyższa pozy­cja lite­ra­tu­ry to jed­na z wie­lu tego typu. Na tym blo­gu jest wie­le przy­kła­dów takich spe­cy­fi­ka­cji. Stawianie tezy, że jedy­ną moż­li­wą for­mą usta­le­nia opro­gra­mo­wa­nia jest kod źró­dło­wy, nie ma żad­ne­go uza­sad­nie­nia w fak­tach: mamy na świe­cie ogrom­ną ilość doku­men­ta­cji sta­no­wią­cej pre­cy­zyj­ną spe­cy­fi­ka­cje opro­gra­mo­wa­nia jakie ma powstać. Oczywiście nie ma obo­wiąz­ku two­rze­nia takich doku­men­tów (meto­dy nazy­wa­ne agi­le) ale po pierw­sze jest to moż­li­we, po dru­gie jest to jed­nak nadal naj­sku­tecz­niej­sza meto­da zama­wia­nia opro­gra­mo­wa­nia. Panu Marucie, świet­ne­mu praw­ni­ko­wi, pole­cam jed­nak kon­fron­to­wa­nie poglą­dów pro­gra­mi­stów któ­rych repre­zen­tu­je, z dostęp­ną lite­ra­tu­rą i nauko­wą i popu­lar­ną z zakre­su inży­nie­rii opro­gra­mo­wa­nia oraz orzecz­nic­two w tym zakre­sie, np. poniższe: 

Dokumentacja i inne mate­ria­ły doty­czą­ce pro­jek­to­wa­nia pro­gra­mu kom­pu­te­ro­we­go nale­ży trak­to­wać jako pro­gram kom­pu­te­ro­wy (imple­men­ta­cja dyrek­ty­wy Parlamentu Europejskiego i Rady 2009/24/WE dnia 23 kwiet­nia 2009 (wer­sja ujed­no­li­co­na dyrek­ty­wy Rady Wspólnoty Europejskich nr 91/250 z dnia 14 maja 1991): ?dla celów niniej­szej dyrek­ty­wy poję­cie ?pro­gram kom­pu­te­ro­wy? obej­mu­je rów­nież przy­go­to­waw­cze pra­ce pro­jek­to­we i mate­riał projektowy?.

Co potwier­dza­ją tak­że auto­rzy naj­now­szych publi­ka­cji nauko­wych, np. 

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

Podsumowując: moż­li­we jest opra­co­wa­nie doku­men­ta­cji opro­gra­mo­wa­nia opi­su­ją­cej (wyma­ga­ny) mecha­nizm jego dzia­ła­nia i archi­tek­tu­rę. Oprogramowanie powsta­łe na bazie takiej doku­men­ta­cji to imple­men­ta­cja pro­jek­tu i sta­no­wi ono utwór zależ­ny w sto­sun­ku do utwo­ru jakim jest pier­wot­na spe­cy­fi­ka­cja. Prawo autor­skie jest tu wręcz dosko­na­łym mecha­ni­zmem kon­tro­l­nym nad wyko­naw­cą opro­gra­mo­wa­nia: mając pra­wa mająt­ko­we do pro­jek­tu tech­nicz­ne­go, z zasa­dy dys­po­nu­je­my w peł­ni opro­gra­mo­wa­niem wyko­na­nym na nasze zamó­wie­nie i na pod­sta­wie takiej doku­men­ta­cji. Jeżeli dostaw­ca stwo­rzy zamó­wio­ne opro­gra­mo­wa­nie ina­czej bo po swo­je­mu, to zna­czy tyl­ko tyle, nie zre­ali­zo­wał zawar­tej umo­wy i nie nale­ży mu płacić. 

Tak zwa­ne pro­jek­ty «agi­le» to cał­ko­wi­ty brak kon­tro­li nad wyko­naw­cą i nad wła­snym know-how. Trudno się więc dzi­wić, że jest to meto­da for­so­wa­na przez dostaw­ców opro­gra­mo­wa­nia i ich prawników. 

(pole­cam tak­że ana­lo­gicz­ny pra­wo­moc­ny wyrok doty­czą­cy muzy­ków gra­ją­cych z nut pod dyk­tan­do dyry­gen­ta)

Źródła

Wolak, G. J. (2019). Umowa o dzie­ło jako zobo­wią­za­nie rezul­ta­tu. https://​doi​.org/​1​0​.​3​4​6​9​7​/​2​451 – 0807-SP-2019 – 1‑006
Murawski, R. (Ed.). (2015). Filozofia mate­ma­ty­ki i infor­ma­ty­ki. Copernicus Center Press.
Friedenthal, S., Moore, A., & Steiner, R. (2009). OMG Systems Modeling Language (OMG SysMLTM) Tutorial September, 2009. 132.
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

Opis Przedmiotu Zamówienia – instrukcja nie tylko dla prawników

Podobno każ­dy lubi zupę pomi­do­ro­wą. Podobno każ­dy potra­fi odróż­nić dobrą pomi­do­rów­kę od innych zup. Podobno każ­dy od cza­su do cza­su ma ocho­tę na pomi­do­rów­kę. Bardzo wie­le osób potra­fi jakoś tam opi­sać jaka ta pomi­do­rów­ka powin­na być: lek­ko kwa­sko­wa­ta i pikant­na, kon­sy­sten­cja tłu­ste­go roso­łu, wyraź­ny smak pomi­do­rów, poda­na z ryżem, maka­ro­nem lub łazan­ka­mi, raczej gorą­ca. I teraz naj­waż­niej­sze: jakie zna­cze­nie dla samej pomi­do­rów­ki ma to czy: zamó­wi­my ją w restau­ra­cji, zamó­wi­my z dosta­wą do domu czy sami zro­bi­my? W kwe­stii samej pomi­do­rów­ki nie ma to żad­ne­go zna­cze­nia. Do roz­wa­że­nia jest tyl­ko to czy potra­fi­my ją sami ugo­to­wać, czy mamy na to czas, czy mamy budżet na gotow­ca z dosta­wą do domu czy może mamy czas i budżet na wizy­tę w dobrej restau­ra­cji. Jednak gene­ral­nie jest to cały czas ta sama pomi­do­rów­ka (na razie pomi­jam pecha ze złym kucha­rzem ale tu jeste­śmy trosz­kę bezbronni).

Wniosek jest jeden: na samym począt­ku i dłu­go jesz­cze, a cza­sem nigdy, nie ma żad­ne­go zna­cze­nia czy ta pomi­do­rów­ka będzie robio­na dla nas czy nala­na z wiel­kie­go gara: opi­su­jąc ją będzie to zawsze taki sam opis. Po pro­stu raz jest taniej a raz dro­żej, raz szyb­ciej a raz trze­ba pocze­kać. Wiemy dla­cze­go, i nie zale­ży to od opi­su pomi­do­rów­ki, bo zawsze jej smak jest taki sam.

Umowy

Od lat spo­ty­kam się w tej (IT) bran­ży z, cza­sa­mi bar­dzo kurio­zal­ny­mi, kon­struk­cja­mi praw­ny­mi przed­mio­tu umo­wy” w umo­wach jakie ser­wu­ją moim klien­tom dostaw­cy opro­gra­mo­wa­nia. Postanowiłem jed­nak nie komen­to­wać tu tych umów, posta­no­wi­łem napi­sać instruk­cję” wraz z uza­sad­nie­niem. Bo oka­zu­je się, że pra­wie nikt nie ma pro­ble­mu z pomi­do­rów­ką ale wie­lu ma pro­blem z opro­gra­mo­wa­niem, któ­re się w pew­nych kwe­stiach niczym od pomi­do­rów­ki nie różni.

Na począ­tek jed­nak sche­mat blo­ko­wy, na któ­rym zobra­zu­je­my nasz przed­miot dywagacji.

Opis dia­gra­mu

Aplikacja jest opi­sa­na w doku­men­cie Specyfikacja opro­gra­mo­wa­nia, jest reali­za­cją tej Specyfikacji. Dokument ten zawie­ra opis tego, czym jest Aplikacja, czy­li to jakie usłu­gi świad­czy ona użyt­kow­ni­kom i innym (zewnętrz­nym) apli­ka­cjom. Każdy byt zewnętrz­ny w sto­sun­ku do Aplikacji jest na tym dia­gra­mie akto­rem. Byt korzy­sta­ją­cy bez­po­śred­nio z usług Aplikacji, jest akto­rem TEJ Aplikacji. GUI ozna­cza, że Użytkownik to czło­wiek korzy­sta­ją­cy z niej za pośred­nic­twem inter­fej­su użyt­kow­ni­ka”. API ozna­cza, że Aplikacja_3 korzy­sta z usług Aplikacji (jest zin­te­gro­wa­na) za pośred­nic­twem inter­fej­su pro­gra­mi­stycz­ne­go. Aplikacja jest uza­leż­nio­na od Interesariusza 2, podob­nie jak Aplikacja 1. Działanie Aplikacji (opro­gra­mo­wa­nia) jest uza­leż­nio­ne od dostę­pu do Aplikacji 1 i Aplikacji 2 (i nie świad­czy im żad­nych usług ze swo­jej stro­ny). Interesariusz 2 i Interesariusz 4 są ze sobą zwią­za­ni Umową. Specyfikacja opro­gra­mo­wa­nia, podob­nie jak Kod pro­gra­mu, ma trwa­ły zwią­zek z Umową.

Specyfikacja opro­gra­mo­wa­nia to doku­ment zawie­ra­ją­cy jed­no­znacz­ny opis zacho­wa­nia się Aplikacji i mecha­nizm jej dzia­ła­nia. W tym miej­scu infor­ma­cja dla praw­ni­ków: taki opis jest moż­li­wy do wyko­na­nia, podob­nie jak moż­li­wy jest do wyko­na­nia opis maszy­ny do szy­cia czy wago­nu kole­jo­we­go. Specyfikacja ta – jej treść – nie zale­ży w jakim­kol­wiek stop­niu od tego, kto jest jej wła­ści­cie­lem i użyt­kow­ni­kiem (od akto­rów na tym dia­gra­mie), nie zale­ży tak­że od tre­ści Umowy.

Kod pro­gra­mu to tekst nio­są­cy okre­ślo­ną treść, sta­no­wią­cy wraz z nośni­kiem, mate­rial­ny byt ana­lo­gicz­nie jak np. książ­ka czy obraz.

Na dia­gra­mie poka­za­no róż­ne, wyżej opi­sa­ne, związ­ki (nie nazwa­ne, ich nazwy zale­żą od kon­kret­nej sytu­acji) pomię­dzy ele­men­ta­mi dia­gra­mu. Pomogą nam one w dal­szej części.

Prawny status oprogramowania”

W prze­strze­ni publicz­nej toczą się spo­ry co do tego czym jest opro­gra­mo­wa­nie”, jed­nak moim zda­niem, więk­szość tych spo­rów ma swo­je źró­dła w nie­zro­zu­mie­niu spe­cy­fi­ki tech­no­lo­gii infor­ma­tycz­nych i same­go pra­wa, część jest skut­kiem celo­we­go lub nie, mata­cze­nia w samych umowach.

Ustawodawca, moim zda­niem bar­dzo słusz­nie, zakwa­li­fi­ko­wał opro­gra­mo­wa­nie do utwo­rów lite­rac­kich, gdyż w swej isto­cie jest ono zawsze zapi­sem ana­lo­gicz­nym do tek­stu. Osobną kwe­stią jest treść tkwią­ca w takim utwo­rze (o czym on jest), co podob­nie jak w przy­pad­ku lite­rac­kich tek­stów, może mieć ale nie musi, zna­cze­nie. Tekst Kodu pro­gra­mu zin­ter­pre­to­wa­na przez odpo­wied­nią maszy­nę, potocz­nie zwa­ną kom­pu­te­rem, decy­du­je o tym czym dany kom­pu­ter jest”. Raz jest pro­gra­ma­to­rem pral­ki a raz edy­to­rem tek­stu czy grą inte­rak­tyw­ną. Oprogramowanie czę­sto cechu­je się okre­ślo­nym mecha­ni­zmem dzia­ła­nia”. W lite­ra­tu­rze z obsza­ru tech­nik kom­pu­te­ro­wych i filo­zo­fii, bar­dzo czę­sto moż­na spo­tkać teo­rię mówią­cą, że kom­pu­ter to uni­wer­sal­ny mecha­nizm”. Innymi sło­wy kom­pu­ter może być czym­kol­wiek”, decy­du­je o tym pro­gram kom­pu­te­ro­wy”. Podam przykład.

Zegar to przy­rząd wska­zu­ją­cy aktu­al­ną godzi­nę. Chyba każ­dy czy­ta­ją­cy ten tekst spo­tkał się w swo­im życiu z wie­lo­ma wer­sja­mi tego przy­rzą­du. To co obser­wu­je­my na swo­ich nad­garst­kach czy ścia­nach miesz­kań (i dwor­ców kole­jo­wych) to kon­kret­ne zega­ry (mecha­nicz­ne, cyfro­we, itp.). Mimo wie­lu ich odmian i kon­struk­cji, zawsze słu­żą do tego same­go celu: wska­zu­ją aktu­al­ną godzi­ną (pomi­ja tu te uszko­dzo­ne). Zawsze też mają ten sam mecha­nizm dzia­ła­nia. Poniżej mamy dia­gram opi­su­ją­cy mecha­nizm dzia­ła­nia zega­ra. 

Celowo nie opi­su­ję deta­licz­nie tego dia­gra­mu, zakła­dam, że jest oczy­wi­sty” (poza pew­ny­mi deta­la­mi uży­tej nota­cji). Diagram ten nale­ża­ło­by uzu­peł­nić regu­ła­mi, np. tą że wska­za­nia minut zeru­ją się zawsze po 59 sekun­dzie. Zestaw takich reguł, uzu­peł­nio­ny opi­sem (jest jego ele­men­tem) to mecha­ni­zmu dzia­ła­nia zegara”.

Jak nie­trud­no się prze­ko­nać, wyko­nań (imple­men­ta­cji) tego mecha­ni­zmu jest na świe­cie ogrom, część z nich to wła­śnie kom­pu­ter i pro­gram reali­zu­ją­cy mecha­nizm zega­ra”. Wersji takie­go pro­gra­mu (tek­stu decy­du­ją­ce­go o tym jak zacho­wa się kom­pu­ter) tak­że może być ogrom. Tak więc pro­gram jako treść (utwór lite­rac­ki) speł­nia defi­ni­cję usta­wo­wą utwo­ru. W swej tre­ści może zawie­rać opis mecha­ni­zmu przed­sta­wio­ne­go na powyż­szym dia­gra­mie, zakła­dam, że nikt z czy­ta­ją­cych nie ma wąt­pli­wo­ści, że kon­kret­na treść pro­gra­mu i kon­kret­ny uży­ty kom­pu­ter, to inwen­cja twór­cza auto­ra pro­gra­mu”, nie zmie­nia to fak­tu, że pro­gra­my te będą reali­zo­wa­ły mecha­nizm opi­sa­ny w powyż­szej Specyfikacji opro­gra­mo­wa­nia, Kod pro­gra­mu będzie tu dzie­łem zależ­nym (autor Kodu pro­gra­mu nie jest auto­rem Specyfikacji opro­gra­mo­wa­nia, opra­co­wał swój utwór jako reali­za­cję tej spe­cy­fi­ka­cji). Zarówno Kod pro­gra­mu jak i Specyfikacja są utwo­ra­mi (tak­że w rozu­mie­niu usta­wy). Poniżej uży­te poję­cia i zależ­no­ści mię­dzy nimi:

Z jakimi umowami mamy do czynienia?

Podmioty zobra­zo­wa­ne jako Interesariusz 2 i Interesariusz 4 zawie­ra­ją Umowę, przed­mio­tem umo­wy mogą być usłu­gi, war­to­ści nie­ma­te­rial­ne i produkty.

Najczęściej spo­ty­ka­ną sytu­acją jest tak zwa­ny zakup opro­gra­mo­wa­nia”, a kon­kret­nie jest to jego licen­cjo­no­wa­nie i jed­no­ra­zo­wa opła­ta z tego tytu­łu. Interesariusz 4 jest posia­da­czem praw mająt­ko­wych do Aplikacji. Kupując np. grę kom­pu­te­ro­wą lub pro­gram do wysta­wia­nia fak­tur, fak­tycz­nie mamy nastę­pu­ją­cą sytu­ację: pod­miot kupu­ją­cy (Interesariusz 2) zawie­ra z posia­da­czem praw mająt­ko­wych (Interesariusz 4) Umowę licen­cyj­ną pozwa­la­ją­cą mu na korzy­sta­nie z Aplikacji. Użytkownik korzy­sta z Aplikacji (jest np. pra­cow­ni­kiem Interesariusza 2, lub Interesariusz 2 i Użytkownik to ta sama oso­ba fizyczna).

Umowa może zawie­rać zapi­sy o prze­nie­sie­niu praw mająt­ko­wych z Interesariusza 4 na Interesarusza 2. Integralną czę­ścią takiej Umowy, załącz­ni­kiem do niej, jest Kod pro­gra­mu (jego egzem­plarz na nośni­ku). Aplikacja może posia­dać swo­ją Specyfikację. Przeniesienie praw mająt­ko­wych do Kodu pro­gra­mu może (nie musi) wią­zać się z prze­nie­sie­niem praw mająt­ko­wych do jego Specyfikacji. Jej treść tak­że może być przed­mio­tem odręb­nej umo­wy. Decyduje o tym fakt, że Kod pro­gra­mu jest dzie­łem zależ­nym w sto­sun­ku do jego Specyfikacji.

Specyfikacja opro­gra­mo­wa­nia może zawie­rać w swej tre­ści opis okre­ślo­ne­go mecha­ni­zmu, np. usta­la­nie sco­rin­gu kre­dy­to­bior­cy albo przy­zna­wa­nie okre­ślo­nych upu­stów okre­ślo­nym gru­pom klien­tów. Treść ta może więc sta­no­wić know-how, któ­re może być chro­nio­ne np. jako tajem­ni­ca firmy.

Teraz nie­co trud­niej. Na ryn­ku spo­ty­ka­my poję­cia opro­gra­mo­wa­nie w chmu­rze”, SaaS (Software as a Service), out­so­ur­cing. Pojęcia te, w swych nazwach, nie mają żad­ne­go umo­co­wa­nia w pra­wie. Czym więc są? Osobiście jestem zwo­len­ni­kiem nie­uży­wa­nia ich ina­czej niż jako komen­ta­rza. Innymi sło­wy Umowa powin­na być skon­stru­owa­na z ter­mi­nów praw­nych (uży­tych i zde­fi­nio­wa­nych w Ustawach), ter­mi­ny stwo­rzo­ne na uży­tek komu­ni­ka­cji ryn­ko­wej (np. clo­ud com­pu­ting”) powin­ny być w tych umo­wach każ­do­ra­zo­wo defi­nio­wa­ne z uży­ciem ter­mi­nów prawnych.

Jeżeli więc ktoś korzy­sta w chmu­rze” z opro­gra­mo­wa­nia pozwa­la­ją­ce­go np. zarzą­dzać kon­tak­ta­mi z klien­ta­mi, to zna­czy, że za pośred­nic­twem sie­ci Internet Użytkownik ma dostęp do Aplikacji, korzy­sta z Usług apli­ka­cji. Robi to na pod­sta­wie Umowy jaką zawarł Interesariusz 2 z Interesariuszem 4 (tu tak­że Interesariusz 2 i Użytkowmik mogą być tą samą oso­bą fizycz­ną). Umowa okre­śla tu np. ilu Użytkowników może korzy­stać z Usług apli­ka­cji oraz to, czy użyt­kow­ni­kiem może być kto­kol­wiek czy kon­kret­ne oso­by z imie­nia i nazwiska.

Hosting. Jest to usłu­ga zali­cza­na do out­so­ur­cin­gu. W tym przy­pad­ku mamy sytu­ację taką:

  1. Prawa do Aplikacji ma Interesariusz 2.
  2. Aplikacja zain­sta­lo­wa­na jest na Komputerze będą­ce­go wła­sno­ścią Interesariusza 4.
  3. Użytkownicy, np. pra­cow­ni­cy Interesariusza 2, zdal­nie za pośred­nic­twem sie­ci Internet, korzy­sta­ją z Usług aplikacji.
  4. Umowa pre­cy­zu­je szcze­gó­ło­wo opła­ty i odpo­wie­dzial­ność obu interesariuszy.

Takich kom­bi­na­cji” może być wie­le, jed­nak na koniec opi­szę to co nazy­wa­my prze­tar­ga­mi. Pojawia się w nich poję­cie Opis Przedmiotu Zamówienia, któ­re moim zda­niem spra­wa w tej bran­ży, spo­ro kło­po­tu tak­że prawnikom.

Typowym celem ogła­sza­ją­ce­go prze­targ (każ­de­go kupu­ją­ce­go” opro­gra­mo­wa­nie) jest moż­li­wość korzy­sta­nia z Usług apli­ka­cji. W tym celu zawrze umo­wę (out­so­ur­cin­go­wą, licen­cyj­ną, itp.), któ­ra mu na to pozwo­li. I tu wra­ca­my do naszej pomi­do­rów­ki. Kluczem jest Specyfikacja, któ­ra zawie­ra opis tego jakie to usłu­gi i jaki jest mecha­nizm ich reali­za­cji. Dla kupu­ją­ce­go nie ma tu (na tym eta­pie) abso­lut­nie żad­ne­go zna­cze­nia, czy ta apli­ka­cja będzie spe­cjal­nie dla nie­go two­rzo­na czy nie. Specyfikacja MUSI powstać, bez cze­go nie da się stwier­dzić, czy dana Aplikacja jest tą, któ­rą zama­wia­my i któ­rej potrze­bu­je­my. Do tego korzy­sta­nie z zaku­pio­nej Aplikacji może wyma­gać pew­nych prac, takich jak jej zain­sta­lo­wa­nie, skon­fi­gu­ro­wa­nie, prze­szko­le­nie Użytkowników, umiesz­cze­nie w niej pew­nych danych (np. migra­cja danych z poprzed­nio uży­wa­nej apli­ka­cji), cza­sa­mi zin­te­gro­wa­nie z inny­mi, już wyko­rzy­sty­wa­ny­mi, apli­ka­cja­mi. Ogłaszający taki prze­targ zapła­ci za:

  1. pra­wo korzy­sta­nia z Aplikacji (w usta­lo­nej fir­mie np. licencji),
  2. wszel­kie koniecz­ne usłu­gi poprze­dza­ją­ce nor­mal­ne użyt­ko­wa­nie Aplikacji,
  3. jeże­li na ryn­ku nie jest ofe­ro­wa­ne wyma­ga­ne opro­gra­mo­wa­nie, zosta­nie ono napi­sa­ne” na pod­sta­wie Specyfikacji spe­cjal­nie dla Zamawiającego.

Jak widać, Specyfikacja jest tu bar­dzo istot­nym ele­men­tem, wręcz nie­zbęd­nym. To co nazy­wa­my Opisem Przedmiotu Zamówienia jest czymś wię­cej niż tyl­ko Specyfikacja opro­gra­mo­wa­nia. Dobrą prak­ty­ką jest roz­dzie­la­nie tych trzech powyż­szych ele­men­tów, ogrom­ną wygo­dą jest jeże­li są to odręb­ne umo­wy lub odręb­ne załącz­ni­ki Umowy głów­nej. Splatanie razem tych aspek­tów naj­czę­ściej pro­wa­dzi do nie­po­ro­zu­mień, pro­ble­mów z inter­pre­ta­cją umo­wy w cza­sie spo­rów. W skąd­inąd cie­ka­wym arty­ku­le pew­na kan­ce­la­ria wska­zu­je przy­czy­ny, a jako roz­wią­za­nie pro­ble­mu wska­zu­je jedy­nie pra­wo do wyco­fa­nia sie z umowy:

Nie ma recep­ty na popraw­ne opi­sa­nie przed­mio­tu świad­cze­nia. Jeśli mamy roz­bu­do­wa­ne, pre­cy­zyj­ne spe­cy­fi­ka­cje, to i tak musi­my w umo­wie opi­sać zarzą­dza­nie zmia­ną, ze szcze­gól­nym uwzględ­nie­niem roli ana­li­zy. W więk­szo­ści wypad­ków spe­cy­fi­ka­cje są na tyle ogól­ne, że dopie­ro ana­li­za (pro­jekt funk­cjo­nal­ny, kon­cep­cja itp.) opi­su­je praw­dzi­we ?co”. Już na począt­ku kon­trakt musi zadbać o inte­re­sy stron (zwłasz­cza zama­wia­ją­ce­go), jeże­li oka­że się, że ana­li­za ? choć prze­pro­wa­dzo­na popraw­nie ? pro­wa­dzi do wnio­sków nie­ak­cep­to­wal­nych (kosz­ty, zakres zmian, ter­mi­ny). Jednym ze spo­so­bów jest wpro­wa­dze­nie umow­ne­go pra­wa odstą­pie­nia od umo­wy. To mini­mum praw­ni­czej przy­zwo­ito­ści, pozwa­la­ją­ce małym kosz­tem wyco­fać się z umo­wy. (Źródło: Pięć typo­wych błę­dów w umo­wach wdro­że­nio­wych

Recepty na opi­sa­nie opi­sa­nie nie ma (a na co jest?), ale są zasa­dy, o któ­rych tu piszę. Kilka uwag do powyż­sze­go. Rozbudowana spe­cy­fi­ka­cja to gwa­ran­to­wa­ne pro­ble­my zwią­za­ne z zarzą­dza­niem zmia­ną i tu nale­ży sie zgo­dzić zaś zbyt ogól­ny opis jest jesz­cze gor­szy, bo po pro­stu nie wia­do­mo co jest przed­mio­tem zawie­ra­nej umo­wy. Kluczem jest to: W więk­szo­ści wypad­ków spe­cy­fi­ka­cje są na tyle ogól­ne, że dopie­ro ana­li­za (pro­jekt funk­cjo­nal­ny, kon­cep­cja itp.) opi­su­je praw­dzi­we ?co””. W takim przy­pad­ku nie­ste­ty dostaw­ca po pro­stu dostar­czy to co chce, bo sko­ro jest wyko­naw­cą i auto­rem ana­li­zy wyma­gań to zna­czy jest że jest auto­rem opi­su przed­mio­tu umo­wy. Biorąc pod uwa­gę fakt, że w takich sytu­acjach z zasa­dy dostaw­ca tech­no­lo­gii ma prze­wa­gę mery­to­rycz­ną nad swo­im klien­tem (bo ten z jakie­goś powo­du nie zro­bił opi­su sam), zama­wia­ją­cy w zasa­dzie nie panu­je na tym co dosta­nie. Słowo ana­li­za” nie defi­niu­je tego co jest pro­duk­tem ana­li­zy, ten powi­nien zostać zde­fi­nio­wa­ny. Doświadczenie auto­ra cyto­wa­ne­go arty­ku­łu, mogę potwier­dzić, on sam zaś przy­zna­je, że popraw­ne­go” opi­sa­nia przed­mio­tu zamó­wie­nia praw­ni­cy nie są w sta­nie doko­nać co jest praw­dą. W czę­ści Prawa autor­skie i kod źró­dło­wy” w zasa­dzie Pan Marcin Maruta nie napi­sał nic o pra­wach autor­skich do kodu opro­gra­mo­wa­nia a szkoda.

Najważniejszym celem porząd­ko­wa­nia pojęć w umo­wach, są kwe­stie praw stron i ochro­ny know-how. Bez wyraź­ne­go roz­dzie­le­nia praw do Specyfikacji i Kodu pro­gra­mu, poja­wia­ją się ogrom­ne pro­ble­my z usta­le­niem praw stron. Na tym tle wszel­kie for­my pro­wa­dze­nia pro­jek­tów i wdro­żeń ogra­ni­cza­ją­ce powsta­wa­nie doku­men­tów, szcze­gól­nie Specyfikacji, popu­lar­nie zwa­ne meto­da­mi zwin­ny­mi, pro­wa­dzą do ogrom­nych pro­ble­mów. Typową kon­se­kwen­cją tak zwa­ne­go zwin­ne­go podej­ścia, jest przej­mo­wa­nie praw do know-how przez wyko­naw­ców (nie­ste­ty czę­sto celo­we): autor Kodu pro­gra­mu, któ­ry to kod powstał z pomi­nię­ciem two­rze­nia Specyfikacji opro­gra­mo­wa­nia, wyłącz­nie na pod­sta­wie wywia­dów z przy­szły­mi użyt­kow­ni­ka­mi i ich prze­ło­żo­ny­mi, ma do tego kodu wszel­kie pra­wa, a Zamawiający żad­nych (musiał by je nabyć do twór­cy kodu).

Na zakończenie

Oczywiście nie wyczer­pa­łem tu wszyst­kich kom­bi­na­cji bytów praw­nych w zawie­ra­nych umo­wach. Należy pamię­tać o umo­wach z dostaw­ca­mi apli­ka­cji inte­gro­wa­nych, kom­po­nen­tów itp.. Celem moim było zwró­ce­nie uwa­gi na naj­czę­ściej spo­ty­ka­ne pro­ble­my, ich źró­dła i wska­za­nie jak się przed nimi zabezpieczyć.

Chętnie odpo­wiem na pyta­nia i podej­mę pole­mi­kę. Mam świa­do­mość, że opi­sa­ne tu zagad­nie­nia bywa­ją przed­mio­tem wie­lu spo­rów, sam je nie­jed­no­krot­nie toczę i z dostaw­ca­mi opro­gra­mo­wa­nia i z ich praw­ni­ka­mi. Uważam tak­że, że obec­ne pra­wo pozwa­la na bar­dzo dobrą ochro­nę stron takich umów, wyma­ga to jed­nak ogrom­nej pre­cy­zji w kon­stru­owa­niu tre­ści umów i two­rze­niu doku­men­tów opi­su­ją­cych ich przed­miot co abso­lut­nie nie wymu­sza tak zwa­nych metod wodo­spa­do­wych” w projektach.

Od lat sto­su­ję w swo­ich ana­li­zach i pro­jek­tach mię­dzy inny­mi, dia­gra­my takie jak powyż­szej. Pomagają one usta­lić pre­cy­zyj­nie wszel­kie aspek­ty i praw­ne i pro­jek­to­we w umo­wach, do cze­go gorą­co zachę­cam. Niestety wie­lu praw­ni­ków przyj­mu­je za cel swo­jej pra­cy obu­do­wa­nie” para­gra­fa­mi tego cze­go żąda­ją od nich w umo­wach, ich klien­ci. Owszem fir­my pła­cą praw­ni­kom za to, że Ci chro­nią ich inte­res, ale wie­le z tych umów to nie­ste­ty mani­pu­la­cje i korzy­sta­nie z nie­wie­dzy part­ne­ra, nie raz z jego gor­szej zna­jo­mo­ści (nie­zro­zu­mie­nia) prawa. 

Polecam też świet­ny tekst napi­sa­ny okiem praw­ni­ka (autor mec. Renata Warchol-Lewicka):

Jeżeli twój praw­nik rozu­mie kon­trakt lepiej niż twoi ludzie z biz­ne­su, ozna­cza to że zarów­no praw­nik może mieć pro­blem z tłu­ma­cze­niem praw­nych kom­po­nen­tów całej trans­ak­cji, ale tak­że że twój biz­nes w nie­wła­ści­wy spo­sób komu­ni­ku­je praw­ni­ko­wi cele i zało­że­nia biz­ne­su, któ­re­go umo­wa doty­czy. Może czas coś z tym zro­bić? (Source: TWÓJ PRAWNIK ROZUMIE KONTRAKT LEPIEJ NIŻ TWOI LUDZIE Z BIZNESU? COŚ TU JEST NIE TAK | Renata Warchol-Lewicka | Pulse | LinkedIn) 

UML version 2.5

Co praw­da for­mal­na publi­ka­cja wer­sji 2.5 UML to 1 marzec 2015 r. ale co ma wisieć nie uto­nie (spo­koj­ne prze­brnię­cie tych 794 stron wyma­ga cza­su i cier­pli­wo­ści), czy­li wzmian­ka i kil­ka słów z pierw­szych wra­żeń. Specyfikacja do pobra­nia tu:

Documents Associated With Unified Modeling Language (UML) Version 2.5 (Źródło: UML 2.5

Zdaję sobie spra­wę z tego, że poniż­sze nie wszyst­kim z Was wszyst­ko wyja­śni ale ten aku­rat wpis adre­su­ję dla tych z Was, któ­rzy korzy­sta­ją już z UML, nawet w bar­dzo pro­sty sposób.

Wersja 2.5 UML to wer­sja chy­ba prze­ło­mo­wa, bo:

  • zre­zy­gno­wa­no w koń­cu z podzia­łu na dwie czę­ści Infrastructure i Superstructure,
  • upo­rząd­ko­wa­no cały sys­tem poję­cio­wy nota­cji: jest to w koń­cu jed­na w peł­ni spój­na nota­cja (sys­tem kla­sy­fi­ka­to­rów, kie­dyś Infrastructure) oraz zestaw pre­de­fi­nio­wa­nych grup ste­reo­ty­pów z ich dedy­ko­wa­ną seman­ty­ką i syn­tak­ty­ką (kie­dyś Superstructure).
  • dia­gram jako poję­cie, obec­nie sta­no­wi jedy­nie kon­tekst a nie, jak kie­dyś zamknię­tą sub­no­ta­cję” (UML zaczy­nał w latach 90-tych jako zle­pek kil­ku nota­cji trzech autorów).

Obecnie mamy osiem typów dia­gra­mów (kopia z oryginału):

UML dia­grams may have the fol­lo­wing kinds of fra­me names as part of the heading:
? acti­vi­ty
? class
? com­po­nent
? deploy­ment
? inte­rac­tion
? pac­ka­ge
? sta­te machi­ne
? use case
In addi­tion to the long form names for dia­gram heading types, the fol­lo­wing abbre­via­ted forms can also be used:
? act (for acti­vi­ty fra­mes)
? cmp (for com­po­nent fra­mes)
? dep (for deploy­ment fra­mes)
? sd (for inte­rac­tion fra­mes)
? pkg (for pac­ka­ge fra­mes)
? stm (for sta­te machi­ne fra­mes)
? uc (for use case frames)

Jak widać, trzy­li­tro­wych skró­tów ozna­cza­ją­cych dia­gra­my jest o jeden mniej (sie­dem). To wyni­ka z tego, że wszyst­kie dia­gra­my w UML to tak na praw­dę dia­gra­my klas (ten typ dia­gra­mu nie ma swo­je­go dedy­ko­wa­ne­go skró­tu), z tym że sta­no­wią one kon­tek­sto­we pro­fi­le. Struktura poję­cio­wa tych dia­gra­mów (ich [[tak­so­no­mia]]):

UML The taxonomy of structure and behavior diagrams

W sto­sun­ku do UML 2.4 dia­gram pro­fi­lu jest teraz rów­no­praw­nym typem dia­gra­mu (czter­na­sty). Wszystkie poję­cia UML (con­structs) zosta­ły przy­dzie­lo­ne kon­tek­sto­wo to typów diagramów:

The con­structs con­ta­ined in each of the UML dia­grams are descri­bed in the clau­ses indi­ca­ted below.
? Activity Diagram – Activities
? Class Diagram – Structured Classifiers
? Communication Diagram – Interactions
? Component Diagram – Structured Classifiers
? Composite Structure Diagram – Structured Classifiers
? Deployment dia­gram – Deployments
? Interaction Overview Diagram – Interactions
? Object Diagram – Classification
? Package Diagram – Packages
? Profile Diagram – Packages
? State Machine Diagram – State Machines
? Sequence Diagram – Interactions
? Timing Diagram – Interactions
? Use Case Diagram – Use Cases

Należy to rozu­mieć w ten spo­sób: dia­gram aktyw­no­ści daje kon­tekst dla pojęć z gru­py acti­vi­ties” (aktyw­no­ści i czyn­no­ści oraz ich syn­tak­tycz­ne aso­cja­cje), dia­gram klas daje kon­tekst dla kla­sy­fi­ka­to­rów struk­tu­ral­nych”, itd.

Warto przy­pa­trzeć się swo­im narzę­dziom CASE, gdyż nie­ste­ty nie wszyst­kie mają wbu­do­wa­ny powyż­szy kla­so­wy” para­dyg­mat (w UML wszyst­ko jest kla­są). Wiele z nich nadal hoł­du­je zasa­dzie dia­gra­my jako odręb­ne nota­cje, obec­nie w UML w każ­dym typie dia­gra­mu moż­na użyć każ­de­go ele­men­tu nota­cji, dia­gram jako poję­cie to wyłącz­nie kon­te­ner nio­są­cy głów­ny kon­tekst dane­go mode­lu, bo przy­po­mi­nam, że dia­gram w UML to wyłącz­nie widok cało­ści lub czę­ści mode­lu z okre­ślo­nej per­spek­ty­wy i na okre­ślo­nym pozio­mie abstrakcji.

[uzu­peł­nie­nie 2015-11-21] Z pew­ną satys­fak­cją odkry­łem” (pier­wot­nie, pisząc ten arty­kuł mie­siąc temu, nie zwró­ci­łem na to uwa­gi), że zre­zy­gno­wa­no w koń­cu z poję­cia agre­ga­cji, zwa­nej w czę­ści lite­ra­tu­ry sła­bą kom­po­zy­cją”. Ta kurio­zal­na kon­struk­cja poję­cio­wa kłó­ci­ła się z poję­ciem i aso­cja­cji jako takiej i kom­po­zy­cji jako związ­ku całość część”. Nie ja jeden, jak śle­dzę dys­ku­sje człon­ków OMG na listach LinkedIn, dekla­ro­wa­łem, że nie rozu­miem” czym jest agre­ga­cja (chy­ba pierw­szym, któ­ry to gło­śno mówił był Martin Fowler). Na szczę­ście widać, że defi­ni­cja tego poję­cia nie wytrzy­ma­ła boju z logi­ką. Co praw­da sym­bol aso­cja­cji z pustym rom­bem” jest (tyl­ko) na liście sym­bo­li w dodat­ku B.6 (str. 718) jed­nak widać, że to relikt kom­pa­ty­bil­no­ści wstecz, w tre­ści całej spe­cy­fi­ka­cji to poję­cie nie jest w ogó­le uży­wa­ne. Generalnie mamy zwią­zek kom­po­zy­cji (peł­ny romb), a ele­ment skom­po­no­wa­ny może być rze­czy­wi­sty (part) lub abs­trak­cyj­ny (patrz rozdz. 11.2.3.2 Parts and Roles oraz 11.2.3.3 Connectors). Podobnie z dzie­dzi­cze­niem: nie ma dzie­dzi­cze­nia (korek­ta gru­dzień 2017, UML 2.5.1.).

Polecam całą spe­cy­fi­ka­cję, znacz­nie krót­sza od poprzedniej :).

Sprawna Inżynieria Oprogramowania: Ekstremalna obiektowość

Jestem gorą­cym fanem blo­gów dobrych (tak sądzę, że są ;)) pro­gra­mi­stów. Dlaczego? Bo to oni się męczą z moimi pro­jek­ta­mi. O czym powi­nien pamię­tać dobry ana­li­tyk pro­jek­tant? O dwóch rze­czach (zresz­tą o tym powi­nie pamię­tać każ­dy): po pierw­sze nie zapo­mi­naj kim jest Twój klient – mów do nie­go jego języ­kiem, po dru­gie jak coś two­rzysz dla swo­je­go klien­ta to nie po to by on musiał to jesz­cze raz po Tobie zro­bić po swojemu.

Analitycy jako zasoby

W pro­jek­tach infor­ma­tycz­nych naj­czę­ściej spo­ty­ka­my: ana­li­ty­ka wyma­gań (AW), ana­li­ty­ka sys­te­mo­we­go (AS), dewe­lo­pe­ra w tym archi­tek­ta sys­te­mu (D). W zasa­dzie trud­no powie­dzieć co jest pro­duk­tem dwóch pierw­szych bo Deweloper odda­je dzia­ła­ją­ce opro­gra­mo­wa­nie. Najczęściej AW dostar­cza jakiś opis tego cze­go ocze­ku­je klient, AS porząd­ku­je to co zro­bił AW np. z pomo­cą przy­pad­ków uży­cia a D bie­rze to do ręki i musi zapro­jek­to­wać i wyko­nać opro­gra­mo­wa­nie. Jak widać, odpo­wie­dzial­ność za to co powsta­nie jest roz­my­ta. Klient naj­pierw prze­ka­zu­je swo­je ocze­ki­wa­nia AW zaś otrzy­mu­je pro­dukt od D. Konia z rzę­dem temu, kto mi powie jak tego doko­nać bez per­ma­nent­nych ite­ra­cyj­nych wyja­śnień i bom­bar­do­wa­nia Klienta pyta­nia w rodza­ju co Państwo mie­li na myśli pisząc/mówiąc, że …”.

Od koń­ca. By powsta­ło opro­gra­mo­wa­nie (zakła­dam na dziś, że meto­da­mi obiek­to­wy­mi) musi powstać jego spe­cy­fi­ka­cja, pro­jekt któ­ry dokład­nie opi­su­je co mają zako­do­wać pro­gra­mi­ści. Bez tego nie wia­do­mo ani co ma powstać ani ile to wyma­ga pra­cy. Aby powsta­ła spe­cy­fi­ka­cja musi powstać opis logi­ki sys­te­mu bo tego wła­śnie ocze­ku­je Klient. Aby ta logi­ka powsta­ła trze­ba dokład­nie zro­zu­mieć to cze­go klient ocze­ku­je, jako że ocze­ku­je narzę­dzia wspo­ma­ga­ją­ce­go zarzą­dza­nie jego fir­mą, nale­ży tę fir­mę dokład­nie opi­sac a wcze­śniej zrozumieć.

W czym pro­blem? Mając trzy role w pro­jek­cie: AW, AS i D powsta­je zaba­wa w głu­chy tele­fon, któ­ra koń­czy się tym, że kon­tak­tu­ją się z Klientem wszy­scy bo opis słow­ny wyma­gań z regu­ły jest nie­pre­cy­zyj­ny i nie­kom­plet­ny. AS na bazie tego opi­su coś pro­jek­tu­je, D two­rzy pierw­szą wer­sje sys­te­mu. Klient to dosta­je i zgła­sza uwa­gi i ocze­ki­wa­nia, bo to tak na praw­dę jego pierw­szy kon­takt z pro­duk­tem. Proces ten zna każ­dy kto brał udział w takim pro­jek­cie (pozo­sta­łych prze­strze­gam przez takim podejściem).

Powyżej opi­sa­ny bieg wyda­rzeń to zaso­bo­we (silo­so­we) podej­ście do pro­jek­tu: jak użyć ludzi o posia­da­nych kompetencjach.

Analityk i deweloper jako właściciele procesów

Jak nale­ża­ło się spo­dzie­wać, musia­ło to dopro­wa­dzić do szu­ka­nia roz­wią­za­nia. Podobnie jak w zarzą­dza­niu w innych obsza­rach, zaczy­na­my mówić o pro­ce­sie wytwa­rza­nia opro­gra­mo­wa­nia”. A sko­ro mowa o pro­ce­sie to powin­ny się poja­wić pro­duk­ty poszcze­gól­nych pod-pro­ce­sów, ich wyko­naw­cy są wtór­ni wobec pro­duk­tów. Najpierw defi­niu­je­my pro­dukt potem wska­zu­je­my odpowiedzialnego.

W pro­ce­sie wytwa­rza­nia opro­gra­mo­wa­nia potrzeb­ne sa trzy produkty:

  1. opis celu biz­ne­so­we­go i stra­te­gii jego osią­gnię­cia, jed­nym z narzę­dzie zapew­ne będzie jakieś oprogramowanie,
  2. pro­jekt opro­gra­mo­wa­nia, nale­ży je zaprojektować,
  3. wyko­na­ne (dostar­czo­ne) oprogramowanie.

Mamy więc trzy ocze­ki­wa­ne pro­duk­ty czy­li trzy pro­ce­sy: ana­li­za biz­ne­so­wa, pro­jek­to­wa­nie, wyko­na­nie (imple­men­ta­cja). Projekt jest ści­śle powią­za­ny z ana­li­zą biz­ne­so­wa, gdyż powsta­je na bazie niej i jej peł­ne­go zro­zu­mie­nia, nasu­wa to wnio­sek, że jed­na oso­ba powin­na odpo­wia­dać za pro­jekt i dobrze jest jeśli będzie to autor ana­li­zy biz­ne­so­wej. Jakie roz­wią­za­nie jest więc skuteczne?

Tym roz­wią­za­niem wyda­ja się być:

  1. meto­dy obiek­to­we ana­li­zy, pro­jek­to­wa­nia i implementacji,
  2. podział pro­ce­su na dwa eta­py i dwie role: opra­co­wa­nie pro­jek­tu logi­ki sys­te­mu i implementacja,
  3. [[wzo­rzec pro­jek­to­wy MVC]] i [[pro­jek­to­wa­nie meto­dą DDD]].

W dużym uproszczeniu:

  1. meto­dy obiek­to­we pozwa­la­ją na uży­wa­nie od same­go począt­ku tego same­go spo­so­bu opi­su (mode­lo­wa­nia) roz­wią­za­nia, któ­re powsta­je w mia­rę postę­pów ana­li­zy, zapis tego cze­go ocze­ku­je Klient to Przypadki Użycia (czar­na skrzyn­ka) oraz Model Dziedziny (pro­jekt – bia­ła skrzynka),
  2. do two­rze­nia opro­gra­mo­wa­nia uży­wa się obec­nie naj­czę­ściej fra­me­wor­ków bazu­ją­cych na [[wzor­cu MVC]] dla któ­re­go [[Model Dziedziny]] zapro­jek­to­wa­ny zgod­nie z DDD, jest goto­wym pro­jek­tem logi­ki kom­po­nen­tu Model z MVC zaś Przypadki Użycia to wyma­ga­nia na inter­fejs użyt­kow­ni­ka opi­sa­ny jak V w MVC (kom­po­nent C – kon­tro­ler – odpo­wia­da za ste­ro­wa­nie apli­ka­cją i reali­za­cję wyma­gań poza-funkcjonalnych).

Można wiec powie­dzieć, że kie­ru­nek jest taki:

Tak więc z trzech, nie­ja­sno okre­ślo­nych ról two­rzą sie dwie:

  1. Analityk Biznesowy, któ­re­go rolą jest dostar­czyć wyma­ga­nia funk­cjo­nal­ne (przy­pad­ki uży­cia wraz z ogra­ni­cze­nia­mi) oraz Model Dziedziny,
  2. Deweloper, któ­re­go rolą jest dostar­cze­nie opro­gra­mo­wa­nia imple­men­tu­ją­ce­go tak okre­ślo­ne Wymagania, Developer ma” Architekta Systemu czy­li pro­jek­tan­ta implementacji.

Jest to pro­mo­wa­ny” przez [[IIBA w BABoK]] pro­ces i zakres kompetencji.

Teraz kolej na dono­sy z inne­go blo­ga, jest to blog programisty:

Jeff Bay pro­po­nu­je w nim 9 reguł doty­czą­cych two­rze­nia kodu (przy­kła­dy są w javie, ale więk­szość reguł odno­sić się może do w mia­rę dowol­ne­go języ­ka, szcze­gól­nie OO). Są to:

  • Tylko jeden poziom zagłę­bie­nia na metodę
  • Nie uży­waj sło­wa klu­czo­we­go else
  • Opakowuj wszyst­kie pry­mi­ty­wy i Stringi (w kla­sy o spe­cy­ficz­nej dla zasto­so­wa­nia nazwie)
  • Używaj tyl­ko jed­nej krop­ki na linię
  • Nie skra­caj nazw
  • Pilnuj wszyst­kie encje by były małe
  • Nie uży­waj klas o wię­cej niż dwóch polach
  • Klasa któ­rej polem jest kolek­cja nie powin­na mieć żad­nych innych pól (opa­ko­wy­wa­nie kolek­cji w kla­sy spe­cy­ficz­ne dla kon­tek­stu wykorzystania)
  • Nie uży­waj getterów/setterów/własności

(źr. Sprawna Inżynieria Oprogramowania: Ekstremalna obiektowość.)

Jeżeli uznać, że to wyma­ga­nia w ogó­le na pro­jekt obiek­to­wy to są to wyma­ga­nia dla mnie: Analityka Biznesowego, na to jak ma wyglą­dać Model Dziedziny Systemu.

Po co to wszyst­ko? Bo tu nie ma głu­che­go tele­fo­nu, pro­dukt powsta­je w pierw­szej ite­ra­cji i każ­dy dokład­nie wie za co odpo­wia­da. Całość trwa kró­cej i jest mniej kosztowna.

P.S.

A tym jak taki pro­dukt, Wymagania, powsta­je pisa­łem już wcze­śniej, o tym jak się to imple­men­tu­je niech piszą programiści 🙂

P.S. 2

Polecam tak­że inne cie­ka­we spoj­rze­nie na ten pro­blem w arty­ku­le Analityk sys­te­mo­wy – łącz­nik dwóch świa­tów. Tu fak­tycz­nie sta­je się pro­ble­ma­tycz­ne stwier­dze­nie kim jest, a kim nie, ana­li­tyk sys­te­mo­wy. Być może Analityk Systemowy jest wła­ściw­szym ter­mi­nem, jed­nak ja boje się tego, że powszech­nie koja­rzo­ne z infor­ma­ty­ką poję­cie sys­tem” zabu­rza tak poj­mo­wa­ne zna­cze­nie ana­li­zy sys­te­mo­wej”, któ­ra nie koniecz­nie doty­czy sys­te­mów IT. Modelowanie biz­ne­su (firm, orga­ni­za­cji) meto­da­mi zna­ny­mi z ana­li­zy sys­te­mo­wej ([[ogól­na teo­ria sys­te­mów]]) jest chy­ba jed­nak ana­li­zą biz­ne­so­wą (tego biz­ne­su), ale mogę się mylić…