BUG TRACKING SYSTEM

by

RICHA KUMARI (0947710016) RIDAM SHARMA ( 0947710017)

Department of Computer Science & Engineering

Sunder Deep Group Of Institution

May 2013

BUG TRACKING SYSTEM

by RICHA KUMARI (0947710016) RIDAM SHARMA (0947710017)

Submitted to the Department of Computer Science & Engineering in partial fulfillment of the requirements for the degree of Bachelor of Technology in Computer Science & Engineering

Sunder Deep Group Of Institution Gautam Budha Technical University May 2013

CERTIFICATE

This is to certify that Project Report entitled BUG TRACKING SYSTEM which is submitted By RICHA KUMARI and RIDAM SHARMA in partial fulfillment of the requirement for the award of degree B. Tech. in Department of Computer Science & Engineering of U. P. Technical University, is a record of the candidate own work carried out by him under my/our supervision. The matter embodied in this thesis is original and has not been submitted for the award of any other degree.

Date:

Ashish Dixit (Supervisor)

DECLARATION
We hereby declare that this submission is my own work and that, to the best of my knowledge and belief, it contains no material previously published or written by another person nor material which to a substantial extent has been accepted for the award of any other degree or diploma of the university or other institute of higher learning, except where due acknowledgment has been made in the text.

Signature:

Name:

Richa kumari

Roll no : 0947710016 Date: 1 May,2013

Signature:

Name: Ridam sharma Roll no: 0947710017 Date: 1 May,2013

ACKNOWLEDGEMENT

It gives us a great sense of pleasure to present the report of the B. Tech Project undertaken during B. Tech. Final Year. We owe special debt of gratitude to Assistant Professor Ashish Dixit , Assistant Professor Shailendra pushkin , Department of Computer Science & Engineering, College of Engineering, Lucknow for his constant support and guidance throughout the course of our work. His sincerity, thoroughness and perseverance have been a constant source of inspiration for us. It is only his cognizant efforts that our endeavors have seen light of the day. We also take the opportunity to acknowledge the contribution of Assistant professor Mr Anand prakash srivastava , Head, Department of Computer Science & Engineering, College of Engineering, Lucknow for his full support and assistance during the development of the project. We also do not like to miss the opportunity to acknowledge the contribution of all faculty members of the department for their kind assistance and cooperation during the development of our project. Last but not the least, we acknowledge our friends for their contribution in the completion of the project. Signature: Name : Richa kumari

Roll No.: 0947710016 Date : 1 May,2013

Signature: Name : Ridam sharma

Roll No.: 0947710017 Date : 1 May,2013

ABSTRACT
For many years, bug-tracking mechanism is employed only in some of the large software development houses. Most of the others never bothered with bug tracking at all, and instead simply relied on shared lists and email to monitor the status of defects. This procedure is error-prone and tends to cause those bugs judged least significant by developers to be dropped or ignored. Bug Tracking System is an ideal solution to track the bugs of a product, solution or an application. Bug Tracking System allows individual or groups of developers to keep track of outstanding bugs in their product effectively. This can also be called as Defect Tracking System. The Bug Tracking System can dramatically increase the productivity and accountability of individual employees by providing a documented workflow and positive feedback for good performance. Some salient features are

1. 2. 3. 4. 5. 6. 7. 8. 9.

Product and Component based Creating & Changing Bugs at ease Query Bug List to any depth Reporting & Charting in more comprehensive way User Accounts to control the access and maintain security Simple Status & Resolutions Multi-level Priorities & Severities. Targets & Milestones for guiding the programmers Attachments & Additional Comments for more information

10. Robust

TABLE OF CONTENTS

PAGE

CHAPTER 1 INTRODUCTION1 1.1 1.2 1.3 1.4 overview.....3 Scope of investigation4 Existing system..5 Drawbacks of Existing system...5

CHAPTER 2 FEASIBILITY STUDY....7 2.1 Technical feasibility..8 2.2 Operational feasibility...8 2.3 Economic feasibility...9 CHAPTER 3 SYSTEM REQUIREMENT11 3.1 Hardware requirement specification12 3.2 Software requirement specification... .13 CHAPTER 4 SYSTEM DESIGN..18 4.1 Design objective....19 4.2 Software design. ....20 4.3 Top down and Bottom up approach...21 4.4 Module description...24 4.5 Database structure.....30 CHAPTER 5 DATA DESIGN......40 5.1 ER Diagram...41 5.2 Data Flow Diagram..43 CHAPTER 6 SCREENSHOTS,...53 CHAPTER 7 APPENDIX84 CHAPTER 8 SYSEM TESTING....87 8.1 Software testing88

CHAPTER 9 FUTURE SCOPE.91. REFERENCES..92

CHAPTER-1 INTRODUCTION

1.1 INTRODUCTION

Starting the project we should fully know about the meaning of project. There are seven letters in the word PROJECT each character has its own technical meaning. Planning :-This deal with the idea at thinking and which are required for the project. Resource :-The money problem will be solved and resources from which collected. Operating :- The procedure from which the getting job is prepared in a systematic way is known as operation. Joint effort :- This is directly proper to a operation output is made of several person working sincerely is known as JOINT EFFORT. Engineering :- A well-educated engineer can do this work in a better way to find out better result. Hence the project is as engineering function. Co-operation:- To make the project successfully, it is necessary for its success and completion of project. Technique: - It must as it gives a better shape. It is not possible to complete the project without technique. The project is a system that gives the systematic way of planning and working. OR It represents a temporary task , in a scientific manner carried out by group of engineers to achieve a goal. A bug tracking system or defect tracking system is a software application that is designed to help keep track of reported software bugs in software development efforts. It may be regarded as a type of issue tracking system. Many bug tracking systems, such as those used by most open source software projects, allow users to enter bug reports directly. Other systems are used only internally in a company or organization doing software development. Typically bug tracking systems are integrated with other software project management applications.

Having a bug tracking system is extremely valuable in software development, and they are used extensively by companies developing software products. Consistent use of a bug or issue tracking system is considered one of the "hallmarks of a good software team

1.2 Overview
This Synopsys documents the process of designing, building and testing a software system to be used for marketing BUG TRACKING SYSTEM. The piece of software, and therefore the project, is known as a BUG TRACKING SYSTEM. The project titled as a BUG TRACKING SYSTEM is a web based application. For many years, bug-tracking mechanism is employed only in some of the large software development houses. Most of the others never bothered with bug tracking at all, and instead simply relied on shared lists and email to monitor the status of defects. This procedure is errorprone and tends to cause those bugs judged least significant by developers to be dropped or ignored. Bug Tracking System is an ideal solution to track the bugs of a product, solution or an application. Bug Tracking System allows individual or groups of developers to keep track of outstanding bugs in their product effectively. This can also be called as Defect Tracking System.
The Bug Tracking System can dramatically incr

ease the productivity and accountability of individual employees by providing a documented workflow and positive feedback for good performance.

1.3

Scope of investigation

The aim of this project is to design, build and test a BUG TRACKING SYSTEM. This will be a vastly complex software development project which will take approximately 5 months to complete. The project will be split up into stages and documented thoroughly throughout. Project management is a key factor of this task to ensure the strict deadlines are adhered to. It is also of paramount importance that tried and tested practices and techniques from the field are adhered to to ensure that no common development project mistakes are reproduced.

1.4 Existing System

A bug tracking system is a software application that is designed to help quality assurance and programmers to keep track of reported software bugs in their work. Many bug tracking system , such as those used by most open source software projects,allow user to enter bug report directly. Other systems are only used internally in a company and organisation doing software development.

1.4

Drawbacks of Existing System

Designing work flows. Meaning of fields One bug many releases Trusting history

DESCRIPTION OF PROJECT
The aim of proposed system is to develop a system of improved facilities. The proposed system can overcome all the limitations of the existing system. The system provides proper security and reduces the manual work. The existing system has several disadvantages and many more difficulties to work well. The proposed system tries to eliminate or reduce these difficulties up to some extent. The proposed system will help the user to reduce the workload and mental conflict. The proposed system helps the user to work user friendly and he can easily do his jobs without time lagging. Expected Advantages of Proposed System The system is very simple in design and to implement. The system requires very low system resources and the system will work in almost all configurations. It has got following features Improved designing workflows Better meaning of fields Reduce trusting history

CHAPTER-2 FEASIBILITY STUDY

2.FEASIBILITY STUDY
The concept of feasibility is to determine whether or not a project is worth doing. The process followed in making this determination is called feasibility study. Once it has been determined that a project is feasible, the system analyst can go ahead and prepare the project specification which finalizes project requirements.

Types of feasibility
Technical Feasibility Operational Feasibility Economic Feasibility Social Feasibility Management Feasibility Legal Feasibility Time Feasibility

Here we describe only few of these in detail: 2.1 TECHNICAL FEASIBILITY This is concerned with specifying equipment and software that will successfully satisfy the user requirement. Technical needs of the system include: Facility to produce outputs in a given time Response time under certain conditions Ability to process a certain volume of transaction at a particular period Facility to communicate data to distant location

In examining technical feasibility, configuration of the system is given more importance than the actual make of hardware. Configuration should give the complete picture about the systems requirements: how many workstations are required, how these units are interconnected so that they could operate and communicate smoothly. What speeds of input and output should be achieved at particular quality of printing.

The computers are easily available in almost all the places, even in villages. The software needed to carry out this project includes java as front end and SQL2005 as backend. So the technology required to carry out the project is easily available and affordable, hence this project is technically feasible. Due to all these reasons implementation of such system becomes not only feasible but reputed to the organization. 2.2 OPERATIONAL FEASIBILITY This is mainly related to human organization and political aspects. The points to be considered are: What changes will be brought with the system? What organizational structures are disturbed? What new skills will be required? Do the existing staff members have these skills? If not, can they be trained in due course of time

This feasibility study is carried out by a small group of people who are familiar with information system techniques, who understand the parts of business that are relevant to the project and are skilled in system analysis and design process. This projects are not developed just for fun. They are developed on demand of the organization for which the system is being developed. Therefore the chances of resistance from the college staff are almost nil. Any disturbance to the organization if occurs will be advantageous to the organization. Also the time required to carry out a transaction will be reduced to a large extent, which will make the student happy and cheerful. The operators now will be able to service more students than before in the same time period. There is no need to recruit new staff to operate the system. The existing staff of the college can be trained to interact with the system which is a GUI based software and is easy to use. Hence the project is operationally feasible.

2.3 ECONOMIC FEASIBILITY

Economic analysis is the most frequently used technique for evaluating the effectiveness of a proposed system. More commonly known as cost-benefit analysis; the procedure is to determine the benefits and savings that are expected from a proposed system and compare them with costs. If benefits outweigh costs, a decision is taken to design and implement the system.

CHAPTER-3 SYSTEM REQUIREMENTS

3.1 H/W & S/W SPECIFICATION USED

Hardware Specification:

Processor RAM Hard Disk Monitor Keyboard Mouse Network

:::::::-

Intel Celeron class processor with 233 MHz 32 MB 1GB Color monitor 101 keys Any pointing device Any network supporting TCP/IP

Software Specification:
Platform (both sides) Software ::Any platform MS.NET, Oracle

3.2 SOFTWARE REQUIREMENT SPECIFICATION

An SRS is basically an organizations understanding of a customer or potential clients system requirements and dependencies at a particular point in time prior to any actual design or

development work. Its a two-way insurance policy that assures that both the client and the organization understand the others requirements from that perspectively at a given point in time.

Introduction Purpose of this Document Scope of the Development Project Definitions, Acronyms, and Abbreviations References Overview of the document General description User Persons and Characteristics Product Perspective Overview of functional requirements Overview of Data Requirements General constraints, Assumptions, Dependencies and Guidelines User view of product use Specific Requirements External interface requirements Detailed description of functional requirements Performance requirements Quality attributes Other requirements Behavioral Description System states Events and actions Validation and criteria Performance bounds Classes of tests Expected software response Special considerations The introduction states the goals and objectives of software, describing it in the context of computer based system. It may be nothing more than the software scope of the planning document. The information description provides a detailed description of the problem that the software must solve. Information content and relationships, flow and structure are documented. Hardware, software and human interfaces are described for external system elements and internal software functions.

A description of each function is required to solve the problem, is presented in the functional description. The behavioral description section of the specification examines the operation of the software as a consequence of external events and internally generated control characteristics. In validation criteria we specify, what classes of tests must be conducted to validate function, performance and constraints? Constraints identify limits placed on the software by external hardware, available memory or other existing systems Thebibliography contains references to all documents that relate to the software. These include other software engineering documentation, technical references, vendor literature, and standards. The appendix contains information that supplements the specification. Tabular data, detailed description of algorithms, charts and graphs are presented as appendices.

Secondly, this document is used to ensure that the development of

FUNCTIONAL REQUIREMENTS
Functional requirements specify which outputs should be produced from the given inputs. They describe the relationship between the input and output of the system. For each functional requirement, a detailed description of all the data inputs and their source, the units of measure, and the range of valid inputs must be specified. All the operations to be performed on the input data to obtain the output should be specified. This includes specifying the validation checks on the input and output data.

PURPOSE OF THIS DOCUMENT

The purpose of this document is to convey the requirements of the project (as specified by the client) to the programmers to ensure that the programmers understand and fulfill the requirements to the expectation of the client. Team understands the requirements specified by the client. This document will act as the contract for all future development; all development spawns from and adheres to the details in the requirements. The SRS also outlines the performance requirements that may be set and required by the client/user. References Software Engineering Fundamentals by Ali Behforooz and Frederick J. Hudson(Oxford University Press, 1996). Software Engineering, A Programming Approach by Pressman(2nd Edition, Prentice Hall, 1992). An integrated approach to Software Engineering by PankajJalote (Narosa Publishing

House, 2nd edition). URL of home page is http://www.springer-ny.com/supplements/jalote Fundamentals of Software Engineering by Carlo Ghezzi, Mehdi Jazayeri, Dino Mandrioli (Prentice Hall India).

Overview of Document
The remainder of this document describes the intended users that would be expected to interact with the system frequently, and a simple profile of each user type is provided as a sample. This document now will go into more detail on the expected users their interface and interaction with the product and more on the technical approach and considerations to be implemented.

General Description
User Persons and Characteristics The primary users of this product are the college employees, director perspective candidates. Most of them already have some experience in using computer components (mouse and keyboard), and are willing to learn and explore under the supervision of their superiors. The employees have adequate knowledge so that they can be trained easily to operate the system.

Overview of Functional Requirements

Our product will be stand alone and will have an interface, which can be accessed on more than one-computer at the same time, such as computers connected with LAN. Our main goal is to present facts on a comprehensive level, and make it easier as well.

Hardware Interface Requirements

Our product will require at least a PowerPC Macintosh or a Pentium class PC with 64 MB of RAM (64+ recommended), and color display. Other Software Components: Operating System: Window xp/vista/window7 Detail Description of Functional Requirements Template for describing functional requirements

Purpose

A description of the functional requirement and its motivations(s)

Inputs

which inputs; in what form/format will inputs arrive; from what sources input will be derived; legal domains of each input element Describes the outcome rather than the implementation; include any validity checks on the data, exact timing of each operation (if needed), how to handle unexpected or abnormal situations the form, shape, destination, and volume of the output; output timing; range of parameters in the output; unit measure of the output; process by which the output is stored or destroyed; process for handling error messages produced as output.

Processing

Outputs

Performance Requirements
The software is inherently designed to handle multiple users accessing the same database system. Multiple user sessions will concurrently exist. Each session will receive it's own thread of execution which is invisible to all other components of the system, but will provide reliability, efficiency, and excellent response time. The actual capacity of users that the system can handle is out of the scope of this document.

CHAPTER-4 SYSTEM DESIGN

4.1 DESIGN OBJECTIVES

The primary objective of design is to deliver the requirements as specified in the feasibility report. Following objectives should be kept in mind: -

PRACTICALITY
The system must be stable and can be operated by people with average intelligence.

Efficiency
This involves accuracy, timeliness and comprehensiveness of the system output.

Cost
It is desirable to aim for a system with a minimum cost subject to the conidition that it must satisfy all the requirements.

Fexibility
The system should be modifiable depending on the changing needs of the user. Such modifications should not entail extensive reconstruction or recreation of software. It should also be portable to different computer systems.

Security
This is very important aspect of the design and should cover areas of hardware relaibility, fall back procedures, physical security of data and provision for detection of fraud and abuse.

INTRODUCTION
The aim of system design, which is sometimes also refferred to as top-level design, is to identify the modules that should be in the system, the specifications of these modules, and how they interact with each other to produce the desired results. At the end of the system design all the major data structures, file formats, output formats and the major modules in the system and their specifications are needed.

4.2 SOFTWARE DESIGN

Software design is an iterative process through which requirements are translated into a blueprint for constructing the software. Characteristics that serve as a guide for the evaluation of a good design: The design must implement all of the explicit requirements contained in the analysis model, and it accommodates all of the implicit requirements desired by the customer.

The design must be a readable, understandable guide for those who generate code and for those who test and subsequently maintain the software. The design should provide a complete picture of the software, addressing the data, functional, and behavioral domains from an implementation perspective. DESIGN QUALITY CRITERIA A design should exhibit a hierarchical organization that makes intelligent use of control among the elements of software. A design should be modular i.e. the software should be logically partitioned into elements that perform specific functions and sub functions. A design should contain both data and procedural abstraction. A design should lead to modules that exhibit independent functional characteristics. A design should lead to interfaces that reduce the complexity of connections between modules and with the external environment. A design should be derived using a repeatable method that is driven by information obtained during software requirement analysis.

All these things are implemented in our project using options on the main menu screen. Each option provides a different kind of information, providing modular approach. Data is submitted to the database as server side programming, which gives abstraction to the data using middle tier concepts with fully Object-Oriented programming.

Design Concepts
A set of fundamental software design concepts has evolved: What criteria can be used to partition software into individual components? How function or data is structure detail separated from a conceptual representation of the software? Are there uniform criteria that define the technical quality of a software design?

4.3 Top-down and bottom up strategies

A system consists of components, which have the components of their own, indeed a system is a hierarchy of components. The highest level component corresponds to the total system. A top-down design approach starts with identifying the major components of the system, decomposing them into their low-level components and iterating until the desired level of detail is achieved. Top-down design methods often result in some form of stepwise refinement. Starting from an abstract design, in each step the design is refined to a more concrete level, until we reach a level where no more refinement is needed and the design can be implemented directly. A bottom-up design approach starts with designing the most basic or primitive components and proceeds to higher-level components that use these lower-level components. Bottom-up methods works with layers of abstraction. Starting from the very bottom, operations that provide a layer of abstraction are implemented. The operations of this layer are then used to implement more powerful operations and a still higher layer of abstraction, until the stage is reached where the operation supported by the layer are those desired by the system.

ABSTRACTION
The psychological notion of abstraction permits one to concentrat e on a problem at some level of generalization without regard to irrelevant low level details; use of abstraction also permits one to work with concepts and terms that are familiar in the problem environment without having to transform them to an unfamiliar structure... Procedural abstraction Data abstraction

PROCEDURAL ABSTRACTION It is a named sequence of instructions that has a specific and limited function. DATA ABSTRACTION It is a named collection of data that describes a data object.

REFINEMENT Stepwise refinement is a top-down strategy and the architecture of a program is developed by successive refining levels of procedural details In each step of refinement, one or more instructions of the given program are decomposed into more detailed instructions. This

successive decomposition or refinement of specifications terminates when all instructions are expressed in terms of an underlying computer or programming languages As tasks are refined, so the data may have to be refined, decomposed, or structured, and it is natural to refine the program and the data specifications in parallel. Every solution is always refinable depending on time period and availability of information.

MODULARITY
Modularity is the single attribute of software that allows a program to be intellectually manageable. Monolithic software cant be easily grasped by a reader. The number of control paths, span of reference, number of variables, and overall complexity would make understanding close to impossible.

STRUCTURED DESIGN
Structured design methodology views every software system as having some inputs that are converted into the desired outputs by the software system. The software is viewed as a transformation function that transforms the given inputs into the desired outputs, and the central problem of designing this transformation function. Due to this view of software, the structured design methodology is primarily function oriented and relies heavily on functional abstraction and functional decomposition. The appraoch begins with a system specification that identifies inputs and outputs and describes the functional aspects of the system. The next step is the definition of the modules and their relationship with one another in a form called a structure chart, using data dictionary and other structured tools.

Entity-relationship diagram
The E-R diagram enables a software engineer to fully specify the data objects that are input and output to/from a system, the attributes that define the properties of these objects, and the relationship between the objects. The following approach is taken: -

4.4 MODULES DESCRIPTION

1. Authenticate User

The Bug Tracking System first activates the login form. Here the user enters the User name and password and our system starts the authentication process in which the username and password are matched with the existing username and password in the database. If the password matches then it is allowed to the main page else it warns the user for Invalid User name and password. After successful authentication the system activates menus. The activity log also prepared for failures and security. 2. Products List Of Products After successful authentication the user is provided with the list existing products. Here the user can view the details of products and can modify the existing products. This project even provides the facility of adding new projects. Product Versions All the products are maintained in several versions. As it is not possible to complete the whole project in a single version Features required for the product are categorized into several version with dead lines. And the versions are completed according to their dead line dates. Here the user can add new versions to a product or can modify the existing details of version. Product Users

In order to complete the project each product is allotted with Resources or users. First all the employees with their names and qualifications are stored in the database. Each user is allotted to the product based on their rating, Qualification and designation. For each user Effective date is stored which specifies the total period a user is valid for that product.

Bug Details Bug Details In this module the user is provided with the facility for adding bugs or updating the existing bugs. As the number of bugs for a product can be very large this system is provided with efficient filtering. The user can

filter the bugs based on the priority, database, operating system and status. After the user applies filter the list of bugs are displayed from the database. Bug History Here the bug history is maintained. All the solutions given for the bug resolution by various users are stored. As the bug needs several techniques or methods for resolution it is important to store the history of the bug. Bug Assignee This displays the list of users for whom the bug is assigned for resolution. As the bug need to be resolved for completing the product several user are assigned to find a solution for the bug. The user can add this bug to a new user or he can modify the existing user details. Bug Attachments This gives a list of attachments for a particular bug. The bug can be of any type it can be a database bug or a GUI bug. So while you add a bug you need to provide with the details of bug. So the file attachments can be a document, database file or an image file. All then attachments are stored in a location along with the size and type of the file. Here the user can add a new attachment or can change the details of existing files. 3. Bug Tracking Track Hierarchy

All the bugs saved in the database will have a particular hierarchy. There might be bugs which can be related to the earlier bugs saved in the database so our system is provided with a hierarchy. And user can add child nodes in this hierarchy or he can modify the existing values of the nodes. This hierarchy is based on the parent child relation ship between the bugs.

Track Resolution

This displays a list of all solutions provided by the users allotted to a bug. This stores the action type and the necessary resolution provided by the user.

Track Resources

This displays list of resources allotted to the project. As the bugs need to be resolved resources are provided for the bugs. These Resources will be the resources allotted to the project. The resources are allotted based on the rating of the employee.

4. View Product Bug Hierarchy This module is just for displaying the hierarchy for the easy Look of the bugs. Here the bugs are displayed in the form of parent child nodes. As it is difficult for the user to look at the vast number of bugs in the database. And one cannot easily access the relation between the bugs. Product User Hierarchy This module if for displaying the users allotted to the bug. The users along with their name and designation are displayed in this module. Even in the allotment of resources there can be hierarchy between the employees depending on their designation. So this module simplifies the hierarchy among the employees. 5. Search
Our system provides with the feature of advanced search technique. Generally Number of bugs for a project increased tremendously so if we want to know about a particular bug It takes much amount of time. With the search screen provided one can filter the bugs base on priority, product, severity, database and type of operating system. He can also list the bugs between particular time based on the start date and end date. After Searching it displays a list of bugs. From this list the user can modify the existing bugs or can add a new bug.

6. Admin Users All the users of this system are displayed in this module. One can add new user or can update the details of an existing user. Here the password provided by the user is encrypted before saving them to the database for proper security. This module saves the details like address, phone and email. Configuration

All the Values that we are using in this system are configurable. Values like status, priority and others can be added dynamically on the screen. Suppose if we limit these fields by hot coding them and if the user wants to add a new value again he has to come to the developer of the product. So In order to avoid this it is provided with the feature of adding values from the screen. And the user can change the status to In Active whenever he wants. Log View In order for the efficient Tracking of the system logs are maintained. As the logs will be in vast it will be a problem for user for checking the database. The Log View module can be searched based on the user and Records between a start date and end date. 7. Logout
In this once the user clicks on Log out First the session variable is killed and then the system is redirected to the login page.

8. Prepare Logs At all the stages, whenever user performs an operation by clicking a button, automatically the Bug Tracking System logs the activity.

4.5 DATABASE STRUCTURE

1. TBL_PRODUCT_DETAILS

No 1 2

Field Name PRODUCTID CODE

Data Type Integer String

Size 15

Constraint Primary -

Notes

3 4 5 6 7

TITLE DESCRIPTION DEVELOP_ENVIRON SUPPORT_ENVIRON RELEASEDT

String String String String Date

150 300 150 150 -

Contains information regarding Product developed by the organizations Generally products are equivalent to the projects developed all the details like supporting environments, code and Release dates are stored in this table.

2. TBL_PRODUCT-VERSION

No 1 2 3 4 5 6 7 8

Field Name PRODUCT_VER_CODE PRODUCTID TITLE DESCRIPTION VERSION_HISTORY RELEASEDT STATUS NOTES

Data Type Integer Integer String String String Date Character String

Size 150 300 300 1 300

Constraint Composite Foreign -

Notes

{11-1}

Check -

A|I|S

This table consists of versions for a project. ProjectID in this table has 1 to many relationships with the productId in the Product Details table. Product should not have more than one version active at a time. For efficient maintenance of a product version maintenance is and important module.

3. TBL_PRODUCT_USERS

No 1 2 3 4 5 6 7 8 9 10 11 UID

Field Name

Data Type Long Integer String Date Date String Integer String Integer String Character

Size 15 100 100 1

Constraint Foreign Foreign Check

Notes {1-1} {11-1} Admin|User

PRODUCTID ROLE FROMDT TODT IMPORTANCE PARENTID POSITION INDENT DESIGNATION STATUS

Foreign Foreign A|I|S Check

This table consists of details of users of the product. Users can be programmers, Team Leaders. Each user is valid only between fromdt and todt. UID is foreign key and has 1 to 1 relationship with TBL_AUTHENTICATION

4. TBL_USERS

No 1 2 3 4 5 6 UID

Field Name

Data Type Long String String String String Integer

Size 150 150 300 300 15

Constraint Foreign -

Notes

FNAME LNAME ADDRESS1 ADDRESS2 PHONE

7 8 9

EMAIL MOBILE STATUS

String Integer Character

50 15 1

Check

Validate email

A|I|S

This table contains details of users like name, phone, email etc. UID maintains 1 to 1 relationship with TBL_AUTHENTICATION.

5. TBL_AUTHENTICATION

No 1 2 3 UID

Field Name

Data Type Long Character Character

Size 8 8

Constraint Primary Check -

Notes

UNAME PASSWORD

Unique

This table contains all the users for this bug tracking system. Here the userid is unique for each user. Both Username and password can be either numeric or string.

6. TBL_CONFIGURATION

No 1 2 3 KEY

Field Name

Data Type String String Character

Size 15 30 1

Constraint -

Notes

VALUE STATUS

Unique A|I|S

Configuration table consists of all the values, which are configurable in this project. Values like Role, Priority, Platform etc can be configured in this table. Key value consists of the name of the configuration.

7. TBL_LOG

No 1 2 3 4 5 UID

Field Name

Data Type Long String Date String String

Size 150 100 15

Constraint Foreign -

Notes

ACTIVITY ACTIVITYDTTM IPNUMBER PHONE

Date & time of operation -

This table is used to maintain the log history of the users who has logged in. All the activities done by the user from his login to logout are stored in this table.

8. TBL_BUG_DETAILS

No 1 2 3 4 5 6 7 8 9 10

Field Name BUGID CODE TITLE DESCRIPTION PRODUCTID COMPONENT CATEGORY SEVERITY STATUS STATUSDTTM

Data Type Long String String String Integer String String String Character Date

Size 15 150 300 30 30 15 1 -

Constraint Primary Foreign

Notes

{11-1}

Check

High|Low {A|I|S}

Check

Date & time of operation

This table consists of details of bugs that occurred in the product development. Both the component and severity are obtained from configuration table.

9. TBL_BUG_ORIGIN

No 1 2 3 4 5 7

Field Name BUGID OS DATABASE IMPACTBY REPORTEDBY REPORTDTTM

Data Type Long String String Integer Integer Date

Size 15 15 -

Constraint Foreign Foreign Foreign Check

Notes {1-1}

{11-1} {1-1} {1-1} Date & time of operation

This table consists of origin details of bugs that occurred in the product development. Both the OS and DATABASE are obtained from configuration table. This table contains the fields Responsible for the bug origin.

10. TBL_BUG_ASSIGN

No 1 2 3 4 5 7

Field Name BUGID TYPE UID STATUS ASSIGNEDBY ASSIGNDTTM

Data Type Long String Integer Character Integer Date

Size 15 1 -

Constraint Foreign Foreign Check Foreign Check

Notes {1-1}

{1-1} A|I|S {1-1} Date & time of operation

This table consists of details of assignee to the bug and stored the assigned date time. This table has relation ship with the bugs table.

11. TBL_BUG_RESOLUTION

No 1 2 3 4 5 6 7

Field Name BUGID ACTIONTYPE ACTION DESCRIPTION RESOLVEDBY RESOLVEDTTM STATUS

Data Type Long String String String Integer Date Character

Size 15 150 300 1

Constraint Foreign

Notes {11-1}

Foreign Date & Time of operation A|I|S

This table consists of resolution details for a bug. This stores the necessary action to be taken for resolution, Status and Status date time.

12. TBL_BUG_RESOURCES

No 1 2 3 4 5 6 7

Field Name BUGID TITLE DESCRIPTION RATING RESOURCEBY RESOURCEDTTM UID

Data Type Long String String String Integer Date Integer

Size 150 300 15 -

Constraint Foreign

Notes {11-1}

Foreign Date & Time of operation Foreign {1-1}

This table consists of resources allotted to a bug. This stores title, description, rating and resource date time.

13. TBL_BUG_FILEATTACHMENTS

No 1 2 3 4 5 6 7 8 9

Field Name BUGID TITLE DESCRIPTION FILEID FILEPATH FILETYPE SIZE ATTACHEDBY RESOURCETTM

Data Type Long String String Integer String String Integer Integer Date

Size 150 300 300 15 -

Constraint Foreign

Notes {11-1}

Primary

Foreign Date & Time of operation

This table consists of file attachments for a bug. This stores the file type, file path, attached by. The attachments can be a screen shot or a word document. 14. TBL_BUG_HIERARCHY

No 1 2 3 4 5 6 7

Field Name BUGID PARENTID HIERARCHYBY IMPACT POSITION INDENT STATUS

Data Type Long Long Integer String String Integer Character

Size 300 300 1

Constraint Foreign Foreign Foreign Check

Notes {11-1} {1-1} {1-1} A|I|S

This table consists of hierarchy details of a bug. This ParentId in this table represents the origin bug id and the impact specifies the effect of bug on the over all project.

15. TBL_BUG_HISTORY

No 1 2 3 4 5

Field Name BUGID HISTORYBY REMARKS HISTORYDTTM STATUS

Data Type Long Integer String Date Integer

Size 300 1

Constraint Foreign Foreign -

Notes {11-1}

Date & Time of operation Check A|I|S

CHAPTER-5 DATA DESIGN

5.1 ENTITY RELATIONSHIP DIAGRAM

Definition: An entity-relationship (ER) diagram is a specialized graphic that illustrates the interrelationships between entities in a database. ER diagrams often use symbols to represent three different types of information. Boxes are commonly used to represent entities. Diamonds are normally used to represent relationships and ovals are used to represent attributes.

Entity Relationship (ER) diagram: This diagramming technique is used to visually present a database schema or data model and was original proposed by Chen in the 1970s. There are many different data modeling notations; some are very similar to UML class diagrams (with the exception of operations). However, the notation the used here is slightly different, as proposed by Elmasri, et al. The database schema for this system is shown in figure. The table object has been left out of the diagram because the table management feature set had been dropped from the requirements before this stage of the design process. Some important database design decisions are as follows: _ To store the total price of an order with the order rather than calculating it on the fly when looking at past orders. This is because the price of menu items could change at any time, so the total price at the time of ordering must be stored so that the total price is not incorrectly calculated in future. _ Similar to the previous point, the order receipt is stored as a hard-copy and not regenerated when reviewing past orders because things such as the restaurant name or VAT percentage are subject to change. Receipts stored need to be exactly the same as the customer copy in case ofdispute.

BugTracking

BBBBBUB

BUGID PRODUCTID

Tb1 bug detai

has

Tb1Product details

contains

maintains

has

Tbl_file_attachments

Tbl_bug_resources

Tbl_bug_history

fieldid

Bug detail

historyid

5.2 DATA FLOW DIAGRAM

DFD

The Data flow Diagram shows the flow of data. It is generally made of symbols given below : (1) A square shows the Entity : -

(2)

A Circle shows the Process: -

(3)

An open Ended Rectangle shows the data store : --

(4)

An arrow shows the data flow :-

The DFD can be up to several levels. The 0 level DFD states the flow of data in the system as seen from the outward in each module.The first level DFD show more detail, about the single process of the 0 level DFD.The second level DFD can show even more details and so on.

BTS - TOP LEVEL DIAGRAM

Programmer

Administrator

Bug Tracking System

Database

BTS - TOP LEVEL DIAGRAM

User

tbl_Product_Details

1 Login tbl_Bug_Details 6 Search

2 Products

3 Bugs

Details
Details

Results 7 Admin tasks

4 Track

7.1 Results 5 View 7.2 Configuration User Admin

7.3 Log Views

Details tbl_Configuration

8 Log Out

LOW LEVEL DIAGRAM - LOGIN tbl_Authentication Admin User 1.1 User User Details 1.2 Validate Programmer

LOW LEVEL DIAGRAM - PRODUCTS User tbl_Product_Details

2.1 Product List tbl_Product_Users

2.2 Details

2.3 Version

2.6 Users

2.4 Add / Modify

2.5 Delete

2.7 Add/ Modify

2.8 Delete

tbl_Product_Details

tbl_Product_Users

LOW LEVEL DIAGRAM - BUGS User tbl_Product_Details 2 Product List

tbl_Bug_Details

3.1 Bugs List

3.2 Bug History

3.2 Bug Assigned

3.3 File Attatchments

3.4 Add/Modiy

3.5 Delete

3.6 Add/Modiy

3.7 Delete

3.8 Add/Modiy

3.9 Delete

tbl_Bug_History

tbl_Bug_Assign

tbl_File_Attatchment

LOW LEVEL DIAGRAM - TRACKING tbl_Bug_Details User

4.1 Bug Details

4.2 Track Hierarchy 4.2 Track Resources

4.3 Track Resolution

4.4 Add / Modiy

4.5 Delete

4.6 Add / Modiy

4.7 Delete

4.8 Add / Modiy

4.9 Delete

tbl_Bug_Hierarchy

tbl_Bug_Resources

tbl_Bug_Resolution

LOW LEVEL DIAGRAM - VIEW tbl_Product_Details

User

5.1 Products

5.2 Product User Hierarchy

5.3 Bug Hierarchy

tbl_Product_Users

tbl_Bug_Details

LOW LEVEL DIAGRAM - SEARCH

6.1 User Search Criteria

6.2 Build Query

6.3 Execute Query Results

LOW LEVEL DIAGRAM - LOGOUT

8.1 User Close Session

8.2 Redirect Home Page

CHAPTER-6 SCREEN SHOTS

1. LOGIN FORM:

1. PRODUCTS 1. PRODUCT DETAILS

ADD PRODUCT DETAILS

EDIT PRODUCT DETAILS

2. PRODUCT VERSION

ADD PROJECT VERSION DETAILS

MODIFY PROJECT VERSION DETAILS

3. PRODUCT USERS

MODIFY USER

2.BUGS

1.BUG DETAILS

1. ADD BUG DETAILS

3. BUG ASSIGNED

ASSIGNING BUG TO USER

MODIFY BUG ASSIGNED TO USER

4. FILE ATTATCHMENTS

ADD NEW FILE ATTATCHMENT

MODIFY FILE ATTATCHED

3. TRACKING

TRACK HIERARCHY

2. TRACK RESOURCES

ADD NEW RESOURCE TO BUG

MODIFY EXISTING RESOURCE

TRACK RESOLUTION

ADD NEW RESOLUTION

4. VIEWS

PRODUCT USER HIERARCHY

PRODUCT BUG HIERARCHY

5. SEARCH

6. ADMIN

USER

ADD NEW USER

CONFIGURATION

LOG

CHAPTER-7 APPENDIX

FRONT END We have implemented JavaScript for all the Client side validations. Client side JavaScript is designed to reside inside HTML document & ensure they run properly. It is object based, event driven, platform independent. These are important parts of any Web application to implement Client side Validations and the invalid data is not submitted. The form is not submitted until user fills in correct data. It is extremely useful to restrict mistakes by user.

-BACK END We have used My SQL. MySQL provides database tech. - Large database and space management. - Many concurrent database users. - High transaction processing requirement - High Availability - Industry accepted standards - Manageable security - Portability efficient/effective solution for major

Front End Java Server Pages2.4 User friendly GUI Separation of work (designing & coding) Written once run anywhere Back End

Oracle10gXE Security Performance Scalability Reliability Support RDMS concepts

CHAPTER-8 TESTING

8.1 SOFTWARE TESTING

Software testing is the most important phase of any software development life cycle. It is the testing part, which validates the software and checks whether the software is working as desired or not. A major purpose of the testing is the reveal bugs in the software. In testing the software designed is executed with various test inputs for which the text programmer knows result in the advance. The departure of the program output from the known results confirms that the software contains error. Testing is divided into various phases:

UNIT TESTING:

Unit testing focus verification effort on the small unit of the software designs a module using the data design description as a guide, important control part were tested to uncover error within boundary of the module. The relative complexity of the test and uncovered error limited by the constrain scope established for unit testing. The unit test is always a WHITE BOX oriented and the step can be conducted in the parallel for multiple modules.

1. The module interface was tested to assume that information properly float into and out of the program unit under test. 2. The local data structure was examined to assume that data stored temporarily maintain their integrity during all steps in an algorithm execution. 3. Boundary condition was tested to assume that data stored temporarily maintain their integrity during all steps in an algorithm execution. 4. All independent paths through the control structure were exercise to assume that the all statement in a module have been executed at least once. 5. All error handing path were tested.

STATIC ANALYSIS:

It is technique for assessing the structural characteristics of source code design specifications or any notational representation that conformed to well define syntactic rules. Here structure of the code is examined but the code is examined the code is not executed.

SYSTEM TESTING:

It involves two kinds of activities integration testing and acceptance testing developing strategy for integrating the components of the components of software system in to a complete system requires functioning of the whole system and careful planning so that module are available for the integration where needed. Acceptance testing involves planning and execution of various types of tested in order to demonstrate that the implement software system satisfies the requirement document.

INTEGRATION TESTING:

It is systematic technique for the constructing the program structure while at the some time conducting test to uncover error associated with interface. The objective is to pay unit test module and build program structure that has been dedicated by design. Bottom-up integration beings construction and testing with the atomic (i.e. module at the lowest level in the program structure). Because modules were integrated from the bottom-up, processing required for modules subordinate to a given level was always available and need for stub was eliminated.

CHAPTER-9 FUTURE SCOPE

Simple yet flexible, Low cost for the small and mid-sized companies. Competitive prices: get started for 5$/user. Hosted or locally installed solutions, BugUp Tracker is a powerful web based bug tracker. Supporting an easy way to manage and track your bugs/defects or issues in an efficient way. Using. Free download of Bug tracking system - BugUp Tracker 4.2.115, size 2.50 Mb.

References
[1] I. Alexander. Stakeholders: Who is your system for? IEEE: Computing and Control Engineering,14(1):22{26, April 2003. [2] I. Alexander and T. Zink. Introduction to systems engineering with use cases. IEEE: Computing and Control Engineering, 13(6):289{297, December 2002. [3] Almyta Systems. Point of Sale Systems. http://systems.almyta.com/Point_of_Sale_ Software.asp. Accessed on 20th October 2008. [4] S. W. Ambler. Process Patterns: Building Large Scale Systems Using Object Technology. Cam-bridge University Press, 1998. [5] M. Andrews and J. A. Whittaker. How to Break Web Software: Functional and Security Testing of Web Applications and Web Servers. Addison-Wesley, 2006. [6] Java-2 Complete Reference [7] Java Servlet Programming [8] Pure JavaScript R.Allen Wyke [9] HTML complete - BPB publications. - by Apress publication. - by Patrick Haughton - by O'Reilly - by Jason Gilliam,

[10] Java Server Programming