МАРК РЕГНЕРУС ДОСЛІДЖЕННЯ: Наскільки відрізняються діти, які виросли в одностатевих союзах
РЕЗОЛЮЦІЯ: Громадського обговорення навчальної програми статевого виховання ЧОМУ ФОНД ОЛЕНИ ПІНЧУК І МОЗ УКРАЇНИ ПРОПАГУЮТЬ "СЕКСУАЛЬНІ УРОКИ" ЕКЗИСТЕНЦІЙНО-ПСИХОЛОГІЧНІ ОСНОВИ ПОРУШЕННЯ СТАТЕВОЇ ІДЕНТИЧНОСТІ ПІДЛІТКІВ Батьківський, громадянський рух в Україні закликає МОН зупинити тотальну сексуалізацію дітей і підлітків Відкрите звернення Міністру освіти й науки України - Гриневич Лілії Михайлівні Представництво українського жіноцтва в ООН: низький рівень культури спілкування в соціальних мережах Гендерна антидискримінаційна експертиза може зробити нас моральними рабами ЛІВИЙ МАРКСИЗМ У НОВИХ ПІДРУЧНИКАХ ДЛЯ ШКОЛЯРІВ ВІДКРИТА ЗАЯВА на підтримку позиції Ганни Турчинової та права кожної людини на свободу думки, світогляду та вираження поглядів Контакти
Тлумачний словник |
|
|||||||
Дерево несправностейБезпека ПЗ Стресове тестування Стресове тестування проводиться для того, щоб оцінити надійність і продуктивність в стресових умовах. Це застосовується, в основному, до мережевих систем і систем множинного доступу. Тести на міцність перевіряють продуктивність у разі несподіваних подій, як відключення електрики, помилка устаткування, введення невірних даних або неправильної послідовності комманд. Деякі системи вважаються критично важливими відносно безпеки людини. До них відносяться: медичне устаткування, устаткування контролю літаком і т.д. Загроза може бути непрямою, як у випадку з прийняттями рішень в медицині. Слід зазначити, що безпека і надійність - не одне і те ж. Ненадійна система може бути безпечна, якщо наслідки помилок не небезпечні. Системні вимоги можуть бути неповними і не описувати всіх випадків. Це відноситься до вхідних даних. Для системи важливо працювати правильно навіть у разі введення невірних даних. До помилок ПЗ потрібно відносити і помилки апаратури. Безпека повинна враховувати обидва аспекти. Безпека ПЗ повинна враховуватися, в першу чергу, з точки зору таких загроз, як смерть, втрата здоров'я, фінансові втрати, невідповідність юридичним нормам і т.д. Наприклад, в програмі податкової декларації можуть трапитися наступні помилки: · неправильний підрахунок податку, · нестача податкових декларацій, · податкові декларації, що повторюються. Кожна загроза повинна бути оцінена і класифікована. Для кожної з них повинно бути ухвалене рішення з розглядом найбільш можливих наслідків, а ризик повинен бути мінімізований. Дерево несправностей - один з інструментів, який використовується в оцінці потенційних помилок. Корінь такого дерева - одна з небезпечних ситуацій. Його вузли - проміжні ситуації, які ведуть до вузла вищого рівня. Приклад дерева несправностей зображений на малюнку 11.13.1. Рисунок 11.13.1. Приклад дерева несправностей.
Методи зменшення наслідків загрози Ми можемо зменшити загрози шляхом обережної і уважної реалізації частин системи, які можуть призвести до загроз. Розробку найважливіших частин системи слід доручити досвідченішим програмістам. Також можна написати і порівняти декілька версій важливих частин програми після тестурвання. Потрібно на початках враховувати всі ситуації, які можуть призвести до загроз, і прийняти заходи уникнення їх шляхом посилання повідомлень користувачеві. 13. Чинники успіху, успіх тестування Не можна протестувати все ПЗ. Тому успіх тестування сильно залежить від визначення найвимогливіших до надійності частин програми і уважного вибору даних. Мотивація команди тестувальників також дуже важлива. Слід враховувати цінність знаходження найнебезпечніших помилок. Головними результатами тестування є правильні код, проект, модель і звіт про проведення тестів з їх результатами. Результат також повинен містити оцінку надійності і витрат на підтримку. 14. Короткий звіт Тестування - процес, який повинен виконуватися в ході всього процесу розробки. Хоча найважливіша частина починається тоді, коли реалізація завершується. Тестування - робота важка і така, що вимагає досвіду. Тестувальник повинен бути відповідальним і обережним. Тест повинен бути добре спланований, а дані - вірно вибрані. Дуже затягнуте тестування може не принести результатів. Тому вибір хорошого плану тестування дуже важливий. Добре розроблений тест дозволяє знайти помилки, удосконалити програму, оцінити надійність і витрати на підтримку. XII. Оцінка програмного забезпечення Оцінка програмного забезпечення, експлуатація ресурсів, складність, необхідний час для розробки програмного забезпечення і т.п. є важливим і важким завданням. Немає ніяких критеріїв ідеального програмного забезпечення. 1. Простановка розмірів проекту Простановка розмірів IT-проекту стала одним з найголовніших етапів розробки програмного забезпечення. Завдання - оцінити компактність проекту, вартість виробництва і інсталяції системи. Обчислення відбувається шляхом визначення відповідних числових і символічних мір для кількісної оцінки. Теоретично, проставляння розмірів застосовується до будь-якого модуля, як, наприклад, подія, людина, процес розробки або програма в розробці програмного забезпечення. Вимірювання - процес, в якому значення або символи привласнюються частинам реального світу згідно певним правилам. Вибрані одиниці вимірювання - це міри атрибутів. Міра визначає міру-постулат. Міра не обов'язково повинна добре характеризувати атрибут. Наприклад, число рядків є мірою, але вона не вимірює складність і розмір програми. Питання, на яке слід у такому разі відповісти: що вимірювати? Три проектні об'єкти можуть бути виміряні: процеси, продукти і ресурси. Процес визначає дії в проекті, створення і експлуатацію програмного забезпечення. Програма - предмет, виготовлений процесом: початковий код, специфікація проекту, документована модифікація, плани тестування, документація і т.п. Ресурс - будь-який елемент, потрібний для процесу: людина, методи виробництва і т.п. Нижче представлені вимірювання типового процесу, продуктів і ресурсів. Другий стовпець показує приклади атрибутів, третій стовпець показує характеристики, отримані від прямих вимірювань.
Читайте також:
|
||||||||
|