Wprowadzenie

Zarówno w projektach jak i w dyskusjach np. na konferencjach czy na LinkedIn, pojawia się stale pewne nieporozumienie: “projektowanie to waterfall”. Myśli tak każdy, kto wyobraża sobie, że projekt czegoś to jakaś masa wszystkich możliwych detali. Jednocześnie nie ja jeden widuję “Dokumenty analizy biznesowej” albo “Dokumenty wymagań” zawierające setki pozycji o treści “system powinien…”, nie raz wykonane przez krytyków “water fall”, którzy reprezentując developera deklarującego metody “agile”, “zabezpieczają się” przez odpowiedzialnością za zakres projektu.

Pierwsza ważna uwaga: projekt systemu to nie jest ani zestaw dziesiątków “user story” ani detaliczna dokumentacja powykonawcza! I o tym dzisiaj będzie: abstrahowanie od detali i jednak nadal zarządzanie logiką całości.

Poniżej wymaganie napisane przez dział IT jednego z moich klientów:

Inna osoba z tego samego działu dodała:

Świadomie podaje źródło: dział IT tej instytucji.

Opublikowałem tylko powyższe, bo reszta po anonimizacji i tak była by pustą kartką (niestety ten OPZ ukaże się dopiero za jakiś czas, a do tego momentu jest poufny), ale mam nadzieję, że wyobrażenie sobie reszty jest dość proste. I co z tym? Nic! Otóż nie jest problemem taka forma wyrażenia wymagań przez Zamawiającego, bo on (biznes i nie tylko jak widać) inaczej nie potrafi i nie jest to jego rola. Problemem jest uznanie tego za “wymagania wobec oprogramowania”. Powyższe jest raczej dopiero materiałem do analizy i projektowania.

Wyobraźmy sobie teraz hipotetyczny dokument wynikowy, czyli kilkunastu (a może nawet kilkudziesięciu) nietechnicznych pracowników tej instytucji (księgowość, administracja, itp.) z pomocą “analityka wymagań”, zebrało wymagania, i pracując z edytorem tekstu w trybie rejestracji zmian, warsztatowo, po iluś tam tygodniach “wypracowało” ostateczną wersję “wymagań” a potem nawet dziesiątki “user story”. Ile stron będzie miała taka Analiza Biznesowa Wymagań i co w niej będzie?

Przykłady łatwo znaleźć w Internecie:

przykład 1 (źr. :

Powyższe opracowanie kosztowało 90 tys. zł.

przykład 2 (źr. https://platformazakupowa.pl/transakcja/361167):

Rozwiązanie

Od czasu do czasu przywołuje tu na blogu podejście zwane “Model jako wymaganie” (popularne skróty to: MDD – Model Driven Development, MBSE – Model Based System Engineering, MDSE – Model Driven System Engineering, o MBSE już pisałem ).

Kluczem są modele struktur treści (dokumentów i ekranów GUI) . Powyższe “życzenia” jako spisane wymagania to (w pełnej wersji) ogromna lista życzeń, nie poddająca się żadnej kontroli spójności i kompletności. Proszę podejrzeć wskazane wyżej przykłady, dokumenty na ponad 200 stron nie poddające się żadnej kontroli… (pomijam, że wadliwe formalnie, jeśli chodzi o użycie dekarowanej notacji).

Poniżej zamiennik wyłącznie powyższego o poczcie elektronicznej, wyrażony modelem struktury treści. Jaką ma to zaletę? Tę, że mamy zamkniętą strukturę treści i możemy ją mapować na inne dokumenty (ich szablony w projekcie) w celi weryfikacji logiki spójności.

Zakresy danych nie realizujące logiki biznesowej (i mało ryzykowne jeśli chodzi o pracochłonność) można markować z dokładnością do roli danego zestawu danych (poniżej obszary oznaczone linia przerywaną). Zgodnie z definicją, systemy informacyjne przetwarzają dane, więc dowolny system informacyjny jest sprowadzalny do skończonej liczby informacji wyrażanej jako dokument grupujący określone dane i reguł ich przetwarzania . Rzecz w tym, że nie jest to “baza danych i relacyjny model” (niestety monolit możliwy do wypracowania metodą waterfall), a odrębne dokumenty i ich struktury (oraz słowniki znaczeń użytych nazw). Każdy z nich może być podstawą opracowania odrębnego, możliwego do samodzielnego wykonania, modułu.

Warto wiedzieć, że:

Model rela­cyj­ny danych: zapi­sy­wa­nie ich w posta­ci współ­dzie­lo­nych znor­ma­li­zo­wa­nych struk­tur poję­cio­wych, pozba­wio­nych redun­dan­cji, jest pozba­wio­ny kon­tek­stu , nie spraw­dza się w sys­te­mach zarzą­dza­ją­cych doku­men­ta­mi. Dokument, tak­że w sen­sie praw­nym, nie może być gene­ro­wa­ną dyna­micz­nie (zapy­ta­nia SQL do bazy rela­cyj­nej) struk­tu­rą, bo jest wte­dy wir­tu­al­nym bytem, a taki nie sta­no­wi doku­men­tu w pra­wie (Kodeks Cywilny), nie da się tak­że zarzą­dzać jego cyklem życia. Dlatego doku­men­ty są coraz czę­ściej wyra­ża­ne jako struk­tu­ry XML/XSD i uzu­peł­nia­ne posta­cią ??do czy­ta­nia i dru­ku? w for­ma­cie pdf (real­nie sa to pli­ki pdf z załą­czo­ny­mi wer­sja­mi XML. (źr. Informacje dla korzystających z moich opracowań – Jarosław Żeliński IT-Consulting – Systemy Informacyjne)

Poniżej prosty model “listy odebranych maili”:

Wymagania dotyczące pracy z poczta elektroniczną obrazuje ten oto – weryfikowalny – model struktury treści otrzymanej mailem:

Aby pokazać “jak to działa” piszemy scenariusz (specyfikacja przypadku użycia) stanowiący kontekst użycia tego dokumentu (formularza). Służy on także jako test projektowanej logiki, a później jako test odbiorczy gotowego produktu:

W tym momencie będę kończył, bo kontynuację czytelnik znajdzie w jednym z wcześniejszych artykułów, fragment poniżej:

Pełna doku­men­ta­cja powin­na zawie­rać w załą­cze­niu deta­licz­ne struk­tu­ry tych for­mu­la­rzy (dia­gra­my przed­sta­wia­ją­ce struk­tu­ry XML, lub sko­men­to­wa­ne mock-up?y doku­men­tów). Taka spe­cy­fi­ka­cja zawie­ra wszyst­kie infor­ma­cje pozwa­la­ją­ce deve­lo­pe­ro­wi stwo­rzyć opro­gra­mo­wa­nie słu­żą­ce do zbie­ra­nia i zarzą­dza­nia infor­ma­cją. Jako model wyma­gań na sys­te­my typu EOD jest wystarczająca. Gdyby było praw­dą, że wyma­ga­my od opro­gra­mo­wa­nia tak­że, by zawar­tość wybra­nych pól tych for­mu­la­rzy była wyli­cza­na lub wery­fi­ko­wa­na, musi­my dodat­ko­wo udo­ku­men­to­wać  zależ­no­ści mię­dzy tymi pola­mi. Model taki czę­sto war­to uzu­peł­nić wyma­ga­ną archi­tek­tu­rą opro­gra­mo­wa­nia, bo od niej zale­żą cechy jako­ścio­we apli­ka­cji, tak zwa­ne poza­funk­cjo­nal­ne. Będzie to wła­śnie  model dzie­dzi­ny sys­te­mu, opi­sy­wa­ny na moim blo­gu wielokrotnie. (źr. Modele informacyjne – Jarosław Żeliński IT-Consulting – Systemy Informacyjne).

Źródła