ПроектнийПрактикум / ПрофесійнаПрактика / Разное / lavrishcheva-6

13.K. C. Kang, S. G. Cohen, J. A. Hess, W. E. Novak, and A. S. Peterson. Featureoriented domain analysis (FODA) feasibility study. Technical Report CMU/SEI-90-TR-21, Software Engineering Institute, Carnegie Mellon University, 1990.

14.Mezini, M., Ostermann, K.: Variability management with feature-oriented programming and aspects. In: Foundations of Software Engineering (FSE-12), ACM SIGSOFT (2004)

15.Wilson С., Maples B., Londgrave T. Принципы проектирования и разработки программного обеспечения .–Учебный курс.–Пер.с анг.–М.: Русская редакция, 2000.–559с.

16.Буч Г., Рамбо Д., Джекобсон А. Язык UML. Руководство пользователя:

Пер. с англ. – М.: ДМК, 2000, - 432 с.

17.Кендалл Скотт. Унифицированный процесс. Основные концепции.– Москва–С–Петербург–Киев, 2002.– 157с.

18.CORBA. The Common Object Request Broker: Architecture and Specification. Revision 2.0. Copyright 1991, 1992, 1995 by Sun Microsystems, Inc. – 1995. – 621 p.

19.Эммерих В. Конструирование распределенных объектов. Методы и средства программирования интероперабельных объектов в архитектурах

OMG/CORBA, Microsoft COM и Java RMI. – М.: Мир, 2002. – 510 с.

20.Барлет Н., Лесли А., Симкин С. Программирование на JAVA.

Путеводитель. – Киев. – 1996. – 736 с.

21.Гамма Э., Хелм Р., Джонсон Р., Влиссидес Дж. Приемы объектно-

ориентированного проектирования. Паттерны проектирования. – СПб:

Питер, 2001. – 368 с.

252

Розділ 9. МОДЕЛІ ЯКОСТІ ТА НАДІЙНОСТІ ПРОГРАМНИХ СИСТЕМ

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

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

Якість ПС – предмет стандартизації. У стандарті ДСТУ 2844–94 наведено визначення якості ПС як сукупності властивостей (показників якості) ПС, що забезпечують його здатність задовольняти потреби замовника відповідно до призначення. Цей стандарт регламентує базову модель якості й показники, головним серед яких є надійність. Стандарт ISO/IEC 12207 визначає не тільки основні процеси ЖЦ розробки ПС, а й організаційні та додаткові процеси, які регламентують інженерію, планування й керування якістю ПС.

Відповідно до стандарту на процесах ЖЦ повинен здійснюватися контроль якості ПС:

перевірка відповідності вимог до проектованого продукту та критеріїв їхнього досягнення;

верифікація й атестація (валідація) проміжних результатів ПС на процесах ЖЦ і вимірювання ступеня відповідно до певних показників, які досягаються;

тестування готової ПС, збирання даних про відмови, дефекти й інші помилки, які виявлено у системі;

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

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

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

9.1. Модель якості програмних систем

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

Рис. 9.1. Основні аспекти якості ПС

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

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

Модель якості програмного забезпечення (рис. 9.2) має чотири рівні подання. Перший рівень подання відповідає визначенню характеристик (показників)

якості ПС, кожна з яких відображає окреме уявлення користувача про якість. Відповідно до стандарту [1–4] у модель якості входить шість характеристик

або шість показників якості:

1)функціональність (functionality);

2)надійність (realibility);

3)зручність (usability);

4)ефективність (efficiency);

5)супровід (maitainnability);

6)мобільність (portability).

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

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

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

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

9.1.1. Стандартні показники якості

Короткий опис семантики характеристик моделі якості наведено в табл. 9.1, а їхній змістовний опис – нижче.

*

Таблиця 9.1 – Коротка характеристика показників якості

1. Функціональність – сукупність властивостей, що визначають здатність ПС виконувати перелік функцій у певному середовищі відповідно до вимог щодо обробки й загальносистемних засобів.

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

До атрибутів функціональності належать:

функціональна повнота – властивість компонента, що визначає ступінь достатності основних функцій для розв’язання задач відповідно до призначення ПС;

правильність (точність) – атрибут, що визначає ступінь досягнення правильних результатів;

інтероперабельність – атрибут, що визначає можливість впливати на ПС спеціальними системами й середовищами (ОС, мережа);

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

2. Надійність – сукупність атрибутів, які визначають здатність ПС перетворювати вихідні дані на результати за умов, що залежать від періоду часу життя (зношування і старіння не враховуються). Зниження надійності ПС відбувається через помилки у вимогах, проектуванні й виконанні. Відмови й помилки в програмах з'являються на визначеному проміжку часу [5–10].

До атрибутів надійності ПС належать:

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

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

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

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

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

До чинників, що впливають на надійність ПС, належать:

сукупність загроз, що призводять до несприятливих наслідків і збитків системи або середовища її функціонування;

загроза як виявлення порушення безпеки системи;

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

підвищують ризик і зменшують деякі властивості надійності системи.

Надійність – одна з ключових проблем сучасних програмних систем, і її роль буде постійно зростати, оскільки постійно підвищуються вимоги до якості комп'ютерних систем. Новий напрямок – інженерія програмної надійності (Software reliability engineering) – орієнтується на кількісне вивчення операційної поведінки компонентів системи відносно користувача, який очікує надійну роботу системи

[7].Він складається з:

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

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

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

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

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

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

До атрибутів зручності застосування належать:

зрозумілість – атрибут, що визначає зусилля, витрачені на розпізнавання логічних концепцій та умов застосування ПС;

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

оперативність – атрибут, що вказує на реакцію системи під час виконання операцій й операційного контролю;

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

4. Ефективність – множина атрибутів, які визначають взаємозв'язок рівнів виконання ПС, використання ресурсів (засоби, апаратура, матеріали – папір для друкувального пристрою та ін.) і послуг, що виконуються штатним обслуговуючим персоналом та ін.

До характеристик ефективності ПС належать:

реактивність – атрибут, що вказує на час отклику, обробки й виконання функцій;

ефективність ресурсів – атрибут, що визначає кількість і тривалість використовуваних ресурсів при виконанні функцій ПС;

погодженість – атрибут, що вказує на відповідність даного атрибута заданим стандартам, правилам та приписам.

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

Супровід містить у собі такі атрибути:

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

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

стабільність – атрибут, що вказує на сталість структури й ризик її модифікації;

зовнішні метрики, що визначають властивості продукту, видимі користувачеві;

внутрішні метрики, що визначають властивості, видимі тільки команді розробників.

Зовнішні метрики продукту – це метрики:

надійності продукту, які використовують для визначення числа дефектів;

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

супроводу, за допомогою яких вимірюють ресурси продукту (швидкість, пам'ять, середовище);

застосування продукту, які сприяють визначенню ступеня доступності для вивчення й використання;

вартості створеного продукту.

Внутрішні метрики продукту вміщують:

метрики розміру, необхідні для вимірювання продукту за допомогою його внутрішніх характеристик;

метрики складності, необхідні для визначення складності продукту;

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

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

Зовнішні й внутрішні метрики задають на процесі формування вимог до ПС і

єпредметом планування й керування досягненням якості кінцевого програмного продукту.

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

– вимог;

– сценаріїв і дійових осіб;

– об'єктів, вміщених у сценарій, і локалізація вимог до кожного сценарію;

– параметрів й операцій об'єкта й ін.

Стандарт ISO/IEC 9126–2 визначає такі типи мір:

– міра розміру ПС в різних одиницях вимірювання (число функцій, рядків у програмі, розмір дискової пам'яті й ін.);

– міра часу (функціонування системи, виконання компонента й ін.);

– міра зусиль (продуктивність праці, трудомісткість й ін.);

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

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

загальне число об'єктів і число повторно використовуваних;

загальне число операцій, повторно використовуваних і нових операцій;

число класів, що успадковують специфічні операції;

число класів, від яких залежить певний клас;

260 Розділ 9

число користувачів класу або операцій та ін.

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

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

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

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

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

загальний час розробки й час окремо для кожної стадії;

час модифікації моделей;

час виконання робіт на процесі;

число знайдених помилок при інспектуванні;

вартість перевірки якості;

вартість процесу розробки.

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

9.1.3. Стандартна оцінка показників якості

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

За визначенням стандарту ISO/IES 9126-2 метрика якості ПС являє собою «модель вимірювання атрибута, що зв'язує його з показником якості». При вимірюванні показників якості даний стандарт дає змогу визначати такі типи мір:

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

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

міри зусиль – продуктивний час, витрачений на реалізацію проекту (продуктивність праці окремих учасників проекту, колективна трудомісткість та ін.);

міри інтервалів між подіями, наприклад, час між послідовними відмовами;