2016.03.04 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ę bezpiecznej niezawodnej dystrybucji przetworzonej chronionej informacji. Zakłada się, że wewnętrzna warstwa wytwarza bądź ściąga z sieci informację wrażliwą i przekazuje w postaci przetworzonej do warstwy zewnętrznej świadcząej usługi udostępniania informacji przetworzonej rozwiązaniom klienckim. Na potrzeby projektu rozmiar i liczba wytwarzanych/przechowywanych informacji powinna być nietrywialna (co najmniej setki MB). Docelowy przedmiot rozwiązania implementowanego przez każdą grupę projektową każda grupa projektowa ma za zadanie doprecyzować w ramach pierwszego etapu realizacji projektu. Usługa powinna: - miec 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) wewnętrznej wytwarzającej, przechowującej i przesyłającej przetworzoną wrażliwą informację, (2) warstwy zewnętrznej do udostępniania przetworzonej informacji oprogramowaniu klienckiemu usługi, - 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, stąd każda z warstw powinna być uruchomiona na co najmniej dwóch węzłach, - zapewniać realizację usługi w trakcie awarii w czasie obsługi, - obsługiwać scenariusz próby ponownego wpięcia się przez węzeł dowolnej z warstw, z którym wcześniej utracono łączność, a zarazem być odporną na próbę zastąpienia nieosiągalnego sieciowo węzła (np. w wyniku ataku DoS, odmowa usługi) węzłem wrogim do tego nieuprawnionym, - na bieżąco i transparentnie dla oprogramowania klienckiego zarządzać dostępnymi zasobami lokalizacyjnymi, - zapewniać zadany (większy niż 1 ale dopuszczalny konfiguracją 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ęść sewerowa usługi powinna być startowana i zamykana jednokrotnym wywołaniem skyptu na jednym węźle serwera z jednym argumentem (wykorzystanie nieinteraktywnych metod automatycznego uwierzytelniania węzłów w SSH), 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. ewentualny 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 demonstrowac albo w laboratorium RSO.B, 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ę fizycznie odbywać w sali laboratorium RSO.B. Wymagane jest co najmniej dla części serwerowej wykorzystanie środowiska systemu Linux Postępy prac i wersja finalna mają być uruchomione, przetestowane i zademonstrowane w środowisku systemu Linux (Ubuntu 14.04 LTS) w laboratorium RSO.B. Efektem końcowym projektu powinny być: - własne działające oprogramowanie, - zautomatyzowana procedura prezentacji możliwości zrealizowanego oprogramowania (obligatoryjnie w postaci skryptu sh, z podziałem na etapy i np. wciskaniem podczas demonstracji ), - pełna dokumentacja projektu zawierająca co najmniej następujące pozycje: - uporządkowane wstępne opracowania, - doprecyzowaną względem treści szczegółową koncepcję zaproponowanego rozwiązania, - 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 ========================= Obligatoryjne: całe oprogramowanie powinno być przygotowane do dystrybucji i instalacji w postaci paczek docker (www.docker.com). Jako narzędzie 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. Rozwiązanie należy obowiązkowo zademonstrować w laboratorium RSO.B na jeden z następujących sposobów: na lokalnych Linuksach, przez dostęp terminalowy bądź portalowy, na własnej mobilnej minisieci (np. laptopy połączone własnym routerem). 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 laboratorium RSO.B. 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 i z zachowaniem jednolitego formatowania. Dokumentacja po każdym etapie powinna mieć postać jednego pliku pdf. Przed prezentacją kroku milowego plik pdf należy obowiązkowo przesłać prowadzącemu na e-mail z zadaniem w tytule identyfikatora grupy projektowej. Na oddawanie etapu należy również mieć wydrukowaną na papierze tę część dokumenacji, która została wytworzona bądź zaktualizowana po poprzednim kroku milowym. 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 (12-14 lub 14-16), w którym ma do dyspozycji laboratorium 518. Harmonogram przedstawiony jest na końcu niniejszego opracowania. Za realizację projektu przez daną grupę odpowiada kierownik projektu i cały zespół projektowy. 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. 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 mozliwości rozwiązania prowadzącemu, g. specjalista od rozwiązania docker i trener dockera dla pozostałych członków zespołu. 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 Docker 2. Uruchomienie dostępnych w sieci wybranych konfiguracji demonstrujących wykorzystanie Docker 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 osoadzonych 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 demonostracji 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 krok milowy 21.04 1 05.05 2 09.06 3 Podany termin dla grup czwartkowych, grupy piątkowe mają termin o dzień później. W powyższych terminach można uzyskać punkty za projekt. Obecność wszystkich członków grupy w terminie kroku milowego jest obowiązkowa.