软件工程13

第十三章管理技术(SoftwareManagement)经理管什么？计划预算组织进度标准§1.估算软件规模⑴静态：Effort=f(lengthofcode)(2)标准值法(ExpertJudgment)请多位专家估算程序的最小规模a，最可能的规模m，和最大规模b。以三组平均值估算程序规模：6bm4aL代码行技术LOC代码行数KLOC千行代码数功能点技术依据对软件信息域特性和软件复杂性的评估结果，估算软件规模。这种方法用功能点（FP）为单位度量软件规模1.信息域特性功能点技术定义了信息域的5个特性，分别是输入项数(Inp)、输出项数(Out)、查询数(Inq)、主文件数(Maf)和外部接口数(Inf)。下面讲述这5个特性的含义。功能点技术（1）输入项数：用户向软件输入的项数，这些输入给软件提供面向应用的数据。输入不同于查询，后者单独计数，不计入输入项数中。（2）输出项数：软件向用户输出的项数，它们向用户提供面向应用的信息，例如，报表和出错信息等。报表内的数据项不单独计数。（3）查询数：查询即是一次联机输入，它导致软件以联机输出方式产生某种即时响应。（4）主文件数：逻辑主文件（即数据的一个逻辑组合，它可能是大型数据库的一部分或是一个独立的文件）的数目。（5）外部接口数：机器可读的全部接口（例如，磁盘或磁带上的数据文件）的数量，用这些接口把信息传送给另一个系统。2.估算功能点的步骤用下述3个步骤，可估算出一个软件的功能点数（即软件规模）。（1）计算未调整的功能点数UFP首先，把产品信息域的每个特性(即Inp、Out、Inq、Maf和Inf)都分类为简单级、平均级或复杂级，并根据其等级为每个特性分配一个功能点数。然后，计算未调整的功能点数UFP：UFP=a1×Inp+a2×Out+a3×Inq+a4×Maf+a5×Inf其中，ai(1≤i≤5)是信息域特性系数，其值由相应特性的复杂级别决定（见书297页）。(2)计算技术复杂性因子TCF度量14种技术因素(297页）对软件规模的影响程度。根据软件的特点，为每个因素分配一个从0（不存在或对软件规模无影响）到5（有很大影响）的值。然后，用下式计算技术因素对软件规模的综合影响程度DI：DI=141iiF技术复杂性因子TCF由下式计算：TCF=0.65+0.01×DI因为DI的值在0-70之间，所以TCF的值在0.65-1.35之间。（3）计算功能点数FP用下式计算功能点数FP：FP=UFP×TCF功能点数与所用的编程语言无关，看起来功能点技术比代码行技术更合理一些。但是，在判断信息域特性复杂级别和技术因素的影响程度时，存在着相当大的主观因素。软件估算模型使用由经验导出的公式来预测软件开发工作量，工作量是软件规模（KLOC或FP）的函数，工作量的单位通常是人月（pm)。支持大多数估算模型的经验数据，都是从有限个项目的样本集中总结出来的，因此，没有一个估算模型可以适用于所有类型的软件和开发环境。§2工作量估算这类模型的总体结构形式如下：E=A+B×(ev)C其中，A、B和C是由经验数据导出的常数，E是以人月为单位的工作量，ev是估算变量（KLOC或FP）。下面给出几个典型的静态单变量模型。1.面向KLOC的估算模型(1)Walston_Felix模型E=5.2×(KLOC)0.91(2)Bailey_Basili模型E=5.5+0.73×(KLOC)1.16静态单变量模型(3)Boehm简单模型E=3.2×(KLOC)1.05(4)Doty模型（在KLOC9时适用）E=5.288×(KLOC)1.0472.面向FP的估算模型(1)Albrecht&Gaffney模型E=-13.39+0.0545FP(2)Maston,Barnett和Mellichamp模型E=585.7+15.12FP动态多变量模型也称为软件方程式。动态多变量估算模型的形式如下：E=(LOC×B0.333/P)3×(1/t)4其中，E是以人月或人年为单位的工作量；t是以月或年为单位的项目持续时间；动态多变量模型B是特殊技术因子，它随着对测试、质量保证、文档及管理技术的需求的增加而缓慢增加，对于较小的程序（KLOC=5-15），B=0.16,对于超过70KLOC的程序，B=0.39;P是生产率参数，它反映了下述因素对工作量的影响：总体过程成熟度及管理水平；使用良好的软件工程实践的程度；使用的程序设计语言的级别；软件环境的状态；软件项目组的技术及经验；应用系统的复杂程度。开发实时嵌入式软件时，P的典型值为2000；开发电信系统和系统软件时，P=10000；对于商业应用系统来说，P=28000。可以从历史数据导出适用于当前项目的生产率参数值。从（13.2）式可以看出，开发同一个软件（即LOC固定）的时候，如果把项目持续时间延长一些，则可降低完成项目所需的工作量。COCOMO2(ConstructiveCostModel):Boehm(1981,1997)171iifMM=a•KLOCb•Man-MonthSize=kilo-codeCostdriverinfo关于成本因素的详细讨论请看教材p.300-301§3.进度计划(SoftwarePlan)1、GanttCharttw12345678ABCD当前进度优点：简单，能动态地反映开发进展。缺点：难以反映多个任务间的逻辑关系。012345678codingAtestingAdebuggingABcodingtestingABC012356789codingAtestingAmodifyingCtestingBtestingCtestingABC4§2.进度计划2、PERT(ProgramEvaluation&ReviewTechnique)和CPM(CriticalPathMethod)例：开发三个模块A、B、C。A为公用模块，B、C的测试须等A的调试完成后进行。A的编码需6天，测试8天，调试6天。B的编码需7天，测试8天，调试6天。C利用已有的模块，须先理解原模块8天，再修改8天，测试9天，调试7天。最后三模块集成测试需5天完成。持续时间LastingTime机动时间SlackTime编号EarliestStartTimeLatestStartTime012345678941363029222014126006142082028293641(0)(0)(15)(4)(2)(4)(0)(2)(0)(2)(0)(0)686678886975(1)标出LastingTime(LT)(2)标出EST:=从起点始，所有进入事件的EST+LT中最大的(3)标出LST:=从终点(EST=LST)始，所有离开事件的LSTLT中最小的(4)标出ST:=终点LST起点ESTLT(5)标出CriticalPath:即EST=LST的所有事件组成的路径§2.进度计划§4.人员组织(Personnel)1、程序设计小组：2~8人的非正式组织优点：规模小，交流方便。缺点：没有明确的权威负责人，组员间缺乏必要的协调。ChiefProgrammerAssistantCPProgramManagerProgramManagerAdminis-trationLibrarianTestTeamSeniorProgrammerJuniorProgrammer全面负责设计、编码、测试和安装主要负责测试，必要时替代CP.负责和项目有关的全部事务性工作行政、后勤管理文档、工具管理提出具体测试方案，编写Driver和Stub,进行测试.后备编程力量2、主程序员组(ChiefProgrammerTeam)：BakerIBM,1972民主制程序员组的一个主要优点，是小组成员都对发现程序错误持积极、主动的态度。但是，使用主程序员组的组织方式时，主程序员对每行代码的质量负责，因此，他必须参与所有代码审查工作。由于主程序员同时又是负责对小组成员进行评价的管理员，他参与代码审查工作就会把所发现的程序错误与小组成员的工作业绩联系起来，从而造成小组成员出现不愿意发现错误的心理。现代程序员组现代程序员组的结构现代程序员组大型项目的技术管理组织结构包含分散决策的组织方式产品运行产品修改产品转移可理解性可维护性灵活性可测试性可移植性可重用性互操作性正确性健壮性效率完整性可用性奉献§5.质量保证(QualityAssurance)1、软件质量的定义：McCall’squalitymodel(1977)软件质量保证（softwarequalityassurance,SQA）的措施主要有：基于非执行的测试（也称为复审或评审），基于执行的测试（即以前讲过的软件测试）和程序正确性证明。复审主要用来保证在编码之前各阶段产生的文档的质量；基于执行的测试需要在程序编写出来之后进行，它是保证软件质量的最后一道防线；程序正确性证明使用数学方法严格验证程序是否与对它的说明完全一致。2.软件质量保证措施参加软件质量保证工作的人员，可以划分成下述两类：软件工程师通过采用先进的技术方法和度量，进行正式的技术复审以及完成计划周密的软件测试来保证软件质量。SQA小组的职责，是辅助软件工程师以获得高质量的软件产品。其从事的软件质量保证活动主要是：计划，监督，记录，分析和报告。简而言之，SQA小组的作用是，通过确保软件过程的质量来保证软件产品的质量。1.技术复审的必要性正式技术复审的显著优点是，能够较早发现软件错误，从而可防止错误被传播到软件过程的后续阶段。走查（walkthrough)审查（inspection）等2.走查走查组由4~6名成员组成。以走查规格说明的小组为例，成员至少包括一名负责起草规格说明的人，一名负责该规格说明的管理员，一位客户代表，以及下阶段开发组（在本例中是设计组）的一名代表和SQA小组的一名代表。其中SQA小组的代表应该作为走查组的组长。走查主要有下述两种方式：（1）参与者驱动法。参与者按照事先准备好的列表，提出他们不理解的术语和认为不正确的术语。文档编写组的代表必须回答每个质疑，要么承认确实有错误，要么对质疑做出解释。（2）文档驱动法。文档编写者向走查组成员仔细解释文档。走查组成员在此过程中不时针对事先准备好的问题或解释过程中发现的问题提出质疑。这种方法可能比第一种方法更有效，往往能检测出更多错误。经验表明，使用文档驱动法时许多错误是由文档讲解者自己发现的。3.审查5个基本步骤：（1）综述。由负责编写文档的一名成员向审查组综述该文档。在综述会结束时把文档分发给每位与会者。（2）准备。评审员仔细阅读文档。最好列出在审查中发现的错误的类型，并按发生频率把错误类型分级，以辅助审查工作。这些列表有助于评审员们把注意力集中到最常发生错误的区域。（3）审查。评审组仔细走查整个文档。（4）返工。文档的作者负责解决在审查报告中列出的所有错误及问题。（5）跟踪。组长必须确保所提出的每个问题都得到了圆满的解决（要么修正了文档，要么澄清了被误认为是错误的条目）。4.程序正确性证明测试只能证明程序中有错误，并不能证明程序中没有错误。程序正确性证明只证明程序功能是正确的，并不能证明程序的动态特性是符合要求的，此外，正确性证明过程本身也可能发生错误。正确性证明的基本思想是证明程序能完成预定的功能。因此，应该提供对程序功能的严格数学说明，然后根据程序代码证明程序确实能实现它的功能说明。在20世纪60年代初期，人们已经开始研究程序正确性证明的技术，提出了许多不同的技术方法。虽然这些技术方法本身很复杂，但是它们的基本原理却是相当简单的。如果在程序的若干个点上，设计者可以提出关于程序变量及它们的关系的断言，那么在每一点上的断言都应该永远是真的。假设在程序的P1,P2,…，Pn等点上的断言分别是a(1),a(2)，…，a(n)，其中a(1)必须是关于程序输入的断言，a(n)必须是关于程序输出的断言。为了证明在点Pi和Pi+1之间的程序语句是正确的，必须证明执行这些语句之后将使断言a(i)变成a(i+1)。如果对程序内所有相邻点都能完成上述证明过程，则证明