Wyniki wyszukiwania dla „reguły biznesowe” – Strona 11

Panowanie nad złożonością czyli gdzie są Przypadki Użycia czyli MVVM-MVC

Tak więc przypadkami użycia opisujemy abstrakcję jaką jest [[Model Dziedziny Systemu]]. Są one wtedy proste, zawierają scenariusz, który w skrócie ma postać: aktor inicjuje usługę, system prezentuje formularz do wypełnienia, aktor wypełnia go i potwierdza, system potwierdza odebranie danych i pokazuje wynik swojej pracy (lub komunikaty o błędach). Tu skupiamy się na opisie tego jakie usługi są wymagane od systemu. Kolejny etap to “komplikowanie” każdego scenariusza w postaci projektowania, dla każdego przypadku użycia, różnego rodzaju wizardów lub wprowadzamy ograniczenia związane z uprawnieniami użytkowników. Ten etap to praca projektantów UX i grafików, specjalistów od ergonomii itp.

Czytaj dalej

Praw fyzyki Pan nie złamiesz i nie bądź Pan głąb

zbieranie wymagań tylko metodą spisywania oczekiwań czy wręcz żądań, użytkowników, jest jedną z najgorszych metod pozyskiwania wymagań! Praktycznie zawsze prowadzi do powstawania specyfikacji bardzo złej jakości (niespójne i niekompletne) oraz niekontrolowanego rozrastania się harmonogramu i budżetu projektu. Dostawcy oprogramowania, godzący się na taki styl prowadzenia projektu, świadomie lub nie, działają na szkodę swoich klientów. Analiza systemowa organizacji jako sposób pozyskania wymagań, który chroni przed takimi zjawiskami.

Czytaj dalej

Gdzie są te cholerne szczegóły

Tak więc, warto rozważyć stosowanie reguł biznesowych i słowników pojęć (Semantics Of Business Vocabulary And Rules), gdyż jest to sprawdzona i bardzo przydatna technika analizy i dokumentowania logiki biznesowej. Polecam także stronę The Business Rules Group i zamieszczony tam Manifest Reguł Biznesowych. Tworzenie monstrualnych dokumentów wymagań, zawierających dziesiątki razy powielane “walidacje” prowadzi do wielu kłopotów z utrzymaniem spójności i kompletności takich specyfikacji. Pomijam już ich uciążliwą objętość. Jako materiał dla programisty są one wtedy trudne w użyciu, do tego skłaniają do najgorszych praktyk, jakimi jest między innymi umieszczanie logiki biznesowej w kodzie formatek ekranowych.

Czytaj dalej

Zintegrowany ERP: postęp czy cofanie?

Zakup oprogramowania, które stanowi jeden, zintegrowany współdzieleniem danych, monolit to nic innego jak zafundowanie sobie długu technologicznego w momencie podjęcia decyzji o takim zakupie. Żadna firma, działająca w obecnych czasach, nie da sama sobie gwarancji, że jej wewnętrzne aktywności nie zmienią się co do ich specyfiki, że nie przybędzie nowych, nie zrezygnuje z niektórych. Monolityczny całościowy system ERP stanowi hamulec każdej takiej zmiany. Oparcie całości na centralnym , współdzielonym module rejestrującym (jest z nim z reguły księgowość) to niemalże “zabetonowanie” architektury biznesowej firmy.

Czytaj dalej

O sieciach handlowych i stanowieniu prawa

Na zakończenie mogę powiedzieć, że dokładnie takie same błędy widzę w projektach informatycznych. Wymagania są definiowane jako dziesiątki i setki “spotkanych w życiu przykładów i doświadczeń”. Lista wymagań, powstała jako efekt wywiadów, prototypów, sesji burz mózgów, bardzo często wygląda jak taki właśnie okręt, którego poszycie składa się w 100% z chaotycznie przybitych łat. To jak by wymagania na okręt spisywali marynarze, kierując się najlepszą swoją wiedzą z rejsów, które odbyli, dodatkowo lobbujący – każdy z nich – na rzecz swojej kajuty i wyposażenia.

Czytaj dalej

Wymagania pozafunkcjonalne – integracja

Integracja to jeden z trudniejszych problemów. Wymaga bowiem nie tylko specyfikowania (i potem ich implementowania) interfejsów, ale także analizy i opracowania bezpiecznej architektury całego systemu (tu znowu architektura korporacyjna). Wiele firm ma, nie dwie ale kilka, kilkanaście a niektóre nawet setki aplikacji. Jeżeli będę ze sobą “pospawane” wywołaniami SQL/ODBC, to ruszenie “tego” praktycznie zawsze kończy się krachem (czytaj ogromne koszty przywrócenia funkcjonowania całości). Brak przemyślanej architektury, integracja ad-hoc “każdy z każdym”, to prosta droga do kłopotów i ogromnych kosztów utrzymania całości. Stosowanie API (ich tworzenie) nieco tylko podnosi koszty wdrożenia, za to chroni przed bardzo dużymi, nieplanowanymi, wydatkami w przyszłości.

Czytaj dalej

Strategia krótkoterminowa

Stosowanie określonych terminów zgodnie z ich właściwymi znaczeniami ma głęboki sens. Rzecz w tym, by budowany “opis” (np. biznes plan, prospekt emisyjny, kontekst projektu IT), był nie tylko “powszechnie zrozumiały” ale o to by w ogóle miał jakiś sens. Bo to, że “ładnie i mądrze brzmi” w korporacyjnej dokumentacji to na dłuższą metę za mało.

Czytaj dalej