Стандартизація та сертифікація інформаційних управляючих систем

1.

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

2.

Основы инженерии качества программных систем / Ф.И.Андон, Г.И.Коваль.,
Т.М.Коротун, Е.М.Лаврищева, В.Ю.Суслов. –К.: Академпериодика, 2007. – 672 с.
Бабенко Л.П., Лавріщева К.М. Основи програмної інженерії. Навч. посіб. –К.: Т-во
“Знання”, КОО, 2001. – 269 с.
Шлеер С., Меллор С. Объектно-ориентированный анализ: моделирование мира в
состояниях : пер. с англ. –К.: Диалектика, 1993. – 240с.
Канер Сэм, Фолк Дж., Нгуен Енг Кен. Тестирование программного обеспечения :
Пер. с англ. –К.: Диасофт, 2001. – 544 с.
Лавріщева К.М. Програмна інженерія. Підручн. –К.: Академперіодика, 2008. – 320 с.
Майерс Г. Искусство тестирования программ : –М.: Мир, 1982. – 176 с.
Дастин Э., Рэшка Д., Пол Дж. Автоматизированное тестирование программного
обеспечения. Внедрение, управление и эксплуатация : Пер. с англ. –М.: Изд.
“Лори”, 2003. – 567с.
Брауде Э. Технология разработки программного обеспечения. – СПб.: Питер, 2004.
– 655 с.
Соммервилл И. Инженерия программного обеспечения. –М.: Изд. дом Вильямс,
2002. – 624 с.
Райчев І.Е., Харченко О.Г. Концепція побудови сертифікаційної моделі якості
програмних систем // Проблемы программирования. –2006. –№2-3. – С. 275–281.

3.

Стандартизація та сертифікація інформаційних
управляючих систем
ПС
І нформаці йна система
Інформаційна система
Зовнішня система (бізнес-система)
Зв'язок між системами

4.

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

5.

ISO/IEC 12207:1995. Information technologies – Software life cycle processes.
ДСТУ 3918-1999. (відповідає ISO/IEC 12207:1995). Інформаційні технології.
Процеси життєвого циклу програмного забезпечення. Держстандарт України.
ISO/IEC 12207:1995 / Amd.1:2002. IT – Software life cycle processes.
ISO/IEC 12207:1995 / Amd.2:2004. IT – Software life cycle processes.
ІSО/ІЕС 15271:1998. IT – Guide for ISO/IEC 12207 Software Life Cycle Processes.
ISO/IEC 15288:2002. Systems engineering – System life cycle processes.
ДСТУ ISO/IEC 15288:2005. Інженерія систем – Процеси життєвого циклу
системи.
ISO/IEC 15288:2008. Systems and software engineering – System life cycle
processes.
IEEE/EIA Std. 12207.0:1996. Software life cycle processes.
IEEE/EIA Std. 12207.1:1997. Software life cycle processes – Life cycle data.
IEEE Std 830-1993. Recommended practice for software requirements specification.
IEEE Std. 1233:1998. IEEE Guide for Developing System Requirements
Specifications.

6.

Якість – це сукупність властивостей ПС, які забезпечують її
здатність задовольняти встановлені або передбачувані потреби
відповідно до призначення ПС (ДСТУ 2844-1994. Програмні засоби
ЕОМ. Забезпечення якості. Терміни та визначення.)
Визначення
вимог
Проектування
ПС
Реалізація
ПС
Тестування
(verification
& validation)
Впровадження
Експлуатація та
супроводження
Вивід ПС із
експлуатації

7.

Аналіз
вимог
Тестування
v.3
v.2
Реалізація
v.1
Проектування
ПС

8.

ЖЦ ПЗ визначений стандартом ISO/IEC 12207:1995 – Information
Technology – Software life cycle processes.
Процеси ЖЦ діляться на 3 групи: головні; допоміжні; організаційні.
Головні процеси: процес покупки (ініціація ЖЦ ПС і визначення
організації, що ініціює розробку/покупку); процес розробки (дії
організації розробника (ОР) – визначення та аналіз вимог,
проектування ПС, реалізація ПС, тестування); процес постачання
(передача ПС покупцеві); процес експлуатації; процес супроводження
(керування модифікаціями ПС та інсталяція нових версій).
Допоміжні процеси – процеси, які забезпечують якість ПС (шляхом
приведення ПС у відповідність до вимог та рекомендацій стандартів).
Організаційні процеси: менеджмент розробки; навчання персоналу;
визначення обов’язків учасників процесів ЖЦ.
Якість ПС – це сукупність властивостей ПС, які забезпечують її здатність
задовольняти вимоги замовників та користувачів.

9.

10.

Інженерія вимог
ПС вводиться в реальний світ для того, щоб впливати на процеси
реального життя. Ті частини реального світу, які впливають на систему або
піддаються її впливу, складають домен прикладної галузі (області) або
домен використання.
Вимоги до ПС стосуються тих властивостей, які повинні бути у
системи, якщо вона адекватно виконує свої функції.
Діючі персони в процесі формулювання вимог: носії інтересів
замовника (часто декілька профгруп); оператори, які здійснюють
обслуговування ПС; розробник ПС.
Методи збирання вимог: інтерв’ю з носіями інтересів замовника й
операторами; спостереження за роботою діючої системи з метою
відділення її проблемних властивостей від тих, які обумовлені структурою
кадрів; сценарії (приклади) можливих випадків виконання її функцій, а
також ролей осіб, що запускають ці сценарії або взаємодіють із системою
під час її функціонування.
Продукт процесу збору вимог – неформалізований їхній опис (або
технічне завдання – ТЗ) – основа контракту на розробку між замовником і
виконавцем розробки системи ( ГОСТ 34.602-89. Информационная
технология – Комплекс стандартов на автоматизированые системы.
Техническое задание на создание автоматизированой системы ).

11.

Базовим стандартом, який визначає порядок і умови збору та постановки вимог
до ПС, є міжнародний стандарт IEEE Std 830 – Recommended Practice for
Software Requirements Specifications. Стандарт складається з розділів:
1. Вступ: мета; область застосування; терміни; посилання.
2. Основна частина. Загальний опис.
2.1. Перспективи програмного продукту: системні інтерфейси;
інтерфейси користувачів; операційні інтерфейси; програмні інтерфейси;
комунікаційні інтерфейси; використання пам’яті та операцій.
2.2. Функції продукту. 2.3. Користувацькі характеристики. 2.4.Обмеження.
2.5. Припущення й залежності.
2.6. Розподіл вимог: C-вимоги – вимоги користувача (Customer requirements);
D-вимоги – вимоги розробника (Developer requirements).
3. Конкретні вимоги.
3.1. Вимоги до зовнішнього, користувацького, програмного, апаратного та
комунікаційного інтерфейсів.
3.2. Класи й об’єкти (відносять до функціональних вимог).
3.3. Вимоги продуктивності (відносять до нефункціональних вимог).
3.4. Обмеження на проектування. 3.5. Атрибути ПС. 3.6. Інші вимоги.
C-вимоги – неформалізовані, а D-вимоги – детальні вимоги, які поділяються на
функціональні та нефункціональні. Функціональні вимоги відносяться до
функціональних характеристик системи (можливості, які повинна забезпечувати
система), а нефункціональні вимоги відносяться до якісних властивостей, котрі
не мають прямого відношення до функціональності ПС (обмеження, пов’язані з
характеристиками функціонування ПС).

12.

D-вимоги складаються за допомогою функціональних специфікацій, що
містять у собі повний список всіх властивостей і функцій, якими повинна володіти
система. Ці вимоги повинні відповідати С-вимогам. Специфікація вимоги до ПЗ
(SRS) має бути: несуперечливою; з можливістю контролю; тестованою;
погодженою; повною.
Мається кілька класів нефункціональних вимог, які є суттєвими для більшості
ПС. Це обмеження, які актуальні для більшості проблемних областей:
вимоги до конфіденційності; вимоги до відмовостійкості; вимоги до кількості
клієнтів, що одночасно мають доступ до системи; вимоги до безпеки;
вимоги до часу очікування відповіді від системи; вимоги до властивостей
системи при виконанні її функцій (обмеження на ресурси пам’яті або процесору,
швидкість реакції на звернення до ПС тощо).
Продуктом процесу аналізу вимог є побудована модель проблеми,
орієнтована на її розуміння виконавцем до початку проектування системи.
Процес побудови моделі проблеми називається концептуальним
моделюванням. Роль концептуальної моделі полягає в тому, щоб бути
посередником між професіоналами, які знаються на різних доменах (наприклад,
фахівцями з бухгалтерського обліку і програмістами).
Сукупність термінології, понять, характерних відносин, а також парадигми
їхньої інтерпретації в рамках домену називається онтологією домену. Онтологія
утримує користувачів у максимально можливому просторі визначених наперед
можливостей, зміст яких зафіксований і зрозумілий як замовнику, так і розробнику.
Серед існуючих відношень між об’єктами статичних доменів найбільш відомі:
узагальнення; конкретизація; агрегація; асоціація.

13.

Для динамічних доменів істотними поняттями є: стан (домену, області,
об’єкта) – фіксація певних властивостей об’єктів на певний момент (чи інтервал)
часу; інтервал стабільності – інтервал часу протягом, якого не змінюється стан;
подія – явище, що провокує зміну станів. Серед динамічних доменів існують
наступні різновиди: інертні – стан не змінюється до впливу зовнішніх агентів;
реактивні – зміна стану як відповідь на певну зовнішню подію; активні – перехід зі
стану в стан без зовнішніх стимулів.
Об’єктно-орієнтована інженерія вимог
Відомі наступні моделі, що визначають архітектуру ПС: модель функції-дані;
об’єктна модель. Основні концепції ООП:
- світ складають об’єкти, які взаємодіють між собою;
- кожний об’єкт має певний набір властивостей (атрибутів);
- об’єкти вступають між собою у відношення, які можуть змінюватися у часі;
- сукупність значень атрибутів об’єкта у певний момент часу обумовлює його
стан -> сукупність станів всіх об’єктів визначає стан предметної області в цілому;
- у певні моменти часу виникають події, які викликають наступні події або зміни
станів об’єктів;
- дії, які виконує об’єкт називають операцією (функцією, методом);
- сукупність дій об’єкта називається його поведінкою;
- об’єкти можуть бути складними і взаємодіють між собою шляхом обміну
повідомленнями. Об’єкти характеризуються: інкапсуляцією; успадкуванням
(спадковістю); поліморфізмом.
Відомі такі об’єктно-орієнтовані підходи: метод Шлеєр і Меллора; метод
сценаріїв (метод Джекобсона); методологія UML.

14.

Метод інженерії вимог С.Шлеєр і С.Меллора
Продуктом аналізу домену є 3 моделі: інформаційна модель системи (онтологія
домену); модель станів об’єктів, визначеної у складі інформаційної моделі; модель
процесів, що забезпечують переходи об’єкту із одного стану в інший.
Інформаційна модель домену
Приклад об’єкта з атрибутами
3. Співробітник
* ім'я
* прізвище
* посада
* табельний номер
* телефон
Мається 3 види зв’язків
1:1
1:n
m:n

15.

Фрагмент та приклад інформаційної моделі
2. Власник
Володіє
1. Авто
R1
* ПІБ
* номер паспорта
* посвідчення водія
* тип
* номер
4. Керівник
5. Проект
Керується
R2
* ПІБ
* посада
Керує
Підпорядковується
R3
6. Виконавець
* ПІБ
* спеціальність
* назва роботи
* назва
* замовник
* дата виконання

16.

Приклад відношення спадкування
1. Рахунок
* номер
* сума
є
2. Готівковий
є
3. Чековий
є
4. Електронний

17.

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

18.

ДПС автоматичної пральної машини
С1. Машину
вимкнуто
П1. Машину увімкнуто,
задано кількість
полоскань і температура
ник
чиль 0
і
Л
.
С2. Подача
>
П7
скань
о
л
о
п
води до бака
Д1. Увімкнути подачу води
Д2. Встановити режим
прання/полоскання
П2. Бак повний
С3. Підігрів
води
Д3. Включити термометр
Д4. Вимкнути воду
П3. Вода підігріта
С4. Обертання
барабану
Д5. Встановити таймер Т1
П4. Таймер Т1 спрацював
С5. Злив води
Д6. Включити злив
П5. Бак пустий
С6. Бак пустий
Д7. Зменшити лічильник
полоскань на 1
П6. Лічильник полоскань = 0
С7. Сушіння
Д8. Встановити таймер Т2
Д9. Запустити центрифугу
П8. Таймер Т2 спрацював
С8. Машину
вимкнуто
Д10. Вимкнути машину

19.

ТПС автоматичної пральної машини
П1
С1
С2
С3
С4
С5
С6
С7
П2
П3
П4
П5
П6
П7
7
2
П8
2
3
4
5
6
1(8)

20.

Дії є алгоритмами, які виконуються системою, як реакція на зовнішні події.
Набір таких дій визначає поведінку системи, її функціональність. Для
подолання складності розуміння дій, виконують їх декомпозицію на окремі
складові, які називають процесами. Послідовність процесів визначає потік
керування.
При цьому процеси обмінюються даними, які утворюють потік даних.
Для представлення моделі алгоритмів дій системи використовуються діаграми
потоків даних дій (ДПДД).
Кожному стану з ДПС може відповідати тільки одна ДПДД. Процес на ДПДД
зображується у вигляді овалу (усередині дається назва), потоки даних
зображуються стрілками (на котрих вказуються ідентифікатори даних, напрямок до
овалу - вхідні, а від овалу - вихідні дані), джерела даних зображуються
прямокутниками або рамками з відкритими сторонами.
Як джерела даних допускаються: атрибути об'єктів (зберігаються у файлах
або базах даних); системні годинники й таймери; дані подій і повідомлення.
Після побудови ДПДД варто побудувати загальну таблицю процесів із такими
колонками: ідентифікатор процесу; тип процесу (аксесор – доступ до архівів
даних, генератор подій, процес-обчислення, перевірка умов); повна назва процесу;
назва стану, у якому визначений процес; назва дії стану;
За допомогою цієї таблиці перевіряється:
- несуперечність назв та ідентифікаторів процесів;
- повнота подій та процесів;
- можливість виявити спільні процеси для різних дій чи станів.

21.

Приклад діаграми потоків даних дій (ДПДД) для стану
“Запис показників датчиків”
Поточний час
Поточний час
Контроль часу
Таймер
Т1
“Створити
таймер”
Т1 спрацював
“Зняти показники
датчиків”
БД показників

22.

Продукти інженерії вимог за методом Шлеєр і Меллора
Відповідно до методу, результатами аналізу вимог до створення ПС
є наступні продукти:
Інформаційна модель системи (онтологія) у формі:
Діаграми сутність-зв’язок;
Описи об’єктів та їхніх атрибутів;
Описи зв’язків між об’єктами.
Модель поведінки об’єктів системи у формі:
ДПС і ТПС;
Описи дій для ДПС;
Описи подій для ДПС та ТПС.
Модель процесів для станів об’єктів у вигляді:
ДПДД;
Таблиці процесів станів;
Описи процесів (природною мовою).

23.

Метод інженерії вимог І.Джекобсона (модель сценаріїв)
Метод Джекобсона – це єдиний метод, що вказує послідовний, достатньо
формалізований підхід до виявлення об’єктів, суттєвих для даної предметної
області.
Відбувається послідовна декомпозиція проблеми:
1) складні проблеми трансформуються в сукупність складових мети;
2) кожна із складових мети трансформується в сукупність можливих прикладів
використання системи (множина сценаріїв);
3) кожний сценарій трансформується в процесі аналізу в сукупність
взаємодіючих об’єктів.
У такий спосіб будується ланцюжок трансформації:
проблема – складові мети – сценарії – об’єкти.
Проведена трансформація відображається у термінах базових понять
проблемної області. Кожний сценарій запускається користувачем (актором), який є
зовнішнім чинником системи. Кожний сценарій запускає один актор.
Складові мети є джерелом вимог до системи і класифікуються на обов’язкові й
бажані. Складові мети можуть перебувати в певних відношеннях (узгодженість,
конфлікт, кооперація, залежність).
Сценарій складається з ряду операцій і має стани й поведінку. Сценарій – це
повний ланцюжок подій, ініційованих актором, і специфікація реакції на них.
Сукупність сценаріїв визначає всі можливі шляхи використання системи.

24.

Діаграма сценаріїв для клієнта банку
Внесення грошей
на рахунок
Зняття грошей з
рахунку
Клієнт
банку

25.

Діаграма сценаріїв бібліотеки
Запис замовлення до
формуляру
Реєстрація і
отримання
формуляру
Запис в чергу
замовлень
Оформлення
замовлення
Читач
Бібліотекар
Реєстрація
повернення книги

26.

Приклади розширення сценаріїв
Реєстрація
повернення книги
“розширює”
Визначення
пошкоджень
екземляру
Обслуговування
черги замовлень
“розширює”
Визначення пільг

27.

Приклад відношення “використовує”
Обробка отриманих
книг
Розрахунок черги
“використовує”
“використовує”
Сортувати

28.

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

29.

Модель аналізу вимог: асоціації між об’єктами бібліотечної системи
Об'єкт-сутність
Керуючий об'єкт
Об'єкт-інтерфейс
О1
О2
Панель
читача
О3
Перевірка
заборгованості
Формуляр
читача
О4
О8
“ні”
О5
Каталог
книг
Виконання
замовлень
О7
Черга
замовлень
Панель
бібліотекаря
О6
Запис у чергу
замовлень
О2
О8

30.

Послідовний підхід до виявлення об’єктів,
суттєвих для даної предметної області, складається з таких кроків:
1) Множина можливих об’єктів визначається на етапі побудови інформаційної
моделі проблемної галузі (E-R діаграми домену).
2) Склад об’єктів уточнюється після побудови комплекту діаграм сценаріїв
для моделювання вимог до проектованої ПС
(можуть з’явитися нові об’єкти та скоротитися склад об’єктів з п.1,
якщо вони не використовуються в сценаріях).
3) Остаточно склад об’єктів визначається після побудови діаграм аналізу вимог
для кожного сценарію (можуть з’явитися нові об’єкти та скоротитися склад
об’єктів з п.2, якщо вони не використовуються у відповідних діаграмах взаємодії).
Продукти інженерії вимог по методу Джекобсона
1) Онтологія домену (для нотації проблемної галузі можна скористатися
діаграмами Чена, тобто ERD).
2) Моделі сценаріїв.
3) Неформальний опис сценаріїв і акторів.
4) Опис інтерфейсів, сценаріїв і акторів.
5) Діаграми взаємодії об’єктів в рамках сценаріїв
(будуються на основі аналізу вимог до функцій ПС).

31.

Unified Modeling Language (UML) розробили Г.Буч, Дж.Рамбо та І.Джекобсон.
UML стала базовим методом при розробці ПЗ і є стандартом де-факто, як метод
моделювання ПП на всіх стадіях ЖЦ. Автори визначили UML, як мову для
специфікації, візуалізації, конструювання й документування ПС, а також мову
моделювання бізнес-застосувань. В UML концептуальна модель вимог
розглядається як сукупність нотацій – діаграм, які візуалізують основні елементи
структури системи. (Вимоги до ПС задаються в основному діаграмами 1 і 2).
Діаграми UML
1) діаграма сценаріїв (варіанти використання) – use case diagram
2) діаграма класів – class diagram
3) діаграми поведінки:
діаграма станів – statechart diagram
діаграма активності – activity diagram
4) діаграми взаємодії:
діаграма послідовності – sequence diagram
діаграма кооперації – collaboration diagram
5) діаграми реалізації:
діаграма компонентів – component diagram
діаграма розміщення – deployment diagram
Відмінності UML 2.0 полягають в обов'язковому використанні основних
пакетів метамоделі та діаграм композитних(складених) структур і додаткових
діаграм структур (діаграм пакетів та об'єктів). Застосовуються допоміжні
діаграми взаємодії (діаграма комунікації, огляду взаємодій та часова
діаграма), а також діаграма скінченного автомата (State machine diagram).

32.

Проектування – це етап ЖЦ ПС, що йде наступним після інженерії вимог.
Завдання етапу – перетворення вимог у проектні рішення, що мають
забезпечити побудову ПС з характеристиками, які відповідають вимогам
(відбувається трансформація множини вимог у простір проектних рішень).
Процеси, які є відносно незалежними один від одного (їх можна виконувати як
послідовно, так і паралельно командами розробників) :
1) Концептуальне проектування, яке складається з уточнення розуміння вимог
й узгодження деталей вимог. Виконується: уточнення даних; уточнення
інтерфейсів; уточнення функцій обробки даних (для зафіксованих
об’єктів уточнюється склад і зміст операцій та схема взаємодії об’єктів);
уточнення нефункціональних вимог (нефункціональні вимоги відображають
обмеження-накладаються організацією та середовищем використання системи).
2) Архітектурне проектування, що полягає у визначенні головних структурних
особливостей створюваної системи.
3) Технічне проектування, що полягає у відображенні вимог середовища
функціонування і платформи розробки системи у проектні рішення та
визначення конструкцій у вигляді компонентів системи або їх композиції
(прив’язка проекту до технічних особливостей платформи реалізації).
4) Детальне проектування слугує для визначення деталей та подробиць
функціонування і зв’язків для всіх компонентів системи.
Базовим стандартом опису проектування ПЗ є стандарт IEEE Std. 1016:1998 –
IEEE Recommended Practice for Software Design Descriptions.
Стандарт ІSО 13407:1999. Human-centred design processes for interactive systems опис процесів проектування людино-орієнтованих інтерактивних систем.

33.

Архітектурне проектування: порівнева архітектура ПС
4
Прикладні системи
3
Компоненти бізнес-застосувань
2
Загальносистемні компоненти (інтерфейс з
універсальними системами)
1
Системні компоненти (інтерфейс з обладнанням)
Архітектурне проектування полягає у визначенні: складу компонент; способів
їхньої композиції; обмеження на їх зв’язки та сполучення.
Трансформація проекту в програмну систему
Процес має кілька назв: конструювання,кодування, програмування,реалізація
Необхідно виконати конструювання, визначивши модулі, потім запрограмувати
модулі обраною мовою програмування, для чого переводять нотацію проекту в
коди, після чого проводиться тестування й верифікація отриманого коду ПС. В
цілому, необхідно перетворити проект у систему, документуючи достатнім чином всі
етапи трасформації, тобто реалізувати ПС. Конче необхідно при реалізації ПЗ
застосовувувати CASE-засоби.

34.

Рівень проекту розробки системи
Керівник проекту
системи
Менеджер
проекту
локальної
комп’ютерної
мережі (ЛКМ)
Системні
аналітики
Група проекту ЛКМ
Група
супроводу
Проектувальники
Менеджери
проекту ПЗ
Програмісти
Група якості
проекту
Група
верифікації та
валідації
Група управління
конфігурацією

35.

Якість ПС та аспекти її вимірювання
У 1998 році був введений в дію стандарт ІSО/ІЕС 15026 – System and software
integrity levels, який визначає рівні цілісності систем і ПЗ.
Стандарт пропонує визначати рівень оцінювання якості від A (вищого) до D
(нижчого), з врахуванням ризиків у сфері: безпеки функціонування (A – загроза
життю людей); захисту інформації (B – загроза втрати інформації); економіки (C –
загроза фінансових збитків); середовища функціонування (D – загроза руйнування
середовища експлуатації ПС). Cтандарт пропонує пріорітети важливості для
характеристик якості, що досягається введенням коефіцієнтів вагомості.
Вітчизняний стандарт ДСТУ 2850–94 «Показники та методи оцінювання якості»
рекомендує порядкову шкалу з п’яти значень: 5 – “вкрай важливо”, 4 – “дуже
важливо”, 3 – “важливо”, 2 – “добре було б”, 1 – “неважливо”.
Вимірювання – це одержання об’єктивних даних про стан продуктів, процесів та
ресурсів розробки ПС. Вимірювання проводять із метою побудови прогнозних і
оціночних моделей, які надалі застосовуються для керування проектом та
удосконалення процесів розробки ОР.
Вимірювання в проекті – це багатокроковий процес: 1) визначення мети
вимірювання – служить для систематизації процесів вимірювання;
2) побудова власне процесу вимірювання – модель вимірювання є
цілеорієнтованою і ґрунтується на декомпозиції мети;
3) вибір базових підходів до вимірювання мір ПС, які обираються таким чином, щоб
результат вимірювання робочих продуктів, процесів та ресурсів протягом ЖЦ
дозволяв оцінити їхню відповідність цілям проекту.

36.

Основні міри: -розмір і складність ПС (на основі цього можна оцінити трудомісткість
і вартість розробки);
- продуктивність (роботи фахівця й колективу в цілому);
- міри вимірювання атрибутів якості.
4) організація збору даних для виконання вимірювань (форми,тести,запитальники).
5) застосування моделей у процесі вимірювання.
Для оцінки ПС використовують два процеси: атестація ПС; сертифікація ПС.
Атестація проводиться ОР для перевірки того, чи відповідає ПС
заданим вимогам. У процесі атестації використовуєть тестування.
Сертифікація проводиться третьою стороною – спеціальним органом,
ліцензованим державою для таких дій. Сертифікація – це оцінка відповідності
властивостей ПС вимогам до неї. Сертифікаційні випробування проводяться
лабораторіїями сертифікації, які призначаються органом сертифікації.
Фактори, що впливають на якість ПС
1) Прикладна область і категорії користувачей. 2) Мета моделювання якості.
3) Стадія ЖЦ. Із плином етапів ЖЦ погляд на якість може змінюватися.
Цільова якість ПС (відображає потреби користувача);
Встановлена якість ПС – рівень значень характеристик якості, що заявлений
у специфікаціях вимог до ПС;
Прогнозована якість програмного продукту – рівень, що передбачається як
якість кінцевого програмного продукту; Якість продукту, що поставляється;
Експлуатаційна якість – якість вимірювана в термінах результату
використання ПС, але не її властивостей.

37.

Для високоцілісних систем найважливішою характеристикою є надійність, для
якої показник середнього часу між відмовами ПС в період експлуатації має бути не
меншим ніж 6 місяців. В той же час для систем з низьким рівнем цілісності
найважливішою характеристикою є функціональність, підхарактеристика
точність, для якої значення числа отриманих точних результатів має бути не
меншим від 95% загального числа отриманих результатів.
Галузь знань ІПЗ “Якість ПЗ”
1) Основи якості ПЗ - Software Quality Fundametals.
2) Процеси керування якістю - Software Quality Management Processes.
3) Практичні міркування - Practical Considerations.
1) Питання якості повинні розглядатися в контексті вимог до ПП => Вибір
характеристик якості. Вибір методів кількісної оцінки показників якості. Метрики
якості. Модель якості. Базовий стандарт якості ISO/IEC 9126 (parts 1-4).
Інженери з групи забезпечення якості мають сприймати питання якості як
частину власної професійної культури. Досягти компромісу між цінністю
характеристик якості для замовника і вартістю забезпечення необхідного їх рівня.
2) Процеси SQM – контроль і оцінка всіх процесів, продуктів та ресурсів
програмної інженерії на етапах ЖЦ з точки зору покращання їх якості.
CMM – Capability Maturity Model (Модель потужності, зрілості можливостей ОР).
ISO/IEC 15504:2004. Information technology – Software Process Assessment.
3) ІSО 9000-3:1997. Guidelines for the application of ISO 9001:1994 to the
development, supply, installation and maintenance of computer software.
Критичність області застосування (відмовостійкість, безпека експлуатації,
захищеність, зручність використання, рівень цілісності ПС).

38.

Якість – це сукупність властивостей ПС, які
забезпечують її здатність задовольняти встановлені або
передбачувані потреби відповідно до призначення ПС.
Інженерія якості ПС - керований процес інкорпорації в
ПС на кожній стадії ЖЦ певних властивостей, які
називають характеристиками якості.
Характеристика
якості
х
х
х
х
Атрибути якості
х
Підхарактеристика
якості

39.

Згідно стандарта ISO/IEC 9126 існують три види якості ПЗ:
External quality (зовнішня якість);
Internal quality (внутрішня якість);
Quality in use (якість у використанні).
Модель якості – це множина взаємозалежних характеристик
якості, що утворює базис для специфікації вимог до якості й
оцінювання якості.
Модель якості, а також метрики якості розглянуті в серії
стандартів ISO/IEC 9126 (parts 1-4) 2001-2004рр. :
ISO/IEC 9126-1 – Модель якості ПС;
ISO/IEC 9126-2 – Метрики зовнішньої якості ПС;
ISO/IEC 9126-3 – Метрики внутрішньої якості ПС;
ISO/IEC 9126-4 – Якість у використанні.

40.

Зв’язок між системами та типи якості
ПС: внутрішня
якість
ПС: зовнішня
якість
ПС
Інформаційна система
Інформаційна система
Зовнішня система (бізнес-система)
ПС: якість у
використанні

41.

Зовнішні характеристики якості відображають вимоги до продукту. Кожна
характеристика якості складається з підхарактеристик. Аби кількісно визначити
критерії якості, специфікують зовнішні вимірні властивості (зовнішні атрибути) і
пов’язані з ними метрики, які являють собою моделі оцінювання атрибутів.
Зовнішні метрики – це метрики застосування яких можливо тільки для ПЗ, яке
працює на комп’ютері та перебуває на стадії тестування або функціонування.
Внутрішні атрибути використовуються для планування досягнення потрібного
рівня зовнішніх характеристик якості.
Визначаються також внутрішні метрики для вимірювання внутрішніх
характеристик якості, тобто атрибути й метрики пов’язані з непрацюючими
на комп’ютері програмними продуктами (документація на ПС, тексти програм,
тестові набори даних тощо). Ці продукти утворюються на стадії розробки, що
передує тестуванню. Зовнішні й внутрішні характеристики якості відносяться до
власних властивостей ПС і відображають погляд замовника й розробника на якість.
Існує ще й третій погляд на якість – погляд кінцевого користувача, який очікує
максимальної ефективності від використання ПС – підвищення продуктивності й
загальної задоволеності. Такий підхід визначає якість у використанні (quality in
use), або експлуатаційну якість.
Експлуатаційна якість – це сукупний ефект характеристик якості для кінцевого
користувача. Вона виміряється в термінах результату використання ПС, але не у
властивостях самої ПС.
У процесі розробки можуть виникати конфлікти вимог : елементи множин
функціональних і нефункціональних вимог до ПС (у тому числі вимог до якості),
можуть вступати в конфлікти, які потрібно вирішувати.

42.

Концепція підвищення якості ПС. Методи підвищення якості
Перший крок – це впровадження в практику організації-розробника (OP)
спеціальних підтримуючих процесів ЖЦ ПС, які регламентуються в стандарті
ISO/IEC 12207, а саме: процес гарантування якості ПЗ (SQA);
процес верифікації; процес валідації; процеси спільних перевірок.
Процес SQA (Software Quality Assurance) – застосування ОР методів і засобів
контролю якості на всіх процесах і етапах ЖЦ ПС. Процес SQA регламентований у
стандарті IEEE Std. 730:1998 – IEEE Standard for Software Quality Assurance Plans.
Верифікація – це дослідження трансформації вхідних робочих продуктів у вихідні;
при цьому перевіряється, чи правильно розробляється програмний продукт
(наприклад, чи правильний код програми по відношенню до вхідних специфікацій).
Валідація – це дослідження сукупності робочих продуктів на певному етапі
процесу розробки на предмет, аби упевнитися чи правильно вони розроблені (чи
відповідають призначенню та специфікованим вихідним вимогам до ПП).
Процеси верифікації і валідації (verification and validation – V&V) регламентуються
стандартами IEEE Std. 1059:1993 – IEEE Guide for Software Verification and
Validation Plans та IEEE Std. 1012:1998 – IEEE Standard for Software V&V.
Процеси спільних колективних перевірок – це перевірка робочих продуктів ПС
(описів вимог, описів проекту, текстів програм системи, експлуатаційної та іншої
документації тощо) групою осіб та прийняття погодженого спільного рішення.
Проведення формальних спільних перевірок регламентується стандартом
IEEE Std. 1028:1997 – IEEE Standard for Software Reviews. ( 5 видів перевірок).

43.

План верифікації і валідації ПС
Призначення
Посилання
Визначення
Організація роботи по V&V
4.1. Організація
4.2. Графік робіт
4.2 Схема призначення рівнів цілісності ПО
4.4. Розподіл ресурсів
4.5Відповідальності
4.6. Інструменти, методології і методи
5. Процеси і дії з V&V
5.1. Процес: Управління
5.1.1. Дія: Управління V&V
5.2. Процес: Придбання
5.2.1. Дія: V&V підтримки придбання
5.3. Процес: Постачання
5.3.1. Дія: V&V планування
5.4. Процес: Розробки
5.4.1. Дія: V&V Концепції
5.4.2. Дія: V&V Вимог
5.4.3. Дія: V&V Проекту
5.4.4. Дія: V&V Реалізації
5.4.5. Дія: V&V Випробувань
5.4.6. Дія: V&V Введення в дію
5.5. Процес: Експлуатація
5.5.1. Дія: V&V Експлуатації
5.6. Процес: Супровід
5.6.1. Дія: V&V Супроводу
6. Вимоги до звітних документів V&V
7. Вимоги до адміністративних процедур
7.1.Реєстрація і ухвалення рішень по аномаліях
7.2. Політика ітерації завдань
1.
2.
3.
4.
7.3. Регулювання відхилень від плану
7.4. Процедури контролю
7.5. Стандарти, практичне керівництво і угоди
8. Вимоги до документування V&V

44.

Входи V&V
- Опис концепції
системи
- Плани та графіки
розробки
- Потреби
користувача
- Потреби замовника
- Призначення рівнів
цілісності
- Звіт про аналіз
загроз
- Результати
розв’язання задач
V&V
Дії по V&V
концепції
Задачі V&V
- Оцінка документу
концепції
- Аналіз критичності
- Аналіз розподілення
вимог (до ТО/ ПЗ)
- Аналіз трасованості
- Аналіз загроз
- Аналіз ризику
Виходи V&V
- Звіти про задачі
- Звіти про аномалій
Входи V&V
- Документи
прийнятої концепції
- Специфікація вимог
до ПЗ
- Специфікація вимог
до інтерфейсів
- Звіт про критичність
задачі
- Документація
користувача
- План випробувань
системи
- план прийомочних
випробувань
- Документація
процесу управління
конфігурацією ПЗ
- Звіт про аналіз загроз
- Плани і графіки
розробки
- Результат рішення
задач V&V
Дії по V&V
вимог
Задачі V&V
- Аналіз трасованості
- Оцінка вимог до ПЗ
- Аналіз інтерфейсів
- Аналіз критичності
- Створення/верифікація
плану тестування для
V&V системи (С)
- Створення/верифікація
плану тестування для
V&V приймання (П)
- Оцінка стану
управління
конфігурацією
- Аналіз загроз
- Аналіз ризику
Виходи V&V
- Звіти про задачі
- Звіти про аномалій
- Плани тестування
для V&V системи/
приймання
Входи V&V
- Специфікація вимог до
ПЗ
- Опис проекту ПЗ
- Специфікація вимог до
інтерфейсів
- Документ проекту
інтерфейсу
- Стандарти
проектування
- Документація концепції
- Звіт про критичність
задачі
- Проекти та плани
випробувань
- Документація
користувача
- Звіт про аналіз загроз
- Плани та графік
розробки
- Результат вирішення
задач V&V
Дії по V&V
проекту
Входи V&V
- Опис проекту ПЗ
- Документ проекту
інтерфейсу
- Початковий код
- Стандарти кодування
- Документація
користувача
- Документація концепції
- Звіт про критичність
задачі
- Проекти/ набори тестів
- Процедури тестування
- Результат тестування
компонентів
- Звіт про аналіз загроз
- Плани та графік
розробки
- Результат вирішення
задач V&V
Дії по V&V
реалізації
Задачі V&V
- Аналіз трасованості
- Оцінка проекту ПЗ
- Аналіз інтерфейсів
- Аналіз критичності
- Створення/верифікація
плану тестування для
V&V компонентів (К)
- Створення/верифікація
плану тестування для
V&V інтеграції (І)
- Створення/верифікація
проекту тестування для
V&V
- Аналіз загроз
- Аналіз ризику
Задачі V&V
- Аналіз трасованості
- Аналіз початкового коду
та документації
початкового коду
- Аналіз інтерфейсів
- Аналіз критичності
- Створення/верифікація
тестових наборів для V&V
- Створення/верифікація
тестових процедур для
V&V
- Створення/верифікація
тестів компонентів
- Аналіз загроз
- Аналіз ризику
Виходи V&V
- Звіти про задачі
- Звіти про аномалій
- Плани тестування для
V&V К/І
- Проекти тестів для V&V
К/І/С/П
Виходи V&V
- Звіти про задачі
- Звіти про аномалій
- Набори тестів для V&V
К/І/С/П
- Процедури тестування
для V&V К/І/С
Входи V&V
- Плани, проекти,
набори і процедури
тестування
- Опис проекту ПЗ
- Документ проекту
інтерфейсу
- Початковий та
кінцевий код
- Результат тестування
компонентів
- Документація
користувача
- Звіт про аналіз загроз
- Плани та графік
розробки
- Результат вирішення
задач V&V
Входи V&V
- Пакет інcталяції
- Документація
користувача
- Звіт про аналіз загроз
- Плани та графік
розробки
- Результат вирішення
задач V&V
- Підсумковий звіт про
дії V&V
Дії по V&V
випробувань
Задачі V&V
- Аналіз трасованості
- Створення/верифікація
тестових процедур для V&V
прийманя
- Виконання/верифікація
тестів для V&V інтеграції
- Виконання/верифікація
тестів для V&V системи
- Виконання/верифікація
тестів для V&V приймання
- Аналіз загроз
- Аналіз ризику
Виходи V&V
- Звіти про задачі
- Звіти про аномалій
- Процедури тестування
для V&V приймання
Дії по V&V
інсталяції пуску
Задачі V&V
- Аудит інсталяційної
конфігурації
- Пробний пуск
- Аналіз загроз
- Аналіз ризику
- Генерація заключного
звіту V&V
Виходи V&V
- Звіти про задачі
- Звіти про аномалій
- Заключний звіт про V&V

45.

Технічний огляд - це систематична оцінка придатності ПП для використання по
призначенню та ідентифікація розбіжностей зі специфікаціями і рекомендаціями
стандартів та керівництв.
Управлінський огляд - систематична оцінка стану процесів ЖЦ з метою контролю
просування проекту, визначення планів, розподілу ресурсів і додержання стандартів.
Формальна інспекція - це систематична перевірка ПП з метою виявлення та
ідентифікації проблем, включаючи дефекти та відхилення від специфікацій і стандартів.
Наскрізний перегляд - це запланований систематичний контроль перебігу розробки
ПП і оцінка його стану. Мета – пошук дефектів, покращання продукту, оцінка
відповідності специфікаціям і стандартам.
Аудиторська перевірка - це аналіз та незалежна перевірка продукту або процесу
третьою стороною з метою оцінювання відповідності стандартам, керівництвам, планам,
умовам договору. Вона виконується групою зовнішніх аудиторів (1-5 чоловік).
Другий крок по підвищенню якості – це досягнення ОР високого рівня зрілості.
Основними стандартами в області якості продукту є стандарти серії ISO 9000.
Серія заснована на методології CMM (Capability Maturity Models – модель
зрілості можливостей). Методологія CMM та шляхи її впровадження в діяльність
організації-розробника ПП докладно розглянуті в стандартах серії ISO 9000.
Стандарт ISO 9000 рекомендує кожній ОР мати свою власну систему якості.
Система якості ПС (за стандартом ДСТУ 2844) – це сукупність організаційної
структури, відповідальності, процедур, процесів і ресурсів, які спрямовані на
реалізацію керування якістю ПС.
Ядро інженерії якості базується на елементах SWEBOK (SoftWare Engineering
Body Of Knowledge) та PMBOK (Project Management Body Of Knowledge)

46.

Ядро професійних знань інженерії якості
У 90-х роках світове комп’ютерне співтовариство почало систематизацію знань у
різних галузях комп’ютерних наук та інформатики з метою зафіксувати їх у вигляді
ядер знань. Для створення ядра знань по програмній інженерії зусиллями ACM
(Association for Computing Machinery) та IEEE Computer Society був створений
координаційний комітет по програмній інженерії SWECC (SoftWare Engineering
Coordinating Committee), в який увійшли спеціалісти світового рівня.
Ядро знань по програмній інженерії у остаточній редакції підкомітету “Software and
System Engineering” ISO/IEC вийшло у 2004 році під назвою: Software Engineering
Body of Knowledge (SWEBOK) Керівництво по SWEBOK було видане згодом у
формі стандарту ISO/IEC 19759. Software Engineering – Guide to SWEBOK.
Керівництво по ядру знань в галузі управління проектами було розроблено
організацією PMI (Project Management Institute). Третя версія PMBOK містить опис
процесів та ключових галузей знань з управління проектами в промисловості та
створення ПЗ. Встановлено рубрики (розділи) як для SWEBOK, так і для PMBOK, а
ядро знань інженерії якості було синтезовано на їх базі.
У ядро знань інженерії якості увійшли такі розділи: концепція якості ПС; процеси
ЖЦ ПС і моделі ЖЦ; контроль і забезпечення гарантій якості (SQA); процеси та
методи перевірки в ЖЦ ПС; вимірювання й прогнозування якості ПС; оцінювання
якості ПС; керування якістю; система якості ПС і сертифікація.
Під інженерією якості ПС розуміють керований процес інкорпорації в ПС на
кожній стадії ЖЦ певних властивостей, які називають характеристиками якості.
Наявність і рівень досягнення цих властивостей вимірюється, прогнозується,
оцінюється й регулюється за допомогою сукупності стандартів, процесів і методів.

47.

Ядро професійних знань інженерії якості. Зв'язок ядра знань інженерії якості з
елементами SWEBOK та PMBOK
PMBOK
Управління інтеграцією проекту
Управління змістом проекту
Управління тривалістю проекту
Управління вартістю проекту
Управління якістю проекту
Управління трудовими ресурсами
Управління комунікацією
Управління ризиком проекту
Управління закупівлями/постачанням
.......
Ядро знань інженерії якості
1) Концепції якості ПС
2) Процеси життєвого циклу ПС і моделі ЖЦ
3) Контроль і забезпечення гарантій якості (SQA)
Визначення вимог до якості
Планування якості
Стандарти, методи, інструменти якості
4) Процеси та методи перевірки в ЖЦ ПС
Верифікація та валідація ПС (V&V)
Інспекції, тестування та випробування ПС
5) Вимірювання й прогнозування якості ПС
Моделі і метрики якості
Парадигми вимірювань
6) Оцінювання якості
Оцінювання якості ПС
Оцінювання потужності процесів ЖЦ ПС
Моделі зрілості організацій розробників ПС
7) Керування якістю
Методології управління розробкою
Керування ризиком проектів
8) Система якості ПС і сертифікація
Сертифікація згідно стандартів ISO 9000
SWEBOK
Програмні вимоги
Процес інженерії вимог
Аналіз вимог
Перевірка вимог
Специфікація вимог
Проектування ПС
Структура та архітектура
Нотації проектування
Аналіз та оцінка якості проекту
Стратегії та методи
Конструювання (реалізація) ПС
Управління конструюванням
.......
Тестування ПС
Рівні, прийоми та метрики тестування
Процес тестування
Супровід ПС
Процес супроводу та його прийоми
Управління конфігурацією ПС
Управління процесом
Ідентифікація конфігурації
Аудит конфігурації
Управління випуском та постачанням
Управління інженерією програмного забезпечення
Ініціювання проекту
Планування проекту
Виконання проекту
Огляд та оцінка проекту
Закриття проекту
Вимірювання в інженерії ПЗ
Процес програмної інженерії
Реалізація та зміна процесу
Визначення та оцінювання процесу
Вимірювання процесу і продукту
Інструменти та методи інженерії ПЗ
Інструментии інженерії ПЗ
Методи інженерії ПЗ
Якість ПС
Процеси
. . . . . . . керування якістю

48.

Процес інженерії якості має гарантувати, що:
- вимоги до якості враховують погляд замовників, користувачів і розробників ПС;
- всі вимоги до якості можуть бути виміряні кількісно або верифіковані;
- процеси ЖЦ містять процедури, орієнтовані на виявлення вимог до якості
й аналіз досягнення властивостей якості;
- стандарти в області якості визначені й дотримуються;
- розробник ПС розуміє цілі якості й вбудовує в ПП властивості, які
забезпечують зовнішню, внутрішню й експлуатаційну якість;
- група якості на підприємстві проводить виміри й оцінювання якості ПП;
- результати вимірів використовуються для керування програмним проектом;
- виконуються процеси V&V та тестування ПС з метою перевірки відповідності
ПС вимогам до якості.
Стандарт ISO/IEC 12207 не виділяє інженерію якості у вигляді окремого
процесу ЖЦ, однак із представлених в ньому процесів, безпосередньо інженерії
якості стосуються наступні процеси:
- керування проектом;
- керування якістю;
- керування ризиками;
- гарантування якості (SQA);
- процеси V&V;
- аналіз вимог до ПС;
- процес вимірювання;
- удосконалення процесів ЖЦ.

49.

Атрибути ПС, які характеризують якість, виміряються за
допомогою метрик якості.
Метрика – це комбінація конкретного методу вимірювання
атрибута сутності й шкали вимірювання.
Модель якості ПС
С1
S1
A1
S2
A2
С2
…….
0 рівень
Сn
…….
S3
…….
Characteristic, Subcharacteristic, Attribute
1 рівень
2 рівень
3 рівень

50.

Метод вимірювання визначає спосіб одержання значень атрибута якості певної
сутності. Шкала використовується для структурування отриманих значень.
Метрика визначає міру атрибута, тобто змінну, котрій присвоюється значення
в результаті вимірювання. Наприклад, сутність – це звіт про виявлення дефектів у
ПС, атрибут – список дефектів, метод вимірювання – підрахунок кількості
дефектів, шкала – цілі числа більше 0, міра атрибута – загальне число
дефектів, ім’я метрики (однойменне мірі) – загальне число дефектів.
Міра атрибута є безпосередньою, якщо вона не залежить від мір інших атрибутів,
або побічною, якщо утворюється на основі мір інших атрибутів.
В основі базової метрики лежить елементарний метод вимірювання атрибута.
Стандарт ISO/IEC 9126-2 рекомендує застосовувати 5 видів шкал виміру значень:
номінальна шкала (класифікаційна шкала); порядкова шкала, яка дозволяє
впорядковувати властивості по зростанню/зменшенню, шляхом порівняння з
базовим значенням; інтервальна шкала – відзначає дистанцію між
властивостями об’єкта (арифметичні операції та операції порівняння);
відносна шкала – значення розрізняються відносно обраної одиниці вимірювання
(найбільш пріорітетна шкала); абсолютна шкала є спеціальним випадком
відносної шкали, де вказується абсолютне значення величини.
Інформацію про рівень задоволення вимог до якості задають області (ранги) на
шкалі, які відповідають різним ступеням задоволеності вимог.

51.

Метрика в системі вимірювання якості
ПС (робочий продукт)
Модель якості
Множина
атрибутів
характеристика
впливає на
Атрибут
характеризує
підхарактеристика
вимірюється за
допомогою
вимірює
міра: число/категорія
обчислює
отримує
значення з
Метрика
включає
множина значень
структурує
Шкала
вимірювань
включає
Метод (способ
отримання значень)

52.

Рівні ранжування метрик
плановий рівень
виміряне значення
вимоги перевиконані
область цільових значень
поточний рівень
мінімально припустимі
значення
гірші значення
Шкала вимірювань
неприпустимі
значення
Рівні ранжування

53.

Класифікація мір та метрик якості
Стандарт ISO/IEC 9126-2 визначає наступні типи мір:
міра розміру – представляє розмір ПС в одиницях вимірювання (функціон.
розмір, число функцій або модулів, кількість рядків у програмах, розмір дискової
пам’яті та ін.); міра часу – періоди реального часу (у секундах, хвилинах, годинах
процесорного часу, час функціонування системи); міра зусиль –корисний час
пов’язаний з певним завданням (продуктивність праці, трудомісткість);
міра інтервалів між подіями (наприклад, час між відмовами);
рахункові міри – статичні лічильники для обліку певних елементів у робочих
продуктах ПС (текстів програм та документації), або динамічні лічильники
(вимірюють кількість помилок, число відмов, відповідей системи на запити тощо).
Метрики зазвичай класифікуються наступним чином:
Об’єктивна/суб’єктивна. Об’єктивна включає підрахунок елементів, які можуть
бути незалежно перевірені (число операторів коду, число помилок); суб’єктивна
ґрунтується на індивідуальному (експертному) розумінні певних властивостей
(рівень складності проблем, модулів тощо).
Примітивні/такі що обчислюються. Примітивні – це базові метрики, які
безпосередньо спостерігаються (розмір програми, число дефектів); такі що
обчислюються – обчислюються на основі примітивних метрик (трудомісткість);
Динамічні/статичні. Динамічним метрикам властивий компонент часу (число
помилок за місяць); статичні метрики не залежать від часу (число виявлених
загалом дефектів); Такі що передбачаються (прогнозуючі)/пояснюючі. Значення
прогнозуючих метрик отримують заздалегідь (прогнозована кількість відмов);
значення пояснюючих з’являються постфактум (реальна інтенсивність відмов).

54.

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

55.

Модель зовнішньої і
внутрішньої якості
згідно стандарта ISO/
IEC 9126 (2001)
1. Функціональність
(Functionality)
2. Надійність
1. Функціональна
повнота(suitability)
2. Точність
(accuracy)
3. Здатність до
взаємодії
(interoperability)
4. Захищеність
(security)
5. Узгодженість
(functionality
compliance)
1. Завершеність (maturity)
2. Відмовостійкість (foult
tolerance)
3. Відновлюваність
(recoverability)
4.Узгодженість
(reliability
compliance)
(Reliability)
3. Зручність
використання
(Usability)
4. Ефективність
1. Зрозумілість
(understandability)
2. Вивчаємість
(learnability)
3. Керованість
(operability)
4. Привабливість
(attractiveness)
5. Узгодженість
(usability
compliance)
1. Реактивність
(time behaviour)
2. Використовуваність ресурсів
(resource
utilisation)
3. Узгодженість
(efficiency
compliance)
(Еfficiency)
5. Cупроводжуваність
(Maintainability)
6.Переносимість
1.Аналізованість
(analysability)
2.Модернізованість (або
змінюваність)
(changeability)
3. Стабільність
(stability)
4. Тестованість
(testability)
5. Узгодженість
(maintainability
compliance)
1. Адаптованість
(adaptability)
2. Зручність
установки
(installability)
3. Здатність до
співіснування
(co-existence)
4. Заміщувальна
здатність
(replaceability)
5. Узгодженість
(portability
compliance)
(Portability)

56.

Функціональність (functionality) – властивість ПС виконувати функції у
відповідності встановленим і очікуваним потребам при використанні у вказаних
умовах. Містить підхарактеристики:
- функціональна повнота (suitability, іноді – функціональна придатність) –
властивість ПС надавати належну множину функцій для вирішення
специфікованих задач і досягнення цілей користувача;
- точність (accuracy) – властивість ПС забезпечувати правильні й погоджені
результати чи впливи з необхідним ступенем точності;
- здатність до взаємодії (interoperability) – властивість ПС взаємодіяти з
однією чи більш специфікованими системами;
- захищеність (security) – здатність ПС забезпечувати захист інформації від
несанкціонованого доступу осіб або систем на читання або модифікацію,
та доступність інформації для осіб і систем, що володіють правами доступу;
-узгодженість функціональності із нормативними документами (compliance).
Надійність (reliability) – властивість ПС зберігати рівень функціонування при
роботі в зазначених умовах. Підхарактеристики:
- завершеність (maturity, іноді –безвідмовність) – властивість ПС уникати відмов
через дефекти, що містяться в ній;
- відмовостійкість(fault tolerance, або стійкість до відмов) – властивість ПС
підтримувати встановлений рівень функціонування в умовах прояву дефектів, а
також помилок у даних або порушень специфікованого інтерфейсу;
- відновлювальність (recoverability) – властивість ПС відновлювати функціонування
на заданому рівні та відновлювати пошкоджені програми й дані;
- узгодженість характеристики reliability із нормативними документами.

57.

Зручність використання (usability) – властивість ПС бути зрозумілою,
освоюваною, зручною і привабливою для користувачів, при використанні в
зазначених умовах. Підхарактеристики:
- зрозумілість (understandability) – властивість ПС, яка дає користувачу зрозуміти
чи дійсно ПС може задовольнити його потреби, та як вона може використовуватися
для вирішення визначених задач і які умови її використання;
- вивчаємість (learnability, іноді – освоюваність) – властивість ПС, що забезпечує
користувачів можливістю освоїти прийоми її застосування;
- керованість (operability) – властивість ПС, яка надає можливість користувачу
керувати або контролювати її дії;
- привабливість (attractiveness) – властивість ПС, яка забезпечує її привабливість
для користувача;
- узгодженість характеристики usability із нормативними документами.
Ефективність (efficiency) – властивість ПС забезпечувати раціональне
використання виділених ресурсів при роботі у встановлених умовах.
Містить такі підхарактеристики:
- реактивність (time behavior, або ефективність у часі) – властивість ПС
забезпечувати належний час відповіді (відгуку) та обробки завдань, а також рівень
пропускної спроможності при виконанні функцій ПС у встановлених умовах
застосування;
- використовуваність ресурсів (resource utilization) – властивість ПС
використовувати належні ресурси в потрібні періоди часу при виконанні своїх
функцій у встановлених умовах застосування;
- узгодженість характеристики efficiency з нормативними документами.

58.

Супроводжуваність (maintainability) – властивість ПС забезпечувати можливість
її ефективної модифікації. Модифікація може включати коригування,вдосконалення
або адаптацію ПС до змін середовища, вимог або функціональних специфікацій.
- аналізованість (analyzability) – властивість ПС, яка дає можливість діагностувати
її недоліки або причини відмов, а також ідентифікувати частини для модифікації;
модернізованість (changeability, або змінюваність) – властивість ПС, що дає
можливість виконувати встановлені види модифікацій;
- стабільність (stability) – властивість ПС мінімізувати несподівані ефекти
модифікацій;
- тестованість (testability) – властивість сприяти перевірці модифікованого ПЗ;
- узгодженість характеристики maintainability із нормативними документами.
Переносність (portability) – властивість ПС бути перенесеною з одного
середовища до іншого.
- адаптованість (adaptability) – властивість ПС адаптуватися для застосування в
різних специфікованих середовищах без використання дій і засобів відмінних від
тих, які спеціально призначені для цих цілей;
- зручність установки (installability, іноді – настроюваність) – властивість ПС, що
зумовлює її здатність до інсталяції в специфікованому середовищі;
- здатність до співіснування (co-existence, або сумісність) – властивість ПС
співіснувати з іншими незалежними ПС у загальному середовищі, розділяючи
загальні ресурси;
- заміщувальна здатність (replaceability) – властивість ПС бути використаною
замість інших специфікованих ПС у середовищі їхнього застосування;
-узгодженість характеристики portability з нормативними документами.

59.

Для кожної підхарактеристики якості існує декілька різних метрик якості,
а тому в моделі якості запроваджують атрибути. Кожний атрибут вимірюють за
допомогою відповідної метрики.
У формулі (1): Q – множина взаємозалежних характеристик (властивостей) якості,
Сi – i-та характеристика якості, Sij – j-та підхарактеристика i-ї характеристики
якості, Аijk – k-й атрибут j-ї підхарактеристики i-ї характеристики якості, Мijk –
метрика k-го атрибута j-ї підхарактеристики i-ї характеристики якості, Wijk –
коефіцієнт ваги (значимості) k-го атрибута j-ї підхарактеристики i-ї характеристики
якості. Крім того: i, j, k – індекси, I – загальна кількість характеристик якості в моделі
якості, Ji – загальна кількість підхарактеристик i-ї характеристики якості, Kij –
загальна кількість атрибутів j-ї підхарактеристики i-ї характеристики якості.
Загальна формула моделі якості
Q Ci Sij Aijk M ijk ,Wijk k 1
K ij
Ji
I
j 1 i 1
(1)
Інтегральна формула моделі якості ( інтегральний рівень якості )
K ij
Ji
I
U q Wi Wij Wijk Qijk
i 1
j 1
k 1
(2)

60.

• Після визначення всіх елементів моделі (1) можна перейти до
випробувань, в ході яких обчислюються фактичні значення атрибутів
підхарактеристик якості. Ці значення порівнюються із обмеженнями,
заданими у вимогах.
• Якщо отримані фактичні значення показників якості відповідають
вимогам, то подальшу оцінку можна провести, використовуючи
інтегральний показник якості. Інтегральний показник якості (2) можна
застосувати для вибору кращого ПЗ із декількох конкуруючих в даній
області (галузі), при умові узгодження конфліктуючих атрибутів якості (у
формулі (2) Qijk – відносний показник якості k-го атрибута, j-ї
підхарактеристики i-ї характеристики моделі якості). Але, оскільки
в моделі є показники з різними метриками (неперервні числові, бальні,
номінальні та інші), необхідно попередньо провести узгодження та
нормування метрик, що роблять шляхом уведення шкал для якісних та
категорійних критеріїв і заданням вагових множників.
• Таким чином, враховуючи (1), інтегральний (узагальнений) рівень якості
ПС Uq можна обчислити як середньозважений показник по формулі (2).
• Необхідно провести узгодження конфліктуючих атрибутів якості.
• Необхідно провести нормування метрик атрибутів якості.

61.

Фрагмент матрицы конфликтов характеристик качества

62.

Приклад обчислення рівня якості атрибута, який вимірюється
відповідно до метрики functional implementation completeness
(закінченість, завершеність функціональної реалізації)
підхарактеристики suitability (функціональна повнота)
характеристики функціональність.
Це буде перший атрибут першої підхарактеристики першої
характеристики якості моделі, тобто: Q111. Міра цього атрибута
вимірюється відповідно до метрики X. Рівень якості цього атрибута
будемо обчислювати по формулі:
Q111 X 1 A / B
(3)
A – кількість нереалізованих функцій; B – кількість функцій, котрі
мають бути реалізовані відповідно до специфікацій та описів ПС.

63.

Приклад для ПрО “Діяльність поліклініки”
Інтервали значення для метрики Fault density визначаємо на основі
припущення, що максимальним допустимим значенням є 1 помилка на
100 рядків коду. Кількість в 100 рядків визначена на основі середнього
розміру методу класу в вихідному коді ПС. Значення метрики Available
co-existence оцінюємо, припускаючи, що максимальною допустимою
кількістю помилок при використанні стороннього ПЗ може бути 1
помилка за всю тривалість робочого дня (8 годин). В кращому випадку
можна розраховувати на 1 помилку за робочий тиждень(5 робочих днів).
Метрику Help frequency унормовуємо виходячи з припущення, що в
оптимальному випадку для використання невідомої функції системи
користувачу достатньо 2 звернень до довідки, для ознайомлення та
перевірки результатів, а відповідно трьохкратне перевищення даного
значення є неприпустимим (6–“2”, 5 –“3”,4 –“3”,3 –“4”, 2–“5”).
Pijk
Відносний показник якості визначається зі співвідношення Qijk
PBijk
Pijk - рівень якості ijk-го елемента показника якості; PBijk - базове значення
ijk-го елемента. Але оцінювання системи на основі різнорідних числових
значень рівня якості атрибутів не буде достовірним, тому доцільно їх
нормувати та привести значення метрик Fault density, Help frequency,
Pijk
Available co-existence до вигляду:
Qijk 1
; Qijk 0,1
(4)
PBijk

64.

- 2.Надійність. 2.1. Завершеність.
A 91
0,42
P
=
=
=
0,42[
Добре];Q
=
1−
= 0,58
- Fault density 211 B 215
211
1,0
- 3.Зручність використання. 3.2. Вивчаємість.
- Help frequency
5
P 321= A= 5[Задовільно];Q321= 1− = 0,16
6
- 4.Переносимість. 4.3.Здатність до співіснування.
- Available co-existence
A 4
0,8
P 421= = = 0,8[Задовільно];Q421= 1− = 0,2
T 5
1,0

65.

Взаємозв’язок понять при оцінюванні якості
Користувач
Розробник
володіє
визначає
забезпечує
Експлуатаційна
якість
залежить від
ПС
Властивості
Характеризують
Зовнішня якість
Характеризують
залежить
від
Внутрішня якість

66.

Експлуатаційна якість
На відміну від моделі зовнішньої і внутрішньої якості, для опису
експлуатаційної якості служить однорівнева модель, яка розподіляє атрибути
експлуатаційної якості по чотирьом характеристикам.
Характеристики експлуатаційної якості:
Результативність (іноді – ефективність, effectiveness) – ступінь у якій
користувач досягає заданих цілей по точності й повноті вирішення задач у
встановленому контексті використання ПС.
Продуктивність (productivity) – ступінь у якій витрачаються ресурси на
досягнення користувачем заданої ефективності у встановленому контексті
використання ПС.
Безпечність (safety) – рівень ризику завдання матеріальних і моральних
збитків, тобто шкоди здоров’ю людей, бізнесу, майну, навколишньому середовищу
при використанні ПС у встановленому контексті.
Задоволеність (satisfaction) – ступінь у якій користувач задоволений ПС у
певному контексті її використання.

67.

68.

Метрики в узагальненій моделі якості
Метрики в узагальненій моделі класифікуються по підхарактеристикам внутрішньої
і зовнішньої якості, а також по характеристикам експлуатаційної якості, що
описані у 2-й, 3-й і 4-й частинах стандарту ISO/IEC 9126.
Опис метрик виконаний за єдиною схемою із зазначенням наступної інформації:
- ім’я метрики. Відповідні метрики внутрішньої і зовнішньої якості мають однакові
імена;
- призначення метрики. Формулюється у вигляді питання, на яке дає відповідь
метрика, що застосовується;
- метод застосування. Містить правила одержання даних і схему їхнього
використання в метриці;
- формула й елементи даних. Вказується формула обчислення й пояснюються
елементи даних, які беруть в них участь;
- інтерпретація виміряних даних. Діапазон значень і найліпше значення;
- тип шкали метрики, тип міри;
- вихідні дані. Джерело даних, що використовується у вимірі.
- процес ЖЦ. Вказується процес у якому рекомендується застосування цієї
метрики для виміру відповідних мір атрибутів якості.

69.

Зв’язок між системами
ПС: внутрішня
якість
ПС: зовнішня
якість
ПС
Інформаційна система
Інформаційна система
Зовнішня система (бізнес-система)
ПС: якість у
використанні

70.

Якість у життєвому циклі ПС
Вимоги користувача
до якості
Використання та
зворотній зв'язок
Сприяють точному
визначенню
Вимоги до зовнішньої
якості
Вказує
Зовнішня якість
Валідація
Сприяють точному
визначенню
Вимоги до внутрішньої
якості
Якість у
використанні
Вказує
Внутрішня якість
Верифікація

71.

Взаємозвязок між моделями якості стандарту ISO/IEC 9126
Експлуатаційна
якість
Зовнішня якість,
Внутрішня якість
Функціональність
Результативність
Надійність
Продуктивність
Зручність
використання
Безпечність
Ефективність
Задоволеність
Супроводжуваність
Переносність

72.

Оцінювання внутрішньої якості програмної ситеми на основі стандарту
ISO/IEC 9126-3. Застосування системи метрик М.Холстеда та Т.Маккейба
Метрична теорія програм
Метрики, що
засновані на
аналізові лексики,
потоку керування,
даних, модульних
та міжмодульних
зв’язків
Математичні
моделі визначення
кількісних значень
характеристик
програм
Оцінювання відхилення
від норми, прогноз
значень характеристик,
які формують прийняття
рішення про
відповідність ПЗ
заданим вимогам
Метрики Холстеда відображають лексичний підхід до вимірювання
характеристик ПЗ, заснований на вимірних властивостях алгоритмів. Властивості
будь-якого опису алгоритму (або програми) можуть бути виміряні чи обчислені на
основі таких метричних характеристик:
n1 – кількість різних (відмінних один від одного) операторів програми;
n2 – кількість різних (відмінних один від одного) операндів програми;
N1 – загальна кількість операторів програми;
N2 – загальна кількість операндів програми.

73.

На цій основі Холстед визначає такі метрики:
Словник програми (в умовних одиницях) n = n1+n2
(5.1)
Довжина реалізації (в умовних одиницях) N = N1+N2
(5.2)
Довжина програми (в умовних одиницях) Ñ = (n1 log2 n1)+(n2 log2 n2) (5.3)
Обсяг програми (у бітах)
V = (N1+N2) log2(n1+n2)
(5.4)
Потенційний обсяг програми
V* = (n2*+2) log2(n2*+2),
(5.5)
де n2* – загальна кількість вхідних і вихідних параметрів.
Припускаємо, що в програмах, ідеальних з погляду економії витрат пам'яті,
1)оператори та операнди не повторюються; 2) всі операнди є або вхідними, або
вихідними параметрами; 3) для запису тексту програми досить двох операторів
(опису заголовка процедури-функції і присвоювання). Використаємо вираз (5.4)
для обсягу програми, за умови, що N1=n1=2 і N2=n2=n2*.
Рівень програми (в умовних одиницях) L = V*/ V (2 n2)/(n1 N2),
(5.6)
якщо n2*=2 .
Рівень мови =L V*,
(5.7)
Інтелектуальний зміст програми (в умовних одиницях)
I=L V (2 n2/n1 N2) (N1+N2) log2(n1+n2)
(5.8)
Робота з програмування (в умовних одиницях)
E = V / L = V2 / V*
(5.9)
Час на програмування (в умовних одиницях)
T = E/S,
(5.10)
абоТ (n1 N2 log2n (n1 log2n1+n2 log2n2))/(2 n2 S),
(5.11)
де S – число Страуда (5<S<20).

74.

Число Страуда S визначається як число «страудовських моментів» за секунду.
«Страудовський момент» – це час, необхідний людині для виконання
елементарного розрізнення об'єктів, подібно розрізненню кадрів фільму.
Страуд винайшов, що людина здатна розрізняти від 5 до 20 об'єктів за секунду.
Потенційний обсяг програми є мірою мінімально необхідного обсягу програми із
заданим словником. Потенційний обсяг не залежить від мови реалізації. При
перекладі програми з однієї мови на іншу потенційний обсяг не змінюється, але
дійсний обсяг V чи збільшується, чи зменшується залежно від мови реалізації.
Використовуючи вираз потенційного обсягу програми, отримані наступні метрики:
Рівень програми L 1 характеризує ефективність реалізації алгоритму щодо витрат
пам'яті. Тільки для найбільш компактної форми реалізації алгоритму (V=V*) рівень
програми дорівнює 1. Усім іншим варіантам реалізації відповідають значення L<1.
Рівень мови – це коефіцієнт пропорційності зміни обсягу програми при перекладі
з однієї мови на іншу так, що добуток рівня програми на потенційний обсяг
залишається незмінним. Інтелектуальний зміст програми характеризує міру
«сказаного» у програмі, чи її «інформативність». Інтелектуальний зміст (рівень)
програми корелює з потенційним обсягом (I V*) і не залежить від мови реалізації.
Робота з програмування (рівняння розумової роботи) характеризує величину
розумової роботи, зв'язаної із написанням програмного коду. Рівняння роботи дає
підставу для розбиття програми на складові частини – модулі. Модульність знижує
обсяг програмування. Найбільш продуктивною є ситуація, за якої для отримання
одного результату використовується не більше 5 об'єктів. У прикладному сенсі цей
результат називають гіпотезою про «6 об'єктів». Для визначення кількості модулів
M у програмі Холстед рекомендує використовувати вираз:

75.

M= n2*/6,
(5.12)
де n2* – загальна кількість вхідних і вихідних змінних у програмі.
З рівняння роботи отримаємо таке рівняння помилок:
B=L E / E0,
(5.13)
де В – кількість помилок у програмі, Е0 – середня кількість елементарних відмінностей між
помилками програмування.
Використовуючи перетворене рівняння роботи:
Е= (V*)3 / 2,
(5.14)
а також значення рівня англійської мови ( =2,16), як аналог мови програмування, і гіпотезу
про «шість об'єктів» ідеальної за витратами пам'яті програми (n1=n1*=2, n2=n2*=6),
Холстед вивів таке рівняння для прогнозу кількості помилок у програмі:
B= Е 2/3 /3000,
(5.15)
або B= V / 3000,
(5.16)
де V – обсяг програми (5.4).
Якщо розрахунки довжини програми і довжини реалізації відрізняються більш ніж на десять
відсотків, то це свідчить про можливу наявність у програмі таких 6 класів
недосконалостей:
1). Наявність послідовності операторів, що доповнюють один одного до того ж самого
операнда, наприклад, А+C–А. 2). Наявність неоднозначних операндів, наприклад, A=D і
A=С.
3). Наявність операндів-синонімів, наприклад, А=В и Т=В. 4). Наявність загальних підвиразів:
(А+B) C + D (А+B). 5). Непотрібне присвоювання, наприклад C=А+B, якщо змінна C
використовується в програмі тільки один раз.
6). Наявність виразів, що не подані в згорнутому вигляді як добуток множників, наприклад
X X+2 X Y+Y Y не подається як (X+Y) (X+Y).
Добуток рівня програми на обсяг є постійною величиною, що дорівнює потенційному обсягу
реалізації даного алгоритму: L V = V* = const.
Якщо мова не змінюється, а змінюється тільки алгоритм, то для будь-якої мови добуток
потенційного обсягу на рівень програми залишається сталою величиною і дорівнює рівню
мови: L V* = = const.

76.

77.

Метрика Маккейба
Метрика Маккейба ґрунтується на аналізі потоку передавання керування від одного
оператора до іншого. Це дозволяє, на відміну від метрик Холстеда, врахувати логіку
програми при оцінюванні її складності.
Програма (алгоритм, специфікація) має бути подана у вигляді управляючого
орієнтованого графу G = (V, Е) із V вершинами і E дугами, де вершини відповідають
операторам, а дуги – переходам від одного оператора до іншого.
Граф, що описує програму у вигляді вершин-операторів і дуг-переходів, називають
графом керування або управляючим графом програми.
Приклад.
main()
{ int zeich = 'x';
while(zeich != '#')
{ printf(" Продовжити введення ");
zeich = getchar();
}
printf("Введення завершене "); }
int zeich=”x”
v
while (zeich!=”#”)
a
printf (“Продовжити введення”)
u
b
b
c
zeich=getchar( )
printf (“Введення завершене”)

78.

Метрика Маккейба є цикломатичним числом графу передач керування програми і
визначається виразом:
M=m–n+2,
(5.17)
де m – кількість ребер графу; n – кількість вершин графу. Величину М,
розраховану за формулою (5.17), називають цикломатичним числом Маккейба.
Теоретичною базою визначення цикломатичного числа Маккейба є теорія графів.
У теорії графів цикломатичне число орієнтованого графа визначається виразом:
M = m – n + 2p
(5.18)
де m – кількість ребер; n – кількість вершин; p – кількість компонентів зв'язності графу.
Кількість компонентів зв'язності p можна розглядати як мінімально необхідну
кількість ребер, які потрібно додати до графу, щоб зробити його повнозв'язним.
Повнозв'язним вважають граф, у якого існує шлях з будь-якої вершини графу в
будь-яку іншу вершину графу. Для графів керування програм повнозв'язність забезпечується
додаванням однієї фіктивної дуги з кінцевої вершини в початкову, тобто у розглядуваному
прикладі із вершини u у вершину v. Тому вважаємо, що для будь-якого графу керування
програми кількість компонентів зв'язності дорівнює одиниці. Підстановка p=1 у формулу
(5.18) дає цикломатичне число Маккейба (5.17). Визначимо цикломатичне число Маккейба
для графу керування програми, зображеного на рисунку. Кількість ребер графу дорівнює
п'яти, кількість вершин теж дорівнює п'яти, тому цикломатичне число дорівнює:
M = 5 – 5 + 2 = 2.
Фізичний зміст цикломатического числа. Контур – це площина, обмежена циклічним
шляхом, у якій початкова і кінцева вершина графу збігаються. Кожному контуру
відповідає шлях, що обмежує його, який веде з початкової вершини графа в кінцеву.
Цикломатичне число визначає кількість незалежних контурів у повнозв'язному графі і, як
наслідок, кількість різних шляхів, що ведуть з початкової вершини в кінцеву. У
практичному аспекті цикломатичне число є мірою складності програми і визначає
кількість тестів, достатніх для тестування за критерієм покриття всіх гілок програми.

79.

Моделі якості ПС
Модель МакКола (1977). Три аспекта якості: функціональність, модифікованість, здатність до адаптації .
Аспекти поділяються на 11 факторів якості і далі на 23 критерія якості, які не обов’язково пов’язані
тільки з одним фактором якості (ієрархічно-мережева структура). Критерії формують цілі проекту. Третя
група характеристик якості - 20 метрик, на основі яких здійснюється кількісне оцінювання показників із
двох інших груп. Модель Боема (1978). Перша ієрархічна модель, на основі якої згодом була сформована
модель ISO/IEC 9126 (1991). Початкові рівні ієрархії схожі з МакКолом, але в моделі Боема модифікованість
і здатність до адаптації віднесені не до верхнього рівня моделі, а до проміжного та нижнього. По Боему
якість ПЗ складається з двох аспектів - функціональності (людський фактор, ефективність,
надійність, мобільність) і зручності експлуатації (оцінюваність, зрозумілість, модифікованість).
Наведені 7 характеристик якості пов’язані з 12 основними критеріями, які знаходяться рівнем нижче.
Більшість із критеріїв якості пов’язані один з одним, через що можуть виникати конфлікти та
неоднозначності при оцінці якості програмного продукту (ПП). Модель Ватса (1987) вдосконалює модель
МакКола, а Модель Дьюча і Вілліса (1988) задає 15 користувацьких та 27 технічних атрибутів якості,
які можуть пов’язуватися з факторами якості, або критеріями якості відповідно.
Модель ISO/IEC 9126 (1991) складається з 6 характеристик якості (функціональність, надійність,
ефективність, зручність використання, супроводжуваність, переносимість). Модель є строго
ієрархічною у відмінності від попередніх моделей. Недоліком моделі є те, що не всі підхарактеристики
якості можуть бути визначені чисельно. Це питання вирішено у стандарті ISO/IEC 9126 (2001) шляхом
впровадження відповідних множин внутрішніх та зовнішніх метрик.
Альтернативою класичним ієрархічним моделям є модель Джилба, яка теж базується на ієрархії
характеристик та підхарактеристик якості, але характеристики ресурсів проекту розробки також увійшли
у модель. Крім того, модель Джилба пов’язана з еволюційною моделлю розробки ПС. Характеристики
якості – працездатність, готовність, адаптованість і зручність використання, а ресурсів – час, гроші,
люди та інструменти. У 1996р. Дромей запропонував гнучку модель якості, яка дозволяє враховувати
особливості ПС, що розробляється. Це досягається за допомогою аналізу архітектури компонентів ПС
та властивостей тих компонентів, які впливають на атрибути якості кінцевого ПП. Встановлюється
зв’язок між атрибутами якості та властивосттями компонентів і оцінюється правильність моделі (слабкі
місця усуваються). Біля 2000р. Боєм запропонував своєрідну, але в наш час дуже популярну та корисну
модель COCOMO (COnstructive COst MOdel). Модель орієнтована на досягнення цілей якості у сполученнні
з оцінюванням вартості та трудозатратності виготовлення ПС і є дуже важливою як для аналітиків та
менеджерів, які керують проектом, так і для розробників ПП, дозволяючи визначити “ціну помилки”.

80.

Модель МакКола
Модифікованість
Перевірка
Супроводжуваність
Оцінюваність
Гнучкість
я
нн
ня
та ії
ен ть ис мод
дж іс кор ає
ва сим ви вз
ро но не до
Вп ере ор ть
П вт ніс
По ат
Зд
Ф
ун
кц
Н
і
Ко аді ону
ва
Еф ре йн
і
с
к
нн
Ц е т т
і
н
ь
к
л
я
Пр іс ти іс
т
ак ніс вн ь
ти ть іст
чн
ь
іс
ть
Здатність до адаптації
Функціональність

81.

Машинонезалежність
Модель Боема
Завершеність
Точність
Мобільність
Якість
функціональності
ЯкістьПЗ
Зручність
експлуатації
Узгодженість
Надійність
Раціональність
Ефективність
Доступність
Людські
фактори
Комунікативність
Оцінюваність
Структурованість
Зрозумілість
Інформативність
Зрозумілість
Модифікованість
Відкритість
Масштабованість

82.

Результати порівняльного аналізу моделей якості ПС
Для проведення порівняльного аналізу моделей якості ПС визначимо
категорії критеріїв. Моделі якості повинні містити сукупність характеристик
якості, набори метрик для проведення оцінювання реалізованих у ПС
властивостей та забезпечувати здатність до адаптації на стадіях ЖЦ.
Для досягнення задоволення користувацьких потреб розробники серійного ПС
використовують моделі якості FURPS (functionality, usability, realibility, perfomance,
service) та CUPRIMDSO (capability, usability, perfomance, realibility, installability,
maintainability, documentation / information, service, overall).
Структура моделі FURPS наслідувана з моделей МакКола та Боема. При цьому
здійснити комунікацію вимог якості та провести їх оцінювання складно, оскільки
необхідно враховувати пріоритетність атрибутів різних характеристик моделі
FURPS. Модель CUPRIMDSO є більш повною по відношенню до FURPS, оскільки
має ширший набір характеристик якості, що дозволяє точніше виявити рівень
задоволення реалізованих у ПС властивостей.
Спільним для цих двох моделей є те, що вони дозволяють виражати якість ПС як
з точки зору кінцевого користувача так і збоку самої ПС. Тому якість ПС, виходячи із
застосування цих моделей, можна поділити на три категорії: якість продукту;
внутрішня якість процесів; якість підтримки.
У результати аналізу і порівняння включимо і модель Дромея. Вона практично
не відрізняється від моделі якості стандарту ISO 9126, який був прийнятий в 1991р.
Перевагою цієї моделі є те, що її використання дозволяє контролювати якість
програмного продукту на етапах ЖЦ. Однак характеристики якості моделі Дромея є
не уніфікованими, не стандартизованими і не набули широкого застосування.

83.

Моделі
ISO 9126
+/-
+
+
+
+
+
+
-
-
+
-
+
-
-
+
-
+
+
-
-
-
-
-
+
-
-
+
+
+
+
+/-
+/-
+
+
+
+
-
-
+
+
+
+
Модель
МакКола
Модель
Боема
Модель
FURPS
Повнота
визначення
характеристик якості
+/-
+/-
+/-
Наявність
метрик
для
кількісного вираження
якості
-
+
Формалізованість
узгодженість
стандартами
-
та
із
Здатність до трансформації
Можливість
комунікації
вимог на стадіях ЖЦ
Ідентифікація
якості
вимог
Структурованість
адаптація
предметної області
до
та
до
Ідентифікація цілей проекту
Модель
CUPRI
MDSO
Модель
Дромея
Вимоги до моделей

84.

Розробка стандартів здійснюється міжнародними й
національними органами стандартизації:
ISO – International Standard Organization
IEC – International Electrotechnical Commission
EOQ – European Organization for Quality
WSSN – World Standards Services Network
ANSI – American National Standards Institute
BSI – British Standards Institution
IEEE – Institute of Electrical and Electronics
Engineering
NASA – National Aeronautics Space Administration
NIST – National Institute of Standards and Technology
SCC – Standards Council of Canada
ДСТУ – Державний комітет по стандартизації,
метрології та сертифікації України
ГОСТ – Государственный комитет РФ по
стандартизации и метрологии

85.

Міжнародні стандарти в області інформаційних технологій (IT) розробляються
об’єднаним технічним комітетом JTC1 (Joint Тechnical Committee №1)
“Information Technology”, заснованим ISO та IEC. Він включає 36 підкомітетів SC
(SubCommittie), а за розробку міжнародних стандартів по програмній інженерії
(Software Engineering – SE) відповідає робочий підкомітет ISO/IEC SC7 “Software
and System Engineering”. Для роботи над проектами стандартів у підкомітеті SC7
створені робочі групи (WG, Working Group).
Базовими стандартами по керуванню якістю продукту і системах управління якістю
ОР є міжнародні стандарти серії ISO 9000. Стандарт ISO 9000-3 регламентує
управління якістю під час розробки, поставки та супроводу ПЗ.
Базові стандарти по керуванню якістю ПЗ
ДСТУ ISO 9000-3 – Стандарти з управління якістю та забезпечення якості.
Частина 3. Настанови щодо застосування ДСТУ ISO 9001-95 під час розроблення,
постачання та супроводження програмних засобів.
Основні діючі стандарти в області інженерії якості
ДСТУ ISO 9000-2001. Системи управління якістю. Основні положення та словник.
ДСТУ ISO 9001-2001. Системи управління якістю. Вимоги.
ДСТУ ISO 9004-2001. Системи управління якістю. Настанови щодо поліпшення діяльності.
ГОСТ 34.602-89. Информационная технология – Комплекс стандартов на АС. Техническое
задание на создание автоматизированой системы.
ГОСТ РФ 28195-89. Оценка качества программных средств. Общие положения.

86.

Основні діючі стандарти в області інженерії якості (продовження)
ISO/IEC 12119 (1994) – IT – Пакети програм, вимоги до якості й тестування.
ISO/IEC 12207 (1995) – IT – Software life cycle processes.
Група стандартів з оцінки ПП – ISO/IEC 14598 :
14598-1 (1999) – IT – Оцінка продукту – Частина 1. Загальний огляд.
14598-2 (2000) – SE – Оцінка продукту – Частина 2. Планування й керування.
14598-3 (2000) – SE – Оцінка продукту – Частина 3. Процес для розробників.
14598-4 (2000) – SE – Оцінка продукту – Частина 4. Процес для замовників.
14598-5 (1999) – IT – Оцінка продукту – Частина 5. Процес для оцінювачів.
14598-6 (1999) – IT – Оцінка продукту – Частина 6. Документація модулів оцінювання.
ISO/IEC 14764 (1999) – IT – Software maintenance.
ISO/IEC 9126-1 (2001) Software engineering – Product quality – Part 1: Quality model.
ISO/IEC TR 9126-2 (2003) Software engineering – Product quality – Part 2: External metrics.
ISO/IEC TR 9126-3 (2003) Software engineering – Product quality – Part 3: Internal metrics.
ISO/IEC TR 9126-4 (2004) Software engineering – Product quality – Part 4: Quality in use metrics.
IEEE std. 610.12 (1990) – Глосарій термінології по програмній інженерії.
IEEE std. 12207.0 (1996) – Процеси ЖЦ ПЗ.
IEEE std. 12207.1 (1997) – Дані ЖЦ ПЗ.
IEEE std. 730 (1998) – Плани забезпечення гарантії якості ПЗ (підходи відповідно до SQA).
IEEE std. 830 (1993) – Recommended Practice for Software Requirements Specifications.
NASA std. 8719.13A (1997). Безпека фукціонування ПЗ.
ДСТУ 2844 (1994). Програмні засоби ЕОМ. Забезпечення якості. Терміни та визначення.
ДСТУ 2850 (1994). Програмні засоби ЕОМ. Показники та методи оцінювання якості.
ДСТУ 2851 (1994). Програмні засоби ЕОМ. Документування результатів випробовувань.
ДСТУ 2853 (1994). Програмні засоби ЕОМ. Підготовка та проведення випробувань.
ДСТУ 2462 (1994). Сертифікація. Основні поняття. Терміни та визначення.
ДСТУ 3918 (1999) – Інформаційні технології. Процеси ЖЦ ПЗ.

87.

Група стандартів SPICE - Software Process Improvement and Capability
dEtermination – WG10 “Оцінювання процесу” – “Process Assessment”
ДСТУ ISO/IEC 15504-1:2002. Інформаційні технології – Оцінювання процесів
життєвого циклу програмних засобів. Частина 1. Концепції та вступна настанова.
ДСТУ ISO/IEC 15504-2:2002. Інформаційні технології – Оцінювання процесів
життєвого циклу програмних засобів. Частина 2. Еталонна модель процесів та
потужності процесу.
ДСТУ ISO/IEC 15504-3:2002. Інформаційні технології – Оцінювання процесів
життєвого циклу програмних засобів. Частина 3. Виконання оцінювання.
ДСТУ ISO/IEC 15504-4:2002. Інформаційні технології – Оцінювання процесів
життєвого циклу програмних засобів. Частина 4. Настанови з виконання оцінювання.
ДСТУ ISO/IEC 15504-5:2002. Інформаційні технології – Оцінювання процесів
життєвого циклу програмних засобів. Частина 5. Модель оцінювання та настанови
щодо показників.
ДСТУ ISO/IEC 15504-6:2003. Інформаційні технології – Оцінювання процесів
життєвого циклу програмних засобів. Частина 6. Настанови з визначення компетенції
оцінювачів.
ДСТУ ISO/IEC 15504-7:2003. Інформаційні технології – Оцінювання процесів
життєвого циклу програмних засобів. Частина 7. Настанови з удосконалення
процесу.
ДСТУ ISO/IEC 15504-8:2003. Інформаційні технології – Оцінювання процесів
життєвого циклу програмних засобів. Частина 8. Настанови з визначання потужності
процесу постачальника.
ДСТУ ISO/IEC 15504-9:2003. Інформаційні технології – Оцінювання процесів
життєвого циклу програмних засобів. Частина 9. Словник термінів.

88.

Робочі групи підкомітету SC7 “Software and System Engineering”
WG2: Документація системних ПП;
WG4: Інструменти і CASE-засоби;
WG6: Оцінювання ПП і метрики;
WG7: Управління життєвим циклом;
WG8: Підтримка процесів ЖЦ;
WG9: Забезпечення гарантій і цілісність ПЗ;
WG10: Оцінювання і контроль процесів ЖЦ;
WG11: Подання й визначення даних в інженерії ПЗ;
WG12: Функціональні вимірювання ПЗ;
WG19: Мови моделювання, метадані, схема та компоненти відкритої
розподіленої обробки;
WG20: Ядро знань в області програмної інженерії;
WG21: Процес управління наробітками в галузі ПЗ;
WG23: Управління якістю систем;
WG24: Життєві цикли ПЗ для малих підприємств.

89.

SQuaRE (Software Quality Requirements and Evaluation) ISO/IEC9126 + ISO/IEC14598. SQuaRE містить 5 груп стандартів:
2500n – Управління якістю ПП:
огляд, структура і довідник по SQuaRE (25000);
планування й керування оцінкою якості продукту.
2501n – Модель якості:
модель якості ПЗ (25010);
модель якості даних (структури даних ПС, БД) (25012);
вказівки по застосуванню моделей якості.
2502n – Вимірювання якості:
еталонна модель вимірювання й вказівки по застосуванню;
базові і похідні метрики якості (примітиви вимірювання);
внутрішні метрики якості;
зовнішні метрики якості;
метрики якості у використанні;
2503n – Вимоги до якості:
вимоги до якості ПЗ;
вказівки по визначенню якості.
2504n – Оцінювання якості продукту:
огляд процесів оцінювання;
процес для розробників;
процес для споживачів (замовників);
процес для оцінювачів.
документування модулів оцінювання.

90.

Архітектура стандартів SQuaRE
2501n
( 9126-2n )
Розділ: Модель якості
2500n
(
9126-1n )
Управління якістю ПП
Загальний розділ
2503n
( 9126-4n )
2504n
( 9126-5n )
Розділ:
Вимоги до якості
Загальний огляд і
Керівництво по SQuaRE
Планування і управління
2502n
( 9126-3n )
Розділ: Вимірювання якості
(застосування метрик якості)
Розділ:
Оцінювання якості

91.

Зв’язок між поточними стандартами і SQuaRE
Поточні розділи
SQuaRE
9126 : Якість продукту
2500n: Управління якістю
-1 Модель якості
0:Загальний огляд і керівництво
-2 Зовнішні метрики
1: Планування і управління
-3 Внутрішні метрики
2501n: Модель якості
-4 Якість у використанні
0:Модель якості і керівництво
2502n: Вимірювання якості
Нові пропозиції
0 : Загальні вимоги і керівництво
Керівництво по використанню 9126&14598
1: Базові метрики
Основні метрики (модель)
2: Внутрішні метрики
Вимоги до якості
3: Зовнішні метрики
4: Метрики якості у використанні
14598 : Оцінювання продукту
5: Документація модулів оцінки
-1 Загальний огляд
2503n: Вимоги до якості
-2 Планування і управління
0: Вимоги до якості і керівництво
-3 Процес для Розробників
2504n: Оцінювання якості
-4 Процес для Покупців
-5 Процес для Оцінювачів
0: Огляд оцінки якості і
керівництво
1: Процес для Розробників
-6 Документація модулів оцінки
2: Процес для Споживачів
3: Процес для Оцінювачів

92.

Оцінювання якості програмних продуктів
Якість ПП оцінюється на основі моделі якості, методу оцінювання і метрик.
Оцінювання якості неможливе, якщо невідомі вимоги користувача до якості
(критерії якості) або не визначений процес вимірювання продуктів, процесів і
ресурсів. Процес оцінювання якості продуктів є одним із процесів ЖЦ, визначених у
стандарті ISO 12207. Мета: “гарантувати шляхом систематичного вимірювання й
оцінювання, що продукт задовольняє встановленим і передбачуваним вимогам
користувачів до цього продукту”. У результаті успішного виконання процесу будуть:
- встановлені вимоги, що стосуються проведення оцінювання;
- визначені критерії оцінки продукту;
- специфіковані методи виконання оцінювання;
- дані вимірювань будуть збиратися, а результати застосування метрик
оцінюватися стосовно критеріїв;
- результати діяльності по оцінюванню продукту будуть доступні для всіх
зацікавлених сторін.
Оцінювання якості кінцевого продукту виконується для:
- ухвалення рішення про приймання продукту;
- ухвалення рішення про строки випуску продукту;
- порівняння продукту з іншими продуктами;
- вибору продукту з множини альтернативних продуктів;
- оцінка як позитивного, так і негативного результату використання продукту.
Процес оцінки продуктів ПЗ проводиться у відповідності зі стандартом ISO 14598.
Процес оцінювання виконується у вигляді покрокової процедури з використанням
узагальненої моделі якості, визначеної в стандартах ISO/IEC 9126.

93.

Оцінювання якості програмних продуктів
Формування цілей оцінювання
Формування
вимог до
оцінювання
Ідентифікація видів продуктів
Специфікація моделі якості
Вибір метрик
Специфікація
оцінювання
Установка рівнів
ранжирування метрик
Установка критеріїв оцінювання
Проектування
оцінювання
Розробка плану оцінювання
Вимірювання характеристик
Виконання
оцінювання
Порівнювання з критерієм
Оцінка результатів
ISO 9126.1
Характеристики якості
ISO 9126.2 Зовнішні метрики
ISO 9126.3 Внутрішні метрики
ISO14598.6 Модулі оцінювання

94.

Пріоритети характеристик з урахуванням рівня цілісності ПЗ
Рівень
цілісності
Характеристики якості
Найбільш
важлива підхарактеристика
Обрана зовнішня метрика
1.Функціональність
Точність
Число
отриманих
точних
результатів
у
%
від
очікуваного їх числа
2. Зручність використання
3. Переносимість
Керованість
Настроюваність
Число ясних повідомлень у %
від
загального
числа
переглянутих повідомлень
Число модулів, що підлягають
повторній
компіляції,
з
урахуванням загального числа
модулів, що переносяться на
нову платформу
Можливий
критерій
приймання
95%
80%
< 6 модулів
Низький
4. Ефективність
5. Надійність
6. Супровід
Реактивність
Стійкість до відмов
Не потрібно
Проміжок часу від посилки
запиту до одержання відповіді
системи
Число відмов, що відбулися
через помилку у вхідних
даних, у % від загального
числа запусків системи з
введенням
неправильних
даних
Не потрібно
< 5сек
25%
-

95.

1. Надійність
2.Функціональність
3. Супровід
Високий
4. Ефективність
5. Зручність використання
6. Переносимість
Завершеність
Середній час між
відмовами в період
експлуатації
Функціональна повнота
Число реалізованих
обов'язкових
функціональних вимог у
% до загального числа
специфікованих
функціональних вимог
Модернізація
Використовува-ність
ресурсів
Зрозумілість
Не потрібно
Число модулів, що
підлягають зміні при
можливих змінах ПЗ
%
Час
зайнятості
CPU
у
визначений
період
роботи
системи
розраховуючи
на
найгірші
операційні
умови
необхідний визначеній
категорії користувачів на
те, щоб зрозуміти, яким
чином використовувати
ПЗ,
щоб
досягти
потрібних результатів
Не потрібно
> 6 місяців
100%
1
80%
< 10 хвилин
-

96.

Оцінювання програмних продуктів
Процес оцінки ПП проводиться у відповідності зі стандартами ISO14598 [1-6].
Процес оцінювання виконується як покрокова процедура з використанням
узагальненої моделі якості стандартів ISO/IEC 9126 [1-4].
Загальна схема оцінки продуктів (структура процесу) зберігається, однак існують
особливості виконання дій у процесі оцінювання окремими категоріями
виконавців. Вони пов'язані з різними цілями оцінювання, видами оцінюваних
продуктів, критеріями, метриками. Оцінювання продуктів розробниками,
замовниками, споживачами продуктів і незалежними оцінювачами здійснюється
відповідно до вимог, які містяться в окремих частинах стандарту ISO/IEC 14598.
Рівні оцінювання (від A до D) з урахуванням ризиків в сфері безпеки
функціонування, захисту інформації, економіки, середовища функціонування).
Оцінювання процесів ЖЦ ПП
Оцінювання процесів ЖЦ необхідне для того, щоб: 1) оцінити стан процесів
розробки з метою їх подальшого вдосконалення; 2) встановити відповідність
власних процесів організації певним вимогам. Оцінювання регламентується
стандартом ISO/IEC 15504, який пропонує двоетапну модель оцінювання. На 1му етапі встановлюється відповідність оцінюваного процесу певним вимогам,
зафіксованим в еталонній моделі цього процесу, а на 2-му визначається,
наскільки точно він організований, стійкий і керований. Еталонні процеси ЖЦ
визначені у стандарті ISO/IEC 12207. Кожен процес в еталонній моделі
описується у вигляді формулювання цілі (призначення) процесу й переліку
тверджень, що констатують відмінні риси успішно здійснюваного процесу. По
тому, чи володіє процес цими особливостями, судять про те, чи виконує процес

97.

рівень 0. Незавершений процес. Відбувається провал при виконанні процесу або збій у досягненні його
цілей – немає(мало) робочих продуктів або результатів процесу,які свідчать про те,що процес виконується.
рівень 1. Виконуваний процес. Призначення процесу в цілому досягається. Співробітники організації
визнають, що діяльність (відповідну призначенню процесу) потрібно здійснювати. Існує загальна
домовленість про те, що ця діяльність здійснюється так, як потрібно, і тоді, коли потрібно. Робочі продукти
процесу ідентифіковані, і по них можна судити про досягнення його цілей. Результати процесу можуть не
бути заздалегідь строго заплановані.
рівень 2. Керований процес. Робочі продукти виробляються відповідно до встановлених процедур.
Процес планується й контролюється. Робочі продукти погоджені з певними стандартами й вимогами.
Основна відмінність від рівня виконуваного процесу полягає в тому, що хід процесу тепер приводить до
випуску робочих продуктів, що повністю відповідають вимогам до якості в межах заданих строків і ресурсів.
рівень 3. Сталий процес. Існує базове визначення процесу, розроблене з урахуванням провідних
принципів і передової практики програмної інженерії, що забезпечує досягнення гарних результатів при
його належному використанні. Базовий процес інституалізуеться (впроваджується) в організації. Далі він
адаптується до умов певного проекту («настроюється» на конкретні робочі продукти, строки і т.д.). Для
реалізації адаптованого процесу виділяються всі необхідні ресурси. Основна відмінність від рівня
керованого процесу -> процес на рівні сталого процесу використовує базовий процес як такий, котрий
дійсно здатний досягти результатів, властивих базовому процесу, і є гарантією досягнення результатів.
рівень 4. Передбачуваний процес. Виконання процесу на практиці відбувається в умовах постійного
кількісного контролю досягнення цілей базового процесу. Продукти й ресурси процесу детально
вимірюються, а результати вимірювань збираються й аналізуються. Це дозволяє ефективно керувати
процесом, передбачати його стан в ході ЖЦ, а також оцінювати якість продуктів у кількісному обчисленні.
Основна відмінність від сталого процесу полягає в тому, що адаптований процес виконується постійно й
завжди можна завбачити, на якому етапі він буде перебувати в певний момент часу.
рівень 5. Процес, що оптимізується. Виконання процесу оптимізується відповідно до поточних й
майбутніх виробничих цілей організації. Існують кількісні цільові показники економічної ефективності й
продуктивності виконання процесу. Встановлено зворотний зв'язок у процесі -> здійснюється постійний
моніторинг відповідності процесу цілям організації і його поліпшення. Процес, що оптимізується припускає
вирішення завдань апробації нових технологій і модернізації неефективних дій для досягнення певних
цілей. Основна відмінність від передбачуваного процесу -> не тільки діючий адаптований процес, але й
базовий процес динамічно змінюються й поліпшуються з метою ефективного досягнення виробничих цілей.

98.

В ISO/IEC 15504 виділені 9 атрибутів потужності процесу на 6 рівнях зрілості процесу. Атрибути потужності процесу :
Рівень
потужності
(зрілості)
1. Виконуваний
процес
Атрибут
Визначення атрибута
АП 1.1
Виконуваність
процесу
Ступінь, у якому процес досягає результатів шляхом перетворення ідентифікованих вхідних
робочих продуктів на ідентифіковані вихідні робочі продукти.
АП 2.1
Керованість
2. Керований
процес
3. Сталий
процес
4.
Передбачуваний
процес
Ступінь, у якому виконання процесу направляється на виробіток робочих продуктів, що
відповідають установленим цільовим показникам процесу (параметрам управління).
виконанням
АП 2.2
Керованість
робочими
продуктами
Ступінь, у якому виконання процесу направляється на створення таких робочих продуктів, які належним
чином документовані й верифіковані.
АП 3.1
Визначеність
Ступінь, у якому виконання процесу використовує визначення процесу (засноване на базовому) для
досягнення результатів процесу.
АП 3.2
Використовуваніс
ть
ресурсів
Ступінь, в якому процес використовує ресурси, що є в наявності (наприклад, трудові ресурси й
інфраструктуру процесу), виділені для розгортання процесу.
АП 4.1
Вимірність
Ступінь, у якому цілі й міри продукту й процесу використовуються для того, щоб гарантувати, що
виконання процесу сприяє досягненню поставлених перед ним цілей.
АП 4.2
Контрольованість
Ступінь, у якому процес контролюється (завдяки збору, аналізу й використанню мір продукту й процесу),
що забезпечує коригування його виконання для досягнення певних цілей (щодо продукту й процесу).
виконання
АП 5.1
Контрольованість
5. Процес, що
ідентифікується
Ступінь, у якому зміни у визначенні, керуванні й виконанні процесу перебувають під постійним контролем
у контексті досягнення відповідних виробничих цілей організації.
модифікації
АП 5.2
Безперервність
удосконалення
Ступінь, у якому зміни в процесі ідентифікуються й впроваджуються таким чином, що є гарантія
безперервного вдосконалення, яке сприяє досягненню відповідних виробничих цілей організації.

99.

Еталонна шкала рейтингів атрибутів процесу
Не
досягнутий
Частково досягнутий
Істотно досягнутий
Повністю
досягнутий
(Н)
(Ч)
(І)
(П)
0%-15%
50%
85%
100%
Сумісна модель оцінювання
Оцінювання процесів повинне проводитися з урахуванням певного контексту
оцінювання (для одних цілей процеси можуть бути придатні, для інших – ні).
1) Сумісна модель повинна охоплювати принаймні ті процеси, які потрібно
оцінювати (один або декілька).
2) В моделі повинні бути докладно описані конкретні практичні прийоми, які
забезпечують досягнення призначення процесу й зазначених в еталонній моделі
результатів процесу. Вони називаються базовими практичними прийомами.
3) Повинні бути чітко визначені робочі продукти, які існують на вході процесу
або з'являються на його виході.
4) В описі кожного робочого продукта повинні вказуватися характеристики, по
яких можна буде його оцінювати.
5) В сумісній моделі повинні бути уточнені описи атрибутів процесу, що
задовольняють наступним вимогам :
- Повинні бути зазначені конкретні практичні прийоми керування процесом.
Для кожного прийому керування повинні вказуватися характеристики його
виконання (по яких можна судити про наявність управління), характеристики
ресурсів і інфраструктури (застосовувані методи, інструменти), а також ті процеси,
з якими може асоціюватися даний прийом керування.

100.

Сумісна модель оцінювання
ВИМІРЮВАННЯ
ПРОЦЕСУ
Процес
Рівень 1: Виконання процесу
- Чи вносять вклад у досягнення
мети процесу ?
- Чи існують ?
Чи адекватні ?
Показники виконання процесу:
Рівні з 2 по 5: Потужність процесу
- Базові практичні прийоми
- Робочі продукти
- Чи свідчать про потужність
процесу ?
- Характеристики робочих
продуктів
- Чи демонструють досягнення
атрибутів процесу ?
ВИМІРЮВАННЯ
ПОТУЖНОСТІ
Рівні потужності та
атрибути процесу
Індикатори потужності
процесу:
- Практичні прийоми
керівництва
- Характеристики здійснення
прийомів
- Характеристики
ресурсів/інфраструктури

101.

Сертифікація – це процедура перевірки відповідності ПС вимогам
замовника, розробника, стандартів з якості ПЗ і галузевих стандартів.
Основні визначення і поняття в області сертифікації ПЗ викладені
в стандарті: ДСТУ 2462 (1994). Сертифікація. Основні поняття. Терміни та
визначення.
Сертифікація – це оцінка відповідності властивостей ПС вимогам.
Для проведення сертифікаційних випробувань використовуються
лабораторії сертифікації, які призначаються органом сертифікації.
Сертифікація відповідності означає дії третьої сторони
(органа сертифікації та випробувальної лабораторії), спрямовані на
підтвердження того, що ПЗ відповідає встановленим вимогам стандартів та інших
нормативних документів. Випробувальна лабораторія проводить тестування ПС.
УКРМЕТРТЕСТСТАНДАРТ => УКРСЕПРО
лабораторія
сертифікації
орган
сертифікації
SoftRating
УКРСЕПРО
УКРСЕРТСОФТ

102.

Сертифікація ПЗ виконується акредитованими незалежними органами
сертифікації. Вона покликана підтвердити, що продукція, яка випускається,
відповідає нормативним документам і вимогам замовника. Результат
сертифікації оформляється у вигляді сертифіката.
Сертифікація може бути обов’язковою й добровільною. Обов’язкова
сертифікація застосовується до ПЗ, а також до систем якості організаціїрозробника, що задіяні при розробці критичних ПС, тобто ПС, пов’язаних із
безпекою життєдіяльності. Необхідність обов’язкової сертифікації визначається
замовником ПС, а в інших випадках рекомендується добровільна сертифікація.
В області сертифікації систем якості, а також продукції й послуг, працює
державна система сертифікації продукції УкрСЕПРО. Вона поєднує біля 150
акредитованих органів сертифікації, а також більше 800 виконавчих
випробувальних (сертифікаційних) лабораторій. Сертифікація систем якості
організацій-розробників ПЗ регламентована в стандарті ДСТУ 3419 – Система
сертифікації УкрСЕПРО–Сертифікація систем якості– Порядок проведення.
Останнім часом нова державна організація взяла на себе основні дії по
стандартизації та сертифікації продуктів та послуг. Цією організацією став
Укрметртестстандарт. Однією із базових організацій по сертифікації ПЗ, яка
має також випробувальну лабораторію, є Софт-Рейтинг (SoftRating).
Лабораторія сертифікації (випробувальна лабораторія) проводить
випробування (в тому числі – сертифікаційні, атестаційні та ін.), а орган
сертифікації займається висновками та прийняттям рішення і, в остаточному
підсумку, видачею сертифікатів відповідності. Сертифікат відповідності
видається УКРСЕРТСОФТ (орган сертифікації, з яким співпрацює Софт-Рейтинг)
на період 1, 2 або 3 роки, залежно від обраної схеми сертифікації.
Обов’язки, діяльність та вимоги до компетенції випробувальних лабораторій
викладені в стандарті ІSО/ІЕС 17025 – General requirements for the competence
of testing and calibration laboratories.

103.

Методологія СММ
В інженерії якості широко використовується сімейство моделей зрілості CMM
(Capability Maturity Models), з числа яких розглянемо модель SW-CMM (CMM for
SoftWare – модель зрілості процесу розробки ПП). Модель СММ може
використовуватися для оцінювання й удосконалювання процесу програмної
інженерії в організації (тому її називають моделлю зрілості чи досконалості
організації, а не окремих процесів ЖЦ). Модель виділяє й дає строгий опис 18
ключових напрямків (областей, ділянок) процесу – КРА (Key Process Areas)
програмної інженерії (схожих із підтримуючими й організаційними процесами ЖЦ в
ISO/IEC 15504). Області «розподілені» по рівнях зрілості від 2 до 5).
Результат оцінювання експертами досягнення ОР певного рівня – сертифікат
рівня зрілості й/або рекомендації з подальшого вдосконалювання процесу.
КРА згруповані по рівнях зрілості так, що кожний КРА завжди стосується тільки
одного рівня СММ. Кожний рівень зрілості крім 1-го може бути декомпозований на
складові частини. Кожен напрямок представлений п'ятьма розділами, причому
кожний розділ визначає перелік рекомендованих практичних дій (процедур).
При виконанні рекомендованих дій досягаються цілі, які є пріоритетними для
відповідного ключового напрямку процесу. Розділ КРА стосується одного аспекту
проблем, пов'язаних із виконанням відповідної ділянки процесу.
У СММ виділені наступні п'ять розділів КРА :
адміністративні міри. Дії, які повинна розпочати ОР, щоб забезпечити пуск
процесу і його стабільність. Адміністративні міри звичайно стосуються формування
політики й забезпечення фінансової підтримки;

104.

Рівні зрілості в моделі СММ

105.

необхідні передумови. У цьому розділі описані умови, які повинні бути створені в
рамках ОР для забезпечення готовності процесу (необхідні ресурси, організаційні
структури й система навчання);
• виконувані процедури. У цьому розділі описані правила й процедури, яких необхідно
дотримуватися для успішної реалізації відповідної ділянки процесу. До таких процедур
відносять розробку планів і процедур, виконання технологічних операцій, а також дії по
перевірці і необхідному коригуванню;
• вимірювання і аналіз. Описані вимоги до проведення вимірів у ході процесу й аналізу
отриманих результатів вимірів, а також наведені приклади даних, які зазвичай
збираються (показників), що необхідні для визначення стану й ефективності процесу.
Ключові процедури розділу описують основні прийоми вимірів, що необхідні для
визначення стану робіт по ключових процедурах, які представлені у розділі «виконувані
процедури». Запропоновані метрики наводяться як додаткова інформація, бо в різних
середовищах проектів можуть потребуватися різні метрики й підходи до вимірювання;
• проведення перевірки. У розділі описані заходи, що вживаються для перевірки
відповідності виконуваних дій вимогам існуючого процесу. До методів перевірки зазвичай
відносять огляди й аудиторські перевірки (ревізії) у ході управління й забезпечення
гарантій якості ПЗ. У цей розділ входять ключові процедури, що стосуються контролю з
боку керівництва організації й керівництва проекту, а також будь-яких дій по перевірці
належного виконання ключових процедур з боку групи якості або інших груп.
На базі СММ SEI (Software Engineering Institute) розробив 2 методи оцінювання
зрілості процесу:
метод SPA (від Software Process Assessment) – оцінювання поточного стану процесу.
Використовується для дослідження процесу програмної інженерії в організації,
визначення його поточного стану, виявлення існуючих проблем, вибору
високопріорітетних цілей поліпшення процесу розробки, вироблення відповідної
стратегії поліпшення й одержання підтримки з боку керівництва;
метод SCE (Software Capability Evaluation) – оцінка спроможностей бюджету організаціїрозробника ПЗ. Може використовуватися при визначенні потенційних організаційвиконавців програмних проектів або для управління ефективністю процесу в організаціяхвиконавцях , що мають в своєму розпорядженні певні ресурси розробки.

106.

Структура рівнів зрілості в моделі СММ

107.

Складові надійності програмних систем
Функціональна
надійність
Працездатність
Безвідмовність
Безпека
Здатність системи
виконувати необхідну
роботу
Здатність системи
виконувати роботу так, як
перебачено за
призначенням
Здатність системи
функціонувати без
катострофічних наслідків
Захищеність
Здатність системи
захистити себе без
випадкових або навмисних
вторгнень
При оценивании надежности =>
Дефект (fault) в ПС – это последствие использования элемента программы, который может
привести к некоторому событию, например, в результате неверной интерпретации этого элемента
компьютером (как ошибка (fault) в программе) или человеком (ошибке (error) исполнителя). Дефект
является следствием ошибок разработчика на любом из процессов разработки – в описании
спецификаций требований, проектных спецификациях, эксплуатационной документации. Дефекты,
не выявленные в результате проверок, являются источником потенциальных ошибок и отказов
ПС. Проявление дефекта в виде отказа зависит от того, какой путь будет выполняться, чтобы найти
ошибку в коде или во входных данных. Не каждый дефект может вызвать отказ или связан с
дефектом в ПС. Любой отказ может вызвать аномалию от проявления внешних ошибок и дефектов.

108.

Общие определения =>
• Ошибка (error) – состояние программы, при котором выдается неправильные
результаты, причиной которых являются изъяны (flaw) в операторах программы или в
технологическом процессе ее разработки, что приводит к неправильной интерпретации
исходной информации, а следовательно и к неверному решению.
• Дефект (fault) в программе является следствием ошибок разработчика на любом из
этапов разработки и может содержаться в исходных или проектных спецификациях,
текстах кодов программ, эксплуатационной документация и т.п. Дефект обнаруживается
в процессе выполнения программы.
• Отказ (failure) – это отклонение программы от функционирования или невозможность
программы выполнять функции, определенные требованиями и ограничениями и
рассматривается как событие, способствующее переходу программы в
неработоспособное состояние из–за ошибок, скрытых в ней дефектов или сбоев в среде
функционирования.
• Отказ может быть результатом следующих причин: ошибочная спецификация или
пропущенное требование (спецификация не отражает требование пользователя);
спецификация может содержать требование, которое невозможно выполнить на данной
аппаратуре и программном обеспечении; проект программы содержит ошибки (пример БД спроектирована без защиты от несанкционированного доступа, а требуется защита);
программа может быть неправильной, т.е. она выполняет несвойственный алгоритм или
он сделан не полностью и т.д.
При оценивании надежности =>
• Ошибка (error) может быть следствием недостатка в одном из процессов разработки
ПС, который приводит к неправильной интерпретации промежуточной информации,
заданной разработчиком или при принятии им неверных решений.
• Отказ ПC (failure) – это переход ПС из работающего состояния в нерабочее или когда
получаются результаты, которые не соответствуют заданным допустимым значениям.
Отказ может быть вызван внешними факторами (изменениями элементов среды
эксплуатации) и внутренними – дефектами в самой ПС. Интенсивность отказов это
частота появления отказов или дефектов в ПС при ее тестировании или эксплуатации.

109.

Тестування програм і систем
Порядок тестування
Вимоги
(11) Прийомоздавальні тести
Документи
(10) Інсталяційні тести
Архітектура
(9) Тести зручності та простоти
використання
Документи
Документи
Детальний проект
(8) Системні тести
Документи
Специфікація
інтерфейсів
(7) Регресійні тести
Документи
(6) Інтегральні тести
Код функцій
Код +
Код модуля (наприклад,
пакета)
Код +
Код +
Код +
Код ітерації чи системи
(5) Тести інтерфейсів
(2), (4) Модульні тести
(1), (3) Тести функцій
Завершений код
Огляд тестування: потік артефактів

110.

Тестування – невід'ємна складова процесу програмної інженерії, один
з методів подальшого поліпшення якості розробленої ПС за допомогою
виявлення дефектів, що залишилися, не виявлених раніше всіма
іншими видами перевірок.
Тестування – це спеціальним образом організована процедура, що
призначена для виявлення помилок у ПС, а не для демонстрації їхньої
відсутності (Г.Майерс).
Тестування дозволяє знайти помилки в програмах і програмних
комплексах. У випадку відсутності помилок на множині припустимих
даних, ПЗ визнається працездатним.
Тестування є одним із самих трудомістких етапів створення
програмного забезпечення. Витрати на проведення тестування
складають не менш 30% загальної вартості виготовлення ПЗ.
Слушним є наступне твердження: імовірність наявності невиявлених
помилок або дефектів у деякій частині програми пропорційна числу
помилок уже виявлених у цій частині, тобто помилки розташовуються в
програмах скупченнями.
Термін testing (тестування) широко використовується, але
визначається по-різному. Стандарт ANSI/IEEE Std. 610.12:1990
визначає термін testing в самому його широкому сенсі як будь-які дії з
аналізу ПП (включаючи методи як динамічної, так і статичної
перевірки). Слово testing може бути переведене не лише як
тестування, але і як випробування (ДСТУ 2844-94, ДСТУ 2853-94).
Але поняття «випробування» звичніше пов'язувати з тими процесами,
що завершують стадії ЖЦ, і на яких виконується не пошук помилок, а
підтвердження придатності розробленого ПП (програмного продукту).

111.

Тестування будемо розглядати як процес виконання ПС з метою перевірки
її відповідності встановленим вимогам і виявлення дефектів.
У міру розвитку програмної інженерії розуміння цілей і завдань тестування
змінювалося. Виділяють наступні «історичні» періоди, що відображають
прогрес в розумінні цілей тестування і його місця в життєвому циклі ПС:
період до 1956 року - орієнтація на налагодження;
період з 1957 по 1978 років - орієнтація на встановлення відповідності ПС
початковим вимогам;
період з 1979 по 1982 років - орієнтація на виявлення дефектів, що
залишилися після реалізації ПС;
період з 1983 по 1987 років - орієнтація на аналіз, перевірку і тестування з
метою оцінки якості ПС на всіх стадіях розробки;
період з 1988 по 1995 роки - інтеграція дій з перевірки і тестування в
життєвий цикл ПС з метою запобігання появи дефектів на всіх стадіях
розробки (з охопленням всіх дій з верифікації, валідації і тестування).
З появою в 1995 році стандарту ISO/IEC 12207, в якому всі дії, пов'язані із
створенням ПС, представлені у вигляді окремих процесів ЖЦ, сталося
розділення завдань верифікації, валідації і тестування по окремим
процесам. Тестування віднесене до основних процесів, але
представлене не одним, а групою процесів.
Ряд завдань тестування вирішуються в рамках інших процесів розробки,
зокрема, завдання планування тестування ПЗ розподілені по процесах:
«Аналіз вимог до ПЗ», «Проектування архітектури системи», «Проектування
ПЗ». Завдання автономне і інтеграційне тестування ПЗ виконуються в
рамках процесів «Побудова ПЗ» і «Інтеграція ПЗ», оскільки нерозривно з
ними пов'язані.

112.

Галузь знань «Тестування ПЗ» в SWЕВОК
Тестування
Основи
тестування
Рівні тестування
Термінологія
тестування
Ключові
питання
Зв’язок тестування
з іншими видами
діяльності
Об’єкти
тестування
Цілі
тестування
Метод тестування
Засновані на
досвіді та інтуіції
Засновані на
специфікації
Засновані на
коді
Методи
направленого
пошуку помилок
Засновані на
використанні
Засновані на типі
ПС
Вимірювання
результатів
тестування
Процес тестування
Оцінка
програм при
тестуванні
Практичні
міркування
Оцінка
виконаних тестів
Тестові
роботи

113.

Термінологія тестування
Тестування полягає в динамічній перевірці поведінки програми на
скінченній множині тестових даних (тестові набори даних – ТНД),
спеціальним чином вибраних з нескінченного вхідного простору, на
відповідність встановленій очікуваній поведінці.
Тестування завжди передбачає деякий «компроміс» між обмеженими
термінами і потенційно необмеженою кількістю тестів, що призводить до
відомих проблем тестування: ухвалення рішень про адекватність
тестування, і проблемам управління - оцінці витрат (вартості, часу,
персоналу) на тестування.
З проблемою адекватності тестування пов'язана проблема вибору
обмеженої множини тестів. Методи тестування відрізняються підходами
до вибору множини ТНД з вхідного простору даних.
Очікувана поведінка - потрібно уміти визначати, чи правильні отримані
результати виконання програми, чи відповідає спостережуване виконання
очікуванням користувача або специфікаціям.
Два основні підходи до виконання тестування - деструктивний (негативне,
руйнівне тестування) і конструктивний (позитивне або демонстраційне).
При деструктивному підході тести вибираються з метою виявлення
дефектів, і ефективним вважається тест з високою вірогідністю їх виявлення.
При конструктивному підході тести вибираються для демонстрації
відповідності характеристик ПС встановленим вимогам користувача або
цілям якості.

114.

• До ключових питань тестування в SWЕВОК віднесені наступні:
Критерії вибору тестів/Критерії адекватності тестів (або правила припинення
тестування). Критерії можуть застосовуватися як для створення ТНД, так і для
перевірки, наскільки вибрані тести адекватні завданням тестування, а також
допомагають визначити, коли можна або необхідно припинити тестування.
Ефективність тестування/Цілі тестування. Тестування - це спостереження за
поведінкою програми, що виконується в цілях тестування із заданими
параметрами, по заданому сценарію або з іншими заданими початковими
умовами або цілями тестування. Ефективність тесту може бути визначена лише
в контексті заданих умов проведення тестових випробувань.
Тестування для виявлення дефектів. У тестуванні для виявлення дефектів
застосовується деструктивний підхід; а успішним вважається тест, що виявив
дефект. Цей підхід принципово відрізняється від іншого підходу, коли тести
запускаються для демонстрації того, що програма задовольняє пред'явлені до
неї вимоги і, відповідно, тест вважається успішним, якщо не знайдено дефектів.
Проблема оракула. «Оракул» в тестуванні - це будь-який агент (людина або
програма), що оцінює поведінку програми і що формує висновок про результат
тесту (тест пройдений чи ні). Цей висновок істотно залежить від трактування
понять «відмова» і «дефект» в конкретному контексті.
Теоретичні і практичні обмеження тестування. Обмеження зумовлені
неможливістю вичерпного тестування і його економічної недоцільності для
конкретних ПС. Тестування повинно проводитися з урахуванням ризику відмови
ПС і ґрунтуватися на таких стратегіях тестування, які отримали поширення в
сучасних методологіях розробки - тестування, засноване на ризику (risk-based
testing) та кероване ризиком тестування (risk-driven testing).
Проблема нездійсненних шляхів. Нездійсненні шляхи - це шляхи потоку
управління програми, які не можуть бути виконані ні при яких вхідних
параметрах. Це складна проблема, особливо при автоматизації тестування.
Тесто-придатність. Цей термін має два різні значення. Перше - міра легкості
опису критеріїв тестового покриття для ПС. Друге - вірогідність, що виконання
програми при тестуванні призведе до її відмови, за наявності дефекту.

115.

Структуризацію процесу тестування ПС по рівнях звичайно зв’язують або з
видами тестованих об'єктів (функція, модуль, система або її частини), або з
цілями якості ПС (функціональність, безпека, надійність), що перевіряються,
на різних стадіях створення і експлуатації ПС.
Виділяють 3 рівні тестування ПЗ: автономне або модульне (unit testing),
інтеграційне (integrating testing) і системне (system testing). У стандарті
ISO/IEC 12207 сформульовано 4 рівні тестування:
модульне(у процесі «Побудова (Конструювання) ПЗ»);
інтеграційне (у процесі «Інтеграція ПЗ»);
тестування ПЗ (власне як процес);
системне (у процесі «Системна інтеграція»).
Модульне тестування передбачає перевірку функціонування об’єктів і
виконується розробниками з доступом до коду, чергуючись з налагодженням.
Об'єктами тестування є окремі процедури (методи і класи в ООП), програмні
модулі і програмні компоненти, що складаються з тісно зв'язаних модулів.
Цілі модульного тестування - виявлення дефектів в реалізації функцій
об'єктів і підтвердження відповідності об'єкту специфікаціям проекту і ТЗ.
Якнайповніше питання систематичного модульного тестування висвітлені в
стандарті IEEE 1008-87 "Standard for Software Unit Testing".
Інтеграційне тестування призначене для перевірки правильності взаємодії між
програмними об'єктами, протестованими автономно. Інтеграційне тестування
виконується при кожній збірці нової версії ПС з метою виявлення дефектів в
інтерфейсах між інтегрованими компонентами і підтвердження їх відповідності
проекту архітектури ПС.
Тестування ПЗ полягає в перевірці функціонування інтегрованої версії ПЗ
системи в модельованому середовищі. Цілі тестування на цьому рівні виявлення дефектів в реалізації зовнішніх функцій ПЗ і підтвердження його
відповідності специфікації функціональних вимог.

116.

Структура V-моделі
Взаємозв'язок рівнів і цілей тестування можна представити у вигляді
модифікованої каскадної моделі ЖЦ (так званої V-подібної). Різновидів V-моделі
існує багато. Вони використовують чотири рівня тестування, відповідні чотирьом
рівням розробки: 1) компонентне (модульне) тестування; 2) інтеграційне
тестування; 3) системне тестування; 4) приймальне тестування (тестування ПЗ).

117.

V – подібна
модель
тестування
Рівень користувача
Вимоги
користувача
Розробка плану
прийомочного
тестування
Вимоги до
системи
Вимоги до ПЗ
(архітектура)
Рівень системи
Розробка плану
системного
тестування
План, вимоги до системи
Системне
тестування
Рівень ПЗ
Розробка плану
комплексного
тестування ПЗ
Вимоги до проекту
(функціям та
компонентам) Розробка плану
компонентного
тестування
Вимоги до
елементів
(модулів)
Приймальне
тестування
План,вимоги користувача
Розробка планів
автономного
тестування
План, специфікація ПК
План, специфікація
функцій ПК
План, специфікація
внутрішніх ф-цій
Код, данні,
процедури
Комплексне
тестування
Збір та
тестування
компонентів
Автономне
тестування

118.

Виділення рівня системного тестування зумовлене необхідністю
забезпечення і оцінки якості сполучення ПЗ з іншими, у тому числі, не
програмними компонентами сучасних систем. На цьому рівні тестування
відбувається перевірка відповідності ПС цілям якості, встановленим у
вимогах до системи з акцентом на нефункціональні вимоги, такими як
надійність, переносимість, продуктивність, стійкість, а також зовнішнім
інтерфейсам з іншими інформаційними системами, ОС, апаратним
забезпеченням. Мета системного тестування - виявлення дефектів,
пов'язаних з незадовільними технічними характеристиками роботи системи.
Види випробувань програмної системи
Існують види тестування ПС, виконувані на завершальних стадіях її розробки і в
ході експлуатації. До них відносять випробування ПС. У ДСТУ 2853-94
визначені наступні види випробувань: попередні, приймальні,
встановлювальні і експлуатаційні.
Попереднє випробування ПС вважається найвищим рівнем «формального»
тестування, що виконується в середовищі розробки з метою виявлення
можливих дефектів, що залишилися, і оцінки досягнутого рівня якості ПС.
«Формальне» означає, що тестування виконується відповідно до встановлених
задокументованих процедур і за участю представників замовника.
Випробування здійснюються в два прийоми - тестування ПЗ і тестування
системи. Мета попередніх випробувань - виявлення невідповідності ПС
зовнішнім специфікаціям функціональних і технічних характеристик.
Приймальне і всі подальші випробування безпосередньо не зв'язують з
поняттям тестування, бо їх мета - підтвердити відповідність (або
невідповідність) ПС початковим вимогам користувача. Відповідно до стандарту
ISO/IEC 12207 ці випробування виконуються в рамках різних процесів ЖЦ.

119.

Мета приймальних випробувань - визначення міри відповідності розробленої
ПС початковим вимогам замовника (користувача). Ці випробування
проводяться виключно в контексті вимог замовника і з його безпосередньою
участю, як правило, в середовищі експлуатації. У трактуванні стандарту ISO/IEC
12207 приймальне тестування, як вид тестування, не включено в «Процес
тестування», а виконується в рамках процесів «Постачання» і «Приймання
замовником» і зв'язується з процесом «Валідація».
Тестування інсталяції (випробування встановлень) виконується в
середовищі експлуатації (в рамках процесу «Інсталяція ПС») і відноситься до
рівня системного тестування. Включає тестування процедур інсталяції ПС з
зовнішніх носіїв.
Перед остаточним випуском системи проводиться Альфа і Бета тестування.
Для цього система передається невеликій групі користувачів - внутрішніх
(Альфа) або зовнішніх (Бета), які експлуатують систему і інформують
розробника про виявлені проблеми. Виявлені відмови і дефекти свідчать про
якість виконаного раніше тестування.
Регресійне (regression test) і повторне (re-test) тестування. Обидва види
тестування стосуються повторного виконання тестів. Проте вони мають
відмінності. Повторне тестування виконується на будь-якому рівні тестування
для перевірки внесених змін, і не регламентується планом тестування.
Регресійне тестування пов'язане з розвитком ПС і особливо широко
застосовується в ітераційних моделях розробки (для тестування нових версій
ПС). Воно полягає в повторенні підмножини раніше виконаних тестів (для того,
щоб переконатися в тому, що те, що раніше працювало, ще працює), а також
розробці нових тестів для перевірки правильності внесених змін в процесі
супроводження і експлуатації ПС. На відміну від повторного тестування,
регресійне тестування планується (в числі іншого, необхідно вирішити
проблему відбору мінімальної множини ТНД ).

120.

Класифікація методів,
заснованих на підходах
до проектування
тестів
Засновані на
досвіді та
інтуіції
Засновані на
специфікації
Засновані на
коді
Методи
скерованого
пошуку
помилок
Засновані на
використанні
Засновані на
типі ПЗ
Евристичний
Ad hoc
Таблиці
рішень
Тестування
потоку
управління
Припущення
про помилки
Тестування по
операційному
профілю
Компонентне
Функціональні
діаграми
Тестування
потоків
данних
Підсівання
помилок
Інженерія
надійності
Тестування
застосувань
для Інтернету
Мутаційне
тестування
Тестування за
сценаріями
Тестування
графічного
інтерфейсу
Еквівалентне
розбиття
Аналіз
граничних
значень
Тестування
об’єктнооріентованих
програм
Розбиття
вхідного
простору на
категорії
Тестування
узгодженості
протоколів
Тестування
переходів між
станами
Тестування
систем
реального часу
Тестування по
формальним
специфікаціям
Тестування
критичних
систем
Випадкове
тестування

121.

Методи тестування, засновані на досвіді і інтуїції
Спеціалізоване тестування (Ad hoc). Найбільш поширений підхід, при якому тести
розробляються виходячи з інтуїції тестувальника і його досвіду в тестуванні подібних
ПС. Ефективність підходу визначається виключно майстерністю тестувальника.
Підхід не вимагає детальної специфікації функцій ПЗ, але не забезпечує оцінювання
повноти тестового покриття. Розвитком підходу є «дослідницьке тестування»
(exploratory testing), основні принципи якого - поєднання вивчення ПП з
проектуванням тестів і їх виконанням.
Методи, засновані на специфікації (або методи функціонального тестування)
Методи широко відомі і відносяться до методів «чорного ящика». Вони
застосовуються для тестування функцій програми і передбачають наявність
специфікації програми (формальної або неформальної), що використовується як
еталон. Методи відрізняються між собою підходами до вибору тестових даних з
множини даних вхідного простору функцій.
До основних методів функціонального тестування відносяться: 1) таблиці
рішень; 2) функціональні діаграми; 3) еквівалентне розбиття; 4) аналіз
граничних значень; 5) розбиття вхідного простору на категорії;
6) тестування переходів між станами; 7) тестування засноване на
формальних специфікаціях.
1) Метод використовує таблиці рішень для проектування тестів. Кожна колонка
такої таблиці представляє комбінацію умов, які можуть істотно вплинути на
виконання програми. Ці умови ідентифікуються на основі аналізу специфікацій.
Потім визначається множина їх можливих значень, і встановлюються обмеження
відносно їх сумісності. Так скорочується кількість тестових предикатів (наприклад,
якесь обмеження може говорити про те, що, якщо умова 1 виконується, то ні умова
2, ні умова 3 не можуть виконуватися).

122.

2) Метод полягає в перетворенні специфікації у функціональні діаграми.
Ідентифікується кожна окрема функція, а потім визначаються всі причини, що впливають
на її поведінку, і всі відповідні реакції (наслідки). Далі будується граф (діаграма), що
зв'язує комбінації причин з очікуваними реакціями на них. Для кожного наслідка, вказаного
на графі, визначаються ТНД щляхом перебору всіх комбінацій причин, що породжують
наслідок. Метод забезпечує побудову ефективних тестів, але складний у використанні, бо
із зростанням числа причин ускладнюється граф причинно-наслідкових зв'язків, а
встановлення обмежень зв'язане з додаванням нових проміжних вузлів.
3) У методі еквівалентного розбиття множина значень вхідних даних функції,
утворюючих вхідний простір, розбивається на набір підмножин таким чином, що в кожну
підмножину потрапляють значення, еквівалентні один одному з точки зору їх
використання в тестах для виявлення помилок. Вважається, що всі тести, які можуть бути
побудовані на основі еквівалентних значень, представляють один «клас еквівалентності»,
і для тестування досить вибрати лише найефективніші з них.
4) У методі аналізу граничних значень, який доповнює попередній метод, дані
вибираються на границях вхідних областей класів еквівалентності, оскільки багато відмов
відбуваються через дефекти, що пов'язані з обробкою граничних значень входів. Важливе
розширення цього методу - тестування стійкості, коли тестові дані вибираються
також і поза областю для тестування відмовостійкості програми до недопустимих входів.
Методи еквівалентного розбиття і аналізу граничних значень вважаються базовими
методами функціонального тестування і повинні застосовуватися разом при проектуванні
набору тестів для кожного рівня тестування.
5) У розвиток цих методів був створений метод, заснований на специфікаціях функцій, і
що використовує для побудови функціональних тестів розбиття вхідного простору
функцій на певні категорії (category partition method або CP-метод). Суть методу
полягає у ряді послідовних декомпозицій функції, починаючи з початкової функціональної
специфікації, і закінчуючи окремими деталями кожної тестованої процедури, і створенні
специфікацій тестів на основі виділення категорій інформації про параметри функції і
умови її виконання.

123.

Правильний та неправильні класи еквівалентності для події 800 ≤ Нб ≤ 1200
II
I
800
III
1200
Класи еквівалентності та граничні області
I
IV
800
II
V
1200
III

124.

6) У методі тестування переходів між станами програма, реалізуючи функцію,
представляється у вигляді моделі, яка відображає всі можливі стани її виконання,
переходи між цими станами, події, що зумовлюють переходи, і подальші дії з обробки
даних в залежності від напрямків переходу.
7) Опис специфікацій на формальній мові (що має певний синтаксис і семантику)
дозволяє автоматично будувати по ним функціональні тести і в той же час забезпечує
еталон для перевірки результатів. Існує цілий ряд методів генерації тестів по
формальних специфікаціях.
Всі вищезгадані методи функціонального тестування відносяться до систематичних
методів на відміну від випадкових (стохастичних) і статистичних методів.
При випадковому тестуванні вхідні дані для тестів вибираються випадково. Як
інструмент для генерації вхідних даних можуть застосовуватися датчики випадкових
чисел. Для інтерактивних програм тестувальник використовує випадкову комбінацію дій з
програмою, намагаючись виявити області її нестійкого функціонування.
Методи, засновані на аналізі коду (або структурні методи)
У традиційній класифікації структурні методи відносять до методів «білого ящика», де
структура програми представляється у вигляді спрямованого графа, в якому
ідентифікуються потоки управління або потоки даних. Тому методи діляться на дві
основні категорії: тестування потоку управління (шляхів) і тестування потоку даних.
У методах тестування потоку управління дані з вхідного простору вибираються так, щоб
забезпечити максимальне покриття коду. Основні методи приведені нижче:
Тестування рядків. Вибираються дані, що забезпечують виконання всіх рядків
(операторів) програми хоча б 1 раз. Цей метод дає найслабший критерій покриття «покриття рядків», прийнятний для програм, що не містять логічних умов і циклів.
Тестування гілок. Вибираються дані, які забезпечують виконання всіх шляхів в програмі
за допомогою логічних умов, що набувають значень true або false.
Тестування логічних умов. Гілки в програмі утворюються в результаті виконання
складних логічних умов, а тому ТНД вибираються так, щоб перевірити всі значення
логічних умов. Цей метод дає найповніший критерій покриття коду програми. Якщо для
задоволення критерію покриття операторів досить 1 тесту, а для покриття гілок буде
досить 2, то для тесту «логічних умов» потрібно створити не менше 4 тестових випадків.

125.

Тестування циклів. Тести розробляються для перевірки кожного циклу при граничних
значеннях змінних циклу і усередині їх границь (для тестування стійкості цикли
перевіряються при значеннях поза границею). Критерій покриття - «всі цикли» в програмі.
У методі тестування потоку даних тестові дані вибираються таким чином, аби
прослідкувати шлях кожної змінної в програмі від визначених значень до останнього
використання. Цей метод вимагає великої кількості тестів, тому на практиці трасуються
лише найбільш критичні значення змінних. Особливий інтерес представляють значення
змінних, що беруть участь в операціях ділення, умов і циклів, виконання яких залежить від
значень змінних. Метод тестування потоку даних може також застосовуватися для пошуку
помилок часу виконання, що важко виявляються, бо зв'язані з використанням пам'яті.
Структурні методи зазвичай застосовуються на рівні модульного тестування програми її
розробником і чергуються з налагодженням, хоча можуть використовуватися і в процесах
V&V для перевірки критичних програм. Методи функціонального і структурного
тестування розглядаються як взаємодоповнюючі, бо використовують різні джерела
інформації для побудови ТНД і призначені для виявлення різних типів помилок.
Методи направленого пошуку помилок
Методи використовуються для проектування тестів, спеціально створених для виявлення
помилок певних типів. До основних методів цієї категорії відносяться: припущення про
помилки (error guessing); підсівання помилок (error seeding); мутаційне тестування
(mutation testing).
Згідно методу висунення припущень про помилки на підставі «історичної» інформації
про помилки, виявлені в подібних програмах, досвіду тестувальника, а також каталогів
відомих помилок, складається список можливих помилок і помилкових ситуацій
(«класичних» приклад- ділення на 0). У традиційній класифікації метод відноситься до
категорії методів «чорного ящика». Ідея - вчитися на чужих помилках, а не на власних.
Методи підсівання помилок і мутаційного тестування призначені для перевірки
ретельності вже виконаного тестування. Вони відносяться до категорії методів «білого
ящика». У методі підсівання помилок в код,протестований на певному ТНД, спеціально
вноситься невелика кількість помилок, а потім програма повторно тестується. Якщо
виявляються не всі внесені помилки, набір тестів вважається недостатнім. Відношення
кількості виявлених внесених помилок до загальної кількості внесених помилок
припускається приблизно рівним відношенню кількості знайдених реальних помилок до
загального числа помилок, що містяться в програмі.

126.

Тести відображають структури даних, алгоритми та інтерфейси між окремими
компонентами системи. Методи функціонального тестування поділяються на:
статичні і динамічні. Статичні методи використовуються під час проведення
інспекцій вихідного коду й аналізу специфікацій компонентів, без виконання програм
на комп’ютерній платформі. Динамічні методи використовуються в процесі
виконання програми на комп’ютері і базуються на побудові графа, що зв’язує
причини помилок з очікуваними реакціями. У процесі тестування накопичується
інформація про помилки, яка надалі слугує для оцінки надійності програм.
Статичні методи тестування. До статичних методів належать методи аналізу
послідовностей операторів і аналізу перетворень типів даних.Техніка аналізу методичний перегляд і аналіз структури програм, а також у доведення правильності
програм формальними методами.
• Статичний аналіз спрямований на аналіз документів, створених на всіх етапах ЖЦ, і
полягає в інспекції вихідного коду програми й наскрізному контролі. Інспекція
вихідного коду складається із спільного розгляду документів незалежними
експертами за участю розробників. Спочатку перевіряється повнота, цілісність,
однозначність і сумісність документів на ПС у порівнянні з вихідними вимогами. На
етапі реалізації ПС під інспекцією розуміється аналіз текстів програм щодо
відповідності вимогам стандартів і керівних нормативних документів ТП.
• Проведення формальних інспекцій і наскрізного контролю (або перегляду)
регламентується стандартом NASA Std. 2202 – NASA Software Formal Inspections
Standard. При наскрізному контролі проводиться перегляд коду програми (ручна
імітація), що дозволяє виявити помилки в логіці.
• У свою чергу статичні методи поділяються на такі методи: Метод простого
структурного аналізу (Дейкстра і Хоар) – орієнтований на аналіз структури
програми (потоки управління й даних). Для проведення аналізу структуру програми
подають у формі графової моделі, де кожна вершина – оператор, а дуга – передача
керування. Цей підхід дозволяє виявити логічні помилки. Метод доказу
правильності програм (Флойд і Наур)–метод надійний, однак трудомісткий і вимагає
колосальних ресурсів. Метод аналізу дерева відмов – вибір ситуації відмови в
окремому компоненті системи й подальше відстеження подієвих ланцюжків, які
можуть призвести до цієї ситуації. Метод аналізу інтерфейсів та інші.

127.

Найповніша класифікація дефектів представлена в стандарті IEEE Std.
1044:1993. У ньому замість терміну дефект використовується термін аномалія.
Важливими аспектами класифікації дефекту є: симптом; серйозність; пріоритет
усунення; стадія розробки і джерело; тип. Симптом дефекту стосується його
видимого прояву, що спостерігає тестувальник при виконанні тестів. Опис
симптому необхідний для аналізу дефекту розробником і визначення дійсної
причини дефекту. Класифікація симптомів така:
Аварійне завершення програми; Неочікувана поведінка програми; "Зависання"
програми; Проблема введення - Коректні дані не вводяться; Неправильні дані
вводяться; Опис даних відсутній або неправильно; Параметри не повні або
відсутні;
Проблема виводу - Неправильний формат; Неправильні
результати/данні; Вивід не повний або відсутній;
Граматика/синтаксис; Незадовільна продуктивність; Відчуття загальної відмови
продукту; Повідомлення про помилку системи; Інше.
Для класифікації дефектів за серйозністю стандарт IEEE Std.1044:1993
рекомендує таку шкалу: Критичний, Серйозний, Значний, Незначний, Не дефект
Класифікація дефектів за стадіями розробки співвідносить дефекти із стадіями
розробки (і процесами), на яких вони були внесені.
Класифікація дефектів за джерелами співвідносить дефекти з робочими
продуктами стадій розробки, використання яких привело до появи дефектів в
коді ПЗ, наприклад: Специфікація (вимог, функцій, проекту, інтерфейсу, даних);
Код (дефекти кодування); Документація на систему; Плани і процедури
тестування.
Нижче перераховані основні типи дефектів (IEEE Std. 1044): Логічні дефекти.
Обчислень. Інтерфейсу. Обробки даних. Введення даних. Обробки помилок і ін.
Згідно підходу, заснованому на профілі дефектів, тестування припиняється, якщо
немає нових і відкритих дефектів серйозності 1, 2, 3. Критерій застосовується при
функціональному і системному тестуванні. Згідно підходу оцінки інтенсивності відмов поки не будуть досягнуті встановлені у вимогах значення метрик надійності.

128.

Опис серйозності дефекту
Код
Серйозність
Опис
1
Критичний
Дефект призводить до відмови всієї системи, підсистеми,
компонента. Подальше тестування і/або використання
системи неможливе.
2
Серйозний
Дефект призводить до відмови компонента ПЗ, втрати даних.
3
Значний
4
Незначний
Дефект не призводить до відмови, не погіршує зручність
користування системою, його можна обійти.
5
Не дефект
Помилки в тесті, збій програмного чи апаратного середовища.
Дефект призводить до отримання некоректних, неповних,
неправдивих результатів, або дефект стосується зручності
використання системи.

129.

Застосування підходів/методів по рівнях тестування
Метод/підхід
Методи структурного
тестування
Автономний
Інтеграційний
+
+
Евристичні
Рівень ПЗ
Системне
+
+
Таблиці рішень
+
+
Функціональні діаграми
+
+
+
Еквівалентне розбиття
+
+
+
Аналіз граничних значень
+
+
+
Розбиття на категорії
+
+
+
Тестування переходів
станів
+
+
+
Тестування по
специфікаціям
+
+
+
Припущення про помилку
+
+
+
Випадкове тестування
+
Операційний профіль
Тестування за сценаріями
+
+
+
+
+

130.

Процентне співвідношення помилок при розробці ПС
згідно класифікації Г.Буча
помилки в коді
11%
помилки в
обчисленнях
помилки в управлінні
даними
6%
помилки у
документації
19%
18%
5%
4%
32%
помилки логіки
5%
помилки у
вимогах
помилки
апаратури
помилки в
інтеграції

131.

Ортогональная классификация дефектов согласно подходу фирмы IBM
Контекст
ошибки
Классификация дефектов
Функция
Ошибки интерфейсов конечных пользователей ПО, вызванные
аппаратурой или связаны с глобальными структурами данных
Интерфейс
Ошибки во взаимодействии с другими компонентами, в вызовах,
макросах, управляющих блоках или в списке параметров
Логика
Ошибки в программной логике, неохваченной валидацией, а также в
использовании значений переменных
Присваивание
Ошибки в структуре данных или в инициализации переменных
отдельных частей программы
Зацикливание
Ошибки, вызванные ресурсом времени, реальным временем или
разделением времени
Среда
Ошибки в репозитории, в управлении изменениями или в
контролируемых версиях проекта
Алгоритм
Ошибки, связанные с обеспечением эффективности, корректности
алгоритмов или структур данных системы
Документация
Ошибки в записях документов сопровождения или в публикациях

132.

Визначення класів еквівалентності для події
S073 = (7120 H 10300) V 588 при тестуванні ПЗ АСКП
Вхідні умови
Обмеження на висоту
польоту
Обмеження на
швидкість
польоту
Правильні класи
еквівалентності
Неправильні класи
еквівалентності
Висота барометрична більше
чи дорівнює 7120м і менше
чи дорівнює 10300м
7120 H 10300 (1)
H 7120 (2)
Швидкість приладова більше
чи дорівнює 588 км/год
V 588 (4)
H 10300
(3)
V 588
(5)

133.

Еквівалентна розбивка та метод граничних значень для предиката 7120 H 10300
із події контролю S073 = (7120 H 10300) V 588
X(6)
X(7)
Hб (висота, м)
X(2)
X(3)
X(1)
7120
10300
Класи еквівалентності для умови V 588 із події контролю S073
Vпр(швидкість, км/г)
X(5)
X(4)
588