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

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