Использование LOC в качестве единицы измерения размера программного продукта

LOC оценка представляет собой наиболее универсальную метрику, поскольку может использоваться при создании любых программных продуктов. Она проще и понятнее как для специалистов, так и для заказчиков и инвесторов. Например, если утверждается, что один компонент программной системы, состоящей из n компонентов, в среднем потребует написания около 1000 строк программного кода, то каждый в состоянии прикинуть ее общий размер и хотя бы примерно оценить трудозатраты, требующиеся для ее создания, исходя из предположения, что средняя производительность одного программиста по-прежнему составляет около 3000 строк кода в год.

Однако многие эксперты в области разработки программного обеспечения утверждают, что это плохая единица измерения. Наиболее существенный вопрос, который возникает при использовании LOC оценок, заключается в том, что же собой представляет одна строка программного кода? Кроме того, при использовании LOC в качестве единицы измерения возникают сомнения в достоверности результатов, так как не учитывается следующее:

• · число строк исходного кода зависит от уровня мастерства программиста. Фактически, чем выше мастерство программиста, тем меньшим количеством строк кода ему удастся обойтись для реализации определенной функциональной возможности (или функциональности) ПС;
• · высокоуровневые языки или языки визуального программирования требуют гораздо меньшего числа строк кода, чем, например, язык Ассемблера или С для отражения одной и той же функциональности. Достаточно представить себе два приложения, имеющих одни и те же функциональные возможности (те же экраны, отчеты, таблицы базы данных), но реализованные на разных языках. Очевидно, что существует обратная взаимосвязь между уровнем языка и производственной выработкой программиста;
• · фактическое число LOC остается неизвестным до тех пор, пока проект не будет почти завершен. Поэтому LOC нельзя использовать для предварительной оценки усилий на разработку и построения плана-графика проекта;
• · в программистском сообществе не достигнуто соглашения о методе подсчета строк кода. Языковые конструкции, используемые, например, в Visual C++, Ассемблере, Коболе или SQL, абсолютно различны. Метод же остается общим для любых приложений, в том числе использующих комбинацию различных языков;
• · заказчику сложно понять, каково соотношение указанных им функциональных и нефункциональных (технических) требований к ПС и объемов программистской работы.

В то же время для повышения достоверности оценок есть несколько достаточно простых рекомендаций:

• · Убедитесь, что каждая учитываемая строка исходного кода содержит лишь один оператор. Если в одной строке содержатся два выполняемых оператора, разделенных точкой с запятой, то они должны учитываться как две строки. Если же один оператор разбит на несколько «физических» строк, он будет учитываться как одна строка. В языках программирования допускаются различные правила кодирования, но обычно проще определять в строке один оператор, обрабатываемый компилятором или интерпретатором.
• · Учитывайте все выполняемые операторы. Конечный пользователь может не иметь возможности практически использовать каждый оператор, но все операторы должны поддерживаться данным продуктом, в том числе и утилитами.
• · Определения данных учитывайте лишь один раз.
• · Не учитывайте строки, содержащие комментарии.
• · Не учитывайте отладочный код либо другой временный код (пробное ПО, средства тестирования и пр.).
• · Учитывайте каждую инициализацию, вызов или включение макроса (директивы компилятора) в качестве части исходного кода, в которой осуществляется какое-либо действие. Не учитывайте повторно используемые операторы.

На практике при оценке размера больших программных систем чаще пользуются показателем тысяч строк исходного кода KSLOC. Эта метрика чаще всего используется при оценках производительности, которая рассчитывается как KSLOC/SM, где SM — staff-month (человеко-месяцы).