Čerstvé kolekce materiálů ke stažení! Shromáždili jsme balíčky materiálů k aktuálním tématům, včetně odborných prezentací, webinářů, článků, příkladů implementace atd.
Pro stažení materiálů klikněte na příslušné tlačítko:

Nejznámější a nejpoužívanější normou pro organizaci procesů řízení kvality je řada norem ISO 9000. Pro proces vývoje softwaru se používá norma ISO 9001, která zahrnuje návrh od výroby. Je třeba poznamenat, že tato norma je obtížně použitelná přímo v řízení kvality vývoje softwaru, protože je zpočátku zaměřena na vývoj průmyslových produktů. Speciálně pro podporu procesů vývoje softwarových systémů organizací ISO byla vyvinuta příručka ISO 9000-3, která formuluje požadavky modelu kvality ISO 9001 pro organizaci procesu vývoje softwaru.

Požadavky směrnice ISO 9000-3 tak lze využít k posouzení kvality vývojového procesu ve vlastní organizaci nebo v organizaci dodavatelů. V současné době je všude zaváděna verze standardu 2000, ve které je řízení procesů v popředí, nicméně v této verzi standardu chybí specifika související s vývojem softwaru.

Nevýhodou normy ISO 9000 je obtížnost měření úrovně kvality procesu vývoje softwaru podle navrženého modelu kvality.

Mezi softwarovými vývojáři, zejména v zahraničí (především v USA), je vysoce hodnocen alternativní model kvality: CMM - SEI. Tento model kvality byl vyvinut v Institutu softwarového inženýrství pod záštitou amerického ministerstva obrany. Zpočátku byl tento model kvality používán vládními, zejména vojenskými, organizacemi při zadávání zakázek na vývoj softwaru. Norma je nyní široce používána k analýze a certifikaci procesů vývoje softwaru ve firmách vyrábějících komplexní software v kritických aplikačních oblastech. Důležitými výhodami modelu CMM je hierarchické vnoření modelů kvality, které umožňuje měřit a porovnávat úrovně kvality procesů v různých organizacích a zajistit efektivní zlepšování kvality procesů.

ISO nyní také vyvinula model kvality pro měření a zlepšování kvality.

Modely kvality CMM a ISO jsou v určitém ohledu zaměnitelné, v podstatě si však neodporují, neboť vycházejí ze stejného paradigmatu kvality - TQM - Total Quality Management.

Je důležité si uvědomit, že pouhý proces vývoje softwaru, který splňuje vysokou úroveň kvality, ještě nezaručuje vysokou kvalitu produktu. Kvalitní proces znamená, že kvalita výsledného produktu se bude stále znovu a znovu zlepšovat. Při rozhodování je proto nutné zohlednit dobu, po kterou je instalován a provozován proces požadované úrovně kvality v dané technologické oblasti. Nedostatek informací o kvalitě procesu však znamená, že kvalita vyvíjeného produktu je nepředvídatelná.

Kvalita softwarového produktu

Kvalita softwarových komponent

Vývoj moderních velkých softwarových systémů je nyní stále více založen na vývoji komponent (Component Base System - CBS). Stavební technologie CBS může výrazně snížit náklady a dobu vývoje. Zároveň se zvyšuje riziko spojené s používáním softwarových komponent vyvinutých různými výrobci v systému.

Nejúčinnějším způsobem řešení tohoto problému je použití metrik pro řízení kvality a rizik při budování CBS, aby bylo možné měřit různé faktory ovlivňující konečnou kvalitu produktu a eliminovat zdroje rizik. V tomto případě by měly být metriky kvality použity k podpoře rozhodování v různých fázích životního cyklu vývoje o ekonomické proveditelnosti použití komponent.

Zdrojové kódy komponent jsou zpravidla pro projektanty systému nepřístupné, navíc poskytují komplexní strukturované rozhraní. Důsledkem toho je, že existuje významný rozdíl mezi metrikami, které jsou obvykle použitelné pro tradiční systémy, a metrikami pro CBS. Většina tradičních metrik se používá ve fázi plánování a vývoje. Klíčem k řízení kvality při používání metrik při vývoji komponentových systémů je výběr metrik kvality, které jsou použitelné ve všech fázích životního cyklu a hodnotí jak kvalitu procesu, tak kvalitu produktu.

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.

Vaším kupujícím 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ěkuji za Váš 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 údajů. 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 Direct 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ů

Pozornost. 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?

Zdravím vás přátelé. Po dlouhé fázi vývoje a ještě delším beta testování se nový Yandex Metrica 2.0 vynořuje ze stínu. Od 22. června se stane hlavním nástrojem pro sběr a analýzu statistik, přičemž stará verze bude převedena na subdoménu old.metrika.yandex.ru, kde dožije své poslední měsíce.

Jsem potěšen Yandex Metrika Beta, i když trvalo nějakou dobu, než jsem se do ní ponořil a pochopil její schopnosti. Ale stojí to za to – alespoň jsem pro sebe našel pár věcí, které aktuální verze ani Analytics neumí.

Ve skutečnosti se v tomto materiálu pokusím analyzovat pracovní proces pro vás, sestavit pokyny pro webovou analýzu v novém Yandex Metrici, protože se poněkud liší od svého předchůdce a může způsobit kognitivní disonanci při prvním seznámení.

- Podívejte se tedy na metriku beta.
- Nechci, bojím se jí.

Rozhovor se známým SEO specialistou.

Nejprve tedy koncepční část. Jaký je hlavní rozdíl? Old Metrica je většinou sada hotových řezů (zpráv) pro analýzu. Jejich nastavení a vytváření vlastních řezů je obtížné a nepohodlné. Z tohoto důvodu tento proces pro mnohé spočívá pouze v práci s „Cíly“, které jsou naštěstí určeny k něčemu úplně jinému a „Zprávy“ zůstávají někde tam, na zaprášené polici, mimo závorky.

Ten současný je již plnohodnotnou plastelínou, která vám umožní upravit si naprosto libovolnou sekci podle svých potřeb, nastavit výchozí data, odfiltrovat nepotřebné a vybrat pohodlnou možnost prezentace dat. Kompletně si přizpůsobte svůj pracovní prostor, což ocení zejména internetoví marketéři.

A teď popořadě

V tuto chvíli je beta stále umístěna na https://beta.metrika.yandex.ru/ a pohled na seznam webů nedoznal zásadních změn s výjimkou několika doplňků a zobrazených procent relativního růstu návštěvnosti do předchozího dne, který byl nyní tak pečlivě odstraněn ze staré verze (říkají, pojď, pokračuj, zvykej si).

Nový systém štítků a panel rychlého přístupu jsou velmi pohodlné. Umožňuje vám vytvořit několik značek v panelu definice značek a přiřadit jednu nebo více z nich ke každému webu (ve skutečnosti je zahrnout do skupin těchto značek). Poté výběrem stejnojmenné možnosti na panelu definice štítku zobrazte na panelu rychlého přístupu skupiny, ke kterým přistupujete nejčastěji. Při prohlížení jedné ze skupin se navíc zobrazí souhrnné statistiky návštěvnosti pro stránky v ní zahrnuté.

Jakmile ale přejdete na samostatný pult, můžete se začít ztrácet. Podívejme se na rozhraní.

Nabídka nového rozhraní Yandex Metrika

Položky horního menu netřeba představovat, ale struktura a některé položky levého menu ano. Za prvé, co víme:

• Shrnutí - hlavní stránka počítadla webu.
• Mapy - mapy kliknutí, rolování, odkazů a analýzy formulářů. Obecně platí, že většina obsahu položky "Chování" je stará verze.
• Nastavení - ve skutečnosti nastavení aktuálního počítadla metrik Yandex.

Ale poslední položka – „Zprávy“ – je základním kamenem aktualizovaného nástroje.

• Moje přehledy jsou všechny řezy, které jste vytvořili a uložili.
• Vyvolení jsou to samé, jen vyvolení (probuzení, Neo).
• Standardní zprávy - zde se nacházejí všechny staré a bolestně známé sekce. Vrátíme se k nim později v materiálu.

Rozhraní hlavní stránky čítače

Konstruktor domovské stránky je podobný tomu, co bylo ve starém Yandex Metrici, ale na rozdíl od druhého je ergonomičtější a má působivou sadu hotových widgetů. I zde se projevuje flexibilita nastavení segmentů vlastní nové verzi.

Můžete si vybrat hotový widget z knihovny nebo vytvořit nový: indikátor, koláčový graf, graf nebo datovou tabulku. Přizpůsobte si část informací zobrazených v nich a připněte je do požadované části souhrnné obrazovky pomocí jednoduchého drug&drop.

Práce se segmenty v Yandex Metrica

Dostáváme se tedy k tomu hlavnímu – popisu schématu generování sestav. Nejprve přejdeme do dříve zmíněných standardních reportů („Reports“ - „Standard Report“) a vybereme informace, které budeme následně segmentovat. Například „Zdroje“ - „Zdroje, shrnutí“.

A nyní začneme vybírat pouze ty návštěvy, které chceme analyzovat. Chceme například zjistit počet lidí, kteří navštívili web z tabletu z vyhledávače Yandex na dotaz, který obsahoval slovo „SEO“. Za tímto účelem jsme nastavili tři úrovně segmentace:

• "Segment" - "Technologie" - "Zařízení" - v okně možností, které se otevře, vyberte "Tablety".
• "Segment" - "Zdroje" - "Poslední zdroj" - "Hledat" - "Vyhledávač" - v okně možností, které se otevře, vyberte "Yandex".
• "Segment" - "Zdroje" - "Poslední zdroj" - "Hledat" - "Hledaná fráze" - v okně, které se otevře, zadejte *SEO* (hvězdičkové operátory označují libovolnou sadu znaků na obou stranách tohoto slova).

Celkem: grafy a tabulka s informacemi budou uspořádány tak, jak potřebujeme, připraveny ke stažení nebo analýze. Za běhu můžete měnit, odstraňovat nebo přidávat nové úrovně upřesnění – zobrazené informace se budou průběžně aktualizovat.

Zde můžeme výsledný segment porovnat s jiným pomocí nástroje „Porovnat segmenty“ - „Ručně zadané“. Nemůžeme však změnit složení segmentu, ale jednoduše porovnat několik období jednoho řezu pomocí možnosti „Předchozí období“.

Ani zde se nezapomnělo na staré dobré „Goals“, které můžeme použít jako další upřesňující parametr pro konstrukci segmentu.

Počet možností konstrukce segmentů je prakticky neomezený. Dále můžeme analyzovat přijaté informace a zapomenout na výběr, nebo je uložit a přistupovat k nim později z nabídky „Reports“ - „My Reports“ nebo jednoduše nahrát data.

Metriky Webvisor Yandex

Výše uvedený proces segmentace se pro tento nástroj velmi hodil. Výběr záznamů návštěv zájmových skupin uživatelů je ještě jednodušší. Postup je stejný - přejděte na „Webvisor“, nastavte segment (nebo jej načtěte z uložených) a podívejte se.

Tímto tuto recenzi-návod končím a jako vždy se těším na vaše dotazy v komentářích.

anotace

Článek poskytuje přehled 7 tříd metrik a více než 50 jejich zástupců, poskytuje podrobný popis a použité výpočetní algoritmy a popisuje roli metrik ve vývoji softwaru.

Úvod

Článek je první fází práce provedené společností Software Verification Systems LLC s cílem vytvořit nové specializované nástroje pro výpočet metrik. Jde o přehled existujících metrik, které vám pomohou systematicky přistupovat k řešení řady problémů. Plánuje se vyvinout metodiku pro hodnocení složitosti portování softwaru na jiné platformy a také pro posouzení složitosti paralelizace programového kódu. Tímto směrem je rozvoj schopností produktu PVS-Studio nejen jako statického analyzátoru, ale také jako nástroje pro predikci mzdových nákladů programátorů při zvládnutí 64bitových systémů a přizpůsobení algoritmů vícejádrovým systémům.

Tento článek představí širokou škálu softwarových metrik. Samozřejmě není radno uvádět všechny existující metriky, většina z nich se v praxi nikdy nepoužívá, ať už z důvodu nemožnosti dalšího využití výsledků, nemožnosti automatizace měření či úzké specializace těchto měření. metriky, ale existují metriky, které se používají poměrně často a jejich přehled bude uveden níže.

Obecně platí, že použití metrik umožňuje projektovým a podnikovým manažerům studovat složitost vyvíjeného nebo dokonce rozpracovaného projektu, hodnotit množství práce, styl vyvíjeného programu a úsilí vynaložené každým vývojářem na implementaci konkrétního řešení. . Metriky však mohou sloužit pouze jako doporučující charakteristiky, nelze je zcela řídit, protože při vývoji softwaru se programátoři, kteří se snaží minimalizovat nebo maximalizovat to či ono opatření pro svůj program, mohou uchýlit k trikům, a dokonce snížit efektivitu programu. Navíc, pokud například programátor napsal malý počet řádků kódu nebo provedl malý počet strukturálních změn, neznamená to, že neudělal nic, ale může to znamenat, že se vada programu hledala velmi obtížně. Poslední problém lze ale částečně vyřešit použitím metrik složitosti, protože ve složitějším programu se chyba hledá obtížněji.

1. Kvantitativní metriky

Nejprve bychom měli zvážit kvantitativní charakteristiky zdrojového kódu programů (kvůli jejich jednoduchosti). Nejzákladnější metrikou je počet řádků kódu (SLOC). Tato metrika byla původně vyvinuta pro odhad nákladů práce na projektu. Protože však lze stejnou funkcionalitu rozdělit na více řádků nebo napsat na jeden řádek, stala se metrika s příchodem jazyků, které dokážou napsat více než jeden příkaz na jeden řádek, prakticky nepoužitelná. Proto se rozlišuje mezi logickými a fyzickými řádky kódu. Logické řádky kódu představují počet příkazů v programu. Tato možnost popisu má také své nevýhody, protože silně závisí na použitém programovacím jazyce a stylu programování.

Kromě SLOC kvantitativní charakteristiky také zahrnují:

počet prázdných řádků,

počet komentářů,

procento komentářů (poměr počtu řádků obsahujících komentáře k celkovému počtu řádků, vyjádřený v procentech),

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řídy, soubory),

průměrný počet řádků pro moduly.

Někdy se navíc rozlišuje mezi stylistickým hodnocením programu (F). Spočívá v rozdělení programu na n stejných fragmentů a výpočtu skóre pro každý fragment pomocí vzorce Fi = SIGN (Ncomm.i / Ni - 0,1), kde Ncomm.i je počet komentářů v i-tém fragmentu, Ni je celkový počet řádků kódu v i-tém fragmentu. Poté bude celkové skóre za celý program určeno následovně: F = SUMFi.

Do skupiny metrik založených na počítání určitých jednotek v kódu programu jsou také zahrnuty Halsteadovy metriky. Tyto metriky jsou založeny na následujících ukazatelích:

n1 - počet jedinečných programových příkazů včetně symbolů

oddělovače, názvy procedur a operační znaky (slovník operátorů),

n2 - počet jedinečných programových operandů (slovník operandů),

N1 - celkový počet výpisů v programu,

N2 - celkový počet operandů v programu,

n1" - teoretický počet unikátních operátorů,

n2" je teoretický počet jedinečných operandů.

Vezmeme-li v úvahu zavedené zápisy, můžeme určit:

n=n1+n2 - programový slovník,

N=N1+N2 - délka programu,

n"=n1"+n2" - teoretický slovník programu,

N"= n1*log2 (n1) + n2*log2 (n2) - teoretická délka programu (u stylově správných programů nepřesahuje odchylka N od N" 10%)

V=N*log2 n - objem programu,

V"=N"*log2 n" je teoretický objem programu, kde n* je teoretický slovník programu.

L=V"/V - úroveň kvality programování, pro ideální program L=1

L"= (2 n2)/ (n1*N2) - úroveň kvality programování, založená pouze na parametrech skutečného programu bez zohlednění teoretických parametrů,

EC =V/(L")2 - potíže s porozuměním programu,

D=1/ L" - složitost programového kódování,

y" = V/ D2 - jazyková úroveň vyjadřování

I=V/D - informační obsah programu, tato charakteristika umožňuje určit mentální náklady na tvorbu programu

E=N" * log2 (n/L) - posouzení potřebného intelektuálního úsilí při vývoji programu, charakterizující počet požadovaných elementárních řešení při psaní programu

Při použití Halsteadových metrik jsou částečně kompenzovány nevýhody spojené s možností zaznamenat stejnou funkcionalitu s jiným počtem řádků a operátorů.

Dalším typem softwarových metrik, které jsou kvantitativní, jsou Gilbovy metriky. Ukazují složitost softwaru na základě hustoty podmíněných příkazů nebo cyklických příkazů. Tato metrika i přes svou jednoduchost poměrně dobře odráží složitost psaní a porozumění programu a při přidání takového ukazatele, jako je maximální úroveň vnoření podmíněných a cyklických příkazů, se účinnost této metriky výrazně zvyšuje.

2. Metriky složitosti toku řízení programu

Další velká třída metrik, která není založena na kvantitativních ukazatelích, ale na analýze grafu řízení programu, se nazývá metriky složitosti toku řízení programu.

Před přímým popisem samotných metrik bude pro lepší pochopení popsán řídicí graf programu a způsob jeho sestavení.

Nechte si představit nějaký program. Pro tento program je zkonstruován orientovaný graf obsahující pouze jeden vstup a jeden výstup, přičemž vrcholy grafu jsou korelovány s těmi sekcemi programového kódu, ve kterých jsou pouze sekvenční výpočty a neexistují žádné operátory větví a smyček, a oblouky jsou korelovány s přechody z bloku do bloku a větvemi provádění programu. Podmínka pro sestavení tohoto grafu: každý vrchol je dosažitelný z počátečního vrcholu a konečný vrchol je dosažitelný z jakéhokoli jiného vrcholu.

Nejběžnějším odhadem na základě analýzy výsledného grafu je cyklomatická složitost programu (McCabeho cyklomatické číslo). Je definován jako V(G)=e - n + 2p, kde e je počet oblouků, n je počet vrcholů, p je počet spojených komponent. Počet propojených komponent grafu lze chápat jako počet oblouků, které je třeba přidat, aby se graf přeměnil na silně propojený. Graf se nazývá silně souvislý, pokud jsou libovolné dva vrcholy vzájemně dosažitelné. U grafů správných programů, tj. grafů, které nemají části nedosažitelné ze vstupního bodu a „visící“ vstupní a výstupní body, se obvykle získá silně propojený graf uzavřením oblouku z vrcholu označujícího konec programu k vrcholu. označující vstupní bod do tohoto programu. V(G) v podstatě určuje počet lineárně nezávislých obvodů v silně spojeném grafu. Takže ve správně napsaných programech p=1, a proto vzorec pro výpočet cyklomatické složitosti má tvar:

Bohužel toto hodnocení není schopno rozlišit mezi cyklickými a podmíněnými strukturami. Další významnou nevýhodou tohoto přístupu je, že programy reprezentované stejnými grafy mohou mít predikáty zcela odlišné složitosti (predikát je logický výraz obsahující alespoň jednu proměnnou).

K nápravě tohoto nedostatku vyvinul G. Myers novou techniku. Jako odhad navrhl vzít interval (tento odhad se také nazývá interval), kde h pro jednoduché predikáty je rovno nule a pro n-ární predikáty h = n-1. Tato metoda umožňuje rozlišit predikáty různé složitosti, ale v praxi se téměř nepoužívá.

Další modifikací McCabeovy metody je Hansenova metoda. Míra složitosti programu je v tomto případě reprezentována jako dvojice (cyklomatická složitost, počet příkazů). Výhodou tohoto opatření je jeho citlivost na strukturu softwaru.

Chenova topologická míra vyjadřuje složitost programu z hlediska počtu přechodů hranic mezi regiony tvořenými grafem programu. Tento přístup je použitelný pouze pro strukturované programy, které umožňují pouze sekvenční připojení řídicích struktur. U nestrukturovaných programů závisí míra Chen výrazně na podmíněných a nepodmíněných větvích. V tomto případě můžete určit horní a dolní hranici míry. Horní je m+1, kde m je počet logických operátorů s jejich vzájemným vnořením. Spodní se rovná 2. Pokud má řídicí graf programu pouze jednu připojenou složku, Chenova míra se shoduje s McCabeovou cyklomatickou mírou.

V návaznosti na téma analýzy kontrolního grafu programu můžeme rozlišit další podskupinu metrik - Harrisonovy a Majelovy metriky.

Tato opatření zohledňují úroveň investic a délku programu.

Každému vrcholu je přiřazena vlastní složitost podle operátora, který reprezentuje. Tuto počáteční složitost vrcholu lze vypočítat jakýmkoli způsobem, včetně použití Halsteadových mír. Pro každý predikátový vrchol vybereme podgraf generovaný vrcholy, které jsou konci oblouků z něj vycházejících, dále vrcholy dosažitelné z každého takového vrcholu (spodní hranice podgrafu) a vrcholy ležící na cestách od vrcholu predikátu k nějaké spodní hranici. Tento podgraf se nazývá sféra vlivu predikátového vrcholu.

Snížená složitost predikátového vrcholu je součtem počáteční nebo snížené složitosti vrcholů zahrnutých do jeho sféry vlivu plus primární složitost samotného predikátového vrcholu.

Funkční míra (SCOPE) programu je součtem redukovaných složitostí všech vrcholů řídicího grafu.

Funkční vztah (SCORT) je poměr počtu vrcholů v řídicím grafu k jeho funkční složitosti a koncové vrcholy jsou vyloučeny z počtu vrcholů.

SCORT může nabývat různých hodnot pro grafy se stejným cyklomatickým číslem.

Pivovarského metrika je další modifikací míry cyklomatické složitosti. Umožňuje sledovat rozdíly nejen mezi sekvenčními a vnořenými řídicími strukturami, ale také mezi strukturovanými a nestrukturovanými programy. Vyjadřuje se vztahem N(G) = v *(G) + SUMAPi, kde v *(G) je modifikovaná cyklomatická složitost, vypočtená stejně jako V(G), ale s jedním rozdílem: výrok CASE s n výstupy je považováno spíše za jeden logický operátor než za n - 1 operátorů.

Pi je hloubka vnoření i-tého predikátového vrcholu. Pro výpočet hloubky vnoření predikátových vrcholů se používá počet „sfér vlivu“. Hloubkou vnoření se rozumí počet všech „sfér vlivu“ predikátů, které jsou buď zcela obsaženy ve sféře daného vrcholu, nebo se s ní protínají. Hloubka vnoření se zvyšuje v důsledku vnořování nikoli samotných predikátů, ale „sfér vlivu“. Pivovarského opatření se zvyšuje při přechodu ze sekvenčních programů na vnořené a následně na nestrukturované, což je jeho obrovská výhoda oproti mnoha dalším opatřením této skupiny.

Woodwardova míra - počet průsečíků oblouků řídicího grafu. Protože by takové situace neměly nastat v dobře strukturovaném programu, používá se tato metrika hlavně ve slabě strukturovaných jazycích (Assembler, Fortran). Průsečík nastane, když řízení překročí dva vrcholy, které jsou sekvenční operátory.

Metoda okrajových hodnot je také založena na analýze regulačního grafu programu. Pro definování této metody je nutné zavést několik dalších pojmů.

Nechť G je řídicí graf programu s jedním počátečním a jedním konečným vrcholem.

V tomto grafu se počet přicházejících vrcholů oblouků nazývá záporný stupeň vrcholu a počet oblouků vycházejících z vrcholu se nazývá kladný stupeň vrcholu. Potom lze množinu vrcholů grafu rozdělit do dvou skupin: vrcholy s kladným stupněm<=1; вершины, у которых положительная степень >=2.

Vrcholy první skupiny budeme nazývat přijímací vrcholy a vrcholy druhé skupiny – výběrové vrcholy.

Každý přijímající vertex má sníženou složitost 1, kromě koncového vertexu, který má sníženou složitost 0. Snížené složitosti všech vertexů v G jsou sečteny a tvoří absolutní hraniční složitost programu. Poté se určí relativní okrajová složitost programu:

kde S0 je relativní mezní složitost programu, Sa je absolutní mezní složitost programu, v je celkový počet vrcholů grafu programu.

Existuje metrika Schneidewind, vyjádřená počtem možných cest v kontrolním grafu.

3. Metriky složitosti toku dat

Další třídou metrik jsou metriky složitosti toku řízení dat.

Chapinova metrika: 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 4 funkčních skupin:

1. P - vstupní proměnné pro výpočty a pro poskytování výstupu,

2. M - proměnné upravené nebo vytvořené v programu,

3. C - proměnné podílející se na řízení provozu softwarového modulu (řídící proměnné),

Protože každá proměnná může vykonávat několik funkcí současně, musí být uvažována v každé odpovídající funkční skupině.

Chapinova metrika:

Q = a1*P + a2*M + a3*C + a4*T,

kde a1, a2, a3, a4 jsou váhové koeficienty.

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

Metrika rozpětí je založena na lokalizaci datových přístupů v každé části programu. Spen je počet příkazů obsahujících daný identifikátor mezi jeho prvním a posledním výskytem v textu programu. Proto identifikátor, který se objeví nkrát, má rozsah n-1. S velkým rozsahem je testování a ladění složitější.

Další metrikou, která bere v úvahu složitost toku dat, je metrika, která dává do souvislosti složitost programů s přístupy ke globálním proměnným.

Dvojice modul-globální proměnná je označena (p,r), kde p je modul, který má přístup ke globální proměnné r. V závislosti na tom, zda program skutečně přistupuje k proměnné r, se tvoří dva typy dvojic „modul - globální proměnná“: aktuální a možné. Možný odkaz na r pomocí p ukazuje, že doména existence r zahrnuje p.

Tato charakteristika je označena Aup a udává, kolikrát moduly Up skutečně přistoupily ke globálním proměnným, a číslo Pup udává, kolikrát k nim mohly přistupovat.

Stanoví se poměr počtu skutečných hovorů k možným

Tento vzorec ukazuje přibližnou pravděpodobnost, že libovolný modul odkazuje na libovolnou globální proměnnou. Je zřejmé, že čím vyšší je tato pravděpodobnost, tím vyšší je pravděpodobnost „neoprávněné“ změny jakékoli proměnné, což může výrazně zkomplikovat práci spojenou s úpravou programu.

Opatření Kafur bylo vytvořeno na základě konceptu informačních toků. Pro použití tohoto opatření jsou zavedeny koncepty místního a globálního toku: místní tok informací z A do B existuje, pokud:

1. Modul A volá modul B (přímé místní vlákno)

2. Modul B volá modul A a A vrací B hodnotu, která se používá v B (nepřímý místní tok)

3. Modul C volá moduly A, B a přenáší výsledek modulu A do B.

Dále bychom měli uvést koncept globálního toku informací: globální tok informací z A do B prostřednictvím globální datové struktury D existuje, pokud modul A vkládá informace do D a modul B používá informace z D.

Na základě těchto pojmů je zavedena hodnota I - informační složitost postupu:
I = délka * (fan_in * fan_out)2
Tady:

délka - složitost textu procedury (měřeno pomocí jedné z objemových metrik, jako jsou Halstead, McCabe, LOC metriky atd.)

fan_in - počet lokálních vláken vstupujících do procedury plus počet datových struktur, ze kterých procedura bere informace

fan_out - počet lokálních vláken pocházejících z procedury plus počet datových struktur, které jsou procedurou aktualizovány

Informační složitost modulu lze definovat jako součet informačních složitostí v něm obsažených procedur.

Dalším krokem je zvážení informační složitosti modulu vzhledem k nějaké datové struktuře. Informační míra složitosti modulu vzhledem k datové struktuře:

J = W * R + W * RW + RW *R + RW * (RW - 1)

W je počet procedur, které pouze aktualizují datovou strukturu;

R - pouze číst informace z datové struktury;

RW - čte i aktualizuje informace v datové struktuře.

Dalším opatřením v této skupině je opatření Oviedo. Jeho podstatou je, že program je rozdělen na lineární neprotínající se úseky - paprsky operátorů, které tvoří řídící graf programu.

Autor metriky vychází z následujících předpokladů: programátor může najít vztah mezi definicí a použitím výskytů proměnné v paprsku snadněji než mezi paprsky; Počet odlišných definujících výskytů v každém paprsku je důležitější než celkový počet použití proměnných výskytů v každém paprsku.

Označme R(i) množinu definujících výskytů proměnných, které se nacházejí v akčním poloměru paprsku i (definující výskyt proměnné je v akčním poloměru paprsku, pokud je v něm proměnná buď lokální). a má určující výskyt, nebo pro něj existuje určující výskyt v některém předchozím paprsku a podél cesty neexistuje žádná lokální definice). Označme V(i) množinu proměnných, jejichž výskyty jsou již v paprsku i. Pak je míra složitosti i-tého paprsku dána jako:

DF(i)=SUM(DEF(vj )), j=i...||V(i)||

kde DEF(vj) je počet definujících výskytů proměnné vj z množiny R(i) a ||V(i)|| - výkon množiny V(i).

4. Metriky toku řízení a složitosti programových dat

Čtvrtá třída metrik jsou metriky, které jsou blízké jak třídě kvantitativních metrik, třídě metriky složitosti toku řízení programu, tak třídě metriky složitosti toku řízení dat (přesně řečeno, tato třída metrik a třída metriky řízení programu metriky složitosti toku jsou stejné třídy – topologické metriky, ale má smysl je v tomto kontextu pro přehlednost oddělit). Tato třída metrik stanovuje složitost struktury programu jak na základě kvantitativních výpočtů, tak na základě analýzy řídicích struktur.

První z těchto metrik je testovací M-Measure. Testovací míra M je míra složitosti, která splňuje následující podmínky:

Míra se zvyšuje s hloubkou vnoření a zohledňuje délku programu. S testovacím opatřením úzce souvisí opatření založené na pravidelném vkládání. Myšlenkou tohoto měřítka složitosti programu je spočítat celkový počet znaků (operandů, operátorů, závorek) v regulárním výrazu s minimálním požadovaným počtem závorek popisujících řídicí graf programu. Všechna opatření v této skupině jsou citlivá na vnoření řídicích struktur a délku programu. Zvyšuje se však výpočetní náročnost.

Měřítkem kvality softwaru je také koherence programových modulů. Pokud jsou moduly těsně propojeny, pak se program stává obtížně modifikovatelným a obtížně pochopitelným. Tato míra není vyjádřena číselně. Typy připojení modulu:

Datová konektivita - pokud moduly interagují prostřednictvím přenosu parametrů a každý parametr je elementárním informačním objektem. Toto je nejpreferovanější typ připojení (spojka).

Propojenost datovou strukturou - pokud jeden modul posílá druhému složený informační objekt (strukturu) pro výměnu dat.

Řídicí vazba - pokud jeden posílá druhému informační objekt - příznak určený k řízení jeho vnitřní logiky.

Moduly jsou propojeny společnou oblastí, pokud odkazují na stejnou globální datovou oblast. Spojení přes globální rozsah je nežádoucí, protože za prvé se chyba v modulu, který používá globální rozsah, může neočekávaně objevit v jakémkoli jiném modulu; za druhé, takovým programům je obtížné porozumět, protože pro programátora je obtížné určit, jaká data konkrétní modul používá.

Soudržnost podle obsahu – pokud jeden z modulů navazuje na jiný. Jedná se o nepřijatelný typ spojky, neboť zcela odporuje principu modularity, tzn. znázornění modulu jako černé skříňky.

Externí vazba - dva moduly sdílejí externí data, jako je komunikační protokol.

Konektivita pomocí zpráv je nejvolnější typ konektivity, moduly nejsou vzájemně přímo propojeny, komunikují prostřednictvím zpráv, které nemají parametry.

Chybějící spojení – moduly spolu neinteragují.

Spojování podtříd je vztah mezi nadřazenou třídou a podřízenou třídou, kde dítě souvisí s rodičem, ale rodič není příbuzný s potomkem.

Časová souvislost - dvě akce jsou seskupeny do jednoho modulu pouze proto, že se vlivem okolností vyskytují ve stejnou dobu.

Dalším opatřením souvisejícím se stabilitou modulu je opatření Colofello, které lze definovat jako počet změn, které je třeba provést v jiných modulech, než je modul, jehož stabilita se kontroluje, a tyto změny se musí týkat právě testovaného modulu. .

Další metrikou z této třídy je McClureova metrika. Výpočet této metriky má tři fáze:

1. Pro každou řídicí proměnnou i se vypočítá hodnota její funkce složitosti C(i) pomocí vzorce: C(i) = (D(i) * J(i))/n.

Kde D(i) je hodnota, která měří rozsah proměnné i. J(i) je mírou složitosti interakce modulů prostřednictvím proměnné i, n je počet jednotlivých modulů v rozdělovacím schématu.

2. Pro všechny moduly zahrnuté v rozdělovací sféře je hodnota jejich funkcí složitosti M(P) určena vzorcem M(P) = fp * X(P) + gp * Y(P)
kde fp a gp jsou v tomto pořadí počet modulů bezprostředně předcházejících a bezprostředně následujících modulů P, X(P) je složitost přístupu k modulu P,

Y(P) - složitost ovládání volání z modulu P jiných modulů.

3. Celková složitost hierarchického schématu MP pro rozdělení programu do modulů je dána vzorcem:

MP = SUM(M(P)) přes všechny možné hodnoty P - programových modulů.

Tato metrika se zaměřuje na programy, které jsou dobře strukturované, složené z hierarchických modulů, které definují funkční specifikaci a strukturu řízení. Rovněž se předpokládá, že každý modul má jeden vstupní bod a jeden výstupní bod, modul vykonává právě jednu funkci a moduly jsou volány v souladu s hierarchickým řídicím systémem, který specifikuje vztah volání na více programových modulech.

Existuje také metrika založená na informačním konceptu, Berlingerova míra. Míra složitosti se vypočítá jako M=SUMfi *log2 pi, kde fi je četnost výskytu i-tého symbolu, pi je pravděpodobnost jeho výskytu.

Nevýhodou této metriky je, že program obsahující mnoho jedinečných znaků, ale v malém množství, bude mít stejnou složitost jako program obsahující malý počet jedinečných znaků, ale ve velkém množství.

5. Objektově orientované metriky

S rozvojem objektově orientovaných programovacích jazyků se objevila nová třída metrik, nazývaná také objektově orientovaná metrika. V této skupině se nejčastěji používá sada metrik Martin a sada metrik Chidamber a Kemerer. Nejprve se podívejme na první podskupinu.

Než začneme uvažovat o Martinových metrikách, je nutné představit koncept kategorie třídy. Ve skutečnosti lze třídu zřídka znovu použít izolovaně od ostatních tříd. Téměř každá třída má skupinu tříd, se kterou spolupracuje a od které ji nelze snadno oddělit. Chcete-li takové třídy znovu použít, musíte znovu použít celou skupinu tříd. Taková skupina tříd je silně propojena a nazývá se kategorie tříd. Pro existenci kategorie třídy platí následující podmínky:

Třídy v rámci kategorie třídy jsou zapečetěny před jakýmkoli pokusem je všechny společně změnit. To znamená, že pokud by se jedna třída změnila, pravděpodobně by se změnily všechny třídy v této kategorii. Pokud je některá ze tříd otevřená nějakému druhu změny, všechny jsou tomuto druhu změny otevřené.

Třídy v kategorii jsou znovu použity pouze společně. Jsou na sobě tak závislé a nelze je od sebe oddělit. Pokud tedy dojde k jakémukoli pokusu o opětovné použití jedné třídy v kategorii, musí být s ní znovu použity všechny ostatní třídy.

Odpovědnost, nezávislost a stabilita kategorie může být měřena počítáním závislostí, které s danou kategorií interagují. Lze definovat tři metriky:

1. Ca: Centripetální soudržnost. Počet tříd mimo tuto kategorii, které závisí na třídách v této kategorii.

2. Ce: Odstředivá spojka. Počet tříd v této kategorii, které závisí na třídách mimo tuto kategorii.

3. I: Nestabilita: I = Ce / (Ca+Ce). Tato metrika má rozsah hodnot.

I = 0 označuje nejstabilnější kategorii.

I = 1 označuje nejnestabilnější kategorii.

Metriku, která měří abstraktnost kategorie (pokud je kategorie abstraktní, je dostatečně flexibilní a lze ji snadno rozšířit), můžete definovat následovně:

A: Abstraktnost: A = nA / nAll.

nA - počet_abstraktních_tříd_v_kategorii.

nAll - celkový_počet_tříd_v_kategorii.

Hodnoty této metriky se liší v rozsahu.

Nyní můžete na základě výše uvedených Martinových metrik sestavit graf, který ukazuje vztah mezi abstrakcí a nestabilitou. Pokud na ní sestrojíme přímku, danou vzorcem I+A=1, pak tato přímka bude obsahovat kategorie, které mají nejlepší rovnováhu mezi abstrakcí a nestabilitou. Tento řádek se nazývá hlavní posloupnost.

Vzdálenost k hlavní sekvenci: D=|(A+I-1)/sqrt(2)|

Normalizovaná vzdálenost k hlavní sekvenci: Dn=|A+I-2|

Téměř pro každou kategorii platí, že čím blíže k hlavní sekvenci, tím lépe.

Další podskupinou metrik jsou Chidamberovy a Kemererovy metriky. Tyto metriky jsou založeny na analýze metod tříd, stromu dědičnosti atd.

WMC (Weighted methods per class), celková složitost všech metod třídy: WMC=SUMci , i=1...n, kde ci je složitost i-té metody, vypočítaná kteroukoli z metrik (Halstead atd., v závislosti na kritériu zájmu), pokud mají všechny metody stejnou složitost, pak WMC=n.

DIT (Depth of Inheritance tree) - hloubka stromu dědičnosti (nejdelší cesta po hierarchii tříd k dané třídě z třídy předků), čím větší, tím lepší, protože s větší hloubkou se zvyšuje abstrakce dat, saturace třída s metodami klesá, ale s dostatečně velkou S hloubkou se složitost porozumění a psaní programu velmi zvyšuje.

NOC (Number of children) - počet potomků (okamžité), čím více, tím vyšší abstrakce dat.

CBO (Coupling between object Classes) - vazba mezi třídami, ukazuje počet tříd, ke kterým je původní třída přidružena. Pro tuto metriku jsou platná všechna dříve uvedená tvrzení pro konektivitu modulů, to znamená, že s vysokým CBO klesá abstrakce dat a opětovné použití tříd je obtížnější.

RFC (Response for a class) - RFC=|RS|, kde RS je sada odpovědí třídy, tj. sada metod, které mohou být potenciálně volány metodou třídy v reakci na data přijatá objektem třída. To znamená, že RS=(((M)((Ri)), i=1...n, kde M jsou všechny možné metody třídy, Ri jsou všechny možné metody, které lze volat i-tou třídou. Pak bude RFC silou dané sady. Čím více RFC, tím obtížnější je testování a ladění.

LCOM (Lack of Kohesion in Methods) - nedostatek soudržnosti metod. K určení tohoto parametru uvažujme třídu C s n metodami M1, M2, ... ,Mn, pak (I1), (I2), ..., (In) jsou sady proměnných používaných v těchto metodách. Nyní definujeme P - množinu dvojic metod, které nemají společné proměnné; Q je sada dvojic metod, které mají společné proměnné. Pak LCOM=|P|-|Q|. Nedostatek soudržnosti může být signálem, že třídu lze rozdělit na několik dalších tříd nebo podtříd, takže je lepší zvýšit soudržnost, aby se zvýšilo zapouzdření dat a snížila se složitost tříd a metod.

6. Metriky spolehlivosti

Dalším typem metrik jsou metriky, které jsou blízké kvantitativním, ale založené na počtu chyb a defektů v programu. Nemá smysl uvažovat o vlastnostech každé z těchto metrik, postačí je jednoduše vyjmenovat: počet strukturálních změn provedených od poslední kontroly, počet chyb zjištěných během kontroly kódu, počet chyb zjištěných během programu testování a počet nezbytných strukturálních změn nutných pro správné fungování programu. U velkých projektů jsou tyto ukazatele obvykle uvažovány ve vztahu k tisícům řádků kódu, tzn. průměrný počet defektů na tisíc řádků kódu.

7. Hybridní metriky

Na závěr je nutné zmínit ještě jednu třídu metrik nazývanou hybridní. Metriky této třídy jsou založeny na jednodušších metrikách a představují jejich vážený součet. Prvním zástupcem této třídy je Kokolova metrika. Je definován následovně:

H_M = (M + R1 * M(M1) + ... + Rn * M(Mn)/(1 + R1 + ... + Rn)

Kde M je základní metrika, Mi jsou další zajímavé míry, Ri jsou správně zvolené koeficienty, M(Mi) jsou funkce.

Funkce M(Mi) a koeficienty Ri jsou vypočítány pomocí regresní analýzy nebo programově specifické analýzy problému.

Metrika Zolnovsky, Simmons, Thayer je také váženým součtem různých ukazatelů. Pro tuto metriku existují dvě možnosti:

(struktura, interakce, objem, data) SUM(a, b, c, d).

(složitost rozhraní, výpočetní složitost, I/O složitost, čitelnost) SUM(x, y, z, p).

Metriky použité v každé možnosti se vybírají v závislosti na konkrétní úloze, koeficienty - v závislosti na hodnotě metriky pro rozhodování v tomto případě.

Závěr

Abych to shrnul, rád bych poznamenal, že neexistuje jediná univerzální metrika. Případné sledované metrické charakteristiky programu je nutné sledovat buď v závislosti na sobě, nebo v závislosti na konkrétní úloze, navíc lze použít hybridní míry, které však závisí i na jednodušších metrikách a také nemohou být univerzální. Přísně vzato, jakákoliv metrika je pouze indikátorem, který silně závisí na jazyku a stylu programování, takže žádné měřítko nelze povýšit na absolutní a nelze se pouze na něm rozhodovat.

Bibliografie

• Záznam blogu CProVer: "Náš praktický výzkum v oblasti výpočtu metrik."
• Koncept metrik. Pokyny pro používání metrik.
  Metrické stupnice. Metriky obtížnosti. Stylistické metriky. http://www.met-rix.narod.ru/
• T.J. McCabe, "A complexity measurement," IEEE Transactions on Software Engineering, sv. SE-2, č. 4, str. 308-320, prosinec 1976.
• Bogdanov D.V., "Standardizace životního cyklu softwaru", Petrohrad - 2000, 210 s.
• G.N. Kaljanov. Poradenství pro podnikovou automatizaci: vědecká a praktická publikace. Cyklus "Informatizace Ruska na prahu 21. století." - M.: SINTEG, 1997. - 320 s.
• Chernonozhkin S.K., "Metody a nástroje pro metrickou podporu pro vývoj programů kvality", abstrakt, Novosibirsk - 1998
• Curtis R. Cook, "Metrika informační teorie pro jazyk symbolických instrukcí"
• Shyam R. Chidamber, Chris F. Kemerer, "Metrics Suite for Object Oriented Design", 1994

Č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 ladění a podpory 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 počítají 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:

1. 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).
   
2. 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. Pokud 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 sekce bude trvat nejdelší dobu a bude generovat nejvíce chyb kvůli složitosti úlohy. 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ž svůj vlastní 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ím, je hloupé počítat náklady práce pomocí této metriky - je nutné komplexní posouzení...

2.2 Metriky obtížnosti

Kromě indikátorů pro hodnocení objemu práce na projektu jsou pro získání objektivních hodnocení projektu velmi důležité indikátory 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 indikují 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 řídicího toku programu a je vypočítáván na základě grafu řídicí logiky programu (control flow graph). 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 okruhů těsně propojené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ů Nprog programu:

Nprogn = NF*jednotka

Kde: NF – počet funkcí nebo požadavků ve specifikaci požadavků na vyvíjený program;
Ned – jediná 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.