北邮软件工程课件第12章控制.ppt

第12章控制,退出,一般说来，所谓控制就是掌握被控制的对象，不让它任意活动或超出规定范围活动，尽量使一切活动都按照预定的计划进行，向预期的目标前进。,12.1风险管理12.2质量保证12.3配置管理12.4小结,12.1风险管理,软件开发几乎总会存在某些风险。对付风险应该采取主动的策略，也就是说，早在技术工作开始之前就应该启动风险管理活动：标识出潜在的风险，评估它们出现的概率和影响，并且按重要性把风险排序，然后，软件项目组制定一个计划来管理风险。风险管理的主要目标是预防风险，但是，并非所有风险都能预防，因此，项目组还必须制定一个处理意外事件的计划，以便一旦风险变成现实时能够以可控的和有效的方式作出反应。,12.1.1软件风险分类风险有两个显著特点。不确定性：标志风险的事件可能发生也可能不发生，也就是说，没有100%发生的风险(100%发生的风险是施加在软件项目上的约束)。损失：如果风险变成了现实，就会造成不好的后果或损失。1.按照风险的影响范围分类(1)项目风险(2)技术风险(3)商业风险,2.按照风险的可预测性分类(1)已知风险(2)可预测的风险(3)不可预测的风险,12.1.2风险识别通过识别已知的和可预测的风险，项目管理者就朝着在可能时避免风险并且在必要时控制风险的目标迈出了第一步。在12.1.1节中描述的每一类风险又可进一步分成两种类型：一般性风险和特定产品的风险。一般性风险对每个软件项目都是潜在的威胁。特定产品的风险只有那些对当前项目的技术、人员、及环境非常了解的人才能识别出来。为了识别出特定产品的风险，必须检查项目计划和软件范围说明，并且回答下述问题：“本项目有什么特殊的性质可能会威胁我们的项目计划”。,事实上，“如果你不主动地攻击风险，风险将主动地攻击你”。因此，应该系统化地识别出一般性风险和特定产品的风险。采用建立风险条目检查表的方法，人们可以集中精力识别下列已知的和可预测的风险。产品规模与要开发或要修改的软件总体规模相关的风险。商业影响与管理或市场所施加的约束相关的风险。客户特性与客户素质以及开发者和客户定期通信的能力相关的风险。,过程定义与软件过程已被定义的程度以及软件开发组织遵守软件过程的程度相关的风险。开发环境与用来开发产品的工具的可用性和质量相关的风险。所用技术与待开发系统的复杂性及系统所包含的技术的“新奇性”相关的风险。人员数目与经验与参加工作的软件工程师的总体技术水平及项目经验相关的风险。,12.1.3风险预测风险预测(也称为风险估算)试图从两个方面来评估每个风险：风险变成现实的可能性或概率，以及当风险变成现实时所造成的后果。1.评估风险后果美国空军建议从性能、支持、成本和进度等四个方面评估风险的后果，他们把上述四个方面称为四个风险因素。下面给出这四个风险因素的定义。性能风险产品能满足需求且符合其使用目的的不确定程度。成本风险能够维持项目预算的不确定程度。,支持风险软件易于改错、适应和增强的不确定程度。进度风险能够实现项目进度计划且产品能按时交付的不确定程度。根据风险发生时对上述四个风险因素影响的严重程度，可以把风险后果划分成四个等级：可忽略的、轻微的、严重的和灾难性的。表121给出了由于软件中潜伏的错误所造成的各种后果的特点(由表中标为“1”的行描述)，或由于没有达到预期的结果所造成的各种后果的特点(由表中标为“2”的行描述)。按照实际后果与表中描述的特点的吻合程度，可以把风险后果划分成四个等级中的某一个。,2.建立风险表建立风险表是一种简单的风险预测技术，表12.2是风险表的一个例子。,表中第4列给出的是风险后果的整体等级值，其中，1代表灾难性的，2代表严重的，3代表轻微的，4代表可忽略的。一旦填好了风险表前4列的内容，就应该根据概率和影响来排序。高概率、高影响的风险放在表的上方，而低概率的风险放在表的下方，这样就完成了第一次风险排序。项目管理者研究排好序的风险表，并确定一条中止线。该中止线是经过表中某一点的水平直线，它的含义是，只有位于线的上方的那些风险才会得到进一步的关注。对于处于线下方的风险要再次评估，以完成第二次排序。,从管理的角度看，风险影响和风险概率的作用是不同的。对一个具有高影响但发生概率很低的风险因素，不应该花费太多管理时间。但是，高影响且发生概率为中到高的风险，以及低影响且高概率的风险，应该进入风险管理的下一个步骤。应该在软件项目进展的过程中，迭代使用上述的风险预测与分析技术。项目组应该定期复查风险表，再次评估每个风险，以确定新情况是否引起它的概率和影响发生变化。作为这项活动的结果，可能在表中添加了一些新风险，删除了某些与项目不再有关系的风险，并且改变了表中风险的相对位置。,12.1.4处理风险的策略对于绝大多数软件项目来说，上述的4个风险因素(性能、成本、支持和进度)都有一个临界值，超过临界值就会导致项目被迫终止。也就是说，如果性能下降、成本超支、支持困难或进度延迟(或这4种因素的组合)超过了预先定义的限度，则因风险过大项目将被迫终止。如果风险还没有严重到迫使项目终止的程度，则项目组应该制定一个处理风险的策略。一个有效的策略应该包括下述三方面的内容：风险避免(或缓解)；风险监控；风险管理和意外事件计划。,1.风险缓解如果软件项目组采用主动的策略来处理风险，则避免风险总是最好的策略。这可以通过建立风险缓解计划来达到。2.风险监控随着项目的进展，风险监控活动也就开始了。项目管理者监控某些能指出风险概率正在变高还是变低的因素。3.风险管理和意外事件计划风险管理和意外事件计划假设缓解风险的努力失败了，风险变成了现实。,12.2质量保证,质量是产品的生命，不论生产什么产品，质量都是极端重要的。软件产品开发周期长，耗费巨大的人力和物力，更必须特别注意保证质量。12.2.1软件质量概括地说，软件质量就是“软件与明确地和隐含地定义的需求相一致的程度”。更具体地说，软件质量是软件符合明确地叙述的功能和性能需求、文档中明确描述的开发标准、以及所有专业开发的软件都应具有的隐含特征的程度。上述定义强调了下述的三个要点。,软件需求是度量软件质量的基础，与需求不一致就是质量不高。指定的标准定义了一组指导软件开发的准则，如果没有遵守这些准则，几乎肯定会导致质量不高。通常，有一组没有显式描述的隐含需求(例如，期望软件是容易维护的)。如果软件满足明确描述的需求，但却不满足隐含的需求，那么软件的质量仍然是值得怀疑的。,下面介绍影响软件质量的主要因素，这些因素是从管理角度对软件质量的度量。可以把这些质量因素划分成三组，它们分别反映用户在使用软件产品时的三种不同倾向或观点。这三种倾向是：产品运行，产品修改和产品转移。图12.1描绘了软件质量因素和上述三种倾向(或称为产品活动)之间的关系，表12.3给出了软件质量因素的简明定义。,图12.1软件质量因素与产品活动的关系,12.2.2软件质量保证措施软件质量保证(SoftwareQualityAssurance，通常缩写为SQA)的措施主要有，基于非执行的测试(也称为复审)、基于执行的测试(即本书第5章和第9章讲述的测试)和程序正确性证明。1.技术复审的必要性正式技术复审的明显优点是，能够较早地发现错误，防止错误被传播到软件过程的后续阶段。正式技术复审实际上是一类复审方法，包括走查(Walkthrough)和审查(Inspection)等具体方法。走查的步骤比审查少，而且没有审查那样正规。,2.走查(1)参与者驱动法参与者按照事先准备好的列表，提出他们不理解的术语和认为不正确的术语。文档编写组的代表必须对每个质疑做出回答，要么承认确实有错误，要么对质疑做出解释。(2)文档驱动法文档编写者向走查组成员仔细解释文档。走查组成员在此过程中不时针对事先准备好的问题或解释过程中发现的问题提出质疑。这种方法可能比第一种方法更彻底，往往能检测出更多错误。经验表明，采用文档驱动法时许多错误是由文档讲解者自己发现的。,3.审查审查的范围要比走查广泛得多，它的步骤也比较多。一般来说，审查有5个基本步骤。综述：由负责编写文档的一名成员向审查组成员综述该文档。在综述会议结束时把文档分发给每位与会者。准备：评审员仔细阅读文档。最好列出在审查中发现的错误的类型，并按发生频率把错误类型分级，以辅助审查工作的进行。这些列表有助于评审员们把注意力集中到最常发生错误的区域。,审查：评审组仔细走查整个文档。和走查一样，这一步的目的也是找出文档中的错误，而不是改正它们。审查组组长必须在一天之内写出一份关于审查的报告。通常每次审查会不超过90分钟。返工：文档的作者负责解决在书面报告中列出的所有错误及问题。跟踪：组长必须确保所提出的每个问题都得到了圆满的解决(要么修正了文档，要么澄清了被误认为是错误的条目)。必须检查对文档所做的每个修正，以确保没有引入新的错误。如果在审查过程中返工量超过5%，则应该召集审查组再对文档全面地审查一遍。,4.程序正确性证明正确性证明的基本思想是证明程序能完成预定的功能。因此，应该提供对程序功能的严格数学说明，然后根据程序代码证明程序确实能实现它的功能说明。如果在程序的若干个点上，设计者可以提出关于程序变量及它们的关系的断言，那么在每一点上的断言都应该永远是真的。假设在程序的P1，P2，Pn等点上的断言分别是a(1)，a(2)，a(n)，其中a(1)必须是关于程序输入的断言，a(n)必须是关于程序输出的断言。,为了证明在点Pi和Pi+1之间的程序语句是正确的，必须证明执行这些语句之后将使断言a(i)变成a(i+1)。如果对程序内所有相邻点都能完成上述证明过程，则证明了输入断言加上程序可以导出输出断言。如果输入断言和输出断言是正确的，而且程序确实是可以终止的(不包含死循环)，则上述过程就证明了程序的正确性。,12.3配置管理,在开发计算机软件的过程中，变化(或称为变动)是不可避免的。如果不能适当地控制和管理变化，势必造成混乱并产生许多严重的错误。软件配置管理是在计算机软件整个生命期内管理变化的一组活动。具体地说，这组活动用来：标识变化；控制变化；确保适当地实现了变化；向需要知道这方面信息的人报告变化。,软件配置管理不同于软件维护。维护是在软件交付给用户使用后才发生的，而软件配置管理是在软件项目启动时就开始，并且一直持续到软件退役后才终止的一组跟踪和控制活动。软件配置管理的目标是，使变化更容易被适应，并且在必须变化时减少所需花费的工作量。,12.3.1软件配置1.软件配置项软件过程的输出信息可以分为三类：计算机程序(源代码和可执行程序)；描述计算机程序的文档(供技术人员或用户使用)；数据(程序内包含的或在程序外的)。上述这些项组成了在软件过程中产生的全部信息，我们把它们统称为软件配置，而这些项就是软件配置项。可以把软件配置管理看作是应用于整个软件过程的软件质量保证活动，是专门用于管理变化的软件质量保证活动。,2.基线基线是一个软件配置管理概念，它有助于我们在不严重妨碍合理变化的前提下来控制变化。IEEE把基线定义为：已经通过了正式复审的规格说明或中间产品，它可以作为进一步开发的基础，并且只有通过正式的变化控制过程才能改变它。简而言之，基线就是通过了正式复审的软件配置项。在软件配置项变成基线之前，可以迅速而非正式地修改它。一旦建立了基线之后，虽然仍然可以实现变化，但是，必须应用特定的、正式的过程(称为规程)来评估、实现和验证每个变化。,12.3.2软件配置管理过程软件配置管理是软件质量保证的重要一环，它的主要任务是控制变化，同时也负责各个软件配置项和软件各种版本的标识、软件配置审计以及对软件配置发生的任何变化的报告。具体来说，软件配置管理主要有五项任务：标识、版本控制、变化控制、配置审计和报告。,1.标识软件配置中的对象为了控制和管理软件配置项，必须单独命名每个配置项，然后用面向对象方法组织它们。可以标识出两类对象：基本对象和聚集对象(可以把聚集对象作为代表软件配置完整版本的一种机制)。每个对象都有一组能惟一地标识它的特征：名字、描述、资源表和“实现”。其中，对象名是无二义性地标识该对象的一个字符串。,图12.2演化图,2.版本控制版本控制联合使用规程和工具，以管理在软件工程过程中所创建的配置对象的不同版本。借助于版本控制技术，用户能够通过选择适当的版本来指定软件系统的配置。实现这个目标的方法是，把属性和软件的每个版本关联起来，然后通过描述一组所期望的属性来指定和构造所需要的配置。上面提到的“属性”，既可以简单到仅是赋给每个对象的特定版本号，也可以复杂到是一个布尔变量串(开关)，该布尔变量串指明了施加到系统上的功能变化的特定类型。,图12.3版本和变体,3.变化控制对于大型软件开发项目来说，无控制的变化将迅速导致混乱。变化控制把人的规程和自动工具结合起来，以提供一个控制变化的机制。变化控制过程如图12.4所示。,图12.4变化控制过程,图12.5访问和同步控制,4.配置审计为确保适当地实现了所需要的变化，我们从两方面采用措施：正式的技术复审；软件配置审计。正式的技术复审(见12.2.2节)关注被修改后的配置对象的技术正确性。复审者评估该配置对象以确定它与其他软件配置项的一致性，并检查是否有遗漏或副作用。软件配置审计通过评估配置对象的那些通常不在复审过程中考虑的特征，而成为对正式技术复审的补充5.状态报告配置状态报告是软件配置管理的一项任务，它回答下述问题：发生了什么事?谁做的这件事?这件事是什么时候发生的?它将影响哪些其他事物?,12.4小结,对于软件开发项目来说，控制是十分重要的管理活动。本章主要讲述了风险管理、质量保证和配置管理等三类软件工程控制活动。当对软件项目寄予较高期望时，通常都会进行风险分析。在识别、预测、评估、监控和管理风险等方面花费的时间和人力，可以从许多方面得到回报：项目进展过程更平稳；跟踪和控制项目的能力更强；由于在问题发生之前已经做了周密计划而产生的信心。,软件质量保证是在软件过程中的每一步都进行的“保护性活动”。软件质量保证措施主要有基于非执行的测试(也称为复审)、基于执行的测试(即通常所说的测试)和程序正确性证明。软件复审是最重要的软件质量保证活动之一，它的作用是，在改正错误的成本相对比较低时就及时发现并排除错误。,走查和审查是进行正式技术复审的两类具体方法。审查过程不仅步数比走查多，而且每个步骤都是正规的。由于在开发大型软件过程中所犯的错误绝大多数是规格说明错误或设计错误，而正式的技术复审发现这两类错误的有效性高达75%，因此是非常有效的软件质量保证方法。软件配置管理是应用于整个软件过程中的保护性活动，它是在软件整个生命期内管理变化的一组活动。,软件配置由一组相互关联的对象组成，这些对象也称为软件配置项，它们是作为某些软件工程活动的结果而产生的。除了文档、程序和数据这些软件配置项之外，用于开发软件的开发环境也可置于配置控制之下。一旦一个配置对象已被开发出来并且通过了复审，它就变成了基线。对基线对象的修改导致建立该对象的新版本。版本控制是用于管理这些对象而使用的一组规程和工具。变化控制是一种规程活动，它能够在对配置对象进行修改时保证质量和一致性。配置审计是一项软件质量保证活动，它有助于确保在进行修改时仍然保持质量。状态报告向需要知道关于变化的信息的人，提供有关每项变化的信息。,