Category Archives projektowanie systemów informatycznych

Myślę, że czasem warto się pochwalić drobnymi osiągnięciami. W 2013 roku miałem okazję współpracować z Ministerstwem Sprawiedliwości. Brałem udział w projekcie SIWPM (System Informatyczny Wspierający Procesy Merytoryczne). Zadaniem tego systemu jest wsparcie pracowników sądu w ich pracy od biura podawczego poprzez zarządzanie aktami (tzw. kalendarz)  kończąc na wsparciu czynności wydawania orzeczeń.

Kilkanaście miesięcy konsultowałem, wspomagałem z ramienia MS proces zbierania wymagań. Pracując z sędziami, sekretarzami, spędzając na analizie setki godzin,  wydaje się, że dość dobrze poznałem specyfikę pracy naszego sądownictwa. 

Istotne jest jednak to, że brałem udział w jednym z tych projektów, w których Zamawiający nie tylko miał wizję systemu ale także wymusił powstanie obszernej dokumentacji analitycznej.

Wynik tej pracy to ponad 600 przypadków użycia i ponad 500 prototypów ekranów. Zidentyfikowano i opisano ponad 2900 scenariuszy użycia systemu.

Enterprise Architect w swojej dokumentacji proponuje by wymagania były łączone ze sobą za pomocą agregacji.

image

Zastosowanie agregacji nie jest zgodne ze znanymi mi  standardami. Jeśli potrzebujesz modelować wymagania zgodnie ze standardami proponuję SysML - Systems Modeling Language for Products and Systems Development.

W poprzedniej części wpisu rozpoczęliśmy definiowanie modelu naszego Web serwisu zgodnego ze strukturą WSDL. Zakończyliśmy zdefiniowaniem komunikatów jakie będą wymieniane z naszym serwisem. Gdy mamy już zdefiniowane komunikaty możemy przystąpić do definiowania portu naszego serwisu. W tym celu na diagram w pakiecie „PortTypes” przeciągamy z toolbox element „Port Type” i nadajemy mu nazwę „PobierzInformacjeOKsiazce”. Następnie definiujemy operację dla naszego portu przez…

WSDL (Web Services Description Language) jest to oparty na XML język pozwalający na opis serwisów Web z uwzględnieniem sposobu dostępu do nich. System Enterprise Architect firmy Sparx Systems pozwala na łatwe utrzymanie modelu zgodnego z WSDL opisującego Web serwisy w repozytorium naszego projektu, który może być później szybko wygenerowany do pliku WSDL i przekazany programistom do implementacji serwisu. W tym…

Pozwolę sobie przytoczyć kilka dobrych praktyk związanych z architekturą.

Struktura poszczególnych modułów powinna być na tyle prosta, aby można ją było w pełni zrozumieć.

2. Moduły powinny być luźno ze sobą powiązane, tzn. powinna być możliwa zmiana implementacji jednego modułu, bez znajomości implementacji pozostałych modułów i bez wpływania na ich zachowanie.

3. Łatwość wprowadzania zmian w projekcie powinna pozostawać w rozsądnej relacji do prawdopodobieństwa wymaganych zmian;

Czy zwinne modelowanie działa zawsze? Otóż nie. Zazwyczaj z podejściem Agile są problemy gdy opisujemy procesy w dużych firmach, gdzie istnieje: duża ilość procesów problemy są oparte o Heavy Six Sigma lub PMI procesy ISO 9000, 900x Ponadto jest duża ilość zespołów analitycznych działających w różnych obszarach Co można wtedy zrobić? Po pierwsze przyzwyczaić się do myśli iż duża organizacja…

Od trzech miesięcy nie wiele pisałem na tym blogu. Kilka słów wyjaśnień. Właśnie wróciłem z kilkutygodniowych wakacji . Oczywiście poza wakacjami bez kontaktu z komputerem to powodów było kilka, ale najważniejszą przyczyną przyczyn była moja obrona. Otóż w kwietniu obroniłem doktorat w Instytucie Podstaw Informatyki Polskiej Akademii Nauk. Otrzymałem tytuł doktora nauk technicznych w zakresie informatyki. Od i wszystko. Teraz…

Ostatnio natknąłem się na prace Kartezjusza* “Rozprawa  metodzie”. Czytając to dzieło w rozdziale w części drugiej przeczytałem opis metody, którą niemalże bez zmian stosuje się dziś w procesie analizy  i projektowaniu systemów.

… Jak  mnogość  praw  dostarcza  często  usprawiedliwienia występkom, tak iż w państwie o wiele większy jest ład wówczas, gdy przy niewielkiej ilości praw są one bardzo  ściśle  przestrzegane,  podobnie,  zamiast  wielkiej  liczby  prawideł,  z  których  składa  się  logika,  sądziłem,  iż wystarczą  mi  następujące  cztery,  bylebym  postanowił  raz  na  zawsze  i  niezłomnie  nie  zaniedbać  ani  razu  ich  przestrzegania.
Pierwszym  było  nie  przyjmować  nigdy  żadnej  rzeczy  za  prawdziwą,  zanim  jej  nie  poznam  z  całą  oczywistością  jako  takiej:  to  znaczy  unikać  starannie  pośpiechu  i  uprzedzeń  i  nie  obejmować  swoim  sądem  niczego  poza  tym,  co  się  przedstawi  memu  umysłowi  tak  jasno  i  wyraźnie,  iż  nie  miałbym  żadnego  powodu  podania tego w wątpliwość.

W poprzedniej części zaprezentowałem model przepływu danych oparty o diagram maszyny stanowej. Zaproponowałem także mechanizm mapowania elementów z diagramu maszyny stanowej na zagrożenia (w oparciu o STRIDE z SDL). Dziś kolejna czwarta i ostania cześć, w której zaprezentuje techniki dokumentacji ryzyk oraz podatności. Na końcu opiszę jak dokumentować mechanizmy łagodzące oraz zrobię krótkie podsumowanie. Zapraszam do lektury. 

Ustalenie ryzyka

Sklasyfikowane klasy zagrożeń wymagają doprecyzowania ryzyka dla każdej z klas.

clip_image002[7]

Rysunek 4. Drzewo zagrożeń – manipulowanie przy przepływie danych (na podst. [1])

Close