目的描述公司產品研發的管理流程與工作內容。通過本規范的實行，保證研發方向對的，階段目的清楚，項目過程可控，從而保證按照預期計劃完畢產品研發和上市銷售。研發管理整體流程研發管理流程圖圖STYLEREF1\s2SEQ圖\*ARABIC\s11研發管理流程模型研發項目的組織結構研發項目的組織結構模型如REF_Ref\h圖22所示，共分為4個層次，決策領導（總經理、研發中心總監/產品中心總監）；項目經理、項目成員；營銷生產質檢運營等相關支持部門；項目管理委員會（由項目管理部根據項目情況組織相關成員組成）。圖STYLEREF1\s2SEQ圖\*ARABIC\s12研發項目組織結構決策領導涉及總經理、研究院主任、研發中心總監/產品中心總監、技術負責人?？偨浝頁碛凶罱K決策權，決策領導逐級下達任務給項目經理，項目經理向直接決策領導報告工作，再分級上報。項目經理是研發項目的管理者，他帶領所有項目成員共同完畢決策領導下達的任務。項目成員是指在項目中執行具體任務的人員，例如分析員、設計師、程序員、測試員等。項目經理下達任務給項目成員，項目成員們向項目經理報告各自的工作。項目成員并非固定在一個項目中工作，他們也許會為多個項目提供服務。假如組織內沒有相對獨立的測試組，那么測試人員的直接領導就是項目經理。假如機構內有測試組，那么測試人員的直接領導是測試經理，當測試人員接受了某個項目的測試任務，那么他要向測試經理或項目經理報告工作。研發項目的角色在研發項目中，每個人可以擁有多個角色，視項目情況而定。角色職責如REF_Ref\h表21所示。后續章節的流程規范將詳述“角色在什么時候，以什么環節做什么事情，產生什么樣的成果”。角色該角色在研發流程中的重要職責決策領導（項目決策者）（1）參與立項評審，為項目提供人力資源。（2）及時了解所有項目的人力資源、進度、質量情況，協商解決問題。（3）在項目結束時，對項目進行綜合評估。項目管理委員會項目管理委員會一般由部門經理以上職位的人員以及項目綜合管理員組成，重要職責是參與“協議項目”和“自主產品”的立項評審、項目開發各階段評審、項目驗收評審等。項目綜合管理員（1）跟蹤每個項目的開發過程，重點檢查需求文檔、設計文檔、變更記錄、用戶文檔是否符合規范。

（2）參與需求評審和設計評審。

（3）假如發現項目問題，先和負責人溝通，假如難以解決，則由上級領導協調。（4）技術部項目綜合管理員由技術中心助理負責項目經理（項目管理者）項目經理是項目重要負責人，重要職責是帶領團隊在預定的時間和成本之內，開發并交付質量合格的項目（產品）。項目經理對本項目的需求、進度、質量、交付負重要責任。（1）負責本項目的任務進度管理、變更管理，以及也許存在的跨項目、跨部門協調。（2）假如本項目沒有專門的需求分析員、系統設計師，那么項目經理承擔需求分析、系統架構設計工作。假如本項目缺少足夠的開發工程師，那么項目經理應當承擔某些模塊開發。（3）在項目結束時，總結知識財富和經驗教訓，完善文檔。對項目成員的業績進行評估。需求分析員（1）負責本項目需求調研、分析、定義，撰寫具體的需求文檔。

（2）將需求準確地傳達給相關人員（如開發、測試、客戶等），隨著項目進展，及時完善需求文檔。系統設計師（1）根據需求開展總體設計，涉及硬件結構設計、軟件構架設計、數據庫設計等。（2）撰寫設計文檔，并將設計成果準確地傳達給其他項目成員。開發工程師（1）按照項目經理分派的任務執行開發設計，涉及美工、界面設計，并清楚地交付給測試人員（準備測試）。假如測試人員報告缺陷，應及時消除缺陷。對自己工作成果的質量負最大責任。（2）參與項目討論，積極發現項目中的問題、消除問題。（3）對自己的源代碼進行配置管理，及時完善文檔。（4）假如本項目沒有專門的工藝技術員，那么開發工程師承擔工藝設計工作。測試工程師（1）了解項目需求，了解項目開發進度，和項目經理商議測試計劃，設計測試用例。（2）根據計劃執行測試，找出盡也許多的缺陷。使用缺陷跟蹤工具，及時將測試信息反饋給相關負責人。（3）向項目經理報告項目內的質量問題，向決策領導報告共性的質量問題。工藝技術員（1）對產品生產工藝進行分析、設計，編制工藝卡片（2）設計必不可少的工裝模具（3）參與需求評審和設計評審。（4）發現問題，及時與負責人溝通，假如難以解決，則由上級領導協調。配置管理員（1）為所有項目創建配置庫，為用戶分派合適的權限，負責信息安全和備份。（2）指導開發人員使用配置管理軟件和研發管理軟件。（3）配置管理工作由項目經理承擔。技術支持主管（1）負責安排售前、生產、售后跟蹤產品開發過程，及時提出需求建議，及時試用產品，糾正偏差，給出優化建議，使產品更加適合目的客戶的需求。（3）協助營銷人員宣傳、銷售該產品，及時獲取客戶的反饋，改善產品。制造、采購、質檢、運營相關支持部門采購負責樣機制作過程中的外購、外協聯絡；制造部門負責產品小批量試制；質檢部門負責試制過程中產品的功能、性能驗證；運營部門負責反饋現場運營情況。表STYLEREF1\s2SEQ表\*ARABIC\s11研發項目中的角色職責流程中的過程域、重要活動和重要工作成果過程域重要活動重要工作成果營銷

過程產品構思和調研產品構思，產品調研產品需求說明書，產品調研報告，技術可行性分析報告產品體驗和宣傳銷售產品體驗，宣傳銷售產品宣傳材料協議項目銷售接觸客戶，可行性分析，投標答辯，簽訂協議投標書，協議，項目需求說明書客戶服務和協議驗收產品維護，評審成果，控制變更，項目驗收項目驗收報告項目管理過程立項管理立項申請，立項評審，項目籌備立項申請書，立項評審報告結項管理結項申請，結項評估，關閉項目結項申請書，結項評估報告項目規劃與監控制定項目計劃，人員管理，任務進度管理，項目成本管理，設備管理項目計劃，日記，周報風險跟蹤和變更控制辨認風險，解決風險，關閉風險

變更申請，變更審批，執行風險跟蹤表，變更控制報告項目開發過程需求開發與管理需求調研，需求分析，需求定義，評審確認，細化跟蹤，變更控制產品（項目）需求說明書系統設計系統方案設計、硬件結構設計，軟件架構設計，用戶界面設計，數據庫設計，模塊設計系統集成方案，系統概要設計說明書，系統具體設計說明書。模塊開發與集成模塊需求細化，模塊設計，模塊實現和集成，工藝設計，試制樣品模塊需求說明書，模塊設計說明書，軟件代碼，硬件及機械結構設計圖，產品圖紙、工藝卡片、工裝設計圖等測試與改錯準備測試，執行測試，消除缺陷測試用例，測試報告軟硬件系統集成系統集成，選擇設備供應商，設備采購和驗收，設備安裝調試設備具體清單小批量試制及改善選擇物料供應商，物料采購，試制產品小批量試制報告，改善記錄部署試用撰寫文檔，軟件部署，客戶培訓，客戶試用（周期允許交付質檢查證測試，否則交付客戶現場試運營）部署說明書，安裝和使用手冊軟件維護接受維護請求，分析維護請求，

執行維護（涉及工廠運營測試、現場試運營測試）維護記錄支持

過程配置管理軟件代碼管理，硬件電路圖管理，文檔管理軟件代碼庫，硬件電路圖庫，文檔庫質量管理技術評審，測試管理，發布管理，質量保證，缺陷（問題）跟蹤技術評審報告，發布記錄，缺陷報告采購及外包產品試制過程中的外購外協外購外協申請單、供方協議評審、合格供方清單?？蛻舴展芾砜蛻粜畔⒐芾恚蛻魡栴}受理（涉及工廠安裝調試運營問題、現場測試運營問題）客戶信息庫，客戶問題記錄，安裝調試運營記錄表STYLEREF1\s2SEQ表\*ARABIC\s12研發項目流程中的過程域、重要活動和重要工作成果立項管理立項管理的流程如REF_Ref\h圖31所示，關鍵活動是“協議項目立項申請”、“自主產品立項申請”、“立項評審”和“項目籌備”。該流程的重要工作成果和負責人見REF_Ref\h表31。注：在立項申請階段，決策領導根據項目特性和開發部門的情況，即任命合適的項目經理，共同進行產品需求調研、可行性分析等，共同籌備立項申請。圖STYLEREF1\s3SEQ圖\*ARABIC\s11立項管理的流程關鍵活動重要工作成果重要負責人自主產品立項申請立項申請書，

產品需求說明書，產品調研報告，技術可行性分析報告相關決策領導、項目經理協議項目立項申請立項申請書，

項目需求說明書，相關協議文本協議項目的銷售專員立項評審立項評審報告項目管理委員會項目籌備項目總體計劃相關決策領導，項目經理表STYLEREF1\s3SEQ表\*ARABIC\s11立項管理重要工作成果和負責人自主產品立項申請項目經理撰寫《立項申請書》，將《立項申請書》、《產品需求說明書》、《產品調研報告》、《立項可行性分析報告》提交給項目管理委員會負責人審閱。如發現文獻內容不合流程規定或者質量不合格，則退還給申請人重新改善，直到文獻合格為止。協議項目立項申請一般情況下，開發方和客戶簽訂正式協議之后，開發方再在公司內部立項。也有一些例外，由于某些因素導致協議尚未簽訂，但是客戶有一些口頭承諾，規定開發方先做項目，后簽訂協議。假如開發方不批準，則也許失去機會。假如開發方批準先開發，但是存在比較大的風險，要在立項評審會議做出決定。項目銷售人員撰寫《立項申請書》，將《立項申請書》、《項目需求說明書》以及相關協議文本提交給項目管理委員會負責人審閱，假如發現文獻內容不合流程規定或者質量不合格，則退還給申請人重新改善，直到文獻合格為止。立項評審評審準備項目管理委員會負責人把《立項申請書》等相關文獻遞交給各個評審委員。項目管理委員會負責人擬定立項評審會議的時間、地點、設備和參與會議的人員名單。舉行評審會議立項申請人陳述《立項申請書》和相關文獻的重要內容。評審委員提出疑問，立項申請人解答。雙方應當對有爭議的內容得出解決意見。項目管理委員會負責人匯總所有評審委員的評審意見，填寫《立項評審報告》，以“少數服從多數”決定是否立項，以及給出項目執行建議。項目終審項目管理委員會負責人將《立項評審報告》遞交給總經理。總經理在《立項評審報告》中簽注最終審批意見。假如批準立項，那么進入下一步“項目籌備”。否則，項目中斷。項目籌備再次明確項目經理責任再次明確項目經理權責，項目經理對立項之后的項目進度和質量負最大責任。確立項目組，項目成員項目啟動會項目經理召開項目啟動會，讓所有項目成員了解項目的目的和工作內容。項目計劃項目計劃的流程如REF_Ref\h圖41REF_Ref\h所示，關鍵活動是“項目估計”、“制定項目計劃”、“審批項目計劃”和“項目計劃變更控制”。該流程的重要工作成果和負責人見REF_Ref\h表41。圖STYLEREF1\s4SEQ圖\*ARABIC\s11項目計劃的流程關鍵活動重要工作成果重要負責人項目估計項目估計表項目經理制定項目計劃項目計劃項目經理審批項目計劃按評審意見修正后的項目計劃相關決策領導，項目經理項目計劃變更控制項目計劃變更控制報告新的項目計劃相關決策領導，項目經理表STYLEREF1\s4SEQ表\*ARABIC\s11項目計劃重要工作成果和負責人項目估計 項目經理組織項目成員進行項目功能、模塊分解，從而估計產品的規模，估計工作量；估計成本和預算。產品規模的重要度量單位有：代碼行類（對象）個數功能電路塊數，機械結構難易限度，機械結構圖紙數量電路原理復雜限度文檔頁數成本涉及人力成本、軟硬件資源成本等；預算除上述成本外還涉及項目知識產權管理、項目驗收等費用。制定項目計劃擬定目的與范圍一方面擬定本項目的目的與工作范圍。目的必須是“可實現的”和“可驗證的”。工作范圍涉及“做什么”和“不做什么”。制定人力資源計劃項目經理制定本項目的角色職責表，并為項目成員分派角色（一個人可以兼多個角色）。制定軟硬件資源計劃分析項目開發、測試以及用戶使用產品所需的軟硬件資源，制定軟硬件資源計劃。資源級別（分為“關鍵”、“普通”兩種）具體配置獲取方式（如“已經存在”、“可以借用”或“需要購買”等）與獲取時間用途（如“誰”在“什么”時候使用）制定財務計劃制定財務計劃。開支類別重要用途金額時間分派任務并制定進度表項目經理結合4.1項目評估結果，以及項目成員數量分解任務并制定具體進度表，建議采用MicrosoftProject制作Gantt圖，附在《項目計劃》中。審批項目計劃申請審批項目經理將《項目計劃》提交給決策領導，最終提交總經理審批。補充說明：假如是協議項目，也許還要請客戶審批，視具體情況而定。審批與修正決策領導根據“項目計劃檢查表”認真審批《項目計劃》。假如《項目計劃》中進度周期不能滿足市場規定期，決策領導和項目經理共同商討解決辦法。批準生效決策領導簽字批準后，該《項目計劃》正式生效，此后項目經理不能隨意修改《項目計劃》。項目計劃變更控制變更申請項目經理向決策領導申請變更《項目計劃》。變更申請書中應當說明：變更因素變更的內容此變更對項目導致的影響補充說明：假如是協議項目，也許還要向客戶提出變更申請，視具體情況而定。審批變更申請機構領導審批變更申請：假如不批準變更，則退回變更請求，項目按照原計劃執行。假如批準變更，轉向第3步。修改項目計劃項目經理修改原《項目計劃》，產生新的《項目計劃》。審批新的項目計劃決策領導審批新的《項目計劃》補充說明：假如項目計劃對整個項目完畢周期有影響時，該項目計劃需提交總經理審批。項目監控項目監控流程如REF_Ref\h圖51所示，關鍵活動是“項目計劃跟蹤”、“偏差控制”和“項目進展總結”。該流程的重要工作成果和負責人見REF_Ref\h表51。圖STYLEREF1\s5SEQ圖\*ARABIC\s11項目監控的流程關鍵活動重要工作成果重要負責人項目計劃跟蹤項目進展報告項目經理偏差控制項目進展總結表STYLEREF1\s5SEQ表\*ARABIC\s11項目控制重要工作成果和負責人項目計劃跟蹤項目經理周期性地（如每周一次）跟蹤每個重要的任務，項目費用使用情況，軟硬件資源配置情況，形成記錄。偏差控制找出顯著偏差項目經理根據任務跟蹤、費用跟蹤、資源跟蹤所產生的數據，對比“項目實際進展”與“項目計劃”，找出顯著偏差項（例如進度偏差大于20％）。分析因素項目經理分析產生顯著偏差的因素，以便采用對的的糾正措施。給出糾正偏差的措施項目經理給出糾正顯著偏差的措施：假如偏差重要是由于《項目計劃》不合理導致的，則要變更項目計劃。假如《項目計劃》自身是合理的，偏差重要是由于項目成員在執行時產生的，那么規定項目成員填補偏差，避免原本合理的計劃在實行時落空。跟蹤糾正偏差的過程項目經理跟蹤糾正偏差的過程，直到該偏差被消除為止。項目進展總結項目經理周期性地（或者在里程碑處）召開項目進展會議，探討問題，總結工作，讓所有項目成員清楚地了解項目的實際進展情況。項目經理撰寫《項目進展報告》，并及時通報給所有項目成員和決策領導。需求開發與管理項目需求開發和管理的流程如REF_Ref\h圖61REF_Ref\h所示，關鍵活動是“需求開發”、“需求確認”、“需求跟蹤”和“需求變更”。該流程的重要工作成果和負責人見REF_Ref\h表61。圖6SEQ圖\*ARABIC\s11需求開發與管理的流程關鍵活動重要工作成果重要負責人需求開發產品需求說明書需求分析員需求確認需求評審項目經理/上級決策領導/項目管理委員會需求變更需求變更申請需求分析員表STYLEREF1\s7SEQ表\*ARABIC\s11需求開發與管理重要工作成果和負責人需求開發細化并分析用戶需求需求分析員對《用戶需求說明書》進行細化，以便產生具體的產品需求。需求分析員對比較復雜的用戶需求進行建模分析，以幫助開發人員更好地理解需求。撰寫產品需求規格說明書需求分析員按照指定的文檔模板撰寫《產品需求規格說明書》。假如待開發的產品分為軟件和硬件兩部分的話，則應當分別撰寫《軟件需求規格說明書》和《硬件需求規格說明書》?！懂a品需求規格說明書》的重要內容涉及：產品介紹；描述用戶群體的特性；定義產品的范圍；闡述產品應當遵循的標準或規范；定義產品中的角色；定義產品的功能性需求；定義產品的非功能性需求，如用戶界面、軟硬件環境、質量等需求需求確認非正式需求評審項目經理先在項目內部組織人員進行非正式的需求評審，以消除明顯的錯誤和分歧。正式需求評審項目經理上報上級領導進行審批，必要情況下邀請項目管理委員會組織相關成員和用戶（協議項目）一起評審需求文檔，盡最大努力使需求文檔可以對的無誤地反映用戶的真實意愿。獲取需求承諾 當需求文檔通過正式的評審之后，項目經理和決策領導、客戶（協議項目）對需求文檔作書面承諾。需求變更需求變更申請需求變更申請人撰寫“需求變更申請書”，遞交給項目經理或客戶方負責人?！靶枨笞兏暾垥北仨氷U述：（1）變更因素；（2）變更的內容；（3）此變更對項目導致的影響。審批需求變更申請項目經理和決策領導、客戶（協議項目）共同審批“需求變更申請書”：假如任何一方不批準變更，則退回變更請求，項目按照“原需求文檔”執行。假如雙方都批準變更，轉向第3步。更改需求文檔需求分析員根據第1步和第2步更改“原需求文檔”，產生新的需求文檔。重新進行需求確認重新進行需求評審，參見需求確認規程中的第2步。重新獲取書面的需求承諾，參見需求確認規程中的第3步。補充說明：1、假如項目經理直接承擔需求分析員工作，需求評審由上級領導審批，必要情況下邀請項目管理委員會組織相關成員和用戶（協議項目）一起評審，視具體情況而定。系統設計系統設計是指設計硬件結構（涉及電路、機械等），軟件架構、用戶界面、數據庫、模塊等，從而在需求與代碼、電路、機械等之間建立橋梁，指導開發人員去實現能滿足用戶需求的產品。圖STYLEREF1\s8SEQ圖\*ARABIC\s11關鍵活動重要工作成果重要負責人軟件架構設計概要設計說明書，具體設計說明書系統設計師硬件結構設計硬件、結構設計方案系統設計師用戶界面設計用戶界面設計說明書開發人員數據庫設計數據庫設計說明書開發人員軟件模塊設計軟件模塊設計說明書開發人員硬件模塊設計硬件模塊設計說明書開發人員工藝設計工藝文獻工藝技術員表STYLEREF1\s8SEQ表\*ARABIC\s11軟件/硬件系統設計設計準備閱讀需求文檔，分解系統設計任務。準備相關的設計工具和資料。擬定影響系統設計的約束因素需求約束。系統設計人員從需求文檔中提取需求約束，例如：本系統應當遵循的標準或規范軟件、硬件環境（涉及運營環境和開發環境）的約束接口/協議的約束用戶界面的約束產品外觀、內部布局、零部件加工工藝、裝配工藝等的約束軟件質量的約束，如對的性、健壯性、可靠性、效率（性能）、易用性、清楚性、安全性、可擴展性、兼容性、可移植性等等。硬件質量的約束，如可靠性、穩定性、精確度、功耗、安全性、可擴展性、抗震性等等隱含約束。有一些假設或依賴并沒有在需求文檔中明確指出，但也許會對系統設計產生影響，設計人員應當盡也許地在此處說明。例如對用戶教育限度、計算機技能的一些假設或依賴，對支撐本系統的軟件硬件的假設或依賴等。系統分解與設計將系統分解為若干子系統，擬定每個子系統的功能以及子系統之間的關系。將子系統分解為若干模塊，擬定每個模塊的功能以及模塊之間的關系。擬定系統開發、測試、運營所需的軟硬件環境。撰寫系統結構設計文檔系統設計人員根據指定的模板撰寫《概要設計說明書》、《具體設計說明書》《硬件結構設計方案》，重要內容涉及：系統概述影響設計的約束因素設計策略系統總體結構子系統的結構與模塊功能開發、測試、運營所需的軟硬件環境系統設計評審系統設計評審重要評審要素涉及：合適性?？疾煸摻Y構是否適合于產品需求，是否可在預定計劃內實現。系統的綜合能力，例如可擴展性，可管理性（可維護性），可復用性，安全性等等，視產品特性而定。補充說明：1、假如項目經理直接承擔系統設計工作，評審由上級領導審批，必要情況下邀請項目管理委員會組織相關成員和用戶（協議項目）一起評審，視具體情況而定。用戶界面設計設計準備界面設計人員閱讀需求文檔和系統設計文檔，明確界面設計任務。界面設計人員與用戶交流，了解用戶的工作習慣和他們對界面的見解。界面設計人員準備相關的設計工具和資料，收集或創作基本的界面資源如圖像、圖標以及通用的組件。界面設計人員擬定本軟件的用戶界面設計規則，重要涉及：軟件主界面（如主窗口、主頁面）的設計規則；軟件子界面（如子窗口、子頁面）的設計規則；標準控件的使用規則；用戶界面設計用戶界面設計一般要經歷“原型創作—>原型評估－>細化”等環節，通常迭代進行。原型創作界面設計人員創作界面原型：先徒手畫，或者用Visio等工具繪制界面的視圖；再用軟件開發工具實現可以運營的原型。原型評估界面設計人員可建議項目經理進行評估界面的原型，匯集意見，及時改善。細化撰寫用戶界面設計文檔用戶界面定型之后，界面設計人員根據指定的模板撰寫《用戶界面設計報告》，重要內容涉及：應當遵循的界面設計規范；界面的關系圖和工作流程圖；主界面的視圖、功能說明、操作方式；子界面的視圖、功能說明、操作方式；用戶界面設計評審界面設計人員可建議項目經理對定型后的界面組織進行正式技術評審，盡最大努力使界面變得更加美觀、易用。用戶界面的重要評審要素涉及：簡潔易用一致性美觀動態反饋功能屏蔽和犯錯解決用戶控制兼容性和可移植性適應性（針對各種用戶）界面設計及測試按照評審結果開始進行界面設計，并自行測試，記錄測試結果，不斷完善改善，直至缺陷、故障消除。數據庫設計設計準備數據庫設計人員閱讀需求文檔和系統設計文檔，明確數據庫設計任務。數據庫設計人員準備相關的設計工具和資料。數據庫設計人員擬定本軟件的數據庫設計規則，重要涉及：數據庫命名規則邏輯設計規則物理設計規則安全性設計規則優化規則數據庫管理與維護規則數據庫設計 數據庫設計一般要經歷“邏輯設計—>物理設計－>安全性設計－>優化”等環節，通常要迭代進行。邏輯設計數據庫設計人員根據需求文檔，創建與數據庫相關的那部分實體關系圖（ERD）。假如采用面向對象方法（OOAD），這里實體相稱于類（class）。物理設計設計表結構。一般地，實體相應于表，實體的屬性相應于表的列，實體之間的關系成為表的約束。邏輯設計中的實體大部分可以轉換成物理設計中的表，但是它們并不一定是一一相應的。安全性設計提高軟件系統的安全性應當從“管理”和“設計”兩方面著手。這里僅考慮數據庫的安全性設計。用戶只能用帳號登陸到應用軟件，通過應用軟件訪問數據庫，而沒有其它途徑可以操作數據庫。對用戶帳號的密碼進行加密解決，保證在任何地方都不會出現密碼的明文。擬定每個角色對數據庫表的操作權限，如創建、檢索、更新、刪除等。每個角色擁有剛好可以完畢任務的權限，不多也不少。在應用時再為用戶分派角色，則每個用戶的權限等于他所兼角色的權限之和。撰寫數據庫設計文檔數據庫設計人員根據指定的模板撰寫《數據庫設計說明書》，重要內容涉及：數據庫環境說明數據庫的命名規則邏輯設計物理設計安全性設計優化數據庫管理與維護說明數據庫設計評審數據庫設計人員可建議項目經理組織進行數據庫技術評審。數據庫的重要評審要素涉及：對的性、完整性、一致性安全性數據庫實現及測試按照評審結果開始進行數據庫代碼編寫，并自行測試，記錄測試結果，不斷完善改善，直至缺陷、故障消除。軟件模塊設計設計準備模塊設計人員閱讀需求文檔和系統設計文檔，明確模塊設計任務。模塊設計人員準備相關的設計工具和資料。模塊設計人員擬定本軟件的編程規范，保證模塊設計文檔的風格與代碼的風格保持一致。模塊設計 模塊設計一般要經歷“接口與屬性設計—>數據結構與算法設計”等環節，并且通常需要反復迭代。接口與屬性設計模塊設計人員設計每個模塊的重要接口與屬性。假如采用面向對象方法，相稱于設計類的函數和成員變量。數據結構與算法設計模塊設計人員設計每個模塊的數據結構與算法。撰寫模塊設計文檔模塊設計人員根據指定的模板撰寫《模塊設計報告》，重要內容涉及：模塊匯總每個模塊的重要接口與屬性每個模塊的數據結構與算法（假如存在的話）模塊設計評審模塊設計人員可建議項目經理組織進行對模塊設計文檔技術評審。模塊實現按照評審結果開始進行模塊代碼編寫，并自行測試，記錄測試結果，不斷完善改善，直至缺陷、故障消除。硬件模塊設計設計準備模塊設計人員閱讀需求文檔和系統設計文檔，明確模塊設計任務。模塊設計人員準備相關的設計工具和資料。模塊設計人員擬定設計規范，保證各單元設計文檔、設計圖的風格保持一致。模塊設計 模塊設計一般要經歷“接口與連接件選型—>模塊內部部件選型—>模塊內部資源分派”等環節。撰寫設計文檔模塊設計人員根據指定的模板撰寫《模塊設計報告》，重要內容涉及：模塊匯總每個模塊的重要接口與連接件選型每個模塊內部部件選型和資源分派模塊設計評審模塊設計人員可建議項目經理組織進行對模塊設計文檔技術評審。模塊實現及測試按照評審結果開始進行各模塊單元電路及結構設計，并測實驗證，記錄測試結果，不斷完善改善，直至缺陷、故障消除。工藝設計根據硬件模塊的設計，外觀規定等，初步進行工藝設計，并在實現中完善。系統測試系統測試的目的是對最終系統進行全面的測試，保證最終軟件系統滿足產品需求并且遵循系統設計。系統測試過程中發現的所有缺陷必須用統一的缺陷管理工具來管理，開發人員應當及時消除缺陷（改錯）。系統測試的流程如REF_Ref\h圖81所示，關鍵活動是“制定系統測試計劃”、“設計測試用例”、“執行系統測試”和“缺陷管理與改錯”。該流程的重要工作成果和負責人見REF_Ref\h表81。圖81系統測試的流程關鍵活動重要工作成果重要負責人制定測試計劃系統測試計劃測試員設計測試用例系統測試用例測試員執行系統測試系統測試報告測試員缺陷管理與改錯缺陷管理報告測試員表8SEQ表\*ARABIC\s11系統測試的重要工作成果和負責人制定系統測試計劃測試人員測試前起草《系統測試計劃》。該計劃重要涉及：測試范圍（內容）測試方法測試環境與輔助工具測試完畢準則人員與任務表補充說明：項目經理審批《系統測試計劃》。設計系統測試用例測試人員依據《系統測試計劃》和指定的模板，設計（撰寫）《系統測試用例》。補充說明：項目經理審批《系統測試用例》，必要條件下可對該測試用例組織技術評審。待開發人員交付后開始執行系統測試。執行系統測試測試人員依據《系統測試計劃》和《系統測試用例》執行系統測試。將測試結果記錄在《系統測試報告》中，用“缺陷管理工具”來管理所發現的缺陷，并及時通報給開發人員。缺陷管理與改錯在整個系統測試過程中，任何人發現軟件系統中的缺陷時都及時報給項目經理及開發人員。開發人員及時解決，直至所有缺陷所有消除。配置管理配置管理即通過執行版本控制、變更控制等規程，以及使用配置管理軟件，來保證所有配置項的完整性和可跟蹤性。配置管理是對工作成果的一種有效保護。該活動貫穿于整個設計開發過程。凡是納入配置管理范疇的工作成果統稱為配置項，配置項重要有兩大類：（1）屬于產品組成部分的工作成果，例如需求文檔、設計文檔、源代碼、測試用例等。（2）項目管理過程域產生的文檔。每個配置項的重要屬性有：名稱、標記符、文獻狀態、版本、作者、日期等。所有配置項都被保存在配置庫里，保證不會混淆、丟失。配置項及其歷史記錄反映了產品的演化過程?；€由一組配置項組成，這些配置項構成了一個相對穩定的邏輯實體?；€中的配置項被“凍結”了，不能再被任何人隨意修改（見變更控制規程）。基線通常相應于開發過程中的里程碑，一個產品可以有多個基線，也可以只有一個基線?；€的重要屬性有：名稱、標記符、版本、日期等。通常將交付給客戶的基線稱為一個“Release”，為內部開發用的基線則稱為一個“Build”。配置管理的流程如REF_Ref\h圖91所示，關鍵活動是“制定配置管理計劃”、“配置庫管理”、“版本控制”和“變更控制”。該流程的重要工作成果和負責人見REF_Ref\h表91。圖9SEQ圖\*ARABIC\s11配置管理的流程關鍵活動重要工作成果重要負責人制定配置管理計劃配置管理計劃配置管理員配置庫管理配置庫管理報告配置管理員版本控制項目組成員變更控制配置項變更控制報告項目經理表STYLEREF1\s10SEQ表\*ARABIC\s11配置管理重要工作成果和負責人制定配置管理計劃、進行配置庫管理擬定配置管理的軟硬件資源配置管理員根據項目的規模以及財力，擬定配置管理軟件以及計算機資源（考慮內存、外存、CPU等）。制定配置項計劃配置管理員辨認項目的重要配置項。每個配置項都有唯一的標記符，標記符的參考格式為Project-Type…Type-Number?？梢栽赑roject（或Product）前面加上公司的標記符。Type…Type表達配置項類型，可以采用多級縮寫。Number為3為數字，范圍從001到999，表達一個配置項有若干個文獻。若配置項只有一個文獻，則該項可以省略。制定基線計劃配置管理員擬定每個基線的名稱（標記符）及其重要配置項，估計每個基線建立的時間。制定配置庫備份計劃配置管理員制定配置庫備份計劃，指明“何人”在“何時”（頻度）將配置庫備份到“何處”。審批《配置管理計劃》如項目經理承擔配置管理員工作，則由技術負責人審批《配置管理計劃》。否則，項目經理審批，技術負責人簽字認可。配置庫管理配置管理員創建配置庫，并且至少創建配置庫的所有第一級目錄。配置管理員為每個項目成員分派操作權限。一般地，項目成員擁有Add,Checkin/Checkout,Download等權限，但是不能擁有“刪除”權限。配置管理員的權限最高。具體操作視所采用的配置管理軟件而定。項目成員根據自己的權限操作配置庫，例如Add,Checkin/Checkout,Download等。配置管理員根據“基線計劃”創建與維護基線，“凍結”配置項，控制變更。配置管理員定期清除配置庫里的垃圾文獻。配置管理員定期備份配置庫。版本控制配置項狀態變遷規則配置項的狀態有三種：“草稿”（Draft）、“正式發布”（Released）和“正在修改”（Changing）。配置項狀態變遷如REF_Ref\h圖92所示。配置項剛建立時其狀態為“草稿”。配置項通過評審（或審批）后，其狀態變為“正式發布”。此后若更改配置項，必須依照“變更控制規程”執行，其狀態變為“正在修改”。當配置項修改完畢并重新通過評審（或審批）時，其狀態又變為“正式發布”，如此循環。圖9SEQ圖\*ARABIC\s12配置項狀態變遷圖配置項版本號規則配置項的版本號與配置項的狀態緊密相關：處在“草稿”狀態的配置項的版本號格式為：0.YZYZ數字范圍為01-99。隨著草稿的不斷完善，“YZ”的取值應遞增?！癥Z”的初值和增幅由用戶自己把握。處在“正式發布”狀態的配置項的版本號格式為：X.YX為主版本號，取值范圍為1-9。Y為次版本號，取值范圍為1-9。配置項第一次“正式發布”時，版本號為1.0。假如配置項的版本升級幅度比較小，一般只增大Y值，X值保持不變。只有當配置項版本升級幅度比較大時，才允許增大X值。處在“正在修改”狀態的配置項的版本號格式為：X.YZ配置項正在修改時，一般只增大Z值，X.Y值保持不變。當配置項修改完畢，狀態重新成為“正式發布”時，將Z值設立為0，增長X.Y值。參見規則（2）。配置項版本控制流程創建配置項項目成員依據《配置管理計劃》，在配置庫中創建屬于其任務范圍內的配置項。此時配置項的狀態為“草稿”，其版本號格式為0.YZ。修改處在“草稿”狀態的配置