Контроль і гарантія якості

Июль 23, 2022

Главная
Информатика
Контроль і гарантія якості

Содержание

2. Гарантуючи якість процесів необхідно впевнитись в тому, що: Усі процеси ЖЦ узгоджуються з планами; Застосовані засоби
3. Вимоги до підготовки компетентних спеціалістів
4. В 1995 р. У. Хамфрі запропонував концепцію «персонального процесу учасника розробки ПЗ» (PSP, “Personal Software Process”).
5. Колективний процес розробки ПЗ (TSP, Team Software Process). Під час 4-денного періоду налаштування усі члени команди
6. Рівень 2 (керований): виробничі перенавантаження неділова атмосфера неочевидні цільові показники нестача необхідних знань або досвіду погана
7. Рівень 4 (передбачуваний): Керування трудовими ресурсами на кількісній основі Рівень компетентності персоналу відповідає специфіці спеціального процесу,
8. Ключові метрики для контролю розробки: Метрики трудомісткості та вартості розробки Метрики розміру і складності програмного продукту
9. Метрики складності: метрики Холстеда; метрика «цикломатичне число» МакКейба; метрика Джілба; метрика Чепіна.
10. Метрики Холстеда: n1 – кількість різних операторів, n2 – кількість різних операндів, N1 – загальна кількість
11. Метрика МакКейба C заснована на аналізі керуючого графу програми. С = e – n + 2.
12. Метрика Чепіна Q − оцінка інформаційної надійності програмного модуля. Q = a1P+a2M+a3C+a4T. P – кількість вхідних
13. int f(int a, int b) { int result = 0; if(a >= b) result = a
14. Метрики Холстеда Оператор = if >= − return Частота 4 2 1 2 1 1 Операнд
15. Метрики складності МакКейба, Джілба та Чепіна Метрика МакКейба: С = e – n + 2. е
16. Метрики, які використовуються в ООП: Цикломатична складність – оцінка складності алгоритму методу Зважене число методів в
17. Метрики помилок Не досягнуто повної узгодженості між основними поняттями: відмова, дефект, помилка. В англ. літературі –
18. Графічні інструменти аналізу якості. Таблиця розшарування даних. Множина даних розшаровується виходячи з двох критеріїв (наприклад «тип
19. Діаграма розсіяння (Scatter Diagram). Перевірка гіпотез щодо залежності між двома величинами.
20. Діаграма стовпчиків (Bar chart).
21. Гістограма. Створюється шляхом групування результатів вимірювань по секціям і підрахунку кількості попадання виміряних значень в кожну
22. Діаграми Парето
23. Контрольні карти (Х-карти)
25. Скачать презентацию

Слайд 2

Гарантуючи якість процесів необхідно впевнитись в тому, що:
Усі процеси ЖЦ узгоджуються

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

Слайд 3

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

Слайд 4

В 1995 р. У. Хамфрі запропонував концепцію «персонального процесу учасника розробки

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

Слайд 5

Колективний процес розробки ПЗ (TSP, Team Software Process). Під час 4-денного

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

Слайд 6

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

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

Слайд 7

Рівень 4 (передбачуваний):
Керування трудовими ресурсами на кількісній основі
Рівень компетентності персоналу відповідає

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

Слайд 8

Ключові метрики для контролю розробки:
Метрики трудомісткості та вартості розробки
Метрики розміру і

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

Слайд 9

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

Слайд 10

Метрики Холстеда:
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.

Слайд 11

Метрика МакКейба C заснована на аналізі керуючого графу програми.
С = e

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

Слайд 12

Метрика Чепіна Q − оцінка інформаційної надійності програмного модуля.
Q = a1P+a2M+a3C+a4T.
P

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

Слайд 13

int f(int a, int b)
{
int result = 0;
if(a >= b)
result =

a − b;
else
result = b − a;
if(result < 5)
result = 0;
return result;
}

Приклад обчислення метрик складності для функції:

Слайд 14

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

Частота
4
2
1
2
1
1

Операнд
a
b
result
0
5

Частота
3
3
6
2
1

n1 = 6, N1 = 11. n2 = 5, N2 = 15.
Розмір словника: n = 6 + 5 = 11.
Розмір програми: N = 11+15 = 26.
Прогнозований розмір: N’= 6∙log26 + 5∙log25 ≈ 27,12.
Об’єм програми: V = 26 ∙log211 = 89,95.
Трудомісткість розробки: E = 6∙15∙26∙log211 / (2∙5) ≈ 809,71.
Час, необхідний для розробки: T = E / 18 ≈ 45 c.
Кількість помилок: B = V / 3000 ≈ 0,03.

Слайд 15

Метрики складності МакКейба, Джілба та Чепіна
Метрика МакКейба:
С = 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.

Слайд 16

Метрики, які використовуються в ООП:
Цикломатична складність – оцінка складності алгоритму методу
Зважене

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

Слайд 17

Метрики помилок
Не досягнуто повної узгодженості між основними поняттями: відмова, дефект, помилка.

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

Слайд 18

Графічні інструменти аналізу якості.
Таблиця розшарування даних. Множина даних розшаровується виходячи з

двох критеріїв (наприклад «тип дефекту» та «дата виявлення»).
Діаграма виконання (Run Chart) або часовий графік.

Слайд 19

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

Слайд 20

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

Слайд 21

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

попадання виміряних значень в кожну секцію.

Слайд 22

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

Слайд 23

Контроль і гарантія якості

Содержание

Гарантуючи якість процесів необхідно впевнитись в тому, що:Усі процеси ЖЦ узгоджуються

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

В 1995 р. У. Хамфрі запропонував концепцію «персонального процесу учасника розробки

Колективний процес розробки ПЗ (TSP, Team Software Process). Під час 4-денного

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

Рівень 4 (передбачуваний):Керування трудовими ресурсами на кількісній основіРівень компетентності персоналу відповідає

Ключові метрики для контролю розробки:Метрики трудомісткості та вартості розробкиМетрики розміру і

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

Метрики Холстеда:n1 – кількість різних операторів,n2 – кількість різних операндів,N1 –

Метрика МакКейба C заснована на аналізі керуючого графу програми.С = e

Метрика Чепіна Q − оцінка інформаційної надійності програмного модуля.Q = a1P+a2M+a3C+a4T.P

int f(int a, int b){ int result = 0; if(a >= b) result =

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

Метрики складності МакКейба, Джілба та ЧепінаМетрика МакКейба: С = e –

Метрики, які використовуються в ООП:Цикломатична складність – оцінка складності алгоритму методуЗважене

Метрики помилокНе досягнуто повної узгодженості між основними поняттями: відмова, дефект, помилка.

Графічні інструменти аналізу якості.Таблиця розшарування даних. Множина даних розшаровується виходячи з