20250523打卡——软件过程管理复习笔记

• 软件过程与管理
  • 一、概论
    • 1. 软件工程的三要素
    • 2. 软件过程的定义
    • 3. 常见的软件过程分类
  • 二、软件质量管理
    • 1. 软件质量的定义（ISO）
    • 2. ISO/IEC 25010:2023 软件质量模型
      • 一级质量特性及含义：
    • 3. 朱兰质量管理三部曲
  • 三、软件项目管理
    • 1. 基本概念
    • 2. 可行性分析：净现值（NPV）的优点
      • 净现值（NPV）的定义：
      • NPV 的优点：
    • 3. 识别软件项目的活动：WBS（工作分解结构）
      • 结构特点：
    • 4. 软件工作量估计方法：常见的软件工作量估计方法
      • 主要估计方法：
      • IFPUG 功能点方法：五大类功能
    • 5. 软件项目的进度安排
      • 1. 甘特图（Gantt Chart）
      • 2. 关键路径法（Critical Path Method，CPM）
      • 3. 关键链法（Critical Chain Project Method，CCPM）
      • 4. PERT 技术（Program Evaluation and Review Technique）
    • 6. 软件项目的资源管理：资源定义，资源分配直方图
    • 7. 软件项目的风险管理：风险的定义，风险管理的框架，风险处理的方法
    • 8. 软件项目的监督与控制：挣值分析
    • 9. 软件项目的配置管理：配置管理的任务，配置项
      • 核心概念
  • 四、经典软件过程管理
    • 1. CMM/CMMI
      • (1) CMM
      • (2) CMMI
    • 2. PSP（个人软件过程）
    • 3. 软件过程模型：瀑布、快速原型、增量、螺旋、形式化、基于组件的开发优缺点
    • 4. MSF（Microsoft Solution Framework）
    • 5. RUP（统一软件开发过程）
    • 五、敏捷软件开发
      • 1. 敏捷宣言
      • 2. 常见的敏捷软件过程

软件过程与管理

一、概论

1. 软件工程的三要素

• 过程
• 方法
• 工具

2. 软件过程的定义

软件过程是用于软件开发及维护的一系列活动、方法及实践。

3. 常见的软件过程分类

• 客户-供应商过程
• 工程过程
• 支持过程
• 管理过程（重点）
• 组织过程

二、软件质量管理

1. 软件质量的定义（ISO）

软件质量是软件产品满足明确或隐含需要能力的性能和特性的总体。

• 用户需求是衡量软件质量的基础。
• 除满足明确定义的需求外，还要满足隐含的需求。

2. ISO/IEC 25010:2023 软件质量模型

一级质量特性及含义：

1. 功能适用性（Functional Suitability）

   • 产品在规定条件下使用时，提供满足预定用户明示和暗示需求功能的能力。
   • 二级特性：
     • 功能完备性
     • 功能正确性
     • 功能适合性

2. 性能效率（Performance Efficiency）

   • 产品在规定的时间和吞吐量参数内执行其功能的能力，以及在规定条件下有效利用资源的能力。
   • 二级特性：
     • 时间特性
     • 资源利用性
     • 容量

3. 兼容性（Compatibility）

   • 产品与其他产品交换信息、在共享相同环境和资源的情况下，执行其所需功能的兼容性。
   • 二级特性：
     • 共存性
     • 互操作性

4. 交互能力（Interaction Capability）

   • 产品与特定用户进行交互的能力，即用户与系统之间通过用户界面交换信息以完成预定任务的能力。

   通俗来说，就是可用性(Useability)

   • 二级特性：
     • 可辨识性
     • 易学性
     • 易操作性
     • 用户差错防御性
     • 用户粘性
     • 包容性
     • 用户支持
     • 自描述性

5. 可靠性（Reliability）

   • 产品在规定的条件下，在规定的时间内执行规定功能而不发生中断和故障的能力。
   • 二级特性：
     • 无障碍
     • 可用性
     • 容错性
     • 易恢复性

6. 安全性（Security）

   • 产品保护信息和数据的能力，使个人或其他产品拥有与其授权类型和级别相适应的数据访问权限，并抵御恶意行为者的攻击模式，强调信息安全。
   • 二级特性：
     • 保密性
     • 完整性
     • 抵抗赖性
     • 可核查性
     • 真实性
     • 耐受性

7. 可维护性（Maintainability）

   • 产品由预定维护者进行有效和高效修改的能力，即变通性。
   • 二级特性：
     • 模块化
     • 可重复使用性
     • 可分析性
     • 可修改性
     • 可测试性

8. 灵活性（Flexibility）

   • 产品适应需求、使用环境或系统环境变化的能力。
   • 二级特性：
     • 适应性
     • 可扩展性
     • 可安装性
     • 可替换性

9. 安全（Safety）

   • 产品在规定条件下避免危及人的生命、健康、财产或环境的能力，强调系统安全。
   • 二级特性：
     • 运行限制
     • 风险识别
     • 故障安全
     • 危险警告
     • 安全集成

3. 朱兰质量管理三部曲

• 质量计划（Quality Plan）：确定项目应达到的质量标准，以及如何满足质量标准的计划安排和方法。
• 质量保证（Quality Assurance，QA）：确保项目达到有关标准，而开展的有计划、有组织的工作活动。
• 质量控制（Quality Control，QC）：确定项目结果与质量标准是否相符，并及时纠正产品缺陷的过程。

三、软件项目管理

1. 基本概念

• 项目：为完成某一独特的产品、服务或成果所做的一次性努力。
• 项目管理：在项目活动中运用相关知识、技能、工具和技术满足项目的要求。
• 五大过程组（PMBOK）：启动、计划、执行、控制、收尾
• 十大知识领域：项目（集成、范围、时间、成本、质量、人力资源、沟通、风险、采购、利益相关者）管理

2. 可行性分析：净现值（NPV）的优点

净现值（NPV）的定义：

• NPV = 各期现金流入现值总和 − 各期现金流出现值总和
• 给定贴现率r,计算公式为：
  $$\text{净现值} = \frac{第\ t\ 年的值}{(1 + r)^t}$$
• 第t年的贴现因子：
  $$1/(1 + r)^t$$
• 使得净现值为0的贴现率称之为内部回报率。

NPV 的优点：

1. 考虑资金的时间价值

   • 提高了投资方案评价的科学性与经济性。

2. 反映全过程的净现金流量

   • 兼顾流动性与长期收益，体现整体投资效果。

3. 引入风险调整机制

   • 可通过调整贴现率反映投资风险：

     • 高风险 → 高贴现率
     • 低风险 → 低贴现率

3. 识别软件项目的活动：WBS（工作分解结构）

工作分解结构（WBS, Work Breakdown Structure）
是一种面向可交付成果的项目任务分组方法，用于组织和定义项目的全部工作范围，采用分级的树状结构，从整体项目目标逐层向下细化任务，是对项目由粗到细的分解过程。

结构特点：

• 上下层次之间的关系
• 注意层次的深度（一般3-5层）
• 只有最底层的叶子节点构成了项目的活动集合
• WBS可以随着项目的进展而细化

4. 软件工作量估计方法：常见的软件工作量估计方法

主要估计方法：

• 专家判断：依赖具有丰富经验的专家来估计工作量，尤其适用于对已有软件进行变更时。专家判断通常结合了已标识的过去类似项目的经验，可能结合类比法和自底向上估计法。
• 类比估计：描述实例特征，选取合适的相似度、相异度的表达式，评价相似程度，用相似的项目数据得到最终估算值。

缺点：
不能使用于早期规模不确定的情况
一般在已经有经验的狭窄领域
难于适应新项目中约束条件、技术、人员等发生重大变化的情况

• 由底向上估计：从项目的最小工作单元开始逐步累积，估算每个任务或子任务的工作量，最后汇总得出整体估计。
• 自顶向下估计：从整体项目范围开始，逐渐向下细化，依据项目的整体目标和框架做出工作量估算。

IFPUG 功能点方法：五大类功能

估计的工作量与实现无关
识别信息系统的五种不同类型的构件或功能
所有构件的加权和就是系统的功能点

在 IFPUG功能点方法 中，信息系统的工作量估算基于五大类功能点：

• 外部输入类型（EI）：系统接收的数据或控制信息，例如用户输入。
• 外部输出类型（EO）：系统产生的输出信息，通常为报告或数据输出。
• 外部查询类型（EQ）：系统对外部数据源的查询，通常没有更新操作。
• 内部逻辑文件类型（ILF）：系统内部存储的数据结构或文件，用于支持系统功能。
• 外部接口文件类型（EIF）：系统与其他外部系统或数据库的接口文件。

5. 软件项目的进度安排

1. 甘特图（Gantt Chart）

• 图形化表示项目各任务的时间安排。
• 优点：直观展示任务的开始和结束时间。
• 缺点：无法表示任务之间的逻辑依赖关系。

2. 关键路径法（Critical Path Method，CPM）

• 用于确定完成项目所需的最短时间路径，即关键路径。
• 关键路径：由项目中耗时最长的活动组成，决定了项目的总工期。
• 关键活动：关键路径上的各个活动，一旦延误将直接影响项目完成时间。
• 实际应用中只需掌握活动节点的表示。
  
  
• 缓冲期分类：
  • 空闲缓冲期：一个活动最早的完成日期与后续活动最早的开始日期之间的差。
  • 干预缓冲期：总缓冲期与空闲缓冲期的差。

3. 关键链法（Critical Chain Project Method，CCPM）

• 与已有的项目管理方法相比，它强调在制定项目计划时考虑资源的约束，在项目执行过程中进行动态管理。

• 关键链：考虑资源冲突后的最长路径，决定项目工期。

• 缓冲区设置：

  • 项目缓冲：添加在关键链尾部，用于防止整个项目延期。
  • 汇入缓冲：添加在非关键链与关键链交汇处，避免关键链被前置任务拖延。

• 步骤：

  1. 确定紧前关系，找出关键路径。
  2. 加入资源限制，得到关键链。
  3. 设置项目缓冲和汇入缓冲。
  4. 按任务时长砍掉一半计算缓冲大小（提高应对不确定性的能力）。

4. PERT 技术（Program Evaluation and Review Technique）

PERT技术是CPM的一种改进
考虑到了进度管理中的风险，将不确定性引入到了进度管理中
对活动的周期进行了三次估计，不再是CPM中的确定值

• 优点：
  活动的标准差是风险的一种度量
  可以估计项目事件完成日期的概率

• 通过三种估计时间计算任务的期望时间和标准偏差：

  • 最乐观时间（期望完成任务的最短时间, O）
  • 最可能时间（正常情况下所花的时间, M）
  • 最悲观时间（最坏可能时间, P）
  • 期望时间：E = (O + 4M + P) / 6
  • 标准差：SD = (P - O) / 6

• 步骤：

  1. 为每个任务估算三种时间并计算期望时间与标准差。
  2. 使用正向遍历法计算达到每个事件的最早时间（期望达到事件的日期）。
  3. 评估整个项目按期完成的概率，满足目标的可能性。

6. 软件项目的资源管理：资源定义，资源分配直方图

• 资源定义：资源是指执行项目所需的任何项和人。
• 资源分配直方图：资源分配直方图通过调整任务的开始时间，来实现资源的负载平衡，确保在整个项目期间资源的合理分配。

7. 软件项目的风险管理：风险的定义，风险管理的框架，风险处理的方法

• 风险的定义：风险是指一个不确定的事件或情况，若其一旦发生，会对项目的目标（如范围、进度、成本、质量）产生积极或消极的影响。

风险是未来可能发生的问题，而不是当前已经发生的事情
风险的产生一般是有原因的

• 风险的三要素：事件、事件发生的概率、事件的影响

• 风险的基本性质：

  1. 风险的客观性
  2. 风险的不确定性
  3. 风险的不利性
  4. 风险的可变性
  5. 风险的相对性
  6. 风险同利益的对称性

• 风险管理的框架：

  1. 风险识别
  2. 风险分析与优先级排序
  3. 风险策划
  4. 风险监督

• 风险处理的方法：

  1. 接受风险
  2. 规避风险
  3. 降低风险
  4. 转移风险

• 风险的分类：

  1. 参与者（Actors）风险
  2. 技术（Technology）风险
  3. 结构（Structure）风险
  4. 任务（Tasks）风险

8. 软件项目的监督与控制：挣值分析

三个数值，两个偏差，两个性能比，两个预测

指标	解释	公式	示例值
计划价值 (PV)	已计划工作的预测成本	-	200 × 5 = 1000
挣值 (EV)	已执行工作的预测成本	-	200 × 3.5 = 700
实际成本 (AC)	已执行工作的实际成本	-	1000
进度偏差 (SV)	已完成工作值与计划的工作值的差	EV - PV	700 - 1000 = -300
成本偏差 (CV)	已完成工作的预算成本和实际成本的偏差	EV - AC	700 - 1000 = -300
进度性能指标 (SPI)	进度性能的指标，反映项目是否按计划进度进行	EV / PV	700 / 1000 = 0.7
成本性能指标 (CPI)	成本性能的指标，反映项目是否按预算支出	EV / AC	700 / 1000 = 0.7
完成时间的估计值 (TEAC)	按照当前进度项目的完成时间估计	SAC / SPI	10 / 0.7 = 14.29
项目的成本预算 (EAC)	按照当前进度，项目的总支出的估计	BAC / CPI	2000 / 0.7 = 2857.14

9. 软件项目的配置管理：配置管理的任务，配置项

配置管理（SCM）的任务目标：

• 标志变更
• 控制变更
• 确保变更正确实现
• 向受变更影响的组织和个人报告变更

核心概念

配置项：
软件配置管理的对象。一个软件配置项是项目中一个特定的、可文档化的工作产品集。例如，程序、文档等。

基线：
已经正式通过复审和批准的某规约和产品，它因此可作为进一步开发的基础，并且只能通过正式的变化控制过程来改变。

软件配置控制委员会

常见的软件配置管理工具：

• GitHub
• Bitbucket
• CVS
• Subversion (SVN)
• Google Code
• Harvest

四、经典软件过程管理

1. CMM/CMMI

(1) CMM

出发点：CMM的核心理念是改善现有的软件开发过程，也适用于其他类型的过程。它强调过程的逐步改进，而非直接提供技术或方法。

体系结构：
CMM由五个成熟度级别组成，每个成熟度级别（除了级别1）包含若干个关键过程域（KPA）。这些级别的逐步提升帮助组织逐渐完善其过程管理。
每个KPA进一步细分为五个公共特征（包括执行约定、执行能力、执行活动、测量与分析、验证实施），这些公共特征包含了关键实践（KP），即每个KPA包括五类关键实践。通过实施这些关键实践，组织便能够实现对应KPA的目标。

成熟度级别：

1. 初始级
   
2. 可重复级
   
3. 已定义级
   
4. 已管理级
   
5. 优化级
   

关键过程域（KPA）：
KPA是指一组相互关联的操作活动，标识了要达到某个成熟度级别时必须满足的条件。

一个软件企业如果希望达到某一个成熟度级别，就必须完全满足该级别的关键过程域的要求，即满足每个关键过程域的目标。
CMM共有18个KPA，每一级都有自己的KPA。
KPA可以分为三大类：管理过程、组织过程和工程过程。

关键实践（KP）：
关键实践描述了对KPA的有效实施和制度化起到最重要作用的基础设施和活动。

(2) CMMI

区别：
CMMI相较于CMM，有两种表现方式：阶段式和连续式。CMMI支持两种不同的表示方法，而CMM仅有阶段式表示。

• 阶段式：CMMI将组织的所有过程域作为一个集合来看待，逐步通过各个阶段进行改进。
  
  
  
• 连续式：CMMI将每个过程域作为独立的领域来处理，可以逐个提升。
  
  
  

关系：
CMMI是CMM的扩展与改进，它在原有CMM的基础上增加了更细化的表示方法和更广泛的适用范围，提升了过程改进的灵活性和针对性。

2. PSP（个人软件过程）

结构：
PSP（个人软件过程）是一种通过对个人开发过程进行系统化管理与改进的方法，旨在提供一种由能力成熟度模型（CMM）描述的支持过程改进组织进程的个人规范，提升软件开发质量和效率。PSP包括多个阶段，强调通过个人对时间和缺陷的记录和分析来进行持续改进。
PSP是假使应用组织处于或接近CMM2级水平。

两种日志：

1. 时间日志：记录个人在各项活动中花费的时间，帮助分析和改进开发过程的效率。
2. 缺陷日志：记录开发过程中发现的缺陷，帮助追踪和分析缺陷产生的原因，进一步优化开发过程。

评审比测试有效的原因：
评审比测试更有效的原因在于，评审阶段能够更早发现错误，且修复成本较低。缺陷越早被发现，修复的成本越低。评审不仅能及早发现缺陷，还能避免后期进行大量的测试与修复，这使得评审比测试更具优势。

四个设计模板：

1. OST（操作规格模板）：对应UML的用例图和时序图，用于描述系统与外界的交互，展示用户与系统在正常和异常情况下的交互，OST一般是动态的。
2. FST（功能规格模板）：对应UML的类图，描述系统与外界的接口（类和类与类关系、外部可见的属性、外部可见的方法）。消除二义性很重要，应尽量使用形式化符号。FST一般是静态的。
3. SST（状态规格模板）：可以精确定义程序的所有状态、状态之间转换以及伴随每次状态转换的动作。SST一般是动态的。
4. LST（逻辑规格模板）：可以精确描述系统的内部逻辑状态。一般用伪代码实现。LST一般是静态的。

3. 软件过程模型：瀑布、快速原型、增量、螺旋、形式化、基于组件的开发优缺点

模型	优点	缺点	适用场景
瀑布模型	- 开发阶段清晰，流程线性，便于管理； - 强调文档，便于跟踪和沟通； - 适合需求稳定的项目。	- 各阶段固定，阶段间产生大量文档，工作量大； - 难以响应需求变更； - 早期错误可能晚些阶段才被发现，影响后续开发。	需求已明确且不易变动的项目
快速原型模型	- 促进用户与开发人员之间的沟通； - 尽早获得系统可用性反馈，帮助明确需求； - 易于调整和修改需求。	- 用户可能因原型不完善而产生疑虑； - 为快速开发可能使用未经充分验证的技术，导致质量低。	需求不明确或变动频繁的项目
增量模型	- 将产品分为多个构件逐步交付，用户可逐步看到可用版本； - 早期增量作为原型帮助明确后期需求； - 降低开发风险； - 重要功能优先交付，增加测试。	- 需要开放式体系结构，支持各个构件的逐步集成； - 难以准确定义需求，导致增量与需求映射困难，容易退化为边做边改，失去控制。	用户需求逐步明确或持续交付的项目
螺旋模型	- 风险驱动，强调风险评估与管理； - 强调重用与早期错误消除； - 质量目标优先，结合开发和维护阶段。	- 需要有丰富的风险评估经验； - 适合大型项目或企业级软件，不适用于小型项目。	高风险、高复杂度的项目
形式化方法模型	- 数学严密性和准确性，交付的软件系统具有高安全性和较少缺陷； - 精确描述系统，适合安全性要求高的项目。	- 需要开发人员具备高级技能和特殊训练； - 形式化转换费时费力，成本高； - 难以适用于交互性强的软件系统，且质量不一定理想。	安全性要求高的系统，特别是关键任务系统
基于组件的开发模型	- 强调软件复用，提升开发效率； - 通过使用开源组件加速交付； - 快速交付，降低开发成本。	- 商业组件修改受限，影响系统演化； - 可能无法灵活地满足个性化需求，影响系统长期可扩展性。	需要快速交付并且可复用组件的项目

4. MSF（Microsoft Solution Framework）

MSF（微软解决方案框架）是微软提出的一种软件开发方法论，强调团队协作和过程管理。团队被视为最小的作战单元，专注于项目的高效推进。

六个角色：

• 产品管理：负责确定产品需求和优先级，确保产品符合市场和用户需求。
• 程序管理：负责项目的整体规划与进度管理，确保项目按时交付。
• 开发：负责实现软件功能，进行编码和系统集成。
• 测试：负责质量保证和软件的功能、性能测试，确保软件无重大缺陷。
• 发布管理：负责软件的发布计划、版本控制和发布实施。
• 用户体验：关注用户界面和交互设计，确保软件易用且符合用户需求。

五个阶段：

• 构思阶段：确定项目的总体目标、愿景和范围，进行需求收集和初步规划。
• 计划阶段：详细制定项目计划，确定开发流程、资源分配、风险评估等。
• 开发阶段：执行实际的软件开发工作，包括编码、集成和单元测试。
• 稳定阶段：对软件进行功能测试、性能测试、修复缺陷，并确保系统稳定。
• 部署阶段：将软件发布到生产环境，并进行上线、用户培训和技术支持。

三个准则：MSF项目管理准则、MSF风险管理原则、MSF就绪管理准则

5. RUP（统一软件开发过程）

RUP（Rational Unified Process）是由IBM Rational提出的一个面向对象的软件工程过程框架，强调迭代开发和架构驱动的设计，适用于各种规模的软件项目。
RUP是UML的最佳实践。

主要特点：用例驱动、以构架为中心、采用迭代和增量模型

九个过程流：

• 核心过程工作流（6个）：

  • 商业建模：定义业务流程和需求，将业务需求与软件系统联系起来。
  • 需求：收集、分析并明确用户需求，确保系统符合用户预期。
  • 分析与设计：创建系统的架构和设计，进行详细的建模和分析。
  • 实现：编写代码并将设计转化为可运行的系统。
  • 测试：对软件进行功能性、性能性和安全性测试，确保产品质量。
  • 部署：将软件交付给用户并进行必要的维护和支持。

• 核心辅助工作流（3个）：

  • 配置与变更管理：确保所有的变更都得到正确管理和跟踪，保证版本控制。
  • 项目管理：管理项目的进度、成本、资源和风险。
  • 环境：提供开发、测试和部署的技术环境支持。

四个阶段：

• 初始（先启）阶段：规划项目的基础工作，包括确定项目愿景和进行需求系统初步分析。
• 细化（精化）阶段：对需求、分析和设计设计流进行详细分析，开始系统开发和测试工作。
• 构建阶段：完成软件的主要开发工作，进行集成测试、调整和修复。
• 交付（转化、产品化）阶段：完成最终的部署和交付，进行生产环境的配置和维护。

六大经验：

1. 迭代式开发

• 需求难以在早期完全确定
• 通过多次迭代逐步完善
• 降低风险并保持开发动力

2. 需求管理

• 持续的需求获取过程
• 用例驱动的方法
• 系统化组织和文档化

3. 组件化架构

• 模块化设计提高复用性
• 构建灵活可扩展的系统
• 降低系统复杂度

4. 可视化建模

• 使用UML等标准建模语言
• 直观展现系统结构和行为
• 有效管理复杂性

5. 质量验证

• 质量管控贯穿全过程
• 早期缺陷发现机制
• 持续的质量评估

6. 变更控制

• 严格的变更管理流程
• 版本控制和隔离机制
• 确保迭代过程有序进行

五、敏捷软件开发

1. 敏捷宣言

我们更重视：

• 个体和互动 高于 流程和工具
• 工作的软件 高于 详尽的文档
• 客户合作 高于 合同谈判
• 响应变化 高于 遵循计划

这意味着，尽管右项有其价值，我们更加重视左项的价值。敏捷方法鼓励灵活性、合作和及时反馈，旨在提高开发效率和软件质量。

2. 常见的敏捷软件过程

过程方法	特点	适合情况
极限编程（XP）	通过快速反馈、结对编程、持续集成、测试驱动、小型发布来提高软件质量。强调团队成员的密切协作。	适合小型、有高度责任心且自觉的团队，需求变化快，且希望快速交付功能的项目。
并行争球法（Scrum）	增量迭代开发，每个迭代周期称为Sprint（通常为2-4周）。每次Sprint结束后进行回顾，持续改进。	适用于快速变化的项目，特别是在需求不完全明确时，能够通过反复迭代逐步明确需求和开发目标。
水晶法（Crystal）	根据项目的特点（如团队规模、项目复杂度等）来选择相应的开发策略和方法，提供高度的灵活性。	适合各种规模的项目，可以根据项目的复杂度和团队情况调整敏捷实践，以最大化开发效率。