Use Case jako moż­li­wa przy­czy­na pora­żek pro­jek­tów IT.
Pojawiły się na ryn­ku sys­te­my zorien­to­wa­ne na model dzia­łań a nie na obsłu­gę zaso­bów i ich zarzą­dza­nie. Planowane opra­co­wa­nie to wnio­ski z oce­ny fak­tów w posta­ci bli­sko 80% nie­uda­nych pro­jek­tów ERP/MRP i pra­wie 90% CRM (sta­ty­sty­ki poda­wa­ne przez IDC i Gartnera).

[…] Jest to kwe­stia nie tyle szko­dli­wo­ści Use Case co meto­do­lo­gii pro­wa­dzą­cej (czę­sto) do sztyw­ne­go pro­duk­tu, kosz­tow­ne­go we wdro­że­niu i roz­wo­ju. Główne tezy:

1. UML + Use Case (bo o tym głów­nie mowa) to model pro­jek­to­wa­nia bazu­ją­cy na wska­za­niu akto­rów i zde­fi­nio­wa­na pro­jek­tu poprzez opis sytu­acji w któ­rych Ci akto­rzy potrze­bu­ją wspar­cia pro­jek­to­wa­ne­go sys­te­mu IT (apli­ka­cji),
2. Powstaje apli­ka­cja, któ­ra sta­no­wi przede wszyst­kim sys­tem pomo­cy w pra­cy (menu apli­ka­cji) akto­ra (pra­cow­ni­ka, oso­by funkcyjnej),
3. Wykonanie doku­men­ta­cji pro­jek­to­wej nie­ja­ko ​„zamra­ża” stan fir­my na dzień wyko­na­nia opisu.
4. Planowo reali­zo­wa­ny pro­jekt na bazie wyma­gań okre­ślo­nych na kon­kret­ny dzień (szcze­gól­nie w dość kon­ser­wa­tyw­nej meto­do­lo­gii PMI) trwa np. dwa lata i odda­ny do użyt­ku sys­tem zosta­je w mię­dzy cza­sie wyprze­dzo­ny przez sytu­acje na ryn­ku, pro­ce­du­ry wpro­wa­dza­nia zmian i zarzą­dza­nia nimi bar­dzo pod­no­szą koszt projektu,
5. Rozbudowa sys­te­mu opar­te­go na Aktorach jest bar­dzo trud­na gdyż nie­jed­no­krot­nie doty­ka archi­tek­tu­ry całe­go systemu,
6. Alternatywą jest kon­struk­cja pro­ce­so­wa sys­te­mu (apli­ka­cji), gdzie nie ma mowy o akto­rach, pro­jekt odwzo­ro­wu­je model biz­ne­so­wy fir­my, zamiast akto­rów poja­wia­ją się zaso­by (w tym kom­pe­ten­cje jeże­li cho­dzi o ludzi), apli­ka­cja tak zapro­jek­to­wa­na sta­no­wi narzę­dzie do opi­su fir­my, w tym defi­nio­wa­nia nie­zbęd­nych zasobów.

[…] W sys­te­mach zorien­to­wa­nych na pro­ce­sy popraw­nie skon­stru­owa­na apli­ka­cja jest w sta­nie roz­wi­jać się płyn­nie wraz z fir­mą. Model pro­ce­so­wy trak­tu­je ludzi (akto­rów) jak zaso­by dla­te­go roz­bu­do­wa apli­ka­cji z natu­ry ewo­lu­cyj­nej (mode­ler pro­ce­so­wy to inte­gral­na część sys­te­mu) jest nie­ja­ko wpi­sa­na w jej życio­rys. Dopisanie nowe­go pro­ce­su może wyma­gać nowe­go pra­cow­ni­ka lub sta­no­wi­ska a to jest tyl­ko natu­ral­ną czyn­no­ścią w posta­ci doda­nia nowych zasobów. […]

Oczywiście jak wszę­dzie są inne kom­pro­mi­so­we roz­wią­za­nia jed­nak w tej chwi­li moż­na chy­ba powie­dzieć, że domi­nu­ją na ryn­ku dwie meto­dy­ki: ​„sta­ra” opar­ta na UML/Use Case oraz wscho­dzą­ce nowe pro­ce­so­we bazu­ją­ce na odwzo­ro­wy­wa­niu mode­lu fir­my. System do mode­lo­wa­nia to coś w rodza­ju wyso­ko­po­zio­mo­we­go gene­ra­to­ra aplikacji. […]

Bardzo cie­ka­wy wpis na innym blo­gu na temat Use Case:

The gre­atest bene­fit I get from use cases is that they focus on the user. Use cases help me to think abo­ut what the user wants to do inste­ad of only focu­sing on imple­men­ta­tion deta­ils. The big­gest pro­blem I have with use cases is that they are not struc­tu­red. They are basi­cal­ly free text. (źr. http://​lar​sho​.blog​spot​.com/​2​0​1​1​/​0​5​/​p​r​o​b​l​e​m​-​w​i​t​h​-​u​s​e​-​c​a​s​e​s​.​h​tml)