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 gdzie i kie­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.

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

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]].

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

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

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]]).

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ę.

(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.