Емпіричне дослідження програмного забезпечення (стр. 1 из 3)
Зміст
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
Метою курсової роботи є практичне засвоєння методів емпіричної інженерії програмного забезпечення та алгоритмів збору й аналізу даних.
Завдання включає вимірювання програмного забезпечення, аналіз і вибір прямих та непрямих метрик для дослідження та визначення залежностей між прямими та непрямими метриками.
Побудувати залежності між метриками ПЗ та експертною оцінкою властивості ПЗ. Метрики та властивості використати згідно індивідуального варіанту.
Побудова залежності між метриками та експертною оцінкою включає побудову залежностей між прямими метриками та експертною оцінкою, непрямими метриками та експертною оцінкою.
Значення експертних оцінок отримати з лабораторної роботи № 5, значення метрик (прямих та непрямих) отримати з лабораторної роботи № 6. Метрики та експертні оцінки повинні бути отримані для одних і тих самих проектів. Для достовірності отриманих даних по кожній метриці повинно бути отримано не менше 2000 значень (з лабораторної роботи № 6), експертних оцінок – не менше 15-и. Залежності будувати між 5-ма прямими метриками та експертною оцінкою, 5-ма непрямими метриками та експертною оцінкою (використати метрики з лабораторної роботи № 6).
Отримані результати по залежностях між метриками та експертними оцінками порівняти із результатами побудови залежностей між прямими та непрямими метриками в лабораторних роботах № 4 та 5. Визначити чи мають спільні тенденції залежності між тими прямими метриками та експертними оцінками, непрямими метриками та експертними оцінками, які мають залежності між собою (прямі-непрямі метрики). Пояснити чому.
Таблиця №1
Варіанти індивідуальних завдань
| Властивості | Прямі метрики | Непрямі метрики |
| Легкість виконання операцій, Супроводжуваність | LOC, NOC, HDD, CALL, NOM | WMC, TCC, PNAS, BovR, CDISP |
2. Призначення, описання й характеристики властивості ПЗ та метрик
Таблиця №2
Експертні оцінки властивостей ПЗ
| Openproj-1.4-src | TalendOpen Studio 3.2.1 | plazma-source 0.1.8 | |
| Зрозумілість | 9 | 8 | 7 |
| Повнота | 10 | 8 | 9 |
| Стислість | 8 | 7 | 9 |
| Портованість | 3 | 9 | 9 |
| Узгодженість | 9 | 8 | 3 |
| Супроводжуваність | 7 | 6 | 5 |
| Тестованість | 7 | 8 | 9 |
| Юзабіліті | 10 | 9 | 7 |
| Надійність | 9 | 7 | 6 |
| Структурованість | 10 | 8 | 7 |
| Ефективність | 9 | 8 | 8 |
| Безпека | 9 | 8 | 4 |
| Зрозумілість інтерфейсу | 10 | 9 | 10 |
| Легкість виконання операцій | 10 | 8 | 9 |
| Зрозумілість повідомлень про помилки | 5 | 9 | 8 |
| Очікуваність функціональності | 10 | 8 | 10 |
| Документованість | --- | 9 | 6 |
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 «Додаток до курсової роботи».
Статистичний аналіз, який виконується з метою визначення залежностей між метриками, складається з трьох етапів: первинний статистичний аналіз, кореляційний аналіз та регресійний аналіз. У даній курсовій роботі використовувалась наступна схема побудови залежностей.
Мал.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) і забезпечує повну підтримку, яка потрібна для всіх фаз залучення в процес аналізу: від граматичного аналізу коду і побудови моделі до легкого визначення бажаних аналізів, у тому числі виявлення дублювання коду. Істотне (і дуже неприємне) завдання в процесі аналізу програмного забезпечення - побудова належної моделі системи.