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
Zarządzanie relacjami pomiędzy wymaganiami

Zarządzanie wymaganiami to ważny element procesu wytwórczego oprogramowania. Jednym z jego elementów budowanie i zarządzanie relacjami pomiędzy wymaganiami. Najczęściej spotykanym więcej

Architektura procesów biznesowych a modelowanie procesów biznesowych – poziomy modelowania

W poprzednim wpisie Modelowanie procesów biznesowych w procesie wytwórczym oprogramowania opisałem znaczenie modelowania procesów biznesowych. W moim odczuciu, modelowanie procesów biznesowych więcej

Wymagania są najważniejsze

Podczas mojej pracy zauważyłem, że spory problem stanowią wymagania. Trudnością nie jest ich spisanie. Trudnością jest ich wyartykułowanie. Pomijam turbulencje związane więcej

Plan zarządzania wymaganiami

Plan zarządzania wymaganiami to dokument, który opisuje zasady postępowania z wymaganiami. W moim odczuciu to jeden z najważniejszych dokumentów, gdyż więcej

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. Wymagane pola są oznaczone *

Przewiń do góry