软件研发管理制度90134

软件研发管理制度文件状态：［V］草稿文件标识：Lolaage-Software—PM当前版本：0.1.2:］正式发布［］正在修改作 者：宋孝光完成日期：2012/3/27版本/状态作者参与者修改日期备注0.1.1宋孝光2012/3/26第一版草稿0.1.2宋孝光2012/3/27整理目录目录1软件研发制度综述11。1精简模型11。2精简过程域的目的41。3精简模型文档结构与规范细分51.4精简模型角色与职责表61。5公司软件过稈的政策81.5。 1冃标81。5。2机构领导的支持8153质量管理的政策81。5.4质量保证小组的政策91.5。 5项目团队的政策92立项管理93项目规划94项目监控104.1项目计划跟踪104。1.1任务跟踪104.1。2费用跟踪114.1.3资源跟踪114。1。4工作成果及其规模跟踪114.2控制偏差125风险管理126需求管理166・1需求确认176.2需求跟踪186。3需求变更控制187结项管理198需求开发209技术预研2110系统设计2210・1体系结构设计2310。2用户界面设计2310。3数据库设计2410・4模块设计2411实现与测试2512系统测试2613客户验收2714技术评审2815配置管理2916质量保证3117培训管理3318服务与维护33软件研发制度综述1。1精简模型“精简模型"是基于CMMI以及软件工程和项目管理知识而创作的一种“软件过程改进方法和规范”，它由众多的过程规范和文档模板组成。精简模型把产品生命周期划分为6个阶段,分别为：◊产品概念阶段◊产品定义阶段◊产品开发阶段◊产品测试阶段用户验收阶段产品维护阶段在精简模型中，软件项目的过程有三大类：项目管理过程、项目研发过程和机构支持过程。上述三类过程可以细分为17个主要过程域，分布在产品生命周期的各个阶段。项目管理过程包含6个过程域,分别为：立项管理◊结项管理◊项目规划◊项目监控◊风险管理◊需求管理项目研发过程包含7个过程域，分别为:需求开发技术预研◊系统设计实现与测试系统测试客户验收◊技术评审机构支撑过程包含4个过程域，分别为：◊配置管理◊质量保证◊培训管理◊服务与维护精简模型如图1-1所示。精简模型的主要特征和优点有:一、直观的过程模型精简模型将项目管理、项目研发、机构支撑所包含的工作划分为相对独立的三类过程，各个过程域之间的关系直观明了.这样,机构领导、项目经理、开发人员、测试人员、质量保证人员等人根据精简模型,很容易知道自己“应该在什么时候、按照什么规范做什么事情”。所以精简模型有助于使机构内的各个职能单位有条不紊地开展工作.二、容易裁剪与扩充精简模型的三类过程贯穿了产品的整个生命周期，17个最常见的过程域都合理地安排在产品生命周期中的某些阶段.用户可以根据自己产品的特征，适当地裁剪或扩充精简的过程域，很容易制定出最适合于本产品的过程模型。图1-1精简模型1。2精简过程域的目的精简模型所有17个过程域的目的如表1-1所示。项目管理过程域目的立项管理采纳符合机构最大利益的立项建议，通过立项管理使该建议成为正式的项目。杜绝不符合机构最大利益的立项建议被采纳，避免浪费机构的资源、资金、时间等。结项管理在项目开发工作结束后，对项目的有形资产和无形资产进行清算、对项目进行综合评估以及总结经验教训等。项目规划为项目的研发和管理工作制定合理的行动纲领（即项目计划） ，以便所有相关人员按照该计划有条不紊地开展工作。项目监控周期性地跟踪项目计划的各种参数如进度、工作量、费用、资源等 ，不断地了解项目的进展情况，以便当项目实际进展显著偏离计划时能够及时采取纠正措施 •风险管理在风险产生危害之前识别它们，从而有计划地消除或削弱风险。需求管理在客户与开发方之间建立对需求的共同理解，维护需求与其它工作成果的一致性，并控制需求的变更。项目研发过程域目的需求开发通过调查与分析，获取用户需求并定义产品需求。技术预研在立项之后到开发工作完成之前的时间内，对项目将采用的关键技术提前学习和研究，尽可能早地发现并解决开发过程中将会遇到的技术障碍 •系统设计设计软件系统的体系结构、用户界面、数据库、模块等，从而在需求与代码之间建立桥梁，指导开发人员去实现能满足用户需求的软件产品。实现与测试依据系统设计文档，编写并测试整个系统的代码。在 精简模型中，实现与测试是“编程、代码审查、单元测试、集成测试、缺陷管理与改错”的综合表述。系统测试对最终系统进行全面的测试，确保最终系统满足产品需求并且遵循系统设计。客户验收客户依据合同对产品进行审查和测试，确保产品满足客户需求。技术评审尽早地发现工作成果中的缺陷，并帮助开发人员及时消除缺陷，从而有效地提高产品的质量。机构支撑过程域目的配置管理通过执行版本控制、变更控制等规程，以及使用配置管理软件来保证所有配置项的完整性和可跟踪性•配置管理是对工作成果的一种有效保护•质量保证提供一种有效的人员组织形式和管理方法，通过客观地检查和监控“过程质量”与“产品质量”，从而实现持续地改进质量。培训管理根据机构（或项目）的需求来制定培训计划，并监督该计划的实施，确保培训取得预期效果。服务与维护是指产品销售之后的客户服务和产品维护，其宗旨是提高客户对产品以及对开发方的满意度。表1-1精简过程域的目的

1.3精简模型文档结构与规范细分精简模型的文档结构如图1—2所示，SPP包含17个过程域，规范细分如表1-2所示。图1-2精简模型文档结构项目管理过程域主要规程文档模板立项管理立项建议立项评审项目筹备《立项建议书》《立项调查报告书》《立项可行性分析报告》《立项评审报告》结项管理结项管理《结项申请书》《结项评审报告》项目规划制定项目计划审批项目计划项目计划变更控制《项目计划》《项目计划变更控制报告》项目监控项目计划跟踪偏差控制项目进展总结《项目监控数据表》《项目偏差控制报告》《项目进展报告》风险管理风险管理《风险检查表》《风险管理报告》需求管理需求确认需求跟踪需求变更控制《需求跟踪报告》《需求变更控制报告》项目研发过程域主要规程文档模板需求开发需求调查需求分析需求定义《用户需求说明书》《产品需求规格说明书》技术预研技术预研《技术预研计划》《技术预研报告》

系统设计体系结构设计用户界面设计数据库设计模块设计《体系结构设计报告》《用户界面设计报告》《数据库设计报告》《模块设计报告》实现与测试实现与测试《实现与测试计划》《编程文档》系统测试系统测试《系统测试计划》《测试用例》《测试报告》客户验收客户验收《客户验收计划》《客户验收报告》技术评审正式技术评审非正式技术评审《技术评审计划》《技术评审报告》《技术评审检查表》机构支撑过程域规程与关键活动文档模板质量保证制定质量保证计划过程与产品质量检查问题跟踪与质量改进《质量保证计划》《质量保证检查表》《质量保证报告》《质量问题跟踪表》配置管理制定配置管理计划配置库管理版本控制变更控制《配置管理计划》《配置库管理报告》《配置项变更控制报告》培训管理机构培训管理项目培训管理《培训计划》《培训评估报告》服务与维护客户服务《客户服务计划》《客户服务报告》产品维护《产品维护计划》《产品维护报告》表1—2精简模型规范细分1。4精简模型角色与职责表精简模型的主要角色及其职责如表1-3所示（详见各个过程域对角色与职责的描述）.公司在应用精简模型时，可以将精简模型的各个角色映射到公司原有的岗位上，也可以依据精简模型角色建立新的岗位。一个人可以被赋予多个角色，视具体情况而定。职责简述常设角色

职责简述机构过程改进角色软件工程过程组（SEPG）（1）制定适合于本机构的过程规范。（2）在机构范围内推广该规范（如培训、考核），评估机构过程能力等。质量保证小组（QAG）（1）监督规范的实施，确保所有项目以及相关部门准照规范开展工作。（2）分析并解决机构内存在的共性质量问题,协组SEPG完善规范。项目管理过程角色机构领导（1） 是机构内所有项目的主管，对立项管理和结项管理有最终决策权 •（2） 监督项目经理的工作，审批项目经理的各种申请。项目经理（1）向机构领导汇报工作。（2）是项目规划、项目监控、风险管理和需求管理过程域的负责人。（3）监督项目成员的工作，审批项目成员的各种申请•项目研发过程角色需求分析员调查、分析并定义需求，撰写相应的需求文档，尽最大努力使需求文档能够正确无误地反映用户的真实意愿。系统设计师根据需求文档设计软件系统的体系结构、用户界面、数据库、模块等 ，并撰写相应的设计文档•程序员（1）根据系统设计文档，编写软件系统的代码。（2）随时测试和检查自己的代码，及时消除代码中的缺陷。测试员从事单元测试、集成测试和系统测试，主要工作包括制定测试计划、设计测试用例、执行测试和撰写测试报告。机构支撑过程角色配置管理员（1）为项目制定《配置管理计划》。（2）创建并维护配置库，如分配权限、清除垃圾文件、备份配置库等。质量保证员（即QAG成员）（1）为项目制定《质量保证计划》。（2）周期性的开展“过程与产品质量检查” •（3）跟踪质量问题，给出质量改进措施。培训管理员制定机构（或项目）的《培训计划》，监督该计划的实施，撰写《培训评估报告》.客户服务人员为客户提供与产品相关的服务（如技术咨询） ，快速响应客户的要求，给客户一个满意的解答•产品维护人员（1）纠错性维护：及时解决用户遇到的技术故障和消除产品中的缺陷。（2）完善性维护：在资源允许的情况下，不断改善产品功能与质量。临时角色职责说明立项建议小组（1）开展立项调查、产品构思和可行性分析，撰写相应文档。（2）申请立项，并在立项评审会议上答辩。立项评审委员会由机构领导、各级经理、市场人员、技术专家、财务人员等组成，委员会按少数服从多数原则投票决定是否同意立项。结项评审委员会对项目的有形资产和无形资产进行清算，对项目进行综合评估，总结经验教训等。结项委员会的人员组成与立项评审委员会的类似。技术评审委员会对工作成果进行正式技术评审，尽早地发现工作成果中的缺陷，并帮助开发人员及时消除缺陷•该委员会由项目内外的技术专家组成。配置控制委员会对配置管理各项活动拥有决策权（例如审批计划，审批变更请求等） 。表1—3精简模型的角色与职责简表1。5公司软件过程的政策1。5。1目标持续改进机构的软件过程能力，不断地提高产品质量、提高生产率并且降低开发成本。1.5。2机构领导的支持机构领导批准用于软件过程改进的必要经费,例如支付咨询费,购买相关软件工具等。机构领导组建SEPG和QAG，专门从事软件过程改进工作。SEPG的主要职责是建立适合于机构的过程规范，QAG的主要职责是监督该规范的实施。建议让SEPG和QAG的大部分人员重叠，这些人既是SEPG成员又是质量保证员，扮演两种角色.这样不仅节约人力资源，并且提高了工作效果（由制定规范的人去监督规范的实施最合适不过）。一般地，SEPG成员和质量保证员共占机构总人数的5％左右.机构领导不仅要口头支持，还要亲自参与软件过程改进的实践。例如参加培训和考试，准照过程规范执行立项管理和结项管理等.1。5。3质量管理的政策质量管理口号：“在开发过程之中内建质量而非修补质量”。质量管理有种基本措施:“质量保证”、“技术评审”和“测试”.一、 质量保证机构的质量保证员周期性地检查项目成员的“工作过程以及工作成果”是否符合既定的规范，来监控和改进“过程质量以及产品质量".机构的质量保证员独立于任何项目，并赋予他一定的权利，对质量不合格的工作成果作出处理。二、 技术评审在工作成果刚产生之际，对其进行技术评审（分正式或非正式两种），目的是尽早地发现工作成果中的缺陷,并帮助开发人员及时消除缺陷,从而提高产品的质量.如果时间允许的话，应当尽可能多地对产品的重要工作成果进行技术评审。技术评审活动由项目开发团队组织。三、测试测试是指通过运行测试用例（testcase）来找出软件中的缺陷。测试与技术评审的主要区别是前者要运行软件而后者不必运行软件.一般地，产品开发过程中有四个测试阶段:单元测试、集成测试、系统测试和验收测试。其中单元测试和集成测试可以由项目开发团队组织。系统测试阶段必须有项目外的人员参与,以保证系统测试的客观性。验收测试由客户组织。如果有条件的话 ,建议机构成立专门的测试小组从事单元测试、集成测试和系统测试工作。1.5。4质量保证小组的政策机构领导任命一位熟悉过程规范并且有丰富的质量管理经验的人担任QAG的负责人(或称为质量经理)。在机构领导的许可下，该负责人组建QAG(成员可以是全职的也可以是兼职的)。QAG在行政上独立于任何项目。这种独立性有助于质量保证员客观地检查和监控“过程以及产品的质量”。QAG准照SEPG制定的“质量保证规范”开展工作。机构领导赋予QAG一定的权利,可以对质量不合格的工作成果做出处理.这种权利使得QAG的工作不会被轻视，并有助于加强全员的质量意识。对于QAG与项目之间出现的难以调和的争议，由机构领导处理.1.5。5项目团队的政策项目中的任何管理人员、开发人员、测试人员等,必须学习与本职工作相关的过程规范，每个人都必须明白自己“应当在什么时候依据什么规范做什么事情”。项目经理应当树立榜样,并且督促项目成员们按规范做事。允许项目经理根据本项目的特征，在SEPG和QAG的指导下,适当地裁剪或扩充机构的过程规范，从而快速建立本项目的过程规范。这项工作应当在“项目规划过程域”中完成，并在《项目计划》中体现出来。如果项目对机构过程规范的裁剪幅度比较大，遭到QAG的反对，如果双方不能达成共识，则由机构领导处理该争议。SEPG对项目过程能力的评估成绩将作为评定项目人员工作业绩的重要因素，具体比重由机构领导决定，建议占30％以上的比重。立项管理参见《项目管理制度试行V2.1版本》项目规划在立项管理过程域的项目筹备阶段,机构领导首先任命一位项目经理,之后机构领导协助项目经理筹备项目经费、人力资源、软件硬件资源等。如果必要的资金和资源已经到位，那么项目经理和核心成员即可组成一个项目规划小组,着手制定《项目计划》并按计划执行研发和管理工作。项目的计划书可分两类：一是全局的计划书(OverallPlan),这里称为《项目计划》二是一些下属计划书(SubordinatePlan)，例如《配置管理计划》、《质量保证计划》、一些开发计划和测试计划等。下属计划书是对《项目计划》的补充,其内容不可与《项目计划》冲突。通常《项目计划》由项目经理负责制定，由机构领导审批.而下属计划书一般由项目成员制定，由项目经理审批即可。

项目计划过程域有3个主要规程:“制定项目计划”、“审批项目计划”和“项目计划变更控制”，流程如图3-1所示。图3—1项目规划流程图项目监控项目监控（ProjectMonitoringandControl，PMC）的目的是通过周期性地跟踪项目计划的各种参数如进度、工作量、费用、资源、工作成果等，不断地了解项目的进展情况,以便当项目实际进展状况显著偏离计划时能够及时采取纠正措施.本规范阐述了项目监控过程域的三个主要规程:◊项目计划跟踪◊控制偏差◊项目进展汇报图4-1项目监控流程4.1项目计划跟踪周期性的跟踪任务（含进度和工作量）、费用、资源、工作成果等，及时了解项目的实际进展情况。为持续过程改进提供有价值的数据。4.1.1任务跟踪项目经理（或其指定的项目成员）周期性地（如每周一次）跟踪每个重要的任务，将采集的数据保存在《项目监控数据表》之中.任务跟踪表的参考格式如表4—1所示。任务名称实际起止时间跟踪日期、当前进度实际工作量实际工作成果

表4—1任务跟踪表4.1。2费用跟踪项目经理（或其指定的项目成员）周期性地跟踪项目费用，将采集的数据保存在《项目监控数据表》之中.费用跟踪表的参考格式如表4—2所示。4.1。3资源跟踪项目经理（或其指定的项目成员）周期性地跟踪软硬件资源，将采集的数据保存在《项目监控数据表》之中.资源跟踪表的参考格式如表4-3所示.软硬件资源名称级别实际配置获取方式与时间使用说明关键关键普通普通表4—3资源跟踪表4.1。4工作成果及其规模跟踪项目经理（或其指定的项目成员）周期性地跟踪工作成果及其规模,将采集的数据保存在《项目监控数据表》之中。工作成果跟踪表的参考格式如表 4—4所示.工作成果名称新开发的成果规模（代码行、类、文档页数）复用或自动生成的成果规模（代码行、类、文档页数）工作成果1工作成果2总和表4—4工作成果及其规模跟踪表

4.2控制偏差对比“项目实际进展”和“项目计划”,分析偏差,如果发现项目实际进展显著偏离计划，则及时采取纠正措施。4。3项目进展汇报周期性地汇报项目进展情况。项目经理周期性地总结项目进展情况，撰写《项目进展报告》并通报给机构领导和所有项目成员。基本信息项目名称报告日期项目编号报告批次第N份项目经理项目所处阶段项目进展状况计划实际情况任务与进度工作成果费用人力资源软硬件资源问题与对策表4—6项目进展报告风险管理风险管理(RiskManagement,RiskM)的目的是在风险产生危害之前识别它们，从而有计划地消除或削弱风险。所有可能危害项目的因素都称为风险。被刻画为风险的事件最终可能发生也可能不发生.人们对待风险有两种态度。一种是被动态度,可比作“救火模式”。另一种是主动态

度,可比作“防火模式”.风险管理属于“防火模式”，目的就是“防止风险产生真正的危害”。为了便于量化管理，我们给风险定义3个参数：◊风险严重性：指风险对项目造成的危害程度。◊风险可能性：指风险发生的几率。◊风险系数:是风险严重性和风险可能性的乘积。参数等级值描述风险严重性很高5例如进度延误大于30%，或者费用超支大于30%。比较高4例如进度延误20%~30%，或者费用超支20%〜30%。中等3例如进度延误低于20%，或者费用超支低于20%.比较低2例如进度延误低于10%，或者费用超支低于10%。很低1例如进度延误低于5%，或者费用超支低于5%。表5-1风险严重性等级参数等级值描述风险可能性很高5风险发生的几率为1.0〜0.8比较高4风险发生的几率为0。8〜0。6中等3风险发生的几率为0.6~0.4比较低2风险发生的几率为0.4〜0.2很低1风险发生的几率为0.2〜0。0表5—2风险可能性等级风险系数风险可能性很高5比较高4中等3比较低2很低1风险严重性很高5252015105比较高420161284中等 31512963比较低2108642很低 154321本表灰色部分的风险系数值为10~25，应当优先处理。表5-3风险系数等级风险严重性的等级划分如表5—1所示，风险可能性的等级划分如表5-2所示，风险系数的等级划分如表3所示。风险管理有4个主要活动：风险识别：根据风险检查表，识别出本项目的风险。风险分析：估计风险严重性、风险可能性、风险系数。风险减缓：对于风险系数超过“容许值”的每一个风险,都应当采取减缓措施。风险跟踪:跟踪风险减缓过程，记录风险的状态.

在项目的生命周期内,上述4个活动将被循环执行，如图5-1所示。直到项目的所有风险都被识别与解决为止。常用的《风险检查表》，使用者应根据实际情况进行适当的删减或补充。风险管理过程域产生的主要文档是《风险管理报告》.商业风险风险类型检查项政治法律市场政府或者其他机构对本项目的开发有限制吗？有不可预测的市场动荡吗？有不利于我方的官司要打吗？本产品销售后在使用过程中可能导致发生重大的损失或伤亡事故吗 ？竞争对手有不正当的竞争行为吗？本产品销售后在使用过程中可能导致发生重大的损失或伤亡事故吗 ？是否在开发很少有人真正需要却自以为很好的产品？是否在开发可能亏本的产品？客户客户的需求是否含糊不清？客户是否反反复复地改动需求？客户指定的需求和交付期限在客观上可行吗？客户对产品的健壮性、可靠性、性能等质量因素有非常过分的要求吗？客户的合作态度友善吗？与客户签的合同公正吗？双方互利吗？客户的信誉好吗？例如按客户的需求开发了产品，但是客户可能不购买。子承包商供应商与子承包商、供应商签订的合同公正吗？双方互利吗？子承包商、供应商的信誉好吗？子承包商、供应商有可能倒闭吗？子承包商、供应商能及时交付质量合格的产品（或部件）吗？子承包商、供应商有能力做好售后服务吗？管理风险风险类型检查项项目计划对项目的规模、难度估计是否比较正确？

人力资源（开发人员、管理人员）够用吗？合格吗？项目所需的软件、硬件能按时到位吗？项目的经费够用吗？进度安排是否过于紧张？有合理的缓冲时间吗？进度表中是否遗忘了一些重要的（必要的）任务？进度安排是否考虑了关键路径？是否可能出现某一项工作延误导致其他一连串的工作也被延误？任务分配是否合理？（即把任务分配给合适的项目成员，充分发挥其才能）是否为了节省钱，不采用（购买）成熟的软件模块，一切从零做起？••・项目团队项目成员团结吗？是否存在矛盾？是否绝大部分的项目成员对工作认真负责？绝大部分的项目成员有工作热情吗？团队之中有“害群之马”吗？技术开发队伍中有临时工吗？本项目开发过程中是否会有核心人员辞职、调动？是否能保证“人员流动基本不会影响工作的连续性”？项目经理是否忙于行政事务而无暇顾及项目的开发工作？上级领导行政部门合作部门本项目是否得到上级领导的重视？上级领导是否随时会抽调本项目的资源用于其他“高优先级”的项目？上级领导是否过多地介入本项目的事务并且瞎指挥？行政部门的办事效率是否比较底，以至于拖项目的后腿？行政部门是否经常干一些无益于生产力的事情，以至于骚扰本项目 ？机构是否能全面、公正地考核员工的工作业绩？机构是否有较好的奖励和惩罚措施？本项目的合作部门的态度积极吗？是否应付了事？或者做事与承诺的不一致？技术风险风险类型检查项需求开发需求管理需求开发人员懂得如何获取用户需求吗？效率高吗？需求开发人员懂得项目所涉及的具体业务吗？能否理解用户的需求？需求文档能够正确地、完备地表达用户需求吗？需求开发人员能否与客户对有争议的需求达成共识？需求开发人员能否获得客户对需求文档的承诺？以保证客户不随便变更需求？综合技术开发能力包括设计编程、测试等开发人员是否有开发相似产品的经验？待开发的产品是否要与未曾证实的软硬件相连接？对开发人员而言，本项目的技术难度高吗？开发人员是否已经掌握了本项目的关键技术？如果某项技术尚未实践过，开发人员能否在预定时间内掌握？

开发小组是否采用比较有效的分析、设计、编程、测试工具 ？分析与设计工作是否过于简单、草率，从而让程序员边做边改 ？开发小组采用统一的编程规范吗？开发人员对测试工作重视吗？能保证测试的客观性吗 ？项目有独立的测试人员吗？懂得如何进行高效率地测试吗？是否对所有重要的工作成果进行了同行评审（正式评审或快速检查）？开发人员懂得版本控制、变更控制吗？能够按照配置管理规范执行吗？开发人员重视质量吗？是否会在进度延误时降低质量要求？表5—4风险检查表风险名称风险识别人风险编号风险识别日期风险描述风险严重性风险系数风险可能性风险处理人风险减缓措施跟踪记录（1）记录何人在何时做了什么事情（2）记录当前风险状态（正在处理，已经解决，不作处理）表5-5风险管理报告需求管理需求管理（RequirementManagement,RM）的目的在客户与开发方之间建立对需求的共同理解，维护需求与其他工作成果的一致性，并控制需求的变更。需求管理过程域的三个主要规程:需求确认需求跟踪需求变更控制图6-1需求工程结构图6.1需求确认项目经理邀请同行专家和用户（包括客户和最终用户）一起评审需求文档，尽最大努力使需求文档能够正确无误地反映用户的真实意愿。当需求文档通过正式的评审之后，开发方负责人（项目经理）和客户对需求文档作书面承诺，使之具有商业合同效果。示例如下：本需求文档建立在双方对需求的共同理解基础之上,我同意后续的开发工作根据该需求文档开展.如果需求发生变化，我们将按照“需求变更控制规程”执行。我明白需求的变更将导致双方重新协商成本、资源和进度等.甲方负责人签字乙方负责人签字评审结束输出《需求评审报告》,书面的需求承诺需求评审报告摘要需求文档输入名称，标识符，版本，作者，完成日期，…需求评审报告输入名称,标识符，评审日期,...评审结论:］工作成果合格，“无需修改”或者“需要轻微修改但不必再审核” •［丿］工作成果基本合格，需要作少量的修改，之后通过审核即可。:］工作成果不合格，需要作比较大的修改，之后必须重新对其评审。评审意见评审小组成员输入评审小组成员表6—1需求评审报告需求承诺需求文档输入名称,标识符，版本，作者，完成日期客户承诺承诺…签字，日期项目经理承诺承诺…签字，日期表6-2需求承诺6。2需求跟踪将系统设计、编程、测试等阶段的工作成果与需求文档进行比较，建立与维护“需求文档－设计文档－代码－测试用例"之间的一致性，确保产品依据需求文档进行开发。项目经理跟踪需求.建立与维护需求跟踪矩阵：正向跟踪。检查需求文档中的每个需求是否都能在后续工作成果中找到对应点。逆向跟踪•检查设计文档、代码、测试用例等工作成果是否都能在需求文档中找到出处.正向跟踪和逆向跟踪合称为“双向跟踪”。不论采用何种跟踪方式，都要建立与维护需求跟踪矩阵（即表格）•需求跟踪矩阵保存了需求与后续工作成果的对应关系。矩阵单元之间的可能存在“一对一"、“一对多”或“多对多"的关系。由于对应关系比较复杂，最好在表格中加必要的文字解释。表6—3为简单的需求跟踪矩阵格式。•当需求文档或后续工作成果发生变更时，要及时更新需求跟踪矩阵。#需求文档（版本，日期）设计文档（版本，日期）代码（版本，日期）测试用例（版本，日期）1标题或标识符，说明标题或标识符，说明代码名称，说明测试用例名称，说明2表6-3简单的需求跟踪矩阵格式6.3需求变更控制修改“原需求文档”中不正确的内容,产生新的需求文档。控制需求文档的变更，防止发生混乱。补充说明：本规程中的“原需求文档"是指已经通过了评审并获得书面承诺的需求文档。开发方负责人（项目经理）和客户共同控制需求变更。需求变更申请申请变更的需求文档输入名称，版本，日期等信息变更的内容及其理由

评估需求变更将对项目造成的影响申请人签字变更申请的审批意见项目经理签字审批意见：签字，日期客户签字（合同项目）审批意见：签字，日期更改需求文档变更后的需求文档输入名称,版本，完成日期等信息更改人签字重新评审需求文档需求评审小组签字评审意见：签字，日期变更结束项目经理签字签字日期：表6-4需求变更控制报告结项管理结项管理（ProjectClosingManagement，PCM）是指在项目开发工作结束后,对项目的有形资产和无形资产进行清算;对项目进行综合评估;总结经验教训等。立项管理与结项管理是前后呼应的两个过程域，使得项目管理过程“有始有终 "。项目结束有两种状况:一是正常结束，二是异常结束。前者是指项目按预定计划结束。后者原因有多种，归根结底都是由于该项目不再符合机构的最大利益。例如有些项目因不适应市场而被中途淘汰，有些项目在执行过程中大大因偏离计划（如进度延误、费用超支）而被取消。不论项目属于正常结束还是异常结束，都要按照结项管理规范处理。国内很多项目普遍存在“虎头蛇尾”的现象，结项管理畸变成了“走过场，吃顿饭”，这是非常有害的。有价值的结项管理至少包括三项内容：对项目的有形资产和无形资产进行清算，既要防止资产流失，又要及时地利用这些资产.对项目进行综合评估。例如评估项目完成情况、项目质量、投入产出分析、项目的市场价值、项目对企业的贡献等等.该评估报告可以作为考核项目人员业绩的重要依据。总结经验教训，使整个机构受益。结项管理的流程如图7—1所示，产生的主要文档有：需求开发需求开发(RequirementDevelopment,RD)的目的是通过调查与分析，获取用户需求并定义产品需求。本规范阐述了需求开发过程域的两个主要规程：需求调查需求定义需求开发与需求管理是相辅相成的两类活动，它们共同构成完整的需求工程。需求工程结构图如图6—1所示，需求开发和需求管理的流程如图8-1所示。求分析”则贯穿于上述两个阶段。需求调查阶段和需求定义阶段在逻辑上存在先后关系，实际工作中二者通常是迭代进行的。我们把从事需求开发工作的人员称为需求分析员（也叫系统分析员）,避免与其它开发人员混淆。一、需求调查需求调查的目的是通过各种途径获取用户的需求信息（原始材料），产生《用户需求说明书》.二、需求分析需求分析的目的是对各种需求信息进行分析,消除错误,刻画细节等.常用的需求分析方法有“问答分析法”、“结构化分析法"和“面向对象分析法”。三、需求定义需求定义的目的是根据需求调查和需求分析的结果，进一步定义准确无误的产品需求，产生《产品需求规格说明书》。系统设计人员将依据《产品需求规格说明书》开展系统设计工作.需求开发过程域产生的主要文档有:技术预研技术预研（TechnicalPre-Research，TPR）是指在立项之后到开发工作完成之前的时间内对项目将采用的关键技术提前学习和研究,以便尽可能早地发现并解决开发过程中将会遇到的技术障碍。在产品开发过程中,技术问题可能会层出不穷。如果一点技术障碍都没有遇到，要么是开发人员的技术水平实在太高了，要么是项目的技术含量实在太低了，这类情况比较少见一般说来，在设计或实现阶段遇到了技术障碍，才去攻克问题，其代价通常比较高。因为其他人的工作可能会被阻塞，已经投入的不少资源将被闲置•最糟糕的是，如果此技术障碍无法攻克，不得已要改变技术方案、重新设计系统，那么不仅浪费了人力、财力、时间，处理不好还会使开发队伍陷入混乱状态。所以开展技术预研工作至少有两大好处：◊帮助开发人员更好地进行需求开发、系统设计和程序设计。◊防止开发进程被技术障碍打断，导致大量的相关工作被阻塞。技术预研的流程如图9—1所示。图9-1技术预研流程技术预研过程中产生的主要文档有：10系统设计系统设计(SystemDesign,SD)是指设计软件系统的体系结构、用户界面、数据库、模块等，从而在需求与代码之间建立桥梁，指导开发人员去实现能满足用户需求的软件产品•本规范阐述了系统设计过程域的四个主要规程：体系结构设计用户界面设计数据库设计模块设计系统设计过程域分为两个阶段：高层设计阶段和详细设计阶段•高层设计阶段的重点是软件系统的体系结构设计 •详细设计阶段的重点是用户界面设计、数据库设计和模块设计，如图10—1所示。图10-1系统设计过程域示意图系统设计过程域产生的主要文档有:《体系结构设计报告》《用户界面设计报告》《数据库设计报告》《模块设计报告》10.1体系结构设计分析与设计软件的体系结构。通过系统分解,确定子系统的功能和子系统之间的关系，以及模块的功能和模块之间的关系,产生《体系结构设计报告》.项目经理指定若干名开发人员从事体系结构设计（以下称为体系结构设计人员）体系结构设计流程如图10-2所示.图10—2体系结构设计流程10。2用户界面设计设计软件的用户界面，产生《用户界面设计报告》。制作用户界面的资源如图像、图标或者界面专用组件等项目经理指定若干名开发人员从事用户界面设计（以下称为界面设计人员）如果可能的话，邀请用户或美工人员协助设计用户界面。用户界面设计流程如图10—3所示。Stepl。设计准备Step2。 界面设计2.1原型创作2.2原型评估Stepl。设计准备Step2。 界面设计2.1原型创作2.2原型评估2。3细化迭代Step3。Step4.撰写 ►设计文档评审图10—3体系结构设计流程10.3数据库设计设计软件的数据库，产生《数据库设计报告》。项目经理指定若干名开发人员从事数据库设计（以下称为数据库设计人员）10。4模块设计设计软件所有模块的主要接口与属性、数据结构和算法，产生《模块设计报告》。项目经理指定若干名开发人员从事模块的设计（以下称为模块设计人员），模块设计人员将在实现阶段编写这些模块的代码。模块设计流程如图10-5所示.

图10—5模块设计流程11实现与测试实现与测试（ImplementationandTest，IT）的目的是依据系统设计文档,编写并测试整个系统的代码。在本规范中，实现与测试是“编程、代码审查、单元测试、集成测试、缺陷管理与改错”的综合表述。实现与测试的流程如图11—1所示。一般地,编程、代码审查、单元测试、集成测试大致存在先后顺序关系，也可以并行、迭代地开展。上述任何活动中发现的缺陷必须用统一的缺陷管理工具来管理，开发人员应当及时消除缺陷（改错）。图11-1实现与测试流程图由于实现与测试是工作量最大、时间最长、产生工作成果（代码与文档）最多的一个项目研发过程域，所以需要作充分的准备工作。实现与测试工作基本上在开发小组内部开展.一个项目可能有一个或者多个开发小组。对于小型项目，项目经理可以兼任开发组长。特别要注意的是，开发人员应当对自己的代码进行审查和测试 （这是份内的工作），但是不能作为该代码已经通过审查和测试的依据。所以开发人员还要互相审查和测试同伴的代码。实现与测试过程域产生的主要文档有：《实现与测试计划》《编程文档》《代码审查报告》《测试用例》《测试报告》《缺陷管理报告》（由缺陷管理工具自动生成）一个项目可能有多个开发小组，视项目规模而定.开发组长由项目经理指定开发组长管理编程、代码审查、单元测试、集成测试、缺陷管理与改错等活动12系统测试系统测试（SystemTest,ST）的目的是对最终软件系统进行全面的测试，确保最终软件系统满足产品需求并且遵循系统设计。系统测试流程如图12-1所示。由于系统测试的目的是验证最终软件系统满足产品需求并且遵循系统设计，所以当产品需求和系统设计文档完成之后，系统测试小组就可以提前开始制定测试计划和设计测试用例，而不必等到“实现与测试"阶段结束。这样可以提高系统测试的效率.系统测试过程中发现的所有缺陷必须用统一的缺陷管理工具来管理，开发人员应当及时消除缺陷（改错）。审批 审批 迭代 图12—1系统测试流程图项目经理设法组建富有成效的系统测试小组。系统测试小组的成员主要来源于:机构独立的测试小组（如果存在的话）.邀请其它项目的开发人员参与系统测试。本项目的部分开发人员.机构的质量保证人员.系统测试小组应当根据项目的特征确定测试内容。一般地，系统测试的主要内容包括：功能测试.即测试软件系统的功能是否正确，其依据是需求文档，如《产品需求规格说明书》。由于正确性是软件最重要的质量因素，所以功能测试必不可少。健壮性测试。即测试软件系统在异常情况下能否正常运行的能力。健壮性有两层含义:一是容错能力，二是恢复能力。性能测试。即测试软件系统处理事务的速度，一是为了检验性能是否符合需求，二是为了得到某些性能数据供人们参考(例如用于宣传)。用户界面测试。重点是测试软件系统的易用性和视觉效果等。安全性(security)测试。是指测试软件系统防止非法入侵的能力。“安全”是相对而言的，一般地，如果黑客为非法入侵花费的代价(考虑时间、费用、危险等因素)高于得到的好处,那么这样的系统可以认为是安全的.安装与反安装测试。系统测试过程域产生的主要文档有:《系统测试计划》《系统测试用例》《系统测试报告》《缺陷管理报告》对最终软件系统进行全面的测试，确保最终软件系统满足产品需求并且遵循系统设计。项目经理组建系统测试小组，并指定一名成员任测试组长.系统测试小组各成员共同制定测试计划、设计测试用例、执行测试，并撰写相应的文档.测试组长管理上述事务。开发人员及时消除测试人员发现的缺陷。13客户验收客户验收(CustomerAcceptance，CA)是指客户依据合同对产品进行审查和测试，确保产品满足客户需求。客户对产品的验收主要有两种方式：成果审查。验收人员审查开发方应当交付的成果,如代码、文档等等。确保这些成果是完整的并且是正确的.验收测试。验收人员对待交付的产品进行全面的测试，确保产品功能、质量符合需求。验收测试的内容、方法与系统测试几乎是相同的。两者主要区别在于执行人员不同.验收测试人员来自于客户方，而系统测试人员则来自于开发方。客户验收流程如图13-1所示.验收准备―►成果审查与验收测试—问题处理——>交付与签字图13-1客户验收流程客户验收过程域产生的主要文档有：◊《客户验收计划》《验收测试用例》《客户验收报告》补充说明：“客户验收"是针对合同项目而言的14技术评审技术评审（TechnicalReview，TR）的目的是尽早地发现工作成果中的缺陷，并帮助开发人员及时消除缺陷，从而有效地提高产品的质量.本规范阐述了技术评审过程域的三个主要规程：◊制定技术评审计划◊正式技术评审◊非正式技术评审技术评审能够在任何开发阶段执行，它可以比测试更早地发现并消除工作成果中的缺陷.技术评审的主要好处有：◊通过消除工作成果的缺陷而提高产品的质量.◊越早消除缺陷就越能降低开发成本。◊开发人员能够及时地得到同行专家的帮助和指导 ,无疑会加深对工作成果的理解，更好地预防缺陷，一定程度上提高了开发生产率。可见技术评审有助于“提高质量、提高生产率、降低成本”,符合软件过程改进的根本目的.技术评审有两种基本类型:正规技术评审（FTR）。FTR比较严格，需要举行评审会议，参加评审会议的人员比较多。非正规技术评审（ITR）。ITR的形式比较灵活，通常在同伴之间开展，不必举行评审会议,评审人员比较少。理论上讲，为了确保产品的质量,产品的所有工作成果都应当接受技术评审.现实中为了节约时间，允许人们有选择地对工作成果进行技术评审。技术评审方式也视工作成果的重要性和复杂性而定。技术评审过程域有三个主要规程:“制定技术评审计划”、“正规技术评审”和“非正规技术评审"，如图14—1所示。图14-1技术评审过程域示意图技术评审的注意事项：◊评审人员的职责是发现工作成果中的缺陷，并帮助开发人员给出消除缺陷的办法,而不是替开发人员消除缺陷。技术评审应当“就是论事”不要打击有失误的开发人员的工作积极性，更不准搞人身攻击(如挖苦、讽刺等)。在会议评审期间要限制过多的争论，以免浪费他人的时间。技术评审过程域产生的主要文档有:《技术评审计划》《技术评审通知》《技术评审报告》《技术评审检查表》15配置管理配置管理(ConfigurationManagement,CM)的目的是通过执行版本控制、变更控制等规程，以及使用配置管理软件，来保证所有配置项的完整性和可跟踪性。配置管理是对工作成果的一种有效保护。本规范阐述了配置管理过程域的四个主要规程:制定配置管理计划◊配置库管理◊配置项版本控制◊配置项变更控制项目研发和管理过程中会产生许许多多的工作成果，例如文档、程序和数据等，它们都应当被保存起来，以便查阅和修改。如果把所有文件一股脑地塞进计算机里，那么使用起来肯定很麻烦。毫无疑问，人们应当将文件分门别类、有条理地保存起来。凡是纳入配置管理范畴的工作成果统称为配置项(ConfigurationItem，CI)，配置项主要有两大类:(1)属于产品组成部分的工作成果，例如需求文档、设计文档、源代码、测试用例 等(2)项目管理和机构支撑过程域产生的文档。这些文档虽然不是产品的组成部分，但是值得保存。每个配置项的主要属性有:名称、标识符、文件状态、版本、作者、日期等.所有配置项都被保存在配置库里，确保不会混淆、丢失。配置项及其历史记录反映了软件的演化过程。基线(Baseline)由一组配置项组成，这些配置项构成了一个相对稳定的逻辑实体。基线中的配置项被“冻结”了,不能再被任何人随意修改(见变更控制规程)。基线通常对应于开发过程中的里程碑(Milestone)，一个产品可以有多个基线，也可以只有一个基线.基线的主要属性有：名称、标识符、版本、日期等。通常将交付给客户的基线称为一个“Release”,为内部开发用的基线则称为一个“Build”。所有的项目成员都要使用配置管理软件来保护自己的工作成果。机构应当采用统一的配置管理软件，常见的配置管理软件有Microsoft的VisualSourceSafe和Rational的ClearCase等.为了提高配置管理的效率和安全性，机构应当有专门的配置管理员（角色）.配置管理员为每个项目制定《配置管理计划》，创建和维护配置库。鉴于配置管理的重要性和复杂性，机构还应当设立配置控制委员会（ConfigurationControlBoard,CCB）.CCB是个虚拟小组,对配置管理各项活动拥有决策权（例如审批计划，审批变更请求等）。对于配置管理而言，CCB是决策者，而配置管理员是执行者。如果机构的各个项目紧密相关（例如一个产品线下的多个项目）,建议机构设立公共的CCB，这个公共的CCB对所有项目的配置管理拥有决策权.如果机构的各个项目相对独立，那么每个项目可以设立各自的CCB。CCB的决策采用“少数服从多数”原则。配置管理的流程如图15—1所示。一、制定配置管理计划配置管理员制定《配置管理计划》，主要内容包括配置管理软硬件资源、配置项计划、基线计划、交付计划、备份计划等。CCB审批该计划。二、配置库管理配置管理员为项目创建配置库，并给每个项目成员分配权限。各项目成员根据自己的权限操作配置库。配置管理员定期维护配置库，例如清楚垃圾文件、备份配置库等。三、版本控制在项目开发过程中,绝大部分的配置项都要经过多次的修改才能最终确定下来。对配置项的任何修改都将产生新的版本.由于我们不能保证新版本一定比老版本“好",所以不能抛弃老版本。版本控制的目的是按照一定的规则保存配置项的所有版本，避免发生版本丢失或混淆等现象,并且可以快速准确地查找到配置项的任何版本。配置项的状态有三种：“草稿”、“正式发布"和“正在修改”,本规程制定了配置项状态变迁与版本号的规则。四、变更控制 在项目开发过程中，配置项发生变更几乎是不可避免的。变更控制的目的就是为了防止配置项被随意修改而导致混乱。修改处于“草稿”状态的配置项不算是“变更”，无需CCB的批准，修改者按照版本控制规则执行即可.当配置项的状态成为“正式发布”，或者被“冻结"后，此时任何人都不能随意修改，必须依据“申请－审批－执行变更－再评审－结束”的规则执行。五、配置审计为了保证所有人员（包括项目成员、配置管理员和CCB）都遵守配置管理规范,质量保证人员要定期审计配置管理工作。配置审计是一种“过程质量检查”活动，是质量保证人员的工作职责之一。配置管理过程域产生的主要文档有：《配置管理计划》《配置库管理报告》《配置项变更控制报告》16质量保证质量保证（QualityAssurance，QA）的目的是提供一种有效的人员组织形式和管理方法，通过客观地检查和监控“过程质量”与“产品质量 ",从而实现持续地改进质量。质量保证是一种有计划的、贯穿于整个产品生命周期的质量管理方法。本规范阐述了质量保证过程域的三个主要规程：制定质量保证计划过程与产品质量检查◊问题跟踪与质量改进过程质量与产品质量存在某种程度的因果关系，通常“好的过程”产生“好的产品"而“差的过程”将产生“差的产品”。人们销售的是产品而不是过程，用户关心的是最终产品的质量，而开发者（团队）既要关心过程质量又要关心产品质量.提高产品质量有三种基本方法：质量保证。质量保证人员通过有计划地检查“工作过程以及工作成果"是否符合既定的规范，来监控和改进“过程质量”与“产品质量"。技术评审。请同行专家、技术人员对工作成果进行评审，尽早发现工作成果中的缺陷。◊测试。通过运行测试用例来找出软件中的缺陷。例如单元测试、集成测试、系统测试、验收测试等。质量保证既关心过程质量又关心产品质量。如果“工作过程以及工作成果”不符合既定的规范，那么产品的质量肯定有问题。基于这样的推理，质量保证人员即使不是技术专家，他也能够客观地检