第一章软件工程基础

本章对软件工程的基本概念进行概述，其中包括软件、软件危机、软件工程、软件工程过程等相关的基本概念。同时介绍了软件的发展、软件危机的产生原因、软件危机的解决途径，软件工程的基本原理与目标，并详细介绍了ISO/IEC 12207软件生存周期过程标准。

●1.1软件的定义、特点及分类

本小节首先介绍软件的定义，明确软件=程序+数据+文档。同时指出，软件与硬件不同，具有智能性、抽象性、复杂性和系统性等特点；最后介绍几种软件分类的方式。

●1.2软件危机

本小节我们简单介绍软件危机的定义，列举历史上著名的软件危机事件，由此归纳出软件危机主要的表现形式和产生原因，最后提出软件工程是缓解软件危机的有效途径。

●1.3软件工程的产生与发展历史

本小节我们介绍软件工程技术领域的产生及软件工程的发展经历了传统软件工程、面向对象的软件工程、面向构件的软件工程及面向服务的软件工程四个阶段。

●1.4软件工程的概念

本小节我们借助于制造工程类比软件工程，来介绍软件工程的定义及软件工程的三要素：方法、工具和过程。

●1.5软件工程的基本原理与目标

本小节介绍软件工程开发过程中必须遵循的七条基本原理，它被认为是确保软件产品质量和开发效率的最小原理集合。然后再此基础上，又介绍软件工程项目成功的基本目标及目标之间的关系。

●1.6软件工程过程的定义及标准

本小节首先介绍软件工程过程的定义，分析软件工程过程的必要性。然后介绍国际标准化组织ISO制订的ISO/IEC 12207软件生存周期过程标准，分别描述了其中涉及到的主过程、支持过程、辅助过程三大过程。最后给出软件生命周期的定义。

第二章问题定义及可行性研究

本章概述了问题定义及可行性研究阶段。分别介绍了这两个阶段的主要任务、实施方法及产生的成果物。

●2.1问题定义

本小节概述问题定义阶段，说明问题定义阶段的主要任务、实施方法及主要成果物，也就是问题定义报告。

●2.2可行性研究及其重要性

本小节介绍可行性研究的含义，通过案例探究可行性研究的重要性。

●2.3可行性研究的方法

本小节主要描述如何对一个项目进行可行性研究，并且通过具体案例，从技术、经济及社会三方面来分析、研究项目的可行性，并作出明确的结论。

第三章软件需求分析

本章首先从分析需求分析的重要性与困难性入手，介绍需求分析的主要任务，通过案例描述需求分析的过程，本章还进一步分析了需求分析过程中的痛点问题-需求的变更，最后介绍了一种数据驱动的需求验证方法-A/B测试。

●3.1需求分析为什么重要？

通过本小节通过案例分析，指出需求分析具有决策性，方向性的作用，它在开发过程中具有举足轻重的地位。

●3.2需求分析为什么困难？

本小节，我们从需求的动态性、模糊性、达成一致的艰难性、人员沟通障碍、体制变革等5个方面分析了需求分析工作的困难性。

●3.3需求分析要分析什么？

本小节我们重点说明需求的定义是分层次，分为用户需求、产品需求及软件需求。需求分析的过程就是从收集用户需求开始，分析与提炼用户需求形成产品需求，进一步细化产品需求形成软件需求的过程。

●3.4需求分析怎么做？

本小节通过生活中的类比案例，讲解如何进行需求分析？首先收集用户需求，并诱导、挖掘用户的真实需求；再此基础上，结合产品定位，提出解决方案形成产品需求，最后进一步细化产品需求，获取系统的软件需求。

●3.5需求分析怎么做？（续）

本小节在通过调研获取用户需求，得到产品需求与软件需求的基础上，我们要对目标系统建立逻辑模型，撰写需求规格说明书，制定初步的系统测试计划来确认需求的可测试性，编写初步的用户手册从用户处确认需求，接下来完善我们初期指定的开发计划，最后对需求进行评审。最后本小节通过一个企业级 真实案例来描述一次完整的需求分析过程。

●3.6需求变更

本小节首先分析产生需求变更三条原因：需求的不确定性、低估需求变更的成本、系统研发周期过长，然后从源头出发，探究解决需求频繁变更的四条途径。

●3.7数据驱动的需求验证-A/B测试

本小节介绍产品设计中，可以通过A/B 测试来解决 经常面临的设计方案选择问题。最后以ZAGG公司的案例，以数据分析的方式，客观评价设计方案的优劣。

第四章软件设计

本章从为什么要进行软件设计入手，介绍了软件的概要设计、详细设计的主要任务及表达工具，通过具体案例介绍了软件设计的过程，最后讨论了架构设计的本质思想-架构思维。

●4.1为什么要进行软件设计？

本小节在描述开发阶段工作流的基础上，引出软件设计活动。接下来又分析了复杂工程项目具有的需求不确定和技术复杂性特点。明确提出复杂工程项目必须进行软件设计活动，因为软件设计活动可以有效降低技术复杂性、降低满足需求和需求变化的开发成本、可以保障服务稳定运行。

●4.2什么是软件设计-概要设计？

本小节，我们介绍软件设计中的概要设计，概要设计的主要内容是完成架构设计、数据设计、接口设计及性能、可靠性与安全性设计。概要设计阶段产生的文档包括：概要设计说明书、数据库设计说明书， 进一步修改用户使用手册、制定初步的集成测试计划等。最后我们又介绍了几种常用的图形化描述工具，用于表达概要设计中的架构设计。

●4.3什么是软件设计-详细设计？

本小节，我们介绍软件的详细设计，主要包括详细设计的内容：为每个模块确定算法，选择适当的工具表达算法；确定每个模块内使用的数据结构；确定模块接口的细节；然后就是详细设计的评审。本小节我们还通过案例介绍了详细设计的描述工具，如常用的流程图、NS图、PAD图、判定表、判定树、PDL等。

●4.4如何做好软件设计？

本小节我们从什么是好的软件设计开始，通过案例探究如何做好软件设计工作，软件设计工作的流程，通常包括：1.设计人员深入理解软件需求，分析需求中，软件设计工作的关注点，得到初步的软件设计-部署设计方案；2.对初步的部署方案采用自顶向下 层层细化的方式完成软件的架构设计，3.最后还要对完成的架构设计方案进行评审，发现问题，及时纠正，以免错误进行发散性传播。

●4.5架构设计的本质思想--架构思维

本小节介绍进行架构设计时，常用的几种思维方式：抽象、分治、复用和演化思维。良好的架构设计思维的培养，离不开高质量项目的实战锻炼，然后就是平时的学习、思考和提炼总结。

第五章软件实现

软件的实现包括编码与测试两个阶段。软件的编码阶段，主要介绍编码的任务、程序设计规范及对代码的评审活动。软件测试是保证软件可靠性的重要手段之一，本章在介绍软件测试过程的基础上，通过案例详细讲解了如何进行软件测试。

●5.1编码

本小节介绍编码阶段的任务：也就是首先考虑从函数库、类库、构件库中挑选可以复用的组件；如果没有满足条件的可复用的组件，就要按照编程规范开发新的、可复用于其他项目的模块。另外，本小节还列举了编码阶段主要的成果物，包括：《源程序清单》、《用户使用手册》、《用户安装手册》及《系统管理员手册》。最后，谈到对代码要进行严格的评审活动。

●5.2什么是软件测试？

本小节，我们从软件测试的概念出发，介绍软件测试的目的，软件测试就是为了尽可能多的 找到软件中的错误，软件测试是不能证明软件的正确性的。最后，阐述了软件测试的六条准则及测试用例的概念。

●5.3软件测试的步骤

本小节，我们首先概述了软件测试的过程，然后详细介绍了，单元测试与集成测试两个测试阶段的主要任务、测试方式及涉及的输入、输出信息等。

●5.4软件测试的步骤（续）

本小节对集成之后的系统，依据软件需求规格说明书中定义的功能需求、性能需求、安全性要求，进行确认测试；然后把已确认的软件系统移植到实际运行环境中，与其它系统元素（如硬件、数据库等）组合在一起，按照系统的功能和性能需求进行系统测试。最后，通过系统测试的系统交付用户，由用户主导进行验收测试。

●5.5如何进行软件测试？

本小节我们以登录功能为例，讲解如何进行软件测试。对于高质量的软件测试，不仅仅需要考虑明确的显式的功能性需求，还要考虑性能、兼容性、安全性等一系列非功能性需求，这些非功能性需求对软件系统的质量有着举足轻重的作用。

第六章软件运行与维护

本章主要介绍软件的交付与软件的维护。
软件交付标志软件开发阶段的结束，漫长的运行维护阶段的开始。本章介绍了软件交付的主要任务和交付方式。
软件的维护是软件生命周期最后一个阶段，也是持续时间最长的阶段。本章详细介绍了4中类型的维护活动及维护活动产生的副作用。

●6.1软件交付

本小节，我们介绍软件的交付活动，详细描述软件交付的主要任务和交付方式。通过一个持续交付工具链案例分享各大互联网公司使用最广泛的一种持续交付方案，通过一系列自动化的工具，实现了测试、部署、运维的自动化。

●6.2软件维护做什么？

本小节，介绍软件维护基本概念的基础上，引入软件开发过程中，面临的四种类型的维护活动：改正性维护、适应性维护、完善性维护及预防性维护。最后，我们介绍软件的副作用，在软件维护过程中，我们要注意，不要因修改软件而引入其他错误或不希望出现的问题。

第七章软件项目管理

软件工程包括技术与管理两方面内容，是技术与管理紧密结合的产物。同时，有效的管理也是大型软件工程项目成功的关键。本章概述了软件项目管理的定义、三约束、五大过程及九大知识领域。
软件配置管理是整个软件生命周期中，标识、管理变化的一组活动。本章首先提出软件配置管理的基本定义，然后介绍了软件配置管理的五项主要任务。

●7.1为什么要学习软件项目管理?

本小节分享了一个软件项目失败的经典案例，通过这个案例，我们认识到软件开发过程，不仅仅需要主过程，来完成主要的技术活动；软件项目的管理同样重要，同样决定着一个项目的成败。

●7.2什么是软件项目管理?

本小节，在介绍软件项目管理定义的基础上，概述了项目管理涉及到的三个要素、五个过程组及九大知识领域。

●7.3什么是软件配置管理?

本小节，我们首先介绍了软件配置管理的基本定义，提出软件配置管理就是一套指导和监督的方法，这套方法可以用来识别和记录配置项；还可以控制配置项的变更；并且 记录和报告变更的处理和执行的状态；目的就是为了维护配置项的完整性、可追溯性及正确性。
除此，本小节还介绍了软件配置管理的五项主要任务，涉及到配置项的标识、版本控制、变更控制、变更之后还需要配置的审计，以确保变更的质量，最后就是书写配置状态报告，记录下变更的发生及影响。

第八章软件开发模型

软件开发模型是跨越整个软件生命周期的软件开发、运行和维护的全部工作和任务的结构框架。它给出了软件开发活动之间的关系。对于任何一个软件项目，都要选择一个合适的软件开发模型。
目前，常见的软件开发模型大致分为两类：
1.以瀑布模型为代表的生命周期模型：瀑布模型、V与W模型、快速原型模型、迭代模型、增量模型、螺旋模型；
2.敏捷开发模型：Scrum模型及极限开发XP模型。

●8.1瀑布模型（上）

本小节，我们介绍了经典的软件开发模型-瀑布模型，谈到瀑布模型将软件生命周期划分为：计划、需求分析、设计、编码、测试及运行维护等六个阶段。并规定六个阶段自上而下、相互衔接，飞流直下，一泻千里，形似瀑布一样。然后我们还介绍了瀑布模型的开发活动具有的共同特点，最后分析了瀑布模型的优点。

●8.2瀑布模型（下）

本小节，我们首先谈到瀑布模型过于理想化，存在着比较强的模型假设，也就是瀑布模型认为需求是明确的，可以通过开发初期的一次需求分析就能搞懂，并且需求分析应该是固定不变的。基于这个模型假设，我们得出瀑布模型的局限性也就是模型自身的缺点。最后归纳模型的优缺点得出瀑布模型适合的项目特点。

●8.3V模型与W模型

本小节，我们介绍瀑布模型的两个变体模型-V模型及W模型。这两种模型基本思想与瀑布模型是相同的，主要特点是强调与开发过程相对应的验证过程。

●8.4快速原型模型

本小节，我们从分析瀑布模型的局限性入手，引出快速原型模型。提出快速原型模型以原型驱动，通过过程的交互性和迭代性，主要用于明确用户的需求，也可以用于大规模开发和实现之前，考核技术实现方案是否合适。最后我们分析了快速原型模型具有的优缺点及其适用的范围。

●8.5迭代与增量模型（上）

本小节我们从瀑布模型的周期太长这个问题出发，引出增量模型。就是将大瀑布拆分成若干个小瀑布模型，分批次、增量开发、批次提交用户。每个增量又是一个从需求到测试的小瀑布模型。最后我们又分析了增量模型的优缺点及其适用范围。

●8.6迭代与增量模型（下）

本小节我们介绍了迭代模型，分析了迭代模型的优缺点及其适用范围，也就是迭代模型更适用于规模大、难度大、需求模糊、并且频繁变更或者技术新颖、风险高的项目。最后我们又比较了增量模型与迭代模型的不同之处。

●8.7螺旋模型（上）

本小节，我们首先介绍了大型软件项目具有的特点，如业务需求复杂，模糊，经常变化；而且，开发过程中往往存在诸多风险因素，在不同程度上损害软件开发过程和软件产品的质量。提出对大型软件项目必须要进行风险管理。接下来我们介绍了什么是风险以及对风险的管理，具体包括：首先是风险识别、然后风险量化、其次对风险制定应对策略，最后就是对风险进行监控预警，风险一旦发生，马上对风险进行干预，避免更大的损失。

●8.8螺旋模型（下）

本小节我们介绍了螺旋模型。在螺旋模型中，软件过程被表示成一个螺线。在螺线上的每一个循环表示过程的一个阶段。并且，每个循环都包含风险的识别、消除风险的环节。在介绍螺旋模型的基础上，我们又分析了螺旋模型具有的优缺点。

●8.9敏捷方法及敏捷宣言

本小节，我们首先提出，敏捷开发已成为众多高效开发团队的制胜之道，它能够大大提高软件开发的效率，及提升软件产品的质量。然后我们在分析敏捷方法特征的基础上，讲解了敏捷宣言，也就是敏捷方法的价值观。

●8.10敏捷开发原则

本小节，我们主要介绍了敏捷开发过程的经验总结-也就是敏捷开发的十二原则，在此基础上，澄清对敏捷开发原则的一些误读。

●8.11 Scrum模型（一）

本小节，我们首先对Scrum模型进行概述，然后详细介绍了模型中的三种角色，就是产品负责人Product Owner、流程负责人 Master及团队成员Team member。其中，Product owner定义了这个项目做什么，Scrum master从过程上保证了如何实现这个项目，Team从技术上保证了如何实现这个项目。他们一起扮演了Scrum流程中猪的角色。

●8.12Scrum模型（二）

本小节，我们介绍了Scrum模型中的文档，具体包括：产品待办目录product backlog，用于描述产品需求；冲刺待办目录sprint backlog是从开发技术角度理解的冲刺开发任务；燃尽图burn-down chart，是Scrum中展示项目进展的一个指示器。
上述三种文档是Scrum模型中定义的最小文档，Scrum模型本质上是一种加模型，仅定义最小文档、最核心实践，然后团队根据敏捷核心思想，结合自己特点，可以进行添加。

●8.13Scrum模型（三）

本小节我们介绍了Scrum模型的活动，主要包括：Sprint策划会议、每日会议 Daily Meeting、Sprint评审会(Review Meeting)及Sprint回顾会议(Retrospective Meeting)。
首先，在每轮Sprint的第一天，召开Sprint策划会议(Sprint Planning Meeting)。在会议上，主要是确定本次sprint的开发任务，即确定sprint backlog中。在sprint期内，团队将决定任务分配、所需的技术等，逐一完成任务。每天团队会进行一个简短的站立会议即每日立会 Daily Meeting，沟通当前进度、下一步任务和当前存在的问题。在每个sprint的最后一天，团队会召集评审会(Review Meeting)，邀请产品负责人等利益相关者参加，对已经完成的产品功能条目进行评审，后者做出判断并给出改进反馈。当天还会召开回顾会议(Retrospective Meeting)，对本次Sprint中的成功与失败之处做出总结，并在以后Sprint中进行改进。

●8.14极限编程XP模型

本小节，我们介绍了另外一种敏捷模型--极限编程XP。本课程我们选择两种敏捷模型：Scrum是一种侧重于项目管理的敏捷框架，而XP关注的是具体的工程技术实践。我们在介绍极限编程四个核心价值的基础上，重点讲解了XP的12个技术实践，希望每个同学能够真正理解这里谈到的价值及实践，并且将其应用到自己的软件项目开发过程中。

●8.15软件工程失败案例

本小节，我们首先盘点了历史上著名的软件项目失败案例，引出PMI美国项目管理协会对失败项目的定义标准，最后试图从软件工程的视角来分析失败项目的主要原因。希望我们每个同学能从这些失败的案例中总结经验，吸取教训，进一步理解软件工程的核心思想。

●8.16开源项目开发过程案例

本小节我们介绍了著名的开源项目VS Code，通过登录VS Code的Github仓库，我们不仅仅可以获取项目的源代码，还可以观察项目的开发过程是怎么组织，团队是如何分工协作的，还有团队开发使用的工具有哪些？
通过观察开源软件的开发过程、团队组织及工具使用，可以帮助我们更好的理解和应用软件工程的知识点，我们也可以借鉴一些好的实践到自己的项目开发中。