Сучасна програмна промисловість за півстоліття пошуків накопичила значну колекцію моделей і метрик, що оцінюють окремі виробничі та експлуатаційні характеристики ПЗ. Однак гонитва за їх універсальністю, неврахування області застосування ПЗ, ігнорування етапів життєвого циклу програмного забезпечення і, нарешті, необґрунтоване їх використання в різнопланових процедурах прийняття виробничих рішень, істотно підірвало до них довіру розробників і користувачів ПЗ.

Тим не менш, аналіз технологічного досвіду лідерів виробництва ПЗ показує, наскільки дорого обходиться недосконалість ненаукового прогнозу розв'язності та трудовитрат, складності програм, негнучкість контролю та управління їх розробкою та багато іншого, що вказує на відсутність наскрізної методичної підтримки і що призводить до його невідповідності вимогам користувача, необхідному стандарту та до подальшої хворобливої ​​та трудомісткої його переробки. Ці обставини вимагають ретельного відбору методик, моделей, методів оцінки якості ПЗ, обліку обмежень їх придатності для різних життєвих циклів і в межах життєвого циклу, встановлення порядку їх спільного використання, застосування надлишкового різномодельного дослідження тих самих показників для підвищення достовірності поточних оцінок, накопичення та інтеграції різнорідної метричної інформації для прийняття своєчасних виробничих рішень та заключної сертифікації продукції.

Нижче, у таблиці 1.3., наведено моделі та метрики, які добре зарекомендували себе при оцінці якості ПЗ, придатні для прогнозування та констатації різних показників складності та надійності програм.

Таблиця 1.3.

Назва моделі	Формула, позначення
МЕТРИКИ СКЛАДНОСТІ
Метрики Холстеда Довжина програми; Обсяг програми Оцінка її реалізації; Складність її розуміння; Трудомісткість кодування; рівень мови вираження; Інформаційний зміст; Оптимальна модульність;	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
Метрики Джилба Кількість операторів циклу; Кількість операторів умови; Число модулів чи підсистем; Відношення числа зв'язків між модулями до модулів; Відношення числа ненормальних виходів із множини операторів до загального числа операторів;	f = N 4 SV/L mod f * = N * SV / L
Метрики Мак-Кейба Цикломатичне число; Цикломатична складність;	(G) = m - n + p (G) = (G) +1 = m – n + 2
Метрика Чепена міра труднощі розуміння програм на основі вхідних та вихідних даних;	H = 0.5T+P+2M+3C
Метрика Шнадевіда Число шляхів у керуючому графі
Метрика Майєрса Інтервальний захід;
Метрика Хансена Пара (цикломатичне число, число операторів)
Метрика Чена Топологічний захід Чена;	M(G) = ((G), С, Q 0)
Метрика Вудворду Вузловий захід (кількість вузлів передач управління);
Метрика Кулика Нормальне число (кількість найпростіших циклів у нормальній схемі програми);
Метрика Хура Цикломатичне число мережі Петрі, що відбиває керуючу структуру програми;
Метрики Вітворфа, Зулевського міра складності потоку управління міра складності потоку даних;
Метрика Петерсона Число багатовхідних циклів;
Метрики Харрісона, Мейджела Функціональне число (сума наведених складнощів усіх вершин графа, що управляє); Функціональне ставлення (ставлення числа вершин графа до функціонального числа); Регулярні вирази (кількість операндів, операторів і дужок у регулярному виразі керуючого графа програми);	f * = N 1 / f 1
Метрика Пивоварського Модифікована цикломатична міра складності;	N(G) = *(G) + P i
Метрика Пратта Тестуючий захід;
Метрика Кантоне Характеристичні числа поліномів, що описують керуючий графік програми;
Метрика Мак-Клура міра складності, заснована на числі можливих шляхів виконання програми, числі керуючих конструкцій та змінних;	C(V) = D(V)J(V)/N
Метрика Кафура міра на основі концепції інформаційних потоків;
Метріка Схуттса, Моханті Ентропійні заходи;
Метрика Коллофело міра логічної стабільності програм;
Метрика Зольновського, Сіммонса, Теєра Зважена сума різних індикаторів: - (Структура, взаємодія, обсяг, дані); - (Складність інтерфейсу, обчислювальна складність, складність введення/виводу, читабельність);
Метрика Берлінгера Інформаційний захід;	I(R) = (F * (R) F - (R)) 2
Метрика Шумана Складність із позиції статистичної теорії мови;
Метрика Янгера Логічна складність із урахуванням історії обчислень; Складність проектування Насиченість коментарями Число зовнішніх звернень Число операторів	C c = log 2 (i + 1) [n Cxy (n)]
ПРОГНОЗ МОДЕЛІ
Моделі Холстеду прогноз системних ресурсів; Прогноз числа помилок. Модель фірми IBM Модель загальної складності Моделі зв'язності Сплайн-модель	P = 3/8 (R a - 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 (S i + S j) + 0.7 C ij P ij = I (Z ij 2 + N ij 2) ln (Z ij 2 + N ij 2) + + Z i + N 1
ОЦІНЮВАЛЬНІ МОДЕЛІ
Джелінскі – Моранди	R(t) = e - (Т - 1 + 1) t
Вейса-Байєса	R 1 (t) = e - - (i -1)) t (, / t 1, ..., t i-1) dd
Шика-Волвертона	R 1 (t) = e - (N - 1 + 1) t i 2 / 2
Літтлвуда	R 1 (t) = (+ / ++ t) (N - i + 1)
Нельсона	R j (t) = exp (ln (1 - P j))
Халецького	R j (t) = P-(1- nj) / n j
Модель налагодженості	R j (t) = P-f j (,)
Мозаїчна модель	R j (t) = 1 - (- j - 1)

У таблиці представлені різноманітні метрики складності ПЗ для різних форм їх подання, моделі, що прогнозують хід розвитку процесів розробки ПЗ і ймовірнісні моделі з оцінки надійності.

Стисло розглянемо метрики складності. Однією з основних цілей науково-технічної підтримки є зменшення складності програмного забезпечення. Саме це дозволяє знизити трудомісткість проектування, розробки, випробувань та супроводу, забезпечити простоту та надійність виробленого ПЗ. Цілеспрямоване зниження складності ПЗ є багатокроковою процедурою і вимагає попереднього дослідження існуючих показників складності, проведення їх класифікації та співвіднесення з типами програм та їх місцезнаходженням у життєвому циклі.

Теорія складності програм спрямовано управління якістю ПЗ і контроль її еталонної складності під час експлуатації. В даний час різноманіття показників (що тією чи іншою мірою описують складність програм) настільки велике, що для їх вживання потрібно попереднє впорядкування. У ряді випадків задовольняються трьома категоріями метрик складності. Перша категорія визначається як словникова метрика, заснована на метричних співвідношеннях Холстеда, цикломатичних заходах Мак-Кейба та вимірах Тейєра. Друга категорія орієнтована на метрики зв'язків, що відображають складність відносин між компонентами системи – це метрики Віна та Вінчестера. Третя категорія включає семантичні метрики, пов'язані з архітектурною побудовою програм та їх оформленням.

Згідно з іншою класифікацією, показники складності поділяються на дві групи: складність проектування та складність функціонування. Складність проектування, яка визначається розмірами програми, кількістю оброблюваних змінних, трудомісткістю та тривалістю розробки та ін. факторами, аналізується на основі трьох базових компонентів: складність структури програми, складність перетворень (алгоритмів), складність даних. До другої групи показників віднесено тимчасову, програмну та інформаційну складності, що характеризують експлуатаційні якості ПЗ.

Існує ще низка підходів до класифікації заходів складності, проте вони, фіксуючи приватні сторони досліджуваних програм, не дозволяють (нехай із великим припущенням) відобразити загальне,те, чиї виміри можуть лягти основою виробничих рішень.

Загальним, інваріантно властивим будь-якому ПЗ (і пов'язаною з його коректністю), є його СТРУКТУРА. Важливо пов'язати цю обставину з певним значенням структурної складності разом заходів складності ПЗ. І більше, під час аналізу структурної складності доцільно обмежитися лише її топологічними заходами, тобто. заходами, основу яких лежать топологічні характеристики граф-модели програми. Ці заходи задовольняють переважній більшості вимог, що висуваються до показників: спільність застосовності, адекватність аналізованої властивості, суттєвість оцінки, спроможність, кількісне вираження, відтворюваність вимірів, мала трудомісткість обчислень, можливість автоматизації оцінювання.

Саме топологічні заходи складності найчастіше застосовуються у фазі досліджень, що формує рішення з управління виробництвом (у процесах проектування, розробки та випробувань) та становлять доступний та чутливий еталон готової продукції, контроль якого необхідно регулярно здійснювати в період її експлуатації.

Першою топологічною мірою складності є цикломатичний захід Мак-Кейба. У основі лежить ідея оцінки складності ПЗ за кількістю базисних шляхів у її керуючому графі, тобто. таких шляхів, компонуючи які можна отримати всілякі шляхи із входу графа у виходи. Цикломатичне число (G) орграфа G з n-вершинами, m-дугами та p-компонентами зв'язності є величина (G) = m – n + p.

Має місце теорема у тому, що кількість базисних шляхів в орграфі дорівнює його цикломатичному числу, збільшеному на одиницю. При цьому, цикломатичною складністю ПЗ з керуючим графом G називається величина (G) = (G) +1 = m – n + 2. Практично цикломатична складність ПЗ дорівнює числу предикатів плюс одиниця, що дозволяє обчислювати її без побудови графа, що управляє, простим підрахунком предикатів . Цей захід відбиває “психологічну” складність ПЗ.

До переваг заходу відносять простоту її обчислення та повторюваність результату, а також наочність та змістовність інтерпретації. Як недоліки можна відзначити: нечутливість до розміру, нечутливість до зміни структури, відсутність кореляції зі структурованістю, відсутність відмінності між конструкціями Розвилка і Цикл, відсутність чутливості до вкладеності циклів. Недоліки цикломатичної міри призвело до появи її модифікацій, а також інших заходів складності.

Дж. Майєрс запропонував як міру складності інтервал [12], де 1 - цикломатична міра, а 2 - число окремих умов плюс одиниця. При цьому оператор DO вважається однією умовою, а CASE c n - результатами за n - 1- умов. Введений захід отримав назву інтервальним заходом.

У. Хансену належить ідея брати як міру складності ПЗ пару (цикломатичне число, число операторів). Відома топологічна міра Z(G), чутлива до структурованості ПЗ. При цьому вона Z(G) = V(G) (рівна цикломатичної складності) для структурованих програм і Z(G) V(G) для неструктурованих. До варіантів цикломатичної міри складності відносять також міру М(G) = (V(G),C,Q), де С - кількість умов, необхідних для покриття графа, що управляє, мінімальним числом маршрутів, а Q - ступінь зв'язності структури графа програми і її протяжність .

До заходів складності, що враховують вкладеність керуючих конструкцій, відносять міру М, що тестує, і міру Харрісона-Мейджела, що враховують рівень вкладеності і протяжності ПЗ, міру Пивоварського - цикломатичну складність і глибину вкладеності, і міру Мак-Клура - складність схеми розбиття ПО модулів та їх внутрішньої складності.

Функціональний захід складності Харрісона-Мейджела передбачає приписування кожній вершині графа своєї власної складності (первинної) та розбиття графа на “сфери впливу” предикатних вершин. Складність сфери називають наведеною і складають її з первинних складнощів вершин, що входять до сфери її впливу, плюс первинну складність самої предикатної вершини. Первинні складності обчислюються всіма можливими способами. Звідси функціональна міра складності є сума наведених складнощів всіх вершин керуючого графа.

Міра Пивоварського має на меті врахувати в оцінці складності ПЗ відмінності не тільки між послідовними та вкладеними керуючими конструкціями, а й між структурованими та неструктурованими програмами. Вона виражається ставленням N(G) = * (G) + P i , де * (G) - модифікована цикломатична складність, обчислена так само, як і V(G), але з однією відмінністю: оператор CASE з n-виходами розглядається як один логічний оператор, а чи не як n – 1 операторів. Р i – глибина вкладеності i – тієї предикатної вершини.

Для підрахунку глибини вкладеності предикатних вершин використовують кількість “сфер впливу”. Під глибиною вкладеності розуміється число всіх “сфер впливу” предикатів, які або повністю утримуватися у сфері вершини, або перетинаються з нею. Глибина вкладеності збільшується з допомогою вкладеності не самих предикатів, а “сфер впливу”. Порівняльний аналіз цикломатичних та функціональних заходів з обговорюваної для десятка різних керуючих графів програми показує, що при нечутливості інших заходів цього класу, міра Пивоварського зростає при переході від послідовних програм до вкладених і далі до неструктурованих.

Міра Мак-Клура призначена для управління складністю структурованих програм у процесі проектування. Вона застосовується до ієрархічних схем розбиття програм на модулі, що дозволяє вибрати схему розбиття із меншою складністю задовго до написання програми. Метрикою виступає залежність складності програми від числа можливих шляхів виконання, числа конструкцій, що управляють, і числа змінних (від яких залежить вибір шляху). Методика розрахунку складності по Мак-Клуру чітко орієнтована добре структуровані програми.

Тестуючим заходом М називається міра складності, що задовольняє наступним умовам:

1. міра складності простого оператора дорівнює 1;

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

3. М (IF P THEN F1 ELSE F2) = 2 MAX (M(F1), M(F2));

4. М (WHILE P DO F) = 2 M (F).

Міра зростає з глибиною вкладеності та враховує протяжність програми. До міри, що тестує, близько примикає міра на основі регулярних вкладень. Ідея цієї міри складності програм полягає у підрахунку сумарного числа символів (операндів, операторів, дужок) у регулярному вираженні з мінімально необхідним числом дужок, що описує керуючий граф програми. Всі заходи цієї групи чутливі до вкладеності конструкцій, що управляють, і до протяжності програми. Проте зростає рівень трудомісткості обчислень.

Розглянемо міри складності, що враховують характер розгалужень. В основі вузлового заходу Вудворда Хедлі лежить ідея підрахунку топологічних характеристик потоку управління. При цьому під вузловою складністю розуміється кількість вузлів передач управління. Цей захід відстежує складність лінеаризації програми і чутлива до структуризації (складність зменшується). Вона застосовна для порівняння еквівалентних програм, краще міри Холстеда, але по спільності поступається мірою Мак-Кейба.

Топологічна міра Чена виражає складність програми числа перетинів кордонів між областями, утвореними блок-схемою програми. Цей підхід застосовується лише до структурованих програм, що допускає лише послідовне з'єднання керуючих конструкцій. Для неструктурованих програм міра Чена істотно залежить від умовних та безумовних переходів. У цьому випадку можна вказати верхню та нижню межі заходу. Верхня - є m+1, де m – число логічних операторів за їх гніздової вкладеності. Нижня – дорівнює 2. Коли керуючий граф програми має лише одну компоненту зв'язності, міра Чена збігається з цикломатичною мірою Мак-Кейба.

Метрики Джилба оцінюють складність графоорієнтованих модулів програм ставленням числа переходів за умовою до загальної кількості операторів, що виконуються. Добре зарекомендувала себе метрика, що відноситься до числа міжмодульних зв'язків до загального числа модулів. Названі метрики використовувалися з метою оцінки складності еквівалентних схем програм, особливо схем Янова.

Використовуються також заходи складності, що враховують історію обчислень, взаємодії модулів і комплексні заходи.

Сукупність цикломатичних заходів придатна для оцінювання складності первинних формалізованих специфікацій, що задають у сукупності вихідні дані, цілі та умови побудови шуканого ПЗ. Оцінка цієї “первинної” програми або порівняння кількох альтернативних її варіантів дозволить спочатку гармонізувати процес розробки ПЗ і від стартової точки контролювати та керувати його поточною результуючою складністю.

З урахуванням нових методик, таких як екстремальне програмування або Scrum, розробка може здійснюватися швидше, а наявність нових платформ та абстрагування від нижніх рівнів дозволяють уникати багатьох помилок. Проте контроль якості повинен здійснюватися на різних рівнях - починаючи з методологічного і закінчуючи технологічним рівнем, коли процеси контролю якості протікають в автоматичному режимі, наприклад при автоматичних складання проекту. Однак будь-який контроль передбачає наявність метрик, які дозволяють оцінити досягнення того чи іншого рівня якості програмного проекту.

Метрики коду

Метрика програмного забезпечення (software metric) – чисельна міра, що дозволяє оцінити певні властивості конкретної ділянки програмного коду. Для кожної метрики зазвичай існують її еталонні показники, що вказують, за яких крайніх значень варто звернути увагу на цю ділянку коду. Метрики коду поділяються на категорії і можуть оцінювати зовсім різні аспекти програмної системи: складність і структурованість програмного коду, зв'язковість компонентів, відносний обсяг програмних компонентів та ін. разом з іншими метриками може бути отримання формалізованих даних з оцінки коду. Наприклад, можна побудувати співвідношення між кількістю рядків коду у класі та кількістю методів/властивостей у класі, отримавши характеристику, що показує, наскільки методи цього класу є об'ємними. Крім того, такі оцінки можна використовувати в сукупності з метриками складності (наприклад, цикломатичною складністю Мак-Кейба) для визначення найбільш складних ділянок у програмному коді та вжиття відповідних заходів.

Метрики коду можуть бути також виявлення архітектурних особливостей. Найбільший ефект застосування таких метрик дає при аналізі великих програмних систем, коли ручний аналіз та перегляд вихідного коду може тривати значний час. Наприклад, можна по-різному візуалізувати метрики, як зазначено на рис. 1, де кожен програмний блок представляється у вигляді прямокутника, при цьому довжина кожної сторони прямокутника відображає значення будь-якої метрики (наприклад, складність, структурованість і т.д.). Подібне уявлення можна будувати як для високорівневих програмних сутностей (складання, бібліотеки, простору імен), так і для більш приватних елементів (властивості, методи). При цьому під час аналізу високорівневої діаграми можна швидко виявити проблемні бібліотеки та спуститися на рівень нижче, щоб дослідити проблемні сутності.

Метрики програмного коду є важливим інструментом і сьогодні використовуються багатьма виробниками ПЗ. Так, при сертифікації на вищі рівні за моделями ISO/IEC або CMM/CMMI використання метрик коду є обов'язковим, що дозволяє певною мірою досягти контрольованості процесу розробки.

Існує безліч різних класифікацій метрик програмного забезпечення, що трактують метрики з різних позицій і ранжують ті самі характеристики за різними критеріями. Однією з таких класифікацій може бути поділ метрик на групи за суб'єктами оцінки:

розмір- Порівняльна оцінка розмірів ПЗ;

складність- Оцінка архітектури та алгоритмів програмної системи (негативні показники цієї групи метрик говорять про проблеми, з якими можна зіткнутися при розвитку, підтримці та налагодженні програмного коду);

підтримуваність- Оцінка потенціалу програмної системи для наступної модифікації.

Безумовно, існують інші групи, які не увійшли до цієї класифікації, наприклад, метрики задоволеності користувача або показники відповідності вихідним вимогам, але в даному випадку нас буде цікавити якість програмного забезпечення з точки зору саме технічної реалізації.

Чи має значення розмір?

Метрика SLOC (source lines of code) відбиває кількість рядків вихідного коду. Даний показник не завжди може використовуватися для об'єктивної оцінки обсягів програмної системи – його числове значення залежить від багатьох випадкових факторів, наприклад стилю кодування. Порівнювати дві програмні системи лише за цим критерієм навряд чи правомірно, тому SLOC з'явилося безліч похідних показників: кількість порожніх рядків; кількість рядків, що містять коментарі; відсоткове співвідношення коментарів; кількість рядків коду, що містяться у методах/функціях; середня кількість рядків коду на метод/функцію; середня кількість рядків коду на клас/пакет; середня кількість рядків коду модуль і т.д.

Крім SLOC, при оцінці розміру часто використовують показник «логічних» рядків коду LSI (logical source instructions), що обчислюється після нормалізації (приведення вихідного коду до належного вигляду) лістингу: усунення розміщення кількох інструкцій на одному рядку, порожніх рядків, очищення від коментарів, форматування рядків коду для ініціалізації даних тощо. Такий показник може бути більш об'єктивної оцінки обсягу системи (показник із застосуванням нормалізації виглядає як і, як і SLOC, – кількість рядків, але з фізичних, а логічних). У LSI також існують похідні, наприклад метрика, що обчислюється не як фізична кількість рядків коду вихідною мовою програмування, а як кількість інструкцій мовою нижчого рівня (мова Асемблера, MSIL та ін), що усуває необхідність нормалізації.

Інші метрики цього базуються на сутності, які стосуються конкретної парадигмі програмування. Найбільш популярною на сьогоднішній день є парадигма об'єктно-орієнтованого програмування, проте для функціонального та процедурного підходу до програмування також є свій специфічний набір метрик. З точки зору об'єктно-орієнтованого підходу розмір системи можна обчислювати як кількість класів, що містяться в ній. Показник кількості класів є однією з основних метрик у даному підході, проте залежно від мови програмування, що використовується, можуть застосовуватися такі метрики, як кількість просторів імен у проекті, кількість структур, перерахувань, кількість методів та ін. Крім того, можна обчислити «щільність» цих показників, визначивши співвідношення значень цих метриків. Наприклад, можна визначити співвідношення кількості класів до кількості методів і зрозуміти, скільки методів в середньому міститься в одному класі. Однак для визначення порогових значень такого типу метрик потрібні додаткові дослідження. Найбільш простим способом визначення граничних величин може бути експеримент, в якому значення цих метрик обчислюються для існуючих систем. Обчислення подібних співвідношень дозволить скоригувати уявлення про систему, що склалася на основі кількісних метриків.

Безпосередня якість системи залежить від використання даних показників, проте досвідчені розробники згодом можуть приблизно прогнозувати обсяг системи на заданий функціонал, необхідний замовнику. В цьому випадку при помітному відхиленні від заданих показників (наприклад, суттєвому збільшенні кількості класів при низькій кількості методів на клас) варто задуматися про те, що в системі може бути надлишкова кількість об'єктів, і на більш ранній стадії виконати рефакторинг коду.

Складність

Для оцінки та контролю якості коду можуть безпосередньо використовуватися метрики складності: цикломатична складність, зв'язність коду, глибина спадкування та ін.

Метрика цикломатичної складності (cyclomatic complexity) показує кількість розгалужень потоку програми, що управляє, збільшене на одиницю. Для обчислення даної метрики основі вихідного коду будується орієнтований граф, що містить один вхід і один вихід. При цьому вершини графа співвідносять з тими ділянками коду програми, в яких містяться лише послідовні обчислення та відсутні оператори розгалуження та циклу. Дуги у разі співвідносять з переходами від блоку до блоку. При цьому кожна вершина графа досяжна з початкової, а кінцева точка досяжна з будь-якої іншої. У цьому випадку цикломатичну складність можна обчислити як різницю кількості дуг та кількості вершин, збільшену на два. Такий показник може відобразити складність потоку програми, що управляє, і дати сигнал про можливу наявність неякісної ділянки коду. На жаль, попри очевидну практичну корисність, ця метрика неспроможна розрізняти циклічні оператори. Крім того, програмні коди, представлені одними і тими ж графами, можуть мати зовсім різні за складністю предикати (логічні вирази, що містять змінну). Тому іноді цикломатичну складність використовують одночасно з іншими метриками, наприклад з метрикою числа операторів.

Метрика зв'язності класів дозволяє визначити рівень залежності програмних компонентів системи друг від друга. Підвищені значення даної метрики щодо порогових значень можуть говорити про надмірну зв'язаність системи, яка виникає через слабку модульну інкапсуляцію. Така властивість програмної системи може призвести до труднощів повторного використання коду. На цю метрику можна орієнтуватися при побудові та переробці архітектури програмної системи. Основними способами зменшення зв'язності об'єктів є суворіша інкапсуляція логіки в об'єкти, перегляд роботи алгоритмів з концептуальної точки зору і структурна декомпозиція. При цьому використовуються заводи об'єктів, які дозволяють уникнути зайвої зв'язності в момент створення екземплярів класів. Завдяки застосуванню сирих значень даної метрики вдається знизити складність програмної системи, а отже, і складність коду.

Іноді використовують варіацію метрики, що відбиває зв'язність коду, – кількість викликів операції. Ця метрика дозволяє визначити кількісний показник зв'язності системи як викликів методів. Метрика підраховує виклики лише операцій, визначених користувачем. Наприклад, якщо метод A() викликає метод B() три рази, то значення цієї метрики дорівнюватиме одиниці; якщо ж метод B() викликається по одному разу з методів A(), C() і D(), то значення метрики дорівнюватиме трьом. Однак абсолютне значення даної метрики може суттєво змінюватися від проекту до проекту залежно від підходів до проектування та кодування програмних систем. Навіть у межах однієї і тієї ж команди розробників на ідентичних проектах значення даної метрики може відрізнятися з суб'єктивних чинників (наприклад, стилю конкретного розробника виділення логіки окремі методи), які впливали під час побудови програмної системи.

Прямий результат обчислення цієї метрики має сумнівне практичне значення, однак у сукупності із сумарним значенням метрики кількість методів у класі може дати об'єктивну оцінку зв'язності системи. Наприклад, якщо використовувати цю метрику поряд із метрикою складності, а також об'ємними характеристиками, то за сукупністю значень цих метрик можна виявити недостатньо якісний код.

Ще однією важливою метрикою оцінки складності є середня глибина успадкування, яка обчислюється як середнє значення глибини успадкування всім класів системи, визначених користувачем. При цьому не враховуються класи, що стоять на самому нижньому рівні ієрархії успадкування. Високі значення метрики можуть сигналізувати у тому, що архітектори програмної системи дуже захопилися прийомами об'єктно-орієнтованого програмування, але це може негативно позначатися подальшому розвитку системи. Спадкування істотно підвищує зв'язність, яка при цьому може не відбиватися рештою метриків оцінки системи. Найчастіше при побудові програмного коду можна уникнути застосування наслідування, замінивши його рівноцінними прийомами. Наприклад, замість цього можна використовувати ін'єкцію залежностей та IoC-контейнери. Результат обчислення даної метрики, як правило, використовується у сирому вигляді у практичних завданнях побудови архітектури та рефакторингу. Отримані показники метрики також можна використовувати у складніших комплексних метриках. Інакше висловлюючись, якщо значення цієї метрики велике, можна відразу виявити аномалію. Крім того, цю метрику можна використовувати разом з іншими, наприклад підрахувати складність системи по Мак-Кейбу та її обсяг, щоб точніше виміряти програмну систему.

Загалом метрики складності можуть надати суттєву допомогу виробникам програмного забезпечення у процесі контролю та управління якістю програмного забезпечення.

Підтримуваність

Метрики даного типу показують трудомісткість процесу підтримки та розвитку програмного коду і, як правило, тісно пов'язані з метриками складності, але мають особливості, що відображають можливості підтримки системи.

Однією з основних метрик цієї категорії є метрика Холстеда, в рамках якої визначають чотири характеристики програми, що вимірюються: число унікальних операторів програми, включаючи символи-розділювачі, імена процедур і знаки операцій (словник операторів); число унікальних операндів програми (словник операндів); загальна кількість операторів у програмі; загальна кількість операндів у програмі. З цих характеристик проводяться базові оцінки: складається словник програми; визначається довжина програми, її обсяг та складність. Далі пропонується обчислити різні заходи, що дозволяють оцінити програмний код. Наприклад, вираз обчислення якості програмування, складності розуміння програми, розумові видатки створення програми та інших.

Метрика Холстеда має виключно інформаційний характер, проте вона залишається однією з небагатьох, які дозволяють кількісно оцінити показник підтримуваності системи в майбутньому, при цьому цей показник має пряму кореляцію з якістю продукту.

Інструмент аналізу коду

Розробники на платформі Microsoft можуть скористатися версією Visual Studio 2008, яка дозволяє обчислювати базовий набір основних метрик та відстежувати їх у режимі реального часу (рис. 2). Проте основний сценарій використання метрик – це інформування менеджерів розробки у тому, що якість продукту, можливо, знизилося чи підвищилося. Тому має сенс обчислювати такі метрики у процесі збирання проекту.

Visual Stuido 2008 і Microsoft Build не дозволяють вибудувати серйозну ієрархію метрик, і для цього слід скористатися іншими інструментами, наприклад NDepend, що дозволяє для платформи.

Проблеми при використанні метрик коду

Незважаючи на те, що метрики дозволяють контролювати процес розробки, робота з ними пов'язана з низкою проблем.

По-перше, всі відомі на сьогоднішній день метрики коду недостатньо значущі та точні. Вони не здатні забезпечити отримання об'єктивної картини про стан програмної системи, а лише видають показники, що обчислені за заданим алгоритмом. По-друге, процес вимірювання може бути штучно спотворений за рахунок того, що співробітники оптимізуватимуть свій програмний код так, щоб метрики видавали кращі результати. Крім того, формальне використання метрик не враховує досвід співробітників, рівень компанії і може принести не лише користь, а й шкоду.

Проте метрики є досить корисним інструментом у руках розробників та менеджерів проектів, що дозволяє виявити моменти відходу розробки на нижчий якісний рівень та розпізнати найскладніші ділянки у системі. Визначення числових показників може дати нові відомості про продукт, що розробляється, і допомогти грамотніше планувати витрати на його подальший розвиток.

Сергій Звездін ([email protected]) – аспірант Південно-Уральського державного університету (Челябінськ).

У МДУ відкрито портал дистанційного навчання

Школа дистанційної освіти Московського державного університету ім. М.В. Ломоносова відкрила свій Internet-портал. На ньому пропонується доступ до спільної відкритої електронної бібліотеки МДУ та Російської академії наук, підручників та курсів, аудіо- та відеоматеріалів, а також до освітніх програм із застосуванням дистанційних освітніх технологій. Частина ресурсів порталу доступна лише слухачам дистанційних програм, які сплатили за навчання згідно з договором з університетом. Відеоматеріали МДУ тепер доступні на каналіуніверситету в YouTube. Освітній канал містить записи лекцій та заходів університету.

eLearning тільки для 17% російських компаній

Дослідницький центр порталу SuperJob.ru представив результати опитування, присвяченого онлайн-навчання персоналу російських компаній. Серед вітчизняних роботодавців використання електронного навчання у роботі з персоналом не надто поширене. Тільки 17% компаній пропонують персоналу подібну форму навчання. В основному, ці технології застосовують у великих компаніях зі штатом від 5 тис. осіб (50%). Загалом не застосовують подібну практику 79% роботодавців. Причини криються або у відсутності необхідного технічного обладнання, або у небажанні керівництва застосовувати такий вид навчання. Загалом досвід дистанційного навчання мають лише 11% росіян. З цього числа 9% респондентів залишилися задоволеними результатом, а 2% недоучилися і покинули. Серед тих, хто пройшов навчання, чоловіків виявилося майже вдвічі більше, ніж жінок (11% та 6% відповідно). У цьому росіяни віком від 35 до 55 років навчаються через Internet частіше, ніж молодь. Успішним досвідом дистанційного навчання може похвалитися 12% респондентів віком від 40-50 років і лише 9% росіян до 23 років.

Підсумки конкурсу «Максимальна масштабованість 2009»

Конкурс проектів з високопродуктивних обчислень «Максимальна масштабованість», як і минулого року, був присвячений міжнародному форуму з нанотехнологій. На перемогу в ньому претендували вчені з двадцяти міст Росії, проте організатори, компанія Intel та «Російська корпорація нанотехнологій» віддали всі призові місця столичним проектам. Гран-прі отримав Володимир Боченков із хімічного факультету МДУ ім. Ломоносова за проект "Розробка та реалізація паралельного алгоритму температурно-прискореної динаміки". Запропонована автором система дозволяє досліджувати конденсацію наноструктур, молекулярно-променеву епітаксию та взаємодію біологічних молекул.

Стартував чемпіонат світу з програмування

У фіналі 34-го щорічного командного чемпіонату світу з програмування (International Collegiate Programming Contest, ICPC), який проводиться асоціацією Association for Computing Machinery (ACM) і спонсорується IBM, зустрінуться сто студентських команд, які перемогли в регіональних змаганнях. Перед ними буде поставлено як мінімум вісім завдань, які потрібно вирішити за 5 годин. Фінал пройде 5 лютого 2010 року у Харбінському інженерному університеті (Китай). Серед завдань минулих років були, наприклад, такі як пошук втраченого в морі корабля, тріангуляція розташування зіпсованого радіопередавача, обчислення перешкод при грі в гольф, кодування та декодування повідомлень, друк шрифтом Брайля, пошук виходу з лабіринту. Минулого року три із чотирьох золотих медалей вибороли російські команди. На стадії відбіркових змагань у чемпіонаті брало участь 7109 команд із 1838 університетів 88 країн світу. Другий рік поспіль чемпіоном світу стала команда Санкт-Петербурзького державного університету інформаційних технологій, механіки та оптики.

Ми випустили нову книгу «Контент-маркетинг у соціальних мережах: Як засісти в голову передплатників та закохати їх у свій бренд».

Підписатися

Створюємо звіт. У метриках вибираємо «Досягнення цілей» – «Мета, на яку у вас налаштована конверсія». Зазвичай це сторінка «Дякую за покупку».

У результаті отримаємо дані про те, скільки за кожною РК було покупок і скільки було витрачено на залучення користувачів, які їх здійснили. Кількість конверсій ділимо на вартість кліків, отримуємо вартість одного ліда. Якщо у вас налаштована , можна додати стовпець «Дохід», щоб оцінити отриманий прибуток.

Сегменти для ретаргетингу та коригування ставок: новий рівень відносин із потенційними покупцями

У цьому розділі ми створимо та збережемо Яндекс.Метрики, визначимо коригування, щоб використовувати їх при налаштуванні кампаній у Директі.

Не забувайте виставляти період часу так, щоб вибірка була репрезентативною. Потрібно щоб дані будувалися на основі поведінки великої групи відвідувачів.

Стать та вік – коригування

Після створення цього звіту ми зможемо побачити, хто краще купує у нас на сайті, чоловіки чи жінки, та який вік таких покупців. Після цього ніщо не завадить встановити коригування ставок на даний сегмент.

Вибираємо: "Звіти" - "Відвідувачі" - "Пол" (1).

У результаті робимо коригування на жінок. При цьому отримані дані допомогли нам побачити, що чоловіки теж проводять час на нашому сайті. Із цією інформацією треба працювати. Наприклад, написати відповідні оголошення.

Час та годинник – коригування

Ваші відвідувачі можуть мати різну активність протягом дня або тижня, тому в даному пункті ми виявимо найбільш конверсійні дні та години для вашого ресурсу, після чого можна буде встановити коригування за часом у Директі.

"Звіти" - "Відвідувачі" - "Відвідуваність за часом доби".

У угрупованнях додаємо: Поведінка: дата та час – «Фрагменти дати/часу» – «День тижня візиту»(2). Вибираємо ціль – сортуємо за конверсією. Отримуємо звіт, в якому показано, в який день і о котрій годині вона (конверсія) максимальна.

Географія

"Звіти" - "Відвідувачі" - "Географія".

Звіт допоможе сайтам визначити регіони, в яких продажі йдуть краще, ніж в інших. Зазвичай багатьом ніш левову частку продажів приносять Москва чи Петербург та його области. Тому основна маса рекламодавців поділяє свої РК на міста федерального значення та решту Росії.

Звіт з географії допоможе вам знайти курс для подальшого дроблення кампаній у Директі або виявити регіональні РК зі слабкою віддачею.

Сегмент «Забутий кошик»

Створюємо: "Звіти" - "Відвідувачі" - "Час з першого візиту".

З метою виберемо макроціль – купівля, запис на консультацію в офісі і т.д. Сортуємо за конверсією. Вибираємо перші 2 рядки для побудови графіка. У результаті отримаємо інформацію про те, скільки часу наші клієнти витрачають на обмірковування рішення про покупку. Крім того, ми зможемо використовувати дані в інтерфейсі Директа, щоб не показувати рекламу тим, хто вже не потребує нашої пропозиції.

Зі звіту бачимо, що в основному мета досягається в день візиту, але і протягом місяця користувачі повертаються і конвертуються.

Тепер сам сегмент. Створимо його для тих, хто залишив товар у кошику, але так і не купив.

Зайдемо до вже знайомого звіту «Джерела» – «Зведення», залишаємо галочку тільки у графі «Переходи з реклами», натискаємо + і в меню вибираємо: «Поведінка» – «Досягнення цілей» – «Мета: додав до кошика» (мета javascript має бути налаштована на кнопки «Додати до кошика»). Зберігаємо і називаємо сегмент, тепер переходимо до Директу.

Знаходимо оголошення, яке хочемо показати цьому сегменту, клацаємо в «Умови підбору аудиторії», потім – «Додати умову».

Звіти для аналізу сайту: вивчаємо та покращуємо

Вебвізор

Його дані допоможуть нам виявити слабкі місця сайту, зрозуміти які труднощі виникають у користувачів.

Розглянемо сегменти Вебвізора для візитів, в яких було досягнуто нашої макромети.

Зробимо вибірку та подивимося, як користувачі досягали її. Можливо, ми зрозуміємо поведінкові патерни наших покупців, про які ми не здогадувалися. Раптом перед відправкою замовлення більшість із них переглядала альбом з фото чи взаємодіяла з інтерактивними елементами на сайті, а може, довго зупинялася на відгуках? Такі дані допоможуть вирішити, як правильно розташувати та оформити блоки на сайті.

Другий сегмент - користувачі, які провели достатньо часу на нашому сайті, щоб зробити покупку, але так і не зробили. Аналіз подібних візитів дасть розуміння основних складнощів, з якими стикаються відвідувачі.

Карти скролінгу / кліків

Карта скролінгу допоможе зрозуміти, на якому екрані відвідувачі проводять більше часу. Можливо, якась потрібна інформація, яка допоможе ухвалити рішення про покупку, знаходиться в «холодній зоні» і її потрібно перенести в інше місце. Наприклад, клієнт рекламується лише за запитами із зазначенням станції метро, ​​а карта з адресою та схемою проїзду розташована внизу сторінки.

Результат – великий відсоток відмов, тому що клієнтам, які приходять за такими запитами, важливим є місце розташування офісу організації.

Навчальне відео. Яндекс.Метрика: знайомство Подивитись відео

Що можна відстежувати за допомогою Метрики

Залучення відвідувачів

Звіти по Директу в Метриці наочно показують, за якими кампаніями, оголошеннями, фразами та пошуковими запитами приходять на ваш сайт відвідувачі, з яких регіонів та з яких рекламних майданчиків. Використовуйте цю інформацію, щоб оптимізувати ваші кампанії.

Наприклад, ви можете покращити фрази: додати ключові фрази з релевантних пошукових запитів та мінус-слова з нерелевантних запитів – це допоможе залучити більш зацікавлених відвідувачів та підвищити CTR.

Аудиторія сайту

У Метриці ви можете отримати детальні характеристики вашої аудиторії. Стать, вік та інтереси відвідувачів обчислюються шляхом аналізу їхньої поведінки в інтернеті за допомогою технології Крипта. Орієнтуючись на ці дані, рекламу можна робити релевантнішою і за рахунок цього підвищувати її ефективність.

Досягнення цілей та конверсії

Важливо не просто привести на свій сайт відвідувачів, а зрозуміти, чи вони стають реальними клієнтами. Для цього в Метриці потрібно налаштувати цілі – тобто визначити ключові дії, які мають виконати відвідувачі сайту.

Наприклад, вашим покупцем може стати відвідувач, який:

• натиснув кнопку «У кошик»;
• пройшов шлях від кошика до сторінки "Дякую за покупку"при оформленні замовлення;
• відвідав не менше двох сторінок сайту;
• зайшов на сторінку із контактною інформацією;
• зареєструвався на сайті або підписався на розсилку.

Наявність налаштованих цілей дозволить зрозуміти, за якими фразами та оголошеннями на сайт приходять користувачі, які досягають мети. Ви зможете не лише аналізувати приріст цільових візитів, а й оптимізувати їх за допомогою однієї з автоматичних стратегій: Середня ціна конверсії або Тижневий бюджет. Максимум конверсій.

Виторг

Власники інтернет-магазинів можуть отримувати в Метриці детальну інформацію про замовлення, здійснені на сайті магазину. Ви зможете дізнатися, скільки грошей принесло кожне замовлення і з яких каналів надходять найбільш прибуткові замовлення.

Прямо в інтерфейсі Метрики ви можете швидко оцінити витрати на рекламу в Директі. Наприклад, ви можете переглянути загальні витрати на рекламу, дізнатися середню вартість конверсій по всіх своїх рекламних кампаніях, оцінити середню або сумарну вартість кліків для певних типів пристроїв, регіонів, пошукових запитів або майданчиків.

Цільові дзвінки

Клієнти роблять замовлення не лише на сайті, а й по телефону. Послуга «Цільовий дзвінок»дозволяє порівняти ефективність різних каналів просування. Ви отримуєте спеціальні телефонні номери, які можна прив'язати до різних джерел, з рівнем деталізації до окремих рекламних кампаній. Номер на сайті та у віртуальній візитці автоматично підміняється залежно від джерела – таким чином можна відстежити, звідки про вас дізнався кожен, хто зателефонував.

Як почати збирати статистику

Встановіть код лічильника на всі сторінки вашого сайту якомога ближче до початку сторінки - від цього залежить повнота даних, що збираються. Коректність установки лічильника ви можете перевірити в консолі браузера.

Якщо ви створюєте багато кампаній з однаковим набором лічильників, ви можете вказати лічильники на сторінці налаштувань користувача у полі Лічильник Метрики для нових кампаній.

Поки ви не вказали номери лічильників, передавати дані між Директом та Метрикою вам допоможе автоматична розмітка посилань. Переконайтеся, що у параметрах кампанії увімкнено опцію Розмічати посилання для Метрики, а ваш сайт коректно відкриває посилання з позначками.

Як працює розмітка посилань

Увага. Якщо у параметрах кампанії не заповнено поле Лічильники Метрики, і при цьому вимкнено опцію Розмічати посилання для Метрики, то дані про кліки по оголошеннях не потраплятимуть у Метрику, а дані з Метрики не потраплятимуть у статистику Директа.

Питання та відповіді

Як швидко оновлюються дані у звітах Метрики?

Дії відвідувача на сайті відображаються у більшості звітів Метрики вже за кілька хвилин. Дані для спеціальних звітів Директу проходять додаткову перевірку, тому вони потрапляють до Метрики із затримкою до декількох годин.

Як швидко до Директу потрапляють дані про досягнення цілей?

Дані про досягнення конкретної мети потрапляють до Директу протягом доби.

Чому відрізняються дані у статистиці Директа та в Метриці?

Оскільки кількісні методи добре зарекомендували себе в інших областях, багато теоретиків і практик інформатики намагалися перенести даний підхід і в розробку програмного забезпечення. Як сказав Том ДеМарко, "ви не можете контролювати те, що не можете виміряти".

Метрики

Набір використовуваних метрик включає:

• порядок зростання (мається на увазі аналіз алгоритмів у термінах асимптотичного аналізу та O-нотації),
• аналіз функціональних точок,
• кількість помилок на 1000 рядків коду,
• ступінь покриття коду тестуванням,
• кількість класів та інтерфейсів ,
• метрики програмного пакета від Роберта Сесіль Мартіна,

Критика

Потенційні недоліки підходу, на які націлена критика:

• Неетичність: Стверджується, що неетично судити про продуктивність програміста за метриками, введеними для оцінки ефективності програмного коду. Такі відомі метрики, як кількість рядків коду та цикломатична складність, часто дають поверхове уявлення про "вдалість" вибору того чи іншого підходу при вирішенні поставлених завдань, однак, нерідко вони розглядаються як інструмент оцінки якості роботи розробника. Такий підхід досить часто призводить до зворотного ефекту, що призводить до появи в коді більш довгих конструкцій та надлишкових необов'язкових методів.
• Заміщення «управління людьми» на «управління цифрами», яке не враховує досвід співробітників та їх інших якостей
• Спотворення: Процес вимірювання може бути спотворений за рахунок того, що співробітники знають про показники, що вимірюються, і прагнуть оптимізувати ці показники, а не свою роботу. Наприклад, якщо кількість рядків вихідного коду є важливим показником, то програмісти будуть прагнути писати якнайбільше рядків і не будуть використовувати способи спрощення коду, що скорочують кількість рядків.
• Неточність: Немає метрик, які були б одночасно значущі і досить точні. Кількість рядків коду - це просто кількість рядків, цей показник не дає уявлення про складність проблеми, що вирішується. Аналіз функціональних точок був розроблений з метою кращого виміру складності коду та специфікації, але він використовує особисті оцінки вимірювального, тому різні люди отримають різні результати.

Див. також

• Основні метрики коду: LOC, SLOC, Джилб, Маккейб, Холстед, ООП та інші

Wikimedia Foundation. 2010 .

• Одометр
• Стетоскоп

Дивитись що таке "Метрика програмного забезпечення" в інших словниках:

Якість програмного забезпечення

Оцінка витрат на розробку програмного забезпечення- При розробці програмного забезпечення дуже важливою є проблема оцінки матеріальних витрат та/або витрат часу на успішне завершення проекту. Існує безліч методів для виконання такої оцінки, серед яких можна виділити загальні… Вікіпедія

Метрика- Має кілька значень: У математиці Метрика функція, що визначає відстані в метричному просторі. Метрика альтернативна назва метричного тензора, зокрема Метрика простору часу 4 тензор, який … Вікіпедія

Покриття коду- Цей термін має й інші значення, див. Покриття. Покриття коду міра, що використовується під час тестування програмного забезпечення. Вона показує процент, наскільки вихідний код програми був протестований. Техніка покриття коду була… … Вікіпедія

Кількість рядків коду- Див. також: Обсяг коду Кількість рядків коду (Source Lines of Code SLOC) це метрика програмного забезпечення, яка використовується для вимірювання його обсягу за допомогою підрахунку кількості рядків у тексті вихідного коду. Як правило, ... ... Вікіпедія

Тестування навантаження- (англ. Load Testing) визначення чи збирання показників продуктивності та часу відгуку програмно-технічної системи або пристрою у відповідь на зовнішній запит з метою встановлення відповідності вимогам, що пред'являються до даної системи … Вікіпедія

Тестування продуктивності- У цій статті не вистачає посилань на джерела інформації. Інформація має бути перевіряється, інакше вона може бути поставлена ​​під сумнів та видалена. Ви можете … Вікіпедія

Scrum- Розробка програмного забезпечення Процес розробки ПЗ Кроки процесу Аналіз Проектування Програмування Документ … Вікіпедія

Цикломатична складність- Програми (англ. Cyclomatic complexity of a program) структурна (або топологічна) міра складності програм, що використовується для вимірювання якості програмного забезпечення, заснована на методах статичного аналізу коду. ЦСП дорівнює… … Вікіпедія

Zabbix- 1.1 alpha 6 running under GNU/Linux … Вікіпедія