• Гідрологія і Гідрометрія
• Господарське право
• Економіка будівництва
• Економіка природокористування
• Економічна теорія
• Земельне право
• Історія України
• Кримінально виконавче право
• Медична радіологія
• Методи аналізу
• Міжнародне приватне право
• Міжнародний маркетинг
• Основи екології
• Предмет Політологія
• Соціальне страхування
• Технічні засоби організації дорожнього руху
• Товарознавство продовольчих товарів

Аудит проекту розробки ПЗ

Аудит

Аудит

Перегляди

Малюнок 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. Види тестів

До тестування відносяться два поняття: помилка і невдача.

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

Невдача - неправильне функціонування системи під час її роботи.

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

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

Тести ПЗ можуть класифікуватися з точки зору головної мети або техніки тестування.

Класифікація з точки зору техніки тестування.

Існують наступні тести:

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

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

Статистичні тести

Статистичні тести циклічні і проводяться відповідно до строго визначеного плану:

· генерування випадкових вхідних даних, які відповідають обраним правилам

· отримання результатів правильно працюючої системи, що має ті ж дані

· запуск системи і порівняння її результатів з вже отриманими.

Статистичні тести легко виконувати автономно. Якщо вірні початкові обмеження і визначена початкова продуктивність системи, тестування може виконуватися автономно.

Недолік - ненадійність. Причина часто полягає в неправильних обмеженнях даних - вони можуть не відповідати реальним.

Заходи надійності, засновані на статистиці помилок:

· Вірогідність невдачі транзакції

· Частота невдачі - кількість помилок за проміжок часу. Застосовується до систем без транзакцій

· Середній час між виконаннями

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

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

1. Active-HDL як сучасна система автоматизованого проектування ВІС.
2. III. Етапи розробки програмного забезпечення
3. VII. Етап проектування
4. VII. Етап проектування
5. Автоматизація проектування напівзамовлених ВІС.
6. Адреса аудитора.
7. Алгоритм проведення внутрішнього аудиту.
8. Алгоритм розробки методичних основ бюджетування
9. Алгоритм розробки техніко-економічного обґрунтування будівництва нового та реконструкції діючих підприємств харчування.
10. Аналіз комерційної здійснимості (спроможності) проекту
11. Аналіз чутливості інвестиційного проекту
12. Аналіз, звітність і аудит у сфері праці

Переглядів: 1736