现代软件工程

第一章 软件工程师及软件团队

1. 程序员应该具备的技能

编写代码和阅读代码的能力，代码质量，版本控制

2. 软件团队的特点

有一致的集体目标，一个团队的成员不一定要同时工作， 团队成员有各自分工，相互依赖合作

3. 团队的组织模式

	封闭模式——遵循传统的权利层级模式
	随机模式——团队松散，依靠团队成员的个人自发性
	开放模式——尝试组成一种团队，既具有封闭模式团队的可控性，还具有随机模式团队的创新性。
	同步模式——有赖于问题的自然区分，不需要很多的交流就可以将成员组织起来共同解决问题。

4. 代码规范

影响代码的 可理解性、可测试性、可修改性。
主要包括：源程序文档华，语句构造，数据说明，输入 / 输出

5.代码复审

指通过阅读代码来检查源代码与编码标准的符合性以及代码质量的活动。
目的：1、在项目早期发现缺陷，将损失降到最低
          2、发现可能改进的地方
          3、促进团队沟通、促进知识共享、共同提高

6. 代码测试

	测试驱动开发（TDD）：先编写测试代码，再根据测试代码进行编程

7. 软件调试

软件调试是在进行了成功的测试之后才开始的工作，它与软件测试不同，调试的任务是进一步诊断和改正程序中潜在的错误。
两部分组成：1、确定程序中可疑错误的确切性质和位置
	    2、对程序（设计，编码）进行修改，排除这个错误

8. 版本控制

指软件开发过程中文件变更的管理。含有（程序代码、配置文件、说明文档）
主要作用：追踪文件的变更与并行开发

第二章 软件及软件工程

什么是软件？指计算机系统中的程序、数据以及相关文档  软件=程序+文档+数据

1. 软件的特点：

		1、软件是设计开发，而不是生产制造的
	 	2、软件不会“磨损”，但是会退化
	    3、大多数软件还是用户定制的

2. 软件技术演化

程序设计阶段--->程序系统阶段--->传统软件工程阶段--->面向对象阶段

3. 软件危机

计算机软件的开发和维护过程所遇到的一系列严重问题。
主要表现：成本与进度估算很不准确，严重拖期和超出预算。无法满足需求
	质量不可靠，难以维护更改，成本比重高等等

4. 软件工程

软件工程的定义：1、①把系统的、规范的、可度量的途径应用于软件开发、运行和维护过程，也就是把工程应用于软件； ②研究①中提到的途径”、2、应用计算机科学、数学以及管理学等原理开发软件的工程
软件工程的内容：1、软件工程是一种层次化的技术。任何工程方法必须构建在质量承诺的基础上。
	           2、软件工程的基础是过程。软件过程将各个技术层次结合在一起，使得合理、及时地开发计算机软件成为可能。
	           3、软件工程方法为构建软件提供技术上的解决方法。
	           4、软件工程工具为过程和方法提供自动化或半自动化的支持。

软件生命周期：是软件从生产直到报废的整个时期
解决问题一般过程：1、理解问题  2、建模和软件设计  3、代码生成  4、测试和质量保证
软件生命周期一般是：软件定义--->软件开发--->运行维护

第三章 软件过程及过程模型

什么是软件过程：一个为创建高质量软件所需要完成的活动、动作和任务的框架 。
通用活动：沟通--->策划--->建模--->构建--->部署

软件过程模型：也称软件开发模型  或 软件生存周期模型，是软件生存周期中一系列有序的软件开发活动的流程，是软件开发全部活动的结构框架。对一个软件的开发无论其大小，都需要选择一个合适的软件过程模型，主要根据软件的类型、规模，开发方法、开发环境等多种因素来确定。

1. 过程模型——瀑布模型

	瀑布模型将软件生命周期划分为软件计划、需求分析、设计、实现、测试、运行和维护等阶段，规定了它们自上而下、相互衔接的固定次序，如同瀑布流水逐级下落。
瀑布模型的变体--V模型
瀑布模型的特点： 1、阶段间具有顺序性和依赖性
	            2、推迟实现的观点
	            3、质量保证的观点
优点： 1、可强迫开发人员采用规范的方法（例如：结构化技术）
           2、要求每个阶段交出的所有产品都必须经过质量保证小组的仔细验证
           3、严格的规定了每个阶段必须提交的文档
缺点： 1、难以应对需求变化  客户难以准确表达需求，软件团队很难准确理解需求。
           2、过于理想  实际项目很少按照该模型给出的顺序进行
           3、风险太大  用户必须有耐心，等到系统开发完成才能见到软件
           4、阻塞状态  开发者常常被不必要地耽搁。
适用场景：需求相当稳定，客户需求被全面的了解风险管理
	开发团队对于应用领域非常熟悉
	外部环境的不可控因素很少
	小型清晰的项目

2. 过程模型——原型开发模型

原型开发模型的产生：
	- 瀑布模型将软件生命周期划分成独立串行的几个阶段，前一个阶段没有完成便无法开始下一阶段的工作。
	- 然而完整而准确的需求规格说明是很难得到的，因为：
		-在开发早期用户往往对系统只有一个模糊的想法，很难完全准确地表达对系统的全面要求 
		-随着开发工作的推进，用户可能会产生新的要求
		-开发者又可能在设计与实现的过程中遇到一些没有预料到的实际困难，需要以改变需求来解脱困境 
概述：
	-原型开发模型是预期系统的一个可执行版本，反映了系统性质的一个选定的子集
	-不必满足所有约束，目的是快速、低成本的构建原型
	-被开发的原型应交付给客户试用，并收集客户的反馈意见，这些反馈意见可在下一轮迭代中对原型进行改进。在前一个原型需要改进，或者需要扩展其范围的时候，进入下一轮原型的迭代开发
优点：
	-快速开发出可以演示的系统，方便了客户沟通
	-采用迭代技术能够使开发者逐步弄清楚客户的需求
采用的策略：废弃策略和追加策略
适用情况：
	-用户定义了一组一般性目标，但是不能标识出详细的输入、处理及输出需求
	-开发者可能不能确定算法的有效性、操作系统的适用性或人机交互的形式

3. 过程模型——增量模型

	-增量模型以迭代的方式运用瀑布模型
	-随着时间的推移，发布一系列称为增量的版本，随着每个版本的交付，逐步为用户提供更多功能
使用方法：
	软件被作为一系列的增量来进行开发，每一个增量都提交一个可以操作的产品，可供用户评估。
	第一个增量往往是核心产品：满足了基本的需求，但是缺少附加的特性。
	客户使用上一个增量的提交物并进行评价，制定下一个增量计划，说明需要增加的特性和功能。
	重复上述过程，直到最终产品产生为止。
优点：
	提高对用户需求的响应：用户看到可操作的早期版本后会提出一些建议和需求，可以在后续增量中调整。
	人员分配灵活：如果找不到足够的开发人员，可采用增量模型，早期的增量由少量人员实现，如果客户反响较好，则在下一个增量中投入更多的人力。
	可规避技术风险：不确定的功能放在后面开发。
缺点：
	-每个附加的增量并入现有的软件时，必须不破坏原来已构造好的东西。
	-加入新增量时应简单、方便 ——软件的体系结构应当是开放的。
	-仍然无法处理需求发生变更的情况。
	-管理人员须有足够的技术能力来协调好各增量之间的关系。
	-难以确定所有版本共需的公用模块。

4. 过程模型——螺旋模型

是一种演化过程模型，主要针对大型软件项目的开发
风险驱动的软件开发模型
	采用循环的方式，逐步加深系统定义和实现的深度
	确定一系列里程碑，确保stakeholders都支持系统解决方案
	第一圈一般开发出产品的规格说明，接下来开发产品的原型系统，并在每次迭代中逐步完善，开发不同的软件版本
结合了原型的迭代性质和瀑布模型的可控性、系统性特点。
优点：
	结合了原型的迭代性质与瀑布模型的系统性和可控性，是一种风险驱动型的过程模型。
	采用循环的方式逐步加深系统定义和实现的深度，同时更好地理解、应对和降低风险。
	确定一系列里程碑，确保各方都得到可行的系统解决方案。
	始终保持可操作性，直到软件生命周期的结束。
	风险驱动。
缺点：
	螺旋模型依赖大量的风险评估专家来保证成功。如果有较大的风险没有被发现和管理，肯定会发生问题。
	软件开发人员应该擅长寻找可能的风险，准确的分析风险，否则将会带来更大的风险。

第四章 敏捷流程

1. 敏捷价值观：

	个人和他们之间的交流胜过开发过程和工具
	可运行的软件胜过宽泛的文档
	客户合作胜过合同谈判
	对变更的良好响应胜过按部就班地遵循计划

2. 敏捷12原则：

	1.我们最优先要做的是通过尽早、持续交付有价值的软件来使客户满意。
	2.即使在开发的后期，也欢迎需求变更。敏捷过程利用变更为客户创造竞争优势。
	3.经常交付可运行软件，交付的间隔可以从几个星期到几个月，交付的时间间隔越短越好。 （小步快跑）
	4.在整个项目开发期间，业务人员和开发人员必须天天都在一起工作。
	5.围绕有积极性的个人构建项目。给他们提供所需的环境和支持，并且信任他们能够完成工作。 
	6.在团队内部，最富有效果和效率的信息传递方法是面对面交谈。 
	7.可运行软件是进度的首要度量标准。
	8.提倡可持续的开发速度。责任人(sponsor)、开发者和用户应该能够长期保持稳定的开发速度。
	9.不断地关注优秀的技能和好的设计会增强敏捷能力。
	10. 简单——是减少不必要工作量的艺术——是必要的
	11. 最好的架构、需求和设计出自于自组织团队。
	12. 每隔一定时间，团队会反省如何才能更有效地工作，并相应调整自己的行为。

3. 敏捷过程：基于敏捷原则进行的软件开发过程，视为敏捷过程。

极限编程：
	主要目标：降低因需求变更带来的成本
	主要方式：采用迭代的交付方式

SCRUM流程：
	三个角色：项目经理（Scrum主管） 产品负责人  开发团队
	三个工件：产品订单  冲刺订单  燃尽图
	五个活动：冲刺  冲刺计划会  每日立会  冲刺评审会  回顾会议

SCRUM流程步骤：1、收集产品订单  2、选取产品订单中的任务加入到冲刺中  3、执行冲刺  4、交付、验收冲刺  5、总结冲刺

敏捷团队的要求：1、自主管理  2、自我组织  3、多功能型

第五章 理解需求

1. 需求分析困难的原因

1、客户说不清楚需求  2、需求自身经常变动  3、分析人员或客户理解有误

2. 软件需求的定义

需求是指系统必须实现什么的规格说明。它描述了系统的行为、特性或属性，是在开发过程中对系统的约束

3. 软件需求的三个层次

1、业务需求 2、用户需求 3、功能需求

	业务需求： 1、反映了组织机构或客户对系统，产品高层次的目标要求
		  2、业务需求从总体上描述了为什么要开发系统，组织希望达到什么目标
		  3、一般使用前景和范围文档来记录业务需求，称作项目轮廓图或市场需求文档
		  4、这些高级别的需求数量很少

	用户需求： 1、描述了用户使用产品必须要完成的任务
		  2、用例、场景描述和事件响应表都是表达用户需求的有效途径。
		  3、在问题定义的基础上进行用户访谈、调查、对用户使用的场景进行整理，从而建立用户角度的需求
		  4、描述了用户能用系统来做些什么

	功能需求： 1.系统分析员描述开发人员在产品实现的软件功能，用户利用这些功能来完成任务，满足业务需求。
		  2、功能需求是需求的主体，他描述的是开发人员如何设计具体的解决方法来实现这些用户需求（how），其数量往往比用户需求高一个数量级
		  3、这些需求记录在软件需求规格说明SRS中

4. 软件需求的分类：

	功能需求：描述系统预期提供的功能或服务
	非功能需求：不直接与系统具体功能相关的需求

需求工程：是应用已经证实有效的技术、方法进行需求分析，确定客户需求，帮助分析人员理解问题并定义目标系统的所有外部特征的一门学科
	它通过合适的工具和几号系统的描述待开发系统及其行为特征和相关约束，形成需求文档，并对用户不断变化的需求演进给予支持
	需求工程的基本活动：起始-->导出-->精华-->协商-->规格说明-->确认-->需求管理
	在实际的开发过程中，获取、建模、编写规约和验证这些需求开发活动不会是线性的、顺序的完成。实际上，这些活动是交叉的，递增和反复的

需求获取技术（面谈、调查、观察实际业务过程、原型法、头脑风暴、场景技术）

竞争性需求分析（NABCD）
	N（need 需求） 解决了用户什么需求
	A（Approach 做法） 用了什么招数
	B（Benefit 好处） 这个产品给用户带来了什么好处
	C（Competitors 竞争） 与竞争对手相比有什么优势
	D（Delivery 推广） 你怎么让目标用户都知道你的产品

需求规格说明书
	作用： 1、便于用户、分析人员和软件设计人员进行理解和交流
	           2、作为软件设计的基础
	           3、作为验收的依据
	需求规格说明语言：1、自然语言  2、形式化语言  3、结构化语言
	主要内容：1、信息描述  2、功能和行为描述  3、性能需求  4、设计约束 5、合适的验收标准

第六章 需求建模

1. 需求建模概述

	需求分析的目的：
		说明软件的工作特征
		指明软件和其他系统元素的接口
		规定软件必须满足的约束
	需求分析的主要任务：
		细化在前期需求工程的基础需求
		构建一种或多种模型以描述用户场景、功能活动、类、类之间的关系、系统和类的行为、数据流等
	需求建模的总体目标：
		描述客户需要什么
		为软件设计奠定基础
		定义在软件完成后可以被确认的一组需求
	需求建模的元素：1、场景模型  2、数据模型  3、类模型  4、数据流模型  5、行为模型

2. 基于场景的建模

	基本概念
		用例：用于表示系统所提供的服务，描述参与者为了使用系统所dig的某一完整功能而与系统之间发生的一段对话（交互）
		场景：场景是用例的实例化，从一个用例可以实例化出来多个用例场景。用例就是对全部场景的抽象。
	用例建模步骤：
		1、识别系统的参与者
		2、识别用例
		3、绘制用例图
		4、编写用例描述

3. 基于数据流的建模

	结构化方法概述：
		一种面向数据流的传统软件开发方法
		以数据流为中序构建软件的分析模型和设计模型
		细分为：结构化分析   结构化设计   结构化程序设计
	主要思想：抽象与自顶向下的逐层分解
	抽象与分解：
		抽象：忽略一个问题中与当前目标无关的那些方面，以便更充分的关注与当前目标有关的方面
		分解：将问题不断分解为较小的问题，直到每个最底层的问题都足够简单为止
		随着分解层次的增加，抽象的级别越来越低，也越接近问题的解
	结构化分析模型
		数据字典是模型的核心，他包含了软件使用和产生的所有数据的描述
		数据流图（DFD）是服务于两个目的：一是指明数据在系统中移动时如何被变换，二是描述对数据流进行变换的功能和子功能
	数据字典
		数据流图与数据字典是密不可分的，两者结合起来构成软件的逻辑模型
		数据字典由字典条目组成，每个条目描述DFD中的一个元素
		数据字典条目包括：数据流、文件、数据项（组成数据流和文件的数据）、加工、源点和终点

4. 基于数据的建模

	ER图

第七章 软件设计

1. 软件设计概念

	分析与设计的区别：分析是干什么？，找到问题空间，只有较少的选择。而设计是指怎么干，解决问题，可以多样化
	软件设计是指将需求转变为软件陈诉的过程，分为概要设计和详细设计
	良好的软件应该展示出坚固性，适用性，愉悦性
	良好设计应该具备的特征：
		必须实现所有在需求模型中的明确需求
		设计必须是可读的、可理解的指南
		设计必须提供软件的全貌
	适度的模块化
	为什么隐蔽信息？
		降低“副作用”的可能性
		减少局部设计绝对对全局的影响
		突出控制结构处通信
		阻止全局数据使用
		促进封装，形成高质量软件
	功能独立
		开发具有“专一功能”和“避免”与其他模块过多交互的模块，可以实现功能的独立
		内聚性：显示了某个模块相关功能的强度
		耦合性：显示了模块键的相互依赖性

2. 体系结构风格

	描述某一特定应用领域中系统组织方式的惯用模式它反映了领域中众多系统所共有的结构和语义特性,并指导如何将各个模块和子系统有效地组织成一个完整的系统。
	常见体系结构风格：
		以数据为中心的体系结构
		数据流体系结构
		调用和返回体系结构
		层次体系结构

3. 体系结构设计

	两种方法：
		结构化设计：数据流模型->软件结构图
		面向对象设计：用例模型->分析类图->设计类图->构件图
	结构化设计：
		结构化设计是指将结构化分析的结果（数据流图）映射成软件的体系结构（结构图）
	根据信息流的特点，可将数据流程图分为变换型数据流图和事务型数据流图，其对应的映射分别称为变换分析和事务分析
	映射步骤：
		1、复审和精华数据流图
		2、确定数据流图的类型
		3、将DFD映射成初始结构图
		4、改进初始结构图

4. 构件级设计

	理解构建设计
		体系设计——建筑平面图、结构、房间和外部环境之间的连接机制
		构建级设计——每个放假的内部细节设计
	基本设计原则：
		1、开闭原则：模块应对外延具有开放性，对修改具有封闭性
		2、替换原则：子类可以替换他们的基类
		3、依赖倒置原则：依赖于抽象，而非具体实现
		4、接口分离原则：多个用户专用接口比一个通用接口要好
		5、发布复用等价性原则：复用的粒度就是发布的粒度
		6、共同封装原则：一同变更的类应该合在一起
		7、共同复用原则：不能一起复用的类不能被分到一组
	内聚性：
		内聚是从功能的角度对模块内部聚合能力的强弱。高内聚是模块独立性追求的目标
	耦合性：
		耦合性是对一个软件结构内不同模块之间互连程度的度量。耦合性的强弱取决于模块间接口的复杂程度，已经通过 接口的数据类型和数目
	设计传统构件：
		主要任务：	
			设计每个模块的详细算法
			设计每个模块内的数据结构
		结构化程序设计方法特点：
			以控制结构为单位，单入口单出口
			从上到下顺序的阅读程序文本
			由于程序的静态描述与执行时的控制流程容易对应，所以能够方便的理解程序
	处理逻辑表示的工具：
		活动图、流程图
		NS图
		PAD图
		判定表、判定树
		过程设计语言PDL（伪代码）

5. 用户界面设计

	概述：
		人机界面是计算机直接与人打交道的途径，是计算机系统的重要组成部分，他的开发工作量占系统开发工作量的40-60%
	黄金规则：
		把控制权交给用户
		减少用户的记忆负担
		保持界面一致

第八章 软件测试

1. 基本概念：

	什么是软件测试：

		狭义：为了发现软件错误而执行软件的过程
		广义：在规定的条件下对程序进行操作，以发现程序错误，衡量软件质量，并对其是否能满足设计要求进行评估的过程
		测试是为了证明程序中有错误，而不是证明程序中无错误
		一个好的测试用例是指他可能发现至今尚未发现的缺陷
		一次成功的测试指的是发现了新的软件缺陷的测试
	白盒测试：（又称为结构测试）把测试对象看作一个透明的盒子，测试人员根据程序内部的逻辑结构及有关信息设计测试用例，检查程序中所有逻辑路径是否都按预定的要求正确地工作,白盒测试主要用于对模块的测试.
	黑盒测试：（又称行为测试）把测试对象看做一个黑盒子，测试人员完全不考虑程序内部的逻辑结构和内部特性，只依据程序的需求规格说明书，检查程序的功能是否符合它的功能需求,黑盒测试可用于各种测试.

2. 软件测试的分类：

	按测试方式分类
		1、静态测试（不需要执行所测试的程序，查询代码是否符合规范，对程序的数据流和控制流进行分析）
		2、动态测试（选择实际测试用例运行测试程序，模拟用户输入）
	按测试过程分类
		1、单元测试：是针对程序中的模块或构件，主要揭露编码阶段产生的错误
		2、集成测试：针对集成的软件系统，主要揭露设计阶段产生的错误
		3、确认测试：是根据软件需求规约对集成的软件进行确认，主要揭露不符合要求规约的错误
		4、系统测试：对应基于计算机系统中的软件，还需要将他集成到基于计算机系统中，并进行系统测试，以揭露不符合系统工程中对软件要求的错误
	按测试目的分类
		功能测试，健壮性测试，接口测试，性能测试，强度测试，压力测试，用户界面测试等等

3. 测试策略

	测试软件的组织
		1、开发人员
		2、独立测试人员
	测试完成的标准
		测试只能是在某个阶段告一段落。
		由于软件使用的软环境可能要永恒地变化。所以，它时刻、永远地面临考验，没有尽头。
		测试是永远也完不成的。
	测试策略：
		开始于 ‘小范围测试’ ，并移向 ‘大范围测试’
		对于传统的软件，开始集中在模块 (构件) ，之后进行模块集成
		对于面向对象的软件，当进行 ‘小范围测试’时，关注点从单个模块（传统上的）转变到面向对象的类，类封装了属性和操作，并意味着通信和协作。
	单元测试：
		指对软件中的最小可测单元进行检测和验证，如C语言中的函数，java中的类
	何时进行单元测试：一般先静态地检查代码是否符合规范，然后动态地运行代码并检查运行结果。

		时机：通常在编码完成后进行，在前期应准备，如写单元测试计划，编写测试用例、单元测试代码等。
		单元测试的依据：项目的文档
	五个基本特征：
		接口、局部数据结构、边界条件、独立路径、错误处理路径

4. 测试方法：

	白盒测试技术：
		1、逻辑覆盖法
		2、基本路径测试法
		3、循环测试方法
	黑盒测试技术：
		1、等价类划分
		2、边值分析法

第九章 软件项目管理

1. 软件质量保证

	提高软件质量最好的办法是：在开发过程中有效地防止工作成果产生缺陷，将高质量内建于开发过程之中。主要措施是“不断地提高技术水平，不断地提高规范化水平”，其实就是练内功，通称为“软件过程改进”。 
	在开发软件的时候，即使人们的技术水平很高，并且严格遵守规范，但是人非机器，总是会犯错误的，因此无法完全避免软件中的缺陷。
	当工作成果刚刚产生时马上进行质量检查，及时找出并消除工作成果中的缺陷。这种方式效果比较好，人们一般都能学会。最常用的方法是技术评审、软件测试和过程检查，已经被企业广泛采用并取得了成效。 
	什么是软件质量：应用有效的软件过程，创造有用的产品，为生产者和使用者提供明显的价值。
		1、有效的软件过程为生产高质量的软件产品奠定了基础，能够使得软件开发过程变得有序。
		2、有用的产品是指交付最终用户要求的内容、功能和特征，满足利益相关者明确提出的需求和其它隐性需求（例如，易用性）。
		3、高质量软件为软件组织和最终用户群体带来收益。