DELL項目工作整理

    大家好，今天來這裡做一個DELL公司內部的軟體開發流程簡介。DELL不是一家專業的軟體開發公司，它的軟體開發流程還遠不完善，但在一些流程式控制制上也有它的優勢，今天來這裡和大家做一個分享，也希望能得到大家的一些建議。今天這裡有一些CMM3和CMM4公司的開發人員，希望你們也能給點建議。 

DELL的軟體開發項目，遵循的是Microsoft的另一套MSF (Microsoft Solutions Framework) 開發流程。

    項目開發分為五個階段：1. Chatting (預討論), 2.Envisioning （想象）, 3.Planing （計劃）, 4.Developing （開發）, 4.Stabilizing （穩定）。在每一個階段都有不同的角色協同工作。

1. Chatting (預討論) （專案經理，BA業務分析人員，使用者）

    項目前期分析，主要內容就是業務分析。專案經理和使用者開會，第一，分析使用者想做什嗎？第二，使用者的想法可不可行？值不值得做？如果值得做，預算要做多少？分析的工具是：CBA (cost benefit analysis) 成本收益分析 ，它的結果是ROI (return of investment) 投入產出比 。一般情況下，使用者提供benefit（收益）分析結果，IT評估項目的cost（成本）。公司目前的立項標準是ROI10比1。我從專案經理那得到的資料是，大致1/3的項目可以繼續往下走。

裡程碑：立項。（項目得到使用者部門經理和IT部門經理的批准，項目進入項目列表）  

2. Envisioning. （想象）（專案經理，業務分析人員，使用者，開發組）

    項目的範圍界定。描繪項目的範圍和關鍵功能點，使項目有個可視的輪廓。這時候，專案經理會收集各個小組的建議。例如，和開發組溝通大致的開發時間，向伺服器組徵詢伺服器的類型和配置，向DBA徵詢資料庫的類型和配置等等。

裡程碑：獲批准的VSD(vision scope definition)    

3. Planning。（專案經理，BA, 開發組，測試組，支援組）

    制定詳細的專案計劃。確定項目的三要素“時間”，“資源”和“範圍”。再加上風險管理。

    1。對於專案經理來說，最重要是向老闆要resource（資源）。當然還要確定項目開發的確切時間。

    2。對於業務分析人員來說，需要明確詳細的業務需求。這時候會畫出系統流程圖和使用者介面草圖，再加上每一項功能的業務描述等等。這些都包括在SRS(system requirement specification)中。

    2。對於開發組來說，最重要是制定了開發計劃，瓜分用例（把每一個功能點分配給開發人員）。定製每個開發人員的開發進度表，code review計劃。

    3。對於開發組來說，還需要定義風險管理計劃和措施。這裡的風險，特指技術痛點。技術痛點需要先做prototype，risk太高的需要捨棄一些功能。（FMEA, failure model effect analysis）因為“任何可能出錯的地方都會出錯。” 

    4。測試組根據SRS定製測試計劃。

    5。專案計劃獲得使用者，專案經理，開發經理和測試經理的同意。

裡程碑：獲批准的SRS(system requirement specification) 

4. Developing。（專案經理，開發組，使用者，伺服器組，資料庫管理員）

設計階段：

    1。開發組：軟體建模。定義系統的架構（邏輯、物理），域建模，用例分析，對每個用例的順序圖表分析，對象建模。重新評估項目的複雜度。在這個階段，可適當調整專案計劃。

    2。伺服器組：安裝測試伺服器，安裝開發相關軟體。如IIS，BIG IP, IBM Message Queue等等。

    3。DBA：安裝配置開發資料庫。配置使用者帳號：一般情況下分為兩個帳號。app帳號為正式環境下啟動並執行受限帳號。admin帳號為可建立資料庫物件的特權帳號。

    4。專案經理：協調各團隊的工作，檢查各項工作進度。

裡程碑：獲批准的設計文檔SDS(system design specification)。

編碼階段：把設計轉換成代碼，根據實際問題適當調整並同步設計，code review和審核進度。

裡程碑：代碼通過單元測試,代碼和文檔都check in版本管理器。

測試階段：

    1。SIT自我裝載，根據用例描述測試每一個情境，分析記憶體流失，最佳化系統效能，提交資料庫效能execution plan執行計畫給DBA review。對系統進行壓力測試（必要情況下提交到馬來西亞的壓力測試組進行測試）。

裡程碑：完成自我裝載報告和得到DBA的上線批准。

    2。UAT（user acceptable testing）使用者測試。使用者根據用例描述測試每一個情境，反饋系統bug和issue。開發人員修正bug並基於issue對系統影響和對業務影響進行判斷，適當的修正系統或記錄業務需求，根據業務優先等級，整合進以後的演化階段。

裡程碑：UAT Sign off。使用者簽收當前系統功能。

部署：

    專案經理整理文檔（Design document, SIT test report, UAT sign off, System downtime approval, server check list, DB checklist. implementation plan. back out plan(data & program)），向change committee（一個專門控制系統更新的委員會）提交新系統上線請求。如果change committee批准請求。

    開發組在指定的時間裡向production（生產）電腦部署系統，產生資料庫部署指令碼，提交給DBA。

    DBA運行部署指令碼，反饋結果。 

5. Stabilizing。（專案經理，開發組，支援組）

系統穩定期。開發組 記錄和反饋系統BUG，向支援組移交程式和文檔等等。

Bug修正：為了減少對生產的影響，在生產環境下的任何bug修正都需要change committee的批准。Change committee只有周二和周四下午接受修改請求，緊急情況下需要部門經理特別批准。對開發組而言，bug修正是一件非常痛苦的事情，這樣在一定程度上也提高了軟體品質。

裡程碑：Support Team Sign off。 

角色：User，Project team 專案經理, BA 業務分析人員， Server team 伺服器組, DBA 資料庫管理員, Develop team 開發組, Support team 支援組。