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 email nie zostanie opublikowany. Pola, których wypełnienie jest wymagane, są oznaczone symbolem *

Może zaciekawi Cię także:

www.analizait.pl by ProjectUP (C) 2020