软工导论知识框架（九）软件项目管理

通过计划、组织、控制一系列活动，合理配置使用资源，达到既定目标的活动。项目管理优先于任何技术之前，并且贯穿于整个软件生命周期全过程。

---

一.软件规模度量

1.代码行技术

估计每个功能需要源代码（参考类似项目的历史数据）；

累计；

估计整个软件源程序行数。

当程序较小时常用的单位是代码行数（LOC）， 当程序较大时常用的单位是千行代码数（KLOC）。

具体步骤：

• 多名（n）有经验软件工程师估计

a:程序最小规模；b:程序最大规模；m:程序最可能规模

• 求三种规模的平均值

 

• 求程序规模

 

优点：代码是所有软件开发项目都有的“产品”，而且很容易计算代码行数。

缺点：源程序不等于软件， 实现语言不同代码行数不同，不适用非过程语言。（局限性）

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

信息域特性：    

(1) 用户输入数：各用户面向不同应用的输入数据计数。  

(2) 用户输出数：为用户提供面向应用的输出信息。    

(3) 用户查询数：即是一次联机输入，以输出方式产生某种即时响应。    

(4) 文件数：每一个逻辑主文件都应计数。    

(5) 外部接口数：所有将信息传到另一系统中的机器可读写接口。

步骤：

（1）估算未调整功能点UFP

（2） 计算技术复杂性因子

（3）计算功能点数FP

 FP＝UFP×TCF

功能点数与所用编程语言无关，比代码行合理。但主观因素过多。（类似AHP层次分析法）

二.工作量估算

工作量是软件规模函数，单位为人月（pm）

(支持大多数估算模型的经验数据，都是从有限个项目的样本 集中总结出来的，因此，没有一个估算模型可以适用于所有类型的软件和开发环境)

1.静态单变量模型（有关软件规模的函数，与时间无关）

E=A+B*(ev)C    A、B、C为经验常数，ev是估算变量（LOC或FP）

面向LOC（代码行）估算模型

（1）Walston－Felix模型      E=5.2×（KLOC）0.91

（2）Bailey-Basili模型      E=5.5＋0.73×（KLOC）1.16

（3）Boehm简单模型      E=3.2×（KLOC）1.05

（4）Doty模型（KLOC>9）      E=5.228×（KLOC）1.407

面向FP（功能点）估算模型

(1) Albrecht&Gaffney模型    E=-13.39+0.0545FP

(2) Maston、Barnett、Mellichamp模型    E=585.7＋5.12FP

         不同的结果主要原因是：这些模型多数都是仅根据若干 应用领域中有限个项目的经验数据推导出来的，适用范围 有限。因此，必须根据当前项目的特点选择适用的估算模 型，并且根据需要适当地调整（例如，修改模型常数）估 算模型。

2.动态多变量模型

        工作量是软件规模和开发时间两个变量的函数。是根据从4000多个当代软件项目中收集的生产率数据推导出来的。

 3.基于过程的估算    

（1）将任务分解为相对较小任务集合。    

（2）估算完成每个任务需要的工作量。    

（3）累计

三.进度计划

        工作量估算完，估算开发时间。

        管理复杂工程项目，最好办法是把工程项目分解成许多逻辑步骤（作业），安排作业顺序，确定每项作业需要用时间，及作业开始和终止时间。

        把工作量分配给特定的软件工程任务并规定完成各项任务的起止日期，从而将估算出的项目工作量分布于计划好的项目持续期内。

 Gantt图（横道图）

 

 四.组织形式

多名软件开发人员合理组织起来，分工协作完成开发工作。

1.民主制小组（Democratic Team）

组内成员之间可以平等交换意见。      

优点：发挥每个成员积极性。      

缺点：削弱个人责任心和必要权威作用。      

适用领域：适合于研制时间长、开发难度大项目。

问题：通信路径多，组内成员少而精

若开发组n个人，两人之间都需要通信，则通信路径n×（n－1）/2  

 2.主程序员制小组

• 专业化：每名成员完成受过专业训练的工作
• 层次化：主程序员有绝对权威

 3.现代程序员组

主程序员由两人担任：

技术负责人and行政负责人，分工明确，明确划分技术负责人和行政负责人权限

软件项目规模较大，程序员组分成若干个小组。

 将民主式程序员组与主程序员组的优点结合进来，形成包含分散决策组织形式。

---

控制：使软件项目按预定计划和预期目标进行。接下来的五六七均为控制的内容~

五.风险管理

1.现代项目管理与传统项目管理的不同之处就是引入了风险管理技术

2.风险：在给定情况下和特定时间内，那些可能发生的结果与预期结果之间的差异，差异越大，风险越大

3.风险两个特性：

• 不确定性：可能发生，可能不发生；                      
• 损失

4.风险的类别

• 项目风险：可能对项目的预算、进度、人力、资源、顾客和需求等方面产生不良影响的的潜在问题
• 技术风险：潜在的设计、实现、接口、验证和维护等方面的问题，此外，规约的二义性、技术的不确定性、陈旧或不成熟的“领先的”技术都可能是技术风险
• 商业风险：威胁要开发的软件的生存能力

 5.风险管理：

风险识别：采用系统化方法，识别特定项目已知和可预测的风险。

 

风险分析：对已识别风险进行估计和评价，确定风险发生的概率与后果。

• 定性分析:评估已识别项目风险影响和可能性，按可能产生影响排序。
• 定量分析:量化分析每一风险概率及对项目造成后果，得出风险大小   和严重程度等。

      可忽略的、轻微的、严重的、灾难性的四个级别。

风险驾驭：制定具体风险应对策略。

• 风险规避是设法降低风险出现的可能性；
• 风险缓解是设法减少风险产生的影响；
• 风险转移是将风险转移给第三方；
• 风险接受是采取应急方案应对风险的发生。

六.质量管理

1、软件质量定义（ANSI/IEEE）：    与软件产品满足规定的和隐含的需求能力有关的特征或 特性全体。

(1) 软件需求是度量软件质量的基础。

(2) 按规范化标准定义开发准则，不遵守软件质量不能保证。

(3) 不能忽略隐含需求。

2、影响软件质量因素  

用软件质量模型描述，较著名模型为McCall等人1979年提出，这些因素是从管理角度对软件质量的度量。

 3.软件质量保证措施

• 基于非执行的测试：复审或评审
• 基于执行的测试：软件测试 程序正确性证明

（1）技术复审的必要性：保证编码前各阶段文档质量，及早纠正大部分缺欠。    

         需求规格说明，数据规格说明，概要设计说明等。

（2）走查 ：是开发者的一次友好的会议，需要仔细规划，有明确的目的、日程、 持续时间和参与人员，许多小组以星期为单位走查。    会后将问题分发给相应人员进行解决。

（3）审查：最系统化严密的评审技术。    

      审查范围比走查广泛、步骤较多。    

     审查组成员：

        组长（同时是技术负责人）；

        负责开发工作的项目组代表（当前阶段和下一阶段）

（4）程序正确性证明    用数学方法验证程序与说明一致。对评价小程序适用（工作量小） 

七.配置管理

1.软件配置项：

(1) 计算机程序（源程序及目标程序）；

(2) 文档（包括技术文档和用户文档）；

(3) 数据结构

2.基线：IEEE定义：已经通过正式复审的规格说明或中间产品，可作为进一步开发基础，并且只有通过正式的变化控制才能改变它。基线标志着软件开发过程的各个里程碑。

3.管理过程

（1）配置标识

标识两类对象：基本对象和复合对象。

• 基本对象：软件工程师分析、设计、编码和测试时建立“文本单元”。    如需求规格说明一节，源程序清单、一组测试用例。
• 复合对象：是基本对象或其它复合对象的集合。

（2）版本控制

版本控制是对配置对象不同版本标识和跟踪过程。保证软件技术的一致性。    

（3）变化控制：变化控制是建立一套组织结构和控制规程，有意识地控 制软件的变更过程。    变化控制过程： 

（4）配置审计：确保所有文档内容变动不超出当初确定软件要求范围。   

（5）配置状态报告：对开发过程做系统记录，反映开发活动历史情况。

软件配置项赋上新的或修改后标识，产生配置状态报告条目 变更被CCA（变更授权人）批准，产生配置状态报告条目 配置审计结果，产生配置状态报告条目