Abstrakty vybraných príncípov softvérového inžinierstva (153-201)

Keď bol stanovený reálny harmonogram a boli alokované príslušné zdroje, všetky zúčastnené strany musia veriť v realizáciu harmonogramu. Inžinieri nebudú úspešní pri vykonávaní bodov harmonogramu, ak sami neveria v jeho reálnosť. Pravdepodobnosť úspechu je viac vecou viery v harmonogram, ako jeho realizovatelnosť.

Najlepšie je dať inžinierom možnosť vyrobiť si harmonogram. Nanešťastie, toto nie je vždy možné. Druhou najlepšou cestou je zapojiť inžinierov do procesu vytvárania harmonogramu s vysokou mierou zodpovednosti za funkčnosť, vytvorenie a reálnosť. Len malo inžinierov by pre zastaveniu projektu chcelo stratiť prácu. Radšej sa dohodnu na harmonograme.

Predpokladajme, že vaša firma na poslednom predstavení zozbierala veľké množstvo údajov spísaných na papieri. Predpokladajme, že ste na základe nazbieraných údajov vybrali jeden z mnohých modelov odhadovania ceny a prispôsobili ho možnostiam vašej firmy. Ďalej predpokladajme, že ste manažérom celého projektu. Máte teda nový projekt a chcete naň aplikovať váš model. Model hovorí, že softvér bude stáť 1 milión. Čo to ale znamená? Určite to neznamená, že váš softvér bude v skutočnosti stáť 1 milión. Na toto tvrdenie sú tri dôvody: (1) Vy, (2) predpoklady, (3) pravdepodobnosť. Ako prvé ste Vy: Vaše schopnosti a vedomosti ako viesť daný projekt budú mať hlavný efekt na celkový výsledok. Napríklad, počas 5 sekúnd dokážete zničiť morálku celého tímu, ktorú ste mohli budovať celý rok.

Po druhé: Niektoré predpoklady, ktoré ste stanovili za účelom určenia počiatočného odhadu ceny sa nemusia splniť presne podľa vášho očakávania. Napríklad, čo ak vám bolo pridelených menej kvalifikovaných ľudí? Čo ak sa zmenili požiadavky? Čo ak nečakane ochorie vaša kľúčová osoba? Čo ak nečakane odíde polovica vašich pracovných staníc, v momente, keď ich najviac potrebujete? Po tretie: Fakt, že odhad je iba vrcholom v rozdelení pravdepodobnosti. Ak vám poviem, že hodím 100-krát mincou a spýtam sa vás, koľko krát padne hlava, pravdepodobne odpoviete, že 50-krát. Znamená to však, že hlava v skutočnosti padne 50-krát? Samozrejme, že nie, a boli by ste veľmi prekvapení, keby naozaj padla 50-krát.

Plány projektu sa obyčajne určujú na začiatku projektu. V týchto plánoch sú zahrnuté termíny odovzdania jednotlivých medzistupňov projektu, ako aj konečný termín odovzdania projektu. Po ukončení každej fázy projektu je nutné navrhnutý časový plán znovu prehodnotiť. Ak sa už plán projektu prehodnotí, len zriedkavo sa stáva, že by sa vracalo k pôvodnému plánu. Z toho vyplýva, že odovzdanie projektu, ktorý sa vo fáze návrhu dizajnu oneskoril o jeden mesiac, sa celkovo oneskorí minimálne o jeden mesiac. Okrem toho aj väčšina prípadov povolávania a odvolávania nových ľudí do projektu sposobí tiež časový sklz. (Koniec koncov, nechceme, aby sme sklamali zákazníka práve v tejto fáze, všakže?). Teda každý medzistupeň, ktorý nestihneme odovzdať načas sposobí, že sa zredukuje čas vyhradený na testovanie produktu.
Nakoniec sa stáva nevyhnutnou jedna z týchto dvoch situácií:

1. projekt je síce ukončený, ale nezodpovedá kvalitou
2. zákazník je v priebehu projektu oboznámený s veľkým časovým sklzom v časovom pláne projektu.

Obe tieto situácie sú neprijateľné. Ak ste manažér, tak vy zodpovedáte za ochranu pred takýmito katastrofami. Okrem toho sa staráte aj o vytvorenie funkčného vzťahu medzi zákazníkom a manažmentom projektu. Informovaním o každej možnej zmene v časovom pláne (špeciálne o sklze) a prerokúvanie možných alternatívnych stratégií so zákazníkom možte predísť týmto zmenáam a hlavne sklzom v časovom pláne. Len a len skorým zásahom a spoluúčasťou všetkých zainteresovaných možete predísť zvyšovaniu časového sklzu.

Za predpokladu, že morálka nebola znížená, členovia projektu, vnímaného ako nepatrne za časovým rozpisom, budú nasmerovaní pracovať veľmi usilovne, aby dobehli plán, teda dochádza k zvýšeniu produktivity práce. Podobne členovia projektu, ktorý je vnímaný ako mierne dopredu pred rozvrhom, si často vyberú voľné dni, pracujú menej hodín, čítajú svoju poštu dlhšie, a poľavujú rôznymi inými spôsobmi, teda dochádza k zníženiu produktivity práce. Takže, samotný odhad ceny (nákladov) ovplyvní výsledok projektu. Akýkoľvek špecifický projekt môže spotrebovať menej zdrojov, ak je nepatrne podhodnotený, ako keby bol trochu nadhodnotený. Ale buďte opatrní ! Ak členovia projektu veria, že plán je príliš podhodnotený, morálka a produktivita práce sa zníži.

Pri plánovaní softvérového projektu nesmieme byť príliš optimistickí ani pesimistickí v časovom harmonograme. Obidve vedie k zvýšeným nákladom. Nesmieme postaviť časový harmonogram tak, aby ľudia pracujúci na projekte boli zavalení prácou na 12 hodín denne. Toto nadsadené tempo sú schopní vydržať ľudia pracujúci na projekte týždeň dva. Potom na ľudí padne únava, v projekte sa vyskytnú zbytočné chyby, ku ktorým sa budeme musieť vrátiť a čo je najdôležitejšie začnú nám stúpať finančné náklady. Pracovníci sú vystresovaní, demotivovaní, prestavajú stíhať časový harmonogram. Začne upadať morálka v tíme, odpor k vedeniu. Projekt može byť akokoľvek dobre premyslený, ale ak máme stiesnený, nevhodný časový plán, tak nám zahubí náš projekt bez ohľadu na kvalitu ľudí alebo dostupnosť nástrojov, jazykov a konania.

Princíp sa zaoberá plánom a jeho aktualizáciou, ktorá by mala byť urobená vždy, keď sa zmenia podmienky, za kto-rých platil predchádzajúci plán. Ak neexistuje nijaký plán, je to dokonca lepšie z hľadiska správania sa ľudí zúčastnených na projekte, pretože vtedy vieme, že projekt nie je riadený a podľa toho sa aj správame. Naproti tomu, ak je projekt riadený, ale plán sa neaktualizuje podľa meniacich sa podmienok, môže to viesť k neúspechu vo výsledku, pretože sme si mysleli, že je všetko v poriadku - "Však ideme podľa plánu...".

Dobre napísaný plán by mal obsahovať zoznam rôznych rizikových situácií, varovných znakov, keď sa riziková situácia stáva hrozbou, a zoznam plánov, ako postupovať pri redukcii hrozieb. Ak sa v procese vývoja systému riziková situácia stane hrozbou, použije sa jeden z plánov a celkový plán sa aktualizuje takým spôsobom, aby sa hrozba zredukovala na minimum. Skutočnou výzvou však je, ak nastane situácia, ktorú aj dobre napísaný plán nepredpokladal. Vtedy je nutné zvyšok projektu preplánovať ako celok, t.j. treba vyjsť z nových predpokladov, identifikovať nové riziká, navrhnúť nové plány ako reakciu na potenciálne hrozby, vytvoriť nové rozvrhy činností, zakomponovať nové kontrolné body, zabezpečiť ľudí, ...

Pri žiadnom softvérovom projekte nie je možné predpovedať čo sa pokazí. Avšak niečo sa isto pokazí. Ešte v raných štádiách plánovania načrtnite najväčšie riziká spojené s vaším projektom. Pre každé z nich vyčíslite pravdepodobnosť toho, že sa potenciálne riziko stane realitou a rozsah škôd, ktoré vás v tomto prípade čakajú. Súčin týchto dvoch čísel predstavuje vaše skutočné vystavenie sa riziku.

Na začiatku práce na projekte vytvorte strom rozhodovania, ktorý načrtne všetko, čo možno spraviť pre zmenšenie vystavenia sa riziku. Na základe toho buď začnite pracovať na výsledkoch, alebo vytvorte plány na vykonanie rôznych akcií v tých bodoch projektu, v ktorých vystavenie sa riziku prekračuje vami akceptovateľnú hranicu. (Samozrejme tiež špecifikujte, ako rozoznáte takúto situáciu, aby ste mohli vykonať potrebné kroky skôr než je neskoro.)

Iste ste už počuli názory "metodických zanietencov" ktorí hovoria, "ak použijete moju metódu, vyrieši sa väčšina vašich problémov". Aj keď veľa metód bolo objektom množstva diskusií, väčšina používaných metód medzi rokmi 1970 a 1980 obsahovala v názvoch slovo "štrukturované" a zase iné v 80-tych a 90-tych rokoch slovo "objektové". Hoci obe tieto vlny prinášajú veľké výhody, ako napr. kvalitné softvérové vyvojové konštrukcie a postupy, ani oni nie sú liekom na všetko. Organizácie, ktoré boli skutočne dobré vo vývoji softvéru so "štrukturovanými metódami" sú dobré aj teraz, keď sa používajú "objektovo-orientované" metódy. Organizácie so slabými výsledkami budú mať slabé výsledky aj s použítím najmodernejších metód. Ako manažér si dajte pozor pred tzv. "poradcami", ktorí Vám sľúbia zvýšenie kvality alebo produktivity založené na nových metódach. Nič nie je na tom zlé, adaptovať sa na novú metódu, ale ak organizácia bola neúspešná v minulosti (či už v produktivite alebo kvalite), pokúste sa odhaliť zdroj týchto neúspechov predtým než ich začnete riešiť inými metódami.

V oblasti informačných technológií podobne ako vo väčšine ďaľších odvetví bohužiaľ platí to staré známe "Peniaze vládnu svetom". Nikoho nezaujíma, ako kvalitný produkt vlastne dostane, ale ako rýchlo (a tiež ako veľmi danému vedúcemu pracovníkovi rozhodujúcemu o verejnej súťaži oťažie vrecko :-((( ). Načo vlastne by mal systém fungovať tak ako chce zákazník, keď mu môžeme ešte desať rokov každý mesiac posielať nový patch... A tak v poslednej dobe už nepočujeme nič iné, ako "ActiveX komponenty vás vynesú na absolútny vrchol (produktivity) !", "Visual Basic, to jediné pravé orechové pre vývoj vašich aplikácií! Vašu aplikáciu napíšete za pať sekúnd!!! Štyri a pol kliku ste od vašeho vytúženého najlepšieho informačného systému!".

Jednotlivé technológie sa predbiehajú v údajoch o zlepšení produktivity tímu. A bohužiaľ často sa manažéri riadia práve týmito "reklamnými frázami". V skutočnosti rast produktivity je možný v omnoho menšej miere (cca. 3-5% na rok podľa 1.1). Samozrejme dosiahnutie "zníženia" nákladov je skutočne "triviálna" operácia - zo životného cyklu SW postupne odstránime "nepotrebné" etapy špecifikácie, analýzy & designu... Avšak asi veľmi málo ľudí si uvedomuje, že takéto riešenie je príliš krátkozraké, a že v dohľadnom čase sa ušetrené náklady vrátia späť ako bumerang v omnoho vyššej miere. Bohužiaľ nové prostriedky tvorby aplikácií priamo nabádajú k nepremyslenej stavbe SW. "Vizuálne" pomôcky zvládne aj laik, nepotrebuje k tomu štúdium "zbytočností" ako Softvérového Inžinierstva a podobne. A je mi smutno keď vidím, koľko tzv. programátorov sú iba úbohí amatéri, ktorí si myslia, že naklikať jeden dialóg je také isté ako napísať komplexný informačný systém firmy.

Nechcem tým povedať, že nové technológie neprispievajú k zvýšeniu rýchlosti vytvorenia SW systému. Naopak, v dnešnej dobe sú podporované prakticky všetky etapy životného cyklu systému. Avšak to najpodstatnejšie - ľudský vklad - nemôže nahradiť žiadna technológia. Ľudský rozum tvorí a vždy tvoriť bude najpodstatnejšiu KREATÍVNU zložku každého vývoja, a pri zvyšovaní produktivity by sme sa mali hlavne orientovať na lepšie využitie tejto, často nedoceňovanej, zložky.

Bez detailného plánu nie je možné manažovať projekt. Plán treba aktualizovať podľa potreby. Keď už máme aktuálny plán, projekt treba manažovať podľa neho. Pri oznamovaní progresu treba hlásiť iba odchýlky od plánu. Správy o tom, čo sa všetko urobilo podľa plánu sú mrhanie časom a zdrojmi — veď každý sa o tom dočíta v pláne. Lepšie sú správy typu: „Všetko ide podľa plánu okrem…“ Takto sa môžeme lepšie sústrediť na riešenie skutočných problémov.

V roku 1984, trinásť hlavných leteckých spoločností predpovedalo, že 50 percent vývoja všetkého softvéru sa v roku 1988 bude stále diať na primitívnych termináloch. Po roku 1998 sa väčšina vývoja softvéru presunula z terminálov na osobné počítače a pracovné stanice. V tom istom odhade sa predpovedalo, že len 15 percent prostredí na vývoj softvéru bude používať Ethernet, a že bude len 27 percentný prienik UNIX-ových strojov do softvérových prostredí. Pravdu povediac tieto odhady boli úplne zlé. Ukazovatele ako rýchlosť hardvéru, schopnosti, štandardizácia a pomer výkon/cena prekročili odhady.

V roku 1984 trinásť hlavných leteckých spoločností predpovedalo, že v roku 1988 bude 46 percent vývoja softvéru realizovaného v jazyku ADA(a menej ako 4 percentá v C), a 54 percent ich softvéru bude znovupoužitého z predchádzajúcich aplikácií. Taktiež predpovedali, že v roku 1994 bude 70 percent vývoja softvéru podporovaného znalostnými systémami. Žiadna z týchto predpovedí sa nesplnila. Vo všetkých prípadoch bola technológia alebo nezrelá, alebo bola predbehnutá udalosťami.

Toto je tzv. „Titanic efekt" Geralda Weinberga. Človek by sa nemal nachádzať v takom stave duševnej spokojnosti, že všetko je pod kontrolou a aj pod kontrolou zostane. Prílišná dôvera je totiž často primárnym pôvodcom mnohých neštastí.

Napr. horolezec si povie: „Je to len malý kúsok, nepotrebujem istenie!", alebo cestovateľ: „Je to iba krátky výlet, nepotrebujem vodu!", alebo hráč pokra: „ Toto sú rozhodne karty, ktoré vyhrávajú!"

V niektorom z predchádzajúcich princípov sa hovorí o tom, že treba vopred vypracovať všetky možnosti a tento princíp hovorí o tom, že je treba tieto možnosti brať vážne a správať sa tak, že sa môžu v skutočnosti stať aj keď sú čo i len pramálo pravdepodobné. Najväčšie manažérske neštastia sa stanú skutočnostou práve vtedy, ak sa na ne zabudne, alebo ak sa snimi úmyselne neráta.

Každý projekt má svoje problémy. Princíp sa zaoberá zaznamenávaním, analyzovaním a učením sa z chýb v oblasti manažmentu a technických chýb vo všeobecnosti. Na konci každého projektu vedúci projektu zadá všetkým kľúčovým členom projektu úlohu analyzovať problémy ktoré sa vyskytli počas vývoja.

Napríklad : „Začali sme o desať dní neskôr integračné testovanie ako bolo naplánované, máme to povedať zákazníkovi." alebo „Začali sme robiť návrh oveľa skôr ako sme poznali väčšinu základných požiadaviek." alebo „Vedenie demotivovalo ľudí pracujúcich na projekte negatívnym vyhlásením v nevhodnom čase".

Všeobecná idea je taká, že treba zdokumentovať, zanalyzovať a poučiť sa z vecí, ktoré sa urobili zle. Takisto je nutne zaznamenať množinu opatrení, ktoré podľa vášho názoru treba urobiť aby sa predišlo daným chybám.

Zabezpečenie produktu (angl. product assurance) pozostáva zo štyroch častí: manažmentu konfigurácií softvéru, zabezpečenia kvality softvéru, verifikácie a validácie, a testovania. V praxi sa uznáva jedine dôležitosť testovania a vyhodnotenia, kým sa ostatné tri zložky pokladajú za luxus a uplatňujú sa iba pri väčších a drahších projektoch. Nasadenie týchto štyroch častí v rámci projektu podstatne zvyšuje pravdepodobnosť, že sa v plánovanom čase a v plánovanom rozpočte vytvorí produkt, ktorý uspokojí očakávania zákazníka. Podstata spočíva v ich správnom nasadení s ohľadom na veľkosť, tvar a obsah projektu.

Manažment konfigurácie softvéru (SCM) môže fungovať dôkladne len v prípade nezávislosti od manažmentu projektu. Projektový manažér môže byť často v dôsledku časovej tiesne zvádzaný vyhnúť sa práve tým kontrolám, ktoré umožňujú projektu prežiť dlhodobo. Napríklad, v období takejto časovej tiesne v rámci projektu môže nastať pokušenie, prijať novú verziu softvéru ako základ, aj keď nebol uchovaný žiadny doklad o tom, akú zmenu požiadaviek by to uspokojilo. Ak je SCM podriadený projektovému manažérovi, nemôže toho veľa urobiť, iba akceptovať to, čo projektový manažér určí. Ak sú vzájomne nezávislí, potom môže SCM uplatniť pravidlá, ktoré sú pre všetkých zainteresovaných najlepšie.

V mnohých softvérových podnikoch sú ľudia umiestňovaný do organizácií zaisťujúcich kvalitu výrobkov pri prvom zaradení, alebo vtedy, keď neukážu dostatočné schopnosti pri vytváraní softvéru. Zaisťovanie kvality však vyžaduje rovnakú úroveň inžinierskej kvality, ako návrh alebo samotné kódovanie. Ako alternatíva rotujú najlepší inžinierske talenty cez organizácie zaisťujúce kvalitu výrobkov. Dobrou vodiacou líniou je, ak každý excelentný inžinier strávi 6 mesiacov z 2-3 rokov v organizácii zaisťujúcej kvalitu výrobkov. Každý z nich očakáva, že sa počas ich návštevy zlepší činnosť organizácie. Takáto politika musí jasne stanoviť, že výmena pracovného miesta je odmenou za vynikajúce výkony.

Je množstvo medziproduktov pri vývoji softvéru :špecifikácie požiadavok, špecifikácie návrhu, kód, plány testov, plány manažmentu, používateľské príručky a pod. Každý z týchto produktov by mal dostať unikátne, jednoznačné pomenovanie, číslo verzie/revízie a dátum kedy bol vytvorený. Ak niektoré z nich obsahujú časti, ktoré sa môžu rozvíjať relatívne nezávisle ( napr. niektoré softvérové časti programu alebo individuálne plány v súhrnom dokumente plánovania testov ), tieto časti by tiež mali dostať unikátne meno, číslo verzie/revízie a dátum. "Zoznamy častí" by mali vymenovať všetky časti, s ktorou verziou/revíziou medziproduktu súvisia, takže viete, ktoré verzie a revízie ktorých častí zahŕňa špecifická verzia každého medziproduktu.

Okrem toho, finálny produkt dodaný zákazníkovi musí mať unikátne číslo verzie/revízie (produktu) a dátum. "Zoznam častí" obsahuje všetky medziprodukty (spolu s verziou a výstupným číslom), ktoré zahŕňa produkt.

Prvé pravidlo rozumných úprav sotwaru je uložiť si všetky časti.

Software už zo svojej podstaty je stále upravovaný. Keďže úpravy spôsobujú veľa chýb, je veľmi pravdepodobné že každá vykonaná zmena bude musieť byť zrušená. Jediný spôsob ako toto urobiť, je uistiť sa, že všetko je uložené pred vykonaním tejto zmeny. Úlohou "manažment softvérových konfigurácií" je práve uložiť kópie všetkého pred tým, ako sa vykonajú zmeny.

Dobre fungujúci proces riadenia zmien (pričom pod termínom "riadenie zmien" si netreba predstaviť predchádzanie zmenám) v projekte znamená, že aj ak to v danom okamihu mierne "skomplikuje život", vo všeobecnosti prinesie osoh všetkým zainteresovaným. Ak má zákazník možnosť priamej komunikácie s pracovníkmi zabezpečujúcimi jeho projekt, často sa snaží preskočiť proces riadenia zmien, a priamo osloviť daného jedinca s požiadavkou na vykonanie zmeny. Toto však nie je vhodný prístup k vykonávaniu zmien v projekte, pretože potom uvrhne celý projekt do hmly, stáva sa neprehľadným, špecifikácia požiadaviek sa stane nevyhovujúcou, čo okrem iného samozrejme zvýši cenu vývoja.

Každý používaný softvérový systém je “ohrozovaný” neustálymi požiadavkami na zmenu, súvisiacimi s požiadavkami používateľov na rozširovanie jeho funkčnosti. Týmto sa zvačšuje jeho zložitosť a narúša jeho vnútorná integrita a organizácia. Keďže zmeny spôsobujú nestabilnosť systému, všetky použiteľné softvérové systémy smerujú k zníženiu svojej spoľahlivosti a udržovateľnosti. Keďže proces “generovania” zmien je “nekonečný”, môže byť niekedy menej nákladné prepracovanie celého systému od začiatku. Môj príspevok sa zaoberá dvomi základnými otázkami a to “Aké sú možné príčiny tohto stavu a aké sú možné východiská resp. riešenia ?”, na základe ktorých boli identifikované nasledujúce základné príčiny - zákazník nikdy nevie, čo vlastne chce, zlé vymedzenie hraníc softvérového systému, zle definované podmienky pre akceptovanie zmien vo funkčnosti systému, neprofesionálny prístup ku zapracovaniu akceptovaných zmien a s nimi zviazané nasledujúce možné východiská - presne vymedzenie hraníc softvérového systému, jasne definované podmienky pre akceptovanie zmien vo funkčnosti systému, komplexné zhodnotenie dopadu zmien na celý systém a jeho následné testovanie.

Samozrejme, táto rada je aplikovateľná vo viacerých aspektoch života, ale je obzvlášť aplikovateľná na software. Podľa svojho pomenovania, software je považovaný za tvárny, ľahko modifikovateľný. Nemyslite si však, že je ľahké nájsť, alebo opraviť chybu v softwaru.

Predpokladajme, že udržujete systém. Testujete zdrojový kód komponentu. Pokúšate sa buď zdokonaliť ho, alebo nájsť príčinu chyby. Popri testovaní nájdete niečo, čo si myslíte že je iná chyba. Nepokúšajte sa ju opraviť. Je veľmi veľká pravdepodobnosť, že zavediete chybu, nie opravu (Princíp 190). Namiesto toho si zaznačte žiadosť o zmenu. Je nádejné, že kontrola kvality a s tým spojená technická prehliadka určí, či ide o chybu a aká má byť pridelená priorita jej opravy. (Princíp 175, 177, 178 a 179).

Ak zlyhá softvér, nemali by ste po zbežnej analýze opravovať niečo, o čom si možno iba myslíte, že je príčinou. Mali by ste sa snažiť plne porozumieť príčine zlyhania.

Predstavte si, že zisťujete príčinu zlyhania softvéru. Všimli ste si, že istý modul zakaždým odovzdáva hodnotu, ktorá je dvakrát väčšia, ako by mala byť. Rýchlym a zlým riešením by bolo jednoducho vydeliť návratovú hodnotu dvoma tesne pred odovzdaním. Takéto riešenie nie je vhodné z dvoch dôvodov: nemusí vždy pomôcť a okrem toho ponecháva program s dvoma chybami, ktoré sa navzájom rušia, čoho dôsledkom je veľmi zlé udržiavanie softvéru v budúcnosti. Ešte horšie riešenie by bolo vydeliť vrátenú hodnotu dvoma v module, ktorý ju používa. Toto riešenie si zachováva všetky nevýhody riešenia predchádzajúceho, naviac však všetky ďalšie moduly, ktoré budú volať chybný modul, obdržia zlú hodnotu. Správnym riešením je preskúmať program, zistiť, prečo je hodnota vždy zdvojnásobená a potom to opraviť.

Komponenty s veľkým počtom chýb počas vývoja budú mať veľa chýb aj po odovzdaní projektu. Je to nepríjemná správa pre vývojárov, ale je to potvrdené údajmi z praxe (a tiež podľa princípu 114, ktorý hovorí, že čím viac chýb som našiel v projekte, tým viac ešte nájdem). Najlepším riešením, je zmazať, vymeniť a prerobiť všetky komponenty so zlou minulosťou. Nemíňajte peniaze na zlé veci.

V dnešných dňoch sa toľko hovorí o reinžinierstve, renovácii a reverznom inžinierstve, až by sme si mohli začať myslieť, že je to jednoduché. Nie je. Niekedy to dáva zmysel, pretože je to hodné investície, inokedy je to naopak plytvanie vzácnymi zdrojmi. Vtedy je lepšie navrhnúť a implementovať všetko od začiatku. Položme si otázku: budú napríklad udržovatelia vyrobenú dokumentáciu skutočne aj používať?

Princíp 193 nabáda na to, že prerobenie všetkého môže byť niekedy dobrá myšlienka. Iný, nie najradikálnejší prístup je úplne prerobiť len najhoršie komponenty. "Najhoršie" tu značí tie, ktoré vyžadujú najväčšie náklady na údržbu. V istom systéme sa nachádzal 800 riadkový modul, ktorý spotreboval 30 percent celkových nákladov na údržbu. Prepísaním sa ušetrili značné zdroje v rámci celého údržbárskeho úsilia.

Úpravy v programoch realizované na základe požiadaviek identifikovaných počas etapy údržby, t.j. zmeny systému na používateľských požiadaviek na rozšírenie systému, resp. požiadaviek na odstránenie chýb zistených počas prevádzky spôsobujú podstatne viac chýb, ako samotný prvotný vývoj systému. Organizácie realizujúce vývoj a následne údržbu veľkých softvérových systémov uvádzajú, že 20-50 percent všetkých zmien vykonaných počas údržby systému spôsobuje vznik nových chýb. Môj príspevok sa zaoberá dvomi základnými otázkami a to "Aké sú možné príčiny tohto stavu a aké sú možné východiská resp. riešenia ?", na základe ktorých boli identifikované nasledujúce základné príčiny - zle definované partnerské vzťahy, neprofesionálny prístup ku zapracovaniu akceptovaných zmien, nedostatočné časové a finančné ohodnotenie prác súvisiacich so zapracovaním zmien a s nimi zviazané nasledujúce možné východiská - presné vymedzenie zmluvné vzťahy, komplexné zhodnotenie dopadu zmien na celý systém a jeho následné testovanie, priradenie dostatočného časového a finančného ohodnotenia pre práce súvisiace so zapracovaním zmien.

Regresné testovanie je testovanie všetkých už predtým testovaných častí softvérového projektu po každej vykonanej zmene. Väčšina ľudí regresné testovanie vynecháva, pretože si myslí, že vykonaná zmena bola neškodná.

Ak sa vykoná nejaká zmena, či už za účelom odstránenia chyby, rozšírenia funkčnosti alebo zvýšenia výkonnosti softvéru, je potrebné otestovať, či bola zmena vykonaná tak, ako sa predpokladalo. To znamená, že je potrebné overiť si, či boli odstránené chyby, ktoré sa mali odstrániť, či nové časti systému fungujú správne, alebo či sa zvýšila výkonnosť. V tomto bode si môžeme položiť otázku: Je toto testovanie postačujúce? Odpoveď znie(!?!): Absolútne nepostačujúce! Prečo? Pretože softvér má nanešťastie jednu zaujímavú vlastnosť. Občas sa totiž správa neočakávateľne. Preto je nevyhnutné vykonať regresné testovanie na overenie, či sa testovaný softvér správa tak ako pred vykonanou zmenou.

Dojem,že zmena je jednoduchá zvyšuje pravdepodobnosť,že bude urobená nekoretne.

To je princíp "Samozneplatňujúceho sa modelu" Geralda Weinberga a vzťahuje sa na všeobecnejšiu situáciu popísanú v princípe 171 (Viera v nemožnosť pohromy vedie k pohrome).Keďže software je veľmi komplexný a jeho správne fungovanie záleží od "perfektnosti", implikácie každej zmeny naň musia byť seriózne zvážené.Akonáhle si vý- vojári myslia,že zmena je jednoduchá,ľahká,alebo evidentná,ich ostražitosť poklesne,nezváži sa komplexný prístup a vo väčšine prípadov je zmena urobená nekorektne,prípadne sa potom neskôr objavia nejaké vedľajšie efekty. Aby sa tomu zabránilo,uistite sa,že zmena , ktorú robíte, je odsúhlasená,poriadne každú zmenu skontrolujte a vykonajte regresné testy po každej sade zmien.

Štruktúrovanie neštruktúrovaného kódu nemusí vždy priniesť jeho zlepšenie. Povedzme, že máte udržiavať program, ktorý bol napísaný neštruktúrovane. Môžete ho mechanicky transformovať na ekvivalent, ktorý je štruktúrovaný a vykonáva tú istú funkciu. Často má však mechanické reštruktúrovanie výsledok rovný zlému kódu. Treba zvážiť, či namiesto toho nie je lepšie modul znovu premyslieť a navrhnúť ho od začiatku použitím správnych softvérových inžinierskych princípov.

(Use profiler before optimizing)

Vo fáze životného cyklu programu, kedy prichádza čas optimalizovať kód s ohľadom na jeho rýchlosť, je dobré si pripomenúť a uvedomiť fakt, že 80% strojového času zaberá iba podstatných 20% kódu. Je teda žiadúce lokalizovať práve túto "živú" časť programu, pretože jej optimalizácia prináša najvýraznejšie výsledky. Jedným z najlepších prístupov k dosiahnutiu tohto cieľa je použitie nástrojov pre optimalizáciu programov - profilerov. Tieto sledujú program v čase jeho vykonávania a analyzujú práve tie časti, ktoré sú "živé" (t.j. časti s najväčším podielom na spotrebovanom strojovom čase). Takto získané vedomosti o vykonávaní programu možno prioritne uplatniť pri jeho optimalizácii.

Toto je Manny Lehmanov "Zákon zachovania familiárnosti". Pri údržbe softvérového systému vznikajú nové a nové verzie. Každá sa nejako odlišuje, teda odráža určitý vývoj alebo rast softvérového systému. Každá verzia obsahuje nové prídavky (t.j. odkláňa sa od pôvodného správania predchádzajúcich verzií). Verzie, ktoré sú zmenené v nadpriemernej miere, majú sklon k zhoršeniu výkonnosti, spoľahlivosti, zvýšeniu chybovosti a prekročeniu časového a finančného rozpočtu. Ďalej, čím väčšia je zmena oproti predchádzajúcej verzii, tým väčšie je riziko. Príčina tohoto fenoménu pôsobí ako stabilizačný efekt distribuovaného softvéru pre používateľa. Pokiaľ zmeny softvéru majú sklon spôsobovať nestabilitu, veľké množstvo zmien medzi verziami môže zapríčiniť taký stupeň nestability, že nemôže byť vyvážený prínosom verzie. Mimotoho psychologická familiárnosť, ktorú vývojári cítia k produktu sa znižuje spolu s rastúcim časom medzi verziami. Čím dlhšie je teda verzia vyvíjaná a modifikovaná, tým cudzejšia vývojárom pripadá. Pri uvoľnení ďaľšej verzie produktu sa uskutočnia hlavné preškolovacie procesy a vývojári sa opäť cítia pohodlne. Ak sa spraví príliš veľa zmien medzi verziami, tieto zmeny spôsobujú nefamiliárnosť kódu a trpí tým kvalita.

Poznámka: Snažte sa zachovať relatívnu konzistentnosť pri množstve zmien vytvorených medzi dvoma verziami produktu.