CC BY
60
Северин П.А.1, Гольчевский Ю.В.2
1 ФБГОУ ВПО «Сыктывкарский государственный университет», магистрант,
pav9 687@yandex. ги
2 ФБГОУ ВПО «Сыктывкарский государственный университет», доцент, yurag@syktsu.ru
Анализ проектов разработки программных продуктов с применением метрик динамики на основе расчета «кодовой карты» проекта
КЛЮЧЕВЫЕ СЛОВА:
Программный продукт, проект, метрики динамики. АННОТАЦИЯ:
В работе рассматривается проблема анализа проектов разработки программных продуктов с использованием метрик динамики, построенных на основе расчета «кодовой карты» проекта и визуализации истории разработки таких проектов.
Постановка проблемы
Использование метрик программного обеспечения, представляющих собой численное значение некоторых его свойств, является успешной практикой решения задач оценки объема трудозатрат, необходимых для создания и поддержания того или иного программного продукта.
«Экономическая» специфика применения обуславливает качественный состав наиболее используемых метрик - как правило, все они, так или иначе, имеют отношение к оценке сложности исходных кодов [1].
Вместе с тем, существует необходимость оценки иных характеристик программного обеспечения, в том числе связанных и с информационной безопасностью, которая, в общем случае, не ограничивается лишь обеспечением конфиденциальности.
Не представляет особой сложности привести примеры, в которых необходимы и более узкоспециализированные метрики безопасности. Например, позволяющие оценивать текущий уровень безопасности применения программного продукта, понимаемый как максимальное потенциально возможное количество присутствующих в исходном коде актуальной версии уязвимостей. Под уязвимостями понимаются недостатки программы, присутствующие в ее исходном коде и приводящие к нарушению информационной безопасности.
В настоящее время законодательно закрепленным критерием является срок эксплуатации программного продукта, по истечении которого требуется повторная проверка безопасности применения путем экспертного анализа его исходных кодов, а также факта внесения
модификаций исходного кода [2]. Однако срок эксплуатации - достаточно условная метрика, поскольку программный продукт, рассматриваемый как совокупность постоянно обновляемых текстов исходных кодов, значительно изменяется за это время. Также имеют место определенные неудобства для разработчиков программного обеспечения, связанные с необходимостью повторных сертификационных испытаний при любом изменении программных продуктов, в том числе выпуска обновлений. Поэтому востребованность объективных метрик, позволяющих охарактеризовать интенсивность внесения изменений и их давность (динамику развития программного продукта) очевидна.
В настоящее время среди метрик безопасности одной из наиболее общеупотребительных является плотность уязвимостей (дефектов) на единицу кода. Но использование данной метрики ограничивается лишь применением ее в качестве индикатора для временной оценки -практический смысл имеет лишь ее изменение в версиях программного продукта.
Таким образом, несмотря на доступность всей предыстории развития экземпляра программного обеспечения и исходных кодов на каждом из его этапов, процесс определения текущего уровня безопасности применения программного продукта представляет собой определенную сложность.
Целью данной статьи является изучение способов построения метрик динамики программного кода и визуализации истории разработки проектов.
Расчет метрик динамики
Развитие программного продукта (проекта) состоит из временных этапов. Актуальный набор исходных кодов, включающий все выпущенные ранее обновления и формируемый по окончании каждого из таких этапов, будем называть дистрибутивом.
В качестве метрик безопасности могут рассматриваться зависимости типа величины кода дистрибутива от времени (версии проекта), а также зависимости типа числа обнаруженных уязвимостей от времени. Сравнение проектов друг с другом может осуществляться с помощью таких показателей, как общее число уязвимостей за весь период развития, средний размер дистрибутива, отношение числа уязвимостей к среднему размеру дистрибутива и т.п.
Например, на рисунке 1 представлены графики, показывающие количество обнаруженных и исправленных уязвимостей безопасности в проектах разработки популярных систем управления контентом веб-сайтов (CMS) Joomla, Drupal и TYPO3, а на рисунке 2 - зависимости общего количества строк кода от версии для тех же CMS. Можно было бы проводить некоторые сравнения приведенных на рисунках данных, однако проблемой такого подхода является то, что общее количество строк кода - весьма условный показатель.
(а)
(б)
(в)
Рисунок 1. Зависимость количества исправленных уязвимостей от версии для CMS: а)
Joomla, б) Drupal, в) TYPO3.
Количество строк
J
Версии
$ S $ & & $ # <* ^ ^ «? S J <? о9
v J?- J? J?- V* v v v v v v V v v V г- v v"
(а)
Количество строк
67000 57000 47000 37000
17000
7000
онгчгпчгшщг^ОООТОН
о и! о о m
ui «i 1 ^ ™
u-| ь-|
OrHLOOulO^CCi
^О ^Х* цО
Версии
О LO О 1Л О N SS^HrJN Г— Г— Г--
(б)
500000
450000
400000
350000
300000
Количество строк
250000
Версии
ОГМгЧгОШГ^О^гНгО
LO LO
H lO CO
LD (£) tD
rH LO 00 о
Й Ш Й
(в)
Рисунок 2. Зависимость общего количества строк кода от версии для CMS: а) Joomla, б)
Drupal, в) TYPO3
Рассмотрим пример для проекта, состоящего из трех временных этапов, и обозначим Vn - объемы кода на n-ном этапе, n Х1,.„, 3. Тогда на втором этапе добавилось не менее (v2 - Vi) кода, а код третьего этапа
отличается от кода второго не менее, чем на (У2 - Уз). При этом код второго этапа может быть полностью новым, а на третьем этапе разработчики могли опять вернуться к исходному коду первого этапа. Таким образом, для анализа проекта нужна полная «карта кода» (или «кодовая карта»), например такая, как показано на рисунке 3._
- код, неизменный на всех этапах
- код, неизменный для 2 и 3 этапа
- код, уникальный для каждого этапа
этапы
1
2
3
Рисунок 3. Пример необходимой для анализа кодовой карты
Один из возникающих при этом вопросов - это вопрос автоматизации создания такой кодовой карты, поскольку число этапов разработки проекта может быть весьма велико.
Рассмотрим пример проекта из трех этапов со следующими допущениями:
• на любом этапе в дистрибутив может быть внесен код, который может просуществовать до любого из последующих этапов;
• если разработчик на каком-либо этапе исключает фрагмент кода из проекта, то на следующих этапах данный фрагмент кода не появляется.
Последнее предположение существенно ограничивает общность получаемого решения, однако на практике подобные случаи «прерываний» и локальных «откатов» достаточно редки, поскольку в процессе развития системы модернизируется ее функционал, и возврат к старому коду является, чаще всего, регрессом на промежуточном этапе.
Пусть N - число этапов, а rnm - объем фрагмента кода, который присутствовал в дистрибутивах с n-го по m-ый этап (m > n).
Для рассматриваемого примера (N = 3) это выглядит так, как показано на рисунке 4.
Зная объемы дистрибутивов, можно записать N уравнений вида:
Пг+^+Ти - iv
Ги+Ги+Т2, + Г2я = V2;
ти I I - V,.
Однако, поскольку всего имеется N-(N+1)/2 неизвестных rnm, необходимы еще N-(N-1)/2 уравнений и дополнительные данные, процесс получения которых можно автоматизировать.
Потребуется утилита с допускающим автоматизацию интерфейсом, которая принимает на входе 2 текстовых файла, и выдает число совпадающих в обоих файлах строк (например, Beyond Compare [3]). При сравнении необходимо учитывать не только содержимое каждой строки, но
и порядок их следования относительно друг друга.
Г13
Г12
r 11 Г23
Г22 Г33
1 2 3
Рисунок 4. Схема распределения фрагментов кода в дистрибутивах
Дистрибутивы готовятся для анализа следующим образом:
• командный скрипт обходит все каталоги дистрибутива в определенном (например, алфавитном) порядке;
• копирует содержимое всех выполняемых (в примере с CMS - *.php) файлов (без учета комментариев), в один файл;
• утилита сравнивает все эти файлы попарно.
Пусть snm - объем кода, который совпадает при сравнении n-го и m-го дистрибутива. Тогда можно записать недостающие для решения относительно переменных rnm системы уравнения:
Г1, + Г1а = Sla;
Г1а = Slsi
Г1а + Г2а = S2a-
Таким образом, построение кодовой карты сводится к решению системы линейных уравнений.
Кодовая карта позволит более наглядно визуализировать процесс развития проекта по сравнению с графиками зависимости размера дистрибутива от стадии проекта и выводов, основанных на сравнении с ними других графиков.
Однако наиболее существенным является то, что знание значений переменных rnm дает возможность вычислить ряд метрик динамики, которые позволят как сравнивать и характеризовать процесс развития программных проектов, так и осуществлять вычисление метрик безопасности. Например, общее количество оригинального кода, среднее время жизни кода, мгновенную и среднюю скорость изменения кода, коэффициенты сложности и безопасности проекта и другие.
Литература
1. Метрики кода и их практическая реализация в Subversion и ClearCase. Часть 1. [Электронный ресурс] URL: http://cmcons.com/artides/CC_CQ/ dev_metrics/mertics_part_1 (Дата обращения: 06.09.2013).
2. Положение о сертификации средств защиты информации по требованиям безопасности информации, утвержденное приказом председателя Государственной технической комиссии при Президенте Российской Федерации от 27 октября 1995 г. № 199.
3. Beyond Compare. [Электронный ресурс] URL: http://www.scootersoftware.com/index.php (Дата обращения: 06.09.2013).
