旅游管理程序软件项目管理大作业

目录1. 合同管理 .51.1合同简介.51.1.1 项目名称 .51.1.2 合同双方 .51.1.3 协议形式 .51.1.4 供应条件和维护协议.51.2软件所有权.51.3环境与标准.61.4客户承诺与验收规程.61.5项目和质量管理.61.6时间表 .61.7价格和付款方式.71.8其他法律要求及违约处理.72. 项目生存期.83. 需求管理 .103.1 软件需求管理过程.103.2 需求规格.133.2.1 需求规格说明书（简略版）.13-可编辑修改 -3.2.2 需求变更管理.134. 任务分解 .144.1 任务清单.144.1.1 功能分解清单.144.2wbs .185. 规模估算 .195.1 直接成本.195.1.1 基本公式 .205.1.2 .205.2 间接成本.225.3 估算的误差.236. 项目进度 .236.1 活动定义.246.2 活动排序.266.3 进度执行与优化.266.4 使用工具.267. 质量计划 .277.1 软件项目的质量计划.277.1.1项目经理的职责.277.1.2 质量保证人员的职责.277.1.3 质量目标 .277.1.4 质量策略 .287.2 软件质量保证活动.287.2.1 审 计 .287.2.2 过程评审 .297.2.3 问题报告 .297.3 测试计划.307.4 质量改善.308. 其他 .318.1 配置计划.318.1.1 配置管理过程.318.1.2 配置管理的人员组成.318.2 风险计划.328.2.1 风险识别与评估.328.2.2 风险规划 .328.2.3 风险分析表.328.2.4 风险控制 .368.3 团队管理.368.3.1 项目组织结构.368.3.2 团队沟通 .381. 合同管理1.1 合同简介1.1.1 项目名称静乐旅游1.1.2 合同双方甲方：静乐旅游公司乙方： it 项目团队1.1.3 协议形式技术合同1.1.4 供应条件和维护协议供应的软件：乙方为甲方提供所需的“ 静乐旅游 ”应用程序。提供的服务： 乙方为甲方提供所需的日常维护和服务器管理，同时对甲方用户提供使用指导。提供的文档：乙方在交付软件时提供详细的软件规格说明书和使用文档。安装服务：乙方为甲方提供软件安装。公文处理：乙方负责将甲方提供的旅游项目输入系统并进行分类。维护协议：当甲方在使用该产品时，在正常操作的情况下出现bug 或系统错误， 乙方免费为甲方提供修复服务以保障软件的正常使用。当由于甲方的错误使用等非软件原因导致出现故障，乙方同样提供修复服务。由于甲方拥有该软件的源代码所有权，因此甲方需要承担部分维修和进一步开发的责任。当软件需要新的功能拓展或改版升级时，由双方共同协商决定。1.2 软件所有权该软件是由甲方该软件是由甲方向乙方定制，甲方拥有该软件的版权，乙方不能将该软件的任何版本卖个其他客户。软件提交时，项目源代码的所有权自动移交到甲方，乙方不得擅自对源代码进行修改。1.3 环境与标准环境： 乙方为甲方安装软件和进行员工培训时，需要由甲方提供住宿和膳食，乙方在规定时间内完成任务。甲方要保证安装软件的硬件设备和合同初始规定一致，乙方只保证软件和规定的硬件兼容。由任何一方的单方面原因导致的延期产生的费用，由该方面支付。标准：乙方在开发过程中必须遵守iso 12207关于软件生命周期和文档的标准。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；windows xp；windows vista；windows 7 ；linux ；ios etc.功能规格：后台（景点管理、订票管理、酒店管理、保险管理、会员管理、系统管理）前台（注册会员、修改用户信息、收藏夹、我的订单、景区景点、周边酒店、票务信息、保险信息）性能需求： 保证用户同时登录服务器时也不会因处理的信息量过大大而导致系统瘫痪。另必须保证系统的安全性，可以禁得住一般的黑客袭击和内部 作假。 对账户有足够的保护措施以防账户被盗。操作简单明了，提示明显，界面美观且生动。现实约束：景点管理、订票管理、酒店管理、保险管理、会员管理、系统管理、注册会员、 修改用户信息、 收藏夹、我的订单、 景区景点、 周边酒店、票务信息、保险信息。质量描述：如需求所述的足够用户承载量；可靠的系统安全性； 界面美观且生动。签字认证：甲方（需方）：胡文静乙方（供方） ：岚羽昕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*tcfufc ：未调整功能点计数tcf：技术复杂度因子tcf=0.56+0.01(sum(fi)：fi:0-5,tcf:0.56-1.355.1.2项复杂度权重因素简单一般复杂外部输入235外部输出346外部查询235外部文件469内部文件6914本项目的功能点计算：功能点项简单一般复杂外部输入5 * 23 * 35 * 5外部输出7 *36 * 41* 6外部查询5 * 21 * 33 * 5外部文件4 * 42 *64 * 9内部文件10 * 61 * 91 * 14总计1175796ufc117 + 57+ 96= 270tcf 技术复杂度因子：技术复杂度因子f1可靠的备份和恢复f2数据通信f3分布式函数f4性能f5大量使用的配置f6联机数据输入f7操作简单性f8在线升级f9复杂界面f10复杂数据处理f11重复使用性f12安装简易性f13多重站点f14易于修改tcf=0.65 + 0.0.1 * ( 5 + 4 + 3+2 + 15 +22 + 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 -8 fp 3。带入本项目的实际数据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 活动排序甘特图id任务名称开始时间完成持续时间1项目规划2016/4/262016/5/41 周 2 天2需求分析2016/5/62016/5/161 周 2 天3总体设计2016/5/172016/5/302 周4详细设计2016/5/302016/6/13 天5编码2016/6/62016/6/212 周 2 天6测试2016/6/212016/6/271 周q2 16年关键路径是决定项目完成的最短时间,关键路径上的任何任务都是关键任务,关键路径上的任何活动延迟，都会导致整个项目完成时间的延迟.在这个项目中首先按照时间顺序计算最早开始时间和最早完成时间,然后按照逆时间顺序计算最晚开始时间和最晚结束时间。从而得出关键路径是：开始需求分析- 详细设计编码-测试。6.3 进度执行与优化在项目的进行过程中可以通过 1 、分解关键任务 2 、给任务增加资源 3 、缩减关键任务的工期 4 、重叠或延迟链接任务 5 、设置日历增加工作时间 6 、通过分配加班工时来缩短关键任务来达到缩减项目工期的目的。6.4 使用工具在整个项目中将使用microsoft的项目管理软件产品microsoft project 2012和 visio 2013 来进行项目的管理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. 将项目组内不能协调的问题汇报给茼级管理者，由南级管理者协调解决。