Tip

SEI Checklist

The SEI checklist is useful if you receive SLOC counts defined with a nonstandard definition or when a definition needs to be ferreted out from developers who may not understand the definitions clearly. It is always best to get SLOC counts in logical, non-comment source statements and not have to qualify a definition using these checklists.

Different languages represent a line of code differently due to conceptual differences involved in accounting for executable statements and data declarations. The purpose of SLOC as a quantitative size measure is to provide an input to a future estimate that will determine how much effort is required to develop or modify a program. To minimize the risk of inconsistent definitions, the Software Engineering Institute (SE) developed a checklist for defining the physical and logical lines of code measures.

SEI Definition Checklist for Source Statement Counts

One helpful tool in counting source lines of code is preparing a checklist of attributes and determining their values. Using checklists provides a detailed definition of the source line of code counting methodology so all parties involved have a clear concise definition to use. The following checklist identifies suggested attributes for size measures.

The nine attributes on the checklist describe the types of software statements for measuring the source lines of code:

  1. Statement type
  2. How produced
  3. Origin
  4. Usage
  5. Delivery

    Requires Free Membership to View

  1. Functionality
  2. Replications
  3. Development status
  4. Language

These attributes take on values independently of each other. The attributes and their respective values represent statement types that are most commonly used by software development groups that seek and utilize the results of size measurement. Using SLOC as a sizing metric has its own trade-offs. It is important to identify and describe the attributes of size, without which consistency in size measurements cannot be achieved.

This article was originally printed in the book Software Sizing, Estimation, and Risk Management. It is being reprinted with permission of Auerbach Publications, Taylor & Francis Group.

----------------------------------------
About the author: Dan Galorath is president of Galorath Inc.


This was first published in May 2007

There are Comments. Add yours.

 
TIP: Want to include a code block in your comment? Use <pre> or <code> tags around the desired text. Ex: <code>insert code</code>

REGISTER or login:

Forgot Password?
By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States. Privacy
Sort by: OldestNewest

Forgot Password?

No problem! Submit your e-mail address below. We'll send you an email containing your password.

Your password has been sent to:

Disclaimer: Our Tips Exchange is a forum for you to share technical advice and expertise with your peers and to learn from other enterprise IT professionals. TechTarget provides the infrastructure to facilitate this sharing of information. However, we cannot guarantee the accuracy or validity of the material submitted. You agree that your use of the Ask The Expert services and your reliance on any questions, answers, information or other materials received through this Web site is at your own risk.