Metrici este o scară cantitativă și o metodă care poate fi utilizată pentru măsurare.
Am dori să adăugăm că introducerea și utilizarea metricilor este necesară pentru a îmbunătăți controlul asupra procesului de dezvoltare și, în special, asupra procesului de testare, pe care îl vom lua în considerare în continuare.
Scopul controlului testului este de a obține feedback și de a vizualiza procesul de testare. Informațiile necesare controlului sunt colectate (atât manual, cât și automat) și utilizate pentru a evalua starea și a lua decizii precum acoperirea (de exemplu, acoperirea cerințelor sau codul cu teste) sau criteriile de ieșire (de exemplu, criteriile de terminare a testului). Măsurile pot fi utilizate și pentru a evalua progresul lucrărilor planificate și al implementării bugetului
Crearea, utilizarea și analizarea valorilor
În opinia noastră, pentru o mai mare claritate, este logic să grupăm metricile pe tipuri de entități implicate în asigurarea calității și testarea software-ului, și anume:
- Valori în funcție de cazuri de testare
- Valori pentru erori/defecte
- Valori în funcție de sarcină
Să aruncăm o privire mai atentă la fiecare dintre ele:
Metrici pentru cazurile de testare
Valorile erorilor
Dorim să remarcăm că metricile „Erori deschise/închise”, „Erori după gravitate” și „Erori după prioritate” vizualizează clar gradul în care produsul se apropie de atingerea criteriilor de calitate pentru erori. Având cerințe pentru numărul de erori deschise, după fiecare iterație de testare le comparăm cu date reale, văzând astfel locurile în care trebuie să ne îmbunătățim pentru a atinge obiectivul cât mai repede posibil.
Valorile „Erori redeschise/închise” și „Erori respinse/deschise” au scopul de a urmări activitatea membrilor individuali ai echipelor de dezvoltare și testare.
Exemplul unu:
Să presupunem că avem o situație în care numărul de bug-uri redeschise după remediere nu scade sau chiar crește. Acesta este un semnal că este necesar să se analizeze cauzele, deoarece O situație similară poate arăta că:
- Soluție de proastă calitate la problemă (remediere erori)
Al doilea exemplu va arăta de ce este necesară valoarea „Erori respinse/deschise”:
Observăm că procentul de erori respinse este foarte mare. Aceasta ar putea însemna:
- Cerințele funcției pot fi interpretate în moduri diferite
- Testerul nu a descris corect problema
- Dezvoltatorul nu vrea să corecteze greșeala pe care a făcut-o sau nu crede că este de fapt o greșeală. (Această problemă este o consecință directă a celei de-a 2-a, care a apărut din cauza unei descrieri inexacte)
Toate aceste probleme destabiliza în mod semnificativ situația din proiect. Prin urmare, atunci când apar, se recomandă să purtați o scurtă conversație cu șefii echipei de proiect pentru a reduce ulterior numărul de defecte redescoperite și respinse.
Valori în funcție de sarcină
| Nume | Descriere |
| Sarcini de implementare | Valoarea arată numărul și rezultatele instalărilor aplicației. Procedura de instalare a aplicației a fost descrisă în articolul Procedura de instalare a unei noi versiuni de software (Deployment WorkFlow). Dacă numărul de versiuni respinse de echipa de testare este extrem de mare, se recomandă analizarea și identificarea urgentă a motivelor, precum și rezolvarea cât mai curând posibil a problemei existente. |
| Sarcini încă deschise | Valoarea arată numărul de probleme încă deschise. Până la sfârșitul proiectului, toate sarcinile trebuie finalizate. Prin sarcini intelegem urmatoarele tipuri de munca: redactarea documentatiei (arhitectura, cerinte, planuri), implementarea modulelor noi sau schimbarea celor existente in baza solicitarilor de modificare, lucru la amenajarea standurilor, diverse studii si multe altele. |
Valorile pentru sarcini pot fi diferite, am dat doar două dintre ele. Valorile pentru timpul de finalizare a sarcinii și multe altele pot fi, de asemenea, interesante.
În concluzie, am dori să remarcăm că prezența măsurătorilor și graficelor necesare care reflectă schimbările în starea proiectului de-a lungul timpului vă va permite să îmbunătățiți nu numai procesul de testare, ci și dezvoltarea în ansamblu și, de asemenea, facilitează procedura de analiză a proiectului finalizat, ceea ce vă va permite să preveniți problemele viitoare în viitor.erori.
| Video de antrenament. Yandex.Metrica: introducere Priveste filmarea |
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 puteți obține caracteristici detaliate ale publicului dvs. 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, ci să înțelegi dacă aceștia devin clienți adevărați. 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ă "Multumesc pentru cumparaturile facute" la plasarea unei comenzi;
- a vizitat cel puțin două pagini ale site-ului;
- a mers la pagina cu 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 costul mediu al conversiilor pentru toate campaniile dvs. publicitare și să estimați costul mediu sau total al clicurilor pentru anumite tipuri de 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. Primești numere de telefon speciale care pot fi legate la diferite surse, cu un nivel de detaliu până la campaniile de publicitate individuale. 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.
Intrebari si raspunsuri
Cât de repede se actualizează datele în rapoartele Metrica?
Acțiunile unui vizitator pe un site web sunt reflectate în majoritatea rapoartelor Metrica în câteva minute. Datele pentru rapoartele speciale de pe Direct sunt supuse verificărilor suplimentare, astfel încât ajung în 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 statisticile directe diferite de cele din Metrica?
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 anumită perioadă de timp, calculată ținând cont de 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 funcția obiectiv principal a programului;
Oferă capacitatea de a determina costurile necesare atingerii nivelului de calitate cerut, precum și gradul de influență a diferiților factori externi asupra indicatorului de calitate;
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
posibile opţiuni de rezolvare a problemei şi implementarea acestora ş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 ale complexității topologice și informaționale a programelor;
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 de a percepe și înțelege textele programului, axate pe
factori psihologici esențiali pentru menținerea și 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
Cernikov Alexei
1. Introducere
Spre deosebire de majoritatea industriilor de producție de materiale, în materie de proiecte de dezvoltare software, abordările simple bazate pe înmulțirea intensității muncii cu productivitatea medie a muncii sunt inacceptabile. Acest lucru este cauzat, în primul rând, de faptul că indicatorii economici ai proiectului depind neliniar de volumul de muncă, iar la calcularea intensității forței de muncă este permisă o eroare mare.
Prin urmare, pentru rezolvarea acestei probleme se folosesc metode complexe și destul de complexe, care necesită o mare responsabilitate în aplicare și un anumit timp de adaptare (coeficienți de ajustare).
Sistemele moderne cuprinzătoare pentru evaluarea caracteristicilor proiectelor de dezvoltare software pot fi utilizate pentru a rezolva următoarele probleme:
- evaluarea preliminară, permanentă și finală a parametrilor economici ai proiectului: intensitatea muncii, durata, costul;
- evaluarea riscurilor pentru proiect: riscul de încălcare a termenelor limită și de neîndeplinire a proiectului, riscul de creștere a intensității forței de muncă în etapele de depanare și susținere a proiectului etc.;
- luarea deciziilor de management operațional - pe baza urmăririi anumitor metrici ale proiectului, este posibil să se prevină cu promptitudine apariția unor situații nedorite și să se elimine consecințele deciziilor de proiectare prost concepute.
1. Introducere
2 metrici
2.1 Metrici orientate pe dimensiune (indicatori de estimare a volumului)
2.1.1 Evaluarea LOC (Linii de cod)
2.1.1.1 Măsuri de stilistică și înțelegere a programelor
2.1.2 Total după SLOC
2.2 Indicatori de dificultate
2.2.2 Metrici Halstead
2.2.4 Metrici Chapin
2.4 Lista generală de metrici
2.4 Rezumat
6 resurse de internet
2. Metrici
Măsurile de complexitate a programului sunt de obicei împărțite în trei grupuri principale:
- metrici pentru dimensiunea programului;
- metrici de complexitate a fluxului de control al programului;
- metrici ale complexității fluxului de date din program.
Metricurile primului grup se bazează pe determinarea caracteristicilor cantitative legate de dimensiunea programului și sunt relativ simple. Cele mai cunoscute valori ale acestui grup includ numărul de instrucțiuni de program, numărul de linii de text sursă și un set de metrici Halstead. Măsurile din acest grup sunt concentrate pe analiza textului sursă al programelor. Prin urmare, ele pot fi utilizate pentru a evalua complexitatea intermediarilor de dezvoltare.
Valorile celui de-al doilea grup se bazează pe analiza graficului de control al programului. Un reprezentant al acestui grup este metrica McCabe.
Graficul de control al programului, care este utilizat de metricile acestui grup, poate fi construit pe baza algoritmilor modulului. Prin urmare, metricile celui de-al doilea grup pot fi utilizate pentru a evalua complexitatea produselor de dezvoltare intermediară.
Valorile celui de-al treilea grup se bazează pe evaluarea utilizării, configurației și plasării datelor în program. Aceasta se referă în primul rând la variabilele globale. Acest grup include valorile Chapin.
2.1 Metrici orientate pe dimensiune (indicatori de evaluare a volumului)
2.1.1 Evaluarea LOC (Linii de cod)
Măsurile orientate pe dimensiuni măsoară direct un produs software și procesul de dezvoltare al acestuia. Astfel de valori se bazează pe estimări LOC.
Acest tip de metrici măsoară indirect produsul software și procesul de dezvoltare a acestuia. În loc să calculeze scorurile LOC, se analizează mai degrabă funcționalitatea sau utilitatea produsului decât dimensiunea.
Metricile orientate pe dimensiuni sunt cele mai utilizate pe scară largă în practica dezvoltării software. În organizațiile implicate în dezvoltarea de produse software, se obișnuiește să se înregistreze următorii indicatori pentru fiecare proiect:
- costurile totale ale forței de muncă (în luni-om, ore-om);
- dimensiunea programului (în mii de linii de cod sursă -LOC);
- costul de dezvoltare;
- volumul documentației;
- erori descoperite pe parcursul unui an de funcționare;
- numărul de persoane care lucrează la produs;
- perioada de dezvoltare.
Pe baza acestor date, sunt de obicei calculate valori simple pentru a evalua productivitatea muncii (KLOC/om-lună) și calitatea produsului.
Aceste metrici nu sunt universale și controversate, mai ales pentru un astfel de indicator precum LOC, care depinde în mod semnificativ de limbajul de programare utilizat.
Numărul de linii de cod sursă (Lines of Code - LOC, Source Lines of Code - SLOC) este modalitatea cea mai simplă și cea mai comună de a estima cantitatea de muncă pe un proiect.
Inițial, acest indicator a apărut ca o modalitate de a evalua cantitatea de muncă pe un proiect care a folosit limbaje de programare cu o structură destul de simplă: „o linie de cod = o comandă de limbă”. De asemenea, se știe de mult că aceeași funcționalitate poate fi scrisă în numere diferite de linii, iar dacă luăm un limbaj de nivel înalt (C++, Java), atunci este posibil să scriem 5-6 linii de funcționalitate într-o singură linie - aceasta nu este o problemă. Și asta nu ar fi atât de rău: instrumentele moderne de programare generează în sine mii de linii de cod pentru o operație banală.
Prin urmare, metoda LOC este doar o metodă de evaluare (de care ar trebui luată în considerare, dar nu se bazează pe evaluări) și nu este în niciun caz obligatorie.
În funcție de modul în care este luat în considerare codul similar, există doi indicatori principali SLOC:
- numărul de linii „fizice” de cod - SLOC (abrevierile utilizate sunt LOC, SLOC, KLOC, KSLOC, DSLOC) - este definit ca numărul total de linii de cod sursă, inclusiv comentarii și linii goale (la măsurarea indicatorului pe numărul de linii goale, de obicei se introduce o limită - La calcul se ia în considerare numărul de linii goale, care nu depășește 25% din numărul total de linii din blocul de cod măsurat).
- Numărul de linii „logice” de cod – SLOC (abrevierile folosite sunt LSI, DSI, KDSI, unde „SI” reprezintă instrucțiuni sursă) – este definit ca numărul de comenzi și depinde de limbajul de programare utilizat. Dacă limbajul nu permite plasarea mai multor comenzi pe o singură linie, atunci numărul de SLOC-uri „logice” va corespunde numărului de comenzi „fizice”, cu excepția numărului de linii goale și de comentarii. Dacă un limbaj de programare acceptă plasarea mai multor comenzi pe o linie, atunci o linie fizică trebuie socotită ca mai multe linii logice dacă conține mai multe comenzi de limbă.
Pentru metrica SLOC, există un număr mare de derivate menite să obțină indicatori individuali de proiect, principalii fiind:
- numărul de linii goale;
- numărul de rânduri care conțin comentarii;
- procentul de comentarii (raportul dintre liniile de cod și liniile de comentariu, metrica stilistică derivată);
- 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.
2.1.1.1 Măsuri de stilistică și înțelegere a programelor
Uneori este important nu doar să numărăm numărul de linii de comentarii din cod și să le corelezi pur și simplu cu liniile logice de cod, ci să afli densitatea comentariilor. Adică, codul a fost mai întâi bine documentat, apoi prost. Sau această opțiune: antetul unei funcții sau clase este documentat și comentat, dar codul nu este.
Fi = SIGN (Ncom. i / Ni – 0,1)
Esența metricii este simplă: codul este împărțit în n bucăți egale și Fi este determinat pentru fiecare dintre ele
2.1.2 Total după SLOC
Dezavantaje potențiale ale SLOC care sunt vizate de critici:
- Este urât și incorect să reduceți evaluarea muncii unei persoane la câțiva parametri numerici și să judeci productivitatea după aceștia. Managerul poate atribui cei mai talentați programatori în cel mai dificil domeniu de lucru; aceasta înseamnă că dezvoltarea acestei secțiuni va dura cel mai mult timp și va genera cele mai multe erori din cauza complexității sarcinii. Fără a ști despre aceste dificultăți, un alt manager poate decide pe baza indicatorilor obținuți că programatorul și-a făcut treaba prost.
- Metrica 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 propria lor performanță. 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 (vezi bara laterală despre India).
- 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.
Și principalul lucru de reținut: metrica SLOC nu reflectă intensitatea muncii pentru crearea unui program
.
| Exemplu din viață
: Într-una dintre companii, în timpul implementării, am folosit această metrică - am numărat linii de cod. Șeful organizației era în vacanță, dar la întoarcerea din ea a decis să profite de transparența și trasabilitatea schimbărilor și să vadă cum se descurcă managerii săi cu proiectele lor. Și pentru a înțelege pe deplin cursul, am coborât la cel mai jos nivel (adică nu am evaluat densitatea defectelor, numărul de bug-uri remediate) - la nivelul textelor sursă. Am decis să număr cine a scris și câte rânduri. Și ca să fie cu adevărat distractiv, compară numărul de zile lucrătoare pe săptămână și cantitatea de cod scris (logica este simplă: o persoană a lucrat 40 de ore pe săptămână, ceea ce înseamnă că trebuie să scrie o mulțime de lucruri). Desigur, a existat o persoană care a scris doar un rând într-o săptămână, nici măcar nu a scris-o, ci a corectat doar pe cel existent... Furia managerului nu a cunoscut limite - a găsit un leneș! Și ar fi rău pentru programator dacă managerul de proiect nu ar explica că: a fost găsită o eroare în program, un client VIP a găsit-o, eroarea afectează afacerea clientului și trebuia remediată urgent, în acest scop acest anume A fost selectat antreprenorul care a instalat standul, a inundat mediul clientului, a confirmat apariția erorii și a început să o caute și să o elimine. Firește, în cele din urmă, a schimbat fragmentul de cod care avea starea greșită și totul a funcționat. |
De acord, este stupid să calculezi costurile forței de muncă folosind această măsurătoare - este necesară o evaluare cuprinzătoare...
2.2 Indicatori de dificultate
Pe lângă indicatorii de evaluare a volumului de muncă la un proiect, indicatorii de evaluare a complexității acestuia sunt foarte importanți pentru obținerea unor evaluări obiective ale proiectului. De regulă, acești indicatori nu pot fi calculați în primele etape ale lucrării la un proiect, deoarece necesită cel puțin o proiectare detaliată. Cu toate acestea, acești indicatori sunt foarte importanți pentru obținerea estimărilor de prognoză privind durata și costul proiectului, deoarece determină în mod direct intensitatea muncii acestuia.
2.2.1 Metrici orientate pe obiecte
În condițiile moderne, majoritatea proiectelor software sunt create pe baza abordării OO și, prin urmare, există un număr semnificativ de metrici care permit evaluarea complexității proiectelor orientate pe obiecte.
|
Metrici |
Descriere |
| Metode ponderate pe clasă (WMC) | Reflectă o măsură relativă a complexității unei clase bazată pe complexitatea ciclomatică a fiecăreia dintre metodele sale. O clasă cu metode mai complexe și mai multe metode este considerată mai complexă. Clasele părinte nu sunt luate în considerare la calcularea valorii. |
| Metode ponderate pe clasă (WMC2) |
O măsură a complexității clasei bazată pe ideea că o clasă cu mai multe metode este mai complexă și că o metodă cu mai mulți parametri este, de asemenea, mai complexă. Clasele părinte nu sunt luate în considerare la calcularea valorii. |
| Adâncimea arborelui moștenire | Lungimea celei mai lungi căi de moștenire care se termină în acest modul. Cu cât arborele de moștenire al unui modul este mai adânc, cu atât poate fi mai dificil să preziceți comportamentul acestuia. Pe de altă parte, creșterea adâncimii oferă un potențial mai mare pentru un anumit modul de a reutiliza comportamentul definit pentru clasele strămoși. |
| Numărul de copii | Numărul de module care moștenesc direct un anumit modul. Valorile mari ale acestei metrici indică o reutilizare ridicată; în acest caz, o valoare prea mare poate indica o abstractizare prost aleasă. |
|
Cuplare între obiecte |
Numărul de module asociate acestui modul în rolul de client sau furnizor. Cuplarea excesivă indică o încapsulare modulară slabă și poate preveni reutilizarea codului. |
| Răspuns pentru clasă | Numărul de metode care pot fi apelate de instanțe ale clasei; calculează atât suma numărului de metode locale, cât și a numărului de metode la distanță |
2.2.2 Metrici Halstead
Metrica Halsted se referă la valorile calculate pe baza analizei numărului de linii și a elementelor sintactice ale codului sursă al programului.
Valoarea Halstead se bazează pe patru caracteristici măsurabile ale programului:
- NUOprtr (Număr de operatori unici) - numărul de operatori unici de program, inclusiv caractere separatoare, nume de proceduri și semne de operație (dicționar operator);
- NUOprnd (Număr de operanzi unici) - numărul de operanzi unici de program (dicționar de operanzi);
- Noprtr (Număr de operatori) - numărul total de operatori din program;
- Noprnd (Număr de operanzi) - numărul total de operanzi din program.
Pe baza acestor caracteristici, se calculează scorurile:
- Dicționarul programului
(Vocabularul programului Halstead, HPVoc): HPVoc = NUOprtr + NUOprnd; - Durata programului
(Lungimea programului Halstead, HPLen): HPLen = Noprtr + Noprnd; - Domeniul de aplicare al programului
(Volum programului Halstead, HPVol): HPVol = HPLen log2 HPVoc; - Complexitatea programului
(Dificultate Halstead, HDiff): HDiff = (NUOprtr/2) × (NOprnd / NUOprnd); - Pe baza indicatorului HDiff, se propune evaluarea eforturilor de dezvoltare ale programatorului folosind indicatorul HEff (Halstead Effort): HEff = HDiff × HPVol.
2.2.3 Metrica de complexitate ciclomatică a lui McCabe
Indicatorul de complexitate ciclomatică este unul dintre cei mai comuni indicatori pentru evaluarea complexității proiectelor software. Acest indicator a fost dezvoltat de omul de știință McCabe în 1976, aparține grupului de indicatori pentru evaluarea complexității fluxului de control al unui program și este calculat pe baza graficului logic de control al programului (graficul fluxului de control). Acest graf este construit sub forma unui graf direcționat, în care operatorii de calcul sau expresiile sunt reprezentați ca noduri, iar transferul de control între noduri este reprezentat ca arce.
Indicatorul de complexitate ciclomatică permite nu numai evaluarea intensității muncii de implementare a elementelor individuale ale unui proiect software și ajustarea indicatorilor generali pentru estimarea duratei și costului proiectului, dar și evaluarea riscurilor asociate și luarea deciziilor de management necesare.
O formulă simplificată pentru calcularea complexității ciclomatice este următoarea:
C = e – n + 2,
Unde e – numărul de coaste , si n - numărul de noduri
pe graficul logic de control.
De obicei, operatorii logici nu sunt luați în considerare la calcularea complexității ciclomatice.
În procesul de calcul automat al indicatorului de complexitate ciclomatică, de regulă, se utilizează o abordare simplificată, conform căreia graficul nu este construit, iar indicatorul este calculat pe baza numărării numărului de operatori logici de control (dacă comutați, etc.) și numărul posibil de programe de căi de execuție.
Numărul ciclomatic al lui McCabe indică numărul de treceri necesare pentru a acoperi toate circuitele unui grafic strâns conectat sau numărul de rulări de testare ale unui program necesare pentru testarea exhaustivă „fiecare ramură lucrează”.
Indicatorul de complexitate ciclomatică poate fi calculat pentru un modul, metodă și alte unități structurale ale programului.
Există un număr semnificativ de modificări ale indicatorului de complexitate ciclomatică.
- Complexitatea ciclomatică „modificată” – nu ia în considerare fiecare ramură a unui operator cu alegere multiplă (comutator), ci întregul operator ca un întreg unic.
- Complexitate ciclomatică „strictă” – include operatori logici.
- Calcul „simplificat” al complexității ciclomatice - implică calculul nu pe baza unui grafic, ci pe baza numărării operatorilor de control.
2.2.4 Metrici Chapin
Există mai multe modificări ale acestuia. Să luăm în considerare o versiune mai simplă, și din punct de vedere al utilizării practice, destul de eficientă a acestei metrici.
Esența metodei este de a evalua puterea informațiilor 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 patru grupuri funcționale.
Q = a1P + a2M + a3C + a4T, unde a1, a2, a3, a4 sunt coeficienți de ponderare.
Q = P + 2M + 3C + 0,5T.
2.3 Evaluare preliminară bazată pe metode statistice în funcție de etapele de dezvoltare a programului
Atunci când folosesc instrumente integrate, companiile care dezvoltă soluții standard (această categorie include așa-numitele „inhausers” - companii angajate în deservirea activității de bază) au posibilitatea de a face previziuni ale complexității programelor pe baza statisticilor colectate. Metoda statistică este potrivită pentru rezolvarea unor astfel de probleme tipice și practic nu este potrivită pentru a prezice proiecte unice. În cazul proiectelor unice, se folosesc alte abordări, a căror discuție depășește sfera acestui material.
Sarcinile tipice se încadrează dintr-o abundență de departamente de afaceri către departamentele de dezvoltare, astfel încât o evaluare preliminară a complexității ar putea simplifica foarte mult sarcinile de planificare și management, mai ales că există o bază de date acumulată pentru proiecte în care sunt stocate nu numai rezultatele finale, ci și toate inițiale și cele intermediare.
Să evidențiem etapele tipice ale dezvoltării programului:
- elaborarea specificațiilor cerințelor programului;
- definirea arhitecturii;
- dezvoltarea structurii modulare a programului, dezvoltarea interfețelor între module. Dezvoltarea algoritmilor;
- dezvoltarea și testarea codului.
Acum, să încercăm să ne uităm la o serie de metrici care sunt adesea folosite pentru evaluarea preliminară în primele două etape.
2.3.1 Evaluarea preliminară a complexității programului în etapa de elaborare a specificațiilor cerințelor programului
Pentru evaluarea rezultatelor acestei etape se poate folosi metrica numărului estimat de operatori Nprog ai programului:
Nprogn =NF*Nunit
Unde: NF – numărul de funcții sau cerințe din specificația cerințelor pentru programul în curs de dezvoltare;
Ned – o singură valoare a numărului de operatori (numărul mediu de operatori pentru o funcție sau cerință medie). Valoarea Ned este statistică.
2.3.2 Evaluarea preliminară a complexității în etapa de definire a arhitecturii
Si = NI / (NF * NIed * Ksl)
Unde:
NI – numărul total de variabile transmise prin interfețe între componentele programului (de asemenea statistice);
NIed – o singură valoare a numărului de variabile transferate prin interfețe între componente (numărul mediu de variabile transferate peste interfețe pentru o funcție sau cerință medie);
Ksl este coeficientul de complexitate al programului în curs de dezvoltare, ține cont de creșterea complexității unitare a programului (complexitate pe o funcție sau cerință a specificației cerințelor programului) pentru programe mari și complexe în comparație cu software-ul mediu.
2.4 Lista generală de metrici
Tabelul 1 conține o scurtă descriere a valorilor care nu sunt incluse în descrierea detaliată de mai sus, dar, cu toate acestea, aceste valori sunt necesare și importante, ele sunt doar mult mai puțin comune din punct de vedere statistic.
De asemenea, rețineți că scopul acestui articol este de a arăta principiul și nu de a descrie toate valorile posibile în multe combinații.
Salutări, prieteni. După o etapă lungă de dezvoltare și teste beta și mai lungi, noul Yandex Metrica 2.0 iese din umbră. Din 22 iunie, va deveni principalul instrument de colectare și analiză a statisticilor, în timp ce versiunea veche va fi transferată în subdomeniul old.metrika.yandex.ru, unde își va trăi ultimele luni.
Sunt încântat de Yandex Metrika Beta, deși a durat ceva timp să mă aprofundez în ea și să îi înțeleg capacitățile. Dar merită - cel puțin am găsit câteva lucruri pentru mine pe care nici versiunea actuală, nici Analytics nu le pot face.
De fapt, în acest material voi încerca să analizez procesul de lucru pentru dvs., să compun instrucțiuni pentru analiza web în noul Yandex Metrica, deoarece este oarecum diferit de predecesorul său și poate provoca disonanță cognitivă la prima cunoaștere.
- Așa că uită-te prin valoarea beta.
- Nu vreau, mi-e frică de ea.
Conversație cu un specialist SEO familiar.
Deci mai întâi partea conceptuală. Care este principala diferență? Old Metrica este în mare parte un set de felii gata făcute (rapoarte) pentru analiză. Configurarea lor și crearea propriilor felii este dificilă și incomod. Din acest motiv, pentru mulți, acest proces constă doar în lucrul cu „Obiective”, care, din fericire, sunt destinate cu totul altceva, iar „Rapoartele” rămân undeva acolo, pe un raft prăfuit, în afara parantezelor.
Actuala este deja o plastilină cu drepturi depline, care vă permite să personalizați absolut orice secțiune pentru a se potrivi nevoilor dvs., să setați datele inițiale, să filtrați ceea ce este inutil și să selectați o opțiune convenabilă de prezentare a datelor. Personalizați-vă complet spațiul de lucru, care este apreciat în special de specialiștii în marketing pe internet.
Și acum în ordine
În prezent, versiunea beta este încă localizată la https://beta.metrika.yandex.ru/ și vizualizarea listei de site-uri nu a suferit modificări fundamentale, cu excepția câtorva completări și a procentului afișat de creștere a traficului relativ până în ziua precedentă, care acum a fost eliminată cu atâta grijă din versiunea veche (se zic, hai, trece, obișnuiește-te).
Noul sistem de etichete și panoul de acces rapid sunt foarte convenabile. Vă permite să creați mai multe etichete în panoul de definire a etichetelor și să atribuiți una sau mai multe dintre ele fiecărui site (de fapt, incluzându-le în grupuri de aceste etichete). Apoi, selectând opțiunea cu același nume în panoul de definire a etichetei, afișați grupurile pe care le accesați cel mai des în panoul de acces rapid. În plus, la vizualizarea unuia dintre grupuri, vor fi prezentate statistici sumar de trafic pentru site-urile incluse în acesta.
Dar odată ce treceți la un contor separat, puteți începe să vă pierdeți. Să ne uităm la interfață.
Meniul noii interfețe Yandex Metrika
Elementele din meniul de sus nu au nevoie de introducere, dar structura și unele elemente din meniul din stânga au nevoie. În primul rând, ceea ce știm:
- Rezumat - pagina principală a contorului site-ului.
- Hărți - hărți de clicuri, derulare, linkuri și analize de formulare. În general, majoritatea conținutului articolului „Comportament” este versiunea veche.
- Setări - de fapt, setările contorului actual Yandex Metrica.
Dar ultimul element - „Rapoarte” - este piatra de temelie a instrumentului actualizat.
- Rapoartele mele sunt toate secțiunile pe care le-ați creat și salvat.
- Aleșii sunt același lucru, doar aleșii (trezire, Neo).
- Rapoarte standard - aici se află toate secțiunile vechi și dureros de familiare. Vom reveni la ele mai târziu în material.
Interfața paginii principale a contorului
Constructorul paginii de pornire este similar cu ceea ce era în vechiul Yandex Metrica, dar, spre deosebire de acesta din urmă, este mai ergonomic și are un set impresionant de widget-uri gata făcute. Ei bine, aici se face simțită și flexibilitatea setărilor de segment inerente noii versiuni.
Puteți selecta un widget gata făcut din bibliotecă sau puteți crea unul nou: indicator, diagramă circulară, grafic sau tabel de date. Personalizați o porțiune a informațiilor afișate în ele și fixați-le în partea dorită a ecranului rezumat folosind un simplu drog și picurare.
Lucrul cu segmente în Yandex Metrica
Așadar, ajungem la principalul lucru - o descriere a schemei de generare a rapoartelor. În primul rând, mergem la rapoartele standard menționate anterior („Rapoarte” - „Raport standard”) și selectăm informațiile pe care apoi le vom segmenta. De exemplu, „Surse” - „Surse, rezumat”.
Și acum începem să selectăm doar acele vizite pe care dorim să le analizăm. De exemplu, dorim să aflăm numărul de persoane care au vizitat site-ul de pe o tabletă din motorul de căutare Yandex pentru o interogare care a inclus cuvântul „SEO”. Pentru a face acest lucru, am stabilit în consecință trei niveluri de segmentare:
- „Segment” - „Tehnologii” - „Dispozitive” - în fereastra de opțiuni care se deschide, selectați „Tablete”.
- „Segment” - „Surse” - „Ultima sursă” - „Căutare” - „Motor de căutare” - în fereastra de opțiuni care se deschide, selectați „Yandex”.
- „Segment” - „Surse” - „Ultima sursă” - „Căutare” - „Expresie de căutare” - în fereastra care se deschide, introduceți *SEO* (operatorii cu asterisc indică orice set de caractere pe ambele părți ale acestui cuvânt).
Total: graficele și tabelul cu informații vor fi rearanjate în modul în care avem nevoie, gata pentru descărcare sau analiză. Din mers, puteți modifica, elimina sau adăuga noi niveluri de rafinament - informațiile afișate vor fi actualizate din mers.
Aici putem compara segmentul rezultat cu altul, folosind instrumentul „Comparare segmente” - „Specificat manual”. Cu toate acestea, nu putem modifica compoziția segmentului, ci pur și simplu comparăm mai multe perioade dintr-o felie folosind opțiunea „Perioada anterioară”.
Nici aici nu au fost uitate vechile „Goaluri” bune, pe care le putem folosi ca un alt parametru clarificator pentru construirea unui segment.
Numărul de opțiuni pentru construirea segmentelor este practic nelimitat. În continuare, putem analiza informațiile primite și uităm de selecție, sau le putem salva și accesa ulterior din meniul „Rapoarte” - „Rapoartele mele”, sau pur și simplu să încărcăm datele.
Webvisor Yandex Metrics
Procesul de segmentare de mai sus a fost foarte util pentru acest instrument. Selectarea înregistrărilor vizitelor la grupurile de utilizatori de interes a devenit și mai ușoară. Procedura este aceeași - accesați „Webvisor”, configurați un segment (sau încărcați-l din cele salvate) și uitați-vă.
Aici închei această instrucțiune de revizuire și, ca întotdeauna, aștept cu nerăbdare întrebările dumneavoastră în comentarii.
