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

目录1. 合同管理31.1合同简介31.1.1项目名称31.1.2合同双方31.1.3协议形式31.1.4供应条件和维护协议31.2软件所有权31.3环境与标准31.4客户承诺与验收规程31.5项目和质量管理31.6时间表41.7价格和付款方式41.8其他法律要求及违约处理42.项目生存期53.需求管理53.1软件需求管理过程53.2需求规格73.2.1需求规格说明书（简略版）73.2.2需求变更管理84.任务分解84.1任务清单84.1.1功能分解清单84.2WBS105.规模估算115.1直接成本115.1.1基本公式115.1.2115.2间接成本135.3估算的误差136.项目进度146.1活动定义146.2活动排序156.3进度执行与优化156.4使用工具157.质量计划157.1软件项目的质量计划157.1.1 项目经理的职责157.1.2质量保证人员的职责157.1.3质量目标167.1.4质量策略167.2软件质量保证活动167.2.1审计167.2.2过程评审167.2.3问题报告167.3测试计划177.4质量改善178.其他188.1配置计划188.1.1配置管理过程188.1.2配置管理的人员组成188.2风险计划188.2.1风险识别与评估188.2.2风险规划188.2.3风险分析表188.2.4风险控制208.3团队管理208.3.1项目组织结构208.3.2团队沟通211. 合同管理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.35 5.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 + 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.627.72810-8 FP3。带入本项目的实际数据 E = 60.62 * 7.728 *10-8 *2973 =122.73（人月）直接成本计算直接成本组成:开发成本,管理成本，质量成本。简易估算：开发（工作量）规模：Scale(Dev) 122.73(单位：人月)管理、质量（工作量）规模： Scale(Mgn)=a* Scale(Dev) = 122.73 *20% = 24a :比例系数：例如：20%-25%直接成本=规模*人力成本参数 = 146 * 0.15 = 21.9万元人力成本参数=1500/人月（由于校内开发，成本比较低）5.2间接成本 间接成本= 规模*人力成本参数*间接成本系数（间接成本系数=1.53）本例中间接成本 = 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的项目管理软件产品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.将项目组内不能协调的问题汇报给茼级管理者，由南级管理者协调解决。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.风险识别是试图通过系统化地确定对项目计划的威胁，识别已知和可预测的风险。2.风险识别过程： 输入 标识风险 按照一定标准对风险排序 制定风险表3.根据“IT项目常常存在一些共同的风险源”我们根据以往经验制定了风险分析表。检查表法是利用检查表作为风险识别的工具，是根据风险要素建立软件项目的风险条目列表，列表中列出所有与风险因素有关的提问，可以使管理者集中识别常见的类型中的已知和可预测的风险。 8.2.2风险规划 针对风险分析的结果，为提高实现项目目标的机会，降低风险的负面影响而制定风险应对策略和应对措施的过程，即制定一定的行动和策略来对付、减少、以至于消灭风险事件。通常采取的措施有1.回避风险。2.转移风险。3.损失控制。4.自留风险。 8.2.3风险分析表 通过对风险识别，风险评估，风险规划 ，我们制定了如下风险分析表。风险分析表排序输入风险事件可能性影响风险值风险应对措施1最终用户抵制该系统。政府领导可能会由于某个细节的问题对整个系统产生反感。70%70%50%1. 尽力满足用户提出的需求。2. 界面尽可能的美观，方便。3. 需求分析阶段派出专门的系统分析员去了解用户的性格，爱好，工作习惯。2项目期间，需求方更换领导。政府的工作可能会产生不同的领导有不同的需求的现象，如果更换领导将很大的增加风险。60%70%40%1. 软件详细设计阶段注意增加软件的可重用性。提高复用水平。2. 沟通和协调。3客户的需求规格说明。需求不明确，增加需求，导致需求蔓延，由于本软件是不太了解计算机的领导使用，变更需求可能性很大。70%50%35%1采取加班的方法。2修改计划去掉一些任务。3与客户商量延长一些时间。4.当出现影响重大的变更需求时与客户协调，这个版本的不做改动，在下一个版本中进行功能的提升。4合同带来的限制。进度要求紧，合同金额有限。30%50%15%可以请一些实习的学生做辅助工作,一来成本不高,二来可以加快进度.。5交付期限紧缩。需方存在紧缩交付期限的可能。导致项目吃紧。20%60%10%1. 加班。2. 临时雇佣员工。3. 调整结构。6历史项目信息。开发人员的流动。15%60%9%1注意项目团队的沟通，