Przypadki użycia są łatwiejsze do zrozumienia niż diagramy BPMN

Jakiś czas temu napotkałem ciekawe wyniki badań, które zostały opracowane w Polsce. Instytut Informatyki Politechniki Poznańskiej wykonał badania, w których  celem było znalezienie odpowiedzi na pytanie: jaka reprezentacja wymagań: tekstowa, czy graficzna, jest lepsza z punktu widzenia stopnia zrozumienia przez osoby je czytające?
Jako reprezentanta podejścia tekstowego wybrano przypadki użycia. Natomiast dla notacji graficznej wybrano zapis BPMN,  który przypomina UML, lecz jest tworzony z zamiarem opisu modeli biznesowych. Uczestnikami eksperymentu byli studenci 4-tego roku Inżynierii Oprogramowania oraz Gospodarki Elektronicznej.

Eksperyment składał się z następujących kroków:

  1. Wykładu wprowadzającego do konkretnej notacji (90 minut).
  2. Ćwiczeń w trakcie których studenci otrzymali wysokopoziomowy zapis procesów PRINCE2 wyrażonych w danej notacji, zawierającej celowo posiane błędy. Zadaniem studentów było ich znalezienie. Dokument miał 5 stron, natomiast etap ćwiczeń trwał 90 minut.
  3. Eksperyment, który przebiegał w podobny sposób jak ćwiczenia. Tym razem jednak zmieniona została dziedzina biznesowa. Zamiast procesu PRINCE2, studenci otrzymali model biznesowy opisujący regulamin studiów (zaliczanie semestrów, zdawanie egzaminów, egzamin dyplomowy, itp.). Studenci w ciągu godziny musieli znaleźć wszystkie możliwe błędy.

Jako stopień zrozumienia wymagań przyjęto liczbę znalezionych błędów w dokumencie (DDR).

W wyniku przeprowadzanych eksperymentów zaobserwowano, że DDR dla przypadków użycia był wyższy niż dla diagramów BPMN i wynik był istotny statystycznie (na poziomie istotności 0,05). Uzasadnia to następujące przypuszczenie: przypadki użycia są łatwiejsze do zrozumienia niż diagramy BPMN.
Lepiej zatem wyrażać modele biznesowe korzystając z przypadków użycia.

Technorati Tagi: przypadki użycia,UML,diagramy BPMN,diagramy,wymagania na system

Podobne wpisy

  • 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 […]
  • 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 […]
  • 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 […]
  • Złote reguły towarzyszące przypadkom użycia ?Złote reguły? to nic innego jak wykaz punktów, które zazwyczaj kontroluję podczas tworzenia przypadków użycia. Gdy mam już narysowany przypadek użycia sprawdzam czy: przypadek użycia […]
  • Prototyp a przypadek użycia Specyfikacja wymagań na system to trudny moment przede wszystkim dla osób, które muszą je wyspecyfikować. Nie zawsze wiadomo w jaki sposób narzędzia informatyki będą mogły pomóc. Często […]
Reklama
MODESTO - licencje Enterprise Architect

2 komentarze dla “Przypadki użycia są łatwiejsze do zrozumienia niż diagramy BPMN”

  1. moje uwagi:
    – porównanie BPMN i UC to jakieś nieporozumienie, po pierwsze UC to specyfikacja a nie przeływy jak w BPMN po drugie BPMN nie służy do specyfikowania niczego a do modelowania zjawisk.

    W metodyce która z powodzeniem: model procesow (np. BPMN) służy do udokumentowania i weryfikacji (audyt) tego co sie w organizacji dzieje. Diagram UC to lista czynności zz modelu procesów wybranych do zakresu projektu. I co tu porównywać?

  2. Porównanie dotyczyło tego co jest łatwiej czytać. Z przytoczonych przeze mnie badań wynika, że to UML jest techniką, która jest łatwiej przyswajalna.

Zostaw komentarz

Twój adres email nie zostanie opublikowany. Pola, których wypełnienie jest wymagane, są oznaczone symbolem *

Przewiń do góry