CMMI 阶段式模型
初始的：过程不可预测且缺乏控制。
已管理的：过程为项目服务。
已定义的：过程为组织服务。
定量管理的：过程已度量和控制。
优化的：集中于过程改进。
CMMI连续式模型
CL0（未完成的）：过程域未执行或未得到CL1中定义的所有目标。
CL1（已执行的）：其共性目标是过程将可标识的输入工作产品转换成可标识的输出工作产品，以实现支持过程域的特定目标。
CL2（已管理的）：其共性目标是集中于已管理的过程的制度化。
CL3（已定义级的）：其共性目标集中于已定义的过程的制度化。
CL4（定量管理的）：其共性目标集中于可定量管理的过程的制度化。
CL5（优化的）：使用量化（统计学）手段改变和优化过程域，以满足客户的改变和持续改进计划中的过程域的功效。
软件开发模型
软件过程模型习惯上也称为软件开发模型，它是软件开发全部过程、活动和任务的结构框典型的软件过程模型有瀑布模型、增量模型、演化模型(原型模型、螺旋模型)、喷泉模型基于构件的开发模型和形式化方法模型等。
极限编程
开发方法
RUP阶段
RUP在每个阶段都有主要目标,在构建阶段结束时产生“在适当的平台上集成的软件产品”
初启阶段结束时产生一个构想文档、一个有关用例模型的调查、一个初始的业务用例、一个早期的风险评估和一个可以显示阶段和迭代的项目计划等制品；
精化阶段结束时产生一个补充需求分析、一个软件架构描述和一个可执行的架构原型等制品；
构建阶段结束时的成果是一个准备交到最终用户手中的产品，包括具有最初运作能力的在适当的平台上集成的软件产品、用户手册和对当前版本的描述；
移交阶段结束时产生移交给用户产品发布版本。
敏捷开发
敏捷开发是一种以人为核心、迭代、循序渐进的开发方法，适用于小团队和小项目，具有小步快跑的思想。常见的敏捷开发方法有极限编程法、水晶法、并列争球法和自适应软件开发方法
(1)极限编程是一种轻量级的开发方法，它提出了四大价值观:沟通、简单、反馈、勇气。五大原则:快速反馈、简单性假设、逐步修改、提倡更改、优质工作。十二个最佳实践:计划游戏、隐喻、小型发布、简单设计、测试先行、重构、结对编程、集体代码所有制、持续集成、每周工作40小时、现场客户和编码标准。
(2)水晶法强调经常交付，认为每一种不同的项目都需要一套不同的策略、约定和方法论。
(3)并列争球法的核心是迭代、增量交付，按照30天进行迭代开发交付可实际运行的软件。
(4)自适应软件开发的核心是三个非线性的，重叠的开发阶段:猜测、合作、学习。
系统设计
软件设计包括体系结构设计、接口设计、数据设计和过程设计。
过程设计：系统结构部件转换成软件的过程描述。
结构设计：定义软件系统各主要部件之间的关系。
接口设计（人机界面设计）：软件内部、软件和操作系统间以及软件和人之间如何通信。
数据设计：将模型转换成数据结构的定义。好的数据设计将改善程序结构和模块划分，降低过程复杂性。
概要设计
设计软件系统总体结构：基本任务还是采用某种设计方法，将一个复杂的系统按功能划分成模块；确定每个模块的功能；确定模块之间的调用关系；确定模块之间的接口，即模块之间传递的信息；评价模块结构的质量。
数据结构及数据库设计：在需求分析阶段对数据的组成、操作约束和数据之间的关系进行了描述，概要设计阶段要加以细化，详细设计阶段则规定具体的实现细节。
编写概要设计文档：概要设计说明书、数据库设计说明书、用户手册以及修订测试计划。
评审：对设计部分是否完整地实现了需求中规定的功能、性能等要求，设计的可行性，关键的处理以及外部接口定义的正确性、有效性、各部分之间的一致性等都一一进行评审。
详细设计
对每个模块进行详细的算法设计，用某种图形、表格和语言等工具将每个模块处理过程的详细算法描述出来。
对模块内的数据结构进行设计。
对数据库进行物理设计，即确定数据库的物理结构。
其他设计：根据软件系统的类型，还可能需要进行代码设计、输入/输出格式设计，用户界面设计等。
编写详细设计说明书。
评审：对处理过程的算法和数据库的物理结构都要评审。
模块设计原则
模块之间的耦合
管道过滤器
软件测试
单元测试：其实就是开发中的测试
自顶向下集成测试：从具体到抽象，不需要编写驱动模块，需要编写桩模块
自底向上集成测试：从抽象到具体，需要编写驱动模块，不需要编写桩模块
回归测试：就是重新测试
冒烟测试：没考过。
测试技术
技术：等价类划分、边界值分析、错误推测、因果图
测试策略
自底向上驱动程序、自顶向下桩程序
测试顺序
测试方法
白盒测试覆盖测试法
覆盖率从低到高：
- 语句覆盖法：语句覆盖法要求设计足够多的测试用例，使得程序中每条语句至少被执行一次，是最基本的覆盖要求
- 分支覆盖法：又称判定覆盖法，它要求设计足够多的测试用例，使得程序中每个判定至少有一次为真值，有一次为假值，即程序中的每个分支至少执行一次，每个判断的取真、取假至少执行一次。
- 条件覆盖法：要求设计足够多的测试用例，使得判定中的每个条件获得各种可能的结果，即每个条件至少有一次为真值，有一次为假值。
- 分支条件覆盖法：又称判定条件覆盖法，要设计足够多的测试用例，使得判定中每个条件的所有可能结果至少出现一次，每个判定本身所有可能结果也至少出现一次。
- 条件组合覆盖法：要求设计足够多的测试用例，使得判定中的每个条件结果的所有可能结果至少出现一次，这样也会使得每个判定本身的所有可能结果至少出现一次。
- 路径覆盖法：要求设计足够多的测试用例，覆盖程序中所有可能的执行路径。
白盒测试原则
常见的黑盒测试方法
等价类划分：确定无效与有效等价类，设计用例尽可能多的覆盖有效类，设计用例只覆盖一个无效类。
边界值分析：处理边界情况时最容易出错，选取的测试数据应该恰好等于、稍小于或稍大于边界值。
各测试阶段的任务：
（1）验收测试：有效性测试、软件配置审查、验收测试。
（2）系统测试：恢复测试、安全性测试、强度测试、性能测试、可靠性测试和安装测试。
（3）集成测试：模块间的接口和通信。
（4）单元测试：模块接口、局部数据结构、边界条件、独立的路径、错误处理。
（5）其他测试：回归测试（修改软件后进行的测试，防止引入新的错误）。负载测试（对软件负载能力的测试）。压力测试（对软件超负荷条件下运行情况的测试）。
McCabe复杂度（重要）
V(G)=m-n+2,
其中V(G)是有向图G中的环路个数，m是G中的有向弧数，n是G中的节点数.
也可用闭环的个数+1，计算复杂性。
软件能力成熟度模型
将软件能力成熟度自低到高依次划分为5级.
第一级：初始级(Initial)；无序，随意
初始级的软件过程是无序的，项目的执行是随意甚至是混乱的。工作方式处于救火状态，不断的应对突如其来的危机；
第二级：可重复级(Repeatable)；基本的项目管理管理
建立了基本的项目管理过程来跟踪费用，进度和功能特性，制定了必要的过程纪律，能重复早先类似的应用项目取得的成功。
第三级：已定义级(Defined)；标准化，文档化
已经将软件管理核工程两方面的过程文档化，标准化，并综合成组织的标准软件过程，所有项目均使用该标准开发维护软件。
第四级：已管理级(Managed)；可预测
收集对软件过程和产品质量的详细度量，对软件过程和产品都有定量的理解和控制。
第五级：优化级(Optimizing)。优化
过程的量化反馈和先进的新思想，新技术促使过程不断改进。
软件过程改进
甘特图
PERT图
- 最早开始时间
- 最迟开始时间
- 松弛时间
如果2个节点同时指向一个节点时，2条路径计算最早开始时间后，取最大值。
如果是计算最迟时间，则取多条路径计算后的最小值。
项目活动图
项目管理工具特征
软件配置管理
软件文档
1、开发文档（开发人员）
（1）可行性研究和项目任务书
（2）需求规格说明
（3）功能规格说明
（4）设计规格说明（包括程序和数据规格说明）
（5）开发计划
（6）软件集成和测试计划
（7）质量保证计划、标准、进度
（8）安全和测试信息
2、产品文档（用户）
（1）培训手册
（2）参考手册和用户指南
（3）软件支持手册
（4）产品手册和信息广告
3、管理文档（负责人）
（1）开发过程的每个阶段的进度和进度变更的记录
（2）软件变更情况的记录
（3）相对于开发的判定记录
（4）职责定义
软件可靠性、可用性、可维护性
冗余附加技术
软件维护工具
软件维护工具：版本控制工具、文档分析工具、开发信息库工具、逆向工程工具、再工程工具
风险分析
软件维护
（1）改正性维护：识别和纠正软件错误，改正性能上的缺陷；
（2）适应性维护：外部环境数据库发生变化而去改正；
（3）完善性维护：增加新的功能与需求；
（4）预防性维护：预先提高软件的可维护性；
软件评审
质量属性及其子特性
沟通管理
1、有主程序员：n个成员小组，1个主程序员，普通程序员只需要与主程序员沟通。
沟通路径：n-1。
2、无主程序员：n个成员的项目小组，相互之间都可以沟通。
沟通路径：n（n-1）/2。
COCOMO模型
其他知识点
1.COCOMO II模型的估算选择包括：对象点、功能点、源代码行数
2.软件工程的基本要素包括方法、工具和过程
3.软件文档分为：开发文档、管理文档、产品文档；
4、需求分析确定软件要完成的功能以及非功能性要求
5、概要设计将需求转换为软件的模块划分，确定模块之前的调用关系
6、详细设计将模块进行细化，得到详细的数据结构和算法
7、编码根据详细设计进行代码的编写，得到可运行的软件，并进行单元测试
8、需求不清晰且规模不太大时，用原型化方法合适
数据处理领域的不太复杂的软件，用结构化开发比较合适
9、软件工程每一个阶段结束前，应该着重对可维护性进行复审。在系统设计阶段的复审期间，应该从容易修改、模块化和功能独立的目的出发，评价软件的结构和过程。
10、软件风险一般包含不确定性和损失两个特性
11、一个软件开发过程描述了 “谁做”、“做什么”、“怎么做”和“什么时候做”，RUP用角色来表述“谁做”
