4 Life cycle of a Fact Sheet
    4.1 Ideal life cycle of a Fact Sheet

    The ideal life cycle of a fact sheet is shown in the diagram below:

     

     

    4.2 Detection of a problem

    The life cycle of a fact sheet starts with the detection of a problem. This detection can be done by any member of the project team, even by the client, in any phase of the life-cycle of the product.

    As soon as a problem is detected, a fact sheet has to be created, even if it's only for tracking purposes.

    At the moment of creation, the fact sheet is in the N (new) state. Each new fact sheet will be analysed by the person responsible for managing the fact sheets, and if needed, by the Change Control Board (see below).

    4.3 Change Control Board

In a large project, there is a group of people reviewing regularly the status of each fact sheet. It is called the Change Control Board. This group is constituted, for example, of the project manager, the manager of the fact sheets (who is often also the head of development), the head of validation, and any other person who's team may be impacted by the changes made to the final product.

In a small project, the Change Control Board is represented only by the project manager, he must nevertheless regularly review the status of each fact sheet.

The frequency of the meetings is proportional to the importance and the expected reactivity to solve to detected problems.

During these meetings, it is possible to talk about the severity of the outstanding problems, of their type, their current state, and obviously of their content. The purpose of these meeting is :

After each meeting, the following actions points are taken:

In some cases, when a high reactivity is needed, this step of the change control board can be bypassed, with the drawback of bad communication.

      4.4 Observing of a problem

      It can happen that when a problem is detected, it can not be reproduced, or the development team needs more information to reproduce it. In this case, the problem, it's occurrence and it's environment needs to be carefully observed, in order to gather extra information. Sometimes this observation period can last several days or weeks. During all this time, the related fact sheet, is not really new, and not really under analysis either, hence the purpose of the observation status.

      4.5 Analysis of a Fact Sheet

      When a fact sheet is assigned to a member of a project, he studies it to find the causes of the problem. This task can take from a few minutes to several days. The developer adds his analysis to the fact sheet in one or more paragraphs.

      Reading the analysis, the manager can ask for extra information or find that the analysis is well done, that the developer know what he is talking about, and let him start the correcting process. Or on the contrary, the manager can decide to rather abandon the problem (see below).

      4.6 Abandoning a Problem

      The decision to abandon a problem is always taken by either the Change Control Board or the person managing the fact sheets, according to the organization of the project. This decision can only be done following a clear analysis and explaining the reasons for abandoning the problem.

      Once the problem has been abandoned, an e-mail is sent to the person having submitted the problem to notify him. This person can immediately react if he does not agree with the decision to abandon the problem.

      4.7 Opening a Fact Sheet

      Once a problem is well analyzed, and that the person responsible for the management of the fact sheets thinks that the developer has a good grip on the problem, that all the impacts of the problem have been studied, the problem is ready to be corrected. In this case, the manager give the green light for the correction process.

      This phase is often bypassed when the correction of the problem becomes obvious after the analysis. In this case, the person who has done the analysis can pass directly to the correction. In this working mode, the correction must obviously take alone the responsibility of all the unseen impacts of his modifications.

      When the correction process is long, it is advised to put the fact sheet on the open state to avoid showing this sheet among the list of problems under analysis to have nicer statistics. This information is important for the Change Control Board (or the project manager) who see the counters change, and is reassured about this problem being almost solved since being in the open state, rather than still under analysis which can mean that none has a clue.

      4.8 Correction of a problem

      When a problem is corrected, the indicates it in the fact sheet describing the modifications he has done and the new versions of the modified files (in case the files are under some type of configuration management) or the new versions of the modified documents.

      4.9 Validation of a Problem

      When a problem is solved, the solution has to by validated (verified).

      On a small project, these two steps could be done by the same person, but it really corresponds to two different phases, for example, the modifications are checked through unitary tests, and validated through functional tests.

      On a large project, the software part impacted by the changes will be passed to validation. The head of the validation team is in charge of distributing the corrected fact sheets to be validated by the members of his team ("forVerif" functionality in GIFFT). For some problems, for example very technical issues relating to the internals of the code, the validation team can not have the necessary knowledge to verify the corrections. In this case, the person having submitted the sheet, should be asked to validate it. This can be used as a general rule, because the submitter has usually all the information to quickly reproduce the conditions in which the problem has been detected.

      Once, the verification is done, either the sheet is set to "verified" state, or is rejected if the problem is still present. Rejected sheets get the "new" status, and the manager is notified.

    1. 4.10 Notifications during the lifetime of a fact sheet

The table below summarizes the default cases when an e-mail is sent to someone when a change took place in a fact sheet. In each case, the message is sent to the person who needs to take care of the issue, so that the sheet can continue it's way towards resolution. This table is folly configurable (see setup).

On this event :

a message is sent to

Head of Development

Head of Validation

Submitter

Analyzer

Corrector

Verifier

Creation (N)

X

X

       

Change sheet header

X

         

Set to Observed (Ob)

   

X

     

Adding an analysis

X

   

X

   

Editing an analysis

X

   

X

   

Copying a sheet

           

Assigning (A)

     

X

   

Opening (O)

     

X

   

Abandoning the issue

(B R D P Ab)

X

 

X

     

Correction (C)

X

X

       

Assigned for Verification

         

X

Validation (V)

       

X

 

Rejecting (N)

X

         

Note: the mail is only to a destination if it is a different person than the one who has done the action that generated the mail.