1.         PURPOSE

The major purposes of this documentation is to provide an overview of Quality Assurance Test Info System by listing out in brief the programs, data files, equipment, etc.  

2.         system summary

2.1            Background

This design specification is based upon the information that provided in the product specification by Quality Assurance department from Europe as well requirement clarification with QA & MIS department in Hong Kong to build up a QA Testing Info System on testing data for the QA department in 4 different geographical sites.

The QA Testing Info System is a distributed database system that located in Hong Kong, Shenzhen (PRC), Shanghai (PRC) and Holland (Europe) geographical sites. Each site will have their individual database server to store their local reliability data as well as other locations’ data.  The users of the System are connected to their local site first and then retrieve or update the data to other site according to their authority and functionality.

The SYSTEM will be a client-server approach on integrated PowerBuilder 6.5 as front-end application tools with Oracle 8 as backend Relation Database Management System.  The client workstations’ operating system will run on Microsoft Windows 95, 98 & NT 4.0 in Chinese or English version as well as operation system in server will be a Microsoft Windows NT 4.0 in English version.  Basically the language of the application is displayed in English, furthermore with the ‘Help File’ shall also be in Chinese and English.

Two approaches on data synchorization will be adopted for the SYSTEM to handle the local and remote data accessing. Regarding on the data on security and master code table, the online update through Oracle database link is used to cater those functions on all the inserting, updating and deletion is simultaneously conducted in 4 sites to increase data integrity.  After maintenance on those data by local or global user administrator, a mail will automatically be sent to all user administrators through the email system for notification.  For the rest of the data of transaction (reliability test), Oracle Replication will be proposed to handle those functions for conducting on the batch window (6 to 8 hours).

2.2            OBJECTIVES

The model for QA Testing Info System (SYSTEM) is based upon following major principles:

• Use as less as possible products for reliability testing. (Cost of test chambers, products and testing).
• Maximize the use of all data available.
• Select .the test specimens in such a way that maximum technology elements are involved in each test run.
• To provide management with accurate and timely information on reliability test and for planning and management purpose.
• To streamline the manual operations of Quantity Assurance department through computerization:

• To eliminate the requirement of keeping duplicate records.
• To improve security management.
• To eliminate tedious manual tasks.

3.         system Requirement

3.1            Online and batch services

The online service period would be Hong Kong time from 8:00 am to 21:00 pm for all sites that users on each site can conduct the online functions including data retrieving, inserting, updating and deleting on database.  The details for online services of each site are as follows :

1. Hong Kong    : From 8:00 am to 20:00 pm (Hong Kong time)
2. Shenzhen       : From 8:00 am to 20:00 pm (Hong Kong time)
3. Shanghai        : From 8:00 am to 20:00 pm (Hong Kong time)
4. Holland          : From 14:00 pm to 22:00 pm (Hong Kong time)

The batch service period would be Hong Kong time from 23:00 pm to 7:00 am for data synchnization by Oracle Replication all sites that users on each site cannot conduct any online functions including data retrieving, inserting, updating and deleting on database.  The details for batch services of each site are as follows :

1. Hong Kong    : From 21:00 am to 7:00 am (Hong Kong time)
2. Shenzhen       : From 21:00 am to 7:00 am (Hong Kong time)
3. Shanghai        : From 21:00 am to 7:00 am (Hong Kong time)
4. Holland          : From 23:00 pm to 7:00 am (Hong Kong time)

3.2            Data synchronization

Two approaches on data synchronization will be adopted for the SYSTEM to handle the local and remote data accessing.

1. Security and Master Code Data     :        Online accessing to the database by Oracle Database Link within 4 sites.  For the connecting on remote sites, only the action on save will be built up to the database for reducing the network traffic.
2. Transaction Data                        :    Batch processing to the database by Oracle Replication function within 4 sites.

3.3            Error Handling

Because SYSTEM will be used as distributed database approach, total 4 databases are served to the user functions and the accessing mainly on local database.  For different cases, the error handling will be handling by the application system and the details are as follows:

1. Security and Master Code Data     :        If one of communication link is break around 4 sites, the transaction will not be completed and 3 automatically retry by application system in 1 minute will be performed.  If the connection is still not ok after retry function, an error message will be displayed to alert user to perform the manual retry process.
2. Transaction Data                        :    Batch processing to the database by Oracle Replication function within 4 sites.
3. Batch Replication                      :    If one of communication link is break around 4 sites, the replication will not be completed and automatically retry by application system in 1 hour will be performed.  If the connection is not ok after retry function, an error message will be displayed to alert user to perform the manual retry process.

3.4            Access Control

The SYSTEM provides different access authorities to the operation staff for updating and retrieval. User identity code and password are provided to protect the system from unauthorized access.  All user identity codes and passwords are controlled and allocated by the IT Dept.

3.5            access levels and privileges

An access level gives the user a certain degree of freedom to records and database functions. This degree of freedom consists of a set of privileges. Table 1 lists the privileges per access level.

Table1: Overview of privileges per access level

Role	Authority
Global User Administrator	Maintain the application functions for all users on 4 sites. Maintain the security & master data on 4 sites.
Local User Administrator	Maintain the application functions for all users on local site. Maintain the security data on local site. Maintain the master data on 4 sites.
Author (Full Access)	Maintain the Test Lab, Test Product, Test Severity and Test Result data on local site. Block the data on Test for private use on local site. Print the report on Test data.
Operator (Full Access)	Retrieve the Test Lab, Test Product and Test Severity data on local site. Maintain the Test Result data on local site. Print the report  on Test data on local site

 

Role	Authority
Reader (Read Access)	Retrieve the Test Lab, Test Product, Test Severity and Test Result data on local site. Print the report on Test data. Users are controlled by specific Product Types and Customers for Test Data and Report Printing.

3.6            Logging mechanism

The database trigger will be used to take up the function on performing the logging mechanism on SYSTEM.  Normally, one set of log table will be created to store the log data while the original table to have the action on inserting, updating and deleting.  Some of the transactions will only keep the key information and others will keep the changed information in before and after image.  For the detail on function logging mechanism, the details are also documented on the document of screen layout by each major function.

3.7            CONTROL ON security and master code TABLE CHANGES

Changing information to the database pick tables has to be agreed between all people with full access level and coming from the QA department.  This should be done in a controlled way.  It should be a way is to do this via electronic OK’s from all people concerned before the change can be made effective.

3.8            Others

1. An online function will be built up to cater the global changes on the table of the ‘Defect Code’ information.
2. Program Developer will assist the IT personnel on the global changes on the table of the ‘Technology Group’ by the batch SQL statement.
3. The design on Phase 2 for report function will be followed on the document of report layout.

4.         SYSTEM FUNCTIONS

The below table lists the breakdown of functions provided by SYSTEM, including online and batch mode, by their function ID.

Function ID

Function Name

Mode

Please refer to document on screen and report layout document for reference.

5.         SYSTEM FLOW

This section is show the major process on local and remote database for different functions on SYSTEM and details are as follows:

1. Security Module        : 4 local and remote databases will also be updated and a mail will be sent to each System Administrator.
2. Code Table Module   : 4 local and remote databases will also be updated and a mail will be sent to each System Administrator.
3. Transaction Module   : 1 local database will be updated and remote site will be updated by replication.
4. Report Module          : 1 local database will mainly be retrieved and other remote databases are also able to retrieved for different requirement on functions.
5. Security Module