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.

Inne artykuły na podobny temat

Komentarze

  1. Mirek Piotrowski 6 kwietnia 2011 at 14:42

    Opisany prze Pana faza pla­no­wa­nia” wska­zu­je na to, że wyni­ki ana­li­zy biz­ne­so­wej powin­na być zna­na na eta­pie pla­no­wa­nia i ten pogląd rów­nież sto­su­ję w prak­ty­ce. Jednak w opi­sie kolej­nej fazy Analiza” napi­sa­no, że ma w tym eta­pie miej­sce (zno­wu) Analiza biz­ne­so­wa”. Czy argu­men­tu­je Pan wyko­ny­wa­nie dru­giej ana­li­zy biz­ne­so­wej? A moż­ne cho­dzi o ana­li­zę pro­ce­sów biz­ne­so­wych? Proszę o wyjaśnienie.

    • Jarek Żeliński 7 kwietnia 2011 at 10:10

      Na eta­pie pla­no­wa­nia powi­nien być zna­ny (pozna­ny) model biz­ne­so­wy i cele biz­ne­so­we spon­so­ra pro­jek­tu wraz z ich mier­ni­ka­mi. Analiza biz­ne­so­wa to ana­li­za i mode­lo­wa­nie pro­ce­sów biz­ne­so­wych oraz tak­so­no­mii. Faktem jest, że poję­cie ana­li­zy biz­ne­so­wej” nie posia­da ści­słej defi­ni­cji dla­te­go fak­tycz­nie nie raz bez­piecz­niej jest posłu­gi­wać się defi­ni­cją tego co powsta­nie (pro­duk­tem danej ana­li­zy). Jednak naj­waż­niej­sze jest by mode­le pro­ce­sów i tak­so­no­mia były wyko­na­ne z pomo­cą for­mal­nych nota­cji. Modelowanie meto­da­mi nie­for­mal­ny­mi (lub łama­nie zasad sfor­ma­li­zo­wa­nej nota­cji) naj­czę­ściej pro­wa­dzi do dia­gra­mów, któ­rych jakość nie odbie­ga wie­le od tek­sto­we­go opi­su… Dobre mode­le to nie zastą­pie­nie tek­stu jaki­miś sym­bo­la­mi a zastą­pie­nie nie­jed­no­znacz­ne­go tek­stu ści­śle zde­fi­nio­wa­ny­mi sym­bo­la­mi i ich zło­że­nia­mi (kon­struk­cja­mi) mają­cy­mi pro­ste i zara­zem jed­no­znacz­ne znaczenia.

    • Łukasz Mozalewski 7 kwietnia 2011 at 20:44

      W szcze­gól­no­ści w przy­pad­ku tech­nik zwin­nych nastę­pu­je powta­rzal­ność eta­pu ana­li­zy biz­ne­so­wej, ale na róż­nym pozio­mie szcze­gó­ło­wo­ści. Na począt­ku okre­śla­na jest lista wyma­gań („wie­my co chce­my”), a potem okre­śla­jąc zakres wyma­gań dla dane­go prze­bie­gu („wie­my, co teraz robi­my”), wyma­ga­nia mogą zostać uszcze­gó­ła­wia­ne w spo­sób pozwa­la­ją­cy na reali­za­cję danej czę­ści sys­te­mu. Jest wie­le tech­nik pozwa­la­ją­cych na uspraw­nie­nie tego procesu.

    • Jarek Żeliński 8 kwietnia 2011 at 10:35

      Wadą wie­lu metod, tych zwin­nych w szcze­gól­no­ści, jest zaczy­na­nie od wie­my co chce­my” i kolej­ne podej­ścia do tema­tu, a prak­ty­ka poka­zu­je, że naj­czę­ściej nie wie­my cze­to chce­my” i nale­ży to porząd­nie zba­dać. Odkrywanie wyma­gań meto­dą kolej­nych przy­bli­żeń pro­to­ty­pu kodu jest bar­dzo kosz­tow­ne i cza­so­chłon­ne. Tu prób­ka spo­so­bu roz­wią­za­nia tego pro­ble­mu: https://​it​-con​sul​ting​.pl/​2​0​2​0​/​1​2​/​1​1​/​a​n​a​l​i​z​a​-​b​i​z​n​e​s​o​w​a​-​o​d​-​z​l​e​c​e​n​i​a​-​d​o​-​k​o​m​p​l​e​t​n​e​g​o​-​p​r​o​j​e​k​t​u​-​t​e​c​h​n​i​c​z​n​e​g​o​-​z​-​u​z​y​c​i​e​m​-​n​a​r​z​e​d​z​i​a​-​c​a​se/

      Kluczowe eta­py powin­ny być jed­nak wodo­spa­dem (cofa­nie się do ana­li­zy jest naj­kosz­tow­niej­sze w każ­dym pro­jek­cie), dla­te­go wska­za­łem pro­ces z pro­to­ty­pem odrzu­ca­nym jako naj­efek­tyw­niej­szy kom­pro­mis – przy zało­że­niu że pro­to­ty­py to jed­nak mode­le a nie kod.

    • Grzegorz Bednarski 27 kwietnia 2011 at 16:48

      W Scrumie począ­tek i koniec pro­jek­tu są dobrze zde­fi­nio­wa­ny­mi pro­ce­sa­mi – czy­li wła­śnie wodo­spa­da­mi. Na począt­ku ma miej­sce w szcze­gól­no­ści wła­śnie ana­li­za oraz high-level design.

    • Jarek Żeliński 27 kwietnia 2011 at 20:50

      W SCRUM’ie mnie boli” to, że pra­ca pro­jek­to­wa cały czas w zasa­dzie odby­wa się na kodzie” czy­li pra­cu­je kosz­tow­ny zasób zespół pro­gra­mi­stów”, w meto­dy­kach, o któ­rych ja piszę (i jestem orę­dow­ni­kiem), wery­fi­ka­cja popraw­no­ści pro­jek­tu ma miej­sce na mode­lach, i nie jest tu mode­lem kod (nawet uprosz­czo­ny) a dia­gra­my z logi­ką sys­te­mu a to testu­je jed­na oso­ba. Do tego wyko­na­nie dia­gra­mu zaj­mu­je o wie­le mniej cza­su niż napi­sa­nie odpo­wia­da­ją­ce­go mu kodu. Po dru­gie nie­for­mal­ne histo­ryj­ki” są nie­we­ry­fi­ko­wal­ne, ich sens lub brak sen­su wyj­dzie dopie­ro przy kolej­nym sprin­cie”… to kosztuje…

      W pew­nej kla­sie pro­jek­tów dają­cych się ogar­nąć” kil­ko­ma nie­skom­pli­ko­wa­ny­mi przy­pad­ka­mi uży­cia SCRUM się spraw­dza, jed­nak wraz ze wzro­stem zło­żo­no­ści jest kosztowny…

    • Grzegorz Bednarski 12 maja 2011 at 20:08

      w scru­mie powsta­ją wszyst­kie mode­le jakie mogą powstać w tra­dy­cyj­nym mode­lu. jest tam jak naj­bar­dziej miej­sce dla analityka.

      przed roz­po­czę­ciem sprin­tów ma miej­sce peł­na ana­li­za, jej testo­wa­nie itp – taka jaka jest pro­mo­wa­na na tym blo­gu, ponie­waż począ­tek i koniec pro­jek­tu w scru­mie jest dobrze zde­fi­nio­wa­nym pro­ce­sem. jeśli pro­jekt jest zło­żo­ny to czas ana­li­zy się wydłu­ża tak jak jest tutaj napi­sa­ne a sprin­ty się nie zaczynają.

      cie­ka­we jest to, co się dzie­je dalej. w przy­pad­ku scru­ma po pierw­szym sprin­cie mode­le powin­ny być aktu­ali­zo­wa­ne zgod­nie z infor­ma­cją zwrot­ną od klien­ta. w przy­pad­ku o któ­rym piszesz, model idzie do kosza. pyta­nie co lepsze.

      dużo rze­czy napi­sa­nych o scrum jest nie­ste­ty nie­praw­dzi­wych. nie moż­na tak ten­den­cyj­nie przed­sta­wiać swo­ich poglą­dów kosz­tem innych. naj­gor­sze jest to, że ktoś mło­dy i nie­do­świad­czo­ny może to przy­jąć za prawdę.

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

      Najdziwniejsze w tym wszyst­kim jest to, że np. o SCRUM mam infor­ma­cje głów­nie z lite­ra­tu­ry na temat meto­dyk zwin­nych. Osobiście bra­łem udział w jed­nym pro­jek­cie, o któ­rym kie­row­nik pro­jek­tu poważ­nie mówił, że to SCRUM”. Jednak nie cho­dzi tu o to czy to czy­sty SCRUM czy nie a o to, że w meto­dy­kach zwin­nych opi­sa­nych jak powy­żej, pro­dukt koń­co­wy nie ma swo­jej peł­nej doku­men­ta­cji na począt­ku imple­men­ta­cji. Innymi sło­wy powsta­nie to co powsta­nie”. Mogę się oczy­wi­ście mylić jed­nak tu bazu­je na lite­ra­tu­rze, tak­że WIKI (za któ­ra nie prze­pa­dam ale two­rzą ją głow­nie ludzie od Agile”). Metodyka, któ­ra pro­mu­ję” to ana­li­za i testy mode­li tra­co­nych, jed­nak tu mode­lem jest sfor­ma­li­zo­wa­ny dia­gram a nie kod. Tak więc po pierw­sze, koszt ite­ra­cji” jest nie­po­rów­na­nie mniej­szy, po dru­gie testy robi ana­li­tyk a więc ten kto ma naj­więk­szą wie­dzę o biz­ne­sie klien­ta” a nie pro­gra­mi­sta. Moim zda­niem meto­dy­ki zwin­ne są dosko­na­łe tam gdzie pro­jekt jest na tyle mało zło­żo­ny, że mały zespół pro­gra­mi­stów (lub nawet jeden) ogar­nia” go bez pro­ble­mu i nie­któ­re testy mogą być nawet prze­pro­wa­dzo­ne myślo­wo” lub tyl­ko dys­ku­syj­nie”.

    • Grzegorz Bednarski 13 maja 2011 at 18:48

      ja widzia­łem pro­jek­ty na któ­rych kie­row­nik i uczest­ni­cy mówi­li to scrum” a ze scru­mem nie mia­ło nic wspól­ne­go 🙂 jeśli o takich jest tu pisa­ne, to nie dzi­wię się błęd­nym wnioskom.

      nie dzi­wię się, że idea scru­ma jest tutaj źle poj­mo­wa­na bo spo­tka­łem bar­dzo wie­lu deve­lo­pe­rów i pm’ów, któ­rzy pro­mo­wa­li podob­ne pomy­sły a teo­re­tycz­nie mie­li w tym praktykę.

      jak pisa­łem, przed roz­po­czę­ciem sprin­tów ma miej­sce peł­na ana­li­za i powsta­je doku­men­ta­cja. pisa­nie, że w scru­mie doku­men­ta­cja jest kodem to jakaś pomyłka.

      pro­po­nu­ję sobie prze­czy­tać zamiast wiki coś u źródeł:

      jest tam napi­sa­ne w szczególności:
      Perform doma­in ana­ly­sis to the extent requ­ired to build, enhan­ce, or upda­te the
      doma­in models to reflect the new sys­tem con­text and requirements.”

    • Jarek Żeliński 14 maja 2011 at 00:43

      wstaw tu jakiś sen­sow­ny link z opi­sem SCRUM, bo fak­tycz­nie chy­ba jest za bar­dzo koja­rzo­ny z XP.…

  2. Ari 22 listopada 2017 at 14:35

    Czym się róż­ni WDROŻENIE od IMPLENTACJI?
    Myślałam że to to samo.…
    Cykl życia pro­jek­tu two­rze­nia opro­gra­mo­wa­nia ma czte­ry klu­czo­we fazy:

    Planowanie
    Analiza
    Projektowanie
    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.”

    • Jaroslaw Zelinski 22 listopada 2017 at 17:57

      Jeżeli opro­gra­mo­wa­nie nie ist­nie­je, zosta­nie zapro­jek­to­wa­ne i prze­ka­za­ne deve­lo­pe­ro­wi, któ­ry wyko­na imple­men­ta­cję czy­li powsta­nie dzia­ła­ją­cy kod. Powstałe dzia­ła­ją­ce opro­gra­mo­wa­nie, zosta­nie wdro­żo­ne w fir­mie, czy­li pra­cow­ni­cy fir­my nauczą się go uży­wać i zaczną sto­so­wać w pracy.

  3. Jaroslaw Zelinski 1 grudnia 2017 at 09:11

    Polecam cie­ka­wy wpis na zbli­żo­ny temat:
    In sum, for gre­ater respon­si­ve­ness and a higher bene­fits reali­za­tion ratio, ?pro­duct-mode? is a more effec­ti­ve way of wor­king than projects.”

    https://​mar​tin​fow​ler​.com/​a​r​t​i​c​l​e​s​/​p​r​o​d​u​c​t​s​-​o​v​e​r​-​p​r​o​j​e​c​t​s​.​h​t​m​l​#​C​h​a​l​l​e​n​g​e​s​O​f​O​p​e​r​a​t​i​n​g​I​n​P​r​o​d​u​c​t​-​m​ode

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.