Modelowanie zakresu

9 marca 2012

Ile znasz rzeczy w projektach gorszych od zmiany zakresu? Według badań PMI to najczęstsza przyczyna niepowodzeń! Problemy te występują w prawie 60% projektów. Co możesz zrobić, by uchronić się przed kłopotami? Jasno określ zakres!

Model zakresu daje podstawę do określenia ram analizy i/lub pracy w projekcie i może być punktem wyjścia w ocenie ich rozmiarów. Dzięki ustalonemu zakresowi łatwiej ustalić, czy pojawiająca się kwestia ma być uwzględniona czy też znajduje się poza zakresem (co może znacznie ułatwić pracę i ograniczyć pracę niepotrzebną).

Różne sposoby

Istnieje kilka sprawdzonych technik modelowania zakresu. BABOK [2] wyróżnia:

  • Diagram kontekstu,
  • Zdarzenia,
  • Procesy biznesowe,
  • Diagram przypadków użycia,
  • Lista funkcji.

 Diagram kontekstu

Diagram kontekstu przedstawia w ujęciu wysokopoziomowym przepływ danych – do i od obiektów zewnętrznych. Przykładami takich obiektów mogą być zewnętrzne systemy, instytucje. Dzięki temu określone zostaje jakie dane są pozyskiwane z zewnątrz lub wysyłane na zewnątrz (poza zakresem), a co będzie działo się wewnątrz systemu (w zakresie).
Diagram kontekstu można przedstawiać w notacjach:

  • Diagram przepływu danych (Data Flow Diagram) [4],
  • Gane-Sarson [5],
  • Yourdon [6],

lub nieformalnie:

  • Rich Picture [7],
  • Nieformalne diagramy z obrysem zakresu.

Zdarzenia

System rozumieć można jako obiekt obsługujący wybrane zdarzenia mające miejsce w rzeczywistym świecie. Efektem analizy określonej dziedziny (obszar problemowy) może być lista powiązanych zdarzeń. Określenie zakresu polega na wybraniu tych zdarzeń, które system będzie obsługiwał (w zakresie) i tych, które nadal będą przebiegały całkowicie w świecie rzeczywistym i nie będą wspierane (poza zakresem). Zdarzenia przebiegają na granicy rozpatrywanego rozwiązania – mają swoje źródła lub miejsca przeznaczenia w obiektach zewnętrznych (patrz -> diagram kontekstu). Mogą być one także efektem działania reguł biznesowych (wyzwalanych w określonym czasie).
Kroki określania zakresu:

  1. Identyfikacja zdarzeń mających miejsce na granicy rozpatrywanego rozwiązania
  2. Wybranie zdarzeń obsługiwanych przez rozwiązanie
  3. Określenie reakcji na zdarzenie – listy czynności wykonywanych w celu jego obsłużenia – czyli procesu biznesowego.

 
Przykład:
Zdarzenie: Zgłoszenie zamówienia
Proces:

  1. Przyjęcie zamówienia (w systemie)
  2. Skompletowanie pozycji zamówienia (poza systemem)
  3. Przygotowanie paczki (poza systemem)
  4. Wysłanie zamówienia (poza systemem)
  5. Zmiana statusu zamówienia – widoczna dla klienta (w systemie)

Procesy biznesowe

Zamodelowany wysokopoziomowy proces biznesowy pozwala określić, które elementy rozwiązania będą go wspierać, a które nie. Na tej podstawie może powstać rozróżnienie – „w zakresie” lub „poza zakresem”.
Istnieje kilka możliwości modelowania procesów biznesowych. Najbardziej znane i najczęściej wykorzystywane [3]:

  • Diagram aktywności UML,
  • BPMN,
  • Niesformalizowane schematy blokowe (nie polecam),
  • Opisy (samych nieformalnych opisów nie polecam jeszcze bardziej z powodu niekompletności i braku jednoznaczności).

Więcej o procesach biznesowych już niedługo 😉

Diagram przypadków użycia

Diagram przypadków użycia (zapraszam do -> wpisu na ten temat) przedstawia wizualnie wszystkie główne usługi świadczone przez system użytkownikom. Na jego podstawie można określić czy rozpatrywana kwestia wpisuje się gdzieś w ten układ:

  • jest zawarta w którymś z przypadków użycia,
  • jest powiązana z którymś przypadkiem użycia,
  • jest wykonywana przez któregoś z aktorów w ramach tego systemu.

Lista funkcji

Funkcja (nie funkcjonalność (!), która to jest jednym z wymagań jakościowych) to usługa świadczona przez system, spełniająca jedną lub wiele potrzeb udziałowców. Zazwyczaj określana jest hasłem, które powinno znaleźć swoje rozwinięcie w szczegółowym opisie wymagania lub grupy wymagań. Lista funkcji pozwala łatwo uchwycić zakres rozwiązania. Jest chyba najczęściej spotykanym sposobem opisu zakresu (także w metodykach zwinnych – Agile). Przydaje się w uzgodnieniach na linii klient – dostawca odnośnie zakresu, priorytetów, przy tworzeniu harmonogramu i rozdzielaniu zadań.
 
Źródła:

  1. Gdański oddział PMI (2010): Badanie dojrzałości projektowej firm z północnej Polski, [on-line]. Dostępne: http://www.gdansk.pmi.org.pl/download/Z2Z4L2dkYW5zay9wbC9kZWZhdWx0X29waXN5LzM5LzEvMQ/badanie_dojrzalosci_wyniki_1_1.pdf
  2. International Institute of Business Analyst IIBA, A Guide to the Business Analysis Body of Knowledge® (BABOK® Guide), Version 2.0, 2009.
  3. Żeliński J.: Zagłosuj i poznaj zdanie innych (Jakiej notacji używa się w organizacjach w analizach i projektach), [on-line]. Dostępne: http://it-consulting.pl/autoinstalator/wordpress/zaglosuj-i-poznaj-innych/
  4. http://www.yourdon.com/strucanalysis/wiki/index.php?title=Chapter_9
  5. SmartDraw: Software Design Tutorials – Data Flow Diagram Notations, [on-line]. Dostępne: http://www.smartdraw.com/resources/tutorials/data-flow-diagram-notations/
  6. SmartDraw: Software Design Tutorials – Common Yourdon & Coad Notations, [on-line]. Dostępne: http://www.smartdraw.com/resources/tutorials/yourdon-and-coad-notations/
  7. https://internal.shenton.wa.edu.au/ITResources/12InformSys/Information%20Systems/PDFs/Rich%20Pictures.pdf

Cześć, jestem Hania.

Jako strategiczny analityk biznesowy na pograniczu zarządzania i IT zapewniam, że projekty i działania w organizacji przynoszą wartość biznesową. Dostarczam kompetencji analitycznych managerom i zarządom z Polski, Niemiec i Szwajcarii przy tworzeniu strategii oraz wdrażaniu jej w kilkuset osobowej międzynarodowej organizacji.

Może zaciekawi Cię także:

www.analizait.pl by ProjectUP (C) 2020