CMSC 435 - Assignment 3B
In order to give you experience with the nature of defects in software products, this assignment is an exercise in defect detection. Specifically, you will be asked to identify faults in a design document developed by another group in your class.
In this part of the assignment, you are asked to merge the fault lists you generated in assignment 3A into one fault list which will represent the views of your team as a whole. We estimate that this part of the assignment should take approximately 2 hours. While we are giving you the class period on November 3 to work on the assignment, should you not finish in class, you are expected to meet as a group to complete the assignment by the deadline.
A design fault is an omission, inaccuracy, inconsistency, ambiguity or anything that would lead to an unsatisfactory solution of the problem to be solved. It can fall into any of the following classes:
|
Omission |
Necessary information about the system has been omitted from the design document, or a requirement from the requirements document was not addressed in the design. (e.g. a necessary class, attribute, or method does not appear in the design.) |
|
Ambiguous Information |
Information within the design document is ambiguous, i.e. any of a number of interpretations may be derived that should not be the prerogative of the developer doing the implementation. |
|
Inconsistency |
Information within one part of the design is inconsistent with other information in the design. For example, information in the sequence diagram does not correspond to information presented in the high-level design. |
|
Incorrect fact |
Some information in the design contradicts information in the requirements document or general domain knowledge. |
|
Extraneous |
Information is provided that is not needed or used. (e.g. attributes which will not be used are given for a class.) |
|
Miscellaneous |
Other defects (e.g. mistakes in notation) |
Keep in mind that your team will have the option of developing the loan application based on the design that you reviewed. Hence, it is important not just to identify as many faults as possible in the design, but also to minimize the number of "false positives" reported on your fault forms. Your grade on this portion of the assignment will not be based on the faults you discover. Your grade will be based on how effective your group meetings are at merging the fault lists.
Your fault list must be emailed to Baris (vb43520@umd5.umd.edu) by Wednesday Nov. 4 at 11:59pm. Baris will send an ASCII version of form 3.2 to you via e-mail. Form 3.2 is the form on which you will submit your fault lists. A printed copy of form 3.2 is included with these directions to show you what kind of information must be submitted. Keep track of how long you spend merging the fault lists; you will need this information to answer some of the questions at the bottom of the report form (these questions are for statistical purposes only and will not be used in determining your grade).
If any new faults (faults found during the group meeting and were not reported by any member of your team during assignment 3A) are discovered, please mark them by putting an asterisk (*) before the fault number on form 3.2. Likewise, if any faults with the requirements document are discovered during the design review phase, please e-mail a description of that fault and when it was discovered to Baris.
Your grade will be based on how well you conformed to the process that you were given, NOT on the faults you report.
Be sure to keep a copy of the completed form 3.2 file for yourself! You will need to reuse some of this information on future phases of this assignment.
NOTE: This assignment is part of a study. As always, working with students outside your group will be considered cheating, but for the purposes of the study it is especially crucial that you do not discuss your work with other students in the class. The motivation and design of the study will be discussed in class later this semester.