W wielu firmach toczy się dyskusja o sformalizowaniu procesu wytwórczego oprogramowania. Spontaniczne tworzenie diagramów przez szeroko rozumianych analityków i projektantów nie buduje wartości dokumentacji. Wartość powstaje, gdy cały zespół dokłada diagram do diagramu jak cegiełka do cegiełki. Dodawane modele procesów biznesowych lub diagramy BPMN uzupełniają się wzajemnie. Specyfikują rozwiązanie.
Myśląc o wdrożeniu metodyki dość często myśli się o narzędziach i notacjach. Notacje mniej absorbują. Upraszczając: jest UML i BPMN jest modelowanie :-).
Szukając narzędzia warto rozważyć by narzędzie wspierało zespół w następujących obszarach. Oto one (rozwinięcia hasłowo):
Podejście iteracyjne i dekompozycja
Modela są budowane przyrostowo z zachowaniem reguł obiektowości.
Istotnym jest to by móc dany fragment procesu zdekomponować, gdyż tylko dekompozycja zapewnia taki poziom szczegółowości jaki jest w danej chwili danym odbiorcom potrzebny. Poziom
Obiektowość i ponowne użycie
Raz zdefiniowany proces, w przypadku ponownego użycia powinien być raz zwizualizowany i opisany w repozytorium projektu. szkoda czasu na wielokrotne opisywanie tych samych działań, obiektów (generalnie artefaktów).
Adekwatna dokumentacja
Dokumentacja musi być budowana szybko w ustalonych szablonach. Generatory dokumentacji oszczędzają czas.
Modele i notacje
Dobre narzędzie wspierające modelowanie pozwala na zastosowanie notacji zgodnej ze standardami. Modele mogą i powinny uzupełniać się nawzajem.
Praca grupowa
Modele budowane są dla ludzi i przez ludzi. Musi istnieć możliwość pracy grupowej, udostępniania zasobów i identyfikacji odpowiedzialnych za zmiany na diagramach.
Jedno repozytorium dla wielu interesariuszy
Budując modele procesów biznesowych, chciałbym móc wykorzystać je w przyszłości do projektowania systemów IT. Tworząc architekturę korporacyjną, dobrze jest mieć referencje do realizacji np.: usług aplikacyjnych. Jedno repozytorium projektu jest tu kluczem do sukcesu
Kultura organizacji
Nie można zapomnieć o przyjętych praktykach w danej organizacji. Złe praktyki trzeba wyeliminować. Dobre pielęgnować. Narzędzie CASE powinno wpierać ten obszar. Nie ma nic gorszego jak narzucenie “od górne” produktu, który swoim działaniem łamie i niszczy to co jest dobre i zostało już wypracowane przez organizację
Migracja i integracja
Czasem przychodzi dzień w którym trzeba przenieść nasze repozytorium modeli do innego środowiska . Standard XMI to dziś podstawa. Warto jest tez znać schemat bazy danych, na którym osadzone jest repozytorium. pomaga to w integracji z innymi narzędziami (np.: JIRA) lub w raportowaniu.
Macierze zależności
Aktywność z procesu biznesowego, przypadek użycia powinien być zmapowany z wymaganiami lub regułami biznesowymi. Pozwala ta na lepsze zrozumienie zasad funkcjonowania procesu oraz sprawdzenie pokrycia wymagań. Śledzenie zmian także jest ułatwione.
Podsumowując. Narzędzia CASE to tylko dodatek, ważny dodatek, ale tylko dodatek do modelowania gdyż ważna jest metodyka wytwarzania systemów.
Myśląc o metodyce warto przenalizować obecny proces wytwórczy. Wdrożenie narzędzi do modelowania powinna być ewolucją, usprawnieniem procesu a nie rewolucją – jego destabilizacją.
