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

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. Програмні засоби
ЕОМ. Забезпечення якості. Терміни та визначення.)

7.

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 види зв’язків
1:1
1:n
m:n

15.

Фрагмент та приклад інформаційної моделі

16.

Приклад відношення спадкування

17.

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

18.

ДПС автоматичної пральної машини

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.

Приклад діаграми потоків даних дій (ДПДД) для стану
“Запис показників датчиків”

22.

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

23.

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

24.

Діаграма сценаріїв для клієнта банку

25.

Діаграма сценаріїв бібліотеки

26.

Приклади розширення сценаріїв

27.

Приклад відношення “використовує”

28.

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

29.

Модель аналізу вимог: асоціації між об’єктами бібліотечної системи

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.

Архітектурне проектування: порівнева архітектура ПС
Архітектурне проектування полягає у визначенні: складу компонент; способів
їхньої композиції; обмеження на їх зв’язки та сполучення.
Трансформація проекту в програмну систему
Процес має кілька назв: конструювання,кодування, програмування,реалізація
Необхідно виконати конструювання, визначивши модулі, потім запрограмувати
модулі обраною мовою програмування, для чого переводять нотацію проекту в
коди, після чого проводиться тестування й верифікація отриманого коду ПС. В
цілому, необхідно перетворити проект у систему, документуючи достатнім чином всі
етапи трасформації, тобто реалізувати ПС. Конче необхідно при реалізації ПЗ
застосовувувати 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.

44.

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

48.

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

49.

Атрибути ПС, які характеризують якість, виміряються за
допомогою метрик якості.
Метрика – це комбінація конкретного методу вимірювання
атрибута сутності й шкали вимірювання.
Characteristic, Subcharacteristic, Attribute

50.

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

51.

Метрика в системі вимірювання якості

52.

Рівні ранжування метрик

53.

Класифікація мір та метрик якості
Стандарт ISO/IEC