第1章软件项目计划.ppt

* * * * * * * * * * * * * * * * * * * * * * * * * * 第一章 软件项目计划管理 * 0.agenda 1、初始软件计划 2、项目度量 * 1.初始软件计划 一个成功的软件项目应该是：在工程允许的范围内满足成本、进度和质量目标的要求，而不需要对他的进度和预算进行增补。 计划良好的项目具备的特征： 软件开发计划 项目估计 修改估计 质量保证计划 分期交付计划 * 1.初始软件计划 在初始软件计划中应处理以下主题： 项目要旨 项目的总体目标 计划和进展的公开化 人员策略 时间统计 * 1.初始软件计划 项目组的组织： 项目经理 开发经理 体系结构 软件工程师 产品顾问 配置工程师 项目负责人 质量保证人员 风险管理人 * 2.项目度量 项目管理者和软件项目组经过使用项目度量及从其中导出的指标，可以改进项目工作流程和技术活动。 项目度量的目的是双重的。首先，这些度量能够指导进行一些必要的调整以避免延迟，并减少潜在问题及风险，从而使得开发时间减到最少。其次，项目度量可在项目进行的基础上评估产品质量，并且可在必要时修改技术方法以改进质量。 * 2.项目度量 代码行（Line of Code：LOC）是用于度量软件工作量的一个常用的测度。由于在程序中包含有程序的注释等数据，因此也采用无注释代码行（NCLOC）来测度有效的代码行。 还可以采用其他的度量指标： 每千行代码(KLOC)的错误数 每千行代码(KLOC)的缺陷数 每行代码(LOC)的成本 每千行代码(KLOC)的文档页数 每人月错误数 每人月代码行(LOC) 每页文档的成本 * 2.1 面向规模的度量 2.项目度量 功能点（FP）用系统的功能的数量来测量其规模。功能点数是通过首先计算一个“未调整的功能点计数（UFC）”得到的。对于以下几类进行计数： 外部输入——由用户提供的描述面向应用的数据的项 外部输出——向用户提供的用以生成面向应用的数据的项 外部查询——要求回答的交互式输入 外部文件——对其他系统的机器可读界面 内部文件——系统里的逻辑主文件 * 2.2 面向功能的度量 2.项目度量 一旦收集了这些数据，根据下表对应每个计数都有一个复杂度等级，每个计数乘以相应的复杂度权重再相加就得到UFC。 功能点的复杂度权重表 * 2.2 面向功能的度量 项 权重因素 简单 一般 复杂 外部输入 3 4 6 外部输出 4 5 7 外部查询 3 4 6 外部文件 7 10 15 内部文件 5 7 10 2.项目度量 调整的功能点计数（FP）是通过UFC和技术复杂度因子（TCF）相乘计算出来的。 技术复杂度因子（TCF）表 * 2.2 面向功能的度量 F1 可靠的备份和恢复 F2 数据通信 F3 分布式功能 F4 软件性能 F5 可配置性 F6 实时数据输入 F7 操作简便性 F8 在线升级 F9 界面复杂性 F10 数据处理复杂性 F11 代码重用性 F12 安装简易性 F13 跨平台要求 F14 易于修改 2.项目度量 每一个组成部件设定为0-5，0意味着它的组成对于系统没有什么影响，而5意味着它的组成对于系统来说是重要的。因此TCF计算如下： TCF = 0.65 + 0.01（SUM（Fi）） 因素的改变从0.65（每个Fi为0）到1.35（每个Fi为5）。 FP = UFC × TCF * 2.2 面向功能的度量 2.项目度量 项目 代码行 功能点 1 度量类型 是一种基于物理式的度量，当有代码存在的时候是比较容易数出来的 是一种基于逻辑式的度量，是经过人为逻辑归纳的方法，所以当项目需求比较模糊或没有代码的情况下，也是可以数出来的 2 度量准确度和难易程度 在需求、计划、设计阶段因为本身没有代码行，需要靠估算来解决。总体上估算准确度不高，除非有多年的类似项目经验。估算的准确程度取决于是否有同类项目的数据和估算人员的经验。在编码、测试、实施阶段可以直接数出来 在需求、计划、设计阶段不需要估计就可以直接数出来。计数的准确程度取决于需求规范程度和计数人员的经验。在编码、测试、实施阶段可以直接数出来 * 2.3 两种度量方式的比较 2.项目度量 项目 代码行 功能点 3 与技术的相关性 度量结果与所采用的技术和编程语言有很大关联 度量结果与所采用的技术和编程语言无关 4 对需求开发的帮助 没有帮助 有帮助。因为如果需求不够清晰，往往难以数下去 5 计数复杂度 简单 复杂 6 计数规则的多样性 每个企业都有自己的代码行计数定义，存在很大的不一致性 目前存在4种主要的计数规则：IFPUG、COSMIC、NESMA、MARKII。公平、一致 * 2.3 两种度量方式的比较 2.项目度量 代码行和功能点度量之间的关系依