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 przy­ję­cie ś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­ne­go przy­ję­cia 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 sys­te­mu.” W tym wpi­sie na blo­gu przed­sta­wiam krót­kie wpro­wa­dze­nie do MBSE.

Read more about the article Kiedy maszyna stanowa a kiedy jednak status?
Autorstwa Clemens PFEIFFER - Praca własna: CANON PowerShot G7, CC BY 2.5, https://commons.wikimedia.org/w/index.php?curid=1441506

Kiedy maszyna stanowa a kiedy jednak status?

Różnica mię­dzy sta­nem a sta­tu­sem obiektu

Wstęp

Od cza­su do cza­su wpa­da­ją mi maile z pyta­nia­mi jak to:

Chcę zamo­de­lo­wać dyna­micz­ne zacho­wa­nie / sta­ny smart­fo­na (np. wyłą­cze­nie smart­fo­na, ini­cja­li­za­cja, tryb czu­wa­nia, uży­cie) w dia­gra­mie maszy­ny sta­nów SysML. Dla sta­nu użyt­ko­wa­nia ist­nie­ją rów­nież pod­sta­ny takie jak dzwo­nie­nie, latar­ka lub robie­nie zdjęć. Nie jestem pewien czy powi­nie­nem mode­lo­wać te pod­sta­ny, a jeśli tak, to jak mogę je mode­lo­wać (szcze­gól­nie bio­rąc pod uwa­gę fakt, że każ­dy z tych pod­sta­nów może zmie­niać się w inny, jak rów­nież mogą one dzia­łać rów­no­le­gle).
Moim zda­niem są róż­ne opcje:
1.) Po pro­stu uwzględ­nić je jako aktyw­ność w uży­ciu sta­nu
2.) Wymodelować je w oddziel­nym dia­gra­mie maszy­ny sta­nów
3.) Modelować je w oddziel­nym dia­gra­mie aktyw­no­ści (czy mozna użyć dia­gra­mu aktyw­no­ści zamiast dia­gra­mu maszy­ny stanowej?)

Takie i podob­ne pyta­nia poja­wia­ją się w mailach do mnie czę­sto, ale zanim na nie odpo­wiem tu, opi­szę czym jest model (dia­gram) maszy­ny sta­no­wej. Pokażę tak­że dla­cze­go, np. pró­by wdra­ża­nia obie­gów doku­men­tów na bazie wzor­ca maszy­ny sta­no­wej” spra­wia­ją ogrom­ne kło­po­ty, lub po pro­stu się nie udają.

Na począ­tek to, co znaj­dzie­my np. w Longman English Dictionary:

sta­tus: a situ­ation at a par­ti­cu­lar time, espe­cial­ly in an argu­ment, discus­sion etc. (sytu­acja w okre­ślo­nym cza­sie, zwłasz­cza w kłót­ni, dys­ku­sji itp.)
sta­te: the phy­si­cal or men­tal con­di­tion that some­one or some­thing is in (stan fizycz­ny lub psy­chicz­ny, w jakim znaj­du­je się ktoś lub coś)

źr.: Longman English Dictionary https://​www​.ldo​ce​on​li​ne​.com/

Tak więc gene­ral­nie sta­tus to ogląd obiek­tu z zewnątrz, stan to cecha obiek­tu. Innymi sło­wy moja cho­ro­ba to mój stan, ale moja nie­zdol­ność do pra­cy to aktu­al­ny mój sta­tus (wyni­ka on nie z cho­ro­by, a z usta­le­nia, że cho­rzy nie pra­cu­ją, to nie to samo). Zapraszam do lektury. 

(wię­cej…)

Czytaj dalejKiedy maszyna stanowa a kiedy jednak status?

Opis wymagań z użyciem Gherkin – czyli dużo korniszonów…

Wstęp

Zostałem nie­daw­no zapy­ta­ny czy pomo­gę bo mamy już ponad 150 przy­pad­ków uży­cia w doku­men­ta­cji…”. Myślę sobie, to nie­moż­li­we, nie ma tak wiel­kich sys­te­mów (wyce­na oka­za­ła się w efek­cie pię­cio­krot­nie zawy­żo­na tyl­ko dla­te­go, że uży­to meto­dy zorien­to­wa­nej na user story”). 

(wię­cej…)

Czytaj dalejOpis wymagań z użyciem Gherkin – czyli dużo korniszonów…

Architektoniczne wzorce projektowe w analizie i projektowaniu modelu dziedziny systemu

Wprowadzenie

W arty­ku­le o apli­ka­cjach webo­wych, ponad rok temu, pisałem:

Generalnie klu­czo­wą cechą micro-ser­wi­­sów, czy­nią­cą z nich tak zwa­ną zwin­ną archi­tek­tu­rę, jest cał­ko­wi­ta wza­jem­na nie­za­leż­ność imple­men­ta­cji poszcze­gól­nych usług apli­ka­cyj­nych. (źr.: Aplikacje webo­we i mikro­ser­wi­sy czy­li archi­tek­tu­ra sys­te­mów webo­wych).

Przy innej oka­zji pisa­łem o wzorcach:

Wzorce pro­jek­to­we to bar­dzo waż­na część ??zawo­du? ana­li­ty­ka i archi­tek­ta opro­gra­mo­wa­nia. […] Generalnie wzor­ce są to ska­ta­lo­go­wa­ne stan­dar­dy i dobre prak­ty­ki . (Obiektowe wzor­ce projektowe ) 

Szkolenia dla ana­li­ty­ków poprze­dzam ankie­ta­mi przed szko­le­nio­wy­mi, jak do tej pory żad­na nie zawie­ra­ła pytań o wzor­ce pro­jek­to­we: ani tego że są uży­wa­ne ani tego, że są celem szko­le­nia, nie­mal­że każ­dy dekla­ru­je albo, że uży­wa UML lub, że chce zacząć uży­wać UML, nawet gdy są to pro­gra­mi­ści. Zauważyłem, że wzor­ce pro­jek­to­we w świa­do­mo­ści ana­li­zy biz­ne­so­wej i pro­jek­to­wa­nia (OOAD) nie ist­nie­ją”. Wśród pro­gra­mi­stów, jeże­li jest spo­ty­ka­na, to wie­dza o wzor­cach przy­dat­nych w two­rze­niu biblio­tek i narzę­dzi, czę­sto też powie­la­ne są wyuczo­ne sta­re i złe prak­ty­ki pro­gra­mi­stycz­ne rodem z lat 60-tych (np. prak­ty­ki SmallTalk, patrz dalej). 

Z dru­giej stro­ny od wie­lu lat zna­ne są tech­ni­ki MDA (Model Driven Architecture) czy MBSE (Model Based System Engineering), któ­re w róż­nych for­mach, ale jed­nak wska­zu­ją, że naj­sku­tecz­niej­sza for­ma wyra­ża­nia wyma­gań wobec roz­wią­za­nia to pro­jekt archi­tek­tu­ry i logi­ki dzie­dzi­no­wej (model) dzia­ła­nia apli­ka­cji . O pro­jek­to­wa­niu poprze­dza­ją­cym imple­men­ta­cję pisze sie od dość daw­na, meto­dy obiek­to­we i dobre prak­ty­ki zna­ne są od lat .

Autorzy BABoK prak­tycz­nie od począt­ku ist­nie­nia tego wydaw­nic­twa, zwra­ca­ją uwa­gę na tak zwa­ną bia­łą skrzyn­kę”, czy­li wyma­ga­nia wyra­żo­ne w posta­ci wewnętrz­nej struk­tu­ry pro­duk­tu, wska­zu­jąc, że to znacz­nie sku­tecz­niej­sza meto­da defi­nio­wa­nia wyma­gań wobec roz­wią­za­nia, niż tak zwa­na czar­na skrzyn­ka”, czy­li tra­dy­cyj­ne, i jed­nak mniej sku­tecz­ne, wyma­ga­nia wyra­żo­ne tyl­ko jako cechy funk­cjo­nal­ne i poza-funk­cjo­nal­ne. Pamiętajmy, że adre­sa­tem wyma­gań jest zawsze dostaw­ca produktu!

(wię­cej…)

Czytaj dalejArchitektoniczne wzorce projektowe w analizie i projektowaniu modelu dziedziny systemu

Kastomizacja oprogramowania standardowego, aspekty ekonomiczne: Recenzja i rekomendacje

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

(wię­cej…)

Czytaj dalejKastomizacja oprogramowania standardowego, aspekty ekonomiczne: Recenzja i rekomendacje

Emocjonujące bramki czyli dogmaty vs. logika

W toku szko­leń, a tak­że audy­tów, powsta­ją nie raz spo­ry o inter­pre­ta­cje zna­cze­nia sym­bo­li nota­cji: ich seman­ty­ki i syn­tak­ty­ki (co ozna­cza­ją i jak je moż­na łączyć z inny­mi). Dzisiaj o dość czę­stym spo­rze czy­li bram­ki OR (inc­lu­si­ve) i XOR (exc­lu­si­ve) w nota­cji BPMN oraz o tym, że z 380 stron spe­cy­fi­ka­cji BPMN, w mode­lach ana­li­tycz­nych sto­su­je­my tyl­ko nie­ca­łe 40 stron roz­dzia­łu 7., pozo­sta­łe roz­dzia­ły słu­żą wyłącz­nie lep­sze­mu zro­zu­mie­niu teo­rii i mode­lom wyko­ny­wal­nym. Czyli dla­cze­go w ana­li­zach sto­su­je­my kil­ka, a nie kil­ka­dzie­siąt sym­bo­li nota­cji BPMN. 

(wię­cej…)

Czytaj dalejEmocjonujące bramki czyli dogmaty vs. logika

Dozwolony użytek programów komputerowych czyli o interfejsach

Wstęp

Dzisiejszy wpis to efekt lek­tu­ry arty­ku­łu Pani Mec. Marty Pasztaleniec na stro­nie IP Procesowo. Kluczowe dla dzi­siej­sze­go wpi­su jego frag­men­ty to:

Programy kom­pu­te­ro­we w świe­tle kra­jo­we­go pra­wa autor­skie­go korzy­sta­ją ze szcze­gól­nej ochro­ny. Z uwa­gi na ich spe­cy­fi­kę wyłą­czo­no sto­so­wa­nie nie­któ­rych regu­la­cji z ogól­nej czę­ści pra­wa autor­skie­go, w szcze­gól­no­ści prze­pi­sów doty­czą­cych dozwo­lo­ne­go użyt­ku, któ­ry umoż­li­wia w ści­śle okre­ślo­nych oko­licz­no­ściach korzy­sta­nie z utwo­rów bez zgo­dy twór­cy, a nawet wbrew takiej zgo­dzie. Co do zasa­dy zatem jakie­kol­wiek zwie­lo­krot­nie­nie pro­gra­mu kom­pu­te­ro­we­go wyma­ga zgo­dy twór­cy. […]
Spór ma swą gene­zę w 2005 r. kie­dy to Google nabył star­tup Android Inc i roz­po­czął sta­ra­nia by wejść na rynek smart­fo­nów, two­rząc plat­for­mę do budo­wy sys­te­mów dla urzą­dzeń mobil­nych. Platforma w swym zało­że­niu mia­ła być nie­od­płat­na po to by popu­la­ry­zo­wać śro­do­wi­sko Google. Jako że język pro­gra­mi­stycz­ny Java był wów­czas jed­nym z naj­bar­dziej popu­lar­nych i powszech­nych wśród pro­gra­mi­stów, Google pod­jął roz­mo­wy z Sun Microsystems ? twór­cą Java ? na temat licen­cjo­no­wa­nia całej plat­for­my Java. Ostatecznie zde­cy­do­wał się jed­nak na budo­wę wła­snej plat­for­my. Aby jed­nak zapew­nić jej powszech­ność i łatwość sto­so­wa­nia wśród pro­gra­mi­stów zasto­so­wa­no w nim nazwy funk­cji i for­ma­tów danych cha­rak­te­ry­stycz­ne dla języ­ka Javy. Google de fac­to opra­co­wał wła­sne odpo­wied­ni­ki funk­cji Javy i nadał im nazwy takie same jak w Javie. Oracle, po prze­ję­ciu spół­ki Sun Microsystems, pozwał w 2010 r. Google o naru­sze­nie przy­słu­gu­ją­cych Oracle praw autor­skich i paten­tów. Zarzucono Google sko­pio­wa­nie bli­sko 11 500 linii dekla­ra­cji API pro­gra­mu Java (co sta­no­wi­ło 0,4 % dekla­ra­cji). […]
Sąd uznał, że dzia­ła­nie Google było ?zgod­ne z kre­atyw­nym ?postę­pem?, któ­ry jest pod­sta­wo­wym kon­sty­tu­cyj­nym celem same­go pra­wa autor­skie­go?. Według sądu dozwo­lo­ny uży­tek peł­ni więc istot­ną rolę w roz­wo­ju opro­gra­mo­wa­nia, a pra­wo autor­skie nie powin­no hamo­wać tego roz­wo­ju. (żr.: Dozwolony uży­tek pro­gra­mów kom­pu­te­ro­wych ? jak Google poko­nał Oracle w USA).

Powyższy tekst wska­zu­je na dwa cie­ka­we aspek­ty opro­gra­mo­wa­nia, o któ­rych dzi­siaj napi­szę. Pierwszy to tak zwa­ny dozwo­lo­ny uży­tek, bar­dzo czę­sto przy­wo­ły­wa­ny w spo­rach o bez­płat­ne uży­cie opro­gra­mo­wa­nia i zakres tego uży­cia. Najczęściej doty­czy gier kom­pu­te­ro­wych ale nie tyl­ko. Drugi to cha­rak­ter opro­gra­mo­wa­nia, jakim jest kod źró­dło­wy będą­cy tek­stem, oraz efekt osta­tecz­ny, jakim jest kom­pu­ter reali­zu­ją­cy okre­ślo­ny mecha­nizm”, gdzie kom­pu­ter defi­niu­je­my jako pro­ce­sor, pamięć i pro­gram” . Warto tu zwró­cić uwa­gę na pewien dro­biazg”: autor­ka (jak wie­lu innych praw­ni­ków) trak­tu­je treść pro­gra­mu jako tekst” i nie raz sto­su­je ana­lo­gię do typo­wych utwo­rów pisa­nych takich jak pro­za czy poezja, co jest poważ­nym błę­dem. Fragmenty tek­stów (esej, pra­ca dok­tor­ska, powieść, itp.) bar­dzo czę­sto mają war­tość, cze­go o nie moż­na powie­dzieć o opro­gra­mo­wa­niu (nie dzia­ła w kawał­kach). Owszem, moż­na potrak­to­wać frag­men­ty kodu lite­ra­tu­ro­wo”, jako przy­kła­dy jego struk­try i skład­ni (np. lite­ra­tu­ra na temat wzor­ców pro­jek­to­wych w inży­nie­rii opro­gra­mo­wa­nia), jed­nak nie moż­na mówić o frag­men­cie kodu, że to opro­gra­mo­wa­nie”, gdyż to z zasa­dy musi dzia­łać”, a jest to moż­li­we tyl­ko wte­dy gdy do kom­pu­te­ra zała­du­je­my kom­plet­ny pro­gram a nie cyto­wa­ny fragment”.

(wię­cej…)

Czytaj dalejDozwolony użytek programów komputerowych czyli o interfejsach

Diagram aktywności UML – kiedy

Wstęp

Od cza­su do cza­su jestem pyta­ny o to, kie­dy uży­wać dia­gra­mu aktyw­no­ści UML. Od 2015 roku spe­cy­fi­ka­cja UML wska­zu­je, że dia­gra­my te są narzę­dziem mode­lo­wa­nia metod czy­li logi­ki kodu (dla Platform Independent Model): aktyw­no­ści (acti­vi­ties) to nazwy metod, zadania/kroki (actions) to ele­men­ty kodu (przy­kła­dy w dal­szej części). 

Gdy powsta­wał UML, dia­gra­my aktyw­no­ści były uży­wa­ne tak­że do mode­lo­wa­nie pro­ce­sów biz­ne­so­wych. W roku 2004 opu­bli­ko­wa­no spe­cy­fi­ka­cję nota­cji BPMN, któ­ra w zasa­dzie do roku 2015 prze­ję­ła” po UML funk­cję narzę­dzia mode­lo­wa­nia pro­ce­sów biz­ne­so­wych. W 2015 roku for­mal­nie opu­bli­ko­wa­no spe­cy­fi­ka­cję UML 2.5, gdzie gene­ral­nie zre­zy­gno­wa­no z uży­wa­nia UML do mode­li CIM. Obecnie Mamy usta­bi­li­zo­wa­ną sytu­ację w lite­ra­tu­rze przed­mio­tu: BPMN wyko­rzy­stu­je­my w mode­lach CIM (mode­le biz­ne­so­we), UML w mode­lach PIM i PSM jako mode­le opro­gra­mo­wa­nia (a mode­le sys­te­mów: SysML, pro­fil UML). 

Na prze­ło­mie lat 80/90-tych roz­po­czę­to pra­ce nad stan­da­ry­za­cję nota­cji mode­lo­wa­nia obiek­to­we­go, w 1994 opu­bli­ko­wa­no UML 0.9, w 2001 roku poja­wia­ją się pierw­sze publi­ka­cje o pra­cach nad nota­cją BPMN, jed­no­cze­śnie poja­wia się Agile Manifesto, od 2004 roku ma miej­sce spa­dek zain­te­re­so­wa­nia doku­men­to­wa­niem pro­jek­tów pro­gra­mi­stycz­nych, w 2004 rok publi­ko­wa­no spe­cyf­ka­cję BPMN 1.0, od tego roku ma miej­sce wzrost zain­te­re­so­wa­nia mode­lo­wa­niem pro­ce­sów biz­ne­so­wych, powo­li sta­bi­li­zu­je się obszar zasto­so­wa­nia nota­cji UML. W 2015 roku opu­bli­ko­wa­no UML 2.5, sto­so­wa­nie ana­li­zy (CIM) i i pro­jek­to­wa­nia (PIM), jako eta­pu poprze­dza­ją­ce­go imple­men­ta­cje, sta­ło się stan­dar­dem (źr. wykre­su: Google Ngram).

Tak więc obecnie: 

Nie uży­wa­my dia­gra­mów aktyw­no­ści do mode­lo­wa­nia pro­ce­sów biz­ne­so­wych. Do tego słu­ży nota­cja BPMN!

Diagram aktyw­no­ści może być mode­lem kodu na wyso­kim lub niskim pozio­mie abs­trak­cji, ope­ru­je­my wte­dy odpo­wied­nio aktyw­no­ścia­mi (acti­vi­ty) lub dzia­ła­nia­mi (actions). Te ostat­nie to w zasa­dzie repre­zen­ta­cja pole­ceń programu. 

Nie ma cze­goś takie­go jak pro­ces sys­te­mo­wy”, opro­gra­mo­wa­nie reali­zu­je pro­ce­du­ry”.

Projektując opro­gra­mo­wa­nie zgod­nie ze SPEM , powsta­je Platform Independent Model. W prak­ty­ce już na tym eta­pie pro­gra­mu­je­my, bo two­rzy­my logi­kę i obraz przy­szłe­go kodu. Taka for­ma doku­men­to­wa­nia pozwa­la tak­że lepiej chro­nic war­to­ści inte­lek­tu­al­ne zamawiającego.

(wię­cej…)

Czytaj dalejDiagram aktywności UML – kiedy

SPEM czyli Software & Systems Process Engineering

Tym razem arty­kuł adre­so­wa­ny do zaawan­so­wa­nych analityków. 

Ta spe­cy­fi­ka­cja (SPEM) jest dato­wa­na na 2008 rok. Stanowi sobą tło dla MDA oraz uza­sad­nia wzor­ce pro­jek­to­wa­ne opar­te na przy­pad­kach uży­cia (mikro­ser­wi­sy, Use Case 2.0, inne podob­ne). Podstawowa róż­ni­ca mię­dzy spe­cy­fi­ka­cją SPEM a spe­cy­fi­ka­cją UML pole­ga na tym, że UML to pro­fi­le MOF sta­no­wią­ce opi­sy nota­cji i sys­te­mów poję­cio­wych. SPEM to meta­mo­del pro­ce­su wytwór­cze­go opro­gra­mo­wa­nia czy­li gene­ral­ne zasa­dy budo­wa­nia pro­ce­sów wytwa­rza­nia i dostar­cza­nia oprogramowania. 

(wię­cej…)

Czytaj dalejSPEM czyli Software & Systems Process Engineering

Modele as-is i to-be, czy warto je robić?

Z zamiarem napisania tego tekstu noszę się już od kilku lat i za każdym razem mówiłem sobie: "ok, jeszcze tylko skończę ten jeden projekt i zobaczymy czy faktycznie ma to sens". I tak od kilku lat. W końcu jednak udało się. Wprowadzenie Popularność podejścia do modeli procesów biznesowych, polegającego na "pokazaniu różnicy", trwa od czasów popularyzacji re-inżynierii procesów biznesowych (lata 90-te) . Umowy na usługi, zawierające w zakresie opracowanie modelu 'as-is' i 'to-be' nadal są podpisywane. Zakładam, że decyzje o zakresie projektu to indywidualne potrzeby zamawiających. Ja opiszę swoje doświadczenia…

Czytaj dalejModele as-is i to-be, czy warto je robić?

Be IT 2021 – po konferencji

W Sobotę 22 maja 2021, na konferencji Be IT 2021 organizowanej przez Koło Naukowe Zarządzanie IT Politechniki Gdańskiej, poprowadziłem warsztat: Analiza i projektowanie struktury informacji. Z uwagi na tematykę: rzeczy dla uczestników nowe, takie jak chmurowe repozytoria i dokumentowe bazy danych NoSQL, poprowadziłem go jako konwersatorium omawiając przykłady repozytoriów NoSQL oferowane w chmurze publicznej oraz omawiając wcześniej przygotowany prosty przykład aplikacji dla Biblioteki, zbudowany z użyciem omówionych wzorców dla baz dokumentowych i notacji UML. Jak co roku otrzymałem ankietę i jak zawsze postanowiłem się z niej wytłumaczyć, a także przyjąć…

Czytaj dalejBe IT 2021 – po konferencji

Krótka historia pewnego wymagania

Wprowadzenie Zarówno w projektach jak i w dyskusjach np. na konferencjach czy na LinkedIn, pojawia się stale pewne nieporozumienie: "projektowanie to waterfall". Myśli tak każdy, kto wyobraża sobie, że projekt czegoś to jakaś masa wszystkich możliwych detali. Jednocześnie nie ja jeden widuję "Dokumenty analizy biznesowej" albo "Dokumenty wymagań" zawierające setki pozycji o treści "system powinien...", nie raz wykonane przez krytyków "water fall", którzy reprezentując developera deklarującego metody "agile", "zabezpieczają się" przez odpowiedzialnością za zakres projektu. Pierwsza ważna uwaga: projekt systemu to nie jest ani zestaw dziesiątków "user story" ani detaliczna…

Czytaj dalejKrótka historia pewnego wymagania

Kod open source, prawa do niego i jego wartość

Na stronach portalu LindekIn ukazał sie bardzo dobry artykuł autorstwa Marcina Maruty z kancelarii Maruta Wachta sp.j., na temat oprogramowania open source: Barierą technologiczną jest brak dostępu do kodu źródłowego, niezbędnego dla wprowadzania zmian i rozwoju oprogramowania. Barierą prawną jest natomiast bardzo szeroki zakres ochrony programów komputerowych, który sprawia że jakakolwiek forma korzystania z programu, w tym jego modyfikowanie, wymagają uzyskania zgody uprawnionego. Ruch Open Source, wyrósł ze sprzeciwu wobec takiego stanu rzeczy, stawia sobie za cel tworzenie i popularyzowanie programów ?otwartych?, ?wolnych?, a więc dostępnych wraz z kodem źródłowym…

Czytaj dalejKod open source, prawa do niego i jego wartość

Koniec treści

Nie ma więcej stron do załadowania