XML 프로그래밍 노력의 규모를 어떻게 측정/추정합니까?

StackOverflow https://stackoverflow.com/questions/489573

  •  20-08-2019
  •  | 
  •  

문제

상황을 설정하려면 - 저는 거의 모든 것을 추정하고 추적하는 것을 좋아하는 산업 중 하나에서 일하고 있습니다.우리의 주요 지표 중 하나는 SLOC(코드의 소스 라인 - 선언적 및 실행 가능한 명령문)입니다.우리는 이를 프로젝트 규모 및 비용 추정, 프로젝트 계획 및 기타 여러 용도로 사용합니다.우리는 이를 사용하여 사과와 사과를 비교하려고 합니다(즉, 한 언어/도메인의 SLOC를 다른 언어/도메인의 SLOC와 비교하지 않습니다). 메모:우리는 이 측정 기준으로 개별 개발자를 평가하지 않으며 단지 SLOC가 예상과 다르다는 이유로 무언가 잘못되었거나 나쁘다고 부르지 않습니다.우리 하다, 그러나 프로젝트에는 더 많은 SLOC가 있고 더 많은 버그가 있을 가능성이 높다고 생각하세요.

꽤 최근에 저는 손으로 코딩했을 구성 요소 대신 라이브러리를 사용하는 프로젝트 작업을 시작했습니다. 예를 들어 JSP 대신 JSF, JDBC 대신 Hibernate 등이 있습니다.그래서...우리 팀은 코드를 작성하는 대신 XML 파일을 개발하고 있습니다.XML 매핑에는 여전히 노력이 필요하며 복잡성에 대한 모호한 상관 관계가 있습니다. 특정 프로젝트에 이러한 XML 구성 파일이 100배 더 많다는 것은 XML 매핑만 만드는 프로젝트보다 생성하는 데 더 많은 노력이 필요하고 디버그하기가 더 복잡할 수 있음을 의미할 수 있습니다. XML 파일의 1/100입니다.

그래서...이 XML 구성 파일의 크기를 측정하기 위한 제안이 있는 사람이 있습니까?요소 수?# 요소 + # 속성?다른 것?

도움이 되었습니까?

해결책

흥미로운 질문입니다.내가 알고 있는 유일한 측정항목은(당신이 제안한 대로 노드와 속성을 계산하는 것 외에) 구조화된 문서 복잡성 측정항목입니다.

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

현재 찾을 수 있는 최고의 링크입니다(오래 걸렸습니다).나는 또한 당신을 위해 그것을 계산해 줄 이 작은 도구를 찾았습니다. (다른 도구도 있을 수 있습니다):

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

그 외에 제가 드릴 수 있는 유일한 조언은 합리적으로 보이는 몇 가지 지표를 선택하여 추적하고 이를 재평가하여 각 문서에 들이는 노력으로 실제로 추세가 나타나는지 확인하는 것뿐입니다.

다른 팁

이와 같은 기준에 따라 프로젝트를 평가하는 것은 동일한 기준에 따라 프로그래머를 평가하는 것만큼이나 어리석은 일이라는 점부터 말씀드리겠습니다.코드 줄 수와 코드 결함 수 사이에 명확한 상관관계가 있다는 연구 결과가 있다는 것을 알고 있습니다.내 생각에는 그것은 단순히 규모가 커지는 문제일 뿐이다.

그렇긴 하지만, 당신의 대군주가... 오류... 제 말은 경영진이 당신에게 무언가를 생각해내도록 요구한다면 비교적 쉽게 측정할 수 있는 몇 가지 사항입니다:

  • 총 노드 수
  • 노드 유형 수
  • 노드당 평균 속성
  • 최고 수준의 중첩

음, 기본 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# 클래스를 작성할 수 있습니다.따라서 Java 또는 C# 대신 XML을 작성하는 경우 SLOC 메트릭이 프로젝트 크기 및 버그를 결정하는 데 사용했던 것보다 훨씬 적은 양의 물을 보유하게 될 것임을 고려할 수 있습니다.

라이센스 : CC-BY-SA ~와 함께 속성
제휴하지 않습니다 StackOverflow
scroll top