Кластеризации данных в области прикладной информатики и программной инженерии на примере зарубежного опыта и зарубежных публикаций
жүктеу/скачать 177,5 Kb.
|
Лаб 1 Даурен
|
Analyzing Software Measurement Data with Clustering Techniques Shi Zhong, Taghi M. Khoshgoftaar, and Naeem Seliya, Florida Atlantic University Нұрмағанбет Дәурен Асқарұлы КН-1905 Цель: изучение современных приложений методов кластеризации данных в области прикладной информатики и программной инженерии на примере зарубежного опыта и зарубежных публикаций. 1) Какую проблему и из какой области решают авторы в статье. Зачем нужно решить эту проблему? Оценка качества программного обеспечения с помощью подходов, основанных на контролируемом обучении, затруднена без данных об измерениях дефектов программного обеспечения, полученных в ходе аналогичных проектов или более ранних выпусков системы. Кластерный анализ с участием экспертов является эффективным решением на основе неконтролируемого обучения для прогнозирования склонности программных модулей к сбоям и потенциально шумных модулей. 2) Как решалась эта проблема раньше: на основе информации из статьи (должна быть таблица методов решения с указанием источников в квадратных скобках и недостатков)
3) Что предложили авторы нового в решении поставленной проблемы и для устранения какого недостатка (один абзац)? Использование алгоритмов кластеризации, для решения проблемы изучения и именования программных модулей. 4) С помощью каких известных методов, моделей и алгоритмов (кластеризации) решается поставленная проблема в статье? Какова схема (методика) решения? Два алгоритма кластеризации: k-средних и Neural-Gas. k-средних Целевая функция, которую он минимизирует дана средней квадратичной ошибкой, где это идентификатор кластера вектора данных и центроид кластера . Neural Gas Алгоритм Neural-Gas кластеризации представляет собой конкурентный метод обучения, использующий правило обучения SoftMax. То есть множество центроидов обновляется каждый раз, когда алгоритм посещает экземпляр данных. Объем обновления зависит от расстояния между экземпляром данных и центроидом кластера. между экземпляром данных и центроидом кластера. 5) Какие данные были использованы для проведения экспериментов? Источники данных, количество и характеристики, примеры. Использовали наборы данных из двух программных проектов НАСА (написанных на C++), обозначенных как JM1 и KC2. после удаления несовместимых программных модулей и модули с отсутствующими значениями из JM1, осталось 8 850 модулей. Они обозначили сокращенный набор данных JM1 JM1-8850. KC2ц содержит 520 программных модулей и обозначен как KC2-520. 6) Какие критерии качества и сравнения (сколько тестовых наборов) использованы в статье? Большинство программных модулей не имели неисправностей. В JM1-8850 1 687 модулей имели не менее одной и не более 26 неисправностей. В KC2-520 106 модулей имели не менее одной и не более 13 неисправностей. Модуль без дефектов был помечен 0 (не подвержен сбоям), а модуль с одним или более дефектами был помечен 1 (подвержен сбоям). Однако мы не использовали эти метки в кластерном и экспертном анализе. Они использовались только для оценки эффективности маркировки эксперта. В качестве критериев сравнения использовали среднюю квадратичную ошибку, частота ложноположительных и частота ложноотрицательных результатов. 7) Каков итог решения проблемы и какие задачи требуется решать в будущем? В JM1-8850, производительность отзыва по шуму экспертной классификации с кластерами, полученными с помощью Neural-Gas, была в целом лучше. чем с кластерами, основанными на k-средних. В KC2-520, однако, наблюдалась обратная картина. Показатели абсолютного отзыва шума классификации, основанной на экспертных оценках, была в целом лучше для набора данных KC2-520, чем для набора данных JM1- 8850. Это указывает на то, что такие характеристики данных, как характеристики данных, такие как степень потенциального шум, среди прочих факторов, влияют на класс-производительность классификатора. 8) Какие недостатки приведенного в статье исследования Вы заметили? Интересно, что большинство модулей, распознанных как шум, были среди модулей, неправильно помеченных кластеризацией и экспертным методом маркировки. Хотя мы еще не знаем, какой из них (метод фильтрации шума или метод кластеризации) был более точным для данного примера, совпадение результатов дает основания для будущих исследований по фильтрации шума с использованием методов кластеризации без контроля. Оригинал статьи For software quality estimation, software development practitioners typically con- struct quality-classification or fault prediction models using software metrics and fault data from a previous system release or a similar software project.1 Engineers then use these models to predict the fault proneness of software modules in development. However, building accurate quality-estimation models is challenging because noisy data usually degrades trained models’ performance. Two general types of noise in software metrics and quality data exist. One relates to mislabeled software modules, caused by software engineers failing to detect, for- getting to report, or simply ignoring existing software faults. The other pertains to deficiencies in some col- lected software metrics, which can lead to two simi- lar (in terms of given metrics) software modules for different fault proneness labels. Removing such noisy instances can significantly improve the performance of calibrated software quality-estimation models.2 Therefore, pinpointing the problematic software modules before calibrating any software quality- estimation models is desirable. Another main challenge is that, in real-world soft- ware projects, software fault measurements (such as fault proneness labels) might not be available for training a software quality-estimation model. This happens when an organization is dealing with a soft- ware project type it’s never dealt with before. In addi- tion, it might not have recorded or collected software fault data from a previous system release. So, how does the quality assurance team predict a software project’s quality without the collected software metrics? The team can’t take a supervised learning approach without software quality metrics such as the risk-based class or number of faults. The estimation task then falls on the analyst (expert), who must decide the labels for each software module. Cluster analysis, an exploratory data analysis tool, naturally addresses these two challenges. жүктеу/скачать 177,5 Kb. Достарыңызбен бөлісу:
|