Презентация Контроль і гарантія якості онлайн
На нашем сайте вы можете скачать и просмотреть онлайн доклад-презентацию на тему Контроль і гарантія якості абсолютно бесплатно. Урок-презентация на эту тему содержит всего 24 слайда. Все материалы созданы в программе PowerPoint и имеют формат ppt или же pptx. Материалы и темы для презентаций взяты из открытых источников и загружены их авторами, за качество и достоверность информации в них администрация сайта не отвечает, все права принадлежат их создателям. Если вы нашли то, что искали, отблагодарите авторов - поделитесь ссылкой в социальных сетях, а наш сайт добавьте в закладки.
Презентации » Устройства и комплектующие » Контроль і гарантія якості
Оцените!
Оцените презентацию от 1 до 5 баллов!
- Тип файла:ppt / pptx (powerpoint)
- Всего слайдов:24 слайда
- Для класса:1,2,3,4,5,6,7,8,9,10,11
- Размер файла:202.87 kB
- Просмотров:51
- Скачиваний:0
- Автор:неизвестен
Слайды и текст к этой презентации:
№1 слайд
![Лекц я . Контроль гарант я](/documents_6/f29319dbcad6685fb74d34dfd9f3e930/img0.jpg)
Содержание слайда: Лекція 9. Контроль і гарантія якості
В архітектурі процесів ЖЦ ПС це завдання двох процесів:
Забезпечення гарантії якості (SQA)
Управління якістю (Quality management)
Існує дві категорії об’єктів забезпечення гарантії якості і пов’язаних з ними задач: робочі продукти і процеси ЖЦ
Гарантуючи якість роб. продуктів необхідно впевнитись в тому, що:
Усі плани належним чином документовані, узгоджені і виконувані
Робочі продукти і пов’язана з ними документація узгоджуються з умовами договорів і відповідають вимогам планів
Продукти повністю задовольняють поставленим до них вимогам і є прийнятними для замовника.
№2 слайд
![Гарантуючи як сть процес в](/documents_6/f29319dbcad6685fb74d34dfd9f3e930/img1.jpg)
Содержание слайда: Гарантуючи якість процесів необхідно впевнитись в тому, що:
Усі процеси ЖЦ узгоджуються з планами;
Застосовані засоби програмної інженерії; середовище розробки, середовище тестування узгоджуються з договором;
Замовник забезпечується необхідною підтримкою згідно з договорами;
Метрики продуктів і процесів відповідають затвердженим стандартам і процедурам;
Назначений штат виконавців має досвід і знання, необхідні для досягнення цілей проекту.
№4 слайд
![В р. У. Хамфр запропонував](/documents_6/f29319dbcad6685fb74d34dfd9f3e930/img3.jpg)
Содержание слайда: В 1995 р. У. Хамфрі запропонував концепцію «персонального процесу учасника розробки ПЗ» (PSP, “Personal Software Process”).
PSP – це схема і сукупність методів індивідуальної професійної діяльності виконавців процесів ЖЦ, заснованої на принципах планування, обліку, самоконтролю і особистої відповідальності за якість рішень, що приймаються.
Підвищення якості продукту досягається по ключовим аспектам:
Аналізуючи усі допущені дефекти, виконавець визначає причини власних помилок і намагається працювати уважніше
Аналізуючи дефекти, виконавець починає усвідомлювати вартість їх усунення і необхідність визначення найбільш ефективних способів виявлення і локалізації дефектів
Виконавець використовує ефективні практичні прийоми PSP для попередження появи помилок в майбутньому.
PSP визначається на семи рівнях (звичні прийоми роботи і вивчення основ PSP - адаптація PSP до усіх великих проектів).
№5 слайд
![Колективний процес розробки](/documents_6/f29319dbcad6685fb74d34dfd9f3e930/img4.jpg)
Содержание слайда: Колективний процес розробки ПЗ (TSP, Team Software Process). Під час 4-денного періоду налаштування усі члени команди визначають стратегію роботи по проекту на 3-4 місяці, складають колективний та індивідуальні плани робіт.
People CMM (people capability maturity model – модель зрілості процесу управління кадрами).
Рівень 1 (початковий):
Неузгодженість дій
Перекладання відповідальності
Дотримання ритуалу
відособленість учасників проекту
№6 слайд
![Р вень керований виробнич](/documents_6/f29319dbcad6685fb74d34dfd9f3e930/img5.jpg)
Содержание слайда: Рівень 2 (керований):
виробничі перенавантаження
неділова атмосфера
неочевидні цільові показники
нестача необхідних знань або досвіду
погана взаємодія
поганий моральний стан
Рівень 3 (визначений):
спеціалізація персоналу по видам діяльності і рівням кваліфікації
планування робіт із врахуванням рівнів кваліфікації
«вузька» спеціалізація процесів
Створена інфраструктура для вимірювання кваліфікації
№7 слайд
![Р вень передбачуваний](/documents_6/f29319dbcad6685fb74d34dfd9f3e930/img6.jpg)
Содержание слайда: Рівень 4 (передбачуваний):
Керування трудовими ресурсами на кількісній основі
Рівень компетентності персоналу відповідає специфіці спеціального процесу, що виконується
Обґрунтована довіра менеджерів до результатів роботи
Рівень 5 (оптимізований):
Вдосконалення персоналу
Вдосконалення на індивідуальному та колективному рівнях
Постійний пошук механізмів вдосконалення індивідуальної роботи
№8 слайд
![Ключов метрики для контролю](/documents_6/f29319dbcad6685fb74d34dfd9f3e930/img7.jpg)
Содержание слайда: Ключові метрики для контролю розробки:
Метрики трудомісткості та вартості розробки
Метрики розміру і складності програмного продукту
Метрики помилок
Трудомісткість та вартість розробки
Основні методи оцінки:
COCOMO (COnstructive COst MOdel),
FPA (Function Point Analysis).
Метрики розміру програмного продукту:
SLOC (Source Lines of Code) – число рядків коду
FPA (function point analysis) – методологія аналізу показників функціонального розміру.
№10 слайд
![Метрики Холстеда n к льк сть](/documents_6/f29319dbcad6685fb74d34dfd9f3e930/img9.jpg)
Содержание слайда: Метрики Холстеда:
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 заснована](/documents_6/f29319dbcad6685fb74d34dfd9f3e930/img10.jpg)
Содержание слайда: Метрика МакКейба C заснована на аналізі керуючого графу програми.
С = e – n + 2.
C – цикломатична складність.
е – кількість ребер на графі.
n – кількість вузлів.
Для забезпечення супроводжуваності і можливості тестування коду бажано, щоб С ≤ 10.
Метрика Джілба cl − відносна складність програми
cl = CL / N1,
де CL − абсолютна складність програми (кількість умовних операторів).
№12 слайд
![Метрика Чеп на Q оц нка](/documents_6/f29319dbcad6685fb74d34dfd9f3e930/img11.jpg)
Содержание слайда: Метрика Чепіна Q − оцінка інформаційної надійності програмного модуля.
Q = a1P+a2M+a3C+a4T.
P – кількість вхідних параметрів,
M – кількість змінних, що модифікуються,
C – кількість змінних, які присутні у керуючих конструкціях,
T – кількість оголошених змінних, які не використо-вуються у модулі.
Формула для типового набору коефіцієнтів a1, a2, a3, a4:
Q = P + 2M + 3C + 0,5T.
№15 слайд
![Метрики складност МакКейба,](/documents_6/f29319dbcad6685fb74d34dfd9f3e930/img14.jpg)
Содержание слайда: Метрики складності МакКейба, Джілба та Чепіна
Метрика МакКейба:
С = 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 слайд
![Метрики, як використовуються](/documents_6/f29319dbcad6685fb74d34dfd9f3e930/img15.jpg)
Содержание слайда: Метрики, які використовуються в ООП:
Цикломатична складність – оцінка складності алгоритму методу
Зважене число методів в класі – визначається кількістю методів, реалізованих в класі або сумою оцінок цикломатичної складності кожного.
Кількість віддалених методів, що викликаються.
Відгук на клас – сума числа локальних і віддалених методів. Чим більше число методів, що можуть бути викликані з класу повідомленнями, – тим складніше клас.
Недостатність зв’язності методів – число пар методів, що не мають спільних атрибутів.
Зчеплення між класами – кількість окремих ієрархій класів, які залежать від даного класу. Чим слабше зчеплення – тим краще.
Глибина дерева наслідування.
Кількість нащадків – число безпосередніх підкласів (чим більше – тим більша ймовірність невдалої абстракції класу).
№17 слайд
![Метрики помилок Не досягнуто](/documents_6/f29319dbcad6685fb74d34dfd9f3e930/img16.jpg)
Содержание слайда: Метрики помилок
Не досягнуто повної узгодженості між основними поняттями: відмова, дефект, помилка. В англ. літературі – anomaly, error, fault, failure, incident, flaw, problem, gripe, glitch, defect, bug.
Відмова (failure) – подія переходу ПС із працездатного стану в непрацездатний або отримання результатів за межами допустимих значень.
Дефект (defect) – запис елементу програми або тексту документу, використання якої може призвести до неправильної інтерпретації цього елемента комп’ютером (fault) або людиною (error).
Схема відмови програми:
дефект в коді (defect) – [помилка (fault)] – аномалія (anomaly) = відмова (failure)
Скачать все slide презентации Контроль і гарантія якості одним архивом:
Похожие презентации
-
Разработка логического контроллера малой автоматизации и ПО для упрощенного программирования
-
Микроконтроллеры. Платформа Arduino
-
Контроллер. Проектирование и разработка веб-сервисов
-
Создание программ на контроллере EV3
-
Проектирование метеостанции на микроконтроллере Atmega 328
-
Моделі і метрики якості програмних систем
-
Інженерія якості. Ядро професійних знань
-
Парадигма якості в програмній інженерії
-
Міжнародний стандарт якості програмних засобів ISO 9126
-
Средства отладки программ. Контроль текста программы