Metrika je kvantitativna ljestvica i metoda koja se može koristiti za mjerenje.
U svoje osobno ime dodajemo da je uvođenje i korištenje metrike potrebno 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.... Kontrolne informacije se prikupljaju (i ručno i automatski) i koriste za procjenu statusa i donošenje odluka kao što su pokrivenost (npr. pokrivenost testom zahtjeva ili koda) ili izlazni kriteriji (npr. kriteriji završetka testa). metrike se također mogu koristiti za procjenu napretka planiranog rada i iskorištenja proračuna.
Izradite, koristite i analizirajte metriku
Po našem mišljenju, radi veće jasnoće, ima smisla grupirati metriku prema vrstama subjekata uključenih u osiguranje kvalitete i testiranje softvera, i to:
- metrike testnih slučajeva
- Mjerni podaci o greškama/defektima
- metrika zadatka
Pogledajmo pobliže svaki od njih:
metrika testnog slučaja
metrika grešaka
Napominjemo da metrike "Otvorene / zatvorene greške", "Bugovi po ozbiljnosti" i "Bugovi po prioritetu" dobro vizualiziraju stupanj do kojeg se proizvod približava ispunjavanju kriterija kvalitete za greške. Imajući zahtjeve za brojem otvorenih bugova, nakon svake iteracije testiranja, uspoređujemo ih sa stvarnim podacima, pri čemu vidimo mjesta na koja trebamo dodati kako bismo što prije postigli cilj.
metrike "Ponovno otvorene/zatvorene greške" i "Odbijene/otvorene greške" osmišljene su za praćenje izvedbe pojedinačnih članova razvojnih i testnih timova.
Primjer jedan:
Recimo da imamo situaciju da se broj bugova koji su ponovno otvoreni nakon popravljanja ne smanjuje ili čak raste. To je signal da je potrebno provesti analizu uzroka, budući da situacija poput ove može pokazati da:
- Površno rješenje problema loše kvalitete (popravak bugova)
Drugi primjer pokazat će za što je potrebna metrika "Odbijene / otvorene greške":
Primjećujemo da je postotak odbijenih grešaka vrlo visok. to može značiti:
- Zahtjevi funkcije mogu se tumačiti na različite načine
- Tester nije točno opisao problem
- Programer ne želi ispraviti pogrešku koju je napravio ili ne vjeruje da je to zapravo greška. (Ovaj problem je izravna posljedica 2., koji je nastao zbog netočnog opisa)
Svi ovi problemi značajno destabiliziraju situaciju na projektu. Stoga se, ukoliko se dogode, preporuča provesti kraći razgovor s voditeljima projektnih timova kako bi se naknadno smanjio broj ponovno otkrivenih i odbijenih nedostataka.
metrika zadatka
| Ime | Opis |
| Zadaci raspoređivanja | Mjerni podatak pokazuje broj i rezultate instalacija aplikacije. Postupak instalacije aplikacije opisan je u članku Postupak instalacije tijeka rada implementacije. Ako je broj verzija koje je testni tim odbio kritično velik, preporuča se hitna analiza i utvrđivanje razloga, kao i rješavanje postojećeg problema što je prije moguće. |
| Još uvijek otvoreni zadaci | Mjerni podatak pokazuje broj zadataka koji su još otvoreni. Do kraja projekta svi bi zadaci trebali biti zatvoreni. Pod zadacima podrazumijevamo sljedeće vrste poslova: pisanje dokumentacije (arhitektura, zahtjevi, planovi), implementacija novih modula ili izmjena postojećih po zahtjevu 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. Također može biti zanimljiva metrika o vremenu izvršenja zadataka i mnogi drugi.
Zaključno, želimo napomenuti da će vam prisutnost potrebnih metričkih podataka i grafikona koji odražavaju promjenu stanja projekta tijekom vremena omogućiti da poboljšate ne samo proces testiranja, već i razvoj u cjelini, te će također olakšati postupak analize dovršenog projekta, koji će vam omogućiti da spriječite greške iz prošlosti.
| Video s uputama. Yandex.Metrica: poznanstvo Gledaj video |
Što se može pratiti pomoću metrike
Privlačenje posjetitelja
Izravna izvješća u Metrici jasno pokazuju koje kampanje, oglasi, fraze i upiti za pretraživanje dolaze na vašu stranicu, iz kojih regija i s kojih platformi za oglašavanje. Koristite ove informacije za optimizaciju svojih kampanja.
Na primjer, možete poboljšati svoje izraze dodavanjem ključnih riječi iz relevantnih upita za pretraživanje i negativnih ključnih riječi iz nerelevantnih upita - to će vam pomoći privući više zainteresiranih posjetitelja i povećati CTR.
Publika stranice
U Metrici možete dobiti detaljne karakteristike svoje publike. Spol, dob i interesi posjetitelja izračunavaju se analizom njihovog ponašanja na internetu korištenjem Crypt tehnologije. Na temelju tih podataka oglasi se mogu učiniti relevantnijima i time povećati njihova učinkovitost.
Postizanje ciljeva i konverzije
Važno je ne samo dovesti posjetitelje na svoju stranicu, već i razumjeti postaju li oni pravi kupci. Da biste to učinili, u Metrici morate postaviti ciljeve – odnosno odrediti ključne radnje koje posjetitelji web-mjesta moraju izvršiti.
Na primjer, vaš klijent može biti posjetitelj koji:
- kliknuli gumb "Dodaj u košaricu";
- išao od košarice do stranice "Hvala vam na kupnji" prilikom narudžbe;
- posjetili najmanje dvije stranice stranice;
- otišao na stranicu s podacima za kontakt;
- registrirani na stranici ili pretplaćeni na newsletter.
Prisutnost prilagođenih ciljeva omogućit će vam da shvatite koje fraze i oglase koriste korisnici da bi došli do stranice. Ne samo da možete analizirati rast ciljanih posjeta, već ih i optimizirati pomoću jedne od automatskih strategija: Prosječni trošak konverzije ili Tjedni proračun. Maksimalni broj konverzija.
Prihod
Vlasnici internetskih trgovina mogu dobiti detaljne informacije o narudžbama napravljenim na web stranici trgovine u metrici. Moći ćete saznati koliko novca je svaka narudžba donijela i iz kojih kanala dolaze najisplativije narudžbe.
Upravo u sučelju Metrica možete brzo procijeniti svoje troškove oglašavanja u Yandex.Directu. Na primjer, možete vidjeti ukupnu potrošnju na oglase, vidjeti prosječnu cijenu konverzija u svim svojim oglasnim kampanjama i procijeniti prosječnu ili ukupnu cijenu klikova za određene vrste uređaja, regije, pretraživanja ili web-lokacije.
Ciljani pozivi
Kupci naručuju ne samo na web stranici, već i putem telefona. Servis "Ciljani poziv" omogućuje vam usporedbu učinkovitosti različitih kanala promocije. Dobivate posebne telefonske brojeve koji se mogu povezati s različitim izvorima, s razinom detalja sve do pojedinačnih reklamnih kampanja. Broj na web stranici i u virtualnoj posjetnici automatski se mijenja ovisno o izvoru - na taj način možete pratiti gdje je svaki pozivatelj saznao za vas.
Kako početi prikupljati statistiku
Instalirajte kod brojača na sve stranice svoje stranice što bliže vrhu stranice - o tome ovisi potpunost prikupljenih podataka. Ispravnost postavke brojača možete provjeriti u konzoli preglednika.
Ako izradite mnogo kampanja s 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 pomoći će vam u prijenosu podataka između Directa i Metrica. Provjerite je li opcija omogućena u postavkama kampanje. Označite veze za Metrica, a vaša stranica ispravno otvara veze s oznakama.
Kako radi označavanje veze
Pažnja. Ako polje nije popunjeno u parametrima kampanje metrika brojača, a opcija je onemogućena Označite veze za Metrica, tada podaci o klikovima na oglase neće biti uključeni u Metrica, a podaci iz Metrica neće biti uključeni u statistiku Yandex.Directa.
Pitanja i odgovori
Koliko brzo se podaci osvježavaju u izvješćima Metrica?
Radnje posjetitelja na web-mjestu odražavaju se u većini Metrica izvješća za nekoliko minuta. Podaci za posebna izvješća o Directu prolaze dodatnu provjeru, pa u Metricu ulaze s kašnjenjem i do nekoliko sati.
Koliko brzo podaci o ostvarenju cilja dolaze u Yandex.Direct?
Podaci o postizanju određenog cilja dolaze u Yandex.Direct u roku od 24 sata.
Zašto se podaci u statistici Yandex.Directa i Metrica razlikuju?
Berg O.Yu.
METRIKE PROCJENE KVALITETE SOFTVERA
Kako obrada podataka sve više utječe na naše živote, računalne pogreške sada mogu imati posljedice kao što su imovinska šteta, kršenje tajnosti i mnoge druge, uključujući smrt. Pouzdanost softvera (softvera) je vjerojatnost njegovog rada bez kvarova u određenom vremenskom razdoblju, izračunata uzimajući u obzir trošak za korisnika svakog kvara. Stoga je potrebno moći mjeriti kvalitetu softvera tijekom cijelog razvojnog ciklusa. Kvalitetu softvera treba ocjenjivati na temelju kriterija kvalitete, koji bi trebali:
Numerički okarakterizirati glavnu ciljnu funkciju programa;
Omogućiti određivanje troškova potrebnih za postizanje tražene razine kvalitete, kao i stupnja utjecaja na pokazatelj kvalitete različitih vanjskih čimbenika;
Budite što jednostavniji, dobro mjerljivi i imajte nisku varijaciju.
Mjerni podaci se koriste za mjerenje kriterija izvedbe i kvalitete. Trenutno je poznat veliki broj metrika koji ocjenjuju pojedinačna proizvodna i operativna svojstva softvera. Međutim, težnja za njihovom univerzalnošću, zanemarujući opseg razvijenog softvera, faze životnog ciklusa značajno smanjuje učinkovitost njihovog korištenja.
metrika kvalitete programa je sustav za mjerenje kvalitete programa. Ta se mjerenja mogu provoditi na razini kriterija kvalitete programa ili na razini pojedinačnih karakteristika kvalitete. U prvom slučaju mjerni sustav omogućuje izravnu usporedbu programa u pogledu kvalitete. Istodobno, sama mjerenja ne mogu se provoditi bez subjektivnih procjena svojstava programa. U drugom slučaju, karakteristike se mogu mjeriti objektivno i pouzdano, ali će ocjena kvalitete softvera u cjelini biti povezana sa subjektivnom interpretacijom dobivenih ocjena.
U proučavanju softverske metrike postoje dva glavna područja:
Tražite metrike koje karakteriziraju najspecifičnija svojstva programa, t.j. metrike za ocjenjivanje samog softvera;
Korištenje metrike za procjenu tehničkih karakteristika i čimbenika razvoja softvera, t.j. metrike za ocjenjivanje uvjeta za razvoj programa.
Prema vrsti informacija dobivenih prilikom procjene kvalitete softvera, metrike se mogu podijeliti u tri skupine:
Mjerne vrijednosti koje ocjenjuju odstupanje od norme karakteristika materijala početnog dizajna. Oni utvrđuju potpunost navedenih specifikacija izvornog koda.
metrika za predviđanje kvalitete softvera koji se razvija. Daju se na setu
moguće opcije rješavanja problema i njihovu implementaciju te određuju kvalitetu softvera, koji
će se na kraju postići.
metrika po kojoj se donosi odluka o usklađenosti konačnog softvera s navedenim zahtjevima. Omogućuju vam procjenu usklađenosti razvoja s navedenim zahtjevima.
Trenutno se u svjetskoj praksi koristi nekoliko stotina programskih metrika. Postojeće evaluacije programa kvalitete mogu se grupirati u šest područja:
Procjene topološke i informacijske složenosti programa;
Procjene pouzdanosti softverskih sustava koji omogućuju predviđanje situacija kvara;
Procjena performansi softvera i poboljšanje njegove učinkovitosti identificiranjem pogrešaka u dizajnu;
Procjena razine jezičnih alata i njihova primjena;
Evaluacije težine percepcije i razumijevanja programskih tekstova, usredotočene na
psihološki čimbenici koji su bitni za održavanje i modificiranje programa;
Procjene produktivnosti programera za predviđanje vremena razvoja programa i planiranje rada na izradi softverskih sustava.
Ovisno o karakteristikama i značajkama korištene metrike, dodjeljuju im se različite mjerne skale:
Nominalna ljestvica odgovara metrici koja klasificira programe u tipove na temelju prisutnosti ili odsutnosti neke karakteristike bez obzira na gradacije;
Redna ljestvica odgovara metrikama koje omogućuju rangiranje nekih karakteristika usporedbom s referentnim vrijednostima, t.j. mjerenje na ovoj ljestvici zapravo određuje relativni položaj pojedinih programa;
Intervalna skala odgovara metrikama koje pokazuju ne samo relativni položaj programa, već i koliko su udaljeni jedan od drugog;
Relativna ljestvica odgovara metrikama koje omogućuju 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 skupa nesavršenost neznanstvenog predviđanja rješivosti i troškova rada, složenost programa, nefleksibilnost kontrole i upravljanja njihovim razvojem i još mnogo toga, što ukazuje na nedostatak kraja. -dovršetak metodološke podrške i u konačnici dovodi do njezina neusklađenosti sa zahtjevima korisnika, traženog standarda i naknadne bolne i mukotrpne izmjene istih. Ove okolnosti zahtijevaju pažljiv odabir tehnika, modela, metoda za procjenu kvalitete softvera, uzimajući u obzir ograničenja njihove prikladnosti za različite životne cikluse, utvrđivanje redoslijeda njihove zajedničke uporabe, korištenjem suvišnih studija različitih modela istih pokazatelja. povećati pouzdanost trenutnih procjena, akumulaciju i integraciju heterogenih metričkih informacija za donošenje pravovremenih odluka o proizvodnji i certificiranje konačnog proizvoda.
Zaključno, valja napomenuti da se pri odabiru metrike za procjenu kvalitete softvera potrebno voditi sljedećim pravilima:
metrika bi trebala imati smisla i za kupca i za izvođača;
metrika mora biti objektivna i njena definicija je nedvosmislena;
metrika bi trebala omogućiti praćenje trenda promjena;
metrika se može automatizirati.
Temeljito provedena metrička analiza kvalitete u skladu s razvojnim ciljevima stvara osnovu za ispravno planiranje i kontrolu troškova kvalitete kako bi se postigli potrebni pokazatelji i učinkovitost u korištenju resursa.
KNJIŽEVNOST
1. Liu K., Zhou S. Yang H., metrika kvalitete objektno orijentiranog dizajna za razvoj i ponovni razvoj softvera, - Proceedings of the First Asia-Pacific Conference on Quality Software, 2000 IEEE
2. Boehm B. W., Brown J. R., Lipow M. KVANTITATIVNA OCJENA KVALITETE SOFTVERA Zbornik radova 2. međunarodne konferencije o softverskom inženjerstvu o međunarodnoj konferenciji o softverskom inženjerstvu listopada 1976.
3. Houdek F., Kempter H. Obrasci kvalitete – pristup pakiranju iskustva softverskog inženjerstva ACM SIGSOFT Software Engineering Notes, Proceedings of 1997 sympozium on Symposium on software reusability, svibanj 1997.
4. W. Royce Software Project Management, Moskva, LORI
Aleksej Černikov
1. Uvod
Za razliku od većine grana materijalne proizvodnje, u pitanjima projekata razvoja softvera neprihvatljivi su jednostavni pristupi koji se temelje na množenju intenziteta rada s prosječnom produktivnošću rada. To je prvenstveno zbog činjenice da ekonomski pokazatelji projekta nelinearno ovise o količini posla, a pri izračunu složenosti dopuštena je velika pogreška.
Stoga se za rješavanje ovog problema koriste složene i prilično složene tehnike koje zahtijevaju veliku odgovornost u primjeni i određeno vrijeme za prilagodbu (postavljanje koeficijenata).
Suvremeni integrirani sustavi za procjenu karakteristika projekata razvoja softvera mogu se koristiti za rješavanje sljedećih zadataka:
- preliminarna, trajna i konačna procjena ekonomskih parametara projekta: intenzitet rada, trajanje, trošak;
- procjena rizika za projekt: rizik od poštivanja rokova i nedovršetka projekta, rizik povećanja intenziteta rada u fazama otklanjanja pogrešaka i podrške projektu itd.;
- donošenje operativnih upravljačkih odluka - na temelju praćenja određenih projektnih metrika moguće je pravovremeno spriječiti pojavu nepoželjnih situacija i otkloniti posljedice nepromišljenih projektantskih odluka.
1. Uvod
2 metrika
2.1 Mjerni podaci temeljeni na dimenziji (indikatori procjene volumena)
2.1.1 LOC evaluacija (linije koda)
2.1.1.1 metrika stila i razumljivosti programa
2.1.2 SLOC Ukupno
2.2 Mjerila složenosti
2.2.2 Halstead metrika
2.2.4 Čepin metrika
2.4 Opći popis metrike
2.4 Sažetak
6 Internet resursi
2. metrika
Uobičajeno je podijeliti metriku složenosti softvera u tri glavne skupine:
- metrika veličine programa;
- metrika složenosti tijeka kontrole programa;
- metrika složenosti toka podataka programa.
metrike u prvoj skupini temelje se na kvantificiranju veličine programa i relativno su jednostavne. Najpoznatije metrike ove grupe uključuju broj programskih izraza, broj redaka izvornog teksta i skup Halsteadovih metrika. metrike u ovoj skupini usmjerene su na analizu izvornog koda programa. Stoga se mogu koristiti za procjenu složenosti razvojnih međuprodukta.
Metrike druge skupine temelje se na analizi kontrolnog grafa programa. Predstavnik ove skupine je McCabeova metrika.
Kontrolni graf programa, koji koristi metrika ove grupe, može se izgraditi na temelju modulskih algoritama. Stoga se metrika druge skupine može koristiti za procjenu složenosti razvojnih međuproizvoda.
metrike treće skupine temelje se na procjeni korištenja, konfiguracije i smještaja podataka u programu. To se prvenstveno odnosi na globalne varijable. Ova skupina uključuje Chepinovu metriku.
2.1 Mjerni podaci temeljeni na dimenziji (procjene obujma)
2.1.1 LOC evaluacija (linije koda)
Dimenzionalne metrike izravno mjere softverski proizvod i njegov razvojni proces. Takve se metrike temelje na LOC rezultatima.
Ova vrsta metrike neizravno mjeri softverski proizvod i njegov razvojni proces. Umjesto izračunavanja LOC rezultata, ne gleda se na veličinu, već na funkcionalnost ili korisnost proizvoda.
Dimenzijsko orijentirana metrika najčešće se koristi u razvoju softvera. U organizacijama koje se bave razvojem softverskih proizvoda za svaki projekt, uobičajeno je registrirati sljedeće pokazatelje:
- ukupni troškovi rada (u čovjek-mjesecima, čovjek-sati);
- veličina programa (u tisućama redaka izvornog koda -LOC);
- trošak razvoja;
- volumen dokumentacije;
- greške otkrivene tijekom godine rada;
- broj ljudi koji su radili na proizvodu;
- razvojno razdoblje.
Na temelju ovih podataka obično se izračunavaju jednostavne metrike za procjenu produktivnosti rada (KLOC / čovjek-mjesec) i kvalitete proizvoda.
Ove metrike nisu univerzalne i kontroverzne, posebno za takav pokazatelj kao što je LOC, koji značajno ovisi o korištenom programskom jeziku.
Linije koda (LOC, Source Lines of Code - SLOC) su najjednostavniji i najčešći način procjene opsega projekta.
U početku je ovaj pokazatelj nastao kao način za procjenu količine posla na projektu, u kojem su korišteni programski jezici koji su imali prilično jednostavnu strukturu: "jedan redak koda = jedna jezična naredba". Također je odavno poznato da se ista funkcionalnost može napisati s različitim brojem redaka, a ako uzmemo jezik visoke razine (C++, Java), onda je moguće napisati 5-6 redaka funkcionalnosti u jednom redu - to nije problem. A to bi bilo pola problema: moderni programski alati sami generiraju tisuće redaka koda za trivijalnu operaciju.
Stoga je LOC metoda samo metoda procjene (koju treba uzeti u obzir, ali ne temeljiti se na procjenama) i ni na koji način nije obvezna.
Ovisno o tome kako se sličan kod uzima u obzir, postoje dva glavna SLOC indikatora:
- broj "fizičkih" redaka koda - SLOC (korištene kratice LOC, SLOC, KLOC, KSLOC, DSLOC) - definira se kao ukupan broj redaka izvornog koda, uključujući komentare i prazne redove (prilikom mjerenja indikatora na broj praznih redaka, u pravilu se uvodi ograničenje - brojenje uzima u obzir broj praznih redaka, koji ne prelazi 25% ukupnog broja redaka u izmjerenom kodnom bloku).
- Broj "logičkih" linija koda - SLOC (koriste se kratice LSI, DSI, KDSI, gdje "SI" - izvorne upute) - definiran je kao broj naredbi i ovisi o korištenom programskom jeziku. Ako jezik ne dopušta postavljanje nekoliko naredbi u jedan redak, tada će broj "logičkih" SLOC-ova odgovarati broju "fizičkih", osim broja praznih redaka i redaka komentara. U slučaju da programski jezik podržava postavljanje nekoliko naredbi u jedan redak, tada jedan fizički redak treba smatrati nekoliko logičkih redaka ako sadrži više od jedne jezične naredbe.
Za SLOC metriku postoji veliki broj izvedenica dizajniranih za dobivanje pojedinačnih pokazatelja projekta, od kojih su glavni:
- broj praznih redaka;
- broj redaka koji sadrže komentare;
- postotak komentara (omjer redaka koda i redaka komentara, izvedena metrika stila);
- prosječan broj redaka za funkcije (klase, datoteke);
- prosječan broj redaka koji sadrže izvorni kod za funkcije (klase, datoteke);
- prosječan broj redaka za module.
2.1.1.1 metrika stila i razumljivosti programa
Ponekad je važno ne samo prebrojati broj redaka komentara u kodu i jednostavno ih povezati s logičkim redovima koda, već i saznati gustoću komentara. Odnosno, kod je prvo dobro dokumentiran, 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)
Bit metrike je jednostavna: kod se dijeli na n jednakih dijelova i Fi se određuje za svaki od njih.
2.1.2 SLOC Ukupno
Potencijalni nedostaci SLOC-a na meti kritika:
- ružno je i netočno ocjenu rada osobe svesti na nekoliko brojčanih parametara i po njima suditi o uspješnosti. Menadžer može dodijeliti najtalentiranije programere u najteža područja rada; to znači da će razvoj ovog odjeljka trajati najduže i da će generirati najviše pogrešaka, zbog složenosti zadatka. Nesvjestan ovih poteškoća, drugi menadžer izvedbe mogao bi odlučiti da je programer loše obavio posao.
- Mjerilo ne uzima u obzir iskustvo zaposlenika i njihove druge kvalitete
- Izobličenje: Proces mjerenja može biti izobličen činjenicom da su zaposlenici svjesni mjernih podataka koji se mjere i nastoje optimizirati te metrike, a ne vlastitu izvedbu. Na primjer, ako je broj redaka izvornog koda važan pokazatelj, programeri će nastojati napisati što više redaka i neće koristiti tehnike pojednostavljivanja koda koje smanjuju broj redaka (vidi bočnu traku o Indiji).
- Netočnost: ne postoje metrika koja je dovoljno značajna i točna. Broj redaka koda je jednostavno broj redaka; ovaj pokazatelj ne daje ideju o složenosti problema koji se rješava. Analiza točaka funkcije osmišljena je za bolje mjerenje složenosti koda i specifikacije, ali koristi osobnu prosudbu mjeritelja, tako da će različiti ljudi dobiti različite rezultate.
I glavna stvar koju treba zapamtiti: SLOC metrika ne odražava složenost izrade programa
.
| Primjer iz stvarnog života
: U jednoj od tvrtki, tijekom implementacije, primijenili smo ovu metriku – brojali smo redove koda. Voditelj organizacije bio je na godišnjem odmoru, no po povratku s njega odlučio je iskoristiti transparentnost i sljedivost promjena i vidjeti kako njegovi menadžeri stoje na projektima. A da bih u potpunosti ušao u tečaj, spustio sam se na najnižu razinu (odnosno, nisam procijenio gustoću nedostataka, broj ispravljenih grešaka) - na razinu izvornih tekstova. Odlučio sam prebrojati tko je koliko redaka napisao. I da bude potpuno zabavno – povežite broj radnih dana u tjednu i količinu napisanog koda (logika je jednostavna: čovjek je radio 40 sati tjedno, što znači da mora puno pisati). Naravno, postojala je osoba koja je napisala samo jedan redak u tjednu, nije ni napisala, već je samo ispravila postojeći... Ljutnji vođe nije bilo granica – našao je ljenčare! I bilo bi loše za programera da voditelj projekta nije objasnio to: pronađena je greška u programu, pronašao ju je VIP klijent, greška utječe na poslovanje klijenta i to je trebalo hitno otkloniti, za to upravo ovaj izvršitelj je odabran, koji je postavio štand, preplavio klijentovo okruženje, potvrdio grešku i počeo je tražiti i popravljati. Naravno, na kraju je promijenio dio koda u kojem je uvjet bio netočan i sve je funkcioniralo. |
Slažem se, glupo je izračunavati troškove rada prema ovoj metrici - potrebna je sveobuhvatna procjena ...
2.2 Mjerila složenosti
Osim pokazatelja za ocjenu obima posla na projektu, za dobivanje objektivnih ocjena projekta vrlo su važni pokazatelji za ocjenu njegove složenosti. Ti se pokazatelji u pravilu ne mogu izračunati u najranijim fazama rada na projektu, jer zahtijevaju barem detaljan dizajn. Međutim, ovi pokazatelji su vrlo važni za dobivanje prediktivnih procjena trajanja i cijene projekta, jer izravno određuju njegov radni intenzitet.
2.2.1 Objektno orijentirana metrika
U suvremenim uvjetima većina softverskih projekata stvara se na temelju OO pristupa, pa stoga postoji značajan broj metrika koje vam omogućuju procjenu složenosti objektno orijentiranih projekata.
|
Metrika |
Opis |
| Ponderirane metode po razredu (WMC) | Odražava relativnu složenost klase temeljenu na ciklomatskoj složenosti svake od njezinih metoda. Klasa sa složenijim metodama i više metoda smatra se složenijom. Prilikom izračunavanja metrike roditeljske klase se ne uzimaju u obzir. |
| Ponderirane metode po klasi (WMC2) |
Mjera složenosti klase koja se temelji na činjenici da je klasa s više metoda složenija i da je metoda s više parametara također složenija. Prilikom izračunavanja metrike roditeljske klase se ne uzimaju u obzir. |
| Dubina stabla nasljeđivanja | Duljina 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 za ponovnu upotrebu zadanog modula ponašanja definiranog za klase pretka. |
| Broj djece | Broj modula koji izravno nasljeđuju određeni modul. Velike vrijednosti ove metrike ukazuju na široku mogućnost ponovne upotrebe; međutim, previsoka vrijednost može ukazivati na loše odabranu apstrakciju. |
|
Spajanje između objekata |
Broj modula povezanih s ovim modulom kao kupcem ili dobavljačem. Prekomjerna kohezija ukazuje na slabost u modularnoj enkapsulaciji i može spriječiti ponovnu upotrebu koda. |
| Odgovor za razred | Broj metoda koje mogu pozvati instance klase; izračunato kao zbroj broja lokalnih metoda i broja udaljenih metoda |
2.2.2 Halstead metrika
Halsteadova metrika odnosi se na metriku izračunatu na temelju analize broja redaka i sintaktičkih elemenata izvornog koda programa.
Osnovu Halsteadove metrike čine četiri mjerljive karakteristike programa:
- NUOprtr (Broj jedinstvenih operatora) - broj jedinstvenih programskih operatora, uključujući znakove za razdvajanje, nazive procedura i znakove operacija (rječnik operatora);
- NUOprnd (Broj jedinstvenih operanda) - broj jedinstvenih programskih operanda (rječnik operanda);
- Noprtr (Broj operatera) - ukupan broj operatera u programu;
- Noprnd (Broj operanda) - ukupan broj operanada u programu.
Na temelju ovih karakteristika izračunavaju se procjene:
- Programski rječnik
(Halstead programski rječnik, HPVoc): HPVoc = NUOprtr + NUOprnd; - Duljina programa
(Duljina programa Halstead, HPLen): HPLen = Noprtr + Noprnd; - Opseg programa
(Halstead Program Volume, HPVol): HPVol = HPLen log2 HPVoc; - Složenost programa
(Halstead Difficulty, HDiff): HDiff = (NUOprtr / 2) × (NOprnd / NUOprnd); - Na temelju indikatora HDiff, predlaže se evaluacija razvojnih napora programera pomoću indikatora HEff (Halstead Effort): HEff = HDiff × HPVol.
2.2.3 metrika McCabeove ciklomatske složenosti
Pokazatelj ciklomatske složenosti jedan je od najčešćih pokazatelja za procjenu složenosti softverskih projekata. Ovaj indikator razvio je znanstvenik McCabe 1976. godine, pripada skupini indikatora za procjenu složenosti tijeka kontrole programa i izračunava se na temelju grafa kontrolnog tijeka. Ovaj graf je konstruiran u obliku usmjerenog grafa, u kojem su računski operatori ili izrazi predstavljeni kao čvorovi, a prijenos upravljanja između čvorova predstavljen je kao lukovi.
Pokazatelj ciklomatske složenosti omogućuje ne samo procjenu radnog intenziteta implementacije pojedinih elemenata softverskog projekta i prilagođavanje općih pokazatelja za procjenu trajanja i cijene projekta, već i procjenu povezanih rizika i donošenje potrebnih upravljačkih odluka.
Pojednostavljena formula za izračun ciklomatske složenosti je sljedeća:
C = e - n + 2,
gdje e - broj rebara , i n - broj čvorova
na grafu toka kontrole.
U pravilu se pri izračunavanju ciklomatske složenosti ne uzimaju u obzir logički operatori.
U procesu automatiziranog izračuna pokazatelja ciklomatske složenosti, u pravilu se koristi pojednostavljeni pristup prema kojem se graf ne gradi, već se pokazatelj izračunava na temelju brojanja broja upravljačkih logičkih operatora (ako, prekidač itd.) i mogući broj putova izvršavanja programa.
McCabeov ciklomatski broj označava broj prolaza potrebnih za pokrivanje svih kontura usko povezanog grafa ili broj probnih pokretanja programa potrebnih za iscrpno testiranje na osnovi "svaka grana radi".
Indeks 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.
- "Modificirana" ciklomatska složenost - ne razmatra svaku granu operatora višestrukog izbora (switch), već cijeli operator u cjelini.
- "Stroga" ciklomatska složenost - uključuje logičke operatore.
- "Pojednostavljeno" izračunavanje ciklomatske složenosti - predviđa izračun ne na temelju grafa, već na temelju izračuna upravljačkih operatora.
2.2.4 Čepin metrika
Postoji nekoliko njegovih modifikacija. Razmotrimo jednostavniju, a sa stajališta praktične upotrebe - prilično učinkovitu verziju ove metrike.
Bit metode je procijeniti informacijsku snagu jednog softverskog modula analizom korištenja varijabli s I/O liste.
Cijeli skup varijabli koje čine I/O popis podijeljen je u četiri funkcionalne skupine.
Q = a1P + a2M + a3C + a4T, gdje su a1, a2, a3, a4 težinski koeficijenti.
Q = P + 2M + 3C + 0,5T.
2.3 Preliminarna procjena na temelju statističkih metoda ovisno o fazama razvoja programa
Koristeći integrirane alate, tvrtke koje razvijaju standardna rješenja (u ovu kategoriju spadaju tzv. “inhousers” - tvrtke koje opslužuju glavni posao) postaje moguće predvidjeti složenost programa na temelju prikupljenih statistika. Statistička metoda je vrlo prikladna za rješavanje takvih tipičnih problema i praktički nije prikladna za predviđanje jedinstvenih projekata. U slučaju jedinstvenih projekata koriste se drugi pristupi, čija je rasprava izvan dosega ovog materijala.
Tipični zadaci spadaju u obilje odjela za razvoj poslovanja, stoga bi preliminarna procjena složenosti mogla uvelike pojednostaviti zadatke planiranja i upravljanja, pogotovo jer postoji akumulirana projektna baza u kojoj ne samo konačni rezultati, već i svi početni i međurezultati. su spašeni.
Istaknimo tipične faze u razvoju programa:
- izrada specifikacije zahtjeva za program;
- definicija arhitekture;
- izrada modularne strukture programa, razvoj sučelja između modula. Razvoj algoritama;
- razvoj i testiranje koda.
Pokušajmo sada razmotriti brojne metrike koje se često koriste za preliminarnu procjenu u prve dvije faze.
2.3.1 Preliminarna procjena složenosti programa u fazi izrade specifikacije zahtjeva za program
Za procjenu rezultata rada ove faze može se koristiti metrika predviđenog broja programskih operatora Nprogn:
Nprog = NF * Ned
Gdje je: NF - broj funkcija ili zahtjeva u specifikaciji zahtjeva za razvijeni program;
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 tijekom faze definiranja arhitekture
Si = NI / (NF * NIed * Kl)
Gdje:
NI je ukupan broj varijabli prenesenih kroz sučelja između programskih komponenti (također je statistički);
NIed — pojedinačna vrijednost broja varijabli koje se prenose putem sučelja između komponenti (prosječan broj varijabli prenesenih preko sučelja po jednoj prosječnoj funkciji ili zahtjevu);
Ksl je koeficijent složenosti programa koji se razvija, uzima u obzir rast složenosti jedinice programa (složenost po funkciji ili zahtjev za specificiranjem zahtjeva za program) za velike i složene programe u usporedbi s prosjekom P.S.
2.4 Opći popis metrike
Tablica 1 sadrži kratak opis metrika koje nisu bile uključene u detaljan opis iznad, no unatoč tome, te su metrike potrebne i važne, samo su statistički mnogo rjeđe.
Također imajte na umu da je svrha ovog članka pokazati princip, a ne opisati sve moguće metrike u mnogim kombinacijama.
Pozdrav prijatelji. Nakon duge faze razvoja i još duljeg beta testiranja, novi Yandex Metric 2.0 izlazi iz sjene. Od 22. lipnja postat će glavni alat za prikupljanje i analizu statistike, dok će stara verzija biti prebačena na poddomenu 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, da naučim njegove mogućnosti. Ali isplati se – barem sam za sebe pronašao nekoliko stvari koje ne mogu učiniti ni trenutna verzija ni Analytics.
Zapravo, u ovom materijalu pokušat ću vam rastaviti radni proces, sastaviti upute o web analitici u novoj Yandex metrici, budući da je nešto drugačija od svog prethodnika i može izazvati kognitivnu disonancu pri prvom sastanku.
- Dakle, pogledajte beta metriku.
"Ne želim, bojim se nje."
Razgovor s poznatim SEO stručnjakom.
Dakle, prvo idejni dio. Koja je glavna razlika? Stari Metric je uglavnom skup gotovih rezova (izvješća) za analizu. Njihovo postavljanje i stvaranje vlastitih kriški je teško i nezgodno. Zbog toga se za mnoge ovaj proces sastoji samo od rada s "Ciljevima" koji su, na dobar način, namijenjeni nečemu sasvim drugom, a "Izvješća" ostaju negdje vani, na prašnjavoj polici, izvan zagrada. .
Trenutni je već punopravni plastelin, koji vam omogućuje da apsolutno bilo koju krišku prilagodite svojim potrebama, postavite početne podatke, filtrirate nepotrebne i odaberete prikladnu opciju za predstavljanje podataka. U potpunosti i potpuno prilagodite radni prostor, što posebno cijene internetski trgovci.
A sada, redom
Trenutačno se beta još uvijek nalazi na https://beta.metrika.yandex.ru/ i pogled na popis stranica nije doživio dramatične promjene, s izuzetkom nekoliko dodataka i prikazanog postotka rasta prometa u odnosu na zadnji dan, koji je sada tako pažljivo uklonjen iz stare verzije (kažu, idemo, navikni se).
Novi sustav naljepnica i traka za brzi pristup vrlo je prikladan. Omogućuje vam stvaranje nekoliko oznaka na ploči definicije oznaka i dodjeljivanje jedne ili više oznaka svakoj stranici (zapravo, uključivanjem u grupe ovih oznaka). Zatim, odabirom istoimene opcije na ploči s definicijom oznake, na ploči za brzi pristup prikažite grupe na koje se najčešće pozivate. Osim toga, prilikom pregleda jedne od grupa, prikazat će se zbirna statistika prometa na stranicama uključenim u nju.
Ali prijeđite na zaseban šalter, već se možete početi gubiti. Pogledajmo sučelje.
Yandex metric novi izbornik sučelja
Stavke gornjeg izbornika ne trebaju prezentaciju, a struktura i neke stavke lijevog izbornika trebaju. Prije svega, ono što znamo:
- Sažetak - Glavna stranica brojača stranice.
- Karte - karte klikova, pomicanja, linkova i analitika obrazaca. Općenito, većina sadržaja stavke Ponašanje je stara.
- Postavka - zapravo, postavke trenutnog brojača Yandex Metrica.
I ovdje je posljednja stavka - "Izvješća" - kamen temeljac ažuriranog alata.
- Moja izvješća su svi dijelovi koje kreirate i spremate.
- Odabrani su isti, samo odabrani (buđenje, Neo).
- Standardni izvještaji - tu su se smjestili svi stari i bolno poznati dijelovi. Na njih ćemo se vratiti dalje u materijalu.
Sučelje glavne stranice brojača
Konstruktor početne stranice sličan je onom u staroj Yandex Metrici, ali je, za razliku od potonjeg, ergonomičniji i ima impresivan skup gotovih widgeta. Pa, ovdje se također osjeti fleksibilnost postavki segmenta svojstvena novoj verziji.
Možete odabrati gotov widget iz biblioteke ili stvoriti novi: mjera, tortni grafikon, grafikon ili tablica podataka. Prilagodite dio informacija prikazanih u njima i popravite sažetak u željenom dijelu zaslona jednostavnim lijekom & drop.
Rad sa segmentima u Yandex metrici
Dakle, došli smo do glavne stvari - opisa sheme izvješćivanja. Prije svega idemo na prethodno spomenuta standardna izvješća ("Izvješća" - "Standardno izvješće") i odabiremo informacije koje ćemo potom segmentirati. Na primjer "Izvori" - "Izvori, sažetak".
A sada počinjemo birati samo one posjete koje želimo analizirati. Na primjer, želimo saznati broj ljudi koji su posjetili stranicu s tableta iz tražilice Yandex na upit koji sadrži riječ "SEO". Da bismo to učinili, postavili smo tri razine segmentacije:
- "Segment" - "Tehnologije" - "Uređaji" - u prozoru s opcijama koji se otvori odaberite "Tableti".
- "Segment" - "Izvori" - "Zadnji izvor" - "Traži" - "Tražilica" - u prozoru s opcijama koji se otvori odaberite "Yandex".
- "Segment" - "Izvori" - "Zadnji izvor" - "Traži" - "Izraz za pretraživanje" - u prozoru koji se otvori upišite * SEO * (operatori zvjezdice označavaju bilo koji skup znakova s obje strane ove riječi).
Ukupno: grafikoni i tablica s informacijama bit će prepravljeni na način koji nam je potreban, spremni za istovar ili analizu. U hodu možete promijeniti, ukloniti ili dodati nove razine preciziranja - prikazane informacije će se ažurirati u hodu.
Ovdje možemo usporediti rezultirajući segment s drugim, koristeći alat "Usporedi segmente" - "Postavi ručno". Međutim, ne možemo mijenjati sastav segmenta, već jednostavno usporediti nekoliko razdoblja jednog odsječka kroz opciju "Prethodno razdoblje".
Ni ovdje nisu zaboravljeni dobri stari "Ciljevi" koje možemo koristiti kao još jedan parametar za zadavanje građenja segmenta.
Broj mogućnosti za izradu segmenata praktički je neograničen. Zatim možemo analizirati primljene informacije i zaboraviti na odabir, ili ih spremiti i pristupiti im u budućnosti iz izbornika "Izvješća" - "Moja izvješća" ili jednostavno učitati podatke.
Yandex metrički webvisor
Gore opisani proces segmentacije bio je vrlo zgodan za ovaj alat. Filtriranje zapisa o posjetima interesnim grupama korisnika upravo je postalo lakše. Redoslijed je isti - idite na "Webvisor", postavite segment (ili ga učitajte iz spremljenih), pogledajte.
Ovim je završena ova uputa za pregled, a kao i obično čekam vaša pitanja u komentarima.
