Często spotykam się z różnymi metodami uwzględniania prawa w “dokumentacji wymagań”. Jakim wymaganiem jest “zgodność z obowiązującym prawem”? I trudniejsze pytanie: czy zmiana prawa to zmiana wymagań? Inny aspekt problemu to analiza i definicja (opis) tej zgodności z prawem. Spotkać można się z metodą polegającą na traktowaniu każdego (mającego wpływ na system) paragrafu np. ustawy jako wymagania.
Problem zgodności oprogramowania z prawem ma dwa aspekty.
Zgodność oprogramowania z prawem polega na tym, że “oprogramowanie nie może ograniczać stosowania prawa to jest nie może wymuszać swoimi ograniczeniami działań niezgodnych z prawem”.
Ja osobiście rekomenduję rozciągnięcie tej definicji na “ani nie powinno pozwalać na łamanie prawa“. Tu jednak wielu uważa, że “zamawiam narzędzie i używam jak chcę, na swoja odpowiedzialność”. Coś w tym jest, warto jednak zostawić “włącznik”. Typowym przykładem tego problemu jest możliwość tworzenia ujemnych stanów magazynowych (sprzedaż tego czego się nie ma, jest niezgodna z prawem). Budzi to wiele kontrowersji na etapie “analizy wymagań”, ale osobiście uważam ujemne stany magazynowe, i wielu ludzi jakich spotykam w projektach też, za patologię i niedojrzałość do prowadzenia biznesu. Jednak włącznik w wielu rozwiązaniach jest :).
Czym jest wymaganie? Jak je definiujemy?
Wymagania w stosunku do oprogramowania dzieli się najczęściej na funkcjonalne i poza-funkcjonalne. Wymaganie funkcjonalne to usługa systemu (oprogramowanie wspiera nas w wykonywaniu jakiejś czynności), mogą być tu wydzielone wymagania przejściowe (np. funkcjonalności potrzebne tylko na czas migracji ze starego systemu). Wymagania poza-funkcjonalne to ograniczenia czyli wymagania jakościowe lub dziedzinowe. Jakość to niezawodność, bezpieczeństwo, wydajność. Dziedzinowe wymagania to np. zdolność oprogramowania do realizacji konkretnej logiki biznesowej, stopień odwzorowania rzeczywistości – zgodność z tą rzeczywistością (np. ujemny stan magazynowy to nierzeczywisty stan, opis produktu to struktura, którą należy odwzorować w systemie). Wymagania wynikające z aktów prawnych to wymagania dziedzinowe (ograniczone zachowania obiektów biznesowych) i ograniczenia.
Kiedy jakie wymagania?
Specyfikując wymagania warto pamiętać po pierwsze o zakresie projektu, a po drugie o tym czy specyfikujemy wymagania na produkt gotowy (tak zwany [[COTS]] np. pakiet ERP czy CRM), czy na system dedykowany. Wymagania wynikające z dziedziny systemu (tu prawo) powinny być udokumentowane jako “coś co będzie implementowane” ale czy zawsze?
Swego czasu pisałem o tym, że podstawowy model w analizie, model przypadków użycia, zawiera abstrakcję systemu oraz jego użytkowników: aktorów.
Jednym z kluczowych elementów specyfikacji jest w moich projektach specyfikacja aktorów. Jak często spotykacie Państwo projektanta, który opracowuje listę aktorów systemu zawierającą ich charakterystykę, w szczególności wiedzę i wymagane umiejętności? W czym problem? Zasadnicze pytanie: prawo ma znać aktor czy czy “system”? Kto ma nadzorować jego przestrzeganie? Prawie każdy człowiek ma w domu nóż, gdzie jest zaimplementowane “nie zabijaj”?
Czy postawiono wymaganie: system nie może pozwolić na wykonanie operacji niezgodnej z prawem? Kto lub co ma realizować wymagania “zgodności z prawem”? Jeżeli aktor, zapisujemy to w charakterystyce aktorów (człowiek musi przestrzegać prawa i odpowiada za jego nie przestrzeganie).
Jeżeli chodzi o projektowany system, sprawa się komplikuje, gdyż prawo to ograniczenia i nie powinny one być szkieletem tego systemu a co najwyżej dodatkowymi parametrami. Osobiście hołduję zasadzie hermetyzacji w projektach, to co nazywamy prawem opisuje jako dedykowane klasy dziedzinowe mające pełną wiedzę o tych ograniczeniach prawnych (także wewnętrznych zarządzeniach w firmie itp.). Tą metodą oddzielam zmienność prawa od szkieletu systemu, dzięki czemu zmiany prawne nie powodują lawinowych zmian w gotowym już oprogramowaniu.
Druga korzyść to swoboda decydowania jaką “wiedzę” ma mieć aktor a jaką “system”. Prostym przykładem jest usługa systemu (przypadek użycia) jaką jest wystawianie faktur. Inaczej system powinien zachować się gdy fakturę wystawia np. Główny Księgowy (ma pełną wiedzę o tym co robi) i można dać takiej osobie dużą swobodę kształtowania treści takiego dokumentu (raczej poprzestaniemy na nieskomplikowanej walidacji podstawowej logiki obliczeń). Jednak wystawienie faktury przez “zwykłego” pracownika działu sprzedaży, powinno być obłożone wieloma zabezpieczeniami, regułami, np. towar wyłącznie na podstawie zamówienia, tylko wybrane podatki, itp.
W przypadku systemu gotowego, nie widzę sensu prowadzenia żmudnej analizy aktów prawnych, wykonał ją (zakładam, że tak) dostawca – twórca, gotowego oprogramowania np. ERP i oczekuje od niego tej zgodności z prawem (i innymi normami czy standardami). Unikamy w ten sposób nadmiernych kosztów (pracochłonność) specyfikacji wymagań na gotowe oprogramowanie. Deklaracja dostawcy (np. system jest zgodny z ustawą o rachunkowości, podatku VAT itp…) jest wystarczającym do wyboru tego oprogramowania (i tak nie sprawdzimy tego w rozsądnie krótkim czasie podczas wyboru oprogramowania) a potem powodem do ewentualnej reklamacji. Wykonanie szczegółowej listy ograniczeń prawnych wcale takiej deklaracji dostawcy nie “ulepszy”. Gdy zechce, zadeklaruje tę zgodność tak czy tak…
Więc jak?
Ograniczenia prawne (nakazy i zakazy) to reguły analogiczne do biznesowych (reguły biznesowe to wewnętrzne nakazy i zakazy, wewnętrzne prawo firmy). Na etapie analizy biznesowej należy je opisać i skojarzyć z czynnościami (tymi, które są ograniczane tymi regułami):
Stosuję następujący sposób uwzględniania prawa w wymaganiach: traktowanie prawa jako odrębnej specyfikacji reguł biznesowych. Powstaje lista w rodzaju: ID reguły, jej definicja, opis, źródło … Reguły biznesowe można potem kojarzyć (śladować) z czynnościami w procesach i z klasami w modelu dziedziny. Jestem zwolennikiem traktowania takich reguł właśnie nie, jak wymagań (prawo to nie usługa systemu a ograniczenie swobody jego użycia) a jak ograniczeń w procesach. Prawo może się zmieniać, system powinien być na to odporny…
Mały cytat z opisu metodyki jaką stosuję:
Praktycznie każda organizacja, poza prawem, którego musi przestrzegać, ma własne wewnętrzne regulacje. Ich liczba jest zależna od stopnia formalizacji pracy. W przypadkach gdy regulacje te były tworzone latami, bardzo często ich liczba jest większa niż wymaga tego sytuacja. Bardzo często poszczególne regulacje bywają sprzeczne lub zamiast reguły specyfikują jej wariant (np. zamiast określić ogólnie istnienie progu podejmowania przez kadry kierownicze decyzji o kosztach i sposób ich określania, specyfikują osobno stanowiska i konkretne kwoty, nie raz sprzeczne).
Reguły biznesowe mogą być obrazowane na diagramach. Specyfikowane są w postaci listy zawierającej symbol i nazwę reguły oraz jej formułę w postaci: ?dla każdego ??, ?jeżeli ? to ??, ?zawsze gdy? należy ?? itp. Reguły biznesowe tworzy się na bazie pojęć budowanego Słownika pojęć, który jest integralną częścią projektu.
WARTOŚĆ DODANA
Podstawową korzyścią z wyodrębnienia reguł biznesowych i słownika pojęć jest uporządkowanie słownictwa w dokumentacji i uczynienie jej jednoznaczną oraz weryfikacja ewentualnych sprzeczności regulacji wewnętrznych (Zarządzeń, Prawa). Powoływanie się na Reguły biznesowe na modelach procesów biznesowych, pozwala zachować ich prostotę nie tracąc szczegółowości wiedzy o procesach. Tak wykonana dokumentacja procesów nie wymaga częstej i kosztownej aktualizacji, z reguły aktualizowane są procedury i reguły biznesowe, na które modele procesów się powołują.
(źr. SPOSÓB PROWADZENIA I DOKUMENTOWANIA ANALIZ BIZNESOWYCH I PROJEKTOWANIA SYSTEMÓW, Jarosław Żeliński)
Tak więc akty prawne to zakazy i nakazy, reguły biznesowe. Oprogramowanie, zależnie od przyjętej konwencji, nie powinno ograniczać ani nawet utrudniać postępowania zgodnego z prawem, może też pojawić się oczekiwanie by nie pozwalało łamać prawa. Szczegółowa analiza aktów prawnych, w moich oczach, ma sens gdy projektujemy oprogramowanie. Gdy stawiamy wymagania przed już istniejącym oprogramowaniem, jeżeli zakładamy że kupimy gotowe, wystarczy wymagać zgodności z prawem w obszarze stosowania oprogramowania. Jeżeli np. oprogramowanie ma pozwalać na wystawianie faktur to znaczy, że powinno być możliwe wystawienie każdej faktury przewidzianej prawem w sposób zgodny z nim. Możemy dodatkowo zażądać by nie było możliwe wystawienie faktury niezgodnej z prawem.
Podsumowanie
Podstawą kojarzenia pojęć i ich śladowania są definicje tych pojęć: muszą być zgodne, lub całkowicie się w sobie zawierać. Jeżeli czynność jest szerszym pojęciem niż przypadek użycia, przypadek użycia jest wywodzony (mapowany) z czynności w procesie, przypadek użycia nie powinien oznaczać niczego co nie mieści się w pojęciu “czynność”.
W procesie mamy czynności, wymagania funkcjonalne to usługi systemu: jego przypadki użycia. Oznacza to, że nie jest wymaganiem funkcjonalnym to, co nie jest przypadkiem użycia systemu ([[zasada wyłączonego środka w logice]]). Wymagania poza-funkcjonalne to pozostałe, nie będące usługą systemu, jego cechy. Pozostają więc jakość i logika wewnętrznej budowy. Śladowanie to wygląda np. tak:
Czynność jest mapowana na przypadek użycia. Rola w procesie na aktora. Przypadek użycia ma odpowiadającą mu klasę usługową (zarządza świadczeniem tej usługi). Jeżeli istnieją jakieś reguły i ograniczenia, są one implementowane jako osobne klasy składowe klasy usługowej. Możliwe jest też zaimplementowanie odrębnego “motora reguł biznesowych” jeżeli system wymaga ich bardziej wyrafinowanej obsługi.
Tak więc zgodność oprogramowania z prawem to jego wymagana cecha (właściwość) a nie funkcjonalność.
Więcej o regułach w artykule: Business rules concept… oraz artykule Reguły biznesowe…
W artykule z 12 czerwca 2012 roku stwierdził Pan w swoim artykule “Prawo a wynagania” iż tworzenie stanów magazynowych a wiec i mozliwośc sprzedaż jest niezgodna z prawem. Czy mógłby Pan, jeżeli mozna określić czy ta niezgodnośc dotyczy konkretnej litery prawa?
Pozdrawiam
Tadeusz Retmańczyk
Chodzi rozumiem, o ujemne stany magazynowe? Wystawienie dokumentu poświadczającego dokonanie sprzedaży towaru (faktura VAT), którego się nie ma (stan zero w magazynie) to poświadczenie nieprawdy co już jest łamaniem prawa. Jest niezgodne z ustawą o podatku VAT (jak go w takiej sytuacji legalnie policzyć?). Nie ma paragrafu mówiącego “nie wolno mieć stanu ujemnego na magazynie”, ogólnie poświadczanie nieprawdy jest łamaniem prawa, a tym są niezgodne z faktami zapisy księgowe (lub ich brak). Ujemne stany magazynowe w oprogramowaniu magazynowym to wyłącznie “lekarstwo” na chęć sprzedania (zafakturowania) towaru, zanim zostanie przyjęty na magazyn. Powodem są najczęściej naciski sprzedawców w zabałaganionej firmie. Niektórzy księgowi bronią się, że dostawa kompensuje ten “minus” i czas “tej chwilowej niezgodności” jest krótki, ale: formalnie data przyjęcia nie może być późniejsza niż data sprzedaży, ma więc miejsce antydatowanie dokumentu przyjęcia. Po drugie jakiekolwiek zdarzenie związane ze sprzedażą (data zdarzenia, np. kradzież, inne nadużycia) rodzą ryzyko wyjawienia tej “chwilowej” sytuacji. Rzecz w tym, że zapisy księgowe nie mogą mieć “momentów” niezgodnych z prawem. Idąc dalej tym tropem, raportowanie z rejestrów zawierających “ujemne stany” czyni te raporty bezużytecznymi…
Na problem ten zwróciłem także uwagę tu: http://it-consulting.pl/autoinstalator/wordpress/2013/02/07/analityk-to-nie-dyktafon/
W jednym z poprzednich artykułów napisał Pan, że: “pracownik” jako człowiek to nie to samo co “pracownik” w systemie, czyli powinno być “kartoteka pracownika” – podobnie z np. odwzorowaniem magazynu. Spodobało mi się to podejście. W konsekwencji tego, możliwe są stany magazynowe ujemne, ponieważ nie są one bezpośrednim odwzorowaniem “fizyczności”. Podobnie dotyczy to też zgodności oprogramowania z prawem.
Oprogramowanie, podobnie jak papier, zdzierży wszystko i to jest prawda, warto jednak nie zapominać, że ono służy do zarządzania tym co realne ;). W oprogramowaniu deklarujemy asercje, to reguły które czynią je przydatniejszym :). Co zrobi właściciel firmy, jeżeli trafi go kontrola z Urzędu skarbowego i wykryje niezgodność danych np. z Ustawą o podatku VAT?
Zależnie od sytuacji i możliwości właściciela podejmie on decyzję, którą uważa za najlepszą 🙂
Zaznaczam, że mówimy o oprogramowaniu zgodnym z wymaganiami właściciela.
Największym dylematem jaki nie raz mam jest to, do jakiego stopnia takie wymagania należy spełniać. Jest gdzieś granica, której przekroczenie czyni z wykonawcy najemnika mordercę. Pytanie, czy najemnik morderca jest rozgrzeszony tym, że wykonywał zlecenie swojego klienta? W tym przypadku, zgodnie z prawem winni są obaj, w IT już nie ma takiego prawa, sami je tworzymy zawierając umowy… Tu chyba nie ma prostej odpowiedzi… Ja osobiście stosuję zasadę, w której w wymaganiach ‘wpisuje asercję”, komentuje ją, i pozostawiam zamawiającemu możliwość jej “wyłączenia”, zalecam jedynie by była to opcja na ekranie a nie “usunięcie z projektu”. To moim zdaniem jest najuczciwsze dla obu stron podejście.
Myślę, że IBM sprzedając komputery nazistom w początkach ubiegłego wieku był blisko granicy “najemnika mordercy”. Dzisiaj jeśli intencją funkcjonalności nie jest oszukiwanie, ale np. uelastycznienie – życie bardzo trudno wpisuje się w sztywne procedury – to moim zdaniem można z czystym sumieniem takie funkcje tworzyć.
Zresztą to nie jest tylko problem informatyki. Np. producenci noży dobrze sobie zdają sprawę, że można ich produkty używać do zabijania – wszystko zależy od intencji produkującego i używającego.
Przykład z nożem jak najbardziej słuszny, jednak pamiętajmy, że np. na pokład samolotu z zasady nie można jednak wnieść niczego co ma ostrze dłuższe niż 6 cm, wiec jednak pewne reguły są ustalane i przestrzegane. Innym wyraźniejszym przykładem tego, że jednak pewne reguły są nie tylko uznawane ale także powstaje oprogramowanie by to kontrolować są aplikacje wykrywające pewne nadużycia czyli systemy typu “fraud detection”. Tak więc zgadzam się z tym, że zamawiający jest dorosły i zna (należy tak założyć) konsekwencje, ale nie zawsze. Znam dyrektorów finansowych dużych firm, którzy byli zaskoczeni tym, że stan ujemny w magazynie jest niedopuszczalny(!). Pytanie brzmi: jaka analiza powinna wykonana na początku projektu? Czy analiza biznesowa, w której treści nie znajdzie się rekomendacja o potencjalnej szkodliwości rozwiązania jest dobra analizą? Czy dostawca oprogramowania pozwalającego na nadużycia nie stawia się w pozycji równej ze sprzedawcą broni zaopatrującym terrorystów?
Przed lub w trakcie analizy zawsze można zapytać: Do czego jest to potrzebne? Jaki cel chcecie osiągnąć? Czy zdajecie sobie sprawę, że to może być niezgodne z przepisami?
Zależnie od odpowiedzi, można wtedy podjąć decyzję zgodną z własnymi przekonaniami.
I to jest chyba właściwe podsumowanie 🙂