Method and apparatus for processing defect data indicative of defects in a product is described. In one example, each of the defects is assigned one of a plurality of severity levels and one of a plurality of impact levels. The defects are classified into categories based on combinations of severity level and impact level. A graphic representative of a topographical relation among numbers of defects in the categories is generated. The graphic is displayed on a graphical user interface (gui).
|
1. A method of processing defect data indicative of defects in a product, comprising:
receiving defect data from an end-user, wherein the defect data is indicative of defects in a product at an end-user's environment;
assigning each of the defects one of a plurality of severity levels;
assigning each of the defects one of a plurality of impact levels;
classifying the defects into categories based on combinations of severity level and impact level;
automatically generating a graphic representative of a topographical relation among numbers of defects in the categories; and
displaying the graphic on a graphical user interface (gui);
wherein the graphic comprises a histogram having a first axis representing severity level, a second axis representing impact level, and a third axis representing a number of defects, the first axis and the second axis defining bins respectively associated with the categories.
8. Apparatus for processing defect data indicative of defects in a product, comprising:
means for receiving defect data from an end-user, wherein the defect data is indicative of defects in a product at an end-user's environment;
means for assigning each of the defects one of a plurality of severity levels;
means for assigning each of the defects one of a plurality of impact levels;
means for classifying the defects into categories based on combinations of severity level and impact level;
means for automatically generating a graphic representative of a topographical relation among numbers of defects in the categories; and
means for displaying the graphic on a graphical user interface (gui);
wherein the graphic comprises a histogram having a first axis representing severity level, a second axis representing impact level, and a third axis representing a number of defects, the first axis and the second axis defining bins respectively associated with the categories.
14. A computer readable storage medium having stored thereon program instructions that, when executed by a processor, cause the processor to perform a method of:
receiving defect data from an end-user, wherein the defect data is indicative of defects in a product at an end-user's environment;
assigning each of the defects one of a plurality of severity levels;
assigning each of the defects one of a plurality of impact levels;
classifying the defects into categories based on combinations of severity level and impact level;
automatically generating a graphic representative of a topographical relation among numbers of defects in the categories; and
displaying the graphic on a graphical user interface (gui);
wherein the graphic comprises a histogram having a first axis representing severity level, a second axis representing impact level, and a third axis representing a number of defects, the first axis and the second axis defining bins respectively associated with the categories.
5. A method of processing defect data indicative of defects in a product, comprising:
receiving defect data from an end-user, wherein the defect data is indicative of defects in a product at an end-user's environment;
assigning each of the defects one of a plurality of severity levels;
assigning each of the defects one of a plurality of impact levels;
classifying the defects into categories based on combinations of severity level and impact level;
automatically generating a graphic representative of a topographical relation among numbers of defects in the categories;
displaying the graphic on a graphical user interface (gui);
assigning a threshold to each of the categories;
comparing the number of defects in each of the categories with the threshold assigned thereto;
automatically displaying, for each category of the categories where the number of defects therein exceeds the threshold assigned thereto, an alert graphic on the gui; and
assigning each of the categories a priority level;
wherein an action is displayed for each alert graphic based on the priority level assigned to the category.
17. A computer readable storage medium having stored thereon program instructions that, when executed by a processor, cause the processor to perform a method of:
receiving defect data from an end-user, wherein the defect data is indicative of defects in a product at an end-user's environment;
assigning each of the defects one of a plurality of severity levels;
assigning each of the defects one of a plurality of impact levels;
classifying the defects into categories based on combinations of severity level and impact level;
automatically generating a graphic representative of a topographical relation among numbers of defects in the categories;
displaying the graphic on a graphical user interface (gui);
assigning a threshold to each of the categories;
comparing the number of defects in each of the categories with the threshold assigned thereto; and
automatically displaying, for each category of the categories where the number of defects therein exceeds the threshold assigned thereto, an alert graphic on the gui; and
assigning each of the categories a priority level;
wherein an action is displayed for each alert graphic based on the priority level assigned to the category.
11. Apparatus for processing defect data indicative of defects in a product, comprising:
means for receiving defect data from an end-user, wherein the defect data is indicative of defects in a product at an end-user's environment;
means for assigning each of the defects one of a plurality of severity levels;
means for assigning each of the defects one of a plurality of impact levels;
means for classifying the defects into categories based on combinations of severity level and impact level;
means for automatically generating a graphic representative of a topographical relation among numbers of defects in the categories;
means for displaying the graphic on a graphical user interface (gui);
means for assigning a threshold to each of the categories;
means for comparing the number of defects in each of the categories with the threshold assigned thereto;
means for automatically displaying, for each category of the categories where the number of defects therein exceeds the threshold assigned thereto, an alert graphic on the gui; and
means for assigning each of the categories a priority level;
wherein an action is displayed for each alert graphic based on the priority level assigned to the category.
3. The method of
4. The method of
6. The method of
7. The method of
9. The apparatus of
10. The apparatus of
12. The apparatus of
13. The apparatus of
15. The computer readable storage medium of
16. The computer readable storage medium of
18. The computer readable storage medium of
19. The computer readable storage medium of
|
This application claims benefit of U.S. provisional patent application Ser. No. 60/714,921, filed Sep. 7, 2005, which is incorporated by reference herein.
1. Field of the Invention
Embodiments of the present invention generally relate to product analysis and, more particularly, to a method and apparatus for product defect classification.
2. Description of the Related Art
Companies that supply products and services to end users track defects associated with such products and services (generally referred to as product defects). Product defects may be discovered before the product is released on a wide scale, such as during manufacture of a product or during beta testing of a product. Product defects may also be discovered after the product is released, such as through technical support calls from end users. Not all defects affect the product in the same way. For example, some defects affect the core functionality of a product such that the product cannot be used for its intended purpose. Other defects affect non-core functions and do not cause the product to be unusable. While the former defects may require an immediate action, the latter may not. Since there are many different types of defects that require various actions, merely storing a list of defects as such defects are discovered for a product is not an efficient product analysis mechanism. Accordingly, there exists a need in the art for an improved method and apparatus for product defect classification.
Method and apparatus for processing defect data indicative of defects in a product is described. In one embodiment, each of the defects is assigned one of a plurality of severity levels and one of a plurality of impact levels. The defects are classified into categories based on combinations of severity level and impact level. A graphic representative of a topographical relation among numbers of defects in the categories is generated. The graphic is displayed on a graphical user interface (GUI).
So that the manner in which the above recited features of the present invention can be understood in detail, a more particular description of the invention, briefly summarized above, may be had by reference to embodiments, some of which are illustrated in the appended drawings. It is to be noted, however, that the appended drawings illustrate only typical embodiments of this invention and are therefore not to be considered limiting of its scope, for the invention may admit to other equally effective embodiments.
The memory 103 may store all or portions of one or more programs and/or data to implement the processes and methods described herein. Notably, the memory 103 may store program code to be executed by the processor 101 for implementing a defect classification system 120. The memory 103 may include one or more of the following random access memory, read only memory, magneto-resistive read/write memory, optical read/write memory, cache memory, magnetic read/write memory, and the like, as well as signal-bearing media as described below. The database 122 may comprise a portion of the memory 103 for the computer. Alternatively, the database 122 may be more sophisticated, such as a database server configured with a well-known database platform (e.g., database software commercially available from Oracle Corporation).
The computer 100 may be programmed with an operating system, which may be OS/2, Java Virtual Machine, Linux, Solaris, Unix, Windows, Windows95, Windows98, Windows NT, and Windows2000, WindowsME, and WindowsXP, among other known platforms. At least a portion of an operating system may be disposed in the memory 103. Although one or more aspects of the invention are disclosed as being implemented as a computer executing a software program, those skilled in the art will appreciate that the invention may be implemented in hardware, software, or a combination of hardware and software. Such implementations may include a number of processors independently executing various programs and dedicated hardware, such as ASICs.
In operation, a user interacts with the defect classification system 120 via one or more of the input devices 112, the output devices 111, and a graphical user interface (GUI) on the display 116. The defect classification system 120 receives data indicative of product defects (“product defect descriptions”) from the external systems 150 for one or more products. The term “product” is meant to include both products and services. The external systems 150 may include various systems for tracking defects in products, such as technical support systems, quality control systems, and the like. A user interacts with the defect classification system 120 to classify the product defect descriptions. Classified defect data 124 may be stored in the database 122 for the product(s). Information derived from the classified defect data 124 may be displayed to a user via the GUI 118. The classified defect data 124 may be updated periodically via user interaction with the GUI 118. An exemplary embodiment of the defect classification system 120 is described immediately below with respect to
The classification module 202 is also configured to receive severity rule data 210 and impact rule data 212. The severity rule data 210 defines a plurality of severity levels assignable product defects. Severity is defined as the seriousness of a defect from the point of view of the end users of the product. Severity is not altered by the technical nature of the underlying defect. For example, if a defect is especially difficult to fix, or requires extensive hardware changes, the severity is not altered. Also, the likelihood of encountering a defect does not affect severity (N.B., this is captured in the impact classification, discussed below). Severity includes not only how the product functions “stand-alone,” but also how it functions within the end user environment. For example, if a networking product does not function when used in conjunction with an end user's existing home network without removing or reconfiguring other devices, this would be considered a defect.
Severity is not dictated by product requirement specifications, but rather by expected performance from an end user point of view. For example, end users may have an expectation that a product performs a certain way. If the product does not function as expected, then this is a defect from the end user point of view, even if the product is functioning as designed. The root cause of the defect may be inadequate product specification or inadequate documentation, but it is a defect none-the-less.
In one embodiment, the severity rule data 210 defines five severity levels. A first severity level (S1) represents the most severe defect. For example, the product or some core functionality of the product is inoperative and there is no workaround. A defect having an S1 severity level will very likely generate both technical support calls and returns of product. A second severity level (S2) is less severe than the S1 level. For example, the product requires a workaround to regain core functionality or a non-core function is inoperative, but the end user is still able to use the core functions of the product. A workaround is not easy or trivial. A defect having an S2 severity level will likely generate technical support calls and may generate returns of product.
A third severity level (S3) is less severe than the S2 level. For example, some feature of the product is confusing to use or is apt to be used incorrectly. The product requires a trivial workaround to recover a non-core function. A defect having an S3 severity level may generate technical support calls. A fourth severity level (S4) is less severe than the S3 level. For example, defects having an S4 severity level may relate to “fit and finish” issues. Product appearance, function, or performance is not as the end user expects or desires or is substandard to what would reasonably be expected of the product brand. A defect having the S4 severity level is not likely to generate support calls.
A fifth severity level (S5) is less severe than the S4 level. For example, defects having an S5 severity level may relate to enhancement issues. That is, the product may be enhanced if it had a particular feature, but is otherwise functioning as expected by the end user. Those skilled in the art will appreciate that the severity rule data 210 may include any number of severity levels having various criteria other than those listed above. In general, the severity levels are defined with respect to expected performance of the product from an end user point of view.
The following are some exemplary defects and corresponding severity levels for a networking device, such as a telephony device:
1) Product does not function with a particular model router: Severity 1;
2) Second line of two-line phone system does not ring if first line is off hook: Severity 1;
3) Product requires a router to be upgraded in order to function: Severity 2;
4) Product requires a static internet protocol (IP) address to be manually configured to function: Severity 2;
5) Product's phone book is not intuitive to use and causes users to lose entries: Severity 3;
6) Product has minor surface blemish on a secondary surface: Severity 4;
7) Product's screen saver should be configurable: Severity 5.
The impact rule data 212 defines a plurality of impact levels assignable product defects. Impact quantifies how likely end users are to encounter a particular defect. In one embodiment, impact is a combination of two main factors: (1) the percentage of the end user base that can experience the defect; and (2) the likelihood of an end user who could encounter the problem actually encountering the defect. For example, a product may include a defect that all end users experience if they use the product is an unusual way. A product may include a defect that affects all end users who have a particular third-party product, albeit a third-party product with a small market share. In both of these examples, the overall impact is lower than it might otherwise be.
In one embodiment, the impact rule data 212 defines five impact levels. The five impact levels are based on the estimated percentage of end users who will encounter the defect. A first impact level (I1) represents the most impact. For example, 20-100% of the end users will encounter an I1 defect. A second impact level (I2) represents less impact than the I1 level. For example, 5-20% of the end users will encounter an I2 defect. A third impact level (I3) represents less impact that the I2 level. For example, 2-5% of the end users will encounter an I3 defect. A fourth impact level (I4) represents less impact that the I3 level. For example, 0.5-2% of the end users will encounter an I4 defect. Finally, a fifth impact level (I5) represents less impact that the I4 level. For example, less than 0.5% of the end users will encounter an I5 defect. Those skilled in the art will appreciate that the impact rule data 212 may include any number of impact levels having various impact percentages or percentage ranges other than those listed above. In general, the impact levels are based on the estimated percentage of end users who will encounter the defect.
The classification module 202 assigns a severity level and an impact level to each defect in the product defect descriptions 208. For example, each product defect description may be displayed to a user on a GUI and the user may assign a corresponding severity level and impact level in accordance with the severity rule data 210 and the severity rule data 212. The classification module 202 may assign various other types of information to each defect in the product defect descriptions 208, such as defect identifiers, company reference numbers, notes related to the defects, and the like. The classification module 202 produces classified defect data 214 as output. The classified defect data 214 may be stored in a database for further processing, as described below.
Returning to
For example, if a defect for a particular product is generating technical support calls with questions or complaints, it may be necessary to change the severity level to a higher severity level. In another example, some defects may not affect product functionality are thus initially assigned a low severity level (e.g., an S5). However, it may be determined later that the defects have such an adverse effect on the end user's perception of the product brand that the severity levels need to be elevated. For example, if a product contained a defect where the brand name was misspelled on the product, the defect may be elevated to a S1 severity level.
The visualization engine 204 is configured to receive the classified defect data 214. The visualization engine 204 automatically generates a graphic representation of a topographical relation among the classified defects for a particular product (“visual representation 216”). For example, each defect may be classified into a particular category based on severity level and impact level. If there are five severity levels and five impact levels, there are 25 possible categories to which a defect belongs. In particular, the categories include (S1,I1) . . . (S1,I5), (S2,I1) . . . (S2,I5), and so on until (S5,I1) . . . (S5,I5). For a given product, there is a particular number defects in each category (including zero defects). In one embodiment, the graphic comprises a histogram. The bins of the histogram correspond to the possible categories among which the defects are distributed. The histogram is three dimensional having first and second axes for the severity level and impact level, which define the bins of the histogram. A third axis represents a number of defects in a given bin. The visual representation 216 may be displayed on a GUI to a user. The visual representation 216 advantageously provides an overall view of the state of a product with respect to product defects. The visual representation 216 provides a concise view of the classified defect data 214.
Returning to
In one embodiment, the alert engine 206 is further configured to receive priority level data 220. The priority level data 220 includes a plurality of priority levels associated with particular severity level/impact level categories. For example, a highest priority level (P1) may require immediate action (e.g., action within hours). A lower priority level (P2) may require an action be taken in an emergency change control board (CCB) meeting. As used herein, a “CCB meeting” is a meeting to discuss and plan product changes. A lowest priority level (P3) may require an action to be taken in a regularly scheduled CCB meeting. Those skilled in the art will appreciate that other types of priority levels may be defined with respect to other types of actions to be taken in response to a particular category of defect.
A particular alert graphic generated by the alert engine 206 may further include text recommending a particular action based on priority level for the defect. For example, an (S1,I1) defect affects a large percentage of end users in such a way that the end users cannot use the product. Therefore, if a defect in this category is discovered, it will require immediate attention to determine the appropriate action (e.g., such a category is assigned a P1 priority level). A triggered alert graphic may include the text “Immediate action required.” An (S2,I1) or an (S2,I2) defect may be important enough to merit an emergency CCB meeting to determine what further action may be may not be necessary (e.g., such categories are assigned a P2 priority level). It may not be sufficient to wait for the next scheduled CCB meeting. A triggered alert graphic for these categories may include the text “Emergency CCB meeting required.” Defects in other categories may be discussed in a regularly scheduled CCB meeting (e.g., such categories are assigned a P3 priority level). A triggered alert for these categories may include the text “Discuss at next scheduled CCB meeting.” Those skilled in the art will appreciate that the severity level/impact level categories may be assigned different priority levels than the examples above.
An aspect of the invention is implemented as a program product for use with a computer system. Program(s) of the program product defines functions of embodiments and can be contained on a variety of signal-bearing media, which include, but are not limited to: (i) information permanently stored on non-writable storage media (e.g., read-only memory devices within a computer such as CD-ROM or DVD-ROM disks readable by a CD-ROM drive or a DVD drive); (ii) alterable information stored on writable storage media (e.g., floppy disks within a diskette drive or hard-disk drive or read/writable CD or read/writable DVD); or (iii) information conveyed to a computer by a communications medium, such as through a computer or telephone network, including wireless communications. The latter embodiment specifically includes information downloaded from the Internet and other networks. Such signal-bearing media, when carrying computer-readable instructions that direct functions of the invention, represent embodiments of the invention.
While the foregoing is directed to embodiments of the present invention, other and further embodiments of the invention may be devised without departing from the basic scope thereof, and the scope thereof is determined by the claims that follow.
Doblmaier, Tom, Groat, Evan A., Goffin, Glen P., Grubb, David, Mensoff, Steven M., Quigley, Dan
Patent | Priority | Assignee | Title |
10185649, | Sep 11 2009 | International Business Machines Corporation | System and method for efficient creation and reconciliation of macro and micro level test plans |
10228678, | Jul 22 2015 | Tokyo Electron Limited | Tool failure analysis using space-distorted similarity |
10235269, | Sep 11 2009 | International Business Machines Corporation | System and method to produce business case metrics based on defect analysis starter (DAS) results |
10372593, | Sep 11 2009 | International Business Machines Corporation | System and method for resource modeling and simulation in test planning |
8352237, | Sep 11 2009 | BROADCOM SEMICONDUCTORS ISRAEL LTD | System and method for system integration test (SIT) planning |
8495583, | Sep 11 2009 | HCL Technologies Limited | System and method to determine defect risks in software solutions |
8527955, | Sep 11 2009 | International Business Machines Corporation | System and method to classify automated code inspection services defect output for defect analysis |
8539438, | Sep 11 2009 | International Business Machines Corporation | System and method for efficient creation and reconciliation of macro and micro level test plans |
8566805, | Sep 11 2009 | International Business Machines Corporation | System and method to provide continuous calibration estimation and improvement options across a software integration life cycle |
8578341, | Sep 11 2009 | International Business Machines Corporation | System and method to map defect reduction data to organizational maturity profiles for defect projection modeling |
8635056, | Aug 27 2012 | International Business Machines Corporation | System and method for system integration test (SIT) planning |
8645921, | Sep 11 2009 | HCL Technologies Limited | System and method to determine defect risks in software solutions |
8667458, | Sep 11 2009 | International Business Machines Corporation | System and method to produce business case metrics based on code inspection service results |
8689188, | Sep 11 2009 | International Business Machines Corporation | System and method for analyzing alternatives in test plans |
8893086, | Sep 11 2009 | International Business Machines Corporation | System and method for resource modeling and simulation in test planning |
8924936, | Sep 11 2009 | International Business Machines Corporation | System and method to classify automated code inspection services defect output for defect analysis |
9052981, | Sep 11 2009 | International Business Machines Corporation | System and method to map defect reduction data to organizational maturity profiles for defect projection modeling |
9176844, | Sep 11 2009 | International Business Machines Corporation | System and method to classify automated code inspection services defect output for defect analysis |
9262736, | Sep 11 2009 | International Business Machines Corporation | System and method for efficient creation and reconciliation of macro and micro level test plans |
9292421, | Sep 11 2009 | International Business Machines Corporation | System and method for resource modeling and simulation in test planning |
9442821, | Sep 11 2009 | International Business Machines Corporation | System and method to classify automated code inspection services defect output for defect analysis |
9558464, | Sep 11 2009 | HCL Technologies Limited | System and method to determine defect risks in software solutions |
9594671, | Sep 11 2009 | International Business Machines Corporation | System and method for resource modeling and simulation in test planning |
9710257, | Sep 11 2009 | International Business Machines Corporation | System and method to map defect reduction data to organizational maturity profiles for defect projection modeling |
9753838, | Sep 11 2009 | International Business Machines Corporation | System and method to classify automated code inspection services defect output for defect analysis |
Patent | Priority | Assignee | Title |
5818953, | Apr 17 1996 | CONAGRA FOODS PACKAGED FOODS COMPANY, INC | Optical characterization method |
5917332, | May 09 1996 | Advanced Micro Devices, INC | Arrangement for improving defect scanner sensitivity and scanning defects on die of a semiconductor wafer |
6092059, | Dec 27 1996 | AMETEK, INC | Automatic classifier for real time inspection and classification |
6334097, | Jan 22 1998 | Hitachi, Ltd. | Method of determining lethality of defects in circuit pattern inspection method of selecting defects to be reviewed and inspection system of circuit patterns involved with the methods |
6456951, | Jan 06 1999 | Hitachi, LTD | Method and apparatus for processing inspection data |
6701259, | Oct 02 2000 | Applied Materials, Inc.; Applied Materials, Inc | Defect source identifier |
6741940, | Sep 25 2001 | Renesas Electronics Corporation; NEC Electronics Corporation | Computer-implemented method of defect analysis |
6982556, | Jun 06 2003 | Yieldboost Tech, Inc.; YIELDBOOST TECH, INC | System and method for classifying defects in and identifying process problems for an electrical circuit |
Executed on | Assignor | Assignee | Conveyance | Frame | Reel | Doc |
Dec 20 2005 | QUIGLEY, DAN | General Instrument Corporation | ASSIGNMENT OF ASSIGNORS INTEREST SEE DOCUMENT FOR DETAILS | 017614 | /0210 | |
Dec 21 2005 | MENSOFF, STEVE | General Instrument Corporation | ASSIGNMENT OF ASSIGNORS INTEREST SEE DOCUMENT FOR DETAILS | 017614 | /0210 | |
Dec 21 2005 | GROAT, EVAN A | General Instrument Corporation | ASSIGNMENT OF ASSIGNORS INTEREST SEE DOCUMENT FOR DETAILS | 017614 | /0210 | |
Dec 21 2005 | GOFFIN, GLEN P | General Instrument Corporation | ASSIGNMENT OF ASSIGNORS INTEREST SEE DOCUMENT FOR DETAILS | 017614 | /0210 | |
Dec 22 2005 | General Instrument Corporation | (assignment on the face of the patent) | / | |||
Jan 03 2006 | DOBLMAIER, TOM | General Instrument Corporation | ASSIGNMENT OF ASSIGNORS INTEREST SEE DOCUMENT FOR DETAILS | 017614 | /0210 | |
Feb 06 2006 | GRUBB, DAVID | General Instrument Corporation | ASSIGNMENT OF ASSIGNORS INTEREST SEE DOCUMENT FOR DETAILS | 017614 | /0210 | |
Apr 15 2013 | General Instrument Corporation | GENERAL INSTRUMENT HOLDINGS, INC | ASSIGNMENT OF ASSIGNORS INTEREST SEE DOCUMENT FOR DETAILS | 030764 | /0575 | |
May 28 2013 | GENERAL INSTRUMENT HOLDINGS, INC | Motorola Mobility LLC | ASSIGNMENT OF ASSIGNORS INTEREST SEE DOCUMENT FOR DETAILS | 030866 | /0113 | |
Oct 28 2014 | Motorola Mobility LLC | Google Technology Holdings LLC | ASSIGNMENT OF ASSIGNORS INTEREST SEE DOCUMENT FOR DETAILS | 035354 | /0420 |
Date | Maintenance Fee Events |
Apr 24 2012 | M1551: Payment of Maintenance Fee, 4th Year, Large Entity. |
Jun 24 2016 | REM: Maintenance Fee Reminder Mailed. |
Nov 11 2016 | EXP: Patent Expired for Failure to Pay Maintenance Fees. |
Date | Maintenance Schedule |
Nov 11 2011 | 4 years fee payment window open |
May 11 2012 | 6 months grace period start (w surcharge) |
Nov 11 2012 | patent expiry (for year 4) |
Nov 11 2014 | 2 years to revive unintentionally abandoned end. (for year 4) |
Nov 11 2015 | 8 years fee payment window open |
May 11 2016 | 6 months grace period start (w surcharge) |
Nov 11 2016 | patent expiry (for year 8) |
Nov 11 2018 | 2 years to revive unintentionally abandoned end. (for year 8) |
Nov 11 2019 | 12 years fee payment window open |
May 11 2020 | 6 months grace period start (w surcharge) |
Nov 11 2020 | patent expiry (for year 12) |
Nov 11 2022 | 2 years to revive unintentionally abandoned end. (for year 12) |