秘 密 仅限于内部使用 质量管理体系培训教材
（一）
北京博思美亚科技发展公司
最新精品资料整理推荐，更新于二〇二一年一月二十七日2021年1月27日星期三20:47:59
……………………………………………………………最新资料推荐…………………………………………………
目 录
公司标准软件过程体系文件导读 ............................................................................... 1 软件生命周期模型 ..................................................................................................... 15 软件开发过程 ............................................................................................................. 25 技术类评审 ............................................................................................................... 111 项目估算指南 ........................................................................................................... 146 标准软件过程总体裁剪指南 ................................................................................... 152
最新精品资料整理推荐，更新于二〇二一年一月二十七日2021年1月27日星期三20:47:59
……………………………………………………………最新资料推荐…………………………………………………
公司标准软件过程体系文件导读
目 录
1、概述 ......................................................................................................................... 2 1.1 目的 ................................................................................................................. 2 1.2 适用范围 ......................................................................................................... 2 1.3 引用文件 ......................................................................................................... 2 1.4 术语 ................................................................................................................. 2 1.5 参考资料 ......................................................................................................... 2 2、公司标准软件过程的开发 ..................................................................................... 3 2.1 开发历程 ......................................................................................................... 3 2.2 公司标准软件过程总体结构 ......................................................................... 6 3、软件过程体系文件 ............................................................................................... 10 3.1 过程管理 ....................................................................................................... 10 3.2 软件开发过程 ............................................................................................... 12 3.3 项目管理 ....................................................................................................... 12 3.4 资源管理 ....................................................................................................... 13 3.5 指南性文件 ................................................................................................... 14
最新精品资料整理推荐，更新于二〇二一年一月二十七日2021年1月27日星期三20:47:59
……………………………………………………………最新资料推荐…………………………………………………
1、概述
1.1 目的
本文件对公司软件过程及其体系文件的总体结构进行描述，为与软件过程的开发、维护、改进、执行、管理和跟踪等有关的人员学习、理解和使用软件过程体系文件提供指南。
1.2 适用范围
适用于SEPG、高层经理、项目经理、软件开发人员、测试人员、软件质量保证人员、软件配置管理人员及其他支持人员为了按规范开展各自的业务活动，学习、理解和使用软件过程体系文件。
1.3 引用文件
无。
1.4 术语
无。
1.5 参考资料
•《Software Project Management Guidebook》（Version 2.0），Process Strategies，Inc.
•《软件工程－实践者的研究方法》，（美）Roger S. Pressman著，黄柏素、梅宏译，机械工业出版社出版，1999年10月
•《实践中的CMM－INFOSYS公司实施软件项目之过程》，潘卡•杰罗特著，杨慧鸣、李光龙泽，2001年7月
最新精品资料整理推荐，更新于二〇二一年一月二十七日2021年1月27日星期三20:47:59
……………………………………………………………最新资料推荐…………………………………………………
2、公司标准软件过程的开发
2.1 开发历程
为了使软件过程保持长期稳定并能持续改进，必须开发组织（即公司）级的标准软件过程。为此，公司组织了以软件工程过程组（SEPG）为主体的标准软件过程开发和文件编写组，具体实施上述任务。公司标准软件过程是在公司范围内的软件项目全面执行CMM二级的基础上，在软件工程一般理论的指导下，收集公司全部软件项目所采用的软件过程，经过分析、归纳、提炼、分类、总结等一系列步骤开发而成；又在开发标准软件过程的基础上，形成了描述这些标准软件过程的相互关联的程序文件体系。
本程序文件体系对组成标准软件过程的基本软件过程要紧，以及软件过程要素之间的关系（软件过程结构）进行描述，描述的重点放在过程的可操作性上。此外，与此相关联，开发或编写了公司的软件过程数据库、与软件过程相关的文档库、软件生命周期描述文件和标准软件过程裁剪指南。它们和公司标准软件过程一起，组成了公司的软件过程资产。
公司的软件过程资产为规范公司软件项目的软件过程提供了基础和保证。各软件项目按标准软件过程裁剪指南，根据项目的实际情况（主要是客户需求）对公司标准软件过程进行裁剪，开发适合项目特定特性的项目软件过程；项目软件过程开发的重点在软件过程的可用性，以及附加到该项目的价值。项目以项目定义的软件过程为基础，制订项目软件开发计划；按计划执行项目的软件开发活动，产生相应的软件工作产品及其他开发成果；开发过程中的数据以及项目结束后进行总结的数据，经过一定的手续，反馈到公司的软件过程数据和软件过程相关文档库，丰富公司的软件过程资产。如此反复循环，促使软件过程得以持续改进。
以上过程和关系可以用图1表示。图中：
表示实体，例如“分配到软件的需求” 表示活动，例如“选择项目的软件生命周期”
图中上半部分用粗线框围起来的部分即公司的软件过程资产部分，它由描述公司标准软件过程的程序文件、软件过程数据库、与软件过程相关的文档库、软件生命周期描述文件和标准软件过程裁剪指南组成。
最新精品资料整理推荐，更新于二〇二一年一月二十七日2021年1月27日星期三20:47:59
……………………………………………………………最新资料推荐…………………………………………………
下半部分则描述公司软件过程资产的利用过程：软件项目按标准软件过程裁剪指南，根据项目的实际情况（主要是客户需求）对公司标准软件过程进行裁剪，开发适合项目特定特性的项目软件过程；制订项目软件开发计划，并按计划执行项目的软件开发活动；将项目数据（包括开发过程中的数据以及项目结束后进行总结的数据）反馈到公司的软件过程数据库和软件过程相关文档库。
最新精品资料整理推荐，更新于二〇二一年一月二十七日2021年1月27日星期三20:47:59
……………………………………………………………最新资料推荐…………………………………………………
图1 公司软件过程资产的开发和利用
最新精品资料整理推荐，更新于二〇二一年一月二十七日2021年1月27日星期三20:47:59
……………………………………………………………最新资料推荐…………………………………………………
2.2 公司标准软件过程总体结构
图2为公司标准软件过程的总体结构。由于本公司的产品（项目）除了纯软件产品（项目）外，还包括软件和硬件兼有的产品（项目），考虑到过程的完整性以及便于理解软件过程和其他过程之间的接口关系，图中的项目开发过程反映了软件和硬件兼有的产品的整个开发过程，但其中非软件过程部分均采用虚线，以示区别。
有关内容说明如下：
（1）项目、项目生命周期和软件生命周期
项目是由一组有起止日期、相互协调的受控活动组成的独特过程，该过程要求达到符合包括时间、成本和资源等约束条件在内的规定要求的目标，其结果将产生产品。而软件项目则是为了开发软件产品（包括系统）而建立的项目。项目和产品都具有一定的生命周期。
项目生命周期是指从项目启动到项目结束为止的时间间隔。项目生命周期一般包括：
•初期策划阶段（主要是可行性分析）；
•开发策划阶段（开发前的人、财、物等的计划和准备）；
•实施阶段（具体实施项目开发计划，保证项目的质量、成本、进度的顺利完成）；
•结束阶段（评审、鉴定及项目交付和组织结束工作）。 在整个项目生命周期，所涉及的过程可以分为两类： •项目开发过程（和被开发产品的实现直接相关）； •项目管理过程（对项目的开发过程进行管理和控制）。
软件生命周期则是指软件产品的生命周期，即是指从设想－软件产品开始到软件不再供使用为止的时间间隔。软件生命周期一般包括：概念阶段、需求阶段、设计阶段、实现阶段、测试阶段、安装和调整阶段、运行和维护阶段，有时还包括退役阶段。
显然，项目生命周期和软件生命周期在时间上是相关的，但在概念上是完全不同的。一般来说，项目生命周期不会超过该项目所开发的软件产品的生命周期。
最新精品资料整理推荐，更新于二〇二一年一月二十七日2021年1月27日星期三20:47:59
……………………………………………………………最新资料推荐…………………………………………………
（2）项目开发过程
图中的下部表示项目的开发过程。它从客户需求开始，通过系统分析，将客户需求分解成软件部分的需求和硬件部分的需求（从此处项目将分成软件项目和硬件项目两部分）。其中，软件项目从软件需求定义阶段、设计阶段、实现阶段、测试阶段、验收交付阶段到项目总结，表示整个软件开发的结束。一般来说，作为软件开发项目到此就意味着结束了，但软件产品的生命周期并未结束。软件产品交付后，将经历使用过程中的维护阶段（维护阶段的时间可能和项目合同有关），直到最后产品退役。
（3）项目管理过程
图中的中部表示项目的管理过程，即对项目的开发过程实施管理的过程。对于软件和硬件兼有的项目来说，项目管理的主要过程如下：
•初期策划（主要针对系统分析、可行性分析进行策划）； •开发策划（开发前的人、财、物等的计划和准备）；
•项目跟踪与监控（对项目初期的系统分析、可行性分析，以及项目开发过程中软件需求定义、设计、实现、测试、验收交付等活动进行跟踪与监控）；
•软件质量保证（SQA，对项目的软件过程和软件产品的符合性进行质量监控，它贯穿于软件项目的始终）；
•软件配置管理（SCM，为确保软件产品的完整性和正确性进行的管理，它贯穿于软件项目的始终）；
•需求管理（为确保满足客户需求进行的管理，它贯穿于项目的始终）； •评审过程（包括同行评审等技术类评审和计划评审等管理类评审）； •项目结束处理（包括项目的鉴定、验收、交付，以及进行项目总结）。 此外，在项目管理活动中，还可能有以下管理过程： •项目培训； •组间协调等。 （4）过程资产
本公司的软件过程资产分两个层次：公司级资产和项目级资产。 a. 公司级资产 包括：
•过程数据库（含软件过程和其他过程的资产）；
最新精品资料整理推荐，更新于二〇二一年一月二十七日2021年1月27日星期三20:47:59
……………………………………………………………最新资料推荐…………………………………………………
•过程相关文档库； •人力资源库。 b. 项目级资产 包括：
•项目控制数据库（项目经理控制，用于保存项目数据，以便对项目进行跟踪与监控）；
•SQA管理库（SQA控制，用于保存项目的软件质量保证数据）； •SCM管理库（SCM控制，用于保存项目的软件配置管理数据）； •SCM库（SCM控制，用于保存项目的所有配置项）。
通过一定的手续，项目的项目控制数据库和SQA管理库中的数据，经过选择，将补充到公司的过程数据库和过程相关文档库中。
此外，根据实际需要，总部一级也可能需要有人力资源库。
最新精品资料整理推荐，更新于二〇二一年一月二十七日2021年1月27日星期三20:47:59
……………………………………………………………最新资料推荐…………………………………………………
图2 软件过程结构图
最新精品资料整理推荐，更新于二〇二一年一月二十七日2021年1月27日星期三20:47:59
……………………………………………………………最新资料推荐…………………………………………………
3、软件过程体系文件
公司的软件过程体系文件的组成如图3所示。
软件过程体系文 过程管理 软件开发过程 项目管理 资源管理 指南性文件 软件开发过程程序文件 培训程序 标准软件过程开发与维护 过程描述文件编写规范（一） 客户需求管理程序文件 项目策划程序文件 项目跟踪与监控程序文件 项目总结程序文件 软件质量保证程序文件 软件配置管理程序文件 组间协调程序文件 技术类评审程序文件 高层验证程序文件 项目估算指南 标准软件过程总体裁剪指南 公司标准软件过程体系文件导读 过程描述文件编写规范（二） 质量管理体系 数据库管理和维护文件 软件生命周期模型描述文件 标识规范 术 语 文件控制程序
图3 软件过程体系文件
按文件的使用目的，公司的软件过程体系文件分为五类：过程管理、软件开发过程、项目管理、资源管理和指南。
3.1 过程管理
过程管理是指对软件过程进行管理，此类文件的使用人员主要是对软件过程
最新精品资料整理推荐，更新于二〇二一年一月二十七日2021年1月27日星期三20:47:59
……………………………………………………………最新资料推荐…………………………………………………
进行开发、维护、改进的人员，例如SEPG成员、项目经理、SQA等。有关文件说明如下：
（1）标准软件过程开发与维护
•使用人员：SEPG和软件过程描述文件编写人员。
•内容提要：本文件对如何开发和管理公司的标准软件过程、如何编写软件过程描述文件、如何编写标准软件过程裁剪指南等作出了规定。
（2）过程描述文件编写规范（一） •使用人员：软件过程描述文件编写人员。
•内容提要：为能分解成若干过程元素的较大过程编写的描述文件编写规范。 （3）过程描述文件编写规范（二） •使用人员：软件过程描述文件编写人员。
•内容提要：为没有明显的入口和出口准则的过程（例如日常管理类的过程）编写的描述文件编写规范。
（4）质量管理体系数据库管理和维护文件
•使用人员：SEPG、项目经理、SQA和数据库的管理和维护人员。 •内容提要：本文件对公司的软件过程数据库和与过程相关文档库的管理和维护作出了规定。考虑到将来需要扩充ISO9001要求的其他数据库，故起此名。
（5）软件生命周期模型描述文件
•使用人员：项目经理以及参与项目软件过程定义的有关人员。
•内容提要：本文件对公司所确定的软件生命周期模型进行描述，作为公司的过程资产之一，供项目选择适合项目情况的软件生命周期模型时参考。
（6）标识规范
•使用人员：对被标识对象进行标识的人中员。
•内容提要：为规范包括文件、表格、产品的标识而制订的规范。 （7）术语
•使用人员：SEPG和软件过程描述文件编写人员。
•内容提要：本文件定义了本软件过程体系文件所使用的专用术语。 （8）文件控制程序 •使用人员：文件管理人员。
•内容提要：本文件对文件的编写、评审、批准、发布、发放、回收等文件
最新精品资料整理推荐，更新于二〇二一年一月二十七日2021年1月27日星期三20:47:59
……………………………………………………………最新资料推荐…………………………………………………
管理要求作出了规定，是整个质量管理体系所要求的用于对受控文件进行管理的文件。
3.2 软件开发过程
软件开发过程是指与软件开发有关的过程，相关文件的使用人员主要是和软件开发有关的人员。
（9）软件开发过程程序文件
•使用人员：项目经理以及参与项目软件过程定义的有关人员。
•内容提要：本程序文件针对本公司软件项目所采用的典型开发过程，分解成过程要素进行描述，供各软件项目根据标准软件过程裁剪指南，定义项目自己的软件过程时使用。
3.3 项目管理
与项目管理有关的文件如下： （10）客户需求管理程序文件
•使用人员：项目经理、SQA、SCM和软件开发人员。
•内容提要：本文件是为了确保项目满足客户需求和如何确保满足客户需求，为项目编写的有关客户需求管理的程序文件。
（11）项目策划程序文件
•使用人员：项目经理以及参与项目策划的其他有关人员。
•内容提要：为指导软件项目进行项目的初期策划和开发策划而编写的程序文件。
（12）项目跟踪与监控程序文件
•使用人员：高层经理、项目经理、SQA、SCM和软件开发人员。 •内容提要：指导软件项目在项目计划执行过程中如何对项目进行跟踪与监控的程序文件。
（13）项目总结程序文件
•使用人员：项目经理、SQA、SCM和软件开发人员。
•内容提要：指导软件项目在项目结束阶段如何进行项目总结的程序文件。
最新精品资料整理推荐，更新于二〇二一年一月二十七日2021年1月27日星期三20:47:59
……………………………………………………………最新资料推荐…………………………………………………
（14）软件质量保证程序文件
•使用人员：SQA、项目经理、SCM和软件开发人员。
•内容提要：指导软件项目的SQA如何执行项目的软件质量保证活动，以及项目的其他人员如何配合的程序文件。
（15）软件配置管理程序文件
•使用人员：SCM、项目经理、SQA和软件开发人员。
•内容提要：指导软件项目的SCM如何执行项目的软件配置管理活动，以及项目的其他人员如何配合的程序文件。
（16）组间协调程序文件
•使用人员：项目经理、SQA、SCM和软件开发人员。
•内容提要：项目在进行项目策划时，应考虑有无组间协调的情况，本程序文件提供这方面的要求和指导。
（17）技术类评审程序文件
•使用人员：项目经理、软件开发人员、SQA以及其他参与评审的人员。 •内容提要：本程序文件为项目进行技术类评审（包括同行评审及其他类型的技术评审）规定要求和提供指导。
（18）高层验证程序文件
•使用人员：高层经理、项目经理、SQA、SCM和软件开发人员。 •内容提要：在公司标准软件过程的开发和改进以及项目在执行软件开发活动的过程中，高层经理应在哪些环节进行验证，如何进行验证？项目的有关人员如何配合？本程序文件为高层经理的验证活动提出要求并提供指导。
3.4 资源管理
资源管理主要包括人力资源、设备、环境等方面的管理。 （19）培训程序
•使用人员：公司培训组、高层经理、项目经理、SQA、SCM和软件开发人员。
•内容提要：对公司级培训和项目级培训的实施要求作出规定，包括培训需求的收集、培训计划、培训实施和培训总结等。
最新精品资料整理推荐，更新于二〇二一年一月二十七日2021年1月27日星期三20:47:59
……………………………………………………………最新资料推荐…………………………………………………
3.5 指南性文件
目前提供以下指南性文件： （20）项目估算指南
•使用人员：项目经理及其他参与估算的人员。
•内容提要：本指南为项目估算的方法（例如：规模估算、工作量估算等）提供指南。
（21）标准软件过程总体裁剪指南
•使用人员：项目经理及其他参与项目软件过程定义的人员。
•内容提要：总体裁剪指南是公司标准软件过程裁剪指南中的高层裁剪指南（或一般性裁剪指南）。它为软件项目在对公司标准软件过程进行裁剪时，提供对一般性活动进行裁剪的指南；裁剪结果为项目进行详细的过程裁剪提供框架性的指导方针（详细裁剪指南分散在各程序文件的“详细裁剪指南”中）。
（22）软件过程体系文件导读（即本文件）
•使用人员：SEPG、高层经理、项目经理、软件开发人员、测试人员、软件质量保证人员、软件配置管理人员等为了按规范开展各自的业务活动，需要学习、理解和使用软件过程体系文件的所有人员。
•内容提要：对公司标准软件过程开发的背景、开发过程、标准软件过程的总体结构，以及相应的软件过程体系文件进行导读性的说明。
最新精品资料整理推荐，更新于二〇二一年一月二十七日2021年1月27日星期三20:47:59
……………………………………………………………最新资料推荐…………………………………………………
软件生命周期模型
目 录
1、概述 ....................................................................................................................... 16 1.1 目的............................................................................................................... 16 1.2 适用范围....................................................................................................... 16 1.3 引用文件....................................................................................................... 16 1.4 术语............................................................................................................... 16 1.5 参考资料....................................................................................................... 16 2、软件生命周期模型描述 ....................................................................................... 17 2.1 瀑布模型 ....................................................................................................... 17 2.2 原型＋瀑布模型 ........................................................................................... 18 2.3 增量模型 ....................................................................................................... 19 2.4 增量的迭代过程模型 ................................................................................... 21 2.5 快速应用开发模型 ....................................................................................... 21 3、几种模型的比较 ................................................................................................... 23 4、其它模型采用说明 ............................................................................................... 23 5、附录 ....................................................................................................................... 23
最新精品资料整理推荐，更新于二〇二一年一月二十七日2021年1月27日星期三20:47:59
……………………………………………………………最新资料推荐…………………………………………………
1、概述
1.1 目的
描述公司级定义的软件生命周期模型，供项目策划时根据项目的具体情况选择或裁剪使用，由此确定软件项目开发过程的各种不同的阶段以及各阶段的执行顺序。
1.2 适用范围
适用于本公司的软件项目策划。
1.3 引用文件
•《软件开发过程程序文件》（QMS-OP01-V1.0） •《标准软件过程开发和维护》（QMS-PSM01-V1.0） •《项目策划程序文件》（QMS-PTM02-V2.0）
1.4 术语
•软件生命周期－从软件设想开始到软件不再使用而结束的时间周期。软件生命周期一般包括系统分析、软件需求分析、设计、实现、测试、验收、运行和维护各阶段，有时还包括退役阶段。
•软件过程－有关开发和维护软件及其相关产品（例如：项目计划、设计文档、代码、测试用例、用户手册等）的活动、方法、实践和变更的集合。
1.5 参考资料
•《软件工程Java语言实现》，Stephen R. Schach著，袁兆山等译，机械工业出版社，1999年9月
•《软件工程实践者的研究方法》，Roger S. Pressman著，黄柏素、梅宏等译，机械工业出版社，1999年10月
•《Software Project Management Guidebook》，Frank J. Koch著，2001年7月
最新精品资料整理推荐，更新于二〇二一年一月二十七日2021年1月27日星期三20:47:59
……………………………………………………………最新资料推荐…………………………………………………
•《实用软件工程》郑人杰、殷人昆、陶永雷著，清华大学出版社，1997年4月
•《软件需求》，Karl E. Wiegers著，陆丽娜、王忠民、王志敏等译，机械工业出版社，2000年7月
•《统一软件开发过程》，Ivar Jacobson、Grady Booch、James Rumbaugh著，周伯生、冯学民、樊东平等译，机械工业出版社，2002年1月
2、软件生命周期模型描述
所有的项目软件开发过程都应遵循一个生命周期模型，每个模型都具有能够帮助实际软件项目进行控制及协调的特征。定义生命周期模型的目的在于将本质上无序的活动有序化，在开发策划期间，必须仔细考虑项目的特征和目标之后，再选择生命周期模型。本文件根据组织内项目的类型，描述常用的几个软件生命周期模型，项目可根据实际情况选择或按规定剪裁使用，但应注意与公司的标准软件开发过程相兼容。见附录“软件过程结构图”，其中的项目软件开发过程即为一个选择瀑布模型的典型项目过程。
2.1 瀑布模型
（1）模型描述
该模型首先由Royce[1970]提出，又称线性顺序模型，包括图2－1所示的典型的几个阶段，其重要特点是：只有当一个阶段的文档已编制好，且该阶段的产品得到SQA认可后，该阶段才算完成；测试或验证在每个阶段都必须执行；一旦产品完成提交用户，其后的任何修改均属于维护阶段。
如果需求明确、能较好理解且较稳定，可以考虑选择瀑布模型。
最新精品资料整理推荐，更新于二〇二一年一月二十七日2021年1月27日星期三20:47:59
……………………………………………………………最新资料推荐…………………………………………………
系统分析 软件需求分析 设 计 实 现 测 试 验 收 维 护
图2－1 瀑布模型
（2）缺点
由于其线性顺序的特点，故只有在项目开发的后期才能得到具有全部功能的软件版本；如果有未定义或未实施的需求，将会引起重复劳动，甚至开发出的产品不是用户所需要的。
（3）本企业适合的项目类型
操作系统产品；译星产品；嵌入式产品开发；对日软件外包项目等。
2.2 原型＋瀑布模型
（1）模型描述
原型模型本身是一个迭代的模型，是为了解决在产品开发的早期阶段存在的不确定性、二义性和不完整性等问题，通过建立原型使开发者进一步确定其应开发的产品，使开发者的想象更具体化，也更易于被客户所理解。原型只是真实系统的一部分或一个模型，完全可能不完成任何有用的事情，通常包括抛弃型和进
最新精品资料整理推荐，更新于二〇二一年一月二十七日2021年1月27日星期三20:47:59
……………………………………………………………最新资料推荐…………………………………………………
化型两种，抛弃型指原型建立、分析之后要扔掉，整个系统重新分析和设计；进化型则是对需求的定义较清楚的情形，原型建立之后要保留，作为系逐渐增加的基础，采用进化型一定要重视软件设计的系统性和完整性，并且在质量要求方面没有捷径，因此，对于描述相同的功能，建立进化型原型比建立抛弃型原型所花的时间要多。原型建立确认需求之后采用瀑布模型的方式完成项目开发，原型＋瀑布模型的开发流程如图2－2所示：
部分系统软件需求 或软件需求分析 原型设计 原型实现 多次迭代原型逐渐完善 原型测试 瀑布测试 图2－2 原型＋瀑布模型
以下情形建议考虑选择原型＋瀑布模型：
a. 项目包含一种新技术，例：新硬件、新的开发语言、新的系统架构等； b. 需求不很清楚；
c. 存在关于性能、可靠性和可行性方面的主要的、未解决的问题； d. 用户界面对系统成功是很关键的，但不很清楚。 （2）缺点
由于原型并非最终产品，如果原型不能利用，可能导致成本的增加；同时会引起客户的误解，以为产品即将完成。
（3）本企业适合的项目类型
新领域的应用项目的开发；Web开发项目等。
2.3 增量模型
（1）模型描述
增量模型是一种进化软件过程模型，融合了线性顺序模型的基本成分（重复地应用）和原型模型的迭代特征，如下图所示。当使用增量模型时，第一个增量
最新精品资料整理推荐，更新于二〇二一年一月二十七日2021年1月27日星期三20:47:59
……………………………………………………………最新资料推荐…………………………………………………
往往是核心产品，即实现了基本的需求；核心产品交用户使用（或进行更详细的复审），使用和/或评估的结果是下一个增量的开发计划，该计划包括对核心产品的修改，使其能更好的满足用户的需要，并发布一些新增的特点和功能。增量模型和原型模型不一样，强调每一个增量均要发布一个可操作产品。早期的增量是最终产品的“可拆卸”版本，但能提供用户服务功能和用户评估的平台。增量模型开发流程见图2－3。
系统 分析
图2－3 增量模型
（2）缺点
由于增量模型的灵活性，往往容易退化成边做边改方法，使软件过程的控制丧失了整体性，最终的产品也不是开放的，而是成为维护人员的恶梦。
（3）本企业适合的项目类型
各种中、大规模的项目类型；已有系统技术路线发生改变但需求明确的移植类项目。
详细 增量n 设计n 实现n 测试n 验收n 详细 增量2 设计2 实现2 测试2 验收2 维护 详细 增量1 设计1 实现1 测试1 验收1 软件需求分析 软件结构设计 最新精品资料整理推荐，更新于二〇二一年一月二十七日2021年1月27日星期三20:47:59
……………………………………………………………最新资料推荐…………………………………………………
2.4 增量的迭代过程模型
（1）模型描述
该模型是一个不断迭代和增量的过程，迭代过程首先要处理一组客户的业务需求，这些业务需求合起来能够揙所开发产品的可用性。其次，迭代过程要解决最突出的风险问题。后续的迭代过程建立在前一次的迭代过程末期所产生的产品之一。一个增量不一定是对原有产品的增加，尤其在生命周期初期，开发人员可能用更加详细和更加完善的设计来代替最初简单的设计。在较后的阶段，增量通常是对原有产品的增加。采用此种模型最好是基于构件和有相应的构件开发工具（如：RUP、配置管理工具等）。
迭代3 迭代2 迭代1 系统 分析1 软件需求分析1 设计1 实现1 测试1 验收1 分析2 系统分析 n 系统 软件需求分析2 设计2 实现2 测试2 验收2 维护 软件需求分析n 设计n 实现n 测试n 验收n
图2－4 增量的迭代模型
（2）缺点
需要相当的风险评估的技术；每个迭代循环控制不好会变成边做边改模式。 （3）本企业适合的项目类型 较复杂的应用项目。
2.5 快速应用开发模型
（1）模型描述
最新精品资料整理推荐，更新于二〇二一年一月二十七日2021年1月27日星期三20:47:59
……………………………………………………………最新资料推荐…………………………………………………
快速应用开发模型（RAD）是一个线性顺序的软件开发模型，强调极短的开发周期（2－3个月）。该模型是线性顺序模型的一个“高速”变种，如果需求理解得很好，且约束了项目范围，就可通过使用基于构件或可得用软件包的建造方法获得快速开发。快速应用开发模型流程见图2－5。适用于信息系统应用软件的开发。
小组n 小组2 小组1 业务 建模1 数据 建模1 处理 建模1 应用 生成1 测试1 业务 建模2 数据 建模2 处理 建模2 应用 生成2 测试2 集成/测试 验收 维护 业务建模 n 数据 建模n 处理 建模n 应用 生成n 测试n 图2－5 快速应用开发模型
（2）缺点
对大型的、但可伸缩的项目，RAD需要足够的人力以创建足够的RAD小组。RAD要求开发者和用户在一个很短的时间内完成一个系统，如果双方中的任何一方没完成约定，都会导致RAD项目失败。
（3）本企业适合的项目类型
具有可重用的构件库和CASE工具的应用项目；信息系统等。
最新精品资料整理推荐，更新于二〇二一年一月二十七日2021年1月27日星期三20:47:59
……………………………………………………………最新资料推荐…………………………………………………
3、几种模型的比较
软件生命 周期模型 瀑布模型 原型＋瀑布模型 增量模型 增量的迭代模型 快速应用开发模型 是否首先定义好绝 大部分的需求？ 有 没有 有 没有 没有 是否有多个 开发周期？ 无 有 有 有 有 是否有 中间软件发布 无 有 可能 有 可能 4、其它模型采用说明
如果在实际工作中，基于特定项目的经验积累和总结，可能需要形成新的软件生命周期模型，此时可依照一定的规程（参见《标准软件过程开发和维护要求》、《项目策划程序文件》）将其定义和描述加入到本文件中。
5、附录
附录1 软件过程结构图
说明：图中“项目软件开发过程”一层延伸到产品退役，即体现出软件的生命周期。采用不同的生命周期模型在该层面的“系统分析”和“软件开发”阶段对应不同的过程。
最新精品资料整理推荐，更新于二〇二一年一月二十七日2021年1月27日星期三20:47:59
……………………………………………………………最新资料推荐…………………………………………………
软件过程结构图
最新精品资料整理推荐，更新于二〇二一年一月二十七日2021年1月27日星期三20:47:59
……………………………………………………………最新资料推荐…………………………………………………
软件开发过程
目 录
1、概述 ....................................................................................................................... 27 1.1 目的 ............................................................................................................... 27 1.2 适用范围 ....................................................................................................... 27 1.3 引用文件 ....................................................................................................... 27 1.4 术语 ............................................................................................................... 27 1.5 参考资料 ....................................................................................................... 28 2、过程总体描述 ....................................................................................................... 28 2.1 过程概述 ....................................................................................................... 28 2.2 结构描述 ....................................................................................................... 29 2.3 过程级裁剪指南 ........................................................................................... 30 3、过程元素 ............................................................................................................... 31 3.1 系统分析 ....................................................................................................... 31 3.2 软件需求分析 ............................................................................................... 36 3.3 结构设计 ....................................................................................................... 43 3.4 详细设计 ....................................................................................................... 46 3.5 编码 ............................................................................................................... 51 3.6 集成测试 ....................................................................................................... 54 3.7 系统测试 ....................................................................................................... 58 3.8 验收 ............................................................................................................... 61 3.9 验收 ............................................................................................................... 65 3.10 软件问题管理 ............................................................................................. 69 4、附录 ....................................................................................................................... 72 附录2.3－1 中大型软件工程项目的标准软件开发过程 ................................ 73 附录2.3－2 中小型软件工程项目的标准软件开发过程 ................................ 74 附录2.3－3 小型软件工程项目的标准软件开发过程 .................................... 75 附录3.1－1 《系统架构和业务需求说明书》文档编写规范 ........................ 76
最新精品资料整理推荐，更新于二〇二一年一月二十七日2021年1月27日星期三20:47:59
……………………………………………………………最新资料推荐…………………………………………………
附录3.1－2 《可行性分析报告》文档编写规范 ............................................ 78 附录3.1－3 《系统需求规格说明书》文档编写规范 .................................... 79 附录3.2－1 需求分析方法指南 ........................................................................ 85 附录3.2－2 结构化分析法 ................................................................................ 86 附录3.2－3 面向对象分析法（OOA） ........................................................... 87 附录3.2－4 快速原型法 .................................................................................... 88 附录3.2－5 《软件需求规格说明书》文档编写规范 .................................... 89 附录3.2－6 《测试计划》文档编写规范 ........................................................ 93 附录3.3－1 《软件结构设计说明书》文档编写规范 .................................... 95 附录3.4－1 《软件详细设计说明书》文档编写规范 .................................... 99 附录3.5－1 《测试报告》文档编写规范 ...................................................... 101 附录3.6－1 集成工作单 .................................................................................. 102 附录3.6－2 集成测试工作单 .......................................................................... 103 附录3.9－1 《软件维护实施计划》文档编写规范 ...................................... 104 附录3.10－1 软件问题报告单 ........................................................................ 105 附录3.10－2 软件问题状态登记表 ................................................................ 110
最新精品资料整理推荐，更新于二〇二一年一月二十七日2021年1月27日星期三20:47:59
……………………………………………………………最新资料推荐…………………………………………………
1、概述
1.1 目的
本程序文件定义了公司内部的软件开发过程，以指导和规范软件项目中开发过程的定义和相应的实施。
1.2 适用范围
整个公司内的软件项目。
1.3 引用文件
《过程描述文件编写规范（一）》（QMS-PSM02-V1.0） 《标准软件过程的开发和维护》（QMS-PSM01-V1.0） 《软件生命周期模型描述文件》（QMS-PSM05-V1.0） 《客户需求管理程序文件》（QMS-PTM01-V2.0） 《技术类评审程序文件》（QMS-PTM09-V1.0） 《软件配置管理程序文件》（QMS-PTM09-V1.0） 《术语》（QMS-PSM07-V1.0）
1.4 术语
•过程：把输入转换为输出的一组彼此相关的活动。 •构造：将源代码进行编译、连接、生成目标代码的过程。
•构造环境：主要指与源码一起进行编译、连接的环境，在C语言中一般是指由编译、连接命令、环境参数、操作语句等构成的一系列脚本程序的组合。
•白盒测试：基于源码进行的测试，主要的形式包括语句覆盖、分支覆盖、路径覆盖等。
•黑盒测试：基于目标代码的测试，主要的形式为功能测试。
•回归测试：对新增的功能或更正错误的部分（包括与其相关的部分）进行的测试，而不是对软件系统全面的测试。
最新精品资料整理推荐，更新于二〇二一年一月二十七日2021年1月27日星期三20:47:59
……………………………………………………………最新资料推荐…………………………………………………
其他术语参见《术语》文件。
1.5 参考资料
•《软件能力成熟度模型CMM方法及其应用》，杨一平等著，人民邮电出版社，2001年4月
•《实践中的CMM－INFOSYS公司实施软件项目之过程》，潘卡·杰罗特著，杨慧鸣、李光龙泽，2001年7月
•《Managing the Software Process》Watts S. Humphrey, Addison Wesley Longman, Inc, 1989
•《Recommended Approach to Software Development》 SEL-81-305，1992.6 •《软件需求》，Karl E. Wiegers著，陆丽那、王忠民、王志敏等译，机械工业出版社，2000年7月
•《软件工程Java语言实现》，Stephen R. Schach著，袁兆山等译，机械工业出版社，1999年9月
•《软件工程实践者的研究方法》，Roger S. Pressman著，黄柏素、梅宏等译，机械工业出版社，1999年10月
•国际－信息技术－软件生存周期过程指南 GB/T8566-2002 •军标－软件开发与文档编制 SJ20778-2000
2、过程总体描述
2.1 过程概述
软件开发过程是指软件产品开发活动中所有阶段、任务的组合。该过程可划分为一系列子过程，包括：系统分析、软件需求分析、设计、编码、测试、验收、维护，每个子过程又由一系列任务和活动组成，如设计过程又可分为结构设计和详细设计。
本程序文件描述公司通用的软件开发过程的组成（称之为“过程元素”）、彼此之间的关系（输入、输出接口），以及相应的裁剪指南。具体的软件开发项目可以根据其范围、规模和复杂度，确定软件生命周期模型，参见《软件生命周期
最新精品资料整理推荐，更新于二〇二一年一月二十七日2021年1月27日星期三20:47:59
……………………………………………………………最新资料推荐…………………………………………………
模型描述文件》；然后根据通用的软件开发过程和裁剪指南，确定项目具体的软件开发过程。
本程序文件涉及的裁剪指南分为两个层次，一层为过程级，主要针对不同的项目所采取的过程的剪裁，以定义不同的典型过程；另一层为过程元素内部，主要针对元素内部的各个任务的剪裁。
2.2 结构描述
软件开发过程在整个标准软件过程中的位置及组成见下图2.2－1。
图2.2－1 软件过程结构图
最新精品资料整理推荐，更新于二〇二一年一月二十七日2021年1月27日星期三20:47:59
……………………………………………………………最新资料推荐…………………………………………………
本程序文件所描述的软件开发过程的元素的组成见下表： 过程元素 需求分析 阶段 系统分析 软件需求分析 结构设计 详细设计 编 码 集成测试 系统测试 验 收 维 护 √ √ √ √ √ √ 每个过程元素的具体描述和工作要求见本程序文件第三节的“过程元素”描述。
√ √ √ √ 设计 实现 测试 验收 维护 2.3 过程级裁剪指南
活 动 开发过程 全过程 （附录2.3－1） 简化过程1－1 （附录2.3－2） 简化过程1－2 （附录2.3－2） 简化过程2－1 （附录2.3－3） 简化过程2－2 （附录2.3－3） 执行 执行 执行 执行 执行 执行 执行 执行 执行 执行 针对中大型软件工程项目或 系统需求明确完全自行设计、实现的项目 针对中小型软件工程项目 自编/移植软件 针对中小型软件工程项目 自由软件 针对小型软件工程项目 自编/移植软件 针对中小型软件工程项目 自由软件 可裁剪属性 选 择 裁剪指导方针 最新精品资料整理推荐，更新于二〇二一年一月二十七日2021年1月27日星期三20:47:59
……………………………………………………………最新资料推荐…………………………………………………
软件开发过程中的技术类评审方式 见《技术类评审程序文件》中相应裁剪指南 3、过程元素
以下分别对软件开发过程中的各个元素进行描述。
3.1 系统分析
3.1.1 元素概述
系统分析的目的是形成一个清楚的、完整的、一致的和可验收测试的系统需求规格说明书，与其它过程元素的关系如下图所示：
来自客户 的需求 系统分析 系统需求规格说明书 系统分配给软件的需求 软件需求分析
可行性 分析报告 系统架构和业务需求说明书 系统分配给硬件的需求 硬件设计、实现、集成 来自客户的需求可以是招标书、项目说明书或意向书等任何形式的客户需求。系统分析是整个软件生命周期的开始，应分析待开发系统特定的预期使用要求，以规定系统需求。
在此阶段，系统工程组要用一种反复迭代的方法逐渐扩充、完善系统需求，使其达到完整；对系统结构进行设计，建立系统的顶层结构，并标出硬件部分、软件部分和人工操作部分。应确保所有系统需求分配到各部分中。分配以各部分的系统需求及其相关系统结构应形成文档，对软件必须要实现的每个功能和每个要满足的关键点进行详细描述。
最新精品资料整理推荐，更新于二〇二一年一月二十七日2021年1月27日星期三20:47:59
……………………………………………………………最新资料推荐…………………………………………………
通过实施本过程元素，完成《系统架构和业务需求说明书》（附录3.1－1）《可行性分析报告》（附录3.1－2）和《系统需求规格说明书》（附录3.1－2），为软硬件开发人员正确建立所要求的系统提供基础。
如上图所示，《系统需求规格说明书》应包括分配到软件部分的需求和分配到硬件部分的需求两部分。但在本文件中，如无特别说明，系统需求均指系统分配给软件部分的需求，也属于客户需求；《系统需求规格说明书》均指系统分配给软件部分的需求的规格说明书。 3.1.2 入口准则和出口准则
（1）入口准则
要 素 招标书、项目说明书或意向书等客户需求 （2）出口准则
要 素 可行性分析报告 判断准则 经过评审并批准执行 判断准则 已接受 系统架构和业务需求说明书 进行了评审并经SCCB批准作为客户需求系统需求规格说明书 评审发现的问题 3.1.3 任务
（1）系统架构和业务需求定义及系统可行性分析，具体过程如下图所示： 来自客户的需求 来自早期 项目的文档 来自客户 基线 已关闭 系统架构识别 系统架构和 业务需求书 最新精品资料整理推荐，更新于二〇二一年一月二十七日2021年1月27日星期三20:47:59 的需求 重用分析 业务需求定义 系统架构和 业务需求评审 可行性分析 可行性分析报告 ……………………………………………………………最新资料推荐…………………………………………………
a. 系统架构识别
•收集和逐条列出所有系统的高层需求（指最高层的产品业务目标）。 •描述满足这些高层需求系统必须实施的基本功能，着重从系统寿命（使用期限）、性能、安全、可靠性和数据项等方面的问题去考虑。
•通过这些功能描述，得到识别软件程序和所有主要接口的系统架构。 •详细说明所有主要数据接口的格式（如：文件、显示、打印输出等）。 b. 重用分析
•如果客户要求的功能与已有的产品很相似，则可评审已有的产品的《系统架构和业务需求说明书》、《系统需求规格说明书》、《用户手册》和相关源代码等来识别重用候选项。选择较强的候选荐并估算相应的成本，评价其可靠性等，根据将开发项目的具体情况，对是否选用重用项作出一个相对折中的选择 。
•调整体系结构来说明采用的可重用软件，把所有重用分析的结果以重用建议的形式记录下来，写入《系统架构和业务需求说明书》文档中。
c. 业务需求定义
•清楚地定义系统必须如何在其业务环境下运行，包括针对所有主要业务模式的业务方案脚本，又称使用实例。形成的描述写入《系统架构和业务需求说明书》文档。
•由于最终用户是系统的直接使用者，需要时可请他们作为产品代表，帮助建立业务方案脚本。
d. 系统架构和业务需求的评审
•就系统架构和业务需求请系统和领域专家进行评审。 e. 可行性分析
•在上述结果的基础上，进一步分析高层需求，从技术、经济、商业以及管理等方面进行可行性研究。
•编写《可行性研究报告》。
•对可行性分析报告进行评价，作出项目是否可行的判断和决策。如果项目可行，则进入下一过程；否则终止系统分析。
（2）开发系统需求
系统需求的开发过程如下图所示。
最新精品资料整理推荐，更新于二〇二一年一月二十七日2021年1月27日星期三20:47:59
……………………………………………………………最新资料推荐…………………………………………………
可行性 分析报告 细化需求 开发系统需求 系统需求规格 说明书评审 系统架构和 业务需求说明来自早期 项目的信息
系统需求规格 说明书
a. 细化需求
•基于高层需求和系统概念及体系结构，向下定义子系统层的所有需求，即细化的用户工作流程。如果系统很大（有很多子系统）或如果将与其它系统接口，就要清楚地定义所有外部接口。
•确定系统性能和可靠性需求。如果某个接受准则对应到某条需求（如：满足特定的响应时间），则需说明这条需求的测试准则。
b. 编写系统需求规格说明书
•在用户已有业务系统的层面，识别需要满足需求的输入和输出的数据，用结构化或面向对象的分析方法，派生出软件必须实施的底层功能和算法。定义所有的文件、报告和显示等，并指出哪些数据用户必须能够修改等。
•保持设计和语言的中立性，即集中在软件需要做什么方面，而不是怎么做。 •创建一个追溯矩阵来映射每个底层的功能或数据说明使其能够得到实现。 •将上述结果形成文件，完成《系统需求规格说明书》的编写，作为软件开发的基础。
c. 系统需求规格说明书评审
•对《系统需求规格说明书》进行同行评审。
评审后的《系统需求规格说明书》必须经SCCB批准，作为需求基线，纳入配置库。 3.1.4 工作产品
最新精品资料整理推荐，更新于二〇二一年一月二十七日2021年1月27日星期三20:47:59
……………………………………………………………最新资料推荐…………………………………………………
•《系统架构和业务需求说明书》 •《可行性分析报告》 •《系统需求规格说明书》
•《追溯表》（MT-PTM01B）（MT-PTM01C） 3.1.5 职责
（1）系统工程组：负责完成本过程元素所要求的所有活动，并填写《追溯表》（见《客户需求管理程序文件》）。
（2）项目经理：负责制订系统分析阶段的计划（在执行过程中可能需要进行计划修订）；管理、度量此过程，并负责安排同行评审。
（3）SCM：统计已定义的需求项的个数和已进行说明的需求的百分比，填写《客户需求统计表》（见《客户需求管理程序文件》）。 3.1.6 资源和能力要求
•必要的培训资源 •支持系统需求分析的设备 •支持系统需求分析的工具 3.1.7 度量
•统计已定义的需求项的个数和已进行说明的需求的百分比 •质量（同行评审缺陷统计） •完成本元素的工作所花费的工时 3.1.8 详细裁剪指南
最新精品资料整理推荐，更新于二〇二一年一月二十七日2021年1月27日星期三20:47:59
……………………………………………………………最新资料推荐…………………………………………………
活 动 可裁剪属性 选 择 裁剪指导方针 系统构架和业务需求定义及系统可行性分析 系统架构识别 执行 执行 不执行 进行重用分析 执行 执行 不执行 业务需求定义 文档 执行 执行 不执行 编写 不编写 新项目或有新的需求的项目 无需修改客户需求的项目 有可重用构件库或是已有版本的产品 新产品或无可重用构件库 新项目或要修改业务需求定义的项目 无需修改业务需求定义的项目 规模较大的、复杂的项目 规模较小的项目或快速原型开发； 可与系统需求规格说明书合并。 系统架构和业务需求说明书评审 可行性分析 文档 不编写 执行 执行 不执行 编写 执行 执行 不执行 规模较大的、复杂的项目 规模较小的项目可不进行，将其放到系统需求说明规格说明书中一起评审。 对系统需求能否实现不清楚 对系统需求能否实现清楚 规模较大、较复杂的项目上，执行了可行性分析活动，要求出此报告。 规模较小、无需执行可行性分析活动；或规模较大、较复杂的项目，执行了可行性分析活动，但不要求单独出此报告，可合并到系统需求规格说明书中。 开发系统需求 细化需求 执行 执行 不执行 新项目或需求需要进一步细化的项目 针对旧项目，细化的需求已存在 3.2 软件需求分析
3.2.1 元素概述
最新精品资料整理推荐，更新于二〇二一年一月二十七日2021年1月27日星期三20:47:59
……………………………………………………………最新资料推荐…………………………………………………
软件需求分析是按照项目定义的软件开发过程，根据系统分配给软件的需求（见《系统需求规格说明书》），进行软件质量特性规格说明的过程。该过程包括进一步明确软件运行环境，明确对软件的功能、性能和数据要求，以及软件与硬件、软件与软件之间的接口要求等，并对软件需求进行验证和文档化，即完成对软件需求的分析与规格定义。有关软件需求的变更管理，请参见《软件配置管理程序文件》。
本元素在整个过程中的位置如下图所示：
3.2.2 入口准则和出口准则
（1）入口准则
要 素 判断准则 系统分配给软件的需求 软件需求分析 结构设计 客户需求（《系统需求规格说明书》） •已由SCCB批准为基线 •已进入配置库 （2）出口准则
要 素 软件需求规格说明书 •已经过审查 •已批准为开发基线 •已进入配置库 系统测试计划 系统测试案例 •已经过审查 •已获得批准 •已进入配置库 用户手册（概要） •已编写 判断准则 最新精品资料整理推荐，更新于二〇二一年一月二十七日2021年1月27日星期三20:47:59
……………………………………………………………最新资料推荐…………………………………………………
3.2.3 任务
各工作阶段如下图所示：
（1）准备阶段
a. 必要时对软件需求分析员进行相关培训（包括有关的技术和业务知识培训，以及有关的工具使用培训）。
b. 审查客户需求，识别并解决影响软件需求的问题。
c. 选择适当的需求分析方法（参见附录3.2－1、附录3.2－2、附录3.2－3、附录3.2－4），并准备相应的分析工具。
建议采用的需求分析方法包括：结构化分析法、面向对象分析法和快速原型法等。如果需要采用上述分析法以外的其它需求分析法，应该得到SEPG的批准。
•结构化分析法
采用结构化的分析技术。后续过程（设计、实现）通常也应该采用结构化技术。
适用于中、小规模的软件项目。 •面向对象分析法
采用面向对象的分析技术。后续过程（设计、实现）通常也应该采用面向对象技术。
适用于各种规模的软件项目。 •快速原型法
借助快速开发工具，以提供原型的方式，迅速掌握客户对软件的需求。 适用于客户描述不清楚对软件的全部或部分需求。
建立满足客户需求的原型后，根据所采用的工具和实际需要确定是否重新进行软件需求规格定义。快速原型不能作为惟一的软件需求规格表达方式，必须辅之以
最新精品资料整理推荐，更新于二〇二一年一月二十七日2021年1月27日星期三20:47:59
系统分配给 软件的需求 准备 收 集 评 审 软件需求 规格说明书 定 义 • 分 析 ……………………………………………………………最新资料推荐…………………………………………………
适当的软件需求规格说明书。
快速原型法可以与结构化分析或面向对象分析技术结合使用。 （2）收集、分析阶段
本阶段需要与客户不断接触、协商。通过对收集到的信息进行分析、归纳，界定出对软件的需求，明确在目标产品中需要什么和以什么形式来表现。
与客户交流的基本形式通常有两种：客户访谈调查（正式的和非正式的）、书面调查（书面报告和调查表）。此外，通过对客户使用的表格和所处的情景进行分析，从而获取需求，也是常用的方法。这些方法对前面推荐的三种需求分析中采用的分析法与后续过程的设计和实现方法有一定的关联关系，通常应该保持所选用的表达方法一致。详见需求分析方法指南。
除了调查客户正常业务处理要求以外，特别需要关注的是异常处理和例外处理要求。这些处理要求往往在软件需求中占有很大的比例，却容易被忽视。
收集、分析可重用的软件或功能模块，确定可用项。 本阶段的工作步骤如下：
•编制工作计划，特别是与受访者协商确定调查、访谈日程安排。 •运用选定的需求分析方法，收集、识别是、导出软件需求。 •收集、筛选、确定可能重用的软件或功能模块。 （3）定义阶段
a. 根据软件需求分析结果，选择适当的实现方案并说明选择理由，形成软件系统的初步设计方案（包括对系统体系结构、数据体系结构和接口的初步设计）。
b. 描述软件需求规格，编制《软件需求规格说明书》（附录3.2－5）。 c. 编制用于验证和确认软件需求是否得到满足的方法－《系统测试计划》和《系统测试案例》，测试计划的编写规范见附录3.2－6。
d. 建立《用户手册》（概要）。
e. 填写追溯表。参见《客户需求管理程序文件》。 （4）评审阶段
a. 评审《软件需求规格说明书》，具体评审过程见《技术类评审程序文件》，对软件需求的评审准则包括：
•系统需求和系统设计的可追溯性；
最新精品资料整理推荐，更新于二〇二一年一月二十七日2021年1月27日星期三20:47:59
……………………………………………………………最新资料推荐…………………………………………………
•与系统需求的外部一致性； •内部一致性； •可测试性；
•软件设计的可行性； •运作和维护的可行性。
b. 对软件需求中的问题，与系统工程组或客户一起确定和审查，并对客户需求和软件需求做出适当的更改。
c. 对软件需求规格说明书进行同行评审。
d. 审查、批准软件需求规格说明书，必要时，对其进行设计评审。 e. 将软件需求规格说明书置于配置管理之下。
当客户需求变更，需要对软件需求做相应的更改时，进行变更控制。参见《软件配置管理程序文件》。 3.2.4 工作产品
•《软件需求规格说明书》 •《系统测试计划》 •《系统测试案例》 •《用户手册》（概要）
•《追溯表》（MT-PTM01B）（MT-PTM01C） 3.2.5 职责
•项目经理：负责选择合适的软件需求分析员，组建软件需求工作组；确定是否需要对有关人员进行培训；负责软件需求规格说明书的审查和批准。
•软件需求分析员：软件需求阶段工作的主要承担者。负责完成本过程元素产生的所有工作产品。
•系统测试负责人：负责组织软件系统测试组对软件需求进行分析，审查软件需求的可测试性；参与软件需求规格说明书的审查和批准。
•质量保证人员：参与工作产品的审查，统计缺陷，并对软件需求分析过程进行审计。
•系统工程人员：配合处理涉及客户需求的软件需求问题。
•系统工程负责人：负责组织系统工程组对软件需求进行分析，审查软件需求的可测试性；负责协调处理涉及客户需求的软件需求问题；参与软件需求规格
最新精品资料整理推荐，更新于二〇二一年一月二十七日2021年1月27日星期三20:47:59
……………………………………………………………最新资料推荐…………………………………………………
说明书的审查和批准。
•客户：参与软件需求规格说明书的审查和批准。 3.2.6 资源和能力要求
•必要的培训资源 •支持软件需求的设备 •支持软件需求的工具 3.2.7 度量
•需求状态统计
•质量（同行评审缺陷统计） •完成本元素的工作所花费的工时
最新精品资料整理推荐，更新于二〇二一年一月二十七日2021年1月27日星期三20:47:59
……………………………………………………………最新资料推荐…………………………………………………
3.2.8 详细裁剪指南 活 动 培训 培训 执行 执行 如果软件需求分析人员对需求分析方法及有关的工具使用或对软件需求所针对领域的业务知识缺乏了解，则必须进行相关培训。 不执行 软件需求分析 软件需求分析 快速 原型法 方法 面向对象分析法 结构化 分析法 采用结构化的分析技术。后续过程（设计、实现）通常也应该采用结构化技术。 适用于中、小规模的软件项目。 详见附录3.2－1需求分析方法指南。 采用面向对象的分析技术。后续过程（设计、实现）通常也应该采用面向对象技术。 适用于各种规模的软件项目。 详见附录3.2－1需求分析方法指南。 借助快速开发工具，以提供原型的方式，迅速掌握客户对软件的需求。 适用于客户描述不清楚对软件的全部或部分需求。 详见附录3.2－1需求分析方法指南。 评审 设计评审 执行 执行 不执行 测试 系统测试案例 文档 单独编写 规模较大的项目。 重要的或技术难度较高的软件项目。 其它软件项目。 软件需求分析人员已经具备相关知识。 可裁剪属性 选 择 裁剪指导方针 不单独编写 小型项目，可以与系统测试计划合并。 最新精品资料整理推荐，更新于二〇二一年一月二十七日2021年1月27日星期三20:47:59
……………………………………………………………最新资料推荐…………………………………………………
3.3 结构设计
3.3.1 元素概述
结构设计是指按照《软件需求规格说明书》，设计软件系统的体系结构，即模块结构，定义每个模块的主要功能和模板之间的联系（即接口），并确定软件系统的数据体系结构。
本元素在整个过程中的位置如下图所示：
3.3.2 入口准则和出口准则
（1）入口准则：
要 素 软件需求规格说明书 •经过审查 •审查获得批准 •进入配置库 （2）出口准则：
要 素 结构设计说明书 集成测试计划 •经过审查 •审查获得批准 •进入配置库 3.3.3 任务
最新精品资料整理推荐，更新于二〇二一年一月二十七日2021年1月27日星期三20:47:59
软件需求分析 结构设计 详细设计 判断准则 判断准则 软件需求 规格说明书 准备 分析 评 审 • 批准 结构设计 说明书 编制 • 设计 ……………………………………………………………最新资料推荐…………………………………………………
（1）准备阶段
根据《软件需求规格说明书》，对软件需求的分析结果进行评估。 •对软件需求阶段所产生的初步设计方案进行评估； •检查重用软件，核实它们与整个系统需求是否相符；
•根据《软件需求规格说明书》，对未确定需求进行评估，确定对策。 （2）分析、设计阶段
对《软件需求规格说明书》进行分析的基础上，使用结构化或面向对象的方法进行结构设计。主要包括三个方面的工作－系统体系结构、数据体系结构以及接口的设计。
a. 系统体系结构设计
•扩充软件需求阶段所提出的初步的系统体系结构。对扩展后的体系结构进行完善，降低那些使软件难于实现、测试、维护和重用的因素，形成高内聚、低耦合的系统体系结构。
b. 数据体系结构设计
•扩展软件需求阶段所提出的初步的数据体系结构，将其变换成实现软件所需的数据结构。
c. 接口设计
•扩展软件需求阶段所提出的初步的接口，将其变换成实现软件所需的接口； •设计软件模块间的接口；
•设计人和计算机间的接口（即人机界面）。 （3）编制阶段
a. 根据分析和设计的结果，编制《软件结构设计说明书》（附录3.3－1）。 b. 编制结构设计的验收准则－《集成测试计划》和《集成测试案例》，确定用于验证和确认结构设计是否得到满足的方法；包括集成步骤和方法。测试计划编写规范见附录3.2－6。
验证和确认的方法包括：演示、集成测试、验证测试、分析和审查等。 c. 定义错误处理和恢复策略，确定用户的输入、显示，更新软件需求阶段建立的初步的《用户手册》。
d. 填写追溯表。参见《客户需求管理程序文件》。 （4）评审、批准阶段
最新精品资料整理推荐，更新于二〇二一年一月二十七日2021年1月27日星期三20:47:59
……………………………………………………………最新资料推荐…………………………………………………
a. 对《结构设计说明书》和《集成测试计划》进行同行评审。
b. 对结构设计中的问题，与软件需求分析人员一起确定和审查，并对结构设计进行适当的更改。
c. 审查、批准《结构设计说明书》，必要时，对其进行设计评审。 d. 将《结构设计说明书》、《集成测试计划》和《集成测试案例》置于配置管理之下。 3.3.4 工作产品
•《结构设计说明书》 •《集成测试计划》 •《集成测试案例》 •《用户手册》（初步）
•《追溯表》（MT-PTM01B）（MT-PTM01C） 3.3.5 职责
•项目经理：
*负责选择合适的设计人员，组建结构设计工作组。
*负责《结构设计说明书》和《集成测试计划》的审查和批准。
•结构设计人员：结构设计阶段工作的主要承担者，负责完成本过程元素产生的所有工作产品。
•系统分析员：配合处理涉及软件需求的问题。 •系统工程负责人：
*负责组织系统工程组对结构设计进行分析，审查结构设计的可测试性； *负责协调处理涉及软件需求的问题；
*参与《结构设计说明书》和《集成测试计划》的审查和批准。 •软件测试负责人：
*负责组织软件测试组对结构设计进行分析，审查结构设计的可测试性； *参与《结构设计说明书》和《集成测试计划》的审查和批准。 3.3.6 资源和能力要求
•结构设计所需要的人力 •结构设计所需要知识的培训 •结构设计所需要的设备
最新精品资料整理推荐，更新于二〇二一年一月二十七日2021年1月27日星期三20:47:59
……………………………………………………………最新资料推荐…………………………………………………
•支持结构设计的开发工具 3.3.7 度量
•质量（评审发现的缺陷数、缺陷的检出率） •完成本元素的工作所花费的工时 3.3.8 详细裁剪指南 活 动 组建设计组 培训 规模 多个小组 系统规模大、技术难度高 单一小组 系统规模小、技术难度一般 结构设计 系统体系结构的结构设计 执行 重用构件的 性能模拟 评审 设计评审 执行 执行 不执行 测试 集成测试案例 文档 单独编写 复杂软件集成 重要的或技术难度较高的软件项目 其它软件项目 执行 不执行 执行 执行 不执行 1、如果软件需求阶段所获得初步的系统体系结构已经足够满足需要 2、已由客户获得 3、旧系统改造、系统体系结构不需更改 其它情况 系统响应要求不高 其它情况 可裁剪属性 选 择 裁剪指导方针 不单独编写 简单软件集成，可以与集成测试计划合并 3.4 详细设计
3.4.1 元素概述
详细设计是根据《结构设计说明书》进行模块设计，将结构设计所获得的模块按照单元、程序、规程的顺序逐步细化。详细定义各个单元的数据结构、程序的实现算法以及程序、单元、模块之间的接口等，作为以后编码工作的依据。
最新精品资料整理推荐，更新于二〇二一年一月二十七日2021年1月27日星期三20:47:59
……………………………………………………………最新资料推荐…………………………………………………
本元素在整个过程中的位置如下图所示：
3.4.2 入口准则和出口准则
（1）入口准则：
要 素 结构设计说明书 •经过审查 •审查获得批准 •进入配置库 （2）出口准则：
要 素 详细设计说明书 单元测试计划 •经过审查 •审查获得批准 •进入配置库 3.4.3 任务
结构设计 准备 分析 评 审 详细设计 说明书 结构设计 详细设计 编码 判断准则 判断准则 • 设计 编制 • 批准
说明书 根据已批准的《结构设计说明书》，详细定义各个模块的数据结构、算法、接口等，编写《详细设计说明书》（附录3.4－1）和《单元测试计划》，测试计划编写规范见附录3.2－6。
（1）准备阶段
根据《结构设计说明书》，对结构设计的设计方案进行评估。 （2）分析、设计阶段
最新精品资料整理推荐，更新于二〇二一年一月二十七日2021年1月27日星期三20:47:59
……………………………………………………………最新资料推荐…………………………………………………
a. 根据《结构设计说明书》，扩展结构设计阶段所定义的系统体系结构。按照单元、程序、过程的顺序逐步细化，将各个子系统成功地精化到每个元素构件实现一个简单的功能，并且能被编写成为一个单一的单元。
设计内容还包括对将程序、单元、模块各部分逐步构成造成一个完整系统的构造环境的要求，即按照程序、单元、模块的顺序确定集成方法。
b. 确定每个单元的实现算法
•确定每个单元所包含程序的实现算法和处理流程。 c. 重用单元的检查
•识别来自软件重用库的单元是否重用，根据必要修改这些单元的算法和处理流程。
（3）编制阶段
a. 根据分析和设计的结果，编制《详细设计说明书》；
b. 编制详细设计的验收准则－《单元测试计划》和《单元测试案例》，确定用于验证和确认详细设计是否得到满足的方法；
验证和确认的方法包括：演示、集成测试、验证测试、分析和审查等； c. 审查、批准《详细设计说明书》，必要时，对其进行设计评审； d. 更新《用户手册》
•对于每个子系统指定详细的输入和输出格式，例如：显示，打印机和描图仪的输出，以及数据储存。
（4）评审、批准阶段
a. 对《详细设计说明书》和《单元测试计划》可进行走查或（和）同行评审；
b. 对详细设计中的问题，与结构设计人员一起确定和审查，并对详细设计做出适应的更改；
c. 审查、批准《详细设计说明书》，必要时，对其进行设计评审； d. 将《详细设计说明书》和《单元测试计划》置于配置管理之下。 3.4.4 工作产品
•《详细设计说明书》 •《单元测试计划》 •《单元测试案例》
最新精品资料整理推荐，更新于二〇二一年一月二十七日2021年1月27日星期三20:47:59
……………………………………………………………最新资料推荐…………………………………………………
•《用户手册》
•《追溯表》（MT-PTM01B）（MT-PTM01C） 3.4.5 职责
•项目经理：
*负责选择合适的设计人员，组建详细设计组。
*负责《详细设计说明书》和《单元测试计划》的审查和批准。
•详细设计人员：详细设计阶段工作的主要承担者。负责完成本过程元素产生的所有工作产品。
•系统分析员：配合处理涉及软件需求的问题。 •系统工程负责人：
*负责组织系统工程组对详细设计进行分析，审查详细设计的可测试性； *负责协调处理涉及软件需求的问题；
*参与《详细设计说明书》和《单元测试计划》的审查和批准。 •软件测试经理：
*负责组织软件测试组对详细设计进行分析，审查详细设计的可测试性； *参与《详细设计说明书》和《单元测试计划》的审查和批准。 3.4.6 资源和能力要求
•详细设计所需要的人力 •详细设计所需要知识的培训 •详细设计所需要的设备 •支持详细设计的开发工具 3.4.7 度量
•工时
•质量（评审缺陷统计）
最新精品资料整理推荐，更新于二〇二一年一月二十七日2021年1月27日星期三20:47:59
……………………………………………………………最新资料推荐…………………………………………………
3.4.8 详细裁剪指南 活 动 组建设计组 设计组规模 规模 多个小组 系统规模大、技术难度高 单一小组 系统规模小、技术难度一般 详细设计 系统体系结构的详细设计 执行 数据体系结构的详细设计 执行 评审 走查或（和） 同行评审 方法 走查 小型、简单软件项目 执行 不执行 执行 不执行 1、如果结构设计阶段所获得系统体系结构已经足够满足需要 2、由客户获得 3、旧系统改造、系统体系结构不需更改 其它情况 1、小项目，且数据体系结构足够满足需要 2、已由客户获得 3、旧系统改造、数据体系结构不需更改 其它情况 可裁剪属性 选 择 裁剪指导方针 同行评审 大中型、一般软件项目 走查和 同行评审 重要软件项目 设计评审 执行 执行 不执行 重要的或技术难度较高的软件项目 其它软件项目 测试 单元测试计划 文档 编写 不编写 单元测试案例 文档 单独编写 由独立的单元测试人员进行单元测试 由编程人员自己进行单元测试 复杂功能单元 不单独编写 简单功能单元，可以与单元测试计划合并 最新精品资料整理推荐，更新于二〇二一年一月二十七日2021年1月27日星期三20:47:59
……………………………………………………………最新资料推荐…………………………………………………
3.5 编码 3.5.1 元素概述
编码阶段主要完成的工作是根据详细设计说明书编写程序源代码，包括必要的数据文件，并进行单元测试，单元测试的内容包括模块内程序的逻辑、功能、参数传递、变量引用、出错处理等方面。
本元素在整个过程中的位置如下图所示：
3.5.2 入口准则和出口准则
（1）入口准则：
要 素 详细设计说明书 单元测试计划 •经过审查 •审查获得批准 •进入配置库 （2）出口准则：
要 素 源代码文件 源代码文件清单 单元测试报告 软件问题报告单 判断准则 •源代码文件获得批准 •源代码文件进入配置库的源代码区 •提交测试负责人 •提交问题管理渠道 判断准则 详细设计 详细设计 集成测试 最新精品资料整理推荐，更新于二〇二一年一月二十七日2021年1月27日星期三20:47:59
……………………………………………………………最新资料推荐…………………………………………………
3.5.3 任务
各工作阶段如下图所示： 详细设计说明书 详细设计说明书 单元测试计划 单元测试计划 准备 代码编制 单元测试 源程序文件 单元测试报告 软件问题报告单 审查
（1）准备阶段 •培训
*根据员的实际水平进行有关编程语言、编程规范、编程方法、编程工具、调试方法、配置管理等方面的培训；
*根据测试人员的实际水平进行有关测试方法、测试工具、问题汇报方法等方面的培训；有关被测产品的功能培训。
•准备开发及测试工具和环境，如有必要在各编码组内对临时的编译环境和调试方法进行约定。
（2）编制阶段
•程序员依据详细设计，进行程序单元的编制工作（包括建立相关的构造环境），并自行检查；在无特殊要求下，单元测试也可由编程者进行，参见裁剪指南。将编制的源代码文件提交审查。
•在更正测试问题时，修改源码，提交新的源码文件。 （3）审查阶段
•对源代码文件进行同行评审，主要的方法为对照详细设计说明书对代码进行查阅，也可根据编程者的经验或程序的难度、重要程度，选择走查评审方式，但目的都是发现程序存在的问题。
•在更正测试问题的情况下，在更正发现的问题之后，对源代码文件进行批准，并将其提交配置库的源代码区中。
（4）单元测试阶段
•从配置库获取源码文件，对照单元测试计划和测试用例进行测试，并将测试结果记录于测试报告（见附录3.5－1）。对源码文件进行的测试，视程序存在
最新精品资料整理推荐，更新于二〇二一年一月二十七日2021年1月27日星期三20:47:59
……………………………………………………………最新资料推荐…………………………………………………
缺陷的情况，可能要重复进行，直至问题解决。
•将测试中发现的缺陷/问题记录于问题报告单，提交测试负责人，并进入问题管理渠道，以便相应的开发人员进行更正，见3.10测试问题管理。
•单元测试的执行者，一般情况下可由程序的编码者进行，特殊情况可由独立于编码者的测试人员进行。 3.5.4 工作产品
•源代码文件 •《单元测试报告》
•《软件问题报告单》（MT-OP01C） •《软件问题状态登记表》（MT-OP01D） 3.5.5 职责
•项目经理
*建立编码组、测试组或相应岗位，并进行必要的培训； *跟踪进度和问题解决状态；
*对提交的源代码进行批准（或指定负责人进行批准工作）。
•程序员：编写和修改程序代码（包括自行测试），提交工作产品，批准后将其配置入配置区的源码库。
•单元测试人员：测试源代码，提交测试报告和软件问题报告单。
•评审人员：负责对指定源代码进行阅读，发现缺陷和问题，填写评审报告。 3.5.6 资源和能力要求
•编码及单元测试所需要的软硬件开发环境和编程/测试人员； •必要的编程/测试培训。 3.5.7 度量
项目经理负责进行以下统计：
•源程序总量（总代码行数或功能点等规模测量值）； •发现的缺陷总数； •编码工时和审查工时； 3.5.8 详细裁剪指南
最新精品资料整理推荐，更新于二〇二一年一月二十七日2021年1月27日星期三20:47:59
……………………………………………………………最新资料推荐…………………………………………………
活 动 培训 编程语言、编程规范、编程方法、编程工具、调试方法、配置管理 测试方法、测试工具、问题汇报方法 执行 不执行 执行 对单元测试有经验的团队 对单元测试缺乏经验的团队，或采用新的工具的情况 不单独编写 简单功能单元，可以与单元测试计划合并 执行 不执行 执行 对开发环境和编程语言等有经验的团队 对开发环境和编程语言等缺乏经验的团队，或采用新的编程语言、工具的情况 可裁剪属性 选 择 裁剪指导方针 3.6 集成测试 3.6.1 元素概述
集成测试阶段主要完成的工作是集成和集成测试。集成是参考结构设计说明书并根据详细说明书中规定的系统集成方案将不同的测试的程序单元进行构造，并逐步构造成一个完整的软件产品的过程；集成测试则是在集成完成之后，对各单元、模块之间接口的正确性和集成后功能的正确性进行验证。对于大型软件，集成测试可以采取分步进行的方法，例如可以先对各子系统进行集成测试，然后在子系统之间进行集成测试。
本元素在整个过程中的位置如下图所示：
3.6.2 入口准则和出口准则
编码 集成测试 系统测试 最新精品资料整理推荐，更新于二〇二一年一月二十七日2021年1月27日星期三20:47:59
……………………………………………………………最新资料推荐…………………………………………………
（1）入口准则：
要 素 结构设计说明书 详细设计说明书 集成测试计划 源代码文件 （2）出口准则：
要 素 集成的软件系统 （完整的源代码和目标代码） 集成测试报告 软件问题报告单 3.6.3 任务
结构设计说明书 详细设计说明书 准备 构造 判断准则 •经过审查 •获得批准 •进入配置库 判断准则 •获得批准 •进入配置库 •提交集成测试负责人 •已进入软件问题管理流程 审查 集成测试 集成的软件系统 集成测试报告 软件问题报告单 集成测试计划 源代码文件 （1）准备阶段是： •培训
*根据编程人员的实际水平进行有关程序语言、集成方法、版本控制工具、构造工具和配置管理工具的培训；
*根据测试人员的实际水平进行有关测试方法、测试工具、测试问题汇报方法等方面的培训。
•准备构造环境；
•向项目组发布集成日程及源码库冻结时间表；
最新精品资料整理推荐，更新于二〇二一年一月二十七日2021年1月27日星期三20:47:59
……………………………………………………………最新资料推荐…………………………………………………
•准备测试工具和环境。 （2）构造阶段
•在每次集成前，根据详细设计中的集成方法和步骤（如自顶向下，自底向上，面向对象等集成方法），集成负责人负责制定集成工作表单（见附录3.6－1），其中列出分步集成的程序清单、配置区的获取源、集成时间表、源码库冻结计划、集成结果的版本号或标识名，并将该工作表单发布给所有项目的开发人员和管理人员；
•冻结相关的源代码库；
•分步骤将各部分的程序源代码导入集成环境，进行编译和链接或等同的构造操作（针对非过程化的编程语言）；
•记录构造过程中出现的问题。如果问题属构造环境不完善，则完善构造环境；如果问题属于源代码文件级（包括局部构造环境）的问题，则填写软件问题报告单，汇报出现的问题；问题解决后，重复构造过程，直至构造完成；每次构造需标识每次构造的版本号；
•构造结束或源代码导入集成环境的过程结束（取决于代码配置管理机制），开放源代码库；
•将工作产品提交审查。 （3）审查阶段
•核查集成状态和结果，并进行批准；
•批准后，将目标程序和程序清单进入目标代码库。 （4）集成测试阶段
•在每次集成测试前，集成测试负责人负责制定集成测试工作表（见附录3.6－2），其中列出当次集成测试的类型、程序名及标识号（对应集成结果）、范围、时间表、参加人员和分工，并将该工作表单发布给所有项目的开发人员和管理人员；
•从目标代码库获取程序目标码，对照集成测试计划进行测试，并将测试结果记录于测试报告（测试报告编写规范见附录3.5－1）；
•将测试中发现的缺陷/问题记录于软件问题报告单，提交测试负责人，并进入软件问题管理流程，以便由相关的开发人员进行更正，见3.10测试问题管理；
•集成测试视程序存在缺陷的情况，可能要重复进行，直到问题解决；每当
最新精品资料整理推荐，更新于二〇二一年一月二十七日2021年1月27日星期三20:47:59
……………………………………………………………最新资料推荐…………………………………………………
测试软件或软件的环境发生变化时，应适当进行回归测试。 3.6.4 工作产品
•集成后的系统目标代码（包括文件清单），及相应的源代码（包括文件清单） •集成测试报告
•《软件问题报告单》（MT-OP01C） •《软件问题状态登记表》（MT-OP01D） •《集成工作单》（MT-OP01A） •《集成测试工作单》（MT-OP01B） 3.6.5 职责
•项目经理：建立集成组、集成测试组或相应岗位，并进行必要的培训；跟踪进度和问题解决状态；对集成后的系统目标码进行批准（或指定负责人进行批准工作）。
•集成负责人员：负责集成过程的实施。
•集成人员：负责环境构建，集成的过程操作，并将集成后的目标代码提交批准。
•程序员、设计人员：修改源码或设计，解决集成过程中出现的与源码有关的问题。
•测试人员：测试系统目标码，将测试报告和软件问题报告单提交测试负责人。
3.6.6 资源和能力要求
•集成环境、测试工具、人力设备资源 •相关的版本维护管理的培训 •集成策略及目标代码的版本维护 3.6.7 度量
项目经理负责进行以下统计： •发现的缺陷总数及解决的缺陷总数； •集成及集成测试的工时； •进度完成情况。
最新精品资料整理推荐，更新于二〇二一年一月二十七日2021年1月27日星期三20:47:59
……………………………………………………………最新资料推荐…………………………………………………
3.6.8 详细裁剪指南 活 动 培训 程序语言、集成方法、版本管理工具、构造工具和配置管理工具的培训 培训 测试方法、测试工具、问题汇报方法 执行 不执行 执行 对单元测试有经验的团队 对单元测试缺乏经验的团队，或采用新的工具的情况 执行 不执行 执行 有集成背景的团队 对开发环境和编程语言等缺乏经验的团队，或采用新的编程语言、工具的情况 可裁剪属性 选 择 裁剪指导方针 3.7 系统测试 3.7.1 元素概述
系统测试的主要任务是从系统需求的角度对系统运行的正确性和性能进行验证。系统测试的依据为系统测试计划。
本元素在整个过程中的位置如下图所示：
集成测试 系统测试 验收 最新精品资料整理推荐，更新于二〇二一年一月二十七日2021年1月27日星期三20:47:59
……………………………………………………………最新资料推荐…………………………………………………
3.7.2 入口准则和出口准则
（1）入口准则：
要 素 系统需求 系统的目标代码 系统测试计划 用户手册 判断准则 •经过审查 •获得批准 •进入配置库 编写完成 （2）出口准则：
要 素 系统测试报告 软件问题报告单 3.7.3 任务
（1）准备阶段是：
•培训：根据测试人员的实际水平进行有关测试方法、测试工具、测试流程、问题汇报方法等方面的培训；有关被测产品的功能培训；
•安排测试日程； •准备测试工具和环境； •准备必要的测试数据。 （2）测试阶段
•从目标代码库获取程序目标代码，对照系统测试计划并参考用户手册进行测试，将测试结果记录于测试报告（测试报告编写规范见附录3.5－1）；
•将测试中发现的缺陷/问题记录于问题报告单，并提交测试负责人，进入软
最新精品资料整理推荐，更新于二〇二一年一月二十七日2021年1月27日星期三20:47:59
判断准则 •获得批准 系统需求说明书 系统目标代码 集成测试计划 用户手册 准备 系统测试 系统测试报告 软件问题报告单 ……………………………………………………………最新资料推荐…………………………………………………
件问题管理流程（见3.10）
•集成测试视程序存在缺陷的情况，可能重复进行，直至问题解决。 3.7.4 工作产品
•《系统测试报告》
•《软件问题报告单》（MT-OP01C） •《软件问题状态登记表》（MT-OP01D） 3.7.5 职责
•项目经理：负责建立系统测试组或相关的岗位，并进行必要的培训；跟踪进度和问题解决状态；对最终的目标代码进行批准（或指定负责人进行批准工作）。
•程序员、设计人员：修改源码或设计，解决集成过程中出现的与源码有关的问题。
•测试人员：测试系统目标码，将测试报告提交测试负责人，将软件问题报告单提交问题管理渠道（见3.10）。 3.7.6 资源和能力要求
•执行测试的软硬件环境和测试人员 •必要的测试工具 •必要的培训 3.7.7 度量
项目经理负责进行以下统计： •发现的缺陷总数及解决的缺陷总数； •进度完成情况。
最新精品资料整理推荐，更新于二〇二一年一月二十七日2021年1月27日星期三20:47:59
……………………………………………………………最新资料推荐…………………………………………………
3.7.8 详细裁剪指南 活 动 培训 测试方法、测试工具、问题汇报方法 系统测试 系统测试 执行 不执行 执行 集成测试中已包含对系统功能的测试 集成测试只涉及模块的接口测试，不涉及功能测试 执行 不执行 执行 对单元测试有经验的团队 对单元测试缺乏经验的团队，或采用新的工具的情况 可裁剪属性 选 择 裁剪指导方针 3.8 验收 3.8.1 元素概述
验收阶段主要由验收测试、验收测试问题改正和验收三部分组成： •验收测试的主要目的是验证所开发的系统在用户的使用环境下（或模拟的用户使用环境下）是否满足系统需求，从用户的角度验证整个系统进行的正确性。
•验收测试问题改正是对验收测试中发差异性问题进行修改。
•验收则是在验收测试的基础上，依据项目合同或项目任务书对项目的完成情况进行综合评价。
本元素在整个过程中的位置如下图所示：
3.8.2 入口准则和出口准则
（1）入口准则：
要 素 验收测试计划 判断准则 已评审 系统测试 验收 维护 测试（系统测试、集成测试、单元测试） 已完成 最新精品资料整理推荐，更新于二〇二一年一月二十七日2021年1月27日星期三20:47:59
……………………………………………………………最新资料推荐…………………………………………………
（2）出口准则：
要 素 验收测试报告 验收测试问题报告单 验收报告 3.8.3 任务
（1）验收测试
验收测试流程图如下所示：
由验收测试组完成以下活动： a. 准备验收测试
测试人员从配置库提取验收测试计划和被测试系统的目标代码，根据测试计划建立测试环境，必要时准备测试数据和编写测试用例程序，同时参考用户手册。
b. 执行/再执行验收测试用例
按验收测试计划（必要时参考用户手册）反复执行验收测试用例。将测试发现的问题填写到《软件问题报告单》（见3.10问题管理），通过测试问题管理渠道提交给相应的开发人员进行更正，并重复测试过程，直至问题得到解决。
c. 分析并报告测试结果
分析测试结果并形成验收测试报告（见附录3.2－1）。 （2）验收测试问题改正
验收测试问题改正流程如下图所示：
最新精品资料整理推荐，更新于二〇二一年一月二十七日2021年1月27日星期三20:47:59
判断准则 已提交 已关闭 已提交 执验收测试 计划 用户手册 系统描述 软件代码 准备验收测试 行/再执行验收用例 分 析并报告测试结果 验收测试 报告 ……………………………………………………………最新资料推荐…………………………………………………
验收测试 修改升级配置库 发布 已验收测试的系统 将交付的产品
软件错误 问题报告单 包括以下活动： a. 修改软件错误
开发组人员根据测试问题报告单分析、修改错误，若有变更则按变更控制的要求执行。
b. 升级配置库
SCM负责人对新提交的配置进行配置。 （3）验收 a. 组织验收
验收在验收测试的基础上由验收组进行，验收组通常应有客户代表和SCCB的成员参加。验收内容一般包括以下方面：
•对项目实施的技术路线、采用的关键技术进行评价； •对应产生的工作产品的完整性、正确性进行评价； •对验收测试的结果进行评价；
•依据项目合同或项目任务书对项目的完成情况进行综合评价。
在上述评价的基础上，给出验收结论，并形成验收报告。验收结论分为：通过验收；需要复评；不通过验收。其中：
•基本符合项目合同或项目任务书的要求按期保质完成的，可视为通过验收。 •由于提供文件资料不详，难以判断，或任务完成不足80%且原因难充确定导致较大争议的，可视为需要复评；
•属以下情况之一者，可视为不通过验收；任务未能按合同或项目任务书的要求完成；应产生的工作产品不完整或不真实；由于采用未经批准的技术路线，导致开发成果已无实用价值。
b. 发布已通过验收的产品
通过验收的产品（系统）经SCCB批准后，由SCM负责人将经客户验收确
最新精品资料整理推荐，更新于二〇二一年一月二十七日2021年1月27日星期三20:47:59
……………………………………………………………最新资料推荐…………………………………………………
认的最终版配置到客户区，并形成运行基线。 3.8.4 工作产品
•验收测试报告
•《软件问题报告单》（MT-OP01C） •《软件问题状态登记表》（MT-OP01D） •验收报告 •可交付产品 3.8.5 职责
•验收测试组：负责验收测试的各项活动。
•开发组人员：负责验收测试中发现问题的改正和测试辅助。
•项目管理人员：负责指派验收测试责任和完成测试规程；确保测试质量和进程；确保组间协调。
•验收组：具体进行验收。 •SCCB：批准运行基线。 3.8.6 资源和能力要求
•资源：验收测试和验收环境的保证。 •能力：
*验收测试人员接受过验收测试的培训； *公司为验收提供充足的资源和资金。 3.8.7 度量
（1）验收测试人员 •验收测试所花费的工时 （2）开发组人员
•改正验收测试中发现的问题所花费的工时 （3）验收组 •验收所花费的工时 （4）项目管理人员 •验收管理所花费的工时 •验收问题状态跟踪 3.8.8 详细裁剪指南
最新精品资料整理推荐，更新于二〇二一年一月二十七日2021年1月27日星期三20:47:59
……………………………………………………………最新资料推荐…………………………………………………
活 动 验收测试 验收测试 可裁剪属性 选 择 裁剪指导方针 执行 执行 不执行 非自主开发的产品 自主开发的产品 3.9 验收
3.9.1 元素概述
软件产品交付发布后，就进入软件运行/维护阶段，直至下一个版本的发布或维护期终止。
本元素在整个过程中的位置如下图所示：
维护包括以下几种类型： •改正性维护
为识别和纠正软件错误、改正软件性能上的缺陷所进行的诊断和改正错误的过程。
•适应性维护
因外部环境或数据环境发生变化而修改软件的过程。 •完善性维护
为满足用户扩充软件功能、增强软件性能、改进工作效率等新的需求而修改或开发软件的过程。
•预防性维护
提高软件可维护性、可靠性等，为进一步改进软件打下基础的修改过程。 3.9.2 入口准则和出口准则
（1）入口准则：
要 素 软件产品 （2）出口准则： 判断准则 已交付用户使用 验收 维护 最新精品资料整理推荐，更新于二〇二一年一月二十七日2021年1月27日星期三20:47:59
……………………………………………………………最新资料推荐…………………………………………………
要 素 软件产品（自主开发产品） 已退役 判断准则 合同要求的维护期限（合同项目） 已到期 3.9.3 任务
本过程元素仅对软件产品的一部分维护要求进行描述。软件产品的维护可能存在多种情况。由于情况不同，其处理方针也不同，因此，不同情况的维护要求可能分别在不同的程序文件中进行描述。
下表给出了本公司可能发生的软件产品的维护要求情况，以及相应的处理方针。
维护要求情况 维护处理方针 （1）合同类项目，产品交付后，属于由于服务程序中的用户支持包括维用户支持性质的维护活动 护，因此在服务程序中考虑 （2）合同类项目，合同规定产品交付在本过程元素中考虑。在项目策划时，后需要有一个维护期 应同时对产品交付后的维护进行策划 （3）自主开发产品，产品上市后，属由于服务程序中的用户支持包括维于用户支持性质的维护活动 护，因此在服务程序中考虑 （4）自主开发产品，产品上市后进行在本过程元素中考虑 的主动性维护活动 （5）自主开发产品，产品上市后，发按新项目的要求考虑 生的维护要求属于重大的功能性改进，需要引发新的开发项目 由上表可见，本过程元素只考虑情况（2）和情况（4）两种情况。 情况（2）和情况（4）的主要区别是：前者是合同要求，因此产品（系统）交付后的维护活动属于项目活动的组成部分；后者则是自主开发产品上市后主动进行的改进性维护活动，但不一定是项目活动的组成部分。对于情况（2），在项目策划时，在进行开发策划的同时应对交付后的维护活动也进行初步策划，并反映到开发计划中；产品交付后，负责维护的小组根据项目维护的初步策划，进一步制订维护实施计划。对于情况（4），则一般在产品上市后，由负责维护的小组
最新精品资料整理推荐，更新于二〇二一年一月二十七日2021年1月27日星期三20:47:59
……………………………………………………………最新资料推荐…………………………………………………
独立制订属于改进性质的维护计划。
作为一人鹸发项目，通常在软件产品通过验收交付、进行项目总结后，就可以认为项目已经结束了，其后的维护是一个相对独立的维护阶段；维护阶段的时间有可能很长，甚至直到产品退役。情况（2）中的维护阶段可以视为项目的延伸，但维护人员只需要保持少数项目成员，且维护阶段的时间一般不会很长，且应在合同中作出规定。
维护阶段的任务如下： （1）建立软件维护小组
软件维护小组的组成可以是项目组的成员，也可以不是项目组的成员。 （2）制定维护实施计划
由软件维护小组负责人负责该计划的编制。内容包括维护小组的组成及职责，规定维护工作流程、维护过程信息记录与统计等，计划的格式见附录3.9－1。维护实施计划编制后应进行评审。
（3）实施软件维护
软件产品维护的具体实施按规定的维护工作流程进行。软件产品维护的一般工作流程如下图：
•获取软件问题、分配维护任务 列入计划 完善性、适应性 高优先级 评价优先次序 问题分析 维护实施 判别维护类型 改进性 评价严重程度 问题分析 确定维护要求 列入计划 不严重 最新精品资料整理推荐，更新于二〇二一年一月二十七日2021年1月27日星期三20:47:59
……………………………………………………………最新资料推荐…………………………………………………
在软件维护期，维护负责人通过《软件问题报告单》获取问题，判定维护类型（改进性、完善性、适应性），并根据问题的严重程度或申请的轻重缓急将维护任务分配给维护小组的成员。对于紧急维护任务，应优先安排人力，执行维护任务，解决完问题再进行问题登记；对于紧急程度低的任务，可以列入维护计划，按计划执行维护任务。
•实施维护任务
由于维护工作实际是排除错误、功能修改和开发新功能等过程，所维护的问题可能涉及软件开发的各个过程，包括软件需求规格说明、设计、编码、测试等。所有涉及对上述过程的配置项的修改，必须严格按照软件配置管理的要求进行。软件配置管理人员应对维护中的配置项的状态进行跟踪，具体要求参见《软件配置管理程序》。
•维护过程记录
为评价维护的有效程度，确定维护的实际人工时，维护人员在维护过程中应记录以下信息：软件问题报告单编号、维护类型、程序语言类型、所属功能模块、代码文件名称、维护所付出的人工时和累计人工时、维护开始日期和结束日期、维护人员等。同时对维护阶段所发现的缺陷数进行统计。
在维护期间，维护记录应由维护组负责保存，并定期提交所在总部的软件质量保证组。 3.9.4 工作产品
•《软件问题报告单》（MT-OP01C） •《软件问题状态登记表》（MT-OP01D） •软件维护实施计划 3.9.5 职责
•维护负责人：制定软件维护实施计划，确认维护类型，分配维护任务，追踪任务的完成情况。
•软件维护人员：负责进行软件维护任务的执行。 3.9.6 资源和能力要求
•需要被维护软件产品的全部开发文档、源代码、开发工具、资源环境等； •对合作伙伴（软、硬件开发商）应进行本公司软件维护工作流程的培训； •根据维护工作需要，对软件维护人员进行相应的需求管理、分析与设计、
最新精品资料整理推荐，更新于二〇二一年一月二十七日2021年1月27日星期三20:47:59
……………………………………………………………最新资料推荐…………………………………………………
配置管理、错误跟踪等CASE工具的培训。 3.9.7 度量
（1）软件维护负责人
•定期统计在维护过程中发现缺陷的引入阶段、数量和解决情况，见下表： 产生阶段 缺陷统计 维护期间发现的缺陷个数 维护期间解决的缺陷个数 •定期统计各类维护所花费的人工时。 （2）软件维护人员
•在个人周报中按维护类分类统计维护工作花费人工时。 3.9.8 详细裁剪指南 活 动 可裁剪属性 选 择 裁剪指导方针 需求 设计 实现 测试 制定维护实施计划 制定维护实施计划 建立软件维护小组 维护小组成员 角色 只安排一人 对小项目或仅有一般商业意义的项目 文档 编写 不编写 其它情况 项目定义过程有维护阶段并已经在项目开发计划中做出详细规定的项目 专门的维护组 其他 实施软件维护 执行维护任务 步骤 可先于“维护任务分配” 按规定顺序执行 对紧急维护任务 其他类型问题或申请 3.10 软件问题管理
3.10.1 元素概述
软件问题管理的主要任务是收集软件项目开发/维护过程中所发现的各种软件问题报告，分析问题的引入阶段，分发问题至解决责任者，监控问题的解决状
最新精品资料整理推荐，更新于二〇二一年一月二十七日2021年1月27日星期三20:47:59
……………………………………………………………最新资料推荐…………………………………………………
态。
本元素与其他过程元素的关系如下：
软件问题管理 其他过程元素
3.10.2 入口准则和出口准则
（1）入口准则 不适合。 （2）出口准则 不适合。 3.10.3 任务
软件问题 报告单 Y 新问题 登 记 分析•分类 N N 解决 分 发 软件问题 报告单 Y 改变问题状态 （1）登记阶段
•将产品开发过程、维护过程提交的软件问题报告单进行收集和过滤，并在软件问题状态登记表中登记新问题，对已解决的问题，变更软件问题登记状态表中问题的状态；
最新精品资料整理推荐，更新于二〇二一年一月二十七日2021年1月27日星期三20:47:59
……………………………………………………………最新资料推荐…………………………………………………
•对于未解决且有新的变化的问题重新进行分析。 （2）分析•分类 •确认问题产生阶段；
•评估是否修改，对某些问题是否投入资源和工期进行修改有争议时，项目经理是最终决策者；
•指定问题修改的责任组或责任人和解决问题的优先级。 （3）分发阶段
•将问题报告单的副本分发到指定的负责部门或人员，并在软件问题状态登记表中记录相关信息。 3.10.4 工作产品
•《软件问题报告单》（MT-OPT01C） •《软件问题状态登记表》（MT-OPT01D） 3.10.5 职责
项目经理：负责建立问题管理组织或岗位，具有对问题解决应对的最终决策权
开发人员（分析、设计、编码人员）：接受问题修改任务
问题管理：负责对问题报告单及问题状态进行登记、状态维护、分发等工作 问题分析人员：负责分析问题及问题修改的责任组织，评估对问题采取的策略
质量保证人员：对问题管理过程和问题状态进行审计 配置管理人员：对可能引起的版本变更或基线变更进行维护 3.10.6 资源及能力需求
•必要的工具、人力资源 •必要的培训 3.10.7 度量
项目经理负责进行以下统计： •发现的缺陷/问题总数 •解决的缺陷/问题总数
•引起各类基线变更的总数（同一个基线多次变更，只记一次） •问题管理的工时
最新精品资料整理推荐，更新于二〇二一年一月二十七日2021年1月27日星期三20:47:59
……………………………………………………………最新资料推荐…………………………………………………
3.10.8 详细裁剪指南 活 动 问题登记 软件问题状态登记表 软件问题的报告与传递 软件问题报告单的传递 执行 执行 不执行 问题管理基于纸介质 问题管理基于多用户自动化管理，问题的各种登记项可通过访问问题库获取 文档 编写 不编写 问题管理基于纸介质 采用多用户自动化问题管理系统时，状态登记项可从问题库中抽取 可裁剪属性 选 择 裁剪指导方针 4、附录
最新精品资料整理推荐，更新于二〇二一年一月二十七日2021年1月27日星期三20:47:59
……………………………………………………………最新资料推荐…………………………………………………
附录2.3－1 中大型软件工程项目的标准软件开发过程
系统需求规格 系统分析 N N Y Y 此记为评审活动符号
说明书 软件需求规格说明书 软件需求分析 N Y 结构设计 说明书 N Y 结构设计 详细设计 说明书 详细设计 N Y 源代码 N Y 集成测试 编码 集成测试报告 N Y 系统测试 系统测试报告 N Y 验收 验收测试报告 N Y 维护 更新的软件 N 最新精品资料整理推荐，更新于二〇二一年一月二十七日2021年1月27日星期三20:47:59
Y ……………………………………………………………最新资料推荐…………………………………………………
附录2.3－2 中小型软件工程项目的标准软件开发过程
软件需求规格说明书 软件需求分析
软件需求规格说明书 软件需求分析 N Y 系统设计 Y N 系统设计 说明书 Y 系统设计 说明书 N Y 系统设计 N 源代码 编码 集成测试 报告 N 集成测试 系统测试 报告 Y 系统测试 N Y 系统测试 报告 系统测试 N Y 验收 Y N 验收测试 报告 验收测试 报告 N 验收 N Y Y 维护 维护 更新的软件 N Y 更新的软件 N Y 简化过程1－1 自编/移植软件 简化过程1－2 自由软件 最新精品资料整理推荐，更新于二〇二一年一月二十七日2021年1月27日星期三20:47:59
……………………………………………………………最新资料推荐…………………………………………………
附录2.3－3 小型软件工程项目的标准软件开发过程
总体设计 说明书 总体设计 总体设计 说明书 总体设计
N Y N Y 源代码 编码 集成测试 报告 集成测试 N Y 系统测试 Y N 系统测试 报告 系统测试 报告 N 系统测试 N Y Y 验收 验收测试 验收测试 报告 N 验收 报告 Y 维护 N Y Y 维护 N Y 更新的软件 N 更新的软件 简化过程2－1 自编/移植软件 简化过程2－2 自由软件 最新精品资料整理推荐，更新于二〇二一年一月二十七日2021年1月27日星期三20:47:59
……………………………………………………………最新资料推荐…………………………………………………
附录3.1－1 《系统架构和业务需求说明书》文档编写规范
1、引言
（1）系统目的和背景
说明开发本系统的目的和背景。 （2）组织
对进行系统架构和业务需求分析的组织机构进行说明。 2、系统概述
（1）系统概述
从概念层对系统进行说明，包括所有客户的高层需求。 （2）系统架构
用框图的形式说明系统的总体架构，包括要实现的主要功能和外部接口。 3、重用建议
（1）重用分析
对已进行的领域和提供重用的可能性进行分析。 （2）重用候选项
对潜在的重用候选项－结构组件、设计、业务过程、测试方法－以及相关的折中办法进行说明。
（3）修改后的系统体系结构
对考虑可重用元素后的系统体系结构进行说明。 4、业务环境
（1）业务方案脚本概述
用实例的形式概要性地说明本系统运行时的业务情况。 （2）业务环境图
说明本系统运行的环境（包括硬件、软件、数据、人员等系统构件）。 （3）人员职责
说明业务过程中人员的职责。 5、业务模式
（1）业务模式概述
最新精品资料整理推荐，更新于二〇二一年一月二十七日2021年1月27日星期三20:47:59
……………………………………………………………最新资料推荐…………………………………………………
概要说明本系统的业务模式。 （2）数据
对每个业务模式中所处理的数据的值及其处理频度进行说明。 （3）业务
对每个业务模式中的业务的顺序、频率和类型（如：批处理或交互式）进行说明。
6、主要功能（对象）业务描述 6.1 功能1
对功能1的业务进行描述。描述要求如下：
•用流程图表示出所有使用实例的输入、输出和关键控制顺序。
•输入数据的描述，包括输入的格式和限制。例如：数据输入屏幕（包括显示、菜单、弹出窗口）格式的描述等。
•过程－该功能将如何工作的高层描述。
•输出数据描述，包括输出的格式和限制。例如：结果输出屏幕（包括显示、报告、屏幕、示图）格式的描述等。
•处理过程中所要求的状态和驱动信息的描述，包括对用户响应的任何关键信息的指南。 6.2 功能2
对功能的2的业务进行描述。描述要求同功能1。 ∶ ∶ ∶ 6.n 功能n
对功能n的业务进行描述。描述要求同功能1。
最新精品资料整理推荐，更新于二〇二一年一月二十七日2021年1月27日星期三20:47:59
……………………………………………………………最新资料推荐…………………………………………………
附录3.1－2 《可行性分析报告》文档编写规范
1、项目背景
问题描述；实现环境；限制条件。 2、管理概要与提示
重要的研究结果；说明；提示；影响。 3、候选方案
候选系统的配置；选择最终方案的准则。 4、系统描述
简略的范围描述；分配元素的可行性。 5、经济可行性（成本－效益分析）
经费概算；预期的经济效益。 6、技术可行性（技术风险评价）
技术实力；已有工作基础；设备条件。 7、法律可行性
系统开发可能导致的侵权、违法和责任。 8、用户使用可行性
用户单位的行政管理、工作制度；使用人员的素质。 9、其它与项目有关的问题
其它方案介绍；未来可能的变化。
最新精品资料整理推荐，更新于二〇二一年一月二十七日2021年1月27日星期三20:47:59
……………………………………………………………最新资料推荐…………………………………………………
附录3.1－3 《系统需求规格说明书》文档编写规范
1、引言 1.1 编写目的
说明编写本系统需求规格说明书的目的，指出预期的读者。 1.2 背景
说明待开发系统或项目（以下简称系统）的名称。 列出此开发任务的提出者、开发者、用户等。 说明本系统与其他系统的关系。 1.3 定义
列出本文中用到的专门术语的定义和综合词原文。 1.4 参考资料
本文件中引用的属于本系统的其他文件。 本文件中引用的其他文献、资料以及开发标准。 2、系统概述 2.1 系统概述
本系统的开发意图、应用目标及作用范围（现有系统存在的问题和建议系统所要解决的问题）。
表示外部接口和数据流的系统高层次图。说明本系统与其他相关系统的关系，是独立系统还是一个较大系统的组成部分。 2.2 运行环境
简要说明本系统的运行环境（包括硬件、外围设备环境和支持环境等）的规定。
2.3 约束条件
列出进行本系统开发工作的约束条件。例如：经费限制、开发期限和所采用的方法与技术，以及政治、社会、文化、法律等。 3、需求
指功能、业务（包括接口、资源、性能、可靠性、安全性、保险性等）、数据需求。
最新精品资料整理推荐，更新于二〇二一年一月二十七日2021年1月27日星期三20:47:59
……………………………………………………………最新资料推荐…………………………………………………
3.1 需求概述
3.1.1 系统总体功能、业务结构
描述系统总体功能、业务的结构。 3.1.2 软件系统的需求
说明对软件系统的需求。 3.1.3 硬件系统的需求
说明对硬件系统的需求。 3.1.4 内部接口需求
说明软件系统和硬件系统之间的接口。 3.2 系统需求项 3.2.1 需求1
（1）编号和名称 本需求的编号和名称。 （2）需求描述 对本需求的具体描述。 （3）参考源
说明本需求的参考源，区分派生出的需求。 （4）功能接口或外部实体
说明本需求对其他主要的功能接口或外部实体的需求。 （5）性能
说明本需求对频率、响应时间、精度等的需求。 ∶ ∶ ∶ 3.2.n 需求n
（1）编号和名称 本需求的编号和名称。 （2）需求描述 对本需求的具体描述。 （3）参考源
最新精品资料整理推荐，更新于二〇二一年一月二十七日2021年1月27日星期三20:47:59
……………………………………………………………最新资料推荐…………………………………………………
说明本需求的参考源，区分派生出的需求。 （4）功能接口或外部实体
说明本需求对其他主要的功能接口或外部实体的需求。 （5）性能
说明本需求对频率、响应时间、精度等的需求。 3.3 性能需求
说明本系统的性能要求。如：数据精度、时间特性（响应时间、处理时间、数据转换时间、数据传输时间、运行时间等）、运行环境、操作方式等。 3.4 外部接口需求 3.4.1 人机界面
说明本系统面向用户的输入、输出接口、包括：显示输入、输出和打印输出等形式的界面规格要求。 3.4.2 外部硬件接口
说明本系统与外部硬件之间接口的逻辑特点。 3.4.3 外部软件接口
说明本系统与其他软件的接口，并指出相关软件的名称、版本、厂商等。 3.4.4 通信接口
说明本系统的通信接口，如网络协议等。 3.5 数据需求
说明本系统的输入、输出数据及数据管理能力方面的要求（处理量、数据量）。 3.6 操作需求
说明本系统在常规操作、特殊操作以及初始化操作、恢复操作等方面的要求。 3.7 可使用性、可维护性、可移植性、可靠性和安全性需求
说明本系统在可使用性、可维护性、可移植性、可靠性和安全性等方面的要求。
3.8 故障处理需求
说明本系统在发生可能的软硬件故障时，对故障处理的要求。 3.8.1 软件系统出错处理
说明属于软件系统的问题； 给出发生错误时的错误信息；
最新精品资料整理推荐，更新于二〇二一年一月二十七日2021年1月27日星期三20:47:59
……………………………………………………………最新资料推荐…………………………………………………
说明发生错误时可能采取的补救措施。 3.8.2 硬件系统冗余措施的说明
说明哪些问题可以由硬件设计解决，并提出可采取的冗余措施； 对硬件系统采取的冗余措施加以说明。 4、需求说明
说明系统总体功能或对象层次的结构图和流程图
对每个主要子系统中的基本模块进行描述，结构图、流程图或对象图 通常使用的约定描述（数学符号、度量单位等） 每个基本功能或对象的描述，如： 功能号和名称 输入
过程－功能将做什么的详细描述 输出
候选可重用软件的识别 用于验证满足需求的验收准则
数据字典－指出数据项名、定义、项结构组成、项范围、项类型 下面4.1－4.6是一个例子。 4.1 系统硬件设备布局
描述硬件系统总体布局，必要时描述地理分布图、网络拓扑结构图等。 4.2 硬件系统总体功能/对象结构
对软件系统总体功能/对象结构进行描述，包括结构图或对象图。 4.3 软件系统总体功能/对象结构
对软件系统总体功能/对象结构进行描述，包括结构图、流程图或对象图工。 4.4 软件子系统功能/对象结构
对每个主要子系统中的基本功能模块/对象进行描述，包括结构图、流程图或对象图。 4.5 描述约定
通常使用的约定描述（数学符号、度量单位等） 4.6 功能或对象的描述 4.6.1 功能或对象1
最新精品资料整理推荐，更新于二〇二一年一月二十七日2021年1月27日星期三20:47:59
……………………………………………………………最新资料推荐…………………………………………………
（1）编号和名称
本功能/对象的编号和名称。 （2）输入
描述本功能/对象的输入信息（包括需要访问的存储信息）。 （3）过程
对本功能/对象将做什么进行详细的描述。 （4）输出
描述本功能/对象的输出信息（包括需要访问的存储信息）。 （5）候选可重用软件
说明识别出的候选可重用软件。 （6）验收准则
说明用于验证满足需求的验收准则。 （7）数据字典
指出数据项名、定义、项结构组成、项范围、项类型。 4.6.n 功能或对象n
（1）编号和名称
本功能/对象的编号和名称。 （2）输入
描述本功能/对象的输入信息（包括需要访问的存储信息）。 （3）过程
对本功能/对象将做什么进行详细的描述。 （4）输出
描述本功能/对象的输出信息（包括需要访问的存储信息）。 （5）候选可重用软件
说明识别出的候选可重用软件。 （6）验收准则
说明用于验收满足需求的验收准则。 （7）数据字典
指出数据项名、定义、项结构组成、项范围、项类型。 5、需求与需求说明的映衬
最新精品资料整理推荐，更新于二〇二一年一月二十七日2021年1月27日星期三20:47:59
……………………………………………………………最新资料推荐…………………………………………………
针对项目类型区分项目所独有的需求和标准需求。 6、算法说明
用于实施系统计算功能的公式和算法的描述 每个主要算法的概况 用于每个主要算法的详细公式 7、非技术性需求
•交付日期 •里程碑点 8、尚未解决的问题
如需要，可说明系统需求中的尚未解决的遗留问题。 9、支持信息
如需要，可说明本系统的有关支持信息，如附录、索引等。
编写规范的使用说明：
编写文档时，要求具有本规范规定的所有条目如果某条目无内容，则填写“无”，并在可能的情况下说明理由。必要时，可增加适当的条目。
最新精品资料整理推荐，更新于二〇二一年一月二十七日2021年1月27日星期三20:47:59
……………………………………………………………最新资料推荐…………………………………………………
附录3.2－1 需求分析方法指南
本指南推荐使用的需求分析方法包括以下三种：结构化分析法、面向对象分析法和快速原型法。
需求分析初期需要与客户不断接触、协商，确定目标产品中需要什么。除了调查客户正常业务处理要求以外，特别需要关注的是异常处理和例外处理要求。这些处理要求往往在软件需求中占有很大的比例，却容易被忽视。
与客户交流的基本形式有两种：客户访谈调查（正式的和非正式的）、书面调查（书面报告和调查表）。此外，通过对客户使用的表格和所处的情景进行分析，从而获取需求，也是常用的方法。这些方法对前面推荐的三种需求分析法都有效，只是在运用时的表达方式有所不同。
由于表达方式的不同，在需求分析中采用的分析法与后续过程的设计和实现方法有一定的关联关系，通常应该保持所选用的表达方法一致。
最新精品资料整理推荐，更新于二〇二一年一月二十七日2021年1月27日星期三20:47:59
……………………………………………………………最新资料推荐…………………………………………………
附录3.2－2 结构化分析法
结构化分析法又可分为面向过程和面向数据的结构化分析法。前者以过程为主线获取对软件功能的需求，适用于以过程为中心的系统（例如，业务处理系统），通常以数据流图（DFD）对业务处理需求进行规格说明；而后者则以数据为主线获取对软件功能的需求，适用于以数据为中心的系统（例如，信息查询系统），通常以实体关系模型（ER）对数据处理需求进行规格说明。
用状态（转换）图表示有穷状态机也是进行规格说明的方法之一。一个有穷状态机包括五个部分：状态集J、输入集K在、由当前状态和当前输入确定下一个状态（次状态）的转换函数T、初始状态S和终态集F。例如，每个菜单驱动的用户界面都是一个有穷状态机的实现。
与结构化分析法相应的设计方法是结构化设计技术，实现方法通常是结构化程序设计语言（例如C语言等）。
最新精品资料整理推荐，更新于二〇二一年一月二十七日2021年1月27日星期三20:47:59
……………………………………………………………最新资料推荐…………………………………………………
附录3.2－3 面向对象分析法（OOA）
面向对象的分析法（OOA）是一种半形式化的规格说明技术。 面向对象的分析法（OOA）由三个步骤组成： （1）类建模
确定类及其属性，然后确定类之间的相互关系。通常以流图（类似于实体关系图）的形式表示，称为类模型或对象模型。此步骤是面向数据的。
（2）动态建模
确定对每个类或子类的操作。通常以流图（类似于有穷状态机）的形式表示，称为动态模型。此步骤是面向操作的。
（3）功能建模
确定产品如何计算各种结果（不考虑次序）。通常以流图（类似于数据流图）的形式表示，称为功能模型。此步骤大部分是面向操作的。
在实践中，以上三个步骤并不是完全按顺序进行的，但通常总是从步骤1开始。OOA的三个步骤是市郊地并行发生的。OOA是一种利用图表来说明三个建模结果的建模技术。
与面向对象的分析法（OOA）相对应的设计法是面向对象设计技术，实现方法是面向对象程序设计语言（例如C＋＋语言等）。
最新精品资料整理推荐，更新于二〇二一年一月二十七日2021年1月27日星期三20:47:59
……………………………………………………………最新资料推荐…………………………………………………
附录3.2－4 快速原型法
快速原型就是利用适当的开发工具快速建立的旨在展示目标产品主要功能的软件。它只反映客户看得见的功能（例如，屏幕形式和打印形式），而省略了“隐含的”功能（例如，对文件的修改）。
客户与工发人员一起对快速原型进行试验，开发人员过程中做观察记录。客户基于现有经验，告诉开发人员快速原型的哪些部分满足了他们的需求，特别是可以提出哪些部分需要改进。开发人员快速修改原型，直到双主方都认为客户的要求已经准确地纳入了快速原型之中。然后，再根据这个快速原型来定义软件需求规格。
在开发用户界面时，快速原型法是特别有效的。 快速原型法的主要缺陷是不能作为惟一的规格说明：
（1）有效合同问题。如果在开发者是否令人满意地完成了应尽的责任问题上发生分歧，快速原型是不能作为开发者与客户之间合法的合同协议的。
（2）维护问题。如果没有规格说明书，维护人员将无法获得当前版本规格说明的清晰陈述。
正是由于这些原因，快速原型法仅被用作需求分析技术，也就是作为确定客户需求的一种方法。因此，必须在快速原型基础上产生书面的软件需求规格说明书。
软件开发人员和项目管理人员不应该对快速原型继续开发并使用其成为最终产品。因为这种做法与“边做边改”一样，在逐步求精过程中，修改是在运行的产品上进行。这最终将是时间和成本都花费很大的方法。此外，用于快速建立原型的开发平台，因运行效率问题，通常也不宜用作运行平台。设计不佳和难以维护是将原型开发成最终产品的最大危险。而且随着产品规模的增大，这种风险有成比例上升的趋势。
最新精品资料整理推荐，更新于二〇二一年一月二十七日2021年1月27日星期三20:47:59
……………………………………………………………最新资料推荐…………………………………………………
附录3.2－5 《软件需求规格说明书》文档编写规范
1、引言 1.1 编写目的
说明编写本软件需求规格说明书的目的，指出预期的读者。 1.2 背景
a. 说明待开发产品或项目（以下简称产品）的名称。 b. 列出此开发任务的提出者、开发者、用户等。 c. 说明本产品与其他产品的关系。 1.3 定义
列出本文件中用到的专门术语的定义和缩写词原文。 1.4 参考资料
a. 本文件中引用的属于本开发产品的其他文件。 b. 本文件中引用的其他文献、资料以及软件开发标准。 2、需求概述 2.1 目标
a. 本产品的开发意图、应用目标及作用范围（现有产品存在的问题和建议产品所要解决的问题）。
b. 本产品的主要功能、处理流程、数据流程及简要说明。
c. 表示外部接口和数据流的系统高层次图。说明本产品与其他相关产品的关系，是独立产品还是一个较大产品的组成部分（可用方框图说明）。 2.2 运行环境
简要说明本产品的运行环境（包括硬件环境和支持环境）的规定。 2.3 关键点
说明本软件需求规格说明书中的关键点（例如：关键功能、关键算法和所涉及的关键技术等）。 2.4 约束条件
列出进行本产品开发工作的约束条件。例如：经费限制、开发期限和所采用的方法与技术，以及政治、社会、文化、法律等。
最新精品资料整理推荐，更新于二〇二一年一月二十七日2021年1月27日星期三20:47:59
……………………………………………………………最新资料推荐…………………………………………………
3、需求规格
3.1 软件系统总体功能/对象结构
对软件系统总体功能/对象结构进行描述，包括结构图、流程图或对象图。 3.2 软件子系统功能/对象结构
对每个主要子系统中的基本功能模块/对象进行描述，包括结构图、流程图或对象图。 3.3 描述约定
通常使用的约定描述（数学符号、度量单位等） 3.4 功能或对象的描述 3.4.1 功能或对象1
（1）编号和名称
本功能/对象的编号和名称。 （2）输入
描述本功能/对象的输入信息（包括需要访问的存储信息）。 （3）过程
对本功能/对象将做什么进行详细的描述。 （4）输出
描述本功能/对象的输出信息（包括需要访问的存储信息）。 （5）候选可重用软件
说明识别出的候选可重用软件。 （6）验收准则
说明用于验证满足需求的验收准则。 （7）数据字典
指出数据项名、定义、项结构组成、项范围、项类型。 ∶ ∶ ∶
3.4.n 功能或对象n
（1）编号和名称
本功能/对象的编号和名称。
最新精品资料整理推荐，更新于二〇二一年一月二十七日2021年1月27日星期三20:47:59
……………………………………………………………最新资料推荐…………………………………………………
（2）输入
描述本功能/对象的输入信息（包括需要访问的存储信息）。 （3）过程
对本功能/对象将做什么进行详细的描述。 （4）输出
描述本功能/对象的输出信息（包括需要访问的存储信息）。 （5）候选可重用软件
说明识别出的候选可重用软件。 （6）验收准则
说明用于验证满足需求的验收准则。 （7）数据字典
指出数据项名、定义、项结构组成、项范围、项类型。 3.5 性能
说明本产品的性能要求。如：数据精度、时间特性（响应时间、处理时间、数据转换时间、数据传输时间、运行时间等）、运行环境、操作方式等。 3.6 外部接口
从以下方面说明外部接口： a. 人机界面
说明本产品面向用户的输入、输出接口，包括：显示输入、输出和打印输出等形式的界面规格要求。
b. 外部硬件接口
说明本产品与外部硬件之间接口的逻辑特点。 c. 外部软件接口
说明本产品与其他软件的接口，并指出相关软件的名称、版本、厂商等。 d. 通信接口
说明本产品的通信接口，如网络协议等。 3.7 数据
说明本产品的输入、输出数据及数据管理能力方面的要求（处理量、数据量）。 3.8 操作
说明本产品在常规操作、特殊操作以及初始化操作、恢复操作等方面的要求。
最新精品资料整理推荐，更新于二〇二一年一月二十七日2021年1月27日星期三20:47:59
……………………………………………………………最新资料推荐…………………………………………………
3.9 可使用性、可维护性、可移植性、可靠性和安全性
说明本产品在可使用性、可维护性、可移植性、可靠性和安全性等方面的要求。
3.10 故障处理
a. 说明属于软件系统的问题； b. 经出发生错误时的错误信息； c. 说明发生错误时可能采取的补救措施。 3.11 算法说明
用于实施系统计算功能的公式和算法的描述。 a. 每个主要算法的概况；
b. 用于每个主要算法的详细公式。 4、尚未解决的问题
如需要，可说明软件需求中的尚未解决的遗留问题。 5、支持信息
如需要，可说明本产品的有关支持信息，如附录、索引等。
编写规范的使用说明
编写文档时，要求具有本规范规定的所有条目如果某条目无内容，则填写“无”，并在可能的情况下说明理由。必要时，可增加适当的条目。
最新精品资料整理推荐，更新于二〇二一年一月二十七日2021年1月27日星期三20:47:59
……………………………………………………………最新资料推荐…………………………………………………
附录3.2－6 《测试计划》文档编写规范
1、引言 1.1 目的
说明编写本测试计划的目的，指出预期读者。 1.2 范围
说明本测试计划适用的系统和软件的用途，以及系统和软件的版本号或标识号。 1.3 定义
列出本文中引用的专门术语。 1.4 引用文档
列了出本文档引用的其他文档的名称、编号、版本号。 2、软件测试环境
描述预计的测试现场的软件测试环境。 2.1 测试环境构成
描述用于测试的硬件、软件、拓扑结构，以及所有软硬件的配置、软件版本号，以及使用许可证要求。 2.2 安装、测试与控制
描述如何获取、安装、维护测试环境中的软件项。 2.3 参与组织
描述进行测试的组织和其职责。 2.4 人员
描述所需测试人类型、技术水平、数量。 3、测试内容 3.1 计划执行的测试
描述计划测试的总范围。 3.2 测试的总体设计
描述测试的策略和原则，包括测试类型，如集成测试、系统测试，以及测试方法，如白盒测试、黑盒测试、回归测试等。
最新精品资料整理推荐，更新于二〇二一年一月二十七日2021年1月27日星期三20:47:59
……………………………………………………………最新资料推荐…………………………………………………
3.3 测试用例
列出测试项的用例，能够输入数据、预期输出数据、测试步骤。 4、测试进度
为测试预计时间框架，包括准备环境的时间表、进行测试的时间表。
最新精品资料整理推荐，更新于二〇二一年一月二十七日2021年1月27日星期三20:47:59
……………………………………………………………最新资料推荐…………………………………………………
附录3.3－1 《软件结构设计说明书》文档编写规范
1、引言 1.1 编写目的
说明编写本软件结构设计说明书的目的，指出预期的读者。 1.2 背景
a. 说明待开发产品或项目（以下简称产品）的名称； b. 列出此开发任务的提出者、开发者、用户等。 1.3 基线
说明编写本软件结构设计说明书的设计基线。 1.4 范围
说明本软件结构设计说明书所涉及的内容范围。 1.5 定义
列出本文件中用到的专门术语的定义和缩写词原文。 1.6 参考资料
a. 本文件中引用的属于本开发产品的其他文件； b. 本文件中引有的其他文献、资料以及软件开发标准。 2、总体设计 2.1 概述 2.1.1 功能描述
参考本开发产品的《需求规格定义说明书》，说明对本产品要实现的功能、性能（包括：响应时间、安全性、兼容性、可移植性、资源使用等）要求。 2.1.2 运行环境
参考本开发产品的《需求规格定义说明书》，简要说明对本产品的运行环境（包括硬件环境和支持环境）的规定。 2.2 设计思想 2.2.1 系统构思
说明本产品设计采用的关键技术和主要算法。 2.2.2 关键技术与算法
最新精品资料整理推荐，更新于二〇二一年一月二十七日2021年1月27日星期三20:47:59
……………………………………………………………最新资料推荐…………………………………………………
简要说明本产品设计采用的关键技术和主要算法。 2.2.3 关键数据结构
简要说明本产品实现中的最主要的数据结构。 2.3 基本处理流程
系统流程图
用流程图表示本产品系统的主要控制流程和处理流程。 数据流程图
用数据流程图表示本产品系统的主要数据通路，并说明处理的主要阶段。 2.4 产品的系统体系结构 2.4.1 系统单元
说明本产品系统中各单位（子系统、模块、子程序、公用程序等）的划分，简要说明每个单元的标识符和功能等（用一览表和框图的形式说明）。 2.4.2 系统层次结构
分层地给出各个系统单元之间的控制与被控制关系。 2.4.3 系统单元设计
确定每个系统单元的功能。若是较大系统，可以根据需要对系统单元作进一步的划分及设计。
2.5 功能需求与系统单元的关系
说明各项系统功能的实现同各系统单元的分配关系（最好用矩阵图的方式）。 2.6 人工处理过程
说明在本产品的运行过程中包含的人工处理过程（若有的话）。 3、系统主要数据结构说明 3.1 数据结构
列出产品总体设计中产生的主要数据结构，包括它们的名称、标识符及主要数据项等。
3.2 数据结构与系统单元的关系
说明各个数据结构与访问这些数据结构的各个系统单元之间的对应关系。 4、接口设计 4.1 外部接口 4.1.1 用户接口
最新精品资料整理推荐，更新于二〇二一年一月二十七日2021年1月27日星期三20:47:59
……………………………………………………………最新资料推荐…………………………………………………
说明将向用户提供的输入、输出接口。 4.1.2 其它外部接口
说明本产品同外界其它，包括与硬件、各支持软件之间的接口关系。 4.2 内部接口
说明本产品内部各个功能模块之间的接口关系。 5、运行设计 5.1 系统初始化
说明本产品的初始化过程。 5.2 运行控制
a. 说明对系统施加不同的外界运行控制时所引起的各种不同的运行模块组合，说明每种运行所历经的内部模块和支持软件。
b. 说明每一种外界运行控制的方式方法和操作步骤。 c. 说明每种运行模块组合将占用各种资源的情况。 d. 说明系统运行时的安全控制。 5.3 运行结束
说明本产品运行的结束过程。 6、系统出错处理设计 6.1 出错信息
包括出错信息表、故障处理技术等。 6.2 补救措施
说明故障出现后可能采取的补救措施。 7、系统维护设计
说明为了系统维护的方便，在系统内部设计中作出的安排。 7.1 检测点的设计
说明在系统中专门安排用于系统检查与维护的检测点。 7.2 检测专用模块的设计
说明在系统中专门安排用于系统检查与维护的专用模块。 8、尚待解决的问题
说明 在本设计中没有解决而系统完成之前应该解决的问题。
最新精品资料整理推荐，更新于二〇二一年一月二十七日2021年1月27日星期三20:47:59
……………………………………………………………最新资料推荐…………………………………………………
附加说明：
编写文档时，要求具有本规范规定的所有条目。如果某条目无内容可填写，则填写“无”，并在可能的情况下说明理由。
最新精品资料整理推荐，更新于二〇二一年一月二十七日2021年1月27日星期三20:47:59
……………………………………………………………最新资料推荐…………………………………………………
附录3.4－1 《软件详细设计说明书》文档编写规范
1、引言 1.1 编写目的
说明编写本软件详细设计说明书的目的，指出预期的读者。 1.2 背景
a. 说明待开发软件系统的名称。
b. 列出开发此软件系统任务的提出者、开发者和用户等。 1.3 基线
说明编写本软件详细设计说明书的设计基线。 1.4 范围
说明本软件详细设计说明书的涉及的内容范围。 1.5 定义
列出本软件详细设计说明书中用到的专门术语和缩写词原文。 1.6 参考资料
属于本项目的其它已发表的文件。 本文件中引用的文献、资料、标准等。 2、程序系统体系结构 2.1 程序划分
用一系列图表列出本程序系统内的每个程序（包括每个模块和子程序）的名称、标识符、功能及其所包含的源程序文件名。 2.2 程序层次结构关系
用一系列图表列出本程序系统内的每个程序（包括每个模块和子程序）之间的层次结构与调用关系。 3、全局数据结构说明
本章说明本程序系统中使用的全局数据常量、变量和数据结构。 3.1 常量
包括数据文件名称及其所在目录，功能说明，具体常量说明等。 3.2 变量
最新精品资料整理推荐，更新于二〇二一年一月二十七日2021年1月27日星期三20:47:59
……………………………………………………………最新资料推荐…………………………………………………
包括数据文件名称及其所在目录，功能说明，具体变量说明等。 3.3 数据结构
包括数据结构名称，功能说明，具体数据结构说明（定义、注释、取值…）等。 4、程序设计
4.1 程序1《标识符》设计说明 4.1.1 数据结构说明
给出本程序中的局部数据结构说明，包括数据结构名称，功能说明，具体数据结构说明（定义、注释、取值…）等。 4.1.2 算法及流程
给出本程序的算法及流程，可采用流程图、PAD图或“表＋伪指令”的形式（参照相应的国际标准或国家标准）。 4.1.3 数据存储说明
具体说明需要以文件方式保存的数据文件名、数据存储格式、数据项及属性等。
4.1.4 源程序文件说明
给出本程序的各源程序文件的说明，包括源程序文件名称及其的居目录，功能说明，包含的前导文件及函数名称等。 4.1.5 函数说明
具体说明本程序中的各个函数，包括函数名称及其所在文件，功能，格式，参数，全程变量，局部变量，返回值，算法说明，使用约束等。 4.2 程序2（标识符）设计说明
用类似4.1的方式，说明第2个程序乃至第n个程序的设计考虑。
附加说明：
•编写文档时，要求具有本规范规定的所有条目。如果某条目无内容可填写，则填写“无”，并在可能的情况下说明理由。
最新精品资料整理推荐，更新于二〇二一年一月二十七日2021年1月27日星期三20:47:59
……………………………………………………………最新资料推荐…………………………………………………
附录3.5－1 《测试报告》文档编写规范
1、引言 1.1 目的
说明编写李测试报告的目的，指出预期读者。 1.2 范围
说明本测试报告适用的系统和软件的用途，以及系统和软件的版本号或标识号。 1.3 定义
列出本文中引用的专门术语。 1.4 引用文档
列出本文档引用的其他文档的名称、编号、版本号。 2、测试结果
描述每个测试用例的结果。 3、评价
根据测试结果对被测试软件进行全面评估。 4、改进建议
对被测试软件的设计、操作或测试提供改进建议。
最新精品资料整理推荐，更新于二〇二一年一月二十七日2021年1月27日星期三20:47:59
……………………………………………………………最新资料推荐…………………………………………………
附录3.6－1 集成工作单
集成工作单
（文件编号：MT-OP01A 版次：V01） 记录编号：MT-OP01A-
项目名称： 集成概述： 集成软件包信息 序号 相关人员： 软件功能 软件名 配置区系统及软件路径名 源代码冻结时间 集成负责人： 集成序号： 填写时间： 注解：
集成序号－表示第N次集成
集成概述－简要介绍此次集成的内容、策略、集成步骤和依赖的软硬件环境
集成软件包信息－包括软件功能、软件名、配置区系统及软件路径名、源代码冻结时间，例如，软件功能：浏览器，软件名：Netscape5.0，配置区系统及软件路径名：XX：/home/source/netscape/……，源代码冻结时间（在此期间内，不接受新的配置项）：2001/8/12 9：00 AM－2001/8/13 15：00 PM
集成产品－集成后的工作产品名
集成产品版本号－为集成产品分配版本号，用于标识不同的集成产品，该标识号在运行系统中应有体现
相关人员：集成人员，配置人员，主要相关的开发组负责人
最新精品资料整理推荐，更新于二〇二一年一月二十七日2021年1月27日星期三20:47:59
……………………………………………………………最新资料推荐…………………………………………………
附录3.6－2 集成测试工作单
集成测试工作单
（文件编号：MT-OP01B 版次：V01） 记录编号：MT-OP01B-
项目名称： 集成测试概述： 集成测试安排 序号 相关人员： 软件功能 软件名 测试负责人 计划测试时间（启动－终止） 集成测试负责人： 集成产品及版本号： 填写时间： 注解：
集成测试概述－简要介绍此次集成测试的内容、类型（接口、功能）、依赖的软硬件环境 集成产品及版本号－对应的集成产品名版本号（见集成工作单）
相关人员：集成人员，配置人员，问题管理负责人，主要相关的开发组负责人
最新精品资料整理推荐，更新于二〇二一年一月二十七日2021年1月27日星期三20:47:59
……………………………………………………………最新资料推荐…………………………………………………
附录3.9－1 《软件维护实施计划》文档编写规范
1、项目概述
项目目标、功能、用户、合同维护期限或版本使用期限的概要性介绍。 2、项目维护组织
简述项目维护小组成员构成、维护负责人及其职责，包括任务分配、过程信息记录与统计等责任的权限规定。 3、过程信息记录与统计
规定维护过程记录内容，需要度量的数据项、度量的责任人及统计的时间间隔。
4、维护工作流程
包括维护申请的接收、维护类型确认、维护申请优先级排定、维护任务分配、软件更新的发布。
5、维护过程记录与统计等。
最新精品资料整理推荐，更新于二〇二一年一月二十七日2021年1月27日星期三20:47:59
……………………………………………………………最新资料推荐…………………………………………………
附录3.10－1 软件问题报告单
软件问题报告单
（文件编号：MT-OP01C 版次：V01） 记录编号：MT-OP01C-
以下由汇报人填写 项目名称： 软件名称： 报告人姓名： Email*： 问题简述： 问题发现阶段： 版本号： 日期： □软件需求分析 □集成 问题类型： □结构设计 □系统测试 □详细设计 □验收 □编码 □维护 □编码 □重大 □设计 □高 □文档 □中 □硬件 □低 □建议 □疑问 严重程度： 是否可再现： □是 □否 问题及再现描述（包括环境）： 是否附件（注明页数）： 修改建议*： 以下由问题管理人员填写 问题修改责任者： 优先级： □立即解决 □尽快解决 □在下一个阶段版本前解决 □可能的情况下解决 以下由问题解决者填写 处理说明： 问题解决情况： 修订的版本号： □正在解决 □搁置 □已解决 □打开 □无法再现问题/需更多信息 □问题被撤回 □依照设计 问题状态： □关闭 问题解决者签字： 时 间： 问题解决者签字： 时 间： 问题解决者签字： 时 间： *表示可选 最新精品资料整理推荐，更新于二〇二一年一月二十七日2021年1月27日星期三20:47:59
……………………………………………………………最新资料推荐…………………………………………………
“软件问题报告单”填写说明
汇报人填写部分
问题简述：用一行句子表述，用于索引和查找。注意：即使两个相近问题的问题报告单，也不能用同一个简述，否则容易引起误会。
问题发现阶段：汇报者发现问题进所处的开发阶段，如编码、系统测试。
问题类型：
编码：汇报者认为是程序编码方面的问题，如：数值A是数值B和数值C的和，但程序语句为A＝B＋B；
设计：汇报者认为是设计方面的问题，而程序是“依据设计”实现的； 文档：程序执行结果于手册或联动帮助不符，或文档本身表述有问题； 硬件：汇报者认为问题是由于硬件支持导致的问题；
建议：汇报者没有发现错误，但相信其建议能改善现有的程序； 疑问：对程序或执行的结果不理解，但不能确信是问题。
严重程度：
重大：导致系统崩溃；
高：导致运行软件本身无法运行；
中：相关功能无法运行或运行不正常，但不影响软件的其他功能； 低：不影响功能运行的一些小问题，如提示语言窗口位置不明显，语言风格不合适。
是否可再现：
是：表示可以再现，并在“问题及再现描述”中描述如何再现，以帮助修改人员理解问题和发生环境。
否：测试者经多次努力没有找到再现的规律，但也可以在“问题及再现描述”中描述自己的推测。
问题及再现描述：
最新精品资料整理推荐，更新于二〇二一年一月二十七日2021年1月27日星期三20:47:59
……………………………………………………………最新资料推荐…………………………………………………
除非非常明显，否则汇报者应将导致问题出现的步骤描述清楚，包括系统环境，出错信息。对于无法再现的问题，可描述出错信息和汇报者的推测及系统信息。
建议：
此项可选，如果汇报者有修改此问题的建议，可以在此描述。
问题管理人填写部分
问题登记号：由问题管理人指定一个唯一的编号。
问题修改责任者：
指定负责修改问题的部门或部门的负责人。
优先级：
由问题分析人员定义。尽管对问题的优先级可能有不同的看法，但只有经项目经理许可才能改动问题的优先级。
状态：
打开：问题管理人在接到软件问题报告单后，经审核，填写此状态。
问题修改人填写部分
处理说明：
问题修改责任人可在此简单描述问题是如何修改的，或为什么搁置、或不同意见。如果是基于多用户的自动化问题管理系统，此项可以由看到此问题的相关人员同时填写，表态他们对此问题的想法。
问题解决状态：
正进行：修改者接到报告后，正进行修改； 已解决：已经解决，并已将工作产品提交；
无法再现问题/需更多信息：不能搞清问题所在，需要更多的信息；
最新精品资料整理推荐，更新于二〇二一年一月二十七日2021年1月27日星期三20:47:59
……………………………………………………………最新资料推荐…………………………………………………
搁置：项目经理知道这是个问题，但选择了在这个版本中不给予解决的决定，项目经理需为此项签字；
依照设计：例如，程序员是依据设计实现的，更正问题需要更正设计； 问题被撤：汇报者认为汇报有误，撤回软件问题报告单。
注：在基于纸介质的问题管理方式下，除非正在进行修改，其他状态下，需将签字后的报告单传至问题管理处。
状态：
关闭：测试者在对更新的工作产品进行测试之验证问题已解决后，填写此项，测试者需为此项签字。
最新精品资料整理推荐，更新于二〇二一年一月二十七日2021年1月27日星期三20:47:59
……………………………………………………………最新资料推荐…………………………………………………
软件问题报告单传递流程
开发及维护过 报告者 •项目名称、软件名称、版本号、姓名、日期 •问题简述、问题发现阶段、问题类型、严重程度 •是否可再现、再现描述
软件问题报告单 测试 构造新版本 解决 责任人修改 问题登记、分析 问题管理者 问题评估者 •修改建议 •问题标识号 •问题修改 •优先级 •置问题状态为打开 修改人 •处理说明 •问题解决情况 •签字 测试人员 •验证已解决后至“状态”为关闭，签字 •仍有问题，在签字处签字，并标明问题依然存在，保留“状态”为打开 最新精品资料整理推荐，更新于二〇二一年一月二十七日2021年1月27日星期三20:47:59
……………………………………………………………最新资料推荐…………………………………………………
附录3.10－2 软件问题状态登记表
软件问题状态登记表
（文件编号：MT-OPO1D 版次：V01） 记录编号：MT-OP01D-
问题登记号 问题简述 状 态 说 明 “软件问题状态登记表”填写说明
“问题登记号”、“问题简述”同“软件问题报告单”相应表项 状态：用于追溯问题解决的情况，状态值表示如下： 1、“软件问题报告单”已登记，以确定采取什么行动。
2、“软件问题报告单”中的问题已指定开发人员进行处理，正进行修改。 3、修改已作完，已提交配置库。
4、问题处理者认为：无法再现问题/需更信息；或不能搞清问题所在，需要更多的信息；或依照设计。
5、已完集成构造，正进行测试。 6、测试仍有问题。 7、问题搁置。
8、问题被撤：汇报者认为汇报有误，撤回软件问题报告单。
最新精品资料整理推荐，更新于二〇二一年一月二十七日2021年1月27日星期三20:47:59
……………………………………………………………最新资料推荐…………………………………………………
技术类评审
目 录
1、概述 ..................................................................................................................... 112 1.1 目的 ............................................................................................................. 112 1.2 适用范围 ..................................................................................................... 112 1.3 引用文件 ..................................................................................................... 112 1.4 术语 ............................................................................................................. 112 1.5 参考资料 ..................................................................................................... 112 2、过程总体描述 ..................................................................................................... 112 2.1 过程概述 ..................................................................................................... 112 2.2 结构描述 ..................................................................................................... 114 3、过程元素 ............................................................................................................. 115 3.1 走查 ............................................................................................................. 115 3.2 同行评审 ..................................................................................................... 117 3.3 设计评审 ..................................................................................................... 127 4、附录 ..................................................................................................................... 137 表1 同行评审计划........................................................................................... 137 表2－1 软件工作产品评审指导方针............................................................. 138 表2－2 评审检查表......................................................................................... 139 表3 个别审查记录表....................................................................................... 141 表4 评审会议记录........................................................................................... 142 表5 同行评审总结报告................................................................................... 143 表6 设计评审报告........................................................................................... 144 表7 评审人员名单........................................................................................... 145
最新精品资料整理推荐，更新于二〇二一年一月二十七日2021年1月27日星期三20:47:59
……………………………………………………………最新资料推荐…………………………………………………
1、概述
1.1 目的
用于指导在软件开发过程中进行的技术性评审活动，提高评审效率，使评审切实起到改善产品质量的作用。
1.2 适用范围
本公司的所有软件开发项目。
1.3 引用文件
无。
1.4 术语
无。
1.5 参考资料
•《软件能力成熟度模型CMM方法及其应用》，杨一平等著，人民邮电出版社，2001年4月
•《实践中的CMM－INFOSYS公司实施软件项目之过程》，潘卡•杰罗特著，杨慧鸣、李光龙译，内部试用版，2001年7月
•《Principles of Software Inspection for Chinasoft Co., Ltd.》，Frank. J. Koch，Process Strategies，Inc. January 2002
2、过程总体描述
2.1 过程概述
在本公司的质量体系文件中，将评审活动分为三类：技术类评审、管理类评
最新精品资料整理推荐，更新于二〇二一年一月二十七日2021年1月27日星期三20:47:59
……………………………………………………………最新资料推荐…………………………………………………
审和过程评审。其中：
•技术类评审是指针对软件项目实施过程中产生的工作产品进行的旨在尽早发现可能存在的缺陷的技术性评审活动，例如，针对软件需求规格说明书、设计说明书和源代码文件进行的设计评审和检查活动等。评审人员以工程技术人员为主。
•管理类评审是指软件项目实施过程中项目管理性质的评审活动，例如针对项目计划进行的评审和SCCB针对配置项进行的评审活动等。
管理类评审通常在技术类评审之后、工程阶段结束之前进行项目决策，例如，是否认可里程碑和基线，工作产品是否可以进入配置库等。评审人员由项目经理、配置管理人员、质量保证人员和项目组的部分技术人员组成。
•过程评审是指由SQA和/SEPG针对软件项目过程进行的评审活动，例如对项目计划中定义的项目软件过程进行的评审活动和针对项目的执行过程进行的评审活动等。
本文定义对技术类评审的要求和技术类评审的实施过程和方法。 本过程的目标是：
•有计划地进行技术类评审－以成本效益较高的方式来发现缺陷，提高生产效率
•及早识别并消除软件工作产品中的缺陷－改善产品质量
技术类评审适用于可运行测试的和不可运行测试的工作产品，通常在产生工作产品的工作阶段的中后期进行。对有些工作产品的技术类评审，也可能在产生该工作产品的过程中采用不同的技术类评审方法进行多次评审。通过技术类评审活动可以及早消除软件工作产品中的缺陷，改善产品质量。同时，通过技术类评审活动可以使相关人员对软件工作产品和能够预防的缺陷有更好的理解。
技术类评审通常按照事先定义好的检查表，系统地检测软件工作产品，找出其中可能存在的缺陷、确定需要更改的范围。
技术类评审关注的是被评审的软件工作产品本身，而不是软件工作产品的作者。技术类评审的结果也不应作为管理人员评价个人工作业绩的依据。
正式的技术类评审活动应在软件项目计划中做出安排，需要进行技术类评审的软件工作产品应在项目定义的软件过程中加以标识。
技术类评审可以分为三种形式：走查、同行评审和设计评审。其中：
最新精品资料整理推荐，更新于二〇二一年一月二十七日2021年1月27日星期三20:47:59
……………………………………………………………最新资料推荐…………………………………………………
•走查是在软件开发过程中对工作产品进行审查的一种评审形式。走查由作者自己对工作产品做逐行逐句的介绍，审查人员根据其讲解，指出其工作产品中可能存在的缺陷，以及与标准、规范的不符合项。通常用于正式或非正式的自查、互查，可以在工程阶段中灵活安排，可分散、多批次进行。
•同行评审又称同级评审，是在软件开发过程中按照明确定义的过程对工作产品进行系统检查的一种评审形式。同行评审由一组与软件工作产品的作者处于同一种级别的、具有类似工作（技术）经验的技术人员来进行。作为一种特例，同行评审可以由一个人来完成（单人评审）。
同行评审可以在工程阶段中灵活安排，可分散、多批次进行。
•设计评审是在软件开发过程中的阶段后期按照明确定义的过程对工作产品进行实现方案和实现技术确认的一种评审形式。设计评审通常在一个工程阶段结束之前，针对作为里程碑和基线的工作产品进行。
评审人员由技术专家、高层经理、项目经理和项目组部分技术人员组成，必要时还可以邀请客户代表参加。
针对不同的工作产品，对一个工作产品的技术类评审可以单独采用上述三种形式形式之一进行评审，也可以综合采用多种形式进行评审。在一个项目中，对哪些工作产品进行哪些评审，由项目组在进行项目策划时确定。
2.2 结构描述
缺陷记录 软件工作产品 走查 同行评审 评审总结报告 设计评审 技术类评审 当对一个工作产品综合采用多种形式进行评审时，应按照走查－同行评审－设计评审的顺序进行，工作产品与评审关系如下表所示：
最新精品资料整理推荐，更新于二〇二一年一月二十七日2021年1月27日星期三20:47:59
……………………………………………………………最新资料推荐…………………………………………………
工作产品 评审类型 系统需求规格说明书 软件需求规格说明书 结构设计说明书 详细设计说明书 编 码 集成测试计划 系统测试计划 最终发布产品 项目计划 软件规模 公司过程开发和改进活动计划 公司标准软件过程 软件生命周期文件 走查 √ √ 同行评审 √ √ √ √ √ √ √ √ √ √ 设计评审 √ √ √ SCCB评审 √ √ √ 项目管理类评审 √ 3、过程元素
以下分别对各过程元素进行具体描述。
3.1 走查
3.1.1 元素概述
走查通常用于工作组内部的正式或非正式自查、互查，以便尽早发现工作产品中可能存在的设计缺陷和不符合标准、规范的问题。同时，也是技术人员切磋技艺、提高工作水平的一种很好的交流形式。
走查以讲演会的方式进行，由作者自己对工作产品做逐行逐句的介绍，审查人员根据其讲解，指出其工作产品中可能存在的缺陷，以及与标准、规范的不符合项。在走查中发现的缺陷和问题，由作者在走查结束之后做适当的处理。
走查主要适用于实现阶段和详细设计阶段的工作产品。例如：程序源代码文件、数据源代码文件、详细设计说明书、数据编码说明书等。
正式的走查活动应在软件项目计划中做出安排。需要进行正式的走查的软件工作产品应在项目定义的软件过程中加以标识。一个软件工作产品是否需要进行走查，由项目经理和项目组在项目过程中定义。
最新精品资料整理推荐，更新于二〇二一年一月二十七日2021年1月27日星期三20:47:59
……………………………………………………………最新资料推荐…………………………………………………
软件工作产品 走查缺陷记录
3.1.2 入口准则和出口准则
（1）入口准则
工作产品 要评审的软件工作产品及其源头文件 （2）出口准则
工作产品 评审检查表 缺陷记录 3.1.3 任务
（1）选择评审人员由作者向工作组负责人或项目经理提出走查评审要求，并协商确定参加评审的适当人员。评审人员可以是本工作组的成员，也可以是其他工作组的成员。需要特别指出的是，适当吸收其他工作组的成员参加走查，对提高工作产品的可读性是非常有帮助的。
此外，还要落实评审场地和时间，并通知参加评审的人员。
（2）确定检查表选择或编制适用于走查对象的检查表，以便评审人员有一致的评判标准。
（3）走查演讲会在讲演会上，由作者自己逐行逐句的讲解其工作产品，审查人员根据检查表的要求和自身的经验，随时指出其工作产品中存在的缺陷，以及与标准、规范的不符合之处，交流工作中的经验。作者应记录下存在的缺陷和不符合项，以便在走查结束之后做必要的修改。参见附录中的表3个别审查记录表。
3.1.4 工作产品
•评审检查表 •缺陷记录
确认准则 已编制 已记录 确认准则 作者已准备 最新精品资料整理推荐，更新于二〇二一年一月二十七日2021年1月27日星期三20:47:59
……………………………………………………………最新资料推荐…………………………………………………
3.1.5 职责
作者：准备好所要评审的工作产品及相关文件；选择评审人员；确定检查表；落实评审场地和时间；邀请评审人员；在讲演会上讲解工作产品；记录缺陷和问题，并在事后进行适当的处理。
工作组负责人或项目经理：协助作者选择评审人员，落实评审场地和时间；安排评审人员的工作任务；监督作者对走查中发现的缺陷和问题的修改和解决。
评审人员：根据检查表和自身的经验，发现工作产品中可能存在的缺陷和不符合项。交流工作中的经验。 3.1.6 资源与能力要求
•会议场地 3.1.7 度量
•是否编制了适合评审对象的评审检查表 •是否所有缺陷和不符合项都记录在案 •缺陷数量
•记录完成走查所花费的人工时 3.1.8 详细裁剪指南
活动 确定评审检查表 检查表 文件 使用检查表 不使用检查表 度量 缺陷数量 度量项 执行 不执行 正式评审 非正式评审 正式评审或非正式评审 非正式评审 可裁剪属性 选择 裁剪指导方针 3.2 同行评审
3.2.1 元素概述
最新精品资料整理推荐，更新于二〇二一年一月二十七日2021年1月27日星期三20:47:59
……………………………………………………………最新资料推荐…………………………………………………
个 别 审 查 评 审 会 议 缺 陷 和 问 题 跟 踪 同行评审总结报告 软件工作产品 评 审 计 划 评审计划、检查 个别审查记录 评审会议记录 同行评审（又称同级评审）是在软件开发过程中按照明确定义的过程对工作产品进行系统检测的方式之一。同行评审由一组与软件工作产品的作者处于同一级别的、具有类似工作（技术）经验的技术人员来进行。作为一种特例，同行评审可以由一个人来完成（单人评审）。
同行评审人员按照事先定义好的检查表系统地检测软件工作产品，找出其中可能存在的缺陷、确定需要更改的范围，并对消除缺陷过程进行跟踪。
同行评审关注的是被评审的软件工作产品本身，而不是软件工作产品的作者。与软件工作产品的作者相关的管理人员不应参加同行评审，因为相关的管理人员参加同行评审可能会妨碍评审员提出问题或发现缺陷。同行评审的结果也不应作为管理人员评价个人工作业绩的依据。
应进行同行评审的工作产品包括： •公司级的过程定义文件
例如：过程开发和维护活动计划、标准软件过程文件、软件生命周期模型描述文件等
•软件项目管理过程中的工作产品
例如：项目计划、风险管理计划、软件规模估算等 •软件开发过程中的下列工作产品
*各种说明书（例如，软件需求规格说明书、概要设计说明书、详细设计说明书、数据编码说明书等）
最新精品资料整理推荐，更新于二〇二一年一月二十七日2021年1月27日星期三20:47:59
……………………………………………………………最新资料推荐…………………………………………………
*各种计划书（例如，系统测试计划、集成测试计划等） *其它文档（例如，系统测试用例，集成测试用例等）
同行评审活动应在软件项目计划中做出安排。需要进行同行评审的软件工作产品应在项目定义的软件过程中加以标识。一个软件工作产品是否需要进行同行评审，由项目经理和项目组在项目过程中定义。整个标准软件过程中需同行评审的地方有：
•公司过程开发和改进活动计划 •公司标准软件过程 •软件生命周期文件
•软件规模（对软件规模估算的有效性产生怀疑时） •软件需求规格说明书 •软件设计说明书 •测试计划、用例、规程 3.2.2 入口准则和出口准则
（1）入口准则
工作产品 要评审的软件工作产品及其源头文件 （2）出口准则
工作产品 同行评审计划 评审检查表 个别审查记录表 评审会议记录 同行评审总结报告 3.2.3 任务
（1）评审计划
同行评审的准备阶段。旨在确定评审人员、明确评审标准、制定评审计划、使评审人员了解评审要求。准备步骤如下：
最新精品资料整理推荐，更新于二〇二一年一月二十七日2021年1月27日星期三20:47:59
确认准则 作者已提交 确认准则 已编制 已编制 所有评审员均已提交给主持人，并得到主持人的认可 已经被确认 已完成，并且所有缺陷和问题都已得到解决 ……………………………………………………………最新资料推荐…………………………………………………
①项目经理和软件工作产品的作者（以下简称：作者）协商确定同行评审的主持人。
主持人应：
•有能力和时间承担同行评审的总体责任 •有能力确保以适当的方式进行和完成同行评审 •能够确保在同行评审过程中遵循所有步骤
•接受过如何进行同行评审的正规培训，或者具有参加过几次同行评审的经验
作者不能担任主持人。
②选择合适的评审员，建立评审组。
评审组的所有成员都是评审员，包括主持人、作者和书记员均可作为评审员。 ③必要时对主持人和评审员进行相关培训。 培训内容包括：
•同行评审的目标、原理和方法 •对同行评审进行计划和组织的过程 •同行评审的准备就绪准则和完成准则 •执行和促进同行评审工作
•跟踪和确认基于同行评审识别的缺陷而进行的软件工作产品的返工 •收集同行评审所生产的数据 •报告同行评审的结果
④主持人必须首选确认已经符合本过程的入口准则。
⑤确定评审人员的分工，编制评审工作计划。参见附录中的表1同行评审计划。
评审计划和个别审查过程最好在一个连续的时间段内完成。个别审查的时间与评审会议的时间比大约为1：1。
⑥编制/优化评审检查表及评审标准。
针对特定的软件工作产品，需要根据软件工作产品评审指导方针的要求编制特定的检查表，或者对标准检查表进行裁剪。重点考虑：对标准和规范的符合性、完整性和正确性、构造规则及可维护性。
参见附录中的表2－1软件工作产品评审指导方针和表2－2评审检查表
最新精品资料整理推荐，更新于二〇二一年一月二十七日2021年1月27日星期三20:47:59
……………………………………………………………最新资料推荐…………………………………………………
（例）。
⑦复制并分发评审文件。
评审文件包括所要评审的软件工作产品及其技术规范（通常是生产该软件工作产品的工作过程的输入）。
⑧召开评审动员会。
说明和规定评审的各项目标；根据需要提供对评审文件和评审过程的介绍。 召开会议时，主持人负责简要说明所要评审的软件工作产品、评审组的各项目标，以及评审过程要求（如果必要）。软件工作产品的作者也可以对软件工作产品做进一步的说明，包括特别难于理解和掌握的问题。在这个会议上，应特别强调和明确关于软件项目或软件工作产品的特殊问题。这个步骤是可选项，在没有必要召开会议时，主持人只需向评审员提供评审文件即可。
（2）个别审查
同行评审的个别审查阶段。评审员已经了解评审要求，并有能力和时间承担相应的同行评审工作。在此基础上，给评审人员一定的时间，按照检查表，独自对工作产品进行审查，查找并记录软件工作产品中可能存在的缺陷。个别审查步骤如下：
①个别审查软件工作产品
评审员应仔细阅读评审文件，使用检查表以一致的评审准则审查软件工作产品，分别做好评审会议的准备工作。
如果软件工作产品有不明确的地方或者看起来存在缺陷，那么，评审员应在个别审查记录中记录缺陷或问题并加以必要的说明。参见附录中的表3个别审查记录表。
②记录在个别审查过程中所花费的时间 ③提交个别审查记录表
个别审查完毕时，评审员应将个别审查记录表提交给主持人。 ④检查个别审查的情况
主持人应对个别审查记录表中的工作量和缺陷数据做简要的检查，核实评审员在个别审查中确实投入了足够充分的时间和精力。如果准备工作不充分，则应该推迟评审会议。
（3）评审会议
最新精品资料整理推荐，更新于二〇二一年一月二十七日2021年1月27日星期三20:47:59
……………………………………………………………最新资料推荐…………………………………………………
评审会议是确认个别审查中所发现缺陷和问题的过程。主持人在所有评审员都已提交符合要求的个别审查记录表后召开评审会议，并负责掌握会议进程。
评审过程中的一条基本原则是，只确认各项缺陷和问题，不讨论其解决方案！这一点需要主持人特别关注。解决缺陷和问题是作者和相关人员在会议之后要做的工作。
a. 小组评审会议议程 •审议
逐项审议：由阅读员逐条朗读个别审查提交的缺陷记录，向评审组解释清楚每一项的含义。如果评审员以前确认了此项缺陷，或者在听取朗读时有新的发现，均可以随时举手，提出自己的意见，对此项缺陷进行讨论。
逐段审议：由阅读员逐段朗读被评审的工作产品或者由主持人根据被评审的工作产品逐段引导评审员审议。如果评审员以前确认了关于此段的缺陷，或者在审议时有新的发现，均可以随时举手发言，提出自己的意见，对此段中的缺陷逐项进行讨论。
采用哪一种审议方法，由主持人决定。
•在会议结束之前，由书记员说明在会议中发现和确认了哪些缺陷和问题，还有哪些缺陷和问题需要进一步讨论和审查，并进行最终确认。
•如果只需要做少量修改即可解决缺陷和问题，则将缺陷和问题的状态标记为“已被接受”。如果需要做许多修改，则必须由主持人召开一次跟踪会议或者重新做一次同行，验证对软件工作产品的各项修改是否已经正确地完成。
•主持人负责建议需要进行和完成哪些任务，并根据以往的数据提供用于实施这些建议的指导方针。主持人还要负责归纳和整理关于所提出问题的总结。
•缺陷应该由作者解决－返工；而问题则可以由不同人员解决。可以在会议 结束之前分配任务，以便跟踪所存在的问题解决情况。 b. 单人评审会议议程
•只有作者和评审员两人参加会议。双方通过逐条讨论，确认并记录缺陷和问题；明确解决问题的分工。
•评审员负责填写同行评审总结报告。 （4）缺陷和问题跟踪
监督基于同行评审识别出的缺陷而进行的软件工作产品的返工；必要时进行
最新精品资料整理推荐，更新于二〇二一年一月二十七日2021年1月27日星期三20:47:59
……………………………………………………………最新资料推荐…………………………………………………
后续的评审；收集、报告同行评审产生的数据。
•由作者修改识别出的所有缺陷。
•主持人跟踪缺陷修改情况，必要时重新召开评审会议。
•对有待解决的问题进行调查，并将调查结果提供给作者，并确认是否存在缺陷。
•必要时召开全体或部分评审员的评审会议，重新评审经过修改的软件工作产品，或讨论对有待解决问题的研究分析结果（工作方式与评审会议相同）。
•编写同行评审总结报告，并将报告提交给项目经理（项目经理应将同行评审总结报告放入项目控制数据库）。 3.2.4 工作产品
•《同行评审计划》（MT-PTM09A） •评审检查表
•《个别审查记录表》（QR-PTM09B） •《评审会议记录》（QR-PTM09C） •《同行评审总结报告》（MT-PTM09D） 3.2.5 职责
（1）作者：软件工作产品的作者
•负责提供需要进行同行评审的软件工作产品和相关资料，并准备好分发给评审员的副本。
•配合项目经理确定主持人和评审组人选。 •在评审会议上审查所讨论的问题，包括： *澄清不是缺陷或问题的理由 *确认缺陷和有待讨论和解决的问题 •修改识别出的所有缺陷。
（2）主持人：作为评审组长，对评审总体负责，并协调同行评审期间的各项工作。
•选择评审员，组建评审组 •组织、安排对评审员的培训 •编制评审计划 •编制检查表及评审标准
最新精品资料整理推荐，更新于二〇二一年一月二十七日2021年1月27日星期三20:47:59
……………………………………………………………最新资料推荐…………………………………………………
•分发评审文件
•召开评审动员会，介绍评审要求及背景情况 •个别检查评审员的工作产品；收集个别审查记录表。 •负责会议的组织并控制会议的进程，包括：
*确保会议始终围绕主要目的－发现和确认缺陷或问题 *确保对所发现的问题都能够达成一致或者形成共识 *确保所有缺陷和问题都记录在案 *确保每个问题都有人跟踪和解决 *负责填写同行评审总结报告
•负责确保已经确认的所有缺陷和问题，以及度量数据都记录在案，所有缺陷和问题得到解决。
•负责完成同行评审总结报告，包括对下一阶段工作（如果存在）的建议。参见附录中的表5同行评审总结报告。
（3）评审员：负责找出软件工作产品中存在的缺陷。 •必要时参与制定评审计划、检查表及评审标准。 •找出并记录软件工作产品中存在的缺陷。 •记录在个别审查阶段所花费的时间。 •向主持人提交个别审查记录表。 •积极参与会议审议。
•如果承担了解决遗留问题的任务，则对问题进行调查，并提交调查结果和所花费工时的记录。
（4）项目经理：
•负责选择主持人，并在获得主持人同意之后选择其他评审组成员。 •完成同行评审熽和评审产品数的统计。
（5）阅读员：通常由评审员担任，主持人和作者不能担任阅读员。 •负责逐条朗读个别审查提交的缺陷记录，向评审组解释清楚每一条的含义。 （6）书记员：可以由主持人或作者兼任。 •负责将所提出的问题和缺陷记录下来。 •完成评审会议记录。
•将会议结果告知评审组全体成员。
最新精品资料整理推荐，更新于二〇二一年一月二十七日2021年1月27日星期三20:47:59
……………………………………………………………最新资料推荐…………………………………………………
（7）质量保证人员： •完成缺陷的统计。 3.2.6 资源与能力要求
•评审文件的复制资源 •评审文件的分发资源 •评审员的培训资源 •会议场地 •记录工具 3.2.7 度量
•确定了同行评审的评审人员及其分工
•评审员有能力和时间承担相应的同行评审工作 •编制了适合评审对象的评审检查表 •编制了可实施的同行评审计划 •预先分发了评审文件
•评审计划过程中所花费的人工时
•个别审查记录表是否都符合评审要求 •个别审查过程中所花费的人工时 •是否所有缺陷和问题都记录在案 •是否每个问题都有人跟踪和解决 •是否按要求填写了同行评审总结报告 •缺陷数量 •问题数量
•缺陷类型（严重程度） •会议时间
•评审会议所花费的人工时
•是否所有缺陷和问题得到解决 •评审所花费的总工时
•与计划相比较，实施同行评审的次数统计
最新精品资料整理推荐，更新于二〇二一年一月二十七日2021年1月27日星期三20:47:59
……………………………………………………………最新资料推荐…………………………………………………
•与计划相比较，被评审产品的数目统计 3.2.8 详细裁剪指南
活动 组建评审组 评审组规模 规模 单人评审 小组评审 根据评审对象的重要性、技术难度、规模，以及评审员能够投入的时间和评审成本，确定评审组的人数（至少3人－作者、主持人和阅读员）。 适用于重要性、复杂性和技术难度不高的软件工作产品。 评审过程与多人的评审组基本相同，只是仅有一名评审员，评审会议只有作者和评审员参加。 编制评审检查表 编制/优化检查表 内容 没有标准检查表或标准检查可裁剪属性 选择 裁剪指导方针 不能使用标表不完全符合评审需求，则针准检查表 对软件工作产品的实际情况编制检查表或在标准检查表的基础上，优化检查表项。 可以使用标准检查表 其它情况。 评审动员会 评审动员会 执行 不执行 评审员均熟悉同行评审过程及评审要求，通过阅读评审文件就能够理解被评审的软件工作产品，并独立进行个别评审。 最新精品资料整理推荐，更新于二〇二一年一月二十七日2021年1月27日星期三20:47:59
……………………………………………………………最新资料推荐…………………………………………………
执行 其它情况。必要时，可以请作者介绍有关情况。 检查个别审查的情况 检查 执行 执行 不执行 会议议程 小组评审会议议程 单人评审会议议程 审议 审议 方法 逐项审议 逐段审议 跟踪 缺陷跟踪 执行 不跟踪 跟踪 软件项目很重要 存在重要或严重缺陷 软件项目不很重要 缺陷不严重且不重要 跟踪 不跟踪 存在有待解决的问题 不存在有待解决的问题 被评审的工作产品规模较大 被评审的工作产品规模不大 执行 执行 不执行 单人评审 小组评审 执行 执行 小组评审 小组评审 单人评审 3.3 设计评审
3.3.1 元素概述
最新精品资料整理推荐，更新于二〇二一年一月二十七日2021年1月27日星期三20:47:59
……………………………………………………………最新资料推荐…………………………………………………
工作产品 评 审 个 别 审 查 评 审 会 议 缺 陷 和 问 题 跟 踪 设计评审总结报告 计 划 评审计划、检查 个别审查记录 评审会议记录
设计评审是在软件开发过程中的阶段后期按照明确定义的过程对工作产品进行实现方案和实现技术确认的一种评审形式。设计评审通常在一个工程阶段结束之前，针对作为里程碑和基线的工作产品进行。
设计评审的目的是在工程进入下一阶段之前，尽可能地识别出工作产品中的重大技术缺陷，避免后续工程因工作产品的质量缺陷而出现大量返工和严重工期延误。同时，通过设计评审可以使相关人员对工作产品和能够预防的缺陷有更好的理解。
设计评审由技术专家、高层经理、项目经理和项目组主要技术人员进行，必要时还可以邀请客户代表参加。
设计评审人员按照事先定义好的检查表系统地审查工作产品，找出其中可能存在的缺陷、确定需要更改的范围，并对消除缺陷过程进行跟踪。
设计评审活动应在项目计划中做出安排，通常在工程阶段结束之前进行。需要进行设计评审的工作产品应在项目定义的项目过程中加以标识。一个工作产品是否需要进行设计评审，由项目经理和项目组在项目过程中定义。 3.3.2 入口准则和出口准则
（1）入口准则
最新精品资料整理推荐，更新于二〇二一年一月二十七日2021年1月27日星期三20:47:59
……………………………………………………………最新资料推荐…………………………………………………
工作产品 要评审的工作产品及其源头文件 （2）出口准则
工作产品 设计评审计划 评审检查表 个别审查记录表 评审会议记录 设计评审报告 设计评审总结报告 确认准则 已编制，且可实施（相关人员有时间和能力） 已编制 所有评审员均已提交 已经被确认 已按要求填写 已完成，并且所有缺陷和问题都已得到解决 3.3.3 任务
（1）评审计划
设计评审的准备阶段。旨在确定评审人员、明确评审标准、制定评审计划、使评审人员了解评审要求。
•质量保证人员和项目经理协商确定设计评审的评审组长。 评审组长应：
*有能力和时间承担设计评审的总体责任 *有能力确保以适应的方式进行和完成设计评审 *能够确保在设计评审过程中遵循所有步骤 作者不能担任评审组长。
•质量保证人员和评审组长协商选择合适的评审人员，建立评审组。 •必要时对评审组长和评审人员进行相关培训。 培训内容包括：
*设计评审的目标、原理和方法 *对设计评审进行计划和组织的过程 *设计评审的准备就绪准则和完成准则 *执行和促进设计评审工作
最新精品资料整理推荐，更新于二〇二一年一月二十七日2021年1月27日星期三20:47:59
确认准则 作者已提交 ……………………………………………………………最新资料推荐…………………………………………………
*跟踪和确认基于设计评审识别的缺陷而进行的工作产品的返工 *收集设计评审所产生的数据 *报告设计评审的结果
•评审组长必须首先确认已经符合本过程的入口准则。
•质量保证人员或评审组长确定评审人员的分工，编制评审工作计划。参见附录中的表1同行评审计划。
评审计划和个别审查过程最好在一个连续的时间段内进行并完成。个别审查的时间，大约与评审会议的时间为1：1。
•质量保证人员或评审组长编制/优化评审检查表及评审标准。
针对特定的工作产品，需要根据设计评审指导方针的要求编制特定的检查表，或者对标准检查表进行裁剪。重点考虑：对标准和规范的符合性、完整性和正确性、可行性、可靠性及可测试性。
参见附表中的2－1设计评审指导方针和表2－2评审检查表（例） •复制并分发评审文件。
评审文件包括所要评审的工作产品及其技术规范（通常是产生该工作产品的工作过程的输入）。
可以提前分发，也可以在评审预备会上分发。 •召开评审预备会。
说明和规定评审的各项目标；根据需要提供对评审文件和评审过程的介绍。 召开会议时，评审组长负责简要说明所要评审的工作产品、评审组的各项目标，以及评审过程要求。作者也可以对工作产品做进一步的说明，包括特别难于理解和掌握的问题以及希望重点审议的问题。在这个会议上，应特别强调和明确关于项目或工作产品的特殊问题。这个步骤是可选项，在没有必要召开会议时，评审组长只需向评审人员提供评审文件即可。
（2）个别审查
设计评审的个别审查阶段。给评审人员一定的时间，按照检查表，独自对工作产品进行审查，查找并记录工作产品中可能存在的缺陷。
•个别审查工作产品
评审人员应在参加评审会议前仔细阅读评审文件，使用检查表以一致的评审准则审查工作产品，分别做好评审会议的准备工作。
最新精品资料整理推荐，更新于二〇二一年一月二十七日2021年1月27日星期三20:47:59
……………………………………………………………最新资料推荐…………………………………………………
如果工作产品有不明确的地方或者看起来存在缺陷，那么，评审人员应在个别审查记录中记录缺陷或问题并加以必要的说明。参见附录中的表3个别审查记录表。
•记录在个别审查过程中所花费的时间。 •检查个别审查的情况。
在可能的情况下，质量保证人员应对个别审查记录表中的工作量和缺陷数据做简要的检查，核实评审人员在个别审查中确实投入了足够充分的时间和精力。如果准备工作不充分，则应该推迟评审会议。
（3）评审会议
评审会议是对关键技术方案进行论证，并确认个别审查中所发现的缺陷和问题的过程，评审组长负责掌握会议进程。评审过程中的一条基本原则是，只论证技术方案，提出改进建议；确认各项缺陷和问题，不解决具体缺陷和问题！这一点需要评审组长特别关注。解决缺陷和问题是作者和相关人员在会议之后要做的工作。
•评审组长应确认所有与会人员是否已做好参加会议的准备。如果准确工作不充分，则应推迟评审会议。
•审议
逐项审议：由阅读员逐条朗读个别审查提交的缺陷记录，向评审组解释清楚每一项的含义。如果评审人员以前确认了此项缺陷，或者在听取朗读时有新的发现，均可以随时举手发言，提出自己的意见，对此项缺陷进行讨论。
逐段审议：由阅读员逐段朗读被评审的工作产品或者由评审组长根据被评审的工作产品逐段引导评审人员审议。如果评审人员以前确认了关于此段的缺陷，或者在审议时有新的发现，均可以随时举手发言，提出自己的意见，对此段中的缺陷逐项进行讨论。采用哪一种审议方法，由评审组长决定。
•作者应对所讨论的问题进行审查，并澄清其不是缺陷或问题的理由，或者同意其是缺陷或是有待讨论和解决的问题。
书记员负责将所提出的问题和缺陷记录下来。参见附录中的表4评审会议记录。
•在会议结束之前，由书记员会议中发现和确认了哪些缺陷和问题，还有哪些缺陷和问题需要进一步讨论和审查，并进行最终确认。评审组长负责归纳和整
最新精品资料整理推荐，更新于二〇二一年一月二十七日2021年1月27日星期三20:47:59
……………………………………………………………最新资料推荐…………………………………………………
理出关于所提出问题的总结，形成评审结论，并就评审结论达成一致意见。
•如果只需做少量修改即可解决缺陷和问题，则将缺陷和问题的状态标记为“已被接受”。如果需要做许多修改，则必须由质量保证人员召集一次跟踪会议或者重新做一次设计评审，验证对工作产品的各项修改是否已经正确地完成。
•评审组长负责填写设计评审报告。参见附录中的表5设计评审报告。其中，“评审通过后的批准意见”一栏，供管理类评审使用。
•缺陷应该由作者解决－返工；而问题则可以由不同人员解决。可以在会议结束之前分配任务，以便跟踪所存在的问题解决情况。
•质量保证人员应编制评审人员名单，参见附录中的表6评审人员名单，并在会议结束之前收集评审人员的个别审查记录表。会后负责编写设计评审总结报告。
（4）缺陷和问题跟踪
监督基于设计评审识别出的缺陷而进行的工作产品的返工；必要时进行后续的评审；收集、报告设计评审产生的数据。
•由作者修改识别出的所有缺陷。
•质量保证人员跟踪缺陷修改情况，必要时重新召开评审会议。
•对有待解决的问题进行调查，并将调查结果提供给作者，并确认是否存在缺陷。
•必要时召开全体或部分评审人员的评审会议，重新评审经过修改的工作产品，或讨论对有待解决问题的调查结果（工作方式与评审会议相同）。
•质量保证人员负责完成设计评审总结报告，并将报告提交给项目经理（项目经理应将设计评审总结报告放入项目控制数据库）。 3.3.4 工作产品
•《设计评审计划》（同《同行评审计划》（MT-PTM09A）） •评审检查表
•《个别审查记录表》（QR-PTM09B） •《评审会议记录》（QR-PTM09C） •《设计评审报告》（QR-PTM09E）
•《设计评审总结报告》（同《同行评审总结报告》（MT-PTM09D）） 3.3.5 职责
最新精品资料整理推荐，更新于二〇二一年一月二十七日2021年1月27日星期三20:47:59
……………………………………………………………最新资料推荐…………………………………………………
（1）作者：工作产品的作者。
•负责提供需要进行评审的工作产品和相关资料。 •对评审会议上所讨论的问题做必要的解释。 •修改识别出的所有缺陷。 （2）质量保证人员：
•负责选择评审组长和其他评审组成员。 *选择评审人员，组建评审人组； *负责编制/优化评审检查表及评审标准； *准备好分发给评审人员的评审文件副本； *联络评审人员，分发评审文件；
*召开评审预备会，介绍评审要求及背景情况。 •检查个别审查的情况，确定能否按时召开评审会议。 •协助评审组长组织并控制会议的进程，包括： *确保所有缺陷和问题都记录在案； *确保每个问题都有人跟踪和解决。
•负责确保已经确认的所有缺陷和问题，以及度量数据都记录在案，所有缺陷和问题得到解决。
•负责完成设计评审总结报告，包括对下一阶段工作产品（如果存在）的评审建议。参见附录中的表5设计评审总结报告。
（3）项目经理：
•协助质量保证人员选择评审组长。 •作为评审人员参加评审会议。
•完成设计评审数目和评审产品数的统计。
（4）评审组长：对评审总体负责，并协调设计评审期间的各项工作。 •在评审计划的活动中负责： *确认评审成员；
*组织、安排对评审人员的培训； *编制评审计划；
*协助编制检查表及评审标准；
•负责会议的组织并控制会议的进程，包括：
最新精品资料整理推荐，更新于二〇二一年一月二十七日2021年1月27日星期三20:47:59
……………………………………………………………最新资料推荐…………………………………………………
*确保会议始终围绕主要目的－发现和确认缺陷和问题。 *确保对所发现的缺陷或问题都能够达成一致或者形成共识。 （5）评审人员：
•必要时参与制定评审计划、检查表及评审标准。 •根据检查表和分工要求，审查工作产品。 •找出并记录工作产品中存在的缺陷。 •记录在个别审查阶段所花费的时间。
•积极参与会议审议，审查所讨论的问题，包括： *澄清不是缺陷或问题的理由； *确认缺陷和有待讨论和解决的问题。
•如果承担了解决遗留问题的任务，则对问题进行调查，并提交调查结果和所花费工时的记录。
（6）阅读员：通常由评审人员担任，评审组长和作者不能担任阅读员。 •负责逐条朗读个别审查提交的缺陷记录，向评审组解释清楚每一条的含义。 （7）书记员：可以由评审组长或作者兼任。 •负责将所提出的问题和缺陷记录下来。 •完成评审会议记录。
•将会议结果告知评审组全体成员。 3.3.6 资源与能力要求
•评审文件的复制资源 •评审文件的分发资源 •评审人员的培训资源 •会议场地 •记录工具 3.3.7 度量
•确定了设计评审的评审人员及其分工
•评审人员有能力和时间承担相应的设计评审工作 •编制了适合评审对象的评审检查表 •编制了可实施的设计评审计划 •预先分发了评审文件
最新精品资料整理推荐，更新于二〇二一年一月二十七日2021年1月27日星期三20:47:59
……………………………………………………………最新资料推荐…………………………………………………
•评审计划过程所花费的工时
•个别审查记录表是否都符合评审要求 •个别审查过程中所花费的工时
•是否所有缺陷和问题都记录在案 •是否每个问题都有人跟踪和解决 •是否按要求填写了设计评审总结报告 •缺陷数量 •问题数量
•缺陷类型（严重程度） •会议时间
•评审会议所花费的工时
•是否所有缺陷和问题得到解决 •评审所花费的总工时
•与计划相比较，实施设计评审的次数统计 •与计划相比较，被评审产品的数目统计
最新精品资料整理推荐，更新于二〇二一年一月二十七日2021年1月27日星期三20:47:59
……………………………………………………………最新资料推荐…………………………………………………
3.3.8 详细裁剪指南
活动 编制评审检查表 编制/优化检查表 内容 没有标准检查表或标准检查表不完全符合评审需求，则针可裁剪属性 选择 裁剪指导方针 不能使用标对工作产品的实际情况编制准检查表 检查表或在标准检查表的基础上，优化检查表项。 使用标准检其它情况 查表 评审预备会 评审预备会 执行 执行 不执行 评审人员均熟悉设计评审过程及评审要求，通过阅读评审文件就能够理解被评审的工作产品，并独立进行个别评审。 其它情况。必要时，可以请作者介绍有关情况。 审议 审议 方法 逐项审议 逐段审议 跟踪 缺陷跟踪 执行 不跟踪 跟踪 软件项目很重要 存在重要或严重缺陷 软件项目不很重要 缺陷不严重且不重要 问题跟踪 执行 跟踪 不跟踪 存在有待解决的问题 不存在有待解决的问题 被评审的工作产品规模较大 被评审的工作产品规模较大 最新精品资料整理推荐，更新于二〇二一年一月二十七日2021年1月27日星期三20:47:59
……………………………………………………………最新资料推荐…………………………………………………
4、附录
表1 同行评审计划
同行评审计划
（文件编号：MT-PTM09A 版次：V01） 记录编号：MT-PTM09A-
项目名称/标识 工作产品名称/标识 工作产品的规模 计划编制日期 年 月 日 预计评审总工时（小时） 评审申请日期 年 月 日 会 议 会议名称 地点 文 档 文档类型 源头文件 软件工作产品 检查表/标准 评审人员 姓名 角色 主持人（评审组长） 作 者 书记员 标准效率和评估 个别审查效率（页/小时） 会议效率（页/小时） 说明：
源头文件－产生工作产品的工作过程的入口文件；标准效率和评估－组织的标准数据；备注－分工等信息。
评估个别审查（小时） 备注 文档名称 开始时间 结束时间 最新精品资料整理推荐，更新于二〇二一年一月二十七日2021年1月27日星期三20:47:59
……………………………………………………………最新资料推荐…………………………………………………
表2－1 软件工作产品评审指导方针
软件工作产品评审指导方针 软件工作产品 软件需求说明书 评审重点 •软件需求满足客户需求 •软件需求是可实施的 •软件需求是否完整、一致和明确 进入准则 •文档符合规范要求 客户 设计人员 系统测试人员 安装实施人员 用户文档作者 概要设计说明书 •设计覆盖了需求 •设计是可实施的 •设计是否有遗漏和缺陷 •文档符合规范要求 •需求经过评审并已定稿 需求作者 用户文档作者 详细设计人员 开发人员 源代码 •编码前进行了设计 •源代码是否完整和正确 •源代码中的缺陷 系统测试用例 •用例覆盖了需求中的所有条件 •用例是否正确 •用例是否可执行 项目计划 •满足项目管理和控制需求 •计划是否完整和明确 •计划是否可实施 •符合计划书标准模板 项目经理 SEPG成员 与其它项目经理 •已建立需求基线 •系统测试计划符合规范 •源代码已经完成汇编 •源代码符合编程规范 设计人员 测试人员 开发人员 需求作者 测试人员 参与者 最新精品资料整理推荐，更新于二〇二一年一月二十七日2021年1月27日星期三20:47:59
……………………………………………………………最新资料推荐…………………………………………………
表2－2 评审检查表
例1：
软件需求评审检查表 序号 1 评审重点 完整性 问题 •是否完整地定义了软件需求规格？ •是否定义了所要解决问题范围内的处理结构和信息流？ •是否考虑了数据量和处理量？ •是否定义了关键的接口和界面？ •范围内的功能是否都有适当的描述？ •是否考虑了异常处理和例外处理？ •是否考虑过其它可选的软件需求？ •是否定义了用户手册概要？ 2 一致性 •所描述的软件需求与客户需求和系统需求是否一致？ •所规定的处理及其数据是否与必须完成的功能要求一致？ •是否有超出范围的功能？ •是否存在前后不一致的描述？ 3 4 正确性 明确性 •是否正确理解和描述了客户对软件的需求？ •是否存在含混、不清楚和含有二义的描述？ •图表是否清楚？ •某些信息是否被忽略了或有冗余？ 5 可实施性 •是否每一项软件需求都存在实现的可能？ •约束条件是否现实？ •是否考虑了实现需求的技术风险？ •计划的估算是否受到影响？ 6 可验证性 •是否对每一项软件需求都能够进行验证？ •是否详细描述了验证标准？ •验证标准是否合适？ 7 8 9 10 可追溯性 •是否能够在后续过程中对每一项软件需求进行追溯？ • • • 最新精品资料整理推荐，更新于二〇二一年一月二十七日2021年1月27日星期三20:47:59
……………………………………………………………最新资料推荐…………………………………………………
例2：
概要设计评审检查表 序号 1 评审重点 完整性 •是否覆盖了所有软件需求？ •概要设计是否完整？ •是否定义了各子系统或模块之间的接口？ •是否存在设计遗漏和缺陷？ 2 一致性 •与软件需求和系统需求是否一致？ •所设计的处理及其数据是否与必须完成的功能要求一致？ •是否有超出范围的功能？ •是否满足约束条件的限制？ •是否存在前后不一致的描述？ 3 正确性 •是否正确理解和描述了软件需求的要求？ •是否存在设计上的错误？ 4 明确性 •是否存在含混、不清楚和含有二义的描述？ •图表是否清楚？ •某些信息是否被忽略了或有冗余？ 5 可实施性 •是否每一项设计要求都是可实现的？ •是否考虑了设计实现的技术风险？ •计划的估算是否受到影响？ 6 可验证性 •是否对每一项设计要求都能够进行验证？ •是否详细描述了验证标准？ •验证标准是否合适？ 7 可追溯性 •是否能够在后续过程中对每一项软件需求进行追溯？ •是否能够从每一项设计要求追溯到其对应的软件需求？ 8 9 可靠性 安全性 •是否满足客户的要求，以及所达到的程度如何？ •是否考虑了误操作的防范和处理？ •是否考虑了非法操作的防范和处理？ •是否满足客户的要求？ 10 11 12 13 14 可维护性 可移植性 运行效率 方便性 灵活性 •是否便于发现错误，并易于纠正所发现错误？ •是否易于移植和改造？ •是否满足客户要求？ •是否便于用户使用操作？ •是否能够灵活处理不同的业务/操作需求？ 问题 最新精品资料整理推荐，更新于二〇二一年一月二十七日2021年1月27日星期三20:47:59
……………………………………………………………最新资料推荐…………………………………………………
表3 个别审查记录表
个别审查记录表
（文件编号：MT-PTM09B 版次：V01） 记录编号：QR-PTM09B-
项目名称/标识 工作产品名称/标识 评审员姓名 缺陷/问题记录 序 号 说明：
主－主要缺陷，次－次要缺陷；改－改进建议，问－疑问；参照项－对应的检查表项。
文档号 页 位 号 置 主 类型 次 改 问 描述 参照项 解决办法 个别审查工时（小时） 最新精品资料整理推荐，更新于二〇二一年一月二十七日2021年1月27日星期三20:47:59
……………………………………………………………最新资料推荐…………………………………………………
表4 评审会议记录
评审会议记录
（文件编号：MT-PTM09C 版次：V01） 记录编号：QR-PTM09C-
项目名称/标识 工作产品名称/标识 工作产品的规模 会议日期 会议时间 主 持 人 作 者 评 审 员 其他人员 年 月 日 书 记 员 缺陷/问题记录 序 号 文档号 页号 位置 主 类型 次 改 问 描述 参照项 解决办法 评审会议总工时（小时） 确认缺陷的截止日期 年 月 日 会议时数（小时） 有待解决的问题记录 序号 问题描述 说明：
主－主要缺陷，次－次要缺陷；改－改进建议，问－疑问；参照项－对应的检查表项。
负责人 目标日期 解决日期 最新精品资料整理推荐，更新于二〇二一年一月二十七日2021年1月27日星期三20:47:59
……………………………………………………………最新资料推荐…………………………………………………
表5 同行评审总结报告
同行评审总结报告
（文件编号：MT-PTM09D 版次：V01） 记录编号：MT-PTM09D-
项目名称/标识 工作产品名称/标识 工作产品的规模 报告编制日期 年 月 日 评审总工时（小时） 评审申请日期 年 月 日 个别审查数据 审查员 合计 审查工时 审查页数 主要缺陷 会议数据 与会人数 主要缺陷 会议持续时间（小时） 次要缺陷 完成数据 主要缺陷 次要缺陷 变更请求 返工工时 结论 评审意见 （填写说明：评审会议对工作产品的评审意见） 建议 （填写说明：针对下一阶段工作的建议） 总结 （填写说明：对本次同行评审工作的总结） 跟踪•收尾工时 结束日期 年 月 日 会议效率（页/小时） 改进建议 疑问 次要缺陷 改进建议 疑问 审查效率 最新精品资料整理推荐，更新于二〇二一年一月二十七日2021年1月27日星期三20:47:59
……………………………………………………………最新资料推荐…………………………………………………
表6 设计评审报告
设计评审报告
（文件编号：MT-PTM09E 版次：V01）
设计评审报告 （文件编号：QR/04C 版次：V01） 项目名 被评审对象名称 阶段 开发策划 □ 评审内容（空间不够可附页）： 评审结论（空间不够可附页）： 需求分析 □ 系统设计 □ 标 题 记录编号 评审日期 评审性质 QR-PTM09E- 年 月 日 评审□ 复审□ 项目标识号 实现 □ 测试 □ 安装验收 □ 设计更改 □ 评审组长签字： 年 月 日 评审通过后的批准意见： 批准人签字： 年 月 日 注：
如安排复审，则“评审通过后的批准意见”栏在复审通过后填写。
最新精品资料整理推荐，更新于二〇二一年一月二十七日2021年1月27日星期三20:47:59
……………………………………………………………最新资料推荐…………………………………………………
表7 评审人员名单
设计评审人员名单 序号 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 姓名 单位 评审报告 标题 编号 QR/PTM09E- 职称/职务 联系电话 签名 最新精品资料整理推荐，更新于二〇二一年一月二十七日2021年1月27日星期三20:47:59
……………………………………………………………最新资料推荐…………………………………………………
项目估算指南
目 录
1、概述 ..................................................................................................................... 147 1.1 目的 ............................................................................................................. 147 1.2 适用范围 ..................................................................................................... 147 1.3 引用文件 ..................................................................................................... 147 1.4 术语 ............................................................................................................. 147 1.5 参考资料 ..................................................................................................... 147 2、内容 ..................................................................................................................... 147 2.1 WIDEBAND-DELPHI估算法 ......................................................................... 147
最新精品资料整理推荐，更新于二〇二一年一月二十七日2021年1月27日星期三20:47:59
……………………………………………………………最新资料推荐…………………………………………………
1、概述
1.1 目的
为项目进行各项估算提供指南。
1.2 适用范围
适用于软件开发项目。
1.3 引用文件
无。
1.4 术语
无。
1.5 参考资料
《Software Project Management Guidebook》（Version 2.0），Process Strategies，Inc.
2、内容
以下各节对项目所涉及的各项估算方法进行指南性说明，每一节介绍一种估算方法。
2.1 Wideband-Delphi估算法
Wideband-Delphi估算法的指导思想是：“三个臭皮匠赛过诸葛亮”或者说“多个脑袋胜过一个脑袋”。它强调由多人组成的估算组进行估算，以避免由个人进行的估算的局限性和片面性，使估算结果尽可能更接近实际。本估算法是在工作任务拆分后形成的任务表为基础进行的。估算过程如下：
最新精品资料整理推荐，更新于二〇二一年一月二十七日2021年1月27日星期三20:47:59
……………………………………………………………最新资料推荐…………………………………………………
2.1.1 估算策划
估算策划通常由项目经理进行，主要明确以下事项： •确定估算的对象，例如：项目、活动、或产品； •确定估算组成员，并确定估算的主持人。 估算组的成员通常应由以下人员组成：
•主持人，在估算期间负责估算活动的策划和协调； •项目经理；
•两到六个对要估算的对象较熟悉并具有估算能力的其他人员。
上述事项确定后，由估算主持人准备被估算对象的材料（包括任务表和任务的详细说明）以及估算用表。 2.1.2 准备会
在进行正式估算前应召开准备会。在准备会上，主持人应就以下内容向全体估算人员作说明：
•估算对象的情况； •估算目标；
•假设和约束条件，以避免影响估算。
此外，主持人有责任对不熟悉Wideband-Delphi估算的人员解释估算的方法。同时将任务表和估算用表发给全体估算员。 2.1.3 估算实施
估算在满足以下前提下进行： •假设由一个人执行全部任务； •假设所有任务都是顺序执行的； •假设每项任务都不间断地被执行。
为方便说明估算的过程，假设有五位估算员（主持人除外），分别编号为＃1－＃5。估算过程如下：
（1）第一轮估算
在听取对任务情况的简单说明后，各估算员独立地对各项任务进行估算，并将各项任务的估算结果及其总计值填写到估算表上。例如＃2号估算员的估算结果如下表（单位：小时）：
最新精品资料整理推荐，更新于二〇二一年一月二十七日2021年1月27日星期三20:47:59
……………………………………………………………最新资料推荐…………………………………………………
WBS活动 任务1 任务2 任务3 任务4 任务5 修正： 总计： 估算＃1 100 20 35 65 150 － 370 修正＃1 修正＃2 修正＃3 最终结果 假设 其他四位估算员也分别将各自的估算结果填写到估算表上。主持人收集各位估算员的估算表，整理汇总，登录到汇总表上，如下表所示：
5 4 3 2 1
0 200 400 600 800 1000
表中的第一行上的粗竖线分别表示五位估算员第一轮的估算结果。显然是很分散的。主持人组织估算员们进行讨论，讨论时应掌握以下原则：
•主持人不得公开估算员的姓名，以防止估算员们的估算思路互相影响，影响估算员的独立判断能力；
•主持人必须保持公正，不能起裁决的作用； •讨论时可以集中在估算差距较大的几个任务上进行； •讨论时间应控制在15－20分钟。 （2）其余各轮的估算
估算员们在讨论的基础上，分别对各项任务进行新的估算，并将每项任务的估算差值及估算总计值登录到估算表中；主持人收集各位估算员的估算表，整理汇总，登录到汇总表上，依次重复。汇总表的纵坐标值表示估算的轮次，每个估算轮次所对应的水平线上用粗竖线表示出每位估算员的估算总计值。
当满足以下条件之一时，估算终止： •已进行了四轮估算；
•估算值的范围已集中到预先定义的可接受的精度范围内；
最新精品资料整理推荐，更新于二〇二一年一月二十七日2021年1月27日星期三20:47:59
……………………………………………………………最新资料推荐…………………………………………………
•估算进行的时间已到预定时间（一般为2小时）； •估算员已不想再进行进一步的估算。
下面是估算结束后＃2号估算员的估算表和主持人的汇总表的情况：
＃2估算员的各次修正及最终结果（单位：小时）
WBS活动 任务1 任务2 任务3 任务4 任务5 修正： 总计： 估算＃1 100 20 35 65 150 － 370 修正＃1 -10 +15 -10 -30 -35 335 修正＃2 -5 +5 +15 +5 +20 355 修正＃3 最终结果 85 40 50 60 120 － 355 假设 5 4 3 2 1
0 200 400 600 800 1000
（3）结果统计
对每位估算员的最终估算结果进行统计，如下表所示：
WBS活动 假设 ＃1 任务1 任务2 任务3 任务4 任务5 总计： 90 70 85 105 150 500 ＃2 85 40 50 60 120 355 估 算 者 ＃3 70 75 75 85 135 440 ＃4 80 60 70 80 110 400 ＃5 115 75 95 150 165 600 估算 然后对上述数据进行整合，得出本次估算的最终结果。整合的方法可以考虑以下几种：
•取平均值
最新精品资料整理推荐，更新于二〇二一年一月二十七日2021年1月27日星期三20:47:59
……………………………………………………………最新资料推荐…………………………………………………
•取中 •给出范围
•给出平均值、最好和最差情况
例如，采用平均值的结果如下（单位：人时） 任务1：88 任务2：64 任务3：75 任务4：96 任务5：136 项目总工时：459
最新精品资料整理推荐，更新于二〇二一年一月二十七日2021年1月27日星期三20:47:59
……………………………………………………………最新资料推荐…………………………………………………
标准软件过程总体裁剪指南
目 录
1、概述 ..................................................................................................................... 153 1.1 目的 ............................................................................................................. 153 1.2 适用范围 ..................................................................................................... 153 1.3 引用文件 ..................................................................................................... 153 1.4 术语 ............................................................................................................. 153 1.5 参考资料 ..................................................................................................... 153 2、内容 ..................................................................................................................... 153 标准软件过程总体裁剪指南.............................................................................. 154
最新精品资料整理推荐，更新于二〇二一年一月二十七日2021年1月27日星期三20:47:59
……………………………………………………………最新资料推荐…………………………………………………
1、概述
1.1 目的
为软件项目对公司标准软件过程进行详细裁剪时，提供框架和总体指导方针。
1.2 适用范围
适用于本公司范围内的软件项目。
1.3 引用文件
《标准软件过程的开发和维护》（QMS-PSM01-V 1.0）
1.4 术语
无。
1.5 参考资料
•《Process Tailoring and the Software Capability Maturity Model》，Mark P. Ginsberg and Lauren H. Quinn
•《实践中的CMM－INFOSYS公司实施软件项目之过程》，潘卡•杰罗特著，杨慧鸣、李光龙译，2001年7月
2、内容
本指南根据《标准软件过程的开发和维护》关于总体裁剪指南的编写要求，以及本公司项目的实际情况编写而成。
具体的指南内容如下表。
最新精品资料整理推荐，更新于二〇二一年一月二十七日2021年1月27日星期三20:47:59
……………………………………………………………最新资料推荐…………………………………………………
标准软件过程总体裁剪指南
总体裁剪指导方针 项目规模：小；技能水平：低 与评审有关的指导方针 1、只对所有影响较大的文档（如项目尽早发现问题，避免返工。 计划、概要设计等）进行正式评审 2、对每个开发人员最初提供的工作产考虑到技能水平低，进行最初的指导品（文档和代码）进行同行评审 与工作量有关的指导方针 1、将任务划分得更多个独立的小任务 降低任务难度。 2、在考虑日程时应考虑开发人员学习考虑到技能水平低，需要学习。 掌握技术的过程 3、制订培训计划并进行培训 考虑到技能水平低，进行培训的必要性。 4、当编程工作量较大时，为开发人员为了确保质量。 提供编写良好、经过测试的编程框架 与正式性有关的指导方针 1、可以适当减少开发基线中需要配置考虑到项目规模较小，过程可能较简的配置项 单。 项目规模：小；技术水平：高 与评审有关的指导方针 1、只对所有影响较大的文档（如项目尽早发现问题，避免返工。 计划、概要设计等）进行正式评审 2、可以减少同行评审次数，有些评审因为项目规模较小，团队技能水平较改为检查 与工作量有关的指导方针 1、只有当编程工作量较大、编程框架因为团队技能水平较高，编程框架的利用率较高的情况下才提供编程框架 利用率有限。 高。 把关是必要的。 原因 最新精品资料整理推荐，更新于二〇二一年一月二十七日2021年1月27日星期三20:47:59
……………………………………………………………最新资料推荐…………………………………………………
与正式性有关的指导方针 1、可以适当减少开发基线中需要配置考虑到项目规模较小，过程可能较简的配置项 单。 2、当项目的重要程度较低时，变更管因为项目规模较小，团队技能水平较理可以不那么正式。 高，但重要程度较高时仍需加强变更管理。 项目规模：中等以上；技能水平：低 与评审有关的指导方针 1、只对所有影响较大的文档（如项目尽早发现问题，避免返工 计划、概要设计等）进行正式评审 2、对每个开发人员最初提供的工作产考虑到技能水平低，进行最初的指导品（文档和代码）进行同行评审 把关是必要的。 3、由项目以外的技术人员对技术文档考虑到项目中缺少技术水平高的评审进行评审 人员。
与工作量有关的指导方针 1、将任务划分得更多个独立的小任务 降低任务难度。 2、在考虑日程时应考虑开发人员学习考虑到技能水平低，需要学习。 掌握技术的过程 3、制订培训计划并进行培训 降低到技能水平低，进行培训的必要性。 4、当编程工作量较大时，为开发人员为了确保质量。 提供编写良好、经过测试的编程框架 5、为同类活动开发软件工具 与正式性有关的指导方针 1、严格按配置管理程序的要求进行配考虑到团队规模较大，必须加强醘管置管理 理，以免发生混乱。 减少工作量（规模较大时可能做到） 2、按正式的变更管理的要求进行变更 管理 最新精品资料整理推荐，更新于二〇二一年一月二十七日2021年1月27日星期三20:47:59
……………………………………………………………最新资料推荐…………………………………………………
项目规模：中等以上；技能水平：高 与评审有关的指导方针 1、只对所有影响较大的文档（如项目尽早发现问题，避免返工。 计划、概要设计等）进行正式评审 2、如果项目的重要程度降低，可以适因为团队的技能水平较高，因此如项当减少同行评审的次数 目的重要程度不是很高，可以适当减少同行评审的次数。 与工作量有关的指导方针 1、只有当编程工作量大、编程框架得因为团队技能水平较高，编程框架的用率较高的情况下才提供编程框架 2、为同类活动开发软件工具 利用率有限。 减少工作量（团队规模较大时可能做到） 与正式性有关的指导方针 1、严格按配置管理程序的要求进行配考虑到团队规模较大，必须加强配置置管理 管理，以免发生混乱。 2、按正式的变更管理的要求进行变更 管理
最新精品资料整理推荐，更新于二〇二一年一月二十七日2021年1月27日星期三20:47:59
因篇幅问题不能全部显示，请点此查看更多更全内容