软件工程复习（一）：知识点

写在前面：试卷

1.名词解释 *10 （20‘）

2.判断 *10 （10’）

3.选择 *20 （20‘）

4.简答 *6 （20’）

5.综合 *3 （20‘）

第一章：软件工程概述

1.几个概念

• 方法：完成软件开发任务的技术手段
• 工具：为软件开发方法提供半自动的或者自动的软件支撑环境
• 过程：支持软件开发各个环节的控制和管理
• 模式或者风格：编程范型、提供了（同时决定了）程序员对程序执行的看法
• 软件工程：使用工具、方法、过程和范式来确保软件产品的质量。它们的目标是使用便利、高产的方法来生成解决问题的高效方法。是一个系统工程，既有对技术问题的分析和综合，也有对开发过程和参与者的管理

2.描述bug术语

• 错误error：在软件生产过程中的人为产生的错误（需求说明的错误，代码中的错误）
• 缺陷fault：在功能实现过程中产生的问题。（一个问题可能产生几个缺陷静态存在的）
• 失败failure：相对于系统指定行为的偏离。（动态存在）
• 联系：
  • 缺陷是系统内部的观点，就像从开发者的角度看待问题；
  • 失败是外部观点，即从用户角度看到的问题，并非每一个缺陷都是失败。
  • 人为错误可能导致故障，故障可能导致失败

3.怎么认识软件的质量

• 产品的质量：用户从外部特性看软件具有足够的功能并已于学习和使用就说明软件具有高质量，软件开发者从内部特征来看错误数量和类型来判断软件质量的高低，通过建立模型，把用户的外部视图和软件开发人员的内部视图联系起来。（McCall质量模型，ISO9126质量模型）
• 过程的质量：有许多过程都能影响最终作品的质量，如果任何一个活动出现了差错，整个产品的质量就会受到影响。对软件开发的过程剑魔，研究过程，并巽宅方法对他甲乙改进。
• 商业的质量：即商业应用背景下的软件质量，讲技术价值与商业价值统一起来。

4.软件工程涉及的人员

• 客户：为将要开发的软件系统支付费用的公司、组织或个人。

• 开发人员：为客户构建软件系统的公司、组织或个人，其中包括协调并指导程序员和测试人员的管理人员。

• 用户：实际使用系统的人，包括坐在终端前的人、提交数据的人或阅读输出的人。

  

5.开发团队的成员

6.软件工程发生的变化

（1）因素：

​ ①商业产品发布时间的压力

​ ②越来越高的开发和维护成本

​ ③桌面计算能力需要

​ ④网络的扩展

​ ⑤面向对象的技术应用

​ ⑥图形用户界面

​ ⑦瀑布开发模型的不可预见性

（2）特征：

​ ①抽象：在某种概括层次上对问题描述，使得我们能够集中于问题的关键方面而不会陷入细节。通常，抽象可以从标识对象的类、层次等方式进行组织。

​ ②分析和设计方法以及表示法：不只是提供了交流媒介，还是我们能够建立模型并检查完整性和一致性。

​ ③用户界面原型化：原型化意味着构建一个小的系统版本，帮助用户或者客户标识系统的关键需求，证明设计或方法的可行性。原型化通常设计一个良好的用户界面。

​ ④软件体系结构：系统体系结构根据一组体系单元以及单元之间的相互关系来描述系统。单元越独立，体系结构越模块化，越容易分别设计和开发不同的部分。

​ ⑤软件过程：不同的软件类型需要不同的过程，大型、复杂的系统需要更多的结构、检查和平衡。

​ ⑥复用：在软件开发过程中通常通过复用以前开发项目中的项来利用应用程序之间的共性。

​ ⑦测度：量化我们做了什么以及我们的目标是什么，有助于使我们的过程和产品的特定特性更加可见。

​ ⑧工具和集成环境：平台集成、表示集成、过程集成、过程集成、数据集成、控制集成

第二章：过程和生命周期

1.几个概念

• 过程：软件开发活动中产生某种期望结果的一系列有序任务，涉及活动、约束和资源。
• 生命周期：产品的构建过程
• 软件生命周期：我们把描述了软件产品从概念到实现、交付、使用和维护的整个软件开发过程叫做软件生命周期。
• 过程很重要？
  • 一致性和具有一定的结构
  • 允许我们分析、理解、控制和改进组成过程的活动，并以此指导我们的行动。
  • 获取经验并把经验传送给他人。
• 原型：一个部分开发的产品。他是客户和开发人员能够对计划开发的系统的先关方面进行检查，以决定它对最终产品是否合适和恰当。
• 循环周期：从编写需求文档到系统交付使用会经过的时间
• 运行系统或产品系统：当前正在被客户和用户使用的系统
• 开发系统：准备用来替换现行产品系统的下一个版本
• 增量开发：首先定义一个小的功能子系统，然后在每个新的发布中增加新功能。
• 迭代开发：在一开始就提交一个完整的系统

2.软件过程模型

详细版请参照小黑手600的博文。

模型	Feature	Usage	Pros	Cons
瀑布模型	开发阶段严格按照线性方式进行，每一个阶段具有相关的里程碑和交付产品，且需要确认和验证。	过程较为简单的开发，关注文档和制品	a.使用里程碑、提交物来描述软件实现的过程，管理者可以评价这个过程b.简单，使用者易于理解c.它是复杂模型的基础	a.无法反应真实情况b.无法处理变化c.典型的制造业模式，无法处理实际过程中的重复开发问题d.文档转化困难
V模型	瀑布模型的变种	关注活动和正确性	a.强调分析和设计是相互联系的b.使得隐藏在瀑布模型中的迭代和重用更加明确	a.验收测试活动是由客户而不是开发人员进行的，用户不是专业人员，需要使用一段时间才能发现问题，这样会加大工期。
原型化模型	减少产品最终的风险和不确定性	关注设计的不断修正	a.本身是有效的过程模型的基础b.它允许用户以独立的工程模型方式，每一阶段都基于原型的建立，以快速构造系统，逐步完成各阶段的任务c.有效的降低了开发时的风险和不确定性	过程复杂繁琐
可操作规格
可转换模型
阶段化开发	增量和迭代	很急切的看到一个版本的出现	每个版本的周期减少了	耗资大，人力物力消耗大
螺旋模型	把开发活动和风险管理合并起来	大项目	降低和控制风险	只适合大项目
敏捷方法			增加了软件过程的灵活性，缩短了开发时间，对于商业竞争有很大的优势，在同行中首先占领市场	设计不系统，各部门配合起来可能出现不一致，没有完整的开发文档

3.极限编程XP

• 四个特性：交流、简单性、勇气、反馈
• 12个实践：规则游戏/小的发布/隐喻/简单设计/首先编写测试/重构/对编程/集体所有权/持续集成/可以忍受的步伐/在现场的客户/代码标准

4.XP与Scrum

1.迭代长度不同：

​ XP的一个sprint的迭代长度大约1-2周，Scrum是2-4周

2.在迭代中是否修改需求

​ XP在一个迭代中，如果一个需求还没有实现，就考虑用另外一个需求来替换，替换的原则是需求实现的时间一样。Scrum不一样，它是不允许修改和添加需求的。

3.在迭代中，需求是否按照优先级实现

​ XP是严格按照的，Scrum比较灵活，比如一个需求的优先级是6，但是依赖于一个优先级为10的，那么就可以显示优先级为10的

4.软件的实施过程中，是否采用严格的工程方法，保证进度或者质量

​ Scrum没有这些，要求开发者的自觉；XP比较严格，它采用TDD（测试驱动开发），自动测试开发，结对编程，简单设计，重构等约束行为。

简单的说：Scrum是重视管理和组织的实践，XP侧重于编程的实践。

第三章：计划和管理项目

1.几个概念

• 项目进度：对特定项目的软件开发周期的刻画，包括对项目阶段、步骤、活动的分解，对每个活动的交互关系的描述，以及对各活动完成时间及整个项目完成时间的初步估算。（通过列举项目的各个阶段，把每个阶段分解成离散的任务或活动，来描述项目的软件开发周期。）

• 活动：项目中的一部分，一般占用项目进度计划的一段时间。

• 里程碑：指特定的时间点，标志着活动的结束，通常伴随着提交物。

• 关键路径：在最长路径中，它的每个节点的时差都是0，因为正是这条路径决定这个项目是否按照进度完成，因此它被称为关键路径

• 风险：在软件生产过程中有负面结果的、人们不希望看到的事件。

  风险管理：项目经理必须进行风险管理来了解和控制项目中的风险。

  风险影响：与风险有关的损失

  风险概率：风险发生的可能性百分比

  风险控制：能够改变结果的程度

  风险成本 Risk exposure = (risk probability) x (risk impact)

2.活动图、关键路径

• 活动图：

  • 边表示活动（时间）
  • 节点表示里程碑
  • 虚线表示此后的活动必须在之前活动完后才能进行，活动依赖前驱

• 关键路径是项目管理中进度控制的一个术语。在项目的网络图中，从项目开始到项目完成有许多条路径可以走，就像从798艺术区到北京大学一样。如果20个人同时从798艺术区出发，每个人走不同的路(乘坐地铁、公交车或是自驾)，但只有20人全部到达北京大学，才能完成聚会。这最后一个到达的人就是走最长路径（花费时间最多）的人。相似的，只有最长(花费时间最多)的路径完成之后，项目才算结束。这条在整个网络图中最长的路径就叫关键路径（critical  path）。

• 我们来总结一下关键路径法的4个关键点：

  • （1） 关键路径是项目网络图中最长的路径，他决定了项目的总耗时时间；
  • （2） 项目经理必须把注意力集中在那些优先等级较高的任务，确保他们准时完成，关键路径上任何活动的推迟都将导致整个项目推迟；
  • （3） 项关键路径要时间，向非关键路径要资源；
  • （4） 调整进度，平衡资源

• 关键路径算法：

3.项目人员

1.沟通路径：n(n-1)/2，有(2^n-1)个小组从事项目子系统工作

2.软件人员应该具备的素质

• 完成工作的能力
• 对工作的兴趣
• 开发类似应用程序的经验
• 使用类似工具或语言的经验
• 使用类似技术的经验
• 使用类似开发环境的经验、培训
• 与他人交流的能力
• 与他人共同承担责任的能力
• 管理能力

3.核心成员

• 主程序员：总体负责系统的设计和开发，其他小组成员向主程序员汇报，主程序员对每个决定由最终决策权。
• 副程序员（主程序员助理）：在必要的时候代替主程序员。
• 在具有高度确定性，稳定性，一致性和重复性的项目中，使用像主程序员负责制这样的等级㢟形式会更有效。在项目中涉及大量的不确定性，采用更为民主的方法可能会更有效。
• 忘我方法：不是把责任放在单个人身上，而是让每个人平等的承担责任。过程与个人是分开的。批评是针对产品或结果的，不涉及个人。忘我小组结构是民主的，不论讨论的是设计问题还是测试技术，小组成员投票产生决策。

4.主要工作

​ 需求分析/系统设计/程序设计/程序实现/测试/培训/维护/质量保证

4.工作量评估

• 专家估算法：工作量的估计方法依靠的是专家的判断，预测的准确性是给予估计者的能力经验客观性和洞察力。

  • 主要类推法：Delphi技术、Wolwerton模型（该模型的缺点是受变化和主观性的影响，还受当前数据相关性的影响）

• 算式估算：

  • 基本公式：E=（a+b*S^c）m(X)

  注： S是估算的系统规模，而 a,b和 c是常量。 X是从 x1到 x2的一个成本因素。而 m是基于这些因素的一个调整因子。

• Walston&Felix模型

  • E=5.25^0.31m(X)

• Bailey&Basili模型

  • E=(5.5+0.73*S^1.46)m(X)

• .COCOMO的三次估算

  • E=bS^c m(X)
  • bS^c是初始的基于规模的估算，通过关于成本驱动因子信息的向量m（X）对它进行调整
  • 第一阶段：计划和原型阶段，通过应用点估算规模
  • 第二阶段：早起设计阶段，根据需求中的功能点
  • 第三阶段：后体系阶段，功能点/代码行

5.风险管理

• 风险管理的步骤

  

第四章：获取需求

1.几个概念

• 需求：对期望的行为的表达。
• 需求类型：
  • 功能需求：系统应该提供的服务、如何对输入做出反应以及系统在特定条件下的行为描述。【功能、数据】
  • 质量需求：非功能性需求，软件必须拥有的质量特性，诸如响应时间、易使用性、高可靠性或低维护代价等。【性能】
  • 设计约束：已经做出的设计决策或限制问题解决方案集的设计决策，例如平台或构件接口的选择。【物理环境、接口、用户】
  • 过程约束：对用于构建系统的技术和资源的限制，例如客户要求使用敏捷开发方法。【资源、文档】

2.需求的特性

• 正确性
• 一致性
• 确定性（无二义性）
• 完备性
• 可行性
• 相关性
• 可测试性
• 可跟踪性

3.建模方法

1.UML重点：用例图、类图

2.E-R图

4.原型化需求

• 抛弃型原型：仅用于了解问题，探索可行性，并不打算用来作为将来实际提交系统的一部分，而是用来扔掉。
• 演化型原型：用于了解问题、并作为将来准备提交系统的一部分
• 这两种都叫：快速原型化

第五章：设计体系结构

1.几个概念

• 设计：设计将需求中的问题描述专述变成软件解决方案的创造性过程

2.设计过程模型

不断迭代：描绘体系结构计划、分析体系结构咋么能很好地促进所期望的性质、根据分析结果改进和优化体系结构

最终：体系结构文档化后就进行正式的设计评审

结果：SAD

3.满足质量属性

• 可修改性
• 性能（系统速度和容量上的特点：响应时间、吞吐量、负载）
• 安全性
• 可靠性（主动故障检测、故障恢复）
• 健壮性
• 易使用性
• 商业目标

第六章：设计模块

1.几个概念

• 重构：通过调整程序代码改善软件的质量、性能，使其程序的设计模式和架构更趋合理，提高软件的扩展性和维护性。

2.设计原则

• 模块化（耦合、内聚）
• 接口
• 信息隐藏
• 增量式开发
• 抽象
• 通用性

3.面向对象的设计

• 概念
• 可替换性
• UML

4.面向对象设计模式

• 基本概念

第七章：编写程序

1.编程的知道原则

• 控制结构
• 算法
• 数据结构
• 通用性指导原则（局部输入输出、包含伪代码、改写重写，而不是补丁、复用）

2.文档分类

• 内部文档：
  • 头注释块
  • 其他程序注释
  • 有意义的变量名和语句标记
  • 文档化数据
• 外部文档
  • 描述问题
  • 描述算法
  • 描述数据

3.编写过程

• 极限编程
• 结对编程

第八章：测试程序

1.软件故障和实效

• 沉浸式
• 目的
• 分类

2.故障类型

• 算法故障
• 计算故障
• 文档故障
• 吞吐量故障

3.正交缺陷分类

• 功能
• 接口
• 检查
• 赋值
• 计时、串行化
• 构建、包、合并
• 文档
• 算法

4.测试的步骤

5.单元测试

• 两类代码审查的区别

6.集成测试

• 自底向上集成
• 自顶向下集成

7.OO测试和传统测试的区别

第九章：测试系统

1.测试的原则

• 找根源
• 测试的过程
  • 功能测试
  • 性能测试
  • 验收测试
  • 安装测试
• 配置管理
  • 几个概念：系统配置、配置管理
  • 版本发布
  • 回归测试（步骤）
  • delta、单独文件和条件编译
  • 变化（变更）控制
• 测试小组
  • 专业测试人员
  • 系统测试人员
  • 配置管理代表
  • 用户

2.功能测试

• 基本原则
  • 具有很高的故障…
  • …
• 因果图

3.性能测试

• 类型

4.可靠性、可用性及可维护性

• 定义

5.验收测试

• 种类

6.安装测试

• 测试前
• 测试

第十一章：维护系统