Design and Implementation of a Bug Tracking System for Student Groups

David Lannoye Department of Computer Science University of North Dakota Grand Forks, North Dakota 58202 dlannoye@cs.und.edu

Abstract
With the strong focus that undergraduate computer science programs are now placing on software engineering there is still one area where students are not exposed to the technology that our colleges in the commercial sector have been embracing for some time. That area is the implementation and use of bug tracking systems. This paper will discuss the design goals and development of a bug tracking system that is targeted for use by student groups to aid them in managing the development of software projects by minimizing the hassle of tracking bugs in the various versions of the software. The final system itself allows groups to collect and store various computer anomalies, errors, and problems from the project that they are working on and to be able to effectively document and communicate these bugs to the members of their group in a real-time system. The paper will examine design choices that were made to create such a system that provides powerful bug tracking abilities to students, while still serving as a gentle introduction to these systems as they are used in commercial software development. We will also examine the ideal audience for this type of system and talk about its ability to scale to larger groups as the number of communication paths between group members grows. Finally this paper will examine the benefits of exposing students to this type of software system during their time in school.

1. Introduction
Undergraduate computer science classes often emphasize group project work to introduce students to the working environment of the average computer science graduate. In this group work many students try to use technology similar to that of the current industry standard, e.g. UML modelers, integrated development environments, and revision control. However, one area that many student groups ignore is the use of bug tracking systems or bug databases. In industry these play an important role by allowing developers to keep a centralized repository of all the known and fixed bugs in their software. Bug tracking systems are a tool used by software developers to enhance the quality of their software products. The automation that bug tracking systems provide allows for efficient monitoring and controlling of reported bugs. Generally bug tracking systems allow developers and testers to add bugs to a database, provide details about the bugs in the database and make updates to the bugs as progress is made. Along with these features there also features that allow bugs to be assigned to specific developers. This allows for allows for developers to use the bug tracking system as a to do list when the development cycle enters a maintenance stage. Finally bug tracking systems allow for the bugs that are entered into them to be prioritized making critical bugs easier to find in the database.

1.1.

Problem Description

As it has been noted that many student groups do not use bug tracking systems, so we felt it would provide an interesting experiment to design and implement a bug tracking system that is targeted for use by undergrads. The bug tracking system will be designed with features that the average student project will need, but will lack some of the more advanced features of commercial bug tracking systems. For our project we will determine which features a bug tracking system needs to offer students to be an effective system. We will then design and implement a system around these requirements.

1.2.

Significance of the Work

By providing a bug tracking system aimed at students we are giving students a chance to experiment with technology that the industry is currently using, but still have a system that serves as a gentle introduction to the use of bug tracking systems. The use of a bug tracking system provides groups with an advantage when it come to documenting the system since the bug database serves as a record of the maintenance and improvements that have been made to the software. The use of a bug tracking system also allows developer to keep track of bugs in a more organized fashion than other methods. Finally, after reviewing currently available bug tracking systems there were none available that were targeted to be used by students as an introduction to using bug tracking systems.

1.3.

Scope of the Work

The development of our bug tracking system was carried out as part of the course for a class at the University of North Dakota. Since it was developed as a semester long project our system was designed to support multiple front ends for interaction with the bug database, but for the purposes of the class only one frontend was implement. Our work included several iterative design phases followed by an implementation phase where the system was deployed to a database and a frontend was developed.

2. Benefits
There are many benefits to introducing students to bug tracking systems. Specific to students there is the benefits that exposure to this technology can bring when they enter the work force. However all developers can receive benefits offered by bug tracking systems like streamlining the bug tracking process, providing repeatable tests, and reducing development time and cost by allowing for improved coordination and communication among team members.

2.1.

Exposure

One of the most important benefits of introducing this type of knowledge management technology is the exposure that it gives to undergrads. By giving them this exposure before they first enter the workforce they will be familiar with bug tracking systems. This will be an advantage as when they start new projects there are many other things that they will likely need to be brought up to speed on such as coding standards, libraries, and development environments. Eliminating the need to learn how to use a bug tracking system will allow them to become productive members of the team in a shorter time span.

2.2.

Limited memory for details

When it comes to managing the details of a complex project like software development psychology studies have shown that on average the human mind can only keep track of seven chunks of information (1). When one thinks of the impact of this on software development it becomes clear that seven chunks of information is a limiting factor when one needs to jumble around variable names, algorithms, and bugs. Thus, the use of a bug tracking system allows developers to offload this responsibility to a centralized and searchable repository of information. Allowing them to forget about bugs, but yet still have documentation of their existence and come back to work on them at a later date.

2.3.

Repeatability

When bugs are accurately described in the bug tracking system it allows developers to view all of the steps necessary to reproduce the bug. Having these steps documented allows the developer to create a test case for the bug and use tools such as a debugger to start diagnosing the problem. Had the steps not been documented properly parts might be forgotten making the bug non-

reproducible, thus causing it to go unfixed. Documenting test cases also allows developers to notice common steps between bugs, potentially alerting them to problems at higher levels in the software architecture.

2.4.

Group Management

When it comes to group management bug tracking systems also offer some obvious benefits. As we know in any group project as the number of group members increases so do the number of possible communication paths between them. Having a bug tracking system helps to create a centralized place for all bug information to be stored, thus simplifying the communication process as it is related to bugs. And since all information is centralized when a tester or developer finds a new bug they can check the database to see if anyone else has reported it, allowing them to eliminate duplication of efforts that might occur if two developers found the same bug and independently set about fixing it. Also since the bug database assigns the ownership of the bug to one person it lays out responsibilities for that person to decide whether the bug needs to be fixed or not. Finally since the bug tracking system documents who owns the bug, other developers are quickly able to discover who the main contact point for that bug is.

2.5.

Potential Pitfalls

One of the main pitfalls to using bug tracking systems is that it can be hard to convert others on your project to start using the bug tracking system. And if everyone isnt using it the bug database can become incomplete quickly.

3. Design Goals
To design our bug tracking system we start by examining existing commercial bug tracking systems. Most of our design ideas came from examining Bugzilla (2) and FogBugz (3) bug tracking systems. After examining these commercial implementations we then started to iterate on our design until we established what we felt outlined the core functionality of our bug tracking system. Our major design goals are as follows

3.1.

Simplicity

The first design goal we established is what we consider to be our most important goal: The program must be simple to use. Since this program will likely be the first experience for many students with bug tracking systems it should be functionally complete, but provide limited extras allowing the user to focus on the core features of using a bug tracking system.

3.2.

Multi User

At an early stage we decide that the program had to support multiple connections to the bug database. This is implement by using a client server model with the actually bug database being hosted by a dedicated server. Each user is then allowed to connect to the database using a frontend client.

3.3.

Support for Multiple Frontends

Although for the purposes of our class we would only develop one frontend, the backend implementation of the bug database should allow for various frontends to be written. In example a frontend could be implemented as a plugin to a students integrated development environment or an exceptional handling routine in a program could automatically add bug reports when the software fails.

4. Design Details
From the previous design goals we started to form a design for an application we named Black Widow after the deadly spider. To provide the reader with more information about our design what follows is a discussion of how we defined different parts of the system.

4.1.

Bug Information

One of the major issues with bug tracking systems is deciding what information you need to capture from the user to identify bugs. The information we chose to store about bugs is as follows: bug id, project id, summary, status, severity, reported by, reported time, assigned to, target fix date, the bug description, and comments left on the bug. The bug id is a unique identification number. In most cases the summary will be what developers will associate with the bug since it provides a short title for the bug to be remembered by. Status and Severity allow developer to prioritize the fixing of bugs for example the status field can identify a bug as 'new', 'assigned', 'resolved' or 'reopened'. Then the severity field can identify how dangerous the bug is by categorizing bugs as 'low', 'moderate', 'high' or 'severe'. The reported by field documents the user/developer who first discovered the bug. The assigned to field lays out who is responsible for fixing the bug. The more detailed information about the bug, such as its behavior and the necessary steps to repeat it, is stored in the bug description. Finally the comments section allows developers to exchange ideas and possible solutions.

4.2.

User Interfaces in Black Widow

To provide the user with an interactive way to enter information about the bugs we developed the following figure (Figure 1) to show the different user interfaces and the transitions between them.

User Login

Administrator View

Bug Browsing View

Add User

Add Project

Add Bug

Detailed Bug

Remove User

Remove Project

Comment on Bug F IGURE 1

Watch A Bug

Modify Bug

4.3.

Technical Implementation Details

Working from this detailed design we decided that the best way to meet our design goals and provide the functionality described above was to use a database backend. We then identified the different data that our database would need to store and specified it using Entity-Relationship notation (See Appendix A Entity Relationship diagram and Appendix B Formal Schema). Using this we developed the SQL markup to do table creation and used a MySQL database that runs on a remote server. The frontend which the user interacts with was then constructed to provide the necessary interfaces. This is a desktop application that was developed using Microsoft Visual Studio 2005 and C#. We utilized the ODBC package to provide database connectivity between the desktop application and the server which stored the bug information. The final application runs all current versions of Microsoft Windows and requires an internet connection for communication with the database (See Figure 2 for a screen shot of the application).

F IGURE 2

5. Conclusion
In conclusion we feel that our bug tracking system fill a unique niche for a bug tracking system targeted at student groups. For future work it would be ideal to continue the development of our bug tracking system by offering different implementations of the frontend. Also we feel that a study could be done to analyze the productivity of groups working without the help of our bug tracking system and compare that to the productivity of groups working with our bug tracking system.

References
1. McConnell, Steve. Code Complete Second Edition. Redmond : Microsoft Press, 2004. 2. Bugzilla. http://www.bugzilla.org/. [Online] 3. Fog Creek Software. http://www.fogcreek.com/FogBUGZ/. [Online]

Appendix A Relationship

Entity diagram

Appendix B Formal Schema

Users
usersID INT email VARCHAR(256) firstName VARCHAR(256) lastName VARCHAR(256) password VARCHAR(256) description VARCHAR(512)

Project
projectID INT name VARCHAR(256) description VARCHAR(512) managerusersID INT

Bug
bugID INT severity ENUM('low', 'high', 'severe') projectID INT reportedByUser 'moderate', INT summary VARCHAR(256) reportedTime TIMESTAMP description VARCHAR(512) assignedToUser INT status ENUM('new','assigned', 'resolved','reopened') fixDate TIMESTAMP

CommentsOn
commentID INT usersID INT bugID INT commentTime TIMESTAMP commentText VARCHAR(512)

Watches
usersID INT bugID INT

Mods
modifyID INT usersID INT bugID INT modifiedTime TIMESTAMP description VARCHAR(512)

DevelopsOn
usersID INT projectID INT

TestsOn
usersID INT projectID INT