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

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

Wymagania – Zarządzanie wersjami

Zmiany w wymaganiach wymaga ich wersjonowania.Wersje wymagań pomagają uzyskać dostęp do określonego stanu wymagania w trakcie życia oprogramowania. Najczęściej wersje 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 e-mail nie zostanie opublikowany.

Przewiń do góry