软件工程课程知识点学习框架总结

交换有价值的信息获得对方的理解和支持

向一个进度延迟的软件项目中增加人员可能会使其进度更加推迟

谈话、讨论、演讲、汇报、谈判、会议

肢体语言：面部表情、手势、眼神、姿态、仪表观察他人的肢体语言获得他人的信息，同时也要注意管理自己的肢体语言！！！

合同、报告、会议纪要、报表、备忘录、便条

电话、Email、BBS、Blog、即时通讯、协作工具

沟通需求:• 职责、协调、状态、授权 • 任务分配清晰工作会议:• 项目启动会、成员进度汇报、项目进展会 • 设置沟通期望• 及时、公开、恰到好处

• 和谁进行沟通?为什么? • 需要什么类型的信息?• 详尽程度和频率如何?• 沟通的目标是什么?• 采用何种方式沟通比较好?

• 目标- 项目概况:范围与目标、总体进度、方法和程序 - 确定项目人员的角色和任务- 确立团队的工作模式• 形式- 重大项目:精心准备、集中1-2 天;前期介绍与建立基本规则- 一般项目:简单有效;回顾项目范围与成员互相自我介绍• 建立基本规则- 计划决策、追踪决策、管理变动决策、关系决策

• 制定当前阶段的项目计划• 将工作任务明确分配给项目成员

• 向项目干系人和高层管理者汇报项目进展 • 解决需要高层管理者支持的问题

• 通报项目组成员的工作进展• 了解成员在工作中遇到的困难，并寻找资源解决 • 确定后续的工作计划

缺少亲切感

不经常交流

反馈比较慢

• 尽可能保证清楚地表达• 保持经常不断地交流• 保持立刻反馈和文件共享关键：交流、交流、再交流

有经验的工程师重用已有的设计• 模型组件重用 • 模型结构重用有智慧的工程师规划未来• 建立可重用的模型组件 • 建立易于修改的模型结构

抽象:关注重点，暂忘细节

分解:将问题切分，分而治之

多视角映射:切换关注点，分别讨论

模块化:建立稳定结构、缩小变化影响范围

模式:多次成功应用的模型结构

类对象通常对应一个命名实体，因此，用名词表达，于是我们先从名词开始 切记:别想一步到位

对象几乎无处不在

软件实体在扩展性应该是开放的， 在更改性应该是封闭的。

依赖倒置原则指的是依赖关系应该是尽量依赖接口(或抽象类)，而不是依赖于具体类。

在设计时采用多个和特定客户类(client)有关的接口要比采用一个通用的接口要好。

分支主题

• 如何将复杂的软件系统划分成模块• 如何规范模块的构成• 如何将这些模块组织成为完整的系统 • 如何保证系统的质量要求

构件

连接

连接件

• 体系结构的呈现形式是一个设计规约，而框架则是“半成品”的软件; • 体系结构的目的是指导软件系统的开发，而框架的目的是设计复用。

应将单元接口设计得尽可能简单，并将单元对于环境的假设和要求降至最低。

高内聚、低耦合

层次结构

事件风格

软件不能独立存在，需要依附于一定的环境(如硬件、网络以及其他软件)软件必须遵从人为的惯例并适应已有的技术和系统软件需要随接口变化而变化

人们总是认为软件是容易修改的，但忽视了修改所带来的副作用不断的修改可能导致软件的退化，从而结束其生命周期

软件是一种“看不见、摸不着”的逻辑实体，不具有空间的形体特征开发人员可以直接看到程序代码，但是源代码并不是软件本身软件是以机器代码的形式运行，但是开发人员无法看到源代码是如何执行的

• 交付的许多功能不是客户需要的 • 交付的日期没有保障• 客户使用时发现许多Bug

• 客户需求变化频繁，无力应对• 无法预见软件的交付质量• 对流程盲目遵从，忽视客户业务价值

• 开发团队专注技术，忽视风险（听意思是时间成本）• 无能力预测成本，导致预算超支

• 无法评估开发人员能力及工作进度 • 困扰于如何提升团队的能力与效率

史前时代

瀑布过程模型

质量标准体系

• 敏捷开发方法流行• 更紧密的团队协作• 有效应对需求变化• 快速交付高质量软件 • 迭代和增量开发过程

• 大规模的设计与建造 • 复杂问题与目标分解 • 团队协作与过程控制

• 较低的开发成本 • 按时完成开发任务并及时交付 • 实现客户要求的功能 • 具有良好性能、可靠性、可扩展性、可移植性等 • 软件维护费用低

支持软件开发各个环节的控制和管理

流程

完成软件开发任务的技术手段

发展过程

为软件开发方法提供自动的或半自动的软件支撑环境

按流程分

• 构造一个新的系统不必从零做起，直接复用已有的构件进行组装 • 构件是经过反复使用验证的，由其组成的新系统具有较高的质量

软件复用是利用将已有的软件制品，直接组装或者合理修改形成新的软件系统，从而lt;font color=quot;#0076b3quot;gt;提高开发效率和产品质量，降低维护成本。

软件复用不仅仅是代码复用

• 将一个复杂的问题分解成若干个简单的问题，然后逐个解决 • 来源于人们生活与工作的经验，完全适合于技术领域

软件工程是一项解决问题的工程活动，通过对问题进行研究分析，将一个复杂问题 解成可以理解并能够处理的若干小问题，然后再逐个解决。

• 软件开发是自底向上逐步有序的生长过程• 小步快跑:每走完一步再调整并为下一步确定方向，直到终点

lt;font color=quot;#0076b3quot;gt; 软件更像一个活着的植物，其生长是一个逐步有序的过程。软件开发应该遵循软件的客观规律，不断进行迭代式增量开发，最终交付符合客户价值的产品。

• 优化:优化软件的各个质量特性，如运行速度、资源利用、用户体验 • 折中:通过协调各个质量特性，实现整体质量的最优

lt;font color=quot;#0076b3quot;gt; 软件工程师应当把优化当成一种责任，不断改进和提升软件质量;但是优化是一个多目标的最优决策，在不可能使所有目标都得到优化时，需要进行折中实现整体最优。

抽象

软件建模方法

用户界面原型化

软件体系结构

软件过程

软件复用

度量

工具与集成环境

用户

开发人员

投资者

软件过程

软件产品

产品效用

正确的软件

软件运行正确

• 做了用户想要它做的事情• 正确有效地使用计算机资源• 易于用户学习和使用• 设计良好、代码良好且易于测试和维护

性能

产品特色

可靠性

符合性

耐久性

可服务性

审美

感知

功能性

可靠性

易用性

效率/性能

可维护性

可移植性

客户需求

分析

客户满意的产品

高质量的设计（设计阶段）

规范的编码（实现阶段）

有效的测试（测试阶段）

• 商业目标决定质量目标，不应该把质量目标凌驾于商业目标之上 • 质量是有成本的，不可能为了追求完美的质量而不惜一切代价• 理想的质量目标不是“零缺陷”，而是恰好让广大用户满意

编写代码

• 软件全生命周期的 70% 成本是维护• 软件在其生命周期中很少由原编写人员进行维护

• 提高编码质量，避免不必要的程序错误• 增强程序代码的可读性、可重用性和可移植性

https://github.com/google/styleguide

只编写够用的注释，过犹不及，重视质量而不是数量

• 好的注释解释为什么，而不是怎么样 • 当修改代码时，维护代码周围的所有注释

编写自文档化的代码

模块化设计

面向抽象编程

错误与异常处理

• 检查设计的合理性• 互为 Backup(后备人员)• 分享知识、设计、技术• 增加代码可读性• 处理代码中的“地雷区

按照具体编程语言的编码规范进行检查，包括命名规则、程序注释、缩进排版、声明与初始化、语句格式等

• 类的设计和抽象是否合适• 是否符合面向接口编程的思想 • 是否使用合适的设计模式

• 在出现海量数据时，队列、表、文件在传输、上载等方面是否会出 现问题，是否控制如分配的内存块大小、队列长度等• 对 Hashtable、Vector 等集合类数据结构的选择和设置是否合适• 有无滥用 String 对象的现象• 是否采用通用的线程池、对象池等高速缓存技术以提高性能• 类的接口是否定义良好，如参数类型等应避免内部转换• 是否采用内存或硬盘缓冲机制以提高效率?• 并发访问时的应对策略• I/O 方面是否使用了合适的类或采用良好的方法以提高性能(如减少序列化、使用 buffer 类封装流等)• 同步方法的使用是否得当，是否过度使用?• 递归方法中的迭代次数是否合适(应保证在合理的栈空间范围内)• 如果调用了阻塞方法，是否考虑了保证性能的措施• 避免过度优化，对性能要求高的代码是否使用profile工具

• 分配的内存是否释放，尤其在错误处理路径上(如 C/C++)• 错误发生时是否所有对象被释放，如数据库连接、Socket、文件等 • 是否同一个对象被释放多次(如 C/C++)• 代码是否保存准确的对象引用计数

• 循环结束条件是否准确• 是否避免了死循环的产生• 对循环的处理是否合适，应考虑到性能方面的影响

• 代码中所有的全局变量是否是线程安全的• 需要被多个线程访问的对象是否线程安全，检查有无通过同步方法保护• 同步对象上的锁是否按相同的顺序获得和释放以避免死锁，注意错误处理代码• 是否存在可能的死锁或是竞争，当用到多个锁时，避免出现类似情况:线程A获得锁1，然后锁2，线程B获得锁2，然后锁1• 在保证线程安全的同时，注意避免过度使用同步，导致性能降低

• 数据库设计或SQL语句是否便于移植(注意与性能会存在冲突) • 数据库资源是否正常关闭和释放• 数据库访问模块是否正确封装，便于管理和提高性能 • 是否采用合适的事务隔离级别• 是否采用存储过程以提高性能• 是否采用 PreparedStatement 以提高性能

• Socket 通讯是否存在长期阻塞问题 • 发送接收的数据流是否采用缓冲机制 • Socket 超时处理和异常处理• 数据传输的流量控制问题

• 每次当方法返回时是否正确处理了异常，如最简单的处理是记录日 志到日志文件中• 是否对数据的值和范围是否合法进行校验，包括使用断言• 在出错路径上是否所有的资源和内存都已经释放• 所有抛出的异常是否都得到正确的处理，特别是对子方法抛出的异 常，在整个调用栈中必须能够被捕捉并处理• 当调用导致错误发生时，方法的调用者应该得到一个通知• 不要忘了对错误处理部分的代码进行测试，很多代码在正常情况下 执行良好，而一旦出错整个系统就崩溃了?

• 方法的参数是否都做了校验• 数组类结构是否做了边界校验• 变量在使用前是否做了初始化• 返回堆对象的引用，不要返回栈对象的引用• 方法的 API 是否被良好定义，即是否尽量面向接口编程，以便于维护和重构

• 对命令行执行的代码，需要详细检查命令行参数 • WEB 类程序检查是否对访问参数进行合法性验证 • 重要信息的保存是否选用合适的加密算法• 通讯时考虑是否选用安全的通讯方式

• 日志是否正常输出和控制• 配置信息如何获得，是否有硬编码

证明需要进行优化

性能分析工具能够有效地描述程序运行的性能状况，提供各种统计数据帮助程序员找出程序中的性能瓶颈

验证代码

设计更好

文档化行为

具有回归性

对通过所有被测模块的数据流进行测试

检查模块中的数据结构是否正确的定义和使用

检查数据流或控制流中条件或数据处于边界时的出错可能性

检查由于计算错误、判定错误、 控制流错误导致的程序错误

检查可能引发错误处理的路径 以及进行错误处理的路径

单元测试应能快速运行，如果运行缓慢，就不会愿意频繁运行它

单元测试应相互独立，某个测试不应为下一个测试设定条件。当测试相互依赖时，一个没通过就会导致一连串的失败，难以定位问题。

单元测试应该是可以重复执行的，并且结果是可以重现的

单元测试应该有布尔输出，无论是通过或失败，不应该查看日志文件或手工对比不同的文本文件来确认测试是否通过

及时编写单元测试代码，应恰好在开发实际的单元代码之前

测试通过率是指在测试过程中执行通过的测试用例所占比例， 单元测试通常要求测试用例通过率达到100%

测试覆盖率是用来度量测试完整性的一个手段，通过覆盖率数据，可以了解测试是否充分以及弱点在哪里。代码覆盖率是单元测试的一个衡量标准，但也不能一味地去追求覆盖率。

代码覆盖率（达到70%-80%就可以了，过高覆盖率可能会造成测试成本大大增加）

通过人工分析或程序正确性证明？？的方式来确认程序正确性

通过动态分析？？和程序测试等方法来检查和确认程序是否有问题

将测试对象看做一个黑盒子， 完全不考虑程序内部的逻辑结构和内部特性，只依据程序的需求规格说明书，检查程序的功能是否符合它的功能说明

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

驱动模块

测试用例

桩模块1桩模块2...桩模块N

适用于以下场景的测试

lt;font color=quot;#c41230quot;gt;无法适用于复杂场景的测试，但这些场景才是重点和难点

需要应用针对接口的编程技术，即被测试的代码通过接口来引用对象， 再使用Mock对象模拟所引用的对象及其行为，因此被测试模块并不知道它所引用的究竟是真实对象还是Mock对象

降低软件测试成本保证测试工作质量评估和检验测试效果

是对规格说明有意义、合理的输入数据构成的集合，能够检验程序是否实现了规格说明中预先规定的功能和性能

是对规格说明无意义、不合理的输入数据构成的集合，以检查程序是否具有一定的容错性

min、min+、nom？？、max- 和 max

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

控制流图(CFG， Control Flow Graph)是一个过程或程序的抽象表示。 控制流图的基本符号:• 矩形代表了连续的顺序计算，也称基本块• 节点是语句或语句的一部分，边表示语句的控制流

最弱的逻辑覆盖准则

具有比语句覆盖更强的测试能力，但仍是弱的逻辑覆盖

条件覆盖只能保证每个条件至少有一次为真，而没有考虑整个判定结果

没有考虑条件的各种组合情况

覆盖了所有组合，但覆盖路径有限

覆盖程序中的所有可能的执行路径

可能没有覆盖所有条件组合

• 覆盖率数据只能代表测试过哪些代码，不能代表是否测试好这些代码。• 较低的测试覆盖率能说明所做的测试还不够，但反之不成立。• 路径覆盖 gt; 判定覆盖 gt; 语句覆盖• 测试人员不能盲目追求代码覆盖率，而应该想办法设计更好的测试用例。• 测试覆盖率应达到多少需要考虑软件的整体要求以及测试成本。

绘制控制流图

计算环路复杂度

确定基本路径

设计测试用例

检查循环结构的有效性

简单循环(次数为 n)

嵌套循环

串接循环

人们通过开展技术探索和市场调查等活动，研究系统的可行性和可能的解决方案，确定待开发系统的总体目标和范围

分支主题

在可行性研究之后，分析、整理和提炼所收集到的用户需求，建立完整的需求分析模型，编写软件需求规格说明

分支主题

• 分析模型 • 软件需求规格说明

根据需求规格说明，确定软件体系结构，进一步设计每个系统部件的实现算法、数据结构及其接口等

分支主题

• 设计模型 • 软件体系结构文档 • 软件详细设计文档

概括地说是将软件设计转换成程序代码，这是一个复杂而迭代的过程，要求根据设计模型进行程序设计以及正确而高效地编写和测试代码

分支主题

• 源程序 • 目标代码 • 可执行构件

检查和验证所开发的系统是否符合客户期望，主要包括单元测试、子系统测试、集成测试和验收测试等活动

分支主题

• 测试规程 • 测试用例 • 测试报告

系统投入使用后对其进行改进，以适应不断变化的需求。完全从头开发的系统很少，将软件系统的开发和维护看成是一个连续过程更有意义。

软件项目管理

软件配置管理