程序大小的度量标准

Question

我被要求提供一个关于企业应用程序大小的指标。有问题的应用程序是一个基于Web的应用程序，我不知道如何量化它的大小。明显但没有用的指标是代码行，文件数量等。确定应用程序大小的一些建议方法是什么？

申请注意事项：

• 基于ASP.NET Web窗体的C＃App
• 分层架构
• 通过存储过程进行的所有数据库交互

Answer 1

用户有权访问的“网页”或“区域”数

问题 ：如果将部件合并到一个“控制中心”界面更有意义，可以将部件分成不同的页面或部分来捏造。

---

班级数量

问题 ：与其他类相比，这并未考虑某些类的复杂性（或简单性）。你可能有一个包含两个属性和一个方法的类，而另一个类可以是硬核。

---

非查找表的数量

问题 ：这不会考虑软件的复杂性，只考虑它所依赖的数据层。与一些类相关的一些相同问题也可以在这里应用，其中一些表比其他表更复杂。

---

代码行

问题 ：这是一个相当标准的指标，但它为具有大量行的程序提供了更多积极的内涵，而不是鼓励更高效和优雅的代码。

---

开发需要多少工时

问题 ：没有两个开发人员具有相同的技能组，并且没有两个开发人员可能会花费相同的时间（或遵循相同的路径）创建一个软件。因此，可能需要一个开发人员花费相同的时间，由3个技能较低/经验丰富的开发人员组成的团队敲出相同数量的代码。此外，如果你开始将更多的人应用于一个问题而不是真正必要的话，那么整个“神话人月”就会开始发挥作用。

---

总的来说，我认为指标的最大问题是他们尝试测量软件的一些可量化属性，而实际上软件的质量质量而不是数量，以及这是指标真正失败的地方。

Answer 2

SLOC （源代码行）是一种普遍接受的尺寸衡量标准。

您的问题只询问规模，但我敢打赌，您被要求提出这些指标，以便管理层可以确定支持此应用程序所需的工作量。在这种情况下，我会考虑代码的复杂性。

您可能希望下载适用于许多编程语言的Understand 试用版，它将为您提供所需的指标，免费试用期将持续足够长的时间以获取管理所需的数字。

至于指标，我会看一下：

圈复杂度 V（G）是衡量复杂性的一个很好的衡量标准。

SEI可维护性指数非常适合查看维护代码库的难度。

至少15％的代码评论率以及其他必要的高级别和低级别设计文档。意识到其中大部分都将过时，但它们仍然可以帮助您的员工开始。

测试覆盖率也是值得关注的内容。他们有单元测试吗？当你拥有一个漂亮的单元测试套件时，代码更容易维护，你可以运行它以给自己一个“合理”的感觉，你没有破坏任何东西。 80％的测试覆盖率通常是最低的。

Answer 3

功能点分析方法，我认为适用于中型到大型应用程序，独立于编程语言：

http://en.wikipedia.org/wiki/Function_point_analysis

分析结果是一个功能点值，可用于估计实施时间。这种方法很容易理解和实现（使用简单的电子表格），但它需要一些经验，因为计算中的一些关键因素是可变的。

Answer 4

有哪些建议的方法可以确定能够提供真正含义的应用程序的大小？

如果你找到了一个非常好的答案，请正确写完，好吗？

根据我的经验，代码指标几乎普遍很糟糕。他们中的一些人只能做坏事。

[附录]

公平地说，问题不是那么精确，以至于“代码指标很糟糕”，毕竟它们只是测量（希望是明确定义的）;问题是他们似乎永远不会衡量人们希望他们衡量的东西但是就像他们那样使用。指责这种滥用的数字并不公平。

Answer 5

如果你知道它的用途，那么它只能提供真正的意义。你知道测量尺寸的目的吗？如果没有，请问。