Analiza biznesowa
Agenda Cele projektu Wizja projektu Modelowanie biznesowe Wymagania użytkownika Przypadki użycia
Cele projektu
Cechy SMART S Specific Precyzyjne M Measurable Mierzalne A Agreed To Zaakceptowane R Realistic Realne T Time constraint Ograniczone w czasie
Wizja projektu
Wizja projektu Zadania wizji projektu: Krótki opis problemu Zdefiniowanie ogólnego celu projektu Zdefiniowanie ogólnego zarysu funkcjonalności projektu Zdefiniowanie klientów i użytkowników projektu Wizja zebrana jest w dokumencie wizyjnym powstałym w wyniku spotkań wizyjnych
Wstępna deklaracja zakresu projektu Opis projektu na ogólnym poziomie zawierający: Wymagania dotyczące produktów cząstkowych projektu Wymagania dotyczące produktu projektu Ramy realizacji projektu (co jest w zakresie, a co jest poza zakresem projektu) Wizja zawiera wstępną deklarację zakresu projektu
Modelowanie biznesowe
Modelowanie biznesowe Analiza struktury i dynamiki organizacji przeanalizowanie struktury i dynamiki organizacji, w której oprogramowanie ma być wdrażane (tzw. organizacji docelowej ). Identyfikacja problemów Zrozumienie aktualnych problemów organizacji, które identyfikują miejsca dla potencjalnych ulepszeń Identyfikacja procesów biznesowych opis procesów biznesowych zachodzących u klienta, aby był jednakowo zrozumiały przez wszystkich uczestników projektu (klienta i zespół projektowy). Tak, aby postrzegali docelową organizację w jednakowy sposób (jej strukturę, dynamikę i problemy). Opis rozpatrywanego problemu
Wymagania użytkownika
Wymagania definicja (PMI) Uwarunkowanie lub zdolność, którą powinien spełnić lub posiadać system, wyrób, usługa, rezultat lub element składowy, aby wykazać zgodność z kontraktem, normą, specyfikacją lub innym formalnie narzuconym dokumentem
Definiowanie wymagań Wizja źródłem wymagań projektu Wymagania stanowią podstawę tworzenia planu zarządzania projektem Proces definiowania wymagań Zebranie informacji Analiza i interpretacja informacji Przygotowanie dokumentacji Uzyskanie akceptacji dokumentacji
Weryfikacja wymagań Prezentacja udokumentowanych wymagań przed kluczowymi interesariuszami Uwagi interesariuszy Dokument wymagań projektu Pozyskanie formalnego zatwierdzenia Dokumentu wymagań od sponsora
Kto tworzy wymagania użytkownika? Klient stawia wymagania odnośnie systemu Analityk bada rynek i tworzy wymagania funkcjonalne systemu Przyszły użytkownik systemu
Przykład system rejestrowania błędów System rejestrowania błędów: służy do obsługi błędów powstających podczas tworzenia oprogramowania i zarządzania nimi system wewnętrzny: wymagania użytkownika nie pochodzą od klienta
System obsługi błędów- wymagania Wymagania funkcjonalne Wprowadzanie zgłoszeń Przeglądanie zgłoszeń Obsługa zgłoszenia Definiowanie obiegu błędów dla projektu Zarządzanie użytkownikami systemu Wymagania systemowe Integracja z podsystemami Przyjazny interfejs użytkownika
Wprowadzanie zgłoszeń- wymagania System powinien umożliwić: wprowadzanie nowego zgłoszenia do systemu, przypisanie zgłoszenia do projektu lub modułu, ustalenie dla zgłoszenia wersji realizacji oraz priorytetu, przypisanie typu zgłoszenia, wymuszone przypisanie osoby prowadzącej zgłoszenie, edycję treści zgłoszenia i pozostałych jego parametrów wraz z zapisem wszelkich zmian w historii zgłoszenia, edycję informacji dodatkowych, ale tylko z zapisem w tekście, kto i kiedy dokonał zmiany, tworzenie duplikatu zgłoszenia, z możliwością zmiany dowolnego z parametrów lub zmiany w treści, tworzenie powiązań między zgłoszeniami, potrzebne są dwa typy powiązań jedno nie wpływające na kolejność realizacji zgłoszeń, a drugie określające kolejność realizacji, czyli nie można przejść w zgłoszeniu nadrzędnym do następnego stanu przed zamknięciem zgłoszenia podrzędnego, ustalenie, kto ma się zająć zgłoszeniem w przypadku, gdy dotrze ono do wybranego stanu z WorkFlow
Rola wymagań użytkownika Punkt wyjścia procesu projektowania Rozwiązywanie sprzeczności wynikających ze sprzecznych oczekiwań różnych klientów Pomoc w konstruowaniu planu rozwoju systemu poprzez nadawanie priorytetów Usuwanie niejednoznaczności sytuacji, w której istnieje kilka wzajemnie sprzecznych interpretacji pewnego tekstu lub sytuacji
Przyczyny powstawania niejednoznaczności brakuje wymagań: dodanie nowych wymagań może rozstrzygnąć niejednoznaczność niejednoznaczne wyrazy: posiadające wiele znaczeń wymagania wprowadzone przez projektanta (nie przez użytkownika): powstaje konflikt na poziomie języka
Analiza wymagań Czy nie ma niejednoznaczności? Czy wymagania są kompletne? Czy wymagania są zrozumiałe dla wszystkich zainteresowanych?
Przy tworzeniu wymagań warto zwrócić uwagę na Przeanalizowanie systemu istniejącego i zastosowanie wyciągniętych wniosków przy tworzeniu nowego systemu Słuchanie innych, jeżeli mówią, że idziemy złą ścieżką Wyodrębnienie działań priorytetowych, z możliwością późniejszej zmiany ich kolejności
Związki pomiędzy wymaganiami Wymagania z reguły nie są pojedynczym bytem sformułowanie jednego wymagania wpływa na drugie Im wymaganie jest bardziej ogólne tym bardziej wpływa na inne wymagania Wymagania można grupować: Jeżeli grupa wymagań cechuje się silnymi związkami wewnętrznymi, a nie wpływa w znacznym stopniu na pozostałe wymagania, to można z tego zrobić podsystem
Wyznaczanie priorytetów Wymaganie jest konieczne, jeżeli nie można się bez niego obejść w systemie Wymaganie jest przydatne, jeżeli jego pominięcie nie spowoduje poważnych problemów związanych z realizacją podstawowych zamierzeń Wymaganie jest nieistotne, jeżeli mogą okazać się przydatne w pewnych zastosowaniach, lecz wprowadzenie ich do systemu nie jest warte wysiłku Wymaganie jest zbędne, jeżeli nie wiąże się w żaden sposób z celem projektu
Przypadki użycia
Przykładowy przypadek użycia Zgłoszenie błędu Warunki wstępne: Użytkownik jest zalogowany systemie Przebieg podstawowy: 1) Przypadek rozpoczyna się w widoku zgłoszeń, gdy użytkownik wybierze opcję dodawania zgłoszenia. 2) Pojawia się okno szczegółów zgłoszenia, pracownik wpisuje tytuł treść zgłoszenia, wybiera także moduł do którego ono należy wypełnia pozostałe dane związane ze zgłoszeniem. 3) Po wyborze modułu zgłoszenia pobierane są dane dotyczące workflow tym module i na ich podstawie ustawiane ewentualne podpowiedzi przy dalszym wypełnianiu zgłoszenia. Jeżeli wybrany projekt/moduł nie ma zdefiniowanego workflow to użytkownik jest o tym informowany i musi wybrać inny lub anulować zgłoszenie. 4) Użytkownik musi też wybrać osobę odpowiedzialną za realizację następnego stanu zgłoszenia, system podpowiada użytkownikowi jaka osoba według ustawień WorkFlow powinna zostać przypisana do tego zgłoszenia. Będzie to zazwyczaj programista przypisany do modułu lub administrator projektu. Oczywiście pracownik nie musi zastosować się do sugestii może wybrać dowolną osobę spośród przypisanych do modułu, a nawet spośród pozostałych użytkowników systemu TrackNet. 5) Po zatwierdzeniu zgłoszenie zostaje utworzone. Jeżeli dla modułu, wybranego w zgłoszeniu jest ustawiona notyfikacja mailem na tworzeniu zgłoszenia, zostaje wysłana odpowiednia wiadomość e-mail do zdefiniowanej w notyfikacji osoby/grupy osób. Stan końcowy: Zgłoszenie zostało dodane do systemu. Ewentualne notyfikacje zostały wysłane.
Części składowe: Przypadki użycia Nazwa; Identyfikator (ID); Opis; Warunki wstępne (ang. precondition); Warunki końcowe (ang. postconditions); Sekwencja akcji
Rola przypadków użycia Opisują zachowanie się systemu z punktu widzenia użytkownika Definiują granice systemu oraz relacje pomiędzy systemem a jego otoczeniem Pokazują ogólny obraz funkcjonalności systemu nie ma na tym etapie żadnych decyzji odnośnie funkcjonalności Pokazują co się będzie działo w systemie. Umożliwia to przemyślenie bądź przeprojektowanie całego procesu na wczesnym etapie
Cechy charakterystyczne przypadków użycia Przypadki użycia powinny być: Kompletne Zrozumiałe Niezależne od implementacji i używanej technologii Dobrze zaprojektowane z punktu widzenia użytkownika
Dlaczego tak? Sponsorzy są w stanie stwierdzić, co będzie zrobione, a co nie Użytkownicy wiedzą, co system będzie robił, a co nie (ewentualne sugestie są możliwe na tym etapie) Developerzy wiedzą, nad czym będą pracować
Elementy diagramu przypadków użycia Aktorzy (ang. actors) osoba, organizacja, system wewnętrzny wchodzący w interakcję z danym systemem Przypadki użycia (ang. use cases) sekwencja akcji wykonywana przez aktora (- ów) Asocjacje (ang. associations) Powiązanie pomiędzy aktorem a przypadkiem użycia
Przykład diagramu
Czym są i do czego służą diagramy przypadków użycia Definicja diagramu przypadku użycia: Diagram ukazujący relacje między aktorami i przypadkami użycia wewnątrz system Zastosowanie diagramu przypadku użycia: Modelowania całości lub części wymagań użytkowników systemu W skład modelu przypadków użycia wchodzą: diagramy przypadków użycia dokumentacje specyfikujące przypadki użycia oraz definicje aktorów
Dobór aktorów Przy doborze aktorów istotne jest: Ustalenie jaka grupa użytkowników potrzebuje wspomagania ze strony systemu Z jakich systemów zewnętrznych musi korzystać system do poprawnego realizowania swoich funkcji Ustalenie czy jest to aktor konkretny (np. Jan Kowalski) czy określenie roli (np. sprzedawca) Relacje pomiędzy aktorami warto ustanowić relację dziedziczenia pomiędzy aktorami Ustalenie głównych zadań aktorów
Możliwości ponownego wykorzystania komponentów Relacja rozszerzania (<<extend>>) Relacja zawierania (<<include>> w UML 2.0; <<uses>> w poprzednich wersjach)
Zawieranie przypadków użycia Zależność zawierania pomiędzy przypadkami użycia (ang. include dependancy) Polega na wywoływaniu jednego przypadku przez drugi
Rozszerzanie przypadków użycia Zależność rozszerzania pomiędzy przypadkami użycia (ang. extend dependency) rozszerzenie polega na dodaniu dodatkowych sekwencji akcji do sekwencji przypadku bazowego - w ten sposób można tworzyć alternatywny scenariusz dla bazowego przypadku użycia
Dziedziczenie Przypadków użycia: Zastępuje sekwencję akcji dziedziczonego przypadku użycia przez sekwencję akcji dziedziczącego przypadku użycia Aktorów: Bardziej wyspecjalizowany aktor dziedziczy zachowanie mniej wyspecjalizowanego aktora
Przykład zależności pomiędzy aktora
Przebiegi alternatywne (1) UC01 Aktorzy Warunki wstępne Obsługa zgłoszeń (dodawanie, przeglądanie, modyfikacja) Użytkownik - Aktor musi być zalogowany w systemie - Aktor musi widzieć przynajmniej jedno zgłoszenie (dla przepływów I i III) Przepływ główny Przeglądanie listy zgłoszeń 1. Aktor wskazuje projekt/moduł którego zgłoszenia chce przeglądać 2. System wyświetla listę dostępnych dla aktora zgłoszeń i umożliwia ich przeglądanie Przepływy alternatywne I Przeglądanie szczegółów 3. Aktor wskazuje zgłoszenie którego szczegóły chce przeglądać 4. System wyświetla szczegółowe informacje o zgłoszeniu 5. Aktor wybiera opcję zakończenia przeglądania szczegółów 6. System przechodzi do kroku 2. przepływu głównego II Dodawanie zgłoszenia 3. Aktor wybiera opcje dodania zgłoszenia 4. System umożliwia wprowadzenie danych nowego zgłoszenia 5. Aktor wprowadza wymagane dane i zatwierdza wykonanie operacji 6. System potwierdza dodanie nowego zgłoszenia i przechodzi do kroku 2. III Modyfikacja zgłoszenia 3. Aktor wskazuje zgłoszenie które chce zmodyfikować 4. System wyświetla bieżące dane zgłoszenia i umożliwia modyfikację danych edytowalnych 5. Aktor modyfikuje wybrane dane i zatwierdza wykonanie operacji 6. System potwierdza modyfikację zgłoszenia i przechodzi do kroku 2.
Przebiegi alternatywne (2) Warunki końcowe Dla przepływu II i III zmiana stanu systemu Wyjątki Anulowanie wykonywania operacji (przejście z kroku II.5, III.5) System potwierdza anulowanie operacji i przechodzi do kroku 2. przepływu głównego Brak uprawnień (przejście z kroku I.4, II.3, III.3) System informuje o braku uprawnień do wykonania odpowiedniej czynności i powraca do kroku 2. przepływu głównego Błędne lub niepełne dane zgłoszenia (przejście z kroku II.6, III.6) System informuje o podaniu błędnych lub niepełnych danych zgłoszenia i umożliwia ponowne podanie danych zgłoszenia
Dobre rady dla projektantów Przypadki użycia Nazwy powinny być zaczerpnięte z rozpatrywanej dziedziny systemu Rozmieszczenie przypadków użycia z użyciem ograniczeń czasowych Przypadek użycia nie powinien być ani za bardzo ogólny ani za bardzo szczegółowy
Dobre rady dla projektantów c.d. Aktorzy Podstawowi aktorzy powinni być umieszczeni w lewym górnym rogu diagramu Nazwa aktora powinna być rzeczownikiem w liczbie pojedynczej, określającą rolę aktora (nie jego pozycję) Każdy aktor powinien być powiązany z jednym lub większą liczbą przypadków użycia
Dobre rady dla projektantów c.d. Relacje: Asocjacje pomiędzy aktorem a przypadkiem użycia powinny być wskazywane, jeżeli aktor pojawia się wewnątrz logiki przypadku użycia Relacja <<include>> używa się, jeżeli dokładnie wiadomo, kiedy wywołać przypadek użycia Relacja <<extend>> używa się, jeżeli przypadek użycia może być wywoływany w wielu miejscach innego przypadku użycia
Dobre rady dla projektantów c.d. Relacje c.d.: Relacje <<extend>> powinny być używane nie za często Unikanie więcej niż dwóch poziomów asocjacji przypadków użycia Umieszczanie zawieranego przypadku użycia po prawej stronie wywołującego Umieszczanie rozszerzającego przypadku użycia poniżej bazowego
Dobre rady dla projektantów c.d. Relacje c.d.: Umieszczanie dziedziczącego przypadku użycia poniżej przypadku bazowego Umieszczanie dziedziczącego aktora poniżej aktora bazowego
Dla zainteresowanych: Alistair Cockburn Writing Effective Use Cases
Dziękuje..