1、 HUBEI UNIVERSITY OF AUTOMOTIVE TECHNOLOGY 在線考試系統案例分析 目錄：1、導言32、項目概述33、項目任務范圍44、項目目標55、項目組織結構56、項目生存期57、時間計劃78、項目成本估算79、質量管理計劃710、配置管理計劃1211、項目風險計劃1712、度量計劃1813、項目溝通與評審20 1、 導言現在，計算機硬件技術的發展已經達到了相當高的水平。但是，遠程教育軟件的開發目前還處于起步階段，隨著這項技術的不斷深入發展，就要求有更好、更完善的軟件系統應用到遠程教育當中去，這就給軟件設計人員提出了更高的設計要求。 遠程教育包括很多環節，例如教學系

2、統、答疑系統和考試系統等等。其中很重要的一個環節就是在線考試系統，同時它也是最難實現的環節。在我國，雖然遠程教育已經蓬勃地發展起來，但是目前學校與社會上的各種考試大都采用傳統的考試方式，在此方式下，組織一次考試至少要經過五個步驟，即人工出題、考生考試、人工閱卷、成績評估和試卷分析。顯然，隨著考試類型的不斷增加及考試要求的不斷提高，教師的工作量將會越來越大，并且其工作將是一件十分煩瑣和非常容易出錯的事情，可以說傳統的考試方式已經不能適應現代考試的需要。隨著計算機應用的迅猛發展，網絡應用不斷擴大，如遠程教育和虛擬大學的出現等等，且這些應用正逐步深入到千家萬戶。人們迫切要求利用這些技術來進行在線考試

3、，以減輕教師的工作負擔及提高工作效率，與此同時也提高了考試的質量，從而使考試更趨于公證、客觀，更加激發學生的學習興趣。例如目前許多國際著名的計算機公司所舉辦的各種認證考試絕大部分采用這種方式。 在線考試是現階段研究開發的一個熱點。它是建立在國際互聯網上的應用系統，客戶端的配置可以極為簡單，使考試不受地域的局限。一個完備的在線考試系統可以使用戶在網上學習過后及時檢驗自己的學習效果，已發現自己的不足，使得學習效率得到很大提高。在線考試系統中題目的生成、試卷的提交、成績的批閱等都可以在網絡上自動完成。只要形成一套成熟的題庫就可以實現考試的自動化。這樣一來，教師所要做的只是精心設計題目、維護題庫，而不

4、是組織考試，從而大大減輕了教師的負擔，這表明其經濟性是相當可觀的。為了適應新形勢的發展，我進行了這一系統的初步設計工作，也可以說是做一個初步的探索，希望它能夠在各類考試中發揮高效、便捷的作用,把老師從繁重的工作中解脫出來！2、 概述在線考試系統主要功能包括學生管理、試卷管理、教師管理、學生在線考試等等。在線考試系統是對學校考試方式的優化和改進，是基于INTERNET環境的綜合考試系統，方便教師學生進行考試和查詢。目的是適應大環境的發展和方便信息的交流，充分利用學校資源，提高工作效率，系統具有標準化、分布式存儲和檢索、易用易維護開放等特點。3、項目任務范圍本文主要考慮的是高校內部的在線考試系統，

5、所以因其特殊性并不對所有人開放。系統主要用戶可以分為兩類：一種是學生用戶，一種是教師用戶。其中學生用戶能使用的功能有：在線考試，成績查詢，修改信息等。教師用戶使用的功能有：在線出題，修改成績，修改試題，成績查詢等任務分布見圖一 圖一、任務分布圖4、 項目目標 目前電化教育已經越來越普及，各地的學校紛紛建設自己的校園網，但是好多學校在投巨資建設校園網之后。未能高效的利用校園網的資源。在線考試系統提供了有效利用校園網，實現考試的無紙化。本軟件產品可以達到以下目標。 1、提高考試效率，減少紙張的使用 2、節省開支 3、考試過程的清晰化 4、符合學校的標準和規則5、項目組織結構由于該項目在實施過程中需

6、要涉及不同組織的各方面人員，而各組織之間的利益、任務和職責也不盡相同，因此明確定義項目組織結構和各自職責可保證項目的順利進行。市場部：負責項目的相關商務活動，負責與甲方交流商定。負責產品的說明。項目管理：負責項目的組織和規劃、負責項目計劃制定和維護軟件開發：負責項目的軟件開發、配合產品的驗收等相關活動質量保證：負責項目過程和產品規范的制定、過程評審和產品審計配置管理：負責項目的配置管理活動、負責軟件產品的提交角色映射表項目管理組軟件開發組質量保證組配置管理組負責人王紅張磊 王偉王明組成人11116、項目生存期根據該項目的特點并結合公司已有的軟件生存期模型定義，本項目生存期采用增量模型如圖：項目

7、規劃需求分析設計增量3增量1增量2集成測試產品提交生存期中的各階段定義如下：項目規劃階段階段目標：根據合同和初步的需求分析確定項目的規模、時間和資源需求。輸入：合同文本、SOW過程：項目規劃，計劃確認輸出：項目計劃需求分析階段階段目標：確定客戶需求輸入：項目計劃，SOW過程：需求獲取，需求分析輸出：原型系統，需求規格設計階段階段目標：總體系統結構設計輸入：原型系統，需求規格過程：總體設計輸出：系統設計說明書，數據庫結構定義增量1實現階段目標：實現系統的舊書回收功能輸入：系統設計說明書、數據庫定義結構過程：詳細設計，編碼，代碼走查，代碼評審，單元測試輸出：詳細設計說明書，源代碼，可運行版本-1增

8、量2實現階段目標：實現舊書再利用功能輸入：系統設計說明書、數據庫結構定義過程：詳細設計，編碼，代碼走查，代碼評審，單元測試輸出：詳細設計說明書，源代碼，可運行版本-27、時間計劃項目進度計劃甘特圖如圖所示見圖28、 項目成本估算現金流圖見圖39、 質量管理計劃文檔目的能夠保證完成在線考試系統質量文檔范圍【描述本質量管理計劃涵蓋的計劃范圍。本文檔將定義可交付物的質量標準和檢驗標準】。參考軟件向管理案例教程第二版韓萬江姜立新編著項目背景通過在線考試，以減輕教師的工作負擔及提高工作效率，與此同時也提高了考試的質量，從而使考試更趨于公證、客觀，更加激發學生的學習興趣。項目結構【描述項目質量管理團隊成員

9、組成，繪制組織結構圖】。【實施小項目時，項目經理負責保證質量。通常，可以指定一位質量監督員協助項目經理】?！緦嵤┐蟮捻椖繒r，可成立質量保證小組，指定人員擔任專職的質量經理。質量保證小組成員包括客戶和第三方人員】。質量管理【可參照下表，描述在項目各生命周期階段所需遞交的交付物】。序號交付物交付時間負責人1軟件規劃張磊2需求開發王明3設計王紅4通用功能張磊，王明5在線考試管理張才6成績查詢張才7試卷信息管理王紅，張磊【描述項目質量控制過程中采用的評審方式。如：定期質量評審是對項目前一階段的工作質量進行總結和評審，形成如下評審報告】：項目評審項目質量評審報告項目名稱 在線考試系統質量經理張磊時間20

10、16項目階段描述檢查內容檢查結果項目按規范流程執行情況合格項目文檔情況充分系統設計與需求的符合性符合技術實現方法的合理性、可行性、用戶認同性統一項目進度情況順利人員安排情況合理資源保證情況 優秀對外協作情況優秀問題列表序號問題描述帶來的風險及影響嚴重程度解決辦法、期限2不準確是項目不符合現實30%15不合格有漏洞有篡改入侵60%311不合格有漏洞有篡改入侵60%216不合格有漏洞有篡改入侵60%124不合格有漏洞有篡改入侵60%330不合格有漏洞有篡改入侵60%236不合格有漏洞有篡改入侵60%245不合格有漏洞有篡改入侵60%34其它意見和建議 無各質量檢查點【列舉項目的質量檢查點和初步時間

11、計劃，如】：檢查點日期項目計劃階段需求調研階段需求分析階段概要設計階段詳細設計階段編碼/單元測試階段集成測試階段系統測試階段工程實施階段參與人員和要求【無特殊要求，具體要求視情況而定】。項目計劃階段檢查清單檢查內容檢查時間完成情況負責人項目規模通過張磊時間計劃通過張磊項目需求通過王明需求調研階段檢查清單檢查內容檢查時間完成情況負責人資源需求通過張才計劃設置通過張才需求分析階段檢查清單檢查內容檢查時間完成情況負責人項目計劃通過張磊，王明sow通過王明設計階段檢查清單檢查內容檢查時間完成情況負責人總體實現通過張磊，王明通過張磊開發階段檢查清單檢查內容檢查時間完成情況負責人系統設計說明書王紅數據庫結

12、構定義王明集成測試階段檢查清單檢查內容檢查時間完成情況負責人測試計劃王偉測試案例王偉，張磊系統測試階段檢查清單檢查內容檢查時間完成情況負責人集成測試王偉系統測試王偉，張磊工程實施階段檢查清單檢查內容檢查時間完成情況負責人系統軟件包王紅驗收王磊質量檢查和確認技術審計產品一覽表項審計對象審計階段參照標準1軟件項目計劃計劃結束企業質量體系2軟件配置管理計劃計劃結束企業質量體系3軟件質量保證計劃計劃結束企業質量體系4總體設計文檔設計結束企業質量體系和項計劃5詳細設計文檔設計結束企業質量體系和項計劃6數據庫表和編碼規范設計結束企業質量體系和項計劃7產品代碼每個階段實施結束企業質量體系和項計劃8測試報告測

13、試結束企業質量體系和項計劃9測試計劃設計結束企業質量體系和項計劃10用戶文檔測試結束企業質量體系和項計劃10、配置管理計劃軟件項目配置管理計劃案例項目案例為在線考試系統，該項目的配置管理計劃如下：10.1引言主要功能：實現通過機房在線考試。其他功能：實現對考試試卷的管理，教師的管理，學生成績的管理，考試課程的管理，查看考試試卷等功能。10.2組織及職責配置管理的角色和職責見表1。表1：配置管理角色職責表角色人員職責和工作范圍配置管理者張磊（1） 制定配置管理計劃（2） 創建和維護配置庫SCCB負責人王明（1） 審批配置管理計劃（2） 審批重大的變更SCCB成員張磊（項目經理），王偉（質量保證人

14、員），王明（配置管理者）審批某些配置項或基線的變更10.3配置管理環境由于本項目屬于中小型項目，工期也不很長，而且項目組人員對Visual SourceSafe也比較熟悉，所以采用Visual SourceSafe作為配置管理工具。配置庫目錄結構表2：配置庫的目錄結構序號內容說明路徑1TCM技術合同管理$prj-SchoolTCM2RM需求管理$prj-SchoolRM3SPP軟件項目規劃$prj-SchoolSPP4SPTO軟件項目跟蹤與管理$prj-SchoolSPTO5SCM軟件配置管理$prj-SchoolSCM6SQA軟件質量保證$prj-SchoolSQA7SPE軟件產品工程設計$

15、prj-SchoolSPEDESIGN8源代碼$prj-SchoolSPESOURCE9目標代碼$prj-SchoolSPEBUILD10測試$prj-SchoolSPETEST11發布$prj-SchoolSPERELEASE用戶及權限表3：配置庫的用戶權限類別人員權限說明配置管理者王明負責項目配置管理，擁有所有資源權限項目經理張磊訪問、讀質量保證人員王偉訪問、讀開發人員張磊，王明，王偉等訪問、讀高層管理張磊訪問、讀10.4配置管理活動配置項標志主要配置項表4：配置項列表類型主要配置項標識符預計正式發表時間技術合同合同QTD-School-TCM-Contract-V1.02016-8-11

16、SOWQTD-School-TCM-SOW-V1.02016-8-11計劃項目計劃QTD-School-SPP-PP-V1.02016-8-11質量保證計劃QTD-School-SPP-SQA-V1.02016-7-24配置管理計劃QTD-School-SPP-SCM-V1.02016-7-24需求需求規格說明書QTD-School-RM-SRS-V1.02016-8-1用戶DEMOQTD-School-RM-Demo-V1.02016-8-1設計總體設計說明書QTD-School-Design-HL-V1.02016-8-2數據庫設計QTD-School-Design-DB-V1.02016

17、-8-2詳細設計說明書QTD-School-Design-LL-V1.02016-8-5設計術語及規范QTD-School-Design-STD-V1.02016-8-2編程源程序QTD-School-Code-ModuleName-V1.02016-8-2編碼規則QTD-School-Code-STD-V1.02016-8-2測試測試計劃QTD-School-Test-Plan-V1.02016-8-3測試用例QTD-School-Test-Case-V1.02016-8-3測試報告QTD-School-Test-Report-V1.02016-8-4提交運行產品QTD-School-Pro

18、duct-Exe-V1.02016-8-14驗收報告QTD-School-Product-Report-V1.02016-8-16用戶手冊QTD-School-Product-Manual-V1.02016-8-16項目基線在Visual SourceSafe中基線由LABLE標志，字母必須為大寫?；€管理由項目執行負責人確認、SCCB授權，由配置管理員執行。表5基線名稱/標識符基線包含的主要配置項預計建立時間需求需求規格說明書、用戶DEMO2016-7-20總體設計總體設計說明書、數據庫設計2016-7-20項目實現軟件源代碼、編碼規則2016-8-11系統測試測試用例、測試報告2016-8

19、-15配置項的版本管理配置項可能包含的分支從邏輯上可以劃分成4個不同功能的分支：主干分支、私有分支、小組分支、集成分支。讓它們分別對應4類工作空間。這四類工作空間（分支）由項目執行負責人統一管理，根據各開發階段的實際情況定制相應的版本選取規則，來保證開發活動的正常運作。在變更發生時，應及時做好基線的推進。對配置項的版本管理在不同分支具有不同的策略：（1） 主干分支系統默認自動建立的物理分支主干分支（/main）,基線均以LABLE方式出現在主干分支上。（2） 私有分支如果多個開發工程師維護一個配置項時建議建立自己的私有分支。配置管理員對其基本不與管理，如個別私有空間上的版本樹過于冗余，將對其冗

20、余版本進行限制。（3） 小組分支如果出現小組共同開發一配置項，該分支可視為項目組內部分組的私有空間，存放代碼開發過程中的版本分支，由項目組內部控制。（4） 集成分支集成測試時在主干分支的特定版本（由LABLE標志清晰）上建立集成分支，測試工作在集成分支上完成。私有分支和小組分支均為可選，必要時建立。命名規范本項目配置項命名規范由5個字段組成，從左到右依次為：公司、項目、類型、編號和版本號，如圖1所示。這些字段用一橫線（-）分隔。圖1：配置項命名規范變更管理變更管理的流程是：（1） 由請求者提交變更請求，SCCB會召開復審會議對變更請求進行復審，以確定該請求是否為有效請求。典型的變更請求管理有需

21、求變更管理、缺陷追蹤等。（2） 配置管理者收到基線修改請求后，在配置庫中生成與此配置項相關的波及關系表。（3） 配置管理者將基線波及關系表提交給SCCB，由SCCB確定是否需要修改，如果需要修改，SCCB應根據波及關系表，確定需要修改的具體文件，并在波及分析表中標志出來。（4） 配置管理者按照出庫程序從配置庫中取出需要修改的文件。（5） 項目人員將修改后的文件提交給配置管理者。（6） 配置管理者將修改后的配置項按入庫程序放入配置庫。（7） 配置管理者按SCCB標識出的修改文件，由波及關系表生成基線變更記錄表，并按入庫程序放入配置庫。配置狀態統計利用配置狀態統計，可以記錄和跟蹤配置項的改變。狀態

22、統計可用于評估項目風險，在開發過程中跟蹤更改，并且提供統計數據以確保所有必需的更改已被執行。為跟蹤工作產品基線，配置管理者需手機下列信息：基線類型工作產品名稱配置項名稱/標識符版本號更改日期/時間更改請求列表需要更改的配置項當前狀態當前狀態發生日期項目組每周提交配置項清單及其當前版本。配置管理人員每半個月提交變更請求的狀態統計。11、項目風險計劃下圖是本項目的風險計劃清單表1、 規模度量排序輸入風險事件可能性影響風險值風險應對措施1客戶的SOW需求不明確，增加需求，導致需求延遲%70%50%351、 采取加班的方法2、 修改計劃去掉一些任務3、 與客戶商量時間長一些2合同進度要求緊，合同金額有

23、限%30%50%15可以請一些實習的學生做一些輔助工作，可以加快進度3歷史項目信息開發人員對測試工作不重視%30%40%121、 強制性要求每段代碼保留測試單元，由SQA檢查2、 加入專業的測試人員4WBS供貨商、外包商的質量問題%20%50%10多選擇幾個可以作為備份的外包商和供應商5歷史項目信息開發人員的流動%15%60%91、 注意項目團隊的溝通，及時了解開發人員的動態2、 控制好項目過程中的文檔3、 從其他項目組借調人員4、 從外部招聘有過此類開發經驗的人員表1：項目規模的度量指標12.度量計劃根據企業的質量策略和項目的特點制定本項目度量計劃，主要目的是為本項目的控制提供實際數據，以及

24、將來其它項目提供估算依據，表1給出項目規模的度量指標，表2是項目的時間度量指標，表3是需求變更度量指標。任務名稱規模度量單位計劃實際需求規格說明書文本頁數 26 28總體設計說明書HLD頁數 13 15系統測試計劃文本頁數 20 21詳細設計說明書DLD頁數 38 40單元測試計劃文本頁數 1516 源程序LOC行數 1800 1900單元測試報告文本頁數 15 16系統測試報告文本頁數 16 18總計文本頁數 92 99 HLD頁數 13 15 DLD行數 38 40 LOC行數 1800