【软件工程】软件工程知识点提纲8

1. 软件规模的度量和估算

代码行技术、功能点技术

1.1 代码行技术

为了使得对程序规模的估计值更接近实际值,可以由多名有经验的软件工程师分别做出估计。

每个人都估计程序的最小规模（a）、最大规模（b）和最可能的规模（m），分别算出这3种规模的平均值a ̅、b ̅、和m ̅之后，再用下式计算程序规模的估计值：
L=(a ̅+b ̅+4m ̅)/6

1.2 功能点技术

• 信息域特点
  • 输入项数（Inp）：用户向软件输入的项数，这些输入给软件提供面向应用的数据。
  • 输出项数（Out）：软件向用户输出的项数，它们向用户提供面向应用的信息。
  • 查询数（Inq）：查询即是一次联机输入，它导致软件以联机输出方式产生某种即时响应。
  • 主文件数（Maf）：逻辑主文件的数目。
  • 外部接口数（Inf）：机器可读的全部接口的数量，用这些接口把信息传送给另一个系统。
• 估算功能点的步骤
  • 计算未调整的功能点数UFP
    首先，把产品信息域的上述五个特性（Inp、Out、Inq、Maf和Inf）都分类为简单级、平均级或复杂级，并根据其等级为每个特性分配一个功能点数（例如，一个简单级的输入项分配3个功能点，一个平均级的输入项分配4个功能点，而一个复杂级的输入项分配6个功能点）。
    UFP=a_1×Inp+a_2×Out+a_3×Inq+a_4×Maf+a_5×Inf
    
  • 计算技术复杂性因子TCF
    影响因素的确定：根据软件的特点，为每个因素分配一个从0（不存在或对软件规模无影响）到5（有很大影响）的值。然后，用下式计算技术因素对软件规模的综合影响程度DI（其中F_i表示该技术因素的影响因素）：
    
    技术复杂性因子TCF由下式计算：
    TCF=0.65+0.01×DI
    因为DI的值在0～70之间,所以TCF的值在0.65～1.35之间。
  • 计算功能点数FP
    FP=UFP×TCF

2. 软件工作量估算

分解技术、经验模型

2.1 分解技术

纵向为分解模块
横向为交流、计划、风险分析、设计、编程、测试等模块，单位为人月

2.2 经验模型

公式给出再进行计算

3. 工作量估算

• 静态单变量模型
  E=A+B×（ev）^C
  A、B、C经验数据导出的常数
  E以人月为单位的工作量
  ev估算变量（KLOC或FP）
  KLOC千行代码数
  • 面向KLOC的估算模型
    • 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
  • 面向FP的估算模型
    • Albrecht&Gaffney模型
      E=-13.39+0.0545EP
    • Maston，Barnett和Mellichamp模型
      E=585.7+15.12EP
• 动态多变量模型
  E=（LOC×B^0.333/P）3×（1/t）^4
  E以人月或人年为单位的工作量
  t以月或年为单位的项目持续时间
  B特殊技术因子：对于较小的程序KLOC=5~15，B=0.16；对于超过70KLOC的程序，B=0.39
  P是生产率参数：开发实时嵌入式软件P=2000；开发电信系统和系统软件P=10000；对于商用应用系统来说P=28000
• COCOMO2模型
  
  E开发工作量（以人月为单位）
  a是参数模型
  KLOC是估计的源代码行数（以千行为单位）
  b是模型指数
  f_i （i=1~17）是成本因素

为了确定工作量方程中模型指数b的值，原始的COCOMO模型把软件开发项目划分成组织式、半独立式和嵌入式这样3种类型，并指定每种项目类型所对应的b值（分别是1.05，1.12和1.20）。COCOMO2采用了更加精细得多的b分级模型，这个模型使用5个分级因素W_i(1≤i≤5),其中每个因素都划分成从甚低（W_i=5）到特高（W_i=0）的6个级别，然后用下式计算b的数值：

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

4. 进度计划

4.1 估算开发时间

• Walston_Felix模型
  T=2.5E^0.35
• 原始的COCOMO模型
  T=2.5E^0.38
• COCOMO2模型
  T=3.0E^(0.33+0.2×（b-1.01）)
• Putnam模型
  T=2.4E^(1/3)
  E是开发工作量（以人月为单位）
  T是开发时间（以月为单位）

4.2 Gantt图

例子：油漆工刷墙
首先刮掉旧漆，然后刷上新漆，最后清除溅在窗户上的油漆。一共分配了15名工人去完成这项工作，然而工具却很有限：只有5把刮旧漆用的刮板，5把刷漆用的刷子，5把清除溅在窗户上的油漆用的小刮刀。
思路：由5名工人用刮板刮掉第1面墙上的旧漆（这时其余10名工人休息），当第1面墙刮净后，另外5名工人立即用刷子给这面墙刷新漆（与此同时拿刮板的5名工人转去刮第2面墙上的旧漆），一旦刮旧漆的工人转到第3面墙而且刷新漆的工人转到第2面墙以后，余下的5名工人立即拿起刮刀去清除溅在第1面墙窗户上的油漆……。这样安排使每个工人都有活干，因此能够在较短的时间内完成任务。
假设木板房的第2、4面墙的长度比第1、3面墙的长度长一倍，此外，不同工作需要用的时间长短也不同，刷新漆最费时间，其次是刮旧漆，清理油漆需要的时间最少。下表列出了估计每道工序需要用的时间。可以使用Gantt图描绘上述流水作业过程：
在时间为零时开始刮第1面墙上的旧漆，两小时后刮旧漆的工人转去刮第2面墙，同时另5名工人开始给，1面墙刷新漆，每当给一面墙刷完新漆之后，第3组的5名工人立即清除溅在这面墙窗户上的漆。从下图可以看出，12小时后刮完所有旧漆，20小时后完成所有墙壁的刷漆工作，再过2小时后清理工作结束。因此全部工程在22小时后结束，如果用前述的第一种做法，则需要36小时。

4.3 工程网络

上图事件2既是作业1—2（刮第1面墙上的旧漆）的结束，又是作业2—3（刮第2面墙上旧漆）和作业2—4（给第1面墙刷新漆）的开始。也就是说，只有第1面墙上的旧漆刮完之后，才能开始刮第2面墙上旧漆和给第1面墙刷新漆这两个作业。工程网络显式地表示了作业之间的依赖关系。
上图中还有一些虚线箭头，它们表示虚拟作业，也就是事实上并不存在的作业。例如，事件4既是给第1面墙刷新漆结束，又是给第2面墙刷新漆开始（作业4—6）。但是，在开始给第2面墙刷新漆之前，不仅必须已经给第1面墙刷完了新漆，而且第2面墙上的旧漆也必须已经刮净（事件3）。也就是说，在事件3和事件4之间有依赖关系，或者说在作业2—3（刮第2面墙上旧漆）和作业4—6（给第2面墙刷新漆）之间有依赖关系，虚拟作业3—4明确地表示了这种依赖关系。注意，虚拟作业既不消耗资源也不需要时间。

4.4 估算工程进度

先将每个作业分成开始和结束，连接关系，以最大值依赖关系顺序计算最早时刻，以最小值依赖关系逆序计算最迟时刻）

例：事件4的最早时刻：EET=max{2+3，6+0}=6
事件10的最迟时刻：LET=23-2=21
事件9的最迟时刻：LET=21-1=20
事件8的最迟时刻：LET=min{21-6，20-0}=15

4.5 关键路径

事件的最早时刻和最迟时刻相同

4.6 机动时间

动机时间=（LET）_结束-（EET）_开始-持续时间

5. 软件人员组织

• 民主制程序员组（非正式的组织方式）
  小组成员完全平等，享有充分民主，通过协商做出技术决策。小组成员之间的通信是平行的，若小组内有n个成员﹐则可能的通信信道共有n（n-1）/2条。程序设计小组的人数不能太多，否则组员间彼此通信的时间将多于程序设计时间。优点：组员们对发现程序错误持积极的态度，这种态度有助于更快速地发现错误，从而导致高质量的代码；组员们享有充分民主，小组有高度凝聚力，组内学术空气浓厚，有利于攻克技术难关。
• 主程序员组
  因为软件开发人员多数比较缺乏经验；程序设计过程中有许多事务性的工作，例如，大量信息的存储和更新；多渠道通信很费时间，将降低程序员的生产率。
• 现代程序员

6. 软件质量保证

• 软件质量：与软件产品满足规定的和隐含的需求的能力有关的特征或特性的全体。
  • 功能与性能方面：软件应该能够按照既定的要求进行工作，与明确规定的功能和性能需求一致；软件要保证能够可靠的工作，合法的输入下正确运行，非法输入和意外事件可安全处理。
  • 软件结构方面：
    • 要求系统内部结构清晰，易于软件人员阅读和理解，方便对软件的修改和维护
    • 要求系统具备良好的人机交互界面，方便用户使用
  • 开发标准与文档方面：软件开发应该与明确成文的开发标准相一致，而且要遵循一些软件开发准则，软件文档资料也必须齐全。
• 软件质量保证
  • 应用技术手段：软件质量保证活动开始于帮助分析员获得高质量的规格说明书，帮助设计员应用高效的技术方法和工具，并且始终贯穿整个开发过程。
  • 组织技术评审：在软件开发过程的每个阶段结束后，都需要组织技术评审，可以及早发现软件开发过程中可能引起的潜在错误，并对质量进行评价。
  • 加强软件测试：软件测试是软件质量保证的重要手段，可以发现软件中大多数隐蔽的错误。
  • 推行软件工程标准：一旦标准确定，就应该重视标准，并在软件开发中统一遵循。
  • 控制软件变更：软件质量的一个主要威胁来自于对软件的修改和变更。在修改的过程中常常会引起一些新的潜在错误。因此，应严格控制软件的修改和变更。
  • 对软件质量进行度量：软件质量保证的一个重要目标也是对软件质量进行跟踪，这就需要对软件质量进行度量，并对软件质量情况及时记录和报告。

7. 软件配置管理

• 软件配置
  • 软件配置项
  • 基线
• 软件配置管理过程
  • 标识软件配置中的对象
  • 版本控制
  • 变化控制
  • 配置审计
  • 状态报告