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ą.

Zostaw odpowiedź

Twój adres email nie zostanie opublikowany. Pola, których wypełnienie jest wymagane, są oznaczone symbolem *

Możesz użyć tych HTML tagów i atrybutów: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>

Close