Author: adminsimplerec

Загалом можна виділити дві великі групи технік статичного тестування – це перевірки або перегляди (Reviews) та статичний аналіз.

Процес перевірки документації

Перевірки (reviews) документації варіюються від неофіційних до офіційних. Неофіційні перевірки характеризуються відсутністю визначеного процесу та офіційно задокументованих результатів. Для формальних перевірок характерна участь команди, задокументовані результати перевірки та задокументовані процедури проведення перевірки. Формальність процесу перевірки пов’язана з такими факторами, як модель життєвого циклу розробки програмного забезпечення, зрілість процесу розробки, складність робочого продукту, який перевіряється, будь-які законодавчі чи нормативні вимоги.

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

Стандарт ISO (ISO/IEC 20246) містить більш поглиблений опис процесу перевірки робочих продуктів, включаючи ролі та методи перевірки.

Процес перевірки (reviews) включає такі основні дії:

• Планування
• Початок перегляду
• Індивідуальна підготовка
• Комунікація проблем та аналіз
• Виправлення та звітування

Планування

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

Початок перегляду

• Розповсюдження робочого продукту (фізично чи за допомогою електронних засобів) та інших матеріалів, таких як логи, контрольні списки та інші відповідні робочі продукти
• Пояснення учасникам обсягу, цілей, процесу, ролей і результатів роботи
• Відповіді на будь-які запитання щодо перевірки, які можуть виникнути в учасників

Індивідуальна підготовка

• Перегляд всього або частини робочого продукту
• Позначення можливих недоліків, рекомендації та запитання

Комунікація проблем та аналіз

• Повідомлення про виявлені потенційні дефекти (наприклад, на оглядовій зустрічі)
• Аналіз потенційних дефектів, визначення права власності та статусу
• Оцінка та документування характеристик якості
• Оцінка результатів перевірки за критеріями виходу для прийняття рішення про перевірку (відхилити; необхідні значні зміни; прийняти, можливо, з незначними змінами)

Виправлення та звітування

• Створення звітів про дефекти для тих знахідок, які потребують змін у робочому продуктіВиправлення дефектів, виявлених (як правило, виконується автором) у перевіреному робочому продукті
• Повідомлення про дефекти відповідній особі або команді
• Запис оновленого статусу дефектів (у формальних перевірках), потенційно включаючи згоду автора коментаря
• Збір показників (для більш формальних типів перевірки)
• Перевірка відповідності критеріям виходу (для більш формальних типів перевірки)
• Прийняття робочого продукту після досягнення критеріїв виходу

Ролі у формальній перевірці

Типов формальна перевірка (formal review) документаці включатиме такі ролі:

• Автор (Author)
• Менеджмент (Management)
• Модератор (Moderator)
• Керівник (лідер) перевірки (Review leader)
• Рецензенти (Reviewers)
• Секретар (Scribe)

Автор

• Створює робочий продукт, що перевіряється
• Виправляє дефекти робочого продукту, що перевіряється (при необхідності)

Менеджмент

• Відповідає за планування перевірки
• Приймає рішення про виконання перевірок
• Призначає персонал, бюджет і час
• Контролює поточну ефективність витрат
• Виконує контрольні рішення у разі неадекватних результатів

Модератор

• Забезпечує ефективне проведення оглядових нарад (якщо вони проводяться)
• Посередництво, якщо необхідно, між різними точками зору
• Часто є особою, від якої залежить успіх перевірки

Керівник (лідер) перевірки

• Бере на себе загальну відповідальність за перевірку
• Вирішує, хто буде залучений, і організовує час і місце проведення

Рецензенти

• Можуть бути експертами в галузі, особами, які працюють над проєктом, зацікавленими сторонами, які зацікавлені в робочому продукті, або особами з певним технічним чи бізнес-досвідом
• Визначають потенційні дефекти в робочому продукті, що перевіряється
• Можуть представляти різні точки зору (наприклад, тестувальник, розробник, користувач, оператор, бізнес-аналітик, експерт з зручності використання тощо)

Секретар

• Зіставляє потенційні дефекти, виявлені під час індивідуальної перевірки
• Записує нові потенційні дефекти, відкриті питання та рішення наради з перегляду (якщо вона проводиться)

У деяких типах рецензування одна особа може виконувати кілька ролей, і дії, пов’язані з кожною роллю, також можуть відрізнятися залежно від типу перевірки. Крім того, з появою інструментів для підтримки процесу перевірки, особливо реєстрації дефектів, відкритих питань і рішень, часто відпадає потреба в секретарі.

Типи перевірок документації

Хоча перевірки можна використовувати для різних цілей, одна з головних цілей – виявити дефекти. Усі типи перевірки можуть допомогти у виявленні дефектів, і вибраний тип перевірки має ґрунтуватися на потребах проєкту, наявних ресурсах, типі продукту та ризиках, бізнес-сфері та культурі компанії, серед інших критеріїв вибору.

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

Типи дефектів, виявлених під час перевірки, відрізняються, особливо залежно від робочого продукту, який перевіряється.

Найпоширеніші типи перевірки робочої документації: неформальна перевірка, наскрізне проходження, технічна перевірка, інспекція.

Неформальна перевірка (informal review, e.g., buddy check, pairing, pair review)

• Основне призначення: виявлення потенційних дефектів
• Можливі додаткові цілі: генерація нових ідей або рішень, швидке вирішення незначних проблем
• Не базується на офіційному (задокументованому) процесі
• Може не включати нараду з перевірки (review meeting)
• Може виконуватись колегою автора (buddy check) або кількома людьми
• Результати можуть бути задокументовані
• Корисність залежить від рецензентів
• Використання контрольних списків необов’язкове
• Дуже часто використовується в гнучкій розробці

Наскрізне проходження (Walkthrough)

• Основні цілі: виявлення дефектів, вдосконалення програмного продукту, розгляд альтернативних реалізацій, оцінка відповідності стандартам і специфікаціям
• Можливі додаткові цілі: обмін ідеями щодо технік чи варіацій стилю, навчання учасників, досягнення консенсусу
• Індивідуальна підготовка перед нарадою з перевірки (review meeting) необов’язкова
• Нараду з перевірки (review meeting) зазвичай проводить автор робочого продукту
• Секретар обов’язковий
• Використання контрольних списків необов’язкове
• Може мати форму сценаріїв, пробних прогонів або моделювання
• Створюються журнали потенційних дефектів і звіти про перевірку
• На практиці може варіюватися від досить неформального до дуже офіційного

Технічний огляд (Technical review)

• Основні цілі: досягнення консенсусу, виявлення потенційних дефектів
• Можливі додаткові цілі: оцінка якості та зміцнення довіри до робочого продукту, генерація нових ідей, мотивація та надання можливості авторам покращувати майбутні робочі продукти, розгляд альтернативних реалізацій
• Рецензенти мають бути технічними колегами автора та технічними експертами в тій самій чи інших дисциплінах
• Необхідна індивідуальна підготовка перед оглядовою зустріччю
• Нарада з перевірки (review meeting) є необов’язковою, в ідеалі її проводить навчений модератор (зазвичай не автор)
• Секретар обов’язковий, в ідеалі не автор
• Використання контрольних списків необов’язкове
• Створюються журнали потенційних дефектів і звіти про перевірку

Інспекція (Inspection)

• Основні цілі: виявлення потенційних дефектів, оцінка якості та формування довіри до робочого продукту, запобігання майбутнім подібним дефектам шляхом навчання автора та аналізу першопричини
• Можливі подальші цілі: мотивація та надання можливості авторам покращувати майбутні робочі продукти та процес розробки програмного забезпечення, досягнення консенсусу
• Дотримується визначеного процесу з офіційно задокументованими результатами на основі правил і контрольних списків
• Використовує чітко визначені ролі та може включати спеціального читача (який читає продукт роботи вголос, часто перефразовуючи, тобто описуючи його своїми словами, під час оглядової зустрічі)
• Необхідна індивідуальна підготовка перед оглядовою зустріччю
• Рецензенти є або колегами автора, або експертами в інших дисциплінах, які стосуються робочого продукту
• Використовуються визначені критерії входу та виходу
• Секретар обов’язковий
• Оглядову зустріч проводить навчений модератор (не автор)
• Автор не може виступати в ролі керівника перевірки, читача чи секретаря
• Створюються журнали потенційних дефектів і звіт про перевірку
• Показники збираються та використовуються для вдосконалення всього процесу розробки програмного забезпечення, включаючи процес перевірки

Техніки перевірок документації

lІснує ряд методів перевірки, які можна застосувати під час індивідуальної підготовки для виявлення дефектів. Ці методи можна використовувати в описаних вище типах перевірок. Ефективність методів може відрізнятися залежно від типу огляду, який використовується. Серед методів перевірок документації виділяють:

• Ad hoc
• На основі контрольного списку
• Сценарії та пробні прогони
• На основі переспективи (поглядів)
• На основі ролей (рольовий)

Ad hoc

Під час спеціального перегляду рецензентам надається мало або взагалі не надається вказівок щодо того, як слід виконувати це завдання. Рецензенти часто читають робочий продукт послідовно, виявляючи та документуючи проблеми, коли вони з ними стикаються. Спеціальне рецензування – це широко використовувана техніка, яка потребує невеликої підготовки. Ця техніка сильно залежить від навичок рецензента та може призвести до багатьох повторюваних проблем, про які повідомляють різні рецензенти.

Контрольний список

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

Сценарії та пробні прогони

Під час рецензування на основі сценарію рецензентам надаються структуровані вказівки щодо того, як прочитати робочий продукт. Перевірка на основі сценаріїв підтримує рецензентів у виконанні «пробних прогонів» робочого продукту на основі очікуваного використання робочого продукту (якщо робочий продукт задокументовано у відповідному форматі, наприклад варіанти використання). Ці сценарії надають рецензентам кращі вказівки щодо визначення конкретних типів дефектів, ніж прості записи контрольного списку. Як і у випадку перевірки на основі контрольного списку, щоб не пропустити інші типи дефектів (наприклад, відсутні функції), рецензенти не повинні бути обмежені задокументованими сценаріями.

На основі перспективи

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

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

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

Рольовий

Огляд на основі ролей — це техніка, за якої рецензенти оцінюють робочий продукт з точки зору окремих ролей зацікавлених сторін. Типові ролі включають конкретні типи кінцевих користувачів (досвідчені, недосвідчені, старші, діти тощо), а також конкретні ролі в організації (системний адміністратор, тестувальник продуктивності тощо). Застосовуються ті самі принципи, що й у читанні в перспективі, оскільки ролі подібні.

Фактори успіху перевірок

Для успішної перевірки необхідно розглянути відповідний тип огляду та використані методи. Крім того, існує низка інших факторів, які впливатимуть на результат перевірки.

Організаційні фактори успіху для оглядів включають:

• Кожна перевірка має чіткі цілі, визначені під час планування перевірки та використані як вимірювані критерії виходу
• Застосовуються типи перевірки, які підходять для досягнення цілей і відповідають типу та рівню робочих продуктів програмного забезпечення та учасників
• Будь-які використовувані методи перевірки, такі як перевірка на основі контрольного списку або на основі ролей, підходять для ефективного виявлення дефектів у робочому продукті, який перевіряється
• Будь-які використовувані контрольні списки стосуються основних ризиків і є актуальними
• lВеликі документи пишуться та переглядаються невеликими частинами, щоб контролювати якість шляхом надання авторам ранніх і частих відгуків про недоліки
• Учасники мають достатньо часу для підготовки
• Перевірки плануються з належним повідомленням
• Керівництво підтримує процес перевірки (наприклад, шляхом виділення достатнього часу для діяльності з перевірки в графіки проєкту) Перевірки інтегровані в політику якості або тестування компанії.

Пов’язані з людьми фактори успіху перевірок включають:

• Для досягнення цілей рецензування залучаються потрібні люди, наприклад, люди з різними навичками або перспективами
• Тестувальники вважаються цінними рецензентами, які роблять внесок у рецензування та дізнаються про робочий продукт, що дає їм змогу готувати більш ефективні тести та готувати ці тести раніше
• Учасники приділяють достатньо часу та уваги до деталей
• Огляди проводяться невеликими частинами, щоб рецензенти не втрачали концентрації під час індивідуального огляду або зустрічі з перевірки (якщо вона проводиться)
• Виявлені дефекти визнаються, оцінюються та розглядаються об’єктивно
• Зустріч добре організована
• Перевірка проводиться в атмосфері довіри; результат не використовуватиметься для оцінки учасників
• Учасники уникають мови тіла та поведінки, які можуть вказувати на нудьгу, роздратування або ворожість до інших учасників
• Забезпечується адекватне навчання, особливо для більш формальних видів перевірок
• Пропагується культура навчання та вдосконалення процесу

Статичний аналіз

Метою статичного аналізу є пошук дефектів у вихідному коді програмного забезпечення та моделях програмного забезпечення.

Потік керування (Control flow) — це послідовність подій (шляхів) після запуску компонента або системи на виконання.

Потік даних (Data flow) — це абстрактне представлення послідовності та можливих змін стану об’єктів даних: створення, використання або видалення.

Метрики коду

Під час виконання статичного аналізу коду обчислюється інформація про структурні атрибути коду, такі як:

• Частота коментарів
• Глибина вкладення
• Цикломатичне число
• Кількість рядків коду

Показники складності ідентифікують зони з високим ризиком і складність.

Досвідчені програмісти знають, що 20% коду викличуть 80% проблем, а аналіз складності допомагає знайти ці важливі 20%.

Цінність статичного аналізу

• Раннє виявлення дефектів до виконання тесту
• Раннє попередження про підозрілі аспекти коду або дизайну шляхом обчислення показників.
• Ідентифікація дефектів, які важко знайти під час динамічного тестування
• Виявлення залежностей і невідповідностей у моделях програмного забезпечення
• Покращено підтримку коду та дизайну
• Попередження дефектів

Типові дефекти

• Типові дефекти, виявлені інструментами статичного аналізу:
• Посилання на змінну з невизначеним значенням
• Непослідовні інтерфейси між модулями та компонентами
• Змінні, які не використовуються або оголошені неправильно
• Недосяжний (мертвий) код
• Відсутня та помилкова логіка (потенційно нескінченні цикли)
• Надто складні конструкції
• Порушення стандартів програмування
• Вразливі місця безпеки
• Порушення синтаксису коду та моделей програмного забезпечення

Інструменти статичного аналізу

Інструменти статичного аналізу зазвичай використовуються розробниками (перевірка на відповідність попередньо визначеним правилам або стандартам програмування) до та під час тестування компонентів та інтеграції, а також під час моделювання програмного забезпечення.

Інструменти статичного аналізу можуть створювати велику кількість попереджувальних повідомлень, які потрібно ретельно аналізувати, щоб забезпечити найбільш ефективне використання інструменту.

Компілятори можуть запропонувати певну підтримку для статичного аналізу, включаючи обчислення показників.

Інструменти статичного аналізу: CodeScene, Parasoft, Code Compare, Sourcemeter, Understand.

В цьому відео поговоримо про техніки статичного тестування:
00:06 Статичне тестування
00:46 Процес перевірки документації
08:30 Ролі у формальній перевірці
12:25 Типи перевірок документації
14:02 Неформальна перевірка
15:16 Наскрізне проходження
17:31 Технічна перевірка
20:03 Інспекція
23:44 Техніки перевірок документації
24:39 Ad hoc
26:06 Контрольний список
27:59 Сценарії та пробні прогони
30:25 На основі перспективи
33:52 Рольовий
36:11 Фактори успіху перевірок
40:09 Статичний аналіз
41:06 Метрики коду
42:01 Цінність статичного аналізу
42:39 Типові дефекти, які виявляються статичним аналізом
43:45 Інструменти статичного аналізу

Статичне тестування — це техніка тестування програмного забезпечення, яка використовується для перевірки дефектів програмного забезпечення без виконання коду.

Статичне тестування проводиться, щоб уникнути помилок на ранній стадії розробки, оскільки легше виявити помилки та вирішити їх.

Це також допомагає знаходити помилки, які не можуть бути знайдені динамічним тестуванням.

Основи статичного тестування

На відміну від динамічного тестування, яке вимагає запуск на виконання програмного забезпечення, що тестується, статичне тестування спирається на перевірку робочих продуктів вручну (тобто огляди) або керовану інструментами оцінку коду чи інших робочих продуктів (тобто статичний аналіз). Обидва типи статичного тестування оцінюють код або інший робочий продукт, що тестується, без фактичного виконання коду або робочого продукту, що тестується.

Статичний аналіз важливий для сейфті-крітікал комп’ютерних систем (наприклад, авіаційного, медичного або ядерного програмного забезпечення), але статичний аналіз також став важливим і поширеним в інших середовищах. Наприклад, статичний аналіз є важливою частиною тестування безпеки. Статичний аналіз також часто включається в автоматизовані інструменти створення та розповсюдження програмного забезпечення, наприклад, у гнучкій розробці, безперервній доставці та безперервному розгортанні.

Цінність статичного тестування

При застосуванні на ранніх стадіях життєвого циклу розробки програмного забезпечення статичне тестування дозволяє завчасно виявити дефекти до виконання динамічного тестування (наприклад, під час перегляду вимог або специфікацій дизайну, уточнення невиконаних завдань тощо).

Дефекти, виявлені на ранній стадії, часто набагато дешевше усунути, ніж дефекти, виявлені пізніше в життєвому циклі, особливо порівняно з дефектами, виявленими після розгортання програмного забезпечення та його активного використання.

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

Переваги статичного тестування

До переваг статичного тестування відносять:

• Більш ефективне виявлення та виправлення дефектів до виконання динамічного тестування
• Виявлення дефектів, які нелегко виявити динамічним тестуванням
• Запобігання дефектам у дизайні чи кодуванні шляхом виявлення невідповідностей, двозначностей, протиріч, упущень, неточностей і надмірностей у вимогах
• Підвищення продуктивності розробки (наприклад, за рахунок покращеного дизайну, більш зручного обслуговування коду)
• Зменшення витрат і часу розробки
• Зменшення вартості та часу тестування
• Зменшення загальної вартості якості протягом усього терміну служби програмного забезпечення завдяки меншій кількості збоїв у подальшому життєвому циклі або після введення в експлуатацію
• Покращення комунікації між членами команди під час участі в оглядах

Статичне і динамічне тестування

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

Однією з головних відмінностей є те, що статичне тестування виявляє дефекти в робочих продуктах безпосередньо, а не визначає збої, викликані дефектами під час запуску програмного забезпечення. Дефект може існувати в робочому продукті протягом дуже тривалого часу, не викликаючи збою. Дефект у робочому продукті може тривалий час ніяк не проявлятися (наприклад через рідкісність набору умов, які можуть призвести до його прояву), тому буде непросто побудувати та виконати динамічний тест, який його виявить. Статичне тестування може виявити дефект із набагато меншими зусиллями.

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

Статичне тестування і дефекти

У порівнянні з динамічним тестуванням типові дефекти, які легше та дешевше знайти та виправити за допомогою статичного тестування, включають:

• Дефекти вимог (наприклад, невідповідності, двозначності, протиріччя, упущення, неточності та надмірності)
• Дефекти дизайну (наприклад, неефективні алгоритми або структури бази даних, високий зв’язок, низька зв’язність)
• Дефекти кодування (наприклад, змінні з невизначеними значеннями, змінні, які оголошені, але ніколи не використовуються, недоступний код, повторюваний код)
• Відхилення від стандартів (наприклад, недотримання стандартів кодування)
• Неправильні специфікації інтерфейсу (наприклад, інші одиниці вимірювання, що використовуються системою)
• Вразливості системи безпеки (наприклад, сприйнятливість до переповнення буфера)
• Прогалини або неточності в простежуваності бази тестів або покритті (наприклад, відсутність тестів для критерію прийнятності)

В цьому відео поговоримо про статичне тестування:
00:05 Статичне тестування
01:03 Основи Статичного тестування
02:31 Цінність статичного тестування
04:10 Переваги статичного тестування
05:20 Статичне і динамічне тестування
07:01 Статичне тестування і дефекти

Серія міжнародних стандартів ISO/IEC 25000, також відомих як Системні та програмні вимоги якості і оцінка (System and Software Quality Requirements and Evaluation), визначає характеристики, якими оцінюється якість програмного продукту.

Стандарт ISO/IEC 25010 містить термінологію для визначення, вимірювання та оцінки якості систем та програмних продуктів. Він визначає вісім характеристик якості програмного забезпечення, серед яких: функціональна придатність, рівень продуктивності, сумісність, зручність використання, надійність, безпека, зручність супроводу, портативність.

Стандарт ISO/IEC 25010 є ґрунтовним переглядом стандарту ISO/IEC 9126. У новий стандарт додано додаткові характеристики та підхарактеристики, які детальніше описують процес якості програмного продукту, а також введені уточнення та перегрупування характеристик для більш ясного їх розуміння.

Якість програмного забезпечення –  це здатність програмного продукту, згідно з вказаними умовами, задовольняти встановлені потреби. (ISO 25000:2014).

Функціональна придатність (Functional Suitability)

Функціональна придатність (Functional Suitability) включає функціональну повноту, функціональну правильність, функціональну відповідність.

Функціональна повнота (Functional completeness) — ступінь покриття сукупності функцій всіх визначених завдань і цілей користувача.

Функціональна коректність (Functional correctness) — ступінь забезпечення продуктом чи системою необхідного рівня правильних результатів.

Функціональна відповідність (Functional appropriateness) — ступінь, з яким функції сприяють виконанню завдань і досягненню цілей.

Ефектиність продуктивності (Performance efficiency)

Ефектиність продуктивності (Performance efficiency) включає часові характеристики, використання ресурсів, місткість.

Часові характеристики (Time behaviour) — ступінь відповідності вимогам про час відповіді, час обробки і показники пропускної здатності продукта або системи.

Використання ресурсів (Resource utilization) — ступінь задоволення вимог про споживання обсягів і видів ресурсів продуктом або системою при виконанні їх функцій.

Місткість (Capacity) — ступінь відповідності вимогам граничних значень параметрів продукта або системи.

Сумісність (Compatibility)

Сумісність (Compatibility) включає співіснування та  функціональну сумісність.

Співіснування (Co-existence) — здатність продукта сумісно функціонувати з іншими незалежними продуктами у спільній середі з розділенням спільних ресурсів і без негативного впливу на будь-який інший продукт.

Функціональна сумісність (Interoperability) — здатність двох або більше систем, продуктів або компонентів обмінюватис даними і використовувати такі дані.

Зручність використання (Usability)

Зручність використання (Usability) включає можливість визначення придатності, можливість вивчення, керованість, захист від помилок користувача, естетика користувацкого інтерфейсу, доступність.

Можливість визначення придатності (Appropriateness recognizability) — можливість користувача зрозуміти чи підходить продукт або система для їхніх потреб.

Можливість вивчення (Learnability) — можливість використання продукта або системи певними користувачами для досягнення конкретних цілей навчання для експлуатації продукта або системи з ефективність, результативністю, без ризику і у відповідності з вимогами у вказаному контексті використання.

Керованість (Operability) — наявність в продукті або системі атрибутів, які забезпечують просте управління та контроль.

Захист від помилок користувача (User error protection) — рівень системного захисту користувачів від помилок.

Естетика користувацького інтерфейсу (User interface aesthetics) — ступінь задоволеності користувача інтерфейсом взаємодії.

Доступність (Accessibility) — можливість викорситання продукту або системи для досягнення певної мети у вказаному контексті використання широким колом осіб з різними можливостями.

Надійність (Reliability)

Надійність (Reliability) включає зрілість, готовність, відмовостійкісь, відновлюваність.

Зрілість (Maturity) — ступінь відповідності системи, продукта або компонента при нормальній роботі вимогам надійності.

Готовність (Availability) — ступінь працездатності і доступності системи, продукта або компонента.

Відмовостійкість (Fault tolerance) — здатність системи, продукта або компонента працювати як призначено, не дивлячись на наявність дефектів програмного забезпечення або апаратниї засобів.

Відновлюваність (Revoverability) — здатність продукта або системи відновити дані та необхідний стан системи у випадку переривання або збою.

Безпека (Security)

Безпека (Security) включає неможливість заперечення, цілісність, конфіденційність, відстежуваність, автентичність.

Неможливість заперечувати (Non-repudiation) — впевненість, що хтось не може заперечувати дійсність чогось. Себто можливісь беззаперечно довести факт події або дії таким чином, що цей факт не можна заперечити.

Цілісність (Integrity) — ступінь запобігання системою, продуктом або компонентом несанкціоноваго доступу до модифікацій даних.

Конфіденційність (Confidentiality) — забезпечення продуктом або системою обмеження доступу до даних тільки для тих, кому доступ довзволено.

Відстежуваність (Accountability) — ступінь, до якої дії об’єкта можуть бути відстежені однозначно.

Автентичність (Authenticity) — ступінь достовірності, відповідності об’єкта або ресурса необхідному об’єкту або ресурсу.

Зручність супроводу (Maintainability)

Зручність супроводу (Maintainability)  включає модульність, можливість багаторазового використання, можливість аналізу, можливість модифікацій, можливість тестування.

Модульність (Modularity) — ступінь представлення системи або програми у вигляді окремих блоків таким чином, щоб зміна одного компонента здійснювала мінімальний вплив на інші компоненти.

Можливість багаторазового використання (Reusability) — ступінь, в якій актив може бути використаний в декількох системах чи при створенні інших активів.

Можливість аналізу (Analysability) — ступінь простоти оцінки впливу змін однієї або більше частин на продукт або систему або простоти діагностики продукта для виявлення недоліків та причин відмов, або простоти ідетифікації частин, які порібно змінювати.

Можливість модифікацій (Modifiability) — ступінь простоти ефективної та раціональної зміни продукту або системи без додавання дефектів та зниження якості продукта.

Можливість тестування (Testability) — ступінь простоти ефективного та раціонального визначення для системи, продукта або компонента критеріїв тестування, а також простоти виконання тестування з метою визначення відповідності цим критеріям.

Портативність (Portability)

Портативність (Portability) включає можливість адаптації, можливість встановлення, можливість заміни.

Можливість адаптації (Adаptability) — ступінь простоти ефективної та раціональної адаптації для удосконалених апаратних засобів, програмного забезпечення, інших операційних середовищ або умов використання.

Можливість встановлення (Installability) — ступінь простоти ефективного, раціонального, успішного встановлення або видалення продукта або системи в заданому середовищі.

Можливість заміни (Replaceability) — здатність продукта замінити інший конкретний програмний продукт для досягнення тих самих цілей в тих же умовах.

Вимоги до програмного забезпечення

Вимоги до програмного забезпечення – це опис характеристик і функцій цільової системи. Вимоги передають очікування користувачів від програмного продукту. Вимоги можуть бути очевидними або прихованими, відомими або невідомими, очікуваними або неочікуваними з точки зору клієнта.

Розробка вимог

Процес збору вимог до програмного забезпечення від клієнта, їх аналізу та документування відомий як розробка вимог.

Метою розробки вимог є розробка та підтримка складного, описового документа “Специфікація системних вимог”.

Процес розробки вимог включає наступні стадії:

• Техніко-економічне обґрунтування
• Збір вимог
• Специфікація вимог до програмного забезпечення
• Перевірка вимог програмного забезпечення

ТЕО (техніко-економічне обґрунтування)

Коли клієнт звертається до організації за розробкою бажаного продукту, у нього виникає приблизне уявлення про те, які функції має виконувати програмне забезпечення та які функції очікуються від програмного забезпечення.

Посилаючись на цю інформацію, аналітики детально вивчають, чи можливо розробити бажану систему та її функціональність.

Це техніко-економічне обґрунтування спрямоване на досягнення мети організації. У цьому дослідженні аналізується, чи можна практично матеріалізувати програмний продукт з точки зору впровадження. Досліджуються технічні аспекти проєкту та продукту, такі як зручність використання, ремонтопридатність, продуктивність та здатність до інтеграції.

Результатом цього етапу має бути звіт про техніко-економічне обґрунтування, який повинен містити адекватні коментарі та рекомендації для керівництва щодо того, чи слід розпочинати проєкт.

Збір вимог

Якщо техніко-економічний звіт є позитивним для реалізації проєкту, наступний етап починається зі збору вимог від користувача. Аналітики та інженери спілкуються з клієнтом і кінцевими користувачами, щоб дізнатися їхні ідеї щодо того, що має надавати програмне забезпечення та які функції вони хочуть включати в програмне забезпечення.

Специфікація вимог до програмного забезпечення

SRS — це документ, створений системним аналітиком після збору вимог від різних зацікавлених сторін.

SRS визначає, як передбачене програмне забезпечення взаємодіятиме з апаратним забезпеченням, зовнішніми інтерфейсами, швидкістю роботи, часом відгуку системи, переносимістю програмного забезпечення на різні платформи, зручністю обслуговування, швидкістю відновлення після збою, безпекою, якістю, обмеженнями тощо.

Вимоги, отримані від клієнта, написані природною мовою. Системний аналітик відповідає за документування вимог технічною мовою, щоб вони могли бути зрозумілими та корисними групі розробників програмного забезпечення.

Перевірка вимог програмного забезпечення

Після розробки специфікацій вимог, починається перевірка цих вимог. Користувач може попросити незаконне, непрактичне рішення або експерти можуть неправильно витлумачити вимоги. Це призвести до суттєвих збитків, якщо не внести виправлення. Вимоги можна перевірити на такі умови:

• Чи можливо їх практично реалізувати
• Чи вони коректні та відповідають функціям і домену програмного забезпечення
• Чи є якісь неясності
• Чи вони повні
• Чи можна їх продемонструвати

Процес виявлення вимог

Процес виявлення вимоги містить наступні фази:

• Збір вимог – розробники обговорюють їх із клієнтом і кінцевими користувачами та знають їхні очікування від програмного забезпечення.
• Організація вимог – розробники встановлюють пріоритети та впорядковують вимоги в порядку важливості, терміновості та зручності.
• Обговорення. Якщо вимоги є неоднозначними або є деякі конфлікти у вимогах різних зацікавлених сторін, якщо вони є, тоді це обговорюється із зацікавленими сторонами. Щоб усунути двозначність і конфлікти, вони обговорюються для ясності та коректності. Нереалістичні вимоги доцільно відхилити чи модифікувати.
• Документація. Усі формальні та неофіційні, функціональні та нефункціональні вимоги систематизуються та документуються.

Методи виявлення вимог

Виявлення вимог — це процес з’ясування вимог до системи програмного забезпечення шляхом спілкування з клієнтом, кінцевими користувачами, користувачами системи та іншими, хто зацікавлений у розробці системи програмного забезпечення.

Існують різні способи виявити вимоги: інтерв’ю (співбесіди), опитування, анкетування, розбір задачі, аналіз домену, мозковий штурм, прототипування, спостереження.

Інтерв’ю (співбесіди)

Співбесіди є сильним засобом збору вимог. Організація може проводити кілька типів співбесід, таких як:

• Структуровані (закриті) інтерв’ю, де кожна окрема інформація, яку потрібно зібрати, вирішується заздалегідь, вони чітко слідують шаблону та предмету обговорення.
• Неструктуровані (відкриті) інтерв’ю, де інформація для збору не вирішується заздалегідь, більш гнучкі та менш упереджені.
• Усні опитування
• Письмові інтерв’ю
• Індивідуальні співбесіди, які проводяться між двома людьми за столом.
• Групові інтерв’ю, які проводяться між групами учасників. Вони допомагають виявити будь-які відсутні вимоги, оскільки задіяно багато людей.

Опитування

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

Анкети

Документ із заздалегідь визначеним набором об’єктивних запитань і відповідних варіантів передається всім зацікавленим сторонам для відповіді.

Розбір задачі

Команда інженерів і розробників може проаналізувати роботу, для якої потрібна нова система. Якщо у клієнта вже є програмне забезпечення для виконання певної операції, воно вивчається та збираються вимоги до запропонованої системи.

Аналіз домену

Кожне програмне забезпечення належить до певної категорії домену. Експерти у цій галузі можуть надати велику допомогу для аналізу загальних і конкретних вимог.

Мозковий штурм

Між різними зацікавленими сторонами проводяться неформальні дебати, і всі їхні внески записуються для подальшого аналізу вимог.

Прототипування

Прототипування — це створення користувальницького інтерфейсу без додавання детальної функціональності, щоб користувач міг інтерпретувати особливості запланованого програмного продукту. Це допомагає краще уявити вимоги. Відгуки клієнтів служать вхідними даними для збору вимог.

Спостереження

Команда експертів відвідує організацію або робоче місце клієнта. Вони спостерігають за фактичною роботою існуючих встановлених систем. Вони спостерігають за робочим процесом у клієнта та за тим, як вирішуються проблеми виконання. Команда сама робить деякі висновки, які допомагають сформувати вимоги, які очікуються від програмного забезпечення.

Характеристики вимог до програмного забезпечення

Збір вимог до програмного забезпечення є основою всього проєкту розробки програмного забезпечення. Тому вони мають бути чіткими, правильними та чітко визначеними.

Повна специфікація вимог до програмного забезпечення має бути:

• Ясною
• Правильною
• Послідовною
• Зрозумілою
• Можливою для внесення модифікацій, змін
• Можливою для перевірки
• Пріоритизованою
• Однозначною
• Відстежуваною

Функціональні та нефункціональні вимоги

Функціональні вимоги. До цієї категорії належать вимоги, пов’язані з функціональним аспектом програмного забезпечення.

Нефункціональні вимоги. До цієї категорії відносяться вимоги, не пов’язані з функціональним аспектом програмного забезпечення. Це неявні або очікувані характеристики програмного забезпечення, про які користувачі роблять припущення (сумісність, продуктивність, портативність, безпека, зручність використання тощо).

В цьому відео поговоримо про якість ПЗ та вимоги
00:06 Якість ПЗ
06:17 Функціональна придатність
07:34 Ефектиність продуктивності
08:32 Сумісність
09:40 Зручність використання
12:21 Надійність
13:37 Безпека
17:25 Зручність супроводу
19:43 Портативність
20:45 Вимоги до ПЗ
22:11 Розробка вимог
23:18 Техніко-економічне обґрунтування
24:44 Збір вимог
25:10 Специфікація вимог до ПЗ
26:31 Перевірка вимог до ПЗ
27:48 Процес виявлення вимог
29:25 Методи виявлення вимог
33:22 Функціональні і нефункціональні вимоги