Abordarea metrică a fost dezvoltată inițial exclusiv în scopuri de management de proiect și pentru a atinge conformitatea contractului. După ce obiectivele au fost atinse, acestea au devenit exemplu practic pentru studiu. Performanța proiectului CCPDS-R nu a fost niciodată aproape de optim; În timpul procesului de execuție, s-au făcut în mod constant un număr mare de erori. O afirmație similară este valabilă pentru programul de determinare a valorilor: uneori a măsurat lucrul greșit, alteori a măsurat lucrul greșit. Nu a contribuit la interpretarea timpurie și a folosit metode manuale unde era nevoie de automatizare. Cu toate acestea, lucrul cu valorile a dus la îmbunătățirea lucrului în echipă, la îmbunătățirea proceselor, la o mai bună înțelegere a riscurilor și, desigur, la un produs mai eficient. În primele etape ale proiectului, a existat rezistență din partea managementului, a dezvoltatorilor practici și chiar a monitorilor de progres.

contracta. După primul an și după câteva îmbunătățiri în interpretare, automatizare, prezentare și definiție, a existat un sprijin aproape unanim. Toate părțile au folosit date obiective din programul de metrici pentru a-și informa planurile, riscurile, direcțiile de dezvoltare și rezultatele.

Toate metricile prezentate Subsisteme scop general au fost extrase direct din revizuirile lunare ale managementului de proiect. Niciuna dintre aceste valori nu a fost creată după fapt. Deși un program de definire a parametrilor a fost o cerință contractuală, guvernul nu a specificat ce măsurători ar trebui utilizate. Acest lucru a fost lăsat la discreția contractantului, astfel încât echipa de proiect să preia proprietatea asupra programului de metrici ales.

TRW a formulat patru obiective de program pentru definirea metricilor:.

Furnizarea de date pentru a evalua tendințele actuale de performanță a proiectului și pentru a determina la ce să acordați atenție atunci când gestionați proiectul.

Furnizarea datelor pentru planificarea etapelor ulterioare și crearea altor subsisteme.

Furnizarea de date pentru a evalua dificultatea relativă de a îndeplini cerințele finale de calitate.

Furnizați date pentru a determina ce îmbunătățiri ale procesului sunt necesare și pentru a justifica nevoia acestora.

Următoarele sunt exemple specifice de metrici recomandate în Capitolul 13. Sunt oferite mai multe exemple de metrici pentru măsurarea progresului, precum și metrici de calitate pentru defecte, reprelucrare și finalizare. Descrie elementele de bază necesare automatizării; necesită niște abordări tehnice interesante care sunt conținute direct în produsele de lucru de proiectare și codificare.

D.7.1 Progresul dezvoltării.

Măsurare precisă progresul dezvoltării în prezența mai multor activități paralele în diferite etape a fost o problemă dificilă pentru echipă, gestionarea creației Subsisteme de uz general. A trebuit depus un efort considerabil pentru a dezvolta o abordare consecventă care să ofere informații exacte cu privire la starea la nivel de subsistem și la starea versiunii. Scopul a fost obținerea unei estimări ponderate care să includă următoarele:.

■ Valori Ada/ADL. Ele au făcut posibilă determinarea destul de precisă a indicatorilor direcți ai progresului tehnic. Aceste valori în sine au reflectat absolut exact progresul în dezvoltare și implementare. Cu toate acestea, acestea nu erau potrivite pentru a descrie părțile finalizate ale contractului și situația financiară.

■ Valori adăugate. Acestea au făcut posibilă determinarea destul de exactă a stării financiare și a părților contractului pregătite pentru livrare către client. În general, sunt indicatori slabi ai progresului tehnologic real.

Ca și în cazul majorității altor valori software, ambele abordări au furnizat inițial estimări inexacte ale progresului absolut. Cu toate acestea, au fost estimări excelente ale progresului relativ dacă au fost monitorizate în mod regulat (lunar în cazul nostru). Pe măsură ce experiența cu aceste valori a crescut, scorurile absolute au fost ajustate treptat pentru a prezice succesul sau riscul. Evaluările generale au fost rezumate într-un singur grafic. În fig. D.9 arată progresul rezultat la cel mai înalt nivel pentru fiecare versiune individuală și pentru Subsistemul cu scop general în ansamblu. Lungimea zonei umbrite din fiecare versiune în raport cu linia punctată (referitor la luna curentă) determină dacă execuția este înainte sau în urmă programului existent. De exemplu, figura arată starea după luna 17: testarea NT a versiunii 2 este cu o lună întârziere programată, dezvoltarea versiunii 3 este înaintea programului cu o lună, dezvoltarea

Orez. D.9. Progresul general al dezvoltării.

Subsistemul de uz general este conform programului, dar testarea HT a subsistemului de uz general este în întârziere cu o lună. Zonele umbrite sunt evaluarea dezvoltatorului principal, care a combinat valorile de progres lunar cu valorile lunare de sănătate financiară într-un scor rezumat (și, prin urmare, oarecum subiectiv).

Colectarea lunară de valori de metrică a oferit managementului înțelegerea detaliată a progresului, a creșterii codului și a altor metrici obținute pe fiecare versiune. Metricile sunt colectate pentru fiecare versiune și pentru CSCI pentru a fi considerate din unghiuri diferite. Managerii*fiecărei CSCI individuale și-au colectat și evaluat valorile înainte de a fi agregate pentru proiect în ansamblu. Procesul a fost obiectiv, eficient și semnificativ. Cel mai Nivel inferior Evaluările TBD_Statements au fost, desigur, subiective, dar au fost determinate de cei mai cunoscători: dezvoltatorii direcți. Scorurile au fost stocate în format cod sursă. În acest caz, a crescut probabilitatea ca acest tip de produs de lucru să depoziteze cel mai mult ultimele informatii. Acest proces a permis, de asemenea, compararea progresului în diferite domenii ale proiectului într-o manieră consecventă și uniformă.

În fig. D.10 furnizează estimări lunare de progres pentru Subsistemul cu scop general și pentru fiecare versiune. Volumul planificat al modificărilor s-a bazat pe un calcul aproximativ mediu ponderat pentru fiecare versiune, efectuat conform instrucțiunilor date în secțiunea D.5.3: 30% din volumul creat la momentul PSCP și 70% din volumul de către timpul KSCP. În general, subsistemul cu destinație generală a fost aproape exact așa cum era planificat, cu o singură excepție. Progresul realizat până la momentul PCAP (cu mult înainte de termen) a reflectat impactul pozitiv neașteptat al instrumentelor generatoare de sursă. Cu ajutorul acestuia, au fost generate peste 50.000 de SLOC-uri pentru SAPO.

Conformitatea lucrării cu planurile a variat în funcție de versiunea specifică. Progresul realizat pentru subsistem și pentru fiecare lansare a fost evaluat lunar de managementul intern și de client prin revizuiri ale managementului de proiect. Măsurile de progres au oferit un mecanism obiectiv și un limbaj convenit pentru descrierea modificărilor la planuri și arhitectură, probleme de proiectare, riscuri de programare și alte probleme legate de management. Obiectivitatea acestei abordări a fost componenta principală a relațiilor neantagoniste stabilite între toate părțile interesate.

Toată lumea a înțeles că, deși valorile metrice nu erau exacte în primele etape ale ciclului de viață, acestea erau corecte. Valorile absolute au fost rareori importante. Tendințele relative au fost mai importante și, pe măsură ce procesul a progresat, acuratețea tuturor valorilor a crescut. Până la momentul POP, valorile metrice au devenit piatra de temelie a comunicării proiectului.

Orez. D.10. Progrese în dezvoltarea subsistemului de uz general D.7.2 Progrese în testare.

Organizația de testare a trebuit să creeze teste de integrare a versiunilor și teste de conformitate (unele teste NT, FT și OCT). Testarea integrării versiunilor a fost mai puțin eficientă în identificarea problemelor decât era de așteptat. Testele ITV trebuiau să conţină Set complet proceduri de testare a integrării - de la capabilități de bază la condiții la limită speciale. O mare parte din această muncă, în special firele de bază, s-au suprapus cu munca de integrare pentru demonstrație. În consecință, testele ITV au dublat adesea pregătirea pentru demonstrații, ceea ce a fost mai puțin rentabil decât dacă activitățile de pregătire pentru demonstrații ar fi fost combinate cu și responsabilitatea pentru ITV.

atribuite organizației care efectuează testarea. Tabelul D.6 prezintă rezultatele etapei 2 ITV, care reflectă starea integrată a produsului. Cu toate acestea, s-a depus mai mult efort pentru planificarea, pregătirea și execuția ITV decât a fost necesar. Combinarea pregătirii pentru demonstrații cu activitățile ITV ar permite mai puțin personal să facă o treabă mai bună. O astfel de abordare ar permite creșterea gradului de integrare (fiind parte integrantă lucrări de pregătire pentru demonstrații) înainte de retestare și efectuați mai eficient backtesting după retestare pentru a vă asigura că toate problemele anterioare au fost rezolvate.

<.>

Tabelul D.6.

Caracteristicile SCO pentru testarea ITV versiunea 2

Tabelul D.7 și Fig. D.11 vă permite să vă uitați la valorile de progres din diverse puncte perspective care au fost folosite pentru planificarea și monitorizarea programului de testare în proiectul CCPDS-R. Figura prezintă un grafic al progresului în raport cu ceea ce este planificat pentru testarea conformității. Testele NT, FT și OCT au fost sursele opțiunilor de testare utilizate de organizația de dezvoltare de software. NT era responsabilitatea echipelor de dezvoltare, dar trebuia desfășurat într-un mediu formal de management al configurației și sub supravegherea (supravegherea vizuală) a personalului de testare. FT a constat din grupuri de scenarii interconectate funcțional care au demonstrat conformitatea cu cerințele care acoperă mai multe componente simultan. Testele OCT ne-au permis să determinăm aspecte de conformitate care nu au putut fi demonstrate înainte creație completă sisteme. Cerințele Cantitative de Performanță (QPR) au acoperit toate CSCI-urile.

Testarea formală NT (testarea conformității cu cerințele, efectuată în formularul testare independentă) s-a dovedit a fi mai dificil decât era planificat. Acest lucru s-a datorat în primul rând ca specificațiile cerințelor și revizuirile de proiectare au devenit supraîncărcate cu detalii de dezvoltare și proceduri de aprobare.

Implementarea testării formale NT a fost controlată cu atenție de guvern și a durat foarte mult timp pentru a se pregăti pentru revizuire. Guvernul a cerut proceduri extinse de testare pentru multe detalii individuale de proiectare care nu ar fi trebuit de fapt să fie considerate cerințe. În plină dezvoltare, procedurile HT erau rareori disponibile cu 30 până la 60 de zile înainte de re-testare, deoarece contractul era necesar pentru orice tip de testare de conformitate. Procesul formal de testare NT a fost unul dintre motivele principale pentru care reevaluările au fost finalizate în mod constant mai târziu decât era planificat.

Tabelul D.7.

Testarea de conformitate funcționează folosind diferite tipuri de teste pentru diferite CSCI

Orez. D.11. Progresul testării subsistemului de uz general

D.7.3 Stabilitate.

În fig. D.12 oferă nivelul general de modificare a configurației de bază. Afișează numărul total de SLOC considerate inutilizabile (eliminate din versiunea de bază pentru îmbunătățire din cauza unui defect descoperit, pentru extindere sau pentru efectuarea altor tipuri de modificări) și numărul de SLOC-uri restaurate (cele care au fost reîncorporate în versiunea de bază cu corecții, extensii sau alte modificări). Viteza cu care au fost descoperite defectele, care a diferit de viteza cu care au fost corectate, a avut ca rezultat o atenție intensă a managementului, modificări ale priorităților de alocare a resurselor și acțiuni corective întreprinse pentru a se asigura că organizația de testare (identificarea defectelor) și organizația de dezvoltare (efectuarea restaurării) sunt în echilibru relativ. În general, situația prezentată în figură se referă la un proiect extrem de reușit.

D.7.4 Rata defectelor.

În fig. D.13 Numărul total de defecte este determinat în raport cu subsistemul software în ansamblu. Această măsurătoare estimează defectele totale identificate în timpul dezvoltării Subsistemului de uz general ca aproximativ 25% din volumul întregului produs. Rata medie de defecte în industria software variază de la 40% la 60%. Iniţială configurație de bază a fost creat la momentul POP, la 14 luni. După aceea, i s-au adăugat 1600 modificări individuale.

Luna de executare a contractului Fig. D.13. Rata defectelor în subsistemul de uz general.

D.7.5 Adaptabilitate

Pentru subsistemul cu scop general în ansamblu, aproximativ 5% din volumul total de muncă a fost cheltuit pentru finalizarea versiunii de bază a software-ului. Costul mediu pe modificare a fost de aproximativ 24 de ore pe SCO. Aceste valori vă permit să evaluați ușurința cu care s-ar putea face modificări versiunii de bază a software-ului. Nivelul de adaptabilitate atins de proiectul CCPDS-R a fost de aproximativ patru ori mai mare decât pentru proiectele convenționale, în care costurile de reluare a ciclului de viață depășesc de obicei 20% din nivelul costului total.

În fig. D.14 arătat cost mediu o schimbare în procesul de creare a unui subsistem cu scop general. Până la OCT, 1600 de SCO au fost procesate cu privire la modificările bazei de configurare, rezultând un cost pe modificare stabil. Proiectul CCPDS-R a fost unul dintre puținele contraexemple la afirmația: „cu cât treceți mai târziu în ciclul de viață, cu atât găsiți probleme mai costisitoare”.

Cele mai multe dintre primele SCO (prezentate în caseta etichetată „Modificări de proiect” în Figura D.14) au fost modificări care au implicat un număr mare de oameni și un număr mare de componente (modificări ale interfețelor și arhitecturii). SCO-urile ulterioare (etichetate „Modificări în implementare”) s-au concentrat de obicei pe o singură persoană și o componentă. Ultima parte a curbei reflectă o creștere atipică a defectelor, care a fost rezultatul unei mari propuneri tehnice de a schimba complet setul de mesaje primite pentru Subsistemul de uz general. Această zonă a fost una dintre acele zone în care a face schimbări nu a fost atât de ușoară pe cât ne-am fi dorit. Deși proiectul a fost sustenabil și adaptat la un numar mare scenarii pentru efectuarea de modificări furnizate în prealabil, revizuirea întregului set de mesaje de intrare nu a fost niciodată intenționată, iar proiectul nu a fost conceput pentru aceasta.

Orez. D.14. Adaptabilitate Subsisteme de uz general.

D.7.6 Completitudine.

Proiectul CCPDS-R avea cerințe speciale de fiabilitate și, prin urmare, software-ul a fost distribuit într-un mod special. O echipă de testare independentă a creat o suită de testare automată. S-a desfășurat la ore ciudate și a testat versiunea de bază a software-ului folosind scenarii de mesaje aleatorii. Această strategie a condus la testare extinsă în condiții realiste pe o perioadă lungă de timp. Pe baza rezultatelor, a fost posibilă determinarea valorii MTBF pentru software. Componentele critice pentru fiabilitate, forțate să treacă la primele etape ale planului de iterație, au fost supuse celor mai stricte teste de fiabilitate. Rezultatele sunt prezentate în Fig. D.15.

Pentru arhitecturile moderne distribuite, această metodă de testare statistică, pe de o parte, este necesară pentru a asigura o acoperire maximă a testelor și, pe de altă parte, este utilă pentru detectarea problemelor asociate cu conflictul de resurse, blocajele, supraîncărcarea resurselor, scurgerile de memorie și altele. erori Heisenberg. Rularea scenariilor aleatorii și accelerate pe perioade lungi de timp (peste noapte sau weekend) oferă o perspectivă timpurie asupra integrității generale a resurselor sistemului.

Orez. D.15. Completitudinea subsistemului de uz general.

D.7.7 Costuri financiare/de lucru pt specii individuale Activități.

Tabelul D.8 discută structura generală detaliată a costurilor a subsistemului cu destinație generală din proiectul CCPDS-R. Aceste date au fost derivate din costul final WBS și structurate în conformitate cu liniile directoare date în Secțiunea 10.1. Elementele de nivel inferior sunt descrise în Tabelul D.9.

■ Procentele prezentate în Tabelul D.8 corespund aproximativ cu procentele prezentate în Capitolul 10. Cu toate acestea, unele dintre elementele de management din Tabelul D.9 au fost împărțite în mai multe elemente din Tabelul D.8 pentru a evidenția activitățile la managementul proiectului nivel .

■ Sa constatat că efortul general al echipei de testare este relativ scăzut în comparație cu proiectele care utilizează un proces tradițional. Motivul principal al acestei stări de lucruri este că echipa de arhitectură preda un integrat software echipa care a efectuat testarea și evaluarea și a fost responsabilă în primul rând de testarea produsului integrat.

Tabelul D.8.

Costuri financiare pentru Subsistemul de uz general pentru elementele WBS de cel mai înalt nivel

Pe lângă SLOC să caracteristici cantitative include, de asemenea:

• numărul de linii goale,
• numărul de comentarii,
• procentul de comentarii (raportul dintre numărul de rânduri care conțin comentarii și numărul total de rânduri, exprimat ca procent);
• numărul mediu de linii pentru funcții (clase, fișiere),
• numărul mediu de linii care conțin codul sursă pentru funcții (clase, fișiere),
• numărul mediu de rânduri pentru module.

De asemenea, sunt incluse în grupul de metrici bazate pe numărarea anumitor unități din codul programului și metricile Halstead. Aceste valori se bazează pe următorii indicatori:

N1 - numărul de instrucțiuni unice de program, inclusiv simboluri

Separatoare, nume de proceduri și semne de operație (dicționar operator),

N2 - numărul de operanzi unici de program (dicționar de operanzi),

N1 - numărul total de declarații din program,

N2 - numărul total de operanzi din program,

N1" - numărul teoretic de operatori unici,

N2" este numărul teoretic de operanzi unici.

Ținând cont de notațiile introduse, putem determina:

N=n1+n2 - dicționar de programe,

N=N1+N2 - lungimea programului,

N"=n1"+n2" - dicționar teoretic al programului,

N"= n1*log 2 (n1) + n2*log 2 (n2) - lungimea programului teoretic (pentru programele corecte din punct de vedere stilistic, abaterea lui N de la N" nu depășește 10%)

V=N*log 2 n - volumul programului,

V"=N"*log 2 n" este volumul teoretic al programului, unde n* este dicționarul teoretic al programului.

L=V"/V - nivel de calitate programare, pt program ideal L=1

L"= (2 n2)/ (n1*N2) - nivelul de calitate al programării bazat numai pe parametri program real fără a lua în considerare parametrii teoretici,

E C =V/(L")2 - dificultatea de a înțelege programul,

D=1/L" - complexitatea codificării programului,

Y" = V/ D2 - nivelul limbajului de expresie

I=V/D - conținutul informativ al programului, această caracteristică vă permite să determinați costurile mentale ale creării unui program

E=N" * log 2 (n/L) - evaluarea efortului intelectual necesar la elaborarea unui program, caracterizarea numărului de soluții elementare necesare la scrierea unui program

Când se utilizează metrica Halstead, dezavantajele asociate cu capacitatea de a înregistra aceeași funcționalitate cu un număr diferit de linii și operatori sunt parțial compensate.

Un alt tip de metrici software care sunt cantitative sunt metricile Gilb. Ele arată complexitatea software-ului pe baza densității programului de instrucțiuni condiționate sau de instrucțiuni în buclă. Această măsurătoare, în ciuda simplității sale, reflectă destul de bine complexitatea scrierii și înțelegerii unui program, iar atunci când se adaugă un astfel de indicator ca nivelul maxim de imbricare a declarațiilor condiționate și ciclice, eficacitatea acestei metrici crește semnificativ.

2. Măsuri ale complexității fluxului de control al programului

Înainte de a descrie direct valorile în sine, pentru intelegere mai buna Se va descrie graficul de control al programului și metoda de construire a acestuia.

Să fie prezentat un program. Pentru acest program, se construiește un grafic direcționat care conține doar o intrare și o ieșire, în timp ce vârfurile graficului sunt corelate cu acele secțiuni ale codului programului în care există doar calcule secvențiale și nu există operatori de ramificație și buclă, iar arcurile sunt corelate cu tranzițiile de la bloc la bloc și ramuri ale execuției programului. Condiție pentru construirea acestui grafic: fiecare vârf este accesibil de la vârful inițial, iar vârful final este accesibil de la orice alt vârf.

Cea mai comună estimare bazată pe analiza graficului rezultat este complexitatea ciclomatică a programului (numărul ciclomatic McCabe). Este definit ca V(G)=e - n + 2p, unde e este numărul de arce, n este numărul de vârfuri, p este numărul de componente conectate. Numărul de componente conectate ale unui grafic poate fi considerat ca fiind numărul de arce care trebuie adăugate pentru a transforma graficul într-unul puternic conectat. Un grafic se numește puternic conectat dacă oricare două vârfuri sunt reciproc accesibile. Pentru graficele programelor corecte, adică graficele care nu au secțiuni inaccesibile din punctul de intrare și nu au puncte de intrare și ieșire „atârnătoare”, un grafic puternic conectat se obține de obicei prin închiderea unui arc de la un vârf care denotă sfârșitul programul la un vârf care indică punctul de intrare în acest program. În esență, V(G) determină numărul de circuite liniar independente dintr-un grafic puternic conectat. Deci, în programele scrise corect p=1 și, prin urmare, formula pentru calcularea complexității ciclomatice ia forma:

V(G)=e - n + 2.

Din pacate, această evaluare incapabil să facă distincția între structurile ciclice și cele condiționale. Un alt dezavantaj semnificativ al acestei abordări este că programele reprezentate de aceleași grafice pot avea predicate de complexitate complet diferită (un predicat este o expresie logică care conține cel puțin o variabilă).

Pentru a corecta acest neajuns, G. Myers a dezvoltat o nouă tehnică. Ca o estimare, el a sugerat să se ia un interval (această estimare se mai numește și interval), unde h pentru predicate simple este egal cu zero, iar pentru predicate n-are h = n-1. Această metodă face posibilă distingerea predicatelor de complexitate diferită, dar în practică nu este folosită aproape niciodată.

O altă modificare a metodei McCabe este metoda Hansen. O măsură a complexității unui program în în acest caz, reprezentat ca o pereche (complexitate ciclomatică, număr de operatori). Avantajul acestei măsuri este sensibilitatea la structura software-ului.

Măsura topologică a lui Chen exprimă complexitatea unui program în termeni de număr de treceri ale granițelor dintre regiunile formate de graficul programului. Această abordare este aplicabilă numai programelor structurate care permit numai conectarea secvențială a structurilor de control. Pentru programele nestructurate, măsura Chen depinde în mod semnificativ de ramuri condiționate și necondiționate. În acest caz, puteți specifica limitele superioare și inferioare ale măsurii. Cel de sus este m+1, unde m este numărul de operatori logici cu imbricarea lor reciprocă. Cel mai mic este egal cu 2. Când graficul de control al unui program are o singură componentă conectată, măsura Chen coincide cu măsura ciclomatică McCabe.

Continuând subiectul analizei graficului de control al unui program, putem distinge un alt subgrup de metrici - metrici Harrison și Majel.

Aceste măsuri iau în considerare nivelul investiției și durata programului.

Fiecărui vârf i se atribuie propria complexitate în funcție de operatorul pe care îl reprezintă. Acest dificultate inițială vârfurile pot fi calculate în orice mod, inclusiv folosind măsuri Halstead. Pentru fiecare vârf de predicat, selectăm un subgraf generat de vârfuri care sunt capetele arcelor care emană din acesta, precum și vârfuri accesibile de la fiecare astfel de vârf (limita inferioară a subgrafului) și vârfuri situate pe căile de la vârful predicatului. la o anumită limită inferioară. Acest subgraf se numește sfera de influență a vârfului predicatului.

Complexitatea redusă a unui vârf de predicat este suma complexităților inițiale sau reduse ale vârfurilor incluse în sfera sa de influență, plus complexitatea primară a vârfului predicat în sine.

Măsura funcțională (SCOPE) a unui program este suma complexităților reduse ale tuturor vârfurilor graficului de control.

Relația funcțională (SCORT) este raportul dintre numărul de vârfuri dintr-un grafic de control și complexitatea funcțională a acestuia, iar vârfurile terminale sunt excluse din numărul de vârfuri.

SCORT poate accepta sensuri diferite pentru grafice cu același număr ciclomatic.

Metrica Pivovarsky este o altă modificare a măsurării complexității ciclomatice. Vă permite să urmăriți diferențele nu numai între structurile de control secvențiale și imbricate, ci și între programele structurate și nestructurate. Se exprimă prin relația N(G) = v *(G) + SUMMAPi, unde v *(G) este complexitatea ciclomatică modificată, calculată în același mod ca V(G), dar cu o singură diferență: o instrucțiune CASE cu n ieșiri este considerat ca un operator logic, mai degrabă decât ca n - 1 operatori.

Pi este adâncimea de imbricare a vârfului i-lea al predicatului. Pentru a calcula adâncimea de imbricare a vârfurilor predicatelor, se utilizează numărul de „sfere de influență”. Adâncimea de cuibărire este înțeleasă ca numărul tuturor „sferelor de influență” ale predicatelor care fie sunt complet conținute în sfera vârfului în cauză, fie se intersectează cu acesta. Adâncimea cuibării crește datorită cuibării nu a predicatelor în sine, ci a „sferelor de influență”. Măsura Pivovarsky crește atunci când se trece de la programele secvențiale la cele imbricate și apoi la cele nestructurate, ceea ce reprezintă avantajul său imens față de multe alte măsuri din acest grup.

Măsura Woodward - numărul de intersecții de arce ale graficului de control. Deoarece astfel de situații nu ar trebui să apară într-un program bine structurat, această metrică este utilizată în principal în situații slabe. limbaje structurate(Asamblator, Fortran). Un punct de intersecție apare atunci când controlul depășește două vârfuri care sunt operatori secvențiali.

Metoda valorii la limită se bazează și pe analiza graficului de control al programului. Pentru a defini această metodă, este necesar să se introducă mai multe concepte suplimentare.

Fie G graficul de control al unui program cu o singură inițială și un singur vârf final.

În acest grafic, numărul de vârfuri de arc de intrare se numește gradul negativ al vârfului, iar numărul de arce care emană de la vârf se numește gradul pozitiv al vârfului. Apoi, mulțimea vârfurilor graficului poate fi împărțită în două grupe: vârfuri cu grad pozitiv<=1; вершины, у которых положительная степень >=2.

Vom numi vârfurile primului grup primitor, iar vârfurile celui de-al doilea grup - vârfuri de selecție.

Fiecare vârf receptor are o complexitate redusă de 1, cu excepția vârfului final, care are o complexitate redusă de 0. Complexitățile reduse ale tuturor vârfurilor din G sunt însumate pentru a forma complexitatea limită absolută a programului. După aceasta, se determină complexitatea marginală relativă a programului:

Unde S0 este complexitatea marginală relativă a programului, Sa este complexitatea marginală absolută a programului, v este numărul total de vârfuri ale graficului programului.

Există o metrică Schneidewind, exprimată în termeni de număr moduri posibileîn graficul de control.

3. Măsuri de complexitate a fluxului de date

Metrica Chapin: esența metodei este de a evalua puterea informațiilor unui individ modul software prin analiza naturii utilizării variabilelor din lista I/O.

Întregul set de variabile care alcătuiesc lista I/O este împărțit în 4 grupuri funcționale:

1. P - variabile de intrare pentru calcule și pentru furnizarea de ieșire,

2. M - variabile modificate sau create în cadrul programului,

3. C - variabile implicate în controlul funcționării modulului software (variabile de control),

Deoarece fiecare variabilă poate îndeplini mai multe funcții simultan, ea trebuie luată în considerare în fiecare grup funcțional corespunzător.

Valoare Chapin:

Q = a1*P + a2*M + a3*C + a4*T,

Unde a1, a2, a3, a4 sunt coeficienți de ponderare.

Q = P + 2M + 3C + 0,5T

Valoarea ponderii se bazează pe localizarea acceselor la date în cadrul fiecărei secțiuni de program. Spen este numărul de instrucțiuni care conțin un anumit identificator între prima și ultima apariție în textul programului. Prin urmare, un identificator care apare de n ori are un interval de n-1. Cu un interval mare, testarea și depanarea devin mai complicate.

O altă metrică care ia în considerare complexitatea unui flux de date este o metrică care leagă complexitatea programelor de accesele la variabile globale.

O pereche modul-variabilă globală este notată cu (p,r), unde p este modulul care are acces la variabila globală r. În funcție de faptul dacă programul accesează efectiv variabila r, se formează două tipuri de perechi „modul - variabilă globală”: actuală și posibilă. Posibila referire la r prin p arată că domeniul de existență al lui r include p.

Această caracteristică este notată cu Aup și indică de câte ori modulele Up au accesat efectiv variabile globale, iar numărul Pup indică de câte ori le-ar fi putut accesa.

Se determină raportul dintre numărul de apeluri reale și cele posibile

Această formulă arată probabilitatea aproximativă ca un modul arbitrar să facă referire la o variabilă globală arbitrară. Evident, cu cât această probabilitate este mai mare, cu atât este mai mare probabilitatea modificării „neautorizate” a oricărei variabile, ceea ce poate complica semnificativ munca asociată cu modificarea programului.

Măsura Kafur a fost creată pe baza conceptului de fluxuri de informații. Pentru a utiliza această măsură, sunt introduse conceptele de flux local și global: un flux local de informații de la A la B există dacă:

1. Modulul A apelează modulul B (fir local direct)

2. Modulul B apelează modulul A și A returnează lui B o valoare care este utilizată în B (flux local indirect)

3. Modulul C apelează modulele A, B și transferă rezultatul modulului A la B.

În continuare, ar trebui să dăm conceptul de flux global de informații: un flux global de informații de la A la B printr-o structură globală de date D există dacă modulul A pune informații în D și modulul B utilizează informații din D.

Pe baza acestor concepte, se introduce valoarea I - complexitatea informațională a procedurii:
I = lungime * (fan_in * fan_out)2
Aici:

Lungime - complexitatea textului procedurii (măsurată prin intermediul uneia dintre valorile de volum, cum ar fi valorile Halstead, McCabe, LOC etc.)

Fan_in - numărul de fire locale care intră în procedură plus numărul de structuri de date din care procedura preia informații

Fan_out - numărul de fire locale care provin din procedură plus numărul de structuri de date care sunt actualizate de procedură

Complexitatea informațională a unui modul poate fi definită ca suma complexităților informaționale ale procedurilor incluse în acesta.

Următorul pas este să luăm în considerare complexitatea informațională a unui modul în raport cu o anumită structură de date. Măsura informațională complexitatea modulului în ceea ce privește structura datelor:

J = W * R + W * RW + RW *R + RW * (RW - 1)

W este numărul de proceduri care actualizează doar structura datelor;

R - citeste doar informatii din structura de date;

RW - atât citiți, cât și actualizați informațiile din structura de date.

O altă măsură din această grupă este măsura Oviedo. Esența sa este că programul este împărțit în secțiuni liniare care nu se intersectează - raze de operatori care formează graficul de control al programului.

Autorul metricii face următoarele presupuneri: programatorul poate găsi relația dintre definirea și utilizarea aparițiilor unei variabile într-o rază mai ușor decât între raze; Numărul de apariții distincte definitorii din fiecare rază este mai important decât numărul total de apariții variabile de utilizare în fiecare rază.

Să notăm cu R(i) mulțimea de apariții definitorii ale variabilelor care sunt situate în raza de acțiune a razei i (o apariție definitorie a unei variabile se află în raza de acțiune a unei raze dacă variabila este fie locală în ea și are o apariție definitorie, sau pentru aceasta există o apariție definitorie într-o rază anterioară și nu există o definiție locală de-a lungul căii). Să notăm cu V(i) mulțimea de variabile ale căror apariții sunt deja în raza i. Apoi măsura complexității razei i este dată astfel:

DF(i)=SUM(DEF(v j)), j=i...||V(i)||

Unde DEF(v j) este numărul de apariții definitorii ale variabilei v j din mulțimea R(i) și ||V(i)|| - puterea multimii V(i).

4. Măsuri ale fluxului de control și complexitatea datelor programului

Prima dintre aceste metrici este testarea M-Measure. O măsură de testare M este o măsură a complexității care îndeplinește următoarele condiții:

Măsura crește odată cu adâncimea cuibării și ține cont de durata programului. Strâns legată de măsura de testare este o măsură bazată pe înglobări regulate. Ideea acestei măsuri a complexității programului este de a număra numărul total de caractere (operanzi, operatori, paranteze) într-o expresie regulată cu numărul minim necesar de paranteze care descriu graficul de control al programului. Toate măsurile din acest grup sunt sensibile la imbricarea structurilor de control și la durata programului. Cu toate acestea, nivelul de complexitate computațională crește.

De asemenea, o măsură a calității software-ului este coerența modulelor programului. Dacă modulele sunt strâns cuplate, atunci programul devine greu de modificat și greu de înțeles. Această măsură nu este exprimată numeric. Tipuri de conectivitate module:

Conectivitate de date - dacă modulele interacționează prin transferul de parametri și fiecare parametru este un obiect informațional elementar. Acesta este cel mai preferat tip de conexiune (cuplaj).

Conexiune prin structura de date - dacă un modul trimite altuia un compozit obiect informativ(structură) pentru schimbul de date.

Cuplare de control - dacă cineva trimite altuia un obiect de informare - un steag conceput pentru a controla logica sa internă.

Modulele sunt legate printr-o zonă comună dacă se referă la aceeași zonă globală de date. Cuplarea peste un domeniu global este nedorită deoarece, în primul rând, o eroare într-un modul care utilizează domeniul global poate apărea în mod neașteptat în orice alt modul; în al doilea rând, astfel de programe sunt greu de înțeles, deoarece este dificil pentru programator să determine ce date sunt folosite de un anumit modul.

Coeziune prin conținut - dacă unul dintre module se leagă în interiorul altuia. Acesta este un tip inacceptabil de cuplare, deoarece contrazice complet principiul modularității, adică. reprezentarea modulului ca o cutie neagră.

Cuplare externă - două module partajează date externe, cum ar fi un protocol de comunicație.

Conectivitatea folosind mesaje este cel mai liber tip de conectivitate; modulele nu sunt conectate direct între ele; ele comunică prin mesaje care nu au parametri.

Lipsa de cuplare - modulele nu interacționează între ele.

Cuplarea subclaselor este o relație între o clasă părinte și o clasă copil, în care copilul este înrudit cu părintele, dar părintele nu este înrudit cu copilul.

Relația de timp - două acțiuni sunt grupate într-un singur modul doar pentru că, din cauza circumstanțelor, ele apar în același timp.

O altă măsură legată de stabilitatea unui modul este măsura Colofello, ea poate fi definită ca numărul de modificări care trebuie făcute în alte module decât modulul a cărui stabilitate este verificată, iar aceste modificări trebuie să privească modulul testat. .

Următoarea valoare de la din această clasă- metrica McClure. Există trei etape în calcularea acestei valori:

1. Pentru fiecare variabilă de control i, valoarea funcției sale de complexitate C(i) se calculează folosind formula: C(i) = (D(i) * J(i))/n.

Unde D(i) este o valoare care măsoară domeniul de aplicare al variabilei i. J(i) este o măsură a complexității interacțiunii modulelor prin variabila i, n este numărul de module individuale din schema de partiționare.

2. Pentru toate modulele incluse în sfera de partiționare, valoarea funcțiilor lor de complexitate M(P) este determinată de formula M(P) = fp * X(P) + gp * Y(P)
unde fp și gp sunt, respectiv, numărul de module care preced imediat și imediat după modulul P, X(P) este complexitatea accesării modulului P,

Y(P) - complexitatea apelării controlului din modulul P al altor module.

3. Complexitatea generală a schemei ierarhice MP pentru împărțirea unui program în module este dată de formula:

MP = SUM(M(P)) peste toate valorile posibile ale modulelor P - program.

Această metrică se concentrează pe programe care sunt bine structurate, compuse din module ierarhice care definesc specificația funcțională și structura de control. De asemenea, se presupune că fiecare modul are un punct de intrare și un punct de ieșire, modulul îndeplinește exact o funcție, iar modulele sunt apelate în conformitate cu un sistem de control ierarhic care specifică relația de apel pe mai multe module de program.

Există, de asemenea, o metrică bazată pe conceptul de informare- Măsura Berlinger. Măsura complexității este calculată ca M=SUMf i *log 2 p i , unde f i este frecvența de apariție a simbolului i, p i este probabilitatea apariției acestuia.

Dezavantajul acestei metrici este că un program care conține multe caractere unice, dar în cantități mici, va avea aceeași complexitate ca un program care conține un număr mic de caractere unice, dar în cantități mari.

5. Metrici orientate pe obiecte

Înainte de a începe să luăm în considerare metricile Martin, este necesar să introducem conceptul de categorii de clasă. În realitate, o clasă poate fi rar reutilizată izolat de alte clase. Aproape fiecare clasă are un grup de clase cu care lucrează în cooperare și de care nu poate fi separată ușor. Pentru a reutiliza astfel de clase, trebuie să reutilizați întregul grup de clase. Un astfel de grup de clase este strâns legat și se numește categorie de clase. Pentru existența unei categorii de clasă există următoarele condiții:

Clasele dintr-o categorie de clasă sunt sigilate de orice încercare de a le schimba pe toate împreună. Aceasta înseamnă că, dacă o clasă s-ar schimba, toate clasele din acea categorie ar putea să se schimbe. Dacă vreuna dintre clase este deschisă la un fel de schimbare, toate sunt deschise la acest tip de schimbare.

Clasele dintr-o categorie sunt reutilizate numai împreună. Sunt atât de interdependenți și nu pot fi separați unul de celălalt. Astfel, dacă se încearcă reutilizarea unei clase dintr-o categorie, toate celelalte clase trebuie reutilizate împreună cu aceasta.

Responsabilitatea, independența și stabilitatea unei categorii pot fi măsurate prin numărarea dependențelor care interacționează cu acea categorie. Pot fi definite trei metrici:

1. Ca: Coeziunea centripetă. Numărul de clase din afara acestei categorii care depind de clasele din cadrul acestei categorii.

2. Ce: Ambreiaj centrifugal. Numărul de clase din această categorie care depind de clasele din afara acestei categorii.

3. I: Instabilitate: I = Ce / (Ca+Ce). Această valoare are o gamă de valori.

I = 0 indică categoria cea mai stabilă.

I = 1 indică categoria cea mai instabilă.

Puteți defini o metrică care măsoară abstractitatea (dacă o categorie este abstractă, atunci este suficient de flexibilă și poate fi extinsă cu ușurință) unei categorii, după cum urmează:

A: Abstracție: A = nA / nAll.

NA - numărul_de_clase_abstracte_în_categorie.

NAll - total_number_of_classes_in_category.

Valorile acestei valori variază în interval.

Acum, pe baza valorilor Martin de mai sus, puteți construi un grafic care arată relația dintre abstractizare și instabilitate. Dacă construim pe ea o dreaptă, dată de formula I+A=1, atunci această linie dreaptă va conține categorii care au cel mai bun echilibru între abstractizare și instabilitate. Această linie se numește secvența principală.

Distanța față de secvența principală: D=|(A+I-1)/sqrt(2)|

Distanța normalizată până la secvența principală: Dn=|A+I-2|

Este adevărat pentru aproape orice categorie că, cu cât este mai aproape de secvența principală, cu atât mai bine.

Următorul subgrup de metrici este metricile Chidamber și Kemerer. Aceste metrici se bazează pe analiza metodelor de clasă, arborele de moștenire etc.

WMC (Metode ponderate pe clasă), complexitatea totală a tuturor metodelor clasei: WMC=SUMAc i , i=1...n, unde c i este complexitatea metodei i-a, calculată folosind oricare dintre metricile ( Halstead etc. în funcție de criteriul de interes), dacă toate metodele au aceeași complexitate, atunci WMC=n.

DIT (Depth of Inheritance tree) - adâncimea arborelui de moștenire (cea mai lungă cale de-a lungul ierarhiei clasei către o anumită clasă din clasa strămoșilor), cu atât mai mare, cu atât mai bine, deoarece cu o adâncime mai mare, abstractizarea datelor crește, saturația de clasa cu metode scade, dar cu un suficient de mare Cu profunzime, complexitatea înțelegerii și scrierii unui program crește foarte mult.

NOC (Număr de copii) - numărul de descendenți (imediat), cu atât mai mult, cu atât este mai mare abstracția datelor.

CBO (Coupling between object classes) - cuplare între clase, arată numărul de clase cu care este asociată clasa originală. Pentru aceasta metrica sunt valabile toate afirmatiile introduse mai devreme pentru conectivitatea modulelor, adica cu un CBO mare, abstractizarea datelor scade si devine mai dificila. reutilizare clasă.

RFC (Răspuns pentru o clasă) - RFC=|RS|, unde RS este setul de răspuns al unei clase, adică setul de metode care pot fi apelate de o metodă de clasă ca răspuns la datele primite de un obiect al clasei. clasă. Adică RS=(((M)((R i )), i=1...n, unde M sunt toate metode posibile class, R i - toate metodele posibile care pot fi apelate de clasa i-a. Atunci RFC va fi puterea set dat. Cu cât sunt mai multe RFC-uri, cu atât este mai dificil de testat și de depanat.

LCOM (Lack of cohesion in Methods) - lipsa de coeziune a metodelor. Pentru a determina acest parametru, luăm în considerare clasa C cu n metode M1, M2,... ,Mn, apoi (I1),(I2),...,(In) sunt seturi de variabile utilizate în aceste metode. Acum definim P - un set de perechi de metode care nu au variabile comune; Q este un set de perechi de metode care au variabile comune. Apoi LCOM=|P|-|Q|. Lipsa de coeziune poate fi un semnal că clasa poate fi împărțită în mai multe clase sau subclase, deci este mai bine să creșteți coeziunea pentru a crește încapsularea datelor și a reduce complexitatea claselor și metodelor.

6. Indicatori de fiabilitate

7. Metrici hibride

H_M = (M + R1 * M(M1) +... + Rn * M(Mn)/(1 + R1 +... + Rn)

Unde M este metrica de bază, Mi sunt alte măsuri interesante, Ri sunt coeficienți selectați corect, M(Mi) sunt funcții.

Funcțiile M(Mi) și coeficienții Ri se calculează folosind analiza regresiei sau analiza sarcinilor pentru un anumit program.

Valoarea Zolnovsky, Simmons, Thayer este, de asemenea, o sumă ponderată a diferiților indicatori. Există două opțiuni pentru această valoare:

(structură, interacțiune, volum, date) SUM(a, b, c, d).

(complexitatea interfeței, complexitatea de calcul, complexitatea I/O, lizibilitatea) SUM(x, y, z, p).

Metricile utilizate în fiecare opțiune sunt selectate în funcție de sarcina specifică, coeficienții - în funcție de valoarea metricii pentru luarea unei decizii în acest caz.

Concluzie

Colecții proaspete de materiale pentru descărcare! Am colectat pachete de materiale pe subiecte actuale, inclusiv prezentări ale experților, webinarii, articole, exemple de implementare etc.
Pentru a descărca materiale, faceți clic pe butonul corespunzător:

Cel mai cunoscut și utilizat standard pentru organizarea proceselor de control al calității este seria de standarde ISO 9000. Pentru procesul de dezvoltare software se folosește standardul ISO 9001, care include proiectarea prin producție. Trebuie remarcat faptul că acest standard este dificil de utilizat direct în managementul calității dezvoltării software, deoarece este axat inițial pe dezvoltarea de produse industriale. În special pentru a sprijini procesele de dezvoltare a sistemelor software de către organizația ISO, a fost elaborat ghidul ISO 9000-3, care formulează cerințele modelului de calitate ISO 9001 pentru organizarea procesului de dezvoltare software.

Astfel, cerințele ghidului ISO 9000-3 pot fi folosite pentru a evalua calitatea procesului de dezvoltare în propria organizație sau în organizația contractanților. În prezent, versiunea 2000 a standardului este pusă în uz peste tot, în care controlul proceselor este în prim-plan, însă în această versiune a standardului nu există nicio specificitate legată de dezvoltarea software.

Un dezavantaj al standardului ISO 9000 este dificultatea de a măsura nivelul de calitate al unui proces de dezvoltare software conform modelului de calitate propus.

Printre dezvoltatorii de software, în special din străinătate (în primul rând în SUA), se bucură de un rating ridicat model alternativ calitate: SMM - SEI. Acest model de calitate a fost dezvoltat la Institutul de Inginerie Software sub sponsorizarea Departamentului de Apărare al SUA. Inițial, acest model de calitate a fost folosit de organizații guvernamentale, în special militare, atunci când plasau comenzi pentru dezvoltarea de software. Standardul este acum utilizat pe scară largă pentru a analiza și certifica procesele de dezvoltare software ale firmelor care produc software complex în domenii critice de aplicație. Avantajele importante ale modelului CMM sunt imbricarea ierarhică a modelelor de calitate, care vă permite să măsurați și să comparați nivelurile de calitate a procesului în diferite organizații și să asigurați îmbunătățirea eficientă a calității procesului.

De asemenea, ISO a dezvoltat acum un model de calitate pentru a măsura și îmbunătăți calitatea.

Într-o anumită privință, modelele de calitate CMM și ISO sunt interschimbabile, însă, în esență, nu se contrazic, deoarece se bazează pe aceeași paradigmă de calitate - TQM - Total Quality Management.

Este important de reținut că pur și simplu având un proces de dezvoltare software care să satisfacă nivel inalt calitate, nu garantează lansarea produsului Calitate superioară. A avea un proces de calitate înseamnă că calitatea produsului rezultat se va îmbunătăți constant din nou și din nou. Prin urmare, la luarea deciziilor, este necesar să se țină cont de timpul în care se instalează și funcționează un proces de nivelul de calitate cerut într-o anumită zonă tehnologică. Cu toate acestea, lipsa de informații despre calitatea procesului înseamnă că calitatea produsului în curs de dezvoltare este imprevizibilă.

Calitatea produsului software

Calitate componente software

Dezvoltarea sistemelor software mari moderne se bazează acum din ce în ce mai mult pe dezvoltarea componentelor (Component Base System - CBS). Tehnologia de construcție CBS poate reduce semnificativ costurile și timpul de dezvoltare. În același timp, crește riscul asociat cu utilizarea componentelor software dezvoltate de diferiți producători în sistem.

Cel mai mod eficient Soluția la această problemă este utilizarea unor metrici pentru a gestiona calitatea și riscurile la construirea CBS, pentru a măsura diverși factori care afectează calitatea finală a produsului și pentru a elimina sursele de risc. În acest caz, valorile calității ar trebui utilizate pentru a sprijini luarea deciziilor la diferite etape ale ciclului de viață al dezvoltării cu privire la fezabilitatea economică a utilizării componentelor.

Codurile sursă ale componentelor, de regulă, sunt inaccesibile pentru proiectanții de sistem; în plus, oferă o interfață structurată complexă. Consecința acestui lucru este că există o diferență semnificativă între valorile pentru care sunt de obicei aplicabile sisteme tradiționaleși valori pentru CBS. Cele mai multe metrici tradiționale sunt utilizate în faza de planificare și dezvoltare. Cheia managementului calității atunci când se utilizează metrici în dezvoltarea sistemelor componente este selectarea unor metrici de calitate care sunt aplicabile în toate etapele ciclului de viață și evaluează atât calitatea procesului, cât și calitatea produsului.

Berg O.Yu.

METRICI PENTRU EVALUAREA CALITĂȚII SOFTWARE-ULUI

Pe măsură ce prelucrarea datelor ne afectează din ce în ce mai mult viețile, erorile computerului pot avea acum consecințe precum daune materiale, încălcarea vieții private și multe altele, inclusiv moartea. Fiabilitatea software-ului este probabilitatea funcționării acestuia fără defecțiuni pentru o perioadă de timp. anumită perioadă timp, calculat luând în considerare costul pentru utilizator al fiecărei defecțiuni. Prin urmare, este necesar să se poată măsura calitatea software-ului pe tot parcursul ciclului de dezvoltare. Este recomandabil să se evalueze calitatea software-ului pe baza unor criterii de calitate, care ar trebui:

Caracterizați numeric principalul funcția țintă programe;

Oferă capacitatea de a determina costurile necesare pentru atingerea nivelului necesar de calitate, precum și gradul de influență asupra indicatorului de calitate a diferitelor factori externi;

Fii cât mai simplu posibil, bine măsurabil și ai varianță scăzută.

Metricurile sunt folosite pentru a măsura caracteristicile și criteriile de calitate. În prezent, sunt cunoscute un număr mare de metrici care evaluează producția individuală și proprietățile operaționale ale software-ului. Cu toate acestea, urmărirea versatilității lor, ignorarea domeniului de aplicare a software-ului dezvoltat și etapele ciclului de viață reduce semnificativ eficiența utilizării lor.

Valoarea calității programului este un sistem de măsurare a calității programului. Aceste măsurători pot fi efectuate la nivelul criteriilor de calitate a programului sau la nivelul caracteristicilor individuale de calitate. În primul caz, sistemul de măsurare permite compararea directă a programelor din punct de vedere calitativ. În plus, măsurătorile în sine nu pot fi efectuate fără evaluări subiective ale proprietăților programelor. În al doilea caz, caracteristicile pot fi măsurate în mod obiectiv și fiabil, dar evaluarea calității software-ului în ansamblu va fi asociată cu o interpretare subiectivă a evaluărilor rezultate.

În studiul metricilor software, există două direcții principale:

Căutați metrici care caracterizează cele mai specifice proprietăți ale programelor, de ex. metrici pentru evaluarea software-ului în sine;

Utilizarea unor metrici pentru a evalua performanța tehnică și factorii de dezvoltare a software-ului, de ex. metrici pentru evaluarea condițiilor de dezvoltare a programului.

Pe baza tipului de informații obținute la evaluarea calității software-ului, metricile pot fi împărțite în trei grupuri:

Metrici care evaluează abaterile de la normă în caracteristicile materialelor de proiectare inițială. Ele stabilesc caracterul complet al caracteristicilor tehnice specificate ale codului sursă.

Metrici care vă permit să preziceți calitatea software-ului dezvoltat. Sunt definite pe platou

opțiuni posibile soluţii la o problemă dată şi implementarea lor şi determină calitatea software-ului care

va fi realizat în final.

Măsuri prin care se ia decizia dacă software-ul final îndeplinește cerințele specificate. Acestea vă permit să evaluați conformitatea dezvoltării cu cerințele specificate.

În prezent, câteva sute de metrici ale programului sunt utilizate în practica mondială. Evaluările calitative existente ale programelor pot fi grupate în șase domenii:

Estimări de topologice şi complexitatea informaţiei programe;

Evaluări ale fiabilității sistemelor software, permițând anticiparea situațiilor de defecțiune;

Evaluarea performanței software-ului și îmbunătățirea eficienței acestuia prin identificarea erorilor de proiectare;

Evaluarea nivelului instrumentelor lingvistice și aplicarea acestora;

Evaluări ale dificultății perceptuale și de înțelegere textele programului orientat spre

factori psihologici, esential pentru intretinerea si modificarea programelor;

Estimarea productivității programatorilor pentru a prezice momentul dezvoltării programului și planificarea lucrărilor de creare a sistemelor software.

În funcție de caracteristicile și caracteristicile metricilor utilizate, acestea sunt asociate cu diverse scale de măsurare:

Scara nominală corespunde unor metrici care clasifică programele în tipuri pe baza prezenței sau absenței unei caracteristici fără a ține cont de gradații;

Scara ordinală corespunde unor metrici care vă permit să clasați anumite caracteristici prin comparație cu valorile de referință, adică. măsurarea pe această scară determină de fapt poziția relativă a programelor specifice;

Scala intervalului corespunde unor metrici care arată nu numai poziția relativă a programelor, ci și cât de departe sunt acestea unul de celălalt;

Scara relativă corespunde unor metrici care permit nu numai aranjarea programelor într-un anumit mod și evaluarea poziției acestora unele față de altele, ci și determinarea cât de departe sunt estimările de limita de la care poate fi măsurată caracteristica.

O analiză a experienței tehnologice a liderilor producției de software arată cât de costisitor este pentru imperfecțiunea unei previziuni neștiințifice a solvabilității și a costurilor cu forța de muncă, complexitatea programelor, inflexibilitatea controlului și gestionării dezvoltării acestora și multe altele, indicând lipsa acestora. a suportului metodologic end-to-end și conducând în cele din urmă la nerespectarea acestuia cu cerințele utilizatorului și cu standardul cerut.și la reelaborarea ulterioară dureroasă și consumatoare de timp a acestuia. Aceste circumstanțe necesită o selecție atentă a tehnicilor, modelelor, metodelor de evaluare a calității software-ului, ținând cont de limitările adecvării acestora pentru diferite cicluri de viață, stabilirea ordinii de utilizare în comun a acestora, utilizarea cercetărilor eterogene redundante ale acelorași indicatori pentru a crește fiabilitatea evaluărilor curente, acumularea și integrarea informațiilor metrice eterogene pentru luarea deciziilor de producție în timp util și certificarea produsului final.

În concluzie, trebuie remarcat faptul că atunci când alegeți metrici pentru evaluarea calității software-ului, trebuie să vă ghidați după următoarele reguli:

metrica trebuie să aibă sens atât pentru client, cât și pentru executant;

metrica trebuie să fie obiectivă și definiția ei lipsită de ambiguitate;

metrica ar trebui să permită urmărirea tendinței schimbărilor;

metrica poate fi automatizată.

Analiza metrică a calității efectuată cu atenție în conformitate cu obiectivele de dezvoltare creează baza pentru planificarea corectă și controlul costurilor calității pentru a obține performanța necesară și eficiența resurselor.

LITERATURĂ

1. Liu K., Zhou S. Yang H., Quality Metrics of Object Oriented Design for Software Development and Re-dezvoltare, - Proceedings of the First Asia-Pacific Conference on Quality Software, 2000 IEEE

2. Boehm B. W., Brown J. R., Lipow M. EVALUARE CANTITATIVĂ A CALITĂȚII SOFTWARE Proceedings of the 2nd International Conference on Software Engineering on International Conference on software engineering October 1976

3. Houdek F., Kempter H. Modele de calitate - O abordare a experienței de ambalare a ingineriei software ACM SIGSOFT Note de inginerie software, Proceedings of the 1997 symposium on Symposium on software reusability Mai 1997

4. W. Royce Software Project Management, Moscova, LORI