ch9软件工程管理.pptx

第9章软件工程管理l软件工程管理概述l软件规模估算l进度计划l人员组织l软件配置管理l软件质量保证l软件工程标准与软件文档软件工程管理概述l1. 软件产品的特点软件是逻辑产品，具有高度的抽象性同一功能的软件可以有多样性软件生产过程复杂，具有易错性软件开发与维护主要是根据用户需求“定制”的，其过程具有复杂性和易变性软件的开发和运行经常受到计算机系统环境的限制，因而软件有安全性和可移植性等问题软件生产有许多新技术需要软件工程师进一步研究和实践l2.软件工程管理的重要性分阶段管理策略涉及多学科软件规模不断增大，管理难度增加，管理不善的后果严重l3.软件工程管理的内容 包括对软件开发成本、控制、开发人员、组织机构、用户、软件开发文档、软件质量等方面的管理。软件规模和开发工作量估算面向规模的度量（代码行技术）面向功能的度量（功能点技术）CoCoMo模型软件项目估算l估算涉及到人、技术、环境、政策等多种因素，很难精确地估算出项目的开销。l常用四种估算方法参照已有类似项目估计待开发项目成本和工作量将大的项目分解成若干子项目，分别估算出子项目成本和工作量，再估算整个项目按软件的生命期分别估算各阶段的工作量和成本，再汇总，从而估算出整个项目根据实验或历史数据给出软件项目工作量或成本的经验公式软件项目代码行和功能点估算是成本和工作量估算的基础。（规模）LOC或FP的期望值：e=（a+4m+b)/6l代码行技术用软件项目的代码行（LOC）数表示软件项目的规模生产率P=L/E，E是软件项目的工作量，用人月（PM）度量，L用千行代码kLOC度量每行代码的平均成本C=S/L，S是软件项目总的开销文档与代码比D=Pd/L，Pd是软件项目的文档页数代码出错率EQR=Ne/L，Ne是软件项目的代码错误数l例：下表提供了一个国外典型的软件项目记录l利用这些数据，可以求出：lP=12.1kLOC/24PM=504LOC/PMlC=168000美元/12.1kLOC=13.88美元/LOClD=365Pd/12.1kLOC=30.16Pd/kLOClEQR=29个/12.1kLOC=2.4个/kLOCl用代码行数估计软件规模简单易行l缺点：代码行数的估算依赖于程序设计语言的功能和表达能力；采用代码行估算方法会对设计精巧的软件项目产生不利影响；在软件项目开发前或开发初期估算它的代码行数十分困难；代码行估算只适用于过程式程序设计语言，对非过程式的程序设计语言不太适用等l功能点技术依据对软件信息域特性和软件复杂性的评估结果，估算软件规模5个信息域特性为：用户输入数：各个用户输入是面向不同应用的输入数据（参数，不含查询数）个数。用户输出数：各个用户输出是面向应用的输出信息个数，包括报告，屏幕信息，错误信息等。用户查询数：查询是一种联机的交互操作，统计查询/响应的总计数。 文件数：每一个逻辑主文件都应计数。逻辑主文件是指逻辑上的一组数据，可以是一个大数据库的一部分，可以是一个单独的文件。外部接口数：与系统中其他设备通过外部接口读写信息次数均应计数。功能点 FP (Function Point)。 FP UFP( 0.65 0.01SUM ( Fi ) ) 估算功能点的步骤1.计算未调整的功能点数UFP UFP=a1Inp+a2Out+ a3Inq+a4Maf+a5Inf 其中，ai（1i5）是信息域特性系数，值由相应特性的复杂级别决定。l2.计算技术复杂因子TCF14种技术因素：技术因素、数据通信、分布式数据处理、性能标准、高负荷的硬件、高处理率、联机数据输入、终端用户效率、联机更新、复杂的计算、可重用性、安装方便、操作方便、可移植性、可维护性。 l计算技术因子对软件规模的综合影响程度DI：l技术复杂性因子TCP由下式计算： TCP = 0.65 + 0.01 DI l计算功能点数FP FP = UFP TCP 代码行度量与功能点度量的比较代码行度量（依赖开发语言）与功能点度量（不依赖开发语言）的比较 LOC/FP（平均）：汇编语言=300FORTRAN=100pascal=90Ada=70面向对象语言=30 四代语言4GL=20 代码生成器=15一行Ada语言代码的“功能”平均是一行FORTRAN语言代码“功能”的1.4倍，一行四代语言代码的“功能”平均是一行传统程序设计语言代码“功能”的35倍CoCoMo 模型l1981年Boehm提出“构造性成本模型”（Constructive Cost Model）l该成本估算模型是一种精确、易于使用的成本估算方法lCOCOMO模型的分类（按其详细程度，分三级）基本模型、 中间模型、 详细模型基本模型是静态单变量模型，用源代码行数(LOC) 为自变量的经验函数计算软件开发工作量。中间模型在用LOC为自变量的函数计算软件开发工作量（称为名义工作量）的基础上，用涉及产品、硬件、人员、项目等方面的影响因素调整工作量估算。详细COCOMO模型包括中间模型的所有特性，但用上述各种影响因素调整工作量估算时，还要考虑对软件工程过程中每一步骤（分析、设计等）的影响。基本的CoCoMo模型l公式l其中： E 表示工作量（人月PM） D 表示开发时间（月） L 是项目的代码行估计值（千行代码）bLaE)(dcED 基本的CoCoMo模型参数la,b,c,d 常数取值软件类型abcd适用范围组织型2.41.052.50.38各类应用程序半独立型3.01.122.50.35各类实用程序、编译程序等嵌入型3.61.202.50.32实时处理、控制程序、操作系统中间的CoCoMo模型以基本的CoCoMo模型为基础，工作量估计公式中乘以调节因子EAF E 表示工作量（人月PM） L 是项目的代码行估进一步考虑15种影响软件工作量的因素EAFLaEb)(iiFEAF151软件类型ab组织型3.21.05半独立型3.01.12嵌入型2.81.20l产品因素： 软件可靠性、数据库规模、产品复杂性；l硬件因素： 执行时间限制、存储限制、虚拟机易变性、环境周转时间；l人的因素： 分析员能力、应用领域实际经验、程序员能力、虚拟机使用经验、程序语言使用经验；l项目因素： 现代程序设计技术、软件工具的使用、开发进度限制。例 一个规模为10KLOC的商用微机远程通信的嵌入型软件，使用中间COCOMO模型进行成本估算。名义工作量E1 2.8 (10)1.20 44.38实际工作量E 44.381.17 51.9中间CoCoMo模型与各种开发方案对工作量的影响l建议参加项目的人数N 为人数，D 为开发时间（月）, E 为工作量（人月）l一般来说，由N个程序员组成的小组，实现相同的规模的程序，相互通信数 , 设每次通信和交换意见的平均的工作量 ，则增加的通信开销为DEN/2/ ) 1(2NNCN2/ ) 1(NNEcl一般情况下，由N 个程序员组成的小组共同开发一个程序的工作量 ，满足：l程序员小组的生产率：l单个程序员与程序员小组生产率的比为l事实：盲目增加程序员人数会推迟软件完成的日期 rEcrEEE)/(cGEELOCP)/(cpEEERCoCoMo2模型1997年Boehm对CoCoMo模型进行了扩充，称为CoCoMo2. COCOMO2模型分成三个层次l应用系统组成模型：用于估算构建原型的工作量，这种模型考虑到大量使用已有构件的情况l早期设计模型：用于软件结构设计阶段l后期设计模型：用于软件开发阶段 COCOMO2模型把软件开发工作量表示成代码行（KLOC）的非线性函数：其中，是模型系数，典型值为3.0，b是模型指数，fi是成本因素。COCOMO2模型使用了5个分级因素Wi（1i5），分别是：项目先例性、开发灵活性、风险排除度、项目组凝聚力和过程成熟度。 其中每个成本因素划分为6个级别，每个级别的分级因素Wi取值如下：甚低Wi=5，低 Wi=4, 正常Wi=3，高Wi=2，甚高Wi=1，特高Wi=0。b的值：171*biEkLOCfi进度计划l可以把用于一般开发项目的进度安排的技术和工具应用于软件项目。l为监控软件项目的进度计划和工作的实际进展情况，为表现各项任务之间进度的相互依赖关系，需要采用图示的方法。l在图示方法中，必须明确标明：l 各个任务的计划开始时间，完成时间；l 各个任务完成标志（即文档编写和评审）；l 各个任务与参与工作的人数，各个任务与工作量之间的衔接情况；l 完成各个任务所需的物理资源和数据资源甘特图Gantt Chartl在甘特图中，每一任务完成的标准，不是以能否继续下一阶段任务为标准，而是以必须交付应交付的文档与通过评审为标准。因此在甘特图中，文档编制与评审是软件开发进度的里程碑。工程网络技术l工程网络技术PERT技术 (Program Evaluation and Review Technique)叫做程序评估与审查技术，CPM方法叫做关键路径法，它们都是安排开发进度，制定软件开发计划的最常用的方法。l它们都采用网络图来描述一个项目的任务网络，也就是从一个项目的开始到结束，把应当完成的任务用图或表的形式表示出来。1. 计算最早时刻2. 计算最迟时刻3. 关键路径4. 机动时间 上述示例工程中各项任务的进度安排，可用Gantt图画出：（先安排关键路径上的任务） 路径优化人员组织1. 开发人员2. 组织机构l三种组织结构模式按课题划分的模式（Project Format）按职能划分的模式（Functional Format）矩阵形模式（Matrix Format）l程序设计小组的组织形式有3种： 主程序员组、民主制程序员组及层次式小组3. 用户用户的阻力和干扰：不积极配合、求全求快、功能的变化 软件配置管理l软件配置（Software Configuration）是软件产品在软件开发或运行过程中产生的全部信息。l软件配置管理（Software Configuration Management）简称SCM，是在软件的整个生存周期内管理变更的一组活动。l软件配置管理(Software Configuration Management，简称SCM)的四项任务:l()标识变更l()控制变更l()配置审计l()配置状态报告 l软件开发过程的最终结果包括三类信息：计算机程序（源程序和目标程序）；描述程序的文档（面向技术人员和面向用户）；数据结构（包括程序内部和外部定义两部分）。l组成上述信息的所有项目构成一个软件配置，其中每一项称为一个软件配置项（Software Configuration Item，简称SCI），它是配置管理的基本单位。一个SC中最早的SCI是系统规格说明书。lSCM要解决的主要问题就是保证软件的质量。 l基线（baseline）的原意是棒球场的边线，在软件开发过程中，为了有效地控制变动，软件配置管理引入基线的概念。lIEEE组织对于基线的定义“已经通过正式复审和批准的某规约或产品，它因此可以作为进一步开发的基础，并且只能遵循正式的变化控制过程得到改变”。l根据这个定义，基线标志软件开发过程的各个里程碑，任一SCI，一旦形成文档并复审通过，即成为一个基线，它标志开发过程中一个阶段的结束。对于已成为基线的SCI，虽然可以修改，但必须按照一个特殊的、正式的过程进行评估，确认每一处修改。相反，对于未成为基线的SCI，可以进行非正式修改。 l某个SCI一旦成为基线，随即被放入项目数据库（project database）。此后，若开发小组中某位成员希望改动SCI，首先要将它拷贝到私有工作区并在项目数据库中锁住，不允许他人使用。在私有工作区中完成修改控制过程并复审通过之后，再把修改后的SCI推出并回送到项目数据库，同时解锁。 l一般软件配置需包括下列SCI：l1系统规格说明书l2软件项目规划l3需求分析结果l 1）软件需求规格说明书l 2）可执行的或“纸样”原型l4初步用户手册 l5设计规格说明书l 1）数据设计描述l 2）总体结构设计描述l 3）模块设计描述l 4）界面设计描述l 5）对象描述（若采用面向对象技术） l6 6源代码清单l7测试规格说明书l 1）测试计划和过程l 2）测试用例和实验结果 l8操作和安装手册l9可执行程序l 1）每个模块的可执行代码l 2）连接到一起的代码l10数据库描述l 1）数据模型和文件结构l 2）初始化映象l11联机用户手册l12维护文档l 1）软件问题报告单l 2）维护申请单l 3）预计变动的顺序l13软件工程的标准和过程 l软件配置管理主要任务是控制软件的修改，主要包括：标识软件配置中各种对象；管理软件的各种版本；控制对软件的修改； 审计配置；报告配置情况。 l所有SCI都应按面向对象的方式命名并组织起来。对象命名是为了能够根据名称提取对象；而通过组织对象并描述其间的关系则着眼于在对象变更时能够清楚地了解变更的影响范围。l基本对象在分析、设计、编码或测试阶段由开发人员创建的某个“文本单元”（unit of text）。例如，需求说明书中某一节，某个模块的源代码，或按等价分类法制定的一套测试用例l复合对象由若干基本对象和复合对象组合而成的对象，是一个递归的概念。例如，“设计规格说明书”是复合对象，它由“数据模块”和“模块N”等基本对象组合而成。 l每个配置对象都拥有名字、描述、资源列表和实际存在体四个部分：1. 对象名一般为无二义字符串；2. 对象描述包括若干数据项，它们指明对象的类型（例如，文档、程序还是数据）、所属工程项目的标志及变动和版本的有关信息；3. 资源列表给出该对象要求、引用、处理和提供的所有实体，如数据类型、特殊函数等，有时变量也被看作资源；4. 只有基本对象才有实际存在体，它是指向该对象“单元正文描述”的一个指针；对于复合对象，此项取null值。 l除了标识配置对象外，还必须指明对象之间的关系，一个对象可标识为另一个复合对象的一部分，即此两对象之间存在一个关系。若干关系可定义出对象之间的分层结构。例如：l“E R图”“数据模型”l“数据模型”“设计规格说明书”l因一个配置对象可能与其他多个对象有关系，所以SCI的分层结构不一定是简单的树状结构，而是更一般的网状结构。 l为了适应不同环境特点和满足不同用户的个性需求，往往一个项目保存多个版本。l配置管理的版本控制主要解决下列问题： 1）根据不同用户的需要配置不同的系统； 2）保存系统老版本，为以后调查问题使用； 3）建立一个系统新版本，使它包含某些决策而抛弃另一些； 4）支持两位以上工程师同时在一个项目中工作； 5）高效存储项目的多个版本。 l版本控制系统都为配置对象的每个版本设置一组属性，这组属性既可以是简单的版本号，也可以是一串复杂的布尔变量（即开关值），用以说明该版本功能上的变化。l进化图可用于描述一个软件系统的不同版本。l图中每个结点都是软件的一个完整版本，它由所有协调一致的软件配置项组成（源代码，文档和数据）。此外，一个版本还允许有多种变形（Variant）。例如，一个程序的某个版本由A、B、C、D、E五个部件组成，部件D仅在系统配有彩色显示器时使用，部件E则适用于单显，那么该版本就有两种变形，一种由A、B、C、D四个部件组成，另一种由A、B、C、E四个部件组成。 l在大型软件开发过程中，无控制地修改会迅速导致混乱。所谓修改控制，即把人的努力与自动工具结合起来，建立一套机制，有意识地控制软件修改。 l当一个“修改申请”提出后，开发者依据技术指标和潜在的副作用，对其他配置对象和系统功能可能造成的影响以及项目成本等诸多因素进行评估。评估的结果将形成一个“修改报告单”，提交给修改控制机构(CCA)决策。lCCA一旦同意修改，应立即提供一个“工程变动命令”ECO（Engineering Change Order）。它指明修改任务、需遵守的限制和复审标准。然后从项目数据库中“提出”待修改对象，经修改后再“推出”更新版本。l这一对动作是项目数据库访问控制和同步控制要求的。访问控制决定哪些人员有权访问或修改某个配置对象；而同步控制则保证并行修改时不因互相重写而造成丢失修改。 l软件开发人员根据ECO从项目数据库中提出待修改对象，访问控制机构，核实该开发人员是否有此特权，而同步控制机构则及时锁住待修改对象，不允许其他开发人员再做修改，直至该对象的新版本推出。加锁期间，其他工程人员仍可提取该对象的副本（称为提取版本）使用。l上图所示的修改控制用于已交给用户的软件产品，称为正式修改控制。若欲修改的SCI虽已为基线版本，但尚未交付用户，此时修改控制称为工程级的修改控制，它除了不涉及用户外，其他步骤与正式的修改控制大致相同。若SCI并未成为基线版本，只需进行非正式的修改控制，则在不影响系统需求的前提下，该SCI的开发者可随意改动 变更控制过程来自用户的CR工作量评估递交CR表格CCA审查评估CR被否决同意CR，给人员分配任务SCM检出配置项更 改审计并检入更改内容建立基线测试，执行QA和测试活动提交改变到下一个Release通知用户构造适当的版本并审计所有配置项新版本中引入变化，并发布该版本 l对于变更工作，必须通过正式的技术复审和软件配置审计工作来验证被核准进行变更的对象是否进行了必要的、正确的变更，并得到了重新的配置。l正式的技术复审着重考虑所修改对象在技术上的正确性，复审人员应对该对象是否与其他SCI协调以及在修改中可能产生的疏忽和副作用进行全面的评估。l软件配置审计作为正式复审的一种补充措施，主要考虑下列在正式技术复审中未被考虑的因素：工程变动命令中指定的修改是否都已完成？有无进行未经指定的其他附加变更？是否做过正式技术复审？是否严格遵守软件工程标准？是否对修改过的SCI进行了强调说明？修改的日期和执行修改的人员是否已经注明？该SCI的属性是否能够反映本次修改的结果？是否遵循了标注变更、记录变更和报告变更的SCM工作规程？所有相关的SCI是否已一并修改？ 配置状况报告配置状况报告 l建立并发布配置状况报告（Configuration Status Reporting，简称CSR）是软件配置管理的一项任务.lCSR主要概述下列问题：发生了什么事情；谁做的；何时发生的；有什么影响。lCSR的时机与上图所述过程紧密相关: 当某个SCI被赋予新标记或更新标记时;或修改控制机构CCA批准一项修改申请（产生一个工程变动命令ECO）时;或配置审计完成时。lCSR的输出可放在联机数据库中，供开发人员和维护人员随时按关键字查询 软件质量保证l计算机软件质量是软件的一些内部特性及其组合，质量不是在软件产品中被测试出来的，而是在软件开发和生产过程中形成的。l软件质量（Software quality）的定义为：l（1）软件产品中能满足给定需要的性质和特性的总体。l（2）软件具有所期望的各种属性的组合程度。l（3）顾客和用户觉得软件满足其综合期望的程度。l（4）确定软件在使用中将满足顾客预期要求的程度。l为保证软件充分满足用户要求而进行的有计划、有组织的活动称为软件质量保证，其目的是生产高质量的软件。软件质量的特性l软件质量是指软件满足明确规定或隐含定义的需求的程度。l软件质量的要点：l软件功能必须满足用户规定的需求；l软件应遵守规定标准所定义的一系列开发准则；l软件应满足某些隐含的需求。如，可理解性、可维护性等。软件质量的特性:功能性：功能性：软件的功能达到它的设计规范和能满足用户需求的程度可靠性：可靠性：在规定的时间和规定的条件下，软件能够实现所要求的功能的能力以及不引起系统失效的概率易使用性：易使用性：用户学习、操作、准备输入和理解输出的难易程度效率：效率：软件实现某种功能所需计算机资源的多少及执行其功能时使用资源的持续时间的多少可维护性：可维护性：进行必要修改的难易程度可移植性：可移植性：软件从一个计算机环境转移到另一个计算机环境下的运行能力软件质量保证措施软件质量保证措施l软件质量保证是软件工程管理的重要内容。包括以下措施：l应用好的技术方法l测试软件l进行正式的技术评审l标准的实施l控制变更l程序正确性证明l记录、保存和报告软件过程信息软件工程标准与软件文档软件工程标准l软件工程标准化的定义 对软件生存期内的所有开发、维护和管理工作逐步建立起标准软件工程标准化的意义l提高软件的可靠性、可维护性和可移植性；l提高软件的生产率和软件人员的技术水平；l提高软件人员之间的通信效率，减少差错和误解；l有利于软件管理；l有利于降低软件产品的成本和运行维护成本；l有利于缩短软件开发周期。l软件工程标准化的类型 参照其它工程领域对工程标准划分的方法，软件工程标准主要有两种：按标准的类型划分和按标准的范围划分。(1) 按标准的类型划分 主要有过程标准、产品标准、行业标准、记法标准等。 过程标准与开发一个产品或从事一项服务的一系列活动或操作有关。过程标准使用一组方法、工具和技术，给出“谁来做”、“做什么”、“如何做”、“何时做”、“何地做”及在软件工程活动中进行的不同层次工作的过程模型。 产品标准则涉及软件工程事务的格式和内容。软件开发和维护活动文档化的结果就是软件产品，软件文档是软件工程活动进一步开展的基础。 软件开发作为一种行业，其行业标准涉及软件工程的所有方面，如执业认证、职业培训、产品许可等。行业标准可以等同于行业行为规范。 记法标准规定了在软件工程行业范围内，以唯一的方式进行交流的方法，如术语、表示法、语言等。(2) 按标准的范围划分 主要是根据软件的任务功能和软件生存期进行比较、判定、评价和确定软件工程标准的范围和内容。任务功能可以表示软件工程过程，可以划分为产品工程功能、验证与确认功能以及技术管理功能3个部分。 产品工程功能包括定义、生产和支持最终产品所必须的过程。验证和确认功能是检查产品质量的活动。技术管理功能是构造和控制产品工程的过程。 这3个部分并不集中在单个的软件生存周期里，而是并行进行的生产、检查和控制活动。 根据以上两种分类方法，软件工程标准可用一张二维表格来表示。根据以上两种分类方法，软件工程标准可用一张二维表格来表示。 标准范围标准范围标准类型标准类型软软 件件 生生 存存 期期概念概念需求需求设计设计实现实现测试测试制造制造安装安装与检与检验验运行运行/ /维护维护引退引退过过程程方法方法技术技术度量度量产产品品需求需求GB/T 9385-1988设计设计部件部件描述描述计划计划报告报告行行业业职业职业道德准则道德准则认证认证特许特许课程课程记记法法术语术语表示法表示法GB/T 1526-1989语言语言 标准范围标准范围标准类型标准类型过程管理过程管理产品管理产品管理资源管理资源管理评审与审计评审与审计产品分析产品分析测试测试过过程程方法方法GB/T 8566-1995技术技术度量度量产产品品需求需求设计设计部件部件描述描述计划计划报告报告行行业业职业职业道德准则道德准则认证认证特许特许课程课程记记法法术语术语表示法表示法语言语言 上述两表给出了二维表的大致格式。其中，给出了上述两表给出了二维表的大致格式。其中，给出了GB/T 9385-GB/T 9385-19881988、GB/T 1526-1989GB/T 1526-1989、GB/T 8566-1995GB/T 8566-1995这这3 3个标准的例子，用于说个标准的例子，用于说明各个标准的类型及其作用。明各个标准的类型及其作用。 1. 1. GB/T 9385-1988GB/T 9385-1988是原电子工业部批准的是原电子工业部批准的计算机软件需求说计算机软件需求说明编制指南明编制指南，用于指导软件需求规格说明书的编写。，用于指导软件需求规格说明书的编写。 2. 2. GB/T 1526-1989GB/T 1526-1989是国家标准总局批准的信息处理是国家标准总局批准的信息处理数据流数据流图、程序流程图、系统结构图、程序网络图、系统资源图的文件编制图、程序流程图、系统结构图、程序网络图、系统资源图的文件编制符号及约定。符号及约定。 3. 3. GB/T 8566-1995GB/T 8566-1995是国家标准总局批准的信息技术是国家标准总局批准的信息技术软件生软件生存期过程标准，它规定了在获取、供应、开发、操作、维护软件和固存期过程标准，它规定了在获取、供应、开发、操作、维护软件和固件的软件部分时，要实施的过程、活动和任务。目的是为用户提供一件的软件部分时，要实施的过程、活动和任务。目的是为用户提供一个公共的框架，使软件从业人员可以使用个公共的框架，使软件从业人员可以使用“相同的语言相同的语言”创作和管理创作和管理软件。软件。软件工程标准编制的层次软件工程标准编制的层次 根据软件工程标准制定的机构和标准适用的范围，可分为根据软件工程标准制定的机构和标准适用的范围，可分为5 5个层次：国个层次：国际标准、国家标准、行业标准、企业际标准、国家标准、行业标准、企业( (机构机构) )标准、项目标准、项目( (课题课题) )标准。标准。1. 1. 国际标准国际标准：由国际联合机构制定和公布的标准，供各国参考。：由国际联合机构制定和公布的标准，供各国参考。 如如ISOISO国际标准化组织。国际标准化组织。2. 2. 国家标准国家标准：由政府或国家级的机构制定或批准，适用于全国范围。：由政府或国家级的机构制定或批准，适用于全国范围。 如如GBGB中国国标、中国国标、ANSI_ANSI_美国国家标准协会、美国国家标准协会、BSBS英国国家标准、英国国家标准、JISJIS日本工业标准。日本工业标准。3. 3. 行业标准行业标准：由行业机构、学术团体或国防等机构制定，适用于某个业务：由行业机构、学术团体或国防等机构制定，适用于某个业务领域。领域。 如如IEEEIEEE美国电气和电子工程师学会、美国电气和电子工程师学会、GJBGJB中国国家军用标准。中国国家军用标准。4. 4. 企业规范企业规范：企业因软件工程工作的需要制定的适用于本企业的规范。：企业因软件工程工作的需要制定的适用于本企业的规范。 如如IBMIBM通用产品部于通用产品部于19841984年制定的年制定的程序设计开发指南程序设计开发指南。5. 5. 项目规范项目规范：由某一科研生产项目组织制定，仅为该项目任务服务的软件：由某一科研生产项目组织制定，仅为该项目任务服务的软件工程规范。工程规范。 如如CIMSCIMS计算机集成制造系统计算机集成制造系统软件工程规范。软件工程规范。中国的软件标准中国的软件标准 19831983年起，我国陆续制定和发布了年起，我国陆续制定和发布了2020余项软件工程国家标余项软件工程国家标准。这些标准可以分为以下四类：准。这些标准可以分为以下四类：1. 1. 基础标准基础标准：规定了信息加工处理和软件工程领域的术语、符：规定了信息加工处理和软件工程领域的术语、符号、表示、构造、分类级约定；号、表示、构造、分类级约定；2. 2. 开发标准开发标准：规定了软件生存期过程、软件支持环境、软件记：规定了软件生存期过程、软件支持环境、软件记录处理流程、软件维护等的工作规范；录处理流程、软件维护等的工作规范；3. 3. 文档标准文档标准：规定了软件产品、需求、测试、管理等文档的编：规定了软件产品、需求、测试、管理等文档的编制规范；制规范；4. 4. 管理标准管理标准：规定了软件配置管理计划、质量保证计划、产品：规定了软件配置管理计划、质量保证计划、产品质量特性、软件可靠性和可维护性管理等的规范和工作要素。质量特性、软件可靠性和可维护性管理等的规范和工作要素。 下表列出了我国部分软件工程标准的名称及其标准号：下表列出了我国部分软件工程标准的名称及其标准号：类型类型标准名称标准名称标准号标准号基基础础标标准准软件工程术语软件工程术语GB/T 11457-1989GB/T 11457-1989信息处理信息处理数据流程、程序流程图、系统结构图、数据流程、程序流程图、系统结构图、程序网络图、系统资源图的文件编制符号及约定程序网络图、系统资源图的文件编制符号及约定GB/T 1526-1989GB/T 1526-1989软件工程标准分类法软件工程标准分类法GB/T 15538-1995GB/T 15538-1995信息处理信息处理程序构造及其表示法的约定程序构造及其表示法的约定GB/T 13502-1992GB/T 13502-1992信息处理信息处理单命中判定表规范单命中判定表规范GB/T 15535-1995(ISO 5806)GB/T 15535-1995(ISO 5806)信息处理系统信息处理系统计算机系统配置图符号及其约定计算机系统配置图符号及其约定GB/T 14085-1993(ISO 8790)GB/T 14085-1993(ISO 8790)开开发发标标准准信息技术信息技术软件生存期过程软件生存期过程GB/T 8566-1995GB/T 8566-1995软件支持环境软件支持环境GB/T 15853-1995GB/T 15853-1995信息处理信息处理按记录组处理顺序文卷的程序流程按记录组处理顺序文卷的程序流程GB/T 15697-1995(ISO 6593)GB/T 15697-1995(ISO 6593)软件维护指南软件维护指南GB/T 14079-1993GB/T 14079-1993文文档档标标准准计算机软件产品开发文档编制指南计算机软件产品开发文档编制指南GB/T 8567-1988GB/T 8567-1988计算机软件需求说明编制指南计算机软件需求说明编制指南GB/T 9385-1988GB/T 9385-1988计算机软件测试文档编制规范计算机软件测试文档编制规范GB/T 9386-1988GB/T 9386-1988软件文档管理指南软件文档管理指南GB/T 16680-1996GB/T 16680-1996管管理理标标准准计算机软件配置管理计划规范计算机软件配置管理计划规范GB/T 12505-1990GB/T 12505-1990信息技术信息技术软件产品评价质量特性及其使用指南软件产品评价质量特性及其使用指南GB/T 16260-1996GB/T 16260-1996计算机软件质量保证计划规范计算机软件质量保证计划规范GB/T 12504-1990GB/T 12504-1990计算机软件可靠性和可维护性管理计算机软件可靠性和可维护性管理GB/T 14394-1993GB/T 14394-1993软件工程标准的制定与推行软件工程标准的制定与推行 软件工程标准的制定与推行通常要经历一个环状生命周期，如下图所示。软件工程标准的制定与推行通常要经历一个环状生命周期，如下图所示。从最初的制定一项标准的初步设想，经发起后，沿着环状生命期，顺时针经从最初的制定一项标准的初步设想，经发起后，沿着环状生命期，顺时针经历以下步骤：历以下步骤：审核修订建议开发咨询审批公布培训实施发起发起撤销撤销1. 1. 建议建议拟定初步的建议方案拟定初步的建议方案2. 2. 开发开发制定标准的具体内容制定标准的具体内容3. 3. 咨询咨询征求并吸收有关人员的意见征求并吸收有关人员的意见4. 4. 审批审批由管理部门决定能否推出由管理部门决定能否推出5. 5. 公布公布公布发布，使标准生效公布发布，使标准生效6. 6. 培训培训为推行标准准备人员条件为推行标准准备人员条件7. 7. 实施实施投入使用，需经历相当期限投入使用，需经历相当期限8. 8. 审核审核检验实施效果，决定修改或撤销检验实施效果，决定修改或撤销9. 9. 修订修订修改其中不适当的部分，形成标准的新版本，进入修改其中不适当的部分，形成标准的新版本，进入新的周期新的周期 事实上，几乎所有的标准都有一个逐步的成熟，在环状生事实上，几乎所有的标准都有一个逐步的成熟，在环状生命期上循环数次的经历，这就需要标准的制定者和使用者付出命期上循环数次的经历，这就需要标准的制定者和使用者付出大量的劳动，来对标准加以完善。大量的劳动，来对标准加以完善。软件文档的分类软件文档的分类 国家标准局在国家标准局在19881988年年1 1月颁布了月颁布了计算机软件计算机软件开发规范开发规范和和计算机软计算机软件产品开发文件编制指件产品开发文件编制指南南，作为软件开发和文，作为软件开发和文档编制工作的准则和规程。档编制工作的准则和规程。 基于软件生存期方法，基于软件生存期方法，可以从可以从形式上形式上将将软件文档软件文档大致大致分成两类分成两类：软件开发软件开发过程中需要填写的各种图过程中需要填写的各种图表表，及，及应编制的各种技术应编制的各种技术文件或管理资料文件或管理资料。 软件文档根据其产生软件文档根据其产生和使用的范围，主要划分和使用的范围，主要划分为为3 3大类：大类：开发文档、用开发文档、用户文档和管理文档户文档和管理文档。软件文档软件文档开发文档开发文档用户文档用户文档管理文档管理文档可行性研究报告可行性研究报告项目开发计划项目开发计划软件需求说明书软件需求说明书数据库设计说明书数据库设计说明书概要设计说明书概要设计说明书详细设计说明书详细设计说明书用户手册用户手册操作手册操作手册软件需求说明书软件需求说明书数据要求说明书数据要求说明书项目开发计划项目开发计划模块开发卷宗模块开发卷宗开发进度月报开发进度月报测试计划测试计划测试分析报告测试分析报告项目开发总结报告项目开发总结报告1. 1. 开发文档开发文档 开发文档主要负责对软件开发过程进行描述和规范。开发文档除开发文档主要负责对软件开发过程进行描述和规范。开发文档除了前面列表的内容，还包括软件的详细技术描述，如程序逻辑、程序了前面列表的内容，还包括软件的详细技术描述，如程序逻辑、程序间相互关系、数据格式、存储等。间相互关系、数据格式、存储等。 开发文档主要可以发挥以下几个方面的作用：开发文档主要可以发挥以下几个方面的作用：(1) (1) 作为软件生存期个阶段之间的通信工具，记录生成软件需求、设作为软件生存期个阶段之间的通信工具，记录生成软件需求、设计、编码、测试等的详细规定和说明；计、编码、测试等的详细规定和说明；(2) (2) 描述开发小组的工作职责。通过规定软件规划设计、主题脚本编描述开发小组的工作职责。通过规定软件规划设计、主题脚本编制、文档编制、质量保证等人员的角色，来定义制、文档编制、质量保证等人员的角色，来定义“如何做如何做”和和“何时何时做做”；(3) (3) 用作检验点，而允许管理者评估开发进度。如果开发文档缺失或用作检验点，而允许管理者评估开发进度。如果开发文档缺失或过时，管理者将失去跟踪和控制软件项目的重要工具；过时，管理者将失去跟踪和控制软件项目的重要工具；(4) (4) 形成系统维护人员所要求的基本的软件支持文档，并构成产品文形成系统维护人员所要求的基本的软件支持文档，并构成产品文档档 的一部分；的一部分；(5) (5) 记录软件开发的历史。记录软件开发的历史。2. 2. 用户文档用户文档 用户文档主要负责对软件产品的安装、配置、使用、维护等信息进行描用户文档主要负责对软件产品的安装、配置、使用、维护等信息进行描述。包括系统安装配置手册、用户操作手册、软件需求说明书、数据要求说述。包括系统安装配置手册、用户操作手册、软件需求说明书、数据要求说明书等。用户文档主要发挥以下作用：明书等。用户文档主要发挥以下作用：(1) (1) 为使用和运行软件产品的用户提供培训和运行参考信息；为使用和运行软件产品的用户提供培训和运行参考信息；(2) (2) 为产品维护工程师提供必要的信息；为产品维护工程师提供必要的信息；(3) (3) 促进和方便软件产品的市场推广。促进和方便软件产品的市场推广。 用户文档的提供通常可以包括以下形式：产品的市场宣传资料、适合管用户文档的提供通常可以包括以下形式：产品的市场宣传资料、适合管理者的产品指南和相关资料、提供给潜在用户的较深入的产品技术资料、产理者的产品指南和相关资料、提供给潜在用户的较深入的产品技术资料、产品使用所需的完整的操作和技术资料等。品使用所需的完整的操作和技术资料等。 用户文档的涉众通常包括以下人员：一般潜在用户、具有决策权的潜在用户文档的涉众通常包括以下人员：一般潜在用户、具有决策权