《系统架构设计师教程（第2版）》第5章-软件工程基础知识-07软件项目管理

1. 项目管理概述

• 概述：
  • 为了使软件项目能够按照预定的成本、进度、质量顺利完成
  • 而对人员(People)、 产品 (Product)、 过程 (Process) 和项目 (Project) 进行分析和管理的活动

必须对软件项目的工作范围、可能风险、需要资源(人、硬件/软件)、要实现的任务、经历的里程碑、花费工作量(成本)、进度安排等进行预先计划和执行

• 涉及范围：覆盖了整个软件工程过程（软件工程过程最后结束时才终止）
• 软件项目管理的特殊性
  • 首先，软件是纯知识产品，其开发进度和质量很难估计和度量，生产效率也难以预测和保证
  • 其次，软件系统的复杂性也导致了开发过程中各种风险的难以预见和控制。

2. 软件进度管理

• 进度：指对执行活动和里程碑所制定的工作计划
• 进度管理：指为了确保项目按期完成所需要的管理过程
• 软件进度管理过程包括：活动定义、活动排序、活动资源估计、活动历时估计、制定进度计划、进度控制

2.1 工作分解结构（WBS）

1）概述

• 工作分解结构 (Work Breakdown Structure) ：
  • 把一个项目按一定的原则分解成任务
  • 任务再分解成一项项工作
  • 再把一项项工作分配到每个人的日常活动中
  • 直到分解不下去为止。

即：项目→任务→工作→日常活动

工作分解结构以可交付成果为导向，对项目要素进行的分组，它归纳和定义了项目的整个工作范围，每下降一层代表对项目工作的更详细定义。 WBS总是处于计划过程的中心，也是制订进度计划、资源需求、成本预算、风险管理计划和采购计划等的重要基础。

2）工作包

• 概念：WBS树形结构中最底层的被称为工作包
  • 是最低层次的可交付成果
  • 应当由唯一主体负责完成

3）常见分解方式

• 按产品的物理结构分解
• 按产品或项目的功能分解
• 按照实施过程分解
• 按照项目的实施单位分解
• 按照项目的目标分解
• 按部分或职能进行分解

4）对任务分解的基本要求

• 工作包是可控和可管理的，不能过于复杂
• 任务分解也不能过细（树形结构不超过6层）
• 每个工作包要有一个交付成果
• 每个任务必须有明确定义的完成标准
• WBS 必须有利于责任分配

2.2 任务活动图

1）活动

经过工作分解之后，会得到一组活动任务，这是需要对每个活动进行定义，并确定活动之间的关系。

• 活动：指完成项目的各个交付成果所必须进行的各项具体活动
• 对活动的管理：需要明确每个活动的前驱、持续时间、必须完成日期、里程碑或交付成果。
  • 前驱：指的是该活动开始之前必须发生的事件或事件集
  • 持续时间：是指完成该活动的时间长度(一般单位为天或周)
  • 必须完成日期：指的是该活动必须完成的具体日期
  • 里程碑：指的是判定该活动完成的一组条件。

2）任务活动图

• 如何得到活动图：
  • 每个活动在明确了前驱、必须完成日期等内容后 —>
  • 就确定了活动之间的相互关系、前后顺序 —>
  • （根据活动顺序就）可以得到对应的任务活动图
• 作用：任务活动图是项目进度管理、项目成本管理等一系列项目管理活动的基础
• 工具：甘特图

3. 软件配置管理（SCM）

3.1 概述

• 软件配置管理 (Software Configuration Management) 是一种标识、组织和控制修改的技术
• 目标：标识变更、控制变更、确保变更正确实现并向其他有关人员报告变更
• 目的：使错误降为最小并最有效地提高生产效率

3.2 核心内容

软件配置管理核心内容包括版本控制和变更控制。

1）版本控制 (Version Control)

• 版本控制：是指对软件开发过程中各种程序代码、配置文件、说明文档等文件变更的管理
• 主要的功能：
  • 追踪文件的变更

  它将什么时候、什么人更改了文件的什么内容等信息忠实地记录下来。每一次文件的改变，文件的版本号都将增加

  • 并行开发

  软件开发往往是多人协同作业，版本控制可以有效地解决版本的同步以及不同开发者之间的开发通信问题，提高协同开发的效率。并行开发中最常见的不同版本软件的错误(Bug) 修正问题也可以通过版本控制中分支与合并的方法有效地解决。

2）变更控制 (Change Control)

• 作用：对变更进行管理，确保变更有序进行（而不是控制变更的发生）
• 引起变更的因素：
  • 来自外部的变更要求

    如客户要求修改工作范围和需求等

  • 开发过程内部的变更要求

    如:为解决测试中发现的一些错误而修改源码甚至设计

4. 软件质量管理

4.1 概述

• 软件质量：就是软件与需求相一致的程度（这些需求可以是明确的或隐含的）

• 即，软件应符合：
  • 明确叙述的功能和性能需求
  • 文档中明确描述的开发标准
  • 所有专业开发的软件都应具有的隐含特征

• 影响因素
• 产品运行：
  • 正确性
  • 健壮性
  • 效率：完成预定功能需要的资源
  • 可用性
  • 风险：是否能按计划完成任务
• 产品修改
  • 可理解性
  • 可维修性
  • 灵活性
  • 可测试性
• 产品转移
  • 可移植性
  • 可再生性
  • 互运行性

4.2 软件质量保证（SQA）

1）概述

• 软件质量保证 (Software Quality Assurance) ：
  • 是建立一套有计划，有系统的方法
  • 来向管理层保证拟定出的标准、步骤、实践和方法能够正确地被所有项目所采用
  • 它通过对软件产品和活动进行评审和审计来验证软件是合乎标准的
• 目的：使软件过程对于管理人员来说是可见的
• 目标：以独立审查的方式，从第三方的角度监控软件开发任务的执行，就软件项目是否正确遵循已制订的计划、标准和规程给开发人员和管理层提供反映产品和过程质量的信息和数据，提高项目透明度，同时辅助软件工程取得高质量的软件产品。
• 关注点：一开始就避免缺陷的产生

2）质量保证的主要目标

• 事前预防工作

例如，着重于缺陷预防而不是缺陷检查。

• 尽量在刚刚引入缺陷时即将其捕获
• 作用于过程而不是最终产品
• 贯穿于所有的活动之中（而不是只集中于一点）

3）软件质量保证的主要任务

• SQA审计与评审
  SQA审计包括对软件工作产品、软件工具和设备的审计，评价这几
  项内容是否符合组织规定的标准。 SQA评审的主要任务是保证软件工作组的活动与预定的软件
  过程一致，确保软件过程在软件产品的生产中得到遵循。
• SQA报告
  SQA人员应记录工作的结果，并写入到报告之中，发布给相关的人员。
  SQA报告的发布应遵循三条原则： SQA和高级管理者之间应有直接沟通的渠道； SQA报告必
  须发布给软件工程组，但不必发布给项目管理人员；在可能的情况下向关心软件质量的人发布
  SQA报告。
• 处理不符合问题
  这是SQA 的一个重要的任务， SQA人员要对工作过程中发现的问题进行处理及时向有关人员及高级管理者反映。

4）软件质量保证组

• 软件质量保证组
• 时间：项目开始时就一起参与建立计划、标准过程
• SQA组织要保证如下内容：
  • 选定的开发方法被采用
  • 选定的标准和规程得到采用和遵循
  • 进行独立的审查
  • 偏离标准和规程的问题得到及时的反映和处理
  • 项日定义的每个软件任务得到实际的执行

4.3 软件质量认证

质量认证用来检验整个企业的质量水平，注重软件企业的整体资质，全面考察软件企业的
整体质量体系，检验该企业是否具有设计、开发和生产符合质量要求的软件的能力。目前国内
软件企业主要采用的是ISO 9000 和能力成熟度模型 (Capability Maturity Model,CMM)。

1）ISO 9000

• 概述：
  • 是一组标准的统称（而非一个标准）

  是国际标准化组织 (ISO) 在1994年提出的概念，是指由 ISO/Tc176 (国际标准化组织质量管理和质量保证技术委员会)制定的国际标准

  • ISO 9001 包括设计、开发、生产、安装和服务等活动的质量保障模式
  • 该标准规定了质量体系的20个方面的质量要求
  • 覆盖了全部设计和开发活动。
• 作用：用于证实组织具有提供满足顾客要求和适用法规要求的产品的能力

  如果软件开发企业能够达到这些要求，表明该企业具备质量保证能力，达到了 ISO 9001 认证

• 目的：增进顾客满意

2）CMM/CMMI

• CMM
  • 软件能力成熟度模型 (Capability Maturity Model for Software)
  • 是软件生产过程标准和软件企业成熟度等级认证标准（我国大多企业使用）
  • 由美国卡内基梅隆大学软件工程研究所1987年研制成功的
  • 是一个概念模型
  • 框架和表示是刚性的（不能随意改变），但模型的解释和实现有一定弹性
• CMMI
  • 软件能力成熟度模型集成（Capability Maturity Model Integration for Software）
  • 在 CMM 的基础上发展而来的，一种软件能力成熟度评估标准
  • 作用：
    • 指导软件开发过程的改进
    • 进行软件开发能力的评估

相关内容之前的章节介绍过：

5. 软件风险管理

• 方法：要辨识风险，评估它们出现的概率及产生的影响，然后建立一个规划来管理风险
• 目标：是预防风险
• 软件项目风险：是指在软件开发过程中遇到的预算和进度等方面的问题以及这些问题对软件项目的影响

5.1 Boehm的软件风险管理体系

两大阶段：

• 风险估计：风险辨识、风险分析、风险排序
• 风险控制：风险管理计划、风险处理、风险监督
  偏重理论

5.2 Charette的风险分析和管理体系

两大阶段：

• 分析：辨识、估计、评价
• 管理：计划、控制、监督
  偏重理论

5.3 CMU-SEI风险管理体系

• 美国卡内基梅隆大学软件研究所的CMU-SEI风险管理体系
• 包括
  • SRE（Site Reliability Engineering，站点可靠性工程 ）

  负责服务的变更管理、应急响应、监控、可用性、性能、延迟、效率和容量规划，通常为流程自动化编写软件

  • CRM(Continuous Risk Management，持续风险管理)
  • TRM(Team Risk Management，团队风险管理)
  • CMM配合的软件风险管理
• 是基于实践的全面风险管理体系，并将软件需求方作为软件风险管理的要素

---