快速学习COSMIC方法之十七：如何寻找更简单有效的规模度量方法？

  很多企业都在探索合理估算工作量的方法，而工作量的多少主要取决于软件规模的大小，因此在估算软件工作量之前需要先估算其规模。传统的规模估算方法是进行代码行的估算，但是对于同一个需求，不同经验的人员去估算，结果差别很大，不同的实现语言，估算结果差别也很大，即使不同经验的人员针对同一种需求去实现，实际的代码行数也差别很大，并且实际情况中，往往一个需求可能需要多种语言结合才能实现。因此，使用代码行作为衡量软件规模的单位，进而再估算软件的工作量，不具有可比性，偏差比较大。

  目前，越来越多的企业尝试使用功能点来衡量软件规模，进而估算工作量。而COSMIC方法是目前功能点度量最先进的方法，也是最简单易用的方法。但是，也有很多公司在使用功能点方法时，认为需要学习一些规则，需要经过训练，不够简便，因此想寻求一种更简单快速的方法。这种探索的精神值得提倡，但是需要注意，自己探索的方法必须要合理且要具备一定的科学性。自创的方法如果仅仅在本公司内使用是可以的，但如果想要和业内的其他组织进行对比，还要具备广泛的适用性。

  如何判断自己独创的规模度量方法的合理性与科学性呢？最简单的方法就是判断采用这种方法度量的规模数据与实际工作量数据之间的相关性。我们先来看一个成功的例子：

  例1:某公司为银行开发应用软件，自己定义了一套需求描述的规范，项目都能严格按照需求规模来描述需求，他们以需求的个数作为需求的规模，积累了79个项目的历史数据:

表格 1-1
项目序号	需求 个数	编码工作量 （人天）	项目序号	需求个数	编码工作量 （人天）	项目序号	需求个数	编码工作量 （人天）	项目序号	需求个数	编码工作量 （人天）
1	78	574	21	15	117.37	41	30	139.38	61	60	224.94
2	45	227	22	35	234.49	42	307	1224.83	62	71	265.08
3	13	60	23	11	59.06	43	60	225.06	63	52	193.66
4	20	71	24	10	50.63	44	32.21	95.27	64	85	305.63
5	107	846	25	120	587.25	45	35.31	309.09	65	110	300.63
6	40	208	26	28	118.75	46	28	217.41	66	290	1322.00
7	20	103	27	50	186.34	47	30	232.35	67	56	217.56
8	142	709	28	63	173.64	48	16	101.69	68	155	571.75
9	104	456	29	192	514.12	49	142	831.76	69	70	215.16
10	15	60	30	15	84.01	50	348	1511.26	70	30	152.84
11	297	988	31	11	55.25	51	48	128.26	71	20	99.89
12	152	498	32	67	323.69	52	35	307.25	72	66	330.00
13	63	174	33	79	380.26	53	24	209.00	73	135	638.83
14	23	200	34	24	108.13	54	20	151.19	74	152	667.00
15	14	90	35	46	186.33	55	12	88.88	75	85	343.31
16	12	66	36	21	78.19	56	30	186.88	76	9	30.00
17	42	198	37	21	69.63	57	135	727.69	77	20	63.50
18	50	215	38	15	88.31	58	47	224.19	78	20	60.00
19	280	936	39	151	872.46	59	27	115.05	79	54	140.00
20	37	291	40	30	164.44	60	330	1354.69

对这79个历史项目的数据进行回归分析，得到下图的回归方程：

图一需求个数与编码工作量的拟合线图

   由上图可以看出，需求个数与编码工作量是强相关的，R-sq超过了90%。则对该公司而言，用自定义的需求个数代表软件的规模就是一个合适的选择，该方法在公司内是合理的、科学的、简单易行的方法！

  我们再来看一个失败的案例。

  例2:某公司开发政府的行政管理系统，自定义度量软件规模的计量单位：需求点，公司有自定义的规则，并且描述了一个需求点的定义。共积累了25个历史项目数据：

表格 1-2
项目序号	需求点数	开发工作量 （人天）	项目序号	需求点数	开发工作量 （人天）
1	150	1026	14	95	726.7
2	20	1840.9	15	20	120.4
3	7	91.7	16	45	836.4
4	18	17	17	90	232
5	164	1734.2	18	6	160.2
6	42	300.6	19	22	1269.5
7	10	195.7	20	158	263.9
8	220	953.2	21	20	672.1
9	7	552.9	22	59	395.7
10	20	590.4	23	24	1298
11	115	2067.5	24	6	1246.6
12	20	489.1	25	220	1993.9
13	100	1222.8

    对该组历史数据画散点图分析：

图二需求点数与开发工作量之间的散点图

  由上图可以看出，开发工作量与需求点数具有微弱的相关性，进行相关性分析，可以发现：

  两者的相关性系数只有0.439，因此即使统计相关，但是由于相关性系数太小，不具有实际的使用价值。这就说明在这家公司内，需求点数的定义，不是一个合适的规模计量单位！

  以上的检验方法简单易行，所以当公司自定义一套规模度量方法后，可以使用项目数据实际检验一下。即使在敏捷方法中，也可以采用上述方法检验故事点与实际工作量之间的相关性。参见例3:

  例3:某项目采用故事点法做了规模估算，当项目结束后，积累了12次迭代完成的故事点数与实际工作量数据，如下表：

表格 1-3
迭代周期	故事点数	工作量（人时）	迭代周期	故事点数	工作量（人时）
1	232	257	7	360	480
2	155	286	8	264	454
3	228	249	9	286	349
4	315	318	10	272	401
5	346	441	11	105	153
6	272	398	12	265	346

  为了检验故事点与工作量是否相关，故事点的定义是否合理，该项目组对上述的数据画了拟合线图如下：

图三故事点数与工作量之间的拟合线图

  由上图可以看出，R-sq超过了60%，故事点数与工作量之间具有很好的相关性，因此可以判定，故事点可以作为规模的计量单位，并且可以使用故事点来估算工作量，且结果较为合理。

  最后，我们来看一家公司对标准的COSMIC方法进行本地化后，用来度量维护、升级类的软件规模的案例：

  例4:某公司为一家保险类软件开发的公司，在导入标准的COSMIC功能点方法后，对标准的方法做了微调，以度量维护升级的软件，积累了如下的16个历史项目的数据：

表格 1-4
项目 序号	功能点个数 CFP	开发工作量 （人天）	项目 序号	功能点个数 CFP	开发工作量 （人天）
1	6.2	34.1	9	75	67.6
2	4.2	16.3	10	41.5	36
3	11	28.5	11	90	82
4	3.6	14	12	55	57
5	54.4	43	13	68.5	55
6	68.7	61.5	14	16.6	32
7	41.1	56.7	15	18	22
8	24.5	29	16	19	45

  对上述数据，进行回归分析后，得到：

图四功能点个数与开发工作量之间的拟合线图

   由上图可以看出，R-sq超过了80%,功能点与工作量之间具有很强的相关性！说明该公司在实践COSMIC标准方法的基础上，增加的本地化规则是适合公司项目特点的，且较为合理。因此可以使用本地化后的COSMIC方法度量软件功能点数，进而估算开发工作量。