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

1、旅游管理系统软件项目管理大作业1 合同书-22 生存期-33 需求规格说明-43.1 目标-43.2 用户类和特征-43.3 运行环境-43.4 功能需求-5 3.4.1确定执行者-5 3.4.2 确定用例-5 3.4.3 用例文档-63.5 非功能需求-83.6 故障处理-84 任务分解-85 项目估算-95.1 直接成本-95.2 间接成本-125.3估算的误差-126 进度计划-136.1活动顺序-136.2甘特图-147 质量计划-147.1组织机构-14 7.2高层管理-14 7.3项目的质量保证人员-14 7.4质量目标-15 7.5 质量策略-168 配置管理-169 风险管理-

2、 179.1 风险识别与评估-179.2 风险规划-179.3风险分析表-189.4风险控制-201.合同书 合同名称：旅游管理系统项目开发合同合同号：甲方：北京交通大学海滨学院乙方：海科软件科技有限公司地址：北京交通大学海滨学院地址： 上海陆家嘴邮编：061100邮编：510000联系人：关羽联系人：刘备电话：（010）电话：（010）传真：（010）传真：（010）根据中华人民共和国合同法的规定，合同双方就旅游管理系统项目的技术开发，经协商一致，签定本合同。第一条、双方的基本权利和基本义务 甲方的权利和义务 根据本合同项目的实际需要和乙方的要求提供协助，并提供有关的资料，报表及文档等，甲方

3、保证所提供的所有资料完整、真实、合法。按本合同约定支付软件开发费用。甲方有权在软件验收之日起一年内，要求乙方对验收完毕的软件模块出现的非人为因素造成的错误及故障，进行免费维护。 乙方的权利和义务 按照甲方提供的材料按时完成本合同规定的软件开发工作。 可以根据甲方的要求帮助甲方举办培训和技术咨询，具体的操作方式及费用双方另行签署协议确认。依合同收取软件开发费用。 乙方有义务在软件验收之日起一年内，对验收完毕的软件模块出现的非人为因素造成的错误及故障，进行免费维护。 第二条、标的技术的内容、范围及要求： 根据甲方的要求，乙方完成西安火车站售票系统的研制开发。 1. 根据甲方要求进行系统方案设计，要

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

5、 第二阶段：完成第一阶段的系统设计方案之后，乙方于100个工作日内完成系统基本功能的开发。 3. 第三阶段：完成第一和第二阶段的任务之后，由甲方配合乙方于10个工作日内完成系统的调试、集成。第五条、技术成果的归属和分享专利申请权：归甲方所有； 技术秘密的使用权、转让权：两年内，使用权转让权归甲方所有。 第六条、验收的标准和方式： 研究开发所完成的技术成果，达到了本合同第二条所列技术指标，按国家标准，采用一定的方式验收，由甲方出具技术项目验收证明。第七条、风险的承担：在履行本合同的过程中，确因在现在水平和条件下难以克服的技术困难，导致研究开发部分或全部失败所造成的损失，风险责任由甲方承担50%，

6、乙方承担50%。 本项目风险责任确认的方式：双方协商。 第八条、违约金和损失赔偿额的计算： 除不可抗力因素外（指发生战争、地震、洪水、飓风或其他人力不能控制的不可抗力事件），甲乙双方必须遵守合同承诺，否则视为违约并承担违约责任； 1.如果乙方不能按期完成软件开发工作并交给甲方使用，乙方应向甲方支付延期违约金。每延迟一周，乙方向甲方支付合同总额0.5%的违约金，不满一周按一周计算，但违约金总额不得超过合同总额的5%。 2.如果甲方不能按期想甲方支付合同款项，甲方应向乙方支付延期违约金。每延迟一周，甲方向乙方支付合同总额0.5%的违约金，不满一周按一周计算，但违约金总额不得超过合同总额的5%。甲方

7、(盖章)： 法人代表(签字)：刘谁 2016年6月6日 乙方(盖章)： 法人代表(签字)：张谁 2016年6月6日 2.项目生存期此项目因面向的用户群体相当广泛，不同的用户都有可能提出该系统针对某一类群体的改进意见和要求。此项目在开发过程应满足在开发结束后，可以在功能上进行扩充。项目内部意见不统一，可完成核心功能后推出开发初代版本，搜集用户意见进行有效更改和相关功能的添加，因此选用增量式模型。增量式模型的特点如下：可以避免一次性投资太多带来的风险，将主要的功能或者风险大的功能首先实现，然后逐步完善，保证投入的有效性。可以更快地开发出可以操作的系统。可以减少开发过程中用户需求的变更。（图1.1）

8、 图1.13.需求规格说明3.1 目标“旅游管理系统”主要提供用户信息、管理员信息、旅游信息等的管理与维护。3.2用户类和特征 管理员、用户。管理员需要进行用户的创建、修改、删除、备份等工作，具备计算机知识，如权限管理等。用户是普通用户，具备一定的计算机操作知识即可。3.3运行环境 （1）硬件资源 服务器：工作站或小型机； 网络设备：网络交换机，网卡，网线； 打印机。 （2）软件资源 服务器端软件选择的具体说明： 操作系统：windows 2000 或windowsXp 数据库：Microsoft SQL Server 2005 JDK：jdk1.5 应用服务器：Apache tomcat5.

9、5 开发平台：Eclipse3.2 + MyEclipse 5.5.1 客户端软件选择的具体说明：web浏览器。3.4 功能需求相应的需求有：(1)能够存储一定数量的用户信息,并方便有效的进行相应的信息操作和管理，这主要包括： 用户基本信息的查询、个人信息的修改。(2)能够对一定数量的旅游线路信息进行相应的信息操作和管理，这其中包括： 旅游线路信息的查询。(3)能够提供给管理员对所有信息进行相应的信息操作和管理，这其中包括： 管理员对所有用户信息的添加、修改、删除和备份。 管理员对所有旅游路线信息的添加、修改、删除和备份，批量打印。 管理员对账号，密码信息的修改 用户对账号，密码信息的修改(4

10、)数据保存：需要长期保存在数据库的数据有：1. 用户信息：用户的基本信息；2. 旅游线路信息：旅游线路的基本信息； 3. 用户账号信息：用户账号密码信息；4. 管理员账号信号：管理员账号密码信息(5)系统用户：管理员、用户。5. 用户：可对本人住址信息、联系方式、和基本信息进行查询。6. 可对本人联系方式、住址信息、年龄、性别进行修改。7. 可对旅游路线信息就行查询。=8. 管理员：可对本人的账号密码进行查询。9. 可对旅游路线信息进行查询、添加、修改。10. 可对所有用户账号信息进行添加、修改、删除。11. 可对所有用户基本信息进行添加、修改、删除、备份。3.4.1确定执行者执行者为用户和管

11、理员3.4.2确定用例图2.1是我们通过一定的调研和分析得到的“旅游管理系统”的用例图：图2.13.4.3用例文档（1）用户基本信息的维护用例用例名：用户信息的维护参与执行者：管理员 / 用户入口条件：管理员 / 用户已经登陆到该系统中。事件流：管理员将用户基本信息（Excel文件）导入本系统时，点击提交按钮，系统将用户的基本信息从Excel中解析出后，保存到数据库中，并创建相关用户的系统默认账户信息；当有单个用户基本信息入库时，管理员在录入页面录入用户基本信息，点击提交按钮，系统将用户基本信息保存到数据库中；当某一用户的基本信息需要修改时，管理员通过输入查询条件，搜索出该用户，点击“查看用户

12、信息”，系统在不可编辑状态显示该用户基本信息，点击编辑按钮，系统在可编辑状态显示该用户的基本信息，管理员修改具体信息，点击提交按钮，系统将更新数据库中该用户的基本信息；当需要删除一个或多个用户信息时，管理员查找到需要删除的用户记录，点击删除按钮，系统提示“确定要删除？”对话框，管理员选择“是”，系统将删除数据库中相应用户的基本信息，以及删除数据库中相应的用户账户记录，反之，则不进行任何操作；当需要备份一个或多个用户信息时，管理员查询到需要备份的用户纪录，点击备份按钮，系统提示“确定要备份这些记录吗？备份后将删除这些记录”对话框，当管理员选择“是”，系统将这些数据保存到Excel文件，并删除数据

13、库中相应的记录。出口条件： 系统将数据库中的信息进行相应的操作：添加信息时，将新的用户基本信息保存在数据库中，并在用户帐户中添加相关用户的默认帐户信息；修改用户基本信息时，将数据库中该用户的基本信息做相应的更新操作；删除用户基本信息时，则删除数据库中的相应用户记录，并在用户帐户中删除相应用户账户记录；备份用户基本信息时，则将数据库中的相应用户记录保存为Excel文件，并删除数据库中的相应用户记录。异常事件：无 （2）旅游线路信息的维护用例用例名：旅游线路信息的维护参与执行者：管理员入口条件：管理员已经登录到该系统中。事件流：管理员将旅游线路信息（Excel文件）导入本系统时，点击提交按钮，系统

14、将旅游线路信息从Excel中解析出后，保存到数据库中；当有单个旅游线路基本信息入库时，管理员在录入页面录入旅游线路信息，点击提交按钮，系统将旅游线路基本信息保存到数据库中；当某一旅游线路的基本信息需要修改，管理员通过输入查询条件，搜索出课程，点击查看，系统在不可编辑状态显示该旅游线路基本信息，点击编辑按钮，系统在可编辑状态显示该旅游线路的基本信息，管理员修改具体信息，点击提交按钮，系统将更新数据库中该旅游线路的基本信息；当需要删除一个或多个旅游线路信息时，管理员查找到需要删除的课程记录，点击删除按钮，系统提示“确定要删除？”对话框，当管理员选择“是”，系统将删除数据库中相应旅游线路的基本信息，

15、反之，则不进行任何操作。出口条件： 系统将数据库中的旅游线路信息进行相应的操作：添加旅游线路信息时，将新的旅游线路信息保存在数据库中；修改旅游线路信息时，将数据库中该旅游线路信息做相应的更新操作；删除旅游线路信息时，则删除数据库中的相应课程记录。异常事件：无（3）用户基本信息的查询用例用例名：用户基本信息的查询参与执行者：管理员和用户入口条件：管理员和用户已经登录到系统中事件流：管理员通过交互界面输入查询条件搜索用户信息纪录，点击“查看用户信息”，在不可编辑状态下查看用户基本信息；学生点击个人基本信息，在不可编辑状态下查看用户基本信息。出口条件：系统显示用户信息（4）旅游线路基本信息的查询用例

16、用例名：旅游线路基本信息的查询参与执行者：管理员和用户入口条件：管理员和用户已经登录到系统中。事件流：管理员登录后显示旅游线路列表点击查看按钮，在不可编辑状态下查看课程信息；管理员通过交互界面输入查询条件搜索课程信息，点击查看按钮，在不可编辑状态下查看旅游线路信息。出口条件：系统显示旅游线路信息。（5）账号密码信息管理用例用例名：账号密码信息管理参与执行者：管理员和用户入口条件：管理员和用户已经登录到系统中。事件流：用户点击“修改密码”，在口令修改页面输入原密码、新密码，并确认新密码，点击提交按钮。出口条件：数据库中的密码被修改成最新的密码。3.5非功能需求1. 性能需求 “旅游管理系统”的使

17、用者是管理员和用户。对于管理员的管理工作，性能要求不是很严格，但需要方便查找、录入、导出等操作。对于用户的查看成绩功能，对性能要求较高，一般需要达到并发数400以上。2. 安全性需求 由于“旅游管理系统”中的用户资料是重要资料，所以要保证对于用户资料的操作有较高的安全级别。对于整个系统，需要完整的权限控制，防止某些人恶意的攻击系统，修改原始记录。同时对于数据库中的数据需要定时备份，防止系统数据丢失。此外，系统要求用户在登陆时需要身份验证。3.6故障处理 在正常情况下，应不出错。一旦发生意外，比如掉电、网络不通等，应保证系统数据不会丢失。4.任务分解本计划以项目初期估算为蓝本，尽量实现所有成员在

18、整个项目过程中都能得到相关技能的锻炼，根据现有成员的特点，制定了任务分配。若在计划执行过程中遇到不可控困难，可向项目经理提出申请延期。项目开始前可根据个人意愿进行小幅度任务调整，申请人需填写任务申请表。计划开始后除极特别因素外，不予重新调整。项目任务分解编码表编码任务名称备注R000 000需求讨论初步确定需求P000 000软件规划制定项目计划P100 000项目规划P200 000计划评审M000 000需求开发细化需求M100 000用户界面设计M200 000用户需求评审M300 000修改需求、界面M400 000编写需求说明M500 000需求验证D000 000设计完成项目设计工

19、作D100 000概要设计D200 000数据库ER图编制、建库D300 000设计评审C000 000实施实际开发C100 000用户管理C100 100用户注册C100 200用户注销C100 300账号登陆C100 400个人信息管理C200 000旅游线路信息管理C200 100添加旅游线路信息C200 200删除旅游线路信息C200 300编辑旅游线路信息C200 400查看旅游线路信息T000 000测试对项目进行测试T100 000功能模块测试T200 000系统集成测试T300 000环境测设V000 000部署发布并交付5.项目估算5.1 直接成本 成本估算的方法有1.代码行

20、、功能点、对象点 。2.类比 (自顶向下)估算法。3.自下而上估算法。4.参数法估算法。5.专家估算法。在这个项目中我们主要采取功能点估算法，同时融合进入其他的估算方法进行验证。用系统的功能数量来测量其规模，与实现产品所使用的语言和技术没有关系的。基本公式FP =UFC*TCFUFC：未调整功能点计数TCF：技术复杂度因子TCF=0.65+0.01(sum(Fi)： Fi:0-5,TCF:0.65-1.35复杂度权重因素项简单一般复杂外部输入346外部输出457外部查询346外部文件5710内部文件71015本项目的功能点计算：功能点项简单一般复杂外部输入5 * 33 * 45 * 6外部输出

21、7 * 46 * 51* 7外部查询5 * 31 * 43 * 6外部文件4 * 52 * 74 * 10内部文件10 * 71 * 101 * 15总计14870110UFC148 + 70 + 110 = 328TCF-技术复杂度因子：技术复杂度因子F1可靠的备份和恢复F2数据通信F3分布式函数F4性能F5大量使用的配置F6联机数据输入F7操作简单性F8在线升级F9复杂界面F10 复杂数据处理F11重复使用性F12安装简易性F13多重站点F14易于修改TCF = 0.65 + 0.0.1 * ( 5 + 4 + 3+2 + 1 5+2 2 + 3 +5+4+3+3) = 0.65 + 0.

22、01 * 45 = 1.1。 功能点计算：FP=UFC*TCF。UFC=328。TCF=1.1.FP=328*1.1 = 360.8人月数计算：在本项目中，根据以往的经验使用经验导出成本模型（面向FP驱动的 ）中的kemerer模型来计算人月数。Kemerer模型 E=60.627.72810-8 FP3 。带入本项目的实际数据 E = 60.62 * 7.728 *10-8 *360.83 = 220、03（人月）直接成本计算直接成本组成:开发成本,管理成本，质量成本。简易估算：开发（工作量）规模：Scale(Dev) 220.03(单位：人月) 管理、质量（工作量）规模： Scale(Mg

23、n)=a* Scale(Dev) = 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估算的误差由于基础数据不足，缺乏经验的估算人员，签约前后不连贯，低劣的推测技术，估算对需求的敏感性等一系列原因，可能会引起估算的误差。对此项目的人月数定义考虑误差如下估算：220个人月 +40 -25+15人月：需求变更-15人月：晚上时间的利用+5人月：假期放假-10人月：实验室采取奖励措施+20人月：放假最佳情况：95人月。计划情况：120人月。最坏情况：160人月。项目成本估算声明：由于涉及到的小组成员没有实际开发的经验，在薪酬结算方面没有可供参照的标准，因此在这里采用统一的￥100.00 人天。成本估算任务名称工时成本估