旅游管理程序 软件项目管理大作业.docx
《旅游管理程序 软件项目管理大作业.docx》由会员分享，可在线阅读，更多相关《旅游管理程序 软件项目管理大作业.docx（30页珍藏版）》请在冰豆网上搜索。
旅游管理程序软件项目管理大作业
1.合同管理
1.1合同简介
1.1.1项目名称
静乐旅游
1.1.2合同双方
甲方：
静乐旅游公司
乙方：
IT项目团队
1.1.3协议形式
技术合同
1.1.4供应条件和维护协议
供应的软件：
乙方为甲方提供所需的“静乐旅游”应用程序。
提供的服务：
乙方为甲方提供所需的日常维护和服务器管理，同时对甲方用户提供使用指导。
提供的文档：
乙方在交付软件时提供详细的软件规格说明书和使用文档。
安装服务：
乙方为甲方提供软件安装。
公文处理：
乙方负责将甲方提供的旅游项目输入系统并进行分类。
维护协议：
当甲方在使用该产品时，在正常操作的情况下出现BUG或系统错误，乙方免费为甲方提供修复服务以保障软件的正常使用。
当由于甲方的错误使用等非软件原因导致出现故障，乙方同样提供修复服务。
由于甲方拥有该软件的源代码所有权，因此甲方需要承担部分维修和进一步开发的责任。
当软件需要新的功能拓展或改版升级时，由双方共同协商决定。
1.2软件所有权
该软件是由甲方该软件是由甲方向乙方定制，甲方拥有该软件的版权，乙方不能将该软件的任何版本卖个其他客户。
软件提交时，项目源代码的所有权自动移交到甲方，乙方不得擅自对源代码进行修改。
1.3环境与标准
环境：
乙方为甲方安装软件和进行员工培训时，需要由甲方提供住宿和膳食，乙方在规定时间内完成任务。
甲方要保证安装软件的硬件设备和合同初始规定一致，乙方只保证软件和规定的硬件兼容。
由任何一方的单方面原因导致的延期产生的费用，由该方面支付。
标准：
乙方在开发过程中必须遵守ISO12207关于软件生命周期和文档的标准。
1.4客户承诺与验收规程
客户承诺：
乙方开发软件过程中，甲方通过人员协同乙方进行开发。
该人员主要参与项目的规划设计和需求分析，阶段性验收和总体测试。
当项目出现需求变更时，对乙方进行详细的阐述说明。
乙方不负责这些人员提供食宿和联系设备。
验收规程：
2016年6月24日，乙方为甲方安装所需的软件。
6月25日至6月31日甲方代表对产品进行验收测试，并根据需求在6月30日前对商品提出更正请求。
测试通过后，双方进行软件交付签字。
乙方对甲方进行软件使用培训。
1.5项目和质量管理
甲乙双方前四个月每月初进行一次进展会议，后三个月每两周周末进行进展会议。
会议内容为乙方向甲方提供最新进度的掩饰和下一阶段的工作安排和计划。
甲方根据演示提出相应的整改意见，并对下一步工作进行提出意见和建议。
1.6时间表
详细时间表见项目进度。
此处略。
1.7价格和付款方式
软件总价为150万元整。
合同签订后，甲方向乙方支付50万元定金。
项目的第三个月，乙方按计划时间表完成需求分析、系统分析、设计和完成系统的基本框架后，甲方向乙方支付50万元。
该系统完成后，甲方进行验收测试，在签字验收完成后，甲方向乙方支付全款。
1.8其他法律要求及违约处理
由任何一方的过失导致出现损失后的赔偿由双方协商决定。
甲方法人代表：
胡文静
乙方法人代表：
岚羽昕
签约地点：
静乐旅游公司项目管理主任办公室
有效期限：
2015年—2018年6月26号
2.项目生存期
确定该项目的生存期模型按如下步骤进行分析：
评审、分析项目的特性；选择适合项目的生存期模型；标识生存期模型与项目不一致地方,并进行裁减。
“静乐旅游”应用程序涉及到用户的隐私安全，因此很强调产品的性能和安全性。
需保证产品能保持稳定运行，不会以为一定数量的用户同时登录注册等操作时挂机，以致宝贵的消息或操作无法及时运行。
总而言之该项目的性能安全性为主，可操作性次之，界面美观度最末。
虽然项目的需求可能会因领导“挑剔”的口味而一再改变，不过大体的需求是明确的。
而且又考虑到项目安全性能的首要要求，以V模型为基础的生存期最为合适。
同时参杂增量模型生存期的一些特点以应对可能会随时添加的功能需求。
项目生存期模型如下：
该生存期模型将V模型除最后的项目规划和验收测试以外的过程做一复制，套用增量模型在首先完成基本功能的基础上增加功能。
3.需求管理
3.1软件需求管理过程
静乐旅游公司提出需求如下：
设计开发、安装调试并后期满足需求的“静乐旅游”应用程序。
需要该程序为桌面应用程序，进入程序后需要弹出旅游介绍界面，该旅游介绍界面需与计算机自身系统分离，不得覆盖，具有独立窗口。
该系统实现了管理员通过对景点信息、订票信息、酒店信息、保险信息、会员信息维护，实现了会员在线预订景区景点旅游的功能。
其模块介绍如下：
后台：
后台是整个信息系统中最重要复杂的部分。
管理员通过此处对网站内容进行管理.后台管理共分为景点管理、订票管理、酒店管理、保险管理、会员管理、系统管理。
1.景点管理
对景点信息进行添加、修改、删除和查询操作；对会员的景点订单信息进行确认。
2.订票管理
添加新的航向信息，修改、删除和查询票务信息操作；对会员的票务订单信息进行确认。
3.酒店管理
添加新的酒店信息，修改、删除和查询酒店信息操作；对会员的酒店订单信息进行确认。
4.保险管理
添加新的保险信息，修改、删除和查询保险信息操作；对会员的保险订单信息进行确认。
5.会员管理
添加新的会员信息，修改、删除和查询会员信息操作。
6.系统管理
可以通过链接进入后台主页、前台主页，修改密码以及退出系统操作。
综上所述，系统后台的功能需求可以通过图3.1简要表示。
图3.1系统后台的功能需求
前台：
前台部分就是用户浏览、选择景点的地方，需根据所需旅游线路安排布局，照顾用户浏览习惯，简化流程，使会员能迅速找到旅游景区景点，真正做到“简洁高效流畅”的环境。
1.注册会员
用户可以预定旅游景区景点信息,但是用户必须通过注册成为会员才具有这些权限。
2.修改用户信息
会员可以对自己的信息进行修改。
3.收藏夹
会员可以将中意的旅游景区景点信息放入收藏夹，并对该信息进行删除或生成订单操作。
4.我的订单
可以查看生成旅游景区景点的订单信息，并对已经确认的订单信息进行相应的明细信息的酒店选择，订票、保险的购买等。
5.景区景点
用户可以通过选择景点城市查看网站中的景区景点信息。
6.周边酒店
用户可以通过输入城市、价格或名称以及选择星级查询相应的酒店信息。
7.票务信息
用户可以通过输入出发地或目的地以及选择类型查询相应的票务信息。
8.保险信息
用户可以通过输入名称或选择类型查询相应的保险信息。
综上所述，系统的前台功能需求可以通过图3.2简要表示。
图3.2系统前台的功能需求
3.2需求规格
3.2.1需求规格说明书（简略版）
系统定义：
“静乐旅游”应用程序
应用环境：
Windows2000；WindowsXP；WindowsVista；Windows7；LINUX；IOSetc.
功能规格：
后台（景点管理、订票管理、酒店管理、保险管理、会员管理、系统管理）
前台（注册会员、修改用户信息、收藏夹、我的订单、景区景点、周边酒店、票务信息、保险信息）
性能需求：
保证用户同时登录服务器时也不会因处理的信息量过大大而导致系统瘫痪。
另必须保证系统的安全性，可以禁得住一般的黑客袭击和内部作假。
对账户有足够的保护措施以防账户被盗。
操作简单明了，提示明显，界面美观且生动。
现实约束：
景点管理、订票管理、酒店管理、保险管理、会员管理、系统管理、注册会员、修改用户信息、收藏夹、我的订单、景区景点、周边酒店、票务信息、保险信息。
质量描述：
如需求所述的足够用户承载量；可靠的系统安全性；界面美观且生动。
签字认证：
甲方（需方）：
胡文静
乙方（供方）：
岚羽昕
3.2.2需求变更管理
需求变更：
假设静乐旅游公司对IT项目团队提出如下需求变更：
在显示主面做一个能显示访问当前系统在线的人员数量，方便管理员统计每天用户是否旅游的情况。
软件基线产品修改提交单
申请人：
小刘
申请日期：
2016年6月13日
项目名称：
“静乐旅游”应用程序
修改内容：
增加功能“显示在线访问人员数量”，可之间与表中用户进行记录，不必输入对方用户名
验证意见：
同意更改
验收人：
小齐
验证日期：
2016年6月24日
4.任务分解
4.1任务清单
4.1.1功能分解清单
“静乐旅游”应用程序
1.1后台管理
1.1.1景点管理
1.1.1.1添加景点
1.1.1.2修改景点
1.1.1.3删除景点
1.1.1.4查询景点
1.1.1.5会员对景点订单的确认
1.1.1.6界面
1.1.1.7单元测试
1.1.2订票管理
1.1.2.1添加订票
1.1.2.2修改订票
1.1.2.3删除订票
1.1.2.4查询订票
1.1.2.5会员对票务订单的确认
1.1.2.6界面
1.1.2.7单元测试
1.1.3酒店管理
1.1.3.1添加酒店
1.1.3.2修改酒店
1.1.3.3删除酒店
1.1.3.4查询酒店
1.1.3.5会员对酒店订单的确认
1.1.3.6界面
1.1.3.7单元测试
1.1.4保险管理
1.1.4.1添加保险
1.1.4.2修改保险
1.1.4.3删除保险
1.1.4.4查询保险
1.1.4.5会员对保险订单的确认
1.1.4.6界面
1.1.4.7单元测试
1.1.5会员管理
1.1.5.1添加会员
1.1.5.2修改会员
1.1.5.3删除会员
1.1.5.4查询会员
1.1.5.5界面
1.1.5.6单元测试
1.1.6系统管理
1.1.6.1添加新的会员信息
1.1.6.2修改新的会员信息
1.1.6.3删除新的会员信息
1.1.6.4查询新的会员信息
1.1.6.5界面
1.1.6.5单元测试
1.2前台管理
1.2.1注册会员
1.2.1.1界面
1.2.1.2单元测试
1.2.2修改用户信息
1.2.2.1界面
1.2.2.2单元测试
1.2.3收藏夹
1.2.3.1界面
1.2.3.2单元测试
1.2.4我的订单
1.2.4.1界面
1.2.4.2单元测试
1.2.5景区景点
1.2.5.1界面
1.2.5.2单元测试
1.2.6周边酒店
1.2.6.1界面
1.2.6.2单元测试
1.2.7票务信息
1.2.7.1界面
1.2.7.2单元测试
1.2.8保险信息
1.2.8.1界面
1.2.8.2单元测试
4.2WBS
“静乐旅游”应用程序
项目规划：
1.合同签署
1.1需求分析报告&项目初步规划
1.2项目建议书
1.3合同草案
2.计划编制
2.1时间表
3.确认计划
需求分析：
1.需求开发
1.1需求探索
2.需求管理
2.1需求规格说明书
3.系统测试计划编制
总体设计：
1.策略确定
2.开发标准确定（具体分配方式见任务清单）
3.架构设计（具体分配方式见任务清单）
4.集成测试计划编制
详细设计：
1.接口设计（具体分配方式见任务清单）
2.模块设计（具体分配方式见任务清单）
3.单元测试计划编制
实现：
1.编码（具体分配方式见任务清单）
2.代码复核
3.单元测试
测试：
1.集成测试
2.系统测试
3.测试总额
4.缺陷跟踪
5.手册编写
5.规模估算
5.1直接成本
成本估算的方法有1.代码行、功能点、对象点。
2.类比（自顶向下）估算法。
3.自下而上估算法。
4.参数法估算法。
5.专家估算法。
在这个项目中我们主要采取功能点估算法，同时融合进入其他的估算方法进行验证。
用系统的功能数量来测量其规模，与实现产品所使用的语言和技术没有关系的。
5.1.1基本公式
FP=UFC*TCF
UFC：
未调整功能点计数
TCF：
技术复杂度因子
TCF=0.56+0.01（sum（Fi））：
Fi:
0-5,TCF:
0.56-1.35
5.1.2
复杂度权重因素
项
简单
一般
复杂
外部输入
2
3
5
外部输出
3
4
6
外部查询
2
3
5
外部文件
4
6
9
内部文件
6
9
14
本项目的功能点计算：
功能点
项
简单
一般
复杂
外部输入
5*2
3*3
5*5
外部输出
7*3
6*4
1*6
外部查询
5*2
1*3
3*5
外部文件
4*4
2*6
4*9
内部文件
10*6
1*9
1*14
总计
117
57
96
UFC
117+57+96=270
TCF—技术复杂度因子：
技术复杂度因子
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.01*45=1.1。
功能点计算：
FP=UFC*TCF。
UFC=270。
TCF=1.1.
FP=270*1.1=297
人月数计算：
在本项目中，根据以往的经验使用经验导出成本模型（面向FP驱动的）中的kemerer模型来计算人月数。
Kemerer模型E=60.62×7.728×10-8FP3。
带入本项目的实际数据E=60.62*7.728*10-8*2973=122.73（人月）
直接成本计算
直接成本组成:
开发成本,管理成本，质量成本。
简易估算：
开发（工作量）规模：
Scale（Dev）122.73（单位：
人月）
管理、质量（工作量）规模：
Scale（Mgn）=a*Scale（Dev）=122.73*20%=24
a:
比例系数：
例如：
20%--25%
直接成本=规模*人力成本参数=146*0.15=21.9万元
人力成本参数=1500/人月（由于校内开发，成本比较低）
5.2间接成本
间接成本=规模*人力成本参数*间接成本系数（间接成本系数=1.5—3）
本例中间接成本=122.73*0.15*1.5=28万元。
估算成本=直接成本+间接成本=21.9+28=49.9万元
5.3估算的误差
由于基础数据不足，缺乏经验的估算人员，签约前后不连贯，低劣的推测技术，估算对需求的敏感性等一系列原因，可能会引起估算的误差。
对此项目的人月数定义考虑误差如下
估算：
220个人月+40-25
+15人月：
需求变更
-15人月：
学生的晚上时间的利用
+5人月：
学生期末考试
-10人月：
实验室采取奖励措施
+20人月：
寒暑假
最佳情况：
195人月。
计划情况：
220人月。
最坏情况：
260人月。
6.项目进度
项目进度管理是指在项目实施过程中，对各阶段的进展程度和项目最终完成的期限所进行的管理。
是在规定的时间内，拟定出合理且经济的进度计划（包括多级管理的子计划），在执行该计划的过程中，经常要检查实际进度是否按计划要求进行，若出现偏差，便要及时找出原因，采取必要的补救措施或调整、修改原计划，直至项目完成。
其目的是保证项目能在满足其时间约束条件的前提下实现其总体目标。
项目进度管理是根据工程项目的进度目标，编制经济合理的进度计划，并据以检查工程项目进度计划的执行情况，若发现实际执行情况与计划进度不一致，就及时分析原因，并采取必要的措施对原工程进度计划进行调整或修正的过程。
工程项目进度管理的目的就是为了实现最优工期，多快好省地完成任务。
项目进度管理是项目管理的一个重要方面，它与项目投资管理、项目质量管理等同为项目管理的重要组成部分。
它是保证项目如期完成或合理安排资源供应，节约工程成本的重要措施之一。
6.1活动定义
“静乐旅游”应用程序
项目规划：
1.合同签署
1.1需求分析报告&项目初步规划
1.2项目建议书
1.3合同草案
2.计划编制
2.1时间表
3.确认计划
需求分析：
1.需求开发
1.1需求探索
2.需求管理
2.1需求规格说明书
3.系统测试计划编制
总体设计：
1.策略确定
2.开发标准确定（具体分配方式见任务清单）
3.架构设计（具体分配方式见任务清单）
4.集成测试计划编制
详细设计：
1.接口设计（具体分配方式见任务清单）
2.模块设计（具体分配方式见任务清单）
3.单元测试计划编制
实现：
1.编码（具体分配方式见任务清单）
2.代码复核
3.单元测试
测试：
1.集成测试
2.系统测试
3.测试总额
4.缺陷跟踪
5.手册编写
6.2活动排序
甘特图
关键路径是决定项目完成的最短时间,关键路径上的任何任务都是关键任务,关键路径上的任何活动延迟，都会导致整个项目完成时间的延迟.
在这个项目中首先按照时间顺序计算最早开始时间和最早完成时间,然后按照逆时间顺序计算最晚开始时间和最晚结束时间。
从而得出关键路径是：
开始–》需求分析-》详细设计–》编码-》测试。
6.3进度执行与优化
在项目的进行过程中可以通过1、分解关键任务2、给任务增加资源3、缩减关键任务的工期4、重叠或延迟链接任务5、设置日历增加工作时间6、通过分配加班工时来缩短关键任务来达到缩减项目工期的目的。
6.4使用工具
在整个项目中将使用Microsoft的项目管理软件产品microsoftproject2012和Visio2013来进行项目的管理
7.质量计划
7.1软件项目的质量计划
7.1.1项目经理的职责
1.评审质量计划。
2.与质量保证人员一起协商不符合项问题的纠正措施，并安排资源实施纠正措施。
3.定期或事件驱动地评审质量保证活动和结果。
7.1.2质量保证人员的职责
1.负责项目实施过程中对项目实施情况进行监督，包括对项目实施过程和工作产品进行监督检查。
2.实施项目组成员的质量保证培训。
3.制定质量保证计划。
4.按计划实施审计活动，依照质量保证计划执行评审/审计，并记录执行中发现的不符合项。
5.对不符合问题提交不符合项报告，跟踪并验证纠正措施的执行情况。
6.对项目内不能解决的不符合项问超；向高层管理提交报告。
7.向项目经理报告项目质量工作状况和质量度量结果。
8.定期向项目组报告质量活动的结果。
9.制定质量保证的过程改进计划，记录过程数据。
7.1.3质量目标
1.基于需求的测试覆盖率为100%。
2.功能测试完善
3.每个阶段评审中发现的问题都已经解决或得到适当处理。
4.产品发布时不存在严重问题以及以上的缺陷。
5.严格满足合同的要求和规格
6.用户领导满意
7.1.4质量策略
1.控制产品的质量，及时纠正缺陷
2.应该特别注意项目工作产品质量的早期评审工作，元论是质量保证还是质量控制，采取的策略都是早期预防和早期排除缺陷。
3.将质量贯彻到日常的项目进展过程中
7.2软件质量保证活动
7.2.1审计
审计（Audit）是对过程或者产品的一次独立评估。
将审核的主体与为该主体以前建立的一组规程和标准进行比较目的是确保真正的遵循了这一个过程，产生了合适的文档和精确反映实际项目的报告，可以预先规划的，也可以是临时决定的。
现在讲本项目中的预先规划审计列出如下。
在整个开发过程中，会根据需要插入临时决定的审计。
1.审计软件项目计划时间：
计划结束标准：
合同要求
2.需求规划文档时间：
需求制定标准：
需求规格说明
3.总体设计文档时间：
总体设计制定标准：
软件项目计划
4.详细设计文档时间：
详细设计制定标准：
软件项目计划
5.编码规范时间：
详细设计制定标准：
软件项目计划
6.产品代码时间：
编码结束标准：
编码规范
7.测试文档时间：
详细设计制定标准：
企业质量要求
8.用户手册时间：
产品提交之前标准：
项目计划和需求
将审计的结果编写审计报告及时提交。
以下是制定的质量审计模版
7.2.2过程评审
项目严格按照组织定义的软件过程进行开发，过程评审的具体依据参照企业的过程规范，保证项目中的所有过程活动都在实施范围内。
在每次评审之后，要对评审结果做出明确的决策并形成评审记录。
评审可采取文件传阅、评审会等形式。
质量保证人员负责对项目过程迸行监督，将发现的问题和解决情况在每周的例会上通报，对没有解决的问题迸行讨论，对不能解决的问题提交高级管理者处理。
每个周末，进行一次配置管理审核，确认配置管理工作是否正常进行。
7.2.3问题报告
质量保证人员对于每次审计活动发现的不符合项，应该和项目经理协商不符合项的纠正措施并预定完成日期，若和项目经理存在意见分歧，质量保证人员可以上报给高层管理者，由高层管理者决定最后的措施。
同时，不符合项在项目周例会中汇报。
对不符含项，质量保证人员耍在预定完成日期内重新审计，验证不符合项的纠正情况，若超过预定完成日期1周仍然有没解决的不符合项，质量保证人员上报给高级管理者，由高级管理者决定最后的措施。
质量保证人员有独立的汇报途径，日常的汇报途径如下：
1.将发现的问题通知项目经理，协调纠正措施。
2.将项目组内不能协调的问题汇报给茼级管理者，由南级管理者协调解决。
3.将日常工作和过程数据汇报给质量经理，由其统一收集并进行统计。
7.3测试计划
下面是本项目的测试大概计划，详细内容请查阅测试文档。
1.基本测试
单元测试
集成测试
系统测试
测试工作安排
测试准备工作
测试用例设计
2.系统测试设计
版本兼容性测试
性能测试
恢复测试
安全性测试
压力测试
7.4质量改善
为了达到更好的质量，现在制定质量改善要求：
1.软件质量活动必须经过规划
2.软件质量活动规划必须明文规定
3.质量活动必须尽早开始
4.质量小组必须独立存在
5.应该经过训练
6.必须有适当的经费
8.其他
8.1配置计划
8.1.1配置管理过程
1.配置项标识、跟踪
2.配置管理环境建立
3.基线变更管理
4.基线审核
5.配置状态统计
6.配置管理计划
8.1.2配置管理的人员组成
角色
人员
职责、工作范围
配置管理者
李莉
（1）制定《配置管理计划》
（2）创建和维护配置库
SCC负责人
媛媛
（1）审批《配置管理计划》
（2）审批重大的变更
SCCB成员
项目经理－肖晓
配置管理者－柳眉
审批某些配置项或基线的变更
8.2风险计划
8.2.1风险识别与评估
1.风险识别是试图通过系统化地确定对项目计划的威
升级会员 