【现代软件工程】第九章-优快云博客

本文链接：https://blog.youkuaiyun.com/m0_62761621/article/details/131185346

现代软件工程第九章

软件项目管理

软件项目管理

软件质量保证

质量的死对头是缺陷（defect,bug…），缺陷是混在产品中的人们不喜欢、不想要的东西，它对产品没有好处只有坏处。缺陷越多质量越低，缺陷越少质量越高，提高软件质量的基本手段是消除软件缺陷

消除软件缺陷的三种方式

提高软件质量最好的办法是：在开发过程中有效地防止工作成果产生缺陷，将高质量内建于开发过程之中。主要措施是“不断地提高技术水平，不断地提高规范化水平”，其实就是练内功，通称为“软件过程改进”。
当工作成果刚刚产生时马上进行质量检查，及时找出并消除工作成果中的缺陷。这种方式效果比较好，人们一般都能学会。最常用的方法是技术评审、软件测试和过程检查，已经被企业广泛采用并取得了成效。
典型现象是：在软件交付之前，没有及时消除缺陷。当软件交付给用户后，用着用着就出错了，赶紧请开发者来补救。

软件质量

应用有效的软件过程，创造有用的产品，为生产者和使用者提供明显的价值。

有效的软件过程为生产高质量的软件产品奠定了基础，能够使得软件开发过程变得有序。
有用的产品是指交付最终用户要求的内容、功能和特征，满足利益相关者明确提出的需求和其它隐性需求（例如，易用性）。
高质量软件为软件组织和最终用户群体带来收益。

McCall的质量因素

在这里插入图片描述
**正确性：**程序满足需求规格说明和完成用户任务目标的程度。
可追踪性：从一个设计表示或实际程序追踪到需求的能力。
完备性：所需功能完全实现的程度
一致性：设计文档与系统实现的一致性。
可靠性：程序以所要求的精度完成预期功能的程度。
准确性：计算和控制的精度
容错性：在各种异常条件下继续提供操作的能力
与正确性的区别：正确性：它按我的需要工作吗？可靠性：在任何时候它都能适当地响应吗？
完整性：对未授权人员访问软件或数据的可控程度。
易用性（易培训性）：对程序学习、操作、准备输入和解释输出所需要的工作量
效率：程序完成其功能所需的资源：计算效率，存储效率

可维护性：定位和修复程序中的一个错误所需要的工作量
简单性：理解程序的难易程度
简明性：程序源代码的紧凑与简洁性
检测性：系统能监视自身的运行，一旦发生错误，能明确地标识出产生错误的位置
灵活性（适应性）：修改一个可正常运行的程序所需的工作量
模块化：程序部件的独立性
通用性：程序部件潜在应用范围的广泛性，即可重用性
软件系统独立性：程序与非标准的程序设计语言特征、操作系统特征以及其他环境限制无关的程度。
硬件独立性：软件同支持它运行的硬件系统不相关的程度。
与可维护性的区别：可维护性：我能修复它吗？灵活性：我能改变它吗？
可移植性：将软件从一个硬件和软件系统环境移植到另一个所需要的工作量
可复用性：软件的各个构件可以在另一个软件中使用的程度
互操作性：将一个系统连接到另一个系统所需要的工作量
通信通用性：使用标准接口、协议、规范的程序
数据通用性：在程序中使用标准的数据结构和类型

软件质量保证（SQA）

什么是SQA：参照一定的质量标准、目标及各项软件流程、规范来监督、管理软件产品的质量
SQA的目的：是使软件过程对于管理人员来说是可见的。核实产品遵从于对应的需求、过程描述、标准及规程。

软件质量保证目标

需求质量。需求模型的正确性、完整性和一致性将对所有后续工作产品的质量有很大的影响。
设计质量。软件团队应该评估设计模型的每个元素，以确保设计模型显示出高质量，并且设计本身符合需求。
代码质量。源代码和相关的工作产品（例如，其他说明资料）必须符合本地的编码标准，并显示出易于维护的特点。
质量控制有效性。软件团队应使用有限的资源，在某种程度上最有可能得到高品质的结果。

软件质量保证的任务

为项目准备SQA计划
参与开发项目的软件过程描述
评审各项软件工程活动，验证其是否符合定义的软件过程
审核指定的软件工作产品，验证其是否符合定义
确保软件工作及工作产品中出现的偏差已文档化，并且按照文档化的规程进行了处理
记录所有不符合的部分，并报告给高层管理者

软件项目估算

项目估算是对需求分析、设计、编码、测试、集成交付等整个软件开发过程所花费工作量、时间、成本等的预测。
项目估算是制定合理的项目计划的基础。
可能的“捷径”：把估算推迟到项目后期进行，根据已经完成的类似项目进行，使用比较简单的分解技术，使用一个或多个经验模型

基于问题规模的估算（1）

包括LOC估算(直接测量)和FP估算(间接测量)

过程：
从软件范围陈述入手，将软件分解成一些可独立进行估算的功能
估算每个功能的LOC或FP
将基线生产率度量应用于适当的估算变量中，导出每个功能的成本或工作量
将所有功能的估算合并。

项目任务分解

按过程分解

在这里插入图片描述

按功能分解

在这里插入图片描述

基于问题规模的估算（2）

三点估算

综合不同的估计结果
先确定规模的乐观值(Sopt)、可能值(Sm)和悲观值(Spess)，再将它们结合起来
期望值S=(Sopt+4Sm+Spess)/6

基于LOC的估算

基于分解技术的估算（FP）

基于过程的估算

将过程分解为一组较小的任务，并估算完成每个任务所需的工作量
步骤
从项目范围中抽取出软件功能
给出为实现每个功能所必须执行的一系列框架活动
估算每个软件过程活动所需的工作量
将平均劳动力价格应用于每个软件过程活动的估算工作量，从而估算出成本

经验估算模型

典型的估算模型是通过回归分析从以往软件项目中收集的数据而得到的

其它估算模型

COCOMO II模型（构造性成本模型）
基于用例的估算
面向对象项目的估算

项目进度安排

延期怎么办？

按照以往项目的历史数据和本项目进展情况，重新进行详细的估算，确定新的估算工作量和工期。
采用增量过程模型，制定一个软件过程策略，以保证能够在规定交付日期提供主要功能，而将其他功能的实现推到以后。
与客户交流，说明规定的交付日期是不现实的，并将增量开发策略作为可选计划提交给客户

项目进度安排

是一种活动，通过将时间分配给特定的软件工程任务，从而将所估算的工作量分配到计划的项目工期内

基本指导原则

划分：将项目划分成多个可以管理的活动、动作和任务
相互依赖性：划分后的各个活动、动作或任务之间的相互依赖关系必须是明确的
时间分配：每个安排了进度计划的任务必须分配一定数量的工作单位；必须为每个任务指定开始日期和完成日期
工作量确认：必须确保在任意时段中分配的人员数量不会超过项目团队中的总人员数量
确定责任：每个任务都应该指定特定的团队成员来负责
明确结果：每个任务都应该有一个明确的输出结果
确定里程碑：每个任务或任务组都应该与一个项目里程碑相关联

人员与工作量的关系

在项目后期增加人手常会对项目产生破坏性影响
需要培训
增加交流路径
项目进度具有弹性
在一定程度上可以缩短项目交付日期（增加资源），也可以拖延项目交付日期（减少资源）
如果能够拖延交付时间，则可以明显降低项目成本

工作量分配

在这里插入图片描述

定义任务网络

单个任务和子任务之间存在顺序上的相互依赖关系，当有多人参与项目时，多个开发活动和任务并行进行的可能性很大。
任务网络，也称活动网络，是一个项目任务流程的图形表示。

进度安排

关键路径方法（CPM）

基于数学方法来规划项目活动
关键在于构建一个项目模型，包括：完成项目所需活动，每项活动的持续时间，活动之间的依赖性
空闲时间（浮动时间、机动时间）= 可用时间 - 实际时间
可用时间：依据进度，至活动结束所余时间。
实际时间：完成活动需要的时间
关键路径：空闲时间为0的节点所构成的路径

甘特图

跟踪进度

定期举行项目状态会议
评估所有在软件过程中所进行的评审的结果
判断正式的项目里程碑是否按预定日期完成
比较项目表中列出的各项任务的实际开始日期与计划开始日期
与开发者进行非正式会谈，获取他们对项目进展及可能出现问题的客观评估
通过分析获得值来定量地评估项目进展

风险管理

风险

具有负面后果、人们不希望发生的事件。
不确定性：可能发生，也可能不发生（事件发生的概率称为风险概率，当概率为1时，风险变成了必然发生的问题，不再称为风险。）
损失：具有负面后果，是不希望发生的事（与风险有关的损失称为风险影响）
能够改变结果的程度，常要考虑风险控制：降低或消除风险所采取的行动

风险策略

被动风险策略

对风险不闻不问，直至出现问题。这时，项目团队赶紧采取行动，试图迅速解决问题
缓解措施：为预期的救火行为安排额外资源
纠正措施：运用资源去解决问题
危机管理：在危险发生在控制之外时（很可能），项目将处于危机状态

主动风险策略

在技术工作开始之前，就开始识别出潜在的风险，评估它们发生的概率及影响，并按重要性排序。然后，制定一个计划来管理风险
有正式的风险分析
风险影响一般可控

风险类型（1）

项目风险：威胁到项目计划(拖延项目进度和增加成本)：预算、进度、人员、资源、利益相关方、需求
技术风险：威胁到软件的质量及交付时间：设计、实现、接口、验证和维护
商业风险：威胁到软件的生存能力：市场、策略、销售、管理、预算

风险类型（2）

已知风险：通过仔细评估项目计划、开发项目的商业及技术环境、以及其他可靠的信息来源之后可以发现的风险
可预测风险：能够从过去项目的经验中推断出来
不可预测风险：可能会出现，但很难事先识别出它们来

风险管理

了解和控制项目中的风险

七项原则：

全面观点：在整个系统和商业环境下考虑软件风险
长远观点：考虑将来可能发生的风险
广泛交流：如果有人提出一个潜在的风险，要重视它
结合：考虑风险时必须与软件过程相结合
强调持续的过程：持续的风险管理
开发共享的产品：
协同工作：汇聚所有利益相关者的智慧、技能和知识

风险管理的作用

提高项目的成功率
保证风险发生时的及时反应
增加团队的健壮性
帮助项目经理抓住工作重点

风险管理过程

在这里插入图片描述

风险识别（1）

系统化地指出对项目计划的威胁

识别方法：建立风险条目检查表：产品规模，商业影响，客户特性，过程定义，开发环境，开发技术，人员才干及经验

风险识别（2）

规模影响风险：

对于估算出的产品规模的信任程度如何；
是否以程序、文件或事务处理的数目来估算产品规模；
产品规模与以前产品的规模的平均值的偏差百分比是多少；
产品创建或使用的数据库大小如何；
产品的需求改变多少？交付之前有多少？交付之后有多少？
复用的软件有多少？

风险识别（3）

客户相关风险：

以前是否曾与这个客户合作过；
客户是否清楚需要什么；他能否花时间把需求写出来；
客户是否同意召开正式的需求收集会议，以确定项目范围；
客户是否愿意建立与开发者之间的快速通信渠道；
客户是否愿意参加复审工作
客户是否具有该产品领域的技术素养
客户是否了解软件过程；

风险识别（4）

过程风险：

是否已经拟定了成文的、用于本项目开发的软件过程说明；
开发人员是否同意按照文档所写的软件过程进行开发
是否定期对需求规约、设计和编码进行正式技术复审
是否使用方便易用的规格说明技术来辅助客户与开发者间的通信
是否90％以上的代码都是使用高级语言编写的；
是否定义及使用特定的规则进行代码编写；
是否收集所有软件项目的质量度量值；

风险识别（5）

技术风险：

该技术对于你的公司而言是新的吗；
待开发软件是否需要使用新的或未经证实的硬件接口；
待开发软件是否需要与开发商提供的未经证实的软件产品接口
需求是否要求开发某些程序构件，这些构件与你的公司以前开发的构件完全不同
需求中是否要求使用非传统的软件开发方法
需求中是否有过分的对产品性能的约束

风险识别（6）

开发环境风险：

是否有可用的软件项目管理工具；
是否有可用的分析及设计工具；
是否有可用的编译器或代码生成器
是否有可用的软件配置管理工具
项目组的成员是否接受过每个所使用工具的培训
工具的联机帮助及文档是否适当

风险识别（7）

与人员数目及经验相关的风险：

是否有足够的人员可用；
人员在技术上是否配套；
开发人员是否能够自始至终地参加整个项目的工作
开发人员对自己的工作是否有正确的期望
开发人员是否接受过必要的培训
开发人员的流动是否仍能保证工作的连续性

风险识别（8）

识别影响风险因素的风险驱动因子

风险因素
软件项目的不确定性
性能风险：产品能够满足需求且符合其使用目的不确定程度
成本风险：能够维持项目预算的不确定程度
支持风险：开发出的软件易于纠错、修改及升级的不确定程度
进度风险：能够维持项目进度且按时交付产品的不确定程度

风险驱动因子
可导致软件项目的不确定性程度改变的事物，如未识别出的软件失误，开发成员变动等。
风险驱动因子对于风险因素的影响可分成四类：可忽略的、轻微的、严重的或灾难的。

风险预测

又称风险估计，试图从两个方面评估每一个风险：风险发生的可能性，风险相关问题产生的后果
建立风险表
评估风险影响
本质：风险发生时可能带来的问题
范围：风险的严重性及风险的整体分布情况
时间：何时能感受到风险的影响及风险的影响会持续多长时间
风险显露度：RE=P*C P为风险发生概率，C为风险发生时带来的项目成本
对风险事件发生概率的评估，对项目风险影响的评估，给出项目风险排序。