Development of a Defect Tracking System (DTS)
Abstract of the project
This project is aimed at developing an online defect tracking system useful for applications developed in an organization. The Defect Tracking System (DTS) is a web based application that can be accessed throughout the organization. This system can be used for logging defects against an application/module, assigning defects to individuals and tracking the defects to resolution. There are features like email notifications, user maintenance, user access control, report generators etc in this system.
Generic Technology keywords
Databases, Programming, Network and Middleware
Specific Technology keywords
HTML, Active Server Pages, VB, MS SQL Server
Unix Shell, Java, SQL
Project type keywords
Analysis, Design, Implementation, User Interface.
Functional components of the project
Following is a list of functionalities of the system. More functionalities that you find appropriate can be added to this list. And, in places where the description of a functionality is not adequate, you can make appropriate assumptions and proceed.
Following three tasks can be performed with the application :
(a) User Maintenance: Creating, Granting & Revoking access and Deleting users from application.
(b) Component Maintenance : Creating a component (application being developed
/ enhanced), Granting & Revoking access on components to Users and Marking a component as Active or Closed.
(b) Defect Tracking : Creating, Assigning defects to users, Modifying and Closing a defect. A defect screen should at least have following details
Â¢ Defect Number and Title
Â¢ Defect priority
Â¢ Date created
Â¢ Defect description
Â¢ Defect diagnosis
Â¢ Name of originator
Â¢ Name of Assignee
© Find User: A search screen to find users and display results.
(d) Find component: A search screen to find components and display results.
(e) Find defect : A search screen to find defects and display results.
(f) Report: Generate reports on defects.
Accordingly there would be following levels of user privileges :
Â¢ Application admin having all privileges.
Â¢ Component admin having privileges (b),(d),(e),(f) for the components they own.
Â¢ Users having privileges for (b),(d),(e),(f) for components they have access to.
Â¢ All should have privileges for ©.
1. A user should be able to
Â¢ Login to the system through the first page of the application.
Â¢ Change the password after logging into system.
Â¢ View the defects assigned to the User.
Â¢ Find defects for components on which the user has access.
Â¢ Find components on which the user has access.
Â¢ Modify the defects by changing / putting values in fields.
Â¢ Assign defects to other users having access to the component.
Â¢ Find details of other Users.
Â¢ Generate reports of defects for components on which the user has access.
2. As soon as a defect is assigned to a user a mail should be send to the User.
3. A Component Admin should be able to do the following tasks in addition to 1:
Â¢ Add an User to the component for creating and modifying defects against that component.
Â¢ Remove a user from the component.
Â¢ Mark a component as Active / Closed. No new defects can be created against a Closed component. A component cannot be closed until all defects against the component are also closed.
4. The Application Admin should be able to do the following tasks in addition to 1 & 3:
Â¢ Add a new component.
Â¢ Add an user to a component as Component Admin.
Â¢ Remove Component Admin privilege from a user.
Â¢ Add a new user.
Â¢ Remove a user.
Steps to start-off the project
There are couple of alternatives to implement such a system.
A. Microsoft platform: The system is developed using Active Server Pages as the
front end and SQL Server as the back end.
Servelet programming in Java, any relational database (eg Postgress / Oracle /
My SQL), and tools in Unix
The following steps will be helpful to start off the project.
1. Study and be comfortable with technologies such as
Active Server Pages/HTML and SQL server.
Unix commands, Shell programming, Java Programming, SQL.
Some links to these technologies are given in the ËœGuidelines and Referencesâ„¢
section of this document.
2. Create a user database with different access levels.
3. Assign a mail-admin who will create mail-ids for the people in the intranet of your lab
or in the internet. These mail-ids will be used for sending automatic notifications and
reports. The mail-admin will also take care of assigning the logins to the users of the
4. Create the front-page of the application giving a brief description and a login box.
5. Create the help-pages of the application in the form of Q&A. This will help you also
when implementing the application.
Number Description Alternatives (If available)
1 PC with 2 GB hard-disk and 256 MB RAM Not Applicable
Number Description Alternatives (If available)
1 Windows 95/98/XP with MS-office Not Applicable
2. MS-SQL server MS-Access
3. Linux Not Applicable
4. Oracle PG SQL / My SQL
3 to 4 students can complete this in 6 months if they work fulltime on it.
Milestones and Timelines
Number Milestone Name Milestone Description
(From Week â€œ To week) Remarks
1 Requirements Specification Complete specification of the system (with appropriate assumptions) constitutes this milestone. A document detailing the same should be written and a presentation on that be made. 2-3 Attempt should be made to add some more relevant functionalities other than those that are listed in this document.
2 Technology familiarization Understanding of the technology needed to implement the project. 4-5 The presentation should be from the point of view of being able to apply it to the project, rather than from a theoretical perspective.
3 Database creation A database of atleast 100 entries of users with all roles should be created. The number of mail-ids to be created need not be 100. It can be around 10 to 20. 5-7 It is important to finalize on the database at this stage itself so that development and testing can proceed with the actual database itself.
4 High-level and Detailed Design Listing down all possible scenarios and then coming up with flow-charts or pseudocode to handle the scenario. 7-11 The scenarios should map to the requirement specification (ie, for each requirement that is specified, a corresponding scenario should be there).
5 Development for web front end functionalities. Implementation of the main screen giving the login, screen that follows the login giving various options, screens for each of the options 12-18 During this milestone period, it would be a good idea for the team (or one person from the team) to start working on a test-plan for the entire system. This test-plan can be updated as and when new scenarios come to mind.
6 Integrating the front-end with the database The front-end developed in the earlier milestone will now be able to update the defects database. Other features like mail notification etc should be functional at this stage. In short, the system should be ready for integration testing. 19-20
7 Integration Testing The system should be thoroughly tested by running all the testcases written for the system (from milestone 5). 20-24 Another 2 weeks should be there to handle any issues found during testing of the system. After that, the final demo can be arranged.
8 Final Review Issues found during the previous milestone are fixed and the system is ready for the final review. 24-26 During the final review of the project, it should be checked that all the requirements specified during milestone number 1 are fulfilled (or appropriate reasons given for not fulfilling the same)
Guidelines and References
http://msdn.microsoft.com/library/defaul...torial.asp (ASP tutorial)
http://www.functionx.com/sqlserver/ (SQL-server tutorial)
http://heather.cs.ucdavis.edu/~matloff/U...ellII.html (Shell script introduction)
http://technet.oracle.com (For Oracle)
http://www.mysql.com (For MySQL)
http://java.sun.com/docs/books/tutorial (Java Tutorial)