2017年11月_麦哲思科技任甲林

原创一次CMMI虚假改进、评估的案例

早晨起来收到CMMI研究所发给所有主任评估师的一封邮件，是一个老外主任评估师，在中国的最近的一个评估经历。看到之后，心情极其沉重。这不是第一次看到、听到业内的这种做法，虽然以前，CMMI研究所的各方面人士在非官方的途径对中国与印度的评估有所抱怨，但是这是第一次CMMI研究所在全球范围内给所有的LA通报这么一个案例，这是一个有确切证据的案例。希望所有的中国的软件公司、中国的过程改进咨询公司、所有的评

2017-11-29 12:45:00 8920 1

原创一个敏捷项目的咨询记录

近日对一个敏捷项目进行了2小时的简单访谈，对他们的一些实践点评如下：综述： 1 敏捷的实践看着简单做着难，实践少，但是实践的很多细节要做到位。 2 要让团队的成员知其然知其所以然，才能够进行经验化过程控制。 3 要在团队内建立承诺的文化，说到一定要做到。 4 目标、需求、任务、任务状态、问题、团队规则都要可视化！ 5 牺牲质量追求速度，是

2017-11-28 15:59:40 1282

原创快速学习COSMIC之一：COSMIC方法的简单案例

COSMIC方法是新一代的软件规模度量方法，其基本的原理很简单，就是度量软件需求中的输入、输出、读、写这4类数据移动的个数，我们通过2个简单的例子来说明其基本的原理。案例一：针对MIS类软件的需求对于应用软件而言，我们都有这样的需求：允许合法用户登录到系统中；对于上述的功能需求，我们可以采用USE CASE的方式详细描述需求如下：

2017-11-24 10:13:02 16171

原创测试投入度量元的选择

很多项目在讨论测试是否可以结束的时候，往往是只关注了测试发现的缺陷有多少？缺陷的严重级别分布如何？测试发现的缺陷关闭情况如何？而忽略了一个前提，即测试的投入是否充分？如何量化测试的投入呢？我们可以从测试用例的密度，测试投入的工作量，测试的工期，测试的人数等多个方面来度量测试的投入，可以参见图一中候选的测试投入的度量元。图一：测试投入与产出的候选度量元哪个度量元更合适呢？如何判

2017-11-21 15:28:01 1525

原创需求变更对软件质量的影响

根据我们的经验，需求变更越多，造成的软件修改越多，bug也就会越多，事实是否如此呢？需要我们根据历史的数据进行检验。某企业采集了历史上多个项目的的需求变更次数、交付代码的规模、软件测试发现的缺陷个数，参见下表，基于这些历史数据我们分析一下，看看我们的经验结论是否成立。表一：需求变更的历史数据 ID 需求变更数代码规模LOC 总缺陷数测试缺陷密度bugs/KLOC

2017-11-15 15:32:18 3079

原创需求人员的图解力

需求描述方法是专业的需求分析人员必须掌握的技能，在众多的方法中，图形化描述需求是重中之重，一图胜千言。在没有文字之前，人与人之间的沟通是通过图形来表达的，象形文字是造字的最主要的手段。随着时间的推移，人们越来越依赖于文字，反而弱化了用图形表达思想的技能。做为需求人员，应该将图形化表达思想的能力重新捡起来，形成自己的技能，我们称之为图解力。需求人员应该掌握哪些图形的使用方法呢？请参见下边的不完全列表

2017-11-08 19:34:54 1160

原创缺陷清除率的简单分析

某项目采集了在一个迭代周期内缺陷的注入与发现数据。把缺陷注入分为了3个活动，把缺陷发现分为了4个活动，一个月内的统计数据见下表：某项目的缺陷清除率分析缺陷注入\缺陷发现Sprint planning设计与编码代码评审测试小计需求分析453 12设计与编码 27128测试 22小计4530342缺陷清除率33.3%62.5%96.8%100.0% 在此统计表中并没有采集到产品发布后的度量数据

2017-11-01 10:30:15 3268

麦哲思科技