- •Перелік термінів та позначень
- •Передмова
- •Частина 1. Початок програмування в срср. Витоки розвитку
- •1.1. Поява і розвиток технології програмування (1952–2012)
- •1.2. Формування технологічних напрямів (1965–1975)
- •1.3. Становленья технології програмування (1975–1982)
- •1.4. Розвиток інтерфейсу в технології програмування (1976–1992)
- •1.5. Розвиток об’єктної технології програмування (1992–2002)
- •1.6. Індустріальні основи технології програмування (2002–2012)
- •1.7. Навчання тп у кну Тараса Шевченко (1965–2012) та філії мфті (2000–2012)
- •Контрольні питання і завдання до частини 1
- •Список літератури до частини 1
- •Частина 2. Парадигми технології програмування
- •2.1. Модульне програмування та збиральний підхід
- •2.1.1. Інтерфейс в програмуванні
- •2.1.2. Зборка модулів по а.П.Єршову
- •2.1.3. Метод зборки готових програмних елементів
- •2.1.4. Формальне подання методу збирання різномовних модулів
- •2.2. Парадигма об’єктно-орієнтованого програмування
- •2.2.1. Базові концепції ооп
- •2.2.2. Чотирьох рівневе проектування ом
- •2.2.3. Концепції об’єктного аналізу
- •2.2.4. Функції, алгебра та операції об’єктного аналізу
- •2.2.5. Моделювання моделі ПрО
- •2.2.6. Опис параметрів інтерфейсу ом
- •2.3. Парадигма uml-метода моделювання
- •2.3.1 Основні діаграми методу
- •2.3.2. Моделювання поведінки системи
- •2.3.3. Побудова пс засобами uml
- •2.4. Парадигма компонентного програмування
- •2.4.1. Теоретичні аспекти компонентного програмування
- •2.4.2. Моделі компонентного програмування
- •2.4.3. Графове подання компонентної моделі ПрО
- •2.4.4. Об’єднання компонентів. Модель середовища
- •2.4.5. Компонентна алгебра
- •2.4.6. Іінструментальні засоби кп
- •2.4.7. Технологія компонентної розробки пс
- •2.4.8. Типізація і класифікація програмних компонентів
- •2.4.9. Жц проектування пс із типових компонентів та кпв
- •Розробка вимог до пс – це формування та опис функціональних, технологічних, організаційних та ін. Властивостей програмної системи, які необхідні чи бажані з точки зору кінцевого користувача.
- •Розгортання рпс. У випадку, коли рпс створюється для конкретного замовника, який є і користувачем, то деякі завдання розгортання виконуються на попередніх етапах. До них, зокрема, відносяться:
- •Супровід рпс компонентній пс характеризується наступними особливостями.
- •2.5. Парадигма аспектно-орієнтованого програмування
- •2.5.1.Основні елементи парадигми аоп
- •2.5.2. Засоби аоп
- •2.5.3. Підтримка аоп впродовж життєвого циклу пс
- •2.5.5. Методичні аспекти аоп
- •2.6. Парадигма генерувального програмування
- •2.6.1 Предметно-орієнтована мова – dsl
- •2.6.2. Простір проблем і рішень ПрО
- •2.6.3. Інженерія ПрО і кпв
- •2.7. Сервісно-орієнтоване програмування
- •2.7.1 Базові понятті сервісу Інтернет
- •2.7.2. Сервіси wcf мs.Net з контрактами
- •2.8. Парадигми теоретичного програмування
- •2.8.1 Алгебраїчне та інсерційне програмування
- •2.8.2. Реалізація агентних програм
- •2.8.3. Експлікативне, номінативне програмування
- •2.8.4. Алгоритмічні алгебри
- •Контрольні питання і завдання до частини 2
- •Список літератури до частини 2
- •Частина 3. Моделі і засоби проектування предметних областей
- •3.1. Моделі проектування ПрО предметних областей
- •3.1.1. Концептуальні моделі пс, спс за компонентами
- •3.1.2. Моделі взаємозв’язку об’єктів
- •3.1.3. Модель інтеграції (зборка) компонентів
- •3.1.4. Тестування прикладних і інтерфейсних об'єктів
- •3.1.5. Моделі взаємодії і варіабельності пс для організації обчислень
- •3.1.6. Підхід до виконання пс в сучасних розподілених середовищах
- •3.2. Онтологічний підхід до подання знань про проблемні області
- •3.2.1. Онтологічне моделювання проблемної області
- •3.2.2. Мовний опис онтології домену чи спс
- •3.2.3. Підхід до реалізація онтології ПрО
- •3.3. Типи даних та засоби їх генерації для використання в збиральному прогрмуванні
- •3.3.1. Проблема забезпечення сумісності типів даних при зборки кпв
- •3.3.2. Аксіоматика простих типів даних
- •3.3.3. Аксіоматика структурних і складних типів даних. Структурні типи даних.
- •3.3.4. Семантичні аспекти взаємодії різнорідних програм
- •3.3.5. Характеристика типів даних для зборки програм
- •3.3.6. Фундаментальні і загальні типи даних
- •3.3.6. Баові поняття стандарту з типів даних
- •3.3.7. Перебудова загальних типів даних до фундаментальних для мп
- •3.4. Підходи і методи доказу програм
- •3.4.1. Мови специфікації програм –vdm, raise, Concept
- •3.4.2. Концепторна мова специфікації
- •3.4.3. Методи доведення правильності програм
- •3.4.4. Модель доказу програми за твердженнями
- •З.5. Проектування пс засобами жц з реалізації доменів
- •3.4.1. За загальна характеристика стандарту жц iso/iec 12207:2002
- •3.4.2. Формування конкретних моделей життєвого циклу
- •3.4.3. Підходи до моделювання ПрО мовними засобами dsl
- •3.6. Модель якості пс
- •3.6.1. Структура моделі якості
- •3.6.2. Модель витрат сосомо Боєма
- •3.6.3. Інтегрована модель витрат на спс
- •Контрольні питання і завдання до частини 3
- •Список літератури до частини 3
- •4.1.1. Моделі взаємодії компонентів у пс
- •Частина 4. Методи індустрії виробицтва програм і систем
- •4.1. Загальні основи методології виробництва пс і спс
- •4.1.2 Методологічні аспекти виробництва спс з готових ресурсів
- •4.2. Мова опису моделей взаємодії на основі xml
- •4.2.1 Подання та обмін даними в компонентних моделях
- •4.2.3 Модель конфігурації компонентів на основі xml
- •4.3. Графове подання пс і спс
- •4.3.1 Графове визначення моделі взаємодії об'єктів
- •4.3.2 Типи зв’язків об’єктів у графової моделі ПрО
- •4.4. Розробка методів побудови проблемно-орієнтованих технологій
- •4.4.1. Аналіз динаміки розвитку фабрик програм
- •4.3.2. Базисні ресурси фабрики програм
- •4.5. Загальні лінії виробництва програм з кпв
- •4.4.1. М етодологія побудови тл
- •4.4.2. Нові дисципліни індустрії наукового совтвера
- •4.4.3. Новітні засоби Grid і Cloud для обчислення задач e–sciences
- •4.4.4. Сучасні системи побудови рпс з сервісних ресурсів
- •4.4.5. Методологія розроблення тл
- •4.4.6. Принципи проектування іс
- •4.5. Методи при оцінюванні економічних характеристик проектів
- •4.5.2. Формальний апарат експертно-аналітичного оцінювання об’єктів і процесів у спс
- •4.5.3. Методи оцінки розміру
- •4.6. Створення Windows застосувань
- •4.6.1. Створення нової програми.
- •4.6.2. Властивості і дизайн програм
- •4.6.3. Компіляція програм
- •2.5. Запуск застосунка
- •4.6.4. Розширення функціональності програм
- •4.7. Інженерії тестування програмних систем
- •4.7.1. Основні поняття інженерії тестування
- •4.7.2 Становлення інженерії тестування
- •4.7.3. Методи тестування. Метрики і критерії
- •4.7.4. Інструменти тестування та оцінювання
- •4.7.5. Тестування веб-застосувань
- •Контрольні питання і завдання до частини 4
- •Список літератури до частини 4
- •5.2. Фабрика програм в кну
- •5.2.3. Створення фабрики студентів
- •5.2.4. Лінії продуктів фабрики на головної сторінки
- •5.2.5. Принципи роботи з репозиторієм програм і артефактів
- •5.2.6. Навчання дисципліні “Програмна інженерія” на фабрики
- •5.3. Репозиторій кпв
- •5.3.1. Загальний опис репозиторію
- •5.3.2. Технологія обслуговування репозиторію кпв
- •5.4. Розробка кпв
- •5.4.1. Опис моделей кпв, інтерфейсу і операцій розробки кпв
- •5.4.2. Реалізація побудови компонентної системи
- •5.4.3. Процеси технології оброблення кпв
- •5.4.4. Зборка різномовних програм у середовищі Visual Studio
- •5.5. Конфігурація кпв
- •5.5.1. Конфігурування кпв з урахуванням варіабельності
- •5.5.2. Опис прикладу використання конфігуратору програм
- •5.6. Генерація систем мовою dsl
- •5.6.1. Лінія опису та генерації доменів dsl
- •5.6.2. Опис життєвого циклу пз та його реалізації на мові dsl
- •2.7. Онтологія – обчислювальна геометрія
- •5.7.1. Онтологія домену – Обчислювальна геометрія
- •5.7.3. Опис моделі онтології ПрО «Обчислювальна геометрія»
- •5.7.4. Опис програми домену «Обчислювальна геометрія» мовою owl
- •5.8. Оцінка якості пс
- •5.8.2. Оцінка витрат на продукт
- •5.8.3. Опис модуля прогнозування трудовитрат на розробку пс
- •5.8.4. Приклад оцінювання затрат на розробку пс ас
- •5.9.1. Опис веб-технології Java ee
- •5.9.3. Приклад взаємодії Java і ms.Net через веб-сервіси
- •5.9.4. Інструкція по використанню графічного інтерфейсу прикладу
- •5.10. Генерація тд
- •5.10.1. Відображення типів даних у середовищі ітк
- •5.10.2. Система генерації загальних типів даних до фундаментальних
- •5.11. Інструментальні засоби сайта ітк
- •5. 12. Розділ сайта «Технологія навчання»
- •Контрольні питання і завдання до частини 5
- •Список літератури до частини 5
- •Післямова
- •Додаток 1. Парадигма структурного програмування
- •Додаток 2. Приклад створення служб wcf у ms Visual Studio 2010
- •Додаток 3. Онтологічний підхід з подання тестування кпв та пс
- •Додаток 4. Оцінка застосування метода сосомо на конкретних даних
- •Додаток 5. Програма курсу «Технологія програмування іс»
4.7.3. Методи тестування. Метрики і критерії
Методи тестування відрізняються підходами до вибору множини тестових даних із вхідного простору тестовуваних функцій. Кожний метод надає відповідний критерій покриття набором тестів вхідного простору.
Традиційна класифікація методів тестування базується на їхньому розділенні на дві категорії – «чорна скрінька» (функціональне) і «біла скрінька» (структурне) [20, 21, 24] – і враховує лише два підходи до проектування тестів. Сучасна класифікація методів тестування, заснована на підходах до проектування тестів.
Вибір найбільш ефективних методів тестування за певних умов та на різних рівнях тестування є складною проблемою та пов’язаний з аналізом ризиків відмов ПС.
Метрики тестування. Виміри в програмній інженерії мають велике значення, оскільки їх використання дозволяє одержувати об’єктивну інформацію щодо стану ПС та процесів розроблення. Рекомендований склад метрик наведено в стандарті ISO/IEC 9126.
Оскільки основними процесами, які зазвичай досліджуються в інженерії якості та надійності, є процеси “внесення помилок”, “усунення дефектів” та “процес виникнення відмови”, основними метриками вважаються “кількість дефектів”, “щільність дефектів” та “інтенсивність відмов”.
Кількість дефектів, виявлених тестуванням, не можна вважати хорошим індикатором якості ПС, вони більшою мірою слугують індикаторами ефективності тестування [29]. В той же час, невелика кількість дефектів, виявлених під час тестування, не є індикатором поганого тестування, а може свідчити про ефективність процесу розробки. Об’єктивним індикатором ефективності тестування є відношення:
Ee = De / De +Do
де Ee – ефективність тестування, De – кількість дефектів, виявлених під час тестування, Do – кількість дефектів, виявлених при експлуатації.
На жаль цей індикатор не можна використовувати для керування процесом тестування, оскільки значення Do можна отримати надто пізно.
Реєстрація дефектів повинна бути однією з цілей процесу тестування, вона, також, визначена як обов’язкова вимога базового стандарту з якості ISO 9000–3. Реєстрація дефектів слугує основою для формування банків історичних еталонних даних по програмних проектах, які можуть використовуватися для вдосконалювання процесів програмної інженерії. Аналіз даних про щільність дефектів в програмних продуктах дозволив визначити середній показник щільності дефектів – 6 дефектів на 1000 рядків для США і Європи, 2 – для Японії [2].
Крім цих базових метрик для вимірювання результатів тестування корисними є такі метрики:
метрики оцінювання набору тестів відповідно до обраного критерію покриття, як от метрики покриття тестових вимог, коду чи функцій;
метрики тенденцій дефектів (знайдених, усунутих, по серйозності, пріоритету тощо).
Крім того, для ефективного керування процесом тестування важливими метриками є час і вартість тестування.
Щодо практичного використання метрик для керування процесом тестування існує декілька проблем, а саме:
збирання початкових даних для обчислення метрик;
інтерпретація результатів розрахунку та ступінь довіри до них;
яким чином використовувати метрики для керуванням тестуванням на кожному рівні;
вибір мінімальної множини метрик, прийнятних в контексті певного процесу тестування.
Метрики для включення в процес тестування повинні вибиратися таким чином, щоб слугувати об'єктивними індикаторами стану виконання процесу тестування і поточного стану ПС.
Критерії завершення тестування. Об’єктивні критерії завершення тестування ґрунтуються на кількісних вимірах, які поділені по чотирьох категоріях:
критерії, базовані на метриках покриття;
критерії, базовані на серйозності дефектів;
критерії, базовані на оцінках інтенсивності відмов та надійності;
критерії оптимізації вартості, часу тестування та надійності.
У першому підході критерії підрозділяють на структурні та функціональні. Ці критерії є індикатором повноти виконаного тестування, але не враховують час, витрачений на тестування. Тестування припиняють при досягненні граничних значень.
Критерії другої категорії базуються на розподілі виявлених дефектів за ступенем серйозності та встановленні граничних значень кількості усунутих дефектів з урахуванням їхньої серйозності. Тестування припиняють, якщо усунені всі найбільш серйозні дефекти і визначена кількість дефектів інших типів серйозності. Ці критерії не враховують час, витрачений на тестування та усунення дефектів.
В критеріях третьої категорії, базованих на оцінках інтенсивності відмов та надійності, тестування продовжують до тих пір, поки не будуть досягнуті встановлені граничні значення метрик надійності (інтенсивність відмов, середній час функціонування без відмови, або ймовірність безвідмовної роботи). Ці критерії не враховують наслідки відмов, а лише їх ймовірність.
Критерії оптимізації (четверта категорія) спрямовані на пошук “компромісу” між часом тестування та вимогами до якості. Ці критерії базовані на використанні моделей надійності за визначенням оптимального часу тестування.
Нехай С1 – вартість усунення однієї відмови під час розроблення та тестування; С2 – вартість усунення відмови при експлуатації, С2>С1; С3 – вартість одиниці часу тестування (наприклад, одного дня), te – час тестування, (te) – інтенсивність відмов ПС при експлуатації за умови, що тестування здійснювалося протягом часу te; (te) – функція зростання надійності.
Тоді повна вартість тестування та усунення дефектів при експлуатації за умови, що ПС тестується час te – є сума:
де
– витрати на усунення відмов при
тестуванні;
– витрати на пошук та усунення відмов
при експлуатації, де y
–очікуваний час експлуатації;
– витрати на тестування.
Знаходження часу тестування te* , при якому повна вартість усунення дефектів під час тестування та експлуатації буде мінімальною,
te* = {t: D(T/t) D(T/te*), 0 t tmax },
де tmax – максимально допустимий час тестування.
Згідно цього критерію тестування може бути завершеним, якщо:
всі заплановані функціональні тести пройшли;
структурне тестування було виконано набором тестів, який забезпечує 100% покриття рядків коду, 80% покриття логічних умов і 100% покриття викликів процедур;
інтенсивність виявлення відмов не вище 40 нових відмов на 1000 годин тестування;
тривалість безперервного функціонування ПС без відмови досягає 100 годин.
В умовах обмежених ресурсів на тестування критерій завершення повинен встановлюватися, виходячи з оцінок ризику відмови ПС. Він має враховувати, які ідентифіковані ризики усунені шляхом тестування, і якою є серйозність дефектів, що залишилися.
