Produkt: Opis Przedmiotu Zamówienia (opracowanie specyfikacji SWS) zawierający zarówno udokumentowany Model Biznesowy Organizacji jak i Projekt Techniczny Rozwiązania, realizowany jest także nadzór autorski nad realizacją. Korzyści: ochrona know-how Zamawiającego, kompletne…
Jeżeli jeszcze ktoś nie wyczuł podstępu to niniejszym informuję, że powyższy diagram to diagram klas notacji UML. Jego cechą jest to, że klasy zostały przedstawione z pomocą ikon, reprezentujących określone stereotypy. Zgodnie z UML, linie przerywane z grotem reprezentują związki użycia (grot wskazuje na użyty obiekt)), asocjacje z pełnym rombem to kompozycje (związek całość część). Czy taki diagram jest niezrozumiały dla biznesu? Mam także nadzieję, że tu widać wyraźnie, że modelowanie dziedziny systemu w postaci klas połączonych z pomocą prostych asocjacji itp., to nie model obiektowy a nieudolna atrapa bazy danych, która z paradygmatem obiektowym nie wiele ma wspólnego.
I tu dochodzimy do sedna: aby stworzyć profil notacji – co czasami bywa niezbędne dla jakości analizy – należy zbudować słownik pojęć z dziedziny analizowanego problemu. Bez takiego słownika analiza może być niewykonywalna, albo jej jakość będzie bardzo niska – czytaj użycie jej wyników będzie bardzo ryzykowne.
Po co dokumentować (modelować) AK? Przede wszystkim po to by zrozumieć jak działa organizacja, a potem by móc świadomie, znając ryzyko, podejmować decyzje o wprowadzaniu zmian do niej. […] Czy to musi być jakiś standard np. TOGAF? Nie jestem przekonany. ArchiMate (notacja zalecana w TOGAF) to nic innego jak system pojęciowy. Czy mamy wybór? Oczywiście, że mamy. Od dawna OMG dostarcza sprawdzone i otwarte standardy notacyjne.
Często słyszę, że to trudne i pracochłonne (dodatkowe klasy w modelu) ale niestety zbyt prosty projekt potrafi być kosztowniejszy w rozbudowie w porównaniu z pierwotnym wytworzeniem, dlatego jak klient w ramach wymagań wpisuje (a wpisuje coraz częściej): system ma umożliwiać łatwe rozszerzenia funkcjonalności, to należy go tak projektować, w przeciwnym wypadku wymaganie to nie jest spełnione…
Druga uwaga: często sami klienci zabijają swoje projekty żądając na samym początku dokumentowania wszystkich szczegółów jakie im do głowy przyjdą nie potrafiąc jednocześnie opisać mechanizmu działania ich organizacji. To niestety często spotykane zjawisko, z którym moim zdaniem należy walczyć. Paradoksalnie złożoność systemów biznesowych tkwi w mechanizmie ich funkcjonownia a nie w danych które zbierają (których nie raz jest po prostu za dużo…)
Książkę polecam przede wszystkim analitykom do nauki ale także “wyżartym” programistom, by sobie uporządkowali zdobyte doświadczenie i możliwie łagodnie przechodzili od metod strukturalnych do obiektowych. Tu pewnie nowinka dla nich: bazy danych projektujemy na samym końcu, na etapie implementacji opracowanego kompletnego projektu obiektowego.
… spotykam się jednak w literaturze z tezami, że wdrożenie jakichkolwiek norm, nie tylko jakości, powinno być także poprzedzone analizą. Innymi słowy normy jakości powinny być wdrażane jako odpowiedź (rozwiązanie) na określone wymagania, a nie dla samego faktu ich wdrażania. Owszem, bywa, że wymaganiem jest np. wymóg przetargowy (oferty mogą składać tylko firmy mające określony certyfikat), jednak moda na jakość, mimo że nie przeminęła całkowicie, powoli przechodzi w racjonalne powody wdrażania norm jakości.
Niestety źle dobrany system informatyczny, mający wspierać/automatyzować czynności w procesie, może być powodem powstania całych podręczników procedur nieuzasadnionych biznesowo, dedykowanych użytkownikom tego systemu, stwarzając przy tym pozory, że to sam proces jest ich źródłem 🙁
Niestety tak się często kończą projekty, w których pomięto analizę i projektowanie i od razu wybrano dostawcę i produkt (analiza wykonana przez dostawce to raczej “jak wdrożyć to co mamy” a nie “jak rozwiązać problem użytkownika”).
Problemem większości projektów IT jest założenie, że tylko dostawca/wykonawca usługi ma wiedzę o tym jak to zrobić. Tezę tę forsują najczęściej własnie wykonawcy (developerzy), a problem polega na tym, że wykonawca dąży tu do sytuacji gdy sam sobie stawia wymagania a potem rozlicza ich realizację.
