przypadki użycia

Podsumowanie 2016 i plany na 2017

Kończy się rok 2016. Dla mnie dość intensywny i jednocześnie pełen refleksji. Refleksja dotyka kilku tematów. Zastanawiam się dokąd zmierza architektura korporacyjna? Co stanie się z architektami korporacyjnymi w organizacjach, które jeszcze nie dojrzały do wykorzystania mocy architektury korporacyjnej. Myślę coraz cieplej o Scrum, który coraz częściej łączy się z analizą po to by dokumentacja […]

Podsumowanie 2016 i plany na 2017 Czytaj dalej »

Dokumentacja przypadków użycia w administracji publicznej

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

Dokumentacja przypadków użycia w administracji publicznej Czytaj dalej »

Jak opisywać przypadki użycia?

Opisując przypadki użycia stosuję kilka poziomów ich opisu. Najpierw identyfikuję aktorów i przypadki użycia potem dla każdego przypadku użycia opisuje punkty końcowe i początkowe by pomiędzy tymi punktami umieścić scenariusze.  Jakiś czas temu wynotowałem z jakiejś publikacji taki oto zakres działania Aktorzy i cele. Wypisz aktorów i ich cele, których realizację system będzie wspomagał. Sprawdź

Jak opisywać przypadki użycia? Czytaj dalej »

TORMIGO – oficjalnie na stronach Sparx Systems

Tormigo został oficjalnie zarejestrowany na stronach Sparx Systems jako program wspierający Enterprise Architect’a http://sparxsystems.com.au/products/3rdparty.html#tormigo Tormigo jest konkurencją dla RaQuest w zakresie zarządzania wymaganiami. Poza tradycyjnym wpisaniem wymagania Tormigo umożliwia zapisywanie danych bezpośrednio z MS Word i OpenOffice. Ponadto Tormigo działa pod Linuxem. Co więcej Tormigo umożliwia zarządzanie wymaganiami poprzez system automatycznego ich wersjonowania przy każdej

TORMIGO – oficjalnie na stronach Sparx Systems Czytaj dalej »

KILKA PORAD DLA MODELOWANIA WYMAGAŃ METODĄ AGILE

Chciałbym podzielić się kilkoma istotnymi zasadami, które, mam nadzieję, że pomogą ustanowić efektywne podstawy dla modelowania wymogów metodą agile (i nie tylko). 1. "Niezwykle ważny jest aktywny udział osób zainteresowanych”. Udziałowcy projektu powinni przekazywać swoje wymagania, nadawać im priorytety oraz w odpowiednim czasie podejmować decyzję. Istotnym jest, aby udziałowcy projektu zrozumieli tę koncepcję i angażowali

KILKA PORAD DLA MODELOWANIA WYMAGAŃ METODĄ AGILE Czytaj dalej »

Identyfikacja elementów modelu statycznego na bazie modelu przypadków użycia

Analizując model przypadków użycia można zidentyfikować elementy modelu statycznego (struktury). Poniżej kilka porad w tym zakresie: Szukaj rzeczowników: to zazwyczaj klasy lub atrybuty, przykładowo Centrum Odpowiedzialności. Szukaj czasowników: wskazują one często na związek. Przykładowo, użytkownik przypisuje Klienta do Centrum Odpowiedzialności. Szukaj sprawców: jeśli biznes wskazuje na ich działanie, lub są oni do czegoś potrzebni, stanowią

Identyfikacja elementów modelu statycznego na bazie modelu przypadków użycia Czytaj dalej »

Przypadki testowe z diagramów aktywności w Enterprise Architect

Kilka dni temu pisałem (w tekście: Automatyczne generowanie diagramów aktywności w Enterprise Architect) o wsparciu dla półautomatycznego tworzenia diagramów aktywności. Teraz dodam iż na podstawie tych samych scenariuszy można utworzyć przypadki testowe Podobne wpisy Model Analizy Biznesowej Model Analizy Biznesowej opisuje realizację biznesowych przypadków użycia. Prezentuje jak pakiety biznesowe, pracownicy biznesowi i byty biznesowe współpracują

Przypadki testowe z diagramów aktywności w Enterprise Architect Czytaj dalej »

Przypadek użycia i działanie aktorów w tym samym czasie

Co zrobić w sytuacji gdy do wykonania danej funkcji, opisanej przez przypadek użycia, potrzeba w tym samym momencie więcej niż jednego aktora? Czy można pokazać to na diagramie przypadków użycia? Otóż nie. Diagram przypadków użycia nie definiuje nam tego kto w jakiej sytuacji, w jakim momencie korzysta z danej funkcji. Relacja aktor – przypadek użycia

Przypadek użycia i działanie aktorów w tym samym czasie Czytaj dalej »

Agile a tworzenie przypadków użycia

Właściwym podejściem do definiowania przypadków użycia dla tworzenia oprogramowania przy użyciu metody agile to zacząć od definicji zakresu. Definicje zakresu można opisać za pomocą diagramów WPA (Wysokiego Poziomu Abstrakcji) Kiedy już zakres zostanie zdefiniowany należy zdefiniować nazwy przypadków użycia a następnie stopniowo nadawać priorytety i definiować bardziej szczegółowo przypadki użycia podczas gdy są one włączane

Agile a tworzenie przypadków użycia Czytaj dalej »

Przypadki użycia ułatwiają określenie celu i zakresu projektu

Wiele mówi się o tym co dają przypadki użycia dla wymagań na system. Warto jest tez wiedzieć iż przypadki użycia pozwalają, zwłaszcza w projektach agile, na określenie celu  i zakresu projektu. Zasadniczo bez przypadków użycia: Projektanci nie mają pojęcia, jaki cel ma użytkownik. Zespół nie zostaje poinformowany odpowiednio wcześnie o zakresie projektu. Różne zachowania użytkowników

Przypadki użycia ułatwiają określenie celu i zakresu projektu Czytaj dalej »

Scroll to Top