項目開發(fā)管理規(guī)范最新版本.doc

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