Sablona prispevky MSI

Podobné dokumenty
Sablona prispevky MSI

msipapersource54-fabik

Microsoft Word - Hitka - esej2011_06-is-xhitka.doc

Snímka 1

NSK Karta PDF

msipapersource34-gablovsky

Sablona prispevky MSI

Sablona prispevky MSI

Microsoft Word - msipaper63-lamos.doc

Style Sample for C&N Word Style Sheet

Microsoft Word - Bartalos.doc

Sablona prispevky MSI

Sablona prispevky MSI

Microsoft Word - Lajcin - esej2011_07-si-xlajcin.doc

Snímek 1

Manažment v Tvorbe Softvéru 2018/2019

Snímka 1

PM pre Automotive a vyrobu-1

NSK Karta PDF

Microsoft Word - msipaper44-hlavacek.doc

Rozdeľovanie IT zákaziek UX Peter Kulich

Microsoft Word - RolyRiadeniaZmien_V1.doc

ISO Systémy manažérstva proti korupcii Svetový deň normalizácie 2018 Miroslav HRNČIAR Žilinská univerzita v Žiline

WP summary

Microsoft Word - msipaper57-petrakova.doc

Sablona prispevky MSI

Prezentácia programu PowerPoint

Microsoft Word - Jaroszewicz - esej2011_08_15_xjaroszewicz.docx

Microsoft Word - Ivanec - esej2011_16-si-xivanec.doc

Microsoft Word - Manažment_tagov_tim24_tema12_2017.docx

Microsoft Word - Kocian - esej2011_13-is-xkocianr.doc

Snímka 1

Oplatí sa riskovať?

Microsoft Word - Pavlech - esej2011_02-is-xpavlechl.doc

C(2014)5449/F1 - SK

Prezentácia programu PowerPoint

KRITÉRIÁ PRE VÝBER PROJEKTOV - POSUDZOVACIE KRITÉRIÁ pre posúdenie projektových zámerov v rámci Integrovaného regionálneho operačného programu priorit

msipapersource02-gregor

Microsoft Word - Vacula - esej2011_04-si-xvacula.doc

Moderne projekty v biznis suvislostiach-1

Centrum pre hospodárske otázky Komentár 1/2018: Schválená investičná pomoc v roku 2017 Martin Darmo, Boris Škoda 1 V roku 2017 vláda Slovenskej republ

Microsoft Word - 08_Vacho.doc

13 ISF

Sablona prispevky MSI

Informatívna hodnotiaca správa o priebežnom plnení Komunitného plánu sociálnych služieb mesta Trnavy na roky za rok 2018 Komunitný plán soci

Príloha č. 2 Vyzvania pre finančné nástroje OP KŽP OPKZP-PO4-SC411/421/ FN Zoznam povinných merateľných ukazovateľov Operačný program Prioritn

Intellectual Property, Psychology and Sociology

Príloha k príkazu generálneho riaditeľa Sociálnej poisťovne č. 2/2018 Popis a zodpovednosti rolí v rámci projektového riadenia (1) Riadiaci výbor proj

?SPEÐNOS? PROJEKTOV SYSTÉMOVEJ INTEGR?CIE

PowerPoint Presentation

#project #process #change PRACUJTE FLEXIBILNE A INOVATÍVNE! AGILE MANAGEMENT

Prezentácia programu PowerPoint

Predškolská výchova vo svete 2

Nová éra Microsoft Dynamics 365 v IT spoločnosti GAMO Vďaka dodanému riešeniu sme pomohli zlepšiť fungovanie kľúčových oblastí

Obecné zastupiteľstvo v

Cielená príprava žiakov s ťažkým zrakovým postihnutím na ďalšie štúdium

Akreditovaný polročný kurz Riadenie a rozvoj ľudských zdrojov

TA

Šablona dokumentu

SK01-KA O1 Analýza potrieb Zhrnutie BCIME tím Vyhlásenie: "Podpora Európskej komisie pre výrobu tejto publikácie nepredstavuje súhlas

Mnz_osobnost_profil_manazer_(2)_2019

Vnútorný predpis Číslo: 2/ Výzva na predkladanie žiadostí o Inštitucionálne projekty MTF STU Vypracovala: doc. Ing. Kristína Gerulová

NSK Karta PDF

NSK Karta PDF

NSK Karta PDF

(24 Peter Malega RIADENIE PROJEKTU – STRATEGICKA CESTA)

Microsoft Word - a13_45.SK.doc

Milé študentky, milí študenti, v prvom rade Vám ďakujeme za vyplnenie ankety. Táto anketa bola zameraná na zistenie Vášho postoja ku kvalite materiáln

Sablona prispevky MSI

PM C-03 Prostredie riadenia ¾udských zdrojov

Microsoft Word - Usmernenie c 6_2010_vyplnanie tab 11_MS

Vyhodnotenie študentských ankét 2013

Kurz-Riadenie-rizik-prakticky Prihlaska

Prieskum PAS a INEKO o návrhu Ministerstva financií SR na prelomenie bankového tajomstva 10. septembra 2018 Podnikatelia odmietajú návrh na prelomenie

Snímka 1

Microsoft Word - Fabik - esej2011_18-is-xfabik.doc

SLOVENSKÁ TECHNICKÁ UNIVERZITA V BRATISLAVE FAKULTA INFORMATIKY A INFORMAČNÝCH TECHNOLÓGIÍ Metodika archivácie verzií HW Tímový projekt Stratos FIIT M

EURÓPSKA KOMISIA V Bruseli C(2018) 6560 final ANNEX 1 PRÍLOHA k vyoknávaciemu rozhodnutiu Komisie, ktorým sa stanovuje metodika monitorov

Čo bude ďalší krok pre rozvoj ekonomiky SR, alebo Premrhaný(?) potenciál štátneho IT

Microsoft Word - pe453195_sk.doc

ĽAHKO. BEZ NÁMAHY. BEZ ÚNAVY. Naša patentovaná vysokotlaková pištoľ EASY!Force citeľne odľahčí vaše kĺby a svaly. PROFESSIONAL VYSOKOTLAKOVÉ ČISTIČE

Description of the certification procedure (ISO 9001, ISO 14001, ISO/TS 29001, OHSAS 18001, ISO 50001)

Doplňujúce údaje k vyzvaniu č. OPII-2018/7/5-NP Zoznam iných údajov Zoznam iných údajov UPOZORNENIE: Iné údaje poskytuje prijímateľ výlučne počas impl

Koncepcia a trendy rozvoja obnoviteľných zdrojov energie na báze biomasy v Prešovskom a Košickom kraji

Slovenská technická univerzita v Bratislave Fakulta informatiky a informačných technológií Zápisnica zo stretnutia #4 Tím sixpack Bc. Jozef Blažíček B

Slovenská technická univerzita v Bratislave Fakulta informatiky a informačných technológií Tres Faciunt Collegium Posudok Študijný program: Počítačové

Snímka 1

Snímka 1

4. Aktivity Klubu pacientov SMyS [režim kompatibility]

Platný od: OPIS ŠTUDIJNÉHO ODBORU EKONOMIKA A RIADENIE PODNIKOV

Prezentácia programu PowerPoint

Snímka 1

Microsoft Word - Krajcovic - Esej2011_10-si-xkrajcovic.doc

NSK Karta PDF

UNIVERZITA PAVLA JOZEFA ŠAFÁRIKA V KOŠICIACH VZDELÁVACÍ PROGRAM Moderná didaktická technika v práci učiteľa Aktualizačné vzdelávanie prof. MUDr. Ladis

Název prezentace může být na dva řádky (písmo Calibri, vel. 40, tučné)

Microsoft PowerPoint - 1_eSO1

msipapersource61-petras

Kreatívny priestor a jeho úloha v akademických knižniciach (s príkladom zo Slovenska)

Prepis:

Kategorizácia a riadenie rizík v softvérovom projekte šesťčlenného tímu JOZEF GREXA Slovenská technická univerzita Fakulta informatiky a informačných technológií Ilkovičova 3, 842 16 Bratislava xgrexa[zavináč]is[.]stuba[.]sk Abstrakt. Oblasť manažmentu rizík sa stáva stále dôležitejšou súčasťou vývoja softvérového projektu. Veľa softvérových projektov je neúspešných práve kvôli nedostatočnému zohľadneniu možných rizík a ich dôsledkov. Avšak aj na pôde manažmentu rizík je už dosiahnutých veľa zásadných výsledkov. V mojej práci som sa venoval pohľadu na rôzne riziká v kontexte konkrétneho tímového softvérového projektu, ktorý už pri jeho začiatkoch ponúka možnosť odhadnúť rôzne rizikové oblasti a ich dôsledky. Zameral som sa na kategorizáciu rizík, pričom každá kategória predstavuje množinu rizík spolu súvisiacich, ich možné riadenie a taktiež konkrétne pridelenie úloh príslušnému členovi tímu. Práca je všeobecným podkladom pre manažment rizík v tímovom softvérovom projekte šesťčlenného tímu. Úvod Každá snaha, aktivita či samotná práca so sebou prináša určitú úroveň nejasností ohľadne toho, ako sa bude postupne vyvíjať resp. aké výsledky prinesie. Podobne je to aj pri vývoji softvérového systému. S každým ďalším krokom vývoja, s každým novým návrhom a podnetom súvisia riziká, ktoré tieto kroky sprevádzajú. Samozrejme, všeobecnou snahou, je možné riziká eliminovať resp. čo najviac obmedziť. Avšak úplné vyradenie všetkých možných rizík je takmer nemožné. Preto je nutné pozrieť sa na rizikové oblasti z druhej strany, to znamená, snažiť sa ich odhadnúť a predvídať a následne ich čo najefektívnejšie riadiť. Podľa môjho názoru je oveľa lepšie mať v projekte viac rizík, nad ktorými máme kontrolu, ako menej takých rizík, o ktorých nevieme. V kontexte tímového projektu nadobúda oblasť rizík ďalšie rozmery spojené s manažmentom tímu a komunikáciou v tíme. Väčšina softvérových projektov sa vyvíja v podmienkach, ktoré nie sú vždy úplne predvídateľné a v ktorých existuje veľa faktorov, ktoré môžu ovplyvniť výsledný produkt. Podľa článku autorov Powel a Klein [6] sa projekt považuje za úspešný vtedy, ak spĺňa požiadavky (funkcionalitu, Manažment projektov softvérových a informačných systémov, október 2008, s. 1-8.

2 Jozef Grexa spoľahlivosť, udržateľnosť, rozšíriteľnosť, efektívnosť, schopnosť začleniť sa do väčšieho projektu a schopnosť prevádzkovať systém v daných podmienkach), je splnený v danom termíne a v rámci stanoveného rozpočtu. Výskum, ktorý opisuje May [4], ukazuje, že len jedna šestina všetkých projektov bola ukončená načas a v rámci daného rozpočtu, jedna tretina projektov bola zrušená a viac ako polovica priniesla len obmedzené výsledky. V štúdií autorov Keil a kol. [3] sa ukázalo, že hlavnú úlohu vo vysokej neúspešnosti projektov zohrávajú projektoví manažéri, ktorí v prvých fázach projektu nedostatočne zohľadňujú možné riziká vyplývajúce z projektu. Potvrdzuje to tiež štatistika, ktorá ukazuje, že asi tretina projektov sa ukončí s neúspechom až vo fáze implementácie. Preto je dnes jasné, že manažment rizík musí byť samozrejmou súčasťou práce v tímovom projekte. Riziká a ich kategorizácia Existuje veľa rôznych modelov a štúdií, ktoré sa venujú definovaniu rizík a ich zaradeniu do určitých skupín. Je veľmi ťažké nájsť medzi týmito skupinami všeobecne platnú normu, pretože sú závislé od charakteru a zamerania jednotlivých projektov. Avšak napriek tomu je mojou snahou použiť už existujúce modely a vytvoriť pohľad na riziká vývoja softvérového systému v kontexte konkrétneho šesťčlenného tímu pracujúceho na softvérovom projekte. V mojom štúdiu problémovej oblasti som prišiel k záveru, že najdôležitejšou úlohou je nájsť vhodné kategórie, do ktorých by sme mohli existujúce riziká zaradiť. Tieto kategórie vytvorím s ohľadom na zloženie šesťčlenného tímu pracujúceho na softvérovom projekte. Podľa môjho názoru je manažment rizík oblasť, ktorú musia pri svojej práci zohľadniť všetci členovia tímu. V každej časti vývoja a tiež na každej pozícií v tíme sa vyskytujú riziká, ktoré môže najlepšie odhadnúť, posúdiť a riadiť ten člen tímu, ktorý je manažérom danej časti. Ak manažér kvality pri úvodných analýzach zistí, že niektoré funkcie systému nespĺňajú požiadavky koncového používateľa, je to práve on, ktorý môže najlepšie odhadnúť riziko z toho plynúce. Podobne je to napríklad aj s úlohou manažéra plánovania, ktorý môže zistiť, že daný čiastkový výsledok, nie je možné pri danom pracovnom tempe dosiahnuť včas. Následne môže práve manažér plánovania najlepšie odhadnúť riziká, ktoré to prináša do ďalších krokov vývoja a tiež určiť, ako daným rizikám predísť resp. ako ich efektívne riadiť. Samozrejme, popri tom zohráva veľmi dôležitú úlohu samotný manažér rizík, ktorý musí s nadhľadom riadiť riziká, ktoré sa v jednotlivých častiach práce v tíme vyskytujú. Manažér rizík zhodnotí mieru ohrozenia jednotlivých častí projektu a s ohľadom na celý projekt zabezpečí efektívne prideľovanie úloh súvisiacich s riadením rizík jednotlivým členom tímu. V šesťčlennom tíme sa môžu jednotliví členovia nachádzať na rôznych pracovných pozíciách. Tieto pozície a činnosti, ktoré z nich plynú, úzko súvisia s charakterom projektu, na ktorom tím pracuje. Preto je mojou snahou vytvoriť kategórie, ktoré nájdu čo najširšie využitie v rôznych softvérových projektoch šesťčlenných tímov. Hlavná myšlienka kategorizácie, ako som už naznačil vyššie,

Kategorizácia a riadenie rizík v softvérovom projekte šesťčlenného tímu 3 spočíva v tom, že všetci členovia tímu sa podieľajú na identifikácií a riadení rizík vo svojej oblasti a sfére vplyvu na projekt, avšak najväčšiu zodpovednosť má manažér rizík, ktorý musí všetky zistené riziká efektívne riadiť a snažiť sa hľadať čo najlepšie východiská s ohľadom na celý projekt. V mojom štúdiu v oblasti manažmentu rizík som dospel k definovaniu nasledujúcich šiestich kategórií 1. Komunikácia so zákazníkom 2. Organizácia tímu 3. Technická podpora 4. Personálne zabezpečenie 5. Plánovanie 6. Globálny manažment rizík Som presvedčený, že tieto kategórie vytvárajú pre šesťčlenný tím možnosť zahrnúť čo najširšie spektrum rôznych rizík, ktoré môžu projekt ohrozovať. V najbližších odsekoch sa chcem venovať každej kategórií osobitne, pričom pre každú určím aj konkrétne riziká, ktoré sa tu môžu vyskytnúť. Komunikácia so zákazníkom Podľa štúdie, ktorú uskutočnili Addison a Vallabh [2], je komunikácia medzi zmluvnými stranami jedným z najväčších zdrojov rizík. Problémom často býva fakt, že medzi členmi tímu, ktorý realizujú projekt a koncovým používateľom, ktorý definuje požiadavky stojí viacero ľudí. Títo ovplyvňujú projekt spôsobom, ktorý vyplýva z ich postavenia a pozície a potom sa môže stať, že majú rozdielne názory a pohľady na konkrétne časti projektu. Myslím si, že v súvislosti s týmto problémom sa vynára často aj problém nepochopenia požiadaviek zákazníka a tým aj nesplnenie jeho očakávaní. Za kľúčové, pokladám v oblasti komunikácie so zákazníkom nasledovné problémy: nejasný alebo nepochopený rozsah alebo cieľ projektu nedostatočné zapojenie používateľa nepochopenie požiadaviek zo strany projektových manažérov neustále zmeny požiadaviek zo strany zákazníka nenaplnenie očakávaní koncového používateľa Organizácia tímu Podľa článku Abdel-Hamid a kol. [1] je rozvrhnutie a načasovanie činností najkomplikovanejším faktorom v tímovom projekte. Je totiž veľmi ťažké v začiatkoch práce na projekte s potrebnou presnosťou odhadnúť časové a finančné nároky na projekt. Veľmi často dochádza k podceneniu projektu. Podľa mňa je z opačného pohľadu práve organizácia tímu najsilnejšou zbraňou v snahe predchádzať rizikám. Ako je naznačené v článku, ktorý napísali autori Ropponen a Lyytinen [7], pre

4 Jozef Grexa zlepšovanie organizácie v tíme sú potrebné hlavne bohaté skúsenosti v danej oblasti. Podľa mňa je tiež dôležité dôsledne zapojiť do projektu všetkých členov tímu a tiež vyššie postavených ľudí, ktorí daný projekt ovplyvňujú. V oblasti organizácie tímu pokladám za kľúčové nasledujúce problémy: nereálny plán alebo rozpočet nedostatočné zapojenie vyššieho manažmentu neadekvátne zapojenie členov tímu Technická podpora Do oblasti technickej podpory spadajú v mojej kategorizácií hlavne riziká, vyplývajúce z nedostatočnej metodológie a prípravy v projekte, z nedostatočného využívania rôznych zdrojov alebo z použitia nesprávnych nástrojov alebo ľudí na nesprávnych miestach. Technická podpora zahŕňa hlavne fázu analýzy a návrhu až po implementáciu softvérového systému. V týchto fázach je dôležité zamerať sa na podstatné funkcie systému a riešiť ich s použitím vhodných vývojových a podporných prostriedkov. Je tiež dôležité správne rozdeliť činnosti medzi členov tímu podľa ich vzdelania a skúseností v danej oblasti. Tu sa technická oblasť mierne stretáva s oblasťou personálneho zabezpečenia. K tomuto faktu sa v ďalších odsekoch ešte vrátim. Podstatné problémy v technickej oblasti, z ktorých vyplývajú hlavné riziká sú: nedostatočná metodológia v projekte vývoj nepotrebných a zlých softvérových funkcií nedostatočné využívanie zdrojov a zabezpečenie maximálneho výkonu tímu zavedenie novej technológie použitie nesprávnych nástrojov nedostatočné zohľadnenie analýzy a návrhu softvéru vo fáze implementácie Personálne zabezpečenie Oblasť personálneho manažmentu tvorí úplne samostatnú no neoddeliteľnú súčasť tímového projektu. Podľa mňa sú však riziká, ktoré z tejto oblasti plynú veľmi závažné. Hlavné problémy spočívajú v nedostatočnej komunikácií medzi jednotlivými členmi tímu, v rôznorodosti osobností členov tímu a tiež v atmosfére, ktorá v tíme vládne. Myslím si, že je dôležité, hlavne v začínajúcich tímoch, vytvoriť priateľskú atmosféru. Často býva problémom nedostatočné zhodnotenie osobností jednotlivých členov, ktoré potom vedie do neadekvátneho rozdelenia zodpovedností v tíme. Myslím si, že je potrebné priložiť rozdeleniu hlavných úloh a pozícií v tíme patričnú pozornosť. Tiež je dôležité priebežne sledovať prácu jednotlivých členov v tíme tak, aby si boli členovia tímu navzájom akýmisi kontrolórmi. Dôležitá je tiež snaha predísť neštandardnému postupu pri práci jedného z členov v tíme, čím by mohli byť v danej

Kategorizácia a riadenie rizík v softvérovom projekte šesťčlenného tímu 5 oblasti ostatní členovia postavení mimo obraz. Hlavné problémové aspekty v oblasti personálneho zabezpečenia sú podľa môjho názoru: neadekvátne zručnosti/vedomosti jednotlivých členov na daných pozíciách nevyvážené rozdelenie zodpovedností v tíme neefektívne a neprimerané využívanie ľudských zdrojov neštandardné postupy pri práci jednotlivých členov tímu Plánovanie Plánovanie je v porovnaní so skôr uvedenými kategóriami niečím odlišné. Nie je tak jasne definovanou oblasťou ako ostatné, kde sa dajú jasne určiť aspoň základné riziká. Samozrejme, že v súvislosti so samotným plánovaním sa vynárajú problémy ako nedostatočná tvorba plánov, nedostatočné zohľadnenie vplyvov prostredia na budúcu prácu alebo nedôsledné plánovanie činností v jednotlivých fázach a oblastiach softvérového projektu. Avšak okrem týchto problémov má oblasť plánovania z pohľadu manažmentu rizík jednu veľmi dôležitú úlohu. Je to odhad rizík, ktoré súvisia s prichádzajúcimi plánovanými činnosťami. Je samozrejmé, že odhadovať možné riziká je nevyhnutné v každej časti projektu osobitne, avšak práve v oblasti plánovania prichádza do úvahy globálny pohľad na budúce činnosti a budúci vývoj, ktorý umožňuje celkový odhad rizík, prípadne ich vzájomný vplyv. Podľa štúdie Phan a kol. [5], väčšina projektov zlyháva hlavne po manažérskej stránke a nie po technickej. Z toho usudzujem, že je manažment plánovania a organizácie veľmi dôležitý a tým pádom je dôležitý aj odhad a riadenie rizík, ktoré táto oblasť prináša. Globálny manažment rizík Manažment rizík, ako som už spomínal a verím, že je to z posledných odsekov zrejmé, je zásadnou súčasťou manažmentu celého tímu. Preto si myslím, že je dôležité, aby bola v tíme vytvorená a obsadená pozícia manažéra rizík. Nie je nevyhnutné, aby daný člen tímu zastával výlučne túto funkciu. Je však dôležité, aby jej venoval dostatočný záujem. V mojom ponímaní predstavuje globálny manažment rizík monitorovanie čiastkových rizík v jednotlivých vyššie uvedených kategóriách, zhodnotenie ich vzájomného vplyvu a vplyvu na projekt a tiež ich riadenie, to znamená určenie a rozdeľovanie činností potrebných na obmedzenie týchto rizík. Úlohou manažéra rizík je hlavne získavať informácie o rizikách z uvedených kategórií od jednotlivých členov tímu. Na riadenie rizík môžu byť použité rôzne metódy v závislosti od charakteru a smerovania projektu. Je tiež úlohou manažéra rizík vybrať vhodné metódy na riadenie resp. obmedzenie rizík na minimálnu úroveň. Manažér rizík musí mať prehľad o aktuálne vykonávaných činnostiach v tíme. Je možné, že nastane situácia, kedy je efektívnejšie pokračovať v implementácií ďalších súčastí systému, ako sa snažiť obmedziť riziká v jednej konkrétnej už implementovanej časti. Tak isto sa môže stať, že činnosti potrebné na riadenie rizík môžu byť veľmi časovo náročné, a preto môže byť efektívnejšie danú rizikovú časť úplne vynechať a snažiť sa ju nahradiť inými

6 Jozef Grexa alternatívnymi časťami. Manažér rizík musí dokázať podobné situácie analyzovať, v čo najkratšom čase vyhodnotiť a poskytnúť vhodné riešenie. Niektoré zo spomínaných rizík v softvérovom projekte objasňujú aj Addison a Vallabh [2]. V rámci svojej práce uskutočnili prieskum dôležitosti uvedených rizík z pohľadu skúseností projektových manažérov. Do prieskumu sa zapojilo 36 projektových manažérov. Výsledok prieskumu je uvedený na obrázku nižšie (pozri Obr. 1). Obr. 1. Graf výsledkov prieskumu dôležitosti rizík [2]. Riadenie rizík Riadenie rizík je ďalšou veľkou témou, súvisiacou s manažmentom rizík. V tejto práci sa chcem tejto téme venovať len okrajovo, ale myslím si, že je dôležité poznamenať niekoľko faktov. Kategorizácia rizík, tak ako som ju uviedol pre softvérový projekt šesťčlenného tímu, je nevyhnutným základom pre ďalšie riadenie a prácu s rizikovými faktormi. V oblasti riadenia rizík existuje veľké množstvo modelov a postupov, ktoré sú vhodné aj pre manažment rizík v tímovom projekte spomínaného charakteru. Je veľmi dôležité tieto postupy analyzovať, prispôsobiť a správne zvoliť pre konkrétny softvérový projekt. Avšak dovolím si tvrdiť, že vhodná identifikácia a kategorizácia rizík tvorí nevyhnutný základ pre riadenie rizík a v celkovom manažmente rizík predstavuje asi dve tretiny všetkých krokov, nutných k zabezpečeniu kvalitného manažmentu

Kategorizácia a riadenie rizík v softvérovom projekte šesťčlenného tímu 7 rizikových oblastí. S kategorizáciou rizík v kontexte ich riadenia, veľmi úzko súvisí rozdelenie zodpovedností za vymedzené kategórie jednotlivým členom tímu. Podľa môjho názoru, je to najdôležitejšia časť riadenia rizikových oblastí. Ak má každý člen tímu na svojej pozícií jednoznačne určené zodpovednosti a vymedzené pole pôsobnosti, vytvárajú sa tak najlepšie predpoklady k predchádzaniu, včasnej identifikácií, obmedzeniu alebo riadeniu rizík. Preto uvádzam môj návrh pridelenia zodpovedností za dané kategórie možným pozíciám v softvérovom projekte šesťčlenného tímu (pozri Obr. 2). Obr. 2. Schéma pridelenia kategórií ku členom tímu na daných pozíciách. Veľkosť poľa v obrázku vyjadruje mieru zapojenia člena tímu na danej pozícií do celkového manažmentu rizík. Uvedená schéma je veľmi konkrétna, ale myslím si, že dostatočne názorne ilustruje pridelenie zodpovedností za jednotlivé rizikové oblasti alebo kategórie šiestim členom tímu na daných pozíciách. Je zrejmé, že pozície v tíme môžu byť rôzne a závisia od charakteru a zamerania projektu. Avšak napriek tomu som presvedčený, že uvedená schéma je podkladom pre softvérové projekty rôzneho charakteru. Záver Práca v tíme so sebou prináša veľké množstvo rizík z rôznych oblastí. Identifikácia a kategorizácia rizík je základom kvalitného a efektívneho manažmentu týchto oblastí. Vo svojej práci som vytvoril kategórie, ktoré majú široký záber rôznych potenciálnych rizík a zároveň sú vhodným podkladom pre manažment rizík v šesťčlennom tíme.

8 Jozef Grexa Taktiež vytvárajú predpoklad pre spoľahlivé riadenie rizík, do ktorého sú v rámci svojej práce zapojení všetci členovia tímu. Verím, že uvedený článok nájde svoje uplatnenie v praxi a zavedené kategórie budú prakticky používané pri práci šesťčlenného tímu v softvérovom projekte. Použitá literatúra 1. Abdel-Hamid, T.K., Sengupta, K., Swett, C.: The Impact of Goals on Software Project Management: An Experimental Investigation. MIS Quarterly, Vol 23, No. 4, (1999), 531-555. 2. Addison, T., Vallabh, S.: Controlling Software Project Risks an Empirical Study of Methods used by Experienced Project Managers. Proceedings of SAICSIT, (2002), 128-140. 3. Keil, M., Cule, P.E., Lyytinen, K., Schmidt, R.: A Framework for Identifying Software Project Risks. Communications of The ACM, Vol 41, No. 11, (1998), 77-83. 4. May, L.J.: Major Causes of Software Project Failures. Dostupné na http://www.stsc.hill.af.mil/crosstalk/1998/07/causes.asp. (1998). 5. Phan, D., Vogel, D., Nunamaker, J.: The Search for Perfect Project Management. Computerworld, Vol 22, (1998), 95-100. 6. Powel, P.L., Klein, J.H.: Risk Management for Information Systems Developement. Journal of Information Technology, Vol 11, (1996), 309-319. 7. Ropponen, J., Lyytinen, K.: Components of Software Development Risk: How to Address Them? IEEE Transactions on Software Engineering, Vol 26, No. 2, (2000), 98-111. Annotation Risk Categorization and Control within the Software Project of Six Member s Team The area of risk management is still more important part in the process of software system development. Many software projects are unsuccessful because of the inadequate handling of possible risks and their consequences. However, in the field of risk management many significant results have been achieved. Essay shows my view on software project risks in the context of six member s team. Even in the beginning of software project, there are the possibilities of many risks and their consequences estimation. The main goal is the risk categorization. Each category is the set of related risks showing the possibilities of handling, control and team task management. This essay brings the universal ground for the software project risk management in six member s team.