學生成績管理系統(tǒng) 軟件項目管理大作業(yè).doc

學生成績管理系統(tǒng)項目管理文檔目錄一.合同管理11.1簽訂須知11.2 需方合同環(huán)境11.2.1合同準備11.2.2合同簽署11.2.3合同管理21.2.4合同終止過程21.3供方合同環(huán)境21.3.1 合同準備21.3.2 合同簽署21.3.3 合同管理31.3.4 合同終止過程31.4 內(nèi)部環(huán)境31.5 合同3二.生存期42.1 增量式模型4三.需求管理63.1 軟件需求管理過程63.1.1 軟件需求說明書63.1.2 可行性分析63.1.3 對功能的規(guī)定63.1.4 數(shù)據(jù)流圖7四.項目任務(wù)分解94.1 系統(tǒng)設(shè)計思想94.2 系統(tǒng)數(shù)據(jù)流程圖設(shè)計94.2.1 系統(tǒng)數(shù)據(jù)流程圖94.2.2 學生成績管理系統(tǒng)的描述104.3 模塊設(shè)計10五.項目估算105.1 聲明105.2 項目規(guī)模估算115.3 項目成本估算11六.進度計劃126.1 項目進度126.2 甘特圖13七.質(zhì)量計劃137.1 項目測試137.1.1 系統(tǒng)登錄測試137.1.2 學生成績信息的錄入測試137.1.3 學生成績的查詢測試147.1.4 確認測試147.1.5系統(tǒng)測試147.1.6 故障對策147.1.7 測試結(jié)果的評價147.2 系統(tǒng)維護147.3 SQA活動圖157.4 不符合性問題處理167.5記錄的收集、維護和保存17八項目風險管理178.1項目風險管理的目的178.2項目風險管理的組成188.3 風險的種類188.3.1資源風險188.3.2 業(yè)務(wù)風險198.3.3 技術(shù)風險198.3.4進度風險208.4 定義風險參數(shù)208.5 風險管理策略208.6 風險管理角色及職責208.7 學生成績管理項目中風險的識別208.8 風險的控制218.9 風險監(jiān)控2122一.合同管理1.1簽訂須知 1. 該合同為某某局合同范本，原則上不得改動，如一定要進行修改，請附上修改前后對比表。為列入修改前后對比表的修改部分，視為惡意篡改，我局不予以承認。1.2 需方合同環(huán)境1.2.1合同準備1.招標文件 河北省教育部需要引入一套“學生成績管理系統(tǒng)”應(yīng)用程序，現(xiàn)向個大學進行公開招標，歡迎有資格的投標大學參加。 一招標項目名稱：“學生成績管理系統(tǒng)”應(yīng)用軟件 二招標內(nèi)容：河北省學生“學生成績管理系統(tǒng)”應(yīng)用程序的設(shè)計，開發(fā)，安裝、調(diào)試、使用教學及相應(yīng)的后期維護升級。 三資質(zhì)要求：具有省級政府項目投標資格的企業(yè)或個人，詳細要求見投標須知（投標須知略）四投標、開標有關(guān)說明： 1.投標文件發(fā)售時間：2016年6月18日至2012年6月20日工作時間內(nèi) 2.投標文件發(fā)售地點：北京交通大學海濱學院 3.投標文件售價：￥10,000 （售后不退，不接受郵購） 4.投標地點：北京交通大學海濱學院報告廳 5.投標截止時間：2016年6月30日北京時間10:00時 6.開標時間：2016年7月1日北京時間14:00時 7.開標地點：北京交通大學海濱學院報告廳 五有關(guān)規(guī)定： 1.超過投標截止時間、不按規(guī)定密封的投標或不按招標文件規(guī)定提交有效足額投標保證金（以匯票、支票、現(xiàn)金支付）的投標，恕不接受。 2.提交投標保證金戶名：北京交通大學海濱學院財務(wù)處 3.開戶行：XX市渣打銀行XXX路分行 4.賬號：123456789012345 六聯(lián)絡(luò)： 北京交通大學海濱學院 詳細地址：略 聯(lián)系人：略 郵編：000000 電話：（02X）10000000 傳真：（02X）10000000 1.2.2合同簽署河北省教育部與北京交通大學海濱學院（本文假設(shè)北京交通大學海濱學院投標成功，該項目由北京交通大學海濱學院下發(fā)至北京交通大學海濱學院軟件學院承擔設(shè)計、開發(fā)、安裝調(diào)試等一系列工作，內(nèi)部部門人員配臵同軟件企業(yè)相同，借用大連理工大學之名而已。即北京交通大學海濱學院為供方）以河北省委省政府提出的合同草案為基礎(chǔ)，經(jīng)過確定談判日程、合同草案提交、合同條款協(xié)商、確定合同簽署文本、合同簽署文本審閱、合同簽署的流程完成合同簽署。最終形成合同簽署文本以及任務(wù)下達書。并將任務(wù)下達書分發(fā)給各中標單位（此處設(shè)該項目僅有北京交通大學海濱學院全權(quán)負責軟件的設(shè)計開發(fā)）1.2.3合同管理1.驗收過程 河北省教育部政府依據(jù)合同準備和合同簽署時確定的需求資料及合同文本制定驗收清單。對驗收清單評審后制定驗收計劃，并按驗收計劃執(zhí)行，得到驗收報告。對發(fā)現(xiàn)的問題制定驗收問題處理計劃，最終確認驗收報告。 2.違約事件處理過程 在合同執(zhí)行期內(nèi)，如果合同雙方河北省教育部政府或北京交通大學海濱學院有違約事件。需根據(jù)違約事件報告進行違約事件通告，確定處理方式后按計劃處理違約事件。之后形成違約事件處理報告。1.2.4合同終止過程河北省教育部政府與北京交通大學海濱學院根據(jù)合同及相關(guān)文檔，發(fā)布合同終止通知、項目執(zhí)行總結(jié)1.3供方合同環(huán)境1.3.1 合同準備1.項目分析 北京交通大學海濱學院根據(jù)招標書安排項目分析任務(wù)。經(jīng)過需求管理者確定、需求分析、需求分析評審、項目規(guī)模估算、項目風險分析、項目初步實施規(guī)劃、初步實施規(guī)劃評審，最終得到需求分析報告和項目初步規(guī)劃。 2.競標 北京交通大學海濱學院按照需求分析報告和項目規(guī)劃進行競標，通過技術(shù)能力要求確定、人力資源要求確定、實現(xiàn)環(huán)境要求確定、資金管理要求確定、能力判定、評估結(jié)果審評等評定，并進行需求成熟度評估、用戶支持保證評估、用戶資金保證評估、可行性分析、項目決策、編寫項目建議書等步驟，根據(jù)項目建議書參加競標。1.3.2 合同簽署河北省教育部政府與北京交通大學海濱學院（本文假設(shè)北京交通大學海濱學院投標成功，該項目由北京交通大學海濱學院下發(fā)至北京交通大學海濱學院軟件學院承擔設(shè)計、開發(fā)、安裝調(diào)試等一系列工作，內(nèi)部部門人員配臵同軟件企業(yè)相同，借用大連理工大學之名而已。即北京交通大學海濱學院為供方）以河北省委省政府提出的合同草案為基礎(chǔ)，經(jīng)過確定談判日程、合同草案提交、合同條款協(xié)商、確定合同簽署文本、合同簽署文本審閱、合同簽署的流程完成合同簽署。最終形成合同簽署文本以及任務(wù)下達書。并將任務(wù)下達書分發(fā)給各中標單位（此處設(shè)該項目僅有北京交通大學海濱學院全權(quán)負責軟件的設(shè)計開發(fā)）1.3.3 合同管理1.合同執(zhí)行跟蹤管理過程 北京交通大學海濱學院以項目計劃為基礎(chǔ)，進行項目計劃審批和合同執(zhí)行管理規(guī)劃。按計劃完成項目進展報告、合同責任落實、需求變更處理和產(chǎn)品驗收。 2.合同修改控制 如果需方即河北省省教育部提出變更請求，假設(shè)提出的是要求添加不用登錄網(wǎng)頁直接通過“學生成績管理系統(tǒng)”應(yīng)用程序即可向網(wǎng)內(nèi)用戶發(fā)送郵件，并根據(jù)不同層級用戶的權(quán)限顯示網(wǎng)內(nèi)在線用戶。則北京交通大學海濱學院需依據(jù)合同和變更請求進行變更評估，并提出合同修改建議，確定修改策略。對當前計劃進行調(diào)整，并需得出處理報告。 3.違約事件處理過程 在合同執(zhí)行期內(nèi)，如果合同雙方河北省教育政府或北京交通大學海濱學院有違約事件。需根據(jù)違約事件報告進行違約事件通告，確定處理方式后按計劃處理違約事件。之后形成違約事件處理報告。4.產(chǎn)品提交過程 在產(chǎn)品的開發(fā)測試結(jié)束后向河北省教育部提交產(chǎn)品，經(jīng)過審查后正式提交給河北省教育部政府。最終相方簽字認可，通知相關(guān)各方。 5.產(chǎn)品維護過程 根據(jù)合同中的維護需求，制定維護需求記錄。1.3.4 合同終止過程河北省教育部政府與北京交通大學海濱學院根據(jù)合同及相關(guān)文檔，發(fā)布合同終止通知、項目執(zhí)行總結(jié)1.4 內(nèi)部環(huán)境 北京交通大學海濱學院內(nèi)部確定任務(wù)范圍，使相關(guān)各方有效的配合。 1.5 合同 1.合同雙方 甲方：河北省教育部 乙方：北京交通大學海濱學院2.協(xié)議形式 協(xié)議形式：技術(shù)合同 3.供應(yīng)的商品和服務(wù) 供應(yīng)的軟件：乙方為甲方提供所需的“學生成績管理系統(tǒng)”應(yīng)用程序 提供的服務(wù)：乙方為甲方提供所需的日常維護和服務(wù)器管理。同時對甲方用戶提供使用教學。 提供的文檔：乙方在交付軟件時提供詳細的軟件規(guī)格說明書和使用文檔。 安裝服務(wù)： 乙方為甲方提供軟件的安裝。 公文處理： 乙方負責將甲方提供的公文資料加載入系統(tǒng)并進行分類 維護協(xié)議： 當甲方在使用該產(chǎn)品時，在正常操作的情況下出現(xiàn)BUG或系統(tǒng)錯誤，乙方免費為甲方提供修復(fù)服務(wù)以保障軟件的正常使用。當由于甲方的錯誤使用等非軟件原因?qū)е鲁霈F(xiàn)故障，乙方同樣提供修復(fù)服務(wù)。由于甲方擁有該軟件的源代碼所有權(quán)，因此甲方需要承擔部分維修和進一步開發(fā)的責任。當軟件需要新的功能拓展或改版升級時，由雙方共同協(xié)商決定。 4.軟件所有權(quán) 該軟件是由甲方向乙方定制，甲方擁有該軟件的版權(quán)，乙方不能將該軟件的任何版本賣個其他客戶。軟件提交時，項目源代碼的所有權(quán)自動移交到甲方，乙方不得擅自對源代碼進行修改。 5.環(huán)境 乙方為甲方安裝軟件和進行員工培訓時，需要由甲方提供住宿和膳食，乙方在規(guī)定時間內(nèi)完成任務(wù)。甲方要保證安裝軟件的硬件設(shè)備和合同初始規(guī)定一致，乙方只保證軟件和規(guī)定的硬件兼容。由任何一方的單方面原因?qū)е碌难悠诋a(chǎn)生的費用，由該方面支付。 6.客戶承諾 乙方開發(fā)軟件過程中，甲方通過人員協(xié)同乙方進行開發(fā)。該人員主要參與項目的規(guī)劃設(shè)計和需求分析，階段性驗收和總體測試。當項目出現(xiàn)需求變更時，對乙方進行詳細的闡述說明。乙方不負責這些人員提供食宿和聯(lián)系設(shè)備。 7.驗收規(guī)程 2016年7月25日，乙方為甲方安裝所需套數(shù)的軟件。7月25日至7月31日甲方代表對產(chǎn)品進行驗收測試，并根據(jù)需求在8月30日前對產(chǎn)品提出更正請求。測試通過后，雙方帶白哦進行軟件交付簽字。乙方對甲方進行軟件使用培訓。 8.標準 乙方在開發(fā)過程中必須遵守ISO 12207關(guān)于軟件生命周期和文檔的標準。 9.項目和質(zhì)量管理 甲乙雙方前四個月每月初進行一次進展會議，后三個月每兩周周末進行進展會議。會議內(nèi)容為乙方向甲方提供最新進度的掩飾和下一階段的工作安排和計劃。甲方根據(jù)演示提出相應(yīng)的整改意見，并對下一步工作進行提出意見和建議。 10.價格和付款方式 軟件總價為230W。合同簽訂后，甲方向乙方支付50萬元定金。項目的第三個月，乙方按計劃時間表完成需求分析、系統(tǒng)分析、設(shè)計和完成系統(tǒng)的基本框架后，甲方向乙方支付80萬元。該系統(tǒng)完成后，甲方進行驗收測試，在簽字驗收后完成后，甲方向乙方支付全款。11.其他法律要求 由任何一方的過失導致出現(xiàn)損失后的賠償由雙方協(xié)商決定。二.生存期2.1 增量式模型如圖1所示：理由如下： 1）學生成績管理系統(tǒng)的全部功能分成查詢功能和添加功能兩大類，因此可以先基于查詢功能做出一個最小的使用版本，再逐步添加其余的功能。這樣一來，用戶可以先試用最小版本的同時，提出更多明確的需求，這有助于下一階段的開發(fā)，大大減小了開發(fā)的風險。 2）在學生成績管理系統(tǒng)需求中，要求系統(tǒng)具有可擴充性。若使用增量模型，可以保證系統(tǒng)的可擴充性。用戶明確了需求的大部分，但也存在不很詳盡的地方。這樣只有等到一個可用的產(chǎn)品出來，通過客戶使用，然后進行評估，評估結(jié)果作為下一個增量的開發(fā)計劃，下一個增量發(fā)布一些新增的功能和特性，直至產(chǎn)生最終完善的產(chǎn)品。 3）“系統(tǒng)要求有可擴充性，可以再現(xiàn)有系統(tǒng)的基礎(chǔ)上，可以在增加其他功能模塊”-也說明用戶可能會增加新的需求。 4）應(yīng)該從最基礎(chǔ)的應(yīng)用做起，逐步擴充其應(yīng)用，所以選用增量模型來學生成績管理系統(tǒng)。 5）本項目具備增量式模型的其他特點：項目復(fù)雜程度為中等；預(yù)計開發(fā)軟件的成本為中等；產(chǎn)品和文檔的再使用率會很高；項目風險較低。生存期中各階段的定義如下：項目規(guī)劃階段 階段目標：根據(jù)合同和初步的需求分析確定項目的規(guī)模、時間計劃和資源需求。輸入：合同文本、SOW 過程：項目規(guī)劃，計劃確認 輸出：項目計劃 需求分析階段 階段目標：確定客戶的需求 輸入：項目計劃，SOW 過程：需求獲取，需求分析，需求控制 輸出：原型系統(tǒng)，需求規(guī)格 設(shè)計階段 階段目標：總體系統(tǒng)結(jié)構(gòu)設(shè)計 輸入：原型系統(tǒng)，需求規(guī)格 過程：總體設(shè)計 輸出：系統(tǒng)設(shè)計說明書、數(shù)據(jù)庫結(jié)構(gòu)定義 增量1實現(xiàn) 階段目標：實現(xiàn)系統(tǒng)的通用功能 輸入：系統(tǒng)設(shè)計說明書、數(shù)據(jù)庫結(jié)構(gòu)定義 過程：詳細設(shè)計，編碼，代碼走查，代碼評審，單元測試 輸出：詳細設(shè)計說明書，源代碼，可運行版本-1 增量2實現(xiàn) 階段目標：實現(xiàn)系統(tǒng)的管理員模塊管理功能 輸入：系統(tǒng)設(shè)計說明書、數(shù)據(jù)庫結(jié)構(gòu)定義 過程：詳細設(shè)計，編碼，代碼走查，代碼評審，單元測試 輸出：詳細設(shè)計說明書，源代碼，可運行版本-2 增量3實現(xiàn) 階段目標：實現(xiàn)系統(tǒng)教師模塊管理功能 輸入：系統(tǒng)設(shè)計說明書、數(shù)據(jù)庫結(jié)構(gòu)定義 過程：詳細設(shè)計，編碼，代碼走查，代碼評審，單元測試 輸出：詳細設(shè)計說明書，源代碼，可運行版本-3 增量4實現(xiàn) 階段目標：實現(xiàn)系統(tǒng)的學生模塊管理功能 輸入：系統(tǒng)設(shè)計說明書、數(shù)據(jù)庫結(jié)構(gòu)定義 過程：詳細設(shè)計，編碼，代碼走查，代碼評審，單元測試 輸出：詳細設(shè)計說明書，源代碼，可運行版本-4 增量5實現(xiàn) 階段目標：實現(xiàn)系統(tǒng)的學生自助預(yù)約功能 輸入：系統(tǒng)設(shè)計說明書、數(shù)據(jù)庫結(jié)構(gòu)定義 過程：詳細設(shè)計，編碼，代碼走查，代碼評審，單元測試 輸出：詳細設(shè)計說明書，源代碼，可運行版本-5 集成測試 階段目標：通過集成環(huán)境下的系統(tǒng)測試 輸入：測試計劃、測試案例 過程：集成測試，系統(tǒng)測試 輸出：系統(tǒng)軟件包，測試報告，產(chǎn)品說明書 產(chǎn)品提交三.需求管理3.1 軟件需求管理過程3.1.1 軟件需求說明書 隨著在校大學生人數(shù)的不斷增加，教務(wù)系統(tǒng)的數(shù)據(jù)量也不斷的上漲。學校工作繁雜、資料重多，雖然各類管理信息系統(tǒng)已進入高校，但還未普及，而對于學生成績管理來說，目前還沒有一套完整的、統(tǒng)一的系統(tǒng)。因此，開發(fā)一套適和大眾的、兼容性好的系統(tǒng)是很有必要的。3.1.2 可行性分析目前，隨著辦公信息化的開展，高校的擴招，新生入學以及期末考試結(jié)束后，學校都需要對一些繁瑣的流程進行管理，通過一個基于B/S架構(gòu)的管理系統(tǒng)，可以很好的將這一個過程進行化繁為簡。此項目具有普遍性，能夠應(yīng)用于很多學校。因此，該類型系統(tǒng)可以大量投入使用。3.1.3 對功能的規(guī)定 從程序的結(jié)構(gòu)中可以看出，學生的信息輸入輸出功能是由學生管理系統(tǒng)進行的。課程的輸入輸出是由課程管理系統(tǒng)進行的，而班級的信息流動則是班級管理系統(tǒng)進行的。學生成績管理信息系統(tǒng)的幾個基本功能： （1）學生的基本信息管理：學號、姓名、系別、班級等。 （2）課程的基本信息管理：課程號碼、課程名稱、任課教師、學分、學時、課程內(nèi)容簡介等。 （3）登陸管理：要求使用者提供合法的用戶名、密碼和相關(guān)權(quán)限。 （4）成績的錄入：由老師（管理員）錄入成績、要用到前面的學生信息、課程的信息等。 （5）成績查詢：學生進行成績查詢、要用到前面的學生信息、課程信息等。 （6）匯總功能：系統(tǒng)管理員、教務(wù)處對成績進行分類匯總，比較各個系院的成績，為制定以后教學管理計劃提供數(shù)據(jù)基礎(chǔ)。3.1.4 數(shù)據(jù)流圖 圖1.總體數(shù)據(jù)流圖 圖2. 學生信息數(shù)據(jù)流圖 圖3. 成績信息數(shù)據(jù)流圖圖4.信息操作數(shù)據(jù)流圖圖5.成績操作結(jié)果數(shù)據(jù)流四.項目任務(wù)分解4.1 系統(tǒng)設(shè)計思想采用現(xiàn)有的資源，先進的管理系統(tǒng)開發(fā)方案，充分利用學校現(xiàn)有的資源和財力、物力、提高系統(tǒng)開發(fā)的水平和應(yīng)用效果。系統(tǒng)就滿足學校的需求，例如學生信息的錄入、查詢、更新等。學生錄入與排名。系統(tǒng)就具備數(shù)據(jù)庫維護功能，及時根據(jù)用戶需求進行數(shù)據(jù)添加、刪除、修改等操作。4.2 系統(tǒng)數(shù)據(jù)流程圖設(shè)計 其中系統(tǒng)的主要業(yè)務(wù)流程圖如圖4-2所示。 圖4-2 系統(tǒng)流程此圖是顯示學生成績信息管理系統(tǒng)對信息管理的業(yè)務(wù)流程圖輸入信息處理的一個過程。4.2.1 系統(tǒng)數(shù)據(jù)流程圖頂層圖如圖4-2-1所示。圖4-2-1 數(shù)據(jù)流程-此圖是學生成績信息管理系統(tǒng)中管理員對系統(tǒng)中信息的處理過程的流程圖，通過此圖可以大概了解本系統(tǒng)對學生成績信的處理過程。信息管理圖如圖4-2-2所示。圖4-2-2 信息管理此圖是學生成績管理系統(tǒng)中對學生成績信的管理圖來對該系統(tǒng)中的信息管理情況。4.2.2 學生成績管理系統(tǒng)的描述1.“學生成績管理系統(tǒng)”主要分為瀏覽和后臺管理兩個子系統(tǒng)。 2.學生信息包括學生的學號、姓名、地址、電話等的信息。 3.教師信息包括教師的姓名、帳號、地址、電話等的信息。 4.教務(wù)員信息包括教務(wù)員的姓名、帳號、地址、電話等的信息。 5.成績信息包括課程代號、學號及成績。 6.課程信息包括課程名稱、任課教師、課程類別、學分、學期等信息。4.3 模塊設(shè)計1.用戶登錄模塊：填寫已分配的用戶名稱，填寫正確的密碼，進入主控制頁面。 2.顯示模塊：顯示要求的內(nèi)容。 3.查詢模塊：提供多種查詢條件，可按需要進行查詢。 4.錄入模塊：向數(shù)據(jù)庫中添加記錄。 5.修改模塊：可以找到指定信息并對其進行修改。 6.刪除模塊：找到要刪除的記錄，并將其刪除。五.項目估算5.1 聲明項目規(guī)模估算使用Delphi法進行估算，具體步驟如下：協(xié)調(diào)人向小組成員提供項目規(guī)格和估計表格；協(xié)調(diào)人召集小組討論與規(guī)模相關(guān)的因素；小組成員匿名填寫迭代表格；協(xié)調(diào)人整理出一個估計總結(jié)，以迭代表的形式返回各成員；協(xié)調(diào)人召集小組會，討論較大的估計差異；成員復(fù)查估計總結(jié)并在迭代表上提交另一個匿名估計；重復(fù)4-6， 直到達到一個最低和最高估計的一致。附Delphi法規(guī)模估計迭代表。Delphi法規(guī)模估計迭代表項目名稱：估計日期：估計者：估計輪次：結(jié)果：代碼行（LOC）周期（月）工作量（人月）費用（元）理由：5.2 項目規(guī)模估算經(jīng)過小組內(nèi)部討論得出項目規(guī)模估算如下：項目名稱：學生成績管理系統(tǒng)規(guī)模預(yù)測： 代碼行：15,000 LOC 周期：1 月 工作量：6 人月 費用：￥5530 元5.3 項目成本估算聲明 由于涉及到的小組成員沒有實際開發(fā)的經(jīng)驗，在薪酬結(jié)算方面沒有可供參照的標準，因此在這里采用統(tǒng)一的￥30.00 人天。成本估算任務(wù)名稱工時成本估算學生成績管理系統(tǒng)111 人天￥5530.00設(shè)備損耗31 工作日￥1000.00 需求討論2*2 人天￥120.00 軟件規(guī)劃6*2 人天￥360.00 需求開發(fā)6*4 人天￥720.00 設(shè)計4*4 人天￥480.00 實施6*13 人天￥2340.00 測試3*5 人天￥450.00 部署2*1 人天￥60.00六.進度計劃項目進度管理是指在項目實施過程中，對各階段的進展程度和項目最終完成的期限所進行的管理。是在規(guī)定的時間內(nèi)，擬定出合理且經(jīng)濟的進度計劃（包括多級管理的子計劃），在執(zhí)行該計劃的過程中，經(jīng)常要檢查實際進度是否按計劃要求進行，若出現(xiàn)偏差，便要及時找出原因，采取必要的補救措施或調(diào)整、修改原計劃，直至項目完成。其目的是保證項目能在滿足其時間約束條件的前提下實現(xiàn)其總體目標。 項目進度管理是根據(jù)工程項目的進度目標，編制經(jīng)濟合理的進度計劃，并據(jù)以檢查工程項目進度計劃的執(zhí)行情況，若發(fā)現(xiàn)實際執(zhí)行情況與計劃進度不一致，就及時分析原因，并采取必要的措施對原工程進度計劃進行調(diào)整或修正的過程。工程項目進度管理的目的就是為了實現(xiàn)最優(yōu)工期，多快好省地完成任務(wù)。 項目進度管理是項目管理的一個重要方面，它與項目投資管理、項目質(zhì)量管理等同為項目管理的重要組成部分。它是保證項目如期完成或合理安排資源供應(yīng)，節(jié)約工程成本的重要措施之一。6.1 項目進度任務(wù)名稱起止時間負責人資源工作量需求討論2016.6.15-2016.6.16張三2開發(fā)人員參與2人/天*2項目規(guī)劃2016.6.17-2016.6.18李四全體人員參與6人/天*2需求確定2016.6.19-2016.6.22王五全體人員參與6人/天*4設(shè)計2016.6.23-2016.6.26張三3開發(fā)人員參與3人/天*4項目實施2016.6.27-2016.7.9王五全體人員參與6人/天*13測試2016.7.10-2016.7.14李四3開發(fā)人員參與3人/天*5部署2016.7.15張三2開發(fā)人員參與2人/天*1交付2016.7.16王五6.2 甘特圖七.質(zhì)量計劃7.1 項目測試根據(jù)企業(yè)的質(zhì)量方針和質(zhì)量目標，結(jié)合本項目特點,制定項目的總體質(zhì)量目標：1） 基于需求的測試覆蓋率為100%；2） 軟件功能測試用例通過率不低于95；3） 每個階段評審中發(fā)現(xiàn)的問題都已經(jīng)解決或得到適當處理。4） 產(chǎn)品發(fā)布時不存在嚴重及其以上的缺陷。注：嚴重問題指導致系統(tǒng)或模塊不能正常工作的問題。7.1.1 系統(tǒng)登錄測試測試方法是，輸入不正確的賬號或密碼，選擇錯誤的角色，看能否登錄系統(tǒng)，確保系統(tǒng)的安全性。如表5-6-1所示。 表5-6-1 系統(tǒng)登錄測試測試事件測試效果輸入錯誤賬號登錄失敗輸入錯誤密碼登錄失敗選擇角色錯誤登錄失敗輸入正確賬號密碼選擇正確角色登錄成功測試結(jié)果：只有輸入正確賬號密碼和選擇正確角色才能登錄系統(tǒng)。7.1.2 學生成績信息的錄入測試 測試方法是，信息漏輸，看能否錄入成功，以確保學生信息的完整性。如表5-6-2 所示。 表5-6-2 學生成績信息的錄入測試測試事件測試效果學號漏輸錄入失敗姓名漏輸錄入失敗課程號漏輸錄入失敗課程名漏輸錄入失敗分數(shù)漏輸錄入失敗學分漏輸錄入失敗專業(yè)漏輸錄入失敗輸入信息完整錄入成功測試結(jié)果：輸入完整的信息，才能錄入成功。 7.1.3 學生成績的查詢測試 測試方法是輸入錯誤的學號，看能否查詢成績，以確保查詢的正確性。如表5-6-3所示。 表5-3 學生成績的查詢測試測試事件測試效果輸入錯誤學號查詢失敗輸入正確學號查詢成功測試結(jié)果：只有輸入正確的學號，才能查詢學生的成績。7.1.4 確認測試它是檢驗軟件的功能和性能及其他特性是否與用戶所合理期待的要求一致。它又可稱為有效性測試。它依據(jù)需求分析，使用黑盒法進行測試。7.1.5系統(tǒng)測試 它是將一個已經(jīng)過確認測試的軟件與計算機的硬件、外設(shè)、某些支持軟件、數(shù)據(jù)和人員等其他系統(tǒng)元素結(jié)合在一起，在實際運行環(huán)境下，進行 一系列的整體、有效性的測試。7.1.6 故障對策 測試過程中的故障推測： 測試中可能出現(xiàn)數(shù)據(jù)信息不能保存、 查詢信息時候出現(xiàn)死機的現(xiàn)象 措施： 1信息不能保存的原因可能是數(shù)據(jù)類型不一致 2查詢信息時候死機可能是查詢方式不正確7.1.7 測試結(jié)果的評價系統(tǒng)功能評價：此系統(tǒng)各模塊都能實現(xiàn)各自的功能，符合學校對系統(tǒng)的要求，系統(tǒng)運行穩(wěn)定。 結(jié)論：該系統(tǒng)可運用于實際當中。7.2 系統(tǒng)維護 我們所開發(fā)的學生成績管理系統(tǒng)力求適應(yīng)各大學院的成績管理，所以在開發(fā)上應(yīng)具有通用性以及可移植性，所以對系統(tǒng)的要求很高。因此系統(tǒng)在維護上應(yīng)做到可維護性強，在功能上具有可擴充性。為了便于功能擴充和修改，可對軟件進行周期性的維護，跟蹤軟件的質(zhì)量變化。為了改善軟件的可維護性，應(yīng)逐步提高軟件的技術(shù)和工具。軟件應(yīng)采用模塊化技術(shù)進行開發(fā)。模塊開發(fā)時候，各個模塊應(yīng)該并行開發(fā)，以提高軟件開發(fā)效率。系統(tǒng)在第一階段開發(fā)的時，備好軟件系統(tǒng)的文檔，以便二次開發(fā)時候便于修改，并做好文檔的及時更新。管理任務(wù)：其實測試工作和運營可以同時進行，運營主要看這個項目需要什么樣的運營方案進行支持。質(zhì)量保證任務(wù)：維護小組的任務(wù)一方面是保證對項目客戶的跟蹤服務(wù)，另一方面是確保該項目其它的開發(fā)人員從項目中盡快的解脫出來以便投入到下一個項目的開發(fā)中。所以通常項目維護小組成員主要由項目組的少部分開發(fā)人員承擔完成。他們不僅了解軟件的核心內(nèi)容，而且與客戶也不陌生，以便能夠以最快的速度修正錯誤。對于一般性的錯誤，如操作不當?shù)纫鸬膯栴}，全部由維護小組執(zhí)行完成，但需要用戶測試確認上線。如果較大的修改則需要走變更控制流程，用戶或者維護人員填寫變更申請，經(jīng)專家會議討論分析可行方案在由維護小組實施，通過測試后方可提交用戶。 維護小組的人員基本上是按項目跟進的。當一個項目剛剛交付用戶時，在維護小組有較多的人員進行跟進，隨軟件的穩(wěn)定，跟進的人逐步減少，并轉(zhuǎn)移到其它項目中去?；€產(chǎn)品：用戶手冊，操作手冊，項目開發(fā)總結(jié)，維護記錄。7.3 SQA活動圖7.4 不符合性問題處理1.將不符合性問題寫入審計報告，并與項目經(jīng)理一起協(xié)商加以解決（糾正措施、解決期限和復(fù)審時間），將不符合性問題、糾正措施等事宜寫入SQA審計報告，報告給項目經(jīng)理，并抄送SQA主管；2.SQA組針對上述不符合性問題進行復(fù)審，驗證不符合性問題是否得到糾正。如果所有問題已糾正，SQA組在審計報告上簽字確認，本過程結(jié)束；3.有些不符合性問題在不能和項目經(jīng)理一起協(xié)商加以解決的（特指不能與項目經(jīng)理形成一致的解決方案和期限的；或項目經(jīng)理不能提供相關(guān)證據(jù)證明SQA指出的不符合性問題是錯誤的），SQA組將不符合性問題及情況說明寫入SQA審計報告，報告給開發(fā)部部門主管，并抄送SQA主管和項目經(jīng)理；4.SQA組針對上報給部門主管的不符合性問題進行復(fù)審，驗證不符合性問題是否得到糾正。如果所有問題已糾正，SQA組在審計報告上簽字確認，本過程結(jié)束；如果仍有問題沒有解決，SQA組將沒有解決的不符合性問題及情況說明寫入SQA審計報告，上報給中央研究院院長，并抄送開發(fā)部部門主管、項目經(jīng)理和SQA主管；5.追蹤上報的不符合性問題，直至不符合性問題解決；6.SQA組根據(jù)不符合性問題的嚴重程度，有權(quán)直接將審計報告匯報給CTO；7.將審計報告納入項目SCM并提交到組織的過程數(shù)據(jù)庫中。7.5記錄的收集、維護和保存項目組應(yīng)當保留項目執(zhí)行過程中形成的各類文檔、各種記錄、各級周報、各級會議記錄、對于項目中問題的處理也需要形成記錄保存。每周由質(zhì)量保證人員根據(jù)任務(wù)清單的審計任務(wù)進行審計活動，并收集各活動的過程數(shù)據(jù)。八項目風險管理8.1項目風險管理的目的風險是指在項目進行過程中可能發(fā)生的事件，這些事件將會對項目按預(yù)期時間，資源和預(yù)算完成產(chǎn)生重大影響。風險管理的目標是在潛在問題發(fā)作以前就標志它們，這樣就可以在生命周期中可以適時地計劃和啟用風險處理活動。8.2項目風險管理的組成8.3 風險的種類分清風險的種類有利于更好的對項目進行風險管理。8.3.1資源風險1.組織對該項目是否有足夠的支持（包括管理人員、測試員、QA 和其他外部的相關(guān)各方）。 這是否是該組織嘗試過的最大項目。 軟件工程是否有明確定義的流程？需求記錄和管理。2.資金完成項目所需的資金是否到位。是否為培訓和指導分配了資金。 是否有預(yù)算限制使得系統(tǒng)必須以固定的成本交付，否則將被取消。 成本估算是否準確3.人員是否可以獲得足夠的項目工作人員。 他們是否具備合適的技能和經(jīng)驗。 他們以前是否在一起工作過。他們是否相信項目會成功。 是否可以找到用戶代表來擔任復(fù)審員。 是否可以找到領(lǐng)域?qū)＜摇?4.時間時間表制定得是否現(xiàn)實。 是否可以為了滿足時間表而對功能進行規(guī)模管理。 對交付日期的要求有多嚴格。 是否有時間“把工作做好”。8.3.2 業(yè)務(wù)風險如果競爭對手搶先將產(chǎn)品推向市場怎么辦。 如何確保有足夠的資金。系統(tǒng)的預(yù)計價值是否大于預(yù)計成本？（考慮貨幣的時間價值和資金的成本）。 如果無法同關(guān)鍵的供應(yīng)商簽定合同怎么辦。8.3.3 技術(shù)風險1.規(guī)模風險成功是否能夠被評測。是否有關(guān)于如何評測成功的協(xié)議。需求是否相當穩(wěn)定并得到了充分的了解。項目規(guī)模是固定不變還是在不斷擴展。項目開發(fā)的時間范圍是否太短、不夠靈活。2.技術(shù)風險技術(shù)是否已經(jīng)過證明。重復(fù)使用目標是否合理。工件必須要使用一次后才能被重復(fù)使用。 構(gòu)件可能要在若干次發(fā)布后才能變得穩(wěn)定，以致無需重大變更即可復(fù)用。 需求中的事務(wù)量是否合理。事務(wù)比率的估計值是否可靠？這些估計是否過于樂觀。數(shù)據(jù)量是否合理？當前可用的框架是否能夠保存這些數(shù)據(jù)，或者，如果需求使您相信工作站或部門系統(tǒng)將成為設(shè)計的一部分，那么是否能夠在這些地方合理地保存數(shù)據(jù)。 是否有特殊或苛刻的技術(shù)需求。成功是否依賴于新的或未經(jīng)試驗的產(chǎn)品、服務(wù)或技術(shù)？是否依賴于新的或未被證明的硬件、軟件或技術(shù)。對于與其他系統(tǒng)（包括企業(yè)以外的系統(tǒng)）的接口是否存在外部依賴性？是否存在必需的接口或必須創(chuàng)建它們 。是否存在極不靈活的可用性和安全性需求（例如“系統(tǒng)必須永遠不出現(xiàn)故障”）。系統(tǒng)的用戶是否對正在開發(fā)的系統(tǒng)類型沒有經(jīng)驗。 應(yīng)用程序的大小或復(fù)雜性，或者技術(shù)的新穎性是否導致了風險的增加。是否存在對國家語言支持的需求。是否可能設(shè)計、實施和運行該系統(tǒng)？某些系統(tǒng)只由于太大或太復(fù)雜而無法正常工作。 3.外部依賴性風險該項目是否依賴于其他（平行的）開發(fā)項目。成功是否依賴于市售產(chǎn)品或外部開發(fā)的構(gòu)件。成功是否依賴于開發(fā)工具（設(shè)計工具、編譯器等）和實施技術(shù)（操作系統(tǒng)、數(shù)據(jù)庫、進程間通信機制等）的成功集成。您是否有替代計劃，可以在沒有這些技術(shù)的情況下交付項目。8.3.4進度風險功能是否無限追加。計劃是否過于樂觀。是否缺乏計劃。在壓力下是否放棄計劃。是否追趕計劃。8.4 定義風險參數(shù)風險參數(shù)可用于評估、分類和劃分風險的優(yōu)先級；該項目將發(fā)生的可能性的等級劃分為：非常可能發(fā)生，可能發(fā)生，