概述
这个复习笔记主要是记录了软件工程学习中基本笔记，内容有些简略，但是基本涉及，下面指点出来的可以细细去学习一下，可以跟老师的PPT来。
- 黑盒白盒测试中各个方法及其案例
- UML一些例图的基本规则和使用
- 结构化设计工具中部分工具的案例
- PPT上老师给出的软考案例题
- 软件测试中的测试用例
- 实用软件工程（吕云翔）课本后面的题目
- 软考的三道大题，对应课本4,5,6章
最终的考试：
- 21个单选题，3个多选题，7个判断题，基本上是课件上课本里讲过的（下面的笔记还是有点用的，当然要靠自己去学）。
- 填空题：4题7个空，哇，有点难，有两空完全不会，我觉得要将PPT结合书本去看，主要还是PPT，那两分小问题的。还考了一个Scrum框架，我不清楚我写对了没。喵的我没认真去看这块，东西太多了。
- 说说增量模型与迭代模型，并讲一下这两个之间的区别
- 软考三个大题，课上讲过的，PPT上有的，简单的很！画用例图、按照实例补充活动图中的空。
总结：考试不难，认真看一遍PPT或者书本，多留意PPT上面的题目，会做就OK了
第一章 软件工程概述
学习课程：掌握系统的软件开发理论、技术和方法、使用正确的工程方法开发出低成本、可靠、性能好、能高效运行的软件，为今后从事软件开发和维护打下坚实基础。
软件
-
软件的定义：软件不是程序，而是程序、数据以及开发、使用和维护程序需要的所有文档的完整集合。
-
软件的特点：复杂性(代码多而复杂)、不可见性、演化性(版本迭代)
-
软件的分类
- 软件发展
- 程序设计阶段（个人开发）
- 软件产生个体化，规模小
- 软件是设计者头脑中隐含的过程，除程序清单，无文档材料保存
- 为单个用户提供定制软件，包括技术咨询、软件编程和维护
- 软件销售是一次性的
- 程序系统阶段（软件作坊）
- 产品软件由专门的开发组织开发
- 软件维护工作耗费大量资源（软件危机）
- 公约组织提出软件工程
- 软件工程阶段（企业解决方案）
- 打破软件生产个体化的特征，出现工程化设计原则、方法和标准
- 以企业解决方案供应商面目出现
- 互联网快速发展，软件工程遇到新的挑战！
- 目前阶段（面向大众的成套软件）
- 软件架构发生变化：集中主机环境、客户机服务器、浏览器服务器
- 新技术：专家系统、人工智能、神经网络、并行计算、网格技术、云计算
- 程序设计阶段（个人开发）
- 软件发展
软件危机
软件开发遇到的问题：
- 不能满足用户需求
- 软件成本逐年上升，硬件越来越廉价
- 软件质量难以得到保证，且难以发挥硬件潜能
- 难以控制开发风险，开发速度赶不上市场变化
- 软件产品维护困难，集成系统更加困难
- 软件文档不完备
- 软件危机：计算机软件的开发和维护过程中所遇到的一系列严重问题
- 软件危机的原因：（主要是软件本身的特点及开发方法）
- 客观：缺乏“可见性”、软件经常维护、软件规模庞大
- 主观：忽视需求分析的重要性、没有认识到软件产品的权重、对于开发过程没有进行有效的管理
- 如何消除软件危机：
- 首先应该对计算机软件有一个正确的认识
- 软件开发不是个体的劳动，应该是团队协作完成的项目
- 推广项目开发中成功的技术和方法、研究更好更有效的技术和方法
- 开发和使用更好的软件工具
软件工程
软件工程是一门交叉学科，目的是为了消除软件危机
- 工程化方法的特点：
- 注重问题的分解与合并
- 注重建模
- 软件工程的三要素：过程（支持软件生命周期的所有活动）、方法（为软件开发过程提供“如何做”的技术）、工具（提供半自动化的环境支撑）
- 1968年，在北大西洋公约组织举行的一场学术会议上，首次提出软件工程概念。
软件质量特性
第二章 软件过程
软件过程
- 过程：一组将输入转化为输出的相互关联或相互作用的活动
- 软件过程：是为了获得高质量软件而实施的一系列活动
软件生命周期
-
概念：软件产品的生命周期是指从设计产品的构想开始，到软件需求的确定、软件设计、软件实现、产品测试与验收、投入使用已经产品版本的不断更新，到最终该产品被市场淘汰的全过程。
-
传统的软件生命周期：
-
软件生命周期
- 软件定义：问题定义、可行性分析、需求分析
- 软件开发：概要设计、详细设计、编码、软件测试
- 软件维护：通过维护是系统持久满足用户要求
软件过程模型
瀑布模型
- 瀑布模型的特点
- 阶段具有顺序性和依赖性：前一阶段结束是后一阶段的开始，前一个阶段输出文档，后一个阶段输入文档。
- 文档驱动的，过程模型简单、容易执行、不可回溯性
- 适用场景：开发人员经验丰富、需求确定、风险较低
快速原型模型
- 快速原型的优点：
- 通过原型准确获取用户需求
- 克服瀑布模型的缺点，减少由于软件需求不明确带来的开发风险
- 线性顺序进行的
- 快速原型的缺点：
- 没有经过严谨的系统设计和规划，可靠性和性能都难以保障
- 让客户觉得开发成本很低
增量模型（渐增模型）
- 优点：
- 具有瀑布模型的所有优点
- 将待开发的软件系统模块化，分批次的提交软件产品，使用户可以及时了解软件项目的进展。
- 第一个可交付版本需要的成本和时间是很少的，由于很快发布了第一个版本，因此可以减少用户的需求变更。
- 开发顺序灵活
- 适用于：
- 待开发的软件系统能够被模块化
- 软件产品可以分批次的进行交付
- 软件开发人员应用领域不熟悉，难以一次性进行系统开发
- 项目管理人员把握全局的水平较高
迭代（演化）模型
螺旋模型
- 优点：将风险分析扩展到各个阶段中，大幅度降低了软件开发的风险，对于大型软件项目有较好的风险控制
- 有助于把软件质量作为软件开大的一个重要目标
- 减少了过多测试或测试不足所带来的风险
- 在维护和开发之间并没有本质的区别
- 缺点：需要风险评估的经验和专门知识，也需要费用
- 使用场景：适合大型软件项目
喷泉模型
- 优点：无缝，可同步开发，提高开发效率，节省开发时间，适应面向对象软件
- 缺点：可能随时加各种信息、需求与资料，需严格管理文档，审核难度加大
Rational 统一过程模型
统一软件开发过程（RUP）模型是基于UML的一种面向对象软件开发模型，集中了多个软件开发模型的优点，采用迭代和增量递进的开发策略。
- 优点：
- 不断的版本发布成为一种团队日常工作的真正驱动力
- 将发现问题、制定方案和解决过程集成到下一次迭代
- 迭代开发，降低风险
- 更好的安排产品开发的辅助过程
各种软件开发模型的对比
敏捷开发方法
敏捷方法概述
敏捷开发是一种基于更紧密的团队协作、能够有效的应对快速变化的需求、快速 交付高质量的软件的迭代和增量的新型软件开发方法。
- 更关注协作
- 更关注质量
- 更关注可工作的产品
- 更关注全才化的专才
- 基于实践而非基于理论
有兴趣可以去网上查看，反正我这里看不下去了QAQ
极限编程（XP）
极限编程和传统方法的不同在于它更强调可适应性而不是可预测性。极限编程的支持者认为软件需求的不断变化时很自然的现象，是软件项目开发中不可避免的、也是应该欣然接受的现象。
- 极限编程：是一种实践性较强的规范化软件开发方法，它强调用户需求和团队工作
- 极限编程特别适用于软件需求模糊且容易改变、开发团队人数少于10人、开发地点集中的场合。
- 结对编程：由两名程序员在同一台电脑上结对编写解决同一问题的代码。
- 极限编程的5个价值观：沟通、简单、反馈、勇气、尊重
- 五个原则：快速反馈、假设简单、增量变化、拥抱变化、高质量的工作
- 12个最佳实践
- 完整的团队
- 小发布
- 系统隐喻
- 简单的设计
- 测试驱动
- 重构
- 结对编程
- 代码全体共有
- 持续集成
- 设计改进
- 编码标准
- 现场客户
- 规划游戏
第三章 可行性分析
可行性分析的目的
目的：用最小的代价最短的时间来确定问题是否能够解决
经过项目发起、项目论证、项目审核和项目立项四个过程后，一个软件工程的项目正式启动了
可行性分析的任务
可行性研究有多个方面：战略、操作、计划、技术、社会、市场、经济、风险等可行性。
可行性研究的任务：一般从经济、技术、操作和法律四个方面来研究每种解法的可行性，做出明确的结论来供用户参考
- 经济可行性主要进行成本-效益分析，从经济角度、确定系统是否值得开发。经济效益通常可用货币的时间价值、投资回收期和纯收入来度量。
- 技术可行性分析主要根据系统的功能、性能和约束条件等。分析现有的资源和技术条件下系统能否实现。
- 操作可行性是对开发系统在一个给定的工作环境中能否运行或运行好坏程度的衡量。操作可行性研究决定在当前的政治意识形态、法律法规、社会道德、民族意识以及系统运行的组织机构或人员等环境下，操作系统是否可行。
- 法律可行性：研究系统开发过程中可能会涉及到的合同、侵权、责任以及各种法律相抵触的问题。法律可行性分析主要依据如下：
- 中华人民共和国著作权法实施条例
- 计算机软件保护条例
- 可行性的研究的步骤
- 明确系统目标
- 分析研究现行系统
- 设计新系统的高层逻辑模型
- 获得并比较可行的方案
- 撰写可行性研究报告
第四章 结构化分析
需求工程
软件项目的失败原因案例中，不充分的需求规范和需求的改变导致项目失败占比很高。
- 需求是什么：是一种解决问题后所能达到的期望；一件事的两面（问题是糟糕的一面，需求是理想的一面）
- 需求分析的常用方法：
- 功能分解法
- 结构化分析方法
- 信息建模方法
- 面向对象分析方法
- 需求分析的步骤：
- 需求获取
- 分析模型
- 需求描述
- 需求验证
需求的层次
业务需求
描述组织或客户的高层次目标，是系统目标，它必须是业务导向、可度量、合理可行的。业务需求从总体上描述了为什么要开发系统（why），组织希望达到一个什么目标。
用户需求
描述的是用户使用产品必须完成的目标或任务，怎么完成需求，通常是在问题定义的基础上进行用户访谈、调查，对用户使用的场景进行整理，从而建立从用户角度的需求。用户需求描述可使用系统来做些什么（what）。
系统需求
描述用户对系统行为的期望，每个系统需求反映了一次外界与系统的交互行为。功能需求规定开发人员必须在产品中实现的软件功能，用户利用这些功能来完成任务，满足业务需求。功能需求是需求的主体，它描述的是开发人员如何设计具体的解决方案来实现这些需求（How）
需求分类
结构化分析方法
结构化分析方法概述
数据流图（DFD）
- 数据流图（DFD图）描绘系统的功能模型，描绘数据在系统中流动和处理的情况。
- 创建“数据流图”有两个目的：
- 指出当数据在软件系统中移动时怎么样被变换；
- 描绘变换数据流的功能和子功能
数据字典
数据字典是关于数据信息的集合，也就是对数据流图中所包含元素的定义集合。
E-R 图
- 构成E-R图的基本要素：实体、属性、联系。
- 关系规范化在数据库设计的逻辑设计阶段实现的。逻辑阶段设计数据库表，确定表以及表之间的关系。
状态转换图（STD）
- 是一种描述系统对内部或者对外部事件响应的行为模型。描述系统状态和事件，事件引发系统在状态间的转换，而不是描述系统中数据的流动。适用于描述实时系统。
第五章 结构化设计
软件设计
软件设计阶段做什么：
- 问题的定义–>“要解决什么问题”
- 可行性分析–>“能不能实现”
- 软件需求分析–>“系统需要实现什么功能”
- 软件设计–>“怎么实现”(核心地位，保证质量的关键步骤)
-
软件设计原则（重要原则：模块化）
-
模块化：把软件按照规定的规则，划分为一个个较小的，相互独立的但有相互关联的部件。
-
为什么要模块化？
- 模块化是为了使一个复杂的大型程序能被人的智力所管理
- 如果一个大型程序仅由一个模块组成，它将很难被人所理解
-
模块化的过程注意点：
- **模块的规模要适中。**如果规模过小，会增大模块之间相互调用的复杂度，同时也增大了花费在模块调用上的开销。如果规模过大，那么模块内部的复杂度会大，增大日后测试和维护的工作难度。
- 提高模块的独立性，降低模块间的耦合程度。独立性是指软件系统中的每个模块只完成特定的单一功能，而与其他模块没有太多联系。提高模块的独立性有助于系统维护以及软件复用。
- 提高模块的内聚程度。内聚是指模块内部的各个元素之间彼此结合的紧密程度。模块的高内聚通常意味着低耦合。
- 加强模块的保护性。保护性是指当一个模块内部出现异常时，它的负面影响应该尽量局限在模块内部，从而保护其他模块不受影响，降低错误的影响范围。
耦合
| 低强度耦合 | 描述 |
|---|---|
| 无直接耦合 | 调用模块和被调用模块不存在直接的数据联系 |
| 数据耦合 | 存在数据联系，简单变量的数据传递 |
| 标记耦合 | 存在数据联系，数组、结构、对象等复杂数据结构的数据传递 |
| 中强度耦合 | 描述 |
|---|---|
| 控制耦合 | 模块之间的联系不是数据，而是控制信息 |
| 较强耦合 | 描述 |
|---|---|
| 外部耦合 | 系统允许多个模块同时访问同一个全局变量 |
| 公共耦合 | 允许多个模块同时访问全局性的数据结构 |
| 高强度耦合 | 描述 |
|---|---|
| 内容耦合 | 允许一个模块直接调用另一个模块中的数据 |
在软件设计时，开发人应该尽量使用数据耦合，较少使用控制耦合，限制公共耦合的使用范围，同时坚决避免使用内容耦合。
内聚
| 低内聚 | 描述 |
|---|---|
| 偶然内聚 | 模块各元素之间无实质的联系，而只是偶然的组合在一起 |
| 逻辑内聚 | 模块内部各组成成分的处理动作在逻辑上相似，但功能却彼此不同 |
| 时间内聚 | 将若干在同一时间段内进行的彼此不相关的工作集中在一个模块中 |
| 中内聚 | 描述 |
|---|---|
| 过程内聚 | 模块内部各个成分按照确定的顺序进行无相关联系的工作 |
| 通信内聚 | 模块内部各个成分的输入数据和输出数据都相同 |
| 高内聚 | 描述 |
|---|---|
| 顺序内聚 | 模块内各个组成部分顺序执行，前一个成分的输出就是后一个成分的输入 |
| 功能内聚 | 模块内各个组成部分都为完成同一个功能而存在，在这里强调完成并且只完成单一的功能。 |
结构化设计与结构化分析的关系
结构化设计方法
- 表示软件结构的图形工具：层次图、HIPO图、结构图
面向数据流的设计方法、面向数据结构的设计方法。
……
……
过程设计工具
描述程序处理过程的设计工具成为过程设计工具，分为图形，表格、语言3类。
| 图形工具 | 表格工具 | 语言工具 |
|---|---|---|
| 程序流程图 | 判定树 | 过程设计语言 |
| N-S 盒图 | 判定表 | |
| PAD 图 |
流程图
流程图是对过程、算法、流程的一种图形表示，它对某个问题定义、分析或解法进行描述，用定义完善的符号来表示操作、数据、流向等概念。
N-S图（盒图）
N-S图，是一种符合结构化程序设计原则的图形工具，用类似盒子的矩形以及矩形之间的嵌套来表示语句或语句序列。用N-S图表示算法的优点是思路清晰，结构良好，设计容易，因此可以有效的提高程序设计的质量和效率。
PAD 图
PAD图也叫问题分析图，基于结构化程序设计思想，用二维树形结构的图来表示程序控制及逻辑结构。
判定表
在某些数据处理中，某个数据处理的执行可能需要依赖于多个逻辑条件的取值，此时可用判定表。判定表能够清晰的表示复杂的条件组合与应做的动作之间的对应关系。
判定树
判定树是判定表的变种，其优于判定表的一点是，它的形式简单到不要任何说明，一眼就可以看出其含义，因此易于使用和掌握。
过程设计语言（PDL）
过程设计语言也成程序描述语言，也成伪代码，它是一种用于描述模块算法设计和处理细节的语言。
第六章 面向对象的开发方法
面向对象方法
面向对象基本概念
结构化VS面向对象
- 结构化：自顶向下，逐步细分
- 面向对象：以对象为基础，以消息（或事件）来驱动对象执行处理
面向对象技术是一系列指导软件构造的原则，并通过语言、数据库和其他工具来支持这些原则
面向对象技术=类+对象+抽象+封装+继承+多态+消息……
符合人类思维习惯
UML(统一建模语言)
- UML三友：OOSE、Booch、OMT
静态建模机制
用例图
类图
对象图
动态建模机制
顺序图
状态图
活动图
描述物理架构机制
构件图
部署图
第七章 软件测试
软件测试概述
-
测试分类：单元测试、集成测试、系统测试、验收测试、回归测试
-
单元测试：是对软件基本组成单元进行的测试，其测试对象是软件设计的最小单位（即方法）。单元测试一般由编写该单元代码的开发人员执行，用于检测被测代码的功能是否正确。单元测试通常采用白盒测试（把测试对象看做一个透明盒子，允许测试人员利用程序内部的逻辑结构进行测试）
-
集成测试：将所有模块按照总体设计要求组装成为子系统或系统进行的测试。集成测试通常由测试人员来完成，一般采用黑盒测试(又称功能测试，它将测试对象看做一个黑盒子，完全不考虑程序内部的逻辑结构和内部结构，只依据程序的需求规格说明书，检查程序的功能是否符合它的功能说明)
-
系统测试：对整个系统的测试，将硬件、软件、操作人员看做一个整体，在实际运行环境或模拟实际运行环境下，检验他是否有不符合系统说明书的地方。
-
验收测试：是在软件产品完成了功能测试和系统测试之后，产品发布之前所进行的软件测试活动，其目的是验证软件的功能和性能是否能够满足用户所期望的要求。
-
回归测试：指修改了旧代码后，重新进行测试以确认修改没有引入新的错误或者导致其他代码产生错误。自动回归测试将大幅度降低系统测试、维护升级等阶段的成本。回归测试的策略有两种，一种是完全回归，一种是部分回归。
白盒测试
逻辑覆盖
- 语句覆盖：程序中每个可执行语句至少被执行一次。语句覆盖是最弱的逻辑覆盖准则。
- 判定覆盖（分支覆盖）：程序中每个判定的取真分支和取假分支至少经历一次，即判断真假值均被满足。判定覆盖具有比语句覆盖更强的测试能力，但仍是弱的逻辑覆盖。
- 条件覆盖：每个条件的可能取值至少满足一次。条件覆盖只能保证每个条件至少有一次为真，而不考虑整个结果。
- 判定-条件覆盖：判定条件覆盖能够同时满足判定、条件两种覆盖标准。
- 条件组合覆盖：判断中每个条件的所有可能取值组合至少执行一次，并且每个判断本身的结果也至少执行一次。
流图
黑盒测试
- 黑盒测试主要测试功能。通常由独立测试人员根据用户需求文档来进行。
等价类划分法设计测试用例
边界值法设计测试用例实例
17万+
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
