USI - 102 - Projekt klíčenka"
! ! ! ! ! ! ! ! ! ! ! ! ! ! !
! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! !
Předmět A7B36USI paralelka 102 – Pondělí 14:30 cvičící Martin Komárek ČVUT FEL Tomáš Záruba, Gulnara Abilova, Martin Karban, Levan Bachukuri Termín odevzdání: 6.října 2013
!
!
Link na projekt: https://www.assembla.com/spaces/usi-klicenka
!
Výstup zkontroloval: Tomáš Záruba, Verze 1.17#
! 1 z 10
Obsah" !
USI - 102 - Projekt klíčenka 1 1.0 Stručný popis: !............................................................................................3! 2.0 Zainteresované osoby: !...............................................................................3! 3.0 Aktuální stav!................................................................................................3! 4.0 Vize projektu pro objednavatele: (Z jeho pohledu)!......................................4! 5.0 Vize projektu pro dodavatele: (Z našeho pohledu) !.....................................4! 6.0 Klíčové vlastnosti řešení: !............................................................................5! 7.0 Implementace!..............................................................................................5! 7.1 Centrální aplikace (Server) !.............................................................5! 7.2 Terminál desktop !.............................................................................5! 7.3 Terminál v prohlížeči !.......................................................................5! 8.0 Požadavky pro funkční nasazení!.................................................................6! 8.1 Omezení požadavků!.........................................................................6! 9.0 Klíčové vlastnosti!.........................................................................................7! 9.1 Základní funkční požadavky!............................................................7! 9.2 Role v systému !................................................................................7! 10.0 Finanční ohodnocení projektu!...................................................................8! 10.1 Rozdělení případných zisků!...........................................................8! 12.0 Termíny!......................................................................................................9!
! ! ! ! ! !
13.0 Závěr !.......................................................................................................10
2 z 10
1.0 Stručný popis: " Společnost EYELEVEL je globální leader v budování interiérů obchodů. Ve správě má přes 140 značek a po světě pobočky od NewYorku, Prahu po Moskvu. Jedná se o společnost, jež má kapitálový základ InnerWorkings, Inc. a je v Fortune 500. Společnost očekává masivní růst díky finanční intervenci a Tomáš Záruba (projektový manažer za ČVUT) spolupracuje v úvodní studii proveditelnosti při nasazení BPM.!
!
Díky velikosti firmy vznikají problémy s licencemi a společnost přichází o veliké peníze. Dle konzultace s Ing. Františkem Lukešem až o 1 600 000 USD ročně. !
! ! 2.0 Zainteresované osoby: " ! ! !
Objednavatel EYELEVEL " Dodavatel ČVUT"
Dodavatel: " Project manager and programer: ! Database programer: ! ! UI programer:!! ! ! Proces manager:! ! !
!
! ! ! !
Tomáš Záruba
Martin Karban
Levan Buchukuri! Gulnara Abilova!
Odběratel: " EYELEVEL - Ing. František Lukeš (konzultant a hodnotitel) !
!
Supervize: ! Ing. Martin Komárek (
[email protected])!
! !
!
3.0 Aktuální stav" Odběratel má velké množství zaměstnanců v officu. (Více než 150 a je tu potenciál růstu až 400) Od vývojářů, architektů, designérů, obchodníků atd… Pro podporu podnikání je využíváno více než 200 různých programů v různých verzích (CS3, CS4, CS5) a často se stává že firma vlastní určitou licenci, ale koupí další, protože se někde ztratí povědomí, že se již koupila a někdo ji nevyužívá. Je nutné tento problém vyřešit a nejvhodnější variantou se jeví tvorba informačního systému, který kvůli ochraně (nelze teď smluvně se studenty uzavřít) nebude navázán pomocí interface na databázi společnosti ale vytvoří se duplicitní stromová hierarchie do které bude moci administrátor zasahovat. Ideální by bylo pokud by byl program součástí vnitropodnikového řešení BPM a procesního portálu, který jeden ze členů ve společnosti implementuje, ale není dobré načasování, nejsou připravené aplety, výstupy ze systému atd. !
! ! ! ! ! ! !
3 z 10
! 4.0 Vize projektu pro objednavatele: (Z jeho pohledu)" Naše firma má cloudový program, který spravuje licence (v podobách stringu, rar… atd) a různé instalační klíče nebo předplacené přístupy k různým informacím. Tyto data jsou spárovaná s konkrétním uživatelem, který k nim má přístup. Program má stromovou hierarchii uživatelů a v případě že šéf vyhodí zaměstnance, systém sám uvolní konkrétní licence a klíče pro nové uživatele. Tvorba uživatele je jednoduchá, buď je tvoří uživatel sám směrem dolů. Nebo správce programu ve struktuře kdekoliv. Pro uživatele lze ze seznamu licencí firmy vybrat uvolněné, nebo požádat o přikoupení nových. Možné je i licence odebírat a přidávat za chodu. V případě plnění termínů se vytvoří malé workflow o žádosti klíčů, potvrzení oprávnosti koupě, přeposlání administrátorovy, přiřazení klíčů atd. Kolektivní licence mohou být sdíleny v rámci skupiny
! ! !
5.0 Vize projektu pro dodavatele: (Z našeho pohledu) " Program bude plně optimalizován a vytvořen po konzultacích s objednavatelem, vytvořena dokumentace pro zaměstnance aby měli jednodušší seznámení se s programem. Program bude implementován v úzké součinnosti s objednavatelem. Hlavním cílem je prezentovat tým takovým způsobem, že EYELEVEL bude chtít navázat komerční spolupráci, protože potřeb na řešení je více. Především pak získat důvěru a navázat program pomocí interface s ERP a MRP popřípadě v procesním portálu, který je ve výstavbě.
4 z 10
6.0 Klíčové vlastnosti řešení: " - Šetří náklady, které jsou vynakládány na zbytečné nákupy na programy, které nejsou vytěžovány protože se neví že jsou k dispozici. !
- Dokáže dát zpětnou vazbu, kolik je licencí určitých programů a dát tak informace o nákladnosti rozšiřování některých pozic (popřípadě celých týmů) !
- Umožní v reálném čase uživatelům uvolňovat nebo sdílet licence napříč firmou jedná se především o licence poskytující konzultantské informace, které jsou předpláceny a mají časovou trvanlivost. (Předplacený vývěsník aktualizací zákonů atd.) !
! ! 7.0 Implementace" !
Centrální aplikace bude psána v programovacím jazyce Java a poběží na serveru, vytřeného z NAS. Nároky na výpočetní výkon či odezvu jsou minimální. Potencionálním řešením je cloudové sdílení kdy server bude uložen na hostiDeskopovoungu. Přes protokol TCP bude komunikovat s desktopovou aplikací. Vize počítá s řešením v prohlížeči - ale kvůli bezpečnostnímu omezení a dalším vlivům je tato varianta v tuto chvíli nejistá. Je nutná konzultace týmu se supervizí ze strany EYELEVEL a jejich IT týmu, který bude vytvářet konzultační suport pro systém klíčenka.
!
! !
7.1 Centrální aplikace (Server) " Program bude přistupovat k databázi, kde budou zaznamenány veškeré informace o ! uživatelích, klíčích, práv, de bude probíhat řízení elektronického workflow. ! Aplikace musí poskytovat všechny služby, jak pro správce systému (viz. kapitola Klíčové ! vlastnosti), tak i pro běžné uživatele systému.!
! !
7.2 Terminál desktop " Terminál bude sloužit pouze pro zaměstnance objednavatele. Zde se zaměstnanec přihlásí pod svůj uživatelský účet, který v počátku dopředu vytvoříme podle vyexportované databáze, kterou nám zašle HR manažer. Každému uživateli se přidělí heslo a přístupové jméno a v emailu bude vyrozuměn jak se přihlásit atd. spolu s dokumentací “How to use”. !
!
V systému jsou role s různými právy a úkoly. (Nákupčí, Admin, Vedoucí) Jde o duplicitu s BPM, ale díky uzavřenému systému řešení nešlo zvolit jinak. Role jsou popsány v kapitole Role uživatelů systému."
! !
7.3 Terminál v prohlížeči " Jde o schodné řešení jako u desktop terminálu, ale veškeré dění programu bude v prohlížeči. Podobně jako office a office 365 online.
! ! ! ! ! ! ! ! !
!
5 z 10
! 8.0 Požadavky pro funkční nasazení" Hlavní aplikace bude realizována v prostředí Java s pomocí GUI apletů. Pro analýzu a návrh bude použit nástroj Enterprise Architect. Z databázových systémů využijeme bezplatného řešení SQL.!
!
8.1 Omezení požadavků"
!
Vzhledem k velice obtížnému prosazení programovacího jazyka PHP se zvolil pro realizaci ! jazyk Java.!
6 z 10
9.0 Klíčové vlastnosti"
!
9.1 Základní funkční požadavky" • • • • • • • • • •
• •
! ! !
Registrace nového uživatele jiným uživatelem s přednastavitelnými právy! Přiřazení role respektive práv! Zadávání nových licencí! Evidování a změna parametrů u licencí, klíčů a přístupových dat, správa jejich časového kontextu! Změna vlastnictví licence (odebrání, přidání)! Podání žádosti o přidělení volné licence ze seznamu! Příjem žádosti o přidělení licence a její vyhodnocení Vedoucím (Souhasím/ Nesoulasím)! Příjem žádosti o přidělení licence Administrátorem a její zpracování! Vzdání se licence, když jí uživatel již nepotřebuje v reálném čase ! Žádost (elektronické workflow) o novou licenci - schválení vedoucím, přesun informace k nákupčímu. (Doprovodné informace jsou generovány a zasílány do emailu) ! V případí vyhození zaměstnance vedoucím se uvolní všechny jeho licence! Vyhledávání v seznamu licencí (jejich počet atd.) pomocí evidenčního seznamu, který je uměle dopředu navržen. !
9.2 Role v systému "
!
! !
•
Na straně uživatele systému (uživ. role: Uživatel ) ! • Jedná se o uživatele systému, který se přihlásí vidí svoje údaje, jaké vlastní licence. Může požádat o nové pokud je k práci potřebuje nebo se vzdát licencí které již nepotřebuje.
•
Na straně uživatele s vyšším oprávněním (uživ. role: Administrátor) ! • Jedná se dohled nad chodem aplikace. Jeho funkce jsou v kládání nových programů (licencí), obnova hesla užvatelům, tvorba nových uživatelů a přiřazování je do stromové struktůry, nastavování hlavních práv (vedoucí nákupčí, admin) !
•
Na straně uživatele s vyšším oprávněním (uživ. role: Vedoucí) ! • Jako uživatel, ale má možnost uživatelům pod sebou a sobě přidělovat licence a popřípadně jim určit zda se jendá taktéž o vedoucí. Uživatele může tvořit a ti se mu zařzují do stromové struktury. Schvaluje žádosti o nové licence. A má možnost podívat se jaké všechny licence jsou k dispozici a v jakém počtu. !
•
Na straně uživatele s vyšším oprávněním (uživ. role: Nákupčí) ! • Jedná se o uživatele, který dostává navíc schválené žádosti o nákup nového programu. Po nakoupení program zaeviduje a tato informace se zašle administrátorovi, který jí může infromačně doplnit, zařadit do databáze a přidělit uživatelovi, který vznesl žádost.!
!
Role jsou určovány parametrem, tedy se jen k jednotlivým uživatelům přidělí jaké mají práva (možnosti). !
7 z 10
10.0 Finanční ohodnocení projektu" Projekt není vyvíjen komerčně, ale je nutné definovat co se bude s programem dít po ukončení předmětu USI. Nikdo z členů si nenárokuje žádné finanční ohodnocení. V případě další spolupráce, například implementace do systému BPM se nasazení ! bude řídit podle bodu licenční ujednání a bodu a návrhu rozdělení případných zisků. !
!
10.1 Rozdělení případných zisků"
! ! !
Software a licence je nabízena zdarma v rámci praxe. V případě finančního ohodnocení se zisk rozpočítá poměrově k počtu odpracovaných hodin jednotlivce s poukazem na náročnost vykonaných úkonů. Poslední slovo má projektový manažer.!
11.0 Licenční ujednání" Tým počítá s reálným nasazením a vzdává se ve prospěch společnosti EYELEVEL veškerých práv. Společnost EYELEVEL nemá možnost kód předávat třetím stranám. !
!
Případné manipulace se zdrojovým kódem musí být odsouhlasený podpisem celého! vývojového týmu bez výjimky a zdrojový kód předložen k nahlédnutí. ! Pokud se provozovatel EYELEVEL rozhodne využít tento software, má plné ! právo na využívání programu v plném rozsahu. Není dovolena žádná manipulace se ! zdrojovým kódem ani poskytnutí žádné části programu třetí straně. Vývojový tým si však vyhrazuje právo na správu softwaru a případnou obci nástavby softwaru a dohodnuté ceny 300kč/h hrubé mzdy programovacího času. !
! ! ! !
8 z 10
12.0 Termíny" Termíny odevzdání jednotlivých částí projektu se řídí organizací semestru předmětu ! A7B36USI.!
1. Iterace 3. týden semestru – Vize projektu • Vize
!
2. Iterace 5. týden semestru – Prvotní analýza • Vize upravená • Business Analýza • Katalog funkčních a obecných požadavků • Model případů užití
!
3. Iterace 6. týden semestru – Detailní analýza • Vize upravená (Podle funkčních požadavků z druhé iterace) • Business proces management - (návrh řešení) • Katalog funkčních a obecných požadavků • Model případů užití • Analytický doménový model
! !
7. týden semestru – Controling postupu - konzultace
! !
9. týden semestru – Controling postupu - konzultace
4. Iterace 8. týden semestru – Model architektury • Implementační dokumentace - možnosti a návaznost na problémy s nejasnostmi z Vize • Model architektury • Model komunikace - sekvenční diagramy • Model nasazení
5. Iterace 12. týden semestru - Programování podle dokumentace • Vytvoření kompletní dokumentace • Zpráva o implementaci • Zpráva o testování • Zpráva o spokojenosti řešení při testingu s uživateli
! 6. Iterace 13. týden semestru – Odevzdání hotového projektu ! ! X iterace: - 10. týden dalšího semestru - navázání na BPM
! ! !
9 z 10
13.0 Závěr "
!
Úvodní dokument shrnul základní problémy objednavatele a jako řešením se jeví tvorba nového IS přímo na míru. Nový systém má obsáhnout malé portfolio procesů (elektronické workflow), které potencionálně firma konsoliduje a integruje pod jednu platformu v novém BPM. Cílem je šetření nákladů, optimalizace a efektivnost. Studie se nezabývala zabývala časovým rozložením tak, aby využila období s nejnižším obratem objednavatele a nevyvářela rizika spojená se špatným načasováním. Nezdar programu není finančním rizikem. Od systému se očekává maximální zefektivnění a šetření nákladů na správu klíčů a licencí a poskytnout HR managementu a dalším nástroje, které jim umožní jednodušeji a lépe řídit firmu při návrzích na růst oddělení, při kalkulaci nákladů na vznik pozic atd. ) IS klíčenka má vyřešit základní problémy, jež objednavatele trápí, a dát mu do ruky nový nástroj, jež mu pomůže šetřit náklady. Systém byl navrhnut v případě cloudového řešení jako rezistentní vůči operačním systémům a tedy lze šetřit na nákladech spojených s IT. Hlavním problémem je, že každý zaměstnanec má svůj Macbook jako přenosný PC a odborní zaměstnanci k tomu mají výkoné desktop PC s Linuxem a Windows v mnoha verzích.
!
Věříme, že kvalita odvedené práce a tohoto dokumentu jsou začátkem dlouhodobé spolupráce mezi ČVUT a EYELEVEL.
!
Podepsán vedoucí týmu, business analytik a šéf-programátor
! ! ! ! ! ! !
10 z 10
!
