software de calitate corespunde ideii că programul face față cu succes tuturor sarcinilor care îi sunt atribuite și nu pune probleme nici utilizatorilor finali, nici superiorilor acestora, nici serviciului de suport, nici specialiștilor în vânzări. Și pentru dezvoltatori înșiși, crearea unui program de înaltă calitate aduce mult mai multă plăcere.

Dacă cereți unui grup de oameni să-și dea părerea despre ce este un software de calitate, puteți obține următoarele răspunsuri:

• Este ușor de utilizat.
• Demonstrează bine performanţă.
• Nu există erori în ea.
• Nu corupă datele utilizatorului în timpul erorilor.
• Poate fi folosit pe diferite platforme.
• Poate funcționa 24 de ore pe zi și 7 zile pe săptămână.
• Este ușor să adăugați funcții noi.
• Satisface nevoile utilizatorilor.
• Este bine documentat.

Toate acestea au într-adevăr o legătură directă cu calitatea software-ului. Dar aceste răspunsuri evidențiază caracteristici care sunt importante pentru un anumit utilizator, dezvoltator sau grup de astfel de persoane. Pentru a satisface nevoile tuturor părților (utilizatori finali, clienți, dezvoltatori, administratori ai sistemelor în care va lucra, organizații de reglementare etc.), pentru a obține o poziție puternică a software-ului dezvoltat pe piață și a crește potențialul de dezvoltare a acestuia, este necesar să se țină cont de întregul set de caracteristici software, importante pentru toți părțile interesate.

Răspunsurile de mai sus arată că calitatea software-ului poate fi descrisă printr-un set mare de caracteristici eterogene. Această abordare a descrierii conceptelor complexe se numește holistică(din cuvântul grecesc ????, întreg). Nu oferă un cadru conceptual unificat pentru a lua în considerare problemele implicate, așa cum face sistem complet concepte (de exemplu, mecanica newtoniană în fizică sau teoria clasică a computabilității bazată pe mașinile Turing), dar măcar ne permite să nu pierdem nimic esențial.

Principiile generale pentru asigurarea calității proceselor de producție în toate sectoarele economiei sunt reglementate de un set de standarde ISO 9000. Cele mai importante standarde pentru dezvoltarea de software în componența sa sunt următoarele:

• ISO 9000:2000 Sisteme de management al calității - Fundamente și vocabular .

  Sisteme de Management al Calității - Fundamente și Vocabular. (Analogic - GOST R-2001).

• ISO 9001:2000 Sisteme de management al calitatii - Cerinte. Modele pentru asigurarea calității în proiectare, dezvoltare, producție, instalare și service .

  Sisteme de management al calitatii - Cerinte. Modele de asigurare a calității în proiectare, dezvoltare, comercializare, instalare și întreținere.

  Definește reguli generale pentru asigurarea calității rezultatelor în toate procesele ciclului de viață. (Analogic - GOST R-2001).

  • Acest standard evidențiază următoarele procese:
    • Control de calitate.
    • Managementul resurselor.
    • Dezvoltarea sistemului de management.
    • Cercetare de piata.
    • Design de produs.
    • Achizitii.
    • Productie.
    • Asigurarea de servicii.
    • Protecția produsului.
    • Evaluarea nevoilor clienților.
    • Suport in comunicarea cu clientii.
    • Suportul comunicațiilor interne.
    • Managementul documentelor.
    • Mentinerea evidenta a activitatilor.
    • Planificare.
    • Instruire.
    • Audituri interne.
    • Evaluări ale managementului.
    • Monitorizare si masuratori.
    • Managementul neconformității.
    • Imbunatatire continua.
    • Managementul și dezvoltarea sistemului în ansamblu.
  • Fiecare proces trebuie să aibă planuri de dezvoltare a procesului care să conțină cel puțin următoarele secțiuni:
    • Proiectarea procesului.
    • Documentarea procesului.
    • Implementarea procesului.
    • Suport proces.
    • Monitorizarea procesului.
    • Administrarea procesului.
    • Îmbunătățirea procesului.
  • Pe lângă sprijinirea și dezvoltarea unui sistem de procese care vizează satisfacerea nevoilor clienților și utilizatorilor,

Abordări ale calității software

Să clasificăm diferite abordări ale calității software-ului folosind două dimensiuni.

Prima dimensiune este orientată fie pe produs, fie pe proces. Pentru a îmbunătăți calitatea software-ului, vă puteți concentra pe calitatea produsului în sine, de exemplu, făcându-l mai ușor de utilizat. O abordare alternativă este îmbunătățirea procesului de dezvoltare, cu presupunerea că, cu cât procesul este mai bun, cu atât calitatea software-ului este mai bună.

A doua dimensiune se referă fie la conformitate, fie la îmbunătățire. Prin conformitate înțelegem respectarea oricărui standard. Îmbunătățirea vizează trecerea la metode și practici mai bune pentru a îmbunătăți calitatea.

ISO 9126 este un standard de calitate a produsului care definește atributele și caracteristicile calității, inclusiv măsurători pentru cuantificarea acestor caracteristici;

„practică îmbunătățită” este, de exemplu, management îmbunătățit al configurației software, inspecție, testare etc.;

ISO 9000 este un set de standarde care declară cerințele pentru sistemele calității. Din perspectiva dezvoltării software, cele mai utile sunt Ghidul de aplicare a ISO 9001 în dezvoltarea, livrarea și întreținerea software-ului;

Metodele de îmbunătățire a procesului de dezvoltare software oferă o scară de niveluri și cerințe de conformitate prin care o companie de calculatoare poate fi plasată la acea scară. Cele mai cunoscute și populare două metode sunt:

modelul de maturitate a procesului de dezvoltare software - Modelul de maturitate a capabilităților pentru software (CMM), propus de Institutul de Inginerie Software (SEI);

identificarea oportunităților și îmbunătățirea procesului de creare a software-ului. ISO/IEC 15504 Îmbunătățirea proceselor software și determinarea capacității (SPICE).

Două afirmații critice stau la baza atingerii calității.

• Calitatea începe cu satisfacerea nevoilor dezvoltatorilor.
• Calitatea este dovedită prin satisfacerea nevoilor utilizatorilor.

Abordările pentru atingerea calității sunt:

• calitatea se realizează cu ajutorul dezvoltatorilor calificați, aderarea strictă la procese și abordări tehnologice de succes;
• calitatea se realizează prin înțelegerea pe deplin a tuturor acțiunilor și schimbărilor. Nici o singură linie din program nu ar trebui adăugată sau schimbată fără o înțelegere completă a ce, de ce și cum se face;
• calitatea este obținută prin testarea amănunțită a programului înainte ca acesta să fie pus la dispoziția utilizatorului;
• atingerea calității trebuie planificată;
• Obținerea calității este responsabilitatea fiecărui dezvoltator.

Caracteristici de calitate software

În prezent, nu există criterii general acceptate pentru calitatea software-ului.

Standardul ISO 9000-3, clauza 6.4.1

Definiția clasică a calității este aceea că produsul software dezvoltat își confirmă specificația, iar specificația trebuie să fie orientată către caracteristicile pe care le dorește clientul.

Standardele moderne clarifică conceptul de calitate prin introducerea unui set de caracteristici și caracteristici care îi afectează capacitatea de a satisface nevoile specificate ale utilizatorilor. Să enumerăm o serie de astfel de caracteristici [Zhogolev 1996].

Funcționalitate (adecvare, acuratețe, interoperabilitate, consecvență, securitate). Funcționalitatea este capacitatea unui produs software de a îndeplini un set de funcții care satisfac nevoile specificate sau implicite ale utilizatorului. Setul de astfel de funcții este definit în descrierea externă a produsului software.

Fiabilitate (completitudine, stabilitate, recuperabilitate).

Comoditate (înțelegere, ușurință în utilizare, ergonomie). Comoditatea reprezintă caracteristicile unui produs software care permit reducerea la minimum a eforturilor utilizatorului de a pregăti datele inițiale, de a utiliza produsul software și de a evalua rezultatele obținute, precum și de a evoca emoții pozitive ale unui utilizator specific sau implicit.

Eficiență (în termeni de timp și resurse). Eficiența este raportul dintre nivelul serviciilor oferite de un produs software utilizatorului în condiții date și cantitatea de resurse utilizate.

Mentenabilitate (ușurință de analiză, schimbare, stabilitate, verificabilitate). Mentenabilitatea este caracteristicile unui produs software care minimizează efortul necesar pentru a face modificări pentru a elimina erorile din acesta și pentru a-l modifica în conformitate cu nevoile în schimbare ale utilizatorilor.

Portabilitate (adaptabilitate, flexibilitate de instalare, consecvență cu standarde și reguli, înlocuire). Portabilitatea este capacitatea unui produs software de a fi transferat dintr-un mediu în altul, în special de la o arhitectură hardware la alta.

Calitate bună (organizare rațională, atenție). Să aruncăm o privire mai atentă la cele două caracteristici cele mai interesante.

Fiabilitatea este capacitatea unui program de a îndeplini anumite funcții fără defecțiuni în condiții date pentru o anumită perioadă de timp, cu o probabilitate suficient de mare. Un produs software de încredere nu exclude prezența erorilor în el. Este important aici ca erorile în aplicarea practică în anumite condiții să apară destul de rar. Gradul de fiabilitate este caracterizat de probabilitatea ca un produs software să funcționeze fără defecțiuni pentru o anumită perioadă de timp.

Există următoarele abordări pentru asigurarea fiabilității:

• prevenirea erorilor;
• autodetecția erorilor;
• autocorectarea erorilor;
• asigurarea tolerantei la erori.

Bunătatea programului constă în faptul că programul este organizat în mod rezonabil și rațional, cu o organizare destul de bine gândită a fluxurilor de control și a fluxurilor de informații și nu este prea complicat. Conceptul de factor de calitate a fost introdus de Pottosin [Pottosin 1997] pentru a evalua meritele interne ale implementării programului din punct de vedere tehnic. Pottosin introduce patru clase de criterii de calitate pentru programe.

Criterii cantitative asociate cu diferite metode de evaluare (metrice) a complexității programelor. Să indicăm exemple de caracteristici numerice.

Măsurile Halstead [Halstead 1981], care includ o serie de formule care evaluează lungimea, volumul, nivelul și conținutul intelectual al programelor.

Estimarea complexității graficului de control al unui program. Un fragment de program poate fi evaluat prin numărul ciclomatic al graficului său de control, care este egal cu m - n + 2, unde m este numărul de arce, an este numărul de vârfuri ale graficului de control. Se crede că numărul ciclomatic nu trebuie să depășească 10.

Evaluarea modularizării programului. O astfel de evaluare ar trebui să conțină mai multe criterii. De exemplu, complexitatea unui modul este evaluată de totalitatea complexității procedurilor definite în acesta și de complexitatea conexiunilor modulului cu alte module pentru importul și exportul de entități definite.

Criterii genetice asociate cu originea programului și disciplina creării acestuia.

Criterii structurale legate de evaluarea organizației manageriale în program și reflectarea organizației manageriale în textul programului.

Criterii pragmatice legate de evaluarea măsurii în care textul programului îndeplinește scopul programului. Se formulează o listă de excese care nu ar trebui să existe în programele bune, de exemplu, redundanța de calcul.

Evaluarea calității procesului de dezvoltare

Cererea de eficiență și flexibilitate de la același program este

este ca și cum ai căuta o soție fermecătoare și modestă.

Aparent, ar trebui să ne oprim la unul din două lucruri.

D. Weinberg

La începutul acestei secțiuni, am observat că există două abordări care pot fi utilizate pentru a evalua calitatea unui produs software.

• Evaluați calitatea produsului final.
• Evaluați calitatea procesului de dezvoltare.

Calitatea produsului final poate fi evaluată prin testare și exploatare. Timpul ar trebui alocat pentru aceasta după finalizarea lucrării principale a programului. Dar a doua abordare ar trebui să devină parte a strategiei pe termen lung a companiei.

Modelul de maturitate al procesului de dezvoltare software

Modelul definește cinci niveluri de maturitate organizațională (http://www.sei.cmu.edu/cmm).

Primul nivel. La acest nivel, procesul de dezvoltare se caracterizează printr-o absență virtuală a proceselor de management. Succesul proiectului depinde de eforturile individuale, de calitățile personale și chiar de eroismul participanților la proiect.

Nivel repetabil. La acest nivel de maturitate, compania ar trebui să aibă procese de management de bază pentru a urmări costul proiectului, programul și funcționalitatea. Nivelul se caracterizează prin faptul că managementul proiectelor se bazează pe experiența acumulată și succesele obținute anterior vor fi repetate în aplicații similare.

Un anumit nivel. Procesul de dezvoltare software (atât la nivel de management, cât și de inginerie) este documentat, standardizat și integrat în întreaga organizație. Procesul încetează să mai depindă de calitățile individuale ale dezvoltatorilor individuali și nu poate aluneca la niveluri inferioare în situații de criză.

Nivel gestionat. Compania stabilește indicatori cantitativi detaliați pentru procesul de dezvoltare și calitatea produsului. Atât procesul de dezvoltare, cât și produsele sunt de înțeles și controlat.

Nivel de optimizare. Îmbunătățirea continuă a procesului de dezvoltare pe baza analizei rezultatelor proceselor curente și a aplicării de idei și tehnologii inovatoare.

Identificarea oportunităților și îmbunătățirea procesului de creare a software-ului

Acest model este foarte apropiat de modelul de maturitate, dar nivelurile de capacitate pot fi aplicate nu numai organizației în ansamblu, ci și proceselor individuale. Modelele de acest tip sunt adesea numite continue. În modelele continue, un proces poate fi la un nivel de maturitate scăzut și altul la un nivel de maturitate ridicat. Standardul definește șase niveluri de maturitate a procesului.

Nivelul 0: Procesul nu rulează.

Nivelul 1. Proces de execuție.

Nivelul 2. Proces gestionat.

Nivelul 3. Proces stabilit.

Nivelul 4: Proces previzibil.

Nivelul 5. Proces de optimizare.

La evaluarea și îmbunătățirea calității proceselor se realizează sarcinile descrise mai jos [Terehov, Tuñon 1999].

Compararea procesului de dezvoltare software existent într-o organizație dată cu modelul descris în standard. Analiza rezultatelor face posibilă determinarea punctelor forte și a punctelor slabe ale procesului, a riscurilor interne ale acestuia.

Evaluarea posibilității de îmbunătățire a unui proces dat pe baza identificării capacităților actuale.

Implementarea tehnică a sarcinilor atribuite pe baza obiectivelor formulate de îmbunătățire a procesului. După aceasta, întregul ciclu de lucru începe din nou.

Despre rolul Ministerului Apărării

De remarcat faptul că din punct de vedere istoric, modelele de evaluare a calității procesului de dezvoltare au fost create cu scopul de a obține proceduri rezonabile de evaluare și dezvoltare ulterioară a proceselor tehnologice în acele organizații care solicită comenzi pentru dezvoltarea proiectelor de importanță pentru apărare. Modelele sunt aplicabile companiilor care dezvoltă sisteme complexe și în timp real. Acestea sunt sisteme cu cicluri de viață lungi, unde defectele software-ului pot fi critice.

Software „Destul de bun”.

Ieri la Seattle, după ce Bill Gates a menționat lansarea versiunii beta

Noul program al Microsoft a fost lovit de un cutremur.

Utilizatorii așteaptă îngroziți anunțul lansării versiunii finale a produsului.

Promotorul software-ului „destul de bun” este Edward Yordon [Yordon 2001]. Subliniem că el aplică acest concept „proiectelor pierdute”, care sunt supuse unor constrângeri stricte de timp, buget și resurse umane (vezi Secțiunea 1.6). În cele mai multe proiecte fără speranță, clientul poate fi mulțumit de un sistem suficient de ieftin, suficient de performant, care are capacitățile necesare, este suficient de robust și va fi gata destul de curând. De fapt, aceste caracteristici pot fi considerate definiția software-ului „suficient de bun”.

Se pare că chiar și software-ul „suficient de bun” este dificil de creat. Să prezentăm câteva din totalitatea motivelor care explică acest lucru [Yordon 2001].

Adesea ei încearcă să definească calitatea doar în termeni de defecte (erori). Din punctul de vedere al utilizatorului, aspecte precum pregătirea pentru o anumită dată nu sunt mai puțin importante.

Presupunerea este că mai puține erori înseamnă o calitate mai bună, iar utilizatorul preferă acea calitate. Cu toate acestea, uneori, utilizatorul este dispus să facă compromisuri și să accepte unele greșeli în schimbul că va face treaba mai repede.

Ignorarea factorilor precum moralul echipei de dezvoltare și condițiile de lucru adecvate.

James Bach subliniază următoarele condiții necesare pentru crearea unui software „suficient de bun”:

• strategie utilitarista - arta analizei cantitative si maximizarii castigului net in situatii incerte;
• strategie evolutivă – considerată nu numai în raport cu ciclul de viață al proiectului, ci și cu oamenii, procesele și resursele;
• echipele eroice nu sunt programatori strălucitori puternici, ci specialiști obișnuiți calificați, capabili de o cooperare eficientă;
• infrastructura dinamică este opusul birocrației și dominației politicii;
• procese dinamice – procese care sprijină munca într-un mediu evolutiv.

Din păcate, software-ul „destul de bun” este rareori suficient de bun. Niklaus Wirth notează că aceasta este „o consecință a manifestării triste a spiritului vremurilor noastre, în care mândria personală față de munca proprie dispare”. În opinia sa, „nu te poți aștepta la o muncă de înaltă calitate dacă nu te dedici complet acesteia, dacă nu există satisfacție personală, în plus, plăcere de la ea”.

O observație interesantă că unele companii se străduiesc să scadă nivelul intelectual al utilizatorilor produselor lor a fost făcută de mulți programatori. Este extrem de benefic pentru companii să aibă de-a face cu oameni ale căror calificări tehnice nu le permit să determine aspectele reale (de exemplu, calitatea, complexitatea, valoarea) unui produs software. Sub pretextul „simplificarii” muncii și a face computerele mai accesibile utilizatorilor, companiile supraîncărcă și complică în mod repetat software-ul în așa fel încât utilizatorului să înțeleagă extrem de greu cum funcționează de fapt și să devină un profesionist.

Standardizarea tehnologiei informației

Un standard este o definiție general acceptată a unei componente hardware sau software care rezultă dintr-un acord. Profilul este un set de standarde legale și/sau faptice concentrate pe îndeplinirea unei sarcini specifice [Kozlov 1999].

Standardele pot fi clasificate astfel:

• după tipul de stabilire a cerințelor:
• stabilirea cerințelor pentru obiect;
• stabilirea cerințelor procesului;
• dupa scara:
• internaţional;
• guvern;
• industrie;
• intreprinderi;
• după gradul de înregistrare legală:
• acceptate legal;
• funcționează efectiv.

Procesul de standardizare a tehnologiei informației este susținut de trei grupuri principale de organizații. Organizații internaționale care fac parte din ONU. Organizația Internațională pentru Standardizare (ISO) este o organizație internațională de standardizare.

Despre ISO

În 1947, reprezentanții a 25 de țări au decis să creeze o organizație a cărei sarcină principală ar fi să coordoneze evoluțiile și să unifice standardele internaționale. Noua organizație a fost numită Organizația Internațională pentru Standardizare (ISO). Discrepanța dintre numele complet și abreviere se explică prin faptul că „ISO” este un prefix grecesc care înseamnă „egal”.

International Electrotechnical Commission (IEC) - comisie electrotehnică internațională.

Uniunea Internațională de Telecomunicații-Telecomunicații (ITU-T) - uniunea internațională de telecomunicații - telecomunicații. Până în 1993, această organizație a fost numită International Telegraph and Telephone Consultative Committee - comitetul consultativ internațional pentru telefonie și telegrafie.

Organizații profesionale sau administrative industriale.

Institutul de Ingineri Electrici și Electronici (IEEE) - Institutul de Ingineri Electrici și Electronici.

Internet Activity Board (IAB) este un consiliu care guvernează activitățile pe Internet.

Consortii industriale.

Object Management Group (OMG) - grup de gestionare a obiectelor.

X/Open este un consorțiu organizat de un grup de furnizori de echipamente informatice.

Open Software Foundation (OSF) este o fundație de software deschisă.

În 1987, ISO și IEC și-au combinat activitățile în domeniul standardizării tehnologiei informației și au creat un singur organism - Joint Technical Committee 1 (JTC1). Acest comitet este destinat să formeze un sistem de standarde de bază în domeniul tehnologiei informației.

Creșterea rapidă a complexității și dimensiunii pachetelor software moderne, cu creșterea concomitentă a responsabilității funcțiilor îndeplinite, a crescut brusc cerințele clienților și utilizatorilor pentru calitatea și siguranța utilizării acestora. Un mijloc dovedit de a asigura eficiența ridicată și calitatea funcționării programelor și sistemelor software sunt standardele internaționale dezvoltate cu participarea reprezentanților companiilor lider din industrie.

Pe măsură ce utilizarea și complexitatea sistemelor informaționale se extind, au apărut zone în care erorile sau calitatea insuficientă a programelor sau datelor pot provoca daune care depășesc semnificativ efectul pozitiv al utilizării acestora.

În multe cazuri, contractele și planurile preliminare pentru crearea de software și baze de date complexe pentru sistemele informaționale sunt pregătite și evaluate fără pricepere, pe baza ideilor informale ale clienților și dezvoltatorilor despre funcțiile necesare și caracteristicile de calitate ale sistemelor informaționale. Erorile semnificative de sistem în determinarea indicatorilor de calitate solicitați, aprecierea intensității forței de muncă, costul și durata creării software-ului sunt un fenomen destul de răspândit. Multe sisteme informatice nu sunt capabile să îndeplinească pe deplin sarcinile funcționale necesare cu o calitate garantată și trebuie să fie modificate pentru o lungă perioadă de timp și uneori fără succes pentru a atinge calitatea și fiabilitatea necesară a funcționării, cheltuind în plus o mulțime de bani și timp. Ca urmare, proiectele de sisteme informatice adesea nu corespund scopului și cerințelor inițiale declarate pentru caracteristicile de calitate și nu se încadrează în programele și bugetele de dezvoltare.

În specificațiile tehnice și proiectele de sisteme informatice implementate, informațiile despre conceptele și valorile calității produselor software, ce caracteristici sunt descrise, cum ar trebui să fie măsurate și comparate cu cerințele reflectate în contract, specificațiile tehnice sau specificațiile sunt adesea silentioase. sau insuficient formalizate. În plus, unele dintre caracteristici sunt adesea absente din cerințele pentru software, ceea ce duce la luarea în considerare sau la omisiune arbitrară a acestora în timpul testării. Declararea neclară în documente a conceptelor și a valorilor cerute ale caracteristicilor calității software-ului provoacă conflicte între clienți-utilizatori și dezvoltatori-furnizori din cauza interpretărilor diferite ale acelorași caracteristici. În acest sens, asigurarea calității necesare a software-ului și bazelor de date a devenit o sarcină strategică în ciclul de viață al sistemelor informaționale moderne.

În ultimii ani, au fost create multe standarde internaționale care reglementează procesele și produsele ciclului de viață al software-ului și bazelor de date. Utilizarea acestor standarde poate servi ca bază pentru sistemele de asigurare a calității software, totuși, este necesară ajustarea, adaptarea sau excluderea unor prevederi ale standardelor în raport cu caracteristicile fundamentale ale tehnologiilor și caracteristicilor acestui tip de produs. În același timp, mulți clienți au nevoie de tehnologie de design, producție și calitate a produsului pentru a îndeplini standardele internaționale moderne, care trebuie stăpânite și aplicate pentru a asigura competitivitatea produselor pe piața globală.

Standardizarea caracteristicilor de calitate

Una dintre cele mai importante probleme în asigurarea calității software-ului este formalizarea caracteristicilor calității și metodologia de evaluare a acestora. Pentru a determina caracterul adecvat al calității funcționării, disponibilitatea capacităților tehnice ale instrumentelor software pentru interacțiune, îmbunătățire și dezvoltare, este necesar să se utilizeze standarde în domeniul evaluării caracteristicilor calității acestora. Baza pentru reglementarea indicatorilor de calitate software a fost anterior standardul internațional ISO 9126:1991 (GOST R ISO / IEC 9126-93) „Tehnologia informației. Evaluarea produsului software. Caracteristici de calitate și linii directoare pentru aplicarea acestora”. Proiectul final al standardului ISO 9126-1--4 din patru părți este în curs de finalizare și oficializare pentru a înlocui ediția minoră din 1991. Proiectul constă din următoarele părți la rubrica generală „Tehnologia informației – caracteristici și metrici ale calității software”: „Partea 1. Caracteristicile și subcaracteristicile calității” Partea 2. Măsuri externe de calitate” „Partea 3. Măsuri interne de calitate” „Partea 4. Măsuri de calitate în uz”.

În Rusia, în domeniul asigurării ciclului de viață și a calității pachetelor software complexe, se utilizează în principal un grup de standarde GOST învechite, care rămân în urmă cu 5-10 ani în urma nivelului mondial.

Prima parte a standardului, ISO 9126-1, clasifică atributele de calitate software în șase caracteristici utilizate în părțile rămase ale standardului. Pe baza posibilităților fundamentale de măsurare a acestora, toate caracteristicile pot fi combinate în trei grupuri, cărora li se aplică diferite categorii de metrici:

• metricile categorice sau descriptive (nominale) sunt cele mai adecvate pentru funcționalitatea instrumentelor software;
• metricile cantitative sunt aplicabile pentru a măsura fiabilitatea și eficacitatea pachetelor software complexe;
• Valorile de calitate sunt cele mai în concordanță cu utilizarea, mentenabilitatea și portabilitatea software-ului.

O parte a standardului ISO 9126-1 oferă definiții cu clarificări din restul părților sale pentru fiecare caracteristică software, precum și pentru subcaracteristicile de calitate.

În ultimii câțiva ani, au fost create multe standarde ISO care reglementează procesele și produsele ciclului de viață al software-ului și bazele de date, care pot servi drept bază pentru sistemele de asigurare a calității software.

Partea a doua și a treia ale standardului - ISO 9126-2 și ISO 9126-3 - sunt dedicate formalizării, respectiv, metricilor externe și interne pentru caracteristicile de calitate ale software-ului complex. Toate tabelele conțin un titlu unificat, care reflectă numele și scopul valorii; modul de aplicare a acestuia; metoda de masurare, tipul scarii metrice; tipul mărimii măsurate; date de referință pentru măsurare și comparare; precum și etapele ciclului de viață al software-ului (conform ISO 12207) cărora le este aplicabilă metrica.

A patra parte a standardului, ISO 9126-4, este destinată cumpărătorilor, furnizorilor, dezvoltatorilor, întreținerii, utilizatorilor și managerilor de calitate software. Acesta justifică și comentează indicatorii selectați din sfera (contextul) de utilizare a software-ului și grupul de metrici selectate pentru utilizatori.

Selectarea indicatorilor de calitate

Datele inițiale și cea mai mare prioritate la alegerea indicatorilor de calitate în majoritatea cazurilor sunt scopul, funcțiile și adecvarea funcțională a instrumentului software corespunzător. O descriere destul de completă și corectă a acestor proprietăți ar trebui să servească drept bază pentru determinarea valorilor majorității celorlalte caracteristici și atribute de calitate. Capacitățile fundamentale și tehnice și acuratețea de măsurare a valorilor atributelor caracteristicilor de calitate sunt întotdeauna limitate în conformitate cu conținutul acestora. Aceasta definește intervale raționale de valori pentru fiecare atribut care pot fi selectate pe baza bunului simț, precum și prin analizarea precedentelor în specificațiile cerințelor proiectelor reale.

Procesele de selectare și stabilire a unor metrici și scale pentru a descrie caracteristicile calității software-ului pot fi împărțite în două etape:

• selectarea și justificarea unui set de date inițiale care reflectă caracteristicile generale și etapele ciclului de viață ale unui proiect software și ale consumatorilor acestuia, fiecare dintre acestea afectând anumite caracteristici de calitate ale pachetului de software;
• selectarea, stabilirea și aprobarea unor metrici și scale specifice pentru măsurarea caracteristicilor și atributelor de calitate ale proiectului pentru evaluarea și compararea ulterioară a acestora cu cerințele caietului de sarcini în procesul de testare sau certificare a calificării la anumite etape ale ciclului de viață al software-ului.

În prima etapă, întreaga nomenclatură de bază a caracteristicilor, subcaracteristicilor și atributelor standardizate în ISO 9126 ar trebui să fie luată ca bază. . În continuare, este necesară identificarea și prioritizarea consumatorilor care au nevoie de anumiți indicatori ai calității unui proiect software, ținând cont de specializarea și interesele profesionale ale acestora. Pregătirea datelor inițiale este finalizată prin identificarea unei game de indicatori de calitate de bază, prioritari, care determină adecvarea funcțională a software-ului pentru anumiți consumatori.

În a doua etapă, după fixarea datelor inițiale, care trebuie efectuate de către consumatorul evaluărilor calității, procesele de selecție a nomenclaturii și metricilor încep cu ierarhizarea caracteristicilor și subcaracteristicilor pentru un anumit proiect și consumatorul acestora. În continuare, acești specialiști trebuie să stabilească și să convină asupra unei scale metrice și de rating pentru subcaracteristicile și atributele acestora pentru fiecare dintre indicatorii selectați pentru proiect și consumatorul rezultatelor analizei. Pentru indicatorii reprezentați prin caracteristici calitative, este de dorit să se definească și să se înregistreze în caietul de sarcini descrieri ale condițiilor în care ar trebui să se considere că această caracteristică este implementată în software. Valorile selectate ale caracteristicilor de calitate și atributele acestora trebuie verificate în prealabil de către dezvoltatori pentru fezabilitatea lor, ținând cont de resursele disponibile ale unui anumit proiect și, dacă este necesar, ajustate.

Control de calitate

Standardul internațional ISO 14598, format din șase părți, este dedicat metodologiei și standardizării evaluării caracteristicilor de calitate ale instrumentelor software finite și ale componentelor acestora (produs software) în diferite etape ale ciclului de viață. Se recomandă următoarea schemă generală a proceselor de evaluare a caracteristicilor calității programului:

• stabilirea cerințelor inițiale pentru evaluare - definirea obiectivelor de testare, identificarea tipului de metrici software, identificarea indicatorilor adecvați și a valorilor solicitate ale atributelor de calitate;
• selectarea metricilor de calitate, stabilirea evaluărilor și a nivelurilor de prioritate pentru metricile subcaracteristicilor și atributelor, selectarea criteriilor pentru efectuarea examinărilor și măsurătorilor;
• planificarea și proiectarea proceselor pentru evaluarea caracteristicilor și atributelor de calitate în ciclul de viață al unui instrument software;
• efectuarea de măsurători pentru evaluare, compararea rezultatelor cu criteriile și cerințele, rezumarea și evaluarea rezultatelor.

Pentru fiecare caracteristică de calitate, se recomandă crearea unor măsuri și o scală de măsurare care să evidențieze valorile cerute, acceptabile și nesatisfăcătoare. Implementarea proceselor de evaluare trebuie să fie corelată cu etapele ciclului de viață ale unui proiect software specific, în conformitate cu versiunea aplicabilă, adaptată a standardului ISO 12207.

Fitness funcțional- cea mai incertă și obiectiv dificil de evaluat subcaracteristică a unui instrument software. Domeniile de aplicare, nomenclatura și funcțiile complexelor software acoperă domenii atât de diverse ale activității umane, încât este imposibil să se evidențieze și să unifice un număr mic de atribute pentru evaluarea și compararea acestei subcaracteristici în diferite complexe software.

Evaluarea corectitudinii software-ului constă în determinarea formală a gradului de conformitate a unui set de programe implementate cu cerințele inițiale ale contractului, specificațiile tehnice și specificațiile pentru software și componentele acestuia. Prin verificare, trebuie determinată conformitatea cu cerințele inițiale ale întregului set de componente ale pachetului software, până la module și texte de program și descrieri de date.

Evaluarea interoperabilității este de a determina cât de bine funcționează componentele software și baze de date împreună cu alte sisteme de aplicații și componente pe diferite platforme de calcul și interacționează cu utilizatorii într-un stil care este convenabil pentru a trece de la un sistem de calcul la altul cu funcții similare.

Evaluarea securității software include determinarea caracterului complet al utilizării metodelor și mijloacelor disponibile de protejare a software-ului de potențiale amenințări și a securității realizate a sistemului informațional. Cele mai răspândite și detaliate sarcini metodologice și sistemice pentru evaluarea protecției cuprinzătoare a sistemelor informaționale sunt stabilite în trei părți ale standardului ISO 15408:1999-1--3 „Metode și mijloace de asigurare a securității. Criterii de evaluare a securității informațiilor. tehnologii”.

Evaluarea fiabilității- măsurarea metricilor cantitative ale atributelor subcaracteristicilor în uz: completitudine, toleranță la defect, recuperabilitate și disponibilitate/preparare.

Cerințe de memorie și performanță calculatorul aflat în proces de rezolvare a problemelor variază semnificativ în funcție de compoziția și volumul datelor inițiale. Pentru a determina corect debitul maxim al unui sistem informatic cu un instrument software dat, este necesar să se măsoare valorile extreme și medii ale duratelor de execuție ale grupurilor funcționale de programe și rutele de-a lungul cărora sunt realizate. Dacă performanța computerului nu a fost evaluată anterior în timpul procesului de proiectare, atunci cel mai probabil va fi necesară o modificare majoră sau chiar înlocuirea computerului cu unul mai rapid.

Evaluarea gradului de utilizare Evaluarea software-ului este efectuată de experți și include determinarea gradului de înțelegere, ușurință de utilizare, învățare și atractivitate a software-ului. Aceasta este în principal o evaluare calitativă (și subiectivă) în puncte, dar unele atribute pot fi evaluate cantitativ prin complexitatea și durata operațiunilor atunci când se utilizează software-ul, precum și prin cantitatea de documentație necesară pentru a le studia.

Mentenabilitatea este posibil să se evalueze completitatea și fiabilitatea documentației despre stările software-ului și ale componentelor sale, toate modificările propuse și finalizate, ceea ce face posibilă stabilirea stării actuale a versiunilor programului în orice moment și istoricul dezvoltării lor. Ar trebui să definească strategia, standardele, procedurile, alocarea resurselor și planurile pentru crearea, modificarea și aplicarea programelor și a documentelor de date.

Evaluarea mobilității- o determinare calitativă de către experți a adaptabilității, ușurinței de instalare, compatibilității și înlocuirii programelor, exprimată în puncte. Această caracteristică a unui instrument software și totalitatea atributelor sale pot fi (și oportun) evaluate cantitativ în indicatori economici: cost, intensitatea forței de muncă și durata de implementare a procedurilor pentru transferul unui anumit set de programe și date către alte platforme.

Sistemul de management al calității

Selectarea caracteristicilor și aprecierea calității software-ului este doar una dintre sarcinile în domeniul asigurării calității produselor produse de companiile de dezvoltare software. O soluție cuprinzătoare la problemele de asigurare a calității software-ului implică dezvoltarea și implementarea unuia sau altuia sistem de management al calității. În practica mondială, cel mai utilizat sistem se bazează pe standardele internaționale din seria ISO 9000, care include mai mult de o duzină de documente, inclusiv standardul care reglementează asigurarea calității software-ului (ISO 9000/3). Aceste standarde ar trebui să servească drept ghid pentru specialiștii de top în companiile de dezvoltare de software personalizat.

Definiții ale caracteristicilor și subcaracteristicilor de calitate (ISO 9126-1)

Funcționalitate- capacitatea unui instrument software de a oferi soluții la probleme care să satisfacă nevoile formulate ale clienților și utilizatorilor atunci când se utilizează un set de programe în condiții date.

Fitness funcțional- un set și descrieri ale unei subcaracteristici și atributelor acesteia care definesc scopul, nomenclatura, funcțiile de bază, necesare și suficiente ale software-ului, corespunzătoare specificațiilor și specificațiilor tehnice ale clientului sau potențialului utilizator.

Corectitudine (corectitudine)- capacitatea unui instrument software de a oferi utilizatorului rezultate corecte sau acceptabile și efecte externe.

Interoperabilitate- proprietatea software-ului și a componentelor acestora de a interacționa cu una sau mai multe componente ale mediului intern și extern.

Securitate- capacitatea componentelor software de a proteja programele și informațiile de orice influențe negative.

Calitatea software-ului este o preocupare constantă a ingineriei software și este discutată în multe domenii ale cunoașterii.

• Phil Crosby: Calitatea înseamnă conformitatea cu cerințele utilizatorului.
• Watts Humphrey: Calitatea este atingerea unui nivel excelent de utilizare.
• Compania IBM: a inventat sintagma „calitatea condusă de piață”.
• Criteriul Baldrige:„calitate orientată către client”.
• Sistemul de management al calității ISO 9001: Calitatea este gradul în care caracteristicile inerente îndeplinesc cerințele.

Calitate acceptabila- acesta este gradul de perfecțiune dorit al produsului (serviciului) creat, capabil să satisfacă utilizatorii și realizabil în limitele de proiectare date.

Calitatea in activitatile proiectului:

• Managementul cerințelor („atribute de calitate” ca categorie de cerințe nefuncționale);
• Testare (așa-numita MTBF, metrici precum MTTF - Mean Time To Failure, adică timpul mediu dintre defecțiunile sistemului detectate etc.).

„Calitate acceptabilă” poate fi comparat cu nivelul de serviciu din cadrul unui anumit SLA - Service Level Agreement. Adică, calitate acceptabilă poate fi considerată ca<количественно выраженный>compromis între client și antreprenor cu privire la caracteristicile produsului creat de antreprenor în interesul<решения задач>clientului, ținând cont de alte limitări ale proiectului (în special, costul, care este adesea denumit „costul calității”).

Figura „Zona de cunoștințe - Calitatea software-ului”

Figura „Modelul unui sistem de management al calității”

Fundamentele calității software

S-a ajuns la un acord privind cerințele de calitate, împreună cu comunicarea clară către ingineri a ceea ce reprezintă calitatea<получаемого продукта>, necesită discuții și definirea formală a multor aspecte ale calității.

Inginerii trebuie să înțeleagă conceptul de calitate, caracteristicile și semnificația calității în raport cu software-ul dezvoltat sau întreținut.

O idee importantă este că cerințele software definesc caracteristicile necesare calității software și influențează, de asemenea, metodele de cuantificare formulate pentru evaluarea acestor caracteristici.<соответствующие>criteriul de acceptare.

Cultura și etica ingineriei software

Se așteaptă ca inginerii de software să accepte problemele legate de calitatea software-ului ca parte a acestora<профессиональной>cultură.
Considerațiile etice pot juca un rol semnificativ în calitatea software-ului, cultura și atitudinea inginerilor.<к своей работе>. IEEE Computer Society și ACM au dezvoltat un cod de etică și practică profesională bazat pe opt principii pentru a ajuta inginerii să-și consolideze angajamentul față de calitate și independență.<в решении вопросов обеспечения достойного качества создаваемых программных продуктов>în munca lor zilnică.

Valoarea și costurile calității

Conceptul de „calitate”, de fapt, nu este atât de evident și de simplu pe cât ar părea la prima vedere. Pentru orice produs de inginerie sunt multe<интерпретаций>calitate, în funcție de „sistemul de coordonate” specific. Multe dintre aceste puncte de vedere trebuie discutate și determinate în etapa de dezvoltare a cerințelor pentru un produs software. Caracteristicile de calitate pot fi cerute în grade diferite, pot fi absente sau pot stabili anumite cerințe, toate acestea putând fi rezultatul unui fel de compromis.

Costul calității poate fi diferențiat în:

• costul avertismentului<дефектов>(costul de prevenire),
• cost de evaluare,
• costul eșecului intern,
• costul eșecului extern.

Forța motrice din spatele proiectelor software este dorința de a crea software care are o anumită valoare. Valoarea software-ului poate fi sau nu exprimată sub formă de cost. Clientul are de obicei propria idee despre investiția de cost maxim, a cărei rentabilitate este așteptată dacă obiectivele principale ale creării software-ului sunt atinse. Clientul poate avea și anumite așteptări cu privire la calitatea software-ului. Uneori, clienții nu se gândesc la problemele de calitate și la costurile asociate. Caracteristicile de calitate sunt pur decorative sau fac parte integrantă din software? Răspunsul se află probabil undeva la mijloc, așa cum este aproape întotdeauna cazul în aceste cazuri, și este o chestiune de discuție despre gradul în care clientul este implicat în procesul de luare a deciziilor și înțelegerea deplină de către client a costurilor și beneficiilor. asociat cu atingerea unui anumit nivel de calitate. În mod ideal, majoritatea acestor decizii ar trebui luate în timpul procesului de cerințe, dar aceste probleme pot apărea pe parcursul ciclului de viață al software-ului. Nu există<“стандартных”>reguli cu privire la modul exact în care trebuie luate astfel de decizii. Cu toate acestea, inginerii trebuie să poată imagina diverse alternative și costurile acestora.

Modele și caracteristici de calitate

ISO/IEC definește trei modele de calitate software conexe (ISO 9126-01 Inginerie software - Calitatea produsului, Partea 1: Model de calitate):

• calitate interioara,
• calitate exterioară şi
• calitatea în timpul funcționării, precum și un set de lucrări relevante pentru evaluarea calității software-ului (ISO14598-98 Software Product Evaluation).

Calitatea procesului de inginerie software

Managementul calității (managementul calității software) și calitatea procesului de inginerie software (calitatea procesului de inginerie software) sunt direct legate de calitatea produsului software creat.

Există două standarde importante în domeniul calității software.

• TickIT- se referă la luarea în considerare a sistemului general de management al calității ISO 9001-00 aplicat proiectelor software.
• Un alt standard important este CMMI, discutat în zona de cunoștințe Procesul de inginerie software, oferă recomandări pentru îmbunătățirea procesului. Domeniile de proces CMMI (domeniile de competență) sunt direct legate de managementul calității:
  • asigurarea calității procesului și produselor (categoria de proces „Suport” CMMI),
  • verificare (categoria „Inginerie”) și
  • certificare (validare, categoria „Inginerie”).

În același timp, CMMI clasifică revizuireȘi audit ca metode de verificare, dar nu ca procese independente.

Aceste standarde sunt încă considerate a fi complementare și că certificarea la ISO 9001 ajută la atingerea nivelurilor superioare de maturitate CMMI.

Calitatea produsului software

În primul rând, inginerii trebuie să stabilească obiective pentru crearea de software.În acest context, este deosebit de important să ne amintim că cerințele clienților sunt primare și conțin cerințe de calitate, și nu doar de funcționalitate (cerințe funcționale). Astfel, inginerii sunt responsabili de extragerea cerințelor de calitate care nu sunt întotdeauna prezentate explicit, precum și de discutarea importanței acestora și a gradului de dificultate în realizarea lor. Toate procesele asociate cu calitatea (de exemplu, asamblarea, inspecția și îmbunătățirea calității) trebuie să fie proiectate ținând cont de aceste cerințe și să suporte costurile suplimentare (ca o parte importantă a costului software-ului).

Standardul ISO 9126-01 (Inginerie software - Calitatea produsului, Partea 1: Model de calitate) definește, pentru două dintre cele trei modele descrise aici, caracteristici asociate și „subcaracteristici” de calitate, precum și metrici utile pentru evaluarea calității produselor software.

Înțelegerea termenului „produs” este extinsă pentru a include toate artefactele create ca rezultat al tuturor proceselor utilizate pentru a crea produsul software final. Exemplele de produse includ (dar nu se limitează la):

• specificația completă a cerințelor de sistem,
• specificarea cerințelor software pentru componentele software ale sistemului (specificația cerințelor software, SRS),
• modele,
• documentatie de testare,
• rapoarte generate ca urmare a muncii de analiză a calității.

Deși termenul de calitate este folosit cel mai adesea în legătură cu produsul final și comportamentul sistemului în timpul funcționării, este o bună practică de inginerie să ceri ca conformitatea cu caracteristicile de calitate specificate să fie evaluată pentru ieșiri/produsele ciclului de viață pe parcursul tuturor proceselor de inginerie software.

Imbunatatire a calitatii

Calitatea software-ului poate fi îmbunătățită printr-un proces iterativ de îmbunătățire continuă. Acest lucru necesită control, coordonare și feedback în gestionarea multor procese care rulează simultan:

1. procesele ciclului de viață,
2. procesul de detectare, eliminare și prevenire a defecțiunilor/defectelor și
3. procese de imbunatatire a calitatii.

Teoriile și conceptele aplicabile ingineriei software suntîmbunătățirea calității de bază. De exemplu, prevenirea și diagnosticarea timpurie a erorilor, îmbunătățirea continuă și atenția la cerințele clienților (orientarea către client), care constituie principiul „construirii calității”. Aceste concepte se bazează pe munca experților în calitate care au ajuns să creadă că calitatea unui produs este direct legată de calitatea proceselor utilizate pentru a-l crea.

Abordări precum TQM(Total Quality Management - total management management) și PDCA(Planificare, Efectuare, Verificare, Acționare – Planificare, Acțiune, Verificare, Reacție/Ajustare) sunt instrumente pentru atingerea obiectivelor legate de calitate. Suportul de management ajută la executarea proceselor, evaluarea produselor și obținerea tuturor datelor necesare. În plus, programul de îmbunătățire elaborat (programul de îmbunătățire, de obicei vizat și care acoperă activitatea unui departament sau organizație în ansamblu) identifică în detaliu toate acțiunile și proiectele de îmbunătățire<отдельных аспектов деятельности>într-o anumită perioadă de timp în care astfel de proiecte pot fi implementate cu soluţionarea cu succes a problemelor relevante. În același timp, sprijinul managerial înseamnă că toate proiectele de îmbunătățire au suficiente resurse pentru a-și atinge obiectivele. Sprijinul managementului este strâns legat de implementarea interacțiunii active în echipă și ar trebui să prevină apariția unor potențiale probleme (și rezistența pasivă sau chiar activă la implementarea programului de îmbunătățire sau a proiectelor individuale ale acestuia). Formarea grupurilor de lucru, sprijinirea managerilor de mijloc și resursele dedicate la nivel de proiect sunt discutate în zona de cunoștințe „Procesul de inginerie software”.

Procese de calitate software

Managementul calității software (SQM, Managementul calității software) se aplică tuturor aspectelor proceselor, produselor și resurselor. SQM definește procesele, proprietarii de procese, precum și cerințele proceselor, măsurătorile proceselor și rezultatele acestora, plus canalele de feedback.

Procesele de management al calității conțin multe activități. Unele dintre ele vă permit să găsiți direct defectele, în timp ce altele vă ajută să determinați unde exact poate fi important să efectuați studii mai detaliate, după care, din nou, se lucrează pentru a detecta direct erorile. Multe acțiuni pot fi, de asemenea, realizate cu scopul de a atinge ambele obiective.

Planificarea calității software include:

1. Definirea produsului solicitat din punct de vedere al caracteristicilor de calitate.
2. Planificarea proceselor pentru obtinerea produsului necesar.

Aceste procese diferă de procesele SQM în sine, care, la rândul lor, au ca scop evaluarea performanței calității planificate, mai degrabă decât implementarea efectivă a acestor planuri. Procesele de management al calității trebuie să abordeze cât de bine produsul va satisface nevoile clienților și părților interesate, să ofere valoare clientului și părților interesate și să aibă calitatea necesară pentru a îndeplini cerințele software menționate.

SQM poate fi folosit pentru a evalua atât produsele finale, cât și cele intermediare. Unele dintre procesele SQM specializate sunt definite în standardul 12207:

• Procesul de asigurare a calității;
• Procesul de verificare;
• Proces de validare;
• Procesul comun de revizuire;
• Procesul de audit.

Toate aceste procese sprijină urmărirea calității și, de asemenea, ajută la identificarea posibilelor erori. Cu toate acestea, ele diferă în ceea ce se concentrează.

Procesele SQM constau din sarcini și tehnici care conceput pentru a evalua modul în care planurile software se concretizează și cât de bine îndeplinesc cerințele specificate produsele intermediare și finale. Rezultatele acestor sarcini sunt raportate managerilor înainte de a lua măsurile corective adecvate. Procesul SQM este gestionat cu încredere că datele de raportare sunt exacte.
După cum este descris în această zonă de cunoștințe, procesele SQM sunt strâns legate. Ele se pot suprapune și uneori chiar se pot combina. Ei par a fi de natură reactivă, datorită faptului că privesc procesele în contextul practicilor învățate și al produselor deja produse. Cu toate acestea, acestea joacă un rol major în etapa de planificare, fiind proactive ca procese și proceduri necesare atingerii caracteristicilor și nivelurilor de calitate cerute de părțile interesate.<проекта>software.

Managementul riscului poate juca, de asemenea, un rol semnificativ în furnizarea de software de calitate. Includerea analizei de risc „regulate” (ca permanente, nu periodice; în original – disciplinată) și<соответствующих>tehnician de control<рисками>în procesele ciclului de viață al software-ului poate crește potențialul de a produce un produs de calitate. Informații mai detaliate despre managementul riscului pot fi găsite în zona de cunoștințe „Managementul ingineriei software”.

Asigurarea calității software (SQA)

Procese SQA să furnizeze dovezi că produsele software și procesele ciclului de viață al proiectului îndeplinesc cerințele specificate. O astfel de confirmare se realizează pe baza de planificare, stabilire<работ>punerea în aplicare și efectuarea unui set de acțiuni menite să se asigure că calitatea devine parte integrantă a software-ului.
Această viziune presupune o formulare clară și precisă a problemei, precum și ca cerințele pentru soluția corespunzătoare să fie definite și exprimate clar, complete și interpretate fără ambiguitate.<программному>decizie. SQA realizează asigurarea calității în procesul de dezvoltare și întreținere prin realizarea diferitelor activități în toate etapele<жизненного цикла>, care vă permite să identificați probleme într-un stadiu incipient, care sunt aproape inevitabile în orice activitate complexă.

Managementul riscurilor este un instrument suplimentar serios pentru asigurarea calității software-ului.

SQA, așa cum este formulat de SWEBOK, se concentrează pe procese. Rolul SQA este de a se asigura că procesele sunt planificate în mod corespunzător, că procesele continuă să fie executate pe baza planului și că sunt luate măsurătorile necesare procesului și că rezultatele măsurătorilor sunt comunicate părților interesate (organizații și indivizi).

Planul SQA definește mijloacele care vor fi utilizate pentru a se asigura că produsul în curs de dezvoltare îndeplinește cerințele specificate ale utilizatorului cu cel mai înalt nivel de calitate posibil, în limitele constrângerilor de proiectare specificate.

Pentru a realiza acest lucru, este mai întâi necesar ca obiectivele de calitate să fie clar definite și înțelese (și, de asemenea, clar interpretabile, ceea ce este o condiție prealabilă pentru orice obiective și cerințe corespunzătoare). Acest lucru trebuie reflectat în planurile de management relevante.<проектом>, dezvoltare și sprijin.

Activitățile și sarcinile specifice de asigurare a calității sunt structurate cu cerințe detaliate pentru costul și resursele asociate acestora, obiectivele de management și graficele corespunzătoare în contextul obiectivelor stabilite de planurile de management, dezvoltare și întreținere. Planul SQA identifică documentele, standardele, practicile și convențiile utilizate pentru controlul proiectului și modul în care aceste aspecte vor fi verificate și monitorizate pentru a asigura adecvarea și conformitatea cu planul specificat.
Un plan SQA identifică metrici, tehnici statistice, proceduri de raportare a problemelor și acțiuni corective, instrumente precum instrumente, tehnici și metodologii, probleme de securitate fizică a media, instruire și raportare și documentare legate de problemele SQA.

În plus, planul SQA abordează și probleme legate de activitățile de asigurare a calității legate de alte tipuri de activități descrise în<различных>planuri pentru crearea de software, care includ, de asemenea, furnizarea, instalarea, întreținerea de soluții software personalizate și/sau replicabile/pregătite (comercial off-the-shelf, COTS) necesare pentru un proiect software dat. Planul SQA poate conține criteriile de acceptare a software-ului și activitățile de raportare și management necesare pentru asigurarea calității.<и контролю над>lucrări.

Verificare și validare (V&V)

Verificarea și certificarea software-ului este o abordare disciplinată a evaluării produselor software, aplicată de-a lungul întregului ciclu de viață. Eforturile de verificare și calificare vizează asigurarea calității ca caracteristică integrală a software-ului și satisfacerea cerințelor utilizatorului.
V&V abordează în mod direct problemele legate de calitatea software-ului și utilizează tehnici de testare adecvate pentru a detecta defecte specifice. V&V poate fi folosit pentru produse intermediare, totuși, în măsura în care „pașii” intermediari corespund<соответствующих>procesele ciclului de viață.

Procesul V&V determină în ce măsură produsul (rezultatul) anumitor lucrări de dezvoltare și întreținere îndeplinește cerințele formulate în cadrul acestor lucrări, iar produsul final satisface obiectivele specificate și cerințele utilizatorului.

Verificare- o încercare de a se asigura că un produs este proiectat corect (produsul este construit în mod corect; de obicei pentru intermediari, uneori pentru produsul final), în sensul că produsul realizat prin activitate îndeplinește specificațiile stabilite de activitatea anterioară .
Certificare– o încercare de a se asigura că se construiește produsul potrivit (se construiește produsul potrivit; de obicei, în contextul produsului final), în ceea ce privește atingerea scopului declarat.

Ambele procese – verificare și certificare– începe în stadiile incipiente de dezvoltare și întreținere. Acestea oferă examinarea (examinarea) capabilităților cheie ale produsului atât în ​​contextul livrabilelor imediat precedente (produse intermediare), cât și în ceea ce privește îndeplinirea specificațiilor relevante. Scopul planificării V&V este de a oferi proceselor de verificare și certificare resursele necesare și de a atribui în mod clar roluri și responsabilități. Documentele rezultate din planul V&V și<детально>descrie diversele resurse, roluri și activități, precum și tehnicile și instrumentele utilizate.
Planul abordează, de asemenea, aspectele legate de management, comunicări, politici și proceduri ale activităților de verificare și calificare și interacțiunile acestora. În plus, poate aborda probleme legate de raportarea defecțiunilor și documentația cerințelor.

Revizuire și Audituri

Cinci tipuri de evaluări și audituri:

• Recenzii de management
• Recenzii tehnice
• Inspecții
• „Trecere”
• Audituri

Recenzii de management

Scopul evaluărilor de management este de a urmări dezvoltarea<проекта/продукта>, determinarea stării planurilor și programelor, aprobarea cerințelor și alocarea resurselor sau evaluarea eficienței abordărilor de management utilizate pentru atingerea obiectivelor declarate.

Evaluările managementului sprijină deciziile de a face modificări și de a lua măsuri corective necesare în timpul implementării unui proiect software.

Evaluările conducerii determină caracterul adecvat al planurilor, programelor și cerințelor, monitorizându-se în același timp progresul sau nerespectarea acestora. Aceste evaluări pot fi efectuate asupra produsului, fiind înregistrate sub formă de rapoarte de audit, rapoarte de stare (dezvoltare), rapoarte V&V, precum și diverse tipuri de planuri - managementul riscului de proiect/managementul proiectului, managementul configurației, securitatea.<использования>software (siguranță), evaluarea riscurilor etc.

Recenzii tehnice

Scopul evaluărilor tehnice este de a examina un produs software pentru a determina adecvarea acestuia pentru scopul propus. Scopul este de a identifica abaterile de la specificațiile și standardele aprobate. Pentru asigurarea evaluărilor tehnice trebuie repartizate următoarele roluri: decident; lider de revizuire; recorder; precum și personalul tehnic care susține (realizează direct) activitățile de evaluare.

Evaluarea tehnică necesită, fără greșeală, următoarele date de intrare:

• Declarații de obiective
• Un produs software specific (în curs de evaluare)
• Un plan de proiect dat (plan de management al proiectului)
• Lista problemelor (intrebărilor) asociate produsului
• Proceduri de evaluare tehnică

Echipă<технической оценки> urmează o procedură de evaluare specificată. Persoanele calificate (din punct de vedere tehnic) oferă o imagine de ansamblu asupra produsului (reprezentând echipa de dezvoltare). Studiu<продукта> desfășurate în cadrul uneia sau mai multor întâlniri (între cei care prezintă produsul și cei care asigură evaluarea). Evaluarea tehnică este finalizată după ce toate activitățile de investigare a produsului prescrise au fost finalizate.

Inspecții

Scopul inspecțiilor este de a detecta și identifica anomalii într-un produs software. Există două diferențe majore între inspecții și evaluări (manageriale și tehnice):

1. Persoanele care dețin funcții de conducere (manager) în legătură cu orice membru al echipei de inspecție nu ar trebui să participe la inspecții.
2. Inspecția ar trebui să fie condusă de un lider imparțial (independent de proiect și de obiectivele acestuia) instruit în tehnici de inspecție.

Inspecția software-ului implică întotdeauna autorii produsului intermediar sau final, spre deosebire de evaluări, care nu necesită neapărat acest lucru. Inspecțiile (ca unități organizatorice temporare - grupuri, echipe) includ un lider, un registrator, un examinator și mai mulți (2 până la 5) inspectori. Membrii echipei de inspecție se pot specializa în diferite domenii de expertiză (au domenii de competență diferite), de exemplu, domeniul subiectului, metodele de proiectare, limbajul etc. La un moment dat (perioada) de timp, inspecțiile sunt efectuate în legătură cu un mic fragment separat al produsului (în majoritatea cazurilor, concentrându-se pe caracteristicile funcționale individuale sau pe alte caracteristici; adesea, pornind de la regulile de afaceri individuale, cerințele funcționale sau atributele de calitate). , nota autorului). Fiecare membru al echipei ar trebui să examineze produsul software și alte intrări înainte de întâlnirea de inspecție, poate aplicând diferite tehnici analitice la porțiuni mici ale produsului sau la produsul în ansamblu, în acest din urmă caz ​​analizând doar un aspect al acestuia, cum ar fi interfețe. Orice anomalie găsită trebuie documentată și informațiile comunicate conducătorului inspecției. În timpul procesului de inspecție, liderul conduce sesiunea<инспекции>și verifică că totul<члены команды>pregătit pentru inspecție.

Un instrument comun utilizat în inspecții este o listă de verificare care conține anomalii și întrebări legate de aspecte<программного продукта>, stârnind interesul. Foaia rezultată clasifică adesea anomaliile și este evaluată de echipă pentru completitudine și acuratețe. Decizia de a finaliza o inspecție se ia în conformitate cu unul (oricare) din trei criterii:

1. Adopţie<продукта>fără nevoie sau fără nevoie de procesare
2. Adopţie<продукта>cu verificarea fragmentelor procesate
3. Nevoie de reinspectare

Întâlnirile de inspecție durează de obicei câteva ore, spre deosebire de evaluările și auditurile tehnice, care în cele mai multe cazuri implică mai multă muncă și, prin urmare, durează mai mult.

Walk-throughs

Scopul rulării este de a evalua produsul software. Testul poate fi efectuat cu scopul de a familiariza (instrui) publicul cu produsul software.

Principalele obiective ale cursei sunt:

• Caut anomalii
• Îmbunătățirea produsului
• Discuție despre modalități alternative de implementare
• Evaluarea conformității cu standardele și specificațiile

O prezentare este similară cu o inspecție, totuși, de obicei, este efectuată într-un mod mai puțin formal. Practic, cursa este organizată de ingineri pentru alți membri ai echipei pentru a obține feedback de la aceștia asupra muncii lor, ca unul dintre elementele (tehnicile) de asigurare a calității.

Audituri

Scopul unui audit software este evaluarea independentă a produselor și proceselor software pentru conformitatea cu reglementările, standardele, liniile directoare, planurile și procedurile aplicabile.

Auditul este o activitate organizată formal în care participanții îndeplinesc roluri specifice, cum ar fi auditor principal, alt auditor, înregistrare și inițiator. La audit participă un reprezentant al organizației/unității organizaționale care este evaluată. În urma auditului, sunt identificate cazuri de neconformitate și este generat un raport solicitat de echipă<разработки>pentru a lua măsuri corective.

Deși există diverse denumiri formale (și clasificări) pentru evaluări și audituri, este important de reținut că aceste tipuri de activități pot fi efectuate pe aproape orice produs în orice stadiu al procesului de dezvoltare sau întreținere.

Consideratii practice

Cerințe de calitate software

Factori de influență

Planificarea, managementul și selecția activităților și tehnicilor SQM sunt influențate de diverși factori, printre care:

• Domeniul de aplicare al sistemului în care va funcționa software-ul (critică de siguranță)<людей>), critică pentru afaceri etc.)
• Cerințe de sistem și software
• Ce componente sunt utilizate în sistem - comercial (extern) sau standard (intern)
• Ce standarde de inginerie software sunt aplicabile într-un context dat?
• Care sunt metodele și instrumentele software utilizate pentru dezvoltare și întreținere, precum și pentru asigurarea și îmbunătățirea calității (produs și procese)
• Bugetul, personalul, organizarea activităților proiectului, planuri și grafice pentru toate procesele
• Cine sunt utilizatorii țintă și care este scopul sistemului
• Nivel de integritate a sistemului

Informațiile despre acești factori influențează modul în care exact procesele SQM vor fi organizate și documentate, ce activități SQM vor fi selectate (standardizate în cadrul unui proiect, echipă, unitate organizațională, organizație), ce resurse sunt necesare și ce restricții sunt impuse eforturilor îndreptate către asigura calitatea.

Fiabilitate

Garantiabilitatea- garanție<высокой>fiabilitate, protecție împotriva defecțiunilor.
În cazurile în care o defecțiune a sistemului poate duce la consecințe extrem de grave (astfel de sisteme sunt uneori numite „sistem de înaltă încredere” sau „sistem de integritate ridicată” în sursele în limba engleză, în rusă ele sunt uneori denumite „sisteme de înaltă fiabilitate”, „sisteme de înaltă fiabilitate”. disponibilitate” și etc.), capacitatea generală (cumulativă) de garanție a sistemului (ca o combinație de hardware, software și oameni) este principala și prioritară cerință de calitate în raport cu funcționalitatea principală.<системы>.

Fiabilitate software-ul include caracteristici precum toleranța la erori, siguranța utilizării (siguranță - siguranță în contextul unui risc acceptabil pentru sănătatea umană, afaceri, proprietate etc.), securitatea sau securitatea informațiilor (securitatea - protecția informațiilor împotriva operațiunilor neautorizate, inclusiv accesul la citire, precum și garantarea disponibilității informațiilor pentru utilizatorii autorizați, în măsura drepturilor care le sunt atribuite), precum și comoditatea și ușurința de utilizare (utilizabilitate). Fiabilitatea este, de asemenea, un criteriu care poate fi definit în termeni de garanție.

În discuția acestei probleme, literatura extinsă despre sistemele de înaltă fiabilitate joacă un rol semnificativ. Totodată, se folosește terminologie care provine din domeniul sistemelor mecanice și electrice tradiționale (inclusiv cele care nu includ software) și descrie conceptele de pericol, riscuri, integritate a sistemului etc.

Nivelurile de integritate ale software-ului

Nivel de integritate software determinată pe baza consecințelor posibile ale unei defecțiuni software și a probabilității ca o astfel de defecțiune să apară. Atunci când diferite aspecte ale siguranței (aplicații și securitatea informațiilor) sunt importante, tehnicile de analiză a pericolelor (în contextul siguranței utilizării) și a amenințărilor (în contextul securității informațiilor) pot fi utilizate pentru a dezvolta planuri de lucru pentru a identifica posibilele puncte fierbinți de accidente. . Un istoric al defecțiunilor unor sisteme similare poate ajuta, de asemenea, la identificarea celor mai utile tehnici pentru detectarea defecțiunilor și<всесторонней>evaluarea calității software-ului.

Atunci când luăm în considerare integritatea software-ului mai detaliat în contextul unor proiecte specifice, este necesar să se acorde o atenție deosebită (alocarea resurselor adecvate și efectuarea lucrărilor necesare) nu numai proceselor SQM (în special celor formale, inclusiv audit și certificare), ci și la aspecte de management al cerințelor (din punct de vedere al integrității criteriilor), managementul riscului (inclusiv planificarea riscurilor atât în ​​etapa de dezvoltare, cât și în etapa de exploatare și întreținere a sistemului), proiectare (care, pentru creșterea capacității de garanție, implică în mod necesar o -analiza si verificarea in profunzime a solutiilor arhitecturale si tehnologice planificate pentru utilizare, deseori prin realizarea de proiecte pilot, standuri demonstrative etc.) si testare (pentru a asigura un studiu cuprinzator al caracteristicilor comportamentale ale sistemului, inclusiv emularea mediului de operare). /configurația în care sistemul trebuie utilizat în timpul funcționării).

Caracterizarea defectelor

Procesele SQM asigură găsirea defectelor. Descrierea caracteristicilor defectelor joacă un rol fundamental în înțelegerea produsului, facilitează ajustările procesului sau produsului și informează managerii de proiect și clienții despre starea procesului sau a produsului. Există multe taxonomii (clasificări și metode de structurare) ale defectelor (eșecurilor). Caracterizarea defectelor este, de asemenea, utilizată în audit și evaluări, unde liderul de evaluare prezintă adesea o listă de anomalii întocmită de membrii echipei de evaluare pentru a fi discutate la întâlnirile corespunzătoare.

Pe fundalul evoluției (și apariției de noi) metode și limbaje de proiectare, împreună cu noile tehnologii software, apar noi clase de defecte. Acest lucru necesită un efort enorm pentru a interpreta (și corecta) clasele de defecte (eșecuri) definite anterior. Când urmărește defectele, inginerul este interesat nu numai de numărul lor, ci și de tipul lor. Repartizarea defectelor pe tip este deosebit de importantă pentru identificarea celor mai slabe elemente ale sistemului, în ceea ce privește tehnologiile și soluțiile arhitecturale utilizate, ceea ce duce la necesitatea studierii aprofundate a acestora, realizarea de proiecte pilot de specialitate, dovezi suplimentare. de concept (POC - o abordare frecvent utilizată atunci când se utilizează noile tehnologii), atragerea de experți terți etc. Informația în sine, fără clasificare, este adesea pur și simplu inutilă pentru identificarea cauzelor defecțiunilor, deoarece pentru a determina modalități de rezolvare a problemelor, este necesar să le grupați în tipuri adecvate. Întrebarea este de a defini o taxonomie a defectelor care să fie semnificativă pentru ingineri și pentru organizație în ansamblu.

SQM asigură colectarea de informații în toate etapele de dezvoltare și întreținere software. De obicei, când spunem „defect”, ne referim la „eșec”, așa cum este definit mai jos. Cu toate acestea, culturi și standarde diferite pot implica semnificații diferite pentru acești termeni.

Definițiile parțiale ale conceptelor de acest fel sunt următoarele:

• Eroare:„Diferența... dintre rezultatul corect și rezultatul calculat<полученным с использованием программного обеспечения>”
• Defect:„Pas, proces sau definiție incorectă a datelor într-un program de calculator.”
• Eșec: “<Некорректный>rezultatul obținut ca urmare a unei deficiențe”
• Eroare umană/utilizator (greșeală):„O acțiune umană care a dus la un rezultat incorect”

Când discutăm acest subiect, un defect este înțeles ca rezultat al unei defecțiuni software. Modelele de fiabilitate sunt construite pe baza datelor de defecțiuni colectate în timpul testării sau utilizării software-ului. Astfel de modele pot fi folosite pentru a prezice eșecurile viitoare și pentru a ajuta la deciderea dacă să oprească testarea.

Pe baza rezultatelor muncii SQM care vizează detectarea defectelor, se întreprind acțiuni pentru eliminarea defectelor din produsul studiat. Cu toate acestea, problema nu se termină aici. Există și alte acțiuni posibile pentru a profita din plin de rezultatele muncii relevante SQM. Printre acestea se numără analiza și rezumatul (rezumatul)<по обнаруженным несоответствиям/дефектам>, utilizarea tehnicilor de evaluare cantitativă (obținerea de metrici) pentru îmbunătățirea produsului și a procesului, urmărirea defectelor și eliminarea acestora din sistem (cu management și control tehnic al acțiunilor corective necesare). La rândul său, sursa de informații pentru îmbunătățirea procesului, în special, este procesul SQM.

Datele privind inconsecvențele și defectele găsite în timpul implementării tehnicilor SQM relevante trebuie înregistrate pentru a preveni pierderea acestora. Pentru unele tehnici (de exemplu, evaluare tehnică, audit, inspecții), prezența unui înregistrator este obligatorie, tocmai pentru a înregistra astfel de informații, împreună cu problemele (inclusiv cele care necesită o atenție suplimentară) și deciziile luate. În cazurile în care sunt utilizate instrumente de automatizare adecvate, acestea pot oferi, de asemenea, informațiile de ieșire necesare despre defecțiuni (de exemplu, statistici rezumate privind stările defectelor, persoanele responsabile etc.). Datele defectelor pot fi colectate și înregistrate sub formă de cereri de modificare a software-ului (SCR) și ulterior pot fi introduse în anumite tipuri de baze de date (de exemplu, pentru a urmări statisticile istorice/inter-proiect pentru analize ulterioare și îmbunătățirea procesului), atât manual, cât și automat din instrumente de analiză adecvate (o serie de instrumente moderne de proiectare și instrumente specializate vă permit să analizați codul și modelele folosind metrici adecvate care sunt semnificative pentru asigurarea calității produselor și proceselor). Rapoartele de defecțiuni sunt transmise la nivelul de conducere al organizației/unității sau structurii organizaționale (pentru a lua decizii adecvate cu privire la proiect, produs, proces, personal, buget etc.).

Tehnici de management al calității software

Tehnicile SQM pot fi clasificate în mai multe categorii:

• static
• tehnici care necesită utilizarea intensivă a resurselor umane
• analitic
• dinamic

Tehnici statice

Tehnicile statice implică<детальное>cercetarea (examinarea) documentației de proiectare, software și alte informații despre un produs software fără executarea acestuia. Aceste tehnici pot include alte activități de evaluare „colectivă” sau de analiză „individuală” discutate mai jos, indiferent de măsura în care este utilizată automatizarea.

Tehnici intensive de oameni

Forma acestor tipuri de tehnici, inclusiv evaluarea și auditul, poate varia de la întâlniri formale până la întâlniri informale sau discuții despre produs, fără măcar a se referi la codul acestuia. De obicei, acest tip de tehnică implică interacțiune față în față între cel puțin doi și, în majoritatea cazurilor, mai mulți specialiști. În același timp, astfel de întâlniri pot necesita o pregătire prealabilă (aproape întotdeauna legată de determinarea conținutului întâlnirilor, adică a listei problemelor de discutat). Resursele utilizate în astfel de tehnici, împreună cu artefactele studiate (produs, documentație, modele etc.), pot include diverse tipuri de liste de verificare și rezultatele tehnicilor analitice (discutate mai jos) și lucrări de testare. Aceste tehnici sunt discutate, de exemplu, în standardul 12207 atunci când se discută revizuirea și auditul.

Tehnici analitice

Inginerii software folosesc de obicei tehnici analitice. Din punctul de vedere al metodelor și abordărilor Agile, indivizii și interacțiunile presupun<непосредственное>comunicare și interacțiune constantă între membrii echipei.

Uneori, mai mulți ingineri folosesc aceeași tehnică, dar pe părți diferite ale produsului. Unele tehnici se bazează pe specificul instrumentelor utilizate, altele implică lucru „manual”. Mulți pot ajuta la găsirea directă a defectelor, dar cel mai adesea sunt folosite pentru a sprijini alte tehnici. O serie de tehnici includ, de asemenea, diferite tipuri de examinare (evaluare) ca element integral al analizei generale a calității. Exemple de astfel de tehnici sunt analiza complexității, analiza logicii de control (sau analiza fluxului de control) și analiza algoritmică.

Fiecare tip de analiză are un scop specific și nu toate tipurile sunt aplicabile fiecărui proiect. Un exemplu de tehnică de suport este analiza complexității, care este utilă pentru identificarea părților unui proiect de sistem care sunt prea complexe pentru a fi implementate, testate sau întreținute corect. Rezultatul analizei complexității poate fi folosit și pentru a dezvolta cazuri de testare. Tehnicile de detectare a defectelor, cum ar fi analiza logicii de control, pot fi utilizate și în alte cazuri. Pentru software-ul cu o logică algoritmică extinsă, este extrem de important să se aplice tehnici algoritmice, mai ales în cazurile în care un algoritm incorect (nu implementarea lui, ci logica, nota autorului) poate duce la rezultate catastrofale (de exemplu, software de avionică, pentru care siguranța). probleme de utilizare – siguranța joacă un rol decisiv).

Alte tipuri, mai formale, de tehnici analitice sunt cunoscute ca metode formale. Ele sunt folosite pentru a verifica cerințele și designul (desigur, doar ocazional, în practica actuală de dezvoltare de software industrial). Verificarea corectitudinii se aplică pieselor critice de software (care, în general, nu are prea mult de-a face cu metodele formale - aceasta este o modalitate naturală de a obține o calitate acceptabilă minimizând costurile). Cel mai adesea ele sunt utilizate pentru a verifica părți deosebit de importante ale sistemelor critice pentru misiune, de exemplu, cerințe specifice<информационной>siguranța și fiabilitatea.

Tehnici dinamice

În procesul de dezvoltare și întreținere a software-ului, trebuie să recurgeți la diferite tipuri de tehnici dinamice. Practic, acestea sunt tehnici de testare. Cu toate acestea, tehnicile de simulare, verificarea modelului și „execuția simbolică” pot fi considerate tehnici dinamice (execuția simbolică, implică adesea folosirea modulelor „fatice” în ceea ce privește logica care se execută, cu intrare și ieșire emulată atunci când se consideră scenariul general de comportamentul sistemelor multimodule uneori Acest termen include și alte tehnici, în funcție de sursa aleasă).

Revizuirea (citirea) codului este de obicei considerată o tehnică statică, dar un inginer cu experiență poate executa codul direct „în timp ce” îl citește (de exemplu, folosind instrumente interactive de depanare pas cu pas pentru a revizui sau a evalua codul altcuiva). Astfel, această tehnică poate fi discutată și ca dinamică. Astfel de discrepanțe în clasificarea tehnicilor arată în mod clar că, în funcție de rolul unei persoane într-o organizație, acesta poate accepta și aplica aceleași tehnici în moduri diferite.

În funcție de organizație<ведения>proiect, anumite lucrări de testare pot fi efectuate în timpul dezvoltării sistemelor software în procesele SQA și V&V. Deoarece planul SQM abordează problemele de testare, acest subiect include câteva comentarii despre testare.

Testare

Procese de confirmare<качества> , descris în SQA și V&V<планах>, examinează și evaluează orice rezultat (inclusiv produsul intermediar și final) asociat cu specificația cerințelor software pentru:

• trasabilitate
• consistenta
• completitudine/completitudine,
• corectitudine
• și execuția directă<требований>(performanţă).

O astfel de confirmare acoperă, de asemenea, orice artefacte de ieșire din procesele de dezvoltare și întreținere, colectare, analiză și cuantificare a rezultatelor. Activitățile SQA asigură că tipurile de teste adecvate (necesare în contextul proiectului dat) sunt planificate, proiectate și implementate, iar V&V - dezvoltarea de planuri de testare, strategii, scripturi și proceduri<тестирования>.
Problemele de testare sunt discutate în detaliu în zona de cunoștințe Testare. Două tipuri de testare urmează obiectivele stabilite de SQA și V&V, deoarece sunt responsabile pentru calitatea datelor utilizate în proiect:

• Evaluarea și testarea instrumentelor utilizate în proiect
• Testarea de conformitate (sau evaluarea testelor de conformitate) a componentelor și a produselor COTS (COTS - produs comercial de la raft, gata de utilizare) pentru utilizare în produsul creat.

Uneori, organizațiile independente V&V pot solicita capacitatea de a monitoriza procesul de testare și, în anumite cazuri, de a certifica (sau, mai des, de a documenta/înregistra) execuția efectivă.<тестов>pentru a se asigura că acestea sunt efectuate în conformitate cu procedurile specificate. Pe de altă parte, se poate face un apel către V&V pentru a evalua testarea în sine: suficiența planurilor și procedurilor, adecvarea și acuratețea rezultatelor.

Un alt tip de testare care se efectuează sub supravegherea unei organizații V&V este testarea terților. O astfel de terță parte nu este ea însăși dezvoltatorul produsului și nu este afiliată în niciun fel cu dezvoltatorul produsului. Mai mult, terțul este o sursă de evaluare independentă, de obicei acreditată pentru a avea acreditările corespunzătoare (de exemplu, organizația care a dezvoltat standardul, a cărei conformitate este evaluată de un expert independent și ale cărei acțiuni sunt confirmate de creatorul standardului). ). Scopul acestui tip de testare este verificarea conformității produsului cu un anumit set de cerințe (de exemplu, securitatea informațiilor).

Măsurarea calității software-ului

Modelele de calitate a produselor software includ adesea indicatori pentru a determina nivelul fiecărei caracteristici de calitate pe care o are un produs.

Dacă caracteristicile de calitate sunt alese corect, astfel de măsurători pot susține calitatea (nivelul de calitate) în multe feluri. Valorile pot ajuta la ghidarea procesului de luare a deciziilor. Metricurile pot ajuta la identificarea aspectelor problematice și a blocajelor în procese. Metricurile sunt un instrument pentru ingineri de a evalua calitatea muncii lor - atât în ​​scopurile definite de SQA, cât și din punctul de vedere al unui proces de îmbunătățire pe termen lung<достигаемого>calitate.
Odată cu creșterea complexității interne și a sofisticarii software-ului, problemele de calitate depășesc cu mult afirmarea faptului că software-ul funcționează sau nu. Întrebarea este cât de bine sunt atinse obiectivele de calitate cuantificate.

Există câteva alte subiecte care discută valorile care susțin direct SQM. Acestea includ asistență pentru a decide când să se oprească testarea. În acest context, modelele de fiabilitate și comparațiile cu mostre (standarde acceptate ca exemple de o anumită calitate - benchmarks) par utile.

Costul procesului SQM este unul dintre<проблемных>întrebări care apar întotdeauna în procesul de decizie a modului în care va fi organizat proiectul (lucrul de proiectare). Adesea, se folosesc modele de cost generice, bazate pe determinarea exactă a momentului în care este descoperit un defect și a cât de mult efort este necesar pentru a-l corecta comparativ cu situația în care defectul a fost găsit mai devreme în ciclul de viață. Datele de proiectare pot oferi o imagine mai clară a costurilor.

În cele din urmă, raportarea SQM în sine oferă informații utile nu numai despre procesele în sine (care implică starea lor actuală, nota autorului), ci și despre modul în care toate procesele ciclului de viață pot fi îmbunătățite.

Deși estimările cantitative (în acest caz vorbim despre rezultatele evaluărilor, și nu despre procesul de măsurare) ale caracteristicilor calității pot fi utile în sine (de exemplu, numărul de cerințe neîndeplinite și proporția acestor cerințe), ele pot fi utile.<эффективно>aplica tehnici matematice si grafice pentru a facilita interpretarea valorilor metrice. Astfel de tehnici sunt clasificate în mod destul de natural, de exemplu, după cum urmează:

• Pe baza metodelor statistice (de exemplu, analiza Pareto, distribuția normală etc.)
• Teste statistice
• Analiza tendințelor
• Predicție (de exemplu, modele de fiabilitate)

Tehnicile bazate pe statistici și testele statistice oferă adesea un „instantaneu” al celor mai problematice zone ale produsului software studiat (și, apropo, același lucru este adesea valabil și pentru procese). Graficele și diagramele rezultate ajută vizual factorii de decizie în identificarea zonelor pe care să se concentreze resursele<проекта>. Rezultatele analizei tendințelor pot arăta că programul este încălcat, de exemplu, în timpul testării; sau că eșecurile anumitor clase devin din ce în ce mai frecvente până când se iau măsuri corective în timpul dezvoltării. Tehnicile de predicție ajută la planificarea timpilor de testare și la prezicerea eșecurilor.

Caracteristici de calitate software

Portabilitate- Un set de atribute legate de capacitatea software-ului de a fi transferat dintr-un mediu în altul.
NOTĂ Mediul poate include mediul organizațional, tehnic sau software.

Fiabilitate- Un set de atribute legate de capacitatea software-ului de a-și menține nivelul de performanță în condiții specificate pe o anumită perioadă de timp.

Note:

1. Nu există uzură sau îmbătrânire a software-ului. Limitările de fiabilitate apar din cauza erorilor în cerințe, proiectare și implementare. Eșecurile datorate acestor erori depind de modul în care este utilizat software-ul și de versiunile de software selectate anterior.
2. ISO 8402 definește „fiabilitatea” ca „capacitatea unui element de a îndeplini o funcție cerută”. În acest standard, funcționalitatea este doar una dintre caracteristicile calității software-ului. Prin urmare, definiția fiabilității a fost extinsă pentru a „își menține nivelul de performanță” în loc de „a îndeplini o funcție necesară”.

Utilizabilitate- Un set de atribute referitoare la domeniul de activitate necesar pentru utilizare și evaluarea individuală a unei astfel de utilizări de către un set specificat sau preconizat de utilizatori.

Note:

1. „Utilizatorii” pot fi interpretați ca fiind majoritatea utilizatorilor direcți ai software-ului interactiv. Utilizatorii pot include operatori, utilizatori finali și utilizatori indirecti care sunt afectați de sau depind de utilizarea software-ului. Practicitatea trebuie luată în considerare în gama de condiții de operare a utilizatorului care pot afecta software-ul, inclusiv pregătirea pentru utilizare și evaluarea rezultatelor.
2. Utilizabilitatea, definită în acest standard ca un set specific de atribute ale unui produs software, diferă de definiție din punct de vedere ergonomic, unde alte caracteristici precum eficiența și ineficiența sunt considerate componente ale utilizabilității.

Mentenabilitatea- Un set de atribute legate de domeniul de activitate necesar pentru a efectua modificări specifice (modificări).
NOTĂ Modificarea poate include corecții, îmbunătățiri sau adaptare a software-ului la schimbările de mediu, cerințe și condiții de operare.

Funcționalitate- Un set de atribute legate de esența setului de funcții și proprietățile specifice ale acestora. Funcțiile sunt acelea care îndeplinesc nevoile declarate sau anticipate.

Note:

1. Acest set de atribute caracterizează ceea ce face software-ul pentru a satisface o nevoie, în timp ce alte seturi caracterizează în primul rând când și cum este realizat.
2. În această specificație, nota de definire a calității este luată în considerare pentru nevoile declarate și anticipate.

Eficienţă- Un set de atribute legate de relația dintre nivelul de calitate al operațiunii software și cantitatea de resurse utilizate în condiții specificate.
NOTĂ Resursele pot include alte produse software, hardware, materiale (de exemplu, hârtie de imprimat, dischete) și serviciile personalului de operare, întreținere sau întreținere.

Calitatea produsului software

Calitatea software-ului- întregul domeniu al caracteristicilor și caracteristicilor unui produs software care se referă la capacitatea acestuia de a satisface nevoile stabilite sau anticipate.

Importanța fiecărei caracteristici de calitate variază în funcție de clasa de software. De exemplu, fiabilitatea este cea mai importantă pentru software-ul sistemelor critice pentru luptă, eficiența este cea mai importantă pentru software-ul sistemelor în timp real critice în timp și gradul de utilizare este cel mai important pentru software-ul de dialog cu utilizatorul final.

Importanța fiecărei caracteristici de calitate variază, de asemenea, în funcție de punctele de vedere adoptate.

Vizualizare utilizator

Utilizatorii sunt interesați în principal de aplicarea software-ului, de performanța acestuia și de rezultatele utilizării. Utilizatorii evaluează software-ul fără a examina aspectele interne ale acestuia sau modul în care software-ul a fost creat.

Utilizatorul poate fi interesat de următoarele întrebări:

• Are software-ul caracteristicile necesare?
• Cât de fiabil este software-ul?
• Cât de eficient este software-ul?
• Este software-ul ușor de utilizat?
• Cât de ușor este să transferi software și alte medii?

Vizualizarea dezvoltatorului

Procesul de creare necesită ca utilizatorul și dezvoltatorul să utilizeze aceleași caracteristici de calitate a software-ului pe care le folosesc pentru a stabili cerințele și acceptarea. Atunci când software-ul este dezvoltat pentru vânzare, cerințele de calitate trebuie să reflecte nevoile vizate.

Deoarece dezvoltatorii sunt responsabili pentru crearea de software care trebuie să îndeplinească cerințele de calitate, ei sunt la fel de interesați de calitatea produselor intermediare, precum și de calitatea produsului final. Pentru a evalua calitatea produselor intermediare în fiecare fază a ciclului de dezvoltare, dezvoltatorii trebuie să utilizeze metrici diferite pentru aceleași caracteristici, deoarece aceleași metrici nu se aplică tuturor fazelor ciclului de viață.

De exemplu, utilizatorul înțelege eficiența în termeni de timp de răspuns, în timp ce proiectantul folosește termenii de lungime a rutei și latența și timpul de acces în specificația de proiectare. Valorile utilizate pentru interfața externă a unui produs sunt interschimbabile cu valorile utilizate pentru structura acestuia.

Prezentarea managerului

Managerul poate fi mai interesat de calitatea generală decât de o anumită caracteristică de calitate și din acest motiv va trebui să determine importanța valorilor care reflectă cerințele de afaceri pentru caracteristicile individuale.
Managerul poate avea nevoie, de asemenea, să cântărească îmbunătățirile calității față de criteriile de control, cum ar fi întârzierile planificate sau depășirile de costuri, deoarece dorește să optimizeze calitatea în limitele costurilor, forței de muncă și timpului.

Evaluarea calității produsului software

Următoarea figură prezintă pașii principali necesari pentru evaluarea calității software-ului.

Figura „Modelul procesului de evaluare”

Procesul de evaluare constă din trei etape: stabilirea (definirea) cerințelor de calitate, pregătirea pentru evaluare și procedura de evaluare. Acest proces poate fi aplicat în orice fază adecvată a ciclului de viață pentru fiecare componentă software.
Scopul etapei inițiale este stabilirea cerințelor în ceea ce privește caracteristicile calității. Cerințele exprimă nevoile mediului extern pentru produsul software în cauză și trebuie determinate înainte de începerea dezvoltării.
Scopul celei de-a doua etape este pregătirea bazei de evaluare.
Rezultatul celui de-al treilea este o concluzie despre calitatea produselor software. Calitatea generală este apoi comparată cu alți factori, cum ar fi timpul și costul. Decizia finală de management se ia pe criteriul controlabilității. Rezultatul este o decizie a conducerii de a accepta sau de a respinge, sau de a elibera sau nu produse software.

Model de calitate a procesului

Procesul de dezvoltare trebuie să fie structurat în așa fel încât să poată fi măsurată calitatea produsului. Cercetările efectuate arată că, cu cât este mai mare calitatea procesului de dezvoltare, cu atât este mai mare calitatea software-ului dezvoltat în acest proces. Calitatea în fiecare etapă a proiectului crește, în primul rând, ca o consecință directă a maturității procesului, și în al doilea rând, datorită utilizării unui produs intermediar de calitate superioară produs în etapa anterioară. Se subliniază că importanța celui de-al doilea motiv, care asigură o creștere a calității pe parcursul ciclului de viață pentru procesele mature, se dovedește a fi mult mai importantă. Toate acestea pot fi reprezentate sub forma unui model.

Figura „Model conceptual al calității procesului de dezvoltare”

De aici rezultă următoarele consecințe:
În primul rând: calitatea se acumulează într-un produs într-o producție complexă în mod cumulativ, iar contribuția la calitate făcută în stadiile incipiente are un impact mai puternic asupra produsului final decât în ​​etapele ulterioare. Acest lucru este confirmat de toată practica de programare, de exemplu, se știe că deficiențele în proiectarea sistemului nu pot fi compensate prin codificare de înaltă calitate.
Astfel, pentru a gestiona calitatea construirii unui sistem complex, este necesară selectarea producătorilor pe baza măsurării gradului de maturitate și transparență a proceselor de dezvoltare utilizate. Măsurarea calității procesului de dezvoltare al antreprenorului este o parte importantă a managementului calității totale, mai importantă decât măsurarea calității produsului rezultat produs în timpul testării de acceptare.
În al doilea rând: testarea și măsurarea calității ar trebui să aibă loc în toate etapele ciclului de viață. Recuperarea datelor de calitate care au fost construite în stadiile incipiente poate fi foarte costisitoare fără rezultate complete

Ghid privind aplicarea caracteristicilor de calitate

1 Aplicabilitate

2 Idei despre calitatea software-ului

2.1 Vizualizarea utilizatorului
2.2 Introducerea dezvoltatorului
2.3 Prezentarea managerului

3.1 Stabilirea cerințelor de calitate

3.2 Pregătirea pentru evaluare

3.2.1 Selectarea parametrilor de calitate (indicatori)
3.2.2 Determinarea nivelurilor de clasare
3.2.3 Definirea criteriului de evaluare

3.3 Procedura de evaluare

3.3.1 Măsurare
3.3.2 Clasament
3.3.3 Evaluare

1. Introducere

2 Definirea indicatorilor de calitate comprehensivă

2.1 Funcționalitate

2.1.1 Adecvare
2.1.2 Precizie
2.1.3 Interoperabilitate
2.1.4 Conformitate
2.1.5 Securitate

2.2 Fiabilitate

2.2.1 Stabilitate (Maturitate)
2.2.2 Toleranța la erori
2.2.3 Recuperare

2.3 Utilizabilitate

2.3.1 Înțelegerea
2.3.2 Capacitatea de învățare
2.3.3 Ușurință în utilizare (operabilitate)

2.4 Eficiențe

2.4.1 Comportament în timp
2.4.2 Comportamentul resurselor

2.5 Mentenabilitatea

2.5.1 Analizabilitatea
2.5.2 Schimbare
2.5.3 Stabilitate
2.5.4 Testabilitate

2.6 Portabilitate

2.6.1 Adaptabilitate
2.6.2 Ușurință de implementare (Instabilitate)
2.6.3 Conformitate
2.6.4 Înlocuit

Note:

1. Interschimbabilitatea este utilizată în loc de compatibilitate pentru a evita posibilele confuzii cu interoperabilitatea.
2. Interschimbabilitatea cu un anumit instrument software nu implică faptul că instrumentul este interschimbabil cu instrumentul software în cauză.
3. Interschimbabilitatea poate include atribute de ușurință în implementare și adaptabilitate. Conceptul a fost introdus ca o subcaracteristică separată datorită importanței sale.

Calitatea proiectului

Calitatea include toate activitățile proiectului care asigură că proiectul îndeplinește obiectivele pentru care a fost întreprins. Prin urmare, managementul calității se aplică atât proiectului, cât și produsului proiectului.
Calitatea este extrem de importantă deoarece exprimă și înregistrează obiectivele, făcându-le documentate (formalizate).
Prin urmare, calitatea este o componentă critică a managementului structurii proiectului.
Pentru calitate, totul este măsurabil.

Managementul calitatii proiectelor

Dacă managementul calității este concentrat într-o singură parte a organizației, acesta nu va deveni universal. Managerul de proiect poate delega aspecte ale managementului calității. Managerul de proiect își păstrează responsabilitatea finală.

Principii de calitate (ISO 9000)

1. Orientarea către client
2. Responsabilitatea managementului
3. Angajarea oamenilor
4. Abordarea procesuala
5. Abordare sistematică a managementului
6. Imbunatatire continua
7. Luarea deciziilor bazate pe fapte
8. Relații reciproc avantajoase cu furnizorii

Figura „Diferențe în înțelegerea managementului calității în ISO 9000 și PMBoK”

Managementul calității proiectelor (PMI): Sub-procese

• Planificarea calitatii
• Asigurarea calității
• Control de calitate

Planificarea calitatii

Una dintre etape este determinarea standardelor existente care se aplică unui proiect dat și cum să le respecte. Rezultatul planificării calității este o listă a tuturor standardelor de calitate care se aplică proiectului. Este atașată o listă de recomandări cu privire la modul în care vor fi îndeplinite cerințele acestor standarde.

Procesul de planificare a calității: intrări

• Politica de calitate. Un document care conține principii pentru modul în care o organizație definește calitatea, dar nu conține modalități de a atinge calitatea.
• Conținutul proiectului (sfera). Definește ce trebuie făcut ca rezultat al proiectului și, prin urmare, ce trebuie monitorizat în procesele de management al calității. Acest document este rezultatul procesului de planificare a domeniului de aplicare al proiectului.
• Descriere produs. Conține detalii tehnice și alte aspecte relevante care pot afecta planificarea calității.
• Standarde și reglementări. O listă de standarde și reglementări relevante pentru o anumită zonă sau proiect.
• Alte documente.

Procesul de planificare a calității: instrumente și tehnologii

• Analiza beneficii/costuri. Relevant pentru discuția despre costul calității. Scopul acestui instrument este de a compara costul real al lipsei de calitate cu beneficiile asigurării calității.
• Comparaţie. Folosit pentru a genera idei de îmbunătățire prin comparație cu alte proiecte. Este cel mai eficient atunci când comparația se face cu cei mai buni, și nu doar cu alte proiecte interne.
• Diagrame. Folosit pentru a arăta modul în care diferitele elemente interacționează. Există multe tipuri de diagrame, inclusiv o diagramă cauză și efect.
• Stabilirea experimentelor. Folosiți scenarii ce se întâmplă dacă pentru a determina care variabile sunt cele mai influente asupra rezultatului final al proiectului.
• Costul calității.

Procesul de planificare a calității: rezultate, rezultate

• Plan de management al calitatii. Descrie modul în care echipa de management al proiectului va implementa politica de calitate. Ar trebui să acopere următoarele domenii:
• Controlul proiectării.
• Controlul documentației.
• Controlul aprovizionării materialelor.
• Inspecții.
• Controlul testelor (testare).
• Controlul asupra echipamentelor de control și măsurare.
• Acțiuni corective.
• Înregistrări de calitate.
• Audituri (plan si procedura)
• Proceduri documentate și instrucțiuni de lucru. Ele descriu în detaliu procesele și modul de măsurare a calității procesului, subprocesului și acțiunilor individuale efectuate.
• Liste de verificare. Liste de întrebări pentru a verifica dacă nu lipsește nimic.

Asigurarea calității

Procesul de asigurare a calității- aceasta este adoptarea de măsuri sistematice planificate pentru a asigura implementarea tuturor proceselor specificate necesare pentru ca proiectul (produs, serviciu) să îndeplinească cerințele de calitate.
Asigurarea calității este principalul subproces al managementului calității. Această activitate continuă pe tot parcursul proiectului.

Proces de calitate: intrări

• Instructiuni de lucru. Un alt rezultat al procesului de planificare a calității.
• Rezultatele măsurătorilor de control al calității. Ieșirea procesului de control al calității.

Procesul de asigurare a calității: instrumente și tehnici

Instrumente și tehnici de planificare a calității. Acestea includ analiza cost-beneficiu, comparații, diagrame, design experimental și evaluări cost-calității.

Audituri de calitate

„Înregistrări” structurate care confirmă „lecțiile învățate”. Tipurile de audit de calitate sunt:

• intern extern,
• sistem / produs / proces / organizare,
• planificat/regulat,
• deosebite si complicate.

Procesul de asigurare a calității: rezultate

Imbunatatire a calitatii. Implica întreprinderea de acțiuni pentru creșterea eficienței și productivității proiectului pentru a oferi beneficii suplimentare proprietarilor de proiect.

Control de calitate

Monitorizarea anumite rezultate pentru a determina conformitatea acestora cu standardele de calitate acceptate și pentru a identifica modalități de eliminare a cauzelor performanței nesatisfăcătoare.

Procesul de control al calității: intrări

• Rezultatele lucrării. Rezultatele apar întotdeauna în procesul de colaborare, execuție și replanificare a proiectului.
• Plan de management al calitatii. Ieșirea procesului de planificare a calității.
• Instructiuni de lucru. Ieșirea procesului de planificare a calității.
• Liste de verificare.

Controlul calității: instrumente și tehnici

• Inspecții. Include activități precum măsurarea, testarea, testarea pentru a se asigura că rezultatul îndeplinește cerințele.
• Diagrame de control. Graficele de rulare definesc statistic limitele superioare și inferioare, reflectate de ambele părți ale mediilor procesului.
• Diagrame: Ishikawa, Pareto.
• Eșantionarea statistică.
• Analiza tendințelor.

« Scopul utilizării instrumentelor– înregistrați rezultatele sau modificările, afișați-le grafic și apoi identificați și corectați problemele într-un mod adecvat.”

Procesul de control al calității: ieșiri

• Imbunatatire a calitatii. Ieșirea din procesul de asigurare a calității.
• A lua decizii. Deciziile se iau în funcție de faptul dacă obiectul inspectat este acceptat sau respins.
• Acțiuni corective. O acțiune întreprinsă pentru a aduce un obiect neconform în conformitate.
• Liste de verificare completate.
• Configurarea procesului.

Referințe

• http://sorlik.blogspot.com, Sergey Orlik, 2004-2005
• Genelt A.E. Manual educațional și metodologic pentru disciplina „Managementul calității dezvoltării software” 2007, Sankt Petersburg

Adnotare: Sunt luate în considerare caracteristicile de calitate ale produselor software. Se observă că problemele de calitate trebuie abordate pe tot parcursul ciclului de viață. Se arată că testarea unui produs software ne permite să garantăm parametrii de calitate specificați. Sunt luate în considerare diferite tipuri de teste și instrumente de testare în VisualStudio 2012. Se arată că refactorizarea codului îmbunătățește calitatea produsului software.

Puteți descărca prezentarea pentru această prelegere.

Scopul prelegerii:

Obțineți o înțelegere a metodelor și instrumentelor pentru asigurarea calității produselor software.

Introducere

Calitatea produsului software determinate de mai multe criterii. Calitativ software trebuie să îndeplinească cerințele funcționale și nefuncționale în conformitate cu care a fost creat, să aibă valoare de afaceri și să îndeplinească așteptările utilizatorilor.

În ciclul de viață al managementului aplicației, calitatea trebuie monitorizată în toate etapele ciclului de viață al software-ului. Începe să se formeze prin identificarea cerințelor necesare. La specificarea cerințelor, este necesar să se indice funcționalitatea dorită și modul de verificare a realizării acesteia.

Calitativ software trebuie să aibă calitate ridicată de consumator, indiferent de domeniul de aplicare: utilizare internă de către dezvoltator, afaceri, știință și educație, medicină, vânzări comerciale, sfera socială, divertisment, web etc. Pentru utilizator software trebuie să satisfacă un anumit nivel al nevoilor sale.

Un aspect important al creării de software de înaltă calitate este asigurarea cerințelor nefuncționale, cum ar fi ușurința în utilizare, fiabilitatea, performanţă, Securitate, ușurința întreținerii. Fiabilitatea software-ului determină capacitatea de a efectua anumite funcții fără defecțiuni în condiții specificate și pentru o anumită perioadă de timp. Performanţă caracterizat prin timpul de execuție a tranzacțiilor specificate sau a operațiunilor de lungă durată. Securitatea determină gradul în care un sistem este protejat de daune, pierderi, acces neautorizat și activități criminale. Ușurință de întreținere definește ușurința cu care un produs poate fi întreținut în termeni de ușurință în remedierea defectelor, efectuarea de ajustări pentru a îndeplini noile cerințe și gestionarea unui mediu schimbat.

Managementul ciclului de viață al produsului software îi ajută pe dezvoltatori să realizeze în mod intenționat crearea de software de înaltă calitate și să evite pierderea timpului cu reproiectarea, reproiectarea și reprogramarea software-ului.

Testarea software-ului

Testarea produselor software ne permite să ne asigurăm pe parcursul întregului ciclu de viață al software-ului că proiectele software îndeplinesc parametrii de calitate specificați. Scopul principal al testării este identificarea abaterilor în implementarea cerințelor funcționale, detectarea erorilor în execuția programului și corectarea lor cât mai devreme posibil în timpul proiectului.

De-a lungul ciclului de viață al dezvoltării software, sunt utilizate diferite tipuri de testare pentru a se asigura că lansările de etape îndeplinesc valorile de calitate specificate. În acest caz, se folosesc teste automate și manuale.

Testarea unitară	este destinat să verifice funcționarea corectă a metodelor claselor software. Testele unitare sunt scrise și executate de dezvoltatori în timpul procesului de codare. Testarea unitară este utilizată atât pentru a verifica calitatea codului aplicației, cât și pentru a verifica obiectele bazei de date.
	este destinat testării în care testatorul nu are scenarii de testare predefinite și încearcă să exploreze intuitiv capacitățile produsului software și să detecteze și să repare erori necunoscute.
Testarea integrării	utilizat pentru a verifica funcționarea corectă a componentelor produsului software.
Testare funcțională	presupune verificarea cerințelor software specifice și se realizează după adăugarea de noi funcții la sistem.
Testare stresanta	este destinat să testeze funcționalitatea unui produs software la sarcina maximă de intrare.
Testare de regresie	utilizat la efectuarea modificărilor software-ului pentru a verifica funcționarea corectă a componentelor sistemului care ar putea interacționa cu componenta modificată.
Testare cuprinzătoare	conceput pentru a testa cerințele funcționale și nefuncționale ale întregului sistem al unui produs software.
Testarea de acceptare	este un test funcțional care trebuie să confirme că produsul software îndeplinește cerințele și așteptările utilizatorilor și clienților. Testele de acceptare sunt scrise de analiști de afaceri, specialiști în asigurarea calității și testeri.

În calitate de dezvoltator de software, VisualStudio 2012 oferă posibilitatea de a crea teste de unitate, de încărcare și de interfață cu utilizatorul. VisualStudio 2012 oferă următoarele șabloane de proiect de testare:

• proiect de test unitar, care vă permite să creați teste unitare în timpul dezvoltării;
• proiect cu performanță web și teste de încărcare;
• un proiect cu teste UI codificate.

Setul de instrumente de testare din VisualStudio 2012 este MicrosoftTestManager (MTM). MTM este conceput pentru a gestiona ciclul de viață al testării software, inclusiv planificarea, testarea și monitorizarea. MTM este integrat cu TeamFoundationServer. Folosind Microsoft TestManager, testerii pregătesc planuri de testare și gestionează testarea. Când creați un plan de testare, adăugați suitele de testare, cazurile de testare și configurațiile necesare pentru testare. Configurațiile sunt folosite pentru a stabili mediul în care vor fi executate suitele de testare. Microsoft TestManager vă permite să rulați teste manuale, automate și exploratorii. Rezultatele testelor sunt stocate într-o bază de date, care vă permite să pregătiți diverse rapoarte analitice. Erorile identificate în timpul testării sunt înregistrate, documentate și transferate dezvoltatorilor pentru eliminare. Atunci când se fac modificări la codul unui sistem software, apare nevoia de testare de regresie, iar MTM generează automat un plan de testare de regresie, identificând ce teste trebuie reexecutate.

Pentru testerii și dezvoltatorii de software, VisualStudio 2012 include un manager de mediu virtual LabManagement. Instrumentele de testare LabManagement vă permit să creați o infrastructură care emulează cât mai aproape posibil mediul real al utilizării planificate a produsului software. Astfel de cadre pot fi folosite pentru a realiza build-uri automate, automatiza teste și executa cod dezvoltat.

Refactorizarea

Calitatea codului unui produs software este în mare măsură determinată de cât de dificil sau ușor este să faci modificări codului, precum și de cât de accesibil este codul de înțeles. Aplicația software generată poate îndeplini funcțiile necesare, dar are probleme la efectuarea modificărilor sau la înțelegerea codului generat. În acest caz, un astfel de software nu poate fi numit de înaltă calitate, deoarece în etapa de întreținere pot apărea probleme cu modificarea sa atunci când cerințele utilizatorului se modifică.

Pentru a îmbunătăți calitatea codului aplicației software, se utilizează refactorizarea [,]. Potrivit lui Fowler M., refactorizarea este definită ca „procesul de schimbare a unui sistem software în așa fel încât comportamentul său extern să nu se schimbe, dar structura sa internă să fie îmbunătățită”. În consecință, în procesul de proiectare pentru a crea un produs software de înaltă calitate, este necesar nu numai să se asigure îndeplinirea cerințelor funcționale, ci și a celor nefuncționale, în special, mentenabilitatea, care implică posibilitatea și ușurința de a face modificări la codul, precum și capacitatea de a înțelege cu ușurință codul creat.

Designul slab al codului este determinat de un număr de semne:

• rigiditate - o caracteristică a unui program care face dificilă efectuarea modificărilor codului;
• fragilitate - capacitatea unui program de a se deteriora în multe locuri atunci când se face o singură modificare;
• stagnarea se caracterizează prin faptul că codul conține părți care ar putea fi utile în alte sisteme, dar efortul și riscul pe care îl implică încercarea de a separa aceste părți ale codului de sistemul original este prea mare;
• complexitatea inutilă se caracterizează prin faptul că programul conține elemente care nu sunt utilizate în prezent;
• repetiție inutilă, care constă în bucăți repetate de cod într-un program;
• opacitatea, care caracterizează dificultatea de înțelegere a codului.

Pentru a crea un design de cod de înaltă calitate, este recomandabil să aplicați câteva principii și modele de proiectare software [,].

Principiul responsabilității unice prevede că o clasă ar trebui să aibă un singur motiv pentru schimbare. Din acest principiu rezultă că este recomandabil să se atribuie o singură responsabilitate unei clase.

Principiul deschis/închis determină că entitățile software (clase, module, funcții) trebuie să fie deschise pentru extindere, dar închise pentru modificare.

Principiul substituției Liskov determină că ar trebui să fie posibil să se înlocuiască oricare dintre subtipurile sale în loc de o clasă de bază.

Principiul inversării dependenței definește două prevederi:

• Modulele de nivel superior nu ar trebui să depindă de modulele de nivel inferior. Ambele trebuie să depindă de abstracții;
• abstracțiile nu ar trebui să depindă de detalii. Detaliile trebuie să depindă de abstracții.

Principiul separării interfețelor specifică că clienții ar trebui să fie conștienți doar de interfețele abstracte care au proprietatea de coeziune.

Modelele de design oferă soluții universale, testate în practică. Este oferită o listă extinsă de modele. Dintre lista generală de modele, ar trebui să le evidențiem pe cele care sunt adecvate pentru a fi utilizate în dezvoltarea agilă de software. Aceste modele sunt Echipă, Strategie, Fațadă, Mediator, Singleton, Fabrică, Compozitor, Observator, Server abstract/Adaptor/Gateway, Proxy și Gateway, Vizitator și Stat.

Utilizarea tiparelor în dezvoltare vă permite să creați software, care este ușor de modificat și întreținut.

Trebuie remarcat faptul că pentru a efectua refactorizarea este necesar să existe teste fiabile care să asigure conformitatea cu cerințele funcționale, îmbunătățind în același timp proiectarea codului software.

Termeni cheie

Testarea unitară	testare menită să verifice funcționarea corectă a metodelor claselor software.
Testare exploratorie	testare, în care testatorul nu are scenarii de testare predeterminate și încearcă să exploreze intuitiv capacitățile produsului software și să detecteze și să repare erori necunoscute.
Testarea integrării	testare menită să verifice funcționarea corectă a componentelor unui produs software.
Testare funcțională	testare concepută pentru a verifica cerințele software specifice, care se efectuează după adăugarea de noi funcții la sistem.
Testare stresanta	testare concepută pentru a verifica funcționalitatea unui produs software sub sarcină maximă de intrare.
Testare de regresie	testarea utilizată la efectuarea modificărilor software-ului pentru a verifica funcționarea corectă a componentelor sistemului care ar putea interacționa cu componenta modificată.
Testare cuprinzătoare	testare menită să verifice conformitatea cu cerințele funcționale și nefuncționale ale întregului sistem al unui produs software.
Testarea de acceptare	testarea, care este testarea funcțională care trebuie să confirme că produsul software îndeplinește cerințele și așteptările utilizatorilor și clienților.
MicrosoftTestManager	Instrumente Microsoft concepute pentru a gestiona ciclul de viață al testării software.
LabManagement	manager de mediu de testare virtuală.

Trusa de antrenament

Întrebări

1. Ce caracteristici ar trebui să aibă un produs software de înaltă calitate?
2. Ce cerințe nefuncționale determină calitatea unui produs software?
3. Care este rolul testării în asigurarea calității unui produs software?
4. Ce tipuri de teste sunt folosite pentru a verifica calitatea unui produs software?
5. Pentru ce este folosit testarea de regresie?
6. Ce șabloane de proiect de testare sunt disponibile în VisualStudio 2012?
7. Pentru ce este folosit MicrosoftTestManager? Ce functionalitate are?
8. Ce se utilizează LabManagement pentru testare?
9. Pentru ce se folosește refactorizarea codului?
10. Dați semne de cod de calitate scăzută.

Exerciții

1. Pregătiți o revizuire analitică a testării NUnit.
2. Pregătiți o revizuire analitică a testării xUnit.net.
3. Pregătiți o revizuire analitică a testării MbUnit.