Tvorba plánov v softvérovom projekte, rozdelenie úloh, plnenie a aktualizácia plánov

Similar documents
kucharka exportu pro 9FFFIMU

Spájanie tabuliek. Jaroslav Porubän, Miroslav Biňas, Milan Nosáľ (c)

Aplikačný dizajn manuál

Databázové systémy. SQL Window functions

Tvorba a potreba plánov v softvérovom projekte

BODY PRÍPADOV POUŽITIA ALEBO AKO MERAŤ SOFTVÉR

Anycast. Ľubor Jurena CEO Michal Kolárik System Administrator

Testovanie bieleho šumu

AKO NA RIZIKÁ. Hurá metóda asi nebude správna. Jaroslav Grega. Čo je riziko? Čo je manažment rizík

SOFTVÉROVÁ PODPORA PLÁNOVANIA PROJEKTOV V MALÝCH TÍMOCH

Tvorba plánov DÁVID KOVÁČ

Copyright 2016 by Martin Krug. All rights reserved.

Riešenia a technológie pre jednotnú správu používateľov

VYLEPŠOVANIE KONCEPTU TRIEDY

Obsah. SOA REST REST princípy REST výhody prest. Otázky

Constraint satisfaction problems (problémy s obmedzujúcimi podmienkami)

Kvalita, výsledok plánovania a riadenia

TP-LINK 150Mbps Wireless AP/Client Router Model TL-WR743ND Rýchly inštalačný sprievodca

Február Scrum: Vyvinuli a udržiavajú Ken Schwaber a Jeff Sutherland

MERANIE SOFTVÉRU. Jakub Šimko MSI

Registrácia účtu Hik-Connect

Desatinné čísla #1a. Decimal numbers #1b. How much larger is 21,8 than 1,8? Desatinné čísla #2a. Decimal numbers #2b. 14 divided by 0,5 equals...

PODPORNÉ PROSTRIEDKY PRE VERZIOVANIE: VHODNÝ VÝBER PRE NÁŠ TÍM?

AKO ZVÍŤAZIŤ NAD SOFTVÉROVÝM PROJEKTOM

Základná(umelecká(škola(Jána(Albrechta Topoľčianska(15

Význam manažmentu rizík pre úspešnosť projektu

Databázy (1) Prednáška 11. Alexander Šimko

Mesačná kontrolná správa

MS Exchange 2010 Prechod Ing. Peter Záhradník

Efektívna analýza a plánovanie rizík v softvérových projektoch malého a stredného rozsahu

BGP - duálne prepojenie AS. (primary + backup spoj), s IBGP, cez virtuální L2 linky

AKO NEPREHRAŤ NÁROČNÚ HRU PROJEKTOVÉHO MANAŽMENTU

Manažment rizík v softvérovom projekte

Osobovo-orientovaný prístup vývoja softvéru

Metody projektového řízení

Podporné prostriedky pre riadenie softvérového projektu

Plánovanie a agilné metodológie vývoja softvéru

Mesačná kontrolná správa

Manažérsky sen dokonalej tímovej práce

MSI KIVT FEI STU Bratislava

eduscrum príručka Pravidlá hry December 2013 Vyvinuté eduscrum tímom Autori: Arno Delhij & Rini van Solingen Review: Jeff Sutherland

NÁVRH ICT PROJEKTU A APLIKACE METODIKY PROJEKTOVÉHO MANAGEMENTU V PODNIKU DESIGN OF ICT PROJECT AND PROJECT MANAGEMENT APPLICATION IN COMPANY

Plánovanie SCRUM šprintu pomocou nástroja Redmine

Rýchlosť Mbit/s (download/upload) 15 Mbit / 1 Mbit. 50 Mbit / 8 Mbit. 80 Mbit / 10 Mbit. 10 Mbit / 1 Mbit. 12 Mbit / 2 Mbit.

Dlhodobé udržanie motivácie v malom vývojovom tíme pracujúcom metódou SCRUM

Agilné metódy vývoja softvéru a rozsah projektu

Textový formát na zasielanie údajov podľa 27 ods. 2 písm. f) zákona

9. PROJEKTOVÉ PLÁNOVANIE

Tvorba softvéru v treťom tisícročí Hobiti

KOOS PRIESKUM O KOLENE

Problém Big Data a ako ho riešiť pomocou NoSQL. Ján Zázrivec Softec

Microsoft Azure platforma pre Cloud Computing. Juraj Šitina, Microsoft Slovakia

Ochrana proti DDoS za použitia open-source software. Katarína Ďurechová

Jazyk SQL. Jaroslav Porubän, Miroslav Biňas, Milan Nosáľ (c)

Tvorba informačných systémov. 4. prednáška: Návrh IS

REPORT DESIGNER 1 VYTVORENIE A ÚPRAVA FORMULÁRA. úprava formulárov v Money S4 / Money S Vytvorenie formulára

Poradové a agregačné window funkcie. ROLLUP a CUBE

MS Project - Programy a rieš enia pre projektový manažment MS Project Project management programs and solutions

Stres a IT zamestnanci

Návrh kritérií pre habilitáciu docentov a vymenúvanie profesorov na Ekonomickej fakulte TU v Košiciach

Využitie simulácií pri manažovaní projektu 1

Podporované grantom z Islandu, Lichtenštajnska a Nórska prostredníctvom Finančného mechanizmu EHP a Nórskeho finančného mechanizmu

LL LED svietidlá na osvetlenie športovísk. MMXIII-X LEADER LIGHT s.r.o. Všetky práva vyhradené. Uvedené dáta podliehajú zmenám.

NÁKLADY ŽIVOTNÉHO CYKLU LIFE CYCLE COSTS

SLOVENSKÁ TECHNICKÁ UNIVERZITA FAKULTA INFORMATIKY A INFORMAČNÝCH TECHNOLÓGIÍ ILKOVIČOVA 3, BRATISLAVA 4

UNIVERZITA KOMENSKÉHO V BRATISLAVE FAKULTA MATEMATIKY, FYZIKY A INFORMATIKY POKROČILÝ MERAČ ČASU BAKALÁRSKA PRÁCA.

Databázy (1) Prednáška 08. Alexander Šimko

GTD DONE. Getting Things. Umenie byť produktívny bez stresu

Vnímanie neviditeľného [Holographic Eyes]

Projekt implementace projektového řízení do společnosti HRAZDIL stav, s.r.o. Bc. Monika Bušová

TRANSCRIPTION OF NUMERICAL OBJETCS TO TEXT FOR SLOVAK LANGUAGE

Recipient Configuration. Štefan Pataky MCP, MCTS, MCITP

Vzory, rámce a webové aplikácie

PRACOVNÝ DOKUMENT ÚTVAROV KOMISIE. Spoločná metodika hodnotenia štátnej pomoci

POROVNANIE GUI VYBRANÝCH SOFTVÉROVÝCH NÁSTROJOV

VYSOKÉ UČENÍ TECHNICKÉ V BRNĚ BRNO UNIVERSITY OF TECHNOLOGY

Spôsoby zistenia ID KEP

UNIVERZITA KOMENSKÉHO V BRATISLAVE FAKULTA MATEMATIKY, FYZIKY A INFORMATIKY VÝUKOVÁ WEBOVÁ APLIKÁCIA NA PROGRAMOVANIE GPU.

Stres, jeho príčiny a riešenia

Agilné metódy vývoja softvéru a rozsah projektu

V MALOM PROJEKTE MALÉ RIZIKÁ?

Distribuované databázy Motivácia Homogénne a heterogénne databázové systémy Distribuované databázové systémy a transakcie Požiadavky na systém,

Tvorba softvéru v tretom tisícrocí

Príručka pre mladých lídrov

Analýza osobností v softvérovom projekte MIROSLAV JACKOVIČ

Komunikačné protokoly 2005 KP 2005 #3 - IP v02.doc

Programovanie v jazyku Python. Michal Kvasnica

VYSOKÉ UČENÍ TECHNICKÉ V BRNĚ BRNO UNIVERSITY OF TECHNOLOGY

Proces terénnej sociálnej práce v sociálne vylúčenej komunite

UNIVERZITA KOMENSKÉHO V BRATISLAVE FAKULTA MATEMATIKY, FYZIKY A INFORMATIKY

Projekt využití CRM jako konkurenční výhoda firmy STABOS, s.r.o. Bc. Jana Mižíková

IDEÁL DOBRÉHO ŽIVOTA" Z OSOBNEJ PERSPEKTÍVY

Manažment kvality a testovanie softvéru

Government Cloud. Stratégia využitia Cloud Computing-u vo Verejnej správe SR. Peter Kišša

MOŽNOSTI VYUŽITIA ĽUDSKÉHO POSTUPU PRE NÁVRH

ZADÁNÍ DIPLOMOVÉ PRÁCE

Dokumentácia k riadeniu

Hodnotenie kvality produktu

Metody optimalizace činností firemních struktur. Filip Stránsky

SLOVENSKÁ POĽNOHOSPODÁRSKA UNIVERZITA TECHNICKÁ FAKULTA

Transcription:

Tvorba plánov v softvérovom projekte, rozdelenie úloh, plnenie a aktualizácia plánov MARIÁN SALAJ Slovenská technická univerzita Fakulta informatiky a informačných technológií Ilkovičova 3, 842 16 Bratislava salo3@atlas.cz Abstrakt. Pri vytváraní projektového plánu sa pokúšame predpovedať budúcnosť, čo vôbec nie je jednoduché. Dosť veľa projektov zlyhá kvôli úbohému, alebo zlému plánu. Ale ani dobrý plán však nezaručuje úspech, hlavne kvôli neistotám pri vývoji softvéru. Prečo potom vytvárať plán, keď existuje veľa vecí ktoré nemôžeme dobre predpovedať? Esej si kladie za cieľ informovať o význame plánu pre projekt, identifikovať faktory ktoré vnášajú do plánu neistoty a spôsobe ako s nimi zaobchádzať pri tvorbe plánu. Časť eseje sa venuje aj spôsobu akým reagovať, keď sa zistí, že projekt sa odkláňa od plánu. Úvod Mnohé projekty skončia neúspechom. Časť je jednoducho zrušená a veľká väčšina tých čo sú úspešne dokončené sú dokončené neskoro a prekročili plán nákladov, niekedy aj viac ako 100%. Čo rozhoduje nad úspechom, alebo neúspechom projektu? Je to viacej vecí, ale jedna z nich je dobre postavený plán pred začiatkom projektu, jeho aktualizácia ako projekt postupuje a jeho dodržiavanie. Tvorba plánu je tematikou tejto eseje. Čitateľ bude oboznámený s významnosťou plánu a jeho tvorbou. Časť eseje je venovaná činnostiam ktoré treba vykonať aby sa zabránilo neskorému dokončeniu projektu. Podotýkam, že sa zameriavam hlavne na tvorbu plánu v malom tíme. Význam plánu Projekt je proces, ktorý má začiatok a koniec. V softvérovom inžinierstve je cieľ zvyčajne efektívny softvér. Každý projekt začína vytvorením projektového plánu, Manažment v softvérovom inžinierstve, október 2006, s. 1-7.

2 Marián Salaj ktorý predstavuje schému na zabezpečenie chodu projektu. Vytváranie projektového plánu znamená predpovedať budúcnosť s cieľom minimalizovať riziko počas vykonávania plánu. Cieľom je vytvoriť plán, aby čo najviac odpovedal realite. Existuje však veľa detailov počas práce na projekte, ktoré si vyžadujú špeciálnu pozornosť. Tieto detaily voláme narušenia a vnášajú neurčitosť do projektu. Tieto narušenia je občas ťažké predpovedať. Vynára sa tu však potom otázka, že či má vôbec význam vytvárať plán projektu keď existujú tieto narušenia. Prečo jednoducho nereagovať na udalosti tak ako projekt postupuje? Každý kto ma tú skúsenosť pracovať na úboho plánovanom projekte vie, že toto nie je riešenie. Hlavným problémom keď nevytvorí tím plán, je to, že potom len ťažko vie presne povedať ako postupuje na projekte. Tím si môže myslieť, že má ešte dosť času na dokončenie a zrazu zistí, že nestíha dokončiť projekt načas. Preto zobrať si čas na spravenie plánu pred začatím projektu zjednoduší veci neskôr. Aj napriek tomu, že projektový plán má svoje hranice, plní niekoľko funkcií: definuje ciele, úlohy a zodpovednosti - toto umožňuje tímu pracujúcemu na projekte porozumieť čo sa snaží projekt dosiahnuť - čo treba urobiť a pre koho to treba urobiť definuje požiadavky na zdroje udáva kontrolné body projektu pripravuje na nastanie pravdepodobných udalostí očakávanie nepravdepodobných udalostí - plán sa snaží identifikovať niektoré udalosti ktoré môžu nastať a vytvára mechanizmus ako s nimi zaobchádzať, alebo aspoň ako ich rozpoznať keď nastali zlepšuje výkonnosť tímu vytvára základňu pre sledovanie a riadenie práce Existuje niekoľko faktorov, ktoré vytvárajú narušenia, niektoré z nich sú: rozsah - plán sa vytvára ešte pred začiatkom práce na projekte a v tom čase je ešte nevieme aký veľký bude, aké úsilie stojí za požadovanými funkciami výkonnosť - často nevieme aký efektívny budeme pri nadobúdaní nových poznatkov a ako efektívne ich budeme využívať technológia - ovplyvňuje rozsah aj výkonnosť, zmeny v technológií môže mať výrazný efekt na správanie projektu Tvorba plánov Každý projekt je iný, má svoje špecifické požiadavky a preto pre každý projekt treba vytvárať plán odznova. Aj keď nový projekt môže byť podobný nejakému

Tvorba plánov v softvérovom projekte, rozdelenie úloh, plnenie a aktualizácia plánov 3 predchádzajúcemu, recyklovanie starého plánu nie je riešenie a môže narobiť viacej škody ako osohu. Článok [1] takéto recyklovanie plánov berie za hriech v plánovaní. Existuje viacero druhov plánov, ktoré možno vytvárať v rámci projektového plánu. Vytvárajú sa podľa veľkosti projektu a tímu. Najzaujímavejšie pre malé tímy sú plány rozsahu a rozvrhu projektu, plán ľudských zdrojov, prípadne aj plán nákladov na projekt. Plán rozsahu slúži ako podklad pre budúce rozhodnutie, stanovuje merateľné kritéria na určenie, či projekt, alebo jeho etapa skončili. Tvorí základ pre dohodu medzi zákazníkom a projektovým tímom. Plán ľudských zdrojov určuje aké ľudské zdroje treba na vykonanie činnosti aký ľudia sú potrební a v akom množstve. Plán rozvrhu projektu Projekty sú zvyčajne dosť veľké na to aby sa dali naplánovať naraz, preto vytvorenie plánu postupuje krokmi zhora nadol, pri realizácií projektu sa potom postupuje zdola nahor. Komplexné projekty môžu obsahovať niekoľko poloautonómnych komponentov, ktoré môžu byť plánované nezávisle. Ak vytvorenie nejakého komponentu trvá príliš dlho, mala by byť práca rozdelená na etapy (okolo 4 až 6 mesiacov). Každá etapa vytvára podmnožinu výsledkov projektu, je definovaná výsledným správaním, výzorom a informačnou štruktúrou pod ňou. Jednotlivé etapy sa spravidla plánujú na rôznej úrovni podrobnosti, napr. nasledujúca etapa podrobne, ostatné predbežne. Na konci každej etapy projektový tím vypracuje sumarizáciu výsledkov etapy v písomnej forme. Cieľom tohto je zamyslieť sa nad náročnosťou činností - bolo treba vynaložiť viacej úsilia alebo menej? Prečo? Čo môžeme spraviť aby sme sa podobnej chybe vyhli v budúcnosti. Jednotlivé etapy sa potom ďalej rozdelia na činnosti. Činnosti v pláne treba opísať jednoznačne a každá má jednoznačne definovanú podmienku ukončenia (u činností ktoré neprodukujú merateľný výstup je podmienka ukončenia daná uplynutím určitého času). Neodporúča sa opisovať činnosť spočiatku veľmi detailne. Článok [1] dokonca hovorí o skorom detailnom plánovaní ako o jednom z hriechov plánovania, a jeho hodnotu dáva na úroveň ako keby sa neplánovalo vôbec. Každý člen tímu potom môže pomocou tejto informácie sledovať svoj postup na aktuálnej úlohe. Je pre neho potom jednoduchšie povedať, či sa nachádza mimo plánu a či mu stačí vynaložiť viacej úsilia, alebo či treba upovedomiť vedúceho projektu. Ako už bolo spomenuté vytvorenie detailného plánu rozvrhu projektu zahŕňa rozbitie etapy na činnosti (s dĺžkou trvania nie viac ako dva týždne na jedného človeka). Toto nie je jednoduchá úloha a preto by ju ma robiť člen tímu, ktorý má najviac skúseností s činnosťami na ktorých sa robí v danej etape. Táto osoba potom vytvorí zoznam práce, ktorá musí byť vykonaná pred dosiahnutím cieľa etapy. Pri vytváraní zoznamu činností treba brať do úvahy okrem práce ktorú treba vykonať, aj to, že môžu nastať prekvapenia z predchádzajúcich etáp. Je dôležité identifikovať a dokumentovať vzťahy medzi činnosťami, aby mohli by činnosti zoradené.

4 Marián Salaj Pri zvažovaní závislosti medzi činnosťami v rámci projektu sa berie do úvahy či sa jedná o nevyhnutnú závislosť, alebo závislosť podľa uváženia. Pri nevyhnutnej závislosti existujú fyzické obmedzenia, ktoré nemožno nijak ovplyvniť. Závislosti podľa uváženia treba veľmi dobre zdokumentovať. Pri zoraďovaní činností treba uvažovať nad tým aké úlohy musia byť ukončené skôr ako môžeme začať pracovať na tejto úlohe. Je možne vykonávať súbežne nejaké iné úlohy? Ktoré činnosti závisia na nej a nemôže ich začať skôr ako neskončí? Výsledkom týchto úvah je vytvorenie grafu činností, ktorý ukazuje závislosti medzi činnosťami. Ďalším krokom pri vytváraní plánu je odhadnutie dĺžky trvania jednotlivých činností. Dĺžka môže byť udaná v dňoch, týždňoch, intervaloch alebo ako pravdepodobnosť určitého času trvania. Najkvalifikovanejší člen tímu na túto úlohu by mal ohodnotiť obtiažnosť činností (napr. ľahká, stredná, ťažká) a podľa toho odhadnúť potrebný čas. Podkladom pre takéto posúdenie sú jeho skúsenosti a informácie z predchádzajúcich projektov (hovoríme o porovnaní na základe analógie). Prípadne môžu byť použité na určenie dĺžky trvania ďalšie merateľné parametre (napr. pri implementácií triedy počet funkcií v triede), treba však odhaliť vzťah medzi týmito parametrami a dĺžkou trvania činnosti. Ak sa pri tomto kroku zistí, že činnosť je veľmi náročná, alebo trvá dlho, tak sa ju treba pokúsiť rozložiť na menšie činnosti a vytvoriť závislosť medzi nimi. Výsledok predchádzajúcej práce je daný osobe, ktorá vytvorí plán rozvrhu. Výhodné je pri tom použiť nejaký softvér, ktorý slúži na vytváranie plánov. Zväčša je vytváraný vo viacerých iteráciách, najmä preto lebo sa zmenia odhady trvania činností. Pre každú činnosť sa určí čas kedy musí začať a skončiť najneskôr, bez toho aby to malo vplyv na celkovú dĺžku projektu. Hovoríme o takzvanej dobe nečinnosti. Rozvrh je potom vytvorený za použitia matematickej analýzy. Vytvorený detailný plán potom pozostáva z grafu činností, ktorý ukazuje vzťahy medzi činnosťami a z Ganntovej schémy, ktorá ukazuje začiatky, dĺžku trvania činností, dobu nečinnosti a pridelenú osobu, osoby. Priložený je popis činností. Tento plán potom koluje medzi členmi tímu, na posledné úpravy a akceptáciu. Vytvorený plán musia odsúhlasiť všetky skupiny zapojené do prác na danom projekte (v prípade tímu teda všetci jeho členovia). Po jeho odsúhlasení môže začať práca na projekte. Zaobchádzanie s neznámym Ako už bolo spomenuté počas vykonávania plánu môžu nastať rôzne situácie, ktoré sa nedali predpovedať pri vytváraní plánu a môžu predĺžiť dobu trvania projektu. Existuje niekoľko stratégií ako zaobchádzať s nimi pri vytváraní plánu. Môžeme sa jednoducho tváriť, že neexistujú a dúfať, že nenastanú. Alebo môžeme dúfať že nastanú dobré nepredvídateľné veci, ktoré vyrušia tie zlé. Najlepšie je samozrejme priznať, že existujú a počítať s nimi pri vytváraní plánu. Čo sa však stane ak k celkovej odhadnutej dĺžke projektu pridáme určitú rezervu pre prípad, že by nastali nepredvídateľné udalosti a podľa toho stanovíme termín ukončenia projektu? Je vysoko pravdepodobné, že tento čas bude spotrebovaný členmi

Tvorba plánov v softvérovom projekte, rozdelenie úloh, plnenie a aktualizácia plánov 5 tímu, jednoducho preto, lebo je tam. Zvyčajne sa však prácou na projekte zistí, že je väčší ako sa myslelo a to nie preto lebo sa zmenil rozsah projektu, ale kvôli lepšiemu porozumeniu cieľu. V [2] navrhli riešenie vytváraním dvoch plánov - jeden tradičný a druhý, z ktorého termíny odovzdania budú povedané zákazníkovi. Tento plán počíta s určitou rezervou a preto je jeho dĺžka trvania dlhšia. Potom vlastne zákazníkovi bude povedaní jeden termín, zatiaľ čo tím pracuje na druhom. Ak sa potom pretiahne trvanie projektu tak sa nič nestane, teda ak sa neprekročí termín, ktorý bol stanovený na odovzdanie zákazníkovi. Samozrejme takéto vytváranie dvojitých plánov funguje len vtedy ak môžeme sami stanoviť termín ukončenia projektu. Ak je termín zadaný zákazníkom tak nemá význam robiť dvojité plány. Otázkou potom zostáva aj to, či by mali členovia tímu vedieť, že existuje iný dátum odovzdania, alebo by si to mal manažér nechať pre seba. Ak nevedia ako sa budú správať ak sa to dozvedia? Plnenie plánu Plnenie plánu je veľmi dôležitá vec. Keď činnosť spotrebuje všetku dostupnú dobu nečinnosti, tak hovoríme, že činnosť mešká. Kým nebude dokončená nemôžu začať činnosti, ktoré na nej závisia. Úlohou projektového manažéra je rozpoznať, že dochádza k oneskoreniu oproti plánu a snažiť sa konať, tak aby bol termín uvedený v projektovom pláne dodržaný. Toto môže byť dosiahnuté skrátením doby trvania ostávajúcich činností, alebo skrátením celkovej zostávajúcej dĺžky projektu. Treba si však najprv položiť otázku, či zákazník trvá na termíne dokončenia projektu. Lebo ak netrvá a neexistuje žiadna zmysluplná práca pre tím po skončení projektu tak pravdepodobne nemá význam vynakladať viacej prostriedkov. Skrátenie kritickej cesty Celkovú dobu trvania projektu možno určiť tak, že spočítame dobu trvania všetkých činností na každej ceste v grafe činností a vyberiem najväčšiu hodnotu. Cesta ktorej táto doba potom prislúcha sa nazýva kritická cesta. Keďže činnosti na tejto ceste sú zodpovedné za celkovú dobu trvania projektu nemá význam urýchľovať činnosti mimo kritickej cesty, keďže tie neskrátia dĺžku trvania projektu. Treba však myslieť na to, že skracovaním doby trvania činností na kritickej ceste sa môže iná cesta stať kritická. Pobádanie tímu aby robili rýchlejšie môže mať nejaký efekt, ale zvyčajne je vyžadovaná viac pozitívnejšia akcia, ako je napríklad zvýšenie dostupných zdrojov. Treba zvážiť či má zmysel pridať ďalšieho programátora, lebo hlavne pri malých a dostatočne rozpracovaných moduloch to môže mať skôr opačný, ako želaný efekt. Teda činnosť skončí ešte neskôr ako kedy sme nič nespravili. Zvýšenie zdrojov sa dá dosiahnuť tak, že ich urobíme dostupné po dlhšiu dobu. Teda tím bude robiť nadčasy. Ak toto neponúka dostatočné riešenie projektový manažér môže zvážiť pridanie efektívnejšieho zdroja, prípadne jeho vymenenie

6 Marián Salaj s menej efektívnejším zdrojom v nejakej činnosti mimo kritickej cesty. Určite bude produktívnejší nejaký skúsený programátor ako nejaký nováčik. Prehodnotenie podmienok Ak sa pokus o skrátenie činností na kritickej ceste ukáže ako nedostatočný, tak sa treba pokúsiť zvážiť závislosti medzi činnosťami. Pôvodný plán bol pravdepodobne spravený predpokladajúc ideálne podmienky a normálne pracovné postupy. Treba si položiť otázku, či nemôže začať ďalšia činnosť bez toho aby musela predchádzajúca skončiť. Napr. používatelia môžu byť začať školený ešte pred ukončením testovania. Záver Cieľom tejto eseje bolo informovať čitateľa o význame plánu pre projekt, akú funkciu plní, aké úlohy stoja za jeho vytvorením, ako dodržať plán, resp. aké kroky treba vykonať aby bol plán dodržaný. Na záver ešte podotýkam, že aj amatér v tvorbe projektov môže zostaviť výborný projektový plán, keď pozorne zohľadní špecifické potreby projektu. Použitá literatúra 1. McConnel, Steve : The Nine Deadly Sins of Project Planning, IEEE Software 5-7, September/October 2001 2. G. Armour, Phillip : To plan, two plans, Communications of the ACM, Volume 48, Issue 9, 15-19, September 2005 3. Rettig, Marc; Simons, Gary : A project planning and development process for small teams, Communications of the ACM, Volume 36, Issue 10, 45-55, October 1993 4. Krašna, Marjan; Rozman, Ivan; Stiglic, Bruno : How to improve the quality of software engineering project management, ACM SIGSOFT Software Engineering Notes, Volume 23, Issue 3, 120-125, May 1998 5. Bieliková, Mária : Manažment v softvérovom inžinierstve, 1999 6. Hughes, Bob; Cotterell, Mike: Software project management, Second Edition, 1999 Annotation Producing plans in software project, work distribution, tracking and plan actualization When we produce a project plan, we are attempting to foretell the future, what is not so easy. Many projects fail due to poor or bad plan. But not even a good plan guarantee success, mainly because of the uncertainty of software development. Why is it necessary to produce a plan, when many things exists which we can not well predict? The goal of this essay is to inform

Tvorba plánov v softvérovom projekte, rozdelenie úloh, plnenie a aktualizácia plánov 7 about importance of the plan for project, identify factors that introduce unpredictability into the project and how to deal with them. Part of the essay is about methods which we should use when we find out that the project diverging from project plan.