Bug Resolution Case Study
Description
Case study Description
Business Goals and Domain Assumptions
Business Goals for the current case study.
Business Goals
Field | Description |
---|---|
UniqueID | BUG-BG1 |
Short Name | Enable efficient duplicates identification |
Type | Business Goals. |
Description | Help developers and gatekeepers to manage issues. Developers should not work on duplicates, but instead access all duplicates issue entries to get more description on the issue. Gatekeepers should be notified of possible duplicates. Customers should be notified when their entry is a possible duplicate. |
Rationale | Developers lose time with duplicates. Duplicate entries should instead help to get more complete information. |
Involved Stakeholders | Customer, Gatekeeper |
Conflicts | Poor detection could ruin the process. |
Priority of accomplishment | Should have. |
Field | Description |
---|---|
UniqueID | BUG-BG2 |
Short Name | Enable efficient issue resolution |
Type | Business Goals. |
Description | As much as possible relevant information should be providedd in order to resolve an issue |
Rationale | The resolution of an issue requires an appropiate provision of relevant information, timely and content-based |
Involved Stakeholders | Developer, Leader, Gatekeeper |
Conflicts | None |
Priority of accomplishment | Must have. |
Scenarios
The following figure shows the general use-case diagram for the Bug Resolution case study.
Field | Description | ||||||
---|---|---|---|---|---|---|---|
UniqueID | S1.1 | ||||||
Short Name | Detect possible duplicate issues at creation | ||||||
Brief Description | The Customer (or developer) enters and describes an issue | ||||||
Related To | BUG-BG1 | ||||||
Involved Actors | Customer | ||||||
Detailed Operational Description | The customer enters an issue. If a potential duplicate is spotted, he is asked to check it. A gatekeeper is notified about the new issue. | ||||||
Problems and Challenges | Notify the customer on time, so he/she can validate it's duplicate.
Good quality detection. |
Business Trigger | Customer encounters an issue and reports it. | Preconditions | An issue tracking system is installed and ALERT is configure to retrieve information from it. | Postconditions | If the customer validate the duplicate it is marked as a very probable duplicate, and a gatekeeper has been asked to merge it.
If the customer didn't validate the duplicate it is marked as a potencial duplicate. |
Field | Description | ||||||
---|---|---|---|---|---|---|---|
UniqueID | S1.2 | ||||||
Short Name | Spot a duplicated issue for merging. | ||||||
Brief Description | The Gatekeeper spots a duplicated issue and merge it. | ||||||
Related To | BUG-BG1 | ||||||
Involved Actors | Gatekeeper, Developer, Customer | ||||||
Detailed Operational Description | The gatekeeper is suggested potential duplicates in order to merge them or take an action on them. | ||||||
Problems and Challenges | Duplicates detection is very complex. If not efficient enough, it will be useless. | Business Trigger | A newly created issue was identified as possible duplicate. | Preconditions | ALERT is installed. A new issue has just been created, but not reviewed yet. | Postconditions | Suggestion is remembered as good by the system. The gatekeeper is ready to merge the issue. |
Field | Description | |||||
---|---|---|---|---|---|---|
UniqueID | S2.1 | |||||
Short Name | Show issues relevant to my code | |||||
Brief Description | Present the developer all information relevant to his/her code. | |||||
Related To | BUG-BG2 | |||||
Involved Actors | Developer | |||||
Detailed Operational Description | Developer wants to get all possible information which is relevant to his/her code. The developer searches through the relevant information space and can select part of the results to be visualized in a proper way. | |||||
Problems and Challenges | The code must be annotated properly.
The extracted knowledge must be annotated properly. |
Business Trigger | None | System installed. Knowledge is extracted from available information sources. | Postconditions | The developer found all the issues related to the work he did in the past, or he is doing now (similar issues). |
Field | Description | |||||
---|---|---|---|---|---|---|
UniqueID | S2.2 | |||||
Short Name | Display extended issue view | |||||
Brief Description | Add more information about an issue on the BTS. | |||||
Related To | BUG-BG2 | |||||
Involved Actors | Gatekeeper, Developer, Leader | |||||
Detailed Operational Description | The BTS shows standard information about an issue when looking at an issue, ALERT will enhance this view with additional information. The developer will know all the history of this issue, potential duplicates and useful information to solve this issue. The leader will be able to assign this issue from this view, and the gatekeeper will be able to get suggested potential duplicates. | |||||
Problems and Challenges | Have a smooth transition between ALERT UI and other UIs when taking an action (i.e. I want to merge two duplicates in the BTS, propose me a link going to the bug description page or, if possible, to the page to merge this bug).
The additional information must be relevan enough, which involves an efficient filtering system. |
Business Trigger | An actor (except customer) is viewing the issue. | ALERT installed. An issue is entered. | Postconditions | The developer has had all necessary information about the issue he is working on.
Suggest assignees to the leader: Go to "Assign one issue" scenario. Suggest duplicates to the Gatekeeper: Go to S1.2 |
Field | Description | ||||||
---|---|---|---|---|---|---|---|
UniqueID | S2.3 | ||||||
Short Name | Search the knowledge base with a keyword or topic | ||||||
Brief Description | Enable searching through the knowledge based using keywords. | ||||||
Related To | BUG-BG2 | ||||||
Involved Actors | Gatekeeper, Developer, Leader | ||||||
Detailed Operational Description | Leader, developer, gatekeeper perform keyword-based search using a suitable interface. The returned list is sorted by the relevance and clustered based on predefined criteria and customer profile. In case of too lees or too many results, appropiate changes in the search criteria should be provided. | ||||||
Problems and Challenges | The code and all other information sources must be annotated properly.
The actors profile must be available. The developer did not define the key words for the issue precisely or did not access to other information sources, so the system does not have the input data. |
Business Trigger | A new developer joined the organization and began working on one part of the code. | Preconditions | System installed. Knowledge is extracted from available information sources. Actor's profile available.
The new developer has access to the ALERT system, authorized access to his/her profile and access to its basic options. |
Postconditions | The actor found the information he/she was looking for (any kind of information) from subsystems (wiki, forum, BTS...).
In case that the list of search results is empty: New result page is shown with the same result or more. In case that the list of search results is too long: New result page is shown with the same results or less. In the case that the actor is a new developer: The new developer is familiarized with the project and the code parts he/she is interested in. |