Hurtownie danych czyli Systemy od historii”

Wczoraj mia­ła miej­sce kon­fe­ren­cja: Business Intelligence GigaCon 2011. Więcej tu: Hurtownie danych jako stan­dar­do­we modu­ły COTS (Commercial off the shelf) nowo­pro­jek­tow­nych sys­te­mów dedy­ko­wa­nych December 6th.

Poruszyłem mię­dzy inny­mi pro­ble­ma­ty­kę: aspek­ty pro­jek­to­we sys­te­mów dedy­ko­wa­nych i dosto­so­wy­wa­nych oraz ?core doma­in? i poję­cie COTS (Szczegółowe infor­ma­cje http://​giga​con​.org/​b​i​_​2​011).

Nie jest moim celem powie­la­nie tu refe­ra­tu, dla­te­go tyl­ko kil­ka kwe­stii a potem mała uwa­ga na temat metod argu­men­ta­cji osób rekla­mu­ją­cych swo­je pro­duk­ty, ale po kolei.

Hurtownia danych jako skład historii

W swo­im refe­ra­cie wska­za­łem na hur­tow­nie danych i meto­dy skła­do­wa­nia tam danych oraz na poję­cie sys­tem dedy­ko­wa­ny”. I tak:

  1. MIT: Oprogramowanie dedy­ko­wa­ne to kosz­tow­ne, dłu­go wyko­ny­wa­ne i ryzy­kow­ne, pro­jek­ty two­rze­nia opro­gra­mo­wa­nia od zera dla klienta,
  2. PRAWDA: Oprogramowanie dedy­ko­wa­ne to opro­gra­mo­wa­nie (System) zapro­jek­to­wa­ne na bazie dobrze opi­sa­nych wyma­gań, zło­żo­ne z kom­po­nen­tów (typo­we goto­we kom­po­nen­ty to ERP, CRM, SCM, inne).

To zna­czy, że doce­lo­wo – jako sys­tem dedy­ko­wa­ny – klient otrzy­ma zestaw zin­te­gro­wa­nych kom­po­nen­tów (pod­sys­te­mów, apli­ka­cji). Możliwe jest, że nie­któ­re zosta­ną opra­co­wa­ne i wyko­na­ne spe­cjal­nie dla nie­go. Pełny Zintegrowany System wspo­ma­ga­ją­cy zarzą­dza­nie (wszyst­kie apli­ka­cje w fir­mie) naj­czę­ściej nawet w 90% skła­da się z opro­gra­mo­wa­nia goto­we­go (COTS ? Commercial of the shelf).

Kolejnym mitem jest teza, że koszt inte­gra­cji jest duży. Powiem tak: zły pro­jekt zawsze koń­czy się wyso­ki­mi kosz­ta­mi, pro­jekt inte­gra­cyj­ny także.

Praktyka poka­zu­je, że popraw­nie posta­wio­ne wyma­ga­nia oraz pro­jekt wyko­na­ny przed wybo­rem roz­wią­za­nia, to naj­czę­ściej pro­jek­ty, w któ­rych kosz­ty inte­gra­cji są wie­lo­krot­nie niż­sze od kosz­tów kasto­mi­za­cji sys­te­mów zin­te­gro­wa­nych ERP i para­dok­sal­nie trwa to krócej.

Po trze­cie wdra­ża­nie eta­pa­mi (apli­ka­cja po apli­ka­cji) pozwa­la na to, by te poszcze­gól­ne pod­sys­te­my pra­co­wa­ły na sie­bie bez cze­ka­nia na cał­ko­wi­te zakoń­cze­nie wdro­że­nia cało­ści, jak to ma miej­sce naj­czę­ściej pod­czas wdra­ża­nia duże­go i zin­te­gro­wa­ne­go sys­te­mu. Warto tak­że zauwa­żyć, że taka – tak zwa­na kom­po­nen­to­wa – archi­tek­tu­ra jest łatwa w mody­fi­ka­cji (moż­li­wa jest wymia­na dowol­ne­go skład­ni­ka bez szko­dy dla innych cze­go nie moż­na powie­dzieć o dużych sys­te­mach ERP). Przykład z sys­te­ma­mi BI (Business Inteligence), któ­re będę tu zwał Raportowaniem.

Ogólnie wyma­ga­nia na sys­tem wspo­ma­ga­ją­cy zarzą­dza­nie maja taką strukturę:

Diagram Przypadek uzycia

Diagram jest pro­sty. Chcę zwró­cić uwa­gę na to, że wie­le funk­cjo­nal­no­ści (może nawet wszyst­kie) sys­te­mów wspo­ma­ga­ją­cych zarzą­dza­nie moż­na na takie dwie kate­go­rie podzie­lić. Przypomnę, że dia­gra­my przy­pad­ków uży­cia to nie pro­jek­ty sys­te­mu” a ich spis tre­ści”. Projektem, na wyso­kim pozio­mie abs­trak­cji (ang. HLD czy­li [[Hihg Level Design]]), jest dopie­ro to:

Model komponentow

Załóżmy, że archi­tekt sys­te­mu stwo­rzył powyż­szy model. Decyzja pro­jek­to­wa: sys­tem trans­ak­cyj­ny obsłu­gu­je naszą spe­cy­fi­kę biz­ne­so­wą, jest odpo­wie­dzią na wyma­ga­nie: Obsługa tego co się teraz dzie­je. Opracowano dokła­da­nie wyma­ga­nia, na ryn­ku nie zna­le­zio­no wyma­ga­nych funk­cjo­na­li­ści i ta część sys­te­mu zosta­nie wytworzona.

W ramach wyma­gań jed­nak, jak widać na poprzed­nim dia­gra­mie, mamy tak­że wyma­ga­nie: Pokaż co wyda­rzy­ło się kie­dyś. Są to funk­cjo­nal­no­ści rapor­to­we. Raportowanie jako funk­cja sys­te­mu jest dość dobrze opa­no­wa­na, są na ryn­ku goto­we pro­duk­ty (jest ich wie­le). Więc z pro­jek­tu deve­lo­per­skie­go (opro­gra­mo­wa­nie pro­jek­to­wa­ne) wyłą­czo­no ten zakres i kupio­no pod­sys­tem, popu­lar­nie zwa­ny hur­tow­nia danych. Większość tego typu apli­ka­cji ma bar­dzo dobre, uni­wer­sal­ne inter­fej­sy, więc ich inte­gra­cja nie sta­no­wi żad­ne­go problemu.

System trans­ak­cyj­ny, pro­jek­to­wa­ny, w ogó­le nie zaj­mu­je się histo­rią, prze­twa­rza wyłącz­nie dane bie­żą­ce dzię­ki cze­mu stał się znacz­nie prost­szy, czy­taj tań­szy w wyko­na­niu. Wszelkie dane o histo­rycz­nych sta­nach naszych danych są w hur­tow­ni danych a tę mamy już goto­wą, taniej niż koszt wytwo­rze­nia podob­ne­go systemu.

I tak: ta część, któ­ra opi­su­je spe­cy­fi­kę naszej orga­ni­za­cji (ozna­czo­na na nie­bie­sko), to tak zwa­ne core doma­in” czy­li głów­ny ele­ment dzie­dzi­ny sys­te­mu. Jeżeli nie znaj­dzie­my na ryn­ku pro­duk­tu, któ­ry w 100% mu odpo­wia­da nale­ży wydzie­lić taki frag­ment i stwo­rzyć sobie dedy­ko­wa­ny. Kastomizacja goto­we­go pro­duk­tu zawsze jest kom­pro­mi­sem, naj­czę­ściej bar­dzo kosz­tow­nym. (wię­cej o prak­ty­ce pro­jek­to­wa­nia zwa­nej DDD).

Pojecie [[COTS (Commercial off the shelf)]], o któ­rym już na blo­gu nie raz wspo­mi­na­łem, to tu nasz goto­wy kom­po­nent: hur­tow­nia danych. W efek­cie wszel­kie funk­cjo­nal­no­ści zwią­za­ne z rapor­to­wa­niem imple­men­tu­je­my w tej hur­tow­ni, pozo­sta­łe musi­my wytwo­rzyć. To dodat­ko­wa korzyść: baza danych sys­te­mu trans­ak­cyj­ne­go sta­je się dużo prost­sza, czy­taj tań­sza, bo model danych nie musi obsłu­gi­wać historii”.

Jeżeli potrzeb­ne nam zaawan­so­wa­ne meto­dy rapor­to­wa­nia i ana­liz nale­ży raczej zaku­pić apli­ka­cję z rodza­ju Business Inteligence zamiast zle­cać dostaw­cy sys­te­mu (np. ERP) kolej­ne imple­men­to­wa­nie wyra­fi­no­wa­nych – kosz­tow­nych w opra­co­wa­niu i utrzy­ma­niu – raportów.

Przy oka­zji: uży­cie hur­tow­ni danych w tle”, to nic inne­go jak clo­ud com­pu­ting :), tu tak zwa­na chmu­ra prywatna”.

Demagogia na konferencji

Z ust oso­by pro­mu­ją­cej pewien pro­dukt zali­czo­ny do Business Intelligence padło stwier­dze­nie: Nasz pro­dukt jest pro­sty, pobie­ra dane do rapor­tów bez­po­śred­nio z sys­te­mu ERP, nie musi­my więc dodat­ko­wo inwe­sto­wać w pośred­ni­czą­cy sys­tem hur­tow­ni danych, kto­ry może mieć dane nie­ak­tu­al­ne. Tezę tę miał poprzeć dia­gram podob­ny do tego:

Demagodia OLAP vs Proste BI

U góry mam skom­pli­ko­wa­ny sys­tem BI” a na dole nasz pro­sty i łatwy w obsłu­dze sys­tem”. To jak by usu­nąć zie­lo­ny kom­po­nent z powyż­sze­go dia­gra­mu kom­po­nen­tów. Gdzie haczyk? Ano tu:

Model danych ERP vs OLAP

Górny dia­gram to przy­kład mode­lu danych dla hur­tow­ni danych. Jest pro­sty, w prak­ty­ce sko­men­to­wa­ny po ludz­ku”, jako meta­da­ne, jest czymś, z czym może pra­co­wać każ­dy, kto tyl­ko zna daną dzie­dzi­nę, taki model danych (tak zwa­na gwiaz­da) odwzo­ro­wu­je w pro­sty spo­sób zna­ne biz­ne­so­we pojęcia.

Diagram niżej to model danych nie­wiel­kie­go sys­te­mu biz­ne­so­we­go (model danych sys­te­mu ERP, mają­cy nawet tysią­ce rela­cyj­nych, nic nie mówią­cych zwy­kłe­mu śmier­tel­ni­ko­wi tabel, był­by w tej pro­por­cji zwy­kłą kolo­ro­wą nie­czy­tel­ną pla­mą…). Wykonanie samo­dziel­nie jakie­go­kol­wiek rapor­tu z tego dru­gie­go sys­te­mu tabel gra­ni­czy z cudem. Można przy­go­to­wać (admi­ni­stra­tor bazy) tak zwa­ne wido­ki” dla użyt­kow­ni­ków co nie zmie­nia fak­tu, że ich opra­co­wa­nie to wie­dza tajem­na” i nikt z biz­ne­su” sam tego nie zro­bi. I naj­waż­niej­sze: dostęp do peł­ne­go mode­lu danych naj­czę­ściej wyma­ga zła­ma­nia zasad bez­pie­czeń­stwa to jest udo­stęp­nie­nia danych z pomi­nię­ciem mecha­ni­zmów kon­tro­l­nych apli­ka­cji ERP.

Hurtownia danych to model stwo­rzo­ny pod kątem prze­twa­rza­nia fak­tów histo­rycz­nych na pro­stym mode­lu danych (dia­gram powy­żej, gór­ny, to tak zwa­na kost­ka OLAP). Opracowanie takie­go mode­lu wyma­ga spe­cjal­nej ana­li­zy i pro­jek­tu, ale nie zapo­mi­naj­my: ana­li­zę się robi raz a rapor­ty sta­le… tu prze­szko­lo­ny użyt­kow­nik biz­ne­so­wy sam daje radę bez problemu.

Tak więc sza­now­ni Państwo. Jeśli tyl­ko Wasza fir­ma jest bli­żej czo­łów­ki niż ogo­na ran­kin­gu ryn­ku w Waszej bran­ży, nie daj­cie się namó­wić na jeden zin­te­gro­wa­ny ERP i jakiś model refe­ren­cyj­ny, bo nawet jak uda się go wdro­żyć, to zmia­na cze­go­kol­wiek będzie trud­na a upgra­de do now­szej wer­sji nie­moż­li­wy. Opracowanie pro­jek­tu sys­te­mu skła­da­ją­ce­go się z kom­po­nen­tów, pozwo­li Wam dobrać naj­le­piej speł­nia­ją­ce Wasze wyma­ga­nia apli­ka­cje. Jak z kloc­ków LEGO moż­na zło­żyć dedy­ko­wa­ny sys­tem” poma­ga­ją­cy utrzy­mać prze­wa­gę na ryn­ku, a nie cofa­ją­cy Waszą fir­mą do pozio­mu innych pod­mio­tów w bran­ży”.

Prognozowanie

Problem w tym, że z tych samych danych róż­ne fir­my ana­li­tycz­ne potra­fią wycią­gnąć róż­ne wnio­ski. Nie mam wąt­pli­wo­ści, że w naj­bliż­szych cza­sie cze­ka nas wysyp firm spe­cja­li­zu­ją­cych się w ana­li­zie danych pły­ną­cych z inter­ne­tu, ale póki co, wnio­ski są fru­stru­ją­ce: nie potra­fi­my wia­ry­god­nie prze­wi­dy­wać tren­dów ryn­ko­wych. (Piotr Podleśny, pre­zes fir­my Atena, źr. Prognozy wyma­ga­ją zro­zu­mie­nia danych – Computerworld).

Nauka wyka­za­ła, że sama ana­li­za danych histo­rycz­nie nie sta­no­wi żad­nej pro­gno­zy. Do tak zwa­nej pre­dyk­cji wyma­ga­ny jest model przed­mio­tu”, któ­re­go zacho­wa­nia chce­my prze­wi­dy­wać. Czy to moż­li­we? Tak. Czy to łatwe? Znowu odpo­wiem: nie. Potrzebny jest model a nie tyl­ko dane histo­rycz­ne (te pozwa­la­ją wyłącz­nie na ana­li­zę tego co było), wię­cej o tym w arty­ku­le o meto­dach nauko­wych ana­li­zy.

Czas nie jest aktorem dla Systemu c.d. czyli projekt

i uda­ło się. Ciąg dal­szy tek­stu Czas nie jest akto­rem dla Systemu, zapra­szam do lektury.

Prosty przy­kład (na opi­sa­nie bom­by w sie­ci inter­net się nie odwa­ży­łem ;)). Produkt jaki ma powstać to syre­na sygna­ło­wa. Wymaganie funk­cjo­nal­ne: sys­tem powi­nien pozwa­lać na zapro­gra­mo­wa­nie godzi­ny i cza­su trwa­nia sygna­łu. Wymaganie poza-funk­cjo­nal­ne: dokład­ność zega­ra pro­gra­ma­to­ra ma być nie gor­sza niż błąd rzę­du sekun­dy w ska­li roku (:)).

Wersja pierwsza

Diagram pro­sty (wprost mode­lo­wa­ne wyma­ga­nia zama­wia­ją­ce­go) za to imple­men­ta­cja już nie. Diagram przy­pad­ków uży­cia, jego celem jest opi­sa­nie wyma­gań funk­cjo­nal­nych, czy­li tego jakie sys­tem ma ofe­ro­wać usłu­gi albo jak kto woli serwisy:

Diagram enig­ma­tycz­ny ale do tego słu­ży ten typ dia­gra­mu: akto­rzy i usłu­gi dla nich (tak zwa­ny korzeń pro­jek­tu). W tej posta­ci (pierw­sza ite­ra­cja ana­li­zy i pro­jek­to­wa­nia) otrzy­ma­my np. taki pro­jekt archi­tek­tu­ry (logi­ki) systemu:

Jak widać sys­tem skła­da się z dwóch pod­sta­wo­wych kom­po­nen­tów: Sterownika i Generatora Dźwięku czy­li syre­ny wła­ści­wej ;). Sterownik jest imple­men­to­wa­ny (znak Realizacji) z pomo­cą gene­ra­to­ra sygna­łu cza­su i pro­gra­ma­to­ra. Programator ma inter­fejs użyt­kow­ni­ka (GUI), zapro­gra­mo­wa­ny wysy­ła do Syreny sygna­ły Start i Stop zgod­nie z usta­wio­nym (zapro­gra­mo­wa­nym) cza­sem (har­mo­no­gra­mem).

Generator sygna­łu cza­su ma wyśru­bo­wa­ne wyma­ga­nia, więc jego wyko­na­nie będzie raczej kosztowne.

Wersja dru­ga

Jak widać pro­gra­mo­wa­nia dużo, koszt cało­ści poten­cjal­nie wyso­ki, więc kom­bi­nu­je­my dalej. Czy aby na pew­no wszyst­ko trze­ba robić same­mu? Pierwsza rzecz po wstęp­nym pro­jek­cie to upew­nie­nie się, czy nie ma cze­goś goto­we­go na ryn­ku. Jak nie trud­no (chy­ba) się domy­śleć, zegar­ków na ryn­ku dosta­tek, więc chy­ba nie trze­ba go na nowo odkry­wać. Mamy coś takie­go jak COTS ([[Commercial off the shelf]]) czy­li ogól­nie dostęp­ne na ryn­ku kom­po­nen­ty lub usłu­gi. No to zmia­na projektu:

Zegarek mam goto­wy, kupu­je­my Zegar lub, tu, uży­je­my wzor­co­we­go sygna­łu cza­su, np. takie­go jakie­go uży­wa typo­wa domo­wa pogo­dyn­ka z radio­wo ste­ro­wa­nym zega­rem (to dar­mo­wa usłu­ga). Teraz nasz dia­gram UC wyglą­da tak:

Tu akto­rem abso­lut­nie nie jest Czas, akto­rem jest inny sys­tem, tu źró­dło sygna­łu cza­su. Diagram UC jest zgod­ny ze stan­dar­dem a my zro­zu­mie­li­śmy isto­tę rze­czy”. Stosowanie w ana­li­zie stan­dar­dów pro­wa­dzi do rozu­mie­nia i ma taką wła­śnie zale­tę: ana­li­za i mode­lo­wa­nie pro­wa­dzi do zro­zu­mie­nia pro­ble­mu, łama­nie zasad nota­cji ukry­wa nie­zro­zu­mie­nie pro­ble­mu (o co cho­dzi z tym ocze­ki­wa­nym przez klien­ta czasem).

Wprowadziłem dwa ste­reo­ty­py: czło­wieksys­tem, cel chy­ba jest oczy­wi­sty (czło­wiek ma ekra­ny GUI, sys­tem jakiś inter­fejs” wymia­ny danych).

Rolą ana­li­ty­ka biz­ne­so­we­go jest zro­zu­mie­nie celu zama­wia­ją­ce­go ale też opra­co­wa­nie naj­ko­rzyst­niej­sze­go roz­wią­za­nia. Nie jest to wyrę­cza­nie pro­gra­mi­stów, a ana­li­za i pro­jek­to­wa­nie. Programiści (dostaw­ca opro­gra­mo­wa­nia) imple­men­tu­ją, roz­wią­zu­ją pro­ble­my techniczne.

Tak więc jedy­nym tak na praw­dę ele­men­tem (kom­po­nen­tem) wyma­ga­ją­cym szcze­gó­ło­we­go opra­co­wa­nia i imple­men­ta­cji jest Programator, war­to było pochy­lić się nad ana­li­zą i pro­jek­to­wa­niem, testy pomy­słu wyko­nać na mode­lach… bo taniej.

Pokazałem przy oka­zji tak zwa­ne zstę­pu­ją­ce podej­ście do ana­li­zy i pro­jek­to­wa­nia: od ogó­łu do szcze­gó­łu. Zanim zacznie­my pro­jek­to­wać model dzie­dzi­ny sys­te­mu war­to ogra­ni­czyć zakres pro­jek­tu do nie­zbęd­ne­go mini­mum (naro­bić to się każ­dy potra­fi .)). W sty­lu opar­tym na [[Domain Driven Design]] (DDD) nazy­wa się „[[core doma­in]]” i „[[boun­ded con­text]]” (o DDD innym razem).

Zapytany zosta­łem tak­że o testy akcen­ta­cyj­ne. Proste: nasta­wiam jakąś godzi­nę i czas wycia” i cze­kam :), żeby dłu­go nie cze­kać nasta­wiam taką by cze­kać kil­ka minut a nie godzin … upły­wu cza­su się nie testu­je (ten pły­nie i bez nas) , testu­je­my pro­gra­ma­tor… Owszem moż­na się umó­wić, że testu­je­my sygna­ły Start Stop inter­fej­su a nie syre­nę (będzie ciszej).

Podsumowanie

Jak widać trosz­kę się, mam nadzie­ję, upo­rząd­ko­wa­ło i mamy nastę­pu­ją­ce wnioski:

  1. czas nie jest żad­nym akto­rem, akto­rem jest bene­fi­cjent sys­te­mu, ktoś kto z nie­go korzy­sta lub z nim współ­pra­cu­je, para­me­try takie jak godzi­na alar­mu i czas jego trwa­nia, to nie aktor czas, a treść danych wpro­wa­dza­nych do sys­te­mu (np. for­mu­larz kon­fi­gu­ra­cji alarmu),
  2. opra­co­wa­nie samej spe­cy­fi­ka­cji wyma­gań funk­cjo­nal­nych abso­lut­nie nie deter­mi­nu­je pro­jek­tu, czy­li tego co nam pro­gra­mi­ści dostar­czą (a może to być kosz­tow­ne lub nie, ale to wyni­ka z pro­jek­tu a nie dia­gra­mu UC),
  3. jedy­nym spo­so­bem dokład­ne­go posta­wie­nia zada­nia pro­gra­mi­stom (deve­lo­pe­ro­wi) jest opra­co­wa­nie pro­jek­tu tego co ma powstać (jego logi­ki), jest to już nie spe­cy­fi­ka­cja wyma­gań funk­cjo­nal­nych a spe­cy­fi­ka­cja sys­te­mu (albo jak kto woli, wyma­ga­nie jest projektem),
  4. nie licz­cie na to, że dostaw­ca zawsze zro­bi wszyst­ko by to kosz­to­wa­ło jak naj­mniej… (patrz dru­ga wer­sja pro­jek­tu, jest tań­szy w wyko­na­niu – ryzyko),
  5. jeże­li ktoś umiesz­cza na dia­gra­mie UC akto­ra Czas, to naj­praw­do­po­dob­niej nie rozu­mie imple­men­ta­cji albo ukry­wa ją, lub odkła­da imple­men­ta­cję, to zna­czy, że odsu­wa jed­ną z naj­waż­niej­szych decy­zji pro­jek­to­wych (kosz­ty!) na później,
  6. zale­tą takie­go pro­jek­to­wa­nia (obiek­to­we ukie­run­ko­wa­ne na kom­po­nen­ty) jest moż­li­wość szyb­kie­go osią­ga­nia celu rela­tyw­nie niskim kosz­tem, w tym pro­jek­cie tak na praw­dę do napi­sa­nia jest sam pro­gra­ma­tor, resz­tę jako COTS kupu­je­my: goto­wą syre­nę, sygnał cza­su wyko­rzy­stu­je­my cudzy” (w tym przy­pad­ku to przy oka­zji kla­sycz­ny clo­ud computing).

Tak więc war­to na eta­pie ana­li­zy biz­ne­so­wej wyko­nać nie ste­no­gram z życzeń zama­wia­ją­ce­go (potra­fi sobie nawet sam zro­bić krzyw­dę) i nagi­nać zasa­dy (czas to nie aktor!), ale wyko­nać pro­jekt logi­ki sys­te­mu by zro­zu­mieć pro­blem do roz­wią­za­nia i spraw­dzić jak go roz­wią­zać naj­efek­tyw­niej. Wybór wyko­naw­cy powi­nien być ostat­nim krokiem.

Poniżej ana­li­za (dia­gram poka­zu­ją­cy powyż­sze niu­an­se ana­li­zy i mode­lo­wa­nia czy­li zro­zu­mie­nia co tak na praw­dę jest isto­ta problemu):

Wyobraźmy się, że wie­lu poten­cjal­nych deve­lo­pe­rów dosta­ło wyma­ga­nie: dostar­czyć pro­gra­mo­wa­na syre­nę (lub pierw­szy dia­gram UC) jako zapy­ta­nie ofer­to­we, jaki będzie roz­rzut ofert?

Do zama­wia­ją­cych opro­gra­mo­wa­nie: oddzie­laj­cie ana­li­zę i pro­jek­to­wa­nie od wyko­na­nia :), to ma same zale­ty. Zastanów się teraz Czytelniku, jakie roz­wią­za­nie zapro­po­nu­je więk­szość firm programistycznych…

Na koniec pyta­nie z gatun­ku iro­nii: jak na tym tle wyglą­da­ją zwin­ne meto­dy­ki wytwa­rza­nia oprogramowania?

P.S.

Polecam dia­gram przy­pad­ków uży­cia z innej stro­ny: Udziałowcy pro­jek­tu czy­li któ­ry dia­gram UML …,

oraz ten sam pro­blem, opi­sa­ny z innej per­spek­ty­wy na stro­nach IBM.