您如何衡量/估计XML编程工作的大小？

Question

设置场景 - 我在那些喜欢估计和跟踪几乎所有事情的行业中工作.我们的一个关键指标是SLOC(源代码行 - 声明性和可执行语句).我们将其用于项目规模和成本估算,项目规划以及许多其他方面.我们尝试用它来比较苹果和苹果(即,我们不将一种语言/域中的SLOC与另一种语言/域中的SLOC进行比较). 注意:我们不会根据此指标评估各个开发人员,也不会仅因为SLOC与预期不同而调用错误或错误.我们做,不过,考虑一个项目有更多的SLOC可能也有更多的bug.

最近,我开始研究使用库代替组件的项目,否则这些组件将被手工编码 - 例如JSF而不是JSP,Hibernate而不是JDBC等等.所以...而不是编写代码行,我们的团队正在开发XML文件.XML映射仍然需要付出努力,并且复杂性仍然存在模糊关联 - 在给定项目中,如果将这些XML配置文件中的100倍更多,可能会表明创建需要花费更多精力,并且调试可能比仅使用项目更复杂1/100的XML文件.

那么......有没有人有任何关于测量这些XML配置文件大小的建议？元素数量？#elements + #properties？别的什么？

Answer 1

有趣的问题。我知道的唯一指标（除了按照您的建议计算节点和属性之外）是一种称为“结构化文档复杂性指标”的指标。

http://www.oreillynet.com/xml/blog/2006/05/metrics_for_xml_projects_5_str_1.html

是我目前能找到的最好的链接（已经有一段时间了）。我还发现了这个小工具，它显然会为您计算它（可能还有其他工具）：

http://schematron.com/resources/documentcomplexitymetric.html

除此之外，恐怕我唯一的建议就是选择几个看似合理的指标来跟踪，并重新评估它们，以确定它们是否确实随着应用于每个文档的努力而产生趋势......