Legal claims defining the scope of protection. Each claim is shown in both the original legal language and a plain English translation.
1. A method for providing feedback to developers of a sufficiency of log messages associated with a change set made to a continuous delivery pipeline in a Software as a Service (SaaS) environment, the method comprising: calculating, by a processor of a computing system, a complexity of the change set made to the continuous delivery pipeline in the SaaS environment; comparing, by the processor of the computing system, a current log message created as a result of a test operation of the continuous delivery pipeline in the SaaS environment during a current run with a previous log message created as a result of the test operation of the continuous delivery pipeline in the SaaS environment during a previous run, to determine a log difference between the current log message and the previous log message; determining, by the processor of the computing system, a module sensitivity for each module of the change set; identifying, by the processor of the computing system, a trust level of a developer of the change set; analyzing, by the processor of the computing system, a serviceability of the change set made to the continuous delivery pipeline in the SaaS environment based on: (i) the complexity of the change set, (ii) the log difference between the current log message and the previous log message, (iii) the module sensitivity of each module of the change set, (iv) a stability of changes that were recently introduced in the change set, and (v) the trust level of the developer of the change set, wherein, as a function of the analyzing, the sufficiency of the log messages for each module of the change set is determined; and removing, by the processor of the computing system, the change set from the continuous delivery pipeline in the SaaS environment based on the sufficiency of the log messages for each module of the change set.
This invention relates to a system for evaluating the adequacy of log messages in a Software as a Service (SaaS) environment during continuous delivery pipeline operations. The system addresses the challenge of ensuring sufficient logging for debugging and monitoring changes in a SaaS environment, where inadequate logging can lead to difficulties in troubleshooting and maintaining system stability. The method involves analyzing a change set introduced into the continuous delivery pipeline. First, the system calculates the complexity of the change set, which likely involves assessing factors such as the number of modified files, lines of code changed, or the impact of the changes. Next, the system compares log messages generated during the current test run of the pipeline with those from a previous run to identify differences, which may indicate new or missing log entries. The system also evaluates the sensitivity of each module affected by the change set, likely based on factors such as criticality or historical failure rates. Additionally, it assesses the trust level of the developer responsible for the change, which may be derived from their past performance or reliability. The system then analyzes the serviceability of the change set by considering the complexity, log differences, module sensitivity, stability of recent changes, and developer trust level. Based on this analysis, the system determines whether the log messages are sufficient for debugging and monitoring purposes. If the logs are deemed insufficient, the change set may be removed from the pipeline to prevent potential issues. This approach helps ensure that changes are properly logged before deployment, improving system reliability and maintainability.
2. The method of claim 1 , further comprising: determining, by the processor of the computing system, a log level for each module of the change set based on: (i) the complexity of the change set, (ii) the log difference between the current log message and the previous log message, (iii) the module sensitivity of each module of the change set, and (iv) the trust level of the developer of the change set.
This invention relates to a method for dynamically determining log levels in a computing system to optimize logging efficiency and relevance. The method addresses the problem of excessive or insufficient logging in software systems, which can lead to either overwhelming log data or inadequate debugging information. The system analyzes a change set—a collection of code modifications—to determine an appropriate log level for each module within the change set. The log level is calculated based on multiple factors: the complexity of the change set, the difference between the current log message and the previous log message, the sensitivity of the module being modified, and the trust level of the developer making the changes. By dynamically adjusting log levels, the system ensures that critical changes are logged in detail while less significant changes receive minimal logging, improving system performance and maintainability. The method is implemented by a processor in the computing system, which evaluates these factors to assign the most appropriate log level for each module in the change set. This approach enhances debugging efficiency and reduces log clutter, making it easier to identify and resolve issues in software development and deployment.
3. The method of claim 1 , wherein a log level determination is further based on a change stability factor, and wherein the change stability factor is calculated over time based on a number of problems occurring with the change set and an effect on an initial log level over time.
This invention relates to log management systems that dynamically adjust log levels based on system behavior. The problem addressed is the static nature of traditional log levels, which often generate excessive logs when unnecessary or insufficient logs when critical issues arise. The solution involves dynamically determining log levels by incorporating a change stability factor, which assesses the reliability and impact of system changes over time. The method calculates the change stability factor by tracking the number of problems associated with a specific change set and measuring its effect on the initial log level. As problems increase or persist, the stability factor adjusts the log level to provide more detailed logging, improving issue detection and resolution. Conversely, if the change set proves stable, the log level may be reduced to minimize unnecessary log data. This adaptive approach ensures logs remain relevant and actionable, balancing performance and diagnostic needs. The system monitors changes in real-time, continuously updating the stability factor to reflect current system conditions. By dynamically adjusting log levels, the invention reduces log noise while ensuring critical issues are captured, improving system observability and operational efficiency. This method is particularly useful in environments where system changes are frequent, such as software deployments or configuration updates.
4. The method of claim 3 , wherein a log level for each module of the change set is dynamically configured to return log messages of the continuous delivery pipeline in the SaaS environment for a specific log level.
This invention relates to log management in continuous delivery pipelines within Software-as-a-Service (SaaS) environments. The problem addressed is the need for dynamic log level configuration across multiple modules in a change set to filter and retrieve relevant log messages during the deployment process. Traditional systems often rely on static log levels, which can either generate excessive logs or miss critical information, impacting debugging and monitoring efficiency. The solution involves dynamically configuring log levels for each module within a change set. This allows administrators to specify different log levels (e.g., debug, info, warning, error) for individual modules, ensuring that only the necessary log messages are captured and returned for analysis. The dynamic configuration is applied during the execution of the continuous delivery pipeline, enabling real-time adjustments based on deployment requirements or troubleshooting needs. This approach improves log relevance, reduces noise, and enhances the ability to diagnose issues in a SaaS environment. The method integrates with the continuous delivery pipeline, where each module in the change set is associated with a configurable log level. The system processes these configurations to filter logs accordingly, ensuring that only the specified log messages are generated and stored. This dynamic filtering is particularly useful in complex deployments where different modules may require different levels of logging granularity. The solution optimizes resource usage by avoiding unnecessary log generation while maintaining visibility into critical operations.
5. The method of claim 1 , wherein calculating the complexity of the change set made to the continuous delivery pipeline in the SaaS environment includes identifying, by the processor of the computing system, modules related to the change set, a developer identification, a type of file that was changed, a kilo of lines of code (KLOC) of the change set, a number of files changed by the change set, a number of work items, and a recency of changes of the change set.
This invention relates to assessing the complexity of changes made to a continuous delivery pipeline in a Software-as-a-Service (SaaS) environment. The problem addressed is the lack of a systematic way to evaluate the impact and risk associated with changes in such environments, which can lead to deployment failures or service disruptions. The method involves calculating the complexity of a change set by analyzing multiple factors. These include identifying the modules affected by the change, the developer responsible, the type of files modified, the size of the change in terms of kilo lines of code (KLOC), the number of files altered, the number of associated work items, and the recency of previous changes. By evaluating these factors, the system can determine the potential risk and impact of the change before deployment. The analysis helps prioritize changes, identify high-risk modifications, and improve the reliability of continuous delivery pipelines. This approach ensures that changes are thoroughly assessed before being integrated, reducing the likelihood of errors and enhancing the stability of the SaaS environment. The method leverages automated processing to gather and analyze these metrics, providing a data-driven assessment of change complexity.
6. The method of claim 1 , wherein determining the module sensitivity for each module of the change set includes: (i) extracting, by the processor of the computing system, information about a defect and a field problem history, a number of developers that contributed to the module, and (ii) calculating, by the processor of the computing system, a module complexity based on a number of files affected by the change set, a size of the files affected by the change set, and a number of cross-references to the files affected by the change set.
This invention relates to software development and quality assurance, specifically to assessing the risk associated with changes in a software module. The problem addressed is the difficulty in predicting which software modules are more likely to introduce defects or failures when modified, due to factors like complexity, developer involvement, and historical issues. The method evaluates the sensitivity of each module in a change set by analyzing multiple factors. First, it extracts data about the module's defect and field problem history, as well as the number of developers who have contributed to it. This helps identify modules with a track record of issues or those that have been frequently modified by multiple developers, which may indicate higher risk. Second, it calculates the module's complexity by assessing the number of files affected by the change, the size of those files, and the number of cross-references (e.g., dependencies) to them. A higher number of affected files, larger file sizes, or more cross-references suggest greater complexity, which can increase the likelihood of introducing errors. By combining these factors, the method provides a quantitative measure of module sensitivity, helping developers and quality assurance teams prioritize testing and review efforts on higher-risk changes. This approach improves software reliability by focusing resources on the most critical areas of a codebase.
7. The method of claim 1 , wherein identifying the trust level of the developer of the change set includes extracting a contribution of the developer of the change set, an experience level of the developer of the change set, and a number of issues reported against the developer of the change set.
This invention relates to software development and change management, specifically to assessing the trustworthiness of developers submitting code changes. The problem addressed is the difficulty in evaluating the reliability of code contributions from developers, which is critical for maintaining software quality and security. The invention provides a method to determine a developer's trust level by analyzing multiple factors related to their contributions. The method involves extracting three key metrics to assess a developer's trustworthiness. First, it evaluates the developer's contribution history, such as the volume and quality of past code changes. Second, it considers the developer's experience level, which may include factors like tenure, role, or expertise in specific areas. Third, it examines the number of issues reported against the developer's previous contributions, such as bugs, security vulnerabilities, or code review feedback. These metrics are combined to generate a trust score, which helps in determining whether a developer's proposed changes should be accepted, reviewed more thoroughly, or rejected. This approach improves decision-making in code review processes by providing an objective assessment of developer reliability, reducing risks associated with untrusted contributions. The method can be integrated into version control systems, continuous integration pipelines, or automated code review tools to enhance software development workflows.
8. A computer system, comprising: a processor; a memory device coupled to the processor; and a computer readable hardware storage device coupled to the processor, wherein the computer readable hardware storage device contains program code executable by the processor via the memory device to implement a method for providing feedback to developers of a sufficiency of log messages associated with a change set made to a continuous delivery pipeline in a Software as a Service (SaaS) environment, the method comprising: calculating, by the processor of the computer system, a complexity of the change set made to the continuous delivery pipeline in the SaaS environment; comparing, by the processor of the computer system, a current log message created as a result of a test operation of the continuous delivery pipeline in the SaaS environment during a current run with a previous log message created as a result of the test operation of the continuous delivery pipeline in the SaaS environment during a previous run, to determine a log difference between the current log message and the previous log message; determining, by the processor of the computer system, a module sensitivity for each module of the change set; identifying, by the processor of the computer system, a trust level of a developer of the change set; analyzing, by the processor of the computer system, a serviceability of the change set made to the continuous delivery pipeline in the SaaS environment based on: (i) the complexity of the change set, (ii) the log difference between the current log message and the previous log message, (iii) the module sensitivity of each module of the change set, (iv) a stability of changes that were recently introduced in the change set, and (v) the trust level of the developer of the change set, wherein, as a function of the analyzing, the sufficiency of the log messages for each module of the change set is determined; and removing, by the processor of the computer system, the change set from the continuous delivery pipeline in the SaaS environment based on the sufficiency of the log messages for each module of the change set.
In the domain of Software as a Service (SaaS) environments, continuous delivery pipelines require robust logging to ensure system reliability and maintainability. A key challenge is determining whether log messages adequately cover changes introduced in a change set, particularly when those changes impact sensitive modules or are made by less experienced developers. This system addresses this problem by analyzing log messages to assess their sufficiency in providing feedback to developers. The system calculates the complexity of a change set in a continuous delivery pipeline and compares current log messages from test operations with previous log messages to identify differences. It also determines the sensitivity of each module affected by the change set and evaluates the trust level of the developer responsible. By analyzing these factors—along with the stability of recent changes—the system assesses the serviceability of the change set. If the log messages are deemed insufficient, the change set is removed from the pipeline to prevent potential issues. This approach ensures that critical changes are properly logged, reducing risks in SaaS deployments.
9. The computer system of claim 8 , further comprising: determining, by the processor of the computing system, a log level for each module of the change set based on: (i) the complexity of the change set, (ii) the log difference between the current log message and the previous log message, (iii) the module sensitivity of each module of the change set, and (iv) the trust level of the developer of the change set.
This invention relates to a computer system for managing log levels in software development, addressing the challenge of optimizing log verbosity to balance debugging needs with system performance. The system dynamically adjusts log levels for software modules based on multiple factors to ensure relevant information is captured without excessive logging. The system first identifies a change set, which includes modifications to one or more software modules. For each module in the change set, the system determines a log level by analyzing the complexity of the change, the difference between the current and previous log messages, the sensitivity of the module, and the trust level of the developer making the changes. Complexity assesses the scope and impact of the modifications, while log difference evaluates changes in log content. Module sensitivity categorizes modules by criticality, and developer trust level reflects the reliability of the developer's contributions. By integrating these factors, the system assigns appropriate log levels to ensure sufficient debugging information is available while minimizing unnecessary log entries, improving system efficiency and maintainability.
10. The computer system of claim 8 , wherein a log level determination is further based on a change stability factor, and wherein the change stability factor is calculated over time based on a number of problems occurring with the change set and an effect on an initial log level over time.
A computer system monitors and adjusts log levels for software changes to optimize system performance and troubleshooting. The system tracks changes made to software, such as updates or patches, and dynamically determines the appropriate log level (e.g., debug, info, warning, error) for each change. The log level adjustment is based on a change stability factor, which evaluates the reliability of the change over time. This factor is calculated by analyzing the number of problems associated with the change and how those problems impact the initial log level. For example, if a change frequently causes errors, the system may increase the log level to capture more detailed diagnostic information. Conversely, if a change remains stable with no issues, the log level may be reduced to minimize unnecessary logging overhead. The system continuously updates the stability factor as new data becomes available, ensuring that log levels remain optimized for both performance and troubleshooting efficiency. This approach reduces manual intervention and improves system reliability by automatically adapting logging behavior based on real-time performance data.
11. The computer system of claim 10 , wherein a log level for each module of the change set is dynamically configured to return log messages of the continuous delivery pipeline in the SaaS environment for a specific log level.
The invention relates to a computer system for managing log levels in a continuous delivery pipeline within a Software-as-a-Service (SaaS) environment. The system addresses the challenge of efficiently capturing and filtering log messages during software deployment, ensuring that relevant diagnostic information is available while minimizing unnecessary log data. The system includes a change set comprising multiple modules, each responsible for different aspects of the deployment process. A key feature is the dynamic configuration of log levels for each module, allowing administrators to specify which log messages (e.g., debug, info, warning, error) are generated and returned for analysis. This dynamic adjustment ensures that logs are tailored to the current deployment phase or troubleshooting needs, improving efficiency and reducing storage requirements. The system may also include a log aggregation component that collects and processes these messages, enabling real-time monitoring and historical analysis. By dynamically configuring log levels per module, the system optimizes performance and resource usage while maintaining visibility into the deployment pipeline.
12. The computer system of claim 8 , wherein calculating the complexity of the change set made to the continuous delivery pipeline in the SaaS environment includes identifying, by the processor of the computer system, modules related to the change set, a developer identification, a type of file that was changed, a kilo of lines of code (KLOC) of the change set, a number of files changed by the change set, a number of work items, and a recency of changes of the change set.
This invention relates to a computer system for analyzing the complexity of changes made to a continuous delivery pipeline in a Software-as-a-Service (SaaS) environment. The system addresses the challenge of assessing the impact and risk associated with software changes in cloud-based deployment pipelines, where rapid and frequent updates can introduce instability if not properly evaluated. The system calculates the complexity of a change set by analyzing multiple factors. It identifies the modules affected by the change, the developer responsible, the type of files modified, the size of the change in terms of kilo lines of code (KLOC), the number of files altered, the number of associated work items (e.g., tasks or bug reports), and the recency of previous changes to the same components. By aggregating these metrics, the system provides a comprehensive assessment of the change's potential impact, helping teams prioritize testing, review, or deployment decisions. This approach improves the reliability and efficiency of SaaS deployments by quantifying risk before changes are applied.
13. The computer system of claim 8 , wherein determining the module sensitivity for each module of the change set includes: (i) extracting, by the processor of the computing system, information about a defect and a field problem history, a number of developers that contributed to the module, and (ii) calculating, by the processor of the computing system, a module complexity based on a number of files affected by the change set, a size of the files affected by the change set, and a number of cross-references to the files affected by the change set.
This invention relates to software development systems that analyze code changes to assess risk and impact. The system evaluates the sensitivity of software modules within a change set to identify potential issues before deployment. The analysis includes extracting data on defect history, field problem reports, and developer contributions to each module. Additionally, the system calculates module complexity by assessing the number of affected files, their sizes, and the number of cross-references to those files. This approach helps prioritize testing and review efforts by highlighting modules with higher risk profiles. The system aims to reduce deployment failures by providing developers with insights into the stability and maintainability of code changes. By integrating historical defect data and structural complexity metrics, the system supports more informed decision-making in software development workflows.
14. The computer system of claim 8 , wherein identifying the trust level of the developer of the change set includes extracting a contribution of the developer of the change set, an experience level of the developer of the change set, and a number of issues reported against the developer of the change set.
A computer system evaluates the trustworthiness of software developers by analyzing their contributions, experience, and issue history. The system assesses a developer's trust level by extracting data on their past contributions to a codebase, their experience level (e.g., years of activity, role, or seniority), and the number of issues (e.g., bugs, defects) reported against their work. This trust level is used to determine whether a proposed change set from the developer should be automatically approved, flagged for review, or rejected. The system may also compare the developer's trust level against predefined thresholds or organizational policies to enforce security and quality standards. By automating trust assessment, the system reduces manual review overhead while mitigating risks associated with low-trust developers. The approach is particularly useful in collaborative development environments where code contributions must be validated efficiently. The system may integrate with version control systems, issue trackers, and developer profiles to gather the necessary data for trust evaluation.
15. A computer program product comprising a computer readable hardware storage device storing computer readable program code, the computer readable program code comprising an algorithm that when executed by a processor of a computing system implements a method for providing feedback to developers of a sufficiency of log messages associated with a change set made to a continuous delivery pipeline in a Software as a Service (SaaS) environment, the method comprising: calculating, by the processor of the computing system, a complexity of the change set made to the continuous delivery pipeline in the SaaS environment; comparing, by the processor of the computing system, a current log message created as a result of a test operation of the continuous delivery pipeline in the SaaS environment during a current run with a previous log message created as a result of the test operation of the continuous delivery pipeline in the SaaS environment during a previous run, to determine a log difference between the current log message and the previous log message; determining, by the processor of the computing system, a module sensitivity for each module of the change set; identifying, by the processor of the computing system, a trust level of a developer of the change set; analyzing, by the processor of the computing system, a serviceability of the change set made to the continuous delivery pipeline in the SaaS environment based on: (i) the complexity of the change set, (ii) the log difference between the current log message and the previous log message, (iii) the module sensitivity of each module of the change set, (iv) a stability of changes that were recently introduced in the change set, and (v) the trust level of the developer of the change set, wherein, as a function of the analyzing, the sufficiency of the log messages for each module of the change set is determined; and removing, by the processor of the computing system, the change set from the continuous delivery pipeline in the SaaS environment based on the sufficiency of the log messages for each module of the change set.
In the domain of Software as a Service (SaaS) environments, continuous delivery pipelines require robust logging to ensure system reliability and troubleshooting. However, insufficient or inconsistent log messages can hinder debugging and maintenance. This invention addresses the challenge by providing automated feedback to developers regarding the adequacy of log messages associated with changes in a continuous delivery pipeline. The system calculates the complexity of a change set introduced into the pipeline and compares log messages from current and previous test runs to identify differences. It assesses module sensitivity for each affected module and evaluates the developer's trust level. The system then analyzes the serviceability of the change set by considering the complexity, log differences, module sensitivity, recent change stability, and developer trust. Based on this analysis, the system determines whether the log messages are sufficient for each module. If the logs are deemed insufficient, the change set may be removed from the pipeline to prevent potential issues. This approach ensures that only well-documented changes proceed, improving system reliability and maintainability.
16. The computer program product of claim 15 , further comprising: determining, by the processor of the computing system, a log level for each module of the change set based on: (i) the complexity of the change set, (ii) the log difference between the current log message and the previous log message, (iii) the module sensitivity of each module of the change set, and (iv) the trust level of the developer of the change set.
This invention relates to automated log level determination in software development, addressing the challenge of optimizing log verbosity for debugging and monitoring. The system dynamically assigns log levels (e.g., debug, info, warn, error) to code changes based on multiple factors to balance performance and diagnostic utility. The log level is determined by analyzing the complexity of the change set, the difference between current and previous log messages, the sensitivity of the affected modules, and the trust level of the developer submitting the change. The complexity of the change set is assessed by evaluating the scope and impact of modifications, such as the number of files altered or the depth of code changes. The log difference metric compares the semantic or structural variance between consecutive log entries to detect anomalies. Module sensitivity reflects the criticality of the affected components, while developer trust is derived from historical performance metrics or reputation. The system processes these inputs to generate an optimal log level, ensuring sufficient detail for troubleshooting without excessive logging overhead. This approach improves debugging efficiency and system performance by adapting log verbosity to context-specific needs.
17. The computer program product of claim 15 , wherein a log level determination is further based on a change stability factor, and wherein the change stability factor is calculated over time based on a number of problems occurring with the change set and an effect on an initial log level over time.
This invention relates to a computer program product for dynamically adjusting log levels in a software system based on change stability. The problem addressed is the inefficiency of static log level settings, which either generate excessive logs that overwhelm monitoring systems or insufficient logs that hinder troubleshooting. The solution involves a dynamic log level adjustment mechanism that considers a change stability factor to optimize logging behavior. The change stability factor is calculated over time by analyzing the number of problems associated with a specific change set and the effect of those problems on the initial log level. As problems occur, the system evaluates their frequency and impact, adjusting the log level accordingly. For example, if a change set frequently causes issues, the log level may be increased to capture more detailed diagnostic information. Conversely, if the change set remains stable, the log level may be reduced to minimize log volume. This adaptive approach ensures that logging resources are allocated efficiently, balancing performance and diagnostic needs. The system may also incorporate additional factors, such as historical data, system performance metrics, and user-defined thresholds, to refine log level adjustments. By continuously monitoring and analyzing change stability, the invention provides a self-optimizing logging mechanism that improves system observability and reduces operational overhead.
18. The computer program product of claim 17 , wherein a log level for each module of the change set is dynamically configured to return log messages of the continuous delivery pipeline in the SaaS environment for a specific log level.
This invention relates to a computer program product for managing log levels in a continuous delivery pipeline within a Software-as-a-Service (SaaS) environment. The system addresses the challenge of efficiently capturing and filtering log messages during the deployment and operation of software modules in a SaaS environment, where dynamic adjustments to log verbosity are necessary to balance performance and debugging needs. The invention includes a mechanism to dynamically configure log levels for individual modules within a change set, allowing administrators to specify which log messages are generated and returned for each module. This enables fine-grained control over logging behavior, ensuring that only relevant log messages are captured based on the operational context. The system dynamically adjusts log levels in response to changes in the pipeline or user requirements, optimizing resource usage while maintaining visibility into system operations. The solution integrates with the continuous delivery pipeline to apply these log level configurations, ensuring that log messages are filtered and returned according to the specified levels. This approach enhances troubleshooting and monitoring capabilities by providing targeted log data, reducing noise, and improving system performance. The dynamic configuration allows for real-time adjustments without requiring manual intervention or system restarts, making it suitable for high-availability SaaS environments.
19. The computer program product of claim 15 , wherein calculating the complexity of the change set made to the continuous delivery pipeline in the SaaS environment includes identifying, by the processor of the computing system, modules related to the change set, a developer identification, a type of file that was changed, a kilo of lines of code (KLOC) of the change set, a number of files changed by the change set, a number of work items, and a recency of changes of the change set.
This invention relates to assessing the complexity of changes made to a continuous delivery pipeline in a Software-as-a-Service (SaaS) environment. The problem addressed is the lack of a systematic way to evaluate the impact and risk associated with changes in such environments, which can lead to deployment failures or service disruptions. The solution involves a computer program product that calculates the complexity of a change set by analyzing multiple factors. These factors include identifying the modules affected by the change, the developer responsible, the type of files modified, the size of the change in terms of kilo lines of code (KLOC), the number of files altered, the number of associated work items, and the recency of previous changes in the same area. By quantifying these elements, the system provides a comprehensive assessment of the change's potential impact, enabling better risk management and decision-making in the deployment process. This approach helps organizations prioritize changes, allocate resources efficiently, and reduce the likelihood of deployment-related issues. The method ensures that all relevant factors are considered, providing a more accurate and reliable measure of change complexity in SaaS environments.
20. The computer program product of claim 15 , wherein determining the module sensitivity for each module of the change set includes: (i) extracting, by the processor of the computing system, information about a defect and a field problem history, a number of developers that contributed to the module, and (ii) calculating, by the processor of the computing system, a module complexity based on a number of files affected by the change set, a size of the files affected by the change set, and a number of cross-references to the files affected by the change set.
This invention relates to software development and maintenance, specifically to assessing the risk and impact of code changes in a software system. The problem addressed is the difficulty in predicting which software modules are most likely to introduce defects or cause field problems when modified, due to factors like complexity, developer involvement, and historical issues. The invention provides a method to evaluate module sensitivity by analyzing multiple factors. First, it extracts information about a module's defect and field problem history, as well as the number of developers who have contributed to it. This helps identify modules with a track record of issues or those that have been frequently modified by multiple developers, which may indicate higher risk. Second, it calculates module complexity by assessing the number of files affected by a change set, the size of those files, and the number of cross-references (e.g., dependencies) to them. A higher number of affected files, larger file sizes, or more cross-references suggest greater complexity and potential risk. By combining these factors, the system quantifies module sensitivity, enabling developers to prioritize testing, review, or refactoring efforts on the most critical modules. This approach helps reduce the likelihood of introducing new defects or exacerbating existing issues during software updates.
Unknown
March 10, 2020
Browse 5M+ US patents with plain-English claim translations and AI-generated analysis.