Дерево несправностей

Безпека ПЗ

Стресове тестування

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

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

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

Слід зазначити, що безпека і надійність - не одне і те ж. Ненадійна система може бути безпечна, якщо наслідки помилок не небезпечні.

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

До помилок ПЗ потрібно відносити і помилки апаратури. Безпека повинна враховувати обидва аспекти.

Безпека ПЗ повинна враховуватися, в першу чергу, з точки зору таких загроз, як смерть, втрата здоров'я, фінансові втрати, невідповідність юридичним нормам і т.д.

Наприклад, в програмі податкової декларації можуть трапитися наступні помилки:

· неправильний підрахунок податку,

· нестача податкових декларацій,

· податкові декларації, що повторюються.

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

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

Приклад дерева несправностей зображений на малюнку 11.13.1.

Рисунок 11.13.1. Приклад дерева несправностей.

Методи зменшення наслідків загрози

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

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

13. Чинники успіху, успіх тестування

Не можна протестувати все ПЗ. Тому успіх тестування сильно залежить від визначення найвимогливіших до надійності частин програми і уважного вибору даних.

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

Головними результатами тестування є правильні код, проект, модель і звіт про проведення тестів з їх результатами. Результат також повинен містити оцінку надійності і витрат на підтримку.

14. Короткий звіт

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

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

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

XII. Оцінка програмного забезпечення

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

1. Простановка розмірів проекту

Простановка розмірів IT-проекту стала одним з найголовніших етапів розробки програмного забезпечення. Завдання - оцінити компактність проекту, вартість виробництва і інсталяції системи.

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

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

Міра визначає міру-постулат. Міра не обов'язково повинна добре характеризувати атрибут. Наприклад, число рядків є мірою, але вона не вимірює складність і розмір програми.

Питання, на яке слід у такому разі відповісти: що вимірювати?

Три проектні об'єкти можуть бути виміряні: процеси, продукти і ресурси.

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

Програма - предмет, виготовлений процесом: початковий код, специфікація проекту, документована модифікація, плани тестування, документація і т.п.

Ресурс - будь-який елемент, потрібний для процесу: людина, методи виробництва і т.п.

Нижче представлені вимірювання типового процесу, продуктів і ресурсів.

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

Читайте також:

<== попередня сторінка	\|	наступна сторінка ==>
Компаратор	\|	Ресурси

Не знайшли потрібну інформацію? Скористайтесь пошуком google:

Генерація сторінки за: 0.01 сек.