User Documentation 2

The Galactic Customer IT Services is IT Support Company with over 250,000 employees with companies in 50 States with the main headquarters located in Gainesville, FL. The location chosen for the headquarters is based on a Telco Gateway Infrastructure that the main fiber-optic trunk line runs along the I-75 corridor, from Miami Lakes FL to the most northern part of Michigan. This I-75 corridor plays an important part of the Networking ability for the organization. The Galactic Customer IT Services is an IT support company, which provides IT support to various small to large companies both within the Unites States and support to various military bases overseas. This large customer service company has installed application software to its large Help Desk ticketing system.

The next phase to implement is the upgrading of its Networking Infrastructure. This Organization has several new updated Servers ready to install on the network. With the previous project being accepted the organization has decided to move forward to improving its networking infrastructure, however the organization has requested that the project team to draft a plan that requires the following in the plan: Requirements, Design, System Development Methodology, WBS (Work Breakdown Structure), Communications Plan, Quality Assurance Plan, Documentation Plan, and Quality Assurance and results of test-case execution be the project can be closed.

The project requirements will come from the software requirements for the Galactic customer services. The project was to create a new ticketing software that the customer wanted upgraded and to completely replace the previous product. The requirements are the following:

· Ticket system

· Ticketing automation forwarding system

· VoIP system for out of country calls

· Application that delivers automated workflow

· Application that handles auto-updates and simple to intermediate patches

The ticketing system that we have to create has to follow the design that the stakeholders and owners expect. A ticketing system that needs to be omni-channel supported, which is a type of support that gives the customer using the product the ability to utilize the application from any multiple sources. This includes phone, email, self-service ticket creation via application, and walk-in visits to the company itself. (Andrews, 2019)

This application requires a section that allows the system to process incoming tickets and to be able to route the ticket to the appropriate IT support personnel. This system will require the capability to allow the user to select in detail what their issue is, select the department the issue pertains too, and also select the level of importance the user the believes the issue is. However, the end-used will not decide the level of importance; the automated system will determine the level of importance by keywords located in the ticket and which section the ticket is for. (Andrews, 2019)

The VoIP telecommunication is crucial to the company’s success of providing adequate care to its overseas and out of state clients. Companies that must call into the main HQ in Gainesville, FL, do not want to spend the extra money for long distance phone calls. Instead the stakeholders have insisted on requiring an easier more cost-efficient way of telecommunication for the long-distance entities. VoIP will utilize a private VPN that will allow the client and HQ to speak directly with each other over the internet rather than use a phone company that will hike up prices of telephone usage. (Unknown, 2019)

The application portion of the software will be able to create self-service tickets while also being able to create and recommend updated software while providing the adequate information to patch the current software if needed. This is a valuable part of the software because it allows the end users the ability to fix issues and low-level problems themselves or have the automated service patch the issue if possible. Having that service will provide the client and the service provider to spend more time on conducting business as usual instead of losing time and money waiting to speak to an operator or having their ticket cleared.

.

Below is a design diagram that I did for the team project from the last course, as you see it was for an online ticketing application. As seen, you have customers that can communicate to the customer service group via the Internet, which will connect by way of a secure VPN that links to the online ticketing application, which connects to the ticket automation part of the system and sends tickets to customer service operators. As you can see the system is simple and yet can be complicated.

Drafted and Imported from my Smart Draw Software 16 November 2019

Now the team is working on the Networking portion for the organization. The organization will have to send out service technicians to customers for issues that are not resolved by remote access for customers that the help deck could not resolve. Even though the main hub is in Gainesville, FL there is a remote site in every State located in one of the major cities. Below is a diagram depicting a replica of the network that will connect all areas where trouble tickets will print for the service technicians

Drafted and Imported from my Smart Draw Software 16 November 2019

The ticketing application servers will be in Gainesville, Florida. The network will consist of Voice over Internet Protocols (VoIP), IP routing, DS3 lines to the ISPs (Internet Service Provider) HTML protocols will be in use and the HTTPS protocol. The Organization will be utilizing Secured Virtual Private Network services.

For the creation of our network that will work with the Galactic Customer Service unit we will implement the Waterfall methodology. This method is a slow starter but once it gets in the design and development stages it fairs great because of the long planning. The waterfall approach begins with multiple meetings that allows the stakeholders, owners, dev team, and customer to brainstorm and come up with detailed plans to ensure that the entire project is open for viewing from beginning to end. The reason for this choice is because the very detailed structured documentation of the project. (Rouse, 2019) This structure allows our group to follow step by step to ensure the success of the project and guarantee that nothing gets overlooked. The planning stage increases the efficiency of the project while allowing all avenues open to view. This is to include all risks and threat factors. During the planning stage, the group will come together to discuss probable/possible risks that could come along during the development stage. Once all factors meet satisfaction, then the plans made available to create a risk mitigation process. (Rouse, 2019) This will allow the team to know how to mitigate/avoid certain risks that come along.

Another factor in choosing this method is the fact that the personnel on the development team can be interchangeable. This means that if six people start the project and one or two decide to leave or let go, the process can continue as planned. This works well also if other people come in to fill those vacant position. It allows the process to continue as planned without a lag in the development process because of the detail in the plans. With the way our remote communication is set-up, communication issues are sure to occur. With that being said, the waterfall method is the appropriate choice based on the fact that the approach is our way of risk mitigation.

APPLICATION DEVELOPMENT METHODS 2

The system will utilize the use of automated response system which will always ensure that customers and vendors get real-time as well as proper company support using well-organized customer service. The applications design is in a way that whenever a customer logs into the system, there is an automatic query popping out prompting the customer to chat with the client about anything they may wish to enquire about the company.

Customer satisfaction is very essential; therefore, there is the need to properly track customer and client communication. To ensure there is monitoring, the application will have to always produce a copy of the communication between the companies; client and other users. This will easily provide an oversight authority for tracking the communications there; the business managers can check if the clients are useful to the business. This approach is very beneficial in determining if the application effectively provides customer satisfaction.

The alignment of stakeholders’ requirements and the applications design will ensure the organization has attained operational effectiveness. The organization will attain improved productivity if the customer service application is working properly (Lin, 2007).

Regarding the quality of communication, the application architecture, this is put together in model form in a way that response will give the preferred quality assurance to the customers by the utilization of automated systems. Using automated alert applications in the automation strategy will ensure that customers’ issues are properly and in time. Communication quality will enhance ability by ensuring every stakeholder’s requirements meet their expectations since different people have different interests. Additionally, it also aids in ensuring the right design gets put together properly.

The objective of our Quality Assurance plan is to create a product that has these qualities (Spacey, 2017):

· Stability

· Availability

· Reliability

· Timeliness

· Accuracy

· Durability

To ensure that our product meets those criteria, we have decided to implement these specific objectives to produce the best product for the customer. The objectives are as follows:

· Connection speed should allow fast VoIP connection and create and easy connection for customers/employees to utilize the ticketing system.

· Front-line employees should have adequate training on new network capabilities and its usage.

· Ticketing system should connect to the network within the building in approximately 30 seconds while the outside connectors should only experience a 1-minute delay depending on the connection speed of their internet service. **Allow for up to 2.5 minutes with a 50Mbps internet speed connection**

· Employees should be able to connect to the network 99.99% of the time.

· The new network should accurately (90%) deliver service to the customer service application to allow employees the ability to actively connect to satisfy their customer incident reports.

· Network should not experience any drops of service during business peak hours.

· Maintenance needs adequate training and have a 1-2-hour response time, either remotely or if need physically.

Our company is looking to provide a service that is 100% defect free. We will continue to monitor and test until the system is working at the levels that meet the customer’s requirements and our own.

After the objectives are in place it is time to put a QA team together. Once we have the team together, we will then assign roles. Each role has a specific duty that needs assigning to team members where they need to follow the detailed specifications outlined in the requirements and specification phase of the waterfall method (Unknown, 2018). The roles are breaking down in the following matter:

QA Manager (QAM): The QA Manager responsibility will be to supervise the actions of the members of his/her team. He/she is responsible for selecting the members of his team and providing them with the job assignment that fits their skill set. The QA Manager will be the person that is responsible for creating and disseminating the final report for the QA assessment.

Manual QA Engineer (MQAE): The responsibility of the MQAE is to develop the software/hardware needed in order to manually test components and/or separate sections of application software.

Test Automation Engineer (TAE): The responsibility of the TAE is to develop the software that will be using to conduct the portions of the system that run automatically.

Business Analyst (BA): Acts as the liaison between the upper management and the QA teams. Ensures that the application and the network it runs on is meeting expectations.

QA Analyst (QAA): The QAA is the person that goes beyond the testing and does an evaluation of the network. It’s often said that this member of the team goes off script to see if they can find anything that unusual with the product.

(Eisenberg, 2019)

In terms of coordination, this basically involves making sure that the QA plan does not overlap or contradict another plan in place. It is vital that we plan and check with other plans in the work such as risk management plan. The QAM will be responsible to ensure that the QA plan does not contradict another plan and vice versa.

The objective of the unit testing plan is to provide the team doing the testing the help needed in validating the quality of the software that is in the testing phase. It also helps those outside of the testing team like developers and others involved in the process. “In the test plan there are important aspects that are documented such as test scope, test strategy, and test estimation.” (Guru99, 2019) Unit testing is one of the levels of testing within a quality assurance plan. In my opinion it is the most important of all testing sequences. It is the first level of testing. The testing in done in individual units or components, whether it is software or any other type of product being in development. The main purpose of a unit testing plan is to validate each unit of a product or software meet what the design is to do.

Within the Unit Test Plan there are test cases that will need documenting and each one scheduled. I will show ten major test cases relating to this project shown in a table form.

Integration testing will test the integration of each module using the Bottom-Up Approach. This will test each module by testing each child module with the parent module. This will be an efficient way to find errors, bugs, and other problems between each module.

Regression testing will consist of two phases:

Phase 1 (Partial Test) – When a new update/feature when added to the system, the team will test the modules it directly affects. This will help identify early bugs and errors. If the test results in no errors, then the full testing won’t happen. If bugs/errors occur or if the system fails to operate after, we will proceed to phase 2 testing.

Phase 2 (Full test) – The system test, will help identify bugs/errors across the entire system

First, a quality metric is an objective measure of a product or processes quality. Using quality metric measurements will allow the user to quantify the quality of a product and or process, which is comparing it to a particular value. There are several quality metrics that developers use in the development of products, processes, and projects. The type of quality metric that the team will use in this project are as follows:

Product quality metrics

· Mean time to failure

· Defects

· Customer issues

· Customer Pleasure

Process quality metrics

· Defects during network testing

· Defect arrival pattern during network testing

· Phase defect removal

· Effectiveness of defect removal

The main source of input for system defects or irregularities will be the internal Quality Assurance Team, the idea is to catch any major defects with the system before the users of the system notice them. If a User reports a defect, it’s given a higher prioritization for repair than one reported by the internal team. This is to fix any issues in the practical function of the program, allowing business to continue to operate with minimal impact from system errors (Ivanova, 2019).

To assist the quality assurance team in their task of examining the system for potential defects, there are several formulae that will help compare the system’s current performance to ideal thresholds. These will also assist in informing other quality metrics like the total bug count, the defect removal efficiency rate or DRE and the Bug burn down (the projected amount of time to close out all remaining bugs in the system).

Tracking the DRE will show how effective the QA team is at removing bugs from the product before they effect the experience of the end user, represented as a percentage. The Calculations made by taking the number of bugs found in development and dividing that by all the bugs found in both production and development then multiplying by 100 to get the percentage of DRE (Arnold, 2019). Keeping track of this number will give a good representation of the team’s ability to get ahead of potential issues as well as provide valuable data on bug burn down, BBD.

BBD is a projection used to determine the potential length of time the QA team will need to research and fix open bug tickets, based on the average closure amount over the previous lifecycle of the project (Data, 2017). If there are 100 open bug tickets and after 5-weeks, 10-tickets closed per week, you could average it would take another 5 weeks to finish the bug tickets. If the project has a completion date within 4 weeks, you could use that project to assign extra resources to accomplish the task sooner.

Measuring the fixed defects percentage will also assist in tracking the success of the QA team in repairing the bugs reported by users or QA testers and should be under review by management to determine overall quality and success. Calculations made by dividing defects fixed by defects reported and multiply by 100 to get the percentage.

(Reichert, 2019)

The likelihood of damage, threat or hardship and some other mischief realized by inside or external liabilities is known as a risk. It is powerlessness where neither the probability nor the technique for occasion is known (Jacoby and Kaplan, 2013). Various sorts of risks can occur in an undertaking. These are; cost perils, plan threats, and the introduction risks. In spite of the way that there are others that can happen, these are the most generally perceived ones. Errand threats consolidate both internal perils and the risks which are insane.

Positive risk is a questionable circumstance that prompts a gainful result. A negative risk then again is one that outcomes in a misfortune (Doherty, 2000). Cost, execution, preparing, plan and legally binding dangers are on the whole negative dangers. They are dangers instead of chances

Utilized for recording risks, is a risk register, the guides made against that risk and the administration of each risk (Funtowicz and Ravetz 2010). The register is basic to fruitful administration of dangers. Likelihood and effect lattice are the way toward surveying the probabilities and significances of dangers when they occur. Each risk evaluated on its probability of event and the effect on a target on the off chance that it occurs. It very well may be in use in my task to characterize the degree of the dangers that can emerge and the likelihood against the outcomes of the dangers. It can combine both of the parts onto a similar scale.

Example:

A=high (rating 100)

B=medium rating (rating 50)

C=low (low rating 10)

Probability occurrence (in percentage)

A= 80-100

B= 60-80

C=30-60

D=0-30

Risk in a development project is unpreventable. As much as one may prepare totally, certain perils may happen due to unavoidable conditions. Perils either present minute or long stretch to the security of the people, prosperity and condition, are immaterial. This risk could either have a negative or constructive outcome on the endeavor if it occurs. It may have in any event one reason and besides at any rate one impact.

The strategy of risk management the board is a total commitment (Froot, Scarfstein and Stein, 2013). The legally binding specialists and the assignment group need to work inseparable to ensure that the vulnerabilities reduced or oversaw appropriately. The critical responses to risks join controlling, enduring, help, move, sharing, avoiding improving and abusing.

Purpose: Quality Management Review

Audience: Stakeholders, Client, and project Team Members

Details: This report will review the progress of all phases of the project.

Galactic Customer IT Services is an IT support company located in Gainesville, FL. They have tasked out a project development team to upgrade their ticketing system, upgrade their VoIP capabilities, and an application to automate workflow, updates, and patches. Galactic Customer IT Services is a well-known client in the IT industry. This document will be in place alongside all other deliverables to produce reports, reviews, and tasks that completed throughout the course of the project.

The Project Manager is responsible for:

• Documenting the client’s requirements, expectations, and constraints for the project.

• Communicating with the client and project design teams

• Ensuring the client’s quality objectives identified and documented.

• Identifying the scope of the project and degerming the needs of the project that include refining the requirements, budgets, and all quality assessments.

The Project Design Teams are responsible for:

• Creating a finished product that meets or exceeds the requirements and constraints that the client has identified.

• Delivering the product with all quality assessments accounted and implemented.

• Taking the appropriate steps to ensure quality is at their level.

• Communicating with the Project Manager with identified risks, time frames, and stage/phase completions.

· This system has an expected employee user usage of 250,000 and 250,000 potential customer users.

· Galactic Customer IT Services has several servers at each location.

· Current system software will have an upgrade after completion of this project.

· Several Remote locations across the country.

· Workstations and VoIP hardware.

· VPN

· Current ticketing system

The client and project manager will review the design before this phase becomes complete. Once the design has an approval, the work starts. Design changes will be minimal to reduce risks such as scope creep.

The waterfall method got the approval for use. This methodology will provide detailed documentation throughout the project. The project team is confident is providing all the necessary documentation to ensure the project starts off with as much information as possible. This will help mitigate risks in the later stages of development.

The Work Breakdown Structure (WBS) has a place in the Project Plan document. This WBS will need a review and updated during each phase of the project. Future phases may alter this structure and will be update as needed.

· Daily reports will be available and sent out via email to all team members. This will allow the teams to fully understand the areas that are complete and in progress.

· Weekly reports cover the timeline, budget, main goals for the week, deliverables, and questions or concerns about the previous week.

· Milestone reports have a review period during weekly meetings. These meetings will cover the requirements for completion, completed milestone reviews, deliverable approvals, and project time frames.

· Quality management meetings held weekly to cover the current status of each stage of the project.

· Updates to the communication plan will need approval before any changes made.

Andrews, M. (2019) The Best 11 Ticketing System Software in 2019. Retrieved from https://blog.hubspot.com/service/it-ticketing-system

Arnold, J. (2019, January 7). 64 Essential Software Quality Testing Metrics for Measuring Success. Retrieved from https://www.qasymphony.com/blog/64-test-metrics/.

Data, N. (2017, November 7). 13 Essential Software Development Metrics to Ensure Quality. Retrieved from https://blog.usenotion.com/13-essential-software-development-metrics-to-ensure-quality-219cfc264ed1.

Dennis, J. (2018). Three unbeatable security advantages of cloud-based solutions for your business. Retrieved from https://www.cloudcomputing-news.net/news/2018/jun/25/three-unbeatable-security-advantages-cloud-based-solutions-your-business

Doherty, N. A. (2000), integrated risk Management: Techniques and strategies for managing corporate risk. New York McGraw-Hill.

Eisenberg, Aviram. (2019.) Does your QA Team Structure Pass the Test. Retrieved from https://igniteoutsourcing.com/it-outsourcing/qa-team-structure-roles-responsibilities/?

Froot, K.A., Scharfstein, D.S., & Stein, J.C. (2013) Risk management: Coordinating corporate investment and financing policies. The journal of finance 48, no.5 1629-1658.

Funtowicz, S. O., & Ravetz, J. R. (2010). Three types of risk assessment and the emergence of post-normal science

Guru99, (2019). How to Create a Test Plan (with Example). Retrieved 25 November 2019, from https://www.guru99.com/what-everybody-ought-to-know-about-test-planing.html

Ivanova, I. (2019, November 10). Important Software Test Metrics and Measurements – Explained with Examples and Graphs. Retrieved from https://www.softwaretestinghelp.com/software-test-metrics-and-measurements/.

Jacoby, J., & Kaplan, L. B. (2013). The components of perceived risk. ACR Special Volumes

Reichert, A. (2019, January 22). How to write a software defect report. Retrieved from https://techbeacon.com/app-dev-testing/write-software-defect-reports-get-results-boost-credibility.

Rouse, M. (2019, February). waterfall model. Retrieved from TechTarget: https://searchsoftwarequality.techtarget.com/definition/waterfall-model

Spacey, John. (2017.) 14 Examples of Quality Objectives. Retrieved from https://simplicable.com/new/quality-objectives

Unknown. (2018.) QA Activities in a Waterfall Process. Retrieved from https://qatestlab.com/resources/knowledge-center/waterfall-process/

Online Ticketing

Customer Service

Tickets

Persistence

Security

UML Component Diagram: Online Ticketing

order

access

control

encryption

dataAccess

dataAccess

VPN

Internet

Customer

Remote Site 1

Remote Site 2Remote Site 3

Remote Site 4 Remote Site 5

Remote Site 6Remote Site 7Remote Site 8

Remote Site 9

Remote Site 10

Gainesville Florida

LosAngeles,Calafornia

ISP

Cloud

ISP

Cloud

T3

T2T2

T2

T2

T2

T2

T2

T2

T2

T2

DS3

DS3