5). Супроводжуваність

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

Супроводжуваність включає підхарактеристики:

– аналізованість – атрибут, що визначає необхідні зусилля для діагностики у відмовах або ідентифікації частин, які модифікуватимуться;

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

- Стабільність - атрибут, що вказують на ризик модифікації;

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

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

6). Переносність- безліч показників, що вказують на здатність програмного забезпечення пристосовуватися до роботи в нових умовах середовища виконання. Середовище може бути організаційним, апаратним і програмним. Тому перенесення ПЗ у нове середовище виконання може бути пов'язаний із сукупністю дій, спрямованих на забезпечення його функціонування в середовищі, відмінному від того середовища, в якому воно створювалося з урахуванням нових програмних, організаційних та технічних можливостей.

Переносність включає підхарактеристики:

– адаптивність – атрибут, визначальний зусилля, витрачаються адаптацію до різних середовищах;

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

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

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

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

9.1.1. Метрики якості програмного забезпечення

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

Система вимірювання ПЗ включає метрики та моделі вимірювань, які використовуються для кількісної оцінки його якості.

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

Відповідно до стандарту метрики визначаються за моделлю вимірювання атрибутів ПЗ на всіх етапах ЖЦ (проміжна, внутрішня метрика) і особливо на етапі тестування або функціонування (зовнішні метрики) продукту.

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

Типи метрик. Існує три типи метрик:

– метрики програмного продукту, що використовуються при вимірі його характеристик – властивостей;

– метрики процесу, які використовуються при вимірі якості процесу, що використовується для створення продукту.

– метрики використання.

Метрики програмного продуктувключають:

- Зовнішні метрики, що позначають властивості продукту, видимі користувачеві;

- Внутрішні метрики, що позначають властивості, видимі тільки команді розробників.

Зовнішні метрикипродукту включають такі метрики:

- Надійності продукту, які служать для визначення числа дефектів;

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

- Супроводження, за допомогою яких вимірюються ресурси товару (швидкість, пам'ять, середовище);

– застосування продукту, які сприяють визначенню ступеня доступності для вивчення та використання;

- Ціни, якими визначається вартість створеного продукту.

Внутрішні метрикипродукту включають метрики:

- Розміру, необхідні для вимірювання продукту за допомогою його внутрішніх характеристик;

– складності, необхідні визначення складності продукту;

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

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

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

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

– вимог;

– сценаріїв та дійових осіб;

– об'єктів, включених до сценарію, та локалізація вимог до кожного сценарію;

- Параметрів та операцій об'єкта та ін.

Стандарт ISO/IEC 9126–2 визначає такі типи заходів:

– міра розміру ПЗ у різних одиницях виміру (кількість функцій, рядків у програмі, розмір дискової пам'яті та інших.);

– міра часу (функціонування системи, виконання компонента та ін.);

- міра зусиль (продуктивність праці, трудомісткість та ін);

– заходи обліку (кількість помилок, кількість відмов, відповідей системи та інших.).

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

– загальна кількість об'єктів та кількість повторно використовуваних;

– загальна кількість операцій, повторно використовуваних та нових операцій;

- Число класів, що успадковують специфічні операції;

- Число класів, від яких залежить даний клас;

- Число користувачів класу або операцій та ін.

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

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

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

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

Метрики процесіввключають метрики:

– вартості, що визначають витрати на створення продукту чи архітектуру проекту з урахуванням оригінальності, підтримки, документації розробки;

- Оцінки вартості робіт фахівців за людину-дні або місяці;

– ненадійності процесу – кількість не виявлених дефектів під час проектування;

- Повторюваності, які встановлюють ступінь використання повторних компонентів.

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

– загальний час розробки та окремо час для кожної стадії;

- Час модифікації моделей;

- Час виконання робіт на процесі;

- Число знайдених помилок при інспектуванні;

- Вартість перевірки якості;

- Вартість процесу розробки.

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

9.1.2. Стандартний метод оцінки значень показників якості

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

За визначенням стандарту ISO/IES 9126–2 метрика якості ПЗ є “моделлю вимірювання атрибуту, що зв'язується з показником його якості”. Для користування метриками під час вимірювання показників якості цей стандарт дозволяє визначати такі типи заходів:

- Заходи розміру в різних одиницях вимірювання (кількість функцій, розмір програми, обсяг ресурсів та ін);

- Заходи часу - періоди реального, процесорного або календарного часу (час функціонування системи, час виконання компонента, час використання та ін);

- Заходи зусиль - продуктивний час, витрачений на реалізацію проекту (продуктивність праці окремих учасників проекту, колективна трудомісткість та ін);

- Заходи інтервалів між подіями, наприклад, час між послідовними відмовими;

– лічильні заходи – лічильники визначення кількості виявлених помилок, структурної складності програми, числа несумісних елементів, числа змін (наприклад, число виявлених відмов та інших.).

Метрики якості використовуються при оцінці ступеня тестованості після проведення випробувань на безлічі тестів (безвідмовна робота, здійснюваність функцій, зручність застосування інтерфейсів користувачів, БД і т.п.).

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

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

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

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

Тобто. при проведенні оцінки окремого показника за допомогою оціночних елементів прораховується вагомий коефіцієнт k– метрика, j- Показник, i- Атрибут. Наприклад, як j- Показника візьмемо переносимість. Цей показник обчислюватиметься за п'ятьма атрибутами ( i = 1, ..., 5), причому кожен з них множитиметься на відповідний коефіцієнт k i .

Усі метрики j– атрибути підсумовуються та утворюють i - показник якості. Коли всі атрибути оцінені за кожним показником якості, проводиться сумарна оцінка окремого показника, та був інтегральна оцінка якості з урахуванням вагових коефіцієнтів всіх показників ПО.

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

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

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

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

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

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

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

– метрична (1.1 – абсолютна, 1.2 – відносна, 1.3 – інтегральна);

- порядкова (рангова), що дозволяє ранжувати характеристики шляхом порівняння з опорними;

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

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

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

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

- порядкова шкала служить для впорядкування характеристики зростання або спадання шляхом порівняння їх з базовими значеннями;

- інтервальна шкала задає суттєві властивості об'єкта (наприклад, календарна дата);

- Відносна шкала задає деяке значення щодо обраної одиниці;

- Абсолютна шкала вказує на фактичне значення величини (наприклад, кількість помилок у програмі дорівнює 10).

9.1.3. Управління якістю ПС

Під управлінням якостірозуміється сукупність організаційної структури та відповідальних осіб, а також процедур, процесів та ресурсів для планування та управління досягненням якості ПС. Управління якістю – SQM (Software Quality Management) базується на застосуванні стандартних положень щодо гарантії якості – SQA (Software Quality Assurance).

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

- Впровадження стандартів та відповідних процедур розробки ПС на етапах ЖЦ;

– оцінка дотримання положень цих стандартів та процедур.

Гарантія якості полягає в наступному:

– перевірка несуперечності та здійсненності планів;

- Узгодження проміжних робочих продуктів з плановими показниками;

- Перевірка виготовлених продуктів заданим вимогам;

– аналіз застосовуваних процесів на відповідність договору та планам;

– середовище та методи розробки узгоджуються із замовленням на розробку;

– перевірка прийнятих метрик продуктів, процесів та прийомів їх вимірювання відповідно до затвердженого стандарту та процедур вимірювання.

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

– визначення кількісних властивостей якості, заснованих на виявлених та передбачених потребах користувачів;

- Управління реалізацією поставлених цілей для досягнення якості.

SQM ґрунтується на гарантії того, що:

- Цілі досягнення необхідної якості встановлені для всіх робочих продуктів в контрольних точках продукту;

– визначено стратегію досягнення якості, метрики, критерії, прийоми, вимоги до процесу вимірювання та ін.;

– визначено та виконуються дії, пов'язані з наданням продуктам властивостей якості;

– проводиться контроль якості (SQA, верифікація та валідація) та цілей, якщо вони не досягнуті, то проводиться регулювання процесів;

- Виконуються процеси вимірювання та оцінювання кінцевого продукту на досягнення необхідної якості.

Основні стандартні положення щодо створення якісного продукту та оцінки рівня досягнутого виділяють два процеси забезпечення якості на етапах ЖЦ ПС:

– гарантія (підтвердження) якості ПС, як результат певної діяльності на кожному етапі ЖЦ з перевіркою відповідності системи стандартам та процедурам, орієнтованим на досягнення якості;

- Інженерія якості, як процес надання продуктам ПЗ властивостей функціональності, надійності, супроводу та інших характеристик якості.

Процеси досягнення якості призначені для:

а) управління, розробки та забезпечення гарантій відповідно до зазначених стандартів та процедур;

б) управління конфігурацією (ідентифікація, облік стану та дій з автентифікації), ризиком та проектом відповідно до стандартів та процедур;

в) контроль базової версії ПС та реалізованих у ній характеристик якості.

Виконання зазначених процесів включає такі дії:

– оцінка стандартів та процедур, які виконуються при розробці програм;

– ревізія управління, розробки та забезпечення гарантії якості ПЗ, а також проектної документації (звіти, графіки розробки, повідомлення та ін.);

– контроль проведення формальних інспекцій та переглядів;

– аналіз та контроль проведення приймального тестування (випробування) ПС.

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

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

Система якості(Quality systems – QS) – це набір організаційних структур, методик, заходів, процесів та ресурсів для здійснення управління якістю. Для забезпечення необхідного рівня якості програмного забезпечення застосовуються два підходи. Один з них орієнтований на кінцевий програмний продукт, а другий – на процес створення продукту.

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

При другому підході передбачаються та вживаються заходи щодо запобігання, оперативного виявлення та усунення помилок, починаючи з початкових етапів ЖЦ відповідно до плану та процедур забезпечення якості ПС, що розробляється. Цей підхід представлений у серії стандартів ISO 9000 та 9000-1,2,3. Мета стандарту 9000-3 полягає у видачі рекомендацій організаціям-розробникам створити систему якості за схемою, наведеною на рис.9.3.

Спільна

Система контроль Керівник робота Відповідальний

Якості від виконавця від замовника

Загальна політика

Відповідальність

та повноваження

Засоби контролю

План досягнення

якості ПС

9.3. Вимоги стандарту до організації системи якості

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

Планування якостіє діяльність, спрямовану визначення цілей і вимог до якості. Воно охоплює ідентифікацію, встановлення цілей, вимог до якості, класифікацію та оцінку якості. Складається календарний план–графік щодо аналізу стану розробки та послідовного виміру спланованих показників і критеріїв на етапах ЖЦ.

Оперативне керуваннявключає методи та види діяльності оперативного характеру для поточного управління процесом проектування, усунення причин незадовільного функціонування ПС.

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

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

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

9.2. Моделі оцінки надійності

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

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

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

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

Програмне Документ

і т.д. Кольорова павутина, пропонована в підручниках, Складна для сприйняття та розуміння ... його використання. М.М. ПетрухінГОУ ВПО « ... засоби. На сьогоднішній день у програмноюінженеріїможна виділити два основні підходи до розробки програмногозабезпечення ...

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Географія

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

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

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

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

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

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

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

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

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

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

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

Вебвізор

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

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

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

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

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

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

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

Свіжі добірки матеріалів для скачування! Ми зібрали пакети матеріалів з актуальних тем, що включають презентації експертів, вебінари, статті, приклади впроваджень та ін.
Щоб завантажити матеріали, натисніть на відповідну кнопку:

Найбільш широко відомим і використовуваним стандартом для організації процесів контролю якості є серія стандартів ISO 9000. Для розробки програм використовується стандарт ISO 9001, що передбачає проектування в процесі виробництва. Слід зазначити, що цей стандарт важко використовувати безпосередньо в управлінні якістю розробки програмного забезпечення, оскільки він орієнтований на розробку промислових виробів. Спеціально для забезпечення процесів розробки програмних систем організацією ISO розроблено керівництво ISO 9000-3, яке формулює вимоги моделі якості ISO 9001 до організації процесу розробки програмного забезпечення.

Таким чином, для оцінки якості процесу розробки у власній організації або організації підрядників можуть використовуватися вимоги керівництва ISO 9000-3. В даний час повсюдно вводиться у використання версія стандарту 2000 року, в якому на чільне місце ставиться управління процесом, проте в даній версії стандарту специфіка, пов'язана з розробкою ПЗ відсутня.

Недоліком стандарту ISO 9000 є труднощі виміру рівня якості процесу розробки програмного забезпечення відповідно до запропонованої моделі якості.

Серед розробників програмного забезпечення особливо там (насамперед у США) великим рейтингом користується альтернативна модель якості: СММ - SEI. Ця модель якості розроблена в інституті інженерії програмного забезпечення (Software Engineering Institute) при спонсорстві міністерства оборони США. Спочатку дана модель якості використовувалася державними, зокрема військовими, організаціями для розміщення замовлень на розробку програмного забезпечення. В даний час стандарт широко використовується для аналізу та сертифікації процесів розробки програмного забезпечення фірм, які виробляють складне програмне забезпечення у критичних сферах застосування. Важливими перевагами моделі СММ є ієрархічна вкладеність моделей якості, яка дозволяє вимірювати та порівнювати рівні якості процесів у різних організаціях та забезпечувати ефективне вдосконалення якості процесів.

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

У певному відношенні моделі якості СММ та ISO є взаємозамінними, проте, по суті, вони не суперечать одна одній, оскільки ґрунтуються на одній парадигмі якості – TQM – Total Quality Management.

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

Якість програмного продукту

Якість програмних компонент

Розробка сучасних великих програмних систем нині дедалі більше базується на компонентної розробці (Component Base System – CBS). Технологія побудови CBS дозволяє значно знизити вартість та час розробки. У той самий час зростає ризик, що з використанням у системі програмних компонент розроблених різними виробниками.

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

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

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

Метрики

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

• порядок зростання (мається на увазі аналіз алгоритмів у термінах асимптотичного аналізу та 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 … Вікіпедія

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

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

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

Таблиця 1.3.

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

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

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

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

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

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

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

Першою топологічною мірою складності є цикломатичний захід Мак-Кейба. У основі лежить ідея оцінки складності ПЗ за кількістю базисних шляхів у її керуючому графі, тобто. таких шляхів, компонуючи які можна отримати всілякі шляхи із входу графа у виходи. Цикломатичне число (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. Коли керуючий граф програми має лише одну компоненту зв'язності, міра Чена збігається з цикломатичною мірою Мак-Кейба.

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

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

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