软件工程笔记

软件概念

软件

软件 = 程序+数据+文档

• 程序
  按事先设计的功能和性能需求执行的指令序列
• 数据
  用于程序正常操纵信息的数据结构
• 文档
  与程序开发、使用、维护相关的图文资料

软件危机

在计算机软件的开发和维护过程中所遇到的一系列严重问题，通常导致开发效率降低、开发质量降低。

产生原因

• 客观上：
  逻辑部件 规模庞大
• 主观上：
  忽视需求分析（例如：错误地认为有一个目标的概括描述就可以着手编写程序，许多细节以后再补充）
  错误认为：软件开发=程序编写
  轻视软件维护

软件工程

1. 应用系统化的、学科化的定量的方法，来开发维护软件，将工程应用到软件
2. 对1中各种方法的研究
3. 要素：方法（包含：结构化方法、面向对象的方法）、工具、过程

四个发展阶段

1. 传统软件工程阶段
2. 对象工程
3. 过程工程
4. 构建工程

软件过程模型

软件过程，软件开发中所遵循的路线图。

概念

软件过程模型是从软件项目需求定义至软件运行维护的整个生命周期过程中系统开发、运行和维护所实施的全部过程。
为软件开发的各个阶段提供一种过程规范。

常用模型

1. 瀑布模型（经典生命周期模型）
2. 增量过程模型：增量模型、RAD模型
3. 演化过程模型：原型模型、螺旋模型
4. 喷泉模型

瀑布模型

特点

1. 分为固定的几个阶段，次序固定，自上而下
2. 以文档为驱动
3. 阶段间具有顺序性和依赖性
4. 每个阶段必须完成规定的文档，每个阶段结束前完成文档审查，及早改正错误

缺点

1. 实际项目很少遵守瀑布模型提出的顺序，需求可能变更
2. 客户通常难以清晰描述所有需求
3. 客户需要有耐心，只有项目完成才能看到所开发的软件

变体

V模型：强调了过程中的质量保证

增量过程模型

用于不确定因素多、资金到位不足、无法提出完整需求的开发，增量可并行开发、独立开发

从部分需求出发、先建立不完整系统、再反复扩充完善

增量模型采用了基于时间的线性序列 ， 每个确定线性序列都会输出该软件的一个“增量”。

特点

• 增量
  小而可用的软件
• 特点
  在前面增量的基础上开发后面的增量

优点

1. 增量包概念的引入 ， 以及它不需要提供完整的需求 。 只要有一个增量包出现，开发就可以进行。
2. 在项目的初始阶段不需要投入太多的人力资源。
3. 增量可以有效地管理技术风险。

缺点

1. 每个增量必须提供一些系统功能，有时开发者难以根据客户需求给出大小适合的增量

原型模型

客户定义一个总体目标集，但是他们并不清楚系统的具体输入输出；或开发者不确定算法的效率、软件与操作系统是否兼容以及客户与计算机交互的方式。此时，原型法是很好的选择 。

优点

1. 快速为用户提供一个可以看到的原型软件
2. 可有效应对需求的不确定性
3. 原型系统可以逐步演化为最终系统，避免浪费人力

缺点

1. 整个软件可能是随意搭成的 ， 开发者没有考虑整体软件质量与长期的可维护性
2. 采用了一些折中手段让系统快速运行起来，比如不合适的操作系统、开发语言、低效算法等

螺旋模型

该模型结合了瀑布模型和原型模型的特点。螺旋模型强调风险管理，因此该模型适用于大型系统的开发。
螺旋模型沿着螺线旋转 ，在笛卡尔坐标的四个象限上分别表达了四个方面的活动 ：

• 制定计划 。
  确定软件目标 ， 选定实施方案 ， 弄清项目开发的限制条件。
• 风险分析。
  分析所选方案，考虑如何识别和消除风险。
• 实施工程。
  实施软件开发。
• 客户评估 。
  评价开发工作 ， 提出修正建议 。

优点

1. 支持用户需求的动态变化。
2. 原型可看作形式的可执行的需求规格说明，易于为用户和开发人员共同理解，还可作为继续开发的基础，并为用户参与所有关键决策提供了方便 。
3. 特别强调原型的可扩充性和可修改性 ， 原型的进化贯穿整个软件生存周期，这将有助于目标软件的适应能力。
4. 为项目管理人员及时调整管理决策提供了方便，进而可降低开发风险 。

缺点

1. 如果每次迭代效率不高，致使迭代次数过多将会增加成本并推迟提交时间
2. 使用该模型需要有相当丰富的风险评估经验和专门知识，要求开发队伍水平较高

适应场合

支持需求不明确、特别是大型软件系统的开发，并支持面向规格说明 、 面向过程 、 面向对象等多种软件开发方法，是一种具有广阔前景的模型

基于构建模型

软件构件由厂家作为产品供应，通过定义良好的接口提供特定功能，这些构件能够集成到正在构建的软件中。
本质上是演化模型，具有很多螺旋模型的特点，差别是采用了预先打包的软件构件开发应用系统

四个阶段

• 需求
  与其它模型相同，这里不再赘述。
• 组件分析
  根据需求规格搜索可满足该需求的组件 。 通常情况下，没有完全匹配的情况，因而组件通常需要加以修改。
• 系统设计
  与其它模型的系统设计有所不同，因为该模型是基于重用的。设计者必须考虑到重用的概念，但遗憾的是，如果没有可重用的组件，还要设计新的软件。用的。设计者必须考虑到重用的概念，但遗憾的是，如果没有可重用的组件，还要设计新的软件。
• 开发和集成
  在这个阶段 ， 组件集成到系统中。

优点

1. 能最大程度复用已经开发的软件，减少开发费用，缩短开发周期

缺点

1. 模型复杂
2. 需求可能折中 ， 进而导致系统可能不完全符合需求
3. 无法完全控制所开发系统的演化

统一过程模型

一种用例驱动，以架构为核心，迭代并且增量的软件过程
结合面向对象分析与设计方法，最重要的体现是统一建模语言 （Unified Modeling Language, UML ）
时间上有四个顺序阶段 ： 初始阶段 、 细化阶段 、 构造阶段和交付阶段，每个阶段涉及9 种核心工作流的多种工作流

优点

1. 多次迭代，每次迭代有不同工作重点，有效识别风险
2. 采用了面向对象的分析与设计方法 ，且增量开发

缺点

1. 过程比较复杂 ， 可能导致效率低下
2. 必须要有严格的过程管理 ， 架构不正确也将引起全面错误

敏捷过程模型

特点

增量、快速、可执行原型来适应不可预测的变更

12原则

1. 尽早 、持续地交付有价值的软件来使客户满意。
2. 即使在开发的后期，也欢迎需求变更。
3. 交付的时间间隔越短越好。
4. 业务人员和开发人员必须天天都在一起工作。
5. 围绕有积极性的个人构建项目。
6. 最富有效果和效率的信息传递方法是 面对面交谈。
7. 可运行软件是进度的首要度量标准。
8. 敏捷过程提倡 可持续的开发速度。
9. 不断地 关注优秀的技能和好的设计会增强敏捷能力。
10. 简单（使不必做的工作最大化的艺术）是必要的。
11. 最好的架构、需求和设计出自于自组织团队。
12. 每隔一定时间，团队会 反省如何才能更有效地工作。

主要敏捷软件过程

• 极限编程
  只对即时需求做设计，不考虑长远需求
  沟通 、 简明 、 反馈 、 鼓励 、 尊重
• 自适应软件开发
  分为思考协作和学习个阶段
• 动态系统开发方法
  一个应用系统80% 的功能可以在20%的时间内完成

软件开发面临的三大问题

1. 提前预测哪些需求是稳定的而哪些需求会变更非常困难。同样，预测项目进行中客户优先级的变更也很困难。
2. 对很多软件来说，设计和构建是交错进行的。
3. 从制定计划的角度来看，分析、设计、构建和测试并不像我们所设想的那么容易预测。

解决方法：增量、快速、可执行原型来适应不可预测的变更—敏捷开发

需求分析

定义

确定系统必须具有的功能和性能，系统要求的运行环境并预测系统前景。以一种清晰、简洁、一致且无二义性的方式，陈述待开发系统的一个集合。

过程

需求获取->需求提炼->需求描述（撰写需求规格说明书）->需求验证

需求规格说明书

• 确定系统的运行环境要求
  硬件环境（网络、服务器等）
  软件环境（ 操作系统、 数据库等 ）
• 系统的功能性需求
  系统需要支持的若干功能点
  输入
  输出
  存储
  计算
• 系统的非功能性需求
  响应时间
  可靠性
  安全性
  可扩展性
• 系统接口

需求模型

基于场景的模型

场景建模描述用户如何与系统以及使用软件时出现的特定活动序列进行交互

用例图

• UML 用例图(User Case Diagram)
  从系统使用者的角度所理解的系统总体功能
• 参与者 （Actor ）
  在系统外部与系统直接交互的人或事物(如系统、进程）
  参与者是角色(role) 而不是具体的人
  参与者作为外部用户( 而不是内部)与系统发生交互作用
• 用例（Use Casxe ）
  系统外部可见的一个系统功能单元。
  系统的功能由系统单元所提供，并通过一系列系统单元与 一 个或多个参与者之间交换的消息所表达。
• 关系（Relationship)
  参与者与用例之间的关联关系，用实线表示，表示参与者与用例之间的交互，参与者使用这个用例功能。
  泛化关系
  用例与用例之间的关系：① 包含关系 ② 扩展关系
  
  • 包含关系
    用带<include>的虚线表示，A为基用例，B为包含用例时，A指向B。
    包含用例必须被执行 ，不需要满足某种条件
    包含用例的执行不会改变基用例的行为
  • 扩展关系
    用带<extend>的虚线表示，A为扩展用例，B为基用例时，A指向B。
    扩展用例是可选的，如果缺少扩展用例不会影响到基用例的完整性
    扩展用例在一定条件下才会执行，并且其执行会改变基用例的行为

活动图

泳道图

类模型

类是组具有相同数据结构和相同操作的对象集合。
类是一组具有相同数据结构和相同操作的对象集合。类可视为一个具有类似特性与共同行为的对象摸板，可用来产生对象。
类是对象的抽象，而对象是类的具体实例。

类（Class ）在UML中通常以实线矩形框表示。
• 类的名称（Name ）必须的，用于同其它类进行区分
• 类的属性（Attribute ）
• 类的操作 （Operation）

类之间的关系

• 关联关系
1. 命名关联
2. 命名关联中的角色
3. 确定关联的多重性
• 聚合/复合关系
1. 聚合关系描述的是部分与整体的关系， UML中使用从部分指向整体的端点带有空心菱形的线段表示
2. 复合关系描述的也是部分和整体的关系，但是语义更强，部分的生命周期取决于整体的生命周期， UML中组成使用从部分指向整体的 UML中组成使用从部分指向整体的端点带有实心菱形的线段表示
• 泛化关系
1. 描述类的一般和具体之间的关系，表明“是一种”关系
2. UML 中泛化关系使用从子类 （ 具体 ） 指向超类 （ 一般 ） 的带有空三角形箭头的实线表示。

行为模型

流模型

• 用数据流图来描述系统逻辑功能模型的一种图形工具
• 数据流图从数据传递和加工的角度，以图形的方式刻画数据流从输入到输出的移动变换过程
• 数据流图的基础是功能分解
  
  
  
  
  

系统设计

定义

软件系统或组建架构、构件、接口和其他特性的定义过程及该过程的结果。

原则

1. 设计应是一种架构
2. 设计应该时模块化的
3. 设计应采用正确清楚的表示方式
4. 设计应包含数据、体系结构、接口、接口组件

程序流程图

1. 程序流程图又称程序框图，是用统一规定的标准符号描述程序运行具体步骤的图形表示。
2. 程序框图的设计是在处理流程图的基础上 ，通过对输入输，将出数据和处理过程的详细分析，将计算机的主要运行步骤和内容标识出来。
3. 程序框图的优点是采用规范的符号，画法简单清晰。
   
   

顺序图

1. 顺序 图显示参与交互作用的参与者与对象 ， 以及它们生成的按时间排序的事件，是系统的动态建模
2. 描述消息在对象间如何传递
3. 按时间顺序实现对业务控制流的建模
4. 顺序图是二维图，在水平轴上显示角色（对象），在垂直轴上从上到下显示消息的顺序
5. 每条垂直线称为对象的生命线，表示对象存在的时间
6. 在生命线上**的方法叫**（控制焦点），作为垂直的矩形显示在顺序图上 ， 表示此时间段内对象执行相应操作
7. 对象间的通信用消息表示

五要素：参与者、对象、生命线、控制焦点、消息

• 参与者：参与者发出情况或者接收系统的服务。
• 对象：对象是特定行为与属性的集合，在描述中有意义的集合
• 生命线：用于描述对象的存在周期，对象下方的虚线就是该对象的生命线。
• 控制焦点：是指活动者或对象处于执行状态的时间段。**状态的时间段，从**开始到空闲状态结束。
• 消息：用于描述对象间交互的方式及内容。同步消息、异步消息、返回消息、自关联消息

消息：
1.同步消息=调用信息：一个对象向另一个对象发出同步消息(调用)后，将处于阻塞状态，直等到另外对象的回应。–消息的发送者把控制递给消息的接收者，然后停止活动，等待消息的接收者放弃或者返回控制。（三角箭头实线）
2.异步消息：发出异步消息(信号)后，该对象可进行其他操作，不需要等到另一个对象的响应。–消息发送者通过消息把信号传递给消息的接收者，然后继续自己的活动，不等待接受者返回消息或者控制。异步消息的接收者和发送者是并发工作的。（箭头实线）
3.返回消息：同步消息的返回消息。（箭头虚线）
4.自关联消息：用来描述对象内部函数的互相调用。–表示方法的自身调用以及一个对象内的一个方法调用另外一个方法（三角箭头实线）

软件测试

黑盒测试

等价类划分

1. 某个输入域的子集合。在该子集合中，各个输入数据对于揭露程序中的错误都是等效的。
2. 把所有可能的输入数据，即程序的输入域划分成若干部分，然后从每一部分中选取少数有代表性的数据做为测试用例

划分等价类来确定测试用例的步骤

（1）确定有效等价类；
（2）确定无效等价类；
（3）对所有等价类列表，并标号；
（4）设计测试用例，使其覆盖尽可能多的有效等价类，重复这个过程，直至所有有效等价类被覆盖完；
（5）设计测试用例，使每个测试用例均只覆盖一个无效等价类，重复这个过程，直至所有无效等价类被覆盖完。掌握边界值法。

等价类的类型

• 有效等价类
  对规格说明而言，有意义、合理的输入数据所组成的集合
  检验程序是否实现了规格说明预先规定的功能和性能
• 无效等价类
  对规格说明而言，无意义的、不合理的输入数据所组成的集合
  检查被测对象的功能和性能的实现是否有不符合规格说明要求的地方

等价类的划分原则

1. 按照区间划分——在输入条件规定了取值范围或值的个数的情况下，可以确定一个有效等价类和两个无效等价类
2. 按照数值划分——在规定了一组输入包括 n入且数据（假设括个输值），并程序要对每一个输入值分别进行处理的情况下，可确定 n 个有效等价类（每个值确定一一 个有效等价类）和一个无效等价类（所有不允许的输入值的集合）
3. 按照数值集合划分—— 在输入条件规定了输入值的集合（集合中的输入值具有同等效果）或规定了“必须如何”的条件下，可以确定一个有效等价类和一个无效等价类 （ 该集合有效值之外）
4. 按照限制条件或规则划分—— 在规定了输入数据必须遵守的规则或限制条件的情况下，可确定一个有效等价类 （ 符合规则 ） 和若干个无效等价类（从不同角度违反规则）

白盒测试

• 判定结构测试
  语句覆盖
  判定覆盖
  条件覆盖
  判定-条件覆盖
• 循环测试
  简单循环
  嵌套循环
  串接循环

软件测试策略

• 单元测试：针对每个单元的测试， 以确保每个模块能正。 常工作为目标 。
• 集成测试：对已测试过的模块进行组装，进行集成测试。目的在于检验与软件设计相关的程序结构问题 。
• 确认（有效性）测试：是检验所开发的软件能否满足所有功能和性能需求的最后手段 。
• 系统测试：检验软件产品能否与系统的其他部分（比如，硬件 、 数据库及操作人员 ） 协调工作 。
• 验收（用户）测试：检验软件产品质量的最后一道工序。主要突出用户的作用 ， 同时软件开发人员也应有一定程度的参与。

单元测试

单元测试针对每个程序的模块 ，主要测试5个方面的问题 ：—— 模块接口、局部数据结构、边界条件、独立的路径和错误处理

模块接口

• 这是对模块接口进行的测试 ， 检查进出程序单元的数据流是否正确。模块接口测试必须在任何其它测试之前进行。
• 模块接口测试至少需要如下的测试项目：
（1 ）调用所测模块时的输入参数与模块的形式参数在个数、属性 、 顺序上是否匹配；
（2 ）所测模块调用子模块时，它输入给子模块的参数与子模块中的形式参数在个数、属性、顺序上是否匹配；
（3 ）是否修改了只做输入用的形式参数；
（4 ）调用标准函数的参数在个数、属性、顺序上是否正确；
（5 ） 全局变量的定义在各模块中是否一致。

局部数据结构

• 在模块工作过程中 ，必须测试模块内部的数据能否保持完整性，包括内部数据的内容、形式及相互关系不发生错误
• 对于局部数据结构，应该在单元测试中注意发现以下几类错误：
（1 ）不正确的或不 致的类型说明 。
（2 ）错误的初始化或默认值。
（3 ）错误的变量名 ， 如拼写错误或书写错误。
（4 ）下溢、上溢或者地址错误。

路径测试

• 在单元测试中 ， 最主要的测试是针对路径的测试 。 测试用例必须能够发现由于计算错误、不正确的判定或不正常的控制流而产生的错误
• 常见的错误有：误解的或不正确的算术优先级 ； 混合模式的运算 ； 错误的初始化；精确度不够精确；表达式的不正确符号表示。
• 针对判定和条件覆盖 ， 测试用例还要能够发现如下错误：不同数据类型的比较；不正确的逻辑操作或优先级；应当：不同数据类型的比较；不正确的逻辑操作或优先级；应当相等的地方由于精确度的错误而不能相等；不正确的判定或不正确的变量；不正确的或不存在的循环终止；当遇到相等的地方由于精确度的错误而不能相等；不正确的判定或不正确的变量；不正确的或不存在的循环终止；当遇到分支循环时不能退出 ； 不适当地修改循环变量

边界条件

• 边界测试是单元测试的最后一步 ， 必须采用边界值分析方法来设计测试用例，认真仔细地测试为限制数据处理而设置的边界处 ， 看模块是否能够正常工作
• 一些可能与边界有关的数据类型如数值、字符、位置、数量 、 尺寸等 ， 还要注意这些边界的首个 、 最后一个、最大值、最小值、最长、最短、最高、最低等特征
• 在边界条件测试中 ， 应设计测试用例检查以下情况：
（1 ）在n 次循环的第0 次、1 次、n 次是否有错误。
（2 ）运算或判断中取最大值 、 最小值时是否有错误。
（3 ）数据流、控制流中刚好等于、大于、小于确定的比较值是否出现错误 。

出错处理

• 测试出错处理的重点是模块在工作中发生了错误 ， 其中的出错处理设施是否有效。
• 检验程序中的出错处理可能面对的情况有：
（1）对运行发生的错误描述难以理解 。
（2）所报告的错误与实际遇到的错误不一致。
（3）出错后 ， 在错误处理之前就引起系统的干预。
（4）例外条件的处理不正确。
（5）提供的错误信息不足，以至于无法找到错误的原因。

执行过程

单元测试常常是和代码编写工作同时进行的，在完成了程序编写、复查和语法正确性验证后，就应进行单元测试用例设计。
辅助测试模块有两种：
（1 ）驱动模块(Drive) 用来模拟被测试模块的上一级模块，相当于被测模块的主程序。它接收数据，将相关数据传送给被测模块，启动被测模块，并打印出相应的结果。，相当于被测模块的主程序。它接收数据，将相关数据传送给被测模块，启动被测模块，并打印出相应的结果。
（2 ）桩模块(Stub) 用来模拟被测模块工作过程中所调用的模块。它们一般只进行很少的数据处理。

集成测试

集成测试就是将软件集成起来后进行测试。又称为子系统测试 、 组装测试 、 部件测试等
集成测试主要可以检查诸如两个模块单独运行正常 ， 但集成起来运行可能出现问题的情况 。
集成测试是 种范围很广的测试 ， 当向下细化时，就成为单元测试。

主要方法

• 自顶向下的集成方法
  
  1. 这种组装方式将模块 ， 按系统程序结构， 沿控制层。 从 次自顶向下进行集成 。 从属于主控模块的按深度优先方式（纵向）或者广度优先方式（横向）集成到结构中去
  2. 自顶向下的集成方式在测试过程中较早地验证了主要的控制和判断点
  3. 选用按深度方向集成的方式 ，可以首先实现和验证一个完整的软件功能
  4. 缺点是桩的开发量较大
• 自底向上的集成方法
  
  1. 自底向上集成方法是从软件结构最底层的模块开始，按照。 接口依赖关系逐层向上集成以进行测试
     由于是从最底层开始集成，对于一个给定层次的模块，它（ 包 ） 已 的子模块 （ 包括子模块的所有下属模块 ） 已经集成并测试完成，所以不再需要使用桩模块进行辅助测试。在模块的测试过程中需要从子模块得到的信息可以直接运行子模块得到。
  2. 自底向上的集成方法的优点是每个模块调用其他底层模块都已经测试，不需要桩模块；
  3. 缺点是每个模块都必须编写驱动模块；缺陷的隔离和定位不如自顶向下。
• 冒烟方法
  
  1. 将已经转换为代码的软件构件集成为构造（build） 。 一个构造包括所有的数据文件 、 库 、 可复用的模块以及实现一个或多个产品功能所需的工程化构件
  2. 设计一系列测试以暴露影响构造正确地完成其功能的错误。其目的是为了发现极有可能造成项目延迟的业务阻塞 （show stopper ） 错误
  3. 每天将该构造与其他构造，以及整个软件产品集成起来进行冒烟测试 。 这种集成方法可以是自顶向下，也可以自底向上

回归测试

在集成测试策略的环境中，回归测试是对某些已经进行过的测试的某些子集再重新进行一遍 ， 以保证上述改变不会传播无法预料的副作用或引发新的问题。
在更广的环境里 ， 回归测试就是用来保证 （ 由于测试或其他原因的）改动不会带来不可预料的行为或另外的错误。
• 回归测试可以通过重新执行所有的测试用例的一个子集人工地进行，也可以使用自动化的捕获回放工具来进行。
• 回归测试集包括三种不同类型的测试用例：
（1）能够测试软件的所有功能的代表性测试用例
（2）专门针对可能会被修改而影响软件功能的附加测试
（3）针对修改过的软件成分的测试

系统测试

• 系统测试是从用户使用的角度来进行的测试，主要工作是将完成了集成测试的系统放在真实的运行环境下进行测试，用于功能确认和验证。
• 系统测试基本上使用黑盒测试方法
• 系统测试的依据主要是软件需求规格说明

主要内容

• 功能性测试
• 可靠性测试
• 压力测试
• 性能测试
• 恢复测试
• 安全测试
• 其他的系统测试还包括配置测试、兼容性测试、本地化测试 、 文档测试 、 易用性测试等

验收测试

有用户参加的系统测试，验收是否满足用户需要

软件管理

定义

计划、协调、度量、监控、控制及报告等管理方法在软件开发和维护中的具体应用，以保证整个过程是系统的、有原则的、可量化的(IEEE610.12-90)。

四大要素

• 人员（People ）：关键业务领域：招聘、选拔、绩效管理、培训、薪酬、职业发展、组织和工作设计、团队管理、培训、薪酬、职业发展、组织和工作设计、团队/ 文化的发展。
• 产品(Product) ： 在策划 一 个项目以前 ， 应当建立产品的目标和范围，应考虑其他解决办法，以及技术和管。 理应当被约束 。
• 过程(Process) ：软件开发的一个全面计划。
• 项目(Project) ： 理解成功项目管理的关键因素 ， 掌握项目计划、监控和控制的一般方法。

对项目进行WBS分解

编制项目进度网络图

项目的关键路径

关键路径：从项目开始到项目完成有许多条路径，在整个网络图中最长的路径就叫关键路径
非关键路径（noncritical path): 在整个网络图中非最长的路径都叫非关键路径。

软件规模度量

定义

一种量化衡量方法,使得人们可以理解和把握软件项目的(生产)效率(或者所需要的劳动量)

目的

• 描述（项目和过程）
• 评估（状态和质量）
• 预测（为计划）
• 改进（产品质量和过程性能）

方法

1. 直接测量（面向规模的度量）
2. 功能点度量（面向功能的度量）
3. 项目工作量度量
4. COCOMO模型

面向规模的度量

o 生产率: PM = L / E, L 表示代码总量( 单位：KLOC)，E表示软件工作量( 单位 ： 人月)
o 每千行代码的平均成本：CKL = S / L ，S 为软件项目总开销
o 文档与代码比: Dl = Pd / L ，Pd 表示文档页数率
o 代码出错率: EQRl = Ne / L ，Ne表示代码出错的数目

优点

1. 简单易行，自然直观

缺点

1. 依赖于程序设计语言的表达能力和功能
2. 软件开发初期很难估算出最终软件的代码行数
3. 对精巧的软件项目不合适
4. 只适合于过程式程序设计语言

面向功能的度量

用软件的功能表示软件的规模

• “功能”不能直接度量，需要依靠其他度量结果导出
• 功能点度量涉及多种因素
• 项目开发初期就可估算出
• 功能点计算目前主要基于经验公式

功能点的计算方法

FP=UFC×TCF=UFC×(0.65+0.01×∑Fi)$$FP=UFC\times TCF=UFC\times (0.65+0.01\times \sum F_i)$$

• UFC (Unadjusted Function Component) : 未调整功
  数能点计数, 5个信息量的”加权和”
• TCF (Technical Complexity Factor): 技术复杂度因
  子
• Fi : 14个因素的“复杂性调节值” (i =1..14) 0.65, 0.01 都是经验常数

UFC相关的五类组件：内部逻辑文件（ILF, Internal Logical Files ）、外部接口文件（EIF, External Interface Files）、外部输入（EI, External Input）、外部输出（EO, External Output ）和用户查询 （EQ, External Query）

Fi的取值(0,1,2,3,4,5):0- 没有影响 ，1- 偶有影响，2- 轻微影响，3- 平均影响，4- 较大影响，5- 严重影响

• 系统需要可靠的备份和复原吗？
• 系统需要数据通信吗？
• 系统有分布处理功能吗？
• 性能是临界状态吗？
• 系统是否在一个实用的操作系统下运行？
• 系统需要联机数据项吗？
• 联机数据项是否在多屏幕或多操作之间进行切换？
• 需要联机更新主文件吗 ？
• 输入、输出、查询和文件很复杂吗？
• 内部处理复杂吗？
• 代码需要被设计成可重用吗？
• 设计中需要包括转换和安装吗？
• 系统的设计支持不同组织的多次安装吗？
• 应用的设计方便用户修改和使用吗？

优点

1. 与程序设计语言无关, 在开发前就可以估算出软件项目
   事的规模( 事前)

不足

1. 没有直接涉及算法的复杂度，不适合算法比较复杂的软件系统；
2. 功能点计算主要靠经验公式，主观因素比较多
3. 数据不好采集

COCOMO模型

CoCoMo 模型是 一 个综合经验模型 ， 模型中的参数取值来自于经验值，并且综合了诸多的因素、比较全面的估算模型

• 基本COCoMo 模型
  • 系统开发的初期，估算整个系统的工作量( 包括维护)和软件开发和维护所需的时间
• 中间COCoMo 模型
  • 估算各个子系统的工作量和开发时间
• 详细COCoMo 模型
  • 估算独立的软构件，如各个子系统的各个模块的工作量和开发时间

基本CoCoMo模型

• E=a∗(kLOC)b$E=a\ast (kLOC{)}^b$;E 是工作量( 人月) ，a 和b 是经验常数
• D=c∗Ed$D=c\ast E^d$ ;D 是开发时间( 月) ，c 和d 是经验常数
• 其中，a,b,c,d为经验常数，其取值见下表

软件类型	a	b	c	d	适用范围
组织型	2.4	1.05	2.5	0.38	各类应用程序
半独立型	3.0	1.12	2.5	0.35	各类编译程序等
嵌入型	3.6	1.20	2.5	0.32	实时软件、OS等

中间CoCoMo模型

• E=a∗(kLOC)b∗EAF$E=a\ast (kLOC{)}^b\ast EAF$
• 其中，E表示工作量(人月) ，EAF表示工作量调节因子，a,b

软件类型	a	b
组织型	3.2	1.05
半独立型	3.0	1.12
嵌入型	2.8	1.20

EAF的的取值(考虑15个因素)

• 软件产品属性(3) ：软件可靠性，软件复杂性，数据库的规模
• 计算机属性(4) ：程序执行时间，程序占用内存大小，软件开发环境的变化 ， 软件开发环境的响应速度
• 人员属性(5) ：分析员能力，程序员能力，领域经验，开发环境的经验 ， 程序设计语言的经验
• 项目属性(3) ：软件开发方法的能力，软件工具的数量和质量 ， 软件开发的进度要求

CMMI方法

CMMI的全称为Capability Maturity Model Integration，即能力成熟度模型集成，能增强软件企业的开发与改进能力，帮助企业对软件工程过程进行管理和改进，从而能按时地、不超预算地开发出高质量的软件。

五级CMMI

第一级别：初始级
第二级别：可管理级
第三级别：已定义级
第四级别：量化管理级
第五级别：优化管理级

软件维护

定义

软件维护是指软件系统交付使用以后，为了改正错误或满足新的需求而修改软件的过程
软件出现问题或者需要改进而对代码及其文档进行修改，其目的是对现有软件产品进行修改地同时保持软件的完整性。

分类

（1）改正程序中的错误和缺陷。
（2）改进设计以适应新的软、硬件环境。
（3）增加新的应用范围

类型：
- 完善性维护
增加功能与性能需求
- 改正性维护
纠正隐藏错误
- 预防性维护
某部分重新设计，编制和测试
- 适应性维护
适应使用过程中外部环境、数据环境等变化

主要因素

因素	特征
可理解性	易于理解的设计模式
可测试性	充分的质量保证技术
可修改性	完备的文档内容和良好的设计内容
可移植性	良好的编码标准
可重用性	有效的模块化

环境因素

1. 软件维护的文档
2. 软件的运行环境
3. 软件的维护组织
4. 软件的维护质量

IEEE维护模型

软件维护技术

程序的理解

建立从问题/应用域到程序设计的映射

• 清晰简明的文档
• 代码浏览工具
• 程序理解的任务：以软件维护、升级和再工程为目的，在不同的抽象级别上建立基本软件的概念模型，包括从代码本身的模型到基本应用领域的模型，即建立从问题/应用域到程序设计/实现域的映射集

具体任务：
• 通过检查单个的程序设计结构，程序被表示成抽象语法树、符号表或普通源文本
• 尽量做到程序隐含信息的显性表示及程序内部关系的可视化
• 从源代码中提取信息，并存放在通用的数据库中，然后通过查询语言对数据库进行查询
• 检查程序构造过程中的结构关系，明确表示程序组成部分之间的依赖关系。
• 识别程序的高层概念，如标准算法、数据结构、语法及语义匹配等。

软件再工程

对现有软件仔细审查，重新构造（对新模式实现）

软件****

分析目标系统，识别系统的构件及其交互关系，并通过高层抽象来展示目标系统过程。