Bug Resolution Case Study
From Scube-casestudies
Description
There is a common problematic in Open Source communities related to the way how they face the problems of solving an issue and the tools that they use. These communities don't have a standard way to define this process and they acknowledge the lack of communication between the non-integrated tools that they have. This case study describes a system which is designed to help communities to improve their efficiency solving bugs. Its main goal of is to gather and systemize requirements for the ALERT system. A detailed study of user requirements was performed, identifying the main factors (e.g. knowledge sources) that affect the efficiency and quality of the issue resolution. These factors were analyzed from the knowledge management point of view.
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. |
| Field | Description |
|---|---|
| UniqueID | BUG-BG3 |
| Short Name | Reduce emails, increase relevance |
| Type | Business Goals. |
| Description | Developer gets a lot of information by emails, and it begins difficult to select which one is relevant. ALERT should send only relevant information to the developer. The notifications can be customized with custom rules, or be integrated in standard ALERT processes. |
| Rationale | Developers gets too many emails and would save time and do not miss important information if they did get relevant notifications. |
| Involved Stakeholders | Customer, Gatekeeper |
| Conflicts | Notifications need to be relevant. |
| Priority of accomplishment | Must have. |
| Field | Description |
|---|---|
| UniqueID | BUG-BG4 |
| Short Name | Accelerate issue attribution |
| Type | Business Goals. |
| Description | A new issue has been entered in the system and a developer and/or a leader should be informed about the issue as soon as possible.
It includes the situation that the sequence of interactions with the different information sources should be considered as a whole. It considers that the duplicates for this issue are resolved, i.e. this issue should not be considered as a duplicate issue. |
| Rationale | The information about a new issue should be spread over all relevant people (it might be only one) as soon as possible in order to create awareness about that issue, its consequences and urgency (for resolving).
This approach decreases the information overload. |
| Involved Stakeholders | Developer, Leader |
| Conflicts | None |
| Priority of accomplishment | Must have. |
| Field | Description |
|---|---|
| UniqueID | BUG-BG5 |
| Short Name | Help to monitor the community |
| Type | Business Goals. |
| Description | The system provides help to those involved with the project, with different levels of privileges, to follow the activities of the projects. Customization of profiles, recommendation of projects, familiarization with the project code or monitoring the activites of the project are just some of the options and helps the system offers. |
| Rationale | By accessing the community and the ALERT system, the developer should have an easy access to the information he/she needs, and the leader should be able to follow the activities on the project more easily. |
| Involved Stakeholders | Developer, Leader |
| Conflicts | A new developer joined the project and wants to start working, but does not have feedback. The leader follows the activities of the project, so he/she also needs an easier flow of the relevant data. |
| Priority of accomplishment | Should 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 |
| Preconditions | 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. |
| Preconditions | 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. |
| Field | Description |
|---|---|
| UniqueID | S3.1 |
| Short Name | Receive notifications |
| Brief Description | The developer receives notifications about the situation for which he/she is subscribed. |
| Related To | BUG-BG3 |
| Involved Actors | Developer |
| Detailed Operational Description | The developer receives notifications about the situation for which she is subscribed. Information sources may be the customer, the leader or the gatekeeper. |
| Problems and Challenges | The developer might be overloaded with emails containing different notifications which obstruct his/her efficient work. |
| Business Trigger | A situation which is of interest for the developer has been detected. |
| Preconditions | The developer is subscribed and works on solving the issue addresssed by the notification. |
| Postconditions | The developer is notified of all relevant information about the issue he/she works on.
Take an action if the actor is on another page: The action was already executed or will be easy to execute from this page. The system knows his/her suggestion was relevant. |
| Field | Description |
|---|---|
| UniqueID | S3.2 |
| Short Name | Register to notification |
| Brief Description | The custormer or developer can change his/her notifications preferences. |
| Related To | BUG-BG3 |
| Involved Actors | Customer, Developer, Leader, Gatekeeper |
| Detailed Operational Description | Any actor can register to notification or create his/her own notification rule. |
| Problems and Challenges | Proposed notifications must be well chosen.
Subscribing/unsubscribing must be an easy process. |
| Business Trigger | An actor wants to receive a notification or wants to receive fewer notifications. |
| Preconditions | ALERT installed. |
| Postconditions | Developer sees notification rules and is subscribed to them.
Customer or developer unsubsctibe a notification: Actor is logged. Leader changes default project notifications. |
| Field | Description |
|---|---|
| UniqueID | S3.3 |
| Short Name | Create a new notification rule |
| Brief Description | Design a new notification rule |
| Related To | BUG-BG3 |
| Involved Actors | Gatekeeper, Developer, Leader |
| Detailed Operational Description | An actor wants to define new interesting situations to be informed about (as soon as they appear). He/She is using the interaction pattern editor to design notification rules for these new situations. The actor can either develop a new rule from scratch or by reusing already defined rules. |
| Problems and Challenges | Interaction patterns depend on the domain ontology.
The complexity of the rules can exceed the expressiveness of the pattern language. |
| Business Trigger | None |
| Preconditions | System installed. Data related to ontologies are entered. |
| Postconditions | A new notification rule is generated.
An interaction pattern is deployed in the CEP engine. In case an actor starts from an existing pattern and wants to modify it: The information about the reuse of patterns is updated. |
| Field | Description |
|---|---|
| UniqueID | S4.1 |
| Short Name | Get a suggested issue to assign to myself |
| Brief Description | Inform the developer about an issue he/she might be interested in. |
| Related To | BUG-BG4 |
| Involved Actors | Developer |
| Detailed Operational Description | Developer would like to be informed as soon as an issue that can be of his/her interest appears. The system assigns some notification patterns to the developer. These rules are based on comparing the skills of the developer and the annotation provided for an issue. The system matches the input data with the desired patterns in real-time. In case of matching, new events will be produced and send to the developer. |
| Problems and Challenges | IReal-time data processing.
Inform the developer proactively. |
| Business Trigger | A developer is entering the system. |
| Preconditions | System installed. Issues are entered.
Every event related to the user expertise is a relevant notification rule. |
| Postconditions | The issue is assigned to a developer. The statistics about notification rules (complex event patterns) is updated.
In case a notification (issue) is out of the context: The statistics about irrelevant notification rules (complex event patterns) are updated. |
| Field | Description |
|---|---|
| UniqueID | S4.2 |
| Short Name | Get suggested developers to assign them an issue |
| Brief Description | Leader is searching for a developer who should resolve an issue. |
| Related To | BUG-BG4 |
| Involved Actors | Leader |
| Detailed Operational Description | Leader is searching for the issues to be resolved and the system assigns relevant developers for selected issues. |
| Problems and Challenges | The developers profiles should be available. |
| Business Trigger | Some notifications are coming from the system to the leader. Otherwise, he/she just starts searching for issues. |
| Preconditions | System installed. Issues are entered.
The leader has defined relevant notification rules. |
| Postconditions | Developer will be informed about the bugs that he/she could fix.
In case that the list of relevant developers is empty: New result page is proposed, with more results. In case that the list of relevant developers is too long: New result page is proposed, with less results. |
| Field | Description |
|---|---|
| UniqueID | S5.1 |
| Short Name | Read the history of a project's code |
| Brief Description | Reading the project code history. |
| Related To | BUG-BG5 |
| Involved Actors | Developer |
| Detailed Operational Description | A new developer familiarizes with the code, means of coding and issue history by reading the project code history. |
| Problems and Challenges | None |
| Business Trigger | A new developer is familiarized with the project, begins working on the code part and wants to be familiarized with the code itself. |
| Preconditions | The developer has access to the ALERT system, authorized access to his/her profile and access to basic options. |
| Postconditions | The new developer is familiarized with the project code history. |
| Field | Description |
|---|---|
| UniqueID | S5.2 |
| Short Name | Suggest a project to work on to new developers |
| Brief Description | The system suggests a project to work on to the developer. |
| Related To | BUG-BG5 |
| Involved Actors | Developer |
| Detailed Operational Description | Based on the developer's customized public profile, the system analyses the data and suggest a project which would match his/her expertise. |
| Problems and Challenges | Inadequate data in the developer public profile that were not validated by the leader. |
| Business Trigger | The developer is ready to operate, but has no assigned project. |
| Preconditions | The developer should have an authorized access to the system, should change his/her public profile and be familiarized with the basic project information. |
| Postconditions | The developer is assigned to the project for which he/she is responsible and which match his/her expertise. |
| Field | Description |
|---|---|
| UniqueID | S5.3 |
| Short Name | Create and customize public profile. |
| Brief Description | The developer customizes his/her public profile. |
| Related To | BUG-BG5 |
| Involved Actors | Developer |
| Detailed Operational Description | The developer joins the community by subscribin to the mailing list, forum or BTS. The system automatically creates a public profile. The developer completes the profile by entering personal data and chooses the level of privileges. He/She receives a notification of a successful or unsuccessful data entry. |
| Problems and Challenges | The profile is taken by other developers.
Entered data is incomplete. |
| Business Trigger | A new developer joined the project and was delegated to customize his/her public profile. |
| Preconditions | The system has automatically created a public profile for the developer based on his/her subscriptions to other systems apart from ALERT.
The developer has access to the data change interface on his/her profile. |
| Postconditions | All relevant data were entered into the new developer's profile.
The profile is already taken: The developer has verified his/her public profile. Not all data were entered into obligatory fields: Incomplete data entry was detected and the developer must repeat the process. |
| Field | Description |
|---|---|
| UniqueID | S5.4 |
| Short Name | Show ongoing project status |
| Brief Description | The leader wants to know what is the current status of the project, especially what are "hot" topics. |
| Related To | BUG-BG5 |
| Involved Actors | Leader |
| Detailed Operational Description | The leader wants to get more insights into the status of the project and uses different visualization tools to analyse trends. The most important one is the search of "hot" topics, i.e. topics which are very frequently mentioned in different contexts (discussions, comments about issues...). |
| Problems and Challenges | Visualization can take more time to be presented (complex statistical calculations).
Entered data is incomplete. |
| Business Trigger | None |
| Preconditions | System installed. Metadata available. |
| Postconditions | Leader has a real-time overview of the project. |
| Field | Description |
|---|---|
| UniqueID | S6.1 |
| Short Name | Install ALERT system |
| Brief Description | Make it easy for the administrator to install and configure ALERT. |
| Related To | None |
| Involved Actors | Administrator |
| Detailed Operational Description | In order to be deployed in communities, ALERT has to be installed and configured easily by administrators (who might be leaders as well in many projects). This scenario describes how to install and configure ALERT, how to integrate it with external software (BTS, wiki, etc.) and how to customize it for the community. |
| Problems and Challenges | Integration with external software can be difficult. The process should be made as simple as possible.
Documentation must be good, and describe the whole process. |
| Business Trigger | Want to trial ALERT |
| Preconditions | ALERT is not installed yet.
Installation prerequisites are satisfied. |
| Postconditions | ALERT is ready to use.
Configure the system to retrieve information from one third party software. |
