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

  • Specyfikacja systemu a przypadki użycia Na jednym ze spotkań z klientem otrzymałem pytanie: Czy przypadki użycia są jedyną formą specyfikacji systemu? Moja odpowiedź była jasna: NIE. Przypadki użycia są niewątpliwie pożyteczne […]
  • 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 […]
  • 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 […]
  • 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 […]
Reklama

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 *