Abstrakt. V súčasnosti je zodpovednosť softvérových firiem za chyby v ich produktoch len veľmi obmedzená. Firmy sa zriekajú akejkoľvek zodpovednosti, pričom sa obhajujú najmä argumentmi o rozdielnosti softvéru oproti bežným produktom, akými sú napríklad autá a argumentmi o nemožnosti vyvinúť softvér, ktorý by neobsahoval chyby. V eseji analyzujem súčasný stav, pričom sa na daný problém pozerám z oboch strán a zamýšľam sa nad jednotlivými argumentmi odporcov i zástancov zavedenia zodpovednosti za softvér. V práci som sa pokúsil odpovedať na otázku, akým smerom sa bude vývoj v danej oblasti uber;ať v budúcnosti a aký bude mať dopad na vývoj a predaj softvérových produktov.

Abstrakt. V súčasnosti existuje mnoho teoreticky opísaných postupov ako riešiť rôzne typy projektov, avšak v praxi neustále vidíme ako niektoré projekty končia neúspechom. Úspech alebo neúspech projektu nie je závislý na jedinom rozhodnutí, na jedinom kroku v priebehu projektu, ale závisí od mnohých faktorov. Ak však nebudeme dbať na znalosti získané z teórie a na skúsenosti z praxe, môžeme nevedomky spraviť mnoho chýb, ktoré sa podpíšu na zlyhaní projektu. Teória nie sú len prázdne slová, ale je to návod ako robiť veci lepšie a chytrejšie. Nemali by sme preto brať teoretické znalosti na ľahkú váhu a mali by sme sa v čo najväčšej miere usilovať preniesť teóriu do praxe.

Abstrakt. Hlavnou úlohou manažmentu projektu je snaha dosiahnuť definované ciele za stanovený čas, pri použití ľudských, materiálnych a finančných zdrojov. Každý softvérový projekt potrebuje na správnu organizáciu a plánovanie informácie, ktoré boli vygenerované predošlými projektmi alebo vznikli na základe skúseností, štúdií alebo výskumu projektantov pracujúcich v danej organizácii. Tieto informácie sa tiež nazývajú znalosti, ktoré sa snaží manažment projektu organizovať pomocou manažmentu znalostí. V tomto článku sa budeme zaoberať manažmentom znalostí v distribuovaných projektoch, t.j. v takých projektoch, z ktorých je každý jeden vyvíjaný súčasne na viacerých miestach. Tu si opíšeme základné typy znalostí a spôsoby ich získavania, uchovávania a identifikácie ich zdrojov, a dva základne prístupy manažmentu znalostí: kodifikácia a personalizácia. Na záver si na základe zhodnotenia výhod a obmedzení oboch modelov, predložíme návrh hybridného modelu.

Abstrakt. Open Source je slovné spojenie v poslednej dobe často vystupujúce do popredia. V tejto eseji sa budem venovať spôsobom a metódam, akými je Open Source softvér vyvíjaný, pričom dôraz bude kladený na slovo metódy, nie Open Source. Tieto metódy sú s drobnými úpravami dobre využiteľné aj pri tzv. komerčnom vývoji softvéru, nakoľko nie sú kladené žiadne obmedzenia na účel a cenu vyvíjaného softvéru. Vyjadrím sa k aplikovateľnosti Open Source metód mimo Open Source komunity, pre ktorú sú typické isté odlišnosti od komunity bežných vývojárov, ako napríklad silná vnútorná motivácia prameniaca napríklad z použiteľnosti výsledného produktu pre samotného vývojára. Vyjadrím sa k zásadám Open Source, k vývoju a riadeniu Open Source projektov.

Abstrakt. Outsourcovanie je v súčasnej dobe často skloňovaný pojem. Je to obsiahly problém, ktorý som v mojom prípade zúžil na samotný postup alebo praktiky, vedúce k úspešnému zvládnutiu a zavŕšeniu projektu.
Základná otázka je jasná. Outsourcovať? Odpoveď na to nie je až taká jednoznačná. Outsourcovať v prípade, že to má priniesť pozitívny výsledok, čo môže byť zníženie výdavkov ako aj zvýšenie kvality. S týmto problémom úzko súvisí otázka čo outsourcovať. Určite to nesmie byť predmet záujmu spoločnosti. A keďže outsourcovanie je vzťah medzi dvoma partnermi, je nevyhnutné vytvoriť podmienky vyhovujúce obom stranám, čo bezprostredne vedie k vytvoreniu zmluvného vzťahu. Na jeho základe je treba vytvoriť spôsob kontroly a merania kvality spolupráce, ktorej pomáha motivácia. Tá spravidla býva finančná, ale vyplýva zo vzťahu medzi partnermi. Tento vzťah môže byť ponímaný aj ako možnosť k výmene technológií a technologických znalostí medzi partnermi. Bezpochyby, dôležitým prvkom je vedenie a upevňovanie dialógu a vzťahu ku zákazníkovi, pre ktorého je produkt vyvíjaný.

Abstrakt. Účelom tejto eseje je priblížiť a vysvetliť potencionálnemu čitateľovi, čo sa vlastne skrýva pod pojmom Open Source Software (OSS) - voľne sa dá tento názov preložiť ako voľne šíriteľný softvér. Opíšem jeho vznik, trochu málo priblížim tvorcov tohto softvéru, zodpovedám otázku prečo vlastne ľudia investujú svoj voľný čas na jeho tvorbu.
Keďže OSS je programový produkt oddelený od licenciovaného, riadi sa vlastnými pravidlami pre voľne šíriteľný softvér (Open Source Definition), najznámejšie štandardy sú GNU General Public License (GPL) a Berkeley Software Distribution (BSD).Vyzdvihnem jeho výhody oproti Closed Source Software (CSS) - voľný preklad komerčný softvér - a pravdaže neobídem ani jeho nevýhody v druhej časti eseje.
Rozmer zdrojového kódu poskytuje užitočnú informáciu pre stanovenie jeho kvality, pričom hlavnými charakteristikami kvality sú napríklad udržovateľnosť, spoľahlivosť, rozšíriteľnosť a prenosnosť. Medzi hlavné požiadavky používateľov softvéru patrí jeho kvalita a už spomenuté charakteristiky kvality, preto sa touto témou bude zaoberať posledná časť.

Abstrakt. V každom vývojovom tíme sa vytvorí, prípadne je pevne stanovená nejaká hierarchická štruktúra. Aká je však vnútorná organizácia práce v tímoch? Na čo sa v danom tíme kladie najväčší dôraz, keď chce tím dosiahnuť svoj stanovený cieľ? Vo všeobecnosti je možné určiť tri základné modely (prototypy) organizácie tímov a to sekvenčný model, skupinový model a sieťový model. V praxi sa samozrejme mnohokrát používa ešte aj hybridný prístup zložený z viacerých modelov. Tieto jednotlivé modely sa vo viacerých charakteristikách diametrálne odlišujú. Každý z modelov kladie najväčší dôraz na úplne iné veci. Je možné badať rôzny prístup k členom daného tímu z pohľadu ich individuality (osobnosti). V jednotlivých prototypoch je aj iná úroveň dôvery voči čiastkovým výsledkom, ktoré členovia tímu prezentujú. Taktiež sa líšia v rôznych spôsoboch a formách komunikácie, ktoré preferujú. Z pohľadu manažmentu v softvérovom inžinierstve je tiež zaujímavé, aké typy ľudí sú vhodné na prácu v jednotlivých modeloch organizácie tímov, akých ľudí treba hľadať pri zostavovaní svojho tímu.

Abstrakt. Ako sa ukázalo, stupeň neúspechu softvérových projektov je v súčasnosti enormne vysoký a dopady na globálnu ekonomiku sú o to väčšie, čím viac spoločností sa púšťa do vývoja softvéru. Väčšina softvérových projektov sa vyvíja v nepredvídateľnom prostredí plnom nástrah, ktoré nepriaznivo vplývajú na výsledok projektu. Prieskumy zamerané na zhodnotenie projektov po ich ukončení však odhalili, že mnoho z týchto problémov bolo v skutočnosti možné predvídať. Táto práca sa preto zameriava na najzávažnejšie riziká, ktoré môžu nastať počas vývoja softvéru, a pravidlá používané na zníženie výskytu týchto rizík či minimalizáciu ich dopadu. Vychádzajúc zo skúseností projekto-vých manažérov sa budem snažiť načrtnúť ich pohľad na svet rizík softvérových projektov.

Abstrakt. Softvérový priemysel je jedným z najrýchlejšie sa rozvíjajúcich odvetví. S týmto rozvojom je spojené aj vysoké riziko neúspechu, ak proces vývoja softvéru nie je riadený a nesústreďuje sa na skutočné riziká, ktoré ho ohrozujú. V tejto eseji sa budem venovať základnému zdroju neúspechu, ktorý vychádza z mylnej predstavy, že softvér je iba produkt. Ďalej sa budem venovať softvéru chápanému ako médium na uchovávaniu vedomostí, pričom najprv sa pozriem, aké je postavenie softvéru v rámci ostatných médií na uchovávanie vedomostí a neskôr uvediem, aký vplyv má tento postoj na proces vývoja softvéru. V druhej časti eseje budem rozoberať faktory, ktoré podľa výskumu v rôznych organizáciách najviac ohrozujú tento proces.

Abstrakt. Patenty sú regulačným nástrojom, ktorého účelom je motivácia k efektívnemu rozvoju technických inovácií. Odvetvie vývoja softvéru má, čo sa týka patentovej ochrany určité špecifiká. Nové myšlienky sa objavujú častejšie a rýchlejšie ako v iných odvetviach. Typický program obsahuje stovky až tisíce patentovateľných miest, vzniká problém, akú časť softvéru patentovať. Problémom je aj fakt, že vývoj softvéru je väčšinou založený na zdieľaní myšlienok. Často krát sa znovupoužívajú už aplikované myšlienky, ktoré sa vylepšujú a rozvíjajú. Práve v oblasti softvéru je možné, že patentová ochrana (na dlhé obdobie zabraňujúca tejto znovupoužiteľnosti) má nepriaznivý vplyv na inováciu. Nezanedbateľné ťažkosti spôsobujú firmy, snažiace sa špekuláciami ťažiť z patentovania všeobecných princípov a riešení, ktorých nulový prínos pre spoločnosť, neinovatívnosť a hlavne triviálnosť riešenia je zjavná. V eseji sa venujem možným riešeniam načrtnutých problémov. Analyzujem názory na túto problematiku od sprísnenia podmienok patentovania až po hlasy väčšiny odborníkov IT volajúce po úplnom zrušení softvérových patentov.

Abstrakt. Vzorovým príkladom svetovej globalizácie je softvérový outsourcing. Dôvody pre ktoré softvérové firmy využívajú outsourcing sú najmä zníženie nákladov nasledované nedostatkom kvalifikovanej pracovnej sily, vyššia kvalita a rýchlejšie nasadzovanie produktov na trh. Hlavne kvôli kultúrnym odlišnostiam medzi krajinou odkiaľ pochádza zákazník a krajinou, v ktorej sídli poskytovateľ outsourcingových služieb, vznikajú zvýšené nároky na manažment procesu vývoja softvéru. V tejto práci prezentujem názory a štúdie o tom, prečo sa firmy rozhodujú pre outsourcing a prečo niektoré nie. Pokúsim vysvetliť, aké dôvody viedlo firmy k rozhodnutiu využiť outsourcing.

Abstrakt. Výkonnosť zamestnancov je ovplyvňovaná rôznymi činiteľmi. Jedným z kľúčových činiteľov je stres. Účinkom jeho negatívneho pôsobenia sú vystavení aj programátori, návrhári, analytici, vedúci tímov a vo všeobecnosti všetci pracovníci zamestnaní v oblasti tvorby informačných systémov. Keďže stres môže spôsobiť zníženie efektívnosti zamestnancov alebo až zlyhanie projektov, je nutné venovať mu pozornosť, zistiť čo ho spôsobuje a vykonať nápravné kroky. Elimináciou prípadného stresu a stimulovaním atmosféry vo firme môže byť efektivita zvyšovaná, a preto je táto téma dôležitá nielen pre softvérové firmy. V eseji sú rozdelené príčiny stresu do viacerých skupín. V každej skupine je najčastejšia príčina stresu identifikovaná a je navrhnutý aspoň jeden spôsob jej eliminácie, ktorý môže byť zamestnávateľom vykonaný. Esej sa tiež venuje vzťahom medzi rôznymi príčinami stresu a inými súvisiacimi okolnosťami.

Abstrakt. Esej pojednáva o psychologických aspektoch v softvérovom procese pričom sa zameriava najmä na fázu verifikácie a validácie. Na odhaľovanie chýb a zlyhaní možno pozerať napríklad z pohľadu dynamiky, automatizácie, testujúceho subjektu či návykov používateľov i testerov. Jednou z kľúčových úloh testovania je aj zistenie, či boli splnené nefunkcionálne požiadavky. Testovanie a prehliadky (dynamika) napriek tomu, že predstavujú odlišné techniky, nemožno od seba odlúčiť. Esej sa ďalej venuje porovnaniu automatizovaného resp. manuálneho prístupu k testovaniu i porovnaniu pohľadov tvorcu kódu a používateľa. Sú spomenuté ich rôzne návyky, ktoré majú vplyv na výslednú kvalitu resp. výslednú spokojnosť používateľa. Pre účely manažovania projektov je potrebné zohľadniť tieto psychologické aspekty pri plánovaní (testovania) i pri z toho vyplývajúcich odhadoch nákladov. Nemenej dôležitým je aj riziko vzniku konfliktov medzi testermi a programátormi, ktoré treba efektívne riešiť alebo sa mu pokúsiť predchádzať.

Abstrakt. Charakter dodávania softvéru sa môže meniť v závislosti od konkrétnej paradigmy vývoja a dodávania produktu. V tomto článku sa zameriame hlavne na povahu vzťahov medzi zákazníkom a dodávateľom softvéru a na meniacu sa úlohu zákazníka a dodávateľa v konkrétnych paradigmách ako napríklad commercial off-the-shelf, component-based software engineering a software service engineering. Charakter a povaha vzťahov medzi partnermi je v jednotlivých modeloch rôzna a môže hrať kľúčovú úlohu pri napľňaní požadovaného cieľa, alebo úlohy. Každý zo spomínaných prístupov má samozrejme svoje výhody, nevýhody a obmedzenia, ktoré budú analyzované. Informácie v takejto podobe môžu byť užitočné pri rozhodovaní, ktorú z uvedených paradigiem použiť pri snahe o úspešné vyriešenie projektu.

Abstrakt. Na produktivitu softvérových tímov má vplyv viacero faktorov. Jedným z najdôležitejších je správna koordinácia členov tímu a delenie si prác na projekte. Poznáme tri základné prístupy ku problému koordinácie, z ktorých každý je vhodný pre iný typ projektu a štruktúru tímu. Big Bang prístup odkladá koordináciu až do záverečnej fázy, zatiaľ čo prístup s periodickou synchronizáciou má pevne stanovené termíny koordinačných stretnutí. Tretím prístupom je koordinácia riadená výskytom problémov. Medzi faktormi ovplyvňujúcimi kvalitu koordinačného procesu sú charakteristika projektu, schopnosti tímu, dostupná technológia a nástroje a v neposlednom rade medziľudské vzťahy v tíme, ktoré zásadným spôsobom ovplyvňujú komunikáciu medzi spolupracovníkmi. Dobrá komunikácia medzi členmi tímu je kľúčovým faktorom pri koordinácii. Jej dôležitosť si v čoraz väčšej miere uvedomujú všetky spoločnosti vyvíjajúce softvér a podporujú komunikáciu vo vnútri tímu aktivitami, ktoré s projektom zdanlivo nesúvisia (napríklad spoločné športové aktivity). Vplyv týchto aktivít sa ale veľmi pozitívne prejaví pri diskusiách o problémoch a prispeje k tvorivej atmosfére v tíme. Rôzne druhy týchto takzvaných "team building activities", ako aj spôsoby ich bezproblémového plánovania sú popísané v tejto práci.