Analýza Systém Správce Toto je analýza aplikace Systém Správce, která slouží k alokaci zaměstnanců vedených v databázi do týmů. Jedná se o pomůcku projektových manažerů. Rozbor požadavků Funkční požadavky 1. Přístup Uživatel aplikace se může do systému přihlásit pomocí platného uživatelského jména a hesla. Akceptační kritérium: Libovolný registrovaný uživatel se může přihlásit do aplikace. 2. Změna hesla Uživatel si může změnit heslo. Akceptační kritérium: 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 Systém vždy obsahuje správcovský účet "admin". Akceptační kritérium: Do čisté instalace aplikace se dá přihlásit uživatelským jménem "admin" a heslem "admin". 2. Založení uživatelského účtu. Admin může vytvořit nového registrovaného uživatele v některé z rolí zaměstnanec, personalista nebo projektový manažer. Akceptační kritérium: 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 Admin může změnit libovolnému uživateli heslo. Akceptační kritérium: 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 Admin může smazat libovolného uživatele. Akceptační kritérium: 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
Projektový manažer může vytvořit tým a určit jeho jméno a popis. Automaticky se stane jeho vedoucím. Akceptační kritérium: 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 s zakládajícím uživatelem. 2. Editace týmu Projektový manažer může změnit název, popis a vedoucího týmu, který sám vede. Priorita: should have Akceptační kritérium: 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 moct dále upravovat. 3. Smazání týmu Projektový manažer může smazat svůj tým. Priorita: should have Akceptační kritérium: Tým po smazání zmizí z databáze spolu s veškerými asciovanými údaji. 4. Prohledávání databáze profilů Projektový manažer může prohledávat databázi podle všech položek profilu. Akceptační kritérium: Manažer zadá kritéria vyhledávání a zpět dostane seznam vyhovujících profilů. 5. Správa členů týmu 1. Přidání člena Projektový manažer může z výpisu vyhledaných profilů přidat člena do týmu. Akceptační kritérium: U každého profilu ve výsledku vyhledávání je zobrazeno tlačíko "přidat." Po jeho stisknutí se vybraný profil přidá do týmu jako člen. 1. Odebrání člena Manažer může odebrat člena z týmu. 6. Pozvánka Projektový manažer může rozeslat pozvánku všem členům týmu. Priorita: should have Akceptační kritérium: Po sestavení týmu může projektový manažer zaslat všem nepotvrzeným členům týmu pozvánku na emailovou adresu uvedenou v profilu. Zaměstnanec 1. Správa profilu Zaměstnanec může upravovat informace ve svém profilu. Akceptační kritérium: 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 Zaměstnanec může potvrdit nebo zamítnout pozvánku do týmu. Priorita: should have Akceptační kritérium: 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 Personalista může schválit jednotlivé položky profilu.
Priorita: nice to have Akceptační kritérium: 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 500-1000 uživatelů. 5. Bezpečnost dat Informace vedné v aplikaci jsou dostupné jen po přihlášení. Příklady užití
Analytický model tříd Popis tříd KLIENTSKÁ APLIKACE EmployeeFrame Prostá třída sloužící k vykreslení jedné ze základních obrazovek našeho systému - okno s osobními údaji 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.
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í. ServerConnection Třída fungující jako singleton sloužící ke komunikaci se serverovou aplikací. Item Třída přestavující dovednostní položku zaměstnance. FrameGroups Implementace GUI pro správu skupin uživatelů. FrameItems Implementace GUI pro správu globálních dovednostních položek. FrameEditGroup Implementace GUI pro editaci a přiřazování dovednostních položek skupiny. Source Třída, která si nechá poslat veškeré informace o uživateli ze serverové aplikace a umožňující s těmito informaci dále pracovat jiným třídám. User 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ů. SERVEROVÁ APLIKACE ClientConnection
Třída spouštějící se jako samotné vlákno, přes kterou se komunikuje s jednotlivýmu 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, která dekóduje a zpracovává příchozí zprávy od klientů. DBConnection Třída komunikující s databází. **// ktora obsahuje metody vracajici Stringi ktore su posielane klientovi Popis protokolu Návrh textového protokolu mezi klientem a serverem. Další sekvence budou přibývat s postupem implementace. Symbol "větší než" značí komunikaci od klienta k serveru. Symbol "menší než" představuje odpověď server. Server na požadavek zpravidla odpoví zprávou OK, pokud požadavek vyřídil vpořá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 je role uživatele a nebo KO, pokud došlo k chybě přihlášení. role: Přihlášený uživatel > CHANGE_PASS old_pass new_pass < OK KO důvod role: admin přídání uživatele: > ADD role user pass [group] < OK KO důvod smazání uživatele: > DEL user_id < OK KO důvod
změna hesla uživatele: > CHANGE_PASS user_id pass < OK KO důvod žádost o přijetí informací uživatele: > INFO user_id < KLIC HODNOTA;KLIC HODNOTA;... odhlášení ze systému: > LOGOUT < OK KO důvod Architektura Klientska aplikacia pomocou grafickeho rozhrania posiela poziadavky serverovej apliacii, poziadavky su vo forme textu v tvare urcenom v protokole. Serverova aplikacia pomocou protokolu rozpozna poziadavku a reaguje pripojenim k databaze kde sa provede pozadovany dotaz. Nasledne je klietska aplikacia informovana o pripadnom uspechu. V pripade neuspechu je konkretizovany dovod. Vysledok je zobrazeny v grafickom prostredi Návrh databáze
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.
Správa uživatelů dostupná v roli admin.
Návrh pro správu skupin zaměstnanců a jejich dovednodností
Správa týmů a přidání týmu v roli projektového manažera