MgtPro_8_QualityMgt

Quality Baseline/Goals

1. Functionality:

a. Suitability:

1. The function of the sub-functions in the system should meet the principle of high cohesion and low coupling.
2. The number of database table rows does not exceed 1 million rows, the maximum capacity of the database does not exceed 1000 GB, and the disk space needs at least 40G. 1000000.
3. All the requirement should be implemented as requirement document says.
4. The maximum number of transactions per day is 3,000.
5. The average number of concurrent transactions is 20, and the maximum number of concurrent transactions is 50.
6. The estimated number of users is 10,000, the number of login users per day is about 3000, and the bandwidth of the network is 100M bandwidth.
7. The system can simultaneously satisfy 10,000 user requests and provide browsing capabilities for 25,000 concurrent users.

b. Accuracy:

1. The data stored by the system should be atomic and persistent.
2. The accuracy of the calculation is 7 digits after the decimal point.

c. Interoperability (Interoperability):

1. The system should have good interaction with the delivery platform.

d. Compliance:

1. Software coding should follow a uniform standard.

2. Reliability:

1. There is a prompt for the input, the data is checked to prevent data anomalies.
2. The system is robust and should be able to handle various abnormal situations that occur during system operation, such as human error, illegal data input, hardware device failure, etc. The system should be able to handle it correctly and avoid it properly.
3. The probability that the service cannot be completed due to the failure of the software system is less than 5‰.
4. The system is required to run 24 hours a day, and the continuous operation failure time of the whole year cannot exceed 10 hours.
5. The system defect rate has a maximum of 1 failure every 1,000 hours.
6. In 1,000,000 transactions, there is a maximum of 1 time when the system needs to be restarted.

3. Usability:

a. Learnability:

1. Within 3 months of the introduction of the product, 60% of users should be able to use it to complete the transfer task within 45 seconds, the failure rate is controlled within one ten thousandth.
2. 60% of users will realize that this is the bank’s online banking within 5 seconds of seeing the product for the first time.
3. 80% of users can successfully buy a book within 5 minutes after receiving a half-hour system introduction training.

b. Operability:

1. Some rural areas have poor network quality and low bandwidth. Guarantee the availability of the system under conditions of poor network environment.
2. In 95% of the failures, the system takes up to 20 seconds to restart.
3. Provide data backup and recovery functions to enable timely recovery and restore of data (provided by hardware and third-party software) when system data is lost due to system errors or other reasons or system data is corrupted.

4. Efficiency:

a. Time Behaviour:

1. In 95% of cases, the general time response time does not exceed 1.5 seconds, and the peak time does not exceed 4 seconds.
2. The time required for the positioning system to display from the click to the first interface must not exceed 300 milliseconds.
3. When the network is unblocked, the time required to dial-up to the GPRS network must not exceed 5 seconds.
4. When the network is unblocked, the website page refresh time does not exceed 10 seconds.
5. In the recommended configuration environment: the login response time is within 2 seconds, the refresh response time of the column is within 2 seconds, the response time of the entry page list is refreshed within 2 seconds, and the response time of the information entry is turned on within 1 second, and the department and personnel list response is refreshed. Time is 2 seconds.
6. Search during the off-peak hours according to the number and name specific conditions, and the search results can be obtained within 3 seconds.

b. Resource Behaviour:

1. CPU usage <=50%.
2. Memory usage <=50%.

5. Maintainability:

a. Changeability:

1. After receiving the modification request, the general modification should be completed within 1-2 days; for the major demand or design modification after the assessment, it should be completed within 1 week.
2. 90% of the BUG modification time does not exceed 1 working day, and the other does not exceed 2 working days.
3. The circle complexity of the code must be within 10.
4. Any method of any object does not allow more than 200 lines of code.
5. Install the new version and keep all database contents and all personal settings unchanged.
6. The product must provide tools to track any database fields.

b. Testability:

1. The maximum circle complexity of a module cannot exceed 15.
2. The delivered system must pass unit testing and be 100% covered.
3. Development activities must use regression testing and allow for a complete test to be re-run within 12 hours.

6. Portability:

1. The code change rate should be less than 20% when the system is migrated.
2. The installation success rate should be greater than 90% when the system is transplanted.
3. Functional integrity should reach 90% and above in the new target environment after system migration.

7. Security

1. Strict access control. After the user is authenticated, the user can only access the data within the scope of his or her rights, and can only perform operations within its scope of authority.
2. Different users have different identities and rights. They need to provide trusted authorization management services under the premise of authenticity of users, protect data from illegal/over-authorized access and tampering, and ensure confidentiality and integrity of data. Sex.
3. Provide running log management and security auditing functions to track the historical usage of the system.
4. Can withstand general malicious attacks from the Internet. Such as viruses (including Trojans) attacks, password guessing attacks, hacking, etc.
5. At least 99% of attacks need to be detected within 10 seconds.
6. Network delivery data should be encrypted. It is necessary to ensure that data is not sneaked, stolen or tampered with during collection, transmission and processing. Business data needs to be encrypted at the time of storage to ensure that it is not hackable.

8. Compatibility

1. The system should support IOS, Android, Windows operating system;
2. The system should support Oracle, DB2 database system;
3. Up to 5% of system implementations need to be specific to a particular operating system.
4. The average time to replace the relational database system is no more than 2 hours, and no data loss is guaranteed.

Quality Metric

The following metrics are majorly used for generating the daily/weekly status report with accurate data during test case development/execution phase and this is also useful for tracking the project status and Quality of the software.

1. percentage Test cases Executed:

This metric is used to obtain the execution status of the test cases in terms of percentage.

$$TestCaseExecuted\% = \frac{No_{TestCaseExecuted}}{Total \space No_{TestCasesWritten}}* 100.$$

2. percentage Test cases not executed:

This metric is used to obtain the pending execution status of the test cases in terms of percentage.

$$TestCasesNotExecuted\% = \frac{No_{TestCasesNotExecuted}}{Total \space No_{TestCasesWritten}} * 100.$$

3. percentage Test cases Passed:

This metric is used to obtain the Pass percentage of the executed test cases.

$$Test Cases Passed\% = \frac{No_{ Test Cases Passed} }{Total \space No_{Test Cases Executed}} * 100.$$

4. percentage Test cases Failed:

This metric is used to obtain the Fail percentage of the executed test cases.

$$Test Cases Failed \%= \frac{No_{ Test Cases Failed }}{ Total \space No_{ Test Cases Executed}}* 100.$$

5. percentage Test cases Blocked:

This metric is used to obtain the blocked percentage of the executed test cases. A detailed report can be submitted by specifying the actual reason of blocking the test cases.

$$Test Cases Blocked \% = \frac{No_{ Test Cases Blocked}}{ Total \space No_{ Test Cases Executed}}* 100.$$

6. Defect Density

$$Defect Density = No_{ Defects identified }/ size$$

(Here “Size” is considered as requirement. Hence here the Defect Density is calculated as number of defects identified per requirement. Similarly, Defect Density can be calculated as number of Defects identified per 100 lines of code [OR] No. of defects identified per module etc.)

7. Defect Removal Efficiency (DRE)

$$Defect Removal Efficiency(DRE) = (\frac{No_{ Defects Found During QA Testing}}{ No_{ Defects Found During QA Testing}} +No_{ Defects Found By End user}) * 100$$

DRE is used to identify the test effectiveness of the system.

8. Defect Leakage:

Defect Leakage is the Metric which is used to identify the efficiency of the QA testing i.e., how many defects are missed / slipped during the QA testing.

$$Defect Leakage = \frac{No_{ Defects Found in UAT }}{No_{ Defects Found in QA Testing.}}* 100$$

9. Defects by Priority:

This metric is used to identify the no. of defects identified based on the Severity / Priority of the defect which is used to decide the quality of the software.

$$\begin{align} Critical Defects\% &= \frac{No_{ Critical Defects Identified }}{ Total \space No_{ Defects Identified} }* 100 \\ High Defects\% &= \frac{No_{ High Defects Identified}}{Total \space No_{ Defects Identified}} * 100 \\ Medium Defects\% &=\frac{ No_{ Medium Defects Identified }}{ Total \space No_{ Defects Identified}} * 100 \\ Low Defects\% &= \frac{No_{ Low Defects Identified}}{Total \space No_{ Defects Identified}} * 100 \end{align}$$