Zóny pre každého študenta

Riadenie kvality IS

Riadenie kvality IS
 
S rozvojom informatiky vzniká obrovské množstvo softvérových produktov. Pre každý z týchto produktov je potrebné zabezpečiť riadenie kvality. Jedným z prostriedkov na dosiahnutie kvality, je vypracovanie smerníc pre zabezpečenie kvality softvéru.
 
Cieľom tejto metodiky je poskytnúť informáciu o riadení kvality počas životného cyklu IS vychádzajúcu z noriem ISO 9000. Normy ISO však presne nešpecifikujú typy dokumentov, ktoré majú vznikať a praktická implementácia noriem je preto problematická, vytvára úroveň neurčitosti a súčasne poskytuje určitú voľnosť.
 
Preto sú k niektorým oblastiam vedené poznámky, ktoré majú uľahčiť praktický pohľad na životný cyklus  IS z pohľadu riadenia kvality.  Snahou autorov bolo v každej fáze rozdeliť povinnosti a aktivity na dodávateľa a zákazníka.
 
Všetky činnosti tvoriace podstatu riadenia kvality úzko súvisia  a nie je možný pohľad len z jednej strany. Dodávateľ je chápaný ako realizátor projektu, zákazníkom je subjekt, pre ktorého sa vyvíja produkt. Teraz sa pozrieme na riadenie kvality v životnom cykle IS z pohľadu dodávateľa a zákazníka.
 
12.1 Základné normy pre riadenie kvality
 
V Európe platné normy pre riadenie kvality sa nachádzajú v skupine ISO 9000. Normy sú však všeobecné a opisujú všetky výrobné a vývojové procesy. Z pohľadu nášho záujmu sú zaujímavé normy špecializované na použitie pri vývoji, dodávke a údržbe softvéru. V nasledujúcej časti budeme vychádzať z normy ČSN ISO 9000-3, vydanej v roku 1992 (Slovenská verzia zatiaľ nie je vydaná, preto je platná česká veria vydaná v ČSFR).
 
Je to smernica pre použitie ISO normy 9001, pre podmienky vývoja, dodávky a údržby softvéru. Jej podstatná časť sa venuje systému riadenia kvality počas životného cyklu IS. V uvedenej norme však jednotlivé fázy nie sú konkrétne určené a  je možné činnosti spojené s riadením kvality prispôsobiť používanému životnému cyklu.
 
Ďalšie normy použité v tejto časti sú:  STN ISO 9001:1996 a STN ISO 9003:1997.
 
12.2 Fáza plánovania a riadenia
12.2.1   Dodávateľ
12.2.1.1 Koncepcia kvality

Vedenie dodávateľskej organizácie musí určiť a dokumentovať vlastnú koncepciu, ciele a svoje záväzky v oblasti kvality. Dodávateľ musí zaistiť, aby koncepcia bola zrozumiteľná a aby bola dodržovaná na všetkých úrovniach organizácie.

12.2.1.2 Politika kvality
Vrcholový manažment dodávateľa s  menovitou zodpovednosťou musí stanoviť a dokumentovať svoju politiku kvality, vrátane cieľov kvality a svojich záväzkov týkajúcich sa kvality. Politika kvality musí rešpektovať organizačné ciele dodávateľa, ako aj očakávania a potreby zákazníkov.

12.2.1.3 Plán vývoja  

Plán vývoja má obsahovať:
· definíciu produktu, vrátane formulácie jeho cieľov, s ohľadom na súvisiace projekty zákazníka alebo dodávateľa;
· organizáciu zdrojov projektu, vrátane zloženia skupiny, zodpovednosť, využitie subdodávateľov a materiálových zdrojov;
· fázy vývoja;
· harmonogram projektu stanovujúci úlohy, ktoré sa majú vykonávať, zdroje a dobu požadovanú pre každú úlohu;
· identifikácia príslušných plánov, ako sú plán kvality, plán konfiguračného riadenia, plán integrácie, plán skúšok.
 
Plán vývoja má stanoviť systematický postup alebo metodiku prenášania špecifikácie požiadaviek zákazníka do softvérového produktu, vrátane prípadného rozdelenia práce na jednotlivé fázy a ich identifikácia:
 
· vývojové fázy
· požadované vstupy pre každú fázu
· požadované výstupy pre každú fázu
· postup overovaní, ktoré sa majú v každej fáze previesť[mg1] 
· rozbor možných problémov spojených s vývojovými fázami a splnením špecifikovaných požiadaviek.
 
V pláne vývoja sa má stanoviť, ako bude projekt riadený. Mal by obsahovať :
· harmonogram vývoja, jeho zavedenie a s tým spojených dodávok;
· operatívne riadenie postupu vývojových prác;
· organizačné zodpovednosti, zdroje a prideľovanie úloh;
· organizačné a technické prepojenie medzi jednotlivými skupinami.
Plán vývoja má identifikovať metódy zaisťujúce správne prevádzanie všetkých činností  Môže obsahovať:
· pravidlá, praktiky a dohody použité pri vývoji;
· nástroje a metodiky vývoja;
· konfiguračné riadenie.
 
Vráťme sa k vstupom a výstupom každej fázy.
Vstupy – každá požiadavka sa má definovať tak, aby sa mohla overiť. Neúplné, nejednoznačné alebo protichodné požiadavky musí riešiť zodpovedná osoba poverená zostavením požiadaviek.
 
Výstupy – každý výstup má:
· spĺňať stanovené požiadavky;
· obsahovať preberacie kritériá pre postúpenie do ďalšej fázy alebo sa na ne odvolávať;
· vyhovovať príslušným postupom a zvyklostiam vývoja;
· identifikovať tie vlastnosti produktu, ktoré sú rozhodujúce z hľadiska bezpečnosti a správnej funkcie;
· vyhovovať príslušným požiadavkám predpisov.
 
Na konci každej fázy má dodávateľ zostaviť plán overovania všetkých výstupov . Overovanie vývoja má zabezpečiť, aby výstupy vývojovej fázy vyhovovali vstupným požiadavkám definovaných definovaným pomocou opatrení na riadenie vývoja, ako sú:
 
· preskúmanie vývoja v príslušných bodoch vývojových fáz,
· porovnanie nového návrhu s podobným vyskúšaným  návrhom,
· vykonávanie skúšok a názorných ukážok.
 
12.2.1.4 Plán kvality 
Dodávateľ má pripraviť a dokumentovať plán kvality, ktorý má zaviesť činnosti v oblasti kvality pre vývoj každého softvéru na základe systémovej kvality a má sa zaistiť, aby všetky zainteresované organizácie plán kvality pochopili a dodržiaovali.
 
Plán kvality sa má súčasne s postupom vývojových prác aktualizovať a na začiatku fázy sa majú stanoviť všetky položky týkajúce sa príslušnej fázy. Plán kvality majú preskúmať a odsúhlasiť všetky organizácie zainteresované na jeho zavedení.
 
Dokument obsahujúci plán kvality nemusí byť samostatným dokumentom. Môže sa skladať z viacerých dokumentov, prípadne môže byť obsiahnutý v dokumentácii plánu vývoja. Plán kvality má mať nasledovný obsah:
 
· ciele kvality vyjadrené, pokiaľ možno, v merateľných parametroch;
· stanovené kritériá pre vstup a výstup každej vývojovej fázy;
· identifikovanie typov skúšok, overovania a potvrdzovania platnosti;
· podrobné plánovanie skúšky, overovanie a potvrdzovanie platnosti, vrátane harmonogramov, zdrojov a schvaľovacích orgánov;
· vymedzenie zodpovednosti za činnosti v oblasti kvality, ako napríklad preskúmanie a skúšky, konfiguračné a zmenové riadenie, rozbor chýb a opatrenia k náprave.
 
Pozn.: Plán kvality je možné použiť len spolu s plánom vývoja (niekedy označovaný ako Plán
budovania IS). V pláne vývoja sú špecifikované fázy a ich vstupy a výstupy.
 Kritériá pre vstup a výstup z/do fázy sú definované v pláne kvality. Plán kvality nie
   je možné kompletne zdokumentovať už vo fáze plánovania a riadenia, pretože
 predposledná uvedená časť venujúca sa testovaniu, je rozložená do ďalších fáz
 životného cyklu. K plánu kvality patria nasledovné dokumenty vznikajúce počas
 životného cyklu:

· Plán verifikácie,
· Plán a procedúry akceptačného testovania,
· Plán a procedúry integrácie a testovania systému,
· Plán a procedúry testovania modulov,
· Protokoly o testovaní modulov,
· Protokoly o testovaní a integrácii systému,
· Protokoly o akceptačnom testovaní.
 
12.2.1.5 Interné previerky systému kvality
Dodávateľ musí realizovať systém plánovaných a dokumentovaných interných previerok systému kvality. Harmonogram sa určuje podľa dôležitosti činností.
 
Previerky systému kvality sa vykonávajú počas celého životného cyklu IS. Súčasťou previerok sú aj nápravné opatrenia. Výsledky previerok musia byť dokumentované a  predložené pracovníkom, ktorí sú zodpovední za preverovanú oblasť. Riadiaci zodpovední pracovníci musia včas začať vykonávať nápravné opatrenia k odstráneniu nedostatkov zistených pri previerke.
 
12.2.1.6 Opatrenia pre nápravu
Dodávateľ musí stanoviť, dokumentovať a dodržovať postupy pre vyšetrenie príčin výskytu cgybných chybných produktov, rozbor všetkých postupov, preventívnych činností, operatívneho riadenia pre nápravu, uskutočnenie a zaznamenanie zmien vedúcich k náprave. Postupy nápravnej činnosti musia obsahovať:
 
· účinné zaobchádzanie so sťažnosťami zákazníka a záznamami o nezhodách produktu;
· zistenie príčin nezhôd produktu;
· určenie nápravnej činnosti potrebnej pre odstránenie príčin chýb;
· uplatnenie postupov operatívneho riadenia, ktoré zabezpečia prijatie účinných nápravných opatrení.
K zníženiu chýb produktu prispieva aj preventívna činnosť.

12.2.1.7 Zodpovednosť a právomoci
Musí byť stanovená zodpovednosť, právomoci a vzájomné vzťahy pracovníkov, ktorí majú vplyv na kvalitu. Ide hlavne o pracovníkov, ktorí potrebujú organizačnú nezávislosť a právomoci.
 
12.2.1.8  Zdroje a pracovníci pre overovanie
Dodávateľ musí stanoviť svoje požiadavky na overovanie, zabezpečiť príslušné zdroje a určiť pracovníkov pre overovanie.
 
Pozn.:  Pod overovaním sa rozumie v oblasti IS testovanie. Testy sa budú vykonávať vo fáze
  implementácie a  integrácie IS a poverení pracovníci tvoria testovací tím pre
  integračné testovanie.

 
12.2.1.9 Predstaviteľ vedenia
Dodávateľ musí určiť predstaviteľa vedenia pre projekt, ktorý musí  mať bez ohľadu na iné povinnosti vyhradené právomoci a zodpovednosť za vedenie projektu.
 
Pozn.:  Vedúci projektu nesie zodpovednosť za celý priebeh prác od špecifikácie až po
uvoľnenie, prípadne prevádzku, ak je to zmluvne určené.

 
12.2.1.10  Preskúmanie zmluvy
Dodávateľ musí preskúmať každú zmluvu, aby sa uistil že:
· rozsah zmluvy a požiadavky  zákazníka sú stanovené a dokumentované;
· náhodné nepredvídateľné výdaje a riziká sú zaistené;
· chránené informácie sú vhodným spôsobom zabezpečené;
· akékoľvek požiadavky, líšiace sa od požiadaviek v ponuke sú vyjasnené;
· dodávateľ je spôsobilý splniť požiadavky zmluvy;
· zodpovednosť dodávateľa s ohľadom na subdodávateľské práce je stanovená;
· názvoslovie je schválené oboma stranami;
· zákazník je spôsobilý splniť zmluvné záväzky.
 
O preskúmaniach sa majú viesť záznamy.
Zmluva by mala z pohľadu riadenia kvality obsahovať nasledovné:
· preberacie kritériá;
· prejednávanie zmien v požiadavkách zákazníka počas vývoja;
· prerokovávanie problémov zistených pri preberaní, vrátane reklamácií spojených s kvalitou a sťažnosťami zákazníka;
· činnosti prevádzané [mg2] zákazníkom, hlavne špecifikácia požiadaviek, preberanie uvádzanie do prevádzky;
· vybavenie, nástroje a softvér, ktorý má zabezpečiť zákazník;
· technické normy, smernice a postupy, ktoré sa majú použiť;
· požiadavky na rozmnoženie zmluvy?.
 
K tejto oblasti prislúcha aj spôsob vykonávania zmien v zmluve a spôsob ich oznamovania všetkým zainteresovaným miestam.
 
12.2.1.11  Posudzovanie subdodávateľov
 
Dodávateľ musí zvoliť subdodávateľov na základe ich schopností splniť požiadavky kontraktu, vrátane požiadaviek na kvalitu. Dodávateľ musí vytvoriť a udržovať záznamy o vhodnosti subdodávateľov.
 
Voľba subdodávateľov, typ a rozsah operatívneho riadenia uplatňovaného dodávateľom musí závisieť na druhu výrobku, prípadne i  na záznamoch o  skôr preukázanej schopnosti subdodávateľov a na plnení dohôd.
 
12.2.2   Zákazník
12.2.2.1 Zodpovednosť vedenia zákazníka

Zákazník musí spolupracovať s dodávateľom tak, aby mu boli včas doručené všetky potrebné informácie. Zákazník musí menovať predstaviteľa zodpovedného za komunikáciu s dodávateľom.
 
Zodpovedná osoba má tiež zodpovednosť v otázkach zmluvných záležitostí.
 
Zodpovednosť je určená v minimálne týchto položkách:
· formulovanie požiadaviek na dodávateľa;
· zodpovedanie otázok dodávateľa;
· schvaľovanie návrhov dodávateľa;
· uzatváranie dohôd s dodávateľom;
· zabezpečenie, aby  organizácia zákazníka dodržiaovala dohody uzatvorené s dodávateľom;
· formulovanie preberacích kritérií a postupov.
· jednanie o dodaných položkách softvéru, ktoré nie sú vhodné pre použitie.

12.2.2.2 Preskúmanie zmluvy
Aj keď normy ISO priamo nehovoria o povinnosti preskúmania zmluvy zákazníkom, je vhodné, aby zákazník postupoval podobne ako dodávateľ, teda preskúmal každú zmluvu s dodávateľom, aj keď je tvorcom zmluvy (pozri časť preskúmanie zmluvy dodávateľom). Ak zákazník dodrží pravidlá pri vytváraní zmlúv, výsledkom bude kvalitnejší produkt, čo je v konečnom dôsledku hlavným cieľom zákazníka.
 
12.2.2.3  Spoločné

Je potrebné rozvrhnúť pravidlá spoločného preskúmania, týkajúce sa dodávateľa a zákazníka. Pravidlá je potrebné dohodnúť v troch oblastiach:
 
· zhoda softvéru so špecifikáciou požiadaviek dohodnutých so zákazníkom,
· výsledky overovania/testovania,
· výsledky preberacích/akceptačných testov.
 
Pozn.: Pod spoločným preskúmaním môžeme rozumieť akceptačné testovanie, vykonávané
  vo fáze akceptačného testovania. Základné pravidlá pre akceptačné testovanie je
  potrebné stanoviť hneď na začiatku projektu, aby sa predišlo neskorším sporom pri
akceptačnom testovaní a preberaní produktu.


12.3 Fáza analýzy IS
12.3.1   Dodávateľ
12.3.1.1 Špecifikácia požiadaviek zákazníka 

Dodávateľ musí mať úplný a jednoznačný súbor funkčných požiadaviek, aby mohol pokračovať vo vývoji. Požiadavky musia zahŕňať všetky hľadiská, potrebné pre uspokojenie zákazníka.
 
Okrem vlastnej funkčnosti to sú napríklad:
· výkon,
· bezpečnosť,
· bezporuchovosť/spoľahlivosť,
· ochrana informácií.
 
Požiadavky sa musia stanoviť tak presne, aby v priebehu preberania bolo možné potvrdiť ich platnosťsplnenie. Požiadavky sa zaznamenávajú do špecifikácie požiadaviek zákazníka. Niekedy tento dokument vypracováva zákazník. Ináč dokument vypracováva dodávateľ v úzkej spolupráci so zákazníkom. Špecifikácia požiadaviek má byť podrobená dokumentačnému a konfiguračnému riadeniu, ako súčasti dokumentácie vývoja.
 
Počas špecifikácie požiadaviek je potrebné venovať pozornosť:
· menovaniu osôb zodpovedných za vypracovanie špecifikácie požiadaviek zákazníka;
· metódam odsúhlasovania požiadaviek a schvaľovanie zmien;
· snahe predchádzať nedorozumeniam, ako je napríklad definícia termínov, zdôvodňovanie požiadaviek;
· zaznamenaniu a preskúmaniu výsledkov.
 
Pozn.: Po ukončení vypracovávania Špecifikácie požiadaviek zákazníka je potrebné tento dokument schváliť. V tejto fáze, teda vo fáze analýzy, sa ukončuje vypracovávanie základnej časti Plánu kvality. Súčasťou Plánu kvality je aj Plán verifikácie, ktorý sa všeobecne venuje problematike verifikácie produktu. Zo Špecifikácie požiadaviek zákazníka vzniká Plán akceptačného testovania.
 
12.3.2   Zákazník
12.3.2.1 Špecifikácia požiadaviek zákazníka

Zákazník špecifikuje svoje požiadavky na systém. Spolupracuje pritom s dodávateľom. Vzniká dokument Špecifikácia požiadaviek zákazníka.
 
Niekedy, ak tak bolo zmluvne dohodnuté, tento dokument vypracováva zákazník.
Počas špecifikácie požiadaviek je potrebné venovať pozornosť:
· menovaniu osôb zodpovedných za vypracovanie špecifikácie požiadaviek zákazníka;
· metódam odsúhlasovania požiadaviek a schvaľovanie zmien;
· snahe predchádzať nedorozumeniam, ako je napríklad definícia termínov, zdôvodňovanie požiadaviek;
· zaznamenaniu a preskúmaniu výsledkov.

12.4  Fáza projektovania IS
12.4.1   Dodávateľ
12.4.1.1 Návrh

Okrem požiadaviek pre všetky fázy vývoja sa majú vziať do úvahy nasledujúce hľadiská, podstatné pre činnosť, spojené s návrhom:
· identifikácia úvah o návrhu – okrem vstupov a výstupov je potrebné skúmať hľadiská, ako sú napr. pravidlá navrhovania a definícia interných prepojení;
· metodika návrhu – má sa použiť systematická metodika vhodná pre daný typ vyvíjaného softvérového produktu;
· využitie skúseností z predchádzajúcich návrhov;
· následné postupy – produkt musí byť navrhnutý v rozsahu praktickom pre uľahčenie skúšania, údržby a používania.
 
Pozn.. Počas projektovania vzniká Špecifikácia akceptačných testov, obsahujúca testovacie
procedúry, ktoré majú slúžiť ako hlavný prostriedok pre overenie požiadaviek
zákazníka uvedených a schválených v Špecifikácii požiadaviek. Z návrhu
architektúry vznikajú dokumenty Plán integrácie a testovania IS a Plán testovania
modulov.

 
12.4.2   Zákazník
Vo fáze projektovania pokračuje upresňovanie požiadaviek zákazníka, teda zákazník musí poskytnúť potrebné informácie pre nejednoznačné požiadavky, definované v Špecifikácii požiadaviek. V prípade zmien požiadaviek na systém počas projektovania, je potrebné každú zmenu preskúmať, zhodnotiť následky a riadne dokumentovať.

12.5  Fáza Implementácie
12.5.1   Dodávateľ
12.5.1.1 Implementácia

Okrem požiadaviek pre všetky činnosti sa majú brať do úvahy nasledujúce hľadiská:
· pravidlá – pravidlá programovania, programovacie jazyky, zhodné názvoslovie, pravidlá pre komentáre a podobne;
· metodiky – dodávateľ musí za účelom splnenia požiadaviek zákazníka používať vhodné metodiky a nástroje implementácie.
 
Dodávateľ má prevádzať preskúmanie, aby sa uistil, že sú požiadavky splnené, a že použité metodiky sú správne vykonávané. Implementácia nemá pokračovať, pokiaľ  nie sú uspokojivo vyriešené dôsledky všetkých známych nedostatkov alebo inak známe riziko pokračovania.
 
Pozn.: Pri vlastnej implementácii je nutné dodržiavať potrebné pravidlá a dohodnuté
názvoslovie. Dôležité je, že každá ďalšia zmena alebo rozširovanie funkčnosti musí
prebiehať rovnakým spôsobom ako prvýkrát.

 
12.5.1.2 Príprava pracovníkov testovania
Pracovníci, ktorí v zmysle tejto normy vykonávajú konečnú kontrolu a skúšky, musia mať primerané skúsenosti a/alebo  školenie, vrátane potrebnej kvalifikácie na vykonávanie špecificky určených úloh. O príprave pracovníkov sa musia udržovať príslušné záznamy.
 
Pozn.: Vo fáze implementácie je potrebné pripraviť všetko na ďalšiu fázu, fázu integrácie
  systému. Preto je nevyhnutné pripraviť testovací tím, zaškoliť pracovníkov
  vybraných pre testovanie a pripraviť testovacie dáta.
K najzložitejším úlohám patrí
  príprava dokumentov Špecifikácia procedúr pre testovanie modulov a Špecifikácia
procedúr pre integráciu a testovanie systému. Súčasťou procedúr sú aj pripravené
testovacie dáta.

 
12.5.2   Zákazník
Zákazník musí byť informovaný o priebehu prác počas fázy implementácie. V prípade zmien požiadaviek na systém počas implementácie, je potrebné každú zmenu preskúmať, zhodnotiť následky a riadne dokumentovať.

12.6  Fáza Integrácie IS
12.6.1   Dodávateľ
12.6.1.1 Testovanie a validácia

 
Skúšanie (testovanie) môže byť požadované na niekoľkých úrovniach, od softvérových jednotiek až po úplný softvérový produkt.
 
Existuje niekoľko rozdielnych prístupov k skúšaniu a integrácii. V niektorých prípadoch môže byť potvrdzovanie platnosti, prevádzkové testovanie a testy pri odovzdávaní jedna a tá istá činnosť.
 
Dokument, ktorý opisuje plán skúšok, môže byť samostatný dokument alebo môže byť súčasťou iného dokumentu alebo sa môže skladať z niekoľkých dokumentov.
 
Pozn.: Vyššie uvedený všeobecný opis by mal byť uvedený v Pláne verifikácie, ktorý je
  súčasťou Plánu kvality. Vo fáze integrácie sa vykonávajú testy modulov systému
  a integrácia a testovanie systému.

 
12.6.1.2 Plán skúšok 
 
Dodávateľ má pred začatím testovania vytvoriť a  preskúmať plány testov, špecifikácie a postupy. Do úvahy je potrebné vziať:
· plány na softvérovú položku;
· testovacie prípady, testovacie dáta a očakávané výstupy;
· typy skúšok, ktoré sa majú vykonať, napr. hraničné skúšky, prevádzkové testy, testy použiteľnosti;
· testovacie prostredie, nástroje a testovací softvér;
· kritériá, podľa ktorých sa bude posudzovať dokončenie skúšky;
· dokumentácia používateľa;
· požiadavky na pracovníkov a ich vhodné zaškolenie.
 
Pozn.: Testy sa vykonávajú podľa dopredu špecifikovaných plánov testovania, Plánu
  integrácie a testovania systému a Plánu testovania modulov. Pri testovaní sa
  používajú vopred pripravené testovacie dáta. Pri testoch sa vychádza z opisu
  testovacieho prostredia.

 
12.6.1.3 Testovanie
Pri testovaní sa má prihliadať na nasledovné:
· výsledky skúšok sa majú zaznamenať, ako je uvedené v príslušnej špecifikácii;
· akékoľvek zistené problémy a ich možný dopad na ostatné časti softvéru sa majú zaznamenať a majú sa upozorniť zodpovedné osoby, aby sa problémy mohli sledovať, pokiaľ nebudú vyriešené;
· oblasti ovplyvnené prípadnými modifikáciami sa majú identifikovať a znova preskúmať
· primeranosť a dôležitosť skúšok sa má vyhodnocovať;
· konfigurácia softvéru a hardvéru sa má posudzovať a dokumentovať.
 
Pozn.: Integrácia a  testovanie systému, prípadne testovanie modulov sa vykonáva pakovane, pokiaľ nie sú odstránené odchýlky od požiadaviek. Výstupom z testov ú protokoly alebo správy obsahujúce výsledky testov, záznamy o priebehu testov  zhodnotenie výsledkov testov. V prípade, že sa rozhodne, že systém je  uspokojivom stave, je možné prejsť k akceptačnému testovaniu a vypracováva sa dokument Konfigurácia systému.
 
12.6.1.4 Potvrdzovanie platnosti
 
Skôr ako dodá dodavateľ produkt zákazníkovi, má dodávateľ potvrdiť platnosť jeho funkcie ako úplného produktu, pokiaľ možno za podmienok podobných tým, v ktorých bude produkt používaný.
 
Pozn.: Preverovanie celkovej funkčnosti systému sa vykonáva pri integrácii a testovaní  systému. 

12.6.1.5 Prevádzkové testovanie 
Ak zákazník požaduje prevádzkové testy, majú  sa určiť:
· vlastnosti, ktoré sa majú skúšať v prevádzkovom prostredí;
· konkrétne zodpovednosti dodávateľa a zákazníka za vykonávanie a hodnotenie testov;
· postup uvedenia prostredia používateľa do pôvodného stavu po teste.
 
Pozn.: Cieľom prevádzkových testov je preukázať, že pri dodržaní prevádzkových procedúr  prevádzkovom prostredí bude systém plne funkčný. Prevádzkové testovanie sa otom vykonáva ako súčasť integrácie systému ale aj akceptačného testovania.
 
Vo fáze integácie systému dodávateľ vytvára používateľskú dokumentáciu.
 
12.6.2   Zákazník
Zákazník musí byť informovaný o priebehu testovania modulov a integrácie a testovania systému.

12.7 Fáza Akceptačného testovania
12.7.1   Dodávateľ
12.7.1.1 Akceptačné testovanie

 
Ak je dodávateľ pripravený odovzdať overený produkt, má zákazník posúdiť, či je produkt alebo jeho časť  prijateľný podľa skôr odsúhlasených kritérií a spôsobom špecifikovaným v zmluve. Dodávateľ musí schváliť  a dokumentovať spôsob vysporiadania sa s problémami.
 
Plánovanie preberacích (akceptačných) testov – dodávateľ má napomáhať zákazníkovi pri určovaní:
· časového plánu;
· postupov vyhodnocovania;
· prostredia a zdrojov pre softvér a hardvér;
· preberacích kritérií.
 
12.7.1.2 Rozmnožovanie, dodávka a uvádzanie do prevádzky
Pred dodávkou sa má previesť rozmnoženie a má sa vziať do úvahy:
· počet kópií každej softvérovej položky, ktorá má byť dodaná;
· druh médií pre každú softvérovú položku, vrátane formátu a verzie, v čitateľnom tvare;
· dohoda o požadovanej dokumentácii,  ako sú napr. príručky a návody pre používateľov;
· záležitosti odovzdaných a odsúhlasených autorských práv a licencií;
· uloženie originálu programu a záložných kópií, pokiaľ je to možné, tak aj plánov obnovy po havárii;
· doba záväzku dodávateľa dodávať kópie.
 
12.7.1.3 Uvádzanie do prevádzky
Má sa jasne stanoviť úloha, zodpovednosť a záväzky dodávateľa s ohľadom na:
· harmonogram prác vrátane nadčasov a víkendov;
· prístup do objektov zákazníka, bezpečnostné preukazy, heslá, doprovod;
· dosiahnuteľnosť skúsených pracovníkov;
· dostupnosť a prístup k systémom a zariadeniam zákazníka;
· potreba potvrdzovania platnosti, ako súčasť každého uvedenia do prevádzky sa má stanoviť zmluvne;
· oficiálny postup schválenia každého uvedenia do prevádzky.
 
12.7.1.4 Vzdelávanie
Aj keď normy ISO 9000 nehovoria priamo o vzdelávaní zákazníkov pri preberaní produktu, v časti (ISO 9000-3:1992, 6.9) sa hovorí o výcviku pracovníkov. Tento výcvik sa vzťahuje aj na budúcich prevádzkovateľov produktu. To znamená, že dodávateľ musí vyškoliť v potrebnom rozsahu pracovníkov zákazníka alebo iného subjektu, ktorý bude systém prevádzkovať. Vzdelávanie musí byť riadne dokumentované. O priebehu, obsahu, ako aj účasti na školení je potrebné viesť predpísané záznamy.
 
12.7.2   Zákazník
12.7.2.1 Akceptačné testovanie

 
Zákazník má posúdiť, či je produkt alebo jeho časť  prijateľný podľa skôr odsúhlasených kritérií a spôsobom špecifikovaným v zmluve.
 
12.7.2.2 Plán akceptačného testovania 
Plán akceptačného testovania vzniká vo fáze analýzy IS a vychádza zo špecifikácie požiadaviek zákazníka.
 
Plánovanie preberacích (akceptačných) testov – dodávateľ má napomáhať zákazníkovi pri určovaní:
· časového plánu;
· postupov vyhodnocovania;
· prostredia a zdrojov pre softvér a hardvér;
· preberacích kritérií.
 
Pozn.: Vlastné akceptačné testovanie vykonáva testovací tím, ktorý sa skladá z pracovníkov
  zákazníka, ako aj z pracovníkov dodávateľa. Testovací tím musí byť založený čo
  najskôr, aby mohli byť testy dôkladne pripravené, zdokumentované a riadené.
Uvedené časti sa nachádzajú v nasledovných dokumentoch: časový plán a postup
vyhodnocovania sú uvedené v
 Pláne akceptačného testovania; opis prostredia
a zdrojov je opísaný v 
Konfigurácii systému, vznikajúcej vo fáze integrácie
systému; preberacie kritériá môžu byť uvedené tak v 
Pláne akceptačného testovania
ako aj v priamo v 
Pláne kvality alebo inom súvisiacom dokumente.
 
Za vlastné akceptačné testovanie je zodpovedný zákazník. Samozrejme, že pri celom postupe napomáha dodávateľ, v  ktorého záujme je úspešné ukončenie akceptačného testovania, čím môže dôjsť k prebratiu produktu.

12.7.2.3 Dodanie
Zákazník musí vykonať overovanie správnosti a úplnosti kópií dodávaného softvérového produktu.
 
Pozn.: Dodávanie softvéru prebieha po úspešnom vykonaní akceptačných testov. Dodávateľ
  vytvára potrebné kópie produktu, teda vytvára kópie médií, dokumentácie, prípadne
  zabezpečuje hardvérovú základňu.

 
12.7.2.4 Uvádzanie do prevádzky
Má sa jasne stanoviť úloha, zodpovednosť a záväzky zákazníka s ohľadom na:
· harmonogram prác vrátane nadčasov a víkendov;
· prístup dodávateľa do objektov, bezpečnostné preukazy, heslá, doprovod;
· dosiahnuteľnosť skúsených pracovníkov;
· dostupnosť a prístup k systémom a zariadeniam;
· potreba potvrdzovania platnosti, ako súčasť každého uvedenia do prevádzky sa má stanoviť zmluvne;
· oficiálny postup schválenia každého uvedenia do prevádzky.

12.8  Fáza prevádzky IS
12.8.1   Dodávateľ
12.8.1.1 Údržba

Ak je zmluvne určená údržba produktu po prvej alebo ďalších dodávkach, potom dodávateľ vytvára a udržuje postupy pre vykonávanie činností spojených s údržbou a postupy pre overovanie, či tieto činnosti spĺňajú špecifikované požiadavky na údržbu. Činnosti údržby softvérového produktu sa obvykle delia nasledovne:
· riešenie problémov – riešenie problémov vyžaduje zisťovanie, analýzu a opravu nezhôd softvéru vyvolaných prevádzkovými problémami. Pri riešení problémov sa môžu použiť dočasné opatrenia, aby sa znížili prestoje a trvalé zmeny sa vykonajú neskôr;
· modifikácia prepojenia – ak sa realizovali dodatky a zmeny hardvérového systému alebo prvkov riadených softvérom, môže vzniknúť požiadavka na modifikáciu prepojenia;
· rozširovanie funkcií alebo zlepšovanie vlastností – zákazník môže požadovať v priebehu údržby rozširovanie funkcií alebo zlepšenie existujúcich vlastností.
 
V kontrakte sa majú špecifikovať položky, ktoré sa majú udržovať a časové obdobie, počas ktorého sa majú udržovať, napr.:
· program,
· dáta a ich štruktúry,
· špecifikácia,
· dokumenty pre zákazníka a/alebo používateľov,
· dokumenty pre potreby dodávateľa.
 
12.8.1.2 Plán údržby 
Všetky činnosti spojené s údržbou sa majú vykonávať a riadiť  plánom údržby, ktorý je dopredu definovaný. V závislosti na rozsiahlosti poskytovania údržby sa dodávateľ zúčastňuje na vytváraní plánu údržby. V krajnom prípade, ak je kompletná údržba poskytovaná dodávateľsky, plán údržby vypracováva dodávateľ a zákazník ho schvaľuje. Podrobnejšie sa budeme plánu údržby venovať v zákazníckej časti.
 
12.8.1.3 Identifikácia počiatočného stavu produktu
Dodávateľ musí stanoviť, dokumentovať a schváliť počiatočný stav produktu, ktorý sa má udržovať.
 

12.8.1.4 Podporná skupina
Na podporu činností spojených s údržbou je potrebné zriadiť skupinu zloženú so zástupcov dodávateľa a zákazníka. Keďže činnosti údržby sa nemôžu vykonávať vždy podľa harmonogramu, má byť činnosť tejto skupiny tak operatívna, aby sa dokázala vysporiadať s nečakanými problémami. Môže byť taktiež vhodné identifikovať vybavenie a zdroje, ktoré sa majú použiť pre činnosti spojené s údržbou.
 
12.8.1.5 Záznamy a protokoly o údržbe
Všetky činnosti spojené s údržbou sa majú zaznamenať do vopred pripravených formulárov a uchovávať. Dodávateľ a zákazník musí stanoviť a schváliť pravidlá pre predkladanie správ o údržbe.
 
Záznamy o údržbe majú obsahovať nasledovné body:
· súpis došlých žiadostí o pomoc alebo informácií o problémoch a ich aktuálny stav;
· orgán zodpovedný za vybavovanie žiadostí o pomoc alebo zavádzanie príslušných opatrení k náprave;
· priority, ktoré boli určené pre opatrenia k náprave;
· štatistické údaje o výsledkoch porúch a činnostiach spojených s údržbou.
 
12.8.1.6 Postupy uvoľňovania zmien k používaniu 
Na základe potreby udržovať správnu funkciu majú dodávateľ a zákazník dohodnúť a dokumentovať postupy pre začlenenie zmien do softvérového produktu.
 
Tieto postupy majú presadzovať:
· základné pravidlá pre určovanie, či sa môžu dočasné úpravy začleniť do systému alebo je potrebné vyvinúť novú verziu;
· opisy typov uvoľňovania zmien  závisiacich na ich početnosti a/alebo vplyvu na operácie zákazníka a na jeho schopnosti včas zaviesť akékoľvek zmeny;
· metódy informovania zákazníka o aktuálnych alebo plánovaných zmenách;
· metódy potvrdzovania, že zavedené zmeny nevyvolajú ďalšie problémy;
· požiadavky na záznamy ukazujúce, ktoré zmeny, kde, u koho a  kedy boli realizované.
 
12.8.2   Zákazník
12.8.2.1 Údržba

Ak je zmluvne určená údržba produktu po prvej alebo ďalších dodávkach, potom dodávateľ vytvára a udržuje postupy pre vykonávanie činností spojených s údržbou a postupy pre overovanie, či tieto činnosti spĺňajú špecifikované požiadavky na údržbu (Pozri časť dodávateľa).

12.8.2.2 Plán údržby
Všetky činnosti spojené s údržbou sa majú vykonávať a riadiť v súlade s plánom údržby, ktorý je dopredu definovaný. V prípade, že sa na údržbe podieľa aj dodávateľ,  dokument plánu údržby schvaľuje zákazník aj dodávateľ. Plán údržby by mal obsahovať:
· rozsah údržby;
· identifikáciu počiatočného stavu produktu;
· podpornú skupina;
· činnosti spojené s údržbou;
· záznamy a správy o údržbe.
 
12.8.2.3 Identifikácia počiatočného stavu produktu
 
Zákazník musí stanoviť, dokumentovať a schváliť počiatočný stav produktu, ktorý sa má udržovať.
 
12.8.2.4 Podporná skupina
Na podporu činností spojených s údržbou je potrebné zriadiť skupinu zo zástupcov dodávateľa a zákazníka. Keďže činnosti údržby sa nemôžu vykonávať vždy podľa harmonogramu, má byť činnosť tejto skupiny tak operatívna, aby sa dokázala vysporiadať s nečakanými problémami. Môže byť tiež vhodné identifikovať vybavenie a zdroje, ktoré sa majú použiť pre činnosti spojené s údržbou.
 
12.8.2.5 Záznamy a protokoly o údržbe
Všetky činnosti spojené s údržbou sa majú zaznamenať do vopred pripravených formulárov a uchovávať v súlade s plánom archivácie dokumentov, ak nebolo zmluvne dohodnuté inak. Dodávateľ a zákazník musí stanoviť a schváliť pravidlá pre predkladanie správ o údržbe. Záznamy o údržbe majú obsahovať nasledovné body:
· súpis došlých žiadostí o pomoc alebo informácií o problémoch a ich aktuálny stav;
· organizácia/orgán zodpovedná/ý za vybavovanie žiadostí o pomoc alebo zavádzanie príslušných opatrení k náprave;
· priority, ktoré boli určené pre opatrenia k náprave;
· štatistické údaje o výsledkoch porúch a činnostiach spojených s údržbou.
 
12.9  Podporné činnosti nezávislé na fáze
12.9.1   Výcvik

Dodávateľ musí vytvoriť a udržovať postupy pre stanovenie potrieb výcviku a poskytnúť výcvik všetkým pracovníkom, ktorých činnosť ovplyvňuje kvalitu. Pokiaľ je to požadované, majú mať pracovníci vykonávajúci špecifické úlohy odpovedajúce vzdelanie, výcvik alebo skúsenosti. Výber tém má byť zameraný na špecifické nástroje, postupy, metódy a počítačové zdroje používané pri vývoji a riadení softvérového produktu. Taktiež sa môže požadovať výcvik schopností a znalostí odborov, ktorými sa má softvér zaoberať. O výcviku sa majú udržovať a archivovať príslušné záznamy.
 
12.9.2   Konfiguračné riadenie
Konfiguračné riadenie poskytuje mechanizmus pre identifikovanie, operatívne riadenie a sledovanie verzií každej softvérovej položky. V mnohých prípadoch sa musí staršia verzia, ktorá sa stále používa, tiež udržovať a riadiť. Systém konfiguračného riadenia má:
· jednoznačne identifikovať verziu každej softvérovej položky;
· identifikovať verziu každej softvérovej položky, ktoré spolu tvoria špecifickú verziu úplného produktu;
· identifikovať dosiahnutý stav vyvíjaných alebo dodaných a  nasadených softvérových produktov;
· riadiť súčasnú aktualizáciu danej softvérovej položky viac než jednou osobou;
· zaistiť podľa požiadaviek koordináciu aktualizovania rozmnožených produktov na všetkých miestach;
· identifikovať a sledovať všetky činnosti a zmeny vyplývajúce zo žiadosti o zmenu od začatia až po uvoľnenie.
 
12.9.3   Plán konfiguračného riadenia
Dodávateľ má vytvoriť a zaviesť plán konfiguračného riadenia, ktorý obsahuje:
· organizácie zainteresované na konfiguračnom riadení a  im pridelenej zodpovednosti;
· činnosti spojené s konfiguračným riadením, ktoré sa majú vykonávať;
· nástroje, metódy a metodiky pre konfiguračné riadenie, ktoré sa majú používať;
· etapu, pri ktorej sa majú položky predložiť na kontrolu konfigurácie.
 
 
12.9.3.1 Činnosti spojené s konfiguračným riadením
12.9.3.1.1  Identifikovateľnosť a nadväznosť konfigurácie

Dodávateľ má udržovať  postupy pre identifikovanie softvérových položiek počas všetkých fáz, od špecifikácie vývoja až po vydanie. Má sa identifikovať:
 
· funkčná a technická špecifikácia;
· všetky nástroje vývoja, ktoré majú vplyv na funkčné a technické požiadavky;
· všetky prepojenia na iné softvérové položky a na hardvér;
· všetky dokumenty a počítačové súbory týkajúce sa softvérovej položky.
 
12.9.3.1.2   Zmenové riadenie
Dodávateľ má vytvoriť a udržovať postupy, ktoré majú identifikovať, dokumentovať, preskúmavať a  autorizovať akékoľvek zmeny softvérových položiek pri konfiguračnom riadení. Všetky zmeny týchto položiek sa majú vykonávať v súlade s týmito postupmi. Skôr ako je zmena prijatá, má byť potvrdená jej platnosť a majú sa identifikovať a overiť vplyvy na iné položky. Majú sa vytvoriť metódy pre oznámenie zmien tým osobám, ktorých sa to týka a metódy pre vyjadrenie nadväznosti medzi zmenami a modifikovanými časťami softvérových položiek.
Zones.sk – Najväčší študentský portál
https://www.zones.sk/studentske-prace/informatika/8636-riadenie-kvality-is/