На головну

Основні характеристики якості програмного забезпечення.

  1.  C. Цей твір поглиненої дози (D) на коефіцієнт якості іонізуючого випромінювання (k);
  2.  Event-менеджмент - поняття, основні методи.
  3.  I. Основні богословські положення
  4.  I. ОСНОВНІ Богословська ПОЛОЖЕННЯ
  5.  I. Основні завдання та напрямки роботи бібліотеки
  6.  I. Основні лінгвістичні джерела.
  7.  I. Основні права громадян

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

ПС характеризуються також конструктивними показниками якості, номенклатура яких майже не залежить від призначення і області використання програм. Ці показники характеризують будь-які програми та дозволяють зіставляти за показниками якості програми різного призначення. Оцінювані характеристики ПС групуються по трьох етапах життєвого циклу програм: проектування, експлуатація, супровід. Всього розрізняють чотири етапи життєвого циклу програм (рис.12): системний аналіз, в ході якого визначається призначення і основні функціональні характеристики, оцінюються витрати і можлива ефективність застосування; проектування програм включає розробку структури ПС, програмування налагодження модулів, випробування та впровадження для постійної експлуатації програм; експлуатація програм; супровід програм полягає в розвитку функціональних можливостей, підвищення експлуатаційних характеристик системи, тиражування програмного комплексу. Показники якості ПС і методи їх визначення, групуються за останніми трьома етапами (рис.13). Це не єдина модель показників якості ПС, в роботах [8,1] запропоновані інші системи показників, але приводиться на рис.13 модель має впорядкованістю і дозволяє ранжувати показники.

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


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


Рис.12. Схема життєвого циклу програмних систем


 
 


Рис.13. Схема показників якості програмних систем


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

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

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

Всі конструктивні показники якості ПС діляться на основні та допоміжні (що впливають на значення основних) показники. Основні показники показані на рис.13, а допоміжні в табл.2.

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

4.3. Показники якості етапу проектування програмних систем

Складність проектування конкретізуется і стає вимірним при встановленні зв'язку цього поняття з конкретними ресурсами, необхідними для виконання завдання. У табл.3, наведені різні показники складності програм, з яких етап проектування характеризують п.1-3. Ці показники вибрані по тому, що вони є імітують ресурсами для проектування будь-якого виробу, в тому числі і ПС.

Складність проектування ПС часто називають статистичної складністю. Її доцільно аналізувати на базі трьох специфічних компонент: складність програмних модулів, складність структури комплексу, складність структури даних (рис.14).

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


Таблиця 2.Допоміжні показники якості.

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

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

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

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

 (1)

де V - об'єм тексту програми в бітах; V *  - Потенційний обсяг опису програм - це обсяг найбільш компактного тексту програми для фіксованого алгоритму, написаного на мові самого високого рівня.

Вираз (1) може бути представлено у вигляді

,

де l - показник рівня мови використовуваної системи програмування (див. табл.4).

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

,

де S - інтенсивність аналізу і прийняття рішень програмістом, яка вимірюється числом символів, які розрізняє програміст в секунду (S?18).

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


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

   показник складності  Рівень складності
 простий  середньої складності  складний  над-складний
 1.  Трудомісткість створення, чол. - роки  0,1  1-10  103-104
 2.  Тривалість розробки, роки  0,1-0,5  1-2  2-5  3-10
 3.  Кількість розробляють фахівців, чол  1-2  3-10  10-100  100-1000
 4.  Довжина програми, операторів  103  104  105  106-107
 5.  Кількість модулів, шт.  1-3  10-102  103  104-105
 6.  Кількість оброблюваних змінних, типів  102-103  104-105  106-108
 7.  Тривалість рішення варіанта завдання, ч.  10-2-10-1  102-103
 Допустимий час відгуку, с.  106-104  103-102  10-0,1  10-2-10-4

Таблиця 4. Значення показника рівня мови l

 Мова програмування  Рівень мови l
 PL-1  1,53
 Алгол  1,21
 Фортран  1,14
 асемблер  0,88


Рис.14. Види складності проектування.

                               
               


Рис.15. Приклад графа програми (а) і повного безлічі маршрутів в цьому графі (б)


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

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

де М - безліч індексів модулів ПС;  - Змінна, що враховує зв'язок i-го модуля з j-им;  - Змінна, що враховує зв'язок j-го модуля з i-им; и  можуть приймати або значення 1, якщо зв'язок є, або 0, якщо зв'язку немає.

Слід зазначити, що при такому визначенні складності кожна керуюча зв'язок враховується двічі: в зухвалій і в викликається модулі.

Загальна кількість інформаційних зв'язків в ПС одно:

де G - безліч індексів інформаційних одиниць (змінні, які передаються в модуль як формальні параметри, також є інформаційними одиницями);  - Змінна, що враховує використання k-ой інформаційної одиниці в i-му модулі;  - Змінна, що враховує формування k-ой Інформаційним одиниці в i-му модулі:


Керуючі та інформаційні зв'язки, описуються матрицями зв'язків.

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

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

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

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

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

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

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

Метрики коректності програмних модулів дуже різні і досить повно представлені в [8].

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




 В 2. Роль програмних систем САПР ТПП в сучасному |  Структура і склад програмного забезпечення (ПО) |  В 2. Роль програмних систем САПР ТПП в сучасному виробництві |  У 3. Розвиток САПР ТПП |  Структура і склад програмного забезпечення (ПО) САПР ТПП |  Основні принципи проектування ПО САПР ТПП |  Структура математичного забезпечення АСТПП |  Методи розробки ПЗ САПР |  Глава 2. Класифікація сфер застосування і користувачів САПР ТПП |  Характер розв'язуваних завдань і кваліфікація користувачів САПР ТПП |

© um.co.ua - учбові матеріали та реферати