metrika je kvantitativna skala i metoda koja se može koristiti za mjerenje.
Napominjemo da je uvođenje i korištenje metrike neophodno za poboljšanje kontrole nad procesom razvoja, a posebno nad procesom testiranja, što ćemo dalje razmotriti.
Svrha kontrole testa je dobiti povratnu informaciju i vizualizirati proces testiranja. Informacije potrebne za kontrolu prikupljaju se (i ručno i automatski) i koriste se za procjenu statusa i donošenje odluka kao što su pokrivenost (na primjer, pokrivenost zahtjeva ili koda testovima) ili izlazni kriteriji (na primjer, kriteriji završetka testa). Metrike se također mogu koristiti za procjenu napretka planiranog rada i implementacije budžeta
Kreiranje, korištenje i analiza metrike
Po našem mišljenju, radi veće jasnoće, ima smisla grupirati metriku po tipovima subjekata uključenih u osiguranje kvaliteta i testiranje softvera, i to:
- metrika po testnim slučajevima
- metrika za greške/defekte
- metrika po zadatku
Pogledajmo pobliže svaki od njih:
Metrike za testne slučajeve
metrika grešaka
Napominjemo da metrike “Otvorene/Zatvorene greške”, “Greške po ozbiljnosti” i “Greške po prioritetu” jasno vizualiziraju stepen do kojeg se proizvod približava postizanju kriterija kvaliteta za greške. Imajući zahtjeve za brojem otvorenih grešaka, nakon svake iteracije testiranja upoređujemo ih sa stvarnim podacima i na taj način vidimo mjesta na kojima treba da se poboljšamo kako bismo što brže postigli cilj.
metrike "Ponovno otvorene/zatvorene greške" i "Odbijene/otvorene greške" imaju za cilj praćenje rada pojedinačnih članova timova za razvoj i testiranje.
Primjer jedan:
Recimo da imamo situaciju da se broj bugova koji se ponovo otvaraju nakon popravljanja ne smanjuje ili se čak povećava. To je signal da je potrebno analizirati uzroke, jer Slična situacija može pokazati da:
- Loše kvalitetno rješenje problema (ispravka greške)
Drugi primjerće pokazati zašto je potrebna metrika "Odbijene/otvorene greške":
Primećujemo da je procenat odbijenih grešaka veoma visok. ovo bi moglo značiti:
- Zahtjevi funkcije mogu se tumačiti na različite načine
- Tester nije precizno opisao problem
- Programer ne želi ispraviti grešku koju je napravio ili ne vjeruje da je to zapravo greška. (Ovaj problem je direktna posljedica drugog, koji je nastao zbog netačnog opisa)
Svi ovi problemi značajno destabilizuju situaciju na projektu. Stoga, kada se pojave, preporučuje se kratak razgovor s voditeljima projektnih timova kako bi se naknadno smanjio broj ponovno otkrivenih i odbijenih nedostataka.
metrika po zadatku
| Ime | Opis |
| Zadaci raspoređivanja | metrika pokazuje broj i rezultate instalacija aplikacije. Procedura za instaliranje aplikacije opisana je u članku Procedura za instaliranje nove verzije softvera (Deployment WorkFlow). Ukoliko je broj verzija koje je tim za testiranje odbio kritično visok, preporučuje se hitna analiza i utvrđivanje razloga, kao i rješavanje postojećeg problema što je prije moguće. |
| Još uvijek otvoreni zadaci | metrika pokazuje broj još otvorenih pitanja. Do kraja projekta svi zadaci moraju biti završeni. Pod zadacima podrazumijevamo sljedeće vrste poslova: pisanje dokumentacije (arhitektura, zahtjevi, planovi), implementaciju novih modula ili promjenu postojećih na osnovu zahtjeva za izmjenom, rad na postavljanju štandova, razne studije i još mnogo toga. |
Metrike za zadatke mogu biti različite, dali smo samo dva od njih. metrika za vrijeme završetka zadatka i mnogi drugi također mogu biti zanimljivi.
U zaključku, želimo napomenuti da će vam prisustvo potrebnih metrika i grafikona koji odražavaju promjene statusa projekta tokom vremena omogućiti da poboljšate ne samo proces testiranja, već i razvoj u cjelini, a također će i olakšati proceduru za analizu završenog projekta, što će vam omogućiti da spriječite buduće probleme u budućnosti.
| Video trening. Yandex.Metrica: uvod Pogledajte video |
Šta se može pratiti pomoću Metrice
Privlačenje posetilaca
Direktni izvještaji u Metrici jasno pokazuju koje kampanje, oglasi, fraze i upiti za pretraživanje dovode posjetitelje na vašu web stranicu, iz kojih regija i sa kojih platformi za oglašavanje. Koristite ove informacije da optimizirate svoje kampanje.
Na primjer, možete poboljšati svoje fraze dodavanjem ključnih riječi iz relevantnih upita za pretraživanje i negativnih ključnih riječi iz nerelevantnih upita - to će pomoći privući više zainteresiranih posjetitelja i povećati CTR.
Publika sajta
U Metrici možete dobiti detaljne karakteristike vaše publike. Pol, dob i interesovanja posjetitelja izračunavaju se analizom njihovog ponašanja na internetu korištenjem Crypt tehnologije. Na osnovu ovih podataka oglašavanje se može učiniti relevantnijim i time povećati njegovu efikasnost.
Postizanje ciljeva i konverzije
Važno je ne samo dovesti posjetitelje na svoju web stranicu, već i razumjeti da li oni postaju pravi klijenti. Da biste to učinili, morate postaviti ciljeve u Metrica-u - odnosno odrediti ključne radnje koje posjetitelji stranice trebaju izvršiti.
Na primjer, vaš kupac može biti posjetitelj koji:
- kliknuli na dugme „Dodaj u korpu“;
- išao od korpe do stranice "Hvala vam na kupnji" prilikom naručivanja;
- posjetili najmanje dvije stranice stranice;
- otišao na stranicu sa kontakt informacijama;
- registrovani na sajtu ili pretplaćeni na bilten.
Prilagođeni ciljevi će vam omogućiti da shvatite koje fraze i reklame dovode korisnike na stranicu koji ostvaruju svoje ciljeve. Ne samo da možete analizirati povećanje ciljanih posjeta, već ih i optimizirati koristeći jednu od automatskih strategija: Prosječni trošak konverzije ili Sedmični budžet. Maksimalne konverzije.
Prihod
Vlasnici online trgovina mogu dobiti detaljne informacije u Metrici o narudžbama na web stranici trgovine. Možete saznati koliko novca donosi svaka narudžba i iz kojih kanala dolaze najprofitabilnije narudžbe.
Upravo u sučelju Metrica, možete brzo procijeniti svoje troškove oglašavanja u Directu. Na primjer, možete pogledati svoje ukupne troškove oglašavanja, saznati prosječnu cijenu konverzija za sve svoje reklamne kampanje i procijeniti prosječnu ili ukupnu cijenu klikova za određene vrste uređaja, regija, upita za pretraživanje ili platforme.
Ciljani pozivi
Kupci naručuju ne samo na web stranici, već i putem telefona. Servis "Ciljani poziv" omogućava vam da uporedite efikasnost različitih kanala promocije. Dobijate posebne telefonske brojeve koji se mogu povezati sa različitim izvorima, sa nivoom detalja sve do pojedinačnih reklamnih kampanja. Broj na web stranici i virtuelnoj vizitkarti automatski se zamjenjuje ovisno o izvoru - na taj način možete pratiti gdje je svaki pozivalac saznao za vas.
Kako početi prikupljati statistiku
Instalirajte kod za brojač na sve stranice vašeg sajta što bliže vrhu stranice - o tome zavisi potpunost prikupljenih podataka. Ispravnost instalacije brojača možete provjeriti u konzoli pretraživača.
Ako kreirate više kampanja sa istim skupom brojača, možete odrediti brojače na stranici korisničkih postavki u polju Brojač metrika za nove kampanje.
Dok ne navedete brojeve brojača, automatsko označavanje veze će vam pomoći u prijenosu podataka između Directa i Metrica. Provjerite je li opcija omogućena u postavkama vaše kampanje Označite linkove za Metrica, a vaša stranica ispravno otvara veze sa oznakama.
Kako funkcionira označavanje linkova
Pažnja. Ako polje u parametrima kampanje nije popunjeno Brojači metrika, a opcija je onemogućena Označite linkove za Metrica, tada podaci o klikovima na oglase neće biti uključeni u Metricu, a podaci iz Metrice neće biti uključeni u Direktnu statistiku.
Pitanja i odgovori
Koliko brzo se podaci ažuriraju u Metrica izvještajima?
Radnje posjetitelja na web stranici odražavaju se u većini Metrica izvještaja u roku od nekoliko minuta. Podaci za specijalne izvještaje na Direktu prolaze dodatnu provjeru, pa u Metrici završavaju sa zakašnjenjem i do nekoliko sati.
Koliko brzo podaci o ostvarenju ciljeva dolaze u Direct?
Podaci o postizanju određenog cilja šalju se Direkti u roku od 24 sata.
Zašto se podaci u Direktnoj statistici razlikuju od podataka u Metrici?
Berg O.Yu.
METRIKA ZA PROCJENU KVALITETA SOFTVERA
Kako obrada podataka sve više utječe na naše živote, kompjuterske greške sada mogu imati posljedice kao što su oštećenje imovine, kršenje privatnosti i mnoge druge, uključujući smrt. Pouzdanost softvera je vjerovatnoća njegovog rada bez kvarova u određenom vremenskom periodu, izračunata uzimajući u obzir trošak za korisnika svakog kvara. Stoga je neophodno biti u mogućnosti mjeriti kvalitet softvera tokom cijelog razvojnog ciklusa. Preporučljivo je ocjenjivati kvalitet softvera na osnovu kriterija kvalitete, koji bi trebali:
Numerički karakterizirati glavnu ciljnu funkciju programa;
Omogućiti određivanje troškova potrebnih za postizanje potrebnog nivoa kvaliteta, kao i stepena uticaja različitih eksternih faktora na indikator kvaliteta;
Budite što jednostavniji, dobro mjerljivi i imajte nisku varijaciju.
Metrike se koriste za mjerenje karakteristika i kriterija kvaliteta. Trenutno je poznat veliki broj metrika koje procjenjuju pojedinačna proizvodna i operativna svojstva softvera. Međutim, težnja za njihovom svestranošću, ignorisanje obima softvera koji se razvija i faza životnog ciklusa značajno smanjuje efikasnost njihove upotrebe.
Metrika kvaliteta programa je sistem za merenje kvaliteta programa. Ova mjerenja se mogu vršiti na nivou kriterijuma kvaliteta programa ili na nivou individualnih karakteristika kvaliteta. U prvom slučaju, sistem mjerenja omogućava direktno poređenje programa u pogledu kvaliteta. Štaviše, sama mjerenja se ne mogu izvršiti bez subjektivnih procjena svojstava programa. U drugom slučaju, karakteristike se mogu objektivno i pouzdano mjeriti, ali će procjena kvaliteta softvera u cjelini biti povezana sa subjektivnom interpretacijom rezultirajućih ocjena.
U proučavanju softverske metrike postoje dva glavna pravca:
Tražite metriku koja karakteriše najspecifičnija svojstva programa, tj. metrike za procjenu samog softvera;
Korištenje metrike za procjenu tehničkih performansi i faktora razvoja softvera, npr. metrika za procjenu uslova razvoja programa.
Na osnovu vrste informacija dobijenih prilikom procene kvaliteta softvera, metrike se mogu podeliti u tri grupe:
Metrike koje procjenjuju odstupanja od norme u karakteristikama materijala za početni dizajn. Oni utvrđuju potpunost specificiranih tehničkih karakteristika izvornog koda.
metrika koja vam omogućava da predvidite kvalitet razvijenog softvera. Definisani su na setu
moguće opcije za rješavanje problema i njihovu implementaciju te određuju kvalitet softvera koji
će se na kraju postići.
Metrike pomoću kojih se donosi odluka o tome da li konačni softver ispunjava navedene zahtjeve. Oni vam omogućavaju da procenite usklađenost razvoja sa specificiranim zahtevima.
Trenutno se u svjetskoj praksi koristi nekoliko stotina programskih metrika. Postojeće kvalitativne evaluacije programa mogu se grupisati u šest oblasti:
Procjene topološke i informatičke složenosti programa;
Procjene pouzdanosti softverskih sistema, koje omogućavaju predviđanje situacija kvarova;
Procjena performansi softvera i poboljšanje njegove efikasnosti identificiranjem grešaka u dizajnu;
Procjena nivoa jezičkih sredstava i njihove primjene;
Procjene težine percepcije i razumijevanja programskih tekstova, fokusirane na
psihološki faktori bitni za održavanje i modificiranje programa;
Procjena produktivnosti programera za predviđanje vremena razvoja programa i planiranje rada na kreiranju softverskih sistema.
Ovisno o karakteristikama i karakteristikama korištenih metrika, oni su povezani s različitim mjernim skalama:
Nominalna skala odgovara metrici koja klasifikuje programe u tipove na osnovu prisustva ili odsustva neke karakteristike bez uzimanja u obzir gradacija;
Redna skala odgovara metrikama koje vam omogućavaju rangiranje određenih karakteristika u poređenju sa referentnim vrijednostima, tj. mjerenje na ovoj skali zapravo određuje relativnu poziciju specifičnih programa;
Intervalna skala odgovara metrikama koje pokazuju ne samo relativnu poziciju programa, već i koliko su udaljeni jedan od drugog;
Relativna skala odgovara metrikama koje omogućavaju ne samo da se programi rasporede na određeni način i procijene njihov položaj jedan u odnosu na drugi, već i da se odredi koliko su procjene udaljene od granice s koje se karakteristika može mjeriti.
Analiza tehnološkog iskustva lidera u proizvodnji softvera pokazuje koliko je to skupo zbog nesavršenosti nenaučne prognoze rješivosti i troškova rada, složenosti programa, nefleksibilnosti kontrole i upravljanja njihovim razvojem i još mnogo toga, što ukazuje na nedostatak end-to-end metodološke podrške i u konačnici dovodi do njenog neusklađenosti sa zahtjevima korisnika i traženog standarda, te do naknadne bolne i dugotrajne prerade iste. Ove okolnosti zahtijevaju pažljiv odabir tehnika, modela, metoda za procjenu kvaliteta softvera, uzimajući u obzir ograničenja njihove prikladnosti za različite životne cikluse, utvrđivanje redosljeda njihove zajedničke upotrebe, korištenje suvišnih heterogenih istraživanja istih indikatora za povećanje pouzdanost trenutnih procjena, akumulacija i integracija heterogenih metričkih informacija za donošenje pravovremenih odluka o proizvodnji i sertifikaciju finalnog proizvoda.
U zaključku, treba napomenuti da se prilikom odabira metrike za procjenu kvaliteta softvera morate voditi sljedećim pravilima:
metrika mora imati smisla i za kupca i za izvođača;
metrika mora biti objektivna i njena definicija nedvosmislena;
metrika bi trebala omogućiti praćenje trenda promjena;
metrika se može automatizirati.
Pažljivo sprovedena metrička analiza kvaliteta u skladu sa razvojnim ciljevima stvara osnovu za pravilno planiranje i kontrolu troškova kvaliteta radi postizanja zahtevanih performansi i efikasnosti resursa.
LITERATURA
1. Liu K., Zhou S. Yang H., metrika kvaliteta objektno orijentiranog dizajna za razvoj i ponovni razvoj softvera, - Zbornik radova Prve azijsko-pacifičke konferencije o kvalitetnom softveru, 2000. IEEE
2. Boehm B. W., Brown J. R., Lipow M. KVANTITATIVNA OCJENA KVALITETA SOFTVERA Zbornik radova 2. međunarodne konferencije o softverskom inženjerstvu na Međunarodnoj konferenciji o softverskom inženjerstvu, oktobar 1976.
3. Houdek F., Kempter H. Obrasci kvaliteta – pristup pakovanju iskustva softverskog inženjeringa ACM SIGSOFT Napomene o softverskom inženjerstvu, Zbornik radova simpozijuma o ponovnoj upotrebi softvera iz 1997. godine, maj 1997.
4. W. Royce Software Project Management, Moskva, LORI
Chernikov Alexey
1. Uvod
Za razliku od većine industrija materijalne proizvodnje, u pitanjima projekata razvoja softvera neprihvatljivi su jednostavni pristupi zasnovani na množenju intenziteta rada sa prosječnom produktivnošću rada. To je uzrokovano, prije svega, činjenicom da ekonomski pokazatelji projekta nelinearno zavise od obima posla, a prilikom izračunavanja intenziteta rada dopuštena je velika greška.
Stoga se za rješavanje ovog problema koriste složene i prilično složene metode koje zahtijevaju veliku odgovornost u primjeni i određeno vrijeme za prilagođavanje (podešavanje koeficijenata).
Savremeni sveobuhvatni sistemi za procenu karakteristika projekata razvoja softvera mogu se koristiti za rešavanje sledećih problema:
- preliminarna, trajna i konačna procjena ekonomskih parametara projekta: intenzitet rada, trajanje, cijena;
- procjena rizika za projekat: rizik od kršenja rokova i neispunjenja projekta, rizik povećanja intenziteta rada u fazama otklanjanja grešaka i podrške projektu itd.;
- donošenje operativnih upravljačkih odluka - na osnovu praćenja određenih projektnih metrika, moguće je pravovremeno spriječiti pojavu neželjenih situacija i eliminirati posljedice loše osmišljenih projektantskih odluka.
1. Uvod
2 metrike
2.1 metrika orijentirana na dimenzije (indikatori procjene volumena)
2.1.1 LOC procjena (linije koda)
2.1.1.1 metrika stilistike i razumljivosti programa
2.1.2 Ukupno prema SLOC
2.2 metrika težine
2.2.2 Halstead metrika
2.2.4 Chapin metrika
2.4 Opšta lista metrika
2.4 Sumiranje
6 Internet resursi
2. metrika
metrika složenosti programa obično se dijeli u tri glavne grupe:
- metrika veličine programa;
- metrika složenosti toka kontrole programa;
- metrika složenosti programskog toka podataka.
Metrike prve grupe zasnivaju se na određivanju kvantitativnih karakteristika vezanih za veličinu programa i relativno su jednostavne. Najpoznatije metrike ove grupe uključuju broj programskih izraza, broj redova izvornog teksta i skup Halstead metrika. metrike u ovoj grupi su fokusirane na analizu izvornog koda programa. Stoga se mogu koristiti za procjenu složenosti razvojnih međuproizvoda.
Metrike druge grupe zasnivaju se na analizi kontrolnog grafa programa. Predstavnik ove grupe je McCabe metrika.
Kontrolni graf programa, koji koristi metrika ove grupe, može se izgraditi na osnovu modulskih algoritama. Stoga se metrika druge grupe može koristiti za procjenu složenosti srednjih razvojnih proizvoda.
Metrike treće grupe zasnivaju se na procjeni upotrebe, konfiguracije i smještaja podataka u programu. Ovo se prvenstveno odnosi na globalne varijable. Ova grupa uključuje Chapin metriku.
2.1 metrika orijentirana na dimenzije (indikatori procjene količine)
2.1.1 LOC procjena (linije koda)
Mere orijentisane na dimenzije direktno mere softverski proizvod i njegov razvojni proces. Takve metrike su zasnovane na LOC procjenama.
Ova vrsta metrike indirektno mjeri softverski proizvod i njegov razvojni proces. Umjesto izračunavanja LOC rezultata, gleda se na funkcionalnost ili korisnost proizvoda, a ne na veličinu.
Dimenzionalno orijentisane metrike se najčešće koriste u praksi razvoja softvera. U organizacijama koje se bave razvojem softverskih proizvoda, uobičajeno je da se za svaki projekat registruju sledeći indikatori:
- ukupni troškovi rada (u čovjek-mjesecima, čovjek-sati);
- veličina programa (u hiljadama linija izvornog koda -LOC);
- trošak razvoja;
- obim dokumentacije;
- greške otkrivene tokom godine rada;
- broj ljudi koji rade na proizvodu;
- razvojni period.
Na osnovu ovih podataka obično se izračunavaju jednostavne metrike za procjenu produktivnosti rada (KLOC/čovjek-mjesec) i kvaliteta proizvoda.
Ove metrike nisu univerzalne i kontroverzne, posebno za indikator kao što je LOC, koji značajno ovisi o korištenom programskom jeziku.
Broj redova izvornog koda (Lines of Code - LOC, Source Lines of Code - SLOC) je najjednostavniji i najčešći način za procjenu količine posla na projektu.
U početku je ovaj pokazatelj nastao kao način za procjenu količine posla na projektu koji je koristio programske jezike s prilično jednostavnom strukturom: „jedan red koda = jedna jezična komanda“. Odavno je poznato da se ista funkcionalnost može napisati u različit broj redova, a ako uzmemo jezik visokog nivoa (C++, Java), onda je moguće napisati 5-6 linija funkcionalnosti u jednom redu - ovo nije problem. I to ne bi bilo tako loše: savremeni programski alati sami generišu hiljade linija koda za trivijalnu operaciju.
Stoga je LOC metoda samo evaluativna metoda (koju treba uzeti u obzir, ali se na nju ne oslanjati u procjenama) i ni na koji način nije obavezna.
U zavisnosti od toga koliko se sličan kod uzima u obzir, postoje dva glavna SLOC indikatora:
- broj “fizičkih” linija koda - SLOC (korištene skraćenice su LOC, SLOC, KLOC, KSLOC, DSLOC) - definira se kao ukupan broj redova izvornog koda, uključujući komentare i prazne redove (kada se mjeri indikator na broja praznih redova obično se uvodi ograničenje - Prilikom izračunavanja uzima se u obzir broj praznih redova koji ne prelazi 25% ukupnog broja redova u izmjerenom bloku koda).
- Broj “logičkih” linija koda – SLOC (korištene skraćenice su LSI, DSI, KDSI, gdje su “SI” izvorne instrukcije) – definira se kao broj naredbi i ovisi o korištenom programskom jeziku. Ako jezik ne dozvoljava postavljanje više naredbi u jedan red, tada će broj “logičkih” SLOC-ova odgovarati broju “fizičkih”, s izuzetkom broja praznih redova i redova za komentare. Ako programski jezik podržava postavljanje više naredbi u jednu liniju, onda se jedna fizička linija mora računati kao više logičkih linija ako sadrži više od jedne jezičke naredbe.
Za SLOC metriku postoji veliki broj derivata dizajniranih za dobijanje pojedinačnih indikatora projekta, a glavni su:
- broj praznih linija;
- broj redova koji sadrže komentare;
- procenat komentara (odnos redova koda i redova komentara, izvedena stilska metrika);
- prosječan broj linija za funkcije (klase, datoteke);
- prosječan broj redova koji sadrže izvorni kod za funkcije (klase, datoteke);
- prosječan broj redova za module.
2.1.1.1 metrika stilistike i razumljivosti programa
Ponekad je važno ne samo izbrojati broj redova komentara u kodu i jednostavno ih povezati s logičkim redovima koda, već saznati gustinu komentara. Odnosno, kod je prvo bio dobro dokumentovan, a onda loše. Ili ova opcija: zaglavlje funkcije ili klase je dokumentirano i komentirano, ali kod nije.
Fi = ZNAK (Ncomm. i / Ni – 0,1)
Suština metrike je jednostavna: kod se dijeli na n jednakih dijelova i za svaki od njih se određuje Fi
2.1.2 Ukupno prema SLOC-u
Potencijalni nedostaci SLOC-a koji su na meti kritika:
- Ružno je i netačno svoditi ocjenu rada osobe na nekoliko numeričkih parametara i po njima suditi o produktivnosti. Menadžer može dodijeliti najtalentovanije programere u najteže područje rada; to znači da će razvoj ovog odjeljka trajati najduže i generirati najviše grešaka zbog složenosti zadatka. Ne znajući za ove poteškoće, drugi menadžer može na osnovu dobijenih pokazatelja odlučiti da je programer loše uradio svoj posao.
- metrika ne uzima u obzir iskustvo zaposlenih i njihove druge kvalitete
- Distorzija: Proces mjerenja može biti iskrivljen zbog činjenice da su zaposleni svjesni indikatora koji se mjere i nastoje optimizirati ove pokazatelje, a ne svoj učinak. Na primjer, ako je broj redova izvornog koda važan pokazatelj, tada će programeri nastojati da napišu što je moguće više redaka i neće koristiti tehnike pojednostavljenja koda koje smanjuju broj redova (pogledajte bočnu traku o Indiji).
- Nepreciznost: Ne postoje metrike koje su dovoljno značajne i tačne. Broj redova koda je jednostavno broj redova; ovaj indikator ne daje predstavu o složenosti problema koji se rješava. Analiza funkcionalnih tačaka je razvijena kako bi se bolje izmjerila složenost koda i specifikacije, ali koristi ličnu procjenu mjerača, tako da će različiti ljudi dobiti različite rezultate.
I glavna stvar koju treba zapamtiti: SLOC metrika ne odražava radni intenzitet kreiranja programa
.
| Primjer iz života
: U jednoj od kompanija, tokom implementacije, koristili smo ovu metriku – brojali smo redove koda. Šef organizacije je bio na odmoru, ali je po povratku s njega odlučio iskoristiti transparentnost i sljedivost promjena i vidjeti kako njegovi menadžeri rade sa svojim projektima. A da bih u potpunosti razumio kurs, spustio sam se na najniži nivo (to jest, nisam procijenio gustinu defekata, broj ispravljenih grešaka) - na nivo izvornih tekstova. Odlučio sam da prebrojim ko je napisao i koliko redova. A da bude zaista zabavno, uporedite broj radnih dana u sedmici i količinu napisanog koda (logika je jednostavna: osoba je radila 40 sati sedmično, što znači da mora pisati puno stvari). Naravno, postojala je osoba koja je napisala samo jedan red u sedmici, nije ga ni napisala, već je samo ispravila postojeći... Menadžerov gnev nije imao granice - pronašao je lenčinu! I bilo bi loše za programera da menadžer projekta nije objasnio da: pronađena je greška u programu, pronašao ju je VIP klijent, greška utiče na poslovanje klijenta i to je trebalo hitno ispraviti, za ovu svrhu izabran je izvođač, koji je postavio štand, preplavio okolinu klijenta, potvrdio nastanak greške i počeo da je traži i otklanja. Naravno, na kraju je promijenio dio koda koji je bio u pogrešnom stanju i sve je funkcioniralo. |
Slažem se, glupo je izračunavati troškove rada koristeći ovu metriku - neophodna je sveobuhvatna procjena...
2.2 metrika težine
Pored indikatora za procjenu obima posla na projektu, indikatori za procjenu njegove složenosti su veoma važni za dobijanje objektivnih ocjena projekta. Ovi pokazatelji se po pravilu ne mogu izračunati u najranijim fazama rada na projektu, jer zahtijevaju, u najmanju ruku, detaljan dizajn. Međutim, ovi pokazatelji su veoma važni za dobijanje prognostičkih procjena trajanja i troškova projekta, jer direktno određuju njegov radni intenzitet.
2.2.1 Objektno orijentisana metrika
U savremenim uslovima, većina softverskih projekata se kreira na osnovu OO pristupa, pa stoga postoji značajan broj metrika koje omogućavaju procenu složenosti objektno orijentisanih projekata.
|
metrika |
Opis |
| Ponderisane metode po klasi (WMC) | Odražava relativnu meru složenosti klase zasnovanu na ciklomatskoj složenosti svake od njenih metoda. Klasa sa složenijim metodama i više metoda smatra se složenijom. Roditeljske klase se ne uzimaju u obzir prilikom izračunavanja metrike. |
| Ponderisane metode po klasi (WMC2) |
Mjera složenosti klase zasnovana na ideji da je klasa s više metoda složenija i da je metoda s više parametara također složenija. Roditeljske klase se ne uzimaju u obzir prilikom izračunavanja metrike. |
| Dubina stabla nasljeđivanja | Dužina najduže staze nasljeđivanja koja završava u ovom modulu. Što je dublje stablo nasljeđivanja modula, to može biti teže predvidjeti njegovo ponašanje. S druge strane, povećanje dubine daje veći potencijal datom modulu da ponovo koristi ponašanje definirano za klase predaka. |
| Broj djece | Broj modula koji direktno nasljeđuju dati modul Velike vrijednosti ove metrike ukazuju na visoku mogućnost ponovne upotrebe; u ovom slučaju prevelika vrijednost može ukazivati na loše odabranu apstrakciju. |
|
Spajanje između objekata |
Broj modula povezanih s ovim modulom u ulozi klijenta ili dobavljača. Prekomjerno spajanje ukazuje na slabu modularnu enkapsulaciju i može spriječiti ponovnu upotrebu koda. |
| Odgovor za klasu | Broj metoda koje mogu pozvati instance klase; izračunava i zbroj broja lokalnih metoda i broja udaljenih metoda |
2.2.2 Halstead metrika
Halstedova metrika se odnosi na metriku izračunatu na osnovu analize broja linija i sintaksičkih elemenata izvornog koda programa.
Halstead metrika je zasnovana na četiri mjerljive karakteristike programa:
- NUOprtr (Broj jedinstvenih operatora) - broj jedinstvenih programskih operatora, uključujući znakove za razdvajanje, imena procedura i znakove operacija (rečnik operatora);
- NUOprnd (Broj jedinstvenih operanda) - broj jedinstvenih programskih operanda (rečnik operanda);
- Noprtr (Broj operatera) - ukupan broj operatera u programu;
- Noprnd (Broj operanda) - ukupan broj operanada u programu.
Na osnovu ovih karakteristika izračunavaju se rezultati:
- Programski rječnik
(Halstead programski vokabular, HPVoc): HPVoc = NUOprtr + NUOprnd; - Dužina programa
(Dužina Halstead programa, HPLen): HPLen = Noprtr + Noprnd; - Opseg programa
(Halstead Program Volume, HPVol): HPVol = HPLen log2 HPVoc; - Složenost programa
(Halstead poteškoća, HDiff): HDiff = (NUOprtr/2) × (NOprnd / NUOprnd); - Na osnovu indikatora HDiff, predlaže se evaluacija razvojnih napora programera pomoću indikatora HEff (Halstead Effort): HEff = HDiff × HPVol.
2.2.3 McCabeova ciklomatska metrika složenosti
Indikator ciklomatske složenosti jedan je od najčešćih indikatora za procjenu složenosti softverskih projekata. Ovaj indikator je razvio naučnik McCabe 1976. godine, pripada grupi indikatora za procjenu složenosti kontrolnog toka programa i izračunava se na osnovu logičkog grafa kontrole programa (control flow graph). Ovaj graf je konstruisan u obliku usmjerenog grafa, u kojem su računski operatori ili izrazi predstavljeni kao čvorovi, a prijenos kontrole između čvorova predstavljen je kao lukovi.
Indikator ciklomatske složenosti omogućava ne samo procjenu radnog intenziteta implementacije pojedinih elemenata softverskog projekta i prilagođavanje ukupnih indikatora za procjenu trajanja i troškova projekta, već i procjenu povezanih rizika i donošenje potrebnih upravljačkih odluka.
Pojednostavljena formula za izračunavanje ciklomatske složenosti je sljedeća:
C = e – n + 2,
Gdje e – broj rebara , i n – broj čvorova
na grafu kontrolne logike.
Obično se logički operatori ne uzimaju u obzir prilikom izračunavanja ciklomatske složenosti.
U procesu automatizovanog izračunavanja indikatora ciklomatske složenosti, po pravilu se koristi pojednostavljeni pristup prema kojem se graf ne konstruiše, već se indikator izračunava na osnovu brojanja logičkih operatora upravljanja (ako, prekidač, itd.) i mogući broj putanja izvršavanja programa.
McCabeov ciklomatski broj označava broj prolaza potrebnih za pokrivanje svih kontura čvrsto povezanog grafa, ili broj probnih pokretanja programa potrebnih za iscrpno testiranje "svaka grana radi".
Pokazatelj ciklomatske složenosti može se izračunati za modul, metodu i druge strukturne jedinice programa.
Postoji značajan broj modifikacija indikatora ciklomatske složenosti.
- „Modifikovana“ ciklomatska složenost – ne razmatra svaku granu operatora višestrukog izbora (switch), već čitav operator kao jedinstvenu celinu.
- „Striktna“ ciklomatska složenost – uključuje logičke operatore.
- „Pojednostavljeno“ izračunavanje ciklomatske složenosti - uključuje izračunavanje ne na osnovu grafikona, već na osnovu brojanja kontrolnih operatora.
2.2.4 Chapin metrika
Postoji nekoliko njegovih modifikacija. Razmotrimo jednostavniju, i sa stanovišta praktične upotrebe, prilično učinkovitu verziju ove metrike.
Suština metode je procijeniti informacijsku snagu jednog softverskog modula analizom prirode upotrebe varijabli sa ulazno-izlazne liste.
Čitav skup varijabli koje čine I/O listu podijeljen je u četiri funkcionalne grupe.
Q = a1P + a2M + a3C + a4T, gdje su a1, a2, a3, a4 težinski koeficijenti.
Q = P + 2M + 3C + 0,5T.
2.3 Preliminarna procjena zasnovana na statističkim metodama u zavisnosti od faza razvoja programa
Prilikom korišćenja integrisanih alata, kompanije koje razvijaju standardna rešenja (u ovu kategoriju spadaju tzv. „inhauseri” – kompanije koje se bave servisiranjem osnovne delatnosti) imaju mogućnost da na osnovu prikupljenih statistika prave prognoze složenosti programa. Statistička metoda je vrlo pogodna za rješavanje takvih tipičnih problema i praktično nije prikladna za predviđanje jedinstvenih projekata. U slučaju jedinstvenih projekata koriste se i drugi pristupi, čija rasprava je izvan okvira ovog materijala.
Tipični zadaci padaju iz izobilja poslovanja u razvojne odjele, pa bi preliminarna procjena složenosti mogla uvelike pojednostaviti zadatke planiranja i upravljanja, pogotovo jer postoji akumulirana baza podataka za projekte u kojoj se ne pohranjuju samo konačni rezultati, već i svi početni i srednjih.
Istaknimo tipične faze u razvoju programa:
- razvoj specifikacije programskih zahtjeva;
- definicija arhitekture;
- razvoj modularne strukture programa, razvoj interfejsa između modula. Razvoj algoritama;
- razvoj koda i testiranje.
Pokušajmo sada pogledati nekoliko metrika koje se često koriste za preliminarnu procjenu u prve dvije faze.
2.3.1 Preliminarna procjena složenosti programa u fazi izrade specifikacije zahtjeva programa
Za procjenu rezultata ove faze može se koristiti metrika predviđenog broja operatora Nprog programa:
Nprogn =NF*Jedinica
Gdje je: NF – broj funkcija ili zahtjeva u specifikaciji zahtjeva za program koji se razvija;
Ned – pojedinačna vrijednost broja operatora (prosječan broj operatora po jednoj prosječnoj funkciji ili zahtjevu). Ned vrijednost je statistička.
2.3.2 Preliminarna procjena složenosti u fazi definiranja arhitekture
Si = NI / (NF * NIed * Ksl)
gdje:
NI – ukupan broj varijabli prenetih preko interfejsa između programskih komponenti (također statistički);
NIed – pojedinačna vrijednost broja varijabli prenesenih preko interfejsa između komponenti (prosečan broj varijabli prenetih preko interfejsa po jednoj prosečnoj funkciji ili zahtevu);
Ksl je koeficijent složenosti programa koji se razvija, uzima u obzir povećanje složenosti jedinice programa (složenost po jednoj funkciji ili zahtjev specifikacije programskih zahtjeva) za velike i složene programe u poređenju sa prosječnim softverom.
2.4 Opšta lista metrika
Tabela 1 sadrži kratak opis metrika koje nisu obuhvaćene gore navedenim detaljnim opisom, ali su ipak ove metrike neophodne i važne, samo su statistički mnogo manje uobičajene.
Također imajte na umu da je svrha ovog članka da pokaže princip, a ne da opiše sve moguće metrike u mnogim kombinacijama.
Pozdrav, prijatelji. Nakon duge faze razvoja i još dužeg beta testiranja, novi Yandex Metrica 2.0 izlazi iz sjene. Od 22. juna postat će glavni alat za prikupljanje i analizu statistike, dok će stara verzija biti prebačena na poddomen old.metrika.yandex.ru, gdje će doživjeti svoje posljednje mjesece.
Oduševljen sam Yandex metric Beta, iako je trebalo neko vrijeme da se udubim u nju i shvatim njene mogućnosti. Ali isplati se - barem sam pronašao nekoliko stvari za sebe koje ni trenutna verzija ni Analytics ne mogu učiniti.
Zapravo, u ovom materijalu pokušat ću za vas analizirati proces rada, sastaviti upute za web analitiku u novoj Yandex metrici, budući da je nešto drugačija od svog prethodnika i može izazvati kognitivnu disonancu pri prvom upoznavanju.
- Dakle, pogledajte beta metriku.
- Ne želim, bojim se nje.
Razgovor sa poznatim SEO stručnjakom.
Dakle, prvo konceptualni dio. Koja je glavna razlika? Old Metrica je uglavnom skup gotovih rezova (izvještaja) za analizu. Njihovo postavljanje i kreiranje vlastitih kriški je teško i nezgodno. Iz tog razloga se za mnoge ovaj proces sastoji samo od rada sa „Cilevima“, koji su, srećom, namijenjeni nečemu sasvim drugom, a „Izvještaji“ ostaju negdje tamo, na prašnjavoj polici, izvan zagrada.
Trenutni je već punopravni plastelin koji vam omogućava da prilagodite apsolutno bilo koji odjeljak prema vašim potrebama, postavite početne podatke, filtrirate ono što je nepotrebno i odaberete prikladnu opciju prezentacije podataka. Potpuno prilagodite svoj radni prostor, što posebno cijene internet marketingu.
A sada redom
Trenutno se beta još uvek nalazi na https://beta.metrika.yandex.ru/ i prikaz liste sajtova nije pretrpeo suštinske promene sa izuzetkom nekoliko dodataka i prikazanog procenta rasta prometa u odnosu na do prethodnog dana, koji je sada tako pažljivo skinut sa stare verzije (kažu, hajde, idemo dalje, navikni se).
Novi sistem etiketa i panel za brzi pristup su veoma praktični. Omogućava vam da kreirate nekoliko oznaka u tabli definicije oznaka i dodelite jednu ili više njih svakoj lokaciji (u stvari, uključujući ih u grupe ovih oznaka). Zatim, odabirom opcije istog imena na tabli definicije naljepnice, prikažite grupe kojima najčešće pristupate na panelu za brzi pristup. Osim toga, prilikom pregleda jedne od grupa, prikazat će se zbirna statistika prometa za web-lokacije uključene u nju.
Ali kada pređete na zaseban šalter, možete početi da se gubite. Pogledajmo interfejs.
Meni novog Yandex metric interfejsa
Stavke gornjeg menija ne trebaju uvod, ali struktura i neke stavke lijevog menija trebaju. Pre svega, ono što znamo:
- Sažetak - glavna stranica brojača stranice.
- Mape - mape klikova, skrolovanja, linkova i analitika obrazaca. Općenito, većina sadržaja stavke "Ponašanje" je stara verzija.
- Postavke - zapravo, postavke trenutnog brojača Yandex metrika.
Ali posljednja stavka - "Izvještaji" - je kamen temeljac ažuriranog alata.
- Moji izvještaji su svi dijelovi koje ste kreirali i sačuvali.
- Odabrani su ista stvar, samo odabrani (buđenje, Neo).
- Standardni izvještaji - ovdje se nalaze svi stari i bolno poznati dijelovi. Na njih ćemo se vratiti kasnije u materijalu.
Interfejs glavne stranice brojača
Konstruktor početne stranice je sličan onome što je bio u staroj Yandex Metrica, ali je, za razliku od potonjeg, ergonomičniji i ima impresivan skup gotovih widgeta. Pa, fleksibilnost podešavanja segmenta svojstvena novoj verziji takođe se ovde oseća.
Možete odabrati gotov widget iz biblioteke ili kreirati novi: indikator, tortni grafikon, grafikon ili tabelu podataka. Prilagodite dio informacija prikazanih u njima i zakačite ih na željeni dio ekrana sa sažetkom pomoću jednostavnog lijeka&drop.
Rad sa segmentima u Yandex Metrica
Dakle, dolazimo do glavne stvari - opisa šeme generisanja izvještaja. Prije svega, idemo na prethodno navedene standardne izvještaje (“Izvještaji” - “Standard Report”) i odabiremo informacije koje ćemo potom segmentirati. Na primjer, "Izvori" - "Izvori, sažetak".
I sada počinjemo birati samo one posjete koje želimo analizirati. Na primjer, želimo da saznamo broj ljudi koji su posjetili stranicu sa tableta iz Yandex tražilice za upit koji je uključivao riječ "SEO". Da bismo to učinili, postavili smo tri nivoa segmentacije:
- "Segment" - "Tehnologije" - "Uređaji" - u prozoru opcija koji se otvori odaberite "Tableti".
- "Segment" - "Izvori" - "Posljednji izvor" - "Pretraga" - "Tražilica" - u prozoru opcija koji se otvori odaberite "Yandex".
- "Segment" - "Izvori" - "Posljednji izvor" - "Traži" - "Izraz za pretraživanje" - u prozoru koji se otvori unesite *SEO* (operatori zvjezdice označavaju bilo koji skup znakova s obje strane ove riječi).
Ukupno: grafikoni i tabela sa informacijama će biti preuređeni na način koji nam je potreban, spremni za preuzimanje ili analizu. U hodu možete mijenjati, uklanjati ili dodati nove nivoe preciziranja - prikazane informacije će se ažurirati u hodu.
Ovdje možemo usporediti rezultirajući segment s drugim, koristeći alat “Uporedi segmente” - “Ručno specificirano”. Međutim, ne možemo mijenjati sastav segmenta, već jednostavno uporediti nekoliko perioda jednog isječka koristeći opciju „Prethodni period“.
Ni ovdje nisu zaboravljeni dobri stari „Ciljevi“, koje možemo koristiti kao još jedan parametar za pojašnjavanje za konstruiranje segmenta.
Broj opcija za izradu segmenata je praktično neograničen. Zatim možemo analizirati primljene informacije i zaboraviti na odabir, ili ih sačuvati i pristupiti im kasnije iz menija “Izvještaji” - “Moji izvještaji” ili jednostavno učitati podatke.
Webvisor Yandex metrika
Gore navedeni proces segmentacije je bio vrlo zgodan za ovaj alat. Odabir zapisa posjeta interesnim grupama korisnika postao je još lakši. Procedura je ista - idite na “Webvisor”, postavite segment (ili ga učitajte iz sačuvanih) i pogledajte.
Ovdje završavam ovo uputstvo za recenziju, i kao i uvijek, radujem se vašim pitanjima u komentarima.
