软件过程与管理总复习

“规范”一词被解释为“明文规定或约定俗成的标准”，或理解为“用来控制或治理一个团队的一系列准则与章程，以及团队成员必须遵守的相关的规章制度”。
过程规范就是对输入/输出和活动所构成的过程进行明文规定或约定俗成的标准。软件过程规范是软件开发组织行动的准则与指南，可以依据上述各类过程的特点而建立相应的规范，如软件基本过程规范、软件支持过程规范和软件组织过程规范。

软件过程规范的建立

软件能力成熟度模型（CMM/CMMI ）
个体软件过程（PSP）
团队软件过程（TSP）
IBM-Raional 统一过程（RUP）
极限编程（eXtreme Programming，XP）
微软软件框架（MSF）

1.2.2 过程规范的内容和示例

任务规范
日常规章制度
软件工具

“责任人、参与人员、入口准则、出口准则、输入、输出和活动”等基本内容

1.2.3 过程规范的影响和作用

消极影响的存在和消除
Fred Brooks “创造力来自个人，而不是组织结构或者过程” 规范存在的必要性
过程规范的作用

帮助团队实现共同的目标
一个规范的软件过程必将能带来稳定的、高水平的过程质量
过程规范使软件组织的生产效率更高

1.3 软件生命周期的过程需求

1.3.1 软件工程过程

工程过程是软件系统、产品的定义、设计、实现以及维护的过程。

开发过程：定义并开发软件产品的活动过程，包括需求分析、软件设计和编程等。
运行过程：在规定的环境中为其用户提供运行计算机系统服务的活动过程，包括软件部署
维护过程：提供维护软件产品服务的活动过程，也就是通过软件的修改、变更，使软件系统保持合适的运行状态，这一过程包括软件产品的移植和退役。

1.3.2 软件支持过程

文档编制

明确并定义文档开发中所采用的标准、软件过程中所需要的各类文档。
详细说明所有文档的内容、目的及相关的输出产品。
根据定义的标准与已确定的计划来编写、审查、修改和发布所有文档。
按已定义的标准和具体的规则维护文档

配置管理

软件过程或项目中的配置项（如程序、文件和数据等有关内容）被标识、定义。
根据已定义的配置项建立基线，以便对更改与发布进行有效的控制，并控制配置项的存储、处理与分发，确保配置项的完全性与一致性。
记录并报告配置项的状态以及已发生变更的需求

质量保证

针对过程或项目确定质量保证活动、制定出相应的计划与进度表。
确定质量保证活动的有关标准、方法、规程与工具。
确定进行质量保证活动所需的资源、组织及其组织成员的职责。
有足够的能力确保必要的质量保证活动独立于管理者以及过程实际执行者之外进行开展和实施。
在与各类相关的计划进度保持一致的前提下，实施所制定的质量保证活动。

验证

根据需要验证的工作产品所制定的规范（如产品规格说明书）实施必要的检验活动：
有效地发现各类阶段性产品所存在的缺陷，并跟踪和消除缺陷。

确认

根据客户实际需求，确认所有工作产品相应的质量准则，并实施必需的确认活动。
提供有关证据，以证明开发出的工作产品满足或适合指定的需求。

联合评审

与客户、供应商以及其他利益相关方（或独立的第三方）对开发的活动和产品进行评估。
为联合评审的实施制定相应的计划与进度，跟踪评审活动，直至结束。

审核

判断是否与指定的需求、计划以及合同相一致。
由合适的、独立的一方来安排对产品或过程的审核工作。
以确定其是否符合特定需求

问题解决

提供及时的、有明确职责的以及文档化的方式，以确保所有发现的问题都经过相应的分析并得到解决。
提供一种相应的机制，以识别所发现的问题并根据相应的趋势采取行动。

1.3.3 软件管理过程

项目管理过程是计划、跟踪和协调项目执行及生产所需资源的管理过程。项目管理过程的活动，包括软件基本过程的范围确定、策划、执行和控制、评审和评价等。
质量管理过程是对项目产品和服务的质量加以管理，从而获得最大的客户满意度。此过程包括在项目以及组织层次上建立对产品和过程质量管理的关注
风险管理过程，在整个项目的生命周期中对风险不断的识别、诊断和分析，回避风险、降低风险或消除风险，并在项目以及组织层次上建立有效的风险管理机制
子合同商管理过程，选择合格的子合同商并对其进行管理的过程

1.3.4 软件组织过程

业务规划过程是为组织与项目成员提供对愿景的描述以及企业文化的介绍，从而使项目成员能更有效地工作。
定义过程是建立一个可重复使用的过程定义库，从而对其它过程等提供指导、约束和支持
改进过程是为了满足业务变化的需要，提高过程的效率与有效性，而对软件过程进行持续的评估、度量、控制和改善的过程
人力资源和培训过程，为项目或其它组织过程提供培训合格的人员所需的活动
基础设施过程是建立生存周期过程基础结构、为其他过程建立和维护所需基础设施的过程

1.3.5 软件客户－供应商的过程

客户－供应商过程是内部直接影响到客户、外部直接影响开发、向客户交付软件以及软件正确操作与使用的过程，包括软件获得、客户需求管理、提供软件、操作软件以及提供客户服务等5个子过程。

软件获得：

获取过程从确定需要获取的软件系统、产品或服务开始，然后制定和发布标书、选择供方和管理获取过程，直到验收软件系统、产品或服务。
该过程的成功实施会导致最终生成一个明确的合同或条约，清楚地描述出客户与供应方的期望、职责与义务。

客户需求管理：

在整个软件生命周期中，针对不断变化的客户需求加以收集、处理和跟踪，并建立软件需求的基准线，以作为项目中软件开发活动过程和产品度量和变更管理的基础

提供软件：

按客户、事先规定的要求对软件进行包装、发布与安装的活动过程

确定包装、发布以及安装软件的有关要求。
软件有效地被安装与使用。
软件达到需求定义中所规定的质量水平。

操作软件：

确定和管理由于引人并发操作软件而带来的操作上的风险。
按要求的步骤和在要求的操作环境中运行软件。
提供操作上的技术支持，以便解决操作过程个出现的问题．
确保软件（或主机系统）有足够的能力满足用户的需求

提供客户服务：

基于实施情况，确定客户所需要的支持服务。
通过提供适当的服务来满足客户的需求。
针对客户对产品本身及其相应的支持服务的满意程度进行持续的评估

1.4 软件生命周期标准

1.4.1 ISO/IEC标准体系

ISO/IEC 12207:1995-软件生存周期过程

从多个角度说明了软件生命周期各个过程中的活动，对规范软件开发过程，协调各类人员之间的关系，都具有指导作用。

ISO/IEC15504软件过程评估标准

能力确定模式，帮助评估并确定一个潜在软件供应商的能力。
过程改进模式，帮助提高软件开发过程的水平。
自我评估模式，帮助判断是否有能力承接新项目的开发。

ISO/IEC标准体系的构成

	软件过程						系统过程
原理	12207/AMD1的过程结果						15288
要素标准	12207 /14764	TR15846	TR16326	15939	14598	15910	15288标准部分
指南	TR15271	ISO9000-3	TR9294			18019	15288 指南

1.4.2 IEEE标准体系

IEEE 1074:1997 - 生命周期过程的标准。
IEEE 1540-01 - 软件风险管理。
IEEE 1517-99 - 软件复用过程。
IEEE 1219-1998 - 软件维护过程。
IEEE Std 730-2001 -软件质量保证计划。
IEEE Std 1012 - 验证与确认。 IEEE Std 1028 - 评审。

1.4.3 标准体系全貌图

1.5 软件过程建模

1.5.1 软件过程建模型

瀑布模型
螺旋模型、增量模型、迭代模型
V模型
并发过程模型
极限编程（XP）
IBM-Rational统一过程（RUP）

1.5.2 基于UML的过程建模

用户模型视图，从用户的视角来表示系统。用例（Use-case）描述使用场景，可用于用户模型视图的建模方案。
结构模型视图，从系统内部来分析数据和功能，属于静态结构建模。
行为模型视图，描述系统动态或行为方面的各种元素间交互或协作关系，属于动态结构建模。
实现模型视图，针对如何构建（实现）系统的结构和行为时的表示。
环境模型视图，表示待实现的系统环境的结构和行为。

UML图

用例模型：对应用例图、序列图、协作图、状态图和活动图
分析模型：对应类图和对象图（包括子系统和包）、序列图、协作图、状态图和活动图。
设计模型：对应类图和对象图（包括子系统和包）、序列图、协作图、状态图和活动图。
开发模型：对应配置图（包括活动类和组件）、序列图、协作图。
实现模型：对应组件图、序列图和协作图。
测试模型：测试模型引用了所有其它模型，所以使用所对应的所有视图。

从迭代的角度理解UML建模

从顺序角度理解UML建模

1.5.3 基于IDEF3的过程建模

美国空军集成计算机辅助制造（ICAM）项目基础上建立起来的，只包含3种方法——功能建模（IDEF0）、信息建模（IDEF1）和动态建模（IDEF2）。
随着信息系统的相继开发，后来又增加了不少IDEF方法，如数据建模扩展版本（IDEF1X）、过程描述获取方法（IDEF3）、面向对象的设计方法（IDEF4）、实体论（Ontology）描述获取方法（IDEF5）、设计理论（rationale）获取方法（IDEF6）、人机交互设计方法（IDEF8）、业务约束发现方法（IDEF9）、网络设计方法（IDEF14）等。

IDEF3的过程描述方法

场景描述，通过文档记录由一个组织或系统阐明的一类典型问题的一组情况以及过程赖以发生的、重复出现的背景。场景描述的主要作用，就是要把过程描述的前后关系确定下来。
对象，是那些发生在软件开发过程描述中的、任何具体的或概念的事物。对象的识别和特征抽取，有助于进行过程流描述和对象状态转换描述。

IDEF3建模图形符号

1.5.4 基于Agent的自适应软件过程模型

过程Agent，实现任务的动态分配和分布式协同。
监控Agent，负责在本地监控任务的实施。
服务Agent，封装了任务实现的方法。
活动Agent，帮助实现过程活动的动态整合。
资源Agent，封装了活动实现的角色和方法。

软件过程模型的要素

基于Agent的软件过程模型

1.5.5 基于SOA的软件过程模型

面向服务架构（Service-Oriented Architecture，SOA）是企业级的、按需连接资源的新型架构，它描述了一系列模式和指导方针来创建松耦合、依赖业务的服务。

基于SOA的软件过程模型

第2章软件过程成熟度

2.1 过程成熟度标准

3个基本概念

软件过程能力
软件过程性能
软件过程成熟度

2.1.1 软件过程不成熟的特点

软件过程能力低，不能按预定计划开发出客户满意的产品，项目拖延、费用大大超出预算已成惯例。
过程性能的不可预见性，对进度和预算估计、产品质量的目标缺乏历史数据和有效方法的客观基础，开发的进度、成本和产品的质量都难以预测。
过程的不可视性，软件过程缺乏定义、缺乏文档和缺乏跟踪，在整个软件过程中，不清楚每个阶段进出的标准、执行的方法和规则。
过程的不稳定性，实际的、具体的操作过程是在一个项目开始后临时拼凑而成，每个项目都不一样。
过程的被动性、缺乏改进的主动性。

2.1.2 软件过程成熟的标准

软件过程能力高，具有全组织范围的管理软件开发和维护过程的能力。
软件过程性能可预见性，对进度、预算和质量做出现实的和准确的估计和预测。
软件过程规范化，可遵循的标准、规则和指导性原则。
过程的一致性
过程的丰富性
过程的可视性
过程的稳定性
过程的不断改进

2.2 能力成熟度模型概述

2.2.1 CMM的基本内容

CMM是软件过程能力成熟度模型（Capacity Maturity Model，CMM）的简称，是卡耐基－梅隆大学软件工程研究所为了满足美国联邦政府评估软件供应商能力的要求，于1986年开始研究的模型，并于1991年正式推出了CMM 1.0 版。
CMM描述一条从无序的、混乱的过程到成熟的、有纪律的过程的改进途径，描绘出软件组织如何增加对软件开发和维护的过程控制，如何向软件工程和管理的优秀文化演变等方面的指导

CMM的起源和结构

CMM建立的目的。
CMM的起源
内容和结构

2.2.2 系统工程能力模型

国际系统工程委员会（International Council on Systems Engineering，INCOSE）基于各种工程标准为评估系统工程能力建立了对照表。在此期间，该对照表发展为成熟的能力模型，称为系统工程能力评估模型（Systems Engineering Capability Assessment Model，SECAM）。SECAM扩充了连续式模型——软件过程改进和能力确定模型(Software Process Improvement Capability dEtermination，SPICE)的概念，但是比SE-CMM更加明确地注重在系统工程实践上，采用EIA632标准作为过程模型设计参考的基础。

2.2.3 集成化产品开发模型

从美国国防工业协会(National Defense Industrial Association, NDIA)的许多大公司来看，IPPD概念是大型软件开发过程模型的基础，并得到国防部（Department of Defense, DOD）的鼎力相助。
IPPD强调在贯穿整个生命周期期间所有技术及业务的相关人员的参与，这些人员包括顾客、供应商以及产品和产品相关过程的开发者，涉及的业务如测试与评价、制造、支持、培训、销售、采购、财务、合同以及处置过程。

2.2.4 CMMI介绍

模型学科	源模型
软件	SW-CMM，草案版本2.0
系统工程	EIA/IS 731
集成化产品与过程开发	IPD-CMM, 版本0.98

2.3 过程成熟度级别

CMM/CMMI成熟度的5个等级

2.3.1 成熟度等级的行为特征

初始级具有明显的不成熟过程的特点
可重复级/受管理级建立了管理软件项目的方针和实施这些方针的规程，使软件项目的有效管理过程制度化，有能力去跟踪成本、进度和质量。一个有效过程可特征化为已文档化的、已实施的、可培训的和可测量的软件过程
已定义级包含一组协调的、集成的、适度定义的软件工程过程和管理过程，具有良好的文档化、标准化，使软件过程具有可视性、一致性、稳定性和可重复性，软件过程被集成为一个有机的整体
已管理级的软件过程是量化的管理过程。在上述已定义级的基础上，可以建立有关软件过程和产品质量的、一致的度量体系，采集详细的数据进行分析，从而对软件产品和过程进行有效的定量控制和管理。
优化级不断改善组织的软件过程能力和项目的过程性能，利用来自过程和来自新思想、新技术的先导性试验的定量反馈信息，使持续过程改进成为可能。为了预防缺陷出现，组织有办法识别出弱点并预先针对性地加强过程

2.3.2 理解成熟度等级

理解可重复级和已定义级 注意力逐渐从技术问题转向组织体系和管理问题
理解定量管理级和优化级

2.3.3 成熟度等级的过程特征

第2级，焦点开始集中在软件过程的管理上，一个受管理的过程则是一个可重复的过程。从管理角度可以看到一个按计划执行的并且阶段可控的、规范化的软件开发过程
第3级，通过裁剪组织的标准软件过程来建立自定义的软件过程
第4级，对软件产品的质量、开发进度和其它开发目标进行有效的评估和预测
第5级，其焦点是软件过程的持续改进

2.3.4 CMMI过程域

2.3.5 CMM和CMMI过程域的比较分析

级别

CMM 过程域

CMMI 过程域

需求管理

软件项目规划

软件项目追踪与监控

软件子合同管理

软件质量保证

软件配置管理

需求管理

项目计划

项目监督和控制

供应商合同管理

过程和产品质量管理

配置管理

度量和分析

软件过程要点

软件过程定义

培训计划

软件集成管理

软件产品工程

组间协作

同级评审

组织级过程焦点

组织级过程定义

组织级培训

集成化群组

集成化项目管理

组织级集成环境

需求开发

技术解决方案

产品集成

验证

确认

风险管理

决策分析和解决方案

过程量化管理

质量管理

项目定量管理

组织级过程性能

错误预防

技术更改管理

过程更改管理

因果分析和解决方案

组织级改革和实施

2.4 软件过程的可视性

2.5 过程能力和效能预测

2.6 软件过程框架

2.6.1 软件过程环境和过程框架

软件过程环境的内容

不同的过程对象。
不同的过程层次。
过程资源的差异。
过程文化的差异。
开发类型不同。

软件过程框架

2.6.2 软件过程文化

过程文化的类型

过程至上，奉过程为教条，一切围绕着过程，组织、质量和效率都服从于过程，过程的执行严格，过程结果可靠、稳定，认为生产的“东西”是过程的一个节点，只是全局的一部分。但效率较低，缺乏灵活性、创造性。
以过程为焦点，关注过程，强调过程的重要性，但不拘于过程，让过程服从于质量和效率、服从于组织的业务目标……
过程只能起辅助作用，人决定一切, 过程可能流于形式……

2.6.3 PSP/TSP和CMM组成的软件过程框架

PSP/TSP/CMM之间的关系

组织的过程目标

第3章软件过程的组织管理

3.1 组织过程焦点

3.1.1 组织过程焦点的基础

1. 执行约定

（1）组织应该遵循一个文档化的关于协调软件流程的制定和改进活动的组织方针
（2）高级管理人员发起对软件过程制定和改进的组织活动
（3）高级管理人员监督软件过程的制定和改进的组织活动

2. 执行能力

（1）建立一个负责整个组织的软件过程活动的工作组
（2）为软件过程活动提供足够的资源和资金
（3）组织软件过程活动的组员进行培训
（4）软件工程组和其他工程组的组员接受软件过程活动的相关培训

3.1.2 组织过程焦点的活动

3. 执行活动

（1）定期评估软件过程并根据评估结果制订相应的更改计划
（2）组织制定和维护有关软件过程和改进活动的计划
（3）协调组织的标准软件过程和项目自定义的软件过程的制定和改进工作
（4）协调组织的软件过程数据库的使用
（5）新过程、新方法、新工具的评价、监控和推广
（6）对有关组织和项目的软件过程培训进行统一管理
（7）及时将有关软件过程制定和改进的活动通知与实施软件过程相关的组和人员

3.1.3 组织过程焦点的评估

4. 度量与分析

已经完成的工作量以及实际消耗的资源与计划的比较。
每次软件过程的评估结果与以往的评估结果和建议的比较。

5. 验证实施

评审软件过程制定和改进活动的进展状态。
分析在低层次上无法解决的矛盾和问题。
各项活动的组织、实施、审核以及结果。
总结验证结果，写出总结报告并将报告发送给有关的工作组和人员。

3.2 组织过程定义

组织过程定义的目的是开发和维护一组可用的软件过程财富（software process assets）, 这些财富可以用来改进跨越各个项目的过程性能并为组织的长期发展奠定基础。
软件过程定义涉及到开发和维护组织的标准软件过程（standard software process）。

3.2.1 软件过程定义基础

组织过程定义-软件过程财富

软件过程财富可用于开发、执行和维护标准软件过程和项目定义软件过程。软件过程财富主要包含如下内容：

组织标准软件过程。
软件生命周期的描述。
过程剪裁指南和准则。
组织软件过程数据库。
软件过程的有关文档库。

组织过程定义-过程裁减

标准软件过程 ——组织标准软件过程是基本过程的可操作的定义，基本过程指导在组织中建立一个针对所有软件项目的共用的软件过程，是项目定义软件过程的基础。
项目定义软件过程 ——项目定义软件过程是指对项目所用软件过程的可操作的定义。项目定义软件过程是一个已很好特征化的和已理解的软件过程，用软件标准、规程、工具和方法予以描述。

3.2.2 剪裁标准软件过程的指南和准则

剪裁指南和准则的主要作用：

选择一个适合项目的生命周期模型。
剪裁和细化组织标准软件过程和所选择的软件生命周期，使之适合项目的具体特征。

3.3 PSP过程框架和成熟度模型

3.3.1 PSP原则和思想

3.3.2 PSP过程框架

PSP过程框架

PSP过程由一系列方法、表格、脚本等组成，用以指导软件开发人员计划、度量和管理他们的工作。

3.3.3 PSP成熟度模型

PSP成熟度模型

PSP是一个具有4个等级的成熟度框架。4个等级分别为个体度量过程、个体计划过程、个体质量管理过程和个体循环过程。

3.4 PSP设计与实践

3.4.1 PSP0/PSP0.1--------个体度量过程

3.4.2 PSP1/PSP1.1--------个体计划过程

3.4.3 PSP2/PSP2.1--------个体质量管理过程

3.4.4 PSP3--------个体循环过程

3.5 TSP的结构和启动过程

3.5.1 TSP的原则和思想

3.5.2 TSP结构

3.5.3 TSP启动过程

3.6 TSP工作流程

3.6.1 策略和计划

3.6.2 需求

3.6.3 设计和实现

3.6.4 测试和后期维护

3.5&3.6 TSP— 小组软件过程

TSP解决的主要问题：

如何规划和管理一个软件开发团队。
如何制订团队工作所需要的策略。
如何定义和确定团队中每个角色的职责。
如何为团队中每个成员分配不同的角色。
团队及其不同角色在整个开发过程的不同阶段应该做些什么，如何更好地发挥作用。
在如何协调团队成员之间的任务，并跟踪报告团队整体的任务进度。
采用哪些方法提高团队的协作能力。

TSP结构

TSP由分阶段的众多循环构成。TSP遵循交互性原则，每一阶段和循环都能在上一阶段或循环的基础上重新规划。

TSP启动过程

整个启动流程共包含了9个启动会议。当流程结束时，小组将创建详细的工作计划，并形成一个团结一致的、高效的团队。

TSP工作流程

第4章软件过程的需求管理

4.1 需求管理的模型和流程

4.1.1 软件需求工程概述

4.1.2 需求过程系统模型

所有与需求直接相关的活动统称为需求工程，需求工程分为了两个部分：需求开发和需求管理。其中，需求开发又分为了需求获取、需求分析、需求定义和需求验证4个部分，而需求管理则包含了变更控制、版本控制、需求跟踪和需求状态跟踪。

软件需求包括三个不同的层次：业务需求、用户需求和功能需求（也包括非功能需求）。

业务需求（business requirement）反映了组织机构或客户对系统、产品的概括的目标要求，它在项目视图与范围文档中予以说明。主要的目的是对企业目前的业务流程进行评估，得出一个业务前景。业务需求的确定对后面的用户需求和功能需求起到了限制作用。
用户需求(user requirement) 文档描述了用户使用系统而完成的任务的集合，用户需求在用户案例（user case）文档或方案脚本中予以说明。收集和分析用户需求是不容易的，因为很多需求是隐形的，很难获取，更难保证需求完整，而需求又是易变的，这就要求用户和开发人员进行充分地交流。
功能需求(functional requirement)定义了开发人员必须实现的软件功能，它源于用户需求。功能需求是软件需求说明书中最重要的部分之一，它在开发、测试、质量保证、项目管理以及相关项目功能中都起了重要的作用。非功能需求描述了系统展现给用户的行为和执行的操作等，包括要遵从的业务规则、人机接口、安全性和可靠性等要求。

4.2 需求开发

4.2.1 需求获取的过程和方法

需求开发的目的是通过调查与分析，获取用户需求并定义产品需求。

需求获取概述

需求获取是通过各种途径获取用户的需求信息（原始材料），产生《用户需求说明书》。

需求获取的方法

需求研讨会
头脑风暴
用例模型
访谈
角色扮演
原型法

4.2.2 基于用例的需求获取和分析

基于用例的需求获取

执行者的识别

谁使用系统的主要功能？

谁将提供、使用和删除信息？

谁负责维护、管理并保持系统正常运行？

谁会对某一特定需求感兴趣？

系统的外部资源是什么？

系统需要和哪些外部系统交互？

用例的识别

某个执行者要求系统为其提供什么功能？该执行者需要做哪些工作？

执行者需要阅读、创建、销毁、更新或存储系统中哪些（类）信息？

系统中的事件一定要告之执行者吗？执行者需要告诉系统一些什么吗？那些系统内部的事件

从功能的角度代表什么？

由于新功能的识别，执行者的日常工作被简化或效率提高了吗？

系统需要什么样的输入输出？输入在哪里？输出去往哪里？

该系统的当前情况存在哪些问题？

4.2.3 需求定义

需求定义

需求定义指的是解释涉众需求,并根据需求规模整理成对要构建系统的明确的说明。

前景文档是用一般的语言定义系统特征的文档
软件需求规格说明书是用更专业的术语定义系统特征的文档。

4.3 需求管理

4.3.1 需求确认

需求确认

如何进行需求评审？

（1）分层次评审

目标性评审
功能性评审
操作性评审

（2）分阶段评审

如何保证需求规格说明书的质量？

正确性
完备性
易理解性
一致性
可行性
健壮性
易修改性
易测试性和可修改性
易追溯性
兼容性

4.3.2 需求跟踪

需求跟踪

需求的标识
需求的属性
需求状态

正向跟踪：以用户需求为切入点，检查《用户需求说明书》或《需求规格说明书》中的每个需求是否都能在后继工作产品中找到对应点。
逆向跟踪：检查设计文档、代码、测试用例等工作产品是否都能在《需求规格说明书》中找到出处。

正向跟踪和逆向跟踪合称为“双向跟踪”。

4.3.3 需求变更控制

需求变更控制流程

需求的变更是不可避免的，因此如何有效控制需求的变化对于项目成功至关重要。

需求变更控制策略

（1）项目启动阶段的变更预防

（2）项目实施阶段的需求变更

（3）项目收尾阶段的总结

第5章软件过程的技术管理

5.1 软件过程的技术架构

5.1.1 过程技术架构的层次和内容

5.1.2 软件过程资源的管理

5.2 软件过程的问题分析和决策方法

5.2.1 过程问题解决的系统方法

5.2.2 原因分析和缺陷分析

在开发周期的每个阶段实施根本原因分析（root cause analysis），为有效开展缺陷预防活动提供依据。
通过制订原因分析计划、选择缺陷分析数据而找出原因、实施建议措施、评价变更的效果、记录数据等多个环节，最终完成这一活动。
经常使用的工具有：数据库系统、过程建模工具、统计分析包。

5.2.3 决策分析与决定

选择决策技术和结构层次，制订决策分析与决定的计划；
建立作为决策基础的评价准则；
建立并运用决策分析指导原则，确定推荐的候选方案；
选择评价方法，对照准则评价候选方案。
选择解决方案

5.3 软件过程的技术路线

5.3.1 软件项目过程的技术解决流程

制订技术解决计划。
系统定义、候选方案和评估准则。
系统操作概念和使用场景。
系统架构设计。
系统构件的详细设计。
实现设计——完成编程和单元测试。
通过复审、测试完成对系统的验证。
软件发布或部署。
软件的操作和维护。

技术解决流程示意图

5.3.2 技术解决计划的建立和实施

建立并维护技术解决的组织方针，反复进行产品构件的选择、产品和产品构件的设计以及产品构件设计的实现、验证工作。
设计技术路线，确定技术路线中关键的难题和初步的解决办法。
根据项目的规模以及财力，确定技术解决人力资源、硬件资源和技术解决工具。
技术解决方案准则应该包含对软件生命周期设计问题的处理。
为每个候选解决方案拟订产品运行和用户交互作用的时间场景。
应充分考虑新技术所带来的风险，要计划好一些应急的措施或备用的成熟的技术。

技术工具

设计规范工具。
仿真程序和建模工具。
原型设计工具。
场景定义和管理工具。
需求跟踪工具。
交互式文档编制工具。

5.3.3 开发设计

系统定义
设计标准和准则的属性
设计方法
产品构件设计
设计文档

5.3.4 编程和单元测试

主要的编程思想
推荐的编程方法
编程准则和规范
单元测试方法
代码重构

5.3.5 验证、确认与测试

验证（verification）是指验证或检验软件是否已正确地实现了产品规格书所定义的系统功能和特性，验证过程提供证据表明，软件相关产品与所有生命周期活动的要求相一致。
确认（validation）是为了保证所生产的软件可追溯到用户需求的一系列活动，确认过程提供证据，表明软件是否满足客户需求，并解决了相应问题。
测试（testing）是为了发现软件的缺陷，减少产品质量的潜在风险。测试是实现验证活动和确认活动的最有效的手段和途径。

5.4 知识传递

纵向传递是一个具有很强时间顺序性的接力过程,指软件产品和技术知识从需求分析阶段到设计阶段、从设计阶段到编程阶段、从开发阶段到维护阶段、从产品上一个版本到当前版本的知识传递过程。
横向传递是指软件产品和技术知识在不同团队之间的传递过程
知识传递的有效方法

5.5 软件过程管理工具

5.5.1 需求管理工具

IBM-Rational AnalystStudio
Telelogic DOORS
Borland Caliber

5.5.2 面向对象的分析设计工具

IBM-Rational Rose是面向对象技术分析设计工具的代表，是可视化的建模工具
面向对象技术分析设计工具很多，如表5-5所示，其中SVG是W3C的一种图形矢量标准，可以在网上快速加载矢量图和UML图，强大的事件及脚本功能，也使得UML图具有更强的交互性和更为丰富的表达能力。

5.5.3 配置管理和变更管理工具

配置管理的主要工作包括通过创建软件配置管理库、定义配置项（包括需求、分析设计模型、代码、文档、测试用例、测试数据等）以及建立和维护软件的基线。
变更请求管理的主要工作包括控制和记录配置项内容的变更，建立和维护一个系统并使其追踪和管理变更请求及问题报告。
(1) 开源工具CVS（Concurrent Versions System，并发版本系统）是网络透明的版本控制系统。
(2) IBM-Rational ClearCase。
(3) 青鸟软件配置管理系统（简称JBCM系统）是基于构件复用的配置管理系统。
(4) IBM-Rational ClearQuest是需求变更管理工具

第6章软件过程的项目管理

6.1 软件配置管理

6.1.1 配置管理过程

软件配置管理概念

配置配置是在技术文档中明确说明最终组成软件产品的功能或物理属性。
配置项 在软件生存周期内所产生的各种应纳入管理范围的系统构成成分。包括各种管理文档和技术文档，源程序与目标代码，以及运行所需的各种数据等（配置管理的资源对象）
基线基线是评审过的一个或多个软件配置项，每一个基线都是下一步开发的出发点和基础。
配置管理库 配置管理库也称受控库，用于存储软件配置项以及相关配置管理信息。

软件配置管理流程

6.1.2 基线控制

计划基线
需求基线
设计基线
编码基线
测试基线

6.1.3版本控制

1. 版本的访问和同步控制

2. 版本的分支

3. 版本的合并

6.1.4变更控制

6.2 项目估算和资源管理

6.2.1规模度量

项目规模估算的方法

常用的规模估算方法：

(1)代码行方法

(2)功能点分析方法

(3)面向对象软件的对象点方法

其他估算方法：德尔菲法(Delphi technique)、COCOMO模型、特征点(feature point)、对象点(object point)、3-D功能点(3-D function points)、Bang度量(DeMarco's bang metric)、模糊逻辑(fuzzy logic)、标准构件法(standard component)等

6.2.2成本估算

项目成本的组成

（1）直接成本

人力成本
硬件设备
软件费用

（2）间接成本

项目管理成本
一般管理成本

项目成本的估算方法

（1）经验估算法

（2）比例法

（3）工作分解结构表

自上而下
自下而上

6.2.3资源管理

项目人力资源管理

1. 确定项目角色

角色	职能
项目经理	项目的整体计划、组织和控制。
需求人员	在整个项目中负责获取、阐述以及维护产品需求及书写文档。
设计人员	在整个项目中负责评价、选择、阐述以及维护产品设计以及书写文档。
编码人员	根据设计完成代码编写任务并修正代码中的错误。
测试人员	负责设计和编写测试用例，以及完成最后的测试执行。
质量保证人员	负责对产品的验收、检查和测试的结果进行计划、引导并做出报告。
环境维护人员	负责开发和测试环境的开发和维护。
其他	另外的角色，如文档规范人员、硬件工程师等。

2. 团队建设

项目软硬件资源管理

1. 软件资源管理

操作系统
编译器
应用软件
测试工具
……

2. 硬件资源管理

服务器
PC
……

6.3 项目风险评估

项目风险管理

6.3.1风险识别

常用的风险识别方法

检查单
文件审核
头脑风暴
德尔菲法
访谈
SWOT分析
图表分析

6.3.2风险分析和评估

定量的风险分析

量化的风险分析通常需要对事实进行更详细的分析，较之主观的风险分析往往更为可靠。

主要的量化分析方法有：比率/范围分析概率分析敏感性分析

6.4 制定项目计划

6.4.1WBS-工作分解结构

1 项目范围规划

1.1 确定项目范围
1.2 获得项目所需资金
1.3 定义预备资源
1.4 获得核心资源
1.5 项目范围规划完成

2 分析/软件需求

2.1 行为需求分析
2.2 起草初步的软件规范
2.3 制定初步预算
2.4 工作组共同审阅软件规范/预算
2.5 根据反馈修改软件规范
2.6 确定交付期限
2.7 获得开展后续工作的批准(概念、期限和预算)
2.8 获得所需资源
2.9 分析工作完成

3 设计

3.1 审阅初步的软件规范
3.2 制定功能规范
3.3 根据功能规范开发原型
3.4 审阅功能规范
3.5 根据反馈修改功能规范
3.6 获得开展后续工作的批准
3.7 设计工作完成

4 开发

4.1 审阅功能规范
4.2 确定模块化/分层设计参数
4.3 分派任务给开发人员
4.4 编写代码
4.5 开发人员测试(初步调试)
4.6 开发工作完毕

创建WBS的基本法则

每个工作工作单元在WBS只能出现一次
概要任务是对其下所有任务的总结
每个WBS的条目都有单独的人员负责
与实际要做的工作情形保持一致
建立WBS时应让项目组员参予
每个WBS条目都应备案 WBS既要灵活又要不失控制

6.4.2日程和人员安排

任务排序
时间安排

6.5 项目跟踪和监督

6.5.1项目跟踪的重要性

1. 了解成员的工作情况
2. 调整工作安排，合理利用资源
3. 促进计划内容的完善
4. 促进项目经理对人员的认识
5. 促进对项目工作量的估计
6. 统计并了解项目总体进度
7. 有利于人员考核

第7章软件过程的质量管理

7.1 质量管理概述

提前预防

7.2 软件质量方针和计划

7.2.1 软件质量方针

7.2.2 质量计划

制定质量计划的方法和技术

利益/成本分析
基准
流程图
试验设计

7.3 软件评审过程和方法

7.3.1角色和责任

7.3.2 软件评审过程

7.3.3软件评审方法

临时评审（Ad hoc review）
轮查（Passroud）
走查（Walkthrough）
小组评审（Group Review）
审查（Inspection）

7.4 缺陷分析和预防

7.4.1缺陷分析

1. 缺陷每日发展趋势

2. 缺陷分布

7.4.2 鱼骨图

7.4.3 缺陷预防

从流程上加强控制

建立和规范工作流程
过程改进

采用有效的工作方法

代码评审
单元测试

提高个人的技术水平

自我学习和提高

7.5 质量度量

质量度量的作用

有效的沟通和改进可见性。
尽早的发现和更正问题。
作出关键的权衡。
跟踪特定的项目目标。
管理风险。
有助于决策。
计划未来的项目。

7.5.1 度量要素

数据
图表
度量模型

7.5.2 基于缺陷的质量度量

1. 代码质量度量

2. 产品质量度量

3. 测试改进质量度量

4. 测试效率度量

7.6 PSP过程质量管理

7.6.1 过程质量度量

7.6.2 缺陷移除和预防

数据记录和分析
有效的设计
彻底的设计

第8章软件过程的集成管理

8.1 集成项目管理

8.1.1 项目过程的集成管理

根据多个项目的需求对组织标准过程的剪裁，构造完整的、集成的过程规范。
根据相关利益者的要求和计划，实现产品和产品构件的设计目标。
对项目进度进行安排、对资源进行分配和调度。识别、跟踪和解决问题。
综合运用上述集成的过程规范来管理项目。
协调各相关利益者的关系，并使之积极、主动参与到项目管理中来。
其它必要的项目管理内容，如风险管理、质量管理、配置管理等。
其它必要的技术活动，如需求开发、设计和验证等。

8.1.2 集成管理流程

集成管理的关键

1．项目已定义过程

顾客需求。
产品和产品构件需求。
承诺。
组织的过程需求和目标。
操作环境。
业务环境。

2．集成项目管理的核心和工具

问题跟踪和报告软件包。

群件系统，如IBM-Lotus Domino/Notes, 微软的Exchanger Server。
基于互联网的实时会议（通讯）平台。
综合决策数据库。
集成产品支持环境。

8.2 集成项目的合成计划

8.2.1 合成项目计划

合成项目计划时，要考虑本组织、顾客以及最终用户的当前的和预计的需求和目标，需纳入项目己定义过程、与相关利益者协调、融合评审/审查计划，包括各个阶段的进入/进出的评判准则。

合成项目计划的范围
合成计划的具体步骤。

8.2.2 合成项目计划的管理

利用组织过程财富库实施项目已定义过程。
运用项目已定义过程、项目计划和从属计划，监督和控制项目的活动和工作产品。
收集并分析有关的度量项目。
定期审查环境是否足以满足项目和团队间合作的需求。
定期审查项目的绩效和状态，并根据审查结果进行适当调整、协调。

8.2.3 合成项目计划的实施

管理依存关系:与那些应该参加本项目活动的相关利益者进行协调。
确保所产生的工作产品满足组织所做的承诺和项目验收的要求。对所开发的每个工作产品进行验证，如复审、评审或测试。
解决所发现的有关问题/依存关系上的问题

8.2.4 组间协调

组间协调的目标和作用
组间协调的约定和方法
组间协调的最佳实践

8.3 产品集成的过程管理

8.3.1 软件产品工程

传统产业的启示
软件产品集成的策略
软件产品工程的任务

软件产品工程的任务和约束

8.3.2 产品集成的管理流程

制订产品集成的策略和计划。
建立产品集成的过程和准则。
建立产品集成的环境。
审查接口描述的完备性并管理接口的变更。
确认集成用的产品构件已经就绪(完成测试)。
产品构件的持续集成。
验证或测试组装之后的集成产品。
交付或部署产品。

制订产品集成的策略和计划

建立并维护产品集成的策略和组织方针。
进一步完善产品集成策略和环境、产品构件接口的兼容性、集成次序和方法、集成验证标准和方法
确定产品集成需要使用的资源/工具
确定产品集成相关角色的责任、权限和人选。
培训计划。
确定产品集成的相关利益者，并确定其介入时机。
建立和维护产品集成过程的描述
制订关于《产品集成计划》的审批规程。

8.3.3 软件产品工程的实践

按照项目自定义的软件过程开展软件工程活动。
清楚前提条件。
抓住需求。
在软件过程管理中，加强对项目计划活动的质量控制。
选择并运用合适的软件工程方法和工具来构造和维护软件产品。
项目实施过程中保证软件计划、软件活动和产品之间的一致性。
加强同行评审。
有效的度量体系和充分的度量分析工作。
验证。

8.4 集成产品开发模式

8.4.1 IPD产生的背景

集成产品开发模式（Integrated Product Development, IPD）是一套针对集成化产品而研制出来的产品开发过程的管理体系，包括过程管理的思想、模式和方法。
SEI给出了IPD的标准定义——IPD是一种面向客户需求、贯穿产品生命周期的活动，能及时进行协同的、产品开发的系统方法。
IPD的思想来源于美国PRTM（Pittiglio Rabin and McGrath）公司开发的产品及周期优化法(Product And Cycle-time Excellence, PACE)，而最先将IPD付诸实践的是IBM公司。

8.4.2 产品及周期优化方法

8.4.3 IPD核心思想

产品开发是一项投资决策。
基于市场的创新和开发。
跨部门、跨系统的协同。
异步开发模式，也称并行工程。
重用。
结构化的流程。

8.4.4 IPD的过程框架模式

8.5 IPD方法应用和实践

8.5.1 IPD的方法体系

8.5.2 IPD的方法启动和建立

调研诊断需求分析及总体方案。
产品战略及规划。
研发组织结构。
研发组织切换。
研发业务流程。
研发流程切换。
薪酬及绩效管理培训开发体系。

8.5.3 市场过程管理

客户需求分析
投资组合分析
衡量指标

8.5.4 流程重整

跨部门团队
结构化流程
项目和管道管理

8.5.5 产品重整

异步开发
共用基础模块（CBB）

8.5.6 新产品开发

IPD 的有效采用和实施将给组织新产品的开发带来如下好处。

产品投入市场时间缩短40-60％。
产品开发浪费减少50-80％。
产品开发生产力提高25-30％。
新产品收益百分比增加100％。

第9章软件过程的评估和改进

9.1 过程模型的剪裁

9.1.1 软件开发组织的类型

组织独立承担某项新产品的全程开发和维护，开发过程不受外部因素影响。
组织完成所开发的软件产品的主体部分，但要将次要部分交给第三者完成或集成第三方的软件产品。
组织缺乏独立完成软件产品开发的能力，从软件承包商接受软件产品开发的子项目，接受指导下完成项目。

9.1.2 CMMI表示方法

9.1.3 模型剪裁的用途

对过程模型的剪裁，其基本用途不外乎为两类：

将剪裁模型用于内部过程改进。
将剪裁模型用于建立评估基线。

有的组织将剪裁模型用于两者，既用于过程改进，也用于建立评估基线。

9.1.4 连续式表示模型的剪裁

模型的剪裁应侧重于那些支持核心业务目标的过程域和实践。
作为基础的过程域和实践\应该要保留下来，不能舍弃。
过程改进是一种自主行为，所以过程改进的模型剪裁基本可以由组织自行确定，相对灵活。
一个组织或项目，从单个过程域或有限的几个过程域实施评估和改进，可以获得过程能力的提高，虽然其提高的程度要低于全面实施整个模型的结果,因为我们知道，各个过程域之间是相辅相成的。
从执行评估的角度看，模型剪裁的程度将直接影响评估结果的可比较程度，所以，一般要求使用相对稳定的几个剪裁版本。

9.2 软件过程度量

9.2.1 过程度量的内容

软件过程能力度量

需求管理和需求开发能力；技术解决能力、因果分析能力和决策分析能力；项目计划能力、项目监督和控制能力、合同管理能力和集成化项目管理能力；质量管理能力、配置管理能力和风险管理能力；组织级过程定义能力、组织级培训能力、组织级改革能力和产品集成能力。

软件过程性能的度量

过程效率和质量度量的结合

9.2.2 过程度量的流程

9.2.3 过程度量的方法

建立软件开发过程度量的基线，然后将获得的实际测量值与基线进行比较分析，例如获得度量值的平均值和分布情况，平均值反映了组织的整体水平或程度，而分布情况反映了组织的过程能力和执行的稳定性

9.2.4 过程度量技术

1．分析性技术: 量化证据以确定什么地方需要改进和改进工作是否成功

对比实验研究。
模拟实验研究。
过程定义评审。
正交缺陷分类。
根本原因分析。
统计过程控制。
个体软件过程。

2．基准技术

9.2.5 过程能力度量

过程能力的度量，3个参数：

Cp指数—— 过程变更程度指数。
K指数—— 过程均值和制定值的吻合程度。
Cpk指数—— 过程能力的综合指数。

Cp = σ/ P

k = (M1 - M2) / (σ/2)

Cpk ＝ (1-k) x Cp

Cpk<1 过程没有达到执行能力的最低标准。
Cpk =1 过程恰好达到最低要求。
Cpk >1 过程超过了预定的最低标准。

Cp值 vs.σ值、k值 vs. 准确性

概率

K 值范围

准确性

1.00

1.33

1.50

1.67

1.83

2.00

3.0

4.0

4.5

5.0

5.5

6.0

99.73

99.9937

99.9999943

99.9999998

k≤0.125

0.125<k≤0.250

0.250<k≤0.500

0.500<k≤0.750

k>0.750

优秀

良好

一般

较差

很差

9.2.6 软件过程生产率的度量

在现有人员的能力和历史数据分析基础之上，来测量人员的生产力水平，包括软件开发过程整体生产率（成本核算模型）、软件编程效率和软件测试效率等,例如每人日代码行、每人月功能点、每人年类数或每个类平均人天数等。

9.3 过程评估参考模型

9.3.1 ISO/IEC 15504评估模型

15504评估方法

过程尺度，最基础的可度量的过程目标，也可用于标识过程成功与否的预期结果。
过程能力尺度，是具有一系列过程属性、对任何过程的适用性、管理过程和提高过程能力时所必需的可度量特征。
能力确定模式，帮助评估并确定一个潜在软件供应商的能力。
过程改进模式，帮助提高软件开发过程的水平。
自我评估模式，帮助判断是否有能力承接新项目的开发。

15504评估等级

级别（详见表9-2）

第0级，不完善的过程

第1级，已实施的过程

第2级，已管理的（已计划和已跟踪的）过程

第3级，已建立的过程

第4级，可预测的过程

第5级，优化的过程

9.3.2 Bootstrap评估模型

它是过程改进的先决条件，用以判断软件过程的当前实施情况并且对改进的方法加以约束。 Bootstrap方法是欧洲共同体项目(ESPRIT项目5441)产生的结果
Bootstrap过程体系由过程分类、过程领域、过程和最佳实践组成。过程域由出多个过程类别组成，涵盖组织、方法和技术等3个领域,每个过程最终分解为活动和基本实践。
也分为两个层次——组织和项目
采用CMM的5个成熟度等级作为自己的能力等级，但是它们之间存在一些差异

9.3.3 Trillium评估模型

Trillium模型是由电信公司联盟基于CMM1.1版本、考虑了电信业的特殊需求而开发的，其目标是提供指导持续改进计划的方法，呈现大量的工业实践以帮助改进现有的软件过程和生命周期，即作为在竞争性商业环境中改进组织能力的指南。

依照行业内最佳实践，建立组织的产品开发和支持进程能力的基准。
作为自我评估模型，帮助软件组织在产品开发过程中识别改进的机会。
在合同的谈判阶段，帮助选择供应商。

1.没有系统化。

2.可重复和面向项目的。

3.已定义的和面向过程的。

4.已管理和一体化的。

5.合成整体

9.3.4 CMM/CMMI的评估体系

1．基于CMM的内部过程改进评估

2．基于CMM的软件能力评估

3．SCAMPI评估方法

4．组织过程的预评估

9.4 过程评估

9.4.1 软件过程评估的目标和期望

软件过程评估的目的是对当前组织内部所运行的软件过程能力和性能等状态进行准确的、客观的描述，试图发现当前过程实施的特点，标识出其中的强项与弱项，使将来发挥强项、克服弱项，更好地控制过程、改进过程，避免在质量、成本以及进度方面出现重大的问题。

能充分和各个层面、各个方面的人员沟通，获得全面的、第一手数据，确保可靠的、准确的评估结果。
评估的结果被应用于过程改进，或有助于第3方组织对本组织的认可。

评估输入和输出

输入

评估发起方、被评估组织单位及其之间的关系。
过程评估的背景、目的。
评估参考模型范围以及模型对应的表示。
评估约束、评估小组构成和收集的任何附加信息。

输出

评估最终报告：每个被评估过程域的强项和弱项的文字陈述；
对相应评估对象的定级描述。
是否达到评估输出的决定，可能要求附加的定级输出来作为评估的结果。
基于评估结果，采取行动的建议或过程改进活动计

9.4.2 软件过程评估的内容和范围

软件需求获取、分析、开发、变更控制和管理等能力
项目计划能力
项目监督和控制能力
合同管理能力
软件度量能力
软件质量保证和管理流程、手段和方法等
技术开发、革新，产品的定义、设计、实现
产品集成，项目集成管理
配置管理、维护
风险识别、控制和管理
原因分析、决策、问题解决的能力
组织变革，改进过程，建立组织商业目标
组织培训的计划和实施能力

9.4.3 软件过程评估的方式和类型

评估方式

自我评估是指由软件开发组织内部进行的评估，主要是由成员个人进行的评估行为。
第三方评估,也称为能力检测。
综合方式。

评估类型

A类评估。全面综合的评估方法，要求全面覆盖评估中所使用的模型。
B类评估。评估范围缩小，集中于需要关注的过程域。
C类评估，也称为快估。主要是检查特定的风险域，找出过程中的问题所在。

CMMI 3种评估类型的对比

特征	A类	B类	C类
用途模式	全面综合的评估方法。组织的成熟度等级的评定。	自我评估。范围小，集中于关注的过程域。	快估。检查特定的风险域
优点	覆盖全面、结果客观，能整体把握组织过程能力和清楚过程中的优势和弱势，评定等级。	发现过程问题并启动组织的过程改进，提高过程洞察力，风险小。	投入小、反馈及时、见效快。
缺点	投入大、资源需求很多、风险大。	严格性和规范性低、不够全面，不能评定等级。	深度和广度都不够，结果可信度低。
评估发起人	组织的最高管理层。	过程改进组织或质量管理部门。	任何组织内部的经理。
评估组组成	内部和外部人员。	内部或外部人员。
评估组规模	4 ～ 10人＋评估组长。	2 ～ 6人＋评估组长。	1 ～ 3人＋评估组长。
评估组资格	有经验。	有适当经验。
对评估组长的要求	主评估师。	主评估师或受过专业过程评估培训的人员。	有过程评估经验的人员

9.4.4 软件过程评估的方法

1．评估方法准则

2．选择评估时机

3．评估步骤

4．软件过程评估注意的要点

9.5 过程改进的模型和方法

9.5.1质量改进范例

9.5.2 过程改进的 IDEAL模型

IDEAL模型的两维结构

9.5.3 过程改进的 Raytheon方法

9.5.4 过程改进的 6 Sigma方法

阶段	活动要点	常用工具和技术
定义	项目启动、确定CTQ。	QFD，FMEA 流程图，亲和图。	头脑风暴法，树图排列图，CT 分解
测量	测量输出、确定项目基线。	运行图，分层法 FMEA，散布图，直方图	测量系统分析，过程能力分析水平对比法，抽样计划
分析	确定关键影响因素。	散布图，因果图多变量图	假设检验，回归分析方差分析，抽样计划
改进	设计并验证改进方案。	FMEA，试验设计田口方法	响应面法，过程仿真过程能力分析
控制	保持成果。	控制计划，SPC控制图标准操作SOP	防错方法，目标管理

DMADV方法

9.6 组织和技术革新

1．组织和技术革新的理念和原则

2．组织和技术革新的计划

3．先导性试验的重要性

4．组织和技术革新所需要的环境和支持

5．组织和技术革新的工具

6．概念培训和专题培训

7．组织和技术革新的实施步骤

8．技术革新关联的全过程活动

9.7 软件过程改进的实施

9.7.1 过程改进的原则和策略

组织过程改进实施的原则可以概括为以下8点。

软件过程改进的组织应设定切实可行的目标。
过程改进是一个持续进行的活动，而不是一次性的活动。
软件过程改进需要得到组织管理层足够的支持。
软件过程改进不只是单个组织单元)的事，而应包括软件开发过程涉及的所有团队和成员。
过程改进活动应被视为一个一个的项目，从而获得必要的预算和资源。
坚持适当的监控机制。
过程改进的成功与否取决于过程实施效果。
对改进活动的过程进行监控，鼓励创新，及时获得反馈，及时进行纠正或调整。

过程改进的策略

1．自顶向下与自底向上相结合

2．循序渐进、持续改进

3．文化变革先行

4．内外结合，以内为主

5．切合实际、区别对待

6．充分利用管理工具

9.7.2 过程改进的组织支持

管理指导委员会（MSC）
软件工程过程组（SEPG）
软件质量保证组（Software Quality Assurance Group，SQAG）
软件配置管理组（Software Configuration Management Group，SCMG）
技术工作组（TWG）和过程行动组（PAG）

9.7.3 过程改进计划

除了设定软件改进目标之外，还应包括SPI的领域、方法和策略等，并综合下列因素：

基础设施能够满足需求，及时提供资源。
对过程改进工作的方向、范围和进度提供建议。
如何识别SPI程序推进过程中的障碍和风险。
如何维持SPI程序实施的可视性。
如何鼓励信息共享或提供信息共享的方便快捷的渠道。
如何抓住和保存过程改进中的经验、教训，并改善计划本身

9.7.4 过程改进的具体实施步骤

过程改进组织的建立
确定目标
评估状态
制定计划
制定规范
过程试点
实施监控
反馈修正
过程改进成果推广

9.7.5 软件过程改进的自动化实现

TOSSP软件过程系统的内容和层次结构

第10章软件过程的管理实践

10.1 IBM-Rational 业务驱动开发的过程管理

10.1.1 RUP的迭代过程

初始阶段

主要成果是：

前景文档：对核心项目要求、关键性质、前景说明。初始的项目术语表。初始的用例模型和商业用例。项目规划，其中明确阶段和迭代，一个或多个原型。初始的风险评估和商业模型。

里程碑被评估的准则是：

相关共利益者对项目范围定义和成本/进度估计达成共识。通过主要的用例将需求无二义地表达出来。成本/进度估计、优先级、风险和开发过程的可信度。开发出来的体系结构原型的深度和广度

细化阶段

成果是：

用例模型。一些增加的需求可执行的体系结构原型及其描述。修订后的风险表和商业用例、开发用例，指定要使用的过程。整个项目的开发计划。初步的用户手册（可选）。

细化阶段被评估的准则是：

产品的前景是否稳定？体系结构是否稳定？可执行的演示是否强调了主要的风险元素，并得到解决？构造阶段的规划是否已经足够详细和准确，是否有可信度的评估支持？如果用当前的计划来开发整个系统，包括使用已定义的体系结构，是否所有相关共利益者对此都达成一致？

构造阶段

β版，至少应该包括：

在特定平台上集成的软件产品。
用户手册和对当前版本的描述。

评估准则是：

产品版本是否足够稳定和成熟，可以在用户群中发布吗？
是否所有相关共利益者都同意产品的发布？
实际的资源支出和计划的支出的比值是否仍然可接受？

交付阶段

主要工作有：

β测试，确认新系统达到用户的预期。
与被取代的旧系统并行操作，以及功能性数据库的转换。
用户和维护人员培训。
向市场、分销商和销售人员进行新产品的展示。

交付阶段侧重向用户提交软件的活动，评估准则可以非常简单，也可能极其复杂。

用户是否满意？
是否能够接受实际的和计划的资源支出的比？

10.1.2 提高过程的适应性

早期开发活动的目标应是找出不确定性，在计划中逐渐提高精确性。
把项目划分为一组迭代过程以交付产品的增量价值来获得早期的、连续的用户反馈。
利用演示和反馈来调整开发计划。
包含并管理变更。
在生命周期尽早发现关键风险，通过不断评估所面对的风险，并在下一次迭代中消除或减少已知的风险。
同步的测试和验证是减少风险的重要手段之一。

10.1.3 需求开发和质量改进

1. 定义并理解业务过程和用户需求

2. 区分项目，需求与软件能力的优先次序

3. 尽早地并且不断地测试

4. 资源的复用

5. 整个团队在整个过程中关注质量

10.1.4 架构设计和组件复用

复用的问题之一是在开发时两个组件需要知道对方的存在。基于标准的接口和独立于平台和具体实现技术的。
软件开发的目标是设计、实现并验证一个架构。
降低复杂度和改善交流的方法是利用高级工具、框架和语言。
逐步建立起测试自动化，更有效地实施持续集成策略。

10.1.5 跨团队协作

自我管理团队的概念，激励团队成员达到最好表现。
鼓励跨职能的合作。
提供有效的合作环境。
集成化的跨业务、软件和运作团队间的合作。
各司其职，积极参与质量工作。

10.1.6 过程实施的最佳实践

起始阶段
细化阶段
构建和发布阶段

10.2 微软公司的软件开发过程模式

10.2.1 MSF的过程模型

角色和任务

角色

任务

产品管理

程序管理

开发

用户体验

测试

发布管理

负责全面工作，确认用户需求，编写前景/范围说明书。

负责设计工作，概念设计，项目组织结构。

开发系统原型，技术选型，可行性分析。

收集用户在使用方面的需求和建议。

制定测试策略，建立测试标准。

运营和支持，建立运营标准。

10.2.2 MSF的团队模型

6种基本角色，即程序管理、开发、测试、发布管理、用户体验和产品管理。这些角色和实现特定的关键质量目标有直接的关系，而关键质量目标能否达到是项目成功的标志。所以，MSF 团队模型的核心是技术项目必须符合各种利益相关人的需求。

两种类型的子团队

职能团队是由职能角色组织起来的单领域子团队。开发角色常常有一个或者多个职能团队来承担。
特性团队是跨专业的子团队，把主要精力放在构建解决案的特定特性或者能力上。

原则

10.2.3 MSF过程模型的特点和原则

目标驱动而非任务驱动。
外部可见的里程碑。
应提交项的变更管理。
递进的版本发布策略。
风险驱动的进度管理。
项目组集体参与管理产品质量。

10.2.4 MSF过程模型的应用

1．为共同的愿景而工作

2．推动开放式沟通

3．赋予团队成员权力

4．建立清晰的职责和共同的责任

5．关注交付业务价值

6．保持灵巧，预测变化

7．质量投资

8．学习所有的经验

10.3 敏捷模型的软件过程管理

10.3.1 敏捷方法的过程模型

主张简单、轻装前进。
拥抱变化，这种变化是不断递增的。
可持续性，简单的说，在开发的时候就能想象到未来。
项目投资产生最大的效益或回报。
有目的的建模。
多种模型。
高质量的工作、快速反馈。
软件是项目的主要目标，文档是次要的。

极限编程生命周期

测试驱动开发

10.3.2 敏捷过程的最佳实践

编程	简单设计、测试、重构、编码标准
团队实践	代码集体所有、持续集成、隐喻、编码标准、每周40小时工作制、结对编程、小型发布
过程	现场客户、测试、计划博弈、小型发布

	起始阶段	细化阶段	构建阶段	交付阶段
需求	用户素材	小型发布	先行测试	测量
分析	CRC卡片	迭代计划	任务计划、迭代编程	计划博弈
设计	系统隐喻	单元测试	重构	持续集成
实现	编码标准	简单设计	集体代码所有权	运行所有测试

10.4 面向构件的软件过程

10.4.1 面向构件软件过程的思想

1．从传统的关注点分离到构件组装

2．以构件为中心组织软件过程。

3．高度关注可复用性和软件过程知识积累

4．高度并行的开发过程

基于构件描述的网状软件结构

10.4.2 面向构件软件过程的阶段划分

需求阶段。捕获需求、识别业务构件、归纳业务构件需求。
分析与高层设计阶段。
分析业务构件、识别服务构件，归纳服务构件的需求并完成架构设计。
并行开发与测试阶段。
提交、发布与部署阶段。应用管理。

10.5 软件过程的自定义体系

10.5.1 过程模式的对比分析

鉴于每个软件组织，无论在所属的行业、业务类型、组织规模、成熟度等方面，还是在软件产品线结构、特点、开发平台等方面，都具有自己的特点，很难直接采用某种现成的软件过程模式 CMM/CMMI、RUP、MSF、Agile和CBSP

优势、弱势和适用范围
对比分析

10.5.2 自我定义的理想管理过程

1．过程选择的原则

2．过程的具体操作建议

根据自己的特色来选择软件过程。不要过于在乎过程过轻或过重，只需要关注它是否合适，因为没有最好、只有最适合组织本身的过程模式、方法等.

一指流沙q

关注

9
点赞
踩
25

收藏

觉得还不错? 一键收藏
0
评论
软件过程与管理总复习

目录第1章软件过程规范1.1 过程的定义1.1.1 过程的定义1.1.2 软件过程的分类和组成1.1.3 软件过程定义的层次性 1.2 过程规范1.2.1 什么是过程规范1.2.2 过程规范的内容和示例 1.2.3 过程规范的影响和作用 1.3 软件生命周期的过程需求1.3.1 软件工程过程1.3.2 软件支持过程1.3.3 软件管理过程1.3.4 软件组织过程1.3.5 软件客户－供应商的过程1.4 软件生命周期标准1.4.1 ISO/IEC标准体系1.4.2 IEEE标准体系1.4.3 标准体系全貌图
复制链接

扫一扫