Don't have an account yet? You can create one. As a registered user you have some advantages like theme manager, comments configuration and post comments with your name.
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.
Search
Languages
Select Interface Language:
Advertising
Please contact us via the feedback page to discuss advertising rates.
The Itil Community Forum: Forums
ITIL :: View topic - Are defects found during development Problems or Incidents?
Posted: Thu Oct 16, 2008 4:12 pm Post subject: Are defects found during development Problems or Incidents?
When software defect is found by customers, it is reported to Service Desk and handled as an Incident (Fault). How about defects found during development? Are they handled by Incident Management, Problem Management or other process? Or Project Management? In other words, they are outside IT Service Management.
Joined: Mar 04, 2008 Posts: 1894 Location: Helensburgh
Posted: Thu Oct 16, 2008 5:01 pm Post subject:
Francis,
Defects found during development are nothing to do with service management because a program (or anything else) in development is not providing a service.
If you develop programs, you will have a development regime that controls how you perform your development function. _________________ "Method goes far to prevent trouble in business: for it makes the task easy, hinders confusion, saves abundance of time, and instructs those that have business depending, both what to do and what to hope."
William Penn 1644-1718
Joined: Mar 04, 2008 Posts: 1894 Location: Helensburgh
Posted: Fri Oct 17, 2008 5:14 pm Post subject:
fralaw wrote:
Does software development a service in the ITIL Framework?
ITIL is about service management. Essentially, Service Management assumes that software has been developed. Service Management becomes concerned with software when there is a proposal to introduce it into service. Then it has to be validated as to function, reliability, robustness, operability, compatibility, performance, etc.
Software development, on the other hand, (seeing this future validation ahead of it) has to be designed and tested to address these points if it is to succeed.
From the Service Management point of view, in-house software is much like bought-in software. However it would be prudent to create links with the in-house development function to help ensure the fitness of the software products without going through costly iterations, and without costly accommodations by the infrastructure for example.
In other words it is good to develop integrations within the organization, but the processes for control during development have to be appropriately designed for that purpose and should not impinge on Service Management which has its own role in the real world.
This is not to say that the same software might not be useful (although I would expect software designed for the purpose would normally be a better bet), just that you would use a separate instance and you would not use Service Management staff to manage the processes.
When Service Management staff are at the coal face doing their day to day job, they care not a jot about what is going on in development and in fact the development department is probably one of their customers in terms of keeping their servers and networks running. _________________ "Method goes far to prevent trouble in business: for it makes the task easy, hinders confusion, saves abundance of time, and instructs those that have business depending, both what to do and what to hope."
William Penn 1644-1718
Stuff found and fixed during development stays outside Incident and Problem Mgmt. After all, these ITSM processes focus on IT services in production, not on development or test.
However, there is one thing to keep in mind. Often, new or enhanced systems go live while the project that built it knows that there are some issues. The pressure to deliver on time is big and a few (not too major) errors here and there are then often foregiven. When these known issues make it into production, I would advise to track them through Problem Mgmt, either as a problem record (to drive investigation) or as a known error (if the root cause is already known). Any available workarounds should be documented along with these problems and known errors.
Doing this provides Incident Mgmt with visibility into all problems and known errors with their workarounds in the environment. Incidents triggered by these problems/known errors can be properly associated and resolved by using the workarounds. This approach also facilitates the hand-off from a development project to a standing maintenance organization. _________________ Manager of Problem Management
Fortune 100 Company
ITIL Certified
How does the development/issues live/incidents boundary apply to customers partaking in early adopter (aka beta II) testing? Does the 'service' start as soon as they receive software from you, or only when it is launched in their live environment?
Joined: Sep 16, 2006 Posts: 3574 Location: London, UK
Posted: Tue Jan 27, 2009 12:31 am Post subject:
Regardless of where the testing / qa / development defects is found...it is still development / testing and outside of Problem mgmt (operations) and inside in Software development lifec cycle _________________ John Hardesty
ITSM Manager's Certificate (Red Badge)
Change Management is POWER & CONTROL. /....evil laughter
Joined: Mar 04, 2008 Posts: 1894 Location: Helensburgh
Posted: Wed Jan 28, 2009 8:46 pm Post subject:
RT wrote:
How does the development/issues live/incidents boundary apply to customers partaking in early adopter (aka beta II) testing? Does the 'service' start as soon as they receive software from you, or only when it is launched in their live environment?
You build appropriate early adopter protocols specific to your project.
Whether and how these integrate or parallel your service protocols is absolutely down to specific cases and has to be fully planned and managed involving all parties affected. _________________ "Method goes far to prevent trouble in business: for it makes the task easy, hinders confusion, saves abundance of time, and instructs those that have business depending, both what to do and what to hope."
William Penn 1644-1718
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
Forum FAQ
Search
Usergroups
Profile
Log in to check your private messages
Log in
