1.需求工程。P13
- 需求是任何软件开发项目的基础。
- 好的需求是项目成功开发的必要条件。
- 需求分析工作可划分为两个阶段：需求开发和需求管理。需求开发就是传统意义上的需求分析。
2.需求开发（需求分析）的目标。P13
- 与客户和其他涉众在系统的工作内容方面达成并保持一致。
- 使系统开发人员能够更清楚地了解系统需求，定义系统边界；
- 为软件实施计划提供基础；
- 为估算开发系统所需成本和时间提供基础；
- 定义系统用户的需求和目标。
3.需求开发阶段包括需求获取、需求分析、规格化说明和需求验证4个活动；需求管理包括需求跟踪管理和需求变更管理。P14
4.需求获取的内容。P14
- 收集背景资料。
- 定义项目前景和范围。
- 选择信息的来源。
- 选择获取方法，执行获取。
5.需求分析在两个层次上进行。P15
- 系统需求分析。
- 软件需求分析
6.需求分析的工作内容。P15
- 主要工作是通过建模来整合各种信息，从而使人们更好地理解问题。
- 为问题定义了一个需求集合，并进而形成一个初步的解决方案。
- 还要检查需求中存在的错误、遗漏、不一致等缺陷，并加以修正。
- 首要任务是确定递归系统边界背景分析。
7.需求规格说明。P15
- 以需求规格说明书的形式固化下来。文档化需求前，首先要定制文档模板，以及模板撰写需求文档。
- 在撰写中一方面要选择最准确的表示方式，
- 同时又要注意保证文档的良好结构和易读性。
8.需求验证。P16
- 验证的主要任务是执行验证和问题修改。
- 需求验证通过之后，会形成需求规格说明书基线文档，该文档被纳入管理配置，作为指导系统后续开发的依据。
9.需求跟踪管理。P16
- 正向跟踪
- 反向跟踪
10.需求变更管理。P17
11.软件设计（包括高层设计和详细设计）P17~P18
- 目标是构造解决方案，设计过程是把对软件的需求描述转为软件表示，这种表示能在编码开始以前对其质量做出评价。
- 关键是对软件体系结构、数据结构、过程细节以及接口这4种程序属性的确定。
12.高层设计内容。P17
- 高层设计即传统软件工程中的概要设计和体系结构设计。
- 高层设计是为了系统后续实现做准备的，因此但凡对系统影响大的因素或风险，都应该在高层设计阶段加以考虑，并给出可行的解决方案。
- 高层设计至少应包括定义相关标准、确定系统的开发与运行的软硬件环境、确定系统体系结构、模块或组件划分、数据库设计等主要活动。
- 高层设计主要讨论的问题应该是涉及面广、影响大的问题，或者对系统的关键指标影响大的纵深性问题。
13.详细设计内容。P18
- 详细设计的主要任务是选定数据结构和算法设计，完成模块或者对象设计。
- 包括的主要活动有模块的进一步细化与设计、数据迁移程序的开发、通用程序框架的设计/开发、实用工具的开发、单元测试计划的开发。
14.构造内容。P18
- 阶段目标是形成完整并经验证的程序组件集。
- 主要活动可描述为：建立测试数据库、生产代码、实施独立的单元测试。
15.测试内容。P19
- 单元测试
- 集成测试
- 系统测试
- 验收测试
16.软件维护分类。P19
- 软件更新——会导致软件产品的功能说明发生变化。
- 校正性维护——在不改变软件功能说明的前提下，修正软件中处理、性能或实现方面的错误。
- 适应性维护——在不改变软件功能说明的前提下，修正运行环境或数据环境的改变。
- 完善性维护——在不改变软件功能说明的前提下，为增强性能或可维护性而进行的维护。
17.软件项目的生存周期的主要内容。P20
- 项目启动。为确定项目的目标和范围。
- 项目规划。建立项目的基准计划。
- 项目实施。按照计划实施和监控项目。
- 项目收尾。交付产品以及总结经验教训。
18.软件项目计划内容。P22
- 确定项目的工作范围。（功能、性能、约束、界面和可靠性要求）
- 识别资源。（描述资源是什么、可用性陈述、要求使用的先后、使用多长时间）
- 软件项目评估。（确定工作量、判定需要多少人、要多少钱才能开发出这个软件）
- 做出外购决策。（自行开发、修改本单位已有的重用件、购买一个成品件并加以修改、软件外包出去）
- 编制项目计划。（参与项目的各种角色通信的范围和资源、定义风险和风险管理技术、定义费用和进度、为所有参与者提供活动途径、勾画质量保证、变更如何管理等）
19.项目风险的分类。P23
- 软件估算风险
- 商业影响风险
- 客户相关风险
- 开发技术风险
- 开发环境风险
- 开发人员风险
- 过程相关风险
20.风险管理包含的活动。P23
- 风险识别：确定项目有哪些风险，包括运行专家判断法、头脑风暴法等方法分析项目风险产生的各种原因或者影响因素，以确定风险事件及其来源
- 风险分析：比较风险大小，确定风险性质。通过对各种风险进行定性、定量的分析，包括发生概率、影响严重程度等，确定各种风险的大小及性质
- 风险评估：指定风险相应的措施和实施步骤，按照风险的大小和性质，制定相应的措施去应对相应的风险，包括风险接受、风险转移。
- 风险监控：监督、检查风险事件的发生情况及风险措施的落实情况，通过对风险事件及来源的控制和对风险计划落实情况监督，确保风险措施有效
21.软件配置管理是一种标识、组织和控制修改的技术，它作用于整个软件生存周期，其目的是使错误率降到最低并有效地提高生产率。
22.软件主要配置项SCI P24
- 操作概念
- 需求规格说明
- 设计文档
- 源代码
- 目标代码
- 测试计划
- 测试用例、测试配置和测试结束
- 维护和开发工具
- 用户手册
- 维护手册
- 接口控制文档
23.基线是经过正式评审和认可的一组软件配置项（文档或其他软件产品），此后它们将作为下一步开发工具的基础，只有通过正式的变更控制流程才能被更改。基线的作用是把各阶段的工作划分得更加明确，使本来连续的工作在这些点上断开，以便于验证和确认开发成果。
24.典型基线。P25~P26
- 计划基线
- 需求基线
- 规格说明基线
- 设计基线
- 实现基线
- 测试基线
- 操作基线
25.基线所需文档。P26
- 创建基线的事件。
- 与基线和配置控制相关联的SCI。
- 自基线创建以来，对基线所做的变更。
- 建立和更改基线以及基线中的SCI所使用的规程。
- 批准基线中SCI更改的机构应该具有的权限。
- 如何标识更改，如何将这一变更与基线和其中的SCI关联起来。
26.配置标识的最终目的是依据基线的目标，标识与该目标一致的、最重要和最关键的软件项。
27.版本控制：一个版本只要修改了一个数据就得增加一个新版本，这样存放起来会占用很多空间，于是采用增量存放的方法，只在新版本中存放修改的那一部分，使用时调出原版本临时修改。
28.配置控制：请求变更、变更评估、变更批准/拒绝、变更实现。P29
30.状态簿记的目的是及时、准确地给出软件配置项的当前状况，供相关人员了解，以加强配置管理工作。
31.最小数据集包括内容。P30
- 被批准的一个SCI的最初版本。
- 对于该SCI，所有请求的变化状态。
- 对于该SCI，所有被批准的变更的实现状态。
32.配置审计是指对于存储配置项及相关记录的软件基线库的结构、内容和设施进行检验，其目的在于验证基线是否符合描述基线的文档。
33.验证与确认（Verification and Validation， V&V ）的目标。P32
- 尽早发现和改正软件错误。
- 增强过程与产品风险的洞察力。
- 支持软件生存周期过程，确保程序性能、进度、指出的需要。
34.计划 V&V 过程主要任务。P33
- 根据项目需求的关键度确定 V&V 投入的工作量和实时 V&V 个人或组织的独立程度。
- 根据 V&V 过程投入的工作量确定是否要建立一个 V&V 软件产品的过程。
- 建立软件开发过程中的活动或软件产品的 V&V 过程。
- 基于确定的 V&V 过程，开发 V&V 实施计划。
- 执行并监控 V&V 计划。
35.软件 V&V 实施包括：合同验证、过程验证、需求验证、设计验证、编码验证、测试验证、集成验证和文档验证等部分。 P33~36
36.软件质量保证SQA（Software Quality Assurance, SQA）为了保证软件产品符合其指定的需求，软件开发过程符合已建立的计划而提供的保证过程，其工作重点更重于事前的预防。
37.SQA 过程规划主要内容。P37
- 根据项目特征建立一个适合本项目的SQA过程，来监控软件产品及其开发过程，以确保与标准、过程相符，确保软件产品、过程、使用标准的缺陷对管理者可见。
- 确保SQA过程与V&V 过程、联合评审过程和审计过程一致。
- 开发SQA过程的活动和任务计划，并在整个合同期内实施并维护已文档化的SQA计划。
- 按计划执行SQA活动和任务。
- SQA活动和任务记录要符合获取方合同的要求
- 负责保证遵守合同需求的个人应具有组织自由度和资源的调配能力，并具有允许客观评估或发起、影响、处理和验证问题的权威性。
38.软件工程过程保证活动的目标。P37~38
- 确保依照合同要求按时执行所有过程。
- 确保内部软件工程实践、开发环境、测试环节和配置库符合合同要求。
- 确保初始化合同需求分解成自合同的合理性，确保自合同的软件产品满足初始化合同的需求。
- 在遵守合同、谈判与计划方面，确保获取者和其他团体得到了所需要的支持和合作。
- 确保软件产品和过程度量遵守所建立的标准和规程。
- 确保指定的人员有足够的技能和必要的知识以满足项目需求，并接受必要的培训。
39.SQA的职责。P38
- 对所有开发计划和质量计划的完整性进行评审。
- 作为审查主持人，参与设计和代码的审查。
- 对所有测试计划是否符合标准进行评审。
- 对所有测试结果的显著样本进行评审，以确定是否按照计划执行。
- 定期审核SCM的执行情况，以确定是否符合标准。
- 参与所有项目的季度和阶段评审，如果没有合理得到相关标准和规程的要求，应对不符合项进行登记。
40.为了建立SQA功能，组织的基本框架应包括内容。P39~P40
- 质量保证实践：定义了足够的开发工具、技术、方法和标准，可用作质量保证评审的标准。
- 软件项目规划评价：如果一开始没有进行充分的质量实践规划，就不可能真正实施该评估。
- 需求评价：由于低质量的需求不可能产生高质量的产品，因此必须评审初始需求是否符合质量标准。
- 设计过程的评价：需要某种手段，确保设计遵循了规划的方法，实现了需求，且设计本身的质量已通过了独立评审。
- 软件集成和测试过程评价：建立软件质量测试规程，测试由独立的组进行，这个组应积极并能够找出问题，应及早对测试进行规划，测试本身的质量也要经过评审。
- 管理和项目控制过程内部评价：通过确认管理过程有效实施，SQA有助于确保整个组织将重点放在取得高质量的成果上。
- 质量保证规程的剪裁：应对软件质量保证计划进行剪裁，以保证每个项目的特殊需要。
41.SQA和V&V 异同点。P42
- 相同点：两者的目标都是监控项目和产品，确保客户得到符合质量保准的产品。
- 不同点：SQA是一种内部的方法，主要处理标准的符合问题和产品流的符合问题。V&V 工作关注一个项目产品的技术属性及其开发过程。
42.启动一个SQA程序的步骤。P43
- 启动SQA程序
- 表示SQA问题
- 编制SQA计划
- 建立标准
- 确定SQA功能
- 进行培训并宣传SQA程序
- 实施SQA计划
- 评价SQA程序
43.软件质量保证计划（Software Quality Assurance Plan，SQAP）要点。P45
- 目的
- 参考文件
- 管理
- 文档
- 标准、管理和约定
- 评审和审核
- 软件配置管理
- 问题报告和纠正措施
- 工具、技术和方法
- 代码控制
- 媒介控制
- 供应商控制
- 记录的收集、维护和保持
44.联合评审过程也称为里程碑评审，它是在适当的实际评估项目和产品活动的过程，包括项目管理和技术标准两方面的评审，并贯穿于整个合同周期。这一过程包括对评审过程进行规划、项目管理评审和技术评审三个活动。P46~P47
45.审核是对软件产品是否满足需求及其标准规范、过程是否遵循合同与计划独立作出的相符性评价。该活动包括审核过程计划、审核的实施。P47~P48
46.软件文档管理是软件产品的开发人员、管理人员、维护人员、用户以及其他与项目相关人员交流的基础。软件文档大致分为3类文档：软件开发类、软件工程过程类和用户类。文档过程包括以下活动：文档计划、设计与开发、制备、维护。P49~P50
47.基础设施过程主要任务是在组织级别为软件产品生存周期过程提供基础支持。包括活动：基础设施过程规划、基础设施建立、基础设施维护。P50
48.改进过程是建立、评估、度量、控制和改进软件生存周期过程的过程。包括过程建立、过程评估和过程改进。P50~P51
49.培训过程是提供并维持已培训人员的过程。这一过程包括如下活动：过程实施、培训材料开发、培训计划实施。P51~P52
50.本章小结。P52
- 需求分析、设计、构造、测试等软件开发的核心活动固然重要，但支持这些核心活动的项目管理、配置管理、验证与确认、质量保证等支持活动对提高软件产品的开发效率与保护软件开发成果等，与主要的软件开发活动同等重要，有时在这些支持活动上花费的成本可能更高。