旅游管理系統(tǒng)軟件項目管理大作業(yè)

1、目錄1. .合同書-22. 生存期33. 需求規(guī)格說明43.1 目標43.2 用戶類和特征43.3 運行環(huán)境43.4 功能需求53.4.1 確定執(zhí)行者53.4.2 確定用例53.4.3 用例文檔63.5 非功能需求83.6 故障處理84. 任務分解85. 工程估算95.1 直接本錢95.2 間接本錢125.3 估算的誤差126. 進度方案136.1 活動順序136.2 甘特圖147. 質量方案147.1 組織機構147.2 高層治理147.3 工程的質量保證人員147.4 質量目標157.5 質量策略168. 配置治理169. 風險治理179.1 風險識別與評估179.2 風險規(guī)劃179.3

2、風險分析表189.4 風險限制201.合同書合同名稱：旅游治理系統(tǒng)工程開發(fā)合同合同號：乙方：?？栖浖萍嫉刂罚荷虾ｊ懠易欤?10000聯(lián)系人：劉備：010：010甲方：北京交通大學海濱學院地址：北京交通大學海濱學院：061100聯(lián)系人：關羽：010：010根據?中華人民共和國合同法?的規(guī)定,合同雙方就旅游治理系統(tǒng)工程的技術開發(fā),經協(xié)商一致,簽定本合同.第一條、雙方的根本權利和根本義務甲方的權利和義務根據本合同工程的實際需要和乙方的要求提供協(xié)助,并提供有關的資料,報表及文檔等,甲方保證所提供的所有資料完整、真實、合法.按本合同約定支付軟件開發(fā)費用.甲方有權在軟件驗收之日起一年內,要求乙方對驗收完

3、畢的軟件模塊出現(xiàn)的非人為因素造成的錯誤及故障,進行免費維護.乙方的權利和義務根據甲方提供的材料按時完本錢合同規(guī)定的軟件開發(fā)工作.可以根據甲方的要求幫助甲方舉辦培訓和技術咨詢,其體的操作方式及費用雙方另行簽署協(xié)議確認.依合同收取軟件開發(fā)費用.乙方有義務在軟件驗收之日起一年內,對驗收完畢的軟件模塊出現(xiàn)的非人為因素造成的錯誤及故障,進行免費維護.第二條、標的技術的內容、范圍及要求：根據甲方的要求,乙方完成西安火車站售票系統(tǒng)的研制開發(fā).1 .根據甲方要求進行系統(tǒng)方案設計,要求建立B/S結構的,基于的Sqlserver數據庫、NT效勞器和J2EE技術的三層架構體系的綜合效勞軟件系統(tǒng).2 .配合甲方,在于

4、整體系統(tǒng)相融合的根底上,建立系統(tǒng)建立的軟硬件環(huán)境.第三條、應到達的技術指標和參數1 .系統(tǒng)應滿足并行登陸,并行查詢的速度要求.其中主要內容包括1保證1000人以上可以同時登陸系統(tǒng)2所有查詢速度應在10秒之內3保證數據的每周備份4工作日期間不能當機5出現(xiàn)問題應在10分鐘內恢復.2 .系統(tǒng)的主要功能是滿足雙方認可的需求規(guī)格,不可以隨意改動.第四條、研究開發(fā)方案1 .第一間斷：乙方在合同簽訂后15個工作日內,完成合同內容的系統(tǒng)設計方案.2 .第二階段：完成第一階段的系統(tǒng)設計方案之后,乙方于100個工作日內完成系統(tǒng)基本功能的開發(fā).3 .第三階段：完成第一和第二階段的任務之后,由甲方配合乙方于10個工作

5、日內完成系統(tǒng)的調試、集成.第五條、技術成果的歸屬和分享專利申請權：歸甲方所有；技術秘密的使用權、轉讓權：兩年內,使用權轉讓權歸甲方所有.第六條、驗收的標準和方式：研究開發(fā)所完成的技術成果,到達了本合同第二條所列技術指標,按國家標準,采用一定的方式驗收,由甲方出具技術工程驗收證實.第七條、風險的承當：在履行本合同的過程中,確因在現(xiàn)在水平和條件下難以克服的技術困難,導致研究開發(fā)局部或全部失敗所造成的損失,風險責任由甲方承當50%乙方承當50%本工程風險責任確認的方式：雙方協(xié)商.第八條、違約金和損失賠償額的計算：除不可抗力因素外指發(fā)生戰(zhàn)爭、地震、洪水、颶風或其他人力不能限制的不可抗力事件,甲乙雙方必

6、須遵守合同承諾,否那么視為違約并承當違約責任；1 .如果乙方不能按期完成軟件開發(fā)工作并交給甲方使用,乙方應向甲方支付延期違約金.每延遲一周,乙方向甲方支付合同總額0.5%的違約金,不滿一周按一周計算,但違約金總額不得超過合同總額的5%2 .如果甲方不能按期想甲方支付合同款項,甲方應向乙方支付延期違約金.每延遲一周,甲方向乙方支付合同總額0.5%的違約金,不滿一周按一周計算,但違約金總額不得超過合同總額的5%甲方蓋章：法人代表簽字：劉誰2021年6月6日乙方蓋章：法人代表簽字：張誰2021年6月6日2 .工程生存期此工程因面向的用戶群體相當廣泛,不同的用戶都有可能提出該系統(tǒng)針對某一類群體的改良意

7、見和要求.此工程在開發(fā)過程應滿足在開發(fā)結束后,可以在功能上進行擴充.工程內部意見不統(tǒng)一,可完成核心功能后推出開發(fā)初代版本,搜集用戶意見進行有效更改和相關功能的添加,因此選用增量式模型.增量式模型的特點如下：可以避免一次性投資太多帶來的風險,將主要的功能或者風險大的功能首先實現(xiàn),然后逐步完善,保證投入的有效性.可以更快地開發(fā)出可以操作的系統(tǒng).可以減少開發(fā)過程中用戶需求的變更.圖1.1圖1.13 .需求規(guī)格說明3.1 目標“旅游治理系統(tǒng)主要提供用戶信息、治理員信息、旅游信息等的治理與維護.3.2 用戶類和特征治理員、用戶.治理員需要進行用戶的創(chuàng)立、修改、刪除、備份等工作,具備計算機知識,如權限治理

8、等.用戶是普通用戶,具備一定的計算機操作知識即可.3.3 運行環(huán)境1硬件資源效勞器：工作站或小型機；網絡設備：網絡交換機,網卡,網線；打印機.(2)軟件資源效勞器端軟件選擇的具體說明：操作系統(tǒng)：windows2000或windowsXp數據庫：MicrosoftSQLServer2005JDK:jdk1.5應用效勞器：Apachetomcat5.5開發(fā)平臺：Eclipse3.2+MyEclipse5.5.1客戶端軟件選擇的具體說明：web瀏覽器.3.4 功能需求相應的需求有：(1)能夠存儲一定數量的用戶信息,并方便有效的進行相應的信息操作和治理,這主要包括：用戶根本信息的查詢、個人信息的修改.

9、(2)能夠對一定數量的旅游線路信息進行相應的信息操作和治理,這其中包括：旅游線路信息的查詢.(3)能夠提供應治理員對所有信息進行相應的信息操作和治理,這其中包括：治理員對所有用戶信息的添加、修改、刪除和備份.治理員對所有旅游路線信息的添加、修改、刪除和備份,批量打印.治理員對賬號,密碼信息的修改用戶對賬號,密碼信息的修改(4)數據保存：需要長期保存在數據庫的數據有：1 .用戶信息：用戶的根本信息；2 .旅游線路信息：旅游線路的根本信息；3 .用戶賬號信息：用戶賬號密碼信息；4 .治理員賬號信號：治理員賬號密碼信息(5)系統(tǒng)用戶：治理員、用戶.5 .用戶：可對本人住址信息、聯(lián)系方式、和根本信息進

10、行查詢.6 .可對本人聯(lián)系方式、住址信息、年齡、性別進行修改.7 .可對旅游路線信息就行查詢.=8 .治理員：可對本人的賬號密碼進行查詢.9 .可對旅游路線信息進行查詢、添加、修改.10 .可對所有用戶賬號信息進行添加、修改、刪除.11 .可對所有用戶根本信息進行添加、修改、刪除、備份.3.4.1 確定執(zhí)行者執(zhí)行者為用戶和治理員3.4.2 確定用例圖2.1是我們通過一定的調研和分析得到的“旅游治理系統(tǒng)的用例圖：圖2.13.4.3 用例文檔(1)用戶根本信息的維護用例用例名：用戶信息的維護參與執(zhí)行者：治理員/用戶入口條件：治理員/用戶已經登陸到該系統(tǒng)中.事件流：治理員將用戶根本信息(Excel文

11、件)導入本系統(tǒng)時,點擊提交按鈕,系統(tǒng)將用戶的根本信息從Excel中解析出后,保存到數據庫中,并創(chuàng)立相關用戶的系統(tǒng)默認賬戶信息；當有單個用戶根本信息入庫時,治理員在錄入頁面錄入用戶根本信息,點擊提交按鈕,系統(tǒng)將用戶根本信息保存到數據庫中；當某一用戶的根本信息需要修改時,治理員通過輸入查詢條件,搜索出該用戶,點擊“查看用戶信息,系統(tǒng)在不可編輯狀態(tài)顯示該用戶根本信息,點擊編輯按鈕,系統(tǒng)在可編輯狀態(tài)顯示該用戶的根本信息,治理員修改具體信息,點擊提交按鈕,系統(tǒng)將更新數據庫中該用戶的根本信息；當需要刪除一個或多個用戶信息時,治理員查找到需要刪除的用戶記錄,點擊刪除按鈕,系統(tǒng)提示“確定要刪除？對話框,治理員

12、選擇“是,系統(tǒng)將刪除數據庫中相應用戶的根本信息,以及刪除數據庫中相應的用戶賬戶記錄,反之,那么不進行任何操作；當需要備份一個或多個用戶信息時,治理員查詢到需要備份的用戶紀錄,點擊備份按鈕,系統(tǒng)提示“確定要備份這些記錄嗎？備份后將刪除這些記錄對話框,當治理員選擇“是,系統(tǒng)將這些數據保存到Excel文件,并刪除數據庫中相應的記錄.出口條件：系統(tǒng)將數據庫中的信息進行相應的操作：添加信息時,將新的用戶基本信息保存在數據庫中,并在用戶帳戶中添加相關用戶的默認帳戶信息；修改用戶根本信息時,將數據庫中該用戶的根本信息做相應的更新操作；刪除用戶根本信息時,那么刪除數據庫中的相應用戶記錄,并在用戶帳戶中刪除相應

13、用戶賬戶記錄；備份用戶根本信息時,那么將數據庫中的相應用戶記錄保存為Excel文件,并刪除數據庫中的相應用戶記錄.異常事件：無(2)旅游線路信息的維護用例用例名：旅游線路信息的維護參與執(zhí)行者：治理員入口條件：治理員已經登錄到該系統(tǒng)中.事件流：治理員將旅游線路信息(Excel文件)導入本系統(tǒng)時,點擊提交按鈕,系統(tǒng)將旅游線路信息從Excel中解析出后,保存到數據庫中；當有單個旅游線路根本信息入庫時,治理員在錄入頁面錄入旅游線路信息,點擊提交按鈕,系統(tǒng)將旅游線路根本信息保存到數據庫中；當某一旅游線路的根本信息需要修改,治理員通過輸入查詢條件,搜索出課程,點擊查看,系統(tǒng)在不可編輯狀態(tài)顯示該旅游線路根本

14、信息,點擊編輯按鈕,系統(tǒng)在可編輯狀態(tài)顯示該旅游線路的根本信息,治理員修改具體信息,點擊提交按鈕,系統(tǒng)將更新數據庫中該旅游線路的根本信息；當需要刪除一個或多個旅游線路信息時,治理員查找到需要刪除的課程記錄,點擊刪除按鈕,系統(tǒng)提示“確定要刪除？對話框,當治理員選擇“是",系統(tǒng)將刪除數據庫中相應旅游線路的根本信息,反之,那么不進行任何操作.出口條件：系統(tǒng)將數據庫中的旅游線路信息進行相應的操作：添加旅游線路信息時,將新的旅游線路信息保存在數據庫中；修改旅游線路信息時,將數據庫中該旅游線路信息做相應的更新操作；刪除旅游線路信息時,那么刪除數據庫中的相應課程記錄.異常事件：無(3)用戶根本信息的

15、查詢用例用例名：用戶根本信息的查詢參與執(zhí)行者：治理員和用戶入口條件：治理員和用戶已經登錄到系統(tǒng)中事件流：治理員通過交互界面輸入查詢條件搜索用戶信息紀錄,點擊“查看用戶信息,在不可編輯狀態(tài)下查看用戶根本信息；學生點擊個人根本信息,在不可編輯狀態(tài)下查看用戶根本信息.出口條件：系統(tǒng)顯示用戶信息(4)旅游線路根本信息的查詢用例用例名：旅游線路根本信息的查詢參與執(zhí)行者：治理員和用戶入口條件：治理員和用戶已經登錄到系統(tǒng)中.事件流：治理員登錄后顯示旅游線路列表點擊查看按鈕,在不可編輯狀態(tài)下查看課程信息；治理員通過交互界面輸入查詢條件搜索課程信息,點擊查看按鈕,在不可編輯狀態(tài)下查看旅游線路信息.出口條件：系統(tǒng)

16、顯示旅游線路信息.(5)賬號密碼信息治理用例用例名：賬號密碼信息治理參與執(zhí)行者：治理員和用戶入口條件：治理員和用戶已經登錄到系統(tǒng)中.事件流：用戶點擊“修改密碼,在口令修改頁面輸入原密碼、新密碼,并確認新密碼,點擊提交按鈕.出口條件：數據庫中的密碼被修改成最新的密碼.1.5 非功能需求1 .性能需求“旅游治理系統(tǒng)的使用者是治理員和用戶.對于治理員的治理工作,性能要求不是很嚴格,但需要方便查找、錄入、導出等操作.對于用戶的查看成績功能,對性能要求較高,一般需要到達并發(fā)數400以上.2 .平安性需求由于“旅游治理系統(tǒng)中的用戶資料是重要資料,所以要保證對于用戶資料的操作有較高的平安級別.對于整個系統(tǒng),

17、需要完整的權限限制,預防某些人惡意的攻擊系統(tǒng),修改原始記錄.同時對于數據庫中的數據需要定時備份,預防系統(tǒng)數據喪失.此外,系統(tǒng)要求用戶在登陸時需要身份驗證.1.6 故障處理在正常情況下,應不出錯.一旦發(fā)生意外,比方掉電、網絡不通等,應保證系統(tǒng)數據不會喪失.4 .任務分解本方案以工程初期估算為藍本,盡量實現(xiàn)所有成員在整個工程過程中都能得到相關技能的鍛煉,根據現(xiàn)有成員的特點,制定了任務分配.假設在方案執(zhí)行過程中遇到不可控困難,可向工程經理提出申請延期.工程開始前可根據個人意愿進行小幅度任務調整,申請人需填寫任務申請表.方案開始后除極特別因素外,不予重新調整.工程任務分解編碼表編碼任務名稱備注R000

18、000需求討論初步確定需求P000000軟件規(guī)劃制定工程方案P100000工程規(guī)劃P200000方案評審M000000需求開發(fā)細化需求M100000用戶界面設計M200000用戶需求評審M300000修改需求、界囿M400000編寫需求說明M500000需求驗證D000000設計完成工程設計工作D100000概要設計D200000婁k據庫ER圖編制、建庫D300000設計評審C000000實施實際開發(fā)C100000用戶治理C100100用戶注冊C100200用戶注銷C100300賬號登陸C100400個人信息治理C200000旅游線路信息治理C200100添加旅游線路信息C200200刪除旅游

19、線路信息C200300編輯旅游線路信息C200400查看旅游線路信息T000000測試對工程進行測試T100000功能模塊測試T200000系統(tǒng)集成測試T300000環(huán)境測設V000000部署發(fā)辦并交付5 .工程估算5.1 直接本錢本錢估算的方法有1.代碼行、功能點、對象點.2.類比(自頂向下)估算法.3.自下而上估算法.4.參數法估算法.5.專家估算法.在這個工程中我們主要采取功能點估算法,同時融合進入其他的估算方法進行驗證.用系統(tǒng)的功能數量來測量其規(guī)模,與實現(xiàn)產品所使用的語言和技術沒有關系的.根本公式FP=UFC*TCFUFC未調整功能點計數TCF技術復雜度因子TCF=0.65+0.01(

20、sum(Fi):Fi:0-5,TCF:0.65-1.35復雜度權重因素項簡單復雜外部輸入346外部輸出457外部查詢346外部文件5710內部文件71015本工程的功能點計算:功能點TCF-復雜度因子：項簡單復雜外部輸入5*33*45*6外部輸出7*46*51*7外部查詢5*31*43*6外部文件4*52*74*10內部文件10*71*101*15總計14870110UFC148+70+110=328技術復雜度因子F1可靠的備份和恢復F2數據通信F3分布式函數F4性能F5大量使用的配置F6聯(lián)機數據輸入F7操作簡單性F8在線升級F9復雜界面F10復雜數據處理F11重復使用性F12安裝簡易性F13

21、多重站點F14易于修改TCF=0.65+0.0.1*(5+4+3+2+1+5+3+2+2+3+5+4+3+3)=0.65+0.01*45=1.1.功能點計算：FP=UFC*TGFUFC=328TCF=1.1.FP=328*1.1=360.8人月數計算：在本工程中,根據以往的經驗使用經驗導出本錢模型面向FP驅動的中的kemerer模型來計算人月數.Kemerer模型E=60.62X7.728乂10-8FP3.帶入本工程的實際數據E=60.62*7.728*10-8*360.83=220、03人月直接本錢計算直接本錢組成：開發(fā)本錢,治理本錢,質量本錢.簡易估算：開發(fā)工作量規(guī)模：ScaleDev22

22、0.03單位：人月治理、質量工作量規(guī)模：ScaleMgn=a*ScaleDev=220.03*20%=44a:比例系數：例如：20%-25%直接本錢=模*人力本錢參數=264.03*0.15=40萬元人力本錢參數=1500/人月由于校內開發(fā),本錢比擬低5.2 間接本錢間接本錢=規(guī)模*人力本錢參數*間接本錢系數間接本錢系數=1.53本例中間接本錢=220.03*0.15*1.5=60萬元.估算本錢=直接本錢+間接本錢=40+60=100萬元5.3 估算的誤差由于根底數據缺乏,缺乏經驗的估算人員,簽約前后不連貫,低劣的推測技術,估算對需求的敏感性等一系列原因,可能會引起估算的誤差.對此工程的人月數

23、定義考慮誤差如下估算：220個人月+40-25+15人月：需求變更-15人月：晚上時間的利用+5人月：假期放假-10人月：實驗室采取獎勵舉措+20人月：放假最正確情況：95人月.方案情況：120人月.最壞情況：160人月.工程本錢估算聲明：由于涉及到的小組成員沒有實際開發(fā)的經驗,在薪酬結算方面沒有可供參照的標準,因此在這里采用統(tǒng)一的¥100.00人天.本錢估算任務名稱工時本錢估算旅游治理系統(tǒng)111人大¥19300.00設備損耗31工作日¥5000.00需求討論2*2人大¥400.00軟件規(guī)劃6*2人大¥1200.00需求開發(fā)6*4人大¥

24、;2400.00設計4*4人大¥800.00實施6*13人大¥7800.00測試3*5人大¥1500.00部署2*1人大¥200.006 .進度方案6.1 活動排序描述任務前導任務時間/天工程規(guī)劃A無18需求分析B無4總體設計CA,B18詳細設計DA,B4編他EC,D7測試FE16.2甘特圖7 .質量方案7.1 組織機構在工程實施期間成立工程質量保證組織,該組織由質量保證人員和工程經理組成,項目經理負責質量監(jiān)督工作及工程進展過程中各環(huán)節(jié)的質量把關,開發(fā)經理負責質量控制的工作,質量保證人員負責質量保證的工作.7.2 高層治理高層治理是公司負責質量的高級治理

25、,其質量責任如下：受理工程內不能解決的不符合問題,必要時與工程經理協(xié)調；負責聽取質量保證組的工作報告,評審質量保證活動和結果；參加有關質量保證過程改良的評審.7.3 工程的質量保證人員質量保證人員的質量責任如下：負責工程實施過程中對工程實施情況進行監(jiān)督,包括對工程實施過程和工作產品進行監(jiān)督檢查；實施工程組成員的質量保證培訓；制定質量保證方案；按方案實施審計活動,依照質量保證方案執(zhí)行評審/審計,并記錄執(zhí)行中發(fā)現(xiàn)的不符合項；對不符合問題提交不符合項報告,跟蹤并驗證糾正舉措的執(zhí)行情況；對工程內不能解決的不符合項問題向高層治理提交報告；向工程經理報告工程質量工作狀況和質量度量結果；定期向工程組報告質量

26、活動的結果；制訂質量保證的過程改良方案,記錄過程數據.7.4 質量目標根據企業(yè)的質量方針和質量目標,結合本工程特點,制定工程的總體質量目標:1） 基于需求的測試覆蓋率為100%2） ?軟件功能測試用例通過率不低于95%;3） ?每個階段評審中發(fā)現(xiàn)的問題都已經解決或得到適當處理.4） ?產品發(fā)布時不存在嚴重及其以上的缺陷.注：嚴重問題指導致系統(tǒng)或模塊不能正常工作的問題.結合以往的工程經驗和企業(yè)的質量相應標準,制定質量標準如下表：質量方案標準工程具體描述計戈11實際缺陷排除率缺陷數/頁需求檢查4系統(tǒng)總體設計檢查2缺陷排除率缺陷數/KLOC詳細設計復核30詳細設計檢查10代碼復核65代碼檢查20編譯

27、20單元測試15系統(tǒng)集成5系統(tǒng)測試57.5 質量策略為了保證提交用戶的產品是高質量,實施過程中采取的質量保證舉措包括：1將質量貫徹到日常的工程進展過程中；2應該特別注意工程工作產品質量的早期評審工作,無論是質量保證還是質量限制采取的策略都是早期預防和早期排除缺陷.8 .配置治理配置治理的目的是保證在整個軟件生命周期中軟件產品的完整性.軟件配置的根本目標包括:軟件配置治理的各項工作是有方案進行的.被選擇的工程產品得到識別,限制并且可以被相關人員獲取.已識別出的工程產品的更改得到限制.是相關組別和個人及時了解軟件基線的狀態(tài)和內容.配置治理的流程圖9 .風險治理工程風險治理是指通過風險識別、風險分析

28、和風險評價去熟悉工程的風險,并以此為根底合理地使用各種風險應對舉措、治理方法技術和手段,對工程的風險實行有效的限制,妥善的處理風險事件造成的不利后果,以最少的本錢保證工程總體目標實現(xiàn)的治理工作.9.1 風險識別與評估1風險識別是試圖通過系統(tǒng)化地確定對工程方案的威脅,識別和可預測的風險.2風險識別過程輸入-標識風險-根據一定標準對風險排序-制定風險表3根據“IT工程常常存在一些共同的風險源我們根據以往經驗制定了風險分析表.檢查表法是利用檢查表作為風險識別的工具,是根據風險要素建立軟件工程的風險條目列表,列表中列出所有與風險因素有關的提問,可以使管理者集中識別常見的類型中的和可預測的風險.9.2 風險規(guī)劃針對風險分析的結果,為提升實現(xiàn)工