Курсовая работа: Емпіричне дослідження програмного забезпечення

Зміст

1. Завдання. 2

2. Призначення, описання й характеристики властивості ПЗ та метрик. 4

2.1 Пояснення до експертних оцінок. 4

2.2 Пояснення метрик ПЗ за варіантом. 5

3. Опис алгоритмів та засобів. 7

4. Первинний статистичний аналіз метрик та експертних оцінок. 8

4.1 Openproj-1.4-src. 10

4.2 TalendOpen Studio 3.2.1. 13

4.3 Plazma-source 0.1.8. 15

4.4 Статичний аналіз трьох проектів разом. 17

5. Кореляційний аналіз. 20

5.1 Openproj-1.4-src. 20

5.2 TalendOpen Studio 3.2.1. 21

5.3 Рlazma-source 0.1.8. 22

5.4 Кореляційний аналіз трьох проектів разом. 23

6. Регресійний аналіз. 26

Загальні висновки по курсовій роботі 28

1. Завдання

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

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

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

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

Значення експертних оцінок отримати з лабораторної роботи № 5, значення метрик (прямих та непрямих) отримати з лабораторної роботи № 6. Метрики та експертні оцінки повинні бути отримані для одних і тих самих проектів. Для достовірності отриманих даних по кожній метриці повинно бути отримано не менше 2000 значень (з лабораторної роботи № 6), експертних оцінок – не менше 15-и. Залежності будувати між 5-ма прямими метриками та експертною оцінкою, 5-ма непрямими метриками та експертною оцінкою (використати метрики з лабораторної роботи № 6).

Отримані результати по залежностях між метриками та експертними оцінками порівняти із результатами побудови залежностей між прямими та непрямими метриками в лабораторних роботах № 4 та 5. Визначити чи мають спільні тенденції залежності між тими прямими метриками та експертними оцінками, непрямими метриками та експертними оцінками, які мають залежності між собою (прямі-непрямі метрики). Пояснити чому.

Таблиця №1

Варіанти індивідуальних завдань

2. Призначення, описання й характеристики властивості ПЗ та метрик

Таблиця №2

Експертні оцінки властивостей ПЗ

2.1 Пояснення до експертних оцінок

Openproj-1.4-src

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

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

TalendOpen Studio 3.2.1

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

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

plazma-source 0.1.8

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

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

Нотатка. Під час виконання курсової роботи було проаналізовано також такі властивості програмного забезпеченя, як зрозумілість, повнота, стислість, портованість, узгодженість, тестованість, юзабіліті, надійність, структурованість, ефективність, безпека, зрозумілість інтерфейсу, зрозумілість повідомлень про помилки, очікуваність функціональності та документація. Усі експертні оцінки додаються у документі формату Microsoft Office Word «Додаток до курсової роботи»

2.2 Пояснення метрик ПЗ за варіантом

LOC – метрика, що вказує на кількість фізичних рядків коду.

NOM – метрика, що вказує на кількість методів у програмному коді.

NOC – метрика, що вказує на кількість класів у проекті.

NDD – метрика, що вказує на кількість кількості прямих нащадків.

CALL – метрика, що вказує на кількість викликів методу.

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

TCC –метрика, що вказує на щільність згуртованості класу.

PNAS – метрика, що вказує на частки нових додаткових послуг.

BovR – метрика, що вказує на співвідношення перевизначених базових класів.

CDISP – метрика, що вказує на дисперсійний зв’язок.

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

3. Опис алгоритмів та засобів

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

Мал.1. Схема побудови залежностей

4. Первинний статистичний аналіз метрик та експертних оцінок

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

Кореляційний аналіз пар „метрика – експертна оцінка”

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

Регресійний аналіз залежних величин

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

При виконанні даної курсової роботи використовувався такий засіб автоматизації як Statistica. Statistica (торгова марка - STATISTICA) - пакет для всебічного статистичного аналізу, розроблений компанією StatSoft. У пакеті STATISTICA реалізовані процедури для аналізу даних (data analysis), управління даними (data management), видобутку даних (data mining), візуалізації даних (data visualization).

Для виконання завдання курсової роботи було використано також й наступне програмне забезпечення вимірювання IPlasma

Мал.2. Головне вікно IPlasma

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

Метрики IPlasma можуть бути поділенні на наступні категорії:

Метрики розміру – включають розміри об’єкту аналізу(наприклад, Lines of Code)

Метрики складності – включають складність об’єкту дослідження(наприклад, Cyclomatic Complexity)

Метрики взаємозв’язку – включає обмін даними між об’єктами (наприклад, Coupling Between Objects)

Метрики зв’язаності класів – включає зв’язаність класів між собою(наприклад, Tight Class Cohesion)

Платформа інструменту починається безпосередньо з вихідного коду (C++ або Java) і забезпечує повну підтримку, яка потрібна для всіх фаз залучення в процес аналізу: від граматичного аналізу коду і побудови моделі до легкого визначення бажаних аналізів, у тому числі виявлення дублювання коду. Істотне (і дуже неприємне) завдання в процесі аналізу програмного забезпечення - побудова належної моделі системи.

Мета будівництва моделі - витягування з вихідного коду інформації, яка доречна з точки зору специфічної мети. Для цього використовується відкрита бібліотека для аналізу Recoder (для Java) та McC (Model Capture for C++).

Інструмент iPlasma розвивався як пошуковий інструмент. Він успішно застосовувався для аналізу проектів ряду ”real-world” систем, у тому числі самі великі системи (>1 MLOC), подібно до mozilla (C++, 2.56-мільйонів LOC) і eclipse (Java, 1.36-мільйонів LOC).

4.1 Openproj-1.4-src

Було проведено статичний аналіз за допомогою Statistica для проекту Openproj-1.4-src для метрик зазначених у варіанті. Для метрик було обчислено статистичні характеристики(математичне сподівання, середнє квадратичне відхилення, коефіцієнти ексцесу та асиметрії). Також довірчий інтервал, на основі якого було відсіяно значення метрик, що не потрапляють в нього. Для кожної метрики було визначено закон розподілу. Документ з усіма обчисленнями додається у форматі STATISTICA Workbook «Openproj».

Мал.3. Проведений статичний аналіз за допомогою Statistica для метрик LOC, NOC, HDD, CALL, WMC та BOvR

Мал.4. Проведений статичний аналіз за допомогою Statistica для метрик TCC, CDISP та PNAS

4.2 TalendOpen Studio 3.2.1

Мал.5. Проведений статичний аналіз за допомогою Statistica для метрик LOC, NOC, HDD, CALL, WMC та BOvR

Мал. 6. Проведений статичний аналіз за допомогою Statistica для метрик TCC, CDISP та PNAS

Було проведено статичний аналіз за допомогою Statistica для проекту TalendOpen Studio 3.2.1 для метрик зазначених у варіанті. Для метрик було обчислено статистичні характеристики(математичне сподівання, середнє квадратичне відхилення, коефіцієнти ексцесу та асиметрії). Також довірчий інтервал, на основі якого було відсіяно значення метрик, що не потрапляють в нього. Для кожної метрики було визначено закон розподілу. Документ з усіма обчисленнями додається у форматі STATISTICA Workbook «TalendOpen Studio».

4.3 Plazma-source 0.1.8

Мал.7. Проведений статичний аналіз за допомогою Statistica для метрик LOC, NOC, HDD, CALL, WMC та BOvR

Мал. 8. Проведений статичний аналіз за допомогою Statistica для метрик TCC, CDISP та PNAS

Було проведено статичний аналіз за допомогою Statistica для проекту plazma-source 0.1.8 для метрик зазначених у варіанті. Для метрик було обчислено статистичні характеристики(математичне сподівання, середнє квадратичне відхилення, коефіцієнти ексцесу та асиметрії). Також довірчий інтервал, на основі якого було відсіяно значення метрик, що не потрапляють в нього. Для кожної метрики було визначено закон розподілу. Документ з усіма обчисленнями додається у форматі STATISTICA Workbook «plazma-source».

4.4 Статичний аналіз трьох проектів разом

Первинний статичний аналіз було проведено для усіх трьох проектів разом. В результаті, було отримано нові статичні показники та побудовано гістограми. Усі обчислення та побудови представлені в додатковому документі формату STATISTICA Workbook «Курсовий проект».

Мал.9. Первинний статичний аналіз для метрик LOC, NOC, CALL, WMC, BovR на основі усіх трьох проектів

Мал.10. Первинний статичний аналіз для метрик TCC, CDISP, PNAS на основі усіх трьох проектів

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

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

5. Кореляційний аналіз

Кореляційний аналіз проводиться на основі отриманих значень метрик по варіанту та експертних оцінок властивостей ПЗ також по варіанту.

5.1 Openproj-1.4-src

Таблиця №3. Коефіцієнт кореляції

У даній таблиці приведено обчислення коефіцієнта кореляції кожної метрики проекту Openproj-1.4-src відносно однієї з властивостей ПЗ, а саме легкості у використанні.

Таблиця №4. Коефіцієнт кореляції

У даній таблиці приведено обчислення коефіцієнта кореляції кожної метрики проекту Openproj-1.4-src відносно однієї з властивостей ПЗ, а саме супроводжуваності програмного продукту.

НОТАТКА. Усі обчислення коефіцієнтів кореляції для проекту Openproj-1.4-src додано у документі формату STATISTICA Workbook «Openproj_кореляція».

5.2 TalendOpen Studio 3.2.1

Таблиця №5. Коефіцієнт кореляції

У даній таблиці приведено обчислення коефіцієнта кореляції кожної метрики проекту TalendOpen Studio 3.2.1 відносно однієї з властивостей ПЗ, а саме легкості у використанні.

У таблиці 6 приведено обчислення коефіцієнта кореляції кожної метрики проекту TalendOpen Studio 3.2.1 відносно однієї з властивостей ПЗ, а саме супроводжуваності програмного продукту.

Таблиця №6. Коефіцієнт кореляції

НОТАТКА. Усі обчислення коефіцієнтів кореляції для проекту TalendOpen Studio 3.2.1 додано у документі формату STATISTICA Workbook «TalendOpen Studio_кореляція».

5.3 Рlazma-source 0.1.8

Таблиця №7. Коефіцієнт кореляції

У даній таблиці приведено обчислення коефіцієнта кореляції кожної метрики проекту plazma-source 0.1.8 відносно однієї з властивостей ПЗ, а саме легкості у використанні.

Таблиця №8. Коефіцієнт кореляції

У даній таблиці приведено обчислення коефіцієнта кореляції кожної метрики проекту plazma-source 0.1.8 відносно однієї з властивостей ПЗ, а саме супроводжуваності програмного продукту.

НОТАТКА. Усі обчислення коефіцієнтів кореляції для проекту plazma-source 0.1.8 додано у документі формату STATISTICA Workbook «plazma-source_кореляція».

5.4 Кореляційний аналіз трьох проектів разом

Кореляційний аналіз було проведено для усіх трьох проектів разом. В результаті, було отримано нові коефіцієнти кореляції. Усі обчислення представлені в додатковому документі формату STATISTICA Workbook «Курсовий проект_кореляція».

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

Таблиця №9 Коефіцієнт кореляції

Таблиця №10 Коефіцієнт кореляції

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

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

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

6. Регресійний аналіз

На основі попередніх обчислень було проведено регресійний аналіз, результатом якого є побудова ліній регресії. Побудовані лінії регресії представлені нижче. Усі обчислення та сама побудова ліній регресії представлена у додатковому документі формату STATISTICA Workbook «Курсовий проект_регресія».

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

Мал.12. Регресійний аналіз метрики NOC відносно експертної оцінки властивості «Легкість у виконанні»

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

Загальні висновки по курсовій роботі

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

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

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

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