Search
Topics
  Create an account Home  ·  Topics  ·  Downloads  ·  Your Account  ·  Submit News  ·  Top 10  
Modules
· Home
· Content
· FAQ
· Feedback
· Forums
· Search
· Statistics
· Surveys
· Top
· Topics
· Web Links
· Your_Account

Current Membership

Latest: JMuhammad
New Today: 20
New Yesterday: 65
Overall: 131777

People Online:
Visitors: 60
Members: 1
Total: 61 .

Languages
Select Interface Language:


Major ITIL Portals
For general information and resources, ITIL and ITSM World is the most well known for both ITIL and ITIL Books. A shorter snapshot approach can be found at ITIL Zone

Related Resources
Service related resources
Service Level Agreement
Outsourcing

Note: ITIL is a registered trademark of OGC. This portal is totally independent and is in no way related to them. See our Feedback Page for more information.


The Itil Community Forum: Forums

ITIL :: View topic - Software Maintenance as PM - root cause or fix
 Forum FAQForum FAQ   SearchSearch   UsergroupsUsergroups   ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 

Software Maintenance as PM - root cause or fix

 
Post new topic   Reply to topic    ITIL Forum Index -> Problem Management
View previous topic :: View next topic  

Can you identify root cause for a sofware bug without testing a fix in all cases?
Yes
0%
 0%  [ 0 ]
No
0%
 0%  [ 0 ]
not sure
0%
 0%  [ 0 ]
Total Votes : 0

Author Message
BlueKiwi
Newbie
Newbie


Joined: Jul 07, 2009
Posts: 1

PostPosted: Wed Jul 08, 2009 3:15 am    Post subject: Software Maintenance as PM - root cause or fix Reply with quote

Dear fellow ITers,

Synopsis: should root cause analysis on a software defect stop when a bug is pinpointed, or when a proven fix is created?

I've been tasked with implementing problem management for a complex set of software services our organization depends on. I'm trying to follow the ITIL framework, but keep wondering if software maintenance (finding bugs & fixing them) fits or not. One of our goals is to assign a cost to each fix and allow our customer to allocate limited resources to those fixes that matter most.

For example, can you really find a root cause (usually a defect) and then do an accurate estimate without actually testing a fix? Sometimes you may find the root cause and the fix is as simple as changing a constant in the code. At other times it may be a complex set of conditions under which a certain piece of code gives the incorrect result - but that code works for 99 other use cases. Root cause analysis can take some time, and you can't really say you have a good proposed fix until you write it and regression test the code. In such a case, should you stop, risk an estimate, and go back to the customer before you write a fix? If you don't you may end up spending a lot of time testing a fix to a problem which the customer might say wasn't worth that much time to fix.

1. Have you found it practical to identify a location of a bug, and then do estimates to fix it, before testing a fix?

2. Is a problem a Known Error once the root-cause is found and a workaround proposed - before a permanent fix is found or applied?

I'd appreciate any input from those who are using ITIL methodologies on software maintenance. I've been told it fits, but I'm not quite sure.
Back to top
View user's profile
UKVIKING
Senior Itiler


Joined: Sep 16, 2006
Posts: 3261
Location: London, UK

PostPosted: Wed Jul 08, 2009 3:29 am    Post subject: Reply with quote

You have to go outside the box

You need software development lifecycle and defect management - not in ITIL

here is the flow

Application is LIVE
A user finds a fault - Incident raised
the incident is examined whether it is a fault, user error (operator headspace / needs training), performing as function.

If it is a fault, then IM needs to restore service.. if NOT, IM ticket stays open unless there is work around
If it is a fault, then it has to be looked at by PM or Applicaton support to determine whether this is a Bug fix to resolve or a fix that will be dealt with when the new version comes in (design and build)

Then PM pushes this to the correct development

The IM ticket remains open (inactive or whatever) as the service is not working.
the PM ticket remains open until fix is deployed

the app dev team develops the fix or release
tests the fix / release
goes to CM Board
deploys
verifies and closes all related PM/ IMs
_________________
John Hardesty
ITSM Manager's Certificate (Red Badge)

Change Management is POWER & CONTROL. /....evil laughter
Back to top
View user's profile
Display posts from previous:   
Post new topic   Reply to topic    ITIL Forum Index -> Problem Management All times are GMT + 10 Hours
Page 1 of 1

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum

Powered by phpBB 2.0.8 © 2001 phpBB Group
phpBB port v2.1 based on Tom Nitzschner's phpbb2.0.6 upgraded to phpBB 2.0.4 standalone was developed and tested by:
ArtificialIntel, ChatServ, mikem,
sixonetonoffun and Paul Laudanski (aka Zhen-Xjell).

Version 2.1 by Nuke Cops 2003 http://www.nukecops.com

Forums ©

 

Logos/trademarks property of respective owner. Comments property of poster. Rest 2004 Itil Community for Service Management & Foundation Certification. SV
Site source copyright (c)2003, and is Free Software under the GNU / GPL licence. All Rights Are Reserved.