Jarosław Żeliński Date. (2021). Metody kasto­mi­za­cji opro­gra­mo­wa­nia stan­dar­do­we­go – aspek­ty eko­no­micz­ne: Recenzja. https://​doi​.org/​1​0​.​1​3​1​4​0​/​R​G​.​2​.​2​.​2​2​2​9​2​.​0​1​927

Wstęp

Publikacja Jędrzeja Wieczorkowskiego (dalej: recen­zo­wa­ne opra­co­wa­nie) o poniż­szym tytu­le uka­za­ła się w 2015 roku:

Jędrzej Wieczorkowski
Instytut Informatyki i Gospodarki Cyfrowej
Szkoła Główna Handlowa w Warszawie
Metody kasto­mi­za­cji opro­gra­mo­wa­nia stan­dar­do­we­go: aspek­ty eko­no­micz­ne.

Autor recen­zo­wa­ne­go tek­stu odno­si sie do skut­ków eko­no­micz­nych, pomi­ja jed­nak cał­ko­wi­cie skut­ki praw­ne kasto­mi­za­cji kodu opro­gra­mo­wa­nia, któ­re mają wpływ na kosz­ty i ochro­nę war­to­ści inte­lek­tu­al­nych. Autor pisze we wstępie:

Celem niniej­sze­go opra­co­wa­nia jest ana­li­za moż­li­wych metod kasto­mi­za­cji sys­te­mów infor­ma­tycz­nych zarzą­dza­nia prze­pro­wa­dzo­na z eko­no­micz­ne­go punk­tu widze­nia, w tym w szcze­gól­no­ści opła­cal­no­ści sto­so­wa­nia opro­gra­mo­wa­nia stan­dar­do­we­go i wyko­rzy­sta­nia poszcze­gól­nych metod jego adap­ta­cji. […] Kastomizację sys­te­mu infor­ma­tycz­ne­go ogól­nie nale­ży rozu­mieć jako jego adap­ta­cję do potrzeb kon­kret­ne­go pod­mio­tu. M. Flasiński okre­ślił kasto­mi­za­cję, jako ?kon­fi­gu­ra­cję sys­te­mu, osa­dze­nie w sys­te­mie za pomo­cą prac pro­gra­mi­stycz­nych dodat­ko­wych funk­cjo­nal­no­ści oraz mody­fi­ka­cję ist­nie­ją­cych funk­cjo­nal­no­ści systemu?

Dostarczanie opro­gra­mo­wa­nia i jego wdra­ża­nie, wią­że się jego ewen­tu­al­nym dosto­so­wa­niem do potrzeb użyt­kow­ni­ka. Autor powyż­sze­go opra­co­wa­nia, sto­su­jąc nie­pre­cy­zyj­ne defi­ni­cje pojęć, wpro­wa­dza czy­tel­ni­ka w błąd, opi­su­jąc przy­czy­ny i kon­se­kwen­cje zwią­za­ne z sze­ro­ko poję­tym dosto­so­wa­niem opro­gra­mo­wa­nia do potrzeb użytkownika. 

Niestety z tego doku­men­tu korzy­sta wie­lu praw­ni­ków, nazy­wa­jąc go nie raz nawet ​„wykład­nią”.

Architektura oprogramowania i definiowanie jego funkcjonalności

Podstawowym ele­men­tem opi­su­ją­cym opro­gra­mo­wa­nie są usłu­gi jakie ono świad­czy użyt­kow­ni­ko­wi. Standardem opi­su sys­te­mów, tak­że infor­ma­tycz­nych, jest obec­nie sys­tem poję­cio­wy i nota­cja UML . Usługi apli­ka­cji defi­niu­je­my tu jako ocze­ki­wa­ny i trwa­ły efekt (pro­dukt) jaki uzy­sku­je aktor (użyt­kow­nik) z pomo­cą apli­ka­cji (jej usług). Uzyskanym trwa­łym efek­tem jest tu zarów­no uzy­ska­ny np. nowy doku­ment, jak i uzy­ska­na zmia­na zacho­wa­nia samej apli­ka­cji. Co do zasa­dy usłu­ga apli­ka­cji to jej funk­cjo­nal­ność, a więc coś co ona potra­fi, bo zosta­ła w tym celu stworzona. 

Jeżeli opro­gra­mo­wa­nie nie ofe­ru­je okre­ślo­nej wyma­ga­nej funk­cjo­nal­no­ści (nie speł­nia wyma­gań), wyma­ga­na jest inge­ren­cja w jego kon­struk­cję czy­li kod. 

Powyższy dia­gram obra­zu­je zwią­zek apli­ka­cji (defi­nio­wa­na jest jako kom­pu­te­ro­wy pro­gram użyt­ko­wy) z jej kodem (dia­gram przy­pad­ków uży­cia, związ­ki nota­cji UML napi­sa­no z dużej litery):

• wyma­ga­ne usłu­gi apli­ka­cji ofe­ru­je apli­ka­cja (System, po lewej): Korzystanie z aktu­al­nej logi­ki apli­ka­cji oraz Ustawienia logi­ki dzia­ła­nia apli­ka­cji: jej para­me­try­za­cji, to Typy Usług aplikacji.
• Aplikacja (kod) Realizuje funk­cjo­nal­no­ści wyspe­cy­fi­ko­wa­ne po lewej jako ​„Aplikacja”,
• Aplikacja (kod) wyko­nu­je się w Środowisku apli­ka­cji: biblio­te­ki pro­gra­mi­stycz­ne (fra­me­work),
• źró­dłem Środowiska i Komponentu apli­ka­cyj­ne­go stan­dar­do­we­go (kod) jest pro­du­cent opro­gra­mo­wa­nia standardowego,
• źró­dłem Komponentu apli­ka­cyj­ne­go dedy­ko­wa­ne­go (kod) jest Developer, (kom­po­nen­ty te współ­pra­cu­ją: są zintegrowane),
• wdro­że­nie, wyma­ga­ją­ce zmia­ny logi­ki dzia­ła­nia apli­ka­cji, osią­ga­ne meto­dą zwa­ną para­me­try­za­cją (kon­fi­gu­ra­cją), to co do zasa­dy korzy­sta­nie z apli­ka­cji, nie wyma­ga więc inge­ren­cji w jej kod, gdyż para­me­try­za­cja to tak­że usłu­ga ofe­ro­wa­na użyt­kow­ni­ko­wi przez apli­ka­cję (zmia­na war­to­ści okre­ślo­nych zmiennych/parametrów),
• wyma­ga­ne, dodat­ko­we usłu­gi apli­ka­cji, nie­do­stęp­ne w jej stan­dar­do­wej wer­sji, reali­zu­je kom­po­nent dedy­ko­wa­ny (czy­li roz­sze­rze­nie), wytwo­rzo­ny w śro­do­wi­sku macie­rzy­stej aplikacji,
• zmia­na zacho­wa­nia apli­ka­cji stan­dar­do­wej, nie­do­stęp­na z pozio­mu usług apli­ka­cji, wyma­ga więc albo jej roz­sze­rze­nia, albo jej kasto­mi­za­cji (czy­li inge­ren­cji w jej macie­rzy­sty kod).

Taksonomia pojęcia Zmiana zachowania oprogramowania

Pojęcie «dosto­so­wa­nie» w języ­ku pol­skim jest defi­nio­wa­ne jako: ​„zmie­nić coś tak, by paso­wa­ło do cze­goś”. W inży­nie­rii opro­gra­mo­wa­nia ope­ru­je­my poję­ciem wyma­ga­nie: ​„waru­nek lub zespół warun­ków, któ­rym ktoś lub coś musi odpo­wia­dać”. Tak więc dosto­so­wa­nie ozna­cza tu dopro­wa­dze­nie do tego, by opro­gra­mo­wa­nie speł­nia­ło «wyma­ga­nia». Jeżeli opro­gra­mo­wa­nie stan­dar­do­we nie speł­nia wyma­gań to zna­czy, że trze­ba je dosto­so­wać, czy­li zmie­nić jego zacho­wa­nie (o ile się na to godzimy).

Powyższy dia­gram obra­zu­je tak­so­no­mię poję­cia ​„zmia­na zacho­wa­nia opro­gra­mo­wa­nia”. Do pojęć słow­ni­ko­wych: «para­me­try­za­cja» i «roz­bu­do­wa», doda­no w tej tak­so­no­mii poję­cie zde­fi­nio­wa­ne przez auto­ra recen­zo­wa­ne­go opra­co­wa­nia: «kasto­mi­za­cja», tak by speł­nia­ło zasa­dy logi­ki defi­nio­wa­nia pojęć: defi­ni­cje pojęć muszą się wza­jem­nie wyklu­czać . Generalizacja musi więc sta­no­wić uogól­nie­nie pojęć sta­no­wią­cych jej spe­cja­li­za­cję (typy). Innymi sło­wy: para­me­try­za­cja, roz­bu­do­wa i kasto­mi­za­cja, to spe­cjal­ne, i wyklu­cza­ją­ce się zara­zem wza­jem­nie, typy (meto­dy) zmia­ny zacho­wa­nia oprogramowania.

Szczególnie nie­bez­piecz­na jest kasto­mi­za­cja, któ­ra ozna­cza inge­ren­cję w kod aplikacji: 

Kastomizacja ERP: to zmia­ny, któ­re fir­my wpro­wa­dza­ją do swo­ich sys­te­mów ERP, aby speł­nić kry­tycz­ne wyma­ga­nia biz­ne­so­we. Zmiany te zazwy­czaj obej­mu­ją edy­cję kodu źró­dło­we­go opro­gra­mo­wa­nia w celu uzy­ska­nia funk­cjo­nal­no­ści, któ­rych nie zawie­ra­ją funk­cje natywne.

https://​softwa​re​con​nect​.com/​l​e​a​r​n​/​e​r​p​-​c​o​n​f​i​g​u​r​a​t​i​o​n​-​v​s​-​c​u​s​t​o​m​i​z​a​t​i​on/

Poniżej ilu­stra­cja poka­zu­ją­ca ww. definicje:

Recenzowane opracowanie

Autor recen­zo­wa­ne­go opra­co­wa­nie kla­sy­fi­ku­je sys­te­my (apli­ka­cje):

?? powie­lar­ne zamknię­te ? opra­co­wa­ne na ano­ni­mo­wy rynek, mają­ce nie­wiel­kie moż­li­wo­ści dosto­so­wa­nia do spe­cy­ficz­nych potrzeb biz­ne­so­wych poszcze­gól­nych odbior­ców;
?? dedy­ko­wa­ne ? opra­co­wa­ne od pod­staw ?na mia­rę? dla kon­kret­ne­go odbior­cy;
?? wyko­rzy­stu­ją­ce model roz­wo­ju opro­gra­mo­wa­nia wie­lo­krot­ne­go uży­cia (ang. reu­sa­ble) ? przy ich two­rze­niu wyko­rzy­stu­je się biblio­te­ki zawie­ra­ją­ce goto­we ele­men­ty opro­gra­mo­wa­nia, zazwy­czaj nazy­wa­ne kom­po­nen­ta­mi;
?? stan­dar­do­we para­me­try­zo­wal­ne ? opra­co­wa­ne na ano­ni­mo­wy rynek, któ­re w ramach dosto­so­wa­nia do potrzeb odbior­cy wyma­ga­ją w sze­ro­kim zakre­sie usta­wie­nia para­me­trów eks­plo­ata­cyj­nych, czy­li kastomizacji.

Powyższa kla­sy­fi­ka­cja stoi w cał­ko­wi­tej sprzecz­no­ści z meto­da­mi zmia­ny zacho­wa­nia opro­gra­mo­wa­nia, w szcze­gól­no­ści z wcze­śniej przy­ta­cza­ną przez auto­ra defi­ni­cją kasto­mi­za­cji (inge­ren­cja w kod), czym autor sam łamie wła­sną defi­ni­cję poję­cia «para­me­try­za­cja», prze­cząc poda­nej przez sie­bie defi­ni­cji ​„kasto­mi­za­cja». Dodać war­to, że biblio­te­ki (fra­me­wor­ki) to goto­we funk­cje, z któ­rych two­rzy się kom­po­nen­ty, nie jest praw­dą, że biblio­te­ki to kom­po­nen­ty apli­ka­cyj­ne (funk­cje biblio­tecz­ne same z sie­bie nie ofe­ru­ją funk­cjo­nal­no­ści apli­ka­cji, kom­po­nen­ty tak).

Teza auto­ra recen­zo­wa­ne­go opracowania:

O typo­wej kasto­mi­za­cji sto­so­wa­nej w sze­ro­kim zakre­sie moż­na więc mówić w przy­pad­ku stan­dar­do­wych sys­te­mów para­me­try­zo­wal­nych, okre­śla­nych tak­że jako sys­te­my wypo­sa­żo­ne w moż­li­wość tech­no­lo­gicz­nej kastomizacji.

sta­no­wi sobą pozba­wio­ny logi­ki zle­pek: ​„para­me­try­za­cja to kasto­mi­za­cja”. W kon­se­kwen­cji uzna­łem, że kolej­ny roz­dział recen­zo­wa­ne­go opra­co­wa­nia: ​„Ekonomiczne aspek­ty kasto­mi­za­cji opro­gra­mo­wa­nia”, pozo­sta­wię bez komen­ta­rza, gdyż sko­ro uży­te defi­ni­cje są nie­spój­ne i sprzecz­ne, wnio­sko­wa­nie na ich pod­sta­wie z zasa­dy jest nie­wła­ści­we. Stosowane przez auto­ra w dal­szej czę­ści opra­co­wa­nia ​„intu­icyj­ne” wnio­sko­wa­nie, jest moim zda­niem cał­ko­wi­cie nie­upraw­nio­ną i nie­nau­ko­wą, meto­dą wyjaśniania.

Prawo autorskie a architektura kodu aplikacji

Ustawa o pra­wie autor­skim , nie wprost, posłu­gu­je sie poję­ciem zacho­wa­nia inte­gral­no­ści utwo­ru, ozna­cza­ją­cym brak jakiej­kol­wiek inge­ren­cji w jego postać. W kon­se­kwen­cji ozna­cza to, że kasto­mi­za­cja, jako inge­ren­cja w kod pro­gra­mu, sta­no­wi naru­sze­nie inte­gral­no­ści utwo­ru, jakim jest ten kod. 

Na dia­gra­mie Oprogramowanie i jego imple­men­ta­cja poka­za­no archi­tek­tu­rę apli­ka­cji w spo­sób pozwa­la­ją­cy ziden­ty­fi­ko­wać jej ele­men­ty z per­spek­ty­wy inte­gral­no­ści utwo­ru, jakim jest kod pro­gra­mu. Diagram Taksonomia poję­cia ​„zmia­na zacho­wa­nia opro­gra­mo­wa­nia”, poka­zu­je moż­li­we meto­dy zmia­ny zacho­wa­nia aplikacji. 

Uznając fakt, że kasto­mi­za­cja naru­sza inte­gral­ność utwo­ru, i fakt, że może ona być legal­nie nie­moż­li­wa z uwa­gi na ochro­nę praw­no-autor­ską, zmia­na zacho­wa­nia opro­gra­mo­wa­nia, bez naru­sze­nia inte­gral­no­ści kodu, jest moż­li­wa wyłącz­nie poprzez para­me­try­za­cję lub roz­bu­do­wę. Rozbudowa apli­ka­cji to doda­nie nowe­go kodu, bez inge­ren­cji w już ist­nie­ją­cy: powsta­je nowy utwór. Z per­spek­ty­wy inży­nie­rii opro­gra­mo­wa­nia, powsta­je nowy kom­po­nent apli­ka­cji, jako nowy utwór, inte­gro­wa­ny z ist­nie­ją­cym już kodem, bez inge­ren­cji w nie­go. Nowy kom­po­nent może powstać w śro­do­wi­sku pro­gra­mi­stycz­nym dostar­czo­nym (licen­cjo­no­wa­nym) przez dostaw­cę opro­gra­mo­wa­nia stan­dar­do­we­go, co bar­dzo uła­twia ich inte­gra­cję. Postępowanie takie jest zale­ca­ne przez pro­du­cen­tów opro­gra­mo­wa­nia stan­dar­do­we­go, w przy­pad­ku, gdy wyma­ga­ne jest jasne wska­za­nie praw autor­skich i odpo­wie­dzial­no­ści za funk­cjo­no­wa­nie apli­ka­cji: sepa­ra­cja ory­gi­nal­ne­go kodu dostaw­cy, od kodu powsta­łe­go w celu zmia­ny zacho­wa­nia pozwa­la zagwa­ran­to­wać podział na kod licen­cjo­no­wa­ny od pro­du­cen­ta apli­ka­cji i dedy­ko­wa­ny, dostar­czo­ny (czę­sto wraz z pra­wem mająt­ko­wym) przez wdra­ża­ją­ce­go apli­ka­cję developera.

Podsumowanie

Wdrażanie opro­gra­mo­wa­nia stan­dar­do­we­go: goto­we­go, ofe­ro­wa­ne­go na ryn­ku dla sze­ro­kie­go gro­na odbior­ców, wią­że się koniecz­no­ścią zacho­wa­nia odpo­wie­dzial­no­ści dostaw­ców i ochro­ny ich autor­skich praw oso­bi­stych i mająt­ko­wych. To tak­że zacho­wa­nie bez­pie­czeń­stwa nabyw­ców opro­gra­mo­wa­nia, gdyż jego dostaw­ca pono­si odpo­wie­dzial­ność za jego jakość, jed­nak tyl­ko pod warun­kiem zacho­wa­nia inte­gral­no­ści utwo­ru jaki dostar­czył. Kastomizacja stan­dar­do­we­go opro­gra­mo­wa­nia, jako inge­ren­cja w jego kod, naru­sza tę inte­gral­ność, co zdej­mu­je odpo­wie­dzial­ność z pier­wot­ne­go jego auto­ra (pomi­jam tu kwe­stie tego, czy autor/dostawca wyra­ża na to zgo­dę i na jakich warunkach).

W efek­cie moż­na stwierdzić:

• wdro­że­nie opro­gra­mo­wa­nia powin­no pole­gać na para­me­try­za­cji oprogramowania,
• jeże­li zmia­na funk­cjo­nal­no­ści nie jest moż­li­wa meto­dą para­me­try­za­cji, powin­na pole­gać na roz­bu­do­wie o nowe kom­po­nen­ty (dedy­ko­wa­ne lub kupio­ne na rynku),
• kasto­mi­za­cja stan­dar­do­we­go opro­gra­mo­wa­nia pro­wa­dzi do zwol­nie­nia jego autorów/producenta, z odpo­wie­dzial­no­ści za jego jakość, a tak­że pro­wa­dzi do sytu­acji, w któ­rej insta­la­cja nowej wer­sji stan­dar­do­we­go opro­gra­mo­wa­nia (upgra­de) znisz­czy wpro­wa­dzo­ne zmia­ny, dla­te­go w pro­jek­tach nale­ży prze­strze­gać opi­sa­nej wyżej sepa­ra­cji i korzy­stać z rękoj­mi dla kodu dedy­ko­wa­ne­go (zapi­sy o rezy­gna­cji z rękoj­mi, for­so­wa­ne przez wie­lu dostaw­ców opro­gra­mo­wa­nia są więc i nie­upraw­nio­ne i nieuczciwe). 

W per­spek­ty­wy kosz­tów pro­wa­dzi to do sytu­acji, w któ­rej nabyw­ca opro­gra­mo­wa­nia, po jego kasto­mi­za­cji, bie­rze na sie­bie 100% kosz­tów dal­sze­go utrzy­ma­nia i roz­wo­ju, co jest nie­eko­no­micz­ne, bo celem korzy­sta­nia z opro­gra­mo­wa­nia stan­dar­do­we­go jest obni­że­nie tych kosz­tów (efekt ska­li: pro­du­cent roz­kła­da kosz­ty utrzy­ma­nia i roz­wo­ju opro­gra­mo­wa­nia na wszyst­kich swo­ich klien­tów). W przy­pad­ku roz­bu­do­wy, mamy do czy­nie­nia z samo­dziel­nym, rela­tyw­nie nie­wiel­kim, nowym ele­men­tem (kom­po­nent) apli­ka­cji, któ­ry z regu­ły sta­no­wi (jego logi­ka) know-how fir­my, do któ­re­go fir­ma (nabyw­ca) posia­da, w pra­wi­dło­wo skon­stru­owa­nej umo­wie, pra­wa majątkowe.

Recenzowane opra­co­wa­nie jest czę­sto przy­ta­cza­ne jako uza­sad­nie­nie tre­ści umów pro­po­no­wa­nych przez dostaw­ców opro­gra­mo­wa­nia, jako ​„wykład­nia”. Uważam, że umo­wy te są bar­dzo nie­ko­rzyst­ne dla nabyw­ców opro­gra­mo­wa­nia, gdyż nie tyl­ko prze­rzu­ca­ją na nabyw­ców opro­gra­mo­wa­nia wszel­kie ryzy­ka wyni­ka­ją­ce z jako­ści tego opro­gra­mo­wa­nia, ale tak­że powo­du­ją, że know-how zawar­te w kasto­mi­zo­wa­nym kodzie, sta­je się wła­sno­ścią dostaw­cy takie­go opro­gra­mo­wa­nia, gdyż nie ist­nie­je gra­ni­ca pomię­dzy kodem dostaw­cy a kodem powsta­łym na zamó­wie­nie nabywcy. 

Bezpieczna dla nabyw­cy umo­wa na dosta­wę opro­gra­mo­wa­nia powin­na zawierać:

• koszt licen­cji na kod stan­dar­do­wy i kosz­ty jego para­me­try­za­cji (usłu­ga eks­perc­ka dostawcy),
• zakres i koszt roz­bu­do­wy (roz­sze­rze­nie) kodu stan­dar­do­we­go o nowe kom­po­nen­ty (na pod­sta­wie dostar­czo­ne­go pro­jek­tu technicznego), 
• prze­nie­sie­nie na nabyw­cę autor­skich praw mająt­ko­wych do powsta­łe­go kodu sta­no­wią­ce­go roz­bu­do­wę (utwór zależ­ny pro­jek­tu tech­nicz­ne­go) dostar­czo­nej apli­ka­cji (kodu standardowego).

Dodatek

Inżynieria opro­gra­mo­wa­nia, jak każ­da inży­nie­ria, cechu­je się wie­lo­ma dobry­mi prak­ty­ka­mi. Należą do nich wzor­ce archi­tek­to­nicz­ne i zasa­dy two­rze­nia dobrej archi­tek­tu­ry . Jaka to jest ta ​„dobra archi­tek­tu­ra”? W inży­nie­rii dobra archi­tek­tu­ra sys­te­mu to taka, któ­ra pro­wa­dzi do kon­struk­cji łatwych (czy­li tanich) w utrzy­ma­niu i roz­wo­ju (ser­wi­so­wal­ność). W wie­lo­let­nim cyklu życia pro­duk­tu jego zapro­jek­to­wa­nie i wytwo­rze­nie sta­no­wi naj­krót­szy okres. Kolejne lata to utrzy­ma­nie i roz­wój. Do tego dru­gie­go zmu­sza­ją nas zmie­nia­ją­ce się świat i nasze potrzeby. 

Jedną z pod­sta­wo­wych zasad dobrej archi­tek­tu­ry jest zasa­da Open Closed Principle. Sprowadza się ona do tezy: opro­gra­mo­wa­nie powin­no być zamknię­te na zmia­ny i otwar­te na roz­sze­rze­nia. Oznacza to, że roz­wój, szcze­gól­nie ten w toku wdra­ża­nia, gdy uzu­peł­nia­my stan­dar­do­we opro­gra­mo­wa­nie o bra­ku­ją­ce a wyma­ga­ne funk­cjo­nal­no­ści, powi­nien pole­gać na doda­wa­niu roz­sze­rzeń, a nie na mody­fi­ko­wa­niu już ist­nie­ją­cych ele­men­tów (kodu). Dlatego zna­ko­mi­ta więk­szość zna­nych mi, liczą­cych się na mię­dzy­na­ro­do­wym ryn­ku, dostaw­ców np. Systemów ERP, zale­ca pro­ste postępowanie:

• ana­li­za gap-fit (ana­li­za luki) czy­li okre­śle­nie, któ­rych wyma­gań użyt­kow­ni­ka nie speł­nia stan­dar­do­wa wer­sja oprogramowania,
• pod­ję­cie decy­zji, któ­re bra­ku­ją­ce funk­cjo­nal­no­ści zosta­ną doda­ne, czy­li okre­śle­nie zakre­su pro­jek­tu (ma to wpływ na koszt i harmonogram),
• wyko­na­nie bra­ku­ją­cych modu­łów (roz­sze­rze­nia) i ich inte­gra­cja z dostar­czo­nym opro­gra­mo­wa­niem standardowym,
• aby to uła­twić, dostaw­cy stan­dar­do­we­go opro­gra­mo­wa­nia dostar­cza­ją (licen­cjo­nu­ją) tak­że śro­do­wi­sko pro­gra­mi­stycz­ne i inte­gra­cyj­ne (biblio­te­ki pro­gra­mi­stycz­ne: frameworki).

Dzięki temu zysku­je­my tak­że z per­spek­ty­wy praw­nej: sepa­ru­je­my utwo­ry mają­ce róż­nych auto­rów i wła­ści­cie­li. Na opro­gra­mo­wa­nie stan­dar­do­we dosta­je­my licen­cję, dedy­ko­wa­ne roz­sze­rze­nia prze­cho­dzą (powin­ny) na kupu­ją­ce­go wraz z pra­wem mająt­ko­wym. Produkty te mają, każ­dy swój, odręb­ne cykle życia. Zyskujemy tak­że to, że upgra­de (uno­wo­cze­śnie­nie doko­na­ne przez dostaw­cę opro­gra­mo­wa­nia stan­dar­do­we­go) nie nad­pi­sze (nie znisz­czy) kodu reali­zu­ją­ce­go nasze dedy­ko­wa­ne funk­cjo­nal­no­ści, bo ten jest odręb­nym kodem (kom­po­nen­tem).

[Niniejsze opra­co­wa­nie dorę­czo­no auto­ro­wi recen­zo­wa­ne­go doku­men­tu, żad­na posta­wio­na tu teza nie zosta­ła zakwestionowana]. 

Źródła