软件工程复习（五）

第22章 项目管理概念

软件项目的特殊之处：

• 产品无形
• 无统一标准过程

22.1 管理涉及的范围

管理涉及的范围：

• 人员
  是整个项目成功最重要的因素
• 产品——项目团队将要开发的软件
  确定产品的目标只是识别出产品的总体目标（从利益相关者的角度），而不用考虑如何实现这些目标
• 过程
  为完成工作所要求的框架活动和软件工程任务
• 项目
  实现产品的所有工作

22.2 人员

软件人员的素质和组织管理是保证软件项目成功最重要的因素

利益相关者

领导能力的MOI模型：

• 激励：鼓励团队成员发挥其最大潜能
• 组织：沿用已有过程（或创新过程），从而将最初概念转换成最终产品
• 思想或创新：即便被具体开发目标所约束，亦能鼓励团队成员创新，并让其感受到内在的创造力

具有实战能力的项目经理应该具有的四种品质：

• 解决问题
• 管理者的特性
• 成就团队成员
• 影响和队伍建设

软件团队的四种组织范型：

• 封闭式范型
• 随机式范型
• 开放式范型
• 同步式范型

软件工程复习二有提到团队的内容

22.3 产品

22.4 过程

软件过程管理中，需要定义整个软件开发经历的活动、所采用的技术方法、每个阶段的验收标准等。

22.5 项目

项目管理者在有限资源的约束下，对软件项目的全过程进行计划、组织、指挥、协调、控制和评价，以实现项目的目标。

如何避免90-90问题

• 在正确的基础上开始工作
• 保持动力
• 跟踪进展
• 做出英明的决策
• 进行事后分析

22.6 W^5HH原则

22.7 关键实践

第23章 过程度量和项目度量

23.1 过程领域和项目领域中的度量

过程改进的过程

不同的类型的过程数据可分为“私有的和公有的”的使用
私有的度量数据的例子有：

• （按人的）缺陷率
• （按模块的）缺陷率
• 开发中发现的错误数

某些过程度量对软件项目组是私有的，但对所有小组成员是公有的。例如

• 主要软件功能（由多个开发人员完成）的缺陷报告
• 技术评审中发现的错误
• 每个模块和函数的代码行或功能点

公用度量一般是吸取了原本是个人的或小组的私有信息

可以用以下指标进行生产率度量：

• 根据创建的模型
• 文档的页数
• 功能点
• 交付的源代码行数

23.2 软件测量

测量在现实世界中可分为两类：直接测量和间接测量
软件测量也可这样分类

• 软件过程的直接测量包括花费的成本和工作量
• 产品的直接测量包括产生的代码行、运行速度、存储容量以及某段时间内报告的缺陷
• 产品的间接测量包括功能、质量、复杂性、有效性、可靠性、可维护性等

软件度量范围分为产品度量、项目度量和过程度量

面向规模的度量
基于所开发的软件的“规模”

面向功能的度量

调和代码行和功能点的度量方法

面向对象的度量

• 场景脚本的数量
• 关键类的数量
• 支持类的数量
• 每个关键类的平均支持类数量
• 子系统的数量

面向用例的度量

23.3 软件质量的度量

质量测量的最有效的指标：

• 正确性

正确性是软件完成所需的功能的程度
最常用的测量是每千行（KLOC）的缺陷数

• 可维护性

可维护性指遇到错误时程序能被修改的容易程度，环境发生变化时程序能够适应的容易程度，用户希望改变需求时程序能被增强的容易程度
平均变更时间（MTTC）

• 完整性

完整性的两个附加属性：危险性和安全性
危险性是指某个特定类型的攻击在给定的时间内发生的概率
安全性是某个特定类型的攻击将被击退的概率

• 可用性
  
  

缺陷排除效率（DRE）
是对质量保证及控制活动中滤除缺陷能力的一个测量，这些活动贯穿于所有过程框架活动

项目内部

第24章 软件项目估算

24.1 对估算的观察

软件项目管理从项目策划开始，估算是项目策划的第一项活动，是其它项目策划活动的基础

估算的风险：

• 项目的复杂性
• 项目的规模
• 项目的结构化程度
• 历史信息的有效性

24.2 项目计划过程

项目计划任务集：

1. 规定项目范围
2. 确定可行性
3. 分析风险
4. 确定需要的资源
   • 人力资源
   • 可复用的软件资源
   • 硬件、软件资源
5. 估算成本和工作量
   • 分解问题
   • 适用规模、功能点、过程任务或用例等方法进行两种以上的估算
   • 调和不同的估算
6. 制定项目进度计划任务
   • 建立一组有意义的任务集合
   • 定义任务网络
   • 适用进度计划工具制定时间表
   • 定义进度跟踪机制

24.3 软件范围和可行性

软件范围描述了

• 要交付给最终用户的功能和特性
• 输入和输出的数据
• 使用时要呈现给用户的“内容”
• 界定系统的性能、约束、接口和可靠性

功能、性能和约束必须在一起进行评价

影响软件可行性的因素

• 技术
• 经济
• 时间
• 资源
• 法律

24.4 资源

项目策划的第二个任务是对完成软件开发工作所需的资源进行估算
资源四个特征：

• 资源描述
• 可用性说明
• 何时需要资源
• 使用资源的持续时间

最后两个特性可以看成时间窗口

三类主要的软件工程资源

• 人员
• 可复用的软件构件
• 开发环境
  

可复用软件资源
4种软件构件

• 成品构件
• 具有完全经验的构件
• 具有部分经验的构件
• 新构件

24.5 软件项目估算

可能的 “捷径”

1. 把估算推迟到项目后期进行
2. 根据已经完成的类似项目进行估算
3. 使用比较简单的分解技术，生成项目的成本和工作量估算
4. 使用一个或多个经验模型来进行软件成本和工作量的估算

3和4可行，最理想情况是同时使用这两种方法，相互进行交叉分析

24.6 分解技术

估算的准确性取决因素

• 估算待开发产品规模的正确程度
• 把规模估算转换成人员工作量、时间及成本的能力
• 项目计划反映软件团队能力的程度
• 产品需求的稳定性和支持软件工程工作的环境

规模的测量

• 直接：代码行（LOC）
• 间接：功能点（FP）

估算问题规模的方法

• 模糊逻辑法
• 功能点法
• 修改法
• 标准构件法

基于问题规模的估算

基于LOC的估算

基于FP估算

上图的数据存在一定问题，估算值那一列都是四舍五入之后的值，但计算FP值的时候又用四舍五入之前的值，第三行那个数据有问题

Delphi方法
召集一组相关专家开会确定

基于过程的估算

基于用例的估算
困难：

• 没有标准的形式
• 用例表现的是软件的外部视图
• 没有标识出所描述的功能和特性的复杂性
• 不能描述出涉及很多功能和特性的复杂行为（交互）

过程：

• 明确原则
• 建立结构层次内的层次，确定每个用例的平均长度，定义软件的类型
• 确定系统的大致体系结构
• 利用经验数据确定（层次结构中每一层）每个用例的LOC或FP的估算值
• 基于历史数据计算开发系统所需的工作量

24.7 经验估算模型

COCOMO II模型
应用领域

• 应用组装模型
• 早期设计阶段
• 体系结构后阶段

对象点的计算

• （用户界面的）屏幕数
• 报表数
• 构造应用系统可能需要的构件数

与功能点一样，是一种间接的软件测量

软件方程

开发小组人数与软件生产率的关系

24.8 面向对象项目的估算

第25章 项目进度安排

25.1 基本概念

25.2 项目进度安排概述

基本指导原则：

• 划分
• 相互依赖性
• 时间分配
• 工作量确认
• 确定责任
• 明确结果
• 确定里程碑

软件神话：即使进度拖后，我们也总是可以在项目后期增加更多的程序员来跟上进度

PNR曲线

人员和工作量之间的关系

25.3 为软件项目定义任务集

软件项目类型：

• 概念开发项目
• 新应用系统开发项目
• 应用系统增强项目
• 应用系统维护项目
• 再工程项目

影响任务集选择的因素

• 项目的规模
• 潜在的用户数量
• 任务的关键性
• 应用程序的寿命
• 需求的稳定性
• 客户/开发者进行沟通的容易程度
• 可应用技术的成熟度
• 性能约束
• 嵌入式和非嵌入式特性
• 项目人员配置以及再工程因素等

25.4 定义任务网络

任务网络，也称活动网络，是一个项目任务流程的图形表示。必须协调多个并发任务，以保证它们能够在后继任务需要其工作产品之前完成

25.5 进度安排

关键路径法（CPM）

例子：

任务滞后Lag

关键路径可能不止一条

正推法

逆推法

时序图

项目表

25.6 挣值分析

挣值分析是在软件小组按项目进度表工作时，定量分析项目进展的技术

第26章 风险管理

26.1 被动风险策略和主动风险策略

被动风险策略针对可能发生的风险来检测项目，直到风险发生时，才会抽出资源来处理它们。
缓解措施：为预期的救火行为（救火模式）安排额外资源
纠正措施：运用资源去解决问题
危机管理：在危险发生在控制之外时（很可能），项目将处于危机状态

主动风险策略
在技术工作开始之前，就开始识别出潜在的风险，评估它们发生的概率及影响，并安排重要性排序
有正式的风险分析
风险影响一般可控

26.2 软件风险

软件风险
两个特性

• 不确定性
• 损失

软件风险类型

• 项目风险
• 技术风险
• 商业风险

另一种风险分别类型

• 已知风险
• 可预测风险
• 不可预测风险

实施有效风险管理框架的七项原则

• 保持全面观点
• 采用长远观点
• 鼓励广泛交流
• 结合
• 强调持续的过程
• 开发共享的产品
• 鼓励协同工作

风险管理的四个作用

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

26.3 风险识别

风险识别试图系统化地指出对项目计划（估算、进度、资源分配等）的威胁。

风险因素

• 性能风险
• 成本风险
• 支持风险
• 进度风险

风险驱动因子：可导致软件项目不确定性程度改变的事物，如未识别出的软件错误，开发成员变动等。

风险驱动因子对于风险因素的影响可分为四类

• 可忽略的
• 轻微的
• 严重的
• 灾难的
  

26.4 风险预测

26.5 风险细化

26.6 风险缓解、监测和管理

风险回避：通过建立一个风险缓解计划来回避风险
风险监测：监测那些可以表现风险正在变高或变低的因素
风险管理及应急计划：风险发生时的应对措施，是以缓解工作已经失败、而且风险已经发生为先决条件

26.7 RMMM计划

风险缓解、监测和管理计划RMMM计划将所有风险分析工作文档化，项目管理者还可将其作为整个项目计划的一部分：

• 缓解：我们能够规避风险
• 监测：哪些因素能够显示风险在变化
• 管理：风险发生时，如何应对

风险信息表单（RIS）

风险缓解是一种问题规避活动，而风险监测则是一种项目跟踪活动，这种监测活动有三个主要目的

• 评估所预测的风险是否真正发生了
• 保证正确地实施了各风险的缓解步骤
• 收集能够用于今后风险分析的信息