软件工程期末冲刺

一、软件工程的产生与发展

(一)软件工程的产生与发展

软件的本质特征：

软件具有复杂性、一致性、可变性和不可见性等固有的内在特性，这是造成软件开发困难的根本原因。

什么是软件工程

应用软件领域的理论方法来解决软件系统“从无到有”、“从有到好”的过程。

工程化思想

1. 分而治之
2. 折中
3. 复用

（二）软件工程的基本概念

1. 软件工程的基本要素：方法、过程、工具、泛型

2. 软件工程所关注的目标

功能性需求：软件所实现的功能达到它的设计规范和满足用户需求的程度
非功能性需求：系统能够完成锁期望的工作的性能与质量如可用性、可修改性、安全性等等

二、软件项目开发

（一）软件项目开发过程

1、软件开发过程的典型就阶段

计划->需求分析->软件设计->软件实现->软件验证->软件维护

2.典型软件过程模型

（1）瀑布模型

1. 基本思想
   将软甲开发将软件开发过程划分为分析、设计、编码、测试等阶段工作。以线性方式进行，上一阶段的输出是下一阶段的输入。每个阶段均有里程碑和提交物
2. 特点
   需求最为重要，假设需求是稳定的
   以文档为中心，文档是连接各阶段的关键
3. 问题
   很难实现需求的稳定，用户只有在项目尾声时才能得到可执行的程序，任务之间有依赖容易阻塞
4. 适用场景
   软件项目较小
   需求在项目开始之前已经被全面的了解
   需求在开发中不太可能发生重大改变
   外部环境的不可控因素很少

（2）增量过程模型

1.增量模型

软件被作为一系列的增量来进行开发，每一个增量都提交一个可以操作的产品，可供用户评估
本质是以迭代的方式运用瀑布模型
适用：再开始开发时，需求明确且可分解。在开发中希望尽快提交其中的一些增量产品。

2.快速应用程序开发（RAD）

侧重于短周期开发的增量过程模型，通过基于已有资源的构建方法实现快速开发
本质是瀑布模型的高速变体，并行运行瀑布模型

（3）演化过程模型

1.快速原型开发模型

得到基本需求后简单分析就进开发，原型是用来让用户评估和提意见的，随时可能被抛弃

2.螺旋模型

该模型将软件生存周期的活动分为四个可重复的阶段：规划、风险分析、开发和评估
螺旋重复四个阶段

（二）软件项目开发管理

1.基本概念

1. 项目(Project)：精心定义的一组活动，使用受约束的资源(资金、人、原料、能源、空间等)来满足预定义的目标
2. 项目管理(Project Management, PM)：有效的组织与管理各类资源(例如人)，以使项目能够在预定的范围、质量、时间和成本等约束条件下顺利交付(deliver)。
3. 团队：由少量的人组织，具有互补的技能，对一个共同目的、绩效目标及方法做出承诺并彼此负责
4. 主程序员式组织结构：以主程序员为核心，主程序员既是项目管理者也是技术负责人，团队其他人员的职能进行专业化分工。
5. 矩阵式组织结构：将技术与管理工作进行分离，技术负责人负责技术决策，管理负责人负责非技术性事务的管理决策和绩效评价

2.软件项目估算

估算的类别

（1） 规模估算

规模估算是对所开发软件的规模进行估计，它是其他估算的基础，通常以代码行、功能点、故事点等作为衡量单位。

（2） 工作量估算

工作量估算是结合投入人力和开发任务所需要的工作时间进行估算，通常以人时、人天、人月、人年等作为衡量单位。

（3） 进度估算

进度估算是以项目阶段为单位，通过任务分解、工作量估算、有效资源分配等对项目可能实施的进度给出正确的评估。

（4） 成本估算

成本估算是对包括项目投入的人力、物质、有形和无形的支出成本进行估算，一般软件项目以人力成本为主要部分。

估算的风险

估算的风险取决于资源、成本及进度的定量估算中存在的不确定性

基本估算方法

分段估算、专家判断、参数估算

代码行技术LOC

从过去开发类似产品的经验和历史数据出发，估计出所开发软件的代码行数。

功能点技术方法FP

功能点方法是依据软件信息域的基本特征和对软件复杂性的估计，估算出软件规模。这种方法适合于在软件开发初期进行估算，并以功能点为单位度量软件规模。

COCOMO模型

结构性成本模型 COCOMO（COnstructive COst MOdel）是一种利用经验模型进行成本估算的方法。

故事点方法

把一些常见“标准任务”给出一个“标准点数”，形成比较基线；估算时只要是同一类型任务，直接写故事点数而非天数

机器学习方法

人工神经网络是采用一种学习方法导出一种预测模型，首先建立神经网络，再使用一组历史项目数据（样本数据）训练网络，训练后的网络可以用于估算新项目的工作量。

3.项目进度安排

工作量分配

40-20-40原则（40给前期分析和设计，20给编码，40给测试）

定义任务网络

用网络图任务之间的依赖关系

时间分配

计算关键路径

计算任务网络中的关键路径

确定最终的开始和结束日期

松弛量(Slack)：在不影响最终交付日期的前提下，一个任务最多可被推迟的总天数。

绘制任务进度安排图

甘特图（Gantt Chart）是一种通用的显示进度方法，其横轴表示时间，纵轴表示活动，线条表示在整个期间上计划和实际的活动完成情况

4.项目风险管理

风险识别

风险预测

建立风险表（可能的风险、发生的概率、可能的后果、缓解的策略）

风险缓解检测和管理

三、需求

（一）软件需求及需求工程

软件需求

需求定义

以一种清晰、简洁、一致且无二义性的方式，描述用户对目标软件系统在功能、行为、性能、设计约束等方面的期望，是在开发过程中对系统的约束。
需求通常用于表达“做什么”，而不描述“如何做”

需求分类

功能性需求

1. 业务需求：客户对于系统的高层次目标要求，定义了项目的远景和范畴（这个系统是干什么的）
2. 用户需求：描述的是用户的目标，或者用户要求系统必须完成的任务（每个用户使用这个系统来做什么）
3. 系统需求：系统应该提供的功能和服务，通常涉及用户或外部系统与该系统之间的交互，不考虑系统内部的实现细节

非功能性需求

非功能性需求定义软件系统以及软件开发过程为满足系统功能需求要满足的其他约束条件

需求工程

1.需求获取

通过与用户的交流，对现有系统的观察及对任务进行分析，从而开发、捕获和修改用户的需求

2.需求分析

对收集到的需求进行提炼、分析和审查，为最终用户所看到的系统建立概念化的分析模型

3.需求规格说明

精确的、形式化的阐述一个软件系统必须提供的功能、非功能、所要考虑的限制条件等

4.需求验证

对其他需求工程活动的质量的保证。通过数学的形式化工具或工程化的测试过程来确保系统满足干系人的要求

（二）需求获取与建模

需求获取的手段

面对面访谈、问卷调查、专题讨论会、头脑风暴

需求建模

基于场景的方法

1.用户故事

格式：作为一个角色,可以活动，以便于价值

2.用例图

uml-面向对象的建模语言

用例描述了使用者使用系统完成用户某一目标的过程

单纯的用例图并不能描述完整的信息，需要用文字描述不能反映在图形上的信息

3.活动图

显示了组成复杂过程的步骤序列，例如算法或工作流

（三）需求规格说明

需求规格说明书（SRS）是具有一定法律效力的合同文档。
清楚地描述软件在什么情况下，需要做什么，以及不能做什么

三大组成部分

引言（应该如何使用这份SRS）、整体描述和需求描述

四、软件开发

(一)软件工程开发方法与软件设计

软件工程开发方法

传统开发方法

1. 功能分解法：以系统需要提供的功能为中心来组织系统
2. 结构化方法：以数据流为核心，将对数据流的处理过程进行抽象，系统=功能+数据
3. 信息建模法：核心概念是实体和关系，实体和关系都可以带有属性（E-R法）

面向对象方法

分析的核心是与问题有关的实体，系统=对象+消息

软件设计

设计的原则

抽象、封装、模块化、层次化、复用

系统分解原则：内聚性、耦合性

（二）体系结构设计

软件体系结构要素

软件体系结构（Software Architecture）包括构成系统的设计元素的描述、设计元素之间的交互、设计元素的组合模式以及在这些模式中的约束
软件体系结构 = 勾践 + 连接件 + 约束

构件（component）

构件是具有某种功能的可复用的软件结构单元，表示系统中主要的计算元素和数据存储
特点：可分离、可替换、可配置、可复用
构件的接口与其内部实现应该严格分开

连接（connection）

连接是构件之间建立和维护行为关联与信息传递的途径

约束（constraints）

构件之间的协议

软件体系结构风格

数据流风格

如管道-过滤器风格，通过数据流将任务之间的步骤连接起来

以数据为中心的风格（仓库）

数据存储位于结构中心，其他构件会经常访问该数据存储对数据进行操作

调用和返回体系结构风格

本质：将大系统分解为若干模块，主程序调用这些模块实现完整的系统功能

面向对象体系结构风格

以类为构件，以类之间的函数调用和消息传递为连接件

层次体系结构风格

系统被组织成若干个层次，每个层次由一系列构件组成
例：C/S、B/S、混合模式

（三）类/数据建模与设计

1.CRC卡片分拣法-面向对象方法

1. 识别对象
2. 识别类的功能职责
3. 识别类交互协作关系

2.DFD-结构化方法

数据流图

主要元素有数据流、加工、数据存储、外部实体

1. 加工:对数据流进行某些操作或变换
2. 数据存储：需要在外存储器上保存的数据，它可以是数据库文件或任何形式的数据组织
3. 外部实体：本系统外部环境中的实体（包括人员、组织或其他软件系统）
4. 数据流：数据在系统内传播的路径

DFD的层次性

自顶向下的分解：

1. 顶层DFD图（关联图）

通过系统和外部世界之间的联系来描述系统的范围
2. 0层DFD

将顶层DFD中的系统分解为若干个子系统，决定每个子系统间的数据接口和活动关系
3. 底层DFD

继续细化到无需继续分解，是最基本的加工

DFD的基本原则

1. 把数据存储放在0层或更低层的子图上，不要放在顶层的关联图上
2. 使用数据流图是，不要试图让数据流图反映处理的顺序，忽略系统的运行时的时间特性
3. 加工通过数据存储进行通讯，尽量避免从一个加工直接流到另一个加工
4. 数据不能直接由一个数据存储直接流到另一个数据存储
5. 数据不能直接从一个外部实体直接流到一个数据存储
6. 数据不能直接从一个数据存储直接流到一个外部实体
7. 数据不能直接在外部实体之间流动
8. 数据流是单向的
9. 任何加工必须有输入和输出数据流
10. 对现有加工进行持续的分解和组合，直到所有加工之间达到较高的聚合度
11. 尽量将每一张DFD上的所有元素数目控制在7-12个

（四） 行为建模与设计

状态图

描述了一个特定对象的所有可能状态以及由于各种事件的发生而引起的状态之间的转移

组成

状态、状态转移、事件

特殊的状态

初始状态、结束状态、组合状态、历史状态

状态图的绘制

详细见题目

顺序图

强调消息时间顺序的交互图

组成：

对象、生命线、激活、消息

绘制：

见题目

协作图

只对相互间有交流的对象和这些对象间的关系建模

活动图

本质上就是流程图

（五） 物理建模与设计

组件图

组件是物理上的，对象是逻辑上的

五、软件编码、测试与质量保障

（一）软件编程

良好的编程实践

文档化的代码、注释、规范化

代码审查

代码重构

1.定义

重构是对软件内部结构的一种调整，其目的是在不改变软件功能和外部行为的前提下，提高其可理解性、可扩展性和可重用性

2.重构方法

抽取方法、引入解释性变量、简化条件表达式、

（二）软件测试

概述

1.术语解释

1. 错误：在软件生存期内不希望或不可接受的人为错误，其结果是导致软件缺陷的产生
2. 缺陷：软件缺陷是存在于软件产品之中的那些不希望或不可接受的偏差，其结果是软件运行于某一特定条件时出现故障
3. 故障：软件运行过程中出现的一种不希望或不可接受的内部状态，若无适当措施（容错）加以及时处理，便产生软件失效
4. 失效：软件运行时产生的一种不希望或不可接受的外部行为结果

2.软件测试概念

测试是使用人工和自动手段来运行或检测某个系统的过程，其目的在于检验系统是否满足规定的需求或弄清结果与实际结果之间的误差

3.软件测试原则

集群性：软件错误具有聚集性，对存在错误的部分应该重点测试
杀虫剂悖论：用同样的测试用例多次虫谷测试，最后将不再能发现新的缺陷。因此，测试用例需要定期修改和新增

软件测试策略

1.软件测试的对象

需求规格说明、设计规格说明、源程序

2.软件测试类型

1. 测试对象角度：单元测试（每个模块分别测试），集成测试（将所有单元组装为子系统或系统进行测试）系统测试（包括恢复测试，安全性测试，压力测试，性能测试），验收测试（验证是否满足用户要求）
2. 测试技术角度：黑盒测试（功能测试），白盒测试（结构测试）
3. 程序执行角度：静态测试、动态测试
4. 人工干预角度：手工测试、自动化测试

3.测试用例

具有代表性和典型性，寻求系统设计和功能设计的弱点，既有正确输入也有错误或异常输入，考虑用户使用的多场景

（三）白盒测试

概述

白盒测试（又称为结构测试或逻辑驱动测试），把测试对象看做一个透明的盒子，允许测试人员利用程序内的逻辑结构及有关信息，设计或选择测试用例对程序所有逻辑路径进行测试

方案

1.逻辑覆盖

2.控制结构测试

（1）基本路径测试

1. 画出流程图
2. 画出流图（拆分流程图中的判定条件）
3. 确定环复杂度
4. 确定独立路径的基本集合
5. 设计测试用例

（2）循环测试

简单循环、嵌套循环、串接循环、非结构循环

（四）黑盒测试

黑盒测试概述

又称“功能测试”，是一种从用户观点出发的测试。将测试对象看做一个黑盒子，测试人员不考虑程序内部结构，只依据需求规格说明书检查程序的功能。

测试方法

1.等价类测试

将程序的输入划分为若干个数据类，从中生成测试用例。并合理的假定：测试某等价类的代表值就等于对这一类其他值的测试。
要求：无冗余、无漏洞
等价类类型：有效等价类（检测系统功能是否正常），无效等价类（检测程序容错性）

2.边界值测试

通常作为等价类测试的补充，测试用例来自于等价类的边界。

3.场景法测试

按照不同场景来设计用例
比如ATM取款，有成功、ATM内无现金、ATM内现金不足等场景

（五）变异测试

基本思想

给定一个程序P和一个测试数据集T，通过变异算子为P产生一组变异体Mi（合乎语法的变更），对P和M都使用T进行测试运行。如果Mi在某个测试输入t上产生与P不同的结果，则该Mi被杀死，否则称为活的变异体。对所有获得变异体进行分析，是否与P等价，如果不等价则进一步测试。

概念

如果P'与P不等价，但T中没有测试可以区分P'和P，则称T是不充分的。可以利用这种方式对T进行增强。

（六）性能测试

分类

1. 压力测试：施加越来越大的负载，直到发现程序性能下降的拐点
2. 负载测试：不断施加压力或一定压力下持续一段时间，直到系统达到极限
3. 强度测试：迫使系统在异常资源下运行，测试对异常的抵抗力
4. 并发测试：测试并发性
5. 大数据测试：测试数据处理极限
6. 配置测试：通过测试找到系统各项资源的最优分配原则
7. 可靠性测试：加载一定压力情况下检验系统是否稳定

六、软件实施、维护与演化

（一）敏捷开发

敏捷开发概述

敏捷开发是一种基于更紧密的团队协作、能够有效应对快速变化需求、快速交付高质量软件的迭代和增量的新型软件开发方法。
敏捷开发方法中，适应大于设计。软件不是一开始设计好的，而是一步步迭代好的。
影响最大的是XP方法和Scrum方法，前者偏重编程实践，后者偏重项目管理。

Scrum方法

Scrum方法兼顾计划性和灵活性，将整个开发过程分为若干次更小的迭代，每个迭代周期称为一个冲刺，每个冲刺就是一个小的瀑布模型。

（二）软件实施、维护与演化

软件交付工作

1.项目实施

项目实施是将软件系统部署到客户方的计算机系统上，协助客户准备基础数据，使软件系统顺利上线运行

2.客户培训

在系统安装完成、基础数据准备齐全之后，应该组织客户培训，使其掌握对软件系统的使用和操作。

3.项目验收

客户对系统进行验收测试，包括范围核实（用户需求是否全部实现）和质量核实（质量属性是否满足要求）。

软件演化法则

Lehman法则

软件维护

为了修改软件的缺陷或者增加新功能而对软件进行修改；软件的修改通常发生在局部，一般不会改变整个结构

软件再工程

为了避免软件本身退化而对软件的一部分进行重新设计、编码和测试，以便提高软件的可维护性和可靠性等