Introducere
Această lucrare este dedicată descrierii metodelor de detectare și eliminare a erorilor, care pot îmbunătăți semnificativ calitatea software-ului în sistemele încorporate și pot economisi resursele materiale și de timp cheltuite cu sistemele de depanare. Metodele luate în considerare pot fi utilizate fără prea multe dificultăți în dezvoltarea unei game largi de proiecte software pentru sisteme încorporate, iar experiența acumulată își păstrează pe deplin valoarea în implementarea altor proiecte și tehnologii țintă. În plus, fac posibilă garantarea simplității menținerii, modificării și transferului programelor create pe noi tipuri de dispozitive. Pe scurt, aceste tehnici nu numai că oferă o oportunitate de a îmbunătăți aplicațiile încorporate existente și procesele de dezvoltare, dar vă asigură și că, odată cu proliferarea de noi dispozitive încorporate, aveți deja experiența necesară pentru a dezvolta aplicații performante pentru aceste tehnologii, la timp și in buget.
Nu este un secret pentru nimeni că depanarea programelor încorporate este extrem de dificilă. Depanarea în sine este departe de a fi o stațiune, iar software-ul pentru sistemele încorporate de depanare presupune cerințe speciale în acest sens. În primul rând, este foarte dificil să extragi informațiile necesare din sistemele încorporate. Procesul de depanare se bazează de obicei pe rezultatul aplicației și pe feedback-ul corespunzător de la programator, iar programele sistemelor încorporate nu au capacitatea de a imprima imagini de ecran pe care dezvoltatorii de alte tipuri de software le pot utiliza.
Cumva trebuie să ieși din această situație neplăcută. O soluție posibilă este conectarea hardware-ului special la un modul, care este un set de hardware pentru care este scris software-ul depanat. Acest hardware special oferă dezvoltatorului posibilitatea de a vedea ce se întâmplă cu software-ul lor. De exemplu, așa-numitele monitoare de memorie vă permit să introduceți informații în zone separate de memorie, să citiți conținutul memoriei pe monitor și să utilizați conținutul memoriei monitorului pentru a analiza starea sistemului în momentul prăbușirii acestuia. . În plus, sistemele încorporate pot fi depanate folosind sisteme de simulare, care sunt medii software în care programele care sunt depanate sunt executate în același mod în care ar fi executate pe sistemul țintă.
Sistemele de simulare au multe avantaje. Acestea includ de obicei dispozitive de depanare și imprimări, dar sistemele de simulare sunt doar imitatoare. Un program depanat poate rula cu succes într-un sistem de simulare și poate fi complet inoperabil în condiții reale. Deci sistemele de simulare sunt doar o soluție parțială. Erorile software pot trece cu ușurință de sistemul de simulare și reapar în hardware real.
Aici se află problema principală: așa cum se arată în fig. 1, repararea erorilor care nu sunt detectate în etapa de testare, dar în timpul utilizării, este mult mai costisitoare. Dacă se găsește o eroare într-un program pentru sisteme neîncorporate, atunci poate fi lansată o versiune actualizată a programului cu remedieri, costul unor astfel de actualizări este de obicei relativ scăzut. Dacă se găsește o eroare într-un sistem încorporat, atunci pentru a o remedia, este necesar să reveniți și să modificați dispozitivele în sine cu acest sistem. Costul unei astfel de returnări poate atinge valori astronomice și poate determina companiile să intre în faliment.

Orez. 1. Costul remedierii erorilor în sistemele încorporate

După părerea mea, timpul și costul identificării și remedierii erorilor pentru sistemele încorporate se dublează aproximativ (din cauza dificultăților descrise mai sus). În lumina acestor costuri de neconceput, orice metodă care va preveni inițial apariția erorilor este de neprețuit. Din fericire pentru dezvoltatorii încorporați, unele dintre noile tehnici de dezvoltare software pot fi folosite pentru a preveni erorile. Cele mai recomandate două dintre ele sunt standardele de programare și testarea unitară.
Adevărat, ambele metode nu sunt atât de folosite astăzi, cât sunt glorificate. Aproape toți dezvoltatorii de software sunt de acord cu valoarea lor ridicată, dar puțini le folosesc. Această inconsecvență se datorează în cele mai multe cazuri din două motive. În primul rând, mulți oameni consideră că respectarea standardelor de programare și testarea unitară este o sarcină obositoare. Având în vedere cât de mult timp și efort pot economisi aceste abordări în viitor, dezvoltatorii ar trebui să aibă puțină răbdare și să evite costurile uriașe cu forța de muncă (și posibila abandonare a proiectului) mai târziu.
Dezvoltatorii de sisteme în timp real le este și mai dificil, deoarece trebuie, pe lângă orice altceva, să rezolve probleme legate de respectarea diferitelor dependențe de timp. La sfârșitul articolului, ne vom uita la dificultățile care apar la depanarea sistemelor în timp real și ne vom familiariza cu câteva metode de depanare care sunt concepute pentru a depăși aceste dificultăți și care pot fi utilizate și în dezvoltarea oricărui software.
Modalități de depanare a programelor
Depanarea programelor este de a verifica funcționarea corectă a programului și a hardware-ului. Totuși, un program care nu conține erori de sintaxă poate conține erori logice care împiedică programul să își îndeplinească funcțiile prevăzute. Erorile logice pot fi asociate cu algoritmul programului sau cu o neînțelegere a funcționării echipamentelor conectate la porturile microcontrolerului.
Depanatorul încorporat în mediul de programare integrat vă permite să depanați acele secțiuni ale codului programului care nu depind de funcționarea echipamentelor care nu fac parte din cipul microcontrolerului. Aceasta se referă de obicei la calculul expresiilor matematice sau la conversia formatelor de reprezentare a datelor.
Trei metode sunt de obicei folosite pentru a depana programe: Depanarea pas cu pas a programelor prin introducerea subrutinelor; Depanarea pas cu pas a programelor cu executarea unei subrutine ca o singură instrucțiune; Rulați programul până la punctul de întrerupere.
Depanarea pas cu pas a programelor constă în faptul că se execută o instrucțiune a programului și apoi se controlează acele variabile asupra cărora această instrucțiune ar fi trebuit să acționeze.
Dacă programul are deja subrutine depanate, atunci subrutina poate fi considerată ca o declarație a programului și poate utiliza a doua metodă de depanare a programelor.
Dacă există o secțiune suficient de mare a programului în program care a fost deja depanată mai devreme, atunci acesta poate fi executat fără a controla variabilele pe care le afectează. Utilizarea punctelor de întrerupere vă permite să săriți peste partea deja depanată a programului. Un punct de întrerupere este stabilit în locurile în care este necesar să se verifice conținutul variabilelor sau pur și simplu să se controleze dacă controlul este transferat unui anumit operator.
Aproape toate depanatoarele acceptă această proprietate (precum și execuția programului până la ieșirea cursorului și a subrutinei). Apoi depanarea programului continuă într-un mod pas cu pas cu controlul variabilelor locale și globale, precum și registrele interne ale microcontrolerului și tensiunile la pinii acestui microcircuit. Urmați standardele de programare!

Cel mai bun mod de a îmbunătăți calitatea software-ului este să încercați să nu faceți greșeli în procesul de introducere a codului sursă.
Primul pas în prevenirea greșelilor este conștientizarea că greșelile pot fi într-adevăr prevenite. Cel mai mare obstacol în calea controlului erorilor este credința comună că erorile sunt inevitabile. Este o iluzie! Erorile nu apar de la sine, ci sunt introduse în text de către dezvoltator. A greși este uman, așa că chiar și cei mai buni programatori greșesc din când în când dacă au ocazia. Prin urmare, pentru a reduce numărul de erori, este necesar să se reducă posibilitatea apariției acestora. Una dintre cele mai bune moduri aici este să urmați standardele de programare, care elimină terenul fertil pentru erori în stadiile incipiente.
Standardele de programare sunt „reguli” specifice limbajului care, dacă sunt respectate, reduc foarte mult șansa de a introduce erori în timpul dezvoltării aplicației. Standardele de programare ar trebui urmate în etapa de scriere a programelor, înainte de a fi transferate pe platformele țintă, în timp ce standardizarea ar trebui să existe pentru toate limbile. Deoarece majoritatea dezvoltatorilor încorporați folosesc C, ne vom concentra mai mult pe standardele de programare C, deși există aceleași standarde pentru alte limbaje, inclusiv C++ și Java.
În general, standardele de programare se împart în două categorii:
standarde de programare din industrie: reguli acceptate de toți programatorii într-un anumit limbaj (de exemplu, neintroducerea unei bucle prin antetul acesteia).
standarde speciale de programare: reguli urmate de un anumit grup de dezvoltatori, în cadrul unui anumit proiect, sau chiar de un singur programator. Există trei tipuri de standarde personalizate pe care le poate folosi un dezvoltator de sisteme software încorporate: standarde interne, standarde personale și standarde definite de platforma țintă.
Standardele interne de programare sunt reguli specifice organizației sau echipei de dezvoltare. Astfel, convențiile de denumire unice pentru organizație sunt un exemplu de standarde interne de programare.
Standardele personale sunt reguli care vă vor ajuta să evitați cele mai frecvente greșeli. De fiecare dată când apare o eroare, programatorul trebuie să analizeze cauza apariției acesteia și să dezvolte propria sa regulă care împiedică reapariția acesteia. De exemplu, dacă într-o declarație de condiție scrieți adesea un semn de atribuire în loc de un test de egalitate (adică „dacă (a=b)” în loc de „dacă (a= =b)”), atunci trebuie să creați următorul standard pentru tine: „Ai grijă să nu folosești un semn de atribuire într-o declarație de testare a condiției”.
Standardele definite de platforma țintă sunt reguli care, dacă sunt încălcate pe platforma respectivă, pot duce la anumite probleme. De exemplu, astfel de standarde ar putea fi limite ale utilizării memoriei sau dimensiunea variabilelor impuse de platforma țintă.
Pentru a înțelege mai bine ce sunt standardele de programare și cum funcționează acestea, să ne familiarizăm cu ele folosind exemple specifice. Luați în considerare următoarea notație în C:
{
.
.
.
}
Aici, dimensiunea unui tablou unidimensional este declarată în lista de argumente ale funcției. Acesta este o construcție periculoasă, deoarece în C, un argument de matrice este transmis ca un pointer către primul său element, iar apelurile diferite către o funcție pot conține matrice de dimensiuni diferite printre argumentele sale reale. După ce ați creat o astfel de construcție, ar trebui să utilizați un buffer de dimensiune fixă ​​de 80 de elemente, presupunând că acesta este tamponul care va fi transmis funcției, iar acest lucru poate duce la distrugerea memoriei. Dacă autorul acestui operator a urmat standardul de programare „nu declarați dimensiunea unui tablou unidimensional printre argumentele unei funcții” (luat din setul de standarde de programare în limbajul C al uneia dintre cele mai importante companii de telecomunicații), atunci acest text ar arăta astfel și problemele cu distrugerea memoriei ar putea fi evitate:
char *subșir (șir de caractere, int start_pos, int lungime)
{
.
.
.
}
Standardele de programare vă permit, de asemenea, să evitați problemele care pot să nu apară până când codul este portat pe o altă platformă. De exemplu, următoarea bucată de cod va funcționa corect pe unele platforme și va genera erori după portarea lui pe alte platforme:
#include
test nul (car c) (
în cazul în care o<= c && c <= z) { // Неправильно
}
if(este mai jos(c)) (// Drept
}
In timp ce<= c && c <= Z) { // Неправильно
}
în timp ce (supper(c)) ( // Dreapta
}
}
Problemele de portare pot fi legate de testele de caractere care nu folosesc funcțiile ctype.h (isalnum, isalpha, iscntrl, isdigit, isgraph, islower, isprint, ispunct, isspace, isupper, isxdigit, tolower, toupper). Funcțiile ctype.h pentru verificarea caracterelor și conversia literelor mari în minuscule și invers funcționează cu o mare varietate de seturi de caractere, sunt de obicei foarte eficiente și garantează aplicabilitatea internațională a produsului software.
Cea mai bună modalitate de a implementa aceste standarde și alte standarde de programare este să le aplicați automat ca parte a unei tehnologii de programare, împreună cu un set de standarde și mecanisme specifice ale industriei pentru a crea și menține standarde de programare specifice sistemului. Atunci când alegeți o astfel de tehnologie, trebuie mai întâi să găsiți răspunsuri la întrebări, inclusiv următoarele:
Se aplică acestui program și/sau compilator?
Conține un set de standarde de programare din industrie?
Vă permite să creați și să mențineți standarde de programare personalizate (inclusiv cele definite de platforma țintă)?
Este ușor să structurați rapoarte în funcție de prioritățile de grup și de proiect?
Cât de ușor se integrează în procesul de dezvoltare existent?
Testarea unitară

Adesea, atunci când dezvoltatorii aud despre testarea unitară, o percep ca un sinonim pentru testarea unitară. Cu alte cuvinte, atunci când testează un singur modul sau subrutină a unei unități software mai mari, dezvoltatorii cred că fac teste unitare. Desigur, testarea unitară este foarte importantă și cu siguranță ar trebui făcută, dar aceasta nu este metoda asupra căreia aș dori să mă opresc. Prin „testare unitară” mă refer la testarea la un nivel și mai scăzut: testarea celor mai mici unități de program posibile care alcătuiesc un program de aplicație, cât timp se află încă în mediul de instrumente (sistemul gazdă) în cazul limbajului C, acestea vor fi funcții , care sunt verificate imediat după compilare.
Testarea unitară îmbunătățește foarte mult calitatea software-ului și eficiența procesului de dezvoltare. Când testați la nivel de caracteristică, sunteți mult mai aproape de această tehnică și aveți o capacitate mult mai mare de a crea seturi de intrare care detectează erori cu o acoperire de 100% (Figura 2). De asemenea, testând un bloc de cod imediat după ce a fost scris, eviți să fii nevoit să „treci prin” straturi de erori pentru a găsi și a remedia singurul original – în acest caz, îl remediazi imediat și întreaga problemă este rezolvată. . Acest lucru accelerează și facilitează semnificativ procesul de dezvoltare, deoarece sunt cheltuite mult mai puține resurse materiale și de timp pentru găsirea și eliminarea erorilor.

Orez. 2. Ușurința de a găsi erori în testarea unitară

Testarea unitară poate fi împărțită în cel puțin două procese separate. Primul este testarea cutiei negre sau procesul de identificare a problemelor funcționale. La nivel de bloc, testarea „cutie neagră” constă în verificarea performanței prin determinarea gradului în care parametrii interfeței publice ai unei funcții se conformează cu specificația acesteia; o astfel de verificare se efectuează fără a ține cont de metodele de implementare. Rezultatul testării cutiei negre la nivel de bloc este asigurarea că o anumită funcție se comportă exact așa cum este definită și că o eroare funcțională minoră nu va duce la o avalanșă de probleme insolubile.

Orez. 3. Testarea cutiei negre

Al doilea proces se numește testare „cutie albă” și este conceput pentru a identifica defectele de proiectare. La nivelul blocurilor individuale, se verifică dacă întregul program se va prăbuși la transmiterea unor parametri neaștepți la funcție. Acest tip de testare ar trebui să fie efectuat de o persoană care are o înțelegere aprofundată a modului în care este implementată funcția testată. După o astfel de verificare, puteți fi sigur că nu există erori care să conducă la blocarea sistemului și că funcția va funcționa stabil în orice condiții (adică va produce rezultate previzibile chiar și cu parametrii de intrare neaștepți).

Orez. 4. Testarea cutiei albe

Ambele procese de mai sus pot servi drept bază pentru o a treia testare de regresie. Salvând cazurile de testare cutie neagră și casetă albă, le puteți folosi pentru testarea regresiei la nivel de bloc și puteți verifica integritatea codului pe măsură ce îl modificați. Conceptul de testare de regresie la acest nivel este o nouă abordare originală. Când efectuați testarea regresiei la nivel de bloc, puteți determina imediat după ce modificați textul dacă au apărut noi probleme și le puteți remedia imediat după ce apar, prevenind astfel propagarea erorii la niveluri superioare.
Principala problemă a testării unitare este că, dacă nu utilizați tehnologii automate de testare unitară, este dificil, obositor și prea lung de efectuat. Să aruncăm o privire rapidă asupra motivelor pentru care includerea testării unităților umane în procesele de dezvoltare actuale este dificilă (dacă nu imposibilă).
Primul pas în testarea unitară a software-ului încorporat este să creați un mediu care vă permite să rulați și să testați caracteristica de interes pe sistemul gazdă. Acest lucru necesită următorii doi pași:
dezvoltarea textului programului care va rula funcția,
scrierea modulelor false care vor returna rezultate în locul resurselor externe accesate de funcția care lipsesc sau nu sunt disponibile în prezent.
A doua etapă este dezvoltarea suitelor de testare. Pentru o acoperire completă a designului și a caracteristicilor funcționale ale funcției, este necesar să se creeze două tipuri de suite de testare: pentru „cutia neagră” și pentru „cutia albă”.
Specificarea funcției ar trebui să formeze baza pentru dezvoltarea suitelor de testare cutie neagră. În special, pentru fiecare intrare din specificație, trebuie creat cel puțin un set de testare și este de dorit ca aceste seturi să ia în considerare condițiile limită specificate în specificație. Nu este suficient să verificați că unii parametri de intrare conduc la rezultatele așteptate; este necesar să se determine intervalul de interrelații dintre intrări și ieșiri, ceea ce va face posibilă tragerea unei concluzii despre implementarea corectă a caracteristicilor funcționale specificate și apoi crearea suitelor de testare care acoperă complet acest interval. De asemenea, puteți testa pentru condiții nespecificate și eronate.
Scopul suitelor de testare cutie albă este de a descoperi toate defectele latente prin testarea extensivă a funcției cu o varietate de intrări. Aceste seturi ar trebui să aibă următoarele caracteristici:
asigurați o acoperire cât mai mare posibil (100%) a unei funcții: așa cum sa menționat deja, acest grad de acoperire la nivel de bloc este posibil, deoarece este mult mai ușor să creați seturi pentru a testa fiecare caracteristică a unei funcții în afara aplicației (acoperire 100%) nu este posibil în toate cazurile, dar acesta este un scop pentru care să ne străduim);
identificați condițiile de prăbușire a funcției.
Trebuie remarcat faptul că crearea unor astfel de seturi pe cont propriu, fără a deține tehnologiile pentru construcția lor, este o sarcină incredibil de dificilă. Pentru a crea cazuri de testare cu casete albe eficiente, trebuie mai întâi să înțelegeți complet structura internă a unei funcții, să scrieți seturi care oferă o acoperire maximă a funcției și să găsiți setul de intrări care cauzează eșecul funcției. Este posibil să se obțină spectrul de acoperire necesar pentru testarea cutie albă extrem de eficientă numai prin examinarea unui număr semnificativ de căi prin funcție. De exemplu, într-un program tipic de 10.000 de declarații, există aproximativ o sută de milioane de căi posibile; nu este posibil să se creeze manual cazuri de testare pentru a testa toate aceste căi.
După crearea suitelor de testare, este necesar să testați complet funcția și să analizați rezultatele pentru a identifica cauzele erorilor, blocărilor și punctelor slabe. Trebuie să aveți o modalitate de a parcurge toate cazurile de testare și de a determina rapid care dintre ele cauzează probleme. De asemenea, este necesar să existe un instrument de măsurare a acoperirii pentru a evalua caracterul complet al testării caracteristicilor și pentru a determina dacă sunt necesare cazuri de testare suplimentare.
Orice modificare a caracteristicilor trebuie testată cu regresie pentru a se asigura că nu există erori noi și/sau erori anterioare au fost remediate. Includerea testării regresiei unitare în procesul de dezvoltare vă va permite să vă protejați de multe erori, acestea vor fi detectate imediat după ce apar și nu vor putea provoca propagarea erorilor în aplicație.
Testarea regresiei se poate face în două moduri. Primul este că dezvoltatorul sau testerul analizează fiecare caz de testare și determină care dintre ele poate fi afectat de codul modificat. Această abordare se caracterizează prin economisirea timpului mașinii datorită muncii efectuate de o persoană. Al doilea, mai eficient, este rularea automată a tuturor cazurilor de testare pe computer după fiecare modificare de text. Această abordare garantează o eficiență mai mare pentru dezvoltator, deoarece nu trebuie să petreacă timp analizând întregul set de cazuri de testare pentru a determina care seturi ar trebui să fie rulate și care nu.
Dacă puteți automatiza procesul de testare unitară, nu numai că veți îmbunătăți calitatea testării, dar veți elibera și mult mai mult timp și resurse materiale pentru dvs. decât va necesita acest proces. Dacă scrieți programe în C, atunci puteți utiliza tehnologiile existente pentru a automatiza testarea unitară. Cu cât puteți automatiza mai multe procese, cu atât veți obține mai multă valoare.
Atunci când alegeți o tehnologie de testare unitară, trebuie mai întâi să răspundeți la următoarele întrebări:
Este această tehnologie potrivită pentru textul și/sau compilatorul dvs.?
Poate genera automat circuite de testare?
Poate genera automat cazuri de testare?
Permite introducerea cazurilor de testare create de utilizator și a modulelor fictive?
Testarea regresiei este automatizată?
Include tehnologie sau legătură cu tehnologia pentru recunoașterea automată a unei erori în timpul rulării?
Instrumente de depanare care nu schimbă modul de funcționare al programelor

Deoarece sistemele de operare în timp real trebuie să îndeplinească anumite sarcini sub constrângeri de timp predeterminate, sincronizarea devine un parametru critic pe care dezvoltatorii trebuie să-l ia în considerare atunci când instalează software-ul de testare. De obicei, există multe întreruperi diferite care apar în timpul execuției programelor și este extrem de important ca aplicația să răspundă corect atunci când apare întreruperea. Situația este și mai complicată atunci când apar mai multe întreruperi simultan sau când mai multe aplicații rulează pe sistem cu mai multe fire care interacționează între ele. De fapt, acestea sunt aplicații cu mai multe căi de execuție simultane, diverse secvențe de cod par să fie executate în același timp, chiar dacă în sistem există un singur procesor central. Este interesant de remarcat faptul că, dacă aceste aplicații ar rula pe mai multe procesoare, fire diferite ar fi, în practică, încărcate pe procesoare diferite.
Dacă erorile care apar în aplicațiile în timp real se manifestă în interacțiunile dintre program și întreruperi, atunci acestea vor fi foarte sensibile la timp. În acest caz, este esențial să înregistrați ordinea în care au apărut erorile, deoarece acest lucru vă va permite să înțelegeți cauzele și consecințele fiecărei erori. Aceasta este tocmai problema principală a depanării sistemelor în timp real: există un număr suficient de erori greu de detectat care apar doar la anumite rapoarte de timp.
Această problemă este agravată de faptul că astfel de erori nu sunt atât de ușor de reprodus. Este foarte dificil să recreați o situație cu aceleași relații de timp ca cele care au cauzat eroarea într-un program real. Mecanismul de depanare pentru astfel de aplicații ar trebui să fie cât mai îngăduitor. Orice intervenție în cursul execuției programului poate duce la o modificare a caracteristicilor sale temporale și la absența condițiilor de eroare. Desigur, crearea unor condiții în care să nu apar erori este bună, dar în acest caz este un obstacol în calea depanării programului.
Baza teoretică a problemei depanării sistemelor în timp real poate fi principiul incertitudinii al fizicianului german Werner Heisenberg, cunoscut de toată lumea din cursul fizicii, conform căruia este imposibil să se determine simultan viteza și locația unei particule în mișcare. . Heisenberg credea că, determinând coordonatele unei particule, experimentatorul își schimbă astfel locația, ceea ce nu permite determinarea coordonatelor sale cu precizie. Operația de măsurare afectează obiectul măsurat și distorsionează rezultatele măsurării. Principiul incertitudinii este una dintre axiomele mecanicii cuantice.
Așa cum este aplicat subiectului nostru, acest principiu înseamnă că depanarea unui sistem necesită colectarea de informații despre starea acestuia. Cu toate acestea, colectarea de informații despre starea sistemului își schimbă caracteristicile temporale și complică semnificativ reproducerea fiabilă a condițiilor pentru apariția unei erori.
Astfel, miezul problemei este de a găsi o modalitate de a detecta erorile în timp real și de a analiza comportamentul programului fără a afecta relațiile de sincronizare existente. Primul tău impuls ar fi probabil să folosești un depanator, dar depanatorii tind să întrerupă execuția unui program și să-i schimbe sincronizarea în consecință. Sistemele de simulare sunt, de asemenea, de puțin folos, deoarece nu pot recrea caracteristicile temporale ale mijloacelor tehnice reale. Nimeni nu a creat încă un sistem de simulare care să poată simula în timp real; parametrii de sincronizare pot fi determinați numai prin descărcarea programului în hardware-ul propriu-zis.
Acesta din urmă necesită un mecanism special pentru înregistrarea simplificată a stării sistemului. Unul dintre mecanismele posibile și potrivite este scrierea informațiilor pe RAM, deoarece o astfel de operație este extrem de rapidă. O modalitate de a folosi acest mecanism este să organizați un buffer special undeva în memorie și să utilizați un pointer către acest buffer în programul dumneavoastră. Pointerul indică întotdeauna începutul buffer-ului. Programul inserează operațiuni de scriere în celula identificată de indicator. După fiecare operație de scriere, valoarea indicatorului se modifică în mod corespunzător. Uneori este util să folosiți un buffer inel (adică, după ce ați scris în ultima celulă a tamponului, indicatorul începe să indice la începutul tamponului), ceea ce vă permite să urmăriți situațiile care duc la o problemă. În același timp, este necesar să se ofere o modalitate de salvare a conținutului tamponului după terminarea normală sau anormală a programului, pentru a avea ulterior acces la acesta și a efectua așa-numita „depanare post-mortem” . Metoda de implementare depinde de hardware, de obicei se poate face dacă nu reinițializați (resetați) hardware-ul.
Acum aveți nevoie de un mecanism pentru a citi această memorie. Aici puteți folosi depanatorul și alte mijloace de extragere a informațiilor din RAM. În special, puteți scrie un program simplu care va trimite aceste date către un fișier sau imprimantă. Indiferent de instrumentul pe care îl utilizați, pasul final va fi probabil analizarea manuală a conținutului tamponului. Dacă buffer-ul tău este circular, atunci trebuie să știi exact care este valoarea pointerului; evenimentele care au început secvența vor fi imediat înainte de indicator, evenimentele care au avut loc chiar înainte de accident vor fi imediat după indicator.

Orez. 5. Secvența evenimentelor din tamponul inel

Acum sarcina ta principală este să încerci să înțelegi succesiunea datelor înregistrate în buffer. Această sarcină este similară cu studiul cauzelor unui accident de avion conform citirilor instrumentelor înregistrate de „cutia neagră” a aeronavei. Analiza caracteristicilor programului în acest caz se efectuează după ce evenimentul a avut loc, ceea ce, desigur, afectează execuția acestuia mult mai puțin decât controlul în timpul lucrului.
Uneori este foarte dificil să recuperați evenimentele care au dus la prăbușire și nu există o idee clară despre când a apărut eroarea. Poate dura multe luni doar pentru a afla cauza erorii. În astfel de cazuri, puteți utiliza metoda de depanare logaritmică pentru a găsi operatorul eronat. În diferite locuri ale codului depanat, sunt plasați markeri (de exemplu, instrucțiuni precum exit), iar în fața lor sunt instrucțiuni de scriere în memorie. Apoi rulați programul și așteptați momentul blocării. În cazul unui accident, știți între ce markeri s-a întâmplat. Această metodă detectează, de asemenea, probleme de sincronizare, deoarece vă permite să găsiți segmente de cod în care apar încălcări de sincronizare.
O altă soluție este utilizarea așa-numitelor firewall-uri ca tehnologie de depanare. Un firewall este un punct din fluxul logic al unui program în care ipotezele care stau la baza următorului cod se dovedesc a fi adevărate. Verificarea acestor ipoteze este diferită de verificarea normală a erorilor. Activarea firewall-ului este un semnal pentru dezvoltator că starea internă a sistemului este instabilă. Acest lucru se poate întâmpla, de exemplu, dacă o funcție care așteaptă un argument strict pozitiv primește o valoare zero sau o valoare negativă. Pentru dezvoltatorii fără experiență, majoritatea firewall-urilor par banale și inutile. Cu toate acestea, experiența dezvoltării de proiecte mari arată că pe măsură ce sistemele software se dezvoltă și se îmbunătățesc, ipotezele implicite despre mediul de execuție sunt încălcate din ce în ce mai des. În multe cazuri, chiar și autorului însuși îi este greu să formuleze care sunt condițiile adecvate pentru executarea unei anumite secțiuni de cod.
Firewall-urile implementate în interiorul sistemelor încorporate necesită mijloace speciale de comunicare pentru a transmite mesaje către lumea exterioară; discuția despre modul de stabilire a unor astfel de canale de transmisie depășește domeniul de aplicare al acestui articol.
Concluzie

Metodele de prevenire și detectare a erorilor discutate mai sus, precum și tehnologiile de depanare, pot îmbunătăți semnificativ calitatea software-ului sistemelor încorporate și pot reduce resursele materiale și de timp cheltuite pentru depanare. Metodele de mai sus pot fi utilizate cu ușurință în dezvoltarea unei game largi de proiecte software încorporate, iar experiența dobândită își păstrează pe deplin valoarea în implementarea altor proiecte și tehnologii țintă. În plus, fac posibilă garantarea ușurinței întreținerii, modificării și portarii programelor create pe noi tipuri de dispozitive. Pe scurt, aceste tehnici nu oferă doar o oportunitate de a îmbunătăți aplicațiile încorporate existente și procesele de dezvoltare, ci și de a vă asigura că, odată cu proliferarea de noi dispozitive încorporate, aveți deja experiența necesară pentru a dezvolta aplicații de înaltă performanță pentru aceste tehnologii și pe timp şi în conformitate cu bugetul alocat.
Literatură

1. M. Aivazis și W. Hicken. „Programare defensivă C++: firewall-uri și informații de depanare”. Raport C++ (iulie-august 1999): 34 40.

Clasificarea erorilor software

Să luăm în considerare clasificarea erorilor în funcție de locul apariției lor, care este considerată în cartea lui S. Kaner „Software Testing”. Concepte fundamentale ale managementului aplicațiilor de afaceri. . Principalul criteriu al programului ar trebui să fie calitatea acestuia, care este interpretată ca absența deficiențelor în acesta, precum și eșecurile și erorile evidente. Dezavantajele programului depind de evaluarea subiectivă a calității acestuia de către un potențial utilizator. În același timp, autorii sunt sceptici cu privire la caietul de sarcini și susțin că, chiar dacă există, deficiențele identificate în etapa finală indică calitatea scăzută a acesteia. Prin această abordare, depășirea deficiențelor programului, în special în etapa finală de proiectare, poate duce la o scădere a fiabilității. Evident, această abordare nu este potrivită pentru dezvoltarea de software responsabil și sigur, dar problemele erorilor în specificații, evaluarea subiectivă a calității programului de către utilizator există și nu pot fi ignorate. Ar trebui dezvoltat un sistem de anumite restricții care să țină cont de acești factori la dezvoltarea și certificarea unui astfel de software. Pentru programele obișnuite, toate problemele asociate cu evaluarea subiectivă a calității lor și prezența erorilor sunt cel mai probabil inevitabile.

Într-o scurtă clasificare, sunt evidențiate următoarele erori.

Erori de interfață cu utilizatorul.

Erori de calcul.

Erori de control al fluxului.

Erori de transmitere sau interpretare a datelor.

Supraîncărcări.

Controlul versiunii.

Eroarea a fost identificată și uitată.

Erori de testare.

1. Erori UI.

Multe dintre ele sunt subiective, pentru că adesea ele reprezintă mai mult un inconvenient decât erori logice „pure”. Cu toate acestea, ele pot provoca erori de către utilizatorul programului sau pot încetini timpul de lucru până la o valoare inacceptabilă. Ca urmare, vom avea erori în sistemul informațional (SI) în ansamblu. Sursa principală a unor astfel de erori este un compromis complex între funcționalitatea programului și ușurința de a învăța și de a lucra cu utilizatorul acestui program. Problema trebuie să înceapă să fie rezolvată atunci când proiectați un sistem la nivelul descompunerii sale în module separate, pe baza faptului că este puțin probabil că va fi posibilă proiectarea unei interfețe de utilizator simplă și convenabilă pentru un modul supraîncărcat cu diverse funcții. În plus, trebuie luate în considerare liniile directoare de proiectare a interfeței cu utilizatorul. În etapa de testare a software-ului, este util să furnizați instrumente de testare încorporate care să rețină secvența acțiunilor utilizatorului, timpul de efectuare a operațiunilor individuale și distanța pe care s-a deplasat cursorul mouse-ului. În plus, este posibil să utilizați mijloace mult mai complexe de testare psiho-fizică în etapa de testare a interfeței cu utilizatorul, ceea ce vă va permite să evaluați viteza de reacție a utilizatorului, frecvența acestor reacții, oboseala etc. Trebuie menționat că astfel de erori sunt foarte critice din punctul de vedere al succesului comercial al software-ului dezvoltat. acestea vor fi evaluate în primul rând de un potențial client.

2. Erori de calcul.

Se disting următoarele motive pentru apariția unor astfel de erori:

Logica incorectă (poate fi rezultatul erorilor de proiectare și codare);

Operațiile aritmetice sunt efectuate incorect (de regulă, acestea sunt erori de codare);

Calcule inexacte (pot rezulta atât din erori de proiectare, cât și din erori de codare). Acesta este un subiect foarte complex și trebuie să ne dezvoltăm propria atitudine față de acesta din punctul de vedere al dezvoltării de software securizat.

Sunt evidențiate subitemele: constante învechite; erori de calcul; paranteze spațiate incorect; ordinea incorectă a operatorilor; funcția de bază nu funcționează corect; depășire și pierdere de biți semnificativi; erori de tăiere și rotunjire; confuzie cu prezentarea datelor; conversia incorectă a datelor dintr-un format în altul; formula greșită; aproximare greșită.

3. Erori de control al fluxului.

Această secțiune include tot ceea ce este legat de secvența și circumstanțele execuției instrucțiunilor programului.

Subitetele ies în evidență:

Comportamentul evident incorect al programului;

tranziție GOTO;

Logica bazată pe definirea rutinei de apelare;

Utilizarea meselor de sărituri;

Executați date (în loc de comenzi). Situația este posibilă din cauza erorilor în lucrul cu pointerii, a lipsei verificărilor limitelor matricei, a erorilor de salt cauzate, de exemplu, de o eroare în tabelul de adrese de salt, a erorilor de segmentare a memoriei.

4. Erori în prelucrarea sau interpretarea datelor.

Subitetele ies în evidență:

Probleme de transmitere a datelor între rutine (mai multe tipuri de erori sunt incluse aici: parametrii nu sunt în ordine sau lipsesc, nepotrivirea tipului de date, aliasuri și interpretarea diferită a conținutului aceleiași zone de memorie, interpretarea greșită a datelor, informații de eroare inadecvate, înainte de blocarea starea corectă a datelor nu a fost restabilită din subrutină, copii învechite ale datelor, variabilele asociate nu sunt sincronizate, setarea locală a datelor globale (adică confuzia variabilelor locale și globale), utilizarea globală a variabilelor locale, masca incorectă a câmpului de biți, valoarea incorectă de la masa);

Limitele locației datelor (aceasta include mai multe tipuri de erori: sfârșitul unui șir terminat cu nul nu este indicat, sfârșitul neașteptat al șirului, scriere/citire în afara limitelor structurii de date sau ale elementului său, citire în afara bufferului de mesaje, citire în afara buffer-ului de mesaje, completarea variabilei până la cuvântul complet, depășirea și supraîncărcarea stivei de date, codul de suprascriere sau datele unui alt proces);

Probleme cu mesageria (aceasta include mai multe tipuri de erori: trimiterea unui mesaj către un proces greșit sau către portul greșit, eroare la recunoașterea unui mesaj primit, mesaje lipsă sau nesincronizate, mesaj transmis doar la N din N + 1 procese, coruperea datelor stocate pe un dispozitiv extern, pierderea modificărilor, datele introduse nesalvate, volumul de date prea mare pentru procesul de primire, încercarea nereușită de a anula scrierea datelor).

5. Sarcini crescute.

În condiții de încărcare crescută sau lipsă de resurse, pot apărea erori suplimentare. Sub-articolele sunt evidențiate: resursa necesară nu este disponibilă; resursa neeliberată; nu există semnal pentru eliberarea dispozitivului; fișierul vechi nu este șters de pe unitate; memoria neutilizată nu este returnată sistemului; timp suplimentar pe calculator; nu există un bloc liber de memorie de dimensiune suficientă; dimensiune insuficientă a tamponului sau a cozii de intrare; elementul de coadă, tampon sau stivă nu este șters; mesaje pierdute; degradarea performanței; creșterea probabilității de curse situaționale; sub sarcină crescută, cantitatea de date opționale nu este redusă; ieșirea prescurtată a altui proces nu este recunoscută la sarcină crescută; locurile de muncă cu prioritate scăzută nu sunt suspendate.

În această secțiune, aș dori să atrag atenția asupra următoarelor:

1) Unele dintre erorile din această secțiune pot apărea și la sarcini nu foarte mari, dar, poate, vor apărea mai rar și după intervale de timp mai lungi;

2) Multe dintre erorile din cele 2 secțiuni anterioare aflate deja în formularea lor sunt de natură probabilistică, așa că ar trebui să se presupună că modelele și metodele probabilistice pot fi folosite pentru a le identifica.

6. Controlul versiunilor și al identificatorilor.

Subpunctele ies în evidență: erorile vechi reapar în mod misterios; nu actualizarea tuturor copiilor de date sau de fișiere de program; fără titlu; fără număr de versiune; numărul de versiune incorect în titlul ecranului; informații despre drepturile de autor lipsă sau incorecte; programul compilat din copia de arhivă nu corespunde cu versiunea vândută; discurile terminate conțin cod sau date nevalide.

7. Erori de testare.

Sunt erorile echipei de testare, nu programul. Subitetele ies în evidență:

Erori ratate în program;

Problema nu este observată (se notează următoarele motive: testerul nu știe care ar trebui să fie rezultatul corect, eroarea s-a pierdut într-o cantitate mare de date de ieșire, testerul nu se aștepta la un astfel de rezultat al testului, testerul este obosit și neatent, se plictisește, mecanismul de execuție a testului este atât de complicat încât testerul îi acordă mai multă atenție decât rezultatelor).

Lipsesc erori de pe ecran;

Problema nu este documentată (se notează următoarele motive pentru aceasta: testerul nu păstrează înregistrări exacte, testerul nu este sigur că aceste acțiuni ale programului sunt eronate, eroarea părea a fi prea mică, testerul consideră că eroarea nu va fi fi remediat, testerului i s-a cerut să nu mai documenteze astfel de erori).

8. Eroarea este identificată și uitată.

Sunt descrise erori în utilizarea rezultatelor testelor. După părerea mea, secțiunea ar trebui îmbinată cu cea anterioară. Se evidențiază subpunctele: raportul final nu a fost întocmit; o problemă gravă nu este re-documentată; reparație netestată; lista problemelor restante nu a fost revizuită înainte de lansarea produsului.

Trebuie remarcat faptul că erorile de testare descrise în ultimele 2 secțiuni necesită eliminarea automatizării testării și a instrumentelor de raportare. În mod ideal, aceste instrumente ar trebui să fie integrate cu instrumente și tehnologii de proiectare software. Ele ar trebui să devină instrumente importante pentru crearea de software de înaltă calitate. Atunci când se dezvoltă instrumente automate de testare, erorile care sunt inerente oricărui software ar trebui evitate, de aceea este necesar să se solicite ca astfel de instrumente să aibă caracteristici de fiabilitate mai mari decât software-ul testat cu ele.

Principalele moduri de a trata erorile

Luând în considerare caracteristicile considerate ale acțiunilor umane în timpul traducerii, pot fi indicate următoarele modalități de tratare a erorilor:

Restrângerea spațiului de căutare (simplificarea sistemelor create),

Asigurarea nivelului necesar de pregătire pentru dezvoltatori (acestea sunt funcțiile managerilor echipei de dezvoltare),

asigurarea lipsei de ambiguitate a interpretării prezentării informațiilor,

controlul corectitudinii traducerii (inclusiv controlul lipsei de ambiguitate a interpretării).

Presupunând că vor exista încă unele erori în software, cea mai bună strategie (după prevenirea erorilor) este includerea instrumentelor de detectare a erorilor în software-ul însuși.

Majoritatea metodelor vizează, dacă este posibil, detectarea imediată a defecțiunilor. Detectarea imediată are două avantaje: puteți minimiza impactul erorii și bătaia de cap ulterioară pentru persoana care trebuie să extragă informații despre aceasta, să le găsească și să o corecteze.

(SITELINK-S405) Măsurile de detectare a erorilor (/SITELINK) pot fi împărțite în două subgrupe: pasiv încearcă să detecteze simptomele unei erori în timpul funcționării „normale” a software-ului și activ încercările unui sistem software de a-și examina periodic starea pentru semne de eroare.

Detectie pasiva. Măsurile de detectare a erorilor pot fi luate la mai multe niveluri structurale ale unui sistem software. Aici vom lua în considerare nivelul subsistemelor, sau componentelor, de ex. ne vor interesa măsurile luate pentru depistarea simptomelor de erori, luate în timpul trecerii de la o componentă la alta, precum și în cadrul componentei. Toate acestea, desigur, se aplică și modulelor individuale din cadrul unei componente.

În dezvoltarea acestor măsuri, ne vom baza pe următoarele.

1. Neîncrederea reciprocă. Fiecare dintre componente trebuie să presupună că toate celelalte conțin erori. Când primește unele date de la o altă componentă sau de la o sursă din afara sistemului, trebuie să presupună că datele pot fi incorecte și să încerce să găsească erori în ele.

2. Detectare imediată. Erorile trebuie detectate cât mai curând posibil. Acest lucru nu numai că limitează daunele pe care le provoacă, dar și simplifică foarte mult sarcina de depanare.

3. redundanţă. Toate instrumentele de detectare a erorilor se bazează pe o anumită formă de redundanță (explicită sau implicită).

Când dezvoltați măsuri de detectare a erorilor (SITELINK-S405) (/SITELINK), este important să adoptați o strategie consecventă pentru întregul sistem. Acțiunile întreprinse după detectarea unei erori software ar trebui să fie consecvente în toate componentele sistemului. Acest lucru ridică întrebarea exact ce acțiune ar trebui luată atunci când este detectată o eroare. Cea mai bună soluție este să închideți imediat programul sau (în cazul sistemului de operare) să puneți procesorul într-o stare de așteptare. Din punctul de vedere al oferirii persoanei care depanează programul, cum ar fi un programator de sistem, condițiile cele mai favorabile pentru diagnosticarea erorilor, terminarea imediată pare a fi cea mai bună strategie. Desigur, în multe sisteme, o astfel de strategie este nepractică (de exemplu, se poate dovedi că este imposibil să suspendați sistemul). În acest caz, se folosește metoda înregistrarea erorilor. O descriere a simptomelor erorii și o „instantanee” a stării sistemului sunt stocate într-un fișier extern, după care sistemul poate continua să funcționeze. Acest dosar va fi ulterior examinat de personalul de întreținere.

Ori de câte ori este posibil, este mai bine să opriți execuția programului decât să înregistrați erorile (sau să oferiți o opțiune suplimentară pentru a rula sistemul în oricare dintre aceste moduri). Diferența dintre aceste metode este ilustrată prin modalități de a identifica cauzele zdrăngănitoarelor ocazionale din mașina dvs. Dacă mecanicul se află pe bancheta din spate, atunci el poate examina starea mașinii în momentul în care se produce zdrăngănirea. Dacă alegeți metoda de înregistrare a erorilor, sarcina de diagnosticare devine mai dificilă.

Detectare activă a erorilor. Nu toate erorile pot fi detectate prin metode pasive, deoarece aceste metode detectează o eroare numai atunci când simptomele acesteia sunt supuse unei verificări adecvate. Verificări suplimentare pot fi efectuate dacă instrumentele software speciale sunt concepute pentru a căuta în mod activ semne de erori în sistem. Se numesc astfel de fonduri detectare activă a erorilor.

Instrumentele active de detectare a erorilor sunt de obicei combinate în monitor de diagnostic: un proces paralel care analizează periodic starea sistemului pentru a detecta o eroare. Sistemele software mari care gestionează resursele conțin adesea erori care duc la pierderea resurselor pentru o perioadă lungă de timp. De exemplu, managementul memoriei sistemului de operare închiriază blocuri de memorie către programele utilizatorului și alte părți ale sistemului de operare. O eroare chiar în aceste „alte părți” ale sistemului poate duce uneori la o defecțiune a unității de gestionare a memoriei care returnează memoria închiriată anterior, ceea ce provoacă o degenerare lentă a sistemului.

Monitorul de diagnosticare poate fi implementat ca o sarcină care rulează periodic (de exemplu, este programată la fiecare oră) sau ca o sarcină cu prioritate scăzută care este programată să ruleze atunci când sistemul intră într-o stare de așteptare. Ca și până acum, verificările specifice pe care le efectuează monitorul depind de sistemul specific, dar unele idei vor fi clare din exemple. Monitorul poate examina memoria principală pentru a detecta blocuri de memorie care nu sunt alocate de niciuna dintre sarcinile care rulează și care nu sunt incluse în lista liberă a sistemului. De asemenea, poate verifica situații neobișnuite: de exemplu, un proces nu a fost programat să ruleze pentru o perioadă rezonabilă de timp. Monitorul poate căuta mesaje „pierdute” în interiorul sistemului sau operațiuni I/O care rămân nefinalizate pentru un timp neobișnuit de lung, zone de memorie de pe disc care nu sunt marcate ca alocate și neincluse în lista de memorie liberă, precum și ca diverse tipuri de ciudățenie în fișierele de date.

Uneori este de dorit ca monitorul să efectueze teste de diagnosticare a sistemului în circumstanțe de urgență. Poate apela anumite funcții de sistem, comparând rezultatul acestora cu unul prestabilit și verificând dacă timpul de execuție este rezonabil. Monitorul poate prezenta periodic sistemului sarcini „goale” sau „ușoare” pentru a se asigura că sistemul funcționează cel puțin în cel mai primitiv mod.

Trimiteți-vă munca bună în baza de cunoștințe este simplu. Utilizați formularul de mai jos

Studenții, studenții absolvenți, tinerii oameni de știință care folosesc baza de cunoștințe în studiile și munca lor vă vor fi foarte recunoscători.

Găzduit la http://www.allbest.ru/

1. Analiza caracteristicilor de fiabilitate software ale ASOIU și metode de predicție a defecțiunilor software

1.1 Concepte de bază ale fiabilității software

Automatizarea proceselor de control este direcția principală în dezvoltarea sistemelor de comandă și control, în cadrul căreia se realizează dezvoltarea, crearea și utilizarea în procesele de comandă și control al trupelor de calculatoare electronice, mijloace tehnice asociate, suport informațional și matematic, care poate crește semnificativ eficiența comenzii și controlului, îmbunătăți calitatea prelucrării informațiilor și a sistemelor de management al performanței. În aceste scopuri, sunt create sisteme automate de comandă și control.

Elementul principal al sistemului automat de comandă și control este un set de instrumente de automatizare a postului de comandă de diferite niveluri, care sunt o combinație de mijloace tehnice (transmitere, procesare, afișare a informațiilor) și software.

Unul dintre cele mai grave deficiențe ale software-ului ASOIU este costul ridicat și fiabilitatea scăzută. Mulți experți consideră că prima dintre aceste deficiențe este o continuare a celei de-a doua. Deoarece software-ul este prin natura sa nefiabil, testarea și întreținerea acestuia reprezintă o cheltuială constantă și semnificativă.

Înainte de a analiza fiabilitatea software-ului, să clarificăm conceptele fundamentale de bază ale teoriei fiabilității.

Fiabilitatea software-ului este proprietatea de a se asigura că rezultatele corecte sunt obținute în conformitate cu un anumit algoritm într-un anumit interval de timp.

Eroare software - starea pachetului software asociată cu o funcționare defectuoasă a pachetului software și încetarea funcționării ulterioare din cauza erorilor.

Prin eroare software înțelegem o astfel de combinație de comenzi în program, atunci când este executată cu date inițiale corecte, se obține un rezultat care nu corespunde valorilor de referință specificate în documentația tehnică.

Fiabilitatea software-ului ASOIU este determinată de fiabilitatea, recuperabilitatea și stabilitatea acestuia.

Fiabilitatea software-ului este proprietatea sa de a menține capacitatea de a îndeplini corect sarcina funcției și de a rezolva sarcinile atribuite mijloacelor de calcul ale sistemului de control automat în procesul de procesare a informațiilor pe computer pentru un timp dat. În același timp, starea software-ului, în care sarcinile de prelucrare a informațiilor pe un computer sunt rezolvate corect (corect), se numește stare de lucru. Altfel, statul este numit inoperabil.

Trecerea de la o stare operabilă la o stare inoperabilă are loc sub influența defecțiunilor software. O caracteristică a unei defecțiuni software este că eliminarea acestuia se realizează prin corectarea programului sau a datelor de intrare.

O proprietate importantă a software-ului este recuperabilitatea acestuia, care este înțeleasă ca o proprietate care constă în adaptabilitatea software-ului pentru a detecta cauzele defecțiunilor software și a le elimina. Recuperarea după o defecțiune a unui program poate consta în corectarea și restabilirea textului programului, corectarea datelor, efectuarea de modificări în organizarea procesului de calcul (ceea ce este adesea necesar atunci când instrumentele de calcul funcționează în timp real).

Se știe că o defecțiune în teoria fiabilității este definită ca o defecțiune cu auto-recuperare care nu necesită intervenție externă pentru a o elimina. Cu alte cuvinte, o defecțiune este o eroare recuperabilă automat și care are un timp de recuperare destul de scurt. Prin urmare, în legătură cu fiabilitatea software-ului ACS, ar trebui să se indice în mod specific criteriul care permite clasificarea pierderii de operabilitate a complexului software ca defecțiune sau defecțiune. Ca un astfel de criteriu, luăm o anumită valoare de prag a timpului de recuperare (? în timp).

Astfel, depanarea necesită mai puțin timp și resurse decât depanarea. Într-o formă formalizată, definiția eșecului și eșecului software poate fi reprezentată ca:

Înăuntru cu< ? в пор

În s - timpul de recuperare după o defecțiune.

B o - timpul de recuperare după eșec.

Stabilitatea funcționării software-ului este capacitatea de a limita consecințele erorilor interne în programe și efectele adverse ale mediului extern (care includ defecțiuni hardware, date de intrare incorecte, erori ale operatorului și altele) și de a le rezista.

În analiza conceptelor de bază ale fiabilității software-ului sunt date definiții, defecțiuni, erori și fiabilitatea software-ului. S-a dovedit că trecerea de la o stare de lucru la o stare nefuncțională are loc sub influența defecțiunilor software. Din indicatorii de timp se poate observa că este nevoie de mai puțin timp și resurse pentru a elimina un eșec decât pentru a elimina un eșec.

1.2 Principalele cauze și simptome ale erorilor software

Principalele cauze ale erorilor software sunt:

Complexitatea mai mare a software-ului, de exemplu, în comparație cu hardware-ul computerului.

Traducerea incorectă a informațiilor de la o reprezentare la alta la nivel macro și micro. La nivel macro, la nivel de proiect, diferite tipuri de informații sunt transferate și transformate între organizații, departamente și performeri specifici în toate etapele ciclului de viață al software-ului. La nivel micro, la nivelul interpretului, informația este transformată după schema: obțineți informații, amintiți-vă, selectați din memorie, reproduceți informația.

Sursele erorilor software sunt:

Interne: erori de proiectare, erori de algoritmizare, erori de programare, calitate insuficientă a instrumentelor de protecție, erori de documentare.

Externe: erori ale utilizatorului, defecțiuni și defecțiuni ale hardware-ului computerului, distorsiuni ale informațiilor în canalele de comunicare, modificări ale configurației sistemului.

Semnele de eroare sunt:

1. Încheierea prematură a programului.

2. Creșterea timpului de execuție a programului.

3. Încălcarea secvenței de apelare a subrutinelor individuale.

4. Erori la ieșirea informațiilor provenite din surse externe, există o nepotrivire între informațiile de intrare din cauza: deformarea datelor pe mediile primare, defecțiuni și defecțiuni la echipamente, zgomot și defecțiuni în canalele de comunicație, erori în documentație.

Erori ascunse în programul însuși: eroare de calcul, eroare I/O, erori logice, eroare de manipulare a datelor, eroare de compatibilitate, eroare de interfață.

Distorsiuni ale informațiilor de intrare care urmează să fie prelucrate: distorsiuni ale datelor de pe mediile de stocare primare; defecțiuni și defecțiuni ale echipamentelor pentru introducerea datelor de pe mediile de stocare primare; zgomot și defecțiuni în canalele de comunicație la transmiterea mesajelor prin liniile de comunicație; defecțiuni și defecțiuni la echipamentele de transmitere sau de primire a informațiilor; pierderea sau denaturarea mesajelor din unitățile tampon ale sistemelor de calcul; erori în documentație; utilizat pentru pregătirea introducerii datelor; erori ale utilizatorului în pregătirea informațiilor inițiale.

Acțiuni nevalide ale utilizatorului:

1. Interpretarea greșită a mesajelor.

2. Acțiuni greșite ale utilizatorului în procesul de dialog cu software-ul.

3. Acțiunile incorecte ale utilizatorului sau, în alt mod, pot fi numite erori ale utilizatorului care apar ca urmare a documentației software de proastă calitate: descrieri incorecte ale caracteristicilor programului; descrieri incorecte ale modurilor de operare; descrieri incorecte ale formatelor de informații de intrare și de ieșire; descrieri incorecte ale mesajelor de diagnosticare.

Defecțiuni ale echipamentului instalației: duc la încălcări ale cursului normal al procesului de calcul; duce la denaturarea datelor și a textelor programelor din memoria principală și externă.

Deci, atunci când luăm în considerare principalele cauze ale defecțiunilor și defecțiunilor software, putem spune că aceste cunoștințe vă permit să luați măsurile necesare în timp util pentru a preveni defecțiunile și defecțiunile software.

1.3 Principalii parametri și indicatori ai fiabilității programelor ASOIU

Termenul de model de fiabilitate software se referă în general la un model matematic construit pentru a evalua dependența software-ului de un parametru specificat.

Parametru - valori cantitative, într-o funcție sau model matematic, alese sau estimate în condiții specifice.

Valoarea unor astfel de parametri fie se presupune a fi cunoscută, fie poate fi măsurată în cursul observațiilor sau studiului experimental al procesului de funcționare a software-ului.

Complicarea algoritmilor pentru funcționarea sistemelor automatizate duce la un volum și complexitate semnificative de software. Creșterea volumului (până la 10 5 sau mai multe instrucțiuni ale mașinii) și complexitatea software-ului fac imposibilă dezvoltarea componentelor complet fără defecte ale programelor software. Ca rezultat, software-ul este pus în funcțiune cu erori care provoacă defecțiunea software-ului. Procesul de depanare software pentru identificarea și eliminarea erorilor din programe poate fi reprezentat printr-un grafic al modificărilor ratei de eșec software o.

Orez. 1.3.1. - durata de viață a programului.

Secțiunea 1 corespunde etapelor de depanare, testare și operare de probă a software-ului. În secțiunea 2, erorile software reziduale după proiectare, corespunzătoare unei combinații destul de rare de date de intrare și depanare a erorilor. În secțiunea 3 apar noi erori, iar după mai multe modificări la pachetul software, software-ul devine învechit. După aceea, software-ul este supus înlocuirii complete, deoarece a expirat și nu îndeplinește noile condiții.

1.4 Metode de predicție a defecțiunilor software și de testare a programelor

Prevenirea erorilor este cea mai bună modalitate de a îmbunătăți fiabilitatea software-ului. Pentru implementarea acestuia a fost elaborată o metodologie de proiectare a sistemului de control care corespunde modelului spiral al ciclului de viață al software-ului. Tehnica asigură o scădere consistentă a complexității în toate etapele analizei obiectului. La descompunerea ASOIU, au fost identificate nivelurile de management al sistemului, apoi subsistemele, complexele de sarcini și așa mai departe, până la funcții și proceduri automate individuale.

Metodele de predicție și testare a software-ului pot preveni, minimiza sau elimina apariția erorilor.

Metodele de predicție și testare software includ:

1. Metode de a face față complexității sistemului.

Complexitatea sistemului este unul dintre principalele motive pentru fiabilitatea scăzută a software-ului. În general, complexitatea unui obiect este o funcție a interacțiunii dintre componentele sale. În lupta împotriva complexității software, sunt utilizate două concepte: [L.1]

Structura ierarhica. Ierarhia vă permite să împărțiți sistemul în niveluri de înțelegere. Conceptul de niveluri vă permite să analizați sistemul, ascunzând detaliile de implementare ale altor niveluri care nu sunt esențiale pentru un anumit nivel. Ierarhia vă permite să înțelegeți, să proiectați și să descrieți sisteme complexe.

Independenţă. În conformitate cu acest concept, pentru a minimiza complexitatea, este necesar să se maximizeze independența elementelor sistemului.

2. Metode pentru obținerea unei mai mari acuratețe în traducerea informațiilor.

Metodele de îmbunătățire a schimbului de informații se bazează pe introducerea diferitelor tipuri de redundanță în software-ul de sistem:

concediere temporară. Utilizarea unei părți din performanța computerului pentru a controla execuția și a restabili funcționalitatea software-ului după o defecțiune.

redundanță informațională. Dublarea unei părți a datelor din sistemul informațional pentru a asigura fiabilitatea și controlul fiabilității datelor.

Redundanța software include:

neîncrederea reciprocă - componentele sistemului sunt proiectate pe ipoteza că alte componente și datele sursă conțin erori și ar trebui să încerce să le detecteze;

detectarea și înregistrarea imediată a erorilor;

efectuarea de funcții identice de către diferite module ale sistemului și compararea rezultatelor procesării;

controlul și recuperarea datelor folosind alte tipuri de redundanță.

Fiecare dintre metode îmbunătățește fiabilitatea software-ului și toleranța la erori. Este imposibil să se determine care dintre aceste metode este mai bună, deoarece fiecare metodă se bazează pe propriile principii și concepte. Prin urmare, ambele metode pot fi utilizate.

O etapă importantă a ciclului de viață al software-ului, care determină calitatea și fiabilitatea sistemului, este testarea. Testarea este procesul de rulare a programelor cu intenția de a găsi erori. Etape de testare: controlul unui modul de program separat separat de alte module ale sistemului; controlul interfețelor (conexiunilor) între părți ale sistemului (module, componente, subsisteme); monitorizarea performanței funcțiilor automatizate de către sistem; verificarea conformității sistemului cu cerințele utilizatorilor, precum și corectitudinea documentației, execuția programului în strictă conformitate cu instrucțiunile.

Există două strategii în proiectarea testelor: testarea conform specificațiilor (documentația) fără a se preocupa de textul programului și testarea față de textul programului fără a se preocupa de specificații. Un compromis rezonabil se află undeva la mijloc, deplasându-se într-o direcție sau alta în funcție de funcțiile îndeplinite de un anumit modul, complex sau subsistem.

Calitatea pregătirii datelor inițiale pentru testare afectează grav eficiența procesului în ansamblu și include:

1. Termeni de referință.

2. Descrierea sistemului.

3. Manual de utilizare.

4. Textul sursă.

5. Reguli de construcție (standarde) de programe și interfețe.

6. Testarea criteriilor de calitate.

7. Valorile de referință ale datelor inițiale și rezultate.

8. Resurse dedicate, determinate de resursele financiare disponibile.

Cu toate acestea, testarea exhaustivă a tuturor ramurilor algoritmului oricărui program pentru toate variantele datelor de intrare este practic imposibilă. Prin urmare, durata fazei de testare este o problemă pur temporară. Având în vedere că resursele reale ale oricărui proiect sunt limitate de buget și timp, se poate susține că arta testării constă în selectarea testelor cu impact maxim.

Erorile în programe și date pot apărea în orice etapă a testării, precum și în timpul funcționării sistemului. Informațiile înregistrate și prelucrate trebuie utilizate pentru a identifica abaterile de la cerințele clientului sau de la termenii de referință. Pentru a rezolva această problemă, se utilizează un sistem de gestionare a configurației versiunilor componentelor software, o bază pentru documentarea testelor, a rezultatelor testelor și a corecțiilor de program finalizate. Mijloacele de acumulare a mesajelor despre erori, erori, propuneri de modificări, corecții efectuate și caracteristicile versiunii sunt principalele pentru gestionarea dezvoltării și întreținerii complexului software și constau în jurnalele:

Modificări propuse.

Defecte găsite.

ajustări aprobate.

Modificări implementate.

versiuni personalizate.

Acest capitol analizează principalele cauze și simptome ale erorilor, prezintă principalii parametri și indicatori ai fiabilității software-ului. Sunt, de asemenea, luate în considerare metode de predicție a defecțiunilor software și de testare a programelor pentru a îmbunătăți fiabilitatea. Pentru a evalua fiabilitatea software-ului, se folosesc modele speciale pe baza parametrilor și indicatorilor indicați mai sus.

2. Analiza modelelor de evaluare a fiabilității software-ului

Modelele matematice existente ar trebui să evalueze caracteristicile erorilor din programe și să prezică fiabilitatea acestora în timpul funcționării. Modelele sunt de natură probabilistică, iar fiabilitatea prognozelor depinde de acuratețea datelor inițiale și de profunzimea prognozei în timp.

Aceste modele matematice sunt concepute pentru a evalua:

1. Indicatori de fiabilitate ai pachetului software în procesul de depanare;

2. Numărul de erori rămase nedetectate;

3. Timpul necesar pentru a detecta următoarea eroare într-un program care rulează;

4. Timpul necesar pentru a identifica toate erorile cu o probabilitate dată.

Există o serie de modele matematice:

Modelul exponențial de modificare a erorii în funcție de timpul de depanare.

Model cu schimbare discretă care ia în considerare timpul de creștere discretă dintre defecțiuni ca funcție liniară a timpului de testare și de testare.

modelul Schumann. Datele de intrare pentru modelul Schumann sunt colectate în timpul testării software-ului la intervale de timp fixe sau aleatorii.

Model La Padula. Conform acestui model, executarea unei succesiuni de teste în m etape. Fiecare etapă se încheie cu corecții ale software-ului.

Modelul Dzhelinsky-Moranda. Datele inițiale sunt colectate în timpul testării software-ului. În acest caz, timpul până la următoarea defecțiune este fixat.

Model Schick-Wolverton. Modificarea modelului Dzhelinsky-Moranda pentru cazul apariției mai multor erori pe intervalul considerat.

Modelul Musa. În timpul testării, se înregistrează timpul de execuție a programului (test rulare) până la următoarea eroare.

Modelul probabilităților tranzitorii. Acest model se bazează pe un proces Markov care rulează într-un sistem discret cu timp continuu.

Model Mills. Utilizarea acestui model implică necesitatea introducerii artificiale a unui anumit număr de erori cunoscute în program înainte de a începe testarea.

modelul lui Lipov. O modificare a modelului Mills care ia în considerare probabilitatea detectării unei erori atunci când se utilizează un număr diferit de teste.

Un model simplu intuitiv. Utilizarea acestui model presupune testarea de către două grupuri de programatori independent unul de celălalt, folosind suite de testare independente.

Modelul Corcoran. Modelul utilizează probabilități diferite de eșec pentru diferite tipuri de erori.

Modelul Nelson. Acest model, atunci când calculează fiabilitatea software-ului, ia în considerare probabilitatea de a alege un set de teste specifice pentru următoarea execuție a programului.

Cu un număr atât de mare de modele, principalele sunt modelele exponențiale și care se schimbă discret.

2.1 Model în schimbare discretă

În această lucrare, un model cu schimbare discretă este un model care se bazează pe o creștere discretă a timpului dintre defecțiuni. Acest model se bazează pe următoarele ipoteze:

1. Eliminarea erorilor din program duce la o creștere a timpului dintre defecțiuni T cu aceeași valoare egală cu:

T (1) =T (2) =…=T (i) = const (2.1.1)

T (i) = T (i) - T (i-1) (2.2.2)

2. Timpul dintre două eșecuri consecutive:

i = t i - t i -1 (2.1.3)

este o variabilă aleatoare care poate fi reprezentată ca suma a două variabile aleatoare:

i = i -1 + I (2.1.4)

unde i sunt variabile aleatoare independente care au aceeași așteptare matematică M() și abateri standard.

3. Intervalul de timp inițial 0 este comparabil cu variabila aleatoare 0 , adică. 0 0 , deoarece în perioada inițială de funcționare a programelor, eșecurile acestora apar foarte des.

Pe baza celei de-a doua ipoteze, intervalul dintre defecțiunile i-a (i-1) - m poate fi determinat prin relația:

i = i -1 + i = 0 + j (2.1.5)

din care puteți obține raportul pentru determinarea timpului de apariție a eșecului m-a în program:

t m = i = (0 + j) (2.1.6)

Pe baza celei de-a treia ipoteze, relațiile rezultate vor lua forma:

i = 0 + j = j (2.1.7)

t m = (0 + j) = i j (2.1.8)

În aceste ipoteze, timpul mediu între (m-1) - m și m-a eșec al programului este egal cu:

T0 (m) = M(m -1) = M(j) = i j = m M(). (2.1.9)

Timpul mediu până la apariția defecțiunii a m-a poate fi determinat de raportul:

T m = M(t m ) = i jk) = M(). (2.1.10)

2.2 Distribuția exponențială

Să trecem acum direct la analiza distribuției exponențiale adecvate.

Distribuția considerată este caracterizată de un număr de proprietăți, cum ar fi:

1. Erorile din pachetul software sunt independente și apar la întâmplare. Această proprietate caracterizează invarianța în timp a intensității manifestării și detectării erorilor (adică osh =const) pe parcursul întregului timp de execuție a programului (=t n -t 0).

2. Intensitatea manifestării și detectării erorilor osh (rata de eșec) este proporțională cu numărul de erori rămase în el:

()= Kn 0 () (2.2.1)

unde K - coeficient de proporționalitate, ținând cont de viteza reală a computerului și de numărul de comenzi din program.

3. În procesul de corectare a erorilor de program, nu sunt generate erori noi. Aceasta înseamnă că rata de corectare a erorilor dn/dt va fi egală cu rata de detectare a acestora:

Atunci n 0 ()= N 0 - n(). (2.2.3)

Pe baza ipotezelor prezentate mai sus, obținem:

n()=N0 (1-e - K); (2,5)

Dacă acceptăm asta, obținem:

2.3 Metodologie de evaluare a fiabilității programelor după numărul de erori corectate

Fie N 0 numărul de erori din program înainte de testare.

n() - numărul de erori eliminate în timpul testării (testării) programului;

n 0 () - numărul de erori rămase în program la sfârșitul testului.

Atunci n 0 ()= N 0 - n().

Pe baza ipotezelor introduse în paragraful 2.2.1, și anume: și ()= Kn 0 () obținem:

K este un coeficient care ține cont de viteza computerului.

Soluția acestei ecuații diferențiale în condițiile inițiale t=0 și =0 este:

n()=N0 (1-e-K); (2.3.2)

n0 ()=N0-n()=N0e-K. (2.3.3)

Fiabilitatea programului în funcție de rezultatele testelor în timp poate fi caracterizată prin timpul mediu dintre defecțiuni, egal cu:

Dacă introducem valoarea inițială a timpului mediu dintre eșecuri înainte de testare, egală, atunci obținem:

ceea ce arată că MTBF crește pe măsură ce erorile sunt identificate și corectate.

În practică, în procesul de corectare a programului, pot apărea în continuare erori noi. Fie B factorul de reducere a erorii, definit ca raportul dintre intensitatea reducerii erorii și intensitatea manifestării lor sau rata de eșec, adică:

Dacă notăm cu m - numărul defecțiunilor detectate, iar M 0 - numărul de defecțiuni care trebuie să apară pentru a putea identifica și elimina n erori corespunzătoare, adică:

atunci timpul mediu dintre defecțiuni și numărul de defecțiuni detectate este determinat de următoarele relații:

Dacă acceptăm asta, obținem:

Pentru utilizare practică, interesează numărul de erori m, care trebuie detectat și corectat pentru a crește timpul mediu dintre defecțiuni de la T 01 la T 02 . Acest indicator poate fi obținut din următoarele relații:

Deci, evaluarea fiabilității programelor în funcție de numărul de erori corectate este determinată de formula:

2.4 Metodologia de evaluare a fiabilității programelor în funcție de timpul de testare

Timpul de testare suplimentar necesar pentru a asigura o creștere a timpului mediu dintre defecțiuni de la T 01 la T 02 este determinat din relațiile:

unde T 01 și T 02 sunt determinate conform formulei (2.3.9):

Evaluarea fiabilității programelor în ceea ce privește timpul de testare se determină după formula:

2.5 Metodologia de evaluare a fiabilității programelor pentru timpul de funcționare

Timpul dintre eșecurile succesive - o variabilă aleatoare T (i) poate fi reprezentată ca suma a două variabile aleatoare:

T (i) = T (i -1) + T (i) (2.5.1)

Aplicând succesiv (3.3.1) la toate perioadele de timp de funcționare dintre defecțiuni, obținem :

T(i) = T(0) + T(?) (2.5.2)

Variabila aleatoare T n - timpul de funcționare înainte de apariția celei de-a n-a defecțiuni a programului - este egală cu:

T n = T (i) = (2.5.3)

Introducem urmatoarele ipoteze:

1) toate variabilele aleatoare T () sunt independente și au aceleași așteptări matematice m? t și abaterile standard? ? t

2) variabila aleatoare T (0) este neglijabilă în comparație cu suma T (?)

Următoarele considerații pot servi ca bază pentru a doua ipoteză: în perioada inițială a funcționării programului, erorile apar foarte des, adică timpul T (0) este scurt. Suma (2.5.3) crește rapid pe măsură ce n crește, iar fracția T(0) scade rapid. Vom presupune că T (0) ? T(0) . Conform celei de-a doua ipoteze, avem:

T(n)=T(?). (2.5.4)

Cu același T (?), timpul de funcționare între (n-1) și n defecțiuni - o variabilă aleatoare T (n) - are o așteptare matematică:

mt(n)=M=nm? t (2.5.6)

T(n)=? ? t (2.5.7)

Pentru o variabilă aleatoare T n, așteptarea matematică este:

M? t (2.5.8)

și abaterea standard:

T; (2.5.9)

Pentru a calcula valorile și, este necesar să se găsească estimări statistice ale caracteristicilor numerice ale diferenței aleatoare T (i) din datele privind eșecurile programului în perioada de observație t n:

n n este numărul de eșecuri ale programului pentru timpul de funcționare (0, t n).

Având în vedere că la t >t n numărul defecțiunilor este n n >> 1, din (2.5.8) și (2.5.9) avem:

m t (n) ? m? t , (2.5.12)

T(n)=? ? t n ; (2.5.13)

Deoarece variabilele aleatoare T (n) și T n conform (2.5.4) și (2.5.5) sunt egale cu sumele multor variabile aleatoare, T (n) și T n pot fi considerate distribuite normal cu așteptări matematice și varianțele determinate de (2.5.6) - (2.5.9), (2.5.12) și (2.5.13). Întrucât timpul de operare este pozitiv, în practică se utilizează distribuția normală trunchiată pe intervalul (0,?). De obicei factorul de normalizare este c?1.

Cu n>n n, densitatea distribuției timpului de funcționare între (n-1) și n defecțiuni succesive:

f (n) (?) = , (2.5.14)

Unde? numărat din momentul ultimei (n-1) defecțiuni.

Concluzie

Lucrarea a arătat că fiabilitatea software-ului este de zece ori mai mică decât fiabilitatea hardware. Cerințele pentru fiabilitatea software-ului este definirea performanței necesare a misiunilor de luptă pentru cel puțin 1872 de ore.

Analiza arată că cel mai mare impact asupra fiabilității software-ului este oferit de erorile interne și erorile care se găsesc la începutul funcționării programelor. Pe baza acesteia, a fost efectuată o analiză a modelelor de fiabilitate, a metodelor de calcul și evaluare a fiabilității software-ului. Cu ajutorul acestei analize, pe baza unei metode discrete și exponențiale, a fost calculat timpul necesar pentru testarea software-ului pentru a crește durata de viață a programului.

Bibliografie

Predicția fiabilității software-ului

1. V.V. Lipaev Proiectare software pentru sisteme automate de control. (inginerie de sistem, arhitectură, tehnologie). M., „Bufnițe. radio”, 1977.

2. R.S. Zakharova Întrebări de bază ale teoriei și practicii fiabilității.

3. V.A. Blagodatskikh, V.A. Volnin, K.F. Poskakalov Standardizarea dezvoltării software.

4. A.A. Voronov Fundamente teoretice pentru construirea sistemelor automate de control. Elaborarea termenilor de referință.-M.: Nauka, 1997.

5. Fundamentele teoriei aplicate a fiabilității sistemelor automate de control. Manual, Tver, VA PVO, 1995, n/s 32. 965.0-75. V.M. Ioanov şi colab., inv. nr. 8856.

6. B.N. Gorevici. Calculul indicatorilor de fiabilitate a sistemelor de arme și a elementelor redundante. Note de curs, VA PVO, 1998, n/s 68.501.4, G68, inv. №9100

Găzduit pe Allbest.ru

Documente similare

Analiza metodelor de evaluare a fiabilității software-ului în toate etapele ciclului de viață, clasificarea și tipurile acestora, cerințe. Software cu versiuni multiple. Modele și algoritmi moderni pentru analiza fiabilității software-ului.

teză, adăugată 11.03.2013


Acțiuni care sunt efectuate în proiectarea AIS. Tehnologii de cluster, tipurile lor. Metode de calcul a fiabilității în diferite etape de proiectare a sistemelor informaționale. Calculul fiabilității cu redundanță. Testarea software-ului pentru fiabilitate.

lucrare de termen, adăugată 07.02.2013


Software-ul ca produs. Principalele caracteristici ale calității software-ului. Concepte de bază și indicatori ai fiabilității software. Factori și metode destabilizatoare pentru asigurarea fiabilității funcționării software-ului.

prelegere, adăugată 22.03.2014


Model de fiabilitate software ca model matematic de evaluare a dependenței fiabilității software de unii parametri specifici, analiza tipurilor. Caracteristici generale ale unui model intuitiv simplu, analiza domeniilor de utilizare.

prezentare, adaugat 22.03.2014


Solicitări ale clienților pe zonă de posibile solicitări către server. Un program pentru prezicerea comportamentului fiabilității software-ului bazat pe metoda Monte Carlo. Influența numărului de programe client asupra comportamentului sistemului software client-server.

test, adaugat 12.03.2010


Caracteristici ale modelelor analitice și empirice de fiabilitate software. Proiectarea unui algoritm de testare și dezvoltarea unui program pentru determinarea fiabilității software prin modele Schumann, Mills, Lipov, folosind limbajul C# și VisualStudio 2013.

lucrare de termen, adăugată 29.06.2014


Fiabilitatea sistemului de control ca ansamblu de fiabilitate a mijloacelor tehnice, computerului, software-ului și personalului. Calculul fiabilității sistemelor tehnice, modurilor de defecțiune a ACS și TSA, creșterea fiabilității și a cauzelor defecțiunilor ACS.

curs de prelegeri, adăugat 27.05.2008


Metode exacte și aproximative pentru analiza fiabilității structurale. Criterii de evaluare a fiabilității structurale prin modelare statistică. Dezvoltarea unui algoritm și program pentru calcularea fiabilității structurale. Ghid pentru lucrul cu programul.

teză, adăugată 17.11.2010


Declarație despre problema fiabilității software și cauzele acesteia. Caracteristici de fiabilitate hardware. Programul de calculator ca obiect de cercetare, fiabilitatea și corectitudinea acestuia. Modelul secvenței testului Bernoulli.

rezumat, adăugat 21.12.2010


Fiabilitatea ca caracteristică a calității software (SW). Metodologia de calcul a caracteristicilor de fiabilitate a software-ului (cum ar fi timpul până la eșec, disponibilitate, probabilitatea de eșec), caracteristici de predicție a modificărilor acestora în timp.