软件工程（3）

目录

一、软件规模量度

1. 代码行技术

具体方法

优缺点

2. 功能点技术

具体步骤

二、工作量估算

1. 静态单变量模型

1.1 面向KLOC估算模型

1.2 面向FP估算模型

2. 动态多变量模型

3. 基于过程的估算

三、进度计划

估算开发时间的方程

Gantt图

四、软件开发组织形式

五、风险控制

风险类别

风险管理

1. 风险识别

 2. 风险分析

3. 风险驾驭

六、质量控制

软件质量概念

软件质量保证措施

七、配置控制

软件配置

1. 软件配置项

2. 基线

软件配置管理过程 

1. 配置标识

2. 版本控制

3. 变化控制

4. 配置审计

5. 配置状态报告

软件配置管理工具

---

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

一、软件规模量度

常用方法：代码行技术、功能点技术

1. 代码行技术

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

累计；

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

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

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

具体方法：

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

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

2.求三种规模的平均值

3.求程序规模

 

优缺点

优点：

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

缺点：

• 源程序不等于软件
• 实现语言不同代码行数不同
• 不适用非过程语言

2. 功能点技术

依据软件信息域特性和软件复杂性评估结果估算软件规模。

信息域特性：

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

具体步骤：

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

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

 

 （3）计算功能点数FP

                TCF = 0.65 + 0.01 x DI

                FP ＝ UFP × TCF

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

二、工作量估算

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

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

1. 静态单变量模型

   E=A+B*(ev)C

   A、B、C为经验常数，ev是估算变量（LOC或FP）。

1.1 面向KLOC估算模型

（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

1.2 面向FP估算模型

（1）Albrecht&Gaffney模型        E=-13.39+0.0545FP

（2）Maston、Barnett、Mellichamp模型        E=585.7＋5.12FP

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

2. 动态多变量模型

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

E＝〔LOC×B0.333/P〕3×（1/t）4

• t是以月或年为单位的项目持续时间；
• B为特殊技术因子，随着需求增加缓慢增加。
  小程序0.16（5～10KLOC），大程序（超70KLOC）0.39。
• P为生产率参数，反应过程管理、使用语言、系统的复杂程度等对工作量的影响实时嵌入软件2000；系统软件10000；商业系统 28000等。

3. 基于过程的估算

1. 将任务分解为相对较小任务集合。
2. 估算完成每个任务需要的工作量。
3. 累计

三、进度计划

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

如：工作量为20人月项目，可能是下列几种进度表1个人用20个月；4个人用5个月；20个人用1个月等。

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

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

估算开发时间的方程

(1)Walston_Felix模型： 

(2)原始的COCOMO模型：

(3)COCOMO2模型：

(4)Putnam模型：

 E是开发的工作量（人月），T是开发时间（月）

Gantt图

例矩形木板房需重新油漆。三步：刮旧漆，刷新漆，清除溅在窗上油漆。15名工人，5把刮旧漆刮板，5把刷漆刷子，5把清除溅在窗上油漆小刮刀。

 在甘特图上加上菱形标记代表里程碑。

四、软件开发组织形式

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

程序设计小组的组织形式

（1）民主制小组（Democratic Team）

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

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

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

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

通信路径多，组内成员少而精。

若开发组n个人，两人之间都需要通信。

通信路径n×（n－1）/2  

例：假设一个人单独开发软件5000行/人月，4人一组共同开发且采用民主制小组形式，每条路径耗费工作量250行/人月，分析生产率变化情况。

6条通信路径

每人生产率降低

5000－6×250/4＝4625行/人月

（2）主程序员制小组

 

专业化：每名成员完成受过专业训练的工作

层次化：主程序员有绝对权威

 （3）线代程序员组

主程序员由两人担任：技术负责人；行政负责人。分工明确。明确划分技术负责人和行政负责人权限。

 

五、风险控制

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

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

风险两个特性：不确定性：可能发生，可能不发生；损失

风险类别

项目风险：可能对项目的预算、进度、人力、资源、顾客和需求等方面产生不良影响的的潜在问题

技术风险：潜在的设计、实现、接口、验证和维护等方面的问题，此外，规约的二义性、技术的不确定性、陈旧或不成熟的“领先的”技术都可能是技术风险

商业风险：威胁要开发的软件的生存能力

• 开发了一个无人真正需要的产品(市场风险)
• 开发的产品不符合公司的整体商业策略(策略风险)
• 建造了一个销售部门不知如何销售的产品(销售风险)
• 由于重点转移失去了高级管理层支持(管理风险)
• 没有得到充分预算或人力资源保证(预算风险)

风险管理

1. 风险识别

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

 2. 风险分析

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

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

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

3. 风险驾驭

制定具体风险应对策略。

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

六、质量控制

软件质量概念

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

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

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

2. 影响软件质量因素

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

软件质量保证措施

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

1. 技术复审的必要性

保证编码前各阶段文档质量，及早纠正大部分缺欠。

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

2. 走查

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

3. 审查

最系统化严密的评审技术。

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

审查组成员：

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

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

SQA小组代表

4. 程序正确性证明

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

七、配置控制

软件配置

1. 软件配置项

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

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

(3) 数据结构。

2. 基线

IEEE定义：已经通过正式复审的规格说明或中间产品，可作为进一步开发基础，并且只有通过正式的变化控制才能改变它。

基线标志着软件开发过程的各个里程碑。

软件配置管理过程 

1. 配置标识

标识两类对象：

        基本对象和复合对象。

基本对象：

        软件工程师分析、设计、编码和测试时建立“文本单元”。

        如需求规格说明一节，源程序清单、一组测试用例。

复合对象：

        是基本对象或其它复合对象的集合。

对象标识：（名字、描述、资源表、“实现”）

对象标识要考虑层次结构：

例：E-R diagram 1.4 <part-of>data model

         data model <part-of> design specification

其中<part-of>表示一个对象是另外一个对象的一部分。

2. 版本控制

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

版本演变

3. 变化控制

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

变化控制过程：

4. 配置审计

确保所有文档内容变动不超出当初确定软件要求范围。

5. 配置状态报告

对开发过程做系统记录，反映开发活动历史情况。

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

软件配置管理工具