软件研发管理制度

1、. z.软件研发管理制度文件状态： 草稿 正式发布 正在修改文件标识：Lolaage-Software-PM当前版本：作 者：宋孝光完成日期：2012/3/27版本/状态作者参与者修改日期备注宋孝光2012/3/26第一版草稿宋孝光2012/3/27整理目录目录TOC o 1-3 h z uHYPERLINK l _Toc3206503521 软件研发制度综述 PAGEREF _Toc320650352 h 3HYPERLINK l _Toc3206503531.1 精简模型 PAGEREF _Toc320650353 h 3HYPERLINK l _Toc3206503541.2 精简过程域

2、的目的 PAGEREF _Toc320650354 h 4HYPERLINK l _Toc3206503551.3 精简模型文档构造与规细分 PAGEREF _Toc320650355 h 5HYPERLINK l _Toc3206503561.4 精简模型角色与职责表 PAGEREF _Toc320650356 h 6HYPERLINK l _Toc3206503571.5 公司软件过程的政策 PAGEREF _Toc320650357 h 8HYPERLINK l _Toc3206503581.5.1 目标 PAGEREF _Toc320650358 h 8HYPERLINK l _Toc

3、3206503591.5.2 机构领导的支持 PAGEREF _Toc320650359 h 8HYPERLINK l _Toc3206503601.5.3 质量管理的政策 PAGEREF _Toc320650360 h 8HYPERLINK l _Toc3206503611.5.4 质量保证小组的政策 PAGEREF _Toc320650361 h 9HYPERLINK l _Toc3206503621.5.5 工程团队的政策 PAGEREF _Toc320650362 h 9HYPERLINK l _Toc3206503632 立项管理 PAGEREF _Toc320650363 h 9H

4、YPERLINK l _Toc3206503643 工程规划 PAGEREF _Toc320650364 h 9HYPERLINK l _Toc3206503654 工程监控 PAGEREF _Toc320650365 h 10HYPERLINK l _Toc3206503664.1工程方案跟踪 PAGEREF _Toc320650366 h 11HYPERLINK l _Toc3206503674.1.1 任务跟踪 PAGEREF _Toc320650367 h 11HYPERLINK l _Toc320650368费用跟踪 PAGEREF _Toc320650368 h 11HYPERLI

5、NK l _Toc320650369资源跟踪 PAGEREF _Toc320650369 h 11HYPERLINK l _Toc320650370工作成果及其规模跟踪 PAGEREF _Toc320650370 h 12HYPERLINK l _Toc3206503714.2 控制偏差 PAGEREF _Toc320650371 h 12HYPERLINK l _Toc3206503724.3 工程进展汇报 PAGEREF _Toc320650372 h 13HYPERLINK l _Toc3206503735 风险管理 PAGEREF _Toc320650373 h 14HYPERLINK

6、 l _Toc3206503746需求管理 PAGEREF _Toc320650374 h 18HYPERLINK l _Toc3206503756.1 需求确认 PAGEREF _Toc320650375 h 18HYPERLINK l _Toc3206503766.2 需求跟踪 PAGEREF _Toc320650376 h 20HYPERLINK l _Toc3206503776.3 需求变更控制 PAGEREF _Toc320650377 h 20HYPERLINK l _Toc3206503787 结项管理 PAGEREF _Toc320650378 h 22HYPERLINK l

7、_Toc3206503798需求开发 PAGEREF _Toc320650379 h 23HYPERLINK l _Toc3206503809 技术预研 PAGEREF _Toc320650380 h 24HYPERLINK l _Toc32065038110 系统设计 PAGEREF _Toc320650381 h 25HYPERLINK l _Toc32065038210.1体系构造设计 PAGEREF _Toc320650382 h 26HYPERLINK l _Toc32065038310.2用户界面设计 PAGEREF _Toc320650383 h 26HYPERLINK l _T

8、oc32065038410.3数据库设计 PAGEREF _Toc320650384 h 27HYPERLINK l _Toc32065038510.4 模块设计 PAGEREF _Toc320650385 h 28HYPERLINK l _Toc32065038611 实现与测试 PAGEREF _Toc320650386 h 28HYPERLINK l _Toc32065038712 系统测试 PAGEREF _Toc320650387 h 30HYPERLINK l _Toc32065038813 客户验收 PAGEREF _Toc320650388 h 31HYPERLINK l _T

9、oc32065038914 技术评审 PAGEREF _Toc320650389 h 32HYPERLINK l _Toc32065039015 配置管理 PAGEREF _Toc320650390 h 33HYPERLINK l _Toc32065039116 质量保证 PAGEREF _Toc320650391 h 35HYPERLINK l _Toc32065039217 培训管理 PAGEREF _Toc320650392 h 37HYPERLINK l _Toc32065039318 效劳与维护 PAGEREF _Toc320650393 h 381 软件研发制度综述1.1精简模型精

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

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

12、程模型。. z.客户验收根据产品特征确定最适宜的开发模型，以线性顺序为主，以并行、迭代为辅。并行、迭代配置管理 质量保证 培训管理其它： 人力资源管理 财务管理 行政管理 市场营销 技术预研效劳与维护系统测试技术评审实现与测试需求开发系统设计结项管理工程监控 风险管理 需求管理产品维护客户验收产品测试产品开发工程规划立项管理产品定义产品概念机构支撑过程工程研发过程工程管理过程客户验收根据产品特征确定最适宜的开发模型，以线性顺序为主，以并行、迭代为辅。并行、迭代配置管理 质量保证 培训管理其它： 人力资源管理 财务管理 行政管理 市场营销 技术预研效劳与维护系统测试技术评审实现与测试需求开发系统

13、设计结项管理工程监控 风险管理 需求管理产品维护客户验收产品测试产品开发工程规划立项管理产品定义产品概念机构支撑过程工程研发过程工程管理过程图1-1 精简模型-. z.1.2 精简过程域的目的精简模型 所有17个过程域的目的如表1-1所示。工程管理过程域目的立项管理采纳符合机构最大利益的立项建议，通过立项管理使该建议成为正式的工程。杜绝不符合机构最大利益的立项建议被采纳，防止浪费机构的资源、资金、时间等。结项管理在工程开发工作完毕后，对工程的有形资产和无形资产进展清算、对工程进展综合评估以及总结经历教训等。工程规划为工程的研发和管理工作制定合理的行动纲领即工程方案，以便所有相关人员按照该方案有

14、条不紊地开展工作。工程监控周期性地跟踪工程方案的各种参数如进度、工作量、费用、资源等，不断地了解工程的进展情况，以便当工程实际进展显著偏离方案时能够及时采取纠正措施。风险管理在风险产生危害之前识别它们，从而有方案地消除或削弱风险。需求管理在客户与开发方之间建立对需求的共同理解，维护需求与其它工作成果的一致性，并控制需求的变更。工程研发过程域目的需求开发通过调查与分析，获取用户需求并定义产品需求。技术预研在立项之后到开发工作完成之前的时间，对工程将采用的关键技术提前学习和研究，尽可能早地发现并解决开发过程中将会遇到的技术障碍。系统设计设计软件系统的体系构造、用户界面、数据库、模块等，从而在需求与

15、代码之间建立桥梁，指导开发人员去实现能满足用户需求的软件产品。实现与测试依据系统设计文档，编写并测试整个系统的代码。在精简模型中，实现与测试是编程、代码审查、单元测试、集成测试、缺陷管理与改错的综合表述。系统测试对最终系统进展全面的测试，确保最终系统满足产品需求并且遵循系统设计。客户验收客户依据合同对产品进展审查和测试，确保产品满足客户需求。技术评审尽早地发现工作成果中的缺陷，并帮助开发人员及时消除缺陷，从而有效地提高产品的质量。机构支撑过程域目的配置管理通过执行版本控制、变更控制等规程，以及使用配置管理软件来保证所有配置项的完整性和可跟踪性。配置管理是对工作成果的一种有效保护。质量保证提供一

16、种有效的人员组织形式和管理方法，通过客观地检查和监控过程质量与产品质量，从而实现持续地改良质量。培训管理根据机构或工程的需求来制定培训方案，并监视该方案的实施，确保培训取得预期效果。效劳与维护是指产品销售之后的客户效劳和产品维护，其宗旨是提高客户对产品以及对开发方的满意度。表1-1 精简过程域的目的1.3精简模型 文档构造与规细分精简模型的文档构造如图1-2所示，SPP包含17个过程域，规细分如表1-2所示。过程域过程改良政策文档模板规程过程域过程改良政策文档模板规程图 1-2 精简模型 文档构造工程管理过程域主要规程文档模板立项管理立项建议立项评审工程筹备立项建议书立项调查报告书立项可行性分

17、析报告立项评审报告使用现有的规*使用现有的规*结项管理结项管理结项申请书结项评审报告工程规划制定工程方案审批工程方案工程方案变更控制工程方案工程方案变更控制报告工程监控工程方案跟踪偏差控制工程进展总结工程监控数据表工程偏差控制报告工程进展报告风险管理风险管理风险检查表风险管理报告需求管理需求确认需求跟踪需求变更控制需求跟踪报告需求变更控制报告工程研发过程域主要规程文档模板需求开发需求调查需求分析需求定义用户需求说明书产品需求规格说明书技术预研技术预研技术预研方案技术预研报告系统设计体系构造设计用户界面设计数据库设计模块设计体系构造设计报告用户界面设计报告数据库设计报告模块设计报告实现与测试实现

18、与测试实现与测试方案编程文档系统测试系统测试系统测试方案测试用例测试报告客户验收客户验收客户验收方案客户验收报告技术评审正式技术评审非正式技术评审技术评审方案技术评审报告技术评审检查表机构支撑过程域规程与关键活动文档模板质量保证制定质量保证方案过程与产品质量检查问题跟踪与质量改良质量保证方案质量保证检查表质量保证报告质量问题跟踪表配置管理制定配置管理方案配置库管理版本控制变更控制配置管理方案配置库管理报告配置项变更控制报告培训管理机构培训管理工程培训管理培训方案培训评估报告效劳与维护客户效劳客户效劳方案客户效劳报告产品维护产品维护方案产品维护报告表1-2精简模型 规细分1.4 精简模型 角色与

19、职责表精简模型的主要角色及其职责如表1-3所示详见各个过程域对角色与职责的描述。公司在应用精简模型时，可以将精简模型的各个角色映射到公司原有的岗位上，也可以依据精简模型角色建立新的岗位。一个人可以被赋予多个角色，视具体情况而定。常设角色职责简述机构过程改良角色软件工程过程组SEPG1制定适合于本机构的过程规。2在机构围推广该规如培训、考核，评估机构过程能力等。质量保证小组QAG1监视规的实施，确保所有工程以及相关部门准照规开展工作。2分析并解决机构存在的共性质量问题，协组SEPG完善规。工程管理过程角色机构领导1是机构所有工程的主管，对立项管理和结项管理有最终决策权。2监视工程经理的工作，审批

20、工程经理的各种申请。工程经理1向机构领导汇报工作。2是工程规划、工程监控、风险管理和需求管理过程域的负责人。3监视工程成员的工作，审批工程成员的各种申请。工程研发过程角色需求分析员调查、分析并定义需求，撰写相应的需求文档，尽最大努力使需求文档能够正确无误地反映用户的真实意愿。系统设计师根据需求文档设计软件系统的体系构造、用户界面、数据库、模块等，并撰写相应的设计文档。程序员1根据系统设计文档，编写软件系统的代码。2随时测试和检查自己的代码，及时消除代码中的缺陷。测试员从事单元测试、集成测试和系统测试，主要工作包括制定测试方案、设计测试用例、执行测试和撰写测试报告。机构支撑过程角色配置管理员1为

21、工程制定配置管理方案。2创立并维护配置库，如分配权限、去除垃圾文件、备份配置库等。质量保证员即QAG成员1为工程制定质量保证方案。2周期性的开展过程与产品质量检查。3跟踪质量问题，给出质量改良措施。培训管理员制定机构或工程的培训方案，监视该方案的实施，撰写培训评估报告。客户效劳人员为客户提供与产品相关的效劳如技术咨询，快速响应客户的要求，给客户一个满意的解答。产品维护人员1纠错性维护：及时解决用户遇到的技术故障和消除产品中的缺陷。2完善性维护：在资源允许的情况下，不断改善产品功能与质量。临时角色职责说明立项建议小组1开展立项调查、产品构思和可行性分析，撰写相应文档。2申请立项，并在立项评审会议

22、上辩论。立项评审委员会由机构领导、各级经理、市场人员、技术专家、财务人员等组成，委员会按少数服从多数原则投票决定是否同意立项。结项评审委员会对工程的有形资产和无形资产进展清算，对工程进展综合评估，总结经历教训等。结项委员会的人员组成与立项评审委员会的类似。技术评审委员会对工作成果进展正式技术评审，尽早地发现工作成果中的缺陷，并帮助开发人员及时消除缺陷。该委员会由工程外的技术专家组成。配置控制委员会对配置管理各项活动拥有决策权例如审批方案，审批变更请求等。表1-3精简模型的角色与职责简表1.5 公司软件过程的政策1.5.1 目标持续改良机构的软件过程能力，不断地提高产品质量、提高生产率并且降低开

23、发本钱。1.5.2 机构领导的支持机构领导批准用于软件过程改良的必要经费，例如支付咨询费，购置相关软件工具等。机构领导组建SEPG和QAG，专门从事软件过程改良工作。SEPG的主要职责是建立适合于机构的过程规，QAG的主要职责是监视该规的实施。建议让SEPG和QAG的大局部人员重叠，这些人既是SEPG成员又是质量保证员，扮演两种角色。这样不仅节约人力资源，并且提高了工作效果由制定规的人去监视规的实施最适宜不过。一般地，SEPG成员和质量保证员共占机构总人数的5%左右。机构领导不仅要口头支持，还要亲自参与软件过程改良的实践。例如参加培训和考试，准照过程规执行立项管理和结项管理等。1.5.3 质量

24、管理的政策质量管理口号：在开发过程之中建质量而非修补质量。质量管理有种根本措施：质量保证、技术评审和测试。质量保证机构的质量保证员周期性地检查工程成员的工作过程以及工作成果是否符合既定的规，来监控和改良过程质量以及产品质量。机构的质量保证员独立于任何工程，并赋予他一定的权利，对质量不合格的工作成果作出处理。二、技术评审在工作成果刚产生之际，对其进展技术评审分正式或非正式两种，目的是尽早地发现工作成果中的缺陷，并帮助开发人员及时消除缺陷，从而提高产品的质量。如果时间允许的话，应当尽可能多地对产品的重要工作成果进展技术评审。技术评审活动由工程开发团队组织。三、测试测试是指通过运行测试用例test

25、case来找出软件中的缺陷。测试与技术评审的主要区别是前者要运行软件而后者不必运行软件。一般地，产品开发过程中有四个测试阶段：单元测试、集成测试、系统测试和验收测试。其中单元测试和集成测试可以由工程开发团队组织。系统测试阶段必须有工程外的人员参与，以保证系统测试的客观性。验收测试由客户组织。如果有条件的话，建议机构成立专门的测试小组从事单元测试、集成测试和系统测试工作。1.5.4 质量保证小组的政策机构领导任命一位熟悉过程规并且有丰富的质量管理经历的人担任QAG的负责人或称为质量经理。在机构领导的许可下，该负责人组建QAG成员可以是全职的也可以是兼职的。QAG在行政上独立于任何工程。这种独立性

26、有助于质量保证员客观地检查和监控过程以及产品的质量。QAG准照SEPG制定的质量保证规开展工作。机构领导赋予QAG一定的权利，可以对质量不合格的工作成果做出处理。这种权利使得QAG的工作不会被轻视，并有助于加强全员的质量意识。对于QAG与工程之间出现的难以调和的争议，由机构领导处理。1.5.5 工程团队的政策工程中的任何管理人员、开发人员、测试人员等，必须学习与本职工作相关的过程规，每个人都必须明白自己应当在什么时候依据什么规做什么事情。工程经理应当树立典范，并且催促工程成员们按规做事。允许工程经理根据本工程的特征，在SEPG和QAG的指导下，适当地裁剪或扩大机构的过程规，从而快速建立本工程的

27、过程规。这项工作应当在工程规划过程域中完成，并在工程方案中表达出来。如果工程对机构过程规的裁剪幅度比拟大，遭到QAG的反对，如果双方不能达成共识，则由机构领导处理该争议。SEPG对工程过程能力的评估成绩将作为评定工程人员工作业绩的重要因素，具体比重由机构领导决定，建议占30以上的比重。2 立项管理参见工程管理制度试行V2.1版本3 工程规划在立项管理过程域的工程筹备阶段，机构领导首先任命一位工程经理，之后机构领导协助工程经理筹备工程经费、人力资源、软件硬件资源等。如果必要的资金和资源已经到位，则工程经理和核心成员即可组成一个工程规划小组，着手制定工程方案，并按方案执行研发和管理工作。工程的方案

28、书可分两类：一是全局的方案书Overall Plan，这里称为工程方案；二是一些下属方案书Subordinate Plan，例如配置管理方案、质量保证方案、一些开发方案和测试方案等。下属方案书是对工程方案的补充，其容不可与工程方案冲突。通常工程方案由工程经理负责制定，由机构领导审批。而下属方案书一般由工程成员制定，由工程经理审批即可。工程方案过程域有3个主要规程：制定工程方案、审批工程方案和工程方案变更控制，流程如图3-1所示。审批工程方案制定工程方案按方案执行研发与管理工作工程方案变更控制审批工程方案制定工程方案按方案执行研发与管理工作工程方案变更控制图3-1工程规划流程图4 工程监控工程监

29、控Project Monitoring and Control, PMC的目的是通过周期性地跟踪工程方案的各种参数如进度、工作量、费用、资源、工作成果等，不断地了解工程的进展情况，以便当工程实际进展状况显著偏离方案时能够及时采取纠正措施。本规阐述了工程监控过程域的三个主要规程：工程方案跟踪控制偏差 工程进展汇报 周期性地开展工程方案跟踪工程进展总结偏差控制周期性地开展工程方案跟踪工程进展总结偏差控制图4-1 工程监控流程4.1工程方案跟踪周期性的跟踪任务含进度和工作量、费用、资源、工作成果等，及时了解工程的实际进展情况。为持续过程改良提供有价值的数据。4.1.1 任务跟踪工程经理或其指定的工程

30、成员周期性地如每周一次跟踪每个重要的任务，将采集的数据保存在工程监控数据表之中。任务跟踪表的参考格式如表4-1所示。任务名称实际起止时间跟踪日期、当前进度实际工作量实际工作成果表4-1 任务跟踪表4.1.2费用跟踪工程经理或其指定的工程成员周期性地跟踪工程费用，将采集的数据保存在工程监控数据表之中。费用跟踪表的参考格式如表4-2所示。费用类别主要开支项、用途金额时间表4-2 费用跟踪表4.1.3资源跟踪工程经理或其指定的工程成员周期性地跟踪软硬件资源，将采集的数据保存在工程监控数据表之中。资源跟踪表的参考格式如表4-3所示。软硬件资源名称级别实际配置获取方式与时间使用说明关键关键普通普通表4-

31、3 资源跟踪表4.1.4工作成果及其规模跟踪工程经理或其指定的工程成员周期性地跟踪工作成果及其规模，将采集的数据保存在工程监控数据表之中。工作成果跟踪表的参考格式如表4-4所示。工作成果名称新开发的成果规模代码行、类、文档页数复用或自动生成的成果规模代码行、类、文档页数工作成果1工作成果2总和表4-4 工作成果及其规模跟踪表4.2 控制偏差比照工程实际进展和工程方案，分析偏差，如果发现工程实际进展显著偏离方案，则及时采取纠正措施。记录日期显著偏差描述原因分析纠正措施结果表4-5工程偏差控制报告4.3 工程进展汇报周期性地汇报工程进展情况。工程经理周期性地总结工程进展情况，撰写工程进展报告并通报

32、给机构领导和所有工程成员。根本信息工程名称报告日期工程编号报告批次第N份工程经理工程所处阶段工程进展状况方案实际情况任务与进度工作成果费用人力资源软硬件资源问题与对策表4-6工程进展报告5 风险管理风险管理Risk Management, RiskM的目的是在风险产生危害之前识别它们，从而有方案地消除或削弱风险。所有可能危害工程的因素都称为风险。被刻画为风险的事件最终可能发生也可能不发生。人们对待风险有两种态度。一种是被动态度，可比作救火模式。另一种是主动态度，可比作防火模式。风险管理属于防火模式，目的就是防止风险产生真正的危害。为了便于量化管理，我们给风险定义3个参数：风险严重性：指风险对工

33、程造成的危害程度。风险可能性：指风险发生的几率。风险系数：是风险严重性和风险可能性的乘积。参数等级值描述风险严重性很高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风险发生的

34、几率为0.2 0.0表5-2 风险可能性等级风险系数风险可能性很高 5比拟高 4中等 3比拟低 2很低 1风险严重性很高 5252015105比拟高 420161284中等 31512963比拟低 2108642很低 154321本表灰色局部的风险系数值为1025，应当优先处理。表5-3 风险系数等级风险严重性的等级划分如表5-1所示，风险可能性的等级划分如表5-2所示，风险系数的等级划分如表3所示。风险管理有4个主要活动：风险识别：根据风险检查表，识别出本工程的风险。风险分析：估计风险严重性、风险可能性、风险系数。风险减缓：对于风险系数超过容许值的每一个风险，都应当采取减缓措施。风险跟踪：跟

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

36、否在开发很少有人真正需要却自以为很好的产品？是否在开发可能赔本的产品？客户客户的需否模糊不清？客户是否反反复复地改动需求？客户指定的需求和交付期限在客观上可行吗？客户对产品的强健性、可靠性、性能等质量因素有非常过分的要求吗？客户的合作态度友善吗？与客户签的合同公正吗？双方互利吗？客户的信誉好吗？例如按客户的需求开发了产品，但是客户可能不购置。子承包商供给商与子承包商、供给商签订的合同公正吗？双方互利吗？子承包商、供给商的信誉好吗？子承包商、供给商有可能倒闭吗？子承包商、供给商能及时交付质量合格的产品或部件吗？子承包商、供给商有能力做好售后效劳吗？管理风险风险类型检查项工程方案对工程的规模、难度

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

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

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

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

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

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

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

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

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

46、案完毕。后者原因有多种，归根结底都是由于该工程不再符合机构的最大利益。例如有些工程因不适应市场而被中途淘汰，有些工程在执行过程大因偏离方案如进度延误、费用超支而被取消。不管工程属于正常完毕还是异常完毕，都要按照结项管理规处理。国很多工程普遍存在虎头蛇尾的现象，结项管理畸变成了走过场，吃顿饭，这是非常有害的。有价值的结项管理至少包括三项容：对工程的有形资产和无形资产进展清算，既要防止资产流失，又要及时地利用这些资产。对工程进展综合评估。例如评估工程完成情况、工程质量、投入产出分析、工程的市场价值、工程对企业的奉献等等。该评估报告可以作为考核工程人员业绩的重要依据。总结经历教训，使整个机构受益。经

47、历总结综合评估结项评审结项申请机构领导审批机构领导指示资产检查经历总结综合评估结项评审结项申请机构领导审批机构领导指示资产检查图7-1结项管理流程图结项管理的流程如图7-1所示，产生的主要文档有：8需求开发需求开发Requirement Development, RD的目的是通过调查与分析，获取用户需求并定义产品需求。本规阐述了需求开发过程域的两个主要规程：需求调查需求定义需求开发与需求管理是相辅相成的两类活动，它们共同构成完整的需求工程。需求工程构造图如图6-1所示，需求开发和需求管理的流程如图8-1所示。需求分析需求变更控制需求跟踪需求确认需求管理过程域输出输出用户需求说明书产品需求定义用

48、户需求调查产品需求规格说明书需求开发过程域需求分析需求变更控制需求跟踪需求确认需求管理过程域输出输出用户需求说明书产品需求定义用户需求调查产品需求规格说明书需求开发过程域图8-1 需求开发与需求管理流程图需求开发可分为两个阶段：用户需求调查阶段和产品需求定义阶段。而需求分析则贯穿于上述两个阶段。需求调查阶段和需求定义阶段在逻辑上存在先后关系，实际工作中二者通常是迭代进展的。我们把从事需求开发工作的人员称为需求分析员也叫系统分析员，防止与其它开发人员混淆。一、需求调查需求调查的目的是通过各种途径获取用户的需求信息原始材料，产生用户需求说明书。二、需求分析需求分析的目的是对各种需求信息进展分析，消

49、除错误，刻画细节等。常用的需求分析方法有问答分析法、构造化分析法和面向对象分析法。三、需求定义需求定义的目的是根据需求调查和需求分析的结果，进一步定义准确无误的产品需求，产生产品需求规格说明书。系统设计人员将依据产品需求规格说明书开展系统设计工作。需求开发过程域产生的主要文档有：9 技术预研技术预研Technical Pre-Research, TPR是指在立项之后到开发工作完成之前的时间，对工程将采用的关键技术提前学习和研究，以便尽可能早地发现并解决开发过程中将会遇到的技术障碍。在产品开发过程中，技术问题可能会层出不穷。如果一点技术障碍都没有遇到，要么是开发人员的技术水平实在太高了，要么是工

50、程的技术含量实在太低了，这类情况比拟少见。一般说来，在设计或实现阶段遇到了技术障碍，才去攻克问题，其代价通常比拟高。因为其他人的工作可能会被阻塞，已经投入的不少资源将被闲置。最糟糕的是，如果此技术障碍无法攻克，不得已要改变技术方案、重新设计系统，则不仅浪费了人力、财力、时间，处理不好还会使开发队伍陷入混乱状态。所以开展技术预研工作至少有两大好处：帮助开发人员更好地进展需求开发、系统设计和程序设计。防止开发进程被技术障碍打断，导致大量的相关工作被阻塞。技术预研的流程如图9-1所示。开展技术预研制定方案撰写预研报告工作成果介绍技术评审开展技术预研制定方案撰写预研报告工作成果介绍技术评审图9-1 技

51、术预研流程技术预研过程中产生的主要文档有：10 系统设计系统设计System Design, SD是指设计软件系统的体系构造、用户界面、数据库、模块等，从而在需求与代码之间建立桥梁，指导开发人员去实现能满足用户需求的软件产品。本规阐述了系统设计过程域的四个主要规程：体系构造设计 用户界面设计数据库设计 模块设计 系统设计过程域分为两个阶段：高层设计阶段和详细设计阶段。高层设计阶段的重点是软件系统的体系构造设计。详细设计阶段的重点是用户界面设计、数据库设计和模块设计，如图10-1所示。需求开发高层设计阶段体系构造设计数据库设计用户界面设计模块设计实现与测试详细设计阶段需求开发高层设计阶段体系构造

52、设计数据库设计用户界面设计模块设计实现与测试详细设计阶段图10-1 系统设计过程域示意图系统设计过程域产生的主要文档有：体系构造设计报告用户界面设计报告数据库设计报告模块设计报告10.1体系构造设计分析与设计软件的体系构造。通过系统分解，确定子系统的功能和子系统之间的关系，以及模块的功能和模块之间的关系，产生体系构造设计报告。工程经理指定假设干名开发人员从事体系构造设计以下称为体系构造设计人员。体系构造设计流程如图10-2所示。Step3. 确定设计策略Step2. 确定约束因素Step1. 设计准备Step3. 确定设计策略Step2. 确定约束因素Step1. 设计准备Step4. 系统分

53、解设计Step6. 设计评审Step5. 撰写文档图10-2 体系构造设计流程10.2用户界面设计设计软件的用户界面，产生用户界面设计报告。制作用户界面的资源如图像、图标或者界面专用组件等工程经理指定假设干名开发人员从事用户界面设计以下称为界面设计人员。如果可能的话，邀请用户或美工人员协助设计用户界面。用户界面设计流程如图10-3所示。迭代Step2. 界面设计Step4. 设计评审Step3. 撰写文档Step1. 设计准备2.3细化2.2原型评估2.1原型创作迭代Step2. 界面设计Step4. 设计评审Step3. 撰写文档Step1. 设计准备2.3细化2.2原型评估2.1原型创作图

54、10-3 体系构造设计流程10.3数据库设计设计软件的数据库，产生数据库设计报告。工程经理指定假设干名开发人员从事数据库设计以下称为数据库设计人员。数据库设计流程如图10-4所示。迭代Step2. 数据库设计Step3. 撰写文档2.4优化2.3平安性设计2.2物理设计2.1逻辑设计Step1. 设计准备Step4. 设计评审迭代Step2. 数据库设计Step3. 撰写文档2.4优化2.3平安性设计2.2物理设计2.1逻辑设计Step1. 设计准备Step4. 设计评审图10-4 数据库设计流程10.4 模块设计设计软件所有模块的主要接口与属性、数据构造和算法，产生模块设计报告。工程经理指定

55、假设干名开发人员从事模块的设计以下称为模块设计人员，模块设计人员将在实现阶段编写这些模块的代码。模块设计流程如图10-5所示。Step2. 模块设计2.1接口与属性设计Step4. 设计评审Step3. 撰写文档Step1. 设计准备迭代2.2数据构造Step2. 模块设计2.1接口与属性设计Step4. 设计评审Step3. 撰写文档Step1. 设计准备迭代2.2数据构造与算法设计图10-5 模块设计流程11 实现与测试实现与测试Implementation and Test, IT的目的是依据系统设计文档，编写并测试整个系统的代码。在本规中，实现与测试是编程、代码审查、单元测试、集成测试

56、、缺陷管理与改错的综合表述。实现与测试的流程如图11-1所示。一般地，编程、代码审查、单元测试、集成测试大致存在先后顺序关系，也可以并行、迭代地开展。上述任何活动中发现的缺陷必须用统一的缺陷管理工具来管理，开发人员应当及时消除缺陷改错。缺陷管理与改错单元测试集成测试代码审查编程模块软件系统准备缺陷管理与改错单元测试集成测试代码审查编程模块软件系统准备图11-1 实现与测试流程图由于实现与测试是工作量最大、时间最长、产生工作成果代码与文档最多的一个工程研发过程域，所以需要作充分的准备工作。实现与测试工作根本上在开发小组部开展。一个工程可能有一个或者多个开发小组。对于小型工程，工程经理可以兼任开发

57、组长。特别要注意的是，开发人员应当对自己的代码进展审查和测试这是份的工作，但是不能作为该代码已经通过审查和测试的依据。所以开发人员还要互相审查和测试同伴的代码。实现与测试过程域产生的主要文档有：实现与测试方案编程文档代码审查报告测试用例测试报告缺陷管理报告由缺陷管理工具自动生成一个工程可能有多个开发小组，视工程规模而定。开发组长由工程经理指定。开发组长管理编程、代码审查、单元测试、集成测试、缺陷管理与改错等活动。12 系统测试系统测试System Test, ST的目的是对最终软件系统进展全面的测试，确保最终软件系统满足产品需求并且遵循系统设计。系统测试流程如图12-1所示。由于系统测试的目的

58、是验证最终软件系统满足产品需求并且遵循系统设计，所以当产品需求和系统设计文档完成之后，系统测试小组就可以提前开场制定测试方案和设计测试用例，而不必等到实现与测试阶段完毕。这样可以提高系统测试的效率。系统测试过程中发现的所有缺陷必须用统一的缺陷管理工具来管理，开发人员应当及时消除缺陷改错。审批设计测试用例缺陷管理与改错制定测试方案执行系统测试审批迭代审批设计测试用例缺陷管理与改错制定测试方案执行系统测试审批迭代图12-1 系统测试流程图工程经理设法组建富有成效的系统测试小组。系统测试小组的成员主要来源于：机构独立的测试小组如果存在的话。邀请其它工程的开发人员参与系统测试。本工程的局部开发人员。机

59、构的质量保证人员。系统测试小组应当根据工程的特征确定测试容。一般地，系统测试的主要容包括：功能测试。即测试软件系统的功能是否正确，其依据是需求文档，如产品需求规格说明书。由于正确性是软件最重要的质量因素，所以功能测试必不可少。强健性测试。即测试软件系统在异常情况下能否正常运行的能力。强健性有两层含义：一是容错能力，二是恢复能力。性能测试。即测试软件系统处理事务的速度，一是为了检验性能是否符合需求，二是为了得到*些性能数据供人们参考例如用于宣传。用户界面测试。重点是测试软件系统的易用性和视觉效果等。平安性security测试。是指测试软件系统防止非法入侵的能力。平安是相对而言的，一般地，如果黑客

60、为非法入侵花费的代价考虑时间、费用、危险等因素高于得到的好处，则这样的系统可以认为是平安的。安装与反安装测试。系统测试过程域产生的主要文档有：系统测试方案系统测试用例系统测试报告缺陷管理报告对最终软件系统进展全面的测试，确保最终软件系统满足产品需求并且遵循系统设计。工程经理组建系统测试小组，并指定一名成员任测试组长。系统测试小组各成员共同制定测试方案、设计测试用例、执行测试，并撰写相应的文档。测试组长管理上述事务。开发人员及时消除测试人员发现的缺陷。13 客户验收客户验收Customer Acceptance, CA是指客户依据合同对产品进展审查和测试，确保产品满足客户需求。客户对产品的验收主