試執行問題與建議V1

2022-10-03 05:03:02 字數 3305 閱讀 3748

工程技術生產執行管理系統工程錄井異常預警子系統

渤海鑽探工程公司試點過程中存在的問題與建議

一、 合同技術附件中部分未完成的功能:

1. 自動公升級功能

8月份專案組在更新伺服器上發布了乙個新版本的程式供使用者進行自動更新,發現現場小隊使用的系統能對所需的更新檔案進行**,但是**部分檔案後就停止了**(內部支援人員在測試的時候發現,只要在需更新的軟體中,新增了新檔案,就會造成更新失敗),導致更新失敗。

建議:本功能十分重要,建議廠商盡快修復,並在實際應用中測試通過。

2. 資料**功能

資料**分為兩部分,一部分為臨井資料**,一部分為預警模型配置**。合同規定,系統應該實現臨井資料**功能,臨井資料報括現場採集的實時資料和預警資訊資料。首先,**井的資料,是否需要認證?

臨井的定義是怎樣的?如何定義臨井?外油區的井怎麼**資料(即所錄的井所屬區塊並非本鑽探工程公司所屬)?

其次,實時資料資訊量過大,而現場小隊流量有限,該功能是否還需要開發??

建議:1) 因為井的實時資料可能也是涉密資料,因此建議現場用離線系統也要新增使用者認證。關於臨井,定義為**井所在的最小區塊即可。

該功能具體實現過程是,提供現場小隊**臨井資料的介面,預設搜尋本井所在最小區塊的井名,另外,也允許手動搜尋井名**。

2) 關於**實時資料,此功能不需要**臨井的全部實時資料,僅需**異常資訊相關實時資料即可。

3) 預警模型配置**功實現乙個區塊可以自由定義一套預警模型(因為定義的話需要19中異常都進行配置)供現場小隊進行**,另外需要現場更新了後對現場小隊提示更新**

3. 多井對比圖展示

合同中規定有將老井異常資訊採用多井對比圖的方式展示的功能,但是廠商考慮到現場小隊人員電腦效能不佳,此功能的開放可能會導致小隊上的電腦出現不能工作的現象。

建議:多井對比需要同時提取兩口或者兩口井以上的實時資料進行圖形繪製,確實對電腦效能依賴性比較大,此功能的確可能會影響整個軟體的執行。另外,此功能還需要離線端首先**臨井整口井的實時資料,實現起來缺失比較困難。

建議,對比方式不是以實時資料對比的方式進行,而是僅提取異常資訊資料進行對比。

4. 預設預警資訊提示

合同中規定應該實現如下功能:

a、預設資訊條件滿足時(例如提示鑽達深度1000m)臨井在類似情況下存在事故複雜時。b、根據臨井資訊,提示相關人員留意曾經發生的事故複雜資訊。c、臨井實時資料和本井實時資料存在較大差異時。

建議:前兩條應該實現。最後一條,考慮到現場**臨井實時資料困難大,因此,建議僅讀取臨井的預警記錄進行提示即可(如以鑽達某個井深,臨井發生過異常進行提示)。

5、預警預告資訊處理

接收到下級單位的預警預告資訊後,本地系統自動切換到相關井的資訊,實現上下級聯動。根據下級單位上報的預警預告、提示資訊,維護處置結果和答覆。

建議:此功能是實現預警資訊閉環管理的具體體現,因此,建議此功能盡快實現。

二、 試執行過程中管理存在問題:

1. 渤海鑽探工程公司局機關未指定責任領導:

專案組到渤海鑽探工程公司進行試執行工作之前,工程技術分公司並未向渤海鑽探工程公司下達專案試執行的通知,因此導致在試點工程中,渤海鑽探工程公司並未給專案組指定負責領導,造成在試點執行過程中,部分時間試點工作處於無人看管的狀態。

建議:渤海鑽探工程公司指派相關領導主抓本專案。

2. 渤海鑽探工程公司下屬錄井分公司未指明責任人:

本系統設計時,使用者主要定位在工程技術部,生產執行部、生產排程、資訊中心、現場小隊。然而,在下屬錄井分公司試執行過程中,由於沒有正式的專案試執行通知,因此,下屬錄井公司並未指定相關責任人配合專案組的工作。在試點過程中,幫助專案組進行協調工作的主要是信心中心相關人員,然而資訊中心的工作主要是負責實時資料的傳輸,並不關心現場的預警準確率問題。

建議:下屬錄井公司各部門指派相關專家協助專案組工作。

三、 在試執行工作開展之前未確定相關規範

1. 井資料傳輸規範

由於專案組在**伺服器上新增了**設定功能,允許使用者自由選擇井號傳輸到a7,因此就造成部分井在用本系統進行現場預警和遠端傳輸,但是傳輸的這些資料傳輸到錄井公司,並未**的a7,也就造成**系統讀取不到這些井的相關資訊。

建議:工程技術分公司確定傳輸規範,明確傳輸要求。比如,生產井是否需要傳輸(生產井鑽進周期短,是否有必要進行傳輸),是否僅傳輸風險探井?

2、預警資訊確認規範

試點過程中,發現現場小隊確認後的預警通知單,並未達到專案組的預期。比如確認緣由一欄,專案組期望現場小隊工作人員填寫的現場的實際情況,但是傳回到**端的資料顯示,部分小隊都是隨機輸入的一些無用字元。並且現場傳回的資料顯示,部分小隊確認的異常通知單是錯誤的。

另外,重報的概念和其他的確認型別是否衝突,比如本次預報實際確認可以確認為非軟體因素導致的,但是可能也滿足重報的條件,是否優先選擇重報?

建議:工程技術分公司能出具一些異常預警資訊確認準則,協助現場小隊對異常資訊進行確認。

3、部分小隊對異常資訊不進行確認或確認態度不端正

大部分現場小隊工作人員還是能積極配合專案組的工作,對異常資訊作出準確判斷的。但是,從**端統計的資料可以看出,現場仍然有些人員,對確認工作是持消極怠慢態度的,即使對異常進行了確認,確認資訊也不完整。

建議:工程技術分公司能出具一些考核辦法,比如對現場小隊的小隊長進行考核。

4、**端無人進行審核

專案組考慮到現場小隊的工作水平可有會有差異,在確認工作中可能會出現錯誤判斷的情況,因此,專案組在**端新增了對小隊確認資訊進行再確認的功能,讓**端的專家對這資訊進行審核,一方面讓**領導對下屬小隊的工作能力有更直觀的了解,另一方面,也是增加**端資料統計的準確性。但是,在試點過程中,發現這些資料不知道應該由哪些人員進行審核。

建議:工程技術分公司能出具相關審核準則,要求這些工作應該由哪些人員完成。

四、 預警準確率概念的定義

1. 預警準確率概念應該怎麼定義

試點過程中,專案組發現在預警準確這一概念認知上,現場小隊工作人員與專案組之間存在分歧。部分小隊工作人員,認為只有現場出現了事故,而且我們系統也報出了這種事故,這種才叫預警準確。然而,比如就斷鑽具這一事故,之前可能會有鑽具刺這種異常的過渡,但鑽具刺的嚴重程度不同就會造成鑽具會不會刺斷兩種結果,但是系統只能根據刺漏程度**可能會出現斷鑽具,但至於什麼時候會刺斷,程式可能無法做出計算,因此就會造成一次事故多次進行預報的情況。

建議:預警的意義,本身是在異常事故未發生之前作出提示,這本身就面臨一次事故多次進行提示的狀況,之前的多次提示如果現場沒有採取及時有效地措施的話,才可能導致事故,但這些提示並不代表是不正確的。我認為這個概念還需要進行重新定義。

五、 **端資料沒有充分利用

1. 現在**端已經累計傳輸了很多現場人員確認的資料,但是廠商並未安排相關人員對這些資料進行分析,以從中獲取有用資訊。

XX專案試執行報告V1

xx專案 試執行報告 建設方 xx 承建方 xx公司 監理方 xx公司 20xx年xx月xx日 文件控制 更改記錄 目錄第一章引言 1 1.1 編寫目的 1 1.2 專案背景 1 1.3 參考資料 2 第二章方案概述 3 2.1 試執行目標 3 2.2 試執行需求 3 2.3 風險與約束 3 第三章...

雨水回用系統執行分析與評價V1

雨水回用系統 專題分析 1.非傳統水源利用分析與評價 1 非傳統水源使用實測情況 水量使用採集情況 與設計指標對比情況 備註 本專案的非傳統水源替代率 20 2 非傳統水源利用關鍵指標 3 非傳統水源利用效果評價 根據上述計算分析可以得出,2014年1月 5月雨水回用系統的非傳統水源替代率為32.3...

FullHome公司MIS專案建議書 V1

管理資訊系統 mis 專案建議書 上海 軟體技術 shanghai xxsoftware technology co.ltd.版本 1.0 語言 中文 日期 2005 5 24 本文件是針對 公司在管理資訊系統方面的基本需求,結合 軟體技術 以下簡稱 公司 在資訊系統構建上的豐富經驗,而撰寫的專案建...