软件工程学习笔记

第1章软件工程基本观念

1.1 软件工程的目标与常用模型

1.2 软件开发的基本策略

1.2.1 复用

软件复用可以表述为：构造新的软件系统可以不必每次从零开始，直接使用已有（稳定）的软构件，即可组装（或合理修改）成新的系统。

1.2.2 分而治之

分而治之是指把一个复杂的问题分解成若干个简单的子问题，然后逐个解决。诸如软件的体系结构设计，模块化设计等都是分而治之的表象。

1.2.3 优化-折衷

软件的优化是指优化软件的各个质量因素，比如提高软件运行速度，提高对内存资源的利用率，改善用户界面效果，使三维图形的真实感更强等等。但是软件优化比较复杂，当所有因素不能都得到优化的时候，就需要“折衷”策略。

软件中的“折衷”策略是指通过协调各个质量因素，实现整体质量的最优。在保证其他质量因素不变差的前提下，使某些质量因素变得更好。

第2章程序员与程序经理2.1 了解程序员

2.2了解程序经理

好的程序经理应具备以下品质：

1)技术水平是程序员当中的最高级别

2)能做最多且最难的工作

3)有人格魅力

程序员升为经理后一定要保持编程的习惯。2.4 软件团队建设

技术级别和管理级别都划分为四个等级：

第3章项目计划与质量管理

在可行性分析之后，项目计划与质量管理将贯穿需求分析，系统设计，程序设计，测试，维护等软件工程环节。软件的高质量是“设计”出来的，不是“管”出来的。

3.1 项目计划

只有知己知彼才能做出合理的项目计划。

“知己”是指了解有多少可用资源，包括：人；可复用的软构件；软硬件环境。

“知彼”是指了解项目的规模，难度与时间限制。

3.2 零缺陷质量管理的理念

“零缺陷”质量管理有两个核心内容：高目标；可执行的规范。

3.3 软件的质量因素

3.4 质量检查

质量检查应该在每个实践环节（里程碑）都执行。

检查工作要预防被检查者弄虚作假。

检查工作要有科学的评审方式。

第4章可行性分析与需求分析

可行性分析是要决定“做还是不做”。

需求分析是要决定“做什么，不做什么”。

4.1 可行性分析的要素

做可行性分析不能以偏概全，也不能鸡毛蒜皮的细节都加以权衡。可行性分析必须为决策提供有价值的凭证。

软件的可行性分析一般考虑如下几个要素：经济；技术；社会环境；人。

4.1.1 经济

“成本-收益”分析，“短期-长远利益”分析。

4.1.2 技术

软件的时间限制，软件的质量要求，软件生产率。

4.1.3 社会环境

市场（未成熟的市场，成熟的市场，将要消亡的市场），政策。

4.1.4 人

4.2 可行性分析案例

4.3 需求分析为什么困难

1)客户说不清楚需求。

2)需求自身经常变动。

需要弄清楚哪些是稳定的需求，哪些是易变的需求，以便在进行系统设计时，将软件的核心搭建在稳定的需求上。

3)分析人员或客户理解有误。

4.4 如何进行需求分析

需求围绕两个核心问题开始分析：应该了解什么；通过什么方式去了解。

第5章系统设计

系统设计是把软件需求转化为软件系统的最重要的环节。系统设计的优劣在根本上决定了软件系统的质量高低。

5.1 体系结构设计

体系结构是软件系统中最本质的东西。

1)体系结构是对复杂事物的一种抽象。

2)体系结构在一定的时间内保持稳定。

层次结构；C/S结构。

5.2 模块设计

我们习惯从功能上划分模块，保持“功能独立”是模块化设计的基本原则。“功能独立”的模块可以降低开发，测试，维护等阶段的代价。

5.2.1信息隐藏

模块的信息隐藏可以通过接口设计来实现。一个模块仅提供有限个接口，执行模块的功能或与模块进行通信必须且仅需通过调用公有接口来实现。

5.2.2 内聚与耦合

内聚：模块内部各成分之间的相关联程度的度量。

耦合：模块间依赖程度的度量。

模块设计追求强内聚，弱（松）耦合。

5.2.3 封闭-开放性

如果一个模块可以作为一个独立体被其他程序调用，则称模块具有封闭性。

如果一个模块可以被扩充，则称模块具有开放性。

采用面向过程的开发方法进行程序设计，很难开发出既具有封闭性又具有开放性的模块。采用面向对象设计方法可以较好地解决这个问题。

5.3 数据结构与算法设计

设计高效率的程序是基于良好的数据结构与算法。

数据结构和算法就是一类数据的表示及其相关的操作。

时间-空间的权衡。

5.4 用户界面设计

界面的合适性。

界面风格的“一致性”和“个性化”。

界面的广义美。

第6章C++面向对象程序设计6.1 C++面向对象程序设计的重要概念

设计类时“以行为为中心”，即首先考虑类应该提供什么样的函数。继承与组合。

虚函数与多态。

第7章测试与改错

测试的目的是为了发现尽可能多的缺陷，并期望通过改错来把缺陷都消灭掉，以期提高软件的质量。

7.1 对测试的理解

测试只能证明缺陷存在，而不能证明缺陷不存在。

测试有助于提供软件质量，但是提高软件质量不能依赖于测试。软件的高质量是靠设计出来的，而不是靠测试修补出来的。

7.2 测试人员的选择

独立的测试小组，自动测试，为关键性的软件构建进行代码复查。

公司内部对产品的测试（α测试），需要开发人员与独立的测试小组共同参与。

开发人员应执行“白盒”测试，即测试源程序的逻辑结构以及实现细节。

独立的测试小组应执行“黑盒”测试，即按照规格说明来测试程序是否符合要求，关心程序的外部表现而非程序的内部实现。

软件产品发布之前，在公司外部邀请一些用户对产品进行测试，称为β测试。

7.3 测试的主要内容与常用方法

正确性测试

容错性测试

性能与效率测试

易用性测试

文档测试

第8章维护与再生工程

8.1 软件维护的常识

软件维护一般可划分为三类：

1)纠错性维护

2)适应性维护：新的硬件设备及系统环境的升级导致的适应性维护。

3)完善性维护：新的软件需求。大概占65%。

8.2 维护的代价及其主要因素

8.3 再生工程

如果把维护比作“修修补补”，“再生工程”就可以当做是“痛改前非”。再生工程并不见得代价就比维护要高，再生工程在将来获得的收益却要比通过维护得到的多。

再生工程主要有三种类型：重构，逆向工程（竞争对手的产品或自己多年前的产品），前向工程（预防性维护）。

如果希望软件系统能活下，则必须要对软件进行维护工作。如果希望软件系统有效益，则要设法降低维护的代价。