Meer dan een halve eeuw onderzoek heeft de moderne software-industrie een indrukwekkende verzameling modellen en meetgegevens verzameld die de individuele productie- en operationele eigenschappen van software evalueren. Het nastreven van hun universaliteit, het onvermogen om rekening te houden met de reikwijdte van de toepassing van de software die wordt ontwikkeld, het negeren van de stadia van de softwarelevenscyclus en, ten slotte, het onredelijke gebruik ervan in uiteenlopende prhebben echter het vertrouwen aanzienlijk ondermijnd. van softwareontwikkelaars en gebruikers daarin.

Een analyse van de technologische ervaring van leiders op het gebied van softwareproductie laat echter zien hoe duur het is vanwege de imperfectie van een onwetenschappelijke voorspelling van de solvabiliteit en arbeidskosten, de complexiteit van programma’s, de inflexibiliteit van de controle en het beheer van hun ontwikkeling, en nog veel meer, wat aangeeft het gebrek aan end-to-end methodologische ondersteuning en uiteindelijk leidend tot het niet voldoen aan de vereisten van de gebruiker, de vereiste norm en het daaropvolgende pijnlijke en tijdrovende herwerken. Deze omstandigheden vereisen een zorgvuldige selectie van technieken, modellen en methoden voor het beoordelen van de kwaliteit van software, waarbij rekening wordt gehouden met de beperkingen van hun geschiktheid voor verschillende levenscycli en binnen de levenscyclus, het vaststellen van een procedure voor het gezamenlijk gebruik ervan, het gebruik van redundante multi-modelmodellen onderzoek naar dezelfde indicatoren om de betrouwbaarheid van huidige beoordelingen te vergroten, accumulatie en integratie van diverse metrische informatie voor het nemen van tijdige productiebeslissingen en certificering van eindproducten.

Hieronder, in Tabel 1.3, staan ​​modellen en metrieken die zichzelf hebben bewezen bij het beoordelen van softwarekwaliteit, geschikt voor het voorspellen en vaststellen van verschillende indicatoren van de complexiteit en betrouwbaarheid van programma's.

Tabel 1.3.

Modelnaam	Formule, benaming
COMPLEXITEITSMETRICS
Halstead-statistieken Programmaduur; Reikwijdte van het programma Evaluatie van de implementatie ervan; Moeilijkheid om het te begrijpen; Coderingscomplexiteit; Expressietaalniveau; Informatie-inhoud; Optimale modulariteit;	N = n 1 log 1 n 1 + n 2 log 2 n 2 L * = (2 n 2)/ (n 1 N 2) D = (n 1 N 2) (2n 2) = 1/ L * * = V/ D 2 = V/ L * 2
Gilba-statistieken Aantal lusinstructies; Aantal voorwaardeverklaringen; Aantal modules of subsystemen; De verhouding tussen het aantal verbindingen tussen modules en het aantal modules; De verhouding tussen het aantal abnormale outputs van een reeks operators en het totale aantal operators;	f = N 4 SV / L mod f*=N*SV/L
McCabe-statistieken Cyclomatisch getal; Cyclomatische complexiteit;	(G) = m – n + p (G) = (G) +1 = m – n + 2
Chepin-metriek Een maatstaf voor de moeilijkheid om programma's te begrijpen op basis van invoer- en uitvoergegevens;	H = 0,5T+P+2M+3C
Schnadewied-metriek Aantal paden in de controlegrafiek
Myers-metrisch Intervalmaat;
Hansen-metriek Paar (cyclomatisch nummer, aantal operators)
Chen's maatstaf Chen's topologische maatstaf;	M(G) = ((G), C, Q0)
Woodward-metriek Knooppuntmaat (aantal);
Kulik-metriek Normaal getal (het aantal eenvoudigste cycli in een normaal programmadiagram);
Hoera-metrisch Cyclomatisch nummer van een Petri-net dat de besturingsstructuur van het programma weerspiegelt;
Metrieken van Whitworth, Zulevsky Een maatstaf voor de complexiteit van de besturingsstroom Een maatstaf voor de complexiteit van een datastroom;
Peterson-metriek Aantal multi-invoercycli;
Metrieken van Harrison, Majel Functioneel getal (de som van de verminderde complexiteit van alle hoekpunten van de controlegrafiek); Functionele verhouding (de verhouding van het aantal grafiekhoekpunten tot het functionele aantal); Reguliere expressies (het aantal operanden, operatoren en haakjes in de reguliere expressie van de programmabesturingsgrafiek);	f* = N1 / f1
Pivovarsky-metriek Gemodificeerde maatstaf voor cyclomatische complexiteit;	N(G) = * (G) + Pik
Pratt-metriek Testmaatregel;
Metrisch kanton Karakteristieke aantallen polynomen die de controlegrafiek van het programma beschrijven;
McClure-statistiek Een maatstaf voor de complexiteit gebaseerd op het aantal mogelijke paden voor programma-uitvoering, het aantal besturingsstructuren en variabelen;	C(V) = D(V)J(V)/N
Kafur-metrisch Een maatregel gebaseerd op het concept van informatiestromen;
Schutts-metriek, Mohanty Entropiemaatregelen;
Collofelo-metrisch Een maatstaf voor de logische stabiliteit van programma's;
Zolnovsky, Simmons, Thayer metrisch Gewogen som van verschillende indicatoren: - (structuur, interactie, volume, data); - (interfacecomplexiteit, computationele complexiteit, input/output-complexiteit, leesbaarheid);
Berlinger-metriek Informatiemaatregel;	I(R) = (F * (R) F - (R)) 2
Schumann-metriek Complexiteit vanuit het standpunt van de statistische taaltheorie;
Jongere statistiek Logische complexiteit rekening houdend met de geschiedenis van berekeningen; Ontwerpcomplexiteit Verzadiging van opmerkingen Aantal externe oproepen Aantal exploitanten	C c = log 2 (i + 1)[ n Cxy (n)]
MODEL VOORSPELLING
Halstead-modellen Prognose van systeembronnen; Het voorspellen van het aantal fouten. IBM-model Totale complexiteitsmodel Connectiviteitsmodellen Spline-model	P=3/8 (Ra – 1) 2 Ra B = Nlog 2 n / 3000 B = 23M 1 + M 1 0 B = 21,1 + 0,1 V + COMP (S) P ij = 0,15 (Si + Sj) + 0,7 C ij P ij = S ik ​​(Z ij 2 + N ij 2) ln (Z ij 2 + N ij 2) + + Z ik + N 1
SCHATTINGSMODELLEN
Jelinski – Moranda	R(t) = e - (T – 1 + 1) t
Weiss-Bayes	R 1 (t) = e - - (i –1))t (, /t 1 ,…,t i-1)dd
Chic-Wolverton	R 1 (t) = e - (N – 1 + 1) t ik 2 / 2
Kleinhout	R 1 (t) = (+ / ++ t) (N – ik + 1)
Nelson	R j (t) = exp ( ln (1 – P j))
Khaletski	R j (t) = P- (1- nj) / n j
Foutopsporingsmodel	R j (t) =P- f j (,)
Mozaïekmodel	Rj (t) = 1 - (- j - 1)

De tabel presenteert verschillende maatstaven van de complexiteit van software voor verschillende vormen van representatie ervan, modellen die de voortgang van softwareontwikkelingsprocessen voorspellen en probabilistische modellen voor het beoordelen van de betrouwbaarheid.

Laten we eens snel kijken naar de complexiteitsmetrieken. Een van de belangrijkste doelstellingen van wetenschappelijke en technische ondersteuning is het verminderen van de complexiteit van software. Dit maakt het mogelijk om de complexiteit van ontwerp, ontwikkeling, testen en onderhoud te verminderen en de eenvoud en betrouwbaarheid van de geproduceerde software te garanderen. Gerichte vermindering van de complexiteit van software is een procedure die uit meerdere stappen bestaat en vereist een voorbereidende studie van bestaande complexiteitsindicatoren, hun classificatie en correlatie met programmatypen en hun locatie in de levenscyclus.

De programmacomplexiteitstheorie is gericht op softwarekwaliteitsbeheer en controle van de standaardcomplexiteit ervan tijdens de werking. Momenteel is de verscheidenheid aan indicatoren (die tot op zekere hoogte de complexiteit van programma's beschrijven) zo groot dat het gebruik ervan een voorafgaande bestelling vereist. In sommige gevallen wordt voldaan aan drie categorieën van complexiteitsmetrieken. De eerste categorie wordt gedefinieerd als een woordenboekmetriek gebaseerd op de metrische relaties van Halstead, de cyclomatische metingen van McCabe en de metingen van Thayer. De tweede categorie is gericht op communicatiestatistieken die de complexiteit van de relaties tussen systeemcomponenten weerspiegelen - dit zijn de Win- en Winchester-statistieken. De derde categorie omvat semantische statistieken die verband houden met het architecturale ontwerp van programma's en hun ontwerp.

Volgens een andere classificatie zijn complexiteitsindicatoren onderverdeeld in twee groepen: ontwerpcomplexiteit en operationele complexiteit. De complexiteit van het ontwerp, die wordt bepaald door de omvang van het programma, het aantal verwerkte variabelen, de arbeidsintensiteit en duur van de ontwikkeling en andere factoren, wordt geanalyseerd op basis van drie basiscomponenten: de complexiteit van de programmastructuur , de complexiteit van transformaties (algoritmen) en de complexiteit van gegevens. De tweede groep indicatoren omvat tijd-, programma- en informatiecomplexiteit die de operationele kwaliteiten van de software kenmerken.

Er zijn echter een aantal andere benaderingen voor de classificatie van complexiteitsmaatstaven, maar hoewel deze de specifieke aspecten van de onderzochte programma's vastleggen, laten ze niet toe (zij het met een grote aanname) om de algemeen, iets waarvan de metingen de basis kunnen vormen voor productiebeslissingen.

Een gemeenschappelijk kenmerk dat steevast inherent is aan elke software (en verband houdt met de juistheid ervan) is het STRUCTUUR. Het is belangrijk om deze omstandigheid te verbinden met een bepaalde waarde van structurele complexiteit in de reeks maatstaven voor softwarecomplexiteit. En bovendien is het bij het analyseren van de structurele complexiteit raadzaam om ons alleen te beperken tot de topologische maten ervan, d.w.z. maatregelen gebaseerd op de topologische kenmerken van het grafische model van het programma. Deze maatregelen voldoen aan de overgrote meerderheid van de vereisten voor indicatoren: algemene toepasbaarheid, geschiktheid van de betreffende eigenschap, betekenis van de beoordeling, consistentie, kwantitatieve uitdrukking, reproduceerbaarheid van metingen, lage rekencomplexiteit en de mogelijkheid om de beoordeling te automatiseren.

Het zijn de topologische maten van complexiteit die het vaakst worden gebruikt in de onderzoeksfase, die beslissingen vormen over het productiemanagement (in de processen van ontwerp, ontwikkeling en testen) en een toegankelijke en gevoelige standaard vormen voor het eindproduct, waarvan de controle moet worden uitgevoerd. tijdens de werking ervan regelmatig worden uitgevoerd.

De eerste maatstaf voor topologische complexiteit is de cyclomatische maatstaf van McCabe. Het is gebaseerd op het idee om de complexiteit van software te schatten aan de hand van het aantal basispaden in de controlegrafiek, d.w.z. dergelijke paden, door samen te stellen welke alle mogelijke paden van de invoer van de grafiek naar de uitgangen kunnen verkrijgen. Het cyclomatische getal (G) van een digraph G met n-hoekpunten, m-bogen en p-verbonden componenten is de grootheid (G) = m – n + p.

Er is een stelling dat het aantal basispaden in een digraph gelijk is aan het cyclomatische getal vermeerderd met één. In dit geval wordt de cyclomatische complexiteit van een software P met een controlegrafiek G de waarde (G) = (G) +1 = m – n + 2 genoemd. In de praktijk is de cyclomatische complexiteit van een software gelijk aan het getal van predikaten plus één, waardoor het kan worden berekend zonder een controlegrafiek te construeren door simpelweg de predikaten te tellen. Deze maatstaf weerspiegelt de ‘psychologische’ complexiteit van de software.

De voordelen van de maatregel zijn onder meer de eenvoud van de berekening en de herhaalbaarheid van het resultaat, evenals de duidelijkheid en betekenis van de interpretatie. De nadelen zijn onder meer: ​​ongevoeligheid voor de grootte van de software, ongevoeligheid voor veranderingen in de structuur van de software, gebrek aan correlatie met de structuur van de software, gebrek aan onderscheid tussen de Fork- en Loop-constructies, gebrek aan gevoeligheid voor het nesten van lussen. De tekortkomingen van de cyclomatische maatstaf leidden tot de opkomst van de wijzigingen ervan, evenals tot fundamenteel verschillende maten van complexiteit.

J. Myers stelde het interval [1 2] voor als maatstaf voor complexiteit, waarbij 1 een cyclomatische maatstaf is en 2 het aantal individuele omstandigheden plus één is. In dit geval wordt de DO-operator beschouwd als één voorwaarde, en CASE met n - uitkomsten voor n - 1 voorwaarden.

De geïntroduceerde maat werd een intervalmaat genoemd.

W. Hansen kwam op het idee om een ​​paar (cyclomatisch getal, aantal operators) te nemen als maatstaf voor de complexiteit van software. Er is een topologische maat Z(G) bekend die gevoelig is voor de structurering van software. Bovendien is het Z(G) = V(G) (gelijk aan cyclomatische complexiteit) voor gestructureerde programma's en Z(G) V(G) voor ongestructureerde programma's. Varianten van de cyclomatische complexiteitsmaatstaf omvatten ook de maatstaf M(G) = (V(G),C,Q), waarbij C het aantal voorwaarden is dat nodig is om de controlegrafiek te dekken met een minimum aantal routes, en Q de mate van connectiviteit van de programmagrafiekstructuur en de lengte ervan.

De functionele maatstaf voor complexiteit van Harrison-Majel houdt in dat aan elk grafiekknooppunt zijn eigen complexiteit (primair) wordt toegewezen en de grafiek wordt verdeeld in "invloedssferen" van predikaathoekpunten. De complexiteit van een bol wordt gereduceerd genoemd en is samengesteld uit de primaire complexiteit van de hoekpunten die binnen zijn invloedssfeer vallen, plus de primaire complexiteit van het predikaathoekpunt zelf. Primaire moeilijkheden worden op alle mogelijke manieren berekend. De functionele maatstaf voor softwarecomplexiteit is dus de som van de verminderde complexiteit van alle hoekpunten van de controlegrafiek.

De Pivovarsky-maatregel heeft tot doel om bij het beoordelen van de complexiteit van software niet alleen rekening te houden met verschillen tussen sequentiële en geneste besturingsstructuren, maar ook tussen gestructureerde en ongestructureerde programma's. Het wordt uitgedrukt door de relatie N(G) = * (G) + P i , waarbij * (G) de gewijzigde cyclomatische complexiteit is, berekend op dezelfde manier als V(G), maar met één verschil: een CASE-operator met n-uitgangen worden beschouwd als één logische operator, in plaats van als n – 1 operatoren. P i – nestdiepte van i – dat predicaathoekpunt.

Om de nestdiepte van predikaathoekpunten te berekenen, wordt het aantal “invloedssferen” gebruikt. De nestdiepte wordt opgevat als het aantal van alle “invloedssferen” van predikaten die ofwel volledig in de sfeer van het betreffende hoekpunt zijn opgenomen, ofwel ermee snijden. De nestdiepte neemt toe doordat niet de predicaten zelf nestelen, maar de “invloedssferen”. Een vergelijkende analyse van cyclomatische en functionele metingen uit het besproken programma voor een tiental verschillende controlegrafieken laat zien dat, hoewel andere metingen van deze klasse ongevoelig zijn, de Pivovarsky-maat toeneemt wanneer er van sequentiële programma's naar geneste programma's en vervolgens naar ongestructureerde programma's wordt overgegaan.

De McClure-maatregel is ontworpen om de complexiteit van gestructureerde programma's tijdens het ontwerpproces te beheersen. Het is van toepassing op hiërarchische schema's voor het verdelen van programma's in modules, waardoor u lang voordat u het programma schrijft een partitieschema met minder complexiteit kunt selecteren. De metriek is de afhankelijkheid van de complexiteit van het programma van het aantal mogelijke uitvoeringspaden, het aantal besturingsstructuren en het aantal variabelen (waarvan de padkeuze afhangt). De McClure-methode voor het berekenen van complexiteit is duidelijk gericht op goed gestructureerde programma's.

Een testmaatregel M is een maatstaf voor complexiteit die aan de volgende voorwaarden voldoet:

1. De complexiteitsmaatstaf van een eenvoudige operator is 1;

2. M ((F1; F2; …; Fn)) = i n M(Fi);

3. M (ALS P DAN F1 ANDERS F2) = 2 MAX (M (F1), M (F2));

4. M (terwijl P DO F) = 2 M(F).

De maat neemt toe met de nestdiepte en houdt rekening met de lengte van het programma. Nauw verwant aan de testmaatregel is een maatregel gebaseerd op reguliere inbedding. Het idee van deze maatstaf voor de complexiteit van het programma is om het totale aantal tekens (operands, operatoren, haakjes) in een reguliere expressie te tellen met het minimaal vereiste aantal haakjes die de controlegrafiek van het programma beschrijven. Alle maatregelen in deze groep zijn gevoelig voor het nesten van besturingsstructuren en de lengte van het programma. Het niveau van de rekencomplexiteit neemt echter toe.

Laten we complexiteitsmaatregelen overwegen die rekening houden met de aard van de gevolgen. De knooppuntmeting van Woodward en Hedley is gebaseerd op het idee om de topologische kenmerken van de controlestroom te berekenen. In dit geval verwijst knooppuntcomplexiteit naar het aantal. Deze maatregel volgt de complexiteit van programmalinearisatie en is gevoelig voor structurering (de complexiteit neemt af). Het is toepasbaar voor het vergelijken van gelijkwaardige programma's en verdient de voorkeur boven de Halstead-maatstaf, maar in termen van algemeenheid is het inferieur aan de McCabe-maatstaf.

De topologische maatstaf van Chen drukt de complexiteit van een programma uit door het aantal kruispunten van grenzen tussen gebieden gevormd door het programmastroomschema. Deze benadering is alleen van toepassing op gestructureerde programma's die alleen een sequentiële verbinding van besturingsstructuren mogelijk maken. Voor ongestructureerde programma's hangt de Chen-maatstaf aanzienlijk af van voorwaardelijke en onvoorwaardelijke vertakkingen. In dit geval kunt u de boven- en ondergrenzen van de maat opgeven. De bovenste is m+1, waarbij m het aantal logische operatoren is wanneer ze genest zijn. De onderste is gelijk aan 2. Wanneer de controlegrafiek van een programma slechts één verbonden component heeft, valt de Chen-maat samen met de McCabe-cyclomatische maat.

De statistieken van Gilb evalueren de complexiteit van grafiekgeoriënteerde programmamodules aan de hand van de verhouding tussen het aantal overgangen op basis van de voorwaarde en het totale aantal uitvoerbare instructies. De maatstaf die het aantal intermodulaire verbindingen relateert aan het totale aantal modules heeft zichzelf goed bewezen. Deze statistieken werden gebruikt om de complexiteit van gelijkwaardige programmacircuits te schatten, vooral Yanov-circuits.

Er worden ook complexiteitsmetingen gebruikt die rekening houden met de geschiedenis van berekeningen, de aard van de interactie van modules en complexe metingen.

Een reeks cyclomatische metingen is geschikt voor het beoordelen van de complexiteit van primaire geformaliseerde specificaties, die samen de initiële gegevens, doelen en voorwaarden definiëren voor het construeren van de vereiste software. Door dit “primaire” programma te evalueren of verschillende alternatieve opties te vergelijken, kunt u in eerste instantie het softwareontwikkelingsproces harmoniseren en, vanaf het begin, de huidige resulterende complexiteit ervan controleren en beheren.

Met nieuwe methodieken zoals Extreme Programming of Scrum kan de ontwikkeling sneller plaatsvinden, en door de beschikbaarheid van nieuwe platforms en abstractie uit lagere lagen kunnen veel valkuilen worden vermeden. Niettemin moet kwaliteitscontrole op verschillende niveaus worden uitgevoerd - van methodologisch tot technologisch niveau, wanneer kwaliteitscontroleprocessen automatisch plaatsvinden, bijvoorbeeld tijdens automatische projectassemblages. Elke controle veronderstelt echter de aanwezigheid van maatstaven die het mogelijk maken om de verwezenlijking van een bepaald kwaliteitsniveau van een softwareproject te beoordelen.

Codestatistieken

Softwarestatistiek (softwaremetriek) – een numerieke maatstaf waarmee u bepaalde eigenschappen van een specifiek gedeelte van de programmacode kunt evalueren. Voor elke statistiek zijn er meestal benchmarks die aangeven bij welke extreme waarden het de moeite waard is om aandacht te besteden aan een bepaald codegedeelte. Codemetrieken zijn onderverdeeld in categorieën en kunnen compleet verschillende aspecten van een softwaresysteem evalueren: de complexiteit en structuur van de softwarecode, de connectiviteit van componenten, het relatieve volume van softwarecomponenten, enz. De gemakkelijkst te begrijpen metriek is het aantal regels. van code in een softwaresysteem, hoewel deze gemakkelijk kan worden berekend, maar in combinatie met andere metrieken kan dienen om geformaliseerde gegevens te verkrijgen voor code-evaluatie. U kunt bijvoorbeeld een relatie opbouwen tussen het aantal regels code in een klasse en het aantal methoden/eigenschappen in de klasse, waardoor u een kenmerk krijgt dat aangeeft hoe uitgebreid de methoden van een bepaalde klasse zijn. Bovendien kunnen dergelijke schattingen worden gebruikt in combinatie met complexiteitsmetrieken (bijvoorbeeld de cyclomatische complexiteit van McCabe) om de moeilijkste gebieden in de programmacode te identificeren en passende actie te ondernemen.

Codemetrieken kunnen ook dienen om architectonische kenmerken te identificeren. Het gebruik van dergelijke meetgegevens heeft het grootste effect bij het analyseren van grote softwaresystemen, waarbij handmatige analyse en beoordeling van de broncode veel tijd in beslag kan nemen. U kunt metrieken bijvoorbeeld op verschillende manieren visualiseren, zoals weergegeven in Afb. 1, waarbij elk programmablok wordt weergegeven als een rechthoek, waarbij de lengte van elke zijde van de rechthoek de waarde van een van de metrieken weerspiegelt (bijvoorbeeld complexiteit, structuur, enz.). Een dergelijke representatie kan zowel voor software-entiteiten op hoog niveau (assemblies, bibliotheken, naamruimten) als voor meer private elementen (eigenschappen, methoden) worden gebouwd. Tegelijkertijd kunt u bij het analyseren van een diagram op hoog niveau snel problematische bibliotheken identificeren en naar een lager niveau gaan om problematische entiteiten te onderzoeken.

Programmacodestatistieken zijn een belangrijk hulpmiddel en worden tegenwoordig al door veel softwarefabrikanten gebruikt. Bij certificering op hogere niveaus volgens de ISO/IEC- of CMM/CMMI-modellen is het gebruik van codemetrieken dus verplicht, waardoor tot op zekere hoogte beheersbaarheid van het ontwikkelingsproces kan worden bereikt.

Er zijn veel verschillende classificaties van softwarestatistieken, waarbij statistieken vanuit verschillende perspectieven worden geïnterpreteerd en dezelfde kenmerken worden gerangschikt op basis van verschillende criteria. Een van dergelijke classificaties kan de verdeling van metrieken in groepen zijn op basis van de beoordelingsonderwerpen:

maat– vergelijkende beoordeling van softwareomvang;

complexiteit– beoordeling van de architectuur en algoritmen van het softwaresysteem (negatieve indicatoren van deze groep metrieken duiden op problemen die kunnen optreden tijdens de ontwikkeling, ondersteuning en debuggen van de programmacode);

draagbaarheid– beoordeling van het potentieel van het softwaresysteem voor latere wijziging.

Natuurlijk zijn er andere groepen die niet in deze classificatie zijn opgenomen, bijvoorbeeld statistieken over gebruikerstevredenheid of indicatoren voor de naleving van initiële vereisten, maar in dit geval zullen we geïnteresseerd zijn in de kwaliteit van software vanuit het oogpunt van technische implementatie. .

Maakt de grootte uit?

De SLOC-metriek (broncoderegels) weerspiegelt het aantal regels broncode. Deze indicator kan niet altijd worden gebruikt om het volume van een softwaresysteem objectief te beoordelen; de numerieke waarde ervan hangt af van veel willekeurige factoren, zoals de codeerstijl. Het is nauwelijks legitiem om twee softwaresystemen alleen op dit criterium te vergelijken, er zijn zoveel afgeleide indicatoren voor SLOC verschenen: het aantal lege regels; aantal regels met commentaar; percentage reacties; aantal regels code in methoden/functies; gemiddeld aantal regels code per methode/functie; gemiddeld aantal regels code per klasse/pakket; gemiddeld aantal regels code per module, enz.

Naast SLOC wordt bij het schatten van de omvang vaak de indicator van “logische” coderegels LSI (logische broninstructies) gebruikt, berekend na normalisatie (de broncode in de juiste vorm brengen) van de lijst: het elimineren van de plaatsing van meerdere instructies op één regel, lege regels, opmerkingen verwijderen, coderegels opmaken om gegevens te initialiseren, enz. Een dergelijke indicator kan dienen voor een meer objectieve beoordeling van het volume van het systeem (de indicator die normalisatie gebruikt, ziet er hetzelfde uit als SLOC: het aantal lijnen, maar niet fysiek, maar logisch). LSI heeft ook afgeleiden, zoals een metriek die niet wordt berekend als het fysieke aantal regels code in de bronprogrammeertaal, maar als het aantal instructies in een taal op een lager niveau (Assembler Language, MSIL, enz.), die elimineert de noodzaak van normalisatie.

Andere metrieken van dit type zijn gebaseerd op entiteiten die specifiek zijn voor een specifiek programmeerparadigma. Het meest populaire vandaag de dag is het objectgeoriënteerde programmeerparadigma, maar de functionele en procedurele benaderingen van programmeren hebben ook hun eigen specifieke set metrieken. Vanuit een objectgeoriënteerde benadering kan de grootte van een systeem worden berekend als het aantal klassen dat het bevat. De indicator van het aantal klassen is een van de belangrijkste maatstaven in deze aanpak, maar afhankelijk van de gebruikte programmeertaal kunnen maatstaven zoals het aantal naamruimten in het project, het aantal structuren, opsommingen, het aantal methoden, enz. Bovendien kunt u de “dichtheid” van deze indicatoren berekenen door de verhouding van de waarden van deze statistieken te bepalen. U kunt bijvoorbeeld de verhouding tussen het aantal klassen en het aantal methoden berekenen en begrijpen hoeveel methoden er gemiddeld in één klasse zitten. Er is echter verder onderzoek nodig om drempelwaarden voor dit soort metrieken te bepalen. De eenvoudigste manier om de grenswaarden te bepalen kan een experiment zijn waarin de waarden van deze metrieken worden berekend voor bestaande systemen. De berekening van dergelijke verhoudingen zal ons in staat stellen het idee van het systeem dat zich heeft ontwikkeld op basis van kwantitatieve statistieken te corrigeren.

De kwaliteit van het systeem is niet direct afhankelijk van het gebruik van deze indicatoren, maar in de loop van de tijd kunnen ervaren ontwikkelaars bij benadering de omvang van het systeem voorspellen voor een bepaalde functionaliteit die de klant nodig heeft. In dit geval, als er een merkbare afwijking is van de gespecificeerde indicatoren (bijvoorbeeld een aanzienlijke toename van het aantal klassen met een laag aantal methoden per klasse), is het de moeite waard om na te denken over het feit dat er mogelijk een buitensporig aantal is van objecten in het systeem, en het refactoren van de code in een eerder stadium.

Complexiteit

Om de codekwaliteit te beoordelen en te controleren, kunnen complexiteitsmetrieken rechtstreeks worden gebruikt: cyclomatische complexiteit, codecoherentie, diepte van overerving, enz.

De cyclomatische complexiteitsmetriek toont het aantal vertakkingen van de controlestroom van een programma, verhoogd met één. Om deze metriek te berekenen, wordt op basis van de broncode een gerichte grafiek gemaakt, die één invoer en één uitvoer bevat. In dit geval zijn de hoekpunten van de grafiek gecorreleerd met die secties van de programmacode die alleen sequentiële berekeningen bevatten en geen vertakkings- en lusoperatoren bevatten. Bogen zijn in dit geval gecorreleerd met overgangen van blok naar blok. Bovendien is elk hoekpunt van de grafiek bereikbaar vanaf het startpunt, en het eindpunt is bereikbaar vanaf elk ander punt. In dit geval kan de cyclomatische complexiteit worden berekend als het verschil tussen het aantal bogen en het aantal hoekpunten, verhoogd met twee. Een dergelijke indicator kan de complexiteit van de besturingsstroom van het programma weerspiegelen en een signaal geven over de mogelijke aanwezigheid van een codegedeelte van lage kwaliteit. Helaas kan deze metriek, ondanks zijn duidelijke praktische bruikbaarheid, geen onderscheid maken tussen cyclische operatoren. Bovendien kunnen programmacodes die door dezelfde grafieken worden weergegeven predikaten hebben (logische expressies die een variabele bevatten) die totaal verschillend zijn qua complexiteit. Om deze reden wordt cyclomatische complexiteit soms gelijktijdig met andere metrieken gebruikt, bijvoorbeeld met de metriek van het aantal operators.

Met de klasseconnectiviteitsmetriek kunt u de mate van afhankelijkheid van de softwarecomponenten van het systeem van elkaar bepalen. Verhoogde waarden van deze metriek ten opzichte van de drempelwaarden kunnen duiden op overmatige koppeling van het systeem, wat lijkt te wijten aan zwakke modulaire inkapseling. Deze eigenschap van een softwaresysteem kan leiden tot problemen bij het hergebruiken van code. Deze maatstaf kan als leidraad worden gebruikt bij het bouwen en herontwerpen van de architectuur van een softwaresysteem. De belangrijkste manieren om de objectcohesie te verminderen zijn het strikter inkapselen van logica in objecten, het herzien van de werking van algoritmen vanuit een conceptueel perspectief, en structurele decompositie. In dit geval worden objectfactory's gebruikt, die onnodige connectiviteit vermijden op het moment dat klasse-instanties worden gemaakt. Dankzij het gebruik van ruwe waarden van deze metriek is het mogelijk om de samenhang van het softwaresysteem, en daarmee de complexiteit van de code, te verminderen.

Soms wordt een variatie op de metriek gebruikt die de samenhang van de code weerspiegelt: het aantal bewerkingsaanroepen. Met deze statistiek kunt u de systeemconnectiviteit kwantificeren in de vorm van methodeaanroepen. De statistiek telt alleen oproepen naar de bewerkingen die door de gebruiker zijn gedefinieerd. Als methode A() bijvoorbeeld methode B() drie keer aanroept, is de waarde van deze metriek één; als methode B() elk één keer wordt aangeroepen vanuit de methoden A(), C() en D(), dan is de metrische waarde gelijk aan drie. De absolute waarde van deze metriek kan echter aanzienlijk variëren van project tot project, afhankelijk van de benadering van het ontwerpen en coderen van softwaresystemen. Zelfs binnen hetzelfde ontwikkelingsteam aan identieke projecten kan de waarde van deze maatstaf verschillen als gevolg van subjectieve factoren (bijvoorbeeld de stijl van een bepaalde ontwikkelaar bij het opsplitsen van logica in afzonderlijke methoden) die de constructie van het softwaresysteem hebben beïnvloed.

Het directe resultaat van de berekening van deze metriek is van twijfelachtige praktische betekenis, maar samen met de totale waarde van de metriek kan het aantal methoden in een klasse een objectieve beoordeling geven van de samenhang van het systeem. Als u deze metriek bijvoorbeeld samen met de complexiteitsmetriek en volumetrische kenmerken gebruikt, kunt u op basis van het geheel van de waarden van deze metrieken code van onvoldoende hoge kwaliteit detecteren.

Een andere belangrijke maatstaf voor het beoordelen van de complexiteit is de gemiddelde overervingsdiepte, die wordt berekend als de gemiddelde waarde van de overervingsdiepte voor alle door de gebruiker gedefinieerde klassen in het systeem. Hierbij wordt geen rekening gehouden met klassen die zich niet op het laagste niveau van de overervingshiërarchie bevinden. Hoge waarden van de metriek kunnen erop wijzen dat de architecten van het softwaresysteem zich te veel laten meeslepen door de technieken van objectgeoriënteerd programmeren, en dit kan de verdere ontwikkeling van het systeem negatief beïnvloeden. Overerving vergroot de coherentie aanzienlijk, wat mogelijk niet tot uiting komt in andere systeemevaluatiestatistieken. Vaak kunt u bij het bouwen van programmacode het gebruik van overerving vermijden door deze te vervangen door gelijkwaardige technieken. U kunt in plaats daarvan bijvoorbeeld afhankelijkheidsinjectie en IoC-containers gebruiken. Het resultaat van de berekening van deze metriek wordt meestal in zijn ruwe vorm gebruikt bij praktische problemen met architectuur en refactoring. De resulterende metrieken kunnen ook worden gebruikt in complexere, complexere metrieken. Met andere woorden: als de waarde van deze metriek groot is, kan er onmiddellijk een afwijking worden geïdentificeerd. Bovendien kan deze metriek worden gebruikt in combinatie met andere, zoals de complexiteit en het volume van het McCabe-systeem, om een ​​softwaresysteem nauwkeuriger te meten.

Over het algemeen kunnen complexiteitsmetrieken softwarefabrikanten aanzienlijke hulp bieden bij het bewaken en beheren van de softwarekwaliteit.

Ondersteunbaarheid

Metrieken van dit type tonen de complexiteit van het proces van het onderhouden en ontwikkelen van programmacode en zijn in de regel nauw verwant aan complexiteitsmetrieken, maar hebben hun eigen kenmerken die de ondersteuningsmogelijkheden van het systeem weerspiegelen.

Een van de belangrijkste statistieken in deze categorie is de Halstead-metriek, die vier meetbare kenmerken van een programma definieert: het aantal unieke programma-instructies, inclusief scheidingstekens, procedurenamen en bewerkingstekens (statementwoordenboek); aantal unieke programma-operands (operandwoordenboek); totaal aantal uitspraken in het programma; het totale aantal operanden in het programma. Op basis van deze kenmerken worden basisbeoordelingen gemaakt: er wordt een programmawoordenboek samengesteld; de lengte van het programma, het volume en de complexiteit ervan worden bepaald. Vervolgens wordt voorgesteld om verschillende maatregelen te berekenen waarmee u programmacode kunt evalueren. Bijvoorbeeld een uitdrukking voor het berekenen van de kwaliteit van programmeren, de moeilijkheid om een ​​programma te begrijpen, de mentale kosten van het maken van een programma, enz.

De Halstead-metriek is puur informatief; het blijft echter een van de weinige waarmee we de indicator van systeemondersteuning in de toekomst kunnen kwantificeren, en deze indicator heeft een directe correlatie met de kwaliteit van het uitgebrachte product.

Code-analysetool

Ontwikkelaars op het Microsoft-platform kunnen profiteren van Visual Studio 2008, waarmee u een basisset van belangrijke meetgegevens kunt berekenen en deze in realtime kunt volgen (Afbeelding 2). Het belangrijkste gebruiksscenario voor statistieken is echter om ontwikkelingsmanagers te informeren dat de kwaliteit van een product mogelijk is afgenomen of toegenomen. Daarom is het zinvol om dergelijke statistieken te berekenen tijdens het bouwproces van het project.

Met Visual Stuido 2008 en Microsoft Build kunt u geen serieuze hiërarchie van metrieken opbouwen, en hiervoor moet u andere tools gebruiken, zoals NDepend, waarmee het .NET-platform verschillende soorten cohesie, overerving en abstractie kan berekenen en kan integreren in het programmacreatieproces in overeenstemming met de vereisten van een specifiek ontwikkelingsteam.

Problemen met het gebruik van codestatistieken

Ondanks het feit dat je met statistieken het ontwikkelingsproces kunt beheersen, gaat het werken ermee gepaard met een aantal problemen.

Ten eerste zijn alle momenteel bekende codestatistieken niet betekenisvol of nauwkeurig genoeg. Ze zijn niet in staat een objectief beeld te geven van de toestand van het softwaresysteem, maar geven alleen indicatoren die worden berekend met behulp van een bepaald algoritme. Ten tweede kan het meetproces kunstmatig worden verstoord doordat werknemers hun programmacode ‘optimaliseren’ zodat de meetgegevens betere resultaten opleveren. Bovendien houdt het formele gebruik van statistieken geen rekening met de ervaring van werknemers en het niveau van het bedrijf en kan het niet alleen voordelen, maar ook schade met zich meebrengen.

Niettemin zijn metrieken een behoorlijk nuttig hulpmiddel in de handen van ontwikkelaars en projectmanagers, waardoor ze momenten kunnen identificeren waarop de ontwikkeling naar een lager kwaliteitsniveau is gedaald en de moeilijkste gebieden in het systeem kunnen herkennen. Het bepalen van numerieke indicatoren kan nieuwe informatie opleveren over het product dat wordt ontwikkeld en kan helpen bij het beter plannen van de kosten voor de verdere ontwikkeling ervan.

Sergej Zvezdin ([e-mailadres beveiligd]) – postdoctorale student aan de South Ural State University (Tsjeljabinsk).

Bij MSU is een portaal voor afstandsonderwijs geopend

School voor afstandsonderwijs van de Staatsuniversiteit van Moskou. M.V. Lomonosov opende zijn eigen internetportaal. Het biedt toegang tot de gezamenlijke open elektronische bibliotheek van de Staatsuniversiteit van Moskou en de Russische Academie van Wetenschappen, leerboeken en cursussen, audio- en videomateriaal, evenals educatieve programma's die gebruik maken van technologieën voor afstandsonderwijs. Sommige bronnen van het portaal zijn alleen beschikbaar voor studenten van programma's voor afstandsonderwijs die het collegegeld hebben betaald in overeenstemming met een overeenkomst met de universiteit. MSU-video's zijn nu beschikbaar op kanaal universiteit op YouTube. De educatieve zender bevat opnames van lezingen en universitaire evenementen.

eLearning alleen voor 17% van de Russische bedrijven

Het onderzoekscentrum van het SuperJob.ru-portaal presenteerde de resultaten van een onderzoek naar online training voor personeel van Russische bedrijven. Onder binnenlandse werkgevers is het gebruik van e-learning bij het werken met personeel niet erg gebruikelijk. Slechts 17% van de bedrijven biedt deze vorm van training aan voor het personeel. Deze technologieën worden vooral gebruikt in grote bedrijven met een personeelsbestand van 5.000 mensen (50%). 79% van de werkgevers maakt helemaal geen gebruik van deze praktijk. De redenen liggen ofwel in het gebrek aan noodzakelijke technische uitrusting, ofwel in de onwil van het management om dit soort training toe te passen. Over het algemeen heeft slechts 11% van de Russen ervaring met afstandsonderwijs. Hiervan was 9% van de respondenten tevreden met het resultaat, en 2% studeerde niet af en stopte met studeren. Onder degenen die de opleiding voltooiden, bevonden zich bijna twee keer zoveel mannen als vrouwen (respectievelijk 11% en 6%). Tegelijkertijd studeren Russen tussen de 35 en 55 jaar vaker via internet dan jongeren. 12% van de respondenten in de leeftijdsgroep van 40 tot 50 jaar en slechts 9% van de Russen onder de 23 jaar kan bogen op succesvolle ervaring met afstandsonderwijs.

Resultaten van de wedstrijd “Maximale Schaalbaarheid 2009”

De competitie voor high-performance computing-projecten “Maximum Scalability” zou, net als vorig jaar, samenvallen met het internationale nanotechnologieforum. Wetenschappers uit twintig Russische steden claimden de overwinning, maar de organisatoren, Intel en de Russian Nanotechnology Corporation, reikten alle prijzen uit aan projecten in de hoofdstad. De Grand Prix werd toegekend aan Vladimir Bochenkov van de Faculteit Scheikunde van de Staatsuniversiteit van Moskou. Lomonosov voor het project “Ontwikkeling en implementatie van een parallel algoritme voor temperatuurversnelde dynamiek.” Het door de auteur voorgestelde systeem maakt het mogelijk om de condensatie van nanostructuren, moleculaire bundelepitaxie en de interactie van biologische moleculen te bestuderen.

Het Wereldkampioenschap Programmeren is begonnen

Tijdens de finale van de 34e jaarlijkse International Collegiate Programming Contest (ICPC), georganiseerd door de Association for Computing Machinery (ACM) en gesponsord door IBM, zullen honderd winnende studententeams in regionale competities het tegen elkaar opnemen. Ze krijgen minimaal acht problemen voorgelegd die binnen vijf uur moeten worden opgelost. De finale vindt plaats op 5 februari 2010 aan de Harbin Engineering University (China). Problemen in het verleden omvatten bijvoorbeeld het vinden van een schip dat verdwaald is op zee, het trianguleren van de locatie van een beschadigde radiozender, het berekenen van obstakels in een golfspel, het coderen en decoderen van berichten, het afdrukken in braille en het vinden van een uitweg uit een doolhof. . Vorig jaar werden drie van de vier gouden medailles gewonnen door Russische teams. In de kwalificatiefase namen 7.109 teams van 1.838 universiteiten uit 88 landen deel aan het kampioenschap. Voor het tweede jaar op rij werd het team van de St. Petersburg State University of Information Technologies, Mechanics and Optics wereldkampioen.

We hebben een nieuw boek uitgebracht, Social Media Content Marketing: hoe u in de hoofden van uw volgers kunt kruipen en ze verliefd kunt maken op uw merk.

Abonneren

Laten we een rapport maken. Selecteer in de statistieken ‘Doelen bereiken’ – ‘Het doel waarvoor u de conversie heeft ingesteld’. Dit is meestal een pagina 'Bedankt voor uw aankoop'.

Als gevolg hiervan zullen we gegevens ontvangen over hoeveel aankopen er zijn gedaan voor elke Republiek Kazachstan en hoeveel is uitgegeven aan het aantrekken van gebruikers die deze aankopen hebben gedaan. Deel het aantal conversies door de kosten van klikken om de kosten van één lead te berekenen. Als u dit heeft ingesteld, kunt u een kolom 'Opbrengst' toevoegen om de ontvangen winst te schatten.

Segmenten voor retargeting en bodaanpassingen: een nieuw niveau van relatie met potentiële kopers

In deze sectie zullen we Yandex.Metrics maken en opslaan en aanpassingen definiëren die we kunnen gebruiken bij het opzetten van campagnes in Direct.

Vergeet niet om de tijdsperiode zo in te stellen dat het monster representatief is. Het is noodzakelijk dat de gegevens worden opgebouwd op basis van het gedrag van een grote groep bezoekers.

Geslacht en leeftijd – aanpassing

Nadat we dit rapport hebben gemaakt, kunnen we zien wie beter op onze site koopt, mannen of vrouwen, en wat de leeftijd is van dergelijke kopers. Hierna staat niets ons meer in de weg om de tarieven voor dit segment aan te passen.

Selecteer: “Rapporten” – “Bezoekers” – “Gender” (1).

Daarom maken wij aanpassingen voor vrouwen. Tegelijkertijd hebben de verkregen gegevens ons geholpen te zien dat vertegenwoordigers van het sterkere geslacht ook tijd op onze website doorbrengen. U moet met deze informatie werken. Schrijf bijvoorbeeld relevante advertenties.

Tijd en klok - aanpassing

Uw bezoekers kunnen gedurende de dag of week verschillende activiteiten hebben, dus op dit punt identificeren we de meest converterende dagen en uren voor uw resource, waarna u tijdaanpassingen kunt instellen in Direct.

“Rapporten” – “Bezoekers” – “Aanwezigheid per tijdstip”.

In de groeperingen voegen we toe: Gedrag: datum en tijd – “Datum/tijdfragmenten” – “Dag van de week van bezoek” (2). Selecteer een doel en sorteer op conversie. Wij ontvangen een rapport waaruit blijkt op welke dag en op welk tijdstip de conversie maximaal is.

Geografie

“Rapporten” – “Bezoekers” – “Geografie”.

Het rapport helpt sites regio's te identificeren die beter verkopen dan andere. Voor veel niches komt het leeuwendeel van de omzet doorgaans uit Moskou of St. Petersburg en hun regio's. Daarom verdeelt het grootste deel van de adverteerders hun Republiek Kazachstan in federale steden en de rest van Rusland.

Het geografische rapport helpt u bij het vinden van een koers voor verdere fragmentatie van campagnes in Direct of bij het identificeren van regionale advertentiecampagnes met zwakke rendementen.

Segment “Vergeten winkelwagen”

Wij creëren: “Rapporten” – “Bezoekers” – “Tijd sinds eerste bezoek”.

Voor doelen selecteren we een macrodoel: aankoop, afspraak voor een adviesgesprek op kantoor, enz. We sorteren op conversie. Selecteer de eerste twee lijnen om de grafiek te plotten. Als gevolg hiervan krijgen we informatie over hoeveel tijd onze klanten besteden aan het nadenken over hun aankoopbeslissing. Bovendien kunnen we gegevens in de Direct-interface gebruiken om te voorkomen dat er advertenties worden weergegeven aan degenen die ons aanbod niet langer nodig hebben.

Uit het rapport zien we dat het doel vooral op de dag van het bezoek wordt bereikt, maar dat gebruikers gedurende de hele maand terugkomen en converteren.

Nu het segment zelf. We zullen het maken voor degenen die het artikel in de winkelwagen hebben achtergelaten, maar het nooit hebben gekocht.

Laten we naar het al bekende rapport “Bronnen” – “Samenvatting” gaan, alleen een vinkje plaatsen in de kolom “Advertentieconversies”, klik op + en selecteer in het menu: “Gedrag” – “Doelen bereiken” – “Doel: toegevoegd aan winkelwagen ” (Javascript-doel moet zijn ingesteld op de knoppen "Toevoegen aan winkelwagen"). We slaan het segment op en geven het een naam, ga nu naar Direct.

We zoeken de advertentie die we aan dit segment willen tonen, klikken op ‘Voorwaarden voor doelgroepselectie’ en vervolgens op ‘Voorwaarde toevoegen’.

Rapporten voor websiteanalyse: bestuderen en verbeteren

Webvisor

De gegevens zullen ons helpen de zwakke punten van de site te identificeren en te begrijpen welke problemen gebruikers tegenkomen.

Laten we eens kijken naar de Webvisor-segmenten voor bezoeken waarbij ons macrodoel is bereikt.

Laten we een voorbeeld nemen en kijken hoe gebruikers dit hebben bereikt. Misschien gaan we gedragspatronen van onze klanten begrijpen waar we ons niet van bewust waren. Wat als de meesten van hen, voordat ze een bestelling plaatsten, een fotoalbum doorzochten of interactie hadden met interactieve elementen op de site, en misschien veel tijd besteedden aan recensies? Dergelijke gegevens helpen u beslissen hoe u blokken op de site correct plaatst en ontwerpt.

Het tweede segment bestaat uit gebruikers die voldoende tijd op onze website hebben doorgebracht om een ​​aankoop te doen, maar deze nooit hebben gedaan. Door dergelijke bezoeken te analyseren, wordt inzicht verkregen in de belangrijkste uitdagingen waarmee bezoekers worden geconfronteerd.

Scrollen/klik op kaarten

Een scrollkaart helpt u te begrijpen op welk scherm uw bezoekers meer tijd doorbrengen. Misschien bevindt bepaalde noodzakelijke informatie die zal helpen bij het nemen van een aankoopbeslissing zich in de “koude zone” en moet deze naar een andere plaats worden verplaatst. Een klant wordt bijvoorbeeld alleen geadverteerd voor verzoeken die een metrostation aangeven, en een kaart met een adres en routebeschrijving bevindt zich onderaan de pagina.

Het resultaat is een hoog percentage weigeringen, omdat de locatie van het kantoor van de organisatie belangrijk is voor klanten die met dergelijke verzoeken komen.

Trainingsvideo. Yandex.Metrica: introductie Bekijk de video

Wat kan worden gevolgd met Metrica

Bezoekers trekken

Directe rapporten in Metrica laten duidelijk zien welke campagnes, advertenties, zinsdelen en zoekopdrachten bezoekers naar uw website brengen, vanuit welke regio’s en vanaf welke advertentieplatforms. Gebruik deze informatie om uw campagnes te optimaliseren.

U kunt uw woordgroepen bijvoorbeeld verbeteren door trefwoorden uit relevante zoekopdrachten en uitsluitingszoekwoorden uit irrelevante zoekopdrachten toe te voegen. Dit zal helpen meer geïnteresseerde bezoekers aan te trekken en de CTR te verhogen.

Sitepubliek

In Metrica kunt u gedetailleerde kenmerken van uw publiek verkrijgen. Het geslacht, de leeftijd en de interesses van bezoekers worden berekend door hun gedrag op internet te analyseren met behulp van Crypt-technologie. Op basis van deze gegevens kan reclame relevanter worden gemaakt en daarmee de effectiviteit ervan worden vergroot.

Het behalen van doelen en conversies

Het is belangrijk om niet alleen bezoekers naar uw website te halen, maar ook om te begrijpen of zij echte klanten worden. Om dit te doen, moet u doelen instellen in Metrica, dat wil zeggen de belangrijkste acties bepalen die sitebezoekers moeten uitvoeren.

Uw koper kan bijvoorbeeld een bezoeker zijn die:

• klikte op de knop “Toevoegen aan winkelwagen”;
• ging van winkelwagen naar pagina "Bedankt voor uw aankoop" bij het plaatsen van een bestelling;
• minstens twee pagina's van de site bezocht;
• ging naar de pagina met contactgegevens;
• geregistreerd op de site of geabonneerd op de nieuwsbrief.

Als u aangepaste doelen heeft, kunt u begrijpen welke zinnen en advertenties gebruikers naar de site brengen die hun doelen bereiken. U kunt niet alleen de toename van gerichte bezoeken analyseren, maar deze ook optimaliseren met behulp van een van de automatische strategieën: Gemiddelde conversiekosten of Weekbudget. Maximale conversies.

Winst

Eigenaren van online winkels kunnen in Metrica gedetailleerde informatie ontvangen over bestellingen die op de website van de winkel zijn geplaatst. U kunt zien hoeveel geld elke bestelling heeft opgeleverd en via welke kanalen de meest winstgevende bestellingen komen.

Rechtstreeks in de Metrica-interface kunt u snel uw advertentiekosten in Direct schatten. U kunt bijvoorbeeld uw totale advertentiekosten bekijken, de gemiddelde conversiekosten voor al uw advertentiecampagnes achterhalen en de gemiddelde of totale kosten van klikken schatten voor bepaalde typen apparaten, regio's, zoekopdrachten of platforms.

Gerichte oproepen

Klanten bestellen niet alleen via de website, maar ook telefonisch. Dienst "Doeloproep" Hiermee kunt u de effectiviteit van verschillende promotiekanalen vergelijken. U ontvangt speciale telefoonnummers die aan verschillende bronnen kunnen worden gekoppeld, met een detailniveau tot aan individuele advertentiecampagnes. Het nummer op de website en op het virtuele visitekaartje wordt automatisch vervangen, afhankelijk van de bron. Zo kunt u bijhouden waar elke beller over u heeft gehoord.

Hoe u kunt beginnen met het verzamelen van statistieken

Installeer de tellercode op alle pagina's van uw site zo dicht mogelijk bij de bovenkant van de pagina - de volledigheid van de verzamelde gegevens hangt hiervan af. U kunt de juistheid van de tellerinstallatie controleren in de browserconsole.

Als u veel campagnes maakt met dezelfde set tellers, kunt u de tellers opgeven op de pagina met gebruikersinstellingen in het veld Statistiekenteller voor nieuwe campagnes.

Totdat u tellernummers heeft opgegeven, helpt automatische linkmarkering u bij het overbrengen van gegevens tussen Direct en Metrica. Zorg ervoor dat de optie is ingeschakeld in uw campagne-instellingen Markeer links voor Metrica, en uw site opent op de juiste manier links met tags.

Hoe linkmarkering werkt

Aandacht. Als het veld in de campagneparameters niet is ingevuld Metrische tellers en de optie is uitgeschakeld Markeer links voor Metrica, worden gegevens over advertentieklikken niet opgenomen in Metrica, en worden gegevens van Metrica niet opgenomen in Directe statistieken.

Vragen en antwoorden

Hoe snel worden gegevens bijgewerkt in Metrica-rapporten?

De acties van de bezoeker op de site worden binnen enkele minuten weergegeven in de meeste Metrica-rapporten. Gegevens voor speciale rapporten op Direct worden extra geverifieerd, waardoor ze met een vertraging van enkele uren in Metrica terechtkomen.

Hoe snel komen de gegevens over het bereiken van doelen in Direct terecht?

Gegevens over het behalen van een specifiek doel worden binnen 24 uur naar Direct verzonden.

Waarom verschillen de gegevens in Directe statistieken van die in Metrica?

Omdat kwantitatieve methoden zich op andere terreinen hebben bewezen, hebben veel theoretici en praktijkmensen uit de computerwetenschap geprobeerd deze benadering over te brengen op de ontwikkeling van software. Zoals Tom DeMarco zei: “Je hebt geen controle over wat je niet kunt meten.”

Statistieken

De set gebruikte statistieken omvat:

• volgorde van groei (dat wil zeggen de analyse van algoritmen in termen van asymptotische analyse en O-notatie),
• functiepuntanalyse,
• aantal fouten per 1000 regels code,
• mate van codedekking door testen,
• aantal klassen en interfaces,
• softwarepakketstatistieken van Robert Cecil Martin,

Kritiek

Potentiële tekortkomingen van de aanpak die het doelwit zijn van kritiek:

• Onethisch: Er wordt beweerd dat het onethisch is om de prestaties van een programmeur te beoordelen op basis van meetgegevens die zijn geïntroduceerd om de effectiviteit van programmacode te evalueren. Bekende maatstaven als het aantal regels code en de cyclomatische complexiteit geven vaak een oppervlakkig idee van het ‘succes’ van het kiezen van een bepaalde aanpak bij het oplossen van problemen, maar ze worden vaak beschouwd als een hulpmiddel voor het beoordelen van de kwaliteit van het werk van een ontwikkelaar. Deze aanpak leidt vaak tot het tegenovergestelde effect, wat leidt tot het verschijnen van langere constructies en redundante optionele methoden in de code.
• Het vervangen van ‘people management’ door ‘nummermanagement’, waarbij geen rekening wordt gehouden met de ervaring van medewerkers en hun overige kwaliteiten
• Vertekening: Het meetproces kan vertekend zijn doordat werknemers zich bewust zijn van de indicatoren die worden gemeten en deze indicatoren proberen te optimaliseren in plaats van hun prestaties. Als het aantal regels broncode bijvoorbeeld een belangrijke indicator is, zullen programmeurs ernaar streven zoveel mogelijk regels te schrijven en geen codevereenvoudigingstechnieken gebruiken die het aantal regels verminderen.
• Onnauwkeurigheid: Er zijn geen statistieken die zowel betekenisvol als nauwkeurig genoeg zijn. Het aantal regels code is simpelweg het aantal regels; deze indicator geeft geen idee van de complexiteit van het probleem dat wordt opgelost. Functiepuntanalyse is ontwikkeld om de complexiteit van code en specificatie beter te meten, maar maakt gebruik van het persoonlijke oordeel van de meter, zodat verschillende mensen verschillende resultaten zullen krijgen.

Zie ook

• Basiscodestatistieken: LOC, SLOC, Gilb, McCabe, Halstead, OOP en anderen

Wikimedia Stichting.

• 2010.
• Kilometerteller

Stethoscoop

Bekijk wat “Software Metrics” is in andere woordenboeken:

Softwarekwaliteit Schatting van de kosten voor softwareontwikkeling

- Bij het ontwikkelen van software is het probleem van het inschatten van de materiaalkosten en/of de tijd besteed aan de succesvolle afronding van het project erg belangrijk. Er zijn veel methoden om een ​​dergelijke beoordeling uit te voeren, waaronder de algemene... ... Wikipedia Statistieken

- heeft verschillende betekenissen: In de wiskunde is metriek een functie die afstanden in de metrische ruimte bepaalt. Metrisch is een alternatieve naam voor de metrische tensor, in het bijzonder Metrisch van ruimte-tijd 4-tensor, die ... ... Wikipedia- Deze term heeft andere betekenissen, zie Dekking. Codedekking is een maatstaf die wordt gebruikt bij het testen van software. Het toont het percentage waarmee de broncode van het programma is getest. De codedekkingstechniek was... ... Wikipedia

Aantal regels code- Zie ook: Codevolume Broncoderegels SLOC is een softwaremetriek die wordt gebruikt om het volume ervan te meten door het aantal regels in de broncodetekst te tellen. In de regel ... ... Wikipedia

Belasting testen- (Engelse Load Testing) bepaling of verzameling van prestatie-indicatoren en responstijd van een software-hardwaresysteem of apparaat in reactie op een extern verzoek om naleving van de vereisten voor een bepaald systeem vast te stellen ... Wikipedia

Prestatietesten- Dit artikel bevat geen links naar informatiebronnen. Informatie moet verifieerbaar zijn, anders kan deze in twijfel worden getrokken en verwijderd. Je kunt... Wikipedia

Scrummen- Softwareontwikkeling Softwareontwikkelingsproces Processtappen Analyse Ontwerp Programmering Document ... Wikipedia

Cyclomatische complexiteit- programma's (Engels: Cyclomatische complexiteit van een programma) structurele (of topologische) maatstaf voor de complexiteit van programma's, gebruikt om de kwaliteit van software te meten, gebaseerd op methoden voor statische codeanalyse. DSP is gelijk aan ... ... Wikipedia

Zabbix- 1.1 alpha 6 draait onder GNU/Linux... Wikipedia