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.
Kolokwium z refaktoryzacji odbędzie się na zajęciach 12 / 14 stycznia.
Ta część zajęć jest oparta o materiały dydaktyczne opracowane w centrum szkoleniowym CPTTM w Makau. Będziecie mieli Państwo przydzielony fragment materiału do przestudiowania, a potem na zajęciach opowiecie o tym, czego się dowiedzieliście. Pracować będziecie w parach, bo łatwiej studiować z kimś niż samotnie.
Prezentować może jedna osoba albo dwie, jak wolicie. Na początku referatu należy powiedzieć, na czym polega omawiana przez Was technika refaktoringu i w jakich sytuacjach się ją stosuje. Potem trzeba przedstawić przykłady użycia tej techniki. Możecie Państwo użyć przykładów z podręcznika CPTTM, możecie poszukać ich w sieci, ale bardzo zachęcam do wymyślenia choć jednego własnego.
Jeśli chcecie, możecie przygotować slajdy i użyć rzutnika. Ze slajdami jest jednak problem, nie da się na nich umieścić długich fragmentów kodu źródłowego. Na jednym slajdzie mieści się co najwyżej kilkanaście linii kodu — jeśli spróbujecie dać więcej, to rozmiar czcionki będzie musiał być tak mały, że stanie się nieczytelny dla osób siedzących z tyłu sali. Możecie spróbować użyć Worda i wklejać przygotowane przykłady do brudnopisu (to ten współdzielony dokument, którego używaliśmy na ćwiczeniach z PU), wtedy każdy ze słuchaczy będzie miał kod tuż przed swoim nosem i będzie mógł go samodzielnie przewijać.
Czas trwania wystąpienia powinien zależeć od tego, jak bardzo skomplikowana jest dana technika refaktoryzacji i ile przykładów przygotujecie. Na „zmienne muszą mieć znaczące nazwy, a nie x1, x2, x3” wystarczy 5 minut. Dla większości zagadnień można się zmieścić w 10 minutach; może być też trochę dłużej, ale starajcie się nie przekraczać 15 minut.
Po wygłoszeniu wszystkich referatów, a przed kolokwium, będą zajęcia ze wspólną analizą i przerabianiem przykładowego kodu. Spróbujemy na nich użyć edytora Codeshare zamiast Worda.