《旅游管理程序-软件项目管理大作业.docx》由会员分享，可在线阅读，更多相关《旅游管理程序-软件项目管理大作业.docx（20页珍藏版）》请在三一办公上搜索。
1、目录1.合同管理3Ll合同简介3工程名称3合同双方3协议形式3供给条件和维护协议31.2 软件所有权31.3 环境与标准31.4 客户承诺与验收规程31.5 工程和质量管理31.6 时间表31.7 价格和付款方式31. 8其他法律要求及违约处理42 .工程生存期43 .需求管理53.1 软件需求管理过程53. 2需求规格7需求规格说明书（简略版）7需求变更管理74.任务分解84.1 任务清单8功能分解清单84. 2WBS95.规模估算105. 1直接本钱10根本公式10105. 2间接本钱126. 3估算的误差126 .工程进度136. 1活动定义137. 2活动排序148. 3进度执行与优化
2、149. 4使用工具147 .质量方案157.1 软件工程的质量方案157.1.1工程经理的职责15质量保证人员的职责15质量目标15质量策略157. 2软件质量保证活动15审计15过程评审15问题报告167. 3测试方案168. 4质量改善168.其他178. 1配置方案17配置管理过程17配置管理的人员组成178. 2风险方案17风险识别与评估17风险规划17风险分析表17风险控制199. 3团队管理19工程组织结构19团队沟通201.合同管理1.l合同简介1.Ll工程名称静乐旅游1.1.2合同双方甲方：静乐旅游公司乙方：IT工程团队1.1.3协议形式技术合同供给条件和维护协议供给的软件：
3、乙方为甲方提供所需的“静乐旅游”应用程序。提供的效劳：乙方为甲方提供所需的日常维护和效劳器管理，同时对甲方用户提供使用指导。提供的文档：乙方在交付软件时提供详细的软件规格说明书和使用文档。安装效劳：乙方为甲方提供软件安装。公文处理：乙方负责将甲方提供的旅游工程输入系统并进行分类。维护协议：当甲方在使用该产品时，在正常操作的情况下出现BUG或系统错误，乙方免费为甲方提供修复效劳以保障软件的正常使用。当由于甲方的错误使用等非软件原因导致出现故障，乙方同样提供修复效劳。由于甲方拥有该软件的源代码所有权，因此甲方需要承当局部维修和进一步开发的责任。当软件需要新的功能拓展或改版升级时，由双方共同协商决定
4、。1.2软件所有权该软件是由甲方该软件是由甲方向乙方定制，甲方拥有该软件的版权，乙方不能将该软件的任何版本卖个其他客户。软件提交时，工程源代码的所有权自动移交到甲方，乙方不得擅自对源代码进行修改。1.3环境与标准环境：乙方为甲方安装软件和进行员工培训时，需要由甲方提供住宿和膳食，乙方在规定时间内完成任务。甲方要保证安装软件的硬件设备和合同初始规定一致，乙方只保证软件和规定的硬件兼容。由任何一方的单方面原因导致的延期产生的费用，由该方面支付。标准：乙方在开发过程中必须遵守ISO12207关于软件生命周期和文档的标准。1.4客户承诺与验收规程客户承诺：乙方开发软件过程中，甲方通过人员协同乙方进行开
5、发。该人员主要参与工程的规划设计和需求分析，阶段性验收和总体测试。当工程出现需求变更时，对乙方进行详细的阐述说明。乙方不负责这些人员提供食宿和联系设备。验收规程：2016年6月24日，乙方为甲方安装所需的软件。6月25日至6月31日甲方代表对产品进行验收测试，并根据需求在6月30日前对商品提出更正请求。测试通过后，双方进行软件交付签字。乙方对甲方进行软件使用培训。1.5工程和质量管理甲乙双方前四个月每月初进行一次进展会议，后三个月每两周周末进行进展会议。会议内容为乙方向甲方提供最新进度的掩饰和下一阶段的工作安排和方案。甲方根据演示提出相应的整改意见，并对下一步工作进行提出意见和建议。1.6时间
6、表详细时间表见工程进度。此处略。1. 7价格和付款方式软件总价为150万元整。合同签订后，甲方向乙方支付50万元定金。工程的第三个月，乙方按方案时间表完成需求分析、系统分析、设计和完成系统的根本框架后，甲方向乙方支付50万元。该系统完成后，甲方进行验收测试，在签字验收完成后，甲方向乙方支付全款。1.8其他法律要求及违约处理由任何一方的过失导致出现损失后的赔偿由双方协商决定。甲方法人代表：胡文静乙方法人代表：岚羽昕签约地点：静乐旅游公司工程管理主任办公室有效期限：2015年2018年6月26号2 .工程生存期确定该工程的生存期模型按如下步骤进行分析：评审、分析工程的特性；选择适合工程的生存期模型
7、；标识生存期模型与工程不一致地方,并进行裁减。“静乐旅游”应用程序涉及到用户的隐私平安，因此很强调产品的性能和平安性。需保证产品能保持稳定运行，不会以为一定数量的用户同时登录注册等操作时挂机，以致珍贵的消息或操作无法及时运行。总而言之该工程的性能平安性为主，可操作性次之，界面美观度最末。虽然工程的需求可能会因领导“挑剔”的口味而一再改变，不过大体的需求是明确的。而且又考虑到工程平安性能的首要要求，以Y模型为根底的生存期最为适宜。同时参杂增量模型生存期的一些特点以应对可能会随时添加的功能需求。工程生存期模型如下：该生存期模型将V模型除最后的工程规划和验收测试以外的过程做复制，套用增量模型在首先完
8、成根本功能的根底上增加功能。3 .需求管理3.1 软件需求管理过程静乐旅游公司提出需求如下：设计开发、安装调试并后期满足需求的“静乐旅游”应用程序。需要该程序为桌面应用程序，进入程序后需要弹出旅游介绍界面，该旅游介绍界面需与计算机自身系统别离，不得覆盖，具有独立窗口。该系统实现了管理员通过对景点信息、订票信息、酒店信息、保险信息、会员信息维护，实现了会员在线预订景区景点旅游的功能。其模块介绍如下：后台：后台是整个信息系统中最重要复杂的局部。管理员通过此处对网站内容进行管理.后台管理共分为景点管理、订票管理、酒店管理、保险管理、会员管理、系统管理。1.景点管理对景点信息进行添加、修改、删除和查询
9、操作；对会员的景点订单信息进行确认。2 .订票管理添加新的航向信息，修改、删除和查询票务信息操作；对会员的票务订单信息进行确认。3 .酒店管理添加新的酒店信息，修改、删除和查询酒店信息操作；对会员的酒店订单信息进行确认。4 .保险管理添加新的保险信息，修改、删除和查询保险信息操作；对会员的保险订单信息进行确认。5 .会员管理添加新的会员信息，修改、删除和查询会员信息操作。6 .系统管理可以通过链接进入后台主页、前台主页，修改密码以及退出系统操作。综上所述，系统后台的功能需求可以通过图3.1简要表示。旅游信息管理系统后台景点管理订单管理酒店管理保险管理会员管理系统管理图3.1系统后台的功能需求前
10、台：前台局部就是用户浏览、选择景点的地方，需根据所需旅游线路安排布局，照顾用户浏览习惯，简化流程，使会员能迅速找到旅游景区景点，真正做到“简洁高效流畅”的环境。1 .注册会员用户可以预定旅游景区景点信息,但是用户必须通过注册成为会员才具有这些权限。2 .修改用户信息会员可以对自己的信息进行修改。3 .收藏夹会员可以将中意的旅游景区景点信息放入收藏夹，并对该信息进行删除或生成订单操作。4 .我的订单可以查看生成旅游景区景点的订单信息，并对已经确认的订单信息进行相应的明细信息的酒店选择，订票、保险的购置等。5 .景区景点用户可以通过选择景点城市查看网站中的景区景点信息。6 .周边酒店用户可以通过输
11、入城市、价格或名称以及选择星级查询相应的酒店信息。7 .票务信息用户可以通过输入出发地或目的地以及选择类型查询相应的票务信息。8 .保险信息用户可以通过输入名称或选择类型查询相应的保险信息。综上所述，系统的前台功能需求可以通过图3.2简要表示。旅游信息管理系统前台图3.2系统前台的功能需求3.2需求规格3.2.1需求规格说明书（简略版）系统定义：“静乐旅游”应用程序应用环境：1VindOWS2000；WindOWSXP；WindowsVista；Windows7；LINUX；IOSetc.功能规格：后台（景点管理、订票管理、酒店管理、保险管理、会员管理、系统管理）前台（注册会员、修改用户信息、
12、收藏夹、我的订单、景区景点、周边酒店、票务信息、保险信息）性能需求：保证用户同时登录效劳器时也不会因处理的信息量过大大而导致系统瘫痪。另必须保证系统的平安性，可以禁得住一般的黑客袭击和内部作假。对账户有足够的保护措施以防账户被盗。操作简单明了，提示明显，界面美观且生动。现实约束：景点管理、订票管理、酒店管理、保险管理、会员管理、系统管理、注册会员、修改用户信息、收藏夹、我的订单、景区景点、周边酒店、票务信息、保险信息。质量描述：如需求所述的足够用户承载量；可靠的系统平安性；界面美观且生动。签字认证：甲方（需方）：胡文静乙方（供方）：岚羽听3.2.2需求变更管理需求变更：假设静乐旅游公司对IT工
13、程团队提出如下需求变更：在显示主面做一个能显示访问当前系统在线的人员数量，方便管理员统计每天用户是否旅游的情况。软件基线产品修改提交单申请人：小刘申请日期：2016年6月13日工程名称：“静乐旅游”应用程序修改内容：增加功能”显示在线访问人员数量”，可之间与表中用户进行记录，不必输入对方用户名验证意见：同意更改验收人：小齐验证日期：2016年6月24日4.任务分解4.1 任务清单4.1.1 功能分解清单“静乐旅游”应用程序1.1后台管理1.1.1景点管理1.1.1.1添加景点1.LL2修改景点1.L1.3删除景点1.L1.4查询景点1.1.5会员对景点订单确实认1.LL6界面1.LL7单元测试
14、1.1.2订票管理1.L2.1添加订票1.L2.2修改订票1.L2.3删除订票1.1.2.4查询订票1. 1.2.5会员对票务订单确实认1. 2.6界面2. 1.2.7单元测试2.1. 3酒店管理1. 1.3.1添加酒店2. 1.3.2修改酒店3. 1.3.3删除酒店4. 1.3.4查询酒店I .1.3,5会员对酒店订单确实认3.6界面1.3.7单元测试1.1.4保险管理1.1.4.1添加保险1.L4.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.L5.2修改会员1.L
15、5.3删除会员1.L5.4查询会员1.L5.5界面1.L5.6单元测试1.1.6系统管理1.1.6.1添加新的会员信息1.L6.2修改新的会员信息1.L6.3删除新的会员信息1.L6.4查询新的会员信息1.1.6.5界面1.L6.5单元测试1. 2前台管理1. 2.1注册会员1.2. 1.1界面1.3. 1.2单元测试1.4. 2修改用户信息1.5. 2,1界面1.6. 2.2单元测试1. 2.3收藏夹1.2. 3.1界面3.2单元测试1.2.4我的订单1.3. 4.1界面4.2单元测试1.2.5景区景点1.4. 5.1界面5.2单元测试1.2.6周边酒店1.5. 6.1界面1.6. 6.2单
16、元测试1. 2.7票务信息7.1界面1.2.7.2单元测试1.2.8保险信息1.2. 8.1界面1.3. 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 .模块设计（具体分配方式见任务
17、清单）3 .单元测试方案编制实现：1 .编码（具体分配方式见任务清单）2 .代码复核3 .单元测试测试：1 .集成测试2 .系统测试3 .测试总额4 .缺陷跟踪5 .手册编写5.规模估算5.1 直接本钱本钱估算的方法有L代码行、功能点、对象点o2.类比（自顶向下）估算法。3.自下而上估算法。4.参数法估算法。5.专家估算法。在这个工程中我们主要采取功能点估算法，同时融合进入其他的估算方法进行验证。用系统的功能数量来测量其规模，与实现产品所使用的语言和技术没有关系的。5. 1.1根本公式FP=UFC*TCFUFC：未调整功能点计数TCF：技术复杂度因子复杂度权重因素项简单一般复杂外部输入235外
18、部输出346外部查询235外部文件469内部文件6914本工程的功能点计算:功能点TCF一技术复杂度因r：项简单一般复杂外部输入5*23*35*5外部输出7*36*41*6外部查询5*21*33*5外部文件4*42*64*9内部文件10*61*91*14总计1175796UFC117+57+96=270技术复杂度因子Fl可靠的备份和恢复F2数据通信F3分布式函数F4性能F5大量使用的配置F6联机数据输入F7操作简单性F8在线升级F9复杂界面FlO复杂数据处理Fll重复使用性F12安装简易性F13多重站点F14易于修改TCF=O.65+O.O.1*（5+4+3+2+1+5+3+22+3+5+4+
19、3+3）=O.65+O.O1*45=1.Io功能点计算：FP=UFC*TCF0UFC=270oTCF=L1.FP=270*l.1=297人月数计算：在本工程中，根据以往的经验使用经验导出本钱模型（面向FP驱动的）中的kemerer模型来计算人月数。Kemerer模型E=60.62X7.728IO8FP）带入本工程的实际数据E=60.62*7.728*10-8*2973=122.73（人月）直接本钱计算直接本钱组成:开发本钱,管理本钱，质量本钱。简易估算：开发（工作量）规模：Scale（Dev）122.73（单位：人月）管理、质量（工作量）规模：Scale（Mgn）=a*Scale（Dev）=1
20、22.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人月：需求变更“5人月
21、：学生的晚上时间的利用+5人月：学生期末考试-IO人月：实验室采取奖励措施+20人月：寒暑假最正确情况：195人月。方案情况：220人月。最坏情况：260人月。6.工程进度工程进度管理是指在工程实施过程中，对各阶段的进展程度和工程最终完成的期限所进行的管理。是在规定的时间内，拟定出合理且经济的进度方案（包括多级管理的子方案），在执行该方案的过程中，经常要检查实际进度是否按方案要求进行，假设出现偏差，便要及时找出原因，采取必要的补救措施或调整、修改原方案，直至工程完成。其目的是保证工程能在满足其时间约束条件的前提下实现其总体目标。工程进度管理是根据工程工程的进度目标，编制经济合理的进度方案，并据
22、以检查工程工程进度方案的执行情况，假设发现实际执行情况与方案进度不一致，就及时分析原因，并采取必要的措施对原工程进度方案进行调整或修正的过程。工程工程进度管理的目的就是为了实现最优工期，多快好省地完成任务。工程进度管理是工程管理的一个重要方面，它与工程投资管理、工程质量管理等同为工程管理的重要组成局部。它是保证工程如期完成或合理安排资源供给，节约工程本钱的重要措施之O6. 1活动定义“静乐旅游”应用程序工程规划：1 .合同签署需求分析报告&工程初步规划1.2工程建议书1.3合同草案2 .方案编制2. 1时间表3 .确认方案需求分析：1 .需求开发1.1 需求探索2 .需求管理2.1 需求规格说
23、明书3 .系统测试方案编制总体设计：1 .策略确定2 .开发标准确定（具体分配方式见任务清单）3 .架构设计（具体分配方式见任务清单）4 .集成测试方案编制详细设计：1 .接口设计（具体分配方式见任务清单）2 .模块设计（具体分配方式见任务清单）3 .单元测试方案编制实现：1 .编码（具体分配方式见任务清单）2 .代码复核3 .单元测试测试：4 .集成测试5 .系统测试6 .测试总额7 .缺陷跟踪8 .手册编写9 .2活动排序甘特图ID任务名称开始时间完成持续时间Q216年1项目规划2016/4/262016/5/41周2天2需求分析2016/5/62016/5/161周2天3总体设计2016
24、/5/172016/5/302周4详细设计2016/5/302016/6/13天I5编码2016/6/62016/6/212周2天6测试2016/6/212016/6/271周.键路径是决定工程完成的最短时间,关键路径上的任何任务都是关键任务,关键路径上的任何活动延迟，都会导致整个工程完成时间的延迟.在这个工程中首先按照时间顺序计算最早开始时间和最早完成时间,然后按照逆时间顺序计算最晚开始时间和最晚结束时间。从而得出关键路径是：开始-需求分析-详细设计-编码-测试。6.3进度执行与优化在工程的进行过程中可以通过1、分解关键任务2、给任务增加资源3、缩减关键任务的工期4、重叠或延迟链接任务5、设
25、置日历增加工作时间6、通过分配加班工时来缩短关键任务来到达缩减工程工期的目的。6.4使用工具在整个工程中将使用Microsoft的工程管理软件产品microsoftproject2012和Visio2013来进行工程的管理7.质量方案7.1 软件工程的质量方案工程经理的职责1.评审质量方案。2 .与质量保证人员一起协商不符合项问题的纠正措施，并安排资源实施纠正措施。3 .定期或事件驱动地评审质量保证活动和结果。7.1.2质量保证人员的职责1 .负责工程实施过程中对工程实施情况进行监督，包括对工程实施过程和工作产品进行监督检查。2 .实施工程组成员的质量保证培训。3 .制定质量保证方案。4 .按
26、方案实施审计活动，依照质量保证方案执行评审/审计，并记录执行中发现的不符合项。5 .对不符合问题提交不符合项报告，跟踪并验证纠正措施的执行情况。6 .对工程内不能解决的不符合项问超；向高层管理提交报告。7 .向工程经理报告工程质量工作状况和质量度量结果。8 .定期向工程组报告质量活动的结果。7. .制定质量保证的过程改良方案，记录过程数据。8. 1.3质量目标1 .基于需求的测试覆盖率为100%o2 .功能测试完善3 .每个阶段评审中发现的问题都已经解决或得到适当处理。4 .产品发布时不存在严重问题以及以上的缺陷。5 .严格满足合同的要求和规格.用户领导满意1.4质量策略1.控制产品的质量，及
27、时纠正缺陷2 .应该特别注意工程工作产品质量的早期评审工作，元论是质量保证还是质量控制，采取的策略都是早期预防和早期排除缺陷。3 .将质量贯彻到日常的工程进展过程中7.2软件质量保证活动7.2.1审计审计(AUdit)是对过程或者产品的一次独立评估。将审核的主体与为该主体以前建立的一组规程和标准进行比拟目的是确保真正的遵循了这一个过程，产生了适宜的文档和精确反映实际工程的报告，可以预先规划的，也可以是临时决定的。现在讲本工程中的预先规划审计列出如下。在整个开发过程中，会根据需要插入临时决定的审计。1.审计软件工程方案时间方案结束标准：合同要求2.需求规划文档时间需求制定标准：需求规格说明3.总
28、体设计文档时间总体设计制定标准：软件工程方案4.详细设计文档时间详细设计制定标准：软件工程方案5.编码标准时间详细设计制定标准：软件工程方案6.产品代码时间编码结束标准：编码标准7.测试文档时间详细设计制定标准：企业质量要求8.用户手册时间产品提交之前标准：工程方案和需求将审计的结果编写审计报告及时提交。以下是制定的质量审计模版7.2.2过程评审工程严格按照组织定义的软件过程进行开发，过程评审的具体依据参照企业的过程标准，保证工程中的所有过程活动都在实施范围内。在每次评审之后，要对评审结果做出明确的决策并形成评审记录。评审可采取文件传阅、评审会等形式。质量保证人员负责对工程过程迸行监督，将发现
29、的问题和解决情况在每周的例会上通报，对没有解决的问题迸行讨论，对不能解决的问题提交高级管理者处理。每个周末，进行一次配置管理审核，确认配置管理工作是否正常进行。7. 2.3问题报告质量保证人员对于每次审计活动发现的不符合项，应该和工程经理协商不符合项的纠正措施并预定完成日期，假设和工程经理存在意见分歧，质量保证人员可以上报给高层管理者，由高层管理者决定最后的措施。同时，不符合项在工程周例会中汇报。对不符含项，质量保证人员耍在预定完成日期内重新审计，验证不符合项的纠正情况，假设超过预定完成日期1周仍然有没解决的不符合项，质量保证人员上报给高级管理者，由高级管理者决定最后的措施。质量保证人员有独立
30、的汇报途径，日常的汇报途径如下：1 .将发现的问题通知工程经理，协调纠正措施。2 .将工程组内不能协调的问题汇报给茴级管理者，由南级管理者协调解决。3 .将日常工作和过程数据汇报给质量经理，由其统一收集并进行统计。7. 3测试方案下面是本工程的测试大概方案，详细内容请查阅测试文档。1 .根本测试单元测试集成测试系统测试测试工作安排测试准备工作测试用例设计2 .系统测试设计版本兼容性测试性能测试恢复测试平安性测试压力测试7. 4质量改善为了到达更好的质量，现在制定质量改善要求：1 .软件质量活动必须经过规划2 .软件质量活动规划必须明文规定3,质量活动必须尽早开始4 .质量小组必须独立存在5 .
31、应该经过训练6 .必须有适当的经费8.其他6.1 配置方案8. 1.1配置管理过程L配置项标识、跟踪2.配置管理环境建立3.基线变更管理4 .基线审核5 .配置状态统计6 .配置管理方案8. 1.2配置管理的人员组成角色人员职责、工作范围配置管理者李莉1制定配置管理方案2创立和维护配置库SCC负责人媛媛1审批配置管理方案2审批重大的变更SCCB成员工程经理一肖晓配置管理者一柳眉审批某些配置项或基线的变更9. 2风险方案8. 2.1风险识别与评估1 .风险识别是试图通过系统化地确定对工程方案的威胁，识别和可预测的风险。2 .风险识别过程：输入-标识风险-按照一定标准对风险排序-制定风险表3 .根
32、据“IT工程常常存在一些共同的风险源”我们根据以往经验制定了风险分析表。检查表法是利用检查表作为风险识别的工具，是根据风险要素建立软件工程的风险条目列表，列表中列出所有与风险因素有关的提问，可以使管理者集中识别常见的类型中的和可预测的风险。8.2.2风险规划针对风险分析的结果，为提高实现工程目标的时机，降低风险的负面影响而制定风险应对策略和应对措施的过程，即制定一定的行动和策略来对付、减少、以至于消灭风险事件。通常采取的措施有1.回避风险。2.转移风险。3.损失控制。4.自留风险。8.2.3风险分析表通过对风险识别，风险评估，风险规划，我们制定了如下风险分析表。风险分析表排序输入风险事件可能性
33、影响风险值风险应对措施1最终用户抵抗该系统。政府领导可能会由于某个细节的问题对整个系统产生反感。70%70%50%1. 尽力满足用户提出的需求。2. 界面尽可能的美观，方便。3. 需求分析阶段派出专门的系统分析员去了解用户的性格，爱好，工作习惯。2工程期间，需求方更换领导。政府的工作可能会产生不同的领导有不同的需求的现象，如果更换领导将很大的增加风险。60%70%40%1.软件详细设计阶段注意增加软件的可重用性。提高复用水平。2.沟通和协调。3客户的需求规格说明。需求不明确，增加需求，导致需求蔓延，由于本软件是不太了解计算机的领导使用，变更需求可能性很大。70%50%35%1 .采取加班的方法
34、。2 .修改方案去掉一些任务。3 .与客户商量延长一些时间。4 .当出现影响重大的变更需求时与客户协调，这个版本的不做改动，在下一个版本中进行功能的提升。4合同带来的限制。进度要求紧，合同金额有限。30%50%15%可以请一些实习的学生做辅助工作,一来本钱不高，二来可以加快进度.。5交付期限紧缩。需方存在紧缩交付期限的可能。导致工程吃紧。20%60%10%1.加班。2.临时雇佣员工。3.调整结构。6历史工程信息。开发人员的流动。15%60%9%1 .注意工程团队的沟通，及时了解开发人员的动态。2 .控制好工程过程中的文档。3 .从其他的工程组借调人员。4 .从外部招聘有过此类开发经验人员。7人
35、员缺乏经验。由于本工程中的一些员工是刚刚招聘来的，可能会缺乏经验。15%30%10%1 .采取一帮一，让有经验的程序员带着相对经验少的程序员进行开发。2 .开发之前适当的培训。8用户数量超出方案。由于政府可能向下属单位推行该系统，导致使用人员激增。20%20%20%1.防患于未然，数据库上采用数据池的技术在，增加并发访问量。9技术达不到预期效果。可能有一些技术达不到预期的效果，不能使需方满意。如访问速度，一些特效笺笺10%10%10%1 .找懂得这种技术的人帮助。2 .向老师请教。8. 2.4风险控制1 .实施和跟踪风险管理方案，保证风险方案的执行，评估削减风险的有效性。2 .针对一个预测的风
36、险事实上是否发生了，确保针对某个风险而制定的风险消除步骤正在合理使用3 .监视剩余的风险和识别新的风险，4 .收集可用于将来的风险分析信息8. 3团队管理8. 3.1工程组织结构经过分析我们采用工程型的组织结构。结构图如下：此结构优点：1 .工程经理对工程可以全权负责。可以根据工程需要随意调动工程组织的内部资源或者外部资源。2 .工程型组织的目标单一，完全以工程为中心安排工作，决策的速度得以加快，能够对客户的要求做出及时响应，工程团队精神得以充分发挥。有利于工程的顺利完成。3 .工程经理对工程成员有全部权利，工程成员只对工程经理负责，防止了职能型工程组织下工程成员处于多重领导、无所适从的局面，
37、工程经理是工程的真正、唯一的领导者。4 .组织结构简单，易于操作。工程成员直接属于同一个部门，彼此之间的沟通交流简介、快速，提高了沟通效率，同时也加快了决策速度。此结构缺点：1.每一个工程型组织，资源不能共享，即使某个工程的专用资源闲置，也无法应用于另外一个同时进行的类似工程，人员、设施、设备重复配置，会造成一定程度的资源浪费。5 .公司里各个独立的工程型组织处于相对封闭的环境之中，公司的宏观政策、方针很难做到完全、真正的贯彻实施，可能会影响公司的长远开展。6 .在工程完成以后，工程型组织中的工程成员或者被拍到另一个工程中去，或者被解雇，对工程成员来说，缺乏一种事业上的连续性和平安感。7 .工程之间处于一种条块分割状态，工程之间缺乏信息交流，不同的工程组很难共享知识和经验，工程成员的工作会出现忙闲不均的现象。8. 3.2团队沟通为了保证团队信息的沟通制定如下沟通方案1 .每天午饭时间工程组成员进行口头交流。2 .每周五的15：00-17：00召开工程周例会,3 .及时提交问题报告，问题可以通过网络提交，工程经理会及时获取问题信息。4 .组内成员有任何问题可以在qq群内进行非正式的讨论。
