Ach ten wstrętny, wścibski analityk

Znowu o tym, tak: o ana­li­zie, pro­jek­to­wa­niu i … ryzy­ku. Czy ana­li­za jest koniecz­na? Nie! To cze­mu słu­ży? By praw­do­po­do­bień­stwo tego, że uda się stwo­rzyć i wdro­żyć wła­ści­we opro­gra­mo­wa­nie było jak naj­więk­sze. Ale o co cho­dzi? Ano nie zawsze jest tak, że to praw­do­po­do­bień­stwo jest wystar­cza­ją­co duże! Ale po kolei.

Wprowadzenie

Obecnie na ryn­ku coraz bar­dziej domi­nu­ją tak zwa­ne obiek­to­we meto­dy ana­li­zy, pro­jek­to­wa­nia i pro­gra­mo­wa­nia. W czym pro­blem? Jedyną nama­cal­ną rze­czą jest kod i od pro­gra­mo­wa­nia (kodo­wa­nia) nie ma uciecz­ki: kod musi powstać by powsta­ło opro­gra­mo­wa­nie. Pozostaje ana­li­za i pro­jek­to­wa­nie – to moż­na pomi­nąć, moż­na od razu kodo­wać nicze­go nie ana­li­zu­jąc ani nie projektując.

Myślenie zama­wia­ją­ce­go: Te dwa eta­py, ana­li­za i pro­jek­to­wa­nie, to dodat­ko­wy koszt: może da się go uniknąć.

Myślenie pro­gra­mi­sty: Istniejący pro­jekt to wią­za­nie mi rąk, mojej kre­atyw­no­ści i roz­wo­ju: może uda się od razu zacząć kodować.

Nie raz pro­gra­mi­sta, w sumie tak­że wyko­naw­ca, doda­je sobie powyż­sze myśle­nie klien­ta: unik­nę kosz­tu ana­li­zy i projektowania.

Obaj mają ten sam cel! Pominąć ana­li­zę i projektowanie! 

A teraz po kolei i od koń­ca. Posłużymy się defi­ni­cja­mi a potem je jakoś razem pokle­imy. Mimo, że pod­cho­dzę z dużą rezer­wą do WIKI, posłu­żę się tymi stro­na­mi, gdyż są w więk­szo­ści reda­go­wa­ne przez ludzi zwią­za­nych z infor­ma­ty­ką, nie raz wła­śnie przez pro­gra­mi­stów programistów.

Programowanie obiektowe

Na począ­tek definicja:

Programowanie obiek­to­we (ang. object-orien­ted pro­gram­ming) ? para­dyg­mat pro­gra­mo­wa­nia, w któ­rym pro­gra­my defi­niu­je się za pomo­cą obiek­tów ? ele­men­tów łączą­cych stan (czy­li dane, nazy­wa­ne naj­czę­ściej pola­mi) i zacho­wa­nie (czy­li pro­ce­du­ry, tu: meto­dy). Obiektowy pro­gram kom­pu­te­ro­wy wyra­żo­ny jest jako zbiór takich obiek­tów, komu­ni­ku­ją­cych się pomię­dzy sobą w celu wyko­ny­wa­nia zadań.

Podejście to róż­ni się od tra­dy­cyj­ne­go pro­gra­mo­wa­nia pro­ce­du­ral­ne­go, gdzie dane i pro­ce­du­ry nie są ze sobą bez­po­śred­nio zwią­za­ne. Programowanie obiek­to­we ma uła­twić pisa­nie, kon­ser­wa­cję i wie­lo­krot­ne uży­cie pro­gra­mów lub ich frag­men­tów. (źr. WIKI)

Jak widać, mamy nowe narzę­dzie dla pro­gra­mi­stów, kolej­na edy­cja struk­tu­ra­li­za­cji kodu. cza­sem spo­ty­kam się u pro­gra­mi­stów z defi­ni­cją: pro­gra­mo­wa­nie obiek­to­we to ukła­da­nie kodu w pod­pro­gra­my łączą­ce dane i ope­ra­cje na nich. Tak więc tyl­ko tech­no­lo­gia. Drugi aka­pit tyl­ko to pod­kre­śla: tu tyl­ko technologia.

Powstaje opro­gra­mo­wa­nie.

Projektowanie obiektowe

I tu problem:

Przepraszamy, ale nie ma jesz­cze arty­ku­łu ?Projektowanie obiek­to­we? w Wikipedii. (dziś jest 24 Maj 2011, zno­wu spraw­dzam i nadal nie ma a jest 07 luty 2019).

Nie ma takiej defi­ni­cji w pol­skim WIKI. Czyżby nasi” nie projektowali?

Object-orien­ted design is the pro­cess of plan­ning a sys­tem of inte­rac­ting objects for the pur­po­se of solving a softwa­re pro­blem. It is one appro­ach to softwa­re design. (źr, http://​en​.wiki​pe​dia​.org/​w​i​k​i​/​O​b​j​e​c​t​-​o​r​i​e​n​t​e​d​_​d​e​s​ign)

Uff, jed­nak pro­jek­tu­ją. Tak więc pro­jek­to­wa­nie obiek­to­we to zorien­to­wa­ny obiek­to­wo (para­dyg­mat obiek­to­wy) pro­ces roz­wią­zy­wa­nia pro­ble­mu poprzez pro­jek­to­wa­nie opro­gra­mo­wa­nia jako sys­te­mu komu­ni­ku­ją­cych się obiek­tów. Tak wiec moż­na przed roz­po­czę­ciem kodo­wa­nia, zapla­no­wać to co sta­nie zako­do­wa­ne. Gdzie indziej tak robią.

Powstaje pro­jekt opro­gra­mo­wa­nia (prze­my­śla­ny!).

[nie­ste­ty, wbrew temu co piszą pro­gra­mi­ści, para­dyg­mat obiek­to­wy to nie łącze­nie danych i funk­cji w obiek­ty, a budo­wa­nie sys­te­mu jako zesta­wu współ­pra­cu­ją­cych obiek­tów reagu­ją­cych w okre­ślo­ny spo­sób na okre­ślo­ne bodź­ce, obiek­ty są defi­nio­wa­ne wła­ści­wo­ścia­mi jaki­mi są ich atry­bu­ty i ope­ra­cje, cechu­ją się cał­ko­wi­tą her­me­ty­za­cją, czy­ni nie ujaw­nia­ją swo­ich wła­ści­wo­ści na zewnątrz.]

Analiza obiektowa

Kolejne podej­ście do Wikipedii:

Przepraszamy, ale nie ma jesz­cze arty­ku­łu ?Analiza obiek­to­wa? w Wikipedii. (dziś jest 24 Maj 2011, spraw­dzam 07 luty 2019, nadal nie ma)

Mam pecha, nasi nie ana­li­zu­ją. Znowu spo­glą­da­my na stro­ny anglo­sa­skich WIKI:

Object-orien­ted ana­ly­sis (OOA) looks at the pro­blem doma­in, with the aim of pro­du­cing a con­cep­tu­al model of the infor­ma­tion that exi­sts in the area being ana­ly­zed. Analysis models do not con­si­der any imple­men­ta­tion con­stra­ints that might exist, such as con­cur­ren­cy, distri­bu­tion, per­si­sten­ce, or how the sys­tem is to be built. Implementation con­stra­ints are dealt during object-orien­ted design (OOD). Analysis is done befo­re the Design. (źr. http://​en​.wiki​pe​dia​.org/​w​i​k​i​/​O​b​j​e​c​t​-​o​r​i​e​n​t​e​d​_​a​n​a​l​y​s​i​s​_​a​n​d​_​d​e​s​ign)

W dużym skró­cie: ana­li­za obiek­to­wa (ana­li­za zorien­to­wa­na obiek­to­wo) to opra­co­wa­nie mode­lu poję­cio­we­go infor­ma­cji, opi­su­ją­ce­go bada­ną dome­nę (czy­li ana­li­zo­wa­ny obszar dzie­dzi­no­wy, np. kon­kret­na orga­ni­za­cja, fir­ma nasze­go klien­ta). Kolejny etap to pro­jek­to­wa­nie obiek­to­we. Model ana­li­tycz­ny nie powi­nien zawie­rać ogra­ni­czeń tech­no­lo­gicz­nych (imple­men­ta­cyj­nych), te ogra­ni­cze­nia powin­ny być bra­ne pod uwa­gę dopie­ro na eta­pie pro­jek­to­wa­nia (to pra­ca pro­gra­mi­stów). I na koniec tra­ge­dia: ana­li­za powin­na być wyko­na­na przed roz­po­czę­ciem projektowania!

Powstaje obiek­to­wy model ele­men­tów orga­ni­za­cji zama­wia­ją­ce­go (pole­cam arty­kuł o Domain Driven Design).

Druga strona barykady: Analiza procesowa

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 obiek­ty czy­li struk­tu­ry łączą­ce dane i meto­dy ich prze­twa­rza­nia. 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! Organizacji zamawiającego!

W latach 60-tych (tak!) powsta­ły meto­dy obiek­to­we ana­li­zy i pro­jek­to­wa­nia jako pomysł na mode­lo­wa­nie świa­ta” tak jak jest postrze­ga­ny: w posta­ci obiek­tów mają­cych jakąś wie­dzę i jakieś umie­jęt­no­ści. To ana­li­za obiek­to­wa (sama w sobie nie ma ona nic wspól­ne­go z programowaniem!).

Skoro wie­le pro­ble­mów pro­gra­mi­stycz­nych doty­czy świa­ta rze­czy­wi­ste­go, powstał pomysł stwo­rze­nia języ­ka (ów) pro­gra­mo­wa­nia pasu­ją­ce­go” do pro­duk­tu ana­li­zy obiek­to­wej: mode­lu obiek­to­we­go: powstał obiek­to­wy język pro­gra­mo­wa­nia Small Talk.

Dzisiaj mamy sytu­ację, w któ­rej pro­gra­mi­ści uży­wa­ją obiek­to­wych narzę­dzi pro­gra­mi­stycz­nych i nie­ste­ty postrze­ga­ją je tyl­ko jako nowe meto­dy łącze­nia funk­cji i danych.

A teraz to wszystko narysuję

Zebrałem wszyst­ko powyż­szej i mamy:

Paradygmat obiektowy i procesowy, proces analizy
Paradygmat obiek­to­wy i pro­ce­so­wy, pro­ces analizy

U góry fir­ma (orga­ni­za­cja klien­ta), by zro­zu­mieć ją, pro­wa­dzi­my ana­li­zę pro­ce­so­wą. To ana­li­za ukie­run­ko­wa­na na zarzą­dza­nie czy­li kto, co i po robi. Jak odkry­je­my, że coś war­to uspraw­nić, robi­my to.

Wiedząc, że meto­dy obiek­to­we są sku­tecz­niej­sze w pro­jek­tach biz­ne­so­wych inży­nie­rii opro­gra­mo­wa­nia (no coś nale­ży uznać), opra­co­wu­je­my (prze­cho­dzi­my na) model obiek­to­wy tej organizacji.

Innymi sło­wy, model pro­ce­sów słu­ży nam do zro­zu­mie­nia tego jak dzia­ła orga­ni­za­cja, bo war­tość doda­na powsta­je jako pro­dukt pro­ce­su (biz­ne­so­we­go). Opracowanie narzę­dzia, jakim jest opro­gra­mo­wa­nie, wyma­ga opra­co­wa­nia okre­ślo­nej kon­struk­cji sys­te­mu, a ten jako taki jest obiektowy.

Jeżeli model pro­ce­so­wy orga­ni­za­cji poka­zu­je jak się ona zacho­wu­je, to model obiek­to­wy poka­zu­je czym ona jest.

W pro­ce­sie ana­li­zy obiek­to­wej powsta­je model obiek­to­wy bada­nej orga­ni­za­cji. Tu ma miej­sce trans­for­ma­cja para­dyg­ma­tu pro­ce­so­we­go na obiek­to­wy. To naj­trud­niej­sza część całe­go pro­jek­tu, tu powsta­je naj­więk­sze ryzy­ko, zła ana­li­za obiek­to­wa skut­ku­je jesz­cze gor­szym opro­gra­mo­wa­niem. Z regu­ły model obiek­to­wy jest two­rzo­ny nie dla całej orga­ni­za­cji a dla jej czę­ści (opro­gra­mo­wa­nie to jedy­nie narzę­dzie wspie­ra­ją­ce ludzi a nie cała firma).

Mając obiek­to­wy model wybra­ne­go obsza­ru orga­ni­za­cji i cel pro­jek­tu (koniecz­nie) two­rzy­my pro­jekt przy­szłe­go opro­gra­mo­wa­nia. Tu mała uwa­ga: opro­gra­mo­wa­nie to dwa aspek­ty: jego funk­cjo­nal­ność oraz tech­nicz­ne para­me­try takie jak bez­pie­czeń­stwo, wydaj­ność i dostęp­ność. Funkcjonalność wyni­ka wprost z pro­duk­tu ana­li­zy obiek­to­wej, para­me­try tech­nicz­ne to poza biz­ne­so­we ele­men­ty, któ­rych pro­jek­tan­ta­mi są inży­nie­ro­wie i programiści.

Mając pro­jekt, sia­da­my w koń­cu i kodu­je­my. Powstało opro­gra­mo­wa­nie, któ­re wspie­ra w usta­lo­nym obsza­rze orga­ni­za­cję zama­wia­ją­ce­go: opro­gra­mo­wa­nie to narzę­dzie. Na każ­dym eta­pie powyż­sze­go pro­ce­su powin­no się doko­nać oce­ny jako­ści pro­duk­tu. Należy spraw­dzić (upew­nić się), że mode­le są praw­dzi­we, i że ich imple­men­ta­cja dopro­wa­dzi do powsta­nia ocze­ki­wa­ne­go opro­gra­mo­wa­nia. Jak? Testując je. Jak? Opisałem to już 🙂 w poprzed­nich artykułach.

Diagram powyż­szy wyróż­nia dwa obsza­ry: żół­ty, któ­ry wska­zu­je na kom­pe­ten­cje Analityka Biznesowego oraz fio­le­to­wy, wska­zu­ją­cy na obszar kom­pe­ten­cyj­ny Dewelopera (wyko­naw­cy, dostaw­cy oprogramowania). 

Opracowanie mode­lu biz­ne­so­we­go (pro­ce­so­wy i obiek­to­wy) wyma­ga bar­dzo dużej wie­dzy z zakre­su zarzą­dza­nia i mar­ke­tin­gu. Wykonanie imple­men­ta­cji wyma­ga oczy­wi­ście dużej wie­dzy i doświad­cze­nia w zakre­sie inży­nie­rii opro­gra­mo­wa­nia. Są to nie­ste­ty dwa zupeł­nie odręb­ne obsza­ry wie­dzy i połą­cze­nie ich w jed­nej oso­bie jest nie­zwy­kle rzad­kie. Ale nawet jeśli znaj­dzie­my taka oso­bę, eta­py te powin­ny zostać roz­dzie­lo­ne z inne­go powo­du: wyko­naw­ca w biz­ne­sie nie powi­nien sam sobie sta­wiać wyma­gań! Rodzi to ogrom­ne ryzy­ko nad­użyć. (wię­cej o podzia­le na role w pro­jek­cie)

Komunikacja: powszech­nie uzna­ną meto­dą komu­ni­ka­cji w takich pro­jek­tach jest wła­śnie two­rze­nie mode­li, sfor­ma­li­zo­wa­nych dia­gra­mów obra­zu­ją­cych pro­duk­ty poszcze­gól­nych eta­pów ana­liz i pro­jek­to­wa­nia. O nota­cjach (stan­dar­dach two­rze­nia dia­gra­mów) w innych postach (są to głow­nie BPMNUML). Warto tu tyl­ko przy­to­czyć sta­re porze­ka­dło: rysu­nek wart tysią­ca słów. Kod jest zaś na samym koń­cu osta­tecz­nym produktem.

Agile

Najpierw przy­to­czę tak zwa­ny Manifest Agile:

Manifest Zwinnego Tworzenia Oprogramowania

Wytwarzając opro­gra­mo­wa­nie i poma­ga­jąc innym w tym zakre­sie, odkry­wa­my lep­sze spo­so­by wyko­ny­wa­nia tej pra­cy. W wyni­ku tych doświad­czeń przedkładamy:

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

Działające opro­gra­mo­wa­nie ponad obszer­ną dokumentację.

Współpraca z klien­tem ponad for­mal­ne ustalenia.

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

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

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

Cóż, zastą­pie­nie pro­ce­su ana­li­zy i pro­jek­to­wa­nia wer­bal­ną komu­ni­ka­cją to dro­ga na skró­ty: czer­wo­na strzał­ka. Czy to zła dro­ga? Droga na skró­ty to wspo­mnia­ne na począt­ku ryzy­ko, ogrom­ne bo sta­ty­sty­ki wska­zu­ją sta­le, że ok. 70 – 80% pro­jek­tów pro­gra­mi­stycz­nych ma poważ­ne kło­po­ty. Statystyki te są takie same od lat. Dlaczego? Skoro od razu kodu­je­my to pomi­nę­li­śmy pośred­nie spraw­dze­nia i weryfikacje.

Od lat zna­ny jest powyż­szy pro­ces i mimo to zawsze jest te 80% klien­tów i ich dostaw­ców, któ­rzy doga­du­ją się, że ana­li­za i pro­jek­to­wa­nia żad­ne­mu z nich nie słu­ży… tak jak to napi­sa­no na początku.

Po co to napi­sa­łem? By każ­dy z Państwa sam, świa­do­mie, oce­niał ryzy­ko swo­ich pro­jek­tów. Rezygnacja z ana­li­zy i pro­jek­to­wa­nia to pod­ję­cie pew­ne­go ryzy­ka. Niestety rezy­gna­cja z ana­li­zy i pro­jek­to­wa­nia ze stro­ny dewe­lo­pe­ra to cza­sem dodat­ko­wo sku­tek przy­zna­nia, że ana­li­za i pro­jek­to­wa­nie leży poza kom­pe­ten­cja­mi pro­gra­mi­stów (Ci obiek­to­wo kodu­ją) wiec wybie­ra­na jest dro­ga na skróty.

A Agile? Mam dziw­ne wra­że­nie, że to z jed­nej stro­ny łapa­nie brzy­twy przez toną­ce­go, ratu­nek, głos pro­gra­mi­stów pozba­wio­nych ana­li­ty­ka i pro­jek­tan­ta, a z dru­giej meto­dy­ka pozby­cia się roli nie pasu­ją­cej od para­dyg­ma­tu” pro­gra­mi­sty, któ­ry bada i roz­wi­ja się poprzez sta­łe ćwi­cze­nie się w swo­im fachu”, szko­da, że nie raz na cudzej skórze.

Pominięcie jed­nak ana­li­zy i pro­jek­to­wa­nia pro­wa­dzi do pro­gra­mów gdzie para­dyg­mat obiek­to­wy, koń­czy się na tym, że owe struk­tu­ry łączą­ce dane i ope­ra­cje na nich” powsta­ją jako sztucz­ne byty, nie mają­ce nic wspól­ne­go z rze­czy­wi­sto­ścią, a co naj­wy­żej z wygo­dą kodu­ją­ce­go pro­gra­mi­sty. Tak wła­śnie powsta­ją bar­dzo czę­sto bar­dzo złe pro­gra­my: nie­roz­wo­jo­we, nie­ży­cio­we, nie­na­tu­ral­ne w pracy.

I nie cho­dzi o to by koniecz­nie zatrud­niać ana­li­ty­ka, cho­dzi o to by rze­tel­nie wyko­nać ana­li­zę i pro­jekt zanim roz­pocz­nie­my kodowanie.

Inne artykuły na podobny temat

Komentarze

  1. Matthias 24 maja 2011 at 12:41

    Szkoda, że nie raz na cudzej skó­rze”… hm,… A na czy­jej skó­rze chciał­byś się uczyć? Na swo­jej? Gdyby tak podejść do spra­wy to wszy­scy pra­co­wa­li­by w jed­no­oso­bo­wych pro­jek­tach open-sour­ce, któ­re niko­mu nie słu­żą a jak wia­do­mo tak nie jest. Poza tym docho­dzi do tego wszyst­kie­go wstręt­na i pokręt­na poli­ty­ka, któ­ra nie­jed­no­krot­nie roz­wa­la cały pro­ces nie­waż­ne czy agi­le czy water­fall czy cos inne­go jesz­cze pomiędzy.

    • Jarek Żeliński 24 maja 2011 at 12:52

      Ja się uczę na swo­jej skó­rze i na swój koszt bo to, uczci­we. Ok. 50% moje­go cza­su w mie­sią­cu poświę­cam, poza papie­ra­mi fir­mo­wy­mi, na pro­jek­to­wa­nie na sucho” i pisa­nie dok­to­ra­tu. Znam wie­lu pro­gra­mi­stów, któ­rzy robią podob­nie, zresz­tą pro­jek­ty open-sour­ce wła­śnie taki mają cel: uczyć się bez szkód dla innych: uczci­wie. Współpracuje z pro­gra­mi­sta­mi, któ­rym było by wstyd obie­cać klien­to­wi coś cze­go jesz­cze nie robi­li. Co do poli­ty­ki w tej czy inne fir­mie to jest sta­re kor­po­ra­cyj­ne powie­dze­nie: nie akcep­tu­jesz i wycho­dzisz albo akcep­tu­jesz i zostajesz”.

  2. Paweł Lipiński 1 czerwca 2011 at 16:21

    Po prze­czy­ta­niu tego wpi­su zasta­na­wiam się, czy nie powin­no się jakoś karać roz­prze­strze­nia­nia FUDu…
    To co piszesz jest gru­bo nie­praw­dzi­we, albo bazu­je na nie­zro­zu­mie­niu paru spraw. Po kolei:
    1) Zdajesz się nie rozu­mieć obiek­to­wo­ści i zwią­za­ne­go z nią pro­ce­su pro­gra­mi­stycz­ne­go. Nie winię Cię – zda­je się, że po pro­stu się tym na codzień nie zaj­mu­jesz, dzi­wię się tyl­ko, że poru­szasz ten temat. Co wię­cej Twoje tłu­ma­cze­nia są deli­kat­nie mani­pu­la­cyj­ne (np. Anaysis is done befo­re…” nie ozna­cza Analiza powin­na być wyko­na­na…”) Co wię­cej wzię­cie pierw­sze­go aka­pi­tu z wiki­pe­dii wyry­wa tekst z kon­tek­stu. Np. nie wzią­łeś już pod uwa­gę nastę­pu­ją­ce­go (klu­czo­we­go dla zwin­nych meto­dyk) zda­nia (z arty­ku­łu o pro­jek­to­wa­niu): Both ana­ly­sis and design can be per­for­med incre­men­tal­ly, and the arti­facts can be con­ti­nu­ously grown inste­ad of com­ple­te­ly deve­lo­ped in one shot.” Hm – to zda­nie zaprze­cza Twojemu diagramowi…
    Dobrze, że nawią­za­łeś do DDD, bo to podej­ście bar­dzo sil­nie zaprze­cza fazo­we­mu podej­ściu do two­rze­nia opro­gra­mo­wa­nia. Z resz­tą Eric Evans (autor DDD) pocho­dzi bez­po­śred­nio ze zwin­nych śro­do­wisk (kon­kret­nie XP). Zachęcam do prze­czy­ta­nia jego książ­ki, a zoba­czysz jak wyma­ga­nia i model kon­cep­cyj­ny wyła­nia­ją się W TRAKCIE programowania.
    2. Nawiązanie do zwin­nych meto­dyk wska­zu­je nie­ste­ty na pew­ne nie­do­czy­ta­nie źró­deł. Nigdzie nie jest napi­sa­ne, że 80% pro­jek­tów się nie uda­je ze wzglę­du na brak ana­li­zy (albo ja nie znam takich opra­co­wań). Jest za to napi­sa­ne, że zwin­ne meto­dy­ki zmniej­sza­ją ryzy­ko (http://​www​.infoq​.com/​a​r​t​i​c​l​e​s​/​I​n​t​e​r​v​i​e​w​-​J​o​h​n​s​o​n​-​S​t​a​n​d​i​s​h​-​C​H​AOS)
    3. Teraz kon­kre­ty dot. agile.
    3a. W zwin­nych meto­dy­kach nie jest tak, że nie ma ana­li­zy. Jest i to zwy­kle dużo dokład­niej­sza niż w kla­sycz­nym fazo­wym podej­ściu, bo dzie­je się CIĄGLE, przez cały czas trwa­nia pro­jek­tu. I oczy­wi­ście, że jest ona w więk­szo­ści przed pro­gra­mo­wa­niem danej funk­cjo­nal­no­ści (spo­tka­nie plan­nin­go­we, spo­tka­nie bac­klog gro­oming, a nawet ad-hoc roz­mo­wy przy kawie prze­no­szą­ce się na whi­te­bo­ard), a tyl­ko w czę­ści w trak­cie pro­gra­mo­wa­nia (dopy­tu­je­my w trak­cie pro­gra­mo­wa­nia – wykry­wa­my dodat­ko­we przy­pad­ki, po poka­za­niu klien­to­wi odpo­wied­nie­go kawał­ka UI, itp).
    3b. W zwin­nych meto­dy­kach nie jest tak, że nie ma pro­jek­to­wa­nia. Jest i to zwy­kle dużo dokład­niej­sze niż w kla­sycz­nym fazo­wym podej­ściu, bo dzie­je się CIĄGLE, przez cały czas trwa­nia pro­jek­tu. Każda nowa funk­cjo­nal­ność jest opra­co­wy­wa­na zaraz przed roz­po­czę­ciem pro­gra­mo­wa­nia pod wzglę­dem jej umiesz­cze­nia w sys­te­mie (archi­tek­tu­ra) oraz jej wewn. pro­jek­tu (design). Oczywiście szcze­gó­ły w rodza­ju wzor­ców pro­jek­to­wych powstają/wyłaniają się w trak­cie deve­lop­men­tu, ale dla trud­niej­szych przy­pad­ków duża część pra­cy odby­wa się na papie­rze i whi­te­bo­ar­dzie. Tak więc pro­jek­tu­je­my zarów­no przed deve­lop­men­tem jak i w trak­cie. Tyle, że znów: iteracyjnie/inkrementalnie i per-feature.
    4. Stawianie pozy­cji ana­li­ty­ka jako prze­ci­wień­stwo agi­le jest nie fair. Analityk może (a nawet musi) mieć swo­je miej­sce w zwin­nie pro­wa­dzo­nym pro­jek­cie (i nazy­wa się np. pro­duct owner albo custo­mer w zależ­no­ści od meto­dy­ki), tyle że lepiej żeby nie był ana­li­ty­kiem z zawo­du, tyl­ko eks­per­tem dane­go biz­ne­su. Dlatego w naszych pro­jek­tach ana­li­ty­kiem jest np. spe­cja­li­sta od roamin­gu czy logi­styk. I pra­cu­je ite­ra­cyj­nie dostar­cza­jąc i pogłę­bia­jąc nam wyma­ga­nia. I nie nazy­wa­my go ana­li­tyk, ale to pew­nie tyl­ko kwe­stia nazewnictwa.
    Podsumowując w zwin­nych meto­dy­kach nie cho­dzi o to, żeby rze­tel­nie wyko­nać ana­li­zę i pro­jekt zanim roz­pocz­nie­my kodo­wa­nie” tyl­ko mak­sy­ma­li­zo­wać praw­do­po­do­bień­stwo suk­ce­su przez zbli­że­nie i mak­sy­ma­li­za­cję efek­tyw­nej komu­ni­ka­cji mię­dzy biz­ne­sem, archi­tek­tu­rą i deve­lop­men­tem, by mak­sy­ma­li­zo­wać przy­no­szo­ną wartość.

    Polecam arty­kuł, któ­ry jakiś czas temu napisałem: 

    pozdra­wiam
    Paweł

    • Jarek Żeliński 1 czerwca 2011 at 21:14

      Na począ­tek zazna­czę, że każ­dy ma pra­wo do swo­je­go zda­nia, i Ty i ja.

      Ad.1. Obiektowość to nie tyl­ko obiek­to­wy kom­pi­la­tor ale tak­że ana­li­za i mode­lo­wa­nie, pra­gnę przy­po­mnieć, że języ­ki pro­gra­mo­wa­nia obiek­to­we powsta­ły w odpo­wie­dzi na obiek­to­wy para­dyg­mat ana­li­zy i pro­jek­to­wa­nia a nie odwrot­nie, są imple­men­ta­cją obiektowości.

      Analiza i pro­jek­to­wa­nie (owe wspo­mnia­ne ana­ly­sis and design”) obiek­to­we nie mają nic wspól­ne­go z pisa­niem kodu i fak­tycz­nie jest ite­ra­cyj­ne, kod ten jest wtór­ny do pro­jek­tu: to imple­men­ta­cja wyni­ków pro­jek­to­wa­nia obiektowego.

      DDD to styl pro­jek­to­wa­nia a nie pro­gra­mo­wa­nia, to dru­gie to jest imple­men­ta­cja pro­jek­tu (powta­rzam się). (DDD Evansa jest na mojej pół­ce, nie ma tam nic – nie zna­la­złem – o kodo­wa­niu bez poprze­dza­ją­ce­go go, ite­ra­cyj­ne­go, projektowania).

      2. W kwe­stii zasto­so­wań zwin­nych meto­dyk pole­cam http://​it​-con​sul​ting​.pl/​a​u​t​o​i​n​s​t​a​l​a​t​o​r​/​w​o​r​d​p​r​e​s​s​/​i​n​d​e​x​.​p​h​p​/​2​0​1​1​/​0​3​/​2​2​/​c​o​-​w​y​b​r​a​c​-​c​z​y​l​i​-​c​y​k​l​-​z​y​c​i​a​-​p​r​o​j​e​k​t​u​-​t​w​o​r​z​e​n​i​a​-​o​p​r​o​g​r​a​m​o​w​a​n​ia/, pod­su­mo­wa­nie wie­lu źró­deł o pro­gra­mo­wa­niu i metodach.

      ad.3. Nie piszę o tym, że w zwin­nych meto­dy­kach nie ma ana­li­zy a o tym, że jest ona roz­po­zna­niem bojem” a to wła­śnie krytykuję…

      ad.4.Chodzi mi o to, że roz­po­zna­nie bojem” na papie­rze (ana­li­za i mode­le) jest sku­tecz­niej­sze i tań­sza niż od razu z pomo­cą zespo­łu kode­rów i kodo­wa­nia. Fazowość postrze­gam jako oddzie­le­nie szu­ka­nia roz­wią­za­nia od jego implementacji. 

      Dlaczego o tym w ogó­le piszę? Bo porów­na­nie ofert wyglą­da tak (jeden z wie­lu moich projektów):
      Wariant 1.: Zwinne meto­dy­ki itp.: ofer­ty na bazie opi­su przy­szłe­go użyt­kow­ni­ka oscy­lu­ją w gra­ni­cach 450 – 700 tys.
      wariant 2.: ana­li­za i pro­jek­to­wa­nie, potem imple­men­ta­cja: ofer­ty na bazie wcze­śniej pro­jek­tu UML mają już war­tość 170 – 200 tys., poprze­dza­ją­cy koszt ana­li­zy i pro­jek­tu w tym pro­jek­cie, ok. 30 tys. Każdy potra­fi liczyć. Projekt zamknię­ty, wyko­na­ny w ter­mi­nie i w budże­cie: imple­men­ta­cja kwar­tał, odda­na w wer­sji pierw­szej do użyt­ku. łącz­ny koszt to 200 tys. zamiast 450tys. (?700?). Tak to wyglą­da. To moje doświadczenia.

      Dla mnie obiek­tyw­nym mier­ni­kiem są zakoń­czo­ne i roz­li­czo­ne pro­jek­ty oraz pier­wot­ne ofer­ty jako porównanie.

      Może do zoba­cze­nia na Confiturze 11 Czerwca :), nie ma co się emocjonować. 

      Jak mam rozu­mieć zabro­nić” w sen­sie jakich­kol­wiek wypo­wie­dzi? Cenzura nie­wy­god­nych tez? Polecam tak­że to: 

      oraz to:

      http://​msdn​.micro​soft​.com/​e​n​-​u​s​/​l​i​b​r​a​r​y​/​d​d​4​0​9​4​2​3​(​v​=​V​S​.​100).aspx

  3. Paweł Lipiński 1 czerwca 2011 at 23:56

    To zacznę od tego, że z tym zaka­zy­wa­niem to oczy­wi­ście żart. Natomiast uwa­żam (po prze­czy­ta­niu paru Twoich wpi­sów tu i na GL), że porów­nu­jesz to co znasz (co ja nazy­wam teo­ria­mi i prak­ty­ka­mi z lat 80 – 90tych) z tym o czym chy­ba tyl­ko czy­ta­łeś (agi­le, DDD, itp). Przykłady? Np. we wpi­sie o meto­dy­kach piszesz, że Scrum jest ści­śle pro­gra­mi­stycz­ny, co wyraź­nie wska­zu­je, że mylisz go z XP. Scrum to fra­me­work nie­za­leż­ny (w zało­że­niach) od typu pro­jek­tu – czy to infor­ma­tycz­ny, logi­stycz­ny, admi­ni­stra­cyj­ny, czy jaki­kol­wiek inny.
    Nie pró­bu­ję Ci ode­brać zda­nia, tyl­ko zachę­cam do pozna­nia w prak­ty­ce (naj­le­piej dobrej…) tego o czym piszesz.

    A teraz komen­tarz do komen­ta­rza do komentarza:
    Ad Ad 1. Obecne projektowanie/programowanie obiek­to­we wca­le nie ma wie­le wspól­ne­go z ana­li­zą obiek­to­wą. Szczególnie w pro­jek­tach biz­ne­so­wych, gdzie 90% kodu to infra­struk­tu­ra, ujarz­mie­nie tech­no­lo­gii i GUI a nie logi­ka biz­ne­so­wa. Co wię­cej narzę­dzia do ana­li­zy obiek­to­wej (use case­’y, prze­pły­wy, sekwen­cje itp) rzad­ko dobrze się mapu­ją na pro­gra­mo­wa­nie obiek­to­we, za to świet­nie na pro­ce­du­ral­ne, stąd trud­no o dobrze obiek­to­wy kod w takich pro­jek­tach (no dobra – nie koniecz­nie taki jest głów­ny powód, ale to jeden z nich).
    A co do DDD, to na raz i masz rację i nie. Masz na płasz­czyź­nie lin­gwi­stycz­nej – w koń­cu Design to nie pro­gra­mo­wa­nie. Nie masz za to w war­stwie zna­cze­nio­wej, bo pew­nie nie wiesz, że Evans był zwią­za­ny z XP bar­dzo moc­no i dla nie­go pro­jek­to­wa­nie i pro­gra­mo­wa­nie (jak dla wszyst­kich XPowców) to nie­roz­dziel­ne aktyw­no­ści. Dlatego w książ­ce pisze o tym, że ma ze sobą eks­per­ta, z któ­rym gada­jąc pisze kod. Pisze go naj­chęt­niej w DSLu, żeby eks­pert zro­zu­miał i mógł ew. zgło­sić popraw­ki. Tak więc na raz pro­jek­tu­je (zgłę­bia­jąc swój model kon­cep­cyj­ny i dome­nę) i pro­gra­mu­je, bo powsta­je z tego rich doma­in model” uży­wa­ny potem w apli­ka­cji. Powstaje/prezycuje się też ubi­qu­ito­us lan­gu­age, co jest już zupeł­nie ana­li­tycz­ną rzeczą.
    Ad Ad 2. Przejrzałem wpis i fak­tycz­nie cie­ka­wy, choć nie bez uwag 😉 Model wodo­spa­do­wy w takiej for­mie jak go nary­so­wa­łeś nie ist­nie­je i nie ist­niał nigdy (Winston Royce miał na myśli coś inne­go, co faj­nie poka­za­ne jest tu: http://​www​.youtu​be​.com/​w​a​t​c​h​?​v​=​X​1c2 – sP3o0). Scrum to (jak już pisa­łem) nie­za­leż­na od kodo­wa­nia meto­dy­ka (a nie meto­do­lo­gia, któ­ra po Polsku jest nauką o meto­dy­kach), w któ­rej czę­sto sto­su­je się prak­ty­ki XP. Dlatego nazy­wa­na jest cza­sem XP nie tyl­ko dla orłów. Do tego zwin­ne meto­dy­ki sto­su­je się nie tyl­ko w małych pro­jek­tach i to ze zna­czym suk­ce­sem. Np. w mojej fir­mie nasz głów­ny pro­jekt trwa już ponad 2 lata, a mamy zagwa­ran­to­wa­ne jesz­cze do koń­ca roku. Zespół jest paro­na­sto­oso­bo­wy. W samej javie jest teraz coś pod 200k linii kodu. I uwierz mi, to co wyana­li­zo­wa­li na począt­ku ma się nijak do tego, cze­go chcą teraz. Bo nie tyl­ko zmie­ni­ły się ich ocze­ki­wa­nia, ich klien­tów, tech­no­lo­gie, to jesz­cze wie­le rze­czy oka­za­ło się dopie­ro jak dało się w nie kliknąć.
    Ale zga­dzam się w 100% z tym, że XP (i w ogó­le agi­le) wyma­ga b. dużej odpo­wie­dzial­no­ści i świa­do­mo­ści zespo­łu. Stąd rola coach’a/scrum maste­ra, któ­ry ma dbać o pro­ces i zespół.
    Rozróżnienie podej­ścia z pro­to­ty­pa­mi, pro­to­ty­pa­mi odrzu­ca­ny­mi od innych meto­dyk jest wg mnie błę­dem, bo to orto­go­nal­na do meto­dy­ki tech­ni­ka. Stosuje się je i w wodo­spa­dach i w agi­le­’u. Z resz­tą w agi­le­’u bar­dzo czę­sto (bo ide­al­nie wpa­so­wu­je się w ite­ra­cyj­ność i czę­sty kon­takt z klien­tem), więc wpi­sy­wa­nie dla nich innych war­to­ści w tabel­ce porów­naw­czej jest błę­dem. Tak – wg mnie oczywiście 😉
    Ad Ad 3. No wła­śnie pro­blem jest taki, że nie bar­dzo się da roz­po­znać bez boju. Tzn cza­sem się da wię­cej, cza­sem mniej, ale nigdy 100%. Zawsze coś roz­po­znasz dopie­ro w boju – i to w cale nie tak mało. Dlatego nie jestem za ata­ko­wa­niem z kodem dzie­dzi­ny od pierw­sze­go dnia, za to spę­dza­nie 25% cza­su pro­jek­tu na ana­li­zie też nie jest wg mnie dobrym roz­wią­za­niem. Komentarz do blo­ga to za krót­ka for­ma, żeby pisać dla­cze­go (głów­nie psy­cho­lo­gia się tu kła­nia – dro­gi na skró­ty, zmia­na wyma­gań, licz­ba ogniw w łań­cu­chu komu­ni­ka­cji, itp).
    Ad Ad 4. Każdy pro­gra­mi­sta Ci powie, że mode­le przy­go­to­wa­ne w UMLu moż­na w więk­szo­ści o kant D roz­bić. Do tego ich two­rze­nie jest nie­sa­mo­wi­cie kosz­tow­ne, a utrzy­ma­nie aktu­al­nych jesz­cze bar­dziej. Zwiększają więc one tyl­ko kosz­ty wca­le nie zmniej­sza­jąc ryzy­ka. Pracowałem jako archi­tekt przez parę lat, przy napraw­dę dużych sys­te­mach i uwierz – kod ma się nijak do tego co archi­tek­ci / desi­gne­rzy UMLowi pro­du­ku­ją. Z resz­tą nie może być ina­czej – żaden mniej zło­żo­ny sys­tem nie może kon­tro­lo­wać bar­dziej zło­żo­ne­go. A archi­tek­tu­ra czy ana­li­za jest z natu­ry rze­czy mniej zło­żo­na od pro­gra­mo­wa­nia. Operuje w koń­cu na abs­trak­cjach, uogól­nie­niach i zało­że­niach a nie na faktach.
    Ale i tak zgod­nie z Twoimi prze­my­śle­nia­mi uwa­żam, że wie­lu pro­ble­mów pro­gra­mi­stycz­nych moż­na by unik­nąć gdy­by były lepiej prze­my­śla­ne przed zgło­sze­niem zespo­ło­wi (a więc zana­li­zo­wa­ne). Dlatego nie ucie­kam od ana­li­zy – nawet szcze­gó­ło­wej – ale wybiór­czej, tzn. reali­zo­wa­nej w odpo­wied­nich szcze­gó­łach tam gdzie ma to zastosowanie.

    Porównanie ofert o któ­rym piszesz nie dowo­dzi NICZEGO W OGÓLE. Kwoty w ofer­tach zwy­kle wysta­wia się na pod­sta­wie zgrub­nych, nie­peł­nych, czę­sto sprzecz­nych wyma­gań, w opar­ciu o czyn­ni­ki ryzy­ka, gru­be osza­co­wa­nia i ssa­nie z pal­ca. Do tego docho­dzi poli­ty­ka i kole­sio­stwo. W Twoim przy­pad­ku goście agi­le­’o­wi pew­nie nie chcie­li ryzy­ko­wać, więc wal­nę­li z góry” – z resz­tą chęt­nie bym się dowie­dział jak liczy­li. Goście od UML’a (a Ci agi­le­’ow­cy nie mie­li tego UML’a?) za to pew­nie chcie­li po pro­stu zro­bić pro­jekt, licząc, że jeśli coś się poja­wi ryzy­kow­ne­go to się chwy­ci klien­ta na CRy. A może nie – a może po pro­stu oni do tego usie­dli i poli­czy­li, a agi­le­’ow­cy wyssa­li z pal­ca licząc na brak kon­ku­ren­cji? Kto wie…
    Tak czy siak, mogę Ci powie­dzieć, że my liczy­my na podst. zapy­ta­nia ofer­to­we­go tak:
    1. robi­my z wyma­gań coś a’la user story
    2. porów­nu­je­my do aktu­al­nie robio­ne­go pro­jek­tu (roz­mia­ry story)
    3. sza­cu­je­my wzglę­dem aktualnego
    4. prze­li­cza­my wzglę­dem aktu­al­ne­go (pręd­ko­ści zespołu)
    Więc sta­ra­my się nie wysy­sać z pal­ca, tyl­ko bazo­wać na sta­ty­sty­kach. Do tego nigdy nie robi tego 1na oso­ba, tyl­ko zawsze przy­naj­mniej 2 – 3, żeby dys­ku­to­wa­ły w trak­cie wyceniania.

    Do con­fi­tu­ry!

    • Jarek Żeliński 2 czerwca 2011 at 00:35

      Obecne projektowanie/programowanie obiek­to­we wca­le nie ma wie­le wspól­ne­go z ana­li­zą obiek­to­wą. Szczególnie w pro­jek­tach biz­ne­so­wych, gdzie 90% kodu to infra­struk­tu­ra, ujarz­mie­nie tech­no­lo­gii i GUI a nie logi­ka biznesowa”

      Zgadzam się, że 90% to infra­struk­tu­ra i nie raz to potwier­dza­łem, jed­nak w 100% tam gdzie byłem świad­kiem kło­po­tów z odbio­rem opro­gra­mo­wa­nia pro­blem nie tkwił w infra­struk­tu­rze a w regu­łach biz­ne­so­wych, to że wg. Ciebie są one nie waż­ne potwier­dza tyl­ko ten pro­blem… Otóż to co sys­tem ma robić dla użyt­kow­ni­ka to w 100% ana­li­za i pro­jek­to­wa­nie, tu obiektowe.

      Jeżeli uwa­żasz, że pro­blem jest taki, że nie bar­dzo się da roz­po­znać bez boju.” to Twoje zda­nie i masz pra­wo je mieć. Po raz kolej­ny przy­to­czę: to że nie widzia­łeś nigdy czar­ne­go łabę­dzie nie sta­no­wi żane­go dowo­du na jego nieistnienie”.

      Każdy pro­gra­mi­sta Ci powie, że mode­le przy­go­to­wa­ne w UMLu moż­na w więk­szo­ści o kant D roz­bić.”, uści­slij­my: nie każ­dy i być może te któ­re widzia­łes lub te któ­rych nie potra­fi­łeś prze­czy­tać, nie wiem, pokaż takie przy­kła­dy to będę miał swo­je zda­nie… jak na razie ci pro­gra­mi­ści z któ­ry­mi ja wspól­pra­cu­ję w 100% korzy­sta­ją z mode­li UML i to dzię­ki ich umie­jęt­no­ściom mie­wam pro­por­cje 200 tys. vs. 700tys. u konkurentów.

      do tego ich two­rze­nie jest nie­sa­mo­wi­cie kosz­tow­ne”, wybacz ale to już jest bełkot…ja też takie two­rze je wiem ile kosztują. 

      kod ma się nijak do tego co archi­tek­ci / desi­gne­rzy UMLowi pro­du­ku­ją”, współ­czu­je kom­pe­ten­cja zespo­łu, klu­czo­wą mia­ra zespo­łu ana­li­ty­ków i pro­jek­tan­tów jest to jak się ma pro­dukt koń­co­wy do pro­jek­tu. Jeżeli nijak się nie ma to… 

      porów­na­nie ofert o któ­rym piszesz nie dowo­dzi NICZEGO W OGÓLE.”, dowo­dzi pro­stej rze­czy: istot­nie się różnią. 

      my liczy­my na podst. zapy­ta­nia ofer­to­we­go”, któ­re jest czym? Projektem? Opisem? Życzeniem? Jeżeli ktoś potra­fi zło­żyć ofer­tę nie wie­dząc co ma zro­bić (a co naj­wy­żej, do cze­go to posłu­ży) to ja podzi­wiam, w szcze­gól­no­ści narzut na tę niewiedzę. 

      Do kon­fi­tu­ry… mamy na praw­dę bar­dzo odmien­ne doświad­cze­nia i jak to mówią, rynek to oce­ni nie my, koń­czę ten spór…

  4. Mateusz Kurleto 2 czerwca 2011 at 01:16

    Najpierw się przyczepię:
    Mając obiek­to­wy model orga­ni­za­cji i cel pro­jek­tu (koniecz­nie) two­rzy­my pro­jekt przy­szłe­go opro­gra­mo­wa­nia. Tu mała uwa­ga: opro­gra­mo­wa­nie to dwa aspek­ty: jego funk­cjo­nal­ność oraz tech­nicz­ne para­me­try takie jak bez­pie­czeń­stwo, wydaj­ność i dostęp­ność. Funkcjonalność wyni­ka wprost z pro­duk­tu ana­li­zy obiek­to­wej, para­me­try tech­nicz­ne to poza biz­ne­so­we ele­men­ty, któ­rych pro­jek­tan­ta­mi są inży­nie­ro­wie i programiści.”
    1) tech­nicz­ne para­me­try takie jak(…) – to są poza­funk­cjo­nal­ne wyma­ga­nia zwa­ne tak­że ogra­ni­cze­nia­mi a nie żad­ne tech­nicz­ne aspek­ty, wyma­ga­nie na mak­sy­mal­ny czas odpo­wie­dzi, pozio­my pew­no­ści algo­ryt­mów decy­zyj­nych, czy ilość prze­twa­rza­nych danych, albo infor­ma­cje o pla­no­wa­nym obcią­że­niu – to też wyma­ga­nia poza­funk­cjo­nal­ne i nie mają żad­nych tech­nicz­nych aspektów:P
    2) te wyma­ga­nia (poza­funk­cjo­nal­ne) wca­le nie wyni­ka­ją z pra­cy inży­nie­rów i pro­gra­mi­stów, one jak naj­bar­dziej wyni­ka­ją z ana­li­zy biz­ne­so­wej; to biz­nes musi wyzna­czyć pew­ne gra­ni­ce w ramach któ­rych opro­gra­mo­wa­nie ma być reali­zo­wa­ne – wyma­ga­nia na wydaj­ność, pojem­ność, etc. wyni­ka­ją wprost z ana­li­zy biz­ne­so­wej przy­kład wyma­ga­nia biz­ne­su sys­tem ma być bezpieczny”-bzdura (co to zna­czy bez­piecz­ny?) sys­tem ma korzy­stać z pro­to­ko­łu SSL”-mniejsza bzdura(jakiego? i cze­mu wła­śnie tego?) sys­tem ma prze­sy­łąć dane szy­fro­wa­nym łączem, unie­moż­li­wia­ją­cym pod­słu­cha­nie i odszy­fro­wa­nie prze­sy­ła­nych komu­ni­ka­tów w cza­sie <1 dnia przez kom­pu­ter osobisty”-dobre wyma­ga­nie, któ­re pro­jek­tant zamie­ni na – koży­sta­my z takich to a takich spo­so­bów szy­fro­wa­nia łącza, takich to a takich funk­cji hashu­ją­cych hasła, sto­su­je­my min. 1024 bito­we klu­cze etc.

    A co do Waszej dyskusji:
    1) Jarku, daj sobie spo­kój z tym noto­rycz­nym jeż­dże­niu po Agile jako idei. Już tak wie­le razy przy­zna­łeś mi rację, gdy tłu­ma­czy­łem, że to dobre narzę­dzie w obsza­rze jego użyt­ko­wa­nia, a dobre prak­ty­ki Agile wca­le nie pomi­ja­ją ana­li­zy i pro­jek­to­wa­nia. Nie spło­dzę tak zgrab­ne­go tek­stu (a przy­naj­mniej nie sam) na ten temat, ale napraw­dę Twoja anty­pa­tia wyni­ka z efek­tu krzy­we­go zwierciadła.
    Czytasz o Agile i obser­wu­jesz pro­jek­ty, mie­nią­ce się Agile – choć tak napraw­dę z dobry­mi prak­ty­ka­mi nie mają one nic wspól­ne­go. Ludzie pro­gra­mu­ją na pałę i im się wyda­je, że jak sza­co­wa­li gra­jąc w poke­r’a to są Agile. Nie są, choć tak mówią – to nie jest Agile. Potępiaj kiep­skie wyko­na­nie, a nie napraw­dę solid­ne narzę­dzie projektowe:P Jak mnie spro­wo­ku­jesz to w koń­cu zro­bi­my razem pro­jekt Agile, żeby Ci udo­wod­nić, że to wiel­kie dobro, jak się umie tego używać.

    • Jarek Żeliński 2 czerwca 2011 at 07:17

      Wydaje mi się, że wie­le nie­po­ro­zu­mień, w takich ja ta wymia­na poglą­dów, jest wyni­kiem swo­bo­dy uży­wa­nia pojęć ogól­nie postrze­ga­nych jako zna­ne”. Prawdę mówiąc, nie mam nic prze­ciw­ko jakim­kol­wiek pro­gra­mi­stom, jed­nak trud­no mi zaak­cep­to­wać pew­ne prak­ty­ki. Wydaje mi się, że wystar­czy np. zre­zy­gno­wać ze sło­wa Agile a zacząć pisać o kon­kret­nym przy­pad­ku i kon­kret­nej pra­cy a pro­blem znik­nie. Ja kil­ka lat temu uży­wa­łem poję­cia zwin­na ana­li­za i pro­jek­to­wa­nie” na zmia­nę z Agile Analysis, mając na myśli po pro­stu adap­ta­cyj­ny spo­sób dobie­ra­nia zakre­su pro­jek­tu i spo­so­bu jego pro­wa­dze­nia. Po kil­ku zarzu­tach”, teraz uwa­żam słusz­nych, zre­zy­gno­wa­łem. Dlaczego? Bo to co robi­łem nie mia­ło nic wspól­ne­go z owym mani­fe­stem agi­le. Osobiście, jako zwo­len­nik pod­no­sze­nia jako­ści komu­ni­ka­cji – pre­cy­zo­wa­nia uży­wa­nych pojęć – uwa­żam, że jak dłu­go sło­wo Agile ma tyle defi­ni­cji ilu jest ludzi go uży­wa­ją­cych, tak dłu­go jego uży­wa­nie będzie się wią­za­ło z taki­mi nie­po­ro­zu­mie­nia­mi. Tak więc nie jeż­dżę po Agile a po tym, że to sło­wo nic nie zna­czy (poza tłu­ma­cze­niem: zwinność). 

      Ad.1. Widzisz tu mamy kolej­ne nie­po­ro­zu­mie­nie ;). Krąży wie­le defi­ni­cji pojęć wyma­ga­nia funk­cjo­nal­ne i poza funk­cjo­nal­ne”, nie raz poja­wia­ją się tak­że inne. Dla mnie aspek­tem tech­nicz­nym jest to, że spo­dzie­wa­my się 2 milio­nów doku­men­tów w repo­zy­to­rium”, bo z tym musi sobie pora­dzić dostaw­ca tech­no­lo­gii”, tak­że z algo­ryt­ma­mi wyszu­ki­wa­nia. Wymaganiem funk­cjo­nal­nym będzie to, jakie meta­da­ne będą opi­sy­wa­ły te doku­men­ty, poza funk­cjo­nal­nym to, że czas wyszu­ki­wa­nia doku­men­tu nie powi­nien prze­kro­czyć 5 minut. Tym ostat­nim zaj­mą się już (tak sądzę) inży­nie­ro­wie a nie ana­li­tyk (lub stwier­dzą, że nie da sie tego osiągnąć). 

      Ad.2. Masz rację, wyma­ga­nia poza-func­kjo­nal­ne musi ktoś okre­ślić, biz­nes czy ana­li­tyk biz­ne­so­wy. Twój przy­kład z SSL jest bar­dzo dobry, ja tak­że uwa­żam, że poziom bez­pie­czeń­stwa” to wyma­ga­nie (ogra­ni­cze­nie) a ów SSL to imple­men­ta­cja. Pierwsze pisze ana­li­tyk dru­gie wymy­śla” inży­nier odpo­wie­dzial­ny na pro­jekt imple­men­ta­cji. Jak widać, bała­gan poję­cio­wy jest i mamy nie­po­ro­zu­mie­nia. Co do stwier­dze­nia sys­tem ma być bez­piecz­ny” ono samo z sie­bie jest nie­mie­rzal­ne, racja. Wypadało by napi­sać jak bar­dzo bez­piecz­ny” i okre­ślić mia­rę. Jednak miej­my świa­do­mość, że np. usta­wo­daw­ca posłu­żył się poję­ciem bez­piecz­ny pod­pis elek­tro­nicz­ny”. Co to zna­czy? Nic, chy­ba że uzna­my, że bez­piecz­ny pod­pis elek­tro­nicz­ny” to taki, przy któ­rym zasto­so­wa­no kon­kret­ną, opi­sa­ną w innych doku­men­tach usta­wo­daw­cy tech­no­lo­gię. Tak więc cza­sa­mi wypa­da” posłu­żyć się ogól­nie przy­ję­ta wie­dzą” a dla pre­cy­zji wpi­sać ów SSL jako przy­kład poj­mo­wa­nia” tego pozio­mu bezpieczeństwa. 

      Dlatego ja, by unik­nąć nie­po­ro­zu­mień, nie uży­wam słów Agile”, zwin­ne meto­dy” itp. Po pro­tu nale­ży napi­sać co i jak się robi (zro­bi). Niestety wie­lu dostaw­ców sys­te­mów” nie potra­fi (nie chce?) z góry napi­sać co i jak zro­bią i z tym wal­czę” a nie z dobry­mi prak­ty­ka­mi, któ­re nie raz sam sto­su­ję. Ilu pro­gra­mi­stów (firm) two­rzy doku­ment her­me­ty­za­cja”, któ­ry Ty sto­su­jesz? Ilu pro­gra­mi­stów (firm) potra­fi z góry zade­kla­ro­wać do dostar­czą? Moje ata­ki” doty­czą bała­ga­nu poję­cio­we­go w ofer­tach i pro­to­ko­łach prze­ka­za­nia. Zbyt wie­le pro­gra­mów, za któ­re wysta­wio­no fak­tu­rę a któ­re do nicze­go nie słu­ży­ły, widzia­łem. To nie ja wymy­śli­łem, że fir­ma pro­gra­mi­stycz­na ma mieć dobre­go praw­ni­ka a nie dobre­go pro­gra­mi­stę. Mam tak­że świa­do­mość, że wie­le firm pro­gra­mi­stycz­nych (nie wszyst­kie) ata­ku­je mnie (i nie tyl­ko mnie) bo przy zbyt dobrze (co by to nie mia­ło zna­czyć) okre­ślo­nych wyma­ga­niach, ich pro­jek­ty są moż­li­we do roz­li­cze­nia a tego wie­lu z nich nie lubi. 

      Na koniec: jak ktoś pisze, że pla­no­wa­nie i pro­jek­to­wa­nie nale­ży wytę­pić, będzie moim wro­giem”. Czym jest opra­co­wa­nie wyma­gań i zapro­jek­to­wa­nie logi­ki sys­te­mu jak nie pla­no­wa­niem i pro­jek­to­wa­niem? Przytaczanie przy­kła­dów wyjąt­ko­wo złej jako­ści doku­men­tów ana­li­ty­ków (a praw­da jest, że pro­du­ku­ją takie nawet zacne gieł­do­we spół­ki infor­ma­tycz­ne!), to nie argu­ment by z ana­liz (ana­li­ty­ków) zre­zy­gno­wać a argu­ment za tym by pil­no­wać lepiej ich jako­ści. Idąc tym tro­pem, po tym co nie raz widzia­łem, powi­nie­nem gło­sić tezę by zarzu­cić w ogó­le infor­ma­ty­kę i zwol­nić wszyst­kich pro­gra­mi­stów – to nie ja wymy­śli­łem poję­cie kry­zys opro­gra­mo­wa­nia”… ale to głu­pie więc tak nie powiem.

  5. Piotr Tokarski 28 czerwca 2011 at 20:06

    1. Bądźmy pre­cy­zyj­ni w mani­fe­ście Agile nie przy­pad­ko­wo uży­to sło­wa ponad (eng. over) a nie zamiast (eng. instead).
    2. Manifest agi­le jest napi­sa­ny z punk­tu widze­nia dostaw­cy oprogramowania 

    Jako programista/projektant ceniam to tak że pisa­nie na pod­sta­wie kiep­skie­go pro­jek­tu jest nie­przy­jem­ne , róż­ni­ca tyl­ko taka że jeśli pro­jekt jest wła­sny zaczy­na prze­szka­dzać dopie­ro po pew­nym czasie .

    • Jarek Żeliński 28 czerwca 2011 at 22:30

      Witam
      1. czy­li ogra­ni­cze­nie cza­su (a podob­no zawsze go za mało w pro­jek­tach) zaowo­cu­je rezy­gna­cją z projektowania/dokumentowania, moim zda­niem uczciw­sze jest powie­dze­nie klien­to­wi, że na coś jest po pro­tu za mało czasu…
      2. zga­dzam się w 100%, ale czy to uspra­wie­dli­wia dostawcę?
      Prawdą jest, że pisa­nie cze­go­kol­wiek na bazie kiep­skie­go pro­jek­tu jest fru­stru­ją­ce, dla­te­go nie raz sły­szę narze­ka­nia (słusz­ne) tak­że na analityków-projektantów…;)

  6. Jarosław Żeliński 7 lutego 2019 at 17:27

    Dzisiaj jest 7 luty 2019, nic się nie zmie­ni­ło… kil­ka drob­nych popra­wek w arty­ku­le… Pan Lipiński” (patrz powyż­sza dys­ku­sja) nadal domi­nu­je u developerów.…

Dodaj komentarz

Twój adres email nie zostanie opublikowany

Komentuj i zadawaj pytania autorowi.

Identyfikator *
E-mail *
Witryna internetowa

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