Projekt zespołowy

Harmonogram realizacji projektu

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):
  • aktualizacja i opcjonalnie rozszerzenie architektóry projektu,
  • aktualizacja i opcjonalnie rozszerzenie instrukcji obsługi,
  • implementacja (kod musi przejść przez code review i trafić do głównej gałęzi, tj. master),
  • testy jednostkowe w JUnit,
  • testy akceptacyjne w wybranym narzędziu,

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

Stosowny proces wytwarzania oprogramowania

Scrum

Stosowany będzie proces wytwarzania oprogramowania wzorowany na metodyce Scrum. Z metodyki tej zaczerpnięte zostały następujące elementy:

Przepływ pracy

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.

Zalecane narzędzia

Warunki zaliczania i metoda oceniania

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

Tematy projektów

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.

Rozpoczęcie pracy w projekcie

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.

Literatura

Zalecana literatura do UML w wersji 2.0:


1. M. Fowler, UML w kropelce, Wersja 2.0, LTP, 2005.
2. M. Śmiałek, Zrozumieć UML 2.0, Metody modelowania obiektowego, Helion, 2005.
3. S. Wrycza, Język UML 2.0 w modelowaniu systemów informatycznych, Helion, 2005.

Informacje o przeglądach formalnych i inspekcjach:


4. J. Górski, Inżynieria oprogramowania w projekcie informatycznym, Mikom, 1999.

Informacje o idei programowania przez testy oraz lekkich metodykach wytwarzania oprogramowania i wzorcach projektowych:


5. K . Schwaber, Agile project management with Scrum, Microsoft Press, 2004.
6. K. Beck, C. Andres C., Wydajne programowanie: Extreme programming, Mikom, 2005.
7. K. Beck, TDD by example, Addison-Wesley 2002.

Informacje o narzędziach do testowania:

8. A. Hunt, JUnit: Pragmatyczne testy jednostkowe w javie, Helion 2006.
9. R. Mugridge, W. Cunningham, Fit for Developing Software: Framework for integrated Tests, Prentice Hall, 2005.

Informacje o refaktoryzacji i dobrych praktykach programistycznych:

10. R.C. Martin, Czysty kod, Helion, 2010.
11. M. Fowler, K. Beck, J. Brant, W. Opdyke, D. Roberts, Refaktoryzacja,Wydawnictwo Naukowo-Techniczne 2006.
12. R.C. Martin, Agile Software Development, Principles, Patterns, and Practices, Prentice Hall, 2002.


Ciekawe informacje można również znaleźć na stronach związanych z przedmiotem Inżynieria Oprogramowania:
www.equus.wroc.pl/studia.html
gromit.iiar.pwr.wroc.pl/uml/
W razie jakichkolwiek wątpliwości co do syntaktyki lub semantyki diagramów UML wyrocznię, czyli aktualnie obowiązującą specyfikację, można znaleźć tu:
http://www.uml.org/