| Nr tygodnia | Sprint | Spotkanie | Zadania | ||
| 1 |
1
|
Sprint planning meeting | Zajęcia organizacyjne. Omówienie niejasności i problemów związanych z środowiskiem projektowym i warunkami zaliczenia. Zaplanowanie zadań na pierwszy sprint. | ||
| 3 | Daily Scrum of Scrums (15 min) |
Dla każdego Przypadku Użycia (PU):
Oprócz przypadków użycia należy również realizować zaplanowane zadania i naprawiać znalezione defekty. Zaliczenie zadania lub naprawy defektu wymaga przygotowania tylko implementacji lub tego co jest treścią zadania. Istnieje również możliwość zdobywania punktów za znajdowanie i zgłaszanie błędów, w tym przypadku należy pokazać w systemie JIRA raport z opisem błędu i być przygotowanym na zademostrowanie tego błędu w testowanej aplikacji. |
|||
| 4 |
Daily Scrum of Scrums (15 min) | ||||
| 5 |
Daily Scrum of Scrums (15 min) | ||||
| 6 |
Daily Scrum of Scrums (15 min) | ||||
| 7 |
2
|
Sprint review meeting & Sprint planning meeting (1h) | Sprint review meeting. Na spotkaniu tym wybrane osoby będą przedstawiać rezultatów swojej pracy z kończącego się właśnie sprintu. Za wyjątkiem szczególnych sytuacji należy prezentować tylko działający program. Należy omówić nowe funkcjonalności pokazując je w działaniu. Wszyscy powinni prezentować tą samą instancję programu uruchomioną na tym samym komputerze. Za prezentację przyznawane są punkty. | ||
| 8 | Scrum - Backlog Grooming | ||||
| 9 |
Daily Scrum of Scrums (15 min) | ||||
| 10 |
Daily Scrum of Scrums (15 min) | ||||
| 11 |
3 | Sprint review meeting & Sprint planning meeting (1h) | |||
| 12 |
Scrum - Backlog Grooming | ||||
| 13 |
Daily Scrum of Scrums (15 min) | ||||
| 14 |
Daily Scrum of Scrums (15 min) | ||||
| 15 |
Sprint review meeting & Sprint retrospective meeting (1.5h) | Podsumowanie
projektu |
|||
Stosowany będzie proces wytwarzania oprogramowania wzorowany na metodyce Scrum. Z metodyki tej zaczerpnięte zostały następujące elementy:
Przepływ pracy w projekcie wynika bezpośrednio z przedstawionego w Przebiegu realizacji projektu harmonogramu.
Cały projekt jest podzielony na 3 sprinty. Każdy sprint składa się z takich samych elementów. Zaczyna się spotkaniem Sprint planning meeting, w trakcie którego wybierane są zagadnienia do zrealizowania w trakcie sprintu, a kończy się spotkaniem Sprint review meeting, w trakcie którego prezentowane są uzyskane wyniki. Najważniejszym zadaniem w trakcie sprintu jest rozwiązywanie zaplanowanych na sprint zagadnień, czyli błędów, zadań i przypadków użycia. Należy je realizować w kolejności wynikającej z 'backlogu', a przed rozpoczęciem prac zagadnienie koniecznie sobie przypisać w systemie JIRA. Jeżeli jakimś zagadnieniem zajmuje się kilka osób wszystkie je należy wymienić w komentarzu do zagadnienia przed rozpoczęciem prac.
Rozwiązanie zarówno błędu jak i zadania polega na zrobieniu tego co wynika z treści danego zagadnienia i zaprezentowaniu uzyskanego wyniku prowadzącemu do zatwierdzenia. Rozwiązanie zagadnienia będącego przypadkiem użycia składa się z modelowania w ramach którego należy wytworzyć artefakty związane ze specyfikacją i dokumentacją oraz implementacji, w ramach której automatyzuje się testy i pisze kod źródłowy odpowiadający wybranej funkcjonalności. Punkty za zrealizowanie zagadnienia są przyznawane dopiero po zakończonej sukcesem prezentacji przed Product Ownerem.
Dostęp do systemów z chmury firmy Atlassian (Bitbucket, Confluence i Jira) uzyskuje się przez rejestrację na stronie https://opendce.atlassian.net/admin/users/sign-up.
Ocena końcowa będzie zależeć od liczby zrealizowanych i zaliczonych zagadnień (zagadnienie może być przypadkiem użycia, zadaniem albo błędem), które wcześniej zostały zgłoszone w JIRA. Za każde zagadnienie przyznawane są punkty w liczbie równej wartości pola 'story points' z systemu JIRA. Szczególnym przypadkiem zadań są zadania związane z usuwaniem problemów zidentyfikowanych przez system SonarQube podczas statycznej analizy kodu. Zadania takie studenci mogą zakładać samodzielnie dla problemu sklasyfikowanego jako 'Blocker' albo 'Critical', a za rozwiązanie przyznawany jest 1 punkt. Punkty przyznawane są również za znalezienie i zgłoszenie błędu. Liczba punktów zależy od rodzaju błędu i może się wahać od 1 do 5.
Warunkiem uzyskania danej oceny jest zdobycie odpowiedniej liczby punktów, wg poniższej tabeli:
| Ocena |
Punkty |
| 3,0 |
6 |
| 3,5 |
9 |
| 4,0 |
12 |
| 4,5 |
15 |
| 5,0 |
18 |
1. QualitySpy
Narzędzie wydobywające informacje o historii projektu programistycznego.
Dane zbierane są z systemu śledzenia zagadnień (Jira...) i systemu kontroli
wersji (SVN, GIT...), metryk kodu (ckjm) i systemu ciągłej integracji (Jenkins, Hudson...).
Dane są składowane w bazie danych i udostępniane do dalszej analizy.
Projekt o architekturze komponentowej.
Odnośniki: Jira,
Bitbucket,
Confluence,
Oryginalna wizja projektu.
2. Projects Portfolio
Odnośniki:
Jira
3. Safety Analysis
Narzędzie wspierające analizę bezpieczeństwa przy użyciu drzew zdarzeń,
drzew błędów oraz logiki rozmytej.
Aplikacja desktopowa o rozbudowanym interfejsie graficznym pozwalającym na
rysowanie diagramów.
Projekt o architekturze komponentowej.
Odnośniki: Java.net,
Jira,
Bitbucket,
Confluence.
1. Rejestracja: https://opendce.atlassian.net -> Log in -> Sign up for an account.
2. Odebrać email - może być w spamie.
3. Po zalogowaniu się w JIRA powiadomić prowadzącego i poprosić o uprawnienia.
4. Przejść do zadania QS-151 i wybrać opcję "Utwórz odgałęzienie"
5. Na następnym ekranie zmienic "Branch name" na QS-151-tu-cos-od-siebie. Przeniesie to do serwisu Bitbucket, gdzie trzeba sie bedzie zalogować tymi samymi danymi co w atlassian.net i wybrać login, najlepiej podobny do tego z atlassian.net
6. Pojawi się ekran tworzenia odgałęzienia, gdzie niestety będzie brakowało uprawnień do zrobienia czegokolwiek. Zanim będzie można kontynuować trzeba te uprawnienia zdobyć.
7. Należy poprosić prowadzącego o dodanie do grupy Developers w projekcie w systemie Bitbucket, prowadzący będzie potrzebował adres email dodawanej osoby.
8. W Bitbucket należy przejść do View profile -> Settings -> SECURITY -> SSH keys i wybrać "Add key" by dodać swój klucz publiczny.
9. Teraz można wrócić do ekranu tworzenia odgałęzienia i je utworzyć.
10. Pobieramy źródła projektu. W IntelliJ VCS -> Checkout from version control -> Git; adres projetku: git@bitbucket.org:opendce/qualityspy.git
11. Przełączamy się na odgałęzienie o ustalonej wcześniej nazwie i dopisujemy się w pliku pom.xml do sekcji developers. Tę czynność można wykonać w grupie, tj. od razu dopisać kilka osób.
12. Po wprowadzeniu zmian sprawdzamy, że projekt się poprawnie buduje: mvn clean isntall
13. Wprowadzone zmiany wysyłamy na serwer (git commit i git push)
14. Zmiany powinny wyzwolić budowanie projektu, co można zobaczyć na https://bitbucket.org/opendce/qualityspy/addon/pipelines/home#!/
15. Dla wprowadzonych zmian należy przygotować pull request, na stronie https://bitbucket.org/opendce/qualityspy/pull-requests/ wybieramy "Create pull request". Jako odgałęzienie źródłowe wybieramy swoje własne, utworzone nieco wcześniej, a jako docelowe master.
16. Zmiany trafią do głównej linii kodu (master) dopiero wtedy kiedy pull request zostanie zatwierdzony przez prowadzącego.