cmmi效能

效能与质量

研发阶段和效率价值金字塔

需求调研和评审>技术方案设计和评审>研发>测试

度量

CMMI级别中和BUG率相关的信息

CMMI级别 BUG率
CMM1级 11.95‰
CMM2级 5.52‰
CMM3级 2.39‰
CMM4级 0.92‰
CMM5级 0.32‰

考核千行代码Bug率的问题

代码行数<>价值

考核标准:Bug率数值越小就说明越好->尽量增大代码行数

考核阶段:Bug率的数据主要产出在研发阶段的后期,及提交测试后产出bug数->从项目的研发阶段和效率价值金字塔来看,其对项目的整体质量方面更多的聚焦在微观层面问题,整体的质量的影响范围会较小。

更合理的度量质量

  1. 需求的评审

  2. 架构设计方案评审

  3. 代码模块设计,包的依赖的规划,接口的设计的review

  4. 代码的review的机制

  5. 测试用例评审

  6. 使用代码检测工具,自动发现问题

过程评审是最有效也是成本最低的质量和效率保证和提升的手段。另外,过程评审还是迅速提高新人能力及其成果物的规范性的一个有效手段。

系统质量是要靠上游工程做出来的

上游的工作质量会更为重要,上游的问题的影响范围将更广,对效率和价值的影响更大,应该是我们重点关注的地方。仅仅依赖下游工程(种种测试)来把质量关,是十分低效,而且代价是非常昂贵的。

需求

需求管理

1.需求要被管理,被管理的意思又有两层:一是需求要被确认,二是要控制需求变更

2.需求要用来指导下游的工作产品,如:计划、设计、测试等

常见问题

1.因为项目进度赶等原因,在很多需求还没有明确情况下,便开始开发的工作。
2.开始客户只能提出模糊的需求,客户喜欢先让你做个东西给他看,然后他才可能逐渐提出真正的需求,而需求调研人员,对此没有什么好的处理办法。
3.客户以种种原因不签需求,项目组在不签需求的情况下,便开始开发工作。
4.客户不承认之前提出来的需求,项目组又不能得失客户,项目成员苦不堪言。
5.需求经常变化,无法控制。
6.设计、代码与需求不对应,特别是需求变更时,不知道应该修改哪部分,也不知道会有哪些影响

优秀的需求管理要素:

开发者应该理解需求

通过客户确认(记录)

需求变更管理(记录确认,影响清单确认)

需求双向跟踪维护(纵向:上下游工作产品之间的跟踪关系。横向:需求与需求之间的关系、设计与设计之前的关系、代码与代码之间的关系等)

需求与下游工作产品差异识别(需求变更时:双向跟踪表影响内容同步修改;编写写或者修改计划、设计、代码、测试计划、测试用例等需求下游工作产品时:要与需求保持一致)

实现

工具赋能:需求管理平台<->aido

需求开发

用系统的方法获取真正的全面的能实现的需求

常见问题

没有把握好客户需求,直接进入软件的细节,去讨论要做什么功能,界面要怎样设计去了,而忘记了软件的根本目的是为了解决什么问题。

明确客户需求后,就应该把客户需求转变成产品需求和产品组件需求,客户需求一般都是比较高层次的,而且描述也会比较简单,不能作为日后验收的标准,我们需要对软件的规格进行说明。一般来说,我们写的软件规格说明书都会包含产品需求和产品组件需求的。我们导出产品需求和产品组件需求的时候,要注意产品需求和产品组件需求,必须和客户需求对应起来,通常是多对多的关系。为什么要对应起来?我们要保证,软件的每一个界面,每一个功能都是有用的,都是“源自”客户需求的,这样才能保证我们做的事情都是正确的事情,防止被不相干的事情干扰。

客户需求

可以理解成客户为什么要做本系统,要解决什么问题,客户对系统有怎样的期望,希望能具备一些怎样的特点,简单的说,就是客户的需要是什么。

产品需求

是能满足客户需求,并对软件产品规格进行了详细描述的需求,软件设计师可以根据产品需求进行设计、编码等工作。

产品组件需求

是对产品需求的进一步细化,产品可能会分割成几个子系统、几个部分,每个子系统每部分要具备怎样的功能、要具备怎样的性能、接口要求等,这些可以认为是产品组件需求。

另外一个角度,需求可以分为功能性需求和非功能性需求两类,功能性需求就是系统具备怎样的功能,能做什么事情,而非功能性需求就是指系统要具备怎样的性能、安全级别等方面的要求。客户需求、产品需求和产品组件需求,都会包含功能需求和非功能需求。

优秀的需求开发要素:

干系人的需要、期望、约束和接口要求被收集并转化为客户需求

让客户能完整无遗漏准确地表达出他的想法:(原型、图示、类比、问卷)系统的目标、范围、解决什么问题、希望系统具备怎样的一些特性,满足一些什么接口要求和约束条件等

把客户原始的需求信息整理成正式的客户需求:通常会包括对系统目标、范围、解决问题、软件特性、接口要求等有详细的描述。

客户需求是精确和详细的,以用来开发产品需求和产品组件需求

产品和产品组件需求:对软件规格的描述,详细描述软件与用户是怎样交互的,用户需要输入什么,系统输出等都会比较详细描述出来。可做验收标准
分配需求给每一个产品组件:所有的需求应该与设计的产品组件对应,保证需求驱动后续的设计工作,同时也保证设计都是为需求服务

定义接口需求:包括系统与第三方的系统的接口要求,也包括系统本身各组件、各子系统、各部分之间的接口要求

需求被分析和确认,并定义出具体的功能性需求

操作场景与功能定义:描述出具体需求的操作场景、上下文,具体的操作步骤,对功能的详细描述等。通常我们可以通过序列图等来表达这些内容

分析需求:准确性、全面性、可实现性,平衡约束条件,确保需求符合最终的使用场景要求。通常是通过需求评审

开发

技术方案

常见问题

1)无设计文档
2)有设计文档,但形同虚设
3)设计时没有考虑可以重用以前项目或者第三方的代码或组件
4)没有用需求来驱动设计
5)设计没有考虑多过一个的方案
6)没有考虑清楚设计的原则和标准
7)设计的弹性不够、架构落后?
8)代码与设计脱节?
9)到处都是面条式代码

优秀的技术方案要素:

从候选方案中选择产品或者产品组件的解决方案

先考虑好我们设计方案的选择标准,并找出可能的候选方案

对产品的规格进行详细的表述,操作概念、场景、环境、操作模式和操作状态等

根据选择标准选出最佳方案

开发产品或者产品组件设计

概要设计:建立产品功能和框架,包含产品组成区块、产品组件界定、系统状态与模式、主要的内外部接口和界面设计(功能模块设计、数据库设计包括逻辑设计和物理设计及安全性能设计、模块接口和界面设计)

详细设计:完整定义产品组件的结构和功能,详细描述实现方法、算法

建立和维护技术数据包:(需求、设计资料等)为开发者提供开发产品或组件的综合性描述,以及产品架构描述、分配需求、产品组件的描述、产品相关生命周期过程描述、关键产品特性、必需的物理特征和约束、接口需求、用于确保实现需求的验证准则等。

设计合适的产品组件接口:考虑外部接口和内部接口;与原来系统的关系;

产品组件开发、购买或者重用评估:技术状况

实施产品组件的设计

编码:适当的标准与准则,走查,单元测试

用户文档:用户手册、安装手册、管理员手册、在线帮助等

产品集成

常见问题

时序

优秀的产品集成要素:

完成产品集成的准备工作

建立并维护产品组件的产品集成流程
建立并维护产品组件集成与评估标准
建立并维护产品组件的确认与交付标准

确保产品内部与外部的接口是兼容的

检查接口描述,保证覆盖性和完整性:通常通过评审接口说明。包括产品组件接口,产品集成所有环境的接口(定期)

管理产品和产品组件的内部和外部接口的定义、设计及变更:管理各组件之间的关系,保证组件间保持一致(配置库)

组合已集成的产品组件,并交付已集成、已验证、已确认的产品

在产品集成前,确定要集成的产品的产品组件已被确认、并依据其说明执行,并且确定产品集成接口符合接口说明

根据产品集成顺序和相关过程集成产品组件

评估产品组件的接口兼容性

打包组装已集成的产品或组件,并交付给适当的客户

实现

工具赋能:统一环境管理,持续集成,持续交付

阅读全文
cmmi开发相关

开发阶段

技术方案( Technical Solution )

​ SG1 选择产品构建解决方案

​ SP1.1 开发详细候选解决方案和选择准则 SP1.2 开发操作概念和场景 SP1.3 选择产品构件解决方案

​ SG2 设计

​ SP2.1 运用有效的设计方法 SP2.2 建立完备的技术数据包 SP2.3 设计综合性接口 SP2.4 进行制作、购买或复用分析

​ SG3 实现产品设计

​ SP3.1 实现设计 SP3.2 编制产品支持文档

为设计、开发及实现需求的解决方案。解决方案、设计结果及实现成品包括产品、产品组件,以及与产品相关生命周期的单一过程或适当组合的过程。

提示:产品架构、系统、子系统、性能、组件的解决方案,容易出现没有记录和文档问题;

对于瀑布模型开发来说,系统或产品分解后,架构不能经常变;对于迭代模型开发来说,前一两个迭代,系统或产品的架构要确定;至于设计,对新的产品或系统,考虑如何设计,对于旧的产品,考虑如何优化设计;

概要设计和详细设计的设计准则和标准要描述和规范(基于提高复用性,可扩展性;提高效率,质量,考虑复用提高生产率。)设计准则和标准选择理由加以记录;选择的评估会议可以是非正式如周例会;

设计过程:分解到组件后,是自己做还是采购,考虑增加复用和可扩展性;提高效率和质量,考虑复用提高生产率。

项目工期紧,常常成为很多事情的理由。因为赶时间,拿到需求后,不考虑哪种设计方案更合适,想到什么办法就用什么办法来做,甚至是没有设计可言,直接编码,写设计文档变成了浪费时间的一个事情。不少人进行设计的时候,眼光都放得不够开,不知道可以从很多途径找到可重用的代码,直接自己编码实现数据操作、日志处理、权限认证等事情,结果浪费了时间,而且还不能保证自己的代码是没有问题的。不少可重用的代码都是经过严格测试的,设计架构良好的,可直接使用或者稍加修改则可以为自己所用。

设计方面常见问题:
1)无设计文档
2)有设计文档,但形同虚设
3)设计时没有考虑可以重用以前项目或者第三方的代码或组件
4)没有用需求来驱动设计
5)设计没有考虑多过一个的方案
6)没有考虑清楚设计的原则和标准
7)设计的弹性不够、架构落后?
8)代码与设计脱节?
9)到处都是面条式代码

技术解决方案主要讲述的是设计、开发、实施方面的问题。

SG1: 从候选方案中选择产品或者产品组件的解决方案

Product or product-component solutions are selected from alternative solutions.
制定选择的标准,设计候选方案,针对产规格依据选择标准,从候选方案中选出合适的方案。

这个目标的主要内容就是制定选择的标准(一般涉及成本、进度、效益、风险、技术性能等),设计候选方案,针对产品规格,依据选择标准从候选方案中选出合适的产品或产品组件解决方案。解决方案(有时称为“设计方案”、“设计概念”或“初步设计”);初步设计或设计方案可能与产品需求和产品组件需求开发同步进行并互动(在开发或获取客户需求之后)。

很多开发人员,做编码之前都不太喜欢认真思考设计方案,迫于时间压力,不仔细考虑设计方案是否合适,就直接开展工作,这样做的风险是非常大的。

提示:产品架构、系统、子系统、性能、组件的解决方案,容易出现没有记录和文档问题;

SP1.1 开发详细的候选方案及选择的标准

Develop detailed alternative solutions and selection criteria.

先考虑好我们设计方案的选择标准,并找出可能的候选方案

典型的工作产品

1.备选解决方案筛选准则

  1. 新技术的评估报告

  2. 备选解决方案

  3. 最终选择的评选准则

  4. 对市场现有成品的评估报告

子实践

  1. 界定筛选准则,以作为选择备选解决方案的考虑因素

​ 2.界定现有技术与具竞争优势的新产品技术

​ 3.界定能满足需求的备选现成品:供方

  1. 产生备选方案

  2. 取得每一备选解决方案的完整需求配置。

  3. 开发选择最佳备选解决方案的准则

SP1.2 针对每个产品组件描述操作概念、场景、环境、操作模式和操作状态等

Evolve the operational concept,scenarios,and environments to describe the conditions,operating modes,and operating states specific to each product component.

要求对产品的规格进行详细的表述,因为我们的方案是要满足这些规格的,也只有这样,我们才能更好地找出合适的解决方案

典型的工作产品

  1. 产品组件选择决策及理由

  2. 需求及产品组件间相关性的记录

  3. 解决方案、评估及选择理由的记录

子实践

  1. 依据操作概念、操作方式及操作状态所建立的评选准则,评估各备选解决方案/解决方案组。针对每一个备选解决方案,开发产品操作及使用者互动的时序场景。

  2. 依据备选解决方案的评估,评?评选准则之适用性,必要时,更新准则。

  3. 界定并解决与备选技术方案及需求有关的问题。

  4. 选择能满足已建立之评选准则的最佳解决方案。

  5. 建立与所选择之备选方案关联的需求,此即为该产品组件的配置需求。

  6. 界定将再用(重用)或取得的产品组件解决方案。

  7. 建立并维护解决方案、评估及选择理由的文件。维护选择理由对后续决策十分重要,可以使后续干系人免于返工,也可在某些适用的应用环境下,提供对技术应用的深入见解。

SP 1.3 选择最符合要求的产品组件设计方案

Select the product-component solutions that best satisfy the criteria established.

根据选择标准选出最佳方案

有人可能有这样的疑问,有些项目很简单,或者设计方案很明确,没有必要搞什么候选方案和选择标准,直接设计就可以了。设计方案除了针对整个项目的大的设计方案,还包括组成产品的各个组件的设计方案,绝大部分情况下,一个项目肯定会有部分地方技术不太明确需要仔细分析的。另外,不管怎样,都应该根据项目的实际情况,定出这个项目的设计标准,就算只有一个方案,也需要用该设计标准来检验该方案。大部分情况下,认为不需要考虑多个设计方案、不考虑设计标准,都是“懒惰”思想作怪,不做这样的考虑,项目的风险是比较大的。

SG2: 开发产品或者产品组件设计

Product or product-components designs are developed.

最佳候选方案确定后,就可以开展具体的设计工作了。设计不仅是为了实现,也是为了产品生命周期阶段如修正、重新采购、维护、及安装等。设计文件提供给相关的干系人,以方便对设计的相互了解提供参考,并在产品的开发与后续的生命周期阶段设计上的改变。完整的设计描述,记录与技术数据包内。

SP2.1 开发产品或者产品组件的设计

Develop a design for the product or product components.

产品设计一般包含两个阶段,在执行上可能相互重叠:概要设计与详细设计。

概要设计建立产品功能和框架,包含产品组成区块、产品组件界定、系统状态与模式、主要的内外部接口和界面设计。常见的概要设计说明书问题有(功能模块设计、数据库设计包括逻辑设计和物理设计及安全性能设计、模块接口和界面设计):软件性能描述不具体;性能的解决方案没有记录和文档;数据库设计包括逻辑设计和物理设计及安全性能设计不具体等;

详细设计:完整定义产品组件的结构和功能。详细设计说明书是为编码人员所写,要详细描述实现方法、算法;如是面向结构或数据流方法,数据结构和处理流程(输入、转换、输出数据流);如是面向对象方法,设计类的函数和成员变量,并明确对象之间的相互关系。常见问题是详细设计说明书过于简单,和概要设计一样,接口(内部和外部)设计不具体;

典型的工作产品

  1. 产品架构

  2. 产品组件设计

子实践

  1. 建立并维护准则,以评估设计。

  2. 界定、开发或取得适合于产品的设计方法。选择适合的方法并在一定的工具支持下对设计提供很大的帮助,一般常用的技术和方法:原型法、面向结构化设计方法、面向对象设计方法、E-R模型、设计复用、设计模式等;

  3. 确保设计遵循所应用的设计标准与准则。

  4. 确保设计遵循已配置的需求。

  5. 记录设计。

SP2.2 建立和维护技术数据包

Establish and maintain a technical data package.

这个Practice的字面意思比较难理解,其实意思很简单,就是要建立和维护一套管理所有设计文档、数据的方法或者体制,对设计过程的数据、文档进行有效的管理。技术数据包是给开发人员的做的(主要是需求、设计资料等),设计人员不想做,开发人员非常需要。完备的技术数据包为开发者提供了开发产品或组件的综合性描述,还提供了有关产品类型的以下信息:产品架构描述、分配需求、产品组件的描述、产品相关生命周期过程描述、关键产品特性、必需的物理特征和约束、接口需求、用于确保实现需求的验证准则等。

SP2.3 根据所建立和维护的标准,设计合适的产品组件接口

Design comprehensive product-component interfaces in terms of established and maintained criteria.

考虑外部接口和内部接口;与原来系统的关系;

典型的工作产品

  1. 接口设计规格说明

  2. 接口控制文件

  3. 接口规格准则

  4. 所选之接口设计的理由

子实践

  1. 定义接口准则。一般是组织过程资产的一部分

  2. 界定与其它产品组件相关的接口。

  3. 界定与外部相关的接口。

  4. 界定介于产品组件与产品相关生命周期过程的介面。

  5. 应用准则于接口设计的备选方案。

  6. 记录已选取的接口设计与理由。

SP2.4 根据制定的标准评估哪些产品组件需要开发、购买或者重用

Evaluate whether the product components should be developed,purchased,or resued based on established criteria.

技术状况是对开发或采购产品组件作出选择的重要理由;在开发工作很复杂时,可能以采购现有组件为佳,而拥有先进工具及充足人员情况下则支持自己开发。毕竟有时购买现有的组件,可能不够完备或不能完全满足系统的需要。一旦作出采购现有组件(或外包开发)的决定,就要在供应商协议中进行落实。

典型的工作产品

  1. 设计与产品组件再用的准则

  2. 自制或采购分析

  3. 选择现有成品组件的指引

子实践

  1. 开发产品组件设计再用的准则。

  2. 分析设计以决定产品组件要自行开发、再用或采购。

  3. 当采购或选择非开发的(现成品、政府的成品及再用)时,分析维护所隐藏的代价

SG3: 实施产品设计并开发相应的支持文档

Product components,and associated support documentation,are implemented from their designs.

SP3.1 实施产品组件的设计

Implement the designs of the product components.

简单地说就是依据设计进行编码活动了

典型的工作产品

  1. 已实现的设计

子实践

  1. 使用有效的方法实现产品组件。比如结构化编程、面向对象编程、自动代码生成、软件代码复用、应用合适的设计模式等。

  2. 遵循适当的标准与准则。比如编码规范、过程及质量标准、编码时遵循模块化、明确、简单、可靠、安全、可维护等准则;编码规范描述内容(如编码模块的复杂度和内聚性等)

  3. 对选定的产品组件,执行同行审查。可以通过代码走查、测试等多种方式来实现;单元测试是验证是否实现设计;单元测试要提到接口测试;

  4. 适当时对产品组件执行单元测试。 这里单元测试不局限于软件,涵盖个别硬件、软件单元或先前已整合的相关组合;

  5. 必要时修订产品组件。在实现阶段发生了未能与设计阶段预见的问题,就是修订产品组件时机的范例之一。

SP3.2 开发和维护最终用户文档

Develop and maintain the end-use documentation.

开发和维护用于产品安装、操作及维护的相关文档,如用户手册、安装手册、管理员手册、在线帮助等。

典型的工作产品

  1. 终端使用者培训教材

  2. 使用者手册

  3. 操作手册

  4. 维护手册

  5. 在线求助

子实践

  1. 审查需求、设计、产品及测试结果,以确保影响安装、操作及维护等项文件的相关议题已被界定并解决。

  2. 使用有效的方法,制作安装、操作及维护的文件。

  3. 遵循适当的文件制作标准。如《技术文档编制规范》

  4. 在生命周期的初期阶段就制作安装、操作及维护等文件的初始版本,以供相关的干系人审查。

  5. 执行安装、操作及维护等文件的同行审查。

  6. 必要时修订安装、操作及维护文件。一般为需求、产品、设计、产品实现变更时 。

产品集成( PI )

​ SG1 准备产品集成

​ SP1.1 建立产品集成战略 SP1.2 建立产品集成环境 SP1.3 规定详细的产品集成规程

​ SG2 确保接口兼容性

​ SP2.1 审查接口描述的完备性 SP2.2 管理接口

​ SG3 组装产品构件和交付产品

​ SP3.1 确认集成用的产品构件已经准备就绪 SP3.2 组装产品构件 SP3.3 核查组装的产品构件 SP3.4 打包和交付产品或产品构件

把组成产品的所有软件组件组装起来,使之运行在目标环境上,产品集成包括软件组件之间的集成、软件与硬件的集成、软件基础数据的录入、调试等。系统越复杂,集成就显得越发重要。

基本道理就是随时保证组成最终产品接口一致,能顺畅运行,能随时拿得出可运行的版本。(持续集成)

SG1 完成产品集成的准备工作

Preparation for product integration is conducted.

准备产品、组件集成,包含建立并维护集成的活动和活动顺序、搭建集成环境、执行集成程序。

SP1.1 确定产品组件的集成顺序

Determine the product-component integration sequence.

需要集成的产品组件包括:交付产品的一部分、测试设备、测试程序、以及其他配件等的一个综合体。

产品的集成顺序与确定技术解决方案是一致的,对于复杂的产品而言,集成应该是渐进式的,并且运用“集成-一评价-一集成”的迭代过程。集成支持产品组件渐进式组装和评价,为进一步纳入其他可用产品组件奠定良好的基础,或者是为高风险产品组件的原型设计奠定良好的基础。

具体步骤:

1、确定待集成产品组件。
这个需要注意的是,产品组件还要考虑数据库部分的集成。由于数据库设计与其他功能组件的设计不同,所以往往有专门的数据库人员来设计和维护,所以在产品集成时数据库的集成多数将成为忽略点或是难点。数据库的构架建设最好能自动化执行,因为有时数据库持续集成时可能删除原来数据库,重新自动创建数据库也许是最快捷的方法。
2、利用产品组件接口间的定义,对待集成组件进行验证和确定。
3、确定组件集成的顺序(可以为多种集成顺序方案)。还应包含明确在这些集成的顺序中的一些测试设备、测试软件、支撑产品等
4、确定最佳集成顺序。
5、定期检查集成顺序,必要时进行修改。因为在随着变更,集成顺序也会变更。另外,在集成时还要评估集成、测试环境和实际运行环境的差距,不断调整集成环境,有时集成顺序会变更。
6、记录制订产品集成方案(包括一些被否决的原因)
产品集成方案可以包含的(但不局限)内容有:
*待集成的组件
*产品集成顺序
*要做的活动
*每项活动的责任和所要求的资源
*应予满足的进度
*应予遵循的规程
*所需要的工具

注:这里所说的待集成的组件可能还包括数据库,数据库集成有时也是产品集成的一部分重要内容。

SP 1.2 建立和维护用于支持产品组件集成的环境

Establish and maintain the environment needed to support the integration of the product components.。

这些环境包括硬件环境、网络环境、数据环境等。

产品集成环境可以采用外部采购、复用或是自行开发。为了建立集成环境必需开发设备、软件以及其他资源的自主开发或是采购的需求。这些需求应该在前期需求开发阶段就要进行开发。是外购还是自研、重用是在制定技术解决方案阶段就应该确定的。

产品集成环境可包括:集成设备/程序、测试设备/程序、模拟器(比如一些桩程序)、记录工具等。
具体步骤:
1、确定产品集成的需求。也包括产品集成都需要什么内容?
2、确定产品整合环境的验证标准和程序。这个验证程序可以是自动化的软件程序,也可以是手工的测试流程和用例。
3、确定产品集成自研或是采购所需的产品集成环境。
4、如果无法采购所需集成环境,则进行集成环境的自研工作。
对于无前例、复杂的项目而言,产品集成环境的自研工作将是一项重要的开发工作。它本身就像一个小的项目,也应该包括项目计划、需求开发、技术解决方案、验证、确认以及风险管理等环节。
5、在整个项目执行过程中,进行维护产品集成环境。
如果产品整合环境不再使用时,应进行处理。比如:根据情况分析是否可以复用,如不可再次复用就要进行资源的释放。

SP 1.3 建立和维护产品组件集成的过程及标准

Establish and maintain procedures and criteria for integration of the product components.
这里提到了过程,与SP1.1似乎有点重复,SP1.1只强调考虑集成的现有顺序,而SP1.3要需要考虑具体的集成过程,除了集成顺序,还需要考虑每一步的验证办法、成功标准等。

  产品集成流程可包括:每次增量迭代进行集成的组件和集成编号、每个集成迭代进行测试和评价的内容和验证标准等。
  产品集成标准:实际上是产品集成阶段的准入、准出的标准。它可以定义如何验证产品组件期望值的功能,并定义如何验证交付最终已集成的产品。
  产品集成流程和标准的内容,可以有如下内容:
  *已建立组件的测试内容
  接口的验证
  *性能偏差的可接受程度
  *产品组合与外部接口的衍生需求
  *经验证的可替代元件
  *测试环境的参数
  *测试成本的限制问题和风险
  *产品集成时,质量与成本的平衡点
  *正常执行的可接受几率
  *需求交付率的可接受程度
  *订货到交货的时间及供货周期(需重复提供时需要)
  *人员的可用性
  *集成设备、生产线和环境的可用性
  *
具体步骤:**
  1、建立并维护产品组件的产品集成流程
  2、建立并维护产品组件集成与评估标准
  3、建立并维护产品组件的确认与交付标准

SG2 确保产品内部与外部的接口是兼容的

The product-component interfaces,both internal and external,are compatible.

SG1的SP的工作产品一般会是集成计划、接口说明、集成标准等文档,SG1的主要任务是完成这些文档,而SG2的主要任务就是检查接口是否一致,并在发生接口变化的时候,管理接口的变化,使之保持一致。

许多产品集成的问题往往是由于产品内部接口之间或是与其相连接的外部系统的接口不兼容导致的。所以有效管理产品组件内、外部接口的需求、规格设计,可以确保接口的完整性与兼容性。

SP2.1 检查接口描述,保证覆盖性和完整性

Review interface description for coverage and completeness.
通常我们通过评审接口说明的办法来检查接口的完整性、覆盖性。除审查产品组件接口外,接口应包括产品集成所有环境的接口。
  具体步骤:
  1、审查接口文件的完整性,确保已涵盖所有的接口。
  这个要借助在技术解决方案时编制的接口文档,明确各接口之间的相互关系。对于软件产品而言,接口文件至少应包括如下信息:
  *接口用途
  *接口中的参数类型说明
  *接口参数的来源
  *接口输出参数用途
  *协议与数据特性
  *影响该接口的因素
  等
  2、确保产品组件与接口已标识好标记,确保产品组件可以正确、容易地连接。
  3、定期审查产品接口说明的充分性。
  定期审查现有产品接口说明与正在开发、生产、购买等中的产品没有偏差。有时这种审查要与供应商或生产商共同审查,如有偏差应及时处理有可能涉及到的库存、生产线、用户处等范围。

SP2.2 管理产品和产品组件的内部和外部接口的定义、设计及变更

Manage internal and external interface definitions,designs,and changes for products and product components.
各组件之间是有关系的,我们需要对这些关系进行管理,保证组件间保持一致。
  接口需求驱动着产品组件所需接口的开发,在开发初期就开始管理产品与产品组件的接口。接口的定义接口不仅影响产品组件和外部系统,也影响着验证、确认的环境。
  接口管理包含:维护接口在整个产品周期的一致性,以及解决冲突、不符合以及变更的问题。
  除产品组件接口外,还应包括在集成产品过程中所涉及到的所有接口,以及用于验证、确认、操作、调试、其它支持环境的接口。并且需要记录、维护接口变更的信息,并使其容易查询到和使用。
  具体步骤:
  1、确保接口在整个产品生命周期内的兼容性
  2、解决冲突、不符合以及变更的问题
  3、维护项目成员可以取得接口资料的的存储库
  共享取用的接口资料存储库,提供确保每个成员都知道最新资料的存放处,以及获取和使用的机制,建议放到配置库中。

SG3 组合已集成的产品组件,并交付已集成、已验证、已确认的产品

Verified product components are assembled and the integrated,verified,and validated product is delivered.

主要讲的是执行集成的过程,并交付产品给客户。

根据已制定的产品组件集成的顺序,进行产品组件的集成。整合前,每一个产品组件应确定于其接口相符。集成可以分阶段逐步完成,可以将一些产品组件集成为更大、更复杂一些的产品组件,一直到整个产品集成完毕。在集成过程中,如果出现问题应用文字进行记录,并采取纠正措施。

SP3.1 在产品集成前,确定要集成的产品的产品组件已被确认、并依据其说明执行,并且确定产品集成接口符合接口说明

Confirm,prior to assembly,that each product component required to assemble the product has been properly identified,functions according to its description,and that the product-component interfaces comply with the interface descriptions.
简单的说就是在集成前,做全面的检查工作,保证各部分符合既定的要求。

 确保产品要集成的已被适当的标识、确认的组件符合说明文件,并能根据集成顺序进行实际集成。检查产品组件数量、及产品组件与接口说明不一致的问题。
  具体步骤:
  1、当产品组件处于可进行集成的状态时,尽快跟踪所有产品组件的状态。
  2、根据产品集成顺序与自动化集成程序,确保产品组件已完整提交到集成环境中。
  3、确定每个正确标识的产品组件。
  4、确保已标识的产品组件与说明文件一致。
  5、根据预期配置进行检查配置项的状态。
  6、在集成产品组件前,执行所有接口的预先检查。

SP3.2 根据产品集成顺序和相关过程集成产品组件

Assemble product components according to the product integration sequence and available procedures.
  具体步骤:
  1、确保产品集成环境已准备就绪。
  2、确保正确地按集成顺序执行。
  记录适当的集成过程中的信息,比如:集成组件在配置库中的状态(是否在基线)、产品组件序号、型式以及集成所需的仪表校正日期。
  3、适当地修订产品集成顺序以及集成执行的程序。

SP3.3 评估产品组件的接口兼容性

Evaluate assembled product components for interface compatibility.

  这种评估不仅是对已集成的产品或组件进行评审,还应创造使用环境进行运行,以来评估产品的功能完整性、性能、适用性等符合需求。
  评估的顺序可以按集成顺序,按阶段进行。比如一个OA产品有不同的功能模块,我们可以按照集成顺序先检测登陆,再进行邮箱功能评估,最后进行文档的流转、审批功能的评估。每次集成一部分并进行分步评估,确保每次集成的产品都符合架构的要求。
  具体执行步骤:
  1、根据产品集成顺序与执行程序评估已集成的产品组件。
  2、记录评估结果。
  记录内容可以为:
  *要求与集成规程的适应性
  *产品配置的变更(如:备用零件以及新产品)
  *评估得到的问题。

SP3.4 打包组装已集成的产品或组件,并交付给适当的客户

Package the assembled product or product component and deliver it to the appropriate customer.
  某些产品的包装已经写在了需求规格或是检验标准中,当客户自己进行仓储和运送产品时这点要非常的关注。比如:
  *包装经济且易于运输的需求(如货柜、集装箱装货的需求)
  *可说明性(如:使用可压缩型的薄膜或泡沫等)
  *易拆封且安全(如:锐利边缘、订装的可靠度、对儿童的保护、环保、重量等)
  如果需要开发、制造者进行仓储、运输的话,则要注意一些隐形的包装需求。比如:跨国海运对木箱是否要进行熏蒸除虫;根据仓储地考虑室内防潮、防锈的处理等等,实际这些需求不仅会影响产品的包装,也可能会影响到产品本身的需求。对于这些包装的需求应首先参考国家或国际标准,进行设计、实施。
  对于产品包装,我们应尽可能做一些可靠性的实验,已验证包装的可靠性,比如:跌落试验、盐雾试验、防水等级实验等等。
  在工厂中为配合产品组件所做的调整,可能是在真是安装现场所做的不同,这时应对这些调整和原因进行记录。
  具体执行步骤:
  1、 审查需求、设计、产品、验证结果及文件,以确保影响产品包装与交付问题已被界定与解决。
  2、 利用有效方法包装与交付已集成的产品。
  3、 满足包装与交付产品的需求与标准。如:
  *存储与交付媒体的类型
  *软体原始及备份版本的保管信息
  *必要的文件(使用说明书、维护手册等)
  *版权(一般应在合同或说明书中明确)
  *提供的授权(该产品授权的范围,比如:不可以直接将该产品销售,但可以进行扩展开发其他功能后进行销售)
  *软件安全性
  4、 为产品安装准备场地
  这个准备安装场所,也可能是客户或最终用户的责任。
  5、 交付产品与其相关文件,并确定收到收据。
  6、 在安装场所进行安装,并确保正确操作。
  安装产品可能是客户或是最终用户的责任,比如现在的手机APP。但是也有些软件是在安装现场进行安装,用户只是使用。

阅读全文
cmmi度量指标

1.进度方面

实际进度的计划进度的偏差情况,Gantt图和Pert图。
返工时间占项目总时间的比例情况
项目能够容忍的最大的处理变更的时间
三级强调了偏差的范围,四级强调严格的上下限控制(控制图)

2.工作量

实际工作量和计划工作量的偏差
三级增加对好质量成本和坏质量成本相关工作量的度量(COGQ,COPQ)
对项目返工,评审,测试和处理变更工作量的分别度量

3.成本

计划成本和实际成本的偏差
三级强调了成本和进度的性能指示器(挣值分析)
三级强调了偏差的范围,四级强调严格的上下限控制(控制图)
五级强调了会提供可选择的过程改进和缺陷预防策略供选择,而这个是在对项目的成本和效益做了比较和平衡后得出的。

4.软件质量保证

不合格项的信息
SQA具体的审核信息

5.Review的结果

Review的活动项的状态

6.问题报告

问题项的具体状态(打开,处理,关闭)
问题的原因的分析,对问题的分类的统计
问题的平均处理周期度量

7.同行评审和缺陷

同行评审的缺陷的打开和关闭的情况统计
缺陷密度
缺陷移除率和缺陷泄漏率
同行评审的效率,评审速率的度量
同行评审的覆盖率
四级强调对缺陷分类后的帕累托分析
四级强调对同行评审的关键特征项的控制图分析

8.需求的度量

需求的规模的情况
需求的稳定度或需求的变更率
需求变更的不同类型的分布情况
需求变更处理的效率和周期度量

9.培训

实际安排课程和计划课程的对比
实际参与人员和计划参与人员的对比
对培训的成本和花费的度量
对培训取得的效果的度量

10.测试过程

测试的生产率的度量
测试规模的度量
对测试BUG的分类后的帕累托分析
生命周期不同阶段发现缺陷的数量分布,泄漏情况
测试BUG的密度

基础度量:

工作产品规模大小的估计及实际度量*(例如:页数)*

人力与成本的估计及实际度量*(例如:人时)*

质量度量*(例如:缺陷数、依严重程度区分的缺陷数)*

衍生度量:

挣值*(Earned Value)*

进度绩效指标*(SPI)*

缺陷密度

同行评审涵盖度

测试或验证涵盖度

可靠度度量*(例如:平均失败时间)*

质量度量*(例如:依严重程度区分的缺陷数/总缺陷数)

阅读全文
cmmi度量相关

度量分析

问题:
1.度量的目的是什么?
2.谁来做这个度量?
3.什么时候做这个度量?
4.如何做这个度量?
5.怎样记录度量的数据?记录到哪里?
6.谁会使用这些数据?
7.如何分析这些数据?
8.谁来分析这些数据?
9.分析的结果如何使用?

SG1: Measurement objectives and activities are aligned with identified information needs and objectives. 这个SG主要讲述的是,组织级要明确实际的需要,定出度量的目标,并根据此目标,定义合适的度量方法、过程等。

SP1.1: 建立和维护度量目标,这些度量目标是源自特定的需要的

Establish and maintain measurement objectives that are derived from indentified information needs and objectives.

如:质量、进度、成本是项目管理的三大要素,为了更好地管理这三个方面,可能需要分别对这些方面采取度量手段。也就是说,采取任何度量手段之前,要考虑清楚为什么要进行这个度量。

SP1.2: 制定度量办法满足度量目标的要求

Specify measures to address the measurement objectives.
明确了为什么要进行度量后,要把度量目标转化成可以实际操作的具体的度量办法。如:度量的目的是,要保证软件的质量,为了实现这么目标,定义出对缺陷进行度量、对评审发现的问题进行度量等度量办法。

SP1.3: 制定度量数据的收集及存储办法

Specify how measurement data will be obtained and stored.

SP1.4: 制定度量数据的分析和报告方法

Specify how measurement data will be analyed and reported.

SG2: Mesurement results the adreess identified information needs and objectives are provided. 这个SG主要讲述的是:根据组织级定义的要求,进行度量工作,收集、分析、存储、报告度量信息等。

SP2.1: Obtain specified measurement data.
收集指定的度量数据。
要根据SP1.3指定的收集办法来收集度量数据。

SP2.2: Analyze and interpret measurement data.
分析和说明度量数据。
根据SP1.4指定的办法,对度量数据进行分析,并说明这些数据的意义。

SP2.3: Manage and store measurement data,measurement specifications,and analysis results.
管理和存储度量数据、度量规范及度量结果。
根据SP1.3指定的存储办法,对度量数据及相关文档进行存储和管理。

SP2.4: Report results of measurement and analysis activities to all relevant stakeholders.
向相关人员报告度量结果及分析度量活动情况。
度量的数据、情况,需要让该知道的人知道。

SG1主要从组织级的角度定义度量的做法,SG2就是按照已定义的做法,在实际工作中开展度量的工作。

量化管理

  1. 初级量化管理-感知级,以数据“感知”项目的状况,相当于CMMI2级。

  2. 中级量化管理-经验级,通过经验值来管理项目,相当于CMMI3级。

  3. 高级量化管理-可预测级,用PCB进行项目管理,相当于CMMI4级。

  4. 超级量化管理-持续优化级,持续优化的量化管理,相当于CMMI5级。

“感知级”通过软件度量,大概了解项目的状况,并作为工作调整的依据。

“经验级”通过软件度量,对比项目的历史经验数据,把握项目的状况,并进行相应的工作调整。同时,项目的历史经验数据,可供估算等工作进行参考。

“可预测级”,把“经验级”推向一个更高的高度,对影响问题的因素进行详细的分析,排除和削弱影响项目性能的各种因素,对历史经验数据进行合理分组,统计出性能基线,并用于项目管理。用基线来管理的过程都是稳定的过程,这些过程从统计角度来说都可以准确地预测出将来的结果。

“持续优化级”是“数据管理过程”的最高级别,达到这个级别意味着企业能根据商业目标持续的优化SPC管理,使企业形成别的企业难以模仿并难以超越的核心竞争力。

如果你无法度量它,就无法管理它

CMMI级别中和BUG率相关的信息

CMMI级别 BUG率
CMM1级 11.95‰
CMM2级 5.52‰
CMM3级 2.39‰
CMM4级 0.92‰
CMM5级 0.32‰
考核千行代码Bug率的问题

从考核标准上来说,Bug率数值越小就说明越好,基于这个结果,会引导团队成员做出一些对长远和整体效率无益的行为,例如:

  1. 增大基数,增加无意义代码

  2. 把定长循环分开写,写成顺序方法

  3. 把可配置信息写死到代码中

  4. 大量的复制、粘贴代码

  5. 重新发明各种轮子

统计“千行代码Bug率”和“每日生产代码行数”一样,都是没经过大脑思考,而直接打算把优秀员工踢出团队的懒人式管理方式。特别是对从事智力型工作工程师来说,是很不合适的考量指标。

优秀的程序员是通过减少代码行数来增加功能的。

千行代码Bug率,虽然没有明确鼓励增加代码行数,但是这个计算结果对于优秀的员工来说是相当的不公平。它隐含的推广了“尽量增大代码行数”这个意思。

其次,从考核阶段看,Bug率的数据主要产出在研发阶段的后期,及提交测试后产出bug数。从项目的研发阶段和效率价值金字塔来看,其对项目的整体质量方面更多的聚焦在微观层面问题,整体的质量的影响范围会较小。而前面几个阶段的缺陷,会影响整个项目的进度,甚至导致项目失败,管理者和团队更应该将风险控制和度量指标向前移。

研发阶段和效率价值金字塔

需求调研和评审>技术方案设计和评审>研发>测试

如何更合理的度量质量

如果考核千行代码Bug率不能很好的解决质量核心问题,那我们还有那些方法和方案来提高项目的整体质量呢?

个人觉得,我们还是从项目的研发阶段和效率价值金字塔出发,重整体上去把控质量,上下游一体,从源头开始:

  1. 需求的评审

  2. 架构设计方案评审

  3. 代码模块设计,包的依赖的规划,接口的设计的review

  4. 代码的review的机制

  5. 测试用例评审

  6. 使用代码检测工具,自动发现问题

过程评审是最有效也是成本最低的质量和效率保证和提升的手段。另外,过程评审还是迅速提高新人能力及其成果物的规范性的一个有效手段。

但是过程评审,也存在一些问题:

  1. 前期过度依赖于团队的人员素质

  2. 规则的定义也比较难,产出不好量化

  3. 评审耗时多

  4. 团队的意识不一致

过程评审的实施核心在用统一团队意识

团队意识不一致时,效果一定不好。 意识不一致,在资源的投入上就会缩手缩脚;只有把过程评审做到位,才能体会到评审活动的高效,避免那种走马观花式的“评审”,是浪费时间,不是真正的评审。过程中辅以严密的变更管理和风险控制手段,系统质量出大问题可行性会很小或者近乎为零。

系统质量是要靠上游工程做出来的

上游的工作质量会更为重要,上游的问题的影响范围将更广,对效率和价值的影响更大,应该是我们重点关注的地方。仅仅依赖下游工程(种种测试)来把质量关,是十分低效,而且代价是非常昂贵的。

总结

有效的管理很难绕开度量问题。在选择度量指标上,大部分管理者总是倾向于关注容易度量的指标,而忽略难以度量的指标。但是容易度量的指标不一定是重要的,难以度量的反而可能是重要的。

定性、定量的区别比较,定性是用文字说话,定量是用数字说话,两者侧重点不同,但各有各的好处。虽然已经量化了,但数据有时也可以骗人,量化是一种方法和手段,但并不是最终的目的。

代码行数<>价值。

考核不合理导致出现大量的复制,不合理的设计,大量的冗余,不但难以理解和维护,甚至没有实际运行起来。这样就造成大量的时间浪费,同时也造成质量的严重腐化。

而基于全过程的评审机制和持续改进方法,可以很好的改善质量。但持续改进需要一个过程,需全团队从认知达成一致,并共享问题,统一步调和规范,持续的执行和改进。

千行代码Bug率比较适用工程师自身自我评估和改进

1.进度方面

实际进度的计划进度的偏差情况,Gantt图和Pert图。
返工时间占项目总时间的比例情况
项目能够容忍的最大的处理变更的时间
三级强调了偏差的范围,四级强调严格的上下限控制(控制图)

2.工作量

实际工作量和计划工作量的偏差
三级增加对好质量成本和坏质量成本相关工作量的度量(COGQ,COPQ)
对项目返工,评审,测试和处理变更工作量的分别度量

3.成本

计划成本和实际成本的偏差
三级强调了成本和进度的性能指示器(挣值分析)
三级强调了偏差的范围,四级强调严格的上下限控制(控制图)
五级强调了会提供可选择的过程改进和缺陷预防策略供选择,而这个是在对项目的成本和效益做了比较和平衡后得出的。

4.软件质量保证

不合格项的信息
SQA具体的审核信息

5.Review的结果

Review的活动项的状态

6.问题报告

问题项的具体状态(打开,处理,关闭)
问题的原因的分析,对问题的分类的统计
问题的平均处理周期度量

7.同行评审和缺陷

同行评审的缺陷的打开和关闭的情况统计
缺陷密度
缺陷移除率和缺陷泄漏率
同行评审的效率,评审速率的度量
同行评审的覆盖率
四级强调对缺陷分类后的帕累托分析
四级强调对同行评审的关键特征项的控制图分析

8.需求的度量

需求的规模的情况
需求的稳定度或需求的变更率
需求变更的不同类型的分布情况
需求变更处理的效率和周期度量

9.培训

实际安排课程和计划课程的对比
实际参与人员和计划参与人员的对比
对培训的成本和花费的度量
对培训取得的效果的度量

10.测试过程

测试的生产率的度量
测试规模的度量
对测试BUG的分类后的帕累托分析
生命周期不同阶段发现缺陷的数量分布,泄漏情况
测试BUG的密度

基础度量:

工作产品规模大小的估计及实际度量*(例如:页数)*

人力与成本的估计及实际度量*(例如:人时)*

质量度量*(例如:缺陷数、依严重程度区分的缺陷数)*

衍生度量:

挣值*(Earned Value)*

进度绩效指标*(SPI)*

缺陷密度

同行评审涵盖度

测试或验证涵盖度

可靠度度量*(例如:平均失败时间)*

质量度量*(例如:依严重程度区分的缺陷数/总缺陷数)*

阅读全文
cmmi测试相关

测试阶段

验证意味着每个阶段结束后,对软件产品的技术审查和管理评审,确认则是对每个阶段结束后所产生的代码进行测试

1.软件需求分析阶段

基于“软件测试介入要及早”的原则,在软件需求分析阶段,软件测试人员就可以加入到软件需求分析和确认的行列中,并在该阶段结束后,参与本阶段软件产品的评审。在该阶段,并没有软件代码产生,所以主要的软件产品就是文档。本阶段产生的跟软件测试关系密切的文档是软件需求规格说明和软件开发计划,根据这两份文档,测试人员可以出具软件配置项测试计划,在计划中明确测试类型,测试方法,测试环境,以及测试人员和进度安排

2.软件设计阶段

在软件概要设计阶段,软件人员主要参与的测试活动是评审软件概要设计和软件集成计划文档,并出具软件集成测试计划。同样,在软件详细设计阶段,软件人员参与评审软件详细设计文档,并出具软件单元测试计划

3.软件编码及后续测试阶段

在这个阶段,软件代码已产生,可以按照单元测试计划,拟制单元测试用例,执行单元测试,出具单元测试报告。在单元测试阶段,建议进行代码走查,这是对软件代码的确认。自此以后的阶段,软件确认和验证的对象就都是代码

单元测试完成后,对该阶段的软件产品进行确认,相关文档该评审就评审,该入受控库就入受控库,经软件配置确认后,转入集成测试阶段。

依照集成测试计划,拟制集成测试用例说明,可对软件单元按照某种恰当的集成策略进行组装。在这个阶段,产生集成测试报告。这是该阶段软件验证和确认的成果。同样,集成测试完成后,对该阶段的软件产品也要进行确认并入受控库,经软件配置确认后,转入配置项测试阶段。

软件配置项测试以需求阶段产生的测试计划为依据,拟制配置项测试说明,执行以黑盒为主的配置项测试,出具配置项测试报告。测试完成后,提交配置管理,确认后等待软件交付。(文档审查,静态分析,内存使用缺陷测试,功能测试,性能测试,人机界面测试,余量测试,接口测试,安全性测试)依据需求规格说明书

验证(VER)

是为了确认某一开发阶段的产品是否满足在阶段初期提出的要求而进行评估的过程,验证就是证明是否正确地构造了产品

​ SG1 准备验证

​ SP1.1 选择需要验证的工作产品

​ SP1.2 建立验证环境

​ SP1.3 建立验证规程与准则

​ SG2 执行同级评审

​ SP2.1 准备同级评审

​ SP2.2 进行同级审评

​ SP2.3 分析同级评审数据

​ SG3 验证选定的工作产品

​ SP3.1 执行验证

​ SP3.2 分析验证结果

验证就是按照既定的标准,检查工作产品是否符合要求。工作产品可能是文档也可能是软件本身。而检查的办法一般是同行评审或者是软件测试。

那什么是同行评审呢?比方说:A君是做软件设计的,B君也是做软件设计的,A君写了一份设计文档,让B君这个同行(因为大家都是做设计的)来给给意见,这样就使同行评审。同行评审的目的就是让有同样工作经验和技能的人来评审自己的工作产品,发现尽量多的问题。

验证这个PA其目的是希望软件企业在软件开发整个过程中,做好相应的检查工作,把尽量问题发现前面,保证了项目的可控性,降低开发的成本。

这个PA有3个Specific Goals,SG1讲述的是做好验证的准备,SG2、SG3分别讲述的是执行验证的两种办法,一种是同行评审,一种是执行验证(通常就是测试)。

如果测试是在用户实际生产环境下进行的,例如:验收测试、客户试用系统等,这时这类工作就属于确认(Validation)

SG1 准备验证的工作

Preparation for verification is conducted.

SP1.1 选择需要验证的工作产品以及每个工作产品的验证办法

Select the work products to be verified and the verifaction methords that will be used for each.
组织会定义要进行同行评审的工作产品,如:计划文档、需求文档、设计文档、代码等,并且规定了每种文档的同行评审办法。组织也会
定义需要进行测试的软件产品,比方说要进行单元测试、集成测试、系统测试等。

SP1.2 建立和维护支持验证所需的环境

Establish and maintain the environment needed to support verification.
对于同行评审来说,支持环境可能就是会议室、投影、电脑、事先准备好的文档等。
对于测试来说,支持环境可能就是测试的软件环境、数据环境、硬件环境等。

SP1.3 建立和维护工作产品的验证过程及准则

Establish and maintain verification procedures and criteria for the selected work products.

对于同行评审来说,验证过程就是同行评审开展的过程相关规定,如要事先发资料、通知大家到会、会议的组织、会议记录等等,准则可能就是每个工作产品的评审标准。
对于测试来说,验证过程就是测试过程的相关规定,准则就是需求规格说明书,或者说是测试通过的标准。

SG2 对指定的工作产品进行同行评审

Peer reviews are performed on selected work work products.

SP2.1 做好同行评审的准备

Prepare for peer reviews of selected work products.
如:把要评审的文档实现发给大家,准备好会议议程,准备好会议室、投影仪等。

SP2.2 执行同行评审并识别同行评审中发现的问题

Conduct peer reviews on selected work products and identify issues resulting from the peer review.

SP2.3 分析在同行评审准备、执行、结果方面的数据

Analyze data about preparation,conduct,and results of the peer reviews.
例如:记录评审的准备、进行时间,发现的问题数量,对每个问题进行分析等。

SG3 根据指定的要求验证工作产品

Selected work products are verified against their specified requirements.
这里的验证既包括同行评审也包括测试,但因为SG2专门是针对同行评审的,这个SG可以理解成主要针对除了同行评审外的其它验证活动。

SP3.1 对指定的工作产品进行验证

Perform verification on the selected work products.
如:执行单元测试、集成测试、系统测试等。

SP3.2 分析验证的结果,并制定修正计划

Analyze the results of all verification activities and identify corrective action.
这里强调的是:除了要分析发现的问题外,还需要采取行动修正这些问题。

确认( VAL )

是在开发过程中或结束时,对软件产品进行评估以确定其是否满足软件需求规格的要求,确认则是证明构造的产品是否正确

​ SG1 准备确认

​ SP1.1 选择需要确认的产品

​ SP1.2 建立确认环境

​ SP1.3 建立确认规程与准则

​ SG2 确认产品或产品组件

​ SP2.1 执行确认

​ SP2.2 分析确认结果

验证强调的是在开发过程中对工作产品进行检查,尽早发现问题。而确认强调的是,在真实的使用环境中,确保软件能达到预期的效果。开发环境与真实环境是不可避免存在差异的,为了有效地避免在开发环境中没有问题,但一到真实环境就出现问题的情况,确认的工作是非常重要的。

确认不一定在项目后期才进行,这个PA没有对确认的时间有任何的规定。作为一般的常识,我们应该尽快安排软件的确认工作,如:尽快发出一个小版本,在实际环境中运行起来,尽快发现确认中的问题。
一般来说,调试、试用、验收测试等都是确认的工作。

SG1 准备确认工作

Preparation for validation is conducted.

SP1.1 选择需要确认的产品、产品组件以及确认的方法

Select products and product components to be validated and the validation methods that will be used for each.

SP1.2 建立和维护支持确认的环境

Establish and maintain the environment needed to support validation.
如试用环境、验收环境的准备等。

SP1.3 建立和维护确认的过程及确认准则

Establish and maintain procedures and criteria for valication.

SG2 执行确认,确保产品或者产品组建在目标操作环境下满足使用的要求

The product or product components are validated to ensure that they suitable for use in their intended operating environment.

SP2.1 执行产品及产品组建的确认工作

Perform validation on the selected products and product components.

验证(Verification)与确认(Validation)的区别

验证:验证检查某样东西是否符合之前已定好的标准,如:文档评审,要检查的东西是文档,检查标准就是文档的评审标准,又如:测试软件,要检查的东西就是软件,检查的标准就是软件的规格说明,包括功能说明,性能要求等。

确认:检查软件在最终的运行环境上是否达到预期的目标。一般来说,就是调试、验收测试等,这些工作都是在真正的软件需要运行的环境上进行的,在最终环境上运行软件,确保软件符合使用要求。

阅读全文
cmmi过程域概述

各级别整体能力

CMMI5:进行根本原因分析,消除编差发生的普遍原因,改善过程能力基线,制度化过程改进活动。

CMMI4:建立过程控制方法,建立过程能力基线,消除编差发生的特殊原因。

CMMI3:验证数据,分析度量结果;对组织层面指定的度量确定目标值;制度化度量活动。

CMMI2:基于度量目标,建立一个覆盖过程、产品、和项目的度量框架,并实施度量。

等级与对应过程域

CMMI(Capability Maturity Model Integration):能力成熟度模型整合

CMMI将能力成熟度分为5个级别:初始级,已管理级,已定义级,量化管理级,优化级。

除了成熟度等级,CMMI还有一个重要的概念是过程域(Process Area)。过程域指出了达到某个成熟度等级必须要解决的一族问题。除了初始级以外,每个成熟度等级都有若干个过程域,如下表所示。由于成熟度等级是循序渐进的,如果想达到某个成熟度等级,例如CMMI 3级,除了满足CMMI 3级本身11个过程域之外,还要满足CMMI 2级的7个过程域,依此类推。

CMMI等级 过程域中文名称 过程域英文名称 过程类型
第2级已管理级 7个过程域 需求管理 Requirements Management 工程
项目规划 Project Planning 项目管理
项目监控 Project Monitoring and Control 项目管理
供应商协议管理 Supplier Agreement Management 项目管理
度量分析 Measurement and Analysis 支持
过程和产品质量保证 Process and Product Quality Assurance 支持
配置管理 Configuration Management 支持
第3级 已定义级 11个过程域 需求开发 Requirements Development 工程
技术方案 Technical Solution 工程
产品集成 Product Integration 工程
验证 Verification 工程
确认 Validation 工程
组织过程焦点 Organizational Process Focus 过程管理
组织过程定义 Organizational Process Definition 过程管理
组织培训 Organizational Training 过程管理
集成化项目管理 Integrated Project Management 项目管理
风险管理 Risk Management 项目管理
决策分析与解决方案 Decision Analysis and Resolution 支持
第4级量化管理级 2个过程域 组织过程性能 Organizational Process Performance 过程管理
量化项目管理 Quantitative Project Management 项目管理
第5级优化级 2个过程域 组织革新与推广 Organizational Innovation and Deployment 过程管理
原因分析与解决方案 Causal Analysis and Resolution 支持

PA (Process Area):过程域;
EPG (Engineering Process Group):工程过程小组;
PM (Project Manager):项目经理;
PP (Project Plan):项目规划;
PMC (Project Monitoring and Control):项目监控;
RM (Requirements Management):需求管理;
MA (Measurement and Analysis):度量;
CM (Configuration Management):配置管理(文档与代码管理);
QA (quality assurance):质量保证;
PPQA (Process and Product Quality Assurance):流程与产品质量保证;
RD (Requirements Development):需求开发;
REQM (Requirements ManagementTS ):需求管理;
TS (Technical Solution):技术解决方案(设计和实现);
PI (Product Integration):产品整合;
VER (Verification):验证(评审和测试);
VAL (Validation): 确认(验收);
IPM (Integrated Project Management): 集成项目管理;
RSKM (Risk Management):风险管理;
OPF (Organizational Process Focus):组织过程焦点;
OPD (Organizational Process Definition): 组织过程定义;
OT (Organizational Training):组织培训;
DAR (Decision Analysis and Resolution):决策分析与制定;

CMMI DEV V2.0的PA 与V 1.3的映射关系

CMMI 2.0实践域 CMMI 1.3 过程域 备注
CAR CAR -
CM CM -
DAR DAR -
EST - 新增PA,从PP中剥离出来
GOV - 1.定义了公司高层经理的活动2.来自于V1.3的共性实践
II - 来自于V1.3的共性实践
MPM MA 所有定量管理的实践都合并到MPM中
QPM
OPP
OPM
MC PMC 1.风险跟踪的实践剥离到RSK中2.IPM中有关跟踪的实践汇总到本PA,如管理关键依赖、环境等3.里程碑评审不再出现在实践名字中
OT OT -
PR - 新增PA,从VER中剥离出来
PLAN PP 1.名称修改2.估算的实践剥离成为一个单独的PA3.数据管理的实践剥离到CM中4.风险管理的实践剥离到RSK中5.IPM中与策划有关的实践汇总到本PA6.增加对移交活动的计划
PAD OPD 1.名称修改2.删除了建立团队运作规则指南的实践
PCM OPF 有些实践来自于OPM,改了名字
PQA PPQA 名称修改
PI PI -
RDM RD 所有的需求工程实践都合并到RDM中
REQM
RSK RSKM RSK 是风险和机会管理,增加了机会管理
SAM SAM -
TS TS -
VV VER 合并为VV,同行评审独立成为一个PA
VAL
- IPM IPM拆分到PLAN和MC中

过程域对应活动

一、项目管理类:

1 、项目策划( PP ):

SG1 完成参数估计

​ SP1.1 估计项目的范围 SP1.2 估计项目属性 SP1.3 确定项目生存周期 SP1.4 确定工作量和成本的估计值

SG2 拟订项目计划

​ SP2.1 编制预算和进度 SP2.2 识别项目风险 SP2.3 策划数据管理 SP2.4 策划项目资源 SP2.5 策划必要的知识和技能 SP2.6 策划共利益者的介入 SP2.7 拟订项目计划

SG3 获得对计划的承诺

​ SP3.1 审查从属计划 SP3.2 使工作与资源配备协调 SP3.3 获得计划承诺

2 、项目监督和控制( PMC ):

SG1 对照计划监督项目

​ SP1.1 监督项目策划参数 SP1.2 监督承诺 SP1.3 监督项目风险 SP1.4 监督资料管理 SP1.5 监督共利益者介入情况 SP1.6 进行进展审查 SP1.7 里程碑审查

SG2 管理纠正措施,直到结束

​ SP2.1 分析问题:收集并分析问题,确定处理这些问题所需的纠正措施

​ SP2.2 采取纠正措施:对所识别的问题采取纠正措施

3 、集成项目管理( IPM ) +IPPD

SG1 运用项目已定义过程

​ SP1.1 建立项目已定义过程 SP1.1 运用组织过程财务策划项目活动 SP1.1 建立项目工作环境 综合计划 SP1.1 运用综合计划管理项目 SP1.1 充实组织过程财富

SG2 与相关的共利益者协调和合作

​ SP2.1 管理共利益者介入 SP2.2 管理依存关系 SP2.3 解决协调问题

SG3IPPD 应用(应用 IPPD 原则)

​ SP3.1 建立项目的共同愿景 SP3.2 建立集成团队架构 SP3.3 分配需求至集成团队 SP3.4 建立集成团队 SP3.5 确保跨团队间的合作

4 、供方协定管理( SAM )

SG1 建立供方协定

​ SP1.1 分析由项目所决定的需求 SP1.2 选择供方 SP1.3 建立供方协定

SG2 满足供方协定

​ SP2.1 执行供方协定 SP2.2 监督选定的供方过程 SP2.3 评估选定的供方工作产品 SP2.4 接受取得的产品 SP2.5 移交产品

5 、风险管理( RSKM )

​ SG1 准备风险管理

​ SP1.1 确定风险来源和类别 SP1.2 定义风险参数 SP1.3 建立风险管理战略

​ SG2 识别和分析风险

​ SP2.1 识别风险 SP2.2 对风险进行评价、分类和排列优先顺序

​ SG3 缓解风险

​ SP3.1 拟订风险缓解方案 SP3.2 实施风险缓解

6 、定量项目管理 (QPM)

​ SG1 定量管理项目

​ SP1.1 建立项目目标 SP1.2 组成已定义过程 SP1.3 选择将予以管理的子过程 SP1.4 管理项目性能

​ SG2 对子过程进行统计管理

​ SP2.1 选择度量值和分析技术 SP2.2 运用统计方法,以掌握变化情况 SP2.3 监督所选择的子过程的性能 SP2.4 记录统计管理数据

二、工程类

1 、需求管理( RM )

​ SG1 管理需求

​ SP1.1 理解需求:与需求的提供者对需求的含义达成一致

​ SP1.2 获得对需求的承诺:获得项目组成员对需求的承诺

​ SP1.3 管理需求的变更:在项目进行中,管理需求的变更

​ SP1.4 维护需求的双向可跟踪性:维护需求和工作产品之c间的双向可跟踪性

​ SP1.5 确定项目工作和需求间的差异:识别项目计划、工作产品和需求之间的不一致

2 、需求开发( RD )

​ SG1 开发客户需求:收集共同利益者的需求、期望、限制条件和接口,并且把它们转换成客户需求。

​ SP1.1 获得客户需求:导出产品生存周期所有阶段共利同益者的需求、期望、限制条件和接口。

​ SP1.2 生成客户需求:把共同利益者的需求、期望、限制条件和接口转换成客户需求。

​ SG2 开发产品需求:对客户需求加以精炼和细化,以便开发产品生存周期中的产品和产品构件需求。

​ SP2.1 建立产品需求和构件需求:根据客户需求,为保证产品和产品构件的有效性和可提供性,确定产品和产品构件需求。

​ SP2.2 分配产品构件需求:为每个产品构件分配需求。

​ SP2.3 确定接口需求:确定功能之间或对象之间的接口。

​ SG3 分析和确认需求:对各项需求进行分析和确认,并且开发所要求的功能度的定义。

​ SP3.1 建立操作概念和场景:建立并维护操作概念和场景。

​ SP3.2 定义功能需求:建立并维护所要求的功能度的定义。

​ SP3.3 分析需求:分析派生的需求,确保它们是必要的和充分的。

​ SP3.4 平衡需求:分析需求,平衡共同利益者的需求和约束。

​ SP3.5 确认需求:在适当时候,采用多种技术确认需求,以确保将要产生的产品能在预计的用户环境中恰当运行。

3 、技术解决( TS )

​ SG1 选择产品构建解决方案

​ SP1.1 开发详细候选解决方案和选择准则 SP1.2 开发操作概念和场景 SP1.3 选择产品构件解决方案

​ SG2 设计

​ SP2.1 运用有效的设计方法 SP2.2 建立完备的技术数据包 SP2.3 设计综合性接口 SP2.4 进行制作、购买或复用分析

​ SG3 实现产品设计

​ SP3.1 实现设计 SP3.2 编制产品支持文档

4 、产品集成( PI )

​ SG1 准备产品集成

​ SP1.1 建立产品集成战略 SP1.2 建立产品集成环境 SP1.3 规定详细的产品集成规程

​ SG2 确保接口兼容性

​ SP2.1 审查接口描述的完备性 SP2.2 管理接口

​ SG3 组装产品构件和交付产品

​ SP3.1 确认集成用的产品构件已经准备就绪 SP3.2 组装产品构件 SP3.3 核查组装的产品构件 SP3.4 打包和交付产品或产品构件

5 、验证( VER )

​ SG1 准备验证

​ SP1.1 选择需要验证的工作产品

​ SP1.2 建立验证环境

​ SP1.3 建立验证规程与准则

​ SG2 执行同级评审

​ SP2.1 准备同级评审

​ SP2.2 进行同级审评

​ SP2.3 分析同级评审数据

​ SG3 验证选定的工作产品

​ SP3.1 执行验证

​ SP3.2 分析验证结果

6 、确认( VAL )

​ SG1 准备确认

​ SP1.1 选择需要确认的产品

​ SP1.2 建立确认环境

​ SP1.3 建立确认规程与准则

​ SG2 确认产品或产品组件

​ SP2.1 执行确认

​ SP2.2 分析确认结果

三、组织过程类:

1 、组织过程定义( OPD )

​ SG1 建立组织过程资产

​ SP1.1 建立标准过程 SP1.2 建立生命周期模型描述 SP1.3 建立裁剪准则及指南 SP1.4 建立组织度量库 SP1.5 建立组织过程资产库 SP1.6 建立工作环境标准

​ SG2 促成 IPPD 管理

​ SP2.1 建立授权机制 SP2.2 建立集成团队规则与指南 SP2.3 平衡团队与原隶属组织的责任

2 、组织过程聚焦( OPF )

​ SG1 确定过程改进机会

​ SP1.1 确定组织的过程需求 SP1.2 评估组织的过程 SP1.3 识别组织的过程改进项目

​ SG2 策划和实施过程改进活动

​ SP2.1 制定过程行动计划 SP2.2 实施过程行动计划 SP2.3 部署过程和相关的过程财富 SP2.4 把过程相关的经验纳入本组织的过程财富

3 、组织培训( OT )

​ SG1 确定培训需求并且使培训现成可用

​ SP1.1 确定战略培训需求 SP1.2 确定有哪些培训需求由组织负责满足 SP1.3 建立组织培训战术计划 SP1.4 建立培训能力

​ SG2 提供必要的培训

​ SP2.1 交付培训 SP2.2 建立培训记录 SP2.3 评价培训效果

4 、组织过程性能( OPP )

​ SG1 建立性能基线和模型

​ SP1.1 选择过程 SP1.2 建立过程性能度量值 SP1.3 建立质量和过程性能目标 SP1.4 建立过程性能基线 SP1.5 建立过程性能模型

5 、组织革新与部署( OID )

​ SG1 选择改进项目

​ SP1.1 收集和分析改进建议 SP1.2 识别革新 SP1.3 试行改进 SP1.4 选择改进建议,用于部署

​ SG2 部署改进

​ SP2.1 策划部署 SP2.2 管理部署 SP2.3 度量改进效果

四、支持类

1 、过程和产品质量保证( PPQA )

​ SG1 客观评价过程和工作产品

​ SP1.1 客观评价过程 SP1.2 客观评价工作产品和服务

​ SG2 客观提供情况

​ SP2.1 通报不符合问题,并且确保解决它们 SP2.2 建立记录

2 、配置管理( CM )

​ SG1 建立基线

​ SP1.1 识别配置项 SP1.2 建立配置管理系统 SP1.3 建立或放行基线

​ SG2 跟踪并控制变更

​ SP2.1 跟踪变更 SP2.2 控制变更

​ SG3 建立完整性

​ SP3.1 建立配置管理记录 SP3.2 进行配置审计

3 、测量和分析( MA )

​ SG1 协调测量和分析活动

​ SP1.1 建立测量目标 SP1.2 详细说明度量值 SP1.3 说明数据收集和存储规程 SP1.4 规定分析规程

​ SG2 提供度量结果

​ SP2.1 收集度量数据 SP2.2 分析度量数据 SP2.3 存储数据和结果 SP2.4 通报分析结果

4 、决策分析和决定( DAR )

​ SG1 评价候选方案

​ SP1.1 拟订并运用决策分析的指导原则 SP1.2 选择评价技术 SP1.3 拟订评价准则 SP1.4 确定推荐的侯选方案 SP1.5 评价候选方案 SP1.6 选择解决方案

5 、原因分析和决定( CAR )

​ SG1 确定缺陷的原因

​ SP1.1 选择缺陷数据,用于分析、选择缺陷和其他问题,以供分析使用 SP1.2 分析原因

​ SG2 处理缺陷原因

​ SP2.1 实施措施建议 SP2.2 评价变更的效果 SP2.3 记录数据

阅读全文
测试方案,策略,计划,用例

测试计划提出“做什么”,测试方案明确“如何做”,测试方案需要在测试计划的指导下进行。

测试计划

是对测试全过程的组织、资源、原则等进行规定和约束,并制定测试全过程各个阶段的任务以及时间进度安排,并提出对各项任务的评估、风险分析和管理需求。简言之,测试计划是从管理角度对整个测试活动进行规划和控制。

内容

背景、项目简介、目的、测试范围、测试策略、人员分工、资源要求、进度计划、参考文档、常用术语、提交文档、风险分析

1.概述
项目背景、测试范围(所需测试的特性)、参考文档(需求文档、会议记录、同类项目的参考说明)
2.组织形式
测试涉及人员及其职责的划分
3.测试范围
确定被测特性有哪些,然后按照功能性、非功能性的分类,对系统模块&子模块进行划分,重要级别的设置
4.测试通过与否的标准
根据对测试系统的预判,与项目经理协商并由其确认来定义项目通过&不通过的准则(如:测试覆盖率、缺陷修复率…)
5.测试挂起&恢复条件
1)测试挂起:考虑测试过程中发生一些内外部问题致使测试受阻,用例无法执行的情形,由项目经理确认
2)测试恢复:导致阻塞的问题确认已被修复后,由项目经理确认恢复测试
6.测试进度人力分布计划
计划编制原则:
1)尽量准确预估整个测试活动所需的人力和持续时间
2)讲一个阶段分成若干个能进行有效监控的小阶段
3)计划结构和进度须清晰明了,便于阅览、检查
4)结构包括:任务、负责人、检查人、时间进度条

制定项目测试过程中的测试重点,各个阶段的任务分配以及时间进度安排,并提出对各项任务的评估,风险分析,可以包括测试策略。

测试方案

是描述被测对象需要测试的特性、测试的方法、测试环境的规划、测试工具的设计和选择、测试用例的设计方法、测试代码的设计方案。简言之,测试方案是从技术角度对整个测试活动进行规划和控制。

内容

1.概述
描述软件项目的背景(如:项目名称、项目时间、项目目的)、测试范围、参考文档
2.测试环境
1)软硬件环境
硬件设备:电脑配置、无线路由器、手机…
软件设备:应用服务器、数据库服务器-型号&版本
2)网络构成
测试环境的网络结构、拓扑图
3)环境搭建
测试所需的环境搭建步骤、要求、注意事项
4)测试工具
所需的测试工具,如:LR、Jmeter、Postman、AppScan、AWVS…
3.测试策略
说明此项目将要采取哪些测试手段与方法
结构包括:功能性/非功能性-系统模块&子模块、测试要点、测试要点说明、测试数据描述、优先级、测试方法、用例设计方法
4.测试风险评估与预防
评估项目测试过程中可能存在的风险,设置不同的风险等级,并提前分析相应的预防措施
结构包括:风险描述、风险等级、风险来源、产生阶段、预防措施、对策责任人

侧重测试的方法,测试环境的规划,测试工具的设计和选择,测试用例的设计方法,测试代码的设计方案。

测试策略

如何用尽量少的资源来尽量好的完成测试,给测试活动提供技术上的明确指导,以便测试活动的实施者能够很快的开展自己的工作。

侧重需求分析,评估风险,定义测试范围,确定测试方法,制定测试启动、停止、完成标准和条件。

宏观角度:在不同的项目背景下,根据产品需求和指标,分析产品的功能项和业务逻辑,并判断测试的重点和方向,在当前有限的条件下,统筹各方资源、采取合理有效的方法来推动项目的测试活动开展,以最少的软硬件、人力资源投入得到最佳的测试效果,达到符合当前环境的最优决策。

微观角度:可以归属到测试方案中的一个重要组成项,通过采用有效的测试手段与方法,对产品模块&子模块进行划分,明确测试要点,然后按照功能性与非功能性(易用性、兼容性、性能、安全性…)的分类,明确所采用的测试方法(黑盒/白盒/单元/集成/系统/回归/验收…)、用例设计方法(等价类、边界值、流程分析法、),并设置不同的测试优先级,从而指导后面编写测试用例等工作的开展。

测试用例

根据测试计划,制定完成测试任务的具体测试步骤。

测试用例设计的原则

代表性:能够代表并覆盖各种合理的和不合理、合法的和非法的、边界的和越界的、以及极限的输入数据、操作和环境设置等.

可判定性:即测试执行结果的正确性是可判定的,每一个测试用例都应有相应的期望结果.

可再现性:即对同样的测试用例,系统的执行结果应当是相同的。

阅读全文
cmmi需求相关

需求阶段

需求管理( RM )

SG1 管理需求

SP1.1 理解需求:与需求的提供者对需求的含义达成一致

SP1.2 获得对需求的承诺:获得项目组成员对需求的承诺

SP1.3 管理需求的变更:在项目进行中,管理需求的变更

SP1.4 维护需求的双向可跟踪性:维护需求和工作产品之间的双向可跟踪性

SP1.5 确定项目工作和需求间的差异:识别项目计划、工作产品和需求之间的不一致

常见问题

1.因为项目进度赶等原因,在很多需求还没有明确情况下,便开始开发的工作。
2.开始客户只能提出模糊的需求,客户喜欢先让你做个东西给他看,然后他才可能逐渐提出真正的需求,而需求调研人员,对此没有什么好的处理办法。
3.客户以种种原因不签需求,项目组在不签需求的情况下,便开始开发工作。
4.客户不承认之前提出来的需求,项目组又不能得失客户,项目成员苦不堪言。
5.需求经常变化,无法控制。
6.设计、代码与需求不对应,特别是需求变更时,不知道应该修改哪部分,也不知道会有哪些影响。

SG1

管理需求并且识别出需求与项目计划、工作产品不一致的地方。

1.需求要被管理,被管理的意思又有两层:一是需求要被确认,二是要控制需求变更

2.需求要用来指导下游的工作产品,如:计划、设计、测试等

SP1.1:理解需求。

Develop an understanding with the requirements providers on the meaning of the requirements.

开发者应该理解客户的需求,如果这点做不到,后面的工作是没有意义的。所以,那种在没有理解需求的情况下,就仓促开发的做法是不合适的。

当然,如果想通过做原型来获取需求不在此列,另外,大家也千万不要误解,在没有完全理解需求前一定不能开展开发工作,如果部分需求已经掌握,有部分需求还没有掌握,那也是可以先开展已掌握部分需求的设计、编码工作的,这时需要考虑没有确定部分的需求对这些工作可能带来的影响。

SP1.2:确认需求

Obtain commitment to the requirements from the project participants.

就是要和客户签署需求。

我想大家都非常理解这点的重要性,但大家可能会说,说得容易,客户就是不签,咋办?客户不签需求,主要是两方面的原因:

1)客户不确定需求。

2)客户担心签了需求后,他就不好变了。

把SP1理解需求做好,可以参考需求开发(RD)

消除客户的顾虑,签署需求是双方约束,另外需求是可以变的,现在签署只是标志着当前的一个工作里程碑,当前签订的需求作为后续工作的基准。

SP1.3:管理需求变更

Manage changes to the requirements as they evolve during the project.

需求不是不可以变,只不过需要管理。

1.要充分理解客户提出来的需求变更,深究其原因,不能客户一说变就变,超过一半的客户变更要求,其实都是不合理的,或者是有其它更好的替代办法的。

2.变更要求,要有记录和确认

3.需求变更的影响,包括增加的工作量,风险等。要有清单并确认

4.需求变更导致项目成本和进度变化太大,走决策

SP1.4 :维护需求的双向跟踪

Maintain bidirectional traceability among the requirements and the project plans and work products.

需求是用来指导后续工作的,所以需求与计划、设计、编码、测试等后续工作都需要维护好对应的关系,与SP1.3关系密切

双向跟踪是指纵向和横向跟踪,纵向跟踪的意思是上下游工作产品之间的跟踪关系。而横向跟踪指的是需求与需求之间的关系、设计与设计之前的关系、代码与代码之间的关系等。其中一个需求变化了,有可能影响另外一些需求,其中一个设计变了也可能影响另外一些设计。

这是个双向跟踪网络,任何一点发生变化,能找出全部受牵连的地方。

SP1.5:识别出需求与下游工作产品不一致的地方

Identify inconsistencies between the project plans and work products and the requirements.

1.需求变更时,利用双向跟踪表找出需要修改的地方,并用跟踪表来发现不一致的地方并调整。

2.编写或者修改计划、设计、代码、测试计划、测试用例等需求下游工作产品的时候,要注意要与需求保持一致。

需求开发( RD )

内容:

​ SG1 开发客户需求:收集共同利益者的需求、期望、限制条件和接口,并且把它们转换成客户需求。

​ SP1.1 获得客户需求:导出产品生存周期所有阶段共利同益者的需求、期望、限制条件和接口。

​ SP1.2 生成客户需求:把共同利益者的需求、期望、限制条件和接口转换成客户需求。

​ SG2 开发产品需求:对客户需求加以精炼和细化,以便开发产品生存周期中的产品和产品构件需求。

​ SP2.1 建立产品需求和构件需求:根据客户需求,为保证产品和产品构件的有效性和可提供性,确定产品和产品构件需求。

​ SP2.2 分配产品构件需求:为每个产品构件分配需求。

​ SP2.3 确定接口需求:确定功能之间或对象之间的接口。

​ SG3 分析和确认需求:对各项需求进行分析和确认,并且开发所要求的功能度的定义。

​ SP3.1 建立操作概念和场景:建立并维护操作概念和场景。

​ SP3.2 定义功能需求:建立并维护所要求的功能度的定义。

​ SP3.3 分析需求:分析派生的需求,确保它们是必要的和充分的。

​ SP3.4 平衡需求:分析需求,平衡共同利益者的需求和约束。

​ SP3.5 确认需求:在适当时候,采用多种技术确认需求,以确保将要产生的产品能在预计的用户环境中恰当运行。

需求开发没有做好的原因

大部分是没有把握好客户需求,直接进入软件的细节,去讨论要做什么功能,界面要怎样设计去了,而忘记了软件的根本目的是为了解决什么问题。

当我们明确客户需求后,就应该把客户需求转变成产品需求和产品组件需求,客户需求一般都是比较高层次的,而且描述也会比较简单,不能作为日后验收的标准,我们需要对软件的规格进行说明。一般来说,我们写的软件规格说明书都会包含产品需求和产品组件需求的。我们导出产品需求和产品组件需求的时候,要注意产品需求和产品组件需求,必须和客户需求对应起来,通常是多对多的关系。为什么要对应起来?我们要保证,软件的每一个界面,每一个功能都是有用的,都是“源自”客户需求的,这样才能保证我们做的事情都是正确的事情,防止被不相干的事情干扰。

我们经常抱怨客户的需求在变,其实80%的原因是没有把握住客户需求,其实客户经常变的是产品需求或者是产品组件需求,客户需求是很少变的,就是因为我们没有把握住客户到底想要什么、需要什么,导致我们认为客户太难“服侍”了。只有把握住客户真正的需求,我们才能抓住根本,万变不离其中

需求管理强调的是需求的确认以及需求变更的控制,而需求开发讲究的是用系统的方法获取真正的全面的能实现的需求。
以上两个关于需求开发的例子,都是反面教材,都没有能很好地把握需求,一个没有抓住问题的关键,一个没有能找到真正的需求提供者来获取需求。

理解好需求开发

需要先理解清楚以下几个关键的概念:
1)客户需求(Customer Requirements)
2)产品需求(Product Requirements)
3)产品组件需求(Product Component Requirements)

客户需求是可以理解成客户为什么要做本系统,要解决什么问题,客户对系统有怎样的期望,希望能具备一些怎样的特点,简单的说,就是客户的需要是什么。
产品需求是能满足客户需求,并对软件产品规格进行了详细描述的需求,软件设计师可以根据产品需求进行设计、编码等工作。
产品组件需求,是对产品需求的进一步细化,产品可能会分割成几个子系统、几个部分,每个子系统每部分要具备怎样的功能、要具备怎样的性能、接口要求等,这些可以认为是产品组件需求。

从另外一个角度,需求可以分为功能性需求和非功能性需求两类,功能性需求就是系统具备怎样的功能,能做什么事情,而非功能性需求就是指系统要具备怎样的性能、安全级别等方面的要求。客户需求、产品需求和产品组件需求,都会包含功能需求和非功能需求。

各项内容说明

SG1: 干系人的需要、期望、约束和接口要求被收集并转化为客户需求

Stakeholder needs,expectations,constraints,and interfaces are collected and translated into customer requirements.

SP 1.1: 导出干系人对整个产品生命周期各阶段的需要、期望、约束和接口要求等

Elicit stakeholder needs,expectations,constrains,and interfaces for all phases of the product life cycle.
1)干系人:干系人除了指甲方的领导、系统的最终用户,还包括使用本系统的第三方以及与本系统有交互的第三方系统的拥有者、使用者等。
2)产品生命周期各阶段:干系人对系统的期望不一定只限于软件功能的,可能还包括数据的整理、资料录入、安装培训、维护要求等,干系人可能对软件生产的过程阶段都会提出他的要求,获取需求的时候,要注意干系人在软件生命周期不同阶段有什么要求。
3)需要、期望、约束、接口要求:甲方一般会对系统的目标、范围、解决什么问题、希望系统具备怎样的一些特性,满足一些什么接口要求和约束条件等,都会有大致的想法。需求调研工作,首先要注意搞清楚这些内容。
4)导出:客户的原始想法可能是不明确的,或者是客户一时难表达完整的,我们需要用一定的方法,让客户能完整无遗漏准确地表达出他的想法。通常我们可以通过原型、图示、类比、问卷等办法来导出客户的需求。

SP 1.2: 转化干系人的需要、期望、约束和接口要求为客户需求

Transform stakeholder needs,expectations,constraints,and interfaces into customer requirements.

SP1.1讲述的是通过一些方法记录客户原始的需求信息,而SP1.2讲述的就是把客户原始的需求信息整理成正式的客户需求,通常会包括对系统目标、范围、解决问题、软件特性、接口要求等有详细的描述。

SG2: 客户需求是精确和详细的,以用来开发产品需求和产品组件需求

Customer requirements are refined and elaborated to develop product and product-components requirements.

SG1讲述的是导出客户需求,而SG2讲述的是由客户需求到产品需求、产品组件需求的过程。

SP 2.1: 建立和维护产品和产品组件需求,这些产品和产品组件需求是基于客户需求的

Establish and maintain product and product-component requirements,which are based on the customer requirements.
产品和产品组件需求,是比较细致的需求,会详细描述软件与用户是怎样交互的,用户需要输入什么,系统会输出什么等都会比较详细描述出来。而客户需求一般只描述能实现什么功能、解决什么问题等,比较高层次。
客户需求一般是难以验证是否已实现的,而产品需求和产品组件需求是对软件规格的描述,是可以用来做为验收的标准的。

SP 2.2: 分配需求给每一个产品组件

Allocate the requirements for each product component.

这个SP将需求开发与技术解决方案联系起来,所有的需求应该与设计的产品组件对应起来,保证需求驱动后续的设计工作,同时也保证设计都是为了需求服务的。SP2.2是对SP2.1的进一步细化。

SP 2.3: 定义接口需求

Identify interface requirements
接口需求包括系统与第三方的系统的接口要求,也包括系统本身各组件、各子系统、各部分之间的接口要求。通常这些接口需求在客户需求级别的时候,并不是很明细,需要对客户需求进一步细分成产品需求、产品组件需求,然后发掘出接口需求。SP2.3也是对SP2.1的进一步深化。

SG3:需求被分析和确认,并定义出具体的功能性需求

The requirements are analyzed and validated,and a definition of required functionality is developed.

SP 3.1: 建立和维护操作场景及相关情景

Establish and maintain operational concepts and associated scenarios.

SP 3.2: 建立和维护功能定义

Establish and maintain a definition of required functionality.

SP3.1和SP3.2是对需求描述的要求,要求描述出具体需求的操作场景、上下文,具体的操作步骤,对功能的详细描述等。通常我们可以通过UML的Use Case图或者是序列图等来表达这些内容。

SP 3.3: 分析需求以确认需求是必须和充分的

Analyze requirements to ensure that they are necessary and sufficient.

SP 3.4: 分析需求平衡以平衡干系人的需要和约束

Analyze requirements to balance stakeholder needs and constrains.

SP3.3和SP3.4是对需求的准确性、全面性、可实现性方面的要求,除了要取得全面准确地需求,还需要平衡约束条件,保证需求在约束条件下是可实现的。

SP 3.5: 用各种合适的方法确认需求,确保最终产品能在用户的环境中按照设想运行

Validate requirements to ensure the resulting product will perform as intended in the user’s environment using multiple techniques as appropriate.

这是需求开发的最后一步了,需求导出过程中尽管用了很多办法,但需求确认的时候,仍然需要采取办法确保获取的需求是符合最终的使用场景要求。

SP3.3、SP3.4和SP3.5,通常是通过需求评审来满足的。

阅读全文
kubernetes 1.12.2版本安装

环境准备

准备两台机器:master,node

ip: master:192.168.13.129

node1:192.168.1.130

环境:centos7

注意事项:

docker版本最高支持18.06,高于要此版本报错

kubernetes12.2+docker-ce18.06.1ce

环境配置

在master和node 端执行:

1:安全策略规则配置

1
2
3
4
5
6
7
8
9
10
systemctl stop firewalld
systemctl disable firewalld
setenforce 0
iptables -F
iptables -t nat -F
iptables -I FORWARD -s 0.0.0.0/0 -d 0.0.0.0/0 -j ACCEPT
yum -y install ntp
ntpdate pool.ntp.org
systemctl start ntpd
systemctl enable ntpd

2:内核设置:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
# 关闭selinux
vim /etc/sysconfig/selinux
SELINUX=disable
# 修改内核参数
$vim /etc/sysctl.conf
net.ipv4.ip_forward=1
net.bridge.bridge-nf-call-ip6tables = 1
net.bridge.bridge-nf-call-iptables = 1
net.bridge.bridge-nf-call-arptables = 1
vm.swappiness=0
# 关闭swap
swapoff -a
# 注释自动挂载
vim /etc/fstab
# 关闭selinux
vim /etc/selinux/config
# 保存修改内核参数
sysctl -p
# 确保以下两个文件里面显示值为1:
cat /proc/sys/net/bridge/bridge-nf-call-ip6tables
cat /proc/sys/net/bridge/bridge-nf-call-ip6tables
# 每个节点都修改下面值,
vim /etc/sysconfig/kubelet
KUBELET_EXTRA_ARGS="fail-swap-on=false"

3:域名解析,免密登录,时间同步

a: 域名解析,master执行

1
2
3
4
5
6
7
vim /etc/hosts
# 配置示例
cat /etc/hosts
127.0.0.1 localhost localhost.localdomain localhost4 localhost4.localdomain4
::1 localhost localhost.localdomain localhost6 localhost6.localdomain6
192.168.13.129 master
192.168.13.130 node

b: 免密登录,master执行

1
2
3
4
5
# 生成密钥,直接回车
ssh-keygen -t rsa
# 配置节点
ssh-copy-id -i ~/.ssh/id_rsa k8n1
ssh-copy-id -i ~/.ssh/id_rsa k8n2

c:时间同步,master和node端分别执行

1
2
3
4
yum -y install ntp
ntpdate pool.ntp.org
systemctl start ntpd
systemctl enable ntpd

安装docker:安装官方要求安装

配置docker-CE源 :master node都要配置

1
2
3
4
5
6
sudo yum install -y yum-utils \
device-mapper-persistent-data \
lvm2
sudo yum-config-manager \
--add-repo \
http://mirrors.aliyun.com/docker-ce/linux/centos/docker-ce.repo

安装docker

1
2
3
yum list docker-ce --showduplicates | sort -r
# 目前kubernetes1.12.2支持docker版本最多18.06,docker版本已经更新到18.9了,不能指只有yum安装最新版,要指定版本型号
yum install docker-ce-18.06.1.ce

配置自启动

1
2
3
systemctl start docker
systemctl enable docker
systemctl status docker

配置kubernetes源

1
2
3
4
5
6
7
8
9
10
11
12
13
cat <<EOF > /etc/yum.repos.d/kubernetes.repo
[kubernetes]
name=Kubernetes
baseurl=http://mirrors.aliyun.com/kubernetes/yum/repos/kubernetes-el7-x86_64
enabled=1
gpgcheck=0
repo_gpgcheck=0
gpgkey=http://mirrors.aliyun.com/kubernetes/yum/doc/yum-key.gpg
http://mirrors.aliyun.com/kubernetes/yum/doc/rpm-package-key.gpg
EOF

# 查看yum源
yum repolist

在master端安装:

1
yum install -y kubelet kubeadm kubectl

查看到所需要的安装组件

1
kubeadm config images list

服务组件:

1
2
3
4
5
6
7
k8s.gcr.io/kube-apiserver:v1.12.2
k8s.gcr.io/kube-controller-manager:v1.12.2
k8s.gcr.io/kube-scheduler:v1.12.2
k8s.gcr.io/kube-proxy:v1.12.2
k8s.gcr.io/pause:3.1
k8s.gcr.io/etcd:3.2.24
k8s.gcr.io/coredns:1.2.2

从dockerHub拉取镜像:

1
2
3
4
5
6
7
docker pull guobq/kube-apiserverv1.12.2
docker pull guobq/kube-controller-manager:v1.12.2
docker pull guobq/kube-scheduler:v1.12.2
docker pull guobq/kube-proxy:v1.12.2
docker pull guobq/pause:3.1
docker pull guobq/etcd:3.2.24
docker pull guobq/coredns:1.2.2

给下载下来的镜像组件tag上和服务组件同样的标签

1
2
# example
docker tag guobq/kube-apiserverv1.12.2 k8s.gcr.io/kube-apiserver:v1.12.2

初始化集群

只在master端执行:(注意修改为master地址)

1
2
3
4
kubeadm init \
--kubernetes-version=v1.12.2 \
--pod-network-cidr=10.244.0.0/16 \
--apiserver-advertise-address=192.168.13.129

master初始化之后会出现以下token,要复制下来保存好,加node要用:

kubeadm join 192.168.13.129:6443 –token bppavd.uo0spqpyn6g49fr1 –discovery-token-ca-cert-hash sha256:f526f033651e4f152d551f0950471c53401e95c0ce6b22ae63d3937dfa8fe057

如果忘记token,可以通过以下命令获得:

1
kubeadmin token list

此时root用户还不能使用kubelet控制集群需要,配置下环境变量

1
2
3
4
5
6
7
export KUBECONFIG=/etc/kubernetes/admin.conf
# 也可以直接放到~/.bash_profile
echo "export KUBECONFIG=/etc/kubernetes/admin.conf" >> ~/.bash_profile
# 对于非root用户
mkdir -p $HOME/.kube
sudo cp -i /etc/kubernetes/admin.conf $HOME/.kube/config
sudo chown $(id -u):$(id -g) $HOME/.kube/config

部署fannel

1
kubectl apply -f kube-flannel.yml

kube-flannel.yml文件放在:https://github.com/guobq/k8s/blob/master/kube-flannel/kube-flannel.yaml

配置环境变量

1
2
3
4
5
6
# root 用户执行
kubectl get pods --all-namespaces
# node节点要安装的软件:
yum install -y kubelet kubeadm kubectl
vim /etc/sysconfig/kubelet
KUBELET_EXTRA_ARGS="--fail-swap-on=false"

node节点要安装的docker镜像:

1
2
3
4
kube-proxy:v1.12.2
pause:3.1
kuberneter/coredns:1.2.2
etcd:3.2.24 #node端的ETCD可以安装,也可以不安装

执行之前上面保留下来都token加入node:

1
kubeadm join 192.168.13.129:6443 --token bppavd.uo0spqpyn6g49fr1 --discovery-token-ca-cert-hash sha256:f526f033651e4f152d551f0950471c53401e95c0ce6b22ae63d3937dfa8fe057

节点配置环境

1
2
3
4
5
6
# root用户
export KUBECONFIG=/etc/kubernetes/kubelet.conf
# 非root用户
sudo cp /etc/kubernetes/kubelet.conf $HOME/
sudo chown $(id -u):$(id -g) $HOME/kubelet.conf
export KUBECONFIG=$HOME/kubelet.conf

查看节点:master

1
kubectl get nodes

部署dashboard

获取镜像:

1
2
3
docker pull guobq/dashboard: v1.8.3
# 修改镜像tag
docker tag guobq/dashboard: v1.8.3 k8s.gcr.io/kubernetes-dashboard:v1.8.3

启动dashboard:

1
kubectl apply -f kubernetes-dashboard.yaml

kubernetes-dashboard.yaml放在:https://github.com/guobq/k8s/blob/master/dashboard/kubernetes-dashboard.yaml

部署metrics-server

获取镜像:

1
2
3
docker pull docker pull guobq/metrics-server :v0.3.1
# 修改镜像tag
docker tag guobq/metrics-server :v0.3.1 k8s.gcr.io/metrics-server :v0.3.1

启动metrics-server:

1
kubectl apply -f ./

yaml文件放在:https://github.com/guobq/k8s/tree/master/metrics-server

1.13.2版本所需镜像

1
2
3
4
5
6
7
k8s.gcr.io/kube-apiserver:v1.13.2
k8s.gcr.io/kube-controller-manager:v1.13.2
k8s.gcr.io/kube-scheduler:v1.13.2
k8s.gcr.io/kube-proxy:v1.13.2
k8s.gcr.io/pause:3.1
k8s.gcr.io/etcd:3.2.24
k8s.gcr.io/coredns:1.2.6
阅读全文
使用yum安装tomcat及基本操作

安装Tomcat

1
sudo yum install tomcat

这将安装Tomcat 7及其相关项,比如Java,它也将创建tomcat用户。

最重要的Tomcat的文件将位于/usr/share/tomcat

想运行一个Tomcat应用程序,可以将它放在/usr/share/tomcat/webapps目录,配置Tomcat,并重新启动Tomcat服务。

更改Tomcat在启动时使用的Java选项

1
sudo vi /usr/share/tomcat/conf/tomcat.conf

下面添加JAVA_OPTS行添加到文件。 改变XmxMaxPermSize值,这些设置会影响Tomcat会使用多少内存:

/etc/default/tomcat7–JAVA_OPTS

1
JAVA_OPTS="-Djava.security.egd=file:/dev/./urandom -Djava.awt.headless=true -Xmx512m -XX:MaxPermSize=256m -XX:+UseConcMarkSweepGC"

安装管理包

安装默认Tomcat根页面(tomcat-webapps)和Tomcat Web应用程序管理器和Virtual Host Manager(tomcat-admin-webapps)

1
sudo yum install tomcat-webapps tomcat-admin-webapps 

增加了ROOTexamplessamplemanagerhost-manager Web应用到tomcat/webapps目录。

安装在线文档(可选)

安装Tomcat文档,以便默认Tomcat页面上的所有链接都可以运行

1
sudo yum install tomcat-docs-webapp tomcat-javadoc

配置Tomcat Web管理界面

为了使用在上一步安装的manager webapp,我们必须添加一个登录到我们的Tomcat服务器。我们将通过编辑这样做tomcat-users.xml的文件:

1
sudo vi /usr/share/tomcat/conf/tomcat-users.xml

新增可访问用户manager-guiadmin-gui (前面我们安装了管理接口)。您可以通过定义类似于以下示例的用户来执行此操作。

tomcat-users.xml – 管理用户

1
2
3
<tomcat-users>
<user username="admin" password="password" roles="manager-gui,admin-gui"/>
</tomcat-users>

启动Tomcat

启动

1
sudo systemctl start tomcat

重启

1
sudo systemctl restart tomcat

自启动

1
sudo systemctl enable tomcat

访问Web界面

访问Web管理界面:http://server_IP_address:8080

应用程序管理:http://server_IP_address:8080/manager/html

主机管理http://server_IP_address:8080/host-manager/html/

阅读全文
Algolia