软件项目管理火车站票务管理报告-

目录1.项目启动 11.1合同拟定工作 11.1.1技术的内容、范围及要求 11.1.2应达到的技术指标和参数 11.1.3研究开发计划 21.1.4研究开发经费、报酬及其支付或结算方式 21.1.5利用研究开发经费购置的设备、器材、资料的财产权属 21.1.6履行的期限、地点和方式 21.1.7技术情报和资料的保密 31.1.8技术协作的内容 31.1.9技术成果的归属和分享 31.1.10验收的标准和方式 31.1.11风险的承担 31.1.12解决合同纠纷的方式 41.1.13名词和术语解释 41.1.14其它 41.2生存期模型选择 52.项目计划与执行 62.1需求分析 62.1.1查询 62.1.2订票 62.1.3退票 72.1.4信息需求 72.1.5性能需求 72.1.6图表 82.2任务分解WBS 172.3项目进度计划 182.4项目成本估算 222.4.1签订合同前 222.4.2合同签署后 222.4.3成本预算 232.5项目风险管理 242.5.1软件项目风险管理概念 242.5.2软件项目中的风险 252.5.3风险分析 262.6项目质量计划 272.6.1组织机构 272.6.2质量目标 282.6.3质量策略 292.6.4质量保证活动 292.6.5产品审计 302.6.6过程评审 312.6.7质量控制活动 312.6.8质量保证的报告途径 312.6.9记录的收集、维护和保存 323.项目收尾与总结 323.1软件项目管理总结 323.1.1软件项目管理的概述 323.1.2软件项目的管理过程详解 323.2软件项目管理学习体会 33火车站订票系统1.项目启动1.1合同拟定工作技术开发合同项目名称:xx火车站订票系统委托人（甲方）：xx铁路公司研究开发人（乙方）：xx软件开发研究中心签订地点：xx市签订地点：2014年9月17日有效期限：2014年9月10日至2015年5月31日xx技术市场管理办公室根据《中华人民共和国合同法》的规定，合同双方就xx火车站订票系统开发项目的技术开发，经协商一致，签订本合同。1.1.1技术的内容、范围及要求根究甲方的要求，乙方完成xx铁路公司订票系统开发。根据甲方要求进行系统方案设计，要求建立B/S结构的，基于的SQLserver数据库、NT服务器和J2EE技术的三层构架体系的综合服务软件系统；配合甲方，在与整体系统相融合的基础上，建立系统运行的软硬件环境；具体需求求见SOW。1.1.2应达到的技术指标和参数（1）系统应满足并行登录，并查询的速度要求。其中主要内容包括：保证100人以上可以同时登录系统；所有查询速度应在10秒以内；保证数据的每周备份；工作日期间不能当机；出现问题应在10分钟内恢复。（2）系统的主要功能是应满足双方认可的需求规格，不可以随意改动。1.1.3研究开发计划（1）第一阶段：乙方在合同签订后7个工作日内，完成合同内容的系统设计方案。（2）第二阶段：完成第一阶段的系统设计方案之后，乙方于50个工作日内完成系统基本功能的开发。（3）第三阶段：完成第一和第二阶段的任务之后，由甲方配合乙方于3个工作日内完成系统在北京信息中心的调试、集成。1.1.4研究开发经费、报酬及其支付或结算方式（1）研究开发经费是指完成本项目研究开发工作所需的成本。报酬指本项目开发成果的使用费和研究开发人员的科技补贴。（2）本项目研究开发经费和报酬（人民币大写）：伍拾万元整。（3）支付方式：分期支付。本合同签订之日起生效，甲方在五个工作日内应付给乙方合同总额的50%，计人民币250000.00（人民币大写贰拾伍万元整）。1.1.5利用研究开发经费购置的设备、器材、资料的财产权属1.1.6履行的期限、地点和方式本合同自2014年9月10日至2015年5月31日在xx履行。本合同履行方式：甲方责任：甲方全力协助乙方完成合同内容；合同期内甲方为乙方提供专业性接口技术支持。乙方责任：乙方按甲方要求完成合同内容。乙方愿提供在实现功能的前提下，进一步予以完善；乙方在合同商定的时间内保证系统正常运行；乙方在项目验收后提供一年免费维护；未经甲方同意，乙方不得向第三方提供本系统中涉及专业的技术内容和所有的系统数据。1.1.7技术情报和资料的保密本合同中的相关专业技术内容和所有的系统数据，归甲方所有，未经甲方同意乙方不得提供给第三方。1.1.8技术协作的内容见系统设计方案。1.1.9技术成果的归属和分享（1）专利申请权。（2）技术秘密的使用权、转让权。1.1.10验收的标准和方式研究开发所完成的技术成果，达到了本合同第二条所列技术指标，按国家标准，采用一定的方式验收，由甲方出具技术项目验收证明。1.1.11风险的承担在履行本合同的过程中，却因在现有水平和条件下难以克服的技术困难，导致研究开发部分或全部失败所造成的损失，风险责任由甲方承担50%，乙方承担50%。本项目风险责任确认的方式：双方协商。除不可抗力因素外（指发生战争、地震、洪水、飓风或其他人力不能控制的不可抗力事件），甲乙双方须遵守合同承诺，否则视为违约并承担违约责任：（1）如果乙方不能按期完成软件开发工作并交给甲方使用，乙方应向甲方支付延期违约金。每延迟一周，乙方向甲方支付合同总额0.5%的违约金，不满一周按一周计算，但违约金总额不能超过合同总额的5%。（2）如果甲方不能按期向乙方支付合同款项，甲方应向乙方支付延期违约金。每延迟一周，乙方向甲方支付合同总额0.5%的违约金，不满一周按一周计算，但违约金总额不能超过合同总额的5%。1.1.12解决合同纠纷的方式在履行本合同过程中发生争议，双方当事人和解或调解不成，可采取仲裁或按司法程序解决。双方同意由xx市仲裁委员会仲裁；双方约定向xx市人民法院起诉。1.1.13名词和术语解释本合同中使用的下列词语具有如下含义：“软件”包括“软件系统”，除另有指明外，指在本合同履行期内所开发和提供的当前和将来的软件版本，包括乙方为履行本合同所开发和提供的软件版本和相关的文件；“交付”指乙方在双方规定的日期内交付约定开发的软件的行为。但是乙方完成交付行为，并不意味着乙方已经完成了本合同项下所规定的所有义务；“规格”是指在技术或其他开发任务上所设定的技术标准、规范；“源代码”指用于该软件的源代码。其必须可为熟练的程序员理解和使用，可打印以及被机器阅读或具备其他合理而必要的形式，包括对该软件的评估、测试或其它技术文件；“服务”指根据合同规定乙方应承担的技术支持，包括但不限于安装、调试、开发、测试、维护、培训、咨询等服务。1.1.14其它本合同一式6份，具有同等法律效力。其中正式两份，甲乙双方各执一份；副本4份，交由乙方；本合同未尽事宜，经双方协商一致，可在合同中增加补充条款，补充条款是合同的组成部分。本合同附件：甲方：___________________________（盖章）住所地：______________________________法定代表人：__________（签字） 电话：__________传真：__________联系人：_________电子邮箱地址：________联系人QQ号：___________________________开户银行：______________________________帐号：______________________________通讯地址：______________________________邮政编码：______________________________合同签订地：____________________________乙方：___________________________（盖章）住所地：______________________________法定代表人：__________（签字） 电话：__________传真：_________联系人：_________电子邮箱地址：________联系人QQ号：___________________________开户银行：______________________________帐号：______________________________通讯地址：______________________________邮政编码：______________________________合同签订地：____________________________1.2生存期模型选择针对本项目的开发特点，参考生存期模型说明和软件过程体系，决定采用增量式模型。理由如下：（1）火车站订票系统的全部功能分成通用功能和日常业务管理功能两大类，因此可以先基于通用功能做出一个最小的使用版本，再逐步添加其余的功能。这样一来，用户可以先试用最小版本的同时，提出更多明确的需求，这有助于下一阶段的开发，大大减小了开发的风险。（2）在火车站订票系统需求中，要求系统具有可扩充性。若使用增量模型，可以保证系统的可扩充性。用户明确了需求的大部分，但也存在不很详尽的地方。如：“关于火车车次档案，比照所提供资料设计，现在也没有一个成形的东西：，资源库系统只提到：应提供一个标准的资源库解决方案”。这样只有等到一个可用的产品出来，通过客户使用，然后进行评估，评估结果作为下一个增量的开发计划，下一个增量发布一些新增的功能和特性，直至产生最终完善的产品。（3）“系统要求有可扩充性，可以再现有系统的基础上，可以在前台加挂其他功能模块”也说明用户可能会增加新的需求。（4）对一个管理方式比较成熟的火车站，要完全舍弃原有的管理方式，用火车站售票系统替代全部管理，是不切实际的。所以，可以从基础的做起，逐步扩充其应用，所以选用增量模型来开发火车站售票系统。（5）本项目具备增量式模型的其他特点：[1]项目复杂程度为中等；[2]预计开发软件的成本为中等；[3]产品和文档的再使用率会很高；[4]项目风险较低。2.项目计划与执行2.1需求分析本网上订票系统应该具备如下功能：2.1.1查询分为对车次信息的查询和客户对已订车票信息的查询。要求：（1）对车次的查询，可以按照发车车次进行查询。（2）车次信息包括：车号、出发地、目的地、发车日期、开出时刻、票价。（3）座位类型设定。（4）车次信息只允许用户查询，不能修改。2.1.2订票通过查询系统，客户根据自己的需求找到满意的车次，再输入个人信息后直接通过网上订票确定已预订选中的车票。要求：订票记录应包括：会员名、车号、发车日期、订购日期、订购票数、总价。2.1.3退票可退票，通过查询系统，客户可以根据自己的名字找到自己的订票信息，通过退票模块退去已购车票。2.1.4信息需求即在系统中需要处理哪些数据。根据对火车站网上订票系统的分析，本系统的信息需求如表2.1-1所示。表2.1-1信息输入信息处理信息输出用户输入所需车次检索系统数据库符合用户需求的车次及相关信息用户输入个人信息及所需订购的车票信息更新系统中的订票信息，将新信息存入系统数据库操作反馈（如订票成功）用户输入自己的名字、身份证号；或交易的订单号检索系统数据库符合用户需求的订票信息用户输入自己的名字检索系统数据库以得到订票记录，删除用户请求的订票记录，更新系统数据库操作反馈（如退票成功等）2.1.5性能需求为了保证系统能够长期、安全、稳定、可靠、高效的运行，本系统应该满足以下的性能需求。（1）准确性和及时性系统处理的准确性和及时性是系统的必要性能。系统应能及时而且准确的根据用户权限及所输入的信息做出响应。由于本系统的查询功能对于整个系统的功能和性能完成举足轻重。作为系统的很多数据来源，而车票的数量和时间又影响用户的决策活动，其准确性和及时性很大程度上决定了系统的成败。在系统开发过程中，必须采用一定的方法保证系统的准确性和及时性。（2）易用性本系统是直接面对用户的，而用户往往对计算机并不是非常熟悉。这就要求系统能够提供良好的用户接口，易用的人机交互界面。要实现这一点，就要求系统应该尽量使用用户熟悉的术语和中文信息的界面，从而保证系统的易用性。（3）安全性网上订票系统中涉及到的数据是客运公司相当重要的信息，系统要保证用户的权限，对于车次等信息用户只享有查询服务，不得更改；系统还要提供方便的手段供系统维护人员进行数据备份、日常安全管理、以及系统意外崩溃时数据的恢复等工作。同时系统还要保证对数据库进行及时更新，保证数据一致性。2.1.6图表数据流图：见图1图1数据字典：表2.1-2车次信息数据字典名字：车次信息描述：存放车次信息的文件，以供用户查询定义：车次信息=车号+出发地+目的地+发车日期+开出时刻+到达时刻+坐位类型+票价位置：输出到CRT终端或类似的显示部件表2.1-3订票信息数据字典名字：订票信息别名：订单信息描述：存放订单信息的文件，以供用户查询，并作相应操作定义：订票记录=用户名+车号+发车日期+订购日期+订购票数+总价位置：输出到CRT终端或类似的显示部件表2.1-4用户信息数据字典名字：用户信息描述：存放用户信息的文件，以供用户方便的查询订单信息，进而做出相应的操作定义：用户信息=用户名+地址+性别+电话位置：输出到CRT终端或类似的显示部件E-R图：见图2图2系统流程图：见图3图3用例图：见图4图4顺序图：见图5图5状态图：见图6图6活动图：见图7图72.2任务分解WBS任务分解：见图8图8

2.3项目进度计划甘特图：见图9图9网络图：见图10图10资源分配图：见图11资源名称类型材料标签缩写组最大单位标准费率加班费率每次使用成本成本累算基准日历罗丹工时罗100%¥20.00/工时¥30.00/工时¥0.00按比例标准李都工时李100%¥20.00/工时¥20.00/工时¥0.00按比例标准张译工时张100%¥20.00/工时¥30.00/工时¥0.00按比例标准闫杰工时闫100%¥20.00/工时¥30.00/工时¥0.00按比例标准樊伟工时樊100%¥20.00/工时¥30.00/工时¥0.00按比例标准张合工时张100%¥20.00/工时¥30.00/工时¥0.00按比例标准罗美工时罗100%¥20.00/工时¥30.00/工时¥0.00按比例标准图112.4项目成本估算《火车站订票系统》估算是循序渐进的过程，随着项目的不断发展，估算可以重复多次进行的，而且是逐步精确的。本项目采用自下而上和参数法综合的成本估算方法，然后结合进度形成项目成本预算基线。2.4.1签订合同前签订合同前，根据以往类似项目的经验，采用类比估算方法，进行粗略的估算：根据用户的要求采用B/S结构，公司JSP+SQLServer的技术比较成熟，以前成功完成过类似的项目，根据SOW的说明，基本上需要2~3个开发人员，2个月左右的开发时间，基本上是4~6人月的规模，所以，10~15万可以作为合同的参考价格。这个阶段只需要一个粗略的量级的成本估算，可以不进行详细的成本预算。2.4.2合同签署后合同签署之后，根据现有的资源和WBS分解的结果，进一步细化估算，由于WBS分解是针对项目的功能进行的分解，在成本估算的时候，首先估算每个任务的开发规模，然后通过系数获得相应的质量、管理任务的规模，从而计算直接成本，再计算间接成本，最后计算总成本，具体过程如下。（1）人力资源：[1]2个开发人员[2]1个项目管理人员[3]1个项目质量人员[4]1个配置管理人员（2）设备资源（作为间接成本计算）：[1]3台电脑[2]1台服务器估算步骤如下：（1）获取项目分解结果WBS任务分解是按照项目的功能进行分解的。（2）计算开发成本[1]由于任务分解的结果主要是针对开发任务的分解，管理任务和质量任务可以通过计算开发任务得到，因此根据以往的经验，管理任务和质量任务=20%×开发任务。[2]从表中得知项目规模是177人天，假设开发人员成本参数=480元/天，则内部的开发成本=480元/天×177天=84960元。（3）计算管理、质量成本[1]项目的管理和预算成本=开发成本×20%=16992元。[2]直接成本=84960+16992=101952元。[3]计算间接成本[4]间接成本包括前期合同费用、房租水电、培训、员工福利、客户服务等。[5]根据以往经验，采用公式：间接成本=25%×直接成本=25488元。（4）计算总估成本项目总估成本=101952+25488=127440。（5）重新评估项目的报价[1]重新评估一下项目的报价准确性，当然这时候，项目的合同已经签署了，报价是不能更改的，但是通过再次的评估可以进一步明确企业的项目运作和利润情况等。[2]如果项目的利润是30%，其中风险基金10%，利润15%，税费5%。则项目的总报价=127440×1.3=1656272元。应该说报价还是比较合适的。2.4.3成本预算在进度计划编制完成时，会根据各项任务的情况，安排各项任务的预算成本，最后可以得到比较详细的成本分配情况。2.4.4成本的跟踪控制在项目跟踪控制的每个阶段，会根据项目的具体情况重新估算，预测项目完成后的成本。2.5项目风险管理2.5.1软件项目风险管理概念软件开发中的风险是指软件开发过程中及软件产品本身可能造成的伤害或损失。风险关注未来的事情，这意味着，风险涉及选择及选择本身包含的不确定性，软件开发过程及软件产品都要面临各种决策的选择。风险是介于确定性和不确定性之间的状态，是处于无知和完整知识之间的状态。另一方面，风险将涉及思想、观念、行为、地点等因素的改变。风险管理在项目管理中占有非常重要的地位。首先，有效的风险管理可以提高项目的成功率。其次，风险管理可以增加团队的健壮性。与团队成员一起进行风险分析可以让大家对困难有充分估计，对各种意外有心理准备，大大提高组员的信心，从而稳定队伍。第三，有效的风险管理可以帮助项目经理抓住工作重点，将主要精力集中于重大风险，将工作方式从被动救火转变为主动防范。被动风险策略是针对可能发生的风险来监督项目，直到它们变成真正的问题时，才会拨出资源来处理它们。对于风险管理的一个更聪明的策略是主动式的。主动策略早在技术工作开始之前就已经启动了。标识出潜在的风险，评估它们出现的概率及产生的影响，对风险按重要性进行排序，然后，软件项目组建立一个计划来管理风险。主动策略中的风险管理，其主要目标是预防风险。但是，因为不是所有的风险都能够预防，所以，项目组必须建立一个应付意外事件的计划，使其在必要时能够以可控的及有效的方式做出反应。任何一个系统开发项目都应将风险管理作为软件项目管理的重要内容。在进行软件项目风险管理时，要标识出潜在的风险，评估它们出现的概率及产生的影响，并按重要性加以排序，然后建立一个规划来管理风险。风险管理的主要目标是预防风险，但不是所有的风险都能够预防。所以必须建立一个意外事件计划，使其在必要时能以可控的和有效的方式做出反应。风险管理目标的实现包含三个要素。首先，必须在项目计划书中写下如何进行风险管理；第二，项目预算必须包含解决风险所需的经费，如果没有经费，就无法达到风险管理的目标；第三，评估风险时，风险的影响也必须纳入项目规划中。风险管理涉及的主要过程包括：风险识别，风险量化，风险应对计划制定和风险监控。风险识别在项目的开始时就要进行，并在项目执行中不断进行。就是说，在项目的整个生命周期内，风险识别是一个连续的过程。2.5.2软件项目中的风险（1）风险需求需求已经成为项目基准,但需求还在继续变化;需求定义欠佳,而进一步的定义会扩展项目范畴;添加额外的需求;产品定义含混的部分比预期需要更多的时间;在做需求中客户参与不够;缺少有效的需求变化管理过程。（2）计划编制风险计划、资源和产品定义全凭客户或上层领导口头指令,并且不完全一致;计划是优化的,是"最佳状态",但计划不现实,只能算是"期望状态";计划基于使用特定的小组成员,而那个特定的小组成员其实指望不上;产品规模(代码行数、功能点、与前一产品规模的百分比)比估计的要大;完成目标日期提前,但没有相应地调整产品范围或可用资源;涉足不熟悉的产品领域,花费在设计和实现上的时间比预期的要多。（3）风险组织和管理仅由管理层或市场人员进行技术决策,导致计划进度缓慢,计划时间延长;低效的项目组结构降低生产率;管理层审查决策的周期比预期的时间长;预算削减,打乱项目计划;管理层作出了打击项目组织积极性的决定;必要的规范,导至工作失误与重复工作;非技术的第三方的工作(预算批准、设备采购批准、法律方面的审查、安全保证等)时间比预期的延长。人员风险作为先决条件的任务(如培训及其他项目)不能按时完成;开发人员和管理层之间关系不佳,导致决策缓慢,影响全局;缺乏激励措施,士气低下,降低了生产能力;某些人员需要更多的时间适应还不熟悉的软件工具和环境;项目后期加入新的开发人员,需进行培训并逐渐与现有成员沟通,从而使现有成员的工作效率降低;由于项目组成员之间发生冲突,导致沟通不畅、设计欠佳、接口出现错误和额外的重复工作;适应工作的成员没有调离项目组,影响了项目组其他成员的积极性;找到项目急需的具有特定技能的人。（4）开发环境风险设施未及时到位;设施虽到位,但不配套,如没有电话、网线、办公用品等;设施拥挤、杂乱或者破损;工具未及时到位;工具不如期望的那样有效,开发人员需要时间创建工作环境或者切换新的工具;新的开发工具的学习期比预期的长,内容繁多。（5）客户风险客户对于最后交付的产品不满意,要求重新设计和重做;客户的意见未被采纳,造成产品最终无法满足用户要求,因而必须重做;对规划、原型和规格的审核决策周期比预期的要长;客户没有或不能参与规划、原型和规格阶段的审核,导致需求不稳定和产品生产周期的变更;客户答复的时间(如回答或澄清与需求相关问题的时间)比预期长;客户提供的组件质量欠佳,导致额外的测试、设计和集成工作,以及额外的客户关系管理工作。（6）产品风险矫正质量低下的不可接受的产品,需要比预期更多的测试、设计和实现工作;开发额外的不需要的功能(镀金),延长了计划进度;严格要求与现有系统兼容,需要进行比预期更多的测试、设计和实现工作;要求与其他系统或不受本项目组控制的系统相连,导致无法预料的设计、实现和测试工作;不熟悉或未经检验的软件和硬件环境中运行所产生的未预料到的问题;开发一种全新的模块将比预期花费更长的时间;依赖正在开发中的技术将延长计划进度。（7）过程风险大量的纸面工作导致进程比预期的慢;前期的质量保证行为不真实,导致后期的重复工作;太不正规(缺乏对软件开发策略和标准的遵循),导致沟通不足,质量欠佳,甚至需重新开发;过于正规(教条地坚持软件开发策略和标准),导致过多耗时于无用的工作;向管理层撰写进程报告占用开发人员的时间比预期的多;风险管理粗心,导致未能发现重大的项目风险。2.5.3风险分析在进行了风险辨识后，我们就要进行风险估算，风险估算从以下几个方面评估风险清单中的每一个风险：建立一个尺度，以反映风险发生的可能性；描述风险的后果；估算风险对项目及产品的影响；风险预测的整体精确度，以免产生误解。对辨识出的风险进行进一步的确认后分析风险，即假设某一风险出现后，分析是否有其他风险出现，或是假设这一风险不出现，分析它将会产生什么情况，然后确定主要风险出现最坏情况后，如何将此风险的影响降低到最小，同时确定主要风险出现的个数及时间。进行风险分析时，最重要的是量化不确定性的程度和每个风险可能造成损失的程度。为了实现这点，必须考虑风险的不同类型。识别风险的一个方法是建立风险清单，清单上列举出在任何时候可能碰到的风险最重要的是要对清单的内容随时进行维护，更新风险清单，并向所有的成员公开，应鼓励项目团队的每个成员勇于发现问题并提出警告。建立风险清单的一个办法是将风险输入缺陷追踪系统中，建立风险追踪工具，缺失追踪系统一般能将风险项目标示为已解决或尚待处理状态，也能指定解决问题的项目团队成员，并安排处理顺序。风险清单给项目管理提供了一种简单的风险预测技术，下表是一个风险清单：排序输入风险事件可能性（%）影响风险值风险应对措施1客户的sow需求不明确，增加需求607025采取加班的方法；修改计划去掉一些任务；与客户商量延长一些时间2合同进度要求紧，金额有限20-6020请实习生作辅导工作，成本不高并且可以加快速度3历史项目信息开发人员对测试工作不重视303013强制性要求每段代码保留测试单元，由SQA检查；加入专门的测试人员4WBS供货商，外包商的质量问题305010多选择几个可以备份的外包商和供应商5历史项目信息开发人员的流动20708注意项目团队的沟通，及时了解开发人员的动态；控制好项目过程中的文档；从其它的项目组借调人员；从外部招聘有过此类开发经验人员2.6项目质量计划2.6.1组织机构在项目实施期间成立项目质量保证组织，该组织由质量保证人员和项目经理等组成。项目经理负责质量监督工作及项目进展过程中各环节的质量把关，开发经理负责质量控制的工作，质量保证人员负责质量保证的工作。（1）职责在本项目中，质量保证组织的职责如下：高层管理是公司负责质量的高级管理，其质量职责如下：受理项目内不能解决的不符合问题，必要时与项目经理协调；负责听取质量保证组的工作报告，评审质量保证活动和结果；参加有关质量保证过程改进的评审。（2）项目的质量保证人员质量保证人员的质量职责如下：负责项目实施过程中对项目实施情况进行监督，包括对项目实施过程和工作产品进行监督检查；实施项目组成员的质量保证培训；制定质量保证计划；按计划实施审计活动，依照质量保证计划执行评审/审计，并记录执行中发现的不符合项；对不符合问题提交不符合项报告，跟踪并验证纠正措施的执行情况；对项目内不能解决的不符合项问超；向高层管理提交报告；向项目经理报告项目质量工作状况和质量度量结果；定期向项目组报告质量活动的结果；制定质量保证的过程改进计划，记录过程数据。（3）项目经理项目经理的质量职责如下：评审质量计划；与质量保证人员一起协商不符合项问题的纠正措施，并安排资源实施纠正措施；定期或事件驱动地评审质量保证活动和结果。2.6.2质量目标根据企业的质量方针和质量目标，结合本项目特点，制定项目的总体质量目标：基于需求的测试覆盖率为100%；软件功能测试用例通过率不低于95%；每个阶段评审中发现的问题都已经解决或得到适当处理；产品发布时不存在严重问题以及以上的缺陷；注：严重问题指导致系统或模块不能正常工作的问题。结合以往的项目经验和企业的质量相应标准，制定质量标准如表2.6-1所示。表2.6-1质量计划标准项目具体描述计划的质量问题数实际质量问题数缺陷排除率（缺陷数/页）需求检查4系统总体设计检查2缺陷排除率（缺陷数/KLOC）详细设计复核30详细设计检查10代码复核65代码检查20编译20单元测试15系统集成5系统测试52.6.3质量策略为了保证提交给用户的产品是高质量的，实施过程中采取的质量保证措施包括：将质量贯彻到日常的项目进展过程中；应该特别注意项目工作产品质量的早期评审工作，元论是质量保证还是质量控制，采取的策略都是早期预防和早期排除缺陷。2.6.4质量保证活动质量保证的主要活动包括过程评审和产品审计。过程评审和产品审计的目的是确保在项目进展过程的备个阶段和备个方面采取各项措施来保证和提高提交给用户的产品质量。过程评审和产品审计都应填写相应的报告或活动记录。2.6.5产品审计产品审计由质量保证人员来进行，检查项目产品是否达到质量目标。质量保证人员可以有选择性地审计项目生存期中创建的工作产品，以验证是否符合适当的标准，是否进行了质量检查。表2.6-2便是质量审计一览表。表2.6-2质量审计一览表项审计对象审计阶段参照的标准1软件项目计划计划结束企业质量体系2软件配置管理计划计划结束企业质量体系3软件质量保证计划计划结束企业质量体系4总体设计文档设计结束企业质量体系和项目计划5详细设计文档设计结束企业质量体系和项目计划6数据库表和编码规范设计结束企业质量体系和项目计划7产品代码每个阶段实施结束企业质量体系和项目计划8测试报告测试结束企业质量体系和项目计划9测试计划设计结束企业质量体系和项目计划10用户文档测试结束企业质量体系和项目计划2.6.6过程评审项目严格按照组织定义的软件过程进行开发，过程评审的具体依据参照企业的过程规范，保证项目中的所有过程活动都在实施范围内。在每次评审之后，要对评审结果做出明确的决策并形成评审记录。评审可采取文件传阅、评审会等形式。质量保证人员负责对项目过程迸行监督，将发现的问题和解决情况在每周的例会上通报，对没有解决的问题迸行讨论，对不能解决的问题提交高级管理者处理。每个周末，进行一次配置管理审核，确认配置管理工作是否正常进行。2.6.7质量控制活动质量控制活动包括代码走查、单元测试、集成测试、环境测试等由开发人负责，详见进度计划。编码人员在编写代码时要进行同步单元测试，单元测试要达到分支覆盖，产品通过单元测试和编码检查后，应提交给测试部进行集成测试、系统测试。测试部的测试应达到质量目标要求，软件发布时应达到测试通过准则的要求。2.6.8质量保证的报告途径质量保证人员对于每次审计活动发现的不符合项，应该和项目经理协商不符合项的纠正措施并预定完成日期，若和项目经理存在意见分歧，质量保证人员可以上报给高层管理者，由高层管理者决定最后的措施。同时，不符合项在项目周例会中汇报。对不符含项，质量保证人员耍在预定完成日期内重新审计，验证不符合项的纠正情况，若超过预定完成日期一周仍然有没解决的不符合项，质量保证人员上报给高级管理者，由高级管理者决定最后的措施。质量保证人员有独立的汇报途径，日常的汇报途径如下：将发现的问题通知项目经理，协调纠正措施；将项目组内不能协调的问题汇报给茼级管理者，由南级管理者协调解决；将日常工作和过程数据汇报给质量经理，由其统一收集并进行统计。2.6.9记录的收集、维护和保存项目组应当保留项目执行过程中形成的各类文档、各种记录、各级周报、各级会议记录，对于项目中问题的处理也需要形成记录保存。每周由质量保证人员根据任务清单的审计任务进行审计活动，并收集各活动的过程数据。3.项目收尾与总结3.1软件项目管理总结做任何事情都需要管理，好的管理出好的效益，开发软件项目也不例外。随着信息系统工程、网络工程、软件工程的发展，项目管理和软件工程的交汇越来越多，从而使“软件项目管理”发展起来，一个项目的成功与否，关键一点就是，看项目管理是否得当。所以，项目管理是项目的核心部分，是项目的灵魂。3.1.1软件项目管理的概述所谓项目，就是在特定条件下，具有特定目标的一次性任务，是在一定时间内，满足一系列特定目标的多项相关工作的总称．项目具有一次性