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: TMcCann
New Today: 0
New Yesterday: 69
Overall: 142364

People Online:
Visitors: 62
Members: 0
Total: 62

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 - Incident processes in QA/DEV/TEST environments?
 Forum FAQForum FAQ   SearchSearch   UsergroupsUsergroups   ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 

Incident processes in QA/DEV/TEST environments?

 
Post new topic   Reply to topic    ITIL Forum Index -> The ITIL Service Desk
View previous topic :: View next topic  
Author Message
joshinplano
Itiler


Joined: Jun 20, 2007
Posts: 24
Location: Dallas, TX

PostPosted: Thu Nov 05, 2009 2:47 am    Post subject: Incident processes in QA/DEV/TEST environments? Reply with quote

Does anyone here use their IM process and tool(s) for their DEV/TEST/QA environments?

Some of our Managers and Project Teams are wanting to use our Incident process and tool to start tracking problems in those environments. There has been a lot of downtime in those environments recently, and they believe that using IM will help remediate issues. They want to track both project/release related Incidents, as well as environmental Incidents.

The underlying problem is that if a release is pushed into those environments and something is wrong, a defect is opened in our defect tracking system. The project teams are not responding to those defects quickly, and so the environment sits dormant because the problem is not remediated.

I have tried to explain that, while it could make sense to monitor and use IM for environment related incidents (i.e. server down, etc.) it does not make sense to log defects in use our IM process or tool to track those.

I believe they should follow a process such as:

- Open defect in defect tracking tool
- Project Team analyzes issue and determines if its projected/release related or environment related
- If its project/release related they keep in their defect tracking tool
- If its environment related they open an IM in our IM tool

Any thoughts/input?
Back to top
View user's profile
Diarmid
Senior Itiler


Joined: Mar 04, 2008
Posts: 1884
Location: Newcastle-under-Lyme

PostPosted: Thu Nov 05, 2009 3:17 am    Post subject: Reply with quote

It has to be horses for courses. If the Incident Management tool has the quality required in the non-live environments, then it has to be worth looking at how to do it, especially if it also means they can ditch an inferior tool or even if they can integrate to their other tools.

The issue is largely about maintaining the correct management in place in each environment. I would suggest that they should not use your process but they could use your procedures, although they should probably modify them to meet their own management requirements.

Two approaches seem feasible, but they do depend on the capability of your IM tool and possibly on its licence restrictions.

One is to use a separate instance of the software and let them run it themselves.

the other is to use very clear cut categories/classifications or whatever to distinguish the different systems and have the service desk staff work with both environments.

If the same staff are servicing the live and non-live environments and systems then it makes sense to manage them all together in one system. After all today's development is tomorrow's live system and if it ends up late because it was not given the support priority it deserved. It is perfectly possible that a fix in test is more urgent than some live incidents and if this is true you need a system that manages it that way.
_________________
"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
Back to top
View user's profile Send e-mail
Timo
Senior Itiler


Joined: Oct 26, 2007
Posts: 295
Location: Calgary, Canada

PostPosted: Thu Nov 05, 2009 10:27 am    Post subject: Reply with quote

Aren't all these SW dev methodologies supposed to address areas like issues, incidents, etc? I bet you will find something that will suit your needs if you look in detail into whatever methodology is used by the dev team.
Back to top
View user's profile
rpmason
Senior Itiler


Joined: May 25, 2007
Posts: 105
Location: USA

PostPosted: Fri Nov 06, 2009 12:31 am    Post subject: Reply with quote

I looked at Josh's post and he didn't say anything about it being about software development. Even so, he very well might be describing SW dev.

Our data center has hundreds of pre-production environments on several platforms (mainframe, open systems, windows). We provide the infrastructure and (mostly) commercial-off-the-shelf applications. Our customers use the applications or develop their custom software on our infrastructure.

Josh, we use the same tool for all environments. The Environment field helps to keep it all straight. It's not unusual for a device or a service to be associated with several environments, so we assume the "highest" environment for priority and risk purposes. As always, your mileage may vary.
_________________
Ruth Mason
USA
Back to top
View user's profile
Ghulam
Newbie
Newbie


Joined: Oct 27, 2009
Posts: 2

PostPosted: Fri Nov 06, 2009 7:28 am    Post subject: Reply with quote

One problem faced in an organization i was at was that the help desk was helpless once an application went live - they just didn't know enough about it because of inadequate release management and insufficient understanding of the application. agreeing on the correct classifications and having (and using) agreed distinction between the configuration status of an application, i.e. acquired, development, in test, under QA, under uer acceptance testing, could go a long way in improving the help desks ability to support the application once it goes live. this does require quite a bit of organizational maturity though. the objectives of live environment upport personnel can be different from project personel and project environment users. this could be especially useful if known errors and resolutions during pre-produciton phase of the application are well documented in the the help dewsk tool.
Back to top
View user's profile
Brian1
Newbie
Newbie


Joined: May 23, 2008
Posts: 18
Location: Toronto, ON, Canada

PostPosted: Thu Nov 26, 2009 6:23 am    Post subject: Reply with quote

I would suggest looking at the way you do business today and based on that analysis determine the best course of action for your company. I have consulted at organizations where the user community was heavily involved in development therefore it made sense to call the SD and log incidents there. I have also seen organizations where IM and CM did not apply to pre-production and it was managed under a development methodology. And I have seen companies do nothing in the DEV/QA/TEST world. Really comes down to what your organization is willing to spend and the value proposition they get from the additional investment. FYI, if your developers are not doing this today be prepared for the battle cuz "they no like!".
Back to top
View user's profile
Timo
Senior Itiler


Joined: Oct 26, 2007
Posts: 295
Location: Calgary, Canada

PostPosted: Thu Nov 26, 2009 8:52 am    Post subject: Reply with quote

Ooh, another Canadian Very Happy
Back to top
View user's profile
Diarmid
Senior Itiler


Joined: Mar 04, 2008
Posts: 1884
Location: Newcastle-under-Lyme

PostPosted: Thu Nov 26, 2009 6:34 pm    Post subject: Reply with quote

Just to elaborate on what Brian1 said. Irrespective of how you handle dev incidents in the applications, it is a very good idea to fully manage the dev infrastructure whether it is the same groups that manage the live or not. Infrastructure being used to develop apps is live because you need its capacity and availability in order to perform the development to time.
_________________
"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
Back to top
View user's profile Send e-mail
Display posts from previous:   
Post new topic   Reply to topic    ITIL Forum Index -> The ITIL Service Desk 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.