软件工程笔记

目录

第一章  软件工程概论 / 第二章  个人技术和流程 

软件工程：

两个原则：

两个模式实现原则：

第三章  工程师的成长

代码复审：

第五章   团队和流程

MVP ：

MBP：

第六章  敏捷流程

敏捷价值观之敏捷宣言：

Scrum：

SPRINTS:

第八章   需求分析

电梯演说：

第九章   项目经理

三种经理：

两种工作的区别：

风险：

第十章  典型用户场景

用户故事的核心内容：

第十一章  软件设计与实现

里程碑/基线（baseline）：

第十二章  用户体验

十三章   软件测试

测试准则：

白盒测试：

黑盒测试：

十四章  软件的质量     

CMMI五级

软件测试（Test）：

软件质量保障工作（Quality Assurance）：

从软件的Code Complete 到最后发布经历的步骤：

招数: 设计变更（Design Chang Request）

实训一  测试驱动开发：

测试驱动的设计和开发步骤：

实训二  结对编程

结对编程的好处：

结对编程的坏处：

实训三   重构

重构概念：

补充二  架构模式

架构是：

企业应用：

隔离关注点：

三层架构:

三层架构的关系：

分层架构依赖原则：

UML

用例图：

用例图中涉及的关系：

类图：

时序图：

活动图：

---

---

第一章  软件工程概论 / 第二章  个人技术和流程 

程序=数据结构+算法   软件=程序+软件工程

软件工程：

把系统的、有序的、可量化的方法应用到软件的开发、运营和维护上的过程。

软件工程内容：软件需求分析、软件设计、软件构建、软件测试和软件维护（开发过程）。（/创造软件的过程，运用系统、数学、管理方法完成软件的制作。）

软件开发流程：人们在开发、运营、维护软件的过程中有很多技术、做法、习惯和思想体系。软件工程把这些 相关的技术和过程统一到一个体系中，叫“软件开发流程”。

两个原则：

单一职责原则（Single Responsibility Principle, SRP）：  指出 一个模块（类）应该只有一个导致它变化的原因，一个模块应该完全对某个功能负责。

开放- 封闭原则（Open-Close Principle， OCP）:     软件实体应该是可以扩展的，同时是不可修改的。 允许扩展（Open for extension）。当应用的需求发生改变时，我们可以对模块进行扩 展，从而改变模块的功能。 不允许修改（Closed for modification）。对模块行为进行扩展时，不必改变模块的本身。

两个模式实现原则：

针对接口编程而不是针对实现编程--使用多态； 优先使用代码组合而不是类继承--使用封装。

思想方法原则：封装变化点。

第三章  工程师的成长

代码复审：

看代码是否在代码规范内正确的解决了问题。

代码复审分类：

第五章   团队和流程

MVP ：

Minimum Viable Product 最小可行产品，又称为Minimal Feature Set，最小功能集。 （/把产品最核心的功能用最小的成本实现出来（或者描绘出来），然后快速征求 用户意见。）

MBP：

Maximal Beautiful Product（最强最美产品） 如果对用户的需求了然于心，或者产品团队比用户 更了解用户的需求，为何不把产品最全、最美的形态展现出来，一举征服用户。

第六章  敏捷流程

敏捷价值观之敏捷宣言：

个体与交互重于过程和工具，可用的软件重于晚辈的文档，客户协作重于合同谈判，响应变化重于遵循计划。

Scrum：

是英语中橄榄球运动的一个专业术语，表示“争球”。 特指一种轻量级的敏捷开发框架，是一个增量的、迭代的开发过程。

Scrum特点：

1 Scrum规定了一个非常简单的开发流程。 2 Scrum是现有设计流程的总结。 3 Scrum以团队为基础，是一种在需求迅速变化情况下迭代地、增量地开发系统和产品的方法。 4 Scrum是一个控制由利益和需求冲突导致的混乱的流程。 5 Scrum是改善交流并最优化合作的方式。 6 Scrum是一种检测产品开发和生产过程中障碍并将其去除的方式。

SPRINTS:

1 Scrum的项目过程有一系列的Sprint组成。 2 Sprint的长度一般控制在2-4周。 3 通过固定的周期保持良好的节奏。 4 产品的设计、开发、测试都在Sprint期间完成。 5 Sprint结束时交付可以工作的软件。 6 在Sprint过程中不允许发生变更。

第八章   需求分析

电梯演说：

我们的 <新产品> 是为了解决 <目标用户> 的痛苦, 他们需要 <Need>, 但是现有的方案并没有很好地解决这些需求，我们有独特的办法 <Approach>,  它能给用户带来好处 <Benefit>， 远远超过竞争对手 <Competitor>. 同时，我们有高效率的 <Delivery> 方法，能很快地让大部分用户知道我们的产品，并进一步传播。 把上面的这段话录制为视频，上传到视频网站，并把链接发到个人/团队博客上。

电梯演说模板：（改进产品）我们的 <功能改进> 是为了解决 <目标用户> 的痛苦, 他们需要 <Need>, 但是现有的方案并没有很好地解决这些需求，我们有独特的办法 <Approach>,  它能给用户带来好处 <Benefit>， 远远超过竞争对手 <Competitor>, 包括我们以前的版本。我们有数据 <Data> （用户调查）支持这一个结论。 我们相信新的改进能给我们带来 <Data> 的业绩改善 （用户量，使用时间，评价，收入）。 把上面的这段话录制为视频，上传到视频网站，并把链接发到个人/团队博客上。

第九章   项目经理

三种经理：

Product Manager：产品经理— 正确地做产品。 对一个或多个产品或产品线负责。核心要求是，根据市场和 用户需求，协调各部门资源，正确地把握产品定位和方向，解决用户的痛点，持续优化产品。

Project Manager：项目经理—正确地做流程。与产品经理分开单列。 他们对项目流程负责，即项目从立项到上线按时完成。正确地协调团队内部外部，调配各部门 资源和时间，有效进行风险管理，保证一个项目顺利 按计划结项。

Program Manager：微软的职位名称。PM负责除产品开发和测试之外的所有事情。从某种意义上说，是前面两种角色的综合。

两种工作的区别：

风险：

风险是: “A possible event that affects the project negatively if happens”一个可能的事件，消极影响项目，如果发生 会影响项目成功的可能事件 今天的风险，就是明天的问题 今天的问题，是由昨天的风险导致的。

第十章  典型用户场景

用户故事的核心内容：

1 作为……角色（处在用户的角度思考问题）。 2 我希望系统能做一个……功能（假设我就是这个用户，思考“我” 需要什么功能）。 3 以便能让我……（思考这个功能对我的价值）。敏捷要求在交付价值驱动下工作，用户故事是这个思想的重要体现。

用户故事的三个部分的重要性：

第一部分：最重要（以人为本）；第二部分：最次要（需求）； 第三部分 ：重要（价值）。

第十一章  软件设计与实现

里程碑/基线（baseline）：

 一个已经被正式评审和批准的规格或产品，它作为进一步开发的一个基础，并且必须通过正式的变更流程来变更。

第十二章  用户体验

软件测试知识：无论怎样强调软件测试的重要性和它对软件可靠性的影响都不过分，尽可能早地发现并纠正差错。

十三章   软件测试

测试是为了发现程序中的错误而执行程序的过程。    

好的测试方案是极可能发现迄今为止尚未发现的错误的测试方案；    

成功的测试是发现了至今为止尚未发现的错误的测试。

简答：测试？

测试是为了发现程序中的错误而执行程序的过程。    

好的测试方案是极可能发现迄今为止尚未发现的错误的测试方案；    

成功的测试是发现了至今为止尚未发现的错误的测试。

          测试用例？

描述了一个完整的测试过程，包括测试环境，输入，预期的结果。即一组相关的测试用例，开发和测试其实是软件工程的分支。

测试准则：

为了能设计出有效的测试方案，软件工程师必须充分理解并正确运用指导软件测试的基本准则。主要的测试准则如下所述。

所有的测试都应该能追溯到用户需求。

应该在测试开始之前的相当长时间，就制定出测试计划。  

白盒测试：

白盒测试法的前提是可以把程序看成装在一个透明的白盒子里，也就是完全了解程序的结构和处理过程，白盒测试又称为结构测试。

黑盒测试：

黑盒测试是在程序接口进行的测试，它只检查程序功能是否能按照规格说明书的规定正常使用，程序是否能适当地接收输入数据产生正确的输出信息，并且保持外部信息(如，数据库或文件)的完整性，黑盒测试又称为功能测试。

测试阶段（/测试策略）：

单元测试、集成测试、系统测试、确认测试、回归测试。

十四章  软件的质量     

软件=程序+软件工程

软件质量=程序质量+软件工程质量     

软件质量体现在软件外在功能的质量。

软件工程质量是软件在功能、成本、时间三方面满足利益相关的需求。

CMMI五级

CMMI一级，完成级。

在完成级水平上，企业对项目的目标与要做的努力很清晰，项目的目标得以实现。但是由于任务的完成带有很大的偶然性，企业无法保证在实施同类项目的时候仍然能够完成任务。企业在一级上的项目实施对实施人员有很大的依赖性。

CMMI二级，管理级。

在管理级水平上，企业在项目实施上能够遵守既定的计划与流程，有资源准备，权责到人，对相关的项目实施人员有相应的培训，对整个流程有监测与控制，并联合上级单位对项目与流程进行审查。 企业在二级水平上体现了对项目的一系列管理程序。这一系列的管理手段排除了企业在 CMM1时完成任务的随机性，保证了企业的所有项目实施都会得到成功。

CMMI三级，明确（定义）级。

在定义级水平上，企业不仅可对项目的实施有一整套的管理措施，并保障项目的完成；

而且，企业能够根据自身的特殊情况以及自己的标准流程，将这套管理体系与流程予以制度化。

这样，企业不仅能够在同类的项目上成功地实施CMMI，在不同类的项目上一样能够成功地实施.

CMMI四级，量化管理级。

在量化管理级水平上，企业的项目管理不仅形成了一种制度，而且要实现数字化的管理。

通过量化技术来实现流程的稳定性，实现管理的精度，降低项目实施在质量上的波动。

CMMI五级，优化级CMMI五级，优化级。

在优化级水平上，企业的项目管理达到了最高的境界。

企业不仅能够通过信息手段与数字化手段来实现对项目的管理，而且能够充分利用信息资料，对企业在项目实施的过程中可能出现的次品予以预防。

能够主动地改善流程，运用新技术，实现流程的优化。

软件测试（Test）：

运用一定的流程和工具，验证软件能实现预先设计的功能和特性，工作的 流程和结果通常是可量化的。例如，测试用例、Bug、代码覆盖率、MTTF、软件效能的参数， 等等。正因为流程和结果是明确定义的、可量化的，所以很多测试工作可以自动化。

软件质量保障工作（Quality Assurance）：

软件团队为了让软件达到事先定义的质量标准而进 行的所有活动，包括测试工作。

分工是社会和行业进化的结果。

开发和测试其实是软件工程的两个分支。不同的软件和服务 需要不同方式和程度的测试。独立专业的测试角色等同于第三方代表对产品质量进行检测和认证。

从软件的Code Complete 到最后发布经历的步骤：

Alpha: 指集成了主要功能的第一个试用版本。有些小功能并没有实现。事实上很多软件的Alpha版本只是在内部使用。给外部用户使用的版本会起一个比较美妙的名字，Technical Preview, 等等。     

Beta: 功能基本完备，稳定性较Alpha版本高，用户可以在实际工作中小范围使用，可以有Beta1、Beta2、Beta3……

ZBB（Zero Bug Build）: 团队要有把bug 都搞定的执行力。ZBB = Zero Bug Build，即这一版本的构建把所有已知的Bug都解决掉了。 （Zero Bug Bounce：通常在一个Zero Bug Build之后，Bug数目会以惊人的速度反弹，故称Bounce。系统要经历几次bounce，像阻尼震荡一样，Bug的数目在反弹了几次之后，最后固定在（或者无限逼近于）0。）   

RC（Release Candidate）: 发布候选版本，RC1、RC2……直到RTM为止，版本间隔时间较短。     

RTM（Release To Manufacturer）: 最终发布版本。如果某一个RC版本没有很大的问题，那么这一RC就会成为最终的版本, 通常情况下，软件公司会把最终的版本和相关的文件及其他资料交给另一个团队（Manufacturer）去包装、刻软盘、光盘。在AppStore/MarketPlace 的年代 , 我们有相应的 RTM （Release To Market）。

招数: 设计变更（Design Chang Request）

重写（/重构）

重构：在尽量保持原有界面的基础上优化部分代码。  

重写：重新实现原有功能，同时，要分清是全部重复原有功能，还是偷偷加上许多新的功能（Feature Sneak）。

实训一  测试驱动开发：

测试：为发现程序中的错误而执行程序的过程。

单元测试：在编写出每个模块之后就对它做必要的测试(称为单元测试)，模块的编写者和测试者是同一个人。

测试用例：测试数据和预期的输出结果称为测试用例。

DD原则：除非你有一个失败的自动测试，永远不要写一单行代码。

测试驱动的设计和开发步骤：

1 在开发一个新的功能之前，首先确定你要做什么（不是要如何做！！）

2 为这个功能（Method）写单元测试例子( Unit Test )单元测试例子要覆盖这个Method的 “做什么”。

3 写产品（Production）代码。

4 运行Unit Test。

实训二  结对编程

结对编程的好处：

1 提高设计质量 更好的设计，避免愚蠢的bug。

2 降低成本 分享知识，更少的debug 时间。

3 提高解决问题的信心，结对经常能解决 “不可能的任务” 。

4 提高士气 觉得自己的工作有另一人认可。

5 减轻风险 在团队中有一些 “知识的冗余”，降低了成员离开的负面影响。

6 提高效率。

结对编程的坏处：

1 工作方式的不同 大多数人觉得喜欢一个人工作 。

2 让人感觉到威胁 新手 vs. 老手 。

3 时间可能花在培训上面 （也有价值） 老手 vs. 新手 。

4 对个人情绪，自尊的影响 “my code”  vs. “your code”。

实训三   重构

重构概念：

Refactoring是对已经完成的代码进行改进的过程。在不对代码的外部行为进行改动的情况下，对代码内部的结构进行优化。

Refactoring是严谨地对完成的代码进行清理的从而减少出错的一种方法。

Refactoring的实质是对完成代码的设计进行改进。

Refactoring是XP项目中每天的例行练习。

Refactoring必须和Test-Driven Design and Development伴随进行。

软件开发是一个进化的过程。

补充二  架构模式

架构是：

一点是“最高层次的系统分解”；另一点是“系统中不易改变的决定”。

架构是一种主观上的东西，是专家级的项目开发人员对系统设计的一些可共享的理解 。

企业应用：

一般都涉及到持久化数据;   

 一般都涉及到大量数据;     

一般还涉及到很多人同时访问数据;     

还涉及到大量操作数据的用户界面屏幕;     

通常需要与散布在企业周围的其他企业应用集成。

隔离关注点：

隔离关注点，使得我们可以在同一时间只考虑一个方面的问题，从而减少了人们同时要思考的信息量，这实际上与抽象、模块化背后的原理是一样的。而如果将隔离关注点的概念加以扩展，那么对象的抽取、封装、模块的划分等，其实也属于某种特殊的隔离关注点。

三层架构:

表现层：表现逻辑处理用户与软件间的交互。主要职责是：向用户显示信息；把从用户那里获得的信息解释成领域层或数据源层上的各种动作。     

数据源层：数据源逻辑主要关注与其他系统的交互，这些系统将代表应邀完成相关的任务。主要的数据源逻辑就是数据库，它的主要职责是存储持久数据。

领域层：领域逻辑（业务逻辑），它就是应用必须做的所有领域相关的工作：根据输入数据或已有数据进行计算；对从表现层输入的数据进行验证；根据从表现层接收的命令来确定应该调度哪些数据源逻辑。

三层架构的关系：

领域层是核心！表现层是系统对外提供服务的外部接口；数据源层是系统使用外部服务的接口。

分层架构依赖原则：

领域层和数据源层绝对不要依赖于表现层。也就是说，在领域层和数据源层的代码中，不要出现调用表现层代码的情况。

UML

UML是一种Language（语言）

UML是一种Modeling（建模）

Language UML是Unified（统一）Modeling Language

用例是系统执行的功能或过程，它可以由外部

对象或系统内部另一个用例启动。

用例图：

用例的必要性：1 有助于理解系统需求 2有助于正确设计系统功能 3 有助于正确建立功能间的关系

构建用例图：1 定义系统和系统边界  2 确定参与者及其目标 3 确定用例 步骤 4 确定参与者和用例之间的关系

特征：用例都是动宾结构； 用例是相互独立的； 用例由参与者启动； 有可观测的执行结果；

用例图中涉及的关系：

关联：表示参与者与用例之间的通信，任何一方都可发送或接受消息。

泛化：理解的继承关系，子用例和父用例相似，但表现出更特别的行为。

包含关系：用来把一个较复杂用例所表示的功能分解成较小的步骤。

扩展关系：是指用例功能的延伸，相当于为基础用例提供一个附加功能。

类图：

类是对一组对象的描述，这些对象具有相似的属性、操作、关系和行为。

时序图：

时序图用于按时间顺序模拟控制流程。它显示了在对象生命线上各点之间的对象传递的消息，演示了在时间序列中对象之间的交互

活动图：

初始节点和活动终点：用一个实心圆表示初始节点，用一个圆圈内加一个实心圆来表示活动终点 活动节点：是活动图中最主要的元素之一，它用来表示一个活动。

转换：当一个活动结束时，控制流就会马上传递给下一个活动节点，在活动图中称之为“转换”，用一条带箭头的直线来表示