10.3.11.2. Inçpekcie dokumentov ------------------------------- Inçpekcia dokumentov predstavuje jeden z pr¡stupov k zabezpeŸovaniu kvality. Najzn mejçou technikou s£ Faganove inçpekcie. Pre ilustr ciu d“le§itosti inçpekcie je mo§n‚ uviesœ vìsledky meran¡ pre z kladn‚ atrib£ty procesu tvorby softv‚rovìch syst‚mov a produktov: term¡n dodania - 25-30% ni§sie n klady na projekt - 25-30% ni§sie n klady na prev dzku - 10 - 30 n sobne ni§sie spo–ahlivosœ - 10 - 100 kr t menej chìb testovanie - 85% zlepçenie Vykon vanie inçpekcie vçak vy§aduje i dodatoŸn‚ n klady. Vo vçeobecnosti sa predpoklad  vzrast n kladov o 15% v s£vislosti s vlastnìmi inçpekciami a 30% v s£vislosti s potrebnìm prepracov van¡m dokumentov. Tieto n klady je potrebn‚ zahrn£t do pl nu projektu. Pou§itie Faganovìch inçpekci¡ pom haœ zabezpeŸiœ, §e: - çpecifik cie cie–ov a rieçen¡ s£ upln‚ a interne konzistentn‚ - ciele projektu a jeho technick  realiz cia je realistick  - çpecifik cie cie–ov a rieçen¡ s£ konzistentn‚ so strategickìmi cie–mi pou§ivate–skej organiz cie - çpecifik cie s£ jasn‚ a jednoznaŸn‚ Inçpekcie sa vykon vaj£ pre dokumenty produkovan‚ poŸas projektu. élohy jednotlivìch £castn¡kov procesu inçpekcie s£ nasledovn‚: moder tor - je zodpovednì za vykonanie dobrej inçpekcie a z¡skanie £dajov z inçpekcie. M  k–ucov£ ulohu vo vçetkìch f zach inçpekcie, okrem f xzy prepracovania. autor - poskytuje inform cie o produkte vo vçetkìch f zach, okrem prepracovania. Je zodpovednì za ostr nenie vçetkìch chìb v produkte, ktor‚ s£ v r mci stanoven‚ho Ÿasov‚ho harmonogramu. Ÿitate– - koordinuje pr cu t¡mu poŸas stretnut¡. ¬ita, resp. opisuje produkt na stretnutiach. Mal by byœ inçpektorom danej etapy pr c a mal by byœ s pr cou na produkte obozn menì. Vo v„csine pr¡padov vykon va aj £lohu inçpektora. zapisovate– - zodpovednì za zaznamenanie ka§dej identifikovanej chyby poŸas stretnutia. M“ze to byœ aj jeden z inçpektorov. inçpektor - je zodpovednì za identifik ciu chìb v projekte na z klade svojich sk£senost¡, alebo na z klade çpeci lneho zamerania inçpekcie. Proces inçpekcie mo§no rozŸleniœ do jednotlivìch aktiv¡t nasledovne: Pl novanie Pri strategickom pl novan¡ inçpekci¡ je potrebn‚ stanoviœ, ktor‚ dokumenty bud£ podroben‚ inçpekcii. V tejto etape s£ taktie§ urŸen‚ krot‚ri , za ktorìch m“ze byœ dokument podrobenì inçpekcii. Pri pl novan¡ konkr‚tnej inçpekcie je potrebn‚ stanoviœ moder tora, ktorì bude zodpovednì za vykonanie inçpekcie. Moder tor Ôalej zabezpeŸuje distrib£ciu dokumentov, stanovenie miesta a term¡nu inçpekŸn‚ho stretnutia. D“le§itou £lohou moder tora je urŸenie inçpektorov, ktor¡ bud£ vlastn£ inçpekciu dokumentu vykon vaœ. Inçpektori vykon vaj£ inçpekciu na z klade dodanìch dokumentov. KeÔze sa inçpekcia vykon va pre vìstup urŸit‚ho vìvojov‚ho kroku, k dodatoŸnej dokument cii (tzn. okrem vlastn‚ho dokumentu, ktor‚ho inçpekcia sa vykon va) patr¡: - dokument, ktor‚ho inçpekcia sa vykon va - dokumenty reprezentuj£ce vstupn‚ inform cie pre danì vìvojovì krok - çtandardy a metodol¢gie aplikovan‚ v danom vìvojovom kroku alebo pri tvorbe zodpovedaj£ceho typu dokumentu - zoznam £loh, ktor‚ ma inçpektor vykonaœ (task-list) - zoznam chìb, na ktor‚ je potrebn‚ s£strediœ pozornosœ (check-list) Pre pl novanie inçpekcie je d“le§itì rozsah dokumentov, ktor‚ bud£ podroben‚ inçpekcii. DoporuŸovan‚ rozsahy dokumentov pre inçpekciu na jednom stretnut¡ pre jednotliv‚ typy dokumentov s£ nasledovn‚: çpecifik cia po§iadaviek - 15 - 25 str n funkŸnì n vrh - 15 - 25 str m architektonickì n vrh - 20 - 35 str n podrobnì n vrh - 25 - 45 str n zdrojovì k¢d - 500 riadkov a aj menej v pr¡pade zlo§itejçich modulov pl n testovania - 25 - 40 str n testovacie proced£ry - 25 - 45 str n Preh–ad KeÔze sa pri vìbere inçpektorov predpoklad , §e inçpektori nebud£ priamy tvorcovia dokumentu, je vhodn‚ uskutoŸniœ oboznamovacie stretnutie. Toto stretnutie by malo trvaœ 30-60 min a je zameran‚ na obozn menie sa s cie–mi inçpekcie a s kontextom dokumentu, ktor‚ho inçpekcia sa vykon va. V r mci oboznamovacieho stretnutia m“zu inçpektori obdr§aœ i vybran‚ dokumenty a obozn miœ sa s konkr‚tnymi £lohami v inçpekcii. Pr¡prava Ka§dì z inçpektorov mus¡ inçpekciu vykonaœ samostatne. Za tìmto £celom sa najsk“r mus¡ obozn miœ s dokumentami definuj£cimi kontext dokumentu, ktor‚ho inçpekcia sa bude vykon vaœ. Inçpektor sa mus¡ obozn miœ so çpecifickou £lohou pri inçpekcii, napr. zameran¡m na urŸit‚ typy chìb. Po obozn men¡ sa z £lohami a dokumentom pvykon va vlastn£ inçpekciu. Vlastnej pr¡prave, tzn. realiz cii inçpekcie sa venuje zhruba 30% cel‚ho Ÿasu. Vìsledkom inçpekcie je zoznam detekovanìch chìb v sledovanom dokumente. Moder tor m“ze na z klade tìchto dokumentov rozhodn£t o term¡ne stretnutia. InçpekŸn‚ stretnutie Cie–om inçpekŸn‚ho stretnutia je sumariz cia chìb v dokumente. DoporuŸovan  d’zka stretnutia by nemala presiahnuœ 2 hodiny. Na stretnut¡ sa z£caståuje celì t¡m. Nebìva zvykom, aby sa na inçpekŸnom stretnut¡ z£caståoval i tvorca (tvorcovia) dokumentu. Stretnutie vedie moder tor, ktorì na zaŸiatku stanov¡ ulohy z£castnenìch. ¬itate– potom prezentuje produkt, ktorì je podrobovanì inçpekcii. V £vodnej prezent cii m  podaœ logickì preh–ad o obsahu produktu. V n v„znosti na prezent ciu jednotlivì inçpektori uv dzaj£ chyby, ktor‚ v dokumente identifikovali. Ka§d  chyba sa klasifikuje na z klade d“sledkov, kateg¢rie a typu: d“sledky: z va§n‚ - chyba, ktor  by sp“sobila zlyhanie syst‚mu, alebo zabr nila dosiahnutiu oŸak van‚ho vìsledku - chyba, ktor  sp“sob¡ vytvorenie cybnej spr vy, alebo po§iadavku na zmenu v Ôalçej f ze projektu mal‚ - ka§d  in  chyba kateg¢rie: - chìbaj£ca inform cia - zl  inform cia - inform cia navyçe typy: - jasnosœ - £plnosœ - zl  v„zba - konzistencia - spr vnosœ - pou§itie £dajov - funkcionalita - interfejsy - £roveå podrobnosti - udr§ovate–nosœ - vìkonnosœ - spo–ahlivosœ - testovate–nosœ - trasovate–nosœ - inì Chyby v dokumente identifikovan‚ jednotlivìmi inçpektormi sa zapisuj£ do vìstupn‚ho materi lu stretnutia. Na stretnut¡ nie je povolen  ziadna diskusia o opodstatnenosti chyby, ani o mo§nosti jej odstr nenia. T to skutoŸnosœ m  nasledovn‚ d“vody: - je efekt¡vnejçie ponechaœ rozhodnutie o tom, Ÿi identifikovan  chyba je skutoŸne chybou alebo nie na pracovn¡kovi, ktorì bude urŸenì na jej odstr nenie - diskusia o povahe chyby m“ze potlaŸiœ odvahu rev¡zorov detekovaœ i chyby, o ktrìch s£ si nie celkom ist¡ - diskusia o odstr nen¡ chyby nie je cie–om inçpekŸn‚ho stretnutia - autor najlepçie pozn  povahu probl‚mu, teda i mo§nosti optim lneho odstr nenia chyby InçpekŸn‚ stretnutia sa vyznaŸuj£ znaŸnìm stupåom synargie. Znamen  to, §e vìslednì poŸet identifikovanìch chìb je zv„csa v„csi ako s£cet chìb identifikovanìch jednotlivìmi inçpektormi. Atmosf‚ra diskusie okolo dokumentu poŸas stretnutia inçpiruje k identifik cii Ôalçich chìb. Prepracovanie Po stretnut¡ je zoznam identifikovanìch chìb pridelenì autorom dokumentu na prepracovanie. Autori v tomto pr¡pade musia spolu s moder torom rozhodn£t, Ÿi prvom dodan‚ho zoznamu predstavuje skutoŸn£ chybu alebo nie. Odstraåovanie chyby rob¡ autor pr¡sluçnej Ÿasti dokumentu. Oprava chyby m“ze maœ za n sledok inicializ ciu po§iadavky na zmenu u§ schv len‚ho produktu, preto £zko s£vis¡ s proced£rou riadenia zmien. O ukonŸen¡ odstr nenia chyby rozhodne autor. N sledne sa kontroluje iba odstr nenie chìb oznaŸenìch ako z va§n‚. Odstr nenie ostatnìch chìb sa nekontroluje, iba eviduje. Overenie prepracovania Overenie prepracovania vykon va moder tor pre vçetky chyby oznaŸen‚ ako z va§n‚. T to aktivita m  za £cel taktie§ sledovanie z kladnìch çtatist¡k procesu inçpekcie, ako poŸet identifikovanìch chìb, Ÿas potrebnì na odstr nenie chìb atÔ. Uzavretie inçpekcie Pri uzatv ran¡ inçpekcie moder tor kontroluje, Ÿi vçetky podmienky na vìstupnì dokument splnen‚, napr. odstr nenie vçetkìch chìb, doplnenie £dajov do çtatist¡k inçpekcie atÔ. 10.3.12. Extern  rev¡zia projektu --------------------------------- Extern  rev¡zia projektu je spojen  so zabezpeŸovan¡m kvality vytv ran‚ho produktu. Jej podstata je vykon vanie rev¡zi¡ cast¡ projektu externìmi, projektom nezaœa§enìmi, expertami. D“vody pre potrebu externìch rev¡zi¡ je mo§n‚ zhrn£t nasledovne: 1._f zy: prijekt je zvyŸajne vykon vanì vo f zach, ktor‚ s£ na sebe bezprostredne z visl‚. Tieto z vislosti pri n¡zkej kvalite vstupov nasleduj£cej f zy m“zu v tejto f ze sp“sobovaœ probl‚my. 2._pou§ite–nosœ: pokia– sa nesleduje kvalita produktu, jeho pou§ite–nosœ kles . T to skutoŸnosœ m  za n sledok neefekt¡vne vykon vanie funkci¡, zvìsen‚ prev dzkov‚ n klady a stratu d“veru v syst‚m. 3._n klady: probl‚my m“zu byœ nepredikovate–n‚, no m“zu byœ jednak n kladnejçie vzh–adom na ich odstraåovanie. Je zn mou skutoŸnosœou, §e Ÿim nesk“r je chyba detekovan , tìm vyçsie n klady s£ viazan‚ na jej odstr nenie. 4._£dr§ba: v pr¡pade, §e neidentifikovan‚ chyby ost vaj£ v dodanom produkte, n klady sa ich odstraåovanie sa pres£vaj£ do £dr§by Extern  rev¡zia projektu sa vo v„csine pr¡padov vykon va expertami nezainteresovanìmi na projekte. Extern‚ rev¡zie m“zu byœ pl novan‚ (na konci urŸitìch et p alebo pri dosiahnut¡ kontrolnìch bodov), alebo vy§iadan‚ (v pr¡pade, §e v projekte sa objavia probl‚my). V tomto pr¡pade sa rev¡zii m“ze podrobiœ lubovo–nì dokument. Aktivita spojen  s externìmi rev¡ziami pozost va z troch f z: pl novania, vykon vania rev¡zie a sumariz cie rev¡zie. 10.3.12.1. F zy zabezpeŸovania externej rev¡zie ----------------------------------------------- Pl novanie ---------- Cie–om pl novania externej rev¡zie je vytvorenie rev¡zneho t¡mu, pr¡prava pl nu rev¡zi¡ a jeho ods£hlasenie managementom. 1. pri zaŸleåovan¡ externej rev¡zie do pl nu zabezpeŸovania kvality je potrebn‚ zv ziœ rizik  projektu: - mo§nosœ ovplyvnenia finanŸnej n roŸnosti - zlo§itosœ syst‚my (funkcie, interfejsy, vplyv na in‚ syst‚my) - rozsah zmien sp“sobu spracovania inform ci¡ u pou§ivate–a - oŸak vania a stanovisk  pou§ivate–a - pou§itie novej technol¢gie - rozsah projektu - sk£senosti projekŸn‚ho t¡mu 2. vytvorenie rev¡zneho t¡mu - ved£ci rev¡zneho t¡mu mus¡ maœ aspoå tak‚ sk£senosti ako manager projektu - ved£ci rev¡zneho t¡mu je zodpovednì za priradenie jednotlivìch expertov aktivit m vykon vanìm poŸas rev¡zi¡ 3. pr¡prava pl nu externìch rev¡zi¡ - rozsah rev¡zie - rozpoŸet - identifik cia bodov, v ktorìch sa bude rev¡zia vykon vaœ - po§adovan‚ sk£senosti a dostupn‚ zdroje - z vislosti a ohraniŸenia 4. z¡skanie s£hlasu managementu pre pl n externìch rev¡zi¡ Vykonanie rev¡zie ----------------- Cie–om vykonania rev¡zie je pripravenie rev¡zie, vykonanie rev¡zie, vypracovanie rev¡znej spr vy a vytvorenie pl nu Ôalçich Ÿinnost¡. 1. pr¡prava rev¡zie projektu - stretnutie s projekŸnì t¡mom za £celom vysvetlenia £celu a met¢d rev¡zie a vytvorenia dobrìch pracovnìch vzœahov - aktualiz cia pl nu projektu vzh–adom k rev¡zii - zaslanie managerovi projektu zoznam aspektov, ktor‚ bud£ rev¡ziou pokryt‚ - z¡skanie relevatnej dokument ci pre rev¡ziu - zabezpeŸenie, §e vçetka dokument cia bola prehliadnut  pred vlastnìm rev¡znym stretnut¡m 2. vykonanie rev¡zie projektu - rev¡zia pozost va s rev¡znych stretnut¡ vedenìch ved£cim rev¡zneho t¡mu - met¢dy rev¡zie zahråuj£: - prezent cie - spoloŸn£ rev¡ziu obdr§anìch dokumentov - inçpekcie - prehliadky - naŸrtnutie cie–ov rev¡zneho stretnutia - riadenie rev¡zneho stretnutia - vyhìbanie sa koment rom o çtìle dokumentu - zabezpeŸenie zapisovania priebehu rev¡zneho stretnutia - byœ pripravenì zastaviœ rev¡zie ak: - prijekt nie je pripravenì na rev¡ziu - rev¡zny t¡m nie je pripravenì na rev¡ziu - bola identifikovan  z sadn  chyba, ktorou sa diskusia o kvalite stava bezpredmetn  - £castn¡ci stretnutia nie s£ ochotn¡ spolupracovaœ - dopredu stanovenì cas stretnutia bol prekroŸenì 3. vytvorenie rev¡znej spr vy - zodpovednosœ: ved£ci rev¡zneho t¡mu - distrub£cia: manager projektu, riadiaci org n - doporuŸovanì obsah: - obsah rev¡zie z h–adiska pl nu projektu - zameranie rev¡zie - elimin cia rizika 4. vytvorenie akŸn‚ho pl nu - zodpovednosœ: ved£ci rev¡zneho t¡mu - distrub£cia: manager projektu, riadiaci org n - cie–om je navrhn£t akŸnì pl n v z vislosti od vìsledkov rev¡zie Sumariz cia rev¡zie ------------------- Cie–om je zhodnotiœ pr¡nos rev¡zie z h–adiska projektu. 1. Hodnotiaca spr va o rev¡zii - zodpovednosœ: ved£ci rev¡zneho t¡mu - distrub£cia: riadiaci org n - doporuŸovanì obsah: - n klady rev¡zie vzh–adom na rozpoŸet projektu - rozsah rev¡zie - pr¡nosy rev¡zie pre projekt - identifikovan‚ probl‚my - doporuŸenia k bud£cim zmen m v met¢dach rev¡zi¡ 10.3.12.2. NajŸastejçie sledovan‚ aspekty projektu -------------------------------------------------- Inici cia projektu ------------------ 1. Management projektu - je definovan  vhodn  proced£ra pre management projektu (napr. pre pl novanie, odhady, prode–ovanie zdrojov, defin¡ciu akceptaŸnìch krot‚ri¡, riedenie zmien, pr¡pravu testovac¡ch pl nov atÔ.) ? - pozn  ka§dì zo zainteresovanìch organiz ciu projektu, svoju individu lnu £lohu a zaradenie ? 2. Projekt - s£ jasne definovan‚ ciele a zamerania projektu ? - boli ciele a zameranie projektu schv len‚ vçetkìmi zainteresovanìmi skupinami ? æt£dia dosiahnute–nosti cie–ov projektu --------------------------------------- 1. Ciele projektu - s£ ciele projektu jasne stanoven‚ a pochopen‚ vçetkìmi zainteresovanìmi ? 2. Funkcie syst‚mu - boli identifikovan‚ vçetky po§adovan‚ funkcie ? - je s£casnì a navrhovanì syst‚m adekv tne op¡sanì ? 3. Vhodn‚ alternat¡vy - bol uva§ovanì dostatoŸnì poŸet mo§nìch alternat¡vnych rieçen¡ do adekv tneh h’bky podrobnosti ? - je vìber alternat¡vy dostatoŸne zd“vodnenì ? 4. Podiel pou§ivate–a na projekte - bol pou§ivate– dostatoŸne zapojenì do etapy tvorby çt£die ? - s£hlas¡ pou§ivate– s doporuŸovanou alternat¡vou ? - ch pe pou§ivate– d“sledky vìberu navrhovanej alternat¡vy ? - m  pou§ivate– realistick‚ oŸak vania vzh–adom k vytv ran‚mu syst‚mu ? 5. OhraniŸenia - boli vçetky obmedznenia a ohraniŸenia projektu zv zen‚ ? 6. Metodol¢gia - bola çt£dia vypracovan  na z klade schv lenej metodol¢gie ? 7. Analìza n kladov a pr¡nosov - zahråuje analìza vçetky n klady a mo§n‚ pr¡nosy a s£ tieto odhafy realistick‚ ? - boli n klady a pr¡nosy prehodnocovan‚ pou§ivate–om, tzn. jednotlivìmi zlo§kami v pou§ivate–skej organiz cii ? 8. Pl n projektu - bol vytvorenì adekv tny pl n projektu identifikuj£ci f zy projektu a z kladn‚ aktivity ? - s£ produkty a kontroln‚ body definovan‚ ? - je odovzdanie projektu striktne urŸen‚ vonkajçimi ohraniŸeniami ? - s£ odhady a term¡ny realistick‚ ? - je zahrnut  taktie§ analìza mo§nìch odchìlok odhadov ? - je nasleduj£ca f za (çpecifik cia syst‚mu) napl novan  dostatoŸne podrobne ? - je mo§n‚ priradiœ zdroje ? 9. Riadenie zmien - s£ proced£ry pre riadenie zmien definovan‚ ? - s£ tieto proced£ry dostatoŸne pochopen‚ vçetkìmi zainteresovanìmi ? æpecifik cia syst‚mu -------------------- 1. S£casnì syst‚m - s£casnì syst‚m spracovania inform ci¡ bol dostatoŸne presk£manì o boli definovan‚ vçetky jeho z kladn‚ funkcie - pou§ivate– skontroloval a ods£hlasil defin¡ciu s£casn‚ho stavu spracovania inform ci¡ 2. Vytv ranì syst‚m - pracovn¡ci podie–aj£ci sa na çpecifik cii po§iadaviek na novì syst‚m s£ t¡ ist¡, ktor¡ novì syst‚m bud£ aj pou§ivaœ - vçetky z kladn‚ funkcie pou§ivate–skej organiz cie s£ definovan‚ - vçetky manu lne aj automatizovan‚ funkcie s£ pop¡san‚ - interfejsy k inìm syst‚mom a Ôalçim organizaŸnìm zlo§k m s£ specifikovan‚ - vçetky d“le§it‚ vstupy a vìstupy su zn me, v pr¡pade potreby doplnen‚ preh–adnìmi obrazovìmi ilustr ciami - vçetky £daje s£ definovan‚, vr tane urŸenia kde s£ vstupmi, kde s£ transformovan‚ a kde s£ vìstupmi - vçetky £daje s£ adekv tne analyzovan‚ a modelovan‚, napr. zaruŸenie normaliz cie d tov‚ho modelu - d tov‚ model bol skontrolovanì a ods£hlasenì pou§ivate–om - data-dictionary sa pou§iva a je pravidelne aktualizovanì - pou§ivate– skontroloval a ods£hlasil vytv ran£ specifik ciu nov‚ho syst‚mu - vçetky organizaŸn‚ strukt£ry ovplyvnen‚ novìm syst‚mom çpecifik ciu ods£hlasili a skontrolovali 3. Metodol¢gia - zaruŸenie, §e çpecifik cia syst‚mu bola vytv ran  na z klade schv lenej metodol¢gie 4. Automatizovan‚ podporn‚ prostriedky - ak s£ k dispoz¡cii podporn‚ prostriedky (napr. CASE), musia byœ efekt¡vne vyu§ivan‚ 5. Riadenie/integrita - do syst‚mu bolo zakomponovan‚ adekv tne riadenie, zabezpeŸuj£ce po§iadavky rev¡zie a konformity s pr vom - je pre syst‚m zabezpeŸenì backup, restart a zotavenie z poruchy (recovery) 6. Vìkonnosœ - pre syst‚m bola vykonan  analìza nzaœa§enia pre cel£ pl novan£ zivotnosœ - boli zv zen‚ aspekty vypl vaj£ce z po§adovanej vìkonnosti syst‚mu - ohraniŸenia vìkonnosti boli konzultovan‚ s pou§ivate–om 7. Rev¡zie - çpecifik cia syst‚mu mus¡ byœ preveren  pou§ivate–om a vçetkìmi Ÿasœami organiz cie ovplyvnenej naseden¡m nov‚ho syst‚mu 8. Implement cia - zopdovedaj£ca pozornosœ mus¡ byœ venovan : - çkoleniu pou§ivate–ov (z Ÿoho bude pozost vaœ, ak  bude £roveå, kto ho bude vykon vaœ) - dokument cii - implement cii (napr. pilotnej, paralelne, f zovo-inkrement lnej, konverzii d t) - vçetky rizikov‚ faktory spojen‚ s implement ciou boli zv zen‚ 9. Pl n projektu - pl n projektu bol aktualizovanì - vçetky odhady a term¡ny ukonŸenia s£ naÔalej realistick‚ - dalçia f za (n vrh syst‚mu) je napl novan  dostatoŸne podrobne - je mo§n‚ priradiœ zdroje a pracovn¡kov 10. N klady projektu - n klady projektu st le s£ v s£lade s rozpoŸtom 11. Riadenie zmien - vìznamn‚ zmeny s£ riaden‚ a ich dopad na projekt je analyzovanì - poŸet a rozsah povolenìch zmien nevedie k odchìlke syst‚mu od p“vodn‚ho zamerania a rozsahu N vrh syst‚mu ------------- 1. Datab za - bola vykonan  adekv tna d tov  analìza - boli vytvoren‚ fyzick‚ defin¡cie d t - data-dictionary sa pou§iva a pravidelne aktualizuje 2. Spracovanie - z kladn‚ funkcie boli analyzovan‚ a transformovan‚ do n vrhu syst‚mu, napr. do vìvojovìch diagramov 3. Vstupy a vìstupy - vçetky vstupy a vìstupy boli çpecifikovan‚ 4. Vìkonnosœ - vçetky z vislosti od vìkonnosti boli zv zen‚ 5. Kontroly - technickì n vrh bol kontrolovanì vçetkìmi oddeleniami, ktor‚ bud£ zabezpeŸovaœ prev dzku nov‚ho syst‚mu 6. Metodol¢gia - n vrh syst‚mu bol vykonanì na z klade schv lenej metodol¢gie 7. Implik cie vyplìvaj£ce z hardv‚ru a softv‚ru - boli zv zen‚ vçetky mo§n‚ d“sledky vyplìvaj£ce z pou§it‚ho hardv‚ru a softv‚ru 8. Dokument cia - n vrh syst‚mu je adekv tne dokumentovanì 9. Pl n projektu - pl n projektu bol aktualizovanì - vçetky odhady a term¡ny ukonŸenia s£ naÔalej realistick‚ - dalçia f za (implement cia syst‚mu) je napl novan  dostatoŸne podrobne - je mo§n‚ priradiœ zdroje a pracovn¡kov 10. N klady projektu - n klady s£ st le v s£lade z rozpoŸtom 11. Riadenie zmien - vìznamn‚ zmeny s£ riaden‚ a ich dopad na projekt je analyzovanì Implement cia a testovanie -------------------------- 1. K¢dovanie - bola vykonan  prehliadka k¢du vzh–adom k jeho korektnosti, £plnosti a dodr§aniu programovac¡ch a k¢dovac¡ch çtandardov 2. Testovanie - program tori otestovali nimi vytvoren‚ moduly - syst‚mov‚ (tzn. kombin cia jednotlivìch modulov) testovanie je ukonŸen‚ - integraŸn‚ (tzn. celì syst‚m vr tane interfejsov) testovanie je ukonŸen‚ - na z klade konzult ci¡ s pou§ivate–mi boli propraven‚ adekv tne testovacie £daje pre akceptaŸn‚ testy 3. Metodol¢gia - implement cia a testovanie boli vykonan‚ na z klade schv lenej metodol¢gie 4. Dokument cia - vytvoren‚ programy s£ zodpovedaj£cim sp“sobom dokumentovan‚ 5. Pl n projektu - pl n projektu bol aktualizovanì - vçetky odhady a term¡ny ukonŸenia s£ naÔalej realistick‚ - dalçia f za (odovzd vanie syst‚mu) je napl novan  dostatoŸne podrobne - je mo§n‚ priradiœ zdroje a pracovn¡kov 6. N klady projektu - n klady s£ st le v s£lade z rozpoŸtom 7. Riadenie zmien - vìznamn‚ zmeny s£ riaden‚ a ich dopad na projekt je analyzovanì Odovzd vanie do prev dzky ------------------------- 1. Testovanie - bolo vykonan‚ zodpovedaj£ce syst‚mov‚ (akceptaŸn‚) testovanie - vìsledky testovania syst‚mu boli kontrolovan‚ a splåuj£ pou§ivate–om stanoven‚ akceptaŸn‚ krit‚ri  - syst‚m bol testovanì v prev dzkovom prostred¡ 2. Vìkonnosœ - boli vykonan‚ testy na vìkonov‚ zaœa§enie a testy rozsahu d t - vìsledky testov potvrdzuj£ po§iadavky na hardv‚rov‚ a softv‚rov‚ prostriedky - vìkonnosœ splåuje krit‚ri  stanoven‚ pou§ivate–om 3. ækolenia - bolo ukonŸen‚ skolenie pou§ivate–ov a prev dzkovate–ov syst‚mu - prev dzkovatelia a pou§ivatelia s£ pripraven¡ na nasadenie syst‚mu do prev dzky 4. Dokument cia - pou§ivate–sk , prev dzkov  a technick  dokument cia je £pln  a preveren  5. Konverzia - d tov  konverzia , Ÿi u§ manu lna alebo automatick , bola vykonan  a overen  6. Podpora - je k dispoz¡cii prodpora pre rieçenia probl‚mov a objasåovanie nejasnost¡ 10.4. Z sady tvorby dokument cie -------------------------------- Dokument cia tvor¡ neoddelite–n£ s£casœ ka§d‚ho softv‚rov‚ho produktu. Existencia çtandardu tvorby dokument cie patr¡ k d“le§itìm predpokladom zaŸatia pr c na projekte. Preh–ad r“znych typov dokument cie je na OBR.10.28. OBR.10.28. - hierarchia dokument cie o projekte Dokument cia m“ze maœ nieko–ko typov, od ktorìch z vis¡ jej form t: - technick  a vìvojov  dokument cia - form t A4 - pou§ivate–sk  dokument cia, manu ly - form t A4 alebo B5 - marketingov  dokument cia - r“zny form t, farebn , skladan  Z h–adiska pou§itia mus¡ byœ organiz cia dokument cie jednoduch  a preh–adn . Proced£ry pre tvorbu dokument cie musia byœ jednoduch‚. Z tohoto d“vodu je v ka§dom projekte potrebn‚ definovaœ standardy pre syst‚m Ÿislovania dokumentov a pre form t obsahu jednotlivìch dokumentov. 10.4.1. ¬islovanie dokumentov ----------------------------- ¬islovanie dokumentov v projekte predstavuje z kladn£ proced£ru pre tvorbu dokument cie. Ka§dì dokument v projekte mus¡ maœ priraden‚ jednoznaŸn£ identifik ciu. Z kladn£ sch‚mu pre Ÿislovanie dokumentov je mo§ne definovaœ nasledovne: SSSS.IIII.VV kde jednotliv‚ symboly maj£ vìznam: SSSS - Ÿislo identifikuj£ce dan£ s‚riu dokumentov k dan‚mu projektu bez oh–adu p“vod dokumentu (vìvoj, implement cia, financie ) IIII - identifik cia samotn‚ho dokumentu 0000..9999. Pre t£to identifik ciu je potrebn‚ definovaœ typick‚ intervaly pre r“zne typy dokumentov: 0000-0099 - marketingov‚ dokumenty, çt£die 0100-0199 - çpecifik cia funkŸnìch po§iadaviek 0200-0299 - çpecifik cia technickìch po§iadaviek 0300-0399 - çpecifik cia softv‚rovìch produktov 0400-0499 - çpecifik cia interfejsov 0500-0599 - çpecifik cia testov 0600-0699 - inçtal cie produktov 0700-0799 - manu ly a pr¡ruŸky 0800-0899 - reklamn‚ dokumenty 0900-9999 - rezervovan‚ VV - identifik cia verzie dokumentu (vr tane d tumu jej vytvorenia) 10.4.2. Form t obsahu dokumentov -------------------------------- Form t obsahu dokumentov identifikuje z kladn£ strukt£ru dokumentu dan‚ho typu. Pre vçetky dokumenty je vçak mo§n‚ definovaœ z kladn‚ clenenie, ktor‚ pozost va z nasledovnìch Ÿast¡: - tituln  strana - zoznam zmien vykonanìch v dokumente - obsah - vlastnì dokument - kni§nica a knihovn¡k Tituln  strana - n zov firmy a vlastn¡ka dokument cie - n zov dokumentu - intern‚ cislo dokumentu - d tum vydania danej verzie dokumentu - d tum poslednej opravy (aktualiz cie) - upozornenie o utajovan¡ inform ci¡ - prehl senie o autorskom vlastn¡ctve, d tum Zoznam zmien vykonanìch v dokumente - d tum zmeny - kto zmeny vykonal - ktor‚ strany boli doplnen‚, zruçen‚ alebo modifikovan‚ - struŸnì opis zmeny Zoznam zmien sa aktualizuje pre dan£ verziu, napr. 1.1, 1.2, ... 1.7 ... . Pre nov£ verziu, napr. 2.0, sa vykon  rev¡zia a zoznam sa zaŸne vytv raœ nanovo. Obsah - n zvy Ÿast¡ (kapitol) dokumentu s Ÿislovan¡m str n Vlastnì dokument - £vod - nadv„znosœ na in‚ dokumenty - opis rieçen‚ho probl‚mu - z ver - pr¡lohy, merania ... Kni§nica a knihovn¡k - akìm sp“sobom bude organizovan‚ uchov vanie, spr¡stupåovanie a utajovanie dokumentov - kto bude poverenì pr cou s kni§nicou - ak‚ automatizovan‚ n stroje pre evidenciu, spr vu a generovanie dokumentov sa bud£ pou§ivaœ