Po co są przypadki użycia? Zastanów się nad tym, zanim powiesz „nie, my tego nie potrzebujemy”. Najpierw poznanie potrzeb projektu i świadomość możliwości zastosowania przypadków użycia, a później decyzja.
Czasem „nie potrzebujemy”, bo mamy przecież świetny opis na 3 strony – trzymającą w napięciu ilustrowaną prozę z elementami zwrotów akcji, gdzie cele mieszają się z funkcjami systemu, szczegółowymi polami w bazie danych i propozycjami rozwiązań technicznych (czasem trafionych, czasem nie).
Ile z tym problemów w projekcie? Wiedzą ci, którzy przeżyli 😉 Miałam chwile zwątpienia, ale po kilku problemach, stwierdzam, że to ich właśnie zabrakło i nie ma sensu ich nie robić 🙂 Są przecież dość proste w przygotowaniu, a dają tyle możliwości.
Zastosowanie przypadków użycia
Jakie jest zastosowanie diagramu przypadków użycia i opisów przypadków?
- Specyfikacja wymagań funkcjonalnych
Określamy, co ma robić system.
- Walidacja wymagań
Sprawdzamy, czy te wymagania prowadzą do osiągnięcia postawionych przed projektem celów. I my i klient.
- Podstawia dla diagramów interakcji
Kiedy już wiemy, co ma system robić, możemy planować jak ma to robić.
- Projekt interfejsu użytkownika
Przypadki użycia to nic innego jak usługi świadczone przez system użytkownikowi. Mamy zatem określone wszystkie najważniejsze punkty interakcji system-użytkownik. Trzeba je teraz ładnie zaprojektować. Może to zrobić UX, skoro już wie, jakie informacje będą wymieniane.
- Projekt systemu
Skoro już wiemy, jakie informacje będą wymieniali system i człowiek, nic prostszego, jak zabrać się za projektowanie struktury systemu.
- Projekt testów i ocena rezultatów
Przypadki użycia doskonale nadają się do tego, by przełożyć je w prosty sposób na przypadki testowe dla testów akceptacyjnych. Wiemy, co system powinien robić, wystarczy teraz sprawdzić, czy to się dzieje i jest robione odpowiednio.
- Szacowanie pracochłonności projektu
Kiedy mamy zebrane przypadki użycia systemu, otrzymujemy wgląd w jego złożoność – czynności na podobnym poziomie abstrakcji. Możemy na diagramie ogarnąć je jednym rzutem oka. Stąd staje się on punktem wyjścia do określenia, jak bardzo złożony jest system i z jakim nakładem pracy wiąże się jego przygotowanie.
Źródła:
1. Bobkowska A. (2012): Inżynieria oprogramowania – Model przypadków użycia, Niepublikowane materiały, Politechnika Gdańska.
0 komentarze “Do czego Ci przypadki użycia?”
A kiedy wycena projektu? Można opisać w ten sposób wymagania projektu i wtedy przekazać do wyceny. Ale co w sytuacji, gdy taką analizę wykonuje dostawca zatrudniany tylko do tego projektu i jego zatrudnienie zależy od wyceny całości prac?
Wszystko zależy od sposobu pracy, który Ty przyjmujesz a Twój klient akceptuje. Na logikę – trudno wycenić coś, jeśli jeszcze nie wiemy, co mamy zrobić. Można przyjmować bardzo zgrubne założenia i do wyceny dorzucać bufor na
„niespodzianki”. Życie i projekty pokazują jednak jak często się potem okazuje, że i tego buforu nie starcza i jak bardzo nas projekt zaskakuje.
Jak klienta przekonać do takiego modelu prowadzenia projektu? Do mnie przemawia to zdanie: „trudno wycenić coś, zanim się wie, co jest do zrobienia”. Ale często klient mimo to chce znać jakąś cenę. Więc się jakąś przygotowuje, żeby klient nie odszedł do innej firmy, która nie będzie kręcić nosem na strzępki informacji i jakąś cenę mu poda.
Jak przekonać klienta do analizy przed projektem? Jest tu pewnie mnóstwo wyzwań, których mogę nawet nie brać pod uwagę, bo nie zajmuję się sprzedażą i pozyskiwaniem klientów. Zapytajmy sprzedawców.
Niektórzy twierdzą, że sprawdza się podawanie przedziałów, np. projekt zajmie od 3 miesięcy do 8. A klient na to „Aha, jeśli nie dłużej niż 2 lata, to biorę”. Z czasem doprecyzowujemy i szacujemy coraz dokładniej.
Inni mówią, że o analizę przed rozpoczęciem „roboty” sami proszą klienci „po przejściach”, jeśli się już sparzą na nieprzemyślanych projektach.
Szczerze, nie wiem dlaczego np. w branży budowlanej oczywiste jest, że przygotowuje się projekt, a później wycenia budowę, a w IT jest to nie do przeskoczenia. Klient po prostu przywykł do takiego trybu? Musimy się jeszcze uczyć w naszej branży na błędach, aż wypracujemy lepsze rozwiązania?
Jakbym był klientem i po zapytaniu o wycenę dowiedziałbym się od jednej firmy, ile projekt będzie kosztował, a od drugiej notatkę wyjaśniającą, że najpierw płaci się za analizę a potem za projekt, mógłbym stwierdzić, że:
a) Firma 1 jest bardziej doświadczona w tego typu projektach i już takie robiła wcześniej skoro taką szybką wycenę dostałem.
b) Firma 2 będzie chciała sięgnąć głębiej do mojej kieszeni. Teraz oprócz projektu chcą jeszcze opłat za analizę, ciekawe co będzie potem.
Co ciekawe klienci po przejściach również często nie chcą płatnej analizy, ponieważ mają wybór między taką firmą a dziesiątkami innych wyceniającymi bezpłatnie projekt. To, że jedna firma jest niekompetentna nie oznacza, że inna również taka będzie.
Kolejnym problemem jest cena projektów. Przy projekcie za kilkaset tysięcy (dom, mieszkanie) łatwiej zrozumieć, że trzeba za projekt zapłacić dodatkowo. Projekty informatyczne są często w dużo niższych przedziałach cenowych i trudniej przełknąć dodatkową kwotę na analizę.
Zauważalne jest to przy rozmowach – im droższy, większy projekt tym łatwiej wytłumaczyć, że jest potrzebna dokładniejsza analiza.
Poza tym w takich rozmowach głównie chodzi o sprzedawców. Dobry sprzedawca sprzeda g…. za cenę złota. Słaby sprzedawca złota nie opchnie nawet za cenę g….. Czyli charyzma, dobre podejście do klienta, zdobycie zaufania. Potem można działać zgodnie z regułami w które wierzymy, czyli np sprzedać analizę oddzielnie co nie będzie już takie trudne.
A najprościej jest wliczać takie analizy w koszta projektów, uśredniać czas i dokładać kwotę do ceny całościowej projektów zatwierdzonych. Klient który będzie chciał wykonać projekt i tak wtedy zapłaci za analizę swoją (i innych niestety).
a) Co to znaczy, że firma robiła podobny projekt? Jeśli to jest coś szalenie typowego, z półki, to rozumiem. Ale jak możesz dla firmy zrobić dedykowane oprogramowanie takie samo? To znaczy, że tak firma nam poda cenę czegoś co ma/może zrobić, po czym nam to wciśnie, bez względu na to, czego właściwie nam potrzeba. Dostaniemy to, co zamówił poprzednik, bez zastanawiania, czy to nam pomoże i nam odpowiada.
A jeśli nie wiesz dokładnie co masz zrobić, to jak to wycenisz? Z buforem bezpieczeństwa. Albo przyjmiesz jakieś założenia, które potem mogą się okazać niesłuszne i i tak trzeba będzie przeszacować i skasować.
Pytanie czy bardziej Ci zależy, żeby mieć jakąś wycenę czy wycenę rozsądnie bliską rzeczywistej.
b) Można nie wydzielać analizy z projektu i traktować wszystko jako całość. Podać jakieś widełki i powiedzieć, że dokładniej będziesz w stanie powiedzieć po czasie x spędzonym na analizie.
Co to znaczy wyceniać bezpłatnie projekt? Każesz ludziom wykonywać pracę, za którą nie dostaną wynagrodzenia? Muszą dostać, więc po prostu zrobisz narzut na wycenę realizacji czy czegoś tam.
I celem nie jest wycena „za kasę wycenię”, ale już dostajesz za to analizę – im bardziej dokładna i zaawansowana, tym większe prawdopodobieństwo, że dostaniesz to, czego chcesz. Ile czasu się traci na poprawki na końcu, kiedy się okazuje, że to nie miało być tak?
P.S. Ale długaśny komentarz, Łukasz 🙂
Wszystko zależy od sposobu pracy, który Ty przyjmujesz a Twój klient akceptuje. Na logikę – trudno wycenić coś, jeśli jeszcze nie wiemy, co mamy zrobić. Można przyjmować bardzo zgrubne założenia i do wyceny dorzucać bufor na „niespodzianki”. Życie i projekty pokazują jednak jak często się potem okazuje, że i tego buforu nie starcza i jak bardzo nas projekt zaskakuje.
Jak klienta przekonać do takiego modelu prowadzenia projektu? Do mnie przemawia to zdanie: „trudno wycenić coś, zanim się wie, co jest do zrobienia”. Ale często klient mimo to chce znać jakąś cenę. Więc się jakąś przygotowuje, żeby klient nie odszedł do innej firmy, która nie będzie kręcić nosem na strzępki informacji i jakąś cenę mu poda.
Jak przekonać klienta do analizy przed projektem? Jest tu pewnie mnóstwo wyzwań, których mogę nawet nie brać pod uwagę, bo nie zajmuję się sprzedażą i pozyskiwaniem klientów. Zapytajmy sprzedawców.
Niektórzy twierdzą, że sprawdza się podawanie przedziałów, np. projekt zajmie od 3 miesięcy do 8. A klient na to „Aha, jeśli nie dłużej niż 2 lata, to biorę”. Z czasem doprecyzowujemy i szacujemy coraz dokładniej.
Inni mówią, że o analizę przed rozpoczęciem „roboty” sami proszą klienci „po przejściach”, jeśli się już sparzą na nieprzemyślanych projektach.
Szczerze, nie wiem dlaczego np. w branży budowlanej oczywiste jest, że przygotowuje się projekt, a później wycenia budowę, a w IT jest to nie do przeskoczenia. Klient po prostu przywykł do takiego trybu?
Określenie Wymagań Biznesowych, User Stories – ich priorytetyzacja a następnie spisanie głównych funkcjonalności (na poziomie bardzo ogólnym) – przy projekcie średniej wielkości (prace 3-6 miesięcy) – mozemy zrobic w jakies 6-8h (przy prawnym zespole). Na tej podstawie mozemy dokonać wyceny z marginesem błędu 20-30%.
Jest to poziom akceptowalny zarówno przez klienta jak i przez wykonawce. Moim zdaniem za taką wycene nie powinna być brana żadna opłata. Ta wycena jest zarówna dla klienta jak i dla nas (wyceniających) – musimy wiedziec ile będzie kosztowac nasz praca.
To tak jak idziemy do mechanika, czy zamawiamy ekipe do szpachlowania ścian – dokonywana przez nich wycena jest darmowa. Mechanika który by ządał 100 zł za sam fakt czy podejmie naprawy samochodu omijałbym dalekim łukiem.
Oczywiście nie musicie się ze mną zgadzać.
Oskar, wszystko zależy od projektu – jego cech. Nie zapominajmy, że każdy z nas może pracować przy całkiem innych projektach.
Są projekty od stronek-wizytówek, przez stronki z bazką, do systemów tranzakcyjnych i mających wspierać i usprawniać pracę całych organizacji.
Dalej – mamy projekty:
których celem jest szybkie dostarczenie produktu lub stabilności (coś musi być robione w określony sposób, bez najmniejszych odchyleń)
małe (mało osób) i proste lub duże (ogromna liczba osób po jednej i po drugiej stronie – komplikacja podejmowania decyzji, komunikacji, zmian, wspólnej pracy) i skomplikowane
zmienne, skupione na produkcie (niech się przetestuje, rozwija i zmienia) lub niezmienne, skupione na organizacji (dopasowanie do jej działania)
czasem klient ma dla nas czas (dobra relacja z klientem, klient wewnętrzny(!!)), czasem nie ma (sporadyczny kontakt i zaufanie oparte na umowach, komunikacja oparta na dokumentacji, bardzo wiele osób po stronie klienta, z którymi ustalenia nie mogą być „zapamiętane” czy zapisane 1 zdaniem)
czasem system wymaga dokładnego testowania, określonych i pilnowanych procedur, czasem nie, bo się ewentualnie kiedyś poprawi, jeśli ewentualnie to komuś będzie przeszkadzało
Tutaj pisałam o tym trochę (o różnicach między projektami) – https://analizait.pl/2012/jak-nie-puscic-firmy-z-torbami/
W prostych projektach, podobnych do siebie, wykonywanych w podobnej technologii, w podobnym środowisku, w podobnym zespole – jasne – wyceńmy to szybko, na podstawie analogii. U Ciebie sprawdza się ustalanie wszystkiego w 8h i oszacowanie jest bardzo dokładne.
Są jednak projekty, gdzie w 8h ma miejsce zebranie zespołu, ustalenie celów organizacji, czasem nieoczywistych i czasem niejednakowych dla wszystkich, podejmowanie decyzji, ustalanie wizji. Dopiero jak znamy zamierzone efekty, możemy planować sposób dojścia do niego i proponujemy funkcje, które będą wspierać cel, na poziomie haseł (np. zarządzanie mailingiem – co może znaczyć wiele i być wycenione na 4h jak i 4 tygodnie pracy). Doprecyzowanie może się ciągnąć tygodniami czy nawet miesiącami.
W złożonych przypadkach ja bym się nie podjęła zebrać ustalenia i spisać wymagania w 8h.
Porównanie do mechanika mi bardziej pasuje do przyjścia do kogoś, kto serwisuje strony oparte na CMSach czy frameworkach, z którymi mógł się zapoznać wcześniej – np. zmiany w joomli, drupalu, word pressie, (różne modele samochodów). Takiej osobie, podobnie jak mechanikowi samochodowemu, wystarczy spojrzeć na coś przez chwilę, by wiedzieć jakiego rzędu koszt pociągnie za sobą zmiana.
Szpachlowanie ścian ma jeden, góra dwa parametry (powierzchnia ścian, ew. struktura). IMO dedykowane systemy informatyczne, w których możemy stworzyć „wszystko”, są nieporównywalnie bardziej skomplikowane.
A jeśli chodzi o sprzedawanie analizy, to nie oznacza dostać odpowiedź typu „5”, ale produktem jest dokument – zapis ustaleń, celów, sposobów realizacji – to jest wytyczna, która posłuży do wykonania systemu, a więc da większą pewność, że nikt nie wypaczy tego po drodze (zrobi to, co jest potrzebne zamawiającemu) i skróci czas wykonawcy na zastanawianiu się, co zrobić, planowaniu tego, co zrobić, jak to zrobić (na poziomie koncepcji) i uspokoi ich, że wiedzą, co jest do zrobienia, więc nie trzeba tworzyć wielkiego buforu niepewności w wycenie na nieprzewidziane okoliczności.