2014.03.05, WEiTI PW, RSO.B, tjk Treść zadania laboratoryjnego ============================= Każda grupa projektowa ma za zadanie: a. zaprojektować, b. zaimplementować, c. przetestować, d. zademonstrować odbierającemu projekt usługę rozproszonego systemu plików przechowującego pliki w pamięci operacyjnej bądź na dyskach lokalnych. Usługa powinna: - mieć dokładnie jeden ten sam tekstowy plik konfiguracyjny dla części serwerowej i klientów usługi, - składać się po stronie serwerowej z dwóch warstw: (1) warstwy usług lokalizacyjno/nazewniczych (katalogi, kojarzenie nazw z plikami), (2) warstwy właściwego przechowywania, - oprogramowanie realizujące część serwerową powinno być współbieżne, - składać się po stronie klienckiej z prostych narzędzi opatulających zaproponowane API protokołu komunikacyjnego, - zapewniać odporność na uszkodzenia węzła, - zapewniać realizację usługi w trakcie awarii w czasie obsługi (np. podczas transferu b. dużego pliku), - obsługiwać scenariusz próby ponownego wpięcia się przez węzeł lokalizacyjny bądź danych, który uprzednio zaginął, - na bieżąco i transparentnie dla oprogramowania klienckiego zarządzać dostępnymi zasobami lokalizacyjnymi, - zapewniać zadany (większy niż 1 ale mniejszy niż liczba serwerów danych) poziom redundancji - z obsługą uzupełniania kopii na innych serwerach w przypadku awarii włącznie, - cała część serwerowa usługi powinna być uruchamiana i zamykana jednokrotnym wywołaniem skryptu z jednym argumentem , - opcjonalne: polecenia zrucenia migawki systemu wraz z poleceniem powrotu stanu bazy do zadanej przez zapamiętane id migawki. Usługa, jakkolwiek koncepcyjnie rozumiana jako system plików, nie ma być przedmiotem montowania jak w przypadku klasycznych systemów plików a wykorzystywać po stronie klienckiej np. zestaw napisanych prostych poleceń. Podejmując decyzję o ewentualnym ograniczeniu skali projektu należy dążyć do tego, by ewentualnie pominąć aspekty mniej istotne z punktu widzenia przedmiotu RSO, np. ew. interfejs graficzny czy rozbudowany analizator leksykalny języka zapytań. Nie wolno jednak w wymaganiach na system ograniczać zakresu wymagań niefunkcjonalnych istotnych z punktu widzenia przedmiotu RSO, takich jak: skalowalność, niezawodność, przezroczystość, obsługa czasowych niedostępności, czasowego rozpartycjonowania zasobów, itp. System powinien być uruchamialny w środowisku grupy komputerów pracujących w środowisku Linux. Projekt będzie można demonstrować albo w laboratorium 518, gdzie na 12 komputerach zainstalowany jest system Ubuntu, albo na komputerach własnych bądź środowiskach zdalnych. Ważne jest jedynie, by demonstracja gotowego rozwiązania mogła się odbywać fizycznie w sali 518 na komputerach laboratoryjnych bądź własnych, z których co najmniej część pracuje pod kontrolą systemu Linux. Efektem końcowym projektu powinny być: - własne działające oprogramowanie, - zautomatyzowana procedura prezentacji możliwości zrealizowanego oprogramowania (skrypt sh), - pełna dokumentacja projektu zawierająca co najmniej następujące pozycje: - uporządkowane wstępne opracowania, - szczegółową koncepcję zaproponowanego rozwiązania, w tym opis protokołu i API, - opis organizacji grupowego wytwarzania oprogramowania, przypisanych ról w projekcie, sprawozdanie z prac nad projektem, czyli listę spotkań roboczych wraz z datami i ustaleniami, - dokumentację techniczną proponowanego rozwiązania, - dokumentację testów, - dokumentację uruchamiania i konfiguracji systemu, - opis przygotowanych skryptów testowych i prezentacyjnych. Ważne: z dokumentacji musi jasno wynikać, kto i w jakim stopniu uczestniczył w realizacji poszczególnych elementów projektu. Narzędzia programistyczne ========================= Dowolny nieorientalny i dostępny język programowania. Należy wykazać się samodzielnym zaimplementowaniem algorytmów rozproszonych - czym bardziej zaawansowane mechanizmy będą wykorzystywane z gotowych bibliotek programistycznych, tym bardziej zaawansowane kompleksowo rozwiązanie będzie oczekiwane i wymagane od zespołu projektowego. Do realizacji komunikacji w środowisku rozproszonym prowadzący proponuje wykorzystanie narzędzia Apache Thrift wraz z jego uniwersalnym językiem opisu interfejsu i obsługą kilkunastu najpopularniejszych języków programowania. Istnieje możliwość wykorzystania innej pośredniej warstwy komunikacyjnej, ale wymaga to akceptacji prowadzącego przedmiot najpóźniej podczas oceny pierwszego etapu projektu (pierwszy krok milowy). Rozwiązanie należy obowiązkowo zademonstrować w laboratorium 518 na jeden z następujących sposobów: na lokalnych Linuksach, przez dostęp terminalowy bądź portalowy, na własnej mobilnej minisieci (laptopy i np. przyniesiony router). Uwaga, to na zespole spoczywa obowiązek upewnienia się, że zastosowano narzędzia i postawiono wobec środowiska wymagania, które umożliwiają sprawną demonstrację rozwiązania w sali 518. Do realizacja pracy grupowej (implementacja/dokumentacja) obowiązkowo wymagane będzie użycie systemu kontroli wersji, lokalnego bądź z jednego z portali udostępniających takie rozwiązania w sieci. Cała dokumentacja ma być przygotowana starannie spójnie w jednym środowisku (Latex/Word/OOffice) i z zachowaniem jednolitego formatowania. Ważne: wszystkie dokumenty, w formacie pdf, należy dodatkowo przesyłać prowadzącemu na e-mail. Do harmonogramowania zadań kierownicy projektów mogą użyć narzędzia, np. dostępnego pod Linuksem narzędzia Planner. Użycie narzędzia do harmonogramowania nie jest obowiązkowe, natomiast samo harmonogramowanie projektu jest obowiązkowe i musi mieć swój wyraźny ślad w dokumentacji. Ocenianie ========= Z przedmiotu RSO można zdobyć maksymalnie 100 punktów, 40 punktów z kolokwium oraz 60 (30 + 30) punktów z laboratorium. W celu zaliczenia przedmiotu wymagane jest uzyskanie minimum 50 punktów sumarycznie z kolokwium i laboratorium. Z laboratorium można uzyskać 60 punktów. Punkty uzyskiwane są z dwóch źródeł: 1. ocena projektu jako całości z końcowym rozdysponowaniem uzyskanych punktów przez kierownika projektu (0-30 punktów), 2. ocena indywidualna pracy każdego z członków zespołu przeprowadzona przez prowadzącego laboratoria po zakończeniu projektu (0-30 punktów). W trakcie semestru występują dwa terminy pośrednie oceniania postępów w realizacji projektów (tzw. kroki milowe). Na każdym z tych etapów prowadzący laboratorium ma możliwość przyznania do 5 punktów całemu zespołowi projektowemu. Natomiast końcowa ocena realizacji projektu to możliwość uzyskania 20 punktów. Zatem projekt sumarycznie oceniony jest przez prowadzącego w skali 0-30 punktów. Ocena indywidualna przez prowadzącego laboratoria daje możliwość uzyskania od 0 do 30 punktów włącznie. Przy ocenie uwzględniana jest m.in. dokumentacja pracy członka zespołu, uzyskana liczba punktów z oceny projektu jako całości, systematyczność pracy, obecność na wymaganych terminach oraz ocena rzeczywistego wkładu danego członka zespołu. Z tego względu bardzo ważnym jest, by w dokumentacji projektowej na każdym etapie było ściśle określone, który członek i w jakim stopniu jest odpowiedzialny za poszczególne części projektu. Nabyta liczba punktów jest automatycznie podwajana u kierownika danego projektu. Jednocześnie kierownik, na podstawie własnej oceny wkładu poszczególnych członków zespołu, decyduje o tym, ile punktów z dostępnej puli punktów przyznać każdemu z członków zespołu projektowego. Muszą być jedynie spełnione poniższe warunki: - średnia punktów przyznana członkom zespołu jest równa dokładnie liczbie punktów jaką uzyskał projekt, - każdy z członków zespołu projektowego musi uzyskać liczbę punktów z zakresu 0-30 punktów włącznie. Najprostszym rozwiązaniem spełniającym powyższe warunki jest przyznanie wszystkim członkom zespołu po tyle samo punktów, co uzyskał projekt i zarazem kierownik, jednak kierownik ma prawo do innego rozdziału punktów. Ważne: przy podziale punktów nie mogą być uwzględniane punkty osób, które w trakcie semestru wycofały się z danej grupy projektowej bądź w ogóle z realizacji przedmiotu. Grupy projektowe ================ Zadania realizowane są w grupach projektowych. Każda grupa ma przypisany termin (A - 12-14 i B - 14-16) oraz tydzień (nieparzysty - grupy 1 i 2 oraz parzysty - grupy 3 i 4), w którym ma do dyspozycji laboratorium 518. Taki podział gwarantuje, iż przy oddawaniu kroków milowych w danej chwili w laboratorium znajduje się ograniczona liczba grup projektowych. Ścisły harmonogram przedstawiony jest na końcu niniejszego opracowania. Wymagania odnośnie realizacji zadania projektowego ================================================== Realizacja zadania podzielona jest na trzy oceniane osobno fazy. Faza pierwsza kończy się pierwszym krokiem milowym, druga drugim krokiem, a trzecia demonstracją końcową projektu i przekazaniem pełnej dokumentacji projektu. Na zajęciach, na które wypada oddanie kolejnej fazy projektu obecność _wszystkich_ członków zespołu jest obowiązkowa. Uwaga, w pozostałych terminach laboratorium istnieje możliwość udostępnienia sali 518, ale pod warunkiem wysłania co najmniej dzień wcześniej na e-mail prowadzącego informacji o zamiarze skorzystania z laboratorium. Wstępna faza jest fazą zapoznawania się z zagadnieniem do realizacji, dostępnymi narzędziami, środowiskiem uruchomieniowym, dostępnymi opracowaniami z poprzednich lat. Faza ta wymaga następujących kroków do realizacji na zajęciach wstępnych: - organizacja grup projektowych, żaden student nie może zostać poza grupą projektową, - przypisanie terminu do grupy, - wybór kierownika projektu, Rolą kierownika będzie następnie ustalenie ról poszczególnych członków projektu. W grupie projektowej powinny zostać wyróżnione co najmniej następujące role: a. kierownik projektu, b. architekt - osoba odpowiedzialna za wytworzenie architektury rozwiązania, c. osoba odpowiedzialna za przygotowanie i zarządzanie repozytorium projektu oraz przechowywanie aktualnej kopii zapasowej projektu, d. dokumentalista - osoba odpowiedzialna za zarządzanie dokumentacją projektu, zbieranie i ujednolicanie dokumentacji technicznej pisanej przez innych członków zespołu oraz m.in. protokołowanie ustaleń z poszczególnych spotkań roboczych zespołu projektowego, e. tester - osoba odpowiedzialna za przygotowanie planu testów, w tym testów obciążeniowych, niezawodnościowych i synchronizacyjnych, ich przeprowadzenie oraz opisanie, f. handlowiec - osoba odpowiedzialna za przygotowanie powtarzalnej, maksymalnie zautomatyzowanej (skrypty shell) demonstracji końcowej prototypu (trzeci krok milowy) oraz sprawne przeprowadzenie końcowej demonstracji możliwości rozwiązania prowadzącemu, Kierownik wyznacza i przydziela powyższe oraz dodatkowe role. Wszystkie osoby z przydzielonymi rolami za wyjątkiem kierownika projektu mogą wchodzić w skład zespołu programistycznego realizującego projekt. Kierownik projektu ma zakaz uczestniczenia bezpośrednio w pracach implementacyjnych. FAZA 1 ------ W trakcie pierwszej fazy każdy z zespołów ma za zadanie zrealizować poniższe opracowania. Wymagane pisemne opracowania: 1. Opis rozwiązania Apache Thrift 2. Uruchomienie dostępnych w sieci przykładów demonstrujących wykorzystanie Apache Thrift i opisanie uruchomień w raporcie 3. Koncepcja i architektura rozwiązania własnego opisana m.in. przez zestawienie wymagań funkcjonalnych i niefunkcjonalnych 4. Harmonogram realizacji projektu z pełnym zdefiniowaniem i przydziałem ról w projekcie osadzonych w czasie realizacji projektu 5. Organizacja środowiska programistycznego projektu Pierwszy krok milowy to zakończenie realizacji powyższych opracowań i przekazanie ich w postaci papierowej osobie prowadzącej laboratorium. FAZA 2 ------ Faza druga ma następujące zadania: - opracowanie szczegółowej koncepcji rozwiązania, - realizacja prototypu oferującego ograniczoną funkcjonalność, - opracowanie pełnego planu testów, - opracowanie scenariusza końcowej demonstracji projektu. Zaliczenie tego etapu projektu, to przedstawienie dokumentacji ze szczegółową koncepcją rozwiązania docelowego oraz demonstracja zrealizowanego prototypu (stan "już coś działa"), który oferuje ograniczoną funkcjonalność. Na tym etapie nie jest wymagana kompletna dokumentacja, a demonstracja prototypu nie musi być automatyczna, jednak system ma już dla wybranych scenariuszy oferować pełną funkcjonalność. FAZA 3 ------ Faza trzecia to dokończenie realizacji projektu, skompletowanie dokumentacji, przeprowadzenie testów i demonstracji rozwiązania, czyli dostarczenie wszystkich wymaganych efektów końcowych projektu. Tu można zdobyć najwięcej punktów. Terminy laboratorium i harmonogram oceniania ============================================ data tydzień I tydzień II A1,A2,B1,B2 A3,A4,B3,B4 11.03 18.03 25.03 01.04 08.04 1* 1* 15.04 29.04 06.05 2* 13.05 2* 20.05 27.05 03.06 3* 10.06 3* * - w tym terminie można uzyskać punkty za projekt. Obecność _wszystkich_ członków grupy w terminie kroku milowego jest _obowiązkowa_.