Z uwagi na zainteresowanie moim projektem "demo" stworzyłem tę stronę. Tu będą się pojawiały informacje o kolejnych etapach tworzenia tego dokumentu. Powiadomienia o postępach będą wysyłane mailem do subskrybentów. Projekt Szachy ma na celu pokazanie na prostym przykładzie, toku analizy i produktów jakie tworzę w roli analityka i projektanta. Dokument ten może zawierać pewne braki (brak pewnych szczegółów) gdyż celem tego dokumentu jest zademonstrowanie zawartości tego rodzaju dokumentacji a nie szczegółowe opracowanie realnego projektu, będzie to jednak zaznaczone w treści. Kliknij i pobierz aktualny plik projektu Wszelkie pytania i sugestie na temat treści projektu…
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ą.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 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, 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.
Jak ustrzec się przed wyniesieniem z firmy tajemnicy jej funkcjonowania, tworzonej latami organizacji, procedur i procesów, reguł biznesowych? Jak zatrzymać w firmie wiedzę mino zamawiania oprogramowania, które siła rzeczy ja zawiera? Problem nie jest prosty. Sami prawnicy nie są między sobą zgodni co do tego, gdzie leży granica pomiędzy utworem literackim a szczegółowym opisem rozwiązania. Wydaje się, że kluczem jest to sposób tworzenia opisu tego co ma powstać. Standardem w IT jest opis wymagań, ten jednak z urzędu czyni autora oprogramowania także posiadaczem opisu logiki w nim zawartej, bo on jest autorem jej opisu. Wyjściem wydaje się zawarcie w umowie nie opisu wymagań na oprogramowanie a projektu oprogramowania. Metodą zdefiniowania granicy, za którą mamy nie utwór literacki (specyfikacje wymagań) a projekt wraz z algorytmami, jest metodyka MDA. Wtedy firma realizująca zamówione oprogramowanie tworzy dzieło zależne a zamawiający nie traci panowania nad tak powstałym produktem. Jest to sytuacja jaką znamy w branży budowlanej: developer dostaje projekt architektoniczny, i sam fakt, że postawił na jego podstawie obiekt nie daje mu żadnych praw do niego, gdyż wystarczająco szczegółowy projekt obiektu pozostaje dziełem projektanta a nie jego wykonawcy.Jednak zawsze, bo nie ma złotej reguły, wymaga to konsultacji i szczegółowego określenia zawartości dokumentacji, która ma stać się "opisem przedmiotu zamówienia".
Osobą odpowiedzialną za system IT zawsze będzie zamawiający. Dlatego zamawiający powinien jednoznacznie opisać swoje oczekiwania i zrozumieć potem odpowiedź czyli propozycję ich wykonawcy. Menedżer nie musi uczyć się diagramów UML ale powinien rozumieć modele procesów tak by mieć możliwość ich oceny i zatwierdzania. Dlatego modele procesów powinny być tworzone metodami zrozumiałymi dla menedżerów, moim zdaniem nie jest to notacja UML. Notacja ta jednak jest niewątpliwie doskonałym narzędziem do udokumentowania i przekazania swoich oczekiwań przyszłemu wykonawcy systemu: integratorowi IT. Tak więc wykonaj model procesów biznesowych, określ które procesy chcesz informatyzować. Potem przygotuj na bazie tej analizy listę przypadków użycia przyszłego systemu, uzupełnij ją o model pojęciowy twojego biznesu i firmy i przekaż to do realizacji wykonawcy systemu. Na koniec pozostaje wdrożenie a to już osobny projekt :), socjologiczny.
