Bug Tracking Java Project

visit--- http://bit.ly/bug_javaproject For the complete project + CODE.
visit ------- javaprojects.tutoriallearners.in for other Java Projects

1. PROJECT
ON
“Bug Tracking”

Visit:
http://bit.ly/bug_javaproject
For Complete Project

2. Bug Tracking for Improving
Software Reliability

3. Abstract
Contents
Introduction
Vision
Scope
Definition, Acronyms, Abbreviations
Overview

System Analysis
Existing System
Limitations in Existing System
Proposed System
Advantages over Existing System
Feasibility Study
Economic Feasibility
Operational Feasibility
Technical Feasibility

Software Requirement Specification
Software Requirements
Hardware Requirements

System Design
Architecture Diagram
Authentication
Functional Description
Functions
Maintenance
Functional Description
Functions
E - R Diagrams

4. UML Diagrams
Class Diagram
Use-case Diagram
Sequence Diagram
Component Diagram
Deployment Diagram
Data Dictionary
Coding & Implementation
Technologies Used
HTML & JavaScript, XML
Java Technology
Database Tool / SQL
Webserver / Application Server
Snapshots
User Groups
Testing
Scope for Future Enhancements
Project Summary
Bibliography

5. Abstract
Bug Tracking for Improving Software Reliability (BTS) is an automated system
that can be useful to employees and the managers in any functional
organization. Bug Tracking System gives the facility to define the tasks in the
organization and also allows the managers to track the bugs spent by the
employee for that particular task. A report generation facility is supported in
BTS that allows the managers to analyze which are those skills by employee are
utilized and those which are not utilized. This tool can help managers for Bug
estimation per project or application. This tool helps employees to document
their Bugs and analyze
This project aims at creation of a Bug Tracking System. This project will be
accessible to all developers and its facility allows developers to focus on
creating the database schema and while letting the application server define
table based on the fields in JSP and relationships between them. This system
provides the following facilities.
The objectives of this system are:
·To keep track of employee skills and based on the skills assigning of the
task is done to an employee.
·Employee does bugs capturing. It can be done on daily basis.
Various Reports are generated by this System for an employee and as well as to
a manager.

6. Introduction

7. Visit:
http://bit.ly/bug_javaproject

For Complete Project

8. used for many other purposes such as general issue tracking, simple task lists,
help desk situations or contact management, where the focus is on the tracking
aspect rather than what is being tracked. Even in software development,
tracking systems are quite often not limited to simply tracking bugs, but
extended to track feature requests or enhancements as well as enquiries.

9. System Analysis

10. Existing System

The existing system consists of entering the details in the Microsoft Excel
Sheets for the storing of the data. When a manager needs information of the
employee he searches for the specified file in the file system. He opens the file
and takes the information. Report Generation done manually by copying the
content of the different files into another file. The Manually generated report
was then printed.
Limitations in Existing System
·Information retrieval is a very big process.
·Lack of organization of the files may porn to information loss due to
accidental deletion of files.
·No security because the files are visible to the users.
·Report generation will be a big task.
Proposed System
The Proposed system is a browser which is completely related to online system,
which provides the centralized database. It stores bugs data and description of
the particular bug data. It can also create Excel reports and PDF documents
based on the information in its database.

Advantages over Existing System
·The performance is increased due to well designed database.
·Security is increased
·Time saving in report generation
·Easy to update the details

11. Feasibility Study
Economic Feasibility
Economic feasibility attempts 2 weigh the costs of developing and implementing
a new system, against the benefits that would accrue from having the new
system in place. This feasibility study gives the top management the economic
justification for the new system.
A simple economic analysis which gives the actual comparison of costs and
benefits are much more meaningful in this case. In addition, this proves to be a
useful point of reference to compare actual costs as the project progresses.
There could be various types of intangible benefits on account of automation.
These could include increased customer satisfaction, improvement in product
quality better decision making timeliness of information, expediting activities,
improved accuracy of operations, better documentation and record keeping,
faster retrieval of information, better employee morale.
Operational Feasibility
Proposed project is beneficial only if it can be turned into information systems
that will meet the organizations operating requirements. Simply stated, this test
of feasibility asks if the system will work when it is developed and installed. Are
there major barriers to Implementation? Here are questions that will help test
the operational feasibility of a project:
Is there sufficient support for the project from management from users? If the
current system is well liked and used to the extent that persons will not be able
to see reasons for change, there may be resistance.
Are the current business methods acceptable to the user? If they are not, Users
may welcome a change that will bring about a more operational and useful
systems.

12. Have the user been involved in the planning and development of the project?
Early involvement reduces the chances of resistance to the system and in
general and increases the likelihood of successful project.
Since the proposed system was to help reduce the hardships encountered. In
the existing manual system, the new system was considered to be operational
feasible.
Technical Feasibility
Evaluating the technical feasibility is the trickiest part of a feasibility study. This
is because, .at this point in time, not too many detailed design of the system,
making it difficult to access issues like performance, costs on (on account of the
kind of technology to be deployed) etc. A number of issues have to be
considered while doing a technical analysis.
Understand the different technologies involved in the proposed system before
commencing the project we have to be very clear about what are the
technologies that are to be required for the development of the new system.
Find out whether the organization currently possesses the required
technologies. Is the required technology available with the organization?

13. Software Requirement
Specification

14. Software Requirements
Operating System : Windows XP/ Windows 7/8
User Interface : HTML, CSS
Client-side Scripting : JavaScript
Programming Language : Java
Web Applications : JDBC Servlets, JSP
Database : Oracle/Access
Hardware Requirements
Processor : Pentium IV
Hard Disk : 40GB
RAM : 256MB

15. System Design

16. Functional Description
a.Login to the system through the first page of the application.
b.Change the password after login to the application.
c.See his/her details and change it.
d.Help from the system.

Maintenance
Functional Description
·User Maintenance: Creating, Granting & Revoking access and deleting
users from application.
·Component Maintenance: Creating a component (application being
developed / enhanced), Granting & Revoking access on components to
Users and Marking a component as “Active” or “Closed”.
·Bug Tracking: Creating, Assigning Bugs to users, Modifying and Closing a
Bug. A Bug screen should at least have following details
·Bug Number and Title
·Bug priority
·Date created
·Find User: A search screen to find users and display results
·Find component: A search screen to find components and display results
·Find Bug: A search screen to find Bugs and display results

17. ·Report: Generate reports on Bugs
Modules:
Admin: This module has the entire access to all other modules, admin creates
the project and assigning the projects to the created manager, adding members
to the managers, assigning bugs based on the priority. Can update the
manager, members and access to the particular project data. Generating
reports based on the managers report submission.
Manager: Manager has the full access to the particular project assigned by the
admin and controls the team members access to the bugs assigned. Has the
permission to generate the reports and update the information of team
members and adding members to the project.
Developer: Can access the task or bug assigned by the manager, view
assigned projects and resolving the assigned bug. Developer can view the bugs
list assigned by the manager.
Tester: Tester can access to the projects or bugs assigned by the manager, can
view the assigned projects and can add a new bug to the list and send the bug
back to the manager. Tester can login to the system and access the assigned
projects list.
Reports: Both Admin and Manager can access this module and generate the
reports based on the requirements.

Functions
Admin
Manger
Developer
Tester

18. Reports
Visit:
http://bit.ly/bug_javaproject
For Complete Project

19. Coding
&
Implementation

20. Visit:
http://bit.ly/bug_javaproject

For Complete Project

21. Snapshots

22. MENUS
EDIT PRODUCT DETAILS
Visit:
http://bit.ly/bug_javaproject

For Complete Project

23. MODIFY EXISTING RESOURCE

Visit:
http://bit.ly/bug_javaproject

For Complete Project

24. 6. ADMIN

Visit:
http://bit.ly/bug_javaproject

For Complete Project

25. E R Diagrams

26. Visit:
http://bit.ly/bug_javaproject

For Complete Project

27. B T S - T O P L E V E L D I A G R A M
U s e r
2
P r o d u c t s
1
L o g i n
3
B u g s
6
S e a r c h
4
T r a c k
7
A d m i n t a s k s
5
V i e w
7 . 1
U s e r A d m i n
7 . 2
C o n f i g u r a t i o n
7 . 3
L o g V i e w s
8
L o g O u t
D e t a i l s
D e t a i l s
D e t a i l s
R e s u l t s
t b l _ P r o d u c t _ D e t a i l s
t b l _ C o n f i g u r a t i o n
t b l _ B u g _ D e t a i l s
R e s u l t s

28. L O W L E V E L D I A G R A M - T R A C K I N G
U s e r
4 . 1
B u g D e t a i l s
t b l _ B u g _ D e t a i l s
4 . 2
T r a c k
H i e r a r c h y
4 . 2
T r a c k
R e s o u r c e s
4 . 3
T r a c k
R e s o l u t i o n
4 . 4
A d d / M o d i y
4 . 5
D e l e t e
4 . 6
A d d / M o d i y
4 . 7
D e l e t e
4 . 8
A d d / M o d i y
4 . 9
D e l e t e
t b l _ B u g _ R e s o u r c e s t b l _ B u g _ R e s o l u t i o n
t b l _ B u g _ H i e r a r c h y

29. U s e r
L O W L E V E L D I A G R A M - V I E W
5 . 1
P r o d u c t s
5 . 3
B u g H i e r a r c h y
5 . 2
P r o d u c t U s e r
H i e r a r c h y
t b l _ P r o d u c t _ D e t a i l s
t b l _ P r o d u c t _ U s e r s t b l _ B u g _ D e t a i l s

30. Testing

31. Visit:
http://bit.ly/bug_javaproject

For Complete Project

32. can also be described as an error in the correctness of the semantic of a
computer program. A fault will become a failure if the exact computation
conditions are met, one of them being that the faulty portion of computer
software executes on the CPU. A fault can also turn into a failure when the
software is ported to a different hardware platform or a different compiler, or
when the software gets extended. Software testing is the technical investigation
of the product under test to provide stakeholders with quality related
information.
Software testing may be viewed as a sub-field of Software Quality Assurance
but typically exists independently (and there may be no SQA areas in some
companies). In SQA, software process specialists and auditors take a broader
view on software and its development. They examine and change the software
engineering process itself to reduce the amount of faults that end up in the
code or deliver faster.
Regardless of the methods used or level of formality involved the desired result
of testing is a level of confidence in the software so that the organization is
confident that the software has an acceptable defect rate. What constitutes an
acceptable defect rate depends on the nature of the software. An arcade video
game designed to simulate flying an airplane would presumably have a much
higher tolerance for defects than software used to control an actual airliner.
A problem with software testing is that the number of defects in a software
product can be very large, and the number of configurations of the product
larger still. Bugs that occur infrequently are difficult to find in testing. A rule of
thumb is that a system that is expected to function without faults for a certain
length of time must have already been tested for at least that length of time.
This has severe consequences for projects to write long-lived reliable software.
A common practice of software testing is that it is performed by an independent
group of testers after the functionality is developed but before it is shipped to
the customer. This practice often results in the testing phase being used as
project buffer to compensate for project delays. Another practice is to start
software testing at the same moment the project starts and it is a continuous

33. process until the project finishes.
Another common practice is for test suites to be developed during technical
support escalation procedures. Such tests are then maintained in regression
testing suites to ensure that future updates to the software don't repeat any of
the known mistakes.
It is commonly believed that the earlier a defect is found the cheaper it is to fix
it.
Time Detected
Time
Introduced
Requirements Architecture Construction
System
Test
Post-
Release
Requirements1 3 5-10 10 10-100
Architecture- 1 10 15 25-100
Construction- - 1 10 10-25
In counterpoint, some emerging software disciplines such as extreme
programming and the agile software development movement, adhere to a "test-
driven software development" model. In this process unit tests are written first,
by the programmers (often with pair programming in the extreme programming
methodology). Of course these tests fail initially; as they are expected to. Then
as code is written it passes incrementally larger portions of the test suites. The
test suites are continuously updated as new failure conditions and corner cases
are discovered, and they are integrated with any regression tests that are
developed.
Unit tests are maintained along with the rest of the software source code and
generally integrated into the build process (with inherently interactive tests
being relegated to a partially manual build acceptance process).
The software, tools, samples of data input and output, and configurations are all
referred to collectively as a test harness.

34. Limitations and Future Enhancements
Limitations of the system:
·Only the permanent employees can access the system.
·System works with windows’98 and its compatible environments.
·Advanced techniques are not used to check the authorization.
·Once the employee is registered to a course cannot drop, without
completing.
Future Enhancements:
It is not possible to develop a system that makes all the requirements of the
user. User requirements keep changing as the system is being used. Some of
the future enhancements that can be done to this system are:
·As the technology emerges, it is possible to upgrade the system and can
be adaptable to desired environment.
·Because it is based on object-oriented design, any further changes can
be easily adaptable.
·Based on the future security issues, security can be improved using
emerging technologies.
·Attendance module can be added
· sub admin module can be added

35. Project Summary
This project Bug Tracking for Improving Software Quality and Reliability is to
keep track of employee skills and based on the skills assigning of the task is
done to an employee. Employee does bugs capturing. It can be done on daily
basis. Various Reports are generated by this System for an employee and as
well as to a manager.
This project will be accessible to all developers and its facility allows
developers to focus on creating the database schema and while letting the
application server define table based on the fields in JSP and relationships
between them.
This application software has been computed successfully and was also
tested successfully by taking “test cases”. It is user friendly, and has required
options, which can be utilized by the user to perform the desired operations.
The software is developed using Java as front end and Oracle as back end in
Windows environment. The goals that are achieved by the software are:
Instant access.
Improved productivity.
Optimum utilization of resources.
Efficient management of records.
Simplification of the operations.
Less processing time and getting required information.
User friendly.
Portable and flexible for further enhancement.

37. References

Visit:
http://bit.ly/bug_javaproject

For Complete Project