個性化產品工作流程

2021-08-29 17:35:13 字數 3062 閱讀 6746

軟體產品已經基本成型,已經有乙個以上的使用者在使用。

軟體產品不是通用軟體,使用者的大體功能相同,但都有使用者個性的需求,並進行個性實現。

優勢:

1.        不是通用軟體,而是對不同使用者進行個性實現,使系統盜版的可能性降低。

2.        由多個使用者提出需求,以業務驅動技術進行實現,良好的需求使用者共享,可以保持系統的先進性。

3.        核心部分已經完成,從使用者提出需求到系統上線,實施時間短。

劣勢:

1.        很容易對於使用者需求使有快速開發方式,頭痛醫頭,腳痛醫腳,測試由於時間緊急、測試資料不完整等原因測試達不到質量要求,使系統穩定性不足。

2.        統一版本管理困難,一線人員最怕公升級,不知公升級後會有什麼問題。

3.        由於使用者的增多任務作戰線會拉的長,易形成救火隊組織。分工不明確,到最後可能開發團體每個人是工程人員,也是開發人員還是測試人員,事情混雜,不能專心乙個時間內做一件事情

根據以上情況及個人經驗制訂出以下工作流程。

個性化需求:單獨為某乙個使用者個性所做並不涉及系統核心(委託,轉換,清算,初始化)的需求,需求的失敗程式設計影響只提實現需求實現**內,不應有連鎖影響。

系統需求:涉及系統核心(委託,轉換,清算,初始化)的需求(含由於單一使用者提出的涉及核心的需求,因他個性的需求修改核心,會影響其他使用者)。

1.      使用者工程人員提出需求文件及要求

2.      系統開發負責人了解情況後進行分析,如果決定開發進行下一步,否則告訴需求提出人需求被拒絕。

3.      對需求進行統一編碼

4.      安排相關人員開發,測試人員為使用者工程人員。

5.      在緊急或外部開發方式情況可以由工程人員開發,使用者直接測試。

6.      測試流程按部門〈測試流程〉進行。

7.      測試通過,需求放在〈功能列表〉

8.      安排人員更新〈使用者手冊〉

1.      使用者工程人員或相關人員提出需求文件及要求

2.      系統開發負責人進行內部討論相關性後,如果決定開發進行下一步,否則告訴需求提出人需求被拒絕。

3.      對需求進行統一編碼,對需求編寫測試案例

4.      安排相關人員開發,安排測試人員

5.      測試流程按部門〈測試流程〉進行

6.      測試通過,需求放在〈功能列表〉

7.      安排人員更新〈使用者手冊〉

1.      對於個性化公升級在測試完畢後對個性使用者進行公升級

2.      系統統一公升級在每月的月中進行

3.      新增功能資訊在每月的月中同系統統一公升級一起發布

4.      緊急 bug 問題系統公升級可以隨時

5.      使用者負責人對使用者進行的程式公升級必須記錄在〈使用者維護記錄〉中

6.      〈使用者維護記錄〉系統負責人每月必須進行一次審核

王輝 從 1994 年開始工作,曾擔任教師、資料庫管理員、主程式設計師、專案經理,現在深圳一家公司工作。可以通過 [email protected]

聯絡。

* 表示必須

1 *需求提出人(公司、個人)及****(**、msn等)

2 需求提出的假設(為什麼提出本需求,用於解決什麼問題,由此可以更深入明確及理解需求)

3*需求的編號(由系統負責人統一編碼,編碼人將本號碼放在程式第一行)

4 *需求的具體要求

1)輸入內容(介面的位置在是業務管理還是系統管理,是新加form還是在某上form上修改)

2)輸出內容(通過什麼查詢到結果,是如果是表要說明表記錄和字段變化,如果是介面說明輸出項)

5需求實現驗證人(本需求驗證人必須明確,最好是需求提出者是驗證人)

6*其他

1)實現**時的提示(那個**可以復用)

2*)時間完成要求

3)技術支援人

4)業務支援人

5)相關文件(具體的法規)

1.        程式設計師完成自測試,對測試人員進行需求和功能講解(可選:提交相關《需求說明書》),測試人人員進行桌前程式執行檢查,如果檢查成功下入一下步,否則修改程式。

2.        程式設計師提交程式(相關安裝及使用說明)、功能列表(推薦提供《測試案例》))給測試人員進行確認測試。

3.        測試人員在相應的測試時間內完成《測試bug報告》,中間如果有重大不可測試問題,程式設計師提供緊急技術支援,在 2 小時內解決問題,否則結束測試進入第一步。

4.        程度員在相應的時間內根據《測試bug報告》修改程式,新增修改人及時間。

5.        提交修訂後《測試bug報告》和新程式給測試人員時行回歸測試,測試完畢後進入回歸測試,添寫確認人及時間。

6.        如果 bug 數多於五個,迴圈進入第一步,否則進行下一步。

7.       測試人員新增《功能列表》的測試確認人與時間。

8.       發布新版本給使用者進行驗收測試,測試後由安裝或技術支援人員新增使用者確認人及時間(推薦使用者簽字完成《功能確認書》。

業務編號

業務名稱

業務描繪需求

分析人及

完成時間

相關功能(模組)

功能描繪

**實現人及時間

自測時間

測試人及

測試完成時間

使用者確認人

及時間

EBS Form個性化的工作原理

之前一直沒怎麼研究它的工作原理,都是直接用。最近有個同事問我問題,說他在個性化編寫的 無效果。解決之後,才發現,原來傳說中的ebs的form的個性化是這樣子實現的。說正題。舉個簡單的例子。我在個性化when validate record編寫了一堆條件。如果沒有,趕忙增加,然後。為什麼?因為,我們一...

EBS Form個性化的工作原理

說正題。舉個簡單的例子。我在個性化when validate record編寫了一堆條件。如果沒有,趕忙增加,然後。為什麼?因為,我們一般在form的block裡面新增的觸發器,其執行層次一般是 override。這樣子會導致乙個後果 你在對應的塊,再用個性化編寫對應的觸發器 上面的例子就是when...

部落格個性化

頁面定製css header 將預設的導航頭遮蔽掉,這樣才能把自己的導航欄加上去 定製自己導航欄的樣式 shwtop ul shwtop li shwtop li a,dropbtn 滑鼠移上去,改變背景顏色 shwtop li a hover,dropdown hover dropbtn shwt...