Questioning Strategies Part 1 Questioning StrategiesSocial .docx

Questioning Strategies
Part 1: Questioning Strategies
Social studies standard:
Arts standard:
Grade level:
Learning objective:
Five probing questions that can be used as pre-assessment and
formative assessment questions:
1.
2.
3.
4.
5.
Part 2: Reflection
© 2018. Grand Canyon University. All Rights Reserved.
2
APPLICATION DEVELOPMENT 1

Connie Farris
Group 1
Participating Members
Raphael Brown
Shaun Cummings

Matthew Dunn
Deandre Kralevic
Colorado Technical University
IT Capstone II (IT488-1904B-01)
Abstract
This document will consist of 5-weeks of work, which will
have 6-group members developing this document. The project
will contain 10 total sections with a Quality Management
Report Template inserted at the end of section 10 just before
References. The Project sections will consist of the following:
Section-1: Overview of the project from IT487
Section-2: Requirements for the project from IT487.
Secton-3: The Design of the project from IT487
Section-4: System Development Methodology.
Section-5: Work Breakdown structure.
Section-6: Communication plan
Section-7: Quality Assurance Plan.
Section-8: Documentation Plan.
Section-9: Quality Assurance and results of test-case execution.
Section-10: Project closure
Quality Management Report Template
References.
There will be discussions via the Group Discussion Board,
Group Email, Chat sessions, and through the CTU Messenger.
Table of Contents
(Week 1) Section 6: Communication plan 14
Communication Matrix 16
Description of the type of quality planning 17
Roles 18
Coordination 19

Tasks and Schedule 20
Unit testing plan 20
Unit Test Plan Test Cases21
Plan for integration, system, and regression testing 23
Integration 23
System Testing 25
Regression Testing 26
Quality metrics26
System Defect Analysis 27
Software Defect Report Template 28
Risk management strategies 29
Risk Management 29
Risk Source 30
Project Risk Analyses 31
Qualitative 31
Quantitative 31
Conclusion 31
(Week 3) Section 8: Documentation plan 33
User Documentation 33
Document Control Plan Maintenance 33
Document Control Plan Updates 35
User Document Templates 36
Systems/Network Administration Manual Template 40
System/Network Administration 45
User and Group Accounts46
Server Administration 49
Printer Administration 49
Security Procedures 50
Backup Procedures 55
Inventory Management 57
Section 10 – Project closure 60
QUALITY MANAGEMENT REPORT TEMPLATE 61
References: 102

(Week 1) Section 1: Overview of the project (from IT487)
Overview
The Galactic Customer IT Services is an 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 an
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.
I75 Corridor
http://gregkantner.com/blog/wp-
content/uploads/2012/05/interstate-75-map.gif
(Week 1) Section 2: Requirements (from IT487)
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 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.
.
(Week 1) Section 3: Design (from IT487)
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
(Week 1) Section 4: System development methodology
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 stages 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 since the
approach is our way of risk mitigation.
(Week 1) Section 5: Work breakdown structure
Collection of data and analysis will merge at the same time in
the planning phase, which will help to establish the needs of
stakeholders. The process is supposed to take one week where
the project crew will collect all the information from vendors,
customers, and stakeholders. This will help to decide the
features expected from the program. The next process is coming
up with integration tools and this step will take approximately 3
weeks due to the complex nature of the process.
Time and cost should be well managed and thus testing and
development of the project features will be conducted
simultaneously. Actual testing of the application on vendors and
customers will provide real-time support that greatly aids in the
development and implementation of security measures to reduce
risk. Real-time support also helps greatly to reduce the effects
of malfunctioning on the business and also try to establish the
vital features that may not get into the development phase. This

phase will take no more than 3 weeks to complete. The
development team will actively fix any malfunctioning of the
application.
The last process is monitoring how the application is
performing. The team will offer oversight for support for
example database administration or cloud-based services.
Cloud-based services always have various security features in
place to ensure information communicated through the network
resource is reliable and secured properly (Dennis, 2018).
(Week 1) Section 6: Communication plan
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.Communication Matrix
Stakeholder
Risk Content
Method
Frequency

Project Managers, Team Members
cost
email
As required
Program Manager, Project Managers
performance
memos
weekly
Program Manager
training
Manager program control file
As needed
Program Director,
schedule
email
As required
(Week 2) Section 7: Quality Assurance PlanDescription of the
type of quality planning
Objective

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.

Roles
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)
Coordination
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.
Tasks and Schedule
Unit testing plan
Objective
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.
Unit Test Plan Test Cases

Test Case ID
Test Discription
Test Data
Expected ResUlts
Actual Results
UT-1
Final ticketing application test
End-user input data
Tickets Print out to screen
Test passed 11/06/2019
UT-2
Ticketing system network connection test
Data from ticketing system sent to router
Data packets seen at router
UT-3
ISP Cloud circuit test
Data Test packets set from router
Data packet arrive at ISP cloud
UT-4
DS3 circuit tests
Data test packets sent from host site and remote sites to the ISP
Data test packets reach destinations
UT-5
Bandwidth test
Network bandwidth test to meet specifications
No bottleneck in the network
UT-6
Network throughput speed test
Network throughput test to meet specifications
Network speed to reach specifications
Passed on 11/20/2019

UT-7
VPN circuit test
Test data reaches remote site from host site
Test data arrives at destination site
UT-8
VoIP connection speed test outbound
VoIP data packets sent to the ISP cloud and the cloud receives
it
VoIP data sent form the cooperate office to the ISP cloud
Test passed 11 22/2019
UT-9
VoIP connection speed test Inbound
VoIP data packets sent from the ISP cloud and received
VoIP data packets reach the cooperate office from the ISP
Cloud
UT-10
End point tests ping test
Ping test to the remote sites
Ping test packet reached
Passed 11/27/2019
Plan for integration, system, and regression testing
Integration
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.

Integration Test
Test ID
Test Name
Test Description
Assumption
Impact
F1-E1
Ticket Template
Display a template for user
Template displayed for user without error
High
F1-E1.1
Special Characters
Limit of special characters
Special characters will be limited to prevent the ability to run
code
High
F1-E1.2
Character length
Max character length set to 250
Characters limit applied to improve performance
Low
E1-D1
Ticket Validation
Test for ticket completion
Ticket has all required fields completed
High
E2-D2
Ticket Forwarding
Ticket forwarded to server
Ticket forwarded
Med
E3-D2

Ticket Update
Ticket sent for update
Ticket on standby for update
Med
D1-C1
Ticket Creation
Ticket created without error
Ticket created successfully without error
Med
D2-C1
Ticket Automation
Ticket on standby for forwarding/updating
Ticket ready for forwarding to remote server
Med
C1-B1
Ticketing
Ticket created, validated, and updated. Available to GUI.
Forwarded to server.
Ticketing is available within the GUI
High
C2-B1
Remote Server
User has access to remote server
Remote server has access to send/retrieve tickets
High
C3-B2
Apply Patch
Patch received and sent for application
Patch on standby
Med
C4-B2
Apply Update
Update received and sent for application
Update on standby
Med
System Testing

System Test
Test ID
Test Name
Test Description
Assumption
Impact
S-1
User interaction
User has access to GUI and features
User has access to all features within the application
Med
S-2
UI functionality
All buttons function
All buttons will function as expected
Med
S-3
Ticket Creation (Locally)
User can create a ticket
User can successfully create a ticket
High
S-4
Ticket Creation (remotely)
User can create a ticket
User can successfully create a ticket
High
S-5
System interaction
System can interact with other sub-systems
System can successfully update, retrieve, and edit tickets across
sub-systems
High
S-6
Performance Test
Tickets edited, retrieved, and updated in the specified time
Tickets edited, retrieved, and updated within 5 seconds of entry

Low
S-6.1
Performance Test
The specified number of users can access the system
256 Users can access the application at a time
High
S-7
Compatibility
The application can run across multiple platforms
The application will run on all major platforms. (Windows OS,
Apple OS, IOS, Android)
High
S-8
GUI appearance
User friendly GUI
User can quickly identify and access the requested features
Med
S-9
Security
Codes prevented
Users will not have the ability to run code in the requested
entries
HighRegression Testing
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.Quality metrics
Introduction
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 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
System Defect Analysis
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. Software Defect
Report Template
Summary
Summarize the bug in under a paragraph. i.e. I can’t use the
ticketing system
Description
Describe the issue in greater detail, including the time of day,
terminal number, employee access number and accomplished
Build/Platform
This could represent the Ticketing system, the ticket forwarding
system, the VoIP or the applications for automated workflow or
updater
Steps to reproduce
Include everything that needs to replicate the order of process

that got the user to the error in question.
Actual results
After preforming the action, what exact message or error did the
terminal provide, if any
Expected results
What was the intended action trying to preform? Reference
report numbers or work schedules for faster results
Reporter of Defect
Is the defect report from a user or employee; include contact
information where available
(Reichert, 2019)
Risk management strategies
Risk Management
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. Despite 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 overall negative dangers.
They are dangers instead of chances
Risk Register
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 parts onto a
similar scale.
Example:
Risk Category
Description of Risk
Potential of Risk
Cost
Different views on needs requirements
Delay of Project
Additional Cost
Performance
Software not delivering expected results
Revising plan could cause delays and cost
Schedule
Hardware and software Issues
Increase Cost
Schedule Delays
Contractual
Terms of Contact
Possible Incurred Additional Cost
Risk Source
Risk Source
Description
Risk Repository
History data containing the rundown of perils recognized for
wrapped up wanders. This will be in use to arrive at a rundown
of potential threats for the undertaking.

Checklist Analysis
The risk recognizable proof checklist could be a survey that
makes a difference recognizes crevices and potential dangers.
It’s created based on involvement and extend sort.
Expert Judgement
Risk recognizable verifications moreover done by
conceptualizing with or assembly experienced individuals,
accomplices, and subjects matter masters.
Project status
The project status joins status assembly reports, status reports,
development reports, and quality reports. These reports give the
current venture development, issues gone up against, and edge
encroachment. These allow understanding into the status of the
assignment and potential chance risk.
Project Risk Analyses Qualitative
Impact rating
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-3 Quantitative
Risk event
Probability of Occurrence
Potential Impact
The equipment changes will take an extra week
100%
B 50
The unused software program and network changes will be
delay due to equipment issues.
100%
B 50

At certain level, the client affirms the half highlights portrayed
within the item but educates the firm of other extra necessities
80%
B 45
Conclusion
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.

(Week 3) Section 8: Documentation plan
User Documentation
Upon completion of the product, a manual for the network
admins will be created and disseminated via email. This
document will provide the user with the ability to know the ins
and outs of the network and how to troubleshoot the system if
need be. We believe that the document should be given out via
email and a hard copy should also be produced in case of a
situation where the admin does not have access to the computer
to complete the troubleshoot. Timeline for product
dissemination is after the December 17th date but further down
the line where the project is also complete, preferably a week
after product completion to give time to make edits to the
document.
The end user manual is the most detailed manual that we have
decided to create. It does into full detail on how to operate,
troubleshoot, install, and perform routine maintenance. This
document has a completion date of December 17th, 2019 as
well. However, dissemination will not begin until the project is
complete, and all tests have passed audits. This manual will
need to be in review and tested for cohesiveness in order to pass
the requirements expectation. Once that is complete, we expect
the document to be ready for release about a month before
launch of new system.Document Control Plan Maintenance
The purpose of this Document Control Plan for the
company ISI is to keep accurate records on the current and past
methodologies, used during the creation and maintenance of the
current hardware systems being used. This should include a list
of personnel that have or continue to make changes to the
system. The plan should be reviewed annually to keep current
with advancing technology and evolving business practices.
Sections that are currently being worked on will be

identified by a version number, time stamp and an employee
code to identify and trace the work being done. Official
Documentation should be marked as such, with signatures on
approvals updates or changes being made only by the project
team’s lead. Changes to documents should be marked to identify
physical or electronic to update the appropriate area and track
any changes being made (F, 2018). An additional table of
contents should be provided for any sub along with image and
video references in the sections where applicable.
Document creation, updates or approvals will be performed
by the Network System Administrator and authorized then
released by the Management. The IT staff will be responsible
for the completion and hard copy storage of new materials.
Management will determine what information is accessible to
the different versions released to different Users.
The categories of documents include but are not limited to
Project Administration, Presentations, Cost Analysis
Breakdown, contracts, employee assignments, version tracking,
help sections and research materials.
The Storage of the documents, once created, will be
handled by management to ensure the secure storage of
sensitive materials. Hardcopies stored will also include any
official project materials, including contracts, contacts
proposals and licenses. Electronic Versions will include copies
of the materials above, and will be identified clearly by name,
date, version number and uploader. These will be materials will
be sub sectioned by project folders in the database that will be
clearly identified by the Projects name and subsequent version.
The different versions of documentation will be maintained
in the same manner by staff, though the availability of
information in the documents will be different. Management
will be provided with the complete contents of the documents
provided, including any sensitive or proprietary information to
be able to formulate administrative or financial changes and
respond to various interests. Network System Administration, or
NSA will be provided a document oriented at the system itself,

with less emphasis on financial interests and sensitive
information not directly impacting the projects operations
(Akinci, 2010). With multiple clearance levels on the NSA
staff, each employee login will provide the appropriate
clearance to view the sections needed for that job code.
Policies, procedures and included forms are
End Users will be provided the least technical documentation on
the back end of operations with a focus on the appropriate uses
and available functions of the systems applications. The
emphasis is instead placed on the order of operations and the
types of information the system can process. The help section
should also be more robust with outside reference materials,
training videos and help contacts.Document Control Plan
Updates
Management will be able to manually submit requests for
updated project information at any time. In addition, weekly
scheduled project reports will be provided during the projects
inception and monthly maintenance session reports to track
scheduled or emergency changes made to the system by the
NSA or IT support team. Once completed the updated version
link will be sent to those with appropriate access for review and
release. New additions to the hardcopy files should be added
into the existing files by management and tagged to the applied
version.
Network System Administration is responsible for assigning IT
associates to the completion of the project reports required.
Once completed, the documents will be reviewed for accuracy
of information and conformation to the document control
standards. This should include, associates name and title, a
summary of the reported work, the information changed, the
date and the version number. The associate will alert their
admin by email when the work is completed to be complied into
the new version.
End Users will be alerted by email or program startup when a
new version of the help or instructional documents are changed

or updated. The updates and changes to the User Documents
will be scheduled for once every six months, to be made by the
IT support team, following the procedures outlined above. The
NSA will approve, or request changes then the contact will be
put into place by the Management to ensure the security,
availability and accuracy of the materials supplied. User
Document Templates
Documentation for Management
To: Management
From: Connie Farris and Development Team
Date: 12/02/2019
Subject: Design Plans
We have created this document to inform all management
involved in the development project the steps we will be using
to provide a system that meets all the requirements and needs of
the company and the end-users.
After serious discussion, the development team have decided
to use the Waterfall Methodology for this endeavor. Some of the
main reasons we will use this method are the following:
· Timescales are kept
· No money related shocks
· Testing is made simple
· The result is precious stone clear
· Bargain with issues within the plan
· What you arrange is what you get
Waterfall takes after a straightforward structure of stages
where the comes about of each stage cascade down to the
following level of advancement. (Kienitz, 2017) In other
words, we’re not so much looking at one huge Niagara Falls,
but an arrangement of cascading waterfalls – each with their
claim small pool of exercises.
Processes
The process documents offer guidance to the development,

testing, maintenance and improvement of the systems. The
process documents are normally used by managers, engineers,
testers and the marketing professionals.
Administration will utilize this program for ticketing
framework, ticketing computerization sending framework, VoIP
framework for out of nation calls, conveying workflows and
dealing with auto upgrades and straightforward to halfway
patches. The conclusion clients are not interested to get it the
application profoundly, but to know for performing any of the
above-mentioned assignments.
The description document which provides the necessary
information on the system requirements and the services offered
this document is detailed information regarding the software.
The end users should read through the provided introductory
manual to determine whether it is the required software. The
following is a draft of the description document. Revision
History
Date
Version
Description
Author
<04/13/year>
<1.0>
SRS 1.0
Group-1
<04/15/year>
<2.0>
SRS 2.0
Group-1
<04/15/year>
<3.0>
SRS 3.0
Group-1
<04/16/year>
<4.0>

SRS 4.0
Group-1
This document will be distributed by sending a copy of the
document to each software user either through email or inform
of a hard copy by packing together with the software. The
maintenance of this document can be ensured through filing or
saving in email for easier retrieval.
Secondly is the configuration which is either developed for the
system administrator or the end user. This document clearly
shows how to configure the software for end use. For the system
design or the configuration document, it should have the
following in components;
The configuration or system design document will be distributed
through the packaging materials for the software or rather
sending a softcopy to every software user.
The user guide will be distributed through packing or sending
through the software. It should be accompanied with the
software either through in form of soft copy or through a hard
copy to enable the users to understand how to safely and
correctly use the software.
The final section entails information for possible cost and
configuration timelines
Costs
I would suggest standard server and information center version.
This can be included by two virtual OSE. The authorizing show
is processor+. The server estimating for this version goes for
$890. Information center version goes for $1000. Equipment
prerequisite as recorded over will account up to $1000 whereas
computer program necessity will go up to $500. Significate cost
could be experienced within the staff required for the usage.
With this the cost could increase to about $2000
Duration to complete each task
The table shows project plan for full implementation of c
Task name
Duration

Introductory Arranging
4 days
Windows 7 arrangement to desktops (Stanek, 2013).
6 days
Windows server Establishment (Stanek, 2013).
3 days
Introduce windows server overhauls
2 day
Install virtual server
3 days
Introduce windows 7 overhauls
2day
Customize client computers
2 day
Make application bundles
2 days
Test windows 7 arrangement(Stanek, 2013).
1 day
Arrangement of client computers with server
2 days
Testing of entire client/server framework
3 days
Finalize and provide documentation
1 days
The development team and I hope this document will provide
you with the information to assure we are committed to
providing you with a design that has all the requirements and
needs that will prove it`s worth for now and in the future. Any
questions please feel free to contact us at 1-800-596-1582 or at
[email protected]
Systems/Network Administration Manual Template

Galactic IT Services
3062 Argyle RD1
Gainesville, Florida
32609
USA
Tel: 352-376-5555 Fax: 352-351-5555
Last edited: 08 December 2019
Copyright © 2019 Galactic IT Services. All rights reserved.
No part of this publication may be reproduced, transmitted,
transcribed, stored in a retrieval system, or translated into any
language, in any form or by any means, electronic, mechanical,
photocopying, recording, or otherwise, without prior written
permission from Galactic IT Services
All copyright, confidential information, patents, design rights
and all other intellectual property rights of whatsoever nature
contained herein are and shall remain the sole and exclusive
property of Galactic IT Services. The information furnished
herein is believed to be accurate and reliable.
However, no responsibility is assumed by Galactic IT Services
for its use, or for any infringements of patents or other rights of
third parties resulting from its use.
Running Head: PLANNING & DEVELOPING A PROJECT
1
PLANNING & DEVELOPING A PROJECT
2
:
Document Name: System Administration Guide
© Galactic IT Services 2019. All rights reserved. Page 6 of 35
Document History
Document History will be recorded here, however there are no
documents to place here as of yet.
Revision History

Any time a document is revised it will be recorded in the table
below.
Revision Number
Revision Date
Summary of Changes
Author
Reference Documents
Please see the following documents for more information:
Document Name
Version
Author

Distribution List
This document has been distributed to those listed in the table
below:
Name
Position
Company
Action

Introduction
This System Administrator Guide provides information on how
set up, configure, and deploy the System/Network application
for research, development, and instructional use. The Systems
Administration Guide serves the purpose of an Operations
Guide in distributed client/server applications.
Purpose and Scope
Audience and Assumptions This section introduces and
describes the purpose of the Systems Administration Guide, the
name of the system to which it applies, and the type of
computer operation.
This guide is intended to assist System/Network Administrators
in securing workstations, mobile computers, and computers
within managed environments and should not be applied
throughout an enterprise unless trained and competent
System/Network Administrators are available on the staff.
System Administration Tasks
This section introduces and describes the purpose of the
Systems Administration Guide, the name of the system to which
it applies, and the type of computer operation.
The System Administrator's tasks include:
· Backing up and loading databases
· Changing the password of any account
· Creating server login accounts, which includes assigning
initial passwords
· Creating user databases and granting ownership of them
· Creating, granting, and revoking user-defined roles

· Diagnosing and reporting system problems
· Fine-tuning [Server] by changing configurable system
parameters
· Granting and revoking the Security Officer and Operator roles
· Granting and revoking the System Administrator role
· Granting permissions to [Server] users
· Granting the capability to impersonate another user throughout
the server
· Managing disk storage
· Managing the audit system
· Modifying and dropping server login accounts
· Monitoring [Server]'s automatic recovery procedure
· Security Officer - who performs security-related tasks such as:
· Setting the password expiration interval
· Setting up [Server] to use network-based security services
· Setting up groups which can be used for granting and revoking
permissions)
System/Network Administration Roles
Many of the commands and procedures discussed in this guide
require the System/Network Administrator or Security Officer
role. Other sections are relevant to Database Owners. A
Database Owner's user name within the database is "dbo".
Various security-related, administrative, and operational tasks
are grouped into the following system roles:
System/Network Administrator
By default, the System Administrator (the SA) has the following
roles:
· sa_role
· so_role
· oper_role
Operator
An Operator is a user who can back-up and load databases on a
server-wide basis. The operator role allows a single user to
usecommands to back up and restore all databases on a server
without having to be the owner of each one. These roles provide
individual accountability for users performing operational and

administrative tasks. Their actions can be audited and attributed
to them.
Relationship to Other Plans
Document relationships are recorded in the table below
Resource Name
Purpose
Location
Functional Requirements
[version]
[author]
Operations Guide
[version]
[author]
Configuration Management Plan
[version]
[author]
Software Quality Assurance Plan
[version]
[author]
System Overview
This section will provide a brief description of the system,
including its purpose and uses.
System Software
Below will be the description of the overall system software and
organization.
· List the software modules, programming languages, and
development tools.
· Describe all software required to support the system, and
specify the physical location of all software systems.
· Identify database platforms, compilers, utilities, operating
systems, communications software, etc.
· Identify each software system, subsystem, and program by
name, description, and documentation references.
#

Software
Description
1
[name of software]
2
[name of software]
3
[name of software]
Network Communications Architecture
In this section the communications within the system, such as
Local Area Networks (LANs), buses, etc. will be described.
Included will be the communications architecture(s) being
implemented, such as VoIP, Point to Point, DS3, etc.
A diagram will be provided depicting the communications
path(s) between the system and subsystem modules.
Site Profile
Site Location
This is the official address of the site(s).
Site Contacts
Primary Site Contacts
Primary Contact
Role
Phone
Email

Secondary Site Contacts
Secondary Contact
Role
Phone
Email
System/Network Administration
This section covers procedures for maintaining the file system.
Shutting Down a System
Guidelines for Shutting Down a System
When to Shut Down a System
Reason for System shutdown
Appropriate Run Level
To turn off system power due to anticipated power outage
Run level [X]
To change kernel parameters in the /etc/system file
Run level [X]
To perform file system maintenance
Run level [X]
System Shutdown Commands
Command

Description
When to use
shutdown
An executable shell script that calls the init program to shut
down the system.
Recommended for servers operating at run level because users
are notified of the impending shutdown.
init
An executable that kills all active processes.
Recommended for stand-alone systems when other users will
not be affected.
reboot
An executable that passes boot instructions to the admin system
call.
The init command is the preferred method.
poweroff
An executable that synchronizes the disks and stops the
processor.
Not recommended because it doesn't shutdown all processes and
unmount any remaining file systems.
How to Shut Down a Server Unix based system
1. Become super-user or assume an equivalent role.
2. Find out if users are logged in to the system.
3. Shut down the system.
Turning Off Power to All Devices
You need to turn off power to all system devices when you:
· Replace or add hardware.
· Move the system from one location to another.
· Prepare for an expected power outage.
Turn the power off for system devices, including the CPU, the
monitor, and external devices such as disks, tapes, and printers.
Starting Up a System
Use this procedure to boot a system that is currently at run level
to run level. This run level is used for system maintenance
tasks, such as backing up a file system.
1. Boot the system to run level [x].

2. Type the super-user password.
3. Verify that the system is at run level [x].
Monitoring Performance and System Activity
This is where the procedures to monitor system usage,
performance, and activity will be kept. Installing Programs and
Operating System Updates
Maintaining Audit Records of System Operation
This is where the procedures for the setup and monitoring of the
operating system and application audit trail will be entered
Maintenance Reports
This is where the procedures to create and update maintenance
reports are kept
User and Group Accounts
· System Administrators have access permissions on all systems
objects at all times.
· Network Administrators have access permissions on all
network objects at all times
· Security Officers can always access the audit trail tables in the
security database.
User Types and Privileges
The system will recognize the following types of users:
Type
Privilege
System Administrators
Describe privilege
Network Adninistrators
Describe privilege
Security Officers
Describe privilege
Operators
Describe privilege
Other users (also known as "public")
Describe privilege
System/Network Administrator privileges
System/Administrator’s privileges. Will be entered in the table
below

Privilege
Impact on other users
Describe privilege
Describe privilege
Describe privilege
Adding/Deleting User Logins
A description of the procedures for creating and deleting user
logins and password accounts will be recorded in the table
below
#
Action
1
2
3
Adding New Users
· Security Officer uses will use a command setup for them to
create a server login account for a new user.
· System/Network Administrator will use a command set for
them to add a user to a database.
· Security officer grants specific roles to the user.
This table summarizes the system procedures and commands
used for these tasks.
Task
Role
Command or Procedure
Database
Create new logins, assign passwords etc
Identify Role

Enter command
Identify database
Create groups
Identify Role
Enter command
Identify database
Create and assign roles
Identify Role
Enter command
Identify database
Add users to database
Identify Role
Enter command
Identify database
Grant permissions
Identify Role
Enter command
Identify database
Setting User Permissions
Task
Required Role
Database
Adding/Deleting User Groups

Task
Required Role
Database
Changing User Information
Task
Required Role
Database
Change default database
Identify Role
Enter command
Identify database
Change default language
Identify Role
Enter command
Identify database
Change default settings
Identify Role
Enter command
Identify database

Changing User passwords
#
Action
1
2
3
User Roles/Responsibilities
Role
Responsibility
Enter role type
Describe the responsibilities assigned to this role
Enter role type
Enter role type
Dropping Users / Groups
Task
Required Role
Database
Drop user from database
Database Owner or System Administrator
Enter command
Enter database
Drop group from database
Database Owner or System Administrator
Enter command
Enter databaseServer Administration
The procedures to setup servers, including naming conventions

and standards will be written up here.
Creating Directories
The procedures to create server directories; identify the existing
directories will be written here.
Building Drive Mappings
The procedures to create server drive mappings; identify
existing drive mappings will be written here.
Server Resources
A description of how to use resource limits to restrict the I/O
cost, row count, or processing time that an individual login or
application can use during critical times. A resource limit is a
set of parameters specified by a System Administrator to
prevent an individual login or application from:
· Exceeding estimated or actual I/O costs, as determined by the
optimizer
· Returning more than a set number of rows
· Exceeding a given elapsed time
The set of parameters for a resource limit includes the time of
day to enforce the limit and the type of action to take. This
information will be provided in the table below.
Use the system parameters to:
#
Action
1
Specify the name of the user or application to which the
resource limit applies.
2
Specify the type of limit and set an appropriate value for the
limit type.
3
Specify whether the resource limit is enforced prior to or during
query execution.
4
Specify numeric values for this parameter.
5
Specify the action to be taken (e.g. issue a warning, abort the

query batch, abort the transaction, or kill the session).
6
Specify numeric values for this parameter.
7
Specify the scope (query, query batch, or transaction).Printer
Administration
This section discusses procedures for installing, operating, and
maintaining printers.
Maintenance
This section will be used to describe maintenance contracts,
procedures to include installation and configuration of printer
drivers, and equipment information.
Print Jobs
This section will be used to describe procedures to monitor,
delete, and prioritize print jobs. Setting up local printers
· Setting up print servers
· Setting up print clients
Requirements for Print Servers
· Spooling directory space of 8MB (or more)
· Hard disk strongly recommended (not required)
· Memory of 12MB (or more)
· Swap space of 20 to 24MB (or more)
Printer Configuration Information
Below is the how to configure a printer on the network, you will
need the following configuration information ahead of time.
· Serial (or parallel) device name (required), for example
/dev/xxx.
· Unique name for the printer (required).
· Printer type (required).
· Type of file content (required), for example, PS for
PostScript, simple for ASCII, or both.
· Print server's Internet Protocol (IP) address in universal
address format
· The description of the printer to convey to users
(recommended, optional)
· The default printer for each system (recommended, optional).

Setting up Local Printers
Steps for setting up local printers.
1. Step 1
2. Step 2
3. Step 3
Setting up Print Server
Steps for setting up print servers.
1. Step 1
2. Step 2
3. Step 3
Setting up Print Clients
Steps for setting up print clients.
1. Step 1
2. Step 2
3. Step 3Security Procedures
Below is the process for obtaining identifications (IDs) and
passwords. Include information concerning network access and
confidentiality requirements.
Security Features
Feature
Description
Access Controls
Provides access controls that give object owners the ability to
restrict access to objects, usually with the grant and revoke
commands.
Identification and authentication controls
Ensures that only authorized users can log into the system.
Division of roles
Allows you to grant privileged roles to specified users so that
only designated users can perform certain tasks.
Network-based security
Provides security services to authenticate users and protect data
transmitted among machines on a network.
Auditing
Provides the capability to audit events such as logins, logouts,
server start operations, remote procedure calls, accesses to

database objects, and all actions performed by a specific user or
with a particular role active.
Security Procedures
Task
Description
1. Install server
This task includes preparing for installation, loading files from
your distribution medium, performing the actual installation,
and administering the resources that are required.
2. Set up a secure administrative environment.
This includes enabling auditing, granting roles to individual
users to ensure individual accountability, and assigning login
names to System Administrators and Security Officers.
3. Add user logins to the server; add users to databases;
establish groups and roles; set proxy authorization.
Add logins, create groups, add users to databases, drop and lock
logins, and assign initial passwords. Assign roles to users,
create user-defined roles, and define role hierarchies and mutual
exclusivity of roles.
4. Administer permissions for users, groups, and roles.
Grant and revoke permissions for certain SQL commands,
executing certain system procedures, and accessing databases,
tables, particular table columns, and views.
5. Administer the use of remote servers.
Establish and administer the access that is permitted between
servers, add and drop remote server access, and map remote
login names to local login names.
6. Set up and maintain auditing.
Determine what is to be audited, audit the use of [server], and
use the audit trail to detect penetration of the system and misuse
of resources.
7. Set up your installation for network-based security services.
Configure the server to use services, such as unified login, data
confidentiality with encryption, data integrity, and determine
security for remote procedures.

Guidelines for setting up security
Using the "sa" login
When [server] is installed, a single login called "sa" is
configured with the System Administrator and Security Officer
roles. This means that the "sa" login has unlimited power.
Use the "sa" login only during initial setup. Instead of allowing
several users to use the "sa" account, establish individual
accountability by assigning specific roles to individual
administrators.
Changing the "sa" Login Password
The "sa" login is configured initially with a "NULL" password.
Use sp_password to change the password immediately after
installation.
When to enable auditing
Enable auditing early in the administration process so that you
have a record of privileged commands that are executed by
Security Officers and System Administrators. You might also
want to audit commands that are executed by those with other
special roles, such as operators when they dump and load
databases.
Assigning login names
When assigning [server] login names that are the same as their
respective operating system login names, it makes logging in to
the [server] easier, which simplifies management of the server
and operating system login accounts and makes it easier to
correlate the audit data generated by the [server] with that of
the operating system.
Network Based Security
The server will provide network-based security services that
enable you to authenticate users and protect data transmitted
among machines on a network. In a distributed client/server
computing environment an intruder can view or tamper with
confidential data. With the server, you can use security services
provided by third-party providers to authenticate users, encrypt
data, and prevent data tampering.
· Unified login - use a security mechanism to authenticate users

once without requiring them to supply a name and password
every time they log in to an [server].
· Message confidentiality - encrypt data over the network.
· Mutual authentication - use the security mechanism to verify
the identity of the client and the server.
· Message integrity - verify that data communications have not
been modified.
· Replay detection - verify that data has not been intercepted by
an intruder.
· Out-of-sequence check - verify the order of data
communications.
· Message origin checks - verify the origin of the message.
· Remote procedure security - establish mutual authentication,
message confidentiality, and message integrity for remote
procedure communications.
Setting Up Passwords
The passwords helps prevent access by unauthorized people.
When you create the password, follow these guidelines:
· Do not use information such as your birthday, street address,
or any other word or number that has anything to do with your
personal life.
· Do not use names of pets or loved ones.
· Do not use words that appear in the dictionary or words
spelled backwards.
· The most difficult passwords to guess are those that combine
uppercase and lowercase letters and numbers. Never give
anyone your password, and never write it down where anyone
can see it.
Follow these rules to create a password:
· Passwords must be at least 6 bytes long.
· Passwords can consist of any printable letters, numbers, or
symbols.
· Includes any character other than A-Z, a-z, 0-9,_, #, valid
single-byte or multibyte alphabetic characters, or accented
alphabetic characters
· Begins with a number 0-9

License Agreements
Describe the licensing agreements and procedures for ensuring
that all licenses are current.
The [application] allows a System Administrator to monitor the
number of user licenses used in [Server] and securely manage
the license agreement data. That is, you can ensure that the
number of licenses used on your [Server] does not exceed the
number specified in your license agreement. The [application]
tracks the number of licenses issued; it does not enforce the
license agreement.
How to count licenses
A license is the combination of a host computer name and a user
name. If a user logs in to [Server] multiple times from the same
host machine, it counts as one license. However, if the user logs
in once from host A, and once from host B, it counts as two
licenses. If multiple users log in to [Server] from the same host,
but with different user names, each distinct combination of user
name and host name is counted.Backup Procedures
The System Administrator is responsible for ensuring the
continued integrity of information stored on the system. One
way the system administrator maintains integrity is to back-up
the data on the system periodically so that the data can be
restored if it is lost.
A ‘backup’ is a copy on external storage media, such as disks or
tape, of files on your hard disk. A ‘filesystem backup’ is a copy
of the files in the root filesystem or another regularly mounted
filesystem. Files and filesystems can be damaged, and data can
be lost through:
· Power surges and interruptions
· Hardware failures
· User errors (i.e. accidental removal of important files)
You should back up your filesystems regularly, so you have up-
to-date copies from which to restore lost data
Describe the procedures for regularly scheduled backups,
including program and data storage, and the creation and
storage of backup logs.

Maintenance Schedule (Daily, Weekly)
This section describes documented daily and weekly backup
schedules and procedures. The procedures should include tape
labeling, tracking, and rotation instructions.
Daily Schedule
Task
Mon
Tues
Wed
Thurs
Fri
Sat
Sun

Weekly Schedule
Task
Mon
Tues
Wed
Thurs
Fri
Sat
Sun

Monthly Schedule
Task #
Jan
Feb

Mar
April
May
June
July
Aug
Sept
Oct
Nov
Dec
Task
Task

Task
Task
Running scheduled backups
Before performing a scheduled backup, you might need to
format the media.
1. Select the system to back up from the list.
2. Select Run Scheduled from the menu.
3. If necessary, select or enter the correct media device
Running unscheduled backups
1. Select the system to back up from the list.
2. Select Run Scheduled from the menu.
3. If necessary, select or enter the correct media device

Off-Site Storage Procedures
Maintaining Backup Log
Inventory Management
Maintaining Hardware and Software Configurations
Maintaining Floor Plans
Installing Software/Hardware
Maintaining Lists of Serial Numbers
Maintain Property Inventory
Frequently Asked Questions
How do I [enter FAQ]?
Answer:
Answer:
Answer:
Appendix
References
Glossary
End-User Manual Template
Title Page

(Week-4) Section 9: Quality Assurance and results of test-case
execution
Section 10 – Project closure

QUALITY MANAGEMENT REPORT TEMPLATE
Introduction
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.
Requirements
Resources
· 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
Design
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.
System Development Methodology
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.
Work Breakdown Structure
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.
Communication Plan
· 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 has 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.
Week 1 – 5. QUALITY MANAGEMENT REPORT

Week-1
Completion
Pass/Fail
Status
YES
NO
Under Review
Project Requirements

R-1
Ticketing System
X
The Ticketing System will be omni-channel supported. (i.e.
phone, email, self-service application, and employee input.)
R-2
Ticket Automation
X
This application will allow ticketing automation. This will
allow users to identify their problem and a ticket will auto
generate into the system. The system will automatically forward

the tickets to the appropriate levels.
R-3
VoIP upgrade
X
The VoIP capabilities will provide telecommunications with the
use of a VPN. This will include local and long-distance calling.
R-4
Automated workflow and updates
X
The application will provide the capabilities to create tickets,
provide updates and patches to the system.

Unit Case Testing
Description
UT-1
Final ticketing application test with end-user input data which
should show up on the monitor and print system.
X
Pass

Quality Planning
Quality Control
Quality Assurance
Quality Improvement
Plan
Do
Check
Act
What’s done
Determining the Requirements and constraints of the project.
Monitoring the requirements at each phase.
Measuring the quality of the requirements
Increasing the quality of the requirements at each stage.
When it’s done
Planning phase: client identified these resources
Project development & quality assurance phases
Project development, quality assurance, and sprint phases
Resources
Quality Planning
Quality Control

Quality Assurance
Quality Improvement
Plan
Do
Check
Act
What’s done
Determining the resources available to the project
Monitoring the resources and to utilize them to the fullest
Determining if the resources are available and the quality of
each.
Improve efficiency and effectiveness of the project resources.
When it’s done
Sprints
Design
Quality Planning
Quality Control
Quality Assurance
Quality Improvement
Plan

Do
Check
Act
What’s done
Determining the appropriate design
Monitoring the design to determine if it meets requirements
Measuring the quality of the design for overall performance to
the project
Increase performance when necessary
When it’s done
Sprints
Quality Planning
Quality Control
Quality Assurance
Quality Improvement
Plan
Do
Check
Act
What’s done

Determining the appropriate methodology
Monitoring the chosen methodology
Measuring the quality of each sprint
Increase performance and efficiency of each sprint phase.
When it’s done
Sprints
Work Breakdown
Quality Planning
Quality Control
Quality Assurance
Quality Improvement
Plan
Do
Check
Act
What’s done
Determining the appropriate Work Breakdown Structure
Monitoring the assigned WBS at each level.
Measuring the performance of each level and their time frames
Alter the WBS as needed to increase efficiency.
When it’s done

Sprints
Communication Plan
Quality Planning
Quality Control
Quality Assurance
Quality Improvement
Plan
Do
Check
Act
What’s done
Determining the appropriate communication plan
Monitoring the effectiveness of the communication plan
Measuring the communication plan for any unused time.
Alter the time allotted for meetings, reports, etc. to produce an
efficient plan.
When it’s done

Week-2
Completion
Status
YES
NO
Under Review
Requirements
R-1

Ticketing System
X
R-2
Ticket Automation
X
R-3
VoIP upgrade
X

R-4
X
Unit Test Cases

Description
UT-2
Ticketing system network connection test - Data from ticketing
system sent to router
Exit criteria Data seen at Router
X
Pass
Description
UT-5
Bandwidth test - Network bandwidth test to meet specifications
Exit criteria
No bottleneck in the network
X
Pass

Description
UT-7
VPN circuit test - Test data reaches remote site from host site-
Exit criteria - Test data arrives at destination site
X
Pass
Requirements
Quality Planning
Quality Control
Quality Assurance
Quality Improvement
Plan
Do
Check
Act
What’s done

When it’s done
Resources
Quality Planning
Quality Control
Quality Assurance
Quality Improvement
Plan
Do
Check
Act
What’s done
each.

When it’s done
Sprints
Design
Quality Planning
Quality Control
Quality Assurance
Quality Improvement
Plan
Do
Check
Act
What’s done
the project
When it’s done
Sprints

Quality Planning
Quality Control
Quality Assurance
Quality Improvement
Plan
Do
Check
Act
What’s done
When it’s done
Sprints

Work Breakdown
Quality Planning
Quality Control
Quality Assurance
Quality Improvement
Plan
Do
Check
Act
What’s done
When it’s done
Sprints
Communication Plan
Quality Planning
Quality Control
Quality Assurance
Quality Improvement

Plan
Do
Check
Act
What’s done
efficient plan.
When it’s done
Week 3
Completion
Pass/Fail
Status

YES
NO
Under Review
Requirements
R-1
Ticketing System
X
R-2
Ticket Automation
X

Unit Test Cases
Description
UT-20
Network throughput speed test - Network throughput test to
meet specifications – Exit criteria –Network speed to reach
specifications
X
Pass
Description
UT -3
ISP Cloud circuit test - Data Test packets set from router – Exit

criteria = Data packet arrive at ISP cloud
X
Pass
Description
UT - 8
VoIP connection speed test outbound - VoIP data packets sent
to the ISP cloud and the cloud receives it – Exit criteria - VoIP
data sent form the cooperate office to the ISP cloud and seen
X
Pass

UT - 9
VoIP data packets sent from the ISP cloud and received - VoIP
data packets sent from the ISP cloud and received – Exit criteria
- VoIP data packets reaches the cooperate office from the ISP
Cloud
X
Pass
UT - 4
DS3 circuit tests - Data test packets sent from host site and
remote sites to the ISP – Exit criteria - Data test packets reach
destinations
X
Pass
Requirements
Quality Planning
Quality Control
Quality Assurance
Quality Improvement

Plan
Do
Check
Act
What’s done
When it’s done
Resources
Quality Planning
Quality Control
Quality Assurance
Quality Improvement
Plan
Do
Check
Act

What’s done
each.
When it’s done
Sprints
Design
Quality Planning
Quality Control
Quality Assurance
Quality Improvement
Plan
Do
Check
Act
What’s done

the project
When it’s done
Sprints
Quality Planning
Quality Control
Quality Assurance
Quality Improvement
Plan
Do
Check
Act
What’s done
When it’s done

Sprints
Work Breakdown
Quality Planning
Quality Control
Quality Assurance
Quality Improvement
Plan
Do
Check
Act
What’s done
When it’s done
Sprints

Communication Plan
Quality Planning
Quality Control
Quality Assurance
Quality Improvement
Plan
Do
Check
Act
What’s done
efficient plan.
When it’s done
Week-4

Completion
Pass/Fail
Status
YES
NO
Under Review
Requirements
R-1
Ticketing System
R-2
Ticket Automation

R-3
VoIP upgrade
R-4

Requirements
Quality Planning
Quality Control
Quality Assurance
Quality Improvement
Plan
Do
Check
Act
What’s done
When it’s done

Resources
Quality Planning
Quality Control
Quality Assurance
Quality Improvement
Plan
Do
Check
Act
What’s done
each.
When it’s done
Sprints
Design

Quality Planning
Quality Control
Quality Assurance
Quality Improvement
Plan
Do
Check
Act
What’s done
the project
When it’s done
Sprints
Quality Planning
Quality Control
Quality Assurance
Quality Improvement

Plan
Do
Check
Act
What’s done
When it’s done
Sprints
Work Breakdown
Quality Planning
Quality Control
Quality Assurance
Quality Improvement
Plan
Do
Check
Act

What’s done
When it’s done
Sprints
Communication Plan
Quality Planning
Quality Control
Quality Assurance
Quality Improvement
Plan
Do
Check
Act
What’s done
efficient plan.

When it’s done
Week-5
Completion/Status
Pass/Fail
Statu
YES
NO
Under Review
Requirements

R-1
Ticketing System
R-2
Ticket Automation
R-3
VoIP upgrade

R-4
Quality Planning
Quality Control
Quality Assurance
Quality Improvement
Plan
Do
Check
Act

What’s done
When it’s done
Resources
Quality Planning
Quality Control
Quality Assurance
Quality Improvement
Plan
Do
Check
Act
What’s done
each.

When it’s done
Sprints
Design
Quality Planning
Quality Control
Quality Assurance
Quality Improvement
Plan
Do
Check
Act
What’s done
the project
When it’s done

Sprints
Quality Planning
Quality Control
Quality Assurance
Quality Improvement
Plan
Do
Check
Act
What’s done
When it’s done
Sprints

Work Breakdown
Quality Planning
Quality Control
Quality Assurance
Quality Improvement
Plan
Do
Check
Act
What’s done
When it’s done
Sprints
Communication Plan
Quality Planning
Quality Control

Quality Assurance
Quality Improvement
Plan
Do
Check
Act
What’s done
efficient plan.
When it’s done

References:
Akinci, U. (2010). How to write a Documentation Plan.
Retrieved from
https://www.technicalcommunicationcenter.com/online-
classes/how-to-write-a-documentation-plan/.
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, A., (2019.) Does your QA Team Structure Pass the
Test. Retrieved from https://igniteoutsourcing.com/it-
outsourcing/qa-team-structure-roles-responsibilities/?
F, K. (2018, November 18). Document Control Plan:
Introduction, Plan Content, Examples. Retrieved from
https://www.brighthubpm.com/monitoring-projects/102112-
example-of-a-document-control-plan/.
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
Kienitz, P. (2017). Pros and Cons of Waterfall Software
Development | DCSL Software Ltd. Retrieved 1 December 2019,
from https://www.dcslsoftware.com/pros-cons-waterfall-
software-development/
Minasi, M. (2014). Mastering Windows Server 2012 R2.
Indianapolis: Sybex.
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, J., (2017.) 14 Examples of Quality Objectives.
Retrieved from https://simplicable.com/new/quality-objectives
Stanek, W. R. (2013). Microsoft Windows server 2012 inside
out
Telerik. (n.d.). RadEditor End User Manual. Retrieved from
https://d31ghwrlt97cgl.cloudfront.net/RadEditorAjaxEndUserM
anual.pdf
Unknown. (2018.) QA Activities in a Waterfall Process.
Retrieved from https://qatestlab.com/resources/knowledge-
center/waterfall-process/
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
Online Ticketing
Customer Service
Tickets
Persistence
Security
UML Component Diagram: Online Ticketing
order
access
control
encryption
dataAccess
dataAccess
VPN
Internet
Customer

Questioning Strategies Part 1 Questioning StrategiesSocial .docx

Questioning Strategies Part 1 Questioning StrategiesSocial .docx

Recommended

Recommended

More Related Content

Similar to Questioning Strategies Part 1 Questioning StrategiesSocial .docx

Similar to Questioning Strategies Part 1 Questioning StrategiesSocial .docx (20)

More from audeleypearl

More from audeleypearl (20)

Recently uploaded

Recently uploaded (20)

Questioning Strategies Part 1 Questioning StrategiesSocial .docx