Software Support Process
From UG
(Difference between revisions)
(→Step 1. Perform Initial Analysis) |
(→Step 1. Perform Initial Analysis) |
||
| Line 80: | Line 80: | ||
* analyze request | * analyze request | ||
* interview user/ ask for additional info if required | * interview user/ ask for additional info if required | ||
| + | * consult Mantis to see if this bug is already posted to mantis (if this is a bug) | ||
* try to reproduce (if this is a bug) | * try to reproduce (if this is a bug) | ||
* try to re-solve if possible (if this is not a bug) | * try to re-solve if possible (if this is not a bug) | ||
* provide user with workaround if possible (if this is a bug) | * provide user with workaround if possible (if this is a bug) | ||
| - | * make sure it is a bug, not a change | + | * make sure it is a bug, not a change - consult wiki to see if system behaves as defined in spec (then it is not a bug) |
=== Step 2. Create Bug Report === | === Step 2. Create Bug Report === | ||
Revision as of 18:46, 27 March 2010
Contents |
Intro
CT2 Support Operation covers:
- Maintenance of existing system (upgrades, backups, monitoring, etc)
- Help Desk operation
- Etc
Help Desk requests can be classified into:
- bug reports
- new feature or change request
- create new user / client company request
- general questions and misc
Diagram
See #Figure 1.
Help Desk Level 0 and 1
Help Desk Work flow for any requests coming from Non NY Office Jaguar Users
- Contact Local CT2 Liaison (Level 0).
- (If can not be resolved escalate to Level 1)
- ihelp@jaguarfreight.com (Rob, Denise) (Level 1).
- (If can not be resolved escalate to Level 2)
Help Desk Work flow for any requests coming from NY Office Jaguar Users OR from Client Users
- ihelp@jaguarfreight.com (Rob, Denise) (Level 1).
- (If can not be resolved escalate to Level 2)
Help Desk Level 2
- Marc Selter (Director of Operaions)
- (If can not be resolved escalate to Level 3)
Help Desk Level 3
- Paul - handles server issues, firewall issues, etc
- Tira - handles issues related to Ops Pdfs, Client, Acc Sales modules
- Alex - handles issues related to Ops Reps, Ops, Acc Non Sales modules
All urgent issues must be handled at this level. high, medium, low could be escalated to Level 4.
Help Desk Level 4
Resources
- Level 4 engineer A (Andrei)
- Level 4 engineer B (Roma)
Response times
- if priority is high then same day or morning of the next working day
- if priority is medium then 24 hours
- if priority is low then 48 hours
Responsibilities and Workflow
- Issues are coming through email from Level 3 engineers
- Add link to this issue from 0001893:Support Level 4 tasks (Kiev) ...... <parent mantis> (this might be abolished in the future, now it is mandatory)
- By this time most of issues have mantis
- Create mantis if no mantis exists
- Read "e-mail trail", read mantis, understand request
- Email back questions as required
- Once solution / resolution found respond by e-mail
- E-mail back to Level 3 (this might change)
Bug Reports
Step 1. Perform Initial Analysis
To be handled by Level 0 and 1.
- analyze request
- interview user/ ask for additional info if required
- consult Mantis to see if this bug is already posted to mantis (if this is a bug)
- try to reproduce (if this is a bug)
- try to re-solve if possible (if this is not a bug)
- provide user with workaround if possible (if this is a bug)
- make sure it is a bug, not a change - consult wiki to see if system behaves as defined in spec (then it is not a bug)
Step 2. Create Bug Report
To be handled by Level 0 and 1.
- Bug Report must have:
- good summary (one sentence describing bug, this is how it will appear in Release Notes)
- good description
- steps to reproduce
- screen shots, etc
- always reproducible? (Y/N)
- priority / expected ETA defined
Step 3. Escalation (in some cases)
To be handled by Level 2.
Step 4. Create Mantis and forward to development
To be handled by Level 3.
- create mantis
- post into Bugs Inbox
Change Requests
Requests for Change should initially go to the module owners, and then discussed at The CT2 Board meeting since they may impact other modules. The Board will then decide if they are necessary and should proceed for design and development.
Figure 1
