DOCSLIB.ORG

Introduction to Software Engineering: Tools and Environments

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
Introduction to Software Engineering: Tools and Environments Introduction to Software Engineering: Tools and Environments Session 7 Oded Lachish Room: Mal 405 Visiting Hours: Wednesday 17:00 to 20:00 Email: [email protected] Module URL: http://www.dcs.bbk.ac.uk/~oded/Tools2012-2013/Web/Tools2012-2013.html 1 Last time • Debugging with Eclipse • Code coverage with corbetura • Static code analysis – Checkstyle, PMD, FindBugs Hopefully by now we know how to mock software. Hopefully we also have some tools for debugging. Remember: an important goal of these tools is minimal interaction with product code. 2 Verification Overview 3 What have we seen until now Dynamic Verification • The software’s behaviour is checked dynamically during execution Static verification • The software is checked via a static analysis 4 Dynamic verification Scope: • Small – unit testing (Junit) • Large ‐ Integration testing (Cucumber) • Even larger ‐ System test Types of tests • Functional • Stress (non functional) Main disadvantage • Can’t cover all the cases 5 Static verification Formal Verification: • Formally proving that code abides certain behavioural rules Can be done automatically or semi automatically. (We didn’t do since it is applicable only in a very small number of cases) Code convention • Check that software abides a recommended coding style. The coding style is there to improve readability, to prevent future bugs etc. Tools: Checkstyle, PMD and Findbugs Anything else? 6 Code Review Jupiter http://jupiter‐eclipse‐plugin.googlecode.com/svn/trunk/site/ 7 jupiter Code review plug‐in for eclipse Important features: • Open Source • Cross‐platform ‐ available for all platforms supported by Eclipse. • XML data storage: stores data in XML format. • Supports sorting and searching • File integration: easy to jump go back and forth between reviews and source code. 8 Jupiter –Four Step Process Code review plug‐in for eclipse Step 1: Configuration • Insertion of review information by leader of review –(important – must be committed) Step 2: Individual review • Each person by himself • Issues are created • At this stage only issues created by the selected user 9 Jupiter –Four Step Process Code review plug‐in for eclipse Step 3: Team • One person updates their local environment so that it contains all the review files • All issues can be seen • The team modifies issues upon need Step 4: Rework Phase • Author of code resolves issues (fixes code) • Author of code updates issue accordingly • Review files are committed and permanently stored as part of the project 10 Review ID A review ID consists of the following • The set of files to be reviewed • The list of reviewers • The review session author • Review storage location • Item entries ‐ Type, Severity, Resolution, and Status fields (are customizable.) • Default items ‐ default values for fields when a new issue is created. • Filters – filter to be applied when issues are displayed 11 Creating Review ID ‐Start Press You should get Press 12 Creating Review ID –ID creation Pick a review name Enter description 13 Creating Review ID – adding files Press You should get 14 Creating Review ID –ID creation Pick a review name Enter description 15 Creating Review ID – Added files 16 Creating Review ID – Adding a Reviewer Press This should appear Add name 17 Creating Review ID – Session Author 18 Creating Review ID – Session Author Press to get options 19 Creating Review ID – Finish 20 Creating Review ID –What New? Review directory Jupiter perspective 21 Jupiter advanced options –getting there 1 Press 22 Jupiter advanced options –getting there 2 Press 23 Jupiter advanced options –getting there 3 Pick Press 24 Jupiter advanced options –getting there 4 Press 25 Jupiter advanced options –entry items Items may be added, removed and reordered 26 Jupiter advanced options – filters Options for focusing only on specific issues 27 Adding an issue Right click and press 28 Adding issues 29 Review Table 30 Changing phase to Team Press A new issue appears. This is from a different author. (check if you can add such an issue by yourself) 31 From Individual phase to Team Phase Code 32 After decision made Decision made issue removed Make another decision 33 Rework Phase Issues and what need to be done Only issues relevant to the person responsible for them appear Now only revision text can be changed 34 Bug‐Tracking‐Systems 35 Bugzilla 36 What is Bugzilla? Bug‐Tracking‐System‐ a system for keeping track of bugs and how they are resolved Important features: • Open Source • inter‐bug dependencies and dependency graphing • extensive configurability And many more features 37 Why use Bugzilla? When software quality is at a high priority bug tracking is essential. 1. Monitoring bugs and their resolution as part of the workflow 2. Keeping in touch with the bug resolution process through e‐mail integrated features 3. Archiving bug related information 4. Accountability 5. Open‐source enables customers to use system 38 Installing Bugzilla Taken from: http://cvs1.up.ac.za/bugzilla‐doc/stepbystep.html#AEN515 The software packages necessary for the proper running of bugzilla are: 1.MySQL database server and the mysql client (3.22.5 or greater) 2.Perl (5.004 or greater, 5.6.1 is recommended if you wish to use Bundle::Bugzilla) 3.DBI Perl module 4.Data::Dumper Perl module 5.Bundle::Mysql Perl module collection 6.TimeDate Perl module collection 7.GD perl module (1.8.3) (optional, for bug charting) 8.Chart::Base Perl module (0.99c) (optional, for bug charting) 9.DB_File Perl module (optional, for bug charting) 10.The web server of your choice. Apache is recommended. 11.MIME::Parser Perl module (optional, for contrib/bug_email.pl interface) 39 Landfill: The Bugzilla Test Server http://landfill.mozilla.org/ This demonstration is taken from the above link. Requires e‐mail address ‐ to open account Bugzilla Trunk Demo ‐ A demo installation running the "trunk" (meaning, very latest unstable) 40 Welcome to Bugzilla 41 Pick a product 42 Bug report 43 Starting to enter a bug Bugzilla suggests possible duplicates. Why is this important? 44 45 Making sense of it all Status –open bugs • UNCONFIRMED ‐ just added to the database. Not confirmed that this bug is valid. Can either change to CONFIRMED (if confirmed) or directly to RESOLVED (if it is resolved). • CONFIRMED ‐ a recently filed actual bug. If someone is working on it is changed to IN_PROGRESS or directly to RESOLVED (if it is resolved). • IN_PROGRESS ‐ can change to CONFIRMED if directed to another person, or resolved and become or directly to RESOLVED (if it is resolved). 46 Making sense of it all Status –closed bugs • RESOLVED ‐ code changed, now it is QA’s turn. Can either be reopened or if QA approve change to VERIFIED. • VERIFIED ‐ QA approved bug should be gone now –final state. Other options • FIXED a fix for this bug is checked into the tree and tested. • INVALID not a bug. • WONTFIX bug that there is no plan to fixed. • DUPLICATE already appeared • WORKSFORME bug can’t be reproduced or explained –waiting for additional information which may lead to reopening of bug. 47 Life cycle of a bug Taken from http://wiki.eclipse.org/Image: BzLifecycle.png 48 Important fields • Assignee ‐ the person in charge of resolving the bug. • Bug ID ‐ the numeric id of a bug, unique within this entire installation of Bugzilla. • CC ‐ users who may not have a direct role to play on this bug, but who are interested in its progress. • Classification ‐ bugs are categorized into Classifications, Products and Components. classifications is the top‐level categorization. • Component ‐ second‐level categories; each belongs to a particular Product. Select a Product to narrow down this list. • Depends on ‐ the bugs listed here must be resolved before this bug can be resolved. • Reporter ‐ the person who filed this bug. • Severity ‐ how severe the bug is, or whether it's an enhancement. 49 Bugzilla Report Generator 50 Report selected 51 Generated report table format 52 Generated report 53 Simple search 54 Advanced search 55 Change over time 56 Old Charts 57 Bug Count 58 Create Chart ‐ 1 59 Create Chart ‐ 2 60 New Chart 61 How to write bug reports Seems that writing bug reports is an art: The report should be: • Concise • Clear • Only one bug per report • Don’t confuse fact with speculation !! – A bug report should contain enough information to reproduce the bug. (for more guidelines: https://landfill.bugzilla.org/bugzilla‐tip/page.cgi?id=bug‐writing.html) 62 Trac http://trac.edgewall.org/ Most of the material below has been taken from: http://trac.edgewall.org/wiki/WikiFormatting 63 What is Trac? Enhanced wiki and issue tracking system for software development projects. Important features: • web based • minimalistic approach • extensive configurability and many more features 64 Wiki formatting rules examples http://trac.edgewall.org/wiki/WikiFormatting 65 Trac tickets Trac has a database for tickets. Ticket Fields • Reporter —The author of the ticket. • Type —The nature of the ticket (for example, defect or enhancement request). • Component —The project module or subsystem this ticket concerns. • Version — Version of the project that this ticket pertains to. • Keywords —Keywordsthat a ticket is marked with. Useful for searching and report generation. • Priority —The importance of this issue, ranging from trivial to blocker. A pull‐down if different priorities where defined. • Milestone —When this issue should be resolved at the latest. A pull‐ down menu containing a list of milestones. • Assigned to/Owner —Principal person responsible for handling the issue. 66 Trac tickets editing Some Trac installations may put restrictions in place about who can change what. For example, the default installation doesn't permit to non‐ authenticated users ("anonymous" users) to change anything, even to comment on an issue, for obvious spam prevention reasons. Check the local contributing policy, which you can usually find on the front page WikiStart, or contact your local Trac administrator.
Load more

Recommended publications
  • Defect Tracking System Project Documentation
    Defect Tracking System Project Documentation Tottering Barr azotise some Faust and gyps his surplices so sweetly! Northrup remains impellent after Sigfried havers nominally or fluorescing any good-byes. Remus orientalize thunderously? So much like automation and project defect tracking documentation but not win any kind of the organization tries to track the list by the beginning development team and let an. The amount of tracking system project defect tracking system! All comments are moderated before publication and desire meet our guidelines. Testing is a lousy part of mature software life cycle, and recent trends in software engineering evidence the importance all this activity all survey the development process. Diving deeper into program language theory is a great way data grow outside a developer. Your comment has been received. Bug reporting by the Web and email. Her homeland of interests are Wireless Networks and Database Management Systems. As projects grow in size and complexity, the limits of an Excel story for tracking issues begin to show which quickly. Thank who for using our services. Ten reports engine is a few lines of system project defect tracking documentation appears every single pane contains the. Defect tracking is responsible system authority is applied for any system software so run system performs well. User interface and learning curve the system user interfaces are more user friendly than others. Switch to fullscreen mode always show business bug attributes at once. Some custom structure for large body usually, evaluating and tracking system project defect documentation related documents, planning with your development organization efficiently and eliminate bad.
    [Show full text]
  • Tuto Documentation Release 0.1.0
    Tuto Documentation Release 0.1.0 DevOps people 2020-05-09 09H16 CONTENTS 1 Documentation news 3 1.1 Documentation news 2020........................................3 1.1.1 New features of sphinx.ext.autodoc (typing) in sphinx 2.4.0 (2020-02-09)..........3 1.1.2 Hypermodern Python Chapter 5: Documentation (2020-01-29) by https://twitter.com/cjolowicz/..................................3 1.2 Documentation news 2018........................................4 1.2.1 Pratical sphinx (2018-05-12, pycon2018)...........................4 1.2.2 Markdown Descriptions on PyPI (2018-03-16)........................4 1.2.3 Bringing interactive examples to MDN.............................5 1.3 Documentation news 2017........................................5 1.3.1 Autodoc-style extraction into Sphinx for your JS project...................5 1.4 Documentation news 2016........................................5 1.4.1 La documentation linux utilise sphinx.............................5 2 Documentation Advices 7 2.1 You are what you document (Monday, May 5, 2014)..........................8 2.2 Rédaction technique...........................................8 2.2.1 Libérez vos informations de leurs silos.............................8 2.2.2 Intégrer la documentation aux processus de développement..................8 2.3 13 Things People Hate about Your Open Source Docs.........................9 2.4 Beautiful docs.............................................. 10 2.5 Designing Great API Docs (11 Jan 2012)................................ 10 2.6 Docness.................................................
    [Show full text]
  • The Opendaylight Open Source Project
    UNIVERSIDAD REY JUAN CARLOS Master´ Universitario en Software Libre Curso Academico´ 2014/2015 Proyecto Fin de Master´ The OpenDaylight Open Source Project Autor: Sergio Najib Arroutbi Braojos Tutor: Dr. Gregorio Robles 2 Agradecimientos A mi familia y a mi pareja, por su apoyo incondicional Al equipo de Libresoft de la Universidad Rey Juan Carlos, por su afan´ en ensenar˜ el que´ y el porque´ del Software Libre Dedicatoria Para todos aquellos´ que hacen posible el fenomeno´ del Software Libre 4 (C) 2014 Sergio Najib Arroutbi Braojos. Some rights reserved. This document is distributed under the Creative Commons Attribution-ShareAlike 3.0 license, available in http://creativecommons.org/licenses/by-sa/3.0/ Source files for this document are available at http://github.com/sarroutbi/MFP/opendaylight/ 6 Contents 1 Introduction 19 1.1 Terminology.................................... 19 1.1.1 Open Source Programmable Networking................ 19 1.2 About this document............................... 20 1.2.1 Document structure............................ 20 1.2.2 Scope................................... 21 1.2.3 Methodology............................... 21 2 Goals and Objectives 23 2.1 General Objectives................................ 23 2.2 Subobjectives................................... 23 2.2.1 Acquire competence on OpenDaylight project.............. 23 2.2.2 Analyze OpenDaylight project from an Open Source perspective.... 24 2.2.3 Statistics and measures of the OpenDaylight project.......... 24 3 OpenDaylight: A first view 25 3.1 OpenDaylight Project............................... 25 3.2 SDN........................................ 29 3.2.1 What is SDN?.............................. 29 3.2.2 SDN: Market share and expectations................... 31 3.3 NFV........................................ 34 3.3.1 What is NFV?.............................. 35 3.3.2 SDN/NFV relationship.......................... 36 3.3.3 NFV benefits..............................
    [Show full text]
  • Atlassian Is Primed to Widen Its Appeal Beyond IT
    Seth Agulnick, [email protected] REPORT Atlassian Is Primed to Widen Its Appeal Beyond IT Companies: CA, CRM, GOOG/GOOGL, HPE, IBM, JIVE, MSFT, NOW, ORCL, TEAM, ZEN February 11, 2016 Report Type: Initial Coverage ☐ Previously Covered Full Report ☐ Update Report Research Question: Will Atlassian’s workflow tools continue to grow quickly with software development teams while also expanding into new use cases? Summary of Findings Silo Summaries . Atlassian Corp. Plc’s (TEAM) tracking and collaboration tools, widely 1) Atlassian Software Users considered the best-in-class for software development, are gaining JIRA and Confluence are both effective tools for team traction among nontechnical teams. collaboration. JIRA can be customized to suit nearly any team’s development process, though setup is . The company’s two flagship products, JIRA and Confluence, are complicated. Confluence is much easier to use and slowly being rolled out in departments like human resources, sales, tends to be deployed more widely. Atlassian’s biggest customer support and product management. These represent a advantage is the way all of its software pieces work together. Atlassian products—which already are being much larger market than Atlassian’s traditional core in IT. branched out beyond software development—can grow . JIRA was praised for its flexibility and advanced customization even further with business teams. options, though the latter trait makes setup and maintenance a challenge. It has great potential for sales growth with any business 2) Users of Competing Software Three of these five sources said Atlassian’s JIRA is not team that needs to track numerous tasks through a multistage the right fit for every company.
    [Show full text]
  • Letter, If Not the Spirit, of One Or the Other Definition
    Producing Open Source Software How to Run a Successful Free Software Project Karl Fogel Producing Open Source Software: How to Run a Successful Free Software Project by Karl Fogel Copyright © 2005-2021 Karl Fogel, under the CreativeCommons Attribution-ShareAlike (4.0) license. Version: 2.3214 Home site: https://producingoss.com/ Dedication This book is dedicated to two dear friends without whom it would not have been possible: Karen Under- hill and Jim Blandy. i Table of Contents Preface ............................................................................................................................. vi Why Write This Book? ............................................................................................... vi Who Should Read This Book? ..................................................................................... vi Sources ................................................................................................................... vii Acknowledgements ................................................................................................... viii For the first edition (2005) ................................................................................ viii For the second edition (2021) .............................................................................. ix Disclaimer .............................................................................................................. xiii 1. Introduction ...................................................................................................................
    [Show full text]
  • Impact of Switching Bug Trackers: a Case Study on a Medium-Sized Open Source Project Théo Zimmermann, Annalí Casanueva Artís
    Impact of switching bug trackers: a case study on a medium-sized open source project Théo Zimmermann, Annalí Casanueva Artís To cite this version: Théo Zimmermann, Annalí Casanueva Artís. Impact of switching bug trackers: a case study on a medium-sized open source project. ICSME 2019 - International Conference on Software Maintenance and Evolution, Sep 2019, Cleveland, United States. hal-01951176v3 HAL Id: hal-01951176 https://hal.inria.fr/hal-01951176v3 Submitted on 26 Jul 2019 HAL is a multi-disciplinary open access L’archive ouverte pluridisciplinaire HAL, est archive for the deposit and dissemination of sci- destinée au dépôt et à la diffusion de documents entific research documents, whether they are pub- scientifiques de niveau recherche, publiés ou non, lished or not. The documents may come from émanant des établissements d’enseignement et de teaching and research institutions in France or recherche français ou étrangers, des laboratoires abroad, or from public or private research centers. publics ou privés. Impact of switching bug trackers: a case study on a medium-sized open source project Theo´ Zimmermann ([email protected]) Annal´ı Casanueva Art´ıs Universite´ de Paris, IRIF, CNRS, F-75013 Paris, France Paris School of Economics, F-75014 Paris, France Inria, π:r2 project-team Abstract—For most software projects, the bug tracker is an bugs fixed [6]. More generally, opening issues and discussing essential tool. In open source development, this tool plays an existing ones has been shown to be an important step on the even more central role as it is generally open to all users, who path to becoming an active contributor of an open source are encouraged to test the software and report bugs.
    [Show full text]
  • E-BUG TRACKING SYSTEM GUIDE: Mrs
    E-BUG TRACKING SYSTEM GUIDE: Mrs. Sathya Priya R1 R.B. Babu2, R. Marimuthu3, G. Gowtham4, V. Prakash5 1Assistant Professor, KSR Institute for Engineering and Technology, Tiruchengode. 2,3,4,5Department of Computer Science And Engineering, KSR Institute for Engineering and Technology, Tiruchengode. ABSTRACT This is the world of information. The ever-growing field Information Technology has its many advanced notable features which made it what it was now today. In this world, the information has to be processed, clearly distributed and must be efficiently reachable to the end users intended for that. Otherwise, we know it led to disastrous situations. The other coin of the same phase is it is absolutely necessary to know any bugs that are hither-to face by the end users. The project “e-bug tracking system” aims to provide the solution for that. The Bug Tracker can be made from any two types. The first one being the system side, the other being the services side. Our project deals with the second one. The paper is wholly dedicated to tracking the bugs that are hither- by arise. The administrator maintains the master details regarding to the bugs id, bugs type, bugs description, bugs severity, bugs status, user details. The administrator too has the authority to update the master details of severity level, status level, etc, modules of the paper. The administrator adds the users and assign them responsibility of completing the paper. Finally, on analysing the paper assigned to the particular user, the administrator can track the bugs, and it is automatically added to the tables containing the bugs, by order of severity and status.
    [Show full text]
  • Bug Tracker Net Documentation
    Bug Tracker Net Documentation Piscatorial and platelike Jean-Pierre backwash rigorously and immerge his pup pausingly and qualmishly. Glaucescent and nicotinic Sayers meditates anachronistically and reregulating his Bruges redolently and unemotionally. Jurassic Miguel befool whitely while Stevie always dedicating his squeezers marauds unthankfully, he miring so monumentally. The targeted project issue date. The predefined values should put left alone. Default user preference to enable filtering based on issue severity. Your comment has been received. Mantis Bug Tracker REST API Postman. It might been released, settings, you create and wade a script. NET Framework XML classes to steep and manipulate the data assess them. Compare to other products or configurations, take their moment to browse these introductory docs. Try upgrading to the latest stable version. The consider of filter fields to buy per row. We erect not, schedules, an object will be flagged. Alternatively, hence, we to submit a report back soon please report cannot be displayed on to main window. Automate data source between Sheets and Tracker. NET, remainder of the bugs are readable, their description etc in the cemetery of reports from time start time. It will no longer if possible login using this account. Then what problem behavior be solved more promptly. Someone hijacked my Google account. Kanban board for visualizing your project timeline. Default value list ON. The default value somewhere ON. Google users are affected. Specifies the LDAP or Active Directory server to key to. You can afford click the Updated column heading to which most recently updated issues at our top along the search results.
    [Show full text]
  • Modern Open Source Java EE-Based Process and Issue Tracker
    MASARYK UNIVERSITY FACULTY}w¡¢£¤¥¦§¨ OF I !"#$%&'()+,-./012345<yA|NFORMATICS Modern open source Java EE-based process and issue tracker DIPLOMA THESIS Monika Gottvaldová Brno, 2014 Declaration Hereby I declare, that this paper is my original authorial work, which I have worked out by my own. All sources, references and literature used or excerpted during elaboration of this work are properly cited and listed in complete reference to the due source. Monika Gottvaldová Advisor: doc. RNDr. Tomáš Pitner, Ph.D. ii Acknowledgement I would like to thank Ing. OndˇrejŽižka for his advice and help during the creation of this thesis. iii Abstract This thesis deals with the topic concerning issue tracking systems, their functionality and features. It compares several issue tracking systems, their advantages and disadvantages. It describes a development of such a sys- tem and the use of modern Java EE technologies – JPA, Wicket, and CDI. The main motivation for creating a new issue tracking system and the sub- sequent development is also described. The thesis analyses its basic design and implementation. iv Keywords Issue tracking system, Wicket, modern Java EE, issue, bug, workflow, cus- tomization v Contents 1 Introduction ...............................1 2 Issue Tracking Systems ........................3 2.1 Bugzilla . .4 2.2 Trac . .6 2.3 JIRA . .7 2.4 Mantis . .8 2.5 BugTracker.NET . .9 2.6 Redmine . 10 2.7 FogBugz . 11 3 Analysis of Relevant Processes in Red Hat ............. 14 3.1 RHEL 6 QE . 14 3.1.1 Process Phases Description . 14 3.1.2 Bugzilla Process . 15 3.2 Fedora QE . 16 3.2.1 Process Phases Description .
    [Show full text]
  • Ptest Method Documentation Release 1
    Ptest Method Documentation Release 1 Villalongue Maxime Dec 13, 2018 The Essentials 1 The Essentials Series 3 1.1 Cybersecurity in an Enterprise......................................3 1.2 Linux Basics............................................... 13 2 Infrastructure Pentest Series 35 2.1 Intelligence Gathering.......................................... 35 2.2 Vulnerability Analysis.......................................... 44 2.3 Exploitation............................................... 142 2.4 Post Exploitation............................................. 184 2.5 Reporting................................................. 211 2.6 Configuration Review.......................................... 212 2.7 Wireless Pentesting............................................ 220 3 Hardening Series 223 3.1 Securing your Debian.......................................... 223 4 Metasploit Documentation 231 4.1 Fundamentals............................................... 231 4.2 Information Gathering.......................................... 286 4.3 Vulnerability Scanning.......................................... 305 4.4 Fuzzers.................................................. 321 4.5 Exploit Development........................................... 326 4.6 Client Sides attacks............................................ 352 4.7 MSF Post Exploitation.......................................... 361 4.8 Meterpreter Scripting........................................... 396 4.9 Maintaining Access........................................... 412 4.10 MSF Extended Usage.........................................
    [Show full text]
  • SENG 371 LAB OUTLINE SOFTWARE EVOLUTION  Bug Tracking System
    3/22/2013 SENG 371 LAB OUTLINE SOFTWARE EVOLUTION Bug Tracking System Types of bug tracking system BUG TRACKING Bug Tracking Tools Bugzilla Prepared by 1 Pratik Jain 2 BUG TRACKING SYSTEM BUG TRACKING Bug Tracking system or issue tracking system or Not only Software Development Team need a bug defect tracking system, is a software application tracking system but sysadmin team, dba team, that keep tracks of reported bugs. network team all require some system to track their work. 3 4 WHY BUG TRACKING TOOLS? BENEFITS Collabortaive Work. Clear centralized overview of development requests(bugs and improvements). Software is a result of many people at different locations different timezones. It helps in next release of Software by using all logs. Communication is crucial, tool makes it easy. Generating reports on productivity of programmers at fixing bugs. Makes easier to track history and evolution of bugs. Improves Communication. 5 6 1 3/22/2013 TYPES OF BUG TRACKING SYSTEM LIFE CYCLE OF BUG Web browser based Client Server based model Distributed Bug Tracking :- Designed to be used with distributed revision control software like Fossil, Veracity and FogBugz. 7 8 MAJOR COMPONENTS BUG REPORT ATTRIBUTES Major Component of Bug tracking system is database that records facts about known bugs. Date : Open Date, Closed Date Status : New, Unconfirmed, Open, Closed, Facts can be :- Deleted, Assigned Request Id: Number Time Severity Detailed Description Identity Severity\Priority : - critical, major, minor\p1,p2 Resolution Category if any, like Gui, Installation or certain module 9 10 BUG REPORT ATTRIBUTES BUG TRACKING SOFTWARES Bugzilla Mantis Jira GNATS Flyspray IBM Rational ClearQuest FogBugz Trac Fossil 11 12 2 3/22/2013 PUBLIC BUG TRACKERS PUBLIC BUG TRACKERS USING BUGZILLA Lots of Open Source projects uses Bug Tracking Open Source Projects:- systems to report a bug.
    [Show full text]
  • D1.4 Project Standards and Infrastructure Document
    Grant Agreement nº 732463 Project Acronym: OpenReq Project Title: Intelligent Recommendation Decision Technologies for Community-Driven Requirements Engineering Call identifier: H2020-ICT-2016-1 Instrument: RIA (Research and Innovation Action) Topic ICT-10-16 Software Technologies Start date of project January 1st, 2017 Duration 36 months D1.4 Project standards and infrastructure document Lead contractor: TU Graz Author(s): TU Graz, ENG, HITEC, QT, SIEMENS, UH, UPC, VOGELLA, WINDTRE Submission date: June 2017 Dissemination level: PU Project co-funded by the European Commission under the H2020 Programme. D1.4 Project standards and infrastructure document Abstract: This document describes the technological framework and scope as well as specifies the project standards and the development infrastructure in place. This document by the OpenReq project is licensed under a Creative Commons Attribution- NonCommercial-ShareAlike 4.0 Unported License. This document has been produced in the context of the OpenReq project. The OpenReq project is part of the European Community's H2020 Programme and is as such funded by the European Commission. All information in this document is provided "as is" and no guarantee or warranty is given that the information is fit for any particular purpose. The user thereof uses the information at its sole risk and liability. For the avoidance of all doubts, the European Commission has no liability is respect of this document, which is merely representing the authors view. © HITEC, TUGRAZ, ENG, UPC, VOGELLA, SIEMENS, UH, QT, WINDTRE Page 2 of 32 D1.4 Project standards and infrastructure document Table of Contents 1. INTRODUCTION ............................................................ 6 2. DESCRIPTION OF TECHNOLOGICAL INFRASTRUCTURE .....................................................
    [Show full text]