ch9软件工程管理

《ch9软件工程管理》由会员分享，可在线阅读，更多相关《ch9软件工程管理（89页珍藏版）》请在装配图网上搜索。

1、,,,,,单击此处编辑母版文本样式,,第二级,,第三级,,第四级,,第五级,,*,*,*,单击此处编辑母版标题样式,,第9章　软件工程管理,,软件工程管理概述,,软件规模估算,,进度方案,,,软件配置管理,,软件质量保证,,软件工程标准与软件文档,1,,软件工程管理概述,1. 软件产品的特点,,软件是逻辑产品，具有高度的抽象性,,同一功能的软件可以有多样性,,软件生产过程复杂，具有易错性,,软件开发与维护主要是根据用户需求“定制〞的，其过程具有复杂性和易变性,,软件的开发和运行经常受到计算机系统环境的限制，因而软件有平安性和可移植性等问题,,软件生产有许多新技术需要软件工程师进一步研究和实践,

2、2,,2.,软件工程管理的重要性,,分阶段管理策略,,涉及多学科,,软件规模不断增大，管理难度增加，管理不善的后果严重,3,,3.软件工程管理的内容,,包括对软件开发本钱、控制、开发人员、组织机构、用户、软件开发文档、软件质量等方面的管理。,4,,软件规模和开发工作量估算,,面向规模的度量（代码行技术）,,面向功能的度量（功能点技术）,,CoCoMo,模型,5,,软件工程估算,估算涉及到人、技术、环境、政策等多种因素，很难精确地估算出工程的开销。,,常用四种估算方法,,参照已有类似工程估计待开发工程本钱和工作量,,将大的工程分解成若干子工程，分别估算出子工程本钱和工作量，再估算整个工程,,按软

3、件的生命期分别估算各阶段的工作量和本钱，再汇总，从而估算出整个工程,,根据实验或历史数据给出软件工程工作量或本钱的经验公式,,软件工程代码行和功能点估算是本钱和工作量估算的基础。（规模）,,LOC或FP的期望值：e=（a+4m+b)/6,6,,代码行技术,,用软件工程的代码行（LOC）数表示软件工程的规模,,生产率P=L/E，E是软件工程的工作量，用人月（PM）度量，L用千行代码kLOC度量,,每行代码的平均本钱C=S/L，S是软件工程总的开销,,文档与代码比D=Pd/L，Pd是软件工程的文档页数,,代码出错率EQR=Ne/L，Ne是软件工程的代码错误数,7,,例：下表提供了一个国外典型的软件

4、工程记录,,,,,,,利用这些数据，可以求出：,,P=12.1kLOC/24PM=504LOC/PM,,C=168000美元/12.1kLOC=13.88美元/LOC,,D=365Pd/12.1kLOC=30.16Pd/kLOC,,EQR=29个/12.1kLOC=2.4个/kLOC,8,,用代码行数估计软件规模简单易行,,缺点：,,代码行数的估算依赖于程序设计语言的功能和表达能力；,,采用代码行估算方法会对设计精巧的软件工程产生不利影响；,,在软件工程开发前或开发初期估算它的代码行数十分困难；,,代码行估算只适用于过程式程序设计语言，对非过程式的程序设计语言不太适用等,9,,功能点技术依据

5、对软件信息域特性和软件复杂性的评估结果，估算软件规模5个信息域特性为：,,用户输入数：各个用户输入是面向不同应用的输入数据（参数，不含查询数）个数。,,用户输出数：各个用户输出是面向应用的输出信息个数，包括报告，屏幕信息，错误信息等。,,用户查询数：查询是一种联机的交互操作，统计查询/响应的总计数。,,文件数：每一个逻辑主文件都应计数。逻辑主文件是指逻辑上的一组数据，可以是一个大数据库的一局部，可以是一个单独的文件。,,外部接口数：与系统中其他设备通过外部接口读写信息次数均应计数。,10,,功能点,FP (Function Point),。,FP,＝,UFP×( 0.65,＋,0.01×SU

6、M ( Fi ) ),估算功能点的步骤,1.,计算未调整的功能点数,UFP UFP=a1×Inp+a2×Out+ a3×Inq+a4×Maf+a5×Inf,其中，,ai,（,1≤i≤5,）是信息域特性系数，值由相应特性的复杂级别决定,。,,11,,2.计算技术复杂因子TCF14种技术因素：技术因素、数据通信、分布式数据处理、性能标准、高负荷的硬件、高处理率、联机数据输入、终端用户效率、联机更新、复杂的计算、可重用性、安装方便、操作方便、可移植性、可维护性。,12,,复杂性校正值,Fi,,1.,,系统是否需要,可靠的备份,和,恢复,？,,2.,,是否需要,数据通信,？,,3.,,是否有

7、,分布处理的功能,？,,4.,,是否,性能成为关键,？,,5.,,系统是否,运行在既存的高度实用化的操作环境中,？,,6.,,系统是否需要,联机数据项,？,,7.,,联机数据项是否需要,建立多重窗口显示和操作,，,以处理输入处理,。,,8.,,主文件是否,联机更新,？,,9.,,输入,、,输出,、,文件,、,查询,是否,复杂,？,,10.,,内部处理过程,是否,复杂,？,,11.,,程序代码,是否,可复用,？,,12.,,设计中是否包括了,转移,和,安装,？,,13.,,系统是否设计成可以,重复安装在不同机构中,,14.,,系统是否设计成,易修改,和,易使用,？,13,,计算技术因子对软件规模

8、的综合影响程度,DI,：,,,,,技术复杂性因子,TCP,由下式计算：,,TCP = 0.65 + 0.01 × DI,,计算功能点数,FP,,,FP = UFP ×TCP,14,,一旦计算出功能点，就可仿照LOC的方式度量软件的生产率、质量和其它属性：,,生产率 ＝ FP／PM（人月） 质量 ＝ 错误数／FP,,本钱 ＝ 元／FP 文档 ＝ 文档页数／FP,,功能点度量是为了商用信息系统应用而设计的。,15,,代码行度量与功能点度量的比较,代码行度量（依赖开发语言）与功能点度量（不依赖开发语言）的比较,,LOC/FP（平均）：,,汇编语言=300,,FORTRAN=10

9、0,,pascal=90,,Ada=70,,面向对象语言=30,,四代语言4GL=20,,代码生成器=15,,一行Ada语言代码的“功能〞平均是一行FORTRAN语言代码“功能〞的1.4倍，一行四代语言代码的“功能〞平均是一行传统程序设计语言代码“功能〞的3~5倍,16,,CoCoMo 模型,1981年Boehm提出“构造性本钱模型〞（Constructive Cost Model）,,该本钱估算模型是一种精确、易于使用的本钱估算方法,,COCOMO模型的分类（按其详细程度，分三级）根本模型、 中间模型、 详细模型,,根本模型是静态单变量模型，用源代码行数(LOC) 为自变量的经验函数计算软件

10、开发工作量。,,中间模型在用LOC为自变量的函数计算软件开发工作量（称为名义工作量）的基础上，用涉及产品、硬件、人员、工程等方面的影响因素调整工作量估算。,,详细COCOMO模型包括中间模型的所有特性，但用上述各种影响因素调整工作量估算时，还要考虑对软件工程过程中每一步骤（分析、设计等）的影响。,17,,根本的CoCoMo模型,公式,,,,其中：,,E 表示工作量（人月PM）,,D 表示开发时间（月）,,L 是工程的代码行估计值（千行代码）,,18,,根本的CoCoMo模型参数,a,b,c,d,常数取值,软件类型,a,b,c,d,适用范围,组织型,2.4,1.05,2.5,0.38,各类应用程

11、序,半独立型,3.0,1.12,2.5,0.35,各类实用程序、编译程序等,嵌入型,3.6,1.20,2.5,0.32,实时处理、控制程序、操作系统,19,,中间的CoCoMo模型,以根本的CoCoMo模型为基础，工作量估计公式中乘以调节因子EAF,,,,E 表示工作量（人月PM）,,L 是工程的代码行估,,,进一步考虑15种影响软件工作量的因素,,软件类型,a,b,组织型,3.2,1.05,半独立型,3.0,1.12,嵌入型,2.8,1.20,20,,15,种影响软件工作量的因素,,fi,产品因素：,,软件可靠性、数据库规模、产品复杂性；,,硬件因素：,,执行时间限制、存储限制、虚拟机易变性

12、、环境周转时间；,,人的因素：,,分析员能力、应用领域实际经验、程序员能力、虚拟机使用经验、程序语言使用经验；,,工程因素：,,现代程序设计技术、软件工具的使用、开发进度限制。,21,,22,,例 一个规模为10KLOC的商用微机远程通信的嵌入型软件，使用中间COCOMO模型进行本钱估算。,,,名义工作量E1 ＝ 2.8× (10)1.20 ＝44.38,,实际工作量E ＝ 44.38×1.17 ＝ 51.9,23,,中间,CoCoMo,模型与各种开发方案对工作量的影响,建议参加工程的人数,,,N 为人数，D 为开发时间（月）, E 为工作量（人月）,,一般来说，由N个程序员组成的小组，实现相

13、同的规模的程序，相互通信数 ,,,设每次通信和交换意见的平均的工作量 ，则增加的通信开销为,24,,一般情况下，由,N,个程序员组成的小组共同开发一个程序的工作量 ，满足：,,,程序员小组的生产率：,,,单个程序员与程序员小组生产率的比为,,,,事实：,盲目增加程序员人数会推迟软件完成的日期,,,,25,,CoCoMo2模型,1997,年,Boehm,对,CoCoMo,模型进行了扩充，称为,CoCoMo2.,,COCOMO2,模型分成三个层次,,应用系统组成模型：用于估算构建原型的工作量，这种模型考虑到大量使用已有构件的情况,,早期设计模型：用于软件结构设计阶段,

14、,后期设计模型：用于软件开发阶段,,26,,COCOMO2模型把软件开发工作量表示成代码行（KLOC）的非线性函数：其中，α是模型系数，典型值为3.0，b是模型指数，fi是本钱因素。,,,,COCOMO2模型使用了5个分级因素Wi（1≤i≤5），分别是：工程先例性、开发灵活性、风险排除度、工程组凝聚力和过程成熟度。,,其中每个本钱因素划分为6个级别，每个级别的分级因素Wi取值如下：甚低Wi=5，低 Wi=4, 正常Wi=3，高Wi=2，甚高Wi=1，特高Wi=0。,,b的值：,27,,进度方案,可以把用于一般开发工程的进度安排的技术和工具应用于软件工程。,,为监控软件工程的进度方案和工作的实际

15、进展情况，为表现各项任务之间进度的相互依赖关系，需要采用图示的方法。,,在图示方法中，必须明确标明：,,各个任务的方案开始时间，完成时间；,,各个任务完成标志（即○文档编写和△评审）；,,各个任务与参与工作的人数，各个任务与工作量之间的衔接情况；,,完成各个任务所需的物理资源和数据资源,28,,甘特图,Gantt Chart,29,,在甘特图中，每一任务完成的标准，不是以能否继续下一阶段任务为标准，而是,以必须交付应交付的文档与通过评审为标准,。因此在甘特图中，文档编制与评审是软件开发进度的里程碑。,,30,,31,,工程网络技术,,工程网络技术PERT技术 (Program Evaluati

16、on and Review Technique)叫做程序评估与审查技术，CPM方法叫做关键路径法，它们都是安排开发进度，制定软件开发方案的最常用的方法。,,它们都采用网络图来描述一个工程的任务网络，也就是从一个工程的开始到结束，把应当完成的任务用图或表的形式表示出来。,,1. 计算最早时刻,,2. 计算最迟时刻,,3. 关键路径,,4. 机动时间,32,,33,,通常用两张表来定义网络图。,,一张表给出与一特定软件工程有关的所有任务（也称为任务分解结构WorkBreakdownStructure）;,,另一张表给出应当按照什么样的次序来完成这些任务（有时称为限制表RestrictionLi

17、st）。PERT技术和CPM方法都为工程方案人员提供了一些定量的工具。,,确定关键路径，即决定工程开发时间的任务链。在关键路径上的各个任务都是时间余量为零的关键任务，不能有任何时间延误。,,应用统计模型，对每一个单独的任务确定最可能的开发持续时间的估算值。,,计算边界时间，以便为具体的任务定义时间窗口。,34,,35,,上述例如工程中各项任务的进度安排，可用Gantt图画出：（先安排关键路径上的任务）,路径优化,36,,人员组织,1.,开发人员,,2.,组织机构,,三种组织结构模式,,按课题划分的模式（,Project Format,）,,按职能划分的模式（,Functional Form

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

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

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

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

22、量和参加技术活动。 他直接领导二至三名高级程序员，每位高级程序员通过基层小组，管理若干位程序员。,,这种组织结构只允许必要的人际通信。比较适用于工程本身就是层次结构的课题。因为这样可以把工程按功能划分成若干个子工程，把子工程分配给基层小组，由基层小组完成。,,这种组织方式比较适合于大型软件工程的开发。,44,,45,,人员配备,,如何合理地配备人员，也是成功地完成软件工程的切实保证。所谓合理地配备人员应包括：,,按不同阶段适时任用人员,,恰当掌握用人标准。,,工程开发各阶段所需人员,,一个工程完成的快慢，取决于参与开发人员的多少,,在开发过程中，多数软件工程是以恒定人力配备的。,,实际人力需求

23、与开发进度的关系如以下图中的曲线所示。,,按此曲线，需要的人力随开发进展逐渐增加，在编码与单元测试阶段到达顶峰，以后又逐渐减少。,,如果恒定地配备人力，在开发初期将会有局部人力资源用不上而浪费掉。在开发中期，需要人力不够，造成进度的延误。在开发后期就需要增加人力以赶进度。,,恒定地配备人力将浪费人力资源。,46,,配备人员的原则,,重质量 软件工程是技术性很强的工作，要任用少量有实践经验、有能力的人员去完成关键性的任务。,,重培训 培养所需技术人员和管理人员是有效解决人员问题的好方法。,,双阶梯提升 人员提升应分别按技术职务和管理职务进行，不能混在一起。,47,,对工程经理人

24、员的要求,,软件经理人员是工作的组织者，他的管理能力的强弱是工程成败的关键。他应具有以下能力：,,把用户提出的非技术性要求加以整理提炼, 以技术说明书的形式转告给分析员和测试员。,,能说服用户放弃一些不切实际的要求, 以保证合理的要求得以满足。,,能够把外表上似乎无关的要求集中在一起, 归结为 “需要什么〞, “要解决什么问题〞。这是一种综合问题的能力。,,要懂得心理学, 能说服上级领导和用户，让他们理解什么是不合理的要求。但又要使他们毫不勉强, 乐 于接受，并受到启发。,48,,评价人员的条件,,软件工程中人的因素越来越受重视。在评价和任用软件人员时，必须掌握一定的标准。人员素质的优劣常

25、常影响到工程的成败。,,牢固掌握计算机软件的根本知识和技能。,,善于分析和综合问题，具有严密的逻辑思维能力。,,工作踏实、细致, 不靠碰运气，遵循标准和标准，具有严格的科学作风。,,工作中表现出有耐心、有毅力、有责任心。,,善于听取别人的意见，善于与周围人员团结协作，建立良好的人际关系。,,具有良好的书面和口头表达能力。,49,,软件配置管理,软件配置（,Software Configuration,）是软件产品在软件开发或运行过程中产生的全部信息。,,软件配置管理（,Software Configuration Management,）简称,SCM,，是在软件的整个生存周期内管理变更的一组

26、活动。,,软件配置管理,(Software Configuration Management,，简称,SCM),的四项任务,:,,(,１,),标识变更,,(,２,),控制变更,,(,３,),配置审计,,(,４,),配置状态报告,50,,软件配置管理概念,,软件开发过程的最终结果包括三类信息：,,计算机程序（源程序和目标程序）；,,描述程序的文档（面向技术人员和面向用户）；,,数据结构（包括程序内部和外部定义两局部）。,,组成上述信息的所有工程构成一个软件配置，其中每一项称为一个软件配置项（Software Configuration Item，简称SCI），它是配置管理的根本单位。一个SC中最

27、早的SCI是系统规格说明书。,,SCM要解决的主要问题就是保证软件的质量。,51,,基线技术,,基线（baseline）的原意是棒球场的边线，在软件开发过程中，为了有效地控制变动，软件配置管理引入基线的概念。,,IEEE组织对于基线的定义——“已经通过正式复审和批准的某规约或产品，它因此可以作为进一步开发的基础，并且只能遵循正式的变化控制过程得到改变〞。,,根据这个定义，基线标志软件开发过程的各个里程碑，任一SCI，一旦形成文档并复审通过，即成为一个基线，它标志开发过程中一个阶段的结束。对于已成为基线的SCI，虽然可以修改，但必须按照一个特殊的、正式的过程进行评估，确认每一处修改。相反，对于未

28、成为基线的SCI，可以进行非正式修改。,,某个SCI一旦成为基线，随即被放入工程数据库（project database）。此后，若开发小组中某位成员希望改动SCI，首先要将它拷贝到私有工作区并在工程数据库中锁住，不允许他人使用。在私有工作区中完成修改控制过程并复审通过之后，再把修改后的SCI推出并回送到工程数据库，同时解锁。,52,,一般软件配置需包括以下SCI：,,1．系统规格说明书,,2．软件工程规划,,3．需求分析结果,,1）软件需求规格说明书,,2）可执行的或“纸样〞原型,,4．初步用户手册,,5．设计规格说明书,,1）数据设计描述,,2）总体结构设计描述,,3）模块设计描述,,4）

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

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

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

32、数据模型〞,,“数据模型〞“设计规格说明书〞,,因一个配置对象可能与其他多个对象有关系，所以SCI的分层结构不一定是简单的树状结构，而是更一般的网状结构。,58,,版本控制,,为了适应不同环境特点和满足不同用户的个性需求，往往一个工程保存多个版本。,,配置管理的版本控制主要解决以下问题：,,1）根据不同用户的需要配置不同的系统；,,2）保存系统老版本，为以后调查问题使用；,,3）建立一个系统新版本，使它包含某些决策而抛弃另一些；,,4）支持两位以上工程师同时在一个工程中工作；,,5）高效存储工程的多个版本。,59,,版本控制系统都为配置对象的每个版本设置一组属性，这组属性既可以是简单的版本号，

33、也可以是一串复杂的布尔变量（即开关值），用以说明该版本功能上的变化。,,进化图可用于描述一个软件系统的不同版本。,,图中每个结点都是软件的一个完整版本，它由所有协调一致的软件配置项组成（源代码，文档和数据）。此外，一个版本还允许有多种变形（,Variant,）。,,例如，一个程序的某个版本由,A,、,B,、,C,、,D,、,E,五个部件组成，部件,D,仅在系统配有彩色显示器时使用，部件,E,则适用于单显，那么该版本就有两种变形，一种由,A,、,B,、,C,、,D,四个部件组成，另一种由,A,、,B,、,C,、,E,四个部件组成。,60,,61,,修改控制,,在大型软件开发过程中，无控制地修改会

34、迅速导致混乱。所谓修改控制，即把人的努力与自开工具结合起来，建立一套机制，有意识地控制软件修改。,,当一个“修改申请〞提出后，开发者依据技术指标和潜在的副作用，对其他配置对象和系统功能可能造成的影响以及工程本钱等诸多因素进行评估。评估的结果将形成一个“修改报告单〞，提交给修改控制机构(CCA)决策。,,CCA一旦同意修改，应立即提供一个“工程变动命令〞ECO（Engineering Change Order）。它指明修改任务、需遵守的限制和复审标准。然后从工程数据库中“提出〞待修改对象，经修改后再“推出〞更新版本。,,这一对动作是工程数据库访问控制和同步控制要求的。访问控制决定哪些人员有权访问

35、或修改某个配置对象；而同步控制则保证并行修改时不因互相重写而造成丧失修改。,62,,63,,软件开发人员根据ECO从工程数据库中提出待修改对象，访问控制机构，核实该开发人员是否有此特权，而同步控制机构则及时锁住待修改对象，不允许其他开发人员再做修改，直至该对象的新版本推出。加锁期间，其他工程人员仍可提取该对象的副本（称为提取版本）使用。,,上图所示的修改控制用于已交给用户的软件产品，称为正式修改控制。若欲修改的SCI虽已为基线版本，但尚未交付用户，此时修改控制称为工程级的修改控制，它除了不涉及用户外，其他步骤与正式的修改控制大致相同。若SCI并未成为基线版本，只需进行非正式的修改控制，则在不影

36、响系统需求的前提下，该SCI的开发者可随意改动,64,,变更控制过程,来自用户的,CR,工作量评估,递交,CR,表格,CCA,审查评估,CR,被否决,同意,CR，,给人员分配任务,SCM,检出配置项,更 改,审计并检入更改内容,建立基线测试，执行,QA,和测试活动,提交改变到下一个,Release,通知用户,构造适当的版本并审计所有配置项,新版本中引入变化，并发布该版本,65,,配置审计,,对于变更工作，必须通过正式的技术复审和软件配置审计工作来验证被核准进行变更的对象是否进行了必要的、正确的变更，并得到了重新的配置。,,正式的技术复审着重考虑所修改对象在技术上的正确性，复审人员应对该对象是

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

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

39、要的性质和特性的总体。,,（2）软件具有所期望的各种属性的组合程度。,,（3）顾客和用户觉得软件满足其综合期望的程度。,,（4）确定软件在使用中将满足顾客预期要求的程度。,,为保证软件充分满足用户要求而进行的有方案、有组织的活动称为软件质量保证，其目的是生产高质量的软件。,68,,软件质量的特性,软件质量是指软件满足明确规定或隐含定义的需求的程度。,,软件质量的要点：,,软件功能必须满足用户规定的需求；,,软件应遵守规定标准所定义的一系列开发准则；,,软件应满足某些隐含的需求。如，可理解性、可维护性等。,69,,软件质量的特性:,,功能性：软件的功能到达它的设计标准和能满足用户需求的程度,,可

40、靠性：在规定的时间和规定的条件下，软件能够实现所要求的功能的能力以及不引起系统失效的概率,,易使用性：用户学习、操作、准备输入和理解输出的难易程度,,效率：软件实现某种功能所需计算机资源的多少及执行其功能时使用资源的持续时间的多少,,可维护性：进行必要修改的难易程度,,可移植性：软件从一个计算机环境转移到另一个计算机环境下的运行能力,70,,软件质量保证措施,软件质量保证是软件工程管理的重要内容。,,,包括以下措施：,,应用好的技术方法,,测试软件,,进行正式的技术评审,,标准的实施,,控制变更,,程序正确性证明,,记录、保存和报告软件过程信息,71,,软件工程标准与软件文档,软件工程标准,

41、,软件工程标准化的定义,,对软件生存期内的所有开发、维护和管理工作逐步建立起标准,,,软件工程标准化的意义,,提高软件的可靠性、可维护性和可移植性；,,提高软件的生产率和软件人员的技术水平；,,提高软件人员之间的通信效率，减少过失和误解；,,有利于软件管理；,,有利于降低软件产品的本钱和运行维护本钱；,,有利于缩短软件开发周期。,72,,软件工程标准化的类型,,参照其它工程领域对工程标准划分的方法，软件工程标准主要有两种：按标准的类型划分和按标准的范围划分。,,(1) 按标准的类型划分,,主要有过程标准、产品标准、行业标准、记法标准等。,,过程标准与开发一个产品或从事一项效劳的一系列活动或操作

42、有关。过程标准使用一组方法、工具和技术，给出“谁来做〞、“做什么〞、“如何做〞、“何时做〞、“何地做〞及在软件工程活动中进行的不同层次工作的过程模型。,,产品标准则涉及软件工程事务的格式和内容。软件开发和维护活动文档化的结果就是软件产品，软件文档是软件工程活动进一步开展的基础。,,软件开发作为一种行业，其行业标准涉及软件工程的所有方面，如执业认证、职业培训、产品许可等。行业标准可以等同于行业行为标准。,,记法标准规定了在软件工程行业范围内，以唯一的方式进行交流的方法，如术语、表示法、语言等。,,(2) 按标准的范围划分,,主要是根据软件的任务功能和软件生存期进行比较、判定、评价和确定软件工程标

43、准的范围和内容。任务功能可以表示软件工程过程，可以划分为产品工程功能、验证与确认功能以及技术管理功能3个局部。,,产品工程功能包括定义、生产和支持最终产品所必须的过程。验证和确认功能是检查产品质量的活动。技术管理功能是构造和控制产品工程的过程。,,这3个局部并不集中在单个的软件生存周期里，而是并行进行的生产、检查和控制活动。,73,,根据以上两种分类方法，软件工程标准可用一张二维表格来表示。,74,,75,,上述两表给出了二维表的大致格式。其中，给出了GB/T 9385-1988、GB/T 1526-1989、GB/T 8566-1995这3个标准的例子，用于说明各个标准的类型及其作用。,,1

44、. GB/T 9385-1988是原电子工业部批准的《计算机软件需求说明编制指南》，用于指导软件需求规格说明书的编写。,,2. GB/T 1526-1989是国家标准总局批准的信息处理——数据流图、程序流程图、系统结构图、程序网络图、系统资源图的文件编制符号及约定。,,3. GB/T 8566-1995是国家标准总局批准的信息技术——软件生存期过程标准，它规定了在获取、供给、开发、操作、维护软件和固件的软件局部时，要实施的过程、活动和任务。目的是为用户提供一个公共的框架，使软件从业人员可以使用“相同的语言〞创作和管理软件。,76,,软件工程标准编制的层次,,根据软件工程标准制定的机构和标准适用

45、的范围，可分为5个层次：国际标准、国家标准、行业标准、企业(机构)标准、工程(课题)标准。,,1. 国际标准：由国际联合机构制定和公布的标准，供各国参考。,,如ISO——国际标准化组织。,,2. 国家标准：由政府或国家级的机构制定或批准，适用于全国范围。,,如GB——中国国标、ANSI_美国国家标准协会、BS——英国国家标准、JIS——日本工业标准。,,3. 行业标准：由行业机构、学术团体或国防等机构制定，适用于某个业务领域。,,如IEEE——美国电气和电子工程师学会、GJB——中国国家军用标准。,,4. 企业标准：企业因软件工程工作的需要制定的适用于本企业的标准。,,如IBM通用产品部于19

46、84年制定的《程序设计开发指南》。,,5. 工程标准：由某一科研生产工程组织制定，仅为该工程任务效劳的软件工程标准。,,如CIMS——计算机集成制造系统——软件工程标准。,77,,中国的软件标准,,1983年起，我国陆续制定和发布了20余项软件工程国家标准。这些标准可以分为以下四类：,,1. 基础标准：规定了信息加工处理和软件工程领域的术语、符号、表示、构造、分类级约定；,,2. 开发标准：规定了软件生存期过程、软件支持环境、软件记录处理流程、软件维护等的工作标准；,,3. 文档标准：规定了软件产品、需求、测试、管理等文档的编制标准；,,4. 管理标准：规定了软件配置管理方案、质量保证方案、产

47、品质量特性、软件可靠性和可维护性管理等的标准和工作要素。,,下表列出了我国局部软件工程标准的名称及其标准号：,78,,类型,标准名称,标准号,,基,,础,,标,,准,软件工程术语,GB/T 11457-1989,,信息处理,——,数据流程、程序流程图、系统结构图、程序网络图、系统资源图的文件编制符号及约定,GB/T 1526-1989,,软件工程标准分类法,GB/T 15538-1995,,信息处理,——,程序构造及其表示法的约定,GB/T 13502-1992,,信息处理,——,单命中判定表规范,GB/T 15535-1995(ISO 5806),,信息处理系统,——,计算机系统配置图符号及

48、其约定,GB/T 14085-1993(ISO 8790),开,,发,,标,,准,信息技术,——,软件生存期过程,GB/T 8566-1995,,软件支持环境,GB/T 15853-1995,,信息处理,——,按记录组处理顺序文卷的程序流程,GB/T 15697-1995(ISO 6593),,软件维护指南,GB/T 14079-1993,文,,档,,标,,准,计算机软件产品开发文档编制指南,GB/T 8567-1988,,计算机软件需求说明编制指南,GB/T 9385-1988,,计算机软件测试文档编制规范,GB/T 9386-1988,,软件文档管理指南,GB/T 16680-1996,管

49、,,理,,标,,准,计算机软件配置管理计划规范,GB/T 12505-1990,,信息技术,——,软件产品评价质量特性及其使用指南,GB/T 16260-1996,,计算机软件质量保证计划规范,GB/T 12504-1990,,计算机软件可靠性和可维护性管理,GB/T 14394-1993,79,,软件工程标准的制定与推行,,软件工程标准的制定与推行通常要经历一个环状生命周期，如以下图所示。从最初的制定一项标准的初步设想，经发起后，沿着环状生命期，顺时针经历以下步骤：,审核,修订,建议,开发,咨询,审批,公布,培训,实施,发起,撤销,80,,1. 建议——拟定初步的建议方案,,2. 开发——制

50、定标准的具体内容,,3. 咨询——征求并吸收有关人员的意见,,4. 审批——由管理部门决定能否推出,,5. 公布——公布发布，使标准生效,,6. 培训——为推行标准准备人员条件,,7. 实施——投入使用，需经历相当期限,,8. 审核——检验实施效果，决定修改或撤销,,9. 修订——修改其中不适当的局部，形成标准的新版本，进入新的周期,,事实上，几乎所有的标准都有一个逐步的成熟，在环状生命期上循环数次的经历，这就需要标准的制定者和使用者付出大量的劳动，来对标准加以完善。,81,,软件文档的分类,,国家标准局在1988年1月公布了《计算机软件开发标准》和《计算机软件产品开发文件编制指南》，作为软件

51、开发和文档编制工作的准则和规程。,,基于软件生存期方法，可以从形式上将软件文档大致分成两类：软件开发过程中需要填写的各种图表，及应编制的各种技术文件或管理资料。,,软件文档根据其产生和使用的范围，主要划分为3大类：开发文档、用户文档和管理文档。,软件文档,开发文档,用户文档,管理文档,可行性研究报告,工程开发方案,软件需求说明书,数据库设计说明书,概要设计说明书,详细设计说明书,用户手册,操作手册,软件需求说明书,数据要求说明书,工程开发方案,模块开发卷宗,开发进度月报,测试方案,测试分析报告,工程开发总结报告,82,,1. 开发文档,,开发文档主要负责对软件开发过程进行描述和标准。开发文档除

52、了前面列表的内容，还包括软件的详细技术描述，如程序逻辑、程序间相互关系、数据格式、存储等。,,开发文档主要可以发挥以下几个方面的作用：,,(1) 作为软件生存期个阶段之间的通信工具，记录生成软件需求、设计、编码、测试等的详细规定和说明；,,(2) 描述开发小组的工作职责。通过规定软件规划设计、主题脚本编制、文档编制、质量保证等人员的角色，来定义“如何做〞和“何时做〞；,,(3) 用作检验点，而允许管理者评估开发进度。如果开发文档缺失或过时，管理者将失去跟踪和控制软件工程的重要工具；,,(4) 形成系统维护人员所要求的根本的软件支持文档，并构成产品文档 的一局部；,,(5) 记录软件开发的历史。

53、,83,,2. 用户文档,,用户文档主要负责对软件产品的安装、配置、使用、维护等信息进行描述。包括系统安装配置手册、用户操作手册、软件需求说明书、数据要求说明书等。用户文档主要发挥以下作用：,,(1) 为使用和运行软件产品的用户提供培训和运行参考信息；,,(2) 为产品维护工程师提供必要的信息；,,(3) 促进和方便软件产品的市场推广。,,用户文档的提供通常可以包括以下形式：产品的市场宣传资料、适合管理者的产品指南和相关资料、提供给潜在用户的较深入的产品技术资料、产品使用所需的完整的操作和技术资料等。,,用户文档的涉众通常包括以下人员：一般潜在用户、具有决策权的潜在用户、最终用户、产品维护人员

54、等。,,最根本的用户文档通常包括以下几类：产品培训手册、产品操作手册、产品安装配置手册、产品支持手册、产品信息广告等。,,用户文档的分发按照涉众的类型j进行。不同类型的涉众可以获得不同的用户文档。用户文档在分发前应该制定适宜的分发策略和方案。,84,,3. 管理文档,,管理文档主要是对软件开发过程的管理信息进行描述。管理文档除了前面列表内容，还应该包括被管理者的反应信息，如各色表格、工作总结、开发体会、产品建议等。,,管理文档主要有以下主要：,,(1) 软件初期定义、规划、商务等与客户互动结果的记录；,,(2) 开发过程每个阶段的进度和进度变更的记录；,,(3) 软件开发人员的组织、管理和变更

55、的记录；,,(4) 软件需求、规划、设计等的变更控制的记录；,,(5) 开发过程发生的各种审查、审核、评估等情况的记录；,,(6) 验收、培训、移交、安装等相关工作的实施记录；,,(7) 维护需求的提出、认定、方案、实施等工作的记录。,85,,软件文档与使用者的关系,,,软件开发中产生的各类文档面向不同的用户，而软件用户应该得到的文档也在商业合同中有明确规定。,软件文档的使用对象,开发人员,维护人员,管理人员,用 户,可行性研究报告,工程开发方案,软件需求说明书,数据要求说明书,概要设计说明书,详细设计说明书,数据库设计说明书,测试方案,测试分析报告,设计说明书,测试分析报告,模

56、块开发卷宗,可行性研究报告,工程开发方案,模块开发卷宗,开发进度月报,工程开发总结报告,用户手册,操作手册,86,,软件文档编制与软件生存期的关系,,软件文档的编制是随着软件生存期各个阶段工作的开展而适时进行的。其中，有的仅反映某一阶段的工作，有的则需要跨越多个阶段的工作。,87,,软件文档最终需要答复读者关心的以下问题：,,1. 为什么要开发、维护或修改这个软件？(Why),,2. 工作目标要满足哪些需求？(What),,3. 需求应如何实现？(How),,4. 开发、维护或修改的工作应由谁来完成？(Who),,5. 开发工作的时间如何安排？(When),,6. 开发工作在什么环境中实现，所需信息从何而来？(Where),88,,89,,