Od czasu do czasu jestem pytany o różne „frameworki” i metodyki dotyczące „całościowego opisu firmy”. Można spotkać wiele różnych, lepszych lub gorszych modeli i szablonów, ram (frameworków), jednak moim zdaniem, podejście minimalistyczne (patrz [[brzytwa Ockhama]]) jest najlepsze. Zmusza do zrozumienia istoty rzeczy, bez maskowania niewiedzy nowymi i, nie raz, sztucznymi pojęciami. Drugim powodem, który moim zdaniem leży u podstaw pomysłów na „nowe modele”, jest prawo autorskie. Opracowanie unikalnego „frameworka” czyni z autora takiego dzieła „właściciela metody”, za którą ma prawo pobierać opłaty licencyjne (przykładem jest np. TOGAF i notacja ArchiMate chronione prawem autorskim przez komercyjną organizację The Open Group).
Takich „frameworków” jest więcej, tu dwa inne przykłady na poparcie mojej tezy, TOM:
Target Operating Model (TOM). Once you’ve articulated your strategy, one of the next things to do is to design the organisation to deliver it. This is usually expressed in the form of a Target Operating Model (TOM). The general approach is to define the people, processes and technology required to deliver the strategy. (za How to design a Target Operating Model (TOM)).
albo ten nazwany 7s:
McKinsey and Co’s 7S framework provides a useful framework for analysing the strengths and weaknesses of an organisation (see also 7 Essential Strategy Analysis Tools). The McKinsey Consulting Firm identified strategy as only one of seven elements exhibited by the best managed companies. (za McKinsey 7‑S).
Osobiście stosuję (i nie ja jeden) darmowy i dobrze opisany (moim zdaniem znaczniej lepiej niż powyższe) spójny zestaw systemów pojęciowych rodem z OMG (www.omg.org, dostęp publiczny, nie wymagający żadnych opłat licencyjnych). Powyższe „potrzeby” czyli połączenie pojęć: ludzie, zasoby, wiedza, procesy, połączenie w jeden mechanizm, wyglądają tak:
(opracowanie własne autora na bazie specyfikacji notacji OMG.org)
Łącznikiem jest abstrakcja, jaką jest proces biznesowy. Proces biznesowy jako byt, nie ma w organizacji zmaterializowanej postaci, jednak jest elementem (pojęciem) łączącym wiedzę (dokumenty), ludzi i ich umiejętności, ich strukturę oraz reguły rządzące tym jak powstają produkty procesów. Proces biznesowy to mechanizm łączący pojęcia opisujące organizację. Są to takie pojęcia jak: wiedza, reguły biznesowe, procedury, ludzie i ich struktura organizacyjna, narzędzia pracy (w tym oprogramowanie). Całość jest powiązana razem (o tych powiązaniach pisałem w artykule Modelowanie w projektach integracyjnych). Dysponujemy kompletem notacji pozwalających opisać organizację „od stóp do głów”: [[BMM]] w sferze motywacji biznesowej, [[BPMN]] w sferze przepływu pracy oraz [[UML]] w sferze systemów. Opisałem to w artykule Architektura korporacyjna z OMG.org.
Tak więc po co mnożyć byty? Profesjonalne narzędzia CASE, pozwalają na wykorzystanie opisanych tu notacji (tych chronionych prawami autorskimi notacji, raczej nie obsługują albo robią to za dodatkową opłatą), OMG dba bardzo dobrze o ich spójność pojęciową (opisana w artykule o SOA). Wydaje mi się, że „nowe systemy i frameworki” nie wnoszą żadnej nowej wartości, budują jednak – gdy ich użyć – pewne uzależnienie od ich twórców.
BIO: Od roku 1991 roku, nieprzerwanie, realizuję projekty z zakresu analiz i projektowania systemów, dla urzędów, firm i organizacji. Od 1998 roku prowadzę także samodzielne studia i prace badawcze z obszaru analizy systemowej i modelowania (modele jako przedmiot badań: ORCID). Od 2005 roku, jako nieetatowy wykładowca akademicki, prowadzę wykłady i laboratoria (ontologie i modelowanie systemów informacyjnych, aktualnie w Wyższej Szkole Informatyki Stosowanej i Zarządzania pod auspicjami Polskiej Akademii Nauk w Warszawie. Oświadczenia: moje badania i publikacje nie mają finansowania z zewnątrz, jako ich autor deklaruję brak konfliktu interesów.
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ł).
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,
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.
BIO: Od roku 1991 roku, nieprzerwanie, realizuję projekty z zakresu analiz i projektowania systemów, dla urzędów, firm i organizacji. Od 1998 roku prowadzę także samodzielne studia i prace badawcze z obszaru analizy systemowej i modelowania (modele jako przedmiot badań: ORCID). Od 2005 roku, jako nieetatowy wykładowca akademicki, prowadzę wykłady i laboratoria (ontologie i modelowanie systemów informacyjnych, aktualnie w Wyższej Szkole Informatyki Stosowanej i Zarządzania pod auspicjami Polskiej Akademii Nauk w Warszawie. Oświadczenia: moje badania i publikacje nie mają finansowania z zewnątrz, jako ich autor deklaruję brak konfliktu interesów.
Przyszła w końcu pora na model dziedziny systemu i model sekwencji dla przypadków użycia. Wspomnę także o wymaganiach niefunkcjonalnych? W poprzednim artykule: Diagram klas ? czyli ?reinżynieria? analizy biznesowej c.d. Przypadki użycia i granice systemu opisałem proces do powstania opisu przypadków użycia. Mamy za sobą podstawową pracę z dziedziny jaką jest [[analiza systemowa]]. Postawiliśmy problem do rozwiązania: jakie oprogramowanie powinno powstać. Pod pojęciem jakie należy rozumieć: co powinno ono robić. Opracowano model, przetestowano go. Oceniono dwa warianty (w dużym skrócie ;)), w drugim wariancie obsługa płatności została zlecona partnerowi ([[outsourcing]]) i podjęto racjonalną decyzje o wyborze tego wariantu.
Po tej decyzji mamy zamknięty zakres wymagań: system ma rejestrować zamówienia i pozwalać na natychmiastowe dokonanie płatności. Wiemy także, że nasz system jest częścią większej całości. Outsourcing to decyzja hipotetycznego sponsora projektu na bazie otrzymanych informacji. Koniec analizy biznesowej.
Pora iść dalej. Tym razem problem brzmi: kto i w jakiej technologii ma wykonać to oprogramowanie. Znowu przydały by się warianty czyli różne oferty wykonania tego oprogramowania. Czego nam brakuje by oferty były porównywalne? Modelu tego co należy wykonać! Czy można jako element takiego zapytania dać model przypadków użycia? Z jednej strony można powiedzieć, że owszem. W końcu mamy dokładny opis tego, jakimi cechami (funkcjonalności) ma się charakteryzować to co otrzymamy. I robi tak większość firm. Gdzie widzę kłopot? Zapewne część czytelników zauważyła już, że pominąłem wymagania poza-funkcjonalne.
Dygresja budowlana – pouczająca przygoda
Wyobraźmy sobie, że chcemy zlecić budowę domu. Jego funkcjonalności to między innymi: oddzielne miejsca do spania oraz czytania i oglądania telewizji (tak zwany salon). Kuchnia złączona z salonem. Łazienka na każdym piętrze. Wejście z zewnątrz do salonu poprzez mały przedpokój. Garaż połączony z przedpokojem. I jeszcze wiele innych. Wymagania poza-funkcjonalne, tych może być ogrom! Dom ma być ładny, nie może być podobny do domu sąsiada, musi spełniać wymagania prawa budowlanego, kolorystyka dachu powinna być skorelowana z elewacją, bieżące koszty ogrzewania powinny być możliwie jak najniższe, dom powinien dać się w przyszłości łatwo rozbudować o dwa nowe pomieszczenia. Dom powinien być przygotowany do potencjalnej instalacji komputera w każdym pokoju. Powinno być możliwe zainstalowanie klimatyzacji w ciągu trzech lat od zakończenia inwestycji.
Taki dokument może mieć dziesiątki stron, weryfikacja jego treści (spójność, techniczna niesprzeczność, inne) może być trudna. Opracowanie go w gronie np. czteroosobowej rodziny będzie wyzwaniem już tylko w kategoriach negocjacji ;). Żeby zabezpieczyć się przed „interpretacją” wykonawcy dokument będzie obrastał w szczegóły, ale takie o których pomyślą autorzy dokumentu: rodzina. Jakie mają w tym doświadczenie? Większość tych oczekiwań to własnie poza funkcjonalne życzenia!.
Jak uniknąć tej benedyktyńskiej pracy, której ryzyko rośnie wraz z rozrostem dokumentu? Idziemy do architekta. Nasza rodzina idzie do architekta, ten na bazie powyższych opowieści doprowadza do jakiejś koncepcji rozwiązania (projekt wstępny, koncepcyjny). W momentach sporu pełni role mediatora (łazienka ma być przy salonie czy przy pokoju dzieci), pokazuje na modelu (projekt koncepcyjny, który ewoluuje w trakcie takiej rozmowy) wady i zalety obu rozwiązań, pozwala rodzinie podjąć świadomą decyzje. Zaletą wizyty u architekta, zanim zapytamy jakiegokolwiek developera, jest to, że architekt jest wolny od jakichkolwiek uprzedzeń czy przyzwyczajeń. W każdej dziedzinie inżynierii wykonawcy są wyspecjalizowani, jeśli damy im wybór, będą stosowali technologie najmniej ryzykowne dla siebie (najlepiej poznane) a nie optymalne dla inwestora i to jest oczywiste.
Dlatego warto najpierw iść do architekta, ten nieskażony technologiami (bo nie ma w tym żadnego interesu), opracuje nam projekt funkcjonalny, ale zawierający pewne szczegóły rozwiązań (np. zabroni budowy betonowej ściany w miejscu gdzie my oczekujemy przyszłej rozbudowy). Popatrzymy na coś, co potrafimy szybko ocenić nie tylko od strony wymagań funkcjonalnych (muszla pod półką spełnia stawiane jej wymagania ale czy jest to wygodne?) Na projekcie od razu wychwycimy, czego w tekście opisu raczej nigdy: elementy estetyki, wygody, podjęte kompromisy będą dla wszystkich zrozumiałe i nie będą w przyszłości podważane.
Diagram klas czy model dziedziny – co ma powstać?
(programiści mogą to pominąć)
Otóż [[diagram klas]] ([[UML]]) to narzędzie podobne do rysunku technicznego. Ważne jest to co on przedstawia i to należy najpierw zdefiniować (dopóki nie wiem czy mam napisać: książkę czy rozdział podręcznika, nie wiem co mam w tym języku wyrazić). Tak więc coś należy założyć. Podstawowym założeniem jakie tu przyjmę jest: nie tworzymy oprogramowania od zera. A wiec od czego? Wiele firm programistycznych używa gotowych szkieletów oprogramowania, tak zwanych [[framework]]ów. Są to gotowe, najczęściej dziedzinowe (adresowane dla konkretnej dziedziny zastosowań) biblioteki podprogramów (klas w technologiach obiektowych).
Obejmują zazwyczaj typowe,uniwersalne funkcjonalności takie jak logowanie, wyświetlanie treści na ekranie, zapis do bazy danych (a tak na prawdę utrwalanie, bo baza danych to nie jedyny sposób) , sterowanie zachowaniem się aplikacji, elementy bezpieczeństwa i wiele innych. Funkcjonalności większości biznesowych aplikacji można podzielić na trzy grupy: sterowanie programem, obsługa interfejsu użytkownika oraz funkcjonalności specyficzne dla dziedziny (miejsca) zastosowania. Mamy więc dziedzinę problemu, interfejs użytkownika i sterowanie całością. Innymi słowy mamy: Model, View (widoki), Controller (sterowanie) czyli najpopularniejszy obiektowy wzorzec projektowy aplikacji o wdzięcznej nazwie [[MVC]].
Wniosek z tego taki, że jeśli założymy, że taki szkielet zostanie użyty (a możemy to zapisać w wymaganiach poza-funkcjonalnych dla wykonawcy) to pozostaje po zakończonej analizie biznesowej dokonać analizy obiektowej i zaprojektować [[model dziedziny systemu]]. Narzędziem do jego pokazania jest właśnie diagram klas notacji UML.
Model dziedziny systemu Zamówienia
Tak więc wszystko jasne 🙂 wiec do roboty. Pierwszy etap to opracowanie listy obiektów biznesowych. Tu wkracza kolejna metoda, która stosuję: obiekty dzielimy na narzędzia i przedmioty przetwarzane z pomocą tych narzędzi, pamiętamy, że tego wszystkiego ktoś używa: nasz aktor. Prosty przykład: Do wystawienia faktury potrzebne są: formularz faktury (oczywiste) i fakturzysta (ktoś musi wiedzieć co należy zrobić). Pierwszy stopień innowacji: kalkulator dla fakturzysty. Kolejny stopień to elektroniczny formularz. Obiekty biznesowe: wzór formularza faktury, kalkulator, fakturzysta oraz oczywiście kuwetka na wystawione faktury. Dlaczego tak?
Kolejna metoda analizy i projektowania powiązana z wzorcem MVC: [[Domain Driven Design]] (projektowanie oprogramowania bazujące na modelu dziedziny systemu) czyli DDD. O co tu chodzi? Ogólnie o to by projektować oprogramowanie dość wiernie symulując (a raczej odwzorowując) poznaną rzeczywistość. Dlaczego? Bo osiągamy bardzo ważną korzyść: nawet jeżeli nie uda nam się odkryć sensu istnienia jakiegoś obiektu, mimo wszystko modelujemy go bez uproszczeń, dzięki temu w przyszłości, rozwijając system, nie nadziejemy się na problem wywołany takim uproszczeniem gdyż takie początkowe uproszczenie staje się nie raz poważnym ograniczeniem. Druga zaleta: model taki jest relatywnie łatwiejszy do percepcji niż model z uproszczeniami, w szczególności totalnie niestrawny dla zwykłych ludzi (czyta: nieweryfikowalny przez zamawiającego) [[model relacyjny w trzeciej postaci normalnej]]. Tu bardzo przepraszam czytelników biznesowych, że użyłem niezrozumiałych zapewne dla nich pojęć, ale to właśnie pokazuje, że na tym etapie zamawiający traci kontakt (zrozumienie) z wykonawca tego co sam zamówił zamawiający.
Z modelu procesu dowiadujemy się, że następujące obiekty biorą udział w realizacji potrzebnych nam funkcjonalności: Formularz Zamówienia i koniec! Na pewno? Nie 🙂 bo chcemy by jednak by był to automatyczny system internetowy, wiec potrzebny jest Zarządca. On wie: jak przyjmować Zamówienia oraz skąd brać dane i gdzie je wysyłać. Klient (zamawiający) jest tu aktorem i nie jest on absolutnie obiektem biznesowym do implementacji. Mamy więc dwa obiekty biznesowe: Zarządca i FormularzZamówienia. Do tego mamy interfejsy dla ERP i do Płatności. A gdzie baza danych? Nie ma! Co robić? Wiem! Kuwetka :), potrzebna mi kuwetka. Baza danych to dla biznesu słowo obrzydliwe i nie używamy go. Mamy więc: Zarządca, Kuwetka, FormularzZamówienia, .… aaaaaaaa, a same Zamówienia? :). Komplet:
FormularzZamówienia
GeneratorDruczków
Kuwetka
Zarządca
Zamówienia
Nie zapominamy, że mamy Framework i interfejsy (ERP i Płatności). Pojawił się jeszcze GeneratorDruczków. Skąd się wziął? Kolejna metoda projektowania: [[Role, odpowiedzialność, współpraca]]. Otóż, warto Zarządcę zwolnić z obowiązku posiadania wiedzy o aktualnych wzorach dokumentów. Te wiedzę o aktualnie stosowanych wzorach dokumentów (i rolę) posiada GeneratorDruczków. I mógł by ktoś powiedzieć, że niepotrzebnie komplikuje program. Owszem, skomplikował się. Jeśli jednak w programie pojawią się kiedyś nowe funkcjonalności, inni Zarządcy, wszyscy będą pobierali druczki z jednego miejsca bez zastanawiania się czy są właściwe bo mamy tylko jedno ich źródło, które odpowiada za to by zawsze były właściwe.
Jak wygląda diagram klas:
Tak więc co my tu mamy, po kolei: Klient (nasz aktor) kontaktuje się wyłącznie z Zarządcą, który go obsługuje. Zarządca korzysta z usług GeneratoraDruczków, Kuwetki, zewnętrznych systemów poprzez interfejsy. Koniec. Co dalej? Ano wypadało by pokazać jak Zarządca, zdaniem projektanta (:)) realizuje nasz przypadek użycia. Na potrzeby usystematyzowania projektu przytocze jeszcze raz scenariusz w firmie troszkę sformalizowanej:
Taka postać scenariusza (dialog) pozwala upewnić się, że zamawiający i projektant myślą tak samo. Mały komentarz: Klient ma przed sobą Ekran Startowy i wybiera opcję (polecenie) Nowe Zamówienie. System pyta o NIP, Klient wpisuje NIP i potwierdza. Możliwe jest nie wpisanie NIP. System wyświetla formatkę nowego zamówienia. Formatka ma wypełnione dane Zamawiającego lub nie, jeśli nie podano NIPu albo nie znaleziono go na liście kontrahentów. Klient wprowadza dane poprzez zaznaczenie tego co chce zamówić, wpisuje ilości itp. na koniec potwierdza. System sprawdza i wyświetla kompletne zmówienie. Klient zatwierdza lub rezygnuje (pominąłem, ewentualną edycję dla uproszczenia, jeżeli firma oferuje tysiące produktów także będzie inaczej :)).
W tym momencie Klient ma jedno lub więcej zamówień do opłacenia, w kolejnym przypadku użycia może zaznaczyć zamówienia do opłacenia i wybrać opcję Inicjacja Płatności, System przygotuje niezbędne dane i przekaże sterowanie do Systemu obsługi Płatności. Nie będzie tu tego opisu, celem artykułu jest pokazanie metody a nie wykonanie kompletnego projektu.
Powyższy scenariusz posłuży teraz do przetestowania i uzupełnienia modelu dziedziny i uzupełnienia go (ten etap nazywany jest często [[proof-of-concept]]). Narzędziem do testowania będzie diagram sekwencji:
[singlepic id=73 w=320 h=240 float=center]
Samo wykonanie powyższego diagramu pozwala na sprawdzenie poprawności pomysłu i jego logiki oraz od razu daje nam możliwość weryfikacji atrybutów i operacji. Po tym teście (opracowanie tego diagramu jest testem koncepcji) uzupełniamy model dziedziny o atrybuty i operacje. Diagram klas to statyczny opis, który sam z siebie niczego nie mówi o współpracy obiektów. Jego poprawna interpretacja (nie licząc systemu pojęć) jest niemożliwa bez tego modelu dynamiki (diagram sekwencji to model dynamiki systemu). Zaryzykował bym nawet tezę, że sam diagram klas nie niesie prawie żadnej informacji wykonawcy.
Model dziedziny wzbogacił się:
Podsumowanie
Przytoczę ponownie cytowany diagram klas:
Powyższy diagram w moim mniemaniu jest raczej pewnym modelem pojęciowym. Bez kilku słów o metodyce projektowania trudno go w ogóle oceniać dlatego pokazałem swój diagram klas, i sposób w jaki powstał. Kluczowe różnice:
W moim modelu typ płatności będzie atrybutem Zamówienia
Obiekt Zamówienie, poza zawartością druku zamówienia, obsługuje także inne dodatkowe zadania (pamiętanie o sposobie płatności, przygotowanie serializacji XML do „wsadzenia” obiektu do ERP, może coś jeszcze…)
Klient w ogóle się nie pojawia, chyba już wiadomo dlaczego…
Pozycja zamówienia została „ukryta” w zamówieniu, zależnie od koncepcji były by to elementy agregatu (pozycjezamówienia u mnie były by w relacji kompozycji do obiektu bazowego DrukZamówienia), nie ma klasy Produkt (magazyn), jest to obiekt za który odpowiada system ERP.
U mnie pojawia się Kuwetka, obiekt odpowiedzialny za składowanie Zamówień, pytania o konkretne Zamówienie, ostatnie zamówienie, zestawienie zamówień za okres to potencjalne operacje obiektu Kuwetka.
Pojawia się także Zarządca, obiekt odpowiedzialny za obsługę przypadku użycia (byc może także innych). Na diagramie sekwencji pojawiła się klasa System obsługi…jest to abstrakcja elementu View wzorca MVC.
Powyższy projekt jest bardzo uproszczony i na pewno ma wiele wad, kilka iteracji projektowania i testów warto by jeszcze przeprowadzić. Celem moim jednak było pokazanie samej metody analizy i projektowania, tego do czego można użyć notacji UML. Pokazać, że można zaprojektować logikę oprogramowania i ją przetestować nie pisząc nawet linijki kodu.
Na koniec chciałem pokazać, że w projektach dedykowanych, jeżeli jest nawet cień ryzyka, że wykonawca będzie błądził realizując nasz projekt (nie oczekujmy od programistów, że będą znali i rozumieli naszą firmę, nie taka jest ich rola) warto wykonać taki właśnie projekt. Po pierwsze przetestujemy nasze życzenia, po drugie powstanie materiał, na bazie którego kilku wykonawców dokona wyceny z niewielkim błędem i bez dużych narzutów na niespodzianki. Czy takie projekty robią developerzy? Ich o to pytajcie. Czy ma to sens? Testowanie diagramów jest co najmniej o rząd wielkości tańsze niż testowanie prototypów przez programistów.
Kto powinien opracować taki projekt? Osobiście uważam, że nie powinien to być wykonawca projektu. Powodem jest po pierwsze to, o czym wspomniałem: każdy się specjalizuje w jakiejś jednej technologii. Po drugie w przypadku jakichkolwiek problemów Zamawiający, jako niespecjalista, nie ma żadnej możliwości merytorycznej oceny wykonawcy, nawet gdyby był szkodliwy dla zamawiającego. Nie twierdzę, że wszyscy developerzy to niekompetentni naciągacze ale też nie dam głowy, że takich nie ma. Sugeruję naśladowanie rynku budowlanego: zarządzanie ryzykiem czyli oddzielenie projektowania od wykonania.
Developer także odnosi tu pewną korzyść: jest zwolniony z odpowiedzialności i posądzania go o kombinowanie, zyskuje dodatkowo mediatora pomiędzy sobą i zamawiającym. Minus jest taki, że wynagrodzenie za analizę i projekt nie wpłynie do jego kieszeni ale cóż… to koszt komfortu pracy ale z reguły nie przekracza on 10 – 20% budżetu na powstanie oprogramowania.
Podsumowanie drugie
Czy to ma sens w przypadku gotowych ERP? Moim zdaniem:
Ingerencja (tak zwana kastomizacja) w gotowe oprogramowanie ERP kończy się bardzo często destabilizacją pierwotnie dobrego oprogramowania.
Jeżeli system ERP jest zamknięta bryłą (z reguły świadczy o tym fakt pracy na relacyjnej, znormalizowanej bazie danych) nie warto go kastromizować bo to kosztowny i bardzo ryzykowny proces, do tego pozbawiamy się możliwości prostego jego upgrade’owania.
Brakujące w firmie funkcjonalności lepiej tworzyć osobno, jako dedykowane projekty bo to po pierwsze chroni inwestycję w ERP, po drugie z reguły kosztuje znacznie mniej i znacznie szybciej jest gotowe do użycia (stworzenie małego oprogramowanie jest dużo prostsze niż modyfikacja dużego). Po drugie pojawiają się już systemy ERP mające strukturę własnie szkieletu opartego na wzorcu MVC i zaprojektowanie nowej funkcjonalności polega na analizie i projektowaniu takim jak wyżej opisane, z tą różnicą że implementacja ma miejsce w środowisku tego ERP a nie w środowisku odrębnego narzędzia programistycznego. Tak więc, paradoksalnie,
powyższe analiza i projektowanie powinny być zawsze pierwszym etapem projektu programistycznego niezależnie od tego czy ma powstać nowe oprogramowanie czy tylko nowe funkcjonalności do istniejącego.
A gdzie się podziały wymagania pozafunkcjonalne?
Generalnie w mojej metodyce są one ograniczeniami dokumentowanymi dla każdego przypadku użycia indywidualnie. Powstaje repozytorium ograniczeń i mapowanie ich na przypadki użycia. Bardzo restrykcyjne ograniczenia (np. wysoka dostępność) mogą być wydzielone z ich przypadkami użycia do osobnego podsystemu i implementowane nawet na osobnej platformie jeśli taka będzie potrzeba związana z rentownością. To jednak temat na osobny artykuł :).
Konkluzja biznesowa: Nowy system informatyczny to interakcja firmy i oprogramowania, musi być traktowana łącznie jako jeden system złożony z ludzi i narzędzi w ich otoczeniu. Dlatego decyzja biznesowa o outsourcingu płatności i integracji z ERP powinna być moim zdaniem integralną częścią i produktem analizy biznesowej w projekcie informatycznym.
BIO: Od roku 1991 roku, nieprzerwanie, realizuję projekty z zakresu analiz i projektowania systemów, dla urzędów, firm i organizacji. Od 1998 roku prowadzę także samodzielne studia i prace badawcze z obszaru analizy systemowej i modelowania (modele jako przedmiot badań: ORCID). Od 2005 roku, jako nieetatowy wykładowca akademicki, prowadzę wykłady i laboratoria (ontologie i modelowanie systemów informacyjnych, aktualnie w Wyższej Szkole Informatyki Stosowanej i Zarządzania pod auspicjami Polskiej Akademii Nauk w Warszawie. Oświadczenia: moje badania i publikacje nie mają finansowania z zewnątrz, jako ich autor deklaruję brak konfliktu interesów.
Strona używa plików cookie, aby zapewnić Ci wygodę przeglądania poprzez zapamiętywanie Twoich preferencji i powtarzających się wizyt. Klikając "Akceptuj wszystko", wyrażasz zgodę na użycie WSZYSTKICH plików cookie. Jednakże, możesz odwiedzić "Ustawienia plików cookie", aby zapewnić kontrolowaną zgodę.
Ta strona korzysta z plików cookie, aby poprawić wygodę podczas podczas przeglądania witryny. Pliko cookie, które są sklasyfikowane jako niezbędne, są przechowywane w przeglądarce, ponieważ są niezbędne do działania podstawowych funkcji witryny. Używamy również plików cookie stron trzecich, które pomagają nam analizować i zrozumieć, w jaki sposób korzystasz z tej witryny. Te pliki cookie będą przechowywane w przeglądarce tylko za Twoją zgodą. Możesz również zrezygnować z tych plików cookie. Ale rezygnacja z niektórych z tych plików cookie może mieć wpływ na wygodę przeglądania.
Niezbędne pliki cookie są absolutnie niezbędne do prawidłowego funkcjonowania witryny. Ta kategoria obejmuje tylko pliki cookie, które zapewniają podstawowe funkcje i zabezpieczenia strony. Te pliki cookie nie przechowują żadnych danych osobowych.
Wszelkie pliki cookie, które mogą nie być szczególnie potrzebne do działania witryny i są wykorzystywane w szczególności do gromadzenia danych osobowych użytkowników za pośrednictwem analiz, reklam i innych treści osadzonych, są określane jako niepotrzebne pliki cookie. Wymagane jest uzyskanie zgody użytkownika przed uruchomieniem tych plików cookie w witrynie.
Functional cookies help to perform certain functionalities like sharing the content of the website on social media platforms, collect feedbacks, and other third-party features.
Cookie
Duration
Description
__atuvc
1 year 1 month
AddThis sets this cookie to ensure that the updated count is seen when one shares a page and returns to it, before the share count cache is updated.
__atuvs
30 minutes
AddThis sets this cookie to ensure that the updated count is seen when one shares a page and returns to it, before the share count cache is updated.
bcookie
2 years
LinkedIn sets this cookie from LinkedIn share buttons and ad tags to recognize browser ID.
bscookie
2 years
LinkedIn sets this cookie to store performed actions on the website.
language
session
This cookie is used to store the language preference of the user.
lidc
1 day
LinkedIn sets the lidc cookie to facilitate data center selection.
na_id
1 year 24 days
The na_id is set by AddThis to enable sharing of links on social media platforms like Facebook and Twitter.
ouid
1 year 24 days
Associated with the AddThis widget, this cookie helps users to share content across various networking and sharing forums.
vc
1 year 24 days
The vc cookie is set by addthis.com on sites that allow sharing on social media.
Performance cookies are used to understand and analyze the key performance indexes of the website which helps in delivering a better user experience for the visitors.
Analytical cookies are used to understand how visitors interact with the website. These cookies help provide information on metrics the number of visitors, bounce rate, traffic source, etc.
Cookie
Duration
Description
at-rand
never
AddThis sets this cookie to track page visits, sources of traffic and share counts.
browser_id
5 years
This cookie is used for identifying the visitor browser on re-visit to the website.
CONSENT
2 years
YouTube sets this cookie via embedded youtube-videos and registers anonymous statistical data.
uid
1 year 24 days
This is a Google UserID cookie that tracks users across various website segments.
uvc
1 year 1 month
Set by addthis.com to determine the usage of addthis.com service.
Advertisement cookies are used to provide visitors with relevant ads and marketing campaigns. These cookies track visitors across websites and collect information to provide customized ads.
Cookie
Duration
Description
di2
1 year 24 days
AddThis sets this cookie on sites that allow sharing on social media. It is used to track user behaviour anonymously, to create usage trends that will improve relevance to their services and advertising.
loc
1 year 1 month
AddThis sets this geolocation cookie to help understand the location of users who share the information.
um
1 year 24 days
Set by AddThis for registering the user's sharing of content through social media.
VISITOR_INFO1_LIVE
5 months 27 days
A cookie set by YouTube to measure bandwidth that determines whether the user gets the new or old player interface.
YSC
session
YSC cookie is set by Youtube and is used to track the views of embedded videos on Youtube pages.
yt-remote-connected-devices
never
YouTube sets this cookie to store the video preferences of the user using embedded YouTube video.
yt-remote-device-id
never
YouTube sets this cookie to store the video preferences of the user using embedded YouTube video.
yt.innertube::nextId
never
This cookie, set by YouTube, registers a unique ID to store data on what videos from YouTube the user has seen.
yt.innertube::requests
never
This cookie, set by YouTube, registers a unique ID to store data on what videos from YouTube the user has seen.