O2 DATA HANDLING PROCEDURE

RECEIVE

In general, if I send an e-mail that contains or announces the posting of new data or data sources, I will try to use e-mail subject like ‘Data Transfer – COMPANY NAME, DATA TYPE’. If a client sends e-mail or I or the client AIM this data or information about a data posting, then the person receiving the communication should generate this e-mail on our behalf and copy to me, minsk & mike.

DOWNLOAD/ARCHIVE

1. The Database Group is responsible for downloading the data and archiving it in the correct place. However, if you are first into the office in the morning, or last remaining in the office in the evening, and there is no one in the database group available to start the download, then you should start it! Also, if I directly inform you about a download via AIM or e-mail, then YOU should generate the Data Transfer e-mail and YOU must ALSO perform the download! In all cases, MAKE SURE that the Database Group gets the data!
2. Once the download is complete, you should MAKE SURE that the data is archived in the appropriate place:
   1. ALL Client Source data (e.g., PEG/GDF Finder, Kerne, OMV EPIS/GDB, but also any data source files (excel, word, ASCII) received from clients)
   2. ALL CURRENT Client FIELDPRO database versions (e.g., ENI/AGIP Libya V5,235, WILI TIP V6,270, WILI WG_FIELD V3,196)
   3. ALL LATEST Client FIELDPRO database versions (e.g., ENI/AGIP Libya V6,276, WILI TIP V6,276, WILI_WG_FIELD V6,276)
3. The Database Group will maintain a copy of ALL data on the RESNet (Acton) server as follows:
   1. ALL Client Source data - http://www.resnet.com/ftp/Database%20Server/Client%20Source%20Data/
   2. ALL CURRENT Client FIELDPRO database versions - http://www.resnet.com/ftp/Database%20Server/Client%20Current%20FIELDPRO%20Databases/
   3. ALL LATEST Client FIELDPRO database versions - http://www.resnet.com/ftp/Database%20Server/Latest%20Version%20FIELDPRO%20Databases/
4. EVERYONE (testers and developers) should use CURRENT and LATEST Client FIELDPRO databases (NOT DEMO) for testing!
5. You will migrate ALL client databases from CURRENT DIRECTLY to LATEST after EACH update (i.e. from V5 to V6,276 and again from V5 to V6,277 and NOT from V6,276 to V6,277) to make sure that nothing has gotten broken with the migrations.

DISCUSS/PROCESS

The Testing Group (TG) will discuss the data with the Scientific Group (SG) and the Database Group (DG) to determine what actions have to be taken related to the data (generate PCF to migrate or migrate only once, convert to different format, etc.).

RESPOND

1. If the posting is an update of a previously received data source, then you should simply acknowledge receipt and integrity of upload
2. If new functionality is required (e.g., implement migrations or support new data types received), forward the Data Transfer e-mail to me, minsk & mike with information about the functionality required. That e-mail should then be treated like standard task e-mails.
3. If a new PCF is required to process the data, the SG and DG should determine if it can be handled by SG & TG or if it requires assistance/work from the DG. If there are any questions about the data, you should respond to the client/me with those questions.

DO NOT CHANGE E-MAIL SUBJECTS IN YOUR RESPONSES: I WANT TO FOLLOW CONVERSATION THREADS LATER!

FEEDBACK LOOP

1. Once the client or I respond to any questions related to generating a new PCF, you should process in the same way. This loop should continue until ALL tasks are clarified and estimated and decisions made about assignment of the tasks to personnel!
2. Once the feedback loop is complete, the TG should enter PCF tasks in TT like any other, with a time estimation and delivery date.

IMPLEMENT/DELIVER (FAILURE TO DELIVER CLAUSE)

Data migration (PCF) tasks should be handled according to the same rules as tasks in the O2 Task Handling Procedure.

TESTING

Testers should confirm that tasks are indeed delivered in RELEASE (NOT debug) versions (debug testing is only preliminary)! Any task that is incomplete will be marked with Disposition “Rejected” and relevant feedback will be added to the task description: repeat the IMPLEMENT/DELIVER step above considering Rejected tasks as the same priority as the task itself. PROGRAMMERS & TESTERS SHOULD USE CLIENT DATABASES FOR TESTING: demonstration databases are not sufficient!

CLOSE

If testing confirms that the task is complete, the testers should mark the task with Disposition “Tested – Working (can be Closed)”.