Bug Tracking System

“Bug Management System”

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.

RGNCLC, NLIU Bhopal


CHAPTER 1

RGNCLC, NLIU Bhopal

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.

RGNCLC, NLIU Bhopal


[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

RGNCLC, NLIU Bhopal


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.

RGNCLC, NLIU Bhopal


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.

RGNCLC, NLIU Bhopal


CHAPTER 2

RGNCLC, NLIU Bhopal

LITERATURE

SURVEY


[2.1] Survey 1:AuthorsAiken RelayAmerican History, Smithsonian Institution. "The First "Computer Bug

[2.1.1] Case StudyThe 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

RGNCLC, NLIU Bhopal


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] ConclusionConclusion 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:AuthorsMurray HopperHarvard University

[2.2.1] Case StudyIn 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

RGNCLC, NLIU Bhopal


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.

RGNCLC, NLIU Bhopal

http://en.wikipedia.org/wiki/Human_factor


CHAPTER 3

RGNCLC, NLIU Bhopal

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 ,

RGNCLC, NLIU Bhopal

http://en.wikipedia.org/wiki/Quality_(business)

http://en.wikipedia.org/wiki/Performance_engineering

http://en.wikipedia.org/wiki/Non-functional_requirements

http://en.wikipedia.org/wiki/Non-functional_requirements

http://en.wikipedia.org/wiki/Functional_requirements

http://en.wikipedia.org/wiki/Use_case


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.

RGNCLC, NLIU Bhopal


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

RGNCLC, NLIU Bhopal


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

RGNCLC, NLIU Bhopal


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.

RGNCLC, NLIU Bhopal


[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

RGNCLC, NLIU Bhopal


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

RGNCLC, NLIU Bhopal


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.

RGNCLC, NLIU Bhopal


[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 JDKTM 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.

RGNCLC, NLIU Bhopal


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.

RGNCLC, NLIU Bhopal


[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.

RGNCLC, NLIU Bhopal


[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.

RGNCLC, NLIU Bhopal


[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

RGNCLC, NLIU Bhopal


CHAPTER 4

RGNCLC, NLIU Bhopal

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.

RGNCLC, NLIU Bhopal


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.

RGNCLC, NLIU Bhopal


[4.2] Sequence Diagram:

Figure 3 Sequence Diagram

RGNCLC, NLIU Bhopal


RGNCLC, NLIU Bhopal


[4.3] Class Diagram:-

Figure 4 Class Diagram

RGNCLC, NLIU Bhopal


[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.

RGNCLC, NLIU Bhopal


[4.5] ERD of bug tracking system Agency:

Figure 5 E-R Diagram

RGNCLC, NLIU Bhopal


[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

B u g Tra ck in gS y s te m

P r o g r am m erAd m in is tr a to r

D atab 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

Us er1 .1

Us er D eta ils

1 .2

Valid a te

Ad m in Us er

P r o g r am m er

tb l_ Au th en tic a tio n

Figure 7 Data Flow Diagram for Login

RGNCLC, NLIU Bhopal


[4.6.3] Level ‘2’ DFD-Bugs:

L O W L EV EL D I A G R A M - B UG S

Us er

2

P r o d u c t L is t

tb l_ P r o d u c t_ D eta ils

3 .1

Bu g s L is t

3 .2

Bu g His to r y

3 .2

Bu g As s ig n ed

3 .3

F ileAtta tc h m en ts

tb l_ Bu g _ D eta ils

3 .4

Ad d /M o d iy

3 .5

D e le te

3 .6

Ad d /M o d iy

3 .7

D ele te

3 .8

Ad d /M o d iy

3 .9

D ele te

tb l_ Bu g _ His to r y tb l_ Bu g _ As s ig n tb l_ F ile_ Atta tc h m en t

Figure 8 Data Flow Diagram for Bugs

RGNCLC, NLIU Bhopal


[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

Us er

4 .1

Bu g D eta ils

tb l_ Bu g _ D eta ils

4 .2

T r ac kHier a r c h y

4 .2

T r ac kR es o u r c es

4 .3

T r ac kR es o lu tio n

4 .4

Ad d / M o d iy

4 .5

D ele te

4 .6

Ad d / M o d iy

4 .7

D ele te

4 .8

Ad d / M o d iy

4 .9

D ele te

tb l_ Bu g _ R es o u r c es tb l_ Bu g _ R es o lu tio ntb l_ Bu g _ Hier a r c 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

Us er6 .1

S ear c h C r ite r ia

6 .2

Bu ild Q u er y

6 .3

E x ec u te Q u er y R es u lts

Figure 10 Data Flow Diagram for Search

RGNCLC, NLIU Bhopal


[4.6.6] Level ‘0’ DFD-Logout:

L O W L EV EL D I A G R A M - L O G O UT

Us er8 .1

C lo s e S es s io n

8 .2

R ed ir ec t Ho m eP 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.

RGNCLC, NLIU Bhopal


CHAPTER 5

[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.

RGNCLC, NLIU Bhopal

Conclusion


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/

RGNCLC, NLIU Bhopal

http://www.easywayserver.com/blog/java-best-database-connectivity-web/

http://office.microsoft.com/en-in/access-help/create-an-access-database-HP005187442.aspx

http://office.microsoft.com/en-in/access-help/create-an-access-database-HP005187442.aspx

http://en.wikipedia.org/wiki/Bug

http://bugs.adobe.com/flashplayer/

http://source.android.com/source/report-bugs.html

Bug Tracking System

Documents

Transcript of Bug Tracking System