Национальный аэрокосмический университет им. Н.Е. Жуковского «Харьковский авиационный институт»
Студент
Орехов Александр Александрович, кандидат технических наук, доцент, профессор Национального аэрокосмического университета им. Н. Е. Жуковского «ХАИ», преподаватель, кафедра компьютерных систем и сетей.
УДК 004.054
Введение
Программное обеспечение не является совершенным, это означает, что для программного обеспечения может потребоваться дополнительный модуль или усовершенствование существующего модуля, после чего он может содержать некоторые незаметные или непроверенные ошибки, которые время от времени остаются в программном обеспечении. Ошибка может появляться на любой стадии разработки программного обеспечения, то есть анализа требований (RA), проектирования (SD), кодирования (SC), тестирования (ST), реализации (SI) и обслуживания системы (SM). С быстрым увеличением разработчиков в проектах с открытым исходным кодом, которые постоянно вносят свой вклад в разработку и совершенствование проекта, есть возможность введения новых ошибок в проект. На веб-сайт проекта ежедневно отправляется несколько ошибок, которые могут использовать некоторые инструменты управления конфигурацией (SCM) для управления версиями и выпуском программного обеспечения. Инструменты SCM могут не предоставлять никакого представления об отчетах об ошибках, а также о ходе исправления ошибок. Существует настоятельная необходимость в планировании и внедрении наилучшей системы отслеживания ошибок и отчетности. В среде с открытым исходным кодом обычно, когда ошибка отправляется, любой человек может начать работу по ее исправлению. Но в то же время другие люди могут также начать работу по исправлению той же ошибки. Поэтому владелец или модератор проекта будет путать, какое решение реализовать в системе. Business software провело исследование, целью которого было сравнение лучших поставщиков программного обеспечения для выявления дефектов и ошибок. Не существует ни определенного графика времени для исправления ошибки, ни человека / команды, ответственного за своевременную фиксацию ошибки.
В патентированом программном обеспечении исправление ошибки происходит поэтапно, поскольку на каждом этапе есть отдельная группа, ответственная за работу, выполняемую на этом этапе. В то же время в проекте с открытым исходным кодом любой может найти ошибку и начать работать над этим. Зависимость может стать основной проблемой при вычислении времени для исправления ошибки. Если ошибка обнаружена до фазы реализации, она может быть качественно разрешена командой разработчиков или владельцем модуля. Но как только программное обеспечение выпущено и внедрено, становится очень сложно исправить ошибку. Стало громоздкой задачей для модератора найти подходящего разработчика, который может исправить конкретную ошибку, потому что описание сообщения об ошибке может вообще не предоставлять полной информации [6]. Многие организации обычно полагаются на электронную почту с или без системы сообщений об ошибках с привязкой / обратной связью [1], [5], и эти ошибки будут поддерживаться в электронной таблице или в любом программном обеспечении для редактирования документов. Владельцу или разработчику снова становится очень сложно отслеживать ошибку и ход ее исправления. Существует множество инструментов, разработанных и используемых в настоящее время в промышленности для отчетности и отслеживания прогресса сообщений об ошибках как в небольших, так и в крупных проектах. Множество инструментов было разработано сообществом с открытым исходным кодом, а также частными компаниями, занимающимися разработкой программного обеспечения. Очень сложно выбрать определенную систему отчетности об ошибках и отслеживания, которая может предоставить нам эффективный, целесообразный, полезный и экономически эффективный инструмент для мониторинга хода выполнения графика исправления ошибок [2], [3]. Опрос проводился с целью выявления часто возникающих проблем в системе отчетности об ошибках разработчиками и пользователями [8]. Также были предприняты усилия по моделированию в поисках качества отчета об ошибках в прошлом [7]. Недавно был проведен опрос по инструментам отслеживания ошибок на основе представления, анализа и тенденций [10]. Марко и Александар [10] построили дерево решений на основе некоторых характеристик. Остальная часть статьи организована следующим образом: в разделе 2 документа описывается система отслеживания ошибок и жизненный цикл ошибок. Раздел 3 описывает различные критерии классификации системы отслеживания ошибок. В разделе 4 представлен подробный сравнительный анализ различных систем отслеживания ошибок на основе различных критериев сравнения. В 5 разделе выводы.
1. Система отслеживания ошибок (Багтрекер)
Система отчетности / отслеживания ошибок должна предоставлять интерактивную веб-платформу для отчетности об ошибках и отслеживания прогресса. Система может включать в себя общий процесс или конкретный график обработки сообщений об ошибках. Процесс внесения информации об ошибке может, как правило, содержать следующую пункты:
Как только ошибка будет отправлена в систему, менеджер увидит ее статус и посмотрит детали отчета и его различные параметры. Менеджер также может сбросить или обновить некоторые параметры и соответственно обновить значения статуса и обладателя бага. В крупных проектах с открытым исходным кодом средняя скорость передачи сообщений об ошибках достаточно высока. Например, в проекте [23] средняя скорость передачи сообщений об ошибках составляет 50 выпусков в день [24]. Таким образом, менеджеру очень сложно просматривать каждую ошибку, а затем обновлять ее статус и присваивать ошибку определенному человеку. Хотя каждая система / инструмент имеет свой собственный жизненный цикл ошибки, здесь общий жизненный цикл ошибки (рисунок 1).
Есть много систем отслеживания ошибок, доступных в отрасли для использования. Системы отслеживания ошибок также называются системой отслеживания проблем или багтрекером или системой отслеживания дефектов и т. Д. Системы отслеживания ошибок разрабатываются сообществом с открытым исходным кодом, а также организациями с закрытым кодом в качестве проприетарного программного обеспечения. Открытый исходный код означает, что исходный код предоставляется всем в соответствии с политикой GPL. Любой может внести свой вклад в код добровольно. В сообществах с закрытым исходным кодом исходный код является собственностью организации, и люди, которые не входят в проект, возможно, не смогут увидеть / просмотреть код. Некоторые из инструментов отслеживания ошибок принадлежат сообществам с открытым исходным кодом, а некоторые из них - сообществам с закрытым кодом или коммерческим организациям. Существуют организации, которые также могут предоставлять поддержку решений с открытым исходным кодом. Например, Redhat Inc. [21] предоставляет Red Hat Enterprise Linux (RHEL) и поддерживает сообщества проектов с открытым исходным кодом Fedora [22]. Fedora подпадает под категорию open source, в то время как RHEL - это коммерческая версия, которую поддерживает и спонсирует Redhat.
Рисунок 1 – Жизненный цикл ошибки/бага.
2. Критерии классификации
Система отслеживания ошибок варьируется от общего назначения до конкретной цели. Общая система будет иметь множество функций, в то время как системы целевого назначения могут иметь ограниченные возможности. Подходящий инструмент может быть выбран на основе требований пользователя. Это требование обычно отличается от платформы, поддержки, размера, отчетности, отслеживания и других особенностей проекта. Эти широкие критерии могут быть далее классифицированы или классифицированы в три или более подкатегорий, как указано в таблице 1.
Платформа относится к политике лицензирования, архитектуре, операционной системе, веб-серверу, серверной базе данных, языку программирования и клиент. Поддержка относится к языку, нескольким проектам, веб-интерфейсу, базе данных, уведомлению по электронной почте и локализации. Отчетность относится на основной формы, к электронной почте, вложений, веб и обратной связи. Отслеживание относится к своевременному обновлению состоянию ошибки, графикам количества отложенных ошибок, назначенным, фиксированным в течение определенного периода времени в каждой категории и средствам поиска новых, а также существующих ошибок, чтобы узнать об их статусе. Другая особенность относится к любой другой функции, которая не является частью вышеупомянутых категорий.
|
||||||||||||||
Имеется множество систем отслеживания ошибок. Я выбрал наиболее популярное, наиболее используемое и все еще в процессе усовершенствования, то есть чей релиз продолжается, и ведутся работы по совершенствованию его функции и включению новых функций. В обзоре рассмотрены следующие инструменты: BugZilla [11], Jira [12], Trac [13], Mantis [14], GNats [15], BugTracker.Net [16] и Fossil [17].
3.1 Классификация на основе характеристик платформы
Критерии сравнения, основанные на характеристиках платформы, показаны в таблице 2. В этой таблице большинство этих инструментов доступны в среде с открытым исходным кодом. Mantis является приложением с открытым исходным кодом и его бесплатная версия доступна для загрузки и использования. Некоторые из инструментов доступны в качестве лицензионной версии, для которой поддержку можно получить у владельца. Платная версия Jira поставляется в трех разных вариантах: Standard, Professional и Enterprise, исходя из размера проекта и поддержки.
Большинство этих инструментов работают в веб-среде, в то время как их ранние версии были доступны как клиент-серверная среда. Trac разработан на вики-архитектуре, то есть любой может видеть ошибки, исправлять ошибки и редактировать любую его часть. Рабочая среда для большинства проектов является кросс-платформенной, то есть они могут быть установлены на любом компьютере. BugZilla и GNats доступны в Linux, в то время как BugTracker.Net доступен в среде Windows. Клиенты основаны на браузере, поэтому они не зависят от платформы. Для веб-сервера большинство инструментов требовали apache / tomcat, за исключением BugTracker.Net, для которого требуется MS-IIS. Большинство этих инструментов поддерживают MySQL как базу данных, за исключением BugTracker.net, для которой требуется MS-SQL Server, а Fossil требует SQLLite. Эти инструменты могут варьироваться в зависимости от языка программирования, используемого в кодировании. Инструменты разработаны на языках программирования C, Python, PHP, Perl, Java и C # .Net.
Приложение
Платформа |
BugZilla |
Jira |
Trac |
Mantis |
Gnats |
BugTrack.Net |
Fossil |
Платформа |
Открытый код/бесплатная/ патентованный |
Патентованный |
Открытый код/бесплатная |
Открытый код/ бесплатная/платная |
Открытый код/бесплатная |
Открытый код |
Открытый код/ |
Архитектура системы |
Клиентский сервер/ веб-интерфейс |
Клиентский сервер/ веб-интерфейс |
Веб-интерфейс |
Веб-интерфейс |
Веб-интерфейс |
Веб-интерфейс |
Distributed web based |
ОС сервера |
Linux |
Кроссплатформенная |
Кроссплатформенная |
Кроссплатформенная |
Linux |
Windows |
Linux/Windows/MacOS |
Веб сервер |
Apache, MS-IIS |
Apache,Tomcat |
Apache |
Apache, MS-IIS |
Apache |
MS-IIS |
Apache, MS-IIS |
База данных |
MySQL, Oracle, PostgreSQL |
Все RDBMS |
MySQL, PostgreSQL,SQLite |
MySQL, MS SQL, PostgreSQL |
MySQL |
MySQL |
SQLite |
Язык программирования |
TCL/Perl |
Java |
Python |
PHP |
C |
ASP.Net |
C |
Клиент(веб браузер) |
Любой |
Любой |
Любой |
Любой |
Любой |
Любой |
Любой |
3.2 Классификация на основе характеристик поддержки
Важным компонентом для сравнения инструментов являются функции поддержки, которые показаны в таблице 3. Общие характеристики для функций поддержки - это язык, веб-интерфейс, поддержка обслуживания, уведомление по электронной почте и локализация. Большинство инструментов поддерживают несколько языков на основе системы Unicode. Только Fossil и GNats не поддерживают несколько языков. Опять же в той же строке, большинство инструментов поддерживают веб-интерфейс. Люди более заинтересованы в использовании интерфейса на основе браузера, поскольку он не зависит от среды операционной системы. Fossil не имеет полного веб-интерфейса. Техническая поддержка также предоставляется бесплатно или с платной услугой с номинальной оплатой. Всякий раз, когда сообщается о новой ошибке или обновлении, электронное письмо автоматически отправляется всем пользователям, которые находятся в зарегистрированном списке рассылки с проектом. Это письмо также будет отправлено всем зарегистрированным пользователям, даже если есть небольшое обновление. Локализация ошибок, то есть поиск наиболее релевантной части иерархии исходных файлов программного обеспечения в базе данных хранилища ошибок, является еще одной важной функцией, предоставляемой BugZilla, Trac и Mantis, в то время как другие не имеют.
Приложение
Поддрежка |
BugZilla |
Jira |
Trac |
Mantis |
Gnats |
BugTrack.Net |
Fossil |
Поддержка языка |
Да |
Да |
Да |
Да |
Нет |
Да |
Нет |
Веб интерфейс |
Да |
Да |
Да |
Да |
Да |
Да |
Нет |
Техническая поддрежка |
Да |
Да |
Да |
Да |
Нет |
Да |
|
Email оповещение |
Да |
Да |
Да |
Да |
Да |
Да |
Нет |
Локализация ошибок |
Да |
Нет |
Да |
Да |
Нет |
Нет |
Нет |
3.3 Классификация по видам отчетности
Другим важным компонентом является сообщение об ошибке в проекте. Это может быть сделано любым из этих методов, например, основанной на форме, электронной почтой, вложениями, веб (онлайн) и обратной связью. Это показано в таблице 4.
Приложение
Оповещение |
BugZilla |
Jira |
Trac |
Mantis |
Gnats |
BugTrack.Net |
Fossil |
Форма |
Да |
Да |
Да |
Да |
Да |
Да |
Да |
|
Да |
Да |
Нет |
Да |
Да |
Да |
Нет |
Вложение |
Да |
Да |
Нет |
Да |
Да |
Да |
Нет |
Web(онлайн) |
Да |
Да |
Да |
Да |
Да |
Да |
Да |
Обратная связь |
Да |
Да |
Да |
Да |
Да |
Да |
Да |
BugZilla, Jira, Mantis и BugTraccker.Net имеют почти все средства отчетности, но Trac и Fossil отстают в приложениях и отчетах по электронной почте.
3.4 Классификация по признакам отслеживания
Функция отслеживания будет содержать подкатегории: своевременные обновления, графический дисплей и средство поиска. Большинство систем имеют эти функциональные возможности, как показано в таблице 5. Это может быть далее отнесено к еще одному уровню. Каждый раз, когда будут получены новые обновления, зарегистрированные участники получат по электронной почте уведомление об обновлениях, а также о новой версии системы. Графическое отображение - одна из очень важных функций, которые сообщают пользователю количество отложенных ошибок, количество открытых ошибок, количество закрытых ошибок, время, затраченное каждой ошибкой в форме интерактивных диаграмм, и расчетное время для устранения ошибки . Чтобы отслеживать ошибку, у инструментов есть средство для поиска ошибки, которая уже отправлена в систему. Это будет полезно при идентификации дублирующихся ошибок [4]. Продукт текущего дня должен иметь все эти объекты с динамическими графическими и графическими параметрами. Поисковый механизм также является одним из важных факторов. Как правило, системы имеют полнотекстовый поиск по названию, описанию и кратким отчетам об ошибках.
Приложение
Оповещение |
BugZilla |
Jira |
Trac |
Mantis |
Gnats |
BugTrack.Net |
Fossil |
Своевременное обновление |
Да |
Да |
Да |
Да |
Да |
Да |
Да |
Графики |
Да |
Да |
Да |
Да |
Да |
Да |
Да |
Поиск/фильтрация |
Да |
Да |
Да |
Да |
Да |
Да |
Да |
Большинство систем могут предоставить средство поиска по любому из параметров, таких как идентификатор ошибки, степень серьезности, приоритет, время подачи, автор, кому назначена ошибка, номер назначения / истории назначения и т. д. Существует несколько параметров, на которых может быть обеспечено средство поиска. Jira имеет ограниченные параметры поиска параметров, но мощный. Mantis выводит результаты поиска в столбчатой диаграмме, чтобы показать прогресс конкретной ошибки.
3.5 Классификация по другим признакам
Любая другая функция может включать в себя гораздо больше функций, которые очень важны, но могут не иметь одну специальную категорию. Это локализация ошибок, предсказание изменений, просмотр репозитория исходного кода, контроль версий и средство Subversion. Некоторые из этих систем обладают возможностями этих функций, но они не являются развитыми.
В целом вышеупомянутые подкатегории могут быть дополнительно подразделены на отдельные подгруппы. Это позволит лучше представить систему отчетности и отслеживания ошибок. Это становится очень полезным при выборе инструмента, который будет соответствовать указанным пользователем критериям.
4. Выводы
В данной статье рассмотрены наиболее важные функции багтрекинговых систем и распределены по критериям. Знание основных и дополнительных функций позволит более подробно и главное безошибочно выбрать подходящую систему для определенного проекта или непосредственно для работы в группе разработчиков. В будущем, будет проведена работа над возможностью присвоения приоритета и числовой оценки к каждой функции, что позволит аргументировать выбор конкретными цифрами. Так же есть возможность автоматизировать оценивания и с помощью программы, и вывода информации в виде таблицы или диаграммы. Это позволит наглядно доказать выбор системы.
Рецензии:
17.10.2017, 11:10 Зарипова Римма Солтановна
Рецензия: Удовлетворяет требованиям научной статьи. Рекомендую к публикации.
Комментарии пользователей:
Оставить комментарий