Patent ID: 12197313

Each of the drawings is provided for illustration and description only and does not limit the present disclosure. In accordance with common practice, the features depicted by the drawings may not be drawn to scale. Accordingly, the dimensions of the depicted features may be arbitrarily expanded or reduced for clarity. In accordance with common practice, some of the drawings are simplified for clarity. Thus, the drawings may not depict all components of a particular apparatus or method. Further, like reference numerals denote like features throughout the specification and figures.

DETAILED DESCRIPTION

Provided are example methods and apparatuses that can be used to automatically manage technical debt, which can include identifying technical debt, characterizing technical debt, measuring technical debt, classifying technical debt, analyzing technical debt, remediating technical debt, or combination thereof. In some examples, the provided methods and apparatuses can advantageously automatically generate a technical debt management machine, an information management machine, or both.

Technical debt produces identifiable characteristics in computer-executable instructions, outputs of executed computer-executable instructions, processor-executable instructions, outputs of executed processor-executable instructions, and combinations thereof. Non-limiting examples of the identifiable characteristics can include a presence of a type of instructions known to be produced by technical debt, a presence of a group of instructions known to be produced by technical debt, a presence of an instruction known to be produced by technical debt, or a combination thereof.

Non-limiting examples of the identifiable characteristics can include an absence of a type of required instruction that is typically absent due to technical debt, an absence of a group of required instructions that is typically absent due to technical debt, an absence of a required instruction that is typically absent due to technical debt, or a combination thereof.

Non-limiting examples of the identifiable characteristics can include an absence of a type of instruction that otherwise would be present if a best practice was followed, an absence of a group of instructions that otherwise would be present if a best practice was followed, an absence of a instruction that otherwise would be present if a best practice was followed, or a combination thereof.

Non-limiting examples of the identifiable characteristics can include an output produced by the presence of the type of instructions known to be produced by technical debt, an output produced by the group of instructions known to be produced by technical debt, an output produced by the instruction known to be produced by technical debt, or a combination thereof.

Non-limiting examples of the identifiable characteristics can include an output produced by the type of required instruction that is typically absent due to technical debt, an output produced by the group of required instructions that is typically absent due to technical debt, an output produced by the required instruction that is typically absent due to technical debt, or a combination thereof.

Non-limiting examples of the identifiable characteristics can include an output produced by the type of instruction that otherwise would be present if the best practice was followed, an output produced by the group of instructions that otherwise would be present if the best practice was followed, an output produced by the instruction that otherwise would be present if the best practice was followed, or a combination thereof.

The provided systems and methods can be configured to automatically search information for the identifiable characteristics. The information being searched can be in an object under test, a platform under test, or a combination thereof. In a nonlimiting example, the information being searched can, prior to the search process, be stored on a tangible processor-readable storage medium, a tangible computer-readable storage medium, or both. In a nonlimiting example, the information being searched can, during the search process, be retrieved from a tangible processor-readable storage medium, a tangible computer-readable storage medium, or both. In a nonlimiting example, the information being searched can, during the search process, be stored on a tangible processor-readable storage medium, a tangible computer-readable storage medium, or both. In a nonlimiting example, the information being searched can, following the search process, be stored on a tangible processor-readable storage medium, a tangible computer-readable storage medium, or both. The information being searched for an identifiable characteristic of technical debt can include a software object, computer code, computer software, a computer application, a database, a webpage, the like, or a combination thereof. Descriptions herein relating to searching objects also described searching platforms.

In examples, the automatic searching can include searching the information for presence of an identifiable characteristic in accordance with a rule. In a nonlimiting example, the rule can include rule information including at least one information characteristic whose presence in an object being searched indicates technical debt and results in a violation of the rule, an amount that a technical debt score must be changed for a violation of the rule, or a combination thereof.

When a rule is violated, the provided systems and methods can store a record of the violation (e.g. as search results). The record of the violation can include information describing the rule that was violated, the location of the violation in the information being searched, the amount that the technical debt score must be changed for the violation of the rule, rule information, or a combination thereof. In some examples, the violation of the rule triggers a change in the technical debt score by the amount that the technical debt score must be changed for the violation of the rule. Thus, the technical debt score can indicate a cumulative number of rule violations.

In some examples, when information is searched and no rules are violated, the provided systems and methods can store a record indicating no rules are violated by the information that was searched (e.g. as search results).

The search results can be automatically analyzed to characterize the rule violations. The rule violations can be characterized at least in part per at least one aspect of rule information of the violated rule. For example, the search results can be analyzed to determine a frequency of violation occurrence, a violation trend, aggregate violation characteristics, remediation requirements, a remediation budget, a person responsible for remediation (e.g., a developer, an architect, etc.), a number of rule violations per a respective rule criticality, a number of rule violations per respective rule type, or a combination thereof. In some examples, the provided systems and methods can produce a per-object list of rule violations that indicates a per-object identification of a presence of technical debt, characteristics of the technical debt, or a combination thereof. The provided systems and methods can classify objects by at least one aspect of rule information of the violated rule.

The analysis results can be displayed on a user interface device (e.g. a graphical user interface on a display device).

In some examples, the analysis results can automatically initiate sending a message to the person responsible for the remediation, where the message indicates the existence of the rule violation, a detail about the rule that is violated, a location of the identifiable characteristic in the information that was searched, or combination thereof. In some examples, the analysis results can automatically initiate scheduling a remediation action in a workflow schedule.

The provided systems and methods provide many advantages.

In examples, the provided systems and methods can advantageously automatically identify presence of technical debt and characterize the presence of technical debt. The provided systems and methods can also advantageously automatically search information to identify a presence and location of an identifiable characteristic technical debt. The provided systems and methods can advantageously analyze search results, display analysis results on a user interface device, identify a remediation technique, or combination thereof.

The provided systems and methods can advantageously receive user input describing rule information, deleting rule information, editing rule information, or a combination thereof. Thus, as identifiable characteristics of technical debt change over time, rules can be adapted accordingly.

In some embodiments, the disclosed systems and methods can advantageously efficiently and quickly generate at least a portion of a technical debt management machine, an information management machine, or both when compared to conventional techniques.

The provided systems and methods can advantageously mitigate technical debt and effects thereof, including and not limited to reducing product defects of a tangible device (e.g. improving computer functionality), improving performance of the tangible device, reducing costs associated with identifying and repairing computer functionality problems, causing tangible device to perform more predictably, causing a tangible device to perform less unpredictably, reducing a number of product updates to the tangible device, reducing a number of product release delays of the tangible device, reducing a length of a product release delay of the tangible device, and reducing repair costs of repairs to the tangible device, addressing the previously unaddressed and long felt industry needs identified in the background section herein, or a combination thereof.

In some examples, the provided systems and methods can advantageously provide a rule-based adaptive protection model.

FIG.1depicts an example block diagram of an example method100that can be used to implement generating at least a portion of a technical debt management machine, in accordance with an embodiment of the disclosure. In an embodiment, the method100can be implemented in a form of a set of computer-executable instructions. In examples, computer-executable instructions can include routines, programs, objects, components, data structures, procedures, operations, modules, functions, or a combination thereof, as non-limiting examples. Such computer-executable instructions can be executed by one or more programmed processors or co-processors.

The order in which the method100is described is not intended to be construed as a limitation, and any number of the described features can be combined in any order to implement the method100or alternate methods for automatically generating at least a portion of a process management machine. Additionally, individual features can be omitted, as is practicable, from the method100without departing from the scope of the subject matter described herein. Furthermore, the method100can be implemented in any suitable hardware, software, firmware, or a combination thereof, such as the apparatus described hereby.

As shown inFIG.1, at step102, one or more of the devices described herein can compare information in at least a portion of an object in a software platform to a rule to identify a violation of the rule. The comparing can be performed by at least one processor automatically searching using a rule engine. In examples, the rule can describe at least one information characteristic whose presence in an object being scanned indicates technical debt and results in the violation of the rule.

The violation of the rule can trigger a change in a technical debt score. In some examples, the rule can describe an amount the technical debt score must be changed for the violation of the rule. The amount the technical debt score must be changed for a rule violation can be rule-specific, with different rules having different respective amounts the technical debt score must be changed for respective rule violations.

In some examples, the comparing can further include searching the at least the portion of the object in the software platform for the at least one information characteristic described by the rule and resulting from a specific type of technical debt. In nonlimiting examples, the type of technical debt can be at least one of: architecture debt, code debt, data debt, defect debt, design debt, documentation debt, governance debt, infrastructure debt, operations and maintenance debt, people debt, privacy protection debt, process debt, requirements debt, security debt, service debt, test automation debt, test debt, or user experience debt.

In some embodiments, the comparison can include the rule initiating artificial intelligence searching of the object to identify the violation of the rule. The artificial intelligence searching of the object can include performing a neural network convolution on information from the object being scanned. Some examples, the at least one information characteristic can describe an artificial intelligence hallucination.

In an example, the comparing can be performed per object type.

A presence of some types of technical debt it is more impactful than a presence of other types of technical debt. In some embodiments, the rule can further include information describing a weight to be afforded to the violation of the rule. The weight can be per-technical debt type.

In some embodiments, the rule can include information describing at least one of: a rule title, a rule type, at least one object which the rule can be compared, a respective remediation effort to cure the violation of the rule, a text description of the rule, a priority level of the rule, a keyword to be searched for during the comparing, an object type to which the rule applies, a candidate resolution approach to remediate a violation of the rule, a rule violation discovery approach, a scope of the rule, an application tag of the rule, an activation status of the rule, an inactivation status of the rule, a criticality of the rule, a source of the rule, or if the rule is configured to automatically execute during the comparing. In some examples, the method can further include displaying, by the user display device, the information describing the at least one of: the rule title, the rule type, the at least one object which the rule can be compared, the respective remediation effort to cure the violation of the rule, the text description of the rule, the priority level of the rule, the amount that the technical debt score must be changed for the violation of the rule, the technical debt score value change associated with the violation of the rule, the keyword to be searched for during the comparing, the object type to which the rule applies, the candidate resolution approach to remediate the violation of the rule, the rule violation discovery approach, the scope of the rule, the application tag of the rule, the activation status of the rule, the inactivation status of the rule, the criticality of the rule, the source of the rule, or if the rule is configured to automatically execute during the comparing.

In some examples, the rule can include information describing at least one of: a respective remedial action, a per-object time estimate to resolve the rule violation, an estimated number of hours to resolve the rule violation, an estimated financial budget to resolve the rule violation, a name of person to assign to resolve the rule violation, a name of a group of people to assign to resolve the rule violation, or a combination thereof. In some examples, method can further include displaying, by the user display device, the information describing the at least one of: the respective remedial action, the per-object time estimate to resolve the rule violation, the estimated number of hours to resolve the rule violation, the estimated financial budget to resolve the rule violation, the name of person to assign to resolve the rule violation, the name of the group of people to assign to resolve the rule violation, or the combination thereof.

Some examples, the method can further include receiving user input information describing a characteristic of a rule, defining a rule, or both. The user input information can be received from a user input device, such as those described herein. The user input information describing the characteristic of the rule, defining the rule, or both can be stored in a processor-readable storage device, such as those described herein. In some examples, the characteristic of the rule can describe a type of technical debt. In an example, the type of technical debt can be based on a system context. An example, the type of technical debt can be based on a technology context.

The received user input information describing the characteristic of the rule, defining the rule, or both can be stored in a processor-readable storage device. In some examples, the received user input information can be stored in a catalog of rules. The catalog of rules can provide an organized index of rules by rule name, rule number, information describing at least one category of aspects of rules that is common to at least two rules, or a combination thereof.

Some examples, the method can further include displaying, by the user display device, the information describing the characteristic of the rule.

In some examples, the method can include retrieving the compared rule from a catalog of rules.

In some examples, rules can be categorized. Searches can be performed per category of rules. Subsequent analysis of search results can be performed per category of rules.

In some examples, at least a portion of the method100can be repeated following a change in rule information, addition of a new rule, deletion of a rule, or combination thereof.

As shown inFIG.1, at step104, one or more of the devices described herein can change, responsive to the violation of the rule, the technical debt score by the amount the technical debt score must be changed for the violation of the rule.

In some examples, the initial technical debt score prior to commencing the comparison in step102can be a relatively high value (e.g., 1, 10, 100, 1000, 10000, etc.), with the rule violation requiring decrementing the technical debt score. In some examples, the initial technical debt score prior to commencing the comparison in step102can be a relatively high percentage (e.g., 100 percent), with the rule violation requiring decrementing the technical debt score by at least a fraction of a percent. In some examples, the initial technical debt score prior to commencing the comparison in step102can be a relatively low value (e.g., zero), with the rule violation requiring incrementing the technical debt score. In some examples, the initial technical debt score prior to commencing the comparison in step102can be a relatively low percentage (e.g., zero percent), with the rule violation requiring incrementing the technical debt score by at least a fraction of a percent. Thus, the amount the technical debt score must be changed for a rule violation can be positive or negative.

In some examples, the amount the technical debt score must be changed for the violation of the rule can be weighted (e.g. incremented or decremented) in accordance with respective rule information describing a weight to apply or a violation of the rule.

As shown inFIG.1, at step106, one or more of the devices described herein can automatically display, by a user display device, the technical debt score. The technical debt score can be displayed via a user interface.

In some examples, the method can further include displaying, by the user display device and via a heat map, respective technical debt scores per application, type of technical debt, remediation strategy, or combination thereof. A heat map displaying respective technical debt scores per application can further display at least one type of technical debt per application. A heat map displaying respective technical debt scores per application can further display at least one type of remediation strategy per application. In some examples, the method can further include receiving user input describing a selection of an application depicted on a heat map, and in response further display at least one type of technical debt per the selected application. In some examples, the method can further include receiving user input describing a selection of an application depicted on a heat map, and in response further display at least one type of remediation strategy per the selected application.

In some examples, the heat map can indicate a presence of a type of technical debt, a presence of a quantity of technical debt (e.g., per object, per platform, per application, etc.). The heat map can use colors (e.g., black, white, gray, green, yellow, red, shades thereof, etc.), portions having an area proportional to a displayed characteristic, or combination thereof to distinguish between displayed characteristics.

In some embodiments, the technical debt score can be a total technical debt score for an entire platform. In some examples, the technical debt score can be a total technical debt score for an object.

In some examples, the method can further include scaling the technical debt score to fit in a predetermined range and thus produce a scaled technical debt score. For example, scaling can include converting the technical debt score from points to a percentage. The percentage can indicate a percentage of scanned objects that violate a specific rule. The percentage can indicate a percentage of scanned objects that do not violate the specific rule. The percentage can indicate a percentage of scanned objects that violate at least one rule. The percentage can indicate a percentage of scanned objects that do not violate any rules.

The scaled technical debt score can be displayed via the user display device (e.g. via a user interface). The scaled technical debt score can be calculated for a specific application. In some examples, the scaled technical debt score can be a combined technical debt score for a defined plurality of applications. In a non-limiting embodiment, the combined technical debt score can be calculated for a defined plurality of applications created by a specific organization. In a non-limiting embodiment, the combined technical debt score can be calculated for a defined plurality of applications implemented by a specific organization.

In some examples, the method can further include calculating a trend of the technical debt score over time. The trend of the technical debt score over time can be displayed by the user display device (e.g. via the user interface).

In some embodiments, the method can further include categorizing respective technical debt scores per type of technical debt and priority. The respective technical debt scores per type and priority can be displayed by the user display device (e.g. via the user interface).

In some examples, the method can further include calculating a per-object list of rule violations that contribute to the technical debt score. The per-object list of rule violations that contribute to the technical debt score can be displayed by the user display device (e.g. via the user interface).

In some examples, the method can further include calculating, by respective technical debt type, a number of objects that violate any rule relating to the respective technical debt type. The number of objects violating any rule relating to the respective technical debt type can be displayed by the user display device (e.g. via the user interface). The number of objects violating any rule relating to the respective technical debt type can be displayed by the user display device per the respective technical debt type.

In some examples, the method can further include calculating a ratio of a quantity of objects yielding rule violations to a quantity of objects that were scanned. The ratio can be displayed by the user display device.

In some examples, one or more of the devices described herein can store at least an aspect of the technical debt management machine (e.g., at least one rule, a comparison process, a user input, or a combination thereof) on a non-transitory computer-readable medium. In an example, the non-transitory computer-readable medium can be coupled to an electronic processor that is configured to execute at least a aspect of the technical debt management machine stored on the non-transitory computer-readable medium. In an example, the electronic processor can execute at least a portion of an aspect of the technical debt management machine stored on the non-transitory computer-readable medium.

In some examples, a result of applying the technical debt management machine to the at least one object can be stored on one or more of the devices described herein (e.g., on a non-transitory computer-readable medium). In nonlimiting examples, the stored result can include information describing at least one rule, a comparison result, a user input, a technical debt score, a result of a calculation performed on a technical debt score, a result of a violation of a rule, a remedial action recommendation resulting from a violation of the rule, or a combination thereof.

In examples, at least a portion of the technical debt management machine can be configured as a set of computer-executable instructions (e.g. software instructions), where the computer-executable instructions can be stored on a non-transitory computer-readable data storage device, a non-transitory computer-readable medium, or both.

We now turn toFIG.2A.

FIG.2Adepicts a network implementation200of a system202. One or more users can access the system202through one or more user devices204-1,204-2. . .204-N, collectively referred to as user devices204, hereinafter, or applications residing on the user devices204.

Although the disclosure is explained considering that the system202is implemented on a server, the system202can be implemented in other forms of a computing device or system, such as a laptop computer, a desktop computer, a notebook, a workstation, a virtual environment, a mainframe computer, a server, a network server, or a cloud-based computing environment. It will be understood that the system202can be accessed by multiple users through one or more user devices204-1,204-2. . .204-N.

In one implementation, the system202can comprise a cloud-based computing environment in which the user can operate individual computing systems configured to execute remotely located applications. Examples of the user devices204can include, but are not limited to, a portable computer, a personal digital assistant, a handheld device, a workstation, or a combination thereof. The user devices204can be communicatively coupled to the system202through a network206.

In one implementation, the network206can be a wireless network, a wired network, or a combination thereof. The network206can be implemented as one of several different types of networks, including but not limited to an intranet, local area network (LAN), wide area network (WAN), the Internet, or a combination thereof. The network206can be a dedicated network or a shared network. A shared network can be an association of different types of networks that use a variety of protocols, for example, Hypertext Transfer Protocol (HTTP), Transmission Control Protocol/Internet Protocol (TCP/IP), or Wireless Application Protocol (WAP) to communicate with one another. Further, the network206can include a variety of network devices, including routers, bridges, servers, computing devices, storage devices, or a combination thereof.

In an embodiment, system202can include at least one processor208, an input/output (I/O) interface210, and a memory212. The processor208can be implemented as one or more microprocessors, microcomputers, microcontrollers, digital signal processors, Central Processing Units (CPUs), state machines, logic circuitries, devices that manipulate signals based on operational instructions, or a combination thereof. Among other capabilities, the at least one processor208can be configured to fetch and execute computer-readable instructions stored in the memory212.

The in/out (I/O) interface210can include software and hardware interfaces, for example, a web interface, a graphical user interface (GUI, UI), and the like. The I/O interface210can allow the system202to interact with the user directly or through at least one of the client devices204-1to204-N. Further, the I/O interface210can enable the system202to communicate with other computing devices, such as web servers and external data servers (not shown). The I/O interface210can facilitate communications and data transfer within a wide variety of networks and protocol types, including wired networks (for example, Local Area Network or cable) and wireless networks (such as wireless local area network, a cellular network, or a satellite network). The I/O interface210can include one or more ports for connecting a number of devices to one another or to another server.

The memory212can include a computer-readable medium or computer program product. Non-limiting examples include volatile memory, such as static random-access memory (SRAM) and dynamic random-access memory (DRAM), and/or non-volatile memory, such as read only memory (ROM), erasable programmable ROM, flash memories, hard disks, Solid State Disks (SSD), optical disks, and magnetic tapes. The memory212can include routines, programs, objects, instructions, modules, components, or data structures which perform particular tasks or implement particular abstract data types. The memory212can include programs or instructions that supplement applications and functions of the system202. In an embodiment, the memory212can serve as a repository for storing data processed, received, generated or a combination thereof by one or more programs or coded instructions.

We now turn toFIG.2B.

FIG.2Bdepicts an example diagram of an example computing device250suitable for implementing examples of the disclosed subject matter. For example, at least a portion of the computing device250can be suitable for use as a component part of the system202, at least one of the user devices204-1to204-N, or a combination thereof. In another example, at least a portion of the computing device250can be coupled to the network206.

In examples, a process management machine can include at least a portion of the example computing device250, at least a portion of the system202, or both, configured with computer-executable instructions to perform at least a portion of a technique described hereby, where the computer-executable instructions can be stored on a non-transitory computer-readable data storage device, a non-transitory computer-readable medium, or both.

In examples, aspects of the computing device250can be implemented at least in part in a desktop computer, a laptop computer, a server, a mobile device, a special-purpose computer, a non-generic computer, an electronic device described hereby (as is practicable), the like, or a combination thereof. In some examples, the disclosed subject matter can be implemented in, and used with, hardware devices, computer network devices, the like, or a combination thereof. The configuration depicted inFIG.2Bis an illustrative example and is not limiting.

In some examples, the computing device250can include a processor252, a data bus254, a memory256, a display258, a user interface260, a fixed storage device262, a removable storage device264, a network interface266, the like, or a combination thereof. These elements are described in further detail herein.

The processor252can be a hardware-implemented processing unit configured to control at least a portion of operation of the computing device250. The processor252can perform logical and arithmetic operations based on processor-executable instructions stored within the memory256. The processor252can be configured to execute instructions that cause the processor252to initiate at least a part of a method described hereby. In an example, the processor252can interpret instructions stored in the memory256to initiate at least a part of a method described hereby. In an example, the processor252can execute instructions stored in the memory256to initiate at least a part of a method described hereby. The instructions, when executed by the processor252, can transform the processor252into a special-purpose processor that causes the processor to perform limited functions including at least a part of a function described hereby. The processor252can also be referred to as a central processing unit (CPU), a special-purpose processor (e.g. a non-generic processor), or both.

In some examples, the computing device250can implement machine-learning techniques (e.g. using a Convolutional Neural Network (CNN), etc.) to collect information, process information, or both. In some examples, information stored in an information storage device of the computing device250can be transferred to another computing device.

The processor252can comprise or be a component of a physical processing system implemented with one or more processors. In some examples, the processor252can be implemented with at least a portion of: a microprocessor, a microcontroller, a digital signal processor (DSP) integrated circuit, a field programmable gate array (FPGA), a programmable logic device (PLD), an application-specific integrated circuit (ASIC), a controller, a state machine, a gated logic circuit, a discrete hardware component, a dedicated hardware finite state machine, a suitable physical device configured to manipulate information (e.g., calculating, logical operations, the like, or a combination thereof), the like, or a combination thereof.

The data bus254can couple components of the computing device250. The data bus254can enable information communication between the processor252and one or more components coupled to the processor252. In some examples, the data bus254can include a data bus, a power bus, a control signal bus, a status signal bus, the like, or a combination thereof. In an example, the components of the computing device250can be communicatively coupled together to communicate with each other using a different suitable mechanism.

The memory256generally represents any type or form of volatile storage device, non-volatile storage device, medium, the like, or a combination thereof. The memory256can store data (e.g. a database), processor-readable instructions, the like, or a combination thereof. In an example, the memory256can store data, load data, maintain data, or a combination thereof. In an example, the memory256can store processor-readable instructions, load processor-readable instructions, maintain processor-readable instructions, or a combination thereof. In some embodiments, the memory256can store computer-readable instructions configured to cause a processor (e.g. the processor252) to initiate performing at least a portion of a method described hereby. The memory256can be a main memory configured to store an operating system, an application program, the like, or a combination thereof. The memory256can store a basic input-output system (BIOS) which can control basic hardware operation such as interaction of the processor252with peripheral components. The memory256can also include a non-transitory machine-readable medium configured to store software. Software can mean any type of instructions, whether referred to as at least one of software, firmware, middleware, microcode, hardware description language, the like, or a combination thereof. Processor-readable instructions can include code (e.g., in source code format, in binary code format, executable code format, or in any other suitable code format).

The memory256can include at least one of read-only memory (ROM), random access memory (RAM), a flash memory, a cache memory, an erasable programmable read-only memory (EPROM), an electrically erasable programmable read-only memory (EEPROM), a register, a hard disk drive (HDD), a solid-state drive (SSD), an optical disk drive, other memory, the like, or a combination thereof which is configured to store information (e.g., data, processor-readable instructions, software, a database, the like, or a combination thereof) and is configured to provide the information to the processor252.

The display258(i.e. a user display device) can include a component configured to visually convey information to a user of the computing device250. In examples, the display258can be a video display screen, such as a light-emitting diode (LED) screen, a touch screen, or both. In examples, the display258can display, such as via a user interface, information described herein, information produced by at least a portion of a method described herein, or both. In examples, the display258can display a graphical user interface (GUI).

The user interface260can include user devices such as a switch, a computer mouse, a trackpad, a keypad, a keyboard, a touch screen, a microphone, a speaker, an audio production device, a camera, a jack for coupling the computing device to an audio production device, the like, or a combination thereof. The user interface260can optionally include a user interface controller. The user interface260can include a component configured to convey information to a user of the computing device250, a component configured to receive information from the user of the computing device250, or both. In examples, the user interface260can include the display258.

The fixed storage device262can include one or more hard drive, flash storage device, the like, or a combination thereof. The fixed storage device262can be an information storage device (e.g. storing a database) that is not configured to be removed during use. The fixed storage device262can optionally include a fixed storage device controller. The fixed storage device262can be integral with the computing device250or can be separate and accessed through an interface.

The removable storage device264can be integrated with the computing device250or can be separated and accessed through other interfaces. The removable storage device264can be an information storage device (e.g. storing a database) that is configured to be removed during use, such as a memory card, a jump drive, a flash storage device, an optical disk, the like, or a combination thereof. The removable storage device264can optionally include a removable storage device controller. The removable storage device264can be integrated with the computing device250or can be separate and accessed through an interface.

In examples, a computer-readable storage medium such as one or more of the memory256, the fixed storage device262, the removable storage device264, a remote storage location, the like, or a combination thereof can store non-transitory computer-executable instructions configured to cause a processor (e.g. the processor252) to implement at least an aspect of the present disclosure.

The network interface266can couple the processor252(e.g. via the data bus254) to a network and enable exchanging information between the processor252and the network. In some examples, the network interface266can couple the processor252(e.g. via the data bus254) to the network and enable exchanging information between the processor252and another computing device. For example, the network interface266can enable the processor252to communicate with one or more other network devices. The network interface266can couple to the network using any suitable technique and any suitable protocol. In some examples, the network interface266can include a data bus, a power bus, a control signal bus, a status signal bus, the like, or a combination thereof. Example techniques and protocols the network interface266can be configured to implement include digital cellular telephone, WiFi™, Bluetooth®, near-field communications (NFC), the like, or a combination thereof.

The network can couple the processor252to one or more other network devices. In some examples, the network can enable exchange of information between the processor252and the one or more other network devices. In some examples, the network can enable exchange of information between the processor252and another computing device. The network can include one or more private networks, local networks, wide-area networks, the Internet, other communication networks, the like, or a combination thereof. In some examples, the network can be a wired network, a wireless network, an optical network, the like, or a combination thereof.

In some embodiments, the network device can store computer-readable instructions configured to cause a processor (e.g. the processor252) to initiate performing at least a portion of a method described hereby. In an example, the one or more other network devices can store non-transitory computer-executable instructions configured to cause a processor (e.g. the processor252) to implement at least an aspect of the present disclosure. The non-transitory computer-executable instructions can be received by the processor252and implemented using at least a portion of techniques described hereby. In another example, information described hereby can be stored in the fixed storage device262, the removable storage device264, the network device, the like, or a combination thereof.

We now turn toFIG.3.

FIG.3is a diagram depicting a portion of an example method300for generating and using at least a portion of a technical debt management machine, in accordance with an embodiment of the disclosure.

As shown inFIG.3, at step302, one or more of the devices described herein can receive information describing at least a portion of an aspect of a rule. In some examples, the received information describing at least the portion of the aspect of the rule can be in a computer-readable digital format stored on a non-transient computer readable medium. In some examples, the received information describing at least the portion of the aspect of the rule can be received at the device via a user interface (e.g. via a graphical user interface). In some examples, the received information describing at least the portion of the aspect of the rule can be created by a user based upon the user's experience.

As shown inFIG.3, at step304, one or more of the devices described herein can store the information describing at least the portion of the aspect of the rule in a catalog of rules (e.g. in a computer-readable digital format stored on a non-transient computer readable medium). The catalog of rules can organize and store rule-related information that is organized per rule. The catalog of rules can store information describing multiple rules (e.g., “Rule1”306A, “rule2”306B, “rule3”306C, . . . “Rule N”306N).

As shown inFIG.3, at step308, one or more of the devices described herein can apply a rule on a per-application basis, such as by searching information describing at least a portion of computer-executable instructions (e.g. code) of the application, information describing a computer-generated output of the application, or both. In an example, the searching can be performed using a rule engine.

As shown inFIG.3, at step310, one or more of the devices described herein can store information describing results of the searching in step308in a computer-readable digital format stored on a non-transient computer readable medium.

As shown inFIG.3, at step312, one or more of the devices described herein can aggregate the information describing the results of the scanning. The aggregating can be on a per-rule basis, on a per-application basis, on a per-rule aspect basis, on a per-application aspect basis, on a per-object basis, on a per-rule type basis, on a technical debt type basis, on a technical debt indicator basis, on a per-scope basis, on a per-object type basis, on a per priority level basis, on a per criticality basis, or a combination thereof. information describing results of the aggregating can be stored in a computer-readable digital format stored on a non-transient computer readable medium.

As shown inFIG.3, at step314, one or more of the devices described herein can calculate a technical debt score from the results of the searching in step308and based upon a violation of a rule applied during the scanning. In some examples, remediation-related efforts can be identified from the results of the searching in step308and based upon the violation of the rule applied during the scanning.

In examples, a rule can include information describing an amount that a technical debt score must be changed for a violation of the rule and, responsive to the violation of the rule, the technical debt score is changed accordingly.

As shown inFIG.3, at step316, one or more of the devices described herein can identify information describing planning remediation, budget-related remediation, or both from the results of the searching in step308and based upon the violation of the rule applied during the scanning.

A rule can have associated information describing a remediation activity that can be performed to mitigate the violation of the rule, to resolve violation of the rule, or both. A rule can have associated information describing a budget for remediation activity that can be performed to mitigate the violation of the rule, to resolve violation of the rule, or both. The budget for the remediation activity can describe a remediation time (e.g., in minutes, hours, days, or a combination thereof), a remediation cost, or a combination thereof. When multiple violations of a rule occur, a combined budget for remediation activities can be calculated by multiplying the number of violations by the budget for the remediation activity. Information describing a remediation activity can include an estimated start date to start remediation activity, start date by which remediation activity must be started, an estimated end date of remediation activity, an end date by which remediation activity must be completed, or a combination thereof.

As shown inFIG.3, at step318, one or more of the devices described herein can repeat the searching of step308and calculating of step314over time to monitor changes in technical debt. Step318can optionally include performing step312, step316, or both.

As shown inFIG.3, at step320, subsequent to performing step318, one or more of the devices described herein can calculate information describing a trend over time in the technical debt score, planning remediation, budget-related remediation, or a combination thereof. In an example, the information describing the trend can be displayed by a user device and via a graphical user interface. The trend can be displayed in a tabular form, a graphical form, or a combination thereof.

In an example, information describing the trend can be used to adjust an aspect of rule, evaluate the efficacy of rule, evaluate the accuracy of a rule, or a combination thereof.

We now turn toFIGS.4A-4F.

FIGS.4A-4Fare diagrams depicting a non-limiting example user interface400including a user display or portion thereof402with examples of pages of a graphical user interface of a technical debt management machine, in accordance with an embodiment of the disclosure.

FIG.4Ais a diagram depicting the non-limiting example user interface400including the user display or portion thereof402with a home page404of a graphical user interface of a technical debt management machine, in accordance with an embodiment of the disclosure.

The home page404can include information describing a dashboard, workload actions that are in progress, information describing scans, information describing search results, or a combination thereof. The home page404can include information describing aspects of rule engine, including types of technical debt that the rule engine can detect. The home page404can also include information describing a technical debt indicator, a technical debt map, a rule, a platform that can be scanned, an application to which the rule engine can be applied, or combination thereof.

FIG.4Bis a diagram depicting the non-limiting example user interface400including the user display or portion thereof402with a rule type selection page406of a graphical user interface of a technical debt management machine, in accordance with an embodiment of the disclosure.

FIG.4Cis a diagram depicting the non-limiting example user interface400including the user display or portion thereof402with a technical debt map creation page408of a graphical user interface of a technical debt management machine, in accordance with an embodiment of the disclosure.

The technical debt map creation page408can provide a user interface to enable a user to input information that creates a technical debt map. The technical debt map creation page408can include drop-down boxes, radio buttons, etc. to enable the user to enter information describing aspects of the technical debt map. The aspects of the technical debt map can include, and are not limited to, a technical debt type, a technical debt indicator, a platform name, an application name, a scope of the technical debt map, a rule type, or a combination thereof.

FIG.4Dis a diagram depicting the non-limiting example user interface400including the user display or portion thereof402with a rule detail entry page410of a graphical user interface of a technical debt management machine, in accordance with an embodiment of the disclosure.

The technical rule detail entry page410can provide a user interface to enable a user to input information that creates or updates a rule. The technical rule detail entry page410can include drop-down boxes, radio buttons, etc. to enable the user to enter information describing aspects of the rule. The aspects of the rule can include, and are not limited to, a rule title, a rule weight, a rule priority level, a rule criticality, an amount by which a technical debt score is changed per violation of the rule, an object type, a discovery approach, a target, a priority, a capability of the rule to automatically discover a violation of the rule, an application tag, or a combination thereof.

FIG.4Eis a diagram depicting the non-limiting example user interface400including the user display or portion thereof402with a rule filter condition entry page412of a graphical user interface of a technical debt management machine, in accordance with an embodiment of the disclosure.

The rule filter condition entry page412can provide a user interface to enable a user to input information that creates or updates a rule. The rule filter condition entry page412can include drop-down boxes, radio buttons, etc. to enable the user to enter information describing aspects of the filter condition. The aspects of the filter condition can include, and are not limited to, an aspect of the rule, an operator, and a value.

FIG.4Fis a diagram depicting the non-limiting example user interface400including the user display or portion thereof402with a rule activation page414of a graphical user interface of a technical debt management machine, in accordance with an embodiment of the disclosure. The rule activation page414can provide a user interface to enable a user to activate a rule. The rule activation page414can include drop-down boxes, radio buttons, etc. to enable the user to activate the rule.

We now turn toFIG.5.

FIG.5is a diagram depicting an example user interface500of a technical debt management machine, in accordance with an embodiment of the disclosure.

The example user interface500can be displayed by at least a portion of a display device. The example user interface500can include graphical user interfaces depicting a landing page502, an executive dashboard504, a workspace506, an administrative console508, or a combination thereof.

The landing page502can depict information describing capabilities of the technical debt management machine. The landing page502can include a search feature enabling a user to search for a feature of the technical debt management machine, an aspect of the technical debt management machine, an aspect of a rule, or a combination thereof. The landing page502can include a menu to enable efficient navigation through the features of the technical debt management machine. In examples, the landing page502can display metrics including, and not limited to, a technical debt score. In an example, the landing page502can be based on a persona. The landing page502can be configured to receive user input information describing an action to be performed by the technical debt management machine.

In nonlimiting examples, typical users of the landing page502can include an executive510, an analyst/architect512, an application administrator514, or a combination thereof.

The executive dashboard504can depict information describing a technical debt score for an enterprise (e.g. a numerical score for a plurality of software platforms of a company), a technical debt score heat map indicating details of a technical debt score, a list of technical debt by type and priority, a remediation plan, a list of remediation actions, or a combination thereof.

In nonlimiting examples, typical users of the executive dashboard504can include an executive510, an analyst/architect512, or a combination thereof.

The workspace506can depict information describing a potential user action, a search scope, a result of a scan, or a combination thereof. The workspace506can be configured to receive user input information describing an action to be performed by the technical debt management machine. Example pages of the workspace506are depicted inFIGS.4A-4F and6.

In nonlimiting examples, typical users of the workspace506can include a developer516.

The administrative console508can depict information describing meta model management, application settings, user administration, role application, rule catalogue management, or a combination thereof. The administrative console508can be configured to receive user input information describing an action to be performed by the technical debt management machine.

In nonlimiting examples, typical users of the administrative console508can include an application administrator514.

We now turn toFIG.6.

FIG.6is a diagram depicting a non-limiting example user interface600including a user display or portion thereof602with a home page604of a graphical user interface of a technical debt management machine, in accordance with an embodiment of the disclosure.

The home page604can depict an overall technical debt score606calculated from respective technical debt scores calculated for a plurality of different previously scanned objects, applications, or both. In examples, the home page604can depict an overall technical debt ratio608. In some embodiments, the homepage604can depict a technical debt by type. The homepage604can depict charts, graphs, heat maps, etc. depicting aspects of search results, calculations based on the search results, or a combination thereof.

We now turn toFIG.7.

FIG.7is a diagram depicting a non-limiting example user interface700including a user display or portion thereof702with a search results page704of a graphical user interface of a technical debt management machine, in accordance with an embodiment of the disclosure.

The search results page704can depict information describing a technical debt type706. The search results page704can include information, per-technical debt type, describing: a weight708, a score710, a number of applicable objects712(i.e. a number of scanned objects), a number of technical debt objects714(i.e. number of scanned objects in which technical debt is present), a remediation effort per object716(i.e. a number of estimated hours to remediate technical debt per object), a number of critical objects718(i.e. a number of scanned objects in which the presence of technical debt has a critical effect), a number of high objects720(i.e. a number of scanned objects in which the presence of technical debt has a high effect), a number of medium objects722(i.e. a number of scanned objects in which the presence of technical debt has a medium effect), a number of low objects724(i.e. a number of scanned objects in which the presence of technical debt has a low effect), an estimated debt in effort726, a budget to remediate critical objects728(i.e. a budget to remediate scanned objects in which the presence of technical debt has a critical effect), a budget to remediate high objects730(i.e. a budget to remediate scanned objects in which the presence of technical debt has a high effect), a budget to remediate objects732(i.e. a budget to remediate scanned objects in which the presence of technical debt has a medium effect), a budget to remediate low objects734(i.e. a budget to remediate scanned objects in which the presence of technical debt has a low effect), a total budget to remediate all scanned objects in which technical debt is present736, or a combination thereof.

We now turn toFIG.8.

FIG.8is a diagram depicting a non-limiting example user interface800including a user display or portion thereof802with a search results page804of a graphical user interface of a technical debt management machine, in accordance with an embodiment of the disclosure.

The search results page804can depict information describing a color-coded depiction of scores provided by at least one scanner. The search results page804can depict a color-coded depiction of a technical debt score for at least one application.

In an example, a score that meets or exceeds a first threshold can receive a green color-coded depiction of the score. In an example, a score that does not meet but exceeds the first threshold can receive a green color-coded depiction of the score.

In an example, a score that fails to meet or exceed a second threshold can receive a red color-coded depiction of the score. In an example, a score that does not meet the second threshold can receive a red color-coded depiction of the score.

In an example, a score that fails to meet the first threshold and meets or exceeds the second threshold can receive a yellow color-coded depiction of the score. In an example, a score that fails to meet the first threshold and exceeds the second threshold can receive a yellow color-coded depiction of the score.

In an example, a score that meets but does not exceed the first threshold and meets or exceeds the second threshold can receive a yellow color-coded depiction of the score. In an example, a score that meets but does not exceed the first threshold and exceeds the second threshold can receive a yellow color-coded depiction of the score.

We now turn toFIG.9.

FIG.9is a diagram depicting a non-limiting example user interface900including a user display or portion thereof902with a search results page904of a graphical user interface of a technical debt management machine, in accordance with an embodiment of the disclosure.

The search results page904can depict information describing a distribution of rule violations by technical debt type906. The search results page904can depict information, per the technical debt type906, describing: a distribution percentage (also known as a spread908), a number of applicable scanned objects910, a number of scanned objects912in which the technical debt is detected as a result of a rule violation, a number of critical objects914(i.e. a number of scanned objects in which the presence of technical debt has a critical effect), a number of high objects916(i.e. a number of scanned objects in which the presence of technical debt has a high effect), a number of medium objects in918(i.e. a number of scanned objects in which the presence of technical debt has a moderate effect), a number of low objects920(i.e. a number of scanned objects in which the presence of technical debt has a low effect), or a combination thereof.

We now turn toFIG.10.

FIG.10is a diagram depicting a non-limiting example user interface1000including a user display or portion thereof1002with a search results page1004of a graphical user interface of a technical debt management machine, in accordance with an embodiment of the disclosure.

The search results page1004can depict a reduced set of information describing a distribution of rule violations both per application and by technical debt type1006. The search results page1004can depict information, per the technical debt type1006, describing a distribution percentage (also known as a spread1008).

We now turn toFIG.11.

FIG.11is a diagram depicting a non-limiting example user interface1100including a user display or portion thereof1102with a search results page1104of a graphical user interface of a technical debt management machine, in accordance with an embodiment of the disclosure.

The search results page1104can depict information describing a distribution of rule violations both per application and by technical debt type1106. The search results page1104can depict information, per the technical debt type1106, describing: a number of applicable scanned objects1108, a number of scanned objects1110in which the technical debt is detected as a result of a rule violation, a number of critical objects1112(i.e. a number of scanned objects in which the presence of technical debt has a critical effect), a number of high objects1114(i.e. a number of scanned objects in which the presence of technical debt has a high effect), a number of medium objects in1116(i.e. a number of scanned objects in which the presence of technical debt has a moderate effect), a number of low objects1118(i.e. a number of scanned objects in which the presence of technical debt has a low effect), or a combination thereof.

We now turn toFIG.12.

FIG.12is a diagram depicting a non-limiting example user interface1200including a user display or portion thereof1202with a search results page1204of a graphical user interface of a technical debt management machine, in accordance with an embodiment of the disclosure.

The search results page1204can depict information describing a distribution of rule violations both per application and by priority1206, including: the priority1206, a remediation strategy1208, organized by the priority1206, to remediate technical debt detected as a result of a rule violation, a number of objects1210, per the respective remediation strategy1208, in which the technical debt can be remediated by the respective remediation strategy1208, an estimated number of hours1212, based on the number of objects1210, to remediate the technical debt by the respective remediation strategy1208, a budget allocation, per the respective remediation strategy1208to remediate the technical debt by the respective remediation strategy1208, or a combination thereof.

We now turn toFIG.13.

FIG.13is a diagram depicting a non-limiting example user interface1300including a user display or portion thereof1302with a search results page1304of a graphical user interface of a technical debt management machine, in accordance with an embodiment of the disclosure.

The search results page1304can depict information describing a technical debt reduction plan1306. In a non-limiting example, the technical debt reduction plan1306can include a per-level of criticality display that includes a level of criticality1308and a per-rule results summary1310. The per-rule results summary1310can include a list of technical debt remediation activities1312to be performed to mitigate the technical debt identified by the respective rule.

The technical debt reduction plan1306can include activities and assignments1314. The activities and assignments1314can include information describing an owner1316(i.e. a person1318responsible for performing at least a portion of one of the respective technical debt remediation activities1312). The activities and assignments1314can also include a start date1316, an end date1318, or a combination thereof of the at least the portion of the one of the respective technical debt remediation activities1312.

We now turn toFIG.14.

FIG.14is a diagram depicting a non-limiting example user interface1400including a user display or portion thereof1402with a search results page1404of a graphical user interface of a technical debt management machine, in accordance with an embodiment of the disclosure.

The search results page1404can depict information describing an estimated technical debt score in a form of a graph1406. In some examples, the search results page1404can depict information describing the estimated technical debt score in a form of a chart1408. The estimated technical debt score can be calculated (e.g. projected) using a present technical debt score, a quantity of rule violations, an estimated per-violation time to perform remediation activities, an estimated per-violated rule to perform remediation activities, an estimated per-violation rate of remediation activities, an estimated per-violated rule to perform remediation activities, or a combination thereof.

The graph1406can depict the estimated technical debt score over time. The graph1406can depict the estimated technical debt score on a daily basis, a weekly basis, a monthly basis, a quarterly basis, a half-year basis, a yearly basis, or a combination thereof. The graph1406can depict the estimated technical debt score on a linear scale, a logarithmic scale, or both. In examples, the graph1406can also estimate previous technical debt scores (e.g. calculated, previously estimated, or both).

The chart1408can depict the estimated technical debt score over time. The chart1408can depict the estimated technical debt score on a daily basis, a weekly basis, a monthly basis, a quarterly basis, a half-year basis, a yearly basis, or a combination thereof. In examples, the chart1408can also estimate previous technical debt scores (e.g. calculated, previously estimated, or both).

We now turn toFIGS.15A-15C.

FIGS.15A-15Care diagrams depicting non-limiting example rule information1500of a technical debt management machine, in accordance with an embodiment of the disclosure. The example rule information1500can describe information that can be used to identify a presence of technical debt. The example rule information1500depicted inFIGS.15A-15Care not limiting. In examples, the example rule information1500can be a constituent part of a technical debt management machine. The example rule information1500can be based on a technical debt type. The provided systems and methods advantageously provide techniques for adapting and changing rules and rule information based upon changes in aspects of technical debt.

The example rule information1500can be configured as a set of computer-executable instructions (e.g. software instructions), where the computer-executable instructions can be stored by a non-transitory computer-readable data storage device, a non-transitory computer-readable medium, or both.

In examples, the process management machine can include at least a portion of the example rule information1500configured as a set of computer-executable instructions (e.g. software instructions), where the computer-executable instructions can be stored on a non-transitory computer-readable data storage device, a non-transitory computer-readable medium, or both.

In examples, the example rule information1500can include information describing at least one information characteristic of: an instruction stored on a tangible processor-readable medium and configured to cause a processor to execute the instruction, an output of the processor following execution of the instruction, or a combination thereof.

In examples, the example rule information1500can include information describing, per-rule, at least one of: a rule title1502, a rule type1504, a technical debt type1506, a technical debt indicator1508, a rule scope1510, an object type1512, a priority level1514, a criticality1516(e.g., low, medium, high), a description1518, a discovery approach1520, a resolution approach1522, a source1524, a technical debt map1526, an active indication1528, at least one information characteristic whose presence in an object being scanned indicates technical debt and results in a violation of the rule, an amount that a technical debt score must be changed for a violation of the rule, a weight to be afforded to a violation of the rule, a script to be used during a search for an identifiable characteristic of technical debt, or a combination thereof.

In embodiments, the example rule information1500can include information describing, per rule, at least one of: at least one object which the rule can be compared, a respective remediation effort to cure the violation of the rule, a text description of the rule, a priority level of the rule, a keyword to be searched for during the comparing, an object type to which the rule applies, a candidate resolution approach to remediate a violation of the rule, a rule violation discovery approach, an application tag of the rule, an activation status of the rule, an inactivation status of the rule, a source of the rule, if the rule is configured to automatically execute during the comparing, or a combination thereof.

In examples, the technical debt type1506can include, and is not limited to, architecture debt, code debt, data debt, defect debt, design debt, documentation debt, governance debt, infrastructure debt, operations and maintenance debt, people debt, privacy protection debt, process debt, requirements debt, security debt, service debt, test automation debt, test debt, user experience debt, or a combination thereof.

In examples, the technical debt type1506can include, is not limited to, legacy code, hardcoded values, outdated libraries, outdated dependencies, inconsistent coding techniques, or a combination thereof.

The example rule information1500can include information describing, per rule, at least one information characteristic whose presence in an object being scanned indicates technical debt and results in a violation of the rule.

In an example, the information characteristic can include, and is not limited to: an outdated syntax, an outdated update, an outdated library, infrequently accessed portions of code, infrequently updated portions of code information from a deprecated library, infrequent code refactoring, an outdated test completion date, a cache invalidation error, an off-by-one error, frequent code errors, a reference to a specific value, an absence of a variable, an outdated dependency, an outdated library, a security breach, a code crash, and lack of documentation, lack of efficiency, a lack of query efficiency, a substandard privacy control, a non-standard data storage format, a lack of interoperability, a noncompliance with a regulatory standard, fragmented code, a monolithic architecture, a reliance on an obsolete application programming interface, a lack of integration with a related system, a broken link, a user interface defect, or a combination thereof.

In an example, the information characteristic can include, and is not limited to: an incompatibility between software, an unpatched vulnerability, a process bottleneck, a scaling problem, an inconsistent coding style, a static code analyzer error, an unexpected error arising in one module due to a change in a different module, a growing backlog of unresolved errors, a frequency of software patches, duplicate code, four code performance, decreasing code performance, features that do not address a user need, an artificial intelligence hallucination, computer-executable instructions known to generate an artificial intelligence hallucination, or a combination thereof.

In some examples, the rule information can be based on an information characteristic described by a published best practice, information characteristic described by an open source of information, an information characteristic resulting from a detrimental practice, an information characteristic resulting from user experience, or a combination thereof.

Exemplary embodiments discussed herein can provide certain advantages. These advantages can include those provided by the disclosed features.

Although systems and methods for generating a process management machine are described hereby in a language specific to structural features and/or methods, the appended claims are not necessarily limited to the specific features or methods described. Rather, the specific features and methods are disclosed as examples of implementations for generating a process management machine.

One or more embodiments of the disclosed subject matter are described herein with specificity to meet statutory requirements, but this description does not limit the scope of the claims. The claimed subject matter can be embodied in other ways, can include different elements or steps, and can be used in conjunction with other existing or later developed technologies. This description should not be interpreted as implying any required order or arrangement among or between various steps or elements except when the order of individual steps or arrangement of elements is explicitly noted as being required.

Embodiments of the disclosure are described more fully herein with reference to the accompanying drawings, which form a part hereof, and which show, by way of illustration, exemplary embodiments by which the disclosure can be practiced. The disclosure may, however, be embodied in different forms and should not be construed as limited to the embodiments set forth herein, rather, these embodiments are provided so that this disclosure will satisfy the statutory requirements and convey the scope of the disclosure to those skilled in the art.

Among others, the subject matter of the disclosure can be embodied in whole or in part as a system, as one or more methods, or as one or more devices. Embodiments can take the form of a hardware implemented embodiment, a software implemented embodiment, or an embodiment combining software and hardware aspects. For example, in some embodiments, one or more of the operations, functions, processes, or methods disclosed and/or described herein can be implemented by one or more suitable processing elements (such as a processor, co-processor, microprocessor, Central Processing Unit, Graphics Processing Unit, Tensor Processing Unit, Quantum Processing Unit, controller, or a combination thereof, as non-limiting examples) that is part of a client device, server, network element, remote platform (such as a Software as a Service (SaaS) platform), an “in the cloud” service, or other form of computing or data processing system, device, or platform.

The processing element or elements can be programmed with a set of executable instructions (e.g. software instructions), where the instructions can be stored on (or in) one or more suitable non-transitory computer-readable data storage elements, one or more suitable non-transitory computer-readable media, or both. In an embodiment, the set of instructions can be conveyed to a user through a transfer of instructions or an application that executes a set of instructions (such as over a network, e.g., the Internet). In an embodiment, a set of instructions or an application can be utilized by an end-user through access to a SaaS platform or a service provided through such a platform.

In an embodiment, the systems and methods disclosed herein can provide services through a SaaS or multi-tenant platform. The platform provides access to multiple entities, each with a separate account and associated data storage. Each account can correspond to a User, set of Users, an entity, a set or category of entities, a company, a business advisor, a set or category of Users, an industry, an organization, or a combination thereof, as examples. Each account can access one or more services, a set of which are instantiated in their account, and which implement at least a portion of one or more of the methods, features, or functions disclosed herein.

In an embodiment, one or more of the operations, functions, processes, features, or methods disclosed herein can be implemented by a specialized form of hardware, such as a programmable gate array, application specific integrated circuit (ASIC), or the like. An embodiment of the disclosure can be implemented in the form of an application, a sub-routine that is part of a larger application, a “plug-in,” an extension to the functionality of a data processing system or platform, or other suitable form. This description is, therefore, not to be taken in a limiting sense.

It should be understood that the present invention as described herein can be implemented in a form of control logic using computer software in a modular or integrated manner. Based on the disclosure and teachings provided herein, a person of ordinary skill in the art will know and appreciate other techniques to implement an embodiment of the disclosure using hardware or a combination of hardware and software.

Any of the software components, processes or functions described in this application can be implemented as software code to be executed by a processor using any suitable computer language such as at least one of Python, Java, JavaScript, C, C++, C# (“C Sharp”), Type Script, Java Script, Platform Client Application Programming Interface (API) Script, or Perl using procedural, functional, object-oriented, or other techniques. The software code can be stored as a series of instructions, or commands in (or on) a non-transitory computer-readable medium, such as a random-access memory (RAM), a read only memory (ROM), a magnetic medium such as a hard-drive, a jump drive, an optical medium such as a CD-ROM, or a combination thereof. In this context, a non-transitory computer-readable medium is almost any medium suitable for the storage of data or an instruction set aside from a transitory waveform. Any such computer readable medium can reside on or within a single computational apparatus and can be present on or within different computational apparatuses within a system or network.

According to one example implementation, the term processing element or processor, as used herein, can be a central processing unit (CPU), or conceptualized as a CPU (such as a virtual machine). In this example implementation, the CPU or a device in which the CPU is incorporated can be at least one of coupled, connected, or in communication with one or more peripheral devices, such as the user display device. In another example implementation, the processing element or processor can be incorporated into a mobile computing device, such as a smartphone or tablet computer.

The non-transitory computer-readable storage medium referred to herein can include a number of physical drive units, such as a redundant array of independent disks (RAID), a flash memory, a USB flash drive, an external hard disk drive, thumb drive, pen drive, key drive, a High-Density Digital Versatile Disc (HD-DVD) optical disc drive, an internal hard disk drive, a Blu-Ray optical disc drive, or a Holographic Digital Data Storage (HDDS) optical disc drive, synchronous dynamic random access memory (SDRAM), or similar devices or other forms of memories based on similar technologies. Such computer-readable storage media allow the processing element or processor to access computer-executable process steps, application programs and the like, stored on removable and non-removable memory media, to off-load data from a device or to upload data to a device. As mentioned, with regards to the embodiments described herein, a non-transitory computer-readable medium can include almost any structure, technology, or method apart from a transitory waveform or similar medium.

Certain implementations of the disclosed technology are described herein with reference to block diagrams of systems, and/or to flowcharts or flow diagrams of functions, operations, processes, or methods. It will be understood that one or more blocks of the block diagrams, or one or more stages or steps of the flowcharts or flow diagrams, and combinations of blocks in the block diagrams and stages or steps of the flowcharts or flow diagrams, respectively, can be implemented by computer-executable program instructions. In some embodiments, one or more of the blocks, or stages or steps may not necessarily need to be performed in the order presented or may not necessarily need to be performed.

The computer-executable program instructions described herein can be loaded onto a special purpose computer, a processor, or other programmable data processing apparatus to produce a specific example of a machine, such that the instructions executed by the computer, processor, or other programmable data processing apparatus create means for implementing one or more of the functions, operations, processes, or methods described herein. These computer program instructions can also be stored in a computer-readable memory that can direct a computer or other programmable data processing apparatus to function in a specific manner, such that the instructions stored in the computer-readable memory produce an article of manufacture including instruction means that implement one or more of the functions, operations, processes, or methods described herein.

While certain implementations of the disclosed technology have been described in connection with what is presently considered to be the most practical and various implementations, it is to be understood that the disclosed technology is not to be limited to the disclosed implementations. Instead, the disclosed implementations are intended to cover various modifications and equivalent arrangements included within the scope of the appended claims. Although specific terms are employed herein, they are used in a generic and descriptive sense only and not for purposes of limitation.

This written description uses examples to disclose certain implementations of the disclosed technology, and to enable any person skilled in the art to practice certain implementations of the disclosed technology, including making and using any devices or systems and performing any incorporated methods. The patentable scope of certain implementations of the disclosed technology is defined in the claims, and can include other examples that occur to those skilled in the art. Such other examples are intended to be within the scope of the claims when they have structural elements, functional elements, or both that do not differ from the literal language of the claims, or if they include structural elements, functional elements, or both with insubstantial differences from the literal language of the claims.

The use of the terms “a,” “an,” “the,” and similar referents in the specification and in the following claims are to be construed to cover both the singular and the plural, unless otherwise indicated herein or clearly contradicted by context. The singular portends the plural, where practicable. The terms “having,” “including,” “containing,” and similar referents in the specification and in the claims are to be construed as open-ended terms (e.g. meaning “including, but not limited to,”) unless otherwise noted. All methods described herein can be performed in any suitable order unless otherwise indicated herein or clearly contradicted by context. The use of all examples, or exemplary language (e.g. “such as”) provided herein, is intended merely to better illuminate embodiments of the disclosure and do not pose a limitation to the scope of the invention unless otherwise claimed. No language in the specification should be construed as indicating any non-claimed element as essential to each embodiment of the present invention.

The words “receiving,” “generating,” “extracting,” “determining,” “calculating,” and other forms thereof are intended to be open ended in that an item or items following any one of these words is not meant to be an exhaustive listing of such item or items or meant to be limited to only the listed item or items. The term “or” is used inclusively to refer to items in the alternative and in combination.

Different arrangements of the components depicted in the drawings or described above, as well as components and steps not shown or described are possible. Similarly, some features and sub-combinations are useful and can be employed without reference to other features and sub-combinations. Embodiments of the invention have been described for illustrative and not restrictive purposes, and alternative embodiments will become apparent to readers of this patent. Accordingly, the present invention is not limited to the embodiments described herein or depicted in the drawings, and various embodiments and modifications can be made without departing from the scope of the claims. The disclosed embodiments are merely exemplary of the disclosure, which can be embodied in various forms.