Can you identify root cause for a sofware bug without testing a fix in all cases?
[ 0 ]
[ 0 ]
[ 0 ]
Total Votes : 0
Joined: Jul 07, 2009 Posts: 1
Posted: Wed Jul 08, 2009 3:15 am Post subject: Software Maintenance as PM - root cause or fix
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.
Joined: Sep 16, 2006 Posts: 3536 Location: London, UK
Posted: Wed Jul 08, 2009 3:29 am Post subject:
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
verifies and closes all related PM/ IMs _________________ John Hardesty
ITSM Manager's Certificate (Red Badge)
Change Management is POWER & CONTROL. /....evil laughter
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