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.

Komentarze - 9

  1. Alan

    Rozumiem, że problemy z zakresem występują w 60% *wszystkich* projektów. A jak przekłada się to na niepowodzenia? Ile niepowodzeń (statystycznie) wynika z problemów z zakresem, a ile % udanych projektów miało te problemy (i sobie poradzili)?
    To nie do końca na temat, ale zaciekawiła mnie ta statystyka. 😛

    1. Hania

      Zdaje mi się, że odpowiedzi na Twoje pytanie nie udzieli to konkretne badanie PMI (nie było tego w zakresie). Nie natknęłam się nigdzie na wnioski, które Cię zainteresowany. Jeśli znajdziesz, daj znać! 🙂

    2. Hania

      Alan, natknęłam się na ciekawe badanie info.jamasoftware.com/acton/attachment/1511/f-000f/0/-/-/-/-/file.pdf (cały blog tej firmy jest świetny). Jego opis jest na blogu http://workflow.com.pl/ wraz z innymi ciekawymi artykułami. Może znajdziesz coś interesującego dla siebie 🙂

  2. Adam

    Opisane narzędzia pozwalają określić zakres, tak aby się on nie zmieniał. Ja jestem zdania, że nie ma takiej możliwości żeby w rocznym projekcie nie zmienił się zakres. Oczywiście możemy się trzymać wcześniejszych ustaleń, ale czy taki projekt ma jeszcze sens, tego już nie jestem pewien, bo co z tego że zrobimy wszystko na czas skoro firmie już nie będzie to potrzebne w takiej postaci.
    Zaznaczam, że głównie praktykę mam w IT.

    1. Hania Wesołowska

      Czy podważa Pan zasadność samego modelowania zakresu czy chce Pan powiedzieć, że zna inne sposoby bardziej dostosowane do zmian?

Dodaj komentarz

Twój adres e-mail nie zostanie opublikowany. Wymagane pola są oznaczone *

Może zaciekawi Cię także:

www.analizait.pl by ProjectUP (C) 2020