qq_32198063的博客

CMM（Capability Maturity Model）是用于衡量软件过程能力的事实上的标准，同时也是目前软件过程改进最好的参考标准。因为参加CMM评估的项目都是精心准备的，个别项目或者事业部通过了CMM评估并不意味着整个企业达到了那个水平，这里面的水分相当大。现在业界关注的焦点则是“企业如何以比较低的代价有效地提高软件过程能力”，攻克这个难题必将产生巨大的经济效益和社会效益，这正是作者致力研究的课题。（2）既要提高企业的软件过程能力，又想通过CMM评估来提升企业的威望与知名度。第12章 实现与测试。

维护人员归纳分析各种维护要求，总结一些有价值的建议，向有关领导汇报。

产品（项目）名称《产品维护计划》1.维护范围2.任务安排维护人员任务描述时间3.费用预算款项用途金额本计划的审批意见上级领导审批意见：签字日期。

服务人员归纳分析客户的各种要求，总结一些有价值的建议，向上级领导汇报。

产品（项目）名称客户服务计划1.基础设施客户信息库客户服务电话客户服务电子邮件客户服务网站其他2.任务安排服务人员任务描述时间3.费用预算款项用途金额本计划的审批意见上级领导审批意见：签字日期。

当产品开发完成并开始销售时，原开发小组应当解散以便人力资源重新分配。其中大部分的开发人员将参加新的项目，只需要留小部分人员从事客户服务和产品维护工作。对于合同项目，客户服务和产品维护的周期、费用等等在合同中决定。对于自主研发的产品而言，一般地，客户服务和产品维护工作将持续到产品退役。客户服务与产品维护的流程如图21-1所示。客户服务准备响应客户要求接收客户要求产品维护准备执行维护工作接收并判断维护要求图21-1 客户服务与产品维护流程。

提示：对比学员的主要收益和培训的总成本。）向学员发调查问卷。

机构或项目名称培训通知培训课程名称培训目标培训资料培训方式讲师学员管理人员服务人员时间地点。

对于项目培训计划，项目经理或者技术负责人应当根据产品（项目）的特征、培训需求和机构现状（例如资源、时间、经费等因素）来制定计划。机构发展战略、客户培训要求、员工培训要求等确定培训需求。）对于项目培训计划，项目经理或者技术负责人应当根据。现状（例如资源、时间、经费等因素）来制定计划。）对于机构培训计划，培训管理员应当根据。）对于机构培训计划，培训管理员应当根据。客户的培训要求、项目成员的知识技能等。）机构的领导审批机构培训计划。）项目经理审批项目培训计划。

按范围划分，培训管理可分为“机构培训管理”和“项目培训管理”。流程如图20-1所示。确定机构培训需求执行培训制定机构培训计划培训效果评估确定项目培训需求执行培训制定项目培训计划培训效果评估图20-1 培训管理流程机构培训管理的对象是公共的培训课程，这些培训课程对大多数学员而言是必需的。例如企业规章制度、业绩考核、项目管理、软件工程、客户关系等培训。上述培训由机构培训管理员来管理。

如果采购物品存在严重的缺陷，则退回给乙方。乙方应当给出纠正缺陷，双方协商第二次验收的时间。乙方应当赔偿给甲方造成的损失。）如果采购物品存在一些轻微的缺陷，则乙方应当给出纠正缺陷的措施，双方协商是否需要第二次验收。提示：如果甲方发现采购物品中存在缺陷，双方应当视问题的严重性给出合适的处理措施。）所有采购物品都通过了审查和测试后，乙方将其交付给甲方。）双方的责任人签字认可。采购物品验收测试报告。

除为了维护操作相关设备而需接触乙方有关技术资料等商业秘密和技术秘密的甲方有关人员外，甲方同意不向其他人员泄露乙方的任何保密信息，也不向任何第三方转让、交换或泄漏乙方提供的上述商业秘密和技术秘密等，或擅自出版以上“技术资料”，如违反本条规定致使乙方遭受损失，甲方应负法律责任，并赔偿由此引起的直接和可能的经济损失。不可抗力是指本合同生效后，发生不能预见并且对其发生和后果不能防止或避免的事件，如地震、台风、水灾、火灾、战争等，致使直接影响本合同的履行或不能按约定的条件履行。乙方应当赔偿给甲方造成的损失。

提示：采购管理小组可以根据实际情况适当修改检查项。）如果所有的候选供应商都不合格，则不必挑选供应商。供应商的产品部件的功能是否符合本产品的需求？供应商的产品部件的性能价格比是否令人满意？）采购管理小组挑选出最合适的候选供应商。供应商的产品部件的质量是否令人满意？供应商能否提供较好的服务（维护）？供应商是否已经取得业界认可的证书如。供应商的供货周期是否可以接受？提示：参见采购竞标邀请书。综合竞争力排名与风险分析。候选供应商的材料和应标书。综合竞争力排名与风险分析。候选供应商的材料和应标书。

决策”产生的文档，阐述需求采购的产品部件的主要功能，细节内容可以放在附录中。提示：有助于阐述或细化采购竞标邀请书的材料均可作为附录。提示：给出质量要求，时间、费用限制等等。

如果工作成果存在严重的缺陷，则退回给乙方。乙方应当给出纠正缺陷，双方协商第二次验收的时间。乙方应当赔偿给甲方造成的损失。）如果工作成果存在一些轻微的缺陷，则乙方应当给出纠正缺陷的措施，双方协商是否需要第二次验收。提示：如果甲方发现工作成果中存在缺陷，双方应当视问题的严重性给出合适的处理措施。）当待验收的所有工作成果都通过了审查和测试后，乙方将其交付给甲方。）双方的责任人签字认可。

检查方式（技术评审、测试）外包开发过程监控报告。

如乙方逾期完成开发项目，甲方将给予乙方一个月的宽限期，并且不追究乙方的违约责任。乙方应对本合同所述的技术资料和技术秘密采取保密措施，乙方未经甲方的书面同意，不得将本项目所涉及的技术秘密和资料向与本项目无关的人员或第三方透露，也不能就有关合同内容的任何部分进行新闻的发布、公开的宣称、否认或承认。乙方在研究开发过程中，由于受现有的科学知识、技术水平或试验条件的限制，发生无法预见、无法防止或无法克服的技术困难，导致研究开发工作全部或部分失败，该风险责任的损失由双方共同承担，即根据损失的金额各自承担。

候选承包商的资源（人力、财力、物资等）是否充足并且稳定？）如果所有的候选承包商都不合格，则不必挑选承包商。候选承包商以前开发的产品是否有良好的质量？）外包管理小组挑选出最合适的候选承包商。候选承包商的信誉如何？候选承包商是否已经取得业界认可的证书如。候选承包商的开发能力与管理能力如何？候选承包商的地理位置是否合适？能否提供较好的服务（维护）？是否具有开发相似产品的经验？综合竞争力排名与风险分析。候选承包商的材料和应标书。考察候选承包商的执行能力。综合竞争力排名与风险分析。候选承包商的材料和应标书。

决策”产生的文档，阐述外包产品部件的主要功能，细节内容可以放在附录中。提示：有助于阐述或细化外包竞标邀请书的材料均可作为附录。提示：给出质量要求，时间、费用限制等等。

软件业是一个高速变化、新技术层出不穷的行业，同时又是人力资源成本相对较高的行业。企业需要采用外包和采购形式来获取待开发产品的部件，最大限度地从社会分工合作、资源共享中获益。一般地，在立项阶段，产品负责人应当进行“Make-or-Buy决策”，确定待开发产品的哪些部分应当“采购”、“外包开发”或者“自主研发”。外包管理与采购管理的流程如图19-1所示。外包管理流程MakeorBuy决策采购自主研发外包开发选择承包商签订合同过程监控验收采购管理流程选择供应商签订合同验收。

质量问题跟踪表项目名称质量保证员编号问题描述解决措施实际解决情况。

第N份。

本表适用于检查“工作过程”与“工作成果”是否符合既定的规范。不合格 TBD 待完成 NA 不适用。）请使用者根据实际情况制定本检查表。过程域及工作成果检查表。过程域及工作成果检查表。过程域及工作成果检查表。

质量保证员根据本项目的特征，确定需要检查的主要过程域和主要工作成果，并估计检查时间和人员。虽然质量保证小组在行政上独立于任何项目，但是质量保证员的工作与项目紧密相关，所以《质量保证计划》应当经过项目经理的审批才能生效，以确保《质量保证计划》与《项目计划》一致。）一般地，项目开发小组自己负责单元测试和集成测试，机构独立测试小组负责最终产品的测试（如系统测试和验收测试）。质量保证员根据《技术评审计划》，制定“参与技术评审”的计划。《质量保证计划》，以确保《质量保证计划》符合机构的要求（避免过于宽松而流于形式）

过程质量与产品质量存在某种程度的因果关系，通常“好的过程”产生“好的产品”而“差的过程”将产生“差的产品”。人们销售的是产品而不是过程，用户关心的是最终产品的质量，而开发者（团队）既要关心过程质量又要关心产品质量。质量保证。质量保证人员通过有计划地检查“工作过程以及工作成果”是否符合既定的规范，来监控和改进“过程质量”与“产品质量”。技术评审。请同行专家、技术人员对工作成果进行评审，尽早发现工作成果中的缺陷。测试。通过运行测试用例来找出软件中的缺陷。例如单元测试、集成测试、系统测试、验收测试等。

输入名称，版本，日期等信息。

等权限，但是不能拥有“删除”权限。配置管理员的权限最高。具体操作视所采用的配置管理软件而定。配置管理员记录自己和他人对配置库的重要操作，例如删除文件等。配置管理员为每个项目成员分配操作权限。一般地，项目成员拥有。的批示，从配置库中提取配置项交付给接受人。配置管理员记录主要配置项的版本信息。配置管理员周期性地备份配置库。

配置管理员制定配置库备份计划，指明“何人”在“何时”（频度）将配置库备份到“何处”。（1）根据《项目计划》中的角色分配，确定配置管理员，CCB（配置控制委员会）成员。）配置管理员根据所采用的配置管理软件，确定计算机资源（考虑内存、外存、配置管理员标识配置项，估计每个配置项的正式发布时间。）配置管理员确定本项目的配置管理软件。例如：审批某些配置项或基线的变更。用于配置管理的软硬件资源。）制定《配置管理计划》）审批《配置管理计划》基线所包含的主要配置项。附录：本计划审批意见。附录：本计划审批意见。

项目研发和管理过程中会产生许许多多的工作成果，例如文档、程序和数据等，它们都应当被保存起来，以便查阅和修改。如果把所有文件一股脑地塞进计算机里，那么使用起来肯定很麻烦。毫无疑问，人们应当将文件分门别类、有条理地保存起来。凡是纳入配置管理范畴的工作成果统称为配置项（Configuration Item, CI），配置项主要有两大类：（1）属于产品组成部分的工作成果，例如需求文档、设计文档、源代码、测试用例等。（2）项目管理和机构支撑过程域产生的文档。这些文档虽然不是产品的组成部分，但是值得保存。

根据机构产品线和项目的特征，制定用户指南（手册）检查表。根据机构产品线和项目的特征，制定系统设计检查表。根据机构产品线和项目的特征，制定代码检查表（例如。根据机构产品线和项目的特征，制定测试用例检查表。根据机构产品线和项目的特征，制定需求检查表。不合格 TBD 待完成 NA 不适用。

主要记录评审过程中的“疑问”、“答复”、“争论”、“处理意见”等。提示：由审核人员填写此表格。工作成果合格，“无需修改”或者“需要轻微修改但不必再审核”。工作成果不合格，需要作比较大的修改，之后必须重新对其评审。工作成果基本合格，需要作少量的修改，之后通过审核即可。修正后的工作成果仍然不合格，需重新修改。工作成果名称，标识符，版本，作者，时间。工作成果名称，标识符，版本，作者，时间。提示：由主持人或评审员填写此表格。提示：由主持人或评审员填写此表格。提示：由主持人或评审员填写此表格。

工作成果名称，标识符，版本，作者。

项目经理根据《项目计划》以及现实情况（如可以支配的人力资源），审批《技术评审计划》。）项目的技术负责人（或技术骨干）制定本项目的《技术评审计划》。种组合：高高，高中，高低，中中，中低，低低。）技术评审方式有两种：正规技术评审（），非正规技术评审（

技术评审最初是由IBM公司为了提高软件质量和提高程序员生产率而倡导的。技术评审方法已经被业界广泛采用并收到了很好的效果，它被普遍认为是软件开发的最佳实践之一。技术评审能够在任何开发阶段执行，它可以比测试更早地发现并消除工作成果中的缺陷。通过消除工作成果的缺陷而提高产品的质量。越早消除缺陷就越能降低开发成本。开发人员能够及时地得到同行专家的帮助和指导，无疑会加深对工作成果的理解，更好地预防缺陷，一定程度上提高了开发生产率。

如果工作成果存在严重的缺陷，则退回给开发方。开发方应当给出纠正缺陷，双方协商第二次验收的时间。开发方应当赔偿给客户方造成的损失。）如果工作成果存在一些轻微的缺陷，则开发方应当给出纠正缺陷的措施，双方协商是否需要第二次验收。提示：如果客户方方发现工作成果中存在缺陷，双方应当视问题的严重性给出合适的处理措施。）当待验收的所有工作成果都通过了审查和测试后，开发方将其交付给客户方。）双方的责任人签字认可。

应交付成果的名称、版本。参考系统测试完成准则。

成果审查。验收人员审查开发方应当交付的成果，如代码、文档等等。确保这些成果是完整的并且是正确的。验收测试。验收人员对待交付的产品进行全面的测试，确保产品功能、质量符合需求。验收测试的内容、方法与系统测试几乎是相同的。两者主要区别在于执行人员不同。验收测试人员来自于客户方，而系统测试人员则来自于开发方。客户验收流程如图15-1所示。验收准备问题处理成果审查与验收测试交付与签字图15-1 客户验收流程《客户验收计划》，模板见。《验收测试用例》，模板见。《客户验收报告》，模板见。

客户发现的软件缺陷、问题和建议等。

Beta测试协议1.基本信息开发方Beta客户待测试的产品Beta测试时间知识产权声明2.互利协议开发方给予Beta用户的优惠和承诺Beta用户给予开发方的利益和承诺3.签字生效开发方负责人签字Beta客户签字。

对于非合同项目，在产品正式销售之前，并没有明确的客户，只存在潜在的客户。所以在系统测试之后，不能套用“客户验收规范”。由于系统测试人员来自于开发方内部，他们并不能完全代表客户。所以把仅通过系统测试的产品直接销售给潜在的客户，很有可能因产品尚存在某些缺陷而导致客户不满意，甚至引发商业纠纷。解决这个问题的好方法是Beta测试。Beta测试是指在产品正式销售之前，开发方将产品交付给一些潜在的客户（简称Beta用户）免费试用，请他们对产品进行测试，并获取他们对产品的建议。