Use Case jako możliwa przyczyna porażek projektów IT.
Pojawiły się na rynku systemy zorientowane na model działań a nie na obsługę zasobów i ich zarządzanie. Planowane opracowanie to wnioski z oceny faktów w postaci blisko 80% nieudanych projektów ERP/MRP i prawie 90% CRM (statystyki podawane przez IDC i Gartnera).
[…] Jest to kwestia nie tyle szkodliwości Use Case co metodologii prowadzącej (często) do sztywnego produktu, kosztownego we wdrożeniu i rozwoju. Główne tezy:
- UML + Use Case (bo o tym głównie mowa) to model projektowania bazujący na wskazaniu aktorów i zdefiniowana projektu poprzez opis sytuacji w których Ci aktorzy potrzebują wsparcia projektowanego systemu IT (aplikacji),
- Powstaje aplikacja, która stanowi przede wszystkim system pomocy w pracy (menu aplikacji) aktora (pracownika, osoby funkcyjnej),
- Wykonanie dokumentacji projektowej niejako „zamraża” stan firmy na dzień wykonania opisu.
- Planowo realizowany projekt na bazie wymagań określonych na konkretny dzień (szczególnie w dość konserwatywnej metodologii PMI) trwa np. dwa lata i oddany do użytku system zostaje w między czasie wyprzedzony przez sytuacje na rynku, procedury wprowadzania zmian i zarządzania nimi bardzo podnoszą koszt projektu,
- Rozbudowa systemu opartego na Aktorach jest bardzo trudna gdyż niejednokrotnie dotyka architektury całego systemu,
- Alternatywą jest konstrukcja procesowa systemu (aplikacji), gdzie nie ma mowy o aktorach, projekt odwzorowuje model biznesowy firmy, zamiast aktorów pojawiają się zasoby (w tym kompetencje jeżeli chodzi o ludzi), aplikacja tak zaprojektowana stanowi narzędzie do opisu firmy, w tym definiowania niezbędnych zasobów.
[…] W systemach zorientowanych na procesy poprawnie skonstruowana aplikacja jest w stanie rozwijać się płynnie wraz z firmą. Model procesowy traktuje ludzi (aktorów) jak zasoby dlatego rozbudowa aplikacji z natury ewolucyjnej (modeler procesowy to integralna część systemu) jest niejako wpisana w jej życiorys. Dopisanie nowego procesu może wymagać nowego pracownika lub stanowiska a to jest tylko naturalną czynnością w postaci dodania nowych zasobów. […]
Oczywiście jak wszędzie są inne kompromisowe rozwiązania jednak w tej chwili można chyba powiedzieć, że dominują na rynku dwie metodyki: „stara” oparta na UML/Use Case oraz wschodzące nowe procesowe bazujące na odwzorowywaniu modelu firmy. System do modelowania to coś w rodzaju wysokopoziomowego generatora aplikacji. […]
Bardzo ciekawy wpis na innym blogu na temat Use Case:
The greatest benefit I get from use cases is that they focus on the user. Use cases help me to think about what the user wants to do instead of only focusing on implementation details. The biggest problem I have with use cases is that they are not structured. They are basically free text. (źr. http://larsho.blogspot.com/2011/05/problem-with-use-cases.html)
