Risk Mitigation
ceaukis28c
ProjectDevelopment.docx
Group 1
Participating members:
Raphael Brown
Deandre Kralevic
Shaun Cummings
Matthew Dunn
Running head: PROJECT DEVELOPMENT 3
PROJECT DEVELOPMENT 3
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 1: Overview of the project (from IT487) 7
(Week 1) Section 2: Requirements (from IT487) 9
(Week 1) Section 3: Design (from IT487) 11
(Week 1) Section 4: System development methodology 13
(Week 1) Section 5: Work breakdown structure 15
(Week 1) Section 6: Communication plan 17
(Week 2) Section 7: Quality Assurance Plan 19
Description of the type of quality planning 19
Figure 4: Integration Testing Flowchart 24
Table 4: Integration Testing 25
Software Defect Report Template 31
Table 6: Software Defect Report Template 31
Table 7: Risk Register Example 33
(Week 3) Section 8: Documentation plan 37
Document Control Plan Maintenance 38
Document Control Plan Updates 40
Documentation for Management 41
Duration to complete each task 44
Systems/Network Administration Manual Template 45
System Administration Tasks 51
System/Network Administration Roles 52
Relationship to Other Plans 53
Network Communications Architecture 54
System/Network Administration 56
Guidelines for Shutting Down a System 56
How to Shut Down a Server Unix based system 57
Turning Off Power to All Devices 57
Monitoring Performance and System Activity 57
Maintaining Audit Records of System Operation 58
System/Network Administrator privileges 59
Adding/Deleting User Logins 59
Adding/Deleting User Groups 61
User Roles/Responsibilities 62
Use the system parameters to: 64
Requirements for Print Servers 65
Printer Configuration Information 65
Guidelines for setting up security 68
Changing the "sa" Login Password 68
Maintenance Schedule (Daily, Weekly) 72
Running unscheduled backups 73
Off-Site Storage Procedures 73
Maintaining Hardware and Software Configurations 74
Installing Software/Hardware 74
Maintaining Lists of Serial Numbers 74
Maintain Property Inventory 74
About Galactic Customer IT services. 76
About Service Ticket Master 76
Forwarding a Ticket (Manually ) 77
Creating Automated Workflow 78
Automated Patches and Updates 78
(Week-4) Section 9: Quality Assurance and results of test-case execution 80
Integration Testing 80
Procedure for executing Test Case: 81
Procedure of Executing Test Case: 83
Hardware Certification Testing 92
Section 10 – Project closure 95
QUALITY MANAGEMENT REPORT TEMPLATE 96
System Development Methodology 97
PROJECT DEVELOPMENT 3
(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 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.
.
(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.
Figure 1
Figure 1: 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.
Figure 2
Figure 2: 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 because 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).
Figure 3: WBS Levels
(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, which it 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.
Table 1: Communication
Table 1
|
Stakeholder |
Risk Content |
Method |
Frequency |
|
Project Managers, Team Members |
cost |
|
As required |
|
Program Manager, Project Managers |
performance |
memos |
weekly |
|
Program Manager |
training |
Manager program control file |
As needed |
|
Program Director, |
schedule |
|
As required |
(Week 2) Section 7: Quality Assurance Plan
Description of the type of quality planning
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
Table 2
Unit testing plan
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 is 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
Table 3: Unit Test Plan
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.
Figure 4: Integration Testing Flowchart
Table 4: Integration Testing
|
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
Table 5: 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 |
High |
Regression 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
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
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.
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
Table 6: Software Defect Report Template (Reichert, 2019
|
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 |
Risk management strategies
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 on the whole 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.
Table 7: Risk Register 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
Table 8: Risk Source
Project Risk Analyses
Qualitative
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
Quantitative
Table 9: Risk 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 |
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
The team members have decided to develop three user documents for three audiences. The audiences selected are Management, Network/System Administration, and the end-users. In this Phase the team will be developing the templates necessary for the information that the three audiences will need. Some of the information will be technical in nature, Instructional in nature and informational in nature with diagrams where necessary. The development of the documents started on November 28, 2019 with the template for each audience to be complete by December 04, 2019. The full audiences’ documents are expected to be complete by December 17. 2019.
The management documentation (beta version) will be disseminated before the product is complete. It will more than likely be created while the project is in the development phase. However, if there are any changes to the product after the management manual is complete and disseminated then the team will amend the manual and produce hard copies in order for the managers to take home and study before they have to become compliant on the new equipment. The timeline is to be in production two weeks after the December 17th date. Final copies to be complete and giving out a week after completion of project.
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
From: Connie Farris and Development Team
Date: 12/02/2019
Subject: Design Plans
Table of Contents
Documentation for Management 1
Duration to complete each task 5
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.
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 |
Table 10: Revision History Table
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
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 |
6 days |
|
Windows server Establishment (Minasi, 2014). |
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 |
Table 11: Project Plan Table
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
3062 Argyle RD1
Gainesville, Florida
32609
USA
Tel: 352-376-5555 Fax: 352-351-5555
Last edited: 15 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.
Contents
1.2 System Administration Tasks 8
1.3 System/Network Administration Roles 9
1.4 Relationship to Other Plans 10
2.2 Network Communications Architecture 11
3.2.1 Secondary Site Contacts 12
4 System/Network Administration 13
4.1.1 Guidelines for Shutting Down a System 13
4.1.2 When to Shut Down a System 13
4.1.3 System Shutdown Commands 13
4.1.4 How to Shut Down a Server Unix based system 14
4.1.5 Turning Off Power to All Devices 14
4.3 Monitoring Performance and System Activity 14
4.4 Maintaining Audit Records of System Operation 14
5.1 User Types and Privileges 16
5.2 System/Network Administrator privileges 16
5.3 Adding/Deleting User Logins 16
5.5 Setting User Permissions 18
5.6 Adding/Deleting User Groups 18
5.7 Changing User Information 18
5.8 Changing User passwords 19
5.8.1 User Roles/Responsibilities 19
5.8.2 Dropping Users / Groups 20
7.3 Requirements for Print Servers 23
7.4 Printer Configuration Information 23
7.5 Setting up Local Printers 24
7.6 Setting up Print Server 24
7.7 Setting up Print Clients 24
8.3 Guidelines for setting up security 26
8.3.2 Changing the "sa" Login Password 26
8.3.3 When to enable auditin g 27
8.3.4 Assigning login names 27
8.6.1 How to count licenses 29
9.1 Maintenance Schedule (Daily, Weekly) 30
9.2 Running scheduled backups 32
9.3 Running unscheduled backups 32
9.4 Off-Site Storage Procedures 33
10.1 Maintaining Hardware and Software Configurations 34
10.2 Maintaining Floor Plans 34
10.3 Installing Software/Hardware 34
10.4 Maintaining Lists of Serial Numbers 34
10.5 Maintain Property Inventory 34
11 Frequently Asked Questions 35
Document History
Document History will be recorded here, however there are no documents to place here 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 |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Table 12: Revision History Table
Reference Documents
Please see the following documents for more information:
|
Document Name |
Version |
Author |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Table 13: Reference Documents
Distribution List
This document has been distributed to those listed in the table below:
|
Name |
Position |
Company |
Action |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Table 14: Distribution List Table
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 use commands 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] |
Table 15: Relationship Table
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] |
|
Table 16: Software Description Table
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
This is the official address of the site(s).
Primary Site Contacts
|
Primary Contact |
Role |
Phone |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Table 17: Primary Site Contacts Table
|
Secondary Contact |
Role |
Phone |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Table 18: Secondary Site Contact Table
System/Network Administration
This section covers procedures for maintaining the file system.
Guidelines for Shutting 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] |
Table 19: System Shutdown Information Table
|
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. |
|
power off |
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. |
Table 20: Systems Shutdown Commands Table
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.
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.
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
This is where the procedures to create and update maintenance reports are kept
User and Group Accounts
· System Administrators always have access permissions on all systems objects .
· Network Administrators always have access permissions on all network objects
· Security Officers can always access the audit trail tables in the security database.
The system will recognize the following types of users:
|
Type |
Privilege |
|
System Administrators |
Describe privilege |
|
Network Administrators |
Describe privilege |
|
Security Officers |
Describe privilege |
|
Operators |
Describe privilege |
|
Other users (also known as "public") |
Describe privilege |
Table 21: Privilege Table
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 |
|
Table 22: Privilege Impact Table
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 |
|
Table 23: Actions Table
· 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 |
Table 24: Tasks Table
|
Task |
Required Role |
Command or Procedure |
Database |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Table 25: Setting Used Permissions Table
|
Task |
Required Role |
Command or Procedure |
Database |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Table 26: Adding/Deleting User Groups Table
|
Task |
Required Role |
Command or Procedure |
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 |
Table 27: Changing User Information Table
Changing User passwords
|
# |
Action |
|
1 |
|
|
2 |
|
|
3 |
|
Table 28: Changing User Password Table
|
Role |
Responsibility |
|
Enter role type |
Describe the responsibilities assigned to this role |
|
Enter role type |
Describe the responsibilities assigned to this role |
|
Enter role type |
Describe the responsibilities assigned to this role |
Table 29: User Roles/Responsibilities Table
Table 30: Dropping Users / Groups Table
Server Administration
The procedures to setup servers, including naming conventions and standards will be written up here.
The procedures to create server directories; identify the existing directories will be written here.
The procedures to create server drive mappings; identify existing drive mappings will be written here.
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.
|
# |
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). |
Table 31: System Parameters Table
Printer Administration
This section discusses procedures for installing, operating, and maintaining printers.
This section will be used to describe maintenance contracts, procedures to include installation and configuration of printer drivers, and equipment information.
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).
Steps for setting up local printers.
1. Step 1
2. Step 2
3. Step 3
Steps for setting up print servers.
1. Step 1
2. Step 2
3. Step 3
Steps for setting up print clients.
2. Step 2
3. Step 3
Security Procedures
Below is the process for obtaining identifications (IDs) and passwords. Include information concerning network access and confidentiality requirements.
|
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. |
Table 32: Security Features Table
|
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. |
Table 33: Security Features Table
Guidelines for setting up security
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.
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.
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.
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.
The passwords help to 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
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.
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.
|
Task |
Mon |
Tues |
Wed |
Thurs |
Fri |
Sat |
Sun |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Table 34: Daily Schedule Table
|
Task |
Mon |
Tues |
Wed |
Thurs |
Fri |
Sat |
Sun |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Table 35: Weekly Schedule Table
|
Task # |
Jan |
Feb |
Mar |
April |
May |
June |
July |
Aug |
Sept |
Oct |
Nov |
Dec |
|
Task |
|
|
|
|
|
|
|
|
|
|
|
|
|
Task |
|
|
|
|
|
|
|
|
|
|
|
|
Table 36: Monthly Schedule Table
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
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
Inventory Management
Maintaining Hardware and Software Configurations
Maintaining Lists of Serial Numbers
Frequently Asked Questions
How do I [enter FAQ]?
Answer:
How do I [enter FAQ]?
Answer:
How do I [enter FAQ]?
Answer:
The title page will have the title of the product along with the logo. The version number and revision dates will also be labeled here. The company information will be located on the bottom of this page to include name, address, phone number, and email.
This will display all sections with page numbers. The appendixes, tables, and sub-sections will be listed as needed.
This section will have two sub-sections: Purpose and Intended Use.
The purpose will briefly describe the intent of this guide.
The Intended Use will describe capabilities and uses of the software.
About Galactic Customer IT services.
A brief summary of who are company is and what we provide to the customer. This is a great time to provide the user with information on all services the company offers.
This will provide a brief summary on what the software is and what it can do. This will provide the user information on what solutions this software will provide for them.
This will provide screenshots of the software with strong emphasis on key features. Each feature will be shown and explained briefly.
This will provide a brief explanation of the function of the system. This section has the following sub-sections: Creating a Ticket, retrieving a Ticket, Forwarding a Ticket (Manually), and Automated forwarding Setup.
This will explain how to create a ticket manually. Screenshots will show the process step by step. This will also outline the steps needed for a customer to generate a ticket remotely.
This will explain how to search, edit, and update an existing ticket. The user will be provided screenshots and step by step instruction to complete this task.
Forwarding a Ticket (Manually)
This will provide the process to select a ticket to be forwarded. This will also provide the process on raising or lowering the ticket priority.
This will explain to the user how to set up automated forwarding. The user will be guided to allow the software to access their existing DBMS.
This section will provide a description of how this software can manage workflow. This section will have the following sub-sections: Creating Automated Workflow and Automated Patches and Updates.
This will describe the necessary steps to allow their customers to generate a self-service ticket. The user will be instructed to provide permissions for the software to process all remote generated tickets.
This will guide the user to allow the software to initiate the release of patches and updates. The user will provide access to their server that contains the patch/updates and the software will release the patch/update to the customer.
This will be a quick start guide for the VoIP services that is included with their service package. All features and buttons will be described with the appropriate screenshot for each. A short video will also be provided to explain answering and initiating a call.
This will include Frequently Asked Questions with answers.
This section will cover all known errors, bugs, and problems. Each problem will be identified by name, a description of the problem, and the proper way to troubleshoot the problem with expected results.
This will provide all contact information for support of the product. This will include support email addresses and phone numbers. This section will also provide an area to write their product id # and access code.
This will provide the user with an index of the entire guide. It will provide an alphabetical list of names and subjects, with the associated reference pages.
This will provide the user with multiple pages to write notes. This is also the end of the user manual.
(Week-4) Section 9: Quality Assurance and results of test-case execution
Integration Testing
The integration test is performed to ensure cohesiveness with all the software parts that are integrated together. It specifically targets the interfaces that the two units share with each other. The main objective of this testing is to expose the faults if any, within the interfaces between the integrated software components and the new network that is being configured to the system. (Software Testing Fundamentals, 2019)
The set-up procedure that we are aiming for will be using the Incremental Approach. This approach will allow us to join the units that are logically related. After that, the other units are added and tested until all units have been integrated and tested successfully. The company will utilize what are known as a Stub and Driver to conduct the tests. The Stubs job is to select the unit that is to be tested next while the Driver selects the unit that will be tested. (Guru99, 2019)
Procedure for executing Test Case:
We will be testing each logically related unit first. Once that is complete, we move on to the other units. This is what we will follow:
|
Test ID |
Test Case Objective |
Test Case Description |
Expected Results |
|
0001 |
Check interface link between the network and the company’s PC’s |
Enter network creds in all systems and click on the sign-in button |
Receive the notification that company is connected to internet |
|
0002 |
Check the connection link between the ticketing system and the network |
Attempt to connect to the network from the ticketing software by logging into the network from employee interface |
Employee has access to test simulated customer ticket request |
|
0003 |
Check the interface link between email login and the network |
Attempt to connect to company email via the internet |
User can login into their email via the internet |
|
0004 |
Check the interface link between the ticketing system and the company’s PC’s |
Log into the system with the employee creds |
System should allow the user to connect to the software. |
Table 37: Procedure for executing Test Case Table
The expected results will be the fact that all tests prove that the system will connect to the new network. We also expect that the software that was created prior to the new network being installed will function correctly when connected to the network as well. All activity from the company if needed should function properly when connected to the internet.
The first test to connect the company’s PCs to the network passed the integration tests. The test involving connecting the ticketing system to the network failed. The failure was due to the static IP being used by one of the company’s PCs. This failure was documented, and a solution was administered (dynamic IP suite) implemented. Retesting occurred and passed. Email testing was completed and passed. Software for the ticketing system and the company’s infrastructure connect.
Unit Testing
The objective of this Unit test is to isolate different parts of source code that needs to be verified that it has the ability to perform the actions that is required by the system. Unit testing consists of testing the smallest parts of the system one “unit” at a time to check for correctness of the source code written in order for the system to function. (Guru99, 2019)
Our setup approach will consist of taking each portion of the new network and ensuring its functionality. We will have our development team work together to produce the outcome that is expected from this system. We will check DNS capability, DHCP connectivity, firewall diagnostics, and gateway functionality. These tests are essential to produce our network.
Procedure of Executing Test Case:
The company will be using Junit. It is a testing tool that focuses on java script. It will be performing the set of tests we need automatically instead of manually. This tool tests the code first then it tests the actual product. It produces results and we document, fix, and retest if needed. (Guru99, 2019)
The expected results are that everything functions correctly as required. The firewall is in place and protects the network and the gateway. While the DNS and DHCP protocols are in-line and functioning properly as well. The gateway is able to route information in and out of the network that is critical for the success of the company.
DNS capability test passed. All naming/IP services functioned as expected and produced the correct websites without any error. DHCP protocol passed after static IP assigning could not function well with the size of the company. Gateway functionality test passed information as well was able to route to its destination without any issues.
System Testing
This stage of testing will be the Black Box testing, which covers what the end-user will be working with. “Black box testing is defined as a testing technique in which functionality of the Application Under Test (AUT) is tested without looking at the internal code structure, implementation details and knowledge of internal paths of the software. This type of testing is based entirely on software requirements and specifications.” (Guru99, 2019)
|
System Testing
|
|
|
Objective of test case |
The objective is to ensure that the complete system application is suitable to use by the end-user and that it is capable to work across the Network/Internet |
|
Setup procedure |
1. Have someone act as an end-user 2. Setup the system under test 3. Have end-user run application 4. Have end-user test print system 5. Have end-user place a test ticket to show up on the monitor and send to remote site printer. |
|
Expected results |
The expected results are that the end-user is able to complete all tasks without issues. |
|
Procedure for executing test case |
End-user runs all system applications including entering service tickets, printing those tickets and test access to the knowledge base setup on the cloud. |
|
Results |
Results are that all parts of the test passed. |
Table 38: System Testing Table
Regression Testing
Regression testing will be finished whenever that there is a change to the hidden code. This will involve returning and running all the unit and mix tests once more. The motivation behind this testing is to guarantee that no new bugs have been presented with the progressions that have been made. Its best to do this kind of testing in an advancement situation first. That way if issues are discovered, they can be fixed before this update is applied to the creation framework. During regression testing it is entirely expected to reflect the product as of now set up and apply these tests to a spurious system to perceive what those progressions influence. This is one of the quality affirmation procedures we will acquire to guarantee quality over amount.
A normal regression testing is performed to verify if the build did not break any other parts of the application by the recent code changes for defect fixing or for enhancement” (Tutorials Point, n.d.).
(Full test) – The system test, will help identify bugs/errors across the entire system. This is one of the techniques for Regression Testing in which every one of the tests in the current test basin or suite ought to be re-executed. This is extravagant as it requires enormous time and assets.
Regression Testing 1.2
|
Test case process |
Expected findings |
Results |
Comments |
|
Install new Windows version and OS with License Keys |
All is working good together |
Pass |
|
Table 39: Regression test 1.2
Test 2.1
|
Test Case Process |
Expected findings |
Results |
Comments |
|
Follow all steps in system settings |
All configurations keep their value |
Pass |
|
|
Check to ensure all network setting have been changed using command prompt |
|
Pass |
Settings are stored and connected |
Table 40: Regression Test 2.1
Test 3.1
|
Test Case Process |
Expected Findings |
Results |
|
|
Set internet zone security |
Per company policy |
Pass |
|
Table 41: Regression Test 3.1
Test 4.1
|
Test Case Process |
Expected Findings |
Results |
|
|
User agent |
Reload all plugins and validate browse |
Pass |
|
Table 42: Regression Test 4.1
Network-readiness Testing
Network-readiness testing is just what it says, which is a test to ensure that the Network will be ready to connect the system to it for use.
|
Network-readiness Testing |
|
|
Objective of test case |
The objective for this test case is to ensure that the network is ready to handle the system applications that will used over it. |
|
Setup procedure |
To do the network-readiness test, Network testing tools will be needed. Certain network tool will be placed at different location on the network. |
|
Expected results |
The expected results will be that the Network Infrastructure will pass the test that are applied. |
|
Procedure for executing test case |
1. Connect a bandwidth tester. 2. Test Managed switches for bad ports that can affect data transmission 3. Test routers for routing problems and correct routing table issues. 4. Do a speed-test through the Internet and to the Cloud. 5. Test VoIP circuit to ensure no jitter. 6. Test to see if computers and all other equipment can communicate on the network. |
|
Results |
All test applied to the network passed after one issue was found with one link weeks after install and past original test. Issue was moister getting into the Telco DS3 system. |
Table 43: Network-readiness Testing Table
Recovery Testing
|
Recovery Testing |
|
|
Objective of test case |
The objective of this test case is to ensure if for any reason that there is an outage whether man’s error or by nature that the network and system can be restored as-soon-as-possible. |
|
Setup procedure |
1. Ensure that an off site mirrored hot system is running to keep data backed up 2. Ensure good equipment is programmed and ready to install asap. 3. Ensure IT and Facilities staff are ready for such occurrence 4. Ensure that a backup network will be available if an outage happens |
|
Expected results |
The expected results should be that the systems and Network will be back online after an outage incident. |
|
Procedure for executing test case |
Have IT staff and Facilities Staff in place and ready for testing, do mock network outages, do System failure tests, do Natural Disaster recovery drills. |
|
Results |
After doing a mock recovery test all went well Recovery test passed. |
Table 44: Recovery Testing Table
Penetration testing,
|
Penetration testing |
|
|
Objective of test case
|
This test involves the simulated attack to put the defenses in place on the network to the test. This will involve a two-fold attack on what has been previously determined to be the weakest areas on the previous network. The attacks will be taken out both internally and externally to attempt to cover all possible methods of attack or internal sabotage. The goal will be to ensure the steps taken to improve the network didn’t create additional vulnerabilities and fixed the previous issues. |
|
Setup procedure
|
The external test will be a double-blind white test carried out by HackerLite who will subcontract an employee who won’t be aware what company they are testing while internal security personnel won’t be given advance warning that an external penetration test is being carried out. This test specifically will be used to created more advanced protections for the web application firewall, which protects the network when being used over the larger internet by customers and employees (CyberX, 2019). The internal test will be a targeted test where a system engineer gives a white hacker a set of valid credentials to access an employee sub area of the database system and then works with the system engineer to attempt to gain access to confidential employee information and other area outside that access privileges.
|
|
Procedure for executing test cases
|
The external hacker will attempt to gain access to sensitive information by using dynamic analysis to understand the system and then enter through the Application Protocol Interface, as that was the weakest area defined in the last iteration. The internal hacker will use their privileges and connections from inside the network to determine the abilities and methodologies used by malicious intruders or employees and show them to the system administrator. This will be used as a learning experience to get used to the ideas and methods behind attackers’ motivations.
|
|
Explored Methods – Reported by hackerlife |
Search engine results including the types of software systems being used, hardware purchases and personnel lists. Reverse DNS searches to gather related data and information. Social media searches to look up locations and habits. Trash diving to find important sensitive documents and general surveillance to gain access to detailed schedules or unlocked personal computers (cyberX, 2019). |
|
Expected results
|
Results of the testing should show a readiness to identify and eliminate any and all threats, be they internal or external. |
|
Results |
The internal hacker showed little ability to physically access the various areas of the building due to a combination of physical and digital locks that reduce tampering by automatically triggering a security camera when in use. He was able to use the access give to him to make minor alterations to shipment details and change or cancel several internal orders. Without an employee presence these changes would not have been noticed until they had been processed through the system. These results show that a record or notification of a change in manifests should be recorded or noted in the system to prevent future tampering (Imperva, 2019). The Digital hacker was able to gain access to the company’s API and remain in the system long enough to gain access to the database and make much of the same changes the internal hacker was able to gain access to. Once changes were attempted to be made to financial records, including routing and account numbers the system detected the threat and reported it and the database was disconnected before the entire database was breached. They were able to access and make the initial changes due to them acquiring information that was physically thrown out by an employee. Critical changes should be made to educate employees on the dangers of not shredding important documents. |
Table 45: Penetration Testing Table
Migration Testing
Table 45: Migration Testing Table
Hardware Certification Testing
|
Hardware Certification Testing |
||||
|
Objective |
Setup |
Expected Results |
Procedure |
Results |
|
Minimum Requirements – This test will use the minimum hardware requirements to perform several user actions within the software. |
CPU – 1 GHZ x86 Memory – 2GB RAM HDD – 200 MB free space Software version: 1.0 |
The software will run on the minimum hardware requirements without error. User interactions should not take longer than 5 seconds to process. |
The test PC has the minimum hardware with V1.0 installed. Average user interactions will be performed, and timings will be documented. |
Software successfully ran on the minimum requirements. Each user action was processed within 4 seconds. |
|
Recommended Hardware Requirements – This test will use the recommended hardware requirements to perform several user actions within the software. |
CPU – 2 GHZ Dual Core 64-bit Memory – 4GB RAM HDD – 200 MB free space Software version: 1.0 |
The software will run on the Recommended hardware requirements without error. User interactions should not take longer than 5 seconds to process. |
The test PC has the recommended hardware with V1.0 installed. Average user interactions will be performed, and timings will be documented. |
Software successfully ran on the recommended hardware requirements. Each user interaction was processed within 1.5 seconds. |
|
System Hardware stress test – will test the entire system to show the limits and when it will break. Users will concurrently create, search, edit, and update tickets across the entire system. |
The system will perform normal daily operations. The test will start implementing 10 users at a time. The test will continue until the system fails. |
The system will perform normally until 200 concurrent users are active on the system. |
The system is active with a single user. Every 10 minutes 10 users will be added to the system. At every 50 users, the test will run for 30 minutes to test stability. |
The system performed better than expected. System started to drop performance at 100 users. The system was able to support 150 users without major performance issues. The system crashed at 300 users. |
Table 46: Hardware Certification Testing
Ready-for-use Testing
Table 47: Ready for use Testing Table
Section 10 – Project closure
QUALITY MANAGEMENT REPORT TEMPLATE
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.
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.
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 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 |
||||
|
|
|
|
|
|
|
|
|
|
Completion |
Pass/Fail |
|
|
|
|
Description |
|
|
|
|
|
UT-1 |
Entrance criteria Application software installed on server. Final ticketing application test with end-user input data which should show up on the monitor and print system. Exit criteria Tickets seen on monitor and on printer |
X |
|
Pass |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Project Requirements |
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 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 |
Planning phase: client identified these resources |
Project development & quality assurance phases |
Project development & quality assurance phases |
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 |
Planning phase: client identified these resources |
Project development & quality assurance phases |
Project development & quality assurance phases |
Sprints |
|
|
|
|
|
|
|
|
|
System Development Methodology |
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 |
Planning phase: client identified these resources |
Project development & quality assurance phases |
Project development & quality assurance phases |
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 |
Planning phase: client identified these resources |
Project development & quality assurance phases |
Project development & quality assurance phases |
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 |
Planning phase: client identified these resources |
Project development & quality assurance phases |
Project development & quality assurance phases |
Project development, quality assurance, and sprint phases |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Week-2 |
|
Completion |
Status |
|
|
|
|
|
|
|
|
|
|
|
YES |
NO |
|
Under Review |
|
|
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 Test Cases |
||||
|
|
|
|
|
|
|
|
|
Completion |
Pass/Fail |
|
||
|
|
Description |
|
|
|
|
|
UT-2 |
Entrance criteria Network communication lines installed. Ticketing system network connection test - Data from ticketing system sent to router Exit criteria Data seen at Router |
X |
|
Pass |
|
|
|
|
|
|
|
|
|
|
|
Completion
|
Pass/Fail |
|
|
|
|
Description |
|
|
|
|
|
UT-5 |
Telco communications lines installed and tested and released. Bandwidth test - Network bandwidth test to meet specifications Exit criteria No bottleneck in the network |
X |
|
Pass |
|
|
|
|
|
|
|
|
|
|
|
Completion
|
Pass/Fail |
|
|
|
|
Description |
|
|
|
|
|
UT-7 |
Entrance criteria- Telco communication lines installed tested and released. 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 |
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 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 |
Planning phase: client identified these resources |
Project development & quality assurance phases |
Project development & quality assurance phases |
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 |
Planning phase: client identified these resources |
Project development & quality assurance phases |
Project development & quality assurance phases |
Sprints |
|
|
|
|
|
|
|
|
|
System Development Methodology |
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 |
Planning phase: client identified these resources |
Project development & quality assurance phases |
Project development & quality assurance phases |
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 |
Planning phase: client identified these resources |
Project development & quality assurance phases |
Project development & quality assurance phases |
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 |
Planning phase: client identified these resources |
Project development & quality assurance phases |
Project development & quality assurance phases |
|
|
|
|
|
|
|
|
|
|
Week 3 |
|
Completion |
Pass/Fail |
Status |
|
|
|
|
|
|
|
|
|
|
YES |
NO |
|
Under Review |
|
|
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 Test Cases |
||||
|
|
|
|
|
|
|
|
|
|
Completion |
Pass/Fail |
|
|
|
|
Description |
|
|
|
|
|
UT-6 |
Telco DS3s install tested and released. Network throughput speed test - Network throughput test to meet specifications – Exit criteria –Network speed to reach specifications
|
X |
|
Pass |
|
|
|
Description |
|
|
|
|
|
UT -3 |
Telco DS3s lines installed, tested and released. ISP Cloud circuit test - Data Test packets set from router – Exit criteria = Data packet arrive at ISP cloud |
X |
|
Pass |
|
|
|
|
|
|
|
|
|
|
|
Completion |
Pass/Failed |
|
|
|
|
Description |
|
|
|
|
|
|
|
|
|
|
|
|
UT - 8 |
Telco DS3s lines installed, tested and released.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 |
Telco DS3s lines installed, tested and released.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 reach the cooperate office from the ISP Cloud |
X |
|
Pass |
|
|
|
|
|
|
|
|
|
UT - 4 |
Telco DS3s lines installed, tested and released. 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 |
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 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 |
Planning phase: client identified these resources |
Project development & quality assurance phases |
Project development & quality assurance phases |
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 |
Planning phase: client identified these resources |
Project development & quality assurance phases |
Project development & quality assurance phases |
Sprints |
|
|
|
|
|
|
|
|
|
System Development Methodology |
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 |
Planning phase: client identified these resources |
Project development & quality assurance phases |
Project development & quality assurance phases |
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 |
Planning phase: client identified these resources |
Project development & quality assurance phases |
Project development & quality assurance phases |
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 |
Planning phase: client identified these resources |
Project development & quality assurance phases |
Project development & quality assurance phases |
Project development, quality assurance, and sprint phases |
|
|
|
|
|
|
|
|
|
Week-4 |
|
Completion |
Pass/Fail |
Status |
|
|
|
|
|
|
|
|
|
|
YES |
NO |
|
Under Review |
|
|
Requirements |
|
|
|
|
|
R-1 |
Ticketing System |
|
|
|
|
|
|
The Ticketing System will be omni-channel supported. (i.e. phone, email, self-service application, and employee input.) |
X |
|
Pass |
|
|
R-2 |
Ticket Automation |
|
|
|
|
|
|
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 |
|
Pass |
|
|
|
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 |
|
Pass |
|
|
|
The application will provide the capabilities to create tickets, provide updates and patches to the system. |
|
|
|
|
|
|
|
|
|
|
|
|
Unit Test Cases |
|||||
|
|
Description |
|
|
|
|
|
|
|
Completion |
Pass/Fail |
|
|
|
UT-10 |
Entrance criteria- All network equipment and network equipment are in place and powered up. End point tests ping test Exit criteria- Pings sent to remote site equipment are seen. |
X |
|
Pass |
|
|
|
|
|
|
|
|
|
|
Requirements |
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 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 |
Planning phase: client identified these resources |
Project development & quality assurance phases |
Project development & quality assurance phases |
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 |
Planning phase: client identified these resources |
Project development & quality assurance phases |
Project development & quality assurance phases |
Sprints |
|
|
|
|
|
|
|
|
|
System Development Methodology |
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 |
Planning phase: client identified these resources |
Project development & quality assurance phases |
Project development & quality assurance phases |
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 |
Planning phase: client identified these resources |
Project development & quality assurance phases |
Project development & quality assurance phases |
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 |
Planning phase: client identified these resources |
Project development & quality assurance phases |
Project development & quality assurance phases |
Project development, quality assurance, and sprint phases |
|
|
|
|
|
|
|
|
|
Week-5 |
|
Completion/Status |
Pass/Fail |
Status |
|
|
|
|
|
|
|
|
|
|
YES |
NO |
|
Under Review |
|
|
Requirements |
|
|
|
|
|
R-1 |
Ticketing System |
|
|
|
|
|
|
The Ticketing System will be omni-channel supported. (i.e. phone, email, self-service application, and employee input.) |
|
|
|
|
|
R-2 |
Ticket Automation |
|
|
|
|
|
|
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 |
|
|
|
|
|
|
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 |
|
|
|
|
|
|
The application will provide the capabilities to create tickets, provide updates and patches to the system. |
|
|
|
|
|
|
|
|
|
|
|
|
|
Project Requirements |
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 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 |
Planning phase: client identified these resources |
Project development & quality assurance phases |
Project development & quality assurance phases |
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 |
Planning phase: client identified these resources |
Project development & quality assurance phases |
Project development & quality assurance phases |
Sprints |
|
|
|
|
|
|
|
|
|
System Development Methodology |
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 |
Planning phase: client identified these resources |
Project development & quality assurance phases |
Project development & quality assurance phases |
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 |
Planning phase: client identified these resources |
Project development & quality assurance phases |
Project development & quality assurance phases |
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 |
Planning phase: client identified these resources |
Project development & quality assurance phases |
Project development & quality assurance phases |
Project development, quality assurance, and sprint phases |
|
|
|
|
|
|
|
Table 48: QBR Table
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/.
Astera, (2019). Migrate Your Data with Centerprise Data Integrator. Retrieved from https://info.astera.com/ETL-Data-Migration- Trial.html?utm_source=bing&utm_medium=cpc&utm_campaign=&utm_term=&utm_content=&utm_product=&msclkid=8b356aab0dac1ff517d83744ea99bec1.
CyberX, (2019). 7 Penetration Testing Phases to Achieve Amazing Results. Retrieved from https://cyberx.tech/penetration-testing-phases/.
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 on 25 November 2019, from https://www.guru99.com/what-everybody-ought-to-know-about-test-planing.html
Guru99, (2019). Integration Testing: What is, Types. Retrieved from https://www.guru99.com/integration-testing.html#3
Guru99, (2019). What is Black Box Testing? Techniques, Examples & Types, Retrieved on 09 December 2019, from https://www.guru99.com/black-box-testing.html
Guru99, (2019). What is Unit Testing. Retrieved from https://www.guru99.com/unit-testing-guide.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
Software Testing Fundamentals. (2019). Integration Testing. Retrieved from http://softwaretestingfundamentals.com/integration-testing/
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/RadEditorAjaxEndUserManual.pdf
Tutorials Point. (n.d.). Retrieved May 27, 2018, from Regression Testing: https://www.tutorialspoint.com/software_testing_dictionary/regression_testing.htm
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
