Form 3.2: Due by November 4 at 11:59pm.

Email to Baris Aydinlioglu (vb43520@umd5.umd.edu).

Name:

Team Number:

Document reviewed:

List the faults you discovered below, specifying the page number and the area in which each is found. Use the following codes for describing the fault area:

DE Class Design

DI Class Diagram

SEQ Sequence Diagram

STA State Diagram

Use the following codes for describing the fault class:

A Ambiguity

E Extraneous Information

IF Incorrect Fact

II Inconsistent Information

O Omission

M Miscellaneous Defect

Also rate the severity of the fault by assigning a rating for "importance" and "probability of causing an error" based on the following scales:

Importance:

0. not important, developer should easily see the problem
1. problem, if a failure occurs it should be easy to find and fix (e.g. change to 1 module)
2. important, if a failure occurs, it could be hard to find and fix (e.g. change to several modules)
3. very important, if a failure occurs, it could cause a re-implementation

0. will not cause fault or failure, will be caught by developer
1. could cause a failure but will most likely be caught by developer
2. would cause a failure

An example is provided. Take as much space as you need, and separate each fault with a blank line. Remember to keep a copy of this information for yourself! If you find new faults as a group, please indicate them by putting an asterisk (*) before the Fault number.

When done, skip down to the end and answer the questions there.

Fault # Page # Area Importance Prob. Class Desc.

------ ------ ------ ---------- ----- ----- -----

*0 2 DI 1 2 A Since this isn’t a real fault we’ll assign it a number of 0. Number your faults starting from 1, of course. This fault should be a new fault found by the team during the group meeting since there is an asterisk before the number 0. This fault should describe some ambiguous information found in the class diagrams on page 2 of the design (If you cannot specify the area - for example, some faults may affect multiple sections of the document - leave this field blank.) This fault has a high probability of causing a failure (prob = 2) but is not too important because it should be easy to find and fix (importance = 1). In the description you need to explain exactly what the fault is so that it could be corrected.

Please answer the following questions. Your answers will be used to help us better understand the process, and will not impact the grading of this assignment. Each member of the team should submit separate answers to these questions:

1. How much time did you take as a team to decide on the final lists (report just the time spent on discussing the lists, not including interruptions, breaks, or other non-related activities)?
2. Did you feel that the individual fault lists were similar or rather different? Did this fact effect the amount of time you spent on discussion?
3. Did the fact that all members of the team used different techniques in finding faults in Assignment 3A have an effect on how easy it was to merge the lists?
   __ the different perspectives on the team made it harder to merge
   __ there was no difference due to the perspectives
   __ the different perspectives on the team made it easier to merge
4. Did the fact that all members of the team used different techniques have an effect on how the meeting itself was run? For example, because of the different techniques, did all three members have more equal input to the discussion? Did team members feel less able to discuss aspects of the design that their technique did not deal with? Please describe any related issues you encountered.
5. In assignment 1, your team was responsible for merging both error and fault lists, whereas in assignment 3 your team was only responsible for merging a fault list. Did the lack of an error list slow down the merging efforts, speed it up, or did the time spent remain about the same? Was it easier or harder to merge the lists without the errors?
6. Due to meeting as a team, do you feel there were any resulting benefits to the fault lists (e.g. eliminated redundant faults, improved descriptions, removed entries that weren’t really faults)? Were these benefits effected by having different techniques for the different team members?
7. Do you feel that there were benefits to actually meeting as a team and interacting with your teammates, which could not have been achieved if you simply reviewed your teammates’ fault lists? Is the list of faults that the team generated much different from what the list would have been had you taken your teammates’ lists and merged them into one list all by yourself?
8. Due to meeting as a team, do you feel there were any benefits to you as reviewers? Do you feel you understand the document better now that you have seen your teammates’ work?
9. Because of the team meeting, do you feel you understand what your teammates’ techniques involved? Do you think that they understand yours? If the answer to either of these questions is yes, has this information been beneficial or helpful in any way?
10. Due to meeting as a team, do you think you could do a better job of fixing the document than if you had only worked individually? Use the checklist to answer and then explain your reasoning below.
    
    The team meeting:
    __ would help if I had to repair the requirements
    __ wouldn’t help if I had to repair the requirements
11. What percentage of the faults in the document do you think were found by the team?

12. What percentage of the errors in the document do you think were found by the team?
13. Did your group generally agree or disagree on the "importance" and "probability of causing a failure" rankings given to the faults?
14. Did your group generally agree or disagree on the fault class value assigned to each fault?
    
15. Any additional comments?