Trouble Ticket Management Software
✅ Paper Type: Free Essay | ✅ Subject: Information Technology |
✅ Wordcount: 4997 words | ✅ Published: 23rd Sep 2019 |
Trouble Ticket Management Software
Table of Contents
- Business Background.…………………………………………………………………….…….3
- Project Overview….………………………………………………………………………………3
- Project Objective Statement….…………………………………………………………………5
- Deliverables….………………………………………………………………………………… 5
- Technical Requirements…………………………………………………………………………9
- Functional Requirement…………………………………………………………………………10
- Use case Scenario….……………………………………………………………………………14
- Context Diagram….…………………………………………………………………………….14
- Decision Matrix….………………………………………………………………………………14
- User Input Form….………………………………………………………………………………16
- How the project will improve Current process………………………………………………….19
- Transitioning….…………………………………………………………………………………19
Business background
Our company Point Technologies is emerging with important projects and valuable clients. When there is an issue with the system, manually creating and tracking tickets are very complex. The company needs a software that helps in resolving the employee’s system related problems and to make sure there is continuity in the business process. Problems with the system might be an installation issue, hardware, software, or any other system related issues. Various departments in the company can use this trouble ticket management software and can be benefited with this software.
Project Overview
Trouble Ticket Management Software resolves and tracks the system related issues in the company. The processes involved with the software are described below:
- A trouble ticket is created using an employee identity number. This software automatically fetches all the employee details like name, building, email id, telephone number, department, cubicle number from the database.
- In create ticket home page, employee can fill the type of problem, severity, description of their problem in words and the ticket is then submitted using the submit button.
- The dispatcher assigns the created tickets to the support employees.
- The support team employee’s login page will contain the ticket number, details that were entered in the create ticket home page, two drop down fields, one to enter the status of the tickets and other to enter the severity of the problem.
- Assigned support employee will reach through phone, communicator or come in person to resolve the ticket.
- Employees can check the status and the history of their created tickets.
- When the ticket stays in the bucket for a long time, the reminder emails are sent to the concerned support team employee to work on the issue.
A ticket that created by the employee goes through the following status in the table before it is resolved and closed:
Ticket Status
|
Description |
Create |
Employee creates a trouble ticket when there is an issue with the system. |
Assign |
The dispatcher assigns the created tickets to the support employees. |
In progress |
When the support employee starts to work on the issue, the ticket status changes to in progress. |
Closed |
Once the issue is fixed, the ticket is moved to closed status. |
Reopened |
Ticket is reopened when the issue is closed before resolving it or if the same issue exits even after being fixed. |
Project Objective Statement
The project’s main objective is to create a Trouble Ticket Management software with a budget of $688,152 to be completed within the period of one year and seven months (October 1, 2018- March 6, 2019).
Deliverables
- Requirements document
- Project charter
- Use case diagram
- System design Specification
- Decision Matrix
- User Input Form
- Software code modules for the following:
Home page with fields – Identity number, name, building, email id, telephone number, department, cubicle number.
Create page with fields – Type of problem, severity of the problem, description of the problem in words and submit button.
Support employee login page – Ticket number, details entered in create home page are fetched and displayed, dropdown to enter the status of the tickets.
Ticket cycles (create, assigned, unassigned, in progress, resolved, reopened, closed).
Ticket status reports (daily/weekly basis).
Reminder emails for pending tickets.
- Test cases
- Test plan
- User guide manual
Milestones: (October 1, 2018 – March 6, 2020)
Project Start date: October 1, 2018
Milestone 1: Requirement analysis phase |
Planned Date |
Requirement Analysis signed off between business and development Manager |
October 10, 2018 |
High level design finalized by Architect/Development lead |
October 11, 2018 |
Detailed level design finalized and approved by the Architect |
October 15, 2018 |
Prototype model prepared by the Development lead and approved by the Architect |
October 16, 2018 |
Development team lead discussed with the team and user experience designer |
October 18, 2018 |
Project Manager informed the project plan, planned date to the business |
October 19, 2018 |
Milestone 2: Design phase |
Planned Date |
Use case diagram finalized by the Architect |
November 2, 2018 |
Application user interface approved by the Architect |
December 10, 2018 |
Database tables created by Database Administrator based on the input from Development team |
December 24, 2018 |
Entity relationship approved by the Architect |
December 28, 2018 |
Milestone 3: Development & Testing phase 1 |
Planned Date |
Software coding modules are developed for the home page with the following fields – identity number, name, building, email id, telephone number, department, cubicle number. |
December 20, 2018 |
The Development team performed Unit testing |
January 2, 2019 |
Phase 1 release available for the testing team |
January 20, 2019 |
Testing team performed user interface testing and functionality testing |
February 10, 2019 |
Defects fixed by the development team |
February 28, 2019 |
Phase 1 release certified by the testing team |
March 6, 2019 |
Milestone 4: Development & Testing phase 2 |
Planned Date |
Software coding modules are developed for the create page with the following fields – identity number, type of problem, severity of the problem, type description of the problem in words and submit button. |
March 30, 2019 |
The Development team performed Unit testing |
April 10, 2019 |
Phase 2 release available for the testing team |
April 20, 2019 |
Testing team performed user interface testing and functionality testing |
May 18, 2019 |
Defects fixed by the development team |
May 30, 2019 |
Phase 2 release certified by the testing team |
June 15, 2019 |
Milestone 5: Development & Testing phase 3 |
Planned Date |
Software coding modules are developed for the login page with the following fields – ticket number, details entered in create home page and fetched and displayed, two dropdowns to enter the status and severity of the tickets. |
October 30, 2019 |
The Development team performed Unit testing |
September 20, 2019 |
Phase 3 release available for the testing team |
September 29, 2019 |
Testing team performed user interface testing and functionality testing |
October 15, 2019 |
Defects fixed by the development team |
October 29, 2019 |
Phase 3 release certified by testing team |
November 5, 2019 |
Milestone 6: Development & Testing phase 4 |
Planned Date |
Software coding modules are developed for the various status cycles (create, assign, in progress, closed, reassigned), reports (excel, pdf, html) and remainder emails |
November 25, 2019 |
The Development team performed Unit testing |
December 1, 2019 |
Phase 4 release available for the testing team |
December 10, 2019 |
Testing team performed user interface testing and functionality testing |
December 25, 2019 |
Defects fixed by the development team |
December 29, 2019 |
Phase 4 release certified by the testing team |
January 2, 2020 |
Milestone 7: Final product release |
Planned Date |
Testing team certified the final product |
January 4, 2020 |
Maintenance team is trained |
January 5, 2020 |
Application is deployed into production |
January 8, 2020 |
End and Maintenance user support provided |
March 6, 2020 |
Project end date: March 6, 2020
Technical Requirements
- Application will be developed using Java Enterprise Edition 7, MySQL database and Apache Tomcat as Application Server.
- MS office 2013 package is required for creating documents like requirements document, test plan, requirement traceability matrix and user guide.
- Use case diagram for the project will be created using Visio.
- Company’s standard templates are required for preparing root cause analysis document.
- HP Quality center is required for writing and executing test cases.
- Development center with bring your own device or enterprise desktops.
- All licensed software required for development to be installed.
- Hire user experience designer for creating interactive application.
- Hire developers with Java coding experience.
- Hire testing team with manual testing experience.
- Maintenance/Support team.
- Developer/ Tester issue tracker.
- Team leads for development, testing and maintenance/support teams.
- Reports to be generated in excel, pdf, html formats.
System Specification Document
Functional Requirements
• Staff individuals must have a remarkable login and secret word that they, and just they approach.
• Staff can raise changes to pending hell tickets dependent on their set level of access.
• Staff must have the capacity to make and open their very own tickets.
• Any data about tickets must be held secret to the individuals who relate to it.
• Logs of all issues found must be kept for measurable purposes.
• The client will have the capacity to check the status, and history of any ticket that was
prepared.
• The framework will have a correspondence work for staff to have the capacity to address
help work area staff.
• The framework will have a strong security work, in house and outward.
• Users will get an email each time a change is made to a pending ticket.
• Modifications to any tickets must be quick and basic.
• Logs must be kept of goals to all issues for future examples.
• Tables must be made for each ticket, including: Employee Name, PC ID, Problem, and Resolution. • Database must be fit for performing inquiries, for snappy searches. • Deletion of any records might be performed by IT Director37
Non-Functional Requirements
• The issue that the Newark Public Library was having was that their Help Desk repairs were taking too long. It is thus that reliability has been put as a primary necessity. On the off chance that Rapid Resolve bombs, at that point it will cause express bedlam inside the complex.
• Our framework must be online, rather than an in-house programming program, in view of the way that if a mistake occurs inside our framework, it very well may be amended rapidly, and without having to re-get to every one of the machines in which, the product was introduced.
• Maintenance and changes to the program ought to be basic enough to be made by the IT Director to suit the requirements of the library.
• The product must be easy to use; in this way, all representatives can learn and work with the framework as fast as would be prudent. This diminishes down time, fills in as a learning device and expands worker mindfulness.
• Security estimates much be ensnared, to keep from hacking into the site. On the off chance that a programmer ought to ever get to the framework, they could change ticket status, or open new tickets for work to be performed on a machine that might be unsafe to it.
• In-house safety efforts should likewise be available. On the off chance that a representative needed to attack another worker’s work, they could basically put a ticket in to organize the hard drive on a PC.
Systems Specifications
The Rapid Resolve System was structured exclusively for the utilization of the Newark Public Library. The product that they are right now utilizing is causing exorbitant downtimes, and does not consider every one of their needs. The reasoning behind the Rapid Resolve System was to permit every one of the gatherings that are engaged with the issue to view, change, and resolve open inconvenience tickets.
1.) This framework will enable clients to open an inconvenience ticket when they are having a pc issue.
• The client will sign into the framework with an issued username and secret word.
• Access levels will be resolved and actualized by the IT Directors.
2.) The framework will be joined by a solid database.
• The client will sign into the framework where all data relating to them and their gear dwells.
• The database will be made utilizing SQL, a somewhat simple to-utilize, yet extremely successful program.
3.) We, the makers of the Rapid Resolve System have chosen to utilize C++, Dreamweaver, and SQL. These dialects will be utilized to fabricate a framework that will perform productively, rapidly, and accurately.39
• C++ will be utilized to structure the foundation of our framework. It will play out all estimations, and rationale works in an opportune way.
• Dreamweaver will make the website pages, and layouts for framework
• SQL will be utilized to anchor the database.
4.) obviously, since our framework will be fresh out of the box new, and not have similar capacities or work the equivalent as another other help work area program out there, a type of preparing should be built up.
• Our framework is somewhat shortsighted and straight to the point, an instructional course of one day will be built up. There is the place the representatives will figure out how to:
Make tickets
Change tickets
Talk with Help Desk Personnel Retrieve shut tickets
Check status on open tickets Etc.
5.) Since this an online program, on framework requirements are minimal. • Windows 95, proportionate, or higher as a working system• Minimum 32 MBs of RAM• Minimum 2 GIG hard drive space40
• Minimum 266 MHz processor
6.) The client will have the capacity to check the status, and history of any ticket that was handled.
7.) The framework will have a correspondence work for staff to have the capacity to address help work area faculty.
8.) The framework will have a strong security work, in house and in addition outward.
9.) Users will get an email each time a change is made to a pending ticket.
Use Case Scenario
Context Diagram
Decision Matrix
Elective considered:
1. Elective A – Buying a product officially accessible in market and is configurable as indicated by requirements
2. Elective B – Developing a product by getting a seller (for this situation Digi mission) and putting away information in cloud.
3. Elective C – Developing a product by getting a seller and introducing servers to store information.
Points available for each criterion: 5 points
Conclusion
Rapid Response decided to go ahead with Alternative B as it scored the highest points in decision matrix. The most important criteria were integration with existing system and Digi mission promises to compete best in that.
User Input Form for Help Desk Service
The Components of Forms
Structure
This incorporates the request of fields, the frame’s appearance on the page and the coherent associations between various fields.
Information fields
These incorporate content fields, secret key fields, checkboxes, radio catches, sliders and some other fields intended for customer input.
Field marks
These tell customers what the relating input fields mean.
Activity catch
At the point when the customer squeezes this catch, an activity is performed, (for example, accommodation of the information).
Input
The customer is made to comprehend the after effect of their contribution through input. Most applications and sites utilize plain content as a type of criticism. A message will inform the customer about the outcome and can be sure (demonstrating that the shape was submitted effectively) or negative (“The number you’ve given is wrong”).
Structures may likewise have the accompanying parts:
Help
This is any clarification of how to round out the frame.
Approval
This programmed check guarantees that the customer’s information is substantial.
The first Page would require User information to Log in to the Rapid Response Helpdesk system.
Option for letting end users submit tickets with forms
The Rapid Response Help Center provides end users with a default HTML form for submitting tickets:
How the project will improve the current business system
Coming up next are nevertheless some of help desk’s benefits:
- Automation of customer services
- Productivity and issue tracking
- Better perspective of clients’ information
- Better adaptability of framework
- Limits issue resolution time
Beside the way that Help desk solutions automate the client support process, there are more reasons why the organization should utilize these instruments.
The essential objective of Trouble Ticketing is to mechanize all parts of client support. The perfect help work area arrangement must have center abilities that incorporate an automation suite, announcing and streamlining and ticket management.
Supporting operators in diverting client inquiries and worries to capable staff is the key capacity of the automation suite. This capacity ensures that all tickets are reacted to rapidly, which is made conceivable via automated notifications
Maybe the most valuable component of Help Desk arrangements, ticket management allows enables managers to react to calls and log them effectively. It likewise enables agents to get and answer client criticism through web-based social networking.
Increase employee efficiency
This process involves generating reports on each agent’s qualities and shortcomings, so call supervisors can enable them to assign their work time more efficiently. Besides, it can abbreviate the expectation to by identifying areas where they require additional training based on the agent’s KPIs.
Coordinated telephone support likewise supports specialist efficiency. Time-saving tools like automatic ticket creation and customer profile screen-pops allow agents to focus on helping customers quickly, not on hunting down data or exploring different frameworks.
Obtain reporting and analytics metrics across channel.
Call information is basic for adequately dealing with a call center. All call focus programming gives aggregate data, for example, movement and call volume, yet managers additionally need to see how call information fits into multichannel tasks. A multichannel ticketing framework can help managers not just see how to enhance their telephone support tasks explicitly, yet can see how it fits into a multichannel support technique with centralized reporting.
How to transition this project.
A Lean IT approach could be valuable here. Dividing the transition project in steps and attacking those steps one by one. Keeping everything as basic as could be expected under the circumstances, while making a rundown of the requests that are needed and the ones that are required. Attempting to involve all parties that are concerned by this change process.
Our academic experts are ready and waiting to assist with any writing project you may have. From simple essay plans, through to full dissertations, you can guarantee we have a service perfectly matched to your needs.
View our servicesFrom the requirements that have been chosen, we would now be able to choose which service management (ITSM) provider and which solution to select, with the assistance tool like a decision matrix. The rule behind a decision matrix comprises in weighting the decision criteria dependent on their significance and to rate every alternative (ITSM supplier or potentially arrangement) on those criteria. The choice that gets the highest score turns into the alternative that should apply. Ensuring, in any case, to choose the right criteria for the framework, for the decision to be illustrative of the needs.
The transparency and communication between all parties involved by your project is essential to the good proceeding of your new implementation project and is vital for every good change management process. Training and involving the users of the new software early and throughout the whole change process is also a good practice to take in such a change process.
An Agile work method here can help you subdivide your projects and follow the evolution of the changes throughout the steps of the change management process. Think about using a KISS method as well, to help you determine which elements from your old helpdesk tool to Keep, Improve, Stop and which new element to Start.
All there is left to do is to continue. Set aside the opportunity to meet with groups, examine and ensure that everybody agrees and has a similar data about the changes. Discussion about the troubles that have been experienced amid the progress towards the new helpdesk, the up and coming executions and get the input from the managers. Along these lines, ensuring that individuals get the chance to learn and test the new set up.
References
- HUGHES, B. AND COTTERREL, M. 2002. Software Project Management. Third Edition, McGraw Hill. ISBN 0-07-709834-X
- O’CONNELL, F. 2001. How to run successful project III – The silver bullet. Addison-Wesley. ISBN 0-201-74806-1
- CCTA, 1998. Managing Successful Projects with PRINCE 2. Revised Edition, The Stationary Office. ISBN 0-11-330685-7
- Trouble Ticket Software that is easy to use. (n.d.). Retrieved from https://www.happyfox.com/software/trouble-ticket-software/
Cite This Work
To export a reference to this article please select a referencing stye below:
Related Services
View allDMCA / Removal Request
If you are the original writer of this essay and no longer wish to have your work published on UKEssays.com then please: