2. Systematickì pr¡stup k vìvoju softv‚rovìch syst‚mov ------------------------------------------------------ Softv‚rov‚ in§inierstvo je mo§n‚ definovaœ ako proces transform cie opisu po§adovanìch vlastnost¡ syst‚mu spracovania inform ci¡ do jeho programovej realiz cie. Ako je zrejm‚ i z tohoto jednoduch‚ho opisu, jedn  sa o nesmierne zlo§itì proces, do ktor‚ho s£ zainteresovan‚ r“zne skupiny tvorcov: analytici, program tori, technici a manageri. Realiz cia transform cie po§iadaviek do programovej realiz cie syst‚mu nie je ani zÔaleka tak  jednoduch , ako sa m“ze javiœ zo sk£senost¡ pri tvorbe cviŸnìch jednoduchìch programov. Pri vìvoji syst‚mov sa mnohokr t postupuje ad-hoc pr¡stupom, Ÿo m  za n sledok zlyhania a ne£spechy pri realiz cii mnohìch projektov. A§ 49% vyv¡janìch aplik ci¡ m  probl‚my s prekroŸen¡m pl novan‚ho rozpoŸtu. Kritick£ situ ciu v softv‚rovom in§inierstve dokumentuje aj nasleduj£ca tabu–ka: 5% - syst‚m pou§ivanì tak ako uv dza çpecifik cia 55% - syst‚m dodanì a pou§ivanì po modifik ci ch 10% - syst‚m s¡ce dodanì, ale v praxi v“bec nevyu§ivanì 15% - syst‚m pou§ivanì po £plnom prepracovan¡ 15% - syst‚m v“bec nedodanì (projekt konŸi ne£spechom) S£casn  kr¡za v softv‚rovom in§inierstve sa prejavuje vo vlastnostiach procesu tvorby produktov, ako aj vo vlastnostiach vlastnìch produktov (programov), ktor‚ je mo§n‚ zosumarizovaœ nasledovne: - vysok‚ prekraŸovanie projektovìch rozpoŸtov - vysok‚ prekraŸovanie pl novanìch dodac¡ch term¡nov, tzn. neskor‚ dod vky - neuspokojiv  kvalita produktov - neuspokojiv‚ funkŸn‚ vlastnosti produktov - probl‚my s prev dzkou, £dr§bou a Ôalçimi modifik ciami produktov Prv  zmienka o probl‚moch pri vìvoji v„csich programovìch syst‚mov je zo zaŸiatku 60-tych rokoch. Rozsiahly n rast komplexnosti vytv ranìch syst‚mov pri viac-menej neexistencii met¢d a noriem ich vìvoja sp“sobil, §e sa £plne nahlas zaŸina hovoriœ o softv‚rovej kr¡ze. Od tohoto Ÿasu sa datuje snaha postaviœ vìvoj programovìch syst‚mov na in§iniersky z klad, Ÿi§e zaŸina sa hovoriœ o softv‚rovom in§inierstve. Softv‚rov‚ in§inierstvo mo§no charakterizovaœ ako vedn£ discipl¡nou, ktor  sa sna§i vytv raœ a aplikovaœ jednotiacu metodol¢giu na celì proces vìvoja softv‚rovìch syst‚mov, tzn. pokryœ analìzu, n vrh, implement ciu a testovanie. Rovnako sa v r mci softv‚rov‚ho in§inierstva rozv¡ja i veda o managemente vìvoja softv‚rovìch syst‚mov, meran¡ a kvalite softv‚rovìch syst‚mov. Tendencie k zavedeniu urŸitìch noriem a postupov v softv‚rovom in§inierstve je mo§n‚ sledovaœ u§ dlhçiu dobu. V 60-tych a 70-tych rokoch sa pozornosœ venovala programovaniu v domnen¡, §e postaŸuj£cim faktorom umo§nuj£cim n jsœ vìchodisk  z existuj£cich probl‚mov je vytv ranie "dobrìch" programov. Z tohoto obdobia sa datuj£ mnoh‚ pr¡stupy k çtrukt£rovan‚mu programovaniu. Tieto techniky s£ v s£casnosti akceptovan‚ a pou§ivan‚ vo v„csine organiz ci¡ vytv raj£cich softv‚rov‚ produkty. Zvìsenie produktivity pr ce a kvality programovìch produktov nie je mo§n‚ dosiahnuœ iba zaveden¡m çtrukt£rovanìch pr¡stupov k programovaniu, ak n vrh syst‚mu, z ktor‚ho sa danì programovì k¢d odv dza, je ne£plnì, viacznaŸnì a protireŸivì. Preto sa v 80-tych rokoch pozornosœ pres£va na analìzu a n vrh programovìch syst‚mov. V tomto obdob¡ s£ definovan‚ metodol¢gie ako ETHICS (Effective Technical and Human Implementation of Computer-Based Systems) [Mumford:1979], SSM (Soft Systems Methodology) [Checkland:1981], çtrukt£rovan‚ pr¡stupy zalo§en‚ na systematickej dekompoz¡cii komplexnìch syst‚mov do jednoduhçich, –ahçie zvl dnute–nìch modulov [Gane:1979], [DeMarco:1979], ako aj ucelenejçie metodol¢gie SSADM (Structured Systems and Analysis Method) [Ashworth:1990] a MERISE. Tieto metodol¢gie sa sna§ia etapizovaœ vìvoj programov‚ho syst‚mu (tzn. rozŸleniœ ho na presne definovan‚ jednoduch‚ kroky) a doporuŸiœ prostriedky a postupy, ktor‚ je v danej etape vìvoja vhodn‚ pou§ivaœ. Pre etapiz ciu projektu pre vçetky existuj£ce metodol¢gie predstavuje pojem §ivotn‚ho cyklu programu jednotiacu b zu. 2.1. ¦ivotnì cyklus programovìch syst‚mov ----------------------------------------- V softv‚rovom in§inierstve je evidentnì vçeobecnì s£hlas so skutoŸnosœou, §e vìvoj ka§d‚ho programov‚ho syst‚mu je potrebn‚ vykon vaœ systematicky. Z tohoto d“vodu bìva vìvoj rozdelenì na definovan‚ etapy a zav dza sa pojem §ivotn‚ho cyklu programu. Takìto pr¡stup prin sa rozdelenie (dekompoz¡ciu) komplexn‚ho probl‚mu na jednoduhçie a –ahçie zvl dnute–n‚ probl‚my. Rozdiely v existuj£cich pr¡stupoch k §ivotn‚mu cyklu zv„csa spoŸivaj£ v Ÿlenen¡ na jednotliv‚ et py a postupnosti, ktorou je cez nich potrebn‚ prech dzaœ. Podstatnou charakteristikou ka§d‚ho modelu §ivotn‚ho cyklu vçak je, §e definuje jednotliv‚ etapy a pre ka§d£ z nich Ÿinnosœ, ktor  sa m  vykon vaœ, rovnako ako vstupy a vìstupy etapy. Takìmto sp“sobom sa proces vìvoja programovìch syst‚mov st va preh–adnejçi a kontrolovate–nejçi. V s£casnosti je v praxi pou§ivanìch viacero modelov §ivotn‚ho cyklu. Najzn mejçimi s£ vodop dovì ("waterfal") model a çpir lovì model zachycuj£ci iterat¡vny pr¡stup k vìvoju syst‚mu. Pre naçe £cely zavedieme tzv. V-model §ivotn‚ho cyklu, pou§ivanì NCC (National Computing Center) vo Ve–kej Brit nii. Model je ilustrovanì na OBR.2.1. OBR.2.1. - V-model §ivotn‚ho cyklu V-model zn zoråuje s£vis jednotlivìch et p vo vìvoji programu, ako aj produkty (vìstupy) a vstupy jednotlivìch et p. S£vis et p je mo§n‚ vidieœ jednak v aspekte n slednosti (zn zornenì cez çipky) ako aj v aspekte abstrakcie (zn zornenì ako umiestnenie et p na rovnakej vodorovnej rovine). V tomto zmysle je napr. zrejmì s£vis et p architekt£rneho n vrhu a syst‚movej integr cie a testovania. Etapa na zostupnej hrane modelu s£vis¡ s n vrhom a dekompoz¡ciou syst‚mu na danej £rovni abstrakcie a etapa na vzostupnej hrane s£vis¡ s integr ciou submodulov, resp. realiz cie dan‚ho n vrhu a jeho integr cie do cel‚ho syst‚mu. Vìvoj softv‚rov‚ho syst‚mu nebìva iba jednosmernìm procesom. Po ukonŸen¡ urŸitej etapy sa v Ôalçom vìvoji m“ze identifikovaœ potreba modifik cie vìsledku tejto etapy, Ÿi§e potreba n vratu k jednej z predch dzaj£cich et p. Prepracovanie rieçenia je preto tie§ d“le§itou charakteristikou modelu §ivotn‚ho cyklu. V„csina modelov ponech va sp“sob n vratu k niektorej z predch dzaj£cich et p na n vrh ra. V-model sa sna§i rieçiœ i tento probl‚m. N vrat vo V-modele je mo§nì bezprostredne k predch dzaj£cej etape (ak vìsledky predch dzaj£cej etapy nie s£ uspokojiv‚), alebo k etape na rovnakej £rovni za zostupnej vetve (ak syst‚m na danej £rovni abstrakcie bol zle navrhnutì a je potrebn‚ n vrh prepracovaœ). Model §ivotn‚ho cyklu programu nedefinuje d–zku trvania, ani rozsah jednotlivìch et p. D–zka trvania jednotlivìch et p a n klady s£ r“zne v z vislosti od typu a çpecif¡k vyv¡jan‚ho syst‚mu. V TAB.2.1. s£ uveden‚ relat¡vne n klady z kladnìch et p pre r“zne druhy aplik ci¡ z¡skan‚ na z klade analìzy v„csieho mno§stva projektov vytv ranìch pre jednotliv‚ typy aplik ci¡. S£casœou modelu §ivotn‚ho cyklu nie je iba rozdelenie procesu vìvoja programu na jednotliv‚ etapy, ale taktie§ podrobnejçia charakteriz cia jednotlivìch et p vytv raj£ca ak£si hrub£ metodol¢giu vìvoja softv‚rovìch syst‚mov. Podrobnejçie Ÿlenenie jednotlivìch et p na konkr‚tne kroky a £lohy opisuje konkr‚tna metodol¢gia. Pre ka§d£ etapu §ivotn‚ho cyklu vçak je presne definovanì vstup a vìstup (viÔ. napr. OBR.2.1). Ka§d£ etapu mo§no na tejto £rovni abstrakcie charakterizovaœ mno§inou doporuŸenìch £loh s definovanìmi vstupnìmi inform ciami (dokumentami) a vìstupnìmi inform ciami (dokumentami). Rovnako je potrebn‚ definovaœ predpoklady nevyhnutn‚ pre zaŸatie danej £lohy a sp“soby kontroly ukonŸenia danej £lohy. Ako pr¡klad je mo§n‚ bli§sie pop¡saœ jednotliv‚ ulohy v etap ch V-modelu §ivotn‚ho cyklu. 2.1.1. Etapa çpecifik cie po§iadaviek ------------------------------------- Etapa çpecifik cie po§iadaviek je procesom transform cie neform lnych pou§ivate–skìch po§iadaviek do komplexn‚ho a çtrukt£rovan‚ho opisu tìchto po§iadaviek, tzn. do opisu syst‚mu, ktorì pou§ivate– po§aduje vytvoriœ. Vìchodiskom tejto etapy je obozn menie sa s prostred¡m, v ktorom bude syst‚m v bud£cnosti nasadenì a s probl‚mami, ktor‚ m  syst‚m rieçiœ. Z h–adiska identifik cie pou§ivate–skìch po§iadaviek je vhodn‚ postupovaœ systematicky a po§iadavky rozŸleniœ do nieko–kìch kateg¢ri¡: - funkŸn‚ po§iadavky definuj£ce po§adovan‚ funkcie syst‚mu. Vo v„csine vytv ranìch aplik ci¡ je mo§n‚ tieto po§iadavky pomerne jednoducho identifikovaœ a v„csina çpecifik ci¡ dodanìch pou§ivate–mi sa redukuje na opis pr ve tìchto po§iadaviek. - kvalitat¡vne po§iadavky definuj£ce vlastnosti syst‚mu z h–adiska pou§ivate–sk‚ho komfortu, £dr§by, modifikovate–nosti a spo–ahlivosti vytvoren‚ho syst‚mu. Vo v„csine pr¡padov je pre pou§ivate–a t£to kateg¢riu po§iadaviek ve–mi obtia§ne definovaœ. - kritick‚ atrib£ty definuj£ce kritick‚ hodnoty vlastnost¡, ktor‚ vo vìvoji nie je povolen‚ prekroŸiœ, ako napr. doba odozvy syst‚mu, rozsah datab zy a aplikaŸnìch programov atÔ. PrekroŸenie povolenìch hodn“t tìchto atrib£tov vedie ku krachu projektu. - identifik cia zdrojov, ktor‚ s£ pri vìvoji syst‚mu k dispoz¡cii. Jedn  sa najm„ o materi lne zdroje (technick‚ vybavenie), finanŸn‚ zdroje (rozpoŸet), –udsk‚ zdroje (tvorcovia syst‚mu) a Ÿas, ktorì je k dispoz¡cii pre vìvoj programov‚ho syst‚mu. Identifik ciu zdrojov vo v„csine pr¡padov vykon va analytik na z klade predch dzaj£cich kateg¢ri¡ po§iadaviek. Pri identifik cii pou§ivate–skìch po§iadaviek sa Ÿasto vych dza z existuj£ceho syst‚mu, identifikuj£ sa jeho nedostatky a Ôalçie, novo vzniknut‚ po§iadavky, resp. navrhovan‚ vylepçenia. Vìstupy tejto etapy je mo§n‚ ve–mi hrubo zhrn£t do nasledovnìch dokumentov: - opis s£casn‚ho syst‚mu a identifik cia jeho nedostatkov - çpecifik cia pou§ivate–skìch po§iadaviek na vytv ranì syst‚m Obsah a çtrukt£ra vìstupov jednotlivìch et p bude upresnen  v konkr‚tnej metodol¢gii analìzy a n vrhu op¡sanej nesk“r. 2.1.2. Etapa architektonick‚ho n vrhu ------------------------------------- V etape architektonick‚ho n vrhu sa ujasåuje celkov  koncepcia syst‚mu. T£to etapu je mo§n‚ rozdeliœ do dvoch Ÿast¡: analìza çpecifikovanìch po§iadaviek a n vrh rieçenia. V metodol¢gi ch ako napr. SSADM bìva Ÿasœ tejto etapy ch pan  ako s£casœ etapy çpecifik cie a analìzy po§iadaviek. Pri analìze po§iadaviek sl£zi ako vstupnì dokument çpecifik cia pou§ivate–skìch po§iadaviek. Na z klade tìchto po§iadaviek, resp. na z klade analìzy s£casn‚ho stavu sa navrhne nieko–ko alternat¡v rieçenia. Pre ka§d£ z tìchto alternat¡v sa spracuje analìza realizovate–nosti, v ktorej sa pre ka§d£ alternat¡vu identifikuj£ vìhody a pr¡padn‚ probl‚my, odhadn£ n klady a pr¡nosy a vypracuje sa struŸnì realizaŸnì pl n. Na z klade konzult ci¡ s pou§ivate–mi sa vyberie najvìhodnejçia z alternat¡v. KeÔze vìber z alternat¡v je skoro v§dy ot zkou kompromisov, je mo§n‚, §e niektor‚ pou§ivate–sk‚ po§iadavky bud£ po dohode vynechan‚. Vìstupom tejto Ÿasti s£ nasledovn‚ dokumenty: - zoznam mo§nìch alternat¡v rieçenia - çt£dia realizovate–nosti pre ka§d£ alternat¡vu obsahuj£ca: - identifik cia vìhod a probl‚mov - odhad n kladov a pr¡nosov - struŸnì realizaŸnì pl n - dokument o vìbere a zd“vodnen¡ vìberu alternat¡vy Po vìbere alternat¡vy rieçenia je mo§n‚ prikroŸiœ k Ôalçiemu rozpracovaniu rieçenia na £roveå architektonick‚ho n vrhu. V tejto Ÿasti sa spresn¡ jednak architekt£ra syst‚mu (identifikuj£ sa z kladn‚ moduly syst‚mu a ich vzœahy), n vrh pou§ivate–skìch rozhran¡ a sp“sobu komunik cie, pl n realiz cie syst‚mu, ale aj identifik cia potrebnìch zdrojov pre projekt (odhad d’zky trvania a n kladov). ¬asto sa v tejto etape vytv ra aj prv  verzia pou§ivate–skej pr¡ruŸky. Dohoda s pou§ivate–mi o sp“sobe urŸenia splnenia cie–ov projektu bìva taktie§ s£casœou etapy architektonick‚ho n vrhu. Je potrebn‚ presne stanoviœ podmienky, za ktorìch bude vytvorenì produkt akceptovanì pou§ivate–om. Stanovenie tìchto podmienok znamen  dohodn£t sa na pl ne akceptaŸn‚ho testovania a urŸen¡ testovac¡ch £dajov, ktor‚ bud£ pri testovan¡ pou§it‚. Podcenenie potreby stanovenia sp“sobu prebratia vìsledn‚ho produktu pou§ivate–mi sp“sobuje Ÿastokr t probl‚my s ukonŸen¡m projektu. V etape architektonick‚ho n vrhu je potrebn‚ stanoviœ aj sp“sob a postup nasadzovania syst‚mu do prev dzky. Tento bod zahråuje jednak dohodu o postupe nasadzovania jednotlivìch modulov identifikovanìch v architektonickom n vrhu syst‚mu do prev dzky (a z neho sa odv¡jaj£ci sa pl n postupnosti vytv rania zodpovedaj£cich programovìch celkov), ale aj dohodu o pl ne zaçkolovania bud£cich pou§ivate–om na prev dzku syst‚mu. Vìstupn‚ dokumenty etapy architektonick‚ho n vrhu mo§no sumarizovaœ nasledovne: - çpecifik cia architekt£ry syst‚mu obsahuj£ca: - identifik ciu subsyst‚mov a nimi realizovanìch funkci¡ - çpecifik ciu rozhran¡ - identifik ciu internìch a externìch £dajovìch tokov, vytvorenie modelu £dajov - n vrh architekt£ry, tzn. z kladnìch modulov syst‚mu a v„zieb medzi nimi - odhad potrebnìch –udskìch a materi lnych zdrojov - pl n realiz cie syst‚mu - dohoda o sp“sobe overenia funkŸnosti vytvoren‚ho syst‚mu, tzn. pl n testovania a n vrh testovac¡ch £dajov - n vrh sp“sobu nasadzovania vytvoren‚ho syst‚mu - n vrh postupu zaçkolovania pracovn¡kov pre vytv ranì syst‚m - prv  verzia pou§ivate–skej pr¡ruŸky 2.1.3. Etapa podrobn‚ho n vrhu ------------------------------ Cie–om etapy podrobn‚ho n vrhu je vypracovaœ na z klade architektonick‚ho n vrhu podrobnì n vrh pre jednotliv‚ moduly tvoriace syst‚m. V praxi to znamen  dokonŸenie podrobn‚ho n vrhu pou§ivate–skìch rozhran¡ (vstupov a vìstupov) pre ka§dì modul, n vrh logickej a fyzickej çtrukt£ry £dajov a n vrh algoritmov. Etapa podrobn‚ho n vrhu pre ka§dì modul konŸi detailnou çpecifik ciou programov realizuj£cich danì modul. T to çpecifik cia je podkladom pre program torov v etape k¢dovania. Podobne ako u architektonick‚ho n vrhu, s£casœou podrobn‚ho n vrhu je aj urŸenie sp“sobu overenia funkŸnosti jednotlivìch modulov (pl n testovania a testovacie £daje). Rovnako je pre ka§dì modul potrebn‚ vytvoriœ podrobnì realizaŸnì pl n definuj£ci £lohy jednotlivìch tvorcov syst‚mu pri implement cii dan‚ho modulu. V tejto etape u§ mus¡ byœ zrejm‚, ako je potrebn‚ realizovaœ jednotliv‚ moduly. Vìstupn‚ dokumenty s£ pre ka§dì modul nasledovn‚: - pl n pr c pri implement cii modulu - podrobn  specifik cia potrebnìch –udskìch a materi lnych zdrojov (odhad d’zky trvania a ceny dan‚ho modulu) - podrobn  specifik cia logickej a fyzickej çtrukt£ry £dajov spracov vanìch danìm modulom - podrobn‚ specifik cia çtrukt£ry modulu - çpecifik cia algoritmov realizuj£cich funkcie modulu - çpecifik cia pou§ivate–skìch rozhran¡ pre danì modul - çpecifik cia sp“sobu oçetrovania chybovìch a neoŸak vanìch stavov - pl n testovania modulu s n vrhom testovac¡ch £dajov a sp“sobom overenia funkŸnosti modulu 2.1.4. Etapa k¢dovania a testovania modulov ------------------------------------------- Etapa k¢dovania a testovania modulov bezprostredne nadv„zuje na etapu podrobn‚ho n vrhu pre ka§dì modul. Cie–om tejto etapy je programovo realizovaœ n vrh dan‚ho modulu a vypracovaœ podrobn£ dokument ciu k vytvorenìm programom. Okrem realiz cie n vrhu je v danej etape vykon van‚ aj testovanie modulu. V tejto s£vislosti sa postupuje pod–a vopred vypracovan‚ho pl nu testovania a spolu s pou§ivate–om sa vìsledky testovania modulu vyhodnotia. Rovnako je potrebn‚ vykonaœ merania kritickìch atrib£tov pre danì modul a v pr¡pade prekroŸenia ich povolenìch hodn“t prepracovaœ zodpovedaj£cu Ÿasœ n vrhu modulu, resp. i architektonick‚ho n vrhu. Spolu s implement ciou jednotlivìch modulov prebieha dopracov vanie pou§ivate–skìch manu lov. V tejto etape je u§ mo§n‚ podrobne dokumentovaœ pou§ivate–sk‚ rozhrania, spresniœ popis jednotlivìch funkci¡ a sp“sobu ich aktiv cie. S dopracovan¡m pou§ivate–skìch pr¡ruŸiek sa via§e v„csinou zaŸiatok çkolenia bud£cich pou§ivate–ov postupne pre jednotliv‚ moduly. Vìstupn‚ dokumenty tejto etapy s£: - programov  realiz cia modulov - dokument cia k programovej realiz cii modulov - dokument o testovan¡ (preveden‚ testy a zhodnotenie testov) - dokument o meran¡ kritickìch atrib£tov pre danì modul a v pr¡pade poruçenia povolenìch hodn“t rozhodnutia o Ôalçom postupe - dopracovan‚ pou§ivate–sk‚ manu ly 2.1.5. Etapa integr cie modulov ------------------------------- Etapa integr cie modulov s£vis¡ so zoskupovan¡m modulov do vyçsich funkŸnìch celkov. Pre ka§dì takìto celok prebieha testovanie pod–a vopred vypracovan‚ho pl nu pre danì celok a meranie kritickìch atrib£tov. Vìstupn‚ dokumenty tejto etapy s£: - protokol o testovan¡ funkŸnìch celkov (preveden‚ testy a zhodnotenie vìsledkov) - dokument o meran¡ kritickìch atrib£tov a pr¡padnìch potrebnìch zmen ch 2.1.6. Etapa integr cie a akceptaŸnìch testov syst‚mu ----------------------------------------------------- Etapa integr cie a testovania syst‚mu s£vis¡ s akceptaŸnìm testom cel‚ho syst‚mu. Tento test sa prev dza na z klade pripraven‚ho pl nu v prev dzkovom prostred¡, tzn. u pou§ivate–a. Meraj£ sa taktie§ kritick‚ atrib£ty v prev dzke pokia– mo§no Ÿo najbli§sej re lnemu nasadeniu syst‚mu. Po £speçnom testovan¡ a splnen¡ akceptaŸnìch podmienok prebieha preberacie konanie. V tejto etape by malo konŸiœ zauŸovanie pracovn¡kov pre vytv ranì produkt. Vìstupn‚ dokumenty s£: - vìsledky akceptaŸnìch testov s hodnoten¡m vìsledkov - dokument o splnen¡ akceptaŸnìch krit‚ri¡ pre vytvorenì syst‚m - dokument o ukonŸen¡ a vìsledkov zaçkolovania pou§ivate–ov - preberac¡ protokol 2.1.7. Etapa prev dzky a £dr§by syst‚mu --------------------------------------- Etapa prev dzky syst‚mu s£vis¡ so zabezpeŸovan¡m ka§dodennej prev dzky syst‚mu a jeho Ôalçieho rozvoja. ZabezpeŸovanie ka§dodennej prev dzky vo v„csine pr¡padov prech dza na pou§ivate–a a Ôalçi rozvoj syst‚mu (£dr§ba a modifik cie) zv„csa ost va na tvorcovi. Ka§d  po§adovan  zmena syst‚mu sa m“ze pova§ovaœ za samostatnì produkt, pre ktorì je rovnako mo§no pou§iœ zivotnì cyklus programu. V ka§dom pr¡pade vçak prev dzkou syst‚mu vznikaj£ nasledovn‚ dokumenty: - dokument o chyb ch a neoŸak vanìch situ ci ch, ktor‚ sa poŸas prev dzky syst‚mu vyskytli - porovnanie vìkonnosti a funkŸnosti syst‚mu oproti oŸak vaniam - dokument o modifik ci ch a zmen ch prevedenìch v syst‚me - dokument o §iadanìch zmen ch syst‚mu (ktorì sa modifikuje realizovan¡m po§adovanej zmeny) Z rozpracovania jednotlivìch et p §ivotn‚ho cyklu programu je zrejm‚, §e sa jedn  o ve–mi vçeobecnì popis §ivotn‚ho cyklu, ktorì je potrebn‚ prisp“sobiœ konkr‚tnemu projektu. Rozdiel v §ivotnom cykle bude napr. medzi syst‚mom s jednou inçtal ciou a syst‚mom, u ktor‚ho sa predpoklad  sirok‚ rozçirenie. Rovnako §ivotnì cyklus sa m“ze modifikovaœ na z klade dohodnutej strat‚gie odovzd vania vytv ran‚ho syst‚mu. 2.2. Vari cie §ivotn‚ho cyklu programu -------------------------------------- V s£vislosti s variabilitou vytv ranìch syst‚mov existuj£ r“znorod‚ vari cie §ivotn‚ho cyklu programu. élohou tvorcov softv‚rov‚ho syst‚mu je v etape analìzy pou§ivate–skìch po§iadaviek (ktor  je s£casœou vçetkìch vari ci¡) vybraœ pre çpecifickì pr¡pad najvhodnejçiu vari ciu. V tejto kapitole sme uviedli podrobnejçi opis V-modelu. Pre preh–ad uvedieme nieko–ko Ôalçich, ktor‚ vo v„csine pr¡padou s£visia s dohodnutìm postupom preberania Ÿast¡ vytvorenej aplik cie pou§ivate–om. 2.2.1. Jednof zovì model (BIG BANG) ----------------------------------- Jednof zovì model §ivotn‚ho cyklu programu predpoklad  jednor zov‚ dodanie vytvoren‚ho syst‚mu. Etapa çpecifik cie po§iadaviek a architektonick‚ho n vrhu syst‚mu je vykonan  pre celì syst‚m v spolupr ci s pou§ivate–om, no n vrh jednotlivìch modulov, ich implement cia a testovanie prebieha paralelne bez pou§ivate–a. Po integr cii produktu sa vytvorenì syst‚m dod  pou§ivate–ovi ako celok. Model tak‚hoto pr¡stupu je ilustrovanì na OBR.2.2. OBR.2.2. - Jednof zovì model §ivotn‚ho cyklu programu. Uvedenì pr¡stup m  nieko–ko vìhod i nevìhod. Nespornou jeho prednosœou je skutoŸnosœ, §e predstavuje v s£casnosti najrìchlejçi pr¡stup k vìvoju softv‚rovìch syst‚mov. KeÔze mnoho aktiv¡t pri vìvoji m“ze prebiehaœ paralelne bez striktne urŸenej Ÿasovej n slednosti, tento pr¡stup umo§nuje efekt¡vne pl novaœ a vyu§ivaœ ludsk‚, finanŸn‚ a materi lne zdroje dod vate–skej organiz cie poŸas vìvoja syst‚mu. Tento pr¡stup sa doporuŸuje aplikovaœ, ak s£ splnen‚ nasledovn‚ predpoklady: - zrozumite–n‚ a presne formulovan‚ pou§ivate–sk‚ po§iadavky - po§iadavky pou§ivate–a s£ stabiln‚, tzn. s Ÿasom sa nemodifikuj£ - schopnosœ pou§ivate–a obozn miœ sa a akceptovaœ celì produkt naraz Jednof zovì pr¡stup vçak m  aj nieko–ko nevìhod, ktor‚ treba pri jeho vìbere zoh–adniœ. Prvou jeho nevìhodou je, §e pou§ivate– poŸas cel‚ho vìvoja produktu nem  mo§nosœ zasiahnuœ do jeho vìvoja. Kontaktom pou§ivate–a s produktom je iba vytv ranie çpecifik cie, akceptaŸn‚ testovanie a preberanie produktu. Takìto pr¡stup skrìva nebezpeŸenstvo, §e hotovì produkt, hoci vyv¡janì pod–a p“vodnìch po§iadaviek, nemus¡ sp’naœ pou§ivate–ove predstavy o produkte. V praxi sa pou§ivatelia mnohokr t br nia prevzatiu cel‚ho produktu naraz, preto§e pri rozsiahlych syst‚moch sa nac¡tia byœ kvalifikovan¡ v limitovanom Ÿase rozhodn£t o akcept cii cel‚ho syst‚mu naraz. Jednof zovì model vçak prin sa vysok‚ riziko v zmysle invest¡ci¡ do vìvoja syst‚mu. Ak je rozpoŸet projektu prekroŸenì a pou§ivate– nem  prostriedky na jeho Ôalçie financovanie, nem  k dispoz¡cii ani Ÿasœ pou§ite–n‚ho syst‚mu. Z tohoto d“vodu pri nespr vnom odhade n kladov sa takìto sp“sob dodania produktu konŸi ne£spechom a stratami. Nemennosœ pou§ivate–skìch po§iadaviek poŸas cel‚ho procesu vìvoja syst‚mu predstavuje dosœ z va§nì probl‚m. Model toti§ neobsahuje prostriedky, ktor‚ by umo§novali vysporiadaœ sa so zmenami po§iadaviek, ku ktorìm m“ze d“jsœ poŸas vìvoja syst‚mu. Taktie§ jednor zov‚ zvl dnutie produktu m“ze sp“sobovaœ pri rozsiahlejçich syst‚moch probl‚my. Z tohoto d“vodu je potrebn‚ d“kladne analyzovaœ mo§nosti zaçkolovania pou§ivate–ov na vytv ranì syst‚m. Vo vçeobecnosti mo§no çkolenie zaŸaœ a§ po odovzdan¡ syst‚mu, preto jeho nasadenie do prev dzky bìva oneskoren‚. 2.2.2. F zovo-inkrement lny model --------------------------------- Pri f zovo inkrement lnom modele sa vykon , podobne ako u jednof zov‚ho modelu, çpecifik cia po§iadaviek a architektonickì n vrh pre celì syst‚m v spolupr ci s pou§ivate–om. Potom sa po dohode s pou§ivate–om stanov¡ priorita jednotlivìch modulov a na z klade tejto priority sa jednotliv‚ moduly v definovanìch f zach implementuj£, testuj£ a integruj£ do vytv ran‚ho syst‚mu. Tento model je ilustrovanì na OBR.2.3. OBR.2.3. - F zovo-inkrement lny model §ivotn‚ho cyklu programu Uvedenì model m  nesporn‚ prednosti, no i nedostatky. Medzi prednosti patr¡ postupnì vìvoj a odovzd vanie pou§ivate–ovi po Ÿastiach. Znamen  to, §e pri narazen¡ na ohraniŸenia finanŸn‚ho rozpoŸtu m  pou§ivate– k dispoz¡cii aspoå casœ vytv ran‚ho syst‚mu, ktorej pripisoval najv„csiu prioritu. Znamen  to, §e f zovo inkrement lny model zni§uje riziko invest¡ci¡ do vìvoja softv‚rovìch syst‚mov. Òalçou vìhodou, §e pou§ivate– vid¡ casœ syst‚mu v kratçom term¡ne v predch dzaj£com modele. Z tohoto d“vodu m  pou§ivate– k dispoz¡cii dlhçi cas na rozhodnutie o akcept cii jednotlivìch modulov, ako aj cel‚ho syst‚mu. Rovnako aj zaçkolovanie m“ze prebiehaœ postupne tak, ako s£ odovzd van‚ jednotliv‚ moduly. Medzi nevìhody tohoto modelu patr¡ neexistencia prostriedkov umo§nuj£cich modifik ciu p“vodnìch pou§ivate–skìch po§iadaviek. Taktie§ jednotliv‚ f zy predstavuj£ pomerne rozsiahle Ÿasi syst‚mu, ktorìch integr cia nie je vo v„csine pr¡padov jednoduch . 2.2.3. EvoluŸne-inkrement lny model ----------------------------------- EvoluŸno-inkrement lny model sa sna§i zakomponovaœ potrebu modifik cie p“vodnìch pou§ivate–skìch po§iadaviek do procesu vìvoja produktu. Tento pr¡stup vyplìva z poznania, §e vo v„csine projektov predstavuj£ p“vodn‚ pou§ivate–sk‚ po§iadavky iba hrubì n crt vytv ran‚ho syst‚mu. S postupom pr c na syst‚me sa tieto po§iadavky spresåuj£, Ÿim sa m“ze z roveå modifikovaœ u§ vytvoren‚ rieçenie. Òalçou zauj¡mavou myçlienkou je rozdelenie dod vky na mal‚ casti. Znamen  to, §e na rozdiel od f zovo inkrement lneho modelu nestoj¡ ot zka "ko–ko dodaœ v danej f ze", ale "ko–ko najmenej je nevyhnutn‚ dodaœ vo vytv ranom inkremente". Pl novanie takìchto malìch inkrementov je zvl dnute–nejçie a postup pr c lepçie kontrolovate–nì. V projektoch bìva mnohokr t i viac ako 20 inkrementov (i nieko–ko stov k). EvoluŸne-inkrement lny model je ilustrovanì na OBR.2.4. OBR.2.4. - evoluŸne-inkrement lny model §ivotn‚ho cyklu programu Okrem spomenutìch prednost¡ m  tento model viacero Ôalçich vìhod. Evidentnìm pr¡nosom je zn¡zenie rizika na prijate–n£ mieru. Je toti§ jednoduhçie ukonŸiœ vìvoj syst‚mu neuspokoj£ceho po§iadavky po 5 mesiacoch, ako po 5 rokoch. Òalçim pr¡nosom je orient cia na pou§ivate–a. Pou§ivate– m“ze akt¡vne zasahovaœ do n vrhu Ôalçieho inkrementu, tzn. neust le vylepçovaœ existuj£ci syst‚m. EvoluŸno-inkrement lny model taktie§ rieçi probl‚my odstraåovania chìb v produkte identifikovanìch poŸas prev dzky syst‚mu. Odstr nenie tìchto chìb m“zu byœ zakomponovan‚ medzi po§iadavkami v nasleduj£com inkremente syst‚mu. Pri aplik cii tohoto modelu je potrebn‚ uvedomiœ si aj jeho n roŸnosœ. V prvom rade je potrebn‚ maœ prepracovanì syst‚m spr vy konfigur cie syst‚mu. Taktie§ si treba uvedomiœ, §e £spech v znaŸnej miere z vis¡ od starostliv‚ho pl novania Ôalçich aktiv¡t. ¬astou chybou bìva, §e k realiz cii nasleduj£ceho inkrementu sa prikroŸi eçte pred ukonŸen¡m predch dzaj£ceho inkrementu. Toto m  za n sledok existenciu dvoch inkrementov, ktor‚ sa rozpracov vaj£ s£casne, Ÿo m“ze vy£stiœ v ne£spech projektu. 2.2.4. Prototypovanie --------------------- Prototypovanie predstavuje Ôalçi z pou§ivanìch pr¡stupov k vìvoju softv‚rovìch syst‚mov. Podstatou prototypovania je vytv ranie prototypov (modelov) bud£ceho syst‚mu, na ktorìch je mo§n‚ pou§ivate–ovi demonçtrovaœ vybran‚ aspektu bud£ceho syst‚mu. Takìto pr¡stup napom ha: - upresneniu nejasnìch po§iadaviek pou§ivate–a - overeniu novìch myçlienok a pr¡stupov - overeniu vybranìch pou§ivate–skìch po§iadaviek ich inkorpor cii do prototypu a prezent cii pou§ivate–ovi Model prototypov‚ho vìvoja syst‚mu je ilustrovanì na OBR.2.5. OBR.2.5. - model prototypov‚ho vìvoja softv‚rovìch syst‚mov Z h–adiska postupu pr c sa prototypovanie podob  na evoluŸne-inkrement lny model, preto§e na z klade hodnotenia predch dzaj£ceho prototypu sa vytv ra novì prototyp. Rozdiel vçak je, §e v danom prototype sa nevytv ra komplexn‚ rieçenie syst‚mu, ale iba prototyp na overenie urŸitìch vlastnost¡ a pr¡stupov k rieçeniu vybranìch probl‚mov. Òalçim podstatnìm rozdielom je, §e v poslednej etape (keÔ s£ u§ vçetky pou§ivate–sk‚ po§iadavky vyjasnen‚ a uzavret‚) sa vytv ra vlastnì syst‚m na z klade vyu§itia sk£senost¡ s vìvoja prototypov, priŸom vytvorenì k¢d sa Ôalej nevyu§iva. Je d“le§it‚ si uvedomiœ, §e k¢d prototypov by sa nemal pou§ivaœ vo vìslednom syst‚me, preto§e tento k¢d sa mnohokr t nevytv ra pod–a zadanìch pravidiel a nie s£ na neho kladen‚ tek‚ n roky ako na k¢d vìsledn‚ho syst‚mu. V tomto zmysle sa posledn  f za pprototypov‚ho modelu podob  na jednof zovì model. 2.2.5. Alfa-Beta cyklus ----------------------- Doposia– popisovan‚ modely §ivotn‚ho cyklu sa s£streÔovali na syst‚my, ktor‚ boli zameran‚ na limitovan‚ rozçirenie. V pr¡pade syst‚mov, u ktorìch sa predpoklad  masov‚ rozçirenie (napr. kompil tory, operaŸn‚ syst‚my, r“zne podporn‚ prostriedky) je potrebn‚ pri vìvoji syst‚mu postupovaœ inak. Pri vytv ran¡ syst‚mov, u ktorìch sa predpoklad  sirok‚ rozçirenie sa kladie mimoriadny d“raz na testovanie syst‚mu. Z tohoto d“vodu je potrebn‚ modifikovaœ zivotnì cyklus ro§siren¡m testovac¡ch et p. Z tohoto d“vodu sa do çtandardn‚ho §ivotn‚ho cykly zav dza vytvorenie Alfa a Beta verzi¡ syst‚mov pred vlastnìm odovzdan¡m syst‚mu do prev dzky. OBR.2.6. ilustruje rozçirenie jednof zov‚ho cyklu o vytvorenie Alfa a Beta verzi¡ vytv ran‚ho produktu. OBR.2.6. Alfa-Beta cyklus V Alfa-Beta cykle prebieha analìza po§iadaviek, n vrh a implement cia v softv‚rovej firme bez priamej £casti bud£cich pou§ivate–ov syst‚mu. Po vytvoren¡ produktu a jeho internom testovan¡ vznik  tzv. Alfa verzia produktu. Alfa verzia produktu predstavuje prv£ implement ciu vytv ran‚ho produktu. Preto predstavuje internì produkt pou§ivanì v r mci dod vate–skej firmy, ktorì eçte nie je mo§n‚ dodaœ z kazn¡kom. Pre testovanie Alfa-verzie je vybran  speci lna skupina z kazn¡kov, ktorìm sa poskytne mo§nosœ pracovaœ s Alfa-verziou produktu a kompletnou pou§ivate–skou dokument ciou v r mci dod vate–skej firmy. T to skupina bud£cich z kazn¡kov by sa nemala podielaœ na predch dzaj£com vìvoji syst‚mu, aby ich hodnotenie syst‚mu bolo nestrann‚. Po ukonŸen¡ testovania Alfa-verzie je na z klade pripomienok a odhalenìch chìb sa prevedie reimplement cia vybranìch Ÿast¡ produktu a zodpovedaj£cim sp“sobom sa zmen¡ pou§ivate–sk  dokument cia. Vytvorenì syst‚m sa nazìva Beta verzia syst‚mu. Beta verzia syst‚mu predstavuje testovaciu verziu, ktor  sa dod va vybranej skupine pou§ivate–ov na testovanie v r mci ich podmienok. Tìmto z kazn¡kom s£ poskytovanì ako konzultanti Ÿlenovia vìvojov‚ho t¡mu. Syst‚m je testovanì v r mci be§nej prev dzky, hoci pou§ivatelia si musia uvedomiœ, §e sa st le jedn  iba o Beta-verziu. Po dohodnutom Ÿase sa zhrn£ pripomienky pou§ivate–ov a tiato sa zakomponuj£ do produktu. Tìmto vznik  prv  verzia syst‚mu, ktor  sa komerŸne dod va çirok‚mu spektru z kazn¡kov. 2.3. élohy çpecialistov v §ivotnom cykle ---------------------------------------- Z opisu modelov §ivotn‚ho cyklu programu je zrejm  sirok  sk la aktiv¡t vykon vanìch pri vìvoji programovìch syst‚mov. Z tejto çirky vyplìva aj r“znorodosœ specialistov, ktor¡ sa na vìvoji aplik cie podie–aj£. S£ to najm„ nasledovn‚ skupiny çpecialistov: - analytici - n vrh ri - program tori - odborn¡ci na testovanie - manageri projektu a jednotlivìch et p. Pre lepçie pochopenie vìznamu jednotlivìch profesi¡ si pop¡seme £lohy, ktor‚ s£ jednotlivìmi skupinami çpecialistov zabezpeŸovan‚. ANALYTICI élohou analytika je vniknutie do problematiky spracovania inform ci¡ v organiz ci¡ pou§ivate–a a na z klade jeho po§iadaviek vytvoriœ architektonickì n vrh çtrukt£ry syst‚mu na z klade defin¡cie jednotlivìch funkŸnìch blokov a ich informaŸnìch prepojen¡. Analytik sa zap ja do pr c najm„ v etap ch çpecifik cie a analìzy pou§ivate–skìch po§iadaviek a architektonick‚ho n vrhu syst‚mu. Vìsledkami jeho pr ce s£ najm„: - kompletn  a konzistentn  specifik cia pou§ivate–skìch po§iadaviek - n vrh funkŸnej dekompoz¡cie syst‚mu s definovanìmi informaŸnìmi prepojeniami medzi jednotlivìmi funkŸnìmi modulmi - n vrh potrebnìch internìch informaŸnìch çtrukt£r V mnohìch organiz ci ch sa Ÿasto £loha analytika zamieåa s £lohou n vrh ra, resp. program tora. V ka§dom pr¡pade vçak analytik mus¡ maœ sk£senosti v programovan¡ a n vrhu syst‚mov. éloha analytika je ve–mi n roŸn , preto§e mus¡ rieçiœ probl‚my, na ktor‚ neexistuje jednoznaŸn  a jedin  spr vna odpoveÔ. N vrh syst‚mu bìva vìsledkom mnohìch kompromisov. Jadro pr ce analytika vçak spoŸiva v intenz¡vnej komunik cii s pou§ivate–mi. Z tohoto d“vodu mus¡ maœ bohat‚ sk£senosti v komunik cii s –uÔmi. Rovnako sa vy§aduj£ znalosti s pr ce s podpornìmi prostriedkami, napr. CASE syst‚mami. NµVRHµRI élohou n vrh ra je vytvorenie çpecifik cie poŸitaŸov‚ho rieçenia pou§ivate–ovho probl‚mu. Tento n vrh zahråuje: - çpecifik ciu sp“sobu realiz cie jednotlivìch funkŸnìch modulov (popis algoritmov) - çpecifik ciu fyzickej çtrukt£ry £dajov spracov vanìch navrhovanìm syst‚mom - çpecifik ciu pou§ivate–sk‚ho rozhrania a sp“sobu komunik cie medzi pou§ivate–om avytv ranìm syst‚mom N vrh r je akt¡vny najm„ v etape architektonick‚ho n vrhu a etape podrobn‚ho n vrhu modulov. N vrh r mus¡ taktie§ vyberaœ z mnohìch alternat¡v. Mus¡ maœ sk£senosti programovania, aby vedel zhodnotiœ d“sledky vìberu ist‚ho sp“sobu rieçenia na vlastnosti vìsledn‚ho syst‚mu. U n vrh ra sa taktie§ vy§aduj£ sk£senosti v pr ci s CASE syst‚mami. PROGRAMµTORI élohou program tora je implement cia navrhnut‚ho rieçenia. Jeho znalosti maj£ byœ z oblasti programovac¡ch jazykov, podpornìch prostriedkov a operaŸnìch syst‚mov. Pr ca program tora je presn  a kontrolovate–n : program alebo vyhovuje çpecifik cii, alebo nie. ¬astokr t sa £loha analytika, n vrh ra a program tora sp ja. V tomto pr¡pade analìzu, n vrh a k¢dovanie vykon va t  ist  osoba. Takìto pr¡stup nie je akceptovate–nì a v„csich projektov, preto§e obmedzuje mo§n‚ alternat¡vy skorìm zoh–adåovan¡m mo§nìch implementaŸnìch probl‚mov. ODBORNÖCI NA TESTOVANIE Testovanie je taktie§ d“le§it  casœ v procese vìvoja programu. Testovanie spoŸiva v preuk zan¡ funkŸnosti (resp. nefunkŸcnosti) Ÿasti syst‚mu, alebo jeho modulu, na vybranej vzorke vstupnìch £dajov. Prv‚ testovanie pri vìvoji programu vykon vaj£ samotn¡ program tori. KoneŸn‚ testovanie modulu by vçak nemal vykon vaœ jeho tvorca a, navyçe, toto testovanie by sa malo vykon vaœ systematicky, aby sa testovan¡m pokryla Ÿo najv„csia Ÿasœ k¢du. Testovanie je pomerne zlo§it  oblasœ, ktorej sa budeme venovaœ nesk“r. Z tejto zlo§itosti vçak vyplìva, §e testovaniu by sa mal venovaœ speci lny odborn¡k, nie program tor. MANAGER PROJEKTU Manager projektu predstavuje jednu z najd“le§itejçich osobnost¡, ktor  m“ze podstatnou mierou ovplyvniœ uspech cel‚ho projektu. Treba si uvedomiœ, §e £loha managera sa nem“ze vykon vaœ ako doplnkov  cinnosœ, tzn. §e management projektu zaber  celì pracovnì cas managera. Jeho hlavnìmi £lohami s£: - pl novanie cel‚ho projektu a jeho jednotlivìch et p - odhady n kladov a sleduje ich vyu§ivanie - sledovanie a koordin cia pr c na projekte, identifik cia probl‚mov a neust le prepl novanie - bezprostredne informuje high-management o vzniknutìch probl‚moch (zl  inform cia neskoro je eçte horçia) - sledovanie dodr§iavanie metodol¢gie vìvoja produktu a kvalitat¡vnych atrib£tov produktu - komunik cia s managementom v pou§ivate–skej organiz cii 2.4. Z kladn‚ princ¡py £speçnosti v softv‚rovom in§inierstve ------------------------------------------------------------ Vìvoj rozsiahlych softv‚rovìch syst‚mov nie je proces pokusov a omylov. Ako sme u§ uviedli, je to proces, ktorì m  svoje presn‚ pravidl  a postupnosœ pr c ved£cich ku koneŸn‚mu produktu. Mimo tejto vçeobecnej metodol¢gie je vhodn‚ spomen£t nieko–ko z kladnìch princ¡pov (viÔ. napr. [Benjamin:1971]), ktor‚ je potrebn‚ maœ na mysli pri celom vìvoji programov‚ho syst‚mu. Tieto princ¡py boli formulovan‚ na z klade praktickìch sk£senost¡ empiricky z¡skanìch pri vìvoji mno§stva projektov. Princ¡p 1: Vytvorenì syst‚m je pre pou§ivate–ov Ka§dì vytvorenì syst‚m je mo§n‚ posudzovaœ na z klade dvoch aspektov: - £zitkov‚ vlastnosti syst‚mu - kvalita technick‚ho rieçenia syst‚mu ézitkov‚ vlastnosti syst‚mu predstavuj£ s£hrn vonkajçich prejavov syst‚mu vzh–adom k pou§ivate–ovi. Medzi £zitkov‚ vlastnosti je mo§n‚ zaradiœ napr. pohodlnosœ komunik cie so syst‚mom, preh–adnosœ a uniformitu rozhran¡, zlo§itosœ aktiv cie vybranej Ÿinnosti, kontextovo z visl‚ pomocn‚ vìpisy a n povedi atÔ. S£ hlavnìm krit‚riom hodnotenia a akcept cie syst‚mu v praxi. Kvalita technick‚ho rieçenia predstavuje £roveå vo–by prostriedkov a techn¡k pre dosahovanie po§adovanìch vlastnost¡ syst‚mu. Uveden‚ dva poh–ady na syst‚m bìvaj£ casto predmetom sporov medzi tvorcami syst‚mu a jeho pou§ivate–mi. Pou§ivate–ia posudzuj£ syst‚m na z klade jeho vonkajçich prejavov, tzn. kvality pou§ivate–skìch rozhran¡ a stupåa zhody medzi ich predstavami o syst‚me a skutoŸnìm fungovan¡m syst‚mu. Technick‚ rieçenie syst‚mu ost va pred pou§ivate–mi v„csinou skryt‚, preto nebìva vo v„csine pr¡padov n le§ite oceåovan‚. Tvorcovia syst‚mu vçak venuj£ pozornosœ predovçetkìm technick‚mu rieçenie a kvalita pou§ivate–skìch rozhran¡ predstavuje pre nich Ÿastokr t a§ druhoradì probl‚m, napr. iba form lnu prezent ciu vìsledkov implementovan‚ho spracovania £dajov. Prvìm predpokladom £speçn‚ho projektu je zabr neniu vytv rania vzœahov typu "oni-my", tzn. rozdeleniu zainteresovanìch na skupinu pou§ivate–ov obhahuj£cich £zivate–sk‚ vlastnosti syst‚mu a na skupinu tvorcov zameranìch iba na kvalitu technick‚ho rieçenia. S£casn‚ trendy doporuŸuj£ zapojenie pou§ivate–a vo vçetkìch etap ch vìvoja syst‚mu (JAD met¢da, o ktorej budeme hovoriœ nesk“r), kde je bezprostredne mo§n‚ prisp“sobovaœ navrhovan‚ rieçenie jeho po§iadavk m na pou§ivate–skì komfort a dosahovaœ potrebn‚ kompromisy. Tìmto sp“sobom sa vytv ra pocit spolupatriŸnosti k vytv ran‚mu rieçeniu a n vrhov‚ rozhodnutia vykon vaœ na z klade konsensu. "Dobrì" syst‚m mus¡ dosiahnuœ integr ciu oboch uvedenìch krit‚ri¡. Treba si uvedomiœ (na Ÿo sa mnohokr t zab£da), §e akoko–vek brilantn‚ technick‚ rieçenie nezabezpeŸuj£ce pou§ivate–ovi po§adovan‚ pohodlie v pr ci sa pre neho st va nepou§ite–n‚, Ÿo vedie k ne£spechu a zavrhnutiu cel‚ho prokjektu. Pou§ivate– je koneŸnìm hodnotite–om pou§ite–nosti vytvoren‚ho syst‚mu. V praxi je mnohokr t akceptovan‚ menej kvalitn‚ technick‚ rieçenie, no s prepracovanìm pou§ivate–skìm rozhran¡m a zabezpeŸuj£ce vçetky jeho po§iadavky. Princ¡p 2: Presne definujte etapy a £lohy v nich ¦ivotnì cyklus programu doporuŸuje rozŸlenenie projektu na jednotliv‚ etapy, priŸom iba ve–mi struŸne popisuje s£hrn Ÿinnost¡, ktor‚ sa maj£ v jednotlivìch etap ch vykonaœ. Jednotliv‚ projekty sa vçak l¡sia, preto je potrebn‚ zivotnì cyklus pre konkr‚tny projekt prisp“sobiœ. Tìka sa to hlavne dekompoz¡cie jednotlivìch et p na konkr‚tne pod£lohy, ktorìch plnenie je –ahçie sledovate–n‚. Pre konkr‚tny projekt je nesmierne d“le§it‚ pl novanie, tzn. presn‚ definovanie Ÿinnost¡, ktor‚ je v danej etape potrebn‚ realizovaœ, zodpovednosœ za vykonanie tìchto Ÿinnost¡, ich n v„znosti a odhady zlo§itosti, n kladov a trvania jednotlivìch Ÿinnost¡. Princ¡p 3: Vìvoj programov‚ho syst‚mu nie je iba sekvenŸnì proces ¦ivotnì cyklus zn zoråuje plnenie jednotlivìch et p sekvenŸne. V praxi to vçak neznamen , §e dan£ etapu je mo§n‚ zaŸaœ a§ po skonŸen¡ predch dzaj£cej. V skutoŸnosti sa m“zu jednotliv‚ etapy i prekrìvaœ, no pre jednotliv‚ ulohy v etap ch je potrebn‚ zachov vaœ sekvenŸnosœ dan£ nevyhnutnìmi predpokladmi pre ich zaŸatie. V §ivotnom cykle programu m“ze nastaœ situ cia, keÔ je potrebn‚ prepracovaœ produkt etapy, ktor  u§ bola ukonŸen . V pr¡pade n vrhu syst‚mu je mo§n‚ identifikovaœ po§iadavky, ktor‚ v etape çpecifik cie neboli identifikovan‚ a zahrnut‚ do çpecifik cie. Je preto potrebn‚ n vrat k ukonŸenej etape a prepracovanie doposia– vytvoren‚ho rieçenia. Znamen  to zavedenie iter cie do §ivotn‚ho cyklu programu. Princ¡p 4: Softv‚rov‚ projekty s£ invest¡cie kapit lu Tvorba softv‚rov‚ho syst‚mu sa z h–adiska invest¡cie v niŸom neodliçuje napr. od vìstavby budovy. Takìto poh–ad na vìvoj softv‚rovìch syst‚mov m  za n sledok zva§ovanie efekt¡vnosti ka§dej invest¡cie vlo§enej do vìvoja v porovnan¡ s oŸak vanìmi pr¡nosmi. Softv‚rov‚ syst‚my vo v„csine pr¡padov s£ vyv¡jane preto, aby pou§ivate–ovi prin sali zisk. Z h–adiska tvorcov syst‚mu takìto poh–ad prin sa nasledovn‚ aspekty: - pre ka§dì probl‚m existuje viacero alternat¡v rieçenia. Preto je potrebn‚ v§dy identifikovaœ vçetky mo§n‚ alternat¡vy rieçenia - ka§d  alternat¡va rieçenia je charakterizovan  urŸitìmi n kladmi spojenìmi s jej realiz ciou a oŸak vanìmi pr¡nosmi. Z tohoto d“vodu je potrebn‚ pre ka§d£ z alternat¡v vykonaœ analìzu pr¡nosov vzh–adom na potrebn‚ n klady (vìvoj a prev dzka syst‚mu) - vìber jednej z alternat¡v je potrebn‚ vykon vaœ v spolupr ci s pou§ivate–mi (zad vate–mi projektu), ktor¡ rozhodn£ o invest¡cii do urŸitej z alternat¡v Princ¡p 5: Neob vajte sa zastaviœ projekt Koncepcia zavedenia §ivotn‚ho cyklu do vìvoja softv‚rovìch syst‚mov umo§nuje vyhodnocovaœ aktu lnosœ dalçieho vìvoja syst‚mu po ukonŸen¡ ka§dej vìvojovej etapy. Na z klade tohoto vyhodnotenia je mo§n‚ zastaviœ projekt, ak nesplåuje z kladn‚ oŸak vania. Rozhodovanie o pokraŸovan¡ pr c na projekte sa m  vykon vaœ po ukonŸen¡ ka§dej etapy. Vo v„csine pr¡padov existuje tendencia k nezastaveniu projektu z d“vodov straty u§ vynalo§enìch invest¡ci¡. Doposia– vynalo§en‚ invest¡cie je vçak pri rozhodovan¡ treba pova§ovaœ za nen vratne investovan‚, tzn. nie je mo§n‚ ich z¡skaœ sp„t. Skor‚ zastavenie projektu m“ze uçetriœ invest¡cie vlo§en‚ do Ôalçieho vìvoja nepou§ite–n‚ho alebo neperspekt¡vneho produktu. Princ¡p 6: Dokument cia je produkt vçetkìch et p NajŸastejçou chybou, ktor  sa vyskytuje u softv‚rovìch projektov, je chìbaj£ca dokument cia. Dokument cia sa vytv ra poŸas cel‚ho vìvoja softv‚ru a ka§dì vìvojovì krok mus¡ byœ zdokumentovanì. Priebe§n  tvorba dokument cie umo§nuje aplik ciu met¢d zvyçovania kvality. V praxi sa Ÿastokr t za dokument ciu pova§uje iba pou§ivate–sk  dokument cia. Toto je vçak iba zlomok dokument cie vytv ranej poŸas vìvoja syst‚mu. Odhaduje sa, §e na priemerne na 5 riadkov v programe je potrebnì jeden riadok dokument cie. Dokument ciu nie je mo§n‚ vytv raœ dodatoŸne a dokument cia je z kladnìm predpokladom pre modifik cie syst‚mu vyplìvaj£cich z jeho prev dzky. Z uveden‚ho preh–adu je zrejm‚, §e vìvoj softv‚rovìch syst‚mov je nesmierne zlo§itì proces, ktorì vy§aduje zapojenie znaŸnìch materi lnych a intelektu lnych zdrojov. Aby tieto zdroje neboli premrhan‚, je potrebn‚ aplikovaœ modern‚ met¢dy vìvoja a riadenia projektov. Tieto met¢dy je mo§n‚ vidieœ v dvoch aspektoch: - metodol¢gie analìzy, n vrhu a implement cie syst‚mov - metodol¢gie managementu softv‚rovìch projektov. Tìmto aspektom bud£ venovan‚ nasledovn‚ kapitoly.