Effective software delivery. White paper. May 2009

Krzywe i koszty… architektury

Dwa tygo­dnie temu, na kon­fe­ren­cji o jako­ści sys­te­mów IT, pre­zen­to­wa­łem mię­dzy inny­mi dwa poniż­sze wykresy:

Koszty rozwoju


Pierwszy wykres jest bar­dzo popu­lar­ny w lite­ra­tu­rze przed­mio­tu, tu jeden z wie­lu przy­kła­dów. Powołam się na nie­go później.

Effective software delivery. White paper. May 2009

Drugi jest wyni­kiem moich stu­diów lite­ra­tu­ry , wła­snych badan i doświad­cze­nia i wła­śnie o nim nie­co wię­cej. Wyjaśnię jak powstał.

W zasa­dzie wystar­czy uznać, że jeże­li speł­nie­nie zasa­dy „[[open clo­sed prin­ci­ple in object orien­ted softwa­re]]” (archi­tek­tu­ra sys­te­mu jest otwar­ta na roz­sze­rze­nia i zamknię­ta na zmia­ny) jest moż­li­we, to kod tak zbu­do­wa­nej apli­ka­cji rośnie” linio­wo, a koszt roz­wo­ju podob­nie. Początkowy koszt, to koszt opra­co­wa­nia szkie­le­tu (zwa­ne­go [[core doma­in]]). To wła­śnie – w apli­ka­cjach kon­stru­owa­nych zgod­nie z [[zasa­da­mi SOLID]] – powo­du­je, że koszt począt­ko­wy jest rela­tyw­nie wyż­szy niż koszt archi­tek­tu­ry budo­wa­nej ad-hoc” (ozna­czo­nej ???).

Nie mam ambi­cji two­rze­nia przy­kła­du brzyd­kiej archi­tek­tu­ry”, chy­ba już nie umiem 😉 dla­te­go poni­żej tyl­ko struk­tu­ra apli­ka­cji (archi­tek­tu­ra kom­po­nen­tu Model/MVC) w obiek­to­wym para­dyg­ma­cie (apli­ka­cja to współ­pra­cu­ją­ce obiek­ty) zgod­na z SOLID:

Obiektowy model dziedziny Zasada SOLID
Przykład archi­tek­tu­ry na bazie wzor­ca BCE (BCCE)

Model ten powstał z uży­ciem blo­ków funk­cjo­nal­nych wzor­ca BCE (opi­sa­łem go tu: Wzorzec ana­li­tycz­ny Boundary Control Entity). Dla wyja­śnie­nia: powyż­szy dia­gram to w peł­ni popraw­ny Model dzie­dzi­ny wyko­na­ny z uży­ciem dia­gra­mu klas UML, kla­sy mają ste­reo­ty­py boun­da­ry, con­trol i enti­ty (powy­żej od lewej do pra­wej), ste­reo­ty­py te są repre­zen­to­wa­ne sym­bo­la­mi opi­sa­ny­mi (iko­na­mi) w BCE. Kilka cech tej architektury:

  1. każ­dy przy­pa­dek uży­cia ma dedy­ko­wa­ną kla­sę (ta połą­czo­na z akto­rem) odpo­wie­dzial­ną za jego inter­fejs i sce­na­riusz (ale nie logi­kę biznesową!),
  2. sce­na­riusz przy­pad­ku uży­cia to recep­ta” na to, kie­dy i cze­go wewnątrz apli­ka­cji nale­ży użyć do reali­za­cji celu użytkownika,
  3. to co potra­fi” apli­ka­cja to usłu­gi wewnętrz­ne (logi­ka biznesowa),
  4. to co apli­ka­cja musi wie­dzieć” zapa­mię­ta­ło się (jest prze­cho­wy­wa­ne) w repozytoriach,
  5. żad­ne infor­ma­cje nie są, logicz­nie ani w szcze­gól­no­ści fizycz­nie, współ­dzie­lo­ne: każ­de repo­zy­to­rium, powy­żej są trzy, jest w 100% her­me­ty­zo­wa­ne (imple­men­ta­cja repo­zy­to­riów to abso­lut­nie! nie jest jed­na współ­dzie­lo­na rela­cyj­na baza danych i mapo­wa­nie ORM!).

Widać (mam nadzie­ję na tym dość pro­stym sche­ma­cie), że każ­dy przy­pa­dek uży­cia to odręb­ny ser­wis”, prak­tycz­nie nie­za­leż­na usłu­ga (u Fowlera nazy­wa­ne mikro­ser­wi­sa­mi). Są od sie­bie cał­ko­wi­cie odse­pa­ro­wa­ne, co naj­wy­żej korzy­sta­ją z tych samych spe­cja­li­zo­wa­nych usług wewnętrz­nych (np. z gene­ra­to­ra pli­ków PDF będzie korzy­sta­ła każ­da usłu­ga ope­ru­ją­ca na doku­men­tach do dru­ku). Dodanie kolej­ne­go przy­pad­ku uży­cia w ogó­le nie wpły­wa na resz­tę apli­ka­cji (zale­ta her­me­ty­za­cji), ewen­tu­al­ne redun­dan­cje są raczej zba­wie­niem niż wadą, gdyż każ­da usłu­ga ma swój kon­tekst i wła­sny cykl życia, i jakie­kol­wiek współ­dzie­le­nie tre­ści (nie mylić z wyko­rzy­sta­niem tych samych) raczej zmu­si do (zgni­łe­go) kompromisu.

Współdzielenie danych naj­czę­ściej przy­no­si szko­dy, np. współ­dzie­le­nie listy pro­duk­tów pomię­dzy zamó­wie­niem i fak­tu­rą powo­du­je zależ­ność unie­moż­li­wia­ją­cą wysta­wie­nie fak­tu­ry na pro­duk­ty inne (w innej ilo­ści) niż na tym zamó­wie­nia (nie takie rzad­kie zja­wi­sko w dostęp­nych na ryn­ku sys­te­mach ERP). Utworzenie fak­tu­ry poprzez sko­pio­wa­nie (wyko­rzy­sta­nie) zawar­to­ści Zamówienia, pozwa­la na jej (fak­tu­ry) dowol­ną mody­fi­ka­cję bez potrze­by zmia­ny Zamówienia (żąda­nia powtór­ne­go jego przy­sła­nia lub o zgro­zo, wewnętrz­nej korek­ty!). Współdzielenie danych firm pomię­dzy np. fak­tu­ra­mi i reje­strem kon­tra­hen­tów, skut­ku­je pro­ble­mem gdy aktu­ali­za­cja adre­su kon­tra­hen­ta prze­no­si się na histo­rycz­ne fak­tu­ry. Owszem może nam się przy­tra­fić koszt nowej usłu­gi wewnętrz­nej, ale zro­bi­my to bez jakiej­kol­wiek inge­ren­cji w dotych­cza­so­wą logi­kę (i kod).

Aplikacje, któ­rych archi­tek­tu­ra wewnętrz­na bazu­je na współ­dzie­lo­nych danych, rela­cyj­nej jed­nej bazie danych (jeden spój­ny sys­tem tablic rela­cyj­nej bazy danych pod” apli­ka­cją), gęstej sie­ci wewnętrz­nych zależ­no­ści, wyma­ga­ją – dla doda­nia nowej usłu­gi lub zmia­ny ist­nie­ją­cej – pra­wie zawsze czę­ścio­we­go lub cał­ko­wi­te­go re-fak­to­rin­gu, a w skraj­nych przy­pad­kach nawet migra­cji danych do nowej ich struk­tu­ry. W efek­cie, to co użyt­kow­nik postrze­ga jako roz­sze­rze­nie, dla dewe­lo­pe­ra sta­no­wi pra­co­chłon­ny refak­to­ring, tym bar­dziej pra­co­chłon­ny im więk­sza ta apli­ka­cja. Z tego powo­du kosz­ty wpro­wa­dza­nia zmian do tak stwo­rzo­nej apli­ka­cji są tym więk­sze im więk­sza i zło­żo­na jest ta apli­ka­cja (czer­wo­na linia na wykre­sie kosz­tu roz­sze­rze­nia funkcjonalności).

Pisanie opro­gra­mo­wa­nia ad-hoc, bez prze­my­śla­nej logi­ki i archi­tek­tu­ry cało­ści, pro­wa­dzi do powsta­wa­nia tak zwa­ne­go „[[dłu­gu archi­tek­to­nicz­ne­go]]” (ana­lo­gicz­nie do [[dług tech­no­lo­gicz­ny]]). To dla­te­go bar­dzo czę­sto źle poj­mo­wa­ne agi­le” pozwa­la bar­dzo szyb­ko uzy­skać pierw­sze efek­ty, nie­ste­ty oku­pio­ne bar­dzo kosz­tow­nym póź­niej­szym utrzy­ma­niem i roz­wo­jem takiej apli­ka­cji. Chyba, że pro­dukt taki potrak­to­wa­ny zosta­nie jako efe­me­ry­da albo jako pro­to­typ odrzucany.

Niestety wie­le sys­te­mów ERP i i nie tyl­ko, powsta­ło w latach 90’tych, mają one nie­ste­ty scen­tra­li­zo­wa­ną archi­tek­tu­rę struk­tu­ral­ną (jed­na baza danych i nad nią” funk­cje prze­twa­rza­ją­ce te dane). Efekty tego widać przy wdro­że­niach, w któ­rych dopusz­czo­no tak zwa­ną kasto­mi­za­cje sys­te­mu, czy­li wła­śnie wpro­wa­dza­nie, nie raz bar­dzo wie­lu, zmian. To bar­dzo kosz­tow­ne pro­jek­ty o prak­tycz­nie nie­prze­wi­dy­wal­nym budże­cie. Niestety współ­dzie­le­nie danych wewnątrz takie­go sys­te­mu jest jego poważ­ną wadą a nie – jak to zachwa­la­ją ich dostaw­cy – zaletą…

Analiza procesowa a obiektowa czyli niedopasowanie oporu

Swego cza­su w arty­ku­le o Wścipskim Analityku uza­sad­nia­łem potrze­bę pano­wa­nia nad wyma­ga­nia­mi od momen­tu poja­wie­nia się potrze­by biz­ne­so­wej aż do jej imple­men­ta­cji. Nie zna­czy to abso­lut­nie, że ana­li­tyk ma pro­gra­mo­wać, zna­czy to jed­nak, że ana­li­tyk powi­nien doku­men­to­wać to cze­go żąda w wyma­ga­niach a potem nad­zo­ro­wać realizację.

Developerzy uzur­pu­ją sobie pra­wa do wszyst­kie­go co wią­że się z imple­men­ta­cją. Z jed­nej stro­ny czę­sto żąda­ją szcze­gó­ło­wych danych np. o danych z dru­giej stro­ny sami chcą opi­sać ich logi­kę biz­ne­so­wą (tak, bo dane biz­ne­so­we to logi­ka biz­ne­so­wa a nie tech­no­lo­gia). Do tego bar­dzo wie­lu deve­lo­pe­rów sto­su­je meto­dy pra­cy rodem z przed kil­ku­na­stu lat… We wspo­mnia­nym wyżej arty­ku­le napi­sa­łem mię­dzy inny­mi o tak zwa­nym para­dyg­ma­cie obiek­to­wym i wie­dzy o nim u deve­lo­pe­rów, szu­kam hasła ana­li­za pro­ce­so­wa” i para­dyg­mat obiektowy”:

Tradycyjnie idzie­my do WIKI:

Przepraszamy, ale nie ma jesz­cze arty­ku­łu ?Analiza pro­ce­so­wa? w Wikipedii. (24 Maj 2011)

No cóż, szu­ka­my dalej:

Process ana­ly­sis pre­sents a chro­no­lo­gi­cal sequ­en­ce of steps that expla­in how some­thing is done, how some­thing hap­pens, or how readers can do some­thing. (źr. http://​www​.tcc​.edu/​s​t​u​d​e​n​t​s​/​r​e​s​o​u​r​c​e​s​/​w​r​i​t​c​e​n​t​/​h​a​n​d​o​u​t​s​/​w​r​i​t​i​n​g​/​p​r​o​c​e​s​s​.​htm).

Coś mamy: ana­li­za pro­ce­so­wa pre­zen­tu­je w posta­ci chro­no­lo­gicz­nej sekwen­cji kro­ków, to jak coś powsta­je, co się wyda­rza lub jak moż­na coś zro­bić. Piękna defi­ni­cja. Ta pre­zen­ta­cja to, w kon­tek­ście biz­ne­so­wym, model (mapa) pro­ce­sów biznesowych.

Mamy wiec upo­rząd­ko­wa­ną wie­dzę o fir­mie (orga­ni­za­cji) zama­wia­ją­ce­go opro­gra­mo­wa­nie. Tu tak­że powsta­je opis tego po co i gdzie tego opro­gra­mo­wa­nia chce­my uży­wać: model procesowy.

Tak zwane niedopasowanie oporu

Tak jest nazy­wa­na w lite­ra­tu­rze róż­ni­ca pomię­dzy para­dyg­ma­tem pro­ce­so­wym a obiek­to­wym. Paradygmat pro­ce­so­wy ope­ru­je taki­mi poję­cia­mi jak: pro­ces, wej­ście pro­ce­su, wyj­ście pro­ce­su, zda­rze­nie, wyko­naw­ca pro­ce­su (zaso­by), czyn­ność (lub ich sekwen­cja). Paradygmat obiek­to­wy to wspo­mnia­ne współ­pra­cu­ją­ce obiek­ty. W czym pro­blem? W przej­ściu z mode­lu pro­ce­so­we­go na obiek­to­wy. Czy to łatwe? Nie. Jak to zro­bić? Hm… usiąść i popra­co­wać nad tym.

Należy prze­pro­wa­dzić ana­li­zę obiek­to­wą i wyko­nać model obiek­to­wy. Czego? Kodu? Nie! Logiki dzia­ła­nia i orga­ni­za­cji zamawiającego!

Tak wła­śnie jest: ana­li­za obiek­to­wa i mode­lo­wa­nie obiek­to­we to nie pro­gra­mo­wa­nie. Programowanie (wraz z pro­jek­to­wa­niem ele­men­tów czy­sto tech­nicz­nych) to imple­men­ta­cja modelu.

Jak moż­na radzić sobie z tym nie­do­pa­so­wa­niem”. Pomagają w tym zasa­dy SOLID (w szcze­gól­no­ści zasa­da otwar­to­ści na roz­sze­rze­nia i zamknię­cia na mody­fi­ka­cje oraz pro­jek­to­wa­nie zorien­to­wa­ne na zobo­wią­za­nia klas) oraz wzor­ce DDD w ana­li­zie i projektowaniu.

To co tu opi­szę nie jest pro­stym algo­ryt­mem mode­lo­wa­nia”, z pra­cy myślo­wej niko­go tu nie zwol­nię. Moim celem jest uzu­peł­nie­nie arty­ku­łu o sza­chow­ni­cy i arty­ku­łu o zbyt Niskim pozio­mie ana­li­zy o wska­za­nie, że model dzie­dzi­ny jest bar­dziej ele­men­tem ana­li­zy i mode­lo­wa­nia biz­ne­so­we­go niż pro­jek­to­wa­nia i imple­men­ta­cji. Model ten to jed­no z klu­czo­wych wyma­gań: sys­tem ma reali­zo­wać logi­kę opi­sa­ną w mode­lu dziedziny.

Jeżeli uzna­my, że moż­na (taki) model dzie­dzi­ny imple­men­to­wać to jego opra­co­wa­nie to tak­że pro­jek­to­wa­nie. Nadal uwa­żam, że nie jest to robo­ta dla pro­gra­mi­sty, bo na jakiej pod­sta­wie on miał by taki model opracować?

Jak wyglą­da więc pra­ca ana­li­ty­ka biz­ne­so­we­go zgod­nie z mode­lem kom­pe­ten­cyj­nym IIBA (IIBA com­pe­ten­cy model). Kluczowym ele­men­tem pra­cy Analityka Biznesowego (w kon­wen­cji IIBA) jest pro­wa­dze­nie (ana­li­za) wyma­gań od momen­tu okre­śle­nia potrze­by biz­ne­so­wej aż do imple­men­ta­cji uzy­ska­nia wła­ści­we­go roz­wią­za­nia. Jednak uzy­ska­nie to nie to samo co wła­sno­ręcz­ne wyko­na­nie. Znowu ana­lo­gia do budow­nic­twa: archi­tekt na bazie biz­ne­so­wych celów swo­je­go klien­ta opra­co­wu­je nie tyl­ko wizu­ali­za­cję budyn­ku ale tak­że jego kon­struk­cję, do takie­go pozio­mu by deve­lo­per miał jed­no­znacz­nie posta­wio­ne wyma­ga­nia, nie blo­ku­je to jed­nak deve­lo­pe­ro­wi reali­za­cji” wszel­kich poza-funk­cjo­nal­nych wymagań.

Więc po kolei, opracowujemy.

Model procesu biznesowego

Model procesuMamy tu pro­ces skła­da­ją­cy się z dwóch ele­men­tar­nych pro­ce­sów biz­ne­so­wych (czyn­no­ści). Każda czyn­no­ści, zgod­nie z defi­ni­cją pro­ce­su biz­ne­so­we­go, ma dane wej­ścio­we i dane wyj­ścio­we. Dokument 2 i Dokument 3 powsta­ją w tych pro­ce­sach. Mamy tak­że Procedury two­rze­nia doku­men­tów, czy­li jakąś logi­kę ich two­rze­nia. Pojawia się tak­że regu­ła biz­ne­so­wa. Jest to to ele­ment z poza nota­cji BPMN (nota­cja ta zawie­ra jed­nak moż­li­wość ozna­cza­nia czyn­no­ści wyma­ga­ją­cych uży­cia takiej regu­ły). Na dia­gra­mie poka­za­no, regu­łę biz­ne­so­wą oraz jej powią­za­nie z kon­kret­ną czynnością.

Czas zacząć ana­li­zo­wać czy­li pro­jek­to­wać nasz System. Założenie: wyma­ga­ne jest by System (opro­gra­mo­wa­nie) wspie­ra­ło oba pro­ce­sy: 1 i 2 (przy­po­mnę, że pro­ces biz­ne­so­wy to jed­na czyn­ność lub ich sekwen­cja, więc jed­ną czyn­ność mają­cą wej­ście i wyj­ście tak­że z defi­ni­cji, utoż­sa­mia­ny z pro­ce­sem biznesowym).

Usługi systemu

Usługi sys­te­mu to korzeń ana­li­zy obiek­to­wej. Stanowią szkie­let całe­go obiek­to­we­go pro­jek­tu. two­rzy­my bar­dzo waż­ny dia­gram: dia­gram przy­pad­ków użycia.

Usługi systemu

Często sły­szę, że ten dia­gram nic nie wno­si do pro­jek­tu. To nie praw­da. Wnosi klu­czo­wą infor­ma­cję: wyzna­cza gra­ni­ce Systemu i wska­zu­je ewen­tu­al­ne powią­za­nia z inny­mi sys­te­ma­mi. Ale też nie praw­dą jest, że słu­ży do poka­za­nia cze­go­kol­wiek ponad to, np. kolej­no­ści korzy­sta­nia z usług czy struk­tu­ry wewnętrz­nej. To ostat­nie robi­my w posta­ci mode­lu dziedziny.

Na powyż­szym dia­gra­mie udokumentowano:

  1. System ofe­ru­je użyt­kow­ni­ko­wi dwie usłu­gi (to wyma­ga­nie by Czynność 1 i Czynność 2 pro­ce­su były wspie­ra­ne przez System). 
  2. System będzie korzy­stał z danych inne­go opro­gra­mo­wa­nia (Zewnętrznego źró­dła danych), wyma­ga­na jest więc integracja.
  3. Usługa 2 jest reali­zo­wa­na w cało­ści przez inny, zewnętrz­ny sys­tem, wyma­ga­ne jest od sys­te­mu więc by obsłu­gi­wał prze­kie­ro­wa­nie na inny sys­tem (np. reali­za­cja płat­no­ści na stro­nie Banku).

Zakres pro­jek­tu to wyłącz­nie to co w środ­ku”, albo lepiej: wszyst­ko to co jest poza pro­sto­ką­tem System jest poza zakre­sem pro­jek­tu. Nie dostar­cza­my ani Zewnętrznego źró­dła danych ani Systemu Zewnętrznego usłu­go­daw­cy ale musi­my na liście wyma­gań zapi­sać, że inte­gra­cja z nimi jest wyma­ga­na i jaka ona ma być.

Logika działania Systemu – model dziedziny

Zabawa zaczy­na się tu: zamie­nia­my sce­na­riu­sze” na narzę­dzia i materiały”:

Model dziedziny

Celowo zacho­wa­łem nazwy tak by moż­li­we było śla­do­wa­nie” co z cze­go powsta­ło. Kilka komen­ta­rzy, czy­li dobre prak­ty­ki, wzor­ce i styl projektowania.

Każda usłu­ga ma swo­ją dedy­ko­wa­ną kla­sę, zmia­ny reali­za­cji jed­nej nie prze­nio­są się na inne. Usługi są więc od sie­bie nie­za­leż­ne. Oddzielono two­rze­nie doku­men­tów od ich prze­cho­wy­wa­nia, dzię­ki cze­mu łatwo w przy­szło­ści zmie­nić meto­dy ich two­rze­nia bez potrze­by inge­ren­cji w repo­zy­to­rium. Wszelkie regu­ły biz­ne­so­we (w tym vali­da­cji) są zamknię­te” w tak zwa­nych zło­żo­nych typach danych (valueObject, sytu­acja ide­al­na to cał­ko­wi­ty brak typów pro­stych (typy pro­ste, pri­mi­ti­ves) w pro­jek­cie, wyłącz­nie typy zło­żo­ne). W zasa­dzie zastą­pie­nie wszyst­kich typów pro­stych na zło­żo­ne w obsza­rze mode­lu dzie­dzi­ny, otwie­ra w przy­szło­ści dro­gę do ich roz­bu­do­wy bez potrze­by wpro­wa­dza­nia innych zmian w pro­gra­mie. Realnie pomię­dzy Aktorem a usłu­gą ist­nie­ją kla­sy wido­ku (GUI, View w MVC), tu nie umiesz­czo­ne, bo kla­sy te nie reali­zu­ją (nie powin­ny) żad­nej logi­ki biznesowej.

Powyższy model:

  1. Spełnia zasa­dy SOLID (w szcze­gól­no­ści System jest łatwy w roz­sze­rza­niu i nie wyma­ga w tym celu zmian)
  2. Jest zgod­ny z DDD czy­li struk­tu­ra mode­lu odwzo­ro­wu­je struk­tu­rę i poję­cia biznesowe.

Co zysku­je­my? Niskie kosz­ty dal­sze­go roz­wo­ju, łatwość wyce­ny pro­jek­tu przez deve­lo­pe­ra (zna archi­tek­tu­rę). Powstanie takie­go pro­jek­tu daje mi gwa­ran­cję, że panu­je nad nim. Owszem mogę zało­żyć, że deve­lo­per tak­że taki model opra­cu­je, jed­nak życie poka­zu­je, że pra­wie na pew­no nie…

Powyższe z oczy­wi­stych powo­dów (mało miej­sca i uogól­nie­nie) nie zawie­ra szcze­gó­łów, ale te nale­ży zawsze w pro­jek­cie odkła­dać na sam koniec. Dzięki temu może­my sku­pić się na rze­czach na praw­dę waż­nych (waż­ne jest by zro­zu­mieć cel two­rze­nia doku­men­tu a nie spi­sać jego zawar­tość, ta ostat­nia wyni­ka z tego do cze­go służy).

Ostatni wpis na blo­gu, o Niskim pozio­mie ana­li­zy zawie­ra akapit:

Istnieje nie­ste­ty tak­że bar­dzo duże ryzy­ko, któ­re­go źró­dłem jest sto­so­wa­nie sta­rych, struk­tu­ral­nych metod wytwa­rza­nia opro­gra­mo­wa­nia czy­li roz­biór” (i pro­jekt) sys­te­mu na bazę danych i pro­ce­du­ry. Ta prak­ty­ka (meto­da) nie­ste­ty daje jako efekt opro­gra­mo­wa­nie bar­dzo kosz­tow­ne w pro­jek­to­wa­niu i roz­wo­ju. Od metod struk­tu­ral­nych znacz­nie lep­sze są meto­dy obiek­to­we, nie­ste­ty samo dekla­ro­wa­nie korzy­sta­nia z .NET czy Java albo nota­cji UML nie czy­ni sto­so­wa­nych metod obiektowymi.

Właśnie dla­te­go ana­li­za i wyma­ga­nia powin­ny zawie­rać model dzie­dzi­ny wraz z zale­ce­nia­mi co do imple­men­ta­cji. Nie jest to doku­ment (ten model) dla spon­so­ra pro­jek­tu (w rozu­mie­niu do czy­ta­nia). Jego rola (war­tość jaką wno­si do pro­jek­tu) to mini­ma­li­za­cja ryzy­ka, że deve­lo­per wyko­na coś cze­go nie chcemy.

A gdzie baza danych? Nie tu! Implementacja prze­cho­wy­wa­nia danych to pra­ca deve­lo­pe­ra, nie wol­no mu jedy­nie znor­ma­li­zo­wać powyż­sze­go mode­lu. Zaprojektowanie rela­cyj­ne­go mode­lu i uży­cie mapo­wa­nia obiek­to­wo-rela­cyj­ne­go znisz­czy wszyst­kie zale­ty tego pro­jek­tu a dodat­ko­wo strasz­nie skom­pli­ku­je całość.

(prze­druk uka­zał się w ERP-View)

Analiza wymagań na oprogramowanie czyli opisanie czy zrozumienie

eurekaZ poję­ciem ana­li­zy wyma­gań spo­ty­kam się regu­lar­nie, co chy­ba w moim przy­pad­ku nie jest zasko­cze­niem :). Jednak jest pewien niu­ans, któ­ry moż­na wychwy­cić ana­li­zu­jąc takie ana­li­zy wyma­gań, a tak­że słu­cha­jąc opo­wia­dań o przy­go­dach programistów.

Miałem nie­daw­no kolej­ny audyt doku­men­ta­cji wyma­gań opra­co­wa­nej samo­dziel­nie przez zama­wia­ją­ce­go. Była duża i trud­na w odbio­rze”, kil­ka osób z tej fir­my spi­sa­ło, każ­da dla swo­je­go dzia­łu i ze swo­jej per­spek­ty­wy, ocze­ki­wa­nia. Uporządkowali to tema­tycz­nie. Te kil­ka osób, plus ich pod­wład­ni, pra­co­wa­li nad tym trzy mie­sią­ce (mimo, że nie full time” to jed­nak suge­ru­je sobie same­mu osza­co­wać koszt tej pra­cy). Dokument w pier­wot­nej wer­sji prak­tycz­nie nie był przy­dat­ny. Drugim powo­dem napi­sa­nia tego arty­ku­ły była dys­ku­sja na pew­nym forum na temat kom­pe­ten­cji w IT, ale o tym na końcu.

Praktycznie zawsze spe­cy­fi­ka­cja wyma­gań wyko­na­na samo­dziel­nie przez zama­wia­ją­ce­go, to tak na praw­dę opis tego cze­go sobie życzy na bazie swo­ich dotych­cza­so­wych doświad­czeń. Regułą w takich przy­pad­kach w zasa­dzie jest to, że nowy sys­tem” to coś lep­sze­go od tego co mamy teraz”. Specyfikacja wyma­gań (jej treść) spro­wa­dza się do listy popra­wek i nowych żądań. Jeżeli wyma­ga­nia zosta­ły opra­co­wa­ne jako zapis wywia­dów lub ankiet przez tak zwa­ne­go ana­li­ty­ka” z zewnątrz (pra­cow­nik dostaw­cy opro­gra­mo­wa­nia, nie­za­leż­ny ana­li­tyk), efek­ty są prak­tycz­nie takie same (pomi­jam tu for­mę ich udokumentowania).

Zacytuje po raz kolej­ny meta­fo­rę z książ­ki Martina Fowlera:

Wyobraźmy sobie kogoś, kto chce napi­sać pro­gram symu­lu­ją­cy grę w sno­oke­ra. Problem ten może zostać opi­sa­ny przy­pad­ka­mi uży­cia opi­su­ją­cy­mi powierz­chow­nie cechę: ?Gracz ude­rza bia­ła kulę, któ­ra prze­miesz­cza się z pew­ną pręd­ko­ścią, ta po okre­ślo­nym cza­sie ude­rza czer­wo­ną kulę pod okre­ślo­nym kątem, ude­rzo­na czer­wo­na kula prze­miesz­cza się na pew­na odle­głość w pew­nym kie­run­ku.? Możesz sfil­mo­wać set­ki tysię­cy takich ude­rzeń, zare­je­stro­wać para­me­try każ­de­go ude­rze­nia i jego skut­ki. Jednak tą meto­dą i tak nie stwo­rzysz nawet dość dobrej symulacji.

Jak nie trud­no się domy­śleć ana­li­za wyma­gań nie może trwać w nie­skoń­czo­ność, powsta­nie mało takich opi­sów sce­na­riu­szy czy­li opis moc­no nie­kom­plet­ny. Zapis wywia­dów, obser­wa­cje, ankie­ty i poprze­sta­nie na nich, nie mają pra­wa się spraw­dzić bo w skoń­czo­nym cza­sie na ana­li­zę zawsze będzie ich za mało a i tak będą cha­otycz­ne (będzie to tyl­ko część tego co może się wyda­rzyć i nie wia­do­mo, ile to pro­cent cało­ści bo nie zna­my wszystkich).

Przypadki uży­cia same w sobie, sta­no­wią bar­dzo mier­ne przy­bli­że­nie rze­czy­wi­sto­ści. Oddanie pro­gra­mu do użyt­ku, reali­zu­ją­ce­go tyl­ko ?kon­kret­ne sce­na­riu­sze? i to w spo­sób ?obmy­ślo­ny? przez pro­gra­mi­stę, któ­ry nie potra­fi grać w sno­oke­ra a tyl­ko sły­szał od gra­cza jak się to robi, naj­pew­niej skoń­czy się zaba­wą w kolej­ne ite­ra­cje, pro­to­ty­py itp. Taki pro­gram będzie coraz lep­szy ale nadal nie dotknie nawet reali­zmu sno­oke­ra (wię­cej o tym tu Czy wyma­ga­nia opi­su­ją tyl­ko to ?co? sys­tem ma robić?).

Fowler pisze:

Aby napi­sać na praw­dę dobrą grę, powi­nie­neś raczej zro­zu­mieć pra­wa rzą­dzą­ce ruchem kul, ich zależ­ność od siły i kie­run­ku ude­rze­nia, kie­run­ku itp. Zrozumienie tych praw pozwo­li Ci znacz­nie łatwiej napi­sać dobre oprogramowanie.

I tu jest sed­no: ana­li­za nie powin­na być tyl­ko pasmem wywia­dów, któ­re­go pro­duk­tem będę set­ki stron zapi­sów z ankiet i prze­pro­wa­dzo­nych roz­mów. Analiza, to duża pra­ca, któ­rej celem powin­no być zro­zu­mie­nie a nie tyl­ko opisanie. 

Jaka jest róż­ni­ca? Produktem ana­li­zy, czy­li zro­zu­mie­nia zja­wi­ska (pra­cy fir­my itp.) jest model jej logi­ki dzia­ła­nia (logi­ka biz­ne­so­wa), ten model – popraw­ny – pozwa­la prze­wi­dy­wać co nas cze­ka (testo­wa­ny jest na popraw­ność loso­wo wybra­ny­mi zda­rze­nia­mi w fir­mie). Ten model to model dzie­dzi­ny sys­te­mu (model logi­ki biz­ne­so­wej: spe­cy­fi­ka­cja reguł biz­ne­so­wych). Produktem wywia­dów jest nie­ste­ty wyłącz­nie opis skut­ków w reak­cji na bodź­ce (np. przy­pad­ki uży­cia) ale nadal nie­zro­zu­mia­łe jest to dla­cze­go aku­rat takie” skutki.

Wszystko to co nas ota­cza, samo w sobie jest natu­ral­nie pro­ste. Złożone są, nie poszcze­gól­ne rze­czy, a to, że jest ich wie­le i mają na sie­bie wza­jem­ny wpływ. Celem ana­li­zy jest ziden­ty­fi­ko­wa­nie w naszym oto­cze­niu tych pro­stych ele­men­tar­nych rze­czy i zro­zu­mie­nie ich wza­jem­ne­go na sie­bie wpły­wu. Zrozumienie to mani­fe­stu­je się w posta­ci umie­jęt­no­ści stwo­rze­nia mode­lu tych współ­ist­nie­ją­cych pro­stych rze­czy, zro­zu­mie­nia i opi­sa­nia ich cech i reguł wza­jem­ne­go oddzia­ły­wa­nia. Jeżeli tym ana­li­zo­wa­nym śro­do­wi­skiem jest orga­ni­za­cja, powsta­nie jej model, wie­dza o tym jak funk­cjo­nu­je. A gdzie tu jest miej­sce na opro­gra­mo­wa­nie? By powsta­ło, nale­ży stwo­rzyć tak­że i jego model, by zro­zu­mieć i opi­sać to cze­go potrze­buj­my. Pamiętajmy, że jed­na z naj­trud­niej­szych gier na świe­cie ? sza­chy ? to tyl­ko kil­ka­na­ście figur i pro­ste regu­ły ich prze­miesz­cza­nia. Nawet naj­więk­sza orga­ni­za­cja to tyl­ko skoń­czo­na licz­ba ról i reguł ich postę­po­wa­nia. Należy je tyl­ko odkryć. (żr. Jarosław Żeliński, refe­rat na kon­fe­ren­cji: Firma IT-Consulting Jarosław Żeliński – ana­li­tyk biz­ne­so­wy).

Nie kry­ty­ku­je idei sto­so­wa­nia przy­pad­ków uży­cia, sam je sto­su­ję. One jed­nak są kon­kret­ny­mi, pla­no­wa­ny­mi przy­pad­ka­mi uży­cia opro­gra­mo­wa­nia, to mini­mal­ny zestaw opcji w menu – wyma­ga­ne teraz” usłu­gi sys­te­mu. To nie ma jed­nak nic wspól­ne­go z wewnętrz­ną budo­wą opro­gra­mo­wa­nia, ta powin­na mode­lo­wać zasta­ną rzeczywistość.

Istnieje coś takie­go jak zasa­da SOLID pro­jek­to­wa­nia opro­gra­mo­wa­nia (jed­na z klu­czo­wych cech dobrych pro­jek­tów opro­gra­mo­wa­nia). Cóż to jest SOLID? To roz­wi­nię­cie od ang. Single respon­si­bi­li­ty, Open-clo­sed, Liskov sub­sti­tu­tion, Inter­fa­ce segre­ga­tion and Depen­den­cy inver­sion (wię­cej na stro­nie SOLID (object-orien­ted design) – Wikipedia, the free encyc­lo­pe­dia).

Dzisiaj tyl­ko o skut­kach zanie­dba­nia jed­nej, klu­czo­wej chy­ba wła­sno­ści, któ­ra doty­czy całej apli­ka­cji: Open-Close, któ­ra ozna­cza: apli­ka­cja powin­na być zamknię­ta na zmia­ny i otwar­ta na roz­bu­do­wę.  Dla wie­lu na począt­ku ta zasa­da brzmi wręcz kurio­zal­nie ale ona jak naj­bar­dziej jest moż­li­wa do reali­za­cji. Proszę zwró­cić uwa­gę, że takie wła­snie są dobrze zarzą­dza­ne fir­my, nie ma w nich rewo­lu­cji orga­ni­za­cyj­nej co roku, one się roz­wi­ja­ją a nie zmieniają.

Oprogramowanie, jeże­li w wyni­ku ana­li­zy wyma­gań opra­co­wa­no nie tyl­ko raport z wywia­dów ale tak­że model logi­ki dzia­ła­nia, też speł­ni te zasa­dę. Czym gro­zi jej nie­speł­nie­nie w sto­sun­ku do opro­gra­mo­wa­nia? A tym, do cze­go przy­znał się jeden z pro­gra­mi­stów pod­czas pew­nej dys­ku­sji na forum:

kil­ka razy doświad­czy­łem sytu­acji, że aby speł­nić nowe pro­ste wyma­ga­nie trze­ba było się namę­czyć zarów­no z mode­lem danych jak i apli­ka­cją, Oczywiście moż­na w takiej sytu­acji zarzu­cić, że sys­tem był źle zapro­jek­to­wa­ny, nie­ska­lo­wal­ny, nie prze­strze­gał SOLIDów, nie korzy­stał z wzor­ców itd ale to już jest inna bajka.

Na co ja odpo­wie­dzia­łem: nie, to jest wła­śnie ta baj­ka o nazwie ana­li­za wyma­gań i pro­jek­to­wa­nie, któ­re powin­ny być zro­zu­mie­niem a nie tyl­ko ste­no­gra­mem. Wtedy nowe funk­cjo­nal­no­ści opro­gra­mo­wa­nia moż­na doda­wać bez potrze­by prze­bu­do­wy jego wewnętrz­nej struk­tu­ry. Nie raz jest z powo­du tych kosz­tów po pro­tu nie­moż­li­wy jest roz­wój sys­te­mu. Oceńcie teraz Państwo sami, Ci któ­rzy tego doświad­czy­li, skut­ki wdro­że­nia np. sys­te­mu ERP z kasto­mi­za­cją.… nie­ste­ty ogrom­na więk­szość tego opro­gra­mo­wa­nia nie speł­nia zasa­dy SOLID. Dlaczego? Bo model rela­cyj­ny baz danych, jeże­li obej­mu­je wszyst­kie dane sys­te­mu, nie­ste­ty nie speł­nia tej zasa­dy z zało­że­nia. A dostaw­cy tych sys­te­mów wręcz cie­szą się z tego rekla­mu­jąc się: nasz sys­tem jest w peł­ni zin­te­gro­wa­ny poprzez pra­cę na wspól­nej bazie danych”.… Jak to prze­czy­tasz, nie kupuj tego…

Utopia – czyli model ideału pomaga w projektach

Usługa ta sta­no­wi sobą audyt tre­ści i struk­tu­ry doku­men­tów w pro­ce­sach biz­ne­so­wych oraz opra­co­wa­nie mode­lu archi­tek­tu­ry IT w celu mapo­wa­nia doku­men­tów na apli­ka­cje, w któ­rych powsta­ją i są wyko­rzy­sty­wa­ne (inte­gra­cja). Są to wyłą­czo­ne i połą­czo­ne razem pierw­sze eta­py usług Audyt orga­ni­za­cji, pod­no­sze­nie efek­tyw­no­ści oraz Analiza i Opracowanie Wymagań na Oprogramowanie. Jednym z głów­nych celów i pro­duk­tów jest opra­co­wa­na stra­te­gia cyfry­za­cji i archi­wi­za­cji doku­men­tów w orga­ni­za­cji oraz zarzą­dza­nia ich treścią.

Ten wpis adre­su­ję przede wszyst­kim mene­dże­rom nie tyl­ko IT. Analitycy i pro­gra­mi­ści spo­koj­nie mogą go pomi­nąć, chy­ba, że …;) chcą wie­dzieć dla­cze­go powin­ny powsta­wać ide­ali­zo­wa­ne pro­jek­ty, kie­dy mogą cza­sem wyko­nać nie­ko­niecz­nie ide­al­ną imple­men­ta­cję i dla­cze­go nie nale­ży pomi­jać eta­pu pro­jek­to­wa­nia ide­ali­za­cji .

W jed­nym z ostat­nich wpi­sów w dys­ku­sji napi­sa­łem w komen­ta­rzach, że:

…jestem pury­stą for­mal­nym. Jednak nie dla­te­go, by pacy­fi­ko­wać pro­jek­ty orto­dok­sją. To efekt dwóch rze­czy: teo­ria pozna­nia jako restryk­cyj­ne pod­cho­dze­nie do seman­ty­ki, pozwa­la unik­nąć nie­jed­no­znacz­no­ści. Druga rzecz, to zde­fi­nio­wa­nie ide­ału, pozwa­la oce­nić (zmie­rzyć) odstęp­stwo kon­kret­ne­go pro­jek­tu od nie­go [od ide­ału]. To pozwa­la oce­nić ryzy­ko takie­go pro­jek­tu. Fizyka ma np. nie­ist­nie­ją­ce w natu­rze ide­al­ne waha­dło czy cia­ło dosko­na­le czar­ne , po co? By móc oce­nić błąd rze­czy­wi­stych obli­czeń. Zdaję sobie spra­wę, że to filo­zo­fia, ale taki mam cel , nie tyl­ko ana­li­zo­wać i mode­lo­wać ale w 100% rozu­mieć (Czym jest a czym nie jest tak zwa­ny model dzie­dzi­ny sys­te­mu).

Dość czę­sto spo­ty­kam się z zarzu­tem, że to szko­dzi pro­jek­tom, że trze­ba z jed­nej stro­ny nagi­nać zasa­dy a z dru­giej, że nie ma co zaj­mo­wać się ide­al­ny­mi sys­te­ma­mi bo takich nie będzie, że ogra­ni­cze­nia pro­jek­tu, głów­nie czas i budżet, wyma­ga­ją psu­cia” bo na ide­ały nie ma czasu. 

To są nie­ste­ty, w moim mnie­ma­niu, tłu­ma­cze­nia ludzi nie potra­fią­cych tego ide­ału zro­bić czy­li nie­ma­ją­cych pomy­słu na wła­ści­we roz­wią­za­nie, czy­taj, nie potra­fią­cych pro­ble­mu rozwiązać. 

Droga na skró­ty to dro­ga nie­wie­dzy. Nie twier­dzę tu, że sens mają wyłącz­nie pro­jek­ty ide­al­ne. Twierdze, że na eta­pie ana­li­zy pro­ble­mu i pro­jek­to­wa­nia powi­nien powstać ide­ał, a dopie­ro na eta­pie ana­li­zy zakre­su pro­jek­tu i oce­ny wyko­nal­no­ści, jest miej­sce na ewen­tu­al­ne uprosz­cze­nia, bo tu są one czy­nio­ne świadomie.

Z tezą taką w lite­ra­tu­rze spo­ty­kam się bar­dzo rzad­ko, ale spo­ty­kam . Możliwe, że to bar­dzo odważ­na teza: 

więk­szość pro­jek­tów to roz­wią­zy­wa­nie nie­zro­zu­mia­ne­go problemu. 

Statystyki jed­nak zda­ją się potwier­dzać, że coś jest na rze­czy .

Na szczę­ście, nie ja jeden tak sądzę. Tu zacy­tu­ję tak­że blog pew­ne­go programisty:

cią­gle zmie­nia­ją­cy się pro­gram zwięk­sza swo­ją zło­żo­ność o ile nie pochy­li­my się nad kodem aby ją zmniej­szyć. Pisanie pro­gra­mów jest łatwe, wręcz banal­nie łatwe, jed­nak pisa­nie tak, aby dało się je dłu­go i w mia­rę tanio utrzy­my­wać jest bar­dzo trud­ne. Wynika to z dwóch zło­żo­no­ści. Jedna to zło­żo­ność same­go pro­ble­mu, dru­ga to zło­żo­ność przy­pad­ko­wa. Tą przy­pad­ko­wą two­rzy­my my sami ? pro­gra­mi­ści. Sami kom­pli­ku­je­my soft bar­dzo czę­sto zupeł­nie nie­po­trzeb­nie. Sami idąc na skró­ty gma­twa­my kod tak, że sta­je się z dnia na dzień coraz droż­szy w utrzy­ma­niu. To podra­ża­nie utrzy­ma­nia to wła­śnie dług tech­no­lo­gicz­ny. Dług tech­no­lo­gicz­ny, jak każ­dy dług ma to do sie­bie, że im dłu­żej nie spła­ca­ny tym wię­cej będzie kosz­to­wać. (Dług tech­no­lo­gicz­ny | @rek onli­ne | Arkadiusz Benedykt, Gorąco pole­cam cały ten cykl artykułów).

Tu autor pastwi się, i słusz­nie, na zacią­ga­niem dłu­gu, któ­ry ja postrze­gam jako dług nie tyl­ko tech­no­lo­gicz­ny. To dług nie­zro­zu­mie­nia mają­cy swój począ­tek już na eta­pie ana­li­zy: ktoś nie chciał do koń­ca zro­zu­mieć zło­żo­no­ści pro­ble­mu (patrz wytłusz­cze­nie w cyta­cie), zigno­ro­wał etap dogłęb­nej ana­li­zy pro­ble­mu i zaczął kodo­wać: zacią­gnął dług nie pono­sząc kosz­tu zro­zu­mie­nia tyl­ko zaczy­na od razu kodo­wać. Przypomnę, że pomi­ja­nie dogłęb­nej ana­li­zy i two­rze­nie kodu to imple­men­ta­cja cze­goś, cze­go wła­śnie nie chcie­li­śmy do koń­ca zro­zu­mieć. Czy to zda­nie nie brzmi strasz­nie? Co powstanie?

Czego się spo­dzie­wać po pro­jek­cie, gdy sły­szę: nie ma cza­su na ana­li­zę, myśmy już pod­pi­sa­li umo­wę z wyko­naw­cą bo nasza fir­ma nie ma cza­su. Niestety naj­czę­ściej taki pro­jekt trwa znacz­nie dłu­żej niż pla­no­wa­no, pie­nią­dze oszczę­dzo­ne na zbęd­nym” pro­jek­to­wa­niu ide­ału z ogrom­ną nawiąz­ką są wyda­wa­ne na kolej­ne mody­fi­ka­cje i popraw­ki (spła­ta dłu­gu, nie raz bar­dzo kosztowna).

O sku­tecz­nym zarzą­dza­niu, posia­da­niu wizji, napi­sa­no wie­le, nie jest to miej­sce na powie­la­nie tych prawd. Spójrzmy na poniż­szy cytat:

Społeczeństwo nie­zdol­ne do wyda­wa­nia na świat uto­pii i do poświę­ca­nia się jej zagro­żo­ne jest skle­ro­zą i ruiną. Mądrość, dla któ­rej nie ist­nie­ją żad­ne fascy­na­cje, zale­ca nam szczę­ście dane, goto­we. Wybór szczę­ścia wyobra­żo­ne­go czy­ni nas zdol­nym do zmia­ny, do wzro­stu. Emil Cioran (Business Dialog – Posłuchaj. Powiedz. Przynosimy radość owoc­nej roz­mo­wy)..

A teraz małe ćwi­cze­nie: zamień­cie pań­stwo sło­wo Społeczeństwo” na Organizacje”…

Powyższe wywo­dy, cza­sa­mi wspo­mi­nam o pro­ble­mie dłu­gu na kon­fe­ren­cjach czy na forach, natych­miast wywo­łu­ją pobud­kę zwo­len­ni­ków metod zwin­nych (co by to nie mia­ło zna­czyć). Wiem, że są podob­no róż­ne for­my zwin­no­ści, te dobre i te złe. Ale podob­no zakoń­czo­ne suk­ce­sem zwin­ne pro­jek­ty są jak Yeti: każ­dy o nich mówi a nikt nie widział. Tu zno­wu zacy­tu­ję przy­wo­ły­wa­ny już tu blog:

Modne ostat­nio pro­gra­mo­wa­nie agi­le czy też pro­gra­mo­wa­nie zwin­ne ozna­cza w dużym uprosz­cze­niu cią­głą ewo­lu­cję i cią­głe wpro­wa­dza­nie zmian, tak żeby być ela­stycz­nym na potrze­by biz­ne­su. Nie da się być agi­le budu­jąc mono­li­ty, nie da się być agi­le zacią­ga­jąc coraz to nowe dłu­gi tech­no­lo­gicz­ne. W koń­cu, nie da się być agi­le jeśli po roku czy dwóch wpro­wa­dza­nie zmian zaczy­na trwać dłu­żej i dłu­żej. Jeśli chce­my być agi­le to musi­my bar­dzo moc­no trzy­mać się zasad dobre­go pro­gra­mo­wa­nia. Musimy two­rzyć ela­stycz­ne i otwar­te kon­struk­cje zamiast mono­li­tów. SOLID w tym bar­dzo poma­ga cho­ciaż nie jest to jedy­na ?reli­gia?. Aby to zro­bić trze­ba poświę­cić odpo­wied­nią ilość cza­su i potu aby wypro­du­ko­wać dobry kawa­łek kodu. (Monolity to też dług tech­no­lo­gicz­ny | @rek onli­ne | Arkadiusz Benedykt).

Cóż, o SOLID za nie­dłu­go napi­szę wię­cej, dziś podam jed­ną z klu­czo­wych zasad, nazwał bym ją klu­czo­wym wyma­ga­niem poza­funk­cjon­la­nym: pro­jekt ma być odpor­ny na zmia­ny i otwar­ty na roz­sze­rze­nie. Jak to osią­gnąć? jest tyl­ko jeden spo­sób: wyko­nać dobry pro­jekt. Dobry czy­li prze­my­śla­ny, z peł­nym zro­zu­mie­niem pro­ble­mu i świa­do­mym odkła­da­niem pew­nych prac.

Na zakoń­cze­nie przy­znam, że wśród moich nie­do­szłych klien­tów i pro­gra­mi­stów mam wie­lu wro­gów. To Ci, któ­rzy uwa­ża­ją, że ana­li­zy i pro­jek­to­wa­nie ide­ału (co by tu sło­wo nie mia­ło ozna­czać) na samym począt­ku są bez sen­su, bo i tak wyma­ga­nia biz­ne­su się zmie­nią, więc i pro­gram będzie się zmie­niał. Ja wte­dy pytam: zmie­niał czy roz­sze­rzał? Jeżeli wyma­ga­nia się zmie­nia­ją to raczej sygnał, że nie zosta­ły na począt­ku prze­my­śla­ne… Ale wyma­ga­niem powi­nien być cel a nie aktu­al­ne środ­ki jego osią­ga­nia! Biznes tak­że ma skłon­no­ści do zacią­ga­nia opi­sy­wa­ne­go dłu­gu… Na koniec w kwe­stii wro­gów pół żar­tem i pół serio:

Chińczycy hoł­du­ją powie­dze­niu: ?jak posie­dzisz wystar­cza­ją­co dłu­go nad brze­giem rze­ki, to zoba­czysz tru­py swo­ich wro­gów pły­ną­ce z prą­dem”. No więc sobie siedzę.

… i nie raz je oglą­dam… a sie­dzę sobie ana­li­zu­jąc i pro­jek­tu­jąc… 😉 i nie jestem tu sam…

Źródła

Niaz, M. (1999). The role of ide­ali­za­tion in scien­ce and its impli­ca­tions for scien­ce edu­ca­tion. Journal of Science Education and Technology, 8(2), 145 – 150.
Niaz, M. (1993). If Piaget’s epi­ste­mic sub­ject is dead, shall we bury the scien­ti­fic rese­arch metho­do­lo­gy of ide­ali­za­tion? Journal of Research in Science Teaching, 30(7), 809 – 812. https://​doi​.org/​1​0​.​1​0​0​2​/​t​e​a​.​3​6​6​0​3​0​0​717
Weisberg, M. (2007). Three Kinds of Idealization: The Journal of Philosophy, 104(12), 639 – 659. https://​doi​.org/​1​0​.​5​8​4​0​/​j​p​h​i​l​2​0​0​7​1​0​4​1​240
Jørgensen, M., & Moløkken-Østvold, K. (2006). How lar­ge are softwa­re cost over­runs? A review of the 1994 CHAOS report. Information and Software Technology, 48(4), 297 – 301. https://​doi​.org/​1​0​.​1​0​1​6​/​j​.​i​n​f​s​o​f​.​2​0​0​5​.​0​7​.​002
Liu, C. (2004). Laws and Models in a Theory of Idealization. Synthese, 138(3), 363 – 385.
Matthews, M. R. (2004). Idealisation and Galileo’s pen­du­lum disco­ve­ries: Historical, phi­lo­so­phi­cal and peda­go­gi­cal con­si­de­ra­tions. Science & Education, 13(7 – 8), 689 – 715.