【概述】

软件工程管理是通过计划、组织、控制一系列活动，合理配置使用资源，达到既定目标的活动

其内容包括：软件开发成本、控制、开发人员、组织机构、用户、软件开发文档、软件质量等方面的管理

【软件估算】

概述

软件估算是指以准确的调查资料和项目信息为依据，从估算对象的历史，现状及其规律性出发，运用科学的方法，对估算对象的规模，所需工作量和成本进行的测定

软件估算的内容包括软件规模、工作量和进度，对于估算来说，有些可以做的很仔细，而大多数只是凭主观经验判断

所以多数估算难以做到 10% 以内的精确度，有的甚至误差达几倍，尤其是估算人员经验不足或估算项目没有可参考凭借之时

不同的软件开发阶段，估算的对象和使用的方法都会有所不同，估算的精确度也不一样，一般来说，随着项目进展，对项目内容了解愈多，估算也会越来越精确

软件估算方法

软件估算的方法有很多，大致分为基于分解技术的估算方法和基于经验模型的估算方法两大类

基于分解技术的方法包括：功能点估算法、特征点估算法、对象点估算法、代码行（LOC）估算法、MARK Ⅱ 等

基于经验模型的方法包括：IBM 模型、普特南模型、COCOMO 模型等

其中，代码行技术和功能点技术是最常用的方法

代码行技术

代码行技术通过估计每个功能需要源代码、估计整个软件源程序行数等来进行估计，当程序较小时常用的单位是代码行数（LOC），当程序较大时常用的单位是千行代码数（KLOC）

其优点在于代码是所有软件开发项目都有的产品，而且很容易计算代码行数，其缺点在于源程序并不等于软件，而且实现语言不同代码行数不同，同时不同的开发人员的能力是不同的，并无法很好的估算

功能点技术

功能点技术依据软件信息域特性和软件复杂性评估结果估算软件规模

功能点技术与所用编程语言无关，比代码行要合理，但主观因素过多

信息域特性有：

用户输入数：各用户面向不同应用的输入数据计数
用户输出数：为用户提供面向应用的输出信息
用户查询数：即是一次联机输入，以输出方式产生某种即时响应
文件数：每一个逻辑主文件都应计数
外部接口数：所有将信息传到另一系统中的机器可读写接口

评估过程如下：

1.估算未调整功能点 UFP

一般根据下表计算估算未调整功能点 UFP

2.计算技术复杂性因子 TCF

规定： $TCF=0.65+0.01* DI$

其中，$DI=\sum_{i=1}^14F_i$

$F_i$ 为复杂性校正值，每个因素的尺度是 0~5：

0	1	2	3	4	5
没有影响	偶然的	适中的	普通的	重要的	极重要的

F_i 各项如下：

F1：是同是否需要可靠的备份和恢复？
F2：是否需要数据通信？
F3：是否有分布处理的功能？
F4：性能是否关键？
F5：系统是否运行在既存的高度实用化的操作环境中？
F6：系统是否需要联机数据项？
F7：联机数据项是否需要联机处理以建立多重窗口显示或操作？
F8：主文件是否联机更新？
F9：输入、输出、文件、查询是否复杂？
F10：内部处理过程是否复杂？
F11：程序代码是否被设计成可重用的？
F12：设计中是否包括转换和安装？
F13：系统是否被设计成可重复安装在不同机构中？
F14：应用是否被设计成便于修改和易于用户使用？

3.计算功能点数 FP

规定：$FP=UFP * TCF$

【软件开发进度计划】

概述

项目管理者的目标是定义全部项目任务，识别出关键任务，规定完成各项任务的起、止日期，跟踪关键任务的进展状况，以保证能及时发现拖延进度的情况

为了做到这一点，管理者必须制订一个足够详细的进度表，以便监督项目进度，并控制整个项目

常见的进度表有甘特图和计划评审技术图两种

甘特图

甘特图（Gantt 图），是一种能有效显示行动时间规划的方法，也叫横道图或条形图

其将计划和进度安排两种职能结合在一起，纵向列出项目活动，横向列出时间跨度，每项活动计划或实际的完成情况用横道线表示，还显示了每项活动的开始时间和终止时间，此外，还甘特图还利用菱形标记表示里程碑

某项目进度计划如下：

现在一矩形木板房需重新油漆，过程分为三步：刮旧漆，刷新漆，清除溅在窗上油漆，现在有 15 名工人，5 把刮旧漆刮板，5 把刷漆刷子，5 把清除溅在窗上油漆小刮刀，各项工序估计用时如下：

画出的甘特图如下：

计划评审技术图

计划评审技术图（PERT 图），它采用网络图来描述一个项目的任务网络

不仅可以表达子任务的计划安排，还可以在任务计划执行过程中估计任务完成的情况，分析某些子任务完成情况对全局的影响，找出影响全局的区域和关键子任务，以便及时采取措施，确保整个项目的完成

【软件开发人员组织】

概述

为成功地完成软件开发工作，项目组成员必须以一种有意义且有效的方式彼此交互和通信

如何组织项目组是一个管理问题，管理者必须合理地组织项目组，使项目组有较高生产率，能够按预定的进度计划完成所承担的工作

经验表明，项目组组织得越好，其生产率越高，而且产品质量也越高，组织软件开发人员的方法，取决于所承担的项目的特点、以往的组织经验以及软件开发公司负责人的看法和喜好

民主制程序组

民主制程序员组的小组成员完全平等，享有充分民主，通过协商做出技术决策，对发现错误抱着积极的态度，这种积极态度有助于更快速地发现错误，从而导致高质量的代码，小组有高度凝聚力，组内学术空气浓厚，有利于攻克技术难关

小组成员间的通信是平行的，如果一个小组有 $n$ 个成员，则可能的通信信道有 $\frac{n(n−1)}{2}$ 条

但小组人多的话，通信量会非常大，同时如果组内多数成员技术水平不高，或是缺乏经验的新手，很有可能不能完成项目

主程序员组

为了使少数经验丰富、技术高超的程序员在软件开发过程中能够发挥更大作用，程序设计小组也可以采用主程序员组的组织方式

实际的主程序员应该由两个人来担任：一个是技术负责人，负责小组的技术活动，一个是行政负责人，负责所有非技术的管理决策

由于程序员组的成员人数不宜过多，当软件项目规模较大时，应该把程序员分成若干个小组，每组 2-8 人，并行开发

现代程序员组

现代程序员组把民主制程序员组和主程序员组的优点结合起来，在合适的地方采用分散作决定的方法

这样做有利于形成畅通的通信渠道，以便充分发挥每个程序员的积极性和主动性，集思广益攻克技术难关

【软件过程能力成熟度模型】

软件过程能力成熟度模型（Capability Maturity Model，CMM）是用于评估软件能力与成熟度的一套标准，它由美国卡内基—梅隆大学软件工程研究所推出，侧重于软件开发过程的管理及工程能力的提高与评估，是国际软件业的质量管理标准

软件过程能力成熟度模型认为，软件质量难以保证的问题在很大程度上是由管理上的缺陷造成的，而不是由技术方面的问题造成的

因此，软件过程能力成熟度模型从管理学的角度出发，通过控制软件的开发和维护过程来保证软件产品的质量

它的核心是对软件开发和维护的全过程进行监控和研究，使其科学化、标准化，能够合理地实现预定目标。