Peer Review Kit for the System/Segment Specification Document of the eQip project

Version 0.1 (07/15/02)

Jean-Louis Villecroze eQip Development Team
Contents


Introduction to this Peer Review

The purpose of this review is to verify that all the requirements of the system have been listed and correctly described. It shall also be verified that the listed requirements are valids.

Other review goals include:

  • english mistake
  • understanding
  • adequacy to user needs
  • coherence
  • precision
  • feasability

As there is no designed peers for this review, anybody that whish to contribute to the project shall fill the Defects list according to the concepts listed in the Notes section of this document, and submit the modified document to the review moderator before the Review submission date.


Review information

Review ID eQip/001
Subject Review of the SSS
Document(s) SSS draft 0.9
Moderator Unknown
Author Jean-Louis Villecroze
Peers No designated peers
Schedule
Start date 07/15/02
Review submission 08/09/02
Review meeting date 08/13/02
End date 08/20/02


Defects list

The following table shall be completed by the peer with the defect (s)he found during the review:

Peer nameyour name and email
Review durationhow many hours did you spend on the review ?
Num. Ref. Type Severity Defect Proposition Accepted Status

The Accepted and Status are not to be filled by the peer, but by the review moderator. Type must be filled by using the table Defect type in the Notes and the Severity must be filled using the table Defect severity also in the Notes. Number the defect found starting from 1.


Notes

  1. Concepts definition

    Defect A defect in a system (or component) is a factor preventing the system (or component) from fullfilling its desired function. When a defect becomes active, errors may ensue, in turn causing a system failure.
    Defect severity The severity of a defect is used to decide on the course of action to be taken when a defect is encoutered:

    Spotted Defect non-recorded which is communicated to the author informaly (eg. spelling mistakes)
    Minor Defect recorded but the correction of which is left to the author's discretion
    Major Defect recorded which must be imperatively corrected
    Critical Defect recorded which must be imperatively corrected. The effect of the correction being considered important enough to justify a new review, following correction.

    Defect type To help the corrective action process, any defect found during the peer review, shall be categorized using the following types:

    LabelTypeDescription
    CSH Crash System's component stop functionning in specific (or unknown) conditions.

    Examples :

  2. Application XYZ crash upon user action W.
  3. BHV Behavior System's component doesn't behave the way it should.

    Examples :

  4. Emailer print email instead of emaling it.
  5. CHG Change System or system's component shall integrate a given change.

    Examples :

  6. Allow the user to do X with Y, when W running.
  7. PRF Performance Performance requirements (CPU load, occupation memory, time of processing) no satisfied. The description is correct but ineffective.

    Examples :

  8. The system's perfomance is damaged by this specific requirement,
  9. Performance criteria are not specified,
  10. Code not optimized,
  11. The set of tests does not allow users to measure performance, etc.
  12. ITF Interface Interface errors when an element is combined with other components: incomplete interface description, communication problem (protocol, arguments, calling parameters, etc.).

    Examples :

  13. Incorrect calling protocol,
  14. Incorrect arguments of interface,
  15. Initialization of hardware component,
  16. Initialization and dialogue between processor.
  17. RMA Maintenance and Re-use The element is difficult to maintain or re-use; it is too complicated or sophisticated

    Examples :

  18. Cannot transfer code (whithout comments),
  19. Missing,unclear or irrelevant comments within the code,
  20. Illegible code,
  21. The origin of the error cannot be identified by the error messag.
  22. STD Standard Non compliance with standards, procedures and guides of the baseline. Non compliance with the methods and tools defined for the unit and for the business baseline.

    Examples:

  23. Non compliance with the model plan,
  24. Non compliance with the coding rules (variables and functions names', etc.),
  25. Non compliance with standard,
  26. Non compliance with the software baseline guidelines.
  27. FCT Functional / upper requirements Problem of the element regarding to the amont requirements, such as tracking, coherence, compliance, monitoring.

    Examples :

  28. Incomplete tracking matrix ,
  29. The code does not cover all the assigned requirements,
  30. The design does not describe all the assigned requirements,
  31. Unexpecteed method of functionning,
  32. requirement not taken into account.
  33. DOC Documentation / Understanding DOC - Documentation / Understanding The content of the document does not allow a complete understanding. It is written in an ambiguous or incorrect way.

    Examples :

  34. Incorrect reference to a document,
  35. The descriptions are irrelevant, inadequate, insufficient,
  36. The detailed design (in a document or in a code itself) does not clearly describe the arguments or the feature of every coded function,
  37. The purpose of each test is not clearly defined, etc.
  38. TEC Technique / Algorithms The technical content is incorrect and ambiguous: errors in the calculation of algorithms, incorrect sequencing, etc.

    Examples :

  39. Digital instability
  40. No deallocation of the memory
  41. Incorrect model
  42. Error not modified
  43. Risk of division by zero
  44. Mismanaged interruption
  45. Overflow
  46. Useless or redundant code.
  47. DON Data / Programming language Data errors are: structure, size, initialization. Programming errors concerning: operators, functions and procedures, typing errors,etc.

    Examples :

  48. Variables, pointers not initialized,
  49. Confusion between assignment and comparison,
  50. Size of a table, a buffer,
  51. Scope of a local variable,
  52. Typing errors,
  53. Confusion between names of two variables, etc.
  54. What is a peer review ?

    Peer reviews (PR) are reviews carried out during the development process to detect and correct defects as early as possible. They are based on a comparison of the standpoints of several experts, guided by a checklist procedure, and contribute to reduicing lead time and risks. They also improve the project quality by ensuring better control over the development.

    They are also an excellent mean of communication and learning.

  55. PR roles

    During a PR, there is 3 differents type of players:

    Author The author is the designed or the manager of the document/code beeing examined.
    Moderator The moderator is an important player in the implementation of the review of which he is the coordinator. He must be capable of evaluating the impact of a defect. He can be a peer also. His tasks are:
    • motivation and control of the participants
    • meeting management
    • control of the review effectivieness
    • drafting the PR Kit and review report documents
    Peers Peers are responsible for carrying out the review according to their technical background and to the review goals.



Version History


Release date Version Comments
07/15/02 0.1 Initial release


(C) eQip Project Team 2002 /DOCS/PROJECT/SSS-PRK