Niski poziom analizy…

Pod arty­ku­łem Plansza do gry w sza­chy, zna­lazł się mię­dzy inny­mi taki komentarz:

Kolejna kwe­stia to taka, że nie widzę war­to­ści w tak nisko­po­zio­mo­wej ana­li­zie. Diagram dzie­dzi­ny i ilu­stra­cja Inicjacji gry są nie­zro­zu­mia­łe dla mnie jako laika i tak samo będą nie­zro­zu­mia­łe dla moje­go klien­ta. Nie wiem więc cze­mu dokład­nie słu­żą i co wnoszą.

Powyższe to typo­we podej­ście zama­wia­ją­ce­go lub (i) spon­so­ra pro­jek­tu. To co tu teraz napi­szę, to abso­lut­nie nie jest kry­ty­ka auto­ra powyż­szej wypo­wie­dzi. To ste­reo­ty­po­we, stan­dar­do­we podej­ście wie­lu zama­wia­ją­cych (i nie raz ich pośred­ni­ków) sys­te­my IT: sam zama­wiam i sam odbieram.

To trosz­kę tak, jak by pod­miot inwe­stu­ją­cy w biu­ro­wiec w cen­trum mia­sta sam podej­mo­wał się oce­ny doku­men­ta­cji tech­nicz­nej wyko­na­nej przez archi­tek­ta, algo gorzej: uznał, że sko­ro tej doku­men­ta­cji nie rozu­mie to jej po pro­tu nie chce! Paradoksalnie, powyż­sze podej­ście to naj­częst­sza przy­czy­na pora­żek pro­jek­tów (budow­nic­two wypra­co­wa­ło praw­ne zasa­dy, IT się jesz­cze bro­ni gło­sa­mi dostawców).

W czym pro­blem? Dokładnie w tym, z czym spo­ty­ka­my się kupu­jąc samo­chód: kupu­ją­cy uwa­ża, że rozu­mie to co widzi i cze­go potra­fi użyć (przy­po­mnę, że każ­dy kie­row­ca uży­wa w samo­cho­dzie skrzy­ni bie­gów ale nie każ­dy rozu­mie jej dzia­ła­nie). Pokazanie (opi­sa­nie) w salo­nie, jaki samo­chód jest nam potrzeb­ny, to góra kil­ka godzin. Przekonanie się o tym, co na praw­dę kupi­li­śmy, to już co naj­mniej kil­ka­set (a nie raz kil­ka tysię­cy) prze­je­cha­nych kilo­me­trów. Prawdę o tym co kupi­li­śmy powie nam dopie­ro mecha­nik po zaku­pie, jest to jed­nak za póź­no na zmia­ny. Kto z Państwa sko­rzy­stał z pora­dy dobre­go mecha­ni­ka przed zaku­pem samo­cho­du? Pamiętajmy, że samo­chód to tysią­ce współ­pra­cu­ją­cych pod­ze­spo­łów, któ­re z nich zna­cie, rozu­mie­cie i widzi­cie? A wszyst­kie mają wpływ na walo­ry użyt­ko­we samochodu.

Projekty IT wyglą­da­ją bar­dzo podob­nie, mało kto – przed wybo­rem dostaw­cy opro­gra­mo­wa­nia – pła­ci za ana­li­zę, pra­wie nikt za pro­jekt, któ­re­go nie rozu­mie, ale pra­wie każ­dy sam zama­wia (opi­su­jąc cza­sem jakieś swo­je wyma­ga­nia) i nie­ste­ty pra­wie każ­dy pro­jekt (przy­po­mnę, że to ponad 75%) to kło­po­ty dla kupu­ją­ce­go i na koszt kupującego.

cennik-mechanika

Odpowiedź na zarzut cytowany na początku

W pro­jek­tach ana­li­tycz­nych mamy trzy klu­czo­we eta­py: ana­li­za, pro­jek­to­wa­nie oraz wytwo­rze­nie. Analiza to coś co zro­zu­mie każ­dy zama­wia­ją­cy, bo jej efek­tem jest opis jego wła­snej dzia­łal­no­ści. Powstaje po to, by nikt nie miał wąt­pli­wo­ści jaki jest biz­ne­so­wy cel pro­jek­tu i jak będzie on reali­zo­wa­ny (ale celem biz­ne­so­wym pro­jek­tu nie jest zakup opro­gra­mo­wa­nia!, to jeden z moż­li­wych spo­so­bów jego reali­za­cji). W mię­dzy­cza­sie powsta­je model pro­ce­so­wy, to doku­ment dla ana­li­ty­ka. Celem jego two­rze­nia jest mini­ma­li­za­cja ryzy­ka nie­kom­plet­no­ści i nie­spój­no­ści pro­jek­tu i doku­men­ta­cji wyma­gań. Nie jest praw­dą, że zama­wia­ją­cy ma tu coś do spraw­dze­nia, ale praw­da jest, że zama­wia­ją­cy bie­rze udział w jego testo­wa­niu (spraw­dze­niu popraw­no­ści). Model pro­ce­sów to for­mal­ny opis wyma­ga­ją­cy już pew­nej wiedzy. 

Podstawowym błę­dem jaki popeł­nia­ją zle­ce­nio­daw­cy ana­liz, jest pró­ba for­so­wa­nia zmian w mode­lach w rodza­ju pro­szę mi dopi­sać jesz­cze, że cza­sa­mi ten doku­ment tra­fia do…”. 

Model to pew­na for­mal­na struk­tu­ra. Model gry w sza­chy to sza­chow­ni­ca, bier­ki i regu­ły gry, a nie set­ki godzin fil­mów nakrę­co­nych pod­czas roz­gry­wa­nia real­nych par­tii. Niestety więk­szość widzi i podzi­wia roz­gry­wa­ne par­tie i ocze­ku­je fil­mu, jed­nak opro­gra­mo­wa­nie BigBlue (kom­pu­ter z tym pro­gra­mem wygrał w sza­chy z mistrzem świa­ta) to nie tysią­ce zapi­sa­nych par­tii gry, a pro­gram mają­cy zaim­ple­men­to­wa­ne regu­ły gry… nie­ste­ty tak to wygląda.

Analityk może oddać jako wyma­ga­nie tak­że prze­te­sto­wa­ny pro­jekt logicz­ny opro­gra­mo­wa­nia. Wtedy wyma­ga­na jest tak­że zgod­ność zacho­wa­nia się opro­gra­mo­wa­nia z tą logi­ką. Po co? By wyeli­mi­no­wać ryzy­ka, któ­rych źró­dłem jest nie­zro­zu­mie­nie biz­ne­su zama­wia­ją­ce­go przez deve­lo­pe­ra (to zresz­tą nie jego rola), oraz ryzy­ka zwią­za­ne z budo­wa­niem mar­ży po stro­nie wyko­naw­cy (uprasz­cza­nie pro­jek­tu w celu obni­że­nia pracochłonności).

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

software_development

Metody zwin­ne, to być może dosko­na­łe meto­dy pra­cy w pro­jek­tach zwią­za­nych ze spo­łecz­no­ścio­wy­mi stro­na­mi WWW, ale w pro­jek­tach biz­ne­so­wych nie­ste­ty są to meto­dy tak­że bar­dzo kosz­tow­ne i nie­prze­wi­dy­wal­ne, dla­te­go pro­jek­ty zwin­ne to bar­dzo rzad­ko pro­jek­ty o usta­lo­nym w umo­wie zakre­sie (opis tego co ma powstać). Po lewej stro­nie (dia­gram ze stron pew­ne­go deve­lo­pe­ra) typo­wa zwin­na” pro­ce­du­ra two­rze­nia opro­gra­mo­wa­nia: usu­wa­nie przez deve­lo­pe­ra błę­dów pro­jek­tu (szcze­gól­nie doty­czą­cych reali­zo­wa­nej logi­ki biz­ne­so­wej) może być pętlą nie­skoń­czo­ną, któ­rą tyl­ko wyczer­pa­nie budże­tu lub gra­nicz­ny ter­min jest w sta­nie zatrzy­mać, co może nie dać w efek­cie żad­ne­go przy­dat­ne­go produktu.

Na koniec ku prze­stro­dze cytat pew­ne­go użyt­kow­ni­ka systemu: 

Niestety źle dobra­ny sys­tem infor­ma­tycz­ny, mają­cy wspierać/automatyzować czyn­no­ści w pro­ce­sie, może być powo­dem powsta­nia całych pod­ręcz­ni­ków pro­ce­dur nie­uza­sad­nio­nych biz­ne­so­wo, dedy­ko­wa­nych użyt­kow­ni­kom tego sys­te­mu, stwa­rza­jąc przy tym pozo­ry, że to sam pro­ces jest ich źródłem 🙁

Niestety tak się czę­sto koń­czą pro­jek­ty, w któ­rych pomię­to ana­li­zę i pro­jek­to­wa­nie i od razu wybra­no dostaw­cę i pro­dukt (ana­li­za wyko­na­na przez dostaw­ce to raczej jak wdro­żyć to co mamy” a nie jak roz­wią­zać pro­blem użytkownika”).

Problemem więk­szo­ści pro­jek­tów IT jest zało­że­nie, że tyl­ko dostawca/wykonawca usłu­gi ma wie­dzę o tym jak to zro­bić. Tezę tę for­su­ją naj­czę­ściej wła­śnie wyko­naw­cy (deve­lo­pe­rzy), a pro­blem pole­ga na tym, że wyko­naw­ca dąży tu do sytu­acji, w któ­rej sam sobie sta­wia wyma­ga­nia a potem roz­li­cza ich reali­za­cję. 

Wykonanie ana­li­zy wyma­gań wła­sny­mi zaso­ba­mi (kupu­ją­ce­go) z regu­ły daje złe efek­ty, powo­dem są zbyt sil­ne zależ­no­ści wła­snych pra­cow­ni­ków mię­dzy sobą i ich zależ­ność od aktu­al­nie posia­da­nych zaso­bów. Do tego docho­dzi brak obiek­ty­wi­zmu i obcią­że­nie do zacho­wa­nia wła­snej pozycji.

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.