管理篇 第四章 软件风险管理 什么是风险？ 风险分析 风险管理.

Presentation on theme: "管理篇 第四章 软件风险管理 什么是风险？ 风险分析 风险管理."— Presentation transcript:

1 管理篇 第四章 软件风险管理 什么是风险？ 风险分析 风险管理

2 4.1 什么是风险？ 由于软件的规模增大、复杂度增强、灵活性要求高而导致新一轮的软件危机，因此而引发软件的负面结论：
软件开发的效率和质量问题是经济增长的主要障碍。 软件失效造成巨大的经济损失。 用传统的软件工程技术来控制软件成本和质量也无法尽善尽美。 因此：软件风险是存在的，特别是对于大型复杂软件。 软件风险：是指软件有可能造成的伤害或者损失。

3 软件风险是任何软件开发项目中普遍存在的问题，与项目的大小成正比。
4.1 什么是风险？ 软件风险是任何软件开发项目中普遍存在的问题，与项目的大小成正比。 因为，在制定软件计划时，系统分析员必须回答： 项目的需求是什么？ 不可能准确无误地回答 需要投入多少资源？ 只能凭经验估计给出初步设想 如何安排开发进度？ 这样就存在风险！

4 4.1 什么是风险？ 常见的软件风险类别：进度、经费、性能、组织、管理、人事、过程、方法、工具等。如下例证： 进度过分紧迫； 预算过分紧张；
性能过分的超群，软件可靠性要求过高； 人员缺乏经验，组织结构不适宜； 期望过高而不现实； 没有明确或理解合同的条款； 软件规模估计不恰当； 管理部门缺乏经验； 风险分析和管理不恰当； 缺乏政策性支持； 不熟悉技术或过程； 不熟悉必要的硬件； 需求不一致（或定义不充分）； 需求不断变动； 软件开发计划不恰当； 软件开发过程模型不适用； 缺乏软件工程技术和方法； 缺乏自动化工具的支持；

5 4.2 风险分析 条件：软件的风险对于系统的成败有关键影响时才进行风险分析，因此，先要进行风险估计。 步骤：
标识潜在风险项：收集信息，标明相关的风险。观察风险的征兆，理解其原因。 估计每个风险的大小及其出现的可能性：度量风险的后果和严重程度。 风险评估：要考虑风险间的相互作用。

6 风险管理的本质：制定防止风险的计划，并监管风险。（风险是不可能消除的，只能防止） 风险管理的时机：
4.3 风险管理 风险管理的本质：制定防止风险的计划，并监管风险。（风险是不可能消除的，只能防止） 风险管理的时机： 已经发现存在重要的软件风险； 这些风险可能影响项目的目标； 这些风险将使系统花费大量的运行费用及支持费用； 这些风险是可能防止的。

7 4.3 风险管理 风险管理的任务： 制定风险计划：风险管理计划—RMP和风险排除计划—RA（version）P。
进行风险控制：执行风险计划中体现风险排除策略的控制机制。（确定风险排除策略；确定风险排除战术；建立风险管理计划。） 对风险进行监管：监管软件工程过程和产品，确定风险排除策略是否达到预期目标，是否有可能进一步改进风险排除计划，为控制新的风险提供一些必要的决策信息等。

8 管理篇 第五章 软件项目管理与计划 项目管理过程 软件度量 软件项目估算 软件开发成本估算 进度安排 软件项目的组织与计划

9 5.1 项目管理过程 项目管理的对象：软件工程项目，范围覆盖整个软件工程过程。
项目管理生命期：开始于技术工作启动之前，持续于软件分析、设计与实现过程中，最后终止于软件工程过程结束之时。 项目管理的过程：启动一个软件项目；软件度量；软件估算；风险分析；进度安排；追踪和控制。

10 5.2 软件度量 项目管理主要关心软件生产率和软件产品质量的度量。 软件工程过程度量属性：投入的成本和工作量。
软件产品度量属性：产生的代码行（LOC）、执行速度、存储量大小、周期报告错误数；功能性、复杂性、效率、可靠性、可维护性、和其它质量特性等。

11 5.2 软件度量 度量方法： 面向规模的度量：收集诸如工作量、投入成本、KLOC、文档页数、错误数、投入的人数，计算软件的生产率和质量。
面向功能的度量：收集软件数据域的一些计数度量，如用户输入数、用户输出数、用户查询数、文件数、外部接口数等，利用软件复杂性估计的经验关系式导出功能点。

12 5.2 软件度量 软件质量度量：广泛使用的事后度量（验收度量）包括： 正确性度量：每KLOC的差错数。
可维护性度量：平均变更等待时间（MTTC）以及故障损失。 完整性度量：从系统的危险性和安全性考虑。 可使用性度量：用户友好性（学习系统需要的技能、有效使用需要的时间、生产率净增值、用户主管评价）

13 5.2 软件度量 软件度量的目的：通过对软件生产率和软件质量进行度量，可以对软件提出要求和评价，进而可以建立改进软件工程过程的目标。
软件度量的使用： 使用软件度量建立项目基线； 收集项目当前的生产率和质量状态，利用基线对项目当前状态进行评价，并确定软件工程过程的改进目标。

14 5.3 软件项目估算 软件项目估算是项目计划活动的基础。 项目管理人员应该估算项目需要的资源、成本和工作量。
估算前要明确软件的范围，包括：功能、性能、限制、接口、可靠性，这些因素都影响资源、成本和工作量的估算。 资源：人力资源、硬件和软件资源等。 成本和工作量：先对问题进行分解，然后利用LOC和FP方法，结合基线生产率度量计算每个子功能的成本和工作量，集成后为整个项目的成本和工作量。

15 5.4 软件开发成本估算 软件开发成本：主要是指软件开发过程中所花费的工作量及相应的代价，不包括原材料和能源的消耗，主要是指人的劳动消耗。
估算的依据：从软件计划、需求分析、设计、编码、单元测试、集成测试和确认测试整个软件开发过程所花费的人工代价。

16 5.4 软件开发成本估算 基于分解和类推的估算方法：自顶向下、自底向上、差别估计等。 专家判定技术（Delphi）
经验模型：IBM模型、Putnam模型、COCOMO（Constructive Cost Model）模型

17 5.5 进度安排 合理分配人员的工作量和花费的时间，严密监控软件开发的进展情况，使软件开发进度不致拖延。 过程：
确定软件开发小组人数：人员之间的通信会影响软件生产率，因此，软件小组人数要适宜，一般在2～8人左右。

18 5.5 进度安排 确定任务及其并行性：确定任务之间的从属关系，确定各个任务的先后次序和衔接，确定各个任务完成的持续时间。从中抽取出关键路径。
制定开发进度计划：工作量和时间的分配。 一般：计划阶段占2%~3%； 需求分析占10%~25%; 软件设计占20%~25%; 编码占15%~20%； 测试和调试占30%~40%。

19 5.5 进度安排 用图示表达进度安排：明确标明各个任务的计划开始时间、完成时间；各个任务完成的标志；各个任务与参与工作的人数、各个任务与工作量之间的衔接情况；完成各个任务所需的物理资源和数据资源。 Gantt图、PERT和CPM 项目的追踪和控制

20 5.6 软件项目的组织与计划 制定计划：规定待完成的任务、要求、资源、人力和进度等。 建立项目组织：建立分工明确的责任制机构。
配备人员：任用各种层次的技术人员和管理人员。 指导：鼓励和动员软件人员完成所分配的工作。 检验：对照计划和标准监督并检查实施的情况。

21 管理篇 第六章 软件过程改进 CMM简介 CMM内容 CMM可视化分析 CMM内部结构 CMM应用 CMM的问题
CMM与ISO9000的区别 PSP/TSP

22 6.1 CMM简介 CMM是国际公认的对软件公司进行成熟度等级认证的重要标准。 CMM最早的工作开始于1986年11月，当时的情况：
 软件需求越来越大，所解决问题的复杂程度增长速度超过了人们开发和维护的能力。 产品不能如期交付；质量不能令用户满意；软件开发的开销超过了预算。 更好的软件开发技术也不能解决问题。 软件过程的管理

23 6.1 CMM简介 人们逐步认识到：软件开发中的个人因素并不是很重要，关键是软件开发机构的成熟程度。
卡内基－梅隆大学的SEI受美国国防部的委托和资助，评估软件供应商能力并帮助其改善软件质量，在Mitre公司的协助下，于1987年9月发布了能力成熟度框架以及一套成熟度问卷。四年后的1991年推出CMM1.0，1993年SEI又推出了CMM1.1，适用于500人以上规模的软件公司。近几年，SEI又推出了CMM2.0，同时进入ISO体系，称为ISO/IEC15504，即SPICE（软件过程改进能力评估）。

24 软件过程能力：描述在遵循一个软件过程后所期待结果的界限范围。 软件过程效果：描述在遵循一个软件过程后得到的实际结果。
6.1 CMM简介 软件过程能力：描述在遵循一个软件过程后所期待结果的界限范围。 软件过程效果：描述在遵循一个软件过程后得到的实际结果。 软件过程成熟度：指一个具体的软件过程被明确地定义、管理、度量、控制和实施的程度。 CMM中的软件过程包括：软件工程过程、软件管理过程、软件组织过程。

25 6.1 CMM简介 软件过程改进是持续的，因此，需要设计一个过程改进路线指导软件机构。
1.指导软件机构确定现在所处的能力成熟度等级； 2.确定提高软件质量和过程应该注意的关键问题； 3.选择过程改进策略。

26 6.1 CMM简介 CMM提供了一个结构框架，组织成五个成熟度级别，主要特征如下：
1.初始级：软件过程是杂乱无章甚至混乱的，几乎没有明确定义的的步骤，项目的成功依靠个人或核心人物的努力。 2.可重复级：建立了基本的项目管理过程来跟踪成本、进度和性能。有必要的过程准则来重复以前在同类项目的成功。 3.确定级：软件工程和管理过程已经文档化、标准化，并综合成整个软件开发组织的标准软件过程。针对具体项目裁减后用于实际的项目开发和维护中。 4.管理级：制定了软件产品和过程质量的详细度量标准。软件过程和产品的质量都被开发组织的成员所理解和控制。 5.优化级：根据过程执行的反馈信息以及新技术、新观念的吸纳来持续地改进和优化执行步骤，使企业的软件过程能不断持续地改进。

27 6.2 CMM内容

28 6.2 CMM内容 可重复级：在项目一级建立了过程管理条例和过程实施准则。
确定级：在全企业建立标准的软件过程，并由SEPG负责软件过程活动。 CMM管理级：对软件过程进行定量分析。 优化级：缺陷防范、主动技术变动管理、过程变动管理。

29 6.3 CMM可视化分析 CMM5个成熟度等级之间的差别主要反映在软件过程管理水平的高低上。进一步反映在软件过程提供管理信息的能力上。
管理信息取得决定于软件过程的可视性，即软件过程对于管理人员的透视性。 CMM中不同成熟度等级采纳了不同的管理方式，软件过程提供管理信息的能力也不同。

30 6.3 CMM可视化分析

31 6.4 CMM内部结构 为了在软件过程改进实践中体现CMM模型的可操作性，CMM给出了每一个成熟度级的详细结构规定。 实施保证 实施能力
实施活动 度量与分析 验证实现

32 6.5 CMM应用 CMM是标准：CMM建立了一个可用的标准描述，项目招标方与中标方签订合同时可以利用这些标准对风险进行评估。

33 6.5 CMM应用 软件过程评估 软件能力评价 关注于软件组织内部的软件过程，发现缺陷，提出改进的方向。
确定特定项目中的风险，包括合作者是否有能力按计划开发软件产品，以及是否能按预算完成等。

34 6.5 CMM应用 方法的特点： 考察中运用成熟度问题集作为出发点。 CMM为考察指引方向。 对照KPA发现差异，定义软件过程中的优缺点。

35 6.6 CMM的问题 CMM指明该做什么，但没有指明如何做，它不是方法论，没有给出特定应用领域内的专门技术。

36 6.7 CMM与ISO9000 共同点：强调了软件产品的质量。 不同点：
1.CMM是专门针对软件工业的，而ISO9001则面向所有工业。因此，相对而言，CMM更具体些，ISO9001更抽象些。 2.CMM是面向内部的软件过程改善框架，而ISO9001是供需关系下基于过程的质量需求，强调的是质量的衡量准则，没有告诉软件开发人员如何达到好的目标，如何避免差错。 3.CMM通过KPA中的关键实践活动的执行程度判断软件过程的能力成熟性；ISO9001针对合同环境下设计、开发、生产、服务等环节给出了所需要的最基本的质量要素，通过这些要素实施的有效程度判断企业是否符合要求。 4.CMM的结构是层次化的结构，由等级、KPA、公共属性、关键实践活动组成；ISO9001是简单的线性结构，包含20个质量要素。 5.在应用概念上，CMM强调企业内部素质，而ISO9001重在整体。实施CMM的最大益处是可以较大程度避免形式主义。

37 6.8 PSP/TSP CMM的成功与否与组织内部的相关人员的积极参与和创造性活动密不可分，而且CMM并未提供KPA关键实践活动实施所需要具备的具体知识和技能。 PSP（Personal Software Process）为基于个体和小型群组软件过程的优化提供了具体而有效的途径。 在设计阶段，PSP的着眼点在于软件缺陷的预防，具体办法是强化设计结束准则，而不是设计方法的选择。 PSP的研究结果表明：绝大多数软件缺陷是由于对问题的错误理解或简单的失误造成的，只有很少一部分是由于技术问题而产生的。因此，PSP保障软件产品质量的一个重要途径是提高设计质量。

38 6.8 PSP/TSP 实践证明，仅有PSP是不够的。CMM/SEI在PSP基础上发展出了TSP（Team Software Process）的方法。 TSP指导项目组中的成员如何有效地规划和管理所面临的项目开发任务，并且告诉管理人员如何指导软件开发队伍始终以最佳状态来完成工作。 TSP实施集体管理与自己管理自己相结合的原则，最终目的在于指导开发人员如何在最少的时间内，以预定的费用生产出高质量的软件产品，所采用的方法是对群组开发过程的定义、度量和改进。

39 6.8.1 PSP PSP提供了帮助软件工程师开发软件的表格、脚本和标准，以估算和计划软件工程师的工作，以便软件工程师可以更加清楚自己的个人技术并且提升个人表现。PSP显示了如何定义过程及如何测量其质量和生产率。 PSP用一系列的步骤解释个人软件过程的改进，每一步包含前一步所有元素并且有所增加。

40

41 6.8.2 TSP PSP3可以设计过万行的程序，但是仍然存在由程序导致的两个问题： 1)程序越大，个人花费的时间和精力越大；
2)软件工程师很难面面俱到地关心整个程序的所有方面，以致忽略某些“视觉盲点”的错误。 TSP通过大家共同分担这些问题来解决上述难题。也可以包括一些特殊的优化手段：定期找一个局外人来协助设计审查。 实施TSP应该具备的条件： 1)软件组织应该在CMM2； 2)全体开发人员应该经过PSP培训； 3)小组人数在2～20人之间。

42 6.8.2 TSP TSP方法实施集体管理和自己管理自己相结合的原则： 1)在每一阶段开始要作好工作计划；
2)要有明确定义的目标，努力完成已经接受的委托任务； 3)应定期追踪项目进展状态并进行定期汇报； 4)按自己管理自己的原则管理软件过程； 5)按集体管理的原则进行管理，全体成员都要参加和关心小组工作的规划、进展的追踪和决策的制订等项工作。 按照TSP原则进行管理，管理角色分成： 1)客户界面；2)设计方案；3)实现技术；4)工作规划；5)软件过程；6)产品质量；7)工程支持；8)产品测试。