Koncepcja to nie wymagania!

Dwa lata temu pisa­łem o tym, czym jest, po co się pro­wa­dzi i jak, stu­dium wyko­ny­wal­no­ści projektu:

W lite­ra­tu­rze moż­na spo­tkać róż­ne ?defi­ni­cje? stu­dium wyko­nal­no­ści, jed­nak ta któ­rą opi­sa­łem, zda­je się być naj­bliż­sza defi­ni­cji, któ­rą przy­to­czy­łem na począt­ku: bazu­ją­cej na zna­cze­niu słow­ni­ko­wym. Praktyka poka­zu­je, że inten­cje spon­so­rów tych ana­liz są z nią zbież­ne: celem jest pod­ję­cie decy­zji o naj­mniej­szym ryzy­ku w świe­tle posia­da­nej na dany temat wie­dzy. Definicje bazu­ją­ce na tech­nicz­nej i finan­so­wej wyko­nal­no­ści dane­go pro­jek­tu, są spo­ty­ka­ne dość czę­sto i w lite­ra­tu­rze i na stro­nach wie­lu insty­tu­cji. Metoda pro­wa­dze­nia takich ana­liz, bazu­ją­ca na mode­lo­wa­niu czy­li na ana­li­zie sys­te­mo­wej, wyda­je się być jed­nak naj­wła­ściw­szą. (Źródło: Studium wyko­nal­no­ści ? czym napraw­dę jest | | Jarosław Żeliński IT-Consulting)

W arty­ku­le tym zwra­ca­łem uwa­gę na war­tość mode­lo­wa­nia (a nie ryso­wa­nia…), war­to­ścią tą jest testo­wa­nie kon­cep­cji. Sama kon­cep­cja nie jest żad­nym wyma­ga­niem, co ilu­stru­je świet­ny arty­kuł na stro­nach Modernanalyst​.com:

Requirements must be based on facts and real-life sce­na­rios. When the con­cept is unte­sted or not ful­ly tested, then the requ­ire­ments are hypo­the­ti­cal. Moving to design and build with hypo­the­ti­cal requ­ire­ments, the design and/or build pha­se beco­mes the testing gro­und for the con­cept. This may lead to cla­shes as each par­ty has dif­fe­rent expec­ta­tions of the out­co­me of the ?hypo­the­ses?.

Źródło: Blueprints Are Not Requirements!

Powyższy dia­gram poka­zu­je głów­ne prze­sła­nie opi­sa­nej meto­dy, któ­ra jest zgod­na w 100% z peł­ną ana­li­zą sys­te­mo­wą: pierw­szy etap to opra­co­wa­nie kon­cep­cji czy­li hipo­te­zy mówią­cej taki sys­tem jest nam potrzeb­ny” do roz­wią­za­nia pro­ble­mu biz­ne­so­we­go (potrze­by biz­ne­so­we). Kolejny etap to stwier­dze­nie popraw­no­ści pomy­słu, to nic inne­go jak stu­dium wyko­nal­no­ści, testo­wa­nie pomy­słu. Tu waż­na rzecz: test musi być pro­wa­dzo­ny w opar­ciu o fak­ty i tyl­ko fak­ty, inny­mi sło­wy model nie może koli­do­wać z rze­czy­wi­sto­ścią, musi tak­że poka­zać, że zapro­jek­to­wa­ny nowy lub zmie­nio­ny mecha­nizm dzia­ła­nia orga­ni­za­cji da ocze­ki­wa­ne efek­ty. Dopiero gdy hipo­te­za mówią­ca, że taki sys­tem reali­zu­je nasze potrze­by” zosta­nie potwier­dzo­na testa­mi na mode­lu, ma sens opra­co­wy­wa­nie wyma­gań na to roz­wią­za­nie. W toku opra­co­wy­wa­nia wyma­gań, tak­że je testu­je­my. Tu zno­wu spraw­dza się sku­tecz­ność podej­ścia pro­jekt (model) jako wymaganie”.

Trzy lata temu opi­sa­łem cały taki pro­ces, na dość może try­wial­nym przy­kła­dzie (sza­chy), ale za to (mam nadzie­ję) przej­rzy­stym. Na zakoń­cze­nie arty­ku­łu zwró­ci­łem uwa­gę, że:

Analiza i pro­jek­to­wa­nie obiek­to­we (ang. OOAD) to nie­ja­ko ?imple­men­ta­cja? kla­sycz­nej ana­li­zy sys­te­mo­wej. Nie ma ona nic wspól­ne­go ze struk­tu­ral­ny­mi meto­da­mi ana­li­zy i pro­jek­to­wa­nia opro­gra­mo­wa­nia (cze­go wie­lu zda­je się nadal nie dostrze­gać). Wygląda na to, że jest znacz­nie trud­niej­sza ale prak­ty­ka poka­zu­je, że daje znacz­nie lep­sze rezul­ta­ty. Języki obiek­to­we to nie jakaś tam nowa nazwa kla­sy na pod­pro­gra­my, a zupeł­nie nowy para­dyg­mat pro­gra­mo­wa­nia: musi być poprze­dza­ny ana­li­zą i pro­jek­tem. Jego zale­tą jest to, że pozwa­la na odwzo­ro­wy­wa­nie, nie­mal­że jak w grze, ana­li­zo­wa­ne­go i roz­wią­zy­wa­ne­go pro­ble­mu, pozwa­la na prze­te­sto­wa­nie pomy­słu na pro­gram zanim powsta­nie choć jed­na linia pro­gra­mu. Problemem i wyzwa­niem na eta­pie ana­li­zy jest zro­zu­mie­nie pro­ble­mu, co mam nadzie­ję poka­za­łem. Niestety wie­le ana­liz doku­men­to­wa­nych z uży­ciem nota­cji UML nie ma wie­le wspól­ne­go z OOAD, sta­no­wią echa struk­tu­ral­nych metod ana­li­zy i pro­jek­to­wa­nia, sto­so­wa­nia baz rela­cyj­nych już na eta­pie ana­li­zy (obiek­to­we narzę­dzia nie czy­nią pro­jek­tów obiek­to­wy­mi). Niestety błę­dy te popeł­nia­ją nawet wykła­dow­cy wie­lu uczel­ni i kur­sów. (Źródło: Plansza do gry w sza­chy czy­li ana­li­za i pro­jek­to­wa­nie | | Jarosław Żeliński IT-Consulting).

Autor arty­ku­łu przy­wo­łu­je nie­zmien­ną od lat statystykę:

According to an often-quoted stu­dy from the Gartner Group, 75% of IT pro­jects fail. The Standish Group con­ducts an annu­al survey of IT pro­jects. Their latest report shows a decre­ase in pro­ject suc­cess rates.

  1. 32% of all pro­jects suc­ce­eded: deli­ve­red on time, on bud­get, with requ­ired features.
  2. 44% were chal­len­ged: late, over bud­get, and/or with less than the requ­ired features.
  3. 24% failed: can­cel­led prior to com­ple­tion or deli­ve­red and never used.

When we look back, we not only see failu­res but can cle­ar­ly see the boom the softwa­re indu­stry has been given with its suc­cess. But the wor­ry­ing aspect is that the­re are failu­res that are recur­ring eve­ry year, may­be in a dif­fe­rent orga­ni­za­tion but mostly with com­mon cau­ses. (Źródło: Blueprints Are Not Requirements!)

…i zwra­ca uwa­gę, że ich przy­czy­ny są od lat sta­le takie same…

Requirements must be based on facts and real-life sce­na­rios.” (wyma­ga­nia muszą być opar­te na fak­tach i real­nych sce­na­riu­szach). Więc ile war­te są wizje w pro­jek­tach agi­le albo wydu­ma­ne w toku warsz­ta­to­wych burz mózgów lita­nie życzeń i pomy­słów? Nie tyl­ko moim zda­niem: nie są wie­le war­te i nie powin­ny być wymaganiami.

Inne artykuły na podobny temat

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.