Map
Index
Random
Help
Topics
th

Topic: bug tracking system

topics > computer science > programming > Group: software maintenance



Group:
coordination system
Group:
debugging

Topic:
bugs
Topic:
commitment as a system
Topic:
examples of coordination systems
Topic:
management of large software projects
Topic:
programming environment
Topic:
software change management

Subtopic: productivity up

Quote: MONSTR improved project productivity with an orderly flow of information and responsibility among cooperating individuals [»knobK9_1981]

Subtopic: managing software maintenance by requests up

Quote: maintenance should be driven by the set of modification requests currently outstanding [»knudDB_1976]
Quote: all changes to #5ESS initiated by an Initial Modification Request to ECMS; implemented as deltas for one or more modification requests [»perrDE4_1998]
Quote: a Feature is the fundamental unit of system functionality; a set of Initial Modification Requests (IMRs) implements a Feature; one IMR to hundreds; may include hardware [»puruR6_2005]
Quote: an Initial Modification Request is implemented by a set of Modification Requests; one developer per MR, multiple IMRs and MRs per developer [»puruR6_2005]
Quote: features and change history managed by the IMR Tracking System; MRs and changes managed by the Extended Change Management System [»puruR6_2005]

Subtopic: workflow, bug state up

Quote: MONSTR illustrated the different states of software and the organizational division of responsibility [»mcgoMJ7_1983]
Quote: dispatching a MONSTR trouble report automatically sends it to the next organization in its protocol [»cashPM11_1979]
Quote: with a protocol, MONSTR can track trouble reports exactly, both inside an organization and in transit [»cashPM1_1980]

Subtopic: fault analysis up

Quote: fault analysis of the first 13 releases of an inventory tracking system; 500,000 lines of code, mostly Java [»ostrTJ7_2002]

Subtopic: bug tracking as conversation up

Quote: a MONSTR trouble report includes the record of a continuing conversation about the problem [»cashPM11_1979]
Quote: an automated trouble reporting system discouraged trouble-shooting conversations to identify the problem and its solution; ended up working around the system [»sachP9_1995]
Quote: the receiver of a software trouble report needs to know who sent it, under what authority, and what is expected [»holtAW11_1981]
Quote: MONSTR can report overdue responses to a trouble report [»cashPM11_1979]
Quote: may need to bundle software trouble reports to implement an ad hoc protocol; e.g., if part of a discussion [»cashPM11_1980]

Subtopic: bug tracking by routing up

Quote: automatic filtering/routing of email is immensely valuable; especially for advisory and bug-handling organizations [»boreNS9_1988]
Quote: the bboard andrew.gripes is heavily subscribed and a free-for-all; not useful for the Andrew Support Group [»boreNS9_1988]

Subtopic: bug sorting up

Quote: Andrew's Advisor system first tried automatic filing of messages by subject; 50% misclassification, too cluttered [»boreNS9_1988]
Quote: Andrew's Advisor system now sorts incoming mail by day; students process one day's messages and cross-post those they miss [»boreNS9_1988]
Quote: with human message sorting, Advisor can use fine-grained helpboxes that contain real requests; high-content and worth reading [»boreNS9_1988]

Subtopic: bug owner up

Quote: a trouble report is accepted on behalf of an organization but an individual is responsible; the acceptor's name is tracked [»cashPM1_1980]
Quote: a MONSTR trouble report always has an owner after someone accepts it; only the owner may alter it [»cashPM11_1979]
Quote: if the owner of a trouble report accepts a patch proposal, MONSTR will allow access to the relevant files [»cashPM1_1980]

Subtopic: related bugs up

Quote: MONSTR can report related trouble reports [»cashPM11_1979]

Subtopic: derived bugs up

Quote: Initial Modification Request closed after approval of its Modification Requests; a feature is done when all its IMRs close
Quote: a trouble report can be split into two with the original optionally cancelled [»cashPM1_1980]

Subtopic: canceling a bug up

Quote: MONSTR will not cancel a trouble report until the receiver agrees and all waiting organizations are notified [»cashPM1_1980]

Subtopic: other bug types up

Quote: a notice is like a trouble report without a protocol; either modification or cancellation [»cashPM11_1979]
Quote: a frozen trouble report can not be altered [»cashPM11_1979]

Subtopic: logging up

Quote: keep a running log to recover history of unrecoverable errors [»akscRM9_1984]

Subtopic: bug metrics up

Quote: half of Apache bugs are resolved within a day; much faster close times for high-priority problems; Mozilla much slower [»mockA7_2002]

Subtopic: problems with bug tracking up

Quote: once a user has processed a MONSTR report, no way to send a follow-up message about the same report [»knobK9_1981]
Quote: MONSTR globally classifies trouble reports; heavy users wanted a local classification scheme for organizing their work [»knobK9_1981]
Quote: high numbers of killed or no_change modification requests indicate poor MR quality; waste of time
[»eickSG4_2002]

Related Topics up

Group: coordination system   (8 topics, 217 quotes)
Group: debugging   (10 topics, 333 quotes)

Topic: bugs (66 items)
Topic: commitment as a system (22 items)
Topic: examples of coordination systems (23 items)
Topic: management of large software projects (63 items)
Topic: programming environment (46 items)
Topic: software change management
(48 items)


Updated barberCB 3/05
Copyright © 2002-2008 by C. Bradford Barber. All rights reserved.
Thesa is a trademark of C. Bradford Barber.