MASARYKOVA UNIVERZITA FAKULTA INFORMATIKY
Projektový portál s využitím MS SharePoint dle metodiky PRINCE2
DIPLOMOVÁ PRÁCE Ing. Petr Špaček
Brno, 2014
Prohlášení Prohlašuji, že tato diplomová práce je mým původním autorským dílem, které jsem vypracoval samostatně. Všechny zdroje, prameny a literaturu, které jsem při vypracování používal nebo z nich čerpal, v práci řádně cituji s uvedením úplného odkazu na příslušný zdroj.
Poděkování Děkuji panu Mgr. Emilovi Vařekovi, MBA řediteli firmy Icontio za podporu a poskytnutí potřebných zdrojů. Dále bych chtěl poděkovat své rodině za podporu a trpělivost. Děkuji také paní Ing. RNDr. Barboře Bühnové, Ph.D. za vedení této práce.
Shrnutí Diplomová práce pojednává o problematice projektového řízení. Zaměřuje se na projektovou metodiku PRINCE2. V práci jsou popsány existující nástroje, které slouží pro řízení projektů. Práce analyzuje, navrhuje a následně realizuje informační systém pro podporu projektového řízení podle metodiky PRINCE2 pomocí technologie Microsoft SharePoint, která je v práci popsána z funkčního i vývojářského pohledu.
Klíčová slova Projektové řízení, metodiky projektového řízení, PRINCE2, IPMA, PMI, Microsoft SharePoint
Obsah 1
Úvod .................................................................................................................................... 7 1.1 Cíle práce ..................................................................................................................... 7 1.2 Struktura práce ............................................................................................................. 8
2
Projektové řízení ................................................................................................................. 9 2.1 Terminologie ................................................................................................................ 9 2.1.1 Projekt, program, portfolio ................................................................................... 9 2.1.2 Šest parametrů, které je potřeba řídit .................................................................. 10 2.2 Metodiky projektového řízení .................................................................................... 10 2.2.1 IPMA, ICB ......................................................................................................... 10 2.2.2 PMI, PMBoK ...................................................................................................... 11 2.2.3 OGC, PRINCE2 ................................................................................................. 11 2.2.4 Řízení vývoje ...................................................................................................... 11 2.2.5 Plánování projektu .............................................................................................. 11 2.3 Existující řešení.......................................................................................................... 11 2.3.1 Atlassian, JIRA ................................................................................................... 12 2.3.2 Icontio, PMPortal ............................................................................................... 12 2.3.3 Oracle, Primavera ............................................................................................... 13 2.3.4 Ostatní společnosti a produkty ........................................................................... 13 2.3.5 Řízení svépomocí ............................................................................................... 13 2.3.6 Srovnání .............................................................................................................. 14
3
PRINCE2........................................................................................................................... 16 3.1 Struktura PRINCE2 ................................................................................................... 16 3.1.1 Úrovně řízení ...................................................................................................... 18 3.2 Principy ...................................................................................................................... 18 3.3 Témata ....................................................................................................................... 19 3.4 Procesy ....................................................................................................................... 20 3.4.1 Zahájení projektu ................................................................................................ 22 3.4.2 Směřování projektu ............................................................................................ 22 3.4.3 Nastavení projektu .............................................................................................. 23 3.4.4 Kontrola etapy .................................................................................................... 24 3.4.5 Řízení dodávky produktu ................................................................................... 24 3.4.6 Řízení přechodu mezi etapami ........................................................................... 25 3.4.7 Ukončení projektu .............................................................................................. 25 3.5 Zjednodušený popis PRINCE2 projektu a jeho etap ................................................. 26
4
Microsoft SharePoint ........................................................................................................ 28 4.1 SharePoint 2013 ......................................................................................................... 29 4.2 SharePoint Online ...................................................................................................... 29 4.3 Struktura..................................................................................................................... 30 4.4 Oprávnění ................................................................................................................... 33 4.5 Způsoby úpravy a vývoje ........................................................................................... 35 5
4.5.1 Nastavování ........................................................................................................ 36 4.5.2 Programování ..................................................................................................... 37 4.6 PowerShell ................................................................................................................. 37 5
Analýza systému ............................................................................................................... 39 5.1 Specifikace požadavků .............................................................................................. 39 5.1.1 Funkční požadavky z pohledu PRINCE2 ........................................................... 39 5.1.2 Funkční požadavky z pohledu portálu ................................................................ 40 5.1.3 Nefunkční požadavky ......................................................................................... 40 5.1.4 Diagram případů použití ..................................................................................... 40
6
Návrh systému ................................................................................................................... 42 6.1 Konceptuální diagram ................................................................................................ 42 6.2 Návrh architektury portálu pro SharePoint ................................................................ 43 6.3 Objektová vrstva ........................................................................................................ 44 6.4 Proces PRINCE2 ........................................................................................................ 45
7
Realizace systému ............................................................................................................. 47 7.1 Microsoft SharePoint 2013 ........................................................................................ 47 7.1.1 Způsob vývoje .................................................................................................... 47 7.1.2 Datová vrstva ...................................................................................................... 48 7.1.3 Aplikační vrstva .................................................................................................. 48 7.1.4 Prezentační vrstva ............................................................................................... 49 7.1.5 Oprávnění ........................................................................................................... 50 7.2 Konfigurace a nasazení .............................................................................................. 52
8
Závěr ................................................................................................................................. 53 8.1 Možnosti dalšího vývoje ............................................................................................ 53 8.2 Přínos a poznatky ....................................................................................................... 54
Literatura .................................................................................................................................. 55 Seznam použitých zkratek ........................................................................................................ 57 Seznam příloh ........................................................................................................................... 58
6
1
Úvod
Již od počátku rozvoje lidské inteligence bylo zapotřebí, k jejímu úspěšnému fungování, řízení a plánování budoucích kroků. Na počátku spíše vládl neřízený chaos, následovalo přirozené užití „selského rozumu“, poté si lidé psali poznámky na papír, které později detailně propracovali do komplexních plánů, které byly podkladem pro řízení. Stejné principy jsou využívány i v dnešní době ve firemních prostředích, ve kterých se chceme vyhnout nepřehledné a nekontrolované změti čísel, dokumentů a projektů. Proto je zapotřebí organizaci projektů nastavit určitý rámec a pravidla. Detailní řízení vyžaduje odborníka a existuje celá řada systémů pro jeho podporu. Některé z nich jsou zmíněny v kapitole 2.3 Existující řešení. Vedle výše uvedených přístupů k řízení může existovat i další pohled, který se nesnaží pouze o detailní řízení jednotlivých projektů, a který nenechává rozhodování pouze na zdravém úsudku jednotlivců. Jde o systém, který nabízí pohled na veškeré firemní projekty s určitou abstrakcí. Systém, ve kterém může firma spravovat své portfolio, a kde může mít na jednom místě a v přehledné struktuře přehled o financích a jejich čerpání. Zároveň poskytuje dostatečně detailní pohled na konkrétní projekt tak, aby bylo možné úspěšně rozvrhnout jeho termíny, rizika či zdroje. Nedílnou součástí takového systému je i místo, kde se přehledným způsobem uchovávají důležité dokumenty, ke kterým mají přístup kompetentní uživatelé. Nástupem informačních technologií, počítačů a internetu se naskytla celá řada možností, jak se k plánování, řízení či správě informací a dokumentů postavit. Důležitou skutečností pro to, aby řízení nevypadalo chaoticky neřízeně, je se v těchto možnostech vyznat, správně je využít a vhodně zkombinovat. Aby byl takový systém pro uživatele co nejpohodlnější a přitom co nejužitečnější, je potřeba pravidla navrhnout tak, aby každý uživatel v jakékoliv roli byl schopen tento systém používat, aby byl při práci veden a přitom nemusel být certifikovaným odborníkem, a aby bylo jasné, co od sebe systém i uživatel navzájem požadují. Zároveň není nutné vymýšlet nová pravidla a raději nabídnout osvědčené postupy z praxe, které nabízí různé standardy projektového řízení. Tím se systém odliší od již existujících nástrojů, které zpravidla nabízejí spíše strukturu pro evidenci projektových údajů s více, či méně pokročilou funkcionalitou, ale co už nenabízí, jsou ucelené projektové postupy, které směřují projekty k jejich zdárnému ukončení.
1.1
Cíle práce
Cílem této práce je vytvoření právě takového systému, který poskytne jednoduchou kostru, šablonu a srozumitelný postup, jak k problematice řízení firmy přistupovat. Systém má řešit problematiku správy firemního portfolia, přehled projektů, jejich řízení a jejich plánování a v neposlední řadě má plnit funkci místa, kde se budou koncentrovat dokumenty z celé firmy. Systém se nezaměřuje pouze na detail jednoho projektu či programu, ale snaží se zachytit celé firemní portfolio. Také má poskytovat reporty nad projekty. Přehledným způsobem poskytne správu projektu a umožní jednoduché plánování. U jednotlivých projektů umožní určovat členy týmu, zadávat rizika, milníky, úkoly a změnová řízení. Systém má podporovat schvalování nad některými důležitými entitami, mezi které mohou patřit členové projektového týmu, dokumenty či změnová řízení. 7
Jednou z nejdůležitějších součástí a výhod navrhovaného systému je práce s dokumenty. Ty musí být vhodně organizovány a musí být dohledatelné. Jelikož se často bude jednat o citlivá data, je třeba zajistit oprávnění podle rolí jednotlivých zaměstnanců. Aby byl systém používaný, je třeba ho přizpůsobit pro každou roli, která jej bude využívat. Zároveň je potřeba klást důraz na co největší přínos pro každou z nich. Vedení firmy využije přehledné reporty, ve kterých na první pohled uvidí stav projektů. Projektový manažer dostane nástroj, přes který může aplikovat projektové řízení. Všichni zaměstnanci pak ocení pořádek v dokumentech a agendu na jednom místě. Administrátor firmy, či IT oddělení využijí možnosti platformy Microsoft SharePoint, která umožňuje řadu pokročilých funkcionalit, jako je zálohování, audit, správa oprávnění, logování chyb a jiné. Navrhované řešení je postaveno na technologii Microsoft SharePoint ve verzi 2013. Tato technologie je vybrána z důvodu, že již v základu podporuje řadu funkcí, které by bylo velmi obtížné implementovat. Výsledný produkt bude tedy nástavbou nad touto technologií a bude nad ní vytvářet strukturu projektového portálu s řadou přidaných hodnot. Blíže je tato technologie popsána v kapitole 4. Pro samotnou realizaci je částečně využit projektový portál firmy Icontio s názvem PMPortal. Projektový portál je navržen a implementován pro podporu projektové metodiky PRINCE2 tak, aby aktérům projektového řízení ulehčil práci a pomohl jim aplikovat metodiku PRINCE2 v praxi.
1.2
Struktura práce
Následující druhá kapitola se zabývá teorií projektového řízení. Stručně popisuje existující metodiky ICB (IPMA Competence Baseline) od asociace IPMA (International Project Management Association), PMBoK (Project Management Body of Knowledge) od institutu PMI (Project Management Institute) a PRINCE2 (Projects In Controlled Environments 2nd Version) od OGC (Office of Government Commerce). PRINCE2 je detailněji popsán v kapitole třetí. Dále jsou zde popsány existující produkty dostupné na trhu. Třetí kapitola detailněji popisuje projektovou metodiku PRINCE2. Zabývá se jejími principy, tématy a procesy. Kapitola slouží jako teoretický základ pro analýzu a návrh vznikajícího systému. Čtvrtá kapitola pojednává o technologii Microsoft SharePoint. Jsou zde zběžně porovnány její jednotlivé verze, je zde popsána struktura systému a komponenty, které jej tvoří a způsoby, kterými je možné SharePoint přizpůsobit. Následující pátá kapitola je věnována analýze systému, ve které jsou specifikovány funkční i nefunkční požadavky. Ty jsou zde zobrazeny v diagramu případu užití. Šestá kapitola se zabývá návrhem portálu, který vychází z teoretických poznatků o metodice PRINCE2, platformy Microsoft SharePoint a z analýzy požadavků. V sedmé kapitole je popsána realizační fáze, kde se čtenář dozví o využitých technologiích, způsobu vývoje a o problémech, které v průběhu realizace bylo potřeba řešit. V poslední kapitole jsou zhodnoceny dosažené výsledky, možnosti využití a náměty, kterými by se portál mohl dále vyvíjet. Je zde diskutován přínos a poznatky, kterých jsem díky této práci nabyl.
8
2
Projektové řízení
Tato kapitola seznamuje s teorií projektového řízení. Definuje běžně používané základní pojmy a popisuje metodiky zabývající se touto problematikou. Nakonec porovnává existující systémy pro podporu projektového řízení v organizacích.
2.1
Terminologie
Podle PRINCE2 je projektové řízení: „plánování, delegování, monitorování a kontrola všech aspektů projektu, a motivací angažovaných osob k dosažení cílů projektu v rámci očekávaných výkonnostních parametrů, kterými jsou čas, náklady, kvalita, rozsah, přínos a rizika.“ [1 str. 4]
Obrázek 2-1: Projektové řízení podle PRINCE2. [1 str. 5] Projektové řízení podle PMBOK (Project Management Body of Knowladge): „Je aplikace znalostí, schopností, nástrojů a technik na aktivity projektu, za účelem splnění projektových požadavků.“ [2 str. 8] Projektové řízení je využíváno pro zvýšení efektivity projektu v organizacích a jiných institucích. Jedná se o způsob, kterým je efektivněji dosahováno cílů projektu. Projektové řízení je využíváno, pokud chceme minimalizovat neúspěch projektu a maximalizovat jeho přínos. Projektové řízení přináší zpravidla doporučené postupy, které vzešly z praxe, a ze kterých vznikly ucelené metodiky, které slouží pro úspěšné vedení projektu od jeho začátku až po jeho konec.
2.1.1
Projekt, program, portfolio
Metodika PRINCE2 definuje tyto pojmy následovně: „Projekt je dočasná organizace, která je vytvořena za účelem poskytování jednoho nebo více produktů na základě dohodnutého obchodního případu.“ [1 str. 3] „Program je dočasná flexibilní organizační struktura vytvořená pro koordinaci, řízení a kontrolu implementace souboru souvisejících projektů a opatření, s cílem dodat výstupy a přínosy, které se vztahují ke strategickým cílům organizace. Životní cyklus programu trvá obvykle několik let.“ [1 str. 309] „Portfoliem jsou všechny programy a samostatné projekty vedené organizací, skupinou organizací nebo organizační jednotkou.“ [1 str. 308]
9
Port folio
Prog ra m
*
Port folio A
Prog ra m A.x
* *
Projekt
Projekt A.x.1
Projekt A.x.2
Projekt A.1
Obrázek 2-2: Závislost PPP (Projekt, Program, Portfolio).
2.1.2
Šest parametrů, které je potřeba řídit
Kromě standardního trojimperativu (čas, náklady, kvalita) je v rámci projektového řízení potřeba řídit i další tři parametry: riziko, rozsah a přínos. Čas, který je vymezen pro realizaci projektu od jeho zahájení po ukončení. Náklady, které určují, jaký má projekt rozpočet. Kvalita stanovující požadovaný výstup projektu s ohledem na míru jakosti. Rozsah definuje, co se má v rámci projektu udělat, co má a nemá být zahrnuto ve výsledném produktu. Rizika vnáší do projektu míru nejistoty. Tuto nejistotu se snažíme minimalizovat a připravit se na ni pomocí řízení. V případě pozitivního rizika se míru snažíme maximalizovat. Přínos je parametrem, který nám říká, proč projekt děláme, jaký z něj máme profit. Je důležité mít jasnou představu o smyslu projektu.
2.2
Metodiky projektového řízení
Řízením projektů se zabývají různé světové organizace, které pro projektové řízení vydávají své standardy. Mezi ty nejznámější a nejvýznamnější organizace patří IPMA (International Project Management Association), PMI (Project Management Institute) a OGC (Office of Government Commerce).
2.2.1
IPMA, ICB
ICB (IPMA Competence Baseline) je standardem, který se zaměřuje na schopnosti a dovednosti (kompetence) manažerů a členů jejich týmu. ICB představuje soubor znalostí, které by měl projektový manažer znát. Standard není zaměřen na přesnou podobu procesů a jejich užití, ale spíše doporučuje určité procesní kroky, které je potřeba vhodně aplikovat na konkrétní situace. Vhodnost aplikace procesů závisí na schopnosti jednotlivých manažerů. 10
IPMA je mezinárodní organizace, která má za cíl šířit projektové řízení zejména v Evropě, Africe a Asii. Standard vznikl v šedesátých letech dvacátého století na základě norem evropských států. [3 str. 22-26]
2.2.2
PMI, PMBoK
PMBoK (Project Management Body of Knowledge) je procesní metodikou, ve které je definováno pět hlavních rodin procesů, devět oblastí znalostí a dílčí procesy se vzájemnými vazbami. Procesy mají definované vstupy, výstupy a techniky pro jejich transformaci. Jedná se o standard, který je spravován sdružením firem a individuálních projektový manažerů PMI. PMBoK vznikl na základě amerických vládních standardů a je využíván zejména v amerických společnostech. Aktuálně je standard ve verzi 3 a stále se aktualizuje a zlepšuje. [3 str. 25]
2.2.3
OGC, PRINCE2
PRINCE2 (Project IN Controlled Environment) je procesní metodikou, která přináší osvědčené postupy z praxe. Metodika vznikla na zadání britského ministerstva průmyslu a obchodu. To si pro řízení projektů státních zakázek vymínilo použití vyvinuté metodiky od OGC. OGC přináší celou řadu dalších rozšiřujících i doplňujících standardů. [3 str. 25] O metodice PRINCE2 pojednává celá kapitola 2.3.6.
2.2.4
Řízení vývoje
Existují i další specializované metodiky, zejména specializované na vývoj softwaru. Jako příklady lze zmínit: vodopádový, prototypový, iterativní inkrementální, spirálový přístup, UP (Unified Proces), RUP (Rational Unified Process) nebo také moderní agilní přístupy: Scrum, extrémní programování, vývoj řízený testy. Více informací o řízení vývoje softwarových projektů lze nalézt na portálu Objektová analýza, návrh a programování. [4]
2.2.5
Plánování projektu
Součástí řízení projektů jsou i detailní techniky plánování postupu práce. Tyto techniky nabízí spíše způsob, jak plánovat, než způsob jak projekt řídit. K modelování závislostí, délky trvání, nebo struktury projektu jsou využívány diagramy, které rozdělujeme na síťové nebo sloupové. Nejznámějšími představiteli je Ganttův diagram a síťový diagram. Metodika PRINCE2 přímo nespecifikuje techniku, jakou by se měl projekt detailněji plánovat. Navrhuje však postup, jak k plánu dospět. Využívá postupného stromového rozpadu (WBS, Work brakedown structure) produktu na pod-produkty. Listy jsou pak na nejnižší úrovni tvořeny jednotlivými aktivitami, které mají za cíl vytvořit požadovaný produkt.
2.3
Existující řešení
Na projektové řízení lze využít řadu systémů a produktů. Systémem může být myšleno i sdílené dokumentové uložiště, přes které si projektové týmy vyměňují informace či komunikační nástroj, přes který je tým řízen. Obecně platí, že sebelepší nástroj nestačí a je třeba určitá znalost 11
projektového řízení, pečlivost a disciplinovanost. Systémem pro podporu projektového řízení získáme nástroj, který by měl přispět k lepší organizaci, přehlednosti práce a obecně poskytnout projektovému řízení místo, kde projektové řízení dělat. Snahou této práce bude vytvořit nástroj, který použije osvědčené znalosti z praxe a přinese nejen prostor pro projektové řízení, ale určitý návod, jak projekty řídit, a to právě podle metodiky PRINCE2. Následující nástroje jsou dostupné na našem trhu a slouží k podpoře projektového řízení. Některé navíc přináší kompletní podporu pro běh firmy, jiné zase podporu pro detailnější řízení a komunikaci v rámci týmu nebo nabízí funkcionalitu pro řízení vývoje softwarových produktů. Ať už samotné společnosti nebo jejich partneři nabízejí tyto nástroje spolu s dodatečnými úpravami, kterými přizpůsobují nástroj na míru zákazníkovým potřebám.
2.3.1
Atlassian, JIRA
Atlassian je australská společnost, která poskytuje svoje produkty v oblasti řízení projektů, sdílení znalostí a nástrojů pro vývojáře. Jejím hlavním produktem je systém pro procesní řízení JIRA pomocí webového rozhraní i mobilního zařízení. JIRA se uplatní v oblasti vývoje, kdy je potřeba detailněji řídit práci týmu od přiřazení úkolu až po jeho vyhodnocení a reportování. Nabízí tedy prostředky pro práci s úkoly, reportovanými chybami, požadavky. Nástroj podporuje vnitřní komunikaci pomocí diskuse týmu nad dokumenty, požadavky nebo třeba úkoly. Nabízí organizaci a sledování procesů. Produkt JIRA je možné rozšířit o řadu placených modulů, například o systém pro sdílení obsahu a znalostí (Atlassian Confluence). Další nástavbou pak může být nástroj JIRA Agile, která nabízí nástroj pro agilní management. Další rozšíření umožňuje podporu zákaznického servisu (JIRA Service Desk). Jako jeden z modulů je nabízen také konektor pro SharePoint, který umožňuje propojené vyhledávání dat obou systémů. Ze SharePoint dále využije správu dokumentů a workflow. JIRA je licencována na uživatele. Podrobnější přehled i jiných modulů a produktů společnosti Atlassian lze nalézt na domovských stránkách [5]. Modularita takových komplexních nástrojů je jistě výhodou. Tato výhoda se však může proměnit v nevýhodu, například když zákazník potřebuje z každého modulu pouze jeho menší část. Cenová politika pak celé komplexní řešení zbytečně prodražuje. JIRA například v základu neposkytuje dokumentové úložiště, které nabízí až verze Atlassian Confluence. Další nevýhodou je absence českého jazyka.
2.3.2
Icontio, PMPortal
PMPortal je mladým produktem brněnské společnosti Icontio, který slouží pro zpřehlednění, řízení, reporting a evidenci projektů v rámci firemního portfolia. Nabízí prostředky pro správu myšlenek, které mohou sloužit jako zdroj pro nové projekty. Součástí produktu je místo pro správu dokumentace, evidenci a schvalování změn, plánování úkolů a k nim navázané vykazování práce. Slouží pro správu informací o projektech, které jsou dostupné na jednom místě přes webové rozhraní. Produkt je založen na technologii Microsoft SharePoint a díky tomu již v základu nabízí funkčnost dokumentového úložiště, možností procesního zpracování, správ uživatelských rolí, verzování, schvalování dokumentů a další funkčnosti, které jsou popsány v kapitole věnované 12
systému Microsoft SharePoint. PMPortal lze provozovat na firemní infrastruktuře nebo jako cloudovou službu přes rozhraní internetového prohlížeče. Částečnou nevýhodou tohoto produktu může být slabší podpora řízení vývoje software, protože produktu chybí vazba na zdrojové kódy a místo pro správu chyb a požadavků (issue tracking). Více informací o portále lze nalézt na jeho domovských stránkách [6]. Části systému PMPortal jsou využity pro implementaci nově vznikajícího nástroje pro projektové řízení podle metodiky PRINCE2. Více informací o mé roli na vývoji produktu společnosti Icontio lze nalézt v kapitole věnující se realizaci 7.
2.3.3
Oracle, Primavera
Primavera je systém pro projektové řízení pokrývající všechny okruhy dle metodologie PMI. Jako jeden z mála softwarových řešení vychází z některé z projektových metodik, a to konkrétně z PMI (Project Management Institute), z ověřené praxe a z doporučení svých uživatelů. Oracle Primavera představuje integrované řešení pro řízení portfolia projektů (PPM, Project Portfolio Management) a obsahuje funkce pro jednotlivé role řízení, které zajistí potřeby, odpovědnost a dovednosti pro každého člena týmu. Poskytuje jednotné řešení pro správu projektů všech velikostí, přizpůsobí se různým úrovním složitosti v rámci projektu a nabízí možnosti přizpůsobení. Systém je zaměřen na řešení kritických požadavků v odvětvích, jako je strojírenství a stavebnictví, diskrétní a provozní výroba, veřejná správa, finanční služby a další. Konkrétní oblasti, ve kterých lze systém Primavera využít jsou například: plánování, týmová spolupráce, management rizik, správa zdrojů, správa portfolia. Systém je nabízen pomocí cloudové služby a je ho možné doplnit řadou pokročilých rozšíření. Jednotlivá rozšíření a podrobné informace o systému lze nalézt na stránkách produktu. [7]
2.3.4
Ostatní společnosti a produkty
Dalších nástrojů, které lze využít pro řízení projektů je více. Lze zmínit ty menší a úzce specializované, jako je Task Manager [8] od brněnské společnosti, přes další český produkt Easy Project [9], až po univerzálnější technologické platformy, jako je Unicorn Universe [10], IBM Notes [11] i samotný MS SharePoint.
2.3.5
Řízení svépomocí
Kromě výše zmíněných produktů lze k projektům využít i běžně dostupné firemní prostředky, které jsou ve firmách běžně používány. Ze své zkušenosti vím, že jsou to často kombinace běžně dostupných nástrojů a prostředků. Zaprvé je potřeba mít uložiště, kam ukládat dokumenty. Tím může být síťové úložiště, firemní SharePoint, online uložiště v některé z cloudových služeb, poštovní schránka mailového serveru. Pro práci s uloženými dokumenty jsou k dispozici běžné nástroje typu Microsoft Office, v případě cloudových úložišť to může být samotný prohlížeč. Dále se využívají běžné prostředky pro komunikaci, nejčastěji pomoci e-mailů. Vhodným doplňkem bývá kalendář pro evidenci událostí a úkolů s možností automatického připomínání. 13
Zajímavou kombinaci těchto dílčích služeb nabízí cloudová řešení, například od společnosti Google a Microsoft, která spojují dokumenty, poštovního klienta, kalendář, úkoly i kontaktní seznam. Jednotlivé dílčí služby lze sdílet s jinými uživateli. Popsané řešení nemusí být horší oproti sofistikovaným nástrojům, neposkytuje však takovou specializaci v podobě přednastavené struktury, automatizace a funkčnosti, kterou nástroje na projektové řízení nabízí.
2.3.6
Srovnání
Spolupráce
Připomínkovací systém (Issue tracking)
Plánování
Projekt, Portfolio management
Řízení zdrojů
Správa dokumentů
Prostředí
Serena PPM Atlassian JIRA ARCHIBUS Microsoft Office Project Oracle Primavera Easy Project TaskManager Atollon Workshop INSTANTIS Unicorn Universe PMPortal JIRA+Confluence
Česká lokalizace
Následující tabulka 2-1 zobrazuje jednotlivé systémy z pohledu konkrétních funkčností. Jako zdroj dat je využit český portál Projectman.cz zabývající se projektovým řízením. [12]
Ne Ne Ne Ano Ano Ano Ne Ne Ne Ne Ano Ne
Ne Ano Ne Ne Ano Ano Ano Ne Ano Ano Ano Ano
Ano Ano Ano Ne Ano Ano Ano Ne Ano Ano Ne Ano
Ne Ano Ne Ano Ano Ano Ne Ano Ano Ano Ano Ano
Ano Ano Ano Ne Ano Ano Ne Ano Ano Ano Ano Ano
Ano Ano Ne Ano Ano Ano Ne Ne Ano Ano Ne Ano
Ne Ne Ne Ne Ano Ano Ne Ne Ano Ano Ano Ano
Desktop Web Desktop Desktop Desktop Desktop Web Web Desktop Web Web Web
Tabulka 2-1: Funkcionalita existujících produktů. [12] Kromě popsaných a porovnaných funkčních vlastností jsou velmi důležité i způsoby, jak nástroje dokáží projektovému týmu pomoct v jeho práci. Tyto způsoby jsou popisovány v manuálech produktů. Ke komplexnějším a složitějším produktům jsou zákazníkům nabízeny konzultace k zavedení projektového řízení. Nevýhodou tohoto přístupu může být, že každý výrobce systému má svou vlastní představu o tom, jak projekty řídit, nebo spíše jak správně zadávat do jejich systému data. K tomu často bývají uživatelé systému školeni. Projektoví manažeři a projektový tým se pak musí přizpůsobit implementovanému systému a principům jeho používání. Výhodu pak může mít systém, který sice taky nařizuje, jak systém používat, ale nařizuje to podle známých, osvědčených a uznávaných principů, které popisují projektové metodiky. Z výše popsaných systémů se podporou některé ze známých projektových metodik chlubí pouze Oracle Primavera. Taková vlastnost, která o systému říká, že ho lze využít podle zaběhnutých 14
standardů, může systému pomoci i po marketingové stránce. Lze ho pak nabídnout spolu s proškolením uživatelů a jejich případnou certifikací. Takový systém lze pak nabídnou do organizace, kde se již projekty řídí podle některého ze standardů. Jako příklad lze zmínit vynucení metodiky od OGC při řízení státních zakázek v Anglii.
15
3
PRINCE2
PRINCE2 (Projects in a Controlled Environment) je metodika pro projektové řízení, která vznikla ve Velké Británii pod záštitou Office of Government Commerce (OGC), jež je součástí britské vlády a stará se o pravidelnou aktualizaci této metodiky. Ta poslední největší proběhla v roce 2009. Tato kapitola bude zejména vycházet z oficiálního dokumentu Managing Successful Projects with PRINCE2 [1], který představuje plnou verzi této metodiky pro projektového manažera. Existuje i zjednodušená verze Directing Successful Projects with PRINCE2, která je uzpůsobená pro sponzora projektu a členy projektové rady. Metodika je rozšířena nejvíce v Anglii, ale i ve zbytku Evropy či v Austrálii, u vlád i organizací. Na oficiálních stránkách lze nalézt podrobnější informace o výzkumu využívání metodiky PRINCE2, ze kterých je dostupný i závěrečný dokument výzkumu. [13] PRINCE2 je standardem projektového řízení, který přináší doporučené a osvědčené postupy z praxe. Metodika je obecná, aby mohla být aplikována na jakýkoliv projekt bez ohledu na jeho velikost, typ, organizaci, zeměpisnou polohu nebo kulturu. Toho PRINCE2 dosahuje za pomoci oddělení projektového řízení od specifických činností, jako je design, výroba, konstrukce. Tyto specifické aspekty lze integrovat do metodiky a využívat je současně vedle sebe. Není tedy závislá na technologii, jedná se o metodiku. Z důvodu poměrně velké administrativní režie se hodí spíše pro střední a větší projekty, i když může být využita i pro ty menší. Metodika je procesně orientovaná s definovanými postupy pro řešení konkrétních problémů, zodpovědnostmi a projektovými dokumenty, které v rámci řízení projektu vznikají. Je členěna na sedm témat (Theme) a sedm procesů, které jsou tvořeny aktivitami jednotlivých rolí projektového řízení. Jednotlivé procesy a jejich činnosti jsou řízeny hlavně výjimkami, u kterých se stanovují pravidla, limity, rozhodovací pravomoc z pohledu rozpočtu, kvality, času, rizik, atp. Pravidla se stanovují pro jednotlivé úrovně řízení při zahájení projektu. V průběhu projektu tyto tolerance dávají nastavenou určitou svobodu řídícím pracovníkům bez nutnosti podávat hlášení, či zahájit změnové řízení. V textu této práce bude většina originálních anglických pojmů překládána do českého jazyku. Spolu s českými názvy budou uvedeny i anglické originály, které budou využívány u původních obrázků z citované příručky metodiky. Pro překlady pojmů z PRINCE2 existuje oficiální slovník dostupný na internetu [14].
3.1
Struktura PRINCE2
Metodika PRINCE2 je složena ze čtyř základních elementů znázorněných na obrázku 3-1: Principy Jedná se o závazné principy a osvědčené postupy, které musí být naplněny, aby se jednalo o projekt, který může být řízen dle metodiky PRINCE2. Principů je sedm a jsou popsány v kapitole 3.2.
16
Témata Témata jsou aspekty projektového řízení, které musí mít projektový manažer neustále na zřeteli, je třeba je neustále naplňovat a kontrolovat v průběhu celého procesu. Sedm témat vysvětluje detaily o projektu řízeném pomocí PRINCE2. Procesy Sedm procesů v metodice PRINCE2 definuje seznam doporučených činností, produktů a jiných zodpovědností, které je třeba v průběhu celého projektu provádět. Přizpůsobení se projektovému prostředí Protože je PRINCE2 obecná metodika, kterou je možné aplikovat v jakémkoliv projektovém prostředí, je ji nutné přizpůsobit k tomuto prostředí na míru. Diplomová práce se dále o přizpůsobení nebude zabývat. Pro bližší informace lze nahlédnout do PRINCE2 metodiky [1 str. 215-231].
Obrázek 3-1: Struktura PRINCE2. [1 str. 6] Co PRINCE2 nepokrývá Ne všechno z projektového řízení PRINCE2 pokrývá. Jsou zde oblasti, které jsou mimo rozsah metodiky: Odborné aspekty, které v metodice nejsou z důvodu její obecnosti a nezávislosti na odvětví, ve kterém je použita. Detailní techniky, které mohou být využity spolu s PRINCE2, ale PRINCE2 přímo nespecifikuje techniky, jakým způsobem detailně řídit, či plánovat. PRINCE2 pouze specifikuje produktově založené plánování a posouzení kvality. „Leadership“, jako schopnost vést a motivovat podřízené, tým, či organizaci je důležitým aspektem projektového manažera. Součástí metodiky PRINCE2 není.
17
3.1.1
Úrovně řízení
PRINCE2 management rozděluje organizace do čtyř úrovní, kde je každé úrovni metodikou určena zodpovědnost při rozhodování. Jednotlivým úrovním odpovídají i role ze struktury organizace. V kapitole zabývající se procesy (viz 3.4), jsou těmto rolím přiřazeny jednotlivé procesy. Korporátní nebo programový management (Corporate or programme management) Tato úroveň je stranou od řídícího týmu projektu. Z pravidla se jedná o zákazníka, jehož zodpovědností je převzetí projektu, zhodnocení přínosů a uvedení do provozu. Zároveň je autorem mandátu, inicializuje vznik projektu a stanovuje tolerance, se kterými Projektový výbor pracuje. Vedení – Projektový výbor (Directing – Project Board) Projektový výbor je zodpovědný za směřování projektu (viz kapitola 3.4.2) a ze jeho úspěšnost. Schvaluje hlavní plány a zdroje. Potvrzuje odchylky, které překračují tolerance definované pro projektové manažery. Schvaluje přechody mezi fázemi i změnová řízení. Řízení – Projektový manažer (Managing – Project Manager) Projektový manažer je zodpovědný za běžné činnosti spojené s projektovým řízením v rámci definovaných tolerancí od nadřazené úrovně. Jeho hlavní zodpovědností je naplnění cíle projektu podle stanoveného času, kvality, zdrojů, rozsahu, rizika a přínosu. Projektový manažer je hlavním tvůrcem veškeré dokumentace, která je nezbytná pro přechod mezi fázemi. Poskytování – Týmový manažer (Delivering – Team Manager) Týmový manažer (vedoucí týmu) je zodpovědný za realizaci, za doručení produktu projektu v odpovídající kvalitě, čas a cenu.
Obrázek 3-2: Čtyři úrovně řízení. [1 str. 33]
3.2
Principy
Účelem PRINCE2 je poskytnout manažerské metody, které nejsou závislé na velikosti projektu, typu, organizaci, ani kultuře. Metodika je založena na sedmi zásadách: [1 str. 11-14] Kontinuální obchodní zdůvodnění, které má u PRINCE2 projektu důležitou roli. Projekt musí mít opodstatněný důvod pro své zahájení. Toto opodstatnění musí být platné v průběhu celého projektu. Opodstatnění je pravidelně dokumentováno a dokazováno. 18
3.3
Učení se ze zkušeností, kdy se tým učí z předchozích zkušeností, které jsou vyhledávány, zaznamenávány a využívány po celou dobu projektu i po jeho skončení. Definování role a odpovědnosti, které má projekt stanoven spolu s organizační strukturou. Řízení pomocí etap, které jsou plánovány, monitorovány a kontrolovány v každém přechodu etapy. Řízení na základě výjimek, které mají nastaveny tolerance se stanovenými limity s definovanými pravomocemi. Zaměření se na produkty, které jsou definovány v rámci projektu. Přizpůsobení projektovému prostředí, velikosti, komplexnosti, důležitosti, schopnosti a rizikům projektu.
Témata
V průběhu celého projektu je potřeba se věnovat sedmi tématům PRINCE2, která jsou hlavními aspekty projektu a přinášejí otázky, na které je potřeba se ptát a odpovídat na ně. Procesy, popsané v další kapitole, jsou chronologicky propojeny a využívají níže zmíněná témata. [1 str. 17, 18] Obchodní případ (Otázka Proč?) je téma, které přichází s otázkou, zda má a bude mít projekt potenciální obchodní přínos. Organizace (Otázka Kdo?) definuje strukturu rolí a odpovědnosti v daném projektu, která je nutná pro efektivní řízení. Organizace je rozdělena do čtyř úrovní řízení, blíže popsaných v kapitole 3.1.1. Kvalita (Otázka Co?) je téma, které specifikuje vlastnosti výsledného projektu, metody, kterými je projekt vytvářen, měřen a vyhodnocován. Plány (Otázky Jak? Kolik? Kdy?) je téma, jehož cílem je usnadnit komunikaci a organizaci v průběhu projektu. Rozvrhnout vytváření produktů, náklady a potřebné zdroje. Mezi tyto plány patří projektový plán, plán etapy a plán týmu. Plán je sestavován a rozšiřován ve čtyřech krocích: o V prvním kroku v Zahájení projektu (3.4.1), případně v Nastavení projektu (3.4.3) vznikne popis produktu projektu. o V dalším kroku vzniká vývojový diagram produktů, který představuje hierarchickou strukturu produktů a pod-produktů. Představuje rozsah projektu. o Ve třetí fázi je každý dílčí produkt popsán a jsou mu určena detailní kritéria kvality. o V poslední čtvrté etapě vzniká vývojový diagram produktu. Ve kterém jsou zaznamenány jednotlivé aktivity a závislosti mezi nimi. Ukazuje, v jaké posloupnosti budou produkty vznikat. Rizika (Otázka Co když?) napomáhají identifikovat, hodnotit a řídit nejistoty v plánech a v průběhu projektu. Tím zvyšují pravděpodobnost úspěchu projektu. Změny (Otázka Jaký je dopad?) jsou nedílnou součástí projektu a je třeba k nim přistupovat systematicky. Je třeba je identifikovat, hodnotit a řídit specifikovanými autoritami. Změny vznikají z tzv. otevřených bodů (Issue), které mohou být vzneseny 19
projektovým týmem i jinými zainteresovanými stranami. V projektu může dojít ke třem typům událostí: požadavek na změnu, mimo specifikaci, problém/znepokojení. Postup (Otázky Kde jsme? Kam směřujeme?) je téma, které stanovuje mechanismy, kterými jsme schopni porovnávat plánovaný a skutečný stav projektu. Stanovuje, jak se vzniklou odchylkou naložit. Text této pod-kapitoly pouze stručně zobrazuje témata PRINCE2. Podrobnější popis jednotlivých témat lze nalézt v metodice PIRNCE2 [1 str. 19-109]. Pro každé téma je zde specifikován účel, zodpovědnost za téma, vysvětlení pojmů, které se vážou k tématu a postupy, jak s tématem pracovat.
3.4
Procesy
Metodika PRINCE2 definuje sedm procesů, které slouží pro řízení, správu a směřují projekt k úspěšnému ukončení. [1 str. 111-117] Zahájení projektu (Starting up a Project, SU) Směřování projektu (Directing a Project, DP) Nastavení projektu (Initiating a Project, IP) Kontrola Etapy (Controlling a Stage, CS) Řízení dodávky produktu (Managing Product Delivery, MP) Řízení přechodu mezi etapami (Managing a Stage Boundary, SB) Ukončení projektu (Closing a Project, CP) Každý proces obsahuje dílčí akce, kterými jsou například vytvoření nebo aktualizace dokumentace, rozhodnutí, schválení. Návaznost a souběžnost procesů v jednotlivých fázích projektu je přehledně zobrazena na následujícím obrázku 3-3.
Poznámky: Zahájení projektu (SU) je realizováno v úrovni vedení (Directing) i v úrovni řízení (Managing). Měly by zde být alespoň dvě řídicí etapy. Tou první je Inicializační etapa (Initiation stage). 20
Fáze Řízení přechodu mezi etapami (SB) je poprvé realizováno na konci inicializační etapy a je opakováno na konci každé následující etapy s výjimkou poslední etapy. Je využíván také pro přípravu Plánu realizace výjimky. Obrázek 3-3: PRINCE2 procesy. [1 str. 113]
Následující schéma PRINCE2 procesů 3-4 rozšiřuje předchozí diagram a zobrazuje podrobnější návaznost procesů a aktivit s nimi spojených.
Poznámky: Na konci zahajovací etapy je proces Zahájení projektu (Initiating a Project) využit pro požadavek na schválení této fáze Projektovým výborem (Project board). Podkladem je Projektová inicializační dokumentace (PID - Project Initiation Documentation). Stejně tak je Řízení přechodu mezi etapami (SB - Managing a Stage Boundary) využito pro žádost o schválení Plánu etapy (Stage Plan) pro následující řídicí etapu. Uzavírací aktivity jsou plánovány a schvalovány jako součást schvalování poslední etapy. Proto je proces Ukončení projektu (Closing a Project) realizován v poslední etapě. Obrázek 3-4: Model PRINCE2 procesů. [1 str. 115]
21
Každý proces zahrnuje aktivity, které se v rámci procesu musí vykonat. Aktivity obsahují doporučené akce. Popsaný vztah je na následujícím obrázku 3-5.
Obrázek 3-5: Vztah mezi procesy, aktivitami a akcemi. [2 str. 116]
3.4.1
Zahájení projektu
Zahájení projektu je proces, jehož vstupem je myšlenka (Mandát projektu) a výstupem je sada dokumentů a nastavení, které slouží jako podklad pro oficiální zahájení projektu. Jedná se o aktivity přípravy, po které jsme schopni říct, jestli máme životaschopný projekt. [1 str. 121131]
Obrázek 3-6: Zahájení projektu. [1 str. 121]
3.4.2
Směřování projektu
Směrování projektu je proces, na který dohlíží Projektový výbor (Project Board). Ten je zodpovědný za důležitá rozhodnutí v průběhu projektu. Jeho úlohou je schvalovat přechody do jednotlivých etap: Zahájení projektu, Nastavení projektu, Řízení přechodu, Změnové řízení (Ad-hoc), Ukončení projektu. [1 str. 135-146]
22
Obrázek 3-7: Směřování projektu. [1 str. 135]
3.4.3
Nastavení projektu
Účelem tohoto procesu je stanovit pevný základ pro začínající projekt. Jednoznačně určit hranice projektu a seznámit organizaci s prací, kterou je třeba na projektu udělat. [1 str. 149164]
Obrázek 3-8: Nastavení projektu. [1 str. 149] 23
3.4.4
Kontrola etapy
Proces Kontrola etapy je zaměřen na zadávání práce a její následnou kontrolu. Dohlíží na plánované i opravné akce, na to, aby byly etapy v odpovídajícím progresu. O tom informuje projektový výbor. Zachytává a řeší otevřené body (Issue). [1 str. 167-182]
Obrázek 3-9:Kontrola etapy. [1 str. 167]
3.4.5
Řízení dodávky produktu
Cílem procesu Řízení dodávky produktu je řízení vztahu mezi Projektovým manažerem a Týmovým manažerem, a to za pomoci formálních požadavků k akceptaci, vykonávání a doručování dílčích částí projektu. Rolí týmového manažera je koordinace určité práce na produktu projektu. Vykonavatel práce může být interní i externí vzhledem k organizaci zadavatele. [1 str. 185-190]
Obrázek 3-10: Řízení dodávky produktu. [1 str. 185] 24
3.4.6
Řízení přechodu mezi etapami
Účelem tohoto procesu je poskytnout projektovému výboru (Project Board) potřebné informace od projektového manažera, pro posouzení úspěšnosti současné fáze, na základě kterých projektový výbor schvaluje přechod do další fáze. Mezi tyto informace patří zpráva o ukončení etapy, aktualizovaný projektový plán, obchodní případ a plán revize přínosů. Kromě těchto informací (dokumentů), které připravuje projektový manažer, je schvalován i plán další etapy. Součástí může být i plán realizace výjimky, pokud si o něj projektový výbor zažádá z důvodu odklonění se od původních plánů. [1 str. 193-202]
Obrázek 3-11: Řízení přechodu mezi etapami. [1 str. 193]
3.4.7
Ukončení projektu
Účelem Ukončení projektu je uzavřít projekt potvrzenou akceptací. Zároveň je kontrolováno, jestli bylo dosaženo původních cílů specifikovaných v projektovém záměru. Ukončení projektu je prováděno na konci každého projektu, a to i v případě jeho neúspěchu. [1 str. 205-212]
25
Obrázek 3-12: Ukončení projektu. [1 str. 205]
3.5
Zjednodušený popis PRINCE2 projektu a jeho etap
Výše popsané procesy na sebe navazují a v této podkapitole jsou shrnuty do jednoho procesu, který se je snaží jednoduchým a čitelným způsobem ve zkratce popsat. PRINCE2 procesy jsou zde chápány jako jednotlivé etapy projektu. Projekt je zahájen projektovým mandátem, který může být pouhou myšlenkou. Z mandátu vzniká projektový záměr. V projektovém záměru se určují role sponzora a projektového manažera. Projektový manažer pak vytváří potřebné dokumenty pro přechod do další etapy. Přechod je schvalován Projektovým výborem, po kterém je zahájena inicializace projektu. V inicializaci projektu projektový manažer naplňuje jednotlivá témata a vzniká tak nastavení projektu a jeho dokumentace. Projektový manažer například rozpracovává prvotní plán pomocí WBS (Work Brakedown Structure), ta bude posléze rozšiřována o produkty, které budou rozřazeny na jednotlivé balíky práce a ty bude moci přidělit jednotlivým dodavatelům. Jednotlivé produkty plánu budou rozšířeny o dílčí úkoly a vznikne tak komplexní projektový plán zobrazitelný pomocí Ganttova diagramu. V této úvodní nastavovací etapě se také určuje, kolik realizačních etap bude projekt mít. Po schválení nastavovací etapy přechází projekt do procesu realizace. V každém přechodu mezi etapami PRINCE2 specifikuje dokumenty, které projektový manažer musí vypracovat a aktualizovat. Přechody na základě této dokumentace schvaluje Projektový výbor. V průběhu realizačních etap (může jich být více) jsou řešeny některé další PRINCE2 procesy. Provádí se zde běžné aktivity projektového řízení při realizaci. V průběhu realizace může docházet k neplánovaným změnám (mimo rozsah tolerance pravomoci projektového manažera). V tomto případě nastává změnové řízení, při kterém znovu 26
projektový manažer vypracovává dokumentaci, na základě které projektový výbor schvaluje, či jinak rozhoduje, co se vzniklou neočekávanou událostí. V případě schválení je aktuálně běžící etapa znovu zahájena. Projektový výbor může projekt na základě této změny i ukončit. Na závěr přichází ukončení, kde probíhá vyhodnocení projektu a předání produktu. Ukončení je povinné i v případě neúspěšnosti projektu.
27
4
Microsoft SharePoint
Na úvod této kapitoly je platforma SharePoint představena po funkční stránce. V kapitole jsou zmíněny rozdíly mezi jednotlivými jejími verzemi. V druhé části je nastíněna struktura systému SharePoint, zmíněna jeho některá technická specifika, která jsou dále využita a popsána v kapitole Realizace 7. Microsoft SharePoint je technologická platforma, která se zaměřuje na firemní spolupráci. SharePoint nabízí uživatelům sadu nástrojů, které mohou využít k řízení firmy, sdílení informací, dokumentů, automatizovaným firemním procesům, spolupráci nebo ke komunikaci s jinými obchodními systémy. [15 str. 1] Nabízí vlastnosti systému pro správu dokumentů (DMS, Document Management System) a nabízí funkcionalitu systému pro správu procesů (WMS, Workflow Management System). Nabízí řadu mechanismů, kterými ho lze přizpůsobit firemní infrastruktuře. Lze pomocí něj vyvíjet podnikové aplikace, které mají výše zmíněné vlastnosti. Je to sám o sobě informační systém, který si mohou přizpůsobit sami uživatelé. S využitím programování a vývojářského nástroje Visual Studio lze pak SharePoint upravit k nepoznání. O způsobu přizpůsobení SharePoint pojednává kapitola 4.3. Microsoft SharePoint je centrální platforma pro sdílenou spolupráci pro Microsoft Office systémy. SharePoint je nabízen v hlavních dvou produktech. Prvním z nich je SharePoint Foundation a druhým je SharePoint Server. SharePoint Foundation je základní verze poskytovaná jako nástavba nad Microsoft Serverem zdarma a zahrnuje základní služby pro spolupráci, kterými jsou: Webový informační systém určený pro správu a prezentaci. Kolekce webů, listů a knihoven pro uchování a správu strukturovaných informací a dokumentů, jako jsou kontakty, úkoly, připomínky a faktury. Správa zabezpečení využívající Active Directory pro autentizaci přístupu a zabezpečení obsahu s možností rozšíření pomocí jiných přístupů ověření (Security access providers). Prostředí, které lze uživatelsky konfigurovat a přizpůsobovat přes úpravu struktury, designu až po řízení oprávnění. Integrované Windows Workflow Foundation umožňující vytvářet procesně orientované systémy. Služby nabízející rozhraní, jak se systémem komunikovat pomocí externích aplikací. Oproti základní verzi nabízí SharePoint Server další služby, které umožňují využití pokročilejších funkcí: Pokročilá práce s dokumenty a správou obsahu. Integrace dalších datových zdrojů, přidání reportovacích služeb a rozšířenou správu obsahu. Správa a automatizace formulářů. Integrace dalších aplikací. Pokročilý indexační a vyhledávací nástroj. Zakomponování sociálních služeb. Uživatelské přizpůsobení obsahu a upozornění. 28
[15 str. 2] Tyto možnosti pomáhají vytvořit řešení, které dokáže spojit úsilí zaměstnanců, informace, systémy a firemní procesy na jednom místě. Microsoft shrnuje tyto možnosti do šesti kategorií: Stránky jako jednotná platforma pro intranet, extranet a jiná internetová řešení. Ke stránkám lze přistoupit pomocí internetového prohlížeče, programů z rodiny Microsoft Office nebo pomocí mobilních zařízení. Komunity, které pomocí nástrojů umožní lidem efektivně spolupracovat. Nástroje pro spolupráci pomáhají týmům dosáhnout cíle společným úsilím. Obsah, který tvoří nosnou část všech informací a dokumentů. Do této kategorie spadají nástroje pro práci s obsahem i pro jeho správu. Vyhledávání jako nástroj pro snazší nalezení relevantní informace. Nabízí pokročilé technologie indexování svého i externího obsahu (soubory na discích, v databázích, webových stránkách nebo třeba v obsahu souborů). Analýzy a jejich nástroje zprostředkují relevantní informace pro klíčová rozhodnutí. Jsou využity v oblasti Business intelligence jako nástroje pro podporu rozhodování. Kompozice SharePoint jako integrační platforma, která zahrnuje řadu nástrojů, rozhraní, které umožňují uživateli vybudovat rozsáhlá řešení, která je posléze možné přizpůsobovat stále se měnícím potřebám. [15 str. 2-3]
4.1
SharePoint 2013
Nejnovější verze tohoto produktu má označení Microsoft SharePoint 2013, která oproti svému předchůdci 2010 přináší několik vylepšení. Za zmínku stojí napojení směrem k sociálním sítím, bližší propojení s produkty Office, modernější vzhled a zajímavou možností je také přidání aplikace třetích stran způsobem nákupu přes Office Store (online obchod s aplikacemi pro SharePoint). Dalším vylepšením je práce s verzováním dokumentů na úrovni databáze, kdy se každou novou verzí nevytváří nový dokument, ale jsou verzovány pouze bloky souboru, které se změnily. Více informací o novinkách lze získat z oficiálních stránek. Z vývojářského pohledu jádro zůstalo zachováno a s menším úsilím lze přizpůsobené aplikace převést do nové verze. Podrobné informace lze nalézt na stránkách produktu [16]. Co ovšem nezůstalo stejné, jsou hardwarové nároky, které výrazně stouply. Doporučené hardwarové nároky pro různé druhy využití lze dohledat na stránkách výrobce. Pokud v textu práce není řečeno jinak, je popisována vlastnost platná pro obě vydání 2010 a 2013 s jejich placenou (Standard, Enterprise) i neplacenou (Foundation) verzí.
4.2
SharePoint Online
SharePoint Online je součástí cloudové služby Microsoft Office 365. Poskytuje velmi podobnou funkcionalitu jako SharePoint 2013 s tím rozdílem, že je jako služba nabízen společností Microsoft za poplatek. Výše poplatku se odvíjí od funkcionalit, které jsou rozděleny do kategorií. Cena je účtována měsíčně za uživatele. Aktuální porovnání cen jednotlivých verzí s ohledem na funkčnost lze dohledat na webových stránkách poskytovatele. 29
Hlavní rozdíly tedy nejsou ve funkčnosti, jedná se o stejnou technologii, ale rozdíl je zejména ve způsobu pořízení, použití, správou IT a částečně i možnostmi přizpůsobení se potřebám uživatele. Oproti systému SharePoint, který je instalován ve firemní infrastruktuře (anglicky nazýváno pojmem on-premis), nabízí Online verze provozovaná na serverech společnosti Microsoft tyto výhody: Není nutné investovat do poměrně drahé hardwarové infrastruktury ani do licencí. Pořizovací náklady jsou v podstatě nulové. Není nutné investovat poměrně značné náklady spojené s administrací serverů ani náklady potřebné pro systémy SharePoint, který je z pohledu správy velmi náročný. Microsoft „garantuje“ poměrně vysokou dostupnost ve formě „tří devítek“ (99,9 %). Pokud garantovanou dostupnost v daném platebním měsíci nedodrží, vrací procentuální část platby zpět uživateli. [17] Procentuální dostupnost 99,9% vyjadřuje pravděpodobnost, s jakou systém poskytuje nabízené služby. Uvádí se pomocí ní spolehlivost i doba, za kterou je systém po poruše zpět v provozu. Garantovaná dostupnost 99,9 % v přepočtu na čas říká, že systém bude nedostupný přibližně po dobu 43 minut a 50 sekund za jeden měsíc. [18] 𝑀𝑇𝐵𝐹
Výpočet dostupnosti lze vyjádřit vzorcem: 𝐷𝑜𝑠𝑡𝑢𝑝𝑛𝑜𝑠𝑡 = 𝑀𝑇𝐵𝐹+𝑀𝑇𝑇𝑅 , kde MTBF (Mean Time Between Failures) je doba, kdy byl systém dostupný, a kde MTTR (Mean Time to Repair) je doba nedostupnosti. [18] Na druhé straně má tento přístup i svá negativa v podobě uložených dat na cizím prostředí, což u lidí stále vyvolává nedůvěru. Další nevýhodou je omezené množství úprav, které lze na Online řešení provést. Otázka porovnání bezpečnosti a dostupnosti obou řešení je podle mě poměrně problematická. Ze zkušenosti vím, že firmy provozující Microsoft SharePoint ve vlastní infrastruktuře spoléhají na dodavatelské společnosti, protože sami nemají odborníky na správu těchto technologií. Je tedy otázkou, jestli jsou taková data v rukou firem třetích stran, i když na serverech společnosti, ve větším bezpečí než na serverech v Microsoftu. Na druhou stranu z pohledu vývojáře a možnosti programového přizpůsobení není možné Online produkt upravit neomezeně dle požadavků zákazníka.
4.3
Struktura
Samotný SharePoint není nic jiného než webová aplikace, která běží na Internetovém informačním serveru (IIS, Internet Information Services) za použití technologie ASP.NET využívající Microsoft SQL databázi. Struktura portálu je znázorněna na následujícím zjednodušeném diagramu 4-1, který jednotlivé komponenty zobrazuje v určité hierarchii. Jednotlivé originální pojmy z oblasti systému SharePoint jsou uváděny spolu s jejich českými překlady. Často jsou některé překlady matoucí a při dohledávání dodatečných informací v literatuře nebo na internetu, je anglické názvosloví nezbytné.
30
Farma / Farm
0..* Webová aplikace / Web application
0..* Kolekce webů / Site collection
1 Hlavní web / Site (Root Web)
Web / Web 0..*
1..* Sloupec / Field
1..* Typ obsahu / Content type
0..* 0..* Seznam / List
Dokumentová knihovna / Library
0..* Záznam / Item
Obrázek 4-1: Konceptuální diagram jednotlivých stavebních prvků systému SharePoint. Pro snazší představu je na následujícím obrázku 4-2 znázorněn diagram, který zachycuje konkrétní ukázku SharePoint struktury. Ta je ve skutečnosti situace lehce složitější mezi vazbami seznamů, typy obsahu a sloupci. Ve skutečnosti jsou typy obsahu (Content type) i sloupce (Field) vytvořeny na hlavním webu (Root web). Sloupce jsou pomocí referencí přiřazovány k typům obsahu. Mezi typy obsahu existuje dědičnost podobně jako u dědičnosti v programovacích jazycích. Typ obsahu představuje třídu a sloupce představují vlastnosti třídy. Tyto vlastnosti dědí od svých předků.
31
Farma: Farm Administrace: Web application Nápověda: Site collection
Centrální administrace: Site collection
Portál: Web application Portál: Site collection Hlavní web: Root web Projekt1: Web
Projekt2: Web Členové týmu: List Uživatel1: Item + +
Pavel Novák: Jméno Uklízeč: Pozice
Uživatel2: Item + +
Pavla Nováková: Jméno Ředitelka: Pozice
Obecný projekt: Content type +
Název projektu: Field
Šablony: Library
Interní projekt: Content type
Stavy projektu: List
Seznam projektů: List Projekt2: Item
Externí projekt: Content type +
Dodavatel: Field
+ +
Projekt 1: Item
Firma123: Dodavatel Výměna oken: Název projektu
Obrázek 4-2. Objektový diagram konkrétní ukázkové konfigurace. Následující příklad ukazuje dědičnost mezi některými předdefinovanými a uživatelsky přidanými typy seznamu. V závorce je uvedeno vnitřní id typu obsahu. Pomocí něj lze vyčíst hierarchickou strukturu. Systém (0x) o Položka (0x01) Dokument (0x0101) Formulář (0x010101) Obrázek (0x010102) Událost (0x0102) Úkol (0x0108) Úkol pracovního postupu (0x010801) Úkol správy (0x010802) Historie pracovního postupu (0x0109) Obecný projekt (0x0100A9E86D142D8B495DABD26E92C5F449AF) 32
Interní projekt (0x0100A9E86D142D8B495DABD26E92C5F449AF01) Externí projekt (0x0100A9E86D142D8B495DABD26E92C5F449AF02) K seznamu (List) lze přiřazovat typy obsahu a tím seznam získává jejich sloupce. Ve skutečnosti nedojde k přiřazení typu obsahu, který je uložen na hlavním webu, ale je vytvořen nový, který dědí od toho přiřazovaného. Jednotlivé sloupce jsou pro daný list vytvořeny zkopírováním těch globálních. Tento způsob umožňuje, aby různé seznamy mohly mít přizpůsobené globální sloupce nebo typy obsahu svým potřebám. Jednotlivé záznamy seznamů (Item) jsou pak instancemi konkrétních typů obsahu. Výše popsaná struktura by se dala nazvat datovou vrstvou. Je tvořena seznamy. Při vytváření seznamů a knihoven na SharePoint webu se zároveň automaticky vytváří aplikační a prezentační vrstva pomocí předdefinovaných stránek a šablon. SharePoint databáze je vytvořena již od instalace samotného systému SharePoint a přidáváním seznamů se její struktura nijak nemění, pouze se přidávají nové záznamy do již existujících tabulek. Databázi Microsoft nedoporučuje jakkoliv upravovat ani do ní zasahovat. Nicméně znalost její struktury může být poučná. Jak lze přizpůsobit datovou strukturu, aplikační logiku a prezentační vrstvu je popsáno dále v kapitole 4.5.
4.4
Oprávnění
Oprávnění je klíčovou součástí jakéhokoliv firemního systému a u systému SharePoint to platí obzvlášť. Nastavené oprávnění (Role assignment) je trojice objektu (Securable object), člena (Principal) tvořeného buď uživatelem (User) nebo skupinou (Group), a rolí (Role definition). Závislosti jsou zobrazeny na následujícím diagramu 4-3. Oprávnění / Role definition
1
«asociation» Přiřazené oprávnění / Role assignment Člen / Principal
Skupina / Group
2
Zabezpečitelný objekt / Securable object +Předek + Dědí oprávnění: bool
Uživatel / User
Položka / Item
Seznam / List
Web
Obrázek 4-3: Konceptuální model oprávnění. 33
Na následujícím výčtu jsou popsány definice některých entit: Entita Člen: Objektem typu (#Člen) je každá osoba nebo skupina, které může být uděleno oprávnění. Entita Skupina: Objektem typu (#Skupina) je každé seskupení uživatelů, kterému lze udělit oprávnění. Entita Uživatel: Objektem typu (#Uživatel) je každá osoba, která se může přihlásit do systému a je možné jí to oprávnění udělit. Entita Oprávnění: Objektem typu (#Oprávnění) je výčet atomických akcí, které lze nad nějakým objektem provést. Entita Zabezpečitelný objekt: Objektem typu (#Zabezpečitelný objekt) je každý objekt, kterému lze přiřadit nějaké oprávnění pro některého uživatele. Asociační entita Přiřazení oprávnění: Objektem typu (#Přiřazení oprávnění) je každá reprezentace vztahu mezi členem (#Člen) a objektem (#Zabezpečitelný objekt) se smyslem: (#Oprávnění), které nabývá daný uživatel nebo skupina k danému objektu /0,1 : 0,M. Vazby mezi entitami popisuje následující výčet: 1: Oprávnění (#Oprávnění)-s, které byly použity při přiřazení oprávnění (#Přiřazené oprávnění) /1,N : 0,M. 2: Objekty (#Zabepečitelný objekt)-s, jejichž předkem je jiný objekt (#Zabepečitelný objekt), od kterého mohou dědit oprávnění /0,M : 1,1. Předek položky může být jiná položka (složka), nebo seznam, do kterého položka patří. Rodičem listu je vždy web. Rodičem webu je jiný web (neplatí pro hlavní kořenový web, ten rodiče už nemá). Následující obrázek 4-4 pro názornost ukazuje jednotlivé úrovně oprávnění, které SharePoint v základu nabízí. Tato oprávnění je možné uživatelsky rozšířit.
Obrázek 4-4: Úrovně oprávnění. 34
Úrovně oprávnění v systému SharePoint jsou tvořeny pomocí jednotlivých atomických oprávnění, kterými jsou například: spravování seznamů, přidání, odebrání položky, spravování oprávnění a další. Rozepsané úrovně oprávnění lze nalézt na stránkách podpory produktu [19]. Oprávnění jsou vyjádřena čísly 2𝑥 , kde 𝑥 ≥ 0 ∧ 𝑥 < 64. Jejich bitovým součtem je lze kombinovat a vytvářet tak úrovně oprávnění, které lze pak reprezentovat jedním 64-bitovým číslem. Výhodou oprávnění v systému SharePoint je to, že se vývojář nemusí nijak starat o samotné vyhodnocování oprávnění. Uživatel nebo vývojář pouze řeší, komu a čemu, jaká oprávnění nastavit. I při nastavování je ale třeba dbát na určitá pravidla, a to zejména počet specificky nastavených oprávnění na jednotlivých objektech. Není proto vhodné, aby každá položka velmi rozsáhlého seznamu měla nastavena svá vlastní oprávnění. Pro tyto účely je vhodné využít dědění oprávnění od nadřazeného objektu, kterým může být složka, seznam nebo celý web. SharePoint neumožňuje nastavovat oprávnění na jednotlivé sloupce seznamu, ani jednotlivé pohledy. Tuto skutečnost je možné řešit programově, například vytvořením vlastních sloupců.
4.5
Způsoby úpravy a vývoje
SharePoint jakožto univerzální informační systém nabízí několik možností, jak ho přizpůsobit. Databázovou vrstvu upravit nedovolí, to ale neznamená, že nejde upravovat datová vrstva, která nese uživatelská data. Datovou strukturu systému SharePoint lze přizpůsobovat pomocí definic listů, jejich sloupců a vazbami mezi nimi. Lze vkládat indexy, databázové restrikce. Tím, že upravujeme strukturu, SharePoint zároveň automaticky vytváří aplikační i prezentační vrstvu. To znamená, že při vytvoření a nadefinování struktury nového seznamu jsou zároveň vytvořeny formuláře pro vkládání nových záznamů, jejich editaci i formuláře pro zobrazení všech záznamů v seznamu. Seznamy obsahují mechanizmy pro řazení, filtrování, seskupování, verzování, vytváření nových pohledů nad položkami. Uživatel má možnost zapnout si notifikaci při změně položky. Aplikační logiku lze upravovat pomocí uživatelských procesů, které lze definovat nástrojem Microsoft SharePoint Designer nebo pomocí složitějšího programování přes Visual Studio. Pomocí programování lze v C# kódu rozšiřovat události, které se spouští při úpravách SharePoint objektů. Tyto události se nazývají Event receiver (viz kapitola 7.1.3). Prezentační vrstvu lze přizpůsobit úpravou automaticky vytvořených stránek (aspx), do kterých se vkládají takzvané webové části (Web part), které slouží například pro zobrazení obsahu seznamů, pro založení, zobrazení, úpravu, položky. Jsou to komponenty, které se vkládají do stránek a mohou se na ní vzájemně propojovat. Pokud nechceme editovat přímo prezentační aspx stránky, ale přesto chceme například určit, jaká pole (metadata) se mají ve formuláři zobrazit uživateli, lze využít typy obsahu (Content type), ve kterém specifikujeme, jestli se daný sloupec zobrazí a jestli bude povinný ve formuláři pro založení (New form), zobrazení (Display form), editaci (Edit form). Těchto typů obsahu lze k listu vytvořit více a jednotlivé položky mají přiřazeny právě jeden z nich. Struktura je patrná na diagramech: 4-1 a 4-2. Uživatel si pak může vybírat z typů obsahu a tím se mu zobrazují rozdílná pole. Viz následující obrázek 4-5. 35
Obrázek 4-5: Ukázka použití různých typů obsahu, kdy se automaticky zobrazují různá pole. Upravit SharePoint lze v podstatě dvěma způsoby. Tou první je jeho nastavování, či konfigurace pomocí uživatelského rozhraní skrz internetový prohlížeč, případně pomocí nástroje Microsoft SharePoint Designer. Druhou možností je použití vývojového nástroje Microsoft Visual Studio a balíčků, které se na SharePoint instalují.
4.5.1
Nastavování
Nastavováním je myšlen způsob, kdy pomocí internetového prohlížeče, případně nástroje Microsoft SharePoint Designer je na portálu přizpůsobována struktura webů a listů, jsou nastavována práva, jsou vytvářeny uživatelské stránky a sekvenční procesy. Také je možné do určité míry upravit horní pás karet (ribbon) a další. Designer oproti prohlížeči nabízí rozhraní pro definici workflow, externích datových zdrojů, úpravu stránek a pár dalších drobností. Na úpravu struktury poslouží oba stejně. SharePoint je z větší části nastavován pomocí xml konfigurací. V xml konfiguraci jsou uložené definice listů, knihoven, sloupců, typů obsahu, workflow, uživatelského pásu karet (ribbon). Zmíněné nástroje de facto nabízí uživatelské rozhraní k těmto xml souborům. Uživatel proto s xml soubory v ideálním případě nepřijde do styku. Výhodou tohoto přístupu upravování je, že přizpůsobit SharePoint dokáže vyškolený správce. Přizpůsobit ho do poměrně rozsáhlých řešení, která jistě budou řadě firem pro svůj intranetový portál dostačovat. Problém částečně nastává, pokud chceme složitější funkcionalitu, kterou může být stavové workflow, dynamické nastavování práv, komunikace s externími systémy, přizpůsobování původních šablon. Tyto problémy do jisté míry lze vyřešit pomocí SharePoint Designeru. Zde je poměrně problematické jakékoliv znovupoužití. Protože je potřeba vše „naklikat“, není možné nastavení přenášet v rámci systému či mezi různými SharePoint řešeními (exporty i importy částečně SharePoint podporuje). Co již nelze tímto způsobem řešit jsou časované úlohy (timer job), uživatelské notifikace, dynamické vytváření nových webů, listů, komunikaci s externími aplikacemi. Nelze používat programovací jazyk c#.
36
4.5.2
Programování
Programové úpravy jsou náročnější a je třeba systému SharePoint více rozumět a znát jeho principy. Vývoj probíhá pomocí Visual Studia a na nainstalovaném systému SharePoint přímo na vývojářském PC. V případě dalšího vývoje je možné zdrojové soubory upravovat a instalované řešení aktualizovat. Podle mé zkušenosti je aktualizace jedna z nejkomplikovanějších částí vývoje. O životním cyklu vývoje a jeho možnostech pojednává článek z oficiálních zdrojů [20]. Balík řešení (Solution package) Při vývoji vzniká tzv. balíček řešení (Solution package), který obsahuje veškeré zdrojové soubory, které tvoří xml konfigurace, aspx stránky a případné binární knihovny. Tento balíček řešení je třeba nasadit a nainstalovat na SharePoint. Struktura balíku je tvořena vlastnostmi (Feature), které mohou být nainstalovány na různé části SharePoint (farma, webová aplikace, kolekce webů, web). Vlastnosti (Feature) obsahují jednotlivé elementy, které jsou tvořeny xml konfiguracemi, stránkami, binárními soubory a jinými. Podrobnější informace o balíčcích i o nasazování lze nalézt v literatuře [21 str. 699787], [22 str. 35-77].
4.6
PowerShell
Windows PowerShell je skriptovací nástroj pro správu a administraci Microsoft technologií, který je postaven na technologii .NET Framework. Je nedílnou součástí administrace i vývoje vlastních řešení pro SharePoint. I když SharePoint nabízí uživatelské rozhraní pro administraci, na řadu pokročilých nastavení je potřeba využít skriptů, které jsou vhodné i pro automatizaci těchto úkonů. Z pohledu vývojáře nabízí prostředky pro nasazování řešení, jejich aktualizaci i údržbu. Zároveň je velmi užitečným při vývoji, kdy si vývojář veškeré úkony, které by programoval v prostředí Visual Studio a následně distribuoval na SharePoint, může vyzkoušet pomocí skriptů. Protože je PowerShell postaven na .NET, je možné použít ty samé prostředky, jako při programování v nástroji Visual Studio. To zejména zrychlí vývoj, protože nasazení upraveného řešení na testovací SharePoint je poměrně časově náročné. Je například možné změnit xml definici sloupců, listů, přenastavit parametry workflow, upravit hodnoty v seznamech a mnoho dalších. Následující ukázka 4-1 například vypíše všechny typy obsahu na zadané kolekci webů s ohledem na jejich dědičnost. Tento skript byl použit pro vypsání typů obsahu v kapitole 4.3. $web = Get-SPWeb http://webUrl $web.ContentTypes | Sort Id | % { $spacesCount = $_.Id.ToString().Length $spaces = New-Object String(" ", $spacesCount) [string]::Format("{0}{1} ({2})", $spaces, $_.Name, $_.Id) }
Ukázka 4-1: Skript pro vypsání typů obsahu.
37
Následující skript z ukázky 4-2 spustí dotaz nad projektovým listem a vypíše ty projekty, které mají id stavu 1. $web = Get-SPWeb http://webUrl $list = $web.Lists["Project"] $q = New-Object Microsoft.Sharepoint.SPQuery $q.Query = [string]::Format( "<Where>
{1} ", "WFStateId",1) $dt = $list.GetItems($q); $dt | % {[string]::Format("{0}, {1}",$_.Title, $_["WFStateId"])} $web.Dispose()
Ukázka 4-2: Skript dotazu nad listem. Následující skript z ukázky 4-3 lze využít při aktualizaci stávajícího řešení pomocí nového balíčku řešení. Skript navíc spouští administrační službu, která pro aktualizaci musí být spuštěna. $wspPath = "D:\SharePoint\WSP\" $wspName = "SolutionPackage.wsp" if((Get-Service SPAdminV4).Status -ne [System.ServiceProcess.ServiceControllerStatus]::Running) { net start SPAdminV4 } Update-SPSolution -Identity $wspName -LiteralPath $wspPath$wspName -GacDeployment
Ukázka 4-3: Skript k aktualizaci existujícího řešení.
38
5
Analýza systému
Jednou z nejdůležitějších částí vývoje systému je jeho analýza, kde je nutné získat představu o vznikajícím systému a o tom, co se od něj očekává. V prvních fázích je to sběr požadavků od zákazníka. Ty bývají často velmi obecné a je třeba je dále specifikovat a formálně upravit. Jako formální výstup požadavků může sloužit například diagram případů užití (Use-Case diagram). Požadavky na systém vzešly hlavně ze samotné metodiky PRINCE2, která popisuje potřeby projektového řízení, a platformy Microsoft SharePoint, na které bude portál vyvíjen. Popisovaný systém vznikal za spolupráce firmy Icontio, ve které jsem absolvoval Interim Project. Firma mi umožnila absolvovat krátký úvod do metodiky PRINCE2 a konzultaci s odborníky v oboru. Protože je metodika PRINCE2 velmi rozsáhlá, není možné v této práci zachytit veškeré její specifika. Není to možné i z toho důvodu, že velká část aktivit, které je při řízení projektu nutné vykonávat, jsou závislé na znalostech, schopnostech a pečlivosti jednotlivých aktérů (řídicích pracovníků). Systém má sloužit jako podpora pro projektové řízení podle metodiky PRINCE2 a bude se snažit nabídnout šablony a procesy pro jednodušší spolupráci jednotlivých rolí. Oproti existujícím řešením nabídne také platformu SharePoint, pomocí které si uživatel dál bude moci portál upravovat.
5.1
Specifikace požadavků
V této části jsou popsány funkční i nefunkční požadavky na systém. Největší důraz bude kladen na funkční požadavky, které popisují samotnou funkcionalitu. Na základě těchto informací je sestaven diagram aktivit, který zobrazuje možnosti jednotlivých aktérů projektového řízení. Další částí analýzy jsou nefunkční požadavky, ve kterých je zmíněn zejména výkon, dostupnost a kvalita systému.
5.1.1
Funkční požadavky z pohledu PRINCE2
Nejobecnějším, ale nejdůležitějším požadavkem je podpora projektového řízení dle metodiky PRINCE2. Tato metodika je poměrně hodně založena na časté aktualizaci dokumentace a jejím sdílením. Projektový manažer připravuje dokumentaci pro schválení projektovým výborem. Zároveň projektový manažer musí zadávat a přebírat práci od realizačního týmu. V případě neočekávané situace je třeba řešit změnová řízení. Tyto dílčí procesy jsou navíc propojeny do jednoho celku, ve kterém komunikují a spolupracují. Požadavky na systém jsou následující. Podpora procesu popsaného v kapitole 3.5: Zjednodušený popis PRINCE2 projektu a jeho etap. o Umožnit vložení projektového mandátu / nápadu / myšlenky. o Schválit mandát a založit na jeho základě projektový záměr. o Umožnit zadání proměnlivého počtu realizačních etap. o Umožnit předávání projektu do dalších etap s kontrolou povinných dokumentů. o Umožnit evidenci a schválení změnového řízení. 39
5.1.2
o Zpřístupnit projektový plán, pomocí kterého je možnost rozpadnout projekt na produkty a k nim přiřadit úkoly. o Nabídnout registr rizik, kvality, otevřených bodů. Spravovat projektové údaje. Mít možnost zadávat projektový tým. Řídit oprávnění do systému podle rolí uživatelů. Mít prostor pro ukládání směrnic a pokynů pro uživatele systému. Mít možnost správy šablon dokumentů a jejich využití. Mít k dispozici reporty nad projekty.
Funkční požadavky z pohledu portálu
Aby sytém byl co nejpoužitelnější ve firemní prostředí a držel se trendu dnešních požadavků, bude využito webového rozhraní v podobě intranetu. Systém bude podporovat práci s uživateli a skupinami: autentizaci a autorizaci uživatelů, členění uživatelů do skupin, správu uživatelů, řízení oprávnění. Systém bude podporovat práci s dokumenty, jako je ukládání, vyhledávání. Měl by podporovat práci s uživatelskými i schvalovacími úkoly, podporovat emailové notifikace. Pro výměnu znalostí a informací by systém měl nabídnout prostředky pro zadávání znalostní báze. Systém bude komunikovat česky a anglicky. Bude však umožňovat rozšíření o další jazyky.
5.1.3
Nefunkční požadavky
Pro použití v praxi je třeba specifikovat i nefunkční požadavky, jako je doba odezvy, dostupnost, zálohování, velikost a počet souborů. Je využito platformy Microsoft SharePoint, která je sama o sobě poměrně náročná na hardware a sama přináší několik omezení, jako je velikost souborů, počet záznamů zobrazených v rámci jednoho seznamu, doporučená velikost databáze pro jednu kolekci webů a řada dalších. Doba odezvy, zálohování, obnovy je v režii SharePoint administrace, pod kterou spadá způsob instalace, konfigurace, údržba nebo hardwarové vybavení. V této práci na tyto požadavky nebude brán příliš zřetel, protože nejsou její podstatou.
5.1.4
Diagram případů použití
Následné diagramy užití zobrazují aktéry, jako jednotlivé role z úrovně řízení a akce, které budou moci v systému provádět. Zrevidovat přínosy
Zadat projektový mandát
Korporátní nebo programový management / zákazník
Obrázek 5-1: Akce korporátního nebo programového managementu, nejčastěji zákazníka. 40
Vytvoř schvalovací úkol
<
>
Pošli notifikaci
<>
Kontrola povinných dokumentů <>
Zadat změnu
<>
Zadat výkaz práce
Správa dokumentů
Požádání o schválení projektu
Požádat o schválení změny
<>
{pokud nemá PM pravomoc změnu schválit sám }
Schválit změnu
Správa projektu
<>
Správa projektového plánu {pokud úkol patří
<> danému uživateli}
Projektový manažer <>
<>
Správa úkolů
Týmový manažer člen týmu
<<extend>>
Správa projektového týmu
Pošli notifikaci
Editace metadat projektu
Obrázek 5-2: Akce projektového manažera a členů týmu.
Schval přechod
Schval změnu
Vrať přechod k doplnění
Zamítni změnu
<>
Přejdi k ukončení projektu
Projektový výbor
Obrázek 5-3: Akce Projektového výboru.
Správa nastavení
Správce portálu
<>
Správa projektových stavů
<>
<>
Správa uživatelů
<>
Správa dokumentových typů
Správa dokumentových šablon
Obrázek 5-4: Akce správce celého portálu.
41
Návrh systému
6
Při návrhu portálu je nutné brát ohled na okolní systém, pod kterým portál běží. To je do jisté míry limitující, na druhou stranu není třeba navrhovat některé části systému. Portál je vyvíjen pro Microsoft SharePoint, kde není potřeba navrhovat databázovou vrstvu. Datová vrstva je zachycena pomocí konceptuálního diagramu a promítne se do propojených SharePoint webů, seznamů, sloupců a typů obsahu. Prezentační vrstva je automaticky vytvořena na základě datové vrstvy s drobnými změnami popsaných dále v této kapitole. Více informací o těchto vrstvách je obsaženo v kapitole 4.3.: Struktura SharePoint. Ze systému SharePoint je využito co možná nejvíce. Protože se jedná o pokročilý informační systém pro správu uživatelského obsahu, lze některé požadované funkce realizovat vestavěnými funkcemi přímo ze systému SharePoint. SharePoint také pokrývá funkcionalitu DMS (Document Management System) i WMS (Workflow Management System). Návrh se tedy nezabývá Funkční požadavky z pohledu portálu z kapitoly 5.1.2.
Konceptuální diagram
6.1
Na následujícím diagramu 6-1 je zobrazen zjednodušený konceptuální diagram portálu. Zobrazuje vazby mezi definovanými entitami. Issue
Budget
Quality
Wiki
System task
Portal
Setting
Risk
Document template
WBS/Plan/Task Task
Project + +
ProjectBoard: users ProjectManager: user
Idea / Mandate +
Customer: user
Product +Subproduct
Stage
+Parent
Work report
Team member
Change
Document
Document type
Obrázek 6-1: Konceptuální diagram portálu. 42
6.2
Návrh architektury portálu pro SharePoint
V předcházející kapitole je zobrazen konceptuální diagram, který nebere v potaz možnosti a strukturu systému SharePoint. V následujícím diagramu je tento konceptuální diagram upraven tak, aby odpovídal prostředkům SharePoint. Těmito využitými stavebními prvky jsou Web, Seznam, Dokumentová knihovna, Položka seznamu, Wiki knihovna, Seznam úkolů, Typ obsahu. V kapitole 4.3 jsou tyto stavební kameny systému SharePoint zobrazeny i s vazbami mezi nimi. Většina entit z konceptuálního diagramu se promítne do seznamů nebo knihoven, jak je znázorněno na následujícím diagramu. Problém nastává s entitou Projekt. Jednou z možností je, udělat projektový list, kde jeden záznam představuje jeden projekt. Ostatní entity, které jsou nějakým způsobem na projekt navázány (Riziko, Člen týmu, …) se budou na svůj projekt odkazovat. Jedná se v podstatě o klasický databázový způsob, kdy například tabulka rizik odkazuje cizím klíčem na tabulku Projektů. Všechna rizika všech projektů jsou pak v jedné společné tabulce. Druhou možností je využití webů, které umožní větší oddělení projektových prostorů. SharePoint umožňuje definovat šablony webů, které v sobě zahrnují jednotlivé listy a dokumentové knihovny. Vznikne tedy projektová šablona s předdefinovanou sadu listů a každý projekt bude mít svůj web a na něm své listy. Výhodou tohoto řešení je jeho nezávislost od ostatních projektů. Každý projekt si tak může projektový manažer upravit podle svých představ bez zásahu do struktury listů v jiných projektech. Další velkou výhodou oddělených listů je to, že lze lépe využít dědičnosti oprávnění. Oprávnění aktérům (členům týmu) lze nastavovat na úrovni projektového webu a listů a není nutné je nastavovat na jednotlivé položky. Tím se radikálně zmenší počet unikátně nastavených oprávnění. Nevýhodou tohoto řešení je, že záznamy stejného typu skrz všechny projekty nejsou pohromadě a nelze na ně jednoduše napojit reporty. Kromě projektových webů bude nutné vytvořit list projektů, ve kterém budou uložena jednotlivá projektová metadata. Jedno z těchto metadat je odkaz na projektový web, projektového manažera a mnoho dalších. Projektový mandát bude také součástí projektového listu, bude rozlišen Typem obsahu (Content type). Na projekt se mandát přepne pomocí procesu, kdy se založí projektový web a k němu se vytvoří odpovídající listy. Na diagramu 6-2 je zobrazena logická vazba mezi listem stavů a dokumentovou knihovnou. Tato vazba provazuje stav se složkou, ve které bude dokumentace pro aktuální projektový stav. Každému stavu tedy bude odpovídat jedna složka v dokumentové knihovně. Změny se budou chovat podobně, až na ten rozdíl, že jejich složky budou zanořeny ve složce aktuálního stavu. Při vložení nového stavu nebo změny systém musí přidat i odpovídající složku.
43
Portal: Site Collection Portal: Root Web
Project: Web Issue: List
Budget: List
Project: List
Quality: List
Project: Item + +
Risk: List
ProjectBoard: users ProjectManager: user
Mandate: Item +
Customer: user
Stage: List
WBS/Plan: Task List
Work report: List
Wiki: Wiki List
Change: List
Document: Library
Team member: List
Document template: Library
Document type: List
System task: Taks List
Setting: List
Obrázek 6-2: Aplikovaný konceptuální diagram na stavební prvky systému SharePoint.
6.3
Objektová vrstva
Pro jednodušší práci s SharePoint objektovým modelem, který zpřístupňuje jednotlivé objekty, jako jsou seznamy, weby, položky, je vhodné využít další pomocnou mezivrstvu. Na základě této mezivrstvy bude dědičností vytvořen model odpovídající navržené struktuře v kapitole 6.2. Na následujícím diagramu tříd 6-3 jsou tyto závislosti znázorněny. Pomocná vrstva kopíruje strukturu SharePoint, kde třídy Web, List, Item, Field, Member mají svůj obraz v dll SharePoint knihovnách. V diagramu nejsou kvůli přehlednosti znázorněny některé další třídy: Typ obsahu (ContentType), třídy pracující s oprávněním: Role, RoleAssignment. Vrstva modelu portálu je tvořena převážně jedináčky (stereotyp singleton), jež představují jedinečné instance jednotlivých listů a webů. Jedná se o objekty, přes které je možné přistupovat z datové vrstvy na jejich fyzické protějšky. Diagram zobrazuje pouze některé instance listů se základními metodami.
44
Help layer Member +
Item
SPMember: int
+
Field
SPItem: int
+ +
FieldLookup
Name: string SPField: int
-
FieldMember
LookupList: List
0..* List + + +
Name: string SPList: SPList Url: uri
+ + + + + +
AddItem() : void DeleteItem() : void GetItems() : SPListItems GetSPList() : SPList SetItemsPermissions() : void SetListPermissions() : void
1
StatefulList + + + + +
State
GetActualState() : State GetPosibleTransitions() : Transitions GetPreviousState() : void MoveNextState(Transition) : void SetActualState() : void
1
+StartState 1 1
1
+
IsRootWeb() : bool
1..* 1..*
«delegate» + ActionMethod() : void + ConditionMethod() : bool
TaskList
Web SPWeb: int
0..*
1 +EndState
Transition
0..*
+
0..*
+ + +
CompleteTask() : void CreateTask() : void DeleteTask() : void
Portal model layer «singleton» RootWeb
«singleton» SystemTaskList
«singleton» ProjectWeb +
GetProjectItem() : Item
«singleton» TeamList +
GetAllTeamMembers() : Members
«singleton» ProjectList + + + + + + + +
CreateProjectWeb() : ProjectWeb GetAllMembers() : Members GetCustomer() : member GetProjectBoard() : Member GetProjectManager() : Member GetTasks() : Items IsProject() : bool IsProjectMandate() : bool
Obrázek 6-3: Diagram tříd portálu.
6.4
Proces PRINCE2
V kapitole 3.4: Procesy jsou popsány jednotlivé dílčí procesy PRINCE2 projektu, které pracují s tématy z kapitoly 3.3. V kapitole 3.5 je popsán zjednodušený popis PRINCE2 projektu a jeho etap. Na základě tohoto popisu je vytvořen stavový automat 6-4. Diagram navíc obsahuje dokumenty, které budou vyžadovány pro přechod do dalších fází. Žádosti o schválení a samotné schválení je navrženo následovně. Projektový manažer zadá potřebné dokumenty, které jsou vyžadovány pro aktuální schválení. Poté přes editační formulář projektu (entita Project: Item) požádá projektový výbor o schválení. Systém zkontroluje existenci povinných dokumentů pro danou etapu. Projektovému výboru je vytvořen úkol a je mu zaslána notifikace. Projektový výbor přes schvalovací formulář rozhodne, jestli požadavek schvaluje a může dojít k přechodu do další fáze, nebo požadavek vrátí k doplnění, zamítne a projekt přejde do ukončení.
45
Směřování projektu
Korporát/program
V případě změny bude žádost o schválení totožná, až na rozdíl, že projektový manažer bude žádat o schválení ze změny (položka seznamu změn na projektovém webu – entita Change). Konec
Korporátní nebo programový management
Zadání: - PM - Projektový výbor
Projektový mandát /Založení projektového webu Projektový výbor
Schválení nastavení
Vrátit
Schválení projektu
Schválit
Vrátit
Pro každou realizační etapu Schválení změny
Projektový manažer
Požádat o schválení
Zahájení projektu
Schválení ukončení
Schválení etapy
Zamítnout
Schválit
Vrátit Schválit
Řízení
Revize přínosů
Požádat
Nastavení projektu
Požádat o Vrátit schválení změny Požádat Etapa realizace
Požádat Ukončení projektu
[poslední realizační etapa] Zahájení projektu Povinné dokumenty: - Deník PM - Přehled získaných poznatků - Charta projektu - Osnova Obchodního případu - Popis produktu projektu - Plán etapy
Nastavení projektu Povinné dokumenty: - Strategie: - rizik, konfigurace, kvality, - komunikace - Reistry: - rizik, otevřených bodů, kvality - Plán projektu - Detailní obchodní případ - Záznam o Konfigurační položce - Plán revize přínosů - PID (Projektový inicializační dokuement)
Řízení přechodu Povinné dokumenty: - Plán etapy / Plán realizace výjimky - Popis produktu (následující etapy) - Zpráva o ukončení etapy - Zpráva o získaných poznatcích Aktualizace: - PID - Záznam o Konfigurační položce - Registry - Plán prjektu - Obchodní případ - Plán revize přínosů
Ukončení projektu Povinné dokumenty: - Doporučení následných akcí - Zpráva o získaných poznatcích - Zpráva o ukončení projektu Aktualizace: - PID - Plán projektu - Záznam o Konfigurační položce - Plán revize přínosů Uzavřít: - Registry - Deník PM - Přehled získaných posznatků
Obrázek 6-4: Stavový automat PRINCE2 procesu. Při přechodu mezi stavy bude systém kontrolovat existenci dokumentů na základě jejich dokumentových typů (entita Document type). Existenci dokumentů bude systém kontrolovat uvnitř odpovídající dokumentové složky stavu. Složky stavů budou vytvářeny automaticky pro každý stav. SharePoint nabízí dva způsoby implementace workflow pomocí nástroje Visual Studio. Je to sekvenční workflow a workflow stavového automatu. V této práci bude využit jednoduchý stavový automat, který bude implementován svépomocí, bez použití SharePoint workflow. Výhodou je jednodušší přizpůsobení stavů, přechodů, oprávnění a také proměnlivý počet stavů, které jsou u PRINCE2 zapotřebí. Částečnou nevýhodou jsou také úkoly, přes které je nutné SharePoint workflow ovládat, stavové workflow totiž reaguje na vnější události a tím je právě změna úkolu. Nelze tedy jednoduše spojit zadávání projektových metadat se schválením etapy. Stavového automatu bude využito pro implementaci schvalování dokumentů, změn i celého projektového procesu. 46
7
Realizace systému
K samotné realizaci navrženého systému byly využity poznatky a části kódu z projektů, kterých se účastním ve společnosti Icontio. V této společnosti pracuji jako SharePoint vývojář a starám se o několik projektů. Za poslední rok jsem s kolegy vytvořil malou knihovnu, která nám usnadňuje práci se systémem SharePoint. Tato knihovna je zde využita a jsou zde popsány některé její části. Počátkem navrženého projektového portálu byly na míru vytvářené portály pro verzi Microsoft SharePoint 2010 ve společnosti Icontio, kterých jsem se účastnil jako analytik a vývojář. Posléze ve firmě pod mým vedením vznikal produkt PMPortal (viz 2.3.2), který je stále v procesu vývoje, ale je již v přizpůsobené verzi používán u zákazníků. PMPortal je implementován pro SharePoint 2013 Foundation, proto i portál pro podporu PRINCE2 bude pod touto verzí SharePoint. S nápadem přizpůsobit projektový portál některé z existujících metodik přišlo vedení firmy a já jsem se tohoto nápadu ujal a na toto téma jsem se rozhodl, se svolením majitele firmy, napsat tuto diplomovou práci. Snahou této realizační fáze je použít co možná nejvíce z produktu PMPortal a v této kapitole popsat některé ze způsobu řešení, které jsou použity, a problémy, které jsou potřeba při vývoji řešit.
7.1
Microsoft SharePoint 2013
Výhodou využití platformy SharePoint je, že některé požadavky na funkcionalitu (z kapitoly 5.1.2) je možné splnit přímo využitím platformy Microsoft SharePoint. V průběhu učení se s touto platformou jsem se setkal s mnoha negativními názory na ni. S některými se nedá než nesouhlasit, ale pravdou je, že za vývojem celé platformy stojí zkušený vývojový tým po mnoho let. A představa, že podobnou funkcionalitu si vývojář naimplementuje sám a lépe, je podle mého názoru příliš ambiciózní. Obecnost celé platformy občas komplikuje navržené řešení a někdy je opravdu lepší navržené řešení implementovat mimo nabízené prostředky platformy SharePoint.
7.1.1
Způsob vývoje
Aby bylo možné programově ovlivnit standardní chování SharePoint, bylo potřeba využít Visual Studio. Pomocí něj a jednotlivých konfiguračních souborů (viz 4.5) je vytvořen balíček řešení (solution package) složený z vlastností (Feature) (viz 4.5.2 – balíček řešení). Dalšími elementy jsou sloupce (Field), typy obsahu (Content type), definice seznamů (List definition), instance listů (List instance), pohledy (View), šablona pro projektový web (Web template), ovládací prvky v ribbonu (Custom action). Do jisté míry by tato konfigurace webu šla „naklikat“ i s využitím nástroje SharePoint Designer. Problém jednak nastává s udržovatelností takového řešení a také s tím, že v tomto případě nelze využít programovacího jazyka ke složitější úpravě datové, aplikační a prezentační vrstvy. Pokud bychom chtěli systém rozdělit do klasické trojvrstvé architektury, tak by datovou vrstvu představovala zmíněná konfigurace sloupců, typů obsahu, seznamů a jejich vazeb. Do
47
aplikační vrstvy by se daly zařadit veškeré akce, které uživatel na portálu provádí a spouští. Prezentační vrstvu pak tvoří jednotlivé formuláře, nastavovací stránky, pohledy a jiné.
7.1.2
Datová vrstva
Struktura datové vrstvy implementovaného portálu kopíruje navrženou strukturu z kapitoly 6.2. Rozdílem oproti návrhu je například implementace stavů projektu, kdy seznam stavů musí být umístěn na hlavním webu i na projektovém webu. Dokud totiž není založený projektový web, musí existovat místo, odkud si projektový mandát (myšlenka) vyčte svůj stav. Po založení projektového webu je potřeba stavy projektu konfigurovat a vyčítat pro každý projekt zvlášť. Proto se seznam stavů při založení projektového webu kopíruje a každý projekt tak má svůj výčet stavů. Pro dynamické přepnutí mezi těmito dvěma listy stavů se stará třída ProjectList z aplikační vrstvy, kdy při vytvoření instance této třídy se do vnitřní kolekce načtou ty správné stavy. Projektová metadata jsou uložena na projektové položce (umístěna v projektovém listu na hlavním webu), ale jednotlivé seznamy, dokumenty, stavy jsou uloženy na projektovém webu. Nestandardními prostředky musela být implementována tato vazba mezi projektovou položkou a projektovým webem. Pro odkaz z položky na web byl využit standardní sloupec pro url, který je zobrazován uživateli. Zpětná vazba z webu na položku je implementována pomocí vnitřních metadat webu (SPPropertyBag), která jsou perzistentně uložena v databázi a uživatel k ním přístup nemá. V kódu pak lze nalézt metody, které z projektového webu získají projektovou položku a naopak. //získání projektového webu z projektové položky (z hlavního webu) ProjectList projectList = ProjectList.GetInstance(spWeb); SPWeb projectWebFromItem = projectList.GetRelatedProjectWeb(spItem); //získání projektové položky z projektového webu ProjectWeb projectWeb = new ProjectWeb(spWeb); SPListItem projectItemFromWeb = projectWeb.GetRelatedSPItem();
Ukázka 7-1: Získání projektové položky a projektového webu.
7.1.3
Aplikační vrstva
Mezi akce, které uživatel na portále může spouštět, patří například uložení uživatelských dat z formuláře, validace, nahrání dokumentu, nastavení upozornění a mnoho dalších. Tyto akce řeší SharePoint v základu a toto chování není příliš snadné ovlivnit. Standardně uživatel interaguje se systémem SharePoint pomocí vkládání nových záznamů, jejich editací, využívání předdefinovaných akcí v horním pásu karet (ribbon) a spouštěním workflow. Čím může vývojář reagovat na akce uživatele, je definováním vlastních workflow, vlastních „ribbon“ akcí, vytvořením vlastních stránek (jsme v prostředí ASP.NET) a událostí (event receiver), které lze navázat na změnu položky v seznamu. Event receiver Pokud chceme reagovat na údaje zadané uživatelem a chceme využít automatického generování formulářů, není možné k těmto údajům přistupovat přes c# v aspx stránkách. Je ale možné využít právě události, které jsou navázané na změnu položek, seznamů, webů. Události u položek jsou vyvolávány například při přidání nové položky, při aktualizaci, smazání položky, přidání přílohy a dalších. Event receiver je k většině událostí ve dvou provedeních. Ten, který 48
se provede před změnou (ItemAdding, ItemUpdating) a ten, který se provede po změně (ItemAdded, ItemUpdated). Ten první je vyvoláván před samotným zápisem změn dat do databáze, je spouštěn synchronně a akci je možné zastavit a uživateli zobrazit do formuláře zprávu. Může tak sloužit pro validaci údajů. Ten, který je spouštěn po provedení akce je z pravidla asynchronní (lze změnit). Výhodou událostí (Event receiver), oproti automaticky spouštěným workflow (při změně nebo založení položky), je to, že jsme schopni reagovat na více druhů spouštěcích akcí. Jsme schopni přistoupit k předchozím hodnotám, jsme schopni prováděnou akci zrušit. V systému nejsou použity standardní workflow procesy z Microsoft Workflow Foundation, ale pro reakci na uživatelské vstupy je využito právě systému událostí. Je jich využito například na validaci rozpočtu, detekci změny projektového manažera tak, aby mu mohla být přenastavena práva. Události jsou hlavně využity na spouštění stavového automatu, který řídí schvalovací procesy a navržený proces PIRNCE2. Proces je implementován ve třídě ProjectStates. Zde je například implementován přechod z projektového mandátu do projektového záměru, který založí projektový web. transation.ActionMethod = ProjectStates.CreateProject_MethodInvoke; public static void CreateProject_MethodInvoke(IQActionEventData e){…}
Ukázka 7-2: Použití přechodové akce stavu.
7.1.4
Prezentační vrstva
Vzhled oproti tomu standardnímu, který SharePoint nabízí, změněn nebyl. SharePoint nabízí pro základní formuláře (New form, Display form, Edit form, All items a další) své vlastní aspx stránky, které se při instalaci fyzicky zkopírují k jednotlivým listům. Dodatečně je možné upravit například pomocí nástroje SharePoint Designer. Pokud však chceme do stránek zasahovat i pomocí programovacího jazyka, je vhodné využít vlastní stránky, které umožňují využívat vlastní kód na pozadí (code-behind). Vlastních stránek je využito například pro zobrazení povinných dokumentů pro přechod do další fáze projektu nebo pro realizaci stavového automatu, kdy jsou uživateli nabízeny pouze ty fáze, do kterých může přejít. Ukázka je zobrazena na následujícím obrázku 7-1 ze schvalování dokumentu. Při přizpůsobování stránek na straně klienta byla využita také javascriptová knihovna SPServices [23], která nabízí metody pro práci s vygenerovanými SharePoint formulářovými poli. Těmito metodami může být například kaskádové výběrové pole (Cascade dropdown), kdy jedno výběrové pole je závislé na jiném. Dále je využita javascriptová knihovna jQuery. Častým příkazem je pak na portále získávání SharePoint polí a reakce na hodnoty, které uživatel zadal. Dalším rozšířením prezentační vrstvy na portále jsou webové části (webpart), které na schvalovacích stránkách zobrazují například stručné projektové informace . Další webová část (webpart) zobrazuje log akcí na projektovém formuláři. Obě ukázky jsou zobrazeny na následujícím obrázku 7-1.
49
Obrázek 7-1: Ukázka ze schvalování dokumentu, kde jsou využity webové části a nabízené možnosti přechodu pro schválení z implementovaného stavového automatu.
7.1.5
Oprávnění
Teoretické informace ohledně oprávnění jsou popsány v kapitole 4.4, kde je mimo jiné zmíněné, že úroveň oprávnění k SharePoint objektům je nutné nastavit konkrétnímu uživateli nebo skupině. Role pro oprávnění v rámci navrženého portálu mohou být brány z několika zdrojů. Tím nejjednodušším jsou statické skupiny uživatelů, které jsou vytvořeny na webu portálu. Jsou to například skupiny: Členové portálu, Správce portálu, Koordinátor portálu. Výhodou těchto skupin je to, že na ně lze přistoupit z kódu pouze se znalostí názvu skupiny. Úroveň oprávnění pak lze nastavit přímo této skupině. Stejně lze přistoupit k jednomu konkrétnímu uživateli. Například pokud máme specifický účet, který je využit pro přístup aplikace třetích stran, jsme staticky schopni ho v kódu používat. Nebo jsme schopni jej nastavit přímo na webu. Dalším zdrojem rolí jsou uživatelé zmínění v metadatech položky (datový typ SPFieldUser). Například u projektové položky je pole Projektový manažer, kterého vybírá Projektový výbor, a kterému tak uděluje určitá oprávnění pro vytvořený projektový web, seznamy a jejich položky. Další rolí, využitou v portálu, je seznam uživatelů na projektovém webu, kde jsou umístění členové týmu. Všichni tito členové musí mít nastavené specifické oprávnění, aby mohli s přiřazeným projektem pracovat.
50
Aby se jednotným způsobem přehledně dala nastavovat zmíněná trojice: objekt, role a oprávnění na jednom místě, je v kódu vytvořena struktura, která částečně kopíruje SharePoint strukturu zobrazenou na obrázek 4-3. Tato trojice je staticky nastavena pro jednotlivé objekty, kdy v době kompilace a inicializace kolekce, nejsou konkrétní uživatelé známi. Jedná se o abstraktní uživatele, kteří jsou z dat portálu dohledáváni až v době, kdy se mají jednotlivá oprávnění fyzicky aplikovat. Popsané vztahy jsou zobrazeny na následujícím diagramu 7-2. +ListPermissions RoleAssigement
+
List
0..* GetSPRoleAssigements() : SPRoleAssigements +ItemPermissions
+ +
0..*
SetItemsPermissions(SPWeb, SPListItem) : void SetListPermissions(SPWeb, SPListItem) : void
1
1 Role +
Member
GetSPRoleDefinition(SPWeb) : SPRoleDefinition
+
GetSPMembers(SPWeb, SPListItem) : SPMembers
MemberCustom +
MemberField
GetSPMembers(SPWeb, SPListItem) : SPMembers
+
GetSPMembers(SPWeb, SPListItem) : SPMembers
«delegate» - GetSPMembersDelegate(SPWeb, SPListItem) : SPMembers
1 Field
Obrázek 7-2: Diagram tříd oprávnění. V následné ukázce 7-3 je zobrazena částečná implementace jednotlivých rolí, které jsou využity k nastavení oprávnění pro seznamy, položky nebo weby v další ukázce 7-4. //Výčet rolí/uživatelů používaných na portále class Members { //SharePoint skupiny z webu portálu Member GrAdministratorPMP = new Member("PMP Administrator"); Member GrCoordinatorPMP = new Member("PMP Coordinator"); //Uživatel(é)/Skupina z pole Project Manager umístěného v projektové položce MemberField ProjectManager = new MemberField(ProjectFields.ProjectManager); //Uživatelé uloženi v seznamu členů týmu na projektovém webu. Uživatelé jsou získávány delegátem GetProjectTeamAll MemberCustom ProjectTeamAll = new MemberCustom("ProjectTeamAll", new MemberCustom.GetIQSPMembersDelegate(GetProjectTeamAll)); ... }
Ukázka 7-3: Třída rolí.
51
//Konstruktor projektového listu private ProjectList(PMWeb pmWeb, string listName, string listUrl) : base(pmWeb, listName, listUrl) { //práva pro jednotlivé projektové položky this.ItemPermissions.Add(new PMRoleAssignment(Members.GrAdministratorPMP, PMRole.Contributor)); this.ItemPermissions.Add(new PMRoleAssignment(Members.GrCoordinatorPMP, PMRole.ContributorNoDelete)); this.ItemPermissions.Add(new PMRoleAssignment(Members.ProjectManager, PMRole.ContributorNoDelete)); this.ItemPermissions.Add(new PMRoleAssignment(Members.ProjectTeamAll, PMRole.Reader)); ... }
Ukázka 7-4: Konstruktor projektového listu.
7.2
Konfigurace a nasazení
Pro samotné nasazení portálu je nutné mít připravený SharePoint Foundation nebo Server 2013. Jak nainstalovat SharePoint je možné dohledat na stránkách podpory. V nainstalovaném serveru je třeba založit webovou aplikaci (Web application) a na ni vytvořit novou kolekci webů (Site collection). Do vytvořené kolekce webů lze skriptem například inicializovat skupiny, jejich uživatele a nastavit jazykové mutace. Následující zjednodušený powershell skript ukazuje postup nasazení balíčku řešení (wsp solution package) vytvořený pomocí nástroje Visual Studio. Skript v prvním kroku nahraje wsp balíček na SharePoint, v dalším kroku provede jeho nasazení (deploy) na konkrétní webovou aplikaci. Nakonec skript aktivuje vlastnosti (Feature) na kolekci webů, tím se spustí inicializace sloupců, seznamů a jiných. $SCName = "http://serverName/" $webAppName = "Sharepoint - 80" $wspPath = "D:\PRINCE2\WSP\" $wspName = "PRINCE2.wsp" Add-SPSolution $wspPath + $wspName Install-SPSolution –Identity $wspName -GacDeployment -WebApplication $webAppName #wait for solution deploy Enable-SPFeature -identity PRINCE2_Feature_1_Init -Url $SCName Enable-SPFeature -identity PRINCE2_Feature_2_MainSite -Url $SCName Enable-SPFeature -identity PRINCE2_Feature_ProjectTemplateDef -Url $SCName
Ukázka 7-5: Nahrání balíčku řešení na SharePoint.
52
8
Závěr
Projektové řízení je důležitou součástí jakékoliv organizace, která se zabývá řešením projektů. V textu práce je důležitost využití správných postupů několikrát zmíněna a odůvodněna. Firmy si tuto důležitost uvědomují, ale podle informací, které jsem nabyl v průběhu své praxe, tyto doporučené postupy neaplikují, nemají potřebný personál pro vedení, ani potřebné vybavení v podobě nástroje, který by projektové řízení podpořil a vedl. Po prostudování teorie projektového řízení a po debatě s odporníky z praxe si myslím, že sebelepší nástroj nestačí, a v případě, že není ze strany vedení společnosti a samotných zaměstnanců vůle, jakékoliv pokusy o řízení projektů mohou skončit chaosem zmíněným v úvodní kapitole. V průběhu mé praxe ve firmě Icontio, konkrétně při vývoji software na zakázku pro podporu firemních procesů u zákazníků, jsem však narazil na vedoucí pracovníky, kteří toto odhodlání a vůli měli. Pro něž má podpůrný systém smysl a cítí zodpovědnost za jeho smysluplné užívání. Výhodou těchto zákazníků je poměrně jasná představa, jak své procesy správně řídit. Pro tyto zákazníky má smysl vytvářet systém přizpůsobený přímo jejich potřebám. Mezi výše popsanými případy existuje skupina uživatelů, kteří nemají jasnou představu o řízení, a kteří nechtějí investovat do drahých, na míru přizpůsobených systémů, ale přesto chtějí své projekty správně řídit. Pro tyto uživatele je vhodné aplikovat doporučené a osvědčené postupy z praxe. Osvědčené postupy z praxe přináší projektové metodiky popsané v kapitolách 2.2 a 3. Některé z nich se zabývají konkrétními postupy a akcemi, jiné zase schopnostmi vedoucích pracovníků nebo jinými doporučeními. Cílem práce nebylo zhodnotit, která metodika je lepší, nebo horší, ale stručně popsat jejich vlastnosti a detailněji představit metodiku PRINCE2. Uvědomělý uživatel z třetího případu, ten který by chtěl řídit, ale neví jak, potřebuje nejlépe zkušeného projektového manažera se systémem pro projektové řízení, kterých je celá řada a některé z nich jsou popsány v kapitole 2.3. Až na jeden popsaný systém (Primavera) se produkty ve svých prezentacích nechlubí podporou některé z uznávaných metodik. Smyslem práce je tedy propojit uznávanou metodiku PRINCE2 a nástroj, který dokáže spravovat projektové informace, tím podpořit projektové řízení a spojením tak nabídnout postup i nástroj, „kuchařku i nádobí“. Toto propojení je v práci zanalyzováno, navrženo a realizováno s ohledem na platformu MS SharePoint, která slouží jako podklad pro realizovaný portál.
8.1
Možnosti dalšího vývoje
Samotná metodika je poměrně rozsáhla a zahrnuje spoustu propojených aktivit a informací, které je potřeba v průběhu celého projektu řešit. Navrhnutý a realizovaný portál všechny tyto aktivity a informace nedokáže postihnout, ani si to neklade za cíl. Ty aktivity, které nepostihuje, musejí být řešeny znalostí projektového manažera. Jedná se zejména o kontrolní aktivity a ty, kterými je sestavována dokumentace. Systém tedy nedokáže uživatele provést celou metodikou v každém jejím kroku, neimplementuje podrobné procesy popsané v kapitole 3.4. Důležité však 53
je, že uživatelé mají pomocí portálu k dispozici potřebné šablony dokumentů, které sami o sobě určují témata, kterým je třeba se věnovat. Tím část funkčnosti nástroje přebírají tyto šablony. Další vývoj může mít dva směry. Jedním z nich je detailnější implementace PRINCE2 procesů tak, aby bylo možné zmenšit nároky na znalosti této metodiky u manažerů. To znamená, že systém dokáže vedoucí pracovníky lépe a intuitivně provést životním cyklem projektu. Druhým směrem může být větší integrace dokumentových šablon přímo do systému tak, aby data byla uložena přímo v seznamech, a ne v dokumentech. Tím by bylo možné záznamy lépe kontrolovat, automaticky analyzovat, automaticky na ně upozorňovat, schvalovat a využívat je v reportovacích přehledech.
8.2
Přínos a poznatky
Přínosy této práce a mé stáže ve firmě Icontio se těžko rozdělují a částečně se prolínají. Velkým přínosem pro mě byla práce se systémem MS SharePoint, do jehož tajů jsem podle mého názoru pronikl poměrně důkladně. Neocenitelným přínosem pro mě je i poznání metodiky PRINCE2, se kterou jsem se nejprve seznámil pomocí samostudia, poté pomocí úvodního semináře od odborníka z praxe a následně díky návrhu vytvářeného systému, který tuto metodiku obsahuje a podporuje. Logickým a pochopitelným poznatkem pro mě je to, že projektové řízení je z velké části o osobnosti projektového manažera. A pokud skloubíme schopného vedoucího pracovníka se znalostí správných postupů a s nástrojem, který mu usnadní práci, pak jsme již na půl cesty k úspěšnému řízení projektů.
54
Literatura [1] OGC (Office of Government Commerce). Managing Successful Projects with PRINCE2. London : TSO (The Stationery Office), 2009. ISBN 978-0-11-331059-3. [2] PMI. A Guide to the Project Management Body of Knowledge: PMBOK. 3. Pennsylvania : Project Management Institute, 2004. ISBN: 978-1935589679. [3] Doležal, Jan, a další. Projektový management podle IPMA. 1. vyd. Praha : Grada publishing, a.s., 2009. str. 512. ISBN 978-80-247-2848-3. [4] Pavlíček, Luboš. Objektová analýza, návrh a programování. [Online] 13. 9 2005. [Citace: 11. 5 2014.] . [5] Atlassian. JIRA. Atlassian. [Online] .
Atlassian.
[Citace:
12.
5
2014.]
[6] Icontio. PMPortal přehledné řízení projektů. PMPortal. [Online] Icontio, 2014. [Citace: 12. 5 2014.] . [7] Oracle. Primavera Enterprise Project Portfolio Management. Oracle. [Online] Oracle. [Citace: 13. 5 2014.] . [8] IT park. Task Manager. [Online] IT park, s.r.o. [Citace: 13. 5 2014.] . [9] Easy Software. Český software pro řízení projektů a firmy. Easy Project. [Online] Easy Software s.r.o. [Citace: 13. 5 2014.] . [10] Unicorn. Unicorn Universe. .
[Online]
Unicorn a.s.
[Citace:
13. 5 2014.]
[11] IBM. IBM Notes and Domino family. [Online] IBM. [Citace: 13. 5 2014.] . [12] Projectman. Software pro PM. Projectman. [Online] Projectman.cz, s.r.o. [Citace: 13. 5 2014.] . [13] Sargeant, Richard, a další. PRINCE2 RESOURCES. PRINCE2. [Online] AXELOS, 20. 4 2014. [Citace: 21. 4 2014.] . [14] Boucher, Collis a Klusoň, Martin. PRINCE2:2009 Glossary of Terms – Czech. PRINCE2. [Online] 17. 5 2012. [Citace: 21. 4 2014.] <www.princeofficialsite.com/nmsruntime/saveasdialog.aspx?lID=1895, http://www.prince2.cz/cz/download/1404041641/?at=1>. [15] Bates, Seth a Smith, Tony. SharePoint 2010 User’s Guide: Learning Microsoft’s Business Collaboration Platform. Berkeley, Calif. : Apress, 2010. ISBN 978-1-43022763-2. [16] Microsoft. Co je nového v Microsoft SharePoint Serveru 2013. Office. [Online] Microsoft. [Citace: 15. 3 2014.] http://office.microsoft.com/cs-cz/sharepoint-help/co-jenoveho-v-microsoft-sharepoint-serveru-2013-HA102785546.aspx. 55
[17] Perez, Juan Carlos. Microsoft's Office 365 uptime exceeds 99.9%. Computerworld. [Online] Computerworld, 8. 8 2013. [Citace: 22. 3 2014.] . [18] Enrique, Vargas. High Availability Fundamentals. [Pdf dokument] Kalifarnie : Sun BluePrint OnLine, Sun Microsystems, Inc, 2000. Sv. 806-6857-10. [19] Microsoft. User permissions and permission levels (SharePoint Server 2010). SharePoint Technet. [Online] Microsoft, 12. 3 2010. [Citace: 29. 3 2014.] . [20] —. Application Lifecycle Management in SharePoint 2010. Office Dev Center. [Online] Microsoft, 1. 8 2011. [Citace: 4. 4 2014.] . [21] Eric, Carter, Boris, Scholl a Peter, Jausovec. SharePoint 2010 Development with Visual Studio 2010. Michigan : Addison-Wesley, 2010. ISBN 0-321-71831-3. [22] Malik, Sahil. Microsoft SharePoint 2010: Building Solutions for SharePoint 2010. New York : Apress, 2010. ISBN 978-1-4302-2865-3. [23] SPServices kol. SPServices. CodePlex. .
[Online]
[Citace:
14.
5
2014.]
56
Seznam použitých zkratek OGC PRINCE2 IPMA ICB PMI PMBoK WMS DMS ASP ASPX WSP CAML
Office of Government Commerce PRojects IN Controlled Environment, version 2 International Project Management Association IPMA Competence Baseline Project Management Institute Project Management Body of Knowledge Workflow Management System Document Management System Active Server Page Active Server Page Extended File SharePoint Solution Package Collaborative Application Markup Language
57
Seznam příloh Elektronicky: Zdrojové kódy Návod k instalaci Uživatelská příručka
58
