Wprowadzenie

Pojęcie «sys­tem» sta­ło się bar­dzo popu­lar­ne, głów­nie za spra­wą ​„sys­te­mów infor­ma­tycz­nych”, jed­nak jego rodo­wód jest star­szy i pocho­dzi nie od tech­no­lo­gii a od bio­lo­gii . Poza IT mamy sys­te­my bez­pie­czeń­stwa, sys­tem ubez­pie­czeń, sys­tem eme­ry­tal­ny, sys­tem pra­wa, i wie­le innych. Słownik języ­ka pol­skie­go poda­je taką defi­ni­cję poję­cia system:

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ść
3. narzą­dy lub inne czę­ści żywe­go orga­ni­zmu peł­nią­ce razem okre­ślo­ną funkcję
4. upo­rząd­ko­wa­ny zbiór twier­dzeń, poglą­dów, two­rzą­cych jakąś teorię
5. okre­ślo­ny spo­sób wyko­ny­wa­nia jakiejś czyn­no­ści lub zasa­dy orga­ni­za­cji czegoś
6. for­ma ustro­ju państwowego
7. zespół skał powsta­łych w cią­gu jed­ne­go okre­su geologicznego
8. log. cało­ścio­wy i upo­rząd­ko­wa­ny zespół zdań połą­czo­nych ze sobą sto­sun­ka­mi logicz­ne­go wynikania

Jak widać jest to poję­cie bar­dzo uni­wer­sal­ne dzie­dzi­no­wo, jed­nak gene­ral­nie wszyst­kie te defi­ni­cje to szcze­gól­ne rodza­je tej pierw­szej. My sku­pi­my sie na pierw­szych dwóch: pierw­sza z uwa­gi na jej ogól­ność, dru­ga z uwa­gi na fakt, że kom­pu­ter to sys­tem będą­cy urzą­dze­niem, a w zasa­dzie zespo­łem urządzeń. 

Organizacje, fir­my w szcze­gól­no­ści, to zło­żo­ne ​„sys­te­my sys­te­mów”. Poniżej model fir­my po raz pierw­szy opu­bli­ko­wa­ny w 1985 roku:

Model ten jest nada aktu­al­ny i wykła­da­ny na stu­diach MBA. Pokazuje, że żad­na fir­ma nie jest orga­ni­za­cyj­nym monolitem. 

w 1998 roku M.E.Porter, w kolej­nym wyda­niu swo­jej książ­ki , dodał roz­dział o sys­te­mach infor­ma­tycz­nych, w któ­rym zwró­cił uwa­gę na to, że sys­tem infor­ma­tycz­ny fir­my powi­nien archi­tek­to­nicz­nie odpo­wia­dać wyżej zobra­zo­wa­nej struk­tu­rze fir­my, jeże­li to wystą­pi zja­wi­sko tak zwa­ne­go ​„nie­do­pa­so­wa­nia opo­ru” czy­li nie­zgod­ność sys­te­mu jakim jest fir­ma, z sys­te­mem jakim jest opro­gra­mo­wa­nie ją wspierające.

Teza jako­by mono­li­tycz­ny sys­tem infor­ma­tycz­ny, z jed­ną cen­tral­ną bazą danych, był ade­kwat­ny dla firm, już wte­dy zosta­ła prak­tycz­nie oba­lo­na (naj­bar­dziej zna­ne dziś sys­te­my ERP powsta­ły znacz­nie przed 1998 roku, do tej pory roz­wi­ja­na jest jedy­nie tech­no­lo­gia ich imple­men­ta­cji a nie archi­tek­tu­ra, to dla­te­go ich kom­plek­so­we wdra­ża­nie to od wie­lu lat serie porażek). 

Z książ­ki Portera moż­na wycią­gnąć waż­ny wnio­sek: sys­tem infor­ma­tycz­ny powi­nien sta­no­wić odwzo­ro­wa­nie ww. pro­ce­sów z tą uwa­gą, że pro­ce­sy wspie­ra­ją­ce, jako naj­czę­ściej regu­lo­wa­ne pra­wem, nie budu­ją­ce prze­wa­gi ryn­ko­wej, i z tego powo­du rzad­ko będą­ce tak­że tajem­ni­cą przed­się­bior­stwa, powin­ny (mogą być) wspie­ra­ne jed­ną stan­dar­do­wą apli­ka­cją. Pozostałe, jako uni­kal­ny w każ­dej fir­mie pro­ces ope­ra­cyj­ny (na sche­ma­cie Primary), powin­ny być wspie­ra­ne przez samo­dziel­ne, dedy­ko­wa­ne dzie­dzi­no­wo, zin­te­gro­wa­ne na pozio­mie logi­ki prze­pły­wu danych, aplikacje.

Ten arty­kuł to wyja­śnie­nie czym jest tak zwa­ny ​„sys­tem sys­te­mów” i jak sie to ma do firm. Zainteresowanym pole­cam tak­że . Poniżej trosz­kę teo­rii, prak­ty­ki i przykładów.

Modele i meta-modele

Pojęcie model i meta-model jest bar­dzo waż­ne zarów­no w ana­li­zach jak i w mode­lo­wa­niu sys­te­mów. Słownik języ­ka pol­skie­go defi­niu­je poję­cie model jako (w naszym obsza­rze dzie­dzi­no­wym): ?kon­struk­cja, sche­mat lub opis uka­zu­ją­cy dzia­ła­nie, budo­wę, cechy, zależ­no­ści jakie­goś zja­wi­ska lub obiek­tu?. Przedrostek meta- ozna­cza: ?pierw­szy człon wyra­zów zło­żo­nych wska­zu­ją­cy na wyż­szy sto­pień, następ­stwo lub zmien­ność czegoś?. 

Modelowanie jest waż­ne, jed­nak wie­le mode­li, pozba­wio­nych ich meta-mode­li, jest wadli­wa gdyż ich two­rze­nie i jed­no­znacz­na inter­pre­ta­cja mogą być nie­moż­li­we . OMG​.org publi­ku­je spe­cy­fi­ka­cję MOF, o któ­rej już pisa­łem. Jest to stan­dar­do­wy opis warstw abs­trak­cji, mode­lo­wa­nia i meta-modelowania:

Schemat powyż­szy obra­zu­je pod­sta­wo­we czte­ry pozio­my abs­trak­cji. Licząc od dołu mamy:

• M0 – war­stwa pod­sta­wo­wa, jest to to co jest (może być) mode­lo­wa­ne: real­ny świat, urzą­dze­nie, sys­tem aktów praw­nych, dzia­ła­ją­ce opro­gra­mo­wa­nie w pamię­ci kom­pu­te­ra, kom­pu­ter, itp. na tym pozio­mie mówi­my o obiek­tach (enti­ty), to real­ne byty.
• M1 – jest to model świa­ta ist­nie­ją­ce­go w war­stwie M0, tu byty rze­czy­wi­ste są repre­zen­to­wa­ne z pomo­ca absg­trak­cyj­nych, pro­stych sym­bo­li na sche­ma­tach blo­ko­wych (jeden do jed­ne­go: sym­bol – obiekt rzeczywisty).
• M2 – jest to meta-model wart­swy M0, są to kla­sy (typy) ele­men­tów z jaki zbu­do­wa­ny jest świat M0.
• M3 – jest to meta-meta-model, są to defi­ni­cje pojęć, uży­tych do powsta­nia meta­mo­de­lu, jest to np. defi­ni­cja nota­cji, jakiej uży­je­my to mode­lo­wa­nia war­stwy M2. 

Warstwa M0 to ana­li­zo­wa­ny świat (sys­tem). Warstwa M3 to meto­da mode­lo­wa­nia (typy ele­men­tów na dia­gra­mach mode­li). Warstwa M2 i M1 to np. mode­le w nota­cji UML (i jej pochod­nych): M2 to dia­gra­my klas a M1 to dia­gra­my obiek­tów (spe­cy­fi­ka­cje instan­cji tych klas). W dal­szej czę­ści będzie­my korzy­sta­li z warstw udo­stęp­nia­nych przez UML.

Notacja SysML

Notacja UML jest bar­dzo nad­mia­ro­wa, jako Unified Modeling Language (Ujednolicony Język Modelowania) jest ogól­na, i nie pre­cy­zu­je zasto­so­wa­nia swo­ich ele­men­tów, spe­cy­fi­ku­je ich zna­cze­nie (np. kla­sa ma swo­ją defi­ni­cję w UML, ale to czy uży­je­my poję­cia kla­sy do mode­lo­wa­nia kom­po­nen­tów, ich inter­fej­sów, czy sys­te­mu pojęć, to samo­dziel­na decy­zja użyt­kow­ni­ka UML). UML nie­sie z sobą pięt­no inży­nie­rii opro­gra­mo­wa­nia, gdyż pier­wot­nie nota­cja ta powsta­ła jako narzę­dzie słu­żą­ce do pro­jek­to­wa­nia w inży­nie­rii opro­gra­mo­wa­nia. Jednak szyb­ko odkry­to, że poję­cia mode­li i meta-mode­li są bar­dzo przy­dat­ne, więc sche­ma­ty blo­ko­we w tej nota­cji zaczę­ły domi­no­wać w publi­ka­cjach trak­tu­ją­cych o sys­te­mach i ich mode­lach. Kilka lat po opu­bli­ko­wa­niu spe­cy­fi­ka­cji UML poja­wi­ła się zawę­żo­na i upo­rząd­ko­wa­na spe­cy­fi­ka­cja: nota­cji SysML (System Modeling Language, ), sta­no­wią­cej pro­fil UML i jego podzbiór:

Diagramy wyko­rzy­sty­wa­ne do mode­lo­wa­nia systemów:

Notacja ta szyb­ko zdo­by­ła sobie uzna­nie w prze­my­śle, dosko­na­le nada­je się do mode­lo­wa­nia sze­rzej rozu­mia­nych sys­te­mów np. samo­cho­dów , a gene­ral­nie tak zwa­nych urzą­dzeń mecha­tro­nicz­nych, czy­li zło­żo­nych elek­tro­me­cha­nicz­nych urzą­dzeń, któ­rych czę­ścią są tak­że kom­pu­te­ry (więc tak­że opro­gra­mo­wa­nie). Korzyści ze sto­so­wa­nia abs­trak­cyj­nych mode­li tego typu sys­te­mów są na tyle duże, że nota­cja SysML sta­je się prze­my­sło­wym stan­dar­dem w sys­te­mach zarzą­dza­nia pro­duk­ta­mi i ich pro­duk­cją .

Mechanizm

Słownik języ­ka pol­skie­go defi­niu­je poję­cie mecha­nizm jako: spo­sób, w jaki coś powsta­je, prze­bie­ga lub dzia­ła, np. spo­sób dzia­ła­nia orga­ni­za­cji, opro­gra­mo­wa­nia. W nauce mecha­ni­zmy są obiek­ta­mi o okre­ślo­nych wła­sno­ściach i pro­ce­sa­mi zor­ga­ni­zo­wa­ny­mi w taki spo­sób, że powo­du­ją one regu­lar­ne zmia­ny, począw­szy od począt­ku, czy też warun­ków począt­ko­wych, aż do zakoń­cze­nia dzia­ła­nia lub warun­ków końcowych. 

Statystycznie okre­ślo­na kore­la­cja nie jest mode­lem mecha­ni­zmu, nie okre­śla ona związ­ku przy­czy­no­wo-skut­ko­we­go, jest jedy­nie stwier­dze­niem sta­ty­stycz­nej powta­rzal­no­ści . Cytując Cravera, może­my powie­dzieć: ?mecha­nizm jest wyja­śnie­niem powią­za­nia, któ­re­go Hume szu­kał mię­dzy przy­czy­ną a skut­kiem?, ?mecha­nizm zacho­wa­nia jest zło­żo­nym sys­te­mem, któ­ry opi­su­je to zacho­wa­nie poprzez inte­rak­cję wie­lu kom­po­nen­tów, przy czym inte­rak­cję mię­dzy kom­po­nen­ta­mi moż­na opi­sać jako związ­ki uogól­nień (gene­ra­li­za­cji) kom­po­nen­tów tego sys­te­mu? .

Tak więc model może opi­sy­wać (wyja­śniać) mecha­nizm powsta­wa­nia cze­goś (zacho­wa­nia się cze­goś). Innymi sło­wy jeże­li jakiś np. sche­mat blo­ko­wy coś wyja­śnia, to zna­czy, że jest on mode­lem tego cze­goś. Jeżeli to coś ma dopie­ro powstać, do model ten jest pro­jek­tem tego cze­goś. I tu poja­wia się poję­cie MBSE: Model-based System Engineering. 

Inżynieria sys­te­mów opar­ta na mode­lach (MBSE) jest sfor­ma­li­zo­wa­ną meto­do­lo­gią, któ­ra jest uży­wa­na do wspie­ra­nia wyma­gań, pro­jek­to­wa­nia, ana­li­zy, wery­fi­ka­cji i wali­da­cji zwią­za­nych z roz­wo­jem zło­żo­nych sys­te­mów. W prze­ci­wień­stwie do inży­nie­rii skon­cen­tro­wa­nej na doku­men­tach, MBSE sta­wia mode­le w cen­trum pro­jek­to­wa­nia sys­te­mu. Zwiększone zain­te­re­so­wa­nie śro­do­wisk mode­lo­wa­nia cyfro­we­go w cią­gu ostat­nich kil­ku lat dopro­wa­dzi­ło do zwięk­szo­nej akcep­ta­cji MBSE. W stycz­niu 2020 roku NASA odno­to­wa­ła ten trend, infor­mu­jąc, że MBSE ​„jest coraz czę­ściej przyj­mo­wa­ne zarów­no przez prze­mysł, jak i rząd jako spo­sób na śle­dze­nie zło­żo­no­ści systemów.” 

Metody okre­śla­ne jako MBSE spraw­dza­ją się bar­dzo dobrze jako narzę­dzie spe­cy­fi­ko­wa­nia wyma­gań, tu wyma­ga­niem jest wła­śnie model czy­li pro­jekt sys­te­mu .

Systemy – analiza i modelowanie

Jak już wspo­mnia­no, kom­pu­ter jest coraz czę­ściej ele­men­tem nad­rzęd­nej kon­struk­cji. Dlatego pod poję­ciem «model sys­te­mu» rozu­mie­my coś wię­cej niż oprogramowanie:

Praktyka poka­zu­je, że podej­ście to dosko­na­le spraw­dza się w pro­jek­to­wa­niu sys­te­mów infor­ma­tycz­nych, któ­re z zasa­dy są czę­ścią nad­rzęd­ne­go bytu, jakim jest orga­ni­za­cja, będą­ca ich (przy­szłym) użytkownikiem. 

W nota­cji SysML mode­le sys­te­mów są ogra­ni­czo­ne wyłącz­nie do ich abs­trak­cji, dla­te­go znacz­na część ele­men­tów nota­cji UML nie jest tu sto­so­wa­na (doty­czy to głów­nie część UML słu­żą­cej do revers-inży­nie­rii kodu i do gene­ro­wa­nia kodu z dia­gra­mów). Mamy tu czte­ry fila­ry modelowania:

1. Modele struk­tu­ry, 2. mode­le zacho­wa­nia, 3. mode­le wyma­gań, 4. Model para­me­trycz­ny. Od końca:

Model para­me­trycz­ny to nowy typ dia­gra­mu. Jest to narzę­dzie mode­lo­wa­nia wiel­ko­ści fizycz­nych prze­pły­wa­ją­cych mię­dzy ele­men­ta­mi sys­te­mu, np. prze­ka­zy­wa­ny moment obro­to­wy wału sil­ni­ka czy napię­cie i prąd zasi­la­nia (ale tak­że sygna­ły i komu­ni­ka­ty czy­li infor­ma­cje). Modele wyma­gań to struk­tu­ral­na for­ma pre­zen­ta­cji potrzeb, gene­ral­nie rozu­mia­nych tu jako potrze­by inte­re­sa­riu­szy oraz zewnętrz­ne cechy sys­te­mu. Modele zacho­wa­nia to typo­we dla UML dia­gra­my maszy­ny sta­no­wej, aktyw­no­ści i sekwencji. 

Modele struk­tu­ry w SysML mają jed­nak pew­ną spe­cy­fi­kę: to co w UML jest co naj­wy­żej ​„dobrą prak­ty­ką mode­lo­wa­nia” w SysML jest obli­ga­to­ryj­ne: dekla­ro­wa­nie typów ele­men­tów sys­te­mu (meta­mo­del sys­te­mu) przed ich uży­ciem, zaś okre­ślo­ny sys­tem jest instan­cją tego meta­mo­de­lu. Pierwszy do Block Definition Diagram, dru­gi to Internal Block Diagram. Model para­me­trycz­ny budo­wa­ny jest jako uzu­peł­nie­nie drugiego. 

Przykady:

Powyższy dia­gram to dzie­dzi­no­wy meta­mo­del sys­te­mu: dekla­ru­je­my tu z jakie­go typu ele­men­tów będzie (jest) zbu­do­wa­ny sys­tem. Jest to drze­wia­sta struk­tu­ra dekom­po­zy­cji sys­te­mu oraz jed­nost­ki mia­ry. Konkretny sys­tem, struk­tu­rę fizycz­ną sys­te­mu, mode­lu­je­my jako instan­cję tego metamodelu:

Powyższy model to spe­cy­fi­ka­cje instan­cji typów ele­men­tów (klas ele­men­tów) zade­kla­ro­wa­nych na Diagramie Definicji Bloków. Jeżeli chce­my wyra­zić wiel­ko­ści fizycz­ne opi­su­ją­ce sys­tem sto­su­je­my Diagram Parametryczny:

Diagram para­me­trycz­ny pozwa­la uru­cho­mić symu­la­cję systemu. 

Jak modelujemy firmy

W arty­ku­le Przeciążanie BPMN czy­li jak nie mode­lo­wać pro­duk­cji opi­sa­łem jak mode­lo­wać część pro­duk­cyj­nę fabry­ki. Tu przed­sta­wię nie­co bar­dziej szer­szą per­spek­ty­wę .

Typy ele­men­tów to kla­sy (rodza­je) kom­po­nen­tów, urządzeń:

Typy ele­men­tów (całych blo­ków) dekla­ru­je­my by pla­no­wać ich przy­szłe wyko­rzy­sta­nie ale tak­że pozy­ska­nie (zle­ce­nie wyko­na­nia, zakup). Typowe blo­ki to: napę­dy, ste­row­ni­ki, budow­le, maszy­ny spe­cja­li­stycz­ne itp. Jednym z wie­lu jest kom­pu­ter. Przypominam, że kom­pu­ter to: pro­ce­sor, pamięć i pro­gram. Tak więc tam gdzie poja­wia się ​„opro­gra­mo­wa­nie” real­nie będzie to kom­pu­ter i jakiś styk z nim (czło­wiek lub np. cyfro­wo-ste­ro­wa­ne urządzenie). 

Mając zade­kla­ro­wa­ne typy ele­men­tów może­my przy­stą­pić do świa­do­me­go pro­jek­to­wa­nia (ana­li­zy i mode­lo­wa­nia ist­nie­ją­ce­go) zakładu: 

Takie podej­ście pozwa­la opi­sać całość sys­te­mu jakim jest np. zakład pro­duk­cyj­ny . Może on zawie­rać maszy­ny, urzą­dze­nia i sys­te­my ste­ru­ją­ce wie­lu dostaw­ców, sys­tem ERP itp. Zrozumienie i zapro­jek­to­wa­nie cało­ści oszczę­dza ogrom­ne ilo­ści cza­su i pie­nię­dzy: pozwa­la zapro­jek­to­wać nie tyl­ko okre­ślo­ne apli­ka­cje, ale zapla­no­wać to któ­re kupić jako COTS (ang. com­mer­cial off-the-shelf, goto­we opro­gra­mo­wa­nie dostęp­ne na ryn­ku), któ­re jako zle­cić jako dedy­ko­wa­ne, zapro­jek­to­wać inter­fej­sy i od razu wszyst­ko ład­nie uru­cho­mić. Pozwala ​„oczy­ścić” nasze pomy­sły z wszel­kich błę­dów nie­spój­no­ści, nie­kom­plet­no­ści roz­wią­za­nia. Usuwanie błę­dów na eta­pie pro­jek­to­wa­nia jest to o kil­ka rzę­dów tań­sze niż ich odkry­wa­nie i usu­wa­nie w toku wdrożeń. 

Niezależnie od tego czy chce­my zapro­jek­to­wać i zro­zu­mieć zmy­war­kę, samo­lot, czy uboj­nię (tak, ana­li­zo­wa­łem taką i doku­men­to­wa­łem) zawsze mamy do czy­nie­nia z czymś wię­cej niż tyl­ko kom­pu­ter i apli­ka­cje biz­ne­so­we. Teza, że wdro­że­nia sys­te­mów ERP to tyl­ko opro­gra­mo­wa­nie i wyma­ga­nie na nie było może praw­dzi­wa kil­ka dekad temu, teraz «sys­tem» to przed­się­bior­stwo a nie raz kraj (sys­tem trans­por­tu kra­jo­we­go, albo pla­no­wa­ny KseF). 

Tak więc zaj­mu­jąc się tyl­ko ​„wyma­ga­nia­mi na opro­gra­mo­wa­nie”, zaj­mu­jesz się pew­na małą czę­ścią więk­szej cało­ści, jaką jest orga­ni­za­cja. To zaś ozna­cza, że nie masz zro­zu­mie­nia wpły­wu tego opro­gra­mo­wa­nia na tę całość, i jest bar­dzo praw­do­po­dob­ne, że nie­świa­do­mie szko­dzisz całej tej orga­ni­za­cji. Jeżeli zaś jakiś dostaw­ca, jed­ne­go z typów tych sys­te­mów, nie zna­jąc tej orga­ni­za­cji, uwa­ża że jego roz­wią­za­nie jest dobre, to po pro­stu nie wie co mówi. 

Posiadanie takiej doku­men­ta­cji to tak­że wie­dza dla przy­szłych pra­cow­ni­ków, a nie raz chro­ni­ne know-how. Bardzo czę­sto kom­po­nen­ty tak pro­jek­to­wa­nych sys­te­mów tra­fia­ją póź­niej celo­wo do róż­nych pod­wy­ko­naw­ców, co zapo­bie­ga ryzy­ku prze­ję­cia know-how (zna­jo­mo­ści i zro­zu­mie­nia cało­ści sys­te­mu) przez poten­cjal­ną konkurencję. 

Podsumowanie

Pojęcie mecha­nizm jest w powszech­nym uży­ciu, jed­nak w ana­li­zie i nauce ma ono spe­cy­ficz­ne zna­cze­nie: to wyja­śnie­nie dzia­ła­nia cze­goś, to abs­trak­cja . Z per­spek­ty­wy zarów­no orga­ni­za­cji jak i opro­gra­mo­wa­nia, postrze­ga­nych jako sys­te­my, poja­wia się dru­gie poję­cie jakim jest ​„to z cze­go sys­tem się skła­da” (com­po­si­tion) . Mechanizm nigdy nie jest jed­nym ele­men­tem, jed­nak jako wyja­śnie­nie jest abs­trak­cją, czy­li ​„ukry­wa” (abs­tra­chu­je od) szcze­gó­ły: mecha­nizm, jako opis, jest ide­ali­za­cją .

Od wie­lu lat do opi­su orga­ni­za­cji sto­su­je się poniż­szy, trój­war­stwo­wy model: 

Wierzchołek to stra­te­gia orga­ni­za­cji, jej rola w oto­cze­niu w jakim sie znaj­du­je. Dolna, trze­cia war­stwa, to aktu­al­ny opis tej orga­ni­za­cji. Tu jest ​„wszyst­ko to co ist­nie­je” (zaso­by i deta­licz­ne pro­ce­du­ry). Środkowa war­stwa to wła­śnie MODEL DZIAŁANIA ORGANIZACJI, abs­trak­cyj­ny opis tego ​„co i po co” się dzie­je a nie ​„jak i dlaczego”. 

Chcąc zro­zu­mieć, dla­cze­go orga­ni­za­cja tak a nie ina­czej się zacho­wu­je, musi­my jej opis dopro­wa­dzić do takie­go pozio­mu abs­trak­cji, by moż­li­we było sku­pie­nie się wyłącz­nie na mecha­niź­mie jej dzia­ła­nia. Jest to moż­li­we jedy­nie trak­tu­jąc orga­ni­za­cję jako sys­tem .

Czym są więc wyma­ga­nia na opro­gra­mo­wa­nie? To ta część mecha­ni­zmu dzia­ła­nia orga­ni­za­cji, któ­rą chce­my zacząć reali­zo­wać jako dzia­ła­ją­ce opro­gra­mo­wa­nie lub jego ele­ment. Wymagania na opro­gra­mo­wa­nie to nie są cele użyt­kow­ni­ków! Wymagania na opro­gra­mo­wa­nie to mecha­nizm ich osiągania.

Czy moż­na opi­sać przy­szły sys­tem suchym opi­sem dotych­cza­so­wych fak­tów? Nie! Trzeba go zapro­jek­to­wać czy­li stwo­rzyć coś cze­go nie było!

Gilotyna Hume’a – nazwa pro­ble­mu sfor­mu­ło­wa­ne­go przez szkoc­kie­go filo­zo­fa Davida Hume’a doty­czą­ce­go nie­moż­no­ści wnio­sko­wa­nia, co powin­no być, na pod­sta­wie tego, co jest (ang. is-ought problem).

D. Hume, A Treatise of Human Nature, Oxford, Clarendon Press 1965 (reprint I wyda­nia), s. 469

Bo sam opis sta­nu obec­ne­go i wywia­dy z pra­cow­ni­ka­mi nie sta­no­wią sobą przy­szłych rozwiązań. 

Źródła