Metrics Automation

There are many opportunities to automate the project control activities of a software project. For managing against a plan, a software project control panel (SPCP) that maintains an on-line version of the status of evolving artifacts provides a key advantage. This concept was first recommended by the Airlie Software Council [Brown, 1996], using the metaphor of a project "dashboard." The idea is to provide a display panel that integrates data from multiple sources to show the current status of some aspect of the project. For example, the software project manager would want to see a display with overall project values, a test manager may want to see a display focused on metrics specific to an upcoming beta release, and development managers may be interested only in data concerning the subsystems and components for which they are responsible. The panel can support standard features such as warning lights, thresholds, variable scales, digital formats, and analog formats to present an overview of the current situation. It can also provide extensive capability for detailed situation analysis. This automation support can improve management insight into progress and quality trends and improve the acceptance of metrics by the engineering team.

To implement a complete SPCP, it is necessary to define and develop the following:

• Metrics primitives: indicators, trends, comparisons, and progressions

• A graphical user interface: GUI support for a software project manager role and flexibility to support other roles

• Metrics collection agents: data extraction from the environment tools that maintain the engineering notations for the various artifact sets

• Metrics data management server: data management support for populating the metric displays of the GUI and storing the data extracted by the agents

•/Metrics definitions: actual metrics presentations for requirements progress \(extracted from requirements set artifacts), design progress (extracted from design set artifacts), implementation progress (extracted from implementation set artifacts), assessment progress (extracted from deployment set artifacts), and other progress dimensions (extracted from manual sources, financial management systems, management artifacts, etc.)

• Actors: typically, the monitor and the administrator

Specific monitors (called roles) include software project managers, software development team leads, software architects, and customers. For every role, there is a specific panel configuration and scope of data presented. Each role performs the same general use cases, but with a different focus.

• Monitor: defines panel layouts from existing mechanisms, graphical objects, and linkages to project data; queries data to be displayed at different levels of abstraction

• Administrator: installs the system; defines new mechanisms, graphical objects, and linkages; handles archiving functions; defines composition and decomposition structures for displaying multiple levels of abstraction

The whole display is called a panel. Within a panel are graphical objects, which are types of layouts (such as dials and bar charts) for information. Each graphical object displays a metric. A panel typically contains a number of graphical objects positioned in a particular geometric layout. A metric shown in a graphical object is labeled with the metric type, the summary level, and the instance name (such as lines of code, subsystem, serverl). Metrics can be displayed in two modes: value, referring to a given point in time, or graph, referring to multiple and consecutive points in time. Only some of the display types are applicable to graph metrics.

Metrics can be displayed with or without control values. A control value is an existing expectation, either absolute or relative, that is used for comparison with a dynamically changing metric. For example, the plan for a given progress metric is a control value for comparing the actuals of that metric. Thresholds are another example of control values. Crossing a threshold may result in a state change that needs to be obvious to a user. Control values can be shown in the same graphical object as the corresponding metric, for visual comparison by the user.

Indicators may display data in formats that are binary (such as black and white), tertiary (such as red, yellow, and green), digital (integer or float), or some other enumerated type (a sequence of possible discrete values such as sun..sat, ready-aim-fire, jan..dec). Indicators also provide a mechanism that can be used to summarize a condition or circumstance associated with another metric, or relationships between metrics and their associated control values.

A trend graph presents values over time and permits upper and lower thresholds to be defined. Crossing a threshold could be linked to an associated indicator to depict a noticeable state change from green to red or vice versa. Trends support user-selected time increments (such as day, week, month, quarter, year). A comparison graph presents multiple values together, over time. Convergence or divergence among values may be linked to an indicator. A progression graph presents percent complete, where elements of progress are shown as transitions between states and an earned value is associated with each state. Trends, comparisons, and progressions are illustrated in Figure 13-9.

Metric information can be summarized following a user-defined, linear structure. (For example, lines of code can be summarized by unit, subsystem, and project.) The project is the top-level qualifier for all data belonging to a set (top-level context). Users can define summary structures for lower levels, select the display level based on previously defined structures, and drill down on a summarized number by seeing the lower level details.

Figure 13-10 illustrates a simple example of an SPCP for a project. In this case, the software project manager role has defined a top-level display with four graphical objects.

1. Project activity status. The graphical object in the upper left provides an overview of the status of the top-level WBS elements. The seven elements could be coded red, yellow, and green to reflect the current earned value status. (In Figure 13-10, they are coded with white and shades of gray.) For example, green would represent ahead of plan, yellow would indicate within 10% of plan, and red would identify elements that have a greater

Trend: Comparison of a value over time against known thresholds. Example: design model change traffic

Actual Value

Trend: Comparison of a value over time against known thresholds. Example: design model change traffic

Actual Value

Time

Comparison: Comparison of N values with the same units over time. Example: open action items vs. closed action items

Metric Value 1

Metric Value 2

Time

Progress: Plan vs. actuals over time

Expected Value Actual Value

Time

Figure 13-9. Examples of the fundamental metrics classes

Top-Level WBS Activities

Technical Artifacts

Top-Level WBS Activities

Management

Project Management Made Easy

Project Management Made Easy

What you need to know about… Project Management Made Easy! Project management consists of more than just a large building project and can encompass small projects as well. No matter what the size of your project, you need to have some sort of project management. How you manage your project has everything to do with its outcome.

Get My Free Ebook


Responses

Post a comment