软件工程 第4版 教学课件 ppt 作者 张海藩 吕云翔 编著 13

《软件工程 第4版 教学课件 ppt 作者 张海藩 吕云翔 编著 13》由会员分享，可在线阅读，更多相关《软件工程 第4版 教学课件 ppt 作者 张海藩 吕云翔 编著 13（123页珍藏版）》请在金锄头文库上搜索。

1、北航软件学院 吕云翔,第十三章 控制,通过软件计划，我们明确了软件开发的目标，规划了具体的开发方案，而组织职能的实施又为计划的实现提供了组织机构和资源配置方面的保证。但是，计划规定的目标再好，人员组织得再合理，如果没有有效的控制作为保证，软件开发目标也是难以实现的。因此，控制是十分重要的管理活动。,引言,引言,一般说来，所谓控制就是掌握被控制的对象，不让它任意活动或超出规定范围活动，尽量使一切活动都按照预定的计划进行，向预期的目标前进。 本章结合软件开发的特点，着重讲述软件风险管理、质量保证和配置管理。,13.1 风 险 管 理,13.1.1 软件风险分类 13.1.2 风险识别 13.1.3

2、 风险预测 13.1.4 处理风险的策略,13.1.1 软件风险分类,风险有两个显著特点。 不确定性：标志风险的事件可能发生也可能不发生，也就是说，没有100%发生的风险（100%发生的风险是施加在软件项目上的约束）。 损失：如果风险变成了现实，就会造成不好的后果或损失。 分析风险时，重要的是量化不确定性的程度及与每个风险相关的损失程度。,13.1.1 软件风险分类,1按照风险的影响范围分类 （1）项目风险 （2）技术风险 （3）商业风险,13.1.1 软件风险分类,（1）项目风险 这类风险威胁项目计划，也就是说，如果这类风险变成现实，可能会拖延项目进度并且增加项目成本。项目风险是指预算、进度

3、、人力、资源、客户及需求等方面的潜在问题和它们对软件项目的影响。项目复杂程度、规模以及结构不确定性也是项目风险因素。,13.1.1 软件风险分类,（2）技术风险 这类风险威胁软件产品的质量和交付时间。技术风险是指设计、实现、接口、验证、维护等方面的潜在问题。此外，规格说明的二义性、技术的不确定性、技术陈旧和“前沿”技术也是技术风险因素。一般说来，存在技术风险是因为问题比我们设想的更难解决。,13.1.1 软件风险分类,（3）商业风险 正在开发一个没有人真正需要的“优秀产品”（市场风险）。 正在开发一个不再符合公司的整体商业策略的产品（策略风险）。 正在开发一个销售部门不知道如何去卖的产品。,1

4、3.1.1 软件风险分类, 由于重点转移或人事变动而失去了高级管理层的支持（管理风险）。 没有获得预算或人力上的保证（预算风险）。,13.1.1 软件风险分类,2按照风险的可预测性分类 （1）已知风险 （2）可预测的风险 （3）不可预测的风险,13.1.1 软件风险分类,（1）已知风险 这类风险是通过仔细评估项目计划、开发项目的商业和技术环境，以及其他可靠的信息（如不现实的交付日期，没有描述需求或软件范围的文档存在，恶劣的开发环境），可以发现的那些风险。,13.1.1 软件风险分类,（2）可预测的风险 这类风险可以从过去项目的经验中推测出来（如人员变动，缺乏与客户的沟通，因忙于维护工作而减少开

5、发人员）。 （3）不可预测的风险 这类风险可能而且确实会出现，但是很难事先识别出它们。,13.1 风 险 管 理,13.1.1 软件风险分类 13.1.2 风险识别 13.1.3 风险预测 13.1.4 处理风险的策略,13.1.2 风险识别,通过识别已知的和可预测的风险，项目管理者就朝着在可能时避免风险并且在必要时控制风险的目标迈出了第一步。 事实上，“如果你不主动地攻击风险，风险将主动地攻击你”。因此，应该系统化地识别出一般性风险和特定产品的风险。,13.1.2 风险识别, 产品规模与要开发或要修改的软件总体规模相关的风险。 商业影响与管理或市场所施加的约束相关的风险。 客户特性与客户素质

6、以及开发者和客户定期通信的能力相关的风险。 过程定义与软件过程已被定义的程度以及软件开发组织遵守软件过程的程度相关的风险。,13.1.2 风险识别, 开发环境与用来开发产品的工具的可用性和质量相关的风险。 所用技术与待开发系统的复杂性及系统所包含的技术的“新奇性”相关的风险。 人员数目与经验与参加工作的软件工程师的总体技术水平及项目经验相关的风险。,13.1.2 风险识别,1产品规模风险 是否用LOC或FP估算产品规模？ 估算出的产品规模的可信度如何？ 是否用程序、文件或事务的数目来估算产品规模？ 产品规模与以前产品平均规模相差的百分比是多少？,13.1.2 风险识别, 产品创建或使用的数据库

7、的规模有多大？ 产品的用户数有多少？ 产品需求变动数有多少？产品交付前有多少个变动？交付后有多少个变动？ 重用的软件量有多大？,13.1.2 风险识别,2商业风险 本产品对公司收入有何影响？ 本产品是否受到高级管理层的重视？ 交付期限是否合理？ 打算使用本产品的客户数及本产品符合他们需要的程度？ 本产品必须能够与之互操作的其他产品的数目？, 终端用户的水平如何？ 必须生成并交付给客户的产品文档的质与量如何？ 政府对产品开发的约束？ 延迟交付将使成本增加多少？ 产品缺陷将使成本增加多少？,13.1.2 风险识别,3与客户相关的风险 你以前是否与这个客户合作过？ 该客户对需要什么是否有固定想法？他

8、已经把需求写下来了吗？ 该客户是否同意花时间召开正式的需求收集会，以确定项目范围？ 该客户是否愿意建立与开发者之间的快速通信渠道？,13.1.2 风险识别, 该客户是否愿意参加复审工作？ 该客户是否具有该产品领域的技术素养？ 该客户是否放手让开发人员工作，也就是说，当你们做具体技术工作时该客户是否坚持要在旁边监视？ 该客户是否理解软件过程？,13.1.2 风险识别,4过程风险 （1）过程问题 （2）技术问题,13.1.2 风险识别,（1）过程问题 高级管理层认识到标准的软件开发过程的重要性了吗？ 你的公司是否已经写好了用于本项目的软件过程说明？ 开发人员是否愿意按照文档中描述的软件过程进行开发

9、工作？ 该软件过程是否用于其他项目？,13.1.2 风险识别, 你的公司是否已经为管理人员和技术人员开设了一系列软件工程培训课程？ 是否为每位软件开发者和管理者都提供了书面的软件工程标准？ 是否已经为软件过程中定义的所有交付物建立了文档提纲和示例？ 是否定期地对需求规格说明、设计和代码进行正式的技术复审？,13.1.2 风险识别, 是否每次正式技术复审的结果（含发现的错误和使用的资源）都建立了文档？ 是否有某种机制来保证项目开发工作符合软件工程标准？ 是否使用了配置管理来保持软件需求、设计、代码和测试用例之间的一致性？,13.1.2 风险识别, 是否使用了某种机制来控制影响软件的用户需求变化？

10、 对于每份子合同，是否都有文档化的工作说明、软件需求规格说明及软件开发计划？ 是否有一个过程用来跟踪和复审子合同执行情况？,13.1.2 风险识别,（2）技术问题 是否使用了简易的应用规格说明技术来辅助开发者与客户之间的通信？ 是否使用了特定的方法进行软件分析？ 是否使用了特定的方法进行数据和体系结构设计？ 是否90%以上的代码都使用高级语言编写？,13.1.2 风险识别, 是否定义并使用了特定的代码文档规则？ 是否使用了特定的方法来设计测试用例？ 是否使用了软件工具来支持计划和跟踪活动？ 是否使用了配置管理工具来控制和跟踪软件过程中的变动活动？,13.1.2 风险识别, 是否使用了软件工具来

11、支持软件分析和设计过程？ 是否使用了软件工具来创建软件原型？ 是否使用了软件工具来支持测试过程？ 是否使用了软件工具来支持文档的生成与管理？,13.1.2 风险识别, 是否收集了所有软件项目的质量度量值？ 是否收集了所有软件项目的生产率度量值？,13.1.2 风险识别,5技术风险 将使用的技术对于你的组织而言是新的吗？ 为满足客户需求是否需要创造新的算法或输入/输出技术？ 软件是否需要与新的或未经验证的硬件接口？ 软件是否需要与别的开发商提供的未经验证的软件产品接口？,13.1.2 风险识别, 软件是否需要与功能和性能都未在本应用领域得到验证的数据库系统接口？ 产品需求中是否要求采用特殊的用户

12、界面？ 产品需求中是否要求创建与你的组织以前开发过的构件不同的程序构件？ 用户需求中是否要求使用新的分析、设计或测试方法？,13.1.2 风险识别, 用户需求中是否要求使用非常规的软件开发方法（如形式化方法、基于人工智能技术的方法、人工神经网络）？ 用户需求中是否对产品性能有过分的约束？ 客户是否不能断定其要求的功能是“可行的”？,13.1.2 风险识别,6开发环境风险 是否有可用的软件项目管理工具？ 是否有可用的软件过程管理工具？ 是否有可用的分析和设计工具？ 分析和设计工具是否支持适用于所开发产品的方法？ 是否有可用的编译器或代码生成器，且适用于所开发的产品？,13.1.2 风险识别, 是

13、否有可用的测试工具，且适用于所开发的产品？ 是否有可用的软件配置管理工具？ 环境是否利用了数据库或数据仓库？ 是否所有软件工具都已经集成在一起了？,13.1.2 风险识别, 项目组成员是否已经接受过使用每件工具的培训？ 本地是否有专家能回答关于工具的问题？ 关于工具的联机帮助和文档是否是恰当的？,13.1.2 风险识别,7人员风险 是否有最优秀的人才可用？ 人员在技术上是否配套？ 是否有足够人员可用？ 开发人员能否自始至终地参加整个项目的工作？,13.1.2 风险识别, 项目组成员是否都能全部时间参加工作？ 开发人员对自己的工作是否有正确的期望？ 开发人员是否已接受了必要的培训？ 开发人员的流

14、动是否不影响工作的连续性？,13.1 风 险 管 理,13.1.1 软件风险分类 13.1.2 风险识别 13.1.3 风险预测 13.1.4 处理风险的策略,13.1.3 风险预测,风险预测（也称为风险估算）试图从两个方面来评估每个风险：风险变成现实的可能性或概率，以及当风险变成现实时所造成的后果。,13.1.3 风险预测,1评估风险后果 性能风险产品能满足需求且符合其使用目的的不确定程度。 成本风险能够维持项目预算的不确定程度。 支持风险软件易于改错、适应和增强的不确定程度。 进度风险能够实现项目进度计划且产品能按时交付的不确定程度。,13.1.3 风险预测,根据风险发生时对上述4个风险因

15、素影响的严重程度，可以把风险后果划分成4个等级：可忽略的、轻微的、严重的和灾难性的。,13.1.3 风险预测,2建立风险表 建立风险表是一种简单的风险预测技术。首先在表中第1列列出所有风险，在风险表的第2列中给出每个风险的类型（PS代表产品规模风险，BU代表商业风险，CU代表与客户相关的风险，TE代表技术风险，DE代表开发环境风险，ST代表人员风险）。,13.1.3 风险预测,每个风险发生的概率写在第3列中。每个风险发生的概率值可以先由项目组各个成员分别估算，然后把这些值求平均，得到有代表性的一个概率值。下一步是评估每个风险所造成的后果。对4个风险因素（性能、支持、成本和进度）的等级值求平均，以得到风险后果的整体等级值（如果某个风险因素对项目特别重要，也可以使用加权平均值）。,表中第4列给出的是风险后果的整体等级值，其中，1代表灾难性的，2代表严重的，3代表轻微的，4代表可忽略的。,13.1.3 风险预测,一旦填好了风险表前4列的内容，就应该根据概率和影响来排序。高概率、高影响的风险放在表的上方，而低概率的风险放在表的下方，这样就完成了第1次风险排序。,13.1.3 风险预测,项目管理者研究排好序的风险表，并确定一条中止线。该中止线是经过表中某一点的水平直线，它的含义是，只有位于线的上方的那些风险才会得到进一步的关注。对于处于线下