[Search for users] [Overall Top Noters] [List of all Conferences] [Download this site]

Conference 7.286::digital

Title:The Digital way of working
Moderator:QUARK::LIONELON
Created:Fri Feb 14 1986
Last Modified:Fri Jun 06 1997
Last Successful Update:Fri Jun 06 1997
Number of topics:5321
Total number of notes:139771

4363.0. "Recommended bugs database" by IOSG::BILSBOROUGH (SWBFS) Mon Jan 15 1996 08:42

    
    Hi,
    
    In my department where we develop software we're looking at replacing 
    our bug tracking system.
    
    Can someone tell me what is the corporate recommended product (whether
    internal or external).  If internal how well supported is the dev. group
    (i.e. will they go away tomorrow)
    
    We're looking for easy updating, good reporting, storage of defect
    analysis information and be scaleable so it can handle over 10,000+
    bugs without dying.
    
    Ideally we'd like it to be linked into project management too so
    if it can handle storing requirements, linking them to func. specs.
    etc. too, that'll be a bonus.
    
    Thanks,
    
    Mike
T.RTitleUserPersonal
Name
DateLines
4363.1Mixed Environment...XDELTA::HOFFMANSteve; VMS EngineeringMon Jan 15 1996 10:3119
   There is no corporate-recommended product -- various organizations
   within Digital are making these decisions seperately.

   OpenVMS engineering and a few associated/interested groups are currently
   involved in an evaluation of various problem tracking products, and
   is considering using one of these products to replace the current QAR
   system.  Both internal and external products are under evaluation.
   There is also an evaluation of products -- with different requirements,
   loadings, targets and intended useage -- going on in MCS.

   As for the long-term stability of internal groups or even of external
   corporations, I don't think anyone can answer.  (OpenVMS is using a
   "software escrow" requirement as a hedge...)

   And speaking of requirements, you _will_ want to put together some
   sort of a requirements list or document...  (I can put you in contact
   with the keeper of the OpenVMS requirements document.)

4363.2Good ol' QARSTAR::JACOBIPaul A. Jacobi - OpenVMS DevelopmentMon Jan 15 1996 16:2712
>>>   OpenVMS engineering and a few associated/interested groups are currently
>>>   involved in an evaluation of various problem tracking products, and
>>>   is considering using one of these products to replace the current QAR
>>>   system.

    So far, the evaluations (several attempts) have been going on for 5-10
    years with out much progress that I have seen.  I'm still using QAR to
    respond to bug report.  Maybe one day this will change.


    							-Paul

4363.3PTRAWECIM::MCMAHONDEC: ReClaim TheName!Mon Jan 15 1996 16:511
    Try PTR. Contact Donna Drottar @ CONLON::DROTTAR. 
4363.4Try using CVPDQCAV01::CSUNDERBe Eco Friendly. Save LifeTue Jan 16 1996 02:239
    Mike,
    
    Try using CVPD. This is an application meant to maintain software metrics 
    including defect/bug details. It is developed using RALLY on VAX/VMS. 
    Read the conference FUTURS::CVPD for further details.
    	
    Good luck.
    
    Sunder
4363.5Outsiders...REFINE::MCDONALDshh!Tue Jan 16 1996 08:0747
    
    We (like other groups) headed off some time ago looking at replacement
    systems. In my opinion, the way to go is with external providers. Over
    the years we've watched (and suffered with) so many internally
    developed solutions either never meet their goals, grow stale and
    forgotten, or lose all support. Not necessarily through the fault of
    the "developers"... more due to a lack of corporate structure/funding/
    or because the tool was developed with specific needs for specific
    groups and not with flexibility in mind. 
    
    Defect tracking has become a real hot item in the outside world and
    there are a number of good competitors and all different scales,
    ranging from small yet highly extensible PC based systems to large
    monoliths that run the gamut of operating systems, interfaces, group
    functions and require months of consulting to implement and a mammoth
    budget.
    
    Some of the former:
    
       QUALIT Defect Manager  (nicely built on MSAccess, but still young)
       PVCS Tracker           (well publicized, somewhat lacking in flexibility)
    *  TRACK (by Soffront)    (large, dedicated customer base, very
                               flexible, SQL Server implementation out in a 
                               month... a very probable choice for us... in 
                               use/being implemented by other DEC groups.) 
    
    Some of the latter (corporate suites with defect tracking, help desks
                        "enterprise-wide engineering") :
    
       Qualteam by Scopus     (UNIX or NT servers, Oracle/Sybase/SQL
    			       Server, UNIX/Windows/NT/Mac GUI's)
    
       ClearQuality by Clarify (UNIX based, Windows/Mac/Motif GUI's, Oracle
                                or SYBASE)
    
    *   VANTIVE by VANTIVE     (UNIX or NT servers, Oracle/Sybase/SQL
    				Server, Windows/Mac/Motif/Win95, extensive
                                API for integration, VB scripting, all 
                                communication via RPC's to minimize net
                                traffic. This would be a clear choice if
                                we decided to go the "total integration 
                                route"... and had an unlimited budget.
    
    
    								- Mac
    
           
4363.6Do you think Boeing CC's get free airplanes?KAOM25::WALLDEC Is DigitalTue Jan 16 1996 12:1422
    Now you've hit on something.
    
    If, when we used an internal product we had to transfer a few DECbucks
    from one CC to the developers CC, we might have more viable products -
    with less expense in "real $$$".
    
    ex.
    [no I don't have all the facts, and yes this is an old horse but...]
    DECWrite.
    If each CC with workstations and DECWrite PAKs had ante'd up 10 or 20
    DECbucks a year per, corporately we might have had...
    1 A funded DECWrite group.
    2 ...which was more responsive to "internal comments/requests".
    3 A marketable product.
    4 Less expense associated with MS Word etc.
    5 Maybe by now MS Word would support our DECWrite DOC style, and we'd
    get royalties from them (that is a stretch, and probably for more
    reasons than I know!)
    
    Rob Wall 
    
    
4363.7TINCUP::KOLBEWicked Wench of the WebWed Jan 17 1996 19:523
And in MCS(SRR) we have to use IPMT. For our personal use my
group uses notes for bug tracking but once we are in
production they have to be entered in IPMT. liesl
4363.8PTR Problem Tracking and Reporting SystemENGPTR::ANDERSONThere's no such place as far awayMon Jun 17 1996 12:36143
    WHY DID YOU RECEIVE THIS MEMO...
	In case you need to track and manage problem reports, we want 
	to be sure that you know about PTR.  We also want to be sure 
	that you have enough information to access it to see if it meets 
	your group's problem management needs.


    WHAT IS PTR?
	PTR (Problem Tracking and Reporting system) is a tool that lets 
	Engineering groups and their field test partners enter and track 
	problem reports.  It runs on the World Wide Web and reads and 
	writes to a relational database.


    WHO DEVELOPED PTR?
	The PTR Development Team is physically located in ZKO.  We are 
	part of the Systems Business Unit CIO (Chief Information Officer) 
	group.  The SBU CIO group is part of the Information Services 
	(IS) organization which supplies and maintains the information 
	systems that run Digital's business operations.  The SBU CIO 
	group is specifically chartered to provide information systems, 
	of which PTR is one example, to the Product Management and Devel-
	opment (PM&D) organization within the SBU.  But PTR is available 
	for use company-wide.

	PTR has been developed to provide a supported problem management 
	system to replace the old QAR system and various other unsupported 
	tools currently in use.  PTR is currently used by about 40 product 
	groups and has over 800 registered users.


    WHAT SERVICES DOES THE PTR DEVELOPMENT GROUP PROVIDE?
	We own and pay for the server hardware.  We provide backups for 
	the database on the server.  We provide production support for 
	the server processes.  We will continue to develop and enhance 
	PTR to meet end-user needs.


    WHAT DOES PTR COST?
	Nothing.  PTR has been developed as a shared solution to be used 
	by engineers to make it easier to enter and track problem reports.


    WHAT CAN PTR DO?
	PTR V1.2 allows Digital engineers, internal users, and external 
	field test customers to enter cases (problem reports) into the 
	PTR database, update cases, assign and reassign cases to the 
	appropriate engineers, track the progress of specific cases, and 
	answer and close cases.  Users can obtain selected case statis-
	tics directly from PTR and they can export problem data to Micro-
	soft Access or Excel to use the report-generating and graphing 
	capabilities of those tools.

	PTR's primary interface is a World Wide Web interface.  It can 
	thus be used from any system or PC with a Web browser (such as 
	Netscape or Mosaic) and a network connection.  External field 
	test customers can access PTR via the Internet.  PTR also sup-
	ports a mail interface which allows PTR users to perform most 
	PTR functions via electronic mail.

	IPMT (the MCS call-escalation system) can forward cases to PTR 
	and automatically get responses back from PTR.

	The PTR group maintains all problem data in a central database.  
	Protection mechanisms ensure that each user only has access to 
	authorized products and problem data.


    FUTURE DEVELOPMENTS
	PTR V2 is currently under development.  PTR V2 will satisfy a 
	rich set of user requirements we have gathered from current PTR 
	users and prospective new users.  You will be able to run the 
	PTR server and database on your own hardware if you want--or you 
	can still use ours.  PTR V2 will provide richer report-generating 
	capabilities, make it easier for development groups to manage their 
	own problem data, allow transfers of problem reports between groups 
	(across the net if necessary), and provide richer protection mech-
	anisms.  In addition to supporting the Web and mail interfaces, 
	PTR V2 will support a command-language interface which allows use 
	from dumb terminals, dial-in lines, and batch procedures.  PTR V2 
	will still maintain a bridge to IPMT and any successor systems.  
	Expected availability of PTR V2 is early fall.


    IF YOU WANT TO EVALUATE PTR IN DEPTH...
	Contact us.  We will set up a PTR User Profile and Product for you 
	to use in your evaluation.  You will be able to then administer the 
	product--adding new User Profiles and Components for that Product 
	only.


    IF YOU JUST WANT TO TRY PTR OUT ON YOUR OWN...
	The URL is:

	    http://engptr.zko.dec.com:8030/~ptr_docs/ptr_login.html

	Enter: 	Guest		as your account name

	Enter: 	GUEST		(all upper case) as the Password

	The password is case-sensitive.

	The GUEST account can access two product areas: The DEMO product 
	area and the PTR Product area.

		You can use the DEMO product as a place to enter 'dummy' 
		cases - just to get a feel for how PTR works.

		You can use the PTR product area as a place to enter 
		suggestions for improving PTR or any bugs in PTR itself 
		that you may come across.


    IF YOU WANT TO USE PTR RIGHT NOW...
	Contact us.  We will explain PTR in detail for you and we can 
	discuss migrating your existing Problem Report information into 
	PTR.


    IF YOU WANT TO LEARN MORE ABOUT PTR...
	You can read the online PTR documentation which is listed under 
	"Other Information" on PTR's main screen, or you can contact 
	Marianne Anderson at ENGPTR::ANDERSON, DTN 381-1389.

	If you want to learn about PTR V2 plans or read the functional 
	specification, contact Bert Beander at ENGPTR::BEANDER, DTN 
	381-2105.


    PLEASE LET US KNOW WHAT YOU THINK...
	...via the WEB/PTR itself--enter the Guest PTR account.  Select 
	PTR as your Product.  Enter your comments.  (Be sure to identify 
	yourself in the Dialog Text!)

	...via Mail--Send mail to Marianne Anderson at ENGPTR::ANDERSON


    THANK YOU!

	The PTR Development Team.