软件项目管理 教学课件 作者 朱少民 韩莹 第4章 项目估算.pptVIP

人月神话？ 4.1项目估算的挑战 接受挑战 2300多年前，亚里斯多德曾说过，“应该满足于事物的本性所能容许的精确度，当只能近似于真理时，不要去寻求绝对的准确……”。 项目管理者不应该被估算所困扰，勇于面对软件项目估算的挑战，克服其中的困难，做出一个相对的有价值的估算 估算的基本内容及其关系 软件估算全貌 4.3 基本估算方法 4.4 软件规模估算 4.4.1 德尔菲法 4.4.2 代码行估算方法 4.4.3 功能点分析方法 4.4.4 标准构件法 4.4.5 综合讨论 4.4.1 德尔菲法 4.4.2 代码行估算方法 SLOC (single line of code) KLOC (thousand lines of code) LLOC (logical line of code) PLOC (physical line of code) NCLOC (non-commented line of code) DSI (delivered source instruction) 4.4.3 功能点分析方法 Alain Abran等人提出的全面功能点法 英国软件估算协会（UKSMA）提出的IFPUG 功能点法 UKSMA提出的Mark II FPA功能点法 荷兰功能点用户协会(NEFPUG)提出的NESMA 功能点法 软件估算共同协会(COSMIC)提出的COSMIC-FFP方法 功能点计算元素 功能点如何计算？ 4.4.4 标准构件法 软件由若干不同的“标准构件”组成，这些构件对于一个特定的应用领域而言是通用的。项目计划者估算每一个标准构件的出现次数，然后使用历史项目数据来确定每个标准构件交付时的大小。 例如，一个信息系统的标准构件是子系统、模块、屏幕、报表、交互程序、批程序、文件、LOC以及对象级的指令。 4.4 工作量估算 4.5.1 COCOMO方法 4.5.2 多变量模型 4.5.3 基于用例的工作量估计 4.5.4 IBM RMC估算方法 4.5.5 不同场景的估算法 COCOMO基本变量 DSI(源指令条数)，定义为代码行数，包括除注释行以外的全部代码。若一行有两个语句，则算做一条指令。KDSI即为千代码行数。 MM(估算单位为人月)表示开发工作量。 TDEV(估算单位为月)表示开发进度，由工作量决定。 COCOMO模型影响因素 产品因素：软件可靠性、数据库规模、产品复杂性。 硬件因素：执行时间限制、存储限制、虚拟机易变性、环境周转时间。 人的因素：分析员能力、应用领域实际经验、程序员能力、虚拟机使用经验、程序语言使用经验。 项目因素：现代程序设计技术、软件工具的使用、开发进度限制 COCOMO影响因子EAF值 COCOMO计算公式· 4.5.3 基于用例的工作量估计 通过用例来描述系统的需求更清楚，可以在功能点和用例之间建立良好的映射关系，项目的估算会更准确些。 用例的具体例子 用例的层次 集成系统，由多个系统构成综合系统； 独立的系统，由多个子系统组成； 子系统，由多个模块或组件构成； 模块/组件，由多个类组成，例如可假定平均8个类构成一个组件。 类，无需用例来描述。 用例估算方法 基于用例的估算，最好还是和WBS方法结合起来使用 一般认为用例的数量在10－50 个范围比较合适，而每个用例可以带有几十个相关场景 假定每一层的每一个组件平均有 10 个用例 考虑总的工作量规模时，需要对个别用例的小时数做进一步调整 4.5.4 IBM RMC估算方法 RMC 的工作量估算采用的是 QIF（定量影响因子）估算方法和自底向上估算模式，对项目的任务、活动、阶段、子项目、项目等进行自底向上的层层估算 可以定义多个估算模型 每个估算模型可以定义任意数量的估算因子 每个估算因子都会关联估算公式 使用估算公式来计算该估算因子对应的工作量 IBM RMC估算步骤 创建估算模型，定义相关的估算因子； 把估算模型的估算因子应用到 WBS 底层元素，计算出它们的工作量； 层层向上汇总，计算出项目 WBS 上层元素（包括项目本身）的工作量。 示例1-创建估算因子 示例二：各个任务的工作量估算 示例二：估算结果显示 4.5.5 不同场景的估算法 合同签订之前，了解的需求比较有限，只能了解到项目的总体需求，主要采用“类比分析和经验判断”等方法 基于WBS估算的多维验证，获得类似项目的历史数据、软件生命周期的生产率数据和详细需求，从而可以从不同的路径来估算工作量，获得多个结果，这些结果可以互相印证，以发现估算过程中的不合理之处，使估算更准确。 需求变更的工作量估计，关键是需求变更的波及范围分析 资源估算基本过程 根据WBS进行估算 由工作量和开发周期来估算 资源特征描述 资