Difference between revisions of "Bug Resolution Case Study"

From Scube-casestudies
Jump to: navigation, search
 
(5 intermediate revisions by the same user not shown)
Line 1: Line 1:
 
==Description==
 
==Description==
  
−
Case study 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 and Domain Assumptions==
Line 39: Line 39:
 
| Should have.
 
| Should have.
 
|}
 
|}
 +
  
 
{| cellspacing="0" cellpadding="5" border="1" align="center" style="background:#cccc99;color:black;width:80%;"
 
{| cellspacing="0" cellpadding="5" border="1" align="center" style="background:#cccc99;color:black;width:80%;"
Line 50: Line 51:
 
|- style="background:white; color:black"
 
|- style="background:white; color:black"
 
! Short Name  
 
! Short Name  
−
| Enable efficient issues resolution
+
| Enable efficient issue resolution
 
|- style="background:white; color:black"
 
|- style="background:white; color:black"
 
! Type  
 
! Type  
Line 56: Line 57:
 
|- style="background:white; color:black"
 
|- style="background:white; color:black"
 
! Description  
 
! Description  
−
| As much as possible relevant information should be provided in order to resolve an issue.
+
| As much as possible relevant information should be providedd in order to resolve an issue
 
|- style="background:white; color:black"
 
|- style="background:white; color:black"
 
! Rationale  
 
! Rationale  
Line 65: Line 66:
 
|- style="background:white; color:black"
 
|- style="background:white; color:black"
 
! Conflicts
 
! Conflicts
−
| None.
+
| None
 
|- style="background:white; color:black"
 
|- style="background:white; color:black"
 
! Priority of accomplishment  
 
! Priority of accomplishment  
 
| Must have.
 
| Must have.
 
|}
 
|}
 +
  
 
{| cellspacing="0" cellpadding="5" border="1" align="center" style="background:#cccc99;color:black;width:80%;"
 
{| cellspacing="0" cellpadding="5" border="1" align="center" style="background:#cccc99;color:black;width:80%;"
Line 87: Line 89:
 
|- style="background:white; color:black"
 
|- style="background:white; color:black"
 
! Description  
 
! Description  
−
| Developers get a lot of information by emails, and it begins difficult to select which one is relevant. ALERT should send only relevant information to developer. The notifications can be customized with custom rules, or be integrated in standard ALERT process.
+
| 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.
 
|- style="background:white; color:black"
 
|- style="background:white; color:black"
 
! Rationale  
 
! Rationale  
−
| Developers get too many emails and would save time and do not miss important information, if they get relevant notifications.
+
| Developers gets too many emails and would save time and do not miss important information if they did get relevant notifications.
 
|- style="background:white; color:black"
 
|- style="background:white; color:black"
 
! Involved Stakeholders  
 
! Involved Stakeholders  
Line 101: Line 103:
 
| Must have.
 
| Must have.
 
|}
 
|}
 +
  
 
{| cellspacing="0" cellpadding="5" border="1" align="center" style="background:#cccc99;color:black;width:80%;"
 
{| cellspacing="0" cellpadding="5" border="1" align="center" style="background:#cccc99;color:black;width:80%;"
Line 112: Line 115:
 
|- style="background:white; color:black"
 
|- style="background:white; color:black"
 
! Short Name  
 
! Short Name  
−
| Accelerate issue distribution
+
| Accelerate issue attribution
 
|- style="background:white; color:black"
 
|- style="background:white; color:black"
 
! Type  
 
! Type  
Line 118: Line 121:
 
|- style="background:white; color:black"
 
|- style="background:white; color:black"
 
! Description  
 
! Description  
−
| A new issue has been entered in the system and a developer and/or leader should be informed about the issue as soon as possible.
+
| 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 includes the situation that the sequence of interactions with the different information sources should be considered as a whole.
−
It considers that the issue duplicates for this issue are resolved, i.e. this issue should not be considered as a duplicate issue.
+
It considers that the duplicates for this issue are resolved, i.e. this issue should not be considered as a duplicate issue.
 
|- style="background:white; color:black"
 
|- style="background:white; color:black"
 
! Rationale  
 
! 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).
 
| 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 overloaded.
+
This approach decreases the information overload.
 
|- style="background:white; color:black"
 
|- style="background:white; color:black"
 
! Involved Stakeholders  
 
! Involved Stakeholders  
Line 136: Line 139:
 
|}
 
|}
  
−
== Domain Analysis ==
 
  
−
=== Strategic Dependency Model and Context Diagram ===
+
{| cellspacing="0" cellpadding="5" border="1" align="center" style="background:#cccc99;color:black;width:80%;"
 +
|+ Table BG5. Business Goal BUG-BG5<br>
 +
|-
 +
! Field
 +
! Description
 +
|- style="background:#f0f0f0; color:black"
 +
! UniqueID
 +
| BUG-BG5
 +
|- style="background:white; color:black"
 +
! Short Name
 +
| Help to monitor the community
 +
|- style="background:white; color:black"
 +
! Type
 +
| Business Goals.
 +
|- style="background:white; color:black"
 +
! 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.
 +
|- style="background:white; color:black"
 +
! 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.
 +
|- style="background:white; color:black"
 +
! Involved Stakeholders
 +
| Developer, Leader
 +
|- style="background:white; color:black"
 +
! 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.
 +
|- style="background:white; color:black"
 +
! Priority of accomplishment
 +
| Should have.
 +
|}
  
−
=== Domain Model===
 
  
 
== Scenarios==
 
== Scenarios==
−
The scenarios
+
The following figure shows the general use-case diagram for the Bug Resolution case study.
 +
 
 +
 
 +
[[File:ALERT.JPG]]
 +
 
 +
 
 +
{| cellspacing="0" cellpadding="5" border="1" align="center" style="background:#cccc99;color:black;width:80%;"
 +
|+ Table S1: Scenario S1.1
 +
|-
 +
! Field
 +
! Description
 +
|- style="background:#f0f0f0; color:black"
 +
! UniqueID
 +
| S1.1
 +
|- style="background:white; color:black"
 +
! Short Name
 +
| Detect possible duplicate issues at creation
 +
|- style="background:white; color:black"
 +
! Brief Description
 +
| The Customer (or developer) enters and describes an issue
 +
|- style="background:white; color:black"
 +
! Related To
 +
| BUG-BG1
 +
|- style="background:white; color:black"
 +
! Involved Actors
 +
| Customer
 +
|- style="background:white; color:black"
 +
! 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.
 +
|- style="background:white; color:black"
 +
! Problems and Challenges
 +
| Notify the customer on time, so he/she can validate it's duplicate.
 +
Good quality detection.
 +
|- style="background:white; color:black"
 +
! Business Trigger
 +
| Customer encounters an issue and reports it.
 +
|- style="background:white; color:black"
 +
! Preconditions
 +
| An issue tracking system is installed and ALERT is configure to retrieve information from it.
 +
|- style="background:white; color:black"
 +
! 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.
 +
|}
 +
 
 +
 
 +
{| cellspacing="0" cellpadding="5" border="1" align="center" style="background:#cccc99;color:black;width:80%;"
 +
|+ Table S2: Scenario S1.2
 +
|-
 +
! Field
 +
! Description
 +
|- style="background:#f0f0f0; color:black"
 +
! UniqueID
 +
| S1.2
 +
|- style="background:white; color:black"
 +
! Short Name
 +
| Spot a duplicated issue for merging.
 +
|- style="background:white; color:black"
 +
! Brief Description
 +
| The Gatekeeper spots a duplicated issue and merge it.
 +
|- style="background:white; color:black"
 +
! Related To
 +
| BUG-BG1
 +
|- style="background:white; color:black"
 +
! Involved Actors
 +
| Gatekeeper, Developer, Customer
 +
|- style="background:white; color:black"
 +
! Detailed Operational Description
 +
|The gatekeeper is suggested potential duplicates in order to merge them or take an action on them.
 +
|- style="background:white; color:black"
 +
! Problems and Challenges
 +
| Duplicates detection is very complex. If not efficient enough, it will be useless.
 +
|- style="background:white; color:black"
 +
! Business Trigger
 +
| A newly created issue was identified as possible duplicate.
 +
|- style="background:white; color:black"
 +
! Preconditions
 +
| ALERT is installed. A new issue has just been created, but not reviewed yet.
 +
|- style="background:white; color:black"
 +
! Postconditions
 +
| Suggestion is remembered as good by the system. The gatekeeper is ready to merge the issue.
 +
|}
 +
 
 +
 
 +
{| cellspacing="0" cellpadding="5" border="1" align="center" style="background:#cccc99;color:black;width:80%;"
 +
|+ Table S3: Scenario S2.1
 +
|-
 +
! Field
 +
! Description
 +
|- style="background:#f0f0f0; color:black"
 +
! UniqueID
 +
| S2.1
 +
|- style="background:white; color:black"
 +
! Short Name
 +
| Show issues relevant to my code
 +
|- style="background:white; color:black"
 +
! Brief Description
 +
| Present the developer all information relevant to his/her code.
 +
|- style="background:white; color:black"
 +
! Related To
 +
| BUG-BG2
 +
|- style="background:white; color:black"
 +
! Involved Actors
 +
| Developer
 +
|- style="background:white; color:black"
 +
! 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.
 +
|- style="background:white; color:black"
 +
! Problems and Challenges
 +
| The code must be annotated properly.
 +
The extracted knowledge must be annotated properly.
 +
|- style="background:white; color:black"
 +
! Business Trigger
 +
| None
 +
|- style="background:white; color:black"
 +
! Preconditions
 +
| System installed. Knowledge is extracted from available information sources.
 +
|- style="background:white; color:black"
 +
! Postconditions
 +
| The developer found all the issues related to the work he did in the past, or he is doing now (similar issues).
 +
|}
 +
 
 +
 
 +
{| cellspacing="0" cellpadding="5" border="1" align="center" style="background:#cccc99;color:black;width:80%;"
 +
|+ Table S4: Scenario S2.2
 +
|-
 +
! Field
 +
! Description
 +
|- style="background:#f0f0f0; color:black"
 +
! UniqueID
 +
| S2.2
 +
|- style="background:white; color:black"
 +
! Short Name
 +
| Display extended issue view
 +
|- style="background:white; color:black"
 +
! Brief Description
 +
| Add more information about an issue on the BTS.
 +
|- style="background:white; color:black"
 +
! Related To
 +
| BUG-BG2
 +
|- style="background:white; color:black"
 +
! Involved Actors
 +
| Gatekeeper, Developer, Leader
 +
|- style="background:white; color:black"
 +
! 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.
 +
|- style="background:white; color:black"
 +
! 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.
 +
|- style="background:white; color:black"
 +
! Business Trigger
 +
| An actor (except customer) is viewing the issue.
 +
|- style="background:white; color:black"
 +
! Preconditions
 +
| ALERT installed. An issue is entered.
 +
|- style="background:white; color:black"
 +
! 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
 +
|}
 +
 
 +
 
 +
{| cellspacing="0" cellpadding="5" border="1" align="center" style="background:#cccc99;color:black;width:80%;"
 +
|+ Table S5: Scenario S2.3
 +
|-
 +
! Field
 +
! Description
 +
|- style="background:#f0f0f0; color:black"
 +
! UniqueID
 +
| S2.3
 +
|- style="background:white; color:black"
 +
! Short Name
 +
| Search the knowledge base with a keyword or topic
 +
|- style="background:white; color:black"
 +
! Brief Description
 +
| Enable searching through the knowledge based using keywords.
 +
|- style="background:white; color:black"
 +
! Related To
 +
| BUG-BG2
 +
|- style="background:white; color:black"
 +
! Involved Actors
 +
| Gatekeeper, Developer, Leader
 +
|- style="background:white; color:black"
 +
! 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.
 +
|- style="background:white; color:black"
 +
! 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.
 +
|- style="background:white; color:black"
 +
! Business Trigger
 +
| A new developer joined the organization and began working on one part of the code.
 +
|- style="background:white; color:black"
 +
! 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.
 +
|- style="background:white; color:black"
 +
! 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.
 +
|}
 +
 
 +
 
 +
{| cellspacing="0" cellpadding="5" border="1" align="center" style="background:#cccc99;color:black;width:80%;"
 +
|+ Table S6: Scenario S3.1
 +
|-
 +
! Field
 +
! Description
 +
|- style="background:#f0f0f0; color:black"
 +
! UniqueID
 +
| S3.1
 +
|- style="background:white; color:black"
 +
! Short Name
 +
| Receive notifications
 +
|- style="background:white; color:black"
 +
! Brief Description
 +
| The developer receives notifications about the situation for which he/she is subscribed.
 +
|- style="background:white; color:black"
 +
! Related To
 +
| BUG-BG3
 +
|- style="background:white; color:black"
 +
! Involved Actors
 +
| Developer
 +
|- style="background:white; color:black"
 +
! 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.
 +
|- style="background:white; color:black"
 +
! Problems and Challenges
 +
| The developer might be overloaded with emails containing different notifications which obstruct his/her efficient work.
 +
|- style="background:white; color:black"
 +
! Business Trigger
 +
| A situation which is of interest for the developer has been detected.
 +
|- style="background:white; color:black"
 +
! Preconditions
 +
| The developer is subscribed and works on solving the issue addresssed by the notification.
 +
|- style="background:white; color:black"
 +
! 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.
 +
|}
 +
 
 +
 
 +
{| cellspacing="0" cellpadding="5" border="1" align="center" style="background:#cccc99;color:black;width:80%;"
 +
|+ Table S7: Scenario S3.2
 +
|-
 +
! Field
 +
! Description
 +
|- style="background:#f0f0f0; color:black"
 +
! UniqueID
 +
| S3.2
 +
|- style="background:white; color:black"
 +
! Short Name
 +
| Register to notification
 +
|- style="background:white; color:black"
 +
! Brief Description
 +
| The custormer or developer can change his/her notifications preferences.
 +
|- style="background:white; color:black"
 +
! Related To
 +
| BUG-BG3
 +
|- style="background:white; color:black"
 +
! Involved Actors
 +
| Customer, Developer, Leader, Gatekeeper
 +
|- style="background:white; color:black"
 +
! Detailed Operational Description
 +
| Any actor can register to notification or create his/her own notification rule.
 +
|- style="background:white; color:black"
 +
! Problems and Challenges
 +
| Proposed notifications must be well chosen.
 +
Subscribing/unsubscribing must be an easy process.
 +
|- style="background:white; color:black"
 +
! Business Trigger
 +
| An actor wants to receive a notification or wants to receive fewer notifications.
 +
|- style="background:white; color:black"
 +
! Preconditions
 +
| ALERT installed.
 +
|- style="background:white; color:black"
 +
! Postconditions
 +
| Developer sees notification rules and is subscribed to them.
 +
Customer or developer unsubsctibe a notification: Actor is logged.
 +
Leader changes default project notifications.
 +
|}
 +
 
 +
 
 +
{| cellspacing="0" cellpadding="5" border="1" align="center" style="background:#cccc99;color:black;width:80%;"
 +
|+ Table S8: Scenario S3.3
 +
|-
 +
! Field
 +
! Description
 +
|- style="background:#f0f0f0; color:black"
 +
! UniqueID
 +
| S3.3
 +
|- style="background:white; color:black"
 +
! Short Name
 +
| Create a new notification rule
 +
|- style="background:white; color:black"
 +
! Brief Description
 +
| Design a new notification rule
 +
|- style="background:white; color:black"
 +
! Related To
 +
| BUG-BG3
 +
|- style="background:white; color:black"
 +
! Involved Actors
 +
| Gatekeeper, Developer, Leader
 +
|- style="background:white; color:black"
 +
! 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.
 +
|- style="background:white; color:black"
 +
! Problems and Challenges
 +
| Interaction patterns depend on the domain ontology.
 +
The complexity of the rules can exceed the expressiveness of the pattern language.
 +
|- style="background:white; color:black"
 +
! Business Trigger
 +
| None
 +
|- style="background:white; color:black"
 +
! Preconditions
 +
| System installed. Data related to ontologies are entered.
 +
|- style="background:white; color:black"
 +
! 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.
 +
|}
 +
 
 +
 
 +
{| cellspacing="0" cellpadding="5" border="1" align="center" style="background:#cccc99;color:black;width:80%;"
 +
|+ Table S9: Scenario S4.1
 +
|-
 +
! Field
 +
! Description
 +
|- style="background:#f0f0f0; color:black"
 +
! UniqueID
 +
| S4.1
 +
|- style="background:white; color:black"
 +
! Short Name
 +
| Get a suggested issue to assign to myself
 +
|- style="background:white; color:black"
 +
! Brief Description
 +
| Inform the developer about an issue he/she might be interested in.
 +
|- style="background:white; color:black"
 +
! Related To
 +
| BUG-BG4
 +
|- style="background:white; color:black"
 +
! Involved Actors
 +
| Developer
 +
|- style="background:white; color:black"
 +
! 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.
 +
|- style="background:white; color:black"
 +
! Problems and Challenges
 +
| IReal-time data processing.
 +
Inform the developer proactively.
 +
|- style="background:white; color:black"
 +
! Business Trigger
 +
| A developer is entering the system.
 +
|- style="background:white; color:black"
 +
! Preconditions
 +
| System installed. Issues are entered.
 +
Every event related to the user expertise is a relevant notification rule.
 +
|- style="background:white; color:black"
 +
! 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.
 +
|}
 +
 
 +
 
 +
{| cellspacing="0" cellpadding="5" border="1" align="center" style="background:#cccc99;color:black;width:80%;"
 +
|+ Table S10: Scenario S4.2
 +
|-
 +
! Field
 +
! Description
 +
|- style="background:#f0f0f0; color:black"
 +
! UniqueID
 +
| S4.2
 +
|- style="background:white; color:black"
 +
! Short Name
 +
| Get suggested developers to assign them an issue
 +
|- style="background:white; color:black"
 +
! Brief Description
 +
| Leader is searching for a developer who should resolve an issue.
 +
|- style="background:white; color:black"
 +
! Related To
 +
| BUG-BG4
 +
|- style="background:white; color:black"
 +
! Involved Actors
 +
| Leader
 +
|- style="background:white; color:black"
 +
! Detailed Operational Description
 +
| Leader is searching for the issues to be resolved and the system assigns relevant developers for selected issues.
 +
|- style="background:white; color:black"
 +
! Problems and Challenges
 +
| The developers profiles should be available.
 +
|- style="background:white; color:black"
 +
! Business Trigger
 +
| Some notifications are coming from the system to the leader. Otherwise, he/she just starts searching for issues.
 +
|- style="background:white; color:black"
 +
! Preconditions
 +
| System installed. Issues are entered.
 +
The leader has defined relevant notification rules.
 +
|- style="background:white; color:black"
 +
! 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.
 +
|}
 +
 
 +
 
 +
{| cellspacing="0" cellpadding="5" border="1" align="center" style="background:#cccc99;color:black;width:80%;"
 +
|+ Table S11: Scenario S5.1
 +
|-
 +
! Field
 +
! Description
 +
|- style="background:#f0f0f0; color:black"
 +
! UniqueID
 +
| S5.1
 +
|- style="background:white; color:black"
 +
! Short Name
 +
| Read the history of a project's code
 +
|- style="background:white; color:black"
 +
! Brief Description
 +
| Reading the project code history.
 +
|- style="background:white; color:black"
 +
! Related To
 +
| BUG-BG5
 +
|- style="background:white; color:black"
 +
! Involved Actors
 +
| Developer
 +
|- style="background:white; color:black"
 +
! Detailed Operational Description
 +
| A new developer familiarizes with the code, means of coding and issue history by reading the project code history.
 +
|- style="background:white; color:black"
 +
! Problems and Challenges
 +
| None
 +
|- style="background:white; color:black"
 +
! 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.
 +
|- style="background:white; color:black"
 +
! Preconditions
 +
| The developer has access to the ALERT system, authorized access to his/her profile and access to basic options.
 +
|- style="background:white; color:black"
 +
! Postconditions
 +
| The new developer is familiarized with the project code history.
 +
|}
 +
 
 +
 
 +
{| cellspacing="0" cellpadding="5" border="1" align="center" style="background:#cccc99;color:black;width:80%;"
 +
|+ Table S12: Scenario S5.2
 +
|-
 +
! Field
 +
! Description
 +
|- style="background:#f0f0f0; color:black"
 +
! UniqueID
 +
| S5.2
 +
|- style="background:white; color:black"
 +
! Short Name
 +
| Suggest a project to work on to new developers
 +
|- style="background:white; color:black"
 +
! Brief Description
 +
| The system suggests a project to work on to the developer.
 +
|- style="background:white; color:black"
 +
! Related To
 +
| BUG-BG5
 +
|- style="background:white; color:black"
 +
! Involved Actors
 +
| Developer
 +
|- style="background:white; color:black"
 +
! 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.
 +
|- style="background:white; color:black"
 +
! Problems and Challenges
 +
| Inadequate data in the developer public profile that were not validated by the leader.
 +
|- style="background:white; color:black"
 +
! Business Trigger
 +
| The developer is ready to operate, but has no assigned project.
 +
|- style="background:white; color:black"
 +
! 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.
 +
|- style="background:white; color:black"
 +
! Postconditions
 +
| The developer is assigned to the project for which he/she is responsible and which match his/her expertise.
 +
|}
 +
 
 +
 
 +
{| cellspacing="0" cellpadding="5" border="1" align="center" style="background:#cccc99;color:black;width:80%;"
 +
|+ Table S13: Scenario S5.3
 +
|-
 +
! Field
 +
! Description
 +
|- style="background:#f0f0f0; color:black"
 +
! UniqueID
 +
| S5.3
 +
|- style="background:white; color:black"
 +
! Short Name
 +
| Create and customize public profile.
 +
|- style="background:white; color:black"
 +
! Brief Description
 +
| The developer customizes his/her public profile.
 +
|- style="background:white; color:black"
 +
! Related To
 +
| BUG-BG5
 +
|- style="background:white; color:black"
 +
! Involved Actors
 +
| Developer
 +
|- style="background:white; color:black"
 +
! 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.
 +
|- style="background:white; color:black"
 +
! Problems and Challenges
 +
| The profile is taken by other developers.
 +
Entered data is incomplete.
 +
|- style="background:white; color:black"
 +
! Business Trigger
 +
| A new developer joined the project and was delegated to customize his/her public profile.
 +
|- style="background:white; color:black"
 +
! 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.
 +
|- style="background:white; color:black"
 +
! 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.
 +
|}
  
  
 
{| cellspacing="0" cellpadding="5" border="1" align="center" style="background:#cccc99;color:black;width:80%;"
 
{| cellspacing="0" cellpadding="5" border="1" align="center" style="background:#cccc99;color:black;width:80%;"
−
|+ Table S1: Scenario ID
+
|+ Table S14: Scenario S5.4
 
|-
 
|-
 
! Field  
 
! Field  
Line 153: Line 709:
 
|- style="background:#f0f0f0; color:black"
 
|- style="background:#f0f0f0; color:black"
 
! UniqueID  
 
! UniqueID  
−
| ID
+
| S5.4
 
|- style="background:white; color:black"
 
|- style="background:white; color:black"
 
! Short Name  
 
! Short Name  
−
| <br>
+
| Show ongoing project status
 +
|- style="background:white; color:black"
 +
! Brief Description
 +
| The leader wants to know what is the current status of the project, especially what are "hot" topics.
 
|- style="background:white; color:black"
 
|- style="background:white; color:black"
 
! Related To  
 
! Related To  
−
| <br>
+
| BUG-BG5
 +
|- style="background:white; color:black"
 +
! Involved Actors
 +
| Leader
 +
|- style="background:white; color:black"
 +
! 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...).
 +
|- style="background:white; color:black"
 +
! Problems and Challenges
 +
| Visualization can take more time to be presented (complex statistical calculations).
 +
Entered data is incomplete.
 +
|- style="background:white; color:black"
 +
! Business Trigger
 +
| None
 +
|- style="background:white; color:black"
 +
! Preconditions
 +
| System installed. Metadata available.
 +
|- style="background:white; color:black"
 +
! Postconditions
 +
| Leader has a real-time overview of the project.
 +
|}
 +
 
 +
 
 +
{| cellspacing="0" cellpadding="5" border="1" align="center" style="background:#cccc99;color:black;width:80%;"
 +
|+ Table S15: Scenario S6.1
 +
|-
 +
! Field
 +
! Description
 +
|- style="background:#f0f0f0; color:black"
 +
! UniqueID
 +
| S6.1
 +
|- style="background:white; color:black"
 +
! Short Name
 +
| Install ALERT system
 +
|- style="background:white; color:black"
 +
! Brief Description
 +
| Make it easy for the administrator to install and configure ALERT.
 +
|- style="background:white; color:black"
 +
! Related To
 +
| None
 +
|- style="background:white; color:black"
 +
! Involved Actors
 +
| Administrator
 +
|- style="background:white; color:black"
 +
! 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.
 
|- style="background:white; color:black"
 
|- style="background:white; color:black"
−
! Involved Actors
+
! Problems and Challenges
−
| <br>
+
| 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.
 
|- style="background:white; color:black"
 
|- style="background:white; color:black"
−
! Detailed Operational Description
+
! Business Trigger
−
| <br>
+
| Want to trial ALERT
 
|- style="background:white; color:black"
 
|- style="background:white; color:black"
−
! Problems and Challenges
+
! Preconditions
−
|<br>
+
| ALERT is not installed yet.
−
<br>
+
Installation prerequisites are satisfied.
 
|- style="background:white; color:black"
 
|- style="background:white; color:black"
−
! Additional Material
+
! Postconditions
−
| <br>
+
| ALERT is ready to use.
 +
Configure the system to retrieve information from one third party software.
 
|}
 
|}

Latest revision as of 13:02, 22 September 2011

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

Table BG1. Business Goal BUG-BG1
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.


Table BG2. Business Goal BUG-BG2
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.


Table BG3. Business Goal BUG-BG3
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.


Table BG4. Business Goal BUG-BG4
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.


Table BG5. Business Goal BUG-BG5
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.


ALERT.JPG


Table S1: Scenario S1.1
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.


Table S2: Scenario S1.2
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.


Table S3: Scenario S2.1
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).


Table S4: Scenario S2.2
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


Table S5: Scenario S2.3
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.


Table S6: Scenario S3.1
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.


Table S7: Scenario S3.2
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.


Table S8: Scenario S3.3
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.


Table S9: Scenario S4.1
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.


Table S10: Scenario S4.2
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.


Table S11: Scenario S5.1
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.


Table S12: Scenario S5.2
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.


Table S13: Scenario S5.3
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.


Table S14: Scenario S5.4
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.


Table S15: Scenario S6.1
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.

Retrieved from "https://scube-casestudies.deib.polimi.it/index.php?title=Bug_Resolution_Case_Study&oldid=134719"