软件工程自学
emmm我们专业不学习软件工程，自学一点，权当休闲。
1.概述
应对不断变化的需求
开发占比比测试和维护小得多。
1.2 软件开发的三个阶段
私人化的软件环境中，软件的水平与个人的关系很大。
专家系统：提供专业知识与服务
网格计算：云计算
软件开发的初期，一定要先花时间把需求搞清楚
可读性、可理解性越好，可维护性越好
软件开发追求一致性和标准性
技术先进，需求不清楚是中国的现状。没有技术解决不了的，但是主要问题是把需求提清楚
好的需求本身就是一种资源
维护对一个公司的信誉很重要，要考虑到开发公司的流动性
维护费：技术支持（电话、邮件）、上门解决，这是一个长期的盈利（对客户就是花费）
软件的维护是一件很困难的问题。
软件！=程序，软件是由一个完整的配置组成的，还包括文档和数据。
在软件开发的不同阶段进行修改，需要付出的代价是很不相同的。
一旦发生错误应该马上修改
开发费与维护费是两回事。签合同的时候要说好
1.3 软件工程概述
好的项目管理要尽量准时。
一种策略：快速迭代、抢占市场、尽早上架
开发目的的折中、最优化
易于维护的软件，可靠性一般也比较高
可靠性和性能是互斥的，一个是求稳，一个是性能导向的
软件工程的原则：
例如类，就是对一组有共同特性的对象的抽象
局部化：资源的声明、使用和释放应该放在同一个模块中并且应该尽量靠近
一致性：要培训员工使用公司统一的命名、结构等规范
要使程序易于测试和检查。例如，内存泄露，memory leak，是一种比较难以测试的bug，可能需要长时间的运行才会出现（例如占用了资源没有释放，每次可能只是几k，但是长时间就会造成大范围的内存占用），并且难以排查究竟是哪一段出了问题、没有释放。
软件工程主要是用于大型工程的。
一个模块多大才合适？有一个简单的度量方法，就是一个模块大概就是一张A4纸那么大的内容。当分到类似这样大小的话就没必要再细分模块了。
这一点很重要！要区分我们获取到的工作流程是“真正”的流程，还是停留在规则上的流程，要获取用户真实的工作流程，而不是这个行业的标准、规范上的的工作流程。
软件的开发至今尚未完全摆脱手工的开发模式
甚大型的差不多是操作系统规模的
极大型的，例如弹道导弹系统
在公司我们开发的基本都是中型的项目。
1.4 软件需求说明书
软件需求说明书模板：https://wenku.baidu.com/view/622dced0195f312b3169a532.html
编写软件需求说明书，一般要给两种角色的人看，一种是客户，一种是开发人员。
对于客户： 重点在于清楚的表达客户提出的需求，你是如何理解的，让客户看了你的文档后确认你的表达和描叙是符合它的需求的。为了更形象的表达，请做一些界面原型来表达，这样客户才能真正与你形成互动，使针对客户的软件需求说明书有意义（最好是先做系统原型，直接拿原型与客户交流，客户的需求你就能全面把握了）。
对于开发人员： 重点告诉他们系统需要具有哪些功能，有哪些对象，对象有哪些属性，对象之间有哪些关系，最好能采用UML来表达
例如设计一个数据库，也有数据库的设计说明书，比如用ER图来说明结构等等。
1.5 软件工程的基本原理
“不同层次的管理人员都必须严格按照计划各尽其责地管理软件开发与维护工作，决不能受客户或上级人员的影响而擅自背离预定计划”，很理想化的设定2333
软件开发的步骤：
定义—》可行性分析-》需求分析-》设计-》编程-》测试-》运行-》维护
大多数的错误是在编程之前产生的，设计错误占很大一部分，不要只关注编程错误，例如有的设计根本实现不了。
系统设计没有对错，只有合理还是不合理
一切有关修改软件的建议，特别是涉及到对基准配置的修改建议，都必须按照严格的规程进行评审，获得批准以后才能实施修改，绝对不能谁想修改软件就修改。可以理解为，基准配置是“红线”
开发小组的成员最好是小而精
1.6 软件工程方法
软件工程：技术+管理
传统方法学：面向数据流，结构化的，例如数据流图
面向对象方法学
两种程序设计方法
对象本身就是对数据结构和算法的封装
非结构化程序设计：例如汇编语言中的goto语句，任意跳转，使得程序缺少明确、清晰的结构，没有采用结构化程序设计中常见的分支、循环等逻辑结构，逻辑比较混乱
面向对象程序设计的一个典型例子：神经网络模型的实现？这个当时做的时候比较明显，将节点当成对象确实比结构化的设计更方便理解，出错也少。
软件开发阶段：
传统软件工程各个部分之间，界限非常清楚，每个部分的任务、成果都很清楚。而面向对象软件工程没有清晰的界限，是一个渐进的、细化的、迭代的过程，得到的成果都基本上是同一类的内容，但是越来越深刻：首先明确哪些是对象（对象抽取），再进行对象详细设计，再对对象进行编程和测试。
1.7 软件生存周期
问题定义—》可行性分析-》需求分析-》设计-》编程-》测试-》运行-》维护
问题定义：
可行性分析：
行得通不单单是指技术上，也包括经济上、操作上是不是行得通
开发：需求分析，明确功能，得到性能，最终得到逻辑模型。
数据流程图和数据字典
DFD：数据流图
SRS：软件需求规格说明书，是需求分析的主要成果
整体设计：
把SRS转换为物理模型
SC图：系统结构图、系统图，反映系统内有哪些模块以及模块间的调用关系，体现了要开发的体系结构。
最上面是主控模块，第二层分别是输入处理、数据加工、输出处理模块，第三层是对这些任务的细分。输入模块处理完后给主控模块，然后主控给加工，加工处理完给主控，主控给输出。
详细设计：
详细设计每一个模块，确定模块所需要的算法和数据结构。
外包就是用详细设计完的说明书进行编程，产出就是编程结果，其实就是一种由自然语言到编程语言的翻译，不能掌握产品全局的设计和概念，技术含量比较低。
编码与单元测试：
模块级别的测试就叫单元测试。但是程序员的测试和测试员的测试是不一样的，测试员可能只测正常情况、正常输入，而测试员要测量各种情况下模块的响应。
测试要有严格的测试计划，要有测试用例的分析和设计，要有测试结果的报告
单元测试只能保证模块正确
综合测试：
集成测试就是将模块组装好了之后进行测试
验收测试：正确、没有bug的系统，不代表就是用户想要的系统，和用户约定的功能上也不能有偏差
现场测试：实地运行（强度测试，高并发；恢复测试，意外情况下恢复）
除了技术，维护对人员的语言能力、产品细节的熟悉程度都有很高的要求
1.8 软件开发模型-瀑布模型
软件开发模型
瀑布模型是串行顺序执行的，中间没有回头。是最原始的瀑布模型。
瀑布模型的特点：
瀑布模型首次提出了推迟实现的概念，尽可能推迟编程和测试的时间，分析设计之后才能写代码。
瀑布模型强调质量的保证和文档。每个阶段要处理每个阶段的文档。
瀑布模型是文档驱动的，而螺旋模型是风险驱动的。
1.9 软件开发模型-快速原型模型
开发原型后进行用户反馈，再根据用户反馈修改需求分析和原型，直到用户满意为止。原型是具有了初步系统框架、系统界面，可以操作、少数功能可以使用的软件。直接先交给用户使用，使用户有直观感受，可以很好地获取用户的反馈。用户反馈后，我们马上修改软件设计说明书。
适合于中小型软件和需求模糊的情况。
原型开发一定要快，不能花太大精力去开发
用户认可之后，如果原型比较合理，就可以在原型的基础上继续开发；如果原型开发过于仓促、结构不够合理，就可以直接抛弃
1.10-软件开发模型-增量模型
增量构件就是一个小而可用的软件。将模型分解为一个一个增量进行设计、交付给客户。增量之间要考虑如何良好集成。
每次交付都是一个可用的组件。
增量模型继承是难点：构建化
1.11-软件开发模型-螺旋模型
螺旋模型是风险驱动的，中心思想就是降低风险
螺旋模型的本质是一种快速原型模型
沿着线一圈一圈向外走，从内向外，每一个环节都对风险进行预测。
螺旋模型的特殊就是风险分析
1.12-软件开发模型-构件集成模型
是一种面向对象的模型，软件开发全部构件化，如果构件库有现成构件，就不要再造轮子了，没有的话再编程。实现了软件的高度可重用。
构件应该是经过良好实现了的，具备健壮性且速度快，接口也要良好定义。
2.可行性研究及初步需求分析
2.1 可行性研究
重点：数据流图和数据字典
数据流图和数据字典就构成了需求分析的主要内容
可行性研究的目的不是解决问题，而是确定问题是否值得被解决
其实技术可行性一般不是问题，主要考虑其他方面
经济可行性：可能提出多套方案，成本不一样，供用户选择，我们当然可能也会推荐一套。分析的是成本，但落脚点是效益（可以适当宣传一下效益2333）
操作可行性：企业现有的硬件条件、网络条件等等能否达到要求
有时候经济效益不明显，但是有社会效益，可能也会做，例如政府部门的开发。
可行性研究的结果：
可行性研究的过程：
研究现有系统，获得文档资料
如果新系统相比正在运行的旧系统不能增加收入或者减少使用费用，那么从经济角度来看新系统就不如旧系统
成本/效益分析是重点
软件开发可行性研究报告样例：https://blog.csdn.net/yyp0304Devin/article/details/83315652
2.2 系统流程图
系统流程图不是对数据进行加工处理的控制过程（数据流图），而只是表示数据的流动情况。
一个例子：
2.3 数据流图(DFD)
对输入数据的加工、变换
顶级（0级）数据流图：
描述了目标系统和外部实体之间的数据联系
顶级数据流图将整个系统高度抽象为一个目标系统
数据源/数据终点
箭头：数据流
目标系统：加工、处理、变换
数据流图中的基本符号：
举例：
先构建顶级数据流图：
由概况到细致，先画顶级图有利于减小之后的分析难度
事务也是数据之一
在顶级图的基础上分解，是一级图
数据储存的D1D2表示数据名称，同样的，我们对数据的处理也进行了命名
注意P1和D1之间是双向的数据流，P1到D1是修改库存量；D1到P1是查询库存量以便于生成订货信息
P-》D：数据的添加、修改和删除
D->P：数据的查询（D将查询的结果反馈給P）
对于1级DFD，我们还可以再细化：
二级DFD
传递的“事务”也可以理解为“指令”的意思
分层数据流图的示意图：
画数据图的基本步骤：
以输入输出的方式确定0级图
按流程分开各个加工部分，确定1级图
对1级图不断进行细化，确定之后的图
命名：
一般命名用名词和名词短语
对数据原点和终点的命名应该采用用户行业的术语
DFD+DD构成系统的完整逻辑模型
例如上图，我们可以将更新库存清单这一步也可以变成批处理而不是实时的，对于事务先保存下来，之后批量完成
当然也可以这么画，就是和之前说的比较接近了
系统的设计没有对错，只有哪个更好
面向数据流的设计：
DFD例2：
顶级DFD：
1级DFD：
例3：
如何分析并绘制DFD？
0级DFD：
1级图：
注意事项：
可以出现不属于上一层数据存储环节子项的新的数据存储环节
数据流必须经过加工
2.4 数据字典
数据字典的详细介绍：https://blog.csdn.net/u012881904/article/details/51469366
https://img-blog.csdn.net/20160521104950491
数据之前有助于消除开发人员和用户之间交流时出现的误解，做到有效交流
数据字典是开发数据库的第一步
2.5 成本估计
- 代码行估计
根据公司以往项目结果作为依据估算，公司每天平均产出的代码行是类似的。
- 任务分解技术
小任务的估计较为准确和简单
- 自动估计成本技术
ML可以！
估算软件生命周期为5年，由此计算效益
由此，我们需要计算未来收入的在现在的收益与成本，这就要考虑货币的时间价值：
计算纯收益要将未来的收入折合为现在的值
与年利率相比，起码要证明我们的工程收益率要高于直接把钱存银行2333
3. 软件需求分析
软件需求说明书也是软件方，而不是用户，完成的
数据模型：ER图，就是数据库的那个
功能模型：数据流图
行为模型：状态转换图，在面向对象部分讲解
自顶向下，逐层分解
绘图要用专业的绘图工具
例如在毕业设计中，如果要开发一个系统，就要对系统进行专业的需求分析，所以软件工程还是有意义的呀～
虚线里面的就是需求分析的内容
访谈的准备很重要，要尽量先收集掌握客户的业务信息，要提前准备问题，也可以准备调查表来获得用户的反馈和期望
实际观察用户的工作流程
分析员是用户和开发人员的桥梁
软件计划由用户和分析人员制定
软件需求说明书三方都要参加
原型是分析人员和软件开发小组完成
3.2分析建模
DFD、DD、PSPEC强调的是系统的功能
CFD、CSPEC、STD强调的是系统的行为
ER图是系统的数据模型
结构化分析模型的核心是数据字典
面向对象分析模型：
复习一下ER图吧：
E-R图的数量关系可以用不同的符号表示
例如：
- 数据规范化
这里就是数据库设计的内容
范式级别提高导致数据的存储结构和问题域的结构之间不匹配，使得需求变化时，可能会涉及到多张表同时的修改，稳定性下降
加工说明：
实例：
CFD（控制流图）：在数据流图的基础上添加了控制流
控制：物品经过、时钟、人工驱动
反馈了数据传输过程中受到控制的情况
状态转换图：
一张图只能有一个初态，终态可以有0到多个
终态比起始点多个圈
用例图：
例子：
角色是和系统进行交互、使用系统功能的人。
用例之间的关系：
扩展：在签保险单的用例上拓展一些其他的功能，从而实现其他的用例
使用：纯粹使用另外一个用例的功能
对象关系图：
对象-行为图
对象状态转换图描述的是一个对象，而顺序图和合作图描述的是多个对象
对象状态转换图描述的是一个对象的不同的状态
顺序图描述多个对象按照一定的时间顺序进行协调工作的关系
合作图不再按照时间顺序进行画图，而是只表示对象之间的合作关系
3.3 软件需求说明
样本：https://wenku.baidu.com/view/622dced0195f312b3169a532.html
需求说明中有版本记录表格
3.3.1 验证软件需求
3.4 面向数据流的软件分析与设计
3.4.1 面向数据流的软件分析
系统分析的目标：
这里的分析模型主要就是DFD
调用软件使用公司的员工在信息的交互上都有哪些联系
工作量会影响到软件的结构和并发性
用户参与、先逻辑、自顶向下、标准化
3.4.1.1 结构化问题
确定性很高，条件很充分
半结构化问题：条件不很充分
非结构化问题：条件基本上不具备，解决问题很困难
基本加工：
只要不进一步细分就是基本加工，不一定是最底一级的。
PSPEC：说明基本加工
结构化语言：其实就是伪代码
例如：
决策树：
决策表：
用双线划分了一个田字型结构
盒图（N-S图）：
盒图可以表示一种嵌套关系。
3.4.2 面向数据流的软件设计
软件设计的意义：
从不同的角度看软件设计：
数据设计主要是数据库的设计，软件工程主要考虑系统结构设计和过程设计
软件设计的任务：
接口设计可以包括在体系结构设计中
这四部分和我们的软件工程技术的对应：
软件设计的基本概念：
3.4.3 体系结构设计
数据流图有两类：变换型和事务型图。
系统结构图
SC图中，永远是上层模块调用下层模块
SC图中的模块调用：
数据信息：模块间传递的参数
控制信息：一个模块传递一个可以控制另一个模块流程的信息
传入模块：将信息A由下级传入
传出模块：将上级输出的信息D向下传递
变换模块：将传入的B数据处理为C数据，见下图，也是核心模块
协调模块：主要用来做主控模块，起到一个协调和控制整个程序的作用
将变换DFD化为SC图
例如：
- 划分DFD
注意看上面数据的流动，主控模块，也就是上面我们讲的四种基本模块中的协调模块，本身不处理信息，而只是进行信息的传递，从输入给变换，从变换给输出。
再向下细分：
注意上面DtoE的输出错了，应该是e
最原始的输入是由readA和readD产生的，他们说输入模块，AtoB这类是处理模块，getB这类的是协调模块。Ma是输入模块
writeV是输出模块，Me也是输出模块，虽然它并不是像writeV一样直接进行输出的
最终：
相比DFD，SC图离编程更近了，用SC图可以直接编程、组装了
事务分析后的SC图：
类型标志：分析事务类型模块对事务的类型进行分析并用类型标志来描述，事务调度处理模块收到类型标志后选择正确的处理分支
体系结构优化设计的指导规则
简化接口
高性能要求时的工作
孤立出需要大量占用CPU的模块
3.5 模块化设计
所以说分治是有意义的
但是，模块分解的越多，接口越复杂，接口越多
所以，最后是模块成本和接口成本的协调
模块的深度和宽度
瓮形是最佳的SC结构，上面不断分解，下面实现了软件的重用
这种煎饼形的结构不可取，顶层的扇出太高，应该深度加大，变成多层的塔型结构
专业名称，模块的扇入和扇出
模块的作用范围和控制范围：
作用范围可能比控制范围大：如果修改了全局变量，影响会很广
优化原则：一个模块的作用范围应该在它的控制范围之内。如果有不属于控制范围的模块，就将它划分到这个模块的下属模块中
模块独立性
3.5.1 内聚
模块内部越紧密越好，功能越单元越好
- 偶然性内聚
这种模块的独立性和聚合性都最差
- 逻辑性内聚
逻辑上比较像，但是功能上不一致
- 时间性内聚
他们功能不一样，只是时间要求一致
- 过程性内聚
这种就是比较好的内聚了
- 通信性内聚
- 顺序性内聚
这种就是很好的内聚了，相关性非常好，各个处理成分都和同一个功能相关
- 功能性内聚
这种就是我们追求的模块，功能单一
总结一下：
模块要做到自完备，要在内部进行参数检查，不要依赖上一级去做，这样的模块通用性是不强的
块内聚合形式的判定：
3.5.2 耦合
模块间耦合强、关系紧密不是好事，这说明了模块独立性很差，不利于重用
- 非直接耦合
- 数据耦合
信息仅限于数据
- 特征耦合
输入的不是简单参数，而是复杂的数据结构。输入的数据结构发生变换，会导致内部逻辑变化。传入的数据结构超过了该模块的需要，这种应该加一层，获取真正需要的数据之后再传入该模块。
- 控制耦合
这种就联系比较紧密了，模块内完成的任务也不单一。
控制耦合从原理上是可以避免的：将模块拆分
- 外部耦合
- 公共耦合
使用全局资源进行相互作用，情况很复杂，耦合较差。所以要尽量少用全局变量，就地声明、就地使用、就地释放。
- 内容耦合
内容耦合从高级计算机语言就已经杜绝了（例如杜绝goto）
基于块间耦合的设计原则：
3.6 过程设计
过程设计的原则：
过程设计的工具
- 程序流程图
- N-S图（盒图）
局部变量的声明周期可以很清楚的表现出来
盒图举例：
3.6.2 设计复审
3.7 面向对象软件设计
3.7.1 面向对象软件的开发过程
论域分析：
从更高的视角看问题，提升软件的重用性和通用性
应用分析：
三层结构：
界面类、业务类、公用类
在UML中用三个包图实现
公用类是最底层，它们的通用性比较强
设计好了后，编程实现，然后进行测试
尽可能局部化修改，不要对接口等有大的修改。
3.7.2 面向对象分析（OOA）
OOA、OOD、OOP的理解：https://lovojava.github.io/2017/06/19/20170619/
OOA的目的是定义所有与待解决问题相关的类，核心工作就是提取出类
经典OOA方法：
主要学UML
3.7.3 UML
UML不仅是面向对象软件开发的标准，也是信息系统分析与设计的标准，
建模是为了捕捉、描述系统的核心
可视化建模就是用标准的图示化方法来进行建模工作
UML的目标：
3.7.3.1 UML开发过程
3.7.3.2UML基本图示
3.7.3.3UML的规划分析操作过程
3.7.3.4类图
例如：
类图的类型
聚合关系下，整体类不存在，部分类依然存在；但是如果是构成，则部分随着整体一起消失
3.7.3.5实例图（用例图）
3.7.3.6对象图
对象图可以是对类图的补充和说明
对象之间的关系：
UML动态建模
3.7.3.7顺序图（时序图）
顺序图的特殊情况：循环、条件分支、并行、结束
3.7.3.8协作图
协作图最适合体现类之间的关系
顺序图可以自动生成协作图
3.7.3.9状态图
描述系统的动态行为
3.7.3.10包图
主要体现结构的划分
3.7.3.11活动图
3.7.3.12构件图（部件图）
3.7.3.13配置图（部署图）
3.7.4 面向对象设计（OOD）
OOA和OOD之间没有明显的界限，只是OOA分析的比较粗，OOD分析的比较细
经典的OOD方法
OOD的工作：
详细来说：
面向对象软件开发步骤：按UML标准，用可视化建模工具进行系统分析、设计和迭代开发
3.7.5RUP-UML统一建模过程
生命周期迭代法的三个重要特征
迭代可以提振团队的信心
迭代次数的选择
第一次迭代一般是最难的，要高度重视，第一次迭代一定要成功
团队在迭代开始前往往对困难预计不足
不要对第一次迭代提出过高的要求
4.软件编程的规范和标准
- 编程的质量
- 选择编程语言的标准
- 编程风格
在注释段与程序段、以及不同程序段之间插入空行
书写表达式时，适当使用空格或者圆括号等做隔离符号
5.软件测试
5.1 测试的基本概念
广义上，测试的对象不仅是编程，还有需求分析、设计说明
测试的特效：
测试要抱着为了证明程序有错的目的去测试
测试的种类：
测试文档：
测试的原则：
测试要尽早、不断
要避免只有程序员自己检查自己的程序
编写测试用例的时候一定要有不合理的测试
充分注意测试中的错误群集情况：规律上来说，80%的错误集中在20%的代码之中。某一部分代码如果检测出来Bug非常多，那么它的bug依然非常多的可能性是很大的，应该对这部分代码加强测试
测试信息流：
要对软件的可靠性进行统计分析
5.2 白盒测试
测试人员知道内部逻辑结构
白盒测试方法：
- 逻辑覆盖法
条件覆盖：一个判断里面可以有多个条件通过逻辑组合，条件覆盖要求对每一个条件都对真、假情况各执行一次。但是在这种情况下，判断整体的结果不一定true和false都取过了，所以这就是判定/条件覆盖所要求的
条件组合覆盖：比判定/条件覆盖要求更高，要求判定中所有的条件可能值的所有可能组合都执行一次
- 基本路径法
环路复杂性就是基本路径的条数
有多少条基本路径就要做多少个测试用例
计算环路复杂性：
举例：
流图的基本符号：
注意：
2,3可以合并，不影响环路复杂度的计算
特别注意，像9、10、11这种点，在程序流程图中都不画的，但是流图中必须作为节点处理
再举例：
5.3 黑盒测试
只根据需求的文字说明设计测试用例
- 等价分类法
合法取值叫有效等价类，非法取值叫无法等价类
例如：
- 边界值分析法
它是等价分类法的有效补充
强迫程序在边界值及其附近运行
5.4 多模块程序的测试策略
上面都只是针对一个模块进行的测试，对于多模块
多模块测试的四个阶段：
软件测试流程
确认测试：与需求进行对比，看看功能是否齐全
测试与开发的关系：
单元测试发现的问题主要来源于编程和详细设计阶段
集成测试主要发现详细设计和概要设计的错误
5.4.1 单元测试
单元测试的实施
编写驱动模块来取代结构中待测试模块的上层模块来测试待测试模块，其工作就是传递待测试模块需要的参数以及接收待测试模块返回的参数，驱动模块越精简越好
桩模块：
和驱动模块类似，但是是待测试模块的下层模块
一般地，模块的测试可能既需要桩模块，也需要驱动模块：
被测试模块的输出结果和驱动模块的预期结果比较，就得到了测试结果
5.4.2 综合测试（集成测试）
综合测试策略：
渐增式和非渐增式：将模块一个一个加进来，每加进来一次就测试一次，是渐增式；都加进来一起测试是非渐增式。渐增式比非渐增式要好
自顶向下可以较早发现软件高层体系结构的错误，而自底向上可以使得底层模块的测试非常充分。所以，往往采用混合的方式进行测试，在中间会合。
宽度优先和深度优先：
宽度优先先测试同一层的模块，深度优先先测试一支
宽度优先
深度优先
5.4.3 确认测试
beta测试：对用户分布的测试版本
alpha测试：软件工程内部的测试
确认测试的步骤：
5.4.4 系统测试
它包括：
恢复测试：系统宕机之后多长时间可以恢复
5.4.5 终止测试的标准
第二种硬性要求错误数量的方式对团队的水平和软件的规模要比较熟悉，这样才能比较准确的估计
第三种方法是比较科学的
5.4.6 调试
测试是发现错误，调试是定位和纠正错误
调试是程序员的工作
5.4.7 面向对象测试
类本身就是一个大模块，以类为单位进行测试
6.软件开发过程和项目管理
Murphy定律
从一开始就要对软件开发的复杂性要有清楚的认识
软件计划：
这些从软件开发的一开始就要开始指定了，例如软件测试计划基本上要在需求分析的时候就开始
软件项目度量：
面向功能的度量：
软件项目估算：
尽量拖后估算23333
人工预期：
不同层次员工参与情况：
人员越多越好吗？
不宜人数过多：
人员的几种结构：
项目延迟的原因：
软件可靠性：
CMM认证：
