1. 软件开发模型
瀑布模型
瀑布模型把软件开发分为三大阶段：定义阶段、开发阶段、维护阶段。
瀑布模型的最大缺点在于不能灵活应对变化的需求，瀑布模型适用于需求明确的情况。
软件测试完成后的工作产品，例如系统测试数据、系统测试结果、操作手册、安装手册等。
原型模型
先做出一个简易的原型
原型法适用于用户需求不清，需求经常变化的情况，可以帮助导出系统需求并验证需求的有效性。探索型原型的目的是弄清目标的要求，确定所希望的特性，并探讨多种方案的可行性，可以用来探索特殊的软件解决方案。
原型法能够迅速地开发出一个让用户看得出的系统框架，可以用来支持用户界面设计。
演化模型
演化模型主要针对事先不能完整定义需求的软件开发。用户可以给出待开发系统的核心需求，并且当看到核心需求实现后，能够有效地提出反馈，以支持系统的最终设计和实现。软件开发人员根据用户的需求，首先开发核心系统。当该核心系统投入运行后，用户试用之，完成他们的工作，并提出精化系统、增强系统能力的需求。软件开发人员根据用户的反馈，实施开发的迭代过程。第一迭代过程均由需求、设计、编码、测试、集成等阶段组成，为整个系统增加一个可定义的、可管理的子集。
在开发模式上采取分批循环开发的办法，每循环开发一部分的功能，它们成为这个产品的原型的新增功能。于是，设计就不断地演化出新的系统。 实际上，这个模型可看作是重复执行的多个“瀑布模型”。
“演化模型”要求开发人员有能力把项目的产品需求分解为不同组，以便分批循环开发。这种分组并不是绝对随意性的，而是要根据功能的重要性及对总体设计的基础结构的影响而作出判断。有经验指出，每个开发循环以六周到八周为适当的长度。
增量模型
增量模型，它采用的是一种“递增式”模型，它将软件产品划分称为一系列的增量构件（构件表示物理模块而不是逻辑模块），分别进行设计、编码、集成和测试。在利用增量模型进行开发时，如何进行模块的划分往往是难点所在。
V模型
喷泉模型
喷泉模型是面向对象的开发模型，每个阶段没有明确界限，各阶段同时运行。
RAD
CBSD
敏捷开发
敏捷开发模型，即3-3-5-5模型，（3个工件，3个角色，5个价值观，5个事件）
3个工件：Product Backlog、Sprint Backlog、Product Increment
3个角色：Product Owner、Scrum Master、Development Team
5个价值观：勇气 专注 承诺 尊重 开放
5个事件：Sprint、Sprint Planning、Daily Scrum、Sprint Review、Spring Retrospective
敏捷开发方法
极限编程
敏捷开发是一个大的概念。Scrum是一种敏捷方法，极限编程是敏捷开发的一种实践方法。我们可以把Scrum当作是道，则极限编程就是术，两者其实不冲突，可以结合使用，相辅相成。
Scrum更强调核心价值观，在价值观的指导下推导出的行为准则，产生一系列的Scrum活动，如每日站会、冲刺、评审、回顾会等。极限编程和Scrum是两个不同的敏捷开发方法，它们关注的是软件开发过程中的不同层次的内容。
2. 信息系统(软件)开发方法
3. 需求分析
4. 软件设计
基本原则
“模块的大小适中”原则：过大的模块可能导致系统分解不充分，其内部可能包括不同类型的功能，需要进一步划分；过小的模块将导致系统的复杂度增加，模块之间的调用过于频繁。
结构化方法的分析结果由以下几部分组成：一套分层的数据流图，一本数据词典，一组小说明（也称加工逻辑说明）、补充资料。
编写文档有助于提高软件开发的效率而不是降低。
软件文档按照其产生和使用的范围可分为开发文档，管理文档和用户文档。其中开发文档包括：软件需求说明、可行性研究报告、项目开发计划。
内聚与耦合
内聚的紧密程度从高到低排列：
功能内聚是最理想的内聚模式。
数据耦合：借助参数表传递简单数据
标记耦合：通过参数表传递记录信息（数据结构）
耦合是模块之间的相对独立性的度量。耦合取决于各个模块之间接口的复杂程度、调用模块的方式以及通过接口的信息类型。不取决于模块提供的功能数。
系统结构
概要设计
一般来说，概要设计的内容包含系统架构、模块划分、系统接口、数据设计4个方面的主要内容，不包括模块内算法设计。
5. 软件测试
测试原则与类型
测试用例设计
测试设计和测试用例在需求分析阶段撰写。
黑盒测试：黑盒测试又称为功能测试，主要检测软件的每一个功能是否能够正常使用。在测试过程中，将程序看成不能打开的黑盒子，不考虑程序内部结构和特性的基础上通过程序接口进行测试，检查程序功能是否按照设计需求以及说明书的规定能够正常打开使用。
白盒测试：白盒测试也称为结构测试，主要用于检测软件编码过程中的错误。
白盒测试的重点考点
-
语句覆盖：语句覆盖是指选择足够多的测试用例，使得运行这些测试用例时，被测程序的每个语句至少执行一次。语句覆盖是一种很弱的覆盖标准。
-
判断覆盖：判断覆盖是设计足够多的测试用例，使得程序中的每一个判断至少获得一次“真”和一次“假”，即是程序流程图中的每一个真假分支至少被执行一次。
-
路径覆盖：选取足够的测试用例，使得程序的每条可能执行到的路径都至少经过一次。路径覆盖实际上考虑了程序中各种判定结果的所有可能组合，因此是一种较强的覆盖标准。
测试阶段
单元测试：单元测试侧重于模块中的内部处理逻辑和数据结构，所有模块都通过了测试之后，把模块集成起来仍可能会出现穿越模块的数据丢失、模块之间的相互影响等问题。因此，需要模块按系统设计说明书的要求组合起来进行测试，即集成测试，以发现模块之间协作的问题。
确认测试包括：内部确认测试、Alph测试、Beta测试、验收测试、安装测试。确认测试首先要进行有效性测试以及软件配置审查，然后进行验收测试和安装测试。其中有效性测试，就是在模拟环境下，通过黑盒测试检验所开发的软件是否与需求规格说明书一致。
系统测试包括：恢复测试、安全性测试、压力测试、性能测试、可靠性测试、可用性测试、可维护性测试、安装测试。
回归测试：回归测试是在软件发生变更之后进行的测试，以发现在变更时可能引起的其他错误。
接受测试：接受测试基于客户或最终用户的规格书中的最终测试，或基于用户一段时间的使用后，看软件是否满足客户要求。
McCabe复杂度
另一种计算McCabe复杂度的方法：统计有向图中的闭环数目+1，就等于环路复杂度。
软件调试-归纳法
归纳法是指从测试所暴露的问题出发，收集所有正确或不正确的数据，分析它们之间的关系，提出假想的错误原因，用这些数据来证明或反驳，从而查出错误所在。
6. 系统运行与维护
软件维护工具辅助维护人员对软件代码及其文档进行各种维护活动。软件维护工具主要有：版本控制工具、文档分析工具、开发信息库工具、逆向工程工具、再工程工具。不包括配置管理工具。
软件文档管理指南-按阅读对象分类
LOC是Line Of Codes的缩写，指构成软件的源代码行数。LOC主要用于估算软件成本和规模。软件估算的另外一个传统参数是功能数目。
7. 软件能力成熟度模型
CMM软件能力成熟度模型是一种评价软件承接方软件能力的方法，同时它可帮助软件组织改进其软件过程。CMM分为五个级别：初始级、可重复级、已定义级、已管理级、优化级。
ISO/IEC软件质量模型
ISO/IEC软件质量模型中，质量特性及其子特性如下表所示。
| 功能性 | 可靠性 | 易用性 | 效率 | 维护性 | 可移植性 |
|---|---|---|---|---|---|
| 适合性，准确性，互用性，依从性，安全性 | 容错性，易恢复性，成熟性 | 易学性，易理解性，易操作性 | 时间特性，资源特性 | 可测试性，可修改性，稳定性，易分析性 | 适应性，易安装性，一致性，可替换性 |
8. 软件能力成熟度模型集成-CMMI
软件能力成熟度模型CMM，是一种评价软件承接方软件能力的方法，同时它可帮助软件组织改进其软件过程。CMM分为五个等级：初始级（已执行的），可重复级，已定义级，已管理级，优化级。1级（初始化）为最低级，5级（优化级）为最高级。
（已执行的）的共性目标是过程将可标识的输入工作产品转换成可标识的输出工作产品，以实现支持过程域的特定目标。
9. COCOMO II
COCOMO II是一种成本估算模型，估算选择有：对象点、功能点和源代码行。
10. 项目管理
风险管理
风险管理又称风险曝光度，测量的是资产的整个安全性风险，它将表示实际损失的可能性与表示大量可能损失的咨询结合到单一数字评估中。在形式最简单的定量性风险分析中，风险曝光度可通过将风险可能性及影响相乘算出。
风险曝光度=错误出现率（风险出现率）×错误造成损失（风险损失）。
时间管理-关键路径法
时间管理-前导图法（单代号网络图，PDM）
关键路径即工期最长的路径。
答案：D,C
项目的关键路径为从开始到结束持续时间最长的路径，也是项目的工期。
11. 配置管理
配置管理是通过技术或行政手段对软件产品及其开发过程和生命周期进行控制、规范的一系列措施。配置管理的目标是记录软件产品的演化过程，确保软件开发者在软件生命周期中各个阶段都能得到精确的产品配置。
配置管理的活动包括：制定配置管理计划、配置库管理、配置控制、配置状态报告、配置审计、发布管理和交付。
笔记总结来自：软件设计师考试教程