także analiza przedwdrożeniowa
Coraz częściej utożsamiam analizę z projektem gdyż w sumie produktem analizy jest jakiś projekt czyli model tego co analizowano, model tego co rekomenduję by powstało. Analiza sama z siebie nie jest samowystarczalna (to znaczy samo analizowanie nie jest wartościowym produktem samym w sobie). Problemy z projektami obserwuje nie ja jeden. W każdym kolejnym projekcie staram się szukać przyczyn, zrozumieć problem i podjąć próbę rozwiązania. Problem w zasadzie jest znany. [...] Dalej mamy same dobre rady, z którymi trudno polemizować:
Wysoka modularność, współpraca wielu niezależnych, lub luźno powiązanych elementów, możliwość wymiany małych części, lub tworzenie różnych wariantów tego samego modułu, to podejścia, które przyniosą nam wartość dodaną. Ludzie mający do czynienia z monolitami (układ: jedna wielka baza danych i do tego wielki serwer aplikacyjny) z reguły postrzegają podejście rozproszone (dziesiątki lub setki małych kawałków fruwających gdzieś w koło) jako trudniejsze, bardziej skomplikowane i przez to gorsze i bardziej ryzykowne. Takie spojrzenie to postawienie sprawy do góry nogami.
I tu moim zdaniem autor ma 100% racji. Nie ma chyba nic gorszego niż uznanie, że "jeden wielki zintegrowany system" to zaleta tego Systemu, jest to jego największa wada.
Tak więc każde wymaganie:
kojarzymy z realizującym go przypadkiem użycia,
testujemy (z pomocą dobranego scenariusza testowego),
dokumentujemy modelem opisującym jego realizację (np. Obiekt biznesowy w modelu dziedziny).
Takie podejście powoduje, że zanim jeszcze dotkniemy gotowego produktu (tu niestety już po jego wyborze) możemy po pierwsze: przetestować samą specyfikację a po drugie przekazać potencjalnemu dostawcy (na etapie zapytania) pełna informację o tym, czego oczekujemy od produktu.
Powyższe podejście w postaci 'full wypas" może być pracochłonne, dlatego możliwe są warianty pośrednie czyli tylko dla wymagań oznaczonych jako ryzykowne budujemy testy lub elementy modelu dziedziny, jednak mamy narzędzie do panowania nad tym ryzykiem. Po drugie zyskujemy narzędzie do weryfikacji, odbiór oprogramowania nie będzie sprawdzaniem listy dziesiątek cech, będzie "jazdą próbną na sucho" a więc relatywnie tania metodą testów: dostawca deklaruje (oferta na nasze zapytanie) zgodność z naszymi wymaganiami a te są weryfikowalne.
Ten artykuł jest pewną kontynuacją poprzedniego. Potraktujmy go jako "prostszą wersję" :) popartą oczekiwaniami przyszłego wykonawcy, który w swoim artykule niejako "składa zamówienie na dokument wymagań". Wpadła mi swego czasu…
Producenci różnych rzeczy zdają sobie sprawę, że koszty podjęcia właściwej decyzji przy skomplikowanych produktach są spore i ludzie będą podejmować decyzje błędne, to pozwala działać na rynku firmom, które w przeciwnym wypadku by upadły.
I jak teraz wyglądają w Państwa oczach zakupy i wdrożenia dużych gotowych systemów?
Jak to robić lepiej? Po pierwsze nie kupować "dużych i drogich zintegrowanych systemów" bo to duże ryzyko, kupować mniejsze, łatwiejsze do opisania, projektować te, które są zbyt dużym ryzykiem w przypadku złego wyboru. Jeżeli już z powodu ryzyka mamy poświęcić duży budżet na kosztowne specyfikowanie oprogramowania to sygnał, że należy je za te pieniądze po prostu zaprojektować i wykonać.
Niestety nie ma prostej odpowiedzi jak to robić "dobrze". Chyba, że będzie to propozycja następującego procesu:
analiza biznesowa
zdefiniowanie celu
zaprojektowanie architektury systemu (to jako system należy rozumieć organizację wraz z wspierająca ją informatyką), zmierzamy w kierunku tak zwanej [[architektury korporacyjnej]]
zidentyfikować oczekiwane od oprogramowania usługi (wymagania), podzielić je na odrębne obszary dziedzinowe,
dla każdego obszaru dziedzinowego poprowadzić odrębny projekt wyboru rozwiązania.
wybrać rozwiązania.
Zwracam uwagę drobny szczegół: wybory produktu dokonujemy na końcu, nigdy na początku!
Kolejnym problemem jest niestety jakość projektowania:
Według firmy analitycznej Gartner około 60 proc. wdrożeń wielkich systemów informatycznych kończy się klęską. Przyczyną jest m.in. nieumiejętność przełożenia procesów działających w firmie na działanie systemu informatycznego, brak dostatecznego wsparcia ze strony pracowników i kierownictwa firmy (czasem nawet jawny opór), złe przygotowanie wdrożenia lub jego prowadzenie. (za Serwis Nauka w Polsce - PAP SA).
Jak widać, jakość projektowania jest kluczem, zresztą nie tylko w przypadków dużych systemów ale w każdym przypadku. Różnica jest taka, że jeżeli niejedna firma świadomie ryzykuje kilkaset tysięcy rezygnując z etapu niezależnej analizy i projektowania wartej ok. 10-20% tej kwoty, to podobne podejście projekty warte milionów jest już raczej nieracjonalne...
