Modelowanie zakresu

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