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

Page 1

Bug Management System

CHAPTER 1

INTRODUCTION

RGNCLC, NLIU Bhopal

Page 2

Bug Management System

[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

Page 3

Bug Management System

[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 Page 4

Bug Management System

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. developers develop the projects as per customer requirements. The 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 its 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

Page 5

Bug Management 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.

RGNCLC, NLIU Bhopal

Page 6

Bug Management System

CHAPTER 2

LITERATURE SURVEY

Survey
RGNCLC, NLIU Bhopal Page 7

Bug Management System

[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 arisethis thing gives out and [it is] then that 'Bugs' as such little

RGNCLC, NLIU Bhopal

Page 8

Bug Management System

faults and difficulties are calledshow 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
RGNCLC, NLIU Bhopal Page 9

Bug Management System

Oxford English Dictionary entry for "debug" contains a use of "debugging" in the context of airplane 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

Page 10

Bug Management System

CHAPTER 3

ANALYSIS

Survey

RGNCLC, NLIU Bhopal

Page 11

Bug Management System

[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 softwares operational characteristics indicates the softwares interface with other system elements and establishes constraints that the software meets. In requirement Analysis, we have studied various existing softwares 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

RGNCLC, NLIU Bhopal

Page 12

Bug Management System

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 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. planning and ends

RGNCLC, NLIU Bhopal

Page 13

Bug Management System

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 Page 14

Bug Management System

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 Page 15

Bug Management System

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 objectoriented 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

Page 16

Bug Management System

[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

Page 17

Bug Management System

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

Page 18

Bug Management System

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

Page 19

Bug Management System

[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 Page 20

Bug Management System

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

Page 21

Bug Management System

[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 IBMs CUA standards or Microsofts 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

Page 22

Bug Management System

[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 wont 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
RGNCLC, NLIU Bhopal Page 23

Bug Management System

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

Page 24

Bug Management System

CHAPTER 4

DESIGN

Survey

RGNCLC, NLIU Bhopal

Page 25

Bug Management System

[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

Page 26

Bug Management System

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

Page 27

Bug Management System

[4.2] Sequence Diagram:

Figure 3 Sequence Diagram

RGNCLC, NLIU Bhopal

Page 28

Bug Management System

[4.3] Class Diagram:-

Figure 4 Class Diagram

RGNCLC, NLIU Bhopal

Page 29

Bug Management System

[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

Page 30

Bug Management System

[4.5] ERD of bug tracking system Agency:

Figure 5 E-R Diagram

RGNCLC, NLIU Bhopal

Page 31

Bug Management System

[4.6] Data Flow Diagram:

[4.6.1] Level 0 DFD:
BTS - TOP LEVEL DIAGRAM

Programmer

Administrator

Bug Track ing System

Database

Figure 6 Level 0 Data Flow Diagram

[4.6.2] Level 1 DFD for Login:

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

Figure 7 Data Flow Diagram for Login

RGNCLC, NLIU Bhopal

Page 32

Bug Management System

[4.6.3] Level 2 DFD-Bugs:

LOW LEVEL DIAGRAM - BUGS User tbl_Product_Details 2 Product List

tbl_Bug_Details

3.1 Bugs List

3.2 Bug History

3.2 Bug Assigned

3.3 File Attatchments

3.4 Add/Modiy

3.5 Delete

3.6 Add/Modiy

3.7 Delete

3.8 Add/Modiy

3.9 Delete

tbl_Bug_History

tbl_Bug_Assign

tbl_File_Attatchment

Figure 8 Data Flow Diagram for Bugs

RGNCLC, NLIU Bhopal

Page 33

Bug Management System

[4.6.4] Level 2 DFD-Tracking:

LOW LEVEL DIAGRAM - TRACKING tbl_Bug_Details User

4.1 Bug Details

4.2 Track Hierarchy 4.2 Track Resources

4.3 Track Resolution

4.4 Add / Modiy

4.5 Delete

4.6 Add / Modiy

4.7 Delete

4.8 Add / Modiy

4.9 Delete

tbl_Bug_Hierarchy

tbl_Bug_Resources

tbl_Bug_Resolution

Figure 9 Data Flow Diagram for Tracking

[4.6.5] Level 0 DFD-Search:

LOW LEVEL DIAGRAM - SEARCH

6.1 User Search Criteria

6.2 Build Query

6.3 Execute Query Results

Figure 10 Data Flow Diagram for Search

RGNCLC, NLIU Bhopal

Page 34

Bug Management System

[4.6.6] Level 0 DFD-Logout:

LOW LEVEL DIAGRAM - LOGOUT

8.1 User Close Session

8.2 Redirect Home Page

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

Page 35

Bug Management System

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.

RGNCLC, NLIU Bhopal

Page 36

Bug Management System

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-databaseHP005187442.aspx

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

RGNCLC, NLIU Bhopal

Page 37