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