Use Case

Read more about the article Ile scenariuszy ma Use Case i dlaczego nie jeden?

Ile scenariuszy ma Use Case i dlaczego nie jeden?

Wprowadzenie Bardzo często na szkoleniach, a także na zajęciach laboratoryjnych z przedmiotu Inżynieria oprogramowania, jestem pytany o przypadki użycia i ich scenariusze. Szczególnie często pada pytanie czy przypadek użycie reprezentuje tylko jeden scenariusz. Przypadki użycia w UML to "dzieło" Ivara Jacobsona . Pierwotnie było to narzędzie do opisu zewnętrznych cech (zachowań) systemu, rozumianych jako jego oczekiwane zachowania, czyli wymagania wobec systemu. Był to tak zwany "opis czarnej skrzynki". Problemem było to, że "czarna skrzynka" mówi CO ale nie mówi JAK. Jacobson opisywał przypadki użycia z pomocą warunków (stanów początkowego i…

Czytaj dalejIle scenariuszy ma Use Case i dlaczego nie jeden?
Read more about the article User Story to wymaganie biznesowe, to opis problemu do rozwiązania, a nie funkcjonalność do implementacji!

User Story to wymaganie biznesowe, to opis problemu do rozwiązania, a nie funkcjonalność do implementacji!

Wprowadzenie

O user story pisałem nie raz od ponad dekady, i w zasadzie zawsze powodem jest to samo: kolejny ratowany projekt, gdzie powodem dramatu było stosowanie user story jako wymagań. Kiedy user story jest stosowane jako wymaganie? W zasadzie zawsze tam, gdzie pominięto etap analizy i projektowania. Jakie są skutki? Kilkukrotnie wyższa pracochłonność, czyli znacznie wyższe koszty i dłuższy termin dostarczenia oprogramowania. Niestety, nie raz, tak realizowane projekty kończą się wstrzymaniem prac zanim powstanie pełna funkcjonalność aplikacji, z powodu znacznego przekroczenia budżetu i terminu.

Co proponuję? To co proponuję wielu doświadczonych praktyków na świecie:

Proces MBSE powstawania systemu
(więcej…)

Czytaj dalejUser Story to wymaganie biznesowe, to opis problemu do rozwiązania, a nie funkcjonalność do implementacji!
Read more about the article Jakie przypadki użycia ma poczta a jakie szafa grająca

Jakie przypadki użycia ma poczta a jakie szafa grająca

Myślenie systemowe Najprostsze rzeczy bywają najtrudniejsze w modelowaniu, powodem jest ich "pozorna" prostota. Na wielu uczelniach na świecie zaczęły sie pojawiać studia podyplomowe i szkolenia o wdzięcznym tytule "Myślenie systemowe" (System Thinking, np. to na MIT), ich celem jest kształtowanie myślenia zorientowanego na postrzeganie świata jako systemu czyli mechanizmu złożonego z współpracujących obiektów. Tu pojawia się stosowane w nauce pojęcie "mechanizm" . Po co i kiedy używamy tego pojęcia? "Mechanizmów poszukuje się w celu wyjaśnienia, jak powstaje jakieś zjawisko lub jak działa jakiś istotny proces." . Innymi słowy analizując lub…

Czytaj dalejJakie przypadki użycia ma poczta a jakie szafa grająca
Read more about the article Diagram Przypadków Użycia UML

Diagram Przypadków Użycia UML

Wprowadzenie Jest to diagram, który na równi z Diagramem Klas, budzi bardzo często ogromne problemy interpretacyjne (patrz: Diagram klas...). Bardzo wielu autorów przypisuje temu diagramowi role, których on nie pełni, a nie raz prezentowane w sieci i literaturze przykłady są niepoprawne. Znakomita większość autorów tych diagramów używa ich jako "zbioru możliwych kliknięć" co jest całkowitym niezrozumieniem celu użycia i idei tego diagramu. Nawet jeżeli ktoś potrzebuje takiej mapy klikania, to są do tego lepszych narzędzia i metody (przykład: Mapa ekranów aplikacji ? podstawa dobrego UX/UI design). Tworzenie niezgodnych z notacją…

Czytaj dalejDiagram Przypadków Użycia UML
Read more about the article Paradygmat obiektowy i Przypadki Użycia

Paradygmat obiektowy i Przypadki Użycia

Przypadki użycia w notacji UML1 to jedna z najstarszych metod dokumentowania wymagań i nadal budzi wiele kontrowersji w kwestii ich poprawnego użycia. Obiektowy paradygmat i pojęcie systemu Słownik j.polskiego mówi: paradygmat ?przyjęty sposób widzenia rzeczywistości w danej dziedzinie, doktrynie itp.? obiekt ?rzecz abstrakcyjna, np. cecha lub pojęcie?, ?przedmiot, który można zobaczyć lub dotknąć? system ?układ elementów mający określoną strukturę i stanowiący logicznie uporządkowaną całość?, ?zespół wielu urządzeń, dróg, przewodów itp., funkcjonujących jako całość? Ludwig von Bertalanffy w swojej Ogólnej Teorii Systemów?2? określa system: stanowiący określoną całość byt, złożony z mających interakcje elementów. Pojęciami powiązanymi są tu…

Czytaj dalejParadygmat obiektowy i Przypadki Użycia
Read more about the article Use Case 2.0

Use Case 2.0

Wprowadzenie Właśnie zostałem zapytany: Witam Pana, czy interesował się Pan Use Case 2.0 ? Tak. Od czasu do czasu wpadają mi w ręce takie opisy. Ta idea jest ciekawym i pragmatycznym podejściem do etapu dokumentowania zakresu projektu. Warto jednak pamiętać, że przypadki użycia mają swój kontekst (są osadzone) w tym co robią użytkownicy, bez tego kontekstu są niestety ryzykownym narzędziem, bo deklaratywnym (skąd wiemy, że osoba A ma coś robić skoro nie wiemy jak wygląda cały proces biznesowy, czy mamy polegać tylko na subiektywnej deklaracji tej osoby?). Dość często spotykam…

Czytaj dalejUse Case 2.0
Read more about the article UML a modelowanie procesów biznesowych

UML a modelowanie procesów biznesowych

Niedawno pisałem o UML v.2.51 i zasygnalizowałem, że diagram aktywności daje kontekst dla pojęć z grupy ?activities? (aktywności i czynności oraz ich syntaktyczne asocjacje), diagram klas daje kontekst  dla ?klasyfikatorów strukturalnych?, itd. (Źródło: UML version 2.5 | | Jarosław Żeliński IT-Consulting) Dzisiaj kilka słów na temat modelowania procesów biznesowych w UML. Cztery lata temu poruszałem temat użycia UML do modelowania procesów biznesowych z użyciem modelu Eriksson-Penker'a: Można się także dość często spotkać z definicją sześcioelementową Erikssona-Penkera ([[Eriksson-Penker Business Modeling Profile]]). Tu mamy: Powyższy model bazuje na uznaniu, że proces biznesowy: ma cel, ma specyficzne…

Czytaj dalejUML a modelowanie procesów biznesowych
Read more about the article Transformacja modelu procesów biznesowych na model przypadków użycia

Transformacja modelu procesów biznesowych na model przypadków użycia

Wprowadzenie Ukazują się różne opracowania na temat tytułowej transformacji. Jednym z takich opracowań jest tekst Transformacja Modeli Pana Piotra Carewicza z firmy 300 D&C, opublikowany w periodyku Analiza Biznesowa  Lato 2015 firmowanym przez Warszawski oddział IIBA. Pozwolę sobie na pewną polemikę z przedstawionym tam  procesem transformacji modelu procesów biznesowych BPMN na Przypadki Użycia notacji UML. Autor powołuje się na OMG.org i specyfikacje BPMN i UML. Dlatego dla porządku przytoczę kluczowe definicje. 10.3 ActivitiesAn Activity is work that is performed within a Business Process. An Activity can be atomic or non-atomic(compound). The types…

Czytaj dalejTransformacja modelu procesów biznesowych na model przypadków użycia
Read more about the article Przypadki użycia nie znają swoich realizacji…

Przypadki użycia nie znają swoich realizacji…

Tak wiec pisząc "Krowa z silnikiem odrzutowym, jelita na czerwono, jądrowymi kopytami, wyprawiona na buty skóra, zniszczyła metro, wypadek samochodowy, przelatując nad Warszawą, liczba płyt chodnikowych to 1347, a następnie wylądowała w Elektrociepłowni Żerań, załadunek węgla w południe wykonany przez Kowalskiego, i pożywiła się węglem popijając wodę z Wisły" to poprawne gramatycznie, bezbłędnie napisane zdanie w języku polskim, ale nikt nie ma chyba wątpliwości, że kompletnie pozbawione sensu. Tak samo można poprawnie, zgodnie z zasadami notacji, narysować diagram UML ...

Czytaj dalejPrzypadki użycia nie znają swoich realizacji…
Read more about the article Architektura oprogramowania i UML dla programistów

Architektura oprogramowania i UML dla programistów

Gorąco polecam programistom, by w ogóle zaczęli korzystać z UML a analitykom, by wyleczyli się z wielu mitów o UML rozpowszechnianych niestety na wielu, nie zawsze tanich, szkoleniach i w wielu kiepskich "poradnikach UML" (pisanych nie raz nawet przez uczelnianych doktorów i nie tylko)..... Może wtedy przestaną tworzyć nieprzydatne developerom dokumentacje.

Czytaj dalejArchitektura oprogramowania i UML dla programistów
Read more about the article Visual-Paradigm czyli pokaż czym pracujesz a powiem Ci kim jesteś…

Visual-Paradigm czyli pokaż czym pracujesz a powiem Ci kim jesteś…

Pakiet którego używam (Visual-Paradigm) po ostatnich zmianach ma szanse stać się w moich oczach ideałem :).  O jego nowej wersji pisałem tu: Visual-Paradigm v.11.1. Pisałem tez, że jest w 100% zgodny ze specyfikacjami notacji zarządzanych przez OMG, co jest bardzo ważne. Tu zwrócę uwagę na kilka przydatnych cech. Moim zdaniem cechą dobrego projektu jest nie tylko dobra metodyka ale także to czy dysponujemy narzędziami, które ją wspierają. Tymi narzędziami są nie tylko notacje i systemy pojęciowe ale także oprogramowanie CASE, które powinno spełniać trzy kluczowe warunki: wspierać (a przynajmniej nie ograniczać) metodykę,…

Czytaj dalejVisual-Paradigm czyli pokaż czym pracujesz a powiem Ci kim jesteś…
Read more about the article Visual Paragim Agilian 11.0

Visual Paragim Agilian 11.0

Pojawiła się oczekiwana wersja 11 pakietu CASE firmy Visual-Paradigm. Przede wszystkim rozwój produktu idzie w kilku głównych kierunkach: wsparcie dla wizualnego projektowania aplikacji (mock-up'y, kolejne ułatwienia w tworzeniu i integrowaniu modeli UML), stały rozwój wsparcia dla architektury korporacyjnej (to narzędzie pozwala tworzyć modele powiązane ze sobą, pozwala na prowadzenie analiz wpływu i wielu innych, wspiera także notację ArchiMate) oraz na prawdę bardzo silne wsparcie dla pracy grupowej. Co dzisiaj ogłasza producent: Visual Paradigm International Limited today [16.12.2013] announced the release of Agilian (AG) 11.0, a Visual Modeling tool for Agile…

Czytaj dalejVisual Paragim Agilian 11.0

Koniec treści

Nie ma więcej stron do załadowania

Starsze wpisy