Тема: Методи оцінки ПП
План
Доповнення: ранжування метрик, етапи створення ПП
Існують різні методи оцінки програмних проектів:
2. Оцінка розміру проекту і трудовитрат розробки програмного проекту.
Найбільш впливовий фактор оцінки трудоємності в цих моделях − розмір програмного проекту. Процедура оцінки трудоємності розробки програмного проекту складається з наступних дій:
− оцінка розміру проекту, який розроблюється;
− оцінка трудоємності в людино-годинах (люд.-год.);
− оцінка тривалості проекту в календарних місяцях;
− оцінка вартості проекту.
Оцінка розміру проекту базується на знанні вимог до системи. Для такої оцінки існують два основних способи:
1. По аналогії. Якщо в минулому доводилось мати справу з подібним проектом і його оцінки відомі, то можливо, відштовхуватись від них, приблизно оцінити свій проект.
2. Шляхом підрахунку розміру по певним алгоритмам на основі вихідних даних − вимог до системи.
Основними одиницями виміру розміру програмного проекту є:
− кількість рядків коду (LOC − Lines of Code);
2. Оцінка розміру проекту і трудовитрат розробки програмного проекту.
При використанні LOC виникає ряд питань:
Насправді першорядне значення має набір функціональних властивостей і якості програмного продукту, а не кількість рядків коду.
В останній час широкий розвиток набули методика оцінки трудоємності на основі функціональних точок і методика оцінки трудоємності на основі варіантів використання.
1. Створення структури переліку робіт – задачі розбиваються на невеликі складові елементи для оцінювання розміру.
2. Документування планів – обчислюються величини, трудовитрати, накладні витрати.
3. Оцінка вартості і трудовитрат, необхідних для завершення проекту - завдяки оцінці можливого розміру ПЗ можна судити про розмір запланованих трудовитрат. Всі ці параметри відображуються в плані управління ПП, також створюється план ризиків.
4. Складання графіка – на основі оцінки трудовитрат можна скласти графік.
5. Вибір метричних показників - на базі застосовуваних одиниць виміру формується метричний показник. Його досить вибрати лише один раз, а потім просто посилатися.
Функціональність (functionality) – властивість ПС виконувати функції у відповідності встановленим і очікуваним потребам при використанні у вказаних умовах. Містить підхарактеристики:
3. Метод функціональних точок
Функціонально-орієнтовані метрики вимірюють програмний продукт і процес його розробки. Замість підрахунку LOC-оцінки при цьому розглядається не розмір, а функціональність або корисність продукта.
Переваги функціонально-орієнтованих метрик:
− не залежать від мови програмування;
− легко обчислюються на будь-якій стадії проекту.
1. Кількість зовнішніх вводів. Підраховуються всі вводи користувача, по яким поступають різні прикладні дані. Вводи повинні бути відділені від запитів, які підраховуються окремо.
2. Кількість зовнішніх виводів. Підраховуються всі виводи, по яким до користувача поступають результати, які обчислені програмним додатком. В цьому контексті виводи означають звіти, екрани, роздрукування, повідомлення про помилки. Індивідуальні одиниці даних всередині звіту окремо не підраховуються.
3. Кількість запитів. Під запитом розуміється діалоговий ввод, який приводить до негайної програмної відповіді в формі діалогового виводу. При цьому діалоговий ввод в додатку не зберігається, а діалоговий вивод не потребує виконання обчислень. Підраховуються всі запити— кожний враховується окремо.
4. Кількість внутрішніх логічних файлів. Підраховуються всі логічні файли (тобто логічні групи даних, які можуть бути частиною бази даних або окремим файлом).
5. Кількість зовнішніх інтерфейсных файлов. Підраховуються всі логічні файли з інших додатків, на які посилається даний додаток.
Метод функціональних точок дозволяє виконувати наступні завдання:
Короткий огляд процесу застосування функціональних точок:
- підраховуються функції в кожній категорії (перелік категорії: висновок, введення, опитування, структури даних і інтерфейси);
- визначається складність кожної функції - проста, середня, складна;
- встановлюються вимоги для кожної з категорій;
- кожна функція множиться на відповідний їй параметр, а потім підсумовується з метою отримання загальної кількості функціональних точок;
- Здійснюється перетворення функціональних точок в одиниці виміру LOC за допомогою наступної формули:
LOC = Функціональні точки * множник перетворення
ADJ позначає налаштування загальних характеристик програми. Множник перетворення грунтується на статистичних показниках для програми та мови програмування, представляючи середня кількість рядків коду, що застосовуються для реалізації простої функції.
Заповнення таблиці методом функціональних точок.
Заповнення таблиці методом функціональних точок.
2. Інструкції по визначенню рівня складності для вводу
Інструкції по визначенню рівня складності для виводу
Інструкції по визначенню рівня складності для запиту
Інструкції по визначенню рівня складності для внутрішніх логічних файлів
Інструкції по визначенню рівня складності для зовнішніх інтерфейсних файлів
4. Метод точок властивостей
Метод точок властивостей являє собою розширення методу функціональних точок, що застосовується для вимірювань в додатках різного типу, навіть таких, як вбудовані системи та/або системи реального часу. Точка властивостей представляє собою нову категорію функції, яка може представляти складні алгоритми і управління. В методі додається клас алгоритмів. Визначається алгоритм, як набір правил, який вирішує якусь істотну обчислювальну задачу. Наприклад обчислення квадратного кореня потрібно розглядати як алгоритм. Ця метри особливо корисна для таких систем, як математичне ПЗ, системи дискретного моделювання.
Вимір функціональності необхідно починати з визначення меж ПС.
Зазвичай функціональність даних представляється файлами, таблицями баз даних, об’єктами і іншими одиницями зберігання інформації. При аналізі по методу функціональних точок розглядаються два вида груп даних:
Транзакції – це елементарні процеси, тобто найменші одиниці активності, які мають сенс для користувача, і які відбуваються всередині ПС, породжуються вхідною і вихідною інформацією. В аналізі, основаному на методі FP, виділяють три види транзакцій:
Рівні складності для зовнішніх запитів (EQ) визначаються з використанням наступного простого алгоритму:
вхід зовнішнього запиту розглядається аналогічно зовнішньому входу (EI);
вихід зовнішнього запиту розглядається аналогічно зовнішньому виходу (EO);
3) як результат використовується найбільше значення з отриманих в п. 1 і 2 рівнів складності.
Для більшості представлених форм БД можна відмітити наступні характеристики:
Підрахунок методом FP графічного інтерфейсу
Рівні ранжування метрик
Класифікація мір та метрик якості
Стандарт ISO/IEC 9126-2 визначає наступні типи мір:
міра розміру – представляє розмір ПС в одиницях вимірювання (функціон. розмір, число функцій або модулів, кількість рядків у програмах, розмір дискової пам’яті та ін.); міра часу – періоди реального часу (у секундах, хвилинах, годинах процесорного часу, час функціонування системи); міра зусиль –корисний час пов’язаний з певним завданням (продуктивність праці, трудомісткість);
міра інтервалів між подіями (наприклад, час між відмовами);
рахункові міри – статичні лічильники для обліку певних елементів у робочих продуктах ПС (текстів програм та документації), або динамічні лічильники (вимірюють кількість помилок, число відмов, відповідей системи на запити тощо).
Метрики зазвичай класифікуються наступним чином:
Об’єктивна/суб’єктивна. Об’єктивна включає підрахунок елементів, які можуть бути незалежно перевірені (число операторів коду, число помилок); суб’єктивна ґрунтується на індивідуальному (експертному) розумінні певних властивостей (рівень складності проблем, модулів тощо).
Примітивні/такі що обчислюються. Примітивні – це базові метрики, які безпосередньо спостерігаються (розмір програми, число дефектів); такі що обчислюються – обчислюються на основі примітивних метрик (трудомісткість);
Динамічні/статичні. Динамічним метрикам властивий компонент часу (число помилок за місяць); статичні метрики не залежать від часу (число виявлених загалом дефектів); Такі що передбачаються (прогнозуючі)/пояснюючі. Значення прогнозуючих метрик отримують заздалегідь (прогнозована кількість відмов); значення пояснюючих з’являються постфактум (реальна інтенсивність відмов).
Зовнішні метрики використовують міри ПП, який працює на комп’ютері.
Такі міри отримують в результаті вимірювання поведінки ПС у ході тестування й функціонування відповідно до сценаріїв використання ПС.
Відповідні їм метрики використовують для демонстрації якості ПП, а також для підтвердження того, що ПП задовольняє зовнішнім вимогам до якості.
Приклади зовнішніх метрик для характеристики надійність – число усунутих дефектів, середній час між відмовами.
Внутрішні метрики дають можливість оцінити якість ПС безпосередньо по її властивостях (об’єм коду, число цикломатичності тощо).
Внутрішні метрики відображають якість проміжного й кінцевого ПП по тим характеристикам, які визначені в моделі. Ці метрики використовують для верифікації того, що проміжний та кінцевий продукти задовольняють вимогам до внутрішньої якості. Розробка внутрішніх метрик ґрунтується на виконанні вимірювань статичних атрибутів, які визначаються й оцінюються по тексту вихідного коду, а також по графічному представленню потоків керування, чи документам на ПС. Приклади для характеристики надійність – число помилок знайдених при інспекції коду, число усунутих дефектів при інспекції.
Метрики якості у використанні (експлуатаційні метрики) вимірюють ступінь, у якій ПП задовольняє потреби користувачів в ефективності, продуктивному й безпечному рішенні завдань. Ці метрики оцінюють видимі результати експлуатації ПС. Приклади – повнота досягнення цілей користувачів, точність результатів, продуктивність праці, думка користувачів.
Попередня оцінка якості
Статистичний метод добре підходить для вирішення подібних типових завдань і практично не підходить для прогнозу унікальних проектів. У випадку унікальних проектів застосовуються інші підходи, обговорення яких виходить за рамками даного матеріалу.
Виділимо типові етапи розробки ПЗ:
На етапі розробки специфікацій вимог до програми
Для оцінки результатів роботи даного етапу може бути використана метрика прогнозованого числа операторів програми:
Nпрогн = NF * Nод, де NF - кількість функцій чи вимог у специфікації вимог до програми, що розробляється;
Nод - одиничне значення кількості операторів (середня кількість операторів, що припадають на одну середню функцію або вимогу). Значення Nод - статистичне.
На етапі визначення архітектури
Ця оцінка визначається формулою:
Сі = NI / (NF * NIод * КСЛ)
де NI - загальна кількість змінних, що передаються через інтерфейси між компонентами програми (є статистичною);
Niод - одиничне значення кількості змінних, що передаються через інтерфейси між компонентами (середнє число переданих через інтерфейси змінних, що припадають на одну середню функцію або вимогу);
КСЛ - коефіцієнт складності програми , враховує зростання одиничної складності програми (складності, що припадає на одну функцію або вимога специфікації вимог) для великих і складних програм в порівнянні з середніми програмами.