如何对项目进行估算（成本，人力，资源等等）

因为是第一次管理项目，所以有点糊涂
给点建议

那得根据你的平台，开发的实力而定了，

那是否能提供一个比较好的介绍文档
谢谢！

对人力、财力、资源、进度的管理

主要任务：制定开发进度计划表，开发人员的分工和组织，开发成本、风险的估量和管理，质量的保障管理等等。

1.1 软件度量
即对软件的规模和功能进行模式。

1.1.1  度量、测量和估算
度量：对软件产品、开发过程、资源进行定量描述。

测量：对软件产品的质量进行测试描述

估算：对软件产品、过程、资源进行预测。主要在签订合同、制定计划时使用

p/24

1.1.2  面向规模的度量
用软件的程序代码行的数目表示该软件的规模。

p/25：生产率、成本、出错率的计算

 

特点：估算软件的规模相对简单

缺点：在开发初期估算代码行较困难，适用于过程式程序设计语言。

          存在不公平因素

1.1.3  面向功能的度量
根据事物信息处理程序的基本功能进行度量，在软件的开发初期能估算出软件的规模。

p/26：生产率、成本、出错率等的计算

 

优点：与程序设计语言无关，在开发初期就能进行功能点的度量

缺点：涉及到的主观因素较多，有些数据不易采集，功能点EP值没有直观的物理意义

1.1.4  代码行度量与功能点度量的比较
代码行度量依赖于程序设计语言，而功能点度量不依赖于程序设计语言。

1.2 软件项目估算
成本估算涉及因素：人、技术、环境、政策等

估算方法1：参照已完成的类似项目估算成本和工作量

估算方法2：分解成若干个小系统，逐个估算，然后进行整个项目的估算。

估算方法3：按生命周期进行划分，估算各个阶段的成本和工作量，然后进行汇总合计。

估算方法4：根据实验或历史数据得出本项目的成本和工作量的经验计算公式。

1.2.1  代码行、功能点和工作量估算
p/29：以开发某个CAD软件为例

p/30图2.7：先用代码行度量各个子系统的的规模，估算工作量，然后计算成本，最后得出整个软件的总成本。

p/30图2.8：用上述方法2和3估算工作量，然后估计每个人月的费用，最后得出整个软件的总成本。

1.2.2  经验估算模型之一：CoCoMo模型
1981年Boehm提出的“构造性成本模型（Constructive Cost Model）”：

在静态、单变量模型的基础上进行构造，把整个模型分为3个层次：基本、中间、详细。

基本层次模型：用于开发初期，估算整个系统的工作量和时间。

中间层次模型：估算各个子系统的工作量和开发时间。

详细层次模型：估算相对独立的软部件（模块）。

1.2.3  经验估算模型之二：Putnam模型
1978年Putnam提出的适合于大型软件（30人年）的估算模型：

是一个可用于软件开发的各个阶段的动态多变量的模型。以各个阶段的实测数据为基础，画出工作量的分布曲线，从而估算出成本。

p/34图2.3

特点：曲线所反映的各个阶段的工作量一目了然。

缺点：不能反映人员、计算机资源、项目的属性。

1.3 软件质量度量
对开发出来的软件的质量进行估计个评价。

1.3.1  软件质量定义及三层次度量模型
1983年ANSI/IEEEstd729提出的软件质量的定义：

软件产品必须满足规定的、隐含的以及与需求能力有关的全部特征和特性，包括：

1 软件产品的质量满足并达到用户所要求的程度；

2 软件各种属性的组合程度；

3 用户对软件产品的综合反映程度；

4 软件在使用过程中满足用户要求的程度。

 

1976年Boehm提出的评价软件质量的概念：60个软件质量度量的公式，软件质量度量的层次模型。

 

1978年Walters和McCall提出：包括质量要素、准则、度量的三层次软件质量度量模型。

p/35图2.5 McCall的软件质量度量模型。

1.3.2  软件质量要素
软件质量要素：影响软件质量的重要因素。

划分为3类：

一 表现软件的运行特征的要素：

        正确性、可靠性、有效性、完整性、可用性

二 表现软件承受被修改的能力方面的要素：

        可维护性、灵活性、可测试性

三 表现软件对新环境的适应程度方面的要素：

        可移植性、可重用性、可互操作性

 

1.可修改性：能够对软件进行修改而不增加软件系统的复杂性。

                是一个很重要、也是最难以度量和达到的目标。  

2.有效性：使得软件系统能最有效地利用计算机的时间和空间资源。

3.可靠性：软件防止由于概念、设计和结构等方面的不完善而造成软件系统失效的能力，具有挽回因操作不当而造成软件系统失效的能力。是一个应首要考虑的目标。

4.可理解性：系统结构清晰，需求反映明确。有助于软件的维护、移植和重用。

5.可维护性：是软件工程中一个十分重要的目标。

6.可重用性：降低软件开发成本，提高软件使用效率。

7.可适应性：易于软件的推广和流行。

8.可移植性：该特性支持软件的可重用性和可适应性。

9.可追踪性：包括正向追踪和逆向追踪，使得软件在测试或维护时所发现的问题通过追踪而找出原因。

10.可互操作性：多个软件元素相互通信并协同完成任务的能力。

11.正确性：程序满足规格说明和完成用户目标的程度。

12.完整性：控制没有被授权的人员使用软件和数据的程度。

13.可用性：学会使用本软件的易难程度（包括操作软件、深入数据的准备、输出结果的解释）。

14.灵活性：改变一个操作程序所需要的工作量。

15.可测试性：使得测试程序具有预定功能所需要的工作量。

16.可互操作性：两个或多个系统交换信息并相互使用已交换的信息的能力。

 

p/36表2.11 各质量要素之间的关系。

1.3.3  软件质量要素评价准则
通过评价准则间接地测量软件的质量要素。

定义评价准则的基础：是确定影响软件质量要素的属性。

这些属性必须满足两个条件：

1 能够比较完整、准确地描述软件质量要素；

2 比较易于量化和测量。

 

 McCall共定义了21种准则：p/37

质量要素与评价准则之间的关系：p/38图2.12

 

1985年，国际标准化组织（ISO）建议：软件质量度量模型由三层组成：

1 高层―――软件质量需求评价准则层（SQRC）

2 中层―――软件质量设计评价准则层（SQDC）

3 底层―――软件质量度量评价准则层（SQMC）

上述三层分别对应 McCall等人提出的软件质量要素、评价准则和度量。并且，ISO认为，高层和中层应建立国际标准，便于在国际范围内推广应用软件的质量管理，而底层可以由使用者自己制定。

p/39图2.13 显示了ISO高层8要素和中层23个评价准则之间的关系。

1.4 软件复杂性度量
软件的复杂性度量是软件度量的一个重要组成部分。

1.  软件复杂性和度量原则
K.Magel：从6个方面描述软件的复杂性

1 理解程序的难度

2 纠错、维护程序的难度

3 向他人解释程序的难度

4 按指定方法修改程序的难度

5 根据双击文档编写程序的工作量

6 执行程序时需要资源的程度

 

一般，软件复杂性度量模型应遵循的基本原则：

1 软件复杂性与程序大小的关系不是线性的

2 控制结构复杂的程序比较复杂

3 数据结构复杂的程序比较复杂

4 转向语句使用不当的程序比较复杂

5 循环结构比选择结构复杂，选择结构又比顺序结构复杂

6 语句、数据、子程序和模块在程序中的次序对复杂性有影响

7 全程变量、非局部变量较多时程序比较复杂

8 参数按地址调用比按值调用复杂

9 函数副作用比显式参数传递难于理解

10 具有不同作用的变量共用一个名字时较难理解

11 模块间、过程间联系密切的程序比较复杂

12 嵌套深度越深程序越复杂

2.  控制结构的复杂性度量
T.J.McCade 1976年提出：程序控制结构图  p/40

V(G)：程序结构图的巡回秩数

程序结构复杂性度量：V(G)

T.J.McCade认为：V(G)>10时，模块内部结构复杂、程序编码和测试困难，软件复杂。

3.  文本复杂性度量
从编写的程序来度量复杂性

1.5 软件可靠性度量
可靠性是软件的一个十分重用的要素。

1.  软件可靠性的概念
软件故障：即软件错误，无耗损性故障，存在设计、编程实现时的人为错误。

2.  软件修复和软件有效性
软件修复：排除和改正软件程序中的错误。

不可修复系统：不允许程序停止运行的计算机系统称不可修复系统。应建立双机系统。

可修复系统：允许程序停止运行的计算机系统称不可修复系统。

软件修复包括：发现故障、纠正错误、测试、系统重新启动。

平均修复时间：修复故障的平均所需时间

 

有效性：在某段时间内，系统能够正常运行，称系统在这段时间内有效。

有效性函数A(t)：在时间0～t，100个相同系统中能够正常运行到时间t的系统数。

例：A(300)=0.92

表示：100台相同的系统在运行300小时时间内，有92台运行了300小时，8台无法正常运行而待修。

 

可靠性：在某段时间内，系统不出现任何故障而能够正常运行，称系统在这段时间内可靠性

可靠性函数R(t)：在时间0～t，100个相同系统中能够无故障正常运行到时间t的系统数。

例：R(300)=0.92

表示：100台相同的系统在运行300小时时间内，有92台无故障运行了300小时，8台出现了故障。

3.  软件可靠性估算
利用可靠性模型进行估算。

可靠性模型分类：宏观模型、微观模型

宏观模型：从程序中残留错误的角度建立模型，用统计的方法确定模型中的参数。

微观模型：以程序的控制结构和程序语句分析为基础。

 

p/44-45：错误植入模型

软件平均故障间隔时间估算

1.6 软件开发过程的管理
1.6.1  风险分析
风险分析包括：风险标识、风险估算、风险评价、风险管理

 

1 风险标识：

  项目风险：因项目在预算、进度、人力、资源、顾客、需求等方面的估计有误对软件开发产生的不良影响。

  技术风险：因软件在设计、实现、接口、验证、维护过程中可能存在潜在的问题，或采用了不可靠的技术等对项目造成的危害。

  商业风险：因软件没有人要、或不知、或无法推销本软件而造成的危害。

 

2 风险估算：

  估算造成或影响风险的因素，以及风险所造成的损失。

 

3 风险评价和管理：

  尽可能地估计各种风险，然后逐一列出并评价风险的程度，对这些风险进行密切关注和严格管理。

  p/49：表2.14

1.6.2  进度安排
对软件的开发进度进行管理：制定开发进度表

制定进度表的2 种方法：

1 根据软件的最后交货日期进行倒排日程。

2 根据模型和资源到位情况制定开发的初步计划和交货日期。

 

制定进度时应注意的问题：

1 任务分配、人力资源分配、时间分配要与工程进度相协调

2 任务分解和并行化

3 工作量分布合理

4 工程进度安排       p/52：图2.12

1.6.3  软件开发标准
软件开发标准由政府部门、国防部门或国际性组织制定。

p/52～54

1.6.4  软件质量保证
高质量的软件必须具备的3个具备条件：

1 满足软件需求定义的功能个性能

2 所有文档符合事先确定的软件开发标准

3 软件的特点和属性遵循软件工程的目标和原则。

 

SQA：软件质量保证

SQA活动包括：

1 在需求分析阶段对软件质量提出要求，比自顶向下逐步分解为可以度量、控制的质量要素，为以后的软件开发各阶段的软件测量、定量和定性分析打好基础。

2 研究并确定软件开发的方法和工具。

3 对软件开发的各个阶段进行软件工程的正式技术评审(FTR)。

4 制定并执行软件测试策略和测试计划。

5 生成软件文档并对文档的改变进行控制。

6 保证软件的开发过程和选用的软件开发标准相一致。

7 建立软件质量要素的测量机制。

8 记录SQA活动并生成各种SQA报告。

 

FTR：软件工程的正式技术评审

FTR活动：开会评审软件产品，会议结束通过评审报告。

FTR报告内容：

会议主持人、参加人员、评审产品、评审内容、发现的问题、评审意见。

1.6.5  软件开发人员的组织和分工
软件开发的各个阶段所需要的技术人员的类型、层次和数量不同。在整个软件的开发期间，人员的选择、分配和组织关系到软件开发的效率、进度和质量。

 

“主程序员”组织：

由主程序员和若干个助手（程序员等）组成软件开发小组。

主程序员：负责规划、协调和审查工程的全部技术活动。

程序员：软件的具体分析和开发

1.6.6  软件项目的开发过程管理
管理：开发工程跟踪、质量、进度控制

 

跟踪方式：

定期召开项目工作会议，每个组员汇报任务进展情况和问题

在各个阶段，请专家和用户进行评审

按进度表进行检查

及时向开发人员了解情况

1.7 软件项目管理中的CASE工具
项目信息：项目合同、工程计划、进度表、人员组织、分工、产品评审文件、文档等。

 

软件项目管理工具：正文/表格/图形的输入、输出、编辑工具

                      工作量及成本估算工具

                      工程计划制定工具

                      项目进度制定工具

                      软件质量度量工具

                      软件复杂性度量工具

                      软件可靠性度量工具

                      报告生成工具

                      配置管理工具

                      版本控制工具

上述工具均具有统一的人机界面，并按一定的规则访问软件工程信息库中的信息。

 

好啊！值得学习！

d

<img src="images/post/smile/dvbbs/em02.gif" /><img src="images/post/smile/dvbbs/em01.gif" />

你如果从没有做个类似的项目，你就估算不出准确的项目成本！光有书本没有用哦。

<P>这东西算算就行了,只要不错问题,只会多,不会少!</P>

<img src="images/post/smile/dvbbs/em05.gif" />