🗊Презентация Контроль і гарантія якості

Лекція 9. Контроль і гарантія якості В архітектурі процесів ЖЦ ПС це завдання двох процесів: Забезпечення гарантії якості (SQA) Управління якістю (Quality management) Існує дві категорії об’єктів забезпечення гарантії якості і пов’язаних з ними задач: робочі продукти і процеси ЖЦ Гарантуючи якість роб. продуктів необхідно впевнитись в тому, що: Усі плани належним чином документовані, узгоджені і виконувані Робочі продукти і пов’язана з ними документація узгоджуються з умовами договорів і відповідають вимогам планів Продукти повністю задовольняють поставленим до них вимогам і є прийнятними для замовника.

Гарантуючи якість процесів необхідно впевнитись в тому, що: Усі процеси ЖЦ узгоджуються з планами; Застосовані засоби програмної інженерії; середовище розробки, середовище тестування узгоджуються з договором; Замовник забезпечується необхідною підтримкою згідно з договорами; Метрики продуктів і процесів відповідають затвердженим стандартам і процедурам; Назначений штат виконавців має досвід і знання, необхідні для досягнення цілей проекту.

Вимоги до підготовки компетентних спеціалістів

В 1995 р. У. Хамфрі запропонував концепцію «персонального процесу учасника розробки ПЗ» (PSP, “Personal Software Process”). PSP – це схема і сукупність методів індивідуальної професійної діяльності виконавців процесів ЖЦ, заснованої на принципах планування, обліку, самоконтролю і особистої відповідальності за якість рішень, що приймаються. Підвищення якості продукту досягається по ключовим аспектам: Аналізуючи усі допущені дефекти, виконавець визначає причини власних помилок і намагається працювати уважніше Аналізуючи дефекти, виконавець починає усвідомлювати вартість їх усунення і необхідність визначення найбільш ефективних способів виявлення і локалізації дефектів Виконавець використовує ефективні практичні прийоми PSP для попередження появи помилок в майбутньому. PSP визначається на семи рівнях (звичні прийоми роботи і вивчення основ PSP - адаптація PSP до усіх великих проектів).

Колективний процес розробки ПЗ (TSP, Team Software Process). Під час 4-денного періоду налаштування усі члени команди визначають стратегію роботи по проекту на 3-4 місяці, складають колективний та індивідуальні плани робіт. People CMM (people capability maturity model – модель зрілості процесу управління кадрами). Рівень 1 (початковий): Неузгодженість дій Перекладання відповідальності Дотримання ритуалу відособленість учасників проекту

Рівень 2 (керований): виробничі перенавантаження неділова атмосфера неочевидні цільові показники нестача необхідних знань або досвіду погана взаємодія поганий моральний стан Рівень 3 (визначений): спеціалізація персоналу по видам діяльності і рівням кваліфікації планування робіт із врахуванням рівнів кваліфікації «вузька» спеціалізація процесів Створена інфраструктура для вимірювання кваліфікації

Рівень 4 (передбачуваний): Керування трудовими ресурсами на кількісній основі Рівень компетентності персоналу відповідає специфіці спеціального процесу, що виконується Обґрунтована довіра менеджерів до результатів роботи Рівень 5 (оптимізований): Вдосконалення персоналу Вдосконалення на індивідуальному та колективному рівнях Постійний пошук механізмів вдосконалення індивідуальної роботи

Ключові метрики для контролю розробки: Метрики трудомісткості та вартості розробки Метрики розміру і складності програмного продукту Метрики помилок Трудомісткість та вартість розробки Основні методи оцінки: COCOMO (COnstructive COst MOdel), FPA (Function Point Analysis). Метрики розміру програмного продукту: SLOC (Source Lines of Code) – число рядків коду FPA (function point analysis) – методологія аналізу показників функціонального розміру.

Метрики складності: метрики Холстеда; метрика «цикломатичне число» МакКейба; метрика Джілба; метрика Чепіна.

Метрики Холстеда: n1 – кількість різних операторів, n2 – кількість різних операндів, N1 – загальна кількість операторів, N2 – загальна кількість операндів, розмір програми: N = N1 + N2 , розмір словника: n = n1 + n2, прогнозований розмір: N’ = n1∙ log2n1 + n2∙ log2n2, об’єм програми: V = N ∙log2n, трудомісткість розробки: E = n1∙ N2∙ N∙ log2n / (2∙ n2), час, необхідний на розробку: T = E / 18, кількість помилок (перед інтеграційним тестуванням): B = V/3000.

Метрика МакКейба C заснована на аналізі керуючого графу програми. С = e – n + 2. C – цикломатична складність. е – кількість ребер на графі. n – кількість вузлів. Для забезпечення супроводжуваності і можливості тестування коду бажано, щоб С ≤ 10. Метрика Джілба cl − відносна складність програми cl = CL / N1, де CL − абсолютна складність програми (кількість умовних операторів).

Метрика Чепіна Q − оцінка інформаційної надійності програмного модуля. Q = a1P+a2M+a3C+a4T. P – кількість вхідних параметрів, M – кількість змінних, що модифікуються, C – кількість змінних, які присутні у керуючих конструкціях, T – кількість оголошених змінних, які не використо-вуються у модулі. Формула для типового набору коефіцієнтів a1, a2, a3, a4: Q = P + 2M + 3C + 0,5T.

Метрики Холстеда Оператор = if >= − < return

Метрики складності МакКейба, Джілба та Чепіна Метрика МакКейба: С = e – n + 2. е = 8, n = 7, C = 8-7+2 = 3. Метрика Джілба: cl = CL / N1. CL = 2, N1 = 11. cl = 2 / 11 ≈ 0,18. Метрика Чепіна: Q = P + 2M + 3C + 0,5T. P = 2, M = 1, C = 3, T = 0. Q = 2 + 2∙1 + 3 ∙ 3 + 0,5 ∙ 0 =13.

Метрики, які використовуються в ООП: Цикломатична складність – оцінка складності алгоритму методу Зважене число методів в класі – визначається кількістю методів, реалізованих в класі або сумою оцінок цикломатичної складності кожного. Кількість віддалених методів, що викликаються. Відгук на клас – сума числа локальних і віддалених методів. Чим більше число методів, що можуть бути викликані з класу повідомленнями, – тим складніше клас. Недостатність зв’язності методів – число пар методів, що не мають спільних атрибутів. Зчеплення між класами – кількість окремих ієрархій класів, які залежать від даного класу. Чим слабше зчеплення – тим краще. Глибина дерева наслідування. Кількість нащадків – число безпосередніх підкласів (чим більше – тим більша ймовірність невдалої абстракції класу).

Метрики помилок Не досягнуто повної узгодженості між основними поняттями: відмова, дефект, помилка. В англ. літературі – anomaly, error, fault, failure, incident, flaw, problem, gripe, glitch, defect, bug. Відмова (failure) – подія переходу ПС із працездатного стану в непрацездатний або отримання результатів за межами допустимих значень. Дефект (defect) – запис елементу програми або тексту документу, використання якої може призвести до неправильної інтерпретації цього елемента комп’ютером (fault) або людиною (error). Схема відмови програми: дефект в коді (defect) – [помилка (fault)] – аномалія (anomaly) = відмова (failure)

Графічні інструменти аналізу якості. Таблиця розшарування даних. Множина даних розшаровується виходячи з двох критеріїв (наприклад «тип дефекту» та «дата виявлення»). Діаграма виконання (Run Chart) або часовий графік.

Діаграма розсіяння (Scatter Diagram). Перевірка гіпотез щодо залежності між двома величинами.

Діаграма стовпчиків (Bar chart).

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

Діаграми Парето

Контрольні карти (Х-карти)

Причинно-наслідова діаграма (діаграма Ісікави, «риб'яча кість»). C&E – Cause and Effect diagram