David Staščák

Transkript

1 FRONTGROUP Projekt SPRÁVCE Dokumentace David Staščák

2 Project Overview Statement Problém Náš software by měl řešit problém komunikace ve větších organizacích. Je běžné, že velké i malé firmy, ale i jiné subjekty(například ČVUT), pracují na různých projektech, k čemuž potřebují dát dohromady skupinu lidí. Čím je ovšem firma větší, tím těžší tento úkol je, protože se objevují problémy s komunikací a šířením informace. Jak najít a oslovit ty správné lidi? Jak poznat kdo se pro projekt hodí a kdo by měl zájem se na něm účastnit? K tomu může dopomoci náš software. Často se stává, že lidé, kteří by byli pro projekt vhodní a měli by zájem se na něm podílet, se o něm vůbec nedozví, to chceme změnit. Cíl Chceme dopomoci k tomu, aby bylo pro člověka starajícího se o průběh projektu snadné sestavit kvalitní tým lidí a tím zefektivnit práci celé organizace. Naším cílem je vytvořit software umožňující snadné vyhledávání v databázi zaměstnanců a jejich oslovení k účasti na projektu. Databáze bude obsahovat informace o zaměstnancích a jejich kvalitách a schopnostech. Kritéria úspěchu Pro úspěch našeho projektu je klíčová podrobná projektová dokumentace. Naši aplikaci je potřeba ozkoušet v praxi a tím pádem je potřeba nasadit ji na server. Jelikož se jedná o školní projekt jehož výstupem nemusí být 100% funkční software, bude postačujícím kritériem našeho úspěchu několik hlavních funkcí. Příklad hlavních funkcí: Tvorba uživatelských profilů, správa uživatelských profilů, editace informací, tvorba týmu, přidání člena do týmu, login uživatele, změna hesla uživatele, smazání uživatelského profilu. Pokud se nám podaří implementovat 7-8 z těchto funkcí, budeme to považovat za úspěch. Překážky a rizika Hlavní překážkou je určitě nedostatek času. Náš tým je složen z několika studentů, jejichž rozvrhy se často velmi liší, je proto často problém aby se celý tým sešel, když je potřeba projednat nějaké důležité otázky týkající se projektu. Nemluvě o tom, že někteří už mají vlastní práci, jíž se musí věnovat. Občas někdo onemocní apod. Dalo by se říci, že největší překážkou je pracovní vytížení způsobené prací na několika různých projektech. Další velkou překážkou je bezpochyby naše nezkušenost. Je to pro nás poprvé co máme v týmu vytvořit kompletní projekt včetně dokumentace. Nikdo z nás například neví jak dlouho která část přípravy trvá, může snadno dojít k podcenění úlohy a časovému skluzu. Zadání je nekompletní. Nemáme žádného konkrétního zákazníka se kterým bychom mohli jednat a tak je vymyšlení celého projektu na nás. Naše schopnosti jsou na různé úrovni, naše aplikace bude vyžadovat znalosti databázových a serverových systémů a různých programovacích jazyků, je možné(dokonce pravděpodobné), že ne všichni budou moci přispět stejným dílem k implementační části naší úlohy.

3 Předpoklady úspěchu Všichni máme s programování už nějaké zkušenosti. Určitě se mezi námi najde vždy alespoň jeden člověk který ovládá technologii jež bude potřeba. Spoustu informací včetně odborné konzultace získáváme na cvičeních a přednáškách předmětu a4b33si, měli bychom tedy být schopni postupovat podle jakéhosi harmonogramu a vše stihnout. Je potřeba zajistit server ke zkušebnímu provozu naší aplikace. F U R P S Funkcionalita Základním kamenem našeho softwaru budou uživatelské účty, proto je samozřejmostí jejich jednoduchá tvorba editace a mazání. Správu účtů bude zajišťovat administrátor, jejich editaci pak budou provádět sami zaměstnanci. Dále je potřeba personalista, který bude zajišťovat pravdivost informací. Náš software by měl především umožnit efektivně vyhledávat vhodné lidi k práci na projektech, důraz proto bude kladen hlavně na možnost vyhledání těch nejvhodnějších lidí a sestavení kvalitního týmu. To bude provádět projektový manažer. Užitečnost Náš software by měl sloužit jako nástroj pro vyhledávání v databázi zaměstnanců a jejich zkušeností/předností. Dále poslouží k samotnému sestavování týmů k práci na různých projektech. Jeho účel je tedy v podstatě efektivní správa lidských zdrojů. Uživateli tohoto systému budou tedy především projektový manažeři.

4 Uživatelská použitelnost Naše aplikace bude splňovat zásady pro uživatelsky příjemně navržené prostředí. O těchto zásadách více na stránkách předmětu TUR(Testování uživatelského rozhraní - A4B39TUR) - Spolehlivost O relevantnost údajů se bude starat personalista, který bude jednotlivé informace o zaměstnancích spravovat. Vzhledem k jednoduchosti aplikace se dá předpokládat její malá chybovost. Při nasazení hodláme pro naše testování použít freehosting, jehož dostupnost není vždy zaručena. V ostrém provozu si ji každá firma zajistí vlastním serverem. Výkon Software je zamýšlen jako pomůcka pro větší organizace(např zaměstnanců), kde není možné aby projektoví manažeři znali schopnosti všech lidí, ze kterých si mohou vybírat. Ke svému chodu systém potřebuje administrátora a několik personalistů(podle velikosti organizace), kteří budou zajišťovat relevantnost uživatelských profilů. Rozšiřitelnost Je zde velký potenciál spojit náš systém např. s burzou projektů, kde by naopak sami zaměstnanci měli možnost se do projektů přihlašovat, či softwarem pro správu jednotlivých týmů. Naše ambice jsou jednoduché a dobře dokumentované aplikační rozhraní, které nebude těžké dále upravovat.

5 Kontextový model Analýza a návrh pro Systém Správce Toto je analýza aplikace Systém Správce, která slouží k alokaci zaměstnanců vedených v

6 databázi do týmů. Jedná se o pomůcku projektových manažerů. Rozbor požadavků Funkční požadavky 1. Přístup Popis: Uživatel aplikace se může do systému přihlásit pomocí platného uživatelského jména a hesla. Priorita: Akceptační kritérium: must have Libovolný registrovaný uživatel se může přihlásit do aplikace. 2. Změna hesla Popis: Uživatel si může změnit heslo. Priorita: Akceptační kritérium: must have Přihlášený uživatel si může změnit svoje heslo. Požadavky podle rolí Role určuje, jakou funkčnost bude mít daný uživatel k dispozici. Admin 1. Správa systému Popis: Systém vždy obsahuje správcovský účet "admin". Priorita: Akceptační kritérium: must have Do čisté instalace aplikace se dá přihlásit pod ID "666" a heslem "admin". 2. Založení uživatelského účtu. Popis: Admin může vytvořit nového registrovaného uživatele v některé z rolí zaměstnanec, personalista nebo projektový manažer. Priorita: Akceptační kritérium: must have Admin může vytvořit řádově desítky registrovaných uživatelů v rolích projektový manažer a personalista a řádově stovky uživatelů v roli zaměstnanec. 3. Změna hesla registrovaného uživatele Popis: Admin může změnit libovolnému uživateli heslo. Priorita: Akceptační kritérium: must have Admin může změnit heslo libovolnému registrovanému uživateli v systému. 4. Smazání existujícího uživatelského účtu

7 Popis: Admin může smazat libovolného uživatele. Priorita: Akceptační kritérium: must have Admin může smazat libovolný účet v systému, kromě sebe. Projektový manažer Projektový manažer může spravovat týmy a přidávat do nich zaměstnance. 1. Přidání týmu Popis: Projektový manažer může vytvořit tým a určit jeho jméno a popis. Automaticky se stane jeho vedoucím. Priorita: Akceptační kritérium: must have Po přihlášení v roli projektového manažera je možné založit nový tým a určit u něj jméno a popis. Položka vedoucí týmu je asociována se zakládajícím uživatelem. 2. Editace týmu Popis: Projektový manažer může změnit název, popis a vedoucího týmu, který sám vede. Priorita: Akceptační kritérium: should have Po změně libovolné vlastnosti se tato projeví ve zbytku systému. Pokud projektový manažer změní vedoucího týmu, tak mu tým zmizí z výpisu vlastních týmů a taky ho nebude moci dále upravovat. 3. Smazání týmu Popis: Projektový manažer může smazat svůj tým. Priorita: Akceptační kritérium: should have Tým po smazání zmizí z databáze spolu s veškerými asociovanými údaji. 4. Prohledávání databáze profilů Popis: Projektový manažer může prohledávat databázi podle všech položek profilu. Priorita: Akceptační kritérium: should have Manažer zadá kritéria vyhledávání a zpět dostane seznam vyhovujících profilů. 5. Přidání člena týmu Popis: Projektový manažer může z výpisu vyhledaných profilů přidat člena do týmu. Priorita: Akceptační kritérium: should have U každého profilu ve výsledku vyhledávání je zobrazeno tlačíko "Add to team". Po jeho stisknutí se vybraný profil přidá do týmu jako člen. 6. Pozvánka Popis: Projektový manažer může rozeslat pozvánku všem členům týmu. Priorita: Akceptační kritérium: should have Po sestavení týmu může projektový manažer zaslat všem

8 nepotvrzeným členům týmu pozvánku na ovou adresu uvedenou v profilu. Zaměstnanec 1. Správa profilu Popis: Zaměstnanec může upravovat informace ve svém profilu. Priorita: Akceptační kritérium: must have Po přihlášení do aplikace v roli zaměstnance je možné upravovat položky asociovaného profilu a změny uložit nebo zrušit. 2. Potvrzení pozvánky Popis: Zaměstnanec může potvrdit nebo zamítnout pozvánku do týmu. Priorita: Akceptační kritérium: should have V pozvánce jsou obsaženy dva odkazy. Jeden zajišťuje potvrzení a druhý zamítnutí členství v týmu. Personalista Personalista schvaluje informace, které o sobě zaměstnanci uvedli. 1. Schválení profilu Popis: Personalista může schválit jednotlivé položky profilu. Priorita: Akceptační kritérium: nice to have V profilu má personalista možnost schválit jednotlivé položky. Nefunkční požadavky 1. Desktopová aplikace Uživatelé budou k systému přistupovat pomocí desktopové aplikace, která umožní přihlášení do systému a správu tohoto přihlášení a dále vykonávání všech činností dostupných danému typu účtu. 2. Databáze Systém využívá databázi k ukládání dat. 3. Víceuživatelský systém Se systémem může pracovat naráz víc uživatelů nezávisle na sobě. 4. Výkon Systém zajišťuje správu uživatelů. 5. Bezpečnost dat Informace vedené v aplikaci jsou dostupné jen po přihlášení.

9 Příklady užití Analytický model tříd

10 Popis tříd Klientská aplikace EmployeeFrame Třída vykresluje GUI pro editaci jednotlivých profilů. LoginFrame Přihlašovací obrazovka. Zajišťuje připojení k serveru a ověření uživatele. MainFrame Hlavní okno aplikace, které se otevře po přihlášení. Obsahuje menu s funkcemi společnými pro všechny role. Dále obsahuje menu s funkcemi specifickými pro danou roli. Obsahem okna jsou informace o profilu uživatele. ChangePassDialog Tato třída zobrazuje dialog sloužící ke změně hesla uživatele. Role Rozhraní s funkcemi charakterizujícími uživatelskou roli. AdminRole Třída implementující rozhraní Role. Zajišťuje funkčnost související se správou uživatelů. Main Spouštěcí třída, která vytvoří prvotní GUI pro přihlášení. ServerConnectionInterface Rozhraní pro třídu komunikující se serverem. ServerConnection Třída implementovaná ze ServerConnectionInterface, fungující jako singleton, sloužící ke komunikaci se serverovou aplikací. Item Třída představující položku dovedností zaměstnance. FrameGroups Implementace GUI pro správu skupin uživatelů. FrameItems Implementace GUI pro správu globálních položek dovedností. FrameEditGroup Implementace GUI pro editaci a přiřazování položek dovedností skupiny. Source Třída, která si nechá poslat veškeré informace o uživateli ze serverové aplikace a umožňuje s těmito informaci dále pracovat jiným třídám. User

11 Třída představující uživatele. Uchovává si všechna data o uživateli. Team Třída představující tým. Uchovává si všechna data o týmu. FramePMShowTeams Implementace GUI pro zobrazování týmů projektovému manažerovi. FramePMEditTeam Implementace GUI pro vytváření a editaci týmu. PMRole Třída implementující rozhraní Role. Zajišťuje funkčnost související se správou týmů. ViewProfile Prostá třída sloužící k vykreslení jedné ze základních obrazovek našeho systému - okno s osobními údaji. SourceUserInt, SourceGroupInt, SourceTeamInt, SourceItemInt Rozhraní pro třídy oddělující kódování a dekódování komunikace se serverem od objektových dat. Každé rozhraní má navržené metody pro kontrolu chyb na straně serveru, jedná se o metody umožňující přidávání, odebírání, update a získávání jednotlivých elementů. SourceUser, SourceGroup, SourceTeam, SourceItem Jedná se o implementaci předchozích rozhraní. TeamStatus, ItemsStatus Třída představující elementy a jejich vztahy k ostatním elementům. Serverová aplikace ClientConnection Třída spouštějící se jako samotné vlákno, přes kterou se komunikuje s jednotlivými klienty. Vzniká a zaniká při připojení a odhlášení uživatele. Main Třída poslouchající na portu připojení klientů a přidávající jim komunikační třídu. Protocol Třída na základě příchozího požadavku od klienta získá instanci třídy Worker, na které volá metody pro zpracování požadavku. Worker Jedná se o třídu navrženou podle návrhového vzoru Factory. Vytváří objekty, které zpracovávají všechny možné požadavky od klienta. DBCInt Rozhraní pro třídu komunikující s databází.

12 DBConnection Třída komunikující s databází. Obsahuje metody vracející Stringy, které jsou posílány klientovi. UserData Slouží k vytvoření Hashmapy ve třídě Protocol. Popis protokolu Textový protokol komunikace mezi klientem a serverem. Symbol "větší než" značí komunikaci od klienta k serveru. Symbol "menší než" představuje odpověď serveru. Server na požadavek zpravidla odpoví zprávou OK, pokud požadavek vyřídil v pořádku, nebo KO spolu s vysvětlujícím textem. role: Neověřený uživatel > LOGIN use pass < ADMIN MANAGER EMPLOYEE HR KO duvod Heslo hashované (nice to have). Odpovědí serveru je role uživatele a nebo KO, pokud došlo k chybě přihlášení. role: Přihlášený uživatel > CHANGE_PASS user_id old_pass new_pass role: admin přídání uživatele: > ADD_USER role group pass < user_id KO důvod smazání uživatele: > DEL_USER user_id změna hesla uživatele: > ADMIN_CHANGE_PASS user new_pass update uživatele: > UPDATE_USER user_id name lastname address city phone professia žádost o přijetí informací uživatele: > GET_INFO iduser < idrole;idgroup;name;lastname;address;city; ;phone;professia KO důvod (jedná se pouze o atributy usera,tzn. bez teams a items)

13 získat všechny id uživatelů v User tabulce: > GET_USERS > id_user1;... KO důvod (bez mezer za středníkem) získat skupiny dostupné v systému: > GET_GROUPS > id_group1 name1 pocet_items1 item1_id item2_id;id_group2 name2 pocet_items2 item1_id item2_id... KO důvod (bez mezer za středníkem) získat všechny položky dovedností ve spojovací tabulce: > GET_ITEMS > id_item1 name1;... KO důvod (bez mezer za středníkem) získat všechny týmy v databázi: > GET_TEAMS > id pm name goal project info active;... KO důvod (bez mezer za středníkem) přidání položky dovednosti: > ADD_ITEM nazev odebrání položky dovednosti: > DEL_ITEM nazev úprava položky dovednosti: > UPDATE_ITEM id_item nazev přidání týmu: > ADD_TEAM pm nazev project info goal úprava týmu: > UPDATE_TEAM id_team nazev project info goal smazání týmu:

14 > DEL_TEAM id smazání týmu: > DEL_GROUP id_group přidání group: > ADD_GROUP name pocet_items id_items1 id_items2... úprava group: > UPDATE_GROUP id_group name pocet_items id_items1 id_items2... úprava položky dovednosti: > EDIT_ITEM id_item nazev získat id položek dovedností pro určitého uživatele: > GET_USER_ITEMS id_user > id_item state;... KO důvod získat id týmů pro určitého uživatele: > GET_USER_TEAMS id_user > id_team confirmed;... KO důvod přidání uživatele do týmu: > USER_IN_TEAM id_user id_item odebrání uživatele z týmu: > USER_OUT_TEAM id_user id_item změna stavu účasti uživatele v týmu: > SET_TEAM_CONFIRMED id_user id_team confirmed změna stavu dovednosti uživatele: > SET_ITEM_STATE id_user id_item state získat všechny uživatele v týmu s id:

15 > GET_TEAM_USERS id_team > id_user confirmed;... KO důvod (bez mezer za středníkem) získat všechny týmy pro PM s id: > GET_PM_TEAMS idpm > id pm name goal project info active;... KO důvod (bez mezer za středníkem) Architektura Klientská aplikace pomocí grafického rozhraní posílá požadavky serverové aplikaci. Požadavky jsou ve formě textového řetězce v tvaru zaznamenaném v protokolu. Serverová aplikace pomocí protokolu rozpozná požadavek a reaguje připojením k databázi, kde se provede požadovaný SQL dotaz. Následně je klientská aplikace informována o úspěchu či neúspěchu. V případě neúspěchu je konkretizovaný jeho důvod. Výsledek je zobrazen v grafickém prostředí. Návrh databáze

16 Návrh uživatelského rozhraní Následují náčrty uživatelského rozhraní. Jedná se o úvodní studie, skutečné rozhraní aplikace se může lišit. Přihlášení Návrh přihlašovací obrazovky.

17 Správa uživatelů dostupná v roli admin. Návrh pro správu skupin zaměstnanců a jejich dovedností

18 Správa týmů a přidání týmu v roli projektového manažera Testy Plán testů Účelem testů bude ozkoušení interakcí tříd modelu, tříd zajišťujících komunikaci mezi serverem a klientem a tříd obsluhujících databázi. Znamená to, že testy se nebudou snažit ozkoušet všechny kombinace vstupních a výstupních

19 hodnot. Uživatelské rozhraní se nebude testovat. Bude se vesměs jednat o blackbox testy na úrovni veřejných metod tříd. K tomuto účelu bude využita suita junit. SourceGroupTest Tento test využívá techniku mockupu. Třída SourceGroup normálně zajišťuje výměnu informací o skupinách se serverem. Spojení se nahrazuje pomocí třídy SCMockup, která slouží k zachycení zpráv zasílaných serveru a fingování odpovědi. Přehled testcase: testaddgroup - přidání skupiny testdelgroup - smazání skupiny testupdategroup - odebrání skupiny testloaddataandgetgroup - společný test metod loaddata(), getgroup() a getallgroups() SourceUserTest Tato třída je testována podobně jako třída SourceGroup. Za zmínku stojí test metody loaddata. Tato metoda je složitá a v každém volání se několikrát připojuje na server a komunikuje s ním. Proto je v odpovídajícím testu vytvořen zvláštní mockup serverového spojení - místní třída MultiSCMockup. Ta je schopna zaznamenat opakované volání metody sendmsg. Jednotlivé zprávy jsou uchovány v atributu messages, což je seznam (implementace rozhraní List). Pro každé volání sendmsg je třída schopna poskytnout jinou odpověď. Seznam možných odpovědí je poskytnut v době vytváření třídy ve formě pole řetězců. Odpovědi sendmsg jsou z tohoto pole poskytovány postupně podle toho, jak v něm byly uloženy. Test metody loaddata zároveň ověřuje i metodu getuser, protože spolu souvisí (loaddata naplní instanci SourceUser a getuser ji potom čte). Přehled testcase: testadduser testdeluser testsetteam testdelteam testsetitemstate testsetteamconfirmed testupdateuser testloaddataandgetuser SourceItemTest Tento test využívá techniku mockupu. Třída SourceItem normálně zajišťuje výměnu informací o položkách dovedností se serverem. Spojení se nahrazuje pomocí třídy SCMockup, která slouží k zachycení zpráv zasílaných serveru a fingování odpovědi. Přehled testcase: testadditem přidání položky dovedností testdelitem smazání položky dovedností testupdateitem odebrání položky dovedností testloaddataandgetitem společný test metod loaddata(), getitem() a getallitems()

20 WorkerTest Tento test využívá techniku mockupu. Třída Worker je ve stylu návrhového vzoru Factory a má pro všechny možné požadavky od serveru implementované metody pro zpracování. V testu se používá fiktivní třída pro komunikaci s databází, na které se volají příslušné metody. Třída Worker je otestována všemi požadavky a kontroluje se zde, zda-li byla vrácena správná instance Worker a zda-li je správně nastavena metoda pro kontrolu počtu parametrů požadavku. Přehled testcase: viz protokol komunikace... SourceTeamTest Tato třída je testována podobně jako třída SourceUser. Metody, které čtou data z databáze (loaddata, loaddatafrompm a loaduserstatusinteam) jsou testovány pomocí MultiSCMockup (která je popsána v SourceUserTest). Test metody loaddata zároveň ověřuje i metodu getteam, protože spolu souvisí (loaddata naplní instanci SourceTeam a getteam ji potom čte). V dalších načítacích metodách už není znovu metoda getteam testotvána, protože se předpokládá, že již funguje. Metody, která naopak data do databáze zapisují, jsou testovány pomocí SCMockup. Metody, které jenom vrací již načtená data a samy o sobě z databáze nic nenačítají, testovány nebyly. Přehled testcase: testloaddataandgetteam testloaddatafrompm testloaduserstatusinteam testaddteam testdelteam testupdateteam DBCTest Všechny metody v databázi jsou testované naráz v jedné metodě, na rozdíl od ostatních testů. Pro testovací účely byl vytvořen klon používané databáze, která obsahuje redukované množství testovacích dat. V metodě testit() jsou postupně vyzkoušeny všechny metody třídy DBConnection, kde se v každém případě kontroluje výstup z metody a porovnává se s hodnotami, které byly předem zjištěny. Na konci testování se všechna vložená data vymažou. To zajistí, že data v databázi po každém testu zůstávají nezměněna. Přehled testcase: testit()

21 Plán projektu Jméno projektu: Systém Správce Zahájení projektu: Plánované ukončení projektu: Členové: Radim Tobolka, Jan Ševců, Petr Matějů, Lukáš Vydržel, David Staščák, Jozef Matúš Klient: Ondřej Macek, WBS(Work Breakdown Structure) Naše WBS je poněkud široká, takže zde je rozdělena na jednotlivé podstromy, které mají společný kořen.

22

23 Odhad trvání úloh Tyto odhady jsme vytvořili tak, že jsme každý podle našich dosavadních zkušeností navrhli čas, jak dlouho by mohla daná úloha trvat. Člověk s nejvyšším a nejnižším návrhem zdůvodnil, proč navrhl to, co navrhl. Poté se návrh a zdůvodňování opakovalo a nakonec proběhl návrh třetí. Z těchto návrhů byl potom vypočten aritmetický průměr a jeho výsledek byl vzat jako odhad, jak dlouho bude potřeba na vypracování dané úlohy (tzv. časový poker). Všechny údaje jsou uvedeny v hodinách. Založení 5 Dokumentace 50 Uživatelské rozhraní 50 Databáze 5 Registrovaný uživatel 4 Přihlášení/odhlášení 3 Sessions 2 Šablona 9 Změna hesla 2 Založení nového uživatelského účtu 3 Vypsání uživatelů 4 Úprava profilu 4 Obnova hesla 2 Smazání existujícího uživatelského účtu 1 Přidání/smazání týmu 5 Přidání/odebrání člena 6 Prohlížení týmů 19 Pozvánka 7 Schvalování profilů 4 Dokončení 20 Reálný čas strávený na projektu Z výkazu práce vznikl rozpis uvedený níže. Celkový čas strávený na projektu (podle výkazu práce) je 257 hodin. Náš odhad byl však mnohem nižší 156 hodin. Jedním z důvodů takového rozdílu je naše malá zkušenost s takovýmto projektem a proto špatné odhady časů jednotlivých úloh. Dalším důvodem bylo projevení některých rizik, se kterými jsme na začátku projektu nepočítali (podrobněji v bodě Plán rizik). Všechny údaje jsou uvedeny v hodinách. Položky, u kterých je uvedena nula, se buď neimplementovali (protože byly nice to have), nebo bylo těžké přiřadit k nim konkrétní číslo. Založení 2,5 Dokumentace 71 Uživatelské rozhraní 46 Databáze 24 Registrovaný uživatel 5 Přihlášení/odhlášení 4 Sessions 0 Šablona 0 Změna hesla 4 Založení nového uživatelského účtu 4 Vypsání uživatelů 2 Úprava profilu 7 Obnova hesla 2 Smazání existujícího uživatelského účtu 2 Přidání/smazání týmu 5 Přidání/odebrání člena 4 Prohlížení týmů 3 Pozvánka 0 Schvalování profilů 0 Dokončení 10

24 Vykazování a plánování úkolů Úkoly jsme se snažili plánovat tak, abychom stíhali všechny potřebné dokumenty odevzdávat včas. Plán jejich odevzdávání si určil klient (v našem případě cvičící) na jeho webových stránkách ( Úkoly jsme plánovali a vykazovali pomocí sekce Issues na portále github.com. Jejich celkový přehled je k vidění na adrese Následuje krátká statistika z těchto stránek. Celkem bylo vypsáno 48 úkolů. Na 7 úkolech pracovalo více lidí. Jan Ševců Radim Tobolka Petr Matějů Lukáš Vydržel David Staščák Jozef Matúš 2 úkoly, oba z oblasti dokumentace; potom přestal pro tým pracovat 10 úkolů, polovina dokumentace, polovina implementace 6 úkolů, polovina dokumentace, polovina implementace 4 úkoly, všechny z dokumentace (dělal i implementaci, ale ta nebyla vypsána do úkolů) 9 úkolů, většina dokumentace 10 úkolů, převážná většina implementace Standardně je v roli Approved jen jeden člověk - vedoucí týmu. V naší situaci se odpovědnost za dílo rozkládá na všechny členy a proto je v tabulce role "celý tým."cvičící má u všech úkolů roli Consulted, neboť nám asistuje při vypracování úkolů a Informed, neboť od nás přebírá výsledek práce a hodnotí ho.

25 Plán rizik Plán rizik je vyjádřen v následující tabulce: V podstatě nás postihlo rizik několik. Nejdříve nás postihlo, že nás jeden člen týmu naprosto opustil. Sice občas komunikoval a proto jsme se mu snažili dávat nějaké, alespoň jednoduché, úkoly. Vždy to ale dopadlo tak, že úkol nevypracoval a ten tak zůstal na nás zbývající. To samozřejmě ovlivnilo čas a asi i kvalitu. Dále to byl špatný odhad. Jelikož ještě nemáme tolik zkušení zejména s takto rozsáhlým projektem, při odhadování trvání jednotlivých úloh jsme skutečnou délku podceňovali a tak se skutečný a odhadovaný čas stále vzdalovaly. Dalším rizikem, se kterým jsme se museli vypořádat byla špatná komunikace a koordinace. Kvůli tomu jsme se zpozdili o další kus a skutečný čas se ještě více oddálil od toho odhadovaného. A nakonec nás samozřejmě potkalo riziko spojené s písemkami. Jednalo se hlavně o zápočtovou písemku z PSI, kterou někdo musel psát dokonce dvakrát. Mimo to sem patří i dvě zápočtové písemky z JAG. Nicméně toto riziko nemělo na projekt takový dopad, jako ta dvě předešlá.

26 Finanční plán Takto byl rozpočet stanoven na začátku projektu: Od té doby nebyl upravován a myslíme si, že ani moc upravit nepotřebuje. Doby jednotlivých částí projektu se sice změnily (testování bylo kratší, ale programování delší), ale součet všech časů je přibližně stejný. A protože jsou všechny doby násobeny stejnou částkou. Výsledná cena se prakticky nezměnila, takže můžeme říct, že původní rozpočet jsme dodrželi. Protože náš rozpočet vycházel ze síťového diagramu a z něj jsme nesplnili všechny položky, lze říci, že jsme podcenili časovou náročnost projektu a za stejné peníze a čas jsme dodali méně funkčnosti.

27 Závěrečná zpráva Tento dokument obsahuje závěrečné hodnocení aplikace Systém SPRÁVCE, jakož i hodnocení práce týmu FrontGroup, který tuto aplikaci vytvářel. Zhodnocení vzniklé aplikace Koncept programu jsme zvolili jako klient/server aplikaci, výhody to má ty, že jediný požadavek na klientské počítače je mít nainstalované JRE, které však většina počítačů má, jelikož je potřeba pro využití vlastností většiny webových stránek. Na rozdíl od konceptu webových aplikací nejsme tedy závislí na typu a verzi webového prohlížeče. Veškerá data jsou bezpečně uložená v databází se kterou komunikuje pouze serverová část aplikace. Všechny třídy jsou testovány JUnit testem, aby bylo dosažené co největší spolehlivosti. V nynější verzi programu nejsou implementované všechny případy užití, důvodem jsou časové možnosti a výpadky některých členů týmu. I tak aplikace disponuje spoustou funkcí. Jako přihlašování a odhlašování do/z systému, pro roli administrátora správa uživatelů, skupin uživatelů a položek dovedností včetně jejich přiřazování skupinám, pro projektového manažera správa týmů včetně přidávání a odebírání členů a pro všechny uživatele je tu možnost změny hesla a editace osobních údajů. V další verzi se počítá s doplněním dalších případů užití a designové úpravy GUI programu. Zhodnocení použité infrastruktury K práci na projektu náš tým využil několik komunikačních médií. Využili jsme výhod které nabízí služba googlegroups a vytvořili jsme si s její pomocí komunikační kanál, jímž jsme si vyměňovali ovou poštu. Během semestru se sice objevil menší problém s jejím nastavením, ale celkově pro nás tato služba byla užitečná. Kromě ové komunikace jsme také využili úložiště dokumentů, z důvodu pohodlného přístupu více uživatelů. Kromě ové komunikace jsme také využívali Skype, zpočátku hlavně pro konference které nám nahrazovali osobní setkání týmu, jež nebylo možné díky velkým rozdílům v rozvrzích jeho členů. Později byl využíván také pro řešení akutních problémů, hlavně s implementací. Základním kamenem naší infrastruktury se nakonec stal Github. Prvním důvodem bylo jeho využívání k odevzdávání práce v průběhu semestru. K tomu sloužila wiki v repozitáři našeho týmu. Její ovládání, jakož i ovládání celého githubu bylo zpočátku některým členům týmu záhadou. Je jisté, že ani po třech měsících používání jsme pravděpodobně neodhalili a nevyužili většinu jejího potenciálu. Stejné to pravděpodobně bude s funkcemi repozitáře samého, jež byl druhým důvodem proč jsme github vlastně využívali. Umožňuje efektivní práci více lidí na jednom projektu. Přes menší občasné problémy nám github jistě výrazně pomohl v dokončení celého projektu. V souvislosti s githubem

28 bychom měli také zmínit Issues možnost vypisování úkolů, které nám pomohlo s organizováním naší práce. Zhodnocení projektu na základě vykázaného času, finančního plánu Naplánovaný čas se nám bohužel většinou nepodařilo dodržet. To platí jak z hlediska našeho odhadu trvání jednotlivých úloh, hlavně ve fázi implementace, tak z hlediska rozpočtu, který jsme pro náš projekt měli naplánovaný. Pokud by tedy náš tým pracoval ve skutečné firmě, tak by jsme pravděpodobně neobstáli. Příčinou našeho neúspěchu by určitě byla nezkušenost a z ní plynoucí špatné odhady a také to, že rozpočet byl opravdu jen nahrubo nastřelený také díky absenci zkušeností z praxe. Na druhou stranu na začátku semestru bylo avizováno, že na projektu bychom za semestr měli strávit cca 100 hodin, a z tohoto hlediska uspěla většina členů našeho týmu s velkou rezervou. Osobní hodnocení členů týmu Matějů Petr Moje role v týmu byla asi takový normální programátor. Dělal jsem jak implementaci, GUI tak i dokumentaci. Týmu jsem určitě něco přinesl, minimálně ulehčení práce s projektem a možnost rozdělit programování na více částí. Myslím si, že náš tým pracoval výborně, až na odchod jednoho člena z týmu, který o tom nedal nikomu vědět, a další drobná nedorozumění. Mně tým přinesl určitě hodně. Stal jsem se lepším programátorem, seznámil jsem se s novými věcmi a to nejen v oblasti programování. Matúš Jozef Mojí úlohou v Teamu Frontgroup bylo vytvořit databázi a zajistit komunikaci mezi databází a aplikací tak, aby splňovala Protocol. Projektu jsem se snažil věnovat a svoji práci odevzdávat v určeném termínu. V určitém bodě vývoje jsem ale kvůli nedostatku času způsobil problémy a tehdy jsem byl slabým článkem, který team zbrzdil. Svojí úlohu jsem nakonec splnil. Celkově jsem se snažil spolupracovat a komunikovat s teamom. Práci ve skupině hodnotím kladně a to hlavně díky výbornému vedení hlavního vedoucího. Staščák David Moje role v týmu nebyla nikterak významná. Hned v počátku jsem se přiznal k tomu, že v programování příliš silný nejsem a tudíž bylo mým úkolem hlavně starat se o dokumentaci. Tento úkol jsem podle svého názoru zvládnul a vše probíhalo podle plánu. Ke konci jsem byl bohužel proti své vůli donucen vyprodukovat také několik řádek kódu, který by ostatní bezpochyby zvládli napsat za desetinu času a bez chyb, ale nebylo to tak hrozné. Problémy v týmu se objevovaly, ale nebyly dle mého názoru příliš vážné. Myslím si že jsme jako tým pracovali dobře, alespoň ve srovnání s týmem který měl cvičení s námi. Atmosféra v týmu se mi bohužel s přibývajícím množstvím práce líbila méně a méně. Zdá se mi, že někteří lidé náš projekt začali brát příliš vážně. Na druhou stranu jsme ho stihli dokončit a to je podle mě úspěch. Nemůžu ale říci, že jsem s naším programem spokojený. Sice jsme splnili plán a naprogramovali všechny use cases které jsme si zadali, ale stejně náš software není snad ani ve fázi vhodné k alfa testování. Je pravda, že já bych asi neměl být tak kritický, vzhledem k tomu

29 co jsem naprogramoval, ale na začátku semestru jsem si zkrátka představoval, že budeme odevzdávat téměř funkční software. Jako svůj přínos pro tým bych viděl asi to že jsem se snažil udržet tam alespoň trochu odlehčenou atmosféru. Také jsem se v podstatě staral o komunikaci s druhou skupinou ať už ve smyslu ové komunikace, nebo tím že jsem vypracovával a prezentoval oponentury k jejich pracím. Na začátku projektu jsem se také jako všichni podílel na formování základních ideí. Jako přínos celého toho snažení pro mě, vidím hlavně dvě věci. Jednak jsem trochu nakoukl do toho, jak to chodí ve skutečném světě a ve firmách, které se zabývají vývojem aplikací. A taky jsem tím tak nějak dospěl k rozhodnutí, že něčemu takovému se budu snažit v budoucnu vyhnout, protože dělat tu práci takhle mě nijak zvlášť nebaví. Ozkoušel jsem si při tom práci v týmu, což je určitě dobře, jelikož do té doby jsem vždy programoval na vlastní pěst. Problém je v tom, že z hlediska programování jsem v týmu byl spíše přítěž, ještě na to zkrátka nejsem připravený. Jako druhý přínos vidím seznámení se softwarem github. Abych pravdu řekl, tak zatím mám k němu negativní vztah, ale myslím že je velmi užitečný a do budoucna se budu snažit svůj postoj změnit a dost možná ho začnu využívat. Tobolka Radim V našem týmu jsem se ujal role komunikátora, jak to cvičící označil. Já sám jsem svoji úlohu pochopil spíš jako vedoucího skupiny, který iniciuje spolupráci a rozděluje úkoly. Obával jsem se, že pokud bych tak neudělal, tak bychom prvních pár týdnů nedělali nic a tak si zkomplikovali vypracování celého projektu. Velmi jsem proto uvítal hodnocení v rámci týmu pomocí bodů - u nás měly vysloveně motivační úlohu a pomohly nám včas nastartovat. Později jsem inicioval kontrolu kvality výstupních dokumentů v rámci skupiny ještě před konečným odevzdáním. Problém byl v tom, že ne všichni o tuto kontrolu stáli, takže to fungovalo jen částečně. Při programování jsem lehce ztratil dech a přestal stíhat, co se v týmu děje a tak mi uniklo, že se nám zadrhly práce na databázové části aplikace, což nás ve výsledku zdrželo přibližně o týden a zhoršilo to vztahy v týmu. Role vedoucího v školním týmu je vratká. Závisí na tom, nakolik ho ostatní členové respektují a jsou ochotni poslouchat. Vůbec to není jako ve firmě. To mi ale došlo až v průběhu semestru. Přínos projektu (a předmětu) vidím v tom, že jsem se dozvěděl nové věci z oblasti formulování zadání softwarového projektu (kontextový model, model požadavků). Dále pro mě byla přínosná práce v týmu, které jsem se docela dlouho obával, ale nakonec to nebyl takový problém. Příště se nebudu tolik angažovat jako vedoucí, protože to nemá smysl. V školním týmu jsme si všichni rovni a tak se o rozdělení úkolů, odpovědnosti a podobně musí vyjednávat jinak, než ve firmě. Jen zatím nevím přesně jak. Vydržel Lukáš Svoji účast na projektu bych hodnotil jako zásadní, jelikož jsem navrhnul architekturu programu a způsob komunikace klientské a serverové části aplikace. K obou částem jsem přispěl i implementací tříd obstarávající převod objektových dat do komunikačního protokolu a zpět, tříd obstarávající samotnou komunikaci a také návrhem a implementací GUI pro správu skupin uživatelů a dovednostních položek. Většinu svých metod jsem si i otestoval JUnit testem.

30 Přispěl jsem i k formálním záležitostem projektu jako je například rozpočet, příklady užití a nákres návrhu databáze. Celkově můžu říct, že jsem na projektu strávil hodně času.