Abstrakt. Esej pojednáva o jednotlivých etapách vývoja tímu riešiaceho softvérový projekt. Snaží sa analyzovať tento vývoj z pohľadu manažmentu a identifikovať niektoré aspekty tohto vývoja. Pojednáva o možných dopadoch rozhodnutí manažmentu v jednotlivých fázach na vývoj tímu. Autor sa zaoberá najmä identifikáciou jednotlivých etáp vývoja softvérového tímu, analyzuje aspekty zostavovania tímu vzhľadom na odborné a charakterové vlastnosti jeho potenciálnych členov, ako aj vzhľadom na veľkosť tímu. Ďalej sa autor zaoberá potrebou vybudovať dobrú komunikačnú štruktúru v rámci tímu, problematikou motivácie členov tímu, ako aj budovania dobrých medziľudských vzťahov. Nakoniec sa autor zaoberá problematikou organizačných zmien v rámci tímu.

Abstrakt. Každý softvér sa počas svojho vývoja musí vysporiadať so vznikom chýb. Vznik chýb je neodvratný pri každej ľudskej činnosti, preto je nutné zaoberať sa problémom vzniku chýb a snažiť sa o ich odstránenie. Tento dokument sa zaoberá rozborom kritických miest softvéru, pri ktorých často vznikajú chyby. Spomína aj rozšírenia softvéru ako systém pluginov a podpora skriptovania, ktoré môžu byť zdrojom chýb, prípadne môžu tvoriť bezpečnostné riziko. Ďalej sa zaoberá možnosťami manažmentu ako predchádzať vzniku chýb a ako zabezpečiť úspešnosť softvérového projektu. Na záver článok diskutuje súčasný stav v zodpovednosti za chyby a škody spôsobené chybami softvéru. Uvádza argumenty za aj proti zavedeniu zodpovednosti za chyby.

Abstrakt. Hlavnou výhodou tímu oproti jednotlivcovi je rôznorodosť zdrojov, poznatkov a myšlienok. Nevýhodou tejto rôznorodosti je pravidelný výskyt konfliktov medzi členmi tímu. Aby sa zamedzilo eskalácii konfliktu, je potrebné riešiť hádky rýchlo a otvorene. Štatistiky hovoria, že väčšina manažérov si uvedomuje existenciu nezhôd v tíme a zároveň absolvovali tréning v oblasti riešenia medziľudských vzťahov no iba zriedkakedy dávajú vyššiu prioritu riešeniu týchto konfliktov. Preto je potrebné, aby jednotliví členovia tímu ovládali techniky pre riešenie konfliktov a priamo ich aplikovali medzi sebou. V tomto článku sú objasnené príčiny, priebeh a niektoré zo spôsobov riešenia konfliktov v tímoch.

Abstrakt. Už od počiatku bol softvérový priemysel v kríze. Softvér bol a stále je nespoľahlivý, dodávaný po stanovených termínoch, pružne nereagujúci na meniace sa potreby, neefektívny a drahý. Dokonca aj dnes, problémy so softvérovými systémami sú bežné a často publikované. Hlavným dôvodom je, že koordinácia aktivít sa stáva komplikovanou s rozsahom a narastajúcou zložitosťou projektu a preto sa problémy pochopiteľne častejšie vyskytujú pri vývojoch rozsiahlych softvérových systémov.

Preskúmame úlohu formálnej a neformálnej komunikácie pri koordinovaní práce na softvérových projektoch. Väčšina súčasných podporných nástrojov pre koordináciu používa procedúry formálnej komunikácie, ale ukazuje sa potreba zapojenia aj procedúr neformálnej komunikácie.

Existuje niekoľko prístupov koordinácie problémov pri vývoji softvérových systémov. Opíšeme tri súčasné prístupy, ktoré sa používajú: veľký tresk, častá integrácia a periodická synchronizácia, a chybami poháňaná koordinácia. Prístupy sa líšia v rozdielnom načasovaní a intenzite koordinácie. Taktiež sa budeme venovať faktorom, ktoré ovplyvňujú intenzitu koordinácie.

Záver eseje patrí motivácií ako ďalšiemu prostriedku na zvýšenie produktivity

Abstrakt. Odhadovanie softvérových projektov je oblasť, kde je softvérové inžinierstvo stále veľmi neisté. Pri veľkých projektoch je skôr výnimkou, ak sa odhad čo len približne podobá výslednému úsiliu. Pri menších projektoch je situácia lepšia. V práci uvádzam niektoré možnosti zlepšenia odhadovania pre projekty, ktorých členmi sú aj menej skúsení riešitelia. Ide o použitie kontrolného zoznamu, ktorý slúži na pripomenutie dôležitých častí produktu a aktivít projektu, aby neboli vynechané pri tvorbe odhadu rozsahu a potrebného úsilia. Ako druhú spomeniem techniku Deplhi, ktorej cieľom je uľahčiť zdieľanie znalostí medzi členmi tímu, a tak prispieť ku kvalitnejšiemu odhadu.

Abstrakt. Komunikácia vnútri lokalizovaných, ako aj distribuovaných tímov je veľmi dôležitou súčasťou ich manažmentu a jedným z kľúčových faktorov ich úspechu pri tvorbe softvérových produktov. Tento dokument sa zaoberá časťou plánovania komunikácie a distribúcie informácií, pričom hlavný dôraz kladie na definovanie vhodných spôsobov komunikácie pre jednotlivé úlohy, činnosti a role v tímoch. Dokument približuje teóriu mediálnej bohatosti a jej praktické testy, ktoré boli v posledných rokoch uskutočnené a ktoré potvrdili jej správnosť. Tiež ukazuje, že distribuované tímy sú schopné vykonávať zadané úlohy s aspoň takým dobrým výsledkom ako tímy lokalizované, a teda že výhoda osobnej komunikácie sa s postupným vytváraním a zlepšovaním jednotlivých foriem komunikácie a hlavne s ich úspešným a efektívnym ovládnutím členmi tímu, stiera.

Abstrakt. V tejto práci sa venujem hlavne riadeniu a plánovaniu kvality v životnom cykle softvéru. Na začiatku sa pokúsim vysvetliť, čo je to vlastne kvalita a aký rôzny význam má pre zákazníka a výrobcu. Ďalej rozoberiem jej význam v postupe času. V riadení sa zameriam na základe predstavy TQA na dve stratégie riadenia, a to SQA pre veľké tímy a Podporný tím pre malé tímy a opíšem ich výhody i nevýhody. V plánovaní sa zase zameriam na dôležitosť plánovania a vyzdvihnem hlavne prvé fázy projektu.

Abstrakt. Vplyv softvérových systémov na náš život je obrovský a rastie každým dňom. Softvér sa stal nevyhnutným pre fungovanie ľudskej spoločnosti. Softvérové systémy patria k najzložitejším výtvorom ľudstva vôbec, čo spôsobuje problémy pri ich tvorbe a prevádzke. Vysoká zložitosť softvérových systémov viedla ku vzniku veľkého množstva prístupov a metód, ktoré sa snažili o systematický prístup k tvorbe softvéru. Napriek tomu len málo systémov bolo dodaných do prevádzky za vopred dohodnutých podmienok. V situácii, keď sa zvyšuje tlak, ktorý núti vytvárať kvalitný softvér za menej peňazí a za kratší čas, vznikli nové, tzv. agilné metódy. Agilné metódy vznikli zo skorších prístupov k rýchlemu vývoju aplikácií (RAD), ktoré rozpoznali, že spomedzi obmedzení projektu tvorených časom, cenou a rozsahom má práve rozsah najvyššiu mieru neurčitosti. Preto sa agilné metódy, na rozdiel od tých tradičných, nepokúšajú určiť rozsah projektu v úvodných fázach, ale pracujú s používateľskými požiadavkami oveľa flexibilnejšie. Tento príspevok rozoberá nové zaujímavé postupy na určovanie rozsahu projektu pri použití agilných metód vývoja softvéru.

Abstrakt. Pri plánovaní softvérových projektov ako veční optimisti často predpokladáme, že všetko bude prebiehať podľa navrhnutého plánu. Opačný pohľad ponúka otázku: Prečo vytvárať podrobné plány, keď aj tak nemôžeme predpovedať všetky udalosti? Uvedené prístupy mnohokrát vedú ku vzniku neočakávaných udalostí. Dôsledky týchto udalostí sú väčšinou nežiaduce a prispievajú k zlyhaniu softvérových projektov. Prieskumy však poukazujú na to, že veľa neočakávaných udalostí je predvídateľných, a preto sa manažment rizík stáva neoddeliteľnou súčasťou úloh manažmentu. Práca opisuje základné princípy manažmentu rizík, tiež sa snaží poskytnúť odpovede na dve základné otázky: Aké faktory vnímajú softvéroví projektoví manažéri ako riziká, a ktoré považujú za najdôležitejšie? Ako môžeme kategorizovať riziká?

Abstrakt. Počas celého trvania vývoja softvérového systému dochádza ku komunikácii medzi zákazníkom a vývojárom. Podmienkou úspešnej špecifikácie požiadaviek, návrhu systému, predvádzania prototypu, či testovania je dobrý a fungujúci vzťah medzi zákazníkom a vývojárom. Tvorba softvérového systému nie je jednoduchá úloha, preto by sa obidve strany mali snažiť spraviť čo najviac pre úspešnú spoluprácu. Úlohou zákazníka je čo najlepšie, najpresnejšie a najzrozumiteľnejšie vysvetliť vývojárovi svoje požiadavky na softvérový systém. Na druhej strane, vývojár musí vedieť počúvať a pochopiť, čo sa mu zákazník snaží vysvetliť. Na základe získaných informácií musí vývojár navrhnúť softvérový systém, ktorý bude vyhovovať požiadavkám používateľa. V tejto práci sa snažíme zachytiť základné aspekty vo vzťahu zákazník a vývojár pri tvorbe softvérového systému. Najprv oboznámime čitateľa s problémovým prostredím. Potom uvedieme hlavné prekážky a problémy vo vzťahu zákazníka a vývojára. V poslednej kapitole sa venujeme rôznym metódam a nástrojom používaným pri tvorbe softvérového systému, so zameraním na zákazníka a vývojára.