- •VIII. Розробка інтернет-програм
- •IX. БдБ і БдС системи
- •X. Реалізація
- •XI. Тестування
- •Введення в розробку програмного забезпечення
- •1. Складність інформаційних систем
- •2. Розробка програмного забезпечення
- •Криза програмного забезпечення
- •4.Концептуальне моделювання
- •Життєві цикли програмного забезпечення
- •Модель водоспаду
- •2. Модель водоспаду із зворотнім зв'язком
- •Документоване виконання
- •Прототипування
- •Покрокова розробка
- •7.Модель спіралі
- •III. Етапи розробки програмного забезпечення
- •1. Стратегічний етап
- •Етап визначення вимог
- •2.2. Нефункціональні вимоги
- •4. Етап проектування
- •5. Етап реалізації
- •6. Етап тестування
- •7. Етап установки
- •8. Етап підтримки
- •IV. Стратегічний етап
- •1. Дії на стратегічному етапі
- •2. Співпраця з клієнтом
- •3. Область дії і контекст проекту
- •4. Стратегічні рішення
- •5. Оцінка різних варіантів рішеннь
- •6. Оцінка вартості рішень
- •7. Чинники успіху
- •8. Результати стратегічного етапу
- •9. Короткий звіт
- •V. Розпізнавання вимог і документація
- •1. Складнощі у формулюванні вимог
- •2. Методи ідентифікації вимог
- •3. Методи опису вимог
- •4. Типи вимог
- •5. Перевірка вимог
- •6. Документ з вимогами
- •2. Аналітична модель
- •3. Дії на етапі аналізу
- •4. Функціональна декомпозиція
- •5. Методологія, що використовується в створенні аналітичної моделі
- •6. Документація вимог
- •7. Аналіз чинників успіху
- •8. Короткий звіт
- •VII. Етап проектування
- •1. Цілі проектування
- •Малюнок 7.2.1. Етап проектування.
- •2. Специфікація результатів аналізу
- •3. Дизайн інтерфейсу
- •4. Структуровані схеми/діаграми
- •5. Складова організації даних
- •6. Оптимізація проекту
- •7. Фізична структура системи
- •8. Правильність і якість проекту
- •9. Нефункціональні вимоги на етапі проектування
- •10. Результати етапу проектування
- •11. Детальний документ проекту
- •2. Стандарти, правила і порядок здійснення дій проекту:
- •12. Короткий звіт
- •VIII. Розробка інтернет-програм
- •1. Специфікація інтернет-програми
- •2. Методи розробки інтернет-програм
- •3. Об'єктно-орієнтована гіперсередовищна модель розробки (oohdm)
- •4. Метод розробки веб-сторінок (wsdm)
- •5. Мова веб-моделювання (WebMl)
- •Формулювання вимог
- •Проект структури даних
- •Гіпертекстовий проект
- •IX. Бдб і бдс системи
- •1. Електронний бізнес
- •2. Інтернет-бізнес і електронний ринок.
- •3. Інтернет-магазин
- •4. Модель електронного бізнесу
- •1.Модель брокера
- •2.Модель, яка задовольняє індивідуальним потребам
- •3.Модель контактів
- •5. Платежі
- •6. Безпека
- •8. Моделювання систем бдб і бдс
- •9. Багатошарова архітектура програм
- •9. Cервіс-орієнтована архітектура (соа)
- •10. Короткий звіт
- •X. Реалізація
- •1. Характеристики етапу реалізації
- •2. Надійність програмного забезпечення
- •3. Похибка
- •4. Транзакції
- •5. Середовище реалізації
- •6. Чинники успіху і результати етапу реалізації
- •7. Короткий звіт
- •XI. Тестування
- •1. Етап тестування
- •2. Перевірка
- •Малюнок 11.3.1. Модель V-тестування.
- •3. Перегляди
- •4. Аудит
- •5. Інспекції
- •6. Види тестів
- •7. Процес тестування
- •8. Тестування надійності
- •9. Типи тестів на знаходження помилок
- •10. Програми-інструменти
- •11. Статичні тести
- •12. Підрахунок кількості помилок
- •13. Чинники успіху, успіх тестування
- •14. Короткий звіт
- •XII. Оцінка програмного забезпечення
- •1. Простановка розмірів проекту
- •2. Оцінка складності в проектах
- •3. Ефекти масштабування
- •4. Оцінка вартості програмного забезпечення
- •5. Конструктивна вартісна модель (cocomo)
- •6. Балова функціональна оцінка
- •7. Метод випадкового використання
- •8. Короткий звіт
- •XIII. Управління конфігурацією пз і версіями
- •1. Управління конфігурацією пз
- •2. Елементи конфігурації пз
- •3. Угода позначень
- •4. Зберігання елементів конфігурації
- •5. Перегляди
- •7. План управління конфігурації пз
- •I Вступ
- •II Управління
- •III Визначення конфігурації
- •IV Управління конфігурацією
- •4. Модель якості iso-9126
- •5. Управління якістю
- •6. Стандарти якості
- •7. Незрілість і зрілість виробництва
- •8. План гарантії якості пз (sqap)
- •9. Короткий звіт
- •XV. Управління проектом програмного забезпечення
- •1. Завдання управління проектом
- •2. Працівники виробництва програмного забезпечення
- •3. Характеристика хорошого розробника програмного забезпечення
- •4. Робота в команді
- •5. Управління підприємством по виробництву програмного забезпечення
- •6. Розвиток компанії по розробці програмного забезпечення
- •7. Документація проекту
- •8. Визначення продуктивності
- •9. Складання графіків проекту
- •10. Завдання управління проектом
- •11. Інтерфейс проекту
- •12. Планування проекту
- •13. Управління ризиком
- •14. Вимірювання процесів і продуктів
- •15. Короткий звіт
8. Тестування надійності
Міри надійності
Надійність дуже важлива. Але як її вимірювати? Як порівняти два продукти з точки зору надійності?
Заходи надійності слід визначити. Вимагати надійність немає сенсу, якщо цього не зробити.
Нижче ми наводимо деякі приклади вимірювань надійності:
Міра 1
Мірою є вірогідність помилки при виконанні транзакції. Кожна визначена помилка припиняє транзакцію. Формальна міра - частота таких помилок.
Міра 2
Міра - частота операцій з помилками за одиницю часу. Вона використовується в системах, де немає транзакцій. Наприклад, 0.1/ч означає, що на годину кількість очікуваних помилок дорівнює 0.1.
Міра 3
Мірою є доступність, тобто вірогідність того, що в конкретний момент часу система доступна для виконання завдання. Вона обчислюється як відношення часу, коли система доступна, до часу, необхідного для відновлення після помилки (від появи до усунення помилки). Міра враховує помилкові операції і час, витрачений з їх причини.
Оцінка надійності
Рівень надійності (значення якоїсь міри) визначається вимогами клієнта. Але це у великій мірі відображається в якісній формі, що робить перевірку складною.
Оцінка важлива навіть якщо клієнт не зазначив її у вимогах. Наприклад, зусилля на підтримку можуть значно зменшиться якщо надійність враховуватиметься при спорудженні системи.
Надійність дозволяє оцінити витрати на обслуговування, персонал, телефонні дзвінки, загальну вартість послуг.
Оцінка надійності дозволяє оцінити і поліпшити процес виробництва з точки зору мінімізації витрат на виробництво, підтримку, успіху на ринку і репутації компанії.
Підвищення надійності ПЗ
Мета знаходження помилок полягає в їх виправленні. Якщо цей процес не додасть нових помилок, надійність підвищується. У разі статистичних тестів, покращення визначається за формулою:
Надійність = Надійність_початкова * e (-C * Кількість_тестів)
Міра надійності - частота помилок в операціях. Константа C залежить від системи. Для знаходження С може бути використаний метод найменших квадратів, грунтуючись на надійності спостережень. Надійність можна підвищити, якщо дані,які тестуються вибираються з не тестованих раніше.
9. Типи тестів на знаходження помилок
Динамічні тести класифікують як:
-
Функціональні тести (тестування методом чорного ящика) враховують тільки вимоги.
Система розглядається як чорний ящик, виконуючи свої функції невідомим чином. Тестування повинні проводити персони, що не приймали участі у виробництві тестованих частин.
-
Структурні тести (тестування методом прозорого ящика) враховують механізми реалізації.
Функціональні тести
Повне тестування системи неможливе, оскільки кількість можливих комбінацій вхідних даних дуже велика. Це справедливо навіть для маленьких систем, на тестування яких пішли б роки.
Зазвичай вважається, що якщо функція працює при одних типах даних, то вона працюватиме при всіх. Але це велика помилка, гарантії якому немає.
Дані групуються, що вводяться, відповідно до опису вимог. Наприклад:
Рахунок, менший 1000 грн, повинен бути схвалений супервізором.
Рахунок, більший 1000 грн, повинен бути схвалений президентом.
Така вимога розділяє дані на два класи. Хоча тестування, наприклад, одного значення для кожного класу недостатньо. Граничні умови теж слід перевірити.
Вибух тестованих даних
Приклад демонструє, що тестування повинно проводитися, принаймні, п'ятьма значеннями: 0, 500, 1000, 1500 і максимальним. Якщо кількість таких значень дуже велика, ми застосовуємо комбінаторний вибух для тестових значень. Дані діляться на класи еквівалентності, які враховують елементарні умови. Наприклад, якщо ці умови доповнюються наступними:
Супервізор може схвалити місячний рахунок в 10000 грн. Кожен рахунок, що перевищує цю суму, повинен схвалюватися президентом. Наступні класи також можуть бути враховані в даних, що вводяться: рахунок до 1000 грн; рахунок до 1000 грн; рахунок більше 1000 грн, що не перевищує 10000 грн; рахунок більше 1000 грн, що перевищує 10000 грн;
Врахування цих граничних випадків приводить до збільшення випадків тестування: (0,500,1000, 1500, max) x (<10000, 10000, >10000).
На практиці тестування всіх граничних значень (навіть обмежених типовими і крайніми) неможливе. Повинні бути обрані характерні випадки. Рекомендується враховувати наступне:
-
Вірогідність виконання функції важливіша за її якість.
-
Функції попередньої версії важливіші, ніж нові. Користувачі будуть незадоволені, якщо їх функція в новій версії перестане працювати.
-
Типові ситуації важливіші, ніж виняткові випадки, - помилка у перших буде більш значуща, ніж в других.
Структурні тести
У разі структурних тестів дані вибираються на основі аналізу структури системи, і їх критерії наступні:
-
Критерій покриття всіх функцій. Відповідно до цього критерію, вибір вхідних даних, повинен дати виконатися функціям хоча б один раз. Для задоволення критерію нам не потрібна велика кількість тестів. Критерій не дуже ефективний.
if x > 0 then begin end; y:=ln(x);
-
Критерій покриття всіх виключень умов. Вхідні дані, повинні вибиратися так, щоб кожна умова виконалася хоча б раз або не виконалася. Граничні умови також слід перевірити. У даному прикладі ця вимога дозволяє знайти помилку у випадках if x=0 or x<0.
Можуть бути задіяні вимогливіші критерії.
Тестування програм з циклами
Крітерий вибору даних грунтується на наступних припущеннях:
Дані повинні бути такими, щоб виконалося 0 циклів, мінімальна кількість циклів, максимальна і середня.