软件工程考纲

1 考试题型说明

序号	题型	题量	分值
一	选择题	20	30
二	判断题	10	10
三	简答题	5	30
四	用例规约	1	30

---

2 选择题

• 2.1 软件与软件工程

  • 什么是软件，软件的特点 [1.1.1 1.1.3]

    什么是软件
    软件是在计算机系统支持下，能够完成特定功能和性能的程序、数据和相关文档
    软件的特点
    1.软件是抽象的逻辑产品而不是物理产品；
    2.软件具有极大的灵活性；
    3.软件的突出优点是不会磨损和老化。

  • 软件的8个质量要素 [1.1.5]

    软件的8个质量要素
    正确性，可用性，可靠性，有效性，可维护性，可移植性，安全性，可复用性

  • 什么是软件危机，软件危机的表现，软件危机的原因 [讲义 1.2.2]

    什么是软件危机
    软件危机是指落后的软件生产方式无法满足迅速增长的计算机软件需求，从而导致软件开发与维护过程中出现一系列严重问题的现象。

    软件危机的表现
    1.软件开发进度难以预测；
    2.软件开发成本难以控制；
    3.用户对产品功能难以满足；
    4.软件产品质量无法保证；
    5.软件产品难以维护；
    6.软件缺少适当的文档资料。

    软件危机的原因
    1.用户需求不明确；
    2.缺乏正确的理论指导；
    3.软件开发规模越来越大；
    4.软件开发复杂度越来越高。

  • 软件工程的定义、目标及原则[1.2.1 1.2.3]

    软件工程的定义
    1.将系统的、规范的、可量化的方法应用于软件的开发、运行和维护的过程；
    2.对上述方法的研究。

    软件工程的目标
    在给定成本、进度的前提下，开发出满足用户或市场需要的高质量软件产品。

    软件工程的原则
    抽象、信息隐藏、模块化、局部化、一致性、完全性、可验证性

  • 瀑布模型、快速原型、增量模型、螺旋模型的特点、适用范围、局限性 [1.3]

    #软件生命周期/软件开发过程分解
    可行性研究、 软件需求、 软件设计、 软件编码、 软件测试、 运行与维护、 退役
    

    瀑布模型
    特点
    1.思路简洁明确
    2.每一阶段完成后， 都必须对他的阶段性制品进行评审
    3.可行性研究、需求、设计、编码、测试分离，有利于软件体系结构设计
    适用范围
    规模较小、软件需求比较稳定的项目或者子系统
    局限性
    1.客户和系统分析员确定软件需求后才能进行后续软件开发
    2.用户和软件项目负责人要等相当长的时间才能得到一份软件的最初版本
    3.开发人员在瀑布模型‘上游’出现过失会误导‘下游’开发活动

    快速原型
    特点
    1.利用原型能统一客户和软件开发人员对软件项目的理解，有助于需求的定义和确定
    2.克服瀑布模型的缺点，减少由于软件需求不明确带来的开发风险
    适用范围
    适合预先不能确切定义需求的软件系统的开发
    局限性
    使用这个模型的前提是要有一个展示性的产品原型，因此在一定程度上可能会限制开发人员的创新

    增量模型
    特点
    1.将需求分解，划分为一系列增量
    2.在开发过程中，按照增量不断发布软件新版本
    3.增量开发过程能保持良好的软件体系结构
    适用范围
    软件需求确定
    局限性
    1.增量规模不能大，不然会暴露瀑布模型的缺点
    2.将客户需求分解成增量序列必须对系统需求十分了解，并有顶层设计经验
    3.如何为基本服务定义增量，何时实现这些增量，处理起来比较困难

    螺旋模型
    特点
    1.保留了瀑布模型中系统地、按阶段逐步地进行软件开发和“边开发，边评审”的风格
    2.引入了风险分析，用风险驱动开发
    适用范围
    螺旋模型适合大型软件和需求不能完全确定的软件开发
    局限性
    由于需求的不确定性，软件开发初期无法进行软件体系结构设计，多次迭代会导致软件结构体系变坏，为软件理解和维护带来困难

  • RUP统一过程的特点（跟传统瀑布模型的区别 “阶段划分跟软件制品所处阶段不是一一对应关系）、五个阶段的划分[2.4.1 2.4.2]

    RUP统一过程的特点
    1.软件生存周期只描述软件制品及其进化状态，软件开发过程是根据项目要求调度9个工作流完成软件制品的进化的。
    2.RUP的软件开发过程分解与软件制品所处阶段不是一一对应关系。

    五个阶段的划分
    1.初始阶段
    2.细化阶段
    3.构造阶段
    4.移交阶段
    5.生产阶段

  • 敏捷开发的价值观、原则及实践[1.4.1 1.4.2 `讲义]

    敏捷开发的价值观
    1.人员和交互胜过过程和工具
    2.可以工作的软件胜过面面俱到的文档
    3.与客户合作胜过合同谈判
    4.响应变更胜过遵循计划

    敏捷开发的原则
    1.我们最优先要做的是通过尽早的、持续的交付有价值的软件来使客户满意
    2.即使到了开发的后期，也欢迎改变需求。敏捷过程利用变化来为客户创造竞争优势
    3.经常性的交付可以工作的软件，交付的间隔可以从几周到几个月，交付的时间间隔越短越好。
    4.在整个项目开发期间，业务人员和开发人员必须天天都在一起工作
    5.围绕被激励起来的人个来构建项目。给他们提供所需要的环境和支持，并且信任他们能够完成工作
    6.在团队内部，最具有效果并且富有效率的传递信息的方法，就是面对面的交谈
    7.能工作的软件是首要进度度量标准
    8.敏捷过程提可持续的开发速度。责任人、开发者和用户应该能够保持一个长期的、恒定的开发速度
    9.不断地关注优秀的技能和好的设计会增强敏捷能力
    10.简单----使未完成的工作最大化的艺术----是根本的
    11.最好的构架、需求和设计出自与自组织的团队
    12.每隔一定时间，团队会在如何才能更有效地工作方面进行反省，然后相应地对自己的行为进行调整

    敏捷开发的实践
    1.完整的团队
    2.增量式规划
    3.客户参与全过程
    4.简单设计
    5.结对编程
    6.测试驱动开发
    7.适时重构
    8.持续集成
    9.代码集体所有
    10.其他 (p31)

• 2.2 需求工程

  • 需求工程、需求获取、需求分析的概念第3章、第4章、第5章开篇

    需求工程
    太长了(p67)
    需求获取
    完整地手机、整理利益相关方对目标软件系统的需求，并以其容易理解的业务语言阐述这些需求，形成文档
    需求分析
    在需求获取阶段的输出制品的基础上，获得对软件需求更深入、更完整的理解，并且将软件需求表示为面向软件设计人员、易于修改和维护的分析模型

  • 软件需求的分类：功能需求、质量需求、约束性需求定义以及辩析 [3.1.1]

    功能需求
    功能需求是指利益相关方要求目标软件系统应该具有的功能
    质量需求
    质量需求主要指利益相关方对目标软件系统的质量要求(性能、可靠性等)
    约束性需求
    约束性需求是指利益相关方对目标软件系统在项目预算、完成时间、技术选型、必须遵循的标准与规范等方面提出的要求，以及由预期的开发、运行环境的特征而导致的真对目标软件系统的约束

  • 软件需求的质量要素 -- 对需求进行评价[3.1.2 习题3.1~3.3(略)]

    质量要素
    正确性、可行性、完全性

  • 需求调查的基本方法、特点、适用性、局限性 [3.2.2 讲义]

    1.访谈和会议
    特点
适用性
局限性
    2.调查问卷
    特点
适用性
局限性
    3.业务文档分析
    特点
适用性
局限性
    4.现场观摩
    特点
适用性
局限性

  • 用例的描述方法(用例规约的构成、编写)及注意事项(编写要点) [4.5.1 ~ 4.5.2]

    用例规约的构成、编写
    用例名称、用例ID、参与者、用例描述、前置条件、基本事件流、替代事件流、后置条件
    

    

    用例规约样例

    注意事项
    1.采用带结构化序号的自然语言描述动作序列
    2.采用主动语态、简单句式描述每一个动作，用词力求简洁、清晰
    3.统一使用“系统”指待开发的软件产品，执行者的名称应与用例描述的执行者列表中的执行者名称一致
    4.采用业务而非技术用语描述每个动作，阐明执行者意图，绝不涉及任何用户界面操作
    5.从用户的视角描述系统行为从外部的可见效果，尽量避免系统内部动作
    6.以适当粒度描述每一个动作
    7.避免嵌套使用“如果...那么...”
    8.在一连串动作的前部或后部描述循环、特殊的时序约束或其他有关此子动作序列的其他说明
    9.如果用例A包含子用例B那么A的动作序列描述中采用带下划线的子用例B的名称来引用用例B的交互动作序列

  • 分析类、边界类、实体类、控制类的概念，分析类之间的典型协作过程--顺序图的绘制 [5.4.2 5.4.3]

    分析类:直接服务于软件的功能性需求的概念层面的类
    边界类:负责目标软件系统与外部执行者之间的交互
    实体类:负责保存目标软件系统中具有持久意义的信息项并向其他类提供信息访问操作
    控制类:负责协调、控制其他类共同完成用例规定的功能或行为

    分析类之间的典型协作过程
    

    

    分析类之间的典型协作过程

• 2.3 面向对象及UML (所有UML图画法省略)

   用于表示分析模型的UML图形机制主要是类图、活动图、交互图与状态图
  

  • 面向对象的基本概念：对象、类、接口、封装、继承、多态、消息、关联、组合、聚合、依赖、实现 [讲义]

    对象:对象是人们要进行研究的任何事物，从最简单的整数到复杂的飞机等均可看作对象，它不仅能表示具体的事物，还能表示抽象的规则、计划或事件。
    类:具有相同特性（数据元素）和行为（功能）的对象的抽象就是类。因此，对象的抽象是类，类的具体化就是对象，也可以说类的实例是对象，类实际上就是一种数据类型。
    接口:**
    封装:**
    继承:**
    多态:**
    消息:对象之间进行通信的结构叫做消息。
    关联:**
    组合:**
    聚合:**
    依赖:**
    实现:**

  • 用例相关概念：执行者、用例、框架用例 [4.1.1]

    执行者:外部用户或外部实体在系统的交互过程中扮演的角色

    用例:功能性软件需求的主体部分

    框架用例:宏观功能已基本明确但内容尚不完整的用例

  • 用例图相关概念：执行者与用例间关系，用例间关系 [4.1.2]

    执行者与用例间关系:执行者与用例间关系在用例图中表示为他们之间的连接边，其意义为执行者触发用例的执行，向用例提供信息或从用例获取信息

    用例间关系:包含(<>)、扩展(<>)、继承(<>)

  • 类图：类图的作用，绘制方法，类之间的关系 [4.1.4]

    类图的作用:类图描述面向对象软件系统的静态结构

    类之间的关系:继承、聚合、关联、依赖、实现

  • 活动图：概念、用途、画法 [4.1.5]-- 多了并发表示的机制、泳道

    概念:实体为完成某项功能而执行的操作序列(可以并发和同步)

  • 顺序图：概念、用途、画法 [5.1.1]

    概念:描述一组对象通过消息传递而形成的协作行为

    注意点:[对象名]:[类名]

  • 状态图：概念、用途、画法 [5.1.2]

    概念:描述一个实体在事件刺激下的反应式动态行为

  • 包图：概念、用途 [7.2.1]

    概念:刻画包之间的构成和依赖关系

  • 组件图：概念、用途 [7.2.2]

    概念:描述软件系统中的构件以及构建之间的构成关系和依赖关系

  • 部署图：概念、用途 [7.2.3]

    概念:表示软件系统的可执行工件在运行环境中的分布情况

  • 对象图：概念、用途 [7.2.4]

    概念:软件系统中的某些对象在运行过程中的顺时快照

• 各类UML图形，哪些是静态视图，哪些是动态视图，哪些是结构视图，哪些是行为视图 [2.3] -- 4+1所属的视图、类别

  静态视图:用例图、类图、对象图
  动态视图:交互图顺序图和通信图、状态图、活动图
  结构视图:包图、类图、对象图
  行为视图:交互图 顺序图和通信图、状态图、活动图

• 2.4 软件设计

  • 体系结构设计与详细设计的任务分工及关系（第7章与第9章的开篇）

    p238

  • 软件设计的基本原则 [6.2.1 6.2.2 6.2.3 6.2.4]

    抽象与逐步求精、模块化、信息隐藏、关注点分离

  • 内聚性概念6.2.2，耦合度概念6.2.2，软件独立性、内聚和耦合多种表现形式讲义 辨析以及排序

    内聚性:内聚性表示一个模块内部各成分彼此关联的紧密程度
    耦合度:耦合度是指软件结构中多个模块之间的关联程度

  • 软件体系结构的三要素，主要包括哪些视图（5种视图），每种视图的用途，各自的表达形式（7.1.2、7.6）

    软件体系结构视图
    逻辑视图、开发视图、物理视图、运行视图、数据视图

  • 设计模式的概念7.4.1、设计模式的分类p189按解决方案抽象程度的分类

  • 三种通用的体系结构模式（主要是分层、管道与过滤器）的特点 7.4.2

• 2.5 结构化分析与设计

  • 数据流图的四种基本图元

    外部实体、转换、数据流、数据源

  • 分层数据流图的画法及要点（原则）（讲义）

  • 2.6 软件测试

  • 软件测试的定义（12.1前言）、任务（12.1.1）、软件测试的局限性（无法证明程序无错）、原则（p327）（12.1.4）

    软件测试
    使用人工或 自动手段运行软件系统的过程，目的在于检验系统是否满足规定的需求，或确定预期结果与实际结果之间的差异

    任务
    运行程序或模拟系统执行，发现程序缺陷

  • 黑盒测试与白盒测试的区别 [12.1.3 (p326)]

  • 什么是白盒测试？（12.3.1）白盒测试中—常见的6种覆盖标准的区别（讲义）

  • 什么是黑盒测试？ --等价类划分（12.3.2 1）

  • 什么是单元测试（12.4.1）定义，主要依据，主要方法，测试目标

  • 什么是集成测试（12.4.2）

  • 什么是确认测试（12.4.3）

  • 什么是系统测试（12.4.4）

---

3 简答题