Výpočet spoľahlivosti technických systémov s prihliadnutím na obnovu

Metódy výpočtu spoľahlivosti technických systémov bez zohľadnenia obnovy

Faktory ovplyvňujúce spoľahlivosť technických systémov

Spoľahlivosť komplexu technických prostriedkov

Spoľahlivosť komplexu technických prostriedkov (CTS) má najvýznamnejší vplyv na spoľahlivosť AÚ, preto sa približná spoľahlivosť AÚ často odhaduje len s prihliadnutím na komplex technických prostriedkov.

Kritériá zlyhania technických prostriedkov sú zvyčajne stanovené v súlade s požiadavkami špecifikovanými v normách, špecifikáciách alebo inej technickej dokumentácii pre tieto vozidlá. Keďže väčšina TS má všeobecný priemyselný účel, požiadavky sú stanovené bez ohľadu na systémy, v ktorých tieto TS fungujú. Kritériá zlyhania TS v tomto prípade nezávisia od charakteristík kontrolovaného objektu a požiadaviek na kvalitu riadenia.

Na kvantifikáciu spoľahlivosti komplexu TS sa používajú ukazovatele spoľahlivosti uvedené v článku 1.3. a 1.6.

Spoľahlivosť zložitých moderných jadrových elektrární závisí od rôznych faktorov, ktorých samostatné a komplexné štúdium je potrebné, pretože bez odhalenia fyzikálnej povahy porúch je ťažké vybrať najvhodnejšie oblasti práce na zabezpečenie a zlepšenie spoľahlivosti oboch druhy technických prostriedkov a JE ako celok.

Všetky mnohé faktory, ktoré ovplyvňujú vybavenie zložitých technických systémov, sú zvyčajne klasifikované podľa oblasti ich pôsobenia.

Komu konštruktívny faktory zahŕňajú:

výber štrukturálnych a funkčných schém, metód redundancie a riadenia;

určovanie materiálov a komponentov;

výber režimov a prevádzkových podmienok prvkov v systéme;

stanovenie požiadaviek na tolerancie technických charakteristík prvkov;

výber nastavení a ochrán pre technologické parametre inštalácie;

zohľadnenie psychofyziologických charakteristík operátorov;

vypracovanie prevádzkovej dokumentácie a pod.

Komu výroby faktory zahŕňajú:

· vstupná kontrola kvality materiálov a prvkov prijatých od dodávateľov;

organizácia technologického procesu výrobných zariadení;

Kontrola kvality výrobkov vo všetkých fázach technologického procesu;

kvalifikácia výrobcov;

Zabezpečenie kvality a kontrola inštalácie a uvedenia systémov zariadení do prevádzky;

pracovné podmienky na pracovisku a pod.

Komu operatívne Faktory zahŕňajú faktory, ktoré sa objavujú mimo oblasti návrhu a výroby systému. Podľa charakteru vplyvu na systém možno prevádzkové faktory rozdeliť na cieľ(vplyv vonkajšieho prostredia) a subjektívny(vplyv servisného personálu). Na druhej strane možno objektívne faktory rozdeliť do dvoch skupín: vonkajšie a vnútorné.

Komu vonkajšie faktory zahŕňajú vplyvy spôsobené vonkajším prostredím a prevádzkovými podmienkami. Sú to predovšetkým klimatické faktory (teplota, vlhkosť, slnečné žiarenie, rýchlosť vetra, hmly, snehové búrky, prachové búrky a pod.), mechanické vplyvy (vibrácie, otrasy), elektromagnetické žiarenie, agresivita prostredia a pod. Vnútorné faktory spojené so zmenami parametrov predmetov a konštrukčných materiálov: starnutie, opotrebovanie, korózia. Tieto zmeny sa vyskytujú v priebehu času pod vplyvom vonkajších faktorov. Všetky tieto faktory spravidla ovplyvňujú spoľahlivosť technických systémov ako celku.

Pod subjektívny prevádzkové faktory sú:

Kvalifikácia a školenie servisného personálu;

organizácia a kvalita údržby a bežnej údržby;

Metódy a spôsoby organizácie prevádzky systémov;

· organizovanie zberu a analýzy informácií o prevádzkovej spoľahlivosti vozidla.

Hlavné fázy výpočtu spoľahlivosti.Úlohou výpočtu spoľahlivosti miestnych technických systémov je určiť ukazovatele charakterizujúce ich spoľahlivosť a udržiavateľnosť. Výpočet pozostáva z nasledujúcich krokov:

a) určenie kritérií a typov porúch systému a zloženie vypočítaných ukazovateľov spoľahlivosti;

b) zostavenie štrukturálnej (logickej) schémy založenej na analýze fungovania systému, zohľadnení nadbytočnosti, obnove, monitorovaní zdravotného stavu prvkov atď.;

c) výber metódy na výpočet spoľahlivosti, berúc do úvahy prijaté modely na popis procesov fungovania a obnovy;

d) získanie všeobecnej formy matematického modelu, ktorý spája určené ukazovatele spoľahlivosti s charakteristikami prvkov;

e) výber údajov o ukazovateľoch spoľahlivosti prvkov;

f) vykonanie výpočtu a analýzy výsledkov.

Obsah uvedených etáp do značnej miery závisí od zvolených kritérií zlyhania a vypočítaných ukazovateľov spoľahlivosti, o ktorých sme hovorili vyššie. Medzi najcharakteristickejšie ukazovatele spoľahlivosti TS patrí stredný čas do zlyhania systému, pravdepodobnosť jeho bezporuchovej prevádzky v danom čase, faktor dostupnosti, faktor prevádzkovej dostupnosti a parameter poruchovosti.

Ukazovatele podobného charakteru platia aj pre prvky systému – technické prostriedky, ktorými sú lokálne systémy implementované. Počet uvažovaných ukazovateľov sa rozširuje, ak sa analyzuje pravdepodobnosť prevádzky systémov so zhoršenými ukazovateľmi výkonu, t. j. ak sa zohľadnia postupné (metrologické) poruchy prvkov.

Uvažované ukazovatele sa používajú ako pri vytváraní systémov, tak aj pri ich prevádzke.

Vypracovanie blokovej schémy, ktorá je logickou schémou na výpočet spoľahlivosti systému aj samostatných technických prostriedkov, zahŕňa niektoré body, ktoré je potrebné podrobnejšie prediskutovať. Štrukturálna schéma pre výpočet spoľahlivosti sa vo všeobecnom prípade výrazne líši od funkčného diagramu. Štrukturálny diagram na výpočet spoľahlivosti je grafické zobrazenie prvkov systému, ktoré umožňuje jednoznačne určiť stav systému (funkčný alebo nefunkčný) podľa stavu (prevádzkovateľného alebo nefunkčného) jeho prvkov.

Pre multifunkčné systémy, ako je AC, sú takéto blokové schémy pre každú funkciu; tieto sa bežne označujú ako diagramy spoľahlivosti funkcie alebo diagramy spoľahlivosti funkcie.

Pri zostavovaní schémy môžu byť prvky systému zapojené do série (obr. 2.2, a) alebo paralelne (obr. 2.2, b) v závislosti od ich vplyvu na prevádzkový stav systému. Ak porucha prvku, bez ohľadu na jeho účel, spôsobí poruchu systému, potom je prvok zapojený do série. Ak dôjde k zlyhaniu systému, keď zlyhajú všetky prvky rovnakého typu alebo ich časť, potom sú tieto prvky zapojené paralelne. Sériové zapojenie prvkov sa nazýva aj hlavné zapojenie a paralelné zapojenie sa nazýva záložné.

Ryža. 2.2 Zapojenie prvkov systému:

a - sekvenčné (základné); b - paralelný (záložný)

Pre rovnaké lokálne systémy možno zostaviť rôzne štrukturálne diagramy v závislosti od analyzovanej funkcie systému, ak je multifunkčný, a typu poruchy.

V súčasnosti existuje množstvo usmerňujúcich technických materiálov, ktoré upravujú analytické metódy na výpočet spoľahlivosti súboru technických zariadení JE v štádiu projektovania. Ale so všetkou rozmanitosťou existujúcich metód na výpočet spoľahlivosti systémov možno tieto systémy rozdeliť do troch skupín súvisiacich so systémami:

S jednoduchou štruktúrou, zredukovanou na sériovo-paralelné spojenie prvkov bez zohľadnenia ich obnovy (odhad ukazovateľov spoľahlivosti);

Pri komplexnej štruktúre, ktorá nie je zredukovaná na sériovo-paralelné spojenie prvkov, sa prvky systému neobnovujú (odhad ukazovateľov spoľahlivosti);

S obnoviteľnými prvkami, a to ako pri nule, tak aj v konečnom čase výmeny (obnovy) chybného prvku za prevádzkyschopný (hodnotenie spoľahlivosti, udržiavateľnosti a komplexných ukazovateľov).

Rôzne metódy prvých dvoch skupín pracujú s kvantitatívnymi ukazovateľmi spoľahlivosti pre akékoľvek zákony rozloženia času do zlyhania prvkov. Medzi tieto metódy patrí klasická metóda, založená na základných pojmoch a vetách teórie pravdepodobnosti, a logicko-pravdepodobnostná. Rôzne metódy tretej skupiny sú určené typom zákonov rozdelenia času do zlyhania a obnovy, zložitosťou systému. Hlavnými sú metódy prechodových pravdepodobností a intenzít, ktoré využívajú aparát Markovových procesov s diskrétnym a spojitým časom a metóda využívajúca aparát semimarkovských procesov.

Pomocou zvolenej metódy na základe blokovej schémy systému sa určia analytické modely, ktoré spájajú jeho ukazovatele spoľahlivosti s charakteristikami prvkov a procesmi ich údržby. Analytické modely vo forme vzorcových závislostí, ktoré spájajú uvedené veličiny a sú vhodné na vykonávanie analýzy spoľahlivosti, možno získať pre relatívne jednoduché systémy zavedením množstva zjednodušujúcich predpokladov do matematického popisu charakteristík systémov a procesov. Pre komplexné obnoviteľné systémy, ktoré zahŕňajú subsystémy JE, sa ukazovatele spoľahlivosti často určujú pomocou štatistického (simulačného) modelovania.

Výber charakteristík spoľahlivosti prvkov štruktúrneho diagramu systémov je plný ťažkostí, ktoré určuje množstvo faktorov. Patrí medzi ne závislosť ukazovateľov spoľahlivosti od prevádzkových podmienok, ktoré sa môžu výrazne líšiť v heterogénnych typoch výroby, takže pasové údaje o spoľahlivosti nemusia zodpovedať ich skutočným hodnotám. Pre niektoré prvky, ktoré tvoria systém, nemusia byť tieto indikátory dostupné, napríklad pre uzatváracie ventily, káblové a potrubné komunikačné vedenia atď. Údaje o indikátoroch udržiavateľnosti zariadení často nie sú dostupné. V tomto ohľade je pri výbere indikátorov spoľahlivosti pre prvky systému potrebné použiť údaje o spoľahlivosti iných zariadení, ktoré sú im v dizajne blízke. .

Pomocou ukazovateľov spoľahlivosti prvkov sa podľa získaných matematických modelov vykonáva výpočet ukazovateľov spoľahlivosti systémov, ktorý je možné vykonať ručne alebo na počítači pomocou príslušných aplikačných softvérových balíkov.

Klasická metóda hodnotenia spoľahlivosti. Keďže pri hlavnom spojení prvkov (pozri obr. 2.2, a) nastáva prevádzkyschopný stav systému vtedy, keď sa prevádzkyschopné stavy všetkých prvkov zhodujú, pravdepodobnosť tohto stavu systému je určená súčinom pravdepodobností prevádzkyschopné stavy všetkých prvkov. Ak sa systém skladá z P prvky zapojené do série, potom s pravdepodobnosťou bezporuchovej prevádzky každého z prvkov p i (t) pravdepodobnosť zlyhania systému

Keď sú prvky zapojené paralelne a za predpokladu, že práca jedného z paralelne zapojených prvkov postačuje na fungovanie systému, porucha systému je spoločnou udalosťou, ktorá nastane, keď zlyhajú všetky paralelne zapojené prvky. Ak je zapojený paralelne t prvkov (pozri obr. 2.2, b) a pravdepodobnosť zlyhania každého z nich qj(t) = 1-pj(t), potom pravdepodobnosť zlyhania tohto systému

. (2.2)

Ak bloková schéma spoľahlivosti systému pozostáva z prvkov zapojených sériovo a paralelne, potom jej spoľahlivosť možno vypočítať pomocou (2.1), (2.2).

Na určenie hodnoty stredného času do zlyhania systému a ďalších ukazovateľov spoľahlivosti je potrebné poznať zákonitosti rozloženia času bezporuchovej prevádzky prvkov (času do zlyhania) systému. Keďže exponenciálny zákon možno prijať v oblasti normálnej prevádzky s uspokojivou presnosťou ako zákon rozloženia času bezporuchovej prevádzky prvkov, potom s hlavným spojením prvkov, ak výraz (2.1) má nasledovné forma:

kde .

Takže s hlavným spojením prvkov, ktoré majú exponenciálny zákon distribúcie doby prevádzkyschopnosti, zákon distribúcie doby prevádzkyschopnosti systému bude tiež exponenciálny, v súlade s tým máme:

; ; ; (2.4)

So záložným pripojením t prvky, ktoré majú exponenciálny zákon rozloženia doby prevádzkyschopnosti, pravdepodobnosť zlyhania skupiny paralelne zapojených prvkov:

Ak sú všetky prvky rovnako spoľahlivé a , potom

; .

Pri redundantnom spojení prvkov teda nie je zachovaný exponenciálny zákon rozloženia doby prevádzkyschopnosti.

V mnohých prípadoch nie je možné použiť vyššie diskutovaný spôsob výpočtu spoľahlivosti, pretože obvod spoľahlivosti nie vždy obsahuje sériovo-paralelné zapojenie prvkov.

Existuje niekoľko druhov klasickej metódy na výpočet spoľahlivosti systémov so zložitou štruktúrou, z ktorých niektoré sa budú posudzovať nižšie v súvislosti s analýzou spoľahlivosti mostného obvodu znázorneného na obr. 2.3. (Tento obvod nie je obmedzený na sériovo-paralelné spojenie prvkov.) Pre všetky prvky obvodu sú známe pravdepodobnosti bezporuchovej prevádzky p 1, p 2, p 3, p 4, p 5 a ich zodpovedajúce pravdepodobnosti zlyhania typu "otvorený". q1, q2, q3, q4 q 5. Je potrebné určiť pravdepodobnosť reťazca medzi bodmi a a b schémy.

Ryža. 2.3 Mostové spojenie prvkov

Metóda enumerácie stavu. Výpočtu spoľahlivosti akéhokoľvek systému bez ohľadu na použitú metódu predchádza určenie dvoch nepretínajúcich sa množín stavov prvkov zodpovedajúcich prevádzkyschopným a nefunkčným stavom systému. Každý z týchto stavov je charakterizovaný súborom prvkov, ktoré sú v prevádzkyschopných a nefunkčných stavoch. Pretože pre nezávislé poruchy je pravdepodobnosť každého zo stavov určená súčinom pravdepodobností prvkov, ktoré sú v zodpovedajúcich stavoch, potom pri počte stavov rovným m je pravdepodobnosť prevádzkyschopného stavu systému

; (2.6)

pravdepodobnosť zlyhania

, (2.7)

kde t - celkový počet zdravých stavov v každom z nich j m, z toho počet použiteľných prvkov sa rovná pôda mimo prevádzky - k .

Významnou nevýhodou metódy štátnej enumerácie je, že aj pri relatívne jednoduchej štruktúre je jej aplikácia spojená s ťažkopádnymi výpočtami.

Metóda rozkladu vzhľadom na špeciálny prvok. Táto metóda je založená na použití vzorca celkovej pravdepodobnosti. V zložitom systéme je pridelený špeciálny prvok, všetky možné stavy Ahoj ktoré tvoria ucelenú skupinu, . Ak je analyzovaný stav systému ALE, potom jeho pravdepodobnosť

. (2.8)

Druhý faktor v (2.8) určuje pravdepodobnosť stavu ALE za predpokladu, že špeciálny prvok je v stave Ahoj .Úvaha Ahoj Stav špeciálneho prvku ako bezpodmienečný umožňuje zjednodušiť blokovú schému spoľahlivosti a zredukovať ju na sériovo-paralelné zapojenie prvkov.

Takže v uvažovanom mostíkovom obvode výber prvku 5 ako špeciálneho s dvoma možnými stavmi (1 - prítomnosť a 2 - neprítomnosť reťazca) R{H 1 } =p5; R{H 2 } =q 5 umožňuje z blokovej schémy znázornenej na obr. 2.3, s bezpodmienečne dobrým stavom prvku 5, prejdite na obvod znázornený na obr. 2.4, a. V prípade poruchy prvku 5 má bloková schéma tvar znázornený na obr. 2,4, b. Ak štát ALE- prítomnosť reťazca medzi a a b, potom v súlade s (2.1) a (2.2) máme:

Ryža. 2.4 Konštrukčné schémy mostného spojenia prvkov zodpovedajúcich: a - prítomnosti obvodu v prvku 5; b - neprítomnosť reťazca v prvku 5

Porovnanie oboch metód výpočtu spoľahlivosti ukazuje, že výber špeciálneho prvku s následnou analýzou zjednodušených blokových diagramov výrazne znižuje výpočty.

Metóda minimálnych ciest a úsekov. V niektorých prípadoch na analýzu spoľahlivosti zložitého systému stačí určiť hraničné odhady spoľahlivosti zhora a zdola.

Pri odhade pravdepodobnosti bezporuchovej prevádzky zhora sa stanovia minimálne zostavy prevádzkyschopných prvkov ( spôsoby), aby ste zabezpečili funkčnosť systému. Pri vytváraní cesty, za predpokladu, že všetky prvky sú v nefunkčnom stave, sa postupným prenášaním prvkov do pracovného stavu vykoná výber možností pripojenia prvkov na zabezpečenie prítomnosti obvodu.

Sada prvkov tvorí minimálnu cestu, ak vylúčenie akéhokoľvek prvku z množiny spôsobí zlyhanie cesty. Z toho vyplýva, že v rámci tej istej cesty sú prvky v hlavnom spojení a samotné cesty sú spojené paralelne. Takže pre uvažovaný mostíkový obvod (obr. 2.3) je množina minimálnych dráh znázornená na obr. 2.5. Keďže ten istý prvok je zahrnutý v dvoch paralelných dráhach, ako výsledok výpočtu sa získa horný odhad spoľahlivosti:

Pri určovaní minima oddielov vykoná sa výber minimálneho počtu prvkov, ktorých prechod z prevádzkyschopného stavu do nefunkčného spôsobuje poruchu systému. Pri správnom výbere prvkov sekcie návrat ktoréhokoľvek prvku do pracovného stavu obnoví pracovný stav systému. Keďže porucha každej zo sekcií spôsobuje zlyhanie systému, prvé sekcie sú zapojené do série. V rámci každej sekcie sú prvky zapojené paralelne, pretože na fungovanie systému stačí mať prevádzkyschopný stav ktoréhokoľvek z prvkov sekcie.

Schéma minimálnych prierezov pre mostový obvod je znázornená na obr. 2.6. Keďže ten istý prvok je zahrnutý v dvoch častiach, výsledný odhad je nižší odhad:

Ryža. 2.5 Sada minimálnych ciest

Ryža. 2.6 Súbor minimálnych sekcií

Pri zostavovaní minimálnych ciest a úsekov sa teda akýkoľvek systém premení na štruktúru s paralelným sériovým alebo sériovo paralelným zapojením prvkov.

Metóda pravdepodobnosti prechodu. S ľubovoľnými distribučnými funkciami doby prevádzkyschopnosti a doby obnovy sa spoľahlivosť systémov analyzuje diskretizáciou času s nastavením pravdepodobnosti prechodu systému z jedného stavu do druhého v každom z jeho intervalov. Vďaka stálosti smerov prechodu systému z jedného stavu do druhého a predpokladu bežného, ​​nezávislého a stacionárneho toku porúch možno systému pripísať Markovove systémy s diskrétnym časom.

Výrazná vlastnosť Markovove systémy je, že pravdepodobnosť prechodu systému do niektorého z možných stavov, ktorých počet je obmedzený, závisí len od predchádzajúceho stavu a nezávisí od predchádzajúcich.

Ryža. 2.7 Označený graf stavu obnoveného systému

Spoľahlivosť takýchto systémov je opísaná sústavou algebraických rovníc, ktorých počet zodpovedá počtu možných stavov sústavy. Na ich zostavenie sa používa orientovaný stavový graf, ktorého vrcholy zodpovedajú možným stavom systému a hrany charakterizujú smer a pravdepodobnosť prechodu z jedného stavu do druhého.

Ako príklad analyzujme spoľahlivosť ochranného systému, ktorý môže byť v troch stavoch: prevádzkový, falošný poplach a neprevádzkový, ako je znázornené na obr. 2.7 s číslami 1, 2, 3. Pre časový interval t pravdepodobnosť str. 11 systém udržiava funkčný stav buď s pravdepodobnosťou p 12 a str. 13 prechádza do nefunkčného stavu 2, 3. Počas rovnakého časového intervalu po falošnom poplachu systém s pravdepodobnosťou p21 sa obnoví a vráti do zdravého stavu 1. Na interval t systém dokáže zachrániť štát 2, pravdepodobnosť tejto udalosti je str. 22. Podobne ako pri pravdepodobnostiach str. 33,str. 31 charakterizujú kvalitu obnovy systému po jeho zlyhaní. Pri obnove všetkých zlyhaných systémov p22=p33=0, ap21=p31=1.

Pravdepodobnosť, že sa systém nachádza v niektorom zo stavov po ičasové intervaly určuje nasledujúci systém algebraických rovníc:

(2.9)

Po ľubovoľnom počte intervalov p1 (i) + p2 (i) + p3 (i) = 1. Pre riešenie sústavy rovníc (2.9) je potrebné nastaviť počiatočné rozdelenie pravdepodobnosti medzi stavmi sústavy. V prevádzkovom stave systému v počiatočnom čase P1(0)=1, a R2(0) = R3(0) = 0.

Pravdepodobnosť nájdenia systému po i intervaloch v štáte j vypočítané podľa vzorca:

Rj(i)=M(0)MjDj,(2.10)

kde M(0)=||P1(0)P2(0)P3(0)||- riadkový vektor počiatočného stavu systému; M i-prechodová matica; DJ-stĺpcový vektor analyzovaného stavu. Obsahuje nuly a jednu jednotku, ktorá stojí na mieste analyzovaného stavu. Ak teda po i intervaloch je určená pravdepodobnosťou, že systém bude v stave falošného poplachu

Matica prechodu je zostavená priamo zo stavového grafu. Pre uvažovaný príklad má prechodová matica nasledujúci tvar:

. (2.11)

Matica prechodu je štvorcová: počet riadkov a stĺpcov sa rovná počtu stavov systému. Na zápis matice je vhodné použiť nasledujúcu metódu. Ak mimo matice označíme tým 1i, 2i, 3i stav systému po i intervaloch a 1(i-1), 2(i-1), 3(i-1) jeho predchádzajúce stavy, potom sa do matice zapisujú pravdepodobnosti prechodu zo zodpovedajúceho predchádzajúceho do toho či onoho súčasného. Ak teda predchádzajúci stav 2(i-1) a prúd 1i, potom na priesečník príslušného riadku a stĺpca napíšeme str. 21. Riadky prechodovej matice teda určujú pravdepodobnosti záchrany jedného alebo druhého stavu a jeho odchodu do iných stavov systému, súčet týchto pravdepodobností sa rovná jednej.

Stĺpce matice sú koeficienty rovníc (2.9) pre Pj (i-1). Tieto koeficienty určujú pravdepodobnosti vstupu systému do analyzovaného stavu zo všetkých možných, vrátane analyzovaného. Pri násobení matíc nie je povolená ich permutácia v (2.10).

Pre nekonečne veľký počet intervalov rozdelenie pravdepodobnosti medzi stavmi nezávisí od počiatočného stavu a je určené systémom rovníc:

(2.12)

kde R1, R2, R3 sú limitné (konečné) pravdepodobnosti, že systém bude v zodpovedajúcich stavoch.

Keďže rovnice (2.12) sú lineárne závislé, určiť R1R2, P3 používa sa rovnica P 1 + P 2 + P 3 \u003d 1 a dve z najjednoduchších rovníc (2.12).

Metóda prechodových intenzít. Exponenciálne rozdelenie popisuje fungovanie technických systémov a ich prvkov v oblasti bežnej prevádzky s uspokojivou presnosťou. Použitie exponenciálneho rozdelenia na popis procesu obnovy umožňuje reprezentovať analyzované systémy v prípade bežných nezávislých porúch vo forme Markovove systémy so spojitým časom a použiť systém lineárnych diferenciálnych rovníc prvého rádu na analýzu ich spoľahlivosti.

Exponenciálne rozdelenie popisuje procesy v systémoch bez histórie, pretože zmena pravdepodobnosti ich prítomnosti v určitom stave za určitý interval t závisí len od trvania časového intervalu.

Stručne uvažujme o metóde na určenie pravdepodobnosti stavov Markovovho procesu so spojitým časom.

Nech je systém v niektorých stavoch, ktorých počet je konečný (rovná sa n). Čísla štátov: 0, 1, 2, 3,…, č.

Ak systém môže byť iba v dvoch stavoch - zdravý a zotavujúci sa, potom zníženie pravdepodobnosti jedného stavu vedie k zodpovedajúcemu zvýšeniu pravdepodobnosti iného stavu, pretože v každom okamihu Po(t)+Pi(t)=1. Na obr. 2.8 a je uvedený orientovaný prechodový graf systému pre uvažovanú situáciu. Tu stav 0 zodpovedá zdravému a stav 1 zodpovedá nefunkčnému (obnovenie). Prechody systému zo zdravého stavu (0) do nefunkčného stavu (1) nastávajú pôsobením toku porúch s poruchovosťou a prechodom systému z nefunkčného (1) do zdravého stavu ( 0) sa vyskytuje pri pôsobení toku obnovy s mierou obnovy . Prechod systému zo stavu 0 do stavu 1 nastáva v čase prvej poruchy.

Teda pravdepodobnosti nájdenia systémov v súčasnosti t+dt v každom z uvažovaných stavov sú spojené so zodpovedajúcimi pravdepodobnosťami:

(2.13)

Porovnanie (2.13) so sústavou rovníc (2.9) ukazuje, že v Markovových sústavách so spojitým časom sa pravdepodobnosti str. 11, str. 12, str. 22, str. 21 pomocou prvého je možné zostaviť maticu prechodu podobnú (2.11).

Ryža. 2.8 Graf stavu obnoveného systému:

a - s dvoma stavmi; b - ľubovoľný uzol grafu

Pokiaľ ide o /dt=dPi(t)/dt, potom pravdepodobnosť nájdenia systému so spojitým časom v každom zo stavov určuje nasledujúci systém diferenciálnych rovníc prvého rádu, nazývaný systém Kolmogorov-Chapman:

(2.14)

Vo všeobecnom prípade je počet diferenciálnych rovníc určený počtom možných stavov sústavy, ktoré musia byť (rovnako ako pri sústavách s diskrétnym časom) obmedzené.

Pri písaní sústavy diferenciálnych rovníc sa predbežne zostaví zoznam možných stavov sústavy a príslušný orientovaný stavový graf podobný tomu, ktorý je znázornený na obr. 2.8. Každý z vrcholov zodpovedá jednému zo stavov systému a orientácia hrán je určená smerom prechodu. Stavový graf vyššie diskutovaného dvojstavového systému je teda zvyčajne znázornený tak, ako je znázornené na obr. 2.8, a. Pomocou neho a systému diferenciálnych rovníc 2.14 je ľahké skontrolovať všeobecný princíp písania diferenciálnej rovnice pre ľubovoľný vrchol i(obr. 2.8, b), z ktorého môže systém vychádzať t vrcholov a z ktorých prechádza do jedného a P vrcholy:

(2.13)

Overením správnosti zostavenia sústavy diferenciálnych rovníc je nulová rovnosť súčtu pravých častí rovníc.

Prvý súčet na pravej strane vzorca (2.13) sa vzťahuje na tieto hodnoty j, pre ktoré je možný priamy prechod zo stavu poruchy do pracovného stavu (t. j. pre ktorý ), a druhá - na tieto hodnoty j, u ktorých je možný priamy prechod zo zdravého stavu do stavu zlyhania (t.j. ).

Sústava diferenciálnych rovníc (2.13) je riešená za počiatočných podmienok, ktoré špecifikujú pravdepodobnosti stavov v počiatočnom momente pri t = 0:

a na každú chvíľu t normalizačná podmienka je splnená:

Sústavu rovníc (2.13) možno získať priamo z formy označeného stavového grafu, ak sa použije nasledujúce pravidlo: pre každý z možných stavov sústavy je napísaná rovnica, na ľavej strane ktorej je a na pravej strane toľko členov, koľko sú šípky grafu v kontakte s daným stavom. Ak šípka smeruje do daného stavu, potom sa pred výraz umiestni plus, ak šípka smeruje z tohto stavu, mínus. Každý z členov sa bude rovnať súčinu intenzity prechodu z daného stavu (alebo do daného stavu) pravdepodobnosťou stavu, z ktorého šípka opustí.

Riešenie sústavy rovníc (2.13) prebieha podľa známych pravidiel pre riešenie sústavy diferenciálnych rovníc. Dá sa to však výrazne zjednodušiť, ak vezmeme do úvahy, že uvažovaný proces je stacionárny Markovov proces, pre ktorý sú deriváty možno považovať za rovné nule (pravdepodobnosti stavov sa v čase nemenia). Systém diferenciálnych rovníc (2.13) sa potom transformuje na systém algebraických rovníc.

Teória spoľahlivosti, ktorej základné pojmy uvádza Ch. 1 bol vyvinutý na popis technických systémov vrátane hardvéru JE. K poruchám dochádza v dôsledku zničenia a starnutia komponentov, pričom obnovenie si vyžaduje opravu, nastavenie, výmenu komponentov alebo zariadenia. Ničenie a starnutie nie je charakteristické ani pre softvér (SW) systému ako celku, ani pre jednotlivé programy. Napriek tomu je možné niektoré pojmy, termíny a metódy spoľahlivosti preniesť aj do softvéru (pri akceptovaní určitej podmienenosti takéhoto prístupu).

Pri vývoji softvéru môže existovať niekoľko dôvodov, ktoré vedú k chybám: nesprávne pochopenie algoritmu programátorom; nesprávna kompilácia všeobecnej štruktúry softvéru a vzťahu programov; nesprávny výber metód ochrany programu; chyby pri prenose programov na médiá a pod.

Ladiaci softvér nedokáže odstrániť všetky chyby, keďže počet možných kombinácií vstupných údajov a stavov systému pri jeho činnosti je taký veľký, že je takmer nemožné vopred skontrolovať všetky možné vetvy programu. Preto je tok momentov prejavu softvérových chýb počas prevádzky AS náhodný: chyby sa objavujú v náhodných časoch, keď program vstúpi do sekcie, kde je chyba.

Existujú dva prístupy k výberu indikátorov spoľahlivosti softvéru. Na jednej strane je možné použiť bežné ukazovatele spoľahlivosti, ako je pravdepodobnosť absencie chýb v čase t; stredný čas medzi chybami; priemerný čas obnovy softvéru po ukončení prevádzky a pod. Tieto ukazovatele charakterizujú prejavy softvérových chýb v čase, preto je vhodné ich používať pre softvér, ktorý je nepretržite prevádzkovaný. Pre nepravidelne používané programy (v prípade potreby) je možné použiť také ukazovatele, ako je pravdepodobnosť úspešného dokončenia jedného spustenia programu, pravdepodobnosť, že tento softvér bude schopný vyriešiť ľubovoľnú úlohu z prúdu reálnych úloh.

Pri aplikácii konceptov klasickej teórie spoľahlivosti na softvér je však potrebné vziať do úvahy vlastnosti a rozdiely týchto objektov od tradičných technických systémov, pre ktoré bola teória spoľahlivosti pôvodne vyvinutá:

Pojmy a metódy teórie spoľahlivosti nie sú použiteľné pre všetky typy programov – možno ich použiť len pre softvér, ktorý funguje v reálnom čase a priamo interaguje s vonkajším prostredím;

Dominantnými faktormi, ktoré rozhodujú o spoľahlivosti programov, sú chyby a chyby dizajnu a vývoja a fyzická likvidácia softvérových komponentov pod vonkajšími vplyvmi je druhoradá;

Pomerne zriedkavá deštrukcia softvérových komponentov a potreba ich fyzickej výmeny vedie k zásadnej zmene koncepcií zlyhania a zlyhania programov a k ich oddeleniu podľa dĺžky trvania obnovy vzhľadom na určité prípustné prestoje pre fungovanie informačného systému. ;

Nepredvídateľnosť miesta, času a pravdepodobnosti prejavu defektov a chýb, ako aj ich ojedinelé odhalenie pri samotnej prevádzke dostatočne spoľahlivého softvéru, neumožňuje efektívne využitie tradičných metód na apriórny výpočet ukazovateľov spoľahlivosti komplexných systémy zamerané na stabilné, merateľné hodnoty spoľahlivosti komponentov komponentov;

Po odstránení chyby v programe sa rovnaká chyba v budúcnosti nemôže opakovať. Okrem toho chyby nájdené v softvéri jedného z niekoľkých systémov rovnakého typu sú zvyčajne opravené vo všetkých takýchto systémoch. Tok softvérových chýb je nestacionárny, pretože pri detekcii chýb sa parameter ich toku znižuje. Poruchy vozidla z rovnakého dôvodu sa opakujú; po obnovení sa rovnaká porucha tohto a iných podobných prostriedkov z rovnakého dôvodu môže zopakovať znova. Tok porúch ES v ustálenom stave možno považovať za stacionárny s jednou alebo druhou aproximáciou.

Berúc do úvahy vyššie uvedené vlastnosti, na popis spoľahlivosti softvéru možno použiť špeciálne ukazovatele, ktoré sú špecifické len pre softvér a odrážajú najmä kvalitu vykonania softvéru. Tieto ukazovatele umožňujú vyhodnotiť nasledujúce vlastnosti softvéru, ktoré tvoria pojem „spoľahlivosť softvéru“:

1. Správnosť- statická vlastnosť programu, definovaná ako absencia chýb v ňom. Správnosť programov je zabezpečená ladením (kontrolou) na súbore počiatočných údajov upravených dokumentáciou.

2. Udržateľnosť- dynamická vlastnosť programu, ktorá charakterizuje jeho schopnosť podávať správne výsledky pri hardvérových, informačných a ergatických vplyvoch. Existujú dva typy trvalej udržateľnosti:

- tolerancie- schopnosť programu pokračovať vo svojej práci a produkovať správne výsledky za prítomnosti uvedených vplyvov.

- konzervativizmus- schopnosť programu v prípade porúch, ktoré neumožňujú správne vyriešiť problém, preniesť výpočtový systém do poruchového stavu, z ktorého je možné vykonať reštart s minimálnymi stratami. Stabilita programu je zabezpečená štrukturálnou, informačnou, časovou a algoritmickou redundanciou.

Klasifikácia softvérových porúch. Moderný softvér sa vyznačuje takými typmi porúch, ako sú zlyhanie, zlyhanie a softvérová chyba, ktorého definícia bola uvedená v časti 1.1. Na druhej strane, zlyhania softvéru sú:

- programové- v dôsledku nezistených chýb v programe, ktoré sa vyskytujú pri určitej kombinácii údajov a príkazov zodpovedajúcich špecifikácii;

- informačný- výsledky práce sú skreslené v dôsledku chýb vo vstupných údajoch;

- hardvér- vznikajú v dôsledku občasných porúch technických prostriedkov a/alebo výskytu chýb v prevádzkových prostrediach (poruchy);

- ergatický- vznikajú v dôsledku nesprávneho konania používateľov.

Pri určovaní spoľahlivosti softvéru sa spravidla zohľadňujú iba zlyhania softvéru v dôsledku prítomnosti nezistených chýb v programe.

Chyby sa môžu vyskytnúť vo všetkých fázach životného cyklu softvéru. Zvážte typy softvérových chýb a zodpovedajúce príklady.

1. Nesprávne vyjadrenie problému.

2. Nesprávny algoritmus.

3. Chyba analýzy (neúplné zaúčtovanie situácií, ktoré môžu nastať; logické chyby).

4. Sémantické chyby (nepochopenie poradia, v akom sa operátor vykonáva).

5. Syntaktické chyby (porušenie pravidiel definovaných programovacím jazykom).

6. Chyby pri vykonávaní operácií (príliš veľké číslo, delenie nulou, extrahovanie druhej odmocniny záporného čísla atď.).

7. Chyby v údajoch (neúspešné určenie možného rozsahu zmien údajov).

8. Tlačové chyby (zamieňajú sa znaky, ktoré sú si pravopisne blízke, napr. číslo 1 a písmená I,l).

9. Vstupno-výstupné chyby (nesprávne čítanie vstupných údajov, nesprávne nastavenie formátov údajov).

Ukazovatele kvality a spoľahlivosti moderného softvéru. Formalizácii indikátorov kvality softvéru je venovaná skupina normatívnych dokumentov, v ktorých sú zvýraznené vlastnosti, ktoré umožňujú hodnotiť softvér z pohľadu používateľa, vývojára a projektového manažéra. Odporúča sa 6 hlavných charakteristík kvality softvéru, z ktorých každá je podrobne opísaná niekoľkými (celkovo 21) podcharakteristikami:

1. Funkčnosť je súbor atribútov, ktoré definujú účel, názvoslovie, základné nevyhnutné a postačujúce funkcie softvéru špecifikované technickými špecifikáciami zákazníka alebo potenciálneho používateľa Funkčná vhodnosť je podrobne uvedená:

vhodnosť na použitie;

presnosť;

bezpečnosť;

Schopnosť vzájomnej interakcie;

Súlad s normami a pravidlami dizajnu.

2. Spoľahlivosť- je to schopnosť programu poskytnúť dostatočne nízku pravdepodobnosť zlyhania v procese fungovania v reálnom čase. Spoľahlivosť sa odporúča charakterizovať:

Úroveň dokončenia (bez chýb);

Odolnosť voči chybám;

Reštartovateľnosť.

3. Použiteľnosť popísané:

jasnosť;

schopnosť učiť sa;

Jednoduchosť použitia.

Redundancia zdrojov;

dočasnú nadbytočnosť.

5. Udržateľnosť podrobne:

Pohodlie pre analýzu;

variabilita;

stabilita;

Testovateľnosť.

6. Prenosnosť navrhol reflektovať:

prispôsobivosť;

štruktúrovaný;

nahraditeľnosť;

Implementovateľnosť.

Medzi ukazovatele spoľahlivosti softvéru patria nasledujúce ukazovatele.

1. Pravdepodobnosť chýb v softvéri

(2.16)

kde n je počet možných podmnožín vstupných údajov; pi- pravdepodobnosť výberu i-tá podmnožina; y i- dynamická premenná, y i=0, ak je výstup pravdivý pre i-tá podmnožina; y i=1, ak je výstup neplatný.

Štatistická definícia pravdepodobnosti chyby

kde l je počet vstupných podmnožín, ktoré zlyhali počas testovania.

2. Funkcia spoľahlivosti softvéru, definovaná ako pravdepodobnosť, že k zlyhaniu softvéru došlo mimo intervalu (0,t):

(2.18)

kde je náhodný časový okamih, v ktorom došlo k zlyhaniu softvéru.

Dynamický výpočtový proces spracovania dát, automatizovaná príprava rozhodnutí a vývoj kontrolných akcií;

Informácie nahromadené v databázach, ktoré odrážajú objekty vonkajšieho prostredia a procesy ich spracovania;

Objektový kód programov vykonávaných výpočtovými prostriedkami počas prevádzky softvéru;

Informácie vydávané spotrebiteľom a ovládačom, ktoré sú výsledkom spracovania počiatočných údajov a informácií nazhromaždených v databáze.

Vyššie uvedené softvérové ​​komponenty sú určitým spôsobom objektmi zraniteľnosti, ktoré sú ovplyvnené rôznymi destabilizujúcimi faktormi, ktoré možno rozdeliť na domáci vlastné samotným objektom zraniteľnosti a externé podmienené prostredím, v ktorom tieto objekty pôsobia.

Komu vnútorné destabilizujúce faktory zahŕňajú nasledujúce softvérové ​​chyby:

Systémové chyby pri stanovovaní cieľov a zámerov tvorby softvéru, pri formulovaní požiadaviek na funkcie a charakteristiky riešenia problémov, pri určovaní podmienok a parametrov vonkajšieho prostredia, v ktorom sa má softvér používať;

Algoritmické vývojové chyby pri priamej špecifikácii softvérových funkcií, pri určovaní štruktúry a interakcie komponentov softvérových komplexov, ako aj pri používaní databázových informácií;

Chyby programovania v programových textoch a popisoch údajov, ako aj v zdrojovej a výslednej dokumentácii komponentov a softvéru vo všeobecnosti;

Nedostatočná účinnosť používaných metód a prostriedkov prevádzkovej ochrany programov a údajov pred poruchami a poruchami a zabezpečenie spoľahlivosti fungovania PS v podmienkach náhodných negatívnych vplyvov.

Vonkajšie destabilizujúce faktory sú:

Chyby personálu prevádzky a údržby počas prevádzky softvéru;

skreslenia v telekomunikačných kanáloch informácií pochádzajúcich z externých zdrojov a prenášaných spotrebiteľom, ako aj charakteristiky externých informačných tokov, ktoré sú pre konkrétny AS neprijateľné;

Poruchy a poruchy vo vybavení výpočtových zariadení;

Zmeny v zložení a konfigurácii komplexu interagujúcich zariadení JE nad limity overené počas testovania alebo certifikácie a premietnuté do prevádzkovej dokumentácie.

Jednou z najdôležitejších charakteristík kvality softvéru je spoľahlivosť.

Spoľahlivosť- vlastnosť softvéru zostať v prevádzke po určitú dobu, za určitých prevádzkových podmienok, berúc do úvahy dôsledky každej poruchy pre používateľa.

spracovateľný Toto je stav softvérového nástroja, v ktorom je schopný vykonávať špecifikované funkcie s parametrami stanovenými požiadavkami technických špecifikácií. Poruchová udalosť je spojená s prechodom do nezdravého stavu.

Dôvodom zlyhania softvéru je nemožnosť jeho úplného overenia počas testovania a testovania. Pri prevádzke softvéru v reálnych podmienkach môže nastať taká kombinácia vstupných údajov, ktorá spôsobí poruchu, preto funkčnosť softvéru závisí od vstupných údajov a čím je táto závislosť menšia, tým je úroveň spoľahlivosti vyššia.

Na hodnotenie spoľahlivosti sa používajú tri skupiny ukazovateľov: kvalitatívne, ordinálne a kvantitatívne.

Medzi hlavné kvantitatívne ukazovatele spoľahlivosti softvéru patria:

Pravdepodobnosť bezporuchovej prevádzky P(t3) je pravdepodobnosť, že v rámci daného prevádzkového času nedôjde k poruche systému. Prevádzkový čas - trvanie alebo množstvo práce:

P(t3) = P(t≥t3),

kde t je náhodný prevádzkový čas PS do zlyhania, t3 je špecifikovaný prevádzkový čas.

Pravdepodobnosť zlyhania je pravdepodobnosť, že v rámci daného prevádzkového času dôjde k zlyhaniu systému. Tento indikátor je opakom predchádzajúceho:

Q(t3) = 1 - P(t3).

Miera zlyhania systému λ(t) je podmienená hustota pravdepodobnosti zlyhania softvéru, ku ktorému dôjde v určitom časovom bode, za predpokladu, že pred týmto časom nedošlo k zlyhaniu:

λ(t) = f(t) / P(t),

kde f(t) je hustota pravdepodobnosti zlyhania v čase t:

Medzi λ(t) a P(t) je nasledujúci vzťah:

V konkrétnom prípade λ = konšt.

Р(t) = exp(- λ(t) d t.).

Р(t) = exp(-λ(t)).

Ak je počas testovania počet porúch za určitý časový interval pevný, potom λ(t) je počet porúch za jednotku času.

Stredná doba do zlyhania Ti - matematické očakávanie doby prevádzky softvérového nástroja do ďalšej poruchy

kde t je prevádzkový čas softvéru od (K-1) do zlyhania K.

Ti = (t1+t2+...+tn)/n,

kde ti je čas prevádzky softvéru medzi poruchami, n je počet porúch.

Priemerný čas obnovy Тв - matematické očakávanie času obnovy tвi - čas strávený obnovou a lokalizáciou zlyhania - t.l.i, čas eliminácie zlyhania - tu.о.i, čas kontroly priepustnosti - tp.p.i:

tвi = tо.l.i + tu.о.i + tp.p.i.

Pri tomto ukazovateli pojem "čas" znamená čas strávený programátorom na uvedených druhoch práce.

Faktor dostupnosti K2 – pravdepodobnosť, že sa očakáva, že softvérový nástroj bude v ľubovoľnom čase zamýšľaného použitia v prevádzkovom stave:

K2 \u003d Ti / (Ti + Tv).

Chyby sú príčinou zlyhania softvéru., ktoré možno nazvať: interná vlastnosť softvérového nástroja, reakcia softvérového nástroja na zmenu vonkajšieho prostredia prevádzky. To znamená, že pri najdôkladnejšom testovaní, za predpokladu, že sa podarilo zbaviť všetkých interných chýb, nie je možné s úplnou istotou povedať, že počas prevádzky softvéru nedôjde k poruche.

Hlavným prostriedkom na určenie kvantitatívnych ukazovateľov spoľahlivosti sú modely spoľahlivosti, čím sa myslí matematický model zostavený na posúdenie závislosti spoľahlivosti od parametrov známych vopred alebo odhadnutých počas tvorby softvérového nástroja. Definícia spoľahlivosti ukazovateľov sa v tomto smere zvyčajne uvažuje v jednote troch procesov – predikcia, meranie, hodnotenie.

Predpoveď- ide o definíciu kvantitatívnych ukazovateľov spoľahlivosti na základe charakteristík budúceho softvéru.

Meranie- ide o definíciu kvantitatívnych ukazovateľov spoľahlivosti na základe analýzy údajov o intervaloch medzi poruchami získaných počas vykonávania programov v testovacích podmienkach.

Hodnotenie- ide o definíciu kvantitatívnych ukazovateľov spoľahlivosti na základe údajov o intervaloch medzi poruchami získaných pri testovaní softvéru v reálnych prevádzkových podmienkach.

Všetky modely spoľahlivosti možno klasifikovať podľa toho, ktorý z uvedených procesov podporujú (prediktívne, prediktívne, hodnotiace, meracie). Je potrebné poznamenať, že modely spoľahlivosti, ktoré používajú údaje o intervaloch medzi poruchami ako počiatočné informácie, možno priradiť k meraniu aj odhadu rovnako. Niektoré modely na základe informácií získaných počas testovania softvéru umožňujú predpovedať správanie sa softvéru počas prevádzky.

Zoberme si analytické a empirické modely spoľahlivosti.

Analytické modely umožňujú vypočítať kvantitatívne ukazovatele spoľahlivosti na základe údajov o správaní programu počas testovania (meracie a vyhodnocovacie modely).

Empirické modely sú založené na analýze štrukturálnych vlastností programov. Uvažujú závislosť ukazovateľov spoľahlivosti od počtu intermodulárnych spojov, počtu cyklov v moduloch, pomeru počtu priamych úsekov k počtu odbočovacích bodov a podobne. Je potrebné poznamenať, že empirické modely často nedávajú konečné výsledky ukazovateľov spoľahlivosti.

Modelovanie spoľahlivosti analytického softvéru zahŕňa štyri kroky:

Definícia návrhov súvisiacich s postupom testovania softvéru;

Vývoj alebo výber analytického modelu na základe predpokladov o postupe testovania;

Výber parametrov modelu pomocou získaných údajov;

Aplikácia modelu - výpočet kvantitatívnych ukazovateľov spoľahlivosti podľa modelu.

Analytické modely predstavujú dve skupiny: dynamické a statické modely. V dynamických modeloch spoľahlivosť softvéru, správanie programu (výskyt porúch) sa zohľadňuje v čase. V statických modeloch výskyt porúch nie je spojený s časom, ale iba so závislosťou počtu chýb od počtu testov (podľa oblasti chýb) alebo závislosťou počtu chýb od charakteristík vstupných údajov (podľa údajov oblasť) sa berú do úvahy. Pre použitie dynamických modelov je potrebné mať údaje o výskyte porúch v čase. Statické modely zásadne sa líšia od dynamických tým, že nezohľadňujú čas výskytu chýb v procese testovania a nepoužívajú žiadne predpoklady o správaní sa rizikovej funkcie λ(t). Tieto modely sú postavené na solídnom štatistickom základe.

Model Corcoran

Aplikácia modelu vyžaduje znalosť jeho nasledujúcich ukazovateľov:

Model obsahuje rôznu pravdepodobnosť porúch pre rôzne zdroje chýb a podľa toho aj rôznu pravdepodobnosť ich opravy;

Model využíva také parametre ako výsledok iba N pokusov, v ktorých sa pozorujú chyby Ni i-tého typu;

Identifikácia pri N testoch chyby i-tého typu sa objaví s pravdepodobnosťou ai.

Indikátor úrovne spoľahlivosti R sa vypočíta podľa tohto vzorca:

kde N0 je počet bezporuchových (alebo neúspešných) skúšok vykonaných v sérii N skúšok,

k je známy počet typov chýb,

Yi - pravdepodobnosť chyby,

pre Ni > 0, Yi = ai,

pre Ni = 0, Yi = 0.

Schumannov model

Schumannov model sa vzťahuje na dynamické modely s diskrétnym časom, pre ktoré sa údaje zhromažďujú počas testovania softvéru počas pevných alebo náhodných časových intervalov. Schumannov model predpokladá, že testovanie prebieha v niekoľkých etapách. Každá fáza je vykonaním programu na kompletnom súbore vyvinutých testovacích údajov. Nájdené chyby sú zaznamenané, ale nie sú opravené. Na konci etapy sa vypočítajú kvantitatívne ukazovatele spoľahlivosti, opravia sa zistené chyby, opravia sa sady testov a vykoná sa ďalšia etapa testovania. Schumannov model predpokladá, že počet chýb v programe je konštantný a počas procesu opravy sa nezavedú žiadne nové chyby. Miera detekcie chýb je úmerná počtu zostávajúcich chýb.

Predpokladá sa, že pred testovaním sú chyby Et. Počas testovacieho času τ sa zistia chyby εc na inštrukciu v jazyku stroja.

Špecifický počet chýb na jednu strojovú inštrukciu, ktoré zostávajú v systéme po testovacom čase τ, sa teda rovná:

εr (τ) = Et / It * εc (τ),

kde Je to celkový počet strojových inštrukcií, o ktorých sa predpokladá, že sú počas testovacej fázy konštantné.

Predpokladá sa, že hodnota funkcie poruchovosti Z(t) je úmerná počtu chýb zostávajúcich v programe po čase τ strávenom testovaním:

Z (t) = C * εr (τ),

kde C je nejaká konštanta

t je čas behu programu bez porúch.

Potom, ak sa doba behu programu bez poruchy t počíta od bodu t = 0 a τ zostane nemenné, funkcia spoľahlivosti alebo pravdepodobnosť bezporuchovej prevádzky v intervale od 0 do t sa rovná:

R (t, τ) = exp (-C * * t) (1,9)

tav = 1/(C*).

Potrebujeme nájsť počiatočnú hodnotu chýb Et a koeficient úmernosti - C. Pri testovaní sa zbierajú informácie o čase a počte chýb pri každom chode, t.j. celkový čas testovania τ je súčtom času každého cyklu

τ = τ1 + τ2 + τ3 + … + τn.

Za predpokladu, že chybovosť je konštantná a rovná sa λ, možno ju vypočítať ako počet chýb za jednotku času, kde Ai je počet chýb v i-tom chode:

S údajmi pre dva rôzne skúšobné časy τa a τb, ktoré sú zvolené ľubovoľne, berúc do úvahy požiadavku, že εc(τb) > εc(τa), môžeme porovnať rovnice uvedené vyššie pre τa a τb:

Neznámy parameter C získame dosadením Et do výrazu (1.13) Výpočet vzťahov (1.13). Výpočtom vzťahov (1.13) a (1.14) dostaneme:

programy podľa vzorca (1.9).

Výpočty vykonáme vo vzťahu k učebným osnovám.

Napríklad program má It = 4381 príkazov.

Počas následných testovacích jázd sa získali nasledujúce údaje:

Dva body vyberieme na základe požiadavky, aby počet zistených chýb v intervale A - B bol väčší ako v intervale 0 - A. Pre bod A berieme 2 chody a pre bod B - 8 chodov. Potom budú chyby zistené v testovacích fázach v intervaloch 0 -A a A - B rovnaké:

εс(τА) = 3 ⁄ 4381= 0,0007

εс(τВ) = 7 ⁄ 4381= 0,0015.

Čas testovania v intervaloch sa rovná:

Vypočítajme intenzitu chýb v dvoch intervaloch:

λА = 3 ⁄ 13 = 0,23

λB = 7 ⁄ 12 = 0,58.

Potom sa počet chýb dostupných pred testovaním rovná:

Vypočítajme pravdepodobnosť bezporuchovej prevádzky počas času t pri τ =

Vezmime si t=60 min.

Spoľahlivosť bezporuchovej prevádzky je teda pomerne vysoká a pravdepodobnosť porúch a chýb je malá.

Modelka La Padula

Pozri metodickú príručku pre tvorbu diplomov (LE Kunitsyna), strany 27-29.

Spoľahlivosť softvéru | blog inžiniera spoľahlivosti stránok

Spoľahlivosť softvéru. Úvod

Spoľahlivosť softvéru je záhadná a nepolapiteľná vec. Ak sa pokúsite nájsť niečo na túto tému v Yandex, uvidíte veľa teoretických článkov, kde je napísaných veľa buzzwordov a vzorcov, ale ani jeden článok neobsahuje jediný príklad skutočného výpočtu spoľahlivosti programu.

Ak chcete dobre porozumieť problematike spoľahlivosti a stať sa vysoko plateným špecialistom, pozývam vás na môj kurz školenia spoľahlivosti.

V podnikoch kozmického priemyslu je situácia ešte lepšia. Keď som sa spýtal špecialistov jednej uralskej mimovládnej organizácie, ako hodnotia spoľahlivosť softvéru, vykulili oči a povedali: „Čo tam je, berieme to ako jednotku a hotovo. A spoľahlivosť poskytujeme testovaním. Súhlasím, že takýto prístup má právo na život, ale chcel by som viac. Skrátka, napísal som vlastnú metodiku, prosím o lásku a priazeň. Nižšie je uvedená kalkulačka, na ktorej si môžete vypočítať spoľahlivosť tohto vášho softvéru.

Problém spoľahlivosti softvéru sa stáva čoraz dôležitejším v dôsledku neustálej komplikácie vyvíjaných systémov, rozširovania škály úloh, ktoré sú im pridelené, a následne výrazného nárastu objemu a zložitosti softvéru. Skrátka, dožili sme sa dňa, keď sa hardvér stal spoľahlivejším ako softvér a jedna chyba v programovom kóde môže zničiť vesmírnu misiu v hodnote miliárd dolárov.

Spoľahlivosť softvéru je určená prítomnosťou rôznych druhov chýb v programoch, ktoré sa doň spravidla zavádzajú počas vývoja. Spoľahlivosťou softvéru rozumieme schopnosť vykonávať zadané funkcie pri zachovaní hodnôt stanovených výkonnostných ukazovateľov v priebehu času v rámci stanovených limitov zodpovedajúcich zadaným režimom a podmienkam vykonávania. Chybou sa rozumie každé nesplnenie zadaných funkcií programom. Prejavom chyby je zlyhanie programu.

Indikátory spoľahlivosti softvéru

Najbežnejšie ukazovatele spoľahlivosti softvéru sú nasledujúce:
– počiatočný počet chýb N0 v softvéri po zostavení programu a pred jeho ladením;
je počet softvérových chýb n zistených a zostávajúcich po každej fáze ladenia;
– čas medzi poruchami (MTBF), hodiny;
je pravdepodobnosť bezporuchovej prevádzky (FBR) softvéru pre daný prevádzkový čas P(t);
– poruchovosť softvéru λ, 10-6 1/hod.

Zjednodušené hodnotenie spoľahlivosti softvéru

Najprv zvážte metódy, ktoré nám ponúkame v domácom regulačnom rámci. Jediný normatívny dokument na túto tému je
Hodnotenie spoľahlivosti softvéru v súlade s GOST 28195-99 sa počíta pomocou veľmi zjednodušenej metódy, pričom sa uvádza skutočná spoľahlivosť na základe prevádzkových skúseností softvérového balíka P(t) 1-n/N, kde n je počet porúch počas softvéru testovanie; N je počet experimentov počas testovania. Je zrejmé, že pomocou tejto metódy sa nedá nič vypočítať.

Štatistické hodnotenie spoľahlivosti softvéru

Oveľa zaujímavejší je priemerný štatistický odhad počiatočného počtu N0 chýb v softvéri popísaný v po offline ladení. Podľa tohto odhadu je počet chýb na 1 K slov kódu 4,34 pre jazyky nízkej úrovne (Assembler) a 1,44 pre jazyky vysokej úrovne (C++). Bohužiaľ nie je celkom jasné, čo autori mysleli slovným spojením „1 K slov kódu“. V anglickej literatúre je zvykom používať parameter tisíc riadkov kódu (TCC) (KLOC). Takže podľa operačného systému Windows 2000 je hustota chýb 1,8-2,2 na TSC. Vzhľadom na to, že Windows 2000 je napísaný v programovacom jazyku C a má blízky rozmer počtu chýb, možno s vysokou mierou istoty predpokladať, že ruskí autori mali na mysli práve parameter TSC.
Domáci autori uvádzajú štatistické ukazovatele poruchovosti softvéru λ. Poďme ich priviesť
tabuľka 1.1.

Tabuľka 1.1

Bohužiaľ, pre ktorý softvérový jazyk to platí, autori neuvádzajú. Okrem toho sa zavádzajú korekčné faktory:

Tabuľka 1.2

A koeficient odrážajúci vplyv doby behu programu:

Tabuľka 1.3

Potom sa miera zlyhania softvéru λ určí pomocou tabuliek 1.1-1.3 výrazom:

λ by = λ* Kr* Kk* Kz* Ki (1,1)

Príklad výpočtu 1.
Objem softvéru je napríklad 1 MB.
Potom podľa tabuľky 1.1 λ = 6
Používame priemerné korekčné faktory. Nechať byť:
Kp = 2 (krátke obdobie používania softvéru)
Kk = 0,25 (softvér vysokej kvality)
Kz = 0,25 (vysoká frekvencia zmien softvéru)
Ki \u003d 1 (priemerná úroveň pracovného zaťaženia)
λ by = 0,1 * 10 -6 porúch/hod

P(t) = exp**(-λ*t) (1,2)

Tento štatistický model hodnotenia spoľahlivosti softvéru má oproti zjednodušenému značné výhody, ale má aj množstvo vážnych nedostatkov, najmä nezohľadňuje jazyk vývoja softvéru a má veľké intervaly medzi objemami softvéru. To znamená, že sa napríklad nedá povedať, akú spoľahlivosť bude mať program s objemom 2 gigabajty a ktorý by mal fungovať 10 rokov.
Korekčné faktory sú navyše subjektívne. Z akého stropu sú odobraté, nie je známe.
Pokus o nápravu týchto nedostatkov je Kvantitatívny model hodnotenia spoľahlivosti softvéru.

Kvantitatívny model na hodnotenie spoľahlivosti softvéru

Tento model je založený na mojom predpoklade, že úroveň spoľahlivosti softvéru závisí od množstva softvéru (v bitoch alebo tisíckach riadkov kódu). Toto tvrdenie nie je v rozpore s klasickou teóriou spoľahlivosti, podľa ktorej čím je objekt zložitejší, tým je jeho spoľahlivosť nižšia. Je to logické. Čím viac riadkov kódu je, tým viac chýb bude nakoniec a tým nižšia je pravdepodobnosť bezporuchovej prevádzky programu.
Používame odhad počtu chýb v závislosti od vývojového jazyka zo štatistického modelu:

Tabuľka 1.4

Keď poznáme V, veľkosť softvérového kódu v bitoch, môžeme získať počet riadkov tohto kódu. Výhodnejšie je použiť parameter TSC.

TSK = V/146000 (1,3)

Pomocou údajov v tabuľke 1.4 môžete získať β, pomer počtu chýb na tisíc riadkov kódu:

β \u003d 1,44 * TSC / 1 000 (1,4)

Objem softvéru je 10 MB. vývojový jazyk C++.
Potom podľa 1.3-1.4 bude β 0,08
Tento indikátor je veľmi blízky výsledku z príkladu 1.

Vznikla teda myšlienka porovnať parameter λ, poruchovosť softvéru získanú štatistickým modelom a β, chybovosť softvéru.

Teraz pozornosť! Ako vidíte, existuje silná korelácia výsledkov medzi mierou zlyhania softvéru, berúc do úvahy korekčné faktory, a β, koeficientom počtu softvérových chýb. Použitie iných korekčných faktorov vedie k podobným výsledkom.

Dá sa predpokladať, že nami zavedený (mnou vynájdený) fyzikálny význam β je blízky λ, poruchovosti. λ charakterizuje poruchovosť. β charakterizuje frekvenciu chýb v programe, a teda aj zlyhania. Ale!λ a β sú rôzne. λ, raz určené pre tranzistor, sa nemení s počtom tranzistorov. β je dynamický koeficient. Čím väčší je objem programu, tým väčšie je β. Ale toto je logické. Čím väčší je program, tým viac chýb obsahuje. Navyše sa dá predpokladať, že autori tabuľky 1.1 ju napísali pre softvér v jazyku C.

Je zrejmé, že čím dlhšie program beží, tým je pravdepodobnejšie, že zlyhá.
Pomocou modelu exponenciálnej spoľahlivosti (pri použití tohto modelu sa miera zlyhania považuje za konštantnú) môžete získať softvér WBF:

P(t) = exp**(-λ*t)

Aby sme to zhrnuli, na posúdenie spoľahlivosti softvéru je potrebné poznať jeho vývojový jazyk (vysoký alebo nízky) a množstvo softvérového kódu.

Spoľahlivosť leteckých prístrojov a meracích a výpočtových systémov, V.Yu. Černov / V.G. Nikitin; Ivanov Yu.P. - M. 2004.
Spoľahlivosť a efektívnosť v strojárstve: Príručka., V.S. Avduevskij. 1988.
Odhad zdrojových riadkov kódu z objektového kódu, L. Hatton. 2005.

Teraz skúste niečo spočítať. Nájdite napríklad spoľahlivosť softvéru, ktorý má veľkosť 100 MB a potrebuje bežať 100 hodín. Dôležité! Upozorňujeme, že pri zmene objemu softvéru sa λ vždy prepočítava pre konkrétnu veľkosť softvéru.

V skladbe moderných technických systémov má čoraz väčší podiel výpočtová technika. Náklady na hlavnú bunku integrovaných obvodov – logické hradlo – s rozvojom elektroniky neustále klesajú. Naopak, softvér, ktorého jednotkové náklady boli pri prvých počítačoch veľmi malé, dnes tvorí viac ako 90 % nákladov na počítače. Toto zvýšenie nákladov je spôsobené niekoľkými dôvodmi:

1) Technológia tvorby softvéru vážne zaostáva za technológiou výroby základne prvkov;

2) softvér je svojou povahou komplikovanejší ako hardvér (objem programov pre moderné systémy sa odhaduje na 10 6 - 10 8 alebo viac príkazov alebo informačných slov);

3) požiadavky na softvér počas jeho životného cyklu, ktorý sa zvýšil na 15-20 rokov, sa výrazne menia;

4) na rozdiel od komplexu hardvéru pre softvér (softvér) je veľmi ťažké vypočítať dosiahnuteľnú rýchlosť v štádiu návrhu, navyše sa na zariadení priebežne vykonávajú zmeny.

Z toho vyplýva, že v procese tvorby a prevádzky softvéru sa neustále mení a samotné programy sú náchylné na chyby. V najvšeobecnejšej forme sa chybou rozumie každé nesplnenie funkcií programu, ktoré sú špecifikované v zadávacích podmienkach. Prejavom chyby je porucha a spoľahlivosť výpočtovej techniky pozostáva z dvoch zložiek: spoľahlivosti hardvéru a spoľahlivosti softvéru.

Orientačne sa dá predpokladať, že pomer počtu chýb v programe k celkovému počtu inštrukcií v ňom leží v rozmedzí od 0,25 do 10 na 1000 inštrukcií. To znamená, že v softvéri s objemom 0,5 milióna inštrukcií môže byť 125 - 5000 chýb; tento odhad je navyše optimistický. Identifikácia chýb a ich náprava je viacstupňový proces (v súlade s fázami „životnosti“ softvéru), časovo náročný a nákladný. Keď prejdete do neskorších fáz vývoja softvéru, náklady na chybu rastú, trend tohto nárastu ilustruje tabuľka:

Tabuľka 2.1 – Približná „cena“ softvérovej chyby v rôznych fázach životnosti softvéru

Náklady na chybu, ktorú nebolo možné v týchto fázach nájsť, môžu byť úplne nepredvídateľné a obrovské. Dôkazom toho sú nehody, ku ktorým dochádza pri kozmických lodiach, z ktorých mnohé sa stratili v dôsledku chýb v softvéri.

2.3.1 Základné definície teórie spoľahlivosti softvéru

Hlavné pojmy, ktoré sa používajú v teórii spoľahlivosti softvéru, sú tieto: softvérová chyba; počet zostávajúcich chýb v programe, ktoré sa prenesú na používateľa; intenzita detekcie chýb (riziková funkcia); "beh" programu; zlyhanie programu; pravdepodobnosť zlyhania softvéru.

Hlavným problémom pri definovaní pojmu „chyba softvéru“ je, že chyba v programe je v podstate funkciou samotného programu a toho, čo od neho používateľ očakáva. Uvádzame hlavné prejavy, ktoré možno identifikovať ako chybu:

Výskyt chybného operandu alebo operácie počas programovania;

Nesúlad funkcií vykonávaných Softvérom s požiadavkami špecifikácií alebo chyba v špecifikácii, ktorá vedie k chybe pri vykonávaní prevádzky Softvéru;

Výpočtové chyby (napríklad pretečenie);

Oprava softvéru, ktorá zlepšuje používateľskú skúsenosť.

Softvérové ​​chyby nezahŕňajú opravy, ktoré vytvárajú alebo zničia dočasné softvérové ​​"papiere" pre chýbajúci alebo nesprávny program, ako aj opätovný preklad programu spôsobený nahromadenými opravami. Počet chýb zostávajúcich v softvéri alebo prenesených je potenciálny počet chýb v softvéri, ktoré sa v ňom nachádzajú v nasledujúcich fázach jeho životného cyklu po opravách vykonaných v tejto fáze. Tento počet chýb bude označený symbolom AT.

Predstavme si intenzitu detekcie chýb alebo rizikovú funkciu r(t), ktorý je určený pomerom počtu zistených chýb k časovému obdobiu, za ktoré boli tieto chyby zistené. Pre intenzitu detekcie chýb platia všetky vzorce, ktoré sú známe z teórie spoľahlivosti. Na rozdiel od chybovosti sa riziková funkcia znižuje, keď sú chyby objavené a opravené. Ak predpokladáme, že medzi okamihom detekcie a opravou chýb zostáva konštantná, pričom v okamihu zistenia chýb prudko klesá o konštantnú hodnotu, potom je pre zjednodušenie rozumné predpokladať, že je úmerná počtu zostávajúcich chýb.

, (2.80)

kde je počet zistených chýb v tejto fáze.

Diferenciačná rovnica (2.80) vzhľadom na čas dostaneme

kde je riziková funkcia. Ak riešime diferenciálnu rovnicu s počiatočnými podmienkami

(2.81)

Označiť Potom možno rovnicu (2.81) prepísať ako

Nastavme funkciu rizika diskrétne, pričom časovému intervalu dáme danú hodnotu (deň, týždeň, mesiac). Ak vezmeme logaritmus rovnice (2.82) pre zvolené hodnoty času, získame systém rovníc v tvare

(2.83)

Výpočet exponenciálnej regresie poskytuje pre jej koeficienty nasledujúce výrazy

(2.84)

(2.85)

Program na výpočet exponenciálnej regresie je uvedený nižšie v 2.3.3.

Nasledovnú funkciu času budeme chápať ako špecifickú intenzitu detekcie chýb v softvéri:

(2.87)

kde je počet chýb v softvéri, ktoré boli opravené časom t; je počet inštrukcií v programe. Približne sa dá predpokladať, že

tu - dĺžka príkazového slova; - objem programu Halsted, čo sa stane; AT- počet zostávajúcich chýb v softvéri podľa času t = 0; Komu- koeficient proporcionality. množstvá AT a Komu sú neznáme.

Zvážte dve obdobia ladenia programu T 1 a T 2 také že T 1 < T 2. Nechať byť n 1 a n 2 respektíve počet softvérových chýb zistených v každom z období. Potom pre priemerný čas bezchybnej (bezpečnej) prevádzky v každom z období možno zapísať nasledujúce výrazy:

(2.89)

(2.90)

Vydelením prvej rovnosti druhou po transformáciách získate:

(2.91)

Nahradením výslednej hodnoty B do vzorca pre priemernú dobu prevádzkyschopnosti v prvom období ladenia programu vieme určiť koeficient proporcionality

. (2.92)

Po definovaní AT a Komu je možné vypočítať hodnotu špecifickej intenzity detekcie chýb v softvéri a pravdepodobnosť bezporuchovej prevádzky v ľubovoľnom časovom okamihu za predpokladu, že doba prevádzkyschopnosti podlieha zákonu exponenciálneho rozdelenia.

Spustenie programu je súbor akcií, ktoré zahŕňajú:

Zadanie možnej kombinácie E i vstupné Data;

Vykonanie výpočtu podľa programu, ktorý končí prijatím výsledku F(Ei) alebo odmietnutie.

Pre určitý súbor vstupných údajov odchýlka výsledku od danej hodnoty F`(Ei), získaný ako výsledok vykonávania programu je v prijateľných medziach

(2.93)

a pre všetky ostatné Ei, ktoré tvoria podmnožinu, vykonávanie programu neposkytuje prijateľný výsledok, t.j.

> (2.94)

Udalosti opísané nerovnosťou (2.94) sa nazývajú zlyhania programu.

Metóda štatistického odhadu pravdepodobnosti zlyhania softvéru pre n samostatné behy programov sú tradičné a formálne zahŕňajú hodnotenie

(2.95)

kde ak je splnená nerovnosť (2,93); ak platí nerovnosť (2,94).

Označme prípustnú relatívnu chybu odhadu pravdepodobnosti zlyhania. Potom požadovaný počet nezávislých spustení programu n by mala byť úmerná hodnote, kde je špecifikovaná hodnota pravdepodobnosti poruchy. Takže pre a musí byť počet nezávislých spustení aspoň

Takýto počet cyklov je v praxi ťažko realizovateľný a zvyčajne sa uchyľujú k iným metódam odhadu pravdepodobnosti zlyhania softvéru. Pri znalosti pravdepodobnosti zlyhania nie je ťažké vypočítať pravdepodobnosť bezporuchovej prevádzky softvéru.

Na testovanie spoľahlivosti softvéru sa využívajú metódy testovania štatistických hypotéz a najmä sekvenčná Waldova analýza. Porovnajme dichotomickú premennú s hodnotou 1 , ak (2,94) je pravdivé a 0, ak (2,93) je pravdivé. Potom výsledok behov tvorí vzorku náhodných premenných Označme pravdepodobnosť, že , t.j. program zlyhá ako R; a pravdepodobnosť P 0 toho. ktorá má hodnotu 0 a program je v poriadku. Potom výber hodnoty

P 0 = 0,99 znamená, že v sérii 100 cyklov sa v priemere pravdepodobne vyskytne jedna porucha.

Použitie sekvenčnej analýzy umožňuje výrazne obmedziť počet testov spoľahlivosti softvéru a nekladie prísne požiadavky na zákon distribúcie náhodnej premennej. Praktická aplikácia sekvenčnej analýzy bude demonštrovaná nižšie.

Takzvané Halstedove metriky majú veľký význam pre získanie približných odhadov indikátorov spoľahlivosti softvéru. Rovnaké metriky umožňujú numericky vyhodnotiť ďalšie charakteristiky softvéru: dĺžku programu, jeho objem, úroveň programu, jeho intelektuálny obsah, trvanie vývoja atď. Metriky prešli vážnym praktickým testovaním a preukázali presnosť prijateľnú pre praktické výpočty. Zvážte podstatu Halstedovej metódy.

Pre každý program môžete definovať:

Počet rôznych operácií, napr. atď.;

Celkový počet všetkých operandov (premenných a konštánt);

Celkový počet všetkých operácií

Celkový počet všetkých operandov

Potom je slovník programu , a dĺžka implementácie je Dĺžka programu je v tomto prípade rovná

a hlasitosť programu (2,97)

potenciálny rozsah programu

kde je minimálny počet rôznych operandov (presnejšie počet nezávislých vstupných a výstupných hodnôt).

Potenciálny objem - minimálny možný objem určitého algoritmu. Úroveň programu L sa určuje pomerom potenciálneho objemu k objemu programu

Programátorské práce E sa odhaduje ako celkový počet základných mentálnych rozdielov medzi prvkami potrebnými na vytvorenie programu:

Jazyková úroveň umožňuje zhodnotiť výhodnosť jazyka vyššej úrovne v porovnaní s jeho predchodcom a je určená výrazom

čo nám umožňuje odlišne vyjadrovať vlastnosti E a V:

Tabuľka 2.2 zobrazuje číselné hodnoty pre jazyky rôznych úrovní.

Tabuľka 2.2 - Číselné hodnoty jazykovej úrovne

Zložitosť vývoja softvéru je určená vzorcom

ľudí - hodiny; (2,104)

kde je parameter Stroud, t.j. čas, ktorý potrebuje ľudský mozog na určenie významného rozdielu medzi dvoma prvkami, sa odhaduje na 5 až 20 významných rozdielov za sekundu.

Bolo zaznamenané, že pri vývoji zložitých programov sa výrazne zvyšuje zložitosť ich vytvárania a počet chýb zistených počas ladenia. Počet prenášaných chýb je úmerný veľkosti programu.

Faktor proporcionality S určené na základe nasledujúcich úvah. V súlade s empirickým zákonom D. Millera "7 2" pre určíme, že a pre anglický jazyk, berúc do úvahy (2.100), dostaneme

čo nám umožňuje odhadnúť koeficient S ako

pri jazykoch nižšej úrovne je však správnejšie hodnotiť S, s použitím všeobecnejšieho výrazu

čo najmä pre zostavovateľa dáva hodnotu teda

(2.108)

alebo všeobecnejšie

Hodnoty a možno určiť z výsledkov softvérovej analýzy alebo nepriamo riešením Halstedových rovníc, ak sú známe hodnoty a:

(2.110)

2.3.2 Metodika odhadu počtu zostávajúcich chýb v programe

Posúdenie potenciálneho počtu chýb v softvéri pred začatím vývoja programu možno vykonať výpočtom počtu nezávislých vstupných a výstupných hodnôt, potenciálnej veľkosti programu a možného počtu chýb v ňom. Uveďme príklady analýzy vstupných a výstupných údajov.

Príklad 1 Uvažuje sa o systéme riadenia pristávania lietadiel v podmienkach obmedzenej viditeľnosti. Systém obsahuje lokalizátor, rádiový maják zostupovej dráhy a transpondér rádiového diaľkomeru. Vstupné hodnoty systému sú: tri priestorové súradnice (azimut, nadmorská výška, rozsah), celkový počet súradníc sa rovná Tri informačné referenčné kanály, t.j. - štyri súradnice lietadla (nadmorská výška, pozemná rýchlosť, náklon, sklon).

Celkovo je tam štyridsať vstupov. Pre každý informačný kanál budú štyri výstupné hodnoty (tri priestorové súradnice plus čas), t.j. iba 12 nezávislých veličín.

rozhodnutie.

potenciálny objem programu sa rovná

a počet potenciálnych chýb v softvéri je

Príklad 2 Určite vlastnosti softvéru pre vesmírnu bojovú stanicu (BCS) systému protiraketovej obrany (ABM) typu strategickej obrannej iniciatívy prezidenta USA Reagana. BCS by mal byť navrhnutý tak, aby zachytil asi 1000 cieľov zo vzdialenosti asi 400 km.

rozhodnutie. Na zachytenie je potrebné vypočítať polohu cieľov, ich rýchlosť, vzdialenosť k nim a parametre podmieneného mierenia. Zjednodušte problém a pokúste sa získať spodnú hranicu. Preto sa nebudeme zaoberať úlohami rozpoznávania cieľov a porovnávaním získaných údajov s modelom bojovej situácie. Budeme uvažovať o mimoriadne jednoduchom prípade úplnej decentralizácie, kedy je procesor riadiaceho počítača priamo prepojený so snímačmi BCS a spracováva údaje o súradniciach pozorovaných objektov za účelom výpočtu ich polohy v čase odpočúvania. Domnievame sa, že na jednej obrazovke BCS sa súčasne nezobrazí viac ako 20 cieľov a 30 po sebe idúcich meraní polohy objektu a jeho rýchlosti je štatisticky dostatočných na získanie požadovanej presnosti a výber najlepšieho momentu na zasiahnutie jedného cieľa.

Nechajte zmerať päť veličín na určenie povahy objektu a na obrazovke sa zmerajú dve súradnice pre každý z 20 objektov. Počet vstupných premenných sa teda rovná

Výstupnými hodnotami programu sú uhlové súradnice cieľov a vzdialenosť k nim. Pre 20 cieľov je počet výstupných veličín

takze

čo dáva potenciálnej veľkosti programu hodnotu rovnajúcu sa

Výpočty ukazujú, že na vytvorenie takého objemného softvéru je potrebných asi 10 12 ľudí. - hodiny. Potenciálny počet chýb v tomto obrovskom softvéri pre jazyky rôznych úrovní je:

Oprava takého obrovského množstva chýb môže trvať podstatne dlhšie ako samotná tvorba softvéru. Preto je vývoj softvéru takého veľkého objemu pochybný.

Pred začatím komplexného ladenia vypočítajme potenciálny počet chýb v softvéri. Spresnenie hodnoty počtu chýb je možné vykonať priamym spočítaním hodnôt a . V prípade programov napísaných v nízkoúrovňovom jazyku je to však ťažké. Je možný aj iný prístup, ktorý zvážime pre softvér za podmienok príkladu 1. Charakteristickým znakom tohto softvéru je, že je napísaný v assembleri.

Hodnota je tvorená počtom inštrukcií, použitou inštrukčnou sadou a počtom jednotlivých podprogramov. Vo vzorovom softvéri bolo použitých 45 rôznych príkazov, počet podprogramov bol 157.

Počet operandov sa rovná súčtu (rôzne premenné a dátové polia používané v softvéri); plus počet lokálnych štítkov a konštánt. Na uľahčenie výpočtu sa používa dostupná pamäťová alokácia pamäte s náhodným prístupom (RAM), pri tomto prístupe je vylúčené opakovanie zodpovedajúcich operandov. Počet lokálnych návestí sa počíta podľa textu programu v assembleri naľavo od mnemotechnickej pomôcky inštrukcie. Týmto spôsobom nie je zaručené opakovanie označení a všeobecne akceptovaná tabuľka uľahčuje výpočet. Je zložitejšie spočítať počet rôznych konštánt, ktoré sú formátované do polí číselných údajov a používané pri adresovaní v Assembleri. Preto sa podľa textu programu berie do úvahy len počet konštánt, o ktorých je známe, že sa zmestia do jedného bajtu. Spravidla v texte vyčnievajú a pravdepodobnosť ich zhody je veľmi malá. K hodnote tejto hodnoty sa pripočíta 256 – počet možných bajtových konštánt. Pre uvažovaný softvér majú tieto hodnoty nasledujúci význam:

82 + 334 + 280 + 256 = 952.

Získané hodnoty a možno porovnať s vypočítanými hodnotami, ktoré sú určené z riešenia Halstedových rovníc pre

V dôsledku rozhodnutia Tieto hodnoty možno považovať za prijateľné (rozdiel od skutočného softvéru je 11,0 % a 10,5 %).

Vypočítajte dĺžku programu

a určiť rozsah programu

Spresnený odhad preneseného počtu chýb v softvéri sa rovná:

Odhad sa od predtým získaného = 168 líši len o 12 % a svojim významom sa približuje realite.

2.3.3 Spôsob výpočtu intenzity detekcie chýb v závislosti od času prevádzky programu

V procese komplexného ladenia je softvér upravovaný s cieľom implementovať chýbajúce funkcie a vykonať opravy zistených chýb v už implementovanom programe. Takéto zmeny sa zvyčajne zaznamenávajú do špeciálneho denníka opráv, v ktorom je uvedený dátum a sémantika opravy. Ako príklad uvažujme softvér z príkladu 1. Počiatočné údaje sú výsledkom komplexného ladenia tohto softvéru za obdobie približne dvoch rokov. Počet zistených chýb sa zaznamenával mesačne, intenzita detekcie chýb má teda veľkosť „počet chýb/mesiac“. Miery detekcie chýb za 20 mesiacov sú uvedené v tabuľke nižšie. Tabuľka 2.3 - Hodnoty intenzity detekcie chýb

Δt i
r(ti)
Δt i
r(ti)

Pomocou exponenciálnej aproximácie, ktorá udáva hodnotu počtu zostávajúcich chýb. Táto hodnota dobre súhlasí s predtým určenými hodnotami a .

Exponenciálna aproximácia miery detekcie chýb sa môže použiť na prediktívny výpočet počtu zostávajúcich chýb, ak sa miera detekcie chýb určí s určitým časovým predstihom, napríklad na štvrťrok.

Tabuľka 2.4 - Miera detekcie chýb za štvrťrok dopredu

Δt i
r(ti)

2.3.4 Štatistické hodnotenie pravdepodobnosti bezporuchovej prevádzky

softvér

Uvažujme o metóde sekvenčnej analýzy na odhad pravdepodobnosti bezporuchovej prevádzky programu. Zavádza predpoklad, že ak je pravdepodobnosť úspešného behu R sa nachádza v dostatočne malom okolí bodu P 0, potom je riziko nesprávneho rozhodnutia prípustne malé. Zlé rozhodnutie je rozhodnutie odmietnuť spoľahlivý program alebo preskočiť nespoľahlivý program. Na formalizáciu tohto predpokladu je potrebné stanoviť nasledovné P` a P`` (P`

Že prijatie nespoľahlivého programu sa považuje za chybné rozhodnutie len vtedy, a odmietnutie spoľahlivého programu je chybné rozhodnutie, keď . Po nastavení pravdepodobností P` a P`` tolerovateľné riziko nesprávneho rozhodnutia je také, že pravdepodobnosť chyby prvého druhu, t.j. odmietnutie spoľahlivého programu by nemalo presiahnuť α = Ver , a pravdepodobnosť chyby druhého druhu, t.j. prijatie nespoľahlivého programu by nemalo presiahnuť β = Ver. V tomto prípade sú hodnoty α a β priradené na základe rozumného kompromisu pred začiatkom testovania, pretože s ich poklesom sa objem testov zvyšuje.

Podstata sekvenčnej analýzy hypotéz H 0 (P = P 0) spočíva v testovaní dvoch konkurenčných hypotéz Н`(P = P`) a H``(P = P``). Tu pod pravdepodobnosťou dostupnosti softvéru Popoludnie) pochopiť pravdepodobnosť získania vzorky, v ktorej pre prvky P`

Potom

Ak je hypotéza H` pravdivá, potom

Podobne, ak je pravdivá hypotéza H``, potom

Vytvorme pomer pravdepodobnosti:

(2.114)

Sekvenčná analýza sa vykonáva dovtedy, kým nie sú splnené tieto nerovnosti:

(2.115)

Ak na javisku m potom softvér nie je spoľahlivý; A keď potom môže byť softvér akceptovaný ako spoľahlivý.

Úvod

Popis predmetnej oblasti

1 Schumannov model

Model 2 Mills

3 Model Gelinsky-Moranda

4 Lipovský model

5 Vyhlásenie o probléme

Technológia vývoja aplikácií

1 Algoritmus riešenia

2. Rozloženie aplikácie

2.1 Usporiadanie aplikácie. Schumannov model (tabPage1)

2.2 Usporiadanie aplikácie. Model Gelinsky-Moranda (tabPage3)

2.3 Usporiadanie aplikácie. Mills Model(tabPage5)

2.4 Usporiadanie aplikácie. Lipov model (tabPage4)

3 Popis programu

3.5 Ukladanie výsledkov

Užívateľská príručka

Záver

abstraktné

Program na výpočet spoľahlivosti softvéru

Kľúčové slová:spoľahlivosť, modely, efektívnosť, software, Schumann, mlyny, moranda, limetky.

Cieľ:Návrh a vývoj programu na určenie spoľahlivosti testovaného softvéru rôznymi modelmi pomocou jazyka C# a VisualStudio 2013.

Predmet štúdia:modely spoľahlivosti softvéru

Predmet štúdia:Program v C#

Úvod

Taký faktor ako „spoľahlivosť softvéru“ vždy hral, ​​hrá a bude hrať kľúčovú úlohu pri vývoji akéhokoľvek softvérového produktu.

Čo je to "spoľahlivosť softvéru?" Odpoveď je veľmi jednoduchá - je to vlastnosť systému vykonávať špecifikované funkcie pri zachovaní hodnôt stanovených výkonnostných ukazovateľov v rámci stanovených limitov, ktoré zodpovedajú špecifikovaným režimom a podmienkam vykonávania.

Každý vývojár sa snaží, aby bol jeho program čo najspoľahlivejší, najefektívnejší a bezproblémový. Žiaľ, v súčasnosti nie je možné úplne odstrániť skutočnosť poruchy alebo chyby, hoci sa v tomto smere pracuje každý deň.

Zdá sa však, že je možné vypočítať pravdepodobnosť chýb v programe ako výsledok jeho testovania na rôznych matematických modeloch spoľahlivosti. Ak chcete vedieť, aký spoľahlivý je program, musíte ho otestovať viackrát.

V súlade s cieľom boli sformulované tieto úlohy:

) Vykonajte analýzu predmetu v teréne

) Vytvorte potrebný program

) Vykonajte implementáciu softvéru

) Otestujte aplikáciu

) Určiť efektivitu vypracovaného programu

) Zaznamenajte a analyzujte výsledky

Predmetom výskumu je metóda na výpočet nákladov na vývoj softvéru.

Predmetom štúdia je program na platforme VisualStudio v jazyku C#.

V medzinárodnej norme ISO 9126:1991 je spoľahlivosť vyčlenená ako jedna z hlavných charakteristík kvality softvéru. Softvérový štandardný slovník ako schopnosť systému alebo komponentu vykonávať požadované funkcie za špecifikovaných podmienok počas určeného časového obdobia.

Samotný problém spoľahlivosti softvéru má minimálne dva aspekty: poskytovanie a hodnotenie (meranie) spoľahlivosti. Prvým aspektom sa venuje takmer všetka dostupná literatúra a problematika hodnotenia spoľahlivosti počítačových programov nie je dostatočne rozpracovaná. Zároveň je zrejmé, že spoľahlivosť programu je oveľa dôležitejšia ako jeho tradičné charakteristiky, ako je čas vykonávania alebo požadované množstvo pamäte RAM, ale stále neexistuje všeobecne akceptované kvantitatívne meranie spoľahlivosti programu.

Modely spoľahlivosti softvéru sa delia na analytické a empirické. Analytické modely umožňujú vypočítať kvantitatívne ukazovatele spoľahlivosti na základe údajov o správaní programu počas testovania. Empirické modely sú založené na analýze štrukturálnych vlastností programov.

Analytické modely predstavujú dve skupiny: dynamické a statické. V dynamických modeloch sa správanie softvéru (výskyt porúch) zvažuje v čase. Ak sú intervaly každej poruchy pevné, potom sa získa súvislý obraz o výskyte porúch v priebehu času. Je možné zaznamenať iba počet porúch za ľubovoľný časový interval. V tomto prípade môže byť správanie softvéru reprezentované iba v diskrétnych bodoch.

1. Popis predmetnej oblasti

.1 Schumannov model

Schumanov model je zostavený na základe niekoľkých kritérií:

¾ celkový počet inštrukcií v programe strojového jazyka je konštantný;

¾ na začiatku testov rozloženia sa počet chýb rovná určitej konštantnej hodnote a keď sa chyby opravujú, zmenšujú sa. Počas testovania programu nie sú zavedené žiadne nové chyby;

¾ chyby sú na začiatku rozlíšiteľné, podľa celkového počtu opravených chýb možno posúdiť zostávajúce;

¾ miera zlyhania programu je úmerná počtu zvyškových chýb.

Predpokladá sa, že pred testovaním (t.j t =0) je tam M chýb. Počas testovacieho času τ je nájdený ε1( t ) chyby na inštrukciu v strojovom jazyku.

Potom konkrétny počet chýb na jednu strojovú inštrukciu, ktoré zostávajú v systéme po testovacom čase τ, rovná sa:

kde I je celkový počet strojových inštrukcií, o ktorých sa predpokladá, že sú vo fáze testovania konštantné.

Predpokladá sa, že hodnota funkcie počtu chýb Z(t) je úmerná počtu chýb zostávajúcich v programe po čase strávenom testovaním. τ .

Z (t) = C * ε2 (τ),

kde C je nejaká konštanta, t je čas behu programu bez porúch.

Potom, ak je čas behu programu bez poruchy, t sa počíta od bodu t = 0, a τ zostane pevná, funkcia spoľahlivosti alebo pravdepodobnosť bezporuchovej prevádzky na intervale od 0 do t sa rovná

Potrebujeme nájsť počiatočnú hodnotu chyby M a faktor proporcionality C. Tieto neznáme sa odhadnú preskočením funkčného testu v dvoch bodoch premennej osi ladenia t a t v, zvolený tak, že ε1( t a )<ε1(t d).

Počas testovania sa zbierajú informácie o čase a počte chýb pri každom spustení, t.j. celkový čas testovania τ je súčet času každého behu:

τ = τ1 + τ2 + τ3 + … + τn .

Za predpokladu, že chybovosť je konštantná a rovná sa λ, možno vypočítať ako počet chýb za jednotku času,

Potom

Údaje pre dva rôzne časy testovania t a t c, môžeme porovnať rovnice (3) s ta a tb:

Zo vzťahov (6) a (7) zistíme neznámy parameter C a M:

Príklad 1 .

Program obsahuje 2000 príkazových riadkov, z ktorých pred spustením prevádzky (po dobe ladenia) obsahuje 15 príkazových riadkov chyby. Po 20 dňoch práce sa našla 1 chyba. Nájdite priemerný čas bez chýb programu a poruchovosť programu s faktorom úmernosti rovným 0,7.

I=2000=15=20=1=0,7

E 1(t) = 0,0005 2(t) = 0,007 (t) = 0,906649 St =204,0816

A = 0,0049 - poruchovosť

Príklad 2

Pomocou podmienok príkladu 1 určte pravdepodobnosť bezchybnej prevádzky programu počas 90 dní.

I= 2000= 15= 90= 1= 0,7(t)= 0,643393

Príklad 3 .

Určte počiatočný počet možných chýb v programe obsahujúcom 2 000 príkazových riadkov, ak sa počas prvých 60 dní prevádzky našli 2 chyby a počas nasledujúcich 40 dní sa našla jedna chyba. Definujte T0- priemerný čas bezchybnej prevádzky zodpovedajúci prvej a druhej perióde prevádzky programu a koeficient proporcionality.

I = 2000 1= 60 dní 2= 100 dní 1= 2 chyby 2= 3 chyby 0= 30,333333

λ 1= 0,033333

λ 2= 0,03= 6,6666671(t 1)= 0,0012(t 2)= 0,0015= 12

L 2/L 1= 0,9

Model 1,2 Mills

testovací algoritmus Shuman Mills

Z použitia tohto modelu vyplýva nutnosť umelého „upchatia“ programu pred spustením testovania, t.j. zaviesť do nej množstvo známych chýb. Chyby sa zavádzajú náhodne a zaznamenávajú sa do protokolu umelých chýb. Tester nepozná ani počet, ani povahu zavedených chýb, kým sa indikátory spoľahlivosti nevyhodnotia pomocou Millsovho modelu. Predpokladá sa, že všetky chyby (prirodzené aj umelo zavedené) majú rovnakú pravdepodobnosť, že sa nájdu v procese testovania.

Testovaním programu po určitú dobu sa zhromažďujú štatistiky o chybách. V čase hodnotenia spoľahlivosti podľa protokolu umelých chýb sú všetky chyby rozdelené na vlastné a umelé. Pomer, nazývaný Millsov vzorec,

Umožňuje odhadnúť počiatočný počet chýb v programe N. Tu S je počet umelo zavedených chýb; n je počet nájdených vlastných chýb; V je počet umelých chýb zistených v čase hodnotenia.

1.3 Gelinsky-Moranda model

Hlavným predpokladom, na ktorom je model založený, je, že v procese testovania softvéru má hodnota testovacích časových intervalov medzi detekciou dvoch chýb exponenciálne rozdelenie s mierou zlyhania úmernou počtu ešte nezistených chýb. Každá zistená chyba sa odstráni, počet zostávajúcich chýb sa zníži o jednu.

Funkcia hustoty rozdelenia času detekcie i-tej chyby, počítaná od okamihu zistenia (i - 1)-tej chyby, má tvar

Kde je miera zlyhania, ktorá je úmerná počtu chýb, ktoré ešte neboli v programe zistené:

Kde N je počet chýb pôvodne prítomných v programe; C - koeficient proporcionality.

Najpravdepodobnejšie hodnoty N a C sú určené na základe údajov získaných počas testovania. Ak to chcete urobiť, opravte čas vykonávania programu do ďalšieho zlyhania t1,t2,t3,…,tk. Hodnoty N a C možno získať riešením sústavy rovníc

Ak chcete získať číselné hodnoty λ , musíte namiesto N a C nahradiť ich možné hodnoty N a C. Po vypočítaní hodnôt K podľa vzorca (5) a ich dosadení do výrazu (4) je možné určiť pravdepodobnosť bezporuchovej prevádzky v rôznych časových intervaloch.

1.4 model Lipov

Lipov upravil Millsov model zvážením pravdepodobnosti odhalenia chyby pomocou iného počtu testov. Ak urobíme rovnaký predpoklad ako v Millsovom modeli, t. j. že vnútorné a umelé chyby majú rovnakú pravdepodobnosť, že budú nájdené, potom pravdepodobnosť odhalenia n vnútorných a V zavedených chýb je

Kde m je počet použitých testov, q je pravdepodobnosť zistenia chyby v každom z m testov, vypočítaná podľa vzorca

S je celkový počet umelo zavedených chýb; N - počet vlastných chýb dostupných v softvéri pred testovaním.

.5 Vyhlásenie o probléme

Názov aplikácie: Program na výpočet spoľahlivosti softvéru.

Účel vývoja: Na základe údajov zadaných používateľom vypočítajte hlavné ukazovatele spoľahlivosti softvérového produktu.

Vstupné údaje sa zadávajú do špeciálnych polí. Po spracovaní údajov program zobrazí výsledky v príslušných výstupných poliach.

Aby program správne fungoval, musia byť vyplnené všetky polia. Niektoré modely majú štandardne pevné hodnoty proporcionality.

Na implementáciu tohto programu používame programovací jazyk C# na platforme Visual Studio.

Požiadavky na PC systém:

) Operačný systém Windows 7 alebo vyšší.

) Voľné miesto na pevnom disku: 5 MB alebo viac.

) Net Framework 4.0 alebo vyšší.

) RAM: 128 MB alebo viac.

) Klávesnica a myš.

2. Technológia vývoja aplikácií

.1 Algoritmus riešenia

Na samom začiatku vykonávania programu sa zobrazí formulár, kde je používateľ vyzvaný na vyplnenie príslušných polí údajmi potrebnými pre výpočet.

Na začiatku vykonávania programu sa kontroluje úplnosť a správnosť zadaných údajov. Ak údaje používateľa neboli overené, zobrazí sa príslušné upozornenie.

Po úspešnom absolvovaní kontroly správnosti a úplnosti začne program vykonávať výpočty. Program načíta údaje vyplnené v špeciálnych poliach a vypočíta pomocou vzorcov.

Potom sa výsledky zobrazia v špeciálne určených oknách a vykonávanie programu sa ukončí.

.2.1 Usporiadanie aplikácie. Schumannov model (tabPage1)

menuStrip1 - zobrazí zoznam menu obsahujúci položky "Uložiť výsledky" a "Ukončiť"

tabPage1 - karta prvku tabControl1 s nasledujúcimi prvkami: label49 - 54, label63 - 67, label 61, label59, label48, label62, label58, textBox14 - 19, groupBox4

label52 - akceptuje textovú hodnotu "Príkazové riadky v programe"

label51 - má textovú hodnotu "Riadky obsahujúce chybu"

label50 - akceptuje textovú hodnotu "Dni práce"

label49 - akceptuje textovú hodnotu "Chyby pri behu"

label58 - má textovú hodnotu "počiatočné údaje"

label54 - akceptuje textovú hodnotu "Konečný výsledok"

label61 - má skrátenú hodnotu "KSP"

label60 - má skrátenú hodnotu "CCO"

label59 - akceptuje skrátenú hodnotu "DR"

label48 - má skrátenú hodnotu "OVR"

label62 - má skrátenú hodnotu "KP"

textBox17 - získa hodnotu zadaných údajov používateľa v stĺpci "Príkazové riadky v programe"

textBox15 - získa hodnotu zadaných údajov používateľa v stĺpci "Riadky obsahujúce chyby"

textBox16 - získa hodnotu zadaných údajov používateľa v stĺpci "Dni práce"

textBox14 - získa hodnotu zadaných údajov používateľa v stĺpci "Chyby počas práce"

textBox18 - získa hodnotu zadaných údajov používateľa v stĺpci "Koeficient proporcionality", predvolená hodnota je "1".

textBox19 - slúži na zobrazenie výsledkov výpočtov vykonaných pomocou Schumannovho vzorca.

button5 - akceptuje textovú hodnotu "Vymazať" a tiež vymaže všetky polia v tomto bloku

2.2.2 Usporiadanie aplikácie. Model Gelinsky-Moranda (tabPage3)

tabPage3 - obsahuje všetky skupiny objektov ako label41-42, label45-46, label73-69, label19-14, textBox4, button3, textBox13-10, groupBox3.

label41 - akceptuje textovú hodnotu "Počet chýb pôvodne v programe.

label42 - má textovú hodnotu "faktor proporcionality"

label45 - má textovú hodnotu "Počet chýb po určitom čase"

label46 - má textovú hodnotu "čas detekcie chyby i"

label73 - má textovú hodnotu "Výsledok"

label69 - má textovú hodnotu "Počiatočné údaje"

label72 - má skrátenú hodnotu "CHOPNVP"

label71 - má skrátenú hodnotu "KP"

label70 - má skrátenú hodnotu "KOSV"

label15 - má skrátenú hodnotu "BOO"

label14 - akceptuje textovú hodnotu "Konečný výsledok"

Prvky label19 - label16 akceptujú rovnaké počiatočné textové hodnoty „null“.

textBox10 - získa hodnotu zadaných údajov používateľa v stĺpci "Počet chýb pôvodne v programe"

textBox12 - získa hodnotu zadaných údajov používateľa v stĺpci "Koeficient proporcionality"

textBox11 - získa hodnotu zadaných údajov používateľa v stĺpci "Počet chýb po čase".

textBox13 - získa hodnotu zadaných údajov používateľa v stĺpci "Čas detekcie chyby"

textBox4 - slúži na zobrazenie výsledkov výpočtov vykonaných pomocou vzorca Dzhelinsky-Moranda.

button3 - akceptuje textovú hodnotu "Vymazať" a tiež vymaže všetky polia v tomto bloku

2.2.3 Usporiadanie aplikácie. Mills Model(tabPage5)

tabPage5 - obsahuje skupiny objektov, label9-1, textBox3-1, groupBox1, button1, label13, label44.

label2 - akceptuje textovú hodnotu "Počet umelo zavedených chýb"

label3 - má textovú hodnotu "Počet nájdených vlastných chýb"

label4 - má textovú hodnotu "Počet umelých chýb zistených v čase hodnotenia"

label5 - má textovú hodnotu "Výsledok"

label9 - má textovú hodnotu "Počiatočné údaje"

label13 - akceptuje textovú hodnotu "Konečný výsledok"

label6 - má skrátenú hodnotu "KIVO"

label7 - má skrátenú hodnotu "CHONO"

label8 - má skrátenú hodnotu "CHOKMOIO"

label10 - najprv dostane prázdnu hodnotu a potom dostane hodnoty stĺpca "Počet umelo zavedených chýb"

label11 - najprv dostane prázdnu hodnotu a potom dostane hodnoty stĺpca "Počet nájdených vlastných chýb"

label12 - najprv dostane prázdnu hodnotu a potom dostane hodnoty stĺpca "Počet umelých chýb zistených v čase hodnotenia"

label44 - Získa a vytlačí výsledok výpočtu Millsovho vzorca

button1 - akceptuje textovú hodnotu "Vymazať" a tiež vymaže všetky polia v tomto bloku.

textBox1 - -získa hodnotu zadaných údajov používateľa v stĺpci "Počet umelo zavedených chýb"

textBox2 - získa hodnotu zadaných údajov používateľa v stĺpci "Počet nájdených vlastných chýb"

textBox3 - získa hodnotu zadaných údajov používateľa v stĺpci "Počet umelých chýb zistených do času vyhodnotenia"

2.2.4 Usporiadanie aplikácie. Lipov model (tabPage4)

tabPage4 - obsahuje skupiny objektov, label78-74, label84-97, label82, groupBox5, button4.

label74 - má textovú hodnotu "Počet použitých testov"

label76 - akceptuje textovú hodnotu "Celkový počet umelo zavedených chýb

label77 - preberá textovú hodnotu "Počet vlastných chýb, pred testovaním

label78 - má textovú hodnotu "Počet chýb zavedených koncom testovania

label86 - má textovú hodnotu "Výsledok"

label82 - má textovú hodnotu "Počiatočné údaje"

label90 - akceptuje textovú hodnotu "Konečný výsledok"

label91 - má textovú hodnotu "Pravdepodobnosť zistenia chyby pri použití iného počtu m testov"

label92 - prijíma a zobrazuje výsledok výpočtov pomocou Lipovského vzorca, počiatočná hodnota je "null"

label85 - má skrátenú hodnotu "KIT"

label84 - má skrátenú hodnotu "OKIWO"

label87 - má skrátenú hodnotu "XODNT"

label88 - má skrátenú hodnotu "QUOT"

label89 - akceptuje skrátenú hodnotu "KSOKT"

textBox20 - získa hodnotu zadaných údajov používateľa v stĺpci "Počet použitých testov"

textBox22 - získa hodnotu zadaných údajov používateľa v stĺpci "Celkový počet zavedených umelých chýb"

textBox23 - získa hodnotu zadaných údajov používateľa v stĺpci "Počet vlastných chýb pred testovaním".

textBox24 - získa hodnotu zadaných údajov používateľa v stĺpci "Počet chýb spôsobených koncom testovania"

textBox21 - získa hodnotu zadaných údajov používateľa v stĺpci "Počet vlastných chýb do konca testovania"

button4 - akceptuje textovú hodnotu "Vymazať" a tiež vymaže všetky polia v tomto bloku.

2.3 Popis programu

.3.1 kartaStrana1

triedna hierarchia

pomocou System.Collections.Generic;System.ComponentModel;System.Data;System.Drawing;System.Linq;System.Text;System.Windows.Forms;System.IO;

Použité prvky:;;;;;;

Event Handlersvoid button5_Click(objectsender, EventArgs e)

Táto karta má jednu funkciu

Funkcia Suman počíta podľa Schumannovho vzorca a výsledok odovzdá príslušnému výstupnému objektu, ako je znázornené na obrázku 1.1

((textBox20.Text == "")

)(textBox22.Text == "")

)(textBox23.Text == "")

)(textBox21.Text == "")

)(textBox24.Text == "")

MessageBox.Show("Zadajte číselnú hodnotu!");

MessageBox.Show("Zadajte číselnú hodnotu!");

MessageBox.Show("Zadajte číselnú hodnotu!");

MessageBox.Show("Zadajte číselnú hodnotu!");

Výsledok práce môžete vidieť na obrázku 1.2

Obrázok 1.2 Schumannov výpočet

2.3.2 tabPage3

Hierarchia triedSystem;System.Collections.Generic;System.ComponentModel;System.Data;System.Drawing;System.Linq;System.Text;System.Windows.Forms;

pomocou System.IO;

Použité prvky:

Event Handlersvoid button3_Click(objectsender, EventArgs e)

Táto karta má tiež jednu funkciu

Funkcia Moranda vypočíta podľa Gelinského-Morandovho vzorca a zobrazí výsledok

public void Moranda(EventArgs e_Moranda)

((textBox11.Text == "")

(.Show("Po čase zadajte počet chýb!", "Jelinsky-Moranda Model");

)(textBox13.Text == "")

(.Show("Zadajte čas detekcie i-chyby!", "Jelinsky-Moranda Model");

)(textBox12.Text == "")

(.Show("Zadajte faktor proporcionality!", "Jelinsky-Moranda model");

)(textBox10.Text == "")

(.Show("Zadajte počet chýb pôvodne v programe!", "Jelinsky-Moranda Model");

)t10;(!int.TryParse(textBox10.Text, out t10))

MessageBox.Show("Zadajte číselnú hodnotu!");

int t12;(!int.TryParse(textBox12.Text, out t12))

MessageBox.Show("Zadajte číselnú hodnotu!");

int t13;(!int.TryParse(textBox13.Text, out t13))

MessageBox.Show("Zadajte číselnú hodnotu!");

int t11;(!int.TryParse(textBox11.Text, out t11))

MessageBox.Show("Zadajte číselnú hodnotu!");

(.Show("Chyba:" + ex.Správa);

)lambda, C, N, i, P,t;= Double.Parse(textBox10.Text);= Double.Parse(textBox12.Text);= Double.Parse(textBox11.Text);= Double.Parse(textBox13. Text);= C * (N - i + 1);= lambda * Math.Exp(lambda * (-1) * t);

textBox4.Text = "Funkcia hustoty času detekcie i-tej chyby, počítaná od okamihu detekcie:" + P. ToString();

label16.Text = N.ToString();.Text = C.ToString();.Text = i.ToString();.Text = t.ToString();

Výsledok práce je viditeľný na obrázku 1.3

Obrázok 1.3 Výsledok vykonania výpočtov podľa Gelinského-Morandovho modelu

2.3.3 tabPage5

Použité prvky:;;;;;;

Event Handlersvoid button1_Click(objectsender, EventArgs e)

Táto karta má jednu funkciu

Funkcia Frézovanie vypočíta vzorec Frézovania a vypíše výsledok

public void Mills(EventArgs e_Mills)

((textBox1.Text == "")

(.Show("Zadajte počet umelo zavedených chýb!", "Model Mills");

)(textBox2.Text == "")

(.Show("Zadajte počet vlastných nájdených chýb!", "Model Mills");

)(textBox13.Text == "")

(.Show("Zadajte počet umelých chýb zistených v čase odhadu!", "Millsov model");

)t1;(!int.TryParse(textBox1.Text, out t1))

MessageBox.Show("Zadajte číselnú hodnotu!");

int t2;(!int.TryParse(textBox2.Text, out t2))

MessageBox.Show("Zadajte číselnú hodnotu!");

int t3;(!int.TryParse(textBox3.Text, out t3))

MessageBox.Show("Zadajte číselnú hodnotu!");

(.Show("Chyba:" + ex.Správa);

)S, n, V, N;= Double.Parse(textBox1.Text);= Double.Parse(textBox2.Text);= Double.Parse(textBox3.Text);

N = (S * n) / V;.Text = "Počiatočný počet chýb v programe je:" + N. ToString();

label10.Text = S.ToString();.Text = n.ToString();

label12.Text = V.ToString();

Výsledok vykonania výpočtov podľa Millsovho vzorca je jasne viditeľný na obrázku 1.4

2.3.4 kartaStrana4

Hierarchia triedSystem;System.Collections.Generic;System.ComponentModel;System.Data;System.Drawing;System.Linq;System.Text;System.Windows.Forms;System.IO;

Použité prvky:;;;;;;

Event Handlersvoid button4_Click(odosielateľ objektu, EventArgs e)

Táto karta má jednu funkciu

Funkcia Lipov vykoná výpočet Lipovovho vzorca a vypíše výsledok

public void Lipov(EventArgs e_Lipov)

((textBox20.Text == "")

(.Show("Zadajte počet testov, ktoré sa majú použiť!", "Lipov Model");

)(textBox22.Text == "")

(.Show("Zadajte celkový počet umelo zavedených chýb!", "Lipov model");

)(textBox23.Text == "")

(.Show("Pred testovaním zadajte počet vlastných chýb!", "Lipov Model");

(.Show("Zadajte počet vlastných chýb do konca testovania!", "Lipov Model");

)(textBox24.Text == "")

(.Show("Zadajte počet zavedených chýb do konca testovania!", "Lipov Model");

// Kontrola zadaných hodnôt ​​t20;

if (!int.TryParse(textBox20.Text, out t20))

MessageBox.Show("Zadajte číselnú hodnotu!");

int t21;(!int.TryParse(textBox21.Text, out t21))

MessageBox.Show("Zadajte číselnú hodnotu!");

int t22;(!int.TryParse(textBox22.Text, out t22))

MessageBox.Show("Zadajte číselnú hodnotu!");

int t24;(!int.TryParse(textBox24.Text, out t24))

MessageBox.Show("Zadajte číselnú hodnotu!");

int t23;(!int.TryParse(textBox23.Text, out t23))

MessageBox.Show("Zadajte číselnú hodnotu!");

(.Show("Chyba:" + ex.Správa);

)m, q, S, N, n, V;= Double.Parse(textBox20.Text);= Double.Parse(textBox22.Text);= Double.Parse(textBox23.Text);= Double.Parse(textBox21. Text);= Double.Parse(textBox24.Text);= (n + V) / n;Q = (m / (n + V)) * Math.Pow(n + V, q) * Math.Pow(m - n - V, 1 - q) * ((N / n) * (S / V) / ((N + S) / (n + V)));.Text = Q.ToString();.Text = m.ToString();.Text = S.ToString();.Text = N.ToString();.Text = V.ToString();.Text = n.ToString();

(.Show("Zadávajú sa hodnoty, pre ktoré je výsledok záporný!", "Lipov model");

2.3.5 Ukladanie výsledkov

Na uloženie výsledkov sa používa obslužný program udalosti ToolStripMenu.

Po vykonaní výpočtov podľa vyššie navrhnutých modelov môže používateľ uložiť svoje výsledky.

Obrázok 1.6 Uložiť výber cesty

A po potvrdení uloženia oznámenie o úspešnej operácii:

Obrázok 1.7. Upozornenie na úspešné uloženie.

3. Používateľská príručka

Pre správnu činnosť programu je potrebné vyplniť všetky modely navrhnuté v programe.

Niektoré parametre sú statické a ich zmena môže viesť k nesprávnej činnosti programu.

Pri ukladaní program automaticky priradí názov súboru vo formáte „Výsledky #“ + náhodné číslo od 0 do 9999. Môžete tiež zadať vlastný názov uloženia.

Ak zadáte nesprávne parametre pre výpočet, môžete získať negatívne výsledky.

Ak chcete vypočítať a získať výsledky, kliknite na tlačidlo "Vypočítať".

Záver

Programovací jazyk C# založený na Visual Studio je schopný implementovať všetky potrebné nástroje na výpočet spoľahlivosti programov.

Počas realizácie úlohy sa zlepšili zručnosti programovania, práce s matematickými vzorcami. Vyvinutý program názorne demonštruje implementáciu 4 modelov na určenie spoľahlivosti softvéru. Hlavnou výhodou programu je výroba výpočtov na 4 modeloch súčasne.