软件项目管理文档格式.docx

软件项目管理文档格式.docx

《软件项目管理文档格式.docx》由会员分享，可在线阅读，更多相关《软件项目管理文档格式.docx（11页珍藏版）》请在冰豆网上搜索。

6

输出项数Out

输出系数a2

5

7

查询数Inq

查询系数a3

主文件数Maf

文件系数a4

10

15

外部接口数Inf

接口系数a5

UFP＝a1×

Inp＋a2×

Out＋a3×

Inq＋a4×

Maf＋a5×

Inf

第二步，计算技术复杂性因子TCF

技术复杂性因子由14个方面的技术因素构成，显示了各种技术因素对软件复杂度的影响。

，TCF的值在0.65~1.35之间。

各项技术因素的含义分别为：

序号

Fi

技术因素

1

F1

数据通信

2

F2

分布式数据处理

F3

性能标准

F4

高负荷的硬件

F5

高处理率

F6

联机数据输入

F7

终端用户效率

8

F8

联机更新

9

F9

复杂的计算

F10

可重用性

11

F11

安装方便

12

F12

操作方便

13

F13

可移植性

14

F14

可维护性

第三步，计算功能点数FP：

FP＝UFP×

TCF

功能点技术的优点是比较准确可信，与编程语言无关，缺点是在各项技术因素的复杂因子取值时有很大的主观性。

2、软件开发工作量估算（人月）

软件开发的工作量是软件规模的函数，但是由于软件开发的复杂性，其函数关系只能总结出一些经验公式，缺乏通用的模型。

（1）静态单变量模型

静态单变量模型是指软件开发的工作量仅仅是软件规模的函数，通常具有如下的形式：

E=A+B×

（ev）C

其中E是估算的工作量（单位是人月），A、B、C是经验常数，ev是估算变量，代表软件规模。

常用的静态单变量模型有：

●面向代码行的模型

Walston_Felix模型：

E=5.2×

（KLOC）0.91

Bailey_Basili模型：

E=5.5+0.73×

（KLOC）1.16

Boehm简单模型：

E=3.2×

（KLOC）1.05

Doty模型（KLOC>

9时）：

E=5.288×

（KLOC）1.047

●面向功能点的模型

Albrecht&

Gaffney模型：

E=-13.39+0.0545FP

Maston,Barnett和Mellichamp模型：

E=585.7+15.15FP

2）动态多变量模型

动态多变量模型也称为“软件方程式”，它是从4000多个软件项目中搜集的数据推导出的经验公式，在该模型中软件开发的工作量是软件规模、软件复杂度、开发单位的开发能力和项目持续时间等多个变量的函数。

具体公式为：

E=（LOC×

B0.333/P）3×

（1/t）4

E：

估算的工作量

LOC：

代码行数

B：

特殊技术因子，随着软件规模和过程复杂度增加，对于较小的程序（KLOC＝5～15），B＝0.16；

对于超过70KLOC的程序，B＝0.39；

P：

生产率系数，反映开发单位的软件开发能力和软件的复杂程度之间的关系，可从开发单位的历史数据中计算得到，典型值在2000到28000之间；

t：

项目持续时间

从公式可以看出，软件开发的工作量与软件规模的3次幂成正比，与生产率的3次幂成反比，与项目持续时间的4次幂成反比。

（3）COCOMO2模型

COCOMO模型（构造性成本模型Constructivecostmodel）由Boehm在1981年首次提出，1997年升级为COCOMO2模型。

COCOMO2分为三个层次的模型，分别用于不同阶段或不同类型的软件开发项目：

●应用系统组成模型：

用于估算构建原型的工作量，在构建是要采用大量的可重用构件。

●早期设计模型：

用于估算体系结构设计的工作量。

●后体系结构模型：

用于完成体系结构设计后到软件完全实现的软件开发工作量

以后体系结构模型为例，其工作量估算值是软件规模的幂函数，但由多项系数进行修正：

a：

模型系数，与历史开发数据有关，典型值为3.0

KLOC：

b：

模型指数，

模型指数b由5个分级因素决定：

●项目先例性

●开发灵活性

●风险排除度

●项目组凝聚力

●过程成熟度

每个因素赋予一个0～5的值Wi，取值越高表示对工作量的增长影响越大。

最终的b值为：

因此b的取值范围为1.01～1.26。

fi（i=1～17）：

成本因素

成本因素fi分为4类，根据其重要程度和对于工作量影响的大小赋予一定的值。

二、人员组织

软件开发项目的人员组织主要指开发小组的组织模式。

人员组织的目标是既能增强开发小组整体的开发能力，保证开发的进度和质量。

在软件工程的发展历史上，出现过以下几种人员组织方式。

1、民主制程序员组

民主制程序员组中的程序员没有等级区别，完全平等，通过协商进行任务分配和技术决策。

因为每个人的主动性和工作积极性都能得到激发和保护，团队的凝聚力比较强，规则和标准比较容易形成和遵守，同时团队内的信息共享和知识流动也比较顺畅。

民主制程序员组的缺点在于通讯路径太多，同时因为缺少权威指导，要求所有成员都具有较高的技术水平和工作热情，对外接口也不太明确，团队开发工作容易受到各种外力的影响。

2、主程序员组

主程序员组最早在IBM公司采用，他是由一个技术能力强、开发经验丰富的主程序员为核心来构建开发小组，所有小组成员都只与主程序员之间建立通讯管道，避免了整个开发小组的通讯路径呈指数性增长，也可以使最重要的开发工作被有效地控制，保证软件开发的进度和质量。

在主程序员组中，主程序员是开发小组的领导，工作安排、技术决策、对外接口都由他来承担，同时主程序员还要完成几乎所有的关键性技术工作，包括分析、设计、编码、测试及文档撰写。

主程序员有两个助手：

行政秘书和后备程序员。

行政秘书负责在主程序员的领导下具体管理财务、人事、后勤等各方面的具体事务，减轻主程序员的工作量。

后备程序员是主程序员的备份，他虽然不做决策，但要协助主程序员完成各项工作，详细了解开发工作的所有细节，以在需要的时候随时代替主程序员。

在主程序员组中，还有若干程序员，他们接受主程序员分配的任务，完成具体模块的设计、编程和测试，其工作结果由主程序员负责审查和接纳。

主程序员组就是Brooks在《人月神话》里推荐的“外科手术小组”的人员组织方式，其优点是能保持概念的完整性，团队接口简单，内部通讯代价低，团队成员的分工明确，工作效率理论上会比较高，主程序员的水平也可以保证软件的质量。

但是这种人员组织模式在现实中确会遇到很多问题，例如主程序员的工作压力太大，对他在技术和管理上双重的能力要求不容易满足，团队其它成员工作积极性不高，最后很容易变成一个人享受好的待遇，但在巨大压力下单打独斗。

3、双组长制

双领导制是在一个开发小组中，设立技术组长和行政组长两个领导：

技术组长类似于主程序员，主要负责小组的技术决策和开发管理；

行政组长则负责人事、后勤、业绩考核等工作，两个组长是平级的。

双组长制可以避免主程序员陷入大量行政事务管理中耗费时间和精力，又可以避免对程序员的开发结果技术审查与工作业绩考核挂钩，更好地保障软件开发质量，同时整个团队的通讯路径也比较少，工作效率高。

这种人员组织方式必须建立在两个组长配合默契，沟通良好的基础上，彼此权限的协调决定了开发工作的管理模式和效率，这是天然的困难之处。

同时，每个程序员仍然是被动的开发主体，积极性不容易调动。

在微软公司的早期产品开发阶段，双组长制是主要的人员组织模式。

三、进度计划

软件开发的进度保障是软件工程要解决的主要问题之一。

对于整体如何估算和控制开发进度，目前的方法以时间段分解为主。

当一个长期的软件开发过程被分解为小的阶段时，进度的估计和管理都会变得比较容易。

需要注意的问题是：

在一定的开发工作量下，开发时间不会因为开发人员的数量增加而线性下降。

开发人员越多，沟通和协调的代价越大，根据Boehm的研究，软件项目的开发时间最多只能减少到正常开发时间的75%。

而在已经落后的项目中增加人员，不仅不会缩短开发时间，而且会使得进度更加延后。

除了时间分解的方法，软件开发中还会大量遇到开发任务耦合的问题。

当多个开发任务存在相互关联和依存时，如何安排和协调开发顺序就变得非常重要。

下面介绍两种在软件开发项目中进行任务安排的实用工具。

1、甘特图

甘特图是由亨利·

劳伦斯·

甘特（HenryLaurenceGantt,1861—1919）在一战期间发明的，由于它简单有效，成为了工程项目中历史最悠久、应用最为广泛的进度计划工具。

甘特图由横道图形表示出各项任务的开始和结束时间，并可以纵向比较和协调安排。

例如：

要开发三个类，它们之间存在关系，

对每个类的开发工作量估算如下：

定义时间（天）

实现时间（天）

测试时间（天）

类A

类B

类C

总体

由于每个类的定义、实现、测试都需要顺序进行，而类B的测试必须在类A的测试结束后才能进行，类C的定义必须在类B的定义结束后才能进行，可以画出甘特图如下：

时间

任务

类A定义

类A实现

类A测试

类B定义

类B实现

类B测试

类C定义

类C实现

类C测试

总体测试

甘特图不仅可以表示各任务的进度，更重要的是它可以用于安排人力，甘特图的纵向线就表示了当前同时需要并行完成的任务数量，也就是需要的人力和资源数量。

2、工程网络

工程网络是另一种非常有效的进度计划图形工具，它不仅可以描述各项任务的开始和结束时间，而且可以非常清楚地表达任务之间的依赖关系。

在工程网络中，用圆圈表示事件，是任务的开始和结束，带箭头的实线段表示具体执行的任务，带箭头的虚线段表示事件间的依赖关系。

圆圈左半部的数字代表事件编号，右上部的数字为该事件允许发生的最早时间EET，右下部的数字表示该事件允许发生的最晚时间LET。

（1）计算EET

整个工程网络的第一个事件的EET为0，然后顺序计算各个事件的最早时间EET：

a、考虑进入该事件的所有任务；

b、对于每个任务都计算它的持续时间与最早开始时间之和；

c、选取上述和数中最大值为该事件的最早时间EET。

（2）计算LET

整个工程网络的最后一个事件的LET等于其EET，然后逆序计算各个事件的最晚时间LET：

a、考虑离开该事件的所有任务；

b、对于每个任务都计算它的最晚结束时间与持续时间之差；

c、选取上述差值中最小值为该事件的最晚时间LET。

（3）寻找关键路径

工程网络中最早时间和最晚时间相同的事件之间的任务定义了关键路径，是必须准时开始和结束的任务。

沿关键路径所有任务的总持续时间就是整个项目完成的最短时间。

（4）计算机动时间

不在关键路径上的任务，其结束事件的最晚时间减去其开始事件的最早时间，再减去这个任务的持续时间，就是其机动时间。

机动时间可以灵活地加以应用，以最大程度地利用资源。