软考之软件工程

一、瀑布模型

  严格区分阶段，每个阶段因果关系紧密相连，只适合需求明确的项目

缺点：软件需求完整性、正确性难确定；严格串行化，很长时间才能看到结果；瀑布模型要求每个阶段一次性完全解决该阶段工作，不现实。

二、原型模型 

适合需求不明确的项目

原型模型两个阶段：1、原型开发阶段 2、目标软件开发阶段

抛弃型原型与演化型原型

三、原型及相关模型

四、V模型

五、迭代与增量

增量型：一块一块有增加

迭代型：一轮一轮在变好

 六、螺旋模型

七、构件组装模型

优点：易扩展、易重用、降低成本、安排任务更灵活。

确定：构件设计要求经验丰富的架构师、设计不好的构件难重用、强调重用可能牺牲其他指标（如性能）、第三方构件质量难控制。

八、基于构件的软件工程（CBSE）

CBSE体现了购买而不是重新构造的哲学

CBSE的特征：

• 可组装性：所有外部交互必须通过公开定义的接口进行
• 可部署性：构件总是二进制式的，能作为一个独立实体在平台上运行
• 文档化：用户根据文档来判断构件是否满足需求
• 独立性：可以在无其他特殊构件的情况下进行组装和部署
• 标准化：符合某种标准化的构件模型

构件的组装：

• 顺序组装：按顺序调用已经存在的构件，可以用两个已经存在的构件来创造一个新的构件
• 层次组装：被调用构件的“提供”接口必须和调用构件的“请求”接口兼容
• 叠加组装：多个构件合并形成新构件，新构件整合原构件的功能，对外提供新接口

 九、快速应用开发模型（RAD）

主流程采用瀑布模型，在流程引入大量的构件

十、统一过程（UP，RUP）

十一、敏捷方法概述

11.1、敏捷方法-XP

强调四大价值观：沟通（加强面对面沟通），简单（不过度设计），反馈（及时反馈），勇气（接受变更的勇气）

实践规则：结对编程（两个人写代码，一个人写，一个人审核）、持续集成

 11.2、敏捷方法-SCRUM

核心思想：每次选一部分进行迭代，一个迭代一到四周，侧重项目管理

11.3 其他敏捷方法

水晶方法：提倡“机动性”的方法，拥有对不同类型项目非常有效的敏捷过程

特征驱动开发方法（FDD）：认为有效的软件开发需要三要素：人、过程和技术。定义了六种关键的项目角色：项目经理、首席架构设计师、开发经理、主程序员、程序员和领域专家。

开放式源码：程序开发人员在地域上分布很广，其他方法强调集中办公

ASD方法：其核心是三个非线性的、重叠的开发阶段：猜测、合作与学习

动态系统开发方法（DSDM）：倡导以业务为核心

十二、逆向工程

实现级：包括程序的抽象语法树、符合表、过程的设计表示

结构级：包括反映程序分量之间互相依赖关系的信息，例如调用图、结构图、程序和数据结构

功能级：包括反映程序段功能及程序段之间关系的信息，例如数据和控制流模型

领域级：包括反映程序分量或程序实体与应用领域概念之间对应关系的信息，如实体关系模型

相关概念

（1）重构/重组。重构是指在同一个抽象级别上转换系统的描述形式。

（2）设计恢复：指借助工具从已有程序中抽象出有关数据设计、总体结构设计和过程设计等方面的信息

（3）逆向工程：逆向工程是分析程序。力图在比源代码更高抽象层次上建立程序的表示过程，逆向工程是设计的恢复过程

（4）正向工程：指不仅从现有系统中恢复设计信息，而且使用该信息去改变或重构现有系统，以改善其整体质量

（5）再工程/重构工程：再工程是对现有系统的重新开发过程，包括逆向工程、新需求的考虑过程和正向工程三个步骤

 十三、净室软件工程

净室即无尘室、洁净室。就是一个受控污染级别的环境。

使用盒结构规约（或形式化方法）进行分析和设计建模，并且强调将正确性验证，而不是测试，作为发现和消除错误的主要机制。

使用统计的测试来获取认证被交付的软件的可靠性所必需的出错率信息。

技术手段

• 统计过程控制下的增量式开发：控制迭代
• 基于函数的规范和设计：盒子结构 定义3种抽象层次：行为视图（黑盒）->有限状态机视图（状态盒）->过程视图（明盒）
• 正确性验证：净室工程的核心
• 统计测试和软件认证：使用统计学原理，总体太大时必须采用抽样方法

缺点：

• 太理论化，正确性验证的步骤比较困难且耗时
• 开发小组不进行传统的模块测试，不现实
• 脱胎于传统软件工程，不可避免带有传统软件工程的一些弊端

十四、需求工程-概述

软件需求是指用户对系统在功能、行为、性能、设计约束等方面的期望

十五、需求工程-需求获取

需求获取方法

• 用户面谈：交互好。成本高，要有领域知识支撑
• 联合需求计划：高度组织的群体会议，各方参与，了解想法，消除分歧。交互好，成本高
• 问卷调查：用户多，无法一一访谈，成本低
• 现场观察：针对复杂业务流程和操作
• 原型化方法：通过简易系统方式解决早期需求不确定的问题
• 头脑风暴法：一群人围绕新业务，发散思维，不产生新的观点

十六、需求分析 

需求分析分两条线——结构化需求分析和面向对象需求分析

结构化分析做三个模型——功能模型（数据流图DFD）、数据模型和行为模型

十七、OOA

UML（统一建模语言）：与平台无关，语言无关，由构造块、规则和公共机制组成。

公共机制：

• 规格说明：事物语义的细节描述，它是模型真正的核心
• 修饰：通过修饰来表达更多的信息
• 公共分类：类与对象、接口与实现
• 扩展机制：允许添加新的规则

规则：

• 范围：给一个名字以特定含义的语境
• 可见性：咋样使用或看见名字
• 完整性：事物如何正确、一致地相互联系
• 执行：运行或模拟冬天模型的含义是什么

构造块：

• 事物
  • 结构事物：最静态的部分，包括：类、接口、协作、用例、活动类、构件和节点
  • 行为事物：代表时间和空间上的动作。包括：消息、动作次序、连接
  • 分组事物：看成是个盒子。如：包、构件
  • 注释事物：UML模型的解释部分。描述、说明和标注模型的元素
• 关系
• 图

十八、UML-4+1视图

逻辑视图展现系统的功能,实现视图展现源代码结构

十九、需求定义

严格定义法

• 所有需求都能够被预先定义
• 开发人员与用户之间能够准确而清晰地交谈
• 采用图形/文字可以充分体现最终系统

原型法

• 并非所有的需求都能在开发前被准确的说明
• 项目参加者之间通常都存在交流上的困难
• 有适合的系统开发环境
• 反复是完全需要和值得提倡的，需求一旦确定，就应遵从严格的方法

二十、需求验证

二十一、需求跟踪

 二十二、需求变更管理过程

变更审批由CCB负责

二十三、软件系统建模

二十四、人机界面设计

黄金三法则

• 置于用户控制之下
• 减少用户的记忆负担
• 保持界面的一致性

二十五、结构化设计

结构化设计包括：

• 概要设计（外部设计）：功能需求分配给软件模块，确定每个模块的功能和调用关系，形成模块结构图
• 详细设计（内部设计）：为每个具体任务选择适当的技术手段和处理方法

结构化设计原则：

• 模块独立性原则（高内聚、低耦合）
• 保持模块的大小适中
• 多扇入（复用率高），少扇出（耦合度低）
• 深度（一层一层的调用关系）和宽度均不宜过高

内聚

耦合

模块四要素

• 输入和输出：模块的输入来源和输出去向都是同一个调用者，即一个模块从调用者那儿取得输入，进行加工后再把输出返回调用者。
• 处理功能：指模块把输入转换成输出所做的工作
• 内部数据：指仅供该模块本身引用的数据
• 程序代码：指用来实现模块功能的程序

 二十六、面向对象设计

基本过程

类的分类

• 边界类：机器接口（API接口）、人机交互（用户界面：显示屏，二维码等）
• 控制类：解决应用逻辑、业务逻辑和数据访问逻辑
• 实体类：对接数据表

设计原则

• 单一职责原则：设计目的单一的类
• 开放-封闭原则：对外开放，对修改封闭
• 李氏替代原则：子类可以替换父类
• 依赖倒置原则：要依赖于抽象，而不是具体实现；针对接口编程，不要针对实现编程
• 接口隔离原则：使用多个专门的接口比使用单一的总接口要好
• 组合重用原则：要尽量使用组合，而不是继承关系到达重用目的
• 迪米特原则（最少知识原则）：一个对象应当对其他对象有尽可能少的了解

二十七、软件测试

动态测试：计算机运行

• 白盒测试法
• 黑盒测试法
• 灰盒测试法（白+黑）

静态测试：人工监测和计算机辅助分析

• 桌前检查
• 代码审查
• 代码走查

静态测试都是做静态分析

• 控制流分析：无法到达的语句等
• 数据流分析：引用未定义的变量、对以前未使用的变量再次赋值
• 接口分析：模块之间接口的一致性、子程序和函数之间的接口一致性、函数形参与实参的数量、顺序、类型的一致性
• 表达式分析：括号不匹配、数组引用越界、除数为零

27.1 白盒测试

白盒测试（结构测试）：主要用于单元测试阶段

• 控制流测试（逻辑覆盖测试）（语句覆盖最弱，路径测试覆盖最强）
• 数据流测试
• 程序变异测试（错误驱动测试）

黑盒测试（功能测试）：主要用于集成测试、确认测试和系统测试阶段

• 等价类划分：不同等价类，揭示不同问题；有效等价类/无效等价类
• 边界值分析：1<=x<=10,可取x的值为0,1,10和11作为测试数据
• 错误推测：依靠测试人员的经验和直觉
• 判定表：最适合描述在多个逻辑条件取值的组合所构成的复杂情况下，分别要执行哪些不同的动作。
• 因果图：根据输入条件与输出结果之间的因果关系来设计测试用例

27.2 测试阶段

单元测试：依据详细测试，模块测试，模块功能、性能、接口等

集成测试：依据概要设计，模块间的接口

系统测试：依据需求文档，在真实的环境下，验证完整的软件配置项能否和系统正确连接

确认测试：依据需求文档，验证软件与需求的一致性。内部确认测试、Alpha测试、Beta测试、验收测试，需要用户参与

回归测试：测试软件变更之后，变更部分的正确性和对变更需求的符合性

系统测试

• 功能测试
• 性能测试
  • 负载测试：各种工作负载下系统的性能
  • 压力测试（测上限）：系统的瓶颈或不能接受的性能点
  • 强度测试（测下限）：系统资源特别低的情况下运行
  • 容量测试（并发测试）：同时在线的最大用户数
  • 可靠性测试：MTTF之类的参数
• 健壮性测试
• 用户界面测试
• 安全性测试
• 安装与反安装测试

二十八、遗留系统演化策略

 

考虑遗留系统在业务价值和水平的高低

二十九、新旧系统的转换策略

 

直接转换：会先停止现有系统，再上新系统

并行转换：老系统和新系统并存

分段转换：转换一部分

三十、数据转换与迁移

三十一、软件维护

• 可理解性：是指通过阅读源码和相关文档，了解软件的功能和如何运行的容易程度
• 可修改性：修改软件的难易程度
• 可测试性：验证软件程序正确的难易程度
• 可靠性：一个软件的可靠性越高，需要维护的概率就会越低
• 可移植性：是指将软件从一个环境移植到新环境下正确运行的难易程度

三十二、软件维护类型

• 正确性维护（修bug）：识别和纠正软件错误与缺陷，测试不可能发现所有错误
• 适应性维护（应变）：指使应用软件适应环境变化（外部环境、数据环境）而进行的修改
• 完善性维护（新需求）：扩充功能和改善性能而进行的修改
• 预防性维护（针对未来）：为了适应未来的软硬件环境的变化，应主动增加预防性的新的功能，以使用系统适应各类变化而不被淘汰。经典实例：专用改通用。