当前课程知识点:软件理论与工程 >  第6章 项目管理 >  6.1 软件项目估算 >  6.1 软件项目估算

返回《软件理论与工程》慕课在线视频课程列表

6.1 软件项目估算在线视频

下一节:6.2 软件过程管理

返回《软件理论与工程》慕课在线视频列表

6.1 软件项目估算课程教案、知识点、字幕

大家好

我们今天开始讲软件理论与工程

第六章 第一节 项目估算

我是主讲老师 高广宇

那我们知道

在整个项目的开发和管理过程中

项目的估算是非常重要的

它通常是指在项目的目标确定

和软件基本功能确定之后

就需要去着手项目计划的制订工作

而项目估算是制订计划的基础和依据

项目策划与项目估算

其实是项目开展初期阶段的重要工作

所以它的主要目的是要去

得到一些这个项目的计划

那项目策划中需要开展的活动

通常要包括

我们要去确定并分析项目的一些特征

我们还要去选择项目

将遵循的一些所谓的生存期模型

确定各个阶段的一个任务

当然这个阶段

我们还需要去开展项目的估算

包括估算产品的规模 工作量 成本

以及所需的关键计算机的一个资源

当然还需要去制订一个后续的

一些其他计划和规划

那在项目估算中

我们其实要解决的

主要的问题是什么

是项目实施中

几个非常重要的属性

也就是说

即将要开发的产品的规模

项目所需的工作量

以及项目的成本

这个当然也是整个软件工程过程中

非常关注 非常重要的几个内容

规模 工作量 以及成本

这都是非常重要的 核心的一个属性

规模通常指的是什么

是我们得到的最终软件产品的一个大小

通常来说

我们是以千行代码为单位

记作KLOC

然后当然 除了这个代码行的表示之外

还有一种表示方式是以功能点的方式

就是对于整个软件产品来说

我们包括哪几个功能

然后按照这个基础的功能点来描述

一个软件的规模

因为实际上对于这个千行代码的单位

来描述规模

其实在现在越来越变得不太合理了

大家都知道 如果你是

比如说用Python写的代码

和你用C 用Java写的代码

同样的一个功能

它的代码量完全都不在一个量级

所以说单纯通过千行代码为单位

来表述一个软件的规模

其实是不太合理的

功能点 在有的时候

其实是更加合适和客观的

那第二个是工作量

因为我们都知道

整个项目的开发是需要依靠人的

所以 它通常是采用

一个人工作一个月为单位

记作人月

比如说

我们开发一个软件或者一个项目

它所需要的人月

当然最后的是成本

成本是我们整个项目的开发

它需要考虑投入的

而且最主要的通常是人力成本

因为我们不知道

对于软件开发工程的最主要的成本来源

就是人力成本

那成本的计算方式

这个其实是一个非常麻烦

非常复杂的一个问题

所以 我们需要去形式化

或者通过一些模型去表述它

那一个软件公司

当然它在完成了很多项目

积累了一些经验数据之后

它通常是能够进行一个大致的一个估算

去根据它的生产率

和人工的一个价格做估算

对于一些初创企业来说

有的时候其实它说需要做一个什么东西

说这个东西多少钱

十万 二十万 一百万

其实这个东西浮动非常的大

因为没有一个科学的计算的话

所以 实际上我们要进行严格的

项目估算 也就是成本计算

我们需要去考虑

比如说这里提到的像生产率

它指的是 平均每个人月

我们能够完成的一些源代码行数

当然或者 对于功能点

除了每个人月能够完成的功能点

还有一个重要的元素就是

有这么多的人月

那么就得考虑人工价

所以人工价就是每人月的价值

有了这两个数值之后

当然我们对一个项目

我们能够去估算它的一个成本

也就是整个这个工作量乘以人工价

在我们以主要考虑人力成本的情况下

我们得到整个项目的一个成本

那我们就可以去报价

可以去做成本估算了

这是关于这个成本的一个计算

那通过这个项目估算方法的话

当然前面提到了

除了这个代码量

还有这个功能点那个方法

其实这个是更加的客观的

从软件产品的功能度的角度

去估算产品的规模

功能度指的是依靠功能点方法

也就是以项目的这个需求规格说明中

已经得到确认的软件功能为依据

着重分析 要开发系统的这个功能度

并且认为

软件的大小

实际上和软件的功能度是相关的

而与软件功能如何描述是没有关系的

也就是说我要实现这个功能

至于这个功能你是用什么语言

怎么去实现

这个其实是 跟这个成本

是没有关系

或者跟这个项目的这个代价

是没有关系的

它也与功能需求

需要如何设计和实现无关

所以我们可以去通过功能度

来定义一个项目的成本估算

那功能度的话

通常是会具体说明它的功能度方法

区分不同的功能

我们需要确定一个应用系统的边界

应用系统的边界

是把目标应用系统与用户

和其这个相应的外围

它已经有的应用系统

要去分割开来了

那它包括内部功能和外部功能

那它的内部功能就是说

我整个自己内部的一些这个

需要实现的一些功能

外部功能是需要 它需要去交互的

像用户 像已有的一些系统

一个外部边界

所以 通常有五种类型的功能

第一个 是一些外部的输入

第二个呢 是外部的输出

第三个呢 是对于整个这个系统来说

内部的一些逻辑文件

还有我外部的接口文件

还有外部的一些查询

当然这个查询有可能是人的查询

也有可能是已用的其他的一些系统

在这个对接的过程中的一些查询

总括而言

大概总共五类的一个功能

那对于这些功能来说

其实它有各种各样的一些复杂度

所以 我们通常将各种不同的功能

当然包括前面提到的五大类的功能

分成 简单 中等和复杂三个等级

并且 用不同的影响参数

来描述不同的等级

它的这个影响

那我们有了各种类别的这个功能度的描述

也有了对于不同的功能度

它的一个复杂度的分级的描述

而对于每一个分级

我们都赋予了一些影响因子之后

那我们就可以得到

这么一个计算公式

也就是说 我们从需求规格说明中

我们去看一下

这五类功能度到底分别有多少个

而且是对应到简单 中等和复杂的哪一级

然后 对于每一级

我们有这么一个表

我们有它的这个权重值

那我们就可以得到

最后的UFP的一个值

也就对应到整个软件

它的一个未调节的功能点的一个值

包括这里面是前面提到的这五类功能

然后它所对应到细化的功能内容

还有一些分数值

这是一个示例

大家可以看一下 加深一下理解

那我们前面一开始提到的剩下什么

未经调节的 那就说明了

还有一个调节的问题

为什么要调节

因为我们都知道

任何的软件

它都有自己特定的一些自身特性

同样的一个

就是比如说外部的一个输入的功能啊

什么功能也好

对于不同的系统不同的软件来说

它的影响因子其实是很不一样的

跟它所处的环境

跟它的应用目的

都是有关系的

所以 我们从以下两个方面

分解功能点的调节因子

第一个是它的影响因子

我们从这个PPT列的

各种不同的一些因素

来考虑它的一个影响因子

还有一个 是影响级

当然这里面 这个上述影响因子

因为对于软件功能度的影响

它有多大

我们有时候必须加以区分

于是 我们要将影响因子的影响级

这里面分成了从0到5共6级

再考虑上一个PPT里

十四类的这个影响因子

一共 有0到70个等级

因为14个类别 每个类别5级

因此 我们将0到70

把它抽象成是这个0.7的比率之后

我们知道

它左右能调节的分别是0.35 一半

所以我们得到一个在0.65到1.35之间

可以调节的这么一个调节因子

0.65就是说我们前面

未经调节的那个功能点

我们往低了调

1.35往高了调

左右各浮动0.35

加起来0.7

对应到这个0到70的这个分数

这样我们就得到一个CAF的一个调节因子

经过调节因子调节后的功能点

我们称之为交付功能点

那交付功能点 DFP

就等于调节因子乘上未经调节的功能点

交付功能点

它与软件规模的一些关系来说

一些研究通常表明

计算出的功能点的值

可以代表软件的一些规模

所以 可以有效地作为估计成本的依据

当然软件的规模 我们前面提到了

也可以用这个源代码的行数来表示

那功能点 与这个源代码对应关系

我们也通常有一些经验值

这个表比较老

比如说我们一个DFP通常相当于

这个128行左右的这个C程序等等

当然这个是一些经验值

那功能点方法的优点是说

它只与这个需求规格说明文档信息相关

而与交互代码的行数

没有直接的一个关系

另外 DFP与实现的软件的语言 也是无关的

当然它也有一些不足

第一个就是说

对于每个需求规格说明来说

每个人可能有不同的解释和理解

第二个 功能度的复杂性

估计也有很大的主观因素

所以也是因人而异

还有像那个调节因子CAF计算的时候

也会有一些主观的因素

那所有的这些主观的 不确定的

因人而异的因素

加起来就会导致功能点方法不够准确

因为存在较大的一个差异

因此 我们会采用其它的一些方式

比如这里提到的

专家判定的方式

比如说 Delphi方法

那这个Delphi方法

是通过专家判定技术

由多位专家 这个领域的专家

进行成本估算

我们取得多个估算值

然后 把他们的这个估算值

给综合汇总起来

这个是由这个Read公司

提出的一个技术

这个叫Delphi技术

那Delphi技术的步骤

第一个 它组织每位专家

拿一份需求规格说明

和一张记录估计值的表格

让他们进行一些主观的估计

然后 专家详细地研究需求规格说明之后

然后 召开会议

大家一致对这个估算问题

进行一个讨论

然后各个专家

对软件提出三个软件规模的估算值

第一个就是说 它可能的最小规模

第二个是最可能的规模

第三个是可能的最大规模

无记名地去填写一个表格

并且去阐述作此估算的一个理由

然后组织者 再对专家打的分

进行一个汇总

去计算一个期望中值

基于这个期望中值

再召集专家 再次进行开会

然后 再去做一次这个估算

再去进行无记名的填表

以此不断地去反复

也就是综合大家的意见

并且 结合专家的一些领域专家知识

或者背景知识

最终来获得一个可得到

多数专家共识的一个软件规模

最后 通过与历史资料进行类比

根据过去完成项目的规模和成本等信息

我们来推算软件的一个成本

这也是比较科学的

当然还有一类

就是这里面提到的

像COCOMO的一个模型

这个是软件工程专家

在这个软件工程经济学中

所提出的软件估算模型的层次化结构

称为比如像构造式成本的估算模型 COCOMO

COnstructive COst MOdel

它在软件工程行业其实影响非常广泛

也是非常著名的一个估算模型

这里面的话

我们不做特别详细的一个介绍了

大家可以大致地去看一下

但是通常来说

它包涵三种类型的项目

第一种是固有型的项目

这种规模较小

作为简单的项目的这个开发

第二种叫嵌入型项目

第三种叫半独立型项目

这个COCOMO模型的话

它也有三级模型

包括各种各样的这个参数

初级的 中级的

还有包括像那个高级的

好 那我们这一节

我们就讲到这里

谢谢大家

软件理论与工程课程列表:

课程概述

-课程概述

第1章 软件与软件工程

-1.1 软件的本质

--1.1 软件的本质

-1.2 软件工程

--1.2 软件工程

-1.3 软件过程结构

--1.3 软件过程结构

-1.4 过程模型

--1.4 过程模型

-1.5 敏捷开发方法

--1.5 敏捷开发方法

-第1章 习题

--第1章 习题

第2章 需求分析

-2.1 需求工程过程

--2.1 需求工程过程

-2.2 需求获取

--2.2 需求获取

-2.3 需求分析

--2.3 需求分析

-2.4 过程建模

--2.4 过程建模

-2.5 面向对象建模

--2.5 面向对象建模

-第2章 习题

--第2章 习题

第3章 软件设计

-3.1 设计概述

--3.1 设计概述

-3.2 设计的概念

--3.2 设计的概念

-3.3 设计模型元素

--3.3 设计模型元素

-3.4 体系结构概述

--3.4 体系结构概述

-3.5 体系结构风格

--3.5 体系结构风格

-3.6 构件级设计

--3.6 构件级设计

-3.7 UI设计

--3.7 UI设计

-3.8 基于模式的设计

--3.8 基于模式的设计

-第3章 习题

--第3章 习题

第4章 UML方法

-4.1 UML概述

--4.1 UML概述

-4.2 UML 及UML中的事物

--4.2 UML 及UML中的事物

-4.3 UML关系和图

--4.3 UML关系和图

-4.4 UML 图细节(上)

--4.4 UML 图细节(上)

-4.4 UML 图细节(下)

--4.4 UML 图细节(下)

-第4章 习题

--第4章 习题

第5章 软件测试

-5.1 软件测试策略

--5.1 软件测试策略(上)

--5.1 软件测试策略(下)

-5.2 测试传统的应用系统

--5.2 测试传统的应用系统

-5.3 测试面向对象的应用系统

--5.3 测试面向对象的应用系统

-5.4 测试web应用系统

--5.4 测试web应用系统

-5.5 测试移动应用系统

--5.5 测试移动应用系统

-第5章 习题

--第5章 习题

第6章 项目管理

-6.1 软件项目估算

--6.1 软件项目估算

-6.2 软件过程管理

--6.2 软件过程管理

-6.3 软件配置管理

--6.3 软件配置管理

-6.4 项目版本控制及调试

--6.4 项目版本控制及调试

-第6章 习题

--第6章 习题

6.1 软件项目估算笔记与讨论

也许你还感兴趣的课程:

© 柠檬大学-慕课导航 课程版权归原始院校所有,
本网站仅通过互联网进行慕课课程索引,不提供在线课程学习和视频,请同学们点击报名到课程提供网站进行学习。