Abstrakt. Open source software (OSS) sa dnes stáva silným konkurentom firmám, ktoré sa komerčne zaoberajú vývojom systému. Často sa pod licenciou OSS tvoria veľké softvérové produkty, na ktorých pracuje početná skupina ľudí. Ako môžu postupy vyvinuté pri práci na OSS produktoch, ale aj samotné OSS produkty zmeniť prácu v tíme, rozoberá esej v 3 častiach.
V prvej časti oboznámim čitateľa so stručnou históriou vzniku OSS. V druhej časti eseje ukážem, ako je možné zvládnuť manažérske procesy pri rozsiahlych projektoch. Niektoré vlastnosti riadenia tímu vznikli vďaka rozsiahlosti projektov, ale je možné ich úspešne aplikovať aj pri malých projektoch. Budem sa venovať zväčšeniu efektívnosti tímovej práce zavedením týchto vlastností do štruktúry organizácie práce na menších projektoch. Posledná časť práce sa zaoberá používaním rýchlo sa meniacich OSS produktov v tíme. Tu prejdem od vnútornej štruktúry riadenia tímu k tomu, ako môžu prácu tímu ovplyvňovať už hotové produkty. Spomeniem rýchly vývoj a update produktov, ako je nevyhnutné sledovať najnovšie trendy, ale ako sa nesmie meniť v krátkom období základ, na ktorom je projekt budovaný, pretože projekt nebude nikdy dokončený.

Abstrakt. Iba päť až desať percent softvérových projektov je možné považovať za úplne úspešné. Tridsať percent začatých projektov sa dá považovať za čiastočne úspešné. Čiastočne, pretože väčšina z nich počas svojej existencie narazila na problémy, s ktorými sú poznačené po celý čas. Potýkali sa s časovými alebo finančnými problémami, ktoré vyústili k neskorému dodaniu, prekročeniu finančných limitov alebo zníženiu kvality výsledného softvérového produktu. Preto sa viacero nezávislých ľudí začalo zaoberať tým, čo je podstatné pre úspešný projekt. Výsledkom bola veľmi podobná sada desiatich pravidiel a rád, ktoré treba dodržiavať, ak chceme zvýšiť šance na prežitie. Aj keď tieto pravidlá sú výsledkom dlhoročných praktických skúseností, jedná sa o teóriu, ktorá nemusí v praxi vždy platiť. Preto budú v práci podrobené "zaťažkávaciemu" testu, kde budú konfrontované s praxou tak, ako ju vidí štatistický výskum vykonaný na vzorke 122 projektov. Ide o výskum ako súvisia jednotlivé podmienky projektu s jeho úspešným ukončením.

Abstrakt. Práca sa zaoberá problematikou vzťahov medzi dodávateľmi a odberateľmi v oblasti softvéru. Venuje sa jednotlivým paradigmám vývoja a obstarávania sofvéru a vysvetľuje aj aplikované postupy pre tieto prístupy. V úvode predostiera a stručne charakterizuje tri základné paradigmy, ktorým sa práca ďalej venuje. Následne popisuje podrobnejšie jednotlivé paradigmy, vzťah medzi dodávateľmi a odberateľmi z hľadiska týchto paradigiem a poukazuje aj na ich nedostatky. Dotýka sa aj tendencií dodávateľov a odberateľov v procese obstarávania softvérových produktov. Práca obsahuje aj detailnejší popis a vysvetlenie aplikovaných procesov pre výber dodávateľa a samotného softvérového produktu. V závere práca porovnáva jednotlivé paradigmy a poukazuje na ich jednotlivé aspekty.

Abstrakt. Za úspechom softvérového projektu stoja ľudia, ktorí sa podieľali na jeho vývoji. Týchto ľudí je často veľké množstvo a sú nútení spolupracovať a robiť kompromisy. Vo fáze testovania softvéru sú proti sebe stavaní testeri a vývojári, pretože to čiastočne vyplýva z ich pohľadu a pozície v procese vývoja softvéru. Medzi týmito skupinami ľudí často vznikajú konflikty, ktoré sú ešte vážnejšie, ak sa tam zamiešajú aj medziľudské vzťahy. Pre úspech softvérového projektu je dôležité vedieť týmto konfliktom predchádzať a vedieť ich prípadne zvládnuť tak, aby to bolo prospešné pre projekt aj pre samotných ľudí. Toto je jedna z dôležitých úloh dobrého manažéra.

Abstrakt. Manažment v softvérovom inžinierstve je jedným z najdôležitejších procesov počas vývoja softvérového produktu. Pri plánovaní projektu je potrebné dbať aj na proces manažmentu rizík. Manažér by mal identifikovať najväčšie riziká spojené s projektom a snažiť sa ich kontrolovať, zmierňovať alebo eliminovať. V mojej eseji sa zaoberám niekoľkými faktormi ovplyvňujúcimi rizikovosť projektu. Veľmi dôležité je identifikovanie všetkých faktorov a stanovenie dôležitosti a miery ovplyvniteľnosti týchto faktorov. Preto je dobré mať k dispozícii vyhradeného manažéra rizík, ktorý sa týmito činnosťami bude zaoberať. Vo väčšine prípadov nie je možné jednoznačne stanoviť mieru rizika a preto sa používajú metódy pre odhad rizík. Existuje niekoľko spôsobov odhadovania rizík, ktoré sa odlišujú hlavne v spôsobe použitia, spoľahlivosti a čase potrebnom pre odhad.

Abstrakt. Práca sa zaoberá potrebou správnych odhadov budúcnosti a pojednáva o myšlienke, že inžiniersky prístup v tvrdom konkurenčnom boji nestačí. Pre manažéra v softvérovej firme je dôležité staviť na správnu kartu na základe svojich odhadov, podobne ako burzový maklér nakupuje a predáva akcie podľa vlastného úsudku. Touto kartou môže byť technológia alebo budúce požiadavky zákazníkov, dôležitý je však aj odhad problémov a ich riešenie ešte pred ich vznikom. Navyše, ako všetci vieme, zákazník nevie, čo chce, a preto úlohou dobrého manažéra je aj vedieť to za neho.
Nie každý inžinier môže byť manažérom a nie každý manažér má dar dobrých odhadov a predpovedí, ktoré mu dopomôžu dostať sa vo firme do pozície, v ktorej môže rozhodovať o jej strategickom smerovaní.

Abstrakt. Pri zahajovaní nového softvérového projektu projektový manažér musí stanoviť resp. odhadnúť rozsah a určiť termín dokončenia projektu (ak nie je vopred určený). Z toho potom vyplýva úloha stanoviť počet ľudí ktorí budú na projekte pracovať. Pre tieto úlohy boli vytvorené metriky (LOC, FP) a metóda COCOMO, ktoré poskytnú manažérovi základný obraz o projekte. Ale len projektový manažér na základe svojich skúseností a znalostí o tíme ľudí s ktorým pracuje bude (mal by) vedieť určiť rozsah projektu a počet ľudí potrebných na úspešné dokončenie projektu. V eseji sa pokúšam objasniť prečo výsledky hocijakej metódy, aj keď sa snaží zohľadniť najrôznejšie parametre, nie je možné použiť ako exaktné číslo, ale len ako indikátor nejakého stavu.

Abstrakt. V dnešnej dobe snáď neexistuje väčšia firma, ktorá by nejakým spôsobom nevyužívala metódy outsourcingu. Outsourcuju sa ľudské zdroje, know-how, rôzne služby prípadne aj výpočtová kapacita. V tejto práci sa zameriam na outsourcing ľudských zdrojov pri softvérových projektoch. Pokúsim sa prezentovať môj osobný pohľad na výhodnosť outsourcingu a opíšem, kedy je vhodné uvažovať nad jeho použitím. Ďalej sa budem snažiť na konkrétnom projekte načrtnúť, s akými rizikami sa pri outsourcingu môžeme stretnúť a čo je možné spraviť na ich elimináciu, prípadne zmiernenie ich následkov.

Abstrakt. Článok je rozdelený na dve časti. V prvej časti sa zaoberá existujúcou kategorizáciou rizík vplývajúcich na softvérové procesy a ich výstupy, pričom tieto kategórie rozoberá bližšie. V druhej časti porovnáva dopad rizík na výsledky projektu a identifikuje interaktívne pôsobenie medzi nimi. Článok ponúka aj porovnanie možností kontroly rôznych druhov rizík z pohľadu manažéra softvérového projektu, pričom sa opiera o výsledky internetového prieskumu. Vymedzuje rozdiel medzi výstupmi procesu a výstupmi produktu a objasňuje možné dopady rizík na tieto dve oblasti. Na záver článku sú stanovené aj odporúčania pre manažérov softvérových projektov s dôrazom na elimináciu možných rizík, ktoré sa môžu vyskytnúť pri ich riešení.

Abstrakt. Stresu je v súčasnosti vystavených veľa zamestnancov v IT oblasti, bez ohľadu na to, akú pozíciu zastávajú. Stres má v niektorých situáciách pozitívny účinok, ktorý núti človeka k lepším výkonom. Toto však neplatí pri IT projektoch, kde je vplyv stresu na človeka negatívny, keďže človek pod stresom je náchylný k väčšiemu množstvu chýb. Stres má tiež negatívny vplyv na výsledky firmy a kvalitu jej produktov. Zamestnanci na rôznych pozíciách vnímajú rôzne podnety z okolitého prostredia rôzne, a líšia sa v citlivosti na rôzne stresové faktory. V článku sú identifikované stresové faktory, ktoré pôsobia na jednotlivé skupiny IT zamestnancov. Väčšina stresových faktorov sa dá minimalizovať správnymi pracovnými postupmi alebo zmenou prístupu zamestnanca k riešeniu problému, čí plneniu úlohy.

Abstrakt. Proces testovania softvéru je často podceňovaný alebo z rôznych príčin ignorovaný. Ľudia majú zaužívanú predstavu, že testovanie je jednoduché, že ide o automatizovanú činnosť, na ktorej vykonávanie netreba mať nijaké zvláštne nadanie. Výsledkom potom býva neúspech softvérového projektu alebo nespokojnosť zákazníka. Cieľom tejto eseje je vyvrátiť tieto tvrdenia, poukázať na dôležitosť testovania a priblížiť čitateľovi hlavné problémy, s ktorými je testovanie spojené.

Abstrakt. Tento príspevok reaguje na úvahy podložené meraním, podľa ktorých má OSS prístup k vývoju softvéru problémy s udržiavateľnosťou kódu. V tomto príspevku predstavujem metódy, na základe ktorých bol sformulovaný takýto záver a navrhujem alternatívnu interpretáciu výsledkov. Ďalej predstavujem OSS komunitu a postupy, ktoré používa na riadenie projektu a zabránenie takým nežiadúcim javom ako je zhoršená udržiavateľnosť kódu. Sústreďujem sa pritom hlavne na črty, ktoré považujem za podstatné s hľadiska riadenia OSS projektu a formulujem návrhy na vylepšenie riadenia takéhoto typu projektov.

Abstrakt. V dnešnej dobe vzniká veľké množstvo softvérových projektov rôzneho rozsahu. Aj keď mnohé z nich končia úspešne a spĺňajú požadovanú funkčnosť a kvalitu, existuje veľké množstvo tých, ktoré končia neúspechom z dôvodov prekročenia rozpočtu, nedodržania časového plánu, alebo dodaním systému so zníženou funkcionalitou oproti požadovanej. Práve nedostatočná pozornosť venovaná identifikácii a manažmentu súvisiacich rizík vedie k neúspešneho ukončeniu projektu . Vzhľadom na to, že táto problematika je ešte stále pre mnohých softvérových manažérov pomerne neznáma, je veľmi dôležité vedieť, ktoré typy rizík najviac ovplyvňujú úspešný výsledok projektu a ako navzájom súvisia. Témy, ktorými sa zaoberám teda zahŕňajú analýzu príčin úspechu a neúspechu softvérových projektov v minulosti, identifikáciu rizík, ktoré najväčšou mierou ovplyvňujú úspešný výsledok projektu a hľadanie súvislostí medzi nimi. Pozornosť je venovaná nielen vplyvu rizík na úspešnosť projektu, ale čiastočne aj príčinám krachu softvérových projektov, keďže tieto témy spolu úzko súvisia.

Abstrakt. Úmyslom práce je ponúknuť čitateľovi pohľad na vývoj softvéru očami tímu, ale hlavne pohľad zvonka na tím ako celok. Práca pojednáva o dôležitosti tímu pri súčastných trendoch vo vývoji softvéru, akými je rast veľkosti systémov a s tým spojený rast zložitosti tvorby týchto systémov. Dôraz je kladený aj na výkon jednotlivca, ktorý aj v tíme zostáva na prvom mieste. Súdržnosť, vzájomné dopĺňanie sa a motivácia len podčiarkujú vzájomné vzťahy členov tímu, ktoré tvoria základ pre úspešnú spoluprácu a úspešne vyriešenie projektu. Práca sa zaoberá rozdelením tímu na rôzne typy vzhľadok k vnútornej štruktúre a organizácii tímu, vzhľadom k cieľom ktoré sa majú dosiahnuť a spôsobu akými tieto ciele dosiahnuť.

Abstrakt. Na prvý pohľad sa zdá, že agilné metódy vývoja softvéru priam volajú po zániku etapy návrhu. Povzbudzujú vývojársky tím vytvárať kód a zároveň ho oslobodzujú od písania vyčerpávajúcej dokumentácie. Nielenže sa doslova "vysmievajú" návrhu a označujú ho ako veľká "pred-fáza" skutočného vývoja (big up front), ale aj používanie techník ako UML, ale aj iných flexibilných frameworkov je obmedzované, alebo dokonca úplne vypustené. Faktom je, že návrh v agilných metódach nezaniká. Je prítomný, ale v zmenenej podobe. Agilné metódy upúšťajú od tradičného vodopádového modelu vývoja softvéru a uprednostňujú evolučný model. Nebránia sa zmenám návrhu v jednotlivých iteráciách vývoja. Naopak, uvítajú každú relevantnú zmenu. Základnou technikou v agilných metódach je refaktoring, ktorý umožňuje zmenu návrhu aj vo fáze implementácie. Agilné metódy istým spôsobom omladzujú vývoj, robia ho flexibilným a stavajú vývojársky tím do novej polohy. Jednou z popredných agilných metód je Extreme programming (XP), ktorým sa zaoberá predovšetkým Kent Beck. Je zaujímavé, ako sa názory a myšlienky viacerých zástancov agilných metód stretávajú. Agilné metódy sú v súčasnosti masívne zavádzané do praxe a ešte nepovedali posledné slovo v oblasti vývoja softvérových produktov.

Abstrakt. Predkladaná esej pojednáva o zodpovednosti za softvérové chyby. Opisuje možné dôsledky softvérových chýb pre bežných používateľov. Zamýšľa sa nad problémom či je vôbec možné niesť zodpovednosť za vytvorený program a aký je rozdiel z pohľadu zodpovednosti za generický a za zákazkový softvér.
Ďalšie úvahy sa uberajú smerom, kedy začnú byť firmy zodpovedné za svoje produkty a možné dopady zavedenia legislatívnych noriem pre tvorbu softvéru. Opisuje súčasný stav riešenia a spôsob predchádzania softvérovým chybám. Zamýšľa sa nad myšlienkou, že bezpečnosť informačných systémov nie je technický, ale skôr ekonomický problém. Následne rozoberá situáciu na súčasnom trhu so softvérom a rolu zákazníka, či má skutočne možnosť vybrať si softvér podľa kvality alebo jeho výber podlieha iným kritériám.

Abstrakt. Práca sa zaoberá problematikou zvyšovania produktivity tímov, podieľajúcich sa na tvorbe softvérových produktov. Pojednáva o niekoľkých základných faktoroch, ktoré ovplyvňujú produktivitu práce a teda ich poznanie napomáha pri snahách o zvyšovanie efektívnosti práce. Dotýka sa problematiky koordinácie prác, pričom bližšie analyzuje dôvody vedúce k potrebe dobrej koordinácie a naznačuje spôsoby riešenia tohto problému. Predostiera aj problémy motivácie členov tímu, či už finančnej, osobnej, pracovnej, atď, ako aj nutnosti vyžadovania zodpovednosti, dôležitosti určovania priorít, ale aj technických otázok ako je dodržiavanie štandardov kódovania, či dokumentovania vytvoreného kódu. Práca nepredostiera len teoretické poznatky z oblasti manažmentu, ale aj konkrétne praktické skúsenosti autora a niekoľkých vedúcich pracovníkov z oblasti vývoja softvéru.