Метод забезпечення якості програмних продуктів при гнучкій розробці

Abstract

Гнучкі методи розробки ПЗ були розроблені, щоб звести до мінімуму ризики розробки низькоякісних програмних систем з процесами, заснованими на негнучких методах. Вони вимагають якомога менше накладних витрат, щоб якомога швидше розробляти ПЗ з постійним зворотнім зв’язком з клієнтами. Ці методи засновані на кількох основних практиках, таких як простий проект, який означає, що система повинна бути побудована якомога простіше, а складність повинна бути усунена взагалі. У гнучкій розробці ПЗ організації використовують операції забезпечення якості, наприклад, рефакторинг, для видалення дефектів, які знижують якість ПЗ. Рефакторинг необхідний для усунення дефектів якостей (тобто, недоліки проекту, негативні проектні характеристики, аномалії ПЗ і т.д.). Оскільки час є вирішальним фактором гнучкої розробки, не всі дефекти можуть бути видалені на одній фазі рефакторингу (особливо для однієї ітерації). Загальною проблемою в обслуговуванні ПЗ є відсутність документації для зберігання цих знань, необхідних для виконання задач підтримки. У час, коли програмні системи еволюціонують, їх трансформація або записується явно в документації, або неявно через систему керування версіями. Проблеми або рішення, які виникли на етапах розробки, губляться і повинні бути знову відкритими на більш пізніх етапах супроводу. І очікувані, і неочікувані CAPP (corrective, adaptive, preventive, or perfective) (коригуючі, адаптивні, профілактичні або досконалі) дії використовують і виробляють важливу інформацію, яка не систематично реєструється під час еволюції системи. У результаті, супровід стає зайвим, і єдиним контрзаходами є, наприклад, документування кожної проблеми, інциденту або рішення в системі документації, як Bugzilla. Пряма документація про дефекти якості, виявлених під час автоматичних або ручних операцій (наприклад, аналіз коду, парне програмування або перевірка коду), необхідна, щоб уникнути втрат часу, повторно виявивши їх на більш пізніх етапах. 9 Щоб підтримувати супровід ПЗ для його роботи, нам потрібна центральна і постійна точка (під час ЖЦ продукту), де зберігається необхідна інформація. Щоб вирішити цю проблему, пропонується ввести мову анотацій, яка може використовуватися для запису інформації про характеристики якості та дефектів, знайдених у вихідному коді, і яка представляє історію дефектів та обробки частин програмної системи. Мова анотацій може використовуватися не тільки для підтримки процесів виявлення дефектів якості, а також призначається для процесів тестування та інспекції. На наш погляд, пряме зберігання інформації про дефекти, рішення про них або рефакторинги, що застосовуються в коді (як центральна точка інформації) через мови анотації, такі як JavaDoc, doxygen, або ePyDoc, є найбільш перспективним рішенням.