Jestem gorą­cym fanem blo­gów dobrych (tak sądzę, że są ;)) pro­gra­mi­stów. Dlaczego? Bo to oni się męczą z moimi pro­jek­ta­mi. O czym powi­nien pamię­tać dobry ana­li­tyk pro­jek­tant? O dwóch rze­czach (zresz­tą o tym powi­nie pamię­tać każ­dy): po pierw­sze nie zapo­mi­naj kim jest Twój klient – mów do nie­go jego języ­kiem, po dru­gie jak coś two­rzysz dla swo­je­go klien­ta to nie po to by on musiał to jesz­cze raz po Tobie zro­bić po swojemu.

Analitycy jako zasoby

W pro­jek­tach infor­ma­tycz­nych naj­czę­ściej spo­ty­ka­my: ana­li­ty­ka wyma­gań (AW), ana­li­ty­ka sys­te­mo­we­go (AS), dewe­lo­pe­ra w tym archi­tek­ta sys­te­mu (D). W zasa­dzie trud­no powie­dzieć co jest pro­duk­tem dwóch pierw­szych bo Deweloper odda­je dzia­ła­ją­ce opro­gra­mo­wa­nie. Najczęściej AW dostar­cza jakiś opis tego cze­go ocze­ku­je klient, AS porząd­ku­je to co zro­bił AW np. z pomo­cą przy­pad­ków uży­cia a D bie­rze to do ręki i musi zapro­jek­to­wać i wyko­nać opro­gra­mo­wa­nie. Jak widać, odpo­wie­dzial­ność za to co powsta­nie jest roz­my­ta. Klient naj­pierw prze­ka­zu­je swo­je ocze­ki­wa­nia AW zaś otrzy­mu­je pro­dukt od D. Konia z rzę­dem temu, kto mi powie jak tego doko­nać bez per­ma­nent­nych ite­ra­cyj­nych wyja­śnień i bom­bar­do­wa­nia Klienta pyta­nia w rodza­ju co Państwo mie­li na myśli pisząc/mówiąc, że …”.

Od koń­ca. By powsta­ło opro­gra­mo­wa­nie (zakła­dam na dziś, że meto­da­mi obiek­to­wy­mi) musi powstać jego spe­cy­fi­ka­cja, pro­jekt któ­ry dokład­nie opi­su­je co mają zako­do­wać pro­gra­mi­ści. Bez tego nie wia­do­mo ani co ma powstać ani ile to wyma­ga pra­cy. Aby powsta­ła spe­cy­fi­ka­cja musi powstać opis logi­ki sys­te­mu bo tego wła­śnie ocze­ku­je Klient. Aby ta logi­ka powsta­ła trze­ba dokład­nie zro­zu­mieć to cze­go klient ocze­ku­je, jako że ocze­ku­je narzę­dzia wspo­ma­ga­ją­ce­go zarzą­dza­nie jego fir­mą, nale­ży tę fir­mę dokład­nie opi­sac a wcze­śniej zrozumieć.

W czym pro­blem? Mając trzy role w pro­jek­cie: AW, AS i D powsta­je zaba­wa w głu­chy tele­fon, któ­ra koń­czy się tym, że kon­tak­tu­ją się z Klientem wszy­scy bo opis słow­ny wyma­gań z regu­ły jest nie­pre­cy­zyj­ny i nie­kom­plet­ny. AS na bazie tego opi­su coś pro­jek­tu­je, D two­rzy pierw­szą wer­sje sys­te­mu. Klient to dosta­je i zgła­sza uwa­gi i ocze­ki­wa­nia, bo to tak na praw­dę jego pierw­szy kon­takt z pro­duk­tem. Proces ten zna każ­dy kto brał udział w takim pro­jek­cie (pozo­sta­łych prze­strze­gam przez takim podejściem).

Powyżej opi­sa­ny bieg wyda­rzeń to zaso­bo­we (silo­so­we) podej­ście do pro­jek­tu: jak użyć ludzi o posia­da­nych kompetencjach.

Analityk i deweloper jako właściciele procesów

Jak nale­ża­ło się spo­dzie­wać, musia­ło to dopro­wa­dzić do szu­ka­nia roz­wią­za­nia. Podobnie jak w zarzą­dza­niu w innych obsza­rach, zaczy­na­my mówić o pro­ce­sie wytwa­rza­nia opro­gra­mo­wa­nia”. A sko­ro mowa o pro­ce­sie to powin­ny się poja­wić pro­duk­ty poszcze­gól­nych pod-pro­ce­sów, ich wyko­naw­cy są wtór­ni wobec pro­duk­tów. Najpierw defi­niu­je­my pro­dukt potem wska­zu­je­my odpowiedzialnego.

W pro­ce­sie wytwa­rza­nia opro­gra­mo­wa­nia potrzeb­ne sa trzy produkty:

  1. opis celu biz­ne­so­we­go i stra­te­gii jego osią­gnię­cia, jed­nym z narzę­dzie zapew­ne będzie jakieś oprogramowanie,
  2. pro­jekt opro­gra­mo­wa­nia, nale­ży je zaprojektować,
  3. wyko­na­ne (dostar­czo­ne) oprogramowanie.

Mamy więc trzy ocze­ki­wa­ne pro­duk­ty czy­li trzy pro­ce­sy: ana­li­za biz­ne­so­wa, pro­jek­to­wa­nie, wyko­na­nie (imple­men­ta­cja). Projekt jest ści­śle powią­za­ny z ana­li­zą biz­ne­so­wa, gdyż powsta­je na bazie niej i jej peł­ne­go zro­zu­mie­nia, nasu­wa to wnio­sek, że jed­na oso­ba powin­na odpo­wia­dać za pro­jekt i dobrze jest jeśli będzie to autor ana­li­zy biz­ne­so­wej. Jakie roz­wią­za­nie jest więc skuteczne?

Tym roz­wią­za­niem wyda­ja się być:

  1. meto­dy obiek­to­we ana­li­zy, pro­jek­to­wa­nia i implementacji,
  2. podział pro­ce­su na dwa eta­py i dwie role: opra­co­wa­nie pro­jek­tu logi­ki sys­te­mu i implementacja,
  3. [[wzo­rzec pro­jek­to­wy MVC]] i [[pro­jek­to­wa­nie meto­dą DDD]].

W dużym uproszczeniu:

  1. meto­dy obiek­to­we pozwa­la­ją na uży­wa­nie od same­go począt­ku tego same­go spo­so­bu opi­su (mode­lo­wa­nia) roz­wią­za­nia, któ­re powsta­je w mia­rę postę­pów ana­li­zy, zapis tego cze­go ocze­ku­je Klient to Przypadki Użycia (czar­na skrzyn­ka) oraz Model Dziedziny (pro­jekt – bia­ła skrzynka),
  2. do two­rze­nia opro­gra­mo­wa­nia uży­wa się obec­nie naj­czę­ściej fra­me­wor­ków bazu­ją­cych na [[wzor­cu MVC]] dla któ­re­go [[Model Dziedziny]] zapro­jek­to­wa­ny zgod­nie z DDD, jest goto­wym pro­jek­tem logi­ki kom­po­nen­tu Model z MVC zaś Przypadki Użycia to wyma­ga­nia na inter­fejs użyt­kow­ni­ka opi­sa­ny jak V w MVC (kom­po­nent C – kon­tro­ler – odpo­wia­da za ste­ro­wa­nie apli­ka­cją i reali­za­cję wyma­gań poza-funkcjonalnych).

Można wiec powie­dzieć, że kie­ru­nek jest taki:

Tak więc z trzech, nie­ja­sno okre­ślo­nych ról two­rzą sie dwie:

  1. Analityk Biznesowy, któ­re­go rolą jest dostar­czyć wyma­ga­nia funk­cjo­nal­ne (przy­pad­ki uży­cia wraz z ogra­ni­cze­nia­mi) oraz Model Dziedziny,
  2. Deweloper, któ­re­go rolą jest dostar­cze­nie opro­gra­mo­wa­nia imple­men­tu­ją­ce­go tak okre­ślo­ne Wymagania, Developer ma” Architekta Systemu czy­li pro­jek­tan­ta implementacji.

Jest to pro­mo­wa­ny” przez [[IIBA w BABoK]] pro­ces i zakres kompetencji.

Teraz kolej na dono­sy z inne­go blo­ga, jest to blog programisty:

Jeff Bay pro­po­nu­je w nim 9 reguł doty­czą­cych two­rze­nia kodu (przy­kła­dy są w javie, ale więk­szość reguł odno­sić się może do w mia­rę dowol­ne­go języ­ka, szcze­gól­nie OO). Są to:

  • Tylko jeden poziom zagłę­bie­nia na metodę
  • Nie uży­waj sło­wa klu­czo­we­go else
  • Opakowuj wszyst­kie pry­mi­ty­wy i Stringi (w kla­sy o spe­cy­ficz­nej dla zasto­so­wa­nia nazwie)
  • Używaj tyl­ko jed­nej krop­ki na linię
  • Nie skra­caj nazw
  • Pilnuj wszyst­kie encje by były małe
  • Nie uży­waj klas o wię­cej niż dwóch polach
  • Klasa któ­rej polem jest kolek­cja nie powin­na mieć żad­nych innych pól (opa­ko­wy­wa­nie kolek­cji w kla­sy spe­cy­ficz­ne dla kon­tek­stu wykorzystania)
  • Nie uży­waj getterów/setterów/własności

(źr. Sprawna Inżynieria Oprogramowania: Ekstremalna obiektowość.)

Jeżeli uznać, że to wyma­ga­nia w ogó­le na pro­jekt obiek­to­wy to są to wyma­ga­nia dla mnie: Analityka Biznesowego, na to jak ma wyglą­dać Model Dziedziny Systemu.

Po co to wszyst­ko? Bo tu nie ma głu­che­go tele­fo­nu, pro­dukt powsta­je w pierw­szej ite­ra­cji i każ­dy dokład­nie wie za co odpo­wia­da. Całość trwa kró­cej i jest mniej kosztowna.

P.S.

A tym jak taki pro­dukt, Wymagania, powsta­je pisa­łem już wcze­śniej, o tym jak się to imple­men­tu­je niech piszą programiści 🙂

P.S. 2

Polecam tak­że inne cie­ka­we spoj­rze­nie na ten pro­blem w arty­ku­le Analityk sys­te­mo­wy – łącz­nik dwóch świa­tów. Tu fak­tycz­nie sta­je się pro­ble­ma­tycz­ne stwier­dze­nie kim jest, a kim nie, ana­li­tyk sys­te­mo­wy. Być może Analityk Systemowy jest wła­ściw­szym ter­mi­nem, jed­nak ja boje się tego, że powszech­nie koja­rzo­ne z infor­ma­ty­ką poję­cie sys­tem” zabu­rza tak poj­mo­wa­ne zna­cze­nie ana­li­zy sys­te­mo­wej”, któ­ra nie koniecz­nie doty­czy sys­te­mów IT. Modelowanie biz­ne­su (firm, orga­ni­za­cji) meto­da­mi zna­ny­mi z ana­li­zy sys­te­mo­wej ([[ogól­na teo­ria sys­te­mów]]) jest chy­ba jed­nak ana­li­zą biz­ne­so­wą (tego biz­ne­su), ale mogę się mylić…

Jarosław Żeliński

BIO: Od roku 1991 roku, nieprzerwanie, realizuję projekty z zakresu analiz i projektowania systemów, dla urzędów, firm i organizacji. Od 1998 roku prowadzę także samodzielne studia i prace badawcze z obszaru analizy systemowej i modelowania (modele jako przedmiot badań: ORCID). Od 2005 roku, jako nieetatowy wykładowca akademicki, prowadzę wykłady i laboratoria (ontologie i modelowanie systemów informacyjnych, aktualnie w Wyższej Szkole Informatyki Stosowanej i Zarządzania pod auspicjami Polskiej Akademii Nauk w Warszawie. Oświadczenia: moje badania i publikacje nie mają finansowania z zewnątrz, jako ich autor deklaruję brak konfliktu interesów.

Ten post ma 17 komentarzy

  1. Matthias

    O ile z nie­któ­ry­mi regu­ła­mi z tych 9‑ciu mogę się zgo­dzić o tyle nie­któ­re z nich są kom­plet­nie bez sen­su. Dla przy­kła­du tyl­ko jeden poziom zagłę­bie­nia na metode.
    nie­któ­re zna­ne algo­ryt­my wyma­ga­ją 2- lub 3‑krotnego zagłę­bie­nia” i roz­bi­ja­nie ich na wie­le metod nie ma za bar­dzo sensu.
    To samo tyczy się obiek­tów dome­no­wych z kolek­cja­mi. OK, więc mena­dżer ma wska­znie do obiek­tu trzy­ma­ją­ce­go listę pod­wład­nych… i cała ta zaba­wa w jed­ną krop­kę idzie wkibidibatri 😀

    1. Jarek Żeliński

      Trudno mi oce­niać szcze­gól­nie te doty­ka­ją­ce imple­men­ta­cji ale, hm.. nie­któ­re zale­ce­nia fak­tycz­nie są nie­co hard­co­ro­we. Ale z mojej strony:
      – zagłę­bia­nie metod poza mną bo ich nie implementuję,
      – else tak­że poza mną,
      – pry­mi­ty­wy poza mną,
      – krop­ka także,
      – za skra­ca­nie nazw potra­fię zabić
      – małe encje, owszem jestem za
      – z tym jed­nym polem jako kolek­cją to skła­niam się ku temu tak­że, kolek­cja sama z sie­bie jest waż­nym kawał­kiem” i fak­tycz­nie odpo­wie­dzial­ność za zarzą­dza­nie kolek­cją powin­na być wystar­cza­ją­cym zada­niem dla kla­sy, ja to nazy­wam jed­na kuwet­ka słu­ży do trzy­ma­nia tyl­ko jed­ne­go typu papierków,
      – getterów/setterów tak­że nie lubię,
      Hm… tyle w kwe­stii gło­su pro­jek­tan­ta… któ­ry nie implementuje 🙂

  2. Ja jako deve­lo­per, pro­jek­tant czy archi­tekt apli­ka­cji mam nie­co inne spoj­rze­nie na rolę MVC i DDD.
    MVC trak­tu­ję jako czy­sto tech­nicz­ny wzo­rzec archi­tek­tur apli­ka­cji. Widoki, owszem wyni­ka­ją z wyma­gań (a ich sekwen­cja ze sce­na­riu­szy), ale pozo­sta­łe kom­po­nen­ty (C i C) są czy­sto tech­nicz­ne. Kontroler jest moc­no zwią­za­ny z tech­no­lo­gią pre­zen­ta­cji i nie umiesz­czał bym w nim logi­ki apli­ka­cji poza wysy­ła­niem sygna­łów do mode­lu i ew. wybie­ra­niem nowe­go wido­ku (ale to może zale­żeć od logi­ki biz­ne­so­wej). Model w tym wzor­cu ma rów­nież uję­cie bar­dzo tech­nicz­ne – to co pobie­ra­my z ser­we­ra (Encje, DTO) i to do cze­go dele­gu­je­my pra­cę (servi­sy apliakcyjne).

    Natomiast to w samym DDD widzę wszyst­kie istot­ne z pun­tu widze­nia ana­li­zy odpo­wie­dzial­no­ści, o któ­rych piszesz przy oka­zji MVC i DDD. Bo DDD to dwie war­stwy: Logika Domenowa i Logika Aplikacji. Logika Domenowa to nasz model biz­ne­su zbu­do­wa­ny przy pomo­cy stan­dar­do­wych Building Blcoków (same Encje nie wysa­tr­czą, dla­te­go BB jest ok 7). Natomiast Logika Aplikacji, któ­ra jest ponad Logiką Domenową może mode­lo­wać: Use Casy (orkie­stru­je obiek­ta­mi dome­no­wy­mi) oraz jest odpo­wie­dzial­na za wspo­mnia­ne wyma­ga­nia poza-funkcjonalne.

    Sklejając to razem: z punk­tu widze­nia MVC, mode­lem jest war­stwa Logiki Aplikacji DDD – czy­li ser­wi­sy apli­ka­cyj­ne i to co ich apli nale­ży, czy­li jakieś obiek­ty trans­fe­ro­we (chy­ba, że w pro­stych przy­pad­kach poka­zu­je­my model biz­ne­so­wy wyżej i nie uży­wa­my obiek­tów transferowych).

    Tak więc może­my dowol­nie zmie­niać tech­no­lo­gię war­stwy pre­zen­ta­cji (czy­li kon­tro­le­ry i wido­ku). Zatem jest ona pomi­jal­na w ana­li­zie. Jeżeli Use casy są mode­lo­wa­ne przez servi­sy Logiki Aplikcjai to klien­tem do tych servi­sów może być nawet apli­ka­cja kon­so­lo­wa (i o to zresz­tą cho­dzi w testo­wa­niu beha­wio­ral­nym zacho­wa­nia mode­lu biznesowego).

    Technicznie moż­na podejść też ina­czej do pro­jek­to­wa­nia API Warstwy Logiki Aplikacji – Commandy i Qwereny z archi­tek­tu­ry CqRS. Ale to tyl­ko inne uję­cie API od stro­ny tech­nicz­nej – z punk­tu widze­nia ana­li­zy nie­wie­le się zmienia.

    Natomiast co do ról w pro­jek­cie to ide­al­nie było­by aby te role były gra­ne przez jed­ną oso­bę (gru­pę osób, gdzie każ­da ma wszyst­kie role). Wówczas nie zaj­dzie nam zja­wi­sko głu­che­go tele­fo­nu – chy­ba, że ktoś to roz­sz­cze­pie­nie jaźni;)

    Czy deve­lo­per może roz­ma­wiać wprost z klien­tem? To zale­ży który:)
    W DDD mówi się gło­śno o róż­nych skil­l­se­tach jakie mają deve­lo­pe­rzy. W mode­lo­wa­niu DDD pre­fe­ro­wa­na jest inte­li­gen­cja wer­bal­na nad inte­li­gen­cją algo­ryt­micz­ną – cho­dzi tutaj o jasne, kla­row­ne i ele­ganc­kie wyra­ża­nie mode­lu (nie oszu­ku­je­my się, w biz­ne­sie nie wystę­pu­ją zbyt czę­sto na praw­dę trud­ne algorytmy).

    1. Jarek Żeliński

      Po pierw­sze mogę tyl­ko potwier­dzić, że algo­ryt­my w biz­ne­sie do skom­pli­ko­wa­nych nie nale­żą:). W kwe­stii logi­ki apli­ka­cji, oso­bi­ście skła­niam się ku nie eks­po­no­wa­niu encji” jako cze­goś spe­cjal­ne­go w Modelu. Klasa będą­ca Fakturą i kla­sa WystawiaczFaktur, ją two­rzą­ca z: Produktów, Kontrahenta, Składników podat­ko­wych itp. (np. wzo­rzec Fabryka lub Prototyp) to dwie rów­no­praw­ne kla­sy. Potrzebna jest trze­cia kla­sa: SzafaNaFaktury. Przypadek uży­cia Wystaw Fakturę” wywo­ła meto­dę nowa_faktura, któ­ra utwo­rzy nowy agre­gat FakturaVAT, ten ma meto­dy pozwa­la­jąc ją wypeł­nić. Na koniec WystawiaczFaktur wrzu­ci FakturęVAT do SzafyNaFaktury (tu wzo­rzec repo­zy­to­rium). Całość mie­ści się w Modelu z MVC, to zaś moż­na umie­ścić w dowol­nym fra­me­wor­ku. Tak to postrze­gam. Analityk Biznesowy w zasa­dzie powi­nien stwo­rzyć Model jak wyżej, dla pew­no­ści dla każ­de­go przy­pad­ku uży­cia opra­co­wać sce­na­riusz (dia­gram sekwen­cji) by zwe­ry­fi­ko­wać popraw­ność Modelu: kom­plet­ność klas w mode­lu i ich odpo­wie­dzial­no­ści, kom­plet­ność ich atry­bu­tów i metod. To tak w tele­gra­ficz­nym skró­cie moje postrze­ga­nie pro­ble­mu”. Taki pro­dukt” ana­liz i pro­jek­to­wa­nia wyma­ga już tyl­ko implementacji…

  3. Przeczytałem kil­ka postów z prze­ło­mu 2010/2011 i teraz rozu­miem, że mam w gło­wie inną pro­jek­cję opi­sy­wa­nych ról oraz nie­co inną pro­jek­cję MVC. Co w rezul­ta­cie powo­du­je, że mój poprzed­ni komen­tarz jest w sumie tyl­ko nie­po­trzeb­nym szu­mem w sieci:)

    1. Jarek Żeliński

      Eeee bez prze­sa­dy :), te role w zasa­dzie nie są nigdzie ści­śle z defi­nio­wa­ne stąd moje pró­by. Powyższe są opar­te na pro­duk­tach i pro­ce­sie a nie na kom­pe­ten­cjach, któ­re tu są wtórne.

  4. Jarek Pałka

    Wszystko by było faj­nie, gdy­by autor nie popeł­nił pod­sta­wo­wych błe­dów i nie wyka­zał się zbyt ogól­nym spoj­rze­niem na pro­blem. Cytat „(kom­po­nent C ? kon­tro­ler ? odpo­wia­da za ste­ro­wa­nie apli­ka­cją i reali­za­cję wyma­gań poza-funk­cjo­nal­nych).” Z tego co pamię­tam C w MVC zaj­mu­je się wła­snie tzw. logi­ka biz­ne­so­wa a nie reali­za­cja wyma­gań poza-funkcjonalnych.
    Nie zga­dzam się też z By powsta­ło opro­gra­mo­wa­nie (zakła­dam na dziś, że meto­da­mi obiek­to­wy­mi) musi powstać jego spe­cy­fi­ka­cja, pro­jekt któ­ry dokład­nie opi­su­je co mają zako­do­wać pro­gra­mi­ści”. Sprowadza to pro­gra­mi­stów do roli inte­li­gen­tych maszyn do pisa­nia”. Problem w tym ze takie podej­scia tre­no­wa­no od kil­ku­na­stu lat, pro­bu­jac pozbyc sie inte­li­gen­tych i dro­gich maszyn do pisa­nia, patrz MDA. Zakonczylo sie to kil­ko­ma lad­ny­mi kle­ska­mi, w kto­rych wie­lu z nas bra­lo udzial. Sprowadzajac role pro­gra­mi­stow do tych co to dokład­nie prze­pi­su­ja to co stwo­rzy­li pro­jek­tan­ci” two­rzy­my kolej­ny uklad my analitycy/architekci” kon­tra wy pro­gra­mi­sci”. Uwazam taki podzial rol za kom­plet­na bzdu­re. Sam piszesz Mając trzy role w pro­jek­cie: AW, AS i D powsta­je zaba­wa w głu­chy tele­fon, któ­ra koń­czy się tym, że kon­tak­tu­ją się z Klientem wszy­scy bo opis słow­ny wyma­gań z regu­ły jest nie­pre­cy­zyj­ny i nie­kom­plet­ny.” Skoro te role i taki podzial rol powo­du­je tyle pro­ble­mow to jaki jest sens ich ist­nie­nia i utrzy­my­wa­nia? Przytocze tu jed­na z zasad meto­do­lo­gii Lean, Eliminate waste”. Dla mnie jesli cos wpro­wa­dza tyl­ko zamie­sza­nie, i pro­ble­mu komu­ni­ka­cyj­ne a na kon­cu i tak pro­gra­mi­sta musi poga­dac z klien­tem, to pro­sty sygnal ze te role w pro­jek­cie to tzw. waste” wiec czas sie ich pozbyc. Problem z tym zwia­za­ny jest jesz­cze taki ze te role w pro­jek­cie sa cze­sto w fir­mach prze­ku­wa­ne na sta­no­wi­ska, i tu sie zaczy­na kla­sycz­ne jestem ana­li­ty­kiem to juz nie moj pro­blem, jestem archi­tek­tem ja sie tym nie zaj­mu­je”. Jesli nie jeste­smy cze­gos w sta­nie zde­fi­no­wac, lub zde­fi­nio­wa­ne role wpro­wa­dza­ja kolej­ny narzut w pro­ce­sie to czy­sty sygnal ze nale­zy sie tego pozbyc. Oczywiscie to wszyst­ko w kon­tek­scie ska­li i kla­sy pro­ble­mu (pozdro­wie­nia dla Sławka). 80% pro­cent pro­jek­tów nie jest tak zlo­zo­nych, wiel­kich i prze­ro­snie­tych aby potrze­bo­wac takie­go jasne­go podzia­lu i wydzie­le­nia rol.

    1. Jarek Żeliński

      Przyznaje się do pew­nych uprosz­czeń, bez tego ten arty­kuł to mate­riał na książ­kę. Niewątpliwie bro­nię tezy, że potrzeb­ny jest podział na eta­py pro­jek­to­wa­nie i imple­men­ta­cja, wyzna­cze­nie odpo­wie­dzial­no­ści za etap. Ktoś powi­nien naj­pierw zamknąć temat” czym jest fak­tu­ra i jak się ją wysta­wia a dopie­ro potem pozwo­lić na imple­men­ta­cję wysta­wia­nie fak­tu­ry”. Zabawa w fak­tu­rę meto­dą: może kolej­ny pro­to­typ tego co zro­zu­miał pro­gra­mi­sta” się spodo­ba klien­to­wi, to wła­śnie dro­ga doni­kąd. Bez tego mamy strasz­nie roz­my­tą odpo­wie­dzial­ność, nie da się wszyst­kie­go zała­twić burzą mózgów. 

      Napisałem sam, że trzy roz­my­te role AW, AS i D nie słu­żą pro­jek­to­wi i zamie­niam je na dwie AB i D (czy to lean?). Zresztą nie ja a są to zale­ce­nia IIBA ).

      Daleki jestem od zamia­ny pro­gra­mi­sty w maszy­nę do pisa­nia. Problemów tech­nicz­nych do roz­wią­za­nia pod­czas imple­men­ta­cji nie bra­ku­je, ale będę bro­nił tezy, że nie jest rolą pro­gra­mi­sty udział w dys­ku­sji o tym jak poli­czyć poda­tek VAT na fak­tu­rze. Tu pro­gra­mi­sta nie ma nic do gada­nia bo to nie jego kom­pe­ten­cje i nie ten etap projektu. 

      Owe 80% Sławka jest tak­że waż­ną infor­ma­cją, ja piszę (tego fak­tycz­nie nie wska­za­łem) o pro­jek­tach biz­ne­so­wych, któ­re być może są nud­ne dla pro­gra­mi­sty ale to chy­ba więk­szość pro­jek­tów na rynku. 

      Tu mamy namiast­kę tego o czym piszę:
      http://​www​.gol​den​li​ne​.pl/​f​o​r​u​m​/​2​3​5​8​5​7​2​/​p​o​w​i​a​z​a​n​i​a​-​d​w​u​s​t​r​o​n​n​e​/​s​/​1​#​4​2​9​4​2​611

    2. Matthias

      O M Goooosh!!!!!!!!!!!!!! Wiem, że ja jestem cięż­ki w oby­ciu ale jak mnie ktoś katu­je taki­mi obraz­ka­mi to sie w sobie zamykam…
      Wiecie co? Dajmy tym archi­tek­tom ryso­wać te ich dia­gra­my, ludzi­ki, kre­ski, przej­ścia i wogo­le cały ten ich jueme­lo­wy staf.. prze­cież każ­dy ma swo­je zabaw­ki i nie ład­nie jest się śmiać z tego, że kole­ga ma je gor­sze lub inne lub mniej tren­di. Wszystko to pod jed­nym warun­kiem, że nie beda poka­zy­wać tego pro­gra­mi­stom tyl­ko sie zbio­rą w sobie, zapną pas i udźwi­gną cię­żar pisa­nia sto­ry­jek. Bo takie wyma­ga­nia jak to co kole­ga Jarosław poka­zał w poście, któ­re­go tutaj przy­to­czył to jest wszyst­ko tyl­ko nie coś na pod­sta­wie cze­go moż­na pisać oprogramowanie.
      Generować być może ale nie pisać.….

    3. Jarek Żeliński

      Przyjąłem do wia­do­mo­ści. Czego Ci w tym (te dia­gra­my) bra­ku­je do napi­sa­nia tego kawał­ka opro­gra­mo­wa­nia? Ale rozu­miem, że UML nie jest Ci obcy? Bo jeśli tak to fak­tycz­nie mar­nu­je­my bity…

    4. Matthias

      Oj Jarek P… prze­cież jak już się zosta­je Architektem to nie po to, żeby dziub­dziać w kodzie, nie? 😀 😀 😀

      Oczywiście jest to pure evil, że takie rze­czy się wyra­bia ale natu­ra ludz­ka tak już nami kie­ru­je, że czę­sto wpa­da­my w pułap­kę to nie moja dział­ka”. Niestety praw­da jest inna: moja, moja ci ona! bo jak nie to następ­ne co jest moje” to wina za to, że pro­jekt poszedł w maliny.

    5. Jarek Żeliński

      Absolutnie nie pole­mi­zu­ję ze zło­żo­no­ścią opro­gra­mo­wa­nia jako cało­ści ani z tym, że dla inży­nie­ra jest tam masa trud­nej i fascy­nu­ją­cej pra­cy. Jednak sys­te­my dla biz­ne­su to tak­że wyma­ga­nia funk­cjo­nal­ne, te zaś są obsłu­gi­wa­ne przez jed­ną tyl­ko z wie­lu, war­stwę sys­te­mu o nazwie logi­ka biz­ne­so­wa”. Ona (obiek­ty biz­ne­so­we i ich logi­ka) powin­na być dana jako wyma­ga­nie, goto­wy pro­dukt. W życiu, poza kil­ko­ma może wyjąt­ka­mi, nie widzia­łem dobre­go pro­gra­mi­sty, któ­ry był­by spe­cem od zarzą­dza­nia i mar­ke­tin­gu. Dlatego uwa­żam, że MVC/DDD to roz­wią­za­nie tego pro­ble­mu. Mogę wyma­ga­nia, zamiast beł­ko­tu pro­zą, oddać w posta­ci prze­te­sto­wa­nej, goto­wej do imple­men­ta­ci, war­stwy Modelu Dziedziny. Wymagania poza funk­cjo­nal­ne w rodza­ju czas odpo­wie­dzi, bez­a­wa­ryj­ność, pra­ca na wol­nych łączach, pouf­ność, 2000 jed­no­cze­snych użyt­kow­ni­ków itp. to pro­ble­my dla pro­gra­mi­sty inży­nie­ra… czyż nie?

  5. Jarek Pałka

    Zeby nie mar­no­wac bit’ow, pole­cam http://​www​.infoq​.com/​p​r​e​s​e​n​t​a​t​i​o​n​s​/​D​e​l​i​b​e​r​a​t​e​-​D​i​s​c​o​v​ery oraz http://​www​.sli​de​sha​re​.net/​T​h​o​u​g​h​t​W​o​r​k​s​/​n​e​a​l​-​f​o​r​d​-​e​m​e​r​g​e​n​t​-​d​e​s​i​g​n​-​a​n​d​-​e​v​o​l​u​t​i​o​n​a​r​y​-​a​r​c​h​i​t​e​c​t​ure.
    Co do więk­szo­ści pro­jek­tów IT na ryn­ku, zasto­su­ję pro­sta regu­łe, 20% pro­jek­tów na ryn­ku to 80% pro­cent wydat­ków na pro­jek­ty IT. Pozostałe 80% pro­jek­tów świet­nie sobie pora­dzi bez tych ról, lub wypeł­ni ta pust­kę w inny, bar­dziej opty­mal­ny i kre­atyw­ny sposob.

    1. Jarek Żeliński

      Bardzo cie­ka­we pre­zen­ta­cje, są o czymś czym się nie zaj­mu­je ana­li­tyk biz­ne­so­wy: nie ma tam sło­wa o tym jak zebrać i udo­ku­men­to­wać logi­kę biz­ne­so­wą… może dla­te­go, że to jed­nak nie jest pra­ca dla inży­nie­rów programistów…to powin­ni dostać, albo jak mawia­ją nie­któ­rzy: ktoś powi­nien posta­wić zada­nie pro­gra­mi­stom? Robi to klient, jed­nak ten potra­fi pisać po swo­je­mu” dla­te­go ktoś powi­nien posta­wić zada­nie pro­gra­mi­stom w ich języ­ku”: Analityk potra­fią­cy zapi­sać te biz­ne­so­we wyma­ga­nia tak, by był to zapis jed­no­znacz­ny i testo­wa­ny: np. UML.

    2. Piotr Tokarski

      by był to zapis jed­no­znacz­ny i testo­wa­ny: np. UML.”
      w jaki spo­sób prze­te­sto­wać model zapi­sa­ny np. w UML ?

Dodaj komentarz

Witryna wykorzystuje Akismet, aby ograniczyć spam. Dowiedz się więcej jak przetwarzane są dane komentarzy.