This research is not intended to evaluate the designer nor maintainer (The displayed data will not contain your name)
Instructions:
Use one table for each defect found on the project
Mark the defect on the ``__'' space. Do not mark more then once in the same field
If the classification is not possible, write the possible classification on the ``N/C ____'' space
Description of the Fields:
Project/Subsystem - Type the project and subsystem names
Designer / Maintainer - Type the designer and maintainer (your) names
Source - Origin of the defect component or module
Vendor - Defect caused by vendor acquired component
New Design -Defect caused by newly in-house developed component
Reused Design -Defect caused by reused component (previous design)
Date - Type the date on the format Month/Day/Year
Page - Type the number of the current page and then the total of pages you are submitting
Development Phase - Mark the phase where the defect was found (not the phase where the defect was introduced). Usually, this is the actual phase of the project
Severity/Impact - This is an index of the severity and impact of the defect on the subsystem-system. Mark the severity of the defect according to the following:
Severity 1- The defect fail the subsystem. Redesign is imperative
Severity 2 - The defect alter the functionality of the system. The subsystem might fail if no fix is performed. Redesign is recommended.
Severity 3- The defect alter the functionality of the subsystem but did not imply a failure. Re-evaluation of the design is recommended
History - Indicate whether this defect was considered during the design or not, known or repeated. Mark the defect history according to the following:
Considered - The defect was improperly addressed during the design
Non Considered - The defect was not addressed during the design
Known - The defect is a know defect, not new for the designer or maintainer
Supposed Fixed - The defect was supposed fixed previously
Repeated - The defect happened before with the designer or maintainer
Trigger - The trigger activate, discover faults. It might be environment or condition that helps, force a fault to appear. Mark the type of trigger according to the following:
Formal Review - Human factors that identify faults by thinking about design conformance, compatibility, previous experiences, and implementation discussions. In this case in a formal discussion with project reviewers
Informal Review - Human factors that identify faults. This might happen on a basis of per to per. For instance a designer discussing his design with another person or searching for different opinion
Component Test - Test of individual subsystem/components
System Test - Test of subsystems working together as a final product (integrated)
Stress Test - Submitting the subsystems/system to extreme conditions
Field Test - Submitting to tests on the field
User Operation - During user operation
Defect Types - The defect types are general enough to be applied to many robotic subsystem. It should be possible to classify a defect found in any phase of the development process. Mark the type of defect according to the following:
Function - The component is not working as expected by the designer. The component is working perfectly as on its manufacturer specification. The component is being marginally used or out of its specification.
Environment - The component will/is not working because of the environment. (e.g., heat, vibration, mechanical shock, dust, light, radiation)
Interface - The component interface is not compatible with other components
Interaction - The component is not working in the subsystem, but it works alone. The component does not work in the presence of another component. (e.g., interferences, incompatibility during operation)
Assembly - The component is not working because of improper assembly
Intermittent - The component works and stop working for unknown reasons
Damage - The component is damaged
Manufacture - The component does not meet the design specification or manufacturer datasheet
Documentation - Errors on instructions, maintenance notes, schematics, drafts, and diagrams
Short Description - This information will enable a better understanding of how the designer had classified. It might also enable future work such as knowledge extraction.
Software (IBM ODC)
Function - SOFTWARE; ``a function defect is one that affects significant capability, end-user features, product application programming interface (API), interface with hardware architecture, or global structure(s). It would require a formal design change.''
Interface - SOFTWARE; ``corresponds to errors in interacting with other components, modules, device drivers via macros, call statements, control blocks, or parameters lists.''
Checking - SOFTWARE; ``addresses program logic that has failed to properly validate data and values before they are used, loop conditions, etc.''
Timing / serialization - SOFTWARE; ``are those that are corrected by improved management of shared and real-time resources.''
Build / package / merge - SOFTWARE; ``these terms describe errors that occur due to mistakes in library systems, management of changes, or version control.''
Documentation - SOFTWARE; ``errors can affect both publications and maintenance notes.''
Algorithm - SOFTWARE; ``errors include efficiency or correctness problems that affect the task and can be fixed by (re)implementing an algorithm or local data structure without the need for requesting a design change.''