11.1. Funcționalitatea și fiabilitatea ca criterii de calitate obligatorii pentru software.
În cursul precedent, am analizat toate etapele de dezvoltare a PS, cu excepția certificării sale. În același timp, nu ne-am atins pe asigurarea calității SS în conformitate cu specificațiile de calitate (a se vedea. Curs 4). Adevărat, în punerea în aplicare a specificației funcționale a PS, am discutat astfel aspectele principale ale asigurării criteriului de funcționalitate. Declarând fiabilitatea sa substație atributul principal (a se vedea alin. 1 curs), am ales de prevenire a erorilor ca principala abordare pentru a asigura fiabilitatea stației (a se vedea. Capitolul 3) și a discuta despre realizarea ei în diferite stadii de dezvoltare a SS. Astfel, s-a manifestat teza despre funcționalitatea obligatorie și fiabilitatea PS ca criterii de calitate.
Cu toate acestea, specificarea calității PS poate conține caracteristici suplimentare ale acestor criterii, a căror furnizare necesită o discuție specială. Aceste întrebări sunt subiectul acestei prelegeri. Furnizarea altor criterii de calitate va fi discutată în următoarea conferință.
Mai jos vom discuta despre furnizarea de primitive de calitate PS, exprimând criteriile pentru funcționalitatea și fiabilitatea PS.
11.2. Asigurarea finalizării software-ului.
Completitudinea PS este un primitiv general al calității PS pentru expresia și funcționalitatea și fiabilitatea SM, iar pentru funcționalitate este singura primitivă (vezi Lecture 4).
Funcționalitatea MS este determinată de specificațiile sale funcționale. Finalizarea PS ca primitiva a calitatii sale este o masura a modului in care aceasta specificatie este implementata in acest PS. Furnizarea în întregime a acestui primitiv înseamnă implementarea fiecăreia dintre funcțiile definite în specificația funcțională, cu toate detaliile și caracteristicile specificate în aceasta. Toate procesele tehnologice de mai sus arată cum se poate face acest lucru.
Cu toate acestea, în PS caietul de sarcini de calitate poate fi determinată prin mai multe niveluri de a implementa funcționalitatea PS: poate fi determinată de o versiune simplificată (inițială sau de pornire), care ar trebui să fie puse în aplicare în primul rând, poate fi de asemenea definite și mai multe versiuni intermediare. În acest caz, apare o problemă tehnologică suplimentară: organizarea creșterii funcționalității stației. Este important de menționat că dezvoltarea unei versiuni simplificate a PS nu este dezvoltarea prototipului său. Prototipul este dezvoltat pentru a înțelege mai bine condițiile de aplicare a viitorului SS-ului [11.1], pentru a clarifica descrierea externă. Este proiectat pentru utilizatori selectați și, prin urmare, poate fi foarte diferit de PS necesar, nu numai funcțiile efectuate, ci și caracteristicile interfeței cu utilizatorul. Versiunea simplificată a PS necesar trebuie să fie proiectată pentru utilizare practică de către utilizatorii pentru care este destinată. Prin urmare, principiul de bază al asigurării funcționalității PS este de la bun început să se dezvolte SS în așa fel ca și în cazul în care SS este necesară în întregime, atâta timp cât dezvoltatorii nu vor trebui să se ocupe de acele părți sau componente ale SS-ului, punerea în aplicare a care pot fi puse în funcție de specificațiile calității sale. Astfel, atât descrierea externă cât și descrierea arhitecturii PS ar trebui dezvoltate în totalitate. Puteți amâna doar punerea în aplicare a subsistemelor software în arhitectura anumitor PS dezvoltate, care operație nu este necesară în versiunea inițială a MS. Punerea în aplicare a subsistemelor de software-ul în sine este cel mai bine realizat prin realizarea constructivă scop, lăsând în versiunea inițială a SS imitatori corespunzătoare acelor module software a căror funcționare în această versiune nu este necesară. Este, de asemenea, posibil să se simplifice implementarea unor module software, fără a se pune în aplicare anumite detalii ale funcțiilor corespunzătoare. Cu toate acestea, astfel de module din punct de vedere tehnologic sunt mai bine considerate ca propriile tipuri de simulatoare (deși mult avansate).
În virtutea existente în erorilor PS dezvoltate realizate asigurând în același timp caracterul complet al funcționalității sale (în conformitate cu specificația calității sale) poate fi, de fapt, la fel cum era de așteptat. Putem spune doar că această perfecțiune este realizat cu o probabilitate determinată de volumul și calitatea testării. Pentru a crește această probabilitate, este necesar să continuăm testarea și depanarea PS. Cu toate acestea, o astfel de evaluare a probabilității este o sarcină foarte specifică (ținând cont de faptul că expresia disponibilă în eroare PS este o funcție a datelor sursă), care este încă în așteptare pentru cercetarea teoretică relevantă.
11.3. Asigurarea corectitudinii software-ului.
Furnizarea acestui primitiv este asociată cu acțiuni asupra valorilor tipurilor reale (mai precis, cu valori reprezentate cu o anumită eroare). Pentru a furniza precizia necesară în calcularea valorii unei funcții este de a obține această valoare cu o eroare care nu depășește limitele specificate. Tipurile de erori, metodele de estimare a acestora și metodele de obținere a preciziei necesare (așa-numitele calcule aproximative) sunt tratate prin matematică computațională [11.1, 11.2]. Aici acordăm atenție doar unei anumite structuri a erorii: depinde eroarea valorii calculate (eroarea totală)
din eroarea metodei de calcul utilizate (în care includem inexactitatea modelului utilizat)
din eroarea de reprezentare a datelor utilizate (din așa-numita eroare nerecuperabilă),
din eroarea de rotunjire (inexactități în operațiile utilizate în metodă).
Trimiteți-le prietenilor: