Defect Density Tracking by Source Module

Resolve Bottlenecks,
Find Innovative Solutions
Generate Solutions

Solution Overview

Problem

Current defect tracking systems in software development and CAD fields lack correlation between defect fixes and source code changes, making it impossible to identify defect-prone modules, assess quality over time, or prioritize testing resources effectively.

Innovation Solution

Implement a system that tracks and analyzes defect density by source file or module by capturing and validating changes made to fix defects, mapping physical versions to a canonical entity, and generating reports to identify critical areas for improvement.

Engineering Contradictions & Design Principles

VSEngineering Contradiction Analysis

1Reliability

If defect tracking systems are used to track and analyze defect rates, then defect tracking capability is improved, but the ability to identify defect-prone modules and correlate with source code changes remains lost

Engineering Contradiction:
Improvedefect tracking capabilityVSAvoidcorrelation between defect fixes and source code changes
Core Design Contradiction:
ReliabilityVSLoss of information

Solution Approach 1:

The patent merges the defect tracking system with the source control system by integrating defect tracking data with source code change data. This combination enables the system to correlate defect fixes with actual source code modifications, thereby resolving the loss of information about which files or modules are most prone to defects while maintaining reliable defect tracking capability.

Inventive Principle:
Principle #5Merging (Combining)

2Device complexity

If defect tracking systems operate independently from source control systems, then system simplicity is maintained, but the ability to prioritize quality assurance resources is lost

Engineering Contradiction:
Improvesystem integration complexityVSAvoidquality assurance resource prioritization
Core Design Contradiction:
Device complexityVSProductivity

Solution Approach 1:

The patent introduces an intermediary layer that bridges the defect tracking system and the source control system. This intermediary enables the integration of defect tracking data with source code change data without requiring direct complex integration between the two systems. The intermediary facilitates the correlation between defect fixes and source code modifications, enabling effective prioritization of quality assurance resources while maintaining manageable system complexity.

Inventive Principle:
Principle #24Intermediary (Mediator)

3Ease of manufacture

If no correlation exists between defect tracking system and source control system, then implementation ease is maintained, but the ability to track quality improvement over time is lost

Engineering Contradiction:
Improvesystem implementation easeVSAvoidquality measurement capability
Core Design Contradiction:
Ease of manufactureVSMeasurement precision

Solution Approach 1:

The patent segments the integration function into separate modular components that can be independently implemented. By dividing the correlation between defect tracking and source control into distinct functional modules, the system maintains implementation ease while enabling precise measurement of quality improvement over time through correlated data analysis.

Inventive Principle:
Principle #1Segmentation

Data Source

PatentUS9047164B2Calculating defect density by file and source module
Publication Date: 2015.06.02 OPSHUB
  • US9047164B2 patent drawing
  • US9047164B2 patent drawing
  • US9047164B2 patent drawing

AI summary

Techniques are provided for tracking and analyzing defect density by source file or module. Defect density is the number of distinct defects which required changes to be made (to fix the defect) to a particular file or module in a given period of time. This metric is very useful for identifying the most critical areas of weakness of the system and hence the areas where additional investment/action may be taken. For example, this metric can be used to prioritize the area in which unit tests should be written, for which additional automated system tests should be written or which a project should be undertaken to re-write the error prone file or module to improve its quality and maintainability.