Deoarece metodele cantitative sunt bine stabilite în alte domenii, mulți teoreticieni și practicieni în informatică au încercat să transfere această abordareși în dezvoltarea de software. După cum spunea Tom DeMarco, „Nu poți controla ceea ce nu poți măsura”.

Metrici

Setul de valori utilizate include:

• ordinea creșterii (adică analiza algoritmilor în ceea ce privește analiza asimptotică și notația O),
• analiza punctului de funcționare,
• numărul de erori la 1000 de linii de cod,
• gradul de acoperire a codului prin testare,
• numărul de clase și interfețe,
• valorile pachetului de software de la Robert Cecil Martin,

Critică

Deficiențe potențiale ale abordării care sunt vizate de critici:

• Neetic: Se argumentează că este lipsit de etică să judeci performanța unui programator pe baza unor metrici introduse pentru a evalua performanța. codul programului. Asemenea metrici binecunoscute precum numărul de linii de cod și complexitatea ciclomatică oferă adesea o idee superficială despre „succesul” alegerii unei anumite abordări în rezolvarea problemelor, cu toate acestea, ele sunt adesea considerate ca un instrument pentru evaluarea calitatea muncii unui dezvoltator. Această abordare duce destul de des la efectul opus, ducând la apariția unor constructe mai lungi și metode opționale redundante în cod.
• Înlocuirea „managementului persoanelor” cu „managementul numărului”, care nu ține cont de experiența angajaților și de celelalte calități ale acestora
• Distorsiuni: Procesul de măsurare poate fi distorsionat din cauza faptului că angajații sunt conștienți de indicatorii care sunt măsurați și caută să optimizeze acești indicatori mai degrabă decât performanța lor. De exemplu, dacă numărul de linii de cod sursă este un indicator important, atunci programatorii se vor strădui să scrie cât mai multe linii posibil și nu vor folosi tehnici de simplificare a codului care reduc numărul de linii.
• Inexactitate: nu există valori care să fie atât de semnificative, cât și suficient de precise. Numărul de linii de cod este pur și simplu numărul de linii; acest indicator nu oferă o idee despre complexitatea problemei care se rezolvă. Analiza punctelor de funcționare a fost dezvoltată pentru a măsura mai bine codul și complexitatea specificațiilor, dar folosește raționamentul personal al măsurătorului, astfel încât diferiți oameni vor obține rezultate diferite.

Vezi de asemenea

• Valori de bază ale codului: LOC, SLOC, Gilb, McCabe, Halstead, OOP și altele

Fundația Wikimedia.

• 2010.
• Odometru

Stetoscop

Vedeți ce înseamnă „Metrici software” în alte dicționare:

Calitatea software-ului Estimarea costurilor de dezvoltare software - În timpul dezvoltării software

Problema estimării costurilor materialelor și/sau a timpului petrecut pentru finalizarea cu succes a proiectului este foarte importantă. Există multe metode de realizare a unei astfel de evaluări, printre care se numără și cele generale... ... Wikipedia Metrici

- are mai multe semnificații: În matematică, metrică este o funcție care determină distanțe în spațiul metric. Metric este un nume alternativ pentru tensorul metric, în special Metric of space-time 4 tensor, care ... ... Wikipedia Acoperire cod - Acest termen are alte semnificații, vezi Acoperire. Acoperirea codului este o măsură utilizată în testarea software-ului. Arată procentul cât cod sursă

programul a fost testat. Tehnica de acoperire a codului a fost... ... Wikipedia Numărul de linii de cod

- Vezi și: Volumul codului Linii sursă de cod SLOC este o măsurătoare software utilizată pentru a măsura volumul său prin numărarea numărului de linii din textul codului sursă. De regulă, ... ... Wikipedia Testare de sarcină - (ing. Load Testing) determinarea sau colectarea indicatorilor de performanță și a timpului de răspuns în mod programatic sistem tehnic

sau dispozitiv ca răspuns la o solicitare externă pentru a stabili conformitatea cu cerințele pentru un anumit sistem ... Wikipedia Testarea performanței

- Acest articol nu are link-uri către surse de informații. Informațiile trebuie să fie verificabile, altfel pot fi puse sub semnul întrebării și șterse. Poți... Wikipedia Scrum

- Dezvoltare software Proces de dezvoltare software Etape proces Analiză Proiectare Programare Document ... Wikipedia Complexitatea ciclomatică - programe (ing. Complexitatea ciclomatică a unui program) măsură structurală (sau topologică) a complexității programului utilizată pentru măsurarea calității software-ului, pe baza metodelor analiza statica

cod. DSP este egal cu ... ... Wikipedia Zabbix

Abordarea metrică a fost dezvoltată inițial exclusiv în scopuri de management de proiect și pentru a atinge conformitatea contractului. Odată atinse obiectivele, acestea au devenit un studiu de caz practic. Performanța proiectului CCPDS-R nu a fost niciodată aproape de optim; în procesul de execuție a fost efectuată în mod constant număr mare 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 muncii î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 conducerii, din dezvoltatori practiciși chiar de la observatorii progresului.

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 latitudinea 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.

Mai jos sunt exemple concrete metrici recomandate în Capitolul 13. Sunt furnizate mai multe exemple de metrici pentru măsurarea progresului, precum și indicatori 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ăsurarea cu precizie a progresului dezvoltării cu mai multe activități paralele în diferite etape a fost o provocare pentru echipă. gestionarea creației Subsisteme de uz general. A trebuit depus un efort considerabil pentru a crea o abordare consecventă care să ofere informații exacte cu privire la starea la nivel de subsistem și starea versiunii. Scopul a fost obținerea unei estimări ponderate care să includă următoarele:.

■ Valori Ada/ADL. A permis determinarea destul de precisă a indicatorilor imediati progres 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 (în cazul nostru, lunar). 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 este relativă la linie punctată(aferent lunii curente) 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 în întârziere cu o lună, dezvoltarea versiunii 3 este înaintea programului cu o lună, dezvoltarea

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

Subsistemul cu scop general este conform programului, dar testarea HT a subsistemului cu scop general este cu o lună întârziere. 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. Cele mai multe 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ă. Acest lucru a crescut probabilitatea ca acest tip de produs de lucru să conțină cele mai recente informații. 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 lansare. 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 PPOP (cu mult înainte de termen) a reflectat impactul pozitiv neașteptat al instrumentelor de generare a codului 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 nu erau exacte în stadiile incipiente ciclu de viață, erau adevărate. 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ă un set complet de 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 oferă o perspectivă asupra măsurătorilor de progres din diverse perspective care au fost utilizate pentru a planifica și urmări programul 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ă HT (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 cu adevărat 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 principalele motive 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%. Configurația inițială de bază a fost stabilită la momentul POP, în luna 14. 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, unde costurile de reluare a ciclului de viață depășesc de obicei 20% din nivel general costuri.

În fig. D.14 arată costul mediu al unei modificări î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 pe 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 designul a fost robust și adaptabil la un număr mare de scenarii de schimbare predeterminate, revizuirea întregului set de mesaje de intrare nu a fost niciodată intenționată și nici designul 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 de scripturi 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 produs 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

Ce poate fi urmărit folosind Metrica

Atragerea vizitatorilor

Rapoartele directe din Metrica arată clar ce campanii, anunțuri, expresii și interogări de căutare aduc vizitatori pe site-ul dvs., din ce regiuni și din ce platforme de publicitate. Utilizați aceste informații pentru a vă optimiza campaniile.

De exemplu, vă puteți îmbunătăți expresiile adăugând cuvinte cheie din interogări de căutare relevante și cuvinte cheie negative din interogări irelevante - acest lucru va ajuta la atragerea mai multor vizitatori interesați și la creșterea CTR.

Publicul site-ului

În Metrica poți obține caracteristici detaliate audienta ta. Sexul, vârsta și interesele vizitatorilor sunt calculate analizând comportamentul acestora pe Internet folosind tehnologia Crypt. Pe baza acestor date, publicitatea poate deveni mai relevantă și, prin urmare, poate crește eficiența acesteia.

Atingerea obiectivelor și a conversiilor

Este important nu doar să aduci vizitatori pe site-ul tău web, ci să înțelegi dacă aceștia devin clienti reali. Pentru a face acest lucru, trebuie să setați obiective în Metrica - adică să determinați acțiunile cheie pe care ar trebui să le efectueze vizitatorii site-ului.

De exemplu, cumpărătorul dvs. ar putea fi un vizitator care:

• a făcut clic pe butonul „Adaugă în coș”;
• a trecut din coș în pagină „Vă mulțumesc pentru achiziție” la plasarea unei comenzi;
• a vizitat cel puțin două pagini ale site-ului;
• a mers la pagina de la informații de contact;
• înregistrat pe site sau abonat la newsletter.

A avea obiective personalizate vă va permite să înțelegeți ce fraze și reclame aduc pe site utilizatorii care își ating obiectivele. Puteți nu doar să analizați creșterea vizitelor vizate, ci și să le optimizați folosind una dintre strategiile automate: Costul mediu de conversie sau Bugetul săptămânal. Conversii maxime.

Venituri

Proprietarii magazinelor online pot primi informații detaliate în Metrica despre comenzile plasate pe site-ul magazinului. Puteți afla câți bani a adus fiecare comandă și din ce canale provin cele mai profitabile comenzi.

Chiar în interfața Metrica, puteți estima rapid costurile de publicitate în Direct. De exemplu, puteți să vă uitați la costurile totale de publicitate, să aflați cost mediu conversii pentru toate campaniile dvs. publicitare, estimați costul mediu sau total al clicurilor pentru anumite tipuri dispozitive, regiuni, interogări de căutare sau platforme.

Apeluri direcționate

Clienții plasează comenzi nu doar pe site, ci și telefonic. Serviciu „Apel țintă” vă permite să comparați eficiența diferitelor canale de promovare. Devii special numere de telefon, care poate fi legat de diferite surse, cu un nivel de detaliu până la individual campanii de publicitate. Numărul de pe site și din cartea de vizită virtuală este înlocuit automat în funcție de sursă - astfel poți urmări unde a aflat fiecare apelant despre tine.

Cum să începeți să colectați statistici

Instalați codul de contor pe toate paginile site-ului dvs. cât mai aproape de partea de sus a paginii - de aceasta depinde completitatea datelor colectate. Puteți verifica corectitudinea instalării contorului în consola browserului.

Dacă creați mai multe campanii cu același set de contoare, puteți specifica contoarele în pagina de setări utilizator din câmp Contor de valori pentru noile campanii.

Până când ați specificat numere de contor, marcarea automată a legăturilor vă va ajuta să transferați date între Direct și Metrica. Asigurați-vă că opțiunea este activată în setările campaniei dvs Marcați linkurile pentru Metrica, iar site-ul dvs. deschide corect link-uri cu etichete.

Cum funcționează marcarea linkurilor

Atenţie. Dacă câmpul din parametrii campaniei nu este completat Contoare de metrici, iar opțiunea este dezactivată Marcați linkurile pentru Metrica, atunci datele despre clicurile pe anunțuri nu vor fi incluse în Metrica, iar datele de la Metrica nu vor fi incluse în statisticile directe.

Întrebări și răspunsuri

Cât de repede se actualizează datele în rapoartele Metrica?

Acțiunile vizitatorilor pe site sunt reflectate în majoritatea rapoartelor Metrica în câteva minute. Datele pentru rapoartele speciale prin Direct sunt procesate verificare suplimentară, așa că ajung la Metrica cu o întârziere de până la câteva ore.

Cât de repede ajung datele privind atingerea obiectivelor în Direct?

Datele privind atingerea unui anumit obiectiv sunt trimise la Direct în 24 de ore.

De ce sunt datele din statistica Direct diferite de cele din Metrica?

Adnotare

Lucrarea oferă o privire de ansamblu asupra a 7 clase de metrici și a peste 50 de reprezentanți ai acestora descriere detaliatăși algoritmii de calcul utilizați, este descris rolul metricilor în dezvoltarea software-ului.

Introducere

Articolul este prima etapă a lucrărilor efectuate de Systems LLC verificarea software-ului„să creeze noi instrumente specializate pentru calcularea metricilor. Este o privire de ansamblu asupra metricilor existente care va ajuta la abordarea sistematică a soluționării unui număr de probleme. Este planificată dezvoltarea unei metodologii de evaluare a complexității portarii software-ului pe alte platforme, ca precum și pentru evaluarea complexității paralelizării codului programului. Această direcție este o dezvoltare a capabilităților produsului PVS-Studio nu numai ca analizor static, ci și ca instrument de predicție a costurilor forței de muncă ale programatorilor atunci când stăpânesc sisteme pe 64 de biți și adaptează algoritmi la sisteme multi-core.

Acest articol va introduce o gamă largă de valori software. Desigur, nu este recomandabil să se prezinte toate metricile existente majoritatea nu sunt niciodată utilizate în practică, fie din cauza imposibilității utilizării ulterioare a rezultatelor, fie din cauza imposibilității de automatizare a măsurătorilor, fie din cauza specializării înguste a acestora; metrics, dar există metrics care sunt folosite destul de des, iar revizuirea lor va fi dată mai jos.

În general, utilizarea metricilor permite managerilor de proiect și de întreprindere să studieze complexitatea unui proiect dezvoltat sau chiar în curs de dezvoltare, să evalueze volumul de muncă, stilul programului dezvoltat și eforturile depuse de fiecare dezvoltator pentru a implementa o anumită soluție. . Cu toate acestea, metricile pot servi doar ca caracteristici de recomandare, ele nu pot fi ghidate complet, deoarece atunci când dezvoltă software, programatorii, încercând să minimizeze sau să maximizeze cutare sau cutare măsură pentru programul lor, pot recurge la trucuri, chiar reducând eficiența programului. În plus, dacă, de exemplu, un programator a scris un număr mic de linii de cod sau a făcut un număr mic de modificări structurale, aceasta nu înseamnă că nu a făcut nimic, ci poate însemna că defectul de program a fost foarte greu de găsit. Ultima problema, cu toate acestea, poate fi parțial rezolvat prin utilizarea metricilor de complexitate, deoarece într-un program mai complex eroarea este mai greu de găsit.

1. Metrici cantitative

În primul rând, ar trebui să luăm în considerare caracteristicile cantitative ale codului sursă al programelor (datorită simplității acestora). Cea mai de bază metrică este numărul de linii de cod (SLOC). Această măsurătoare a fost dezvoltată inițial pentru a estima costurile cu forța de muncă pentru un proiect. Cu toate acestea, deoarece aceeași funcționalitate poate fi împărțită pe mai multe linii sau scrisă pe o singură linie, metrica a devenit practic inutilizabilă odată cu apariția limbilor care pot scrie mai multe comenzi pe o singură linie. Prin urmare, se face o distincție între liniile de cod logice și fizice. Liniile logice de cod sunt numărul de comenzi dintr-un program. Această opțiune descrierea are și dezavantajele sale, deoarece depinde foarte mult de limbajul de programare folosit și de stilul de programare.

Pe lângă SLOC, caracteristicile cantitative includ și:

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.

Uneori se face o distincție suplimentară între ratingul stilistic (F) al programului. Constă în împărțirea programului în n fragmente egale și calcularea punctajului pentru fiecare fragment folosind formula Fi = SIGN (Ncomm.i / Ni - 0,1), unde Ncomm.i este numărul de comentarii din fragmentul i, Ni este numărul total de linii de cod din fragmentul i-lea. Apoi punctajul total pentru întregul program va fi determinat după cum urmează: F = SUMFi.

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

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

n2 - numărul de operanzi unici ai programului (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*log2 (n1) + n2*log2 (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*log2 n - volumul programului,

V"=N"*log2 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,

EC =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" * log2 (n/L) - evaluarea efortului intelectual necesar la elaborarea unui program, care caracterizează numărul necesar solutii elementare 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 bucle. 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

Următoarea clasă mare de metrici, bazată nu pe indicatori cantitativi, ci pe analiza graficului de control al programului, se numește metrici de complexitate a fluxului de control al programului.

Înainte de a descrie direct valorile în sine, pentru mai buna intelegere 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 vârful care denotă sfârșitul programul la vârful care denotă 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:

Din păcate, 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ă (predicat - expresie logică conţinând 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. Măsura complexității programului în acest caz este reprezentată ca o pereche (complexitate ciclomatică, număr de declarații). 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 doar conexiune serială structuri 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țiilor ș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 lua valori diferite pentru graficele 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) + SUMAPi, 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ă una operator logic, nu ca operatori n - 1.

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, atunci această metrică folosit în principal în limbaje slab structurate (Assembler, 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, se numește numărul de vârfuri de arc de intrare grad negativ vârfuri, iar numărul de arce care emană dintr-un vârf este 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 de căi posibile în graficul de control.

3. Măsuri de complexitate a fluxului de date

Următoarea clasă de metrici este metrica de complexitate a fluxului de control al datelor.

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 notă 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ăsură informațională a complexității modulului în raport cu 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(vj )), j=i...||V(i)||

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

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

A patra clasă de metrici sunt metrici care sunt apropiate atât de clasa de metrici cantitative, de clasa de metrici de complexitate a fluxului de control al programului, cât și de clasa de metrici de complexitate a fluxului de control al datelor (strict vorbind, această clasă de metrici și clasa de control al programului) metricile complexității fluxului sunt aceeași clasă - metrici topologice, dar are sens să le separăm în acest context pentru claritate). Această clasă de metrici stabilește complexitatea structurii programului atât pe baza calculelor cantitative, cât și pe baza analizei structurilor de control.

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 simboluri (operanzi, operatori, paranteze) în 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;

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 sistem ierarhic control, care specifică relația de apel pe un set de module de program.

Există și o metrică bazată pe conceptul informațional, măsura Berlinger. Măsura complexității este calculată ca M=SUMfi *log2 pi, unde fi este frecvența de apariție a simbolului i, pi 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

În legătură cu dezvoltarea limbajelor de programare orientate pe obiecte, noua clasa metrici, numite și metrici orientate pe obiecte. În acest grup, cele mai utilizate sunt setul de metrici Martin și setul de metrici Chidamber și Kemerer. Mai întâi, să ne uităm la primul subgrup.

Înainte de a începe să luăm în considerare metricile Martin, este necesar să introducem conceptul de categorie 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 doar î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.

nToate - numărul_total_de_clase_în_categorie.

Valorile acestei valori variază în interval.

Acum, pe baza valorilor Martin de mai sus, puteți construi un grafic care arată relația dintre abstractitate și instabilitate. Dacă construim pe ea o linie 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=SUMci , i=1...n, unde ci este complexitatea metodei i-a, calculată prin oricare dintre metrici (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 clasa cu metode scade, dar cu o 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)((Ri )), i=1...n , unde M sunt toate metodele posibile ale clasei, Ri sunt toate metodele posibile care pot fi numite clasa a 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, considerăm o clasă 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

Următorul tip de metrici sunt metrici care sunt aproape cantitative, dar se bazează pe numărul de erori și defecte din program. Nu are rost să luăm în considerare caracteristicile fiecăreia dintre aceste metrici, va fi suficient să le enumeram pur și simplu: numărul de modificări structurale efectuate de la ultima verificare, numărul de erori identificate în timpul revizuirii codului, numărul de erori identificate în timpul testării. a programului și numărul de modificări structurale necesare pentru funcționarea corectă a programului. Pentru proiecte mari De obicei, acești indicatori sunt considerați în raport cu mii de linii de cod, adică. numărul mediu de defecte la o mie de linii de cod.

7. Metrici hibride

În sfârșit, este necesar să menționăm o altă clasă de metrici numite hibride. Valorile acestei clase se bazează pe valori mai simple și reprezintă suma lor ponderată. Primul reprezentant al acestei clase este metrica Kokol. Este definit astfel:

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).

Valorile utilizate în fiecare opțiune sunt selectate în funcție de sarcină specifică, coeficienți - în funcție de valoarea metricii pentru luarea unei decizii într-un caz dat.

Concluzie

Pentru a rezuma, aș dori să remarc că nu există o singură măsură universală. Orice caracteristici metrice monitorizate ale programului trebuie monitorizate fie în funcție de cealaltă, fie în funcție de sarcina specifică în plus, pot fi utilizate măsuri hibride, dar depind și de metrici mai simple și, de asemenea, nu pot fi universale; Strict vorbind, orice metrică este doar un indicator care depinde puternic de limbaj și stilul de programare, așa că nicio măsură nu poate fi ridicată la un absolut și nicio decizie nu poate fi luată doar pe baza acesteia.

Bibliografie

• Intrare de blog CProVer: „Cercetarea noastră practică în domeniul calculului metricilor.”
• Conceptul de metrică. Instrucțiuni pentru utilizarea valorilor.
  Scale metrice. Indicatori de dificultate. Metrici stilistice. http://www.met-rix.narod.ru/
• T.J. McCabe, „O măsură de complexitate”, IEEE Transactions on Software Engineering, vol. SE-2, nr. 4, pp. 308-320, decembrie 1976.
• Bogdanov D.V., „Standardizarea ciclului de viață software", Sankt Petersburg - 2000, 210 p.
• G.N. Kalyanov. Consultanță pentru automatizarea întreprinderilor: Publicare științifică și practică. Seria „Informatizarea Rusiei în pragul secolului XXI”. - M.: SINTEG, 1997. - 320 p.
• Chernonozhkin S.K., „Metode și instrumente pentru sprijinirea dezvoltării metrice programe de calitate", rezumat, Novosibirsk - 1998
• Curtis R. Cook, „Metrica de teoria informației pentru limbajul de asamblare”
• Shyam R. Chidamber, Chris F. Kemerer, „A Metrics Suite for Object Oriented Design”, 1994

Pe lângă SLOC, caracteristicile cantitative includ și:

• 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, pentru un program ideal L=1

L"= (2 n2)/ (n1*N2) - nivel de calitate a programării, bazat numai pe parametrii unui 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 programului

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 bucle. 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 metricile în sine, pentru o mai bună înțelegere, 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 păcate, această evaluare nu este capabilă să facă distincția între structurile ciclice și cele condiționate. 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. Măsura complexității programului în acest caz este reprezentată ca o pereche (complexitate ciclomatică, număr de declarații). 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țiilor și durata programului.

Fiecărui vârf i se atribuie propria complexitate în funcție de operatorul pe care îl reprezintă. Această complexitate inițială a vârfurilor poate fi calculată în orice mod, inclusiv folosind măsurile 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 lua valori diferite pentru graficele 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 limbaje slab structurate (Assembler, 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 de căi 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ției unui singur modul software prin analizarea naturii utilizării variabilelor din lista de intrare-ieșire.

Î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 prezența în program a unei referințe reale la 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 notă 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ăsură informațională a complexității modulului în raport cu 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 de complexitate a 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 obiect de informație compus (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;

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 metrică din această clasă este 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ă și o metrică bazată pe conceptul informațional, 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 de apariție a 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 doar î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 abstractitate și instabilitate. Dacă construim pe ea o linie 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 clasa cu metode scade, dar cu o 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 reutilizarea clasei devine mai dificila.

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 metodele posibile ale clasei, R i sunt toate metodele posibile care pot fi apelate de i-a. Atunci RFC va fi puterea acestui set. Cu cât mai multe RFC, cu atât mai dificilă va fi testarea.

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 sunt calculate folosind analiza de regresie sau analiza problemelor specifice programului.

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).

Măsurile 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