Siedem lat temu (2015) artykuł o wymaganiach i śladowaniu kończyłem słowami:
Tak więc wymagań biznesowych może być kilkadziesiąt. Wymaganych usług systemu (przypadków użycia) w dużym projekcie także może być kilkadziesiąt. Ale setki, czy tysiące ??wymagań? to wyraz utraty panowania nad zakresem projektu? Tu zwrócę uwagę, że wymaganiem (usługa systemu) może być np. wytworzona faktura VAT zgodna z przepisami. Cechy tej faktury (lista pól) to nie osobne wymagania, to cechy (parametry, atrybuty) jednego wymagania. Żadna cecha faktury VAT nie ma sama w pojedynkę żadnej wartości, nie może więc być oddzielnym przypadkiem użycia, tak samo jak wymaganiem naszym może być samochód, ale jego kolor czy automatyczna skrzynia biegów, to cechy samochodu, nie ma sensu wymagać ??czerwonego koloru? nie oczekując samochodu (i jak uzasadnić, to że ten kolor wspiera cel biznesowy). Przypadkiem użycia samochodu jest podróż a nie włożenie kluczyka do stacyjki, bo to jest tylko jeden z elementów scenariusza rozpoczęcia podróży samochodem.
Nadal pojawiają się publikacje o wymaganiach, zarządzaniu nimi i realizowaniu ich. Na rynku są dostępne aplikacje pozwalające je kolekcjonować i zarządzać taką kolekcją. I stale mamy do czynienia z ich – wymagań – niejednoznacznością [zotpressInText item=”{5085975:LXK8VA68}”]. Okazuje się, że ich znaczenie staje sie kluczowe dla projektów, także z perspektywy prawa (PZP i zdefiniowane w zaleceniach UZP pojęcie potrzeba). Tym razem skupię się na pojęciach ‘wymaganie’ i ‘potrzeba’ w odniesieniu do projektu rozwiązania.
Robię to zawsze a najrzadziej o tym pisze, bo to “takie oczywiste”, a co to takiego? TESTY. Dobrze opracowane testy to ciekawa i wyrafinowana forma sprawdzania tego czy dostajemy to co chcemy dostać, to za co płacimy (nie raz słono). Czym są (powinny być) kryteria akceptacji? To właśnie wymagania, pozostaje pytanie: Które? Jeżeli to będą pierwotne wymagania biznesowe jest źle (patrz: Przypadki użycia to nie wymagania). Wiec co? Wymaganiem jest model: zamawiana konstrukcja, mechanizm działania.
V-model czyli wprowadzenie
Ogólnym, najczęściej przytaczanym modelem opisującym cykl wytwarzania w inżynierii jest tak zwany V-model, prezentowany w poniższej ogólnej postaci:
[zotpressInText item=”{5085975:FX2IEJA2}”]
V-model składa się z części: projektowanie, implementacja, testowanie, powtórzenie tego cyklu to rozwój (testy to kryteria akceptacji). Model ten stanowi fundament rozważań o testach, gdyż test to sprawdzenie, a sprawdzenie polega na porównaniu z wzorcem. Co jest wzorcem? Obietnica. A co jest tą obietnicą? Model tego co ma (miało) powstać.
Ważne pytanie: Czym jest inżynieria?
Engineering is the designing, testing and building of machines, structures and processes using maths and science. [Inżynieria to projektowanie, testowanie i budowanie maszyn, struktur i procesów przy użyciu matematyki i nauki.]
Tak więc mówimy o projektowaniu. Na etapie prac inżynierskich powstają: koncepcja i zakres produktu (Concept of Operations), następnie wymagania (Requirements and Architecture) i w końcu projekt (Detailed Design). Kolejny etap to implementacja czyli proces opracowania technologii wykonania i wykonanie produktu (produktem nazywamy przedmiot jaki ma powstać). Powyższe dotyczy każdego produktu inżynierii.
Powstaje więc często pytanie: Czy to co nam dostarczono jest tym co chcieliśmy dostać?
Przedmiot testowania a podmiot testujący
Kluczowe pojęcia w tym wpisie (źr.: sł. j. polskiego PWN):
test: próba, której poddaje się urządzenie, produkt, preparat itp. w celu sprawdzenia jego składu, właściwości i działania; też: to, co służy do przeprowadzenia takiej próbyscenariusz: zaplanowany lub przewidywany rozwój wydarzeń
przedmiot: rzecz, materialny element świata
podmiot:
1. ?nadrzędna część zdania nazywająca osobę, rzecz lub zjawisko, o którym się w zdaniu orzeka?
2. ?osoba aktywna, uczestnicząca w czymś?
3. filoz. ?umysł poznawczy w przeciwieństwie do przedmiotu, który jest poznawany?
4. ?osoba fizyczna lub prawna mogąca mieć prawa i obowiązki?
projekt:
1. ?plan działania?
2. ?wstępna wersja czegoś?
3. ?dokument zawierający obliczenia, rysunki itp. dotyczące wykonania jakiegoś obiektu lub urządzenia?
komputer: ?urządzenie elektroniczne automatycznie przetwarzające dane zapisane cyfrowo, służące do szybkiego wykonywania obliczeń, przechowywania, porządkowania i wyszukiwania danych oraz sterowania pracą innych urządzeń? (definicja sprawozdawcza)
komputer: urządzenie zawierające procesor, pamięć i program (definicja realna)
mechanizm:
1. ?zespół współpracujących ze sobą części maszyny lub przyrządu, wykonujących jakąś pracę?
2. ?sposób, w jaki coś powstaje, przebiega lub działa?
wymaganie: ?warunek lub zespół warunków, którym ktoś lub coś musi odpowiadać?
Pojęcia wieloznaczne zostały pozostawione z definicjami używanymi w dziedzinie inżynierii. Dla lepszego zrozumienia i zarazem przetestowania spójności tego zestawu pojęć, tworzymy model pojęciowy w postaci diagramu opisującego pojęcia i związki między nimi (ontologia wyrażona graficznie):
Model pojęciowy zobrazowany jako diagram faktów notacji SBVR
Model pojęciowy jak ten powyżej, to test jednoznaczności zdań budowanych z pojęć, których spójność, kompletność i niesprzeczność chcemy wykazać. Każda para pojęć połączonych predykatem powinna tworzyć zdanie prawdziwe w analizowanej dziedzinie (taki model powinna zawierać każda analiza biznesowa i specyfikacja wymagań!)
Tak więc przedmiotem testowania jest komputer, a nie – jak sie potocznie mówi – oprogramowanie. Oprogramowanie to tekst (zestaw instrukcji dla procesora), który umieszczony w pamięci komputera, intepretowany przez procesor jako program do wykonania. To z czego korzystamy to urządzenie jakim jest komputer, ten zaś jako całość realizuje określony mechanizm (patrz artykuł Prawo autorskie w projektach IT). Nawet siedząc i czytając ten artykuł korzystasz czytelniku z komputera a nie z “oprogramowania”. Dlatego w nauce (tu information science) mówi się, że komputer to ‘uniwersalny mechanizm’ [zotpressInText item=”{5085975:ZCXJ2S7U}”].
Badanym (testowanym) przedmiotem jest więc komputer (ten zawiera oprogramowanie), który musi spełniać wymagania, a wymaganiem jest projekt mechanizmu jaki realizuje. Dlaczego wymaganiem jest projekt a nie “wymagania”? Bo V-model to także pętla zarządzania jakością, tę pętlę zamyka “strzałka w lewo”: weryfikacja i walidacja. Jest to tak zwana Pętla Cyklu Życia Oprogramowania (ang. SDLC):
Pętla SDLC (źr.:
Z perspektywy inżynierii Zamawiający (podmiot) zamawia produkt (przedmiot). Aby wyrazić to co zamawia, musi określić swoje wymagania. Wymagania można określić na trzy typowe sposoby:
potrzeba (chce przedmiot który pomoże mi w…., posłuży do…)
warunki (przedmiot powinien mieć wymagane cechy:…)
projekt (to jest opis tego jak jest zbudowany i jak ma działać przedmiot, czasami można użyć analogii: chce coś takiego jak …)
Powyższe to nic innego jak lewa strona V-modelu: to są wzorce, a testowanie to ocena zgodności tego co powstało z wzorcem tego co miało powstać, czyli z tym co zaprojektowano (z projektem). Te trzy etapy są zgodne z MDA: analiza biznesowa (CIM, Computation Independent Model), określenie zakresu produktu (przypadki użycia), opracowanie mechanizmu działania (PIM, Platform Independent Model). Model PSM (Platform Specific Model) jest pierwszym etapem implementacji [zotpressInText item=”{5085975:FX3SVDIW}”].
W projektach z zakresu inżynierii oprogramowania V-model jest często przedstawiany jak poniżej:
[zotpressInText item=”{5085975:YUDAGL8K}”]
A jak to widzi i czuje w kieszeni klient
Bo pytanie brzmi: kto, co i kiedy, tak na prawdę testuje. Popatrzmy na to od końca, czyli od momentu gdy dostajemy gotowy produkt: 1. Dostawca oprogramowania udziela rękojmi (musi zgodnie z prawem) 2. Dostawca oprogramowania może udzielić gwarancji 3. Zamawiający oczekuje oprogramowania zgodnie z zamówieniem 4. W dniu odbioru Zamawiający dokonuje podstawowego przeglądu na zgodność z zamówieniem (taka jazda próbna przy odbiorze samochodu), podstawą odbioru jest LISTA POTRZEB. 5. Z uwagi na złożoność oprogramowania (podobnie jak i samochodu) w okresie rękojmi (i gwarancji) wady mozna zgłaszać do dostawcy przez ustalony okres czasu od dnia odbioru, tu podstawą zgłaszania wad jest dokumentacja opisująca mechanizmy i algorytmy działania (czyli co i jak powinno zostać policzone i jaki powinien pokazać się wynik). 6. Po zakończeniu okresu rękojmi i gwarancji przechodzimy do fazy utrzymania i rozwoju na własny koszt (dlatego tak ważne jest zabezpieczenie przed zjawiskiem zwanym vendor lock-in!).
Od góry (przytaczam ponownie V-model po prawej):
Po dokonaniu odbioru i przejścia do fazy eksploatacji systemu, weryfikowana jest (przez życie) koncepcja i cele wdrożenia.
Na etapie odbioru systemu weryfikujemy zgodność z wymaganiami i architekturą HLD
Na etapie wytwarzania weryfikujemy wewnętrzną spójność i poprawność działania.
Etap implementacji to cała praca nad doborem technologii, konfiguracją środowiska i napisaniem brakującego kodu (wbrew proporcjom na diagramie, jest to najkosztowniejsza część projektu).
Rękojmia i gwarancja to usuwanie wad i niezgodności odpowiednio na koszt dostawcy i producenta, po dokonaniu odbioru. Sam odbiór to testy zgodności: czego i z czym? I teraz pytanie do Zamawiającego: a. czy masz aktualną dla projektu listę potrzeb i kto jej jej autorem? b. czy masz dokumentacją mechanizmu działania aplikacji i kto jest jej autorem? c. kto ma prawa majątkowe do tych dokumentów?
Testy odbiorcze to scenariusze. kto je opracował? Sprawdzany czy sprawdzający? Czy wiesz więc za co płacisz? Czy jesteś pewien że treści i liczby na generowanych z systemu dokumentach są poprawne? Czy może czytelniku dałeś sobie wmówić, że jedyna prawdziwa dokumentacja oprogramowania to działający kod? A czy TY jesteś w stanie z takiej “dokumentacji” skorzystać? Więc za co Wy płacicie? Za to, że kazali Wam zapłacić?
Kilka słów o mechanizmie
Przypomnijmy definciję:
mechanizm: 1. ?zespół współpracujących ze sobą części maszyny lub przyrządu, wykonujących jakąś pracę? 2. ?sposób, w jaki coś powstaje, przebiega lub działa?
Innymi słowy, jeżeli chcemy świadomie uzyskać określony efekt, to musimy określić mechanizm jego powstawania. Model-based System Engineering (MBSE) to metodyka podejścia do projektowania i inżynierii oparta na modelowaniu [zotpressInText item=”{5085975:RA6YBH48}”]. Poniżej często przytaczany model obrazujący związek wymagań z mechanizmem (modelem) działania systemu:
[zotpressInText item=”{5085975:6LB9NWB7}”]
Mamy trzy ściśle powiązane perspektywy: wymagania, struktura (architektura) systemu oraz jego zachowanie. Jeżeli wyrazimy je jako modele, to powstaną trzy ścisłe z soba powiązane: model wymagań, model struktury i model zachowania. W przypadku inżynierii systemów stosujemy od lat notację SysML (jest to specjalny profil notacji UML). Te trzy modele muszą być spójne, kompletne i niesprzeczne, bez czego system, jaki na ich podstawie powstanie, będzie wykazywał błędy. Dlatego tak na prawdę model systemu to te trzy modele i ich TESTY w postaci macierzy zgodności (chodzi o kontrole tych czarnych punktów na diagramie powyżej) [zotpressInText item=”{5085975:63PW4WQU}”].
Po co nam model na etapie wymagań? Same wymagania to tak zwany opis “czarnej skrzynki”: wiemy jaki efekt obserwujemy ale nie wiemy jak powstał. Czy to groźne? Bardzo, bo np. zegar jaki obserwujemy na pulpicie komputera to może być prosty mechanizm pokazujący zmieniające się co sekundę kolejne obrazy tarczy zegara (43.200 obrazów i prosty mechanizm ich kolejnego wyświetlania) lub model opisujący mechanizm pomiaru czasu i dynamicznego generowania obrazu pokazującego aktualną godzinę (patrz artykuł o zegarze: Model dziedziny jako mechanizm). Ten pierwszy będzie tanim w wykonaniu i koszmarnie kosztownym w utrzymaniu i rozwoju systemem, drugi – mimo kosztów projektowania – będzie niewiele droższy na etapie wykonania ale będzie o całe rzędy tańszy na etapie utrzymania i rozwoju. Proste testy odbioru “czarnej skrzynki” niczego złego nie pokażą, system zostanie odebrany. Gehenna zacznie się przy próbie pierwszej zmiany np. koloru tarczy… Dlatego MBSE to podejście nazywane często: “projekt systemu jako wymaganie” (pamiętamy żarty o maszynie do obierania ziemniaków, w której był zamknięty człowiek).
Podsumowanie
Testy to sprawdzenie, a tu mamy (powinniśmy mieć) jasny podział na sprawdzającego i sprawdzanego. Typowe dla rynku IT jest wmawianie klientom, że nie mają żadnych kompetencji do analiz, testów, projektowania, że wszystko to zrobi dostawca oprogramowania. Tak więc u tego samego, jednego, dostawcy oprogramowania zamawiana jest: analiza biznesowa, analizy wymagań, projektowanie, implementacja, pisanie testów odbiorczych i testy. Podmiot jakim jest Zamawiający w zasadzie tylko patrzy, i płaci tyle ile chcą dostawcy (projekty T&M to brak kontroli). W efekcie sprawdzający i sprawdzany to ten sam podmiot. Czy to ma sens?
Ostatecznym testem jest to “jak to wszystko działa w praktyce” czyli średnio i długo terminowe efekty wdrożenia. To zaś zależy od dwóch kluczowych rzeczy:
pierwotnej koncepcji biznesowej: wpływ wdrożonego oprogramowania na biznes, oraz
wewnętrznej architektury oprogramowania: wpływ na koszty utrzymania i rozwoju.
Oba powyższe elementy to lewa strona V-modelu. Biorąc pod uwagę fakt, że koszty utrzymania i rozwoju to konsekwencja wewnętrznej architektury, dostawcy systemów bardzo często forsują rezygnacje z rękojmi i gwarancji (wtedy nie ponoszą finansowych skutków niskiej jakości projektu i implementacji). Co to znaczy? Że jeżeli mamy mieć faktyczny podział na sprawdzającego i sprawdzanego, analiza i projektowanie powinna mieć miejsce po stronie Zamawiającego przed wyborem dostawcy. Jak? Po prostu zatrudnić inżyniera do analiz i projektowania oraz do nadzoru, bo praktyka pokazuje, że wtedy może być znacznie szybciej i nawet 10-krotnie taniej.
A teraz pytanie: co i jak testować gdy skastomizujesz kupiony duży gotowy system z tysiącem tabel w bazie danych? Pamiętaj też, że kastomizacja kodu to utrata gwarancji producenta.
Normy ISO, bo o nich będę tu pisał, to przedmiot wielu kontrowersji: zwolennicy i audytorzy namawiają, reszta zaleca rozwagę.
Czym są Normy
W kontekście norm ISO, słownikowa definicja normy brzmi:
norma ?ustalona, ogólnie przyjęta zasada?
(https://sjp.pwn.pl/szukaj/norma.html)
Normami nazywamy także zbiory zasad. Dla porządku będę używał słowa norma pisanego z małej litery w ogólnym słownikowym znaczeniu (zasada), oraz w formie Norma, pisanego z dużej litery, w rozumieniu tekstu (produktu) komitetu normalizacyjnego.
Generalnie stosowanie Norm jest dobrowolne:
CZY STOSOWANIE NORM JEST OBOWIĄZKOWE? Nie. Od 1 stycznia 2003 r. nowa Ustawa o normalizacji zniosła obligatoryjność norm i stosowanie Polskich Norm zgodnie z art. 5 ust. 3 ustawy jest już całkowicie dobrowolne.
Tu jednak ważna uwaga: Norma, jako zbiór zasad, to także tak zwana definicja atrybutowa [zotpressInText item=”{5085975:6LD24N2L}”]. Innymi słowy, stosowanie normy nie jest obowiązkowe a dobrowolne, jednak (dobrowolna) deklaracja wdrożenia określonej Normy to już obowiązek zachowania zgodności z nią. Np. dobrowolne nazwanie produkowanego swojego produktu “kabanosem” stanowi obowiązek wytwarzania go zgodnie z normą (PN-A-82024, patrz uzasadnienie https://www.sejm.gov.pl/sejm7.nsf/InterpelacjaTresc.xsp?key=3261FC15). Innymi słowy zgodność z Normą jest dobrowolna ale całkowita albo żadna.
Normy powstają jako wynik prac wielu ekspertów dziedzinowych, stanowią zbiór wskazówek i dobrych praktyk. Jako teksty (ich struktura i zawartość) nie są to jednak publikacje naukowe (te zawierają uzasadnienie, normy nie uzasadniają swojej treści). Normy więc, to zalecenia na mocy autorytetu (dowód z autorytetu). Jest to ich poważana wada, bo forsowane są jako dogmaty (Norma, jej treść jako zalecenie jest dobra, bo tak uważa zespół ekspertów).
Niewątpliwie, jako zebrany dorobek niemałej grupy doświadczonych ludzi, Normy mają ogromną wartość, jednak są aż i tylko eksperckim zaleceniem. Niewątpliwą zaletą norm jest standaryzacja, czyli zapewnienie, że jak się coś “tak nazywa” to “to jest to coś” (patrz pojęcia i ich definicje atrybutowe oraz słownik j. polskiego: standaryzacja ?wprowadzenie jednolitych norm, zwłaszcza w przemyśle?).
Standaryzacja, podobnie jak stosowanie prawa, to przede wszystkim przewidywalność. Użycie nazwy Normy w stosunku do czegoś (coś jest zgodne z Normą, nie należy mówić “spełnia normę”) to stwierdzenie mówiące, że coś spełnia określoną listę warunków. Jak ktoś zadeklaruje, że postępuje zgodnie z określoną Normą to można uznać, że postępuje zgodnie z zawartymi w niej regułami. I tu pojawia się pojęcie “deklaruje”, czyli jest to obietnica. Owszem mamy system certyfikacji, ale certyfikat to “zdjęcie” wykonane w dniu certyfikacji. Dlatego ocena organizacji na podstawie certyfikatu to troszkę tak, jakby umówić się z kimś na randkę w grudniu na podstawie zdjęcia ze stycznia: ryzyko musimy ocenić sami.
Podsumowując, można powiedzieć, że Norma jako treść, jest dokumentem opisującym określony standard postępowania w prowadzonej działalności usługowej, technologicznej, badawczej. Jest dokumentem powszechnie dostępnym. Często mówi się, że Normy opierają się na podstawach naukowych. Uważam jednak, że skoro treść Norm jest dogmatem, to w moich oczach teza o ich naukowości jest nieuprawniona. Uważam, że uczciwie należy poprzestać na tym, że są one oparte na danych sprawdzonych pod względem słuszności technicznej, ekonomicznej i użytkowej. Z zasady Normy powinny uwzględniać aktualny stan wiedzy, czy tak jest zawsze? Norma zostaje przyjęta na zasadzie konsensusu (czyli przez aklamację) i akceptowana jest przez uznane jednostki normalizacyjne. Robi się to jednak kilka lat.
Najważniejsze jest tu to, że ich respektowanie ma charakter dobrowolny.
Czy warto wdrażać normy
To pytanie zadaje mi prawie każdy klient. Odpowiedź, moim zdaniem, nie jest tak prosta jak uważają firmy je wdrażające i audytorskie oraz komitety normalizacyjne (od momentu komercjalizacji Norm, podmioty te – wygłaszając takie opinie – mają tu konflikt interesu).
Normy mają obecnie także charakter marketingowy, tak jak certyfikaty umiejętności: “masz certyfikat więc robisz to dobrze”, rzecz w tym, że to teza podobna do: “masz prawo jazdy więc jeździsz zgodnie z Kodeksem Ruchu Drogowego”. Jak to wygląda na rynku? Takie ogłoszenia nie są rzadkością:
Potrzebujesz certyfikatu dla celów przetargowych lub kontraktowych? Z naszą pomocą uzyskasz certyfikat systemu zarządzania ISO 9001.
(celowo nie podaje źródła by nie promować tej firmy, google pomoże)
Jeżeli jakiś podmiot uzyskuje certyfikat zgodności z jakąś Normą, nie z powodów własnego przekonania do niego, a z powodu samej chęci “posiadania papieru”, to zdobędzie go ale to, czy jako podmiot, (zawsze) spełnia wymagania Normy, pozostaje dużym znakiem zapytania.
Jak już wyżej wspomniałem, certyfikacja to zdjęcie na moment certyfikowania i warto o tym nie zapominać. Czy to znaczy, że podmioty certyfikowane na co dzień nie spełniają tych Norm? Absolutnie nie. To znaczy tylko tyle, że wiedzą jak je spełnić, nie ma jednak gwarancji, że spełniają. Pamiętajmy także, że certyfikacja jest skuteczna tak samo jak zapowiedziana kontrola. I to co tu teraz napisałem nie jest żadną tajemnicą tak jak to, że każdy posiadacz prawa jazdy wie z jaką prędkością ma jeździć, i że nie każdy tego przestrzega (pamiętajmy, że egzamin na prawo jazdy to to samo co audyt zgodności z Normą).
Jak widać nie jest prawdą, że certyfikat przyznany jakiejś firmie cokolwiek gwarantuje. Poniżej dane na temat liczby wydawanych certyfikatów w różnych krajach:
Nie ma żadnej korelacji pomiędzy poziomem gospodarki danego kraju a liczbą wydanych w nim certyfikatów zgodności z Normami. Wartości dla Włoch i USA są chyba dostatecznym dowodem na brak tej korelacji (Chiny na tle liczby mieszkańców i firm, też nie wypadają imponująco).
Na tle tego wszystkiego ciekawą i słuszną moim zdaniem, opinię prezentują pracownicy Uniwersytetu Ekonomicznego w Krakowie na swoim portalu:
Ciągły postęp nauki i techniki powoduje, że normy opracowywane przez jednostki normalizacyjne dezaktualizują się lub zaczynają odstawać od wymagań praktyki. mimo iż standardy wprowadzają ład i porządek w gospodarce, nie powinny stanowić ograniczeń dla jej rozwoju.
Niewątpliwie Normy, jako uporządkowany dorobek wielu ludzi, stanowiący zbiór najlepszych praktyk, co ma ogromną wartość. Jednak bałwochwalcze podejście do nich wyrządziło wiele zła. Widać to było 20 lat temu, gdy pojawiła się “moda” na wdrażanie norm serii ISO9000 (zarządzanie jakością), a następnie kolejne firmy nie przedłużały certyfikacji nie widząc w tym żadnej wartości dla siebie. Po pewnym czasie ustabilizowała się sytuacja: część firm co roku przechodzi audyty i utrzymuje certyfikat, część tego nie robi, co jednak nie oznacza, że są gorsze. Warto też pamiętać, że w niektórych sektorach pewne certyfikaty są obowiązkiem (np. farmacja, żywność), ale tylko w niektórych.
Po pierwsze brak certyfikatu nie jest tożsame ze złą oceną. Po drugie zgodność z Normą to zero-jedynkowa ocena: zgodny – niezgodny. Przypominam, że Normy to definicje atrybutowe ustalone zbiorowo. Popatrzmy na sport: rekord świata w biegu na 100m to 10 sek. (dokładnie 9,58 sek.). Załóżmy, że wynik 11 sek. ustalimy jako Normę dla “dobrego sprintera”. Czy wynik 11,1 sek. czyni kogoś złym sprinterem? W świetle Norm, taki wynik mówi: “ten człowiek nie jest dobrym sprinterem” i w myśl tej Normy nie jest nim. Taka klasyfikacja to cecha stosowania definicji atrybutowych, i jest to dobra cecha systemu Norm (podobnie jest ze stosowaniem prawa): nie można być Dobrym Sprinterem “troszkę”. Pozostaje pytanie: czy człowiek z wynikiem >11 sek. jest gorszy? Nie, co najwyżej nie zaklasyfikuje się do składu drużyny olimpijskiej, ale czy musi?
Wiele firm ma w swojej strategii utrzymywanie wysokiej jakości, bezpieczeństwa itp.. Robi to jednak adekwatnie do swojej sytuacji i warunków. Korzystanie z Norm, jako zbioru najlepszych praktyk, jest bardzo dobrym pomysłem, podobnie jednak dobrym pomysłem jest pragmatyczna decyzja czy, w danej sytuacji, konieczne jest spełnienie wszystkich warunków danej Normy, czy może świadomie zrezygnujemy z jakiegoś “obowiązku”, bo może on nie mieć wartości w określonym produkcie, usłudze, czy w ogóle w firmie.
Np. zamki do drzwi maja kategorie bezpieczeństwa A, B i C (C najwyższa). Załóżmy, że mamy Normę opisującą warunki nadania certyfikatu “Bezpieczne mieszkanie”, wśród wielu ważnych i wartościowych zaleceń jest zastosowanie zamka kategorii C. Czy świadome zastosowanie zamka kategorii B (bo np. nie mamy w domu złota i diamentów) czyni to mieszkanie “niebezpiecznym”? Nie! To powoduje TYLKO to, że to mieszkanie nie spełnia TEJ Normy. No to jest bezpieczne czy nie? W warunkach świadomie (raport z audytu) określonych przez lokatora jest “wystraczająco bezpieczne”.
W tym miejscu moja sugestia:
przeprowadzić analizę procesów biznesowych organizacji,
na jej podstawie przeprowadzić jej ewentualną optymalizację,
zlecić audyt zgodności z wybraną Normą dziedzinową,
na podstawie wyników (raport z audytu):
zapoznać się z zasadami/warunkami, których organizacja nie spełnia,
dla każdego z nich wykonać analizę ryzyka jakie stwarza on dla organizacji,
podjąć decyzję czy podjąć działania by spełnić określony warunek,
po tych działach albo kwalifikujemy się na certyfikat albo nie, ale brak certyfikatu to świadoma decyzja.
Powyższe robię prawie u każdego klienta, który zleca mi analizę i modelowanie procesów biznesowych organizacji. Niejeden pragmatycznie decyduje, że uzyskany poziom jest wystarczający dla jego strategii. To, że nie dostał certyfikatu nie znaczy, że coś robi źle, to znaczy, że nie spełnia danej Normy, tak samo jak można być wystarczająco szybkim w swoim segmencie rynku, i nie być olimpijczykiem. Pamiętajmy, że kolejne wymagania to koszty, które powinny być adekwatne do uzyskanych korzyści. Stawianie sobie wymagań wyższych niż to konieczne jest złym pomysłem (wręcz rozrzutnością).
Zgodność z określoną Normą może być dla klientów zarówno zaletą jak i wadą organizacji, warto o tym pomyśleć.
Ronald Ross, współautor standardu modelowania reguł biznesowych i biznesowego słownika pojęć [zotpressInText item=”{5085975:HC624KKJ},{5085975:3QENML5V},{5085975:B7SVMTNQ}”] napisał niedawno na swoim profilu LinkedIn:
“People love stories. Are user stories helpful in engineering business solutions? Absolutely. Are you done with requirements and solution engineering when you?ve worked through a set of user stories? No. Not even close!” [“Ludzie kochają historie. Czy historie użytkowników są pomocne w tworzeniu rozwiązań biznesowych? Zdecydowanie tak. Czy skończyłeś z wymaganiami i inżynierią rozwiązania, gdy już opracowałeś zestaw historyjek użytkownika? Nie. Nawet nie zbliżyłeś się do nich!”.]
Świat od dekad boryka się z jakością i skutecznością specyfikowania wymagań na oprogramowanie. OMG.org opublikowało standard o nazwie MDA (ang. Model Driven Architecture [zotpressInText item=”{5085975:UWH8D5UI}”]), który tak opisuje proces tworzenia oprogramowania:
CIM -> PIM -> PSM
Są to odpowiednio modele: Model Biznesowy (CIM: Computation Independent Model), Model Mechanizmu działania (PIM: Platform-Independent Model, jest to model dziedziny systemu wg. MVC) oraz Model Implementacji (PSM: Platform-Specific Model). Swego czasu szerzej opisałem zależności między tymi modelami [zotpressInText item=”{5085975:TBT7B5D2}”] (czytaj więcej o MDA).
CIM to model działania organizacji: procesy biznesowe i ich produkty. Z uwagi na to, że obecnie już nie rodzą się projekty jednorazowej informatyzacji całości organizacji, pojawia się potrzeba określenia zakresu projektu, bo nie jest już nim cała organizacja. Model PIM to udokumentowany mechanizm działania systemu (oprogramowania), logika jego działania. Nie ma tu mowy o tym w jakiej technologii powstanie, bo z zasady mamy ich wiele do wyboru, a wybór technologii zależy od wielu poza-funkcjonalnych ograniczeń i wymagań. Technologia jest (powinna być) konsekwencją wyboru wykonawcy i ten dopiero opracuje model PSM, który w praktyce jest tak zwaną Koncepcją Wdrożenia, można ją także udokumentować w notacji UML, ale na tym etapie powszechna praktyką jest jedynie zaprojektowanie środowiska, zestawienie go i praca od razu w kodzie.
Kluczowym problemem jest przejście z CIM na PIM, czyli jak udokumentować zakres projektu dostarczenia oprogramowania i przekształcić go na wymagania wobec tego oprogramowania?
CIM -> [zakres projektu] -> PIM -> PSM
W metodach zwanych zwinnymi, modele CIM i PIM są pomijane. Typowym zaś narzędziem “zbierania wymagań” są tak zwane historyjki użytkownika (user story). Problem w tym, że są one kluczowym ryzykiem projektów gdyż z reguły są niespójne i niekompletne jako wymagania. Specyfikacja wymagań powinna być: spójna, kompletna i niesprzeczna. Opisanie zakresu projektu historyjkami użytkownika, nie mając modelu procesów biznesowych całości (model CIM), jest pozbawieniem się narzędzia do weryfikacji kompletności, spójności i niesprzeczności takiej specyfikacji. Wszystkie wady (niekompletność, niespójność, sprzeczności) odkrywane są i usuwane (uzupełniane) dopiero na etapie wdrażania. Jest to proces “odkrywania wymagań w toku wdrożenia”.
Historyjki użytkownika jako lista potrzeb biznesowych? Owszem! Historyjki użytkownika jako wymagania dla developera? NIE! To tylko materiał dla projektanta, ponieważ bardzo często jedna i ta sama funkcja systemu realizuje wiele różnych historii użytkownika. Implementacja “per user story” prowadzi do bardzo kosztownych i nieefektywnych rozwiązań (Opisywałem to na blogu: wpis projekt Biblioteka, dwie historyjki użytkownika: chciałbym wypożyczyć książkę oraz chciałbym zwrócić książkę są realizowane jedną usługą aplikacji: Karta Wypożyczenia, która zawiera również pole Data zwrotu. Nadal spotykam programistów przekonujących, że powinny to być dwa osobne ekrany – dwa przypadki użycia, czytaj dwa razy więcej pracy kodera i dwa razy większy koszt).
Czy można sformalizować proces zbierania historyjek użytkownika?
User Story to jedno z najbardziej problematycznych narzędzi w metodach zwinnych. Najczęściej zalecana struktura tych “historyjek”, wraz z przykładami:
“Jako ?typ użytkownika? chcę osiągnąć ?cel?, aby ?jakiś powód?”.
Na przykład:
“Jako Administrator chcę otrzymywać wiadomość e-mail, gdy zostanie przesłany formularz kontaktowy, abym mógł na niego odpowiedzieć”
albo
”Jako użytkownik mam możliwość kliknięcia określonej lokalizacji na mapie”;
[zotpressInText item=”{5085975:B7K58W5A}”]
Tak spisywane wymagania stanowią ogromny problem z powodu nierównej gradacji, sprowadzanie ich do poziomu tak zwanych atomowych user story (drugi z powyższych przykładów) prowadzi do bardzo dużych liczb tych historyjek. Próba ich weryfikacji (walidacja user story) staje się co najmniej trudnym zadaniem. Jakakolwiek wycena oprogramowania na bazie takich historyjek to wróżenie z fusów (więc developerzy mocno zawyżają wyceny z uwagi na ryzyko utraty rentowności). Autorzy innego opracowania zauważają:
Rzeczywiście, przy około 800 US [User Story], hierarchia była raczej trudna do określenia, a obraz systemu podczas planowania był bardzo duży. Skalowalność jest więc zdecydowanie problemem w projektach zwinnych, w których US są słabymi artefaktami inżynierii wymagań. Zdecydował się on [autor] na wprowadzenie wzorca US: “Jako [Użytkownik], chcę [Zadanie], aby [Cel]”, aby zdefiniować hierarchię w postaci Celu, Zadania i Użytkownika, ale bez powiązania semantycznego.
[zotpressInText item=”{5085975:F6WU4MAH}”]
Znam projekt, w którym liczba przypadków użycia, w pewnym średniej tylko wielkości projekcie, szybko sięgnęła czterystu. Wycena na ich podstawie pokazała, że planowany koszt wielokrotnie przekracza planowany budżet. Ten projekt zarzucono, jednak wiele tak wycenionych projektów jest realizowanych, co daje obraz skali strat jakie przynoszą (zawyżony koszt to strata). Powyżsi autorzy piszą na zakończenie:
Przyszłe prace obejmują identyfikację luk reprezentacyjnych, które napotykają praktycy w modelowaniu US, oraz przegląd sposobów, w jakie nasze ramy i [metoda] GORE w ogóle mogłyby rozwiązać te problemy. Równolegle oceniana będzie również zdolność praktyków do stosowania proponowanych ram zamiast zwykłych szablonów. Obecnie trwają prace nad narzędziem CASE (Computer Aided Software Engineering), które zostanie wykorzystane do wsparcia eksperymentów.
[zotpressInText item=”{5085975:F6WU4MAH}”]
Nie znalazłem wyników dalszych prac, więc podzielę się wynikami swoich.
Gradacja User Story
Podstawowym problemem z user story jest, moim zdaniem, brak standardu pozwalającego na zdefiniowanie “atomowej historyjki użytkownika” czyli poziomu, poniżej którego nie dzielimy ich na mniejsze. Jako audytor wielu dokumentacji (często w roli biegłego) zauważyłem, że historyjki użytkownika są doprowadzane do poziomu pojedynczych kroków scenariuszy przypadków użycia. Często też historyjki użytkownika utożsamiane są z przypadkami użycia (UML) i tak modelowane, co jest poważnym błędem. Np. powyższe:
“Jako użytkownik mam możliwość kliknięcia określonej lokalizacji na mapie”
Mogło by to być częścią scenariusza usługi (przypadek użycia UML), której celem jest Pokazanie Określonego Miejsca:
AKTOR inicjuje usługę Cel podróży
SYSTEM wyświetla formularz Adres
AKTOR wprowadza dane i naciska OK
SYSTEM wyświetla mapę z naniesioną lokalizacją
AKTOR klika określony punkt na mapie
SYSTEM powiększa obraz pokazując detale lokalizacji
Powyższa historyjka to jedynie punkt 5. tego scenariusza. Nie trudno dojść do wniosku, że samo kliknięcie na mapie to pozbawiona kontekstu i celu, wyrwana prosta czynność, i jej samodzielne istnienie w specyfikacji jako osobny byt, pozbawione jest sensu. Z perspektywy oprogramowania powstającego w określonym celu, uznanie tej historyjki za samodzielne wymaganie nie ma uzasadnienia. Uznanie jednak, że aplikacja służy między innymi do zapoznawania się określonymi miejscami w przestrzeni, a usługą tej aplikacji jest Pokazanie Określonego Miejsca jak najbardziej ma sens. Idąc za sugestią by historyjka użytkownika miała strukturę:
“Jako [Użytkownik], chcę [Zadanie], aby [Cel]”
zmusza do zastanowienia się czy klikanie na mapie jest celem, czy może jednak tym celem jest Pokazanie Określonego Miejsca, a klikanie jest elementem scenariusza (procedury) realizacji tego celu (pamiętamy, że przypadki użycia mają scenariusze, a te złożone są z sekwencji kolejnych kroków!).
Formalizacja User Story
Pojęcia Użytkownik, Zadanie, Cel, jako spójny zestaw pojęć odpowiadają definicji atomowego (elementarnego) procesu w notacji BPMN (dodatek C, Słownik , [zotpressInText item=”{5085975:QJUPRFNR}”]): Aktywność jest skojarzona z jej wykonawcą (pula, tor), tworzy produkt (data object). Biorąc pod uwagę fakt, że produkt ma tu określonego adresata i musi on stanowić sobą wartość dla tego adresata, mamy punkt wyznaczający granicę “dzielenia na części” tych historyjek. Nie będzie to “możliwość wstawienia z listy numeru NIP nabywcy” a “utworzenie faktury” (bo wartość ma dopiero poprawnie wystawiona faktura, a nie kliknięcie np. w pole NIP by wybrać kontrahenta).
Jak sformalizować historyjkę użytkownika? Podstawą formalizacji (i celem) jest opracowanie metody kontroli poprawności (walidacja). Popatrzmy jeszcze raz na szablon:
“Jako ?typ użytkownika? chcę osiągnąć ?cel?, aby ?jakiś powód?”.
Typ użytkownika to rola, celem jest produkt pracy, a powodem? Powodem jest zawsze to, że określona osoba oczekuje na efekt tej pracy (bez tego praca ta byłaby po prostu zbędna). Można więc wyobrazić sobie taki zapis:
Jako sprzedawca, chcę wystawić fakturę, klientowi.
Mamy tu:
rola: sprzedawca
cel: faktura
powód: oczekuje tego klient.
W tym miejscu widać pełną zgodność tej definicji z konstrukcją: aktywność, jej produkt, jego odbiorca. Innymi słowy analityczny model procesów biznesowych wykonany w notacji BPMN, to nic innego jak połączone w logiczne ciągi historyjki użytkownika.
Wyobraźmy sobie taką listę historyjek użytkownika, wykonaną wg. powyższego opisu:
Specyfikacja historyjek użytkownika
Niektóre narzędzia CASE, pozwalające na ich profilowanie, pozwalają przedstawić to także na modelu wymagań (co później umożliwia śladowanie, czyli kontrolę kompletności, spójności i niesprzeczności):
Diagram wymagań (notacja SysML)
Powyższe mogłoby być konsekwencją takiego modelu procesów:
Diagram procesu realizacji zamówienia (notacja BPMN).
Jak widać, model procesu daje pełny kontekst dla aktywności. Fakt, że proces to logiczny przepływ pracy, powoduje, że tworzenie modeli BPMN gwarantuje spójność, kompletność i niesprzeczność listy aktywności, ich produktów i ról.
Kilka słów o priorytetach
Często stosowane jest nadawanie wymaganiom priorytetów. Jeżeli mówimy o MBSE/MDD (odpowiednio: Model-Based System Engineering, Model-Driven Development), czyli podejściu w którym “model to wymaganie”, priorytety nie są stosowane, gdyż ma powstać to co zostało zaprojektowane (nikt nie nadaje priorytetów składnikom w recepturze na potrawę, nikt nie nadaje priorytetów na elementy składowe produkowanych przedmiotów).
Kiedy i jakim wymaganiom nadajemy priorytety? Ma to sens w przypadku wymagań biznesowych oraz w stosunku do przypadków użycia oprogramowania (przypominam, że Use Case w notacji UML to cecha systemu). Najczęściej spotykane systemu priorytetyzacji to trzystopniowa skala oraz tak zwana MoSCoW.
Trzystopniowa skala to:
niespełnienie tego wymagania pogorszy efektywność pracy
niespełnienie tego wymagania spowoduje ograniczenie funkcjonalności
niespełnienie tego wymagania uczyni system nieprzydatnym do celu w hakim powstaje.
Jak widać jedynka to najniższy priorytet. Z uwagi na zarządzanie projektem i wymaganiami, dodatkowo stosowane są, niezależnie od priorytetów, statusy wymagań: proponowane, zatwierdzone, odrzucone, odroczone, projektowane, wdrożone (mozna spotkań inne ale ich sens jest taki sam).
Skala MoSCoW to:
M – Must have – wymagania obligatoryjne, które system musi zapewniać. S – Should have – wymagania, które powinny znaleźć się w systemie. C – Could have – wymagania dodatkowe, które są pożądane, ale nie są niezbędne. W – Won’t have – wymagania, które nie zostaną wdrożone (ale mogą być wdrożone w przyszłości).
Jak widać skale te różnią sie podejściem. Generalnie celem jest zarządzanie wymaganiami. Skala trzystopniowa to świadome zarzadzanie zakresem projektu. Definicje są precyzyjne: nie ma żadnego problemu z nadawaniem priorytetów. Skala MoSCoW ma charakter uznaniowy: definicje tych czterech grup nie są precyzyjne: nie wiadomo jak odróżnić to co “powinno być” od tego co “jest pożądane”?
Podsumowanie
Stosowanie typowych historyjek użytkownika ma dwie kluczowe wady: 1. nie ma jednej metody zarządzania ich gradacją i strukturą, wielu autorów przywołuje własne, nieco się różniące metody standaryzacji, 2. ich drobiazgowość oraz brak metody kontroli spójności, prowadzą do szybko rosnącej ich liczby, w konsekwencji chaosu, szczególnie w średnich i większych projektach.
Powyżej widać, że modelowanie procesów biznesowych na podstawie zebranych przykładowych dokumentów (produkty pracy ludzi: dokumenty) i opracowanie na ich podstawie diagramu przypadków użycia, daje znacznie lepsze wyniki niż zbierane na warsztatach historyjki użytkownika. Same wymagania wyrażone jako historyjki użytkownika, nie dają żadnej szansy (brak metody) na kontrolę ich spójności, kompletności i niesprzeczności. Wymagania, jako konsekwencja poprawnie wykonanych modeli procesów biznesowych, z zasady są spójne, kompletne i niesprzeczne.
W przytoczonym tu przykładzie widać, że dwie aktywności (rejestracja zamówienia i kontrola jego statusu) realizowane są jako dostęp do zapisanego w systemie Zamówienia. Daje to jasną przesłankę do tego, że dwie historyjki użytkownika (dwie aktywności na modelu procesów) to dwa różne konteksty użycia tej samej usługi aplikacji: Zamówienia (czyli dostęp do ich tworzenia, aktualizacji i podglądu, to typowy przypadek użycia typu CRUD). Prawa dostępu do tego dokumentu modeluje się zaś regułami biznesowymi (nie pokazano ich na diagramach), np. “Klient ma wgląd tylko w Zamówienia, które sam złożył”.
Można uznać, że małe projekty, o małym ryzyku chaosu wywołanego brakiem modeli procesów, można realizowac “na skróty” czyli historyjki użytkownika i od razu model PSM (implementacja) z pominięciem CIM i PIM, jednak jest to poważne ryzyko już przy średnich projektach. Dlatego proces MDA:
{CIM -> [zakres projektu] -> PIM} -> PSM
wydaje się być znacznie efektywniejszy co pokazuje praktyka (w nawiasach klamrowych {} zakres pracy analityka-projektanta).
Zakres projektu to albo całe procesy biznesowe albo świadomie wybrane ich określone aktywności. Nie jest to także żaden “wodospad” (waterfall), bo analityczny model procesów biznesowych powstanie szybciej i taniej niż lista setek historyjek z pomocą wielodniowych warsztatów angażujących całe zespoły ludzi. Wygenerowane z modelu procesów biznesowych przypadki użycia, są z zasady spójne i kompletne, więc ich iteracyjne (kolejne) specyfikowanie (każdy projektujemy jako samodzielny mikroserwis) pozwala bez ryzyka oddawać je kolejno do implementacji, i jednocześnie dokumentować (uszczegóławiać) kolejne.
To sprawdzona w praktyce metoda wspierana przez wiele narzędzi CASE (wszystkie diagramy i ich przekształcenia pokazane w tym artykule powstały z użyciem Visual-Paradigm). Diagram przypadków użycia UML jest tu automatycznie generowany z modeli BPMN, wg poniższych zasad:
Po tej operacji wystarczy sprawdzić konteksty dokumentow i skonsolidować w jeden ewentualne nadmiarowe przypadki użycia. I na koniec:
“Jeśli nie masz modeli pojęciowych, brakuje Ci ważnego elementu układanki w projektowaniu rozwiązań, który jest niezwykle pomocny w dostrzeganiu i przekazywaniu ogólnego obrazu tych historyjek.”
Produktem modelowania procesów biznesowych są jakieś diagramy, i z tym jesteśmy oswojeni. Od czasu do czasu można usłyszeć o symulacjach procesów, lecz to już jednak znacznie rzadziej. O symulacjach procesów pisze się mniej: Google Scholar (literatura naukowa) pokazuje ok. 5 mln publikacji na temat modelowania procesów biznesowych, na temat ich symulacji 2 mln mniej. Ale już Google (“cały Internet”) odpowiednio: 2,3 mld. i 282 mln. Jak widać w powszechnym obiegu symulacje, jako temat, to trzy rzędy (tysiąckrotnie) mniejsza ilość tekstów! (wyszukiwane były hasła ang. ‘business process modeling’ oraz ‘business process simulation’). Zastanówmy się dlaczego i co można osiągnąć symulacją.
Sprzedawca
4.1.3.1. Sprzedaż
unnamed
Sprzedawca
Magazynier
4.2.3.1. Wydanie towaru
unnamed
Magazynier
Klient, 
Pracownik BOK
4.3.3.1. Rejestracja Zamówień
4.3.3.2. Śledzenie Zamówień
unnamed
Pracownik BOK
unnamed
Klient
