【文章內(nèi)容簡介】 己團隊開發(fā)一個技術(shù)架構(gòu)，需要項目的技術(shù)領(lǐng)導(dǎo)者進(jìn)行探討，并有必要對這些結(jié)構(gòu)進(jìn)行一些性能方面的測試。編碼主要是把前面分析的功能點一一進(jìn)行實現(xiàn)。 質(zhì)量保證任務(wù)： 實現(xiàn)也就是代碼的生產(chǎn)過程。這里不僅包括代碼的產(chǎn)生，同時也包括測試用例的產(chǎn)生。針對上一階段提供詳細(xì)設(shè)計，程序員開始編碼并且調(diào)試程序，測試人員則根據(jù)設(shè)計進(jìn)行測試用例的設(shè)計，設(shè)計出來的用例需要得到項目組成員認(rèn)可由項目經(jīng)理審核通過才能進(jìn)入配置庫。同時程序員調(diào)試完程序提交測試人員進(jìn)行程序正確性檢測。 基線產(chǎn)品：模塊開發(fā)卷宗，開發(fā)進(jìn)度報表。 ． 階段六：測試 管理任務(wù)： 一個大型的項目必須經(jīng)過功能測試和性能測試，兩個測試階段。功能測試主要針對項目的需求階段設(shè)計出的需求文檔進(jìn)行測試。性能測試主要是對整個編碼完成的項目進(jìn)行性能方面的測試，測試整個項目是不是經(jīng)得起高并發(fā)，高負(fù)載的影響。 質(zhì)量保證任務(wù)： 需要很多輪的測試工作。 需要及時生成測試分析報告，以達(dá)到歲項目整體的質(zhì)量把握。 基線產(chǎn)品：測試分析報告，開發(fā)進(jìn)度報表，項目開發(fā)總結(jié)報告。 ：運行和維護 管理任務(wù)： 其實測試工作和運營可以同時進(jìn)行，運營主要看這個項目需要什么樣的運營方案進(jìn)行支持。 質(zhì)量 保證任務(wù)： 維護小組的任務(wù)一方面是保證對項目客戶的跟蹤服務(wù)，另一方面是確保該項目其它的開發(fā)人員從項目中盡快的解脫出來以便投入到下一個項目的開發(fā)中。所以通常項目維護小組成員主要由項目組的少部分開發(fā)人員承擔(dān)完成。他們不僅了解軟件的核心內(nèi)容，而且與客戶也不陌生，以便能夠以最快的速度修正錯誤。對于一般性的錯誤，如操作不當(dāng)?shù)纫鸬膯栴}，全部由維護小組執(zhí)行完成，但需要用戶測試確認(rèn)上線。如果較大的修改則需要走變更控制流程，用戶或者維護人員填寫變更申請，經(jīng)專家會議討論分析可行方案在由維護小組實施，通過測試后方可提交用戶。 維護小組的人員基本上是按項目跟進(jìn)的。當(dāng)一個項目剛剛交付用戶時，在維護小組有較多的人員進(jìn)行跟進(jìn)，隨軟件的穩(wěn)定，跟進(jìn)的人逐步減少，并轉(zhuǎn)移到其它項目中去。 基線產(chǎn)品：用戶手冊，操作手冊，項目開發(fā)總結(jié)，維護記錄。 此外，貫穿于整個項目開發(fā)過程之中的至關(guān)重要的項目管理對象是： 文檔管理 。 文檔維護主要是配置管理小組的工作。文檔從用途上分主要分為內(nèi)部文檔和外部文檔。 內(nèi)部文檔包括： 項目開發(fā)計劃； 需求分析； 體系結(jié)構(gòu)設(shè)計說明； 詳細(xì)設(shè)計說明； 構(gòu)件索引； 構(gòu)件成分說明； 構(gòu)件接口 及調(diào)用說明； 組件索引； 組件接口及調(diào)用說明； 類索引； 類屬性及方法說明； 測試報告； 測試統(tǒng)計報告； 質(zhì)量監(jiān)督報告； 源代碼； 文檔分類版本索引； 軟件安裝打包文件。 外部文檔主要包括： 軟件安裝手冊； 軟件操作手冊； 在線幫助； 系統(tǒng)性能指標(biāo)報告； 系統(tǒng)操作索引。 如何保證文檔的全面性，使其真正為項目的進(jìn)度提供保證，又不因為文檔的寫作而耽誤項目的進(jìn)度，這仍然是一個比較難解決的問題。解決此問題，其核心仍然是個 度 的問題。在本項目的開發(fā)中，配置管理小組的一個非常重要的任務(wù)還是書寫文檔規(guī)范和文檔模板。當(dāng)有文檔模板后需要書寫文檔的人員只剩下 填空 的工作，從某種意義上講，書寫文檔的速度會加快。如果書寫文檔的人員認(rèn)為文檔的更細(xì)致的部分可以由他人幫助完成，則該文檔即交由他人完成，但此時文檔并不算被正式提交，當(dāng)他人書寫完畢之后，必須由文檔的初寫者進(jìn)行復(fù)審，復(fù)審?fù)ㄟ^后方可以正式提交，進(jìn)入軟件配置管理的循環(huán)中。 配置管理小組真正核心的工作是對文檔的組織管理。根據(jù)文檔的不同，文檔的來源也不同，有些是通過質(zhì)量保證小組經(jīng)過復(fù)審之后轉(zhuǎn)交給配置管理小組，有些則會直接從文檔的出處到達(dá)配置管理小組。 文檔的管理是一個非常煩瑣的工作，但是長遠(yuǎn)來看它不僅使項目的開發(fā)對單個主要人員的依賴減少，從而減少人員流動給項目的帶來的風(fēng)險，更重要的是在項目進(jìn)行到后百分之十的時候起到拉動項目的作用。 從以往做大項目的經(jīng)驗來看，寫作文檔在項目開發(fā)的早期可能會使項目的進(jìn)度比起不寫文檔要稍慢，但隨著項目的進(jìn)展，各個部門需要配合越來越多，開發(fā)者越來越需要知道其他人員的開發(fā)思路和開發(fā)過程，才能使自己的開發(fā)向前推進(jìn)。一個明顯的例子就是系統(tǒng)整合，或者某些環(huán)節(jié)是建立在其他環(huán)節(jié)完成的基礎(chǔ)之上時，就更顯現(xiàn)出文檔交流的準(zhǔn)確性和高效性。 10．項目風(fēng)險管理 、項目風(fēng)險管理的目的 風(fēng)險是指在項目進(jìn)行過程中可能發(fā)生的事件，這些事件將會對項目按預(yù)期時間，資源和預(yù)算完成產(chǎn)生重大影響。風(fēng)險管理的目標(biāo)是在潛在問題發(fā)作以前就標(biāo)志它們，這樣就可以在生命周期中可以適時地計劃和啟用風(fēng)險處理活動。 、項目風(fēng)險管理的組成 風(fēng) 險 管 理風(fēng) 險 評 估 風(fēng) 險 控 制風(fēng)險識別風(fēng)險優(yōu)先級風(fēng)險分析風(fēng)險管理計劃風(fēng)險化解風(fēng)險監(jiān)控 、風(fēng)險的種類 分清風(fēng)險的種類有利于更好的對項目進(jìn)行風(fēng)險管理。 資源風(fēng)險 組織 對該項目是否有足夠的支持（包 括管理人員、測試員、 QA 和其他外部的相關(guān)各方）。 這是否是該組織嘗試過的最大項目。 軟件工程是否有明確定義的流程？需求記錄和管理。 資金 完成項目所需的資金是否到位。 是否為培訓(xùn)和指導(dǎo)分配了資金。 是否有預(yù)算限制使得系統(tǒng)必須以固定的成本交付，否則將被取消。 成本估算是否準(zhǔn)確 人員 是否可以獲得足夠 的項目工作 人員。 他們是否具備合適的技能和經(jīng)驗。 他們以前是否在一起工作過。 他們是否相信項目會成功。 是否可以找到用戶代表來擔(dān)任復(fù)審員。 是否可以找到領(lǐng)域?qū)＜?。 時間 時間表制定得是否現(xiàn)實。 是否可以為了滿足時間表而對功能進(jìn)行規(guī)模管理。 對交付日期的要求有多嚴(yán)格。 是否有時間“把工作做好”。 業(yè)務(wù)風(fēng)險 如果競爭對手搶先將產(chǎn)品推向市場怎么辦。 如何確保有足夠的資金 。 系統(tǒng)的預(yù)計價值是否大于預(yù)計成本？（考慮貨幣的時間價值和資金的成本）。 如果無法同關(guān)鍵的供應(yīng)商簽定合同怎么辦。 技術(shù)風(fēng)險 規(guī)模風(fēng)險 成功是否能夠被評測。 是否有關(guān)于如何評測成功的協(xié)議。 需求是否相當(dāng)穩(wěn)定并得到了充分的了解。 項目規(guī) 模是固定不變還是在不斷擴展。 項目開發(fā)的時間范圍是否太短、不夠靈活。 技術(shù)風(fēng)險 技術(shù)是否已經(jīng)過證明。 重復(fù)使用目標(biāo)是否合理。 工件必須要使用一次后才能被重復(fù)使用。 構(gòu)件可能要在若干次發(fā)布后才能變得穩(wěn)定，以致無需重大變更即可復(fù)用。 需求中的事務(wù)量是否合理。 事務(wù)比率的估計值是否可靠？這些估計是否過于樂觀。 數(shù)據(jù)量是否合理？當(dāng)前可用的框架是否能夠保存這些數(shù)據(jù)，或者，如果需求使您相信工作站或部門系統(tǒng)將成為設(shè)計的一部分，那么是否能夠在這些地方合理地保存數(shù)據(jù)。 是否有特殊或苛刻的技術(shù)需求 。 成 功是否依賴于新的或未經(jīng)試驗的產(chǎn)品、服務(wù)或技術(shù)？是否依賴于新的或未被證明的硬件、軟件或技術(shù)。 對于與其他系統(tǒng)（包括企業(yè)以外的系統(tǒng)）的接口是否存在外部依賴性？是否存在必需的接口或必須創(chuàng)建它們 。 是否存在極不靈活的可用性和安全性需求（例如“系統(tǒng)必須永遠(yuǎn)不出現(xiàn)故障”）。 系統(tǒng)的用戶是否對正在開發(fā)的系統(tǒng)類型沒有經(jīng)驗。 應(yīng)用程序的大小或復(fù)雜性，或者技術(shù)的新穎性是否導(dǎo)致了風(fēng)險的增加。 是否存在對國家語言支持的需求。 是否可能設(shè)計、實施和運行該系統(tǒng)？某些系統(tǒng)只由于太大或太復(fù)雜而無法正常工作。 外部依 賴性風(fēng)險 該項目是否依賴于其他（平行的）開發(fā)項目。 成功是否依賴于市售產(chǎn)品或外部開發(fā)的構(gòu)件。 成功是否依賴于開發(fā)工具（設(shè)計工具、編譯器等）和實施技術(shù)（操作系統(tǒng)、數(shù)據(jù)庫、進(jìn)程間通信機制等）的成功集成。您是否有替代計劃，可以在沒有這些技術(shù)的情況下交付項目。 進(jìn)度風(fēng)險 功能是否無限追加。 計劃是否過于樂觀。 是否缺乏計劃。 在壓力下是否放棄計劃。 是否追趕計劃。 、定義風(fēng)險參數(shù) 風(fēng)險參數(shù)可用于評估、分類和劃分風(fēng)險的優(yōu)先級；該項目將發(fā)生的可能性的等級劃分為：非?？赡馨l(fā)生，可能發(fā)生，幾乎不可能 發(fā)生 3 個級別。將對項目的影響程度劃分為：非常嚴(yán)重影響，嚴(yán)重影響，中等影響，微弱影響 4 個級別。相應(yīng)的表格如下： 發(fā)生的可能性 對項目的影響程度 名稱 等級 名稱 等級 非?？赡馨l(fā)生 3 非常嚴(yán)重影響 4 可能發(fā)生 2 嚴(yán)重影響 3 幾乎不可能發(fā)生 2 中等影響 2 微弱影響 1 、風(fēng)險管理策略 有三種主要的策略： *風(fēng)險規(guī)避：使其不再受到該風(fēng)險的影響。 *風(fēng)險轉(zhuǎn)移：讓其他方（客戶、廠商、銀行、其他主體等）承擔(dān)該風(fēng)險。 *風(fēng)險接受：決定將該風(fēng)險當(dāng)作意外事件來接受。監(jiān)測風(fēng)險征兆，并制 定應(yīng)急計劃，以確定在風(fēng)險發(fā)生時將采取何種行動。 、風(fēng)險管理角色及職責(zé) （ 1）項目經(jīng)理 項目經(jīng)理對風(fēng)險管理工作負(fù)全部責(zé)任。 （ 2）項目組開發(fā)人員 項目組開發(fā)人員將被要求作為項目風(fēng)險分析組的成員，對項目工作中存在的風(fēng)險進(jìn)行分析，并整理成書面材料。 （ 3） SQA SQA 經(jīng)理將定期對風(fēng)險管理工作開展情況進(jìn)行評審，確保所開展的風(fēng)險管理工作符合組織的要求。 、個人 微薄 項目中風(fēng)險的識別 根據(jù)風(fēng)險識別的分類標(biāo)準(zhǔn)可以識別出個人 微薄 項目中存在的風(fēng)險，如下： 資源風(fēng)險 完成該項目所需的資金受到一定的限制，人員的培 訓(xùn)指導(dǎo)資金不到位，存在一定資金風(fēng)險；參與項目的部分人員沒有一起工作過，也存在著一定的人員風(fēng)險；此外，交付日期的嚴(yán)格要求導(dǎo)致項目存在時間風(fēng)險。 業(yè)務(wù)風(fēng)險 由于軟件行業(yè)的飛速發(fā)展，競爭對手可能搶先將產(chǎn)品推向市場，故存在著業(yè)務(wù)風(fēng)險。 技術(shù)風(fēng)險 客戶可能隨時提出需求和對項目的改進(jìn)，需求的不穩(wěn)定性和項目規(guī)模的不斷擴展，可能導(dǎo)致項目存在規(guī)模風(fēng)險。 進(jìn)度風(fēng)險 功能的無限追加，在強大的壓力下放棄計劃都造成了項目的進(jìn)度風(fēng)險。 、風(fēng)險的控制 1．控制方法 （ 1）風(fēng)險管理計劃 重點是制定一個計劃，以處理在排位靠前的高風(fēng)險 項。 風(fēng)險管理計劃每階段 /迭代重新評估一次。風(fēng)險監(jiān)控時選取風(fēng)險管理計劃中沒有關(guān)閉的前 10 大風(fēng)險進(jìn)行監(jiān)控即可。每階段 /迭代啟動時，選取“風(fēng)險管理計劃”中處于“監(jiān)控”狀態(tài)的前 10 大風(fēng)險，用于本階段 /迭代的周例會上進(jìn)行跟蹤和監(jiān)控（注意：周例會時只監(jiān)控階段 /迭代啟動時監(jiān)控的前 10 大風(fēng)險）。 （ 2）風(fēng)險的化解 避免風(fēng)險（即：不要做冒險的活動） 將風(fēng)險從系統(tǒng)的一部分轉(zhuǎn)移到另一部分（可能對于系統(tǒng)的其他部分此風(fēng)險不會發(fā)生或發(fā)生時影響不大） 購買關(guān)于風(fēng)險的信息（例如：做實驗性項目，請咨詢專家等） 消除風(fēng)險的根源 接受風(fēng)險（如 果風(fēng)險后果較小，而處理它可能代價很大，滾動處理可能是最有效的途徑） 發(fā)布風(fēng)險（將風(fēng)險發(fā)布給相關(guān)涉眾，如：管理者、市場人員、客戶 {特別注意策略 }等） 控制風(fēng)險 制定風(fēng)險無法化解時的“風(fēng)險應(yīng)急計劃” 分配額外的資源來處理風(fēng)險 為處理風(fēng)險留出額外的時間 記住風(fēng)險（為將來的項目積累） ． 風(fēng)險監(jiān)控 （ 1）周例會檢查風(fēng)險 在周工作例會上，項目經(jīng)理需要跟蹤項目的風(fēng)險。 根據(jù)風(fēng)險列表，逐一分析前 10 大風(fēng)險，確認(rèn)已經(jīng)風(fēng)險狀態(tài)是否“發(fā)生”或“關(guān)閉”； 如果風(fēng)險發(fā)生則啟動“風(fēng)險應(yīng)急計劃”或項目組協(xié)商解決辦法，必要時 PM請求相關(guān)高級管理者解決已發(fā)生的風(fēng)險，并且 PM 負(fù)責(zé)在風(fēng)險管理計劃中將此條風(fēng)險標(biāo)示為“發(fā)生”。 如果風(fēng)險已經(jīng)消除，則 PM 負(fù)責(zé)在風(fēng)險管理計劃中將此條風(fēng)險標(biāo)示為“關(guān)閉”。 統(tǒng)計每項風(fēng)險的停留時間 (周數(shù) )。 、 微薄 項目的風(fēng)險管理 個人微薄 項目的主要風(fēng)險是開發(fā)人員對客戶需求不是很熟悉，另外，客戶要求的進(jìn)度比較緊，而且具體需求不是很明確，客戶可能隨時提出需求和對項目的改進(jìn)，需求的不穩(wěn)定性和項目規(guī)模的不斷擴展，可能導(dǎo)致項目存在規(guī)模風(fēng)險。功能的無限追加，在強大的壓力下放棄計劃都造成了項目的進(jìn)度風(fēng)險。下面的這個風(fēng) 險列表就是通過一系列的風(fēng)險識別、風(fēng)險評估、風(fēng)險應(yīng)對，等到的 微薄 項目的風(fēng)險列表。 排序 輸入 風(fēng)險事件 可能性 影響 風(fēng)險值 風(fēng)險應(yīng)對措施 1 客戶的SOW 需求不明確，增加需求，導(dǎo)致需求蔓延 3 3 9 1．采取加班的方法 2．修改計劃去掉一些任務(wù) 3．與客戶商量延長一些時間 2 WBS 復(fù)雜模塊的技術(shù)難關(guān) 2 3 6 對復(fù)雜模塊進(jìn)行外包 3 合同 進(jìn)度要求緊，合同金額有限 2 3 6 可以請一些實習(xí)的學(xué)生做輔助工作 ,一來成本不高 ,二來可以加快進(jìn)度 . 4 WBS 供貨商、外包商的質(zhì)量問題 1 3 3 多選擇幾個可以作為備份的外包商和供應(yīng)商 5 歷史項目信息 開發(fā)人員的流動 1 3 3 1．注意項目團隊的溝通，及時了解開發(fā)人員的動態(tài) 2．控制好項目過程中的文檔 組借調(diào)人員 4．從外部招聘有過此類開發(fā)經(jīng)驗人員 6 規(guī)模