《软件设计师》复习笔记(12.3)——质量管理、风险管理
目录
一、质量管理
1. 质量定义
2. 质量管理过程
3. 软件质量特性(GB/T 16260-2002)
4. 补充知识
McCall质量模型:
软件评审
软件容错技术
真题示例:
二、风险管理
1. 风险管理的目的:
2. 风险管理流程及内容:
3. 项目风险定义与管理要点
4. 风险的属性
5. 风险分类
6. 信息系统风险类型
项目风险:
技术风险:
商业风险:
真题示例:
三、补充知识
项目的组织结构模式
程序设计小组的组织方式
真题示例:
一、质量管理
1. 质量定义
- 质量:软件产品满足明确(基本需求)或隐含(期望需求)要求的能力。
- 质量管理:通过质量计划、控制、保证和改进实现质量目标的管理活动。
2. 质量管理过程
过程 | 描述 |
---|---|
质量规划 | 识别项目质量要求和标准,书面描述如何达到这些标准。 |
质量保证 | 定期通过质量审计(如软件评审)和过程分析确保项目质量。 |
质量控制 | 实时监控结果是否符合质量标准,制定方案消除质量问题原因。 |
3. 软件质量特性(GB/T 16260-2002)
特性 | 子特性 | 定义 |
---|---|---|
功能性 | 适合性、准确性、互用性、依从性、安全性 | 与功能实现相关的属性(如正确性、安全性)。 |
可靠性 | 成熟性、容错性、易恢复性 | 在规定条件下维持性能的能力(如故障恢复)。 |
可用性 | 易理解性、易学性、易操作性 | 用户使用软件的难易程度(如界面友好性)。 |
效率 | 时间特性、资源特性 | 软件性能与资源消耗的关系(如响应速度)。 |
可维护性 | 易分析性、可修改性、稳定性、可测试性 | 修改软件的难易程度(如代码可读性)。 |
可移植性 | 适应性、易安装性、一致性、可替换性 | 软件跨环境运行的能力(如兼容性)。 |
4. 补充知识
McCall质量模型:
维度 | 子特性 |
---|---|
产品运行(product operations) | 正确性(correctness)、可靠性、易使用性、效率(efficiency)、完整性(integrity) |
产品修正(product revision) | 可维护性、灵活性(flexibility)、可测试性 |
产品转移(product transition) | 可移植性、复用性(reusability)、互用性 |
软件评审
阐述软件质量的两个必要条件:
- 设计质量:设计的规格说明书符合用户标准。
- 程序质量:程序按照设计规格说明书所规定的情况正确执行。
软件容错技术
介绍了软件容错的概念及实现容错的主要手段——冗余,具体包含四种冗余技术:
- 结构冗余:分为静态、动态、混合冗余三种,在错误发生时对错误进行备份处理。
- 信息冗余:为检错和纠错,在数据中加上一段额外的信息,比如校验码原理。
- 时间冗余:遇到错误时重复执行,像回滚操作,若重复执行后仍有错误,则转入错误处理逻辑。
- 冗余附加技术:指实现结构、信息和时间冗余技术所需的资源和技术,涵盖程序、指令、数据、存放和调动它们的空间和通道等,在屏蔽硬件错误的容错技术中存在应用 。
真题示例:
软件质量保证是软件项目控制的重要手段,( )是软件质量保证的主要活动之一。
A. 风险评估 B.软件评审 C.需求分析 D.架构设计
软件评审(Software Review)是软件质量保证(SQA)的核心活动之一,通过系统化的检查(如代码审查、设计评审等)发现缺陷,确保符合质量标准。其他选项:
- 风险评估:属于风险管理范畴
- 需求分析:是需求工程阶段的活动
- 架构设计:是设计阶段的任务
ISO/IEC软件质量模型中,易使用性是指与使用所需的努力由一组规定或隐含的用户对这样使用所作的个别评价有关的一组属性,其易使用性的子特性不包括( )。
A、易理解性 B、易学性 C、易分析性 D、易操作性
ISO/IEC 9126 质量模型中,易使用性(Usability)的子特性包括:
- 易理解性(用户快速理解软件功能)
- 易学性(用户学习使用的难易程度)
- 易操作性(用户操作和控制的便利性)
易分析性属于可维护性(Maintainability)的子特性,与故障诊断和修复相关,因此不属于易使用性。
二、风险管理
1. 风险管理的目的:
对项目风险进行认真分析和科学管理,以避开不利条件、减少损失、实现项目目标,虽不能完全避开或消除风险以及只享受权益不承担风险,但可争取避免风险发生或减小风险发生后的影响。
2. 风险管理流程及内容:
- 风险管理计划编制:规划如何安排与实施项目的风险管理,制定相关步骤计划。
- 风险识别:找出项目中已知和可预测的风险,明确风险来源、产生条件、描述风险特征以及确定哪些项目环节会产生风险,形成风险列表。
- 风险定性分析:对已识别的风险进行排序,确定风险可能性与影响程度、优先级以及风险类型。
- 风险定量分析:进一步精准了解风险发生的可能性大小和后果严重程度,方法包括灵敏度分析、期望货币价值分析、决策树分析、蒙特卡罗模拟等。
- 风险应对计划编制:针对每个识别出的风险分别制定应对措施,这些措施形成的文档即风险应对计划,其中消极风险应对策略有避免、转移、减轻;积极风险应对策略有开拓、分享、强大。
- 风险监控:监督风险计划的执行情况,检测残余风险,识别新风险,确保风险计划得以执行,并评估这些计划在减少风险方面的有效性。
3. 项目风险定义与管理要点
- 定义:项目风险是作用于项目上的不确定事件或条件,可能产生威胁,也可能带来机会。
- 管理理念:
- 通过积极合理的规划,超90%的风险可提前应对和管理。
- 风险应尽早识别,高层次风险需记录在章程里。
- 由对风险最具控制力的一方承担相应风险。
- 遵循承担风险程度与所得回报相匹配原则,且承担的风险要有上限。
4. 风险的属性
- 随机性:风险事件的发生及其后果都具有偶然性,即双重偶然,但遵循一定的统计规律。
- 相对性:风险是相对项目活动主体而言的。不同主体对风险的承受力不同,影响也不同。风险承受力受以下因素影响:
- 收益大小:收益越大,越愿意承担风险。
- 投入大小:投入越大,承受能力越小。
- 主体的地位和资源:级别高的人能承担较大的风险。
- 可变性:当条件发生变化时,会引起风险的变化,包括风险性质、后果的变化,以及出现新风险 。
5. 风险分类
分类依据 | 类型 |
---|---|
后果 | 纯粹风险(无收益)、投机风险(可能收益)。 |
来源 | 自然风险(天灾)、人为风险(行为/经济/技术/政治)。 |
可管理性 | 可管理(内部)、不可管理(外部政策)。 |
影响范围 | 局部风险(非关键路径)、总体风险(关键路径)。 |
可预测性 | 已知风险(进度延迟)、可预测风险(服务器故障)、不可预测风险(地震)。 |
6. 信息系统风险类型
-
项目风险:
- 涵盖潜在的预算、进度、人员及组织、资源、用户和需求等方面的问题,项目的复杂性、规模和结构的不确定性也属于风险因素。它对项目计划构成威胁,一旦发生,可能导致项目进度拖延、成本增加。
-
技术风险:
- 涉及潜在的设计、实现、接口、测试和维护问题,规格说明的多义性、技术不确定性、技术陈旧、新技术不成熟等也是风险因素。会威胁到待开发系统的质量和预定交付时间,若成为现实,开发工作可能变得困难甚至无法进行。
-
商业风险:
- 对待开发系统的生存能力构成威胁,主要有以下五种:
- 市场风险:开发的系统不符合市场真正需求。
- 策略风险:开发的系统与企业信息系统战略不符。
- 销售风险:销售部门不清楚如何推销所开发的系统。
- 管理风险:因重点转移或人员变动失去上级管理部门支持。
- 预算风险:开发过程缺乏预算或人员保障。
真题示例:
以下关于软件风险的叙述中,不正确的是( )
A、风险是可能发生的事件
B、如果发生风险,风险的本质、范围和时间可能会影响风险所产生的后果
C、如果风险可以预测,可以避免其发生
D、可以对风险进行控制
- A、B、D选项均正确描述了风险的基本特性:
- 风险本质上是可能发生的事件
- 风险的后果受其本质、范围和时间影响
- 风险可通过管理手段进行控制
- C选项:
即使风险可预测,也只能通过应对策略(如避免、减轻、转移等)降低影响,但无法保证完全避免发生。例如,可预测"关键人员离职风险",但无法彻底避免离职行为。
以下叙述中,( )不是一个风险。
A. 由另一个小组开发的子系统可能推迟交付,导致系统不能按时交付客户
B. 客户不清楚想要开发什么样的软件,因此开发小组开发原型帮助其确定需求
C. 开发团队可能没有正确理解客户的需求
D. 开发团队核心成员可能在系统开发过程中离职
- A、C、D选项均为典型风险:
- 外部依赖导致的进度风险
- 需求理解偏差风险
- 人力资源风险
- B选项:
开发原型是应对需求不明确的解决方案(需求获取手段),而非风险本身。原描述中"因此"表明这是主动采取的措施,而非潜在负面事件。
三、补充知识
项目的组织结构模式
- 项目型:以项目经理为绝对领导核心的组织结构模式。
- 职能型:以部门领导为主导的组织结构模式。
- 矩阵型:融合了项目型和职能型的特点,既存在项目经理也有部门领导,只是二者权力分割情况有所不同。
程序设计小组的组织方式
- 主程序员制小组:主程序员拥有全权负责的权力,后援工程师在必要时能够替代主程序员开展工作,这种组织方式适合大规模项目。
- 民主制小组:也叫无主程序员小组,小组成员之间地位平等,任何决策都需要全员参与投票,适用于项目规模小、开发人员少,且采用新技术和确定性较小的项目。
- 层次式小组:具有两个层次,一名组长领导若干个高级程序员,每个高级程序员又领导若干个程序员 。
真题示例:
在进行软件开发时,采用无主程序员的开发小组,成员之间相互平等;而主程序员负责制的开发小组,由一个主程序员和若干成员组成,成员之间没有沟通。在一个由8名开发人员构成的小组中,无主程序员组和主程序员组的沟通路径分别是( )。
A.32和8 B.32和7 C.28和8 D.28和7
无主程序员组中成员之间相互平等,即任意两个成员之间都存在沟通路径,这种沟通模式可看作是一个完全连通图的形式。 |
主程序员负责制的开发小组由一个主程序员和若干成员组成,成员之间没有沟通,只有成员与主程序员进行沟通。 这意味着沟通路径是主程序员与其他 n−1 个成员之间的连接,所以沟通路径数量为 n−1 条。 |