软件工程导论——7软件项目管理

软件项目管理概述

定义

为了使软件项目能够按照预定的成本、进度和质量顺利完成，而对成本、人员、进度、质量、风险等进行分析和管理的活动。

目标

– 软件产品达到预期的功能和性能要求（质量）
– 项目在合同期限内完成和交付（进度）
– 项目开销控制在预算之内（成本）
• 先于任何技术活动之前，贯穿整个软件生命周期
• 对软件开发是否成功具有决定意义

软件项目管理的基本要素（4P）

人员管理

人员的组织与管理

产品管理

确定产品的工作环境，确定产品的功能和性能，产品处理的是什么数据，经它处理后得到什么数据

过程管理

确定软件过程

项目管理

人员组织与管理

取决于开发组织的管理模式和软件项目的特点。
典型的组织方式：

民主式组织结构

– 小组成员完全平等
– 项目工作由全体人员讨论决定
– 适合规模小、能力强、习惯于共同工作的开发组
– 无权威领导，难解决意见分歧，不适合大规模开发

主程序员式组织结构

主程序员：体系结构设计和关键部分详细设计，管理和知道其他程序员
后备程序员：协助主程序员
程序员：详细设计和编程
优点：实现项目人员的专业化分工，提高了效率
缺点：对主程序员要求高

技术管理式组织结构

将技术和管理分离开来。

软件规模和工作量估算

目的：为项目分配合理的人力、时间和相关资源
– 要完成该项目需要多少工作量？
– 要完成该项目需要多长时间？
– 项目的总成本是多少？

软件规模：软件产品的大小

以代码行表示，以千代码行为单位（KLOC）

1. 将软件分解成尽量小且可独立估算的子功能
2. 计算每个子功能的代码行数
   – 最小代码行数估算值：a
   – 最可能的代码行数估算值：m
   – 最大代码行数估算值：b
   – 代码行数期望值：L=(a+4m+b)/6
3. 将所有子功能的代码行数期望值相加得到系统的代码行数
4. 由多名有经验的开发人员分别给出估算，然后得出估算的平均值
   • 特点
   – 简单方便
   – 根据历史项目数据，历史数据可靠时估计精确
   – 依赖于功能分解，难以在开发初期估算
   – 估计结果与开发语言相关

• 案例：
XXX银行信息系统
该系统应能增加新客户，并能从客户文件中作删除 。系统支持客户的存款和取款业务。在出现透支时 ，系统应给出警告信息。客户可通过终端查询自己 的账户余额，可以要求系统给出自己的透支报告。

以功能点表示，以功能点为单位（FP)

适合在软件开发初期进行估算
估算软件规模的根据：
需求规格说明中确认的软件功能和软件功能的复杂度

功能：

每个功能对应的复杂度

通过功能和功能复杂的计算出未调节功能点（UFP）

可能影响软件规模的因素

每个因素对应的影响级别

通过影响因素和每个因素对应的影响级别，计算出综合影响度。
再使用综合影响度计算出复杂度条件因子（CAF）。
最后将复杂度调节因子和未调节功能点相乘得到交付功能点（DFP）


用交付功能点和不同的的语言对应的平均代码行数（DLOC）相乘得到交付代码行数。
• 优点：
– 可在软件初期进行估算
– 与实现语言无关
• 缺点：
– 功能分类、功能复杂性和影响因素确定方面，主观因素 难以排除
– 适合数据处理类软件，不适用于非数据处理问题，如实 时软件、科学计算软件
– 不能借助工具完成

•案例1：
XXX银行信息系统
该系统应能增加新客户，并能从客户文件中作删除 。系统支持客户的存款和取款业务。在出现透支时 ，系统应给出警告信息。客户可通过终端查询自己 的账户余额，可以要求给出透支客户报告。




•案例2：
计划为某公司开发工资管理系统，其功能和复杂性如下：

软件工作量：投入的人力

专家判定

• 由多位专家进行工作量估算，需要丰富经验
• 用Delphi方法统一专家意见
① 项目协调人向每个专家提供软件规模和估算表格
② 项目协调人召集专家小组会讨论与规模相关的因素
③ 每个专家匿名填写工作量估算表格
④ 项目协调人整理出一个估算总结，将其反馈给专家
⑤ 项目协调人召集专家小组会讨论较大的估算差异
⑥ 专家复查估算总结，在估算表上提交另一个匿名估计
⑦ 重复④到⑥，直到估算结果中的最低和最高达到一致

类比估算

通过和相似历史项目的对比来估算
① 整理出项目的功能列表和实现每个功能的代码行数
② 标识出每个功能列表与历史项目的相同点和不同点
③ 得出各个功能的工作量估算值
④ 产生总的工作量估计
• 精确度取决于历史项目数据的完整性和准确度

经验模型

COCOMO模型

• 经验模型：基于从大量软件项目中收集的数据
• 基于项目规模（代码行数）来估算工作量

基本COCOMO模型

中级COCOMO模型

• 案例：

高级COCOMO模型

COCOMO模型中的软件类型

固有型项目：较为简单的项目，开发人员对项目有着较好的理解和较丰富的经验，包括各类应用软件
半独立型项目：主要指各类实用程序、编译程序等
嵌入型项目：主要指实时处理、控制程序、操作系统等

COCOMOII模型

解决问题：开发初期难以确定代码行数
根据软件开发阶段估算工作量（3阶段）
– 第1阶段：原型阶段
•用应用点来估算软件规模，如屏幕数、报告数、构件数等
– 第2阶段：体系结构设计阶段
•用功能点来估算软件规模
– 第3阶段：详细设计阶段
•功能点或者代码行数估算软件规模

项目进度计划

项目进度

– 项目中的各个阶段
– 每个阶段中的活动
– 每项活动的开始时间、结束时间、持续时间等
– 里程碑
– 可交付的产品

项目进度管理

制定项目进度计划

跟踪项目进展

甘特图通过条状图来显示项目，进度，和其他时间相关的系统进展的内在关系随着时间进展的情况。
甘特图横轴表示时间，纵轴表示要安排的活动。

软件风险管理

什么是风险

– 一种具有负面后果的、人们不希望发生的事件
– 该事件发生后会产生损失（风险影响）
– 该事件有可能发生（风险概率）
– 能够改变结果的程度（风险控制）

风险管理的四个阶段

风险识别

风险条目检查表

风险分析

对识别的风险进行评估：确定风险发生的概率和影响

风险规划

制定风险应对策略
– 风险规避：降低风险出现的可能性，如改变需求
– 风险缓解：减少风险产生的影响
– 风险转移：将风险转移给第三方
– 风险接受：采取应急方案应对风险的发生

风险监控

– 监控指示风险变化的影响因素
– 监视风险应对措施的执行

软件配置管理

简单地说，软件配置管理就是对软件变更的管理

软件配置项 ：

– 与合同、过程、计划和产品有关的文档和数据
– 源代码、目标代码和可执行代码
– 软件工具、库内可复用软件、外购软件及用户提供的软件

基线：

– 通过正式评审和批准的规格说明或者中间产品
– 软件配置项在成为基线之前可以迅速非正式修改，
– 软件配置项成为基线之后，只有通过正式的变更控制过程才 能修改
– 标志软件开发的里程碑

版本控制

对软件的不同版本进行标识和跟踪、对版本的各种操作 进行控制，如检入检出、分支与合并、版本发布等。

考纲

项目管理
重点是项目计划和估计的方法。掌握软件项目管理的主要内容和主要方法，能根据具体的项目进行项目计划和项目估计；理解软件项目管理四个基本要素：人、产品、过程和项目。主要知识点：

1. 项目管理四要素：人员、产品、项目、过程（概念）
2. 软件度量有哪些方法：生产率估计（基于规模（KLOC）、基于功能点（FP））、工作量度量（算法成本模型、COCOMO模型）。掌握直接测量（基于规模）方法。
3. 项目计划与风险管理的概念