《《精编》软件开发成本估算的经验》由会员分享，可在线阅读，更多相关《《精编》软件开发成本估算的经验（46页珍藏版）》请在金锄头文库上搜索。
1、软件开发成本估算的经验模补充资料 软件开发成本估算的经验模型 软件开发成本估算是依据开发成本估算模型进行估算的 开发成本估算模型通常采用经验公式来预测软件项目计划所需要的成本 工作量和进度数据 用以支持大多数模型的经验数据都是从有限的一些项目样本中得到的 IBM模型 E 5 2 L0 91D 4 1 L0 36 14 47 E0 35S 0 54 E0 6DOC 49 L1 01L是源代码行数 KLOC E是工作量 PM D是项目持续时间 月 S是人员需要量 人 DOC是文档数量 页 IBM模型是静态单变量模型 在此模型中 一般指一条机器指令为一行源代码 一个软件的源代码行数不包括程序注释 作
2、业命令 调试程序在内 对于非机器指令编写的源程序 例如汇编语言或高级语言程序 应转换成机器指令源代码行数来考虑 转换系数表 定义 转换系数 机器指令条数 非机器语言执行步数 Putnam模型 Putnam模型是一种动态多变量模型 适用于大型项目 但也可以应用在一些较小的软件项目中 它是假定在软件开发的整个生存期中工作量有特定的分布 大型软件项目的开发工作量分布可以用Rayleigh Norden曲线表示 用Rayleigh Norden曲线可以导出一个 软件方程 td是开发持续时间 年 K是软件开发与维护在内的整个生存期所花费的工作量 人年 L是源代码行数 LOC Ck是技术状态常数 因开发环
3、境而异 技术状态常数Ck的取值 COCOMO模型 COnstructiveCOstMOdel 结构型成本估算模型是一种精确 易于使用的成本估算方法 DSI 源指令条数 定义为代码的源程序行数 若一行有两个语句 则算做一条指令 它包括作业控制语句和格式语句 但不包括注释语句 KDSI 1000DSI MM 度量单位为人月 表示开发工作量 TDEV 度量单位为月 表示开发进度 它由工作量决定 软件开发项目的分类软件开发项目的总体类型 组织型嵌入型半独立型 COCOMO模型的分类COCOMO模型按其详细程度分成三级 基本COCOMO模型中间COCOMO模型详细COCOMO模型基本COCOMO模型是静
4、态单变量模型 用源代码行数 LOC 为自变量的经验函数计算软件开发工作量 中间COCOMO模型在用LOC为自变量的函数计算软件开发工作量 称为名义工作量 的基础上 用涉及产品 硬件 人员 项目等方面的影响因素调整工作量估算 详细COCOMO模型包括中间COCOMO模型的所有特性 但用上述各种影响因素调整工作量估算时 还要考虑对软件工程过程中每一步骤 分析 设计等 的影响 基本COCOMO模型 基本COCOMO模型的工作量和进度公式 中间COCOMO模型 进一步考虑15种影响软件工作量的因素 通过定下乘法因子 修正COCOMO工作量公式和进度公式 可以更合理地估算软件 各阶段 的工作量和进度 中
5、间COCOMO模型的名义工作量与进度公式如下所示 中间COCOMO模型的名义工作量与进度公式 15种影响软件工作量的因素fi 产品因素 软件可靠性 数据库规模 产品复杂性硬件因素 执行时间限制 存储限制 虚拟机易变性 环境周转时间人的因素 分析员能力 应用领域实际经验 程序员能力 虚拟机使用经验 程序语言使用经验项目因素 现代程序设计技术 软件工具的使用 开发进度限制 此时 工作量计算公式改成例1 一个32KDSI的声音输入系统是一个输入原型 或是一个可行性表演模型 所需可靠性非常低 把此模型看做半独立型软件 则有MM 3 0 32 1 12 146又查表知f1 0 75 其它fi 1 00
6、则最终有MM 146 0 75 110 例14 一个规模为10KDSI的商用微机远程通信的嵌入型软件 使用中间COCOMO模型进行成本估算 程序名义工作量MM 2 8 10 1 20 44 38 MM 程序实际工作量MM 44 38 44 38 1 17 51 5 MM 开发所用时间TDEV 2 5 51 5 0 32 8 9 月 如果分析员与程序员的工资都按每月6 000美元计算 则该项目的开发人员的工资总额为51 5 6 000 309 000 美元 做为对比 现在用IBM模型计算 PM 5 2 10 0 91 42 27 人月 D 4 1 10 0 38 9 84 月 S 0 54 42
7、 27 0 60 5 1 人 详细COCOMO模型 详细COCOMO模型的名义工作量公式和进度公式与中间COCOMO模型相同 工作量因素分级表分层 分阶段给出 针对每一个影响因素 按模块层 子系统层 系统层 有三张工作量因素分级表 供不同层次的估算使用 每一张表中工作量因素又按开发各个不同阶段给出 例如 关于软件可靠性 RELY 要求的工作量因素分级表 子系统层 如表所示 使用这些表格 可以比中间COCOMO模型更方便 更准确地估算软件开发工作量 软件可靠性工作量因素分级表 子系统层 进度安排 软件开发项目的进度安排有两种方式 1 系统最终交付日期已经确定 软件开发部门必须在规定期限内完成 2
8、 系统最终交付日期只确定了大致的年限 最後交付日期由软件开发部门确定 进度安排落空 会导致市场机会的丧失 使用户不满意 而且也会导致成本的增加 因此 在考虑进度安排时 要把工作量与花费时间联系起来 合理分配工作量 利用进度安排的有效分析方法严密监控软件开发的进展情况 使软件开发进度不致拖延 软件开发小组人数与软件生产率的关系 当几个人共同承担软件开发项目中的某一任务时 人与人之间必须通过交流来解决各自承担任务之间的接口问题 即所谓通信问题 通信需花费时间和代价 会引起软件错误增加 降低软件生产率 若两个人之间需要通信 则称在这两个人之间存在一条通信路径 如果一个软件开发小组有n个人 每两人之间
9、都需要通信 则总的通信路径有n n 1 2 条 设一个人单独开发软件 生产率是5000行 人年 若4个人组成一个小组共同开发这个软件 则需要6条通信路径 若在每条通信路径上耗费的工作量是250行 人年 则小组中每个人的软件生产率降低为5000 6 250 4 5000 375 4625行 人年 从上述分析可知 一个软件任务由一个人单独开发 生产率最高 而对于一个稍大型的软件项目 一个人单独开发 时间太长 因此软件开发小组是必要的 但是 开发小组不宜太大 成员之间避免太多的通信路径 在开发进程中 切忌中途加人 避免太多的生产率损失 任务的确定与并行性 当参加同一软件工程项目的人数不止一人的时候
10、开发工作就会出现并行情形 软件开发进程中设置许多里程碑 里程碑为管理人员提供了指示项目进度的可靠依据 软件工程项目的并行性提出了一系列的进度要求 因为并行任务是同时发生的 所以进度计划表必须决定任务之间的从属关系 确定各个任务的先后次序和衔接 确定各个任务完成的持续时间 项目负责人应注意构成关键路径的任务 即若要保证整个项目能按进度要求完成 就必须保证这些任务要按进度要求完成 制定开发进度计划 40 20 40规则在整个软件开发过程中 编码工作量仅占20 编码前工作量占40 编码后工作量占40 40 20 40规则只应用来做为一个指南 实际的工作量分配比例必须按照各项目的特点来决定 COCOM
11、O模型开发进度TDEV与工作量MM的关系 TDEV a MM b如果想要缩短开发时间 或想要保证开发进度 必须考虑影响工作量的那些因素 按可减小工作量的因素取值 按此比例确定各个阶段工作量的分配 从而进一步确定每一阶段所需的开发时间 然后在每个阶段 进行任务分解 对各个任务再进行工作量和开发时间的分配 进度安排的方法 可以把用于一般开发项目的进度安排的技术和工具应用于软件项目 为监控软件项目的进度计划和工作的实际进展情况 为表现各项任务之间进度的相互依赖关系 需要采用图示的方法 在图示方法中 必须明确标明 各个任务的计划开始时间 完成时间 各个任务完成标志 即 文档编写和 评审 各个任务与参与
12、工作的人数 各个任务与工作量之间的衔接情况 完成各个任务所需的物理资源和数据资源 1 甘特图 GanttChart 在甘特图中 每一任务完成的标准 不是以能否继续下一阶段任务为标准 而是以必须交付应交付的文档与通过评审为标准 因此在甘特图中 文档编制与评审是软件开发进度的里程碑 2 PERT技术和CPM方法 PERT技术叫做计划评审技术 CPM方法叫做关键路径法 它们都是安排开发进度 制定软件开发计划的最常用的方法 它们都采用网络图来描述一个项目的任务网络 也就是从一个项目的开始到结束 把应当完成的任务用图或表的形式表示出来 三个模块开发的网络图 通常用两张表来定义网络图 一张表给出与一特定软件项目有关的所有任务 也称为任务分解结构WorkBreakdownStructure 另一张表给出应当按照什么样的次序来完成这些任务 有时称为限制表RestrictionList PERT技术和CPM方法都为项目计划人员提供了一些定量的工具 确定关键路径 即决定项目开发时间的任务链 在关键路径上的各个任务都是时间余量为零的关键任务 不能有任何时间延误 应用统计模型 对每一个单独的任务确定最可能的开发持续时间的估算值 计算边界时间 以便为具体的任务定义时间窗口
