您如何衡量/估计 XML 编程工作的规模？答案

【问题标题】：How do you measure/estimate size of XML programming effort?您如何衡量/估计 XML 编程工作的规模？
【发布时间】：2010-10-04 03:00:30
【问题描述】：

为了设置场景 - 我在喜欢估计和跟踪几乎所有事情的行业之一工作。我们的关键指标之一是 SLOC（源代码行 - 声明性和可执行语句）。我们将其用于项目规模和成本估算、项目规划和许多其他事情。我们尝试使用它来比较苹果和苹果（即，我们不会将一种语言/领域的 SLOC 与另一种语言/领域的 SLOC 进行比较）。注意：我们不会根据此指标评估个别开发人员，也不会仅仅因为 SLOC 与预期不同而将其称为错误或坏事。但是，我们确实认为一个项目有更多的 SLOC，也可能有更多的错误。

最近，我开始在使用库代替原本需要手动编码的组件的项目中工作 - 例如 JSF 代替 JSP，Hibernate 代替 JDBC 等等。所以...而不是编写行代码，我们的团队正在开发 XML 文件。 XML 映射仍然需要付出努力，并且复杂性之间仍然存在模糊的相关性 - 在给定项目中拥有多 100 倍的这些 XML 配置文件可能表明它需要更多的努力来创建并且可能比仅具有的项目更复杂的调试XML 文件的 1/100。

那么...有人对测量这些 XML 配置文件的大小有什么建议吗？ # 元素？ # 元素 + # 属性？还有什么？

【问题讨论】：

标签： xml jakarta-ee estimation

【解决方案1】：

首先我要说的是，根据这样的标准评估项目就像根据同样的事情评估程序员一样愚蠢。我知道有研究表明代码行数和代码缺陷数量之间存在明显的相关性。在我看来，这只是一个扩大规模的问题。

话虽如此，如果您的领主...错误...我的意思是管理要求您提出一些建议，这里有一些相对容易的衡量标准：

节点总数
节点类型数
每个节点的平均属性
最高级别的嵌套

【讨论】：

我们并不需要，因为我不想忽视开发 XML 配置的工作。从理论上讲，XML 文件为我们节省了一定程度的复杂性，但它们仍然需要工作。

【解决方案2】：

好吧，如果您只是根据基本的 SOAP/WSDL 操作、消息和类型将架构映射到结构，那么您可能只需将这些方面中的每一个都等同于其各自的方法、消息和类。

例如...这样的客户模式：

  <?xml version="1.0" encoding="utf-8"?>
<xs:schema xmlns:tns="http://tempuri.org" 
           targetNamespace="http://tempuri.org"
           xmlns:xs="http://www.w3.org/2001/XMLSchema">
  <xs:element name="Customer">
    <xs:complexType>
      <xs:sequence>
        <xs:element name="FirstName" type="xs:string" />
        <xs:element name="LastName" type="tns:LastNameType" />
      </xs:sequence>
      <xs:attribute name="CustID" type="xs:positiveInteger"
                    use="required" />
    </xs:complexType>
  </xs:element>
  <xs:simpleType name="LastNameType">
    <xs:restriction base="xs:string">
      <xs:maxLength value="20"/>
    </xs:restriction>
  </xs:simpleType>
</xs:schema>

...等同于 Customer 类...

public class Customer
{
    public string FirstName{}
    public string LastName{get;set;}
    etc...
}

通过这种方式，您可以继续使用当前的 SLOC 基准，只是在相对范围内。

这样做的问题是，编写 XML 模式实际上并不能像编写 Java 或 C# 程序那样允许 LOC 的大变化。程序员可以以一百万种不同的方式编写 C# 类，其中架构定义更加结构化，并且只允许操作、消息和变量名称的长度变化。因此，如果您现在只是编写 XML 而不是 Java 或 C#，那么您可能需要考虑您的 SLOC 指标在确定项目规模和错误方面将比过去少很多。

【讨论】：

要明确 - 我关心的不是自定义开发模式的复杂性。这是对开源产品定义的模式的重用。架构的复杂性与我们使用它的方式的复杂性是不同的。

【解决方案3】：

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

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

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

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

除此之外，恐怕我唯一的建议是只选择几个指标来跟踪看起来合理的指标，然后重新评估它们以确定它们是否真的会随着对每个文档的努力而产生趋势。. .

【讨论】：