文章目录
第一章
软件过程基本概念
软件过程又称软件生存周期过程
软件生存命周期过程包括：
早期：
立项、需求分析、设计、编码、
测试、交付、维护、退役
又加入了：
各种管理活动、质量保证
环境基础设施配置、文档管理等活动
1994年制订了ISO12207软件生存周期过程标准，它把用于开发一个软件系统的过程分为三类：
-
主过程
-
支持过程
-
辅助过程（组织过程）
说明
-
文档：一组活动，用于记录任何其他过程所产生的特定信息
-
配置管理：一组活动，用于捕获和维护开发过程中所产生的信息和 产品，以便于后续开发
-
质量保证：一组活动，用于保证产品和相关过程与需求文档和计划保持一致
-
验证：用于检验产品的活动（正确地做事）
-
确认：用于确认产品的活动 （做正确的事）
-
联合复审：由两方使用的、评估其他活动的状态和产品的活动
-
审计：一组活动，用于确定项目与需求、计划和合同的符合程度
-
问题解决：描述了一组活动，在分析和根除存在的问题时，所要执行的活动
-
管理：组织的管理活动，包括但不限于项目管理（当它们与其他生存周期过程有关时）
-
基础设施：由一组建立生存周期过程所需要的活动组成，包括但不限于人力、资本和开销等，它涵盖了为执行
一个项目所需要的有关资源
-
过程改进：由一组用于改进任何其他过程性能的活动组成
-
培训：定义了为项目有关人员提供合适培训的活动
第二章
2.1 需求分析与管理
什么是需求分析：
2.2 设计
设计的目标是构造解决方案，关键是对软件体系结、数据结构、过程细节，以及接口性质这四种程序属性的确定。
2.3 编码
又称为软件构造，即使用编程语言编写源程序以界面工具构造出应用界面。软件一旦构造出来应及时纳入配置管理。
2.4 软件测试
测试的四个层次：
- 单元测试：工作中分别运行单元测试用例来验证各模块的实现逻辑的正确性；
- 集成测试：将已通过的单元测试的模块，按照一定的顺序逐步集成，测试其接口准确性；
- 系统测试：验证完整的软件系统在预定的硬件环境下的执行情况；
- 验收测试：客户根据系统需求和开发合同，全面验证软件系统合同的满足情况。
2.5 运行与维护
指在软件主要功能不变的同时对其进行修改的过程。
分类如下：
导致软件产品的功能说明发生改变的：软件更新
不导致~的：校正性维护、适应性维护、完善性维护。
2.6 软件项目管理
软件项目管理的基本活动：
启动 —> 规划 —> 实施 —> 收尾
什么是项目？
项目是人们通过努力，运用各种方法，将人力、材料和财务等资源组织起来，根据商业模式的相关策划安排，进行一项独立一次性或长期无限期的工作任务，以期达到由数量和质量指标所限定的目标。
工作分解结构（WBS）是把项目可交付成果和项目工作分解成较小的、更易于管理的组件的过程。
2.7 软件配置管理
软件配置管理(Software Configuration Management, SCM)是指一套管理软件开发和维护过程中所产生的各种中间软件产品的方法和规则。它是控制软件系统演变的学科。
效果：
- 记录软件产品的演化过程
- 确保软件开发者在软件生命周期中的各个阶段都能得到精确的产品配置
- 最终保证软件产品的完整性、一致性、可追溯性
基线：把各阶段的工作划分得更加明确，使本来连续的工作在这些点上断开，以便于验证和确认开发成果。
基线可为软件制品提供三种能力：
-
再生能力：能够“返回”到原先的某一时间重新制造软件系统的特定版本或再现曾经存在的开发环境。
-
可追踪能力：将需求、项目计划、测试用例以及各种软件工件关联在一起。为了实现可追踪能力，不仅需要对系统中的各种工件进行基线化，而且要对项目管理工件进行基线化。
-
报告能力：使我们能够查询任一基线中的内容以及对比不同基线的内容。基线的比较结果可以支持排错以及辅助生成新版发布说明。
版本控制：对系统不同的版本进行标识和跟踪的过程，它可以保证软件技术状态的一致性。
2.8 软件验证与确认
2.9 软件质量保证
软件质量保证（Software Quality Assurance，简称SQA）
是在软件生存周期内，为了保证软件产品符合其指定的需求，软件开发过程符合已建立的计划而提供的保证过程，其工作重点更侧重于事前的预防。
软件质量是指软件满足明确说明或者隐含的需求的程度。
- 用户需求是衡量软件质量的基础
- 除满足明确定义的需求外，还要满足隐含的需求。
引申出三个不同层次的软件质量
符合需求规格：符合开发者明确定义的目标，即产品是不是在做让它做的事情。目标是开发者定义的，并且是可以验证的。
符合用户显式需求：符合用户所明确说明的目标。目标是客户所定义的，符合目标即判断我们是不是在做我们需要做的事情。
符合用户实际需求：实际的需求包括用户明确说明的和隐含的需求。
2.10 软件文档管理
软件文档分为三大类：软件开发类、软件过程管理类、用户类
通常形成过程经历如下活动：
创建文档 —> 设计与开发文档 —> 生产和发行文档 —> 维护文档
第三章 软件生存周期模型
3.1 编码修正模型
特点：成本可能很低；易于使用；最适用于很小且简单的项目；对于一些非常小的、开发完后就会很快丢弃的软件可以采用；对于规模稍大的项目，采用这种模型危险大
3.2 瀑布模型
优点：
-
容易理解、管理成本低
-
文档产生并提供了贯穿生命期的进展过程的充分说明。允许基线和配置早期接受控制。
缺点：需要客户完整表达需求；花更多时间写没用文档；开始时难评估进度状态；过分强调基线和里程碑的文档；开发人员必须理解应用；大量的集成测试工作；直到项目结束都不能演示系统能力。
3.3 增量模型
假设需求可以分段，成为一系列增量产品，且每一真亮可以分别开发。
优点：第一个可交付版本的成本时间少；小系统承担风险小；发布快可以减少用户需求变更；允许增量投资；
不足：如果没有规划可能使后来增量不稳定；一些增量可能需要重新开发和发布；
需要明确给出“变更条款”
采用增量投资方式时，可以采用此模型，客户可以对此进行招标。开发一个具有已知需求和定义的产品时，可以使用。
3.4 统一过程模型
RUP (Rational Unified Process)是什么？
- 是一种软件工程过程，它提供了如何在开发组织中严格分配任务和职责的方法
- 是一个过程产品
- 有自己的过程框架
- 捕获了现代软件开发中的最佳实践
三大特点：用例驱动、以架构为中心、迭代和增量开发
九大工作流：业务建模工作流、需求工作流、分析设计工作流、实现工作流、测试工作流、部署工作流、配置与变更管理工作流、项目管理工作流、环境工作流
RUP的核心是解决可操作性问题，帮助开发人员尽可能少地依赖那些“不可描述的经验”。它详细的给出了每个阶段参与该过程的各种角色，然后标识在过程中，该角色创建的制品。
验证软件质量：
质量评估被内建于过程
使用客观的度量和标准
主要困难：
- 多层次持续的规划与评估
- 判断架构中关键风险的经验
- 高效率的验证和评价手段
- 多工种之间的频繁沟通
- 多版本工作产品的管理
第四章 协同过程模型
它是对RUP过程的裁剪，是基于风险的增量和迭代的开发
适合C/S、B/S结构的软件开发模型
四个阶段，每个阶段至少3次迭代，每个迭代有明确的目标和评估标准。整个项目划分为3次目标明确的增量开发。
4.1 初始阶段
总体目标：生成具有必要内容的业务案例，以证明启动项目是否是正确的。
主要工作：
- 确定系统范围
- 扩展系统构想
- 指定项目规划
- 设立评价准则
4.1.1 迭代一：确定事件与参与者
确定参与者、提取事件、建立事件表、评估首次迭代
参与者：在系统之外与系统交互的某人或某事物
事件：可以描述的、值得记录的在某一特定时间和地点发生的事情（动作）
首次迭代检查点：
- 项目规划文档中所涉及的内容是否已经确定
- 依据应用领域的相关信息确定角色及其职责
- 事件是系统必须支持的功能，它是系统需求的核心，接下来将通过定义用例满足要求
4.1.2 迭代二：用例分析与初步建模
用例：是一个参与者履行的与其行为相关的相互工作序列，它要为这个参与者提供一定的价值
4.1.3 迭代三：细化用例路径和准备系统初始架构
细化用例的基本路径，目的有二：
- 更好地理解实现某个用例可能带来的复杂度。
- 为了估算增量的发布策略即相应的时间/费用
评估迭代三：
细化的路径是否满足用户要求、确定的初步架构是否可行、增量计划是否合理、实施计划是否可行
4.2 细化阶段
总体目标：
- 以实际所能达到的最快速度定义、确认架构并将其基线化
- 设置构想的基线
- 为构造阶段的高可信度计划设定基线
- 演示说明基线架构可以在适当的时间以合理的费用支持这个构想
基本活动：
评价潜在组件，更好地理解制作/买进/重用决定，对构造阶段的成本和进度安排做出决定
迭代一：建立静态模型
迭代二：开发用户界面原型
迭代三：建立动态模型
迭代四：确定系统最终架构
4.3 构造阶段
迭代一：数据库设计与创建
迭代二：组件设计与创建
迭代三：网络设计与创建
4.4 移交阶段
速度定义、确认架构并将其基线化
- 设置构想的基线
- 为构造阶段的高可信度计划设定基线
- 演示说明基线架构可以在适当的时间以合理的费用支持这个构想
基本活动：
评价潜在组件，更好地理解制作/买进/重用决定，对构造阶段的成本和进度安排做出决定
