Grupa nr 1 zaczyna zajęcia o 10:15 w poniedziałki, sala G-1-09, a grupa nr 3 o 10:15 w środy, sala G-1-10. Zapraszam również na konsultacje (pokój C-2-29 lub online, terminy w USOSwebie).
W trakcie semestru można mieć co najwyżej dwie nieusprawiedliwione nieobecności. Przekroczenie tego limitu oznacza brak zaliczenia.
Oceny z ćwiczeń wystawiane są na podstawie:
Warunkiem koniecznym zaliczenia ćwiczeń jest zrealizowanie projektu, czyli uzyskanie za niego oceny co najmniej dostatecznej.
Jan Kettenis, Getting Started With Use Case Modeling, Oracle 2007 (dostępny online).
Krótki white paper streszczający najważniejsze z zasad pisania przypadków użycia omówionych w podręczniku Cockburna. Dla tych, którzy nie potrafią znaleźć czasu na przeczytanie całego podręcznika. Fragmenty poświęcone aplikacji JDeveloper należy pominąć, tak samo późniejsze fragmenty dotyczące diagramów UML.
Lech Madeyski, Marcin Kubasiak, Zwinna specyfikacja wymagań, w: Problemy i metody inżynierii oprogramowania, red. Zbigniew Huzar, Zygmunt Mazur, WNT 2003 (dostępny online).
Artykuł opisujący z życia wzięty projekt informatyczny, w którym najpierw próbowano stosować tradycyjne opisy przypadków użycia, a potem zastąpiono je specyfikacjami zwinnymi. W trzecim etapie naszych projektów będziecie Państwo tworzyć prawie takie same specyfikacje, tyle że zamiast testów dla narzędzia XmlTestSuite będziecie pisać instrukcje dla ludzi-testerów.
Dennis Gurock, Writing Test Cases: Examples, Best Practices & Test Case Templates, Testmo 2023 (dostępny online).
Poradnik omawiający zagadnienia związane z pisaniem dobrej jakości instrukcji dla ludzi-testerów. Zachęcam, aby najpierw zapoznać się z moją ściągawką, a potem z tym poradnikiem.
W jego ramach będziecie Państwo opracowywać kolejne, coraz dokładniejsze specyfikacje wybranego przez Was i zaakceptowanego przez prowadzącego hipotetycznego systemu. Musi być on być na tyle złożony, aby dało się potem dla niego wyodrębnić tak z dziesięć przypadków użycia i więcej niż jednego aktora.
Zrealizowanie projektu nie wymaga pisania kodu w żadnym języku programowania. Będziecie Państwo analizować i projektować, ale nie programować. Rezultatami Waszych działań będą dokumenty w języku polskim.
Projekt trwa przez cały semestr. Prace koordynowane są za pomocą wydziałowej witryny Redmine. Dwa pierwsze etapy projektu realizowane są w 3-4-osobowych zespołach, ostatni trzeci etap jest indywidualny.
Szablon, według którego należy przygotować dokument wizji, dostępny jest w uczelnianej chmurze w formacie Worda oraz jako PDF. Jego części muszą być wypełniane po kolei, bo późniejsze zależą od wcześniejszych. Nie oznacza to, że nie można cofnąć się na początek i czegoś tam poprawić, jeśli podczas pracy nad końcowymi częściami okaże się, że o czymś wcześniej zapomniano.
Dokument wizji należy wgrać na Redmine’a jako plik PDF. Można obok niego wgrać plik źródłowy .docx lub .odt, ale nie jest to konieczne.
Uzgodnienie tego, co w poszczególne punkty szablonu wpisać zajmuje wiele dni, jest to więc dobra okazja do wykorzystania możliwości Redmine’a. Na przykład: skończyliście trzy pierwsze części, to wrzućcie na Redmine’a taką roboczą wersję i przestawcie postęp zadania z 0% na 20%. Niech prowadzący zajęcia widzi, że pilnie pracujecie.
Proszę nie usuwać z Redmine’a starych plików. Jeśli kiedyś wrzucono wersję 20%, to proszę ją zostawić w spokoju gdy będziecie wysyłać wersję 100%.
Na tym etapie należy tylko sporządzić rysunek pokazujący zależności pomiędzy aktorami i gruboziarnistymi przypadkami. Nie przygotowuje się opisów przypadków w języku naturalnym.
Diagram proszę wgrać na Redmine’a jako plik PNG, JPEG lub jednostronicowy PDF.
Zdefiniowane na diagramie przypadki rozdzielane są pomiędzy członków zespołu. Jeśli trzeba, są wcześniej rozbijane na bardziej szczegółowe, np. ze „złóż pismo” mogą powstać „złóż wniosek o miejsce w akademiku”, „złóż wniosek o stypendium”, „złóż odwołanie od odmowy przyznania stypendium” itd.
Na jedną osobę powinny przypadać 3 przypadki. Nie trzeba brać więcej, na diagramie mogą pozostać nikomu nie przydzielone PU.
Każdy członek zespołu indywidualnie opracowuje przydzielone mu przypadki. Zamiast tradycyjnych opisów (takich jak na kolokwium) należy opracować specyfikacje złożone z karty przypadku, szkiców UI (albo wręcz wysokiej wierności makiet) i testów akceptacyjnych. Proszę skorzystać ze ściągawki objaśniającej, jak pisać testy wykonywane przez ludzi-testerów.
Opracowane przez jednego członka zespołu specyfikacje należy umieścić w jednym pliku PDF, założyć na Redmine’ie zadanie i do niego ten plik wgrać. Dla czteroosobowych zespołów powinny więc być cztery odrębne zadania.
Harmonogram projektu:
Zapis „20 / 22.11” oznacza, że zespoły z grupy poniedziałkowej obowiązuje termin 20 listopada, a zespoły ze środy — 22 listopada.
Proszę nie czekać do ostatniej chwili z oddawaniem rezultatów etapów. Spóźnienia skutkują obniżeniem oceny o pół stopnia za każde rozpoczęte trzy dni.
Kolokwium z przypadków użycia odbędzie się na zajęciach 1 / 3.12. Rozgrzewkowe, nieoceniane kolokwium próbne będzie dwa tygodnie wcześniej, 17 / 19.11.
Materiały do ćwiczeń: pierwsza ściągawka, druga ściągawka.
Zamiast pisać mazakiem na tablicy używać będziemy chmury i dwóch współdzielonych dokumentów Worda, brudnopisu dla studentów i czystopisu dla prowadzącego.