软件过程与改进复习整理

软件开发的质量以及效率受到人员、技术和过程这三个因素的影响

软件过程理论的基石：软件产品和服务的质量，很大程度上取决于生产和维护该软件或者服务的过程的质量。

以下来自百度百科：PDCA循环是美国质量管理专家休哈特博士首先提出的，由戴明采纳、宣传，获得普及，所以又称戴明环。全面质量管理的思想基础和方法依据就是PDCA循环。PDCA循环的含义是将质量管理分为四个阶段，即计划（plan）、执行（do）、检查（check）、行动（Action）。

记得在上课的时候我就不是很清楚 do 和 action 之间的区别，因为认为它们都有行动的意思，后面百度了一下，觉得有位网友解释的有点道理，那就是 do 是在执行计划之后做的动作 而 action 是在检查了之后做的改正修复工作。这就类比做作业，首先制定在三小时内要完成一套理综卷子，这个是plan，然后做这套卷子，也就是 do ，做完了之后对答案，也就是 check ,最后订正，便是 action。

过程的六个要素：

（1）输入

（2）输出

（3）活动或者分解的任务/作业

（4）资源：支持活动执行所必须的，包括人员、设备等

（5）测量与验证：保证过程中的相关元素是合格的

（6）过程的目标：执行完这个过程所期望达到的效果

chapter 1：软件过程基础（10分）

-几位质量管理大师的主要贡献：

Shewhart（休哈特）：统计质量控制（SQC）之父

最早提出“计划（Plan）—执行（Do）—检查（Ckeck）”的概念，后来戴明进一步将其发展为PDCA（计划（Plab）—实施（Do）—检查（Check）—行动（Action））

Deming（戴明）：

1）质量改进

2）PDCA环，也称为戴明环

3）十四点原则

Juran（朱兰）：主编《质量控制手册》（quality control handbook），为奠定全面质量管理（TQM）的理论基础和基本方法做出了卓越的贡献

1）适用性质量

2）质量三部曲：质量计划—质量控制—质量改进

3）Juran quality loop（朱兰质量螺旋）

4）80/20原则：质量问题只有20%来自基层操作人员，而恰恰有 80%的质量问题是由于领导责任引起的。

Crosby（克劳士比）：于1964年提出“零缺陷”的概念，即第一次就把事情做对

1）质量管理的绝对性

2）质量改进的基本要素

领悟（comprehension）、承诺（commitment）、能力（capacity）、沟通（communication）、改正（correction）、坚持（continuance）（6C—“变革管理的六个阶段”）

质量运动情况

人物	时间	成就
Shewhart（休哈特）	20世纪30年代	发表“统计学质量控制原理”
Deming（戴明）	1956年	进一步发展并成功证明Shewhart的原理
Crosby（克劳士比）	1960年	发展“软件成熟度的量化”
Humphrey（汉弗莱）	1986年	软件过程中采用Crosby的成熟度量化，加入成熟度等级的概念； 首次提出软件能力成熟度模型，即CMM 将TQM（Total Quality Management）全面质量管理的思想运用到软件过程的改进中； 力推个体软件过程（PSP）和团队软件过程（TSP），这两个理论在解决软件零缺陷方面取得了瞩目成就
SEI	1987-97	发展成熟度框架、问卷 SPA（软件过程评估） SCE（软件能力评估） CMM（能力成熟度模型）

软件过程的定义：当人们在开发和维护软件及其相关产品时所涉及的各种活动、方法、实践和改革等。

软件过程的元素：输入、输出、活动或进一步分解的任务、资源、测量与验证、过程目标

软件过程的分类与组成：

1）软件基本过程

需求分析、软件设计和编码等

2）软件支持过程

配置管理过程、质量保证过程、评审过程等

3）软件组织过程

改进过程和培训过程等

Watts Humphrey的观点：软件系统的质量取决于用于开发和改进它的过程质量。

chapter 2：PSP个体软件过程（Personal Software Process）（25分）

PSP：一种个体级的用于管理和改进软件工程师个人工作方式的持续改进过程。

PSP是包括了 数据记录表格（时间、缺陷日志等）、过程操作指南和规程在内的结构化框架，典型的PSP流程为：策划—设计—编码—编译—单元测试—总结

PSP成熟度级别：

1、个体度量过程

2、个体规划过程

3、个体质量管理过程

4、个体循环过程

大部分项目采用 LOC作为规模度量的方式

通用计划框架：

定义需求；概要设计；规模估算；资源估算；日程计划；开发产品。

PROBE Proxy Based Estimation 基于代理的估算，用于解决早期规划与估算精准之间的矛盾

寻找一种便于早期规划的规模度量的代理，建立这种代理与精确度量之间的关联关系

 

【模块】【类】【方法】都是理想的代理

相对大小矩阵描述了代理与LOC之间的对应关系

PROBE估算方法主要用于估算软件开发的规模和需要的资源

为了保证评审过程的质量，PSP定义了一系列过程质量的度量指标

Yield：度量每个阶段消除缺陷的效率  phase和process

若无历史数据估算，则将单元测试阶段的phase yield设定为50%（资料表明在测试中每发现一个缺陷，往往意味着还有一个缺陷没有被发现）

将缺陷按照比例分配到各个缺陷的注入阶段，重新计算Pase Yield的估算值

A/FR（Appraisal to failure ratio）：质检失效比

=PSP质检成本/失效成本

质检成本为设计和代码评审所花费的时间总和；

失效成本为编译和单元测试所花费的时间总和。

期望值为2.0，越大说明在评审阶段花费的时间越长

PQI（Process Quality Index）:过程质量指标

用以度量PSP过程的整体质量

=设计质量*设计评审质量*代码质量*代码评审质量*程序质量

五个乘积因子的取值范围为【0.0—1.0】

当PQI>=0.4的时候，认为该过程质量较高

评审速度（Review Rate）：

代码评审速度小于200 LOC/h，文档评审速度小于4 page/h

DRL（Defect-Removal Leverage）：缺陷消除效率比

度量的是不同缺陷消除手段消除缺陷的效率

以单元测试每小时发现的缺陷数为基础，其他阶段每小时发现的缺陷数与该基础的比值即为DRL

PSP设计模板

操作规格模板（Operational Specification Template）OST

描述系统与外界的交互

功能规格模板（Functional Specification Template）FST

描述系统对外提供的静态接口

状态规格模板（State Specification Template）SST

描述系统的状态信息

逻辑规格模板（Logical Specification Template）LST

描述系统的静态逻辑

	静态信息	动态信息
内部信息	LST（结构信息） 类和方法的规格说明	SST（行为信息） 状态图
外部信息	FST（功能） 类图	OST/FST（交互信息） 用例图/顺序图 （用例图体现交互对象，而顺序图也表明是如何交互的）

UML中的用例图和顺序图提供了与PSP中OST同样的信息；

UML中的顺序图和类图所描述的类之间的关系以及对象之间的交互信息在PSP的4个设计模板中均没有对应的内容；

FST中对方法的行为有描述，与之对应的UML类图中没有；

PSP中的LST用来描述系统内部的静态逻辑结构，UML中没有与之对应的图示方法

SST中描述了状态、状态转换条件和状态转换中的动作，UML中没有

chapter 3：TSP 团队软件过程

WBS（work breakdown structure）：工作分解结构

WBS是一种树形结构

WBS就是按照一定的原则将项目进行分解，分解为一个一个的任务，任务进一步分解成工作，直到底层元素的粒度大小满足要求，再把一项项工作分配到工作人员的日程安排当中。

基本要求：

1、最底层要素不能重复

2、所有要素必须有清晰明确的定义和描述

3、最底层要素必须要有明确的负责人/团队

4、最底层要素是实现目标的充分必要条件

范围管理：

确保项目做且成功完成所需的所有工作的各过程

收集需求—确定范围—WBS—核实范围—控制范围变更

开发策略与计划：

取考虑以下三个因素

1）WBS

2）产品组件的开发顺序

3）产品组件的获得方式

SDLC（Software Development Life Cycle）

常用：瀑布、螺旋、原型

质量计划：典型的质量保证活动

个人和团队评审；单元测试；集成测试；系统测试；验收测试

风险管理包括风险识别和风险应对：

典型的风险识别的方法：

1、检查WBS中的每个组件找出对应的风险

2、用定义好的风险分类表来评估风险

3、访谈相关领域专家

4、与类似项目进行比较

5、检查以往项目的总结报告

6、检查设计规格和需求规格

风险应对三大策略：

1、风险转移

2、风险消除

3、风险缓解

TSP团队项目规划流程：

TSP项目启动（9次会议历时4天）

第一次：建立产品和业务目标

第二次：角色分配和小组目标定义

第三次：开发流程定义与策略选择

第四次：整体计划

第五次：质量计划

第六次：个人计划与计划平衡（个人与整体之间可能存在矛盾，所以需要调整）

第七次：风险评估

第八次：准备向管理层汇报计划

第九次：向管理层汇报计划内容

TSP项目跟踪与管理

一种客观度量项目进度的项目管理方法：EVM（Earned Value Management 挣值管理法）

PV（Planed Value）:计划价值

EV（Earned Value）：挣值

AC（Actual Cost）：实际成本

典型的纠偏活动：

纠偏原因分析；纠偏措施定义；纠偏措施管理

TSP项目总结

项目总结：提供一个系统的方法来总结经验教训，防止犯同样的错误，同时评估团队绩效和积累过程数据，给团队成员提供持续性学习和改进的机会。

包括三个阶段：

1）准备

2）总结

3）报告

TSP项目总结：

四个阶段：

1、准备阶段：TSP教练给团队进行总结流程和工作内容的培训，包括总结的格式要求等

2、过程数据评价阶段：由过程/质量经理带领，所有成员角色均需要提交PIP（Process Improvement Proposal 过程改进提案）

3、人员角色评价阶段：团队成员结合自己的角色做相应的评价和总结

项目组长	从领导力的角度考察团队表现，重点关注团队受激励的水平和承诺履行情况
过程经理	关注团队遵循过程的程度以及过程改进方案
支持经理	关注配置管理状况和问题、风险跟踪机制以及复用策略的支持等
开发经理	从需求、设计和实现，以及开发策略为话题进行得失总结
质量经理	从项目整体质量状况出发，总结质量目标的实现过程，并找出改进机会
计划经理	关注项目进度，就估算、生产效率、里程碑等话题进行总结
工程师	个人绩效（生产力水平、效率等）

4、总结报告纂写阶段：由项目组长带领团队成员一起完成，并组织评审

TSP项目总结模板

 

成员角色以及对应的工作内容

项目组长	激励团队成员努力工作； 主持项目周例会； 每周汇报项目状态； 分配工作任务； 维护项目资料； 组织项目总结
过程经理	带领团队定义和记录开发过程并且支持过程改进； 建立和维护团队的开发标准； 记录和维护项目的会议记录； 参与项目总结
支持经理	带领团队识别开发过程中所需要的各种工具和设施; 主持配置管理委员会，管理配置管理系统 维护文件项目的词汇表 维护项目风险和问题跟踪系统； 主持软件开发过程中复用策略的应用； 参与项目总结
开发经理	带领团队制定开发策略； 带领团队开展产品规模和所需时间资源的估算； 带领团队开发需求规格说明； 带领团队开发高层设计； 带领团队设计规格说明； 带领团队实现软件产品； 带领团队开展集成测试和系统测试 带领团队开发用户支持文档； 参与项目总结
质量经理	带领团队开发和跟踪质量计划； 向项目组长警示质量问题； 软件产品提交配置管理之前，对其进行评审，消除质量问题； 充当小组评审的组织者和协调者； 参与项目总结
计划经理	带领团队开发项目计划； 带领团队平衡计划； 跟踪项目进度； 参与项目总结

CMM：软件成熟度模型 

也就是 capacity maturity model for software

主要有五个等级

初始级、可重复级、已定义级、已管理级和优化级

每个等级有几个KPA，也就是关键过程域，它们指的是在改进软件组织过程中特别需要关注的区域，每一个KPA会识别一系列的活动，当这些活动完成时，能达到一组增强软件过程能力至关重要的目标。

每一个KPA有多个key practice ，也就是关键实践，所有关键实践都按照五个类别进行组织，分别是：

执行约定  commitment  to perform 

执行能力 ability to perform

执行活动 activity perform

测量分析 measurement analysis

验证执行 verifying implementation

initial repeatable defined managed optimizing

接下来介绍各个能力成熟度等级的KPA名称

CMM2 

1、需求管理 Requirement management

目的：在客户和遵循客户需求的软件项目上保持一致的理解。

2、软件项目计划 Software Project Plan

目的：是为实施软件工程和项目管理制定的合理计划。包括对要做的工作进行估计、确定必要约定以及制定工作计划。

3、软件项目跟踪与监控 Software Project Tracking Oversight

目的：能够随时掌握软件项目开发的实际情况，使项目执行情况与计划背离时，能及时发现并采取有效的纠偏措施。

4、软件子合同/外包合同管理 Software Subcontract Management

目的：为了选择合适的软件开发分承制方，并对其进行有效管理。

5、软件质量保证 Software Quality Assurance

目的：为管理者提供有关项目过程和产品的适当可见性。

6、软件配置管理 Software Configuration Management

目的：保证软件项目生成的产品在软件生命周期中的完整性。

CMM3 Defined 

1、组织过程定义 Organization Process Definition 

目的：开发和维护一个可用的软件过程资源集，以提高各项目软件过程的能力

（由软件工程小组定义 组织标准软件过程）

2、组织工程焦点 Organization Engineering Focus

目的：通过组织软件过程活动，改进整体软件过程能力

3、集成软件管理 Integrated Software Management

目的：将软件工程和项目管理结合成密切相关的、定义完整的软件过程。

（项目经理结合项目的实际情况对组织标准软件过程进行裁剪，得到项目定义软件过程）

4、培训大纲 Training Program

目的：通过培训提高团队个人工作技能

4、软件产品工程 Software Produce Engineering

目的：为了一致地执行一个经过完整定义的软件工程过程，该过程综合了所有软件工程的活动，以便高效地生产出正确而一致的软件产品。

5、组间协调 Intergroup Coordination
目的：建立一种能使软件工程小组与其他小组积极协作的方式，从而使得开发的项目更好、更有效地满足客户的需求

6、同行评审 Peer Review

目的：为了尽早且有效地排除软件项目产品的缺陷，提升产品质量。

CMM4 Managed

1、定量过程管理 Quantitative Process Management

目的：为了定量的控制软件过程效能

2、软件质量管理 Software Quality Management

目的：为了定量地了解软件项目的质量，并实现具体的质量目标。

CMM5 Optimizing 

1、缺陷预防 Defect Prevention

目的：分析项目中出现的缺陷的来源并防止其再次发生

2、技术更新管理  Technology Change Management

目的：为了在识别新技术（工具、过程和方法等）后，有序地将技术引入机构内

3、过程变更管理 process Change Management

目的：不断改进机构中的软件过程，从而提交软件开发效率和生产率。

Scrum：一种迭代式、增量的软件敏捷开发方法

每一次迭代就要完成一个冲刺订单，称为sprint，在选择下一个冲刺订单之前会召开冲刺计划会议，Productor Owner会从项目订单backlog中选择优先级较高的订单作为冲刺订单，然后带领scrum team一起确定完成这项冲刺订单需要的功能数量。将冲刺订单分解为以小时为单位的一系列的任务，一般不超过16个小时，如果超过则需要继续分解。

Scrum开发模型中有两类角色，也就是需要全力以赴的“猪”角色和只需要参与的“鸡”角色。

“猪”角色

Product Owner :掌握方向盘

Scrum Team：引擎

Scrum Master：技工

“鸡”角色

高层领导：通过PO传达公司盈利目标和订单优先级

客户：参与协作；提供资金；反馈

Sprint常见活动：

冲刺计划会议：

在冲刺之前举行，历时4到8小时，PO、Scrum Team和Scrum Master及相关对该项目感兴趣的人参加；PO会从产品订单中挑选出优先级较高的任务，并与开发团队一起决定在这个冲刺中需要完成多少功能。

每日站立会议：

每天固定一个时间点举行，参与人员为PO、Scrum Team和Scrum Master，时长15分钟左右，站立的目的是为了提交会议效率，会议的内容主要分为以下三个部分：昨天做了什么？今天打算做什么？遇到了什么困难？每日站立会议结束后，需要更新项目的燃尽图以及各成员的任务看板（to do; doing; done）。

评审会议：

在冲刺结束之前举行，是一个用于Scrum Team展示给PO关于产品新功能与底层架构实现的非正式会议。

回顾会议：

在冲刺结束之后举行，主要是做一个周期性的回顾，总结刚刚结束的迭代周期的冲刺工作中的经验和教训。

计划纸牌：

是一种用于客观估算订单任务所预计工作量的有效方法。

软件估算

客观准确的项目估算是项目成功的基础

在估算中有两个目标名词：

准确 Accuracy：描述估算结果与实际值相差远近的程度

精确 Precision：描述估算的结果能达到的小数点位数的程度

软件估算有7种技术：

自顶向下是先从整体进行估算，然后分解到各个部分；

effort=size*productivity（工作量=系统规模*生产效率）

自底向上以WBS为基础，先估算各个部门的工作量，再进行合成得到总体的工作量；

专家判断；

对比分析；

数学模型（COCOMO Constructive Cost Model）；

Parkinson;

赢利价格。

功能点法：

外部输入；

外部输出；

内部逻辑文件；

外部接口文件；

外部查询。

根据实际情况得到对应的加权因子然后与对应类型的功能点数量进行相乘之后求和。

提供复杂性判定方法。

COCOMO:

Effort=c*size^k

参数C和K根据系统的分类而定：

系统分类分为三类：有机模式（开发系统的规模较小，团队成员对所处的开发环境十分熟悉），嵌入式模式（开发规模和难度大）和半分离模式（处于前两种模式之间）。

COCOMO修正：

首先从基本模型得到名义成本，然后采用开发成本乘法算子（development effort multiplier）进行修正。

  PM=PM*dem

COCOMO Ⅱ 是进一步的改进产物，提出渐进性评估的概念

考虑到系统开发可能处于的三个不同阶段：

应用构成阶段（采用对象点，区别于面向对象中的对象含义，指的是要处理的屏幕、报告和部件，有simple，avarege和high这三个等级）

早期设计（采用功能点进行估算）

构造阶段

PM=A * SIZE^SF * em1*em2*em3…..

我对改进之后的COCOMO模型的理解是，让估算更加动态化，处于一种随时根据情况进行调整的状态中，根据系统开发所处的每个阶段的特点，结合不用的影响因子进行一种渐进式的更为准确和科学的评估。

SF=1.01*0.01*（各个因素的和）

软件配置管理（Software Configuration Management）

SC是软件开发各个阶段中所产生的所有各个版本的文档、数据和程序的集合。

SCI为软件配置项，即为SC中的元素，根据所处的状态分为基线配置项和非基线配置项这两类。

SCM是一套管理软件开发和维护过程中所产生的各种中间软件产品的方法和规则。

SCM的目标有三个：

1、标识变更

2、控制变更

3、确保变更正确并报告相关人员

进行SCM必须的三个元素：人、规则和工具，SCM的核心工作是要存储和管理配置项。

关于基线，也就是baseline

基线的含义是：经过正式评审和审计，并被批准后的阶段性软件工作产品。

而里程碑是一个阶段标记，标记着某项任务的完成。

基线与里程碑是一一对应的。

重要的检查点为里程牌，不是所有，检查点还可以是时间、计划和事件等。

基线分为三类

功能基线；（合同签字，确定项目框架：知道有事情可做）

指派/分配基线;（SRS完成：知道要做什么）

产品基线。（软件开发结束：已经做完）

这三个基线的完成具有里程牌与之对应。