【PM】資訊化系統軟體開發流程

標籤：

 轉載請註明出處： jiq?欽‘s technical Blog 
軟體開發生命週期

 

建議採用迭代方式，即詳細設計->測試的迭代，概要設計階段會提取出所有需要開發的功能點，這些功能點將會按照優先順序被劃分為3-4個階段，每個迭代階段都會進行詳細設計、編碼和測試，然後與使用者見面進行修正。

所有迭代過程結束之後，再進入整體整合測試、實施以及最後的維護階段。 

1 需求調研和分析

         最終出具《需求調研報告》。需求調研步驟一覽：

整體情況瞭解產出：需求調研報告，補充第一章

調研計劃制定產出：需求調研計劃

具體工作調研產出：需求調研報告，全部補充完整、並確認

需求成果評審產出：需求規格說明書

需求成果錄入產出：錄入到需求管理工具的需求

第一步：整體情況瞭解

目的在於對客戶有個整體瞭解，調研內容包括：

u  系統目標和主要領導的期望：整體把握系統的定位，以後大概要做成什麼樣子。

u  已有系統的建設：看看以前系統做成什麼樣子，客戶為什麼要重新做，哪些地方好的可以借鑒的，哪些地方不好的要避免的

u  部門組織圖和人員角色：知道接下來要找哪些人瞭解具體工作。

u  各個角色涉及的工作項目：瞭解接下來和具體的人瞭解業務工作時需要詢問的範圍。

一般用組織機構圖描述組織機構和人員角色，用二維表格描述各類角色的工作內容，成果補充到《需求調研報告.docx》中。

整體情況瞭解採取的方式可以有很多種：

1向市場部或者產品部進行瞭解，擷取並閱讀相關材料，

2自己打電話同使用者交流；

3同使用者方進行的項目啟動會議；

如果是同使用者交流最好選擇對方中層領導，他們往往對一線工作人員比較瞭解，同時又大概瞭解上面領導的意圖，對系統的定位和期望。劃分清楚部門或角色，弄清楚每個部門或角色的工作內容，就是為了在今後的需求調研中找對正確的人，使今後的調研工作事半功倍。

將瞭解的整體情況錄入到對應的《需求調研報告.docx》中，補充文檔第一章。

第二步：調研計劃制定

         在瞭解了系統的整體情況，即組織機構、使用者角色等資訊後，需要制定一個接下來在使用者現場將要進行的需求調研計劃，參見《需求調研計劃.docx》，同時將《需求調研報告.docx》中補充好的整體情況用紅色加粗字型顯目出來。

         將這兩個文檔發給使用者，提早告知使用者即將進行的現場調研的計劃安排。

第三步：具體工作調研

步驟1：整體情況確認

         之前已經瞭解過一次系統整體情況，這次到使用者現場主要目的是針對自己錄入到《需求調研報告.docx》中的整體情況做進一步深入和確認。

步驟2：商務程序調研

根據前面的調研，已經掌握了系統涉及的角色，以及每個角色的主要工作內容，接下來就是和各類角色的一線工作人員單獨交流瞭解詳細的工作內容，補充完善《需求調研報告.docx》中的二、三、四章。針對每類角色的一線工作人員若有多個，盡量叫在一起，一般和一線工作人員的交流也需要經過多次迭代：

u  第一步：啟動交流，瞭解流程

兩種方式啟動：

方式1：如果已經在上一步清楚了其涉及的工作內容，可以主動逐一詢問，比如“你們在實際工作中是怎麼將購買的產品入庫的？”

方式2：不大清除對方涉及的具體工作內容，可以收集他們使用的報表和單據，詢問報表和單據的用途，通過這種方式開始此次交流。

初次交流一定要在紙上記錄、畫出對應的流程圖的草圖，這種方式較為高效。

一旦準確無誤瞭解了涉及工作內容的流程之後，一定要先暫停交流，將瞭解的流程和流程涉及的所有單據、報表的情況記錄下來，填充《需求調研報告.docx》中第二章工作項目描述的“原始流程”和“單據報表”兩項、以及第三章，建議“原始流程”用文字描述，按照步驟分隔，同時思考一下初步還有哪些問題需要詢問，記錄在“問題列表”一項。

備忘：相關單據、報表盡量都要一份在手裡，在上面備忘欄位的錄入要求、預設值、唯一約束、可選範圍、單據狀態等細節。

u  第二步：流程確認，開始問答

此次殺回來需要將之前記錄下來的流程和單據報表進行最終確認。

然後針對自己想要知道的問題進行問答，記錄在“問題列表”一項。

詢問使用者最希望系統解決工作中的什麼問題？關注點主要在哪方面？記錄在“使用者關注點”一項。注意，在問使用者最想要解決的問題的時候，要看清問題的本質，比如使用者說“我要一個饅頭”，“你為什麼要一個饅頭？”“因為我餓了”，所以如何填報肚子才是使用者最核心的問題，我們在這個環節應該多問為什麼，挖掘使用者最真實的想法。

u  第三步：流程最佳化

到底為止使用者最原始的需求大體上已經記錄完成，即協助使用者梳理其商務程序的工作已經結束，接下來就是要協助使用者最佳化商務程序，建立對應的規範。

流程最佳化包括以下幾種情況：

1 將使用者實際的工作流程和我們的系統結合起來，提出一個新的商務程序；

2 多個部門、角色之間類似的流程可以進行抽象，提出一個統一的規範；

3 多個部門、角色之間銜接的地方是否可以通過系統進行規範或最佳化。

這個過程可以自己私底下思考，也可以和相關使用者一起討論，最終將最佳化後的結果記錄在第六章，通過使用案例圖、活動圖表並配以文字來進行描述。

u  第三步：最佳化結果確認

最佳化後的結果要得到相關角色的確認。

步驟4：需求調研成果確認

針對每個部門/角色進行“步驟2”的迭代之後，至此已經跟每類角色的各個一線工作人員都已經交流完成。接下來要做的就是把能基本做出決策、又瞭解上層大領導的設想和思路的中層領導和之前交流過的一線使用者集中起來，一起將原始流程、關注的問題、特別是最佳化後的流程進行最終修改確認，領導的決議和關注點也要對應記錄下來。至此需求調研報告全部完成，列印出來留給使用者一份，如果能夠簽字最好，方便之後需求變更管理。

產出為：《需求調研報告》

第四步：需求成果評審

         根據需求調研報告出具《需求規格說明書》，需求規格說明書根據不同公司，不同項目可能都不大一樣，但是核心思想都是差不多的，大概涉及以下幾方面內容：

n  運行環境、上下文關係、限制條件（工期、運行環境、技術等）

n  角色及其對應的用例

n  單個用例的細化，包括用例的詳細文字性描述，可用活動圖表加以輔助描述

n  類圖或者E-R圖，描述系統資料對象以及它們之間的關係

n  測試案例(較為抽象、注重需求是否滿足)

注意編寫需求規格說明書之前需要先分析出系統角色，一般原則是從常用操作環境去分析參與的角色有哪些，然後列出所有情境以及各個角色在該情境下的功能許可權和資料許可權，驗證角色劃分正確之後，在進行需求規格說明書編寫。因為編寫需求規格說明書時，繪製使用案例圖和活動圖表需要以分析出來的角色作為參與者。

其實根據我的經驗，需求規格說明書裡面的很多內容其實在需求調研階段已經完成了，只是可能形式上不是很注重，比如系統角色，用例，運行環境，限制條件，對象實體關聯等在需求調研階段就已經需要同時分析出來的。所以說需求規格說明書一定程度上來將是前期需求調研和分析的成果體現。

最終完成需求規格說明書需要經曆以下步驟：

1、  專案經理根據需求調研報告，進行《需求規格說明書》的編寫；

2、  進行項目組內甚至更大範圍的評審會議，這一步很關鍵，需要相關的研發人員以及專案經理等有經驗的角色共同參與；

3、  根據評審結果進行修改，之後發給使用者進行最終確認。

產出為：《需求規格說明書》。

第五步：需求成果錄入

         經過使用者確認的所有需求已經包含在最終形成的《需求調研報告.docx》中，接下來要做的就是將這些需求錄入到需求管理工具中，進行跟蹤管理。

在這裡可以下載我自己編寫的不涉密的 需求調研相關的文檔：http://pan.baidu.com/s/1nq4cm

2 概要設計

         概要設計包括四個方面：

n  技術架構設計。包括邏輯架構和物理架構並詳細說明

n  功能模組組織和劃分，給出功能模組圖或者思維導圖(腦圖)

n  功能點提煉、優先順序確定。第一階段功能點應該盡量少，涵蓋關鍵性業務即可，在完成第一階段功能點研發之後立刻與使用者見面，以免與需求產生較大偏差。可以認為我們採用的是迭代式開發，按照這個階段劃分的功能點進行迭代。

n  後續啟動計劃制定，比如需要在什麼時候完成詳細設計、準備工作、第一階段功能點開發、第一階段產出系統與使用者見面並修改等。

產出為：《概要設計文檔》。

3 詳細設計

         詳細設計包括以下三個方面：

n  各個功能點的詳細設計

n  資料庫詳細設計

n  導航、資料許可權詳細設計

產出為：《XXX功能點詳細設計》、資料庫pdm檔案、《許可權設計》。

4 編碼

 

5 測試

         在測試正式啟動之前，項目負責人需要根據環境和人員制定出可控的測試計劃，比如由哪些人來承擔測試環境搭建，由哪些人來細化或者編寫測試案例，由哪些人來執行具體的測試，由哪些人來執行系統產品化工作。然後各自這些任務的目標，所涉及的工作範圍，階段的劃分，時間限制等都要規定好。然後為每個部分指定一個負責人，進行任務分配和進度控制，並直接向項目負責人彙報進度。

         然後要求所有系統模組單元測試通過，提出最後源碼提交期限後，禁止源碼環境的源碼提交許可權，禁止出測試環境部署人員之外的人員針對測試環境的提交許可權，將測試環境和外界斷開，具體理由可參考另一篇文章。

         在提出測試目標、分配測試工作、劃分測試階段之後，就可以開始啟動系統整合測試。大概可以將資訊化系統的整合測試劃分為以下幾個階段：

（1）      系統開發完成、制定總體測試計劃（測試目標、測試範圍、人員分配）

（2）      部署人員部署系統到測試環境，產品化人員協助。比如資料庫初始化指令碼等需要產品化人員提供，這個階段先不要將資料庫、服務、用戶端等打包。

（3）      需求掌握人員編寫測試案例(參考原始需求調研報告和需求分析報告)；

（4）      測試人員執行第一輪測試；

（5）      第一輪測試Bug修複、迴歸測試至Bug修複完成。

（6）      編寫測試報告，開始產品化打包工作。

（7）      產品化安裝包測試。

（8）      系統安裝文檔、使用者使用手冊編寫。

（9）      最終定版，系統、文檔、源碼歸檔。

6 實施

        

7 維護

在系統開發完成之後，後續的版本迭代、代碼和系統維護過程中，最關鍵的是版本控制問題。

 

撰寫人：季義欽、歡迎交流

【PM】資訊化系統軟體開發流程