Якість програмного

забезпечення

ЛІТЕРАТУРА
1. Орлик С. Программная инженерия. Сопровождение программного
обеспечения. – 2005.
2. Ф.И.Андон, Г.И.Коваль, Т.М. Коротун, В.Ю. Суслов . Основы
инженерии качества программных систем / Под ред. И.В.
Сергиенко. – К.: Академпериодика, 2007. – 672 с.
3. Канер С., Фолк Дж. и др. Тестирование программного
обеспечения. – К: Диасофт, 2001. – 544 с.
4. Брауде Э.Дж. Технология разработки программного обеспечения.
СпБ.: Питер, 2004 – 655 с.
5. Соммервилл Я. Инженерия программного обеспечения. – М.:
«Вильямс», 2002. – 624 с.
6. http://software-testing.ru
 Лекція 1. Якість програмного забезпечення
Що таке якість?

Зазвичай термін «якість» розуміють неправильно. Причини

1. Якість – це не окрема ідея або поняття, а багатомірна і

різнопланова концепція.
2. Для будь-якого поняття і визначення існує декілька рівнів
абстракції, наприклад, коли люди говорять про якість, одна
частина розуміє під цим занадто широкий і розмитий смисл, а
інша може вказувати на конкретне визначення.
3. Термін «якість» є невід’ємною частиною нашого
повсякденного спілкування, але загальноприйняте і
професійне використання може сильно відрізнятись.
 * ПРОЦЕСИ ТА СИСТЕМИ ПІДТРИМКИ ЯКОСТІ ПРОГРАМНИХ СИСТЕМ

Популярний погляд на якість

Якість – це дещо нематеріальне і «неосяжне»

Якість можна критикувати і вихваляти, але зважити і виміряти неможливо.
Люди сприймають і інтерпретують якість по різному.
Якість не може бути контрольованою і керованою.
Якість не може бути кількісно виміряна.

Інша популярна думка – якість нерозривно пов’язана з розкішшю, першим

сортом і тонким смаком.
Дорогий, досконально продуманий і технічно більш складний продукт
розглядається як гарантія вищої якості ніж більш дешеві аналоги.
За таким підходом:
1.Каділлак – якісна машина, а Шевроле – ні
2.Якість обмежена визначеним класом дорогих продуктів. Недорогі
продукти ж важко віднести до якісних.
 * ПРОЦЕСИ ТА СИСТЕМИ ПІДТРИМКИ ЯКОСТІ ПРОГРАМНИХ СИСТЕМ

Професійний підхід до якості

* В 1979 році Філ Кросбі визначив якість як «відповідність

вимогам» ("conformance to requirements").
* В 1970 році Юран і Грін визначили якість як «придатність до
використання» ("fitness for use").
* Уотс Хемпфрі – досягнення відмінного рівня придатності до
використання.
* Компанія IBM - якість, яка управляється ринковими потребами
(“market - driven quality”).
* Критерій Белдріджа для організаційної якості - “якість, яка
задається споживачем”
* Визначення системи менеджменту якості ISO 9001 - ступінь
відповідності наявних характеристик вимогам.
 * ПРОЦЕСИ ТА СИСТЕМИ ПІДТРИМКИ ЯКОСТІ ПРОГРАМНИХ СИСТЕМ

Відповідність вимогам
* Вимоги мають бути настільки чітко визначені, що вони не можуть
бути зрозумілі і інтерпретовані некоректно.
* На етапі розробки, проводяться регулярні вимірювання
розробленого продукту для визначення відповідності вимогам.
* Будь-які невідповідності розглядаються як дефекти –
невідповідність якості.

Виходячи з таких принципів

* якщо Каділлак відповідає усім вимогам до машин Каділлак, то

це якісна машина
* Якщо Шевроле відповідає усім вимогам до машин Шевроле, то
це теж якісна машина
 * ПРОЦЕСИ ТА СИСТЕМИ ПІДТРИМКИ ЯКОСТІ ПРОГРАМНИХ СИСТЕМ

Придатність до використання

* приймає до уваги вимоги і очікування кінцевого користувача, який

очікує, що продукт або надаваний сервіс буде зручним для нього
* продукт має володіти максимально різноманітними варіантами
використання
* кожен варіант використання – це характеристика якості і усі вони
можуть бути класифіковані по категоріям в якості параметрів
придатності до використання.
* «придатність до використання» вказує на важливу роль вимог і
очікувань замовника
Тільки замовник може розказати про якість, оскільки це єдине,
що він дійсно купляє. Замовник не купляє продукт. Він купляє
гарантії того, що усі його очікування до продукту будуть
реалізовані.
 * ПРОЦЕСИ ТА СИСТЕМИ ПІДТРИМКИ ЯКОСТІ ПРОГРАМНИХ СИСТЕМ

*Висновки
З точки зору замовника або користувача продукту:
* Якість – це придатність до використання. Чи робить даний
продукт те, що мені потрібно? Чи спрощує роботу? Чи можу я
його використати так, як мені потрібно?
Точка зору розробника:
* Якість – це відповідність специфікованим і забраним вимогам.
Чи робить даний продукт усе те, що вказано у вимогах?
Проблема в тому, що специфіковані і забрані вимоги – це зазвичай
частина реальних вимог і очікувань замовника.

Отже, якість – це відповідність реальним вимогам, явним і

неявним.
 * ПРОЦЕСИ ТА СИСТЕМИ ПІДТРИМКИ ЯКОСТІ ПРОГРАМНИХ СИСТЕМ

*В чому різниця між Тестуванням и QA (Quality

Assurance)?
Існує дві професії пов’язані з якістю програмного забезпечення:
тестер (Quality Control) і QA manager.

* Контроль якості (QUALITY CONTROL) - це вимірювання якості

продукту.
* Забезпечення якості (QUALITY ASSURANCE) – це вимірювання і
управління якістю процесу, який використовується для
створення якості продукту (або якісного продукту).
Іншими словами.
* Quality Assurance – попередження дефектів шляхом перевірки і
тестування процесу.
* Quality Control - виявлення дефектів шляхом перевірки і
тестування продукту.
 * ПРОЦЕСИ ТА СИСТЕМИ ПІДТРИМКИ ЯКОСТІ ПРОГРАМНИХ СИСТЕМ

Що таке якість програмного забезпечення?

Якщо спитати про це достатньо широку групу людей, які мають
справу з розробкою, продажем або використанням ПЗ, можна
отримати наступні відповіді:

* Легко використовувати
* Хороша продуктивність
* Нема помилок
* Не псує даних користувача при збоях
* Можна використовувати на різних платформах
* Може працювати 24 години на добу і 7 днів на тиждень
* Легко добавляти нові можливості
* Задовольняє потреби користувача
* Добре документовано
 * ПРОЦЕСИ ТА СИСТЕМИ ПІДТРИМКИ ЯКОСТІ ПРОГРАМНИХ СИСТЕМ

*Якість ПЗ по МакКолу

Першою широко відомою моделлю якості ПЗ стала запропонована

в 1977 МакКолом та іншими модель. В ній характеристики якості
розділені на три групи:
* Фактори, які описують ПЗ з позицій користувача. Задаються
вимогами.
* Критерії, які описують ПЗ з позицій розробника. Задаються як
цілі.
* Метрики, які використовуються для кількісного описання і
вимірювання якості.

Фактори, яких було виділено 11, групуються в три групи по

різним способам роботи людей з ПЗ. Отримана структура
відображується у вигляді трикутника МакКола
* ПРОЦЕСИ ТА СИСТЕМИ ПІДТРИМКИ ЯКОСТІ ПРОГРАМНИХ СИСТЕМ
 * ПРОЦЕСИ ТА СИСТЕМИ ПІДТРИМКИ ЯКОСТІ ПРОГРАМНИХ СИСТЕМ

* Метрики МакКола

*Зручність перевірки на відповідність стандартам (auditability)

*Точність керування і обчислень (accuracy)
*Ступінь стандартності інтерфейсів (communication commonality)
*Функціональна повнота (completeness)
*Однорідність використовуваних правил проектування і документації (consistency)
*Ступінь стандартності форматів даних (data commonality)
*Стійкість до помилок (error tolerance)
*Ефективність роботи (execution efficiency)
*Розширюваність (expandability)
*Широта області потенційного використання (generality)
*Незалежність від апаратної платформи (hardware independence)
*Повнота протоколювання помилок та інших подій (instrumentation)
*Модульність (modularity)
*Зручність роботи (operability)
*Захищеність (security)
*Самодокументованість (selfdocumentation)
*Простота роботи (simplicity)
*Незалежність від програмної платформи (software system independence)
*Можливість співвідношення проекту з вимогами (traceability)
*Зручність навчання (training).
 * ПРОЦЕСИ ТА СИСТЕМИ ПІДТРИМКИ ЯКОСТІ ПРОГРАМНИХ СИСТЕМ

*Якість ПЗ по Боему
Визначено 19 проміжних атрибутів (intermidiate construct), які
включають усі 11 факторів якості по МакКолу. Проміжні атрибути
розділяються на примітивні, які в свою чергу, можуть бути
оцінені за допомогою метрик. Додано до метрик МакКола:
* ясність (clarity)
* зручність внесення змін (modifiability)
* документованість (documentation)
* здатність до відновлення функцій (resilience)
* зрозумілість (understandability)
* адекватність (validity)
* функціональність (functionality)
* універсальність (generality)
* економічна ефективність (economy).
 ЛАБОРАТОРНА 1
ТЕМА: MIND MAP, ЯК ІНСТРУМЕНТ ТЕСТУВАННЯ
ТЕОРЕТИЧНА ЧАСТИНА
    Ментальна карта, інтелект-карта, логічна карта, діаграма зв’язків, Mind Map… Якщо раніше Ви не
зустрічалися з цими поняттями, не спішіть із скептичними висновками. Це дійсно ефективний інструмент
структуризації, котрий можна використовувати як в особистому житті, так і при виконанні робочих
завдань — тестування програмного забезпечення, не виключення. А придумав його у якості конспектів
англійський психолог, автор і консультант з питань освіти Тоні Бюзен у кінці 1960-х років.
      Суть Mind Map полягає у декомпозиції основної концепції або кінцевої цілі з метою її кращого розуміння
і її покрокового досягнення відповідно. Це свого роду засіб організації інформації з урахуванням
взаємозв’язків, який допомагає створити цілісну й систематизовану картину проблеми. А виглядає він
деревовидною схемою, на якій в центрі розташовується основна система, а всі відгалуження є її
підсистемами.
Як створити Mind Maps?
      Інтелект-карта — це логічна схема, з чого випливає, що всі її компоненти мають бути пов’язані між собою.
По центру знаходиться ключова концепція (мета, ідея, проблема, система). Це нульовий рівень. Наступні
підсистеми будуть елементами першого рівня, відгалуження цих підсистем – третього і т. д.
      Основна ідея полягає в декомпозиції і виокремленні найменших частин продукту (окремі форми, поля,
чек-бокси тощо) так як іде потік свідомості, а не так як нас вчили зі школи чітко структуровано по стовпчику
вниз.
Для того, щоб такий поділ був ефективним, варто притримуватись наступних правил:
1) Система розподіляється на всіх рівнях по єдиному принципу. Тобто всі підсистеми мають відповідати на
одне і теж питання по відношенню до «материнської» категорії. Якщо це зробити складно, що часто буває
у випадку тестування програмного забезпечення, то доцільно застосовувати це правило для елементів, які
знаходяться на одному рівні.
2) Підсистеми мають взаємно виключати одна одну, а разом створювати цілісний продукт. Підсистеми
мають взаємодіяти між собою. Якщо якісь елементи складно згрупувати, допускається їх виокремлення в
категорію «Інше».
3) На кожному рівні доцільно виділяти 5-7 підсистем. У такому разі інформація представлена в максимально
наочному вигляді. При цьому не виникає плутанини і перенасичення схеми.
4) Глибина декомпозиції визначається рівнем кваліфікації і досвідченості кожного конкретного спеціаліста.
Якщо з таким проектом тестувальник працює не вперше, то рівнів інтелект-карти буде значно менше.
Якщо ж це зовсім нова система для працівника, то ступінь деталізації повинна бути максимальною до
виокремлення найменших елементів.
5) Взаємопов’язані завдання доцільно групувати  за допомогою виділення одним кольором або обведенням їх
у блоки.
У випадку з тестуванням програмного забезпечення доцільно враховувати наступні критерії:
* Вимоги клієнта: замовник завжди орієнтується на просування продукту на ринок і свій
прибуток, тому врахування його побажань обов’язкове.
* Рівень ризику: найбільш важливий функціонал, збій в роботі якого, нанесе найбільшу шкоду
роботі ПО та фінансові втрати замовнику, потрібно тестувати в першу чергу.
* Складність системи: тестування необхідно розпочинати з найскладнішого функціоналу. Це
дозволяє заощадити час та уникнути надлишкових витрат.
* Обмеження у часі: потрібно тестувати у повній мірі лише той функціонал, який запланований на
наступний реліз.
На інтелект-картах можна створити спеціальні позначки для пріоритетних завдань, виділяти їх
іншим кольором тощо.
Чи варто використовувати Mind Maps у тестуванні ПЗ?
Звісно інтелект-карти будуть вельми корисними і в процесі тестування програмного забезпечення
тестувальникам, а також ще бізнес аналітикам, проектним менеджерам, коучам, авторам доповідей та
презентацій.
Такий цілісний підхід допомагає краще зорієнтуватись у суті продукту та розбити його на функціональні
модулі. Можна відслідкувати логічні зв’язки між елементами системи та виявити «вузькі місця», які
становлять загрозу ефективному функціонуванню продукту.
ЗАВДАННЯ
1. Вибрати будь-який програмний продукт (калькулятор, сайт і т.д.)
2. Створити Mind Map функціональних модулів (не забувати 5 правил ефективної карти візуалізації)
3. Зберегти в окреми файл, який підписати ПІП група