W ostatnim artykule zwracałem uwagę między innymi na bardzo ważny element analizy i projektowania jakim jest abstrahowanie od detali, ponieważ: 

…analityk musi abstrahować od wszelkich detali, bez tego projekt zostanie już na samym początku ?zabity? ich ilością. [1]

Nieco wcześniej (2013 r.) pisałem o tym, kiedy uzgadniać detale, które i gdzie one są: 

Cała logika biznesowa jest wykonywana wewnątrz aplikacji (informacje o ewentualnych błędach pojawią się po zatwierdzeniu formularza), np. upust może być sprawdzony (albo naliczony) dopiero po skompletowaniu danych wymaganych do jego wyliczenia, czyli będzie to kilka różnych pól (najmniej dwa :)). Bywa, że do wyliczenia czegoś potrzebne będą dane nie wprowadzane do danej formatki faktury, np. saldo klienta. [2]

 

Tym razem kilka słów o tym jak skomplikować i zabić projekt już pierwszego dnia. Jednym z najbardziej ryzykownych sposobów rozpoczynania projektu jest rozpoczynanie od konsultacji z użytkownikiem w kwestii interfejsu użytkownika. Prowadzi to do sytuacji, w której jeszcze nie mamy żadnego pojęcia o logice biznesowej i architekturze aplikacji, a już deklarujemy to jak będzie się ona komunikowała z użytkownikiem (ciekawe na jakiej podstawie?). 

Do napisania tego artykułu skłonił mnie ten wpis:

The role of design still puzzles many agile teams I work with. When should the design activities take place?  Who should carry them out? How are design decisions best captured? This blog tries to answer the questions by discussing a user-centric, iterative, and collaborative design process for Scrum and Kanban teams. [3]

Autor pokazuje jak “walczy” ze złożonością na tym etapie, ja pragnę zasugerować by do tej złożoności na tym etapie po prostu nie dopuszczać. Powyższy diagram pokazuje z czym walczy analityk, który doprowadzi do zebrania wyrwanych z kontekstu (tak, nie ma modelu logiki więc dyskusje o GUI są oderwane od kontekstu) “wymagań” (historyjki użytkownika, lewa kolumna tablicy Story Area), których zamawiający może “naopowiadać” bardzo dużo.

A jak inaczej? Pomoże nam stosowanie wzorców architektonicznych. Są one od lat dostępne w większości frameworków (szkoda, że bardzo często developerzy je ignorują). Poniżej prosty, abstrakcyjny model klasycznego wzorca MVC.

W architekturze wydziela się komponenty (separowanie odpowiedzialności): odpowiedzialny za obsługę dialogu z użytkownikiem (View), odpowiedzialny za technologie, jakość, bezpieczeństwo, sterowanie itp. (Controler) oraz odpowiedzialny za (całą a nie tylko dane!) logikę biznesową (Model). 

Zarządzanie złożonością polega tu na tym, by na początku analizy i projektowania abstrahować całkowicie od detali GUI! (a dokładnie od całej technologii czyli elementów View i Contoler).  Kluczową odpowiedzialnością aplikacji jest realizacja określonej logiki biznesowej. Na tym etapie powinien powstać model przypadków użycia rozumiany jako prosty dialog pomiędzy użytkownikiem a aplikacją, tu celem jest uchwycenie kluczowych wymagań jakimi są wymagane usługi aplikacyjne realizowane przez aplikację oraz opracowanie wewnętrznej architektury – Modelu, która te usługi zrealizuje. Dopiero po przetestowaniu całej logiki biznesowej na modelach, warto się zabierać na komplikowanie projektu poprzez opracowanie detali GUI, sterowania, bezpieczeństwa itp.. Postępowanie takie umożliwia wzorzec architektoniczny MVVM opracowany ponad 10 lat temu. Wzorzec ten wprowadza dodatkowy komponent pomiędzy komponenty View i Model: View-Model, który realizuje logikę dialogu GUI-użytkownik. Dzięki temu możemy wydzielić etap pracy nad GUI, jako osobny w projekcie, który zrealizuje (później) tak zwany “UX designer”, a developer zamieni pierwotnie abstrakcyjny komponent View na implementacje “View-View Model”.

Bardzo dobry opis tego podejścia:

W przypadku warstwy prezentacji można wykorzystać m. in. następujące rozwiązania: MVC, MVP czy Model-View-ViewModel. Ze względu na mechanizm wiązań (binding), programistom WPF oraz Silverlight, polecany jest wzorzec MVVM ? jest to technologia umożliwiająca bardzo łatwą implementację wzorca. […] …po co utrudniać sobie zadanie poprzez wykorzystywanie MVVM, zamiast pisać aplikację w klasyczny sposób (za pomocą code-behind)? W końcu wdrożenie praktycznie każdego wzorca projektowego wymaga trochę większych początkowych nakładów pracy.

Podejście Code-Behind (autonomous view ? AV) ma poważną wadę ? nie gwarantuje elastyczności oraz testowalności. Podsumowując, wprowadzenie wzorca [MVVM, przypis autora] umożliwia:

• niezależność logiki od sposobu wyświetlania danych,
• niezależność kodu od technologii, w której wykonana jest warstwa prezentacji,
• wykonywanie testów ? za pomocą MVVM czy MVP możliwe jest wykonanie testów zautomatyzowanych (np. jednostkowych),
• łatwą zamianę widoków (brak sztywnych powiązań między widokiem a logiką). [4]

(Tak: stosowanie wzorców podnosi początkową pracochłonność ale zwraca się z nawiązką w dalszych cyklach życia projektu.) Strukturę i historię powstania tej architektury zainteresowani mogą poznać także tu: 

Model View View Model (MVVM) 
In 2005, John Gossman, Architect at Microsoft, unveiled the Model-View-ViewModel (MVVM) pattern on his blog. MVVM is identical to Fowler?s Presentation Model, in that both patterns feature an abstraction of a View, which contains a View?s state and behavior. Fowler introduced Presentation Model as a means of creating a UI platform-independent abstraction of a View, whereas Gossman introduced MVVM as a standardized way to leverage core features of WPF and Silverlight to simplify the creation of user interfaces. MVVM is a specialization of the more general PM pattern, tailor-made for the WPF and Silverlight platforms to leverage core features of WPF such as data binding, commands , templates.

This diagram take from MSDN depicts MVVM Pattern in action.

[5]

 

Tak więc analizę i projektowanie warto zacząć od logiki i szkieletu architektury, a ta to przede wszystkim Model (dziedziny) systemu czyli kompletna logika biznesowa (utożsamianie modelu dziedziny z relacyjną bazą danych to poważny błąd i nieporozumienie). Po uporaniu się z tym etapem projektu ma sens opracowywanie detali komunikacji z użytkownikiem, bo dopiero teraz znamy wymagania i ograniczenia logiki biznesowej. Odkrywanie ich dopiero na etapie prototypowania  to stanowczo za późno, bo generuje to ogromne koszty cyklicznego refaktoringu kodu (albo kod szybko staje się “bryłą błota”). 

 

Bardzo często słyszę, że klient chce jak najszybciej coś zobaczyć. Rzecz w tym, że jeżeli się na to zgodzimy, powstaje i jest akceptowana masa tak zwanych “pobożnych życzeń”, a klient bardzo szybko się przywiązuje do tego co zobaczył na prezentacji (i nie chce odpuścić). W efekcie tworzy się spirala żądań, testów i poprawek, które szybko przekształcają “agile” w porażkę budżetu i harmonogramu. Praktyka pokazuje, że budżet zawsze ma limit, dlatego bardzo wiele takich projektów kończy albo w koszu na śmieci albo efekty stanowią tylko namiastkę tego co opisywała pierwotna wizja. Jeżeli zaś zaczniemy od jądra systemu a na koniec zostawimy sobie “makijaż” jakim jest GUI, szansa na sukces będzie znacznie większa. Problem polega na tym, że moda na “user-centric, iterative, and collaborative design” jest silna mimo tego, że jest przyczyną wielu porażek. 

Tak więc odpowiedź na pytanie jak poradzić sobie z życzeniami biznesu, brzmi: nie dopuszczać do ich wyartykułowania :). Projektowanie i tworzenie samochodu rozpoczyna się od podwozia i napędu a nie od deski rozdzielczej…

Ten artykuł można czytać na dwa sposoby: analitycy czytają od dechy do dechy po kolei ;). Menedżerowie i tak zwany biznes czytają od razu koniec, to jest część Na zakończenie, gdy uznają, że nie wierzą w te wnioski (wyrok) to zaczynają od początku czyli czytają uzasadnienie :).

Niedawno napisałem:

Pomiędzy pojęciami abstrakcja i model jest pewna kluczowa różnica: abstrakcja to pojęcie zaś model to opis mechanizmu, jego konstrukcja, działanie, budowa. Prosty przykład: nazwane prostokąty na typowym diagramie struktury organizacyjnej to abstrakcje komórek organizacyjnych i osób w nich zatrudnionych, prostokąty te wraz z liniami je łączącymi stanowią, jako całość, model podległości zasobów w organizacji. (Źródło: Analiza a modelowanie czyli ile abstrakcji a ile rzeczywistości | | Jarosław Żeliński IT-Consulting)

Kontynuując temat z innej perspektywy powiemy sobie teraz o etapach analizy i projektowania w inżynierii, nie tylko oprogramowania, w oparciu o MDA ([[Model Driven Architecture]], www.omg.org/mda, polecam także pojęcie [[model driven engineering]]). Dobra informacja dla czytelników: na końcu się wszystko wyjaśni, można pominąć część o MDA 🙂

MDA

Pięć lat temu, jeden z artykułów o modelowaniu i projektowaniu, kończyłem tymi słowami:

Podsumowując można by powiedzieć, że etapy tworzenia oprogramowania to:

1. Analiza biznesowa, której produktem są: model organizacji (model biznesowy) oraz opis tego co ma powstać (opis, wymagania na oprogramowanie). Całość (sformalizowane modele) pozwala na przetestowanie czy tak określone wymagania spełniają potrzeby biznesu.
2. Wytworzenie oprogramowania polegające na: opracowaniu szczegółów architektury, rozwiązaniu problemów technicznych (wymagania niefunkcjonalne), kodowaniu oraz dostarczeniu i wdrożeniu.

Źródło: Hej, Biznesie, to ma być dla biznesu czyli dla Ciebie! | | Jarosław Żeliński IT-Consulting

Powoływałem się w tym tekście właśnie na MDA. Czymże to jest? Na stronach OMG znajdziemy: Document — ormsc/14-06-01 (MDA Guide revision 2.0) Contact: Dr. Jon M. SiegelThis final draft of the revised MDA Guide edited in Boston on 18 June 2014 reflects all AB edits requested at the Reston and Boston AB meetings. (Źródło: OMG Document — ormsc/14-06-01 (MDA Guide revision 2.0)) 

Skorzystam z kilku cytatów i napisze co nieco o MDA. Poniżej kluczowe tezy, nie miałem tu ambicji literalnego tłumaczenia tego dokumentu, chodziło mi o pryncypia.

This guide describes the Model Driven Architecture (MDA) approach as defined by the Object Management Group (OMG). MDA provides an approach for deriving value from models and architecture in support of the full life cycle of physical, organizational and I.T. systems (A ?System?, in this context, is any arrangement of parts and their interrelationships, working together as a whole.). The MDA approach represents and supports everything from requirements to business modeling to technology implementations. By using MDA models, we are able to better deal with the complexity of large systems and the interaction and collaboration between organizations, people, hardware, software.

Stosowanie modeli pozwala znacznie lepiej radzić sobie ze złożonością wielkich systemów jakimi są organizacje oraz funkcjonujące w nich związki między ludźmi, oprogramowaniem i infrastrukturą. Fakt, że badane organizacje współpracują z innymi, dodatkowo komplikuje tę całość.

Models as communications vehicles

A fundamental value proposition for models and modeling is to facilitate a team or community coming to a common understanding and/or consensus.

Jedną z głównych ról modeli, poza ich analizą, jest komunikacja: komunikujemy innym członkom zespołu (także klientom) to co zrozumieliśmy i to czego oczekujemy. Tak więc modele są zarówno opisem rzeczywistości powstałym w toku jej zrozumienia, są także opisem tego co ma powstać, jeżeli chcemy tę rzeczywistość stworzyć.

[?]Abstraction deals with the concepts of understanding a system in a more general way; said in more operational terms, with abstraction one eliminates certain elements from the defined scope; this may result in introducing a higher level viewpoint at the expense of removing detail. A model is considered more abstract if it encompasses a broader set of systems and less abstract if it is more specific to a single system or restricted set of systems. [?]

Podstawową rzeczą w analizie jest redukowanie szczegółów i uogólnianie. Człowiek nie jest w stanie analizować czegoś co składa się z setek detali.

Model Analytics

Once models are captured as semantic data various analytics can be executed across those models including model validation, statistics and metrics. Analytics assists in decision making, monitoring and quality assessment. OMG MDA Guide rev. 2.0 June 2014 page 2

Modele pojęciowe i analityczne służą do zrozumienia badanej rzeczywistości. Modele tworzone (projektowanie) służą do testowania pomysłów i podejmowania decyzji, dalej zaś stanowią opis cech wymaganego rozwiązania. Modele wykonywalne to inne modele ale bazują na modelach analitycznych. Poniżej, na bazie MOF ([[Meta Object Facility]]), pokazano trzy poziomy abstrakcji (poziom zerowy to rzeczywistość).

Abstrakcja to “uproszczony” (pozbawiony zbędnych szczegółów) model określonej rzeczywistości. Metamodel to mechanizm tworzenia tej rzeczywistości w tym także model pojęciowy (więcej w dalszej części).

Model (M1) więc jest albo wynikiem (produktem) analizy badanej rzeczywistości, albo wynikiem (produktem) procesu jej projektowania (projektowania rozwiązania). 

Model Simulation and Execution

Models as data can drive simulation engines that can assist in both analytics and execution of the designs captured in models. Simulation assists in the human understanding of how a modeled system will function as well as a way to validate that models are correct. Models can, in some cases be directly executed ? serving as the ?source code? for highlevel applications that implement processes, data repositories and service endpoints. Model execution provides a direct and immediate path to realizing a design with a minimum of technical details being exposed. DBMS Schema and process models are well-known categories of (partially) executable models.[?]

Modele symulacyjne służą do testowania hipotez i podejmowani decyzji. Modele wykonywalne, w tym tworzone automatycznie na bazie modeli abstrakcyjnych, to narzędzia do tworzenia wykonywalnego kodu. Nie tylko w moim mniemaniu, jest to albo daleka przyszłość (mam na myśli komercyjne zastosowania) albo wyłącznie akademickie badania. Wiem, że są udane próby generowania działającego kodu z modeli, jednak wymagania na ilość detali, jakie trzeba zadeklarować w tych modelach, zbliża ich złożoność do złożoności kodu  jaki powstaje. Nie będziemy się tu zajmowali modelami wykonywalnymi.

Cztery produkty

Te dwa opisane na początku etapy do analiza systemowa organizacji (potocznie “analiza biznesowa”) oraz implementacja rozwiązania. Produkty to …

MDA to architektura mająca trzy poziomy modelowania, nazywane  “od góry” CIM (Computation Independent Model), PIM (Platform Independent Model) i PSM (Platform Specific Model).

Architectural Layers It is useful to identify particular ?layers? of an architecture with respect to its level of abstraction. While there can be any number of architectural layers, a broad categorization of this concept is:

• Business or domain models ? models of the actual people, places, things, and laws of a domain. The ?instances? of these models are ?real things?, not representations of those things in an information system. In MDA domain models have historically been called a ?CIM? for ?Computation Independent Model?.
• Logical system models ? models of the way the components of a system interact with each other, with people and with organizations to assist an organization or community in achieving its goals. [model PIM]
• Implementation models ? the way in which a particular system or subsystem is implemented such that it carries out its functions. Implementation models are typically tied to a particular implementation technology or platform. [model PSM].

Model CIM opisuje ludzi i ich związki, miejsca, prawa rządzące tym wszystkim. Ten model opisuje realną, badaną rzeczywistość całkowicie abstrahując od wykorzystywanych ewentualnie posiadanych narzędzi informatycznych (w przypadku start-up’u lub rozwoju organizacji jest to przyszła jej postać). Nie jest to model jakiegokolwiek oprogramowania ani tego jak ono działa. Produktem tego etapu są: modele procesów biznesowych, specyfikacja reguł biznesowych, biznesowy słownik pojęć i modele pojęciowe.

Model PIM opisuje komponenty aplikacji, ich wzajemne interakcje, logikę działania tych komponentów (ta część logiki opisanej w modelu CIM, która ma być realizowana w aplikacji). Produktem tego etapu są modele: przypadków użycia (w tym postać nośników danych, mockup’y ekranów), komponentów, wewnętrzne struktury komponentów (modele dziedziny z perspektywy wzorca MVC),  interakcji, inne jeśli konieczne.

Model PSM to model będący projektem wykonawczym. Jest to rozszerzenie modelu PIM, uszczegółowienie go wraz z dodatkowymi elementami technicznymi (realizującymi środowisko, bezpieczeństwo, wymaganą  wydajność itp.). Kod aplikacji to materializacja (implementacja) modelu PSM.

Powyższe, to cztery produkty powstające w tym procesie. Dlaczego pisze o dwóch etapach? Poniżej wyjaśnienie.

Diagram obrazuje produkty/fazy definiowane jako MDA. Każdy produkt analizy to określony zestaw modeli. Na diagramie wskazano jakich notacji używa się w każdym z nich (tu bazując na notacjach rodem z OMG). Tu przypominam to co już nie raz pisałem: celem jest zrozumienie (i tworzenia potrzebnych w danym przypadku modeli) oraz przekazane tej wiedzy, a nie tworzenie “jakichś modeli i dokumentów”. Każdy model, jego powstanie, ma określony cel.

Jeszcze stosunkowo niedawno w moich projektach związanych z  oprogramowaniem, wyróżniałem trzy etapy: analiza organizacji, specyfikacja wymagań oraz opracowanie logiki dla dedykowanych komponentów oprogramowania. W końcu, po kilku projektach, przekonałem się, że ten podział “nie działa”. Dlaczego?

Skoro na etapie CIM opracowaliśmy między innymi model logiki biznesowej dla danej organizacji (w tym reguły biznesowe, słownik pojęć) to już ją, te logikę, mamy. Okazało się, że ten “trzeci etap” w zasadzie jest sztuczny, gdyż rzetelne opracowanie CIM to także “ta” logika. Tu warto przytoczyć diagram:

Swego czasu pisałem także o testowaniu modeli:

W toku dalszej pracy podejmowana jest decyzja o zakresie projektu. Wskazując to, jakie “działania” ma wspierać lub przejąć na siebie aplikacja (to są właśnie przypadki użycia), wskazujemy jaka logika ma być przez tę aplikację realizowana i kiedy. Wskazanie zakresu projektu jest więc pierwszym etapem definiowania logiki aplikacji. Jeżeli do tego dodać wiedzę dziedzinową, np. to które elementy mogą być współdzielone a które nie, które powinni być całkowicie niezależne itp., powstanie tak zwany model dziedziny systemu (logika biznesowa i jej struktura czyli architektura aplikacji, a konkretnie części realizującej logikę biznesową).

Na zakończenie

Jak podejść do planów zakupu także gotowego oprogramowania? Czy warto je projektować? Oczywiście, że warto z prostego powodu: nie ma znaczenia to, czy przyszłe oprogramowanie będzie gotowe czy trzeba je będzie dopiero stworzyć. Ono ma realizować taką logikę jakiej oczekujemy. Owszem, jest możliwa decyzja: skoro na rynku nie ma poszukiwanego produktu a stworzenie dedykowanego jest zbyt kosztowne, to albo rezygnujemy  z zakupu albo z określonej logiki wewnątrz organizacji. Jednak do podjęcia takiej decyzji musimy tę logikę znać i mieć udokumentowaną (no bo jakoś musimy ją pokazać oferentom). “Ale dostawcy oprogramowania zawsze oferują analizę wymagań”… To prawda … A ilu z nich powie, że nie mają Wam nic do zaoferowania? “Ale dedykowane oprogramowanie może zaprojektować tylko jego wykonawca”. To dlaczego firmy budowlane nie są dopuszczane do prac projektowych i architektonicznych?

Dlatego na diagramie powyżej, jako moment wyboru dostawcy oprogramowania, wskazano ten w którym mamy udokumentowany model logiki czyli PIM. To czy logika taka jest dostępna w jakimś produkcie na rynku czy nie, nie zmienia faktu, że i tak musi zostać ona opisana, bez czego taki wybór jest niemożliwy. Czym więc są (czym powinny być) wymagania na oprogramowanie? Niestety powinny być zwięzłym projektem a nie długą listą cech.

Jeden analityk projektant mający dobre wsparcie narzędziowe, jest w stanie wykonać analizę i projekt dla dowolnie dużej firmy, wystarczy, że potrafi tworzyć abstrakcje i zarządzać złożonością dokumentacji. Czy kilku analityków zrobi to nie gorzej i szybciej? Nie znam takiego przypadku…. bo im więcej osób prowadzi taką analizę tym więcej pracy wymaga koordynacja i praca nad spójnością całości.

Na zakończenie cytat z pewnej dyskusji:

I started a company called Nascent Blue that specializes in MDD for application development. We have actually had the opportunity to compare MDD to traditional development side-by-side on large projects. Our client set up ?the experiment? to collect the PM data for analysis. It was a large project with 5 teams. The results:

1. Our team was less than half the size of the other teams.
2. Our team produced more than twice the code of the other teams.
3. Our team achieved a 75% reduction in cost.
4. Our team achieved a 66% reduction in defect rate.
5. Our team was twice as fast (with half the size).
We have since gotten more efficient and more advanced, so I don?t know what the numbers are now.
(źr. Model driven productivity | LinkedIn).

Znakomita większość programów zawiera ponad 10 krotnie więcej kodu niż mogła by mieć, bo programiści często implementują warianty zachowań a nie ich mechanizmy (co powoduje, że systemy te są tyleż razy droższe niż mogły by być).

Prawie za każdym razem, gdy mówię (ale nie robię tego jednak zbyt często 😉 ), że stosuję metody naukowe w analizie, spotykam się z zarzutem, że przesadzam. Zapewne nie ma sensu epatowanie w projektach biznesowych akademickim słownictwem, nie ma znaczenia dobór słownictwa w nazwaniu metody pracy, bo znaczenie ma skuteczność.

Wprowadzenie

Ludzie i ich praca to informacje i ich wymiana. Komputer i oprogramowanie to mechanizm przetwarzania danych reprezentujących te informacje. Projektowanie oprogramowania polega na zrozumieniu i opisaniu tego mechanizmu, tego jakie to dane i jak są (analiza) lub powinny być (projektowanie) przetwarzane. Aby to zrobić analizujemy dokumenty, nie robimy wywiadów.

Jeżeli ktoś tego nie potrafi i nie rozumie, zaczyna organizować wywiady i kodować to, co ludzie postrzegają ze swojej perspektywy. Tak powstaje najgorsze oprogramowanie.

Można to zobrazować jak poniżej:

Dlatego do opracowania projektu przyszłego ‘systemu informatycznego’ należy najpierw zrozumieć ‘system informacyjny’ firmy (organizacji, branży). W tym momencie możesz kontynuować lekturę tego wątku w artykule System informacyjny a informatyczny.

Poniżej po lewej udokumentowany efekt obserwacji z Ziemi, oprogramowanie powstające na bazie wywiadów i obserwacji ma potem podobna strukturę. Po prawej stronie, efekt zrozumienia obserwacji: model, którego wykorzystanie do napisania oprogramowania zaowocuje oprogramowaniem o znacznie mniejszej złożoności i jednocześnie lepsze, bo wierniej odwzorowujące “sytuację biznesową”: powstanie szybciej, będzie tańsze w wytworzeniu i w późniejszym utrzymaniu i rozwoju.

Dlatego napisałem też artykuł: User Story to wymaganie biznesowe, to opis problemu do rozwiązania, a nie funkcjonalność do implementacji! Poniżej po lewej oprogramowanie, które powstało jako efekt implementacji kolejnych wywiadów z użytkownikami (user story), po prawej efekt przemyślanego projektowania.

Dalsza część artykułu to opis tego czym są metody i teorie naukowe. Czytelników, których metodologiczne detale nie interesują zachęcam do lektury wyżej cytowanych artykułów.

Twierdzenie naukowe

Poniżej definicja tego czym jest twierdzenie naukowe:

Twierdzenie naukowe ? zdanie oznajmiające spełniające następujące warunki [zotpressInText item=”{5085975:UYSPURWG}”]:

1. można wobec niego sformułować kryteria pozwalające na eksperymentalne, obserwacyjne lub logiczne ich obalenie (falsyfikowalne według zasad Karla R. Poppera),
2. istnieją reguły jego odczytania, które ograniczają do skończoności liczbę ich interpretacji (kryterium precyzji Józefa Bocheńskiego),
3. odnosi się do empirycznie doświadczalnej lub logicznie definiowanej rzeczywistości (tzw. widły Hume?a),
4. jest elementem zbioru twierdzeń paradygmatu wyjaśniającego rzeczywistość i pozwalającego na przewidywanie jej przyszłych stanów (koncepcja nauki normalnej T. S. Kuhna),
5. twierdzenie będące najprostszym z możliwych opisów świata (tzw. Brzytwa Ockhama).

Graficznie sam proces odkrycia naukowego można pokazać tak [zotpressInText item=”{5085975:5BB35MDU},{5085975:7T7S2GZL},{5085975:MG2IRJC4}”]:

Celowo cytuję tu literaturę z obszaru inżynierii oprogramowania, by pokazać, że nie jestem odosobniony w tym podejściu. Dla porządku podaje także definicje pojęcia model:

model: system założeń, pojęć i zależności między nimi pozwalający opisać (modelować) w przybliżony sposób jakiś aspekt rzeczywistości

Więcej o modelach w nauce: [zotpressInText item=”{5085975:ZUM2B6ZF}”].

Inżynieria oprogramowania

Jeżeli uznamy, że wynik zarówno analizy jak i projektowania, to także modele (przyjmujemy metodę pracy opartą na tworzeniu modeli: MDD/MDA czyli “model driven development”, MDA czyli “model driven architecture”, itp.), to w związku z tym

model, jako wynik analizy, można potraktować jako twierdzenie naukowe opisujące badaną (analizowaną) organizację, jest on zarazem wymaganiem wobec oprogramowania (ma zostać zaimplementowany).

Wyjaśnienie: odniosę się do powyższej definicji twierdzenia naukowego (zgodnie z powyższym pod pojęciem model rozumiemy komplet dokumentacji zawierającej modele, powstałej jako produkt analizy):

1. kryterium falsyfikacji: dopiero wskazanie w badanej organizacji faktu, którego nie opisuje opracowany model, pozwala uznać model (wynik analizy) za zły,
2. istnieją reguły jego (modelu) odczytania, czyli do stworzenia modelu użyto sformalizowanych notacji i systemów pojęciowych (np. BPMN, UML, BMM, SBVR itp),
3. model powstał na bazie, i odnosi się wyłącznie do, zebranych w toku analizy faktów (w szczególności dokumentów, które powstają w toku pracy analizowanej organizacji – dokumenty opisują fakty np. faktura to opis faktu dokonania sprzedaży),
4. model pozwala na przewidywanie tego co zajdzie w odpowiedzi na określone bodźce (paradygmat procesowy opisujący zachowania i paradygmat obiektowy opisujący struktury), mając model procesów biznesowych można przewidzieć produkt procesu, mając model aplikacji można przewidzieć produkt każdego przypadku użycia,
5. opracowany model jest najprostszy (minimalny) z możliwych, czyli nie da się już z niego usunąć nic bez spowodowania jego zniszczenia (uczynienia nieprawdziwym).

Tu, dla dopełnienia,  warto dodać powszechnie uznawaną w świecie nauki definicję prawdy (A.Tarski): twierdzenie prawdziwe to twierdzenie korespondujące z faktami.

Tak więc mamy to co chcemy czyli kryterium odbioru dokumentacji analitycznej i projektowej: nie jest to liczba stron a “to, że mówi prawdę”. 

Z drugiej strony, niestety nie istnieje możliwość wykazania poprawności dokumentacji powstałej w wyniku ankiet, wywiadów czy burzy mózgów spisanej językiem naturalnym … [zotpressInText item=”{5085975:LXK8VA68}”].

Tę “ciężką artylerię”, jak ta tu opisana, wytaczamy głównie dla projektów ryzykownych i kosztownych… 😉 oraz wszędzie tam gdzie ważna jest ochrona know-how.

Dodatek

(dwa dni po publikacji)

Właśnie podesłano mi link do ciekawego tekstu:

One of the most important elements of every Business Analyst?s toolkit is process modeling, which is also significant activity for Business Process Management professionals. For BPM market B? (Źródło: BPMN for Business Analysts ? why, when and how)

Przejrzałem treśc i wszystkie wypowiedzi one “kręcą się” wokół dokumentowania, prezentacji w celu zatwierdzenia lub zgłaszania uwag oraz niektórzy wskazują na możliwość “rysowania zamiast kodowania w celu wykonania”, albo przeoczyłem albo nikt nie zwrócił uwagi na bardzo – mim zdaniem ważny element – tworzenie modelu organizacji czyli tworzenie hipotezy “tak działacie” jako organizacja.

Problem w tym, że chyba większość “użytkowników” tej (BPMN) – i nie tylko – notacji, stosuje indukcyjne metody uwiarygadniania tych modeli, rozumianych raczej jako schematy blokowe. Podejście bazujące na “dowodzie z ilości” (indukcja): model procesów jest dobry bo bardzo dużo osób (osób akceptujących, recenzentów) tak uznało, jest chyba najgorsze.

To błąd logiczny: nie da się wykazać poprawności metodą indukcyjną. Model owszem powinien być jako diagram zrozumiały dla czytelnika, to nie ulega wątpliwości, jednak jego testy powinny polegać na wskazywaniu (szukaniu) ewentualnych faktów typu “a tu mówi nieprawdę”. Innymi słowy model procesu nie jest “dobry” (odzwierciedla prawdziwy mechanizm działania organizacji) dlatego, że wszyscy go zaakceptowali, jest dobry dlatego, że nikt nie znalazł (nie wskazał) jego wady (nie podważono go).

Projektów zakończonych klęską, w których “wszyscy zaakceptowali dokumentację” znamy chyba wszyscy masę….

Tak więc analityk, który podchodzi systemowo do analizy powinien tworzyć hipotezy “tak to działa” i nie dowodzić ich poprawności, a czekać na wskazanie wad. Notacje (BPMN, UML, BMM, …) oraz modele tworzone z ich pomocą, są doskonałym narzędziem do dokumentowania tych teorii.

Na zakończenie polecam to 🙂

Źródła

[zotpressInTextBib style=”apa” sort=”ASC”]

Swego czasu wpadł mi oczy “nius”:

Tesla Motors CEO Elon Musk decided that the company would build its own business software to run the company. CIO Jay Vijayan and his team built it in just four months. (How Tesla’s Elon Musk Approaches IT – The CIO Report – WSJ).

Nie znam szczegółów, ale domyślam się, że zrezygnowali z “pełnego zintegrowanego pakietu ERP” i to chyba z tego krótkiego tekstu widać.

Od dłuższego czasu nurtuje mnie czym kierują się firmy (ludzie) zawierające umowy na zakup pełnych i zintegrowanych pakietów ERP mimo, że statystyki pokazują, że to z reguły nie ma żadnego sensu.  Praktycznie wszystkie te wdrożenia są po zakończeniu znacznie droższe niż pierwotne oferty, trwają dłużej niż obiecano, nie mała część kończy się fiaskiem i nawet kompletną rezygnacją i odinstalowaniem (bywam w tych firmach i widzę od środka różnicę pomiędzy tym co piszą w gazetach dostawcy w swoich referencjach a tym co faktycznie miało miejsce).

Nie raz o tym tu pisałem więc nie będę się powtarzał.  Popatrzmy na poniższe statystyki:

W Polsce średni koszt wdrożenia projektu na kilkadziesiąt stanowisk (40-80 licencji) wynosi 200-300 tys. dolarów (prawie milion złotych), a projektu dla małej firmy (20-30 licencji) 100-140 tys. dolarów (nieco ponad 400 tys. zł) . Proporcje pomiędzy kosztami sprzętu i oprogramowania utrzymują się na poziomie pół na pół. Najdroższe są usługi konsultingowe, ich koszt sięga 50 proc. kosztów wdrożenia, choć zdarzają się klienci, u których koszty obsługi przez konsultantów nie przekraczają 5 proc. Wówczas klient praktycznie dokonuje wdrożenia własnymi siłami, ze strony dostawcy korzystając głównie z usług szkoleniowych. (Zintegrowane wspomaganie zarządzania przedsiębiorstwem: Przyszłość systemów ERP – Bankier.pl).

Tu mamy koszt ok. 400 tys. zł, czyli jakieś 200 tys. na analizę, projektowanie i wykonanie, to jest możliwe i nie jest to mało. Ostatni taki projekt jaki mam w portfolio trwał tylko pół roku. Różnica jest taka, że za te pieniądze klient nie robił praktycznie żadnych kompromisów (kompromis kastomizacji przy wdrażaniu gotowych dużych pakietów), czas od rozpoczęcia do wdrożenia tylko pół roku! To przykład takiego samego budżetu ale projekt nie był trywialny.

Swego czasu robiłem wyliczenie progowych kosztów opłacalności wytworzenia dedykowanej aplikacji dziedzinowej i wyszło mi, że za 75 tys. (podobno poza Warszawą 50 tys.) już taka może powstać (przy założeniu rzetelnego projektowania a potem dopiero implementacji, wtedy wychodzi za pierwszym razem, mam takie w portfolio). Przy obecnej technologii (frameworki dziedzinowe czyli tak zwane gotowe szkielety)  od dawna już nie piszemy długo i żmudnie kosztownego oprogramowania “od zera” (czym straszą dostawcy gotowego). Dedykowany projekt do dobór właściwych elementów szkieletu, ich konfiguracja, rozwiązywanie wielu problemów poza funkcjonalnych (technicznych), prace programistyczne “wykończeniowe” i serce systemu czyli model jego dziedziny (ok. 3% całości kodu), który faktycznie powstaje “od zera”. Do tego dochodzi coraz większa otwartość na integrację gotowego, dostępnego na rynku oprogramowania realizującego standardowe usługi, takie jak zarządzanie finansami czy magazynami. To się kupuje gotowe i łączy.

Piszę to na początku roku, traktując jako wróżbę, to okres na prognozy więc i ja prognozuję :). Myślę, że postępy w inżynierii oprogramowania, powolne odchodzenie od modelu relacyjnego danych (to wymusza bardzo sztywną integrację) i kolejne projekty pokazujące, że zintegrowany ERP to nie koniecznie “monolityczny” ERP, doprowadzą do “upadku” hegemonii “wielkich dostawców ERP”. Okazuje sie, że można taniej uzyskać takie same, a nie raz lepsze, efekty. Są już pierwsze efekty: dostawcy dużych ERP oferują dość rozbudowane i wygodne interfejsy integracyjne, sami zawierają sojusze z dostawcami osobnych komponentów (lub ich kupują :)). Osobiście nie widzę sensu, by każda zmiana sytuacji biznesowej musiała wymagać wymiany lub modyfikacji całego pakietu ERP, skoro można pojedyncze komponenty.

Jakiś czas temu pisałem o swoich przemyśleniach po rozmowie z pewnym dyrektorem finansowym jednego z moich klientów. Powiedział między innymi, że albo projekt zostanie zrealizowany w roku jednym budżetowym, albo on nie wyda na zgody na jego rozpoczęcie. W czym problem? Ano w tym, że przy obecnym tempie zmian na rynku, prognoza wykraczająca w przyszłość dalej niż rok to wróżenie z fusów… Skutek? Jak ocenić stopę zwrotu z inwestycji w coś, co jest najbardziej płynnym, podatnym na zmiany wymagań, zasobem w organizacji, czyli system wspomagający zarządzanie nią?

Rynek stale się rozwija i dojrzewa. Praktycznie każda większa firma doświadczyła w jakiejś formie wdrożenia gotowego, dostosowywanego do potrzeb, oprogramowania ERP. Warto jednak podkreślić, że idea jednego ?super systemu? ERP II, odchodzi powoli do lamusa. Moim zdaniem to kwestia roku, dwóch. Pierwsze symptomy to zalecenia producentów dużych systemów: wdrażać gotowe oprogramowanie w postaci ?gotowej? tylko tam gdzie pasuje, obszary specyficzne dla firmy opisać i zaprojektować dla nich dedykowane rozwiązanie i zintegrować. (czytaj  Biznes wychodzi z objęć systemu ? monolitycznego ERP).

Co z tym zrobić? Dzielić, jak to mawiają niektórzy kierownicy projektów: człowiek może zjeść nawet słonia, jak? Kęs po kęsie. Tak więc duży projekt należy podzielić na “samodzielne” podsystemy, jednak ta samodzielność ma dwa aspekty: każdy podsystem musi sam z siebie do czegoś służyć, powinien wnosić wartość dodaną. Drugi: każdy projektowany podsystem powinien być zaplanowany jako potencjalnie samodzielne narzędzie (inwestycja) na wypadek gdyby pozostałe nie zostały nigdy wytworzone np. z powodu zmian na rynku.

Ale o tym pisałem więcej już wcześniej. 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…

Po raz kolejny już sprawdza się teza, że wdrażanie jednego wielkiego ERP integrującego “wszystko” jest mrzonką… praktyka pokazuje, że kilka systemów dziedzinowych, zintegrowanych ze sobą jest po pierwsze mniej ryzykowne a po drugie, paradoksalnie, tańsze.

Tak więc: jak dostawca dużego ERP mówi, że duży ERP jest najlepszy to należy to traktować tak samo jak ofertę dostawcy dużego zestawu garnków ze stali nierdzewnej, z których i tak na co dzień używamy jednego a naleśniki i tak robimy z pomocą kupionej wcześniej dobrej teflonowej patelni bo do naleśników lepsza a zamiana jej na nową z nierdzewki tylko dlatego, że ?z kompletu? przeczy zdrowemu rozsądkowi i używa się jej mimo, że pokrywka z zestawu lekko wystaje ? ale przykrywa bo taki jest jej główny cel (w zasadzie tylko nie powinna być mniejsza ani zbyt duża). (Nigdy więcej ERP w jednym kawałku!).

Raport z Badania polskich projektów informatycznych 2010

Na stronie PMResearch.pl pojawiło się ciekawe badanie  Raport zawiera rezultaty analizy 80 starannie wyselekcjonowanych projektów IT. Wyniki prezentuje w zwięzły, syntetyczny sposób. Pobierz raport (za Informacje o wynikach badania polskich projektów informatycznych).

Wyniki badania bardzo polecam, uczą pokory. Pytanie moje do autorów: jak zdefiniowano metodykę Agile? Pobieżna nawet “badanie” zasobów w Internecie pokazuje, że nie istnieje jedna definicja tego “podejścia”. Na stronie agilemanifesto.org czytamy:

Wytwarzając oprogramowanie i pomagając innym w tym zakresie,

odkrywamy lepsze sposoby wykonywania tej pracy.

W wyniku tych doświadczeń przedkładamy:

 Ludzi i interakcje ponad procesy i narzędzia.

Działające oprogramowanie ponad obszerną dokumentację.

Współpracę z klientem ponad formalne ustalenia.

Reagowanie na zmiany ponad podążanie za planem.

Doceniamy to, co wymieniono po prawej stronie,

jednak bardziej cenimy to, co po lewej.

Można by odnieść wrażenie, że ignorowane jest wszystko co nakazuje rozsądek (pogrubienie moje). Paradoksalnie, obserwując projekty, mam wrażenie, że zwinność jest jednak często inaczej rozumiana, nie jako ignorowanie “złotego trójkąta” projektowego (zakres, termin, budżet). Ja w każdym razie zawsze pytam: czym jest tu Agile. Niestety słyszę nie raz, ze “tego się nie definiuje”… co wywołuje u mnie odruch “nie definiuje się zakresu projektu” a to prowadzi do wniosku, że sukcesem jest sam fakt rozpoczęcia projektu…