Domov › Telefon › Programový kód a jeho metriky. Nejdůležitější metriky QA

Programový kód a jeho metriky. Nejdůležitější metriky QA

Berg O.Yu.

METRIKY PRO HODNOCENÍ KVALITY SOFTWARU

Vzhledem k tomu, že zpracování dat stále více ovlivňuje naše životy, mohou mít počítačové chyby nyní důsledky, jako je poškození majetku, porušení soukromí a mnoho dalších, včetně smrti. Spolehlivost softwaru je pravděpodobnost jeho provozu bez poruch po určitou dobu, vypočítaná s přihlédnutím k nákladům pro uživatele na každou poruchu. Proto je nutné mít možnost měřit kvalitu softwaru v průběhu celého vývojového cyklu. Je vhodné hodnotit kvalitu softwaru na základě kvalitativních kritérií, která by měla:

Číselně charakterizujte hlavní účelovou funkci programu;

Poskytovat schopnost určit náklady potřebné k dosažení požadované úrovně kvality a také míru vlivu různých vnějších faktorů na ukazatel kvality;

Být co nejjednodušší, dobře měřitelný a mít nízký rozptyl.

Metriky se používají k měření charakteristik a kritérií kvality. V současné době je známo velké množství metrik, které hodnotí jednotlivé produkční a provozní vlastnosti softwaru. Snaha o jejich všestrannost, ignorování rozsahu vyvíjeného softwaru a fází životního cyklu však výrazně snižuje efektivitu jejich použití.

Metrika kvality programu je systém pro měření kvality programu. Tato měření lze provádět na úrovni kritérií kvality programu nebo na úrovni jednotlivých znaků kvality. V prvním případě systém měření umožňuje přímé srovnání programů z hlediska kvality. Navíc samotná měření nelze provádět bez subjektivního posouzení vlastností programů. Ve druhém případě lze charakteristiky měřit objektivně a spolehlivě, ale posouzení kvality softwaru jako celku bude spojeno se subjektivní interpretací výsledných hodnocení.

Při studiu softwarových metrik existují dva hlavní směry:

Hledejte metriky, které charakterizují nejkonkrétnější vlastnosti programů, tzn. metriky pro hodnocení samotného softwaru;

Použití metrik k hodnocení technického výkonu a faktorů vývoje softwaru, např. metriky pro hodnocení podmínek vývoje programu.

Na základě typu informací získaných při posuzování kvality softwaru lze metriky rozdělit do tří skupin:

Metriky, které hodnotí odchylky od normy v charakteristikách výchozích konstrukčních materiálů. Stanovují úplnost specifikovaných technických charakteristik zdrojového kódu.

Metriky, které umožňují předpovídat kvalitu vyvíjeného softwaru. Jsou definovány na sadě

možné možnosti řešení problému a jejich implementaci a určit kvalitu softwaru, který

bude nakonec dosaženo.

Metriky, podle kterých se rozhoduje o tom, zda finální software splňuje zadané požadavky. Umožňují vám vyhodnotit shodu vývoje se stanovenými požadavky.

V současné době se ve světové praxi používá několik stovek programových metrik. Stávající kvalitativní hodnocení programů lze seskupit do šesti oblastí:

Odhady topologické a informační složitosti programů;

Hodnocení spolehlivosti softwarových systémů, umožňující předvídat poruchové situace;

Posouzení výkonu softwaru a zlepšení jeho účinnosti identifikací chyb v návrhu;

Posouzení úrovně jazykových prostředků a jejich aplikace;

Posouzení obtížnosti vnímání a porozumění programovým textům, zaměřené na

psychologické faktory nezbytné pro udržení a úpravu programů;

Odhadování produktivity programátorů pro předpovídání načasování vývoje programu a plánování prací na tvorbě softwarových systémů.

V závislosti na charakteristikách a vlastnostech použitých metrik jsou spojeny s různými měřítky:

Nominální škála odpovídá metrikám, které klasifikují programy do typů na základě přítomnosti nebo nepřítomnosti nějaké charakteristiky bez zohlednění gradací;

Pořadová stupnice odpovídá metrikám, které umožňují seřadit určité charakteristiky porovnáním s referenčními hodnotami, tzn. měření na této stupnici vlastně určuje relativní polohu konkrétních programů;

Intervalová škála odpovídá metrikám, které ukazují nejen relativní polohu programů, ale také to, jak daleko jsou od sebe;

Relativní měřítko odpovídá metrikám, které umožňují nejen určitým způsobem uspořádat programy a vyhodnotit jejich vzájemnou polohu, ale také určit, jak daleko jsou odhady od hranice, od které lze charakteristiku měřit.

Analýza technologických zkušeností lídrů softwarové výroby ukazuje, jak drahá je nedokonalost nevědecké prognózy řešitelnosti a mzdových nákladů, složitost programů, nepružnost kontroly a řízení jejich vývoje a mnohé další, což naznačuje nedostatek komplexní metodické podpory a v konečném důsledku vedoucí k jejímu nerespektování požadavků uživatele a požadovaného standardu a následnému bolestivému a časově náročnému přepracování. Tyto okolnosti vyžadují pečlivý výběr technik, modelů, metod pro hodnocení kvality softwaru, s přihlédnutím k omezením jejich vhodnosti pro různé životní cykly, stanovení pořadí jejich společného používání, použití redundantního heterogenního výzkumu stejných ukazatelů pro zvýšení spolehlivost aktuálních hodnocení, shromažďování a integrace heterogenních metrických informací pro přijímání včasných rozhodnutí o výrobě a certifikaci konečného produktu.

Na závěr je třeba poznamenat, že při výběru metrik pro hodnocení kvality softwaru se musíte řídit následujícími pravidly:

metrika musí dávat smysl jak pro zákazníka, tak pro interpreta;

metrika musí být objektivní a její definice jednoznačná;

metrika by měla umožňovat sledování trendu změn;

metriku lze automatizovat.

Pečlivě provedená metrická analýza kvality v souladu s vývojovými cíli vytváří základ pro správné plánování a řízení nákladů na kvalitu pro dosažení požadovaného výkonu a efektivity zdrojů.

LITERATURA

1. Liu K., Zhou S. Yang H., Metriky kvality objektově orientovaného designu pro vývoj a re-vývoj softwaru, - sborník z první asijsko-pacifické konference o kvalitním softwaru, 2000 IEEE

2. Boehm B. W., Brown J. R., Lipow M. KVANTITATIVNÍ HODNOCENÍ KVALITY SOFTWARE Sborník příspěvků z 2. mezinárodní konference softwarového inženýrství na Mezinárodní konferenci o softwarovém inženýrství říjen 1976

3. Houdek F., Kempter H. Kvalitní vzory – přístup ke zkušenostem z oblasti softwarového inženýrství ACM SIGSOFT Software Engineering Notes, sborník ze sympozia z roku 1997 na Symposiu o opětovné použitelnosti softwaru, květen 1997

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

Přístup metrik byl původně vyvinut výhradně pro účely projektového řízení a pro dosažení souladu se smlouvou. Jakmile bylo cílů dosaženo, staly se praktickou případovou studií. Výkon projektu CCPDS-R nebyl nikdy ani zdaleka optimální; Během procesu provádění se neustále dělalo velké množství chyb. Podobné tvrzení platí pro program pro určování metrik: někdy změřil špatnou věc, někdy změřil špatnou věc. Neusnadňovala včasnou interpretaci a používala manuální metody tam, kde byla potřeba automatizace. Práce s metrikami však vedla ke zlepšení týmové spolupráce, zlepšení procesů, lepšímu pochopení rizik a samozřejmě k efektivnějšímu produktu. V raných fázích projektu existoval odpor ze strany vedení, praktických vývojářů a dokonce i monitorů pokroku.

smlouva. Po prvním roce a po několika vylepšeních v interpretaci, automatizaci, prezentaci a definici byla téměř jednomyslná podpora. Všechny strany používaly objektivní data z programu metrik k informování o svých plánech, rizicích, směrech rozvoje a výsledcích.

Všechny prezentované metriky General Purpose Subsystem byly extrahovány přímo z měsíčních kontrol projektového řízení. Žádná z těchto hodnot nebyla vytvořena dodatečně. Přestože program na definování metrik byl smluvním požadavkem, vláda nespecifikovala, které metriky by se měly používat. To bylo ponecháno na uvážení dodavatele, aby projektový tým převzal vlastnictví zvoleného programu metrik.

TRW formuloval čtyři programové cíle pro definování metrik:.

Poskytování dat pro vyhodnocení aktuálních trendů výkonnosti projektu a určení, na co si dát při řízení projektu pozor.

Poskytování dat pro plánování následných etap a vytváření dalších subsystémů.

Poskytování údajů pro posouzení relativní obtížnosti dosažení konečných požadavků na kvalitu.

Poskytněte data, abyste určili, jaká vylepšení procesu jsou nutná, a zdůvodněte jejich potřebu.

Následují konkrétní příklady metrik doporučených v kapitole 13. Je uvedeno několik příkladů metrik pro měření pokroku, stejně jako metriky kvality pro vady, přepracování a dokončení. Popisuje základy potřebné pro automatizaci; vyžadují některé zajímavé technické přístupy, které jsou obsaženy přímo v produktech návrhu a kódování.

D.7.1 Pokrok ve vývoji.

Přesné měření pokroku ve vývoji s více souběžnými aktivitami v různých fázích bylo výzvou pro tým, který řídil vytvoření General Purpose Subsystem. Bylo třeba vynaložit značné úsilí na vytvoření konzistentního přístupu, který by poskytoval přesné informace o stavu na úrovni subsystému a stavu verze. Cílem bylo získat vážený odhad, který by zahrnoval následující:.

■ Metriky Ada/ADL. Umožňovaly poměrně přesně určit přímé ukazatele technického pokroku. Tyto metriky samy o sobě naprosto přesně odrážely pokrok ve vývoji a implementaci. Nebyly však vhodné k popisu dokončených částí smlouvy a finančního stavu.

■ Metriky s přidanou hodnotou. Umožnily poměrně přesně určit finanční stav a části smlouvy připravené k předání zákazníkovi. Obecně řečeno, jsou špatnými ukazateli skutečného technologického pokroku.

Stejně jako u většiny ostatních softwarových metrik oba tyto přístupy zpočátku poskytovaly nepřesné odhady absolutního pokroku. Byly to však vynikající odhady relativního pokroku, pokud byly pravidelně sledovány (v našem případě měsíčně). Jak se zkušenosti s těmito metrikami zvyšovaly, absolutní skóre se postupně upravovalo tak, aby předpovídalo úspěch nebo riziko. Celkové hodnocení bylo shrnuto do jediného grafu. Na Obr. D.9 ukazuje výsledný pokrok na nejvyšší úrovni pro každou jednotlivou verzi a pro obecný subsystém jako celek. Délka šrafované oblasti v každé verzi vzhledem k tečkované čáře (odkazující na aktuální měsíc) určuje, zda provedení předchází nebo zaostává za stávajícím plánem. Obrázek například ukazuje stav po 17. měsíci: NT testování verze 2 je o měsíc pozadu, vývoj verze 3 je o měsíc před plánem, vývoj

Rýže. D.9. Obecný vývojový pokrok.

General Purpose Subsystem je podle plánu, ale HT testování General Purpose Subsystem je o měsíc pozadu. Stínované oblasti jsou hodnocením hlavního vývojáře, který spojil měsíční metriky pokroku s měsíčními metrikami finančního zdraví do souhrnného (a tedy poněkud subjektivního) skóre.

Měsíční sbírka hodnot metrik poskytla správě podrobné pochopení pokroku, růstu kódu a dalších metrik dosažených v každé verzi. Metriky se shromažďují pro každou verzi a pro CSCI, aby mohly být zvažovány z různých úhlů. Manažeři* každého jednotlivého CSCI shromáždili a vyhodnotili své metriky předtím, než byly agregovány pro projekt jako celek. Proces byl objektivní, efektivní a smysluplný. Nejnižší úroveň hodnocení TBD_Statements byla samozřejmě subjektivní, ale byla určena těmi nejzkušenějšími lidmi: skutečnými vývojáři. Skóre byly uloženy ve formátu zdrojového kódu. To zvýšilo pravděpodobnost, že tento typ pracovního produktu bude obsahovat nejaktuálnější informace. Tento proces také umožnil konzistentním a jednotným způsobem porovnávat pokrok v různých oblastech projektu.

Na Obr. D.10 poskytuje měsíční odhady postupu pro obecný subsystém a pro každé vydání. Plánovaný objem změn vycházel z výpočtu hrubého váženého průměru pro každou verzi, provedeného podle pokynů uvedených v části D.5.3: 30 % objemu vytvořeného dobou PSCP a 70 % objemu době KSČP. Celkově byl podsystém pro obecné účely téměř přesně podle plánu, s jednou výjimkou. Pokrok dosažený v době PPOP (s výrazným předstihem) odrážel neočekávaný pozitivní dopad nástrojů pro generování zdrojového kódu. S jeho pomocí bylo pro SAPO vygenerováno více než 50 000 SLOC.

Soulad díla s plány se lišil v závislosti na konkrétní verzi. Pokrok dosažený u subsystému a u každé verze byl měsíčně hodnocen interním vedením a zákazníkem prostřednictvím kontrol projektového řízení. Metriky pokroku poskytly objektivní mechanismus a dohodnutý jazyk pro popis změn plánů a architektury, problémů s návrhem, rizik plánování a dalších problémů souvisejících s řízením. Objektivita tohoto přístupu byla hlavní složkou neantagonistických vztahů navázaných mezi všemi zainteresovanými stranami.

Každý pochopil, že ačkoli metrické hodnoty nebyly v raných fázích životního cyklu přesné, byly správné. Absolutní hodnoty byly zřídkakdy důležité. Relativní trendy byly důležitější a jak proces postupoval, přesnost všech metrik se zvyšovala. V době POP se metrické hodnoty staly základním kamenem komunikace projektu.

Rýže. D.10. Pokrok ve vývoji subsystému pro obecné účely D.7.2 Pokrok v testování.

Testovací organizace musela vytvořit testy integrace verzí a testy shody (některé testy NT, FT a OCT). Testování integrace verzí bylo při identifikaci problémů méně účinné, než se očekávalo. Testy ITV musely obsahovat celou sadu procedur integračního testování – od základních schopností až po speciální okrajové podmínky. Velká část této práce, zejména jádrová vlákna, se překrývala s integrační prací pro demonstraci. V souladu s tím testy ITV často duplikovaly přípravu na demonstrace, což bylo méně nákladově efektivní, než kdyby byly aktivity přípravy demonstrací kombinovány s ITV a odpovědnost za ně.

přidělené organizaci provádějící testování. Tabulka D.6 uvádí výsledky fáze 2 ITV, které odrážejí integrovaný stav produktu. Na plánování, přípravu a realizaci ITV však bylo vynaloženo více úsilí, než bylo zapotřebí. Kombinace předváděcí přípravy s aktivitami ITV by umožnila menšímu počtu zaměstnanců dělat lepší práci. Tento přístup by umožnil větší integraci (jako součást demo práce) před revalidací a efektivnější zpětné testování po revalidaci, aby bylo zajištěno, že všechny předchozí problémy byly vyřešeny.

<.>

Tabulka D.6.

Charakteristika SCO pro testování ITV verze 2

Zdroj problémů	Střední (	Velký 0 1 den)
Interpretace požadavků
Problémy s nezávislým testováním
Problémy s rozhraními
Nesprávné provedení
Žádoucí rozšíření (není problém)
Nekompatibilní konfigurace

Tabulka D.7 a Obr. D.11 poskytuje náhled na metriky průběhu z různých perspektiv, které byly použity k plánování a sledování testovacího programu v projektu CCPDS-R. Obrázek ukazuje graf pokroku vzhledem k tomu, co je plánováno pro testování shody. Testy NT, FT a OCT byly zdrojem možností testování, které organizace pro vývoj softwaru použila. NT byla odpovědností vývojových týmů, ale musela být řízena ve formálním prostředí správy konfigurace a pod dohledem (vizuálním dohledem) testovacího personálu. FT se skládal z funkčně propojených skupin scénářů, které prokazovaly shodu s požadavky pokrývajícími několik komponent najednou. Testy OCT nám umožnily určit aspekty shody, které nebylo možné prokázat, dokud nebyl systém plně vyvinut. Kvantitativní výkonnostní požadavky (QPR) pokrývaly všechny CSCI.

Formální testování HT (testování shody prováděné formou nezávislého testování) se ukázalo být obtížnější, než se plánovalo. Bylo to způsobeno především tím, že specifikace požadavků a přezkoumání návrhu byly přetíženy podrobnostmi vývoje a schvalovacími postupy.

Implementace formálního testování NT byla pečlivě kontrolována vládou a příprava na přezkoumání trvala extrémně dlouho. Vláda požadovala rozsáhlé testovací postupy pro mnoho jednotlivých konstrukčních detailů, které by ve skutečnosti neměly být považovány za požadavky. V zápalu vývoje byly postupy HT zřídka dostupné 30 až 60 dní před opakovaným testováním, protože smlouva vyžadovala jakýkoli typ testování shody. Formální proces testování NT byl jedním z hlavních důvodů, proč byly opakované kontroly důsledně dokončeny později, než bylo plánováno.

Tabulka D.7.

Testování shody funguje pomocí různých typů testů pro různé CSCI

Rýže. D.11. Průběh testování obecných subsystémů

Typ testu
Verze 0/1 NT
Verze 2 NT
Verze 3/4/5 NT

D.7.3 Stabilita.

Na Obr. D.12 poskytuje obecnou úroveň změny základní konfigurace. Zobrazuje celkový počet SLOC považovaných za nepoužitelné (ty, které byly ze základní verze odstraněny za účelem vylepšení kvůli objevené závadě, pro rozšíření nebo pro provedení jiných typů změn) a počet obnovených SLOC (těch, které byly znovu začleněny do základní verze). verze s opravami, rozšířeními nebo jinými změnami). Rychlost, s jakou byly defekty objeveny a která se lišila od rychlosti, s jakou byly opraveny, měla za následek intenzivní pozornost managementu, změny v prioritách přidělování zdrojů a nápravná opatření přijatá s cílem zajistit, aby testovací organizace (identifikace defektů) a vývojová organizace (provádějící obnovu) jsou v relativní rovnováze. Obecně platí, že situace znázorněná na obrázku odkazuje na mimořádně úspěšný projekt.

D.7.4 Míra vad.

Na Obr. D.13 Celkový počet defektů je určen vzhledem k softwarovému subsystému jako celku. Tato metrika odhaduje celkové vady zjištěné během vývoje subsystému pro obecné účely jako přibližně 25 % objemu celého produktu. Průměrná chybovost v softwarovém průmyslu se pohybuje od 40 % do 60 %. Počáteční základní konfigurace byla stanovena v době POP, ve 14. měsíci. Poté v něm bylo provedeno 1 600 samostatných změn.

Měsíc realizace smlouvy Obr. D.13. Míra defektů v obecném subsystému.

D.7.5 Adaptabilita

Pro General Purpose Subsystem jako celek bylo asi 5 % z celkového množství práce vynaloženo na finalizaci základní verze softwaru. Průměrné náklady na změnu byly asi 24 hodin na SCO. Tyto hodnoty vám umožňují vyhodnotit snadnost, s jakou lze provést změny v základní verzi softwaru. Úroveň adaptability dosažená projektem CCPDS-R byla přibližně čtyřikrát vyšší než u konvenčních projektů, ve kterých náklady na přepracování během životního cyklu obvykle přesahují 20 % celkových nákladů.

Na Obr. D.14 ukazuje průměrné náklady na jednu změnu v procesu vytváření všeobecného subsystému. Do doby OCT bylo zpracováno 1600 SCO týkající se změn konfiguračních základů, což vedlo ke stabilním nákladům na změnu. Projekt CCPDS-R byl jedním z mála protipříkladů k tvrzení: „čím později v životním cyklu půjdete, tím dražší problémy objevíte.

Většina raných SCO (zobrazených v rámečku označeném „Projektové změny“ na obrázku D.14) byly změny zahrnující velké množství lidí a velké množství komponent (změny v rozhraních a architektuře). Pozdější SCO (označené jako „Změny v implementaci“) se typicky zaměřovaly na jednu osobu a jednu složku. Poslední část křivky odráží atypický nárůst defektů, který byl výsledkem velkého technického návrhu na kompletní změnu sady příchozích zpráv pro General Purpose Subsystem. Tato oblast byla jednou z oblastí, kde provádění změn nebylo tak snadné, jak bychom si přáli. Přestože byl návrh robustní a přizpůsobitelný velkému počtu předem určených scénářů změn, nebylo nikdy zamýšleno přezkoumání celé sady vstupních zpráv a ani pro to nebyl navržen návrh.

Rýže. D.14. Adaptabilita Subsystémy pro všeobecné použití.

D.7.6 Úplnost.

Projekt CCPDS-R měl speciální požadavky na spolehlivost, a proto byl software distribuován zvláštním způsobem. Nezávislý testovací tým vytvořil automatizovanou testovací sadu. Byl proveden v lichých hodinách a testovala se základní verze softwaru pomocí scénářů náhodných zpráv. Tato strategie vedla k rozsáhlému testování za reálných podmínek po dlouhou dobu. Na základě výsledků bylo možné určit hodnotu MTBF pro software. Součásti kritické pro spolehlivost, které byly nuceny přejít do nejranějších fází iteračního plánu, byly podrobeny nejpřísnějšímu testování spolehlivosti. Výsledky jsou uvedeny na Obr. D.15.

Pro moderní distribuované architektury je tato metoda statistického testování na jedné straně nezbytná pro zajištění maximálního pokrytí testem a na druhé straně je užitečná pro odhalování problémů spojených s konflikty zdrojů, uváznutí, přetížení zdrojů, úniky paměti a další Heisenbergovy chyby. Spouštění náhodných a zrychlených skriptů po dlouhou dobu (přes noc nebo o víkendu) poskytuje včasný pohled na celkovou integritu systémových prostředků.

Rýže. D.15. Úplnost subsystému pro obecné účely.

D.7.7 Finanční/pracovní náklady na určité typy činností.

Tabulka D.8 pojednává o celkové podrobné struktuře nákladů obecného subsystému v projektu CCPDS-R. Tyto údaje byly odvozeny z konečných nákladů WBS a strukturovány podle pokynů uvedených v části 10.1. Prvky nižší úrovně jsou popsány v tabulce D.9.

■ Procenta uvedená v tabulce D.8 zhruba odpovídají procentům uvedeným v kapitole 10. Některé prvky řízení v tabulce D.9 však byly rozloženy do několika prvků v tabulce D.8, aby byly zvýrazněny činnosti na úrovni projektového řízení. .

■ Celkové úsilí testovacího týmu bylo shledáno jako relativně nízké ve srovnání s projekty využívajícími tradiční proces. Hlavním důvodem tohoto stavu věcí je, že tým architektury předal integrovaný softwarový produkt testovacímu a hodnotícímu týmu, který byl primárně odpovědný za testování integrovaného produktu.

Tabulka D.8.

Finanční náklady na General Purpose Subsystem pro WBS prvky nejvyšší úrovně

prvek WBS

Černikov Alexej

1. Úvod

Na rozdíl od většiny odvětví materiálové výroby jsou v otázkách projektů vývoje softwaru nepřijatelné jednoduché přístupy založené na násobení náročnosti práce průměrnou produktivitou práce. To je způsobeno především tím, že ekonomické ukazatele projektu nelineárně závisí na objemu práce a při výpočtu náročnosti práce je povolena velká chyba.

Proto se k řešení tohoto problému používají složité a poměrně složité metody, které vyžadují vysokou odpovědnost při aplikaci a určitý čas na přizpůsobení (upravení koeficientů).

Moderní komplexní systémy pro posuzování charakteristik projektů vývoje softwaru lze použít k řešení následujících problémů:

předběžné, trvalé a konečné posouzení ekonomických parametrů projektu: pracnost, doba trvání, náklady;
hodnocení rizik pro projekt: riziko porušení termínů a neplnění projektu, riziko zvýšené pracnosti ve fázích odlaďování a údržby projektu atd.;
rozhodování operativního řízení - na základě sledování určitých metrik projektu je možné promptně předcházet vzniku nežádoucích situací a eliminovat důsledky nedomyšlených návrhových rozhodnutí.

1 Úvod
2 Metriky
2.1 Metriky orientované na dimenzi (ukazatele odhadu objemu)
2.1.1 Hodnocení LOC (řádky kódu)
2.1.1.1 Metriky stylistiky a srozumitelnosti pořadů
2.1.2 Celkem podle SLOC
2.2 Metriky obtížnosti
2.2.2 Halsteadovy metriky
2.2.4 Chapinovy metriky

2.4 Obecný seznam metrik
2.4 Shrnutí
6 Internetové zdroje

2. Metriky

Metriky složitosti programu se obvykle dělí do tří hlavních skupin:

metriky velikosti programu;
metriky složitosti toku řízení programu;
metriky složitosti toku dat programu.

Metriky první skupiny jsou založeny na stanovení kvantitativních charakteristik souvisejících s velikostí programu a jsou poměrně jednoduché. Mezi nejznámější metriky této skupiny patří počet příkazů programu, počet řádků zdrojového textu a sada Halsteadových metrik. Metriky v této skupině jsou zaměřeny na analýzu zdrojového kódu programů. Proto je lze použít k posouzení složitosti vývojových meziproduktů.

Metriky druhé skupiny jsou založeny na analýze grafu řízení programu. Představitelem této skupiny je McCabeova metrika.

Řídicí graf programu, který používají metriky této skupiny, lze sestavit na základě modulových algoritmů. Proto lze metriky druhé skupiny použít k posouzení složitosti meziproduktů vývoje.

Metriky třetí skupiny jsou založeny na posouzení využití, konfigurace a umístění dat v programu. To se týká především globálních proměnných. Tato skupina zahrnuje metriky Chapin.

2.1 Metriky orientované na dimenzi (ukazatele hodnocení objemu)

2.1.1 Hodnocení LOC (řádky kódu)

Metriky orientované na dimenzi přímo měří softwarový produkt a proces jeho vývoje. Tyto metriky jsou založeny na odhadech LOC.

Tento typ metrik nepřímo měří softwarový produkt a proces jeho vývoje. Místo výpočtu skóre LOC se zaměřuje na funkčnost nebo užitečnost produktu spíše než na velikost.

Metriky orientované na dimenzi jsou nejrozšířenější v praxi vývoje softwaru. V organizacích zabývajících se vývojem softwarových produktů je zvykem registrovat u každého projektu následující ukazatele:

celkové mzdové náklady (v člověkoměsících, člověkohodinách);
velikost programu (v tisících řádků zdrojového kódu -LOC);
náklady na vývoj;
objem dokumentace;
chyby zjištěné během roku provozu;
počet lidí pracujících na produktu;
vývojové období.

Na základě těchto dat se obvykle vypočítávají jednoduché metriky pro hodnocení produktivity práce (KLOC/člověk/měsíc) a kvality produktu.

Tyto metriky nejsou univerzální a kontroverzní, zejména u takového ukazatele, jako je LOC, který výrazně závisí na použitém programovacím jazyce.

Počet řádků zdrojového kódu (Lines of Code - LOC, Source Lines of Code - SLOC) je nejjednodušší a nejběžnější způsob, jak odhadnout množství práce na projektu.

Zpočátku tento ukazatel vznikl jako způsob, jak posoudit množství práce na projektu, který používal programovací jazyky s poměrně jednoduchou strukturou: „jeden řádek kódu = jeden jazykový příkaz“. Dlouho se také ví, že stejnou funkcionalitu lze zapsat na různém počtu řádků, a pokud vezmeme jazyk vysoké úrovně (C++, Java), pak je možné na jeden řádek napsat 5-6 řádků funkcionality - to není problém. A to by nebylo tak špatné: moderní programovací nástroje samy generují tisíce řádků kódu pro triviální operaci.

Proto je metoda LOC pouze hodnotící metodou (která by měla být zohledněna, ale nikoli opírána při posuzování) a není v žádném případě povinná.

V závislosti na tom, jak se podobný kód bere v úvahu, existují dva hlavní ukazatele SLOC:

počet „fyzických“ řádků kódu - SLOC (používané zkratky jsou LOC, SLOC, KLOC, KSLOC, DSLOC) - je definován jako celkový počet řádků zdrojového kódu včetně komentářů a prázdných řádků (při měření ukazatele na počtu prázdných řádků se obvykle zavádí limit - Při výpočtu se bere v úvahu počet prázdných řádků, který nepřesahuje 25 % z celkového počtu řádků v měřeném bloku kódu).
Počet „logických“ řádků kódu – SLOC (používané zkratky jsou LSI, DSI, KDSI, kde „SI“ jsou zdrojové instrukce) – je definován jako počet příkazů a závisí na použitém programovacím jazyce. V případě, že jazyk neumožňuje umístit více příkazů na jeden řádek, bude počet „logických“ SLOC odpovídat počtu „fyzických“, s výjimkou počtu prázdných řádků a řádků komentářů. Pokud programovací jazyk podporuje umístění více příkazů na jeden řádek, pak jeden fyzický řádek musí být počítán jako více logických řádků, pokud obsahuje více než jeden jazykový příkaz.

Pro metriku SLOC existuje velké množství derivátů navržených pro získání individuálních projektových ukazatelů, z nichž hlavní jsou:

počet prázdných řádků;
počet řádků obsahujících komentáře;
procento komentářů (poměr řádků kódu k řádkům komentáře, odvozená stylistická metrika);
průměrný počet řádků pro funkce (třídy, soubory);
průměrný počet řádků obsahujících zdrojový kód funkcí (tříd, souborů);
průměrný počet řádků pro moduly.

2.1.1.1 Metriky stylistiky a srozumitelnosti pořadů

Někdy je důležité nejen spočítat počet řádků komentářů v kódu a jednoduše je porovnat s logickými řádky kódu, ale také zjistit hustotu komentářů. To znamená, že kód byl nejprve dobře zdokumentován, pak špatně. Nebo tato možnost: záhlaví funkce nebo třídy je zdokumentováno a okomentováno, ale kód nikoli.

Fi = SIGN (Ncomm. i / Ni – 0,1)

Podstata metriky je jednoduchá: kód je rozdělen na n-stejné části a pro každou z nich je určena Fi

2.1.2 Celkem podle SLOC

Potenciální nevýhody SLOC, které jsou terčem kritiky:

Je ošklivé a nesprávné zredukovat hodnocení práce člověka na několik číselných parametrů a podle nich posuzovat produktivitu. Manažer může přidělit nejtalentovanější programátory do nejobtížnější oblasti práce; to znamená, že vývoj této oblasti zabere nejdelší dobu a generuje nejvíce chyb vzhledem ke složitosti úkolu. Aniž by o těchto potížích věděl, může se jiný manažer na základě získaných ukazatelů rozhodnout, že programátor odvedl svou práci špatně.
Metrika nezohledňuje zkušenosti zaměstnanců a jejich další kvality
Zkreslení: Proces měření může být zkreslený tím, že zaměstnanci jsou si vědomi měřených ukazatelů a snaží se tyto ukazatele optimalizovat spíše než jejich výkon. Pokud je například počet řádků zdrojového kódu důležitým ukazatelem, pak se programátoři budou snažit napsat co nejvíce řádků a nebudou používat techniky zjednodušování kódu, které snižují počet řádků (viz postranní panel o Indii).
Nepřesnost: Neexistují žádné metriky, které by byly dostatečně smysluplné a zároveň přesné. Počet řádků kódu je jednoduše počet řádků, tento indikátor nedává představu o složitosti řešeného problému. Analýza funkčních bodů byla vyvinuta pro lepší měření složitosti kódu a specifikací, ale využívá osobní úsudek měřiče, takže různí lidé získají různé výsledky.

A hlavní věc k zapamatování: metrika SLOC neodráží pracnost při vytváření programu
.

Příklad ze života :
V jedné z firem jsme při implementaci použili tuto metriku – počítali jsme řádky kódu. Šéf organizace byl na dovolené, ale po návratu z ní se rozhodl využít transparentnosti a sledovatelnosti změn a podívat se, jak jsou na tom jeho manažeři se svými projekty. A abych kurz plně pochopil, klesl jsem na nejnižší úroveň (tedy nehodnotil jsem hustotu vad, počet opravených chyb) - na úroveň zdrojových textů. Rozhodl jsem se spočítat, kdo napsal a kolik řádků. A aby to byla opravdu zábava, porovnejte počet pracovních dnů v týdnu a množství napsaného kódu (logika je jednoduchá: člověk pracoval 40 hodin týdně, což znamená, že musí napsat spoustu věcí). Přirozeně se našel člověk, který za týden napsal jen jeden řádek, ani ho nenapsal, pouze opravil ten stávající...
Manažerův hněv neznal mezí – našel flákače! A bylo by špatné pro programátora, kdyby projektový manažer nevysvětlil, že: byla nalezena chyba v programu, našel ji VIP klient, chyba má dopad na podnikání klienta a bylo potřeba ji urychleně opravit, pro tento účel byl vybrán dodavatel, který nasadil stojan, zaplavil prostředí klienta, potvrdil výskyt chyby a začal ji hledat a odstraňovat. Přirozeně nakonec změnil kus kódu, který měl špatný stav a vše fungovalo.

Souhlas, je hloupé počítat náklady práce pomocí této metriky - je nutné komplexní posouzení...

2.2 Metriky obtížnosti

Kromě ukazatelů pro hodnocení objemu práce na projektu jsou velmi důležité pro získání objektivních odhadů projektu ukazatele pro hodnocení jeho složitosti. Tyto ukazatele zpravidla nelze vypočítat v nejranějších fázích práce na projektu, protože vyžadují přinejmenším podrobný návrh. Tyto ukazatele jsou však velmi důležité pro získání předpovědních odhadů doby trvání a nákladů projektu, protože přímo určují jeho pracovní náročnost.

2.2.1 Objektově orientované metriky

V moderních podmínkách je většina softwarových projektů vytvářena na základě přístupu OO, a proto existuje značné množství metrik, které umožňují posoudit složitost objektově orientovaných projektů.

Metriky	Popis
Vážené metody na třídu (WMC)	Odráží relativní míru složitosti třídy na základě cyklomatické složitosti každé z jejích metod. Třída se složitějšími metodami a více metodami je považována za složitější. Nadřazené třídy se při výpočtu metriky neberou v úvahu.
Vážené metody na třídu (WMC2)	Míra složitosti třídy založená na myšlence, že třída s více metodami je složitější a že metoda s více parametry je také složitější. Nadřazené třídy se při výpočtu metriky neberou v úvahu.
Hloubka dědičného stromu	Délka nejdelší dědičné cesty končící v tomto modulu. Čím hlubší je strom dědičnosti modulu, tím obtížnější může být předvídat jeho chování. Na druhou stranu zvýšení hloubky dává danému modulu větší potenciál pro opětovné použití chování definovaného pro třídy předků.
Počet dětí	Počet modulů, které přímo zdědí daný modul Velké hodnoty této metriky ukazují na vysokou znovupoužitelnost. v tomto případě může příliš velká hodnota znamenat špatně zvolenou abstrakci.
Spojení mezi objekty	Počet modulů přidružených k tomuto modulu v roli klienta nebo dodavatele. Nadměrná vazba indikuje slabé modulární zapouzdření a může zabránit opětovnému použití kódu.
Odpověď pro třídu	Počet metod, které mohou být volány instancemi třídy; vypočítá jak součet počtu místních metod, tak počtu vzdálených metod

2.2.2 Halsteadovy metriky

Metrika Halsted odkazuje na metriky vypočítané na základě analýzy počtu řádků a syntaktických prvků zdrojového kódu programu.

Halsteadova metrika je založena na čtyřech měřitelných charakteristikách programu:

NUOprtr (Number of Unique Operators) - počet jedinečných operátorů programu, včetně oddělovacích znaků, názvů procedur a operačních znaků (slovník operátorů);
NUOprnd (Number of Unique Operands) - počet jedinečných programových operandů (slovník operandů);
Noprtr (Number of Operators) - celkový počet operátorů v programu;
Noprnd (Number of Operands) – celkový počet operandů v programu.

Na základě těchto charakteristik se počítají skóre:

Programový slovník
(Halstead Program Vocabulary, HPVoc): HPVoc = NUOprtr + NUOprnd;
Délka programu
(délka programu Halstead, HPLen): HPLen = Noprtr + Noprnd;
Rozsah programu
(Halstead Program Volume, HPVol): HPVol = HPLen log2 HPVoc;
Složitost programu
(Halstead Difficulty, HDiff): HDiff = (NUOprtr/2) × (NOprnd / NUOprnd);
Na základě indikátoru HDiff se navrhuje vyhodnotit vývojové úsilí programátora pomocí indikátoru HEff (Halstead Effort): HEff = HDiff × HPVol.

2.2.3 McCabeho metriky cyklomatické složitosti

Cyklomatický ukazatel složitosti je jedním z nejběžnějších ukazatelů pro hodnocení složitosti softwarových projektů. Tento indikátor vyvinul vědec McCabe v roce 1976, patří do skupiny indikátorů pro hodnocení složitosti toku řízení programu a je vypočítáván na základě grafu toku řízení programu. Tento graf je konstruován ve formě orientovaného grafu, ve kterém jsou výpočetní operátory nebo výrazy reprezentovány jako uzly a přenos řízení mezi uzly je reprezentován jako oblouky.

Cyklomatický ukazatel složitosti umožňuje nejen zhodnotit pracnost implementace jednotlivých prvků softwarového projektu a upravit celkové ukazatele pro odhad doby trvání a nákladů projektu, ale také posoudit související rizika a učinit potřebná manažerská rozhodnutí.

Zjednodušený vzorec pro výpočet cyklomatické složitosti je následující:

C = e – n + 2,

Kde e – počet žeber a n – počet uzlů
na grafu řídicí logiky.

Obvykle se logické operátory neberou v úvahu při výpočtu cyklomatické složitosti.

V procesu automatizovaného výpočtu indikátoru cyklomatické složitosti se zpravidla používá zjednodušený přístup, podle kterého se graf nekonstruuje a indikátor se počítá na základě počtu operátorů řídicí logiky (if, switch, atd.) a možný počet programů cest provádění.

McCabeho cyklomatické číslo udává počet průchodů potřebných k pokrytí všech obrysů těsně spojeného grafu nebo počet testovacích běhů programu potřebných pro vyčerpávající testování „každá větev funguje“.

Cyklomatický indikátor složitosti lze vypočítat pro modul, metodu a další strukturní jednotky programu.

Existuje značné množství modifikací indikátoru cyklomatické složitosti.

„Upravená“ cyklomatická složitost – nepovažuje každou větev operátoru s více volbami (přepínač), ale celý operátor jako jeden celek.
„Přísná“ cyklomatická složitost – zahrnuje logické operátory.
„Zjednodušený“ výpočet cyklomatické složitosti – zahrnuje výpočet nikoli na základě grafu, ale na základě počítání kontrolních operátorů.

2.2.4 Chapinovy metriky

Existuje několik jeho modifikací. Podívejme se na jednodušší a z hlediska praktického použití docela efektivní verzi této metriky.

Podstatou metody je posouzení informační síly jediného softwarového modulu analýzou povahy použití proměnných ze seznamu vstupů a výstupů.

Celá sada proměnných, které tvoří seznam I/O, je rozdělena do čtyř funkčních skupin.

Q = a1P + a2M + a3C + a4T, kde a1, a2, a3, a4 jsou váhové koeficienty.

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

2.3 Předběžné hodnocení založené na statistických metodách v závislosti na fázích vývoje programu

Při použití integrovaných nástrojů mají společnosti vyvíjející standardní řešení (do této kategorie patří tzv. „inhausers“ – společnosti zabývající se obsluhou hlavní činnosti) možnost na základě shromážděných statistik provádět prognózy složitosti programů. Statistická metoda je vhodná pro řešení takových typických problémů a prakticky není vhodná pro predikci unikátních projektů. V případě unikátních projektů se používají jiné přístupy, jejichž pojednání přesahuje rámec tohoto materiálu.

Typické úkoly spadají z hojnosti byznysu do vývojových oddělení, takže předběžné posouzení složitosti by mohlo značně zjednodušit úkoly plánování a řízení, zejména proto, že existuje akumulovaná databáze projektů, ve které jsou uloženy nejen konečné výsledky, ale také všechny počáteční a středně pokročilé.

Zdůrazněme typické fáze vývoje programu:

vývoj specifikací programových požadavků;
definice architektury;
vývoj modulární struktury programu, vývoj rozhraní mezi moduly. Vývoj algoritmů;
vývoj a testování kódu.

Nyní se zkusme podívat na řadu metrik, které se často používají pro předběžné posouzení v prvních dvou fázích.

2.3.1 Předběžné posouzení složitosti programu ve fázi vývoje specifikace požadavků programu

K vyhodnocení výsledků této fáze lze použít metriku předpokládaného počtu operátorů Nprogn programu:

Nprogn = NF*jednotka

Kde: NF – počet funkcí nebo požadavků ve specifikaci požadavků na vyvíjený program;
Ned – jedna hodnota počtu operátorů (průměrný počet operátorů na jednu průměrnou funkci nebo požadavek). Hodnota Ned je statistická.

2.3.2 Předběžné posouzení složitosti ve fázi definice architektury

Si = NI / (NF * NIed * Ksl)

Kde:
NI – celkový počet proměnných přenášených přes rozhraní mezi komponentami programu (také statistický);
NIed – jedna hodnota počtu proměnných přenesených přes rozhraní mezi komponenty (průměrný počet proměnných přenesených přes rozhraní na jednu průměrnou funkci nebo požadavek);
Ksl je koeficient složitosti vyvíjeného programu, zohledňuje nárůst jednotkové složitosti programu (složitost na jednu funkci nebo požadavek specifikace požadavků programu) u velkých a složitých programů oproti průměrnému softwaru.

2.4 Obecný seznam metrik

Tabulka 1 obsahuje stručný popis metrik, které nejsou zahrnuty ve výše uvedeném podrobném popisu, ale přesto jsou tyto metriky nezbytné a důležité, jen jsou statisticky mnohem méně časté.

Všimněte si také, že účelem tohoto článku je ukázat princip, a ne popisovat všechny možné metriky v mnoha kombinacích.

Metriky je kvantitativní měřítko a metoda, kterou lze použít pro měření.

Rádi bychom dodali, že zavedení a používání metrik je nezbytné pro zlepšení kontroly nad vývojovým procesem a zejména nad testovacím procesem, který budeme dále zvažovat.

Účelem kontroly testu je získat zpětnou vazbu a vizualizovat proces testování.

Informace potřebné pro řízení se shromažďují (manuálně i automaticky) a používají se k vyhodnocení stavu a rozhodování, jako je pokrytí (například pokrytí požadavků nebo kódu pomocí testů) nebo výstupní kritéria (například kritéria ukončení testu).

Metriky lze také použít k posouzení postupu plánovaných prací a plnění rozpočtu

Vytváření, používání a analýza metrik
Podle našeho názoru má pro větší přehlednost smysl seskupit metriky podle typů subjektů zapojených do zajišťování kvality a testování softwaru, konkrétně:
Metriky podle testovacích případů

Metriky pro chyby/defekty

Metriky podle úkolu

Podívejme se blíže na každý z nich:

Metriky pro testovací případy

Metriky „Reopened/Closed Bugs“ a „Rejected/Opened Bugs“ jsou zaměřeny na sledování práce jednotlivých členů vývojových a testovacích týmů.

Příklad jedna:
Řekněme, že máme situaci, kdy počet znovu otevřených chyb po opravě neklesá nebo dokonce stoupá. To je signál, že je nutné analyzovat příčiny, protože Podobná situace může ukázat, že:

Nekvalitní řešení problému (oprava chyby)

Druhý příklad ukáže, proč je potřeba metrika „Odmítnuté/Otevřené chyby“:
Pozorujeme, že procento odmítnutých chyb je velmi vysoké. To by mohlo znamenat:

Funkční požadavky lze interpretovat různými způsoby
Tester přesně nepopsal problém
Vývojář nechce napravit chybu, kterou udělal, nebo nevěří, že je to vlastně chyba. (Tento problém je přímým důsledkem toho druhého, který vznikl kvůli nepřesnému popisu)

Všechny tyto problémy výrazně destabilizují situaci na projektu. Proto se při jejich vzniku doporučuje krátký rozhovor s vedoucími projektového týmu, aby se následně snížil počet znovuobjevených a odmítnutých vad.

Metriky podle testovacích případů

Jméno	Popis
Úkoly nasazení	Metrika ukazuje počet a výsledky instalací aplikací. Postup instalace aplikace byl popsán v článku Postup instalace nové verze softwaru (Deployment WorkFlow). Pokud je počet verzí odmítnutých testovacím týmem kriticky vysoký, doporučuje se urychleně analyzovat a identifikovat důvody a co nejdříve vyřešit existující problém.
Stále otevřené úkoly	Metrika ukazuje počet stále otevřených problémů. Na konci projektu musí být dokončeny všechny úkoly. Úkoly rozumíme tyto typy prací: psaní dokumentace (architektura, požadavky, plány), implementace nových modulů nebo změna stávajících na základě požadavků na změnu, práce na zakládání stánků, různé studie a mnoho dalšího.

Metriky pro úkoly se mohou lišit, uvedli jsme pouze dvě z nich. Zajímavá může být také metrika doby dokončení úkolu a mnoho dalších.

Na závěr bychom chtěli poznamenat, že přítomnost potřebných metrik a grafů, které odrážejí změny stavu projektu v průběhu času, vám umožní zlepšit nejen proces testování, ale také vývoj jako celek a také usnadnit postup analýzy dokončeného projektu, což vám umožní předejít budoucím problémům.

Tréninkové video. Yandex.Metrica: úvod

Podívejte se na video

Co lze sledovat pomocí Metrica

Přitahování návštěvníků

Přímé reporty v Metrici jasně ukazují, které kampaně, reklamy, fráze a vyhledávací dotazy přivádějí návštěvníky na váš web, z jakých regionů a z jakých reklamních platforem. Tyto informace použijte k optimalizaci kampaní.

Své fráze můžete vylepšit například přidáním klíčových slov z relevantních vyhledávacích dotazů a vylučujících klíčových slov z irelevantních dotazů – pomůže to přilákat více zainteresovaných návštěvníků a zvýšit CTR.

Publikum webu

V Metrici můžete získat podrobné charakteristiky svého publika. Pohlaví, věk a zájmy návštěvníků se vypočítávají analýzou jejich chování na internetu pomocí technologie Crypt. Na základě těchto údajů lze reklamu učinit relevantnější a tím zvýšit její efektivitu.

Dosažení cílů a konverzí

Je důležité nejen přivést návštěvníky na váš web, ale také pochopit, zda se stanou skutečnými klienty. K tomu je potřeba v Metrici nastavit cíle – tedy určit klíčové akce, které by měli návštěvníci webu provádět.

Váš kupující může být například návštěvník, který:

klikli na tlačítko „Přidat do košíku“;
přešel z košíku na stránku "Děkujeme za nákup" při zadávání objednávky;
navštívili alespoň dvě stránky webu;
přešel na stránku s kontaktními informacemi;
registrovaný na webu nebo přihlášený k odběru newsletteru.

Přizpůsobení cílů vám umožní pochopit, které fráze a reklamy přivádějí na web uživatele, kteří dosahují svých cílů. Nárůst cílených návštěv můžete nejen analyzovat, ale také je optimalizovat pomocí jedné z automatických strategií: Průměrné náklady na konverzi nebo Týdenní rozpočet. Maximální konverze.

Příjmy

Majitelé internetových obchodů mohou v Metrici dostávat podrobné informace o objednávkách zadaných na webových stránkách obchodu. Můžete zjistit, kolik peněz každá objednávka přinesla a ze kterých kanálů pocházejí nejziskovější objednávky.

Přímo v rozhraní Metrica můžete rychle odhadnout své reklamní náklady v Directu. Můžete se například podívat na své celkové reklamní náklady, zjistit průměrné náklady na konverze pro všechny své reklamní kampaně a odhadnout průměrné nebo celkové náklady na kliknutí pro určité typy zařízení, regionů, vyhledávacích dotazů nebo platforem.

Cílené hovory

Zákazníci zadávají objednávky nejen na webu, ale také telefonicky. Servis "cílový hovor" umožňuje porovnat efektivitu různých propagačních kanálů. Obdržíte speciální telefonní čísla, která lze propojit s různými zdroji, s úrovní podrobností až k jednotlivým reklamním kampaním. Číslo na webu a ve virtuální vizitce se automaticky nahradí v závislosti na zdroji – můžete tak sledovat, kde se o vás každý volající dozvěděl.

Jak začít sbírat statistiky

Nainstalujte kód počítadla na všechny stránky svého webu co nejblíže k horní části stránky - závisí na tom úplnost shromážděných dat. Správnost instalace čítače můžete zkontrolovat v konzole prohlížeče.

Pokud vytvoříte mnoho kampaní se stejnou sadou počítadel, můžete počítadla zadat v poli na stránce uživatelských nastavení Počítadlo metrik pro nové kampaně.

Dokud neurčíte čísla počítadel, automatické označování odkazů vám pomůže přenášet data mezi Directem a Metrica. Ujistěte se, že je tato možnost povolena v nastavení kampaně Označte odkazy pro Metricu a váš web správně otevírá odkazy se značkami.

Jak funguje značkování odkazů

Pozor. Pokud není pole v parametrech kampaně vyplněno Počítadla metrik a možnost je zakázána Označte odkazy pro Metricu, pak údaje o kliknutích na reklamu nebudou zahrnuty do Metrice a údaje z Metrice nebudou zahrnuty do statistik Direct.

Otázky a odpovědi

Jak rychle se aktualizují data v přehledech Metrica?

Akce návštěvníka na webu se projeví ve většině přehledů Metrica během několika minut. Data pro speciální reporty na Direct procházejí dodatečným ověřováním, takže v Metrici končí se zpožděním až několika hodin.

Jak rychle se data o dosažení cílů dostanou do Directu?

Údaje o dosažení konkrétního cíle jsou odeslány Direct do 24 hodin.

Proč se údaje ve statistikách Direct liší od údajů v Metrici?

Oblíbené v kategorii: