ch9软件工程管理.ppt

《ch9软件工程管理.ppt》由会员分享，可在线阅读，更多相关《ch9软件工程管理.ppt（89页珍藏版）》请在三一办公上搜索。

1、第9章软件工程管理,软件工程管理概述软件规模估算进度计划人员组织软件配置管理软件质量保证软件工程标准与软件文档,软件工程管理概述,1.软件产品的特点软件是逻辑产品，具有高度的抽象性同一功能的软件可以有多样性软件生产过程复杂，具有易错性软件开发与维护主要是根据用户需求“定制”的，其过程具有复杂性和易变性软件的开发和运行经常受到计算机系统环境的限制，因而软件有安全性和可移植性等问题软件生产有许多新技术需要软件工程师进一步研究和实践,2.软件工程管理的重要性分阶段管理策略涉及多学科软件规模不断增大，管理难度增加，管理不善的后果严重,3.软件工程管理的内容 包括对软件开发成本、控制、开发人员、组织机构

2、、用户、软件开发文档、软件质量等方面的管理。,软件规模和开发工作量估算,面向规模的度量（代码行技术）面向功能的度量（功能点技术）CoCoMo模型,软件项目估算,估算涉及到人、技术、环境、政策等多种因素，很难精确地估算出项目的开销。常用四种估算方法参照已有类似项目估计待开发项目成本和工作量将大的项目分解成若干子项目，分别估算出子项目成本和工作量，再估算整个项目按软件的生命期分别估算各阶段的工作量和成本，再汇总，从而估算出整个项目根据实验或历史数据给出软件项目工作量或成本的经验公式软件项目代码行和功能点估算是成本和工作量估算的基础。（规模）LOC或FP的期望值：e=（a+4m+b)/6,代码行技术

3、用软件项目的代码行（LOC）数表示软件项目的规模生产率P=L/E，E是软件项目的工作量，用人月（PM）度量，L用千行代码kLOC度量每行代码的平均成本C=S/L，S是软件项目总的开销文档与代码比D=Pd/L，Pd是软件项目的文档页数代码出错率EQR=Ne/L，Ne是软件项目的代码错误数,例：下表提供了一个国外典型的软件项目记录利用这些数据，可以求出：P=12.1kLOC/24PM=504LOC/PMC=168000美元/12.1kLOC=13.88美元/LOCD=365Pd/12.1kLOC=30.16Pd/kLOCEQR=29个/12.1kLOC=2.4个/kLOC,用代码行数估计软件规模简

4、单易行缺点：代码行数的估算依赖于程序设计语言的功能和表达能力；采用代码行估算方法会对设计精巧的软件项目产生不利影响；在软件项目开发前或开发初期估算它的代码行数十分困难；代码行估算只适用于过程式程序设计语言，对非过程式的程序设计语言不太适用等,功能点技术依据对软件信息域特性和软件复杂性的评估结果，估算软件规模5个信息域特性为：用户输入数：各个用户输入是面向不同应用的输入数据（参数，不含查询数）个数。用户输出数：各个用户输出是面向应用的输出信息个数，包括报告，屏幕信息，错误信息等。用户查询数：查询是一种联机的交互操作，统计查询/响应的总计数。文件数：每一个逻辑主文件都应计数。逻辑主文件是指逻辑上的

5、一组数据，可以是一个大数据库的一部分，可以是一个单独的文件。外部接口数：与系统中其他设备通过外部接口读写信息次数均应计数。,功能点 FP(Function Point)。FP UFP(0.65 0.01SUM(Fi)估算功能点的步骤1.计算未调整的功能点数UFP UFP=a1Inp+a2Out+a3Inq+a4Maf+a5Inf 其中，ai（1i5）是信息域特性系数，值由相应特性的复杂级别决定。,2.计算技术复杂因子TCF14种技术因素：技术因素、数据通信、分布式数据处理、性能标准、高负荷的硬件、高处理率、联机数据输入、终端用户效率、联机更新、复杂的计算、可重用性、安装方便、操作方便、可移植性

6、、可维护性。,复杂性校正值 Fi1.系统是否需要可靠的备份和恢复？2.是否需要数据通信？3.是否有分布处理的功能？4.是否性能成为关键？5.系统是否运行在既存的高度实用化的操作环境中？6.系统是否需要联机数据项？7.联机数据项是否需要建立多重窗口显示和操作，以处理输入处理。8.主文件是否联机更新？9.输入、输出、文件、查询是否复杂？10.内部处理过程是否复杂？11.程序代码是否可复用？12.设计中是否包括了转移和安装？13.系统是否设计成可以重复安装在不同机构中14.系统是否设计成易修改和易使用？,计算技术因子对软件规模的综合影响程度DI：技术复杂性因子TCP由下式计算：TCP=0.65+0.

7、01 DI 计算功能点数FP FP=UFP TCP,一旦计算出功能点，就可仿照LOC的方式度量软件的生产率、质量和其它属性：生产率 FPPM（人月）质量 错误数FP 成本 元FP 文档 文档页数FP功能点度量是为了商用信息系统应用而设计的。,代码行度量与功能点度量的比较,代码行度量（依赖开发语言）与功能点度量（不依赖开发语言）的比较 LOC/FP（平均）：汇编语言=300FORTRAN=100pascal=90Ada=70面向对象语言=30 四代语言4GL=20 代码生成器=15一行Ada语言代码的“功能”平均是一行FORTRAN语言代码“功能”的1.4倍，一行四代语言代码的“功能”平均是一行

8、传统程序设计语言代码“功能”的35倍,CoCoMo 模型,1981年Boehm提出“构造性成本模型”（Constructive Cost Model）该成本估算模型是一种精确、易于使用的成本估算方法COCOMO模型的分类（按其详细程度，分三级）基本模型、中间模型、详细模型基本模型是静态单变量模型，用源代码行数(LOC)为自变量的经验函数计算软件开发工作量。中间模型在用LOC为自变量的函数计算软件开发工作量（称为名义工作量）的基础上，用涉及产品、硬件、人员、项目等方面的影响因素调整工作量估算。详细COCOMO模型包括中间模型的所有特性，但用上述各种影响因素调整工作量估算时，还要考虑对软件工程过程

9、中每一步骤（分析、设计等）的影响。,基本的CoCoMo模型,公式其中：E 表示工作量（人月PM）D 表示开发时间（月）L 是项目的代码行估计值（千行代码）,基本的CoCoMo模型参数,a,b,c,d 常数取值,中间的CoCoMo模型,以基本的CoCoMo模型为基础，工作量估计公式中乘以调节因子EAF E 表示工作量（人月PM）L 是项目的代码行估进一步考虑15种影响软件工作量的因素,15种影响软件工作量的因素 fi,产品因素：软件可靠性、数据库规模、产品复杂性；硬件因素：执行时间限制、存储限制、虚拟机易变性、环境周转时间；人的因素：分析员能力、应用领域实际经验、程序员能力、虚拟机使用经验、程序

10、语言使用经验；项目因素：现代程序设计技术、软件工具的使用、开发进度限制。,例 一个规模为10KLOC的商用微机远程通信的嵌入型软件，使用中间COCOMO模型进行成本估算。名义工作量E1 2.8(10)1.20 44.38实际工作量E 44.381.17 51.9,中间CoCoMo模型与各种开发方案对工作量的影响,建议参加项目的人数N 为人数，D 为开发时间（月）,E 为工作量（人月）一般来说，由N个程序员组成的小组，实现相同的规模的程序，相互通信数,设每次通信和交换意见的平均的工作量，则增加的通信开销为,一般情况下，由N 个程序员组成的小组共同开发一个程序的工作量，满足：程序员小组的生产率：单

11、个程序员与程序员小组生产率的比为事实：盲目增加程序员人数会推迟软件完成的日期,CoCoMo2模型,1997年Boehm对CoCoMo模型进行了扩充，称为CoCoMo2.COCOMO2模型分成三个层次应用系统组成模型：用于估算构建原型的工作量，这种模型考虑到大量使用已有构件的情况早期设计模型：用于软件结构设计阶段后期设计模型：用于软件开发阶段,COCOMO2模型把软件开发工作量表示成代码行（KLOC）的非线性函数：其中，是模型系数，典型值为3.0，b是模型指数，fi是成本因素。COCOMO2模型使用了5个分级因素Wi（1i5），分别是：项目先例性、开发灵活性、风险排除度、项目组凝聚力和过程成熟度

12、。其中每个成本因素划分为6个级别，每个级别的分级因素Wi取值如下：甚低Wi=5，低 Wi=4,正常Wi=3，高Wi=2，甚高Wi=1，特高Wi=0。b的值：,进度计划,可以把用于一般开发项目的进度安排的技术和工具应用于软件项目。为监控软件项目的进度计划和工作的实际进展情况，为表现各项任务之间进度的相互依赖关系，需要采用图示的方法。在图示方法中，必须明确标明：各个任务的计划开始时间，完成时间；各个任务完成标志（即文档编写和评审）；各个任务与参与工作的人数，各个任务与工作量之间的衔接情况；完成各个任务所需的物理资源和数据资源,甘特图Gantt Chart,在甘特图中，每一任务完成的标准，不是以能否

13、继续下一阶段任务为标准，而是以必须交付应交付的文档与通过评审为标准。因此在甘特图中，文档编制与评审是软件开发进度的里程碑。,工程网络技术,工程网络技术PERT技术(Program Evaluation and Review Technique)叫做程序评估与审查技术，CPM方法叫做关键路径法，它们都是安排开发进度，制定软件开发计划的最常用的方法。它们都采用网络图来描述一个项目的任务网络，也就是从一个项目的开始到结束，把应当完成的任务用图或表的形式表示出来。1.计算最早时刻2.计算最迟时刻3.关键路径4.机动时间,通常用两张表来定义网络图。一张表给出与一特定软件项目有关的所有任务（也称为任务分解

14、结构WorkBreakdownStructure）;另一张表给出应当按照什么样的次序来完成这些任务（有时称为限制表RestrictionList）。PERT技术和CPM方法都为项目计划人员提供了一些定量的工具。确定关键路径，即决定项目开发时间的任务链。在关键路径上的各个任务都是时间余量为零的关键任务，不能有任何时间延误。应用统计模型，对每一个单独的任务确定最可能的开发持续时间的估算值。计算边界时间，以便为具体的任务定义时间窗口。,上述示例工程中各项任务的进度安排，可用Gantt图画出：（先安排关键路径上的任务）,路径优化,人员组织,1.开发人员2.组织机构三种组织结构模式按课题划分的模式（Pr

15、oject Format）按职能划分的模式（Functional Format）矩阵形模式（Matrix Format）程序设计小组的组织形式有3种：主程序员组、民主制程序员组及层次式小组3.用户用户的阻力和干扰：不积极配合、求全求快、功能的变化,软件项目组织的建立开发组织采用什么形式，要针对软件项目的特点来决定，同时也与参与人员的素质有关。组织原则(1)尽早落实责任：在软件项目工作开始时，要尽早指定专人负责，使他有权进行管理，并对任务的完成负全责。（2）减少接口：一个组织的生产率随完成任务中存在的通信路径数目增加而降低。要有合理的人员分工、好的组织结构、有效的通信，减少不必要的生产率的损失。

16、（3）责权均衡：软件经理人员所负的责任不应比委任给他的权力还大。,组织结构的模式1）按课题划分的模式 把软件开发人员按课题组成小组，小组成员自始至终参加所承担课题的各项任务。他们应负责完成软件产品的定义、设计、实现、测试、复查、文档编制、甚至包括维护在内的全过程。2）按职能划分的模式 把参加开发项目的软件人员按任务的工作阶段划分成若干个专业小组。要开发的软件产品在每个专业小组完成阶段加工（即工序）以后，沿工序流水线向下传递。例如，分别建立计划组、需求分析组、设计组、实现组、系统测试组、质量保证组、维护组等。各种文档资料按工序在各组之间传递。,3）矩阵形模式 这种模式实际上是以上两种模式的复合。

17、一方面，按工作性质，成立一些专门组，如开发组、业务组、测试组等；另一方面，每一个项目又有它的经理人员负责管理。每个软件人员属于某一个 专门组，又参加某一项目的工作。,程序设计小组的组织形式小组内部人员的组织形式对生产率也有影响。现有的组织形式有三种。（1）主程序员制小组 小组的核心由一位主程序员(高级工程师)、二至五位技术员、一位后援工程师组成。主程序员负责小组全部技术活动的计划、协调与审查，设计和实现项目中的关键部分。,技术员负责项目的具体分析与开发，文档资料的编写工作。后援工程师支持主程序员的工作，为主程序员提供咨询，也做部分分析、设计和实现的工作。并在必要时能代替主程序员工作。主程序员制

18、小组还可以由一些专家(如通信专家或数据库设计专家)、辅助人员(如打字员和秘书)、软件资料员协助工作。（2）民主制小组 在民主制小组中，遇到问题，组内成员之间可以平等地交换意见。工作目标的制定及做出决定都由全体成员参加。虽然也有一位成员当组长，但工作的讨论、成果的检验都公开进行。这种组织形式强调发挥小组每个成员的积极性。有人认为这种组织形式适合于研制时间长、开发难度大的项目。,（3）层次式小组 在层次式小组中，组内人员分为 三级：组长（项目负责人）一人负责全组工作，包括任务分配、技术评审和走查、掌握工作量和参加技术活动。他直接领导二至三名高级程序员，每位高级程序员通过基层小组，管理若干位程序员。

19、这种组织结构只允许必要的人际通信。比较适用于项目本身就是层次结构的课题。因为这样可以把项目按功能划分成若干个子项目，把子项目分配给基层小组，由基层小组完成。这种组织方式比较适合于大型软件项目的开发。,人员配备如何合理地配备人员，也是成功地完成软件项目的切实保证。所谓合理地配备人员应包括：按不同阶段适时任用人员 恰当掌握用人标准。项目开发各阶段所需人员一个项目完成的快慢，取决于参与开发人员的多少在开发过程中，多数软件项目是以恒定人力配备的。实际人力需求与开发进度的关系如下图中的曲线所示。按此曲线，需要的人力随开发进展逐渐增加，在编码与单元测试阶段达到高峰，以后又逐渐减少。如果恒定地配备人力，在开

20、发初期将会有部分人力资源用不上而浪费掉。在开发中期，需要人力不够，造成进度的延误。在开发后期就需要增加人力以赶进度。恒定地配备人力将浪费人力资源。,配备人员的原则重质量 软件项目是技术性很强的工作，要任用少量有实践经验、有能力的人员去完成关键性的任务。重培训 培养所需技术人员和管理人员是有效解决人员问题的好方法。双阶梯提升 人员提升应分别按技术职务和管理职务进行，不能混在一起。,对项目经理人员的要求软件经理人员是工作的组织者，他的管理能力的强弱是项目成败的关键。他应具有以下能力：把用户提出的非技术性要求加以整理提炼,以技术说明书的形式转告给分析员和测试员。能说服用户放弃一些不切实际的要求,以保

21、证合理的要求得以满足。能够把表面上似乎无关的要求集中在一起,归结为“需要什么”,“要解决什么问题”。这是一种综合问题的能力。要懂得心理学,能说服上级领导和用户，让他们理解什么是不合理的要求。但又要使他们毫不勉强,乐 于接受，并受到启发。,评价人员的条件软件项目中人的因素越来越受重视。在评价和任用软件人员时，必须掌握一定的标准。人员素质的优劣常常影响到项目的成败。牢固掌握计算机软件的基本知识和技能。善于分析和综合问题，具有严密的逻辑思维能力。工作踏实、细致,不靠碰运气，遵循标准和规范，具有严格的科学作风。工作中表现出有耐心、有毅力、有责任心。善于听取别人的意见，善于与周围人员团结协作，建立良好的

22、人际关系。具有良好的书面和口头表达能力。,软件配置管理,软件配置（Software Configuration）是软件产品在软件开发或运行过程中产生的全部信息。软件配置管理（Software Configuration Management）简称SCM，是在软件的整个生存周期内管理变更的一组活动。软件配置管理(Software Configuration Management，简称SCM)的四项任务:()标识变更()控制变更()配置审计()配置状态报告,软件配置管理概念,软件开发过程的最终结果包括三类信息：计算机程序（源程序和目标程序）；描述程序的文档（面向技术人员和面向用户）；数据结构（包括

23、程序内部和外部定义两部分）。组成上述信息的所有项目构成一个软件配置，其中每一项称为一个软件配置项（Software Configuration Item，简称SCI），它是配置管理的基本单位。一个SC中最早的SCI是系统规格说明书。SCM要解决的主要问题就是保证软件的质量。,基线技术,基线（baseline）的原意是棒球场的边线，在软件开发过程中，为了有效地控制变动，软件配置管理引入基线的概念。IEEE组织对于基线的定义“已经通过正式复审和批准的某规约或产品，它因此可以作为进一步开发的基础，并且只能遵循正式的变化控制过程得到改变”。根据这个定义，基线标志软件开发过程的各个里程碑，任一SCI，一

24、旦形成文档并复审通过，即成为一个基线，它标志开发过程中一个阶段的结束。对于已成为基线的SCI，虽然可以修改，但必须按照一个特殊的、正式的过程进行评估，确认每一处修改。相反，对于未成为基线的SCI，可以进行非正式修改。某个SCI一旦成为基线，随即被放入项目数据库（project database）。此后，若开发小组中某位成员希望改动SCI，首先要将它拷贝到私有工作区并在项目数据库中锁住，不允许他人使用。在私有工作区中完成修改控制过程并复审通过之后，再把修改后的SCI推出并回送到项目数据库，同时解锁。,一般软件配置需包括下列SCI：1系统规格说明书2软件项目规划3需求分析结果 1）软件需求规格说明

25、书 2）可执行的或“纸样”原型4初步用户手册 5设计规格说明书 1）数据设计描述 2）总体结构设计描述 3）模块设计描述 4）界面设计描述 5）对象描述（若采用面向对象技术）,6源代码清单7测试规格说明书 1）测试计划和过程 2）测试用例和实验结果 8操作和安装手册9可执行程序 1）每个模块的可执行代码 2）连接到一起的代码10数据库描述 1）数据模型和文件结构 2）初始化映象11联机用户手册12维护文档 1）软件问题报告单 2）维护申请单 3）预计变动的顺序13软件工程的标准和过程,软件配置管理任务,软件配置管理主要任务是控制软件的修改，主要包括：标识软件配置中各种对象；管理软件的各种版本；

26、控制对软件的修改；审计配置；报告配置情况。,标识配置对象,所有SCI都应按面向对象的方式命名并组织起来。对象命名是为了能够根据名称提取对象；而通过组织对象并描述其间的关系则着眼于在对象变更时能够清楚地了解变更的影响范围。基本对象在分析、设计、编码或测试阶段由开发人员创建的某个“文本单元”（unit of text）。例如，需求说明书中某一节，某个模块的源代码，或按等价分类法制定的一套测试用例复合对象由若干基本对象和复合对象组合而成的对象，是一个递归的概念。例如，“设计规格说明书”是复合对象，它由“数据模块”和“模块N”等基本对象组合而成。,每个配置对象都拥有名字、描述、资源列表和实际存在体四个

27、部分：1.对象名一般为无二义字符串；2.对象描述包括若干数据项，它们指明对象的类型（例如，文档、程序还是数据）、所属工程项目的标志及变动和版本的有关信息；3.资源列表给出该对象要求、引用、处理和提供的所有实体，如数据类型、特殊函数等，有时变量也被看作资源；4.只有基本对象才有实际存在体，它是指向该对象“单元正文描述”的一个指针；对于复合对象，此项取null值。,除了标识配置对象外，还必须指明对象之间的关系，一个对象可标识为另一个复合对象的一部分，即此两对象之间存在一个关系。若干关系可定义出对象之间的分层结构。例如：“ER图”“数据模型”“数据模型”“设计规格说明书”因一个配置对象可能与其他多个

28、对象有关系，所以SCI的分层结构不一定是简单的树状结构，而是更一般的网状结构。,版本控制,为了适应不同环境特点和满足不同用户的个性需求，往往一个项目保存多个版本。配置管理的版本控制主要解决下列问题：1）根据不同用户的需要配置不同的系统；2）保存系统老版本，为以后调查问题使用；3）建立一个系统新版本，使它包含某些决策而抛弃另一些；4）支持两位以上工程师同时在一个项目中工作；5）高效存储项目的多个版本。,版本控制系统都为配置对象的每个版本设置一组属性，这组属性既可以是简单的版本号，也可以是一串复杂的布尔变量（即开关值），用以说明该版本功能上的变化。进化图可用于描述一个软件系统的不同版本。图中每个结

29、点都是软件的一个完整版本，它由所有协调一致的软件配置项组成（源代码，文档和数据）。此外，一个版本还允许有多种变形（Variant）。例如，一个程序的某个版本由A、B、C、D、E五个部件组成，部件D仅在系统配有彩色显示器时使用，部件E则适用于单显，那么该版本就有两种变形，一种由A、B、C、D四个部件组成，另一种由A、B、C、E四个部件组成。,修改控制,在大型软件开发过程中，无控制地修改会迅速导致混乱。所谓修改控制，即把人的努力与自动工具结合起来，建立一套机制，有意识地控制软件修改。当一个“修改申请”提出后，开发者依据技术指标和潜在的副作用，对其他配置对象和系统功能可能造成的影响以及项目成本等诸多

30、因素进行评估。评估的结果将形成一个“修改报告单”，提交给修改控制机构(CCA)决策。CCA一旦同意修改，应立即提供一个“工程变动命令”ECO（Engineering Change Order）。它指明修改任务、需遵守的限制和复审标准。然后从项目数据库中“提出”待修改对象，经修改后再“推出”更新版本。这一对动作是项目数据库访问控制和同步控制要求的。访问控制决定哪些人员有权访问或修改某个配置对象；而同步控制则保证并行修改时不因互相重写而造成丢失修改。,软件开发人员根据ECO从项目数据库中提出待修改对象，访问控制机构，核实该开发人员是否有此特权，而同步控制机构则及时锁住待修改对象，不允许其他开发人员

31、再做修改，直至该对象的新版本推出。加锁期间，其他工程人员仍可提取该对象的副本（称为提取版本）使用。上图所示的修改控制用于已交给用户的软件产品，称为正式修改控制。若欲修改的SCI虽已为基线版本，但尚未交付用户，此时修改控制称为工程级的修改控制，它除了不涉及用户外，其他步骤与正式的修改控制大致相同。若SCI并未成为基线版本，只需进行非正式的修改控制，则在不影响系统需求的前提下，该SCI的开发者可随意改动,变更控制过程,配置审计,对于变更工作，必须通过正式的技术复审和软件配置审计工作来验证被核准进行变更的对象是否进行了必要的、正确的变更，并得到了重新的配置。正式的技术复审着重考虑所修改对象在技术上的

32、正确性，复审人员应对该对象是否与其他SCI协调以及在修改中可能产生的疏忽和副作用进行全面的评估。软件配置审计作为正式复审的一种补充措施，主要考虑下列在正式技术复审中未被考虑的因素：工程变动命令中指定的修改是否都已完成？有无进行未经指定的其他附加变更？是否做过正式技术复审？是否严格遵守软件工程标准？是否对修改过的SCI进行了强调说明？修改的日期和执行修改的人员是否已经注明？该SCI的属性是否能够反映本次修改的结果？是否遵循了标注变更、记录变更和报告变更的SCM工作规程？所有相关的SCI是否已一并修改？,配置状况报告,建立并发布配置状况报告（Configuration Status Reporti

33、ng，简称CSR）是软件配置管理的一项任务.CSR主要概述下列问题：发生了什么事情；谁做的；何时发生的；有什么影响。CSR的时机与上图所述过程紧密相关:当某个SCI被赋予新标记或更新标记时;或修改控制机构CCA批准一项修改申请（产生一个工程变动命令ECO）时;或配置审计完成时。CSR的输出可放在联机数据库中，供开发人员和维护人员随时按关键字查询,软件质量保证,计算机软件质量是软件的一些内部特性及其组合，质量不是在软件产品中被测试出来的，而是在软件开发和生产过程中形成的。软件质量（Software quality）的定义为：（1）软件产品中能满足给定需要的性质和特性的总体。（2）软件具有所期望的

34、各种属性的组合程度。（3）顾客和用户觉得软件满足其综合期望的程度。（4）确定软件在使用中将满足顾客预期要求的程度。为保证软件充分满足用户要求而进行的有计划、有组织的活动称为软件质量保证，其目的是生产高质量的软件。,软件质量的特性,软件质量是指软件满足明确规定或隐含定义的需求的程度。软件质量的要点：软件功能必须满足用户规定的需求；软件应遵守规定标准所定义的一系列开发准则；软件应满足某些隐含的需求。如，可理解性、可维护性等。,软件质量的特性:功能性：软件的功能达到它的设计规范和能满足用户需求的程度可靠性：在规定的时间和规定的条件下，软件能够实现所要求的功能的能力以及不引起系统失效的概率易使用性：用

35、户学习、操作、准备输入和理解输出的难易程度效率：软件实现某种功能所需计算机资源的多少及执行其功能时使用资源的持续时间的多少可维护性：进行必要修改的难易程度可移植性：软件从一个计算机环境转移到另一个计算机环境下的运行能力,软件质量保证措施,软件质量保证是软件工程管理的重要内容。包括以下措施：应用好的技术方法测试软件进行正式的技术评审标准的实施控制变更程序正确性证明记录、保存和报告软件过程信息,软件工程标准与软件文档,软件工程标准软件工程标准化的定义 对软件生存期内的所有开发、维护和管理工作逐步建立起标准软件工程标准化的意义提高软件的可靠性、可维护性和可移植性；提高软件的生产率和软件人员的技术水平

36、；提高软件人员之间的通信效率，减少差错和误解；有利于软件管理；有利于降低软件产品的成本和运行维护成本；有利于缩短软件开发周期。,软件工程标准化的类型 参照其它工程领域对工程标准划分的方法，软件工程标准主要有两种：按标准的类型划分和按标准的范围划分。(1)按标准的类型划分 主要有过程标准、产品标准、行业标准、记法标准等。过程标准与开发一个产品或从事一项服务的一系列活动或操作有关。过程标准使用一组方法、工具和技术，给出“谁来做”、“做什么”、“如何做”、“何时做”、“何地做”及在软件工程活动中进行的不同层次工作的过程模型。产品标准则涉及软件工程事务的格式和内容。软件开发和维护活动文档化的结果就是软

37、件产品，软件文档是软件工程活动进一步开展的基础。软件开发作为一种行业，其行业标准涉及软件工程的所有方面，如执业认证、职业培训、产品许可等。行业标准可以等同于行业行为规范。记法标准规定了在软件工程行业范围内，以唯一的方式进行交流的方法，如术语、表示法、语言等。(2)按标准的范围划分 主要是根据软件的任务功能和软件生存期进行比较、判定、评价和确定软件工程标准的范围和内容。任务功能可以表示软件工程过程，可以划分为产品工程功能、验证与确认功能以及技术管理功能3个部分。产品工程功能包括定义、生产和支持最终产品所必须的过程。验证和确认功能是检查产品质量的活动。技术管理功能是构造和控制产品工程的过程。这3个

38、部分并不集中在单个的软件生存周期里，而是并行进行的生产、检查和控制活动。,根据以上两种分类方法，软件工程标准可用一张二维表格来表示。,上述两表给出了二维表的大致格式。其中，给出了GB/T 9385-1988、GB/T 1526-1989、GB/T 8566-1995这3个标准的例子，用于说明各个标准的类型及其作用。1.GB/T 9385-1988是原电子工业部批准的计算机软件需求说明编制指南，用于指导软件需求规格说明书的编写。2.GB/T 1526-1989是国家标准总局批准的信息处理数据流图、程序流程图、系统结构图、程序网络图、系统资源图的文件编制符号及约定。3.GB/T 8566-1995

39、是国家标准总局批准的信息技术软件生存期过程标准，它规定了在获取、供应、开发、操作、维护软件和固件的软件部分时，要实施的过程、活动和任务。目的是为用户提供一个公共的框架，使软件从业人员可以使用“相同的语言”创作和管理软件。,软件工程标准编制的层次 根据软件工程标准制定的机构和标准适用的范围，可分为5个层次：国际标准、国家标准、行业标准、企业(机构)标准、项目(课题)标准。1.国际标准：由国际联合机构制定和公布的标准，供各国参考。如ISO国际标准化组织。2.国家标准：由政府或国家级的机构制定或批准，适用于全国范围。如GB中国国标、ANSI_美国国家标准协会、BS英国国家标准、JIS日本工业标准。3

40、.行业标准：由行业机构、学术团体或国防等机构制定，适用于某个业务领域。如IEEE美国电气和电子工程师学会、GJB中国国家军用标准。4.企业规范：企业因软件工程工作的需要制定的适用于本企业的规范。如IBM通用产品部于1984年制定的程序设计开发指南。5.项目规范：由某一科研生产项目组织制定，仅为该项目任务服务的软件工程规范。如CIMS计算机集成制造系统软件工程规范。,中国的软件标准 1983年起，我国陆续制定和发布了20余项软件工程国家标准。这些标准可以分为以下四类：1.基础标准：规定了信息加工处理和软件工程领域的术语、符号、表示、构造、分类级约定；2.开发标准：规定了软件生存期过程、软件支持环

41、境、软件记录处理流程、软件维护等的工作规范；3.文档标准：规定了软件产品、需求、测试、管理等文档的编制规范；4.管理标准：规定了软件配置管理计划、质量保证计划、产品质量特性、软件可靠性和可维护性管理等的规范和工作要素。下表列出了我国部分软件工程标准的名称及其标准号：,软件工程标准的制定与推行 软件工程标准的制定与推行通常要经历一个环状生命周期，如下图所示。从最初的制定一项标准的初步设想，经发起后，沿着环状生命期，顺时针经历以下步骤：,发起,撤销,1.建议拟定初步的建议方案2.开发制定标准的具体内容3.咨询征求并吸收有关人员的意见4.审批由管理部门决定能否推出5.公布公布发布，使标准生效6.培训

42、为推行标准准备人员条件7.实施投入使用，需经历相当期限8.审核检验实施效果，决定修改或撤销9.修订修改其中不适当的部分，形成标准的新版本，进入新的周期 事实上，几乎所有的标准都有一个逐步的成熟，在环状生命期上循环数次的经历，这就需要标准的制定者和使用者付出大量的劳动，来对标准加以完善。,软件文档的分类 国家标准局在1988年1月颁布了计算机软件开发规范和计算机软件产品开发文件编制指南，作为软件开发和文档编制工作的准则和规程。基于软件生存期方法，可以从形式上将软件文档大致分成两类：软件开发过程中需要填写的各种图表，及应编制的各种技术文件或管理资料。软件文档根据其产生和使用的范围，主要划分为3大类

43、：开发文档、用户文档和管理文档。,软件文档,开发文档,用户文档,管理文档,可行性研究报告,项目开发计划,软件需求说明书,数据库设计说明书,概要设计说明书,详细设计说明书,用户手册,操作手册,软件需求说明书,数据要求说明书,项目开发计划,模块开发卷宗,开发进度月报,测试计划,测试分析报告,项目开发总结报告,1.开发文档 开发文档主要负责对软件开发过程进行描述和规范。开发文档除了前面列表的内容，还包括软件的详细技术描述，如程序逻辑、程序间相互关系、数据格式、存储等。开发文档主要可以发挥以下几个方面的作用：(1)作为软件生存期个阶段之间的通信工具，记录生成软件需求、设计、编码、测试等的详细规定和说明

44、；(2)描述开发小组的工作职责。通过规定软件规划设计、主题脚本编制、文档编制、质量保证等人员的角色，来定义“如何做”和“何时做”；(3)用作检验点，而允许管理者评估开发进度。如果开发文档缺失或过时，管理者将失去跟踪和控制软件项目的重要工具；(4)形成系统维护人员所要求的基本的软件支持文档，并构成产品文档 的一部分；(5)记录软件开发的历史。,2.用户文档 用户文档主要负责对软件产品的安装、配置、使用、维护等信息进行描述。包括系统安装配置手册、用户操作手册、软件需求说明书、数据要求说明书等。用户文档主要发挥以下作用：(1)为使用和运行软件产品的用户提供培训和运行参考信息；(2)为产品维护工程师提

45、供必要的信息；(3)促进和方便软件产品的市场推广。用户文档的提供通常可以包括以下形式：产品的市场宣传资料、适合管理者的产品指南和相关资料、提供给潜在用户的较深入的产品技术资料、产品使用所需的完整的操作和技术资料等。用户文档的涉众通常包括以下人员：一般潜在用户、具有决策权的潜在用户、最终用户、产品维护人员等。最基本的用户文档通常包括以下几类：产品培训手册、产品操作手册、产品安装配置手册、产品支持手册、产品信息广告等。用户文档的分发按照涉众的类型j进行。不同类型的涉众可以获得不同的用户文档。用户文档在分发前应该制定合适的分发策略和计划。,3.管理文档 管理文档主要是对软件开发过程的管理信息进行描述

46、。管理文档除了前面列表内容，还应该包括被管理者的反馈信息，如各色表格、工作总结、开发体会、产品建议等。管理文档主要有以下主要：(1)软件初期定义、规划、商务等与客户互动结果的记录；(2)开发过程每个阶段的进度和进度变更的记录；(3)软件开发人员的组织、管理和变更的记录；(4)软件需求、规划、设计等的变更控制的记录；(5)开发过程发生的各种审查、审核、评估等情况的记录；(6)验收、培训、移交、安装等相关工作的实施记录；(7)维护需求的提出、认定、计划、实施等工作的记录。,软件文档与使用者的关系 软件开发中产生的各类文档面向不同的用户，而软件用户应该得到的文档也在商业合同中有明确规定。,软件文档的

47、使用对象,开发人员,维护人员,管理人员,用 户,可行性研究报告,项目开发计划,软件需求说明书,数据要求说明书,概要设计说明书,详细设计说明书,数据库设计说明书,测试计划,测试分析报告,设计说明书,测试分析报告,模块开发卷宗,可行性研究报告,项目开发计划,模块开发卷宗,开发进度月报,项目开发总结报告,用户手册,操作手册,软件文档编制与软件生存期的关系 软件文档的编制是随着软件生存期各个阶段工作的开展而适时进行的。其中，有的仅反映某一阶段的工作，有的则需要跨越多个阶段的工作。,软件文档最终需要回答读者关心的下列问题：1.为什么要开发、维护或修改这个软件？(Why)2.工作目标要满足哪些需求？(What)3.需求应如何实现？(How)4.开发、维护或修改的工作应由谁来完成？(Who)5.开发工作的时间如何安排？(When)6.开发工作在什么环境中实现，所需信息从何而来？(Where),