Практична робота 3

Тема: розробка вимог на базі стандарту ISO 9126 та колективне інспектування програмного забезпечення.

Теоретичні відомості

Забезпечення якості програмних систем при їх проектуванні є надзвичайно важливим в даний час, коли на ринку програмних систем (ПС) спостерігається жорстка конкуренція. Це особливо важливо для ПС масового використання, до яких відносяться і системи керування базами даних (СКБД), текстовий редактор Word, створення презентацій, графічні редактори.

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

В архітектурі процесів життєвого циклу (ЖЦ) ПС представлено два процеси, які стосу- ються якості, це:

Ø Підтримуючий процес «забезпечення гарантії якості».

Ø Організаційний процес «управління якістю».

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

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

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

 

Аналіз технологій формування вимог

Для формування вимог до ПС можна використовувати стандарт, в якому задана структура і зміст розділів специфікації вимог, які поділяються на два типи: загальні вимоги, або С-вимоги, та детальні вимоги, або D-вимоги. Вимоги замовника подаються, як загальний опис компонентів та функцій ПС. В детальних вимогах передбачено декларування вимог до декількох властивостей ПС, які можна віднести до характеристик якості. В загальному випадку, структура та зміст розділів специфікації вимог, згідно зі стандартом IEEE\ANSI 830, є ієрархічним слабоформалізованим деревом.

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

Крім того, у стандарті відсутні рекомендації щодо вибору атрибутів та метрик з допомогою яких можна було б оцінити міру задоволення вимог. Враховуючи вище перелічені недоліки, бачимо, що технологія, базована на IEEE\ANSI 830, не задовольняє потреби розробки ПС.

При проектування вимог до ПС ряд фірм розробників використовують шаблони та спеціалізовану мову, що дозволяє формалізувати потреби до ПС та розділити описову структуру та дані при їх заповненні. Перевагою даного підходу, відносно технології, базованої на рекомендаціях ІЕЕЕ 830, є те, що методика використання шаблонів та відповідної мови дозволяє суттєво формалізувати формулювання та представлення вимог, а це, в свою чергу, робить її більш гнучкою та прийнятною. Особливо важливо це при внесенні змін у вимоги. Використовуючи шаблони при формулюванні вимог, необхідно визначити та зарезервувати перелік слів або фраз, які б однозначно трактувались як стороною замовника, так і стороною розробника. Якщо це зроблено, тобто узгоджено мову для формулювання вимог, тоді спосіб, а відповідно й засіб трактування вимог, стає досить гнучким. Для прикладу, якщо зарезервувати слово «повинен» та його інтерпретації, то спосіб формулювання вимог буде мати наступний вигляд:

«Система <повинна> опис можливостей системи».

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

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

 

Постановка задачі:

Провести оцінювання якості програмних продуктів за допомогою використання метрик стандарту якості ПЗ ISO9126. В  якості програмного продукту вибрати СКБД. Нехай кінцевий користувач висунув наступні вимоги:

1)          Швидкість відклику на запит повинна становити від 1 до 10с;

2)          Після збоїв в електроживленні відновлення повинно тривати не більше 10хв;

3)          Об’єм даних, який може зберігатись повинен становити не менше 10Гб з можливістю розширення.

Побудувати наступні таблиці:

ü    Таблиця вимог у структурованому стані;

ü    Таблиця вимог якості у використанні;

ü    Таблиця характеристик, під характеристик та атрибутів зовнішньої якості;

ü    Таблицю – матрицю кореляції.

Зробити висновок.

Розробка вимог якості

Для оцінки якості системного прораного забезпечення, використовуються наступні технології:

·    Інтегральні тести SPEC (Standard Performance Evolution Corporation);

·    Тести TCP (Transaction Processing performance Council).

Тести SPEC дозволяються оцінити об’єм обчислень, або кількість ітерацій за фіксований час, та швидкість обчислень, або час виконання однієї ітерації тесту.

Тести TCP є більш спеціалізованими і вони призначені для оцінки продуктивності системи ітерактивної обробки транзакцій (OLTP).

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

Одним з шляхів вирішення цієї задачі є використання рекомендацій стандартів з якості ПС ISO\IEC 25010, в якому описані моделі якості ПС та стандарту ISO\IEC 25030, в якому сформовані положення по розробці вимог якості.

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

Ruser={A1, A2, A3},

де   А1 – функція виконувана ПЗ,

А2 – характеристика якості виконуваної функції,

А3 – метрика вимірювання А2.

Конкретний варіант А1 вибирається з переліку, який зберігається в базі даних.

На наступному кроці вимоги (1) перетворюються у вимоги якості у використанні, які записуються у вигляді:

 

Rinuse={Hi, Ai, Mi},               (2)

де   Hi – характеристика якості,

Ai – атрибут якості,

Mi – метрика для вимірювання якості

Для цього пропонується використовувати базу знань (рис. 1), в якій зберігається інформацію про міцність зв’язків (кореляцію) між характеристиками й атрибутами якості у використанні (2) та вимогами кінцевого користувача (1). Матриця кореляції зв’язків {Kij} між А1i з

(1)               та Hj з (2) визначається експертним шляхом або з використанням алгоритмів асоціативної класифікації.

Зв'язки  між  вимогами  користувача  та  характеристиками   й

атрибутами вимог якості у використанні. Кожен з таких зв'язків

має вагу – певне числове значення. З двох зв'язків сильнішим є той, для його вага є більшою.

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

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

 

Таблиця 1 Вимоги користувачів у структурованому представленні

Умовне позначення	Функція	Характеристика	Метрика

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

 

Таблиця 2 Вимоги якості у використанні

Умовне позначення	Вимога користувача	Характеристика	Атрибут	Метрика

 

Побудова моделі зовнішньої якості для СКБД розпочинається з етапу відбору з числа наявних в стандарті ISO 25010 характеристик та підхарактеристик з метою побудови модифікованої моделі якості. Модифікована модель зовнішньої якості до СКБД приведена на рис. 2. Для цього використовується методологія QFD, на основі якої будується матриця кореляції між атрибутами якості у використанні та підхарактеристиками зовнішньої якості.

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

 

 

Таблиця 3 Характеристики, підхарактеристики та атрибути зовнішньої якості

Характеристика	Підхарактеристика	Атрибут	Умовне позначення

 

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

«--» - дуже слабкий зв'язок;

«-» - слабкий зв'язок;

«+» - міцний зв'язок;

«++» - дуже міцний зв'язок.

Результат описати в таблиці 4 Матриця кореляції.

 

Після того, як визначено атрибути зовнішньої якості, їх потрібно спроектувати на атрибути внутрішньої якості. Для цього використовується той самий підхід, що і для зв’язку між якістю у використанні та зовнішньою якістю: побудова моделі внутрішньої якості до СКБД, визначення атрибутів для внутрішньої якості, побудова матриці кореляції з використанням методу QFD та визначення атрибутів, які мають найвищий ступінь зв’язку з атрибутами моделі зовнішньої якості.

На основі вищє розглянутого створити модифіковану модель зовнішньої якості для СКБД.

 

Зробити висновок і оформити звіт.

 

Література:

1.    ISO/IEC 25010. Software engineering-Software product Quality Requirements and Evaluation -  Quality model. /2006

2.    ISO/IEC 12207. Information technology – Software life cycle processes 2002.

3.    IEEE Std 830, IEEE Recommended Practice for Software Requirement Specification.

4.    Requirement Engineering/ Elizabeth Hull , Ken Jekson, Jeremy Dick// Springer Science + Buisness Media, 2005.-240 p.

5.    Standard Performance Evolution Corporation (SPEC). http://www.spec.org

6.    Transaction Processing Performance (TCP). http://www.tcp.org

7.    Проектування архітектури WEB-застосування на основі моделі якості/ Харченко О.Г.,Галай І.О., Боднарчук І.О., Яцишин В.В. // Інженерія програмного забезпечення

№4, 2010.-26-34 с.