Bug Tracking System

“Bug Tracking System”
Contents
1. INTRODUCTION
Introduction to Project
Purpose of the Project
Existing System & its Disadvantages
Proposed System & its Advantages
2. SYSTEM ANALYSIS
Study of the system
Input & Output Representation
System architecture
3. REQUIREMENT SPECIFICATIONS
Functional Requirements
Performance Requirements
Software Requirements
Hardware Requirements
4. SYSTEM DESIGN
Introduction
UML Diagrams
E-R Diagram
5. CONCLUSION
6. FUTURE ENHANCEMENT
7. BIBLIOGRAPHY
RGNCLC, NLIU Bhopal Page 1

ABSTRACT
Bug Tracking System the system which enable to detect the bugs. It not merely detects the bugs
but provides the complete information regarding bugs detected. Bug Tracking System ensures
the user of it who needs to know about a provide information regarding the identified bug. Using
this no bug will be unfixed in the developed application. The developer develops the project as
per customer requirements. In the testing phase the tester will identify the bugs. Whenever the
tester encounter ‘n’ number of bugs he adds the bug id and information in the database. The
tester reports to both project manager and developer. The bug details in the database tables are
accessible to both project manager and developer.

CHAPTER 1
INTRODUCTION

[1]. Introduction:
When a customer puts request or orders for a product to be developed. The project manager is
responsible for adding users to Bus Tracking System and assigning projects to the users. The
project manager assigns projects to the developers. The developer develops the projects as per
customer requirements. The project manager itself assigns the developed applications to the
“Testers” for testing. The tester tests the application and identifies the bugs in the application.
When the tester encounters ‘n’ no. of bugs, he generates unique id number for each individual
bug. The bug information along with its id is mailed to the project manager and developer. This
is “Bug Report”. These are stored in the database. This is useful for further reference. Bug
information includes the bug id, bug name, bug priority, project name, bug location, bug type.
This whole process continues until all the bugs are got fixed in the application. The bug report is
mailed to the project manager and the developer as soon as the bug is identified. This makes that
no error will go unfixed because of poor communication. It makes ensure that anyone who
needs to know about a bug can learn of it soon after it is reported. Bug Tracking System plays a
vital role in the testing phase. But it supports assigning projects for the developer, tester by the
project manager. The Bug Tracking System maintains the different users separately i.e., it
provides separate environments for project manager, developer and tester.
[1.1] Rational:
The main benefit of a bug-tracking system is to provide a clear centralized overview of
development requests (including bugs and improvements, the boundary is often fuzzy), and their
state. The prioritized list of pending items (often called backlog) provides valuable input when
defining the product roadmap, or maybe just "the next release".
In a corporate environment, a bug-tracking system may be used to generate reports on the

productivity of programmers at fixing bugs. However, this may sometimes yield inaccurate
results because different bugs may have different levels of severity and complexity. The severity
of a bug may not be directly related to the complexity of fixing the bug. There may be different
opinions among the managers and architects.

[1.2] Problem Definition and Its Solutions:
[1.2.1] Problem Definition:

Every application has bugs -- as long as humans write code, there will continue to be errors in
software. Some errors are trivial, while others are critical. Open-source projects like Word Press
need the participation of their user communities to identify bugs in their software, as well as to
plan for new features.
[1.2.2] Proposed System:

Proposed System: The purpose of the Bug Tracking System is to test the application for
the bugs and report it to the project manager and developer. The main intention behind the Bug
Tracking System is that to track bugs and reports them. Store the bug information with a unique
id in the database for future reference. So, this makes the job of handling the bugs easy.
The main objectives of the Bug Tracking System are:

•Identifying the bugs in the developed application.
•No bug will be unfixed in the developed application.
•Not merely identifying the bugs but also providing the bug information.
•As soon as the bugs are identified. They are reported to the project manager and developer.
•To ensure that who needs to know about the bug can learn soon after it is reported
[1.3] Viability of the System:

A viable bug tracking system should permit an administrator to formulate permissions related to
status, move the bug to another status, or delete it. Certain systems also notify interested parties
when additional status changes have been made.
A bug tracking system should also provide a comprehensive overview of development
requests that have been made and their current status. In addition, a list of pending items, which
is prioritized, provides valuable information for everyone involved in producing the software.
In a large organization, it can generate reports related to the productivity a programmer who has
been assigned to repair the bugs, keeping in mind that these problems vary in complexity and
severity, and that managers and program designers sometimes disagree on the best approach to

take. Application support professionals often use a local bug tracker (LBT) as well to monitor
users’ complaints that may be irrelevant in the actual software development process.
The software is a web application which can be run on a windows operating system having Java
platform ( JDK 1.6 or higher ) .
The users of Bug Tracking System:
•Project Manager
•Developer
•Tester
[1.4] Presently Available System:

In the existing system, the project manager assigns the projects to the developers. The
developers develop the projects as per customer requirements. The project manager itself
assigns the developed applications to the tester for testing. In the testing phase, when the tester
encounters no. of bugs then he reports to the project manager and developer about the bug
information. Bottlenecks of the Existing System:
•The tester report which is called “Bug Report” is in the form of physical document. If the
document is damaged then the total information about the bug will be lost.
•The bug information is not stored in the database for future reference.
[1.5] Organization of Report:
Chapter 1-Introduction
In this Contents the introduction of “Bug Tracking System”. What will our software do it’s
functioning and its technology in which the software is made.
Chapter 2-Litrature Survey

In this chapter we have explained about what we study about the project with the previous
projects available in the issue tracking system.

Chapter 3-Analysis
Analysis phase contains the requirement analysis, use case, the activity and the Sequence
diagram.
Chapter 4-Design
In the Design phase we had explained about the our project” Bug Tracking System” with
the help of diagrams, we explained the various stages of the project through class diagram,
Component diagram, Sub System diagram etc.

CHAPTER 2
LITERATURE
SURVEY

[2.1] Survey 1:
Authors
Aiken Relay
American History, Smithsonian Institution.
"The First "Computer Bug
[2.1.1] Case Study

The results of bugs may be extremely serious. Bugs in the code controlling the Therac-25
radiation therapy machine were directly responsible for some patient deaths in the 1980s. In
1996, the European Space Agency's US$1 billion prototype Ariane 5 rocket was destroyed less
than a minute after launch, due to a bug in the on-board guidance computer program. In June
1994, a Royal Air Force Chinook crashed into the Mull of Kintyre, killing 29. This was initially
dismissed as pilot error, but an investigation by Computer Weekly uncovered sufficient evidence
to convince a House of Lords inquiry that it may have been caused by a software bug in the
aircraft's engine control computer.
In 2002, a study commissioned by the US Department of Commerce' National Institute of
Standards and Technology concluded that software bugs, or errors, are so prevalent and so
detrimental that they cost the US economy an estimated $59 billion annually, or about 0.6
percent of the gross domestic product.
The concept that software might contain errors dates back to 1843 in Ada Byron's notes
on the analytical engine in which she speaks of the difficulty of preparing program 'cards' for
Charles Babbage's Analytical engine: an analyzing process must equally have been performed in
order to furnish the Analytical Engine with the necessary operative data; and that herein may
also lie a possible source of error. Granted that the actual mechanism is unerring in its processes,
the cards may give it wrong orders.”Use of the term "bug" to describe inexplicable defects has
been a part of engineering jargon for many decades and predates computers and computer
software; it may have originally been used in hardware engineering to describe mechanical
malfunctions. For instance, Thomas Edison wrote the following words in a letter to an associate
in 1878:
“It has been just so in all of my inventions. The first step is an intuition, and comes with a
burst, then difficulties arise—this thing gives out and [it is] then that 'Bugs' — as such little

faults and difficulties are called—show themselves and months of intense watching, study and
labor are requisite before commercial success or failure is certainly reached.
[2.1.2] Conclusion
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
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.
[2.2] Survey 2:
Authors
Murray Hopper
Harvard University
[2.2.1] Case Study

In 1946, when Hopper was released from active duty, she joined the Harvard Faculty at the
Computation Laboratory where she continued her work on the Mark II and Mark III. Operators
traced an error in the Mark II to a moth trapped in a relay, coining the term bug. This bug was
carefully removed and taped to the log book. Stemming from the first bug, today we call errors
or glitch's [sic] in a program a bug.
Hopper was not actually the one who found the insect, as she readily acknowledged. The
date in the log book was 9 September 1947 although sometimes erroneously reported as
1945.The operators who did find it, including William "Bill" Burke, later of the Naval Weapons
Laboratory, Dahlgren, Virginia were familiar with the engineering term and, amused, kept the
insect with the notation "First actual case of bug being found." Hopper loved to recount the story.
This log book is on display in the Smithsonian National Museum of American History, complete
with moth attached.
While it is certain that the Harvard Mark II operators did not coin the term "bug", it has
been suggested that they did coin the related term, "debug". Even this is unlikely, since the

Oxford English Dictionary entry for "debug" contains a use of "debugging" in the context of air-
plane engines in 1945.
[2.2.2] Conclusion:
Bugs are a consequence of the nature of human factors in the programming task. They arise from
oversights or mutual misunderstandings made by a software team during specification, design,
coding, data entry and documentation. Hence bugs are very dangerous for any program or any
software.

CHAPTER 3
ANALYSIS

[3.1] Analysis:
Analysis is the process of breaking a complex topic or substance into smaller parts to gain a
better understanding of it. Analysis is a detailed study of the various operations performed by a
system and their relationships within and outside of the system. Here the key question is- what
all problems exist in the present system? What must be done to solve the problem? Analysis
begins when a user or producer begins a study of the program using existing system.
[3.1.1] Requirement Analysis:

 Requirement Analysis results in the specification of software’s operational characteristics
indicates the software’s interface with other system elements and establishes constraints
that the software meets.
 In requirement Analysis, we have studied various existing software’s and their features.
We have studied all the websites applications and examined their drawbacks.
 We referenced to certain other websites in order to have some additions and

enhancements to the existing software.
[3.1.2] Requirement Specification:

A Software Requirements Specification (SRS) is a complete description of the behavior of the
system to be developed. It includes a set of use cases that describe all the interactions the users
will have with the software. Use cases are also known as functional requirements. In addition to
use cases, the SRS also contains non-functional (or supplementary) requirements. Non-functional
requirements are requirements which impose constraints on the design or implementation (such
as performance engineering requirements, quality standards, or design constraints).
[3.1.2.1] Functional Requirement:-
Functional requirements may be calculations, technical details, data manipulation and processing
and other specific functionality that define what a system is supposed to accomplish. Behavioral
requirements describing all the cases where the system uses the functional requirements are

captured in use cases. Functional requirements are supported by non-functional requirements ,

which impose constraints on the design or implementation . How a system implements functional
requirements is detailed in the system design. This information is used to help the reader
understand why the requirement is needed, and to track the requirement through the development
of the system.
[3.1.2.2] Non-functional Requirement:-

The Non-functional Requirement which specify overall characteristics such as cost, time
management, reliability and quality of software. The main motto of this project is to save user
time and provide good communication. The total cost of this project is cheap as compare to
manual work done by the person in filling the details of users. Software working in very reliable
which help to voter to fill the form and communicate easily. Due to less complexity and user
friendly the quality is maintained by all over the project.
[3.1.3] Process Adopted Model:
[3.1.3.1] Iterative Waterfall Model:
Iterative and Incremental development is a cyclic software development process developed in

response to the weaknesses of the waterfall model. It starts with an initial planning and ends
with deployment with the cyclic interaction in between.
The basic idea behind iterative enhancement is to develop a software system incrementally,
allowing the developer to take advantage of what was being learned during the development of
earlier, incremental, deliverable versions of the system. Learning comes from both the
development and use of the system, where possible. Key steps in the process were to start with
a simple implementation of a subset of the software requirements and iteratively enhance the
evolving sequence of versions until the full system is implemented. At each iteration, design
modifications are made and new functional capabilities are added.
In this project the model used is Iterative waterfall Model.

Figure 1 Iterative Waterfall Model
We have adopted this model because of following strengths:
• Develop high-risk or major functions first

• Each release delivers an operational product
• Customer can respond to each build
• Uses “divide and conquer” breakdown of tasks
• Lowers initial delivery cost
• Initial product delivery is faster
• Customers get important functionality early
• Risk of changing requirements is reduced
[3.1.3.2] SDLC Stages:-

The six stages of the SDLC are designed to build on one another, taking the outputs from the
previous stage, adding additional effort, and producing results that leverage the previous effort
and are directly traceable to the previous stages. This top-down approach is intended to result in
a quality product that satisfies the original intentions of the customer.
Development efforts go awry when the development team and customer personnel get caught up
in the possibilities of automation. Instead of focusing on high priority features, the team can

become mired in a sea of “nice to have” features that are not essential to solve the problem, but
in themselves are highly attractive. This is the root cause of a large percentage of failed and/or
abandoned development efforts, and is the primary reason the development team utilizes the
Waterfall SDLC.
[3.1.3.3]Requirements Definition Stage:
• The requirements gathering process takes as its input the goals identified in the
high-level requirements section of the project plan. Each goal will be refined into
a set of one or more requirements. These requirements define the major functions of the
intended application, define operational data areas and reference data areas, and define the
initial data entities. Major functions include critical processes to be managed, as well as
mission critical inputs, outputs and reports. A user class hierarchy is developed and
associated with these major functions, data areas, and data entities.
Each of these definitions is termed a Requirement. Requirements are identified by
unique requirement identifiers and, at minimum, contain a requirement title and
textual description.
[3.1.3.4] Design Stage
• The design stage takes as its initial input the requirements identified in the
approved requirements document. For each requirement, a set of one or more
design elements will be produced as a result of interviews, workshops, and/or
prototype efforts. Design elements describe the desired software features in detail, and
generally include functional hierarchy diagrams, screen layout diagrams, tables of business
rules, business process diagrams, pseudo code, and a complete entity-relationship diagram
with a full data dictionary. These design elements are intended to describe the software in
sufficient detail that skilled programmers may develop the software with minimal
additional input.
[3.1.3.5] Development Stage:
• The development stage takes as its primary input the design elements described in
the approved design document. For each design element, a set of one or more

software artifacts will be produced. Software artifacts include but are not limited
to menus, dialogs, data management forms, data reporting formats, and specialized
procedures and functions. Appropriate test cases will be developed for each set of
functionally related software artifacts, and an online help system will be developed to guide
users in their interactions with the software.
[3.1.3.6] Integration & Test Stage:
• During the integration and test stage, the software artifacts, online help, and test
data are migrated from the development environment to a separate test
environment. At this point, all test cases are run to verify the correctness and
completeness of the software. Successful execution of the test suite confirms a
robust and complete migration capability. During this stage, reference data is finalized for
production use and production users are identified and linked to their appropriate roles. The
final reference data (or links to reference data source files) and production user list are
compiled into the Production Initiation Plan.
[3.1.4] Object Oriented Analysis:-
Object-oriented design is the process of planning a system of interacting objects for the purpose
of solving a software problem. It is one approach to software design. An object contains
encapsulated data and procedures grouped together to represent an entity. The 'object interface',
how the object can be interacted with, is also defined. An object-oriented program is described
by the interaction of these objects. Object-oriented design is the discipline of defining the objects
and their interactions to solve a problem that was identified and documented during object-
oriented analysis.
What follows is a description of the class-based subset of object-oriented design, which does not
include object prototype-based approaches where objects are not typically obtained by instancing
classes but by cloning other (prototype) objects.

[3.1.4.1] Input (sources) for object-oriented design:
The input for object-oriented design is provided by the output of object-oriented analysis. Realize that an
output artifact does not need to be completely developed to serve as input of object-oriented design;
analysis and design may occur in parallel, and in practice the results of one activity can feed the other in a
short feedback cycle through an iterative process. Both analysis and design can be performed
incrementally, and the artifacts can be continuously grown instead of completely developed in one shot.
Some typical input artifacts for object-oriented design are:
 Conceptual model: Conceptual model is the result of object-oriented analysis, it captures

concepts in the problem domain. The conceptual model is explicitly chosen to be
independent of implementation details, such as concurrency or data storage.
 Use case: Use case is a description of sequences of events that, taken together, lead to a
system doing something useful. Each use case provides one or more scenarios that
convey how the system should interact with the users called actors to achieve a specific
business goal or function. Use case actors may be end users or other systems. In many
circumstances use cases are further elaborated into use case diagrams. Use case diagrams
are used to identify the actor (users or other systems) and the processes they perform.
 System Sequence Diagram: System Sequence diagram (SSD) is a picture that shows, for
a particular scenario of a use case, the events that external actors generate, their order,
and possible inter-system events.
 User interface documentations (if applicable): Document that shows and describes the
look and feel of the end product's user interface. It is not mandatory to have this, but it
helps to visualize the end-product and therefore helps the designer.
 Relational data model: A data model is an abstract model that describes how data is
represented and used. If an object database is not used, the relational data model should
usually be created before the design, since the strategy chosen for object-relational
mapping is an output of the OO design process. However, it is possible to develop the

relational data model and the object-oriented design artifacts in parallel, and the growth
of an artifact can stimulate the refinement of other artifacts.
[3.1.4.2] Object-oriented concepts:
The five basic concepts of object-oriented design are the implementation level features that are built into
the programming language. These features are often referred to by these common names:
 Object/Class: A tight coupling or association of data structures with the methods or

functions that act on the data. This is called a class, or object (an object is created based
on a class). Each object serves a separate function. It is defined by its properties, what it
is and what it can do. An object can be part of a class, which is a set of objects that are
similar.
 Information hiding: The ability to protect some components of the object from external
entities. This is realized by language keywords to enable a variable to be declared as
private or protected to the owning class.
 Inheritance: The ability for a class to extend or override functionality of another class.
The so-called subclass has a whole section that is derived (inherited) from the super class
and then it has its own set of functions and data.
 Interface: The ability to defer the implementation of a method. The ability to define the
functions or methods signatures without implementing them.
 Polymorphism: The ability to replace an object with its sub objects. The ability of an
object-variable to contain, not only that object, but also all of its sub objects.
[3.1.4.3] Designing concepts:
 Defining objects, creating class diagram from conceptual diagram: Usually map entity to
class.
 Identifying attributes.
 Use design patterns: A design pattern is not a finished design, it is a description of a

solution to a common problem, in a context. The main advantage of using a design

pattern is that it can be reused in multiple applications. It can also be thought of as a

template for how to solve a problem that can be used in many different situations and/or
applications. Object-oriented design patterns typically show relationships and interactions
between classes or objects, without specifying the final application classes or objects that
are involved.
 Define application framework: Application framework is a term usually used to refer to a

set of libraries or classes that are used to implement the standard structure of an
application for a specific operating system. By bundling a large amount of reusable code
into a framework, much time is saved for the developer, since he/she is saved the task of
rewriting large amounts of standard code for each new application that is developed.
 Identify persistent objects/data (if applicable): Identify objects that have to last longer
than a single runtime of the application. If a relational database is used, design the object
relation mapping.
 Identify and define remote objects (if applicable).
[3.1.4.4] Output (deliverables) of object-oriented design:
 Sequence Diagrams: Extend the System Sequence Diagram to add specific objects that
handle the system events. A sequence diagram shows, as parallel vertical lines, different
processes or objects that live simultaneously, and, as horizontal arrows, the messages
exchanged between them, in the order in which they occur.
[3.2] Architecture Specification:

[3.2.1] Purpose:
In a corporate environment, a bug-tracking system may be used to generate reports on the
productivity of programmers at fixing bugs. However, this may sometimes yield inaccurate
results because different bugs may have different levels of severity and complexity. The severity
of a bug may not be directly related to the complexity of fixing the bug.

[3.2.2] Document Conventions:
[3.2.2.1] Java Developer Kit (JDK):

Java Platform, Standard Edition (Java SE) Documentation contains API specifications, feature
descriptions; developer guides, reference pages for JDK TM tools and utilities, demos, and links to
related information. This documentation is also available in a download bundle which you can
install on your machine. To obtain the documentation bundle, see the download page. For API
documentation, refer to the Java Platform, Standard Edition API Specification This provides
brief descriptions of the API with an emphasis on specifications, not on code examples.
[3.2.2.2]The Java Runtime Environment (JRE):

The JRE allows you to run applications written in the Java programming language. Like the
JDKTM, it contains the Java Virtual Machine (JVMTM), classes comprising the Java platform API,
and supporting files. Unlike the JDK, it does not contain development tools such as compilers
and debuggers.
User can freely redistribute the JRE with your application, according to the terms of the JRE
license. Once users have developed your application using the JDK, you can ship it with the JRE
so your end-users will have a Java platform on which to run your software.
[3.2.2.3] Net Beans:
Net Beans IDE is an integrated development environment (IDE) for writing, compiling, testing,
and debugging desktop applications and web applications for the Java platform. NetBeans IDE
includes a full-featured text editor with syntax highlighting and error checking, visual design
tools, Ant support, version control system support, and many other features.
To start the IDE (Microsoft Windows) use one of these methods:

 Double-click the Net Beans IDE icon on your desktop.
 Choose Start > All Programs > NetBeans 6.0 > NetBeans IDE.
 Start the IDE at the command line C:\> netbeans-install-directory\bin\netbeans.exe.
To stop the IDE:

 From the IDE, choose File > Exit.

To uninstall the IDE (Microsoft Windows)
 Use the Add/Remove Programs utility. Do not manually delete the directories and files.
[3.2.3] Scope:-
[3.2.3.1] Functional Requirement:-
Functional requirements may be calculations, technical details, data manipulation and processing
and other specific functionality that define what a system is supposed to accomplish. Behavioral
requirements describing all the cases where the system uses the functional requirements are
captured in use cases. Functional requirements are supported by non-functional requirements,
which impose constraints on the design or implementation. How a system implements functional
requirements is detailed in the system design. This information is used to help the reader
understand why the requirement is needed, and to track the requirement through the development
of the system.
[3.2.3.2] Non-functional Requirement:-
The Non-functional Requirement which specify overall characteristics such as cost, time
management, reliability and quality of software. The main motto of this project is to save user
time and provide good communication. The total cost of this project is cheap as compare to
manual work done by the person in filling the details of users. Software working in very reliable
which help to voter to fill the form and communicate easily. Due to less complexity and user
friendly the quality is maintained by all over the project.
[3.2.4] Overall Description:-
[3.2.4.1] Product perspective:

Bug tracking System is aimed towards the companies who want to reach out to the maximum
cross-section of customer and common people who can be potential customer. This project
envisages bridging the gap between the company and their customer. Bug Tracking system
should detect bugs very effectively.

[3.2.4.2] Product feature:

The main goal of this project is to store bug information by giving unique id for each bug in the
database. This will be used for future reference while the same bug arises. The project has the
following modules:
•Project Manager
•Developer
•Tester
[3.2.4.3] Operating Environment:
Operating System- Windows XP
Minimum Ram- 128 MB
Technology-Java
JDK or NETBEANS run the project.

Back End- MS ACCESS Database used for storing of data
[3.2.4.4] Design and Implementation Constraints:

The system shall be built using a standard web page development tool that conforms to either
IBM’s CUA standards or Microsoft’s GUI standards.
 The computers must be equipped with web browsers such as Internet explorer.
 The product must be stored in such a way that allows the client easy access to it.
 Response time for loading the product should take no longer than five minutes.
 A general knowledge of basic computer skills is required to use the product.
[3.2.4.5] User Documentation:
This Software is a web based application. To run the project java should be installed on the
system that should be jdk1.6.0 and its above versions. Our project can also be run on the
NetBeans. It should also the NetBeans6.0 and its above version.

[3.2.3] System Features:

Listing:
This includes the listing feature of the software where any search or other request of a user to a
particular subject is served. The software loaded and the particular database is initialized. There
are listings based on the priority as by user preferences. This is actually the listing of swing
pages to the users by time of selling, deadline, price, quality etc. Listing includes listing of
 Customer interacts directly to the user of the system.
 User can use the tools provided in the software that are calculator and notepad.
 Just casual listings of random things
 Payment options to buy or sell.
[3.2.4] External Interface Requirements:
[3.2.4.1] User Interfaces:
Each part of the user interface intends to be as user friendly as possible. The fonts and buttons
used will be intended to be very fast and easy to load on pages. The pages will be kept light in
space so that it won’t take a long time for the software to load. The staring page will ask the user
what kind of a user is he, customer, clerk or a casual visitor. Based on which the future pages
will be loaded in a sequential manner. Each listing page will have a area to put the bid, the
product details with photo etc. Each page also will have a search engine to search the products
available so that it is readily available and the user need not search for it. Each button will have
an help link to help the user in understanding the process.
[3.2.4.2] Hardware Interfaces:

A NetBeans will be used to the Pages and the database management system. Most pages will be
made by swing components. Each page will be optimized to the type of software and resolution
being used. Normal modes of network modes used in Internet technology will be used.

[3.2.4.3] Software Interfaces:
The incoming message mostly includes requests for a specific task, which on the course of the
development will be decided in detail and dealt with in design specification document. The
incoming messages from the messages will be converted to a specific format in the database
language, the processing made and the request served. The operations will be intended to be
made as fast as possible.
[3.2.5] Nonfunctional Requirements:-
[3.2.5.1] Performance Requirements:

It should perform faster and economically.
[3.2.5.2]Safety Requirements:
Suitable safety has to be taken while allowing booking the ticket of the customer. They have to
follow the legalities of the land, and must be ethical. There could be possible misuse of the
system by bogus user, bidding and buying without paying up. It is not always possible to check
the postal addresses. Also during money transactions the unreliable networks may cause further
problems. So such practices need to be avoided.
[3.2.5.3]Security Requirement:
Security is the mainly occurs in the online application because any one in the network can hack
the unauthorized access to the network. So that our software is a desktop application there is no
problem of hacking or unauthorized access because the user of the system is able to operate the
system no other can operate our system except user.
[3.2.5.4]Software Quality Attribute:

The system is easy to load and light .It adds to the quality and usability of the system. Some
others quality considerations such as adaptability, availability, correctness, flexibility,
interoperability, maintainability, portability, reliability, reusability, robustness, testability, and
usability will also be very seriously taken to consideration

CHAPTER 4
DESIGN

[4.1] Use Case Diagram:
Figure 2 Use-Case Diagram
[4.1.1] Use Case Specification:

 Login Use Case
The login use case helps the system to identify the operator .The operator will be asked to
enter the username ,password & the designation .The user will be grated permission to
operate the system only if the operator has entered the correct username ,password &
matching up with the designation stored in the database files.

 Login Failed Use Case

The logout use case exists in the system in a extend relationship with the login use case. It
simply informs the operator that whether the username and/or the password and/or the
designation has not entered correctly.
 Add Operator Use Case

The above use case will provide the functionality to add a new system operator that will only
be used by the manager of the system .After the manager has provided the username,
password and the designation to the new operator ,the operator can login into the system and
perform various tasks associated with his designation.
 View and Add Entries Use Case

This use case will only be used by the manager with which the manager will be able to add
new entries such as a new bus ,a new employee ,etc .Also the manager will be able to
remove an entry from the existing entries.
 View Reports Use Case

The view reports use case will provide the functionality to view reports for employees ,bus
trips ,passengers ,etc .These facilities will be used by all the operators of the system.
 Logout Use Case

This use case will provide the operators functionality of exiting the system so that if another
operator wants to enter the system he will have to login again.

[4.2] Sequence Diagram:
Figure 3 Sequence Diagram


[4.3] Class Diagram:-
Figure 4 Class Diagram

[4.4] Data Model:-

Data modeling answers a set of specific questions that are relevant to any data processing
application. What are the primary data objects to be processed by the system? What is the
composition of each data object and what attributes describe the Object? Where do the objects
currently reside? What are the relationships between each object and other objects? What are the
relationships between the objects and the processes that transform them? To answer these
questions, data modeling methods make use of the entity relationship Diagram. The ERD,
described in detail later in this section, enables software Engineer to identify data objects and
their relationships using a graphical notation. In the context of structured analysis, the ERD
defines all data that are entered, stored, Transformed, and produced within an application.
The entity relationship diagram focuses solely on data (and therefore satisfies the first
operational analysis principles), representing a "data network" that exists for a given system. The
ERD is especially useful for applications in which data and the relationships that govern data is
complex. Unlike the data flow diagram (discussed in Section 12.4 and used to represent how data
are transformed), data modeling considers data independent of the processing that transforms the
data.
[4.4.1] Process modeling: The data objects defined in the data modeling phase are
transformed to achieve the information flow necessary to implement a business function.
Processing descriptions are created for adding, modifying, deleting, or retrieving a data object.
[4.4.2] Application generation: RAD assumes the use of fourth generation techniques.
Rather than creating software using conventional third generation programming languages the
RAD process works to reuse existing program components (when possible) or create reusable
components (when necessary). In all cases, automated tools are used to facilitate construction of
the software.

[4.5] ERD of bug tracking system Agency:
Figure 5 E-R Diagram

[4.6] Data Flow Diagram:

[4.6.1] Level ‘0’ DFD:
B TS - TO P L EV EL D I A G R A M
A d m in is t r a t o r
P rogram m er
B u g Tr a c k i n g
S yste m
D a tab as e
Figure 6 Level ‘0’ Data Flow Diagram
[4.6.2] Level ‘1’ DFD for Login:
L O W L EV EL D I A G R A M - L O G I N
tb l_ Au th en tic atio n
Ad m in Us e r
1 .1 1.2
Us e r Us er D etails Va lid a te
P r o g r am m er
Figure 7 Data Flow Diagram for Login

[4.6.3] Level ‘2’ DFD-Bugs:
L O W L EV EL D I A G R A M - B UG S
U s er
tb l_ P r o d u c t_ D etails
2
tb l_ Bu g _ D etails
P r o d u c t L is t
3.1
Bu g s L is t
3.2 3.2 3.3

Bu g H is to r y Bu g As s ig n ed F ile
Attatc h m en ts
3 .6 3 .7 3.8 3.9
3.4 3.5
Ad d /M o d iy D elete Ad d /M o d iy D e lete
Ad d /M o d iy D ele te
tb l_ Bu g _ H is to r y tb l_ Bu g _ A s s ig n tb l_ F ile _ A ttatc h m e n t
Figure 8 Data Flow Diagram for Bugs

[4.6.4] Level ‘2’ DFD-Tracking:
L O W L EV EL D I A G R A M - TR A C K I NG
tb l_ Bu g _ D etails Us er
4 .1
Bu g D etails
4 .2 4.3
T ra c k 4 .2 T rac k
Hie ra r c h y R es o lu tio n
T r ac k
R e s o u rc e s
4 .4 4.5 4.6 4 .7 4 .8 4.9

Ad d / M o d iy D elete Ad d / M o d iy D e lete Ad d / M o d iy D e lete
tb l_ Bu g _ R e s o u r c e s tb l_ Bu g _ R e s o lu tio n
tb l_ Bu g _ Hier a rc h y
Figure 9 Data Flow Diagram for Tracking
[4.6.5] Level ‘0’ DFD-Search:
L O W L EV EL D I A G R A M - S EA R C H
6.1 6 .2 6.3
U s er S e a r c h C r it e r ia Bu ild Q u e r y E x e c u te Q u e r y R e s u lt s
Figure 10 Data Flow Diagram for Search

[4.6.6] Level ‘0’ DFD-Logout:
L O W L EV EL D I A G R A M - L O G O U T
8.1 8.2
Us er C lo s e S e s s io n R e d ir e c t H o m e
P ag e
Figure 11 Data Flow Diagram for Logout
[4.7] Expected Outcomes:-

The software is developed using Netbeans editor as front end and Ms-access 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.
[4.8]Limitations of the system:

• Only the permanent employees can access the system.
•System works with windows 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.

CHAPTER 5
Conclusion
[5.1] Conclusion:
This project Bug Tracking System 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.

Bibliography
Books:-
 Cay S. Horstmann and Gary Cornell, “Core Java™” Volume I – Fundamentals 7th
Ed.
 Dave Thau, “The Book of JavaScript: A Practical Guide to Interactive Web Pages”,
Ed. 2nd .
Website:-
 www.google.com
 http://source.android.com/source/report-bugs.html
 http://bugs.adobe.com/flashplayer/
 http://en.wikipedia.org/wiki/Bug Tracking System
 http://office.microsoft.com/en-in/access-help/create-an-access-database-
HP005187442.aspx
 http://www.easywayserver.com/blog/java-best-database-connectivity-web/

Bug Tracking System

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Bug Tracking System

Uploaded by

Copyright:

Available Formats

“Bug Tracking System”

RGNCLC, NLIU Bhopal Page 1

RGNCLC, NLIU Bhopal Page 2

RGNCLC, NLIU Bhopal Page 3

In a corporate environment, a bug-tracking system may be used to generate reports on the

RGNCLC, NLIU Bhopal Page 4

[1.2] Problem Definition and Its Solutions:

[1.2.1] Problem Definition:

[1.2.2] Proposed System:

The main objectives of the Bug Tracking System are:

[1.3] Viability of the System:

RGNCLC, NLIU Bhopal Page 5

[1.4] Presently Available System:

[1.5] Organization of Report:

Chapter 2-Litrature Survey

RGNCLC, NLIU Bhopal Page 6

RGNCLC, NLIU Bhopal Page 7

RGNCLC, NLIU Bhopal Page 8

[2.1.1] Case Study

RGNCLC, NLIU Bhopal Page 9

[2.2.1] Case Study

RGNCLC, NLIU Bhopal Page 10

RGNCLC, NLIU Bhopal Page 11

RGNCLC, NLIU Bhopal Page 12

[3.1.1] Requirement Analysis:

 We referenced to certain other websites in order to have some additions and

[3.1.2] Requirement Specification:

[3.1.2.1] Functional Requirement:-

RGNCLC, NLIU Bhopal Page 13

captured in use cases. Functional requirements are supported by non-functional requirements ,

[3.1.2.2] Non-functional Requirement:-

[3.1.3] Process Adopted Model:

[3.1.3.1] Iterative Waterfall Model:

Iterative and Incremental development is a cyclic software development process developed in

In this project the model used is Iterative waterfall Model.

RGNCLC, NLIU Bhopal Page 14

Figure 1 Iterative Waterfall Model

We have adopted this model because of following strengths:

• Develop high-risk or major functions first

[3.1.3.2] SDLC Stages:-

RGNCLC, NLIU Bhopal Page 15

[3.1.3.3]Requirements Definition Stage:

[3.1.3.4] Design Stage

[3.1.3.5] Development Stage:

RGNCLC, NLIU Bhopal Page 16

[3.1.3.6] Integration & Test Stage:

[3.1.4] Object Oriented Analysis:-

RGNCLC, NLIU Bhopal Page 17

[3.1.4.1] Input (sources) for object-oriented design:

Some typical input artifacts for object-oriented design are:

 Conceptual model: Conceptual model is the result of object-oriented analysis, it captures

RGNCLC, NLIU Bhopal Page 18

[3.1.4.2] Object-oriented concepts:

 Object/Class: A tight coupling or association of data structures with the methods or

[3.1.4.3] Designing concepts:

 Use design patterns: A design pattern is not a finished design, it is a description of a

RGNCLC, NLIU Bhopal Page 19

pattern is that it can be reused in multiple applications. It can also be thought of as a

 Define application framework: Application framework is a term usually used to refer to a

 Identify and define remote objects (if applicable).

[3.1.4.4] Output (deliverables) of object-oriented design:

[3.2] Architecture Specification:

RGNCLC, NLIU Bhopal Page 20