Structured System Analysis

tools & techniques by Chris Gane and Trish Sarson

Dzisiaj nieco archeologii. Właśnie upolowałem książkę jak poniżej [zotpressInText item=”{5085975:R66WW2XP}”]:

Jednym z powodów był niedawny artykuł (Diagram Przepływu Danych…) na temat diagramów DFD i zobrazowaniu kluczowych funkcjonalności systemów. Książka napisana w 1977 roku, ja mam wydanie z 1989-go (!).

Nie raz tu pisałem, że w branży IT jest źle, nadal: “The Standish Group report 83.9% of IT projects partially or completely fail” (83%9 projektów IT to porażki). Ale ciekawsze jest to, że tak jest od początku tej branży do dzisiaj! Te statystyki rok do roku są niemalże identyczne od dekad.

W ramach chwili luzu pomyślałem, że kilka rzeczy z tek książki tu przytoczę.

Pierwszy rozdział zatytułowany jest Potrzeba lepszych narzędzi. Zawiera między innymi Podrozdział Co poszło źle w analizie? I czytamy np. że projektu kończą sie często stwierdzeniem: “Zbudowaliśmy doskonały technicznie system, ale nie tego chcieli użytkownicy”. Znamy to wszyscy, nie? ;). Albo: [zwykli] ludzie nie wiedzą zbyt wiele na temat elektronicznego przetwarzania danych, dlatego są podatni na propagandę, która obiecuje wiele. To tez znamy, nie? Analitycy zbyt szybko rzucają się na szczegóły (!). Dokumentacja wymagań jest przeładowana szczegółami technicznymi (!). Jeżeli dokumentacja zawiera tyko to co zrozumiałe dla użytkownika, stanowi mało przydatne narzędzie dla programistów (!). Co jest problemem? Brak modeli i nadmiar naturalnego języka w specyfikacjach.

Co proponują autorzy? Proponują modele w postaci diagramów przepływu danych rozumiane jako przepływy logiczne, biznesowe. Proponują budowanie słowników (nazwy dokumentów, ich atrybutów, wartości atrybutów). Co ciekawe, książka powstawała gdy model relacyjny nie był w powszechnym użyciu, pojawiają się raczej pojęcia “dane o książce, dane o zamówieniu”. Mowa jest o dokumentach i plikach w hierarchii: plik -> wiersz -> pole -> podrzędne pole (systemy hierarchiczne organizacji danych i język taki jak np. COBOL lub PL/I). Dane te miały struktury bardzo bliskie dzisiejszym plikom XML.

Logika biznesowa? Albo proste związki między polami (takie jak większy, mniejszy, równy), drzewa decyzyjne albo…. Tablice Decyzyjne ;), które nie raz tu opisywałem, one przeżywają dzisiaj renesans. Co ciekawe nie był żadnych sugestii do usuwania redundancji gdyż dokumenty (formularze) miały swoje indywidualne cykle życia, i przepływ danych był rozumiany jako przepływ tych wypełnionych formularzy. Podział dużych systemów na podsystemy (moduły) był konsekwencją dziedziny (patrz bounded context).

Czy widzicie podobieństwo do dzisiejszych wzorców projektowych? Mikroserwisy, nierelacyjne systemy zarządzania danymi, brak monolitycznych rozwiązań, integracja danych poprzez ich wymianą a nie współdzielenie. Czy to cofanie się? Nie, to sprawdzone wzorce, współdzielenie danych i usuwanie redundancji, nie sprawdza się… Systemy znowu są zorientowane na dokumenty biznesowe. A relacyjne systemy danych? Są i pozostaną raczej tam, gdzie się sprawdzają doskonale: hurtownie danych, big data, itp.

Dawne dokumenty i moduły to dzisiaj obiekty transferujące dane DTO, komponenty, mikroserwisy, systemy rozproszone.

Tyle historii na dzisiaj. 🙂 Czy to jakaś forma nawoływania do powrotu do metod strukturalnych? Nie. Ale dzisiaj mamy metody zorientowane na komponenty, na dokumenty, na logikę przetwarzania nie będąca częścią danych/dokumentów. Czy faktura zawiera jakiekolwiek informacje o tym jak powstała? Nie! Czy Treść umowy zawiera informacje o tym ile trwały negocjacje i skąd sie wzięły takie a nie inne ceny? Nie! Logika biznesowa nie jest częścią danych tak jak wzór na upust nie częścią faktury.

Mamy ogromny postęp w technologii i cały czas ten sam biznes.

Źródła

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

Miesiąc temu pisałem:

Mechatronika i nota­cja SysML ma swo­je począt­ki w latach 90-tych. Modele w tej nota­cji powsta­wa­ły już w fir­mie Boeing (Herrold, 2016). Od tam­tej pory powsta­ło wie­le publi­ka­cji na ten temat, w tym tak­że opi­sy dobrych prak­tyk jaki­mi są wzor­ce pro­jek­to­we (Barbieri, Kernschmidt, Fantuzzi & Vogel-Heuser, 2014). Można spo­tkać coraz czę­ściej publi­ka­cje na temat sto­so­wa­nia metod pro­jek­to­wa­nia opar­tych na SysML (Van Noten, Gadeyne & Witters, 2017).Moim celem było tu zwró­ce­nie uwa­gi na tę w sumie nową dzie­dzi­nę inży­nie­rii, waż­ne by nie utoż­sa­miać jej jedy­nie z robo­ty­ką, bo było by to ogrom­ne uprosz­cze­nie, co mam nadzie­ję poka­za­łem powyż­szy­mi przy­kła­da­mi. (źr.: Inteligentna pralka czyli czym jest mechatronika)

Dzisiaj kontynuacja: kilka słów o zastosowaniach i polecana literatura.

To co nazywamy inżynierią systemów, to multidyscyplinarna dziedzina wiedzy. Założeniem podstawowym jest uznanie, że na etapie analizy i projektowania system (jego model) jest abstrakcją jakiejś implementacji, która nie jest znana. Wiemy także, że obecnie komponenty wszelkich urządzeń to albo elementy mechaniczne (materialne) albo realizujące ich funkcje oprogramowanie (a konkretnie komputer czyli procesor i pamięć oraz program). Komputer jest tu często postrzegany jako ‘uniweralny mechanizm’ [zotpressInText item=”{5085975:LKGQJ85W}”] (patrz także ww. artykuł o pralce: programator mechaniczny vs. elektroniczny). Poniżej podstawowe zastosowanie notacji SysML i cele jej użycia:

Celem jest opisanie urządzenia w postaci systemu współpracujących komponentów (modułów, bloków funkcjonalnych) i wskazanie (zdecydowanie na etapie projektowania) jakiego typu są to (będą) konstrukcje (mechaniczna, elektromechaniczna, elektroniczna, będąca komputerem czyli w grę wchodzi napisanie oprogramowania) oraz opisanie ich współdziałania.

Ogólnie proces tworzenia systemu można zobrazować tak:

Składa się on z trzech kluczowych faz: specyfikowanie, projektowanie i wykonanie komponentów, zestawienie całości i oddanie do użytku. Inżynieria systemów, na etapie projektowania, całkowicie abstrahuje od implementacji i jej szczegółów. Potrzeba ta pojawiła się wraz ze wzrostem złożoności takich konstrukcji jak np. samoloty. Cykl życia projektu systemu i jego samego (np. samolot lub pociąg), gdy składa się on z setek tysięcy detali, jest niemożliwy do zarządzania bez opracowania jego abstrakcyjnej uogólnionej postaci. Warto zwrócić uwagę, że takim złożonym systemem jest także np. nowoczesna fabryka.

W latach 90-tych opracowano (na początku lat 2000 opublikowało OMG.org) notację SysML (rozszerzenie UML) pozwalająca opisać dowolny system na poziomie komponentów i związków między nimi, w całkowitym oderwaniu od ich implementacji [zotpressInText item=”{5085975:WYEVVC8U}”].

Filozofia SysML opera się na dwóch kluczowym strukturach: jest to drzewiasta struktura definiująca typy komponentów i ich zależności całość-część (block definition diagram) oraz struktura obrazująca współdziałanie konkretnych komponentów określonych typów (internal block diagram). Poniżej obrazowy przykład tych dwóch struktur dla samochodu:

SysML, jako metoda modelowania, ma swoją pozycję i kontekst wśród innych:

Standard MBSE (Model-based Systems Engineering) to podejście do inżynierii oparte na modelowaniu (Prezentacja SysML). Jest to niejako kontynuacja abstrakcji “w górę” począwszy od metod takich jak CAD/CAM czyli metod projektowania opartych na rysunku technicznym i modelach 3D. Jak wspomniałem, praktycznie każde urządzenie można skonstruować jako zespół komponentów mechanicznych i będących komputerem. Jeżeli “wzniesiemy” się na wyższy poziom abstrakcji, będzie na poziomie notacji SyML. Schematycznie można to pokazać tak:

Druga książka, którą chciałbym polecić to “SysML for Systems Engineering”. Autorzy tej książki skupili sie na samej notacji, tu przykłady (w przeciwieństwie do poprzedniej) są na drugim planie, dlatego ta pozycja to raczej podręcznik.

Pozycje te doskonale sie uzupełniają. Oczywiście zawsze warto pamiętać, że źródło jest na stronie OMG.org [zotpressInText item=”{5085975:E9MDNWLY}”].

Dla przerażonych nową wiedzą do pozyskania (pierwsza książka 600 stron, druga 300, niestety obie tylko import), być może dobrą na początek będzie cieniutka pozycja “Język inżynierii systemów SysML: architektura i zastosowania : profile UML 2.x w praktyce” [zotpressInText item=”{5085975:QFTJKM5V}”], jednak uprzedzam, że to tylko krótki opis samej notacji.

Czy to działa? jeden z czołowych dostawców systemów CAD/CAM pisze (źr. pod cytatem, nie mam żadnej umowy z firmą Siemens):

W czasach gdy nowoczesne produkty mogą zawierać elementy mechaniczne, elektroniczne, elektryczne i oprogramowanie, trudno jest sobie wyobrazić użycie narzędzia do modelowania, które może uwzględnić tylko ograniczony dziedzinowo zestaw schematów blokowych (np. tylko mechaniczne). Zwłaszcza, że każda z tych dziedzin będzie prawdopodobnie zawierać wiele własnych podsystemów, które integrują się w większy system systemów. Nasze [Siemens, mój przypis] zaangażowanie w SysML v.2. ma kluczowe znaczenie dla przyszłości rozwoju projektowania – kompleksowe modelowanie MBSE zapewnia szybsze podejmowanie lepszych decyzji. Eliminuje ryzyko i poprawia jakość projektów poprzez optymalizację i weryfikację szerzej pojmowanej definicji architektury produktu. Przełamuje granice pomiędzy dziedzinowymi działami rozwojowymi, aby osiągnąć interoperacyjność i wymianę wiedzy w całym łańcuchu wartości. Będziemy kontynuować naszą pracę jako aktywny partner w opracowywaniu standardu języka modelowania następnej generacji oraz zgodnego z nim rozwiązania MBSE, aby zrewolucjonizować sposób, w jaki firmy tworzą, udostępniają i optymalizują systemy w całym przedsiębiorstwie.

Polecam także to:

Źródła

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

Wprowadzenie

Jednym z podstawowych problemów w projektach związanych z systemami informacyjnymi, jest komunikacja z ekspertami dziedzinowymi sponsora projektu. Osoby te stanowią podstawowe źródło informacji i są także kluczowymi recenzentami powstającej dokumentacji: potwierdzają, że analityk i projektant zrozumiał dziedzinę problemu.

Sformalizowane systemy notacyjne są niejednokrotnie dość bogate w symbole, te zaś dla większości ludzi są mało intuicyjne, a ich formalizm bywa niezrozumiały. W efekcie analitycy i projektanci albo prowadzą szkolenia przygotowujące zespoły projektowe do projektu albo uciekają się do stosowania łatwo przyswajalnych nieformalnych schematów blokowych. Obie drogi stwarzają ryzyko w projekcie. Pierwsza podnosi koszty projektu, a czasami powoduje także frustrację zespołu adresata dokumentów projektowych. Druga droga bardzo szybko prowadzi do wielu niejednoznaczności i niespójności (nieformalne schematy blokowe nie poddają się żadnej kontroli poprawności, w większych projektach niejednoznaczność, niespójność i niekompletność dokumentacji stają się główną przyczyną niepowodzeń).

W projektach analizy biznesowej i inżynierii oprogramowania mamy lukę między notacjami BPMN i UML, a jest nią specyfikacja logiki przetwarzania informacji. W notacji BPMN (analityczne modele procesów biznesowych) praktycznie nie ma na nią miejsca (Obiekt Danych jedynie symbolizuje dokument jako produkt pracy), zaś w notacji UML jest ona już głęboko ukryta w postaci atrybutów i metod operacji klas.

Uważam, że należy wykorzystywać istniejący dorobek każdej dziedziny wiedzy. Tak więc, zanim zaproponujmy tworzenie kolejnego systemu notacyjnego (lub komplikowanie istniejącego), warto się upewnić, że jest to konieczne (brzytwa Ockhama w nauce).

W tym artykule podejmuje próbę rozwiązania tego problemu z pomocą diagramów DFD (diagram przepływu danych, ang.. DataFlow Diagram). Diagramy te to narzędzie pochodzące z czasów stosowania metod strukturalnych w analizie i projektowaniu (lata 70-te XX wieku).

Diagram przepływu danych (DFD)

W 2017 roku, przy nieco innej okazji, pisałem:

Metody struk­tu­ral­ne ana­li­zy i pro­jek­to­wa­nia bazu­ją na uzna­niu, że opro­gra­mo­wa­nie to stos funk­cji ope­ru­ją­cych na bazach (skła­dach) danych. Innymi sło­wy pod­sta­wo­we zało­że­nie to ist­nie­nie odręb­nych bytów jaki­mi są baza danych oraz funk­cje, któ­re na tych danych wyko­nu­ją ope­ra­cje. W meto­dach struk­tu­ral­nych two­rzy dwa się rodza­je mode­li: model pro­ce­su prze­twa­rza­nia i model struk­tu­ry danych. Pierwszy wyko­rzy­stu­je nota­cję DFD (Data Flow Diagram, np. nota­cja Gane?a- Sarsona) a dru­gi nota­cja ERD (Entity Relationship Diagram, np. nota­cja Martina) do mode­lo­wa­nia struk­tur rela­cyj­nych baz danych. [zotpressInText item=”{5085975:KD6GH3YZ}”] (blog: Architektura kodu aplikacji jako pierwszy etap tworzenia oprogramowania – Jarosław Żeliński IT-Consulting).

Nie namawiam tu nikogo do powrotu do strukturalnych metod analizy i projektowania. Jednak same diagramy DFD, jako system notacyjny, mają ważną zaletę: modele logiczne (są także fizyczne) są intuicyjne. To zaś powoduje, że na określonym poziomie abstrakcji sprawdzają się jako narzędzie komunikacji z ekspertami dziedzinowymi. Pozostaje tylko zdefiniowanie tego poziomu abstrakcji.

Pojęcie systemu

Dowolny system, także informacyjny, można sprowadzić do architektury składającej się trzech typów elementów: byt poza systemem oraz system, który zbudowany jest z elementów reprezentujących: interfejs (sensor, efector), procesy przetwarzania danych (operacje na danych) i repozytoria danych (pamięć) [zotpressInText item=”{5085975:MQRSLUZH}”].

Istotą diagramów przepływu danych jest uproszczenie polegające na przyjęciu założenia, że model systemu to proces przetwarzania i repozytorium danych zaś jego otoczenia to określony byt zewnętrzny.

W metodach strukturalnych [zotpressInText item=”{5085975:R66WW2XP}”] pojęcie ‘proces’ dotyczy każdej, nawet bardzo detalicznej, operacji na danych (patrz tytuły dawnych podręczników informatyki: “algorytmy + struktury danych = programy”). Moja propozycja zastosowania modeli przepływu danych dotyczy wyłącznie poziomu, na którym operujemy wyłącznie pojęciami (nazewnictwo) z analizowanej dziedziny a modele zawierają wyłącznie nazwane biznesowe operacje i dokumenty jako nośniki danych. Cały czas chodzi wyłącznie o komunikację z ekspertami dziedzinowymi, wiec używane na tych diagramach słownictwo nie może wykraczać poza dziedzinę problemu.

Notacja Gane’a-Sarsona

Kluczowe elementy diagramów przepływu danych omówię stosując popularną notację Gane’a-Sarsona [zotpressInText item=”{5085975:R66WW2XP}”]. Semantyka notacji (symbole i ich znaczenie) operuje trzema symbolami:

1. byt zewnętrzny (External Entity): jest to źródło lub adresat treści (danych) czyli zewnętrzne systemy (otoczenie systemu modelowanego),
2. proces (Process): miejsce (metoda) przetwarzania treści (danych) czyli element realizujący logikę działania systemu,
3. repozytorium (Data Store): miejsce przechowywania treści (danych) czyli pamięć systemu,
4. jednostka danych (Note, treść przekazywana): treść (zestaw danych).

Syntaktyka notacji jest także prosta, obowiązuje jedna zasada: w przekazywaniu danych z miejsca w miejsce zawsze pośredniczy proces. Graficznie przedstawia to diagram:

Przykłady niepoprawnych (po lewej stronie) i poprawnych (po prawej) konstrukcji:

W opisywanej tu metodzie, Data Stor (repozytorium) reprezentuje zbiór dokumentów, te zaś traktujemy tu ‘obiektowo’ jako dokumenty (pojedynczy klasyfikator lub agregat w notacji UML, w metodach strukturalnych dane przechowywane są relacyjnych bazach). Pojęcie Proces na diagramach DFD utożsamiamy z kompletną operacją na dokumencie lub jego części (na danych). W ten sposób uzyskujemy zgodność pojęć Proces i Data Stor odpowiednio z pojęciami Operacja i Repozytorium w notacji UML i wzorcu projektowym DDD (Domain Driven Design [zotpressInText item=”{5085975:6J8CWYMV}”])

Kontekst użycia diagramów DFD

Istotą użycia diagramów DFD jest dialog z dziedzinowym ekspertem, który jest beneficjentem projektu dostarczenia oprogramowania. Jak już wspominałem, poszczególne notacje (nie raz opisywane na tym blogu) to specjalizowane systemy pojęciowe. Specjalizowane dla konkretnych etapów projektu i dziedziny (obszaru) modelowania. Spotykam się nie raz z próbami tworzenia własnych, uniwersalnych “super notacji” do wszystkiego lub tak zwanym przeciążaniem (nadużywaniem i niewłaściwym użyciem) istniejących notacji (uważam, że notacja ArchiMate jest tego przykładem).

Kiedy można użyć notacji DFD? Proces od rozpoczęcia analizy do dostarczenia oprogramowania to:

1. analiza tekstów dziedzinowych (materiały źródłowe)
2. opracowanie modeli procesów biznesowych organizacji analizowanej (notacja BPMN),
3. opracowanie zakresu projektu dostarczenia oprogramowania (notacja UML, diagram przypadków użycia),
4. opracowanie logiki działania aplikacji (notacja DFD, zestaw modeli w notacji UML).
5. opracowanie dokumentu Specyfikacja Wymagań (Opis Przedmiotu Zamówienia, Opis Techniczny Rozwiązania),
6. Odebranie i wdrożenie oprogramowania (Aplikacja).

Schematycznie pokazano to na diagramie poniżej:

Wszystko jest ‘w tle’ (nie pokazano na diagramie) uzupełnione biznesowym słownikiem pojęć i reguł..

Stosowanie sformalizowanych notacji daje nam narzędzie do kontroli spójności, poprawności i kompletności całego projektu: projekt może być (a nawet dobrze by było aby był) w całości prowadzony i dokumentowany z użyciem narzędzi CASE (a nie prostymi narzędziami biurowymi takimi jak edytor tekstu czy arkusz kalkulacyjny). Dobór notacji daje nam możliwość skutecznej, z użyciem dziedzinowego słownictwa, komunikacji z kluczowymi aktorami: Beneficjent oraz Dostawca.

Diagram DFD pełni rolę abstrakcji systemu. Jest (powinien być) zrozumiały dla Beneficjenta i dla Dostawcy gotowego oprogramowania. Jeżeli dostępne na rynku istniejące oprogramowanie nie spełnia (wszystkich) wymagań (nie realizuje wszystkich potrzebnych operacji na dokumentach i ich treści), powstaje dodatkowy projekt architektury (model dziedziny systemu) z użyciem notacji UML i na jego podstawie zamawiane jest dedykowane oprogramowanie.

Harmonizacja notacji

Jak widać na powyższym diagramie, użytych zostało kilka notacji. W inżynierii jest to, wbrew pozorom, dość powszechne zjawisko. To co nazywamy popularnie ‘rysunkiem technicznym’ to schematy blokowe. Zależnie od etapu projektowania i branży, używane są różne dziedzinowe systemy pojęciowe i biblioteki symboli opisane normami ISO/IEEE. Zapewniam, że używanie kilku notacji w jednym projekcie nie jest absolutnie żadnym ewenementem w inżynierii. Istotne jest zapewnienie spójności całości dokumentacji.

Poglądowo opisana harmonizacja pojęć i notacji:

1. analiza tekstów źródłowych (materiałów) prowadzi do powstania modeli procesów biznesowych, słownika pojęć, specyfikacji dokumentów, identyfikacji reguł biznesowych (notacje BPMN oraz SBVR),
2. elementarny proces biznesowy to zadanie (atomowa/elementarna aktywność) zwieńczone produktem (wyjście procesu: zestaw danych zebranych jako dokument), (BPMN)
3. zadanie to jedna lub więcej operacji na danych objętych jednym dokumentem (BPMN),
4. uzgodnienie z zamawiającym zakresu projektu (co system ma robić) prowadzi do powstania diagramu przypadków użycia UML (model systemu jako czarna skrzynka),
5. dla zakresu projektu powstaje opis logiki biznesowej jako lista dokumentów oraz operacji na nich i metod wykonania tych operacji w postaci modelu przepływu danych (DFD), model systemu jako biała skrzynka,
6. operacje na danych są wykonywane wg. określonej metody (np. algorytm) (różne formy: wzory matematyczne, procedury, diagramy aktywności UML, inne),
7. jeżeli ma powstać dedykowane oprogramowanie, należy zaprojektować jego architekturę (model PIM UML), czyli podzielić system na komponenty i każdemu z nich przyporządkować opisane operacje na dokumentach i danych jakie ma wykonywać, model systemu jako biała skrzynka.

Nadal aktualne zastosowania czyli hurtownie danych i raportowanie

Diagramy DFD znajdują nadal – polecam – zastosowanie w projektowaniu systemów raportowania, a konkretnie do analizy i modelowania zasilania systemów raportowych takich jak hurtownie danych. Poniżej typowa sekwencja:

Po lewej stronie mamy różne źródła danych: typowe bazy danych, pliki np. CSV, inne źródła (arkusze kalkulacyjne itp.). Pierwszy etap to normalizacja tych danych. Polega on na opracowanie wspólnego słownika definicji pojęć i metadanych (master data) i przekształceniu danych źródłowych do jednej, ustalonej postaci i formatu (Pobranie i normalizacja). Powstają znormalizowane obrazy danych źródłowych, nie są tu jeszcze przekształcane czy przeliczane. Kolejny etap to opracowanie, na bazie potrzeb raportowych Adresata raportów, kostek analitycznych (Hurtownia danych). Mając te kostki, projektujemy proces ETL (zasilanie hurtowni, ang. extract transform load).

Mając hurtownię danych (zdenormalizowane repozytorium danych gotowe do generowania raportów) można do niej podłączyć dowolny system raportowania z tego typu danych (na diagramie powyżej oznaczony na niebiesko).

Dane (zbiory danych) modelujemy najczęściej z użyciem diagramów ER. Przekształcenia najłatwiej dokumentować jako algorytmy, np. z użyciem diagramów aktywności UML, ewentualnie z użyciem pseudokodu (jednak tego niestety raczej nie będzie rozumiał użytkownik).

Więcej o hurtowniach danych: Hurtownie danych i analizy – jak je robić?

Podsumowanie

Analiza i projektowanie to złożony proces modelowania. Utrzymanie spójności, kompletności i niesprzeczności dokumentacji zawierającej wiele schematów blokowych jest bardzo trudne, dlatego stosuje się do tego narzędzia CASE i sformalizowane notacje. Bez tego utrzymanie wymaganej jakości dokumentów w inżynierii oprogramowania graniczy z niemożliwością, lub staje się kluczowym kosztem samo w sobie (pamiętajmy, że zła dokumentacja generuje koszty wprowadzania poprawek na etapie implementacji i wdrożenia).

Opisana metoda i miejsce stosowania diagramów DFD pozawala wprowadzić formalizm do specyfikowania logiki biznesowej, jeszcze zanim zaczniemy używać notacji UML, która dla większości beneficjentów jest niezrozumiała. Stosowanie diagramów DFD wymaga jednak określenia poziomu abstrakcji oraz przyjęcia definicji pojęć operacja (proces w DFD) i metoda zgodnych z definicjami tych pojęć w notacji UML (to narzuca poziom abstrakcji dla modeli DFD).

Podobne modele, niestety chyba mniej intuicyjne w percepcji dla osób niedoświadczonych w UML [zotpressInText item=”{5085975:DCYU6XZJ}”], można tworzyć z użyciem diagramów aktywności :

Wybór pozostawiam czytelnikom ;).

[wpdm_package id=’47826′]

Źródła

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

Wprowadzenie

?Problemy, w których rozwiązaniu mają pomóc budowane złożone systemy są zwykle ?problemami złośliwymi? [zotpressInText item=”{5085975:3E8MCCST}”]. ?Problem złośliwy? to taki skomplikowany problem, w którym jest tak wiele powiązanych ze sobą bytów, że nie istnieje jego ostateczna specyfikacja. Prawdziwy charakter problemu objawia się dopiero w miarę opracowywania rozwiązania.?

W roku 2014 w artykule Studium wykonalności produktu – czym naprawdę jest napisałem na zakończenie:

W literaturze można spotkać różne ?definicje? studium wykonalności, jednak ta którą opisałem, zdaje się być najbliższa definicji, którą przytoczyłem na początku: bazującej na znaczeniu słownikowym. Praktyka pokazuje, że intencje sponsorów tych analiz są z nią zbieżne: celem jest podjęcie decyzji o najmniejszym ryzyku w świetle posiadanej na dany temat wiedzy.

Definicje bazujące na technicznej i finansowej wykonalności danego projektu, są spotykane dość często i w literaturze i na stronach wielu instytucji. Metoda prowadzenia takich analiz, bazująca na modelowaniu czyli na analizie systemowej,  wydaje się być jednak najwłaściwszą.

Warto jednak zwrócić uwagę, że wykonalność techniczna a zdolność do sfinansowania to nie to samo?  Studium wykonalności technologicznej dotyczy produktu projektu lub efektu organizacyjnego jakiego oczekujemy. Ocena tego czy pozyskamy finansowanie to nie wykonalność a zdolność do sfinansowania (studium wykonalności finansowo-ekonomicznej). To są różne analizy.

To był artykuł o ogólnych zasadach realizacji analizy jaką jest studium wykonalności. Tym razem o tym, czym konkretnie jest etap często nazywany Identyfikacją projektu i czym zajmuje się jako analityk w takich projektach.

Struktura analizy

Kontynuując wątek studium wykonalności, opracowanie takie można zobrazować tak:

Każda inwestycja ma charakter materialny i finansowy. Materialny dotyczy przedmiotu inwestycji (nowy lub zmieniany system) zaś finansowy dotyczy kosztu jego pozyskania lub zmiany.

Moja praca to opracowanie Modelu systemu. Potrzebuję do tego eksperta dziedzinowego. Analiza finansowa i opis finansowania, powstają na podstawie Modelu. Całość dopiero stanowi sobą Studium Wykonalności (nie licząc oczywiście samego wniosku, który opracowuje wnioskujący).

Wymagania formalne

Instrukcje dla wnioskodawców (np. Instrukcja sporządzania Studium Wykonalności Inwestycji (Projektu) dla wnioskodawców ubiegających się o wsparcie z Europejskiego Funduszu Rozwoju Regionalnego w ramach Regionalnego Programu Operacyjnego Województwa Świętokrzyskiego na lata 2014-2020, dalej Instrukcja) zawierają między innymi takie zalecenia:

Identyfikacja projektu powinna dostarczyć zwięzłej i jednoznacznej informacji na temat jego całościowej koncepcji i logicznych ram. Projekt powinien stanowić samodzielną (pod kątem operacyjności) jednostkę analizy. Oznacza to, że powinien on obejmować wszystkie zadania inwestycyjne, które sprawiają, że efektem realizacji projektu jest stworzenie w pełni funkcjonalnej i operacyjnej infrastruktury, bez konieczności realizacji dodatkowych zadań inwestycyjnych nie uwzględnionych w tym projekcie.

To oznacza, że musi powstać projekt całości rozwiązania. Studium wykonalności to opracowanie pokazujące także model rozwiązania będącego przedmiotem analizy, jego wewnętrzną strukturę i mechanizm działania.

Podstawowym celem studium wykonalności technicznej jest uwiarygodnienie tego, że system będący przedmiotem wniosku, może powstać i spełni swoją rolę, tego że cel projektu zostanie osiągnięty. Celem projektu nie może być samo tylko pozyskanie dotacji.

Jak to uwiarygodnić? Należy wykazać nie tylko to, że posiada się środki na sfinansowanie przedsięwzięcia, należy przede wszystkim uwiarygodnić to, że system powstanie i osiągnięte zostaną cele zapowiadane efekty. Jak? Po prostu należy opracować model systemu, nie raz wręcz od zera go zaprojektować, i pokazać, że rozumiemy to co chcemy wytworzyć lub zmienić.

Studium wykonalności to najczęściej żądanie inwestora, czyli podmiotu finansującego przedsięwzięcie. Celem inwestora zaś nie jest samo tylko wydawanie pieniędzy. Jak już pisałem w artykule Studium wykonalności produktu – czym naprawdę jest, studium wykonalności powinno zawierać opis stanu przedmiotu analizy obecnego i planowanego.

Wymieniona na początku Instrukcja jasno precyzuje:

Opis stanu aktualnego (przed realizacją)
Elementem wyjściowym w poprawnie sporządzonej analizie jest rzetelny i dokładny opis stanu aktualnego inwestycji planowanej do realizacji. Jasno i czytelnie opisany aktualny stan pozwala w sposób przejrzysty przejść do identyfikacji istniejących problemów oraz potrzeb, a tym samym do uzasadnienia potrzeby realizacji projektu. Celem opisu stanu obecnego jest oddanie pełnego obrazu stanu istniejącego i przedstawienie otoczenia, w którym będzie realizowany projekt. Opis stanu obecnego jest również podstawą oceny potrzeby realizacji projektu. […] Na tym etapie powinny być wskazane obecne problemy wynikające ze stanu aktualnego.

Kolejna część opracowania powinna zawierać:

Opis stanu projektowanego
Wymagane jest szczegółowe doprecyzowanie i uzasadnienie zakresu rzeczowego projektu, prezentując jego cel, kwestie których będzie dotyczył, infrastrukturę jaka ma zostać stworzona, itp. […] Dodatkowo, należy przeprowadzić analizę projektu w kontekście całego układu infrastruktury, tj. funkcjonalne i rzeczowe powiązania między danym projektem, a istniejącą infrastrukturą.

Zwieńczeniem całości tej części Studium Wykonalności powinna być:

Definicja celów projektu
Zdefiniowanie celów jest niezbędnym etapem służącym identyfikacji i analizie projektu. Stanowi ono punkt wyjścia do przeprowadzenia jakiejkolwiek oceny inwestycji.

oraz

Wskaźniki realizacji celów projektu
Realizacja celu musi być mierzona za pomocą przynajmniej jednego wskaźnika rezultatu.

Zależnie od naboru istotne są detale dotyczące celów sponsora, jednak co do zasady studium wykonalności to nie tylko analiza finansowa. Kluczem jest wykazanie, że otrzymane środki finansowe przyniosą oczekiwane efekty:

Zgodnie z cytowana instrukcją Wniosek o finansowanie to opisu określonego etapu rozwoju organizacji (systemu): pomiędzy Stanem aktualnym a Stanem planowanym (patrz wykres powyżej). Całość to nic innego jak standardowa procedura tak zwanej ogólnej analizy systemowej (której nie należy utożsamiać tylko z systemami informatycznymi):

Najpierw dowiedzmy się ?jak jest i dlaczego jest tak jak jest? a potem napiszmy ?jak powinno być i co należy uczynić, aby było tak jak być powinno? [zotpressInText item=”{5085975:NHWMP6KJ}”].

W dalszej części opiszę pokrótce jak sformalizowanymi metodami i narzędziami można wykonać powyższą analizę.

Sformalizowane modelowanie systemów

Nie tak dawno, w artykule o mechatronice (Inteligentna pralka) prezentowałem metodę projektowania systemów wymagających interdyscyplinarnej wiedzy. Prosty diagram poniżej pokazuje strukturę opisanego tam systemu:

Struktura taka jak ta, pokazuje elementy z jakich składa się rozwiązanie i to jak owa całość jest skonstruowana, jak współdziałają jej poszczególne elementy. Taki model jest pierwszym testem pokazującym, że “to będzie działało”. Modele takie można testować, bo ich tworzenie to sformalizowany proces. Wśród wielu cech elementów modelu jest (może być) także koszt jego pozyskania. Dlatego model taki nie tylko pełni rolę projektu, pełni także role szkieletu wyceny: każdy element należy wycenić czyli podać koszt wytworzenia lub zakupu komponentów, koszt pracy związanej z jego montażem, koszt uruchomienia całości.

Najczęściej w dokumentach tego typu spotykamy schematy blokowe, opracowane jako nieformalne struktury, np. takie jak poniższa:

Zaletą takiej formy prezentacji jest relatywna łatwość ich opracowania, pewne walory estetyczne, wadą zaś tej formy jest to, że nie istnieje żadna możliwość walidacji takich diagramów (weryfikacji poprawności, spójności i kompletności). Jako model są praktycznie nieprzydatne do innych celów niż nieformalna ilustracja. Niestety nie nadają się jako materiał badawczy do studium wykonalności.

Aby uzyskać model do celów analizy, należy schemat blokowy sformalizować. Standardowym narzędziem formalizacji w inżynierii są rysunki techniczne, jednak te pozwalają jedynie na udokumentowanie struktury konstrukcyjnej.

W obecnych czasach coraz więcej konstrukcji to właśnie konstrukcje mechatroniczne, czyli struktury składające się elementów nie tylko mechanicznych. Elementy tych struktur nie tylko “są z sobą połączone”, one na siebie oddziałują, i to nie raz w bardzo wyrafinowany sposób: wymieniają sygnały sterujące. System grzewczy – nieformalny diagram – pokazany powyżej, w wersji sformalizowanej będzie wyglądał mniej więcej tak jak schemat poniżej (to nie jest ten sam system, to wyłącznie przykłady dokumentów):

Formalizm tych schematów polega na precyzyjnym opisie (modelowaniu) nie tylko samej konstrukcji, zawiera także pełny opis mechanizmu działania.

Jak widać, szczegółowość opisu można dostosować do potrzeb: celu tworzenia modelu.

Modele tworzone do celów studiów wykonalności charakteryzują się mniejszą liczba szczegółów. Celem ich tworzenia jest raczej inwentaryzacja komponentów systemu, pozwala to łatwo uzupełnić cechy komponentów np. o ich koszt pozyskania i pracochłonność uruchomienia (koszt pracy). Wtedy struktura modelu ma postać np. jak poniżej [zotpressInText item=”{5085975:8G9TUWIG}”]:

Podsumowanie

Korzystanie z analizy systemowej jako narzędzia i tworzenie sformalizowanych schematów blokowych, na użytek analiz wykonalności, to nie tyko uwiarygodnienie samej analizy.

Studium wykonalności stanowi sobą pre-projektowanie systemu będącego przedmiotem analizy. To początek opracowywania rozwiązania.

[zotpressInText item=”{5085975:KAY59SH7}”], [zotpressInText item=”{5085975:9DAY8HXY}”]

To także obniżenie ryzyka projektu, gdyż modele systemowe pozwalają na weryfikację projektu już na etapie jego dokumentowania. Dodatkowo, uzupełniając modele o koszty komponentów, uwiarygadniamy także wycenę: mamy pewność, że niczego nie pominęliśmy. [zotpressInText item=”{5085975:XH3U2B6I},{5085975:9MFQNJPQ},{5085975:N9375TBL},{5085975:F5MT57P3}”] [zotpressInText item=”{5085975:B9NB3E9J},{5085975:ZBNE5XBH},{5085975:S2MEXIVA}”].

Oferta

Osoby zainteresowane wyceną takiej usługi (zawsze Analiza Biznesowa, czasami także Projekt Techniczny Rozwiązana) zapraszam na stronę Regulamin świadczenia usług.

Źródła

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

15 Maja 2020 odbyło się ciekawe wirtualne spotkanie (zapowiedzi). Zarejestrowało sie ponad 1200 osób, ponad połowa tej liczby brała faktycznie udział. To oznacza, że mają sens zapowiadane i poruszone tam tematy.

O konferencji

Konferencja MAP IT ? Management, Analiza i Produkt w IT zorganizowana została przez Hannę Wesołowską z analiza IT. Ogromne ukłony dla Eleny Zhukovej, Olgi Springer z Product Vision oraz pozostałych znakomitych prelegentów ? Jarka Łojewskiego z Fundacji Dobra Porażka, Michała Bartyzela oraz Michała Redy i Mateusza Kapicy z Product Vision. Ostatnim referatem był mój referat o formalizmach w analizie i projektowaniu.

Zainteresowanie spotkaniem przeszło najśmielsze oczekiwania. Na konferencję zapisało się ponad 1200 osób. W ciągu dnia pojawiło się 1086 unikalnych użytkowników. W szczytowym momencie mieliśmy niemal 800 osób słuchających na żywo.

Nad techniczną stroną przygotowania i przebiegu wydarzenia czuwał Piotr Król ze studia 306 w Gdyni. Piotr obsługuje wydarzenia tej skali (i większe) w wielu branżach, m.in. dla marketingowców, traderów. Podkreślił, że nasze wydarzenie zgromadziło dużą widownię jak na działania organiczne (niewspomagane płatnymi reklamami w Internecie), dostrzegł dużą, w porównaniu z innymi branżami, frekwencję oraz zaangażowanie uczestników.

Nie było jeszcze takiego wydarzenia łączącego tematykę zarządzania przedsiębiorstwem, analizy biznesowej i zarządzania produktem w IT. Ogromnym sukcesem było nie tylko liczne przyciągnięcie zainteresowanych. 94% uczestników konferencja bardzo przypadła do gustu ? 40% osobom podobała się bardzo (5 w skali na 6) a 54% osób było wręcz zachwyconych (6/6). Znakomite oceny otrzymała także każda z prelekcji! Nie było tam słabej, ani nawet średniej prezentacji. Uczestnicy docenili wysoki poziom merytoryczny.

Kolejna edycja MAP IT planowana jest jeszcze na 2020. Śledź komunikaty na analiza IT.

O moim referacie

Dla mnie każde wystąpienie publiczne to nauka i informacja zwrotna z rynku. Publikuję na gorąco wpisane uwagi uczestników, żeby sobie i Wam pokazać, że: uważam, że ma sens praca moja i mi podobnych, ma sens skupienie się głownie na sceptykach bo pokazują, że problem istnieje i należy go identyfikować.

Moja prezentacja była: krótka (30 minut), nieco chaotyczna, skupiona na jednej przykładowej dokumentacji projektu, którą uznaję za wręcz ortodoksyjnie formalną (kilkanaście stron, 50% to schematy blokowe UML). Skupiłem się na tym, że rynek odbiorców oprogramowania wskazuje na źródło problemu i czym jakie są oczekiwania rynku, także na jego patologii. Okrojony czas skutkował tym, że skupiłem sie nie na treści tej dokumentacji, a na wskazaniu tego tego, jakie ryzyka projektu (inżynieria oprogramowania) niweluje każda jej część. Nie był bym sobą, gdybym nie ironizował, to prowokuje emocje, a emocje zmuszają do nieszablonowego myślenia.

Znamienne jest to, że chyba wszyscy prelegenci używali słowa “produkt” w stosunku do oprogramowania. Byłem chyba jedynym prelegentem pracującym po stronie kupującego. Dla mnie, jako analityka i projektanta, oprogramowanie jest narzędziem, jakie nabywa organizacja. Oprogramowanie jako produkt, to perspektywa dostawcy. To jest moim zdaniem to, co różniło mój referat od pozostałych i mam nadzieję, że poszerzyło uczestnikom spojrzenie na problemy tej branży.

Mój referat miał wiele pozytywnych komentarzy, co motywuje do dalszej pracy, ale były i krytyczne. Poniżej właśnie te uwagi do mojej prezentacji i moje wyjaśnienia ;), a,bo usprawiedliwienia.

jak zwykle Pan Jarosław skupia się bardzo na UML, który chyba przez większość agile’owców jest czymś przestarzałym

UML to sformalizowana metoda graficznego dokumentowania wyników analiz i projektów. Od wielu lat UML jest rozwijany, powstają dedykowane wydawnictwa na temat modelowania w inżynierii (SySoM), świat wskazuje że w branży IT jest poważny problem (tylko ok. 15% projektów inżynierii kończy się sukcesem). Moją intencją jest jednak odkrycie tego co jest przyczyną sukcesów tych 15%… Pojęcie agile’owca niestety kojarzy się z projektami realizowanymi metodą prób i błędów i bez żadnej metody… Niestety to brak metod jest “przestarzały”…

widać, że p. Jarosław zatrzymał się na publicu i jest trochę oderwany od rzeczywistości

Nie wiem skąd teza, że formalizmy to cecha instytucji publicznych. Wielokrotnie w prezentacji przywoływałem doświadczenie z projektów dla firm prywatnych, nie mających żadnych rygorów narzucających formalizm… Wiem, że ludzie nie lubiący formalizmów, często nie słuchają niczego innego niż zgodnego ich poglądem.. W tej prezentacji celowo w 100% bazowałem na faktach… (sektor zwany public to ok. 30% moich klientów).

stereotypy, mnóstwo utrwalonych stereotypów, m.in. programisty-klikacza i inne. 🙁

Tu pojawia się wiele nieporozumień i niestety manipulacji. W prezentacji celowo poświęciłem “dedykowany czas” na relacje odbiorcy oprogramowania z jego dostawcą. Podkreślałem rolę separacji projektowania od wykonania. Podstawowym powodem jest konflikt interesu projektanta i wykonawcy (pierwszy maksymalizuje zakres projektu i minimalizuje jego koszt, drugi dokładnie odwrotnie, bo koszt zamawiającego to przychód dostawcy). Trzeba tu sobie jasno powiedzieć: w projekcie developer nie powinien być projektantem. Jeżeli jakiś programista czuje w sobie także ducha projektanta, to może i dobrze, ale nie powinien pełnić obu ról jednocześnie w jednym i tym samym projekcie.

Oryginale materiały pokonferencyjne od organizatora

• Wiecej czasu.
• Za szybko, zbyt chaotycznie
• wydluzyc czas 🙂
• –
• Za mało czasu 🙁
• ciekawe podejście no i dokumentacja
• Konkretne przykłady.
• celnie i dobrze, w oparciu o przykłady, choć trochę butnie 😉
• świetna prezentacja – zabawnie i przekornie, jak zawsze:)
• Proszę wydłużyć 🙂
• Dobra prezentacja, ale jak zwykle Pan Jarosław skupia się bardzo na UML, który chyba przez większość agile’owców jest czymś przestarzałym
• Za krótko i za mało. Z chęcią uczestniczył bym nawet i w tygodniowym jego wykładzie.
• Super
• Pan Jarek może i bez prezentacji – po prostu opowiadać o doświadczeniu 😀
• Duży konkret logiczny, jest o czym mysleć.
• Kontrowersyjne, choć bardzo prawdziwe podejście do projektowania systemu, opisywania wymagań. Szkoda, że nie było pola do dyskusji, z Panem Jarkiem pewnie można byłoby godzinami dyskutować.
• konkretnie, z przykładem i na temat
• Wydłużyć czas prezentacji
• całość wystąpienia świetna
• Jarka się lubi albo nienawidzi 🙂 SUPER
• widać, że p. Jarosław zatrzymał się na publicu i jest trochę oderwany od rzeczywistości
• Mnóstwo “mięsa” i nie owijania w bawełnę.
• Łał. To to na co się czekało. Wielkie Podziękowania. Prosimy częściej.
• Na plus – prezentacja ciekawie poprowadzona. UML nie umarł 🙂
• krótko zwiezle i na temat z prawdziwym przykladem
• Prezentacja fajna Szkoda, że po tej prezentacji nie mógł się wypowiedzieć ktoś ze świata zwinnego by zrobić taką małą kontrę. Albo może nawet taki “ring” gdzie mogły by się zetrzeć ze sobą 2 osoby z tradycyjnego i zwinnego sposobu wytwarzania oprogramowania 😉
• Totalnie inne podejście do problemu. Inny świat. Lepiej jest pokazać liczby niż o nich opowiadać. Po za tym super.
• Dla mnie nieco za trudne słownictwo i za szybko, bo nie zajmuję się analizą biznesową, a w IT pracuję od niedawna. Lubię takie kontrowersyjne i prowokatywne podejście, skłaniające do samodzielnego myślenia, a nie ślepego podążania za trendami.
• Było dokładnie tak, jak się spodziewałem i jak miałem nadzieję, że będzie 🙂
• Plus za konkretną prezentację z konkretnym przykładem.
• ten sarkazm przeszkadza w odbiorze faktów, nie mogłam się skupić na treści
• więcej takich wystąpień i dłuższe proszę 🙂
• Merytorycznie nic do zarzucenia. Za szybko, z pewnych elementów można było zrezygnować. Pytanie jaki był cel? Jeśli przekonać nieprzekonanych, to pewnie się nie udało.
• Dla mnie może nieco zbyt “akademickie” wystąpienie. Ale znów brak merytorycznych uwag. Za słaba jestem w te klocki.
• podobało mi się wyjaśnianie i tłumaczenie wszystkiego po “chłopsku”, trochę takiej ciętej, aczkolwiek dowcipnej ironii która sprawia że trzeba pomyśleć nad sobą
• Prezentacja byłą istną wisienką na torcie pod kątem tematyki i podejścia do sposobu wykonywania analizy i tworzenia dokumentacji. Oczywiście ogromny niedosyt i przydałby się cały dzień z Panem Jarkiem aby właściwie poukładać sobie w głowie wszystko tak jak trzeba i przestać marnować czas na zbędne działania i opisy w dokumentacji
• Klasa… Super merytoryka, energia, przykłady, konkrety, bezpośredniość, no rewelacja. Dużo ciekawiej się mi Pana Jarka słucha niż czyta 😛 Pozdrawiam Was wszystkich serdecznie! Te wszystkie powyższe uwagi to już czepialstwo, bo było serio cudownie ^^ DZIĘKUJE!!
• Dużo przydatnych wniosków z doświadczenia, jednak nie podobała mi się rozwiązłość prelekcji i zbyt wiele (choć ciekawych) dygresji
• To jest hit, jak będę duży chciałbym być Jarkiem. Konkret zarówno jeśli chodzi o narzędzia, jak i podejście do produktu.
• Za mało czasu dla Jarka – ale prezentacja była na prawdę świetna…
• Powinno być więcej czasu zarezerwowane na taki wykład. Był bardzo ciekawy i szkoda, że musiał zostać skrócony. Chętnie wysłuchałabym tej prezentacji z większymi szczegółami.
• Trochę za szybko, ale podkreślenie ważnych punktów dokumentacji analitycznej. Podpowiedź związana z narzędziem do dokumentacji.
• Tak na przekór wszystkim, fajnie pomyślana – brakło trochę… slajdów!
• W prezentacji było kilka ciekawych momentów oraz sporo wiedzy analitycznej, niestety nie odpowiadała mi forma. Pan Jarek za szybko mówił, bardzo chaotycznie przez co bardzo szybko można było zgubić wątek.
• Trzeźwe spojrzenie na proces wytwórczy oprogramowania.
• Za mało czasu – ta prezentacja powinna trwać zdecydowanie dłużej
• n/d
• Za mało czasu i za szybko, lepiej byłoby godzinę – bo bardzo ciekawe i świetnie opowiedziane
• Nie widziałam, bardzo żałuję!
• No cóż. Klasa.
• Po prostu WOW. Nic dodac nic ująć 🙂
• + przykłady z życia – za mało czasu na dokładniejsze omówienie
• Zwięzłe i na temat. Lubie bezpośredniość i szczerość. W tej prezentacji to bylo. Bardzo na plus
• Idealne zakończenie ciekawej konferencji, oby takich więcej
• Fajnie jakby Jarek zapoznał odbiorców z planem wystąpienia.
• Przydatne informacje,wiedza praktyczna
• Widać że prowadzący poświęcił zdecydowanie mniej czasu na przygotowanie się, niż inni (do czego z resztą sam się przyznał). Dużo śmiesznych uwag i być może cennych anegdot, ale przekazanych w sposób chaotyczny.
• Duża wiedz, ale trochę brakowało wprowadzenia, przez pierwszą część nie do końca było wiadomo, co prelekcja chce pokazać, trochę chaotyczna.
• Merytorycznie 6, sam konkret i praktyczna wiedza. Nie trafia jednak do mnie kompletnie całe “show” wokół i robienie z siebie na siłę kogoś niechcianego w środowisku. Średnia wychodzi 3,5, ale jednak merytoryka jest ważniejsza, więc 4 🙂
• Widziałem 3 min, bez audio, old school analiza w czystej postaci 😉
• Ten Pan mógłby opowiadać 3h a nie 30 min i też by się dobrze słuchało.
• Poglądy Jarka pozostają w asymetrii do wcześniejszych prezentacji, ale jego charyzma i zaangażowanie robi wrażenie, a przedstawione przykłady z projektów dają do myślenia.
• Temat spoko, ale dla mnie forma trochę jednak nie dostosowana do ilości czasu. Poczucie humoru nie moje ale wiedzę doceniam:)
• Podobało się wszystko. Szkoda że tak krótko I prowadzący się mocno spieszyl
• Brak
• Niestety nie moglam byc do konca
• Było super
• Stereotypy, mnóstwo utrwalonych stereotypów, m.in. programisty-klikacza i inne. 🙁
• Podobało mi się praktyczne podejście, wiedza i przygotowanie prowadzącego. Zdecydowanie za mało czasu.
• Ogromna wiedza, tylko za dużo nieczytelnej grafiki w prezentacji
• nie oglądałem
• Super że dostajemy punkt widzenia zupełnie przeciwny do całej reszty prelegentów 🙂 Nie do końca się zgadzam (ale też nie do końca się zgadzam z Michałem R.), ale świetnie jest takiej wizji posłuchać.
• Jarek jest mistrzem sam w sobie. Ma ogrom wiedzy praktycznej, więc można by słuchać go godzinami… w kontekście 30 minutowego wykładu, który powinien pokazać jak wymagania biznesowe architektura i logika aplikacji, ciężko powiedzieć że to się udało. Prezentacja nie pozwalała na przeprowadzenie słuchających przez ten proces, bo nie było jednego przykładu. Jarek mówiąc szukał w prezentacji odpowiednich slajdów i szybko je omawiał, co prowadzało chaos. Pokazany diagram sekwencji był na ekranie 3 sekundy, więc nawet nie zdążyłam zobaczyć co zawiera. Na taką konferencję, zdecydowanie lepszym pomysłem byłby prosty przykład i kilka slajdów, które przeprowadzą przez ten proces.
• REWELACJA 🙂
• Konkretna, praktyczna prezentacja, uświadamiająca analitykowi-odbiorcy, jakich dotychczas popełnianych w pracy błędów należy unikać.
• za dużo tematów Jarek chciał poruszyć. Powinien się skupić albo na swojej filozofi prowadzenia projektów, albo na dokumentacji