Zasady panujące na rynku produktów i usług IT wydają się przejrzyste: klient wydaje pieniądze na jakiś produkt, oczekując w zamian określonych korzyści. Jak wynika z udostępnionych przez Gartner Inc. analiz, firmy realizują przy okazji swoją strategię, o której wolałyby klientom nie mówić. Jakie są ich cele? […]

Omawiając strategie firm, Gaughan podkreślił również znaczenie działających przy nich ośrodków badawczych. Ich nadrzędnym celem jest tworzenie innowacji w takich sposób, aby ? zachowując pozory rozwoju ? utrzymywać istniejący stan rzeczy tak długo, jak to tylko możliwe.(źr.  What Microsoft, Oracle, IBM, And SAP Don’t Tell Customers)

Skąd się u wielu użytkowników technologii IT bierze dług technologiczny już w momencie podpisania umowy na wdrożenie? Stąd, że zlecono analizę przedwdrożeniową wymagań dostawcy technologii, a w jego interesie jest dostarczyć to co ma, a nie to czego potrzebuje klient.

Bardzo często tak właśnie definiuje się produkt analizy wymagań: wymagania funkcjonalne opisują to co ma system robić. W dyskusjach (ile mam ich za sobą :)) z programistami przebija się teza, że analityk specyfikuje to “co” system ma robić, a oni już załatwią sprawę tego “jak” ma to robić. W czym problem? W tym, że lista funkcjonalności to test rozwiązania (dostarczonego oprogramowania) a nie wymagania!

Pytanie moje brzmi: A co to znaczy “Jak”?

Czym jest owo “jak”? Kodem programu, logiką na niskim poziomie, logiką na wysokim poziomie? Spójrzmy na taki problem, wymaganie: klient wymaga by system pozwalał na wprowadzanie treści dokumentów, przekazywanie ich innemu pracownikowi wg. definiowanych reguł. Wiemy już co system ma robić. Tego typu systemów obiegu dokumentów (tak się je często nazywa) są dziesiątki, różnią się od siebie nieraz bardzo. Dlaczego?

Bo powyższy opis “co” system ma robić to stanowczo za mało, tak na prawdę nie definiuje on niczego poza tym, w jaki sposób może zostać wykorzystywany. Przypadek użycia jest dosłownie “przypadkiem użycia systemu”, ale przypadków użycia jest nieskończenie wiele. Na ile sposobów wykorzystujecie posiadane oprogramowanie?

Każdego dnia pojawia się  jakiś nowy problem do rozwiązania i użytkownik programu będzie musiał się z nim zmierzyć. Skoro w toku analizy wskazano skończoną liczbę przypadków użycia, to czy daje to prawo by ktoś, np. programista, nie znający analizowanego biznesu, uzurpował sobie prawo do “projektowania i kodowania” tego Jak ten system będzie to robił? Do kodowania na pewno na prawo, ale czy do projektowania także? Czym jest tu to projektowanie i co jest projektowane? Czym jest OOAD ([[Object Oriented Analysis and Design]], ang. analiza i projektowanie obiektowe)?

Zacytuje po raz kolejny metaforę z książki [[Martina Fowlera]]:

Wyobraźmy sobie kogoś, kto chce napisać program symulujący grę w snookera. Problem ten może zostać opisany przypadkami użycia opisującymi powierzchownie cechę: “Gracz uderza biała kulę, która przemieszcza się z pewną prędkością, ta po określonym czasie uderza czerwoną kulę pod określonym kątem, uderzona czerwona kula przemieszcza się na pewna odległość w pewnym kierunku.” Możesz sfilmować setki tysięcy takich uderzeń, zarejestrować parametry każdego uderzenia i jego skutki. Jednak ta metoda i tak nie stworzysz nawet dość dobrej symulacji. Aby napisać na prawdę dobrą grę, powinieneś raczej zrozumieć prawa rządzące ruchem kul, ich zależność od siły i kierunku uderzenia, kierunku itp. Zrozumienie tych praw pozwoli Ci znacznie łatwiej napisać dobre oprogramowanie.

Jak nie trudno się domyśleć analiza wymagań nie może trwać w nieskończoność, powstanie mało takich opisów scenariuszy. Tak więc tradycyjne metody, zapis wywiadów, obserwacje, ankiety, nie mają prawa się sprawdzić bo w skończonym czasie na analizę zawsze będzie ich za mało a i tak będą chaotyczne (będzie to tylko część tego co może się wydarzyć i nie wiadomo, która to część bo nie znamy wszystkich).

Przypadki użycia stanowią bardzo mierne przybliżenie rzeczywistości.  Oddanie programu do użytku, realizującego tylko “konkretne scenariusze” i to w sposób “obmyślony” przez programistę, który nie potrafi grać w snookera a tylko słyszał od gracza jak się to robi, najpewniej skończy się zabawą w kolejne iteracje, prototypy itp. Taki program będzie coraz lepszy ale nadal nie dotknie nawet realizmu snookera.

Znacznie lepszym wyjściem jest stworzenie modelu stołu i kul wraz z ich zachowaniem się, reakcjami na uderzenia. Kto powinien to zrobić? Ktoś kto dość dobrze grywa i rozumie snookera, ale nie koniecznie mistrz tej gry, a także znający jednak fizykę ciał stałych (tego raczej nie zna dobrze mistrz snookera). Taki model to nie przypadki użycia (te są tylko przykładami zastosowania) a model obiektowy zawierający obiekty takie jak kula, kij itp.

Czy taki model stworzy programista na bazie rozmów? Najczęściej nie! Co programista zrobi więc bardzo dobrze? Zapisze taki model w jakimś wybranym języku programowania ([[implementacja]]), zadba o to by możliwa była gra setek użytkowników, by możliwa była 24 godziny, siedem dni w tygodniu, wiele, wiele innych rzeczy ale nie model gry w  snookera.

Co najważniejsze: model taki nie może być żadnym uproszczeniem, gdyż odetnie to możliwość jego rozbudowy (nowe wymagania użytkownika, a te pojawią się na pewno) w przyszłości.

Inny przykład. Jeżeli początkowo projektujemy model pozwalający krawcowi projektować i szyć spodnie, nie powinniśmy projektować zamkniętej konstrukcji dwóch nóg, należy stworzyć model całego człowieka a w implementacji zawrzeć tylko jego część “od pasa w dół”. Będzie to pewien nadmiar ale jeżeli kiedykolwiek krawiec zechce poszerzyć ofertę o marynarki do tych spodni, będzie to proste rozszerzenie modelu a nie tworzenie go prawie od nowa. (tu kłania się DDD: ang. [[Domain Driven Design]] polegający na symulowaniu w projekcie OOAD bytów świata rzeczywistego).

Tak więc dokument wymagań to nie tylko przypadki użycia. Te są raczej testem poprawności rozwiązania, czy model jest poprawny (przypominam, że przypadki użycia, poza ich scenariuszami, zawierają stan początkowy i stan końcowy akcji użytkownika). Dokument wymagań to model (tu [[model dziedziny]]), który po zaimplementowaniu, będzie się zachowywał tak jak tego oczekujemy a przypadki użycia będą jedynie dowodem na to, że jest on poprawny. O czym tu mowa?

Jeśli model przypadków użycia to model tak zwanej czarnej skrzynki, to model dziedziny (bo tak się on nazywa) to tak zwana biała skrzynka. Tę białą skrzynkę także można przetestować. Jak? “Potraktować” ją przypadkami użycia (np. model kul i kija, kilka testowych uderzeń). Skoro mamy obiekty systemu (model, projekt rozwiązania), które reagują na bodźce, to znaczy, że możliwe jest “podanie” stanu wejściowego testowanego przypadku użycia modelu dziedziny i sprawdzeniu czy wytworzy on oczekiwany stan końcowy tegoż przypadku.

Model dziedziny to nie ten świat, o którym wielu myśli

Kolejna ważna uwaga: w oprogramowaniu nie projektujemy świata rzeczywistego (no chyba, że to będzie gra), projektujemy nasze narzędzia. Innymi słowy: w systemie nie modelujemy Dyrektora (on pozostanie żywy po wdrożeniu), modelujemy kartki papieru na jakich zachowujemy o nim informację w realnym świecie. Po co? By zamiast kartek użyć np. systemu kadrowo-płacowego, by wyliczył jego wynagrodzenie szybciej i bez błędów. Zły model (przypominam, system biznesowy to nie gra) zawiera klasę User, dobry model: UserInfo. Polecam książkę o metodyce analizy i modelowania [[Toold&Materials design]].

Narzędzia pracy

Tu niestety pojawia się pewna potrzeba: narzędzie. Czym ono jest? Notacja obiektowa UML. Po co to? Bo tworzenie i testowanie diagramów jest znacznie szybsze i tańsze (zrobi to analityk projektant) niż tworzenie wykonywalnego kodu zdatnego do testowania.

Dalej: oprogramowanie CASE. Czy jakikolwiek rozsądny fotograf dzisiaj pracuje nad zdjęciem cyfrowym z pomocą programu PaintBrusz? Edytuje poszczególne piksele “na piechotę”? Nie, korzystamy z PhotoShopa, Gimpa, itp. Jak nazwać wiec analityka, który modeluje z pomocą takich narzędzi jak PowerPoint a nawet Visio? Są narzędzia, pakiety CASE, zwalniające projektanta z  benedyktyńskiej pracy nad diagramami, może się skupić na treści. Aha: UML to nie generowanie programu, UML to analiza i modelowanie, to narzędzie dokumentowania swoich projektów. Dobry inżynier używa rysunku technicznego, w inżynierii oprogramowania jest to własne UML. Jak ktoś uważa, że UML jest bez sensu sam cofa się o dekadę w rozwoju.

Przykład

Na pewnym forum pojawiło sie takie zadanie, weźmy sytuację biznesową (cytat):

Mamy portal dla klientów. Klientem jest firma, która kupiła nasz produkt. Każda firma ma utworzone kilka kont użytkowników. Na portalu prezentowane są nasze produkty i jakieś dodatkowe ekstrasy dla nich.

Przypadek użycia:

Użytkownik [po zalogowaniu się] widzi tylko takie produkty, które jego firma kiedyś zakupiła.

Dla porządku diagram Przypadków Użycia:

Jak widać, wymaganie funkcjonalne nie za wiele mówi, na tej podstawie może powstać nieskończenie wiele rozwiązań. Prosty scenariusz: użytkownik żąda oferty, system wyświetla ofertę składająca się z wcześniej kupionych produktów. To także nie pomaga, to test tego czy system zrobi to co chcemy. Czego nam potrzeba? Potrzebujemy modelu wnętrza, który zasymuluje “system”, informacje które posiadamy, i odpowie oczekiwaną “ofertą”. Taki model to właśnie model dziedziny:

To nasze “kule do snookera”. Ale czy to dobry model? Czy przykładowy bodziec (żądanie oferty) da oczekiwany rezultat? Sprawdźmy to na modelu:

Co tu mamy? To symulacja tego co zrobiłby (powinien) przyszły gotowy program. Testowanie i projektowanie to proces iteracyjny: jeżeli powyższy model (diagram sekwencji UML) nie da oczekiwanego rezultatu (stan końcowy przypadku użycia) należ go poprawić. Po co takie zabawy? Zwróćcie uwagę ile obiektów jest na modelu dziedziny, czy jesteśmy w stanie to sobie wyobrazić ze szczegółami w głowie? Takich obiektów w dużym systemie będą dziesiątki! Okazji do pomyłki, brakujący obiekt, brakująca informacja itp. jest wiele.

Po takich testach (weryfikacja rozwiązania polega na “potraktowanie” modelu dziedziny wybranymi lub wszystkimi przypadkami użycia) uzupełnimy wszelkie ewentualne braki modelu. Po co? By tych braków nie odkrywać na etapie kodowania, bo to jest nawet 100 razy kosztowniejsze!

Ważna informacja: powyższe diagramy to za mało. Wywołanie operacji klasy, w większości przypadków, wymaga podania parametrów, odpowiedź stanowi np. obiekt lub ich kolekcja albo np. plik XML (lub inny strukturalny). Struktury tych obiektów opisywane są na odrębnych diagramach. Tak więc początkowe

Użytkownik [po zalogowaniu się] widzi tylko takie produkty, które jego firma kiedyś zakupiła.

pokazane na powyższym diagramie sekwencji, polega na tym, że GUI zażąda od Logiki listę nazw produktów sprzedanych firmie, do której jest przyporządkowany zalogowany użytkownik. Żądanie to, po sprawdzeniu logiki praw dostępu itp., zostanie przekazane do repozytorium Informacje, które zwróci kolekcję obiektów spełniającą powyższy warunek. Jedna ważna rzecz: powyższe to nie “przypadek użycia” a reguła biznesowa: widzi tylko takie produkty, które jego firma kiedyś zakupiła. Przypadkiem użycie jest raczej usługa aplikacji Zarządzanie historia zakupów.

Mamy więc koncepcje rozwiązania (tak zwany model logiczny). Powyższe diagramy są tu uproszczone, wymagały by na pewno dopieszczenia ale ilustrują ideę obiektowej analizy i projektowania koncepcji rozwiązania. Realne projekty są oczywiście większe ale nie zapominajmy, że duże projekty dzieli się (powinno) na mniejsze (mikroserwisy). Model dziedziny dzieli się na obszary dziedzinowe, (moduły, podsystemy) by każdy z nich pozwalał na łatwe testowanie jak powyżej. Po drugie doświadczony analityk szybko wychwyci, które podsystemy można kupić na rynku (tak zwane ang.  COTS, Commercial of the Shelf), a które należy zaprojektować do wykonania. Systemy złożone projektuje się na pewnym wyższym poziomie abstrakcji (metodologia top-down), ale stale jest to model i jego testowanie. Ale to tylko (dla użytkownika aż) tak zwana logika biznesowa.

Programiści!

Nikt Wam nie odbiera chleba, macie dużo pracy: po pierwsze implementacja metod (algorytmów) poszczególnych obiektów (np. podaj nazwy produktów, które już raz kupiono), macie zadbać o to: system ma być bezpieczny, wydajny, działać zdalnie na telefonach komórkowych, ma być bezawaryjny itd. To wymagania poza funkcjonalne (lub w niektórych metodykach tak zwane ograniczenia).  Macie dziesiątki problemów technicznych do rozwiązania.

Ale proszę, nie udawajcie, że znacie się na zarządzaniu, marketingu, biznesie, sprzedaży, rynku, produkcji itp. bo to (poza pewnie istniejącymi wyjątkami) nie prawda, a projektowanie na zasadzie “wydaje mi się że rozumiem” to droga do porażki.

Powyżej struktura najczęściej używanego, w metodach obiektowych, wzorca projektowego. Można uznać to za założenia projektowe, tak wygląda “każdy” system (używających innych wzorców przepraszam). Powyższy diagram pozwala jednoznacznie przyporządkować odpowiedzialność za projekt: analityk projektuje warstwę Model, programiści całą resztą. Przypadki użycia, perspektywa obiektu User, także znajdą się w dokumentacji wymagań.  Co jeszcze powinna zawierać taka dokumentacja? Ewentualne oczekiwania użytkownika do interfejsu użytkownika (w końcu to zobaczy, i tylko to). wcześniejsze diagramy to model dziedziny i jego testowanie. Daleki jestem od narzucania wykonawcy, w dokumencie wymagań, pozostałych elementów oprogramowania ale model biznesowy to nie robota dla programistów!

Taki projekt jak powyżej pozwala na dokładną wycenę, oszacowanie pracochłonności. Mamy “opis przedmiotu zamówienia”.  Model dziedziny opisuje komponent Model, wymagania pozafunckjonalne pozostałą resztę.

Proszę, nie wmawiajcie swoim klientem, że poza user story i przypadkami użycia nie ma innych metod opisu wymagań, nie wmawiajcie, że nie ma standardów i że trzeba “próbować” się starać, bo to po protu nie prawda. To, że ktoś czegoś nie widział (nawet przez lata swojej pracy) nie stanowi żadnego dowodu na to, że to nie istnieje.

Tak więc specyfikacja wymagań funkcjonalnych bez takich testów i bez modelu dziedziny tak na prawdę o niczym nie mówi.  Czym to grozi? Tym, że zamawiający najczęściej dostanie to co chce (potrafi) dostarczyć dostawca a nie to czego potrzebuje.

Jak to wygląda dla systemów ERP?

Jeśli z analizy wyjdzie, że np. 3/4 wymagań mieści się w możliwościach gotowych rynkowych systemów (owe COTS) to się wybiera gotowy ERP (wybrane moduły) spełniający opisane wymagania (tylko przypadki użycia i model kluczowych obiektów biznesowych takich jak np. faktura VAT). I to jest właściwa kolejność. Co będzie jeśli zaczniemy od  wyboru gotowego systemu? Chyba nie muszę już odpowiadać…

Systemy ERP to złożone , wielomodułowe produkty. Czy jest sens specyfikowanie skończonej liczby oczekiwanych funkcjonalności (przypadków użycia) by wybrać taki system? Będzie ich nawet kilka tysięcy! Nie! Ani tego nie zweryfikujemy ani nie sprawdzimy podczas odbioru systemu (powodzenia w takich testach odbiorowych). Więc jak?

System ERP można wybrać na bazie projektu, tu tylko na nieco wyższym poziomie abstrakcji. Analiza firmy także polega tu na opracowaniu modeli procesów. Jednak w tym wypadku ich celem jest stworzenie raczej “modelu filozofii działania” firmy a nie projektowanie systemu od zera. Założenie: system na rynku istnieje, należy go jedynie wybrać z pośród wielu istniejących. Do tego potrzebny jest model dziedziny i koncepcja architektury a nie setki wymagań funkcjonalnych.

Najpierw dostawca systemu ERP i wykonana przez niego analiza przed wdrożeniowa czy może jednak najpierw analiza wymagań? Zadam to samo pytanie inaczej, coś z Państwa podwórka: najpierw analiza mieszkania i pomysł na meblowanie a potem jazda po sklepach i szukanie mebli, czy może najpierw dajemy sobie sprzedać meble a potem wciskamy je w nasze pokoje (plus osławiona ich kastomizacja)? Państwo sami musza podjąć decyzję, ryzyka opisałem. Powiem tylko tyle: warto zmierzyć dobrze mieszkanie, opracować pomysł, kupić na rynku to co pasuje,  a pozostałe zakamarki zlecić dobremu stolarzowi, który wpasuje meble i ładnie połączy je z już kupionymi.

A skąd brać te przypadki użycia?

Najgorsza metoda, bo nie poddająca się testowaniu (weryfikacji), to: wywiady, ankiety, warsztaty i podobne metody deklaratywne. Dostaniemy setki niespójnych wymagań, nie raz będących efektem wewnętrznych wewnętrznych negocjacji, rozgrywek (tak, niestety). Powstanie nieweryfikowalna lista na setki pozycji. Jak inaczej?

Analizujemy firmę, tworzymy jej model procesowy jak na diagramie powyżej. Model procesów testujemy z pomocą realnych dokumentów. Po takich testach, wybieramy na tym modelu te czynności, które uznamy za nasze wymagania. Praktyka pokazuje, że jest ich tak na prawdę dziesiątki a nie setki (są to logiczne czynności z ewentualnymi wariantami). Nie możemy się tu pomylić bo mamy przetestowany model procesowy firmy.  Jednak ten model także (podobnie jak modele UML) musi podlegać testom i formalizacji (najlepiej zastosować formalną, pozwalająca na testowanie, notację, np. BPMN – powyższy diagram). Bez tego, model procesów nie będzie lepszy od opisu słownego. Ale o tym już było 🙂 (i pewnie jeszcze będzie).

(więcej o przejściu z procesów na przypadki użycia: transformacja modelu procesów na model przypadków użycia)

Zamawiających nie stać na takie analizy jak powyżej.

Czyżby? Taka analiza to ok. 20% budżetu prac programistycznych i 50% czasu projektu. Bez niej jednak projekt płynie w user story, prototypy, odkrywanie wymagań w trakcie projektu, iteracje (Agile?), termin jest przesuwany kolejny raz. Klient płaci. Badania wykazują (i deklarują to także wykonawcy, czytaj poprzednie moje posty z cytatami, gorąco polecam blogi programistów i ich opinie o userach oraz analitykach i sprzedawcach ich firm!), że w konsekwencji kosztuje to  200% planu pierwotnego (typowy narzut dostawców oprogramowania, patrz diagram poniżej, bywa że narzucają nawet 500% na niewiedzę i niezrozumienie) !!!!!!

Powyższa metoda pozwala by projekt miał to co powinien mieć: dobrze określony zakres projektu (opis przedmiotu zamówienia) a na jego podstawie dobrze oszacowany budżet (rentowność!) i termin wykonania.

Nikt tego nie rozumie czyli kto i co czyta: adresaci dokumentów

Często innym, poza budżetem, argumentem przeciwko takim analizom jest zarzut: “Klient nie rozumie modeli ani diagramów więc po co je robić”. A kto powiedział, że Klient ma je czytać! Klient jest przede wszystkim źródłem wiedzy o własnej firmie, weryfikuje model procesów z pomocą analityka, ustala zakres projektu, sprawdza i potwierdza biznesowy opis swojej firmy i jej potrzeby. Potem zatwierdza ewentualne prototypy ekranów.

Ten zarzut niestety często stawiają także niekompetentni dostawcy, nie potrafiący nic innego poza eksperymentami, prototypami i zjadaniem budżetu Klienta: im więcej tym lepiej…

Modele procesów to narzędzie analityka, modele UML także ale te czyta wykonawca (jak wykonawca nie potrafi czytać UML to on ma problem, a nie analityk czy klient.!). To dokładnie tak jak z mieszkaniem: projektant wnętrz słucha klienta i pokazuje mu efekt pracy: wizualizację. Potem opracowuje dokumentacje techniczną dla stolarza, rysunki techniczne, nazwy materiałów. Tego klient faktycznie raczej nie rozumie ale nie dla niego są te dokumenty. Jednak dobry stolarz to twórczy inżynier, potrafiący wykonać projekt i nie wciska klientowi, tańszych materiałów, nie upraszcza finezyjnych zwieńczeń szafy bo po protu psuje.

Jak wiemy stolarze są różni dlatego coraz częściej projektanci wpisują do swoich umów tak zwany nadzór autorski nad realizacją. Ja także tak robię.

Dla zainteresowanych nieco więcej na ten temat na stronach MSDN:

http://msdn.microsoft.com/en-us/library/dd409376.aspx

Wstęp

Swego czasu brałem udział w burzliwiej dyskusji (zresztą niejednej) na temat sensu prac analitycznych i projektowych przy okazji wdrażania systemów ERP, czyli gotowego oprogramowania (przeczytaj artykuł). Większość dostawców tego oprogramowania, z jakimi miewam kontakt, uważa, że analiza owszem ale w celu opracowania koncepcji wdrożenia, czyli dokumentu mówiącego jak dostosować system ERP do potrzeb klienta z naciskiem na słowo kompromis. Pojawia się prędzej czy później święte słowo kastomizacja, które po protu oznacza najczęściej przerabianie gotowego produktu (nie raz bardzo dobrego do momentu gdy się go nie popsuje tymi przeróbkami, przeczytaj i ten artykuł).

Kastomizacja a parametryzacja

Niedawno pisałem, że

gotowe oprogramowanie należy zostawić nietknięte (nie licząc okienek konfiguracji) a brakujące funkcjonalności opracować, zaprojektować i zintegrować.

Z reguły jak tylko wypowiem tę kwestię, lecą na mnie gromy ze strony konsultantów dostawców ERP. Jednak warto te metodę stosować co potwierdzają nie tylko moje doświadczenia:

Eksperci podkreślają bowiem, że większość kosztów generowanych przez projekt wdrożeniowy nie ma nic wspólnego z kosztem samego oprogramowania. ?Średnio trzy czwarte budżetu pochłaniają koszty wdrożenia, modyfikacji standardowej funkcjonalności oraz modernizacji sprzętu? ? czytamy w raporcie Panorama Consulting Group. […] O systemach klasy ERP coraz częściej mówi się, że są zbyt rozległe, ociężałe i ograniczają możliwości biznesu, od którego wymaga się zwinności i elastyczności. Czy czasy takich systemów już przemijają?? (źr. IDG, 2010r)

Stale śledzę to co się dzieje na rynku systemów IT wspomagających zarządzanie obserwuję taki własnie kierunek rozwoju:

Systemy zintegrowane ERP będą pewnymi zestawami gotowych funkcjonalności, zbudowanymi w oparciu o szkielety oprogramowania zaś integracja będzie bazowania nie na współdzieleniu danych a na wymianie ich pomiędzy modułami i zewnętrznymi systemami na równych prawach. Rozwój systemu w takim przypadku polega na tworzeniu nowych modułów tym środowisku a nie na modyfikacji już istniejących.

Kierunek ten już widać od ok. dwóch lat na rynku (ja o tym pisze od ponad pięciu), prace te więc trwają zapewne  znacznie dłużej. Widać to na stronach niektórych dostawców, liderów na rynku:

Dynamics AX 2009. Framework (szkielet, przyp. mój) to zestaw wzorców projektowych, interfejsów, gotowych bibliotek i innych narzędzi. Elementy te dają wsparcie programistom. Najlepszą praktyką jest sięganie do tych zasobów i wykorzystywanie ich zamiast tworzyć własne podobne. Tu opisano framework, podsystemy i funkcjonalności Microsoft Dynamix AX (źr. Frameworks Introduction).

Obecnie standardem jest stosowanie w framerworkach, przeznaczonych do tworzenia oprogramowania biznesowego w środowisku przeglądarek WWW, (i nie tylko) wzorca projektowego MVC:

Wzorzec MVC pomaga tworzyć aplikacje rozdzielając trzy różne aspekty oprogramowania: interfejs użytkownika, logikę biznesową oraz zachowanie systemu, poprzez zachowanie minimalnych wzajemnych zależności. Wzorzec opisuje gdzie każdy z elementów tej logiki umieszczać. Interfejs użytkownika obsługuje widok (view). Sterowanie aplikacją obsługuje kontroler (controller). Logika biznesowa zawarta jest w modelu (model). Ta separacja pomaga zarządzać złożonością oprogramowania podczas jego tworzenia, ponieważ pomaga skupić się w danym momencie na jednym tylko aspekcie problemu.  (źr. MSDN MVC Overwiew)

Inny przykład podejścia do otwarcia się:

Tu mamy coś w rodzaju fasady ([[wzorzec projektowy fasada]]) dla IFS Application (materiały z publicznej strony WWW), którego nowa wersja to już nie środowisko procedur w Oracle DBMS a serwer aplikacyjny Java J2EE (ciekawe ilu programistów Java mają na etatach dostawcy IFS’a). Zapewne powyższe to nie jedyne przykłady tego rodzaju rozwiązań ERP na rynku (firmy chcące uzupełnić ten artykuł mogą mi przesłać stosowne materiały).

Tak więc da się, trzeba nie tylko chcieć ale i potrafić. Tu mała łyżka dziegciu do garnuszka integratorów i dostawców ERP: najczęściej nie potrafią i mam wrażenie, że nie chcą bo, jak już w poprzednim artykule pisałem, nie jest to w ich interesie.

Model biznesowy dostawców gotowego oprogramowania to w większości przypadków brak kosztów tworzenia własnego produktu i jego rozwoju i budowanie marży na cudzym produkcie. Oferowany jest cudzy produkt wraz usługą  jego wdrożenia. Firma taka stanowi kanał sprzedaży producenta tego oprogramowania. Problem w tym, że od pewnego czasu rynek się zmienia: gotowe produkty bez modyfikacji nie mają tu (zarządzanie) racji bytu a mam wrażenie, że dostawcy ERP starają się za wszelka cenę unikać dostosowań. Dlaczego? Bo ich model biznesowy własnie w większości przypadków nie przewiduje utrzymywania bardzo kosztownego zespołu analityków, projektantów i programistów.

Czy mam rację? Przejrzałem co nieco ogłoszeń o prace dostawców ERP, z tego co zebrałem skompilowałem najczęściej powtarzające się oczekiwania:

Konsultant systemów ERP

Osoba będzie członkiem zespołu biorącego udział w procesie wdrażania systemu ERP (analiza, konfiguracja, szkolenia) oraz zapewniającego bieżącą obsługę i serwis istniejących wdrożeń.

Opis stanowiska pracy

• współpraca z klientem oraz doradztwo merytoryczne
• udział w analizach wdrożeniowych
• zaawansowane wsparcie dla obecnych klientów systemów
• udział we wdrażaniu systemów
• przeprowadzanie prezentacji produktów u klienta
• prowadzenie szkolenia dla klientów
• wsparcie użytkowników systemu
• prowadzenie dokumentacji technicznej,
• zarządzanie zmianami w systemie,
• szkolenie końcowych użytkowników,

Oczekujemy:

• 2-3 letniego doświadczenia we wdrożeniach systemów klasy ERP
• zdolności analitycznego myślenia
• umiejętności rozwiązywania problemów
• doświadczenie we wdrażaniu systemów
• ogólna orientacja w procesach biznesowych i chęć pogłębiania tej wiedzy,
• znajomość metodyki zarządzania projektami wdrożeniowymi
• znajomości SQL

To ostatnie (SQL) pojawia się od czasu do czasu, to kompetencja wymagana do tworzenia nowych raportów w systemie. Gdzie tu jest inżynieria oprogramowania? Czy w państwa wdrożeniach poza konsultantami brali udział analitycy projektanci i programiści czy tylko konsultanci wpadający po to by pozmieniać coś w systemie (powodując nie raz uszkodzenia w innych jego częściach)?

Tak więc co mogę poradzić? Bardzo dokładne przyglądanie się rozdziałom oferty pod tytułem Dostosowanie systemu, Koncepcja wdrożenia oraz ile oczekiwanych przez Państwa  funkcjonalności to te, których system w swej wersji standardowej nie oferuje. Powinny one być po dokładnej analizie, zaprojektowane i zaimplementowane.

Jeżeli Konsultanci zaczynają negocjować rezygnację z części oczekiwań lub oferują coś podobnego w systemie, to pierwszy sygnał, że powinien ktoś im zacząć patrzeć na ręce, i nie mam tu na myśli ich przełożonego.

Na zakończenie list jednego z moich klientów, nazwał bym to typowym problemem:

Planujemy wdrożenie nowego oprogramowania, chcemy tym razem uniknąć presji ze strony dostawcy oprogramowania. Poprzednim razem dostawca oprogramowania upraszczał sobie pracę, już na etapie analizy, którą wykonywał sam. Analiza wymagań polegała na wywiadach i warsztatach grupowych, skończyła się zwykłym opisem, tabelkami i kilkoma nieczytelnymi schematami. Podczas analizy i wdrożenia stale wmawiano nam, że “tego nie można”, “to należy uprościć” albo “tak się nie robi” my zaś nie potrafiliśmy tego ocenić. Wiele naszych potrzeb odkrywaliśmy dopiero podczas instalacji kolejnych prototypów, zaś dostawca unikał wprowadzania zmian i obiecanych dostosowań. Dostaliśmy w efekcie nieprzydatne i niezgodne z biznesowymi potrzebami oprogramowanie. Czy może nam Pan tym razem pomóc?

P.S.

Nie jestem w żaden sposób związany z dostawcami produktów wymienionymi w artykule. Ich nazwy zostały wskazane wyłącznie z szacunku dla praw autorskich cytowanych treści.

Okres wakacyjny (kiedy to było …) zaowocował stosem zaległej literatury…. Dziś przyszła pora na zaległe numery Software Developer Journal. Czasopismo adresowane głównie do programistów i architektów ale jako analityk i ja także znajduje tam nie raz coś ciekawego.

(more…)

Przewiduję powolne odchodzenie od idei systemów zintegrowanych na jednym modelu danych. Dotychczasowa ich zaleta czyli pełna (i zarazem trwała) integracja przestaje być zaletą a staje się garbem. System zintegrowany można już “skleić” ze specjalizowanych aplikacji, komponentów. Technologia komponentowa bardzo ten proces ułatwiła. Drugim powodem przewidywanego odejścia od tej idei są ogromne kłopoty z oceną rentowności wdrożenia systemu ERP. Nie raz jest to po prostu wręcz niemożliwe z powodu braku możliwości oceny jakim kosztem wspieramy pojedynczy proces biznesowy bo trudno z jednego ogromnego systemu wykroić koszt wsparcia pojedynczego procesu. Z tego też powodu rośnie zainteresowanie systemami typu middleware (szyny ESB). Do tej pory były wykorzystywane rzadko i dużych firmach, głównie w sektorze finansowym i głownie z uwagi na ich koszt. Obecnie rozwiązanie to staje się coraz popularniejsze. Dlatego?

Pojawienie się standardów w modelowaniu, ustanowienie modelowania pełnowartościowym etapem projektu (a nie ekstrawagancją), otwieranie się technologii, pojawianie się standardów wymiany metadanych i modeli, torują drogę do znacznego obniżenia kosztów i usprawnienia tworzenia systemów opartych o komponenty. To wszystko powoduje, że nie trzeba jednego wielkiego systemu zintegrowanego. Wystarczy tak zwany motor procesów biznesowych i specjalizowane systemy, mogą one pochodzić od różnych producentów i pracować na różnych platformach.

Jedyne czego trzeba przestrzegać to praca od samej góry: model biznesowy organizacji, model procesów biznesowych, struktura workflow (scenariusze działań czyli wewnętrzny opis procesów), lista oczekiwanych usług systemu IT i sam system składany z komponentów. Te trzy elementy: model biznesowy, model procesów, usługi IT stanowią pewną całość. Ubranie opisu usług w ciało to właśnie obiektowe/komponentowe technologie w IT, architektura SOA i MDA, języki i notacje BPMN, UML oraz format danych XML, obiektowe języki programowania.

Koniec quasimonopolu dostawców systemów

No i okazało sie, że standardy sprawdzone same się bronią. Microsoft w BizTalk Server będzie wspierał BPEL (Business Proces Execution Language, oparty na XML język skryptowy opisu procesów między innymi w systemach BPM i workflow management używany już między innymi w niektórych systemach CASE). Oracle także “rozumie” BPEL. Modelowanie staje się normą a otwartość standardem. Notacje UML i BPMN stają się standardem modelowania.

Co to znaczy? Moim zdaniem to, że powoli staje się coś o czym pisałem swego czasu na stronach IT-Consulting. Monopolistę zaczęli doganiać konkurenci. Monopolista zaczyna czuć pokorę: już nie wyznacza sam standardów de’facto (np. formaty plików dokumentów, narzędzia programistyczne, interfejsy komunikacyjne). Tracąc powoli rynek na rzecz rozwiązań konkurencji dostrzegł, że to co było przewagą rynkową (zamknięte rozwiązania) stało się w dalszej perspektywie hamulcem. Przyszła pora na otwartość i konkurowanie jakością a nie szantaż ponad 80% udziałem w rynku (vide współpraca Microsoft i Novell).

Kierunki rozwoju systemów IT

Albo analiza procesowa i obiektowa albo na margines życia. Coraz powszechniejsze zrozumienie idei zorientowania na procesy, interoperacyjności (w tym zarządzanie łańcuchami dostaw), architektury SOA (która moim zdaniem doskonale się wpasowuje w metody zarządzania zorientowanego na procesy i reorganizację w firmach) powoduje stawianie takich wymagań także dostawcom rozwiązań IT. Te które się do tego nie dostosują, moim zdaniem odejdą z rynku.

Model biznesowy firmy, informacje i dane jakich firma wymaga do sprawnego funkcjonowania to już jeden organizm. Stało się faktem, że żadna firma na rynku już nie będzie w stanie konkurować bez sprawnego zarządzania informacją. Do zarządzania informacją i przetwarzania danych zaś potrzebne są sprawnie działające i przede wszystkim łatwe w ich rozwijaniu systemy. Warunek taki spełniają obecnie zorientowane na procesy systemy tworzone w technologiach obiektowych.

Drugi warunek sprawności organizacji to optymalizacja jej wewnętrznej wydajności. Tu wkraczamy dla odmiany w zarządzanie i jego procesową naturę. Jak to pogodzić? Postrzegam tu właśnie miejsce dla architektury SOA. Firmę i jej miejsce w rynkowym łańcuchu wartości można, moim zdaniem, jednoznacznie opisać tylko za pomocą modelu procesowego zorientowanego na produkty. Zasoby (tu system IT) potrzebne do realizacji tej strategii analizujemy już obiektowo.

Namiastką takich opisów i analiz były procedury w księgach jakości ISO. Do pełnej analizy wymagany jest jednak opis (mapa procesów) uwzględniający cały obraz firmy. SOA to architektura wskazująca naturalny proces projektowania systemów IT: model procesowy firmy (organizacji), analiza procesów z perspektywy zasobów IT jakimi mogą być wspierane, na bazie tej analizy powstaje lista usług na rzecz procesów biznesowych jakich oczekujemy od nowego systemu.

Następnie w procesie analizy obiektowej usługi te transponowane są na model obiektowy przyszłego systemu IT. Analiza obiektowa powinna dać jako produkt także opis dziedziny systemu czyli reprezentację rzeczywistych obiektów w systemie. Jest to podstawa modelu danych dla powstającego systemu. Kolejne etapy to już projekt obiektowego programu (aplikacji) i jego implementacja.