實現個性化軟件產品的工作流程
王輝（轉載自賽迪網）
2004年02月05日
1. 前言
1.1.個性化產品情況
軟件產品已經基本成型，已經有一個以上的用戶在使用。
軟件產品不是通用軟件，用戶的大體功能相同，但都有用戶個性的需求，并進行個性實現。
1.2.優劣分析
優勢：
1.不是通用軟件，而是對不同用戶進行個性實現，使系統盜版的可能性降低。
2.由多個用戶提出需求，以業務驅動技術進行實現，良好的需求用戶共享，可以保持系統的先進性。
3.核心部分已經完成，從用戶提出需求到系統上線，實施時間短。
劣勢：
1.很容易對于用戶需求使有快速開發方式，頭痛醫頭，腳痛醫腳，測試由于時間緊急、測試數據不完整等原因測試達不到質量要求，使系統穩定性不足。
2.統一版本管理困難，一線人員最怕升級，不知升級后會有什么問題。
3.由于用戶的增多工作戰線會拉的長，易形成救火隊組織。分工不明確，到最后可能開發團體每個人是工程人員，也是開發人員還是測試人員，事情混雜，不能專心一個時間內做一件事情。
1.3.目的
根據以上情況及個人經驗制訂出以下工作流程。
2.工作流程
2.1.名詞定義
個性化需求：單獨為某一個用戶個性所做并不涉及系統核心（委托，轉換，清算，初始化）的需求，需求的失敗編程影響只提實現需求實現代碼內，不應有連鎖影響。
系統需求：涉及系統核心（委托，轉換，清算，初始化）的需求（含由于單一用戶提出的涉及核心的需求，因他個性的需求修改核心，會影響其他用戶）。
2.2.個性化需求流程
1.用戶工程人員提出需求文檔及要求
2.系統開發負責人了解情況后進行分析，如果決定開發進行下一步，否則告訴需求提出人需求被拒絕。
3.對需求進行統一編碼
4.安排相關人員開發，測試人員為用戶工程人員。
5.在緊急或外部開發方式情況可以由工程人員開發，用戶直接測試。
6.測試流程按部門〈測試流程〉進行。
7.測試通過，需求放在〈功能列表〉
8.安排人員更新〈用戶手冊〉
2.3.系統需求流程
1.用戶工程人員或相關人員提出需求文檔及要求
2.系統開發負責人進行內部討論相關性后，如果決定開發進行下一步，否則告訴需求提出人需求被拒絕。
3.對需求進行統一編碼，對需求編寫測試案例
4.安排相關人員開發，安排測試人員
5.測試流程按部門〈測試流程〉進行
6.測試通過，需求放在〈功能列表〉
7.安排人員更新〈用戶手冊〉
2.4.系統升級及新增功能發布流程
1.對于個性化升級在測試完畢后對個性用戶進行升級
2.系統統一升級在每月的月中進行
3.新增功能信息在每月的月中同系統統一升級一起發布
4.緊急BUG問題系統升級可以隨時
5.用戶負責人對用戶進行的程序升級必須記錄在〈用戶維護記錄〉中
6.〈用戶維護記錄〉系統負責人每月必須進行一次審核
3.附錄
3.1.簡明需求
* 表示必須
1 *需求提出人（公司、個人）及聯系方式（電話、MSN等）
2 需求提出的假設（為什么提出本需求，用于解決什么問題，由此可以更深入明確及理解需求）
3*需求的編號（由系統負責人統一編碼，編碼人將本號碼放在程序第一行）
4 *需求的具體要求
1）輸入內容（界面的位置在是業務管理還是系統管理，是新加FORM還是在某上FORM上修改）
2）輸出內容（通過什么查詢到結果，是如果是表要說明表記錄和字段變化，如果是界面說明輸出項）
5需求實現驗證人（本需求驗證人必須明確，最好是需求提出者是驗證人）
6*其他
1）實現代碼時的提示（那個代碼可以復用）
2*）時間完成要求
3）技術支持人
4）業務支持人
5）相關文檔（具體的法規）
3.2.測試流程
1.程序員完成自測試，對測試人員進行需求和功能講解（可選：提交相關《需求說明書》），測試人人員進行桌前程序運行檢查，如果檢查成功下入一下步，否則修改程序。
2.程序員提交程序（相關安裝及使用說明）、功能列表（推薦提供《測試案例》））給測試人員進行確認測試。
3.測試人員在相應的測試時間內完成《測試BUG報告》，中間如果有重大不可測試問題，程序員提供緊急技術支持，在2小時內解決問題，否則結束測試進入第一步。
4.程度員在相應的時間內根據《測試BUG報告》修改程序，添加修改人及時間。
5.提交修訂后《測試BUG報告》和新程序給測試人員時行回歸測試，測試完畢后進入回歸測試，添寫確認人及時間。
6.如果BUG數多于五個，循環進入第一步，否則進行下一步。
7.測試人員添加《功能列表》的測試確認人與時間。
8.發布新版本給用戶進行驗收測試，測試后由安裝或技術支持人員添加用戶確認人及時間（推薦用戶簽字完成《功能確認書》。
3.3.功能列表
文章來源于領測軟件測試網 http://www.kjueaiud.com/