Software Change Impact Rating via Dependency Graphs

Resolve Bottlenecks,
Find Innovative Solutions
Generate Solutions

Solution Overview

Problem

Software changes in complex systems are risky and often require extensive testing, leading to long development cycles and reduced deployment frequency, while frequent updates are desirable to adapt to changing environments, but pose risks of downtime and non-technical impacts on users.

Innovation Solution

A software support system assesses the impact of changes by rating factors like complexity, urgency, and user impact, and recommends deployment procedures such as Delta Transport, Online Delta Transport, or Zero Downtime Upgrade, using data analysis and object dependency graphs to minimize risks and optimize deployment timing.

Engineering Contradictions & Design Principles

VSEngineering Contradiction Analysis

1Reliability

If extensive testing is performed to ensure software change reliability, then the reliability of software deployment is improved, but the development cycle time increases and deployment frequency decreases

Engineering Contradiction:
Improvesoftware deployment reliabilityVSAvoiddeployment frequency
Core Design Contradiction:
ReliabilityVSProductivity

Solution Approach 1:

The system performs preliminary impact analysis and risk assessment before deployment by examining object dependency graphs, usage statistics, and change characteristics. This preliminary evaluation identifies potential issues early, enabling targeted testing rather than exhaustive testing of all components, thus maintaining reliability while reducing overall testing time and increasing deployment frequency.

Inventive Principle:
Principle #10Preliminary action

2Adaptability or versatility

If software changes are deployed frequently to adapt to changing environments, then the adaptability of the system is improved, but the risk of downtime and negative user impact increases

Engineering Contradiction:
Improvesystem adaptabilityVSAvoidsystem availability
Core Design Contradiction:
Adaptability or versatilityVSReliability

Solution Approach 1:

The system applies different deployment strategies to different objects based on their individual characteristics and impact levels. Critical objects with high usage are deployed during low-usage periods or with enhanced testing, while less critical objects can be deployed more frequently. This localized approach to deployment quality control enables frequent updates overall while protecting system availability for critical functions.

Inventive Principle:
Principle #3Local quality

3Measurement precision

If comprehensive impact analysis is performed on all software objects, then the accuracy of risk assessment is improved, but the complexity and time required for analysis increases

Engineering Contradiction:
Improveimpact assessment accuracyVSAvoidanalysis system complexity
Core Design Contradiction:
Measurement precisionVSDevice complexity

Solution Approach 1:

The system segments the software landscape into objects with different impact levels based on usage statistics, dependency relationships, and change characteristics. By categorizing objects into segments (e.g., critical, important, optional), the system can apply different levels of analysis depth to each segment, achieving comprehensive coverage of high-impact objects while reducing analysis overhead for low-impact objects, thus balancing accuracy with manageable complexity.

Inventive Principle:
Principle #1Segmentation

Data Source

PatentUS10157052B2Software change management
Publication Date: 2018.12.18 SAP SE
  • US10157052B2 patent drawing
  • US10157052B2 patent drawing
  • US10157052B2 patent drawing

AI summary

Methods, systems, and computer program products for managing software changes and upgrades are described. Software change information of a plurality of changed objects of a software package is obtained, the software change information comprising a name of an object being changed and a type of the object being changed. An object dependency graph for the object is generated, the object dependency graph providing a data structure for identifying dependency relationships of the object being changed, and usage statistics for the object and the object type are retrieved. An identity of a module impacted by a software change is determined based on the data structure and an overall rating of the software change is generated.