Difference between revisions of "Bug Resolution Case Study"

From Scube-casestudies
Jump to: navigation, search
Line 102: Line 102:
 
! 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%;"
 +
|+ Table BG4. Business Goal BUG-BG4<br>
 +
|-
 +
! Field
 +
! Description
 +
|- style="background:#f0f0f0; color:black"
 +
! UniqueID
 +
| BUG-BG4
 +
|- style="background:white; color:black"
 +
! Short Name
 +
| Accelerate issue attribution
 +
|- style="background:white; color:black"
 +
! Type
 +
| Business Goals.
 +
|- style="background:white; color:black"
 +
! 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.
 +
|- style="background:white; color:black"
 +
! 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.
 +
|- style="background:white; color:black"
 +
! Involved Stakeholders
 +
| Developer, Leader
 +
|- style="background:white; color:black"
 +
! Conflicts
 +
| None
 +
|- style="background:white; color:black"
 +
! Priority of accomplishment
 +
| Must have.
 +
|}
 +
 +
 +
{| 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.
 
|}
 
|}
  
Line 348: Line 415:
 
|- style="background:white; color:black"
 
|- style="background:white; color:black"
 
! Postconditions
 
! Postconditions
−
| The actor found the information he/she was looking for (any kind of information) from subsystems (wiki, forum, BTS...).
+
| The developer is notified of all relevant information about the issue he/she works on.
−
In case that the list of search results is empty: New result page is shown with the same result or more.
+
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.
−
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 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 sho
 +
|- style="background:white; color:black"
 +
! Postconditions
 +
| The new developer is familiarized with the project code history.
 
|}
 
|}

Revision as of 12:21, 22 September 2011

Description

Case study Description

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 sho
Postconditions The new developer is familiarized with the project code history.
Retrieved from "https://scube-casestudies.deib.polimi.it/index.php?title=Bug_Resolution_Case_Study&oldid=134718"