软件工程思维脑图思维导图

按照功能划分

按照支持的过程划分

按照支持的范围划分

可行性研究、需求分析、软件设计、软件编码、软件测试、软件维护

定义：线性的开发模型，具有不可回溯性。开发人员必须等前一阶段的任务完成后，才能开始进行后一阶段的工作，并且前一阶段的输出往往就是后一阶段的输入。由于其不可回溯性，如果在软件生命周期的后期发现并要改正前期的错误，那么需要付出很高的代价。传统的瀑布模型是文档驱动的。

优点：过程模型简单，执行容易

缺点：无法适应变更。

适用于的开发项目

定义：快速建立一个能反映用户主要需求的原型系统用户试用原型系统之后会提出许多修改意见，开发人员按照用户的意见快速地修改原型系统，然后再次请用户试用……反反复复地改进，直到原型系统满足用户的要求。

本质：“快速”。开发人员应该尽可能快地建造出一个原型系统，以加速软件开发过程，节约软件开发成本。

目的：获知用户的真正需求，一旦需求确定了，原型将被抛弃

优点：有助于获取和理解用户需求； 尽早发现软件中存在的错误； 支持项目需求的动态变化。

缺点：不能支持风险分析； 开发者为了使一个原型快速运行起来，往 往在实现过程中采用折衷的手段。

适用于的开发项目

定义：把待开发的软件系统模块化，将每个模块作为一个增量组件，从而分批次地分析、设计、编码和测试这些增量组件。 运用增量模型的软件开发过程是递增式的过程。相对于瀑布模型而言，采用增量模型进行开发，开发人员不需要一次性地把整个软件产品提交给用户，而是可以分批次进行提交。

根据增量的方式和形式的不同，分为： 1、基于瀑布模型的渐增模型 2、基于原型的快速原型模型

优点：当产品不能在限定时间完成时，提供了先推出核心产品的途径。 逐步增加产品功能可以使用户有较充裕的时间学习和适应新产品。 当需求变更时，需要重新完成的分析和文档数量比较少。 在开发过程中更容易得到客户对于已完成的开发工作的反馈意见。 更快速地交付和部署有用的软件给客户成为可能。 人员分配灵活，刚开始不需投入大量人力资源。

缺点：软件体系结构必须是开放的。 模型本身是自相矛盾的。整体——独立构件。 不同的构件并行进行有可能加快工程进度，有时无法集成到一起。 整个过程是不可见的。管理人员需要定期交付成果来掌握进度。 随着新的增量的添加，系统结构趋向于降级。

定义：

适用于的开发项目

基本思想：

优点：有助于获取用户需求，加强对需求的理解。 尽早发现软件中的错误。 支持需求的动态变化。 支持风险分析，可降低或者消除软件开发风险。 适合于需求动态变化，难以确定开发风险的系统。

缺点：螺旋模型开发的成败，很大程度上依赖于风险评估的成败。 需要开发人员具有相当丰富的风险评估经验和专门知识。 通常使用的场合： 需求不能完全确定，同时又存在技术、资金或开发时间等风险因素的大型开发项目。

定义：

优点： 该模型的各个阶段没有明显界限，开发人员可以同步进行开发。 多次反复地增加或明确目标系统，降低了错误的可能性。

缺点： 由于喷泉模型在各个开发阶段是重叠的，因此在开发过程中需要大量的开发人员，不利于项目的管理。 要求严格管理文档，使得审核的难度加大，尤其是面对可能随时加入各种信息、需求与资料的情况。

在确定需求之后，开发人员开始从现有的组件库中筛选合适的组件，并对组件功能进行分析。 在对组件分析之后，开发人员可能适当修改需求来适应现有组件，也可能修改组件或寻找新的组件。 组件筛选完成之后，开发人员需要根据需求设计或使用现有的成熟开发框架复用这些组件，一些无法利用现有组件的地方，则需要进行单独的开发，新开发的组件在经历时间考验之后也会加入到组件库中。 最后将所有组件集成在一起，进行系统测试。

敏捷开发

极限编程

瀑布模型与RUP模型之间的关系

瀑布模型与增量模型之间的关系

瀑布模型与快速原型模型之间的关系

瀑布模型与螺旋模型之间的关系

在选择软件过程模型时需要考虑六点

项目发起人或单位为寻求他人的支持，要以书面材料的形式递交给项目的支持者和领导，使其明白项目的必要性和可行性。

可行性研究过程。可行性研究就是指在项目进行开发之前，根据项目发起文件和实际情况，对该项目是否能在特定的资源、时间等制约条件下完成做出评估，并且确定它是否值得去开发。

经过可行性研究后，还需要报告主管领导或单位，以获得项目的进一步审核，并得到他们的支持。

通过可行性研究和主管部门批准后，将其列入项目计划的过程。

说明项目的各项主要工作： 1、软件的功能和性能； 2、为完成项目应具备的条件； 3、甲方和乙方应承担的工作、完成期限和其他4、限制条件； 5、应交付的软件名称，所使用的开发语言及存储形式； 6、应交付的文档。

任务的划分，各项任务的责任人；说明项目开发进度，按阶段应完成的任务，用图表说明每项任务的开始时间和完成时间；说明项目的预算，各阶段的费用支出预算等。

开发该项目所需人员的类型、组成结构和数量等。

项目应交付的日期等。

“系统必须做什么?”，具体来讲：功能需求、性能需求、可靠性和可用性需求、 出错处理需求、接口需求、约束条件、逆向需求、将来可能提出的要求。

1. 确定系统的运行环境和要求

2. 确定系统的功能性需求和非功能性需求

3. 进行有效的需求沟通

4. 需求分析过程中应遵守的原则

5. 需求分析的两个任务

6. 软件需求规格说明书

1、需求获取

2、分析建模

3、需求描述

4、需求验证

为了更好的进行需求分析并记录需求结果，需要进行需求管理。需求管理是一种用于查找、记录、组织和跟踪系统需求变更的系统化方法。可用于： 获取、组织和记录系统需求； 使客户和项目团队在系统变更需求上达成并保持一致。 需求管理的关键在于维护需求的明确阐述、每种需求类型所适用的属性，以及与其他需求和其他项目工件之间的可追踪性。

“分解”是指对于一个复杂的系统，为了将复杂性降低到可以掌握的程度，可以把大问题分解为若干个小问题，然后再分别解决。

“抽象”是用最本质的属性，表示一个软件系统的方法。

1、建立当前系统的“具体模型”

2、抽象出当前系统的逻辑模型

3、建立目标系统的逻辑模型

4、为了对目标系统进行完整的描述还需要考虑人机界面和其他一些问题

数据流图

实体-关系图

状态转换图

定义：思想就是用抽象模型的概念，按照软件内部数据传递和变换的关系，自顶向下逐层分解，直到找到满足功能要求的可实现的软件为止。功能模型用数据流图来描述。

数据流图

数据建模的思想是在较高的抽象层次（概念层）上对数据库结构进行建模。数据模型用实体关系图来描述。

数据模型

复合信息

数据对象

属性

关系

ER图中包含

状态

事件

层次方框图

Warier（瓦尼尔）图

数据流的描述

数据元素的描述

数据存储的描述

处理的描述

数据的定义方法

一致性 所有需求必须是一致的，任何一条需求不能和其他需求互相矛盾。

完整性 需求必须是完整的，规格说明书应该包括用户需要的每一个功能或性能。

现实性 指定的需求应该是用现有的硬件技术和软件技术基本上可以实现的。

有效性 必须证明需求是正确有效的，确实能解决用户面对的问题。

验证需求的一致性 人工技术审查； 形式化的描述软件需求的方法；

验证需求的现实性 仿真或性能模拟技术

验证需求的完整性和有效性 开发原型系统；

有效性检查－－指功能需求是否符合用户所提出的需求。

一致性检查－－系统功能描述及约束是否一致。

完备性检查－－是否包含所有系统用户的需求和约束

可检验性检查－－能否设计出一组验证方法，确定了检验的标准。

软件设计在软件开发过程中处于核心地位，它是保证质量的关键步骤 。

使用基本的设计概念：模块化，抽象，逐步求精，信息隐蔽，自顶向下等。

软件结构图是系统的模块层次结构，反映了整个系统的功能实现，即将来程序的控制层次体系。 它表示的是软件元素之间的关系，比如调用关系、存储关系与嵌套关系。

结构图应注意的事项

数据流分为两种

顺序结构

选择结构

重复结构

便于表示层次结构，而且是对结构进行自顶向下分解的有力工具 形象直观可读性好 既能表示数据结构也能表示程序结构（因为结构程序设计也只使用上述3种基本结构）

用这种图形工具表示选择或重复结构时，选择条件不能直接在图上表示出来，影响了图的表达能力，也不易直接把图翻译成程序。此外框线间的线为斜线，不易在行式打印机上输出。

层次图中的一个方框通常代表一个模块，Jackson图中一个方框只代表几条语句 层次图表现的是调用关系，Jackson图表现的是组成关系

分析并确定输入数据和输出数据的逻辑结构，并用Jackson图描绘这些数据结构 找出输入数据结构和输出数据结构中有对应关系的数据单元

顺序型、 选择型、 先判定型循环（WHILE-DO）、 后判定型循环（DO-WHILE） 多分支选择型

优点：采用简单规范的符号，画法简单 结构清晰，逻辑性强 便于描述，容易理解

缺点：不利于逐步求精的设计 图中可用箭头随意地对控制进行转移，与结构化程序设计精神相悖 不易于表示系统中所含的数据结构 当目标系统比较复杂时，流程图会变得很繁杂、不清晰

特点：不允许随意的控制转移，有利于严格的结构化程序设计 可以很方便地确定一个特定控制结构的作用域，以及局部数据和全局数据的作用域 可以很方便地表示嵌套关系以及模块之间的层次关系

主要特点：表示的程序结构的执行顺序是自最左边的竖线的上端开始，自上而下，自左向右 表示的程序片断结构清晰、层次分明 支持自顶向下、逐步求精的设计方法 只能用于结构化的程序设计 不仅可以表示程序逻辑，还能表示数据结构

判定表用于表示程序的静态逻辑 判定表能够清晰地表示复杂的条件组合与应做的动作之间的对应关系 在判定表中的条件部分给出所有的分支判断的列表，动作部分给出相应的处理。

左上部列出所有条件 左下部是所有可能做的动作 右上部是表示各种条件组合的一个矩阵 右下部是和每种条件组合相对应的动作 判定表右半部实质上是一条规则,规定了与特定条件组合相对应的动作.

列出与一个具体过程(或模块)有关的所有处理 列出过程执行期间的所有条件(或所有判断)。 将特定条件取值组合与特定的处理相匹配,消去不可能发生的条件取值组合。 将右部每一纵列规定为一个处理规则,即对于某一条件取值组合将有什么动作。

判定树也是用来表达加工逻辑的一种工具 判定树是判定表的图形化表示，是判定表的变种。

PDL

伪码

描述系统最基础的数据结构

提供比较接近数据库内部构造的逻辑描述

数据库的物理数据模型

机器语言和汇编语言、高级语言

1）有理想的模块化机制；

2）可读性好的控制结构和数据结构；

3）便于调试和提高软件可靠性；

4）编译程序发现程序错误的能力强；

5）有良好的独立编译机制。

Java：纯面向对象，垃圾自动回收功能，跨平台特性

C语言：面向过程，执行效率非常高

C++：面向对象，部署方便，执行效率高

Python:完全面向对象的语言

好程序的标准

编程的基本原则

效率

是为了检测出软件存在错误

不同立场出发，存在两种完全不同的测试目的

杀虫剂现象

1.完全测试是不可能的

2.测试中有风险存在

3.软件测试只能表明缺陷的存在，而不能证明

产品已经没有缺陷

4.软件产品中所存在的错误数与已发现的错误

数成正比

5.要避免软件测试的杀虫剂现象

6.在设计测试用例时，应包括输入数据和预期

的输出结果两个部分

7.要集中测试容易出错或错误较多的模块

8.应该长期保留所有的测试用例

9.使开发人员和测试人员分立

10.测试工作应该尽早开始

按开发阶段

按测试实施组织

按测试技术

按测试内容

1.制定测试计划

2.编制测试大纲

3要设计和生成测试用例

4实施测试

5生成软件问题的报告。

Ⅴ模型

W模型

H模型

测试用例，英文Test Case，缩写为TC/指的是在测试执行之前设计的一套详细的测试方案，包括测试环境、测试步骤、测试数据和预期结果。测试用例设计的好坏直接决定了测试的效果和结果，所以在软件测试活动中最关键的步骤就是设计有效的测试用例。测试用例可以针对黑盒测试设计用例，也可以针对白盒测试设计用例。

静态测试

动态测试

有效等价类：输入的是有效的数值

无效等价类：输入的是非法的数值

软件测试所包含的边界条件：数字、字符、位置、质量、大小、速度、方位、尺寸、空间

对应的边界值：最大/最小、首位/末位、上/下、最快/最慢、最高/最低、最短/最长、空/满

列举出程序中所有可能有的错误和容易发生错误的特殊情况，根据它们选择测试用例。

一种利用图解法分析输入的各种组合情况，从而设计测试用例的方法，它适合于检查程序输入条件的各种组合情况。

分析和表达多逻辑条件下执行不同操作的情况的工具。在所有的黑盒测试方法中，基于决策表（也称为判定表）的测试是最为严格、最具有逻辑性的测试方法。

在任何情况下都必须选择边界值分析方法

必要时用等价类划分法补充一些测试用例

用错误推测法再追加一些测试用例

如果程序的功能说明中含有输入条件的组合情况，则可选用因果图法和决策表法

代码检查法包括桌面检查、代码审查和走查。

代码检查应该在编译和动态测试之前进行。

代码检查法可以使用测试软件进行自动化测试或人工测试 。

以图的形式表现程序的内部结构

对代码机械性的、程式化的特性进行分析

向源程序中添加一些语句，实现对程序语句的执行、变量的变化等情况进行检查。

语句覆盖

判定覆盖

条件覆盖

条件判定覆盖

条件组合覆盖

路径覆盖

独立路径

环路复杂度

1、非增量式集成：先分别测试每个模块，再将所有模块按照设计要求放在一起结合成所要的程序。

2、增量式集成：将下一个要测试的模块同已经测试好的那些模块结合起来进行测试，测试完后再将下一个应测试的模块结合起来进行测试 。

测试范围可分为功能测试、性能测试、压力测试、容量测试、安全性测试、图形用户界面测试、可用性测试、安装测试、配置测试、异常测试、备份测试、健壮性测试、文档测试、在线帮助测试、网络测试、稳定性测试。

收集各种软件说明书，作为系统测试的参考

仔细阅读软件测试计划，最好制定单独的系统测试计划，作为系统测试的根据，并收集已编好的测试用例

如果没有现成的系统测试用例，则需要做大量工作来编写测试用例

不管软件内部是如何实现的，只是根据需求规格说明书和测试需求列表，验证产品的功能是否符合需求规格。

主要检验以下几个方面： ①功能是否全部实现，有没有遗漏 ②功能是否满足用户需求和系统设计的隐藏需求 ③能否正确地接受输入，并给出正确结果

测试软件系统在实际的集成系统中运行性能。 性能测试的目的是度量系统相对于预定义目标的差距。 性能测试一般要有专门的工具支持，必要情况下，还要自己开发专门的接口工具。

可能要考虑的方面

目的：是验证系统的保护机制是否能够在实际的环境中抵御非法入侵，恶意攻击等非法行为。

测试人员常常扮演系统攻击者的角色，然后尝试各种方案入侵系统

系统设计者的目的是要把系统设计为想要攻破系统而付出的代价大于攻破系统之后得到的信息价值

安全测试机制的性能和安全机制本身一样重要

GUI 测试包含两方面内容：一是界面实现与界面设计是否吻合；二是界面功能是否正确。

确认测试分析报告

最终的用户手册和操作手册

项目开发总结报告。

1、配置复审

2、合法性检查

3、软件文档检查

4、软件代码测试

5、软件功能和性能测试

6、测试结果交付内容

由用户在开发者的场所进行，并且在开发者对用户的“指导”下进行测试。

由软件的最终用户在一个或多个客户场所进行。 这些用户返回有关错误给开发者。

测试时，开发者通常不在测试现场，因而β测试是在开发者无法控制的环境下进行的软件现场应用。

调试活动由两部分组成：①确定程序中可疑错误的确切性质和位置。②对程序(设计、编码)进行修改，排除这个错误 调试是在测试发现错误之后排除错误的过程。 调试途径：①蛮干法 ②回溯法③原因排除法（对分查找法、归纳法、演绎法） 调试过程的结果： 找到了问题的原因并把问题改正和排除掉了 没找出问题的原因

在软件产品交付给用户之后，为了改正软件测试阶段未发现的缺陷，改进软件产品的性能，补充软件产品的新功能等，所进行的修改软件的过程。

1、建立维护机构

2、用户提出维护申请并提交维护申请报告

3、维护人员确认维护类型并实施相应的维护工作

4、整理维护记录并对维护工作进行评审

5、对维护工作进行评价

纠错性维护：为了识别并纠正软件产品中所潜藏的错误，改正软件性能上的缺陷所进行的维护

适应性维护：为了使软件产品适应软硬件环境的变更而进行的维护

完善性维护：软件维护的主要部分，针对用户对软件产品所提出的新需求所进行的维护 

预防性维护：为以后进一步维护软件打下了良好的基础

可理解性 

可测试

可修改性

修改代码的副作用：每次对代码的修改都有可能产生新的错误

修改数据的副作用：数据结构被改动时有新的错误产生的现象

修改文档的副作用：在软件产品的内容更改之后没有对文档进行相应的更新而为以后的工作带来不便的情况