Webinarium 17.01.2018

Po obejrzeniu filmu naciśnij przycisk “Zrobione”. W ten sposób dasz znać, że moduł jest ukończony.

Lista pytań:

  1. W jakich sytuacjach lepiej jest korzystać z diagramu aktywności zamiast opisu przypadku użycia ?
  2. W pewnych przypadkach nazwę scenariusza alternatywnego można traktować jako warunek początkowy danego scenariusza. W ramach swojej pracy spotkałem się, z dokumentacjami, w których zostało przypisanych wiele warunków początkowych do scenariusza alternatywnego. Czy taki zapis jest poprawny ? W jaki sposób można jasno zdefiniować kryterium wejścia w dany scenariusz alternatywny ? Nazwa scenariusza jest warunkiem wejścia w tą ścieżkę ?
  3. Na diagramie PU dosyć łatwo jest rozróżnić relację include oraz extend. W przytoczonym przez Ciebie przykładzie w scenariuszu alternatywnym używamy wyłącznie relacji extend.
    a. Czy tak powinniśmy zawsze postępować?
    b. Czy w scenariuszu głównym w takim razie zawsze powinniśmy korzystać z relacji include?
    c. Istnieją jakieś odstępstwa od tych reguł ?
  4. Jaki powinien być ostateczny poziom szczegółowości opisu scenariuszy PU ? Spotkałem się kiedyś ze stwierdzeniem, że jeden krok z PU powinien odpowiadać jednej metodzie na diagramie sekwencji. Czy zgadzasz się z tym stwierdzeniem ?
  5. EA ogranicza liczbę rozgałęzień danego PU. Mam tutaj na myśli sytuację, że tworząc scenariusz alternatywny do scenariusza głównego nie mogę już do niego dodać następnego scenariusza alternatywnego. Czy takie opisy mogą istnieć ? Abstrahuję tutaj od wykorzystywanego narzędzia, które może w różny sposób ograniczać taki scenariusz.
  6. Na kursie wspomniałeś, że w ramach opisu PU mogą wystąpić różne warunki końcowe. Czy powinny być one w oznaczane którego przepływu PU dotyczą (np. przepływu alternatywnego)? Patrząc na taki opis ze strony Dewelopera może on nie być w stanie zidentyfikować jak ostatecznie powinien zakończyć się PU, podobnie patrząc na dalsze przekształcenie PU w scenariusze testowe także może to wiązać problemy, ponieważ tester może nie zidentyfikować poprawnie w jaki sposób powinien zakończyć się dany PU.
  7. Wspomniałeś także, że PU powinien mieć jeden warunek końcowy. Czy może zostać zidentyfikowanych wiele warunków końcowych, które zostaną spełnione niezależnie od przepływu scenariusza ? W jaki sposób określiłbyś, że np. użytkownik po zakończeniu danego przepływu otrzyma wiadomość email, jego zgłoszenie zostało zapisane w systemie oraz jego dane zostały przekazane np. do centralnego systemu bankowego ?
  8. W warunkach końcowych wspominasz także o poprawnym uzupełnieniu warunków np. uzupełniając w jego treści nazwę statusu jaki uzyska. Czy takie statusy nie powinny być zmapowane na taki PU ? Patrząc na takie rozwiązanie z punktu zmian np. znaczenia i nazwy tego PU, może być ciężkie do zidentyfikowania, w którym miejscu jest zapisana nazwa tego PU.
  9. W wielu literaturach pojawiają się różnego rodzaju testy danych PU. Np. test szefa. W przygotowanym przez Ciebie szkoleniu nie zauważyłem wzmianki o tego typu testach. Czy stosujesz takie testy w swojej pracy ? Jakie jeszcze testy są przez Ciebie znane ?
  10. Patrząc na punkt wyżej np. ubezpieczeniem dany przedmiot jest objęty w danym okresie. Jeżeli zamodelowalibyśmy maszynę stanową w taki sposób, że po przekroczeniu tego okresu zmieniany jest jego status np. na „Poza ochroną” i taka zmiana wykonywana była jakimś automatem. Czy taki automat także warto jest opisać przez PU. PU wg. mojej wiedzy jest opisem interakcji między użytkownikiem a systemem. W jaki sposób podszedłbyś to takiego tematu ?
  11. Dlaczego posiadamy wyłącznie jeden warunek początkowy? Jeżeli chciałbym umożliwić użytkownikowi dostęp do tej funkcjonalności wyłącznie jeżeli jest to użytkownik zautoryzowany w systemie oraz jeżeli np. ubezpieczenie jest aktywne ?
  12. W przytoczonych przez Ciebie przykładach warunki początkowe brzmią troszkę jak akcje. Np. „Aktor otwiera formularz”. Czy taki warunek nie mógłby być np. pierwszym krokiem w scenariuszu PU ? Są jakieś „best practices” do definiowania i tworzenia treści warunków początkowych ?
  13. W jaki sposób mógłbym rozpisać w PU pętlę ? np. jeżeli użytkownik dodaje kilka pozycji do listy zakupów ?
  14. Załóżmy, że użytkownik wnioskuje o rachunek przez stronę internetową. Taki formularz wnioskowania może być kilkuetapowy. W jaki sposób mógłbym to rozpisać w scenariuszu ? Używając scenariuszy alternatywnych ? (zakładam, że użytkownik w dowolnym momencie może wrócić do poprzedniego kroku)
  15. W literaturze i na niektórych blogach pojawiają się biznesowe przypadki użycia. Czym one się różnią od UMLowych przypadków użycia ?
  16. Wspomniałeś, że jeżeli PU posiada małą liczbę kroków, to jest to raczej funkcja i nie powinniśmy jej opisywać jako PU. W zupełności się zgadzam z tym stwierdzeniem i do niej się stosuję w praktyce. Patrząc jednak np. na specyficzny formularz kontaktowy, który jest np. Twoim kontaktem do Twojego prywatnego doradcy, zawierałby on 1 pole, albo i wcale by nie miał pola. W jaki sposób byś zapisał takie wymagania ?
  17. Czy jedna aktywność z procesu powinna odpowiadać tylko i wyłącznie jednemu PU ?
  18. W przykładzie zidentyfikowaliśmy aktora jako “Pracownik BOK”, czy w scenariuszu też powinniśmy się odwoływać do tego aktora (zakładam, że już dodałem opis pracownika do słownika)?

     

  19. Na kursie nie został poruszony wątek scenariuszy wyjątku. Stosujesz je w swojej pracy ?
  20. przypadki użycia: czy dla poprawy czytelności lepiej upychać je w mniejsze pakiety, niż tworzyć jeden wielki diagram?
  21. diagram klas: nie będąc programistą, czy poleca Pan jakieś źródła dla lepszego zrozumienia obiektowości , tak aby sensowniej i lepiej tworzyć klasy aplikacji?
  22. czy aktor może tez być “pasywny” – np. do niego jest coś przesyłane, albo od niego jest coś pobierane (dane z Bazy Danych, plik). np. czy zewnętrzny system (strona www), z którego pobieramy okresowo plik do analizy, jest aktorem? Czy Baza Danych wobec tego powinna być aktorem? jak odróżnić, kiedy jest częścią systemu, a kiedy aktorem?
  23. Czy Zegar/Scheduler, który okresowo wymusza wykonywanie pewnych rzezy, jest aktorem? Jak odróżnić (na bazie dobrych praktyk) kiedy powinien być aktorem, a kiedy elementem systemu?
  24. Czy w klasycznym procesie wytwórczym: wymagania – procesy biznesowe – przypadki użycia, wymagania powinny być mapowane (traceability) na procesy biznesowe, czy na przypadki użycia bezpośrednio? Jeśli na PU – jak zrobić mapowanie na procesy?
  25. czy należy dążyć do tego, by wszystkie PU znalazły się na jednym diagramie, czy można je rozdzielać tematycznie (np. dla case Bankowat: PU związane z bezpośrednią obsługa klienta i PU techniczne)?
  26. gdzie w przypadku case Bankomat jest miejsce na procesy biznesowe (gdyby Zamawiający sobie zażyczył)? jakie one powinny być (chodzi mi o umiejscowienie PB vs PU)
  27. Skąd wiedzieć, którą z 5 perspektyw wybrać przy tworzeniu dokumentacji oprogramowania?
  28. Czy zawsze będą wszystkie perspektywy przy projektach, czy są one substytucyjne / zamienne w stosunku do siebie?
  29. Czy widzisz powiązanie pomiędzy Przypadkiem Użycia a User Story? Oba dotyczą funkcjonalności, wskazują na użytkownika/aktora, mają warunki końcowe/kryteria akceptacji – widzę podobieństwa. Ale jak jest z ich ‘wielkością’, gradacją? Czy są podobnej wielkości, bardziej atomowe czy złożone? Jeśli używamy w projekcie US, to jak się one powinny wiązać do UC: 1-1, 1-n?
  30. Spotkałam się z nomenklaturą nazywania UC w trybie rozkazującym, jako że opisują akcję/interakcję, np. Generuj raport. Co o tym sądzisz
  31. Czy model UC powinien w jakiś sposób pokazywać, że dany UC jest wywoływany z różnych miejsc aplikacji? Widziałam przypadki, w których podawana była ścieżka dojścia do funkcjonalności (nawigacja po menu). Co o tym sądzisz? Czy UC powinny być raczej oderwane od rozwiązania, abstrakcyjne?
  32. Na jednym ze slajdów podałeś przykład scenariusza (str.43 moduł 2), w którym w kroku podawania adresu napisałeś, że jeśli zostanie wprowadzony kod pocztowy, to system automatycznie uzupełni miejscowość. Jest tam adnotacja, że to ‘doszukanie’ miejscowości, to mógłby być osobny UC. Zaintrygowało mnie to spostrzeżenie. Bo wyobrażam sobie taki scenariusz: aktor wpisuje kod pocztowy, system automatycznie wyszukuje miejscowość -> jaka w przypadku tego automatycznego wyszukiwania byłaby interakcja użytkownika z systemem? czy automaty tez się zapisuje przypadkami użycia?
    Idąc dalej, gdybym miała zapisać UC dla rejestracji polisy ubezpieczeniowej, w którym aktor podaje dane osobowe, a system wylicza składkę, i to wyliczenie składki (algorytm) składa się z n-kroków (np. system wylicza wiek osoby, system pobiera parametry dla wybranych świadczeń, system wylicza qx dla wieku i płci, etc.), to też to wg Ciebie można by zapisać UC?
    Ja bym to raczej zapisała jednym krokiem w scenariuszu: system wylicza składkę, a w odpowiednim miejscu dokumentacji dołączyłabym algorytm tego ‘wyliczania składki’. A Ty jak byś zrobił?
  33. Jaką zalecasz wielkość UC, liczbę kroków w scenariuszu? Wielkość UC ma chyba wpływ na estymację projektu w EA, tak?
  34. Czy dokumentacja Analityk Biznesowego powinna być prowadzona w języku polskim, czy angielskim? Czy jest to zależne od ustaleń firmy itp.?
  35. Skąd wiadomo, na jakim poziomie szczegółowości można przestać “tworzyć” (pisać) przypadki użycia?
  36. Jakie bezpłatne narzędzie poleca Pan do obsługi plików EAP? W firmie nie mam Enterprise Architekta ani Visual Paradigm’a, a do domu nie  chcę kupować licencji, tylko skorzystać z darmowego oprogramowania. Pobrałem instalkę Visual Paradigm, ale jeszcze nie instaluję – może dowiem się od Pana o innym, lepszym narzędziu.
  37. Czy Testerzy w firmie mają dostęp do repozytorium, które Analityk Biznesowy sporządza w Enterprise Architect i czy mogą zgłaszać swoje zastrzeżenia / poprawki odnośnie sformułowanych przypadków użycia?
  38. Czy udostępniony przez Pana plik (np. PUML_02) można nazwać artefaktem?
  39. Jak oznaczyć/opisać Akcję, która może wystąpić w dowolnym momencie scenariusza ? np. rezygnacja z transakcji
  40. Czy w praktyce używa się piktogramu Bonduary dla oznaczenia granic systemu ?
  41. W EA opisanych jest więcej relacji. Dodatkowe to: Use, Generalize, Realize, Invokes, Precedes  – czy dla modelowania w EA ma to znaczenie i jakie
  42. Jak wykorzystać dodatkowe pola EA w opisie scenariusza?
  43. Jak wykorzystać funkcjonalność Files w opisie przypadku użycia?
  44. Czy możesz udostępnić prezentację ze slajdami, które pojawiają się w Twoich filmikach (nie znalazłam jej na stronie)? Przepisywanie ich jest żmudne i trochę mija się z celem kursu internetowego.
  45. Czy możesz wygenerować plik .doc/.docx z pliku .eap i go podesłać?
  46. W filmiku ‘Diagram przypadków użycia – prezentacja’ (pierwszym z serii o PU) mówisz, że kolumny w raporcie to wymaganie niefunkcjonalne, dobrze zrozumiałam? A nie funkcjonalne? Dlaczego? Przecież zawiera informacje o tym co ma być w raporcie a nie jak on powstaje.
  47. Bardzo proszę o rozwinięcie co to jest interfejs i podanie przykładu. Takie sformułowanie pojawia się w filmiku ‘Diagram przypadków użycia – prezentacja’? Zawsze to pojęcie było dla mnie jakieś zawiłe.
    Interfejs to jest to samo co Interfejs użytkownika i GUI?
  48. Referuję do Twojego slajdu z prezentacji. Związek zawierania oznacza, że zaczynamy w przypadku ‘Rezerwacja pokoju’, zawsze przechodzimy do Weryfikacji karty kredytowej i zawsze potem wracamy do rezerwacji? (czyli ZAWIERA ten PU w środku/na początku/na końcu PU rezerwacji pokoju?)
  49. Związek rozszerzania oznacza, że rezerwując pokój możemy (ale nie musimy) przejść do rezerwacji parkingu. Jednak jeżeli będziemy rezerwować parking to czy potem musimy wrócić do rezerwacji pokoju?
  50. Jeżeli w rysunku przy związku rozszerzania, pojawiłaby się jeszcze asocjacja od Klienta do UC rezerwacji parkingu, czy oznaczałoby to, że:

    (a) Klient rezerwując parking musi zarezerwować pokój,
    (b) czy też może ale nie musi zarezerwować pokoju?

  51. Przy tym jaki opis nadać UC, mówisz, że może być to: “PU jest odpowiedzialny za naliczenie…”. Spotkałam się z podejściem, że nie możemy pisać, że PU jest za coś odpowiedzialne bo przecież nie jest. Odpowiedzialny będzie System, ewentualnie User. Czy nie powinno to być, że “PU opisuje sposób naliczenia… ” albo “UC definiuje sposób naliczenia…”? Jak się zapatrujesz na takie podejście?
  52. Nie do końca rozumiem, dlaczego w UC warunek początkowy może być tylko jeden. Przykładowo Otwarcie formularza, status artefaktu i uprawnienia aktora to nie są wykluczające się trigery. Mamy więc już 3. Interpretuję to, że te 3 trigery musiałyby być spełnione jednocześnie i tworzą jeden warunek początkowy, słusznie?
  53. Co jednak gdy do danego PU można wejść z kilku miejsc.?
    Przykład: PU Rezerwacja pokoju.
    Mogę go rozpocząć klikając na odpowiedni przycisk “Rezerwuję” na stronie głównej, ale również mogę rozpocząć go klikając z linku “Super oferta” przesłanym w emailu. Mamy więc 2 punkty wejścia.
    Utrudnię jeszcze, co gdy mamy w obu sytuacjach różne uprawnienia. Przycisk “Rezerwuję” na stronie głównej to uprawnienie umożliwiające pełną rezerwację, dla każdego usera.
    Z kolei rezerwując z linku przesłanym w emailu, mogę tylko dokonać uproszczonej rezerwacji (nie ma wszystkich pól widocznych na stronie).Jak wtedy zapisać warunki/warunek początkowy?
  54. Kiedy zaczynasz tworzyć PU? Jeszcze na etapie zbierania wymagań czy już na końcu, gdy (teoretycznie) wiesz wszystko?
  55. W przykładzie PU “Przyjęcie zamówienia od Klienta”, podałeś 2 warunki końcowe. Są one jednak różne i zakładam, że wzajemnie wykluczające się. Zamawia się towar lub naprawę. Rozumiem, że nie są potrzebne oba zamówienia, aby zapisać formularz bez błędów walidacji. Jak to rozdzielić w zapisie “Warunków końcowych”? Dodać odpowiednią adnotację do każdego z punktów, np.:
    Zapisanie zlecenia naprawy – gdy zamówienie dotyczy serwisu,
    Zapisanie zlecenia na towar- gdy zamówienie dotyczy zakupu towaru.
  56. Jak w opis PU wpleść warunki walidacji?
    Aktualnie pracuję nad aplikacją składającą się w 90% z formularzy. Rozwiązałam to tak, że model walidacji jest to 1 plik Excel i opisuje wszystkie strony aplikacji. Do każdego PU, dodałam regułę, że walidacje są przeprowadzane zgodnie z plikiem zamieszczonym w rozdziale Załączniki. W krokach scenariuszy, w których ma następować walidacja, dodałam dopisek, że System dokonuje walidacji zgodnie z w/w. regułą.
    Czy tak jest poprawnie?
  57. Spotkałam się ze stwierdzeniem, że logowanie do systemu nie powinno być zapisywane jako PU, jeżeli zalogowanie się do systemu jest warunkiem koniecznym do działania w aplikacji. Czy to prawda?
  58. Skoro użyteczny PU to minimum 3 kroki, a jeżeli jest ich mało to jest to funkcja, czy w takim razie zmiana wersji językowej np. z PL na EN powinna być opisana jako PU? W sumie zazwyczaj odbywa się to przez 1 klik Usera po której następuje 1 krok Systemu.
    Spotkałam się z występowaniem takich PU.
    Jak się na to zapatrujesz?
    I jeszcze jedno, jeżeli nie PU, to zmiana wersji językowej to będzie wymaganie funkcjonalne czy niefunkcjonalne?
  59. Czy na diagramie PU umieszczamy przypadki wykonywane automatycznie przez nasz (opisywany) system? Wówczas nie łączę ich z aktorem (bo w sumie nikt ich nie inicjuje) chyba, że jakiś CRON ale rozumiem, że to nie aktor?
    Czy takie przypadki należy jakoś specjalnie oznaczać?
  60. Pytanie do filmiku “Diagram pakietów – prezentacja”.
    Co to znaczy, że [cyt.]: “…zewnętrzne elementy pakietu Dziekanat, korzystają z elementów zawartych w pakiecie Planowanie”. Proszę o wyjaśnienie i przykład. Screen niżej.
  61. Co z pakietem Rekrutacja? Zawarte w nim elementy są niezależne, czyli np. nie ma w nie wglądu nikt z Dziekanatu ani Działu finansowego?
  62. Czy pozostałe elementy “Wydziału” (poza “Dziekanatem”), mogą korzystać z elementów “Działu finansowego”?
  63. Do pakietu “Wydział” należy pakiet “Dziekanat”. Czy należy do niego również pakiet “Dział finansowy” (skoro jego dane są importowane do “Dziekanatu”)?
  64. Jeżeli opracowuję dokumentację dla systemu A, który łączy się z systemem B oraz bezpośrednio z bazą danych C, to jak mam to uwzględnić na diagramie PU?
    Uprośćmy, że mamy jednego Aktora-Usera. Umieszczam go na diagramie. Mam umieścić również System B i Bazę danych C? Do każdego z tych trzech aktorów łączę asocjacją poszczególne przypadki użycia?
  65. Co gdy mój diagram zaczyna przypominać pajęczynę z Twojej prezentacji- jak to rozdzielić, gdy PU są ściśle połączone między sobą i aktorami?
  66. Przy tworzeniu klas mówisz, że tworzysz model pojęciowy i dlatego nazwy klas są po polsku. Czy w przypadku oficjalnej dokumentacji (tworzonej po PL) też powinny być tak tworzone, czy też mają być od razu po EN z zachowaniem Camel case? Jeżeli nie ma na to odpowiednich reguł, jakie są powszechne praktyki?
  67. Co to są kooperacje? (z filmu dot. diagramu klas)
  68. Proszę o przykład operacji i metody, aby lepiej zrozumieć czym one się różnią.
    (film dot. diagramu klas)
Scroll to Top