8. Prev dzka a £dr§ba softv‚rovìch syst‚mov ------------------------------------------- Po ukonŸen¡ akceptaŸn‚ho testovania, vytvorenì softv‚rovì syst‚m preber  z kazn¡k. Ak‚ko–vek zmeny vykon van‚ po prevzat¡ produktu predstavuj£ prev dzu a £dr§bu syst‚mu. KeÔ§e produkt nepozost va iba z k¢du programu, zmeny v akìchko–vek dokumentoch taktie§ predstavuj£ udr§bu syst‚mu. édr§ba syst‚mu spotrebuje priemerne 50% a viac z n kladov vynalo§enìch na produkt. V £dr§be syst‚mov je mo§n‚ rozl¡çiœ dva jej typy: korekt¡vnu £dr§bu, perfekt¡vnu (vylepçovaciu) £dr§bu a adapt¡vnu £dr§bu. Korekt¡vna £dr§ba s£vis¡ s odstraåovan¡m vçetkìch chìb pretrv vaj£cich v syst‚me. Medzi tieto chyby je mo§n‚ zaradiœ: - chyby v çpecifik cii - chyby v n vrhu - chyby v k¢dovan¡ - chyby v dokument cii ako aj cel£ çk lu Ôalç¡ch chìb, ktor‚ reprezentuj£ odchìlku od po§adovan‚ho spr vania syst‚mu. Korekt¡vna £dr§ba predstavuje 17% z celej £dr§by syst‚mu. Perfekt¡vna £dr§ba s£vis¡ s vylepçovan¡m efekt¡vnosti alebo inìch £§itkovìch vlastnost¡ produktu, ktor‚ neboli zahrnut‚ v çpecifik cii p“vodn‚ho syst‚mu. Vylepçovanie "udr§ovate–nosti" syst‚mu taktie§ patr¡ k perfekt¡vne £dr§be. Perfekt¡vna £dr§ba predstavuje 60% z celej £dr§by syst‚mu. Adapt¡vna £dr§ba predstavuje modifik ciu produktu v z visloti na zmen ch okolit‚ho prostredia, v ktorom danì produkt pracuje. Adapt¡vna £dr§ba predstavuje 18% z celej £dr§by syst‚mu. Zvyçnìch 5% pripad  na in‚ typy £dr§by. 8.1. Cyklus £dr§by syst‚mu -------------------------- Z h–adiska vynalo§en‚ho Ÿasu a n kladov predstavuje £dr§ba najvìznamnejçiu etapu v §ivotnom cykle programu. Z toho vyplìva i n roŸnosœ pr ce program torov vykon vaj£cich £dr§bu syst‚mov. V minulosti bola t to pr ca mnohokr t podceåovan , z Ÿoho vyplynuli n sledn‚ probl‚my s £dr§bou a dlhodobejçou prev dzkou finanŸne n kladnìch syst‚mov. édr§ba syst‚mu v sebe zahêåa aspekty vçetkìch ostatnìch et po §ivotn‚ho cyklu programu. Udr§ovac¡ cyklus sa zaŸ¡na identifik ciou chyby v syst‚me, alebo identifik ciou potreby vylepçenia, alebo prisp“sobenia vlastnost¡ (funkŸnosti) syst‚mu. Za tìmto £Ÿelom sa vypln¡ çpeci lny dokument, ktorì sa odovzd  prev dzkov‚mu (£dr§bov‚mu) program torovi, ktorì po§iadavku vyhodnot¡. Po§iadavka m“§e po§adovaœ odstr nenie chyby v syst‚me, tzn. identifikovala sa odchìlka medzi spr van¡m produktu a popisom tohoto spr vania v dokument cii. Tak to po§iadavka vçak nemus¡ byœ skutoŸnou chybou, m“§e vyplìvaœ z nespr vnej interpret cie dokument cie. Vo v„Ÿçine pr¡padov sa vçak o chybu v syst‚me skutoŸne jedn . V pr¡padne skutoŸnej existencie chyby mus¡ program tor zistiœ jej p“vod a pr¡Ÿinu. K tomuto m  program tor k dispoz¡cii jej popis, k¢d programu a dokument ciu, ktor  je vo v„Ÿçine pr¡padov v dosœ zlej kvalite. Prev dzkovì program tor preto mus¡ vyu§iœ sirok£ çk lu znalost¡ a sk£senost¡. Po idenrtifik cii chyby v programe je potrebn‚ chybu odstr niœ. V tomto pr¡pade vçak existuje nebezpeŸenstvo chyby z regresie, tzn. nebezpeŸenstvo zavedenia Ôalçej chyby do syst‚mu. Pre minimaliz ciu tohoto rizika je nevyhnutn  podrobn  dokument cia syst‚mu ako celku, ako aj podrobn  dokument cia jednotlivìch programovìch modulov. Òalç¡m krokom je testovanie modifikovan‚ho syst‚mu, tzn. overenie, Ÿi bola chyba odstr nen  spor vne a Ÿi do syst‚mu neboli zaveden‚ Ôalçie regresn‚ chyby. Za tìmto £Ÿelom je potrebn‚ navrhn£œ çpeci lne testovacie d ta. Tieto d ta pozost vaj£ zo s‚rie testov testuj£cich mo§n‚ regresn‚ chyby (s£ uchov van‚ speci lne za tìmto £Ÿelom), ako aj zo s‚rie testov overuj£cich spr vne odstr nenie chyby. Po £speçnom overen¡ vykonania opravy je potrebn‚ vykonan£ modifik ciu podrobne zdokumentovaœ. Najv„Ÿç¡ rozsah v £dr§be vçak zaber  adapt¡vna a perfekt¡vna £dr§ba. Pre ich vykon vanie vçak mus¡ prev dzkovì program tor prejsœ etapami çpecifik cie, n vrhu, implement cie a testovania, v ktorìch existuj£ci syst‚m predstavuje vìchodiskovì bod. Pre urŸit‚ typy zmien nepostaŸ¡ iba modifik cia existuj£cich modulov, ale je potrebn‚ vytvorenie novìch modulov. Na rozdiel od vìvoja syst‚mu, kde Ÿinnosti v jednotlivìch etap ch zabezpeŸuj£ pr¡sluçn¡ specialisti (analytici, n vrh ri, implementaŸn¡ t¡m), mus¡ prev dzkovì program tor vçetky etapy zabezpeŸovaœ s m., resp. v kolekt¡ve prev dzkovìch program torov. Z uveden‚ho preh–adu vyplìva, §e prev dzkovì program tor mus¡ na zabezpeŸenie £dr§by syst‚mu pokrìvaœ pomerne rozsiahlu çk lu Ÿinnost¡. Mus¡ najviac poŸ¡taœ s slabo Ÿitate–nìm k¢dom a nepostaŸuj£cou dokument ciou. KeÔ§e £dr§ba syst‚mu patr¡ k be§nìm po-predajnìm slu§b m, je potrebn‚ k £dr§be priradiœ najlepç¡ch program torov. 8.2. Softv‚rov‚ verzie ---------------------- Pri akejko–vej £dr§be syst‚mu bud£ existovaœ najmenej dve jeho verzie: star  a nov . KeÔ§e ka§dì syst‚m pozost va z modulov, bude existovaœ viacero verzi¡ z viacerìch modulov. K probl‚mov spomenutìm v predch dzaj£cej Ÿasti teda prib£da probl‚m spr vy verzi¡ syst‚mu. Za tìmto £Ÿelom je vhodn‚ oddeliœ dva typy verzi¡ syst‚mu a modulov: rev¡zie a vari cie. Po n jden¡ chyby v module je potrebn‚ chybu opraviœ, tzn. modul modifikovaœ. Nov  verzia mudulu v tomto pr¡pade sa nzìva rev¡zia. Probl‚m existencie viacn sobnìch verzi¡ m“§e byœ vyrieçenì pomerne jednoducho - star  a chybn  verzia sa odstr ni. Takìto pr¡stup vçak vo vçeobecnosti nie je najvhodnejç¡. Predpokladajme, §e existuj£ca verzia modulu m  poradov‚ Ÿ¡slo N a nov  verzia m  Ÿ¡slo N+1. Neexistuje vçak §iadna z ruka, §e verzia N+1 je "korektnejçia" ako verzia N. Hoci novì modul bol otestovanì, jeho nasadenia do prev dzky m“§e sp“sobiœ a§ katastrofick‚ d“sledky (nikto nezaruŸ¡, §e tomu tak nebude). Òalç¡m pr¡padom je distrib£cia verzi¡ pou§¡vate–om. Verzia N+1 m“§e byœ postupne rozçirovan , no identifik cia Ôalçej chyby m“§e d“jsœ od pou§¡vate–a prev dzkuj£ceho star£ verziu modulu. V tomto pr¡pade pre identifik ciu chyby je potrebn‚ konfigurovaœ syst‚m presne tak, ako ho prev dzkuje danì pou§¡vate–. Starçie verzie pri rev¡zi ch je preto potrebn‚ uchov vaœ. T to skutoŸnosœ pl t¡ i pri perfekt¡vej a adapt¡vnej £dr§be. Pri vytv ran¡ syst‚mu m“§e existovaœ viacero sp“sobom dosiahnutia urŸitej funkcie. Typickìm pr¡kladom je pripojenie tlaŸiarne, kde sp“sob pripojenia z vis¡ od jej typu. Inìm pr¡kladom je prenos existuj£ceho syst‚mu do Ôalç¡ch operaŸnìch syst‚mov alebo in£ hardv‚rov£ platformu, kde niektor‚ moduly m“§u byœ od tejto platformy z visl‚ a niektor‚ nie. Vytv ranì alebo udr§ovanì syst‚m preto m“§e obsahovaœ viacero verzi¡ urŸit‚ho modulu, ktor‚ sa v tomto pr¡pade nazìvaj£ vari cie. Na rozdiel od rev¡zi¡, kde novì modul nahr dza starì, m“§u vari ce koexistovaœ paralelne. Vzœah medzi rev¡ziami a vari ciami je ilustrovanì na OBR.8.1. OBR.8.1. - rev¡zie a vari cie 8.3. Spr va konfigur cie syst‚mov --------------------------------- Ka§dì modul syst‚mu m“§e existovaœ v troch form ch: ako zdrojovì program, ako skompilovanì modul (object k¢d) a ako modul zaŸlenenì do vykonate–nej verzie syst‚mu. Formy modulov vytv raj£ce prev dzkovanì syst‚m s£ ilustrovan‚ na OBR.8.2. OBR.8.2. - komponenty vykonate–nej formy syst‚mu Program tor m  k dispoz¡cii kni§nicu verzi¡ jednotlivìch modulov. Konfigur ciou produktu sa nazìva kompoz¡cia çpecifickìch verzi¡ jednotlivìch modulov, z ktorìch dan  verzia produktu pozost va. Probl‚m so spr vou konfigur cie nast va hneÔ pri £Ôr§be syst‚mu. Pri identifik cii chyby je potrebn‚ urŸiœ, ktor‚ verzie jednotlivìch modulov boli pou§it‚ pri vrzii produktu s identifikovanou chybou. Pokia– nie je pou§¡vanì prostriedok pre podporu spr vy konfigur cie, skutoŸn‚ urŸenie verzi¡ jednotlivìch modulov je ve–mi obtia§ne. Znamen  to, §e celì dalç¡ proces identifik cie a odstr nenia chyby pri £dr§be, resp. vylepçovania vlastnost¡ syst‚mu sa komplikuje. Spr va verzi¡ ------------- Prvìm predpokladom pre sp vu konfigur cie je spr va verzi¡. Mnoh‚ operaŸn‚ syst‚mu priamo podporuj£ kontrolu verzi¡. V opaŸnom pr¡pade vçak treba pou§¡vaœ çpeci lny syst‚m pre riadenie spr vy verzi¡. Rozç¡rene pou§¡vanou met¢dou je rozŸlenenie mena modulu na dve Ÿasti: vlastn‚ meno modulu a verzia modulu. Pr¡kladom pou§itioa tak‚hoto oznaŸenie m“§e byœ napr. modul TLA¬_ZOSTAVY/5. Pri oznaŸovan¡ vari ci¡ (tz. jemne modifikovanìch verzi ch zabezpeŸuj£cich funkciu v r“znych kontextoch) sa pou§¡va in  met¢da. Modul je mo§n‚ nazvaœ menom, kde meno vari cie je uzatvoren‚ v z tvork ch. Pr¡kladom oznaŸovania vari ci¡ m“§e byœ modul TLA¬_ZOSTAVY(LASER)/3. Prostriedok, resp met¢da pre identifik ciu verzi¡ predstavuje prvì krok k spr ve verzi¡. Spr va verzi¡ vy§aduje vedenie evidencie o ka§dej uchov vanej verzii. Tu je potrebn‚ evidovaœ zdrojovì k¢dovì element, popis vari ci¡ a rev¡zi¡ vzh–adom k zdroju, pou§itì kompil tor, linker, identifik ciu tvorcu verzie, d tum a Ÿas vytvorenia verzie. Pr ca s viacerìmi vari ciami ---------------------------- V pr¡pade viacerìch vari ci¡ modulu vznikaj£ probl‚my s konzistentnìmi modifik ciami modulov. V pr¡pade identifik cie chyby v Ÿasti modulu, ktor  je spoloŸn  pre vçetky vari cie modulu, je potrebn‚ modifikovaœ pr¡sluçn£ casœ vo vçetkìch vari ci ch. Jednìm z mo§nìch sp“sobov rieçenia tohoto probl‚mu je uchov vanie iba jednej vari cie, priŸom ostatn‚ vari cie s£ reprezentovan‚ mno§inou odchìlok od danej vari cie. Zoznam odchìlok sa nazìva delta. Pri existencii n vari ci¡ modulu mus¡ existovaœ n-1 . Dan  vari cia sa potom z¡ska aplik ciou pr¡sluçn‚ho delta na uchov van£ vari ciu, Ÿ¡m sa uchov  konzistencia vari ci¡ pri ich modifik cii. V pr¡pade, §e je potrebn‚ modifikovaœ çpecifick£ Ÿasœ vari cie, postaŸ¡ modifik cia pr¡sluçn‚ho delta. 8.4. Management £dr§by ---------------------- édr§ba prev dzkovan‚ho syst‚mu predstavuje pomerne zlo§itì proces. Proces £dr§by budeme popisovaœ z h–adiska korekt¡vnej £dr§by. Pre zavedenie systematiŸnosti a kontrolovate–nosti do procesu korekt¡vje £dr§by sa doporuŸuje pri zabezpeŸovan¡ udr§by dodr§iavaœ definovanì postup. DoporuŸenì postup op¡çeme podrobnejçie. Spr vy o chyb ch ---------------- V pr¡pade identifik cie chyby v produkte je pitrebn‚ vyplniœ spr vu o chybe. Tento dokument vyplåuje pou§¡vate– produktu, ktorì chybu identifikoval. Mus¡ obsahovaœ dostatoŸn‚ inform cie na rekonçtruovanie zlyhania syst‚mu, ktor‚ je vo v„Ÿçine pr¡padou sp“soben‚ chybou v programe. V ide lnom stave by mala byœ ka§d  chyba odstr nen  okam§ite. Takìto pr¡stup sa aplikuje iba u chìb, ktor‚ s£ z sadn‚ho charakteru a znemo§åuj£ prev dzku syst‚mu. Chybov‚ spr vy pre menej podstatn‚ chyby sa eviduj£ a prev dza sa ich odstraåovanie (napr. raz za 6 mesiacov). Pri identifik cii chyby, ak sa aj nebude vykon vaœ jej bezprostredn‚ odstr nenie, je potrebn  analìza jej pr¡Ÿin. Vo v„Ÿçine pr¡padov sa podar¡ identifikovaœ Ÿast syst‚mu, ktor  chybu sp“sobuje. Na z klade vìsledkov analìzy je mo§n‚ pou§¡vate–ovi doporuŸiœ, ako je mo§n‚ chybu do jej odstr nenia obch dzaœ. DoporuŸenie sp“sobu pr ce s chybou v syst‚me je d“le§it‚, preto§e m“§e trvaœ dosœ dlhì Ÿas, pokia– bude odstr neniu chyby pridelenì prev dzkovì program tor. Vìsledky analìzy sa obvykle prip jaj£ k spr ve o pr¡sluçnej chybe aby boli dostupn‚ pri odstraåovan¡ chyby. Manager prev dzky produktu potom prirad¡ chybe prioritu, na z klade ktorej sa vyber  odstraåovan  chyba. Priorita by mala definovaœ casovì horozont odstr nenia chyby. V pr¡pade, §e produkt je pou§¡vanì na viacerìch miestach, chybov‚ spr vy sa dopravia na vçetky miesta prev dzkovania k¢pi¡ syst‚mu. Po identifik cii identickej chyby je mo§n‚ z chybovej spr vy z¡skaœ inform cie o prejavoch a d“sledkoch chyby, ale aj inform cie doporuŸuj£ce prev dzku syst‚mu s chybou a odhad term¡nu odstr nenia chyby. Autoriz cia prev dzanìch zmien ------------------------------ Po rozhodnut¡ vykonaœ korekt¡vnu £dr§bu sa oprave danej chyby prirad¡ prev dzkovì program tor. Jeho £lohou je identifik cia bezprostrednej pr¡Ÿiny chyby a odstr nenie tejto pr¡Ÿiny. Po jejm odstr nen¡ mus¡ byœ vykonan‚ testovanie prevedenej opravy, ako aj regresn‚ testovanie. Dokument cia syst‚mu mus¡ byœ taktie§ zodpovedaj£cim sp“sobom aktualizovan , tzn. je potrebn‚ specifikovaœ Ÿo a akìm sp“sobom bolo zmenen‚. Pred vlastnou distrib£ciou novej verzie syst‚mu je potrebn‚ vykonan‚ zmeny nechaœ preveriœ çpeci lnej skupine, ktorej £lohou je zabe§peŸovaœ kvalitu produktu, ako aj procesu jeho vìvoja (Quality Assurance Group). T to skupina by mala byœ nez visl , tzn. nemala by podliehaœ prev dzkov‚mu managerovi. Potreba dodatoŸn‚ho overovania s£vis¡ so zlo§itosœou procesiu £Ôr§by. ReferenŸn‚ verzie ----------------- Pri vykon van¡ akejko–vek £dr§by je potrebn‚ zostaviœ referenŸn£ verziu (resp. viacero referenŸnìch verzi¡) modulov v produkte. Pri h–adan¡ chyby a pr ci s modulmi mus¡ program tor vytvoriœ lok lne k¢pie modifikovanìch modulov vo svojom pracovnom priestore. Ak ko–vek zmena tìchto modulov potom neovplyvn¡ pr cu ostatnìch program torov pracuj£cich na inìch moduloch syst‚mu. Po rozhodnut¡ o potrebe modifik cie modulu v syst‚me (napr. pri potrebe odstr nenia n jdenej chyby), program tor zmraz¡ modifikovanì modul v syst‚me. Zmrazenì modul identifikuje, §e v danom module prebiehaj£ zmeny a preto ho nesmie modifikovaœ §iaden inì program tor. Po vykonan¡ zmien a otestovan¡ opravy chyby sa do syst‚mu zakomponuje nov  verzia modulu, Ÿ¡m sa zmen¡ referenŸn  verzia syst‚mu. Po inçtal cii modulu m“§e zmenenì mkodul zmraziœ inì program tor. Presn‚ dodr§iavanie pop¡sanej techniky je hlavnou £lohou managementu £dr§by. D“le§itou podmienkou zav dzania modifikovanìch modulov do referenŸnej verzie syst‚mu je, §e modifikovanì modul mus¡ byœ testovanì vzh–adom na aktu lnu referenŸn£ verziu (tzn. nie vzh–adom na referenŸn£ verziu, ktor  existovala pro zmrazen¡ dan‚ho modulu, resp. modulov). Spr va konfigur cie poŸas vìvoja syst‚mu ---------------------------------------- PoŸas k¢dovania modulu sa jeho verzie menia pr¡liç rìchlo na to, aby bolo mo§n‚ aplikovaœ techniky spr vy konfigur cie. Ak vçak modul prejde cez SQA (Software Quality Assurance), mal by byœ podrobenì rovnakìm proced£ram spr vy konfigur cie ako poŸas £dr§by. D“vodom je skutoŸnosœ, §e ak bgol modul integrovanì do vytv ran‚ho syst‚mu, modifik cia tohoto modulu m“§e ovplyvniœ celì syst‚m rovnakìm sp“sobom ako v pr¡pade modifik cie modulu pri £dr§be. Naviac, je ve–mi obtia§ne monitorovaœ vìvoj syst‚mu pokia– nie je k dispoz¡cii riadenie konfigur cie. V tomto pr¡pade s£ k dispoz¡ci inform cie o stave ka§d‚ho modulu. Prostriedky pre podporu £dr§by ------------------------------ Je nemyslite–ne po§adovaœ od prev dzkovìch program torov manu lne sledovanie Ÿ¡sel rev¡zi¡ jednotlivìch modulov pri ka§dej modifik cii (niektor‚ operaŸne syst‚my, ako RSX a syst‚mov‚ prostriedky toto umo§åuj£). Rovnako je nepredstavite–n‚ manu lne spracovanie "zmrazovania" modulov tak, ako bolo op¡san‚ v predch dzaj£cich Ÿastiach. Aj sa keÔ softv‚rov  firma zdr haœ investovaœ do podpornìch prostriedkov pre £dr§bu, v ka§dom pr¡pade by mal byœ k dispoz¡cii prostriedok pre zostavenie po§adovanej verzie cel‚ho syst‚mu, ako aj prostriedok pre spr vu verzi¡ modulov. Tieto prostriedky aspoå minim lnym sp“sobom pom haj£ v £dr§be. Techniky £dr§by --------------- édr§ba softv‚rov‚ho produktu nie je jednor zov  aktivita. Aj ve–mi dobre vytvorenì produkt bude prech dzaœ nieko–kìmi vrziami poŸas svojej §ivotnosti. Z tohoto d“vodu je potrebn‚ do §ivotn‚ho cyklu zahrn£œ pl novanie £dr§by. Jednotliv‚ etapy musia zoh–adåovaœ £dr§bu: pri implement cii treba p¡saœ k¢d Ÿitate–ne, dokument cia mus¡ byœ £pln  a presn  atÔ. Udr§ovate–nosœ syst‚mu mus¡ byœ z kladnìm krit‚riom pri n vrhu a implement cii syst‚mu. Probl‚my opakovanej £dr§by -------------------------- Jednou z frustruj£cich œa§kost¡ pri vìvoji produktu je tzv. probl‚m "pohybliv‚ho cie–a". M“§e sa staœ, §e tak rìchlo ako sa vyv¡ja produkt, zad vate– men¡ svoje po§iadavky. T to situ cia m“§e maœ nasledovn‚ dopady: - negat¡vny psychologickì dopad na realizaŸnì t¡m - nevhodn  konçtrukciu a çtrukt£ru k¢du syst‚mu - zvìçenie n kladov na vìvoj produktu - mo§nosœ odliçnost¡ dokument cie od n vrhu a implement cie Rieçenie tohoto probl‚mu je z le§itosœou managementu. Teoreticky je mo§n‚ podstatu probl‚mu vysvetliœ z kazn¡kovi. a v istom stave "zmraziœ" çpecifik ciu a§ do dodania produktu. Rovnako po ka§dej §iadosti s£visiacej s vylepçeniami produktu m“§e byœ specifik cia na urŸitì Ÿas zmrazen .