Rozmowa z Jarosławem Żelińskim: Sami wymyślą, sami zrobią i sami ocenią Naukowcy z Instytutu Informatyki Politechniki Wrocławskiej przyjrzeli się bliżej 80 inwestycjom, które uruchomiono w połowie 2010 roku. I porównali ze sobą ich wyniki. Okazało się, że są ogromne dysproporcje między urzędami a firmami. Dysproporcje niestety na niekorzyść projektów publicznych, które kończą się sukcesem dwukrotnie rzadziej niż analogiczne z sektora prywatnego. A do tego niestety ponad połowa z nich kończy się klapą. Skąd tak duże różnice między efektami informatyzacji prywatnych firm a informatyzacją urzędów? (Informatyzacja administracji, czyli najlepszy sposób na…
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.
Kluczowym narzędziem budowania scenariuszy są modele, te jednak muszą być sformalizowane ([[użycie notacji formalnych]]), w przeciwnym wypadku są "niestetowalne" (w projektach bazujących na AK stosowana jest z reguły notacja ArchiMate).TOGAF to nie jedyna metodologia, w której można spotkać idee użycia scenariuszy. [[The Open Group]] nie ma "monopolu" ani na metody scenariuszowe ani na ([[notację ArchiMate]] stosowaną w projektach AK, która także nie jest objęta żadnym patentem ani inną ochroną prawną. Tak więc zachęcam to brania tej metody pod uwagę, szczególnie w ryzykownych i dużych projektach.
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 przed oczy strona pewnego developera stron WWW. Dlaczego mnie zainteresowała? Bo po pierwsze słusznie oczekuje od swojego klienta konkretów, po drugie potrafi krótko i zwięźle opisać czego potrzebuje, by mógł wytworzyć oprogramowanie (opisał to w kontekście tworzenia stron WWW, które obecnie bardzo często także są wynikiem działania oprogramowania): Podstawowym dokumentem, który należy przygotować jest specyfikacja techniczna. Powinna ona wyszczególnić funkcjonalności, które mają znaleźć się na…
Od czasu do czasu "nawołuję" do formalizowania projektów. Jak nie raz wspominałem, jest to podstawowa metoda uczynienia projektu (jego dokumentacji) przejrzystym. Drugą ważną korzyścią z formalizacji jest tak zwana [[interoperacyjność]], która oznacza możliwość współdziałania technologii różnych dostawców (producentów).Jak nie trudno się domyśleć, problem dotyczy w szczególności każdej większej organizacji, niejako skazanej na posiadanie rozwiązań z różnych źródeł. Klasycznym przykładem jest administracja publiczna (z interoperacyjnością, a raczej jej brakiem, w Polsce walczymy).Tak więc polecam osobom związanym z administracja publiczną i instytucjami publicznymi, zapoznanie się z tą inicjatywą. Moim zdaniem bardzo ważna, dobrze że podjęto ten temat gdyż kwestie integracyjne stanowią nie raz istotny koszt projektów IT a bywa, że brak interoperacyjności powoduje wręcz niemożność ich realizacji (np. w Polsce integracja rejestrów Państwowych).
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!
W 2009 roku udzielając wywiadu Gazecie zwróciłem uwagę na fakt, że: - Patologiczne są przetargi, w których wykonawca systemu sam sobie robi analizę wymagań. Z całym szacunkiem, nie widziałem jeszcze wykonawcy, który by w takiej analizie napisał: "niniejszym stwierdzam, że moje rozwiązanie się tu nie nadaje". Słyszałem za to: "ukręcimy łeb każdemu przetargowi, który ma oddzieloną specyfikację wymagań od wykonania na dwa przetargi" (na szczęście coraz rzadziej się to udaje). Powód był prosty - firmy się obawiały, że mniej zarobią. (Wymiećmy spod kołdry brudy informatyzacji). Świeży przykład. W pewnym przetargu wymagania opisane całkiem przyzwoicie…
Jednym z głównych problemów wielu projektów analitycznych (i nie tylko) jest komunikacja i dokumentowanie działań. Projekty analityczne mają to do siebie, że opisują organizację beneficjenta projektu. Tworzenie jej modeli wymaga "sprzężenia zwrotnego" beneficjent-analityk. Jednak nie chodzi o to, by się codziennie spotykać a o to, by na bieżąco konsultować. Od lat, jako analityk, stosuję z powodzeniem metodę pracy polegającą na studiowaniu i analizie dokumentów. Są to twarde dane o życiu firmy, niosą większość wiedzy o tym co i po co się dzieje. Praktyka pokazuje, że nie szczegóły powstawania tych dokumentów są istotne…
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...
Sam pomysł na metryki bardzo dobry, bardzo mi się spodobał, jednak ma on sens pod warunkiem, że będzie ona (metryka czyli format metadanych) jednolita (pomijam ogłoszona w terminie zapowiadanym w ustawie). Efektem było by jedno, dobrze opracowane [[JRWA]] dla całego kraju oraz spójne informacje o przebiegu spraw. Jest nawet instytucja, która ma stosowne kompetencje by ją stworzyć: [[Archiwa Państwowe]]. I co? I nic!Jak widać mamy bałagan... :( i chyba znowu popis niekompetencji... Metryka dałaby podstawy budowy spójnego systemu zarządzania wiedzą w administarcji. Niestety jak widać nowe ministerstwo popełniło albo falstart albo ktoś nie wie co robi...
zły model to złe oprogramowanie....Duży system ERP to setki i tysiące jego przypadków użycia, nie ma sensu ich specyfikowanie podobnie jak nie ma sensu pytanie o nie przyszłych użytkowników tego systemu bo nie są w stanie ich wyliczyć. Ma jednak sens zrozumienie tego jak firma działa. Po raz kolejny posłużę się metaforą [[Martina Fowlera]]: grę w snookera można opisać relacjonując (zapisując) setki kolejnych partii, ale i tak nigdy nie wyspecyfikujemy nawet ułamka możliwych zagrań. Zdecydowanie lepszą metodą jest przyjrzenie się kilku partiom i wychwycenie cech bili, ich ilości, wymiarów stołu oraz reguł gry, bo to będzie zgodne nie tylko z historią odegranych partii snookera ale z każda przyszłą partią.Dlatego zamiast prowadzenia żmudnych wywiadów i tworzenie nieskutecznej listy setek szczegółowych opisów możliwego użycia oprogramowania, lepiej jest zrozumieć organizację, stworzyć jej model (dziedziny) i wyspecyfikować jakie usługi ma to oprogramowanie świadczyć użytkowników teraz (bo tak należy rozumieć pojęcie przypadku użycia systemu). Poprawny model dziedziny pozwoli także na obsługę przyszłych wymagań mimo, że nie znamy ich teraz. Podobnie jak stół bilardowy: nie zna przyszłych uderzeń ale wiemy, że na pewno zostaną "obsłużone".
Swego czasu przewalała się w środowisku IT fala głosów za "certyfikacją zawodu informatyka". Po pierwsze pojawił się kłopot z definicją kim jest ów "informatyk", po drugie pojawił się kłopot z wykazaniem korzyści dla ogółu klientów, bo korzyść dla środowiska "informatyków" (co by to słowo nie miało tu oznaczać) jest prosta: ograniczenie dostępu do zawodu czyli jego monopolizacja. Zalety w rodzaju "podniesie się jakość usług" do mnie, i nie tylko do mnie, nie przemawiają. Nie wierzy w to nikt, kto ma w praktyce do czynienia z "certyfikowanymi" specjalnościami. Certyfikat (czyli po portu zdany test) to nic innego jak "wiem jak to robić" co nie ma nic wspólnego z "umiem to zrobić". Każdy (prawie) wie jak się biega, jak się robi zdjęcia, jak się śpiewa, wie (w końcu uczą tego w szkole podstawowej i średniej) jak się pisze książki i wiersze, wie .... większość z nas wie jak siw robi większość tego co mamy wokół siebie, czy jednak potrafimy?Certyfikaty itp. to w większości przypadków żadna gwarancja a nie raz wręcz odwrotnie.
