Zwinne projektowanie interfejsu użytkownika

W ostat­nim arty­ku­le zwra­ca­łem uwa­gę mię­dzy inny­mi na bar­dzo waż­ny ele­ment ana­li­zy i pro­jek­to­wa­nia jakim jest abs­tra­ho­wa­nie od deta­li, ponieważ: 

…ana­li­tyk musi abs­tra­ho­wać od wszel­kich deta­li, bez tego pro­jekt zosta­nie już na samym począt­ku ?zabi­ty? ich ilo­ścią. [1]

Nieco wcze­śniej (2013 r.) pisa­łem o tym, kie­dy uzgad­niać deta­le, któ­re i gdzie one są: 

Cała logi­ka biz­ne­so­wa jest wyko­ny­wa­na wewnątrz apli­ka­cji (infor­ma­cje o ewen­tu­al­nych błę­dach poja­wią się po zatwier­dze­niu for­mu­la­rza), np. upust może być spraw­dzo­ny (albo nali­czo­ny) dopie­ro po skom­ple­to­wa­niu danych wyma­ga­nych do jego wyli­cze­nia, czy­li będzie to kil­ka róż­nych pól (naj­mniej dwa :)). Bywa, że do wyli­cze­nia cze­goś potrzeb­ne będą dane nie wpro­wa­dza­ne do danej for­mat­ki fak­tu­ry, np. sal­do klien­ta. [2]

Tym razem kil­ka słów o tym jak skom­pli­ko­wać i zabić pro­jekt już pierw­sze­go dnia. Jednym z naj­bar­dziej ryzy­kow­nych spo­so­bów roz­po­czy­na­nia pro­jek­tu jest roz­po­czy­na­nie od kon­sul­ta­cji z użyt­kow­ni­kiem w kwe­stii inter­fej­su użyt­kow­ni­ka. Prowadzi to do sytu­acji, w któ­rej jesz­cze nie mamy żad­ne­go poję­cia o logi­ce biz­ne­so­wej i archi­tek­tu­rze apli­ka­cji, a już dekla­ru­je­my to jak będzie się ona komu­ni­ko­wa­ła z użyt­kow­ni­kiem (cie­ka­we na jakiej podstawie?). 

Do napi­sa­nia tego arty­ku­łu skło­nił mnie ten wpis:

The role of design still puz­zles many agi­le teams I work with. When sho­uld the design acti­vi­ties take pla­ce? Who sho­uld car­ry them out? How are design deci­sions best cap­tu­red? This blog tries to answer the questions by discus­sing a user-cen­tric, ite­ra­ti­ve, and col­la­bo­ra­ti­ve design pro­cess for Scrum and Kanban teams. [3]

Autor poka­zu­je jak wal­czy” ze zło­żo­no­ścią na tym eta­pie, ja pra­gnę zasu­ge­ro­wać by do tej zło­żo­no­ści na tym eta­pie po pro­stu nie dopusz­czać. Powyższy dia­gram poka­zu­je z czym wal­czy ana­li­tyk, któ­ry dopro­wa­dzi do zebra­nia wyrwa­nych z kon­tek­stu (tak, nie ma mode­lu logi­ki więc dys­ku­sje o GUI są ode­rwa­ne od kon­tek­stu) wyma­gań” (histo­ryj­ki użyt­kow­ni­ka, lewa kolum­na tabli­cy Story Area), któ­rych zama­wia­ją­cy może naopo­wia­dać” bar­dzo dużo.

A jak ina­czej? Pomoże nam sto­so­wa­nie wzor­ców archi­tek­to­nicz­nych. Są one od lat dostęp­ne w więk­szo­ści fra­me­wor­ków (szko­da, że bar­dzo czę­sto deve­lo­pe­rzy je igno­ru­ją). Poniżej pro­sty, abs­trak­cyj­ny model kla­sycz­ne­go wzor­ca MVC.

W archi­tek­tu­rze wydzie­la się kom­po­nen­ty (sepa­ro­wa­nie odpo­wie­dzial­no­ści): odpo­wie­dzial­ny za obsłu­gę dia­lo­gu z użyt­kow­ni­kiem (View), odpo­wie­dzial­ny za tech­no­lo­gie, jakość, bez­pie­czeń­stwo, ste­ro­wa­nie itp. (Controler) oraz odpo­wie­dzial­ny za (całą a nie tyl­ko dane!) logi­kę biz­ne­so­wą (Model). 

Zarządzanie zło­żo­no­ścią pole­ga tu na tym, by na począt­ku ana­li­zy i pro­jek­to­wa­nia abs­tra­ho­wać cał­ko­wi­cie od deta­li GUI! (a dokład­nie od całej tech­no­lo­gii czy­li ele­men­tów View i Contoler). Kluczową odpo­wie­dzial­no­ścią apli­ka­cji jest reali­za­cja okre­ślo­nej logi­ki biz­ne­so­wej. Na tym eta­pie powi­nien powstać model przy­pad­ków uży­cia rozu­mia­ny jako pro­sty dia­log pomię­dzy użyt­kow­ni­kiem a apli­ka­cją, tu celem jest uchwy­ce­nie klu­czo­wych wyma­gań jaki­mi są wyma­ga­ne usłu­gi apli­ka­cyj­ne reali­zo­wa­ne przez apli­ka­cję oraz opra­co­wa­nie wewnętrz­nej archi­tek­tu­ry – Modelu, któ­ra te usłu­gi zre­ali­zu­je. Dopiero po prze­te­sto­wa­niu całej logi­ki biz­ne­so­wej na mode­lach, war­to się zabie­rać na kom­pli­ko­wa­nie pro­jek­tu poprzez opra­co­wa­nie deta­li GUI, ste­ro­wa­nia, bez­pie­czeń­stwa itp.. Postępowanie takie umoż­li­wia wzo­rzec archi­tek­to­nicz­ny MVVM opra­co­wa­ny ponad 10 lat temu. Wzorzec ten wpro­wa­dza dodat­ko­wy kom­po­nent pomię­dzy kom­po­nen­ty View i Model: View-Model, któ­ry reali­zu­je logi­kę dia­lo­gu GUI-użyt­kow­nik. Dzięki temu może­my wydzie­lić etap pra­cy nad GUI, jako osob­ny w pro­jek­cie, któ­ry zre­ali­zu­je (póź­niej) tak zwa­ny UX desi­gner”, a deve­lo­per zamie­ni pier­wot­nie abs­trak­cyj­ny kom­po­nent View na imple­men­ta­cje View-View Model”.

Bardzo dobry opis tego podejścia:

W przy­pad­ku war­stwy pre­zen­ta­cji moż­na wyko­rzy­stać m. in. nastę­pu­ją­ce roz­wią­za­nia: MVC, MVP czy Model-View-ViewModel. Ze wzglę­du na mecha­nizm wią­zań (bin­ding), pro­gra­mi­stom WPF oraz Silverlight, pole­ca­ny jest wzo­rzec MVVM ? jest to tech­no­lo­gia umoż­li­wia­ją­ca bar­dzo łatwą imple­men­ta­cję wzor­ca. […] …po co utrud­niać sobie zada­nie poprzez wyko­rzy­sty­wa­nie MVVM, zamiast pisać apli­ka­cję w kla­sycz­ny spo­sób (za pomo­cą code-behind)? W koń­cu wdro­że­nie prak­tycz­nie każ­de­go wzor­ca pro­jek­to­we­go wyma­ga tro­chę więk­szych począt­ko­wych nakła­dów pra­cy.

Podejście Code-Behind (auto­no­mo­us view ? AV) ma poważ­ną wadę ? nie gwa­ran­tu­je ela­stycz­no­ści oraz testo­wal­no­ści. Podsumowując, wpro­wa­dze­nie wzor­ca [MVVM, przy­pis auto­ra] umożliwia:

  • nie­za­leż­ność logi­ki od spo­so­bu wyświe­tla­nia danych,
  • nie­za­leż­ność kodu od tech­no­lo­gii, w któ­rej wyko­na­na jest war­stwa prezentacji,
  • wyko­ny­wa­nie testów ? za pomo­cą MVVM czy MVP moż­li­we jest wyko­na­nie testów zauto­ma­ty­zo­wa­nych (np. jednostkowych),
  • łatwą zamia­nę wido­ków (brak sztyw­nych powią­zań mię­dzy wido­kiem a logi­ką). [4]

(Tak: sto­so­wa­nie wzor­ców pod­no­si począt­ko­wą pra­co­chłon­ność ale zwra­ca się z nawiąz­ką w dal­szych cyklach życia pro­jek­tu.) Strukturę i histo­rię powsta­nia tej archi­tek­tu­ry zain­te­re­so­wa­ni mogą poznać tak­że tu: 

Model View View Model (MVVM) 
In 2005, John Gossman, Architect at Microsoft, unve­iled the Model-View-ViewModel (MVVM) pat­tern on his blog. MVVM is iden­ti­cal to Fowler?s Presentation Model, in that both pat­terns featu­re an abs­trac­tion of a View, which con­ta­ins a View?s sta­te and beha­vior. Fowler intro­du­ced Presentation Model as a means of cre­ating a UI plat­form-inde­pen­dent abs­trac­tion of a View, whe­re­as Gossman intro­du­ced MVVM as a stan­dar­di­zed way to leve­ra­ge core featu­res of WPF and Silverlight to sim­pli­fy the cre­ation of user inter­fa­ces. MVVM is a spe­cia­li­za­tion of the more gene­ral PM pat­tern, tailor-made for the WPF and Silverlight plat­forms to leve­ra­ge core featu­res of WPF such as data bin­ding, com­mands , templates.

This dia­gram take from MSDN depicts MVVM Pattern in action.

image[5]

Tak więc ana­li­zę i pro­jek­to­wa­nie war­to zacząć od logi­ki i szkie­le­tu archi­tek­tu­ry, a ta to przede wszyst­kim Model (dzie­dzi­ny) sys­te­mu czy­li kom­plet­na logi­ka biz­ne­so­wa (utoż­sa­mia­nie mode­lu dzie­dzi­ny z rela­cyj­ną bazą danych to poważ­ny błąd i nie­po­ro­zu­mie­nie). Po upo­ra­niu się z tym eta­pem pro­jek­tu ma sens opra­co­wy­wa­nie deta­li komu­ni­ka­cji z użyt­kow­ni­kiem, bo dopie­ro teraz zna­my wyma­ga­nia i ogra­ni­cze­nia logi­ki biz­ne­so­wej. Odkrywanie ich dopie­ro na eta­pie pro­to­ty­po­wa­nia to sta­now­czo za póź­no, bo gene­ru­je to ogrom­ne kosz­ty cyklicz­ne­go refak­to­rin­gu kodu (albo kod szyb­ko sta­je się bry­łą błota”). 

Bardzo czę­sto sły­szę, że klient chce jak naj­szyb­ciej coś zoba­czyć. Rzecz w tym, że jeże­li się na to zgo­dzi­my, powsta­je i jest akcep­to­wa­na masa tak zwa­nych poboż­nych życzeń”, a klient bar­dzo szyb­ko się przy­wią­zu­je do tego co zoba­czył na pre­zen­ta­cji (i nie chce odpu­ścić). W efek­cie two­rzy się spi­ra­la żądań, testów i popra­wek, któ­re szyb­ko prze­kształ­ca­ją agi­le” w poraż­kę budże­tu i har­mo­no­gra­mu. Praktyka poka­zu­je, że budżet zawsze ma limit, dla­te­go bar­dzo wie­le takich pro­jek­tów koń­czy albo w koszu na śmie­ci albo efek­ty sta­no­wią tyl­ko namiast­kę tego co opi­sy­wa­ła pier­wot­na wizja. Jeżeli zaś zacznie­my od jądra sys­te­mu a na koniec zosta­wi­my sobie maki­jaż” jakim jest GUI, szan­sa na suk­ces będzie znacz­nie więk­sza. Problem pole­ga na tym, że moda na user-cen­tric, ite­ra­ti­ve, and col­la­bo­ra­ti­ve design” jest sil­na mimo tego, że jest przy­czy­ną wie­lu porażek. 

Tak więc odpo­wiedź na pyta­nie jak pora­dzić sobie z życze­nia­mi biz­ne­su, brzmi: nie dopusz­czać do ich wyar­ty­ku­ło­wa­nia :). Projektowanie i two­rze­nie samo­cho­du roz­po­czy­na się od pod­wo­zia i napę­du a nie od deski rozdzielczej…

Bibliografia

[1]
J. Zelinski, ?Model czy abs­trak­cja?, Jarosław Żeliński IT-Consulting, 22-wrz-2017. [Online]. Available: https://it-consulting.pl//2017/09/22/model-czy-abstrakcja/. [Udostępniono: 25-wrz-2017]
[2]
J. Zelinski, ?Gdzie są te cho­ler­ne szcze­gó­ły?, Jarosław Żeliński IT-Consulting, 18-cze-2014. [Online]. Available: https://it-consulting.pl//2014/06/18/gdzie-sa-te-cholerne-szczegoly/. [Udostępniono: 25-wrz-2017]

MDA – Cztery produkty czyli dwa etapy: wymagania i produkt

Ten arty­kuł moż­na czy­tać na dwa spo­so­by: ana­li­ty­cy czy­ta­ją od dechy do dechy po kolei ;). Menedżerowie i tak zwa­ny biz­nes czy­ta­ją od razu koniec, to jest część Na zakoń­cze­nie, gdy uzna­ją, że nie wie­rzą w te wnio­ski (wyrok) to zaczy­na­ją od począt­ku czy­li czy­ta­ją uzasadnienie :).

Niedawno napi­sa­łem:

Pomiędzy poję­cia­mi abs­trak­cja i model jest pew­na klu­czo­wa róż­ni­ca: abs­trak­cja to poję­cie zaś model to opis mecha­ni­zmu, jego kon­struk­cja, dzia­ła­nie, budo­wa. Prosty przy­kład: nazwa­ne pro­sto­ką­ty na typo­wym dia­gra­mie struk­tu­ry orga­ni­za­cyj­nej to abs­trak­cje komó­rek orga­ni­za­cyj­nych i osób w nich zatrud­nio­nych, pro­sto­ką­ty te wraz z linia­mi je łączą­cy­mi sta­no­wią, jako całość, model pod­le­gło­ści zaso­bów w orga­ni­za­cji. (Źródło: Analiza a mode­lo­wa­nie czy­li ile abs­trak­cji a ile rze­czy­wi­sto­ści | | Jarosław Żeliński IT-Consulting)

Kontynuując temat z innej per­spek­ty­wy powie­my sobie teraz o eta­pach ana­li­zy i pro­jek­to­wa­nia w inży­nie­rii, nie tyl­ko opro­gra­mo­wa­nia, w opar­ciu o MDA ([[Model Driven Architecture]], www​.omg​.org/​mda, pole­cam tak­że poję­cie [[model dri­ven engi­ne­ering]]). Dobra infor­ma­cja dla czy­tel­ni­ków: na koń­cu się wszyst­ko wyja­śni, moż­na pomi­nąć część o MDA 🙂

MDA

Pięć lat temu, jeden z arty­ku­łów o mode­lo­wa­niu i pro­jek­to­wa­niu, koń­czy­łem tymi słowami:

Podsumowując moż­na by powie­dzieć, że eta­py two­rze­nia opro­gra­mo­wa­nia to:

  1. Analiza biz­ne­so­wa, któ­rej pro­duk­tem są: model orga­ni­za­cji (model biz­ne­so­wy) oraz opis tego co ma powstać (opis, wyma­ga­nia na opro­gra­mo­wa­nie). Całość (sfor­ma­li­zo­wa­ne mode­le) pozwa­la na prze­te­sto­wa­nie czy tak okre­ślo­ne wyma­ga­nia speł­nia­ją potrze­by biznesu.
  2. Wytworzenie opro­gra­mo­wa­nia pole­ga­ją­ce na: opra­co­wa­niu szcze­gó­łów archi­tek­tu­ry, roz­wią­za­niu pro­ble­mów tech­nicz­nych (wyma­ga­nia nie­funk­cjo­nal­ne), kodo­wa­niu oraz dostar­cze­niu i wdrożeniu.

Źródło: Hej, Biznesie, to ma być dla biz­ne­su czy­li dla Ciebie! | | Jarosław Żeliński IT-Consulting

Powoływałem się w tym tek­ście wła­śnie na MDA. Czymże to jest? Na stro­nach OMG znaj­dzie­my: Document – ormsc/14 – 06-01 (MDA Guide revi­sion 2.0) Contact: Dr. Jon M. SiegelThis final draft of the revi­sed MDA Guide edi­ted in Boston on 18 June 2014 reflects all AB edits requ­ested at the Reston and Boston AB meetings. (Źródło: OMG Document – ormsc/14 – 06-01 (MDA Guide revi­sion 2.0)

Skorzystam z kil­ku cyta­tów i napi­sze co nie­co o MDA. Poniżej klu­czo­we tezy, nie mia­łem tu ambi­cji lite­ral­ne­go tłu­ma­cze­nia tego doku­men­tu, cho­dzi­ło mi o pryncypia.

This guide descri­bes the Model Driven Architecture (MDA) appro­ach as defi­ned by the Object Management Group (OMG). MDA pro­vi­des an appro­ach for deri­ving value from models and archi­tec­tu­re in sup­port of the full life cyc­le of phy­si­cal, orga­ni­za­tio­nal and I.T. sys­tems (A ?System?, in this con­text, is any arran­ge­ment of parts and the­ir inter­re­la­tion­ships, wor­king toge­ther as a who­le.). The MDA appro­ach repre­sents and sup­ports eve­ry­thing from requ­ire­ments to busi­ness mode­ling to tech­no­lo­gy imple­men­ta­tions. By using MDA models, we are able to bet­ter deal with the com­ple­xi­ty of lar­ge sys­tems and the inte­rac­tion and col­la­bo­ra­tion betwe­en orga­ni­za­tions, people, har­dwa­re, software.

Stosowanie mode­li pozwa­la znacz­nie lepiej radzić sobie ze zło­żo­no­ścią wiel­kich sys­te­mów jaki­mi są orga­ni­za­cje oraz funk­cjo­nu­ją­ce w nich związ­ki mię­dzy ludź­mi, opro­gra­mo­wa­niem i infra­struk­tu­rą. Fakt, że bada­ne orga­ni­za­cje współ­pra­cu­ją z inny­mi, dodat­ko­wo kom­pli­ku­je tę całość.

Models as com­mu­ni­ca­tions vehicles

A fun­da­men­tal value pro­po­si­tion for models and mode­ling is to faci­li­ta­te a team or com­mu­ni­ty coming to a com­mon under­stan­ding and/or consensus.

Jedną z głów­nych ról mode­li, poza ich ana­li­zą, jest komu­ni­ka­cja: komu­ni­ku­je­my innym człon­kom zespo­łu (tak­że klien­tom) to co zro­zu­mie­li­śmy i to cze­go ocze­ku­je­my. Tak więc mode­le są zarów­no opi­sem rze­czy­wi­sto­ści powsta­łym w toku jej zro­zu­mie­nia, są tak­że opi­sem tego co ma powstać, jeże­li chce­my tę rze­czy­wi­stość stworzyć.

[?]Abstraction deals with the con­cepts of under­stan­ding a sys­tem in a more gene­ral way; said in more ope­ra­tio­nal terms, with abs­trac­tion one eli­mi­na­tes cer­ta­in ele­ments from the defi­ned sco­pe; this may result in intro­du­cing a higher level view­po­int at the expen­se of remo­ving deta­il. A model is con­si­de­red more abs­tract if it encom­pas­ses a bro­ader set of sys­tems and less abs­tract if it is more spe­ci­fic to a sin­gle sys­tem or restric­ted set of systems. [?]

Podstawową rze­czą w ana­li­zie jest redu­ko­wa­nie szcze­gó­łów i uogól­nia­nie. Człowiek nie jest w sta­nie ana­li­zo­wać cze­goś co skła­da się z setek detali.

Model Analytics

Once models are cap­tu­red as seman­tic data vario­us ana­ly­tics can be exe­cu­ted across tho­se models inc­lu­ding model vali­da­tion, sta­ti­stics and metrics. Analytics assi­sts in deci­sion making, moni­to­ring and quali­ty asses­sment. OMG MDA Guide rev. 2.0 June 2014 page 2

Modele poję­cio­we i ana­li­tycz­ne słu­żą do zro­zu­mie­nia bada­nej rze­czy­wi­sto­ści. Modele two­rzo­ne (pro­jek­to­wa­nie) słu­żą do testo­wa­nia pomy­słów i podej­mo­wa­nia decy­zji, dalej zaś sta­no­wią opis cech wyma­ga­ne­go roz­wią­za­nia. Modele wyko­ny­wal­ne to inne mode­le ale bazu­ją na mode­lach ana­li­tycz­nych. Poniżej, na bazie MOF ([[Meta Object Facility]]), poka­za­no trzy pozio­my abs­trak­cji (poziom zero­wy to rzeczywistość).

poziomy-abstrakcji

Abstrakcja to uprosz­czo­ny” (pozba­wio­ny zbęd­nych szcze­gó­łów) model okre­ślo­nej rze­czy­wi­sto­ści. Metamodel to mecha­nizm two­rze­nia tej rze­czy­wi­sto­ści w tym tak­że model poję­cio­wy (wię­cej w dal­szej części).

Model (M1) więc jest albo wyni­kiem (pro­duk­tem) ana­li­zy bada­nej rze­czy­wi­sto­ści, albo wyni­kiem (pro­duk­tem) pro­ce­su jej pro­jek­to­wa­nia (pro­jek­to­wa­nia rozwiązania). 

Model Simulation and Execution

Models as data can dri­ve simu­la­tion engi­nes that can assist in both ana­ly­tics and exe­cu­tion of the desi­gns cap­tu­red in models. Simulation assi­sts in the human under­stan­ding of how a mode­led sys­tem will func­tion as well as a way to vali­da­te that models are cor­rect. Models can, in some cases be direc­tly exe­cu­ted ? serving as the ?sour­ce code? for high­le­vel appli­ca­tions that imple­ment pro­ces­ses, data repo­si­to­ries and servi­ce end­po­ints. Model exe­cu­tion pro­vi­des a direct and imme­dia­te path to reali­zing a design with a mini­mum of tech­ni­cal deta­ils being expo­sed. DBMS Schema and pro­cess models are well-known cate­go­ries of (par­tial­ly) exe­cu­ta­ble models.[?]

Modele symu­la­cyj­ne słu­żą do testo­wa­nia hipo­tez i podej­mo­wa­ni decy­zji. Modele wyko­ny­wal­ne, w tym two­rzo­ne auto­ma­tycz­nie na bazie mode­li abs­trak­cyj­nych, to narzę­dzia do two­rze­nia wyko­ny­wal­ne­go kodu. Nie tyl­ko w moim mnie­ma­niu, jest to albo dale­ka przy­szłość (mam na myśli komer­cyj­ne zasto­so­wa­nia) albo wyłącz­nie aka­de­mic­kie bada­nia. Wiem, że są uda­ne pró­by gene­ro­wa­nia dzia­ła­ją­ce­go kodu z mode­li, jed­nak wyma­ga­nia na ilość deta­li, jakie trze­ba zade­kla­ro­wać w tych mode­lach, zbli­ża ich zło­żo­ność do zło­żo­no­ści kodu jaki powsta­je. Nie będzie­my się tu zaj­mo­wa­li mode­la­mi wykonywalnymi.

Cztery produkty

Te dwa opi­sa­ne na począt­ku eta­py do ana­li­za sys­te­mo­wa orga­ni­za­cji (potocz­nie ana­li­za biz­ne­so­wa”) oraz imple­men­ta­cja roz­wią­za­nia. Produkty to …

MDA to archi­tek­tu­ra mają­ca trzy pozio­my mode­lo­wa­nia, nazy­wa­ne od góry” CIM (Computation Independent Model), PIM (Platform Independent Model) i PSM (Platform Specific Model).

Architectural Layers It is use­ful to iden­ti­fy par­ti­cu­lar ?lay­ers? of an archi­tec­tu­re with respect to its level of abs­trac­tion. While the­re can be any num­ber of archi­tec­tu­ral lay­ers, a bro­ad cate­go­ri­za­tion of this con­cept is:

  • Business or doma­in models ? models of the actu­al people, pla­ces, things, and laws of a doma­in. The ?instan­ces? of the­se models are ?real things?, not repre­sen­ta­tions of tho­se things in an infor­ma­tion sys­tem. In MDA doma­in models have histo­ri­cal­ly been cal­led a ?CIM? for ?Computation Independent Model?.
  • Logical sys­tem models ? models of the way the com­po­nents of a sys­tem inte­ract with each other, with people and with orga­ni­za­tions to assist an orga­ni­za­tion or com­mu­ni­ty in achie­ving its goals. [model PIM]
  • Implementation models ? the way in which a par­ti­cu­lar sys­tem or sub­sys­tem is imple­men­ted such that it car­ries out its func­tions. Implementation models are typi­cal­ly tied to a par­ti­cu­lar imple­men­ta­tion tech­no­lo­gy or plat­form. [model PSM].

Model CIM opi­su­je ludzi i ich związ­ki, miej­sca, pra­wa rzą­dzą­ce tym wszyst­kim. Ten model opi­su­je real­ną, bada­ną rze­czy­wi­stość cał­ko­wi­cie abs­tra­hu­jąc od wyko­rzy­sty­wa­nych ewen­tu­al­nie posia­da­nych narzę­dzi infor­ma­tycz­nych (w przy­pad­ku start-up’u lub roz­wo­ju orga­ni­za­cji jest to przy­szła jej postać). Nie jest to model jakie­go­kol­wiek opro­gra­mo­wa­nia ani tego jak ono dzia­ła. Produktem tego eta­pu są: mode­le pro­ce­sów biz­ne­so­wych, spe­cy­fi­ka­cja reguł biz­ne­so­wych, biz­ne­so­wy słow­nik pojęć i mode­le pojęciowe.

Model PIM opi­su­je kom­po­nen­ty apli­ka­cji, ich wza­jem­ne inte­rak­cje, logi­kę dzia­ła­nia tych kom­po­nen­tów (ta część logi­ki opi­sa­nej w mode­lu CIM, któ­ra ma być reali­zo­wa­na w apli­ka­cji). Produktem tego eta­pu są mode­le: przy­pad­ków uży­cia (w tym postać nośni­ków danych, moc­ku­p’y ekra­nów), kom­po­nen­tów, wewnętrz­ne struk­tu­ry kom­po­nen­tów (mode­le dzie­dzi­ny z per­spek­ty­wy wzor­ca MVC), inte­rak­cji, inne jeśli konieczne.

Model PSM to model będą­cy pro­jek­tem wyko­naw­czym. Jest to roz­sze­rze­nie mode­lu PIM, uszcze­gó­ło­wie­nie go wraz z dodat­ko­wy­mi ele­men­ta­mi tech­nicz­ny­mi (reali­zu­ją­cy­mi śro­do­wi­sko, bez­pie­czeń­stwo, wyma­ga­ną wydaj­ność itp.). Kod apli­ka­cji to mate­ria­li­za­cja (imple­men­ta­cja) mode­lu PSM. 

Powyższe, to czte­ry pro­duk­ty powsta­ją­ce w tym pro­ce­sie. Dlaczego pisze o dwóch eta­pach? Poniżej wyjaśnienie.

model-driven-architecture-structure

Diagram obra­zu­je produkty/fazy defi­nio­wa­ne jako MDA. Każdy pro­dukt ana­li­zy to okre­ślo­ny zestaw mode­li. Na dia­gra­mie wska­za­no jakich nota­cji uży­wa się w każ­dym z nich (tu bazu­jąc na nota­cjach rodem z OMG). Tu przy­po­mi­nam to co już nie raz pisa­łem: celem jest zro­zu­mie­nie (i two­rze­nia potrzeb­nych w danym przy­pad­ku mode­li) oraz prze­ka­za­ne tej wie­dzy, a nie two­rze­nie jakichś mode­li i doku­men­tów”. Każdy model, jego powsta­nie, ma okre­ślo­ny cel.

Jeszcze sto­sun­ko­wo nie­daw­no w moich pro­jek­tach zwią­za­nych z opro­gra­mo­wa­niem, wyróż­nia­łem trzy eta­py: ana­li­za orga­ni­za­cji, spe­cy­fi­ka­cja wyma­gań oraz opra­co­wa­nie logi­ki dla dedy­ko­wa­nych kom­po­nen­tów opro­gra­mo­wa­nia. W koń­cu, po kil­ku pro­jek­tach, prze­ko­na­łem się, że ten podział nie dzia­ła”. Dlaczego?

Skoro na eta­pie CIM opra­co­wa­li­śmy mię­dzy inny­mi model logi­ki biz­ne­so­wej dla danej orga­ni­za­cji (w tym regu­ły biz­ne­so­we, słow­nik pojęć) to już ją, te logi­kę, mamy. Okazało się, że ten trze­ci etap” w zasa­dzie jest sztucz­ny, gdyż rze­tel­ne opra­co­wa­nie CIM to tak­że ta” logi­ka. Tu war­to przy­to­czyć diagram:

Swego cza­su pisa­łem tak­że o testo­wa­niu modeli:

W toku dal­szej pra­cy podej­mo­wa­na jest decy­zja o zakre­sie pro­jek­tu. Wskazując to, jakie dzia­ła­nia” ma wspie­rać lub prze­jąć na sie­bie apli­ka­cja (to są wła­śnie przy­pad­ki uży­cia), wska­zu­je­my jaka logi­ka ma być przez tę apli­ka­cję reali­zo­wa­na i kie­dy. Wskazanie zakre­su pro­jek­tu jest więc pierw­szym eta­pem defi­nio­wa­nia logi­ki apli­ka­cji. Jeżeli do tego dodać wie­dzę dzie­dzi­no­wą, np. to któ­re ele­men­ty mogą być współ­dzie­lo­ne a któ­re nie, któ­re powin­ni być cał­ko­wi­cie nie­za­leż­ne itp., powsta­nie tak zwa­ny model dzie­dzi­ny sys­te­mu (logi­ka biz­ne­so­wa i jej struk­tu­ra czy­li archi­tek­tu­ra apli­ka­cji, a kon­kret­nie czę­ści reali­zu­ją­cej logi­kę biznesową).

Na zakończenie

Jak podejść do pla­nów zaku­pu tak­że goto­we­go opro­gra­mo­wa­nia? Czy war­to je pro­jek­to­wać? Oczywiście, że war­to z pro­ste­go powo­du: nie ma zna­cze­nia to, czy przy­szłe opro­gra­mo­wa­nie będzie goto­we czy trze­ba je będzie dopie­ro stwo­rzyć. Ono ma reali­zo­wać taką logi­kę jakiej ocze­ku­je­my. Owszem, jest moż­li­wa decy­zja: sko­ro na ryn­ku nie ma poszu­ki­wa­ne­go pro­duk­tu a stwo­rze­nie dedy­ko­wa­ne­go jest zbyt kosz­tow­ne, to albo rezy­gnu­je­my z zaku­pu albo z okre­ślo­nej logi­ki wewnątrz orga­ni­za­cji. Jednak do pod­ję­cia takiej decy­zji musi­my tę logi­kę znać i mieć udo­ku­men­to­wa­ną (no bo jakoś musi­my ją poka­zać ofe­ren­tom). Ale dostaw­cy opro­gra­mo­wa­nia zawsze ofe­ru­ją ana­li­zę wyma­gań”… To praw­da … A ilu z nich powie, że nie mają Wam nic do zaofe­ro­wa­nia? Ale dedy­ko­wa­ne opro­gra­mo­wa­nie może zapro­jek­to­wać tyl­ko jego wyko­naw­ca”. To dla­cze­go fir­my budow­la­ne nie są dopusz­cza­ne do prac pro­jek­to­wych i architektonicznych?

Dlatego na dia­gra­mie powy­żej, jako moment wybo­ru dostaw­cy opro­gra­mo­wa­nia, wska­za­no ten w któ­rym mamy udo­ku­men­to­wa­ny model logi­ki czy­li PIM. To czy logi­ka taka jest dostęp­na w jakimś pro­duk­cie na ryn­ku czy nie, nie zmie­nia fak­tu, że i tak musi zostać ona opi­sa­na, bez cze­go taki wybór jest nie­moż­li­wy. Czym więc są (czym powin­ny być) wyma­ga­nia na opro­gra­mo­wa­nie? Niestety powin­ny być zwię­złym pro­jek­tem a nie dłu­gą listą cech.

Jeden ana­li­tyk pro­jek­tant mają­cy dobre wspar­cie narzę­dzio­we, jest w sta­nie wyko­nać ana­li­zę i pro­jekt dla dowol­nie dużej fir­my, wystar­czy, że potra­fi two­rzyć abs­trak­cje i zarzą­dzać zło­żo­no­ścią doku­men­ta­cji. Czy kil­ku ana­li­ty­ków zro­bi to nie gorzej i szyb­ciej? Nie znam takie­go przy­pad­ku.… bo im wię­cej osób pro­wa­dzi taką ana­li­zę tym wię­cej pra­cy wyma­ga koor­dy­na­cja i pra­ca nad spój­no­ścią całości.

Na zakoń­cze­nie cytat z pew­nej dyskusji:

I star­ted a com­pa­ny cal­led Nascent Blue that spe­cia­li­zes in MDD for appli­ca­tion deve­lop­ment. We have actu­al­ly had the oppor­tu­ni­ty to com­pa­re MDD to tra­di­tio­nal deve­lop­ment side-by-side on lar­ge pro­jects. Our client set up ?the expe­ri­ment? to col­lect the PM data for ana­ly­sis. It was a lar­ge pro­ject with 5 teams. The results:

1. Our team was less than half the size of the other teams.
2. Our team pro­du­ced more than twi­ce the code of the other teams.
3. Our team achie­ved a 75% reduc­tion in cost.
4. Our team achie­ved a 66% reduc­tion in defect rate.
5. Our team was twi­ce as fast (with half the size).
We have sin­ce got­ten more effi­cient and more advan­ced, so I don?t know what the num­bers are now.
(źr. Model dri­ven pro­duc­ti­vi­ty | LinkedIn).

Produkt analizy jako twierdzenie naukowe

Znakomita więk­szość pro­gra­mów zawie­ra ponad 10 krot­nie wię­cej kodu niż mogła by mieć, bo pro­gra­mi­ści czę­sto imple­men­tu­ją warian­ty zacho­wań a nie ich mecha­ni­zmy (co powo­du­je, że sys­te­my te są tyleż razy droż­sze niż mogły by być).

Prawie za każ­dym razem, gdy mówię (ale nie robię tego jed­nak zbyt czę­sto 😉 ), że sto­su­ję meto­dy nauko­we w ana­li­zie, spo­ty­kam się z zarzu­tem, że prze­sa­dzam. Zapewne nie ma sen­su epa­to­wa­nie w pro­jek­tach biz­ne­so­wych aka­de­mic­kim słow­nic­twem, nie ma zna­cze­nia dobór słow­nic­twa w nazwa­niu meto­dy pra­cy, bo zna­cze­nie ma skuteczność.

Twierdzenie naukowe

Poniżej defi­ni­cja tego czym jest twier­dze­nie naukowe:

Twierdzenie nauko­we ? zda­nie oznaj­mia­ją­ce speł­nia­ją­ce nastę­pu­ją­ce warun­ki :

  1. moż­na wobec nie­go sfor­mu­ło­wać kry­te­ria pozwa­la­ją­ce na eks­pe­ry­men­tal­ne, obser­wa­cyj­ne lub logicz­ne ich oba­le­nie (fal­sy­fi­ko­wal­ne według zasad Karla R. Poppera),
  2. ist­nie­ją regu­ły jego odczy­ta­nia, któ­re ogra­ni­cza­ją do skoń­czo­no­ści licz­bę ich inter­pre­ta­cji (kry­te­rium pre­cy­zji Józefa Bocheńskiego),
  3. odno­si się do empi­rycz­nie doświad­czal­nej lub logicz­nie defi­nio­wa­nej rze­czy­wi­sto­ści (tzw. widły Hume?a),
  4. jest ele­men­tem zbio­ru twier­dzeń para­dyg­ma­tu wyja­śnia­ją­ce­go rze­czy­wi­stość i pozwa­la­ją­ce­go na prze­wi­dy­wa­nie jej przy­szłych sta­nów (kon­cep­cja nauki nor­mal­nej T. S. Kuhna),
  5. twier­dze­nie będą­ce naj­prost­szym z moż­li­wych opi­sów świa­ta (tzw. Brzytwa Ockhama).

Graficznie sam pro­ces odkry­cia nauko­we­go moż­na poka­zać tak :

Budgen, D. (2003). Software design (2nd ed). Addison-Wesley.
Budgen, D. (2003). Software design (2nd ed). Addison-Wesley. 

Celowo cytu­ję tu lite­ra­tu­rę z obsza­ru inży­nie­rii opro­gra­mo­wa­nia, by poka­zać, że nie jestem odosob­nio­ny w tym podej­ściu. Dla porząd­ku poda­je tak­że defi­ni­cje poję­cia model:

model: sys­tem zało­żeń, pojęć i zależ­no­ści mię­dzy nimi pozwa­la­ją­cy opi­sać (mode­lo­wać) w przy­bli­żo­ny spo­sób jakiś aspekt rzeczywistości

Więcej o mode­lach w nauce: .

Inżynieria oprogramowania

Jeżeli uzna­my, że wynik zarów­no ana­li­zy jak i pro­jek­to­wa­nia, to tak­że mode­le (przyj­mu­je­my meto­dę pra­cy opar­tą na two­rze­niu mode­li: MDD/MDA czy­li model dri­ven deve­lop­ment”, MDA czy­li model dri­ven archi­tec­tu­re”, itp.), to w związ­ku z tym 

model, jako wynik ana­li­zy, moż­na potrak­to­wać jako twier­dze­nie nauko­we opi­su­ją­ce bada­ną (ana­li­zo­wa­ną) orga­ni­za­cję, jest on zara­zem wyma­ga­niem wobec opro­gra­mo­wa­nia (ma zostać zaimplementowany).

Wyjaśnienie: odnio­sę się do powyż­szej defi­ni­cji twier­dze­nia nauko­we­go (zgod­nie z powyż­szym pod poję­ciem model rozu­mie­my kom­plet doku­men­ta­cji zawie­ra­ją­cej mode­le, powsta­łej jako pro­dukt analizy):

  1. kry­te­rium fal­sy­fi­ka­cji: dopie­ro wska­za­nie w bada­nej orga­ni­za­cji fak­tu, któ­re­go nie opi­su­je opra­co­wa­ny model, pozwa­la uznać model (wynik ana­li­zy) za zły,
  2. ist­nie­ją regu­ły jego (mode­lu) odczy­ta­nia, czy­li do stwo­rze­nia mode­lu uży­to sfor­ma­li­zo­wa­nych nota­cji i sys­te­mów poję­cio­wych (np. BPMN, UML, BMM, SBVR itp),
  3. model powstał na bazie, i odno­si się wyłącz­nie do, zebra­nych w toku ana­li­zy fak­tów (w szcze­gól­no­ści doku­men­tów, któ­re powsta­ją w toku pra­cy ana­li­zo­wa­nej orga­ni­za­cji – doku­men­ty opi­su­ją fak­ty np. fak­tu­ra to opis fak­tu doko­na­nia sprzedaży),
  4. model pozwa­la na prze­wi­dy­wa­nie tego co zaj­dzie w odpo­wie­dzi na okre­ślo­ne bodź­ce (para­dyg­mat pro­ce­so­wy opi­su­ją­cy zacho­wa­nia i para­dyg­mat obiek­to­wy opi­su­ją­cy struk­tu­ry), mając model pro­ce­sów biz­ne­so­wych moż­na prze­wi­dzieć pro­dukt pro­ce­su, mając model apli­ka­cji moż­na prze­wi­dzieć pro­dukt każ­de­go przy­pad­ku użycia,
  5. opra­co­wa­ny model jest naj­prost­szy (mini­mal­ny) z moż­li­wych, czy­li nie da się już z nie­go usu­nąć nic bez spo­wo­do­wa­nia jego znisz­cze­nia (uczy­nie­nia nieprawdziwym).

Tu, dla dopeł­nie­nia, war­to dodać powszech­nie uzna­wa­ną w świe­cie nauki defi­ni­cję praw­dy (A.Tarski): twier­dze­nie praw­dzi­we to twier­dze­nie kore­spon­du­ją­ce z faktami.

Tak więc mamy to co chce­my czy­li kry­te­rium odbio­ru doku­men­ta­cji ana­li­tycz­nej i pro­jek­to­wej: nie jest to licz­ba stron a to, że mówi prawdę”. 

Z dru­giej stro­ny, nie­ste­ty nie ist­nie­je moż­li­wość wyka­za­nia popraw­no­ści doku­men­ta­cji powsta­łej w wyni­ku ankiet, wywia­dów czy burzy mózgów spi­sa­nej języ­kiem natu­ral­nym … .

cięż­ką arty­le­rię”, jak ta tu opi­sa­na, wyta­cza­my głów­nie dla pro­jek­tów ryzy­kow­nych i kosz­tow­nych… 😉 oraz wszę­dzie tam gdzie waż­na jest ochro­na know-how.

Dodatek

(dwa dni po publikacji)

Właśnie pode­sła­no mi link do cie­ka­we­go tekstu:

One of the most impor­tant ele­ments of eve­ry Business Analyst?s tool­kit is pro­cess mode­ling, which is also signi­fi­cant acti­vi­ty for Business Process Management pro­fes­sio­nals. For BPM mar­ket B? (Źródło: BPMN for Business Analysts ? why, when and how)

Przejrzałem treśc i wszyst­kie wypo­wie­dzi one krę­cą się” wokół doku­men­to­wa­nia, pre­zen­ta­cji w celu zatwier­dze­nia lub zgła­sza­nia uwag oraz nie­któ­rzy wska­zu­ją na moż­li­wość ryso­wa­nia zamiast kodo­wa­nia w celu wyko­na­nia”, albo prze­oczy­łem albo nikt nie zwró­cił uwa­gi na bar­dzo – mim zda­niem waż­ny ele­ment – two­rze­nie mode­lu orga­ni­za­cji czy­li two­rze­nie hipo­te­zy tak dzia­ła­cie” jako orga­ni­za­cja.

Problem w tym, że chy­ba więk­szość użyt­kow­ni­ków” tej (BPMN) – i nie tyl­ko – nota­cji, sto­su­je induk­cyj­ne meto­dy uwia­ry­gad­nia­nia tych mode­li, rozu­mia­nych raczej jako sche­ma­ty blo­ko­we. Podejście bazu­ją­ce na dowo­dzie z ilo­ści” (induk­cja): model pro­ce­sów jest dobry bo bar­dzo dużo osób (osób akcep­tu­ją­cych, recen­zen­tów) tak uzna­ło, jest chy­ba najgorsze.

To błąd logicz­ny: nie da się wyka­zać popraw­no­ści meto­dą induk­cyj­ną. Model owszem powi­nien być jako dia­gram zro­zu­mia­ły dla czy­tel­ni­ka, to nie ule­ga wąt­pli­wo­ści, jed­nak jego testy powin­ny pole­gać na wska­zy­wa­niu (szu­ka­niu) ewen­tu­al­nych fak­tów typu a tu mówi nie­praw­dę”. Innymi sło­wy model pro­ce­su nie jest dobry” (odzwier­cie­dla praw­dzi­wy mecha­nizm dzia­ła­nia orga­ni­za­cji) dla­te­go, że wszy­scy go zaak­cep­to­wa­li, jest dobry dla­te­go, że nikt nie zna­lazł (nie wska­zał) jego wady (nie pod­wa­żo­no go).

Projektów zakoń­czo­nych klę­ską, w któ­rych wszy­scy zaak­cep­to­wa­li doku­men­ta­cję” zna­my chy­ba wszy­scy masę.…

Tak więc ana­li­tyk, któ­ry pod­cho­dzi sys­te­mo­wo do ana­li­zy powi­nien two­rzyć hipo­te­zy tak to dzia­ła” i nie dowo­dzić ich popraw­no­ści, a cze­kać na wska­za­nie wad. Notacje (BPMN, UML, BMM, …) oraz mode­le two­rzo­ne z ich pomo­cą, są dosko­na­łym narzę­dziem do doku­men­to­wa­nia tych teorii.

Na zakoń­cze­nie pole­cam to 🙂

Źródła

Kitchenham, B., Pearl Brereton, O., Budgen, D., Turner, M., Bailey, J., & Linkman, S. (2009). Systematic lite­ra­tu­re reviews in softwa­re engi­ne­ering – A sys­te­ma­tic lite­ra­tu­re review. Information and Software Technology, 51(1), 7 – 15. https://​doi​.org/​1​0​.​1​0​1​6​/​j​.​i​n​f​s​o​f​.​2​0​0​8​.​0​9​.​009
Budgen, D. (2003). Software design (2nd ed). Addison-Wesley.
Popper, K. R. (2002). Logika odkry­cia nauko­we­go (U. Niklas, Trans.). Fundacja Aletheia.
Šenkýř, D., & Kroha, P. (2019). Problem of Incompleteness in Textual Requirements Specification: Proceedings of the 14th International Conference on Software Technologies, 323 – 330. https://​doi​.org/​1​0​.​5​2​2​0​/​0​0​0​7​9​7​8​0​0​3​2​3​0​330
Kitchenham, B. A., Budgen, D., & Brereton, P. (2016). Evidence-based softwa­re engi­ne­ering and sys­te­ma­tic reviews. CRC Press.

Sami zbudujemy oprogramowanie…

Swego cza­su wpadł mi oczy nius”:

Tesla Motors CEO Elon Musk deci­ded that the com­pa­ny would build its own busi­ness softwa­re to run the com­pa­ny. CIO Jay Vijayan and his team built it in just four mon­ths. (How Tesla’s Elon Musk Approaches IT – The CIO Report – WSJ).

Nie znam szcze­gó­łów, ale domy­ślam się, że zre­zy­gno­wa­li z peł­ne­go zin­te­gro­wa­ne­go pakie­tu ERP” i to chy­ba z tego krót­kie­go tek­stu widać.

marzenia i realiaOd dłuż­sze­go cza­su nur­tu­je mnie czym kie­ru­ją się fir­my (ludzie) zawie­ra­ją­ce umo­wy na zakup peł­nych i zin­te­gro­wa­nych pakie­tów ERP mimo, że sta­ty­sty­ki poka­zu­ją, że to z regu­ły nie ma żad­ne­go sen­su. Praktycznie wszyst­kie te wdro­że­nia są po zakoń­cze­niu znacz­nie droż­sze niż pier­wot­ne ofer­ty, trwa­ją dłu­żej niż obie­ca­no, nie mała część koń­czy się fia­skiem i nawet kom­plet­ną rezy­gna­cją i odin­sta­lo­wa­niem (bywam w tych fir­mach i widzę od środ­ka róż­ni­cę pomię­dzy tym co piszą w gaze­tach dostaw­cy w swo­ich refe­ren­cjach a tym co fak­tycz­nie mia­ło miejsce).

Nie raz o tym tu pisa­łem więc nie będę się powta­rzał. Popatrzmy na poniż­sze statystyki:

W Polsce śred­ni koszt wdro­że­nia pro­jek­tu na kil­ka­dzie­siąt sta­no­wisk (40 – 80 licen­cji) wyno­si 200 – 300 tys. dola­rów (pra­wie milion zło­tych), a pro­jek­tu dla małej fir­my (20 – 30 licen­cji) 100 – 140 tys. dola­rów (nie­co ponad 400 tys. zł) . Proporcje pomię­dzy kosz­ta­mi sprzę­tu i opro­gra­mo­wa­nia utrzy­mu­ją się na pozio­mie pół na pół. Najdroższe są usłu­gi kon­sul­tin­go­we, ich koszt się­ga 50 proc. kosz­tów wdro­że­nia, choć zda­rza­ją się klien­ci, u któ­rych kosz­ty obsłu­gi przez kon­sul­tan­tów nie prze­kra­cza­ją 5 proc. Wówczas klient prak­tycz­nie doko­nu­je wdro­że­nia wła­sny­mi siła­mi, ze stro­ny dostaw­cy korzy­sta­jąc głów­nie z usług szko­le­nio­wych. (Zintegrowane wspo­ma­ga­nie zarzą­dza­nia przed­się­bior­stwem: Przyszłość sys­te­mów ERP – Bankier​.pl).

Tu mamy koszt ok. 400 tys. zł, czy­li jakieś 200 tys. na ana­li­zę, pro­jek­to­wa­nie i wyko­na­nie, to jest moż­li­we i nie jest to mało. Ostatni taki pro­jekt jaki mam w port­fo­lio trwał tyl­ko pół roku. Różnica jest taka, że za te pie­nią­dze klient nie robił prak­tycz­nie żad­nych kom­pro­mi­sów (kom­pro­mis kasto­mi­za­cji przy wdra­ża­niu goto­wych dużych pakie­tów), czas od roz­po­czę­cia do wdro­że­nia tyl­ko pół roku! To przy­kład takie­go same­go budże­tu ale pro­jekt nie był trywialny.

Swego cza­su robi­łem wyli­cze­nie pro­go­wych kosz­tów opła­cal­no­ści wytwo­rze­nia dedy­ko­wa­nej apli­ka­cji dzie­dzi­no­wej i wyszło mi, że za 75 tys. (podob­no poza Warszawą 50 tys.) już taka może powstać (przy zało­że­niu rze­tel­ne­go pro­jek­to­wa­nia a potem dopie­ro imple­men­ta­cji, wte­dy wycho­dzi za pierw­szym razem, mam takie w port­fo­lio). Przy obec­nej tech­no­lo­gii (fra­me­wor­ki dzie­dzi­no­we czy­li tak zwa­ne goto­we szkie­le­ty) od daw­na już nie pisze­my dłu­go i żmud­nie kosz­tow­ne­go opro­gra­mo­wa­nia od zera” (czym stra­szą dostaw­cy goto­we­go). Dedykowany pro­jekt do dobór wła­ści­wych ele­men­tów szkie­le­tu, ich kon­fi­gu­ra­cja, roz­wią­zy­wa­nie wie­lu pro­ble­mów poza funk­cjo­nal­nych (tech­nicz­nych), pra­ce pro­gra­mi­stycz­ne wykoń­cze­nio­we” i ser­ce sys­te­mu czy­li model jego dzie­dzi­ny (ok. 3% cało­ści kodu), któ­ry fak­tycz­nie powsta­je od zera”. Do tego docho­dzi coraz więk­sza otwar­tość na inte­gra­cję goto­we­go, dostęp­ne­go na ryn­ku opro­gra­mo­wa­nia reali­zu­ją­ce­go stan­dar­do­we usłu­gi, takie jak zarzą­dza­nie finan­sa­mi czy maga­zy­na­mi. To się kupu­je goto­we i łączy.

Piszę to na począt­ku roku, trak­tu­jąc jako wróż­bę, to okres na pro­gno­zy więc i ja pro­gno­zu­ję :). Myślę, że postę­py w inży­nie­rii opro­gra­mo­wa­nia, powol­ne odcho­dze­nie od mode­lu rela­cyj­ne­go danych (to wymu­sza bar­dzo sztyw­ną inte­gra­cję) i kolej­ne pro­jek­ty poka­zu­ją­ce, że zin­te­gro­wa­ny ERP to nie koniecz­nie mono­li­tycz­ny” ERP, dopro­wa­dzą do upad­ku” hege­mo­nii wiel­kich dostaw­ców ERP”. Okazuje sie, że moż­na taniej uzy­skać takie same, a nie raz lep­sze, efek­ty. Są już pierw­sze efek­ty: dostaw­cy dużych ERP ofe­ru­ją dość roz­bu­do­wa­ne i wygod­ne inter­fej­sy inte­gra­cyj­ne, sami zawie­ra­ją soju­sze z dostaw­ca­mi osob­nych kom­po­nen­tów (lub ich kupu­ją :)). Osobiście nie widzę sen­su, by każ­da zmia­na sytu­acji biz­ne­so­wej musia­ła wyma­gać wymia­ny lub mody­fi­ka­cji całe­go pakie­tu ERP, sko­ro moż­na poje­dyn­cze komponenty.

Nieudane wdrożenie wielkiego systemu informatycznego w USA – a co u nas?

Jakiś czas temu pisa­łem o swo­ich prze­my­śle­niach po roz­mo­wie z pew­nym dyrek­to­rem finan­so­wym jed­ne­go z moich klien­tów. Powiedział mię­dzy inny­mi, że albo pro­jekt zosta­nie zre­ali­zo­wa­ny w roku jed­nym budże­to­wym, albo on nie wyda na zgo­dy na jego roz­po­czę­cie. W czym pro­blem? Ano w tym, że przy obec­nym tem­pie zmian na ryn­ku, pro­gno­za wykra­cza­ją­ca w przy­szłość dalej niż rok to wró­że­nie z fusów… Skutek? Jak oce­nić sto­pę zwro­tu z inwe­sty­cji w coś, co jest naj­bar­dziej płyn­nym, podat­nym na zmia­ny wyma­gań, zaso­bem w orga­ni­za­cji, czy­li sys­tem wspo­ma­ga­ją­cy zarzą­dza­nie nią?

Rynek sta­le się roz­wi­ja i doj­rze­wa. Praktycznie każ­da więk­sza fir­ma doświad­czy­ła w jakiejś for­mie wdro­że­nia goto­we­go, dosto­so­wy­wa­ne­go do potrzeb, opro­gra­mo­wa­nia ERP. Warto jed­nak pod­kre­ślić, że idea jed­ne­go ?super sys­te­mu? ERP II, odcho­dzi powo­li do lamu­sa. Moim zda­niem to kwe­stia roku, dwóch. Pierwsze symp­to­my to zale­ce­nia pro­du­cen­tów dużych sys­te­mów: wdra­żać goto­we opro­gra­mo­wa­nie w posta­ci ?goto­wej? tyl­ko tam gdzie pasu­je, obsza­ry spe­cy­ficz­ne dla fir­my opi­sać i zapro­jek­to­wać dla nich dedy­ko­wa­ne roz­wią­za­nie i zin­te­gro­wać. (czy­taj Biznes wycho­dzi z objęć sys­te­mu ? mono­li­tycz­ne­go ERP).

Co z tym zro­bić? Dzielić, jak to mawia­ją nie­któ­rzy kie­row­ni­cy pro­jek­tów: czło­wiek może zjeść nawet sło­nia, jak? Kęs po kęsie. Tak więc duży pro­jekt nale­ży podzie­lić na samo­dziel­ne” pod­sys­te­my, jed­nak ta samo­dziel­ność ma dwa aspek­ty: każ­dy pod­sys­tem musi sam z sie­bie do cze­goś słu­żyć, powi­nien wno­sić war­tość doda­ną. Drugi: każ­dy pro­jek­to­wa­ny pod­sys­tem powi­nien być zapla­no­wa­ny jako poten­cjal­nie samo­dziel­ne narzę­dzie (inwe­sty­cja) na wypa­dek gdy­by pozo­sta­łe nie zosta­ły nigdy wytwo­rzo­ne np. z powo­du zmian na rynku.

Ale o tym pisa­łem wię­cej już wcze­śniej. Kolejnym pro­ble­mem jest nie­ste­ty jakość projektowania:

Według fir­my ana­li­tycz­nej Gartner oko­ło 60 proc. wdro­żeń wiel­kich sys­te­mów infor­ma­tycz­nych koń­czy się klę­ską. Przyczyną jest m.in. nie­umie­jęt­ność prze­ło­że­nia pro­ce­sów dzia­ła­ją­cych w fir­mie na dzia­ła­nie sys­te­mu infor­ma­tycz­ne­go, brak dosta­tecz­ne­go wspar­cia ze stro­ny pra­cow­ni­ków i kie­row­nic­twa fir­my (cza­sem nawet jaw­ny opór), złe przy­go­to­wa­nie wdro­że­nia lub jego pro­wa­dze­nie. (za Serwis Nauka w Polsce – PAP SA).

Jak widać, jakość pro­jek­to­wa­nia jest klu­czem, zresz­tą nie tyl­ko w przy­pad­ków dużych sys­te­mów ale w każ­dym przy­pad­ku. Różnica jest taka, że jeże­li nie­jed­na fir­ma świa­do­mie ryzy­ku­je kil­ka­set tysię­cy rezy­gnu­jąc z eta­pu nie­za­leż­nej ana­li­zy i pro­jek­to­wa­nia war­tej ok. 10 – 20% tej kwo­ty, to podob­ne podej­ście pro­jek­ty war­te milio­nów jest już raczej nieracjonalne…

Po raz kolej­ny już spraw­dza się teza, że wdra­ża­nie jed­ne­go wiel­kie­go ERP inte­gru­ją­ce­go wszyst­ko” jest mrzon­ką… prak­ty­ka poka­zu­je, że kil­ka sys­te­mów dzie­dzi­no­wych, zin­te­gro­wa­nych ze sobą jest po pierw­sze mniej ryzy­kow­ne a po dru­gie, para­dok­sal­nie, tańsze.

Tak więc: jak dostaw­ca duże­go ERP mówi, że duży ERP jest naj­lep­szy to nale­ży to trak­to­wać tak samo jak ofer­tę dostaw­cy duże­go zesta­wu garn­ków ze sta­li nie­rdzew­nej, z któ­rych i tak na co dzień uży­wa­my jed­ne­go a nale­śni­ki i tak robi­my z pomo­cą kupio­nej wcze­śniej dobrej teflo­no­wej patel­ni bo do nale­śni­ków lep­sza a zamia­na jej na nową z nie­rdzew­ki tyl­ko dla­te­go, że ?z kom­ple­tu? prze­czy zdro­we­mu roz­sąd­ko­wi i uży­wa się jej mimo, że pokryw­ka z zesta­wu lek­ko wysta­je ? ale przy­kry­wa bo taki jest jej głów­ny cel (w zasa­dzie tyl­ko nie powin­na być mniej­sza ani zbyt duża). (Nigdy wię­cej ERP w jed­nym kawał­ku!).

Raport z Badania polskich projektów informatycznych 2010

Na stro­nie PMResearch​.pl poja­wi­ło się cie­ka­we bada­nie Raport zawie­ra rezul­ta­ty ana­li­zy 80 sta­ran­nie wyse­lek­cjo­no­wa­nych pro­jek­tów IT. Wyniki pre­zen­tu­je w zwię­zły, syn­te­tycz­ny spo­sób. Pobierz raport (za Informacje o wyni­kach bada­nia pol­skich pro­jek­tów infor­ma­tycz­nych).

Wyniki bada­nia bar­dzo pole­cam, uczą poko­ry. Pytanie moje do auto­rów: jak zde­fi­nio­wa­no meto­dy­kę Agile? Pobieżna nawet bada­nie” zaso­bów w Internecie poka­zu­je, że nie ist­nie­je jed­na defi­ni­cja tego podej­ścia”. Na stro­nie agi​le​ma​ni​fe​sto​.org czytamy:

Wytwarzając opro­gra­mo­wa­nie i poma­ga­jąc innym w tym zakresie,

odkry­wa­my lep­sze spo­so­by wyko­ny­wa­nia tej pracy.

W wyni­ku tych doświad­czeń przedkładamy:

Ludzi i inte­rak­cje ponad pro­ce­sy i narzę­dzia.

Działające opro­gra­mo­wa­nie ponad obszer­ną doku­men­ta­cję.

Współpracę z klien­tem ponad for­mal­ne usta­le­nia.

Reagowanie na zmia­ny ponad podą­ża­nie za pla­nem.

Doceniamy to, co wymie­nio­no po pra­wej stronie,

jed­nak bar­dziej ceni­my to, co po lewej.

Można by odnieść wra­że­nie, że igno­ro­wa­ne jest wszyst­ko co naka­zu­je roz­są­dek (pogru­bie­nie moje). Paradoksalnie, obser­wu­jąc pro­jek­ty, mam wra­że­nie, że zwin­ność jest jed­nak czę­sto ina­czej rozu­mia­na, nie jako igno­ro­wa­nie zło­te­go trój­ką­ta” pro­jek­to­we­go (zakres, ter­min, budżet). Ja w każ­dym razie zawsze pytam: czym jest tu Agile. Niestety sły­szę nie raz, ze tego się nie defi­niu­je”… co wywo­łu­je u mnie odruch nie defi­niu­je się zakre­su pro­jek­tu” a to pro­wa­dzi do wnio­sku, że suk­ce­sem jest sam fakt roz­po­czę­cia projektu…