АНАЛІЗ ТА ОПРАЦЮВАННЯ МЕТРИК ОЦІНКИ ЯКОСТІ ПРОГРАМНОГО ЗАБЕЗПЕЧЕННЯ НА ЕТАПІ ПРОЕКТУВАННЯ ГОВОРУЩЕНКО Т.О., кандидат технічних наук, доцент кафедри системного програмування, Хмельницький національний університет IІІ Міжнародна наукова конференція студентів, аспірантів та молодих вчених CSE-2009, травня 2009, м.Львів

ПЛАН 1. Історія 2. Мета дослідження 3. Оцінки якості та складності програмного забезпечення (ПЗ) на етапі проектування 4. Метрики програмного забезпечення ПЗ на етапі проектування 5. Результати дослідження метрик процесу проектування 6. Модель зрілості можливостей ПЗ 7. Автоматизація побудови метрик ПЗ 8. Опрацювання результатів метричного аналізу 9. Висновки

ІСТОРІЯ [1] Скляр В.В. Оценка качества и экспертиза программного обеспечения. Лекционный материал. [2] Майерс Г. Надежность программного обеспечения. [3] Myers G.J. The Art of Software Testing. [4] Липаев В.В. Программная инженерия. Методологические основы. [5] Липаев В.В. Выбор и оценивание характеристик качества программных средств: Методы и стандарты. [6] Орлов С.А. Технологии разработки программного обеспечения. Разработка сложных программных систем. [7] Петрухин В.А., Лаврищева Е.М. Методы и средства инженерии программного обеспечения. [8] Ковалевская Е.В. Материалы к курсу "Метрология, качество и сертификация ПО» [9] Новичков А., Шамрай А., Черников А. Метрики кода и их практическая реализация в Subversion и ClearCase. Часть 1 - метрики [10] Брауде Э. Технология разработки программного обеспечения [11] Boehm B. Software Engineering Economics [12] Бахтизин В.В., Глухова В.А. Применение метрик сложности при разработке программных средств [13] Коган Б.И. Автоматизация оценивания качества программного обеспечения [14] Дастин Э., Рэшка Д., Пол Д. Автоматизированное тестирование программного обеспечения. Внедрение, управление и эксплуатация. [15]K. K. Aggarwal, Yogesh Singh, Arvinder Kaur, and Ruchika Malhotra. Application of Artificial Neural Network for Predicting Maintainability using Object-Oriented Metrics. [16]Janusz Zalewski, Andrew J. Kornecki, Henry L. Pfister. Numerical Assessment of Software Development Tools in RealTime Safety Critical Systems Using Bayesian Belief Networks.

МЕТА ДОСЛІДЖЕННЯ Дослідити: 1. Придатність моделей життєвого циклу ПЗ для визначення якості ПЗ на етапі проектування 2. Вимоги по якості на етапі проектування 3. Інформаційні потоки етапу проектування 4. Методи одержання оцінки значень показників якості з точки зору їх придатності для етапу проектування ПЗ 5. Метрики процесу проектування ПЗ з точки зору точності їх значень на етапі проектування 6. Модель зрілості можливостей ПЗ 7. Автоматизацію побудови метрик процесу проектування ПЗ 8. Методи опрацювання результатів метричного аналізу ПЗ

ЯКІСТЬ ПРОГРАМНОГО ЗАБЕЗПЕЧЕННЯ Якість програмного забезпечення (ПЗ) - це ступінь відповідності присутніх характеристик вимогам [ISO 9001:1994 Quality systems - Model for quality assurance in design, development, production, installation and servicing]. Якість ПЗ - це повнота властивостей і характеристик продукту, процесу або послуги, які забезпечують здатність задовольняти оголошеним або передбачуваним потребам [ISO 8402:1994 Quality management and quality assurance]. Якість ПЗ - це ступінь, в якій воно володіє потрібною комбінацією властивостей [ IEEE Standard for Software Quality Metrics Methodology].

ПРИДАТНІСТЬ МОДЕЛЕЙ ЖИТТЄВОГО ЦИКЛУ ПЗ ДЛЯ ВИЗНАЧЕННЯ ЯКОСТІ ПЗ НА ЕТАПІ ПРОЕКТУВАННЯ Моделі життєвого циклу ПЗ: - каскадна; - поетапна; - спіральна. Для визначення якості ПЗ на етапі проектування найбільш прийнятною є спіральна модель життєвого циклу ПЗ, оскільки саме в такій моделі якість визначається на кожному витку спіралі, який відповідає створенню фрагмента або версії ПЗ.

ВИМОГИ ПО ЯКОСТІ НА ЕТАПІ ПРОЕКТУВАННЯ: - вимоги до структури програмної системи (ПС); - вимоги до навігації по ПС; - вимоги до дизайну інтерфейсів користувача; - вимоги до мультимедіа-компонентів ПС; - вимоги по зручності (usability); - технічні вимоги.

ІНФОРМАЦІЙНІ ПОТОКИ ЕТАПУ ПРОЕКТУВАННЯ ПРОГРАМНОГО ЗАБЕЗПЕЧЕННЯ На етапі проектування формується відповідь на питання: "Яким чином програмна система буде реалізовувати висунуті до неї вимоги? Інформаційні вхідні потоки етапу проектування ПЗ: - інформаційна модель - інформація, яку повинне обробляти ПЗ на думку замовника; - функційна модель - перелік функцій обробки інформації та перелік модулів програмного забзпечення; - поведінкова модель - бажана динаміка ПЗ, тобто режими його роботи. Інформаційний вихідний потік етапу проектування - розроблені дані, розроблена архітектура і процедурна розробка ПЗ.

МЕТОДИ ОДЕРЖАННЯ ОЦІНКИ ЗНАЧЕНЬ ПОКАЗНИКІВ ЯКОСТІ З ТОЧКИ ЗОРУ ЇХ ПРИДАТНОСТІ ДЛЯ ЕТАПУ ПРОЕКТУВАННЯ ПЗ Методи одержання оцінки значень показників якості: - вимірювальний; - реєстраційний; - розрахунковий; - експертний. На етапі проектування ПЗ можуть бути задіяні лише розрахункові та експертні методи вимірювання, оскільки неможливо виміряти жодної характеристики ще не розробленого ПЗ і неможливо реєструвати моменти процесу виконання ще не існуючого ПЗ.

МЕТРИКИ ПРОЦЕСУ ПРОЕКТУВАННЯ ПЗ З ТОЧКИ ЗОРУ ТОЧНОСТІ ЇХ ЗНАЧЕНЬ НА ЕТАПІ ПРОЕКТУВАННЯ Метрика - це міра ступеня володіння властивістю, яка має числове значення [IEEE Standard Glossary of Software Engineering Terminology /IEEE Std ]. Іншими словами, метрика ПЗ - це міра, яка дозволяє одержати числове значення деякої властивості ПЗ або його специфікацій.

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

РЕЗУЛЬТАТИ ДОСЛІДЖЕННЯ МЕТРИК ПРОЦЕСУ ПРОЕКТУВАННЯ ПЗ Основні проблеми метрології ПЗ: - відсутність загальноприйнятої номенклатури показників якості; - неможливість проведення натурних випробувань програм на всій множині початкових даних; - низька достовірність та недостатність інформації для одержання оцінок показників якості; - недостатність засобів вимірювання метрик програми; - відсутність обгрунтованих вимог до метричної інформації, виражених в числовому вигляді, які могли б підлягати перевірці; - відсутність можливості інтерпретації одержуваних метрик і оцінок показників якості програм.

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

МОДЕЛЬ ЗРІЛОСТІ МОЖЛИВОСТЕЙ ПРОГРАМНОГО ЗАБЕЗПЕЧЕННЯ 5 рівнів зрілості (maturity levels) моделі Capability Maturity Model (CMM): - початковий (initial) - 75% софтверних організацій - акцент на кодування і тестування програми; - повторюваний (repeatable) - 15% софтверних організацій - акцент на початкові вимоги, методи оцінки і конфцігураційний менеджмент; - фіксований (defined) - 8% софтверних організацій - процеси документовані, стандартизовані і інтегровані в єдиний технологічний потік; - керований (managed) - 1,5% софтверних організацій - намагання оцінити якість процесів і готового продукту кількісно за допомогою метрик; - оптимізований (optimizable) - 0,5% софтверних організацій - використання кількісних критеріїв якості, намагання усунення помилок ще на стадії внутрішнього тестування.

АВТОМАТИЗАЦІЯ ПОБУДОВИ МЕТРИК Автоматизовані засоби оцінки якості ПЗ: - CMM Live та SoftGuide - оцінка рівня компанії за шкалою СММ; - SCOPE*PROCEPT - аналіз інформаційних моделей процесів створення ПЗ, включаючи методи оцінки якості на основі метрик; - Cleanroom Certification Assistant - підрахунок метрик надійності ПЗ математичними методами; - Logiscope - формування метричної інформації (більше 200 типів метрик) про код; - IBM Rational Software Group - вимірювання метрик повноти тестування; - Hindsight - вимірювання вихідного коду і обчислення значення метрик цикломатичної складності Маккейба, метрик Холстеда, складності архітектури програмного продукту; - EzCover - обчислення метрик: цикломатична складність, видозмінена складність, складність даних, розгалуження за входом, розгалуження за виходом, кількість порожніх рядків, рядків з коментарями, виконуваних рядків; - IBM Rational ClearCase - відстежування стану проекту за такими метриками, як кількість запитів в роботі, кількість версій в розробці і кількість дефектів.

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

ОПРАЦЮВАННЯ РЕЗУЛЬТАТІВ МЕТРИЧНОГО АНАЛІЗУ Статистичний аналіз метричної Інтелектуальні методи інформації для визначення рівня опрацювання метричної складності ПЗ: інформації: - аналіз метрик за релізами; - дослідження використання - аналіз метрик за замовниками; штучних нейромереж (ШНМ) - вибірка проектних даних за для прогнозу якості ПЗ на основі проектами, програмами, замовниками. обєктно-орієнтованих метрик Для визначення задовільності чи [15] - зроблено висновок про незадовільності досягнутого рівня корисність ШНМ в побудові складності ПЗ використовується моделі якості ПЗ; відношення розрахункового значення - доведення застосовності байєсо- метрики до базового (статистичного) вих мереж в якості інструменту значення метрики. Якщо таке відношення підтримки для числової оцінки 1, то приймається висновок про ПЗ в реальному часі щодо ПЗ з задовільний рівень складності ПЗ. особливими вимогами до безпеки [16]. Основна проблема - неможливість Інтелектуальні методи досліджені опрацювання метрик для принципово мало, причому для конкретних нового проекту. типів метрик і конкретного ПЗ.

ВИСНОВКИ Проблеми, які потребують додаткового дослідження: - лише 1.5% софтверних організацій намагаються оцінити якість процесів і готового продукту кількісно, за допомогою метрик, і лише 0.5% софтверних організацій намагаються покращити роботу, керуючись кількісними критеріями якості з метою випуску бездефектних продуктів; - технологія вимірювання якості ще не досягла зрілості, оскільки лише 0.5% софтверних організацій знаходяться на оптимізованому, зрілому рівні моделі CММ; - відсутні єдині стандарти на метрики, створено більше тисячі метрик, тому кожен постачальник "вимірювальної" системи пропонує власні способи оцінки якості і відповідно метрики; - існує проблема складності інтерпретації величин метрик. Саме через невирішеність цих питань поки що неможливо створити бездефектне високоякісне ПЗ.

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