2009年7月22日
|
MA
|
| |
|
2009-02-04 作者：人月神话 来源：网络
转载地址：http://www.uml.org.cn/cmm/200902043.asp
|
| |
|
度量过程框架:
度量和分析过程域包括：
- 详细说明度量和分析的目的，使其与已标识的信息需要和目的一致
- 详细说明度量、数据采集、存储机制、分析技术以及报告和反馈机制
- 实现数据的采集、存储、分析和报告
- 提供可用于作出可靠决策的客观结果，并采取适当的纠正行动
将度量和分析活动与项目的其它过程集成，以支持：
- 客观的计划和估计
- 按已制定的计划和目的跟踪实际的性能
- 标识和解决与过程相关的问题
- 提供将度量合并到未来的附加过程中去的基础
注意二级的度量集中在项目级别，项目可以把特定的项目数据和结果存放在项目专用的库中。当数据在项目间广泛共享时，数据可以驻留在组织级度量仓库中。要建立组织级的度量数据库，应该参考三级的过程域OPD组织过程定义，对于度量中的分析到了四级后需要使用统计学的相关方法和工具进行定量的分析，涉及到四级QPM量化项目管理过程域的内容。
SG 1 调整度量和分析活动(度量的目的和活动要与已标识的信息需要和目的相一致)
- SP 1.1 建立度量目的
- SP 1.2 详细说明度量
- SP 1.3 详细说明数据采集和存储规程
- SP 1.4 详细说明分析规程
在进行度量计划和实施度量前，必须要搞清楚度量的目的，度量的目的是通过采集的数据分析，改进我们的过程的有效性，提高效率和改善质量。度量目的的来源可以是管理、技术、项目、产品或过程等方面实现的需要，来源于企业的战略和商业计划，项目计划，管理和技术问题，过程改进计划等。
关于度量信息的分类，可以分为
- 进度和进展（里程碑的实现和工作单元的执行情况）
- 资源和费用（项目分配的人力资源和其它费用）
- 产品规模和稳定性（软件的规模，软件功能范围和数量的变更）
- 产品质量（缺陷密度，现场缺陷）
- 过程性能（评审效率，缺陷泄露情况，过程符合度，不合格项）
- 技术有效性（软件架构和软件重用）
- 客户满意度（交付的产品与服务满足客户期望的程度）
在SP1.2重点是度量本身要是精确的，可量化的度量。度量可能是基本度量，或者是派生度量。基本度量数据由直接度量获得。派生度量数据来自其它数据，通常是由两个或多个基本度量组合而来。如缺陷数是基本度量，而缺陷密度则是派生度量。
在建立了度量的目的和确定了度量的方法后，进入SP1.3要解决度量数据的收集，度量数据的存储两个问题。要明确地说明数据如何采集，从何处采集，和何时采集。要指定采集有效数据的规程。为了分析数据，数据要按可访问的方式存储，并且要确定是否为可能的重新分析或文档目的而保存。
当采集和存储了数据后，就需要选择合适的数据分析方法和工具，到了QPM量化管理后就会更加强调对于不同的子过程该采用哪些统计学的方法和工具。
SG 2 提供度量结果以处理已标识的信息需要和目的
- SP 2.1 采集度量数据：获得特定的度量数据
- SP 2.2 分析度量数据
- SP 2.3 存储数据和结果
- SP 2.4 交流结果
注意在SG1是制定具体的方法和规程，在SP2是实际的度量执行活动。在SP2.1首先是按照度量规程采集我们需要度量的活动的执行数据，在数据采集到后必须对数据进行完整性的检查，以保证数据的准确有效。度量很多时候无效或没有起到实际的作用，最大的原因不是在于度量的方法和工具上面，而是在于我们采集到的数据本身是不准确或错误的，导致最终分析出来的结果也是错误的。
在SP2.2是讲按照计划对度量数据进行分析，必要时要进行额外的分析，结果由有关的项目相关人员评审，并指出将来要对分析作必要的修订。在完成了度量数据的采集和分析后，我们需要对度量后的数据进行存储，以作为项目的历史数据后续可以作为项目计划和估算的重要参数。
度量数据的存储主要包括了：
- 度量计划
- 度量的规格说明
- 已经采集的数据集
- 分析报告和陈述
在二级项目的度量数据主要是服务于项目和个人的需要。到了三级后项目度量数据要存储到组织级的度量数据库中，以方便建立组织级的度量基线。具体内容在三级的OPD过程域。
SEI建议的度量元
- 进度性能（里程碑性能、工作单元进展）
- 成本性能（实际与计划的对照，不一致情况）
- 工作量性能（实际与计划的对照，不一致情况）
- 需求管理（增加的、删除的、修改的，需求易变性）
- 程序规模（源码行数、页数，实际与计划的对照）
- 测试性能（需要的测试，通过的测试）
- 缺陷数据状态（未解决的问题，解决完成的问题，缺陷密度，缺陷来源）
- 过程性能（完成的任务，行动项数）
- 计算机资源利用率（内存占有量，CPU占有量）
- 管理计划项目过程的性能（对照实际进展做估计，重计划，项目总结数据）
在三级我们主要到度量要上升到组织级，在GG3中也谈到要将度量活动制度化为组织级已经定义的过程，组织可以通过各个项目度量数据的收集来建立组织过程能力基线。在四级中注意重点是度量需要到我们需要监控的各个子过程粒度，同时在度量数据分析的时候需要采用统计学的相关方法和工具进行。具体一些CMMI四级中涉及到度量的要求:
- 根据商业目标确定项目目标，根据项目目标
- 根据质量性能目标选择最有价值的子过程进行量化管理，粒度到子过程
- 采用统计学的方法和思想而不仅仅是应用SPC
- 可以应该QFD逐层分解来选择度量技术和子过程
- 度量是使过程受管理的基础，而不仅仅是为将来收集和跟踪数据
- 更好的根据过程能力基线PPB管理当前项目性能，过程受控
- 更好的根据过程能力模型PPM预测将来
|
|
{背景}基础培训和差距分析的工作已经结束了，感觉和我想象的有点出入...
一、差距分析
内容：过程改进的模型、通用实践和特定实践。
收获：1、我做了录音，有点细节还是值得再一听的
2、说的好粗，有待于在专题培训上面再加强
3、最郁闷的是我的练习没有获得附加分且2个多选题写错了....
二、差距分析
内容：以访谈的形式对各个角色访谈最后出个差距结果
任务：1、给我布置了整理文档，这周末就会过来评审
2、早点熟悉，尽快熟悉....
历时一个月，某些事的尘埃落定：
1、关于合作的咨询公司：选好且已签了合同，本周日开始启动仪式...
2、关于我的学习：理论知识是了解了一些，但是看到场景分析题时仍是束手无策，不会做，而且发现有关软件质量管理的文章和书籍都很少，好不容易找到一本，看了以后，仍是没有理清楚书上说的解题思路...
3、学习计划：走一步看一步，但是每步都要走好！
{背景}公司有过3级的打算，我觉得其实不是为了提高管理的效率去引进CMMI3,有很大的原因是看上了政府的补贴吧O(∩_∩)O~
前段时间就和我说过，想让我来接这份工作...（不得不接，没啥思考的余地-_-|||）
这几天的工作的内容就是约咨询公司过来了解情况和在网上搜索资料，多找点资料是对自己有利的，在一大堆的事实面前，我已经从刚开始的兴奋逐渐退化，但还是不能否认这是个很好的学习机会...
希望自己在这个过程中能全心投入和思考，做到收获的最大化...
一、软件需求的来源：
1、项目：由固定客户以合同或契约形式提出；
2、产品：企业内部市场人员通过对市场上潜在的客户要求整理得到；
二、影响软件质量的因素：
1、流程：SQA从流程方面保证软件的质量；
2、技术：测试从技术方面保证软件的质量；
3、组织：保证内部协调工作；
三、CMM与CMMI的区别：
1、适用范围：CMM适用于软件行业，CMMI加入了部分硬件；
2、表达方式：CMM是阶段式的，CMMI是阶段式+连续式的；
3、关注点不同：CMMI关注过程，关注需求、过程的度量；
4、CMM是做为评估标准出现的，CMMI是做为过程改进出现；
四、企业如何选择哪种质量标准：
1、看企业的业务特点：纯软件、规模小的最好选CMM，软件+硬件且规模大的选CMMI；
2、看企业本身对质量管理的态度：未有良好的质量意识的，最好选CMM，如果有质量意识，能自发的执行的，选CMMI；
3、根据公司预算：金额较少的，选CMM，金额较多的，选CMMI；
4、看想在那方面提高，如果想在过程控制方面提高，选CMMI；
5、对已做过CMM，要提高利益最大化的，建议做CMMI；
五、SQA的主要工作范围：
1、指导并监督项目按照过程实施；
2、对项目进行度量、分析，增加项目的可视性；
3、审核工作产品，评价工作产品和过程质量目标的符合度；
4、进行缺陷分析，缺陷预防活动，发现过程的缺陷，提供决策参考，租金过程改进；
六、SQA应具备的技能：
1、熟悉过程改进体系；
2、精通软件质量工程；
3、熟悉业务背景；
4、软件技术能力，自身的学习能力、动手能力；
5、良好的沟通能力；
七、SQA主要工作方法：
遵循质量管理PDCA（Plan计划、Do执行、Check检查、Act改进）循环。
八、软件度量四个基本度量项：
1、规模（size），软件工作产品的大小，如SRS文档页数、HLD文档页数、LLD文档页数、代码量（KLOC）、UT用例数、IT用例数、ST用例数等等；
2、工作量（effort），完成各软件工作产品和活动所用人时（或人天等），如SRS所用人时数、HLD人时数、编码人时数、ST测试人时数等等；
3、进度（schedule），各软件工作产品和活动开始和结束时间；
4、质量（quality）、缺陷（defect），在各软件工作产品和活动中产生的缺陷数，SRS评审发现缺陷数、HLD评审发现缺陷数、LLD发现缺陷数、ST发现缺陷数等等。
本文出自suiyuxiu的51Testing软件测试博客：http://www.51testing.com/?134368
{背景}入职三个月了，在此记录下我的工作历程。
测试项目：
1、投行管理系统（4.21-5.24）
{测试背景}这个项目是公司早已完成的作品，提供给我们的就是一份简单的使用说明书和已经写好的系统，本打算要写测试用例的，可BOSS要我们三个8天测完，所以我们没有写测试用例，就这样测了下去，实际上5月后我和另个同事又继续测了三周，这才结束。
2、OA和PM项目综合管理（5.25-6.11）
{测试背景}内部使用的系统，3人前后花了2周时间；
3、PCBERP(6.12-至今）
{测试背景}系统已在线上，此次是增加一些新的功能；
工作的内容：
1、对所分配的模块执行测试，测试类型只含功能测试和业务流程测试，功能测试的方法多为边界值，业务流程测试也只是想到哪就测到哪,没有做任何的文档记录；-_-|||
2、回归bug，每天提交测试日志。
工作的改进：
1、编写测试用例和及时补充更新测试用例；
2、认真仔细了解每项工作内容。
下个月（八月）学习安排：
1、完成对C的学习；
2、每天坚持听2小时的英语，且周末加强学习；
3、开始学习QTP；
4、继续学习有关测试用例的内容。
{背景}今晚，公司的测试顾问抽空过来给我们这些测试解疑答惑！
1、如何高效的编写测试用例？
答：从三方面入手：
1）功能点
覆盖全部的功能点，至少编写测试点用例（增加、删除、搜索等）；
2）业务流
所有的流程都要理清楚，适当考虑 场景法；
3）通用的测试用例
记得一定要适时补充。
备注：业务逻辑非常容易出bug
2、在时间较紧的情况下，是否也要编写测试用例？
答：至少写测试大纲（个人写分配的模块，然后再评审）
包含的内容有：
1）功能点
2）业务流
3）时间
4）测试的完整
3、职业发展的要求
1）基本能力
测试思路、测试逻辑、发现bug的能力
2）QTP
边看帮助文档边实践
3）有空了解 数据库的使用、linux技术和网络技术