Czego moglibyśmy się nauczyć od naukowców?

Nie jest tu, na moim blo­gu, tajem­ni­cą, że pre­fe­ru­ję nauko­we meto­dy ana­li­zy. Nie cho­dzi o gma­twa­nie świa­ta” a o pro­ste a sku­tecz­ne podej­ście. Codzienna lek­tu­ra blo­gów zapro­wa­dzi­ła mnie dziś na stro­ny pro­gra­mi­sty, któ­ry napisał:

Czego mogli­by­śmy się nauczyć od naukow­ców? A być może tego jak waż­ną rolę i jak bar­dzo cza­so- i kosz­to­chłon­ne jest samo pla­no­wa­nie eks­pe­ry­men­tu, jak waż­ne jest zro­zu­mie­nie czyn­ni­ków zewnętrz­nych któ­re mogą mieć wpływ na prze­bieg eks­pe­ry­men­tu. Być może war­to się zanu­rzyć w ten świat i spróbować.

Zapowiada się nie­źle. oso­bi­ście uwa­żam, że eks­pe­ry­ment jest gene­ral­nie tań­szy i bez­piecz­niej­szy od ćwi­czeń na żywym cie­le, te ostat­nie są zresz­tą nie raz wręcz zabro­nio­ne. Zanurzanie się w świat rze­czy­wi­sty” wiec nie raz jest moż­li­we tyl­ko raz: odda­ją goto­we roz­wią­za­nie (w zasa­dzie jak samo­lot, goto­wy jest obla­ty­wa­ny już z czło­wie­kiem na pokładzie).

Bardzo podo­ba mi się oso­bi­ście idea eks­pe­ry­men­tu. W moim, tak uwiel­bia­nym wąt­ku archi­tek­tu­ry, ana­li­zy biz­ne­so­wej i zarzą­dza­nia pro­jek­ta­mi cza­sa­mi zbyt czę­sto zawie­rza­my teo­riom, mani­fe­stom, wzo­rom i skom­pli­ko­wa­nym mecha­ni­zmom wyli­cza­nia popraw­no­ści zło­żo­no­ści wszech­świa­ta. Naukowcy w sytu­acji gdy zło­żo­ność pro­ble­mu unie­moż­li­wia jego roz­wią­za­nia meto­da­mi ana­li­tycz­ny­mi zwra­ca­ją się ku eks­pe­ry­men­to­wi”. Dlatego bła­gam was archi­tek­ci i ana­li­ty­cy, następ­nym razem gdy będzie­cie pró­bo­wa­li zapro­jek­to­wać zło­żo­ny sys­tem wyko­rzy­staj­cie siłę jaką daje eks­pe­ry­ment. Wszelkiej maści pro­to­ty­py”, testy” czy też Agile’owe spi­ke” są lep­sze niż UML’e, dia­gra­my, work­flo­w’y i rysu­necz­ki z pro­ce­sa­mi biz­ne­so­wy­mi. Programiści was polu­bią za cie­ka­we zada­nia, a wy będzie­cie się mogli pochwa­lić dzia­ła­ją­cy­mi systemami.

I tu zaczy­na­ją się scho­dy. Bo jeże­li rozu­miem pro­gra­mi­stów, że lubią się bawić na koszt klien­ta, to nie rozu­miem dla­cze­go od razu chcą latać na pro­to­ty­pach samo­lo­tów, gorzej, nie chcą cze­kać na pro­jekt i te śmiesz­ne rysun­ki tech­nicz­ne. Dlaczego inży­nier mecha­nik chce zaj­mo­wać się pro­jek­to­wa­niem tego jak ma wyglą­dać i latać samo­lot sko­ro jego rola i kom­pe­ten­cje to kon­stru­owa­nie a nie np. bada­nie satys­fak­cji klien­ta z lotu na wygod­nym fotelu…

Jak mam sobie wyobra­zić two­rze­nie samo­lo­tu w posta­ci pod­sta­wia­nych na lot­ni­sko pasa­żer­skie kolej­nych pro­to­ty­pów? Czy każ­dy pro­jekt IT to samo­lo­ty? Tak! Tam pra­cu­ją ludzie, pła­cą za to i cier­pi ich biz­nes jak opro­gra­mo­wa­nie nie zadzia­ła od razu jak trzeba!

Czy pro­to­ty­py kodu są lep­sze o niż mode­le pro­ce­sów i pro­jek­tu UML? Ja zapy­tam: opra­co­wa­nie i prze­te­sto­wa­nie mapy pro­ste­go pro­ce­su, potem przy­pad­ku uży­cia, kawał­ka mode­lu dzie­dzi­ny i testo­wa­nie tego dia­gra­mem sekwen­cji to pra­ca dla mnie, jed­nej oso­by, na kart­ce papie­ru, koszt to jakieś np. 1000zł. Oddaje pro­dukt (pro­jekt) nie wyma­ga­ją­cy nicze­go poza imple­men­ta­cją. Czy za 1000zł ktoś posa­dzi czło­wie­ka lub ludzi, napi­sze i prze­te­stu­je kod kil­ku­na­stu klas plus dzie­siąt­ków tech­nicz­nych, mając do dys­po­zy­cji jakąś plat­for­mę by to uru­cho­mić? I klient odbie­rze i uży­je to za pierw­szym razem?

Naukowe meto­dy, szcze­gól­nie te zda­rze­nio­we, pole­ga­ją­ce na sta­wia­niu tezy i pró­bie jej fal­sy­fi­ka­cji, to po pierw­sze sku­tecz­ne meto­dy, po dru­gie nie­in­wa­zyj­ne, po trze­cie rela­tyw­nie tanie (w rela­cji do pra­cy na żywym ciele/kodzie). Po co work­flow? Po to by prze­te­sto­wać, czy to co opo­wia­da nie­udol­nie i mozol­nie klient jest logicz­ne, jest praw­dą (tak!). Przetestowany pro­ces biz­ne­so­wy to nic inne­go jak makie­ta, dobry plan mia­sta do pla­no­wa­nia wyciecz­ki. UML? Cóż, moż­na wpu­ścić tabun mura­rzy na budo­wę bez pro­jek­tu archi­tek­to­nicz­ne­go, i meto­dą pro­to­ty­py”, testy” czy też Agile’owe spi­ke” posta­wią wie­żo­wiec ale nie jestem pewien czy to będzie tanio i nie wiem czy odwa­żył bym bym się w tym czymś zamiesz­kać. Po dru­gie zapy­tam: sko­ro te UML’e głu­pie to dla­cze­go książ­ki o wzor­cach pro­jek­to­wych i archi­tek­tu­rze sys­te­mów są nimi nafaszerowane?

Czego jesz­cze może­my się nauczyć od naukow­ców? A to że Dobry eks­pe­ry­ment musi być jak naj­prost­szy w wyko­na­niu i jed­no­cze­śnie dawać jak naj­bar­dziej jed­no­znacz­ną odpo­wiedź potwier­dza­ją­cą lub fal­sy­fi­ku­ją­cą daną teo­rię” (Wikipedia). Czyli Keep Your Tests Simple. (źr. cyta­tów: pri​mi​ti​ve​.jog​ger​.pl.)

A tu pro­szę, same roz­sąd­ne rze­czy (może dla­te­go że prze­pi­sa­ne z WIKI). Oczywiście: model pro­ce­su dobry, to pro­sty model, jego testo­wa­nie tak­że nie jest skom­pli­ko­wa­ne, a odpo­wiedź zero­je­dyn­ko­wa: dzia­ła albo nie działa.

Autor pisze na poczat­ku swo­je­go arty­ku­łu, że stwo­rze­nie pro­gra­mu to teza:

  1. przy zało­żo­nym cza­sie (t) oraz zało­żo­nym budże­cie (b) dostar­czy­my sys­tem (S)
  2. któ­ry dane wej­ścio­we (i) prze­kształ­ci w dane wyj­ścio­we (o)

Haczyk tu tkwi, w tym, że więk­szość pro­gra­mi­stów rzu­ca się na takie coś mimo, że nie dys­po­nu­je opi­sem czym jest (S). Bo nie są nim ani przy­pad­ki uży­cia ani user sto­ry anie notat­ki z sesji JAD. Po dru­gie czym jest ten­że sys­tem”? Bez jego pro­jek­tu nie da się okre­ślić ani ter­mi­nu ani budże­tu ani cza­su wyko­na­nia. To tak jak by ktoś napi­sał, że przy zało­żo­nym cza­sie i budże­cie zbu­du­je hotel wie­dząc jedy­nie ilu gości będzie musiał przy­jąć w cią­gu doby”.

Podejrzewam, że autor po pro­stu miał tego pecha, że dosta­wał jakieś kiep­skie ana­li­zy i pro­jek­ty, beł­kot, któ­re­go nie­ste­ty jest masa. Wtedy jak naj­bar­dziej ma pra­wo mieć rację (tro­chę). ale co dalej znaj­du­je­my na tym blogu:

Estymaty pro­jek­tów przy zasto­so­wa­niu zasa­dy 200% bufo­ru bez­pie­czeń­stwa nadal roz­pa­da­ją się jak zam­ki z pia­sku. Jak to kole­ga ujął pró­bu­jąc zamknąć defi­ni­cję Agile w jed­nym zda­niu klient nadal nie wie co chce, a my dostar­czy­my co mamy” (źr. Slow coding).

Proponuje mu albo jego kie­row­ni­kom pro­jek­tów (w sumie to nie wiem kogo tu oce­niać…) więc poczytać:

  1. opis ana­li­zy meto­dą nauko­wą: Analiza sys­te­mo­wa – ana­li­za biz­ne­so­wa i pro­jek­to­wa­nie systemów
  2. oraz IIBA czy­li jak to robią…

oraz: książ­ki Fowlera, Yourdona, Evansa czy tak zwa­ne­go Gangu Czworga.

Nie są to może jakieś wypa­sio­ne pro­jek­ty ale co do zasa­dy są to owe work­flow­ły i jueme­le do zapo­zna­nia się…:

Na zakończenie

Co mogę po tym powie­dzieć? Państwo sami zde­cy­duj­cie co woli­cie w swo­ich pro­jek­tach: 200% narzu­tu na swo­bod­ne podej­ście dostaw­ców opro­ga­ra­mo­wa­nia czy 20% na dobre­go ana­li­ty­ka pro­jek­tan­ta i dru­gie 20% jakie uczci­wy dostaw­ca doda mając dobry projekt …

Autor napi­sał swo­ją odpo­wiedź i dobrze, bo pole­mi­ka kształci:

http://​pri​mi​ti​ve​.jog​ger​.pl/​2​0​1​1​/​0​5​/​2​3​/​p​o​r​z​a​d​n​i​e​-​m​i​-​s​i​e​-​o​b​e​r​w​a​lo/

Autor napi­sał: Po dogłęb­nym zapo­zna­niu się z pra­ca­mi auto­ra dzie­lę się moimi prze­my­śle­nia­mi i cze­kam na rów­nie cię­tą ripo­stę „, któ­rą napi­sa­łem i nie­zbyt cię­tą (nie to było celem) szko­da jed­nak, że ten­że autor nie tyl­ko sto­su­je tanie ery­stycz­ne chwy­ty w swo­ich wypo­wie­dziach (np. przy­rów­ny­wa­nie praw­dzi­wo­ści swo­ich tez do pew­no­ści odkry­cia Kopernika: posta­no­wi­łem trwać przy mej teo­rii iż to jed­nak Ziemia krą­ży wokół Słońca” co jest dość duża zaro­zu­mia­ło­ścią, bo jeśli w kwe­stii ukła­du sło­necz­ne­go fak­tycz­nie nie mamy wąt­pli­wo­ści to moż­na je mieć w kwe­stii wywo­dów tegoż auto­ra), a w koń­cu usu­nął ze swo­jej stro­ny (dla­cze­go?) po pew­nym cza­sie moją krót­ką odpo­wiedź i link do jej peł­nej wer­sji na tym blogu:

https://it-consulting.pl//index.php/2011/05/24/polemika/

jak to niektórzy robią w Ameryce”">

IIBA czyli jak to niektórzy robią w Ameryce”

O szkoleniu

Ameryka przy­je­cha­ła do nas, [[Darryl Booker]], któ­ry 20 lat (poza pra­cą na uczel­ni) pra­cu­je jako kon­sul­tant, ana­li­tyk biz­ne­so­wy był tre­ne­rem na szko­le­niu, któ­re mam wła­śnie za sobą.

Z jed­nej stro­ny trzy dni pozna­wa­łem coś do cze­go sam docho­dzi­łem, co w zasa­dzie znam i potra­fię, jed­nak z dru­giej stro­ny szko­le­nia pro­wa­dzo­ne przez ludzi z dużym doświad­cze­niem zawsze mają dwa aspek­ty: po pierw­sze począt­ku­ją­cy dowie­dzą się jak nale­ży pra­co­wać i co powin­no pod­czas tej pra­cy powsta­wać po dru­gie dla mnie (dla każ­de­go z dużym doświad­cze­niem) bar­dzo cen­ne są kon­tak­ty z inny­mi ludź­mi z bran­ży, bo porów­na­nie wie­dzy, wymia­na doświad­czeń oraz dys­ku­sje pozwa­la­ją porów­nać swo­je doko­na­nia z cudzy­mi. W wie­lu pro­jek­tach i na kon­fe­ren­cjach sły­szę, że wymy­ślam jakieś nie­stwo­rzo­ne rze­czy bo nikt tak nie robi (mode­lo­wa­nie, testo­wa­nie wyma­gań, pro­of-of-con­cept, itp.). Otóż nie praw­da, po pro­tu bar­dzo wie­lu ludzi (w bar­dzo wie­lu pro­jek­tach) nie zarzą­dza ryzy­kiem przyj­mu­jąc gene­ral­nie opty­mi­stycz­ne wer­sje wydarzeń.

Czego się nauczy­łem na tym szko­le­niu? Że war­to pla­no­wać, pro­jek­to­wać i ana­li­zo­wać bo wte­dy pro­jek­ty są prze­wi­dy­wal­ne zamiast być loterią.

Jak to się robi? Od kil­ku lat pro­mu­ję ideę nauko­wej ana­li­zy sys­te­mo­wej: opis celu, opis pro­ble­mu, sta­wia­nie hipo­tez, mode­le i sce­na­riu­sze, reko­men­da­cje i pro­jekt. Nie musi to być i nie jest żaden tak zwa­ny wodo­spad” pro­jek­to­wy ([[wat­ter fall model IT]]), zwin­ność tu pole­ga na reago­wa­niu na każ­dym eta­pie pro­jek­tu na pro­ble­my i wpro­wa­dza­nie zmian, pro­dukt pro­jek­tu jest zawsze mode­lo­wa­ny i testo­wa­ny na każ­dym eta­pie. W efek­cie spe­cy­fi­ka­cja tego co ma powstać jest kom­plet­na, nie wyma­ga pro­to­ty­po­wa­nia” na żywym cie­le (powsta­je kod dla klien­ta, któ­ry zgła­sza uwa­gi do tego co zoba­czy) a zama­wia­ją­cy wie co dosta­nie w dniu zamó­wie­nia i wie ile to będzie kosztowało.

Mity dostawców oprogramowania

Dostawcy goto­we­go opro­gra­mo­wa­nia szer­mu­ją tezą, że oszczę­dzą Wam kosz­tów ana­li­zy bo mają wie­dzę i doświad­cze­nie zawar­te” w swo­im pro­duk­cie. Ryzyko, że wyma­ga­nia biz­ne­so­we zosta­ną źle zde­fi­nio­wa­ne i ryzy­ko, że dostar­czo­ny pro­dukt nie speł­nia tych wyma­gań jest igno­ro­wa­ne (klient zamó­wił to klient dosta­nie, czy to będzie mu potem potrzeb­ne to nie nasz problem).

Developerzy ofe­ru­ją­cy wyko­na­nie dedy­ko­wa­ne­go opro­gra­mo­wa­nia bez ana­li­zy wyma­gań a np. tyl­ko z pomo­cą tak zwa­nych sesji JAD (ang. [[Joint appli­ca­tion design]]) i kolej­nych pro­to­ty­pów, w ogó­le nie bio­rą pod uwa­gę ryzy­ka nie­kom­plet­no­ści tak okre­ślo­nych wyma­gań ani bra­ku ich spój­no­ści (zna­ny pro­blem odkry­wa­nia wyma­gań w trak­cie wdro­że­nia). Klient powie co chce i będzie OK a opro­gra­mo­wa­nie i tak ma być bo każ­dy ma.

A ryzy­ko, że ana­li­za potrzeb i pro­jekt tego co ma powstać, wyko­na­na przez przy­szłe­go wyko­naw­cę, będzie tak na praw­dę tyl­ko spe­cy­fi­ka­cję tyl­ko tego co dostaw­ca potra­fi wykonać?

Dlaczego tak często projekty łamią zasady rozsądku i zarządzania ryzykiem?

Wczoraj na sali i w kulu­arach padły mię­dzy inny­mi takie odpowiedzi:

  1. dostaw­cy opro­gra­mo­wa­nia bar­dzo czę­sto nie potra­fią takiej ana­li­zy wyko­nać bo nie mają wyma­ga­nych kom­pe­ten­cji, ale potra­fią pro­gra­mo­wać i tyl­ko na to się godzą.

  2. dostaw­cy opro­gra­mo­wa­nia dosko­na­le wie­dzą, że ist­nie­je ryzy­ko że ich pro­dukt nie speł­nia wyma­gań więc bar­dzo czę­sto nie dopusz­cza­ją do takich ana­liz for­su­jąc od razu wdro­że­nie (wręcz tępią w pro­jek­tach zewnętrz­nych analityków!).

  3. klien­ci mają sta­le do czy­nie­nia z dostaw­ca­mi a bar­dzo rzad­ko z nie­za­leż­ny­mi ana­li­ty­ka­mi i bar­dzo czę­sto przyj­mu­ją wia­rę w to co mówią dostawcy.

  4. nie ist­nie­ją nie­za­leż­ni analitycy.

Na ostat­nie odpo­wiem tak: jest ich (nas) mało… ale to łatwo spraw­dzić: popro­sić o refe­ren­cje i zapy­tać co reko­men­do­wa­li. Dobry ana­li­tyk nigdy nie reko­men­du­je imple­men­ta­cji a tyl­ko two­rzy spe­cy­fi­ka­cję biz­ne­so­wą. Po trze­cie, war­to anga­żo­wać ludzi zna­nych w bran­ży z tego, że nie są na pro­wi­zjach u producentów.

Agile…

Wielu z deve­lo­pe­rów idzie dalej: nie trze­ba ana­li­zy, trze­ba od razu zacząć two­rzyć roz­wią­za­nie, [[Agile Manifesto]] – hasło prze­wod­nie tej meto­dy jasno mówi, że cho­dzi o to by pro­gra­mo­wać a nie o to by coś doku­men­to­wać, szko­da cza­su na głu­po­ty (zawsze tak okre­ślo­ne meto­dy zwin­ne koja­rzy­ły mi się z home­opa­tią: dostaw­cy obie­cu­ją coś nie wie­dząc co na praw­dę boli i nie bio­rą żad­nej odpo­wie­dzial­no­ści za skut­ki, co cie­ka­we żad­ne dane nie potwier­dza­ją sku­tecz­no­ści tych metod).

Inna cie­ka­wost­ką metod Agile jest to, że pro­jekt koń­czy się nie wte­dy gdy powsta­nie to co zamó­wił (a raczej wyobra­żał sobie klient bo nic nie zamó­wił, w koń­cu nie powsta­ła żad­na spe­cy­fi­ka­cja) tyl­ko to co powsta­nie dopó­ki nie skoń­czy się budżet. Co powsta­nie? Zobaczymy jak skończymy.

IIBA czyli czym jest ta Analiza Biznesowa

Od pew­ne­go cza­su IIBA pro­mu­je idee Analizy Biznesowej, któ­ra jest poważ­nym zagro­że­niem dla opi­sa­nych wyżej dostaw­ców. Dlaczego? Bo pro­mu­je two­rze­nie doku­men­tów pozwa­la­ją­cych naj­pierw dokład­nie wyspe­cy­fi­ko­wać to co jest potrzeb­ne (czy­taj pomo­że w biz­ne­sie!), potem dopie­ro zosta­je to zamó­wio­ne i dostar­czo­ne lub wykonane.

Nie da się tak? A wła­śnie, że się da. Czy to kosz­tow­ne? Zapytam tak? Co lep­sze nie­przy­dat­ny pro­dukt za 100tys. zł czy przy­dat­ny za 120tys.? Co lep­sze, pro­jekt pla­no­wa­ny na pól roku za 100tys. i wyko­na­ny w ter­mi­nie czy obie­ca­ny za 50tys. w kwar­tał a dostar­czo­ny za 250 tys, po dwóch latach?

To się nazy­wa RYZYKO a ana­li­za i pro­jek­to­wa­nie to zarzą­dza­nie tym ryzykiem!

Co oferuję jako analityk a IIBA zaleca

Porządny pro­jekt analityczny:

[sin­gle­pic id=119 w=533 h=533 float=center]

Kończący się spe­cy­fi­ka­cją wyma­gań (IIBA nazy­wa to Dokument Wymagań Biznesowych):

[sin­gle­pic id=122 w=533 h=533 float=center]

A teraz to co mogę pole­cić: szko­le­nie Analiza Biznesowa w MT&DC. Dostawców nauczy pra­cy a klien­tów wia­ry, że moż­na lepiej. Dlaczego tak pole­cam to szko­le­nie? Bo jego koszt to nic w porów­na­niu do strat jakie gene­ru­je źle zapla­no­wa­ny pro­jekt a któ­rych moż­na unik­nąć lub znacz­nie zmi­ni­ma­li­zo­wać. Nawet jeśli ktoś po szko­le­niu nie będzie potra­fił sam od razu takiej ana­li­zy wyko­nać (bo raczej po trzech dnia nie) to na pew­no będzie w sta­nie oce­nić to co pro­po­nu­ją dostaw­cy a potem zarzą­dzać takim pro­jek­tem. Potem z cza­sem sam (lub na kolej­nych szko­le­niach) nauczy się dobrej ana­li­zy biznesowej.

Na koniec naj­waż­niej­sze, para­fra­zu­jąc stwier­dze­nie Daryll’a: ana­li­ty­kom, któ­rych jedy­nym narzę­dziem pra­cy jest pakiet MS Office, w szcze­gól­no­ści Excel i PowerPoint, z góry dzię­ku­je­my (on uży­wa pro­fe­sjo­nal­nych narzę­dzi CASE i pakie­tów do zarzą­dza­nia projektami).

Inny bar­dzo cie­ka­wy arty­kuł o wyma­ga­niach: Jak zawa­lić pro­jekt infor­ma­tycz­ny. Analiza wymagań.

Co wybrać czyli cykl życia projektu tworzenia oprogramowania

Zbiegły się dwa fak­ty: gorą­ca dys­ku­sja na forum na temat umie­jęt­no­ści pro­gra­mi­stów i przy oka­zji ich roli w pro­ce­sie wytwa­rza­nia opro­gra­mo­wa­nia oraz prze­sył­ka z kolej­ną nową książ­ką na moja pół­kę. Ale po kolei. Najpierw fazy cyklu wytwa­rza­nia opro­gra­mo­wa­nia a potem kil­ka uwag. Zakupiona książ­ka opi­su­je całość, ja tu sku­pie się na jej wstę­pie. Nie będę jej tłu­ma­czył a jedy­nie opi­sze idee. Zwrócę tak­że uwa­gę na pew­ne aspek­ty zwią­za­ne z dostar­cza­niem goto­we­go opro­gra­mo­wa­nia, np. sys­te­mów typu ERP lub ich komponentów.

Fazy procesu tworzenia oprogramowania

Cykl życia pro­jek­tu two­rze­nia opro­gra­mo­wa­nia ma czte­ry klu­czo­we fazy:

  1. Planowanie
  2. Analiza
  3. Projektowanie
  4. Implementacja

Nie nale­ży tego mylić z faza­mi cyklu życia opro­gra­mo­wa­nia, doszły by do powyż­szych jesz­cze: wdro­że­nie, utrzy­ma­nie oraz wyłączenie.

Planowanie

Jest to klu­czo­wa faza w pro­jek­cie. Na tym eta­pie nale­ży sobie odpo­wie­dzieć po co two­rzy­my to opro­gra­mo­wa­nie oraz jak ono powsta­nie. Na tym eta­pie są (powin­ny być) zna­ne wyni­ki ana­li­zy biz­ne­so­wej i stu­dium wyko­ny­wal­no­ści. Innymi sło­wy powin­na być pod­ję­ta decy­zja, że opro­gra­mo­wa­nie ma powstać. Tu usta­la się: czy potra­fi­my to zro­bić, czy pro­jekt ma war­to­ści biz­ne­so­we i jakie, czy będzie moż­li­we uży­cie opro­gra­mo­wa­nia jeśli powsta­nie (np. czy będzie moż­li­we jest wdro­że­nie, bo to nie jest takie oczywiste).

Kolejny krok to ini­cja­cja pro­jek­tu, w szcze­gól­no­ści opra­co­wa­nie har­mo­no­gra­mu. Rozpoczyna się pro­ces zarzą­dza­nia projektem.

Analiza

Na tym eta­pie usta­la się kto będzie uży­wał sys­te­mu, co sys­tem ma robić, oraz gdziekie­dy będzie uży­wa­ny. To tu ma miej­sce ana­li­za biz­ne­so­wa i ana­li­za wyma­gań. Na tym eta­pie sys­tem zosta­je opi­sa­ny wyma­ga­nia­mi jako czar­na skrzyn­ka. Jest to tak­że pierw­sza faza pro­jek­to­wa­nia, jej pro­duk­tem może być model przy­pad­ków użycia.

Projektowanie

To pierw­sza decy­zja o tym, jak sys­tem ma to (wyma­ga­nia użyt­kow­ni­ka) robić. Tu powsta­je kon­cep­cja wewnętrz­nej logi­ki sys­te­mu, jego archi­tek­tu­ra, inter­fej­sy (w tym użyt­kow­ni­ka). Obecnie sto­su­je się meto­dy obiek­to­we, więc pro­jekt czę­sto sta­no­wi abs­trak­cje, dość dokład­na jed­nak, przy­szłe­go sys­te­mu. Abstrakcja ta jest nie­za­leż­na od meto­dy imple­men­ta­cji jed­nak musi (powin­na) sobą sta­no­wić pro­jekt w obiek­to­wym paradygmacie.

Implementacja

To koń­co­wa faza pro­ce­su two­rze­nia opro­gra­mo­wa­nia. W ramach niej powsta­ją pro­jekt imple­men­ta­cji i kod, insta­la­cja i testy, opra­co­wy­wa­ny jest plan pozo­sta­łych ele­men­tów cyklu życia sys­te­mu to jest plan wspar­cia i zarzą­dza­nia oraz rozwoju.

Metodologie tworzenia oprogramowania

Opisane pokrót­ce fazy pro­ce­su two­rze­nia mogą być uło­żo­ne na kil­ka spo­so­bów. Uznane i opi­sa­ne w lite­ra­tu­rze typo­we meto­do­lo­gie moż­na podzie­lić na trzy grupy:

  1. struk­tu­ral­ne (meto­dy wodo­spa­do­wa, rów­no­le­gła, etapowa)
  2. szyb­kie meto­dy (rapid, meto­da eta­po­wa, pro­to­ty­po­wa­nie, odrzu­ca­ne prototypy)
  3. zwin­ne (agi­le, pro­gra­mo­wa­nie ekstremalne)

W ramach każ­dej z tych grup moż­na wyróż­nić jed­ną lub kil­ka sto­so­wa­nych meto­do­lo­gii (jak powyżej).

Metodyka wodospadowa

Najstarsza meto­dy­ka wytwa­rza­nia opro­gra­mo­wa­nia. Opisane czte­ry fazy two­rze­nia reali­zo­wa­ne są sze­re­go­wo, jed­na po drugiej.

1. Waterfall

Każda faza koń­czy się swo­im pro­duk­tem (kolej­nym ele­men­tem doku­men­ta­cji). Proces kon­ty­nu­owa­ny na bazie pier­wot­ne­go szcze­gó­ło­we­go pla­nu (bez korekt lub z nie­wiel­ki­mi korek­ta­mi), prak­tycz­nie zakła­da się, że pro­dukt każ­dej fazy jest osta­tecz­ną wer­sją doku­men­tu. System powsta­je jako efekt linio­we­go procesu.

Proces jest dość dłu­go­trwa­ły, wyma­ga bar­dzo szcze­gó­ło­we­go pla­no­wa­nia w pierw­szej fazie, jest bar­dzo kosz­tow­ny: kosz­tow­ne jest pla­no­wa­nie i kosz­tow­ne są pomył­ki. Można uznać, że od tej pro­stej wer­sji meto­do­lo­gii się odcho­dzi. Metodologia ta cie­szy się jed­nak opi­nią dobrze zarządzalnej.

Metodologia bazu­je na meto­dach struk­tu­ral­nych ana­li­zy: budo­wa mode­lu sys­te­mu zorien­to­wa­ne­go na dane. Model danych jako fun­da­ment sys­te­mu czy­ni go prak­tycz­nie nie­zmien­nym pod­czas całe­go pro­ce­su. System pro­jek­to­wa­ny jest jako układ sys­tem-model danych co wyma­ga bar­dzo żmud­nej pra­cy na eta­pie ana­li­zy i pro­jek­to­wa­nia. Metodyka ta wyma­ga tak­że wyko­na­nia peł­ne­go pro­jek­tu sys­te­mu przed roz­po­czę­ciem jego implementacji.

Zalety meto­dy­ki: wyma­ga­nia muszą być dokład­nie opra­co­wa­ne na dłu­go zanim zacznie się pro­ces imple­men­ta­cji, mini­ma­li­za­cja zmian wyma­gań w trak­cie pro­ce­su implementacji.

Wady meto­dy­ki: dłu­gi pro­ces wytwa­rza­nia (znacz­nie dłuż­szy niż zacho­dzą­ce zmia­ny w oto­cze­niu biz­ne­so­wym), wyma­ga bar­dzo dużej (set­ki, bywa tysią­ce stron) doku­men­ta­cji, wpro­wa­dza­nie zmian wyma­ga cof­nię­cia się prak­tycz­nie do począt­ku procesu.

Metodyka równoległa

2-parallel

W tej wer­sji mody­fi­ka­cja typo­we­go wodo­spa­du pole­ga na pod­ję­ciu pró­by skró­ce­nia całe­go pro­ce­su poprzez podział wyma­gań (wyni­ków ana­li­zy) na odręb­ne quasi-nie­za­leż­ne pod­sys­te­my. Wymaga to dwóch dodat­ko­wych eta­pów: wstęp­ne­go pro­jek­tu by podzie­lić sys­tem na pod­sys­te­my oraz inte­gra­cji na zakoń­cze­nie całości.

Korzyścią jakę przy­no­si podział na pod­sys­te­my jest szyb­sze dostar­cze­nie pro­duk­tu jed­nak pro­jekt sta­je się jesz­cze kosz­tow­niej­szy. Nadal pozo­sta­je ryzy­ko nie­od­wra­cal­no­ści i potrze­by cze­ka­nia na pro­dukt w wer­sji ostatecznej.

Zalety i Wady jak w meto­dy­ce wodo­spa­do­wej, osią­gnię­to pew­ne skró­ce­nie cza­su dostar­cze­nia pro­duk­tu jed­nak kosz­tem dodat­ko­wej doku­men­ta­cji. Proces nadal jest prak­tycz­nie nieodwracalny.

Metodyka etapowa

Jest to pierw­sza pró­ba zamia­ny potrze­by opra­co­wa­nia kom­plet­nej funk­cjo­nal­no­ści na samym począt­ku i szyb­sze­go ([[RAD]]) dostar­cze­nia pro­duk­tu, kosz­tem ogra­ni­czo­nej począt­ko­wo funk­cjo­nal­no­ści. Jest to tak­że pierw­sza meto­dy­ka zakła­da­ją­ca uży­cia opro­gra­mo­wa­nia wspo­ma­ga­ją­ce­go ana­li­zę i pro­jek­to­wa­nie kla­sy [[CASE]].

3. Phased

Jak widać powsta­ją kolej­ne wer­sje sys­te­mu. Pierwsza to mini­mal­na przy­dat­na do pra­cy (użyt­kow­ni­ko­wi) wer­sja, kolej­ne wer­sje to przy­bli­że­nia wer­sji ostatecznej.

Zaletą tego podej­ścia jest skró­ce­nie cza­su ocze­ki­wa­nia na pro­dukt, użyt­kow­nik otrzy­mu­je sto­sun­ko­wo szyb­ko pro­dukt, zaczy­na on zara­biać na sie­bie. Kolejne wer­sje imple­men­tu­ją kolej­ne wyma­ga­nia. Jest to pierw­sza pró­ba napra­wy wad sys­te­mu wodospadowego.

Wadą jest nadal potrze­ba począt­ko­we­go opra­co­wa­nia wszyst­kich wyma­gań w wer­sji osta­tecz­nej, wpro­wa­dza­nie zmian wyma­ga cofa­nia się do począt­ku pro­ce­su gdyż cały czas cią­ży model ana­li­zy struk­tu­ral­nej zamra­ża­ją­cej model sys­te­mu w mode­lu danych.

Wszystkie trzy opi­sa­ne meto­dy mają więc tę wadę, że wszel­kie zmia­ny wyma­gań lub odkry­te wyma­ga­nia w trak­cie trwa­nia pro­ce­su (nie­wy­kry­te na eta­pie ana­li­zy, źle opra­co­wa­ne) sil­nie pod­no­szą kosz­ty gdyż cofa­ją pro­jekt nie­mal­że do początku.

Metodyka prototypowania

4. Prototyping

Po eta­pie pla­no­wa­nia ma miej­sce rów­no­le­gły pro­ces ana­li­zy, pro­jek­to­wa­nia i imple­men­ta­cji. Analiza w tym przy­pad­ku jest czymś w rodza­ju roz­po­zna­nia bojem. W mia­rę trwa­nia ana­li­zy od razu powsta­je pro­jekt i imple­men­ta­cja tego co już pozna­no. Szybko powsta­je pro­to­typ, tak zwa­ny szyb­ki i brud­ny pro­gram, któ­ry reali­zu­je pierw­sze pozna­ne wyma­ga­nia użyt­kow­ni­ka jed­nak dale­ko mu do opty­mal­no­ści i jako­ści. Sponsor pro­jek­tu lub użyt­kow­nik zgła­sza zmia­ny, któ­ry są nano­szo­ne na tym pro­to­ty­pie. Po uzna­niu, że wyma­ga­nia zre­ali­zo­wa­no pro­to­typ, uzu­peł­nio­ny o wyma­ga­ne cechy, sta­je się doce­lo­wym produktem.

Zaletą tej meto­do­lo­gii jest bar­dzo szyb­ki czas dostar­cze­nie naj­waż­niej­szych funk­cjo­nal­niej, wyma­ga­nia są wery­fi­ko­wa­ne na bieżąco.

Wada, poważ­ną, tej meto­do­lo­gii jest to, że osta­tecz­ny pro­dukt jest zlep­kiem pośred­nich pomy­słów, brak ana­li­zy cało­ści (pro­dukt powsta­je nie­mal­że ad-hoc) powo­du­je, że poja­wie­nie się w przy­szło­ści nowych potrzeb czę­sto wyma­ga prze­pro­jek­to­wa­nia znacz­nej czę­ści, a nawet cało­ści systemu.

Metodyka z prototypem odrzucanym

5. Throwaway prototyping

Ta meto­da, bazu­jąc na poprzed­niej, zakła­da two­rze­nie pro­to­ty­pu tyl­ko jak narzę­dzia ana­li­tycz­ne­go. Celem two­rze­nia pro­to­ty­pu nie jest tu roz­po­czę­cie two­rze­nia doce­lo­we­go sys­te­mu a testo­wa­nie hipo­te­zy jaką jest pro­po­zy­cje projektowa.

W tej wer­sji po eta­pie pla­no­wa­nia mamy ana­li­zę, któ­rej celem jest opra­co­wa­nie wyma­gań. Następnie rów­no­le­gły pro­ces ana­li­zy, pro­jek­to­wa­nia i imple­men­ta­cji. Tu ana­li­za pole­ga na zro­zu­mie­niu wyma­gań, imple­men­ta­cją jest jed­nak bar­dzo uprosz­czo­ny model sys­te­mu (jego kon­kret­ne cechy np. tyl­ko inter­fejs użyt­kow­ni­ka). Model ten (np. same moc­ku­py ekra­nów, ele­men­ty logi­ki) jest testo­wa­ny. testy tu słu­żą wyłącz­nie do oce­ny przy­dat­no­ści pomy­słów na eta­pie ana­li­zy i pro­jek­to­wa­nia. testo­wa­ne mode­le nie są ele­men­ta­mi przy­szłe­go sys­te­mu (nie są dalej uży­wa­ne, są wyrzu­ca­ne).

Jak widać, pro­ces ma trzy wyraź­ne fazy:

  1. Planowanie i analiza
  2. Analiza i projektowanie
  3. Projektowanie i implementacja

W pew­nym sen­sie doku­men­ta­cja prze­te­sto­wa­ne­go pro­to­ty­pu sta­je doku­men­ta­cją wyma­gań prze­ka­za­na do osta­tecz­nej zapro­jek­to­wa­nia osta­tecz­nej implementacji.

Wadą meto­dy jest potrze­ba two­rze­nia pro­to­ty­pów i testo­wa­nia każ­dej kon­cep­cji (wyma­ga cza­su i kompetencji).

Zaletą, bar­dzo dużą, tej meto­dy jest to, że pro­ste pro­to­ty­py, któ­re nie są kodem imple­men­ta­cji, są rela­tyw­nie tanie w przy­go­to­wa­niu (mniej pra­co­chłon­ne niż kod pro­to­ty­pu poprzed­niej meto­dy). To pierw­sza meto­dy­ka zakła­da­ją­ca powsta­nie pro­to­ty­pu jako testo­wa­nej hipo­te­zy (wstęp­nej decy­zji pro­jek­to­wej). Biorąc pod uwa­gę kosz­tow­ne odkry­wa­nie wyma­gań i wpro­wa­dza­nie zmian w poprzed­nich meto­dy­kach, ta niwe­lu­je ten pro­blem. Jak widać na dia­gra­mie, testo­wa­nie pro­to­ty­pów ma miej­sce na eta­pie ana­li­zy i pro­jek­to­wa­nia. Do imple­men­ta­cji kie­ro­wa­ny jest prze­te­sto­wa­ny pro­jekt. Wersja osta­tecz­na nie zawie­ra więc w sobie baga­żu ad-hoc wpro­wa­dza­nych zmian – pro­to­ty­py są odrzu­ca­ne (nie są ele­men­ta­mi doce­lo­we­go sys­te­mu). Można wiec bez pro­ble­mu zapro­jek­to­wać sys­tem na bazie prze­te­sto­wa­nych i spój­nych wyma­gań w prze­my­śla­ny sposób.

Wadę, potrze­bę two­rze­nia pro­to­ty­pów, niwe­lu­je dziś ist­nie­nie narzę­dzi CASE, łatwo­ści two­rze­nia atrap sys­te­mu (pro­to­ty­pów) w gra­ficz­nych narzę­dziach pro­jek­to­wa­nia i imple­men­ta­cji. Technologie obiek­to­we tak­że bar­dzo uła­twia­ją ten pro­ces gdyż pro­jekt nie jest uza­leż­nio­ny od mode­lu danych, w 100% jest funk­cjo­nal­no­ścią (mode­le danych powsta­ją na koń­cu pro­ce­su w meto­dy­ka obiektowych).

Poważną wadą poprzed­nich meto­do­lo­gii jest bar­dzo kosz­tow­ny pro­ces reago­wa­nia na zmia­ny wyma­gań i nie­do­stat­ków same­go pro­jek­tu. Pamiętamy, że kom­plet­ny pro­jekt powsta­je na począt­ku pro­ce­su a jego testem jest tak na praw­dę dopie­ro final­ny pro­dukt. Praktyka poka­za­ła, że nawet w przy­pad­ku śred­nio zło­żo­nych pro­jek­tów opra­co­wa­nie sys­te­mu pozba­wio­ne­go wad (głow­nie logi­ki i danych) jest nie­mal­że niemożliwe.

Dlatego jesz­cze przed roz­po­czę­ciem imple­men­ta­cji two­rzo­ny jest i testo­wa­ny pro­to­typ sys­te­mu. Jest to dodat­ko­wy koszt jed­nak usu­wa­nie uste­rek pro­jek­tu na tym eta­pie jest o rząd a nawet dwa mniej kosz­tow­ne niż na eta­pie osta­tecz­nej imple­men­ta­cji. Jeżeli uzna­my fakt, że wer­sja wodo­spa­do­wa wią­że się nie­mal­że pew­no­ścią odkry­cia wad pro­jek­tu, koszt ten jest wart poniesienia.

Metodyka z odrzu­ca­nym pro­to­ty­pem (tak na praw­dę pro­to­ty­pa­mi) daje w efek­cie bar­dzo sta­bil­ny i speł­nia­ja­cy ocze­ki­wa­nia system.

Metodyki zwinne – XP

Na koniec meto­dy­ki zwin­ne zwa­ne czę­sto [[agi­le deve­lop­ment]]. Są to meto­dy­ki ukie­run­ko­wa­ne na pro­gra­mo­wa­nie (imple­men­ta­cję). Przykładami meto­dyk zwin­na są [[SCRUM]], XP ([[extre­me pro­gram­ming]]), DSDM ([[dyna­mic sys­tems deve­lop­ment method]]).

6. Programowanie ekstremalne

Powyżej dia­gram pro­ce­sy wytwa­rza­nia opro­gra­mo­wa­nia meto­dy­ką XP. Bazuje ona na komu­ni­ka­cji, pro­sto­cie, infor­ma­cji zwrot­nej (od klien­ta) i wza­jem­nym wspar­ciu zespo­łu. Zespołem są tu zarów­no pro­gra­mi­ści jak i przy­szły użyt­kow­nik (jed­nak nie spon­sor). Proces ten nasta­wio­ny jest na szyb­kie dostar­cze­nie pro­duk­tu moż­li­wie naj­prost­sza meto­dą. Bazuje na peł­nej inte­gra­cji zespo­łu, komu­ni­ka­cji, inte­rak­tyw­nym pro­ce­sie ana­li­zy i projektowania.

W meto­dy­kach zwin­nych pro­ces two­rze­nia opro­gra­mo­wa­nia bazu­je na tak zwa­nych [[user sto­ry]], są to opi­sy aktu­al­nej wie­dzy i potrzeb (wyma­gań) autor­stwa przy­szłych użyt­kow­ni­ków sys­te­mu. Proces ten nie ma wyróż­nio­nej fazy pla­no­wa­nia cało­ści, gdyż całość dzie­je się dynamicznie.

Dla małych sys­te­mów sil­nie zmo­ty­wo­wa­ny, zgra­ny i doświad­czo­ny zespół może pra­co­wać wydaj­nie. Jednakże jeśli pro­jekt nie jest mały, sku­tecz­ność tej meto­dy­ki pra­cy sta­je się wąt­pli­wa. Podzielenie pra­cy na więk­szy zespół, kon­tak­to­rów, wzma­ga potrze­bę pla­no­wa­nia i doku­men­to­wa­nia pro­jek­tu. Poleganie na opi­sach przy­szłych użyt­kow­ni­ków (nie mają­cych doświad­cze­nia w inży­nie­rii opro­gra­mo­wa­nia) dodat­ko­wo czy­ni takie pro­jek­tu ryzykownymi.

Projekty XP wyma­ga­ją ogrom­nej dys­cy­pli­ny, w prze­ciw­nym wypad­ku pro­wa­dzą do cha­osu. Konsekwencją bra­ku peł­nej począt­ko­wej ana­li­zy czę­sto jest sys­tem będą­cy zlep­kiem doraź­nych, nie­udo­ku­men­to­wa­nych kon­cep­cji, co przy więk­szych pro­jek­tach czy­ni tę meto­dę wyjąt­ko­wo ryzy­kow­ną. Tezy o doku­men­to­wa­niu w kodzie nie spraw­dza­ją się jeśli potrzeb­na jest wie­dza o kon­cep­cji, abs­trak­cyj­nym opi­sie idei systemu.

Prymat dzia­ła­ją­ce­go kodu nad jego doku­men­to­wa­niem bar­dzo czę­sto pro­wa­dzi do bar­dzo wyso­kich kosz­tów utrzy­ma­nia sys­te­mu w przyszłości.

Wadą meto­do­lo­gii jest wła­śnie jej zwin­ność, któ­ra jeśli spraw­dza się, to w nie­skom­pli­ko­wa­nych pro­jek­tach ser­wi­sów inter­ne­to­wych i opro­gra­mo­wa­niu biz­ne­so­wych o małej licz­bie wyma­gań rzę­du kil­ku. Jednak jeśli pro­jekt mie­ści sie w takich gra­ni­cach jest to bar­dzo dobry spo­sób na reali­zo­wa­nie pro­jek­tów o dużych rygo­rach czasowych.

Wybór właściwej metodologii

Wśród wymie­nio­nych każ­da ma wady i zale­ty, wybór naj­lep­szej dla dane­go pro­jek­tu nie jest pro­sty. Do wybo­ru nale­ży brać pod uwa­gę zna­ne cechy nad­cho­dzą­ce­go projektu.

Jasność wyma­gań użyt­kow­ni­ka. Często wyma­ga­nia nie są na począt­ku jasne, zro­zu­mia­łe, nie raz nie są nawet dobrze udo­ku­men­to­wa­ne. Pierwszym eta­pem pro­jek­tu jest nie raz tak na praw­dę dopie­ro odkry­cie i zro­zu­mie­nie celu przy­szłe­go użyt­kow­ni­ka. Tu przy­da­je się dobra ana­li­za biz­ne­so­wa i prototypowanie.

Innym typem utrud­nie­nia może być nowa tech­no­lo­gia. W takim przy­pad­ku dotych­cza­so­we doświad­cze­nie zespo­łu prze­sta­je być wystar­cza­ją­ce. W takich przy­pad­kach przy­da­je się wstęp­ne pro­jek­to­wa­nie i testo­wa­nie hipo­tez, naj­le­piej wraz z zatrud­nio­nym eks­per­tem zna­ją­cym tę tech­no­lo­gię. Prototypy odrzu­ca­ne dosko­na­le się spraw­dza­ją w takich przypadkach.

Złożone sys­te­my nie nada­ją się, z powo­du swej zło­żo­no­ści, do pra­cy na bazie intu­icji. Wymagają udo­ku­men­to­wa­nej ana­li­zy i pro­jek­to­wa­nia, testo­wa­nia, gdyż każ­da pomył­ka jest bar­dzo kosz­tow­na. Systemy tego typu z zało­że­nia mają dłu­gi cykl życia dla­te­go przy­szłe zarzą­dza­nie nim wyma­ga bar­dzo dobrze opra­co­wa­nej dokumentacji.

Systemy wyma­ga­ją­ce nie­za­wod­no­ści i sta­no­wią­ce (ich wadli­we dzia­ła­nie) duże ryzy­ko (biz­ne­so­we, zagro­że­nie życia) dla użyt­kow­ni­ka tak­że wyma­ga­ją bar­dzo dobre­go pla­no­wa­nia i testo­wa­nia (błąd w pro­gra­mie nie­sie za sobą ogrom­ne koszty).

Zdarza się, że kry­tycz­nym czyn­ni­kiem jest ogra­ni­czo­ny czas na wyko­na­nie (np. ogra­ni­czo­ny dostęp do zaso­bów) lub ści­śle okre­ślo­ny ter­min odda­nia pro­duk­tu do eks­plo­ata­cji. W obu tych przy­pad­kach pro­jekt już na eta­pie pla­no­wa­na musi być bar­dzo przewidywalny.

Poniżej zesta­wio­no opi­sa­ne meto­dy oraz cechy pro­jek­tów i czyn­ni­ki ogra­ni­cza­ją­ce ich swobodę.

7-zestawienie-metod

(powyż­szy opis na pod­sta­wie Systems Analysis and Design with UML Version 2.0, Alan Dennis, Barbara Halley Wixom, David Tegarden, Second edi­tion, John Wiley and Sons, Inc. 2005, USA)

Jak się mają na tym tle gotowe systemy, nie tylko ERP

Gotowy sys­tem to dla użyt­kow­ni­ka coś co zoba­czy i uży­je do pra­cy dopie­ro po zain­sta­lo­wa­niu i wdro­że­niu. Spróbujmy wpa­so­wać goto­we opro­gra­mo­wa­nie w powyż­sze pro­ce­sy. Dlaczego? Bo moż­na zało­żyć, że ini­cja­to­rem jest jed­nak kupu­ją­cy. Gotowego sys­te­mu nie musi­my pro­jek­to­wać i wytwa­rzać, więc oszczę­dza­ny czas, jed­nak nie może­my omi­nąć fazy ana­li­zy wyma­gań gdyż musi ist­nieć jakieś zamó­wie­nie.

Mamy więc plan i opis potrze, pomi­ja­my pro­jek­to­wa­nie i wytwo­rze­nie, otrzy­mu­je­my goto­wy pro­dukt. Jak widać pierw­szym przy­bli­że­niem jest kla­sycz­ny wodo­spad, gdzie pierw­szy kon­takt użyt­kow­ni­ka z sys­te­mem ma miej­sce dopie­ro w momen­cie odda­nia do użyt­ku! Dlatego, ze ana­li­za wyma­gań (ich opis) musi być bar­dzo szcze­gó­ło­wa bo nie ma odwro­tu. Jednak nad­mier­na szcze­gó­ło­wość ana­li­zy wyma­gań pro­wa­dzić może do sytu­acji gdy oka­że się, że żaden pro­dukt na ryn­ku ich nie speł­nia naszych wymagań.

Jednak nie­wąt­pli­wą zale­tą jest szyb­ki czas otrzy­ma­nia goto­we­go pro­duk­tu ale pod jed­nym warun­kiem, że speł­nia ocze­ki­wa­nia i koło się zamyka.

Nasuwa się wnio­sek, by zamiast szu­kać pro­duk­tu na bazie setek a nawet tysię­cy drob­nych funk­cjo­nal­no­ści, pójść w kie­run­ku war­to­ści biz­ne­so­wych. Oznacza to, że godząc się na zmia­nę pew­nych nawy­ków pra­cy (np. pew­ne czyn­no­ści będą wyko­ny­wa­ne ina­czej) uzy­ska­my narzę­dzie wspie­ra­ją­ce cele same w sobie np. sys­tem ma poma­gać wysta­wiać fak­tu­ry VAT ale to w jaki spo­sób to robi może być przed­mio­tem kom­pro­mi­su. Produkty róż­nych pro­du­cen­tów się róż­nią mię­dzy sobą, licz­ba cech duże­go zin­te­gro­wa­ne­go sys­te­mu idzie w tysią­ce. Im wię­cej cech tym trud­niej osią­gnąc kom­pro­mis, im więk­szy kom­pro­mis tym mniej speł­nio­nych wyma­gań. Wydaje się więc, że nale­ży zmniej­szyć wie­lość poszu­ki­wa­ne­go sys­te­mu. Łatwiej wybrać kil­ka dedy­ko­wa­nych niż jeden uni­wer­sal­nych. Koszt inte­gra­cji? Owszem ale otrzy­mu­je­my to co jest potrzeb­ne a nie coś co tyl­ko to przypomina.

Pojawia się w ofer­cie dostaw­cy hasło kasto­mi­za­cja. Cóż to takie­go? To wpro­wa­dza­nie zmian do dostar­czo­ne­go goto­we­go, duże­go sys­te­mu. Znowu ten pier­wot­ny, kosz­tow­ny wodo­spad.

Wydaj się wiec, że opty­mal­nych spo­so­bem jest:

  1. Zaplanowanie pro­jek­tu
  2. Analiza
  3. Projektowanie logi­ki sys­te­mu i testo­wa­nie pro­to­ty­pów tej logi­ki czy dobrze zosta­ła zaprojektowana
  4. Opisanie pro­jek­tu, podzie­le­nie go na spój­ne obsza­ry (kom­po­nen­ty)
  5. Wybór meto­dy dal­sze­go postę­po­wa­nia dla każ­de­go komponentu

Tak więc nasu­wa się meto­dy­ka łączą­ca meto­do­lo­gie pro­to­ty­pu tra­co­ne­go na eta­pie ana­li­zy i pro­jek­to­wa­nia oraz rów­no­le­głą na eta­pie wytwa­rza­nia i dostarczania.

Po co dokumentować – wnioski po dyskusji na forum

AllTopics

W kwe­stii Alistair’a Cockburn’a: jest to piew­ca pro­jek­to­wa­nia poprzez przy­pad­ki uży­cia, któ­rej to teo­rii jakoś nie wyzna­ję. Uważam, że pro­jekt udo­ku­men­to­wa­ny wyłącz­nie przy­pad­ka­mi uży­cia jest bar­dzo ryzy­kow­ny bo prak­tycz­nie nie zawie­ra w ogó­le kon­tek­stu, nie licząc warun­ków począt­ko­wych i koń­co­wych każ­de­go przy­pad­ku użycia.

Zmiany w pro­jek­cie. Uważam, że na świe­cie są trzy pew­ne rze­czy: śmierć, podat­ki i zmia­na wyma­gań ale – czym innym jest zmia­na celu pro­jek­tu a czym innym zmia­na jego zakre­su. Jeżeli nor­mą jest zmia­na zakre­su w pro­ce­sie zarzą­dza­nia zmia­ną w pro­jek­cie, tak nie dopusz­czam zmia­ny biz­ne­so­we­go celu pro­jek­tu w trak­cie jego trwa­nia, chy­ba że nazwie­my to nowym projektem.

Tak więc jeśli sys­tem ma zarzą­dzać księ­gar­nią to pro­jekt sys­te­mu należ­ny zro­bić, będzie zawie­rał model biz­ne­so­wy i pro­ce­sy biz­ne­so­we (ale już nie bez­sen­sow­ne szcze­gó­ły pro­ce­dur, któ­re zmie­nia­ją się jak w kalej­do­sko­pie), pro­duk­ty poszcze­gól­nych pro­ce­sów – doku­men­ty, oraz wspo­ma­ga­ją­ce pro­ce­sy, któ­re dostar­cza­ją zaso­by i two­rzą (sta­no­wią) ogra­ni­cze­nia. Wtedy dia­gra­mów pro­ce­sów jest naj­wy­żej kil­ka­na­ście a nie kil­ka­set (to chore).

Tak więc np. dla wspo­mnia­nej księ­gar­ni, po mode­lu biz­ne­so­wym i pro­ce­so­wym powsta­nie model dzie­dzi­ny, model przy­pad­ków uży­cia i ich sce­na­riu­sze. W kwe­stii zmian: Co tu się może zmie­nić? Cel powsta­nia fak­tu­ry? Może obiekt książ­ka? Nie! Można zmie­nić zakres pro­jek­tu usu­wa­jąc bądź doda­jąc przy­pad­ki uży­cia z puli zawar­tej w ana­li­zie ale dobrze wyko­na­ny model dzie­dzi­ny jest na to nie­czu­ły, więc nie ma tu nic do zmia­ny w doku­men­ta­cji ana­li­tycz­nej i pro­jek­cie, tyl­ko w zakre­sie pro­jek­tu implementacji.

Dlatego war­to mieć jed­nak wodo­spa­do­wo” zamknię­tą ana­li­zę i pro­jekt, by łatwo było zarzą­dzać zmia­ną w pro­ce­sie imple­men­ta­cji. Warto spoj­rzeć na to tak­że z innej stro­ny, któ­ra moim zda­niem lepiej tłu­ma­czy potrze­bę doku­men­to­wa­nia i to stan­dar­do­wy­mi (wspól­ny język) meto­da­mi: doku­men­ta­cja to zarzą­dza­nie ryzykiem!

Idealny pro­ces wytwórczy:

1. klient dobrze opi­sał swo­je ocze­ki­wa­nia i podał wszyst­kie istot­ne informacje

2. dewe­lo­per dobrze wszyst­ko zro­zu­miał i okre­ślił budżet, ter­min i zakres projektu

3. deve­lo­per od razu z gło­wy bez pro­jek­tu napi­sał dobry kod – dobre oprogramowanie

Ale jak wiemy:

1. jeże­li jest ryzy­ko, że klient w spo­sób nie­kom­plet­ny opi­sze swo­je ocze­ki­wa­nia nale­ży wyko­nać ana­li­zę biz­ne­so­wą i ją udo­ku­men­to­wać (powsta­je model fir­my klien­ta, któ­ry on zatwierdza)

2. jeże­li jest ryzy­ko, że deve­lo­per nie zro­zu­mie biz­ne­su nale­ży prze­two­rzyć model biz­ne­so­wy i cele biz­ne­so­we klien­ta na wyma­ga­nia na opro­gra­mo­wa­nie w posta­ci przy­pad­ków uży­cia z ograniczeniami

3. Jeżeli jest ryzy­ko, że deve­lo­per nie napi­sze od razu dobre­go opro­gra­mo­wa­nia nale­ży stwo­rzyć model archi­tek­tu­ry, model dzie­dzi­ny, kom­po­nen­ty i sce­na­riu­sze jak kom­po­nen­ty oraz obiek­ty dzie­dzi­ny, reali­zu­ją przy­pad­ki uży­cia, jak obiek­ty mode­lu dzie­dzi­ny i zre­ali­zu­ją inter­fej­sy komponentów.

Powyższe zawsze moż­na zro­bić na żywioł bez kom­plet­ne­go i udo­ku­men­to­wa­ne­go pro­jek­tu jeśli nie ist­nie­je ryzy­ko, że coś się nie uda. Dokumentacja sta­no­wi tak­że ele­ment zarzą­dza­nia wie­dzą. Gdy nie ma doku­men­ta­cji nowy czło­wiek w zespo­le zaj­mu­je czas kole­gów, któ­rzy muszą mu opo­wie­dzieć” o pro­jek­cie, jak jest doku­men­ta­cja, czy­ta ją sam nie obni­ża­jąc efek­tyw­ność pra­cy kolegów.

Tak więc dla jasno­ści: nie negu­ję typo­wej dla SCRUM czy XP wer­sji postę­po­wa­nia, a tyl­ko wska­zu­je na sytu­acje gdy pre­fe­ro­wa­ne są inne. Co do Agile pod­su­mu­ję moje podej­ście: PMI czy Prince2 to dla mnie raczej for­mal­ny spis tre­ści pro­jek­tu” ale dla każ­de­go rze­czy­wi­ste­go pro­jek­tu sam dobie­ram te ele­men­ty tego spi­su, któ­re mi pomo­gą i tak poj­mu­ję zwin­ność projektową.