软件项目应该统计哪些数据?
2012-10-24 23:03
204 查看
前一讲我们提到了一些广为统计,但是实际上却可能没有指导意义的数据。那么这一讲,我们将来阐述那些需要统计并对项目产生积极影响的数据。
一般来说,软件项目最关心的就是Quality (质量)、Cost (成本)、 Delivery(交货期)。管理者希望以不同的角度,不同的形式通过数据形式将这些属性展示出来。那么我们所统计的数据也就是围绕着三方面的。而同时,我们也要关系这些数据将为未来的改进提供什么样的帮助。
1.圈复杂度
圈复杂度无疑是衡量软件质量的一个指标。圈复杂度有现成的工具来统计。C#.Net的NUnit,Java的Google Code Pro*,Matrix等都可以统计这个数据。圈复杂度的推荐指标为不超过10。超过10的代码应该被改进。而过分的求低可能从ROI(投资回报率)上来说不一定值得。
2. 平均Bug修复时间
和统计Bug收敛趋势,Bug数量,二次Bug率,Bug分布,Bug原因统计等不同,统计平均Bug修复时间有助于了解组织在市场中的竞争力。Bug平均修复时间越短说明发布的周期越短,组织也就越具有竞争力。Bug修复的时间应该从Bug登记开始计算,到Bug被彻底修复(即通过已知的全集测试没有测试出二次Bug)为止。这其中还包括等待时间,测试时间,所以想要有短的Bug修复时间,就需要有好的测试机制。关于如何建立好的回归测试机制,在以后的章节中将会详细讨论,这里只强调为了能够缩短Bug平均修复时间必须采用自动化测试。
3. 测试覆盖率
测试覆盖率说明了测试的覆盖程度,但是现在的测试工具基本上只能在C0级别上给出数据。而且,代码被执行了并不代表代码被测试了。所以,现在的测试覆盖率统计工具的数据只能作为参考。为了能够更好地掌握测试覆盖程度,测试代码的复查是不可或缺的。为了能够保障测试的质量应该尽可能的增多不同类别的测试用例。对于测试类别的涵盖程度也是比较重要的审核方面。为了能够更好地说明这个问题,举例如下:
对于一个只能够输入正整数的文本框的校验测试应该有哪些测试数据这个问题,很多人给出的答案仅限于,整数、小数、正数、负数、0等几个条件。
实际上,下面这些也是至关重要的测试用例:
a. 中文、日文、韩文、法文、英文、罗马字等各种语言的数字。例如:quatre
b. 半角、全角的数字。例如:8
c. 带括号、带圆圈的数字。例如:㈥⑦
d. 带加号的数字。例如:+6
e. 分数。例如:3/5
f. 科学计数法。例如:2e5
g.符号。例如:$
h.英文。例如:ask
i.8进制,16进制数字。例如:0x52, FF,
j.以小数点结尾的数字,例如:2.
k.最大值与最小值:例如:Integer.MAX,Integer.MIN
l.百分比。例如37%
4. 测试用例数量
测试用例的数量可以反映测试的力度。
5. 到完成任务所需要的时间
这是用来取代百分比进度报告的。前文已经讨论过百分比进度报告无法给出足够的信息。到完成任务所需要的时间是一个可调整的数字,今天估算剩余工时是10小时,经过了8小时,明天应该还剩余2小时,但是由于今天开会等原因,可以剩余4小时。这样的数字往往比较准确。注意,其值不宜超过20小时,如果超过,应该考虑将任务分解。另外,当任务发现有估算条件遗漏时,可以对数字进行扩大,即,今天估算的剩余工时为10小时,经过了8小时之后,原来应该为2小时,但是由于发现一块重大遗漏,可以变为12小时。至于什么原因导致遗漏是另外需要解决的问题,但是就工时和进度本身,通过这样的数据统计就可以更为准确的把握了。
6. 进度偏差
实际的日程和计划之间有什么样的偏差。这样可以为调整进度或者削减功能提供参考依据。
7. 所用工时
所用工时应该单独列出。尤其是对于超时工作的情况。超时工作(加班)往往带来负面效果。进行实际情况的统计,并且分析投入的工时和产出的价值之间的关系。如果加班时间超过了法定的上限就是一件更为严重的事情。
8. 投入和预算之间的偏差
项目的投入不仅仅包括工时上的投入,还包括因为项目开发需要所产生的机器设备折旧、房租、通信费、差旅费、交通费、项目活动经费、采购的软硬件设施费、外包费、咨询费等各种费用。这些实际花费的费用和当初的预算费用之间的关系究竟如何。如果忘记了某些费用,下次应该如何改进。
9. 代码行数
统计这个不是为了计算Bug密度、测试密度、生产效率的。前文已经说过。统计这个是为了了解代码规模,进而了解代码是否有些臃肿。可以通过对比类似项目的代码行数来看技术上是否得到了改进。例如:某30万行代码的项目,改写之后代码行数为3万。
一般来说,软件项目最关心的就是Quality (质量)、Cost (成本)、 Delivery(交货期)。管理者希望以不同的角度,不同的形式通过数据形式将这些属性展示出来。那么我们所统计的数据也就是围绕着三方面的。而同时,我们也要关系这些数据将为未来的改进提供什么样的帮助。
1.圈复杂度
圈复杂度无疑是衡量软件质量的一个指标。圈复杂度有现成的工具来统计。C#.Net的NUnit,Java的Google Code Pro*,Matrix等都可以统计这个数据。圈复杂度的推荐指标为不超过10。超过10的代码应该被改进。而过分的求低可能从ROI(投资回报率)上来说不一定值得。
2. 平均Bug修复时间
和统计Bug收敛趋势,Bug数量,二次Bug率,Bug分布,Bug原因统计等不同,统计平均Bug修复时间有助于了解组织在市场中的竞争力。Bug平均修复时间越短说明发布的周期越短,组织也就越具有竞争力。Bug修复的时间应该从Bug登记开始计算,到Bug被彻底修复(即通过已知的全集测试没有测试出二次Bug)为止。这其中还包括等待时间,测试时间,所以想要有短的Bug修复时间,就需要有好的测试机制。关于如何建立好的回归测试机制,在以后的章节中将会详细讨论,这里只强调为了能够缩短Bug平均修复时间必须采用自动化测试。
3. 测试覆盖率
测试覆盖率说明了测试的覆盖程度,但是现在的测试工具基本上只能在C0级别上给出数据。而且,代码被执行了并不代表代码被测试了。所以,现在的测试覆盖率统计工具的数据只能作为参考。为了能够更好地掌握测试覆盖程度,测试代码的复查是不可或缺的。为了能够保障测试的质量应该尽可能的增多不同类别的测试用例。对于测试类别的涵盖程度也是比较重要的审核方面。为了能够更好地说明这个问题,举例如下:
对于一个只能够输入正整数的文本框的校验测试应该有哪些测试数据这个问题,很多人给出的答案仅限于,整数、小数、正数、负数、0等几个条件。
实际上,下面这些也是至关重要的测试用例:
a. 中文、日文、韩文、法文、英文、罗马字等各种语言的数字。例如:quatre
b. 半角、全角的数字。例如:8
c. 带括号、带圆圈的数字。例如:㈥⑦
d. 带加号的数字。例如:+6
e. 分数。例如:3/5
f. 科学计数法。例如:2e5
g.符号。例如:$
h.英文。例如:ask
i.8进制,16进制数字。例如:0x52, FF,
j.以小数点结尾的数字,例如:2.
k.最大值与最小值:例如:Integer.MAX,Integer.MIN
l.百分比。例如37%
4. 测试用例数量
测试用例的数量可以反映测试的力度。
5. 到完成任务所需要的时间
这是用来取代百分比进度报告的。前文已经讨论过百分比进度报告无法给出足够的信息。到完成任务所需要的时间是一个可调整的数字,今天估算剩余工时是10小时,经过了8小时,明天应该还剩余2小时,但是由于今天开会等原因,可以剩余4小时。这样的数字往往比较准确。注意,其值不宜超过20小时,如果超过,应该考虑将任务分解。另外,当任务发现有估算条件遗漏时,可以对数字进行扩大,即,今天估算的剩余工时为10小时,经过了8小时之后,原来应该为2小时,但是由于发现一块重大遗漏,可以变为12小时。至于什么原因导致遗漏是另外需要解决的问题,但是就工时和进度本身,通过这样的数据统计就可以更为准确的把握了。
6. 进度偏差
实际的日程和计划之间有什么样的偏差。这样可以为调整进度或者削减功能提供参考依据。
7. 所用工时
所用工时应该单独列出。尤其是对于超时工作的情况。超时工作(加班)往往带来负面效果。进行实际情况的统计,并且分析投入的工时和产出的价值之间的关系。如果加班时间超过了法定的上限就是一件更为严重的事情。
8. 投入和预算之间的偏差
项目的投入不仅仅包括工时上的投入,还包括因为项目开发需要所产生的机器设备折旧、房租、通信费、差旅费、交通费、项目活动经费、采购的软硬件设施费、外包费、咨询费等各种费用。这些实际花费的费用和当初的预算费用之间的关系究竟如何。如果忘记了某些费用,下次应该如何改进。
9. 代码行数
统计这个不是为了计算Bug密度、测试密度、生产效率的。前文已经说过。统计这个是为了了解代码规模,进而了解代码是否有些臃肿。可以通过对比类似项目的代码行数来看技术上是否得到了改进。例如:某30万行代码的项目,改写之后代码行数为3万。
相关文章推荐
- 目前流行的源程序版本管理软件和项目管理软件都有哪些, 各有什么优缺点?
- 一个软件项目开始应该怎么入手分析,搭建
- 实例统计哪些人会购买共享软件?
- 中国烟草总公司天津市公司数据联邦及复制软件采购项目招标公告
- 这5种必知的大数据处理框架技术,你的项目到底应该使用其中的哪几种
- MYPM项目管理平台应该更名为 MYPM IT研发管理集成化软件项目管理平台
- 项目管理工具+软件开发、云计算、数据分析和机器学习工具
- 目前流行的源程序版本管理软件和项目管理软件都有哪些?各有什么优缺点?
- [软件工程]软件质量应该包括哪些?
- 我是一名女程序员,技术一般,沟通能力还可以,2年以后想当一名项目经理,我应该在哪些方面加强。
- IFC标准是为了满足建筑行业的信息交互与共享而产生的统一数据标准,是建 筑行业事实上的数据交换与共享标准。本文概要介绍了IFC标准的产生及发展 历程,IFC的整体框架结构,简要说明了IFC标准的实现方法和过程,描述了 当前的应用以及我们应该更加积极地利用IFC标准为建筑软件行业服务。
- 软件缺陷数据能够告诉你什么? 今天,老大把我喊到办公室叮嘱我,“提测之后每天都要关注项目里的 bug,知道吧?” 我说,“我知道,我每天肯定会及时跟进 Open Bug 的修复进度和 Fixed
- 在软件开发的早期阶段为什么要进行可行性研究?应该从哪些方面研究目标系统的可行性?
- 大数据平台的软件有哪些?
- 四川省地方税务局数据复制分发软件项目招标
- VS2010软件开发平台的VC++项目——读取TXT文件的数据
- 五大数据统计分析软件
- ERP项目中一个表应该有哪些默认字段
- qml-qt项目利用google 分析进行数据统计分析
- 软件项目需求分析的文档都包括哪些内容