Counting XML Source Lines of Code
A customer recently asked how to count XML for their software sizing activity. Turned out the question was more detailed than just the syntax. They really wanted to know IF they should count XML and, if using lines of code, if they should adjust the XML lines. They pointed out that many of their projects include up to 25% XML lines.
The bottom line is that XML while it has no procedural statements (it is a data declaration language) can require significant effort in software development and should be counted. SEER users can use the code generation knowledge base in a component for XML… Also, due to syntax and if not using the code generation kbase , it is appropriate to adjust the XLM lines…. For Galorath research an XML line is about .29 SLOC.
Counting XML
XML is interesting to count since an XML document generally doesn’t actually do anything… that is, XML does not include procedural code. XML is pure declarations wrapped in tags. There is an if statement that can change the value of an element, not program logic. XML Separates Data from HTML. With XML, data can be stored in separate XML files so you can concentrate on using HTML for layout and display and ensure changes in the underlying data will not require any changes to the HTML.
The following are the generic logical source line counting rules:
Step Five: Prepare Baseline Estimate
Budget and schedule are derived from estimates, so if an estimate is not accurate, the resulting schedules and budgets are likely to be inaccurate also. Given the importance of the estimation task, developers who want to improve their software estimation skills should understand and embrace some basic practices. First, trained, experienced, and skilled people should be assigned to size the software and prepare the estimates. Second, it is critically important that they be given the proper technology and tools. And third, the project manager must define and implement a mature, documented, and repeatable estimation process.
To prepare the baseline estimate there are various approaches that can be used, including guessing (which is not recommended), using existing productivity data exclusively, the bottom-up approach, expert judgment, and cost models.
Software Productivity Laws
These laws of software productivity help explain the dynamics of an engineering development project, and they illustrate some of the reasons that just using productivity to estimate is inadequate.
Law 1 - Smaller teams are more efficient. The smaller the team, the higher the productivity of each individual person.
Law 2 - Some schedule compression can be bought. Adding people to a project, to a point, decreases the time and increases the cost as larger teams work together.
Law 3 - Every project has a minimum time. There is an incremental person who consumes more energy than he or she produces. Team size beyond this point decreases productivity and increases time. (Law 3 is also known as Brooks’ law.)
Step Four: Software Sizing
Size is generally the most significant (but certainly not the only) cost and schedule driver. Overall scope of a software project is defined by identifying not only the amount of new software that must be developed, but also must include the amount of preexisting, COTS, and other software that will be integrated into the new system. In addition to estimating product size, you will need to estimate any rework that will be required to develop the product, which will generally be expressed as source lines of code (SLOC) or function points, although there are other possible units of measure. To help establish the overall uncertainty, the size estimate should be expressed as a least-likely-most range.
Predicting Size
Whenever possible, start the process of size estimation using formal descriptions of the requirements such as the customer’s request for proposal or a software requirements specification. You should reestimate the project as soon as more scope information is determined. The most widely used methods of estimating product size are:
