Trzy korzyści z przypadków użycia

Każdemu zalecam stosowanie przypadków użycia ? także a może przede wszystkim w projektach Agile.

Poniżej zamieszczam trzy podstawowe zalety, które myślę, że przekonają do używania przypadków użycia w projektach Agile

1. Dzięki przypadkom użycia zyskuje się kontekst

Nawet w projektach Agile przypadki użycia są mechanizmem umożliwiającym firmom osiąganie celów. Podejście, które wykorzystuje ustrukturyzowane wymagania dostarcza ten kontekst. Innymi słowy przypadki użycia pozwalają określić z jakimi systemami lub innymi zasobami będzie współpracował nasz system.

2. Dzięki przypadkom użycia zyskuje się informacje dot. zakresu projektu

Z politycznego punktu widzenia największym problemem z uruchomieniem projektu Agile w organizacjach typu waterfall jest niewłaściwe ustalenie oczekiwań wobec projektu w zakresie jego trwania i kosztów. Ustalenie oczekiwań i w ten sposób zabezpieczenie zarówno finansowania jak i wsparcia dla projektu może być ważniejsze niż samo wykonanie.

Ustalanie zakresu polega przede wszystkim na ustalaniu priorytetów celów osób zamawiających produkt oraz ustaleniu ram czasowych i harmonogramów dostarczania.

Kluczem jest tutaj dokonanie wpierw przeglądu zakresu projektu, a potem jego dokładne zrozumienie poprzez przeprowadzanie iteracji.

3. Dzięki przypadkom użycia zyskuje się naturalną dekompozycję

Właściwym podejściem do definiowania przypadków użycia dla tworzenia oprogramowania przy użyciu metody Agile to zacząć od definicji zakresu. Kiedy już zakres zostanie zdefiniowany należy zdefiniować nazwy przypadków użycia a następnie stopniowo nadawać priorytety i definiować bardziej szczegółowo przypadki użycia podczas gdy są one włączane do harmonogramu projektu. Dokonujesz także refaktoryzacji przypadków użycia, w miarę potrzeb konsolidując i definiując podrzędne przypadki użycia, oraz definiując, jeśli zachodzi taka potrzeba, rozszerzeń przypadków użycia.

Technorati Tagi: agile modeling,przypadki użycia

Podobne wpisy

  • Pisanie user story i scenariuszy przypadków użycia User story to opis celów zorientowanych na użytkownika, jakie jedna lub więcej osób osiągnie za pomocą Twojego produktu. User stories używa się do osiągnięcia celu zawsze wtedy, kiedy jest […]
  • Prototyp a przypadek użycia Specyfikacja wymagań na system to trudny moment przede wszystkim dla osób, które muszą je wyspecyfikować. Nie zawsze wiadomo w jaki sposób narzędzia informatyki będą mogły pomóc. Często […]
  • 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 […]
  • Jak opisywać przypadki użycia? Opisując przypadki użycia stosuję kilka poziomów ich opisu. Najpierw identyfikuję aktorów i przypadki użycia potem dla każdego przypadku użycia opisuje punkty końcowe i początkowe by […]
  • Specyfikacja systemu a przypadki użycia Na jednym ze spotkań z klientem otrzymałem pytanie: Czy przypadki użycia są jedyną formą specyfikacji systemu? Moja odpowiedź była jasna: NIE. Przypadki użycia są niewątpliwie pożyteczne […]
Reklama

1 thought on “Trzy korzyści z przypadków użycia”

  1. Jacek Rybicki

    Dzięki przypadkom użycia (lub user stories) uzyskujemy szkielet testów. Nie tylko dekompozycję przestrzeni testów i ich systematyzację. Poprzez analizę powiązań przypadków użycia (np. z regułami biznesowymi) można wskazać więcej istotnych przypadków testu.

    Kiedyś rozważałem możliwość utrzymywania tylko dokumentacji testu. Prypadki użycia dawały mi zbyt duży margines błędu przy szacowaniu kosztów. Z np. 25 przypadków użycia można wygenerować i 200 i 700 przypadków testu, w zależności od skomplikowania systemu. Z drugiej strony taką dużą grupą testów trudniej się operuje.

    Dlatego rozwiązanie a) akceptowalne przez klientów b) „agilne”, to model projektu (w Enterprise Architect) stale synchronizowany z chmurą testów, utrzymywanych jako skrypty.
    Niestety, z różnych względów, nie mogę dokumentów generować automatycznie z EA i dokument, stanowiący bazę do rozmów z klientem, jest utrzymywany „ręcznie”.

Leave a Comment

Twój adres email nie zostanie opublikowany. Pola, których wypełnienie jest wymagane, są oznaczone symbolem *