旅游管理系统软件项目管理大作业

1、目录1. .合同书-22. 生存期33. 需求规格说明43.1 目标43.2 用户类和特征43.3 运行环境43.4 功能需求53.4.1 确定执行者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 风险规划179.3

2、风险分析表189.4 风险限制201.合同书合同名称：旅游治理系统工程开发合同合同号：乙方：海科软件科技地址：上海陆家嘴：510000联系人：刘备：010：010甲方：北京交通大学海滨学院地址：北京交通大学海滨学院：061100联系人：关羽：010：010根据?中华人民共和国合同法?的规定,合同双方就旅游治理系统工程的技术开发,经协商一致,签定本合同.第一条、双方的根本权利和根本义务甲方的权利和义务根据本合同工程的实际需要和乙方的要求提供协助,并提供有关的资料,报表及文档等,甲方保证所提供的所有资料完整、真实、合法.按本合同约定支付软件开发费用.甲方有权在软件验收之日起一年内,要求乙方对验收完

3、毕的软件模块出现的非人为因素造成的错误及故障,进行免费维护.乙方的权利和义务根据甲方提供的材料按时完本钱合同规定的软件开发工作.可以根据甲方的要求帮助甲方举办培训和技术咨询,其体的操作方式及费用双方另行签署协议确认.依合同收取软件开发费用.乙方有义务在软件验收之日起一年内,对验收完毕的软件模块出现的非人为因素造成的错误及故障,进行免费维护.第二条、标的技术的内容、范围及要求：根据甲方的要求,乙方完成西安火车站售票系统的研制开发.1 .根据甲方要求进行系统方案设计,要求建立B/S结构的,基于的Sqlserver数据库、NT效劳器和J2EE技术的三层架构体系的综合效劳软件系统.2 .配合甲方,在于

4、整体系统相融合的根底上,建立系统建立的软硬件环境.第三条、应到达的技术指标和参数1 .系统应满足并行登陆,并行查询的速度要求.其中主要内容包括1保证1000人以上可以同时登陆系统2所有查询速度应在10秒之内3保证数据的每周备份4工作日期间不能当机5出现问题应在10分钟内恢复.2 .系统的主要功能是满足双方认可的需求规格,不可以随意改动.第四条、研究开发方案1 .第一间断：乙方在合同签订后15个工作日内,完成合同内容的系统设计方案.2 .第二阶段：完成第一阶段的系统设计方案之后,乙方于100个工作日内完成系统基本功能的开发.3 .第三阶段：完成第一和第二阶段的任务之后,由甲方配合乙方于10个工作

5、日内完成系统的调试、集成.第五条、技术成果的归属和分享专利申请权：归甲方所有；技术秘密的使用权、转让权：两年内,使用权转让权归甲方所有.第六条、验收的标准和方式：研究开发所完成的技术成果,到达了本合同第二条所列技术指标,按国家标准,采用一定的方式验收,由甲方出具技术工程验收证实.第七条、风险的承当：在履行本合同的过程中,确因在现在水平和条件下难以克服的技术困难,导致研究开发局部或全部失败所造成的损失,风险责任由甲方承当50%乙方承当50%本工程风险责任确认的方式：双方协商.第八条、违约金和损失赔偿额的计算：除不可抗力因素外指发生战争、地震、洪水、飓风或其他人力不能限制的不可抗力事件,甲乙双方必

6、须遵守合同承诺,否那么视为违约并承当违约责任；1 .如果乙方不能按期完成软件开发工作并交给甲方使用,乙方应向甲方支付延期违约金.每延迟一周,乙方向甲方支付合同总额0.5%的违约金,不满一周按一周计算,但违约金总额不得超过合同总额的5%2 .如果甲方不能按期想甲方支付合同款项,甲方应向乙方支付延期违约金.每延迟一周,甲方向乙方支付合同总额0.5%的违约金,不满一周按一周计算,但违约金总额不得超过合同总额的5%甲方盖章：法人代表签字：刘谁2021年6月6日乙方盖章：法人代表签字：张谁2021年6月6日2 .工程生存期此工程因面向的用户群体相当广泛,不同的用户都有可能提出该系统针对某一类群体的改良意

7、见和要求.此工程在开发过程应满足在开发结束后,可以在功能上进行扩充.工程内部意见不统一,可完成核心功能后推出开发初代版本,搜集用户意见进行有效更改和相关功能的添加,因此选用增量式模型.增量式模型的特点如下：可以避免一次性投资太多带来的风险,将主要的功能或者风险大的功能首先实现,然后逐步完善,保证投入的有效性.可以更快地开发出可以操作的系统.可以减少开发过程中用户需求的变更.图1.1图1.13 .需求规格说明3.1 目标“旅游治理系统主要提供用户信息、治理员信息、旅游信息等的治理与维护.3.2 用户类和特征治理员、用户.治理员需要进行用户的创立、修改、删除、备份等工作,具备计算机知识,如权限治理

8、等.用户是普通用户,具备一定的计算机操作知识即可.3.3 运行环境1硬件资源效劳器：工作站或小型机；网络设备：网络交换机,网卡,网线；打印机.(2)软件资源效劳器端软件选择的具体说明：操作系统：windows2000或windowsXp数据库：MicrosoftSQLServer2005JDK:jdk1.5应用效劳器：Apachetomcat5.5开发平台：Eclipse3.2+MyEclipse5.5.1客户端软件选择的具体说明：web浏览器.3.4 功能需求相应的需求有：(1)能够存储一定数量的用户信息,并方便有效的进行相应的信息操作和治理,这主要包括：用户根本信息的查询、个人信息的修改.

9、(2)能够对一定数量的旅游线路信息进行相应的信息操作和治理,这其中包括：旅游线路信息的查询.(3)能够提供应治理员对所有信息进行相应的信息操作和治理,这其中包括：治理员对所有用户信息的添加、修改、删除和备份.治理员对所有旅游路线信息的添加、修改、删除和备份,批量打印.治理员对账号,密码信息的修改用户对账号,密码信息的修改(4)数据保存：需要长期保存在数据库的数据有：1 .用户信息：用户的根本信息；2 .旅游线路信息：旅游线路的根本信息；3 .用户账号信息：用户账号密码信息；4 .治理员账号信号：治理员账号密码信息(5)系统用户：治理员、用户.5 .用户：可对本人住址信息、联系方式、和根本信息进

10、行查询.6 .可对本人联系方式、住址信息、年龄、性别进行修改.7 .可对旅游路线信息就行查询.=8 .治理员：可对本人的账号密码进行查询.9 .可对旅游路线信息进行查询、添加、修改.10 .可对所有用户账号信息进行添加、修改、删除.11 .可对所有用户根本信息进行添加、修改、删除、备份.3.4.1 确定执行者执行者为用户和治理员3.4.2 确定用例图2.1是我们通过一定的调研和分析得到的“旅游治理系统的用例图：图2.13.4.3 用例文档(1)用户根本信息的维护用例用例名：用户信息的维护参与执行者：治理员/用户入口条件：治理员/用户已经登陆到该系统中.事件流：治理员将用户根本信息(Excel文

11、件)导入本系统时,点击提交按钮,系统将用户的根本信息从Excel中解析出后,保存到数据库中,并创立相关用户的系统默认账户信息；当有单个用户根本信息入库时,治理员在录入页面录入用户根本信息,点击提交按钮,系统将用户根本信息保存到数据库中；当某一用户的根本信息需要修改时,治理员通过输入查询条件,搜索出该用户,点击“查看用户信息,系统在不可编辑状态显示该用户根本信息,点击编辑按钮,系统在可编辑状态显示该用户的根本信息,治理员修改具体信息,点击提交按钮,系统将更新数据库中该用户的根本信息；当需要删除一个或多个用户信息时,治理员查找到需要删除的用户记录,点击删除按钮,系统提示“确定要删除？对话框,治理员

12、选择“是,系统将删除数据库中相应用户的根本信息,以及删除数据库中相应的用户账户记录,反之,那么不进行任何操作；当需要备份一个或多个用户信息时,治理员查询到需要备份的用户纪录,点击备份按钮,系统提示“确定要备份这些记录吗？备份后将删除这些记录对话框,当治理员选择“是,系统将这些数据保存到Excel文件,并删除数据库中相应的记录.出口条件：系统将数据库中的信息进行相应的操作：添加信息时,将新的用户基本信息保存在数据库中,并在用户帐户中添加相关用户的默认帐户信息；修改用户根本信息时,将数据库中该用户的根本信息做相应的更新操作；删除用户根本信息时,那么删除数据库中的相应用户记录,并在用户帐户中删除相应

13、用户账户记录；备份用户根本信息时,那么将数据库中的相应用户记录保存为Excel文件,并删除数据库中的相应用户记录.异常事件：无(2)旅游线路信息的维护用例用例名：旅游线路信息的维护参与执行者：治理员入口条件：治理员已经登录到该系统中.事件流：治理员将旅游线路信息(Excel文件)导入本系统时,点击提交按钮,系统将旅游线路信息从Excel中解析出后,保存到数据库中；当有单个旅游线路根本信息入库时,治理员在录入页面录入旅游线路信息,点击提交按钮,系统将旅游线路根本信息保存到数据库中；当某一旅游线路的根本信息需要修改,治理员通过输入查询条件,搜索出课程,点击查看,系统在不可编辑状态显示该旅游线路根本

14、信息,点击编辑按钮,系统在可编辑状态显示该旅游线路的根本信息,治理员修改具体信息,点击提交按钮,系统将更新数据库中该旅游线路的根本信息；当需要删除一个或多个旅游线路信息时,治理员查找到需要删除的课程记录,点击删除按钮,系统提示“确定要删除？对话框,当治理员选择“是",系统将删除数据库中相应旅游线路的根本信息,反之,那么不进行任何操作.出口条件：系统将数据库中的旅游线路信息进行相应的操作：添加旅游线路信息时,将新的旅游线路信息保存在数据库中；修改旅游线路信息时,将数据库中该旅游线路信息做相应的更新操作；删除旅游线路信息时,那么删除数据库中的相应课程记录.异常事件：无(3)用户根本信息的

15、查询用例用例名：用户根本信息的查询参与执行者：治理员和用户入口条件：治理员和用户已经登录到系统中事件流：治理员通过交互界面输入查询条件搜索用户信息纪录,点击“查看用户信息,在不可编辑状态下查看用户根本信息；学生点击个人根本信息,在不可编辑状态下查看用户根本信息.出口条件：系统显示用户信息(4)旅游线路根本信息的查询用例用例名：旅游线路根本信息的查询参与执行者：治理员和用户入口条件：治理员和用户已经登录到系统中.事件流：治理员登录后显示旅游线路列表点击查看按钮,在不可编辑状态下查看课程信息；治理员通过交互界面输入查询条件搜索课程信息,点击查看按钮,在不可编辑状态下查看旅游线路信息.出口条件：系统

16、显示旅游线路信息.(5)账号密码信息治理用例用例名：账号密码信息治理参与执行者：治理员和用户入口条件：治理员和用户已经登录到系统中.事件流：用户点击“修改密码,在口令修改页面输入原密码、新密码,并确认新密码,点击提交按钮.出口条件：数据库中的密码被修改成最新的密码.1.5 非功能需求1 .性能需求“旅游治理系统的使用者是治理员和用户.对于治理员的治理工作,性能要求不是很严格,但需要方便查找、录入、导出等操作.对于用户的查看成绩功能,对性能要求较高,一般需要到达并发数400以上.2 .平安性需求由于“旅游治理系统中的用户资料是重要资料,所以要保证对于用户资料的操作有较高的平安级别.对于整个系统,

17、需要完整的权限限制,预防某些人恶意的攻击系统,修改原始记录.同时对于数据库中的数据需要定时备份,预防系统数据丧失.此外,系统要求用户在登陆时需要身份验证.1.6 故障处理在正常情况下,应不出错.一旦发生意外,比方掉电、网络不通等,应保证系统数据不会丧失.4 .任务分解本方案以工程初期估算为蓝本,尽量实现所有成员在整个工程过程中都能得到相关技能的锻炼,根据现有成员的特点,制定了任务分配.假设在方案执行过程中遇到不可控困难,可向工程经理提出申请延期.工程开始前可根据个人意愿进行小幅度任务调整,申请人需填写任务申请表.方案开始后除极特别因素外,不予重新调整.工程任务分解编码表编码任务名称备注R000

18、000需求讨论初步确定需求P000000软件规划制定工程方案P100000工程规划P200000方案评审M000000需求开发细化需求M100000用户界面设计M200000用户需求评审M300000修改需求、界囿M400000编写需求说明M500000需求验证D000000设计完成工程设计工作D100000概要设计D200000娄k据库ER图编制、建库D300000设计评审C000000实施实际开发C100000用户治理C100100用户注册C100200用户注销C100300账号登陆C100400个人信息治理C200000旅游线路信息治理C200100添加旅游线路信息C200200删除旅游

19、线路信息C200300编辑旅游线路信息C200400查看旅游线路信息T000000测试对工程进行测试T100000功能模块测试T200000系统集成测试T300000环境测设V000000部署发办并交付5 .工程估算5.1 直接本钱本钱估算的方法有1.代码行、功能点、对象点.2.类比(自顶向下)估算法.3.自下而上估算法.4.参数法估算法.5.专家估算法.在这个工程中我们主要采取功能点估算法,同时融合进入其他的估算方法进行验证.用系统的功能数量来测量其规模,与实现产品所使用的语言和技术没有关系的.根本公式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联机数据输入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人月直接本钱计算直接本钱组成：开发本钱,治理本钱,质量本钱.简易估算：开发工作量规模：ScaleDev22

22、0.03单位：人月治理、质量工作量规模：ScaleMgn=a*ScaleDev=220.03*20%=44a:比例系数：例如：20%-25%直接本钱=模*人力本钱参数=264.03*0.15=40万元人力本钱参数=1500/人月由于校内开发,本钱比拟低5.2 间接本钱间接本钱=规模*人力本钱参数*间接本钱系数间接本钱系数=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人月.工程本钱估算声明：由于涉及到的小组成员没有实际开发的经验,在薪酬结算方面没有可供参照的标准,因此在这里采用统一的¥100.00人天.本钱估算任务名称工时本钱估算旅游治理系统111人大¥19300.00设备损耗31工作日¥5000.00需求讨论2*2人大¥400.00软件规划6*2人大¥1200.00需求开发6*4人大¥

24、;2400.00设计4*4人大¥800.00实施6*13人大¥7800.00测试3*5人大¥1500.00部署2*1人大¥200.006 .进度方案6.1 活动排序描述任务前导任务时间/天工程规划A无18需求分析B无4总体设计CA,B18详细设计DA,B4编他EC,D7测试FE16.2甘特图7 .质量方案7.1 组织机构在工程实施期间成立工程质量保证组织,该组织由质量保证人员和工程经理组成,项目经理负责质量监督工作及工程进展过程中各环节的质量把关,开发经理负责质量控制的工作,质量保证人员负责质量保证的工作.7.2 高层治理高层治理是公司负责质量的高级治理

25、,其质量责任如下：受理工程内不能解决的不符合问题,必要时与工程经理协调；负责听取质量保证组的工作报告,评审质量保证活动和结果；参加有关质量保证过程改良的评审.7.3 工程的质量保证人员质量保证人员的质量责任如下：负责工程实施过程中对工程实施情况进行监督,包括对工程实施过程和工作产品进行监督检查；实施工程组成员的质量保证培训；制定质量保证方案；按方案实施审计活动,依照质量保证方案执行评审/审计,并记录执行中发现的不符合项；对不符合问题提交不符合项报告,跟踪并验证纠正举措的执行情况；对工程内不能解决的不符合项问题向高层治理提交报告；向工程经理报告工程质量工作状况和质量度量结果；定期向工程组报告质量

26、活动的结果；制订质量保证的过程改良方案,记录过程数据.7.4 质量目标根据企业的质量方针和质量目标,结合本工程特点,制定工程的总体质量目标:1） 基于需求的测试覆盖率为100%2） ?软件功能测试用例通过率不低于95%;3） ?每个阶段评审中发现的问题都已经解决或得到适当处理.4） ?产品发布时不存在严重及其以上的缺陷.注：严重问题指导致系统或模块不能正常工作的问题.结合以往的工程经验和企业的质量相应标准,制定质量标准如下表：质量方案标准工程具体描述计戈11实际缺陷排除率缺陷数/页需求检查4系统总体设计检查2缺陷排除率缺陷数/KLOC详细设计复核30详细设计检查10代码复核65代码检查20编译

27、20单元测试15系统集成5系统测试57.5 质量策略为了保证提交用户的产品是高质量,实施过程中采取的质量保证举措包括：1将质量贯彻到日常的工程进展过程中；2应该特别注意工程工作产品质量的早期评审工作,无论是质量保证还是质量限制采取的策略都是早期预防和早期排除缺陷.8 .配置治理配置治理的目的是保证在整个软件生命周期中软件产品的完整性.软件配置的根本目标包括:软件配置治理的各项工作是有方案进行的.被选择的工程产品得到识别,限制并且可以被相关人员获取.已识别出的工程产品的更改得到限制.是相关组别和个人及时了解软件基线的状态和内容.配置治理的流程图9 .风险治理工程风险治理是指通过风险识别、风险分析

28、和风险评价去熟悉工程的风险,并以此为根底合理地使用各种风险应对举措、治理方法技术和手段,对工程的风险实行有效的限制,妥善的处理风险事件造成的不利后果,以最少的本钱保证工程总体目标实现的治理工作.9.1 风险识别与评估1风险识别是试图通过系统化地确定对工程方案的威胁,识别和可预测的风险.2风险识别过程输入-标识风险-根据一定标准对风险排序-制定风险表3根据“IT工程常常存在一些共同的风险源我们根据以往经验制定了风险分析表.检查表法是利用检查表作为风险识别的工具,是根据风险要素建立软件工程的风险条目列表,列表中列出所有与风险因素有关的提问,可以使管理者集中识别常见的类型中的和可预测的风险.9.2 风险规划针对风险分析的结果,为提升实现工