一、概论
1. 软件工程的三要素。
过程，方法，工具
2. 软件过程的定义。
软件过程是用于软件开发及维护的一系列活动﹑方法及实践·
3. 常见的软件过程分类。常见的软件过程。
二、软件质量管理
1. 软件质量的定义。
软件质量是软件产品满足明确或隐含需要能力的性能和特性的总体。
2. ISO/IEC 9126的结构、六个一级质量特性、一级特性对应的二级特性（理解）。
软件质量特性
软件质量子特性
软件质量度量评价准则
功能性
可靠性
易用性
效率
可维护性
可移植性
3. 朱兰质量管理三部曲。
质量计划、质量控制、质量改进
三、软件项目管理
1. 基本概念：项目；项目管理；项目管理的五大过程组；项目管理的十大知识领域。
项目：项目是为完成某一独特的产品﹑服务或成果所做的一次性努力。
项目管理：项目营理（PM)就是在项目活动中运用相关知识，技能，工具和技术满足项目的要求
项目管理五大过程组：启动，计划，执行，控制，收尾
项目管理的十大知识领域：整合管理、范围管理、时间管理、成本管理、质量管理、人力资源管理、沟通管理、风险管理、采购管理、干系人管理
2. 可行性分析：净现值的优点。
-----净利润/回收期/投资回报率在一定程度上忽视了成本和现金流的时限/收益的大小/现金的时限利息和利率。净现值NPV(利用了贴现率，第t年的值/(1+r)t)。
- 净现值是指特定方案未来现金流入量的现值和未来现金流出量的现值之间的差额。
- 优点：考虑了资金时间价值，增强了投资经济性的评价；考虑了全过程的净现金流量，体现了流动性与收益性的统一；考虑了投资风险，风险大则采用高折现率，风险小则采用低折现率。
3. 识别软件项目的活动：WBS。
任务分解结构（WBS）：是面向可交付成果的对项目任务的分组，它组织并定义了整个项目范围。它是一个分级的树型结构，是对项目由粗到细的分解过程。
- 叶子节点+中间节点是什么？
叶子节点（功能-子功能）：只有最底层的叶子节点构成了项目的活动集合。
中间结点（功能）
4. 软件工作量估计方法：常见的软件工作量估计方法，记住名称，并理解每个方法。
专家判断，类比估计，自底向上，自顶向下。
------专家判断:
类比估计：根据实例特征，评价相似程度，利用相似的项目数据得到最终估算值。
----需要有经验的领域，不能在早期规模不确定的时候使用，难以适应约束条件技术，人员等重大变化。
自底向上
自顶向下
5. 软件项目的进度安排：甘特图、关键路径法、关键链法、PERT技术。（关键路径法必须全面理解掌握，只需要掌握活动节点，活动箭头不需掌握；后两种方法了解，能够了解计算步骤）
(1) http://www.doc88.com/p-5763050345476.html
(2) https://wenku.baidu.com/view/6368fe9e51e79b8968022620.html
(3) http://www.cnitpm.com/pm/5933.html
甘特图的缺点
无法描述任务的逻辑关系，例如,活动H为何在第9周才开始，它与活动F有什么关系
关键路径--只有等项目中耗时最多最长的活动完成之后，项目才能结束。这条路径就是关键路径，组成关键路径的活动就是关键活动。
- 关键链（不考计算题，考定义步骤）与关键路径相比，它既考虑项目活动的紧前关系，又考虑资源冲突，构建网络图，得到最长路径——关键链；关键链决定了项目工期。
关键链法的步骤：
1紧前关系，得到的最长路径---关键路径 2考虑紧前关系和资源冲突，得到关键链（关键链决定了项目工期） 3加入项目缓冲和汇入缓冲；项目缓冲：放在关键链后面；汇入缓冲：放在非关键链与关键链的交汇处 4砍掉所有项目的一半计算缓冲大小
- PERT技术（不考计算题，考定义步骤）：全称：工程评估评审技术。类似于关键路径法。考虑到了进度管理中的风险，将不确定性引入了进度管理中。对活动周期进行三次估计，不再是CPM关键路径中的确定值。
PERT的步骤：
1.估计每个活动的最有可能时间，乐观时间，悲观时间，计算活动的期望周期与标准偏差。
2.正向遍历得到期望达到事件的日期
3满足目标的可能性
6. 软件项目的资源管理：资源定义，资源分配直方图。
资源定义----资源是执行项目所需要的任何项和人。
资源分配直方图通过延迟某些活动的开始日期，来平衡化资源直方图。
7. 软件项目的风险管理：风险的定义，风险管理的框架，风险处理的方法。
风险的定义---一个不确定的事件或者情况，若其一旦发生，会对项目的目标，例如，范围、进度、成本和质量，产生积极或消极的影响。
风险管理的框架---风险识别，风险分析与优先级排序，风险策划，风险监督
风险优先级，风险影响 = (可能的危害)×(发生概率)
风险处理的方法---接受风险，规避风险，降低风险，转移风险
风险的分类--4大类：参与者，技术，结构，任务
8. 软件项目的监督和控制：挣值分析。
(1) https://wenku.baidu.com/view/7bcf90280066f5335a81211b.html
(2) https://blog.csdn.net/pmpljp/article/details/19299077
挣值分析---0/100 OR 百分比
计划价值(已计划工作的预测成本)---Planned value --- PV-----200*5
挣值(已执行工作的预测成本)---Earned value ---EV-----200*3.5
实际成本(已执行工作的实际成本)--- Actual Cost ---AC----1000
进度偏差(已完成的工作值与计划的工作值的差)---Schedule Variance-- SV ---EV-PV---700-1000
成本偏差(已完成工作的预算成本和实际成本的偏差)---Cost Variance --CV --EV-AC---700-1000
进度性能指标(Schedule Performance Index, SPI): SPI = EV / PV---大于1及比预期好
成本性能指标(Cost Performance Index, CPI): CPI = EV / AC----大于1及比预期好
完成时间的估计值(按照当前进度项目的完成时间估计)---TEAC = SAC / SPI (Schedule At Completion, SAC, 项目的计划周期)--------10/0.7
项目的成本预算(按照当前的进度，项目的总支出的估计)--- EAC = BAC / CPI (Budget At Completion, BAC, 计划的项目预算)-----2000/0.7
出题另有：试画出项目的PV、AC、EV曲线，并分析项目的状态。各项任务完成的比例见表3。(完成百分比法分配挣值)
9. 软件项目的配置管理：配置管理的任务，配置项。
配置管理的任务---标志变更,控制变更,确保变更正确实现,向受变更影响的组织和个人报告变更
配置项---软件配置管理的对象，一个软件配置项是项目中一个特定的、可文档化的工作产品集。例如，程序，文档等
常见的软件配置管理软件---GitHub,Bitbucket,CVS,Subversion（SVN）,Google code
四、经典的软件过程管理
1. CMM/CMMI
CMM是一种理念，是指导思想，不是过程不是技术不是方法。
(1) CMM：出发点，体系结构，关键过程域，关键实践活动。
CMM---能力成熟度模型
CMM出发点---改善现有软件开发过程，也可用于其他过程。
CMM体系结构
CMM由5个成熟度级别组成：
每个成熟度级别（除级别1）包含了实现该级别的若干个关键过程域（KPA）
关键过程域(Key Process Area)：一系列相互关联的操作活动，标识了达到某个成熟度级别时所必须满足的条件。
CMM共有18个KPA，每一级都有自己的KPA。KPA分为三大类：管理过程、组织过程和工程过程。
每一个KPA进一步被分为称为公共特征的5个部分：执行约定、执行能力、执行活动、测量和分析、验证实施
这些公共特征包括了关键实践（KP），即每一个KPA包括5类KP
实现了这些KP后，就实现了关键过程域的目标
(2) CMMI与CMM的区别和联系，CMMI的两种表示方法。
---CMMI的两种表示方法：连续式，阶段式。
区别：连续式作为单一过程域或者过程域集合，阶段式作为整个组织已建立的一个过程域集合。CMMI和CMM区别在于：
I是intergration，集成的意思。CMM适用于软件的组织成熟度测评。CMMI适用于多种组织成熟度测评。CMMI相对CMM更完整，更适用于大环境。
一，覆盖了许多领域；到目前为止包括四个下面领域，1，软件过程（SW-CMM）;2x系统工程（SE-CMM）；3集成的产品和 进程开发（IPPD-CMM）
二，CMMI有两种表示方法，一种就是与CMM一样的阶段式表现方法（把CMMI中的若干个过程区域分成5个成熟度级别）；
另一种是连续式的表现方法（将CMMI中过程区域分为四大类，过程管理，项目管理，工程以及支持）
2. PSP：结构，两种日志，评审比测试有效的原因，四个设计模板。
日志---时间日志和缺陷日志
评审比测试有效的原因--在评审时发现的错误比测试是发现的多；成本低。缺陷发现的越早，修复的花费越低；且避免缺陷比发现和修复缺陷更有效。
四个设计模板---a操作规格模板，b功能规格模板,c状态规格模板,d逻辑规格模板
LST逻辑规格模板（无）：用于描述系统中各有机组分（方法，项，算法等）的逻辑实现。
SST状态规格模板（UML:时序图）：用于描述系统中所有可能发生的状态的集合，以及状态之间转换的条件，伴随的动作。。
FST功能规格模板（UML:类图）：描述了系统可以向用户提供对外部可见的行为说明书，以及与这些功能相关的系统行为，变量和内部关系（继承关系）。
OST操作场景模板（UML:用例图）。描述了系统与外界的交互。描述了用户与待设计系统的正常情况下和异常情况下的交互。
3. 软件过程模型：瀑布、原型、增量、螺旋、形式化、组件的优缺点。
瀑布模型
- 特点：
开发阶段严格按照线性方式进行
阶段间有因果关系
每个阶段需评审确认
允许反馈
强调文档
- 适合场所
需求易于完善定义的软件
- 缺点：
各个阶段的划分完全固定，阶段之间产生大量的文档，极大地增加了工作量；
开发过程中很难响应客户的变更要求；
早期的错误可能要等到开发后期的测试阶段才能发现，进而带来 严重的后果
快速原型模型
- 优点
l 加强用户和软件人员之间的沟通，明确系统的需求
l 尽早得到系统可用性的反馈信息，及时修改以获得完整、正确需求
- 缺陷
l 用户会由于看到的原型系统不完善，而对产品产生怀疑
l 可能为了快速开发原型系统，而采用未经充分论证的技术（如操作系统平台、主要的算法）导致质量低下
增量模型：
- 优点
l 整个产品被分解成若干个构件逐步交付，用户可以不断地看到所开发软件的可运行中间版本
l 将早期增量作为原型有助于明确后期增量的需求
l 降低开发风险
l 重要功能被首先交付，从而使其得到最多的测试
- 缺点
l 需要软件具备开放式的体系结构，以便各个构件逐步进入
l 需求难以在增量实现之前详细定义，因此增量与需求的准确映射以及所有增量的有效集成可能会比较困难，容易退化为边做边改方式，使软件过程的控制失去整体性
螺旋模型
- 优点：风险驱动
l 关注软件的重用
l 关注早期错误的消除
l 将质量目标放在首位
l 将开发阶段与维护阶段结合在一起
- 缺点
l 需要风险评估的经验
l 只适应内部大规模软件开发
形式化方法模型：
- 优点
l 由于数学方法具有严密性和准确性，形式化方法开发过程所交付的软件系统具有较少的缺陷和较高的安全性
- 缺点
l 开发人员需要具备一定技能并经过特殊训练
l 形式化描述和转换是一项费时费力的工作,成本高，质量不一定高
l 现实应用的系统大多数是交互性强的软件，但是这些系统难以用形式化方法进行描述
基于组件的开发模型：
- 优点
l 充分体现软件复用的思想
l 实现快速交付软件
l 利用开源组件与软件
- 缺点
l 商业组件的修改受到限制，影响系统的演化
4. MSF：六个角色；过程模型中的五个阶段。
MSF即微软的解决方案。团队是微软作战最小的基本单元。
项目场景中的6个角色：产品管理，程序管理，开发，测试，发布管理，用户体验。-------产程开测发用
5个阶段：构思阶段，计划阶段，开发阶段，稳定阶段，部署阶段。
------构计开稳部
5. RUP：九个软件过程，四个阶段，六大经验。
（Rational Unified Process），统一软件开发过程,面对对象的软件工程的过程框架。
- 9个过程域：6个是核心3个是辅助：
6个核心过程流：商业建模，需求，分析和设计，实现，测试，部署。
3个辅助过程流：配置和变更管理，项目管理，环境。
(商分需设，实测部)----（培根项环）
- 4个阶段：初始，细化，构造，交付。(每个阶段做什么，做完的里程碑，中间产品是什么？)
|
|
主要活动 |
里程碑 |
中间产品 |
|
起始（先启/初始）阶段 |
² 建立系统的业务模型 ² 捕获系统的基本需求 ² 确定系统的边界 ² 识别关键任务 ² 确定系统验收标准 ² 进行项目风险评估 ² 进行项目资源的估计与效益分析 ² 制定项目开发计划于重要里程碑 |
生命期目标 |
² 项目蓝图文档：系统的核心需求、关键特性与主要约束 ² 初始的用例模型（完成10%~20%） ² 初始的项目术语表 ² 业务用例模型，包括商业环境、验收标准和财政预测 ² 初始的风险评估 ² 一个可以显示阶段和迭代的项目计划 ² 一个或多个原型 ² 初始的架构文档 |
|
细化阶段（最关键的阶段） |
² 细化构想，建立对大多数关键用例的确定理解 ² 分析问题域，建立坚实的架构 ² 细化机构并选择组件 ² 捕获80%的功能需求用例 ² 精化风险评估 ² 建立可执行的软件原型 ² 定义非功能需求 ² 制定过程迭代计划和迭代的评价标准 |
生命期构架 |
² 系统架构基线 ² UML静态模型、UML动态模型、UML用例模型 ² 修订的风险评估 ² 修订的用例 ² 修订的项目计划 ² 可执行的原型 |
|
构造阶段 |
² 资源管理、资源控制和过程优化 ² 完成组件开发并根据已定义的评价准则进行测试 ² 利用构想指定的准则对发布的产品进行评估 |
初始运作功能。 构造阶段的结束时项目开发的第三个重要的里程碑。这个阶段产生的版本通常被称为β版。 |
² 可运行的软件系统 ² UML模型 ² 测试用例 ² 用户手册 ² 发布描述 |
|
交付（转化、产品化）阶段 |
² 将软件系统部署到用户环境 ² 修复软件的缺陷 ² 编制用户手册和其他文档 ² 培训用户和维护人员 ² 提供用户咨询 |
产品发布 |
² 可运行的软件产品 ² 用户手册 ² 用户支持计划 |
六大经验---迭代式开发，管理需求，基于组件的体系结构，可视化建模，验证软件质量，控制软件变更
五、敏捷软件开发
1. 敏捷宣言。
敏捷宣言-----四个核心价值十二个原则：
“注重个人及互动胜于过程和工具”
“注重可用的软件胜于详尽的文档”
“注重客户协作胜于合同谈判”
“注重响应变化胜于恪守计划”
2. 常见的敏捷软件过程，SCRUM和极限编程。
---极限编程XP
是一种全新而快捷的软件开发方法。XP团队使用现场客户、特殊计划方法和持续测试来提供快速的反馈和全面的交流。这可以帮助团队最大化地发挥他们的价值。------现场客户，计划游戏，系统隐喻，简单设计，代码集体所有，结对编程，测试驱动，小型发布，重构，持续集成，每周4小时工作制。
XP特别适合于小型的有责任心的、自觉自励的团队开发需求不确定或者迅速变化的软件
---并行争球法---Scrum---增量的迭代的开发过程
整个 开发周期包含若干个小的迭代周期，每个小的的迭代周期称为一个Sprint（2-4周）
---水晶法Crysta----每一个不同的项目都需要一套不同的策略、约定和方法论