МАРК РЕГНЕРУС ДОСЛІДЖЕННЯ: Наскільки відрізняються діти, які виросли в одностатевих союзах
РЕЗОЛЮЦІЯ: Громадського обговорення навчальної програми статевого виховання ЧОМУ ФОНД ОЛЕНИ ПІНЧУК І МОЗ УКРАЇНИ ПРОПАГУЮТЬ "СЕКСУАЛЬНІ УРОКИ" ЕКЗИСТЕНЦІЙНО-ПСИХОЛОГІЧНІ ОСНОВИ ПОРУШЕННЯ СТАТЕВОЇ ІДЕНТИЧНОСТІ ПІДЛІТКІВ Батьківський, громадянський рух в Україні закликає МОН зупинити тотальну сексуалізацію дітей і підлітків Відкрите звернення Міністру освіти й науки України - Гриневич Лілії Михайлівні Представництво українського жіноцтва в ООН: низький рівень культури спілкування в соціальних мережах Гендерна антидискримінаційна експертиза може зробити нас моральними рабами ЛІВИЙ МАРКСИЗМ У НОВИХ ПІДРУЧНИКАХ ДЛЯ ШКОЛЯРІВ ВІДКРИТА ЗАЯВА на підтримку позиції Ганни Турчинової та права кожної людини на свободу думки, світогляду та вираження поглядів Контакти
Тлумачний словник |
|
|||||||
Аудит проекту розробки ПЗАудит Аудит Перегляди Малюнок 11.3.1. Модель V-тестування. Модулі тестування - тестуються окремі частини, щоб упевнитися в правильності. Кожен елемент тестується окремо. Модулі тестуються окремо один від одного. Модуль - безліч незалежних компонентів (процедур і функцій). Тестування цілісності полягає в перевірці інтерфейсів між модулями. Тестування системи. Система - це безліч підсистем. Тестування повинне знайти всі помилки взаємодії підсистем. Також перевіряється, чи відповідає система вимогам. Тестування прийнятності системи - останній етап, який виконується перед доставкою системи користувачеві. Система тестується даними користувача, а не розробника. Перегляд - процес або зустріч, на якій продукт оцінюється персоналом, супервізорами, користувачами, клієнтами і рештою осіб, що мають до нього відношення. Їх думки і рішення про ухвалення визначать майбутнє проекту. Перегляди можуть бути формальними і неформальними. Формальні: технічний, наскрізний контроль, аудит. Технічний перегляд Технічний перегляд - перевірка на відповідність елеметов ПЗ роботі за розкладом (подробиці можна знайти в ANSI/ IEEE Std 1028 -1988 "Стандарти IEEE для переглядів і аудитів"). Наскрізний контроль Наскрізний контроль - попереднє оцінювання документів, моделей і проектів. Мета - визначити дефекти і надати варіанти рішення. Друге завдання - вирішення проблем із стилем (наприклад, з формою коду, документація, інтерфейсами). Аудит - це вид наскрізного контролю, який перевіряє, чи відповідає ПЗ вимогам, специфікаціям, рекомендаціям, стандартам, процедурам, умовам контрактів і ліцензіям. Об'єктивність аудиту вимагає незалежних експертів-професіоналів. Команда по оцінці ПЗ Оцінка ПЗ - дуже важливе питання, яке повинне вирішуватися професіоналами. Потрібно вибрати команду професіоналів, яка підготує і проведе тести. У тестуванні приймають участь наступні персони: супервізор, секретар, члени команди, серед яких є представники користувачів, супервізор проекту розробки ПЗ, розробники ПЗ, бібліотекар ПЗ, персонал гарантії якості проекту, незалежний персонал перевірки і незалежні експерти. Супервізори команд мають наступні завдання: номінування членів команд, організація зустрічей, процес оцінювання, організація роботи, редагування кінцевих документів і, можливо, інші завдання. Аудит - незалежний перегляд і оцінка ПЗ. Він перевіряє, чи відповідає ПЗ вимогам специфікаціям, рекомендаціям, стандартам, процедурам, умовам контрактів і ліцензіям. Об'єктивність аудиту вимагає незалежних експертів-професіоналів. Аудіювання повинне проводитися аудитною групою або персонами з ліцензіями. Правила визначає стандарт ANSMEEE Std 1028-1988 IEEE - стандарт для переглядів і аудиту. Мета аудиту - отримати цілі і інформацію про проекту. Слід оцінювати ресурси, компетенцію і методи, які важливі для досягнення проміжних і повного успіхів.Ця інформація важлива для ухвалення стратегічних рішень. Суб'єкти і перспективи аудиту Суб'єктами аудиту можуть бути процеси або продукти проекту (можуть і обидва). Мета аудиту процесу - перевірити, чи правильно виконується робота, її відповідність принципам і стандартам. Мета аудиту продукту (проміжного або кінцевого) - перевірити, чи відповідає він вимогам і очікуванням. Команда аудиту може застосовувати різні способи перевірки. Технічні аспекти можуть перевірятися для оцінки технічних рішень і як вони застосовані. Аспекти менеджменту можуть бути проаудийовані для того, щоб перевірити, чи достатні процедури менеджменту. 5. Інспекції Інспекція - формальна техніка оцінки персоною або групою персон на наявність помилок у коді, вимогах і проектах, на їх відповідність стандартам і пошук інших проблем в процесі розробки ПЗ [IEEE Std. 729-1983]. Інспекція повинна бути добре спланована і організована. Всі помилки і проблеми повинні бути записані. Супервізори не повинні брати участь в інспекції. Її результати надаються супервізорам у формі звітів, без особистої інформації про інспекторів.Після чого проводиться нарада. Мета наради - зробити виводи про те, які проблеми повинні бути ліквідовані і які дії зроблені для уникнення проблем в майбутньому. Малюнок 11.6.1. Процес інспекції.
На малюнку 11.6.1 представлені наступні етапи інспекції: · Ініціація - виклик інспекції і її голови · Планування - лідер викликає членів, формує управляючі таблиці і план, визначає ретельність контролю · Ініціююча нарада - формулювання правил, завдань, очікувань, створення документів інспекції · Інівідуальний контроль - члени інспекції перевіряють документи, використовуючи критерії контролю (для того, щоб знайти максимальну кількість помилок) · Контрольна нарада (мозкова буря) - збір думок кожного інспектора, які можуть бути "невідповідністю" (потенційною помилкою), "питанням про намір", "пропозицією про удосконалення процесу", пошук інших невідповідностей, залучення до процесу інспекції · Удосконалення продукту: редактор (зазвичай - автор) проводить перевірку усіх рішеннь і проголошує невідповідності. Реальні невідповідності можуть відрізнятися від записаних. Їх сприймають як помилки, або документ редагується для уникнення неправильної інтерпретації. · Доопрацювання: лідер перевіряє, чи всі невідповідності виправлені; він перевіряє завершеність, а не правильність. · Рішення по завершеності: лідер дає оцінку того, чи готовий продукт (чи знаходиться кількість помилок в допустимих межах). · Розробка документів · Мета "мозкової бурі" - визначити причину вагомих помилок (не більше десяти помилок) і запропонувати процедури для їх уникнення в майбутньому. Дослідження показують, що інспекції - найефективніший спосіб (від 50% до 80%; в середньому - 60%; для тестування середній показник - 30%, максимум - 50%). Сам метод і його умови застосовуються рідко і лише до "елітних" систем. Продуктивність в результаті інспекції збільшується на 30% - 100%, час на розробку проекту зменшується на 10% - 30%, вартість тестування зменшується в 5 - 10 разів (менше помилок, менше регресивних помилок), підтримка - в 10 разів більша. Було відмічено, що інспекції мотивують команди: робота виконується вчасно, а її комфорт збільшується. Продукт буде оцінений з більшою компетентністю (ми можемо вихвалятися, а не соромитися). Відбудеться навчання шляхом знаходження помилок, а витрати стануть меншими, оскільки не потрібно буде маскувати низьку якість продукту. Інспекції не є частими, оскільки вони вимагають компетентних персон, які правильно працюють. Не потрібно ніяких особливих інструментів. Витрати і наслідки інспекції нелегко оцінити. Ефект може бути зменшений, якщо інспектора будуть недосвідчені. Також інспекція може призвести до самозахисту розробки проекту. 6. Види тестів До тестування відносяться два поняття: помилка і невдача. Помилка - це неправильна будова програми, яка може призвести до помилок в ході її виконання. Невдача - неправильне функціонування системи під час її роботи. Помилка може призвести до багатьох невдач. Одна і та ж невдача може відбуватися з різних причин. Тестування - це процес визначення і усунення помилок, заснований на неправильних виконаннях і інших тестах. Тести ПЗ можуть класифікуватися з точки зору головної мети або техніки тестування. Класифікація з точки зору техніки тестування. Існують наступні тести: · статичні тести, засновані тільки на аналізі коду. Вони здійснюються програмістами. · динамічні тести, які складаються з виконання різних частин коду і порівняння їх результатів з правильними. Статистичні тести Статистичні тести циклічні і проводяться відповідно до строго визначеного плану: · генерування випадкових вхідних даних, які відповідають обраним правилам · отримання результатів правильно працюючої системи, що має ті ж дані · запуск системи і порівняння її результатів з вже отриманими. Статистичні тести легко виконувати автономно. Якщо вірні початкові обмеження і визначена початкова продуктивність системи, тестування може виконуватися автономно. Недолік - ненадійність. Причина часто полягає в неправильних обмеженнях даних - вони можуть не відповідати реальним. Заходи надійності, засновані на статистиці помилок: · Вірогідність невдачі транзакції · Частота невдачі - кількість помилок за проміжок часу. Застосовується до систем без транзакцій · Середній час між виконаннями · Доступність - вірогідність того, що система у будь-який момент часу буде доступна користувачеві. Обчислюється відношенням часу, впродовж якого система була доступна, до часу тестування. Читайте також:
|
||||||||
|