软件研发管理系统规章制度.doc

《软件研发管理系统规章制度.doc》由会员分享，可在线阅读，更多相关《软件研发管理系统规章制度.doc（43页珍藏版）》请在三一文库上搜索。

1、word软件研发管理制度文件状态： 草稿 正式发布 正在修改文件标识：Lolaage-Software-PM当前版本：作 者：宋孝光完成日期：2012/3/27版本/状态作者参与者修改日期备注宋孝光2012/3/26第一版草稿宋孝光2012/3/27整理目录目录1 软件研发制度综述31.1 精简模型31.2 精简过程域的目的41.3 精简模型文档结构与规X细分51.4 精简模型角色与职责表61.5 公司软件过程的政策81.5.1 目标81.5.2 机构领导的支持81.5.3 质量管理的政策81.5.4 质量保证小组的政策91.5.5 项目团队的政策92 立项管理93 项目规划94 项目监控10

2、项目计划跟踪114.1.1 任务跟踪11费用跟踪11资源跟踪11工作成果与其规模跟踪124.2 控制偏差124.3 项目进展汇报135 风险管理146需求管理186.1 需求确认186.2 需求跟踪206.3 需求变更控制207 结项管理228需求开发239 技术预研2410 系统设计25体系结构设计26用户界面设计26数据库设计2710.4 模块设计2811 实现与测试2812 系统测试3013 客户验收3114 技术评审3215 配置管理3316 质量保证3517 培训管理3718 服务与维护381 软件研发制度综述1.1精简模型“精简模型是基于CMMI以与软件工程和项目管理知识而创作的一

3、种“软件过程改良方法和规X，它由众多的过程规X和文档模板组成。精简模型把产品生命周期划分为6个阶段，分别为： 产品概念阶段 产品定义阶段 产品开发阶段 产品测试阶段 用户验收阶段 产品维护阶段在精简模型中，软件项目的过程有三大类：项目管理过程、项目研发过程和机构支持过程。上述三类过程可以细分为17个主要过程域，分布在产品生命周期的各个阶段。项目管理过程包含6个过程域，分别为： 立项管理 结项管理 项目规划 项目监控 风险管理 需求管理项目研发过程包含7个过程域，分别为： 需求开发 技术预研 系统设计 实现与测试 系统测试 客户验收 技术评审机构支撑过程包含4个过程域，分别为： 配置管理 质量保

4、证 培训管理 服务与维护精简模型如图1-1所示。精简模型的主要特征和优点有：一、直观的过程模型精简模型将项目管理、项目研发、机构支撑所包含的工作划分为相对独立的三类过程，各个过程域之间的关系直观明了。这样，机构领导、项目经理、开发人员、测试人员、质量保证人员等人根据精简模型，很容易知道自己“应该在什么时候、按照什么规X做什么事情。所以精简模型有助于使机构内的各个职能单位有条不紊地开展工作。二、容易裁剪与扩大精简模型的三类过程贯穿了产品的整个生命周期，17个最常见的过程域都合理地安排在产品生命周期中的某些阶段。用户可以根据自己产品的特征，适当地裁剪或扩大精简的过程域，很容易制定出最适合于本产品的

5、过程模型。39 / 43客户验收根据产品特征确定最适宜的开发模型，以线性顺序为主，以并行、迭代为辅。并行、迭代配置管理 质量保证 培训管理其它： 人力资源管理 财务管理 行政管理 市场营销 技术预研服务与维护系统测试技术评审实现与测试需求开发系统设计结项管理项目监控 风险管理 需求管理产品维护客户验收产品测试产品开发项目规划立项管理产品定义产品概念机构支撑过程项目研发过程项目管理过程图1-1 精简模型1.2 精简过程域的目的精简模型 所有17个过程域的目的如表1-1所示。项目管理过程域目的立项管理采纳符合机构最大利益的立项建议，通过立项管理使该建议成为正式的项目。杜绝不符合机构最大利益的立项建

6、议被采纳，防止浪费机构的资源、资金、时间等。结项管理在项目开发工作完毕后，对项目的有形资产和无形资产进展清算、对项目进展综合评估以与总结经验教训等。项目规划为项目的研发和管理工作制定合理的行动纲领即项目计划，以便所有相关人员按照该计划有条不紊地开展工作。项目监控周期性地跟踪项目计划的各种参数如进度、工作量、费用、资源等，不断地了解项目的进展情况，以便当项目实际进展显著偏离计划时能够与时采取纠正措施。风险管理在风险产生危害之前识别它们，从而有计划地消除或削弱风险。需求管理在客户与开发方之间建立对需求的共同理解，维护需求与其它工作成果的一致性，并控制需求的变更。项目研发过程域目的需求开发通过调查与

7、分析，获取用户需求并定义产品需求。技术预研在立项之后到开发工作完成之前的时间内，对项目将采用的关键技术提前学习和研究，尽可能早地发现并解决开发过程中将会遇到的技术障碍。系统设计设计软件系统的体系结构、用户界面、数据库、模块等，从而在需求与代码之间建立桥梁，指导开发人员去实现能满足用户需求的软件产品。实现与测试依据系统设计文档，编写并测试整个系统的代码。在精简模型中，实现与测试是“编程、代码审查、单元测试、集成测试、缺陷管理与改错的综合表述。系统测试对最终系统进展全面的测试，确保最终系统满足产品需求并且遵循系统设计。客户验收客户依据合同对产品进展审查和测试，确保产品满足客户需求。技术评审尽早地发

8、现工作成果中的缺陷，并帮助开发人员与时消除缺陷，从而有效地提高产品的质量。机构支撑过程域目的配置管理通过执行版本控制、变更控制等规程，以与使用配置管理软件来保证所有配置项的完整性和可跟踪性。配置管理是对工作成果的一种有效保护。质量保证提供一种有效的人员组织形式和管理方法，通过客观地检查和监控“过程质量与“产品质量，从而实现持续地改良质量。培训管理根据机构或项目的需求来制定培训计划，并监视该计划的实施，确保培训取得预期效果。服务与维护是指产品销售之后的客户服务和产品维护，其宗旨是提高客户对产品以与对开发方的满意度。表1-1 精简过程域的目的1.3 精简模型 文档结构与规X细分精简模型的文档结构如

9、图1-2所示，SPP包含17个过程域，规X细分如表1-2所示。过程域过程改良政策文档模板规程图 1-2 精简模型 文档结构项目管理过程域主要规程文档模板立项管理立项建议立项评审项目筹备立项建议书立项调查报告书立项可行性分析报告立项评审报告使用现有的规X结项管理结项管理结项申请书结项评审报告项目规划制定项目计划审批项目计划项目计划变更控制项目计划项目计划变更控制报告项目监控项目计划跟踪偏差控制项目进展总结项目监控数据表项目偏差控制报告项目进展报告风险管理风险管理风险检查表风险管理报告需求管理需求确认需求跟踪需求变更控制需求跟踪报告需求变更控制报告项目研发过程域主要规程文档模板需求开发需求调查需求

10、分析需求定义用户需求说明书产品需求规格说明书技术预研技术预研技术预研计划技术预研报告系统设计体系结构设计用户界面设计数据库设计模块设计体系结构设计报告用户界面设计报告数据库设计报告模块设计报告实现与测试实现与测试实现与测试计划编程文档系统测试系统测试系统测试计划测试用例测试报告客户验收客户验收客户验收计划客户验收报告技术评审正式技术评审非正式技术评审技术评审计划技术评审报告技术评审检查表机构支撑过程域规程与关键活动文档模板质量保证制定质量保证计划过程与产品质量检查问题跟踪与质量改良质量保证计划质量保证检查表质量保证报告质量问题跟踪表配置管理制定配置管理计划配置库管理版本控制变更控制配置管理计划

11、配置库管理报告配置项变更控制报告培训管理机构培训管理项目培训管理培训计划培训评估报告服务与维护客户服务客户服务计划客户服务报告产品维护产品维护计划产品维护报告表1-2 精简模型 规X细分1.4 精简模型 角色与职责表精简模型的主要角色与其职责如表1-3所示详见各个过程域对角色与职责的描述。公司在应用精简模型时，可以将精简模型的各个角色映射到公司原有的岗位上，也可以依据精简模型角色建立新的岗位。一个人可以被赋予多个角色，视具体情况而定。常设角色职责简述机构过程改良角色软件工程过程组SEPG1制定适合于本机构的过程规X。2在机构X围内推广该规X如培训、考核，评估机构过程能力等。质量保证小组QAG1

12、监视规X的实施，确保所有项目以与相关部门准照规X开展工作。2分析并解决机构内存在的共性质量问题，协组SEPG完善规X。项目管理过程角色机构领导1是机构内所有项目的主管，对立项管理和结项管理有最终决策权。2监视项目经理的工作，审批项目经理的各种申请。项目经理1向机构领导汇报工作。2是项目规划、项目监控、风险管理和需求管理过程域的负责人。3监视项目成员的工作，审批项目成员的各种申请。项目研发过程角色需求分析员调查、分析并定义需求，撰写相应的需求文档，尽最大努力使需求文档能够正确无误地反映用户的真实意愿。系统设计师根据需求文档设计软件系统的体系结构、用户界面、数据库、模块等，并撰写相应的设计文档。程

13、序员1根据系统设计文档，编写软件系统的代码。2随时测试和检查自己的代码，与时消除代码中的缺陷。测试员从事单元测试、集成测试和系统测试，主要工作包括制定测试计划、设计测试用例、执行测试和撰写测试报告。机构支撑过程角色配置管理员1为项目制定配置管理计划。2创建并维护配置库，如分配权限、去除垃圾文件、备份配置库等。质量保证员即QAG成员1为项目制定质量保证计划。2周期性的开展“过程与产品质量检查。3跟踪质量问题，给出质量改良措施。培训管理员制定机构或项目的培训计划，监视该计划的实施，撰写培训评估报告。客户服务人员为客户提供与产品相关的服务如技术咨询，快速响应客户的要求，给客户一个满意的解答。产品维护

14、人员1纠错性维护：与时解决用户遇到的技术故障和消除产品中的缺陷。2完善性维护：在资源允许的情况下，不断改善产品功能与质量。临时角色职责说明立项建议小组1开展立项调查、产品构思和可行性分析，撰写相应文档。2申请立项，并在立项评审会议上辩论。立项评审委员会由机构领导、各级经理、市场人员、技术专家、财务人员等组成，委员会按少数服从多数原如此投票决定是否同意立项。结项评审委员会对项目的有形资产和无形资产进展清算，对项目进展综合评估，总结经验教训等。结项委员会的人员组成与立项评审委员会的类似。技术评审委员会对工作成果进展正式技术评审，尽早地发现工作成果中的缺陷，并帮助开发人员与时消除缺陷。该委员会由项目

15、内外的技术专家组成。配置控制委员会对配置管理各项活动拥有决策权例如审批计划，审批变更请求等。表1-3 精简模型的角色与职责简表1.5 公司软件过程的政策1.5.1 目标l 持续改良机构的软件过程能力，不断地提高产品质量、提高生产率并且降低开发本钱。1.5.2 机构领导的支持l 机构领导批准用于软件过程改良的必要经费，例如支付咨询费，购置相关软件工具等。l 机构领导组建SEPG和QAG，专门从事软件过程改良工作。SEPG的主要职责是建立适合于机构的过程规X，QAG的主要职责是监视该规X的实施。建议让SEPG和QAG的大局部人员重叠，这些人既是SEPG成员又是质量保证员，扮演两种角色。这样不仅节约

16、人力资源，并且提高了工作效果由制定规X的人去监视规X的实施最适宜不过。一般地，SEPG成员和质量保证员共占机构总人数的5%左右。l 机构领导不仅要口头支持，还要亲自参与软件过程改良的实践。例如参加培训和考试，准照过程规X执行立项管理和结项管理等。1.5.3 质量管理的政策质量管理口号：“在开发过程之中内建质量而非修补质量。质量管理有种根本措施：“质量保证、“技术评审和“测试。一、 质量保证机构的质量保证员周期性地检查项目成员的“工作过程以与工作成果是否符合既定的规X，来监控和改良“过程质量以与产品质量。机构的质量保证员独立于任何项目，并赋予他一定的权利，对质量不合格的工作成果作出处理。二、技术

17、评审在工作成果刚产生之际，对其进展技术评审分正式或非正式两种，目的是尽早地发现工作成果中的缺陷，并帮助开发人员与时消除缺陷，从而提高产品的质量。如果时间允许的话，应当尽可能多地对产品的重要工作成果进展技术评审。技术评审活动由项目开发团队组织。三、测试测试是指通过运行测试用例test case来找出软件中的缺陷。测试与技术评审的主要区别是前者要运行软件而后者不必运行软件。一般地，产品开发过程中有四个测试阶段：单元测试、集成测试、系统测试和验收测试。其中单元测试和集成测试可以由项目开发团队组织。系统测试阶段必须有项目外的人员参与，以保证系统测试的客观性。验收测试由客户组织。如果有条件的话，建议机构

18、成立专门的测试小组从事单元测试、集成测试和系统测试工作。1.5.4 质量保证小组的政策机构领导任命一位熟悉过程规X并且有丰富的质量管理经验的人担任QAG的负责人或称为质量经理。在机构领导的许可下，该负责人组建QAG成员可以是全职的也可以是兼职的。QAG在行政上独立于任何项目。这种独立性有助于质量保证员客观地检查和监控“过程以与产品的质量。QAG准照SEPG制定的“质量保证规X开展工作。机构领导赋予QAG一定的权利，可以对质量不合格的工作成果做出处理。这种权利使得QAG的工作不会被轻视，并有助于加强全员的质量意识。对于QAG与项目之间出现的难以调和的争议，由机构领导处理。1.5.5 项目团队的政

19、策项目中的任何管理人员、开发人员、测试人员等，必须学习与本职工作相关的过程规X，每个人都必须明白自己“应当在什么时候依据什么规X做什么事情。项目经理应当树立榜样，并且督促项目成员们按规X做事。允许项目经理根据本项目的特征，在SEPG和QAG的指导下，适当地裁剪或扩大机构的过程规X，从而快速建立本项目的过程规X。这项工作应当在“项目规划过程域中完成，并在项目计划中表现出来。如果项目对机构过程规X的裁剪幅度比拟大，遭到QAG的反对，如果双方不能达成共识，如此由机构领导处理该争议。SEPG对项目过程能力的评估成绩将作为评定项目人员工作业绩的重要因素，具体比重由机构领导决定，建议占30以上的比重。2

20、立项管理参见项目管理制度试行V2.1版本3 项目规划在立项管理过程域的项目筹备阶段，机构领导首先任命一位项目经理，之后机构领导协助项目经理筹备项目经费、人力资源、软件硬件资源等。如果必要的资金和资源已经到位，那么项目经理和核心成员即可组成一个项目规划小组，着手制定项目计划，并按计划执行研发和管理工作。项目的计划书可分两类：一是全局的计划书Overall Plan，这里称为项目计划；二是一些下属计划书Subordinate Plan，例如配置管理计划、质量保证计划、一些开发计划和测试计划等。下属计划书是对项目计划的补充，其内容不可与项目计划冲突。通常项目计划由项目经理负责制定，由机构领导审批。而

21、下属计划书一般由项目成员制定，由项目经理审批即可。项目计划过程域有3个主要规程：“制定项目计划、“审批项目计划和“项目计划变更控制，流程如图3-1所示。审批项目计划制定项目计划按计划执行研发与管理工作项目计划变更控制图3-1项目规划流程图4 项目监控项目监控Project Monitoring and Control, PMC的目的是通过周期性地跟踪项目计划的各种参数如进度、工作量、费用、资源、工作成果等，不断地了解项目的进展情况，以便当项目实际进展状况显著偏离计划时能够与时采取纠正措施。本规X阐述了项目监控过程域的三个主要规程： 项目计划跟踪 控制偏差 项目进展汇报 周期性地开展项目计划跟踪

22、项目进展总结偏差控制图4-1 项目监控流程周期性的跟踪任务含进度和工作量、费用、资源、工作成果等，与时了解项目的实际进展情况。为持续过程改良提供有价值的数据。4.1.1 任务跟踪项目经理或其指定的项目成员周期性地如每周一次跟踪每个重要的任务，将采集的数据保存在项目监控数据表之中。任务跟踪表的参考格式如表4-1所示。任务名称实际起止时间跟踪日期、当前进度实际工作量实际工作成果表4-1 任务跟踪表项目经理或其指定的项目成员周期性地跟踪项目费用，将采集的数据保存在项目监控数据表之中。费用跟踪表的参考格式如表4-2所示。费用类别主要开支项、用途金额时间表4-2 费用跟踪表项目经理或其指定的项目成员周期

23、性地跟踪软硬件资源，将采集的数据保存在项目监控数据表之中。资源跟踪表的参考格式如表4-3所示。软硬件资源名称级别实际配置获取方式与时间使用说明关键关键普通普通表4-3 资源跟踪表项目经理或其指定的项目成员周期性地跟踪工作成果与其规模，将采集的数据保存在项目监控数据表之中。工作成果跟踪表的参考格式如表4-4所示。工作成果名称新开发的成果规模代码行、类、文档页数复用或自动生成的成果规模代码行、类、文档页数工作成果1工作成果2总和表4-4 工作成果与其规模跟踪表4.2 控制偏差比照“项目实际进展和“项目计划，分析偏差，如果发现项目实际进展显著偏离计划，如此与时采取纠正措施。记录日期显著偏差描述原因分

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

25、动态度，可比作“防火模式。风险管理属于“防火模式，目的就是“防止风险产生真正的危害。为了便于量化管理，我们给风险定义3个参数： 风险严重性：指风险对项目造成的危害程度。 风险可能性：指风险发生的几率。 风险系数：是风险严重性和风险可能性的乘积。参数等级值描述风险严重性很高5例如进度延误大于30%，或者费用超支大于30%。比拟高4例如进度延误20%30%，或者费用超支20%30%。中等3例如进度延误低于20%，或者费用超支低于20%。比拟低2例如进度延误低于10%，或者费用超支低于10%。很低1例如进度延误低于5%，或者费用超支低于5%。表5-1 风险严重性等级参数等级值描述风险可能性很高5风险

26、发生的几率为比拟高4风险发生的几率为中等3风险发生的几率为比拟低2风险发生的几率为很低1风险发生的几率为表5-2 风险可能性等级风险系数风险可能性很高 5比拟高 4中等 3比拟低 2很低 1风险严重性很高 5252015105比拟高 420161284中等 31512963比拟低 2108642很低 154321本表灰色局部的风险系数值为1025，应当优先处理。表5-3 风险系数等级风险严重性的等级划分如表5-1所示，风险可能性的等级划分如表5-2所示，风险系数的等级划分如表3所示。风险管理有4个主要活动： 风险识别：根据风险检查表，识别出本项目的风险。 风险分析：估计风险严重性、风险可能性、

27、风险系数。 风险减缓：对于风险系数超过“容许值的每一个风险，都应当采取减缓措施。 风险跟踪：跟踪风险减缓过程，记录风险的状态。风险识别风险减缓风险跟踪风险分析图5-1 风险管理示意图在项目的生命周期内，上述4个活动将被循环执行，如图5-1所示。直到项目的所有风险都被识别与解决为止。常用的风险检查表，使用者应根据实际情况进展适当的删减或补充。风险管理过程域产生的主要文档是风险管理报告 。商业风险风险类型检查项政治法律市场政府或者其他机构对本项目的开发有限制吗？有不可预测的市场动荡吗？有不利于我方的官司要打吗？本产品销售后在使用过程中可能导致发生重大的损失或伤亡事故吗？竞争对手有不正当的竞争行为吗

28、本产品销售后在使用过程中可能导致发生重大的损失或伤亡事故吗？是否在开发很少有人真正需要却自以为很好的产品？是否在开发可能赔本的产品？客户客户的需求是否模糊不清？客户是否反反复复地改动需求？客户指定的需求和交付期限在客观上可行吗？客户对产品的健壮性、可靠性、性能等质量因素有非常过分的要求吗？客户的合作态度友善吗？与客户签的合同公正吗？双方互利吗？客户的信誉好吗？例如按客户的需求开发了产品，但是客户可能不购置。子承包商供给商与子承包商、供给商签订的合同公正吗？双方互利吗？子承包商、供给商的信誉好吗？子承包商、供给商有可能倒闭吗？子承包商、供给商能与时交付质量合格的产品或部件吗？子承包商、供给商有

29、能力做好售后服务吗？管理风险风险类型检查项项目计划对项目的规模、难度估计是否比拟正确？人力资源开发人员、管理人员够用吗？合格吗？项目所需的软件、硬件能按时到位吗？项目的经费够用吗？进度安排是否过于紧X？有合理的缓冲时间吗？进度表中是否遗忘了一些重要的必要的任务？进度安排是否考虑了关键路径？ 是否可能出现某一项工作延误导致其他一连串的工作也被延误？任务分配是否合理？即把任务分配给适宜的项目成员，充分发挥其才能是否为了节省钱，不采用购置成熟的软件模块，一切从零做起？项目团队项目成员团结吗？是否存在矛盾？是否绝大局部的项目成员对工作认真负责？绝大局部的项目成员有工作热情吗？团队之中有“害群之马吗？技

30、术开发队伍中有临时工吗？本项目开发过程中是否会有核心人员辞职、调动？是否能保证“人员流动根本不会影响工作的连续性？项目经理是否忙于行政事务而无暇顾与项目的开发工作？上级领导行政部门合作部门本项目是否得到上级领导的重视？上级领导是否随时会抽调本项目的资源用于其他“高优先级的项目？上级领导是否过多地介入本项目的事务并且瞎指挥？行政部门的办事效率是否比拟底，以至于拖项目的后腿？行政部门是否经常干一些无益于生产力的事情，以至于骚扰本项目？机构是否能全面、公正地考核员工的工作业绩？机构是否有较好的奖励和惩罚措施？本项目的合作部门的态度积极吗？是否应付了事？或者做事与承诺的不一致？技术风险风险类型检查项需

31、求开发需求管理需求开发人员懂得如何获取用户需求吗？效率高吗？需求开发人员懂得项目所涉与的具体业务吗？能否理解用户的需求？需求文档能够正确地、完备地表达用户需求吗？需求开发人员能否与客户对有争议的需求达成共识？需求开发人员能否获得客户对需求文档的承诺？以保证客户不随便变更需求？综合技术开发能力包括设计编程、测试等开发人员是否有开发相似产品的经验？待开发的产品是否要与未曾证实的软硬件相连接？对开发人员而言，本项目的技术难度高吗？开发人员是否已经掌握了本项目的关键技术？如果某项技术尚未实践过，开发人员能否在预定时间内掌握？开发小组是否采用比拟有效的分析、设计、编程、测试工具？分析与设计工作是否过于简

32、单、草率，从而让程序员边做边改？开发小组采用统一的编程规X吗？开发人员对测试工作重视吗？能保证测试的客观性吗？项目有独立的测试人员吗？懂得如何进展高效率地测试吗？是否对所有重要的工作成果进展了同行评审正式评审或快速检查？开发人员懂得版本控制、变更控制吗？能够按照配置管理规X执行吗？开发人员重视质量吗？是否会在进度延误时降低质量要求？表5-4 风险检查表风险名称风险识别人风险编号风险识别日期风险描述风险严重性风险系数风险可能性风险处理人风险减缓措施跟踪记录1记录何人在何时做了什么事情2记录当前风险状态正在处理，已经解决，不作处理表5-5 风险管理报告6需求管理需求管理Requirement Ma

33、nagement, RM的目的在客户与开发方之间建立对需求的共同理解，维护需求与其他工作成果的一致性，并控制需求的变更。需求管理过程域的三个主要规程： 需求确认 需求跟踪 需求变更控制 需求确认需求管理需求分析需求定义需求调查需求开发需求工程需求变更控制需求跟踪图6-1 需求工程结构图6.1 需求确认项目经理邀请同行专家和用户包括客户和最终用户一起评审需求文档，尽最大努力使需求文档能够正确无误地反映用户的真实意愿。当需求文档通过正式的评审之后，开发方负责人项目经理和客户对需求文档作书面承诺，使之具有商业合同效果。示例如下：本需求文档建立在双方对需求的共同理解根底之上，我同意后续的开发工作根据该

34、需求文档开展。如果需求发生变化，我们将按照“需求变更控制规程执行。我明白需求的变更将导致双方重新协商本钱、资源和进度等。甲方负责人签字乙方负责人签字评审完毕 输出 需求评审报告，书面的需求承诺需求评审报告摘要需求文档输入名称，标识符，版本，作者，完成日期，需求评审报告输入名称，标识符，评审日期，评审结论 工作成果合格，“无需修改或者“需要轻微修改但不必再审核。 工作成果根本合格，需要作少量的修改，之后通过审核即可。 工作成果不合格，需要作比拟大的修改，之后必须重新对其评审。评审意见评审小组成员输入评审小组成员表6-1 需求评审报告需求承诺需求文档输入名称，标识符，版本，作者，完成日期客户承诺承

35、诺签字，日期项目经理承诺承诺签字，日期表6-2 需求承诺6.2 需求跟踪将系统设计、编程、测试等阶段的工作成果与需求文档进展比拟，建立与维护“需求文档设计文档代码测试用例之间的一致性，确保产品依据需求文档进展开发。项目经理跟踪需求。建立与维护需求跟踪矩阵：l 正向跟踪。检查需求文档中的每个需求是否都能在后续工作成果中找到对应点。l 逆向跟踪。检查设计文档、代码、测试用例等工作成果是否都能在需求文档中找到出处。l 正向跟踪和逆向跟踪合称为“双向跟踪。不论采用何种跟踪方式，都要建立与维护需求跟踪矩阵即表格。需求跟踪矩阵保存了需求与后续工作成果的对应关系。矩阵单元之间的可能存在“一对一、“一对多或“

36、多对多的关系。由于对应关系比拟复杂，最好在表格中加必要的文字解释。表6-3为简单的需求跟踪矩阵格式。l 当需求文档或后续工作成果发生变更时，要与时更新需求跟踪矩阵。需求文档版本，日期设计文档版本，日期代码版本，日期测试用例版本，日期1标题或标识符，说明标题或标识符，说明代码名称，说明测试用例名称，说明2表6-3 简单的需求跟踪矩阵格式6.3 需求变更控制l 修改“原需求文档中不正确的内容，产生新的需求文档。l 控制需求文档的变更，防止发生混乱。补充说明：本规程中的“原需求文档是指已经通过了评审并获得书面承诺的需求文档。开发方负责人项目经理和客户共同控制需求变更。需求变更申请申请变更的需求文档输

37、入名称，版本，日期等信息变更的内容与其理由评估需求变更将对项目造成的影响申请人签字变更申请的审批意见项目经理签字审批意见：签字，日期客户签字合同项目审批意见：签字，日期更改需求文档变更后的需求文档输入名称，版本，完成日期等信息更改人签字重新评审需求文档需求评审小组签字评审意见：签字，日期变更完毕项目经理签字签字日期：表6-4 需求变更控制报告7 结项管理结项管理Project Closing Management, PCM是指在项目开发工作完毕后，对项目的有形资产和无形资产进展清算；对项目进展综合评估；总结经验教训等。立项管理与结项管理是前后呼应的两个过程域，使得项目管理过程“有始有终。项目完

38、毕有两种状况：一是正常完毕，二是异常完毕。前者是指项目按预定计划完毕。后者原因有多种，归根结底都是由于该项目不再符合机构的最大利益。例如有些项目因不适应市场而被中途淘汰，有些项目在执行过程中大大因偏离计划如进度延误、费用超支而被取消。不论项目属于正常完毕还是异常完毕，都要按照结项管理规X处理。国内很多项目普遍存在“虎头蛇尾的现象，结项管理畸变成了“走过场，吃顿饭，这是非常有害的。有价值的结项管理至少包括三项内容： 对项目的有形资产和无形资产进展清算，既要防止资产流失，又要与时地利用这些资产。 对项目进展综合评估。例如评估项目完成情况、项目质量、投入产出分析、项目的市场价值、项目对企业的贡献等等

39、该评估报告可以作为考核项目人员业绩的重要依据。 总结经验教训，使整个机构受益。经验总结综合评估结项评审结项申请机构领导审批机构领导指示资产检查图7-1结项管理流程图结项管理的流程如图7-1所示，产生的主要文档有：8需求开发需求开发Requirement Development, RD的目的是通过调查与分析，获取用户需求并定义产品需求。本规X阐述了需求开发过程域的两个主要规程： 需求调查 需求定义需求开发与需求管理是相辅相成的两类活动，它们共同构成完整的需求工程。需求工程结构图如图6-1所示，需求开发和需求管理的流程如图8-1所示。需求分析需求变更控制需求跟踪需求确认需求管理过程域输出输出用户

40、需求说明书产品需求定义用户需求调查产品需求规格说明书需求开发过程域图8-1 需求开发与需求管理流程图需求开发可分为两个阶段：“用户需求调查阶段和“产品需求定义阶段。而“需求分析如此贯穿于上述两个阶段。需求调查阶段和需求定义阶段在逻辑上存在先后关系，实际工作中二者通常是迭代进展的。我们把从事需求开发工作的人员称为需求分析员也叫系统分析员，防止与其它开发人员混淆。一、需求调查需求调查的目的是通过各种途径获取用户的需求信息原始材料，产生用户需求说明书。二、需求分析需求分析的目的是对各种需求信息进展分析，消除错误，刻画细节等。常用的需求分析方法有“问答分析法、“结构化分析法和“面向对象分析法。三、需求定义需求定义的目的是根据需求调查和需求分析的结果，进