RISK AND DEPENDENCY TRACKING AND CONTROL SYSTEM

Abstract

A computing system includes a connection detection system that identifies a set of connected deliverables among a plurality of different deliverables in a data store and graph generator logic that generates a representation of a graph having nodes connected by edges, each node representing a deliverable and each edge connecting a pair of nodes corresponding to a connection between the deliverables represented by the pair of nodes connected by the edge. The computing system also includes a user interaction system that controls interaction with the plurality of different deliverables, the user interaction system comprises link setting logic that generates a link setting user interface mechanism that is actuatable to modify one or more connections and surfacing logic that controls a display to display the representation of the graph and the link setting user interface mechanism.

Description

CROSS-REFERENCE TO RELATED APPLICATION

The present application is based on and claims the benefit of U.S. provisional patent application Ser. No. 62/763,128, filed May 8, 2018, the content of which is hereby incorporated by reference in its entirety.

BACKGROUND

Computing systems are currently in wide use. Some computing systems host services that can be used by users of various different tenants. Each tenant can correspond to a different organization, that has a different set of users.

Many organizations are quite large and have many users. The users may work in different departments, generate different deliverables, and use the hosted services in different ways. Therefore, it can be difficult to communicate collaborative action information between various users.

The discussion above is merely provided for general background information and is not intended to be used as an aid in determining the scope of the claimed subject matter.

SUMMARY

A computing system includes a connection detection system that identifies a set of connected deliverables among a plurality of different deliverables in a data store and graph generator logic that generates a representation of a graph having nodes connected by edges, each node representing a deliverable and each edge connecting a pair of nodes corresponding to a connection between the deliverables represented by the pair of nodes connected by the edge. The computing system also includes a user interaction system that controls interaction with the plurality of different deliverables, the user interaction system comprises link setting logic that generates a link setting user interface mechanism that is actuatable to modify one or more connections and surfacing logic that controls a display to display the representation of the graph and the link setting user interface mechanism.

This Summary is provided to introduce a selection of concepts in a simplified form that are further described below in the Detailed Description. This Summary is not intended to identify key features or essential features of the claimed subject matter, nor is it intended to be used as an aid in determining the scope of the claimed subject matter. The claimed subject matter is not limited to implementations that solve any or all disadvantages noted in the background.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1A is a block diagram of one example of a computing system architecture.

FIG. 1B is a block diagram of one example of graph generator logic.

FIG. 1C is a block diagram showing one example of a deliverable.

FIG. 2 is a flow diagram showing one example of the operation of the architecture illustrated in FIG. 1 in generating and displaying a dependency risk graph.

FIGS. 3-5 are diagrams showing examples of dependency risk graph interfaces.

FIG. 6 is a diagram showing one example of an item information interface.

FIG. 7-8 are diagrams showing examples of dependency creation interfaces.

FIG. 9 is a diagram showing one example of an item information interface.

FIGS. 10-11 are diagrams showing examples of user notification interfaces.

FIG. 12 is a block diagram showing one example of the architecture illustrated in FIG. 1, deployed in a cloud computing architecture.

FIGS. 13-15 show examples of mobile devices that can be used in the architectures shown in the previous figures.

FIG. 16 is a block diagram showing one example of a computing environment that can be used in the architectures shown in the previous figures.

DETAILED DESCRIPTION

Many developer organizations are quite large and have many users. The users may work in several different teams or groups to develop different deliverables that are part of a larger project. The term deliverables broadly covers different objectives and projects that make up a larger project. For example, a deliverable can include functionality (such as code, tools, logic, etc.) that supports a story (e.g., “make the interface more user friendly”), customer promises (e.g., promised customer to increase performance during high load), scenarios (e.g., “Engineers need testing environment more analogous to lab setting”), and tasks (e.g., “check backwards compatibility with older OS”). It can be made up of deliverable packages or pieces of code (e.g., hardware driver, software class, API, etc.), bug corrections (e.g., fix shaders module from crashing during execution), etc.

A large project can often times have a scheduled release date at which point, all deliverables should be complete. However, as many deliverables are dependent on one another for completion, it is helpful for each individual deliverable to remain on schedule or, if a deliverable begins to deviate from its timeline, to see the effects of the deviation. For example, if there is a delay in completing a deliverable that has relatively few items dependent on it, this may have a small impact on the overall project. However, if there is a delay in completing a deliverable that has many items dependent on it, this may have a large impact on the project and increase the risk that the project will not meet its scheduled release date. A first deliverable that is dependent upon a second deliverable may be referred to below as ‘consuming from’ the second deliverable. Conversely the second deliverable may be referred to below as ‘producing for’ the first deliverable.

Tracking and effectively displaying an interactive tree of dependencies, with various control actuators, can allow a project manager or other user to see the bottle necks of a project and to control items in response. For example, a first team may be behind schedule, however, it may not be their fault. Instead it may be because a second team is behind in producing an item or deliverable that the first team is dependent on.

Further, providing a simpler interface to create links between deliverables may be useful. Currently, there is no simple means of creating links between deliverables in a team project environment.

FIG. 1A is a block diagram of one example of a computing system architecture 100. Architecture 100 illustratively includes a computing system 102, dependency/risk and control system 104, user devices 106-108 and other systems 110, all connected to one another either directly, or over network 112. Network 112 can be any of a wide variety of different types of networks, such as a wide area network, a local area network, a near field communication network, a cellular communication network, or any of a wide variety of other networks or combinations of networks.

In the example shown in FIG. 1A, user device 106 is shown generating user interfaces 114 for interaction by user 116. User 116 illustratively interacts with user interfaces 114 to control and manipulate user device 106 and some portions of computing system 102. Similarly, user device 108 is shown generating user interfaces 118 for interaction by user 120. User 120 illustratively interacts with user interfaces 118 in order to control and manipulate user device 108 and portions of computing system 102. Users 116 and 120 may be part of a single organization (or tenant). Therefore, they use their user devices 106-108, respectively, in order to use the services hosted by computing system 102.

In the example shown in FIG. 1A, computing system 102 illustratively includes one or more processors or servers 122, one or more data stores 124, a deliverable system 126, communication system 128 and it can include a wide variety of other service functionality 132. Processors or servers 122 can execute the functionality of deliverable system 126, data store interaction logic 142 and other service functionality 132. Data store 124 includes data relating to a plurality of deliverables 178. However, data store 124 can include other data as well, as indicated by block 179.

Before describing the remaining components of FIG. 1A it may be beneficial to describe a deliverable in greater detail with respect to FIG. 1C. FIG. 1C is a block diagram showing one detailed example of a deliverable 178. Deliverable 178 as shown includes a variety of different data components. However, deliverable 178 can include other items as well as indicated by block 1850.

Deliverable 178 illustratively includes ID data 1780. ID data 1780 is indicative of an identifier for the given deliverable 178. For example, and ID 1780 can be a number or other unique identifier used to track the deliverable in a database.

Deliverable 178 illustratively includes title data 1782. Title data 1782 can be indicative of a title of the deliverable 178. Title 1782 ideally is in a human readable language and allows a developer to identify the deliverable 178. This is opposed to ID 1780 which is primarily for computer identification (e.g., a unique identifier in a database). An example title may be “hardware driver for sound card.”

Deliverable 178 illustratively includes state data 1784. State data 1784 can include information on the current state of deliverable 178. For example, state data can include the developmental state of deliverable 178. For instance, possible states can include proposed, committed, started, completed or cut.

Deliverable 178 illustratively includes type data 1786. Type data 1786 can be indicative of the type of work item. For example, possible work item types include stories, customer promises, scenarios, deliverables, task groups, tasks or measures.

Deliverable 178 illustratively includes iteration data 1788. Iteration data 1788 can be indicative of the current iteration of deliverable 178. For example, an iteration can be the current version and/or build of the deliverable (e.g., v1.1.1).

Deliverable 178 illustratively includes description data 1790. Description data 1790 is indicative of the description of deliverable 178. Description 1790 can briefly describe the objective of the deliverable. An example description may be “Fix the bug issues when a user is in compatibility mode.”

Deliverable 178 illustratively includes priority data 1792. Priority data 1792 is indicative of the priority of deliverable 178. That is, a priority or importance of deliverable to the overall project of which deliverable is part of. Some examples of priority levels include very high, high, medium, low, very low, etc.

Deliverable 178 illustratively includes due date data 1794. Due date data 1794 is indicative of the due date of deliverable 178. A due date can be set by a manager or other user. In some examples, a due date is automatically generated based on its relationship to a greater project (e.g., a deliverable containing baseline code defining classes may have an earlier generated due date than a deliverable containing minor interface tweak tasks).

Deliverable 178 illustratively includes assignment data 1796. Assignment data 1796 is indicative of the user or team responsible for completing a given deliverable. For example, “hardware team” may be responsible for a deliverable titled “hardware driver for soundcard.”

Deliverable 178 illustratively includes risk measure data 1798. Risk measure data 1798 is a value associated with the risk of deliverable. A risk can be indicative of the likelihood of deliverable being completed by its due date (e.g., from due date data 1794). For example, some risk measures include ‘on track,’ ‘not on track,’ ‘at risk’, etc.

Deliverable 178 illustratively includes progress data 1799. Progress data 1799 is indicative of the completion progress of the deliverable. For example, progress may be measured in a percentage (e.g., 10%, 20%, 90%, etc.) or can be measured in different categories (e.g., started, in progress, near completion, etc.).

Deliverable 178 illustratively includes owner data 1800. Owner data 1800 is indicative of the owner of deliverable 178. An owner 1800 can be responsible for creating deliverable 178 and or ensuring that deliverable 178 is completed by its due date 1794. In some cases, owner 1800 is the only user able to change or modify any of the components of deliverable.

Deliverable 178 illustratively includes link data 1802. Link data 1802 is indicative of the relationships of a deliverable with other deliverables. As shown, a link can be in one of several different categories. As indicated by block 1804, deliverable can be linked to another deliverable as consuming from the other deliverable (e.g., the given deliverable is dependent upon another deliverable). As indicated by block 1806, the deliverable can be linked to another deliverable as producing for another deliverable (e.g., another deliverable is dependent on the given deliverable). As indicated by block 1808, a deliverable can be linked to another deliverable as being related to the other deliverable (e.g., while the deliverables are not dependent upon one another, they share similar dependencies or are similar in some other way such as having a similar title, description, assigned to the same or similar team, etc.). Related links, in some instances, are generated automatically based on a detection of some similarity between deliverables. Of course, deliverable 178 can be related to another deliverable in some other way as well, as indicated by block 1810.

Turning back to FIG. 1A, deliverable system 126 illustratively exposes functionality to users 116 and 120 (such as through a front-end system) that allows users 116 and 120 to perform deliverable management operations, such as creating a deliverable, modifying a deliverable, deleting a deliverable, etc. For instance, a manager can create a task (e.g., deliverable) and assign it to a user or team of users. Deliverable system 126 illustratively can detect that, and, in response, automatically generates a record of that in data store 124 via data store interaction logic 142. As another example, a user may update the status data 1784 of a deliverable 178 in data store 124 via deliverable system 126. The status may be indicated by the status data 1784 corresponding to the deliverable record. For instance, when a user completes the deliverable, they can change the status data 1784 to indicate that the deliverable is completed.

In one example, dependency/risk and control system 104 detects dependencies between deliverables 178, in data store 124 of computing system 102. Dependency/risk and control system 104 can automatically construct a graph identifying the various connections among the various deliverables 178 in the organization or tenant, with various control functionality. To illustrate these connections, the graph may have nodes connected by edges. Each node in the graph may represent a deliverable 178, and each edge may represent a dependency (or link represented by link data 1802) between deliverables 178 represented by the connected nodes. To complete these and other functions, dependency/risk and control system 104 includes dependency system 150, risk measure generator system 152, user interaction system 158, control signal generator 156, cross-system comparison logic 154 and can include other items as well, as indicated by 160. Dependency/risk and control system 104 illustratively includes processor(s)/server(s) 154 that can execute functionality of the logic components of the system.

Dependency system 150 illustratively accesses the data store 124, parses link data 1802 of the deliverables, and identifies connected deliverables in data store 124 and constructs a graph where nodes in the graph represent deliverables and edges in the graph represent dependencies and risk among those deliverables.

Update trigger detection logic 162 detects when it is time to construct or update the graph. This can be time-based, such as when an update interval runs, or it can be based on other criteria, such as a volume of dependencies that have been updated, a volume of new deliverables that are created, among other things. When the update trigger is detected, deliverable parsing logic 164 obtains the deliverables 178 in data store 124 and parses the data associated with each deliverable. For example, deliverable parsing logic 164 retrieves data on a plurality of deliverables 178 that includes the deliverable, ID data 1780, title data 1782, status data 1784, link data 1802, etc. Deliverable parsing logic 164 can also filter out deliverables that represent these that are not of interest to dependency/risk and control system 104.

Dependency generator logic 166 then uses the retrieved data to detect which deliverables are dependent, on, or otherwise connected with, each other. For example, if a software deliverable uses a hardware driver deliverable, dependency generator logic 166 detects the dependency of the software deliverable on the hardware driver deliverable. Dependency generator logic 166 can generate an indication of the dependency between the deliverables or a dependency tree indicative of a branching chain of dependencies among many deliverables. Graph generator logic 174 then uses this information to generate a graph as explained below and then controls data store 176 to store a representation of the graph. User inputs are detected and graph restructuring control operations are performed.

Graph generator logic 174 constructs the graph where nodes in the graph represent the deliverables involved in the detected dependency tree, and edges in the graph (which connect the nodes) represent dependency and risk between deliverables. For instance, if a first deliverable 178 has a dependency on a second deliverable 178, then one node in the graph will represent the first deliverable 178 and another node in the graph will represent the second deliverable 178. An edge connecting those two nodes will represent the dependency (or other link) between those two deliverables. This will be repeated for all of the deliverables of interest (e.g., for all deliverables that meet a user set filter or otherwise identified as of interest). Graph generator logic 174 then controls data store 176 to store a representation of the graph.

Risk measure generator system 152 can generate a risk measure or metric corresponding to each of the nodes in the graph or edges in the graph. Risk measure generator system 152 illustratively includes connection identifier logic 182, connection metric generator logic 184, inheritance processing logic 186, risk metric generator logic 188, and it can include a wide variety of other items 194.

Connection identifier logic 182 accesses a source of deliverables (e.g. data store 124) and identifies connections (e.g., from link data 1802) between the deliverables that influence risk of the deliverables. For example, connection identifier logic 182 can determine a connection based upon one deliverable being dependent upon another. As another example, connection identifier logic 182 can determine which deliverables a given team is producing for.

Risk metric generator logic 185 generates a risk metric for a connection, node, deliverable, team, project, etc. For example, deliverables that are behind schedule are considered to be at risk of not meeting their due date and deliverables that are very behind schedule are considered to be at a greater risk. In one example, risk metric generator logic 185 uses progress data 1799 in combination with due date data 1788 of a given deliverable 178 to calculate the risk of the deliverable. Risk metric generator logic 185 can utilize inheritance processing logic 186 to inherit risk from the deliverables, teams, etc. that a given item is consuming from, and aggregates these metrics to generate an overall risk metric for the item for which the risk metric is being completed. For example, if a team project is consuming from a deliverable that is at high risk, then the team project can also inherit this high risk (in some instances, regardless of the team's other progress).

Therefore, connection identifier logic 182 first identifies a number of edges that connect to each node. Connection metric generator logic 184 generates a connection metric, for each node, based upon the number of edges that connect to it. For instance, if a node under consideration has many edges that connect to it, it will have a greater connection metric than a node that has fewer edges connecting to it. Inheritance processing logic 186 generates an inheritance value for each node, based upon the connection metrics and risk metric scores of the nodes to which it is connected.

Risk metric generator logic 188 then generates a risk metric based upon the risk measure of the node and the metric inheritance value for each node. The risk metrics can be output to cross-system comparison logic 154 where the values for the various nodes in the graph representing the organization to which deliverables 178 belong can be compared to values for nodes in graphs representing other projects, organizations or tenants. The results of those comparisons, along with the risk metrics generated by risk measure generator system 152, can be output to control signal generator 156. Control signal generator 156 illustratively generates control signals to control user interaction system 158 based upon those risk metrics. For instance, it can control notification logic 168 to automatically send certain communications to various users, based upon the risk metric generated for the node representing those deliverables. Control signal generator 156 can also generate control signals to control surfacing logic 198 to surface the information for an administrative user, or other users. Control signal generator 156 can also generate control signals to control dependency/risk and control system 104 to send certain communications to other systems 110, where they may be stored, or further processed.

User interaction system 158 surfaces a user interface, utilizing surfacing logic 175, for users 116 and 120 to interact with the systems of architecture 100. For example, user interaction system 158 can surface graphs stored in data store 176. User interaction system 158 includes user interaction detection and control logic 167, notification logic 168, deliverable selection logic 169, filtering logic 171, link setting logic 173, and surfacing logic 175. However, user interaction system 158 can include other items as well, as indicated by block 177.

User interaction detection and control logic 167 can detect user interactions. User interactions can include actuating user interface mechanisms (e.g., nodes, edges, filters, buttons, select dropdowns, etc.). In response to a user interaction user interaction detection and control logic 167 can control computing system 102 or computing system 104 to complete an action. For example, in response to a user actuating an edge, computing system 102 can modify link data 1802 of the deliverables, represented by the nodes that are connected to the actuated edge, to reverse the dependency between the deliverables. As another example, in response to a user actuating a filter select mechanism, user interaction detection and control logic 167 can control deliverable parsing logic 164 to retrieve deliverables in accordance with a newly selected filter and control graph generator logic 174 to generate and display a new graph.

Notification logic 168 can generate a notification to users 116 and 120. A notification can be indicative of a change in a deliverable 178. For example, when link data 1802 of a deliverable is changed, notification logic 168 can generate a notification of this change. Some examples of notifications are shown and described below with respect to FIGS. 10-11.

Other items of logic, such as logic 169, 171 and 173 allow a user to control the computing system. These will now be discussed.

Deliverable selection logic 169 can generate a user interface mechanism that a user 116 or 120, actuates to create a deliverable, select a deliverable, modify a deliverable, delete a deliverable, view information about a deliverable, etc. For example, actuating such a user interface mechanism can allow a user to generate a new deliverable. As another example, actuating such a user interface mechanism can allow a user to modify title data 1782 or progress data 1799. These are examples only.

Filtering logic 171 can generate user interface mechanisms that a user 116 or 120 actuates to filter the deliverables displayed in a graph or surface, by some category or data set. For example, filtering logic 171 can filter a set of deliverables by risk assessment data 1798 (e.g., only show deliverables that have a high risk metric). As another example, filtering logic 171 can filter a set of deliverables by project (e.g., only show deliverables that are in a given project).

Link setting logic 173 can generate user interface mechanisms that a user 116 or 120 actuates to modify link data 1802 (e.g., create a link, select a link, modify a link, delete a link, view information of a link, etc). A link, for example may be a dependency between two deliverables. A user interface mechanism that can be actuated to control the system to create a link between deliverables is shown in FIGS. 7-8.

FIG. 1B is a block diagram showing graph generator logic 174 in greater detail. Graph generator logic 174 includes node generator logic 200, edge generator logic 202, summary generator logic 204 and can include other items as well as indicated by block 205. Node generator logic 200 generates a node interface component that corresponds to a deliverable. To generate a node, node generator logic 200 includes label generator logic 206, icon generator logic 208, dependency count generator logic 210, information generator logic 212, collapse logic 214, centering logic 216, center node generator logic 218, and peripheral node generator logic 220. However, node generator logic 200 can include other items as well is indicated by block 224.

Label generator logic 206 generates a label that corresponds with a generated node. Label generator logic 206 can access data store 124 to retrieve given information. For example, a label may indicate the title of the deliverable, as defined in title data 1782. In another example, a label may indicate the team that is responsible for the deliverable, as defined in assignment data 1796. These are examples only.

Icon generator logic 208 generates an icon corresponding to the generated node. For example, an icon can be indicative of the type of deliverable, the team responsible for the deliverable or it can be indicative of some other attribute of the deliverable represented by the node. In one example, nodes that represent teams have a different icon than nodes that represent deliverables or other items. These are examples only.

Dependency count generator logic 210 generates an indication of the quantity of deliverables consuming from or producing for the deliverable represented by the node. Dependency count generator logic 210 can utilize connection identifier logic 182 to identify and count the number of connections or links to a given node. For example, if a node is producing for ten other deliverables, dependency count generator logic 210 can generate an indication of this (e.g. the number 10 on the edge connecting the nodes).

Information generator logic 212 generates additional information for the generated node which represents a specific deliverable. For example, information generator logic 212 can generate an additional information window or pane that contains further information corresponding to the deliverable (e.g., due date data 1794, team responsible for deliverable, iteration data 1788, status data 1784, type data 1786, etc.).

Collapse logic 214 generates an interface mechanism that is actuated to allow a set of generated nodes to be collapsed into a single node. For example, a generated node may have three dependencies that are also each represented by their own node. Collapse logic 214 provides an input mechanism that is actuated and controls the system to collapse these three additional dependent nodes into one node that indicates how many previous nodes there were. For instance, the collapsed node may be displayed as a node that indicates a number 3.

Centering logic 216 provides an input mechanism that is actuated to center a specific node. For example, there may be a center node, and several peripheral nodes that are not centered. Centering logic 216 provides an input mechanism that is actuated to shift one of the peripheral nodes to the center (e.g., to show a dependency tree from the peripheral node rather than the previous center node). This may require generating a new graph that includes a greater or fewer number of nodes (that represent different items/deliverables/teams) than the previous graph.

Center node generator logic 218 generates center-node-specific user interface mechanisms. For example, it can generate the title, node body, node outline, node shape, icon, etc of the center node.

Peripheral node generator logic 220 generates peripheral-node-specific user interface mechanisms that identify the peripheral nodes. For example, it can generate the title, node body, node outline, node shape, icon, etc. of the peripheral node. Peripheral node generator logic 220 can determine the arrangement of the peripheral nodes. For example, the nodes may be arranged in various layers with some symmetry around the center node.

Edge generator logic 202 generates edges that connect various nodes displayed on a user interface. As discussed above, an edge can be indicative of a relationship between the two nodes. For example, the edge can be indicative of a dependence of one of the nodes on the other node. To generate these edges, edge generator logic 202 illustratively includes node identification logic 230, dependency direction logic 232, risk indication generator logic 234, dependency count logic 236, and reverse logic 238. However, edge generator logic 202 can include other items as well, as indicated by block 240.

Node identification logic 230 identifies two nodes that should have an edge generated between them. For example, node identification logic 230 accesses a database of dependencies (e.g. data store 124), examines the records corresponding to the nodes and determines that one node produces for or consumes from another node. When a node is dependent on or depends from another node, node identification logic 230 can determine that an edge should be generated between the nodes.

Dependency direction logic 232 identifies a direction of dependency, and generates a user interface mechanism, indicative of the direction of dependency. For example, when a deliverable represented by one node is consuming from another deliverable represented by another node, an arrow may indicate the dependency by pointing from the ‘consuming node’ to the ‘producing node.’

Risk indication generator logic 234 generates a user interface mechanism that is indicative of the risk of an item or connection. For example, risk indication generator logic 234 can generate a different edge based on the determined risk. A red edge, for instance, can be indicative of a high-risk dependency and a green edge can be indicative of a low risk dependency. As another example, risk indication generator logic 234 can generate an indication highlighting a node if it is at high risk.

Dependency count logic 236 can generate an interface mechanism that is indicative of the number of deliverables that are dependent on an item. For example, an edge may include a number that shows how many deliverables are represented by the edge as being dependent.

Reverse logic 238 can generate a user interface mechanism that allows a reversal of dependency. For example, a first node may be connected to a second node by an edge and reverse logic 238 generates a user interface mechanism that, when actuated, reverses the dependence between the first and second node (e.g., if the first node is dependent on the second node, activating the interface mechanism will then make the second node dependent on the first note.). It does this by automatically accessing and changing link data 1802 of the deliverable represented by the node. The graph can then be re-rendered to show the new dependence.

Summary generator logic 204 generates a table summary of the deliverables represented by nodes, generated by node generator logic 200. To generate this summary, summary generator logic 204 illustratively includes identifier generator logic 250, status generator logic 252, and risk state generator logic 254. However, summary generator logic 204 can include other items as well as indicated by block 256.

Identifier generator logic 250 generates a user interface mechanism that is indicative of an identifier for a given node, and hence a given deliverable. For example, nodes/deliverables can be identified based on their title or team. In one example, identifier generator logic 250 generates a column of data in a table that indicates a title of an item represented by a line in the table.

Status generator logic 252 generates a status for the item represented by the node. For example, a status of a deliverable that has been proposed but on which work has not begun, may be given the status of proposed. As another example, a deliverable that is currently being developed, can be given a status of committed, or in progress. As another example, a deliverable that has been removed from development, can be given a status of “cut.” In one example, status generator logic 252 generates a column of data in a table that indicates a status of an item represented by a line in the table.

Risk state generator logic 254 generates a user interface mechanism, indicative of the risk status of the node or deliverable. For example, a node or deliverable can have a risk status related to its present completion. For instance, a deliverable that is farther along in its completion than its estimated progress, can have a risk status of being “on track.” In another instance, a node or deliverable that is only 10% complete, but is due shortly, will have a risk status of “at high-risk.” In one example, risk state generator logic 254 generates a column of data in a table that indicates a risk status of an item represented by a line in the table.

FIG. 2 is a flow diagram showing one example of an operation of displaying a set of deliverables. Operation 201 begins at block 260 where a first deliverable is created. A developer can create a deliverable, as indicated by block 261. For example, a developer that discovers a bug in a deliverable can create a task/deliverable indicative of correcting the bug.

A manager can create a deliverable, as indicated by block 262. For example, a manager that is in charge of a project can create a team, deliverable, item, etc. Deliverables may be created in other ways as well as indicated by block 263. For example, a deliverable may be automatically created based on the creation of another deliverable. For instance, a deliverable relating to a specific display device may generate a another deliverable related to a hardware driver to run the display device. In another instance, when an error is detected, a deliverable item may be created, indicative of fixing the bug that created the error.

Operation 201 proceeds at block 270, where a second deliverable is created. The second deliverable can be created in similar ways as the first deliverable. For example, a developer can create a deliverable, as indicated by block 264. As another example, a manager can create the deliverable, as indicated by block 265. However, the deliverable can be created in another way as well, as indicated by block 266.

Operation proceeds at block 275 where a link is created between the deliverables. A developer can create the link, as indicated by block 267. For instance, a developer may know that the deliverable they are working on is dependent upon another deliverable and can control the system to make the connection. For example, the developer actuates a user interface mechanism, generated by the system, to control the system to make the link.

A manager can create the link, as indicated by block 268. For instance, a manager, that is managing a project that consists of several deliverables, knows that one deliverable is required for another deliverable to be completed. Accordingly, the manager could control the system to create a link to show the first deliverable is dependent on the second deliverable.

A link can be created between deliverables in other ways as well, as indicated by block 269. For example, a link between the deliverables can be automatically generated when it is determined that one deliverable must be completed before another deliverable can be completed. For example, assume that a first deliverable is built on an API, where the API is also a second deliverable. In that case, the second deliverable must be completed first, and hence the system can identify the first is dependent on the second and modify the records to reflect that.

Operation 201 proceeds at block 280, where node generator logic 200 generates a node. Generating a node may involve generating a number of components. Label generator logic 206 can generate a label for the node, as indicated by block 271. For example, a label can indicate a title of the deliverable, a team responsible for the deliverable, or can indicate other characteristics of the deliverable as well.

As indicated by block 272, when generating the node, a risk indicator can be generated by risk indication generator logic 234. A risk indicator can be indicative of a current risk status of the item represented by the node (e.g., whether a deliverable is on track or whether the items the deliverable depends on are on track.)

Generating a node, in block 280, can comprise other steps as well as indicated by block 273. For example, icon generator logic 208 can generate an icon for the node. As another example, dependency count generator logic 210 can generate an indicator of either the number of items dependent on the node, or the number of items the node is dependent on.

Operation 201 proceeds at block 285 where edge generator logic 202 generates an edge between the two nodes. Generating an edge between two nodes can comprise generating a variety of components.

As indicated by block 274, while generating the edge, a dependency direction indicator can be generated by dependency direction logic 232. For example, a dependency direction indicator can include an arrow pointing from the producing node to the consuming node. In other examples, the dependency direction indicator can be another shape other than an arrow.

As indicated by block 276, generating an edge can also include risk indication generator logic 234 generating a risk indicator. A risk indicator can be indicative of the risk status associated with the connection represented by the edge. For example, a risk indicator can be generated on an edge between two nodes. In some examples, a node represents more than one deliverable and an edge between such a node indicates that more than one node has a relationship with the other connecting node.

Operation 201 proceeds at block 290, where the nodes and edges are arranged according to a set of rules. Based on one set of rules, the nodes and edges are arranged in a graph that comprises a center node, and a plurality of peripheral nodes that are interconnected by edges.

In one example, the center node can be dependent upon the peripheral nodes, as indicated by block 277. In another example, the peripheral nodes are dependent upon the center node, as indicated by block 278.

One set of rules may dictate that the peripheral nodes are arranged in generally concentric arrangement based upon layers of dependencies, as indicated by block 279. For example, the center node can be a first layer. A second layer of peripheral nodes are nodes that directly dependent upon the center node, and a third layer of peripheral nodes are nodes that are directly dependent upon nodes in the second layer, etc. As stated above, peripheral nodes may be collapsed into a singular node that represents a plurality of deliverables.

The nodes and edges may be aligned in a symmetrical way, as indicated by block 281. For instance, the levels of peripheral nodes can be evenly distributed around the central node. As indicated by block 282, some nodes may be connected to multiple other nodes in a branching fashion. For example, some of the nodes shown in FIG. 5, discussed in greater detail below, are connected in a branching fashion.

Operation 201 proceeds at block 291 where control actuators or user input mechanisms are created, and user input is received through the generated user input mechanisms. User input can be an actuation of one or more user input mechanisms that are displayed by surfacing logic 175. User input mechanisms can include filter mechanisms, dependency reversal mechanisms, information request mechanisms, modify node/edge mechanisms, delete nodes/edge mechanisms, create node/edge mechanisms, etc.

Operation 201 proceeds at block 292 where the system is controlled based on the user input/actuations. Examples of system control based on the user input are indicated by blocks 293-296.

As indicated by block 293, dependency system 150 can change deliverable data. For instance, changing deliverable data can include creating a new deliverable 178 in datastore 124 or deleting a deliverable 178 in data store 124. In another instance, changing deliverable data can include modifying a data component of a deliverable 178 (e.g., those shown in FIG. 1C).

As indicated by block 294, in response to user actuation, graph generator logic 174 can recreate and re-render a graph. This action can be taken after, for example, a user changes a dependency. Re-rending the graph, in this instance, would show an updated location of one or more nodes and/or edges.

As indicated by block 295, in response to user actuation, deliverable parsing logic 164 can modify the deliverables displayed based on a filter change by the user actuation. After a filter change, the graph can also be recreated or re-rendered to remove any data that does not meet the new filter settings.

As indicated by block 296, the system can be controlled in other ways as well. For example, assume a user actuated an interface mechanism to request more information on a node. In response to this actuation, user interaction system 158 can generate a deliverable information pane, one example of which can be described with respect to FIG. 6.

FIG. 3 is a diagram showing one example of an interface 300. Interface 300, as shown, includes a variety of different panes. Graph pane 310 shows a risk graph. Summary pane 328 shows a summary of the objects displayed in graph pane 310. Filter pane 350 shows the current filters applied to the deliverables displayed in graph pane 310.

Graph pane 310 includes a legend 312 that indicates to a user what the various graphics represent. For example, legend 312 shows that thicker edges represent higher risk dependencies. As shown, edge 320-1 is a low risk dependency. While edge 320-2 represents a high-risk dependency.

Center node 316, as shown, represents a team that the user is interested in. However, in another example center node 316 may represent a deliverable or some other item. Center node 316 is surrounded by peripheral nodes 318.

Sorting mechanism 314 can be actuated by a user to sort or arrange the graph in different ways. As shown in FIG. 3 sorting mechanism 314 has been actuated to select “Consuming from Teams.” Therefore, the center node 316 is consuming from peripheral nodes that represent teams.

In other examples, peripheral nodes 318 can represent a deliverable or some other item.

Edges 320 connect center node 316 and peripheral nodes 318. Because of the filter chosen through sorting mechanism 314, edges 320 represent a dependence of a peripheral node 318 on the center node 316. However, if the sorting mechanism 314 was actuated to apply a different filter, center node 316 may be producing for peripheral nodes 318.

FIG. above shows that dependency count indicators 322 are attached to edges 320. Dependency count indicators are indicative of the number of deliverables associated with this dependency. For example, peripheral node 318-1 is producing fifteen deliverables for the team, represented by center node 316. This is indicated by a number fifteen being shown by dependency count indicators 322-1.

Each center node 316 and peripheral node 318 include a label 324 and a logo 326. In other examples, these nodes may not have either label 324 and/or logo 326. Label 324 can be indicative of the title of the deliverable or team represented by the node. Logo 326 can be indicative of a deliverable or team associated with the given node. For example, deliverables or teams that have to deal with graphics or videos may include a camera logo, while a team or deliverable that has to deal with hardware may include a circuit board as logo 326. These are examples only.

Summary pane 328 includes title 330, count indicators 332, at risk indicator 334, caution indicator 336, on-track indicator 338 and list view pane 340. Title 330 can be indicative of the filter applied by filter pane 350 and sorting mechanism 314, or can be indicative of some other information, (e.g., a team or deliverable name).

Count indicators 332 can be indicative of the number of items displayed, given the current filters applied. For example, the current filter may limit the deliverables shown in the graph to those in a given project.

At risk indicator 334 is indicative of the number or percent of items shown or replaced in the graph that are in an at-risk status. For example, an at-risk status means that this item is either behind schedule order depends on an item that is behind schedule.

Caution indicator 336 is indicative of the number or percent of items displayed or represented in the graph that have a caution status. For example, a caution status may indicate that the deliverable is mostly on track but slightly behind schedule or depends on a deliverable that is slightly behind schedule. In another example, the item with the caution status may depend on many deliverables and all deliverables are on schedule except for a small minority which may be behind schedule.

On-track indicator 338 is indicative of the quantity of items displayed that currently have an on-track status. An on-track status can include items that are ahead of schedule or on schedule to meet their due date.

List view pane 340 comprises a table, indicative of the risk status, state and title of the deliverables, teams or other items displayed in, or represented by, graph pane 310. For example, the top item is shown as “at risk” and its state is “cut.” The second item displayed is “at risk” and is in the state of “proposed and committed.” These are examples only.

Filter pane 350 includes a variety of filters 352 that filter the deliverables, teams or other items that are displayed in graph pane 310 and summary pane 328. Some of the filters include filtering by project, iteration, product family, product, release, dependencies, state, risk assessment, value, priority and rank. For example, a project may be a story, family of products, customer promise, etc.

FIG. 4 is a diagram showing one example of a user interface. The items in FIG. 4 are similar to those of FIG. 3 and they are similarly numbered (e.g., graph pane 310 in FIG. 3 is similar to graph pane 410 in FIG. 4.) Graph pane 410 illustratively includes similar items, legend 412, sorting mechanism 414, center node 416, peripheral node 418, edge 420 and dependency count indicator 422.

As shown, sorting mechanism 414 has been actuated in a different way than sorting mechanism 314. In FIG. 4, sorting mechanism 414 has been actuated to select “producing for teams.” Accordingly, center node 416 and peripheral nodes 418 have been chosen and arranged such that center node 416 produces for all peripheral nodes 418. As shown, edge 420-1 is an arrow pointing from center node 416 to peripheral node 418 and indicating a dependency of peripheral node 418 on center node 416. Dependency count indicator 422 is coupled to edge 420. Dependency count indicator 422 is indicative of the number of items produced by the producing team (represented by center node 416) for the consuming team (represented by a peripheral node 418).

FIG. 5 is a diagram showing one example of an interface 501. Interface 501 includes graph pane 510, summary pane 528 and filter pane 550. These items are similar to those shown in FIGS. 3 and 4 but have some differences. For example, in FIG. 5, sorting mechanism 514 has been actuated to select ‘producing for stories.’ Accordingly, center node 516 is producing for the peripheral nodes 518.

For instance, center node 516 is producing for peripheral node 518-1, as indicated or represented by edge 520-1. Peripheral node 518-1 in turn, is producing for peripheral nodes 518-2, as indicated by edge 520-2. As shown, there are three layers of notes including a center node layer, a first peripheral node layer, and a second peripheral node layer. In other examples, there may be a greater or lesser number of layers of nodes, depending on the chain of dependencies.

In one example, some or all of the displayed items are actuators that can be actuated by the user to perform one or more functions. Clicking on or actuating a node, for instance, may bring up an information interface corresponding to that node. FIG. 6 shows one example of this.

FIG. 6 is a diagram showing one example of a user interface for a deliverable information interface 600 that is displayed when the user actuates a node representing a deliverable. Interface 600 includes a label 602 that identifies the deliverable or team represented by the node that was actuated and that is the subject of interface 600. Icon 606 is an icon for the identification of the deliverable or team that is the subject of interface 600. Label 604 is indicative of a description of the subject of interface 600.

User indicator 608 is indicative of the current user or user assigned as a contact for the item of interest in interface 600. Commenting mechanism 609 initiates an interface where comments may be given or viewed.

Status indicator 610 is indicative of the status of the item of interest in interface 600. For example, status indicator 610 shows that the status of the item of interest, is proposed.

Link creation mechanism 612 can be actuated by a user to generate an interface for creating a link between the current item and another item. For example, clicking on link creation mechanism 612 opens an interface, such as the one shown in FIG. 7. However, clicking on status indicator 610 may initiate a different type of linking creation system or interface as well.

Parent mechanism 614 allows a user to select or view a parent of the current item (e.g., a parent may be an item that is producing for the current item). Child mechanisms 616 allow a user to change or view the items that the current item is producing for. For example, there are two items shown that are consuming from the current item.

Related items mechanism 618 allows a user to view or edit items that are related to the current item. For example, related items may be items that are not dependent upon one another, but share similar dependencies or relations. Viewing related items may allow a user to identify a previously missed dependency. For instance, in a large project some related items may actually be dependent upon one another, but not manually identified as such.

FIG. 7 is a diagram showing an interface 700 for creating a dependency between two items. Interface 700, as shown, includes an information pane 702 (similar to the interface of FIG. 6) and a create link pane 704. Create link pane 704 can be used to create a link or dependency between items. Create link pane 704 includes an external group mechanism 706 that toggles an interface that displays items outside of the current group. As shown, external group mechanism 706 is in the negative status. Actuating external group mechanism 706 into a positive status can generate an interface similar to interface shown in FIG. 8.

Link pane 704 includes a deliverable mechanism 708 where a deliverable or a current item has been preselected. For example, since the create link pane was generated from information pane 702 that was indicative of deliverable 17635081, deliverable mechanism 708 has been prefilled with deliverable 17635081. In other examples, deliverable mechanism 708 has not been preselected and instead is replaced by deliverable mechanism 710. Deliverable mechanism 710 allows a user to select, delete, or create a new deliverable that currently does not exist. Select deliverable mechanism 712, instead, allows a user to select a deliverable that currently exists. For example, select deliverable mechanism 712 can be a drop-down menu where a list of selectable deliverables is populated. In another example, select deliverable mechanism 712 includes an auto complete select user interface mechanism.

Reverse mechanism 714 allows a reversal of dependency between the selected items. For example, the items on the left are considered the producers and the items on the right are the consumers (e.g., the items on the right-hand side are dependent upon the items on the left-hand side). When reverse mechanism 714 is actuated it reverses the dependency roles. For example, the consumer will be on the left and the producer will be on the right. It also controls the system to modify the records (e.g. link data 1802) corresponding to the two deliverables to indicate the changed dependency.

Create interaction mechanism 716 can be actuated for a creation of the chosen items. Cancellation mechanism 718 can be actuated to a cancellation of link creation, regardless of the data entered.

FIG. 8 is a diagram showing one example of an interface 700 for link creation. Interface 800 is similar to the interface of FIG. 7. However, external group mechanism 706 has been actuated. Link pane 704 includes group select mechanism 720. Group select mechanism 720 allows a user to select from a group of deliverables that are different than the group that the user belongs to. This may be especially useful when developing in a network of a variety of different applications, projects, etc. Previous attempts to create dependencies between items lacked the ability to link between different groups.

FIG. 9 is a diagram showing an example user interface displaying unmapped item information. Interface 900 includes an unmapped items pane 901. Unmapped items pane 901 includes labels 902. Labels 902 can be indicative of the current work item title, identifying number, associate team or project, etc. Unmapped items pane 901 also includes iterator mechanism 903. Iterator mechanism 903 allows a user to iterate through all the various unmapped work items (given the current filter setting chosen in filter pane 950). As shown, iterator mechanism 903 indicates the current item is item 1 of 4 and includes a mechanism to iterate to the next item (e.g., items 2-4). In other examples iterator mechanism 903 can comprise a different type of iterator mechanism.

Unmapped items pane 901 includes a status chart 904. Status chart 904 shows the status of all the unmapped deliverables (given the filter setting set and filter pane 950). Status chart 904 includes a pie chart showing the different statuses of the deliverables. As shown by the pie chart, one deliverable is committed, and the other three deliverables are proposed. In another example, status chart 904 can include a different chart than a pie chart, as well. Using a chart to display this information can be helpful in assessing the status of a project. For example, in the past, viewing a large project consisting of many work items was complicated, as many items were not properly linked to one another.

Unmapped items pane 901 includes a list view 905. List view 905 is a list view of all the unmapped items (“all” unmapped items that meet the selected filter criteria in filter pane 950). As shown list view 905 includes several work items 906. Work items 906 are each represented by a row with columns indicating a risk assessment, status, logo, and title. In other examples, the row representing work item 906 can include other information as well. Actuating a work item 906 may direct a user to an information interface of the given work item (such as the interface shown in FIG. 6), a risk graph centered on the given item (such as the interfaces shown in FIGS. 3-5) or can allow a user to edit the work item.

FIG. 10 is a diagram showing one example of a notification. Notification 1000 includes a header 1002 and body 1004. Header 1002 is indicative of the subject of the notification. For example, in notification 1000, the subject of notification 1000 is that a dependency has been filed on a work item or team that the user receiving notification 1000 is working on. The dependency has been filed by a user named “Jane Doe.” For example, Jane Doe could have used the interface of FIGS. 7-8 to generate a link between items/deliverables. When this link was made, notification logic 168 may have generated notification 1000 to notify any party associated with the linked items/deliverables.

Body 1004 is indicative of greater detail of the notification 1000. As shown, body 1004 includes subject item indication 1006, target item indication 1008, target item indication 1010 and workflow indication 1012.

Subject item indication 1006 is indicative of the subject item/deliverable of notification 1000. For example, as shown, dependency deliverable 17863052 is the subject item of notification 1000. The title of deliverable 17863052 is “Developers get consistent in office execution experience as lab run through.” This work item/deliverable is a scenario work item, which means the work item is a goal for developers to get an in-office execution experience that is consistent with a typical lab run through.

Action indication 1007 is indicative of the action being completed on or involving the subject item (indicated by subject item indication 1006). As shown, action indication 1007 indicates that the subject item (indicated by subject item indication 1006) is producing for the target items (indicated by target item indication 1008 and target item indication 1010).

Target item indication 1008 is indicative of a target item which is somehow related to the action on subject item. For example, as shown, the target item (indicated by indication 1008) is consuming from the subject item (indicated by indication 1006). Target item indication 1008, as shown, represents an item/deliverable that is a scenario, its identified by number 15668185 and is titled “Developers in IDE have a testing interloper workflow robust enough to support execution workflows.”

Target item indication 1010 is also indicative of a target item which is somehow related to the action on subject item. For example, as shown, the target item (indicated by indication 1010) is consuming from the subject item (indicated by indication 1006). Target item indication 1010 is indicative of a deliverable/item identified by number 15798638 and is titled “Test execution from IDE uses the same technologies mechanisms as lab does.”

Workflow indication 1012 is indicative of a workflow notification to the user receiving notification 1000. Workflow indication 1012, as shown, is indicative of the user being previously notified of this notification 1000. Workflow indication 1012 can be useful in facilitating in-person communication of electronic matters.

FIG. 11 is a diagram showing one example of a notification 1100. Notification 1100 includes a header 1102 and a body 1104. Header 1102 is indicative of the subject of notification 1100. For example, in notification 1100, the subject of notification 1100 is that a work item has been changed to the status of “cut.” The status change has been filed by a user named “Jane Doe.” For example, Jane Doe could have used status indicator 610 of FIG. 6 to change the status of the deliverable. When this status was changed, notification logic 168 may have generated notification 1100 to notify any party associated with the item, whose status has been changed, or an item related to that item.

Body 1104 is indicative of details of the matter of notification 1100. Body 1104 includes subject item indication 1106, possible effect indication 1108 and workflow indication 1112.

Subject item indication 1106 is indicative of the subject item of notification 1100. In this instance, the subject item is deliverable 10663406 and its status has been changed to “cut.” As shown, the subject item is titled shooters bracket that gaming bracket that desktop gaming experiences are using the new shader system.

Possible effect indication 1108 is indicative of a possible effect of the notification 1100. For example, since the subject item has been changed to a status of cut (e.g., changing status data 1784), the items that are dependent upon the now cut work item may also be “cut” (e.g., changing status data 1784). Possible effect indication 1108 alerts the user of this possible effect which may allow a user to act in the scenario (e.g., also cut the dependent item or change the dependency of the item).

Workflow indication 1112 is indicative of a potential workflow scenario. Workflow indication 1112 is indicative of an indication to contact another user in-person. Workflow indication 1112 can be useful in facilitating in person communication or team collaboration on the matter.

It will be noted that the above discussion has described a variety of different systems, components and/or logic. It will be appreciated that such systems, components and/or logic can be comprised of hardware items (such as processors and associated memory, or other processing components, some of which are described below) that perform the functions associated with those systems, components and/or logic. In addition, the systems, components and/or logic can be comprised of software that is loaded into a memory and is subsequently executed by a processor or server, or other computing component, as described below. The systems, components and/or logic can also be comprised of different combinations of hardware, software, firmware, etc., some examples of which are described below. These are only some examples of different structures that can be used to form the systems, components and/or logic described above. Other structures can be used as well.

The present discussion has mentioned processors and servers. In one embodiment, the processors and servers include computer processors with associated memory and timing circuitry, not separately shown. They are functional parts of the systems or devices to which they belong and are activated by, and facilitate the functionality of the other components or items in those systems.

Also, a number of user interface displays have been discussed. They can take a wide variety of different forms and can have a wide variety of different user actuatable input mechanisms disposed thereon. For instance, the user actuatable input mechanisms can be text boxes, check boxes, icons, links, drop-down menus, search boxes, etc. They can also be actuated in a wide variety of different ways. For instance, they can be actuated using a point and click device (such as a track ball or mouse). They can be actuated using hardware buttons, switches, a joystick or keyboard, thumb switches or thumb pads, etc. They can also be actuated using a virtual keyboard or other virtual actuators. In addition, where the screen on which they are displayed is a touch sensitive screen, they can be actuated using touch gestures. Also, where the device that displays them has speech recognition components, they can be actuated using speech commands.

A number of data stores have also been discussed. It will be noted they can each be broken into multiple data stores. All can be local to the systems accessing them, all can be remote, or some can be local while others are remote. All of these configurations are contemplated herein.

Also, the figures show a number of blocks with functionality ascribed to each block. It will be noted that fewer blocks can be used so the functionality is performed by fewer components. Also, more blocks can be used with the functionality distributed among more components.

FIG. 12 is a block diagram of architecture 100, shown in FIG. 1, except that its elements are disposed in a cloud computing architecture 500. Cloud computing provides computation, software, data access, and storage services that do not require end-user knowledge of the physical location or configuration of the system that delivers the services. In various embodiments, cloud computing delivers the services over a wide area network, such as the internet, using appropriate protocols. For instance, cloud computing providers deliver applications over a wide area network and they can be accessed through a web browser or any other computing component. Software or components of architecture 100 as well as the corresponding data, can be stored on servers at a remote location. The computing resources in a cloud computing environment can be consolidated at a remote data center location or they can be dispersed. Cloud computing infrastructures can deliver services through shared data centers, even though they appear as a single point of access for the user. Thus, the components and functions described herein can be provided from a service provider at a remote location using a cloud computing architecture. Alternatively, they can be provided from a conventional server, or they can be installed on client devices directly, or in other ways.

The description is intended to include both public cloud computing and private cloud computing. Cloud computing (both public and private) provides substantially seamless pooling of resources, as well as a reduced need to manage and configure underlying hardware infrastructure.

A public cloud is managed by a vendor and typically supports multiple consumers using the same infrastructure. Also, a public cloud, as opposed to a private cloud, can free up the end users from managing the hardware. A private cloud may be managed by the organization itself and the infrastructure is typically not shared with other organizations. The organization still maintains the hardware to some extent, such as installations and repairs, etc.

In the example shown in FIG. 12, some items are similar to those shown in FIG. 12 and they are similarly numbered. FIG. 12 specifically shows that computing systems 102, dependency/risk and control system 104, and 110 can be located in cloud 502 (which can be public, private, or a combination where portions are public while others are private). Therefore, users 116 and 120 use user devices 106 and 108 to access those systems through cloud 502.

FIG. 12 also depicts another example of a cloud architecture. FIG. 12 shows that it is also contemplated that some computing systems can be disposed in cloud 502 while others are not. By way of example, data stores 124, 176 can be disposed outside of cloud 502, and accessed through cloud 502. In another example, dependency/risk and control system 104 (or other items) can be outside of cloud 502. Regardless of where they are located, they can be accessed directly by the other items through a network (either a wide area network or a local area network), they can be hosted at a remote site by a service, or they can be provided as a service through a cloud or accessed by a connection service that resides in the cloud. All of these architectures are contemplated herein.

It will also be noted that architecture 100, or portions of it, can be disposed on a wide variety of different devices. Some of those devices include servers, desktop computers, laptop computers, tablet computers, or other mobile devices, such as palm top computers, cell phones, smart phones, multimedia players, personal digital assistants, etc.

FIG. 13 is a simplified block diagram of one illustrative example of a handheld or mobile computing device that can be used as a user's or client device 16, in which the present system (or parts of it) can be deployed. FIGS. 14-15 are examples of handheld or mobile devices.

FIG. 13 provides a general block diagram of the components of a client device 16 that can run components of computing system 102 or user devices 106, 108 or dependency/risk and control system 104 or that interacts with architecture 100, or both. In client device 16, a communications link 13 is provided that allows the handheld device to communicate with other computing devices and under some embodiments provides a channel for receiving information automatically, such as by scanning. Examples of communications link 13 include an infrared port, a serial/USB port, a cable network port such as an Ethernet port, and a wireless network port allowing communication though one or more communication protocols including General Packet Radio Service (GPRS), LTE, HSPA, HSPA+ and other 3G and 4G radio protocols, 1Xrtt, and Short Message Service, which are wireless services used to provide cellular access to a network, as well as Wi-Fi protocols, and Bluetooth protocol, which provide local wireless connections to networks.

In other examples, applications or systems are received on a removable Secure Digital (SD) card that is connected to a SD card interface 15. SD card interface 15 and communications link 13 communicate with a processor 17 (which can also embody processors or servers from other FIGS.) along a bus 19 that is also connected to memory 21 and input/output, I/O components 23, as well as clock 25 and location system 27.

I/O components 23, in one embodiment, are provided to facilitate input and output operations. I/O components 23 for various embodiments of client device 16 can include input components such as buttons, touch sensors, multi-touch sensors, optical or video sensors, voice sensors, touch screens, proximity sensors, microphones, tilt sensors, and gravity switches and output components such as a display device, a speaker, and or a printer port. Other I/O components 23 can be used as well.

Clock 25 illustratively comprises a real time clock component that outputs a time and date. It can also, illustratively, provide timing functions for processor 17.

Location system 27 illustratively includes a component that outputs a current geographical location of client device 16. This can include, for instance, a global positioning system (GPS) receiver, a LORAN system, a dead reckoning system, a cellular triangulation system, or other positioning system. It can also include, for example, mapping software or navigation software that generates desired maps, navigation routes and other geographic functions.

Memory 21 stores an operating system 29, network settings 31, applications 33, application configuration settings 35, data store 37, communication drivers 39, and communication configuration settings 41. Memory 21 can include all types of tangible volatile and non-volatile computer-readable memory devices. It can also include computer storage media (described below). Memory 21 stores computer readable instructions that, when executed by processor 17, cause the processor to perform computer-implemented steps or functions according to the instructions. Similarly, client device 16 can have a client system 24 which can run various applications or embody parts or all of architecture 100. Processor 17 can be activated by other components to facilitate their functionality as well.

Examples of the network settings 31 include things such as proxy information, Internet connection information, and mappings. Application configuration settings 35 include settings that tailor the application for a specific enterprise or user. Communication configuration settings 41 provide parameters for communicating with other computers and include items such as GPRS parameters, SMS parameters, connection user names and passwords.

Applications 33 can be applications that have previously been stored on client device 16 or applications that are installed during use, although these can be part of operating system 29, or hosted external to client device 16, as well.

FIG. 14 shows one example in which client device 16 is a tablet computer 1400. In FIG. 14, tablet computer 1400 is shown with screen 1402. Screen 1402 can be a touch screen (so touch gestures from a user's finger can be used to interact with the application) or a pen-enabled interface that receives inputs from a pen or stylus. It can also use an on-screen virtual keyboard. Of course, it might also be attached to a keyboard or other user input device through a suitable attachment mechanism, such as a wireless link or USB port, for instance. Tablet computer 1400 can also illustratively receive voice inputs as well.

FIG. 15 shows that the device can be a smart phone 71. Smart phone 71 has a touch sensitive display 73 that displays icons or tiles or other user input mechanisms 75. User input mechanisms 75 can be used by a user to run applications, make calls, perform data transfer operations, etc. In general, smart phone 71 is built on a mobile operating system and offers more advanced computing capability and connectivity than a feature phone.

Note that other forms of client devices 16 are possible.

FIG. 16 is one example of a computing environment in which architecture 100, or parts of it, (for example) can be deployed. With reference to FIG. 16, an example system for implementing some embodiments includes a general-purpose computing device in the form of a computer 810. Components of computer 810 may include, but are not limited to, a processing unit 820 (which can comprise processors or servers from previous FIGS.), a system memory 830, and a system bus 821 that couples various system components including the system memory to the processing unit 820. The system bus 821 may be any of several types of bus structures including a memory bus or memory controller, a peripheral bus, and a local bus using any of a variety of bus architectures. By way of example, and not limitation, such architectures include Industry Standard Architecture (ISA) bus, Micro Channel Architecture (MCA) bus, Enhanced ISA (EISA) bus, Video Electronics Standards Association (VESA) local bus, and Peripheral Component Interconnect (PCI) bus also known as Mezzanine bus. Memory and programs described with respect to FIG. 1 can be deployed in corresponding portions of FIG. 12.

Computer 810 typically includes a variety of computer readable media. Computer readable media can be any available media that can be accessed by computer 810 and includes both volatile and nonvolatile media, removable and non-removable media. By way of example, and not limitation, computer readable media may comprise computer storage media and communication media. Computer storage media is different from, and does not include, a modulated data signal or carrier wave. It includes hardware storage media including both volatile and nonvolatile, removable and non-removable media implemented in any method or technology for storage of information such as computer readable instructions, data structures, program modules or other data. Computer storage media includes, but is not limited to, RAM, ROM, EEPROM, flash memory or other memory technology, CD-ROM, digital versatile disks (DVD) or other optical disk storage, magnetic cassettes, magnetic tape, magnetic disk storage or other magnetic storage devices, or any other medium which can be used to store the desired information and which can be accessed by computer 810. Communication media typically embodies computer readable instructions, data structures, program modules or other data in a transport mechanism and includes any information delivery media. The term “modulated data signal” means a signal that has one or more of its characteristics set or changed in such a manner as to encode information in the signal. By way of example, and not limitation, communication media includes wired media such as a wired network or direct-wired connection, and wireless media such as acoustic, RF, infrared and other wireless media. Combinations of any of the above should also be included within the scope of computer readable media.

The system memory 830 includes computer storage media in the form of volatile and/or nonvolatile memory such as read only memory (ROM) 831 and random access memory (RAM) 832. A basic input/output system 833 (BIOS), containing the basic routines that help to transfer information between elements within computer 810, such as during start-up, is typically stored in ROM 831. RAM 832 typically contains data and/or program modules that are immediately accessible to and/or presently being operated on by processing unit 820. By way of example, and not limitation, FIG. 16 illustrates operating system 834, application programs 835, other program modules 836, and program data 837.

The computer 810 may also include other removable/non-removable volatile/nonvolatile computer storage media. By way of example only, FIG. 16 illustrates a hard disk drive 841 that reads from or writes to non-removable, nonvolatile magnetic media, and an optical disk drive 855 that reads from or writes to a removable, nonvolatile optical disk 856 such as a CD ROM or other optical media. Other removable/non-removable, volatile/nonvolatile computer storage media that can be used in the exemplary operating environment include, but are not limited to, magnetic tape cassettes, flash memory cards, digital versatile disks, digital video tape, solid state RAM, solid state ROM, and the like. The hard disk drive 841 is typically connected to the system bus 821 through a non-removable memory interface such as interface 840, and optical disk drive 855 are typically connected to the system bus 821 by a removable memory interface, such as interface 850.

Alternatively, or in addition, the functionality described herein can be performed, at least in part, by one or more hardware logic components. For example, and without limitation, illustrative types of hardware logic components that can be used include Field-programmable Gate Arrays (FPGAs), Program-specific Integrated Circuits (ASICs), Program-specific Standard Products (ASSPs), System-on-a-chip systems (SOCs), Complex Programmable Logic Devices (CPLDs), etc.

The drives and their associated computer storage media discussed above and illustrated in FIG. 16, provide storage of computer readable instructions, data structures, program modules and other data for the computer 810. In FIG. 16, for example, hard disk drive 841 is illustrated as storing operating system 844, application programs 845, other program modules 846, and program data 847. Note that these components can either be the same as or different from operating system 834, application programs 835, other program modules 836, and program data 837. Operating system 844, application programs 845, other program modules 846, and program data 847 are given different numbers here to illustrate that, at a minimum, they are different copies.

A user may enter commands and information into the computer 810 through input devices such as a keyboard 862, a microphone 863, and a pointing device 861, such as a mouse, trackball or touch pad. Other input devices (not shown) may include a joystick, game pad, satellite dish, scanner, or the like. These and other input devices are often connected to the processing unit 820 through a user input interface 860 that is coupled to the system bus, but may be connected by other interface and bus structures, such as a parallel port, game port or a universal serial bus (USB). A visual display 891 or other type of display device is also connected to the system bus 821 via an interface, such as a video interface 890. In addition to the monitor, computers may also include other peripheral output devices such as speakers 897 and printer 896, which may be connected through an output peripheral interface 895.

The computer 810 is operated in a networked environment using logical connections to one or more remote computers, such as a remote computer 880. The remote computer 880 may be a personal computer, a hand-held device, a server, a router, a network PC, a peer device or other common network node, and typically includes many or all of the elements described above relative to the computer 810. The logical connections depicted in FIG. 16 include a local area network (LAN) 871 and a wide area network (WAN) 873, but may also include other networks. Such networking environments are commonplace in offices, enterprise-wide computer networks, intranets and the Internet.

When used in a LAN networking environment, the computer 810 is connected to the LAN 871 through a network interface or adapter 870. When used in a WAN networking environment, the computer 810 typically includes a modem 872 or other means for establishing communications over the WAN 873, such as the Internet. The modem 872, which may be internal or external, may be connected to the system bus 821 via the user input interface 860, or other appropriate mechanism. In a networked environment, program modules depicted relative to the computer 810, or portions thereof, may be stored in the remote memory storage device. By way of example, and not limitation, FIG. 16 illustrates remote application programs 885 as residing on remote computer 880. It will be appreciated that the network connections shown are exemplary and other means of establishing a communications link between the computers may be used.

It should also be noted that the different examples described herein can be combined in different ways. That is, parts of one or more examples can be combined with parts of one or more other examples. All of this is contemplated herein.

Example 1 is a computing system, comprising:

a connection detection system that identifies a set of connected deliverables among a plurality of different deliverables in a data store;

graph generator logic that generates a representation of a graph having nodes connected by edges, each node representing a deliverable and each edge connecting a pair of nodes corresponding to a connection between the deliverables represented by the pair of nodes connected by the edge;

a user interaction system that controls interaction with the plurality of different deliverables, the user interaction system comprising:

link setting logic that generates a link setting user interface mechanism that is actuatable to modify one or more connections; and

surfacing logic that controls a display to display the representation of the graph and the link setting user interface mechanism.

Example 2 is the computing system of any or all previous examples wherein the connection detection system comprises:

dependency generator logic configured to identify, as a connection between a first deliverable of the plurality of deliverables and a second deliverable of the plurality of deliverables, a dependency in which the first deliverable is dependent on the second deliverable.

Example 3 is the computing system of any or all previous examples wherein the connection detection system comprises:

filtering logic configured to generate a filter user interface mechanism that allows a user to select deliverable characteristics; and

deliverable parsing logic configured to access the plurality of deliverables and to filter out deliverables, based on the user selected characteristics, to identify the set of connected deliverables.

Example 4 is the computing system of any or all previous examples further comprising:

a risk metric generator system that generates a risk metric corresponding to each node, the risk metric for each given node being based, at least in part, on a completion status of the deliverable represented by the node.

Example 5 is the computing system of any or all previous examples wherein the risk metric generator system comprises:

inheritance processing logic that identifies the risk metrics corresponding to one or more nodes connected to each node, and the generated risk metric for each given node is based, at least in part, on the risk metrics corresponding to one or more nodes connected to the given node.

Example 6 is the computing system of any or all previous examples wherein the graph generator logic comprises:

risk indication generator logic configured to generate an indication of the risk metric on the representation of the graph.

Example 7 is the computing system of any or all previous examples wherein the risk indication generator logic is configured to generate the indication of the risk as part of the node.

Example 8 is the computing system of any or all previous examples wherein the graph generator logic comprises:

risk indication generator logic configured to generate an indication of the risk metric on the representation of the graph as part of the edge between the given node and another node, connected to the given node, having a risk metric that affects the risk metric of the given node.

Example 9 is the computing system of any or all previous examples wherein the link setting logic comprises:

reverse logic configured to generate the link setting user interface mechanism as a reverse dependency user interface mechanism that is actuated to reverse the dependency between the first deliverable and the second deliverable.

Example 10 is the computing system of any or all previous examples wherein the graph generator logic comprises:

summary generator logic configured to generate a tabular summary, wherein each row of the tabular summary corresponds to a node of the graph.

Example 11 is the computing system of any or all previous examples wherein the graph generator logic comprises:

center node generator logic configured to generate a center node corresponding to one of the deliverables in the set of connected deliverables; and

peripheral node generator logic configured to generate one or more peripheral nodes, each peripheral node corresponding to at least one of the deliverables in the set of connected deliverables, and connected directly or indirectly by an edge to the center node.

Example 12 is the computing system of any or all previous examples wherein the graph generator logic comprises:

collapse logic configured to generate a collapse user interface mechanism that is actuated by a user to toggle a set of directly connected peripheral nodes from multiple peripheral nodes into a single peripheral node.

Example 13 is the computing system of any or all previous examples wherein the graph generator logic comprises:

dependency count generator logic configured to generate an indication, for each node, of the number of deliverables dependent on the deliverable represented by the node.

Example 14 is a computer implemented method, comprising:

displaying a deliverable generation user interface mechanism on a display device, the creation user interface mechanism being actuated to create a deliverable;

detecting actuation of the deliverable generation user interface mechanism;

generating a first deliverable and a second deliverable;

displaying a link setting user interface mechanism on the display device, the link setting user interface mechanism configured to generate a dependency between the first and second deliverables;

generating a first node representing the first deliverable and a second node representing the second deliverable;

generating an edge connecting the first node and second node, the edge representing a dependency between the first deliverable and second deliverable;

generating an interface comprising the first node, second node and edge;

controlling, utilizing surfacing logic, a display device to display the interface.

Example 15 is the computer implemented method of any or all previous examples further comprising:

determining a first risk metric for the first node, the first risk metric being based on a completion status of the first deliverable and on a second risk metric indicative of a risk of the second node;

generating a risk indication for the first node, indicative of the first risk metric; and

controlling, utilizing the surfacing logic, the display device to display the risk indication.

Example 16 is the computer implemented method of any or all previous examples further comprising:

displaying a reverse user interface mechanism; and

wherein, in response to an actuation of the reverse user interface mechanism, reversing the dependency between the first deliverable and the second deliverable.

Example 17 is the computer implemented method of any or all previous examples further comprising:

generating a third node representing a third deliverable;

generating a fourth node representing a fourth deliverable;

generating a second edge connecting the third node to the second node, wherein the second edge represents a dependency between the second deliverable and the third deliverable; and

generating a third edge connecting the fourth node to the second node, wherein the third edge represents a dependency between the second deliverable and the fourth deliverable.

Example 18 is a computing system, comprising:

a dependency system that identifies a set of dependent deliverables among a plurality of different deliverables of a cloud service computing system;

graph construction logic that generates a representation of a graph having generally concentric circles of nodes connected by edges, each node representing a deliverable of the plurality of deliverables and each edge, initiating at a first node and terminating at a second node in a pair of nodes, the edge representing a dependence of the first node on the second node;

a risk metric generator system that generates a risk metric corresponding to each node, the risk metric for each given node being based on a number of edges initiating at the given node;

risk indication generator logic that generates an indication of the risk metric for each node on an edge terminating at the given node;

surfacing logic configured to control a display device to display the representation of the graph with the indication of the risk metric corresponding to each node.

Example 19 is the computing system of any or all previous examples wherein graph construction logic comprises:

reverse logic configured to generate a reverse user interface mechanism on an edge that allows a user to actuate the edge and reverse dependence of a first deliverable represented by the first node on a second deliverable represented by the second node to dependence of the second deliverable on the first deliverable.

Example 20 is the computing system of any or all previous examples wherein graph construction logic comprises:

dependency direction logic configured to generate a dependency indication for each edge, the dependency indication indicative of a direction of dependence.

Although the subject matter has been described in language specific to structural features and/or methodological acts, it is to be understood that the subject matter defined in the appended claims is not necessarily limited to the specific features or acts described above. Rather, the specific features and acts described above are disclosed as example forms of implementing the claims.

Claims

1. A computing system, comprising:

a connection detection system that identifies a set of connected deliverables among a plurality of different deliverables in a data store;

graph generator logic that generates a representation of a graph having nodes connected by edges, each node representing a deliverable and each edge connecting a pair of nodes corresponding to a connection between the deliverables represented by the pair of nodes connected by the edge;

a user interaction system that controls interaction with the plurality of different deliverables, the user interaction system comprising: link setting logic that generates a link setting user interface mechanism that is actuatable to modify one or more connections; and

surfacing logic that controls a display to display the representation of the graph and the link setting user interface mechanism.

2. The computing system of claim 1 wherein the connection detection system comprises:

dependency generator logic configured to identify, as a connection between a first deliverable of the plurality of deliverables and a second deliverable of the plurality of deliverables, a dependency in which the first deliverable is dependent on the second deliverable.

3. The computing system of claim 1 wherein the connection detection system comprises:

filtering logic configured to generate a filter user interface mechanism that allows a user to select deliverable characteristics; and

deliverable parsing logic configured to access the plurality of deliverables and to filter out deliverables, based on the user selected characteristics, to identify the set of connected deliverables.

4. The computing system of claim 1 further comprising:

a risk metric generator system that generates a risk metric corresponding to each node, the risk metric for each given node being based, at least in part, on a completion status of the deliverable represented by the node.

5. The computing system of claim 4 wherein the risk metric generator system comprises:

inheritance processing logic that identifies the risk metrics corresponding to one or more nodes connected to each node, and the generated risk metric for each given node is based, at least in part, on the risk metrics corresponding to one or more nodes connected to the given node.

6. The computing system of claim 4 wherein the graph generator logic comprises:

risk indication generator logic configured to generate an indication of the risk metric on the representation of the graph.

7. The computing system of claim 6 wherein the risk indication generator logic is configured to generate the indication of the risk as part of the node.

8. The computing system of claim 5 wherein the graph generator logic comprises:

risk indication generator logic configured to generate an indication of the risk metric on the representation of the graph as part of the edge between the given node and another node, connected to the given node, having a risk metric that affects the risk metric of the given node.

9. The computing system of claim 2 wherein the link setting logic comprises:

reverse logic configured to generate the link setting user interface mechanism as a reverse dependency user interface mechanism that is actuated to reverse the dependency between the first deliverable and the second deliverable.

10. The computing system of claim 1 wherein the graph generator logic comprises:

summary generator logic configured to generate a tabular summary, wherein each row of the tabular summary corresponds to a node of the graph.

11. The computing system of claim 1 wherein the graph generator logic comprises:

center node generator logic configured to generate a center node corresponding to one of the deliverables in the set of connected deliverables; and

peripheral node generator logic configured to generate one or more peripheral nodes, each peripheral node corresponding to at least one of the deliverables in the set of connected deliverables, and connected directly or indirectly by an edge to the center node.

12. The computing system of claim 11 wherein the graph generator logic comprises:

collapse logic configured to generate a collapse user interface mechanism that is actuated by a user to toggle a set of directly connected peripheral nodes from multiple peripheral nodes into a single peripheral node.

13. The computing system of claim 2 wherein the graph generator logic comprises:

dependency count generator logic configured to generate an indication, for each node, of the number of deliverables dependent on the deliverable represented by the node.

14. A computer implemented method, comprising:

displaying a deliverable generation user interface mechanism on a display device, the creation user interface mechanism being actuated to create a deliverable;

detecting actuation of the deliverable generation user interface mechanism;

generating a first deliverable and a second deliverable;

displaying a link setting user interface mechanism on the display device, the link setting user interface mechanism configured to generate a dependency between the first and second deliverables;

generating a first node representing the first deliverable and a second node representing the second deliverable;

generating an edge connecting the first node and second node, the edge representing a dependency between the first deliverable and second deliverable;

generating an interface comprising the first node, second node and edge;

controlling, utilizing surfacing logic, a display device to display the interface.

15. The computer implemented method of claim 14 further comprising:

determining a first risk metric for the first node, the first risk metric being based on a completion status of the first deliverable and on a second risk metric indicative of a risk of the second node;

generating a risk indication for the first node, indicative of the first risk metric; and

controlling, utilizing the surfacing logic, the display device to display the risk indication.

16. The computer implemented method of claim 14 further comprising:

displaying a reverse user interface mechanism; and

wherein, in response to an actuation of the reverse user interface mechanism, reversing the dependency between the first deliverable and the second deliverable.

17. The computer implemented method of claim 14 further comprising:

generating a third node representing a third deliverable;

generating a fourth node representing a fourth deliverable;

generating a second edge connecting the third node to the second node, wherein the second edge represents a dependency between the second deliverable and the third deliverable; and

generating a third edge connecting the fourth node to the second node, wherein the third edge represents a dependency between the second deliverable and the fourth deliverable.

18. A computing system, comprising:

a dependency system that identifies a set of dependent deliverables among a plurality of different deliverables of a cloud service computing system;

graph construction logic that generates a representation of a graph having generally concentric circles of nodes connected by edges, each node representing a deliverable of the plurality of deliverables and each edge, initiating at a first node and terminating at a second node in a pair of nodes, the edge representing a dependence of the first node on the second node;

a risk metric generator system that generates a risk metric corresponding to each node, the risk metric for each given node being based on a number of edges initiating at the given node;

risk indication generator logic that generates an indication of the risk metric for each node on an edge terminating at the given node;

surfacing logic configured to control a display device to display the representation of the graph with the indication of the risk metric corresponding to each node.

19. The computing system of claim 18 wherein graph construction logic comprises:

reverse logic configured to generate a reverse user interface mechanism on an edge that allows a user to actuate the edge and reverse dependence of a first deliverable represented by the first node on a second deliverable represented by the second node to dependence of the second deliverable on the first deliverable.

20. The computing system of claim 19 wherein graph construction logic comprises:

dependency direction logic configured to generate a dependency indication for each edge, the dependency indication indicative of a direction of dependence.