项目管理复习.docx

Capture14
一、 质量，软件质量概念（事物的特征或属性 ）
在软件开发中，可能会遇到两种质量：a) 设计质量包括需求、规格说明书和系统的设计。 b)符合质量主要关注于实现的问题。 C)用户满意度= 合格的产品+ 好的质量+ 按预算和进度安排交付
质量-实用观点
n 玄妙观点 (如 Persig)认为质量是马上就能识别的东西，却不能清楚地定义。
n 用户观点是从最终用户的具体目标来说的。如果产品达到这些目标，就显示出质量。
n 制造商观点是从产品的原始规格说明的角度来定义质量，如果产品符合规格说明，就显示质量。
n 产品观点认为质量是产品的固有属性（比如，功能和特性
n 最后，基于价值的观点根据客户愿意为产品支付多少钱来评测质量。实际上，质量涵盖所有这些观点，或者更多。
软件质量可以这样定义 ： 在一定程度上应用有效的软件过程，创造有用的产品，为生产者和使用者提供明显的价值。
二、 质量的维度
a) 耐久性。是否能够对软件进行维护（变更）或改正（改错），而不会粗心大意地产生料想不到的副作用？随着时间的推移，变更会使错误率或可靠性变得更糟吗？
b) 适用性。软件能在可接受的短时期内完成维护（变更）和改正（改错），技术人员支持人员能得到所需的所有信息以进行变更和修正缺陷吗？
c) 审美。我们中的大多数都同意美的东西具有某种优雅、特有的流畅和醒目的“外在”，这些都是很难量化的，但显然是不可缺少的。
d) 感知。在某些情况下，一些偏见将影响人们对质量的感知。
e) 性能质量。软件是否交付了所有的内容、功能和特性，这些内容、功能和特性在某种程度上是需求模型所规定的一部分，可以为最终用户提供价值。
f) 特性质量。软件是否首次提供了使最终用户惊喜的特性？
g) 可靠性。软件是否无误地提供了所有的特性和能力？当需要时，它是否是可用的？是否无错地提供了功能？
h) 符合性。软件是否遵从本地的和外部的与应用领域相关的软件标准？是否遵行了事实存在的设计惯例和编码惯例？例如，对于菜单选择和数据输入等用户界面的设计是否符合已接受的设计规则？
三、 认识软件质量：足够好软件提供用户期望的高质量功能和特性，但同时也提供了其他更好的包含已知错误的难解的或特殊的功能和特性 。
四、 实现软件质量关键：软件工程方法 项目管理技术 质量控制 质量保证
Capture15
一、 评审技术、什么是评审、为什么进行评审
评审会议由技术人员对技术人员进行 ；在软件工程过程中产生的对工作产品的技术评估 ；软件质量保证机制 ；训练场地
二、 常用的评审技术：正式评审和非正式评审？
三、 度量 评审工作量、发现错误数、错误密度
总评审工作量和发现的错误总数定义为：
i. Ereview = Ep + Ea + Er
ii. Errtot = Errminor + Errmajor
错误密度表示评审的每单位工作产品发现的错误数。
iii. 错误密度= Errtot / WPS
n 其中：
准备工作量Ep——在实际评审会仪之前评审一个工作产品的工作量（单位：人时）
评估工作量Ea —— 实际评审工作中所花费的工作量（单位：人时）
返工工作量Er —— 修改评审期间发现的错误所用的工作量。 （单位：人时）
工作产品规模WPS ——被评审的工作产品规模的衡量（例如，UML模型的数量、文档的页数或代码行数）。
发现的次要错误Errminor ——发现的可以归为次要错误的数量（要求少于预定的改错工作量）。
发现的主要错误Errmajor ——发现的可以归为主要错误的数量（要求多余预定的改错工作量）。
四、 非正式评审和正式评审
非正式评审包括： a. 与同事就软件工程产品进行的简单桌面检查 b.以评审一个工作产品为目的的临时会议（涉及两个以上） c.结对编程评审
结对编程鼓励在创建工作产品（设计或代码）时进行持续的审查，其好处是即时发现错误，结果是得到更好的工作产品质量。
正式评审：FTR的目标是： 发现软件的任何一种表示形式中的功能、逻辑或实现上的错误 ； 验证评审中的软件是否满足其需求 ；保证软件的表现符合预先指定的标准 ；获得以统一的方式开发的软件 ；使项目更易于管理
n FTR实际上是一类评审方式，包括走查和审查。
五、 评审会议（限制争论和辩驳）
评审会（通常）由3~5人参加。 应该提前进行准备，但是占用每人的工作时间应该不超过2小时。 评审会的时间应该少于2小时。 FTR关注的是某个工作产品（例如，一部分需求模型、一份详细的构件设计、一个构件的源代码）。
n 与会人：
开发人员——开发这个工作产品的个人
通知项目负责人该工作产品已经完成，需要进行评审
评审主席——评估该工作产品是否准备就绪，制作产品材料副本，并将这些副本分发给2到3位评审员以便事先做准备
评审员——应该用1到2小时来评审该工作产品通过做笔记或者其他方法熟悉该工作产品。
记录员——负责记录在评审过程中发现的所有重要问题。
n 进行评审：评审工作产品，而不是评审开发人员。 制定并遵守日程表。 限制争论和辩驳。 要阐明问题。 做笔记。 限制参与者人数，并坚持事先做好准备。为每个将要评审的工作产品建立检查清单。 为FTR分配资源和时间。 对所有评审员进行有意义的培训。 评审以前所做的评审。
六、 来自评审的度量
每页文档的审查时间 ； 每KLOC或FP的审查时间 ；每KLOC或FP的审查工作量 ；每一小时评审发现的错误数 ；每一小时准备发现的错误数 ；每一个SE任务发现的错误数（例如：设计） ；次要错误数（例如拼写错误） ；主要错误数（例如：与需求不一致） ；准备期间发现的错误数

Capture16 软件质量保证 （SQA）
一、 SQA要素：标准，评审和审核，测试，错误/缺陷的收集和分析，变更管理，教育，供应商管理，安全管理，安全，风险管理
二、 SQA组的角色：编制项目质量保证计划；参与项目的软件过程描述的编写；评审软件工程活动，已验证符合规定的软件过程；审核指定的软件工作产品已验证是否遵守作为软件过程一部分的那些规定；确保根据文档的规程记录和处理软件工作和工作产品中的偏差；记录各种不符合项并报告给高层管理人员。
三、 SQA目标：需求质量。需求模型的正确性、完整性和一致性将对所有后续工作产品的质量有很大的影响。
设计质量。软件团队应该评估设计模型的每个元素，以确保设计模型显示出高质量，并且设计本身符合需求。
代码质量。源代码和相关的工作产品（例如，其他说明信息）必须符合本地的编码标准，并显示出易于维护的特点。
质量控制有效性。软件团队应使用有限的资源，在某种程度上最有可能得到高品质的结果。
四、 统计SQA：收集软件的错误和缺陷信息，并进行分类。 追溯每个错误和缺陷形成的根本原因（例如，不符合规格说明、设计错误、违背标准、缺乏与客户的交流）。 使用Psreto原则（80%的缺陷可以追溯到所有可能原因中的20%），将这20%（“重要的少数”）原因分离出来。 一旦找出这些重要的少数原因，就可以开始纠正引起错误和缺陷的问题。
五、 软件可靠性
n 可靠性的简单测量是“平均失效间隔时间”(MTBF)， 其中
MTBF = MTTF + MTTR
n 首字母缩略词MTTF和MTTR 分别是 “平均失效时间”和“平均维修时间”。
n 软件可靠性是指在某个给定时间点上程序能够按照需求执行的概率。其定义为：
可用性= [MTTF/(MTTF + MTTR)] x 100%
六、 软件安全：软件安全是一种软件质量保证活动，它主要用来识别和评估可能对软件产生负面影响并促使整个系统失效的潜在灾难
七、 ISO软件质量标准
a) 管理责任、质量体系、合同评审、设计控制、文件和资料控制、产品标识与可追溯性、过程控制、检验和实验、纠正及预防措施、质量记录的控制、内部质量审核、培训、服务以及统计技术等主题。
Capture23 产品度量
n 测度为产品或过程的某些属性的范围、数量、维度、容量或大小提供量化的指标。
n 度量在《软件工程术语的IEEE标准词汇表》中的定义为：度量是一个系统、构件或过程具有给定属性的量化测量程度。
n 一个指标是一个度量或多个度量的组合，它提供了对软件工程、软件项目或产品本身的深入理解。
一、 测量原则
测量的目标应该在数据收集开始前确定； 每一个技术度量都应该有一个清晰的定义； 度量应该来自于有效应用领域的理论 (例如，设计度量应该利用基本的设计概念和原则， 尝试提供一个迹象存在的属性，并且该属性是可取的)； 度量应根据特定的产品和过程来调整，使其能够最佳适应 [Bas84]。
二、 测量过程
公式化。导出适合于所考虑软件表示的测量和度量。
收集。用于导出公式化度量所需数据的积累机制。
分析。度量的计算和数学工具的使用。
解释。为获得对所表示质量的理解而评价度量。
反馈。从对递交给软件团队的产品度量的解释中获得建议。
三、 度量属性
简单的和可计算的。学习如何导出度量应该是相对容易的，且其计算不应该需要过多的工作量或时间。
在经验上和直观上有说服力。度量应该满足工程师直觉上对所考虑的产品属性的概念。
一致的和客观的。度量产生的结果应该总是无歧义的。
单位和量纲的使用是一致的。 度量的数学计算应该使用不会导致奇异单位组合的测度。
编程语言的独立性。 度量应该基于需求模型、设计模型或程序结构本身。
有效的、高质量反馈机制。 也就是，度量应该提供信息以产生高质量的最终产品。
四、 需求模型的度量
基于功能的度量：使用功能点作为归一化因子或规格说明“规模”的手段。
规格说明度量：通过按类划分测量需求数量用于质量的指标
五、 功能点（基于功能的度量）
功能点 (FP)度量可用做测量系统交付功能的有效手段。

利用基于软件信息域可数的(直接)测度和软件复杂性评估的经验关系计算功能点。
信息域的值用下列方式定义:外部输入数 (EIs) ；外部输出数 (EOs) ；外部查询数 (EQs) ；内部逻辑文件数 (ILFs) ；外部接口文件数 (EIFs)
六、 体系结构设计度量
体系结构设计度量
a) 结构复杂度 = g(模块扇出数)
b) 数据复杂度 = f( 输入和输出变量, 模块扇出数)
c) 系统复杂度 = h(结构和数据复杂度)
HK度量：体系结构复杂度作为函数的扇入和扇出
形态度量：模块与模块之间的接口和数量的函数
七、 维护的度量
软件成熟度指标 (SMI) ，它提供了对软件产品稳定性的指标(基于产品每次发布所发生的变更)。 可以确定以下信息：
a) MT = 当前发布的模块数量；
b) Fc = 当前发布中已变更的模块数量；
c) Fa = 当前发布中已增加的模块数量；
d) Fd = 当前发布中已删除前一发布中的模块数量；
软件成熟度指标用下列方式计算:
SMI = [MT - (Fa + Fc + Fd)]/MT
当 SMI 的值接近1.0时，产品开始稳定。

Capture24项目管理概念
一、 四个P之间的关系
人员 —— 一个成功项目最重要的元素
产品 —— 建立的软件
过程 ——框架活动集和完成工作的软件工程任务
项目—— 所有需要做的工作，以使一个产品变成现实
Capture25过程度量和项目度量
一、 为什么进行测度
评估正在进行中的项目的状态 ；跟踪潜在的风险 ；在问题区域造成不良影响之前发现问题 ；调整工作流程或任务 ；评估项目团队控制软件工作产品质量的能力。
二、过程测量
软件过程的功效只能间接地测量.
n 也就是说，根据从过程中获得的结果来导出一组度量。
n 结果包括
• 在软件发布之前发现的错误数的测度
• 提交给最终用户并由最终用户报告的缺陷的测度
• 交付的工作产品 (生产率)的测度
• 花费的工作量的测度
• 花费时间的测度
• 与进度计划是否一致的测度
• 其他测度
我们也可以通过测量特定软件工程任务的特性来导出过程度量。
三、 过程度量规则
解释度量数据时使用常识，并考虑组织的敏感性。
向收集测量和度量的个人及团队定期提供反馈。
不要使用度量去评价个人。
与开发者和团队一起设定清晰的目标，并确定为达到这些目标需要使用的度量。
不要用度量去威胁个人或团队。
指出问题区域的度量数据不应该被“消极地”看待，这些数据仅仅是过程改进的指标。
不要在某一个别的度量上纠缠，而无暇顾及其他重要的度量。
四、 过程度量
质量相关性 ：专注于工作产品和可交付产品的质量
生产率相关性：与花费的工作量相关的工作产品的产量
统计SQA数据：错误分类和分析
缺陷排除效率 ： 评估一个活动在错误传递到下一个活动之前发现错误的能力
重用数据：已产生构件的数量和可重用性的程度
五、 典型的项目度量
每个软件工程任务的工作量/时间；每小时评审发现的错误数 ；计划好的和实际的里程碑日期比较 ；变更(数量)和它们的特性 ；软件工程任务上工作量的分配
六、 典型的面向规模的度量
每千行代码 (KLOC)的错误数；每千行代码 (KLOC)的缺陷数； 每行代码 (LOC)的成本； 每千行代码 (KLOC)的文档页数； 每人月错误数；每评审一小时时错误数；每人月千行代码数；每页文档的成本。
七、 典型的面向功能的度量
每个功能点的错误数 (上千行代码)每个功能点的缺陷数；每个功能点的成本；每个功能点的文档页数；每人月功能点数
八、 为什么选择FP?
与编程语言无关； 所使用的数据是在软件过程初期就确定的准备好的可数特征；对于其他更笨拙的版本来说，使用更少的代码行在实现过程中并没有什么不利 ；更容易衡量可重用的构件的影响
九、 缺陷排除效率
DRE = E /(E + D)
E 是软件交付给最终用户之前发现的错误数
D 是软件交付之后发现的缺陷数
十、 小型组织的度量
从提出请求到评估完成所用的时间(小时或天) ， tqueue .
进行评估所用的工作量(人-小时)， Weval.
从完成评估到把变更工单派发到员工所用的时间(小时或天)， teval.
实现变更所需的工作量 (人-小时)， Wchange.
实现变更所需的时间 (小时或天) ， tchange.
在实现变更过程中发现的错误数， Echange.
将变更发布给客户后发现的缺陷数， Dchange.
十一、 建立度量大纲
明确你的业务目标。 弄清你要了解或学习的内容。 确定你的子目标。
确定与子目标相关的实体和属性。确定你的测量目标。
识别可量化的问题和相关的指标，你将使用它们帮助你达到测量目标。
明确你要收集的数据元素，从这些数据元素中要得到帮助你回答问题的指标。
定义将要使用的测量，并使这些定义具有可操作性。
弄清楚实现测量需要做的操作。准备一份实施测量的计划。
Capture26软件项目估算
一、 估算
对软件工程工作的资源、成本及进度进行估算时，需要
a) 经验
b) 了解有用的历史信息 (度量)
c) 当只存在定性的信息时，还要有进行定量预言的勇气
估算具有与生俱来的风险，正是这种风险导致了不确定性。
二、估算技术
n 借鉴已完成的类似项目
n 常规的估算技术
n 任务分解和工作量估算
n 规模 (例如，功能点) 估算
n 经验模型
n 自动估算工具
三、常规方法：基于LOC/FP估算 见PPT14
n 利用信息域值的估算来计算LOC/FP
n 使用历史数据来建立项目的估算
四、计算预期成本 见ppt28
预期成本=∑ (路径概率) x (估算的路径成本)
五、 项目估算
必须理解项目范围；细化（分解）是必需的；历史度量是非常有用的；至少使用两种不同的技术；不确定性是一直存在于过程内部的
Capture27项目进度安排
软件项目进度安排、软件失败原因：延期、成本高 延期交付 时序图 基本原则。。。
一、 软件延期交付的原因
n 由软件开发团队以外的某个人制定的不切实际的项目结束期限。
n 客户需求发生变更，而这种变更没有在项目变更进度表上预先安排。
n 对完成该工作所需的工作量和(或)资源数量估计不足。
n 在项目开始时，没有考虑到可预测的和(或)不可预测的风险。
n 出现了事先无法预计的技术难题。
n 出现了事先无法预计的人力问题;
n 由于项目团队成员之间的交流不畅而导致的延期。
n 项目管理者未能发现项目进度拖后，也未能采取措施来解决这一问题。
二、 项目进度安排基本原则
n 划分——划分不同的任务
n 相互依赖性——明确任务之间的相互依赖关系
n 工作量确认——确保资源是可用的
n 确定责任 ——每个任务都应该指定特定的团队成员来负责
n 明确输出结果 ——每个任务都应该有一个明确的输出结果
n 确定里程碑 ——质量评审
三、 时序图

Capture28风险分析
一、 风险因素
性能风险——产品能够满足需求且符合其使用目的的不确定程度。
成本风险——能够维持项目预算的不确定程度。
支持风险——开发出的软件易于纠错、修改及升级的不确定程度。
进度风险——能够维持项目进度且按时交付产品的不确定程度。
二、 被动风险管理
项目团队在出现问题后才采取行动 ；风险缓解——计划采用额外的资源进行“救火” ； 努力失败——当风险攻击时，找出资源并应用 ； 危机管理——当努力失败，不响应应用资源，这时项目已经处于真正的危机中了
三、 主动风险管理
主动风险策略早在技术工作开始之前就已经启动了
组织纠正风险的根源
a) TQM概念和统计SQA
b) 检查来自软件边界之外的风险资源
c) 改善管理变更的技术
四、 基本原则
保持全面观点 ——在软件所处的系统中考虑软件风险以及该软件所要解决的业务问题。
采用长远观点 ——考虑将来可能发生的风险；制定应急计划
鼓励广泛交流 ——如果有人提出一个潜在的风险，要重视它。
结合——考虑风险时必须与软件过程相结合
强调持续的过程 ——在整个软件过程中，团队必须保持警惕。随着信息量的增加，要修改已识别的风险；随着知识的积累，要加入新的风险。
开发共享的产品 ——如果所有利益相关者共享相同版本的软件产品，将更容易进行风险识别和评估。
鼓励协同工作 ——在风险管理活动中，要汇聚所有利益相关者的智慧、技能和知识
五、 风险管理范式

六、 风险识别
产品规模 ——与要开发或要修改的软件的总体规模相关的风险。
商业影响 ——与管理者或市场所施加的约束相关的风险。
客户特性 ——与客户的素质以及开发者和客户定期沟通的能力相关的风险。
过程定义——与软件过程定义的程度以及该过程被开发组织遵守的程度相关的风险。
开发环境 ——与用来开发产品的工具的可得性及质量相关的风险。
开发技术——与待开发软件的复杂性及系统所包含技术的“新奇性”相关的风险。
人员才干及经验 ——与软件工程师的总体技术水平及项目经验相关的风险。
七、 风险预测步骤
风险预测，又称为风险估计，试图从两个方面评估每一个风险
a) 风险发生的可能性或概率；
b) 如果风险发生，风险相关问题产生的后果。
4个风险预测步骤：
c) 建立一个尺度，以反映风险发生的可能性。
d) 描述风险产品的后果。
e) 估算风险对项目及产品的影响。
f) 表明风险预测的整体精确度，以免产生误解。
八、 风险显露度
RE = P x C
其中， P 是风险发生的概率， C 是风险发生时带来的项目成本
n 例子：风险识别。 事实上，计划可复用的软件构件中只有70%将集成到应用系统中，其他功能必须定制开发。
n 风险概率。 80% (大约)。
n 风险影响。 计划了60个可复用的软件构件，如果只能利用70%，则18个构件必须从头开发 (除了已经计划开发的定制软件外)。平均每个构件的程序行数是100 LOC，本地数据表明每个LOC的软件工程成本是$14.00，开发构件的总成本 (影响) 将是 18 x 100 x 14 = $25,200。
n 风险显露度。 RE = 0.80 x 25,200 ~ $20,200。
九、 风险分类
产品规模风险；商业影响风险；客户风险；过程成熟度风险；技术风险；员工/人员风险
Capture29维护和再工程
一、 软件维护概念
所谓软件维护就是在软件已经交付使用之后，为了改正错误或满足新的需要而修改软件的过程。
二、 软件维护的类型
纠错性维护；适应性维护；完善性维护或增强；预防性维护或再工程
三、 再工程定义
软件再工程是指对既存对象系统进行调查，并将其重构为新形式代码的开发过程。最大限度地重用既存系统的各种资源是再工程的最重要特点之一。从软件重用方法学来说，如何开发可重用软件和如何构造采用可重用软件的系统体系结构是两个最关键问题。不过对再工程来说前者很大一部分内容是对既存系统中非可重用构件的改造。软件工程再工程是以软件工程方法学为指导，对程序全部重新设计、重新编码和测试，为此可以使用case工具（逆向工程和再工程工具）来帮助理解原有的设计。在软件再工程的各个阶段，软件的可重用程度都将决定软件再工的工作量。
四、 再工程的过程