在線書店管理程序-軟件項目管理大作業(yè)

1、精選優(yōu)質(zhì)文檔-傾情為你奉上目錄 第一部分 合同管理1.1需方合同環(huán)境1.1.1 合同準備藍鯨書店信息有關重要文件需要提供書店的基本重要信息，比如書店管理人信息，投資人信息，法人代表信息，工作人員信息，書店所屬土地信息，書店地址，書店存書所有信息，進貨信息等基本信息。·供方選擇供方根據(jù)項目此項目整理的工作人員名單、最終供方確定的程序、確定最終的供方名單及其提供的建議書。·合同文本準備藍鯨書店根據(jù)資料進行合同草案指定、草案評審、修訂等程序，最終確定合同草案（合同草案略）。1.1.2 合同簽署藍鯨書店與IT項目團隊以藍鯨書店提出的合同草案為基礎，經(jīng)過確定談判日程、合同草案提交、合

2、同條款協(xié)商、確定合同簽署文本、合同簽署文本審閱、合同簽署的流程完成合同簽署。最終形成合同簽署文本以及任務下達書。并將任務下達書分發(fā)給IT項目團隊的管理人及其各部門工作人員。1.1.3 合同管理·驗收過程藍鯨書店依據(jù)合同準備和合同簽署時確定的需求資料及合同文本制定驗收清單。對驗收清單評審后制定驗收計劃，并按驗收計劃執(zhí)行，得到驗收報告。對發(fā)現(xiàn)的問題制定驗收問題處理計劃，最終確認驗收報告。·違約事件處理過程在合同執(zhí)行期內(nèi)，如果合同雙方藍鯨書店或IT項目管理團隊有違約事件。需根據(jù)違約事件報告進行違約事件通告，確定處理方式后按計劃處理違約事件。之后形成違約事件處理報告。1.1.4 合

3、同終止過程藍鯨書店與IT項目團隊根據(jù)合同及相關文檔，發(fā)布合同終止通知、項目執(zhí)行總結。1.2供方合同環(huán)境1.2.1合同準備·項目分析IT項目管理團隊根據(jù)合同安排項目分析任務。經(jīng)過需求管理者確定、需求分析、需求分析評審、項目規(guī)模估算、項目風險分析、項目初步實施規(guī)劃、初步實施規(guī)劃評審，最終得到需求分析報告和項目初步規(guī)劃。·合同文本準備IT項目管理團隊根據(jù)藍鯨書點提出的資料制定合同草案。在經(jīng)評審和修訂后確定己方的合同草案。1.2.2合同簽署同需方，此處略。1.2.3合同管理·合同執(zhí)行跟蹤管理過程IT項目管理團隊以項目計劃為基礎，進行項目計劃審批和合同執(zhí)行管理規(guī)劃。按計劃完

4、成項目進展報告、合同責任落實、需求變更處理和產(chǎn)品驗收。·合同修改控制如果需方即藍鯨書店提出變更請求，假設提出的是要求添加不用登錄網(wǎng)頁直接通過“在線書店”應用程序即可向網(wǎng)內(nèi)用戶發(fā)送郵件，并根據(jù)不同層級用戶的權限顯示網(wǎng)內(nèi)在線用戶。則IT項目管理團隊需依據(jù)合同和變更請求進行變更評估，并提出合同修改建議，確定修改策略。對當前計劃進行調(diào)整，并需得出處理報告。·違約事件處理過程同需方，此處略。·產(chǎn)品提交過程在產(chǎn)品的開發(fā)測試結束后向藍鯨書店提交產(chǎn)品，經(jīng)過審查后正式提交給藍鯨書店。最終相方簽字認可，通知相關各方。·產(chǎn)品維護過程根據(jù)合同中的維護需求，制定維護需求記錄。1.

5、2.4合同終止過程同需方，此處略。1.3內(nèi)部環(huán)境IT項目管理團隊內(nèi)部確定任務范圍，使相關各方有效的配合。詳細任務分解在第四部分任務分解中會有詳細闡述。1.4合同·合同雙方甲方：藍鯨書店乙方：IT項目管理團隊·協(xié)議形式協(xié)議形式：技術合同·供應的商品和服務供應的軟件：乙方為甲方提供所需的“在線書店”應用程序提供的服務：乙方為甲方提供所需的日常維護和服務器管理。同時對甲方用戶提供使用教學。提供的文檔：乙方在交付軟件時提供詳細的軟件規(guī)格說明書和使用文檔。安裝服務： 乙方為甲方提供軟件的安裝。公文處理： 乙方負責將甲方提供的公文資料加載入系統(tǒng)并進行分類維護協(xié)議： 當甲方在使

6、用該產(chǎn)品時，在正常操作的情況下出現(xiàn)BUG或系統(tǒng)錯誤，乙方免費為甲方提供修復服務以保障軟件的正常使用。當由于甲方的錯誤使用等非軟件原因?qū)е鲁霈F(xiàn)故障，乙方同樣提供修復服務。由于甲方擁有該軟件的源代碼所有權，因此甲方需要承擔部分維修和進一步開發(fā)的責任。當軟件需要新的功能拓展或改版升級時，由雙方共同協(xié)商決定。·軟件所有權該軟件是由甲方向乙方定制，甲方擁有該軟件的版權，乙方不能將該軟件的任何版本賣個其他客戶。軟件提交時，項目源代碼的所有權自動移交到甲方，乙方不得擅自對源代碼進行修改。·環(huán)境乙方為甲方安裝軟件和進行員工培訓時，需要由甲方提供住宿和膳食，乙方在規(guī)定時間內(nèi)完成任務。甲方要保

7、證安裝軟件的硬件設備和合同初始規(guī)定一致，乙方只保證軟件和規(guī)定的硬件兼容。由任何一方的單方面原因?qū)е碌难悠诋a(chǎn)生的費用，由該方面支付。·客戶承諾乙方開發(fā)軟件過程中，甲方通過人員協(xié)同乙方進行開發(fā)。該人員主要參與項目的規(guī)劃設計和需求分析，階段性驗收和總體測試。當項目出現(xiàn)需求變更時，對乙方進行詳細的闡述說明。乙方不負責這些人員提供食宿和聯(lián)系設備。·驗收規(guī)程2016年6月15日，乙方為甲方安裝所需套數(shù)的軟件。6月15日至6月31日甲方代表對產(chǎn)品進行驗收測試，并根據(jù)需求在6月30日前對產(chǎn)品提出更正請求。測試通過后，雙方進行軟件交付簽字。乙方對甲方進行軟件使用培訓。·標準乙方在開

8、發(fā)過程中必須遵守ISO 12207關于軟件生命周期和文檔的標準。·項目和質(zhì)量管理甲乙雙方前四個月每月初進行一次進展會議，后三個月每兩周周末進行進展會議。會議內(nèi)容為乙方向甲方提供最新進度的展示和下一階段的工作安排和計劃。甲方根據(jù)演示提出相應的整改意見，并對下一步工作進行提出意見和建議。·時間表詳細時間表見項目進度。此處略。·價格和付款方式軟件總價為200萬元。合同簽訂后，甲方向乙方支付50萬元定金。項目的第三個月，乙方按計劃時間表完成需求分析、系統(tǒng)分析、設計和完成系統(tǒng)的基本框架后，甲方向乙方支付80萬元。該系統(tǒng)完成后，甲方進行驗收測試，在簽字驗收后完成后，甲方向乙方

9、支付全款。·其他法律要求由任何一方的過失導致出現(xiàn)損失后的賠償由雙方協(xié)商決定。甲方法人代表：SSS乙方法人代表：XXX第二部分 生存期確定該項目的生存期模型按如下步驟進行分析：評審、分析項目的特性；選擇適合項目的生存期模型；標識生存期模型與項目不一致地方,并進行裁減?！霸诰€書店”應用程序涉及到用戶的使用感受，需保障產(chǎn)品能保持穩(wěn)定運行，不會因為一定數(shù)量的用戶共同使用等操作時掛機，以致用戶的瀏覽保存記錄丟失和降低用戶使用感?？偠灾擁椖靠刹僮餍院徒缑婷烙^度為主。項目生存期模型如下：該生存期模型將V模型除最后的項目規(guī)劃和驗收測試以外的過程做一復制，套用增量模型在首先完成基本功能的基礎上增加

10、功能。第三部分 需求管理3.1軟件需求管理過程藍鯨書店提出需求如下：設計開發(fā)、安裝調(diào)試并后期維護滿足需求的“在線書店”應用程序。需要該程序有前臺程序，進入程序后需要彈出書單界面，也需要有后臺程序，方便管理。主要有前臺（客戶購買）和后臺（管理員管理）2個主要功能，每個功能需在辦公界面中有獨立的快捷方式。每個功能的具體要求如下：（1）前臺（客戶購買）部分：1.用戶管理：注冊會員、登錄、激活、退出、修改密碼；2.分類顯示：顯示所有1級和2級分類；3.圖書顯示：按分類查詢圖書、通過關鍵字搜索圖書、高級搜索圖書、查看某本圖書的詳細等；4.購物車管理：向購物車中添加圖書、修改購物車中圖書數(shù)量、刪除除購車中

11、圖書、我的購物車；5.訂單管理：通過購物車中圖書生成訂單、查看我的訂單、查看某個訂單的詳細、訂單支付、確認收貨、取消未付款訂單。（2）后臺（管理員管理）部分：1.管理員：管理員登錄；2.分類管理：查看所有分類、添加1級分類、添加2級分類、修改1級分類、 修改2級分類、刪除1級分類、刪除2級分類；3.圖書管理：按分類搜索圖書、高級搜索圖書、添加新圖書、查看圖書詳細信息、編輯圖書、刪除圖書；4.訂單管理：按狀態(tài)搜索訂單、查看訂單詳細信息、取消訂單、發(fā)貨；3.1.1 需求規(guī)格·需求規(guī)格說明書（簡略版）系統(tǒng)定義：“在線書店”應用程序應用環(huán)境：Windows2000；Windows XP；Wi

12、ndows Vista；Windows 7；LINUX；IOS etc.功能規(guī)格：前臺（客戶購買）、后臺（管理員管理）性能需求：保證所有人員同時登錄服務器時也不會因處理的信息量過大而導致系統(tǒng)癱瘓。另必須保證系統(tǒng)的安全性，對賬戶有足夠的保護措施以防賬戶被盜。操作簡單明了，提示明顯，容易上手，界面整潔大方。產(chǎn)品提交：略實現(xiàn)約束：用戶管理、分類顯示、圖書顯示、購物車管理、訂單管理、管理 員、分類管理、圖書管理、訂單管理質(zhì)量描述：如需求所述的足夠用戶承載量；可靠的系統(tǒng)安全性；操作簡單易學。界面整潔大方其他：略簽字認證：甲方（需方）：藍鯨書店 乙方（供方）：IT項目管理團隊3.1.2需求管理圖需求管理包

13、含5個特定實踐，如圖1所示。獲得對需求的理解。在初步整理需求的基礎上，和用戶代表通過初步的分析討論，對當前項目的需求達成共識，并在需求列表中作相應記錄。獲取需求承諾。通過項目參與者的書面承諾，建立各方或各項工作的基準。管理需求變更。維護變更歷史，為調(diào)整與控制提供數(shù)據(jù)。在需求變更后維護對需求的雙向可追溯性。從軟件可維護性的角度提出管理要求。標識項目工作(包括和產(chǎn)品)與需求的不一致性。若發(fā)現(xiàn)不一致性，即啟動。3.1.3需求變更管理·需求變更假設藍鯨書店向IT項目管理團隊提出如下需求變更：在辦公界面做一個可收縮的列表，顯示當前系統(tǒng)在線的工作人員，。·軟件基線產(chǎn)品修改提交單申請人：

14、XXX申請日期：2016年7月6日項目名稱：“在線書店”應用程序階段名稱：文件名稱：修改內(nèi)容：增加功能“可收縮的在線工作人員顯示列表”驗證意見：同意變更，郵箱功能隨之變更驗證人：YYY驗證日期：2016年9月8日SCCB：SSS、CCC、BBB填表人：ZZZ第四部分 任務分解4.1任務清單4.1.1 功能分解清單1“在線書店”應用程序1.1用戶管理1.1.1 注冊會員1.1.2 登錄1.1.3 激活1.1.4 退出1.1.5 修改密碼 1.1.6 單元測試1.2 分類顯示1.2.1 顯示一級分類1.2.2 顯示二級分類1.2.3 界面 1.2.4 單元測試1.3 圖書顯示1.3.1 按分類查詢

15、圖書1.3.2 通過關鍵字搜索圖書1.3.3 高級搜索圖書 1.3.4 查看某本圖書的詳細 1.3.5 單元測試1.4 購物車管理 1.4.1向購物車中添加圖書 1.4.2修改購物車中圖書數(shù)量 1.4.3刪除購物車中圖書 1.4.4我的購物車 1.4.5單元測試1.5訂單管理 1.5.1通過購物車中圖書生成訂單 1.5.2查看我的訂單 1.5.3查看某個訂單的詳細 1.5.4訂單支付 1.5.5確認收貨 1.5.6取消未付款訂單 1.5.7單元測試1.6 管理員 1.6.1管理員登錄1.7分類管理 1.7.1查看所有分類 1.7.2添加1級分類 1.7.3添加2級分類 1.7.4修改1級分類

16、1.7.5修改2級分類 1.7.6刪除1級分類 1.7.7刪除2級分類 1.77.8單元測試1.8圖書管理 1.8.1按分類搜索圖書 1.8.2高級搜索圖書 1.8.3添加新圖書 1.8.4查看圖書詳細信息 1.8.5編輯圖書 1.8.6刪除圖書 1.8.7單元測試1.9訂單管理 1.9.1按狀態(tài)搜索訂單 1.9.2查看訂單詳細信息 1.9.3取消訂單 1.9.4發(fā)貨4.2WBS(1) WBS的定義WBS（工作分解結構）是Work Breakdown Structure的英文縮寫，是重要的專業(yè)術語之一。WBS的基本定義 ：以可交付成果為導向?qū)椖恳剡M行的分組，它歸納和定義了項目的整個工作范圍

17、每下降一層代表對項目工作的更詳細定義。無論在項目管理實踐中，還是在PMP，IPMP考試中，工作分解結構(WBS)都是最重要的內(nèi)容之一。WBS總是處于計劃過程的中心，也是制定進度計劃、資源需求、成本預算、風險管理計劃和采購計劃等的重要基礎。WBS同時也是控制項目變更的重要基礎。項目范圍是由WBS定義的，所以WBS也是一個項目的綜合工具。(2)WBS字典 管理的規(guī)范化、標準化一直是眾多公司追求的目標，WBS字典就是這樣一種工具。它用于描述和定義WBS元素中的工作的文檔。字典相當于對某一WBS元素的規(guī)范，即WBS元素必須完成的工作以及對工作的詳細描述；工作成果的描述和相應規(guī)范標準；元素上下級關系以及

18、元素成果輸入輸出關系等。同時WBS字典對于清晰的定義項目范圍也有著巨大的規(guī)范作用，它使得WBS易于理解和被組織以外的參與者（如承包商）接受。在建筑業(yè)，工程量清單規(guī)范就是典型的工作包級別的WBS字典。(3)WBS的分層 WBS是進行計劃，人員分配，預算計劃的基礎，沒有WBS工作，后面的一切工作都沒有依據(jù)。WBS的分層分解圖如圖2所示(4)系統(tǒng)的WBS 前臺：用戶購書功能WBS圖如圖3所示第五部分 項目估算5.1成本估算5.1 .1直接成本估算 項目開發(fā)工作量估算表 單位：人天編號任務名稱估計值小計前臺設計：531用戶管理模塊82分類顯示模塊103圖書查詢模塊104購物車管理模塊105訂單管理模塊

19、15后臺管理：526分類顯示模塊107圖書查詢模塊248訂單管理模塊18 表1從上圖得知項目工作量是105/人天，假設開發(fā)人員開發(fā)成本參數(shù)=500/人天，則內(nèi)部開發(fā)成本=500*105=52500元。管理和質(zhì)量成本可以根據(jù)以往的經(jīng)驗，管理和質(zhì)量成本約為開發(fā)成本的30%，即：52500*30%=15750元。則直接開發(fā)成本=開發(fā)成本+管理和質(zhì)量成本=68250元。5.1.2 間接成本估算項目名稱在線書店管理系統(tǒng)項目經(jīng)理梁某估算小組成員張三，李四，王五估算階段與日期2014.6.10工作分解結構項目規(guī)模系統(tǒng)模塊新代發(fā)模塊的規(guī)模（代碼行、類、文檔頁數(shù)）復用或自動生成的組件（代碼行、類、文檔頁數(shù)）規(guī)模

20、模塊11025模塊22030模塊32520模塊41515模塊總和7090工作量估計項目研發(fā)工作量估計項目研發(fā)的工作量=100新開發(fā)組件的規(guī)模難度系數(shù)人均生產(chǎn)率10058需求開發(fā)工作量25系統(tǒng)設計工作量15編程工作量30測試工作量25研發(fā)總工作量95項目管理工作量估計項目管理的工作量=75比例系數(shù)0.75項目規(guī)劃工作量16項目監(jiān)控工作量22需求管理工作量21管理工作量14項目支撐工作量估計項目支撐的工作量=30比例系數(shù)0.25配置管理工作量5質(zhì)量保證工作量5外包與采購工作量4培訓管理工作量6支撐總工作量20成本估計類別細分、說明金額人力資源成本2000050000 表25.1.3估算的誤差任務編

21、號里程碑計劃工作預算成本已完成工作預算成本實際成本變量（%）計劃成本1已完成100100100002已完成5050550-103已完成5050400204未開工7000-100-5已完成90901400-55.56未開工7000-100-7已完成4050250508未開工5000-總計450340360-24.4-5.9 表3EAC = （360/340）* = （元）超支 = - = 34059（元）第六部分 項目進度項目進度管理是指在實施過程中，對各階段的進展程度和項目最終完成的期限所進行的。是在規(guī)定的時間內(nèi)，擬定出合理且的進度計劃（包括多級管理的子計劃），在執(zhí)行該的過程中，經(jīng)常要檢查實際

22、進度是否按計劃要求進行，若出現(xiàn)，便要及時找出原因，采取必要的補救措施或調(diào)整、修改原計劃，直至項目完成。其目的是保證項目能在滿足其時間約束條件的前提下實現(xiàn)其總體目標。 6.1定義活動定義活動是一過程，它涉及確認和描述一些特定的活動，完成了這些活動意 味著完成了WBS結構中的項目細目和子細目。通過定義活動體現(xiàn)項目工作內(nèi)容的完成，定義活動的輸入輸出圖如圖5所示 6.2活動排序活動排序過程包括確認且編制活動間的相關性。實際上，這是一個開發(fā)網(wǎng)絡圖的過程。網(wǎng)絡圖是一種示意圖，描繪項目中各項活動以及它們的時序關系?；顒颖仨毐徽_地加以排序以便今后制定實現(xiàn)的可行的進度計劃，可用手工進行排序，大型項目也可以用專

23、門的軟件。排序還因為存在的特定的約束，包括：1.技術需求和規(guī)范2.安全性與效率3.企業(yè)政策與偏好4.資源可用性活動排序過程包括編制活動間的三種相關性:1.內(nèi)在的相關性（強制依賴關系）2.指定性的相關性（資源依賴關系）3.與外部相關性（外部依賴關系）活動間有四種相關依賴的關系：結束>開始：某活動必須結束，然后另一個活動才能開始。結束>結束：某活動結束前，另一活動必須結束。開始>開始：某活動必須在另一活動開始時開始。開始>結束：某活動結束前另一活動必須開始?；顒优判虻慕Y果（輸出）是項目網(wǎng)絡圖。項目網(wǎng)絡圖是項目所有活動以及它們之間邏輯關系（相關性）的一個圖解表示，6.3活動時

24、間估計活動時間估計指預計完成各活動所需時間長短，在項目團隊中熟悉該活動特性的個人和小組可對活動所需時間做出估計?；顒訒r間估計的輸入包括活動目錄，結束和假設，還有：1.資源需求2.資源數(shù)量活動所需時間估計的工具和方法：1.專家判斷2.類推估計6.4項目進度安排工作集子工作完成時間負責人最終交付物描述項目計劃確定負責人以及組長第二周小小負責人以及組長名單完成在線書店管理系統(tǒng)開發(fā)團隊的工作分配確定小組第三周王二小組成員名單成立系統(tǒng)開發(fā)團隊小組搭建環(huán)境第三周各組組長開發(fā)環(huán)境運行說明文檔確定項目 開發(fā)的工具及語言制定項目管理計劃書第四周熊寶項目管理計劃書初稿制定軟件開發(fā)過程管理計劃初步完成需求規(guī)格說明書

25、采集用戶需求第五周小小、熊寶需求規(guī)格說明書通過與用戶溝通以及查閱相關資料了解和采集用戶的需求。對需求進行匯總，制定需求規(guī)格說明初稿分析用戶需求及制定需求規(guī)格說明原型第五周需求規(guī)格說明的進一步完善與修改第六周需求規(guī)格說明的最后確認第七周系統(tǒng)設計系統(tǒng)總體設計第八周張三軟件設計報告初稿制定系統(tǒng)總體的設計方案，并根據(jù)需求說明聯(lián)系實際進行相應的修改系統(tǒng)詳細設計第九周系統(tǒng)模型及架構最后確定第十周開發(fā)系統(tǒng)源代碼及源碼測試系統(tǒng)源碼開發(fā)第十一周李四 交付源代碼掌握開發(fā)工具的使用系統(tǒng)源碼測試第十二周王五 測試文檔根據(jù)測試要求嚴格測試系統(tǒng)源碼復查第十三周吳倩無對代碼進行復查，盡量減少bug進行整個在線書店滾輪系統(tǒng)的

26、集成進行整個網(wǎng)上教學系統(tǒng)的集成第十四周梁冰無與其他小組長無間協(xié)作完成整個系統(tǒng)的集成對整個集成后的系統(tǒng)進行測試檢查 運行情況第十四周張夢無配置好IIS服務，搭建整個系統(tǒng)的運行平臺測試整個系統(tǒng)的發(fā)布情況系統(tǒng)交付系統(tǒng)交付第十五周張斌系統(tǒng)能夠運行以及 以及把相關技術文歸類存檔各組之間可以交流各自的開發(fā)經(jīng)驗和心得體會 表46.5工具使用Microsoft Project是國際上最為盛行與通用的項目管理軟件，適用于新產(chǎn)品研發(fā)、IT、房地產(chǎn)、工程、大型活動等多種項目類型。經(jīng)過微軟多年研發(fā)，Project包含了經(jīng)典的項目管理思想和技術以及全球眾多企業(yè)的項目管理實踐。在企業(yè)內(nèi)部使用和推廣Project，在提升項

27、目管理人員能力的同時也實現(xiàn)了項目管理專業(yè)化與規(guī)范化的過程。第七部分 質(zhì)量計劃項目質(zhì)量計劃是指為確定項目應該達到的質(zhì)量標準和如何達到這些項目質(zhì)量標準而做的項目質(zhì)量的計劃與安排。項目質(zhì)量計劃是質(zhì)量策劃的結果之一。它規(guī)定與項目相關的質(zhì)量標準，如何滿足這些標準，由誰及何時應使用哪些程序和相關資源。 項目質(zhì)量計劃工作的成果：項目質(zhì)量計劃、項目質(zhì)量工作說明、質(zhì)量核檢清單、可用于其它管理的信息。7.1質(zhì)量計劃編制編制項目的質(zhì)量計劃，首先必須確定項目的范圍、中間產(chǎn)品和最終產(chǎn)品，然后明確關于中間產(chǎn)品和最終產(chǎn)品的有關規(guī)定、標準，確定可能影響產(chǎn)品質(zhì)量的技術要點，并找出能夠確保高效滿足相關規(guī)定、標準的過程方法。編制質(zhì)

28、量計劃通常采用流程圖、因果分析圖等方法對項目進行分析，確定需要監(jiān)控的關鍵元素，設置合理的見證點（W點）、停工待檢點（H點），并制定質(zhì)量標準：1.流程圖： 顯示系統(tǒng)的各種成分是如何相互關系的，幫助我們預測在何處可能發(fā)生各種質(zhì)量問題，并由此幫助開發(fā)處理他們的辦法。2.因果分析圖（也稱魚刺圖）如圖7所示：人員參考資料設備質(zhì)量問題環(huán)境方法對于本項目，編制質(zhì)量計劃時采用因果分析圖，描述相關的各種原因和子原因如何產(chǎn)生潛在問題或影響，將影響質(zhì)量問題的“人員、設備、參考資料、方法、環(huán)境”等各方面的原因進行細致的分解，方便地在質(zhì)量計劃中制定相應的預防措施。其次，質(zhì)量計劃中還必須確定有效的質(zhì)量管理體系，明確質(zhì)量監(jiān)

29、理人員對項目質(zhì)量負責和各級質(zhì)量管理人員的權限。戴明環(huán)（又名PDCA循環(huán)法）作為有效的管理工具在質(zhì)量管理中得到廣泛的應用，它采用計劃執(zhí)行檢查措施的質(zhì)量環(huán)，質(zhì)量計劃中必須將質(zhì)量環(huán)上各環(huán)節(jié)明確落實到各責任單位，才能保證質(zhì)量計劃的有效實施。7.2質(zhì)量保證活動質(zhì)量保證的只要活動包括過程評審和產(chǎn)品審計，過程評審和產(chǎn)品審計的目的是確保在項目進展過程中的各個階段和各個方面采取各項措施來保證和提高提交給用戶的產(chǎn)品質(zhì)量。每一次過程評審和產(chǎn)品審計都應填寫相應的報告或活動記錄。如下表9為質(zhì)量計劃標準項目具體描述計劃實際需求檢查52系統(tǒng)總體設計檢查21缺陷排除率（缺陷數(shù)/KLOC）詳細設計復核3227詳細設計檢查107

30、代碼復核6156代碼檢查2018編譯2115單元測試1514系統(tǒng)集成54系統(tǒng)測試55 表57.3產(chǎn)品審計產(chǎn)品審計由質(zhì)量保證人員來進行，檢查項目產(chǎn)品是否達到質(zhì)量目標。質(zhì)量保證人員可以有選擇性地審計項目生存期中創(chuàng)建工作產(chǎn)品，以驗證是否符合適當?shù)臉藴?，是否進行了質(zhì)量檢查，質(zhì)量審計一覽表見表10所示項審計對象審計階段參照的標準1軟件項目計劃計劃結束企業(yè)質(zhì)量體系2軟件配置管理計劃計劃結束企業(yè)質(zhì)量體系3軟件質(zhì)量保證計劃計劃結束企業(yè)質(zhì)量體系和項目規(guī)劃4總體設計文檔設計結束企業(yè)質(zhì)量體系和項目規(guī)劃5詳細設計文檔計劃結束企業(yè)質(zhì)量體系和項目規(guī)劃6數(shù)據(jù)庫表和編碼規(guī)范計劃結束企業(yè)質(zhì)量體系和項目規(guī)劃7產(chǎn)品代碼每個階段實施

31、結束企業(yè)質(zhì)量體系和項目規(guī)劃8測試報告測試結束企業(yè)質(zhì)量體系和項目規(guī)劃9系統(tǒng)計劃設計結束企業(yè)質(zhì)量體系和項目規(guī)劃10用戶文檔測試結束企業(yè)質(zhì)量體系和項目規(guī)劃 表67.4過程評審項目嚴格按照組織定義的軟件過程進行開發(fā)，過程評審的具體依據(jù)參照企業(yè)的過程規(guī)范，保證項目中的所有過程活動都在實施范圍內(nèi)。在每次評審之后，要對評審結果做出明確的決策并形成評審記錄。評審可采取文件傳閱、評審會等形式。7.5測試計劃1.建立每個測試階段的目標。2.確定沒項測試活動的進度和職責。3.確定工具、設備和測試庫的可用性。4.建立用于計劃和進行測試以及報告測試結果的規(guī)程和標準。5.制定衡量測試成功與完成的準則。第八部分 配置計劃項

32、目質(zhì)量計劃是指為確定項目應該達到的和如何達到這些項目質(zhì)量標準而做的項目質(zhì)量的計劃與安排。項目質(zhì)量計劃是的結果之一。它規(guī)定與項目相關的，如何滿足這些標準，由誰及何時應使用哪些程序和相關資源。 項目質(zhì)量計劃工作的成果：項目質(zhì)量計劃、項目質(zhì)量工作說明、質(zhì)量核檢清單、可用于其它管理的信息。8.1配置管理人員組成根據(jù)本項目計劃的角色分配，可以確定配置管理人員，配置管理人員的角色和職責見表11：角色人員職責、工作范圍 配置管理者 張三1.制定配置管理計劃2.創(chuàng)建和維護配置庫項目經(jīng)理李四1.審批配置管理計劃2.審批重大的變更項目組成員項目經(jīng)理：張曉質(zhì)量保證人員：王五配置管理者：吳天審批某些配置項或基線的變更

33、表78.2配置控制配置控制活動請求、評估、認可或拒絕、實現(xiàn)對基線CI的配置變更。變更包括錯誤的改正和可靠性增強。為變更過程所需的必須手續(xù)的復雜程度依靠在配置結構中變更對基線的影響。計劃必須描述在基線CI的變更控制影響。計劃必須定義下列的詳細步驟： 1.變更所需的標識和文檔； 2.變更需求的分析和評估； 3.需求的認可或否決； 4.變更的確認、執(zhí)行和發(fā)布；計劃必須標識用來追蹤和記錄每個變更的執(zhí)行序列的記錄。在處理原始需求的變更的每個不同必須被明確的記錄下來。8.3配置審核和審計配置審核決定事實上CI影響的所需的物理和功能的廣度。配置審閱時建立基線的管理工具。計劃必須為項目標識配置審核和審計。至少

34、，一個配置審核必須在CI發(fā)布前審核。 對每個計劃的配置審核和審計，計劃必須定義以下方面：1.它的目標； 2.處于審核和評審CI；3.審核和評審任務的時間表； 4.實施審核和評審的過程； 5.工作標題的參與者；6.為回顧或支持審核和評審需要用到的文件；7.記錄不足和報告糾正行動的過程；8.對認可之外的認可標準和特定行動。第九部分 風險計劃項目風險管理是指通過風險識別、風險分析和風險評價去認識項目的風險，并以此為基礎合理地使用各種風險應對措施、管理方法技術和手段，對項目的風險實行有效的控制，妥善的處理風險事件造成的不利后果，以最少的成本保證項目總體目標實現(xiàn)的管理工作。9.1風險識別,評估與風險規(guī)劃

35、（1）風險識別 風險識別是理解某特定項目有哪些可能令人滿意的結果的過程。就是采用系統(tǒng)化的方 法，識別某特定項目已知的和可預測的風險。（2）風險評估 風險評估是指，在發(fā)生之前或之后（但還沒有結束），該事件給人們的生活、生命、財產(chǎn)等各個方面造成的影響和損失的可能性進行量化評估的工作。即，就是量化某一事件或事物帶來的影響或損失的可能程度。（3）風險規(guī)劃 針對風險分析的結果，為提高實現(xiàn)項目目標的機會，降低風險的負面影響而制定風險應對策略和應對措施的過程，即制定一定的行動和策略來對付、減少、以至于消滅風險事件。通常采取的措施有：回避風險。轉(zhuǎn)移風險。3.損失控制。4.自留風險。9.2風險分析表根據(jù)風險識別

36、，風險評估，風險規(guī)劃可以制定了如下風險分析表排序輸入風險事件可能性影響風險值風險應對措施1最終用戶抵制該系統(tǒng)投資方可能會由于某個細節(jié)的問題對整個系統(tǒng)產(chǎn)生反感。 80%70%40%1.盡力滿足用戶提出的需求。2.界面盡可能的美觀，方便。3.需求分析階段派出專門的系統(tǒng)分析員去了解用戶的性格，愛好，工作習慣。2項目期間，投資方舉棋不定網(wǎng)上購物系統(tǒng)眾多，投資方瀏覽后可能會經(jīng)常要求更改需求 60%70%40%1.軟件詳細設計階段注意增加軟件的可重用性。提高復用水平。2.溝通和協(xié)調(diào)。3客戶的需求規(guī)格說明需求不明確，增加需求，導致需求蔓延，由于本軟件是不太了解計算機的用戶使用，變更需求可能性很大。 70%5

37、0%35%1.采取加班的方法。2.修改計劃去掉一些任務。3.與客戶商量延長一些時間。4.當出現(xiàn)影響重大的變更需求時與客戶協(xié)調(diào)，這個版本的不做改動，在下一個版本中進行功能的提升。4合同帶來的限制進度要求緊，合同金額有限。  30%50%15%可以請一些實習的學生做輔助工作,一來成本不高,二來可以加快進度。5交付期限緊縮。需方存在緊縮交付期限的可能。導致項目吃緊。 20%60%10%1.加班。2.臨時雇傭員工。3.調(diào)整結構。6歷史項目信息。開發(fā)人員的流動。 15%60%9%1.注意項目團隊的溝通，及時了解開發(fā)人員的動態(tài)。2.控制好項目過程中的文檔。3.從其他的項目組借調(diào)人員。4.從外部招

38、聘有過此類開發(fā)經(jīng)驗員。  7人員缺乏經(jīng)驗。由于本項目中的一些員工是剛剛招聘來的，可能會缺乏經(jīng)驗。 15% 30%10%1.采取一幫一，讓有經(jīng)驗的程序員帶著相對經(jīng)驗少的程序員進行開發(fā)。2.開發(fā)之前適當?shù)呐嘤枴?用戶數(shù)量超出計劃。由于該網(wǎng)站可能銷售商品特別，導致訪問激增。 20% 20%20%1.防患于未然，數(shù)據(jù)庫上采用數(shù)據(jù)池的技術在，增加并發(fā)訪問量。9技術達不到預期效果。可能有一些技術達不到預期的效果，不能使需方滿意。如訪問速度，一些特效等等。 10%10%10%1.找懂得這種技術的人幫忙。2.向老師請教。 表89.3風險應對措施（1）風險規(guī)避 風險規(guī)避是改變項目計劃來消除特定風險事件

39、的威脅。通常情況下我們可以采用多種方法來規(guī)避風險。例如，對于軟件項目開發(fā)過程中存在的技術風險，我們可以采用成熟的技術，團隊成員熟悉的技術或迭代式的開發(fā)過程等方法來規(guī)避風險;對于項目管理風險我們可以采用成熟的項目管理方法和策略來規(guī)避不成熟的項目管理帶來的風險;對于進度風險我們可以采用增量式的開發(fā)來規(guī)避項目或產(chǎn)品延遲上市的風險。對于軟件項目需求不確定的風險我們可以采用的原型法來規(guī)避風險。 （2）風險轉(zhuǎn)移 風險轉(zhuǎn)移是轉(zhuǎn)移風險的后果給第三方，通過合同的約定，由保證策略或者供應商擔保?？梢圆捎猛獍男问絹磙D(zhuǎn)移軟件開發(fā)的風險，例如發(fā)包方面對一個完全陌生領域的項目可以采用外包來完成，發(fā)包方必須有明確的合同約

40、定來保證承包方對軟件的質(zhì)量，進度以及維護的保證。否則風險轉(zhuǎn)移很難取得成功。（3）風險減輕 風險減輕是減少不利的風險事件的后果和可能性到一個可以接受的范圍。通常在項目的早期采取風險減輕策略可以收到更好的效果。例如，軟件開發(fā)過程中人員流失對于軟件項目的影響非常嚴重，我們可以通過完善工件，配備后備人員等方法來減輕人員流失帶來的影響。 （4）風險接受準備應對風險事件，包括積極的開發(fā)應急計劃，或者消極的接受風險的后果。 對于不可預見的風險，例如不可抗力;或者在風險規(guī)避，風險轉(zhuǎn)移或者風險減輕不可行，或者上述活動執(zhí)行成本超過接受風險的情況下采用。第十部分 團隊管理項目團隊是軟件項目項目中最重要的因素，成功的

41、團隊管理是軟件項目順利實施的保證。10.1軟件團隊管理概述軟件項目團隊管理工作結構如圖8所示軟件項目團隊管理團隊人員獲取輸入：1. 人員配置管理計劃2. 人員庫說明3. 招募規(guī)則工具和技術：1.談判2.預分配3.采購輸出：1.已分配的項目人員2.項目團隊名錄團隊建設輸入：1. 項目人員2. 項目計劃3.人員配置管理計劃4.執(zhí)行情況報告5.外部反饋措施：1.團隊建設活動2.一般管理技能3.獎勵和承認系統(tǒng)4.集中5.培訓輸出：1.團隊效能改進2.績效評估輸入團隊組織計劃輸入：1. 組織界面2. 人員配置要求3. 制約 方法和技術：1. 樣板2. 人力資源慣例3. 組織理論4. 項目干系人分析輸出：

42、1. 組織結構圖2. 角色和職責分配3. 人員配備管理計劃4. 支持細節(jié) 圖810.2IT軟件項目管理團隊1.IT軟件管理團隊是通過將不同的個體組織在一起，形成一個具有團隊精神的高效率隊伍來進行軟件項目的開發(fā)。2.軟件項目包括所有的項目干系人。項目干系人是指參與項目和受項目活動影響的人，包括：.項目發(fā)起人.資助者.供應商.項目組成員.協(xié)助人員.客戶.使用者.項目的反對人10.3溝通時間安排1. 小組交流（1）每周例會 每周例會時間由小組負責人自己擬定，因為要滿足各成員在場，所以時間彈性比較大，但確定每周例會時必須的。（2）每天交流 項目小組成員之間要每天進行交流，使用電話、QQ等進行討論有問題

43、及時解決。2. 團隊交流（1）每兩周例會（時間固定） 每兩周四下午14：30到17：30進行整個團隊的項目交流。（2）每天交流每天項目組成人員用電話或者QQ來進行討論，了解項目的進度，交流所遇到的困難并及時解決。第十一部分 項目度量軟件度量是對軟件開發(fā)項目、過程及其產(chǎn)品進行數(shù)據(jù)定義、收集以及分析的持續(xù)性定量化過程，目的在于對此加以理解、預測、評估、控制和改善。沒有軟件度量，就不能從軟件開發(fā)的暗箱中跳將出來。通過軟件度量可以改進軟件開發(fā)過程，促進項目成功，開發(fā)高質(zhì)量的軟件產(chǎn)品。度量取向是軟件開發(fā)諸多事項的橫斷面，包括顧客滿意度度量、質(zhì)量度量、項目度量、以及品牌資產(chǎn)度量、知識產(chǎn)權價值度量，等。度量

44、取向要依靠事實、數(shù)據(jù)、原理、法則；其方法是測試、審核、調(diào)查；其工具是統(tǒng)計、圖表、數(shù)字、模型；其標準是量化的指標。11.1度量指標度量指標如表9所示 度量指標分析方法決策準則里程碑進度偏差1.統(tǒng)計項目各個里程碑進度偏差值，畫出對應的控制圖如果里程碑進度相對偏差超出+/-5%，則項目經(jīng)理需要調(diào)查原因并采取措施。如果里程碑進度相對偏差超出+/-15%，進行正式的計劃變更項目生產(chǎn)率1.統(tǒng)計項目的總工作量和產(chǎn)品實際規(guī)模2.計算出項目生產(chǎn)率若項目生產(chǎn)率高于或者低于公司平均生產(chǎn)率10%，則要求評價項目，檢查項目的實際過程是否與組織的標準過程符合項目軟件開發(fā)生產(chǎn)率1.統(tǒng)計各項目每周的軟件開發(fā)生產(chǎn)率畫出趨勢圖如

45、果該生產(chǎn)率低于或高于公司平均水平10%時，需分析原因，采取相關措施調(diào)整項目按時完成率 項目按時完成率的控制圖對項目按時完成比率低于90%的時候，分析其原因，并制定整改措施。相對偏差低于等于10%為按時完成，反之為未按時完成。軟件產(chǎn)品的遺留缺陷密度1.統(tǒng)計軟件產(chǎn)品遺留缺陷和產(chǎn)品實際規(guī)模，使用柱狀圖表示軟件產(chǎn)品遺留缺陷密度軟件產(chǎn)品的遺留缺陷密度如果高于1，則必須調(diào)查其根本原因顧客滿意度1.根據(jù)顧客滿意度的分數(shù)，可以將產(chǎn)品或者服務的滿意度分為：不滿意、非常不滿意、非常滿意、較滿意、滿意，而后用柱形圖表示滿意度的情況顧客滿意度低于85，則必須調(diào)查其根本原因。需求穩(wěn)定度參見度量構造指南需求穩(wěn)定度低于90

46、%，則必須調(diào)查其根本原因任務工作量分布1.統(tǒng)計各類型任務工作量之和并使用餅圖顯示各類型任務工作量分布情況如果各類型任務工作量所占項目總工作量的比例比公司度量庫中值偏差10%，則必須調(diào)查其根本原因。階段工作量分布1.統(tǒng)計各階段任務工作量之和并使用餅圖顯示各階段任務工作量分布情況如果各階段任務工作量所占項目總工作量的比例比公司度量庫中值偏差10%，則必須調(diào)查其根本原因。 表 911.2 數(shù)據(jù)收集數(shù)據(jù)的收集如表10：目 標 度量 指標數(shù)據(jù)定義責任提高項目化產(chǎn)率功能點l時項目實施過程中計算出功能點數(shù)。功能點負責人用電子表格記錄數(shù)據(jù)。項目開發(fā)周期內(nèi)記錄工作時間量。開發(fā)人員隨時記錄數(shù)據(jù)。提高頂目質(zhì)量缺陷功

47、能點項目實施過程中計算出功能點數(shù)。功能點負責人用電子表格記錄數(shù)據(jù)。計算用戶使用三個月后的缺陷數(shù)。服務臺的人員在接到用戶的報告后采用缺陷跟蹤系統(tǒng)記錄數(shù)據(jù)。降低項目成本成本功能點項目實施過程中計算出功能點數(shù)。功能點負責人用電子表格記錄數(shù)據(jù)。按工作量計算出勞動成本。項目經(jīng)理在項目進行過程中記錄并計算。項目周期內(nèi)記錄非芳動成本。第十二部分 集成項目項目集成管理是為了實現(xiàn)項目目標，確保項目范圍內(nèi)的各項工作能夠順利協(xié)調(diào)地配合進行，消除項目管理中的局部性，平衡項目各個目標之間的沖突，保證項目過程各階段的正確實施，所開展的以整體思想為指導，從全局出發(fā)，以項目總體利益最大化為目標，以統(tǒng)一協(xié)調(diào)各方面管理為內(nèi)容進行

48、的全面管理的過程。它具有綜合性、全局性和內(nèi)外兼顧性的特征。集成項目計劃的完成是項目經(jīng)理完成項目計劃的標志。項目集成管理包括對計劃的集成管理和對項目跟蹤控制的集成管理，它保證項目各要素相互協(xié)調(diào)，在相互影響的項目目標和方案中做出權衡，以滿足或者超出項目干系人的需求和期望。12.1項目集成計劃 12.1.1項目概述網(wǎng)上購書的優(yōu)勢在于選擇面大、價格便宜、交易方便、節(jié)省時間和精力等。整個圖書市場一片繁榮，在這種情況下，網(wǎng)上書店的加入無疑將使得競爭更加激烈，但從另一個方面看，只有在這種激烈的競爭下，網(wǎng)上書店的優(yōu)勢才能得以體現(xiàn)。在中國，網(wǎng)上書店有發(fā)展的必要，也有發(fā)展的基礎，發(fā)展網(wǎng)上書店的各方面條件也日趨成熟

49、，但是還存在一些問題，只有把問題解決好了，才能保證網(wǎng)上書店的蓬勃發(fā)展。網(wǎng)上在線書店是以當前商務的網(wǎng)絡化、快速化實際需求為背景，實現(xiàn)圖書購買的方便、快捷、送貨上門等服務為前提綜合信息服務系統(tǒng)的設計；實現(xiàn)通過Internet互聯(lián)網(wǎng)對圖書購買的相關信息進行發(fā)布及圖書查詢、圖書介紹、圖書內(nèi)容瀏覽等功能。消費者通過網(wǎng)絡在線進行圖書的網(wǎng)上購物和網(wǎng)上支付等活動，這樣即方便了消費者，又減少了企業(yè)成本。倡導“用戶是伙伴，多為用戶著想”的新型客戶服務理念。因此，在網(wǎng)絡在線書店系統(tǒng)實現(xiàn)顯示其它用戶購買情況和瀏覽產(chǎn)品情況。這些新型客戶服務，具有與眾不同的優(yōu)勢和特點，將成為和用戶溝通、聯(lián)系、發(fā)展的有效的方法。12.1.2項目任務范圍在線書店管理項目需要完成的任務主要包括會員注冊、訂單管理、購物車、搜索、支付等基本功能。此外，本系統(tǒng)也將實現(xiàn)在線圖書銷售系統(tǒng)的后端管理，包括圖書的添加、訂單的處理等功能。本系統(tǒng)完全基于JSP技術，在系統(tǒng)的設計與開發(fā)過程中嚴格遵守軟件工程的規(guī)范，運用軟件設計模式，從而減少系統(tǒng)模塊間的偶合，力求做到系