Project Alarm Mechanism

Project Alarm Mechanism

How can we determine that a project is developing in this direction (but it is not yet in the midst of a disaster? How can we determine the necessary measures for software projects before the cost of the rescue measures increases? The answer to these questions is the alarm mechanism of the EWS system.

For the purpose of discussion, we divide the issue into two categories: project management (such as administrative, management, process, environment, and other issues) and product-related (such as software bugs. Project and product problems are classified into the following categories based on the Severity:

1. Critical

Critical product problems: cause product defects that are unavailable or close to unavailability.

Critical project problems: project-related problems that cannot be successful if the project is not overcome.

2. Severe

Severe product problems: product defects that make a major product feature unavailable but still usable for the entire product.

Serious project problems: if the problem is not corrected in time, the following project-related problems will occur:

It greatly affects user satisfaction. There is evidence that 20% or more of the users who are expected to use or buy the product will not use or buy the product.

This results in a project budget overspending of 20%.

As a result, the project's time budget exceeds 20%.

3. Minor class

Minor product problems: defects that make the product difficult to use, but other main features of the product can still run effectively. This category also includes other product defects that are neither critical nor serious.

Minor project problems: problems related to projects that are neither critical nor serious.

Critical and serious problems can trigger alerts. Specifically, based on the number of critical and serious problems, the time required to clear the list of problems, and the progress of solving the problem, determines whether an alarm is triggered. For example, in a strategic software system or life support software system, an alert may sound as long as there is a critical issue that exists in the project beyond a review cycle. In non-emergency software system projects (such as an attendance management system), the alarm mechanism may be more complex.

The alarm mechanism often takes into account the timeliness factor. That is to say, if the critical and serious problems are not solved, their severity will increase over time. The following is an example of an alarm mechanism (the parameter value is in brackets ):

1. Assign the X point value (for example, 5) to a new critical problem );

2. for a critical problem that stays in the problem list, add the y point value for each previous report cycle (for example, one week is a report cycle) (for example, 2 );

3. Assign the Z-point value (for example, 1) to a new serious problem );

4. for a serious problem that stays in the problem list, each previous report cycle (for example, one week is a report cycle) increases the U point value for it (for example, 1 );

5. Add the values of all critical and severe problems in the problem list and calculate the sum;

6. If the sum is greater than the critical value V (for example, 20), the alarm is triggered.

The values of X, Y, Z, U, and V depend on the history of the project, the product in development, the development organization, the product customers and users, and the Development Organization (in the previous project, how is the problem solved) and other features. There are two rules that constrain the X, Y, Z, U, and v values:

1. These values must be set before the project restarts;

2. During project development, changes to these values should be limited and should not be changed frequently.

These two rules ensure that the alarm mechanism will not be changed rashly.

In general, a good project ALARM method is based on a comprehensive review of the project (rather than a problem. However, when a problem has an overwhelming impact (that is, the possibility of project failure is obvious due to the problem), the alarm may also be triggered.

As we mentioned earlier, if the development organization already has a valid EWS, the EWS should be used when the saved project is restarted. For other organizations, we can start with the X, Y, Z, U, and v values in the previous example, and then improve these values during project promotion, in this way, a simple but effective alarm mechanism is established. However, it should be noted that these values should not be changed frequently (rules for X, Y, Z, U, and V already stipulate this ).

 

This article is excerpted from the book "disaster recovery-bringing software projects back to track"

[Us] By bennatan

Translated by Hou yanfei, Hou yufang, and Li Meng

Book details: http://blog.csdn.net/broadview2006/article/details/7719723