SEI Checklist

The SEI Checklist can help you define source lines of code (SLOC) values to enable people to carefully explain and define the SLOC measure used in a project.

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
  6. Functionality
  7. Replications
  8. Development status
  9. 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

Dig deeper on Software Quality Management

Pro+

Features

Enjoy the benefits of Pro+ membership, learn more and join.

0 comments

Oldest 

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:

SearchSOA

TheServerSide

SearchCloudApplications

SearchAWS

SearchBusinessAnalytics

SearchFinancialApplications

SearchHealthIT

Close